{"url":"https://docs.arbitrum.io/","domain":"docs.arbitrum.io","title":"Arbitrum documentation","text":"Get startedwith ArbitrumArbitrum 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.Solidity quickstartStylus quickstartUnderstand ArbitrumArbitrum 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.Build decentralized appsQuickstart (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.Launch your own chainA 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.Run a nodeRun 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.Bridge tokensQuickstart (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.","tokens":471,"squid":"spider-01","role":"Chain Spider","at":1791338256543,"hash":"1e88467a391df241fcaa2870e3f030e188b24b55"}
{"url":"https://dev.jup.ag/docs","domain":"dev.jup.ag","title":"Jupiter Developer Docs - Jupiter Developers","text":"​Why Jupiter\nJupiter is the liquidity infrastructure behind the majority of DeFi on Solana. Whether you’re building a trading terminal, a DeFi protocol, a payments app, or an AI agent, Jupiter gives you the APIs to ship fast and at scale.\nThe same infrastructure that powers jup.ag is available to you as production-grade REST APIs. No RPC nodes, no blockchain state management, no transaction complexity. Jupiter abstracts all of it so you can focus on your product. Every API returns clean JSON, works with a single API key, and is designed to be consumed by both developers and AI agents.\n​APIs\nNo InfrastructureNo RPC nodes, no blockchain state management. Jupiter handles all on-chain interactions for you.Best ExecutionMetis, JupiterZ, and third-party routers compete on every swap. Your users get the best price available.AI-ReadyClean JSON, simple REST, and purpose-built tools (llms.txt, MCP, Skills, CLI) for AI agents and LLMs.\n​Developer Platform\nOne API KeyA single key from the Developer Platform unlocks every Jupiter API. Start free, no upfront payments.ObservabilityReal-time analytics, request logs, and usage dashboards. Debug and monitor your integration from the platform.Built for TeamsOrganisation management, role-based access, shared API keys, audit logs, and 2FA.\n​Products\n\n​Developer Resources\n\n​AI\nJupiter is built for AI agents and LLM-powered development. Every API returns clean JSON with no RPC complexity.\n\n​Community\n\n​Socials\n\n​Get Started\nNew to Jupiter development? Start with the essentials:\n\nEnvironment Setup for libraries, RPC connection, and wallet setup\nDevelopment Basics for accounts, transactions, priority fees, and compute units\nWas this page helpful?","tokens":425,"squid":"spider-02","role":"Liquidity Spider","at":1791338260882,"hash":"a83f827695ba763afc23416b0c098fe2e8ac7502"}
{"url":"https://akash.network/docs/","domain":"akash.network","title":"Akash Network Documentation | Akash Network Documentation - Your Guide to Decentralized Cloud","text":"Akash Network Documentation Access comprehensive documentation to guide you through using Akash Network. Find detailed instructions, FAQs, and resources for a seamless experience. \nGetting Started\n What is Akash Network? Learn about decentralized cloud computing Core Concepts Understand how Akash works Quick Start Deploy your first app in under 10 minutes AI Agents Deploy to Akash with AI coding agents Setup & Deploy Install the Akash skill and deploy from natural-language prompts Developers Deploy applications and build on Akash Network Getting Started Choose your deployment method and get started Deployment Console, CLI, SDKs, and AuthZ Contributing Contribute to Akash codebase and documentation Providers Run compute resources on Akash Network Getting Started Should you run a provider? Hardware requirements and cost analysis Setup & Installation Provider Playbook, Kubespray, and Provider Console Operations Lease management, monitoring, maintenance, and provider verification API Documentation Build on Akash with SDKs, APIs, and architectural insights Getting Started Choose your integration method SDK Official Go and JavaScript/TypeScript SDKs API Console Managed Wallet API Provider Architecture Provider service components Node Architecture Blockchain node architecture and APIs Node Operators Run blockchain nodes and validators Getting Started Choose between full node and validator Node Build CLI Build, Omnibus, and Helm Chart Validators Running validators, Omnibus, and TMKMS Network Upgrades Mainnet 15 upgrade guide Hermes Relayer Run the oracle price relayer (Pyth → Wormhole → oracle) Learn Deep dive into Akash concepts and resources Core Concepts Detailed guides for deployments, storage, GPUs, and more Community Resources Discord, GitHub, blog, and support channels \nNeed Help?\n Discord - Get help from the community GitHub - Report issues and get support","tokens":472,"squid":"spider-03","role":"Compute Spider","at":1791338260919,"hash":"5d1b039613b0b6e68fac6aa108f4eb2cd1bd0b8b"}
{"url":"https://docs.arbitrum.io/arbitrum-bridge","domain":"docs.arbitrum.io","title":"Arbitrum bridge","text":"Arbitrum bridgeMove ETH and ERC-20 tokens between Ethereum and Arbitrum chains.Request an updateThe Arbitrum bridge moves ETH and ERC-20 tokens between Ethereum and Arbitrum One, Arbitrum Nova, and other Arbitrum chains.\nQuickstartTransfer ETH or ERC-20 tokens between a parent and a child chain.USDC on Arbitrum OneThe two kinds of USDC: Arbitrum-native and bridged from Ethereum.Embedded bridge widgetIntegrate and configure the bridge widget in your own dApp.Trace a transactionFollow a transfer through each stage of the bridge.Monitor withdrawalsTrack child-to-parent withdrawals and diagnose stuck ones.TroubleshootingAnswers to the questions users ask most often.How is this guide?QuickstartLearn how to use Arbitrum's bridge to transfer ETH or ERC-20 tokens between a parent chain and a child chain","tokens":202,"squid":"spider-01","role":"Chain Spider","at":1791338270539,"hash":"9ca2ff7f456ac4c9391cc2dddfa677bc10859c1b"}
{"url":"https://akash.network/docs/getting-started/quick-start/","domain":"akash.network","title":"Quick Start - Deploy with Free Trial | Akash Network - Your Guide to Decentralized Cloud","text":"Quick Start - Deploy with Free Trial Deploy your first application on Akash Network in under 10 minutes—no crypto wallet or blockchain experience required!\nThis guide walks you through signing up for the free trial and deploying your first application using one-click templates.\n\nWhat You’ll Get\n\n$1 in free credits — enough to run your first deployment and explore the deploy loop\n30 days — your window to use the trial credit\nOne-click deployment — use pre-built templates\nLive URL — access your deployed application instantly\n\nTime: ~10 minutes\nCost: $0 (free trial credits)\nDifficulty: Beginner-friendly (no technical knowledge required)\n\nWhat the trial covers: The $1 credit is a taste of the deploy loop, not a full compute grant. Deployments run up to 24 hours each, and you can redeploy as many times as you like inside the 30-day window. GPUs up to the RTX 3090 are available. Anything above — including the RTX 4090, RTX 5090, and datacenter cards like the A100, H100, H200, and B200 — requires a non-trial account.\n\nPrerequisites\nAll you need is:\n\nA valid email address (or Google / GitHub account)\n\nThat’s it! No credit card, no crypto wallet, no blockchain setup, no installation required.\n\nStep 1: Visit Akash Console\nOpen your browser and go to console.akash.network\n\nStep 2: Create Your Account\nChoose one of three signup options:\nOption A: Sign up with GitHub (Fastest!)\n\nClick “Continue with GitHub”\nAuthorize Akash Console in the popup\nDone! Skip to Step 3\n\nOption B: Sign up with Google\n\nClick “Continue with Google”\nChoose your Google account\nDone! Skip to Step 3\n\nOption C: Sign up with Email\n\nEnter your email address\nClick “Continue with email”\nCheck your inbox for a 6-digit code and enter it — no password needed\n\nStep 3: Welcome to Akash!\nYou’re in! You’ll see the onboarding screen with your $1 free trial credit already applied — no card required.\nYou’ll see three starter templates:\n\nTemplateStackEst. CostHello World ⭐Next.js in Docker~$0.25/moSpace AgentAgent Zero (AI agent)~$3.41/moLLM ChatbotLlama 3.1 8B~$1.50/hr (requires upgrade)\n\n⭐ Hello World is recommended for first-time users — it deploys in ~30 seconds.\n\nAlready have a Docker image? Click “Deploy image →” at the bottom to go straight to the configurator.\n\nTrial Status — shows your $1 credit balance and 30 days remaining\nImportant: Deployments last maximum 1 day during trial\n\nStep 4: Deploy Your First Application\nYou’ll see the welcome screen with “Choose a template below to launch your first app in seconds.”\nSeveral featured templates are displayed:\nOption A: Use a Featured Template (Recommended for First Deployment)\nPerfect for testing! Choose any featured template to get started.\n\nBrowse the available templates on the welcome screen\nSelect a template that interests you (web apps, databases, etc.)\nRead the template description\nClick “Deploy Now”\nReview the pre-filled configuration\nClick “Create Deployment”\n\nWait ~1-2 minutes for deployment to complete.\nYour first app is live!\nOption B: ComfyUI (AI/Image Generation)\nWant to try something more advanced?\n\nFind the “ComfyUI” card (artist with easel icon)\nRead the description: “A powerful, modular Stable Diffusion tool that lets you build and run advanced image workflows using a visual, node-based interface.”\nClick “Deploy Now”\nFollow the deployment steps\n\nNote: This requires more resources and will use more of your trial credits.\nOption C: Llama-3.1-8b (Language Model)\nDeploy a cutting-edge AI language model!\n\nFind the “Llama-3.1-8b” card\nRead the description: “A cutting-edge language model built for fast, context-aware text generation. Access a wide range of advanced language tasks.”\nClick “Deploy Now”\nFollow the deployment steps\n\nNote: GPU deployments use credits faster but are incredibly powerful!\n\nStep 5: Wait for Deployment\nAfter clicking “Deploy Now” on any template:\n\nConsole will show “Creating Deployment…”\nProviders will automatically bid to host your application\nThe best bid is automatically selected\nYour application starts deploying\n\nTotal time: 1-3 minutes (depending on the template)\nYou’ll see status updates:\n\n“Creating Deployment…”\n“Accepting Bid…”\n“Sending Manifest…”\n“Starting Services…”\n“Running”\n\nStep 6: Access Your Deployment\nOnce your deployment shows “Running” status:\n\nLook for the “URIs” or “Access URLs” section in your deployment details\nClick on the URL shown (e.g., https://your-app.provider.akash.network)\nYour web application will open in a new tab!\n\nCongratulations! You just deployed on Akash Network!\nWhat You Can Do Now:\n\nVisit your deployed app — click the URL to see it live\nView logs — check the “Logs” tab to see what’s happening\nMonitor resources — see CPU, memory, and storage usage\nCheck your balance — watch how much of your $1 credit you’re using\n\nManaging Your Deployment\nView Logs\nIn the Console deployment page:\n\nClick the “Logs” tab\nSelect your service (e.g., web or the template name)\nView real-time logs from your deployment\n\nUpdate Your Deployment\nTo change your deployment configuration:\n\nClick on your active deployment\nClick “Update Deployment”\nEdit the SDL configuration in the editor\nClick “Update” to apply changes\n\nNote: Updates modify your existing lease and may briefly interrupt service during the container restart.\nClose Your Deployment\nImportant: Remember trial deployments last maximum 1 day!\nWhen you’re done testing:\n\nGo to your “Deployments” page\nFind your active deployment\nClick “Close Deployment”\nConfirm the closure\n\nAlways close deployments when you’re done to conserve your $1 trial credits.\n\nUnderstanding Your Dashboard\nThe Console dashboard shows:\n\nTrial Status — your $1 credit balance, days remaining, and usage\nActive Deployments — all your currently running deployments (max 1 day each during trial)\nDeployment Costs — real-time spending from your trial credits\nAccount Balance — visual chart showing credit usage (Balance vs Deployments)\n\nPro tip: Hover over your balance at the top to see detailed credit information!\n\nCommon Questions\n”How long do trial deployments last?”\nAnswer: Trial deployments last a maximum of 1 day (24 hours). After 24 hours, they will automatically shut down. This is a trial limitation — paid accounts can run indefinitely.\n”Which GPUs are available on the trial?”\nAnswer: GPUs up to the RTX 3090 are available on the trial. High-end GPUs (RTX 4090, RTX 5090, A100, H100, H200, B200) are not available during the free trial. Add a payment method to switch to pay-as-you-go and unlock access to every GPU type on the network.\n”What happens after my $1 credit runs out?”\nAnswer: Your deployments will stop, but you can add more funds via credit card:\n\nClick your balance at the top\nClick “Add Funds”\nEnter amount and complete payment via Stripe (funds ACT)\nYour unused trial credits will be kept!\n\n”Can I use my own crypto wallet instead?”\nAnswer: Akash Console is the managed product and no longer accepts wallet connections. For self-custody — bring your own Keplr wallet, sign your own transactions, no time limits — use Console Air, the self-hostable companion app. See Choosing Your Console for a side-by-side comparison.\n”My deployment is taking a long time to start”\nSolution:\n\nWait 2-3 minutes — deployment can take time\nCheck the status updates in Console\nIf stuck for 5+ minutes, close and try a different template\nSome GPU deployments take longer due to high demand\n\n”I don’t see my deployment URL”\nSolution:\n\nWait until status shows “Running” (not just “Active”)\nClick on your deployment to see details\nLook for “URIs” or “Leases” section\nThe URL will be listed there once the container is fully running\n\n”Deployment failed to start”\nSolution:\n\nIf using a custom SDL, check your syntax (indentation, required fields)\nTry using a pre-built template instead (featured templates are most reliable)\nCheck the “Events” or “Logs” tab for error messages\nContact support on Discord if issue persists\n\nWhat’s Next?\nMaximize Your Trial\nYou have $1 in credits and 30 days — here’s how to make the most of it:\n\nTry the Templates — deploy Hello World, Space Agent, or any template that interests you\nExplore the Marketplace — browse pre-built solutions in the Templates section\nTest Your Own Apps — use the SDL Builder to deploy your projects\nMonitor Costs — see how much different workloads cost on Akash\n\nDeploy Real Applications\nNow that you know the basics, explore templates in Akash Console to deploy:\n\nWeb Applications — blogs, APIs, websites\nDatabases — PostgreSQL, MongoDB, Redis\nAI/ML — LLMs, stable diffusion, training\nGPU Workloads — full GPU marketplace available on paid accounts\n\nLearn More\n\nConsole Onboarding Guide — full walkthrough of the deployment configurator and provider marketplace\nCore Concepts — understand how Akash works\nSDL Reference — master the Stack Definition Language\nWhat is Akash? — deep dive into Akash Network\n\nFor Developers\nReady for more advanced workflows?\n\nAkash CLI — command-line deployment and automation\nAkash SDK — build deployment tools with Go or JavaScript/TypeScript\n\nReady to Go Beyond Trial?\nAdd Funds: Click your balance → “Add Funds” → pay with credit card to unlock the full network including high-end GPUs.\nWant self-custody? Use Console Air — bring your own Keplr wallet, sign your own transactions, and remove the 24-hour limit.\nPrefer the command line? Use the Akash CLI — self-custody with your Keplr wallet, perfect for automation and CI/CD.\n\nNeed Help?\nWe’re here to help you succeed!\n\nDiscord — fast, friendly community support\nGitHub Issues — bug reports and support\n\nTips for Success\n\nStart with templates — use a featured template for your first deployment\nWatch your credits — monitor your balance at the top of Console\nRemember the 24-hour limit — trial deployments auto-close after 1 day\nCheck logs first — if something doesn’t work, logs usually tell you why\nExplore the marketplace — browse pre-built solutions in Templates section\nTry different apps — experiment with web apps, AI models, and databases\nAdd funds anytime — keep your trial credits when you add more via credit card\n\nEdit page on github\n Console Air Onboarding Core Concepts","tokens":2525,"squid":"spider-03","role":"Compute Spider","at":1791338273373,"hash":"d1512347bc6e4295ca315d3168f9a4d346c34865"}
{"url":"https://docs.arbitrum.io/chain-info","domain":"docs.arbitrum.io","title":"Arbitrum chain information","text":"Arbitrum chain informationChains information ArbitrumRequest an updateArbitrum public RPC endpoints\nWarning\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\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.How is this guide?Machine Payments Protocol (MPP)This quickstart shows you how to implement the Machine Payments Protocol (MPP) on Arbitrum.GlossaryA list of terms and definitions related to Arbitrum.","tokens":3092,"squid":"spider-01","role":"Chain Spider","at":1791338282732,"hash":"ddf449d038176b4f16a24e172d9e7cc93d97cc97"}
{"url":"https://akash.network/docs/getting-started/console-onboarding/","domain":"akash.network","title":"Console Onboarding Guide | Akash Network - Your Guide to Decentralized Cloud","text":"Console Onboarding Guide URL: console.akash.network/onboarding\nStep 1 — Sign Up\nOn the landing page you’ll see a globe showing available compute regions (AP-Northeast, AP-Southeast, US-West, etc.) and a sign-up panel on the right.\nAuthentication options:\n\nContinue with Google\nContinue with GitHub\nEmail — passwordless, a 6-digit OTP is sent to your inbox\n\nNo credit card required to start. You get $1 in free trial credits on sign-up.\n\nStep 2 — Choose Your First Deployment\nAfter confirming your email you land on the onboarding screen with three starter templates:\n\nTemplateStackEst. CostResourcesHello World ⭐Next.js in Docker~$0.25/mo0.5 vCPU · 512MiB RAMSpace AgentAgent Zero (AI agent)~$3.41/mo4 vCPU · 8GiB RAMLLM ChatbotLlama 3.1 8B~$1.50/hr12 vCPU · 1 GPU · 32GiB RAM\n\n⭐ Hello World is recommended for first-time users — it deploys in ~30 seconds.\n\nAlready have a Docker image? Click “Deploy image →” at the bottom to skip templates and go straight to the deployment configurator.\nSkipping the trial: Clicking “Skip the trial – unlock Console →” opens a side panel to add a credit card and unlock the full console.\n\nStep 3 — Configure Your Deployment\nAfter selecting a template or clicking “Deploy image”, you reach the Configure your deployment screen — a 3-column layout:\nColumn 1 — Deployment Settings\n\nName — label for your deployment\nReclamation — how idle resources are reclaimed (default: Any)\nPlacement — select a placement group (default: dcloud) and optionally pin to a region\n\nColumn 2 — Service Configuration\n\nDocker Image — enter your image URI (e.g. ghcr.io/your-org/app:latest). Check Private registry if auth is required.\nPresets — pick a hardware tier: Small (1 vCPU · 2GiB) or unlock high-end GPU tiers\nGPU — toggle on to add a GPU (requires credits beyond the free trial)\nCompute Resources — manually set CPU count, Memory, and Storage\n\nColumn 3 — Compute Marketplace\nThis panel lists all available providers in real time with their region and 7-day uptime. No pricing is shown at this stage — this is the provider discovery view. Providers span NA, EU, and AP regions.\n\nStep 4 — Request Quotes\nOnce your Docker image and resource spec are set, click “Request quotes” (top-right).\nThe Compute Marketplace updates to show live bids from providers willing to host your exact spec. Compare region, uptime, and price before selecting.\n\nBids vary significantly — the same spec can range from ~1.50/moto27/mo depending on provider and region. EU-southeast and Australia/NZ providers tend to offer the lowest prices.\n\nClick “Select” next to your preferred provider to confirm the lease.\nStep 5 — Deployment Starts\nAfter selecting a provider:\n\nThe lease is created on-chain via Akash’s decentralized marketplace\nThe provider pulls your Docker image and starts the container\nA live URL is provisioned — usually within ~30 seconds for standard templates\n\nNote: If you see the banner “Blockchain unavailable — console in read-only mode until service is restored”, the Akash network is temporarily degraded. New deployments cannot be started until restored. Existing deployments are unaffected.\n\nTips\n\nOverclock providers (multiple regions) consistently show 100% uptime and competitive pricing\nAdding more placements in Column 1 broadens the provider pool and gets you more bids\nGPU deployments require adding credits first — trial credits are CPU-only\nFor self-custody/wallet-based deployments, see Console Air\n\nEdit page on github\n Choosing Your Console Console Air Onboarding","tokens":874,"squid":"spider-03","role":"Compute Spider","at":1791338283201,"hash":"9abbfc918d68d4fc7072d9f41f9f1a5640c75848"}
{"url":"https://developers.jup.ag/","domain":"developers.jup.ag","title":"Jupiter Developer Platform","text":"Build your ownonchain superappBest execution · Every primitive · World-class supportSwapYou paytap to edit ✦You receiveJupUSD119.407407Ship nowDocsLive requests— updating1 callsTrusted by Industry Leaders$2T+Volume500+Integrations<300msLatency34xLess MEVThe APIs behind Solana's best productsDeep liquidity, real-time pricing, rich token data, prediction markets, and much more — all through a single platform.SwapExecute token swaps across Solana's deepest liquidity. Intelligent routing finds the best price across every major DEX.View APITokensAccess rich token metadata, verified lists, and real-time market data for every token on Solana.View APIPriceGet reliable token prices powered by Jupiter's aggregation engine, used by top teams in the ecosystem.View APIPrediction MarketsTap into prediction market data and infrastructure to build new classes of trading and information products.View APIExplore all APIsFeaturesWhy Jupiter Developer Platform?A full DeFi infrastructure stack, actionable real-time insights, everything you need to build, all under one roof.Unified Developer ExperienceAPI keys, analytics, logs, and docs in a single dashboard — spend time shipping, not context-switching.Real-Time ObservabilityMonitor request volume, latency percentiles, and error rates the moment they happen with live-updating dashboards.Built for TeamsOrganizations, role-based permissions, and shared API keys — go from solo prototype to production team in minutes.Enterprise-Grade SecurityTwo-factor authentication, granular audit logs, and role-based access control to meet your compliance requirements.Your agents already know JupiterSkills, MCP, and a CLI — no SDK to learn, no wrapper to maintain. Just connect and build.Jupiter AI toolsnpx skills add jup-ag/agent-skillsStart building in seconds.One API key to access every Jupiter endpointUsage insights and request logs from the moment you deployKey-less mode for AgentsGet StartedRead DocsGet Token PricesGet Token InformationEmbed Swap WidgetPrediction MarketsBuilt for how you buildWhether you're a market maker, exchange, wallet, or searcher — Jupiter fits your stack.Traders & Market MakersAccess Jupiter's routing engine for best-price execution across Solana DEXs. Pair with Perps and Prediction Markets for advanced strategies.Crypto ExchangesIntegrate Jupiter Swap to offer your users instant token exchanges with deep Solana liquidity, trusted by the largest exchanges in crypto.SearchersLeverage Jupiter's routing and Price API to find and act on opportunities faster, with real-time token data and optimized swap execution.WalletsEmbed swaps, token prices, and portfolio data directly into your wallet. Jupiter's APIs power the swap experience in Solana's top wallets.Ready to Build?Enterprise-grade DeFi APIs at startup-friendly prices.Start FreeContact Sales","tokens":708,"squid":"spider-02","role":"Liquidity Spider","at":1791338285817,"hash":"d7f0bc0aee29806295fd0a0985509ea3420382aa"}
{"url":"https://docs.arbitrum.io/run-a-node","domain":"docs.arbitrum.io","title":"Arbitrum node runners","text":"Arbitrum node runnersArbitrum node runners documentationRequest an updateArbitrum nodes: an overviewLearn more about what types of Arbitrum nodes are available to run.Nitro support policyLearn the details of the support policy for Nitro.Prepare to run a nodeLearn the prerequisites for running an Arbitrum node on your local machineHow to run a full node for an Arbitrum chainLearn how to run an Arbitrum node on your local machineHow to assign roles to a Nitro nodeUnderstand how a Nitro node's role (RPC node, archive node, sequencer, batch poster, validator — optionally with split validation — or feed relay) is set by configuration flags, and how to convert a node from one role to another.How to run a local full chain simulationThis page provides instructions for setting up a complete local development environment for testing Arbitrum contracts in a fully simulated environment.How to run a local Nitro dev nodeThis page provides instructions for setting up and running a local Nitro dev node for contract testing and development.Ethereum beacon chain RPC providersA reference list of Ethereum beacon chain RPC providers that Arbitrum node operators can use to access blob data after the Dencun upgrade.Data AvailabilityLearn how data availability works in arbitrumHow to run a feed relayLearn how to run an Arbitrum feed relay, and how to architect relays and nodes for reliable feed consumption at fleet scale.Beacon Nodes: Historical BlobsLearn more about the impacts of the Fusaka upgrade when running a beacon node.Arbos releasesMore typesSequencerNitroTroubleshooting: Run a nodeTroubleshoot common issues when running an Arbitrum node, with configuration-specific guidance and a report generator for getting help.Frequently asked questions: Run a nodeList of questions and answers frequently asked by node runnersHow is this guide?OverviewLearn more about what types of Arbitrum nodes are available to run.","tokens":481,"squid":"spider-01","role":"Chain Spider","at":1791338292971,"hash":"e5c13d7ebeab4c91c4055ddb045184f909871710"}
{"url":"https://akash.network/docs/getting-started/what-is-akash/","domain":"akash.network","title":"What is Akash Network? | Akash Network - Your Guide to Decentralized Cloud","text":"What is Akash Network? Akash Network is the world’s first decentralized cloud computing marketplace. A global network of providers compete to provide you with high-performance compute and GPU resources at up to 85% lower cost than traditional cloud providers.\nIn 60 Seconds\nInstead of paying AWS, Google Cloud, or Azure for servers, you can:\n\nDeploy your applications on a global network of independent providers\nSave up to 85% compared to traditional cloud providers (compare pricing)\nGet censorship-resistant infrastructure\nSupport a decentralized internet\n\nIt’s real cloud computing, but open, permissionless, and affordable.\n\nHow It Works\n1. You Deploy\nDefine what resources your app needs in a simple YAML file (CPU, RAM, storage, GPU, and more).\n2. Providers Bid\nIndependent cloud providers around the world compete to host your application by submitting bids.\n3. You Choose\nPick the best offer based on price, location, and provider reputation.\n4. Your App Runs\nYour application runs on the provider’s infrastructure. You pay per block, and can close anytime.\n\nWhy Use Akash?\nLower Costs\nSave up to 85% compared to AWS, Azure, or Google Cloud. No surprise bills. Pay only for what you use, with resources priced at exact sizes (need 1.36GB RAM? Get exactly that, not just 2GB or 4GB tiers).\nCensorship Resistant\nNo single entity can shut down your application. Deploy anywhere, anytime.\nHigh Performance\nAccess to high-end GPUs and compute at fraction of the cost. Perfect for AI/ML workloads.\nFlexible Access\nStart with our trial ($1 free credits, no card required, 30 days) or go permissionless with your own wallet (no KYC; fund deployments with ACT, or with AKT when the circuit breaker is in effect).\nNote: Trial deployments have a 24-hour maximum duration per deployment, but you can redeploy as many times as you want within your 30-day trial period.\nGlobal Network\nProviders in 85+ countries. Deploy close to your users for better performance.\n\nWhat Can You Deploy?\nAnything that runs in a Docker container:\nWeb Applications\n\nStatic websites\nWeb apps (React, Vue, Angular)\nAPIs and microservices\nWordPress, Ghost, custom CMSs\n\nDatabases\n\nPostgreSQL, MySQL, MongoDB\nRedis, Elasticsearch\nReplicated databases\nBackup servers\n\nAI & Machine Learning\n\nModel training\nInference servers\nJupyter notebooks\nLLMs and diffusion models\n\nGame Servers\n\nMinecraft, Valheim, ARK\nPrivate game servers\nTest environments\n\nDevelopment Tools\n\nCI/CD pipelines\nDevelopment environments\nTesting infrastructure\nBuild servers\n\nKey Concepts\nDeployment\nA deployment is your application definition—what resources you need and how your application should run.\nProvider\nA provider is an independent cloud operator offering computing resources on Akash.\nBid\nA bid is an offer from a provider to host your deployment at a specific price.\nLease\nA lease is the active agreement between you and a provider. Once accepted, your deployment runs on their infrastructure.\nSDL\nThe Stack Definition Language (SDL) is a YAML format that describes your deployment—similar to Docker Compose.\nAKT and ACT\nAKT is Akash’s native token used for staking, governance, and gas. ACT is the USD-pegged compute credit used to fund deployments and pay providers; you get ACT by burning AKT or via credit card in Console.\n\nHow Akash is Different\n\nFeatureTraditional CloudAkash - TrialAkash - WalletCostHigh, fixed pricing$1 free creditsUp to 85% cheaper, market-drivenAccessCredit card + KYCEmail sign-up, no card for the trialNo KYC, permissionlessPaymentCredit card monthlyCredit card (funds ACT)Crypto (ACT; or AKT when circuit breaker)SetupComplicatedSign up in 10 minutesInstall wallet, fund with ACT (or AKT when CB)Deployment LimitNone24 hours per deploymentNoneControlVendor lock-inChoose your providerFull blockchain controlCensorshipCan be shut downCensorship-resistantCensorship-resistant\n\nCommon Use Cases\nDevelopers\nDeploy production applications, side projects, and development environments without breaking the bank.\nAI/ML Engineers\nTrain models and run inference on high-end GPUs at a fraction of cloud costs.\nGamers & Content Creators\nHost private game servers for friends without expensive VPS bills.\nWeb3 Projects\nRun decentralized infrastructure—nodes, indexers, APIs—on decentralized cloud.\nStartups\nReduce cloud costs significantly while scaling your application.\n\nIs Akash Right for You?\nPerfect for:\n\nProduction web applications and APIs\nGPU-intensive workloads (AI/ML, inference, training)\nHigh-performance computing workloads\nCost-sensitive production deployments\nCensorship-resistant infrastructure\nContainerized applications\nDecentralized applications (dApps)\nGame servers and private infrastructure\n\nGetting Started\nReady to deploy your first application on Akash? Choose your path:\nManaged (no wallet, pay with credit card)\n\nAkash Console - Visual web interface with managed wallets; start with the Quick Start free trial and get $1 in credits\nConsole API - REST API for programmatic deployments with managed wallets\n\nSelf-Custody (bring your own wallet)\n\nConsole Air - Self-hostable visual interface for Keplr wallet users, no time limits\nAkash CLI - Command-line power for automation and scripting\n\nNot sure which path is right for you? See Choosing Your Console.\nLearn More\n\nCore Concepts - Understand how Akash works\n\nQuestions?\n\nDiscord - Join our community Discord\nDocumentation - Browse the full documentation\nGitHub - Report issues and get support\n\nEdit page on github\n Choosing Your Console","tokens":1372,"squid":"spider-03","role":"Compute Spider","at":1791338293035,"hash":"bc9c5999f7e5927e5f04e187a5b8b9303e4db20e"}
{"url":"https://developers.jup.ag/blog?tag=Changelog","domain":"developers.jup.ag","title":"Changelog | Developer Platform","text":"ChangelogPinnedJupiter Developer Platform ChangelogEverything shipping on the Developer Platform: API keys, plans, firewall, logs, analytics, and teams. Updated as the platform evolves.YY·July 8, 2026YY·August 10, 2026·1 minChangelog: August 2026Self-serve quote verification for DEX integrations with the new jupiter-amm-test-kit.YY·July 21, 2026·5 minChangelog: July 2026Trigger DCA orders with trailing stop loss and Earn While You Wait, Jupiter Forecast BTC markets, and the hosted Trading MCP server for AI agents.YY·June 30, 2026·5 minChangelog: June 2026Jupiter Forecast launches in beta, JupiterZ routes support integrator fees, and the Lend Borrow API goes public.YY and Anmol·May 31, 2026·3 minBreakingChangelog: May 2026Metis V8 ships to close quote-execution drift, the onchain router renames from iris to metis, and Trigger V2 craft-deposit requires order metadata.YY·April 30, 2026·4 minBreakingChangelog: April 2026Prediction Markets breaking changes, public transaction submission, RTSE docs, Express Verification, and the Developer Platform launch.YY·March 31, 2026·3 minChangelog: March 2026Swap API V2 launches, Trigger V2, the Jupiter CLI, and Metis quote updates.YY·February 28, 2026·1 minChangelog: February 2026The Prediction Market API enters beta.YY·January 31, 2026·1 minChangelog: January 2026Ultra manual mode for integrators that need explicit execution control.YY·December 31, 2025·1 minChangelog: December 2025The Portfolio API enters beta.YY·November 30, 2025·3 minBreakingChangelog: November 2025Lite API deprecation plans, the Metis Binary migration, and Swap and Tokens schema changes.YY·October 31, 2025·2 minChangelog: October 2025Ultra V3, four new Jupiter Aggregator V6 instructions, and Token2022 integrator fees.YY·August 31, 2025·1 minBreakingChangelog: August 2025Legacy endpoint sunsets: Quote V6 and the old Tokens and Price hosts.YY·June 30, 2025·1 minBreakingChangelog: June 2025Price API V3 and Tokens API V2 replace their previous versions.YY·March 31, 2025·2 minBreakingChangelog: March 2025API gateway improvements, the lite-api split, and Trigger's new hostname.YY·January 31, 2025·1 minBreakingChangelog: January 2025New API hostnames and API keys via the Portal.","tokens":554,"squid":"spider-02","role":"Liquidity Spider","at":1791338306216,"hash":"4a75f795a41709568767cc5c7637c31ad9d0d633"}
{"url":"https://docs.arbitrum.io/run-a-node/nitro-support-policy","domain":"docs.arbitrum.io","title":"Nitro support policy","text":"Nitro support policyLearn the details of the support policy for Nitro.Request an updateNitro support\nThis policy defines which versions of Nitro the 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 release that is activated on mainnet 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 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\n 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.\nWarningIn 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\nHow is this guide?OverviewLearn more about what types of Arbitrum nodes are available to run.Start hereLearn the prerequisites for running an Arbitrum node on your local machine","tokens":1272,"squid":"spider-01","role":"Chain Spider","at":1791338308969,"hash":"3c712c1d693c9113f9b1aa7edf7b92d965eaa9d5"}
{"url":"https://akash.network/docs/developers/deployment/","domain":"akash.network","title":"Deployment | Akash Network - Your Guide to Decentralized Cloud","text":"Deployment Deploy applications on Akash Network.\nThis section covers everything you need to deploy applications, including Akash Console, Console Air, the Console API, SDKs, CLI tools, SDL configuration, authorization, and deployment guides.\n\nDeployment Methods\nAkash Console\nVisual web interface (managed) - Deploy using the browser-based Console with free trial OR your own wallet. No CLI required.\nConsole Air\nVisual web interface (self-custody) - Self-hostable counterpart to Akash Console. Connect your own Keplr wallet and sign every transaction yourself, with no managed billing or time limits.\nConsole API\nManaged REST API - Deploy programmatically via REST with managed wallets and credit-card billing. No private keys, crypto, or blockchain client required.\nAkash SDK\nProgrammatic deployments - Build applications with Go or JavaScript/TypeScript SDKs.\nakt CLI\nUnified command-line interface - Deploy through local keys or the Console managed wallet, query the chain, operate leases, and monitor the network from one binary.\nAkash CLI\nCommand-line interface - Full control, automation, and CI/CD integration for advanced users.\n\nConfiguration & Permissions\nAkash SDL\nStack Definition Language - Define your deployment configuration, resources, and pricing.\nAuthZ - Delegated Permissions\nTeam collaboration & automation - Grant deployment permissions securely without sharing private keys. \nEdit page on github\n Getting Started Installation","tokens":362,"squid":"spider-03","role":"Compute Spider","at":1791338309019,"hash":"cfec17c5f0ccb6d7b666b27d64148b04d9a21f6a"}
{"url":"https://developers.jup.ag/docs/tool-kits/plugin/customization","domain":"developers.jup.ag","title":"Customizing Plugin - Jupiter Developers","text":"Try out the Plugin Playground to experience the full swap features and see the different customization options with code snippets.For the full customization options, you can refer to the repository.\nIf you are using TypeScript, you can use the type declaration file to get the full type definitions for the Plugin.\nFull TypeScript Declaration declare global {\n interface Window {\n Jupiter: JupiterPlugin;\n }\n}\n\nexport type WidgetPosition = 'bottom-left' | 'bottom-right' | 'top-left' | 'top-right';\nexport type WidgetSize = 'sm' | 'default';\nexport type SwapMode = \"ExactInOrOut\" | \"ExactIn\" | \"ExactOut\";\nexport type DEFAULT_EXPLORER = 'Solana Explorer' | 'Solscan' | 'Solana Beach' | 'SolanaFM';\n\nexport interface FormProps {\n swapMode?: SwapMode;\n initialAmount?: string;\n initialInputMint?: string;\n initialOutputMint?: string;\n fixedAmount?: boolean;\n fixedMint?: string;\n referralAccount?: string;\n referralFee?: number;\n}\n\nexport interface IInit {\n localStoragePrefix?: string;\n formProps?: FormProps;\n defaultExplorer?: DEFAULT_EXPLORER;\n autoConnect?: boolean;\n displayMode?: 'modal' | 'integrated' | 'widget';\n integratedTargetId?: string;\n widgetStyle?: {\n position?: WidgetPosition;\n size?: WidgetSize;\n };\n containerStyles?: CSSProperties;\n containerClassName?: string;\n enableWalletPassthrough?: boolean;\n passthroughWalletContextState?: WalletContextState;\n onRequestConnectWallet?: () => void | Promise<void>;\n onSwapError?: ({\n error,\n quoteResponseMeta,\n }: {\n error?: TransactionError;\n quoteResponseMeta: QuoteResponse | null;\n }) => void;\n onSuccess?: ({\n txid,\n swapResult,\n quoteResponseMeta,\n }: {\n txid: string;\n swapResult: SwapResult;\n quoteResponseMeta: QuoteResponse | null;\n }) => void;\n onFormUpdate?: (form: IForm) => void;\n onScreenUpdate?: (screen: IScreen) => void;\n}\n\nexport interface JupiterPlugin {\n _instance: JSX.Element | null;\n init: (props: IInit) => void;\n resume: () => void;\n close: () => void;\n root: Root | null;\n enableWalletPassthrough: boolean;\n onRequestConnectWallet: IInit['onRequestConnectWallet'];\n store: ReturnType<typeof createStore>;\n syncProps: (props: { passthroughWalletContextState?: IInit['passthroughWalletContextState'] }) => void;\n onSwapError: IInit['onSwapError'];\n onSuccess: IInit['onSuccess'];\n onFormUpdate: IInit['onFormUpdate'];\n onScreenUpdate: IInit['onScreenUpdate'];\n localStoragePrefix: string;\n}\n\nexport { };\n\n​Display Modes\nJupiter Plugin offers three distinct display modes to suit different use cases:\n​1. Integrated Mode\nThe integrated mode embeds the swap form directly into your application’s layout. This is ideal for creating a seamless swap experience within your dApp.\n{\n displayMode: \"integrated\";\n integratedTargetId: string; // Required: ID of the container element\n containerStyles?: {\n width?: string;\n height?: string;\n borderRadius?: string;\n overflow?: string;\n };\n containerClassName?: string;\n}\n\n​2. Widget Mode\nThe widget mode creates a floating swap form that can be positioned in different corners of the screen. Perfect for quick access to swaps without taking up too much space.\n{\n displayMode: \"widget\";\n widgetStyle?: {\n position?: \"top-left\" | \"top-right\" | \"bottom-left\" | \"bottom-right\";\n size?: \"sm\" | \"default\";\n };\n}\n\n​3. Modal Mode\nThe modal mode displays the swap form in a popup overlay. This is useful when you want to keep the swap form hidden until needed.\n{\n displayMode: \"modal\";\n}\n\n​Form Props Configuration\nThe formProps object allows you to customize the initial state and behavior of the swap form! This can be useful for use cases like fixed token swaps for memecoin communities or fixed amount payments.\n{\n displayMode: \"modal\";\n formProps?: {\n swapMode?: SwapMode; // Set the swap mode to \"ExactIn\", \"ExactOut\", or default to \"ExactInOrOut\"\n\n initialAmount?: string; // Pre-fill the swap amount (e.g. \"100\")\n initialInputMint?: string; // Pre-select the input token by its mint address\n initialOutputMint?: string; // Pre-select the output token by its mint address\n\n fixedAmount?: boolean; // When true, users cannot change the swap amount\n fixedMint?: string; // Lock one side of the swap to a specific token by its mint address\n\n referralAccount?: string; // Set the referral account for the swap\n referralFee?: number; // Set the referral fee for the swap\n }\n}\n\n​Wallet Integration\nJupiter Plugin supports third-party wallet integration through the enableWalletPassthrough prop. This allows your application to pass through an existing wallet provider’s connection in your application to Plugin. If you do not have an existing wallet provider, Plugin will provide a wallet adapter and connection - powered by Unified Wallet Kit.\n{\n // When true, wallet connection are handled by your dApp,\n // and use `syncProps()` to syncronise wallet state with Plugin.\n enableWalletPassthrough?: boolean;\n\n // Optional, if wallet state is ready, \n // you can pass it in here, or just use `syncProps()`\n passthroughWalletContextState?: WalletContextState;\n\n // When enableWalletPassthrough is true, this allows Plugin\n // to callback your app's wallet connection flow\n onRequestConnectWallet?: () => void | Promise<void>;\n}\n\n​Event Handling\nJupiter Plugin provides event handlers to track swap operations:\n{\n onSuccess: ({ txid, swapResult, quoteResponseMeta }) => {\n // Handle successful swap\n console.log(\"Swap successful:\", txid);\n };\n onSwapError: ({ error, quoteResponseMeta }) => {\n // Handle swap errors\n console.error(\"Swap failed:\", error);\n }\n}\n\n​Branding\nJupiter Plugin supports branding through the branding prop. This allows you to customize the Plugin’s logo and name to include your own branding.\n{\n branding?: {\n logoUri?: string;\n name?: string;\n };\n}\n\n​Color Theme\nJupiter Plugin supports a simplified way to customize the color theme. This allows you to match the appearance of the Plugin to your brand.\n/* In your global CSS file */\n:root {\n --jupiter-plugin-primary: 199, 242, 132;\n --jupiter-plugin-background: 0, 0, 0;\n --jupiter-plugin-primaryText: 232, 249, 255;\n --jupiter-plugin-warning: 251, 191, 36;\n --jupiter-plugin-interactive: 33, 42, 54;\n --jupiter-plugin-module: 16, 23, 31;\n}\n\n​Examples\n​Fixed SOL Swap\nwindow.Jupiter.init({\n displayMode: \"integrated\";\n integratedTargetId: \"jupiter-plugin\";\n formProps: {\n initialInputMint: \"So11111111111111111111111111111111111111112\"; // SOL\n initialOutputMint: \"EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v\"; // USDC\n fixedMint: \"So11111111111111111111111111111111111111112\";\n };\n});\n\n​Payment Integration\nwindow.Jupiter.init({\n displayMode: \"modal\";\n formProps: {\n swapMode: \"ExactOut\";\n initialAmount: \"10\";\n fixedAmount: true;\n initialOutputMint: \"YOUR_TOKEN_MINT\";\n fixedMint: \"YOUR_TOKEN_MINT\";\n };\n});\n\n​Floating Widget\nwindow.Jupiter.init({\n displayMode: \"widget\";\n widgetStyle: {\n position: \"bottom-right\";\n size: \"sm\";\n };\n});\nWas this page helpful?","tokens":1713,"squid":"spider-02","role":"Liquidity Spider","at":1791338316114,"hash":"b0ba47ab0a05de72170bf6acbadfc06ee9ba8c20"}
{"url":"https://docs.arbitrum.io/launch-arbitrum-chain","domain":"docs.arbitrum.io","title":"Launch Arbitrum chain","text":"Launch Arbitrum chainLaunch and operate your own Arbitrum chain — configure, deploy, maintain, and customize.Request an updateLaunch and operate your own Arbitrum chain. Configure execution, gas tokens, data availability, governance, and validation for your product's requirements.\nOverviewWhat is an Arbitrum chain? Why/can I create my own? What benefits are there for my use case and my users?.QuickstartCreate an L3 chain with default settings and custom infrastructure.ConfigurationsCheck out all the configuration options for Arbitrum chains.DeploymentLearn about the deployment options for your chain.Extend the protocolExtend the functionality of your chain with advanced configuration options. Requires expertise.IntegrationsIntegrate bridges, signing services, and infrastructure providers to your chain.MigrateMoving from another stack? This is for you.OperateTroubleshooting, monitoring, and chain operations.Run a nodeSpecific node running features for running a chain.How is this guide?How to set up a high-availability sequencerLearn how to set up a high-availability sequencer for your Arbitrum chain.","tokens":279,"squid":"spider-01","role":"Chain Spider","at":1791338318787,"hash":"5844610ad5826cee58e9ea80cddcb34e89bed2c8"}
{"url":"https://www.paradigm.xyz/writing","domain":"paradigm.xyz","title":"Writing | Paradigm","text":"Featured All Writing 2026-09-30 The Game Theory of AI Pacing 2026-07-08 Announcing Our Fourth Fund 2026-08-11 RSI Simulator 2025-09-04 Tempo: The Blockchain Designed for Payments 2026-02-18 Introducing EVMbench 2026-09-30 The Game Theory of AI Pacing 2026-07-08 Announcing Our Fourth Fund 2026-08-11 RSI Simulator 2025-09-04 Tempo: The Blockchain Designed for Payments 2026-02-18 Introducing EVMbench 2026-09-30 The Game Theory of AI Pacing 2026-08-31 GPU World 2026-08-11 RSI Simulator Centaur 2.0 2026-08-10 Centaur 2.0: Permissions, Context, and MCP 2026-07-24 Formally Verifying a Compiler Using Automated Research 2026-06-12 Project Kryptos Centaur 2026-05-21 Open Sourcing Centaur: Multiplayer, self-hosted, secure agents 2026-05-01 PACTs: Protecting Your Bitcoin From a Quantum Sunset 2026-02-04 Introducing Paradigm Predictions 2025-12-08 Polymarket Volume Is Being Double-Counted 2025-08-18 Opportunity Markets 2025-06-12 Quantum Markets 2025-06-02 Orbital 2025-05-12 Multiverse Finance 2025-05-06 Across Prime 2025-05-02 Timing Advantages in Onchain Auctions 2025-03-31 Demystifying the North Korean Threat Pectra Hard Fork 2025-02-19 What comes after Ethereum’s Pectra hard fork? Ethereum Acceleration 2025-01-25 Ethereum Acceleration 2024-12-10 Distribution Markets 2024-11-21 The 5 Levels of Secure Hardware 2024-11-05 pm-AMM: A Uniform AMM for Prediction Markets 2024-10-10 Unichain 2024-10-08 How to Remove the Relay 2024-06-20 Releasing Revmc 2024-06-11 From Staking to Restaking 2024-06-04 Priority Is All You Need 2024-05-07 How to Raise the Gas Limit, Part 2: History Growth Frame Interface Guidelines 2024-05-02 Fig: Frame Interface Guidelines 2024-03-06 Everything Is A Perp 2024-03-05 Joining Paradigm as Research Advisor 2024-03-04 How to Raise the Gas Limit, Part 1: State Growth 2024-02-13 Leaderless Auctions Cancun Hard Fork 2024-01-17 What comes after Ethereum's Cancun hard fork? 2023-09-20 The Casino on Mars 2023-08-14 The Open Problems of Onchain Games 2023-07-25 Collaborate with Paradigm 2023-06-01 Intent-Based Architecture and Their Risks 2023-05-01 Blend: Perpetual Lending With NFT Collateral Proof-of-Stake 2023-04-27 Time, slots, and the ordering of events in Ethereum Proof-of-Stake SNARKs 2023-01-12 Generating secure randomness on Ethereum using SNARKs 2022-09-20 Open Sourcing the Art Gobblers Smart Contracts 2022-09-13 Art Gobblers 2022-09-09 Goldfish: A Provably Secure Replacement for LMD GHOST in PoS Ethereum 2022-09-06 GOO (Gradual Ownership Optimization) 2022-08-25 Data Availability Sampling: From Basics to Open Problems 2022-08-24 Variable Rate GDAs 2022-07-29 Cosmos without Tendermint: Exploring Narwhal and Bullshark 2022-07-11 Understanding Blockchain Latency and Throughput Uniswap v3 Liquidity 2022-05-05 The Dominance of Uniswap v3 Liquidity 2022-04-13 Hardware Acceleration for Zero Knowledge Proofs 2022-04-04 Gradual Dutch Auctions 2022-01-25 Constant Rate Issuance Sales Protocol 2021-11-11 Hiding in Plain Sight 2021-10-13 A Guide to Designing Effective NFT Launches 2021-10-06 RICKS 2021-09-14 Martingale Shares 2021-08-31 Floor Perps 2021-08-17 Two Rights Might Make A Wrong 2021-08-17 Power Perpetuals 2021-08-13 The Dangers of Surprising Code 2021-07-28 TWAMM The Merge 2021-07-20 Ethereum Reorgs After The Merge The Universal AMM 2021-06-07 Uniswap v3: The Universal AMM Booby Trapping 2021-05-27 Booby Trapping the Ethereum Blockchain Liquidity Mining 2021-05-18 Liquidity Mining on Uniswap v3 2021-05-11 Everlasting Options 2021-04-23 On Staking Pools and Staking Derivatives 2021-04-19 Uncovering a Four Year Old Bug 2021-04-19 Understanding Automated Market-Makers, Part 1: Price Impact 2021-04-09 Paradigm CTF 2021 - swap 2021-04-08 A Cosmos Thesis 2021-03-30 The Block Mined In January, 584942419325 Ethereum Blockspace 2021-03-25 Ethereum Blockspace - Who Gets What and Why 2021-03-08 The Cartoon Guide to Perps EIP-1559 2021-02-26 Establishing Bounds for Miner Revenue in EIP-1559 EIP-1559 2021-02-22 Miners will accept EIP-1559, here is why 2021-02-05 MEV and me Optimism's Rollup 2021-01-29 How does Optimism's Rollup really work? Optimistic Rollup 2021-01-27 (Almost) Everything you need to know about Optimistic Rollup 2020-12-20 Paradigm's Open Problems: A Series Financial Alchemy 2020-12-01 Uniswap's Financial Alchemy 2020-11-09 So you want to use a price oracle 2020-10-28 Governance Minimization 2020-09-24 Escaping the Dark Forest 2020-08-28 Ethereum is a Dark Forest EIP-2593 2020-06-24 Analysis of EIP-2593 (Escalator) EIP-1559 2020-06-10 Analysis of EIP-1559 The Yield Protocol 2020-04-01 The Yield Protocol: On-Chain Lending With Interest Rate Discovery Uniswap Markets 2019-11-01 An analysis of Uniswap markets The Rainbow Network 2019-03-01 The Rainbow Network: An Off-Chain Decentralized Synthetics Exchange Recent Announcements Research Build Policy Stories List/Grid List/Grid","tokens":1219,"squid":"spider-04","role":"Research Spider","at":1791338330795,"hash":"e06cb26fdb9387bec7bf04c190e6306c33033b6a"}
{"url":"https://consensys.github.io/smart-contract-best-practices/","domain":"consensys.github.io","title":"Ethereum Smart Contract Best Practices","text":"Ethereum Smart Contract Security Best Practices¶\n\nTip\nThank you for visiting the Smart Contract Security Best Practices. Please note that this resource is no longer actively maintained. Instead, we recommend visiting the Smart Contract Security Field Guide. The Smart Contract Security Field Guide is regularly updated and curated by the same security engineer who previously contributed to the Best Practices guide.\n\nThis document provides a baseline knowledge of security considerations for intermediate Solidity\nprogrammers. It is maintained by ConsenSys Diligence, with\ncontributions from our friends in the broader Ethereum community.\nOur amazing community has also provided translations in\nChinese and\nVietnamese.\nWhere to start?¶\n\nGeneral Philosophy describes the smart contract security mindset\nDevelopment Recommendations contains examples of good code patterns\nKnown Attacks describes the different classes of vulnerabilities to avoid\nSecurity Tools lists tools for improving code quality, and detecting\n vulnerabilities\nBug Bounties List of bug bounties in the ecosystem.\n\nContributions are welcome!¶\nFeel free to submit a pull request, with anything from small fixes, to full new sections. If you\nare writing new content, please reference the contributing page for\nguidance on style.\nSee the issues for topics that\nneed to be covered or updated.","tokens":339,"squid":"spider-06","role":"Security Spider","at":1791338335730,"hash":"bf7a5e8d5cf1b1ca68bdd144f563e7fa3096eb02"}
{"url":"https://consensysdiligence.github.io/smart-contract-best-practices/bug-bounty-programs/","domain":"consensysdiligence.github.io","title":"Bug Bounty Programs - Ethereum Smart Contract Best Practices","text":"Bug Bounty Programs\n\nTip\nLooking for comprehensive information on setting up, managing, and operating a bug bounty program? Please refer to the Smart Contract Security Field Guide's bug bounty guide. This resource provides in-depth, up-to-date knowledge and strategies that are paramount for running a successful bug bounty program.\n\nOver the course of time Ethereum security has evolved to include different flavours of bug bounty programs which will be detailed below:\nBug Bounty Platforms¶\nThe first category are bug bounty platforms wherein a development team submits their project to a platform that either manages the programme for them or simply lists their project for exposure and reach toward interested security researchers. These platforms are further divided by type. The first are web3 native platforms hosting the majority of smart contract and frontend bug bounty programmes you'll find and the second are traditional platforms hosting majorly programmes with the frontend of centralized exchanges in scope. Finally, there are bounty collaboration platforms where developers are paid to code and implement new features or smart contracts.\nWeb3 native platforms:\n\nImmunefi\nHackenProof\n\nTraditional platforms:\n\nHackerOne\nBugcrowd\n\nBounty collaboration platforms:\n\nGitcoin\n\nCrowd-sourced Security Solutions¶\nIn response to the high demand and low supply for professional smart contract security review firms, a few crowd sourced solutions have emerged to solve the issue. They all employ a bug bounty-esque model hence inclusion on this list. They call them \"audit contests\" with freelance security researchers scrambling to find and report vulnerabilities within a set time period i.e two weeks with payouts only being issued for successful findings. Examples are listed below:\n\nCode4rena\n\nProject Managed Bounties¶\nThe final category for now consists of bug bounty programmes that are directly managed by the project team itself and are often focused on smart contracts in their scope whether that's contributing to their features or breaking them.\nIssues and PRs are welcome to add new bounties, or remove those which are no longer\nactive.\n\nAirswap\nEthereum Foundation: Has a large scope, including\n clients, Solidity and Vyper, and more.\nEtherscan.io\nImmutableSoft\n0xProject\nParity: Includes client and contract code","tokens":583,"squid":"spider-06","role":"Security Spider","at":1791338362312,"hash":"d7f9dfb5f9eb11456d1cf575e0ea9766115cd061"}
{"url":"https://consensysdiligence.github.io/smart-contract-best-practices/general-philosophy/","domain":"consensysdiligence.github.io","title":"Index - Ethereum Smart Contract Best Practices","text":"Index\n\nTip\nFor comprehensive insights into secure development practices, consider visiting the Development Recommendations section of the Smart Contract Security Field Guide. This resource provides in-depth articles to guide you in developing robust and secure smart contracts.\n\nEthereum and complex blockchain programs are new and highly experimental. Therefore, you should\nexpect constant changes in the security landscape, as new bugs and security risks are discovered,\nand new best practices are developed. Following the security practices in this document is\ntherefore only the beginning of the security work you will need to do as a smart contract\ndeveloper.\nSmart contract programming requires a different engineering mindset than you may be used to. The\ncost of failure can be high, and change can be difficult, making it in some ways more similar to\nhardware programming or financial services programming than web or mobile development. It is\ntherefore not enough to defend against known vulnerabilities. Instead, you will need to learn a new\nphilosophy of development:","tokens":270,"squid":"spider-06","role":"Security Spider","at":1791338372080,"hash":"7b0437353d1d3c728124bcdb8a034a0165aa374c"}
{"url":"https://eips.ethereum.org/EIPS/eip-190","domain":"eips.ethereum.org","title":"ERC-190: Ethereum Smart Contract Packaging Standard","text":"🎉 Final\n\n Standards Track: ERC\n\n ERC-190: Ethereum Smart Contract Packaging Standard\n\n Authors\n Piper Merriam (@pipermerriam), Tim Coulter (@tcoulter), Denis Erfurt (@mhhf), RJ Catalano (@VoR0220), Iuri Matias (@iurimatias)\n\n Created\n 2017-01-10\n\n Abstract\n\nThis ERC proposes a specification for Ethereum smart contract packages.\n\nThe specification was collaboratively developed by the following Ethereum development framework maintainers.\n\n Tim Coulter (Truffle)\n Denis Erfurt (Dapple)\n Piper Merriam (Populus)\n RJ Catalano (Eris PM)\n Iuri Matias (Embark)\n\n Motivation\n\nPackaging is a core piece of modern software development which is missing from the Ethereum ecosystem. The lack of packaging limits the ability for developers to reuse code which negatively affects productivity and security.\n\nA key example of this is the ERC20 standard. There are a few well audited reusable token contracts available but most developers end up writing their own because of the difficulty in finding and reusing existing code.\n\nA packaging standard should have the following positive effects on the ecosystem:\n\n Greater overall productivity caused by the ability to reuse existing code.\n Increased security caused by the ability to reuse existing well audited implementations of common patterns (ERC20, crowdfunding, etc).\n\nSmart contract packaging should also have a direct positive effect on the end user. Wallet software will be able to consume a released package and generate an interface for interacting with any deployed contracts included within that package. With the advent of ENS all of the pieces will be in place for a wallet to take a human readable name and present the user with an interface for interacting with the underlying application.\n\n Specification\n\nThe full specification for this standard is maintained separately in the repository epm/epm-spec.\n\nThis EIP refers to the 1.0.0 version of the specification: https://github.com/ethpm/epm-spec/tree/v1.0.0\n\nThe specification contains details for a single document referred to as a “Release Lockfile”.\n\n Release Lockfile Specification: https://github.com/ethpm/epm-spec/blob/v1.0.0/release-lockfile.spec.md.\n JSON Schema for Release Lockfile: https://github.com/ethpm/epm-spec/blob/v1.0.0/spec/release-lockfile.spec.json\n\n These documents have not been inlined into this ERC to ensure that there is a single source of truth for the specification.\n\n Use Cases\n\nThis specification covers the following types of smart contract packages.\n\n Packages with contracts intended to be used as base contract such as the common owned pattern.\n Packages with contracts that are ready to use as-is such as an ERC20 token contract.\n Packages with deployed contracts such as libraries or services.\n\nFull explanations and examples of these use cases can be found in the README.md from the epm/epm-spec repository.\n\n Package Managers\n\nThe Release Lockfile is intended for consumption by package management software. Specific care was made to ensure that all of the following functionality can be implemented by package managers.\n\n Deterministic builds\n\nEnsures that a package will always resolve to the same set of dependencies and source files. Both source files and dependencies are content addressed to ensure that the referenced resources cannot change.\n\n Bytecode verification\n\nContains the appropriate information for a package manager to inspect a deployed contract and verify that its bytecode matches the bytecode that results from compilation and linking of the package source code.\n\n Multi-chain deploys\n\nSupports deployments across multiple chains, allowing a package to define addresses on both the public mainnet and testnet.\n\n Trusted packages\n\nAllows for packages which exclude source code or other elements which would be needed for verification of the contract bytecode. This allows for minimalistic packages to be created for special situations where the package manager will not be performing verification.\n\n Framework support and integration\n\nSupport for ERC190 is either implemented or in progress for the following:\n\n Truffle\n Populus\n Dapple\n Eris PM\n Embark\n Browser Solidity\n\n Citation\n Please cite this document as:\n\n Piper Merriam (@pipermerriam), Tim Coulter (@tcoulter), Denis Erfurt (@mhhf), RJ Catalano (@VoR0220), Iuri Matias (@iurimatias), \"ERC-190: Ethereum Smart Contract Packaging Standard,\" Ethereum Improvement Proposals, no. 190, January 2017. Available: https://eips.ethereum.org/EIPS/eip-190.","tokens":1119,"squid":"spider-05","role":"Spec Spider","at":1791338379291,"hash":"84fced79ac2606862f0378f6bfeb8442c873f2e4"}
{"url":"https://consensysdiligence.github.io/smart-contract-best-practices/security-tools/","domain":"consensysdiligence.github.io","title":"Index - Ethereum Smart Contract Best Practices","text":"Index\n\nThis section is about tools that can detect vulnerabilities or help developers maintain a high\ncode quality to reduce the likelihood and impact of vulnerabilities.\n\nCategory\nDescription\n\nVisualization\nThese tools are aimed at visualizing, EVM bytecode, smart contracts, and their control flow graphs.\n\nStatic and Dynamic Analysis\nTools that employ various means of program analysis to find vulnabilities and weaknesses.\n\nClassification\nResources attempting to classify vulnerabilities and weaknesses in smart contracts.\n\nTesting\nTools for running, measuring, and managing smart contract related tests.\n\nLinters and Formatters\nAny tools that highlight code smells and make smart contract code adhere to format standards.\n\nDisassemblers and Decompilers\nTools that translate smart contract bytecode into opcodes and solidity code.\n\nFormal and Runtime Verification\nTools employing verification techniques to detect behaviour satisfying or vioating invariants.\n\n The Diligence Security Tooling Guide\n Download a free copy of the Diligence Security Tooling Guide to discover the top tools in Web3 you can use at any phase of your smart contract development to test and improve security.\n\n Download guide","tokens":301,"squid":"spider-06","role":"Security Spider","at":1791338381409,"hash":"6ad81d196aadd536f0bc17be244e1a41d088cf7c"}
{"url":"https://eips.ethereum.org/EIPS/eip-137","domain":"eips.ethereum.org","title":"ERC-137: Ethereum Domain Name Service - Specification","text":"🎉 Final\n\n Standards Track: ERC\n\n ERC-137: Ethereum Domain Name Service - Specification\n\n Authors\n Nick Johnson <arachnid@notdot.net>\n\n Created\n 2016-04-04\n\n Abstract\n\nThis draft EIP describes the details of the Ethereum Name Service, a proposed protocol and ABI definition that provides flexible resolution of short, human-readable names to service and resource identifiers. This permits users and developers to refer to human-readable and easy to remember names, and permits those names to be updated as necessary when the underlying resource (contract, content-addressed data, etc) changes.\n\nThe goal of domain names is to provide stable, human-readable identifiers that can be used to specify network resources. In this way, users can enter a memorable string, such as ‘vitalik.wallet’ or ‘www.mysite.swarm’, and be directed to the appropriate resource. The mapping between names and resources may change over time, so a user may change wallets, a website may change hosts, or a swarm document may be updated to a new version, without the domain name changing. Further, a domain need not specify a single resource; different record types allow the same domain to reference different resources. For instance, a browser may resolve ‘mysite.swarm’ to the IP address of its server by fetching its A (address) record, while a mail client may resolve the same address to a mail server by fetching its MX (mail exchanger) record.\n\n Motivation\n\nExisting specifications and implementations for name resolution in Ethereum provide basic functionality, but suffer several shortcomings that will significantly limit their long-term usefulness:\n\n A single global namespace for all names with a single ‘centralised’ resolver.\n Limited or no support for delegation and sub-names/sub-domains.\n Only one record type, and no support for associating multiple copies of a record with a domain.\n Due to a single global implementation, no support for multiple different name allocation systems.\n Conflation of responsibilities: Name resolution, registration, and whois information.\n\nUse-cases that these features would permit include:\n\n Support for subnames/sub-domains - eg, live.mysite.tld and forum.mysite.tld.\n Multiple services under a single name, such as a DApp hosted in Swarm, a Whisper address, and a mail server.\n Support for DNS record types, allowing blockchain hosting of ‘legacy’ names. This would permit an Ethereum client such as Mist to resolve the address of a traditional website, or the mail server for an email address, from a blockchain name.\n DNS gateways, exposing ENS domains via the Domain Name Service, providing easier means for legacy clients to resolve and connect to blockchain services.\n\nThe first two use-cases, in particular, can be observed everywhere on the present-day internet under DNS, and we believe them to be fundamental features of a name service that will continue to be useful as the Ethereum platform develops and matures.\n\nThe normative parts of this document does not specify an implementation of the proposed system; its purpose is to document a protocol that different resolver implementations can adhere to in order to facilitate consistent name resolution. An appendix provides sample implementations of resolver contracts and libraries, which should be treated as illustrative examples only.\n\nLikewise, this document does not attempt to specify how domains should be registered or updated, or how systems can find the owner responsible for a given domain. Registration is the responsibility of registrars, and is a governance matter that will necessarily vary between top-level domains.\n\nUpdating of domain records can also be handled separately from resolution. Some systems, such as swarm, may require a well defined interface for updating domains, in which event we anticipate the development of a standard for this.\n\n Specification\n\n Overview\n\nThe ENS system comprises three main parts:\n\n The ENS registry\n Resolvers\n Registrars\n\nThe registry is a single contract that provides a mapping from any registered name to the resolver responsible for it, and permits the owner of a name to set the resolver address, and to create subdomains, potentially with different owners to the parent domain.\n\nResolvers are responsible for performing resource lookups for a name - for instance, returning a contract address, a content hash, or IP address(es) as appropriate. The resolver specification, defined here and extended in other EIPs, defines what methods a resolver may implement to support resolving different types of records.\n\nRegistrars are responsible for allocating domain names to users of the system, and are the only entities capable of updating the ENS; the owner of a node in the ENS registry is its registrar. Registrars may be contracts or externally owned accounts, though it is expected that the root and top-level registrars, at a minimum, will be implemented as contracts.\n\nResolving a name in ENS is a two-step process. First, the ENS registry is called with the name to resolve, after hashing it using the procedure described below. If the record exists, the registry returns the address of its resolver. Then, the resolver is called, using the method appropriate to the resource being requested. The resolver then returns the desired result.\n\nFor example, suppose you wish to find the address of the token contract associated with ‘beercoin.eth’. First, get the resolver:\n\nvar node = namehash(\"beercoin.eth\");\nvar resolver = ens.resolver(node);\n\nThen, ask the resolver for the address for the contract:\n\nvar address = resolver.addr(node);\n\nBecause the namehash procedure depends only on the name itself, this can be precomputed and inserted into a contract, removing the need for string manipulation, and permitting O(1) lookup of ENS records regardless of the number of components in the raw name.\n\n Name Syntax\n\nENS names must conform to the following syntax:\n\n<domain> ::= <label> | <domain> \".\" <label>\n<label> ::= any valid string label per [UTS46](https://unicode.org/reports/tr46/)\n\nIn short, names consist of a series of dot-separated labels. Each label must be a valid normalised label as described in UTS46 with the options transitional=false and useSTD3AsciiRules=true. For Javascript implementations, a library is available that normalises and checks names.\n\nNote that while upper and lower case letters are allowed in names, the UTS46 normalisation process case-folds labels before hashing them, so two names with different case but identical spelling will produce the same namehash.\n\nLabels and domains may be of any length, but for compatibility with legacy DNS, it is recommended that labels be restricted to no more than 64 characters each, and complete ENS names to no more than 255 characters. For the same reason, it is recommended that labels do not start or end with hyphens, or start with digits.\n\n namehash algorithm\n\nBefore being used in ENS, names are hashed using the ‘namehash’ algorithm. This algorithm recursively hashes components of the name, producing a unique, fixed-length string for any valid input domain. The output of namehash is referred to as a ‘node’.\n\nPseudocode for the namehash algorithm is as follows:\n\ndef namehash(name):\n if name == '':\n return '\\0' * 32\n else:\n label, _, remainder = name.partition('.')\n return sha3(namehash(remainder) + sha3(label))\n\nInformally, the name is split into labels, each label is hashed. Then, starting with the last component, the previous output is concatenated with the label hash and hashed again. The first component is concatenated with 32 ‘0’ bytes. Thus, ‘mysite.swarm’ is processed as follows:\n\nnode = '\\0' * 32\nnode = sha3(node + sha3('swarm'))\nnode = sha3(node + sha3('mysite'))\n\nImplementations should conform to the following test vectors for namehash:\n\nnamehash('') = 0x0000000000000000000000000000000000000000000000000000000000000000\nnamehash('eth') = 0x93cdeb708b7545dc668eb9280176169d1c33cfd8ed6f04690a0bcc88a93fc4ae\nnamehash('foo.eth') = 0xde9b09fd7c5f901e23a3f19fecc54828e9c848539801e86591bd9801b019f84f\n\n Registry specification\n\nThe ENS registry contract exposes the following functions:\n\nfunction owner(bytes32 node) constant returns (address);\n\nReturns the owner (registrar) of the specified node.\n\nfunction resolver(bytes32 node) constant returns (address);\n\nReturns the resolver for the specified node.\n\nfunction ttl(bytes32 node) constant returns (uint64);\n\nReturns the time-to-live (TTL) of the node; that is, the maximum duration for which a node’s information may be cached.\n\nfunction setOwner(bytes32 node, address owner);\n\nTransfers ownership of a node to another registrar. This function may only be called by the current owner of node. A successful call to this function logs the event Transfer(bytes32 indexed, address).\n\nfunction setSubnodeOwner(bytes32 node, bytes32 label, address owner);\n\nCreates a new node, sha3(node, label) and sets its owner to owner, or updates the node with a new owner if it already exists. This function may only be called by the current owner of node. A successful call to this function logs the event NewOwner(bytes32 indexed, bytes32 indexed, address).\n\nfunction setResolver(bytes32 node, address resolver);\n\nSets the resolver address for node. This function may only be called by the owner of node. A successful call to this function logs the event NewResolver(bytes32 indexed, address).\n\nfunction setTTL(bytes32 node, uint64 ttl);\n\nSets the TTL for a node. A node’s TTL applies to the ‘owner’ and ‘resolver’ records in the registry, as well as to any information returned by the associated resolver.\n\n Resolver specification\n\nResolvers may implement any subset of the record types specified here. Where a record types specification requires a resolver to provide multiple functions, the resolver MUST implement either all or none of them. Resolvers MUST specify a fallback function that throws.\n\nResolvers have one mandatory function:\n\nfunction supportsInterface(bytes4 interfaceID) constant returns (bool)\n\nThe supportsInterface function is documented in EIP-165, and returns true if the resolver implements the interface specified by the provided 4 byte identifier. An interface identifier consists of the XOR of the function signature hashes of the functions provided by that interface; in the degenerate case of single-function interfaces, it is simply equal to the signature hash of that function. If a resolver returns true for supportsInterface(), it must implement the functions specified in that interface.\n\nsupportsInterface must always return true for 0x01ffc9a7, which is the interface ID of supportsInterface itself.\n\nCurrently standardised resolver interfaces are specified in the table below.\n\nThe following interfaces are defined:\n\n Interface name\n Interface hash\n Specification\n\n addr\n 0x3b3b57de\n Contract address\n\n name\n 0x691f3431\n #181\n\n ABI\n 0x2203ab56\n #205\n\n pubkey\n 0xc8690233\n #619\n\nEIPs may define new interfaces to be added to this registry.\n\n Contract Address Interface\n\nResolvers wishing to support contract address resources must provide the following function:\n\nfunction addr(bytes32 node) constant returns (address);\n\nIf the resolver supports addr lookups but the requested node does not have an addr record, the resolver MUST return the zero address.\n\nClients resolving the addr record MUST check for a zero return value, and treat this in the same manner as a name that does not have a resolver specified - that is, refuse to send funds to or interact with the address. Failure to do this can result in users accidentally sending funds to the 0 address.\n\nChanges to an address MUST trigger the following event:\n\nevent AddrChanged(bytes32 indexed node, address a);\n\n Appendix A: Registry Implementation\n\ncontract ENS {\n struct Record {\n address owner;\n address resolver;\n uint64 ttl;\n }\n\n mapping(bytes32=>Record) records;\n\n event NewOwner(bytes32 indexed node, bytes32 indexed label, address owner);\n event Transfer(bytes32 indexed node, address owner);\n event NewResolver(bytes32 indexed node, address resolver);\n\n modifier only_owner(bytes32 node) {\n if(records[node].owner != msg.sender) throw;\n _\n }\n\n function ENS(address owner) {\n records[0].owner = owner;\n }\n\n function owner(bytes32 node) constant returns (address) {\n return records[node].owner;\n }\n\n function resolver(bytes32 node) constant returns (address) {\n return records[node].resolver;\n }\n\n function ttl(bytes32 node) constant returns (uint64) {\n return records[node].ttl;\n }\n\n function setOwner(bytes32 node, address owner) only_owner(node) {\n Transfer(node, owner);\n records[node].owner = owner;\n }\n\n function setSubnodeOwner(bytes32 node, bytes32 label, address owner) only_owner(node) {\n var subnode = sha3(node, label);\n NewOwner(node, label, owner);\n records[subnode].owner = owner;\n }\n\n function setResolver(bytes32 node, address resolver) only_owner(node) {\n NewResolver(node, resolver);\n records[node].resolver = resolver;\n }\n\n function setTTL(bytes32 node, uint64 ttl) only_owner(node) {\n NewTTL(node, ttl);\n records[node].ttl = ttl;\n }\n}\n\n Appendix B: Sample Resolver Implementations\n\n Built-in resolver\n\nThe simplest possible resolver is a contract that acts as its own name resolver by implementing the contract address resource profile:\n\ncontract DoSomethingUseful {\n // Other code\n\n function addr(bytes32 node) constant returns (address) {\n return this;\n }\n\n function supportsInterface(bytes4 interfaceID) constant returns (bool) {\n return interfaceID == 0x3b3b57de || interfaceID == 0x01ffc9a7;\n }\n\n function() {\n throw;\n }\n}\n\nSuch a contract can be inserted directly into the ENS registry, eliminating the need for a separate resolver contract in simple use-cases. However, the requirement to ‘throw’ on unknown function calls may interfere with normal operation of some types of contract.\n\n Standalone resolver\n\nA basic resolver that implements the contract address profile, and allows only its owner to update records:\n\ncontract Resolver {\n event AddrChanged(bytes32 indexed node, address a);\n\n address owner;\n mapping(bytes32=>address) addresses;\n\n modifier only_owner() {\n if(msg.sender != owner) throw;\n _\n }\n\n function Resolver() {\n owner = msg.sender;\n }\n\n function addr(bytes32 node) constant returns(address) {\n return addresses[node]; \n }\n\n function setAddr(bytes32 node, address addr) only_owner {\n addresses[node] = addr;\n AddrChanged(node, addr);\n }\n\n function supportsInterface(bytes4 interfaceID) constant returns (bool) {\n return interfaceID == 0x3b3b57de || interfaceID == 0x01ffc9a7;\n }\n\n function() {\n throw;\n }\n}\n\nAfter deploying this contract, use it by updating the ENS registry to reference this contract for a name, then calling setAddr() with the same node to set the contract address it will resolve to.\n\n Public resolver\n\nSimilar to the resolver above, this contract only supports the contract address profile, but uses the ENS registry to determine who should be allowed to update entries:\n\ncontract PublicResolver {\n event AddrChanged(bytes32 indexed node, address a);\n event ContentChanged(bytes32 indexed node, bytes32 hash);\n\n ENS ens;\n mapping(bytes32=>address) addresses;\n\n modifier only_owner(bytes32 node) {\n if(ens.owner(node) != msg.sender) throw;\n _\n }\n\n function PublicResolver(address ensAddr) {\n ens = ENS(ensAddr);\n }\n\n function addr(bytes32 node) constant returns (address ret) {\n ret = addresses[node];\n }\n\n function setAddr(bytes32 node, address addr) only_owner(node) {\n addresses[node] = addr;\n AddrChanged(node, addr);\n }\n\n function supportsInterface(bytes4 interfaceID) constant returns (bool) {\n return interfaceID == 0x3b3b57de || interfaceID == 0x01ffc9a7;\n }\n\n function() {\n throw;\n }\n}\n\n Appendix C: Sample Registrar Implementation\n\nThis registrar allows users to register names at no cost if they are the first to request them.\n\ncontract FIFSRegistrar {\n ENS ens;\n bytes32 rootNode;\n\n function FIFSRegistrar(address ensAddr, bytes32 node) {\n ens = ENS(ensAddr);\n rootNode = node;\n }\n\n function register(bytes32 subnode, address owner) {\n var node = sha3(rootNode, subnode);\n var currentOwner = ens.owner(node);\n if(currentOwner != 0 && currentOwner != msg.sender)\n throw;\n\n ens.setSubnodeOwner(rootNode, subnode, owner);\n }\n}\n\n Citation\n Please cite this document as:\n\n Nick Johnson <arachnid@notdot.net>, \"ERC-137: Ethereum Domain Name Service - Specification,\" Ethereum Improvement Proposals, no. 137, April 2016. Available: https://eips.ethereum.org/EIPS/eip-137.","tokens":4110,"squid":"spider-05","role":"Spec Spider","at":1791338392595,"hash":"62908af4ca643c730718849527c6c4bea99da7b1"}
{"url":"https://consensysdiligence.github.io/smart-contract-best-practices/about/","domain":"consensysdiligence.github.io","title":"Contributing to the Smart Contract Security Best Practices - Ethereum Smart Contract Best Practices","text":"Contributing to the Smart Contract Security Best Practices¶\nPlease take a moment to review this document to make the contribution\nprocess easy and effective for everyone involved. Following these guidelines\nhelps to communicate that you respect the maintainers' time in managing and\ndeveloping this open-source project. They should reciprocate that\nrespect in addressing your issue or assessing pull requests.\nUsing the Issue Tracker¶\nThe issue tracker is the preferred channel for feature requests and submitting\npull requests. There are some cases where the issue tracker should not be used:\n\nPlease do not use the issue tracker for personal support requests to ask\n the community for help. There are many Discord and Telegram communities\n around Smart Contract development where people will be more than happy to\n help.\nPlease do not derail or troll issues. Keep the discussion on topic and\n respect the opinions of others.\n\nContent-related Issues¶\nSections on attacks and security best practices should include examples and\nfurther reading. Security-related information is bound to change over time,\nhowever. Content-related issues should flag areas that need more explanations\nor contain outdated content.\nA well-written issue flagging areas of the Best Practices that need attention\nare very beneficial - thank you! Some guidelines for content-related issues:\n\nUse the GitHub issue search: Check if the issue has already been\n reported. If the issue is already present, use a thumbs-up reaction to\n help the developers prioritize.\nCheck if the issue has been fixed: Try checking out open pull requests\n and development branches. The problem you are looking to flag might already\n be fixed.\nIsolate the problem: An excellent content-related issue shouldn't leave\n others needing to chase you up for more information. Please try to be as\n detailed as possible. If content needs fixing across multiple areas,\n please flag one issue for each case.\n\nFeature Requests¶\nFeature requests are welcome. But take a moment to find out whether your idea\nfits with the scope and aims of the project. It's up to you to make a solid\ncase to convince the maintainers of the merits of an additional piece of content.\nPlease provide as much detail and context as possible. Keep in mind that the\nBest Practices do not aim to mirror general security considerations that can\nbe found in the project's respective documentation. Additional content to the\nrepository should be original and flag potential pitfalls developers\nmight encounter when building Smart Contract systems.\nPull Requests¶\nReasonable pull requests - patches, improvements, new content - are a fantastic help.\nThey should remain focused in scope and avoid containing unrelated commits.\nPlease ask first before embarking on any significant pull request (e.g.\nadding new content, refactoring example code). Otherwise, you risk spending a\nlot of time working on something that the maintainers might not want to merge\ninto the project. Please adhere to the coding conventions used throughout the\nproject (indentation, comments, etc.). Adhering to the following this process\nis the best way to get your work merged:\n\nFork the repo, clone your fork,\n and configure the remotes:\n # Clone your fork of the repo into the current directory\ngit clone https://github.com/<your-username>/<repo-name>\n# Navigate to the newly cloned directory\ncd <repo-name>\n# Assign the original repo to a remote called \"upstream\"\ngit remote add upstream https://github.com/<upsteam-owner>/<repo-name>\n\nIf you cloned a while ago, get the latest changes from upstream:\n git checkout <dev-branch>\ngit pull upstream <dev-branch>\n\nCreate a new topic branch (off the main project development branch) to\n contain your new content, change, or fix:\n git checkout -b <topic-branch-name>\n\nCommit your changes in logical chunks. Please adhere to these git commit\n message guidelines\n or your code is unlikely to be merged into the main project. Use Git's\n interactive rebase\n feature to tidy up your commits before making them public.\nLocally merge (or rebase) the upstream development branch into your topic branch:\n git pull [--rebase] upstream <dev-branch>\n\nPush your topic branch up to your fork:\n git push origin <topic-branch-name>\n\nOpen a Pull Request\n with a clear title and description.\n\nStyle Guidelines¶\nTo maintain a consistent writing style across the documents, a few\nconsiderations need to be taken.\n\nSuccinctness: Use precise language and don't assume knowledge beyond\n Solidity and Ethereum basics.\nShow, don't tell: Examples speak more than a lengthy exposition.\n Provide code examples where relevant and raise issues or best practices\n in the code around them.\nGive credit: When further reading is recommended or resources are\n available that corroborate security issues, they should contain credit\n and link to the original resource.\nLabel code: Examples containing code must be labeled as insecure or\n secure where relevant. Specifically, in content regarding attacks,\n vulnerable code should be preceded by // INSECURE.","tokens":1263,"squid":"spider-06","role":"Security Spider","at":1791338392662,"hash":"d89f294a1607b8758c5c79f3f41efd79a2a3d999"}
{"url":"https://forum.arbitrum.foundation/latest","domain":"forum.arbitrum.foundation","title":"Latest topics - Arbitrum","text":"The Arbitrum Foundation notified the Security Council on the need to perform a potential Emergency action. Following a review of the details and known risks, the Security Council decided to execute the upgrade and it was completed at 11:30 EST on 2nd October 2026.\nThis report provides an overview of the risks that required the Security Council Action:\n\nAdd a permissionless guard for the One-Step Proof of BoLD on Arbitrum One\n\nTemporarily pause activation of new Stylus contracts on Arbitrum One & Nova\n\nKey point: To date, known bugs for Stylus primarily impact chain liveness (e.g., denial of service attacks) and do not put any user funds at risk.\nWhy was this action taken\nLet’s take this opportunity to explain why action was taken on two separate issues concerning BoLD and Stylus.\nInstalling the guard for One-Step Proof of BoLD. Given the rise of AI-assisted attacks, we have implemented a precautionary approach that allows anyone to pause settlement of Arbitrum One on Ethereum if there are at least two conflicting answers that pass at the same level in which only one should be valid and pass. This is to halt a class of publicly verifiable and detectable attacks that exploit a bug in the one-step proof. If halted, Arbitrum One will continue to process as normal except that messages from Arbitrum One to Ethereum, such as withdrawals, that are not yet confirmed will have to wait. This provides time for the Security Council to deploy a fix for the bug and resume the rollup.\nPreventing activation of new Stylus contracts. AI-assisted tooling has led to an increasing number of sophisticated attacks on hand-crafted WASM programs that do not use the standard Stylus compiler toolchain. These programs are specifically designed to cause unexpected behaviors such as degrading the chain’s performance for all other users. To date, no attacks have been discovered that permits theft of user funds.\nNew ArbOS releases have patched several reported bugs and known attacks over the past few months, but out of an abundance of caution, we have decided to temporarily pause new activations of Stylus contracts. This was executed as an emergency action to prevent the deployment of new hand-crafted WASM programs that are not yet patched by the current version of ArbOS on the Arbitrum network.\nThe Arbitrum Foundation has informed the Security Council that they will work with the ArbitrumDAO to discuss next steps on the timeline and manner for enabling activation of new Stylus contracts. The Arbitrum community remains confident in the value of Stylus and want to preserve these use cases while taking preventative measures against Stylus-based attack vectors as AI-assisted attack tooling continues to evolve.\nImpact on builders and users\n\nNo new activations. New Stylus contracts cannot be activated during the pause including new versions of existing applications that require activation.\n\nExisting contracts are not paused. Already-active Stylus contracts continue to execute until expiration. This pause does not deactivate them.\n\nThe ArbOS 61 upgrade renewed all active contracts on Arbitrum One, so no currently active contract expires before August 20, 2027.\n\nRenewal via keepalive stays permissionless and is unaffected by the pause.\n\nReactivating an expired contract, or one that needs to be updated after a Stylus version change, is paused.\n\nUsing/calling any activated Stylus contract stays permissionless for all users and developers.\n\nNo impact on EVM. Solidity (EVM) contract deployment and execution are unaffected by this Security Council action.\n\nSecurity Council Actions\nThere are two actions bundled into a single payload:\n\nOne-Step Proof Guard. The L1UpgradeExecutor gives a new pause contract (PauseExecutor) the ability to pause and nothing else. The new pause contract grants the guard (OspSoundnessGuard) PAUSER_ROLE to use it. Anyone can show the guard two conflicting answers to the same step of an open challenge. If the one-step proof accepts both, the guard has the pause contract put Arbitrum One’s settlement to Ethereum on hold.\n\nStylus deactivation. The Security Council called ArbOwner.setWasmActivationGas(2^64 - 1) to raise the Stylus activation gas requirement on Arbitrum One and Nova. This makes activation prohibitively expensive and effectively disables new activations. This is a configuration change and does not require an ArbOS upgrade.\n\nThe Security Council signed the following transactions to update the configuration:\n\nEthereum: Ethereum Transaction Hash: 0x30732bb7d2... | Etherscan\nArbitrum One:\nArbitrum One Transaction Hash: 0x9eb3a4be3b... | Arbitrum One\nArbitrum Nova:\nArbitrum Nova transaction 0x79e0fed470dff7a22059b108e3f8f42eddd2b580a6771594060c4e7326c5f984 | Blockscout\n\nAn external audit was conducted for the OSP Guard contracts. No audit is required for the Stylus deactivation as it is only updating a single parameter in the ArbOS configuration.\n\n 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 Welcome to Discourse\n\n General\n\n Welcome to the Forum!\nThis forum is dedicated to discussions and exchange of ideas related to governance. \nPlease read the following guidelines carefully to ensure a productive and respectful community. \nStay on topic: T…\n\n read more\n\n 41\n\n 21.7k\n\n Mar 22\n\n [CONSTITUTIONAL]: Establish an L1 Voting Recovery System \n\n Proposals\n\n proposal\n\n 1\n\n 79\n\n 5h\n\n Adopting USDG as a Core Strategic Initiative for the ArbitrumDAO\n\n Proposals\n\n 1\n\n 81\n\n 11h\n\n DRIP Season 2 Is Live\n\n DeFi Renaissance Incentive Program (DRIP)\n\n 0\n\n 33\n\n 13h\n\n AGDAO x Arbitrum: Meta GameFi Growth Sprint 2026 - Final Report\n\n Domain Allocator Offerings (prev Questbook)\n\n 1\n\n 24\n\n 13h\n\n MoTZ × Arbitrum — Campaign Final Report\n\n Domain Allocator Offerings (prev Questbook)\n\n 3\n\n 27\n\n 13h\n\n October 6, 2026 - Open Discussion of Proposals Governance Call\n\n Biweekly Proposals Discussions Call\n\n 0\n\n 27\n\n 1d\n\n September 22, 2026 - Open Discussion of Proposals Governance Call\n\n Biweekly Proposals Discussions Call\n\n 1\n\n 69\n\n 1d\n\n StableGuard by FintechCheck: Real-Time Stablecoin Depeg Detection for Treasury & DeFi Protection\n\n General\n\n proposal,proposal-discussions\n\n 12\n\n 143\n\n 3d\n\n Security Council Emergency Action – 2/10/2026\n\n Security Council\n\n 0\n\n 275\n\n 4d\n\n From Governance Token to Utility Token: Evolving ARB Beyond Governance\n\n General\n\n 35\n\n 1.3k\n\n 5d\n\n [Final Report] Paros: Automated Treasury Management for Arbitrum\n\n Domain Allocator Offerings (prev Questbook)\n\n 0\n\n 30\n\n 5d\n\n [Final Report] T3tris.finance - Zero-fee, permissionless vault infrastructure\n\n Domain Allocator Offerings (prev Questbook)\n\n 0\n\n 25\n\n 5d\n\n [Constitutional] AIP: Transition Arbitrum One ordering policy to Priority Gas Auctions (PGA)\n\n Finalized AIPs\n\n 30\n\n 2.2k\n\n 5d\n\n Question: How would sequencer decentralization affect Arbitrum users?\n\n Technical Discussion\n\n 3\n\n 75\n\n 5d\n\n [Final Report] Salt : Permissionless MPC Treasury Management\n\n Domain Allocator Offerings (prev Questbook)\n\n 1\n\n 42\n\n 6d\n\n Stylus Manager - Final Report & Grant Completion\n\n Domain Allocator Offerings (prev Questbook)\n\n 2\n\n 39\n\n 6d\n\n Free API with GMX open interest, funding and liquidations next to CEX data.\n\n General\n\n 2\n\n 47\n\n 7d\n\n Rewarding Active Delegates - September 2026 Results\n\n Rewarding Active Delegates Program (RAD)\n\n 0\n\n 62\n\n 7d\n\n Arbitrum Security Program is Live: Applications Now Open\n\n Announcements\n\n 0\n\n 76\n\n 8d\n\n ArbitrumDAO Factsheet: Robinhood Chain Mainnet Launch\n\n Announcements\n\n 5\n\n 970\n\n 10d\n\n What Makes People Stay in an L2 Ecosystem?\n\n General\n\n 2\n\n 46\n\n 10d\n\n ATM Council Updates\n\n Arbitrum Treasury Management Council\n\n 22\n\n 1.4k\n\n 11d\n\n [RFC] Operational Mandate: Arbitrum Stylus Developer Impact Oracle & Sybil-Resistant ROI Matrix\n\n Early Idea Discussion\n\n 6\n\n 115\n\n 12d\n\n Security Council key exposure across three chains — draft for review\n\n Technical Discussion\n\n security-council\n\n 14\n\n 174\n\n 13d\n\n [Constitutional] AIP Fast Feed\n\n Finalized AIPs\n\n 22\n\n 1.0k\n\n 14d\n\n Banning projects identified in the high-severity Watchdog Program cases\n\n Finalized AIPs\n\n 11\n\n 396\n\n 15d\n\n Final report - Arbitrum and GMX Python tooling for onchain trading\n\n Domain Allocator Offerings (prev Questbook)\n\n 3\n\n 65\n\n 15d\n\n How can small ARB holders participate meaningfully in Arbitrum governance?\n\n General\n\n 2\n\n 57\n\n 16d\n\n [Final Report] Building Regenerative Impact with Green Goods\n\n Domain Allocator Offerings (prev Questbook)\n\n 4\n\n 73\n\n 17d","tokens":2129,"squid":"spider-07","role":"Council Spider","at":1791338415448,"hash":"0319de149f9c632b549ab2af7f52fedf6951420e"}
{"url":"https://docs.switchboard.xyz/","domain":"docs.switchboard.xyz","title":"Introduction | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.Switchboard is the fastest, most customizable, and only permissionless way to bring data on-chain.We're the go-to data provider for prominent DeFi projects such as Kamino, Jito, MarginFi, and Drift. We secure billions of dollars of on-chain volume, process hundreds of millions of requests weekly, and deliver real-time information for hundreds of projects and assets across 10+ blockchains.Why use Switchboard? Our protocol is designed around 4 principles:Fastest Oracle UpdatesWith latencies of 2-5ms with Surge, or 400ms with our standard oracles, no one beats Switchboard's speeds. In the fast-paced world of DeFi, faster price updates directly translate to increased security and higher returns.Low CostsWith on-demand feeds, feeds are created and used only when needed. This eliminates constant data streaming and significantly reduces latency and costs.Permissionless and FlexibleDeploy your new data feed, stream from any source on or off-chain, and set the exact parameters that you need. No need to wait for contracts or red tape.Secure and PrivateSwitchboard prevents anyone, including node operators, from altering, exposing or frontrunning your data. Inside Trusted Execution Environments (TEEs), your code and data stay safe and secure.The Switchboard Protocol is open-source and contributions are welcome. Need help using Switchboard? Our support team is available around the clock on Discord.NextQuick StartLast updated 3 months ago","tokens":385,"squid":"spider-08","role":"Oracle Spider","at":1791338417134,"hash":"d2b49eb3e308884470ddb73353dc4cf20dc10ae8"}
{"url":"https://forum.arbitrum.foundation/t/drip-season-2-is-live/31549","domain":"forum.arbitrum.foundation","title":"DRIP Season 2 Is Live - DAO Programs & Initiatives / DeFi Renaissance Incentive Program (DRIP) - Arbitrum","text":"The Arbitrum Foundation notified the Security Council on the need to perform a potential Emergency action. Following a review of the details and known risks, the Security Council decided to execute the upgrade and it was completed at 11:30 EST on 2nd October 2026.\nThis report provides an overview of the risks that required the Security Council Action:\n\nAdd a permissionless guard for the One-Step Proof of BoLD on Arbitrum One\n\nTemporarily pause activation of new Stylus contracts on Arbitrum One & Nova\n\nKey point: To date, known bugs for Stylus primarily impact chain liveness (e.g., denial of service attacks) and do not put any user funds at risk.\nWhy was this action taken\nLet’s take this opportunity to explain why action was taken on two separate issues concerning BoLD and Stylus.\nInstalling the guard for One-Step Proof of BoLD. Given the rise of AI-assisted attacks, we have implemented a precautionary approach that allows anyone to pause settlement of Arbitrum One on Ethereum if there are at least two conflicting answers that pass at the same level in which only one should be valid and pass. This is to halt a class of publicly verifiable and detectable attacks that exploit a bug in the one-step proof. If halted, Arbitrum One will continue to process as normal except that messages from Arbitrum One to Ethereum, such as withdrawals, that are not yet confirmed will have to wait. This provides time for the Security Council to deploy a fix for the bug and resume the rollup.\nPreventing activation of new Stylus contracts. AI-assisted tooling has led to an increasing number of sophisticated attacks on hand-crafted WASM programs that do not use the standard Stylus compiler toolchain. These programs are specifically designed to cause unexpected behaviors such as degrading the chain’s performance for all other users. To date, no attacks have been discovered that permits theft of user funds.\nNew ArbOS releases have patched several reported bugs and known attacks over the past few months, but out of an abundance of caution, we have decided to temporarily pause new activations of Stylus contracts. This was executed as an emergency action to prevent the deployment of new hand-crafted WASM programs that are not yet patched by the current version of ArbOS on the Arbitrum network.\nThe Arbitrum Foundation has informed the Security Council that they will work with the ArbitrumDAO to discuss next steps on the timeline and manner for enabling activation of new Stylus contracts. The Arbitrum community remains confident in the value of Stylus and want to preserve these use cases while taking preventative measures against Stylus-based attack vectors as AI-assisted attack tooling continues to evolve.\nImpact on builders and users\n\nNo new activations. New Stylus contracts cannot be activated during the pause including new versions of existing applications that require activation.\n\nExisting contracts are not paused. Already-active Stylus contracts continue to execute until expiration. This pause does not deactivate them.\n\nThe ArbOS 61 upgrade renewed all active contracts on Arbitrum One, so no currently active contract expires before August 20, 2027.\n\nRenewal via keepalive stays permissionless and is unaffected by the pause.\n\nReactivating an expired contract, or one that needs to be updated after a Stylus version change, is paused.\n\nUsing/calling any activated Stylus contract stays permissionless for all users and developers.\n\nNo impact on EVM. Solidity (EVM) contract deployment and execution are unaffected by this Security Council action.\n\nSecurity Council Actions\nThere are two actions bundled into a single payload:\n\nOne-Step Proof Guard. The L1UpgradeExecutor gives a new pause contract (PauseExecutor) the ability to pause and nothing else. The new pause contract grants the guard (OspSoundnessGuard) PAUSER_ROLE to use it. Anyone can show the guard two conflicting answers to the same step of an open challenge. If the one-step proof accepts both, the guard has the pause contract put Arbitrum One’s settlement to Ethereum on hold.\n\nStylus deactivation. The Security Council called ArbOwner.setWasmActivationGas(2^64 - 1) to raise the Stylus activation gas requirement on Arbitrum One and Nova. This makes activation prohibitively expensive and effectively disables new activations. This is a configuration change and does not require an ArbOS upgrade.\n\nThe Security Council signed the following transactions to update the configuration:\n\nEthereum: Ethereum Transaction Hash: 0x30732bb7d2... | Etherscan\nArbitrum One:\nArbitrum One Transaction Hash: 0x9eb3a4be3b... | Arbitrum One\nArbitrum Nova:\nArbitrum Nova transaction 0x79e0fed470dff7a22059b108e3f8f42eddd2b580a6771594060c4e7326c5f984 | Blockscout\n\nAn external audit was conducted for the OSP Guard contracts. No audit is required for the Stylus deactivation as it is only updating a single parameter in the ArbOS configuration.\n\n DRIP Season 2 Is Live \n\n DAO Programs & InitiativesDeFi Renaissance Incentive Program (DRIP)\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Oct 6\n\n 1 / 1\n\n Oct 5\n\n 13h ago\n\n post by Entropy 13 hours ago\n\n Entropy\n\n Entropy is very excited to announce that DRIP Season 2 is now live, launching today alongside USDG’s arrival on Arbitrum One. The season focuses on growing USDG supply and usage across the Arbitrum ecosystem.\nLive Today\nIncentives are active from today on two USDG opportunities.\n\nGMX: Supply USDG to the GMX Dollar Vault (GLV [USDG-USDG]). USDC can be converted to USDG directly in the GMX app.\nMorpho: Depositors in the Gauntlet USDG Premium vault. A second USDG vault curated by Steakhouse will also join the program once live.\n\nRewards are distributed through Merkl and are generally claimable at arbitrumdrip.com or on the Merkl App. Season 2 runs on DRIP’s remaining budget under the program’s existing mandate, and the committee will add opportunities as further USDG integrations go live.\nThe USDG Proposal\nThe USDG proposal published today asks the DAO to make USDG growth a core strategic initiative. For DRIP, it would update the program’s parameters to match that goal.\n\nBudget: An additional 100M ARB, bringing the remaining budget to ~165M ARB.\nSeason structure: Seasons Two through Four combined into a single USDG-focused season, no longer bound to fixed cycles.\nPermitted activities: Expanded to include protocol-owned liquidity seeding, liquidity arrangements, and incentive structures with teams integrating USDG.\nTimeline: Extended through one year from onchain approval, currently estimated as November 2027.\n\nThe Season Selection Committee composition, two-thirds approval threshold, Arbitrum Foundation custody, and the DAO’s right to end the program stay unchanged. Forum discussion will run from October 6th to 15th, followed by an offchain and onchain vote. We encourage delegates to share feedback in the proposal thread.\nUntil the proposal passes, Season 2 operates under DRIP’s existing parameters, including the remaining ~65M ARB budget and the current mandate through July 1, 2027. If the proposal does not pass, Season 2 continues under those same parameters.\nWhy USDG\nArbitrum’s membership in the Global Dollar Network gives builders an ecosystem-aligned dollar with liquidity, incentives, and integration support from day one. Builders get stablecoin economics without the cost or regulatory lift of launching their own. Under the proposal, the DAO becomes the recipient of the dollar-denominated revenue USDG growth creates, with the majority reinvested into builder incentives and integrations during the growth phase.\nTracking and Reporting\nUSDG supply and activity on Arbitrum One is live at arbdata.com/usdg. DRIP and USDG progress will be covered in Entropy’s monthly updates, consistent with Season One reporting. We appreciate any help amplifying today’s launch, and Arbitrum’s announcement is here.\nThank you to Offchain, the Arbitrum Foundation, OpCo, Paxos, and the numerous launch partners for making today 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 Adopting USDG as a Core Strategic Initiative for the ArbitrumDAO\n\n Proposals\n\n 1\n\n 81\n\n 11h\n\n 11 June 2025 - Roundup of Active/Upcoming Votes\n\n Weekly Voting Reminders & Updates\n\n 2\n\n 119\n\n Jun 2025\n\n DRIP Season 1 Launch Recap\n\n DeFi Renaissance Incentive Program (DRIP)\n\n 2\n\n 755\n\n Sep 2025\n\n DRIP September 2025 Update\n\n DeFi Renaissance Incentive Program (DRIP)\n\n 0\n\n 376\n\n Oct 2025\n\n July 2025 DRIP Update\n\n DeFi Renaissance Incentive Program (DRIP)\n\n 2\n\n 404\n\n Aug 2025","tokens":2152,"squid":"spider-07","role":"Council Spider","at":1791338426882,"hash":"5ca5775960d536ed0cdc368d128cf7c7bffab979"}
{"url":"https://docs.switchboard.xyz/custom-feeds/task-types","domain":"docs.switchboard.xyz","title":"Task Types Reference | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.This documentation is automatically generated from the job_schemas.proto source file.An OracleJob is a collection of tasks that are chained together to arrive at a single numerical value. Tasks execute sequentially, with each task's output feeding into the next.Some tasks do not consume the running input (such as HttpTask and WebsocketTask), effectively resetting the running result. Others transform the current value through mathematical operations or parsing.Data FetchingAnchorFetchTaskLoad a parse an Anchor based solana account.FieldTypeDescriptionprogram_idstringOwning program of the account to parse.account_addressstringThe account to parse.HttpTaskThe adapter will report the text body of a successful HTTP request to the specified url, or return an error if the response status code is greater than or equal to 400.Input: NoneReturns: String representation of the http response.Example: Basic HttpTask{\n \"httpTask\": {\n \"url\": \"https://mywebsite.org/path\"\n }\n}Example: HttpTask example with headers{\n \"httpTask\": {\n \"url\": \"https://mywebsite.org/path\",\n \"method\": \"METHOD_POST\",\n \"headers\": [\n {\n \"key\": \"MY_HEADER_KEY\",\n \"value\": \"MY_HEADER_VALUE\"\n }\n ],\n \"body\": \"{\\\"MY_BODY_KEY\\\":\\\"MY_BODY_VALUE\\\"}\"\n }\n}FieldTypeDescriptionurlstringA string containing the URL to direct this HTTP request to.methodMethodThe type of HTTP request to make.headersHeaderA list of headers to add to this HttpTask.bodystringA stringified body (if any) to add to this HttpTask.Header fieldsFieldTypeDescriptionkeystringA header key such as Authorization or Content-TypevaluestringA value for the given header key like Basic MYAUTHKEY or application/jsonSolanaAccountDataFetchTaskFetch the account data in a stringified buffer format.FieldTypeDescriptionpubkeystringThe on-chain account to fetch the account data from.SolanaToken2022ExtensionTaskApply Solana Token 2022 extension modifiers to a feed. Input: Token address and extension type. Returns: The value associated with the token2022 extension.FieldTypeDescriptionmintstringThe base58 encoded publicKey of the token mint address.SplTokenParseTaskFetch the JSON representation of an SPL token mint.FieldTypeDescriptiontoken_account_addressstringThe publicKey of a token account to fetch the mintInfo for.mint_addressstringThe publicKey of the token mint address.WebsocketTaskOpens and maintains a websocket for light speed data retrieval.Input: NoneReturns: String representation of the websocket subscription message.Example: Opens a coinbase websocket{\n \"websocketTask\": {\n \"url\": \"wss://ws-feed.pro.coinbase.com\",\n \"subscription\": \"{\\\"type\\\":\\\"subscribe\\\",\\\"product_ids\\\":[\\\"BTC-USD\\\"],\\\"channels\\\":[\\\"ticker\\\",{\\\"name\\\":\\\"ticker\\\",\\\"product_ids\\\":[\\\"BTC-USD\\\"]}]}\",\n \"maxDataAgeSeconds\": 15,\n \"filter\": \"$[?(@.type == 'ticker' && @.product_id == 'BTC-USD')]\"\n }\n}FieldTypeDescriptionurlstringThe websocket url.subscriptionstringThe websocket message to notify of a new subscription.max_data_age_secondsint32Minimum amount of time required between when the horses are taking out.filterstringIncoming message JSONPath filter. Example: \"$[?(@.channel == 'ticker' && @.market == 'BTC/USD')]\"ParsingBufferLayoutParseTaskReturn the deserialized value from a stringified buffer.FieldTypeDescriptionoffsetuint32The buffer offset to start deserializing from.endianEndianThe endianness of the stored value.typeBufferParseTypeThe type of value to deserialize.CronParseTaskReturn a timestamp from a crontab instruction.Input: NoneReturns: A timestampExample: Return the unix timestamp for the on-chain SYSCLOCK{\n \"cronParseTask\": {\n \"cronPattern\": \"* * * * * *\",\n \"clockOffset\": 0,\n \"clock\": \"SYSCLOCK\"\n }\n}Example: Return the unix timestamp for next friday at 5pm UTC{\n \"cronParseTask\": {\n \"cronPattern\": \"0 17 * * 5\",\n \"clockOffset\": 0,\n \"clock\": 0\n }\n}FieldTypeDescriptioncron_patternstringThe cron pattern to parse.clock_offsetint32The timestamp offset to calculate the next run.clockClockTypeUse the TaskRunner's clock or the on-chain SYSCLOCK.JsonParseTaskThe adapter walks the path specified and returns the value found at that result. If returning JSON data from the HttpGet or HttpPost adapters, you must use this adapter to parse the response.Input: String representation of a JSON object.Returns: A numerical result.Example: Parses the price field from a JSON object{\n \"jsonParse\": {\n \"path\": \"$.price\"\n }\n}FieldTypeDescriptionpathstringJSONPath formatted path to the element. https://t.ly/uLtw https://www.npmjs.com/package/jsonpath-plusaggregation_methodAggregationMethodThe technique that will be used to aggregate the results if walking the specified path returns multiple numerical results.RegexExtractTaskFind and extract text using regular expressions from the previous task's output.Input: String output from previous taskReturns: The matched string based on the regex pattern and group numberExample: Extract the first number from a string{\n \"regexExtractTask\": {\n \"pattern\": \"\\\\d+\",\n \"groupNumber\": 0\n }\n}Example: Extract text between quotes{\n \"regexExtractTask\": {\n \"pattern\": \"\\\"([^\\\"]+)\\\"\",\n \"groupNumber\": 1\n }\n}Example: Extract the first JSON object from a stream{\n \"regexExtractTask\": {\n \"pattern\": \"\\\\{[^}]+\\\\}\"\n }\n}FieldTypeDescriptionpatternstringThe regular expression pattern to match against the input string. Uses the fancy-regex Rust crate syntax.group_numberint32The capture group number to extract (0 returns full match, 1+ returns respective capture group). Defaults to 0 if not specified.StringMapTaskMap a string input to a predefined output value using exact string matching.Input: String from previous task output or specified valueReturns: The mapped value as a string if a match is found, or the default value if no match is found.Example: Map \"yes\" to \"1\", \"no\" to \"2\", \"maybe\" to \"3\" (case-insensitive){\n \"stringMapTask\": {\n \"mappings\": [\n {\n \"key\": \"yes\",\n \"value\": \"1\"\n },\n {\n \"key\": \"no\",\n \"value\": \"2\"\n },\n {\n \"key\": \"maybe\",\n \"value\": \"3\"\n }\n ],\n \"defaultValue\": \"0\",\n \"caseSensitive\": false\n }\n}Example: Map HTTP response status with case-sensitive matching{\n \"tasks\": [\n {\n \"httpTask\": {\n \"url\": \"https://api.example.com/status\"\n }\n },\n {\n \"regexExtractTask\": {\n \"pattern\": \"status\\\":\\\\s*\\\"([^\\\"]+)\\\"\"\n }\n },\n {\n \"stringMapTask\": {\n \"mappings\": [\n {\n \"key\": \"active\",\n \"value\": \"100\"\n },\n {\n \"key\": \"inactive\",\n \"value\": \"0\"\n },\n {\n \"key\": \"pending\",\n \"value\": \"50\"\n }\n ],\n \"defaultValue\": \"-1\",\n \"caseSensitive\": true\n }\n }\n ]\n}FieldTypeDescriptionmappingsMappingThe list of key-value mappings.default_valuestringOptional default value to return if no mapping matches. If not provided and no match is found, the task will fail.case_sensitiveboolWhether the string matching should be case-sensitive. Defaults to true.inputstringOptional input value to map. If not provided, will use the previous task output.Mapping fieldsFieldTypeDescriptionkeystringThe string key to match against.valuestringThe value to return if the key matches.Mathematical OperationsAddTaskThis task will add a numerical input by a scalar value from a job of subtasks, an aggregator, or a big.Input: The current running numerical result output from a scalar value, an aggregator, a job of subtasks or a big.Returns: A numerical result.Example: Returns the numerical result by adding by a job of subtasks.{\n \"tasks\": [\n {\n \"valueTask\": {\n \"value\": 100\n }\n },\n {\n \"addTask\": {\n \"job\": {\n \"tasks\": [\n {\n \"valueTask\": {\n \"value\": 10\n }\n }\n ]\n }\n }\n }\n ]\n}Example: Returns the numerical result by multiplying by an aggregator.{\n \"tasks\": [\n {\n \"valueTask\": {\n \"value\": 100\n }\n },\n {\n \"addTask\": {\n \"aggregatorPubkey\": \"GvDMxPzN1sCj7L26YDK2HnMRXEQmQ2aemov8YBtPS7vR\"\n }\n }\n ]\n}Example: Returns the numerical result by multiplying by a big.{\n \"tasks\": [\n {\n \"cacheTask\": {\n \"cacheItems\": [\n {\n \"variableName\": \"TEN\",\n \"job\": {\n \"tasks\": [\n {\n \"valueTask\": {\n \"value\": 10\n }\n }\n ]\n }\n }\n ]\n }\n },\n {\n \"valueTask\": {\n \"value\": 100\n }\n },\n {\n \"addTask\": {\n \"big\": \"${TEN}\"\n }\n }\n ]\n}FieldTypeDescriptionscalardoubleSpecifies a scalar to add by.aggregator_pubkeystringSpecifies an aggregator to add by.jobOracleJobA job whose result is computed before adding our numerical input by that result.bigstringA stringified big.js. Accepts variable expansion syntax.BoundTaskBound the running result to an upper/lower bound. This is typically the last task in an OracleJob.Input: The current running numerical result.Returns: The running result bounded to an upper or lower bound if it exceeds a given threshold.Example: Bound the running result to a value between 0.90 and 1.10{\n \"boundTask\": {\n \"lowerBoundValue\": \"0.90\",\n \"onExceedsLowerBoundValue\": \"0.90\",\n \"upperBoundValue\": \"1.10\",\n \"onExceedsUpperBoundValue\": \"1.10\"\n }\n}FieldTypeDescriptionlower_boundOracleJobThe OracleJob to execute for the lower bound value.lower_bound_valuestringThe value to use for the lower bound. Can be set to a ${CACHE_KEY}.upper_boundOracleJobThe OracleJob to execute for the upper bound value.upper_bound_valuestringThe value to use for the upper bound. Can be set to a ${CACHE_KEY}.on_exceeds_upper_boundOracleJobThe OracleJob to execute if the upper bound is exceeded.on_exceeds_upper_bound_valuestringThe value to use if the upper bound is exceeded. Can be set to a ${CACHE_KEY}.on_exceeds_lower_boundOracleJobThe OracleJob to execute if the lower bound is exceeded.on_exceeds_lower_bound_valuestringThe value to use if the lower bound is exceeded. Can be set to a ${CACHE_KEY}.DivideTaskThis task will divide a numerical input by a scalar value from a job of subtasks, an aggregator, or a big.Input: The current running numerical result output from a scalar value, an aggregator, a job of subtasks or a big.Returns: A numerical result.Example: Returns the numerical result by dividing by a job of subtasks.{\n \"tasks\": [\n {\n \"valueTask\": {\n \"value\": 100\n }\n },\n {\n \"divideTask\": {\n \"job\": {\n \"tasks\": [\n {\n \"valueTask\": {\n \"value\": 10\n }\n }\n ]\n }\n }\n }\n ]\n}Example: Returns the numerical result by dividing by an aggregator.{\n \"tasks\": [\n {\n \"valueTask\": {\n \"value\": 100\n }\n },\n {\n \"divideTask\": {\n \"aggregatorPubkey\": \"GvDMxPzN1sCj7L26YDK2HnMRXEQmQ2aemov8YBtPS7vR\"\n }\n }\n ]\n}Example: Returns the numerical result by dividing by a big.{\n \"tasks\": [\n {\n \"cacheTask\": {\n \"cacheItems\": [\n {\n \"variableName\": \"TEN\",\n \"job\": {\n \"tasks\": [\n {\n \"valueTask\": {\n \"value\": 10\n }\n }\n ]\n }\n }\n ]\n }\n },\n {\n \"valueTask\": {\n \"value\": 100\n }\n },\n {\n \"divideTask\": {\n \"big\": \"${TEN}\"\n }\n }\n ]\n}FieldTypeDescriptionscalardoubleSpecifies a basic scalar denominator to divide by.aggregator_pubkeystringSpecifies another aggregator resut to divide by.jobOracleJobA job whose result is computed before dividing our numerical input by that result.bigstringA stringified big.js. Accepts variable expansion syntax.MaxTaskReturns the maximum value of all the results returned by the provided subtasks and subjobs. Nested tasks or jobs must return a Number.Input: NoneReturns: A numerical result.Example: Returns the maximum numerical result from 3 tasks.{\n \"maxTask\": {\n \"tasks\": [\n {\n \"valueTask\": {\n \"value\": 10\n }\n },\n {\n \"valueTask\": {\n \"value\": 20\n }\n },\n {\n \"valueTask\": {\n \"value\": 30\n }\n }\n ]\n }\n}Example: Returns the maximum numerical result from 3 jobs.{\n \"maxTask\": {\n \"jobs\": [\n {\n \"tasks\": [\n {\n \"httpTask\": {\n \"url\": \"https://www.binance.com/api/v3/ticker/price?symbol=SOLUSDT\"\n }\n },\n {\n \"jsonParseTask\": {\n \"path\": \"$.price\"\n }\n }\n ]\n },\n {\n \"tasks\": [\n {\n \"httpTask\": {\n \"url\": \"https://www.binance.us/api/v3/ticker/price?symbol=SOLUSD\"\n }\n },\n {\n \"jsonParseTask\": {\n \"path\": \"$.price\"\n }\n }\n ]\n },\n {\n \"tasks\": [\n {\n \"httpTask\": {\n \"url\": \"https://api-pub.bitfinex.com/v2/tickers?symbols=tSOLUSD\"\n }\n },\n {\n \"jsonParseTask\": {\n \"path\": \"$[0][7]\"\n }\n }\n ]\n }\n ]\n }\n}FieldTypeDescriptiontasksTaskA list of subtasks to process and produce a list of result values.jobsOracleJobA list of subjobs to process and produce a list of result values.MeanTaskReturns the mean (average) of all the results returned by the provided subtasks and subjobs. Nested tasks or jobs must return a Number.Input: NoneReturns: A numerical result.Example: Returns the mean numerical result of 3 tasks.{\n \"meanTask\": {\n \"tasks\": [\n {\n \"valueTask\": {\n \"value\": 10\n }\n },\n {\n \"valueTask\": {\n \"value\": 20\n }\n },\n {\n \"valueTask\": {\n \"value\": 30\n }\n }\n ]\n }\n}Example: Returns the mean numerical result of 3 jobs.{\n \"meanTask\": {\n \"jobs\": [\n {\n \"tasks\": [\n {\n \"httpTask\": {\n \"url\": \"https://www.binance.com/api/v3/ticker/price?symbol=SOLUSDT\"\n }\n },\n {\n \"jsonParseTask\": {\n \"path\": \"$.price\"\n }\n }\n ]\n },\n {\n \"tasks\": [\n {\n \"httpTask\": {\n \"url\": \"https://www.binance.us/api/v3/ticker/price?symbol=SOLUSD\"\n }\n },\n {\n \"jsonParseTask\": {\n \"path\": \"$.price\"\n }\n }\n ]\n },\n {\n \"tasks\": [\n {\n \"httpTask\": {\n \"url\": \"https://api-pub.bitfinex.com/v2/tickers?symbols=tSOLUSD\"\n }\n },\n {\n \"jsonParseTask\": {\n \"path\": \"$[0][7]\"\n }\n }\n ]\n }\n ]\n }\n}FieldTypeDescriptiontasksTaskA list of subtasks to process and produce a list of result values.jobsOracleJobA list of subjobs to process and produce a list of result values.MedianTaskReturns the median (middle) of all the results returned by the provided subtasks and subjobs. Nested tasks must return a Number.Input: NoneReturns: A numerical result.Example: Returns the median numerical result of 3 tasks.{\n \"medianTask\": {\n \"tasks\": [\n {\n \"valueTask\": {\n \"value\": 10\n }\n },\n {\n \"valueTask\": {\n \"value\": 20\n }\n },\n {\n \"valueTask\": {\n \"value\": 30\n }\n }\n ]\n }\n}Example: Returns the median numerical result of 3 jobs.{\n \"medianTask\": {\n \"jobs\": [\n {\n \"tasks\": [\n {\n \"httpTask\": {\n \"url\": \"https://www.binance.com/api/v3/ticker/price?symbol=SOLUSDT\"\n }\n },\n {\n \"jsonParseTask\": {\n \"path\": \"$.price\"\n }\n }\n ]\n },\n {\n \"tasks\": [\n {\n \"httpTask\": {\n \"url\": \"https://www.binance.us/api/v3/ticker/price?symbol=SOLUSD\"\n }\n },\n {\n \"jsonParseTask\": {\n \"path\": \"$.price\"\n }\n }\n ]\n },\n {\n \"tasks\": [\n {\n \"httpTask\": {\n \"url\": \"https://api-pub.bitfinex.com/v2/tickers?symbols=tSOLUSD\"\n }\n },\n {\n \"jsonParseTask\": {\n \"path\": \"$[0][7]\"\n }\n }\n ]\n }\n ]\n }\n}FieldTypeDescriptiontasksTaskA list of subtasks to process and produce a list of result values.jobsOracleJobA list of subjobs to process and produce a list of result values.min_successful_requiredint32The minimum number of values before a successful median can be yielded.max_range_percentstringThe maximum range between the minimum and maximum values before a successful median can be yielded.MinTaskReturns the minimum value of all the results returned by the provided subtasks and subjobs. Nested tasks or jobs must return a Number.Input: NoneReturns: A numerical result.Example: Returns the minimum numerical result from 3 tasks.{\n \"minTask\": {\n \"tasks\": [\n {\n \"valueTask\": {\n \"value\": 10\n }\n },\n {\n \"valueTask\": {\n \"value\": 20\n }\n },\n {\n \"valueTask\": {\n \"value\": 30\n }\n }\n ]\n }\n}Example: Returns the minimum numerical result from 3 jobs.{\n \"minTask\": {\n \"jobs\": [\n {\n \"tasks\": [\n {\n \"httpTask\": {\n \"url\": \"https://www.binance.com/api/v3/ticker/price?symbol=SOLUSDT\"\n }\n },\n {\n \"jsonParseTask\": {\n \"path\": \"$.price\"\n }\n }\n ]\n },\n {\n \"tasks\": [\n {\n \"httpTask\": {\n \"url\": \"https://www.binance.us/api/v3/ticker/price?symbol=SOLUSD\"\n }\n },\n {\n \"jsonParseTask\": {\n \"path\": \"$.price\"\n }\n }\n ]\n },\n {\n \"tasks\": [\n {\n \"httpTask\": {\n \"url\": \"https://api-pub.bitfinex.com/v2/tickers?symbols=tSOLUSD\"\n }\n },\n {\n \"jsonParseTask\": {\n \"path\": \"$[0][7]\"\n }\n }\n ]\n }\n ]\n }\n}FieldTypeDescriptiontasksTaskA list of subtasks to process and produce a list of result values.jobsOracleJobA list of subjobs to process and produce a list of result values.MultiplyTaskThis task will multiply a numerical input by a scalar value from a job of subtasks, an aggregator, or a big.Input: The current running numerical result output from a scalar value, an aggregator, a job of subtasks or a big.Returns: A numerical result.Example: Returns the numerical result by multiplying by a job of subtasks.{\n \"tasks\": [\n {\n \"valueTask\": {\n \"value\": 100\n }\n },\n {\n \"multiplyTask\": {\n \"job\": {\n \"tasks\": [\n {\n \"valueTask\": {\n \"value\": 10\n }\n }\n ]\n }\n }\n }\n ]\n}Example: Returns the numerical result by multiplying by an aggregator.{\n \"tasks\": [\n {\n \"valueTask\": {\n \"value\": 100\n }\n },\n {\n \"multiplyTask\": {\n \"aggregatorPubkey\": \"GvDMxPzN1sCj7L26YDK2HnMRXEQmQ2aemov8YBtPS7vR\"\n }\n }\n ]\n}Example: Returns the numerical result by multiplying by a big.{\n \"tasks\": [\n {\n \"cacheTask\": {\n \"cacheItems\": [\n {\n \"variableName\": \"TEN\",\n \"job\": {\n \"tasks\": [\n {\n \"valueTask\": {\n \"value\": 10\n }\n }\n ]\n }\n }\n ]\n }\n },\n {\n \"valueTask\": {\n \"value\": 100\n }\n },\n {\n \"multiplyTask\": {\n \"big\": \"${TEN}\"\n }\n }\n ]\n}FieldTypeDescriptionscalardoubleSpecifies a scalar to multiply by.aggregator_pubkeystringSpecifies an aggregator to multiply by.jobOracleJobA job whose result is computed before multiplying our numerical input by that result.bigstringA stringified big.js. Accepts variable expansion syntax.PowTaskRound the current running result to an exponential power.Input: The current running numerical result.Returns: The input raised to an exponential power.Example: Raise 2 to the power of 3, 2^3{\n \"tasks\": [\n {\n \"valueTask\": {\n \"value\": 2\n }\n },\n {\n \"powTask\": {\n \"scalar\": 3\n }\n }\n ]\n}FieldTypeDescriptionscalardoubleTake the working value to the exponent of value.aggregator_pubkeystringTake the working value to the exponent of the aggregators value.bigstringA stringified big.js. Accepts variable expansion syntax.RoundTaskRound the current running result to a set number of decimal places.Input: The current running numerical result.Returns: The running result rounded to a set number of decimal places.Example: Round down the running resul to 8 decimal places{\n \"roundTask\": {\n \"method\": \"METHOD_ROUND_DOWN\",\n \"decimals\": 8\n }\n}FieldTypeDescriptionmethodMethodThe rounding method to use.decimalsint32The number of decimals to round to.SubtractTaskThis task will subtract a numerical input by a scalar value from a job of subtasks, an aggregator, or a big.Input: The current running numerical result output from a scalar value, an aggregator, a job of subtasks or a big.Returns: A numerical result.Example: Returns the numerical result by subtracting by a job of subtasks.{\n \"tasks\": [\n {\n \"valueTask\": {\n \"value\": 100\n }\n },\n {\n \"subtractTask\": {\n \"job\": {\n \"tasks\": [\n {\n \"valueTask\": {\n \"value\": 10\n }\n }\n ]\n }\n }\n }\n ]\n}Example: Returns the numerical result by multiplying by an aggregator.{\n \"tasks\": [\n {\n \"valueTask\": {\n \"value\": 100\n }\n },\n {\n \"subtractTask\": {\n \"aggregatorPubkey\": \"GvDMxPzN1sCj7L26YDK2HnMRXEQmQ2aemov8YBtPS7vR\"\n }\n }\n ]\n}Example: Returns the numerical result by multiplying by a big.{\n \"tasks\": [\n {\n \"cacheTask\": {\n \"cacheItems\": [\n {\n \"variableName\": \"TEN\",\n \"job\": {\n \"tasks\": [\n {\n \"valueTask\": {\n \"value\": 10\n }\n }\n ]\n }\n }\n ]\n }\n },\n {\n \"valueTask\": {\n \"value\": 100\n }\n },\n {\n \"subtractTask\": {\n \"big\": \"${TEN}\"\n }\n }\n ]\n}FieldTypeDescriptionscalardoubleSpecifies a scalar to subtract by.aggregator_pubkeystringSpecifies an aggregator to subtract by.jobOracleJobA job whose result is computed before subtracting our numerical input by that result.bigstringA stringified big.js. Accepts variable expansion syntax.DeFi & DEXCurveFinanceTaskFetch pricing information from Curve Finance pools.Input: NoneReturns: The current price/exchange rate from the specified Curve pool.Example: Fetch the price from a Curve pool on Ethereum{\n \"curveFinanceTask\": {\n \"chain\": \"CHAIN_ETHEREUM\",\n \"poolAddress\": \"0xbebc44782c7db0a1a60cb6fe97d0b483032ff1c7\",\n \"outDecimals\": 18\n }\n}Example: Fetch the price using a custom RPC provider{\n \"curveFinanceTask\": {\n \"chain\": \"CHAIN_ETHEREUM\",\n \"provider\": \"https://eth-mainnet.g.alchemy.com/v2/YOUR-API-KEY\",\n \"poolAddress\": \"0xbebc44782c7db0a1a60cb6fe97d0b483032ff1c7\",\n \"outDecimals\": 18\n }\n}FieldTypeDescriptionchainChainRequired. Specifies which blockchain to use when reading information from Curve Finance.providerstringOptional. The RPC endpoint to use for blockchain requests. If not specified, a default RPC will be used which may have rate limits.pool_addressstringThe on-chain address of the Curve Finance pool to fetch pricing data from.out_decimalsuint32The number of decimal places to include in the returned price value.HyloTaskHylo Protocol task for converting 1 hyUSD to jitoSOL. hyUSD is a stablecoin with NAV pegged to $1.00 USD. Converts exactly 1 hyUSD token to jitoSOL.FieldTypeDescriptiontokenTokenThe Hylo token to convert from (defaults to hyUSD)JupiterSwapTaskFetch the simulated price for a swap on JupiterSwap.Input: NoneReturns: The swap price on Jupiter for a given input and output token mint address.Example: Fetch the JupiterSwap price for exchanging 1 SOL into USDC.{\n \"jupiterSwapTask\": {\n \"inTokenAddress\": \"So11111111111111111111111111111111111111112\",\n \"outTokenAddress\": \"EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v\"\n }\n}Example: Fetch the JupiterSwap price for exchanging 1000 SOL into USDC.{\n \"jupiterSwapTask\": {\n \"inTokenAddress\": \"So11111111111111111111111111111111111111112\",\n \"outTokenAddress\": \"EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v\",\n \"baseAmount\": \"1000\"\n }\n}Example: Supply a request-scoped Jupiter API key without storing it in the job.{\n \"jupiterSwapTask\": {\n \"inTokenAddress\": \"So11111111111111111111111111111111111111112\",\n \"outTokenAddress\": \"EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v\",\n \"baseAmountString\": \"1\",\n \"apiKey\": \"${JUPITER_API_KEY}\"\n }\n}Pass the matching non-empty value when requesting the feed:const response = await gateway.fetchSignaturesConsensus({\n // ...\n variableOverrides: {\n JUPITER_API_KEY: process.env.JUPITER_API_KEY!,\n },\n});FieldTypeDescriptionin_token_addressstringThe input token address.out_token_addressstringThe output token address.allow_listFilterListA list of AMM markets to allow.deny_listFilterListA list of AMM markets to deny.base_amountdoubleThe amount of in_token_address tokens to swap.quote_amountdoubleThe amount of out_token_address tokens to swap.base_amount_stringstringThe amount of in_token_address tokens to swap.quote_amount_stringstringThe amount of out_token_address tokens to swap.slippagedoubleThe allowable slippage on the swap in decimal form (e.g. 0.5 is 0.5% slippage)api_keystringOptional Jupiter API key. For a request-scoped key, set this field to a variable placeholder such as ${JUPITER_API_KEY} and provide the matching non-empty value through variableOverrides when requesting the feed. An override is only applied when this field contains a matching placeholder. If the placeholder is unresolved, the task fails before contacting Jupiter. If this field is omitted or empty, the oracle's configured Jupiter key is used when available. Do not hardcode credentials in an oracle job.FilterList fieldsFieldTypeDescriptionlabelsstringA list of Jupiter AMM labels to allow or deny (e.g. 'Raydium', 'Orca')KuruTaskFetch a swap quote from Kuru API for best path routing on EVM chains.Input: NoneReturns: The expected output amount for swapping tokens via Kuru.Example: Fetch a quote for swapping 1 WETH to USDC.{\n \"kuruTask\": {\n \"tokenIn\": \"0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2\",\n \"tokenOut\": \"0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48\",\n \"amount\": \"1000000000000000000\"\n }\n}Example: Fetch a quote with custom slippage tolerance.{\n \"kuruTask\": {\n \"tokenIn\": \"0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2\",\n \"tokenOut\": \"0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48\",\n \"amount\": \"1000000000000000000\",\n \"autoSlippage\": false,\n \"slippageTolerance\": 100\n }\n}FieldTypeDescriptionuser_addressstringThe Ethereum address of the user making the swap (default: zero address).token_instringThe input token contract address (EVM address format).token_outstringThe output token contract address (EVM address format).amountstringThe amount to swap in wei (e.g., \"1000000000000000000\" for 1 token with 18 decimals).auto_slippageboolWhether to automatically calculate slippage tolerance (default: true).slippage_toleranceuint32Slippage tolerance in basis points (1-10000, e.g., 50 = 0.5%). Only used when auto_slippage is false.referrer_addressstringOptional referrer address for fee sharing.referrer_fee_bpsuint32Optional referrer fee in basis points (0-10000).input_decimalsuint32Number of decimals for the input token (default: 18).output_decimalsuint32Number of decimals for the output token (default: 18).api_keystringOptional API key for authentication (X-API-Key header).bearer_tokenstringOptional bearer token for authentication (Authorization header).api_endpointstringOptional API endpoint override (defaults to ws.staging.kuru.io/api/quote).LpExchangeRateTaskFetch the current swap price for a given liquidity poolInput: NoneReturns: The swap price for a given AMM pool.Example: Fetch the exchange rate from the Orca SOL/USDC pool{\n \"lpExchangeRateTask\": {\n \"orcaPoolAddress\": \"APDFRM3HMr8CAGXwKHiu2f5ePSpaiEJhaURwhsRrUUt9\"\n }\n}Example: Fetch the exchange rate from the Raydium SOL/USDC pool{\n \"lpExchangeRateTask\": {\n \"raydiumPoolAddress\": \"58oQChx4yWmvKdwLLZzBi4ChoCc2fqCUWBkwMihLYQo2\"\n }\n}FieldTypeDescriptionin_token_addressstringUsed alongside mercurial_pool_address to specify the input token for a swap.out_token_addressstringUsed alongside mercurial_pool_address to specify the output token for a swap.mercurial_pool_addressstringMercurial finance pool address. A full list can be found here: https://github.com/mercurial-finance/stable-swap-n-pool-jssaber_pool_addressstringSaber pool address. A full list can be found here: https://github.com/saber-hq/saber-registry-distorca_pool_token_mint_addressstring@deprecated Use orcaPoolAddressraydium_pool_addressstringThe Raydium liquidity pool ammId. A full list can be found here: https://raydium.io/poolsorca_pool_addressstringPool address for an Orca LP pool or whirlpool. A full list of Orca LP pools can be found here: https://www.orca.so/poolsport_reserve_addressstringThe Port reserve pubkey. A full list can be found here: https://api-v1.port.finance/reservesdefituna_pool_addressstringDefiTuna Fusion AMM pool address. Program ID: tuna4uSQZncNeeiAMKbstuxA9CUkHH6HmC64wgmnogDLpTokenPriceTaskFetch LP token price info from a number of supported exchanges.See our blog post on Fair LP Token OraclesNOTE: This is not the swap price but the price of the underlying LP token.Input: NoneReturns: The price of an LP token for a given AMM pool.Example: Fetch the Orca LP token price of the SOL/USDC pool{\n \"lpTokenPriceTask\": {\n \"orcaPoolAddress\": \"APDFRM3HMr8CAGXwKHiu2f5ePSpaiEJhaURwhsRrUUt9\"\n }\n}Example: Fetch the fair price Orca LP token price of the SOL/USDC pool{\n \"lpTokenPriceTask\": {\n \"orcaPoolAddress\": \"APDFRM3HMr8CAGXwKHiu2f5ePSpaiEJhaURwhsRrUUt9\",\n \"useFairPrice\": true,\n \"priceFeedAddresses\": [\n \"GvDMxPzN1sCj7L26YDK2HnMRXEQmQ2aemov8YBtPS7vR\",\n \"BjUgj6YCnFBZ49wF54ddBVA9qu8TeqkFtkbqmZcee8uW\"\n ]\n }\n}Example: Fetch the fair price Raydium LP token price of the SOL/USDC pool{\n \"lpTokenPriceTask\": {\n \"raydiumPoolAddress\": \"58oQChx4yWmvKdwLLZzBi4ChoCc2fqCUWBkwMihLYQo2\",\n \"useFairPrice\": true,\n \"priceFeedAddresses\": [\n \"GvDMxPzN1sCj7L26YDK2HnMRXEQmQ2aemov8YBtPS7vR\",\n \"BjUgj6YCnFBZ49wF54ddBVA9qu8TeqkFtkbqmZcee8uW\"\n ]\n }\n}FieldTypeDescriptionmercurial_pool_addressstringMercurial finance pool address. A full list can be found here: https://github.com/mercurial-finance/stable-swap-n-pool-jssaber_pool_addressstringSaber pool address. A full list can be found here: https://github.com/saber-hq/saber-registry-distorca_pool_addressstringOrca pool address. A full list can be found here: https://www.orca.so/poolsraydium_pool_addressstringThe Raydium liquidity pool ammId. A full list can be found here: https://raydium.io/poolsprice_feed_addressesstringA list of Switchboard aggregator accounts used to calculate the fair LP price. This ensures the price is based on the previous round to mitigate flash loan price manipulation.price_feed_jobsOracleJobA list of OracleJobs to execute in order to yield the price feed jobs to use for the fair price formula.use_fair_priceboolIf enabled and price_feed_addresses provided, the oracle will calculate the fair LP price based on the liquidity pool reserves. See our blog post for more information: https://switchboardxyz.medium.com/fair-lp-token-oracles-94a457c50239MaceTaskFetch a swap quote from MACE (M.A.C.E.) aggregator for best path routing on EVM chains. MACE is a Multi-DEX EVM trade solver that uses simulated transactions for optimal routing.Input: NoneReturns: The expected output amount for swapping tokens via MACE aggregator.Example: Fetch a quote for swapping 1 WETH to USDC on Ethereum.{\n \"maceTask\": {\n \"tokenIn\": \"0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2\",\n \"tokenOut\": \"0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48\",\n \"amount\": \"1000000000000000000\"\n }\n}Example: Fetch a quote with custom slippage and gas price.{\n \"maceTask\": {\n \"tokenIn\": \"0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2\",\n \"tokenOut\": \"0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48\",\n \"amount\": \"1000000000000000000\",\n \"slippageToleranceBps\": 100,\n \"gasPriceWei\": \"50000000000\"\n }\n}FieldTypeDescriptionfrom_addressstringThe Ethereum address of the user making the swap (default: zero address).token_instringThe input token identifier (EVM address, \"native\", or ERC1155 format). Examples: \"native\", \"0x760AfE86e5de5fa0Ee542fc7B7B713e1c5425701\"token_outstringThe output token identifier (EVM address, \"native\", or ERC1155 format).amountstringThe amount to swap in wei (e.g., \"1000000000000000000\" for 1 token with 18 decimals).slippage_tolerance_bpsuint32Slippage tolerance in basis points (1-10000, e.g., 100 = 1%). Default: 10000 (100%).gas_price_weistringGas price to simulate with in wei. Influences route selection - higher values weight gas usage more. Default: \"1000000000\" (1 Gwei).max_routesuint32Maximum number of routes to return (default: 1). Routes range from most valuable to most stable.input_decimalsuint32Number of decimals for the input token (default: 18).output_decimalsuint32Number of decimals for the output token (default: 18).api_keystringOptional API key for authentication.api_endpointstringOptional API endpoint override (defaults to testnet.api.beta.mace.ag for testnet).MeteoraSwapTaskGrab the swap price from a Meteora pool.FieldTypeDescriptionpoolstringThe address of the pool.typeTypeThe pool type.PancakeswapExchangeRateTaskFetch the swap price from PancakeSwap.FieldTypeDescriptionin_token_addressstringThe input token address.out_token_addressstringThe output token address.in_token_amountdoubleThe amount of tokens to swap.slippagedoubleThe allowable slippage in percent for the swap.providerstringThe RPC provider to use for the swap.PumpAmmLpTokenPriceTaskDerive the fair LP token price for a given Pump AMM liquidity pool. Input: Pool address, X token price job, Y token price job. Returns: The fair LP token price for the given Pump AMM liquidity pool. Example: Derive the fair LP token price for a given Pump AMM liquidity pool. {\n \"pumpAmmLpTokenPriceTask\": {\n \"pool_address\": \"Gf7sXMoP8iRw4iiXmJ1nq4vxcRycbGXy5RL8a8LnTd3v\", // USDC/SOL\n \"x_price_job\": {\n \"oracleTask\": {\n \"switchboardAddress\": \"...\" // USDC/USD\n }\n },\n \"y_price_job\": {\n \"oracleTask\": {\n \"switchboardAddress\": \"...\" // SOL/USD\n }\n }\n }\n }\n\n| Field | Type | Description |\n|-------|------|-------------|\n| `pool_address` | string | Required. The address of the liquidity pool in the Pump AMM. |\n| `x_price_job` | OracleJob | Required. The job to execute to fetch the price of the pool x token |\n| `y_price_job` | OracleJob | Required. The job to execute |\n\n---\n\n### PumpAmmTask\n\nExecute a swap task in the Pump AMM based on the given parameters.\n\n _**Input**_: Pool address, input token amount, max allowed slippage, and swap direction.\n\n _**Returns**_: Executes the swap operation in the Pump AMM with the given parameters.\n\n _**Example**_: Swap 10 tokens from X to Y with a maximum slippage of 0.5%\n\n ```json\n {\n \"pumpAmmTask\": {\n \"pool_address\": \"Gf7sXMoP8iRw4iiXmJ1nq4vxcRycbGXy5RL8a8LnTd3v\",\n \"in_amount\": \"10\",\n \"max_slippage\": 0.5,\n \"is_x_for_y\": true\n }\n }\n\n| Field | Type | Description |\n|-------|------|-------------|\n| `pool_address` | string | Required. The address of the liquidity pool in the Pump AMM. |\n| `in_amount` | double | Optional. The input token amount for the swap. - This value should in full units of the input token. - Default value: `1` (Swap 1 full token). |\n| `max_slippage` | double | Optional. The maximum allowed slippage for the swap, expressed as a percentage. - Example: `0.5` represents 0.5% slippage tolerance. - Default value: `3` (3% slippage tolerance). |\n| `is_x_for_y` | bool | Optional. Indicates the swap direction: - `true`: Swapping token X for token Y. - `false`: Swapping token Y for token X. - Default value: `true`. |\n\n---\n\n### SerumSwapTask\n\nFetch the latest swap price on Serum's orderbook\n\n| Field | Type | Description |\n|-------|------|-------------|\n| `serum_pool_address` | string | The serum pool to fetch swap price for |\n\n---\n\n### SushiswapExchangeRateTask\n\nFetch the swap price from SushiSwap.\n\n| Field | Type | Description |\n|-------|------|-------------|\n| `in_token_address` | string | The input token address. |\n| `out_token_address` | string | The output token address. |\n| `in_token_amount` | double | The amount of tokens to swap. |\n| `slippage` | double | The allowable slippage in percent for the swap. |\n| `provider` | string | The RPC provider to use for the swap. |\n\n---\n\n### TitanTask\n\nFetch the simulated swap price from Titan API.\n\n_**Input**_: None\n\n_**Returns**_: The swap price on Titan for a given input and output token mint address.\n\n_**Example**_: Fetch the Titan price for exchanging 1 SOL into USDC.\n\n```json\n{\n \"titanTask\": {\n \"inTokenAddress\": \"So11111111111111111111111111111111111111112\",\n \"outTokenAddress\": \"EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v\"\n }\n}Example: Fetch the Titan price for exchanging 1000 SOL into USDC with slippage.{\n \"titanTask\": {\n \"inTokenAddress\": \"So11111111111111111111111111111111111111112\",\n \"outTokenAddress\": \"EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v\",\n \"amount\": \"1000\",\n \"slippageBps\": 50\n }\n}FieldTypeDescriptionin_token_addressstringThe input token mint address (base58 encoded).out_token_addressstringThe output token mint address (base58 encoded).amountstringThe amount of tokens to swap (raw atoms, not scaled by decimals).user_public_keystringOptional user public key for transaction generation (base58 encoded).swap_modeSwapModeWhether the amount is in terms of input or output token. Defaults to ExactIn.slippage_bpsuint32Allowed slippage in basis points (e.g., 50 = 0.5%).dexesFilterListIf set, constrain quotes to the given set of DEXes.exclude_dexesFilterListIf set, exclude the following DEXes when determining routes.only_direct_routesboolIf set to true, only direct routes between the input and output mint will be considered.providersstringIf set, limit quotes to the given set of provider IDs.access_tokenstringOptional API access token for authenticated requestsapi_endpointstringOptional API endpoint override (defaults to partners.api.titan.exchange)FilterList fieldsFieldTypeDescriptionlabelsstringA list of DEX labels to allow or deny (e.g., 'Raydium', 'Orca')UniswapExchangeRateTaskFetch the swap price from UniSwap.FieldTypeDescriptionin_token_addressstringThe input token address.out_token_addressstringThe output token address.in_token_amountdoubleThe amount of tokens to swap.slippagedoubleThe allowable slippage in percent for the swap.providerstringThe RPC provider to use for the swap.versionVersionThe version of the Uniswap exchange to use.LST & StakingLstHistoricalYieldTaskQuery historical yield data for a given Liquid Staking Token (LST) and perform a statistical reduction operation over the dataset.Input: LST mint address, reduction operation type, and number of epochs to sample.Returns: The computed yield value based on the specified operation.Example: Compute the median APY for an LST over the last 100 epochs{\n \"lstHistoricalYieldTask\": {\n \"lstMint\": \"J1toso1uCk3RLmjorhTtrVwY9HJ7X8V9yYac6Y7kGCPn\",\n \"operation\": \"OPERATION_MEDIAN\",\n \"epochs\": 100\n }\n}\n\n| Field | Type | Description |\n|-------|------|-------------|\n| `lst_mint` | string | Required. The LST mint address for which historical yield data is queried. |\n| `operation` | Operation | Required. The statistical operation to apply to the historical yield dataset. |\n| `epochs` | int32 | Optional. The number of epochs to sample for the computation. - If `epochs = 0`, all available historical data will be used. - If `epochs > 0`, only the last `epochs` entries will be included. |\n\n---\n\n### MarinadeStateTask\n\nFetch the current mSOL/SOL exchange rate from the Marinade program state.\n\n_**Input**_: None\n\n_**Returns**_: The current value of 1 mSOL in SOL.\n\n_**Example**_: Fetch the mSOL/SOL exchange rate\n\n```json\n{\n \"marinadeStateTask\": {}\n}SanctumLstPriceTaskGrab the price of an Sanctum LST relative to SOL.FieldTypeDescriptionlst_mintstringThe address of the LST mint. e.g. INF - 5oVNBeEEQvYi1cX3ir8Dx5n1P7pdxydbGF2X4TxVusJmskip_epoch_checkboolAllow the check to see if the LST was cranked for the current epoch to be skipped.SolayerSusdTaskFetch the current price of Solayer's sUSD stablecoin by reading its interest-bearing mint configuration.Input: NoneReturns: The current price of sUSD relative to USD (1.0 = $1.00)Example: Fetch the current sUSD price{\n \"solayerSusdTask\": {}\n}SplStakePoolTaskFetch the JSON representation of an SPL Stake Pool account.FieldTypeDescriptionpubkeystringThe pubkey of the SPL Stake Pool.SuiLstPriceTaskGet the exchange rate for Sui Liquid Staking Tokens (LSTs) relative to SUI.All configuration is passed as parameters, allowing support for any LST without code changes.Input: NoneReturns: The exchange rate (e.g., 1.068 means 1 LST = 1.068 SUI)Example: haSUI (simple - 1 shared object):{\n \"suiLstPriceTask\": {\n \"packageId\": \"0xbde4ba4c2e274a60ce15c1cfff9e5c42e41654ac8b6d906a57efa4bd3c29f47d\",\n \"module\": \"staking\",\n \"function\": \"get_sui_by_stsui\",\n \"sharedObjects\": [\n \"0x47b224762220393057ebf4f70501b6e657c3e56684737568439a04f80849b2ca\"\n ],\n \"provideLstAmount\": true\n }\n}Example: vSUI (2 shared objects - StakePool + Metadata):{\n \"suiLstPriceTask\": {\n \"packageId\": \"0x68d22cf8bdbcd11ecba1e094922873e4080d4d11133e2443fddda0bfd11dae20\",\n \"module\": \"stake_pool\",\n \"function\": \"lst_amount_to_sui_amount\",\n \"sharedObjects\": [\n \"0x2d914e23d82fedef1b5f56a32d5c64bdcc3087ccfea2b4d6ea51a71f587840e5\",\n \"0x680cd26af32b2bde8d3361e804c53ec1d1cfe24c7f039eb7f549e8dfde389a60\"\n ],\n \"provideLstAmount\": true\n }\n}FieldTypeDescriptionpackage_idstringThe package ID containing the exchange rate function.modulestringThe module name containing the exchange rate function.functionstringThe function name to call (e.g., \"get_sui_by_stsui\", \"from_shares\", \"get_exchange_rate\").shared_objectsstringList of shared object IDs to pass as arguments (in order). These will be resolved to SharedObject arguments with their initial_shared_version.provide_lst_amountboolIf true, appends the LST amount (1e9 = 1 token) as a Pure u64 argument after shared objects. Set to true for functions like \"get_sui_by_stsui(staking, amount)\" or \"from_shares(pool, meta, amount)\". Set to false for functions like \"get_exchange_rate(staking)\" that return the rate directly.rpc_urlstringThe Sui RPC endpoint to use for fetching on-chain data. If not specified, uses the default mainnet RPC.VsuiPriceTaskGet the vSUI/SUI exchange rate on Sui mainnet. No inputs required - uses hardcoded vSUI pool addresses. @deprecated Use SuiLstPriceTask with lst_type = LST_VSUI instead.FieldTypeDescriptionrpc_urlstringThe Sui RPC endpoint to use for fetching on-chain data. If not specified, uses the default mainnet RPC.Oracle IntegrationEwmaTaskCompute an exponentially weighted moving average (EWMA) over an aggregator's history buffer.Input: Aggregator address, lookback period (in seconds), and smoothing factor lambda.Returns: The EWMA value over the specified period.Example: Compute the 1h EWMA with lambda 0.94{\n \"ewmaTask\": {\n \"aggregatorAddress\": \"AGGREGATOR_PUBKEY\",\n \"period\": 3600,\n \"lambda\": 0.94\n }\n}FieldTypeDescriptionaggregator_addressstringThe aggregator to query.periodint32Lookback period in seconds.lambdadoubleSmoothing factor in the range (0, 1].OracleTaskFetch the current price of a Solana oracle protocol.Input: NoneReturns: The current price of an on-chain oracle.Example: The Switchboard SOL/USD oracle price.{\n \"oracleTask\": {\n \"switchboardAddress\": \"GvDMxPzN1sCj7L26YDK2HnMRXEQmQ2aemov8YBtPS7vR\"\n }\n}Example: The Pyth SOL/USD oracle price.{\n \"oracleTask\": {\n \"pythAddress\": \"H6ARHf6YXhGYeQfUzQNGk6rDNnLBQKrenN712K4AQJEG\"\n }\n}Example: The Pyth SOL/USD oracle price using a Hermes API key supplied at execution time.{\n \"oracleTask\": {\n \"pythAddress\": \"H6ARHf6YXhGYeQfUzQNGk6rDNnLBQKrenN712K4AQJEG\",\n \"pythConfigs\": {\n \"apiKey\": \"${PYTH_API_KEY}\"\n }\n }\n}Supply the key in the execution request as \"variableOverrides\": { \"PYTH_API_KEY\": \"...\" }.Example: The Pyth SOL/USD push oracle price.{\n \"oracleTask\": {\n \"pythPushFeedId\": \"0xef0d8b6fda2ceba41da15d4095d1da392a0d2f8ed0c6c7bc0f4cfac8c280b56d\",\n \"pythConfigs\": {\n \"pushFeedShardId\": 0,\n \"maxStaleSeconds\": 75\n }\n }\n}Example: The Chainlink SOL/USD oracle price.{\n \"oracleTask\": {\n \"chainlinkAddress\": \"CcPVS9bqyXbD9cLnTbhhHazLsrua8QMFUHTutPtjyDzq\"\n }\n}FieldTypeDescriptionswitchboard_addressstringMainnet address of a Switchboard feed. Switchboard is decentralized and allows anyone to build their own feed.pyth_addressstringMainnet address for a Pyth feed. A full list can be found here: https://pyth.network/price-feeds/chainlink_addressstringMainnet address for a Chainlink feed. A full list can be found here: https://docs.chain.link/docs/solana/data-feeds-solanapyth_push_feed_idstringPyth price feed ID for an upgraded Solana push feed. The task derives and reads the on-chain feed account using this ID and pyth_configs.push_feed_shard_id; it does not use Hermes or a Hermes API key.pyth_allowed_confidence_intervaldoubleValue (as a percentage) that the lower bound confidence interval is of the actual value. Confidence intervals that are larger that this treshold are rejected. The confidence interval should be provided as a raw percentage value. For example, to represent 10%, enter the value as 10, not 0.1.pyth_configsPythConfigsOptional settings for Pyth Hermes and on-chain push-feed tasks.PythConfigs fieldsFieldTypeDescriptionhermes_urlstringOptional Hermes base URL used by pyth_address tasks.pyth_allowed_confidence_intervaldoublePreferred Pyth confidence interval setting, expressed as a raw percentage. For example, use 10 to represent 10%, not 0.1.max_stale_secondsint32Maximum accepted price age in seconds. Defaults to 15 seconds for pyth_address and 75 seconds for pyth_push_feed_id.push_feed_shard_iduint32Pyth push-feed shard used only by pyth_push_feed_id. Defaults to shard 0.api_keystringOptional API key for authenticated Pyth Hermes requests made by pyth_address tasks. Use a variable placeholder such as ${PYTH_API_KEY} and supply a matching non-empty variableOverrides value at execution time; do not hardcode credentials. This field takes precedence when it is non-empty. If it is omitted or empty, variableOverrides.PYTH_API_KEY is accepted as a compatibility fallback. That fallback is request-wide: the same value is used by every pyth_address task in the execution that does not configure its own api_key. Pyth push-feed tasks read on-chain accounts and do not use this API key.SurgeTwapTaskCompute TWAP from local candle database using AUTO-resolved source.Uses the AUTO source cache to resolve the best (exchange, pair) for a canonical USD pair, then queries local candle storage and computes TWAP.FieldTypeDescriptionsymbolstringCanonical USD trading pair (e.g., \"BTC/USD\", \"ETH/USD\", \"SOL/USD\")time_intervalTimeIntervalTime interval for TWAP calculation (default: ONE_HOUR)SwitchboardSurgeTaskFetch a live spot price straight out of the global Surge websocket cache – the same cache that powers our high-speed on-chain oracles. Input • symbol – the trading-pair symbol as it appears on the exchange • source – which exchange's stream to read from • BINANCE (weight 3) • BYBIT (weight 2) • OKX (weight 2) • COINBASE (weight 3, disabled) • BITGET (weight 2) • PYTH (weight 1) – Pyth oracle network • TITAN (weight 1) – Titan DEX aggregator on Solana • WEIGHTED (default) – use the weighted median of all fresh quotes with the weights shown above. • AUTO – automatically select the best source based on volume, spread, and data quality metrics. Returns The most recent price available from the chosen source. The task fails if the cached tick is older than 5 s. Example: Pull the Binance price for BTC / USDT{\n \"switchboardSurgeTask\": {\n \"source\": \"BINANCE\",\n \"symbol\": \"BTC/FDUSD\"\n }\n}Example: Use the weighted-median oracle for BTC / USDT{\n \"switchboardSurgeTask\": {\n \"source\": \"WEIGHTED\", // or omit — WEIGHTED is the default\n \"symbol\": \"BTC/USD\"\n }\n}Example: Pull the Pyth oracle price for PYUSD / USD{\n \"switchboardSurgeTask\": {\n \"source\": \"PYTH\",\n \"symbol\": \"PYUSD/USD\"\n }\n}Example: Pull the Titan DEX aggregator price for SOL / USDC{\n \"switchboardSurgeTask\": {\n \"source\": \"TITAN\",\n \"symbol\": \"SOL/USDC\"\n }\n}Notes • Symbols are auto-normalised (case-insensitive, punctuation removed). • If a venue’s price is stale (> 5 s) it is ignored in the WEIGHTED calculation. The task errors if no fresh price remains. • The weighted-median algorithm uses cumulative weights based on each exchange's data quality and volume. Currently active sources: Binance (3), Bybit (2), OKX (2), Bitget (2), Pyth (1), Titan (1).TwapTaskTakes a twap over a set period for a certain aggregator. Aggregators have an optional history buffer account storing the last N accepted results. The TwapTask will iterate over an aggregators history buffer and calculate the time weighted average of the samples within a given time period.Input: NoneReturns: The time weighted average of an aggregator over a given time period.Example: The 1hr Twap of the SOL/USD Aggregator, requiring at least 60 samples.{\n \"twapTask\": {\n \"aggregatorPubkey\": \"GvDMxPzN1sCj7L26YDK2HnMRXEQmQ2aemov8YBtPS7vR\",\n \"period\": 3600,\n \"minSamples\": 60,\n \"weightByPropagationTime\": true\n }\n}FieldTypeDescriptionaggregator_pubkeystringThe target aggregator for the TWAP.periodint32Period, in seconds, the twap should account forweight_by_propagation_timeboolWeight samples by their propagation timemin_samplesuint32Minimum number of samples in the history to calculate a valid resultending_unix_timestampint32Ending unix timestamp to collect values up toending_unix_timestamp_taskCronParseTaskExecute the task to get the ending unix timestampSpecialized FinanceExponentPTLinearPricingTaskCompute the current price of an Exponent principal token using a linear schedule from start_price to 1.0 at maturity. Input: Vault address and starting price. Returns: The current principal token price. Example: Price a PT that linearly approaches 1.0 {\n \"exponentPtLinearPricingTask\": {\n \"vault\": \"9YbaicMsXrtupkpD72pdWBfU6R7EJfSByw75sEpDM1uH\",\n \"startPrice\": 0.8\n }\n }\n\n| Field | Type | Description |\n|-------|------|-------------|\n| `vault` | string | The Exponent vault address. |\n| `start_price` | double | The starting price at the vault start timestamp. |\n\n---\n\n### ExponentTask\n\nGet the exchange rate between and Exponent vault pricipal token and\nunderlying token.\n_**Input**_: Vault address\n_**Returns**_: The exchange rate between the vault principal token and\nunderlying token.\n_**Example**_: Get the exchange rate between the vault principal token and\nunderlying token.\n```json\n {\n \"exponentTask\": {\n \"vault\": \"9YbaicMsXrtupkpD72pdWBfU6R7EJfSByw75sEpDM1uH\"\n }\n }\n\n---\n\n### KalshiApiTask\n\nKalshiApiTask fetches a GET endpoint from the Kalshi API (with a token if supplied) and returns the JSON result\n\n| Field | Type | Description |\n|-------|------|-------------|\n| `url` | string | A string containing the URL to direct this HTTP request to. |\n| `api_key_id` | string | A string containing the API Key ID |\n| `private_key` | string | A string containing the private key for authentication |\n| `signature` | string | Optional signature string field |\n| `timestamp` | string | Optional timestamp in milliseconds (used with signature) |\n\n---\n\n### LendingRateTask\n\nFetch the lending rates for various Solana protocols\n\n| Field | Type | Description |\n|-------|------|-------------|\n| `protocol` | string | 01, apricot, francium, jet, larix, mango, port, solend, tulip |\n| `asset_mint` | string | A token mint address supported by the chosen protocol |\n\n---\n\n### MapleFinanceTask\n\nFetch pricing information for Maple Finance assets.\n\n_**Input**_: None\n\n_**Returns**_: The requested price or value based on the specified method.\n\n_**Example**_: Fetch the syrupUSDC fair price from Maple Finance\n\n```json\n{\n \"mapleFinanceTask\": {\n \"method\": \"METHOD_SYRUP_USDC_FAIR_PRICE\"\n }\n}FieldTypeDescriptionmethodMethodThe specific method to use for this task.OndoUsdyTaskOndoUsdyTask represents a task that computes the price of USDY relative to USD using a specified strategy.FieldTypeDescriptionstrategyStrategyThe strategy used to determine the price of USDY.PerpMarketTaskFetch the current price of a perpetual market.FieldTypeDescriptionmango_market_addressstringMarket address for a mango perpetual market. A full list can be found here: https://github.com/blockworks-foundation/mango-client-v3/blob/main/src/ids.jsondrift_market_addressstringMarket address for a drift perpetual market. A full list can be found here: https://github.com/drift-labs/protocol-v1/blob/master/sdk/src/constants/markets.tszeta_market_addressstringMarket address for a zeta perpetual market.zo_market_addressstringMarket address for a 01 protocol perpetual market.TurboEthRedemptionRateTaskFetches tETH/WETH redemption rateUtilitiesBlake2b128TaskCompute the BLAKE2b-128 hash of the input data and convert it to a numeric Decimal value.This task follows cryptographic standard hash truncation practices used in:SHA-224: SHA-256 truncated to leftmost 224 bitsBLAKE2s-128: BLAKE2s-256 truncated to leftmost 128 bitsBLAKE2b-256: BLAKE2b-512 truncated to leftmost 256 bitsInput: String data to hash (can be from a previous task's output)Returns: A positive Decimal number with 18 decimal places (scale 18)Range: 0.000000000000000000 to 79228162514264.337593543950335 (2^96 - 1, scaled)Example: 17512223723.299011049621773283Hash-to-Decimal Conversion AlgorithmStep-by-Step Process1. Compute BLAKE2b-128 hash (produces 16 bytes / 128 bits)Input: \"Hello, World!\"\nOutput: 3895c59e4aeb0903396b5be3fbec69fe2. Truncate to 96 bits (12 bytes) - keep the most significant bitsKEPT (first 12 bytes): 3895c59e4aeb0903396b5be3\nDISCARDED (last 4 bytes): fbec69feThis follows cryptographic standards where truncation keeps the leftmost/most significant bits.3. Pad to 16 bytes for u128 representationAdd 4 zero bytes at the BEGINNING:\n\n000000003895c59e4aeb0903396b5be3\n└──┬──┘└──────────┬───────────┘\npadding first 12 bytes\n(4 bytes) (most significant)4. Interpret as u128 using big-endian byte orderHex: 0x000000003895c59e4aeb0903396b5be3\nDecimal: 17512223723299011049621773283Big-endian is the standard for cryptographic hash representations.5. Convert to Decimal with scale 18 (18 decimal places)Value: 17512223723299011049621773283\nScaled: 17512223723.299011049621773283 (divided by 10^18)Scale 18 prevents precision loss when the protocol rescales values. Guaranteed to fit in Decimal's 96-bit mantissa (max: 2^96 - 1).ReproducibilityTo reproduce this conversion in any programming language:Python Exampleimport hashlib\nfrom decimal import Decimal\n\n# 1. Compute BLAKE2b-128 hash\ndata = b\"Hello, World!\"\nhash_bytes = hashlib.blake2b(data, digest_size=16).digest()\n# Result: b'\\x38\\x95\\xc5\\x9e\\x4a\\xeb\\x09\\x03\\x39\\x6b\\x5b\\xe3\\xfb\\xec\\x69\\xfe'\n\n# 2. Keep first 12 bytes (most significant 96 bits)\ntruncated = hash_bytes[:12]\n\n# 3. Pad with 4 zero bytes at the beginning\npadded = b'\\x00\\x00\\x00\\x00' + truncated\n\n# 4. Interpret as u128 big-endian\nvalue = int.from_bytes(padded, byteorder='big')\n# Result: 17512223723299011049621773283\n\n# 5. Apply scale 18 (divide by 10^18)\nresult = Decimal(value) / Decimal(10**18)\n# Result: Decimal('17512223723.299011049621773283')JavaScript Exampleconst crypto = require('crypto');\n\n// 1. Compute BLAKE2b-128 hash\nconst hash = crypto.createHash('blake2b512')\n .update('Hello, World!')\n .digest()\n .slice(0, 16); // Take first 16 bytes for BLAKE2b-128\n\n// 2. Keep first 12 bytes\nconst truncated = hash.slice(0, 12);\n\n// 3. Pad with 4 zero bytes at the beginning\nconst padded = Buffer.concat([Buffer.alloc(4), truncated]);\n\n// 4. Interpret as big-endian u128\nlet value = 0n;\nfor (let i = 0; i < 16; i++) {\n value = (value << 8n) | BigInt(padded[i]);\n}\n// Result: 17512223723299011049621773283n\n\n// 5. Apply scale 18 (divide by 10^18)\nconst result = Number(value) / 1e18;\n// Result: 17512223723.299011 (note: JS loses precision beyond ~15 digits)Rust Exampleuse blake2::{Blake2b, Digest};\nuse blake2::digest::consts::U16;\nuse rust_decimal::Decimal;\n\ntype Blake2b128 = Blake2b<U16>;\n\n// 1. Compute BLAKE2b-128 hash\nlet mut hasher = Blake2b128::new();\nhasher.update(b\"Hello, World!\");\nlet hash = hasher.finalize();\n\n// 2. Keep first 12 bytes and pad at beginning\nlet mut bytes = [0u8; 16];\nbytes[4..16].copy_from_slice(&hash[0..12]);\n\n// 3. Interpret as big-endian u128\nlet value = u128::from_be_bytes(bytes);\n// Result: 17512223723299011049621773283\n\n// 4. Apply scale 18 (convert with 18 decimal places)\nlet result = Decimal::from_i128_with_scale(value as i128, 18);\n// Result: Decimal(\"17512223723.299011049621773283\")Why This Approach?✅ Cryptographic Standard: Follows the same truncation method as SHA-224, BLAKE2s-128, etc. ✅ Preserves Entropy: Keeps the most significant/diverse bits of the hash ✅ Big-Endian: Standard convention for cryptographic hash representations ✅ Fits Decimal Range: 96 bits always fits within Decimal's mantissa (max 2^96-1) ✅ Scale 18: Prevents precision loss when protocol rescales values ✅ Reproducible: Simple algorithm implementable in any programming language ✅ Deterministic: Same input always produces same outputExample: Hash a static string{\n \"blake2b128Task\": {\n \"value\": \"Hello, World!\"\n }\n}Example: Hash the output from a previous task (e.g., HTTP response){\n \"tasks\": [\n {\n \"httpTask\": {\n \"url\": \"https://example.com/data\"\n }\n },\n {\n \"blake2b128Task\": {}\n }\n ]\n}FieldTypeDescriptionvaluestringOptional value to hash. If not provided or empty, will use the previous task output.CacheTaskExecute a job and store the result in a variable to reference later.Input: NoneReturns: The inputExample: CacheTask storing ${ONE} = 1{\n \"cacheTask\": {\n \"cacheItems\": [\n {\n \"variableName\": \"ONE\",\n \"job\": {\n \"tasks\": [\n {\n \"valueTask\": {\n \"value\": 1\n }\n }\n ]\n }\n }\n ]\n }\n}FieldTypeDescriptioncache_itemsCacheItemA list of cached variables to reference in the job with ${VARIABLE_NAME}.CacheItem fieldsFieldTypeDescriptionvariable_namestringThe name of the variable to store in cache to reference later with ${VARIABLE_NAME}.jobOracleJobThe OracleJob to execute to yield the value to store in cache.ComparisonTaskCompare two values and return one of two results.Input: LHS/RHS values or jobs, plus on_true/on_false outputs.Returns: The value produced by on_true or on_false (or on_failure if evaluation fails).Example: Return 1 if lhs > rhs else 0{\n \"comparisonTask\": {\n \"op\": \"OPERATION_GT\",\n \"lhsValue\": \"10\",\n \"rhsValue\": \"5\",\n \"onTrueValue\": \"1\",\n \"onFalseValue\": \"0\"\n }\n}FieldTypeDescriptionopOperationThe type of operator to use on the left (lhs) and right (rhs) operand.lhsOracleJobOracleJob where the executed result is equal to the left hand side operand.lhs_valuestringString or ${CACHE_KEY} representing the left hand side operand.rhsOracleJobOracleJob where the executed result is equal to the right hand side operand.rhs_valuestringString or ${CACHE_KEY} representing the right hand side operand.on_trueOracleJobThe OracleJob to execute if the condition evaluates to true.on_true_valuestringThe result to use if the condition evaluates to true. Can be set to a ${CACHE_KEY}.on_falseOracleJobThe OracleJob to execute if the condition evaluates to false.on_false_valuestringThe result to use if the condition evaluates to false. Can be set to a ${CACHE_KEY}.on_failureOracleJobThe OracleJob to execute if the condition fails to evaluate.on_failure_valuestringThe result to use if the condition fails to evaluate. Can be set to a ${CACHE_KEY}.ConditionalTaskThis task will run the attempt on the subtasks in an effort to produce a valid numerical result. If attempt. fails to produce an acceptable result, on_failure subtasks will be run instead.Input: The current running numerical result output from a task.Returns: A numerical result, else run on_failure subtasks.Example: Returns the numerical result from the conditionalTask's subtasks, else on_failure returns the numerical result from its subtasks.{\n \"conditionalTask\": {\n \"attempt\": [\n {\n \"tasks\": [\n {\n \"jupiterSwapTask\": {\n \"inTokenAddress\": \"EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v\",\n \"outTokenAddress\": \"DUALa4FC2yREwZ59PHeu1un4wis36vHRv5hWVBmzykCJ\"\n }\n }\n ]\n }\n ],\n \"onFailure\": [\n {\n \"lpExchangeRateTask\": {\n \"orcaPoolAddress\": \"7yJ4gMRJhEoCR48aPE3EAWRmCoygakik81ZS1sajaTnE\"\n }\n }\n ]\n }\n}FieldTypeDescriptionattemptTaskA list of subtasks to process in an attempt to produce a valid numerical result.on_failureTaskA list of subtasks that will be run if attempt subtasks are unable to produce an acceptable result.SecretsTaskDeprecated compatibility task for the legacy Switchboard secrets-server flow.SecretsTask is no longer officially supported. The hosted secrets service has been taken down, and new integrations should use variableOverrides to inject API keys and other authentication credentials at request time.See the Data Feed Variable Overrides guide for the supported pattern.Input: NoneReturns: The inputExample: Legacy SecretsTask{\n \"secretsTask\": {\n \"authority\": \"Accb21tUCWocJea6Uk3DgrNZawgmKegDVeHw8cGMDPi5\"\n }\n}FieldTypeDescriptionauthoritystringThe authority of the secrets that are to be requested.urlstringLegacy server URL override for historical or self-hosted deployments. The old hosted default at https://api.secrets.switchboard.xyz is no longer available.SysclockOffsetTaskReturn the difference between an oracle's clock and the current timestamp at SYSVAR_CLOCK_PUBKEY.UnixTimeTaskGet current time in seconds since Unix epoch.FieldTypeDescriptionoffsetint32The offset to subtract from the current time.ValueTaskReturns a specified value.Input: NoneReturns: A numerical result.Example: Returns the value 10{\n \"valueTask\": {\n \"value\": 10\n }\n}Example: Returns the currentRound result of an aggregator{\n \"valueTask\": {\n \"aggregatorPubkey\": \"GvDMxPzN1sCj7L26YDK2HnMRXEQmQ2aemov8YBtPS7vR\"\n }\n}Example: Returns the value stored in a CacheTask variable{\n \"valueTask\": {\n \"big\": \"${ONE}\"\n }\n}FieldTypeDescriptionvaluedoubleThe value that will be returned from this task.aggregator_pubkeystringSpecifies an aggregatorr to pull the value of.bigstringA stringified big.js. Accepts variable expansion syntax.hexstringA stringified hex number (0x prefix is optional).Protocol-SpecificAftermathTaskFetch a spot swap quote from an Aftermath pool on Sui.Input: Pool address, input amount, and coin types for the swap.Returns: The estimated output amount for the given input.Example: Quote a swap in an Aftermath pool{\n \"aftermathTask\": {\n \"poolAddress\": \"0xPOOL_OBJECT_ID\",\n \"inAmount\": 1,\n \"inCoinType\": \"0x2::sui::SUI\",\n \"outCoinType\": \"0x...::coin::COIN\"\n }\n}FieldTypeDescriptionpool_addressstringThe Aftermath pool object ID.in_amountdoubleThe input amount to quote.in_coin_typestringThe full Sui coin type for the input token.out_coin_typestringThe full Sui coin type for the output token.BitFluxTaskFetch the current swap price from a BitFlux pool.Input: NoneReturns: The swap price between the specified input and output tokens.Example: Fetch the swap price using a custom RPC provider{\n \"bitFluxTask\": {\n \"provider\": \"https:","tokens":15000,"squid":"spider-08","role":"Oracle Spider","at":1791338428677,"hash":"189276d3b1d3093acd8f347045e16a2e8073666c"}
{"url":"https://forum.arbitrum.foundation/","domain":"forum.arbitrum.foundation","title":"Arbitrum - Arbitrum Governance Forum","text":"The Arbitrum Foundation notified the Security Council on the need to perform a potential Emergency action. Following a review of the details and known risks, the Security Council decided to execute the upgrade and it was completed at 11:30 EST on 2nd October 2026.\nThis report provides an overview of the risks that required the Security Council Action:\n\nAdd a permissionless guard for the One-Step Proof of BoLD on Arbitrum One\n\nTemporarily pause activation of new Stylus contracts on Arbitrum One & Nova\n\nKey point: To date, known bugs for Stylus primarily impact chain liveness (e.g., denial of service attacks) and do not put any user funds at risk.\nWhy was this action taken\nLet’s take this opportunity to explain why action was taken on two separate issues concerning BoLD and Stylus.\nInstalling the guard for One-Step Proof of BoLD. Given the rise of AI-assisted attacks, we have implemented a precautionary approach that allows anyone to pause settlement of Arbitrum One on Ethereum if there are at least two conflicting answers that pass at the same level in which only one should be valid and pass. This is to halt a class of publicly verifiable and detectable attacks that exploit a bug in the one-step proof. If halted, Arbitrum One will continue to process as normal except that messages from Arbitrum One to Ethereum, such as withdrawals, that are not yet confirmed will have to wait. This provides time for the Security Council to deploy a fix for the bug and resume the rollup.\nPreventing activation of new Stylus contracts. AI-assisted tooling has led to an increasing number of sophisticated attacks on hand-crafted WASM programs that do not use the standard Stylus compiler toolchain. These programs are specifically designed to cause unexpected behaviors such as degrading the chain’s performance for all other users. To date, no attacks have been discovered that permits theft of user funds.\nNew ArbOS releases have patched several reported bugs and known attacks over the past few months, but out of an abundance of caution, we have decided to temporarily pause new activations of Stylus contracts. This was executed as an emergency action to prevent the deployment of new hand-crafted WASM programs that are not yet patched by the current version of ArbOS on the Arbitrum network.\nThe Arbitrum Foundation has informed the Security Council that they will work with the ArbitrumDAO to discuss next steps on the timeline and manner for enabling activation of new Stylus contracts. The Arbitrum community remains confident in the value of Stylus and want to preserve these use cases while taking preventative measures against Stylus-based attack vectors as AI-assisted attack tooling continues to evolve.\nImpact on builders and users\n\nNo new activations. New Stylus contracts cannot be activated during the pause including new versions of existing applications that require activation.\n\nExisting contracts are not paused. Already-active Stylus contracts continue to execute until expiration. This pause does not deactivate them.\n\nThe ArbOS 61 upgrade renewed all active contracts on Arbitrum One, so no currently active contract expires before August 20, 2027.\n\nRenewal via keepalive stays permissionless and is unaffected by the pause.\n\nReactivating an expired contract, or one that needs to be updated after a Stylus version change, is paused.\n\nUsing/calling any activated Stylus contract stays permissionless for all users and developers.\n\nNo impact on EVM. Solidity (EVM) contract deployment and execution are unaffected by this Security Council action.\n\nSecurity Council Actions\nThere are two actions bundled into a single payload:\n\nOne-Step Proof Guard. The L1UpgradeExecutor gives a new pause contract (PauseExecutor) the ability to pause and nothing else. The new pause contract grants the guard (OspSoundnessGuard) PAUSER_ROLE to use it. Anyone can show the guard two conflicting answers to the same step of an open challenge. If the one-step proof accepts both, the guard has the pause contract put Arbitrum One’s settlement to Ethereum on hold.\n\nStylus deactivation. The Security Council called ArbOwner.setWasmActivationGas(2^64 - 1) to raise the Stylus activation gas requirement on Arbitrum One and Nova. This makes activation prohibitively expensive and effectively disables new activations. This is a configuration change and does not require an ArbOS upgrade.\n\nThe Security Council signed the following transactions to update the configuration:\n\nEthereum: Ethereum Transaction Hash: 0x30732bb7d2... | Etherscan\nArbitrum One:\nArbitrum One Transaction Hash: 0x9eb3a4be3b... | Arbitrum One\nArbitrum Nova:\nArbitrum Nova transaction 0x79e0fed470dff7a22059b108e3f8f42eddd2b580a6771594060c4e7326c5f984 | Blockscout\n\nAn external audit was conducted for the OSP Guard contracts. No audit is required for the Stylus deactivation as it is only updating a single parameter in the ArbOS configuration.\n\n All categories\n\n categories\n\n tags\n\n Categories\n\n Latest\n\n Top\n\n Category\n Topics\n Latest\n\n Announcements\n\n Announcements for important items, events and initiatives in the ArbitrumDAO.\n\n 1 / month\n\n The ArbitrumDAO’s Procedures\n\n Apr 16\n\n The ArbitrumDAO Code of Conduct\n\n Apr 16\n\n Arbitrum Security Program is Live: Applications Now Open\n\n 8d\n\n Proposals\n\n Review community-submitted proposals that await voting by the DAO.\n\n Active AIPs\n\n Finalized AIPs\n\n 2 / month\n\n The Incomplete Guide to Submitting a Proposal to Arbitrum DAO\n\n Apr 2024\n\n How to submit a DAO Proposal\n\n Apr 2023\n\n [CONSTITUTIONAL]: Establish an L1 Voting Recovery System \n\n 5h\n\n Voting Rationale & Governance Calls\n\n Keep abreast about a delegate’s voting record and upcoming governance calls.\n\n Weekly Voting Reminders & Updates\n\n Biweekly Proposals Discussions Call\n\n Governance Reporting Call (GRC)\n\n Delegate Statements\n\n 5 / month\n\n How to add an event to the ArbitrumDAO Governance Community Calendar\n\n May 2024\n\n October 6, 2026 - Open Discussion of Proposals Governance Call\n\n 1d\n\n September 22, 2026 - Open Discussion of Proposals Governance Call\n\n 1d\n\n DAO Programs & Initiatives\n\n Grant programs can share significant updates and run initiatives for the broader community.\n\n Arbitrum Gaming Ventures (AGV)\n\n Domain Allocator Offerings (prev Questbook)\n\n Entropy Advisors Updates\n\n Stylus Sprint Program\n\n Operation Company (OpCo)\n\n Arbitrum Treasury Management Council\n\n DeFi Renaissance Incentive Program (DRIP)\n\n Watchdog Program\n\n Rewarding Active Delegates Program (RAD)\n\n Arbitrum Audit Program (AAP)\n\n Token Flow Report\n\n 13 / month\n\n DRIP Season 2 Is Live\n\n 13h\n\n AGDAO x Arbitrum: Meta GameFi Growth Sprint 2026 - Final Report\n\n 13h\n\n MoTZ × Arbitrum — Campaign Final Report\n\n 13h\n\n Early Idea Discussion\n\n Dedicated to contributors for exploring new ideas that the DAO may want to pursue in the future.\n\n 20\n\n Join the Telegram Arbitrum DAO Delegates private group chat\n\n Feb 2025\n\n [RFC] Operational Mandate: Arbitrum Stylus Developer Impact Oracle & Sybil-Resistant ROI Matrix\n\n 12d\n\n Does your runway number assume you can sell the treasury at spot?\n\n 22d\n\n Technical Discussion\n\n Discussion about the Arbitrum technology stack.\n\n 3 / month\n\n Question: How would sequencer decentralization affect Arbitrum users?\n\n 5d\n\n Security Council key exposure across three chains — draft for review\n\n 13d\n\n Practical examples of how Stylus and Orbit help developers\n\n 19d\n\n Applications for DAO programs\n\n Dedicated to advertising new opportunities for DAO approved programs.\n\n 10\n\n Rewarding Active Delegates (RAD) Program - Application Thread\n\n Aug 27\n\n Oversight and Transparency Committee (OAT) - June 2026 Elections Application Thread\n\n Jun 15\n\n Firestarter Grant Program - Info & Application\n\n Jan 15\n\n Security Council\n\n Information about the Security Council and the regular elections.\n\n Security Council Elections\n\n 1 / month\n\n Security Council Emergency Action – 2/10/2026\n\n 4d\n\n Non-Emergency Security Action to Correct Total DVP\n\n Jul 23\n\n Non-emergency action to facilitate key rotation of Security Council - July 2026\n\n Jul 17\n\n General\n\n Create topics here that don’t fit into any other existing category.\n\n 3 / month\n\n Welcome to Discourse\n\n Mar 22\n\n The Arbitrum Expansion Program and Developer Guild\n\n Aug 2025\n\n StableGuard by FintechCheck: Real-Time Stablecoin Depeg Detection for Treasury & DeFi Protection\n\n 3d\n\n Archive\n\n Categories, posts, and other initiatives, whose posts should be preserved.\n\n Delegate Incentives Program (DIP)\n\n Strategic Objective Settings (SOS)\n\n Firestarters\n\n DAO Event Budget\n\n Sales Pitch by Service Providers\n\n Guides & Documentation\n\n Short Term Incentives Program (STIP) Round 2\n\n Governance Discussion\n\n Report Misuse of Funds\n\n STEP Applications & Updates\n\n ArbitrumDAO Procurement Committee (ADPC)\n\n Multi-Sig Support Service (MSS) Updates\n\n ThankARB by Thrive (prev Plurality Labs)\n\n Treasury Mgmt v1.2 - TM Track (ARB and Stables)\n\n Treasury Management v1.2 - GM Track (ETH)\n\n Grants Discussions\n\n Arbitrum Research & Development Collective\n\n ARDC Security Member\n\n ARDC Risk Member\n\n ARDC Research Member\n\n ARDC DAO Advocate (old)\n\n Biweekly Updates (STIP)\n\n ARDC Supervisory Council\n\n (Re)delegation Week\n\n Long Term Incentives Pilot Program (LTIPP)\n\n LTIPP Bounties\n\n GovHack Brussels\n\n PL Data Monitoring Procurement\n\n GovHack Denver\n\n Short Term Incentives Program (STIP) Round 1\n\n STIP Bridge Addendum\n\n Uniswap-Arbitrum Grant Program (UAGP)\n\n Archived Proposals\n\n Archived Announcements\n\n 1.3k\n\n Independent verification review of Arbitrum — 17 onchain checks, credit-first\n\n 19d\n\n AIE - Wallet Insight | Multichain Wallet Analysis - Full Public Case Study\n\n Aug 10\n\n [PROPOSAL] Nexus Watch by VeriOmnion: Real-Time Financial Integrity & Institutional Signal\n\n Aug 3","tokens":2437,"squid":"spider-07","role":"Council Spider","at":1791338437046,"hash":"0fffc2624ae35aba17016871ba05e3eea1770726"}
{"url":"https://docs.across.to/tools","domain":"docs.across.to","title":"Tools | Across Docs","text":"ToolsTools and utilities for working with Across Protocol.Available Tools\nStatus TrackerTrack the lifecycle of any Across deposit by transaction hash or deposit ID.Token CheckerCheck if Across supports your token across all chains.Chain CheckerCheck if Across supports your chain by ID or name.Transaction BuilderBuild crosschain swap + action requests for the Across API.Get API Key & Integrator IDRegister your project to get an Across API key and integrator ID.AI Transaction BuilderDescribe your crosschain transfer in plain English and get a ready-to-use API call.Status TrackerTrack the status of your Across deposit by transaction hash or deposit ID.","tokens":164,"squid":"spider-09","role":"Bridge Spider","at":1791338438266,"hash":"4924bcb740cdcc7dc9702d62653613906acbca2e"}
{"url":"https://docs.switchboard.xyz/docs-by-chain/evm","domain":"docs.switchboard.xyz","title":"EVM | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.Learn how to build and use programs that call Switchboard data feeds on EVM chains like Ethereum, Monad, and Hyperliquid.If you need to create a custom data feed, check out the custom feeds section.If you are integrating a Feed Builder feed or any bytes32 feed ID from the explorer on EVM, use the v2 feed-hash flow:Fetch the definition with /v2/fetch/{feedId}Simulate with /v2/simulate/{feedHashes} or CrossbarClient.simulateFeed(...)Build the on-chain payload with /v2/update/{feedHashes}?chain=evm&network=mainnet|testnet&use_timestamp=trueThe legacy /simulate/evm and /updates/evm routes are only for older aggregator-based integrations.Monad Example Network SwitchThe packaged Monad examples in sb-on-demand-examples/evm now share one network selector:NETWORK=monad-testnetNETWORK=monad-mainnetRPC_URL remains optional as an override, but the example scripts now verify that it matches the selected network before they broadcast transactions. The Monad guides under this section use that shared env contract.DeploymentsThe Switchboard contract has been deployed to the following EVM networks:ChainNetworkChain IDAddressArbitrumMainnet421610xAd9b8604b6B97187CDe9E826cDeB7033C8C37198ArbitrumSepolia4216140xA2a0425fA3C5669d384f4e6c8068dfCf64485b3bCoreMainnet11160x33A5066f65f66161bEb3f827A3e40fce7d7A2e6CCoreTestnet11140x2f833D73bA1086F3E5CDE9e9a695783984636A76HyperEVMMainnet9990xcDb299Cb902D1E39F83F54c7725f54eDDa7F3347MonadMainnet1430xB7F03eee7B9F56347e32cC71DaD65B303D5a0E67MonadTestnet101430x6724818814927e057a693f4e3A172b6cC1eA690CMorphMainnet-0x33A5066f65f66161bEb3f827A3e40fce7d7A2e6CMorphHolesky-0x3c1604DF82FDc873D289a47c6bb07AFA21f299e5PreviousX402 TutorialNextPrice FeedsLast updated 6 months ago","tokens":451,"squid":"spider-08","role":"Oracle Spider","at":1791338438685,"hash":"3e25b19a1508ec57e755510b7d88ade04defc6e9"}
{"url":"https://docs.switchboard.xyz/docs-by-chain/evm/surge","domain":"docs.switchboard.xyz","title":"Surge Price Feeds | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.Version source of truth: SDK Version MatrixThe Future of Oracle TechnologySwitchboard Surge is the industry's fastest oracle data delivery system, providing sub-100ms latency through direct WebSocket streaming. Built for the next generation of DeFi applications, trading systems, and real-time dashboards.Key InnovationTraditional oracles require multiple steps—gathering prices, writing to blockchain state, reaching consensus, and then making data available—resulting in 2-10 seconds of latency.Switchboard oracles must pass a hardware proof when joining the network, ensuring they run only verified Switchboard code. This allows oracles to stream price data directly from sources to your application via WebSocket, achieving sub-100ms latency.┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐\n│ Price Sources │────▶│ Oracle Network │────▶│ Surge Gateway │\n│ (CEX, DEX) │ │ (SAIL Verified) │ │ (WebSocket) │\n└──────────────────┘ └──────────────────┘ └────────┬─────────┘\n │\n ┌──────────▼──────────┐\n │ Your Application │\n │ • Event Listeners │\n │ • Price Handlers │\n │ • EVM Converter │\n └─────────────────────┘Key FeaturesUnmatched Performance — Sub-100ms latency with direct WebSocket streaming and event-driven updates. No polling required.Zero Setup — No data feed accounts or on-chain deployment needed. Just use your Solana keypair (subscription owner) and connection to start streaming.Cost Efficiency — Subscription-based pricing with no gas fees for receiving updates. Reduced on-chain costs when submitting to contracts.Seamless Integration — TypeScript/JavaScript SDK, WebSocket API for any language, and EVM format conversion for on-chain use.Enterprise-Grade Reliability — 99.9% uptime SLA with global infrastructure, automatic failover, and professional support.User FlowSurge works the same way regardless of your target chain:Subscribe — All Surge subscriptions are managed on Solana, regardless of which chain you're building on. Connect your Solana wallet at the subscription portal.Authenticate — The SDK authenticates your session by signing with your Solana keypair. If the keypair does not have an active subscription, connectAndSubscribe will fail.Stream Prices — Once subscribed, prices stream directly to your application via WebSocket. No on-chain reads required—this is what enables sub-100ms latency.Use Prices — When you need prices on-chain, convert the Surge update to your chain's format and submit it. Switchboard provides SDKs for Solana, EVM, and Sui.Getting Started1. SubscribeConnect your wallet and subscribe at explorer.switchboardlabs.xyz/subscriptions. If you are an AI agent or wish to subscribe programmatically rather than through the UI, see the Surge Subscription Guide.2. Install the SDKnpm install @switchboard-xyz/on-demand@3.10.6 @switchboard-xyz/common@5.8.5\n# or\nyarn add @switchboard-xyz/on-demand@3.10.6 @switchboard-xyz/common@5.8.53. Connect and Streamimport * as sb from \"@switchboard-xyz/on-demand\";\nimport { EVMUtils } from \"@switchboard-xyz/common\";\n\n// Initialize with Solana keypair and connection (uses on-chain subscription)\nconst surge = new sb.Surge({ connection, keypair }); // keypair = Solana keypair with active Surge subscription\n// `connection` is a Solana RPC Connection from @solana/web3.js, not an EVM provider.\n\n// Auth note: the SDK signs with your keypair to authenticate the session.\n// If the keypair has no active Surge subscription, connectAndSubscribe will fail.\n\n// Discover available feeds\nconst availableFeeds = await surge.getSurgeFeeds();\nconsole.log(`${availableFeeds.length} feeds available`);\n\n// Subscribe to specific feeds\nawait surge.connectAndSubscribe([\n { symbol: 'BTC/USD' },\n { symbol: 'ETH/USD' },\n]);\n\n// Handle price updates\nsurge.on('signedPriceUpdate', (response: sb.SurgeUpdate) => {\n const metrics = response.getLatencyMetrics();\n if (metrics.isHeartbeat) return;\n\n const prices = response.getFormattedPrices();\n metrics.perFeedMetrics.forEach((feed) => {\n console.log(`${feed.symbol}: ${prices[feed.feed_hash]}`);\n\n // Convert to EVM format when needed for on-chain use\n const evmEncoded = EVMUtils.convertSurgeUpdateToEvmFormat(response.getRawResponse());\n });\n});Pricing & LimitsPlanPriceQuote IntervalMax FeedsMax ConnectionsPlugFree10s21Pro~$3,000/mo450ms10010Enterprise~$7,500/mo0ms30015Subscriptions are paid in SWTCH tokens. For custom limits or dedicated support, contact sales@switchboard.xyz.Primary Use CasesPerpetual ExchangesSurge is the perfect oracle solution for perpetual trading platforms:surge.on('signedPriceUpdate', async (response: sb.SurgeUpdate) => {\n const metrics = response.getLatencyMetrics();\n if (metrics.isHeartbeat) return;\n\n const prices = response.getFormattedPrices();\n\n for (const feed of metrics.perFeedMetrics) {\n const price = parseFloat(prices[feed.feed_hash].replace(/[$,]/g, ''));\n\n // Update mark price instantly\n await updateMarkPrice(feed.symbol, price);\n\n // Check for liquidations with latest price\n const liquidations = await checkLiquidations(feed.symbol, price);\n if (liquidations.length > 0) {\n const evmEncoded = EVMUtils.convertSurgeUpdateToEvmFormat(response.getRawResponse());\n await executeLiquidations(liquidations, evmEncoded);\n }\n }\n});Oracle-Based AMMsBuild the next generation of AMMs that use real-time oracle prices:class OracleAMM {\n private latestUpdate: sb.SurgeUpdate;\n\n async handlePriceUpdate(response: sb.SurgeUpdate) {\n const metrics = response.getLatencyMetrics();\n if (metrics.isHeartbeat) return;\n\n this.latestUpdate = response;\n const prices = response.getFormattedPrices();\n\n for (const feed of metrics.perFeedMetrics) {\n const pair = this.pairs.get(feed.symbol);\n pair.oraclePrice = parseFloat(prices[feed.feed_hash].replace(/[$,]/g, ''));\n pair.lastUpdate = Date.now();\n }\n }\n\n async executeSwap(tokenIn: string, tokenOut: string, amountIn: number) {\n const pair = `${tokenIn}/${tokenOut}`;\n const latestPrice = this.pairs.get(pair).oraclePrice;\n const amountOut = amountIn * latestPrice * (1 - this.swapFee);\n\n const evmEncoded = EVMUtils.convertSurgeUpdateToEvmFormat(this.latestUpdate.getRawResponse());\n return await this.contract.swap(amountIn, amountOut, evmEncoded);\n }\n}High-Frequency Trading & Arbitragesurge.on('signedPriceUpdate', async (response: sb.SurgeUpdate) => {\n const metrics = response.getLatencyMetrics();\n if (metrics.isHeartbeat) return;\n\n const prices = response.getFormattedPrices();\n\n for (const feed of metrics.perFeedMetrics) {\n const oraclePrice = parseFloat(prices[feed.feed_hash].replace(/[$,]/g, ''));\n const dexPrice = await getDexPrice(feed.symbol);\n\n const spread = Math.abs(dexPrice - oraclePrice) / oraclePrice;\n if (spread > MIN_PROFIT_THRESHOLD) {\n const evmEncoded = EVMUtils.convertSurgeUpdateToEvmFormat(response.getRawResponse());\n await executeArbitrage(evmEncoded, calculateOptimalSize(spread));\n }\n }\n});Liquidation Enginessurge.on('signedPriceUpdate', async (response: sb.SurgeUpdate) => {\n const metrics = response.getLatencyMetrics();\n if (metrics.isHeartbeat) return;\n\n const prices = response.getFormattedPrices();\n\n for (const feed of metrics.perFeedMetrics) {\n const price = parseFloat(prices[feed.feed_hash].replace(/[$,]/g, ''));\n const positions = await getPositionsByCollateral(feed.symbol);\n\n for (const position of positions) {\n const ltv = calculateLTV(position, price);\n if (ltv > LIQUIDATION_THRESHOLD) {\n const evmEncoded = EVMUtils.convertSurgeUpdateToEvmFormat(response.getRawResponse());\n await liquidatePosition(position, evmEncoded);\n }\n }\n }\n});Technical SpecificationsLatency BreakdownOracle processing: ~10msNetwork transmission: ~20-50msClient processing: ~10msTotal: <100msDiscovering Available FeedsUse the getSurgeFeeds() method to see all available trading pairs:const surge = new sb.Surge({ connection, keypair }); // Solana keypair with active Surge subscription\n// `connection` is a Solana RPC Connection from @solana/web3.js, not an EVM provider.\nconst feeds = await surge.getSurgeFeeds();\n\nfeeds.forEach(feed => {\n console.log(`${feed.symbol}`);\n});Supported AssetsAll major cryptocurrency pairsMultiple exchange sources availableNew pairs added regularlyCustom feeds available on requestNote: Surge does not support custom feeds created with the feed builder.FAQHow is Surge different from traditional oracles?Surge streams data directly to your application via WebSocket, bypassing the blockchain entirely for reads. This eliminates gas costs and reduces latency from seconds to milliseconds.Can I use Surge data on-chain?Yes! Surge updates can be converted to EVM-compatible format using EVMUtils.convertSurgeUpdateToEvmFormat() and submitted to your smart contracts.What's the reliability?Surge operates with 99.9% uptime SLA, automatic failover, and global redundancy. Enterprise customers get dedicated infrastructure.How do I handle disconnections?The SDK includes automatic reconnection logic with exponential backoff. Your application will seamlessly recover from network interruptions.Next StepsSurge Tutorial - Step-by-step implementation guideCrossbar Gateway - Stream prices to your frontendSurge Gateway Protocol - Advanced HTTP + WebSocket protocolExplore code examplesJoin our DiscordPreviousPrice Feeds TutorialNextSurge TutorialLast updated 2 months ago","tokens":2336,"squid":"spider-08","role":"Oracle Spider","at":1791338450764,"hash":"98b5162afe4855599f075bb4835856e9db123a9c"}
{"url":"https://forum.arbitrum.foundation/t/how-to-add-an-event-to-the-arbitrumdao-governance-community-calendar/23783/1","domain":"forum.arbitrum.foundation","title":"How to add an event to the ArbitrumDAO Governance Community Calendar - Voting Rationale & Governance Calls - Arbitrum","text":"The Arbitrum Foundation notified the Security Council on the need to perform a potential Emergency action. Following a review of the details and known risks, the Security Council decided to execute the upgrade and it was completed at 11:30 EST on 2nd October 2026.\nThis report provides an overview of the risks that required the Security Council Action:\n\nAdd a permissionless guard for the One-Step Proof of BoLD on Arbitrum One\n\nTemporarily pause activation of new Stylus contracts on Arbitrum One & Nova\n\nKey point: To date, known bugs for Stylus primarily impact chain liveness (e.g., denial of service attacks) and do not put any user funds at risk.\nWhy was this action taken\nLet’s take this opportunity to explain why action was taken on two separate issues concerning BoLD and Stylus.\nInstalling the guard for One-Step Proof of BoLD. Given the rise of AI-assisted attacks, we have implemented a precautionary approach that allows anyone to pause settlement of Arbitrum One on Ethereum if there are at least two conflicting answers that pass at the same level in which only one should be valid and pass. This is to halt a class of publicly verifiable and detectable attacks that exploit a bug in the one-step proof. If halted, Arbitrum One will continue to process as normal except that messages from Arbitrum One to Ethereum, such as withdrawals, that are not yet confirmed will have to wait. This provides time for the Security Council to deploy a fix for the bug and resume the rollup.\nPreventing activation of new Stylus contracts. AI-assisted tooling has led to an increasing number of sophisticated attacks on hand-crafted WASM programs that do not use the standard Stylus compiler toolchain. These programs are specifically designed to cause unexpected behaviors such as degrading the chain’s performance for all other users. To date, no attacks have been discovered that permits theft of user funds.\nNew ArbOS releases have patched several reported bugs and known attacks over the past few months, but out of an abundance of caution, we have decided to temporarily pause new activations of Stylus contracts. This was executed as an emergency action to prevent the deployment of new hand-crafted WASM programs that are not yet patched by the current version of ArbOS on the Arbitrum network.\nThe Arbitrum Foundation has informed the Security Council that they will work with the ArbitrumDAO to discuss next steps on the timeline and manner for enabling activation of new Stylus contracts. The Arbitrum community remains confident in the value of Stylus and want to preserve these use cases while taking preventative measures against Stylus-based attack vectors as AI-assisted attack tooling continues to evolve.\nImpact on builders and users\n\nNo new activations. New Stylus contracts cannot be activated during the pause including new versions of existing applications that require activation.\n\nExisting contracts are not paused. Already-active Stylus contracts continue to execute until expiration. This pause does not deactivate them.\n\nThe ArbOS 61 upgrade renewed all active contracts on Arbitrum One, so no currently active contract expires before August 20, 2027.\n\nRenewal via keepalive stays permissionless and is unaffected by the pause.\n\nReactivating an expired contract, or one that needs to be updated after a Stylus version change, is paused.\n\nUsing/calling any activated Stylus contract stays permissionless for all users and developers.\n\nNo impact on EVM. Solidity (EVM) contract deployment and execution are unaffected by this Security Council action.\n\nSecurity Council Actions\nThere are two actions bundled into a single payload:\n\nOne-Step Proof Guard. The L1UpgradeExecutor gives a new pause contract (PauseExecutor) the ability to pause and nothing else. The new pause contract grants the guard (OspSoundnessGuard) PAUSER_ROLE to use it. Anyone can show the guard two conflicting answers to the same step of an open challenge. If the one-step proof accepts both, the guard has the pause contract put Arbitrum One’s settlement to Ethereum on hold.\n\nStylus deactivation. The Security Council called ArbOwner.setWasmActivationGas(2^64 - 1) to raise the Stylus activation gas requirement on Arbitrum One and Nova. This makes activation prohibitively expensive and effectively disables new activations. This is a configuration change and does not require an ArbOS upgrade.\n\nThe Security Council signed the following transactions to update the configuration:\n\nEthereum: Ethereum Transaction Hash: 0x30732bb7d2... | Etherscan\nArbitrum One:\nArbitrum One Transaction Hash: 0x9eb3a4be3b... | Arbitrum One\nArbitrum Nova:\nArbitrum Nova transaction 0x79e0fed470dff7a22059b108e3f8f42eddd2b580a6771594060c4e7326c5f984 | Blockscout\n\nAn external audit was conducted for the OSP Guard contracts. No audit is required for the Stylus deactivation as it is only updating a single parameter in the ArbOS configuration.\n\n How to add an event to the ArbitrumDAO Governance Community Calendar \n\n Voting Rationale & Governance Calls\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 May 2024\n\n post by Sinkas on May 13, 2024\n\n Sinkas\n\n Arbitrum DAO has a community-run Google calendar where all important calls and events are added for the convenience of delegates and other interested parties.\nWhile any contributor in the DAO can add their event to the calendar, the access to doing so is currently gated to a few members and not open to everyone to avoid having to deal with spam or malicious links.\nBelow you’ll find a guide on how you can request for an event to be added to the ArbitrumDAO Governance Community Calendar and the information you’ll be asked to provide.\nRequesting an event to be added to the calendar\nTo add your event to the calendar, one of the admins of the calendars will need the following information:\n\nTitle: What do you want the event to be called? It should be something short and convey what the call is about.\nDescription: The description should provide some additional context for potential participants to be aware of. For example, if the call is going to discuss a specific proposal, the link to the proposal should be shared here.\nDate: What day will the event happen? Avoid using weekends unless absolutely necessary.\nTime (in UTC): What time of the day will the event take place (convert in UTC)? Keep in mind that the DAO had participants from all over the world and time differences can be a hurdle. Also, check the calendar to ensure there’s no other event at the same time as yours.\nDuration: How long will the call be? Most calls take about 1 hour, but it can be less or more than that depending on your needs.\nMeeting Link: Provide the meeting link for your event. Most events on the Arbitrum calendar use Google Meets but other apps are also welcome. Create a meeting and provide the link so you have host abilities when the event happens. Also, if you plan on recording the call, the recording will be saved in your drive.\nFrequency of the event: If you plan on creating a recurring event, let us know how often you want it to be (once a week, once a month, etc)\n\nLastly, if your event has to be edited, moved, or canceled, please notify the person who added it to the calendar so they can take the necessary actions.\nWho to reach out to?\nOnce you have the above information ready, send a message to Sinkas on Telegram. Alternatively, you can also message @AlexLumley (Telegram), @ocandocrypto (Telegram), or @cliffton.eth (Telegram).\n\nPlease do not reach out to all the above people at the same time. Allow for some reasonable response time before messaging the next person to add your event.\n\nIf you have access to the calendar but are not sure how to add an event using the information above, please refer to the information in the toggle below.\n\nAdding an event to the calendar (for people with access)\nWhen adding an event to the calendar on behalf of someone (and even for yourselves) please make sure to request the above information and use it to set up the event. That way, we can begin having a standardized format for events in the calendar.\nHow to add a different Google Meet link to an event you create:\nWhen you create an event, the link that you create when you add a Google Meeting is by default under your control. That means only you have hosting abilities, and if the call is recorded, the file will be saved in your drive.\nTo avoid having to be there to let people in, and manually make the event organise a co-host for every event you create, you can use the meeting link they’ll provide you instead of your own.\nTo do this, go through the following steps:\n\nWhen creating the event, add a Google Meeting.\nAfter it’s added, click on the drop-down menu icon at the right\n\nΚαταγραφή750×710 30.7 KB\n\nWhen the options appear, click to edit the meeting link and add the respective 9 characters from the meeting link the event organizer sent you.\n\nΚαταγραφή2752×812 37.1 KB\n\n This method only works for Google Meet events. If the event organizer has provided you with a link to a different meeting app (e.g. Zoom), do not add a Google Meet at all, and instead put the link they send you in the “Location” section.\n\n [Non-Constitutional] Let's get our huddles (aka. video calls) in order\n\n Proposal [Non-Constitutional]: Funding DAO Legal Defence and Advocacy with Defi Education Fund\n\n February 11, 2025 - Open Discussion of Proposals Governance Call\n\n 2 years later\n\n Pinned on Nov 28, 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 #2 Arbitrum Open Governance Call (31.05.2023)\n\n Biweekly Proposals Discussions Call\n\n 17\n\n 1.9k\n\n Jul 2023\n\n Interest in a monthly governance call?\n\n Voting Rationale & Governance Calls\n\n community-engagement\n\n 34\n\n 3.4k\n\n Jul 2023\n\n Want to know about community meetings\n\n General\n\n 10\n\n 191\n\n Sep 2024\n\n #5 Arbitrum Open Governance Call (23.08.2023)\n\n Biweekly Proposals Discussions Call\n\n 7\n\n 1.1k\n\n Sep 2023\n\n 8 Oct 2024 - Open Discussion of Proposals Governance Call\n\n Biweekly Proposals Discussions Call\n\n 5\n\n 173\n\n Oct 2024","tokens":2535,"squid":"spider-07","role":"Council Spider","at":1791338450846,"hash":"29b5c0b9b70957d877b15063739a2411d8490f96"}
{"url":"https://docs.switchboard.xyz/docs-by-chain/evm/monad","domain":"docs.switchboard.xyz","title":"Monad | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.Monad is the primary EVM network exercised by the current sb-on-demand-examples repo. The packaged EVM examples now share a single network switch:NETWORK=monad-testnetNETWORK=monad-mainnetIf NETWORK is unset, the examples default to monad-testnet.Network InformationNetworkChain IDDefault RPCSwitchboard ProxyMonad Testnet10143https://testnet-rpc.monad.xyz0x6724818814927e057a693f4e3A172b6cC1eA690CMonad Mainnet143https://rpc.monad.xyz0xB7F03eee7B9F56347e32cC71DaD65B303D5a0E67RPC_URL remains available as an override, but it must still resolve to the chain implied by NETWORK.Monad Mainnet Contract DetailsMonad mainnet uses an ERC1967 proxy. The address apps integrate with is the proxy at 0xB7F03eee7B9F56347e32cC71DaD65B303D5a0E67, and the user-facing ABI is the Switchboard implementation ABI.ItemValueProxy address0xB7F03eee7B9F56347e32cC71DaD65B303D5a0E67Proxy code pageMonadScan proxy codeCurrent implementation0x140E3f2E66619FE1113D971291990caC0b5b72FdImplementation code pageMonadScan implementation codeCanonical ABI@switchboard-xyz/on-demand-solidity/abis/Switchboard.jsonABI sourceSwitchboard ABI in on-demand-solidityMonadScan code visibility for the live mainnet implementation is still being repaired from the exact deployment source. Until that is finished, use the package ABI above instead of guessing from an empty or stale explorer ABI.Randomness API NoteThe current EVM randomness interface is:createRandomnesssettleRandomnessgetRandomnessrevealRandomness and getRandomnessResult are not part of the current Switchboard EVM interface on Monad.Shared Env ContractThe runnable EVM examples use the same env model:PRIVATE_KEY=0xyour_private_key_here\nNETWORK=monad-testnet\nRPC_URL=\nSWITCHBOARD_ADDRESS=Per-example contract addresses stay separate:CONTRACT_ADDRESS for evm/price-feedsCOIN_FLIP_CONTRACT_ADDRESS for evm/randomness/coin-flipPANCAKE_STACKER_CONTRACT_ADDRESS for evm/randomness/pancake-stackerGuardrailsBefore broadcasting transactions, the packaged scripts verify:NETWORK is supportedthe RPC chain ID matches NETWORKthe resolved Switchboard contract has bytecodeMonad SWITCHBOARD_ADDRESS overrides match the canonical address for the selected networkany reused contract address already has deployed bytecodeQuick Start: Price Feedsgit clone https://github.com/switchboard-xyz/sb-on-demand-examples.git\ncd sb-on-demand-examples/evm/price-feeds\nbun install\n(\n cd ../randomness/coin-flip\n [ -d lib/forge-std ] || forge install foundry-rs/forge-std --no-git --shallow\n)\nforge build\ncp .env.example .envFastest testnet path:bun run exampleIf CONTRACT_ADDRESS is unset, bun run example deploys a fresh consumer before submitting the v2 update. If you want to deploy separately first:bun run deploy\n# Save the emitted address into CONTRACT_ADDRESS in .env, then rerun:\nbun run exampleFlip to mainnet with one env var:NETWORK=monad-mainnet bun run exampleQuick Start: Coin Flipcd ../randomness/coin-flip\nbun install\n[ -d lib/forge-std ] || forge install foundry-rs/forge-std --no-git --shallow\nforge build\ncp .env.example .envRun on testnet:bun run deploySave the emitted contract address into COIN_FLIP_CONTRACT_ADDRESS, then fund the contract bankroll before the first flip. The contract accepts any positive wager, and the packaged CLI uses 0.01 MON by default:cast send $COIN_FLIP_CONTRACT_ADDRESS \\\n --rpc-url ${RPC_URL:-https://testnet-rpc.monad.xyz} \\\n --private-key $PRIVATE_KEY \\\n --value 0.01etherThen run the CLI flow:bun run flipRun on mainnet:NETWORK=monad-mainnet bun run deploy\n# Save COIN_FLIP_CONTRACT_ADDRESS in .env, fund the bankroll on mainnet, then:\nNETWORK=monad-mainnet bun run flipIntegration Exampleimport { ethers } from \"ethers\";\nimport { CrossbarClient } from \"@switchboard-xyz/common\";\n\nconst networkName = process.env.NETWORK || \"monad-testnet\";\nconst crossbarNetwork = networkName === \"monad-mainnet\" ? \"mainnet\" : \"testnet\";\nconst rpcUrl =\n process.env.RPC_URL ||\n (networkName === \"monad-mainnet\"\n ? \"https://rpc.monad.xyz\"\n : \"https://testnet-rpc.monad.xyz\");\nconst switchboardAddress =\n networkName === \"monad-mainnet\"\n ? \"0xB7F03eee7B9F56347e32cC71DaD65B303D5a0E67\"\n : \"0x6724818814927e057a693f4e3A172b6cC1eA690C\";\n\nconst provider = new ethers.JsonRpcProvider(rpcUrl);\nconst signer = new ethers.Wallet(process.env.PRIVATE_KEY!, provider);\n\nconst switchboard = new ethers.Contract(\n switchboardAddress,\n [\"function getFee(bytes[] calldata updates) external view returns (uint256)\"],\n signer\n);\n\nconst priceConsumer = new ethers.Contract(\n process.env.CONTRACT_ADDRESS!,\n [\"function updatePrices(bytes[] calldata updates, bytes32[] calldata feedIds) external payable\"],\n signer\n);\n\nconst feedHash = \"0xa0950ee5ee117b2e2c30f154a69e17bfb489a7610c508dc5f67eb2a14616d8ea\";\nconst crossbar = new CrossbarClient(\"https://crossbar.switchboard.xyz\");\n\n// Useful when validating a custom Feed Builder feed before sending a transaction.\nawait crossbar.simulateFeed(feedHash, false, undefined, crossbarNetwork);\n\nconst response = await crossbar.fetchV2Update([feedHash], {\n chain: \"evm\",\n network: crossbarNetwork,\n use_timestamp: true,\n});\n\nif (!response.encoded) {\n throw new Error(\"Crossbar returned no encoded update payload\");\n}\n\nconst updates = [response.encoded];\nconst fee = await switchboard.getFee(updates);\nconst tx = await priceConsumer.updatePrices(updates, [feedHash], { value: fee });\nawait tx.wait();Custom Feed TroubleshootingFeed Builder custom feeds do not require a separate activation or permission toggle on Monad.Use the same bytes32 feed hash/feed ID from Feed Builder or Explorer for the full v2 flow:GET /v2/fetch/{feedId}GET /v2/simulate/{feedId}?network=testnet|mainnetGET /v2/update/{feedId}?chain=evm&network=testnet|mainnet&use_timestamp=trueIf v2/fetch and v2/simulate succeed but v2/update returns ORACLE_UNAVAILABLE, the issue is not a missing deployment step or permission. It can be managed oracle/gateway availability, or oracle-side validation rejecting the feed result. Check oracle errors for RangeExceeded, especially if raw v2 maxJobRangePct was not scaled by 1e9; see Feed Parameter Units.NotesTestnet MON is available from the Monad faucet.The generic randomness helper at evm/randomness/randomness.ts still supports hyperliquid-mainnet in addition to Monad. Run it from evm/randomness after bun install, cp .env.example .env, and bun run example.PreviousRandomness TutorialNextHyperliquidLast updated 3 months ago","tokens":1624,"squid":"spider-08","role":"Oracle Spider","at":1791338464015,"hash":"3363c0a978e7610709240b0f588362735cdc0318"}
{"url":"https://forum.arbitrum.foundation/t/how-to-add-an-event-to-the-arbitrumdao-governance-community-calendar/23783/2","domain":"forum.arbitrum.foundation","title":"How to add an event to the ArbitrumDAO Governance Community Calendar - Voting Rationale & Governance Calls - Arbitrum","text":"The Arbitrum Foundation notified the Security Council on the need to perform a potential Emergency action. Following a review of the details and known risks, the Security Council decided to execute the upgrade and it was completed at 11:30 EST on 2nd October 2026.\nThis report provides an overview of the risks that required the Security Council Action:\n\nAdd a permissionless guard for the One-Step Proof of BoLD on Arbitrum One\n\nTemporarily pause activation of new Stylus contracts on Arbitrum One & Nova\n\nKey point: To date, known bugs for Stylus primarily impact chain liveness (e.g., denial of service attacks) and do not put any user funds at risk.\nWhy was this action taken\nLet’s take this opportunity to explain why action was taken on two separate issues concerning BoLD and Stylus.\nInstalling the guard for One-Step Proof of BoLD. Given the rise of AI-assisted attacks, we have implemented a precautionary approach that allows anyone to pause settlement of Arbitrum One on Ethereum if there are at least two conflicting answers that pass at the same level in which only one should be valid and pass. This is to halt a class of publicly verifiable and detectable attacks that exploit a bug in the one-step proof. If halted, Arbitrum One will continue to process as normal except that messages from Arbitrum One to Ethereum, such as withdrawals, that are not yet confirmed will have to wait. This provides time for the Security Council to deploy a fix for the bug and resume the rollup.\nPreventing activation of new Stylus contracts. AI-assisted tooling has led to an increasing number of sophisticated attacks on hand-crafted WASM programs that do not use the standard Stylus compiler toolchain. These programs are specifically designed to cause unexpected behaviors such as degrading the chain’s performance for all other users. To date, no attacks have been discovered that permits theft of user funds.\nNew ArbOS releases have patched several reported bugs and known attacks over the past few months, but out of an abundance of caution, we have decided to temporarily pause new activations of Stylus contracts. This was executed as an emergency action to prevent the deployment of new hand-crafted WASM programs that are not yet patched by the current version of ArbOS on the Arbitrum network.\nThe Arbitrum Foundation has informed the Security Council that they will work with the ArbitrumDAO to discuss next steps on the timeline and manner for enabling activation of new Stylus contracts. The Arbitrum community remains confident in the value of Stylus and want to preserve these use cases while taking preventative measures against Stylus-based attack vectors as AI-assisted attack tooling continues to evolve.\nImpact on builders and users\n\nNo new activations. New Stylus contracts cannot be activated during the pause including new versions of existing applications that require activation.\n\nExisting contracts are not paused. Already-active Stylus contracts continue to execute until expiration. This pause does not deactivate them.\n\nThe ArbOS 61 upgrade renewed all active contracts on Arbitrum One, so no currently active contract expires before August 20, 2027.\n\nRenewal via keepalive stays permissionless and is unaffected by the pause.\n\nReactivating an expired contract, or one that needs to be updated after a Stylus version change, is paused.\n\nUsing/calling any activated Stylus contract stays permissionless for all users and developers.\n\nNo impact on EVM. Solidity (EVM) contract deployment and execution are unaffected by this Security Council action.\n\nSecurity Council Actions\nThere are two actions bundled into a single payload:\n\nOne-Step Proof Guard. The L1UpgradeExecutor gives a new pause contract (PauseExecutor) the ability to pause and nothing else. The new pause contract grants the guard (OspSoundnessGuard) PAUSER_ROLE to use it. Anyone can show the guard two conflicting answers to the same step of an open challenge. If the one-step proof accepts both, the guard has the pause contract put Arbitrum One’s settlement to Ethereum on hold.\n\nStylus deactivation. The Security Council called ArbOwner.setWasmActivationGas(2^64 - 1) to raise the Stylus activation gas requirement on Arbitrum One and Nova. This makes activation prohibitively expensive and effectively disables new activations. This is a configuration change and does not require an ArbOS upgrade.\n\nThe Security Council signed the following transactions to update the configuration:\n\nEthereum: Ethereum Transaction Hash: 0x30732bb7d2... | Etherscan\nArbitrum One:\nArbitrum One Transaction Hash: 0x9eb3a4be3b... | Arbitrum One\nArbitrum Nova:\nArbitrum Nova transaction 0x79e0fed470dff7a22059b108e3f8f42eddd2b580a6771594060c4e7326c5f984 | Blockscout\n\nAn external audit was conducted for the OSP Guard contracts. No audit is required for the Stylus deactivation as it is only updating a single parameter in the ArbOS configuration.\n\n Voting Rationale & Governance Calls\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 Nov 2025\n\n May 2024\n\n post by Sinkas on May 13, 2024\n\n Sinkas\n\n Arbitrum DAO has a community-run Google calendar where all important calls and events are added for the convenience of delegates and other interested parties.\nWhile any contributor in the DAO can add their event to the calendar, the access to doing so is currently gated to a few members and not open to everyone to avoid having to deal with spam or malicious links.\nBelow you’ll find a guide on how you can request for an event to be added to the ArbitrumDAO Governance Community Calendar and the information you’ll be asked to provide.\nRequesting an event to be added to the calendar\nTo add your event to the calendar, one of the admins of the calendars will need the following information:\n\nTitle: What do you want the event to be called? It should be something short and convey what the call is about.\nDescription: The description should provide some additional context for potential participants to be aware of. For example, if the call is going to discuss a specific proposal, the link to the proposal should be shared here.\nDate: What day will the event happen? Avoid using weekends unless absolutely necessary.\nTime (in UTC): What time of the day will the event take place (convert in UTC)? Keep in mind that the DAO had participants from all over the world and time differences can be a hurdle. Also, check the calendar to ensure there’s no other event at the same time as yours.\nDuration: How long will the call be? Most calls take about 1 hour, but it can be less or more than that depending on your needs.\nMeeting Link: Provide the meeting link for your event. Most events on the Arbitrum calendar use Google Meets but other apps are also welcome. Create a meeting and provide the link so you have host abilities when the event happens. Also, if you plan on recording the call, the recording will be saved in your drive.\nFrequency of the event: If you plan on creating a recurring event, let us know how often you want it to be (once a week, once a month, etc)\n\nLastly, if your event has to be edited, moved, or canceled, please notify the person who added it to the calendar so they can take the necessary actions.\nWho to reach out to?\nOnce you have the above information ready, send a message to Sinkas on Telegram. Alternatively, you can also message @AlexLumley (Telegram), @ocandocrypto (Telegram), or @cliffton.eth (Telegram).\n\nPlease do not reach out to all the above people at the same time. Allow for some reasonable response time before messaging the next person to add your event.\n\nIf you have access to the calendar but are not sure how to add an event using the information above, please refer to the information in the toggle below.\n\nAdding an event to the calendar (for people with access)\nWhen adding an event to the calendar on behalf of someone (and even for yourselves) please make sure to request the above information and use it to set up the event. That way, we can begin having a standardized format for events in the calendar.\nHow to add a different Google Meet link to an event you create:\nWhen you create an event, the link that you create when you add a Google Meeting is by default under your control. That means only you have hosting abilities, and if the call is recorded, the file will be saved in your drive.\nTo avoid having to be there to let people in, and manually make the event organise a co-host for every event you create, you can use the meeting link they’ll provide you instead of your own.\nTo do this, go through the following steps:\n\nWhen creating the event, add a Google Meeting.\nAfter it’s added, click on the drop-down menu icon at the right\n\nΚαταγραφή750×710 30.7 KB\n\nWhen the options appear, click to edit the meeting link and add the respective 9 characters from the meeting link the event organizer sent you.\n\nΚαταγραφή2752×812 37.1 KB\n\n This method only works for Google Meet events. If the event organizer has provided you with a link to a different meeting app (e.g. Zoom), do not add a Google Meet at all, and instead put the link they send you in the “Location” section.\n\n [Non-Constitutional] Let's get our huddles (aka. video calls) in order\n\n Proposal [Non-Constitutional]: Funding DAO Legal Defence and Advocacy with Defi Education Fund\n\n February 11, 2025 - Open Discussion of Proposals Governance Call\n\n 2 years later\n\n Pinned on Nov 28, 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 #2 Arbitrum Open Governance Call (31.05.2023)\n\n Biweekly Proposals Discussions Call\n\n 17\n\n 1.9k\n\n Jul 2023\n\n Interest in a monthly governance call?\n\n Voting Rationale & Governance Calls\n\n community-engagement\n\n 34\n\n 3.4k\n\n Jul 2023\n\n Want to know about community meetings\n\n General\n\n 10\n\n 191\n\n Sep 2024\n\n #5 Arbitrum Open Governance Call (23.08.2023)\n\n Biweekly Proposals Discussions Call\n\n 7\n\n 1.1k\n\n Sep 2023\n\n 8 Oct 2024 - Open Discussion of Proposals Governance Call\n\n Biweekly Proposals Discussions Call\n\n 5\n\n 173\n\n Oct 2024","tokens":2517,"squid":"spider-07","role":"Council Spider","at":1791338464940,"hash":"4f9cad6d873ef5d8f3d046770d58e0598daef51b"}
{"url":"https://docs.across.to/api-reference","domain":"docs.across.to","title":"API Reference | Across Docs","text":"API ReferenceComplete API reference for the Across Protocol.Blast (Chain ID: 81457) — Deprecation Notice \nAcross is deprecating support for the Blast chain (Chain ID: 81457). Once it is disabled (targeting 20th July 2026), Across routes to and from Blast will stop returning quotes, and the /swap/chains endpoint will stop listing Blast as a supported chain.\nThe Across API provides programmatic access to crosschain bridging and swap functionality. Use these endpoints to get quotes, check limits, query deposit status, and more.\nServer URLs\nEnvironmentBase URLProductionhttps://app.across.to/api\nAuthentication\nAll API requests require a Bearer token passed via the Authorization header, and an integratorId query parameter.\nDon't have an API key yet? Get your API key and Integrator ID in under a minute.\nUsing API Keys\nPass your API key as a Bearer token in the Authorization header on every request.\ncurl -H \"Authorization: Bearer YOUR_API_KEY\" \\\n \"https://app.across.to/api/swap/approval?originChainId=42161&destinationChainId=8453&inputToken=0xaf88d065e77c8cC2239327C5EDb3A432268e5831&outputToken=0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913&amount=10000000&tradeType=minOutput&depositor=0xYourAddress&integratorId=0xdead\"const res = await fetch(\n \"https://app.across.to/api/swap/approval?originChainId=42161&destinationChainId=8453&inputToken=0xaf88d065e77c8cC2239327C5EDb3A432268e5831&outputToken=0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913&amount=10000000&tradeType=minOutput&depositor=0xYourAddress&integratorId=0xdead\",\n {\n headers: { Authorization: \"Bearer YOUR_API_KEY\" },\n }\n);import requests\n\nresponse = requests.get(\n \"https://app.across.to/api/swap/approval\",\n params={\n \"originChainId\": \"42161\",\n \"destinationChainId\": \"8453\",\n \"inputToken\": \"0xaf88d065e77c8cC2239327C5EDb3A432268e5831\",\n \"outputToken\": \"0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913\",\n \"amount\": \"10000000\",\n \"tradeType\": \"minOutput\",\n \"depositor\": \"0xYourAddress\",\n \"integratorId\": \"0xdead\",\n },\n headers={\"Authorization\": \"Bearer YOUR_API_KEY\"},\n)req, _ := http.NewRequest(\"GET\",\n \"https://app.across.to/api/swap/approval?originChainId=42161&destinationChainId=8453&inputToken=0xaf88d065e77c8cC2239327C5EDb3A432268e5831&outputToken=0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913&amount=10000000&tradeType=minOutput&depositor=0xYourAddress&integratorId=0xdead\",\n nil)\nreq.Header.Set(\"Authorization\", \"Bearer YOUR_API_KEY\")\nresp, _ := http.DefaultClient.Do(req)let res = reqwest::Client::new()\n .get(\"https://app.across.to/api/swap/approval?originChainId=42161&destinationChainId=8453&inputToken=0xaf88d065e77c8cC2239327C5EDb3A432268e5831&outputToken=0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913&amount=10000000&tradeType=minOutput&depositor=0xYourAddress&integratorId=0xdead\")\n .header(\"Authorization\", \"Bearer YOUR_API_KEY\")\n .send()\n .await?;uri = URI(\"https://app.across.to/api/swap/approval?originChainId=42161&destinationChainId=8453&inputToken=0xaf88d065e77c8cC2239327C5EDb3A432268e5831&outputToken=0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913&amount=10000000&tradeType=minOutput&depositor=0xYourAddress&integratorId=0xdead\")\nreq = Net::HTTP::Get.new(uri)\nreq[\"Authorization\"] = \"Bearer YOUR_API_KEY\"\nres = Net::HTTP.start(uri.hostname, uri.port, use_ssl: true) { |http| http.request(req) }\nEndpoints\nBrowse the individual endpoint pages in the sidebar for full parameter details, response schemas, and code samples.\nEarly AccessGET/swap/counterfactualGenerate a counterfactual deposit addressGasless APIGET/swap/gaslessGet a gasless quotePOST/gasless/submitSubmit a signed gasless withdrawalSwap APIGET/swap/approvalGet swap approval dataPOST/swap/approvalBuild embedded crosschain actionsGET/swap/chainsGet supported chainsGET/swap/tokensGet supported tokensGET/swap/sourcesGet supported sourcesTracking DepositsGET/depositGet all details for a single depositGET/deposit/statusTrack the lifecycle of a depositGET/depositsGet all deposits for a depositorSuggested Fees API (Legacy)GET/suggested-feesRetrieve suggested fee quoteGET/available-routesRetrieve available routesGET/limitsRetrieve current transfer limitsCreate persistent deposit addresses POSTReturns a persistent, infinite-TTL deposit address. The same request parameters always resolve to the same address, so you can request it once and reuse it. Requires an API key with the `deposit-address` permission (Bearer auth).\n\nYou don't need to hardcode which chains you can deposit from (input chains), the API response will include that information in the `supportedInputs` field including the input token to send there, and that route's min/max limits.\n\n**Strongly provide `refundAddresses`.** It is optional, but if a deposit can't be completed and no refund address was supplied, funds can only be recovered through a **manual refund process that takes significantly longer** than the automatic refund. You would need to contact Across support to initiate the manual refund.","tokens":1230,"squid":"spider-09","role":"Bridge Spider","at":1791338467711,"hash":"70b0f6c46ed8820d3d215a3cea981dc7172458c4"}
{"url":"https://docs.switchboard.xyz/docs-by-chain/aptos","domain":"docs.switchboard.xyz","title":"Aptos | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.This guide covers the setup and use of Switchboard data feeds within your project, using the Aggregator module for updating feeds and integrating Switchboard in Move.Version source of truth: SDK Version MatrixActive DeploymentsSwitchboard is currently deployed on the following networks:Mainnet:0xfea54925b5ac1912331e2e62049849b37842efaea298118b66f85a59057752b8Testnet:0x4fc1809ffb3c5ada6b4e885d4dbdbeb70cbdd99cbc0c8485965d95c2eab90935Typescript-SDK InstallationTo use Switchboard On-Demand, add the following dependencies to your project:NPMnpm install @switchboard-xyz/aptos-sdk@0.1.5 @switchboard-xyz/common@5.8.5 @aptos-labs/ts-sdk@6.1.0 --saveAdding Switchboard to Move CodeTo integrate Switchboard with Move, add the following dependencies to Move.toml:[dependencies.Switchboard]\ngit = \"https://github.com/switchboard-xyz/aptos.git\" subdir = \"on_demand/\" rev = \"mainnet\" # testnet or mainnetExample Move Code for Using Switchboard ValuesIn the example.move module, use the Aggregator and CurrentResult types to access the latest feed data.module example::switchboard_example {\n use aptos_framework::aptos_coin::AptosCoin;\n use aptos_framework::object::{Self, Object};\n use switchboard::aggregator::{Self, Aggregator, CurrentResult};\n use switchboard::decimal::Decimal;\n use switchboard::update_action;\n\n public entry fun my_function(account: &signer, update_data: vector<vector<u8>>) {\n\n // Update the feed with the provided data\n update_action::run<AptosCoin>(account, update_data);\n\n /**\n * You can use the following code to remove and run switchboard updates from the update_data vector,\n * keeping only non-switchboard byte vectors:\n *\n * update_action::extract_and_run<AptosCoin>(account, &mut update_data);\n */\n\n // Get the feed object\n let aggregator: address = @0xSomeFeedAddress;\n let aggregator: Object<Aggregator> = object::address_to_object<Aggregator>(aggregator);\n\n // Get the latest update info for the feed\n let current_result: CurrentResult = aggregator::current_result(aggregator);\n\n // Access various result properties\n let result: Decimal = aggregator::result(&current_result); // Update result\n let (result_u128, result_neg) = decimal::unpack(result); // Unpack result\n let timestamp_seconds = aggregator::timestamp(&current_result); // Timestamp in seconds\n\n // Other properties you can use from the current result\n let min_timestamp: u64 = aggregator::min_timestamp(&current_result); // Oldest valid timestamp used\n let max_timestamp: u64 = aggregator::max_timestamp(&current_result); // Latest valid timestamp used\n let range: Decimal = aggregator::range(&current_result); // Range of results\n let mean: Decimal = aggregator::mean(&current_result); // Average (mean)\n let stdev: Decimal = aggregator::stdev(&current_result); // Standard deviation\n\n // Use the computed result as needed...\n }\n}Once dependencies are configured, updated aggregators can be referenced easily.This implementation allows you to read and utilize Switchboard data feeds within Move. If you have any questions or need further assistance, please contact the Switchboard team.Creating an Aggregator and Sending TransactionsBuilding a feed in Switchboard can be done using the Typescript SDK, or it can be done with the Switchboard Web App. Visit the custom feeds section for more on designing and creating feeds.Building Feeds in Typescript [optional]import {\n CrossbarClient,\n SwitchboardClient,\n Aggregator,\n ON_DEMAND_MAINNET_QUEUE,\n ON_DEMAND_TESTNET_QUEUE,\n} from \"@switchboard-xyz/aptos-sdk\";\nimport { OracleJob } from \"@switchboard-xyz/common\";\nimport { Aptos, Account, AptosConfig, Network } from \"@aptos-labs/ts-sdk\"\n\n// get the aptos client\nconst config = new AptosConfig({\n network: Network.MAINNET, // network a necessary param / if not passed in, full node url is required\n});\n// create a SwitchboardClient using the aptos client\nconst aptos = new Aptos(config);\nconst client = new SwitchboardClient(aptos);\n\nconst crossbarClient = new CrossbarClient(\"http://myCrossbarDeployment.com\");\n\n// ... define some jobs ...\nconst jobs: OracleJob[] = [\n OracleJob.fromObject({\n tasks: [\n {\n httpTask: {\n url: \"https://binance.com/api/v3/ticker/price?symbol=BTCUSDT\",\n }\n },\n {\n jsonParseTask: {\n path: \"$.price\"\n }\n }\n ],\n }),\n];\n\nconst isMainnet = true; // set to false for testnet\nconst queue = isMainnet\n ? ON_DEMAND_MAINNET_QUEUE\n : ON_DEMAND_TESTNET_QUEUE;\n\n// Store some job definition\nconst { feedHash } = await crossbarClient.store(queue, jobs);\n\n// try creating a feed\nconst feedName = \"BTC/USDT\";\n\n// Require only one oracle response needed\nconst minSampleSize = 1;\n\n// Allow update data to be up to 60 seconds old\nconst maxStalenessSeconds = 60;\n\n// If jobs diverge more than 1%, don't allow the feed to produce a valid update\nconst maxVariance = 1e9; // 1%, scaled by 1e9 for this chain parameter\n\n// Require only 1 job response (unscaled count)\nconst minResponses = 1;\n\n//==========================================================\n// Feed Initialization On-Chain\n//==========================================================\n\n// ... get the account object for your signer with relevant key / address ...\n\n// get the signer address\nconst account = Account.generate(); // Or plug in your account\nconst signerAddress = account.accountAddress.toString();\n\nconst aggregatorInitTx = await Aggregator.initTx(client, signerAddress, {\n name: feedName,\n minSampleSize,\n maxStalenessSeconds,\n maxVariance,\n feedHash,\n minResponses,\n});\n\nconst res = await aptos.signAndSubmitTransaction({\n signer: account,\n transaction: aggregatorInitTx,\n});\n\nconst result = await aptos.waitForTransaction({\n transactionHash: res.hash,\n options: {\n timeoutSecs: 30,\n checkSuccess: true,\n },\n});\n\n// Log the transaction results\nconsole.log(result);\nUpdating Feeds// Replace with your feed ID\nconst aggregatorId = \"0x1234567890abcdef1234567890abcdef12345678\";D\nconst aggregator = new Aggregator(client, aggregatorId);\n\n// Fetch and log the oracle responses\nconst { updates } = await aggregator.fetchUpdate();\n\n// Create a transaction to run the feed update\nconst exampleAddress = \"YOUR_CONTRACT_ADDRESS\";\nconst updateTx = await client.aptos.transaction.build.simple({\n sender: signerAddress,\n data: {\n function: `${exampleAddress}::switchboard_example::my_function`,\n functionArguments: [updates],\n },\n});\n\n// Sign and submit the transaction\nconst res = await aptos.signAndSubmitTransaction({\n signer: account,\n transaction: updateTx!,\n});\n\n// Wait for the transaction to complete\nconst result = await aptos.waitForTransaction({\n transactionHash: res.hash,\n options: {\n timeoutSecs: 30,\n checkSuccess: true,\n },\n});\n\n// Log the transaction results\nconsole.log(result);(optional) Migrating existing code to On-Demand from V2 without updating logic1. Update Move.tomlYou'll need to update your Move.toml to include the new switchboard_adapter module and address. Replace the switchboard named address with the new switchboard_adapter address.[addresses]\n\n# remove the switchboard address\n- switchboard = \"0xb91d3fef0eeb4e685dc85e739c7d3e2968784945be4424e92e2f86e2418bf271\"\n\n# add the switchboard_adapter address\n+ switchboard_adapter = \"0x890fd4ed8a26198011e7923f53f5f1e5eeb2cc389dd50b938f16cb95164dc81c\"\n\n[dependencies]\n\n# remove the switchboard v2 dependency\n- [dependencies.Switchboard]\n- git = \"https://github.com/switchboard-xyz/sbv2-aptos.git\"\n- subdir = \"move/switchboard/testnet/\" # change to /mainnet/ if on mainnet - or fork and change deps for a specific commit hash\n- rev = \"main\"\n\n# add the on-demand adapter dependency\n+ [dependencies.SwitchboardAdapter]\n+ git = \"https://github.com/switchboard-xyz/aptos.git\"\n+ subdir = \"adapter/mainnet\"\n+ rev = \"main\"2. Update your Move ModulesYou'll need to update named address switchboard to switchboard_adapter in dependencies.module example::module {\n- use switchboard::aggregator;\n- use switchboard::math;\n+ use switchboard_adapter::aggregator;\n+ use switchboard_adapter::math;\n ...\n}The aggregator addresses you use will have to be updated to new On-Demand Aggregators that can be created from your V2 Aggregators on the Switchboard On-Demand App. Update references in your application to on-demand aggregators accordingly.3. CrankingOn-demand works on a pull-based mechanism, so you will have to crank feeds with your client-side code in order to get the latest data. This can be done using the Typescript SDK.import {\n Aggregator,\n SwitchboardClient,\n waitForTx,\n} from \"@switchboard-xyz/aptos-sdk\";\nimport { Account, Aptos, AptosConfig, Network } from \"@aptos-labs/ts-sdk\";\n\n// get the aptos client\nconst config = new AptosConfig({\n network: Network.MAINNET, // network a necessary param / if not passed in, full node url is required\n});\nconst aptos = new Aptos(config);\n\n// create a SwitchboardClient using the aptos client\nconst client = new SwitchboardClient(aptos);\n\nconst aggregator = new Aggregator(sb, aggregatorId);\n\n// update the aggregator every 10 seconds\nsetInterval(async () => {\n try {\n // fetch the latest update and tx to update the aggregator\n const { updateTx } = await aggregator.fetchUpdate({\n sender: signerAddress,\n });\n\n // send the tx to update the aggregator\n const tx = await aptos.signAndSubmitTransaction({\n signer: account,\n transaction: updateTx!,\n });\n const resultTx = await waitForTx(aptos, tx.hash);\n console.log(`Aggregator ${aggregatorId} updated!`);\n } catch (e) {\n console.error(`Error updating aggregator ${aggregatorId}: ${e}`);\n }\n}, 10000);PreviousSurge TutorialNextIotaLast updated 2 months ago","tokens":2394,"squid":"spider-08","role":"Oracle Spider","at":1791338474943,"hash":"96f2910fb015513da4af9c2c4a6e91084d64b5dd"}
{"url":"https://docs.across.to/chains-and-contracts","domain":"docs.across.to","title":"Chains & Contracts | Across Docs","text":"Chains & ContractsDeployed contract addresses for all supported Across chains.Blast (Chain ID: 81457) — Deprecation Notice \nAcross is deprecating support for the Blast chain (Chain ID: 81457). Once it is disabled (targeting 20th July 2026), Across routes to and from Blast will stop returning quotes, and the /swap/chains endpoint will stop listing Blast as a supported chain.\nDeployed Contracts\nAcross is deployed on 22 chains. Contract addresses are sourced from the official contracts repository.Chains Live on the Swap APIThese chains are fully supported and available for bridging via the Swap API.ChainChain IDSpokePoolSpokePoolPeripheryMulticallHandlerEthereum10x5c7B...35C50x97CC...5fD40x0F7A...3a0EArbitrum421610xe35e...5f2A0x97CC...5fD40x0F7A...3a0EARC50420x9b4A...4A840xE791...a32c0xA074...547bAvalanche431140xFE9D...a6580x97CC...5fD40x9610...c60eBase84530x09ae...EC640x97CC...5fD40x0F7A...3a0EBNB Smart Chain560x4e8E...d5050x97CC...5fD40x0F7A...3a0EHyperEVM9990x35E6...0E040x97CC...5fD40x5E78...9bbaInk570730xeF68...9dd40x97CC...5fD40x0F7A...3a0ELinea591440x7E63...ee750x97CC...5fD40xdF1C...cDa2MegaETH43260x3Db0...d40E0x97CC...5fD40xFfc1...FbE4Monad1430xd2ec...A4490x97CC...5fD40xeC41...4511Optimism100x6f26...02810x97CC...5fD40x0F7A...3a0EPlasma97450x5003...207a0x97CC...5fD40x5E78...9bbaPolygon1370x9295...F0960x97CC...5fD40x0F7A...3a0ERobinhood46630xD29C...79780x97CC...5fD4—Solana34268394551451DLv3Ng...eAru—HaQe51...V5BeSoneium18680x3baD...Dd960x97CC...5fD40x0F7A...3a0ETempo42170x2d47...955D0x97CC...5fD40x7D6A...4D90TRON728126428TTbCVP...vkmSTN88jH...1trZTQF7ow...fMDZUnichain1300x09ae...EC640x97CC...5fD40x0F7A...3a0EWorld Chain4800x09ae...EC640x97CC...5fD40x0F7A...3a0EzkSync3240xE0B0...35FF0x7C99...A57D0x68d3...5dbfEthereum#1SpokePool0x5c7B...35C5Periphery0x97CC...5fD4MulticallHandler0x0F7A...3a0EArbitrum#42161SpokePool0xe35e...5f2APeriphery0x97CC...5fD4MulticallHandler0x0F7A...3a0EARC#5042SpokePool0x9b4A...4A84Periphery0xE791...a32cMulticallHandler0xA074...547bAvalanche#43114SpokePool0xFE9D...a658Periphery0x97CC...5fD4MulticallHandler0x9610...c60eBase#8453SpokePool0x09ae...EC64Periphery0x97CC...5fD4MulticallHandler0x0F7A...3a0EBNB Smart Chain#56SpokePool0x4e8E...d505Periphery0x97CC...5fD4MulticallHandler0x0F7A...3a0EHyperEVM#999SpokePool0x35E6...0E04Periphery0x97CC...5fD4MulticallHandler0x5E78...9bbaInk#57073SpokePool0xeF68...9dd4Periphery0x97CC...5fD4MulticallHandler0x0F7A...3a0ELinea#59144SpokePool0x7E63...ee75Periphery0x97CC...5fD4MulticallHandler0xdF1C...cDa2MegaETH#4326SpokePool0x3Db0...d40EPeriphery0x97CC...5fD4MulticallHandler0xFfc1...FbE4Monad#143SpokePool0xd2ec...A449Periphery0x97CC...5fD4MulticallHandler0xeC41...4511Optimism#10SpokePool0x6f26...0281Periphery0x97CC...5fD4MulticallHandler0x0F7A...3a0EPlasma#9745SpokePool0x5003...207aPeriphery0x97CC...5fD4MulticallHandler0x5E78...9bbaPolygon#137SpokePool0x9295...F096Periphery0x97CC...5fD4MulticallHandler0x0F7A...3a0ERobinhood#4663SpokePool0xD29C...7978Periphery0x97CC...5fD4MulticallHandler—Solana#34268394551451SpokePoolDLv3Ng...eAruPeriphery—MulticallHandlerHaQe51...V5BeSoneium#1868SpokePool0x3baD...Dd96Periphery0x97CC...5fD4MulticallHandler0x0F7A...3a0ETempo#4217SpokePool0x2d47...955DPeriphery0x97CC...5fD4MulticallHandler0x7D6A...4D90TRON#728126428SpokePoolTTbCVP...vkmSPeripheryTN88jH...1trZMulticallHandlerTQF7ow...fMDZUnichain#130SpokePool0x09ae...EC64Periphery0x97CC...5fD4MulticallHandler0x0F7A...3a0EWorld Chain#480SpokePool0x09ae...EC64Periphery0x97CC...5fD4MulticallHandler0x0F7A...3a0EzkSync#324SpokePool0xE0B0...35FFPeriphery0x7C99...A57DMulticallHandler0x68d3...5dbfTestnet ChainsTestnet deployments for development and testing. Use the testnet API at https://testnet.across.to/apiTestnet LimitationsTestnet fills typically take around 1 minute, significantly slower than mainnet's sub-two second fills. This is because testnet lacks the economic incentives and relayer competition that drive mainnet's performance and reliability. We also recommend users to perform relatively smaller deposits (~$1) as relayer settlement does not occur on the testnet and unfilled deposits are not automatically refunded.Therefore we only recommend you to use testnet API to ensure your implementation of the API is correct and then switch to mainnet API and experience Across in its true form.ChainChain IDSpokePoolSpokePoolPeripheryMulticallHandlerArbitrum Sepolia4216140x7E63...ee750x10D8...B6100x0F7A...3a0EBase Sepolia845320x82B5...0F8F0x10D8...B6100x0F7A...3a0EBlast Sepolia1685877730x5545...f022—0x0F7A...3a0EBOB Sepolia8088130x3baD...Dd96—0xAC53...44d7Lens Sepolia371110x6A0a...967B—0x02D2...7822Lisk Sepolia42020xeF68...9dd4—0x0F7A...3a0EMode Sepolia9190xbd88...f83b—0x0F7A...3a0EOptimism Sepolia111554200x4e8E...d5050x10D8...B6100x0F7A...3a0EPolygon Amoy800020xd08b...e8e50x10D8...B6100x0F7A...3a0ESepolia111551110x5ef6...B6620x10D8...B6100x0F7A...3a0ESolana Devnet133268194659241JAZWcG...QBiq—Fk1Rpq...mM8hTatara1293990x09ae...EC64—0xAC53...44d7Unichain Sepolia13010x6999...A874—0x0F7A...3a0EArbitrum Sepolia#421614SpokePool0x7E63...ee75Periphery0x10D8...B610MulticallHandler0x0F7A...3a0EBase Sepolia#84532SpokePool0x82B5...0F8FPeriphery0x10D8...B610MulticallHandler0x0F7A...3a0EBlast Sepolia#168587773SpokePool0x5545...f022Periphery—MulticallHandler0x0F7A...3a0EBOB Sepolia#808813SpokePool0x3baD...Dd96Periphery—MulticallHandler0xAC53...44d7Lens Sepolia#37111SpokePool0x6A0a...967BPeriphery—MulticallHandler0x02D2...7822Lisk Sepolia#4202SpokePool0xeF68...9dd4Periphery—MulticallHandler0x0F7A...3a0EMode Sepolia#919SpokePool0xbd88...f83bPeriphery—MulticallHandler0x0F7A...3a0EOptimism Sepolia#11155420SpokePool0x4e8E...d505Periphery0x10D8...B610MulticallHandler0x0F7A...3a0EPolygon Amoy#80002SpokePool0xd08b...e8e5Periphery0x10D8...B610MulticallHandler0x0F7A...3a0ESepolia#11155111SpokePool0x5ef6...B662Periphery0x10D8...B610MulticallHandler0x0F7A...3a0ESolana Devnet#133268194659241SpokePoolJAZWcG...QBiqPeriphery—MulticallHandlerFk1Rpq...mM8hTatara#129399SpokePool0x09ae...EC64Periphery—MulticallHandler0xAC53...44d7Unichain Sepolia#1301SpokePool0x6999...A874Periphery—MulticallHandler0x0F7A...3a0E","tokens":1530,"squid":"spider-09","role":"Bridge Spider","at":1791338477690,"hash":"c29e3ccd1a3a0f09caa40ea7147af8c29db3e0cc"}
{"url":"https://forum.arbitrum.foundation/t/proposal-non-constitutional-funding-dao-legal-defence-and-advocacy-with-defi-education-fund/23062/22","domain":"forum.arbitrum.foundation","title":"Proposal [Non-Constitutional]: Funding DAO Legal Defence and Advocacy with Defi Education Fund - Archive / Archived Proposals - Arbitrum","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 8\n\n 4\n\n 3\n\n 3\n\n 2\n\n read \n\n 19\n min\n\n Apr 2024\n\n 20 / 26\n\n Sep 2024\n\n Mar 2025\n\n Load more posts above\n\n post by cp0x on Apr 5, 2024\n\n cp0x\n\n I understand that the US is the largest player in crypto.\nBut I consider it incorrect to concentrate all efforts and resources on only one country.\nRegarding the legal protection of the crypto space, there was recently a proposal to provide financial support for the legal costs of the trial of the Tornado programmers. But for some reason we were afraid to even discuss it and deleted the article and the vote.\nLet’s start with protecting ordinary programmers, otherwise then there will be no one to make DeFi applications\n\n post by GFXlabs on Apr 5, 2024\n\n GFXlabs\n\nDefi Education Fund filed this in court today in the United States vs Roman Storm et al case. They also were in court last year around the OFAC designation for TC.\nThe DEF is pretty actively involved in a number of cases the US government has brought against DAOs or their contributors.\n\n post by cp0x on Apr 5, 2024\n\n cp0x\n\n Thanks, this gives me hope!\n\n post by thedevanshmehta on Apr 6, 2024\n\n thedevanshmehta\n\n Rather than seeing proposals like this one and the one supporting coin center floated individually, I would much rather see an approved budget, an open call for applications and then ARB voters getting to decide who gets how much.\nOtherwise it’ll be death by a thousand cuts, with each new advocacy group coming and posting a request. This isn’t a knock on the DEF, which i think is fabulous. I don’t agree with the criticism of US centricity, unfortunately the way the world is right now, as goes the US so goes the world.\n\n post by cp0x on Apr 8, 2024\n\n cp0x\n\n Agree with open call for applications and then ARB vote\n\n post by thedevanshmehta on Apr 8, 2024\n\n thedevanshmehta\n\n I’d say open call for applications with eligiblity being filing an amicus curiae brief in the Tornado cash case\nIf number of applicants is 3 or less we can just divide equally without an ARB vote\n\n 4 months later\n\n post by gidagwadajed on Aug 19, 2024\n\n gidagwadajed\n\n Hey all! My name is Nathan Hennigh, and I am the Head of Community Engagement at the DeFi Education Fund.\nFirst off, we are incredibly grateful for the support of the Arbitrum community in funding our efforts to fight for DeFi, open source software, and developers.\nSecondly, I’m excited to share that the patent previously mentioned, covering oracle technology, has been acquired by DEF and dedicated to the public! This is a HUGE win for DeFi, one not possible without your support. Thank you!\nWith that said, I’d like to invite you all to our monthly Community Call on August 27 at 12 PM Central Time. Come join us! Bring your questions and hear more about the patent acquisition and other updates from our CEO, Miller Whitehouse-Levine.\nmeet.google.com/kjb-tgss-skw\nOur Community Calls are on the fourth Tuesday of every month. We’d love to see you there each time! You can also add all the calls to your calendar via the link below!\n\n 23 days later\n\n post by gidagwadajed on Sep 11, 2024\n\n gidagwadajed\n\n Yesterday, in the first DeFi Hearing ever, DEF CLO Amanda Tuminelli testified before congress and absolutely crushed it!\nCheck out here opening statement here: x.com\nCheck out some highlights here:\nx.com\n\n post by JoJo on Sep 12, 2024\n\n JoJo\n\n gidagwadajed\n\n i totally missed this, this is a wonderful result. Do you have something that was published in regard of this patent? Either in docs or in twitter\n\n post by gidagwadajed on Sep 12, 2024\n\n gidagwadajed\n\n Yes it truly was! Here’s the links\nTwitter: x.com\nOriginal article: https://www.defieducationfund.org/post/def-fights-back-against-patent-troll\nSome of the media coverage:\nDEF purchases patent at center of suits against MakerDAO and Compound - Blockworks\nhttps://cointelegraph.com/news/def-ends-dao-lawsuits-makerdao-compund-patent-acquisition\nPatent at Crux of MakerDAO Lawsuit Purchased, Ending Crypto Tech Dispute - Decrypt\n\n 8 days later\n\n post by gidagwadajed on Sep 20, 2024\n\n gidagwadajed\n\n Hey all! Just dropping in again to remind everyone that our community call will be next Tuesday, September 24th, 12 PM Central Time! Excited to see yall there!\nhttp://meet.google.com/kjb-tgss-skw\n\n post by cp0x on Sep 20, 2024\n\n cp0x\n\n Can this be added to the Arbitrum call schedule?\nThere’s a pretty tight schedule for Tuesday.\n\n post by gidagwadajed on Sep 20, 2024\n\n gidagwadajed\n\n Yeah of course! Can you point me to where I can do that?\n\n post by Vertex_Protocol on Sep 21, 2024\n\n Vertex_Protocol\n\n I think one of the people in here should be able to help you get it on the calendar\n\n 20 days later\n\n post by gidagwadajed on Oct 11, 2024\n\n gidagwadajed\n\n Gm gm! Happy Friday! We’re excited to make it easier for you to stay updated on DEF and the latest in the DeFi policy/regulatory space. We’ve launched a Telegram channel that will keep you in the loop with quick, super TLDRs of what’s happening. Please join and feel free to share it with others!\n\n 10 days later\n\n post by gidagwadajed on Oct 21, 2024\n\n gidagwadajed\n\n Hey all!\nDon’t miss the community call happening tomorrow October 22nd, 12 PM, Central Time! It’s on the community calendar now as well! Excited to see everyone there!\nAlso don’t forget to join the announcements Telegram channel if you haven’t already!\n\n 1 month later\n\n post by gidagwadajed on Nov 25, 2024\n\n gidagwadajed\n\n Here again to remind y’all of the community call tomorrow at 12 PM Central! Cant wait to see everyone there!\n\n 4 months later\n\n post by mbernstein on Mar 20, 2025\n\n mbernstein\n\n Hi all!\nOn Tuesday, May 27th at 1pm EST we will be holding our May Community Call. Link to join the call can be found below.\nCan’t wait to see you all there!\n\n post by mbernstein on Mar 24, 2025\n\n mbernstein\n\n Hi all,\nFor information on what the DeFi Education Fund was up to in February 2025, please check out the following link:\n\n post by mbernstein on Mar 31, 2025\n\n mbernstein\n\n Happy Monday everyone!\nI want to flag that on Friday (3/28/25), DEF submitted an amicus brief in support of Jim Harper’s petition for certiorari to the United States Supreme Court in Harper v. Werfel. Harper’s case relates to the IRS’s warrantless acquisition of digital asset transaction records from Coinbase through a “John Doe” summons, raising critical questions about whether individuals retain their Fourth Amendment right to privacy in financial data shared with third-party platforms.\nLearn more here: https://www.defieducationfund.org/post/def-submits-amicus-brief-to-protect-american-s-fourth-amendment-rights\n\n Related topics\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 [Non-Constitutional]: Defending Open Source: A United Stand for Developer Rights and Software Freedom\n\n Finalized AIPs\n\n 59\n\n 5.1k\n\n Jun 2024\n\n The Defiant: #1 Ranked Crypto 101 Education & Onboarding Series\n\n Archived Proposals\n\n proposal\n\n 4\n\n 975\n\n Jan 2024\n\n Frisson Delegate Communication Thread\n\n Delegate Statements\n\n delegation,delegate-statements\n\n 76\n\n 1.1k\n\n Apr 2025\n\n Ignas Delegate Communication Thread\n\n Delegate Statements\n\n 47\n\n 767\n\n Nov 2025\n\n SEED Latam Delegate Communication Thread\n\n Delegate Statements\n\n delegation,delegate-statements\n\n 48\n\n 8.1k\n\n Jan 2025","tokens":1836,"squid":"spider-07","role":"Council Spider","at":1791338477913,"hash":"f20d42b1af468a13702b84fe5fd4f9f374112dd3"}
{"url":"https://docs.phantom.com/","domain":"docs.phantom.com","title":"Build with Phantom - Phantom developer documentation","text":"Phantom is a leading crypto wallet enabling users to manage digital assets and access decentralized applications across Solana, Ethereum, Bitcoin, Base, Polygon, and HyperEVM.\nSui support has been deprecated.\nThis documentation is for developers building with Phantom. For integration support, submit a request using this form. For general support, visit our Help Center.\n​What are you building for?\n\n​Phantom MCP server\nThe Phantom MCP server gives AI agents a Phantom wallet. It’s a core Phantom product — like the mobile app and browser extension, but for users who interact with crypto through AI agents.\nAgents can trade, transfer, and manage assets across Solana, Ethereum, and Bitcoin using 13 tools across two capability groups:\n\n​Phantom Connect SDK\nBuild with our comprehensive SDK suite for web and mobile platforms. Choose from React, React Native, or Browser SDKs to integrate wallet functionality into your app with native multi-chain support.\nChoose the SDK that fits your app:\n\nNot sure which SDK to use? Check out our SDK comparison guide to find the perfect fit for your use case.\n​Developer resources\nWas this page helpful?","tokens":286,"squid":"spider-10","role":"Tooling Spider","at":1791338494106,"hash":"a0f82c69d5c8643273d85e70aed7c4370f2108d9"}
{"url":"https://developers.jup.ag/docs/ai","domain":"developers.jup.ag","title":"Jupiter for AI Agents - Jupiter Developers","text":"Jupiter’s APIs are AI-native: no RPC, clean JSON, simple REST. Whether your agent is running locally or on a hosted platform, there’s a way to connect it to Jupiter.\n​Pick the Right Tool\nWhich tools to use depends on where your agent runs and what it needs to do:\nGoalLocal (Claude Code, Cursor, Codex)Hosted (ChatGPT, Claude.ai)Read the docsSkills + llms.txtDocs MCP + llms.txtExecute operationsCLIJupiter MCP\nLocal agents have shell access, can install packages and run commands. The CLI + Skills combination integrates naturally into these environments.\nHosted agents cannot install tools or execute shell commands. MCP exposes Jupiter’s capabilities as a network service that any agent can discover and call without prior setup.\n​Read the Docs\nFor agents that need to discover and understand Jupiter’s APIs before writing code or taking action.\n\n​Execute Operations\nFor agents that interact with Jupiter directly - swap tokens, check prices, place orders.\nWas this page helpful?","tokens":246,"squid":"spider-02","role":"Liquidity Spider","at":1791338503205,"hash":"0e6ed6f2466f0a1c7209081d56bfe8ef82aa63a1"}
{"url":"https://docs.phantom.com/phantom-connect","domain":"docs.phantom.com","title":"Phantom Connect - Phantom developer documentation","text":"​Overview\nPhantom Connect is a suite of tools that lets developers onboard users instantly with embedded wallets powered by Phantom. Users sign in with Google or Apple, and your app receives a secure, ready-to-use wallet without requiring private-key management. Users who prefer to use their existing Phantom browser extension can also connect that wallet directly.\nWhen users authenticate with social login, Phantom creates an embedded wallet inside a secure environment on the user’s device. This wallet is authorized to transact with your app and is protected by spending-limit controls, domain binding, and real-time risk evaluation. Your app never handles private keys and never becomes a custodian.\n​Connect modal\nPhantom Connect includes a built-in Connect modal that handles sign-in and wallet connection for you. It’s the recommended way to onboard users because it works across supported sign-in methods and returns a connected wallet session your app can use immediately.\n\nConnect modal features:\n\nMultiple sign-in options, including Google, Apple, and the Phantom browser extension\nBuilt-in error handling and loading states\nWorks across devices and environments\nHandles the full connection flow and returns a ready-to-use wallet session\n\nFor implementation, see the Connect guide for your SDK:\nReact, React Native, Browser.\n​Embedded wallets\nEmbedded wallets are wallets built directly into your application. No browser extensions, mobile apps, or external wallet software required. Users authenticate with familiar methods like Google or Apple, and your app instantly has access to a fully functional wallet.\nEmbedded wallets remove the friction of traditional wallet onboarding while maintaining the security and self-custody guarantees users expect.\n​Spending limits\nEmbedded wallets have a default spending limit of $1,000 USD per app per day. This limit applies to the total value of transactions a user can sign through your app within a 24-hour period. The limit resets daily and helps protect users from unauthorized or excessive spending.\n​Authentication methods\nPhantom Connect supports two authentication paths. Social login results in an embedded wallet that your app can use through the Phantom Connect SDKs. Extension and injected wallet connections use the user’s existing wallet instead.\n​Social login\nWhen a user selects Sign in with Google or Sign in with Apple, Phantom Connect creates or retrieves an embedded wallet tied to that identity.\nFlow summary:\n\nUsers authenticate with Google or Apple.\nUsers enter their 4-digit PIN.\nUsers approve any required permissions or spending limits.\nYour app receives the connected embedded wallet.\n\nHow embedded wallets work for different user types:\n\nNew social-login users: Phantom creates a brand-new embedded wallet.\nExisting social-login (seedless) users: Phantom securely converts the existing seedless wallet into an embedded wallet. After that, the same wallet is usable in both Phantom and your app.\n\n​Extension and injected wallets\nWhen users connect with the Phantom extension or any other injected wallet:\n\nPhantom Connect doesn’t create an embedded wallet.\nUsers transact and approve actions directly inside their extension.\nThe extension signs using whatever key-management system that wallet uses.\nYour app receives the connected account through the same Phantom Connect SDK interface.\n\nThis gives your app a unified integration path while preserving the user’s wallet choice.\n​Account selection behavior\n​Social login\nUsers can choose from any Phantom accounts tied to their Google or Apple identity, from the account picker.\n​Extension and injected wallets\nUsers can choose from any Phantom account tied to their recovery phrase.\n​Disconnecting an app\nUsers can disconnect your app at any time from Phantom:\n\nOpen Phantom (extension or mobile app).\nGo to Settings → Connected Apps.\nSelect your app.\nChoose Revoke permissions or Disconnect.\n\nAfter disconnecting, your app can no longer access the wallet.\n​Session duration\nA Phantom Connect session remains active for seven days from the last login. After it expires, users must sign in again with Google or Apple.\n​FAQ\nWhat is Phantom Connect?Phantom Connect lets your users sign in with Google or Apple and receive a secure embedded wallet your app can use for signing. No wallet installation required. Users who prefer the Phantom browser extension can also connect their existing wallet instead.How much does Phantom Connect cost?There’s no cost to use Phantom Connect. Phantom provides authentication, embedded wallets, and signing infrastructure at no charge to developers.How does Phantom Connect keep wallets secure?Phantom Connect creates a wallet that only the user can authorize. Private keys never pass through your app or backend and never appear in plaintext. Every action is authenticated by the user and evaluated against built-in protections like spending limits and app-level permissions. Your integration stays fully non-custodial.Which authentication methods does Phantom Connect support?Phantom Connect supports two ways for users to sign in:\nSocial login: Users sign in with Google or Apple. Your app receives a secure embedded wallet that’s ready to use immediately.\nExtension and injected wallets: Users connect with the Phantom extension or any other injected wallet. All approvals happen in the existing wallet, and no embedded wallet is created.\nYour app can support one or more of these methods depending on your needs.Do I need to handle private keys myself?No. Private keys are never exposed to your app, your backend, or your infrastructure. Phantom Connect handles secure signing behind the scenes, and your app simply requests signatures through the SDK.What does integration look like for my app?Phantom Portal is not accepting new applications at this time. New sign-ups for Phantom Connect SDK access and new app submissions to the Phantom app directory are paused. Existing Portal apps and App IDs are not affected.Integration is lightweight:\nSign in to Phantom Portal.\nOpen your existing app.\nVerify your domain.\nConfigure allowed origins and redirect URLs.\nAdd your app information.\nGet your App ID and integrate.\nTrigger the connect flow and start using the wallet returned by the SDK.\n\n​Resources\nFor implementation details and platform-specific examples, see the Phantom Connect SDKs:\n\nReact SDK\nBrowser SDK\nReact Native SDK\n\nUse the Phantom Cursor plugin to scaffold complete integrations with AI. Your Cursor agent can set up any SDK, configure social login, and build transaction flows automatically. See the plugin documentation for details.Was this page helpful?","tokens":1662,"squid":"spider-10","role":"Tooling Spider","at":1791338520359,"hash":"483c18a72009d6f6768615e4d48fb807f37283de"}
{"url":"https://developers.jup.ag/docs/resources/support","domain":"developers.jup.ag","title":"Support - Jupiter Developers","text":"​Developer Updates\nFor breaking changes and updates, please use these various channels:\n\n​Developer Support\nJupiter provides developer tools and resources to help you integrate with Jupiter. Use these channels for technical support:\n\nUse the AMM Integrators form to submit your AMM for routing integration once your parity tests pass, see Integrate AMM into Metis.\nWARNINGPlease use the Discord channel for your technical questions, as it is a public channel, more people can help you and it promotes discovery/discussion.If you open a ticket via the link that does not relate to Portal Enquiries, we will redirect you to the Discord channel.\n\n​Customer Support\nThe Jupiter UI contains multiple safeguards, warnings and default settings to guide our users to trade safer. However, when you integrate with Jupiter, we cannot control these elements despite sharing best practices, hence, Jupiter is not liable for any losses incurred on your UI/platform.\nThe only exception is for the Jupiter Swap API’s order and execute path, where you can use our ticketing system to provide support to your users.\nWARNINGWe are still in the process of finalizing the Swap API customer support process.Reach out to us in Discord to discuss what is the best way to support your users.Was this page helpful?","tokens":322,"squid":"spider-02","role":"Liquidity Spider","at":1791338520406,"hash":"09d488c12d7e05d00f662c9c3c7f035cbdd685b6"}
{"url":"https://docs.arbitrum.io/launch-arbitrum-chain/extend-the-protocol/stf","domain":"docs.arbitrum.io","title":"How to customize your Arbitrum chain's behavior","text":"Extend the protocolHow to customize your Arbitrum chain's behaviorLearn how to customize your Arbitrum chain's behavior (known as the State Transition Function or STF)Request an updateNoteCustomizations require expertiseCustomizing your chain is a core benefit of building with Arbitrum chains. We strongly recommend that teams interested in customizations work alongside a partner with ArbOS and Nitro software expertise, such as a Rollup-as-a-Service team.Working alongside an experienced Arbitrum chain operator can help your team navigate the complex tradeoff space of rollup customizations, which can include performance, security, and cost considerations. Offchain Labs is positioned to train and enable Rollup-as-a-Service in their work with clients to scale support to the Arbitrum chain ecosystem as a whole. As such, Offchain Labs does not necessarily have the capacity to review code changes made by individual Arbitrum chains.We encourage you to leverage your in-house expertise, collaborate with expert partners, and allocate appropriate resources for both an initial implementation (including an audit) and ongoing maintenance and security management of your customization.\nIntroduction\nBefore customizing your Arbitrum chain, it's important to understand what the State Transition Function (STF) is. The STF defines how new blocks are produced from input messages (i.e., transactions).\nThis guide is only necessary for changes that modify the STF.\nTo customize other node behavior, such as RPC behavior or the sequencer's ordering policy, you can simply\nbuild your own node without worrying about the rest of this guide. However, changes that modify the STF require updating the fraud proving system to recognize the new behavior as correct. Otherwise, the fraud prover would side with unmodified nodes, which would win fraud proofs against your modified node.\nHere's some examples of modifications that affect the STF:\n\nAdding a new EVM opcode or precompile:\n\nThis modifies the STF because a node with this change would disagree about the outcome of EVM execution compared to an unmodified Nitro node when the new opcode or precompile is invoked.\n\nRewarding the deployer of a smart contract with a portion of gas spent in the smart contract's execution:\n\nThis modifies the STF because a node which has this change applied would disagree about the balance of the deployer after transactions. Such changes would lead to disagreements about block hashes compared to unmodified Nitro nodes.\n\nHere's some examples of modifications that don't affect the STF:\n\nAdding a new RPC method to query an address's balance across multiple blocks:\n\nThis doesn't modify the STF because it doesn't change onchain balances or block hashes.\n\nChanging the sequencer to order blocks by tip:\n\nThe sequencer is trusted to order transactions in Arbitrum Nitro, and it can choose any ordering it wants.\nNodes (and the fraud proofs) will simply accept the new transaction ordering as there is no single ordering they think is correct.\n\nModification compatibility with Arbitrum Nitro\nSome potential modifications are incompatible with Arbitrum Nitro and would not result in a functioning blockchain. Here are some requirements for the Arbitrum Nitro State Transition Function:\n\nThe STF must be deterministic. For instance, if you gave an address a random balance using the Go randomness library,\n\nEvery node would disagree on the correct amount of balance and the blockchain would not function correctly. However, it is acceptable to take a non-deterministic path to a deterministic output. For instance, if you randomly shuffled a list of addresses, and then gave them each one ETH, that would be fine, because no matter how the list of addresses is shuffled the result is the same and all addresses are given one ETH.\n\nThe STF must not reach a new result for old blocks. For instance, if you have been running an Arbitrum Nitro chain for a while, and then you decide to modify the STF to not charge for gas, a new node that syncs the blockchain will reach a different result for historical blocks. It's also important to synchronize between nodes when an upgrade takes effect. A common mechanism for doing this is having an upgrade take effect at a certain timestamp, by which all nodes must be upgraded.\nThe STF must be \"pure\" and not use external resources. For instance, it must not use the filesystem, make external network calls, or launch processes. That's because the fraud proving system does not (and for the most part, cannot) support these resources. For instance, it's impossible to fraud prove what the result of an external network call is, because the fraud prover smart contracts on L1 are unable to do networking.\nThe STF must not carry state between blocks outside of the \"global state\". In practice this means persistent state must be stored within block headers or the Ethereum state trie. For instance, ArbOS stores all retryables in contract storage under a special ArbOS address.\nThe STF must not modify Ethereum state outside of a transaction. This is important to ensure that replaying old blocks reaches the same result, both for tracing and for validation. The ArbOS internal transaction is useful to modify state at the start of blocks.\nThe STF must reach a result in under a second. This is a rough rule, but for nodes to keep in sync it's highly recommended to keep blocks quick.\n\nIt's also important for the fraud proofs that execution reliably finishes in a relatively short amount of time.\nA block gas limit of 32 million gas should safely fit within this limit.\n\nThe STF must not fail or panic. It's important that the STF always produces a new block, even if user input is malformed.\n\nFor instance, if the STF receives an invalid transaction as input, it'll still produce an empty block.\n\nBuilding the modified node\nTo modify the State Transition Function, you'll need to build a modified Arbitrum Nitro node Docker image. This guide covers how to build the node and enable fraud proofs by building a new replay binary.\nStep 1. Download the Nitro source code\nClone the Nitro repository before you begin:\ngit clone --branch v3.12.1 https://github.com/OffchainLabs/nitro.git\ncd nitro\ngit submodule update --init --recursive --force\nStep 2. Apply modifications\nNext, make your changes to the State Transition Function. For example, you could add a custom precompile.\nAfter this step, you should visit Customize ArbOS version to see if your changes need to upgrade the ArbOS version. If so, please continue to\nfollow that document to add an ArbOS upgrade logic to your code.\nStep 3. Run the node\nTo build the Arbitrum Nitro node image, you'll first need to install Docker.\nYou can confirm if it's already setup by running docker version in a terminal.\nIf not, try following Docker's getting started guide, or if you're on Linux,\ninstall Docker from your distribution's package manager and start the Docker service.\nOnce you have Docker installed, you can simply run docker build . --tag custom-nitro-node in the nitro folder to build your custom node.\nNoteA chain running a customized State Transition Function will produce blocks that don't match the verified Nitro WASM module root on the parent chain. Coordinate with Offchain Labs before operating a customized STF against a production chain, as the validator configuration required is not covered in this guide.\nYou have two ways of running your node.\n1. Using the docker-compose file\nThis is the recommended way if you're running your Arbitrum chain locally through the provided docker-compose file. In docker-compose.yml, modify the Docker image used for the Nitro container:\n...\nnitro:\n image: custom-nitro-node\n ports:\n...\nAnd run docker compose up to run all of your containers.\n2. Use docker run to run your Nitro node only\nThis method will only run the customized Nitro node (i.e., it will not run Blockscout, or the DA server if you're using an AnyTrust chain). Use the following command:\ndocker run --rm -it -v /path/to/your/node/dir:/home/user/.arbitrum -p 0.0.0.0:8449:8449 custom-nitro-node --conf.file /home/user/.arbitrum/nodeConfig.json\nNoteThe instructions provided in How to run a full node will not work with your Arbitrum chain node. See Optional parameters (Arbitrum chain) for Arbitrum chain-specific CLI flags.\nOnce your node is running, you can try out your modifications to the State Transition Function and confirm they work as expected.\nStep 4. Enable fraud proofs\nTo enable fraud proofs, you'll need to build the \"replay binary\", which defines the State Transition Function for the fraud prover. The replay binary (sometimes called the machine) re-executes the State Transition Function against input messages to determine the correct output block.\nIt has three forms:\n\nThe replay.wasm binary is the Go replay binary compiled to WASM. It's used by the JIT validator to verify blocks against the fraud prover.\nThe machine.v2.wavm.br binary is a compressed binary containing the Go replay binary and all its dependencies, compiled to WASM, then translated to the Arbitrum fraud proving variant .\n\nIt's used by Arbitrator when actually entering a and performing the fraud proofs,\nand has identical behavior to replay.wasm.\n\nThe (stored in module-root.txt) is a 32 byte hash usually expressed in hexadecimal which is a merkelization of machine.v2.wavm.br.\n\nThe replay binary is much too large to post onchain, so this hash is set in the L1 Rollup contract to determine the correct replay binary during fraud proofs.\n\nTo run a validator node with fraud proofs enabled, the validator node's Docker image will need to contain all three of these versions of the replay binary.\n4.1 Build a dev image\nThe simplest way to build a Docker image with the new replay binary is to build a dev image.\nThese images contain a freshly built replay binary, but note that the replay binary and corresponding WASM module root will generally change when the code is updated,\neven if the State Transition Function has equivalent behavior.\nIt's important that the validator's WASM module root matches the onchain WASM module root, which is why this approach is harder to maintain.\nOver the longer term, you'll want to maintain a separate build of the replay binary that matches the one currently onchain, usable by any node image.\nTo build the dev node image and get the WASM module root, run:\ndocker build . --target nitro-node-dev --tag custom-nitro-node-dev\ndocker run --rm --entrypoint cat custom-nitro-node-dev target/machines/latest/module-root.txt\nOnce you have the WASM module root, you can put it onchain by calling setWasmModuleRoot(newWasmModuleRoot) through the upgradeExecutor contract's method executeCall() as the owner. To call this method, you need to set target as your Rollup contract address. Ensure that targetCallData starts with 0x89384960 (this is the signature of setWasmModuleRoot(byte32)), and that it's followed by your WASM module root.\nThe upgradeExecutor contract address and Rollup contract address can be found in the chain deployment info JSON.\nYou can confirm that the WASM module root was updated by calling wasmModuleRoot() on the Rollup contract.\nOnce you have set the new WASM module root onchain, the validator will recognize blocks produced by your customized STF. You can now run your node with fraud proof verification enabled.\nYou have two ways of running your node.\n1. Using the docker-compose file\nAs mentioned before, this is the recommended way if you're running your Arbitrum chain locally through the provided docker-compose file. In docker-compose.yml, modify the Docker image used for the Nitro container. Notice that we'll now use the custom-nitro-node-dev you just created:\n...\nnitro:\n image: custom-nitro-node-dev\n ports:\n...\nAnd run docker compose up to run all of your containers.\n2. Use docker run to run your Nitro node only\nThis method will only run the customized Nitro node (i.e., it will not run Blockscout, or the DA server if you're using an AnyTrust chain). Use the following command:\ndocker run --rm -it -v /path/to/your/node/dir:/home/user/.arbitrum -p 0.0.0.0:8449:8449 custom-nitro-node-dev --conf.file /home/user/.arbitrum/nodeConfig.json\n4.2 Preserving the replay binary\nThe primary issue with simply using a nitro-node-dev build is that, whenever the code changes at all, the replay binary will also change.\nIf the node is missing the replay binary corresponding to the onchain WASM module root, it will be unable to act as a validator.\nTherefore, when releasing new node Docker images it's important to include the currently onchain WASM module root.\nTo do that, you'll need to first extract the replay binary from the nitro-node-dev Docker image built earlier:\ndocker run --rm --name replay-binary-extractor --entrypoint sleep custom-nitro-node-dev infinity\ndocker cp replay-binary-extractor:/home/user/target/machines/latest extracted-replay-binary\ndocker stop replay-binary-extractor\ncat extracted-replay-binary/module-root.txt\nmv extracted-replay-binary \"target/machines/$(cat extracted-replay-binary/module-root.txt)\"\nThese commands will output the new WASM module root, and create the directory target/machines/<wasm module root>.\nThere you'll find the three versions of the replay binary mentioned earlier:\nreplay.wasm, machine.v2.wavm.br, and module-root.txt, along with some other optional files.\nNow that you've extracted the replay binary, there are two ways to add it to future Docker images,\nincluding non-dev image builds. You can either keep it locally and copy it in, or host it on the web.\nOption 1: Store the extracted replay binary locally\nNow that we've extracted the replay binary, we can modify the Docker file to copy it into new Docker builds.\nEdit the Dockerfile file in the root of the nitro folder, and after all the RUN ./download-machine.sh ... lines, add:\nCOPY target/machines/<wasm module root> <wasm module root>\nRUN ln -sfT <wasm module root> latest\nReplace each <wasm module root> with the WASM module root you got earlier.\nOption 2: Host the replay binary on the web\nTo support building the Docker image on other computers without this local machine directory,\nyou'll need to either commit the machine to git, or preferably, host the replay binary on the web.\nTo host the replay binary on the web, you'll need to host the replay.wasm and machine.v2.wavm.br files somewhere.\nOne good option is GitHub releases, but any hosting service works.\nOnce you have those two files hosted, instead of the COPY and RUN command mentioned in option 1,\nyou'll need to add these new lines to the Dockerfile file in the root of the nitro folder,\nafter all the RUN ./download-machine.sh ... lines:\nRUN wasm_module_root=\"<wasm module root>\" && \\\n mkdir \"$wasm_module_root\" && \\\n wget <url of replay.wasm> -O \"$wasm_module_root/replay.wasm\" && \\\n wget <url of machine.v2.wavm.br> -O \"$wasm_module_root/machine.v2.wavm.br\" && \\\n echo \"$wasm_module_root\" > \"$wasm_module_root/module-root.txt\" && \\\n ln -sfT \"$wasm_module_root\" latest\nReplace the <wasm module root> with the WASM module root you got earlier,\nthe <url of replay.wasm> with the direct link to the replay.wasm file (it must be a direct link to the file and not just a download site),\nand the <url of machine.v2.wavm.br> with the direct link to the machine.v2.wavm.br file.\nStep 5. Verify the fraud proofs\nIn theory, fraud proofs should now be working with your newly built Docker images.\nMake some transactions on your new blockchain, test out your modifications to the State Transition Function,\nwait for a batch to be posted, and you should be seeing \"validation succeeded\" log lines!\nIf you see \"Error during validation\", then the replay binary is likely not up-to-date with your modifications to the State Transition Function.\nEnsure that the replay binary is freshly built, not missing any modifications, and that the WASM module root set in the Rollup contract matches your replay binary.How is this guide?How to customize your Arbitrum chain's precompilesLearn how (and when) to customize your Arbitrum chain's precompilesEcosystem supportEcosystem support documentation","tokens":4026,"squid":"spider-01","role":"Chain Spider","at":1791338523163,"hash":"ed51b01a0500f834e8e773b795069117e3390f48"}
{"url":"https://docs.phantom.com/cash","domain":"docs.phantom.com","title":"CASH - Phantom developer documentation","text":"This page documents the CASH token mint on Solana and practical integration notes for apps.\nFor product details, reserve disclosures, and the CASH contributor program, visit usecash.xyz.\n​Token details\nFieldValueChainSolanaMintCASHx9KJUStyftLFWGvEVf59SGeG9sh5FfcnZMVPCASHDecimals6StandardSPL Token\n1 CASH = 1,000,000 base units. Use base units when constructing on-chain transactions.\n​Integrating CASH\nCASH works like any SPL token. See the Solana documentation on tokens for program-level behavior. If your app already handles USDC or other SPL transfers, the same code applies with the CASH mint address above.\n​Accepting CASH with x402\nThe x402 protocol lets you gate HTTP endpoints behind payments. When a client hits a protected route, the server responds with HTTP 402 and payment requirements. The client signs a CASH transfer and retries with proof of payment.\nSee the community x402 CASH facilitator example for a forkable facilitator service and protected Express server you can adapt.\n​Devnet\nDevnet CASH tokens are available for testing. Contact developer support with your use case to get a devnet mint address and test tokens.\n​Next steps\n\nLearn more about SPL tokens in the Solana token docs.\nBrowse Developer tools and resources for Phantom guides, provider integration, and mobile deep links.\nIntegrate wallets in your app with Phantom Connect.\nWas this page helpful?","tokens":346,"squid":"spider-10","role":"Tooling Spider","at":1791338530256,"hash":"3f4b1451b6ac20bd589262de631614c69f8408ba"}
{"url":"https://developers.jup.ag/docs/legal","domain":"developers.jup.ag","title":"Guidelines - Jupiter Developers","text":"​Legal\n\nSDK & API License Agreement - Governs the use of Jupiter’s SDK and API.\nTerms of Use - General terms and conditions for using Jupiter’s platform and services.\nPrivacy Policy - How Jupiter handles user data and privacy protection.\n\n​Support\nIf you have questions about any of our legal documents or need clarification on specific terms, please don’t hesitate to reach out to us.\n\nFor legal inquiries, contact us at: legal@jup.ag\nFor customer and developer support, refer to the Support page for more information.\n\n​Labelling\nWhen integrating with Jupiter products, you are advised to correctly label the APIs used.\nFor SwapAPI UsedRequired LabelSelf-Hosted Metis Swap API binaryMetisWas this page helpful?","tokens":178,"squid":"spider-02","role":"Liquidity Spider","at":1791338530373,"hash":"9052730961b09a1b11533f7637affb40b6a9e13a"}
{"url":"https://docs.arbitrum.io/how-arbitrum-works","domain":"docs.arbitrum.io","title":"How Arbitrum works","text":"How Arbitrum worksA technical look at the protocols and mechanisms behind Arbitrum Nitro.Request an updateA technical look at how Arbitrum works: the Nitro architecture, the protocols that settle transactions on Ethereum, the BoLD dispute protocol, and Timeboost transaction ordering.\nInside Arbitrum NitroA technical deep dive into Nitro's architecture.Deep divesAnyTrust, ArbOS, assertions, messaging, gas and fees, and the transaction lifecycle.ReferenceThe sequencer and Arbitrum's Geth fork.The BoLD dispute protocolHow BoLD resolves disputes over chain state.TimeboostHow Timeboost and the express lane functions.PGA and fast feedHow the priority gas auction and fast feed work.How is this guide?Inside Arbitrum NitroFollow a transaction's journey through the complete Arbitrum Nitro stack, from submission to finality.","tokens":206,"squid":"spider-01","role":"Chain Spider","at":1791338532976,"hash":"3b0ab51033460bf703725e15792ed2e0703d2ea8"}
{"url":"https://docs.phantom.com/phantom-cli","domain":"docs.phantom.com","title":"Phantom CLI - Phantom developer documentation","text":"The Phantom CLI (@phantom/cli) lets you interact with your Phantom embedded wallet directly from the terminal. It supports:\n\nWallet management — check balances, get addresses, and rebalance portfolios\nSolana and EVM — sign messages, send transactions, swap tokens across chains\nHyperliquid perpetuals — open positions, manage orders, deposit and withdraw\nMCP server mode — run as an AI agent tool server exposing all wallet operations as MCP tools\n\n​How it works\nThe CLI authenticates via Phantom Connect — a browser-based OAuth flow (Google, Apple, or Phantom extension). Sessions persist locally and refresh automatically, so you only sign in once.\n# Install globally\nnpm install -g @phantom/cli\n\n# Authenticate\nphantom login\n\n# Check your balances\nphantom wallet balances\n\n​MCP server mode\nRun the CLI as an MCP stdio server to expose all wallet operations as tools for AI agents (Claude, Cursor, and others):\nphantom --mcp\n\nSee the Phantom MCP Server docs for the full tool reference and agent setup instructions.Was this page helpful?","tokens":260,"squid":"spider-10","role":"Tooling Spider","at":1791338540107,"hash":"e731b8d4976f14a19246f8765b449f5b3e69c59c"}
{"url":"https://docs.arbitrum.io/glossary","domain":"docs.arbitrum.io","title":"Arbitrum glossary","text":"Arbitrum glossaryA list of terms and definitions related to Arbitrum.Request an updateActivationThe 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.Active ValidatorA 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.)Address AliasAn 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.Adjustment windowWindow 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.Alt-DAAn \"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.Decentralized applicationA 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.Arb Token BridgeA series of contracts on an Arbitrum chain and its underlying chain that facilitate trustless movement of ERC-20 tokens between the two layers.Arbified Token ListA 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.)ArbitrumArbitrum 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.Arbitrum AnyTrust ChainAn Arbitrum chain that implements the Arbitrum AnyTrust Protocol.Arbitrum AnyTrust ProtocolAn 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.Arbitrum Bridge UIWeb application built and maintained by Offchain Labs for user interactions with the Arbitrum Token Bridge. Visit the Arbitrum Bridge UI.Arbitrum chainA 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.Arbitrum ChainsAn Arbitrum chain is any chain that is built using the Arbitrum stack. Anyone can deploy an Arbitrum chain permissionlessly.Arbitrum ClassicOld 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.)Arbitrum DAOThe 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.Arbitrum Expansion Program (AEP)The 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.Arbitrum Full NodeA 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.Arbitrum NitroCurrent Arbitrum tech stack; runs a fork of Geth and uses WebAssembly as its underlying VM for fraud proofs.Arbitrum NovaThe 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.Arbitrum OneArbitrum One is a public settlement layer built on Ethereum for applications that require strong security guarantees, deep liquidity, and predictable execution.Arbitrum Rollup ChainAn Arbitrum chain that implements the Arbitrum Rollup Protocol.Arbitrum Rollup ProtocolA 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.ArbOSArbitrum's \"operating system\" that trustlessly handles system-level operations; includes the ability to emulate the EVM.Archive NodeAn 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.AssertionA 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.\nAuction ContractA 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.Autonomous AuctioneerA 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.BatchA group of Arbitrum transactions posted in a single transaction on the Underlying Chain into the Sequencer Inbox by the Sequencer.Batch PosterThe 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.BisectionA 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.BlobA 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.BlockchainA distributed digital ledger that is used to record transactions and store data in a secure, transparent, and tamper-resistant way, notably in cryptocurrency protocols.BLS SignatureA 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.BoLDShort for \"Bounded Liquidity Delay\"; latest version of the Arbitrum Challenge protocol designed to eliminate delay attack vectors (see here for more).BonderA 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: stakerBondingLocking 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.BridgeA set of smart contracts for sending Cross-chain messages between blockchains. Every Arbitrum chain includes a bridge to/from its Parent chain.Chain bindingsSoftware 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.Chain OwnerAn 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.Chain stateA 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).ChallengeWhen 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.Challenge bondThe 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.Challenge manager clientSoftware 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.Challenge PeriodThe 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.Challenge protocolThe 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.ChallengeManagerThe 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.Child chainAn Arbitrum Chain that settles to a Parent chain. For example, Arbitrum One and Arbitrum Nova are child chains of Ethereum.ClientA 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.CommitmentIn 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).ConfirmationThe 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.Cross-chain messageAn action taken on some chain A which asynchronously initiates an additional action on chain B.Custom Arb-TokenAny 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 ).Custom gas tokenA 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.Custom gatewayAny Token Gateway that isn't the StandardERC20 gateway.Data Availability CertificateSigned promise from a Data Availability Committee (DAC) attesting to the availability of a batch of data for an Arbitrum AnyTrust Chain.Data Availability Committee (DAC)A 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.Data Availability Server (DAS)The 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.Database SnapshotAn 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.Defensive ValidatorA Validator that watches an Arbitrum chain and takes action (i.e., bonds and challenges) only when and if an invalid Assertion occurs.Delay attackAn 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.Delayed InboxA contract that holds Parent chain initiated messages to be eventually included in the Sequencer Inbox. Inclusion of messages doesn't depend on the Sequencer.Deterministic provingIf 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 nodes.\n\nProving mode: Compiles to WebAssembly (), which transforms into WebAssembly for Arbitrum Virtual Machine (WAVM) for fraud-proof verification.\n\nDev-Tools DashboardDeprecated 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.DissectionA step in the Challenge protocol in which two challenging parties interactively narrow down their disagreement until they reach a One Step Proof.EdgeA 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.EIP-1559An 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.EIP-4844An 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.Ethereum WalletA software application used for transacting with the Ethereum Blockchain.Execution claimA cryptographic commitment to the computed state.Express LaneA 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.Express Lane ControllerAn 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.Externally Owned AccountsAn 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.Fast Exit / Liquidity ExitA 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.Fast FeedA 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.Fast withdrawalsA 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.Feed RelayA 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.First Come First Serve (FCFS)A 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.Force-InclusionCensorship resistant path for including a message into an Arbitrum chain via the Delayed Inbox on its Parent chain; bypasses any Sequencer involvement.ForwarderIn 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.Fraud proofA 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.Gas Price FloorProtocol-enforced minimum gas price on an Arbitrum chain. These values can be found on the chain info page.Gas targetThe 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.Gateway RouterContracts in the Arbitrum Token Bridge responsible for mapping tokens to their appropriate Token Gateway.Generic-Custom GatewayA 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.GethAn 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.Hard finalityThe 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.HashDBNitro'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.History commitmentA 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.Honest validatorA 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.Host I/OThe 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.InkThe 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.KeysetThe 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.L1L1, or Layer 1, refers to the underlying blockchain responsible for maintaining the integrity of the distributed ledger and executing smart contracts. See Layer 1.L2An L2, or Layer 2, is a trustless scaling solution built on top of Ethereum's Layer 1 (L1) base protocol. See Layer 2.L2 BlockData structure that represents a group of L2 transactions (analogous to L1 blocks).L2 to L1 MessageA 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.Layer 1 (L1)L1, 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.Layer 2 (L2)An 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).Layer 3 (L3)An Arbitrum chain whose core contract reside on an Arbitrum Layer 2 (L2) chain.Layer LeapA 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.MultiVMMultiVM refers to Arbitrum's ability to support multiple virtual machines (VMs). Specifically, Arbitrum introduces a WebAssembly ()-based virtual machine alongside the traditional Ethereum Virtual Machine (EVM). This means developers can write 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.Native Fee TokenAn 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.Native mint/burn gas tokenA 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.Offchain LabsThe 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.One Step ProofFinal 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.OneStepProverThe 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.OracleOracles 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.OutboxA 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.Parent chainEVM 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.\"PathDBA 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.PebbleThe 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.Permissionless validationThe 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.PortalA web application maintained by Offchain Labs showcasing the Arbitrum ecosystem; visit it here.Prechecker NodeAn 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.PrecompileA 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).Predecessor AssertionThe last confirmed valid state of the chain.Priority FeeThe 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.Priority Gas Auction (PGA)A 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.propAMMA 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.ProposerA 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.raasRaaS (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.RBlockRefer to AssertionReorgA 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.Retryable AutoredeemThe \"automatic\" (i.e., requiring no additional user action) execution of a Retryable Ticket on an Arbitrum chain.Retryable RedeemThe execution of a Retryable Ticket on a child chain; can be automatic (see Retryable Autoredeem) or manual via a user-initiated child chain transaction.Retryable TicketA parent-to-child cross-chain message initiated by a parent chain transaction sent to an Arbitrum chain for execution (e.g., a token deposit).Reverse Token GatewayA 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.RivalIn 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.Roll forwardIn 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.Rollup contractThe 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.Rollup Event InboxA 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.Rollup Improvement ProposalA Rollup Improvement Proposal (RIP) is a process for proposing, discussing, and recording changes or additions to Ethereum’s rollup ecosystem.SearcherA 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.SequencerAn 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).Sequencer FeedOffchain data feed published by the Sequencer which clients can subscribe to for Soft Confirmations of transactions before they are posted in batches.Sequencer InboxContract 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.Shared SequencingA protocol design space in which multiple rollups use the same entity as their Sequencer; potential benefits include enhanced interoperability and credible neutrality.Smart ContractA computer program whose operations are defined and executed within a blockchain consensus protocol.Soft ConfirmationA 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)Standard Arb-TokenAn token contract on an Arbitrum chain deployed via the StandardERC20 gateway; offers basic ERC-20 functionality in addition to deposit/withdrawal affordances.StandardERC20 gatewayToken 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.State manager backendSoftware 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.State PruningRemoving 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.State SchemeThe 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.State Transition FunctionThe 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).StylusUpgrade 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).TimeboostA 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.TimerThe 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.Token GatewayA 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.TransactionA user-initiated interaction with a Blockchain. Transactions are typically signed by users via wallets and are paid for via transaction fees.Transaction Ordering PolicyThe rules and logic employed by a chain to order incoming transactions into a block.TrustlessIn 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.Trustless bonding poolA 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.Trustless verificationValidators confirm assertions, ensuring transactions adhere to the protocol rules.Underlying ChainSynonymous with Parent chain.Upgrade ExecutorThe 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.Validating bridgeThe 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.ValidatorAn 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.Validator clientThe 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 softwareWalletWhen 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.WASMWidely 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.WASM module rootA 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.WASMerA 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.Watchtower ValidatorA 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.WAVMArbitrum'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.WETH GatewayToken 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.How is this guide?Chain infoChains information ArbitrumContributeLearn how to contribute to Arbitrum's open-source documentation.","tokens":11773,"squid":"spider-01","role":"Chain Spider","at":1791338544173,"hash":"fc7e5abd43909e107affbcd1eaef126e03a09805"}
{"url":"https://docs.arbitrum.io/build-decentralized-apps/machine-payments-protocol","domain":"docs.arbitrum.io","title":"Machine Payments Protocol (MPP)","text":"Machine Payments Protocol (MPP)This quickstart shows you how to implement the Machine Payments Protocol (MPP) on Arbitrum.Request an updateThis quickstart will guide you through implementing an Arbitrum-specific payment method plugin for the mppx library, which implements the Machine Payments Protocol (MPP). MPP defines a generic challenge → credential → settlement flow for payments between two parties:\n\nServer: the merchant/payee (the one that wants to get paid)\nClient: the payer (a user or AI agent)\n\nmppx itself is payment-method-agnostic. This plugin provides methods for settling payments on Arbitrum One or Arbitrum Sepolia with ERC-20 stablecoins (currently USDC) through EIP-3009 authorization, and with almost any ERC-20 via permit2.\nCore concepts\nThe client (payer) never broadcasts a transaction and never pays gas.\n\nThe merchant requests payment (issues a challenge).\nThe payer signs an EIP-712 typed-data authorization offchain—no gas, no prior onchain approval is needed.\nThe merchant's server submits the signature onchain, completing the fund transfer. The merchant pays for the gas.\n\nThis is exactly the \"402 Payment Required\" flow you'd want for machine/agent commerce: an HTTP request hits a paywalled endpoint, the agent signs a payment authorization, and the server settles it atomically before serving the response.\nIt supports two settlement mechanisms:\nTypeOnchain mechanismSupports splits?Need prior approval?authorizationEIP-3009 transferWithAuthorization (native to USDC)❌❌permit2Uniswap's Permit2 permitWitnessTransferFrom✅ (pay multiple recipients in one transaction)✅ payer must pre-approve Permit2 on the token once\nOther optionstransaction and hash credential types are stubbed but intentionally not implemented—these have weaker challenge-binding and carry fraud risk.\nMPP Flow\nWhat the client does\ncharge() returns a Method.toClient handler. In createCredential:\n\nValidates the challenge’s chainId is supported and unexpired.\nChecks the payer’s token balance onchain (balanceOf).\nBranches on credentialTypes:\n\npermit2 (or undefined): builds permitted/transferDetails arrays (handling splits, with the primary recipient pushed to the front), derives the nonce from a challenge hash, and signs the Permit2 witness typed-data.\n\npermit2 splitsThe sum of the amounts in the split must be strictly lower than the total amount for the transaction. So if the total transaction is 10,000 and splits have two recipients that will receive 2,000 and 3,000—the main recipient will receive 5,000.\n\nauthorization: derives nonce = keccak256(challenge.id, challenge.realm) for challenge-binding (anti-replay), looks up the token's EIP-712 domain from the local erc3009Tokens registry (not an onchain query), and signs the TransferWithAuthorization struct.\n\nReturns Credential.serialize(...). No transaction is broadcast.\n\nWhat the server does\ncharge() returns a Method.toServer handler. In verify(credential, request), it independently re-derives and re-checks every value the client claimed (recipient, amount, deadline, nonce/challenge-hash, signature via verifyTypedData, balance, and, for permit2, the Permit2 allowance and split amounts). Then it:\n\nSimulates the transaction with eth_call (so a bad credential doesn’t waste gas).\nSubmits transferWithAuthorization (authorization) or permitWitnessTransferFrom (permit2) from the merchant’s account.\nwaitForTransactionReceipt, then verifies the emitted Transfer logs match the expected recipients/amounts.\nReturns an mppx Receipt: method: \"arbitrum\", status: \"success\", timestamp, reference: txHash.\n\nHow to implement it — server (merchant) side\nmppx has an Express adapter:\nimport express from 'express';\nimport { Mppx } from 'mppx/express';\nimport { privateKeyToAccount } from 'viem/accounts';\nimport { charge } from '@arbitrum/mpp/server';\nimport * as defaults from '@arbitrum/mpp/default';\n\nconst account = privateKeyToAccount(process.env.SERVER_PRIVATE_KEY as `0x${string}`);\nconst app = express();\n\nconst mppx = Mppx.create({\n methods: [\n charge({\n recipient: account.address, // where funds land\n currency: defaults.TOKEN_CONTRACTS.USDC_ARBITRUM_SEPOLIA, // which token\n methodDetails: { chainId: 421614, decimals: 6 },\n account, // pays gas to settle\n }),\n ],\n secretKey: process.env.SERVER_PRIVATE_KEY,\n});\n\n// Gate an endpoint behind a charge:\napp.get(\n '/authorization',\n mppx.charge({\n amount: '1000', // raw units: 1000 = 0.001 USDC (6 decimals)\n description: 'My favorite food',\n methodDetails: { chainId: 421614, credentialTypes: ['authorization'] },\n }),\n (req, res) => res.json({ data: 'authorization worked!' }), // only runs after payment settles\n);\n\napp.listen(3000);\n\nSet credentialTypes to ['permit2'] to use Permit2 instead, and add a splits: [...] array to pay multiple recipients in one transaction.\n⚠️ amount uses raw token units — human-readable decimal conversion isn't supported yet.\n\nHow to implement it - client (payer) side\nimport { Mppx } from 'mppx/client';\nimport { privateKeyToAccount } from 'viem/accounts';\nimport { charge } from '@arbitrum/mpp/client';\n\nconst account = privateKeyToAccount(process.env.CLIENT_PRIVATE_KEY as `0x${string}`);\n\nconst mppx = Mppx.create({\n methods: [charge({ account, chainId: 421614 })],\n});\n\n// mppx intercepts the 402, signs the challenge, retries automatically:\nconst response = await mppx.fetch('http://localhost:3000/authorization');\nconst data = await response.json();\nconsole.log(`Response: ${data}`); // Payment response ('authorization worked!')\nconst receipt = response.headers.get('payment-receipt'); // base64-encoded mppx Receipt\nconsole.log(Buffer.from(receipt!, 'base64').toString('binary')); // Transaction information including hash\nRun the bundled example locally\npnpm install\n\n# .env (copy from .env.example)\nCLIENT_PRIVATE_KEY=0x... # this wallet needs USDC on Arbitrum Sepolia\nSERVER_PRIVATE_KEY=0x... # this wallet needs ETH (gas) on Arbitrum Sepolia\n\n# Terminal 1\npnpm run server # tsx test/server → listens on :3000\n\n# Terminal 2\npnpm run client # tsx test/client → hits /authorization, signs, settles\nFunding requirements\n\nServer needs ETH on the chain (it pays gas to submit the settlement transaction).\nClient needs USDC on the same chain (the funds being pulled).\nFor Permit2, the client must first approve the Permit2 contract (0x000000000022D473030F116dDEE9F6B43aC78BA3) as a spender on the USDC token—Permit2 can’t move tokens it hasn’t been allowed to.\n\nCurrent limitations\n\nOnly USDC on Arbitrum One/Sepolia is registered. To add a token, register its address and EIP-712 name/version/chainId.\namount is raw units only—no human-readable decimal conversion yet.\nFor authorization, the validBefore expiry is trusted from the server's challenge; a far-future expiry theoretically widens the window in which an unsubmitted authorization could be settled late. (Note: the EIP-3009 nonce is challenge-bound—keccak256(id, realm)—and single-use onchain, so a literal replay of an already-settled authorization is blocked once the nonce is consumed.)\ntransaction and hash credential types are intentionally unimplemented (weak challenge-binding).\nStatus is v0.1.0 — early/experimental.\n\nReference links\n\nProtocol overview\nCustom/first-party SDK\nMethod.from\nMethod.toServer\nMethod.toClient\nUnified EVM Spec\nEIP-3009 Transfer with Authorization\nHow is this guide?Arbitrum: introductionFrequently asked questions about Arbitrum, a finance-native blockchain platform.Chain infoChains information Arbitrum","tokens":1867,"squid":"spider-01","role":"Chain Spider","at":1791338556542,"hash":"743a5ee820ad6d837d9b75ada24e370ce306b76d"}
{"url":"https://docs.phantom.com/phantom-mcp-server","domain":"docs.phantom.com","title":"Phantom MCP server - Phantom developer documentation","text":"The Phantom MCP server (@phantom/mcp-server) is a Phantom wallet product for users who interact through AI agents. Just like the mobile wallet and browser extension serve users who click and tap, the MCP server serves users who interact through natural language with their AI assistant.\nWhen someone uses Claude, Cursor, or another AI agent and asks “send 10 USDC to my friend” or “swap some SOL for ETH,” Phantom’s MCP server is the wallet the agent uses to act on their behalf.\n\n​What are you here for?\n\n​Quick install\nNo App ID or Phantom Portal setup required. Add this config to your AI client:\n{\n \"mcpServers\": {\n \"phantom\": {\n \"command\": \"npx\",\n \"args\": [\"-y\", \"@phantom/mcp-server@latest\"]\n }\n }\n}\n\nOn first use, a browser window opens for device-code sign-in. See the setup guide for step-by-step instructions for Claude Desktop, Cursor, and Claude Code.\nAgents receive a new dedicated wallet on authentication — not your existing personal wallet. You must fund the agent’s wallet before it can transact. Use get_wallet_addresses to find the address after setup.\n​What agents can do\nThe MCP server gives agents wallet, swap, and perp-trading tools. See the setup guide and tool reference for full parameter documentation.\nNo fees on swaps. All swaps executed through buy_token and portfolio_rebalance are fee-free.\nSui support has been deprecated.\nWallet operations\nToolDescriptionget_connection_statusCheck if the wallet session is activeget_wallet_addressesGet addresses for Solana, Ethereum, Bitcoin, and Sui. Sui address support has been deprecated.get_token_balancesView token holdings with live USD pricingtransfer_tokensTransfer SOL, ETH, and SPL/ERC-20 tokens with a simulation-first flowsend_solana_transactionSimulate, sign, and broadcast Solana transactionssend_evm_transactionSimulate, sign, and broadcast EVM transactionssign_solana_messageSign UTF-8 messages on Solanasign_evm_personal_messageEIP-191 personal message signingsign_evm_typed_dataEIP-712 structured data signingsimulate_transactionPreview asset changes for a transaction without submitting on-chainget_token_allowanceCheck ERC-20 token allowance for a spender addressphantom_loginRe-authenticate, switch accounts, or refresh a sessionpay_api_accessPay for daily API access when quota is consumed\nSwaps and portfolio\nToolDescriptionbuy_tokenSwap tokens via Phantom routing (Solana, EVM, cross-chain). No fees on swaps.portfolio_rebalanceAnalyze and rebalance portfolio allocation via token swaps\nPerps\nToolDescriptionget_perp_marketsList perp markets with price, funding, open interest, and max leverageget_perp_accountView perp account balance and available marginget_perp_positionsList open positions, leverage, PnL, and liquidation priceget_perp_ordersList open perp ordersget_perp_trade_historyView historical fills, fees, and closed PnLdeposit_to_hyperliquidBridge/swap into the perp accountopen_perp_positionOpen a long or short perp positionclose_perp_positionClose a perp position fully or partiallycancel_perp_orderCancel an open perp orderupdate_perp_leverageUpdate leverage and margin modetransfer_spot_to_perpsMove USDC from Hypercore spot to perpswithdraw_from_perpsBridge USDC from perps directly to an external chain\n\n​Supported clients\nClientHow to connectClaude DesktopAdd to claude_desktop_config.jsonCursorAdd to ~/.cursor/mcp.json (or use the Phantom Cursor plugin)Claude Codeclaude mcp add phantom -- npx -y @phantom/mcp-server@latest\n​How agent wallets sign\nAgent wallets complete a Phantom Connect sign-in, then use an OIDC stamper to stamp KMS requests. KMS validates the stamp, enforces policy, and then signs and submits.\n\n​Related\nWas this page helpful?","tokens":917,"squid":"spider-10","role":"Tooling Spider","at":1791338568725,"hash":"842a9072a308929326210573f48a2905b8b69686"}
{"url":"https://developers.jup.ag/docs/resources/audits","domain":"developers.jup.ag","title":"Audits - Jupiter Developers","text":"Jupiter protocols are audited by reputable security firms to ensure the highest level of security and reliability. The following section provides the audits of Jupiter’s protocols. To report a vulnerability, use the bug bounty program listed on the Security page.\n​Jupiter Swap\n\nOffside Labs: October 2025 (v6)\nOffside Labs: April 2024 (v6)\nSec3 (v3)\n\n​Jupiter Perpetuals\n\nOffside Labs\n\nOtterSec\n\nSec3\n\n​Jupiter Lend\n\nCertora - Formal Verification Report 2: January 7 - March 31, 2026\n\nCode4rena Report: February 12 - March 13, 2026\n\nCertora - Formal Verification Report: September 15 - December 1, 2025\n\nOtterSec Report 2: November 12 - November 20, 2025\n\nOtterSec Report: August 20 - November 1, 2025\n\nOffside Labs - Oracle and Flashloan Report: Oct 13 - Oct 19, 2025\n\nMixbytes - Vault Report: July 28 - October 14, 2025\n\nOffside Labs - Vault Report: July 23 - August 4, 2025\n\nOffside Labs - Liquidity Report: July 10 - July 18, 2025\n\nZenith Report: June 24 - July 31, 2025\n\n​Jupiter Lend AMM\n\nOtterSec - Vault Integration Report: May 8 - June 17, 2026\n\nNeodyme Report: May - June 2026\n\nNeodyme - Operational Security Report: May - June 2026\n\nOtterSec Report: May 19 - June 4, 2026\n\nZenith Report: April 14 - May 11, 2026\n\n​Jupiter Limit Order\n\nOffside Labs (v2)\n\n​Jupiter Lock\n\nOtterSec\n\nSec3\n\n​Jupiter DAO\n\nOffside Labs\n\nWas this page helpful?","tokens":337,"squid":"spider-02","role":"Liquidity Spider","at":1791338568859,"hash":"1e0a465200020c0035556ac8f10768b4faab0249"}
{"url":"https://akash.network/","domain":"akash.network","title":"Akash Network - Decentralized Compute Marketplace","text":"The Open Cloud for AI's Next Frontier Tap into global GPU power at a fraction of the cost. \nRead Razer Case Study\n Get StartedAI Inference on AkashMLAccess leading open-source models instantly via drop-in, OpenAI-compatible APIs. Experience sub-second latency and drastically lower costs than traditional cloud providers without managing the underlying infrastructure.Launch AkashMLDeploy on Akash ConsoleMigrate your Docker containers to an independent cloud network. Use pre-built templates or supply an SDL configuration file to spin up raw compute directly on sovereign infrastructure.Deploy NowBecome a Compute ProviderMonetize your idle server capacity. Run our provider software to list your GPU and CPU hardware on the global network and automatically earn revenue from enterprise deployments.Become a ProviderGet StartedAI Inference on AkashMLAccess leading open-source models instantly via drop-in, OpenAI-compatible APIs. Experience sub-second latency and drastically lower costs than traditional cloud providers without managing the underlying infrastructure.Launch AkashMLDeploy on Akash ConsoleBecome a Compute Provider The Efficiency Gap Market-driven pricing vs. legacy markups. View Pricing Page \nChoose a GPU Model\n 1 1h 1 1h \nAkash\n $2.59/hr Save 59% Deploy Now \nCoreweave\n $6.31/hr \nAWS\n $7.91/hr \nGoogle Cloud\n $10.44/hr View Pricing Page Why the gap? Legacy providers set static rates to protect corporate margins. Akash prices are determined by a global reverse auction to maximize hardware utilization. You pay for the silicon, not the provider's overhead.\n How It WorksGo from configuration to an active workload in seconds.1Configure your deploymentSelect a template or supply your own container image. Specify required resources like GPUs, region, and maximum price to send your request out to the network.Llama 3.1 70BAIH200H100A100ImageModelGPUCPUMemoryMax price2Automated biddingIndependent infrastructure providers meeting your exact requirements automatically submit competitive bids in real time. You see who is offering the hardware and the precise rate.3Authorize and executeAccept the optimal bid to open the lease. The network handles the backend routing instantly, initializing your container and spinning up a live endpoint for your workloads.How It WorksGo from configuration to an active workload in seconds.1Configure your deploymentSelect a template or supply your own container image. Specify required resources like GPUs, region, and maximum price to send your request out to the network.2Automated bidding3Authorize and executeDeploy Now Llama 3.1 70BAIH200H100A100ImageModelGPUCPUMemoryMax price Supercloud for AIStop overpaying for gated compute. Deploy on a global marketplace of high-density GPUs to maximize your engineering runway.Docker NativeNo refactoring. If it runs in a container, it runs on Akash. Migrate your stack from legacy providers with zero changes to your application code.Train 3x LongerH100s for $1.33/hr vs AWS at $3.93/hr. Get nearly 3 hours of compute for the price of 1. Transparent pricing, no hidden fees.1-Click TemplatesLaunch pre-configured environments for Llama 3, DeepSeek, and Stable Diffusion in seconds. Move from configuration to active container in less than 60 seconds.Global Silicon SupplyAccess enterprise-grade H100s and A100s alongside high-performance consumer RTX 5090s. Scale from single-node inference to massive interconnected training clusters on demand.Ray Distributed ClustersScale your machine learning workloads instantly. Provision multi-node Ray clusters to train and fine-tune large-scale models natively, eliminating complex manual cluster orchestration.Operational AutonomyRetain absolute control over your network routing and data residency. Moving away from closed, proprietary ecosystems protects your application stack from single-provider lock-in and vendor dependencies. \nRazer Powers Viral AIInference on Akash\n\nTo scale its global AVA Mini campaign, Razer integrated its open-source AIKit platform with the Akash independent compute network. By pooling distributed high-performance consumer GPUs behind a single managed endpoint, the engineering team achieved reliable elastic scaling with zero manual infrastructure intervention.\n $0.01 per generated image 3.24s avg. end-to-end response time 15x lower inference costs than centralized APIs \nRead Case Study\n \"The future of AI isn't just better models – it's efficient infrastructure. With Razer AIKit, many use cases already run locally. With Akash Network, we extend that into a decentralised cloud to scale efficiently.\"QUYEN QUACHVice President of Software, Razer Global Grid. No Off Switch.Access a global network engineered for high availability. While centralized clouds rely on single points of failure, Akash uses a distributed protocol to keep your workloads independent and resilient against system-wide failure.Explore Compute Providers \nStart Building\n\nLaunch containerized AI workloads via our self-serve console, or coordinate custom enterprise infrastructure configs with our team.\n\nGet in Touch","tokens":1269,"squid":"spider-03","role":"Compute Spider","at":1791338571708,"hash":"aab73a1d3a446500ea9dc0f1a52f777eead63dc5"}
{"url":"https://akash.network/use-cases/","domain":"akash.network","title":"Use Cases — Akash Network","text":"Use Cases\n\nFrom high-growth AI startups to global data centers, teams use Akash to deploy scalable container workloads and monetize enterprise compute.\n AI Inference & Training Run AI inference and training on GPUs rented from independent providers. OpenAI-compatible endpoints through AkashML, or bring your own container. \nLearn more\n Enterprise Reserved NVIDIA B300, B200, H200, H100, and A100 GPU capacity with confidential computing, InfiniBand networking, bare metal access, and dedicated enterprise support. \nLearn more\n Academic & Institutional Research Open research needs open compute. Akash provides academic institutions with cost-effective, permissionless access to high-performance compute for AI and scientific workloads. \nLearn more\n Compute Providers Connect your servers to Akash and let tenants bid on unused CPU, GPU, memory, and storage. You set the minimum price. \nLearn more\n Startups Skip the sales calls and waitlists. Akash gives early-stage teams direct access to GPU capacity priced by open bidding — no markups, no lock-in. \nLearn more","tokens":266,"squid":"spider-03","role":"Compute Spider","at":1791338593550,"hash":"db8e7edbb1c724220b2ce839785e01835e26aca5"}
{"url":"https://consensysdiligence.github.io/smart-contract-best-practices/development-recommendations/","domain":"consensysdiligence.github.io","title":"Index - Ethereum Smart Contract Best Practices","text":"Index\n\nTip\nFor comprehensive insights into secure development practices, consider visiting the Development Recommendations section of the Smart Contract Security Field Guide. This resource provides in-depth articles to guide you in developing robust and secure smart contracts.\n\nThe development recommendations are split into six categories.\n\nCategory\nDescription\n\nGeneral\nGuiding principles that should be kept in mind during development.\n\nPrecautions\nPrinciples that prevent attacks in general or avoid excessive damage in the worst case scenario.\n\nSolidity-specific\nHelpful tips when building smart contracts in Solidity - including interesting quirks.\n\nToken-specifc\nRecommendations to honour when dealing with or implementing tokens\n\nDocumentation\nGuidelines on how to properly document smart contracts and the processes surrounding them.\n\nDeprecated\nVulnerabilities that were applicable in the past but can be reasonably excluded nowadays.","tokens":236,"squid":"spider-06","role":"Security Spider","at":1791338594410,"hash":"e5442b899ac1aecc9c6899579492f9cd00bb50f5"}
{"url":"https://akash.network/use-cases/enterprise/","domain":"akash.network","title":"Enterprise GPU Infrastructure & AI Compute | Akash","text":"High-Performance Compute for Enterprise AI\n\nReserved NVIDIA B300, B200, H200, H100, and A100 GPU capacity for enterprise AI workloads. Run training, inference, and production AI workloads with \nconfidential computing\n\nand flexible infrastructure.\n\nTalk to Sales \nTry Self-Serve \nTrusted by leading AI teams\n\nBuilt for enterprise AI at scale\n Reserved GPU Capacity Guaranteed capacity for your term Reserved B300, B200, H200, H100, and A100 — committed for your term, bare metal available, SLA-backed. No multi-year lock-in. Confidential Computing Hardware-level data protection Protect sensitive AI workloads with hardware-based Trusted Execution Environments (TEEs), keeping data, model inputs, outputs, and model weights protected. InfiniBand GPU Networking High-bandwidth interconnect Deploy high-bandwidth GPU-to-GPU interconnect for multi-node distributed training, including NCCL workloads. Bare Metal GPU Access Full hardware control Dedicated physical GPU servers with no virtualization layer — full hardware control, near-native performance, and no shared tenancy. Available under reserved arrangements. Dedicated Enterprise Support Direct access to the technical team Direct access to the technical team for AI infrastructure onboarding, architecture guidance, deployment support, and defined response times. Transparent Pricing No hidden fees Simple, upfront pricing for GPU compute with no hidden fees or unexpected infrastructure costs. No egress fees. \nResults from teams running production on Akash\n Razer \n$0.01 per image · 3.24s avg response · 15× lower inference cost\n\nProduction AI image generation for the AVA Mini campaign — running across distributed GPU infrastructure at commodity pricing.\n Venice \nH100 GPUs · strict data retention · no prompt or output logging\n\nVenice runs its image generation models on H100 GPUs rented through Akash. Built around user privacy, with no prompt or output retention — dedicated GPU capacity with strict data retention policies is a structural requirement.\n \"The future of AI isn't just better models, it's efficient infrastructure. With Akash Network, we extend into a decentralised cloud to scale efficiently.\"QUYEN QUACHVice President of Software, Razer Astria \nDocker startup dropped from 40–60 min to seconds\n\nAstria runs production image generation on Akash GPUs, fine-tuning on their own product shots and generating on-brand campaign assets. After more than a year in production, Docker image startup dropped from as long as 40–60 minutes on a prior provider to seconds on Akash.\n Passage \n50% lower GPU cost vs. reserved AWS pricing\n\nPassage powers immersive virtual events for brands and creators with high-performance GPUs at a fraction of hyperscaler pricing.\n \"Akash gave us exactly what we needed: high-performance GPUs at 50% lower cost... Even if we were to reserve GPUs on AWS for an entire year, we would not see the same cost savings as Akash provides.\"AREL AVELLINOCEO of Passage \nRead the case studies\n\nFAQs\n No. You run open models on infrastructure you control, so your prompts, outputs, and proprietary data never enter a vendor's training loop. Unlike commercial LLM APIs, whose terms often allow training on your content, nothing you send leaves your boundary.Uptime commitments are set per engagement. Akash works with you to define the availability target your workload requires, then matches you with providers and a deployment architecture that can meet it. Reserved capacity agreements can include contractual uptime terms defined in the SLA.By invoice, in USD. Terms are set per customer, with standard net terms as the default.Any containerized workload. Deploy open models such as GLM, Kimi, Qwen, and DeepSeek (or your own models) using standard Docker, with any framework, language, or runtime. Common workloads include inference, training and fine-tuning, RAG, rendering, and batch compute.Enterprise customers are matched with SOC 2 compliant providers. HIPAA and other certifications are handled case by case, since requirements vary by industry and workload. Bring your compliance requirements to the conversation and Akash will scope provider selection, deployment architecture, and controls against them.Yes. Akash supports multi-GPU and multi-node workloads, including distributed AI training and inference. InfiniBand networking and NCCL can be used for high-performance GPU-to-GPU communication where supported by the deployment configuration.GPU capacity is available across multiple regions through Akash's global provider network. Enterprise customers can discuss preferred regions, GPU types, capacity requirements, and deployment locations with the Akash team.Yes. Teams can validate on the open marketplace at on-demand GPU pricing first, then move steady workloads to reserved capacity. The console.akash.network is self-serve; no contract is needed to evaluate. \nTalk to an enterprise specialist.\n\nScope capacity, terms, and onboarding for your workloads. We typically respond within 3 business days.\n\nTalk to Sales \nTry Self-Serve","tokens":1261,"squid":"spider-03","role":"Compute Spider","at":1791338610286,"hash":"3aa477f068c63bb5d57c51dcc57a46ee2ad7a735"}
{"url":"https://consensysdiligence.github.io/smart-contract-best-practices/development-recommendations/precautions/rate-limiting/","domain":"consensysdiligence.github.io","title":"Rate Limiting - Ethereum Smart Contract Best Practices","text":"Rate Limiting\n\nTip\nFor comprehensive insights into secure development practices, consider visiting the Development Recommendations section of the Smart Contract Security Field Guide. This resource provides in-depth articles to guide you in developing robust and secure smart contracts.\n\nRate limiting halts or requires approval for substantial changes. For example, a depositor may only\nbe allowed to withdraw a certain amount or percentage of total deposits over a certain time period\n(e.g., max 100 ether over 1 day) - additional withdrawals in that time period may fail or require\nsome sort of special approval. Or the rate limit could be at the contract level, with only a\ncertain amount of tokens issued by the contract over a time period.\nExample:\nuint internal period; // how many blocks before limit resets\nuint internal limit; // max ether to withdraw per period\nuint internal currentPeriodEnd; // block which the current period ends at\nuint internal currentPeriodAmount; // amount already withdrawn this period\n\nconstructor(uint _period, uint _limit) public {\n period = _period;\n limit = _limit;\n\n currentPeriodEnd = block.number + period;\n}\n\nfunction withdraw(uint amount) public {\n // Update period before proceeding\n updatePeriod();\n\n // Prevent overflow\n uint totalAmount = currentPeriodAmount + amount;\n require(totalAmount >= currentPeriodAmount, 'overflow');\n\n // Disallow withdraws that exceed current rate limit\n require(currentPeriodAmount + amount < limit, 'exceeds period limit');\n currentPeriodAmount += amount;\n msg.sender.transfer(amount);\n}\n\nfunction updatePeriod() internal {\n if(currentPeriodEnd < block.number) {\n currentPeriodEnd = block.number + period;\n currentPeriodAmount = 0;\n }\n}","tokens":429,"squid":"spider-06","role":"Security Spider","at":1791338612886,"hash":"882695497833cc89047fa658be87d4402498b705"}
{"url":"https://www.paradigm.xyz/writing/kryptos","domain":"paradigm.xyz","title":"Kryptos","text":"Project Kryptos Kryptos is one of the most famous cryptographic mysteries of our time.Since its unveiling at CIA headquarters in 1990, Jim Sanborn's sculpture has taunted the world's best codebreakers and puzzle enthusiasts. The NSA solved three of the four passages of its encrypted message. So did Jim Gillogly, a California cryptographer, working alone in 1999. But the fourth passage, K4, has remained unsolved for more than three decades.When Jim put his private Kryptos archive up for auction in November of last year, we knew we wanted to play a part in protecting this unique piece of cryptographic history. We’re honored to announce that we are the new stewards of the Kryptos secret. And in keeping with our love of puzzles, we decided not to ruin the mystery even for ourselves: We worked with Jim and used modern cryptography to set up an automated system to verify submissions without us ever seeing the answer.We also want to encourage the development of more sophisticated techniques for solving the puzzle. So, in addition to unveiling a new site for K4, we’re hosting an ongoing capture-the-flag-style challenge featuring 10 new puzzles we created, each with a $1,000 prize. Securing Kryptos from everyone — even ourselvesCryptography makes digital trust possible. It's why you can send a message only one person can read, and why digital money works without banks. It's also puzzle-solving at its purest.For Kryptos, we’re keeping K4’s answer secret from ourselves, while preserving our ability to verify if submissions are correct. We used one-way cryptographic functions and secure hardware to lock Jim's answer in a system that confirms correct solutions without anyone (including us) ever seeing what he wrote.You can see the answers to K1, K2 and K3 on our new site, and when you think you've solved K4, you can submit your answer there as well. The verifier checks it against a solution that Sanborn provided. To prevent brute forcing the solution, there’s a $1 fee to submit an answer. Sanborn also provided the ciphertext for another 97-character puzzle, known as K5, that he created at the same time. We plan to release K5 in the future.Kryptos has endured for more than 13,000 days. Thousands have tried to crack it. CIA employees walk past it every day. It's been featured in novels, analyzed in academic papers, and debated in forums worldwide. But it's still unsolved.The clues are out there. The tools are better than ever. And now there's an automated system that verifies your solution instantly. It’s your turn to try to solve K4. Q&AWhat is the capture-the-flag challenge? We want to encourage the development of tools to better attack problems like K4. There has been an explosion in AI-assisted attempts on Kryptos, but none have succeeded yet. One possible reason is that there is no feedback loop that solvers can use to test if their tools are getting better at attacking these kinds of problems.\n\nOur virtual capture-the-flag challenge features 10 new Kryptos-style puzzles of increasing difficulty. Anyone can participate. The challenge is live now and there will be cash prizes of $1,000 for the first solver of each puzzle. The puzzles and leaderboard will remain open until the puzzles are solved. Official rules can be found here.How does your technical solution for K4 verification work? We set up a new computer with a terminal for Jim to enter the plaintext solution to K4. On that device, a program ran the plaintext through a one-way function (a SHA256 hash). It sent the hash to Google’s Cloud Key Management Service, which generated a unique verification tag (a hash-based message authentication code, or HMAC) that can only be reproduced by sending a SHA256 hash of the plaintext to the same cloud-based key. The plaintext never left the device, and we wiped the laptop afterward.What do I get if I solve K4? The answer. \nSpecial acknowledgment to Dave White and samczsun for their partnership and help throughout this project. \n “Kryptos” © Copyright 1988 James Sanborn Artist Jim Sanborn and Paradigm General Partner Dan Robinson at Jim's studio on Chesapeake Bay, 2026. Mini Kryptos Archive Item Paradigm Kryptos Proof of Concept Curved Copper Plate Paradigm","tokens":1054,"squid":"spider-04","role":"Research Spider","at":1791338620193,"hash":"0210377e111b3eb5d5f0368c72e8cc2132fad16b"}
{"url":"https://consensysdiligence.github.io/smart-contract-best-practices/development-recommendations/general/external-calls/","domain":"consensysdiligence.github.io","title":"External Calls - Ethereum Smart Contract Best Practices","text":"External Calls\n\nTip\nFor comprehensive insights into secure development practices, consider visiting the Development Recommendations section of the Smart Contract Security Field Guide. This resource provides in-depth articles to guide you in developing robust and secure smart contracts.\n\nUse caution when making external calls¶\nCalls to untrusted contracts can introduce several unexpected risks or errors. External calls may\nexecute malicious code in that contract or any other contract that it depends upon. As such,\nevery external call should be treated as a potential security risk. When it is not possible, or\nundesirable to remove external calls, use the recommendations in the rest of this section to\nminimize the danger.\n\nMark untrusted contracts¶\nWhen interacting with external contracts, name your variables, methods, and contract interfaces in\na way that makes it clear that interacting with them is potentially unsafe. This applies to your\nown functions that call external contracts.\n// bad\nBank.withdraw(100); // Unclear whether trusted or untrusted\n\nfunction makeWithdrawal(uint amount) { // Isn't clear that this function is potentially unsafe\n Bank.withdraw(amount);\n}\n\n// good\nUntrustedBank.withdraw(100); // untrusted external call\nTrustedBank.withdraw(100); // external but trusted bank contract maintained by XYZ Corp\n\nfunction makeUntrustedWithdrawal(uint amount) {\n UntrustedBank.withdraw(amount);\n}\n\nAvoid state changes after external calls¶\nWhether using raw calls (of the form someAddress.call()) or contract calls (of the form\nExternalContract.someMethod()), assume that malicious code might execute. Even if\nExternalContract is not malicious, malicious code can be executed by any contracts it calls.\nOne particular danger is malicious code may hijack the control flow, leading to vulnerabilities due\nto reentrancy. (See Reentrancy for a fuller discussion of this\nproblem).\nIf you are making a call to an untrusted external contract, avoid state changes after the call.\nThis pattern is also sometimes known as the\nchecks-effects-interactions pattern.\nSee SWC-107\n\nDon't use transfer() or send().¶\n.transfer() and .send() forward exactly 2,300 gas to the recipient. The goal of this hardcoded\ngas stipend was to prevent reentrancy vulnerabilities, but this only\nmakes sense under the assumption that gas costs are constant. Recently\nEIP 1884 was included in the Istanbul hard fork. One of\nthe changes included in EIP 1884 is an increase to the gas cost of the SLOAD operation, causing a\ncontract's fallback function to cost more than 2300 gas.\nIt's recommended to stop using .transfer() and .send() and instead use .call().\n// bad\ncontract Vulnerable {\n function withdraw(uint256 amount) external {\n // This forwards 2300 gas, which may not be enough if the recipient\n // is a contract and gas costs change.\n msg.sender.transfer(amount);\n }\n}\n\n// good\ncontract Fixed {\n function withdraw(uint256 amount) external {\n // This forwards all available gas. Be sure to check the return value!\n (bool success, ) = msg.sender.call.value(amount)(\"\");\n require(success, \"Transfer failed.\");\n }\n}\n\nNote that .call() does nothing to mitigate reentrancy attacks, so other precautions must be\ntaken. To prevent reentrancy attacks, it is recommended that you use the\nchecks-effects-interactions pattern.\n\nHandle errors in external calls¶\nSolidity offers low-level call methods that work on raw addresses: address.call(),\naddress.callcode(), address.delegatecall(), and address.send(). These low-level methods never\nthrow an exception, but will return false if the call encounters an exception. On the other hand,\ncontract calls (e.g., ExternalContract.doSomething()) will automatically propagate a throw (for\nexample, ExternalContract.doSomething() will also throw if doSomething() throws).\nIf you choose to use the low-level call methods, make sure to handle the possibility that the call\nwill fail, by checking the return value.\n// bad\nsomeAddress.send(55);\nsomeAddress.call.value(55)(\"\"); // this is doubly dangerous, as it will forward all remaining gas and doesn't check for result\nsomeAddress.call.value(100)(bytes4(sha3(\"deposit()\"))); // if deposit throws an exception, the raw call() will only return false and transaction will NOT be reverted\n\n// good\n(bool success, ) = someAddress.call.value(55)(\"\");\nif(!success) {\n // handle failure code\n}\n\nExternalContract(someAddress).deposit.value(100)();\n\nSee SWC-104\n\nFavor pull over push for external calls¶\nExternal calls can fail accidentally or deliberately. To minimize the damage caused by such\nfailures, it is often better to isolate each external call into its own transaction that can be\ninitiated by the recipient of the call. This is especially relevant for payments, where it is\nbetter to let users withdraw funds rather than push funds to them automatically. (This also reduces\nthe chance of problems with the gas limit.) Avoid\ncombining multiple ether transfers in a single transaction.\n// bad\ncontract auction {\n address highestBidder;\n uint highestBid;\n\n function bid() payable {\n require(msg.value >= highestBid);\n\n if (highestBidder != address(0)) {\n (bool success, ) = highestBidder.call.value(highestBid)(\"\");\n require(success); // if this call consistently fails, no one else can bid\n }\n\n highestBidder = msg.sender;\n highestBid = msg.value;\n }\n}\n\n// good\ncontract auction {\n address highestBidder;\n uint highestBid;\n mapping(address => uint) refunds;\n\n function bid() payable external {\n require(msg.value >= highestBid);\n\n if (highestBidder != address(0)) {\n refunds[highestBidder] += highestBid; // record the refund that this user can claim\n }\n\n highestBidder = msg.sender;\n highestBid = msg.value;\n }\n\n function withdrawRefund() external {\n uint refund = refunds[msg.sender];\n refunds[msg.sender] = 0;\n (bool success, ) = msg.sender.call.value(refund)(\"\");\n require(success);\n }\n}\n\nSee SWC-128\n\nDon't delegatecall to untrusted code¶\nThe delegatecall function is used to call functions from other contracts as if they belong to the\ncaller contract. Thus the callee may change the state of the calling address. This may be insecure.\nAn example below shows how using delegatecall can lead to the destruction of the contract and\nloss of its balance.\ncontract Destructor\n{\n function doWork() external\n {\n selfdestruct(0);\n }\n}\n\ncontract Worker\n{\n function doWork(address _internalWorker) public\n {\n // unsafe\n _internalWorker.delegatecall(bytes4(keccak256(\"doWork()\")));\n }\n}\n\nIf Worker.doWork() is called with the address of the deployed Destructor contract as an\nargument, the Worker contract will self-destruct. Delegate execution only to trusted contracts,\nand never to a user supplied address.\n\nWarning\nDon't assume contracts are created with zero balance. An attacker can send ether to the\naddress of a contract before it is created so contracts should not assume that their initial state\ncontains a zero balance. See\nissue 61 for more details.\nSee SWC-112","tokens":1737,"squid":"spider-06","role":"Security Spider","at":1791338622703,"hash":"69731f2358cb9df2ea4fa9ef03989c68e53bc77c"}
{"url":"https://console.akash.network/privacy-policy","domain":"console.akash.network","title":"Privacy Policy | Akash Console","text":"Privacy Policy for Akash ConsoleAt Akash Console, accessible from https://console.akash.network, one of our main priorities is the privacy of our visitors. This Privacy Policy document contains types of information that is collected and recorded by Overclock Labs Inc. and how we use it.If you have additional questions or require more information about our Privacy Policy, do not hesitate to contact us.This Privacy Policy applies only to our online activities and is valid for visitors to our website with regards to the information that they shared and/or collect in Akash Console. This policy is not applicable to any information collected offline or via channels other than this website. Our Privacy Policy was created with the help of the Free Privacy Policy Generator.ConsentBy using our website, you hereby consent to our Privacy Policy and agree to its terms.Information we collectThe personal information that you are asked to provide, and the reasons why you are asked to provide it, will be made clear to you at the point we ask you to provide your personal information.If you contact us directly, we may receive additional information about you such as your name, email address, phone number, the contents of the message and/or attachments you may send us, and any other information you may choose to provide.When you register for an Account, we may ask for your contact information, including items such as name, company name, address, email address, and telephone number.How we use your informationWe use the information we collect in various ways, including to:Provide, operate, and maintain our websiteImprove, personalize, and expand our websiteUnderstand and analyze how you use our websiteDevelop new products, services, features, and functionalityCommunicate with you, either directly or through one of our partners, including for customer service, to provide you with updates and other information relating to the website, and for marketing and promotional purposesSend you emailsFind and prevent fraudLog FilesAkash Console follows a standard procedure of using log files. These files log visitors when they visit websites. All hosting companies do this and a part of hosting services' analytics. The information collected by log files include internet protocol (IP) addresses, browser type, Internet Service Provider (ISP), date and time stamp, referring/exit pages, and possibly the number of clicks. These are not linked to any information that is personally identifiable. The purpose of the information is for analyzing trends, administering the site, tracking users' movement on the website, and gathering demographic information.Cookies and Web BeaconsLike any other website, Akash Console uses 'cookies'. These cookies are used to store information including visitors' preferences, and the pages on the website that the visitor accessed or visited. The information is used to optimize the users' experience by customizing our web page content based on visitors' browser type and/or other information.Advertising Partners Privacy PoliciesYou may consult this list to find the Privacy Policy for each of the advertising partners of Akash Console.Third-party ad servers or ad networks uses technologies like cookies, JavaScript, or Web Beacons that are used in their respective advertisements and links that appear on Akash Console, which are sent directly to users' browser. They automatically receive your IP address when this occurs. These technologies are used to measure the effectiveness of their advertising campaigns and/or to personalize the advertising content that you see on websites that you visit.Note that Akash Console has no access to or control over these cookies that are used by third-party advertisers.Third Party Privacy PoliciesAkash Console's Privacy Policy does not apply to other advertisers or websites. Thus, we are advising you to consult the respective Privacy Policies of these third-party ad servers for more detailed information. It may include their practices and instructions about how to opt-out of certain options. You can choose to disable cookies through your individual browser options. To know more detailed information about cookie management with specific web browsers, it can be found at the browsers' respective websites.CCPA Privacy Rights (Do Not Sell My Personal Information)Under the CCPA, among other rights, California consumers have the right to:Request that a business that collects a consumer's personal data disclose the categories and specific pieces of personal data that a business has collected about consumers.Request that a business delete any personal data about the consumer that a business has collected.Request that a business that sells a consumer's personal data, not sell the consumer's personal data.If you make a request, we have one month to respond to you. If you would like to exercise any of these rights, please contact us.GDPR Data Protection RightsWe would like to make sure you are fully aware of all of your data protection rights. Every user is entitled to the following:The right to access – You have the right to request copies of your personal data. We may charge you a small fee for this service.The right to rectification – You have the right to request that we correct any information you believe is inaccurate. You also have the right to request that we complete the information you believe is incomplete.The right to erasure – You have the right to request that we erase your personal data, under certain conditions.The right to restrict processing – You have the right to request that we restrict the processing of your personal data, under certain conditions.The right to object to processing – You have the right to object to our processing of your personal data, under certain conditions.The right to data portability – You have the right to request that we transfer the data that we have collected to another organization, or directly to you, under certain conditions.If you make a request, we have one month to respond to you. If you would like to exercise any of these rights, please contact us.Children's InformationAnother part of our priority is adding protection for children while using the internet. We encourage parents and guardians to observe, participate in, and/or monitor and guide their online activity.Akash Console does not knowingly collect any Personal Identifiable Information from children under the age of 13. If you think that your child provided this kind of information on our website, we strongly encourage you to contact us immediately and we will do our best efforts to promptly remove such information from our records.","tokens":1667,"squid":"spider-03","role":"Compute Spider","at":1791338630957,"hash":"f6b8e42ccbdd8a5082eca2e3b19203102b9e1f41"}
{"url":"https://consensysdiligence.github.io/smart-contract-best-practices/development-recommendations/general/public-data/","domain":"consensysdiligence.github.io","title":"Public on-chain Data - Ethereum Smart Contract Best Practices","text":"Public on-chain Data\n\nTip\nFor comprehensive insights into secure development practices, consider visiting the Development Recommendations section of the Smart Contract Security Field Guide. This resource provides in-depth articles to guide you in developing robust and secure smart contracts.\n\nMany applications require submitted data to be private up until some point in time in order to\nwork. Games (eg. on-chain rock-paper-scissors) and auction mechanisms (eg. sealed-bid\nVickrey auctions) are two major categories of\nexamples. If you are building an application where privacy is an issue, make sure you avoid\nrequiring users to publish information too early. The best strategy is to use\ncommitment schemes with separate phases: first\ncommit using the hash of the values and in a later phase revealing the values.\nHowever, care must be taken to ensure that the hashed value stored isn't recognisable (and thus, de-mappable), as this would defeat the second purpose of hashing - preventing the reveal of such values. Here's an example:\nSay a smart contract allows 2 players to play rock-paper-scissors, and uses this commit-reveal scheme - both players have to send a hash of their move before either of them sends the last (game ending) transaction. Here's what the keccak256 hash of rock is: 10977e4d68108d418408bc9310b60fc6d0a750c63ccef42cfb0ead23ab73d102. If you were playing, and you saw your opponent commiting this, wouldn't this tell you exactly what move your opponent has committed to? A safer implementation would be to hash not just the name of the move, but also, say, a user chosen salt. That would make the resulting salt non-recognisable.\nExamples:\n\nIn rock paper scissors, require both players to submit a hash of their intended move first, then\n require both players to submit their move; if the submitted move does not match the hash throw it\n out.\nIn an auction, require players to submit a hash of their bid value in an initial phase (along\n with a deposit greater than their bid value), and then submit their auction bid value in the\n second phase.\nWhen developing an application that depends on a random number generator, the order should always\n be (1) players submit moves, (2) random number generated, (3) players paid out. The method\n by which random numbers are generated is itself an area of active research; current best-in-class\n solutions include Bitcoin block headers (verified through http://btcrelay.org),\n hash-commit-reveal schemes (ie. one party generates a number, publishes its hash to \"commit\" to\n the value, and then reveals the value later) and RANDAO. As\n Ethereum is a deterministic protocol, no variable within the protocol could be used as an\n unpredictable random number. Also, be aware that miners are in some extent in control of the\n block.blockhash()\n value.","tokens":703,"squid":"spider-06","role":"Security Spider","at":1791338632455,"hash":"fb562d72cb3534aeb6f29e99e00888ed2af1c1c3"}
{"url":"https://consensysdiligence.github.io/smart-contract-best-practices/development-recommendations/precautions/upgradeability/","domain":"consensysdiligence.github.io","title":"Upgradeability - Ethereum Smart Contract Best Practices","text":"Upgradeability\n\nTip\nFor comprehensive insights into secure development practices, consider visiting the Development Recommendations section of the Smart Contract Security Field Guide. This resource provides in-depth articles to guide you in developing robust and secure smart contracts.\n\nCode will need to be changed if errors are discovered or if improvements need to be made. It is no\ngood to discover a bug, but have no way to deal with it.\nDesigning an effective upgrade system for smart contracts is an area of active research, and we\nwon't be able to cover all of the complications in this document. However, two basic approaches are\nmost commonly used. The simpler of the two is to have a registry contract that holds the address of\nthe latest version of the contract. A more seamless approach for contract users is to have a\ncontract that forwards calls and data onto the latest version of the contract.\nWhatever the technique, it's important to have modularization and good separation between\ncomponents, so that code changes do not break functionality, orphan data, or require substantial\ncosts to port. In particular, it is usually beneficial to separate complex logic from your data\nstorage, so that you do not have to recreate all of the data in order to change the functionality.\nIt's also critical to have a secure way for parties to decide to upgrade the code. Depending on\nyour contract, code changes may need to be approved by a single trusted party, a group of members,\nor a vote of the full set of stakeholders. If this process can take some time, you will want to\nconsider if there are other ways to react more quickly in case of an attack, such as an\nemergency stop or circuit-breaker.\nRegardless of your approach, it is important to have some way to upgrade your contracts, or they\nwill become unusable when the inevitable bugs are discovered in them.\nExample 1: Use a registry contract to store the latest version of a contract¶\nIn this example, the calls aren't forwarded, so users should fetch the current address each time\nbefore interacting with it.\npragma solidity ^0.5.0;\n\ncontract SomeRegister {\n address backendContract;\n address[] previousBackends;\n address owner;\n\n constructor() {\n owner = msg.sender;\n }\n\n modifier onlyOwner() {\n require(msg.sender == owner)\n _;\n }\n\n function changeBackend(address newBackend) public\n onlyOwner()\n returns (bool)\n {\n if(newBackend != address(0) && newBackend != backendContract) {\n previousBackends.push(backendContract);\n backendContract = newBackend;\n return true;\n }\n\n return false;\n }\n}\n\nThere are two main disadvantages to this approach:\n\nUsers must always look up the current address, and anyone who fails to do so risks using an old\n version of the contract\nYou will need to think carefully about how to deal with the contract data when you replace the\n contract\n\nThe alternate approach is to have a contract forward calls and data to the latest version of the\ncontract:\nExample 2: Use a DELEGATECALL to forward data and calls¶\nThis approach relies on using the\nfallback function (in\nRelay contract) to forward the calls to a target contract (LogicContract) using\ndelegatecall.\nRemember that delegatecall is a special function in Solidity that executes the logic of the\ncalled address (LogicContract) in the context of the calling contract (Relay), so \"storage,\ncurrent address and balance still refer to the calling contract , only the code is taken from the\ncalled address\".\npragma solidity ^0.5.0;\n\ncontract Relay {\n address public currentVersion;\n address public owner;\n\n modifier onlyOwner() {\n require(msg.sender == owner);\n _;\n }\n\n constructor(address initAddr) {\n require(initAddr != address(0));\n currentVersion = initAddr;\n owner = msg.sender; // this owner may be another contract with multisig, not a single contract owner\n }\n\n function changeContract(address newVersion) public\n onlyOwner()\n {\n require(newVersion != address(0));\n currentVersion = newVersion;\n }\n\n fallback() external payable {\n (bool success, ) = address(currentVersion).delegatecall(msg.data);\n require(success);\n }\n}\n\ncontract LogicContract {\n address public currentVersion;\n address public owner;\n uint public counter;\n\n function incrementCounter() {\n counter++;\n }\n}\n\nThis simple version of the pattern cannot return values from LogicContract's functions, only\nforward them, which limits its applicability. More complex implementations attempt to solve this\nwith in-line assembly code and a registry of return sizes. They are commonly referred to as\nProxy Patterns, but are also known as\nRouter,\nDispatcher and Relay. Each\nimplementation variant introduces a different set of complexity, risks and limitations.\nYou must be extremely careful with how you store data with this method. If your new contract has a\ndifferent storage layout than the first, your data may end up corrupted. When using more complex\nimplementations of delegatecall, you should carefully consider and understand*:\n\nHow the EVM handles the\n layout of state variables in storage,\n including packing multiple variables into a single storage slot if possible\nHow and why\n the order of inheritance impacts\n the storage layout\nWhy the called contract (LogicContract) must have the same storage layout of the calling\n contract (Relay), and only append new variables to the storage (see\n Background on delegatecall)\nWhy a new version of the called contract (LogicContract)\n must have the same storage layout as the previous version,\n and only append new variables to the storage\nHow a contract's constructor can affect upgradeability\nHow the ABI specifies\n function selectors\n and how\n function-name collision\n can be used to exploit a contract that uses delegatecall\nHow delegatecall to a non-existent contract will return true even if the called contract does\n not exist. For more details see\n Breaking the proxy pattern\n and Solidity docs on\n Error handling.\nRemember the\n importance of immutability to achieve trustlessness\n\n* Extended from\nProxy pattern recommendations section","tokens":1502,"squid":"spider-06","role":"Security Spider","at":1791338641726,"hash":"8868bce44a329cad269b26f20fac25321d0b7b5b"}
{"url":"https://eips.ethereum.org/EIPS/eip-2228","domain":"eips.ethereum.org","title":"EIP-2228: Canonicalize the name of network ID 1 and chain ID 1","text":"🎉 Final\n\n Informational\n\n EIP-2228: Canonicalize the name of network ID 1 and chain ID 1\n\n Authors\n William Entriken (@fulldecent)\n\n Created\n 2019-08-04\n\n Simple Summary\n\nThe Ethereum network with network ID 1 and chain ID 1 is named Ethereum Mainnet.\n\n Abstract\n\nThe name for the Ethereum network with network ID 1 and chain ID 1 shall be Ethereum Mainnet or just Mainnet. This is a proper noun.\n\nThis standard specifies the name for this network and provides reference examples in an effort to standardize the word choice and provide a common language for use to refer to this network.\n\n Motivation\n\nThe Ethereum network with network ID 1 and chain ID 1 is referenced using several conflicting names across EIPs, client implementations, and information published on the internet at large. In several locations, even documents written by the same author use inconsistent names to refer to the Ethereum network with network ID 1 and chain ID 1. Names in use at the time of this writing include:\n\n “main net”\n “mainnet”\n “Main net”\n “Mainnet”\n\n Specification\n\nThe network name for network ID 1 and chain ID 1 shall be Ethereum Mainnet, or just Mainnet if the context is known to be discussing Ethereum networks. This IS a proper noun. Several examples are given below which differentiate between usage of the name of the network versus a descriptive reference to the network.\n\nAny name or word styling (i.e. capitalization of the letters) of the network which is inconsistent with the test cases cited below shall NOT be used.\n\n Trademark note\n\n“Ethereum” is trademarked by the Ethereum Foundation. For more information on your obligations when mentioning “Ethereum”, and possibly “Ethereum Mainnet”, see:\n\n USPTO registration number 5110579 by Ethereum Foundation\n The note “you must not use [this mark] without the prior written permission of the Foundation” on the Ethereum Foundation website, Terms of Use page\n\n Rationale\n\nChoosing common word use promotes interoperability of implementations and increases customer awareness. Also, it adds a sense of professionalism when customers see the same word and word styling (i.e. capitalization of letters) across different implementations.\n\nAnybody that has travelled to certain countries and seen an “IPhone [sic]” repair store should immediately recognize that this is off-brand and unofficial. Likewise, the astute customer of Ethereum should recognize if they see the network referred to using inconsistent names in different software, so let’s avoid this.\n\n Backwards Compatibility\n\n MetaMask previously used “Main Ethereum Network” in the account network chooser. MetaMask has been updated consistent with this EIP.\n\n References to Mainnet that are inconsistent with this specification are made in: EIP-2, EIP-779, EIP-150, EIP-155, EIP-190, EIP-225, EIP-1013, EIP-2028, and EIP-2387. For consistency, we recommend the editor will update EIPs to consistently use the name as specified in this EIP.\n\n Test Cases\n\n Examples referencing the name of the network ✅\n\n The contract was deployed to Ethereum Mainnet.\n\n Ethereum runs many applications, this Dapp was deployed to Mainnet.\n\nNo specification is made on whether Dapp, dapp, dApp, etc. is preferred.\n\n SWITCH TO MAINNET\n\nThis example shows a user interface which is in uppercase. To be semantically correct, this could be written in HTML as <span style=\"text-transform: uppercase\">Switch to Mainnet</span>.\n\n switch to mainnet\n\nThis example shows a user interface which is in lowercase. To be semantically correct, this could be written in HTML as <span style=\"text-transform: lowercase\">Switch to Mainnet</span>.\n\n Examples referencing the network in a descriptive way ✅\n\n Mainnet has ### times the number of transactions as the test networks.\n\n Examples of other correct word usage ✅\n\n The main network on Ethereum is Mainnet\n\nThis shows that “main” is used as a descriptive word, but Mainnet is the specific network which is having network ID 1 and chain ID 1.\n\n Examples of poor word choice (avoid this) ❌\n\n Deploy your contract to the Ethereum main network.\n\nThis is referring to a “main” network which is context-dependent. If you were reading this text on a page about Ethereum Classic, they would be referring to network ID 2 and chain ID 62. Therefore this word usage is less crisp. Do NOT use wording like this.\n\n Connect to mainnet.\n\nThese words literally mean nothing. The lowercase, not-proper-noun word “mainnet” is not a plain English word and it should not be in any dictionary. Do NOT use wording like this.\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), \"EIP-2228: Canonicalize the name of network ID 1 and chain ID 1,\" Ethereum Improvement Proposals, no. 2228, August 2019. Available: https://eips.ethereum.org/EIPS/eip-2228.","tokens":1210,"squid":"spider-05","role":"Spec Spider","at":1791338654032,"hash":"2017665c2ef9eb31a73e77b6d0de18819c05635a"}
{"url":"https://docs.switchboard.xyz/how-it-works/switchboard-protocol","domain":"docs.switchboard.xyz","title":"Switchboard Protocol | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.The Switchboard Protocol is a decentralised oracle network that enables blockchain applications to access real-world data securely and reliably. At its core, the protocol coordinates a network of independent oracle operators who fetch, verify, and deliver data on-chain.How It WorksData Requests: Applications request data through Switchboard's on-chain contractsOracle Execution: Oracle nodes running in Trusted Execution Environments (TEEs) fetch and process the requested dataVerification: The protocol verifies oracle signatures and ensures data integrity before making it available on-chainDelivery: Verified data is delivered to your smart contracts for useKey ComponentsOracle Operators: Independent node operators who run Switchboard oracles and earn rewards for providing accurate dataStaking & Slashing: Economic security through restaking mechanisms that incentivise honest behaviour and penalise malicious actorsTEE Protection: Hardware-level security ensures oracle code cannot be tampered with or inspected, even by the operators themselvesProtocol SecurityThe protocol's security model combines cryptographic verification with economic incentives:Oracles must run verified code within TEEs, preventing manipulationOperators stake assets that can be slashed for misbehaviourMultiple oracles can be required to reach consensus on data valuesOn-chain verification ensures only properly signed data is acceptedGet InvolvedRun your own oracle and earn rewardsProvide stake to secure the networkLearn about restaking and the Switchboard NCNPreviousTask Types ReferenceNext(Re)stakingLast updated 9 months ago","tokens":427,"squid":"spider-08","role":"Oracle Spider","at":1791338658204,"hash":"a74bb5d2935ca2b4daab50abee5e58340b07f2f2"}
{"url":"https://eips.ethereum.org/EIPS/eip-7870","domain":"eips.ethereum.org","title":"EIP-7870: Hardware and Bandwidth Recommendations","text":"🎉 Living\n\n Informational\n\n EIP-7870: Hardware and Bandwidth Recommendations\n\n System recommendations for Validators and Full nodes\n\n Authors\n Parithosh Jayanthi (@parithosh), Kevaundray Wedderburn (@kevaundray), Josh Rudolf (@jrudolf), Dankrad Feist (@dankrad), Justin Traglia (@jtraglia), Ignacio Hagopian (@jsign), George Kadianakis (@asn-d6), Fredrik Svantes (@fredriksvantes), Carl Beekhuizen (@carlbeek), Toni Wahrstätter (@nerolation)\n\n Created\n 2025-01-26\n\n Discussion Link\n https://ethereum-magicians.org/t/hardware-and-bandwidth-recommendations-for-full-nodes-and-validators/22675\n\n Abstract\n\nThis proposal specifies hardware and bandwidth recommendations for different types of Ethereum nodes:\n\n Full nodes: Nodes that follow the tip of the chain without necessarily proposing blocks.\n Validators: Split into:\n\n Attesters: Validators that validate and attest to blocks created by proposers.\n Local block builders (Proposers): Validators that create blocks locally and broadcast them to the network.\n\nThe resource-intensive aspect for local block builders lies in creating the block and quickly broadcasting the data required for attesters to validate it in time.\n\nWe note that it may be possible to run a client with less than the recommended specifications, however benchmarks and decision-making will be made with respect to these recommendations.\n\n Motivation\n\nClear system specifications are crucial for:\n\n Ensuring meaningful benchmark comparisons across different client implementations.\n Enabling informed decision-making about protocol upgrades and their resource usage implications.\n Providing clear guidance for node operators to ensure alignment with future network requirements.\n\nWithout a shared understanding of target hardware specifications:\n\n Benchmark results lose significance due to inconsistent testing environments.\n Decision-making becomes challenging for implementation choices, as performance characteristics are heavily hardware-dependent.\n Network participants lack clear guidance for hardware investments.\n\n Specification\n\n Roles and Their Recommended Specifications\n\nNode operators typically run both an Execution Layer (EL) client and a Consensus Layer (CL) client on the same machine. The specifications below assume the combined resource usage of both.\n\n Node Type\n Storage\n Memory\n CPU Cores / Threads\n PassMark CPU Rating\n Bandwidth Download / Upload\n\n Full Node\n 4 TB NVMe\n 32 GB\n 4c / 8t\n ~1000 ST / 3000 MT\n 50 Mbps / 15 Mbps\n\n Attester\n 4 TB NVMe\n 64 GB\n 8c / 16t\n ~3500 ST / 25000 MT\n 50 Mbps / 25 Mbps\n\n Local Block Builder\n 4 TB NVMe\n 64 GB\n 8c / 16t\n ~3500 ST / 25000 MT\n 100 Mbps / 50 Mbps\n\nApproximate single-thread (ST) and multi-thread (MT) PassMark CPU scores. For example, a PassMark ST rating of 3500 and an MT rating of 25000 typically corresponds to upper mid-range server CPUs circa 2024–2025.\n\n Rationale\n\n Storage\n\n Recommended: 4 TB NVMe M.2 drive with:\n\n Sequential R/W: At least ~500 MB/s\n Random 4K Read IOPS: At least ~50,000\n Random 4K Write IOPS: At least ~15,000\n\n Verifying IO Performance: You can use the following commands to benchmark your local storage IO speeds:\n\n Sequential R/W:\n\n fio --name=seq --filename=test --direct=1 --ioengine=libaio --iodepth=64 --bs=1M --size=4G --rw=readwrite\n\n Random 4K R/W:\n\n fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=4G --readwrite=randrw --rwmixread=75\n\n Why NVMe over SATA?\n\n NVMe drives have significantly higher throughput and lower latency than SATA SSDs.\n Drives without DRAM (DRAMless) or with QLC flash are not advised, due to lower endurance and potentially lower sustained performance.\n\n On Endurance (TBW)\n\n Running a node involves frequent writes (e.g., database updates, logs). Ensure that the SSD’s Total Bytes Written (TBW) rating is sufficient for multi-year operation.\n\n Capacity Considerations\n\n As of January 2025, 2 TB can still work, but daily chain growth makes 4 TB more future-proof.\n While EIP-4444 aims to reduce historical storage requirements, the timeline for EIP-4444 remains uncertain.\n\n Memory\n\n Why 64 GB for Validators (Attesters / Local Block Builders)?\n\n Running an Ethereum validator (both EL & CL clients) can be memory-intensive, with state cache dominating RAM usage.\n Certain memory intensive client combinations have historically failed with 16 GB. It is possible to tune cache size in different clients to make it work, however we do not assume that the average user will do this.\n Preliminary benchmarks highlighting zk-STARK memory usage suggest cryptographic operations can demand significant RAM.\n Relative to total hardware costs, upgrading from 32 GB to 64 GB is a small price but can improve stability and is more future proof with regards to zk-STARKs.\n\n CPU\n\n Single vs. Multi-thread Performance\n\n Attesters and local block builders benefit from both high single-thread and multi-thread performance.\n\n Bandwidth\n\n Local Block Builders\n\n Recommended: 100 Mbps download, 50 Mbps upload.\n Rationale:\n\n Distributing blocks is highly bandwidth-intensive.\n If a builder cannot meet these speeds, they risk slower propagation and causing late blocks.\n In extreme cases, a low-bandwidth node could propose partially full blocks or one that includes fewer blobs to mitigate slow broadcast.\n\n Attesters\n\n Recommended: 50 Mbps download, 25 Mbps upload.\n Minimum tested: 15 Mbps (as per ethPandaOps simulations where 40% of the network had Gigabit connections and the other 60% had 15 Mbps upload).\n\n However, real-world performance depends on peer network topology. A node with poor bandwidth could in theory quickly share data with a well-connected peer with good bandwidth which means that this peer could quickly seed the network.\n\n Rationale:\n\n 25 Mbps was chosen as a buffer to account for these miscellaneous factors that are harder to predict.\n\n Validators Using MEV-Boost\n\n Recommended: 50 Mbps download / 25 Mbps upload.\n Rationale:\n\n Most MEV-relay interactions involve fetching bundles and block headers, which can be done within typical broadband speeds.\n While the local validator will also share the block with its peers, the relay will do the same which reduces the need for local bandwidth.\n However, there may be cases where your validator will still build a local block, such as if no MEV-relay responds or if the value of the MEV reward is lower than the minimum configuration set in MEV-Boost. In these circumstances, the recommendations for Local Block Builders would be relevant.\n\n Full Nodes\n\n Recommended: 50 Mbps download / 15 Mbps upload.\n Rationale:\n\n Full nodes currently participate in sampling and must track the chain tip, but are not as latency-sensitive as attesters or local block builders.\n They can operate on lower bandwidth but risk being a slot or more behind the chain if bandwidth capacity is severely limited.\n\n Quick Reference Summary\n\n Full Node\n\n Storage: 4 TB NVMe\n RAM: 32 GB\n CPU: 4 cores / 8 threads (~1000 ST / ~3000 MT PassMark)\n Bandwidth: 50 Mbps down / 15 Mbps up\n\n Attester\n\n Storage: 4 TB NVMe\n RAM: 64 GB\n CPU: 8 cores / 16 threads (~3500 ST / ~25000 MT PassMark)\n Bandwidth: 50 Mbps down / 25 Mbps up\n\n Local Block Builder\n\n Storage: 4 TB NVMe\n RAM: 64 GB\n CPU: 8 cores / 16 threads (~3500 ST / ~25000 MT PassMark)\n Bandwidth: 100 Mbps down / 50 Mbps up\n\n Backwards Compatibility\n\nThis EIP is informational and requires no protocol changes. We recommend that future EIPs include an assessment of their impact on these hardware recommendations.\n\n Security Considerations\n\nN/A\n\n Copyright\n\nCopyright and related rights waived via CC0.\n\n Citation\n Please cite this document as:\n\n Parithosh Jayanthi (@parithosh), Kevaundray Wedderburn (@kevaundray), Josh Rudolf (@jrudolf), Dankrad Feist (@dankrad), Justin Traglia (@jtraglia), Ignacio Hagopian (@jsign), George Kadianakis (@asn-d6), Fredrik Svantes (@fredriksvantes), Carl Beekhuizen (@carlbeek), Toni Wahrstätter (@nerolation), \"EIP-7870: Hardware and Bandwidth Recommendations,\" Ethereum Improvement Proposals, no. 7870, January 2025. Available: https://eips.ethereum.org/EIPS/eip-7870.","tokens":2031,"squid":"spider-05","role":"Spec Spider","at":1791338669534,"hash":"6992df7e9d4032fb3bc6ae5dac818d7f0399471c"}
{"url":"https://docs.switchboard.xyz/how-it-works/switchboard-protocol/re-staking","domain":"docs.switchboard.xyz","title":"(Re)staking | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.The Switchboard protocol is improving the security and efficiency of its data feeds through integration with Jito Node Consensus Networks (NCNs). Jito NCNs are decentralised networks that utilise staked assets to secure and validate on-chain activity within the Solana ecosystem. These NCNs leverage the economic security provided by staked assets to power their operations, creating the potential for stakers to earn rewards. Jito Restaking provides a flexible, multi-asset staking protocol on Solana where users can stake various SPL tokens, receive liquid Vault Receipt Tokens (VRTs) representing their stake, and earn rewards from multiple sources. By integrating Jito's NCNs, Switchboard is significantly strengthening the reliability and performance of its protocol, ultimately delivering enhanced benefits to its users.Specifically, Switchboard chose to secure its protocol with Jito NCNs because of what they offer. That is:Enhanced Data Security: An extra layer of decentralised security, making Switchboard's data feeds more resistant to manipulation and attacks.Improved Protocol Reliability: By leveraging a wide range of staked assets within Jito's ecosystem, the Switchboard protocol gains access to a more robust and dependable network for validating its data.User Rewards: By participating in the Jito Restaking ecosystem through Switchboard, users may have the opportunity to earn additional protocol rewards from their staked assets from multiple networks.Keen to understand restaking, Node Consensus Networks, or Vault Receipt Tokens in greater detail? Explore our dedicated sections:\nWhat is restaking.\nWhat are Node Consensus Networks (NCNs).\nWhat are Vault Receipt Tokens (VRTs).Interested in helping secure the Switchboard Protocol? Visit ‘The Node Partner Program’PreviousSwitchboard ProtocolNextWhat is (re)staking?Last updated 1 year ago","tokens":489,"squid":"spider-08","role":"Oracle Spider","at":1791338669608,"hash":"940a0853a6a410a23566cf2c00fe571995da6f2d"}
{"url":"https://docs.across.to/introduction","domain":"docs.across.to","title":"Welcome to Across | Across Docs","text":"Welcome to AcrossCrosschain interoperability with ~2 second fills across all major chains.Tempo is now live on Across. Bridge to and from Tempo (Chain ID 4217) using the Swap API.\nWhat is Across?\nAcross is a crosschain interoperability protocol that provides the fastest, cheapest, and most secure way to move assets across blockchains. With ~2 second fills on mainnet and support for 24 chains, Across powers crosschain swaps, bridges, and embedded actions through a single unified API.\nThe Swap API is the single entry point: you request a route and it returns a transaction to execute. Across automatically selects the best settlement path under the hood — you don't need to choose.\nAPI key required for production. Get your API key and Integrator ID to authenticate your requests.\nQuick Start\nGet a crosschain swap executing in three steps:\nGet a QuoteCall the Swap API with your transfer parameters to get executable calldata.get-quote.tsconst params = new URLSearchParams({\n tradeType: \"minOutput\",\n originChainId: \"42161\", // Arbitrum\n destinationChainId: \"8453\", // Base\n inputToken: \"0xaf88d065e77c8cC2239327C5EDb3A432268e5831\", // USDC on Arbitrum\n outputToken: \"0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913\", // USDC on Base\n amount: \"1000000000\", // 1000 USDC (6 decimals)\n depositor: \"0xYourWalletAddress\",\n integratorId: \"0xdead\", // Your integrator ID\n});\n\nconst response = await fetch(\n `https://app.across.to/api/swap/approval?${params}`,\n {\n headers: {\n Authorization: \"Bearer YOUR_API_KEY\",\n },\n }\n);\nconst quote = await response.json();See the GET /swap/approval API reference for every parameter and the full response shape.Approve Token SpendingIf the quote includes approval transactions, execute them first.approve.tsimport { createWalletClient, http } from \"viem\";\nimport { arbitrum } from \"viem/chains\";\nimport { privateKeyToAccount } from \"viem/accounts\";\n\nconst account = privateKeyToAccount(\"0xYOUR_PRIVATE_KEY\");\nconst walletClient = createWalletClient({\n account,\n chain: arbitrum,\n transport: http(),\n});\n\nif (quote.approvalTxns?.length) {\n for (const approvalTx of quote.approvalTxns) {\n const hash = await walletClient.sendTransaction({\n to: approvalTx.to,\n data: approvalTx.data,\n });\n console.log(\"Approval tx:\", hash);\n }\n}Execute the SwapSend the main swap transaction using the calldata from the quote.execute.tsconst hash = await walletClient.sendTransaction({\n to: quote.swapTx.to,\n data: quote.swapTx.data,\n value: quote.swapTx.value ? BigInt(quote.swapTx.value) : 0n,\n gas: quote.swapTx.gas ? BigInt(quote.swapTx.gas) : undefined,\n});\n\nconsole.log(\"Swap tx:\", hash);\n// Funds arrive on Base in ~2 seconds\nDirect Route Linking\nLink users directly to a pre-filled bridge route on the Across UI — no API calls needed. Just construct a URL with query parameters for origin chain, destination chain, and tokens.\nhttps://app.across.to/bridge-and-swap?from=8453&to=42161&inputToken=BAL&outputToken=USDC\nLearn more about Direct Route Linking to improve your UX →\nWhat's Next\nAcross for StablecoinsMove native USDC and USDT0 across chains with a single Swap API call.Swap APIDeep dive into the Swap API — parameters, response structure, and integration patterns.Working with HypercoreBridge assets to Hyperliquid's sub-second settlement layer.Why AcrossThe fastest, cheapest, and most secure way to move assets across chains.","tokens":839,"squid":"spider-09","role":"Bridge Spider","at":1791338672452,"hash":"037449a2df3964f575422c133f2c760dd117b5ae"}
{"url":"https://docs.switchboard.xyz/docs-by-chain/movement","domain":"docs.switchboard.xyz","title":"Movement | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.Examples and Source CodeSource code for the Switchboard On-Demand Movement integration can be found in the github repo along with examples.Version source of truth: SDK Version MatrixActive DeploymentsThe Switchboard On-Demand service is currently deployed on the following networks:Mainnet:0x465e420630570b780bd8bfc25bfadf444e98594357c488fe397a1142a7b11ffaTestnet (Bardock):0x465e420630570b780bd8bfc25bfadf444e98594357c488fe397a1142a7b11ffaAdapter AddressesMainnet:0xb3654a69ba2a252849a89fa70845ad8e713a28c322dc580ae457df1f747bb74aTestnet (Bardock):0xfe38ecf6fc57e742327af6e951e9fe2fcadcd6d1f1327ba2bee5a31e43d6637fTypescript-SDK InstallationTo use Switchboard On-Demand, add the following dependencies to your project:NPMnpm install @switchboard-xyz/aptos-sdk@0.1.5 @switchboard-xyz/common@5.8.5 @aptos-labs/ts-sdk@6.1.0 --saveBunbun add @switchboard-xyz/aptos-sdk@0.1.5 @switchboard-xyz/common@5.8.5 @aptos-labs/ts-sdk@6.1.0PNPMpnpm add @switchboard-xyz/aptos-sdk@0.1.5 @switchboard-xyz/common@5.8.5 @aptos-labs/ts-sdk@6.1.0Adding Switchboard to Move CodeTo integrate Switchboard with Move, add the following dependencies to Move.toml:[addresses]\non_demand = \"0x465e420630570b780bd8bfc25bfadf444e98594357c488fe397a1142a7b11ffa\"\n\n# ...\n\n[dependencies.OnDemand]\ngit = \"https://github.com/switchboard-xyz/movement.git\"\nsubdir = \"on_demand/\"\nrev = \"main\"Example Move Code for Using Switchboard ValuesIn the example.move module, use the Aggregator and CurrentResult types to access the latest feed data.module example::switchboard_example {\n use aptos_framework::aptos_coin::AptosCoin;\n use aptos_framework::object::{Self, Object};\n use on_demand::aggregator::{Self, Aggregator, CurrentResult};\n use on_demand::decimal::Decimal;\n use on_demand::update_action;\n\n public entry fun my_function(account: &signer, update_data: vector<vector<u8>>) {\n\n // Update the feed with the provided data\n update_action::run<AptosCoin>(account, update_data);\n\n /**\n * You can use the following code to remove and run switchboard updates from the update_data vector,\n * keeping only non-switchboard byte vectors:\n *\n * update_action::extract_and_run<AptosCoin>(account, &mut update_data);\n */\n\n // Get the feed object\n let aggregator: address = @0xSomeFeedAddress;\n let aggregator: Object<Aggregator> = object::address_to_object<Aggregator>(aggregator);\n\n // Get the latest update info for the feed\n let current_result: CurrentResult = aggregator::current_result(aggregator);\n\n // Access various result properties\n let result: Decimal = aggregator::result(&current_result); // Update result\n let (result_u128, result_neg) = decimal::unpack(result); // Unpack result\n let timestamp_seconds = aggregator::timestamp(&current_result); // Timestamp in seconds\n\n // Other properties you can use from the current result\n let min_timestamp: u64 = aggregator::min_timestamp(&current_result); // Oldest valid timestamp used\n let max_timestamp: u64 = aggregator::max_timestamp(&current_result); // Latest valid timestamp used\n let range: Decimal = aggregator::range(&current_result); // Range of results\n let mean: Decimal = aggregator::mean(&current_result); // Average (mean)\n let stdev: Decimal = aggregator::stdev(&current_result); // Standard deviation\n\n // Use the computed result as needed...\n }\n}Once dependencies are configured, updated aggregators can be referenced easily.This implementation allows you to read and utilize Switchboard data feeds within Move. If you have any questions or need further assistance, please contact the Switchboard team.Creating an Aggregator and Sending TransactionsBuilding a feed in Switchboard can be done using the Typescript SDK, or it can be done with the Switchboard Web App. Visit the custom feeds section for more on designing and creating feeds.Building Feeds in Typescript [optional]import {\n CrossbarClient,\n SwitchboardClient,\n Aggregator,\n ON_DEMAND_MAINNET_QUEUE,\n ON_DEMAND_TESTNET_QUEUE,\n} from \"@switchboard-xyz/aptos-sdk\";\nimport { OracleJob } from \"@switchboard-xyz/common\";\nimport { Aptos, Account, AptosConfig, Network } from \"@aptos-labs/ts-sdk\"\n\n// get the aptos client\nconst config = new AptosConfig({\n network: Network.MAINNET, // network a necessary param / if not passed in, full node url is required\n});\nconst aptos = new Aptos(config);\n\nconst account = Account.generate(); // Or plug in your account\n\n// create a SwitchboardClient using the aptos client\nconst client = new SwitchboardClient(aptos, \"movement\"); // \"bardock\" for testnet\n\n// for initial testing and development, you can use the public\n// https://crossbar.switchboard.xyz instance of crossbar\nconst crossbarClient = new CrossbarClient(\"https://crossbar.switchboard.xyz\");\n\n// ... define some jobs ...\n\nconst isMainnet = true; // set to false for testnet\nconst queue = isMainnet\n ? ON_DEMAND_MAINNET_QUEUE\n : ON_DEMAND_TESTNET_QUEUE;\n\nconst jobs: OracleJob[] = [\n OracleJob.fromObject({\n tasks: [\n {\n httpTask: {\n url: \"https://binance.com/api/v3/ticker/price?symbol=BTCUSDT\",\n }\n },\n {\n jsonParseTask: {\n path: \"$.price\"\n }\n }\n ],\n }),\n];\n\n// Store some job definition\nconst { feedHash } = await crossbarClient.store(queue, jobs);\n\n// try creating a feed\nconst feedName = \"BTC/USDT\";\n\n// Require only one oracle response needed\nconst minSampleSize = 1;\n\n// Allow update data to be up to 60 seconds old\nconst maxStalenessSeconds = 60;\n\n// If jobs diverge more than 1%, don't allow the feed to produce a valid update\nconst maxVariance = 1e9; // 1%, scaled by 1e9 for this chain parameter\n\n// Require only 1 job response (unscaled count)\nconst minResponses = 1;\n\n//==========================================================\n// Feed Initialization On-Chain\n//==========================================================\n\n// ... get the account object for your signer with relevant key / address ...\n\n// get the signer address\nconst signerAddress = account.accountAddress.toString();\n\nconst aggregatorInitTx = await Aggregator.initTx(client, signerAddress, {\n name: feedName,\n minSampleSize,\n maxStalenessSeconds,\n maxVariance,\n feedHash,\n minResponses,\n});\n\nconst res = await aptos.signAndSubmitTransaction({\n signer: account,\n transaction: aggregatorInitTx,\n});\n\nconst result = await aptos.waitForTransaction({\n transactionHash: res.hash,\n options: {\n timeoutSecs: 30,\n checkSuccess: true,\n },\n});\n\n// Log the transaction results\nconsole.log(result);\nUpdating Feeds// replace with your feed address\nconst aggregatorId = \"YOUR_FEED_ADDRESS\";\nconst aggregator = new Aggregator(client, aggregatorId);\n\n// Fetch and log the oracle responses\nconst { updates } = await aggregator.fetchUpdate();\n\n// Create a transaction to run the feed update\n// your contract address\nconst exampleAddress = \"0x1234567890abcdef1234567890abcdef12345678\";\nconst updateTx = await client.aptos.transaction.build.simple({\n sender: signerAddress,\n data: {\n function: `${exampleAddress}::switchboard_example::my_function`,\n functionArguments: [updates],\n },\n});\n\n// Sign and submit the transaction\nconst res = await aptos.signAndSubmitTransaction({\n signer: account,\n transaction: updateTx,\n});\n\n// Wait for the transaction to complete\nconst result = await aptos.waitForTransaction({\n transactionHash: res.hash,\n options: {\n timeoutSecs: 30,\n checkSuccess: true,\n },\n});\n\n// Log the transaction results\nconsole.log(result);\n(optional) Using On-Demand with V2 interfaceIf you have existing code using the Switchboard V2 interface, you can use the On-Demand adapter for full compatibility with the new On-Demand service.1. Update Move.tomlYou'll need to update your Move.toml to include the new switchboard adapter address. Pick the correct one for your target network.[addresses]\n+ switchboard = \"0xb3654a69ba2a252849a89fa70845ad8e713a28c322dc580ae457df1f747bb74a\" # mainnet\n# switchboard = \"0xfe38ecf6fc57e742327af6e951e9fe2fcadcd6d1f1327ba2bee5a31e43d6637f\" # testnet\n\n[dependencies]\n\n# nothing has to change in the switchboard v2 dependency\n[dependencies.Switchboard]\ngit = \"https://github.com/switchboard-xyz/sbv2-aptos.git\"\nsubdir = \"move/switchboard/testnet/\" # change to /mainnet/ if on mainnet - or fork and change deps for a specific commit hash\nrev = \"main\"2. CrankingOn-demand works on a pull-based mechanism, so you will have to crank feeds with your client-side code in order to get the latest data. This can be done using the Typescript SDK.const aggregator = new Aggregator(client, aggregatorId);\n\n// update the aggregator every 10 seconds\nsetInterval(async () => {\n try {\n // fetch the latest update and tx to update the aggregator\n const { updateTx } = await aggregator.fetchUpdate({\n sender: signerAddress,\n });\n\n // send the tx to update the aggregator\n const tx = await aptos.signAndSubmitTransaction({\n signer: account,\n transaction: updateTx!,\n });\n const resultTx = await waitForTx(aptos, tx.hash);\n console.log(`Aggregator ${aggregatorId} updated!`);\n } catch (e) {\n console.error(`Error updating aggregator ${aggregatorId}: ${e}`);\n }\n}, 10000);PreviousIotaNextBuild and Deploy FeedLast updated 2 months ago","tokens":2273,"squid":"spider-08","role":"Oracle Spider","at":1791338683703,"hash":"5b397ea5116b2673e30b3ddca6d91bc8ebee3478"}
{"url":"https://docs.across.to/introduction/why-across","domain":"docs.across.to","title":"Why Across | Across Docs","text":"Why AcrossThe fastest, cheapest, and most secure way to move assets across chains.Integration Simplicity\nOne API call bridges or swaps across any supported chain. GET /swap/approval returns ready-to-execute calldata — Across handles routing, settlement, and gas under the hood, so your integration stays the same for every token, amount, and route.\nSwap API GuideTrade types, parameters, response shape, and a full integration example.Swap API ReferenceThe complete GET /swap/approval parameter list and response schema.\nSpeed\nAcross delivers sub-2-second fills on mainnet — funds reach the recipient on the destination chain almost immediately, with no waiting on slow finality. The fastest way to feel it is to move something.\nBridge Now →Move funds across chains in ~2 seconds on the Across app.\nCost\nAcross is one of the cheapest ways to move assets crosschain:\n\nMarket-based pricing — every transfer is quoted competitively per route, not charged a flat bridge toll, so you get the lowest sustainable rate.\nTransparent, all-in fees — each quote returns an explicit fees breakdown, so the total cost is known before you submit. No hidden spread, no surprise surcharges.\nEfficient infrastructure — low operating overhead is passed through to the fee you see, not tacked on top.\n\nSecurity\nAcross's security model combines:\n\nOptimistic verification with UMA's Optimistic Oracle — bundles are accepted unless challenged\nEconomic bonds — proposers stake capital that can be slashed for invalid bundles\nOnly one honest actor needed — a single honest dispute is enough to reject a bad bundle\nV4 ZK proofs — Succinct/SP1 zero-knowledge proofs provide cryptographic settlement verification\n\nChain Coverage\n23+ mainnet chains and 8 testnet chains, including first-mover support for Solana, MegaETH, Plasma, Monad, and Hyperliquid. Check whether a specific chain or token is supported:\nChain CheckerCheck if Across supports your chain by ID or name.Token CheckerCheck if Across supports your token across all chains.Welcome to AcrossCrosschain interoperability with ~2 second fills across all major chains.Key FeaturesWhat makes Across the fastest, cheapest, and most secure crosschain interoperability protocol.","tokens":551,"squid":"spider-09","role":"Bridge Spider","at":1791338683753,"hash":"e87faa833dd1e2df4a359a4fd0675ca501a3cabb"}
{"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":"spider-05","role":"Spec Spider","at":1791338695257,"hash":"48f4143c3d44f7af78aed73d44b83db750c4dcd4"}
{"url":"https://docs.switchboard.xyz/how-it-works/technical-architecture","domain":"docs.switchboard.xyz","title":"Technical Architecture | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.This section delves into the architecture and technologies used within Switchboard, detailing the interactions between components and the security measures safeguarding the network's integrity.Switchboard operates as a decentralised oracle network, delivering reliable and transparent data feeds to blockchain applications. Several core components underpin Switchboard's functionality and security, these include:Trusted Execution Environments (TEEs): Providing secure enclaves for code execution and data integrity.Oracle Queues: Managing and securing data feeds through structured environments.Node Architecture: Distributing tasks across a network of specialised nodes, with Guardians ensuring security through ongoing review and validation of new Oracles and Guardians.PreviousProviding stake to SwitchboardNextTrusted Execution Environments (TEEs)Last updated 9 months ago","tokens":242,"squid":"spider-08","role":"Oracle Spider","at":1791338695487,"hash":"3593d5c57be71574442331e7bcda958fe30725d7"}
{"url":"https://docs.switchboard.xyz/quick-start","domain":"docs.switchboard.xyz","title":"Quick Start | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.Learn to use Switchboard Data Feeds:Learn how to use a Switchboard price feed in your on-chain application on Solana, EVM, or many other chains.Explore Surge, the industry's fastest oracle data stream, on Solana, EVM, or Sui.Generate verifiably fair randomness for games, lotteries, and more on Solana or EVM.Explore existing feeds or create your own:Browse through thousands of existing data feeds on our explorer site.Can't find an existing feed that does what you need? Learn how to make and use a custom data feed with infinite customization possibilities.Go Deeper:Are you a power user that needs the fastest price updates and lots of queries? Learn how to set up a Crossbar server.Dive into the protocol and technology that power Switchboard.PreviousIntroductionNextSolana / SVMLast updated 8 months ago","tokens":225,"squid":"spider-08","role":"Oracle Spider","at":1791338705043,"hash":"fed034f1cf7fcb42154d55fd94ba251a14c12647"}
{"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":"spider-05","role":"Spec Spider","at":1791338707775,"hash":"0be5858661c50c0bd9a4d83d192383c98d7d4b24"}
{"url":"https://docs.across.to/introduction/persistent-deposit-addresses","domain":"docs.across.to","title":"Persistent Deposit Addresses | Across Docs","text":"Persistent Deposit AddressesOne POST returns a permanent deposit address — send funds from any supported origin chain and they are swept to your recipient on the destination.POST /deposit-addresses returns a persistent, never-expiring deposit address that delivers a token to a recipient on the destination you specify. The same request parameters always resolve to the same address, so you can request it once and reuse it — the amount is not part of the request. Send any amount, any time, and it's swept to the destination automatically; no wallet signing or per-transfer quote is required.\nAPI key with the deposit-address permission required (Bearer auth). Get an API key + Integrator ID.\nSupported routes\nSupport is route-specific — it depends on the origin/destination pair and the tokens on each side, not on the chain alone. There is no single \"is this chain supported\" flag.\nChainsOrigin (deposit from)Ethereum, Optimism, BNB Smart Chain, Polygon, Unichain, Monad, World Chain, HyperEVM, MegaETH, Base, Plasma, Arbitrum, Avalanche, Ink, Linea, Tempo, TronDestination (deliver to)The 17 origin chains above, plus HyperCore (1337)\n\nTron is the only non-EVM chain in the set. Its addresses use the tron namespace (base58, T…) and arrive as their own entry in depositInstructions[] — iterate that array instead of assuming a single EVM address.\nzkSync and Solana are not supported on either side.\n\nDon't hardcode origins. The response's supportedInputs[] lists every origin chain the address accepts, the token to send on each, that route's min/max limits, and its indicative fees and fill time — read them from there. The list stays current as chains and tokens are added. Unsupported destinations and recipients return 400.\nIntegrate\nRequest an addressSend the destination (token + recipient) and a refundAddresses entry to refund to if a deposit can't be completed. The example below requests USDC-SPOT on HyperCore; swap in any supported destination token.curl -X POST https://across.to/api/deposit-addresses \\\n -H \"Authorization: Bearer $ACROSS_API_KEY\" \\\n -H \"Content-Type: application/json\" \\\n -d '{\n \"destination\": {\n \"token\": { \"chainId\": 1337, \"address\": \"0x2000000000000000000000000000000000000000\" },\n \"recipient\": \"0x1111111111111111111111111111111111111111\"\n },\n \"refundAddresses\": [\n { \"namespace\": \"evm\", \"address\": \"0x2222222222222222222222222222222222222222\" }\n ]\n }'Read the deposit instructionThe response returns depositInstructions[]. Each has a depositAddress (an Account — { namespace, address }) and the supportedInputs it accepts: origin chain, input token, that route's min/max limits, plus an indicative fee breakdown and fill time. expiresAt is always null.{\n \"destination\": {\n \"token\": { \"chainId\": 1337, \"address\": \"0x2000…0000\", \"symbol\": \"USDC-SPOT\", \"name\": \"USDC\", \"decimals\": 8 },\n \"recipient\": { \"namespace\": \"evm\", \"address\": \"0x1111…1111\" }\n },\n \"refundAddresses\": [\n { \"namespace\": \"evm\", \"address\": \"0x2222…2222\" }\n ],\n \"expiresAt\": null,\n \"depositInstructions\": [\n {\n \"depositAddress\": { \"namespace\": \"evm\", \"address\": \"0xAcc0…BD6E\" },\n \"supportedInputs\": [\n {\n \"originChainId\": 1,\n \"inputToken\": { \"chainId\": 1, \"address\": \"0xA0b8…eB48\", \"symbol\": \"USDC\", \"name\": \"USD Coin\", \"decimals\": 6 },\n \"limits\": { \"minInputAmount\": \"5000000\", \"maxInputAmount\": \"10000000000000\" },\n \"indicativeFees\": { \"proportionalPct\": \"100000000000000\", \"fixedFeeUsd\": 0.246894 },\n \"indicativeFillTime\": 30\n }\n // …one entry per supported origin chain\n ]\n }\n ],\n \"id\": \"75795-1781095882239-8e49a5353db9\"\n}Send fundsSend one of the tokens listed in supportedInputs[], on the origin chain that entry names, to the depositAddress. It's swept to the destination token and recipient you requested. The address is amount-agnostic and permanent — reuse it for future transfers; re-POSTing the same parameters returns the same address.Track your depositTwo calls: list the deposits made through your deposit address, then fetch full details for the latest one.List deposits for the addressCall GET /deposits with the depositAddress query param. It returns the transfers sent to that address, newest first, each enriched with the bridge deposit created for it. depositTxnRef is the hash of the transfer you sent to the deposit address. A transfer that hasn't been swept yet reports status deposit-pending; once the sweep is picked up, the item carries the bridge deposit's fill status (pending → filled).curl \"https://across.to/api/deposits?depositAddress=0xAcc0dDdb8169FD06a34AADd52a39A4166a15BD6E\" \\\n -H \"Authorization: Bearer $ACROSS_API_KEY\"[\n {\n \"status\": \"filled\",\n \"depositTxnRef\": \"0x92ffc5d69d00e14e79254f68adab030dd38119996501a88cac0da76557703d11\"\n // …other deposit fields\n }\n]Fetch the latest depositPick the latest transfer — the first item in the response — and pass its depositTxnRef to GET /deposit for the full deposit record, including fill status.curl \"https://across.to/api/deposit?depositTxnRef=0x92ffc5d69d00e14e79254f68adab030dd38119996501a88cac0da76557703d11\" \\\n -H \"Authorization: Bearer $ACROSS_API_KEY\"\nSee the full schema, fields, and error responses in the POST /deposit-addresses API reference.Technical FAQFrequently asked questions about integrating Across Protocol.Direct Route LinkingLink users directly to a pre-filled bridge route on the Across UI.","tokens":1326,"squid":"spider-09","role":"Bridge Spider","at":1791338707923,"hash":"170d340cf14d5aa4f4c4ef7563f27208cc2abf7e"}
{"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":"spider-05","role":"Spec Spider","at":1791338719184,"hash":"da58f4c1ad8f98b8008bd65b4372a64d16ac4b4f"}
{"url":"https://docs.across.to/introduction/hypercore","domain":"docs.across.to","title":"Working with Hypercore | Across Docs","text":"Working with HypercoreBridge assets to Hyperliquid's sub-second settlement layer via Across.HyperCore is Hyperliquid's high-performance trading layer with sub-second settlement. Across supports bridging assets directly to HyperCore via the Swap API, letting users go from most supported chains to Hyperliquid quickly.\nAPI key required. Get your API key and Integrator ID to authenticate your requests.\nKey Parameters\nWhen bridging to HyperCore, use these specific values:\nParameterValueNotesdestinationChainId1337HyperCore chain IDoutputTokenUSDC-SPOT addressThe USDC-SPOT token on HyperEVM\nHyperCore uses Chain ID 1337. The Swap API handles the routing from HyperEVM to HyperCore automatically — you don't need to interact with HyperCore directly.\nHow It Works\nOrigin DepositThe user deposits assets on the origin chain (e.g., USDT on Arbitrum) via the Swap API. This creates a crosschain intent with HyperEVM as the destination.HyperEVM FillA relayer fills the intent on HyperEVM, delivering the output token (USDC-SPOT) to the recipient address.HyperCore CreditThe bridged funds are automatically credited to the user's HyperCore account. If the user doesn't have a HyperCore account yet, one is initialized automatically.\nAutomatic account initialization. If the recipient address doesn't have a HyperCore account, one is created automatically during the bridging process. No manual setup required.\nExample: Bridge USDT from Arbitrum to HyperCore\nbridge-to-hypercore.tsimport { createWalletClient, createPublicClient, http, parseUnits } from \"viem\";\nimport { arbitrum } from \"viem/chains\";\nimport { privateKeyToAccount } from \"viem/accounts\";\n\nconst account = privateKeyToAccount(\"0xYOUR_PRIVATE_KEY\");\n\nconst walletClient = createWalletClient({\n account,\n chain: arbitrum,\n transport: http(),\n});\n\nconst publicClient = createPublicClient({\n chain: arbitrum,\n transport: http(),\n});\n\nasync function bridgeToHyperCore() {\n const params = new URLSearchParams({\n tradeType: \"minOutput\",\n originChainId: \"42161\", // Arbitrum\n destinationChainId: \"1337\", // HyperCore\n inputToken: \"0xFd086bC7CD5C481DCC9C85ebE478A1C0b69FCbb9\", // USDT on Arbitrum\n outputToken: \"0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913\", // USDC-SPOT on HyperEVM\n amount: parseUnits(\"500\", 6).toString(), // 500 USDT\n depositor: account.address,\n integratorId: \"0xdead\",\n });\n\n const response = await fetch(\n `https://app.across.to/api/swap/approval?${params}`,\n {\n headers: {\n Authorization: \"Bearer YOUR_API_KEY\",\n },\n }\n );\n const quote = await response.json();\n\n if (!quote.swapTx) {\n throw new Error(`Quote failed: ${JSON.stringify(quote)}`);\n }\n\n console.log(\"Cross-swap type:\", quote.crossSwapType);\n console.log(\"Expected fill time:\", quote.expectedFillTime, \"seconds\");\n\n // Execute approvals\n if (quote.approvalTxns?.length) {\n for (const approvalTx of quote.approvalTxns) {\n const hash = await walletClient.sendTransaction({\n to: approvalTx.to,\n data: approvalTx.data,\n });\n await publicClient.waitForTransactionReceipt({ hash });\n console.log(\"Approval confirmed:\", hash);\n }\n }\n\n // Execute the bridge transaction\n const hash = await walletClient.sendTransaction({\n to: quote.swapTx.to,\n data: quote.swapTx.data,\n value: quote.swapTx.value ? BigInt(quote.swapTx.value) : 0n,\n gas: quote.swapTx.gas ? BigInt(quote.swapTx.gas) : undefined,\n });\n\n console.log(\"Bridge tx:\", hash);\n // Funds will be credited to HyperCore automatically\n}\n\nbridgeToHyperCore();\nVerify the correct USDC-SPOT token address on HyperEVM before production use. Use the /swap/tokens endpoint to look up the current address for destination chain 1337.\nWithdrawing from HyperCore\nGoing the other direction — moving funds off HyperCore to another Across-supported chain — uses a different flow. HyperCore is not EVM-compatible, so users can't broadcast a transaction from there. Instead, they sign 2 EIP-712 payloads on HyperEVM (chain id 999) and Across drives the rest: the HyperCore → HyperEVM mirror move, the standard Across gasless deposit on HyperEVM (for non-passthrough routes), and the relayer fill on the destination.\nThe endpoints involved are GET /swap/gasless (quote + signing steps) and POST /gasless/submit (submit signatures, get a depositId).\nUsers withdrawing HYPE (or non-stablecoin tokens) must hold HYPE on HyperCore to cover HyperCore → HyperEVM gas. For USDC and USDT, the gas fee can be paid in the token itself or auto-deducted in HYPE — no special action needed.\nRefunds for HyperCore withdrawals land on HyperEVM (chain id 999), not HyperCore. Surface this to users explicitly — they will expect refunds to come back to HyperCore.\nLearn about HyperCore withdrawals in detail on the next page.Introduction to Swap APIThe unified entry point for all crosschain operations on Across.Hyperliquid WithdrawalsWithdraw from Hyperliquid (HyperCore) to any Across-supported chain via a gasless multi-signature flow.","tokens":1221,"squid":"spider-09","role":"Bridge Spider","at":1791338719236,"hash":"2a0d3a7ed44fda0c4daeadd4844fac361251ca4f"}
{"url":"https://docs.across.to/introduction/stablecoins","domain":"docs.across.to","title":"Across for Stablecoins | Across Docs","text":"Across for StablecoinsMove native USDC, USDT0, and USDH across chains with a single Swap API call.Across moves native stablecoins across every supported chain through one Swap API call — no wrapped tokens. You request a route; Across picks the best settlement path automatically and returns a transaction to execute.\nAPI key required for production. Get your API key and Integrator ID to authenticate your requests.\nSponsored Routes\nSelect stablecoin routes have zero bridge fees, subsidized by the protocol.\nCurrently sponsored:\n\nUSDT / USDT0 → USDC-SPOT, USDC-PERPS on HyperCore from Ethereum, Arbitrum, Monad, Polygon, Unichain\n\nSponsored routes change over time. To check if a route is currently sponsored, inspect the fees object in the /swap/approval response.\nStablecoin Contract Addresses\nAlways verify addresses via the /swap/tokens endpoint. Token addresses can change as new deployments roll out.\nChainAddressEthereum0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48Arbitrum0xaf88d065e77c8cC2239327C5EDb3A432268e5831Base0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913Optimism0x0b2C639c533813f4Aa9D7837CAf62653d097Ff85Polygon0x3c499c542cEF5E3811e1192ce70d8cC03d5c3359Use /swap/tokens?chainId=<id> for the complete list across all supported chains.ChainAddressEthereum0xdAC17F958D2ee523a2206206994597C13D831ec7Arbitrum0xFd086bC7CD5C481DCC9C85ebE478A1C0b69FCbb9Optimism0x94b008aA00579c1307B0EF2c499aD98a8ce58e58Use /swap/tokens?chainId=<id> for the complete list.\nThis is a subset of supported chains. Query /swap/tokens for the full matrix of stablecoins and chains.\nExample: Large USDC Transfer\nOne /swap/approval call quotes the route and returns the transaction(s) to execute. The integration code is the same for every stablecoin route, regardless of size.\nusdc-transfer.tsimport { createWalletClient, createPublicClient, http } from \"viem\";\nimport { mainnet } from \"viem/chains\";\nimport { privateKeyToAccount } from \"viem/accounts\";\n\nconst account = privateKeyToAccount(\"0xYOUR_PRIVATE_KEY\");\nconst walletClient = createWalletClient({ account, chain: mainnet, transport: http() });\nconst publicClient = createPublicClient({ chain: mainnet, transport: http() });\n\nconst params = new URLSearchParams({\n tradeType: \"minOutput\",\n originChainId: \"1\",\n destinationChainId: \"42161\",\n inputToken: \"0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48\", // USDC on Ethereum\n outputToken: \"0xaf88d065e77c8cC2239327C5EDb3A432268e5831\", // USDC on Arbitrum\n amount: \"1000000000\", // 1,000 USDC (6 decimals)\n depositor: account.address,\n});\n\nconst quote = await fetch(\n `https://app.across.to/api/swap/approval?${params}`,\n { headers: { Authorization: \"Bearer YOUR_API_KEY\" } },\n).then((r) => r.json());\n\n// Execute approvals (if any), then the swap\nif (quote.approvalTxns?.length) {\n for (const approvalTx of quote.approvalTxns) {\n const hash = await walletClient.sendTransaction({ to: approvalTx.to, data: approvalTx.data });\n await publicClient.waitForTransactionReceipt({ hash });\n }\n}\n\nconst hash = await walletClient.sendTransaction({\n to: quote.swapTx.to,\n data: quote.swapTx.data,\n value: quote.swapTx.value ? BigInt(quote.swapTx.value) : 0n,\n});\n\nconsole.log(\"Transfer tx:\", hash);\nSee the GET /swap/approval API reference for every parameter and the full response shape.\nThe integration code is identical for every stablecoin route — call /swap/approval, execute any approvals, then send the returned transaction. Across handles settlement behind the scenes.API Keys & Integrator IDHow to get an API key and integrator ID for production use of the Across APIs.Technical FAQFrequently asked questions about integrating Across Protocol.","tokens":906,"squid":"spider-09","role":"Bridge Spider","at":1791338741125,"hash":"18b945fef0ebd2209c6864652c524d31ec3bb97a"}
{"url":"https://forum.arbitrum.foundation/t/proposal-non-constitutional-funding-dao-legal-defence-and-advocacy-with-defi-education-fund/23062/28","domain":"forum.arbitrum.foundation","title":"Proposal [Non-Constitutional]: Funding DAO Legal Defence and Advocacy with Defi Education Fund - Archive / Archived Proposals - Arbitrum","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 8\n\n 4\n\n 3\n\n 3\n\n 2\n\n read \n\n 19\n min\n\n Apr 2024\n\n 26 / 26\n\n Mar 2025\n\n Mar 2025\n\n Load more posts above\n\n post by cp0x on Apr 5, 2024\n\n post by GFXlabs on Apr 5, 2024\n\n post by cp0x on Apr 5, 2024\n\n post by thedevanshmehta on Apr 6, 2024\n\n post by cp0x on Apr 8, 2024\n\n post by thedevanshmehta on Apr 8, 2024\n\n 4 months later\n\n post by gidagwadajed on Aug 19, 2024\n\n 23 days later\n\n post by gidagwadajed on Sep 11, 2024\n\n post by JoJo on Sep 12, 2024\n\n post by gidagwadajed on Sep 12, 2024\n\n 8 days later\n\n post by gidagwadajed on Sep 20, 2024\n\n post by cp0x on Sep 20, 2024\n\n post by gidagwadajed on Sep 20, 2024\n\n post by Vertex_Protocol on Sep 21, 2024\n\n 20 days later\n\n post by gidagwadajed on Oct 11, 2024\n\n 10 days later\n\n post by gidagwadajed on Oct 21, 2024\n\n 1 month later\n\n post by gidagwadajed on Nov 25, 2024\n\n 4 months later\n\n post by mbernstein on Mar 20, 2025\n\n mbernstein\n\n Hi all!\nOn Tuesday, May 27th at 1pm EST we will be holding our May Community Call. Link to join the call can be found below.\nCan’t wait to see you all there!\n\n post by mbernstein on Mar 24, 2025\n\n mbernstein\n\n Hi all,\nFor information on what the DeFi Education Fund was up to in February 2025, please check out the following link:\n\n post by mbernstein on Mar 31, 2025\n\n mbernstein\n\n Happy Monday everyone!\nI want to flag that on Friday (3/28/25), DEF submitted an amicus brief in support of Jim Harper’s petition for certiorari to the United States Supreme Court in Harper v. Werfel. Harper’s case relates to the IRS’s warrantless acquisition of digital asset transaction records from Coinbase through a “John Doe” summons, raising critical questions about whether individuals retain their Fourth Amendment right to privacy in financial data shared with third-party platforms.\nLearn more here: https://www.defieducationfund.org/post/def-submits-amicus-brief-to-protect-american-s-fourth-amendment-rights\n\n Related topics\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 [Non-Constitutional]: Defending Open Source: A United Stand for Developer Rights and Software Freedom\n\n Finalized AIPs\n\n 59\n\n 5.1k\n\n Jun 2024\n\n The Defiant: #1 Ranked Crypto 101 Education & Onboarding Series\n\n Archived Proposals\n\n proposal\n\n 4\n\n 975\n\n Jan 2024\n\n Frisson Delegate Communication Thread\n\n Delegate Statements\n\n delegation,delegate-statements\n\n 76\n\n 1.1k\n\n Apr 2025\n\n Ignas Delegate Communication Thread\n\n Delegate Statements\n\n 47\n\n 767\n\n Nov 2025\n\n SEED Latam Delegate Communication Thread\n\n Delegate Statements\n\n delegation,delegate-statements\n\n 48\n\n 8.1k\n\n Jan 2025","tokens":664,"squid":"spider-07","role":"Council Spider","at":1791338741682,"hash":"9ad049c01d393fbe68b8c968a90627b9a196862a"}
{"url":"https://docs.arbitrum.io/get-started","domain":"docs.arbitrum.io","title":"Get started with Arbitrum","text":"Get started with ArbitrumFind quickstarts, guides, and reference docs for building dApps, bridging tokens, running nodes, and launching chains on Arbitrum.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 quickstart 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.How is this guide?Arbitrum: introductionFrequently asked questions about Arbitrum, a finance-native blockchain platform.","tokens":704,"squid":"spider-01","role":"Chain Spider","at":1791338745085,"hash":"4b336315bdabf3caed61cde46238cfc5e23a0477"}
{"url":"https://forum.arbitrum.foundation/t/proposal-non-constitutional-funding-dao-legal-defence-and-advocacy-with-defi-education-fund/23062","domain":"forum.arbitrum.foundation","title":"Proposal [Non-Constitutional]: Funding DAO Legal Defence and Advocacy with Defi Education Fund - Archive / Archived Proposals - Arbitrum","text":"The Arbitrum Foundation notified the Security Council on the need to perform a potential Emergency action. Following a review of the details and known risks, the Security Council decided to execute the upgrade and it was completed at 11:30 EST on 2nd October 2026.\nThis report provides an overview of the risks that required the Security Council Action:\n\nAdd a permissionless guard for the One-Step Proof of BoLD on Arbitrum One\n\nTemporarily pause activation of new Stylus contracts on Arbitrum One & Nova\n\nKey point: To date, known bugs for Stylus primarily impact chain liveness (e.g., denial of service attacks) and do not put any user funds at risk.\nWhy was this action taken\nLet’s take this opportunity to explain why action was taken on two separate issues concerning BoLD and Stylus.\nInstalling the guard for One-Step Proof of BoLD. Given the rise of AI-assisted attacks, we have implemented a precautionary approach that allows anyone to pause settlement of Arbitrum One on Ethereum if there are at least two conflicting answers that pass at the same level in which only one should be valid and pass. This is to halt a class of publicly verifiable and detectable attacks that exploit a bug in the one-step proof. If halted, Arbitrum One will continue to process as normal except that messages from Arbitrum One to Ethereum, such as withdrawals, that are not yet confirmed will have to wait. This provides time for the Security Council to deploy a fix for the bug and resume the rollup.\nPreventing activation of new Stylus contracts. AI-assisted tooling has led to an increasing number of sophisticated attacks on hand-crafted WASM programs that do not use the standard Stylus compiler toolchain. These programs are specifically designed to cause unexpected behaviors such as degrading the chain’s performance for all other users. To date, no attacks have been discovered that permits theft of user funds.\nNew ArbOS releases have patched several reported bugs and known attacks over the past few months, but out of an abundance of caution, we have decided to temporarily pause new activations of Stylus contracts. This was executed as an emergency action to prevent the deployment of new hand-crafted WASM programs that are not yet patched by the current version of ArbOS on the Arbitrum network.\nThe Arbitrum Foundation has informed the Security Council that they will work with the ArbitrumDAO to discuss next steps on the timeline and manner for enabling activation of new Stylus contracts. The Arbitrum community remains confident in the value of Stylus and want to preserve these use cases while taking preventative measures against Stylus-based attack vectors as AI-assisted attack tooling continues to evolve.\nImpact on builders and users\n\nNo new activations. New Stylus contracts cannot be activated during the pause including new versions of existing applications that require activation.\n\nExisting contracts are not paused. Already-active Stylus contracts continue to execute until expiration. This pause does not deactivate them.\n\nThe ArbOS 61 upgrade renewed all active contracts on Arbitrum One, so no currently active contract expires before August 20, 2027.\n\nRenewal via keepalive stays permissionless and is unaffected by the pause.\n\nReactivating an expired contract, or one that needs to be updated after a Stylus version change, is paused.\n\nUsing/calling any activated Stylus contract stays permissionless for all users and developers.\n\nNo impact on EVM. Solidity (EVM) contract deployment and execution are unaffected by this Security Council action.\n\nSecurity Council Actions\nThere are two actions bundled into a single payload:\n\nOne-Step Proof Guard. The L1UpgradeExecutor gives a new pause contract (PauseExecutor) the ability to pause and nothing else. The new pause contract grants the guard (OspSoundnessGuard) PAUSER_ROLE to use it. Anyone can show the guard two conflicting answers to the same step of an open challenge. If the one-step proof accepts both, the guard has the pause contract put Arbitrum One’s settlement to Ethereum on hold.\n\nStylus deactivation. The Security Council called ArbOwner.setWasmActivationGas(2^64 - 1) to raise the Stylus activation gas requirement on Arbitrum One and Nova. This makes activation prohibitively expensive and effectively disables new activations. This is a configuration change and does not require an ArbOS upgrade.\n\nThe Security Council signed the following transactions to update the configuration:\n\nEthereum: Ethereum Transaction Hash: 0x30732bb7d2... | Etherscan\nArbitrum One:\nArbitrum One Transaction Hash: 0x9eb3a4be3b... | Arbitrum One\nArbitrum Nova:\nArbitrum Nova transaction 0x79e0fed470dff7a22059b108e3f8f42eddd2b580a6771594060c4e7326c5f984 | Blockscout\n\nAn external audit was conducted for the OSP Guard contracts. No audit is required for the Stylus deactivation as it is only updating a single parameter in the ArbOS configuration.\n\n Proposal [Non-Constitutional]: Funding DAO Legal Defence and Advocacy with Defi Education Fund \n\n ArchiveArchived Proposals\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Apr 2024\n\n 1 / 26\n\n Apr 2024\n\n Mar 2025\n\n post by GFXlabs on Apr 5, 2024\n\n GFXlabs\n\n Overview\nThis proposal is to provide the DeFi Education Fund (DEF) with one million ARB across two disbursements to support them in fulfilling their mission.\nIntroduction\nThe DeFi Education Fund (DEF) is the only advocacy organization that focuses specifically on fighting for policy outcomes favorable to decentralized finance developers and users on the ground in Washington, DC. The DEF uniquely provides a dedicated voice for DAOs and DeFi in legislative, regulatory, and legal advocacy efforts. You can find a summary of their past work, which has included defending DAOs in court, as well as providing comment and consultation to regulators to avoid burdensome rules and regulations in the US, below.\nRationale\nDeFi’s policy challenges are immense and interest in DeFi has only grown since the DEF got to work in 2021. Following the collapse of FTX and with the return of the bull market, there is acute interest in DeFi on Capitol Hill and state legislatures, as well as inside federal and state government agencies. Providing meaningful educational outreach about DAOs and DeFi to lawmakers while also assisting in the legal defense of decentralized organizations is a role not played by anyone else in the US.\nAt this time, DAOs and DeFi protocols face several potentially catastrophic threats: a live IRS proposal would mandate the creation of intermediaries to conduct tax reporting (i.e., ban on disintermediated systems) and a live SEC rulemaking would define anyone loosely related to a DeFi protocol—including the underlying chain’s miners/validators—to be national securities exchanges like the New York Stock Exchange. Moreover, bills written to regulate CeFi often inadvertently capture DeFi protocols and subject them to compliance obligations designed for CeFi businesses.\nIf DeFi development and DAOs are to have a future in the United States, we need to double down on our advocacy efforts to protect DeFi from these myriad policy risks while laying the foundation for longterm proactive policy solutions favorable to DeFi and DAOs. There is a reason TradFi businesses collectively spend over $1 billion per year on U.S. lobbying and policy efforts: it works, and we’re making it work for DeFi.\nOriginally funded by Uniswap governance in 2021 with a one million UNI grant, DeFi Education Fund’s work is a public good that periodically requires funding to continue. This proposal would contribute funding to the organization so that it can expand its legislative, regulatory, and legal advocacy and education efforts on behalf of DeFi and DAO developers and users.\nThe DeFi Education Fund’s work focuses on (further details below):\n\nLegal advocacy and litigation for DeFi, DAOs, and developers;\nFighting regulatory overreach from the SEC, CFTC, FinCEN, CFPB, IRS, et. al.;\nAdvocating and lobbying for DeFi in Congress and at the state level;\nEducating elected representatives and traditional media about DeFi and its benefits; and\nInforming and serving the DeFi community about policy and regulatory developments.\n\nDEF is eager to continue leading the charge in the fight on behalf of DeFi. We can only do that with the backing of the DeFi community, which is why we will be initiating governance proposals for financial support from several DAOs. With the community’s support, we will\n\nsuper charge our impact litigation efforts to reshape the legal landscape to DeFi and DAOs’ benefit;\nexpand our outreach to legislators and double down on our educational efforts;\nmore vigorously challenge the regulatory onslaught targeting DeFi; and\nenhance our ability to engage in state-level debates and jurisdictions outside of the United States.\n\nIf DeFi development and DAOs are to have a future in the United States, we need to double down on our advocacy efforts to protect DeFi from these myriad policy risks while proactively laying the foundation for longterm policy solutions favorable to DeFi and DAOs. We stand ready and able to do so with the community’s backing, and we appreciate your consideration.\nMore Information on DEF\n\nTeam: Miller Whitehouse-Levine, Amanda Tuminelli, Max Bernstein, and Lizandro Peiper\nWeekly updates on policy developments and activities\n12 Month Estimated Budget\nHistorical financial information (annual and monthly)\nX\nContact - Please reach out to discuss!\n\nEmail: miller@defieducationfund.org\nTelegram: @millwl\nTwitter: @fund_defi\n\nImplementation\nUpon passage, 500,000 ARB is to be transferred to and held in a dedicated wallet at Coinbase. The remaining 500,000 ARB will be transferred six months after passage if the following deliverables have been met:\n\nThe DEF posts monthly updates summarizing its activities to support decentralized finance on the Arbitrum forum;\nThe DEF hosts update calls / Q&As at least every other month over this time period to keep the Arbitrum community updated on the legal and regulatory climate and on an ad hoc basis if there are important developments of interest to the Arbitrum community;\nThe DEF is responsive to Arbitrum community questions and requests for information about policy developments or organizational developments; and\nThe DEF’s work continues to focus on DeFi and DAO advocacy.\n\nWe hold half of any tokens we receive for at least 12 months and publish a sales plan before selling any tokens.\nConclusion\nThe DeFi Education Fund is a nonprofit organization with a demonstrated history of being in the trenches fighting for DAOs and decentralized finance. Whether looking to provide legal assistance when DAOs and their members are targeted, providing educational resources, or fighting for policy changes, the DeFi Education Fund is the only major crypto advocate that focuses solely on decentralized web3.\nFAQs\n\nWhy are you raising money now if you have about two years of runway at your current burn?\n\nWe are seeking Arbitrum’s support now for three primary reasons.\nFirst, we need a sense of our longer term funding in order to take on the projects that our work focuses on, which can play out over several years. For example, our legal challenge of the patent covering oracle tech that is being used against DAOs will take a total of at least two years from start to finish. If we did not have a good expectation of being able to operate two years after starting that challenge, we would not have been able to take that project on. In addition, because we hold tokens long term, we are exposed to crypto market price fluctuations.\nSecond, unexpected, ad hoc projects that we are well-positioned to take on in defense of DeFi can be extremely expensive. For example, we expect the challenge to the oracle patent to cost nearly $500,000 over its entire course. A legal challenge to proposed rules that would de facto ban DeFi in the United States could cost well over $1m. We have no ability to predict with certainty when and if those expenditures will be necessary, and without a sense of our longer term funding situation, we can’t take on those types of unexpected, but critical, projects.\nThird, DeFi needs more dedicated advocates working on its behalf. With a larger budget, we can hire more people.\n\nWhy are you asking Arbitrum for money and not other DAOs?\n\nWe will definitely be passing around the hat! We seek Arbitrum’s support as a leading DAO that is building for the long term. The Uniswap DAO took a massive “leap of faith” in generously funding an organization that did not yet exist to do work that would benefit every DeFi project and DAO. We hope that our track record of work has proven valuable to DeFi projects and users such that other leading DAOs will contribute to funding our work going forward.\n\nWhen and how are you planning on selling tokens?\n\nIt is important to us that the DEF remains aligned with the DeFi community and our supporters over the long term. We will hold half of any ARB tokens we receive for at least 12 months from the date we receive them, and we will not sell any ARB tokens without pre-disclosing a sales plan in writing. For example, we received our initial grant from the Uniswap DAO in July 2021 and sold half of the tokens. In February 2024, we began selling portions of the other half of the tokens according to an 18-month written sales plan. We will sell in July 2025 the last of the UNI tokens we received in July 2021.\nACCOMPLISHMENTS\nLegal Advocacy\n\nSEC v. Kraken - In February 2024, we submitted an amicus brief explaining the various incorrect and often inconsistent legal positions the SEC employs in its attempts to justify its position that digital asset transactions are securities transactions.\nVan Loon v. Treasury - In November 2023, we filed another amicus brief related to the Tornado Cash sanctions in the U.S. Court of Appeals for the Fifth Circuit. We argued that the use of privacy-protecting technology is normal and not inherently illicit and that Office of Foreign Asset Control (OFAC) exceeded its statutory authority in issuing sanctions that included purely domestic transactions.\nHarper v. Internal Revenue Service - In October 2023, we filed an amicus brief in a case involving a challenge to a “John Doe” summons the IRS sent to Coinbase that resulted in the collection of information (including information revealing on-chain wallet addresses) about 14,355 Americans (none of whom were accused of any wrongdoing prior to the summons) over a three-year period. Our brief explained the sweeping Fourth Amendment implications of indiscriminately collecting digital asset transaction information and how doing so is more revealing than in the context of TradFi.\nSEC v. Coinbase - In August 2023, we filed an amicus brief in the U.S. District Court for the Southern District of New York in support of Coinbase. We explained how wallets and staking actually work and supported Coinbase’s arguments that it is not a broker through its wallet software, nor did it offer securities through its staking program.\nCoin Center v. Treasury - In June 2023, we filed an amicus brief in support of a challenge to OFAC’s sanctioning of Tornado Cash smart contracts. plaintiffs’ motion for summary judgment ag. In October 2022, Coin Center and several individuals sued Treasury, challenging OFAC’s designation of Tornado Cash smart contracts. The plaintiffs argued that doing so exceeded the Treasury’s authority, and violated the Administrative Procedure Act (APA) and the First Amendment. Our brief supported arguments that the sanctions were beyond the Treasury Department’s statutory authority and violated the Administrative Procedure Act, made the point that Tornado Cash is an important privacy-protection tool, and argued that the sanctions designations made no sense when considering the realities of the technology at issue.\nVan Loon v. Treasury - In April 2023, we submitted our first brief related to Treasury’s sanctioning of Tornado Cash smart contracts. In addition to Treasury’s lack of statutory basis for the actions, We argued that the downstream implications of sanctioning a software protocol will lead to not only a weakening of the digital asset industry, but will also seriously jeopardize law-abiding Americans’ financial privacy.\nCFTC v. Ooki DAO - In late 2022, the Commodity Futures Trading Commission (CFTC) served Ooki DAO, alleging it is “illegally offering leveraged and margined retail commodity transactions in digital assets” without a Futures Commission Merchant designation or a Bank Secrecy Act (BSA) program. The CFTC served “Ooki DAO” via a help chat box with a contemporaneous notice posted on a website purportedly affiliated with Ooki DAO. We filed a brief in the case explaining: “First, the Commission has named Ooki DAO as a defendant in this action, asserting that Ooki DAO is an “unincorporated association comprised of Ooki Token holders.” But nothing about the structure of a DAO inherently dictates that result. In many cases, DAOs lack any central organization or management, and many DAO token holders often lack coordination or common objectives. As a result, DAOs will often not be “associations” of any kind, and therefore will not be proper defendants in an enforcement action brought under the Commodity Exchange Act (“CEA”), which requires that a defendant be a “person” (defined to include “associations”). The Commission has not yet alleged facts sufficient to establish that Ooki DAO is an association, so its attempt to serve Ooki DAO here is premature.”\nCombatting crypto patent trolls: In September 2023, we took action to protect DeFi and crypto from invalid patent infringement claims. We filed a petition with the U.S. Patent and Trademark Office seeking to initiate an inter partes review and cancellation of all claims in a patent owned by True Return Systems LLC. TRS is a patent troll who first tried to sell the patent as an NFT, and when that didn’t work, sued both MakerDAO and Compound Protocol in federal court for alleged infringement of U.S. Patent No. 10,025,797. Our petition argued that the technology that TRS purported to patent was not in fact TRS’s invention, but was instead very similar to oracle technology that had been in development and use for years prior to the patent.\n\nRegulatory Advocacy\n\nIn January 2024, we urged the Department of the Treasury to reconsider its proposed rule to classify crypto “mixing” transactions to be a “primary money laundering concern” subject to enhanced reporting requirements. Among the issues we commented on is the proposal’s all-encompassing definition of “mixing,” which would capture almost all crypto transactions and designate them to be “high risk.”\nIn January 2024, we submitted our thoughts on a Consumer Financial Protection Bureau (CFPB) proposed rulemaking that could expand the CFPB’s supervisory authority to capture self-hosted wallets. We argued that the rulemaking should not move forward as it would further scramble the Federal government’s already-convoluted regulatory treatment of DeFi and crypto-related activities.\nIn November 2023, we filed a comment letter regarding the Treasury Department’s proposed “broker” rulemaking. The proposed rule would introduce a brand new category of broker called a “digital asset middleman,” a new term that is essentially limitless in scope and creates brokers out of thin air in DeFi and, as we argue, runs contrary to the statute and legislative history. Furthermore, we argued that the proposal violates the Fourth Amendment’s prohibition on warrantless searches and seizures of a person’s papers and effects because individuals do not voluntarily turn over their personal data to “digital asset middlemen” who themselves neither collect nor have any legitimate business reason to collect that information. For a plain language review of our issues with the rulemaking, read: “Congress Gets the Runaround From Regulators, Again.”\nIn October 2023, we responded to France’s Autorité de Marchés Financiers (AMF) concerning their DeFi regulatory discussion paper. Our comment letter addressed many topics including permissionless blockchain protocols, legal enforceability of smart contracts, off-chain elements, etc. Importantly, we addressed the legal liability of smart contract developers, arguing that smart contracts’ code is open-source for anyone to audit and make informed decisions. Furthermore, we argued that open-source code is a form of expression as it conveys ideas for societal change and demands protection. We also argued against the AMF’s proposal to create a government-run certification regime for smart contracts.\nIn September 2023, we responded to a request for comment from the Senate Finance Committee regarding the taxation of digital assets. In our submission, we recommended Congress: 1) Revise Section 6050I so that it does not “deputize recipients of digital assets to collect and report information about their payers;” 2) Do not tax staking rewards until a sale or other disposition; 3) Do not apply wash sale rules to taxpayers who utilize digital assets as a form of currency; and 4) explicitly extend the application of section 1058’s nonrecognition rule to “loans” of actively traded fungible tokens.\nIn June 2023, we submitted a response to a consultation from HM Revenue and Customs, the United Kingdom’s tax, payments, and customs authority, regarding “the taxation of DeFi involving the lending and staking of cryptoassets.” At a high-level, our submission noted that any changes to the tax regime that concern DeFi must: be flexible to account for future innovation; exhibit clarity and simplicity to promote compliance by minimizing the burden on taxpayers; and align with the underlying economic substance of a typical DeFi transaction.\nIn June 2023, we submitted a response to Banque of France’s Autorité de Contrôle Prudentiel et de Résolution (ACPR) regarding their discussion paper: “Decentralised’ or ‘Disintermediated’ Finance: What Regulatory Response?” Our primary arguments included that ACPR should not directly regulate miners and validators by establishing standards for public blockchains; a policy that would “force centralization” would eliminate the core innovations of public blockchains; and a framework for smart contract certification would require centralization and the inappropriate regulation of speech.\nIn June 2023, we filed our third comment letter on the SEC’s proposed “exchange” rulemaking. Our brief made two primary arguments: first, the proposal improperly reads and misapplies the Exchange Act and exceeds the SEC’s statutory authority and mandate under the Act; and second, the SEC has flatly failed to comply with numerous procedural and statutory rulemaking requirements.\nIn August 2022, the DEF filed a response to the U.S. Treasury Department’s request for comment on innovation in digital assets. In our response, we explained how DeFi protocols have the potential to benefit consumers, investors, and businesses in the United States and around the world by creating accessible financial infrastructure usable by any individual with an internet connection.\nIn June 2022, we responded to Abu Dhabi’s DeFi consultation, in which we expressed our view that decentralization and disintermediation serve important societal objectives and that forcing the reintroduction of intermediation via legal obligations is a misguided approach to DeFi that would undermine its core potential and innovation.\nIn June 2022, In our second letter on the SEC’s exchange rulemaking, we argued that the proposed rule represents an improperly static regulatory response to a dynamic innovation and therefore needs to be reconsidered in total.\nIn May 2022, we commented on the SEC’s “dealer” rulemaking, which could not only subject large DeFi market participants to the threat of arbitrary SEC enforcement actions but also, potentially, capture liquidity pools themselves as so-called “dealers” under the securities laws. But how would it do so? In what way? The SEC did not say when it proposed the rule nor when it later finalized the rule in early 2024, which we expect to see challenged in court. .\nIn April 2022, we submitted the first of three comment letters on the SEC’s “exchange” rulemaking, which would de facto ban DeFi protocols in the United States. We argued that the Proposal’s expanded definition of an “exchange” is so broad that it could be interpreted to cover DeFi market participants, yet the rule didn’t specify which or why—it didn’t even mention “crypto,” “DeFi,” or “digital assets” once. In January 2023 in response to these concerns, the SEC released 167 pages of additional information explaining that the proposal does apply to DeFi and crypto, which we also responded to.\nIn April 2022, we submitted a comment letter to the Organization for Economic Co-operation and Development (OECD) on its proposed framework for tax reporting in the digital asset ecosystem. Broadly, when it comes to DeFi, the proposal fits squarely in the “how do we apply existing regulations and tactics to innovative systems” camp. This concept would force the creation of intermediaries where they do not exist for tax reporting purposes, a concept that the Treasury Department is now attempting to enshrine in the United States (see November 2023 comment letter on the IRS’s proposed “broker” rulemaking).\n\nLegislative Advocacy\nThe past year has yielded some fruit in the industry’s push for crypto-specific legislation, but legislation is still a few years out, in our view. In July, The House Agriculture Committee and the House Financial Services Committee (HFSC) voted, with bipartisan support, to advance the Financial Innovation Technology for the 21st Century Act, a bill that would create a regulatory framework for crypto in the U.S. That same month, the HFSC advanced a bill to establish a federal regulatory regime for stablecoins.\nMore recently, the House Committee on Energy and Commerce passed the Deploying American Blockchains Act (by a 46-0 margin), which would direct the chief of the Department of Commerce “to promote the competitiveness of the United States related to the deployment, use, application, and competitiveness of blockchain technology or other distributed ledger technology.” While these bills are not perfect, we’re pleased that Congress has taken a serious approach to these matters.\nThere’s another factor that gives us hope for the long-term chances of good legislation passing both chambers. And that is the willingness of Congressional offices and policymakers to engage with DEF and learn about the foundational aspects of the technology. We do “DeFi Demos” on Capitol Hill and advocate for policies welcoming of DeFi and DAOs. We explain why we believe in DeFi and why government officials and elected representatives should be just as curious as we are as to how this technology can improve the lives of their constituents. Away from sensational media headlines and televised hearings, one can see that a better, more open future for DeFi is developing.\nSpecifically, we’ve provided a perspective from DeFi’s corner on the following federal legislation:\n\nH.R. 1122, CBDC Anti-Surveillance State Act\nH.R. 1177/S. 427, Financial Freedom Act of 2023\nH.R. 1414. Keep Innovation in America Act\nH.R. 1747: Blockchain Regulatory Certainty Act\nH.R. 2670, National Defense Authorization Act for Fiscal Year 2024, including provisions related to Amendment 44\nH.R. 2743/S. 293, Fair Access to Banking Act\nH.R. 2891/S. 1323, Secure and Fair Enforcement (SAFE) Banking Act of 2023\nH.R. 2969/S. 1340, Financial technology Protection Act of 2023\nH.R. 3572, Securities Clarity Act\nH.R. 4664, Making appropriations for financial services and general government for the fiscal year ending September 30, 2024, and for other purposes\nH.R. 4763, Financial Innovation and Technology for the 21st Century Act\nH.R. 4766, Clarity for Payment Stablecoins Act of 2023\nH.R. 4841, Keep Your Coins Act of 2023\nH.R. 5403, CBDC Anti-Surveillance State Act\nH.R. 5741, Uniform Treatment of Custodial Assets Act\nH.R. 6307, Creating Legal Accountability for Rogue Innovators and Technology (CLARITY) Act of 2023\nH.R. 6322, End Financing for Hamas and State Sponsors of Terrorism Act\nH.R. 6572, Deploying American Blockchains Act of 2023\nS. 661, Crypto-Asset Environmental Transparency Act of 2023\nS. 695, A bill to repeal the provisions of the Infrastructure Investment and Jobs Act that impose new information reporting requirements with respect to digital asset transfers\nS. 1357, Responsible Digital Asset Advertising Act of 2023\nS. 2226, National Defense Authorization Act for Fiscal Year 2024, including provisions related to Senate Amendment 326 and Senate Amendment 1087 to Senate Amendment 935\nS. 2281, Lummis-Gillibrand Responsible Financial Innovation Act\nS. 2355, Crypto-Asset National Security Enhancement and Enforcement Act of 2023\nS. 2597, Digital Consumer Protection Commission Act of 2023\nS. 2669, Digital Asset Anti-Money Laundering Act of 2023\nS. 3087, Proving Reserves Of Others Funds (PROOF) Act\nS. 3441, Terrorist Financing Prevention Act of 2023\n\nVoice for DeFi: Selected Op-Eds\n\nBankless: “You Can Protect DeFi”\nFortune: “You’ve got a friend in me: How amicus briefs are helping the crypto industry win over the courts”\nCoinDesk: Congress Gets the Runaround From Regulators, Again\nCoinDesk: When Did Privacy Become a Bad Word?\nBlockworks: Crypto rights are fundamental American rights\nFortune: The SEC’s campaign to define ‘exchange’ should concern every American—even those without ties to crypto\nBlockworks: Don’t Drive Crypto Into the EU’s Open Arms\nThe American Conservative: The Wrong Lesson from the Fall of FTX\nCoinDesk: Why Ex-SEC Official John Reed Stark Is Wrong About Crypto\nCoinTelegraph: CBDCs will lead to absolute government control\nFortune: A ‘kitchen sink’ approach won’t work if the 118th Congress wants to fix its DeFi problem\n\nProviding DeFi’s Perspective in the Media\n\nThe Defiant: Crypto Advocates See Coinbase’s SEC Hearing as a “Step Forward”\n\nA spokesperson from the DeFi Education Fund (DEF), a DeFi-focused research and advocacy group, told The Defiant the hearing was “a step forward.” “On wallets and staking, the court rightly noted the paucity of factual allegations in the SEC’s complaint, and we were happy to hear that our amicus brief on these issues was useful in the court’s understanding of them,” the spokesperson said.\n\nDL News: Coinbase lashes out against regulator’s bid to ‘grab jurisdiction’ over crypto — and it’s not the SEC\n\n“Regulatory agencies — the CFPB included — are trying to grab jurisdiction in a way that creates statutory contradictions,” Miller Whitehouse-Levine, CEO of the DeFi Education Fund, told DL News.\n\nCointelegraph: A taxing obligation: Is crypto reporting ‘impossible’ under US law?\n\n“At the moment, it is literally not possible to comply with the reporting requirement,” Miller Whitehouse-Levine, CEO at the DeFi Education Fund, told Cointelegraph. What’s needed instead for the 60 million Americans who own digital assets today are “fit-for-purpose tax provisions” that basically regard crypto as a different sort of case.\n\nLaw360: USPTO To Review Blockchain IP Used To ‘Troll’ Crypto Firms\n\nThe challenge has been led by the DeFi Education Fund, a crypto advocacy group that says that the technology the patent covers predates the patent itself and has called True Return Systems a “patent troll” that threatens to force anyone using oracle systems to pay. On the same day in 2022, True Return Systems brought two suits against what amount to technology programs, arguing that they were infringing on the True Return Systems patent.\n\nBankless Podcast: The US Government is Trying to Kill Crypto\n\nWe need to stop the US from killing crypto. The new IRS proposals could effectively destroy DeFi and other crypto use cases. The good news? We can change this. 5 minutes is all it takes to leave a comment and get the interpretation delayed. In this episode, we bring on Miller Whitehouse-Levine of the DeFi Education Fund and tax lawyer Jason Schwartz to discuss the proposed rules and their catastrophic implications.\n\nLaw360: Crypto Group Urges 1st Circ. To Revive IRS Doc Seizure Suit\n\nA New Hampshire federal court failed to understand the distinctive features of cryptocurrency technology when it determined that the seizure, issued by John Doe summons, did not violate James Harper’s Fourth Amendment right to privacy, DeFi Education Fund argued in an amicus brief. DeFi is a research group that advocates for the benefits of decentralized finance, including cryptocurrency.\n\nDecrypt: Taxes Targeting DeFi Would be ‘Awfully Challenging’: Coinbase VP\n\nToday, Washington, D.C. nonprofit Defi Education Fund said on Twitter that “the proposed ‘broker’ rulemaking… must be stopped” because it would raise “serious tax policy and privacy concerns.”\n\nCointelegraph: Crypto advocates file amicus brief to address users’ Fourth Amendment privacy rights\n\nCryptocurrency advocacy group the DeFi Education Fund (DEF) has urged a United States court to consider the unique aspects of blockchain technology when evaluating the privacy rights of cryptocurrency users under the Fourth Amendment of the U.S. Constitution.\n\nLaw360: DeFi Org Asks USPTO To Review Blockchain IP Held By ‘Troll’\n\nCrypto advocacy group the DeFi Education Fund has asked the U.S. Patent and Trademark Office on Monday to take a look at a patent held by a firm it said is “trolling” decentralized finance entities with lawsuits over a blockchain system the group claims is “indistinguishable” from solutions that came before it.\n\nLaw360: CFTC Enforcement Cases May Force DeFi To Comply Or Leave\n\nThe DeFi Education Fund advocacy group said in a statement to Law360 that the CFTC enforcement actions “completely reject” the New York court’s finding…“The CFTC’s enforcement actions yesterday completely reject the court’s decision in Risley v. Uniswap Labs, which found that it ‘defies logic’ to hold the developer of a DeFi protocol liable for a third party’s potential misuse of that software,” the DeFi Education Fund said.\n\nDL News: The Guidance: A peak into lobbyists’ agenda\n\nWhile the stablecoin and market structure bills are front of mind, for the DeFi Education Fund, Senator Elisabeth Warren and Senator Roger Marshall’s bill on anti-money laundering provisions for digital assets is the priority…“What they propose to essentially do is make miners and validators financial intermediaries for regulatory purposes or software developers,” Miller Whitehouse-Levine, CEO of the Fund, told DL News. “So it’s highly problematic and certainly would kill the industry in the United States.\" But Whitehouse-Levine is hopeful because “everyone’s objective is the same, it’s just a matter of accomplishing how this objective is going to work.”\n\nBloomberg: Treasury Aims to Snag Tax Cheats With Crypto Broker Proposal\n\n“Today’s proposal from the IRS is confusing, self-refuting, and misguided,” said Miller Whitehouse-Levine, chief executive officer of the DeFi Education Fund.\n\nThe Wall Street Journal: U.S. Tackles Crypto Tax Mess\n\n“It attempts to apply regulatory frameworks predicated on the existence of intermediaries where they don’t exist.”\n\nReuters: Biden administration unveils new crypto tax reporting rules\n\nMiller Whitehouse-Levine, CEO of the DeFi Education Fund, a lobbying group focused on decentralized finance, said the proposed approach would neither make filing taxes easier nor improve tax compliance.\n\nCoinDesk: U.S. Senator Lummis, Crypto Lobbyists Urge Court to Dismiss SEC’s Coinbase Lawsuit\n\nIn total, lobby organizations including the Blockchain Association, Crypto Council for Innovation, Chamber of Digital Commerce, DeFi Education Fund, Chamber of Progress, Consumer Technology Association, venture firms like Andreessen Horowitz and Paradigm and half a dozen academics filed a total of six briefs, not including the Senator’s.\n\nBlockworks: DeFi Education Fund seeks FOIA amid SEC inaction on securities dispute\n\nThe DeFi Education Fund recently utilized the Freedom of Information Act to file a request for additional information regarding the Securities and Exchange Commission’s decision not to provide clarity on the classification of syndicated loans as securities.\n\nPOLITICO: What’s that cloud look like? To Chopra, stability risk\n\n“He previously tweeted about being pro-innovation and wanting to keep development of this industry onshore,” DeFi Education Fund CEO Miller Whitehouse-Levine told MM. “Given the contents of the bill, I do think his position has apparently changed.”\n\nThe Block: Senate bill would tighten money laundering and sanctions rules for DeFi\n\nThe bill would “effectively ban DeFi development in the country,” argued Miller Whitehouse-Levine, CEO of the DeFi Education Fund, in a statement decrying the legislation. “Unfortunately, this approach is not only a disproportionate response to the illicit use of DeFi but also risks undermining US law enforcement’s existing insight and reach into peer-to-peer crypto activity,” Whitehouse-Levine said.\n\nBlockworks: SEC’s proposed exchange definition would cause ‘de facto expatriation’ of DeFi companies\n\n“The upshot of this technological reality is that holding DeFi protocols to the requirements of the regulatory regimes governing national securities exchanges and ATSs would result in their de facto expatriation from the United States. DeFi is rapidly gaining trading market share in crypto assets, especially after recent and high-profile fraud and compliance issues at leading centralized and intermediated non-U.S. crypto asset exchanges,” the DeFi Education Fund (DEF) wrote in a 47-page response letter.\n\nCoinDesk: U.S. SEC Out-of-Bounds in Dragging DeFi Into Proposed Exchange Rule, Industry Says\n\n“The proposal would operate as a blanket de facto banishment of DeFi from the United States,” the DeFi Education Fund, a lobbying group, wrote in its comment letter. “The actions and words of the commission and agency personnel have created great confusion.”\n\nThe Capitol Account: Talking `Impact’ Litigation; SEC Officials on Hotseat in House; Stepping up Merger Scrutiny; Banks Bash SEC Custody Plan\n\nAmanda Tuminelli, who is the new chief legal officer at the DeFi Education Fund, thinks there is probably a better way to get answers – in court. Her role at the decentralized finance advocacy group is to spearhead “impact litigation” designed to bring more clarity about the rules digital assets need to follow. And even though she’s only been on the job since March, Tuminelli already has a few targets in mind. (SEC Chair Gary Gensler may want to watch out.)\n\nAxios: U.S. Treasury looks at DeFi and crime\n\n“Those frameworks were developed based on how the global economy worked in the 1970s, and are predicated on the assumption that transactions must occur through custodial financial intermediaries,” DeFi Education Fund CEO Miller Whitehouse-Levine said in a statement.\n\nPOLITICO: DeFi’s turn in the barrel\n\n“DeFi protocols function in a different way than traditional finance, and trying to apply existing AML/CFT rules, isn’t going to accomplish AML/CFT objectives,” DeFi Education Fund policy director Miller Whitehouse-Levine told MM.\n\nBlockworks: Treasury Review Acknowledges Traditional Finance, Not DeFi, Preferred by Criminals\n\n“While the assessment does, at times, demonstrate a sophisticated understanding of the DeFi landscape, it evidences a tension between the idea that decentralization is irrelevant in determining compliance obligations under existing AML/CFT controls and the idea that decentralized protocols are a novel tool unanticipated by existing frameworks,” Miller Whitehouse-Levine, CEO of the DeFi Education Fund, said in an email.\n\nThe Defiant: Gensler Refuses To Call Ether A Security At Congressional Hearing\n\nMiller Whitehouse-Levine, who heads the DeFi Education Fund crypto advocacy group, said Gensler’s appearance “underscores the thesis that [he] has made the policy choice to try and ban crypto in this country.”\n\nThe Defiant: “Everybody” Should be Concerned About the SEC’s Proposed Rule Change for DeFi\n\n“Everybody and their mother,” should be concerned, Whitehouse-Levine said in an interview. Validators of blockchain transactions, members of DAOs, and open source developers, are potentially liable, he said. The DeFi Education Fund is a research firm which advocates for DeFi with policy-makers.\n\nCapitol Account: Grading Gensler: Advocates Assess SEC Chief Two Years In\n\nTop line: F- [grade]. Chair Gensler has morphed the SEC from being the gold standard of financial regulators – an agency that protects American investors and the primacy of its capital markets by adapting its statutorily-authorized regulations to innovative technologies – to being an agency that actively engages in merit-based policymaking. That approach is undermining the SEC’s pursuit of its mission and its credibility already. And in turn, it risks doing lasting damage to the agency and the markets it oversees.\n\nThe Block: Fighting a digital dollar becomes new conservative crypto cause to champion\n\n“A CBDC’s potential for misuse is quite potent. It could severely encroach on Americans’ right to financial privacy and enable an unprecedented degree of control over individuals’ private transactions,” Whitehouse-Levine said. “Protecting the right to financial privacy is a non-partisan issue.”\n\nReuters: Wall St watchdog shortens time-frame for stock trades, proposes new investment adviser rules\n\nHowever Miller Whitehouse-Levine, policy director at DeFi Education Fund, described Gensler’s position as an attempt to cut off digital assets from the traditional financial system. “This should end any doubt that ‘come in and register’ is a fig leaf for the SEC usurping Congress to block crypto in the U.S.,” he said.\n\nNew York Times Dealbook: Investors Await a Momentous Inflation Report\n\nThe left-right divisions run deep. Despite a shared sense of urgency, the gulf between party leaders on the details of any approach to crypto regulation is wide, said Miller Whitehouse-Levine, policy director of the DeFi Education Fund, a crypto lobbying group. “It’ll be a lot of work to get consensus,” he said, and he doesn’t foresee legislation passing any time soon.\n\nCapitol Account: Calling SEC Investor Rule Discriminatory, House Republicans Plot Fresh Push to Open Up PE and Hedge Funds to the Masses\n\nHere’s a response from Miller Whitehouse-Levine, the DeFi Education Fund’s policy director: “The blog post is mistitled. The potential (further) broad decline in digital asset prices, the potential composition of custodial stablecoin reserves, and the potential mass use of a digital asset for payments are not DeFi issues.”\n\nCointelegraph: Blockchain privacy groups urge new US Congress to protect privacy rights\n\nAt the time of writing, the letter had 36 signatories, including industry players such as the Blockchain Association, DeFi Education Fund, Ledger, Nillion Network, Protocol Labs and Proton.\n\nCapitol Account: Crypto Turf Fight: a Progressive Attack on CFTC’s Behnam Gets Personal – and Ugly\n\nAs the head of the DeFi Education Fund, Miller Whitehouse-Levine often notes that he spends much of his time explaining to confused lawmakers what his industry does. Toward that end, the group isn’t wasting any time getting its education efforts going with the new Congress. Today, it sent a letter to every senator and House member that included a “DeFi FAQ,” and encourages them to pass legislation that recognizes the benefits of decentralized finance. You can read the note here.\n\nTIME: A Crypto Reckoning Isn’t Coming Yet\n\nBut Miller Whitehouse-Levine, policy director of The DeFi Education Fund, told TIME in a phone interview two weeks ago that “I don’t think this hearing is indicative of momentum behind the DCCPA. If anything, I think it has added much more to think about in the next few months.”\n\nThe Block: Crypto industry protests against Treasury’s proposed tax reporting regulation\n\nThe Defi Education Fund said earlier this month in its letter that the proposal stretches the definition of a broker beyond its constitutional limits and that the Treasury is essentially creating a new kind of broker called a “digital asset middleman.” The proposed regulations’ definition of ‘digital asset middleman’ is vague to the point of being unintelligible,” Miller Whitehouse-Levine and Amanda Tuminelli — CEO and chief legal officer of advocacy group the DeFi Education Fund respectively — wrote in a letter to the IRS.\n\nFortune: The obscure DAO at the center of a case that could determine the future of crypto\n\n“These are questions of fairness and liability that are generally handled via state law,” said Miller Whitehouse-Levine, policy director at DeFi Education Fund.\n\nThe Lexcon Crypto Show: Was the CFTC right to sue Ooki Dao? Hear from Miller Whitehouse-Levine of DEF\n\nMiller Whitehouse-Levine of the DeFi Education Fund joins Andrew in the studio today to discuss the latest news and activity of the DEF.\n\nThe ReFi DeFi Podcast: The DeFi Education Fund\n\nIt’s clear that US regulators are shining a spotlight on DeFi. It’s essential that we have a group that is dedicated to educating policymakers and shaping the future of DeFi. In this episode, we had the honor to speak to Miller Whitehouse-Levine, Policy Director at the DEF.\n\nThe New York Times’ Dealbook: Warning Signs Multiply Ahead of Pivotal Fed Interest Rates Meeting\n\nThe issue has sparked a feud among crypto insiders. “Decentralization is a spectrum, and where the line is drawn between centralized and decentralized is a policy choice that Congress will eventually have to make,” said Miller Whitehouse-Levine of the DeFi Education Fund.\n\nThe Capitol Account: DeFi Advocate Talks Hacks, Fraud and How His Industry Can Revolutionize Finance\n\nThis week we chatted with Miller Whitehouse-Levine, the policy director of the DeFi Education Fund. An early crypto enthusiast, he may have one of the hardest jobs in Washington: explaining to confused lawmakers and regulators what decentralized finance is – and why they shouldn’t be afraid of it.\n\nDecrypt: CFTC Sues a DAO, Raising Legal Questions for DeFi Founders and Users\n\nIn an emailed statement to Decrypt, the DeFi Education Fund called the lawsuit against Ooki DAO an “unprecedented action [that] seeks to create novel policy in response to novel issues, all via an enforcement action.”\n\n Proposal [Non-Constitutional]: Defending Open Source: A United Stand for Developer Rights and Software Freedom\n\n 9 Apr 2024 - Open Discussion of Proposals Governance Call\n\n [DIP v1.0]Delegate Incentive Program Results (APRIL 2024)\n\n Arbitrum DAO News: Security Council Member Election, STIP Bridge and Arbitrum Fellowships, April 18th\n\n Arbitrum DAO News: 77 LTIPP Applications Ready for Snapshot Voting, April 10th\n\n 8\n\n 4\n\n 3\n\n 3\n\n 2\n\n read \n\n 19\n min\n\n post by jengajojo on Apr 5, 2024\n\n jengajojo\n\n While I generally am supportive of these kind of efforts, I’d like to highlight that politicians all around the world need education about crypto, not just in the US. As I understand this is a general DeFi Education Fund, not just a \" DeFi Education in the US \" fund, hence I would like this squad to consider expanding their scope to other major jurisdictions.\n\n post by pedrob on Apr 5, 2024\n\n pedrob\n\n gm. I’ve been following Defi Education Fund’s work for a while, and I’m a huge fan of it.\n\nCould you please open access to these documents?\nThanks!\n\n post by drllau on Apr 5, 2024\n\n drllau\n\n jengajojo\n\n i’d note from a game-theory point of view, this is an arms race with TradFi (as Le⚔DAO is guild of legal engineers we track this, esp ith BIS stablecoins and FSB. The only way to win is not to play … what this means is coming halfway and offering co-regulation (they obviously refuse to believe DeFi after FTX (d)efective altruism. This falls into categories like public-private partnerships, subordinate legislation, public scrutiny of protocols. There are some disturbing outcomes LexDAO would want to avoid\nperchy-poem941×489 78.2 KB\nThe suboptimal one is in code(rs) we t(h)rust where programmers are deemed fudiciaries and held responsible for their code (you guess where this is going with skynet). This is fundamentally unjust as you are asking one cog to understand the whole complex system.\nThe Szabo approach of just technical updates is heavily criticised by Zamfir (hum’in’loop) and this is the current position with every regulatory body out there with license to thrill (financial theatre) after Terra-bomb and FTX.\nI’m sure some advocacy won’t hurt but are funds better spend on actual compliance rather than stonewalling?\n\n post by GFXlabs on Apr 5, 2024\n\n GFXlabs\n\nApologies. Those were just anchors (table of contents) links in the original document where this was drafted. We have removed them. All the information should be in that section.\nYou can also view additional information about some of this past work here.\n\n post by millerDEF on Apr 5, 2024\n\n millerDEF\n\n Thank you GFXLabs for putting together this proposal! For some context: last year, we worked with GFX (based in Chicago) stopping a bill proposed in the Illinois state legislature that would have inadvertently killed DeFi/p2p development in the state. It was one of the many state-level proposals that are just as problematic are many federal proposals.\nWe would love to host a call next week to share our work, answer questions, etc (Tuesday at 3:30pm ET) if that would be of interested to folks?\n(also, we filed a brief this morning in US v. Roman Storm: The indictment presents a fundamental question with vast implications for software developers in every industry: “when should software developers be held criminally liable for the bad acts of third parties who misuse their software?” According to the government’s theory in the indictment software developers would be criminally liable for the conduct of third parties who use their software years after its creation.\nWe urge the court to reject such a sweeping—and revolutionary—view of the law, as the theories of liability in this case “would grant the government unlimited power to prosecute any software developer who writes code that is later used by a third party for nefarious purposes, merely because the developer becomes aware of that later use. With no limiting principle in place, nearly all developers who create open-source software would be exposed to criminal liability for activity outside of their control years or decades later.”)\n\n post by cp0x on Apr 5, 2024\n\n cp0x\n\n I understand that the US is the largest player in crypto.\nBut I consider it incorrect to concentrate all efforts and resources on only one country.\nRegarding the legal protection of the crypto space, there was recently a proposal to provide financial support for the legal costs of the trial of the Tornado programmers. But for some reason we were afraid to even discuss it and deleted the article and the vote.\nLet’s start with protecting ordinary programmers, otherwise then there will be no one to make DeFi applications\n\n post by GFXlabs on Apr 5, 2024\n\n GFXlabs\n\nDefi Education Fund filed this in court today in the United States vs Roman Storm et al case. They also were in court last year around the OFAC designation for TC.\nThe DEF is pretty actively involved in a number of cases the US government has brought against DAOs or their contributors.\n\n post by cp0x on Apr 5, 2024\n\n cp0x\n\n Thanks, this gives me hope!\n\n post by thedevanshmehta on Apr 6, 2024\n\n thedevanshmehta\n\n Rather than seeing proposals like this one and the one supporting coin center floated individually, I would much rather see an approved budget, an open call for applications and then ARB voters getting to decide who gets how much.\nOtherwise it’ll be death by a thousand cuts, with each new advocacy group coming and posting a request. This isn’t a knock on the DEF, which i think is fabulous. I don’t agree with the criticism of US centricity, unfortunately the way the world is right now, as goes the US so goes the world.\n\n post by cp0x on Apr 8, 2024\n\n cp0x\n\n Agree with open call for applications and then ARB vote\n\n post by thedevanshmehta on Apr 8, 2024\n\n thedevanshmehta\n\n I’d say open call for applications with eligiblity being filing an amicus curiae brief in the Tornado cash case\nIf number of applicants is 3 or less we can just divide equally without an ARB vote\n\n 4 months later\n\n post by gidagwadajed on Aug 19, 2024\n\n gidagwadajed\n\n Hey all! My name is Nathan Hennigh, and I am the Head of Community Engagement at the DeFi Education Fund.\nFirst off, we are incredibly grateful for the support of the Arbitrum community in funding our efforts to fight for DeFi, open source software, and developers.\nSecondly, I’m excited to share that the patent previously mentioned, covering oracle technology, has been acquired by DEF and dedicated to the public! This is a HUGE win for DeFi, one not possible without your support. Thank you!\nWith that said, I’d like to invite you all to our monthly Community Call on August 27 at 12 PM Central Time. Come join us! Bring your questions and hear more about the patent acquisition and other updates from our CEO, Miller Whitehouse-Levine.\nmeet.google.com/kjb-tgss-skw\nOur Community Calls are on the fourth Tuesday of every month. We’d love to see you there each time! You can also add all the calls to your calendar via the link below!\n\n 23 days later\n\n post by gidagwadajed on Sep 11, 2024\n\n gidagwadajed\n\n Yesterday, in the first DeFi Hearing ever, DEF CLO Amanda Tuminelli testified before congress and absolutely crushed it!\nCheck out here opening statement here: x.com\nCheck out some highlights here:\nx.com\n\n post by JoJo on Sep 12, 2024\n\n JoJo\n\n gidagwadajed\n\n i totally missed this, this is a wonderful result. Do you have something that was published in regard of this patent? Either in docs or in twitter\n\n post by gidagwadajed on Sep 12, 2024\n\n gidagwadajed\n\n Yes it truly was! Here’s the links\nTwitter: x.com\nOriginal article: https://www.defieducationfund.org/post/def-fights-back-against-patent-troll\nSome of the media coverage:\nDEF purchases patent at center of suits against MakerDAO and Compound - Blockworks\nhttps://cointelegraph.com/news/def-ends-dao-lawsuits-makerdao-compund-patent-acquisition\nPatent at Crux of MakerDAO Lawsuit Purchased, Ending Crypto Tech Dispute - Decrypt\n\n 8 days later\n\n post by gidagwadajed on Sep 20, 2024\n\n gidagwadajed\n\n Hey all! Just dropping in again to remind everyone that our community call will be next Tuesday, September 24th, 12 PM Central Time! Excited to see yall there!\nhttp://meet.google.com/kjb-tgss-skw\n\n post by cp0x on Sep 20, 2024\n\n cp0x\n\n Can this be added to the Arbitrum call schedule?\nThere’s a pretty tight schedule for Tuesday.\n\n post by gidagwadajed on Sep 20, 2024\n\n gidagwadajed\n\n Yeah of course! Can you point me to where I can do that?\n\n post by Vertex_Protocol on Sep 21, 2024\n\n Vertex_Protocol\n\n I think one of the people in here should be able to help you get it on the calendar\n\n Load more posts below","tokens":13807,"squid":"spider-07","role":"Council Spider","at":1791338752480,"hash":"873cf68202add9535c552ad90dfe3d1ffa58ac35"}
{"url":"https://docs.phantom.com/phantom-mcp-server/tools","domain":"docs.phantom.com","title":"Tool reference - Phantom developer documentation","text":"Before using any tool, call get_connection_status or get_wallet_addresses to confirm the wallet is authenticated.\nsend_solana_transaction, send_evm_transaction, and transfer_tokens use a simulation-first flow by default. Omit confirmed on the first call to preview the action, then pass confirmed: true only after the user approves the simulation.\nMonad support has been deprecated.\nSui support has been deprecated.\n​Wallet operations\n​get_connection_status\nLightweight check of the local wallet connection status. Use this before any operation to confirm authentication without fetching full wallet details.\nNo parameters.\n​get_wallet_addresses\nGets all blockchain addresses for the authenticated embedded wallet (Solana, Ethereum, Bitcoin, Sui). Sui address output has been deprecated.\nParameterTypeRequiredDescriptionderivationIndexnumberNoDerivation index for the addresses (default: 0)\nExample response:\n{\n \"walletId\": \"05307b6d-2d5a-43d6-8d11-08db650a169b\",\n \"addresses\": [\n { \"addressType\": \"Solana\", \"address\": \"H8FpYTgx4Uy9aF9Nk9fCTqKKFLYQ9KfC6UJhMkMDzCBh\" },\n { \"addressType\": \"Ethereum\", \"address\": \"0x8d8b06e017944f5951418b1182d119a376efb39d\" },\n { \"addressType\": \"BitcoinSegwit\", \"address\": \"bc1qkce5fvaxe759yu5xle5axlh8c7durjsx2wfhr9\" },\n { \"addressType\": \"Sui\", \"address\": \"0x039039cf69a336cb84e4c1dbcb3fa0c3f133d11b8146c6f7ed0d9f6817529a62\" }\n ]\n}\n\n​get_token_balances\nReturns token holdings for the authenticated wallet with live USD pricing via the Phantom portfolio API.\nParameterTypeRequiredDescriptionnetworksstring[]NoFilter by network names (e.g., [\"solana\", \"ethereum\", \"base\", \"polygon\", \"arbitrum\", \"bitcoin\", \"sui\"]). Omit to return balances across all supported networks. The monad and sui filters have been deprecated.derivationIndexnumberNoDerivation index for the account (default: 0)\n​send_solana_transaction\nSimulates, signs, and broadcasts a Solana transaction.\nParameterTypeRequiredDescriptiontransactionstringYesBase64-encoded transaction (standard base64 with A-Za-z0-9+/=)networkIdstringNoSolana network identifier (e.g., solana:mainnet). Defaults to solana:mainnet.derivationIndexnumberNoDerivation index for the account (default: 0)walletIdstringNoWallet ID to use for signing (defaults to authenticated wallet)confirmedbooleanNoOmit to simulate first. Set to true only after the user approves the preview.\nExample request:\n{\n \"transaction\": \"AQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAQABAgMEBQYH...\",\n \"networkId\": \"solana:mainnet\"\n}\n\n​send_evm_transaction\nSimulates, signs, and broadcasts an EVM transaction with automatic gas estimation.\nParameterTypeRequiredDescriptionchainIdnumber | stringYesEVM chain ID (e.g., 1, \"8453\", or \"0x2105\")tostringNoDestination address (0x-prefixed)valuestringNoValue in wei as a hex string (e.g., \"0x0\")datastringNoCalldata as a hex stringgasstringNoGas limit as a hex string. Auto-estimated with a 20% buffer if omitted.gasLimitstringNoAlias for gas — accepted directly from DeFi aggregator responses (e.g. LI.FI). If both gas and gasLimit are provided, gas takes precedence.gasPricestringNoLegacy gas price in weimaxFeePerGasstringNoEIP-1559 max fee per gasmaxPriorityFeePerGasstringNoEIP-1559 priority feenoncestringNoTransaction nonce. Auto-fetched if omitted.typestringNoTransaction type such as \"0x2\"derivationIndexnumberNoDerivation index for the account (default: 0)walletIdstringNoWallet ID to use for signing (defaults to authenticated wallet)rpcUrlstringNoCustom EVM RPC URL overrideconfirmedbooleanNoOmit to simulate first. Set to true only after the user approves the preview.\nExample request:\n{\n \"chainId\": 8453,\n \"to\": \"0x742d35Cc6634C0532925a3b844Bc454e4438f44e\",\n \"value\": \"0x2386F26FC10000\",\n \"data\": \"0x\"\n}\n\n​sign_solana_message\nSigns a UTF-8 message on Solana.\nParameterTypeRequiredDescriptionmessagestringYesThe UTF-8 message to signnetworkIdstringYesSolana network identifier (e.g., solana:mainnet)derivationIndexnumberNoDerivation index for the account (default: 0)\n​sign_evm_personal_message\nSigns a UTF-8 message using EIP-191 personal signing for EVM chains.\nParameterTypeRequiredDescriptionmessagestringYesThe UTF-8 message to signchainIdnumberYesEVM chain ID (e.g., 1 for Ethereum, 8453 for Base)derivationIndexnumberNoDerivation index for the account (default: 0)\n​sign_evm_typed_data\nSigns structured data using EIP-712 for EVM chains. Used for DeFi permits and other typed data flows.\nParameterTypeRequiredDescriptiontypedDataobjectYesEIP-712 typed data objectchainIdnumberYesEVM chain ID (e.g., 1 for Ethereum, 8453 for Base)derivationIndexnumberNoDerivation index for the account (default: 0)\n​simulate_transaction\nSimulates a transaction and returns expected asset changes, security warnings, and blocking conditions without submitting on-chain. Use this to preview what a transaction will do before signing or sending. Supports Solana, EVM (Ethereum, Base, Polygon, Arbitrum), Sui, and Bitcoin. Monad and Sui simulation support have been deprecated.\nThe userAccount wallet address is auto-derived from the authenticated session for Solana and EVM chains. Supply it explicitly for Sui and Bitcoin.\nParameterTypeRequiredDescriptionchainIdstringYesCAIP-2 chain ID (e.g., solana:mainnet, eip155:1, eip155:8453, sui:mainnet)typestringYestransaction or messageparamsobjectYesChain-specific transaction parameters (see below)urlstringNodApp origin URL where the transaction originates (e.g., https://jup.ag)contextstringNoTransaction context hint: swap, bridge, send, or gaslessSwapuserAccountstringNoWallet address to simulate for. Auto-derived for Solana and EVM chains.languagestringNoResponse language code (e.g., en, es, ja). Defaults to en.derivationIndexnumberNoDerivation index for address lookup (default: 0)walletIdstringNoWallet ID override (defaults to authenticated wallet)\nChain-specific params shapes:\n\nSolana: { transactions: [\"<base58>\"] }\nEVM: { transactions: [{ from, to, value, data, chainId, type }] }\nSui: { rawTransaction: \"<bytes>\" }\nBitcoin: { transaction: \"<raw>\", userAddresses?: [\"bc1q...\"] }\nEVM message: { message: \"0x...\" }\n\n​Response shape\nThe result is a discriminated union on type (\"transaction\" or \"message\") with a strongly typed schema. Treat any non-empty block as a blocking condition that should prevent signing or sending.\nFieldTypeDescriptiontype\"transaction\" | \"message\"Discriminator matching the request type.blockobject | nullBlocking warning that should prevent the action. Omitted or null when safe.expectedChangesarrayAsset and message changes the user can expect.warningsarrayNon-blocking advisory warnings.advancedDetailsobject | nullChain-specific details for transaction or message scanning.errorstring | nullError message for transactions, or a SimulationErrorCode enum for messages.simulationErrorobject | nullOptional transaction simulation error details.occurredSlippagenumber | nullOptional slippage value for swap-context transaction simulations.\nEach expectedChanges[] entry is one of:\n\ntype: \"AssetChange\" - name, changeText, changeSign (PLUS | MINUS | EQUAL), asset ({ type: \"fungible\" | \"collectible\" | \"native\" | \"unknown\", symbol, decimals, amount, usdValue? }), changeType (approval | revokal | transfer | mint | unknown), and optional image, context, metadata.\ntype: \"MessageOnly\" - message, fallbackMessage, changeType, and optional image, context, metadata.\n\nEach warning (block or warnings[]) has { message, severity, kind? }. severity is an integer where lower numbers are more severe:\nSeverityMeaning1Critical alert2Alert3Critical error4Error\nadvancedDetails shape depends on the chain and request type:\n\nEVM transaction: { chainId, advancedRows, gas, gasLimit, tokenChange?, contractAddresses }. Each contract address has a type of spender, contract, or unknown.\nSolana transaction: { chainId, tokenChange, advancedRows, requestId, safeguard?, totalFee, feePayers }.\nSui transaction: { chainId, tokenChange, requestId, gas: { computationCost, storageCost, storageRebate, nonRefundableStorageFee, totalGasUsed } }.\nBitcoin transaction: { inputs, outputs } with amounts in satoshis.\nEVM message: { contractAddress }.\nSolana message: { errorSignInWithSolana }.\n\nExample transaction response (EVM transfer):\n{\n \"type\": \"transaction\",\n \"expectedChanges\": [\n {\n \"type\": \"AssetChange\",\n \"name\": \"Ether\",\n \"changeText\": \"-0.001 ETH\",\n \"changeSign\": \"MINUS\",\n \"changeType\": \"transfer\",\n \"fallbackMessage\": \"Send 0.001 ETH\",\n \"asset\": {\n \"type\": \"native\",\n \"symbol\": \"ETH\",\n \"decimals\": 18,\n \"amount\": \"1000000000000000\",\n \"usdValue\": 2.19\n }\n }\n ],\n \"warnings\": [],\n \"advancedDetails\": {\n \"chainId\": \"eip155:8453\",\n \"advancedRows\": [],\n \"gas\": [21000],\n \"gasLimit\": 21000,\n \"contractAddresses\": []\n }\n}\n\nExample blocking response (malicious approval):\n{\n \"type\": \"transaction\",\n \"block\": {\n \"message\": \"This transaction grants unlimited spending approval to a flagged address.\",\n \"severity\": 1,\n \"kind\": \"malicious_approval\"\n },\n \"expectedChanges\": [],\n \"warnings\": []\n}\n\n​get_token_allowance\nReturns the ERC-20 token allowance granted by an owner address to a spender address on any supported EVM chain. Use this before a swap to check whether an approval transaction is needed. When ownerAddress is omitted, the authenticated wallet address is used automatically.\nParameterTypeRequiredDescriptionchainIdnumber | stringYesEVM chain ID (e.g., 8453 for Base, 1 for Ethereum). Accepts a number, decimal string, or hex string (e.g., \"0x2105\").tokenAddressstringYesERC-20 token contract address (0x-prefixed)spenderAddressstringYesAddress of the spender to check allowance for (e.g., a swap router)ownerAddressstringNoAddress of the token owner. Defaults to the authenticated wallet address.walletIdstringNoWallet ID (defaults to authenticated wallet). Only used when ownerAddress is omitted.derivationIndexnumberNoDerivation index for the account (default: 0). Only used when ownerAddress is omitted.rpcUrlstringNoCustom EVM RPC URL override\nExample response:\n{\n \"chainId\": 1,\n \"tokenAddress\": \"0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48\",\n \"ownerAddress\": \"0xf81ea875f910eaf8e9b27167f018d0e1b696963a\",\n \"spenderAddress\": \"0x3fC91A3afd70395Cd496C647d5a6CC9D4B2b7FAD\",\n \"allowance\": \"0\",\n \"allowanceHex\": \"0x0\"\n}\n\n​transfer_tokens\nTransfers native tokens or SPL/ERC-20 tokens across Solana and EVM chains using a simulation-first flow.\nParameterTypeRequiredDescriptionnetworkIdstringYesNetwork identifier (e.g., solana:mainnet, eip155:1)tostringYesRecipient addressamountstringYesTransfer amount as a string (e.g., \"0.5\")amountUnitstringNoui for token units, base for atomic units (default: ui)tokenMintstringNoSPL mint or ERC-20 contract address. Omit for native token transfersdecimalsnumberNoToken decimals. Required for ERC-20 transfers when amountUnit is uiderivationIndexnumberNoDerivation index for the account (default: 0)walletIdstringNoWallet ID to use (defaults to authenticated wallet)rpcUrlstringNoCustom Solana or EVM RPC URL overridecreateAssociatedTokenAccountbooleanNoSolana only. Create destination ATA if missing (default: true)confirmedbooleanNoOmit to simulate first. Set to true only after the user approves the preview.\nExample (SOL transfer):\n{\n \"networkId\": \"solana:mainnet\",\n \"to\": \"H8FpYTgx4Uy9aF9Nk9fCTqKKFLYQ9KfC6UJhMkMDzCBh\",\n \"amount\": \"0.1\"\n}\n\n​Swaps and portfolio\n​buy_token\nNo fees on swaps. Phantom does not charge transaction fees, platform fees, or commission on swaps executed through the MCP server. Your users keep what they swap.\nFetches a swap quote from the Phantom routing engine for Solana, EVM, and cross-chain swaps. Optionally signs and sends the initiation transaction when execute: true.\nCross-chain swaps work in both directions: Solana to EVM and EVM to Solana. Cross-chain swaps can also target Hypercore/Hyperliquid when supported.\nParameterTypeRequiredDescriptionamountstringYesSell amount (e.g., \"0.5\")sellChainIdstringNoCAIP-2 chain ID for the sell token (default: solana:mainnet)buyChainIdstringNoCAIP-2 chain ID for the buy token (defaults to sellChainId; set a different value for cross-chain swaps)buyTokenMintstringNoToken to buy. Solana mint address or EVM 0x contract address (omit for native token)buyTokenIsNativebooleanNotrue to buy the native token of the destination chainsellTokenMintstringNoToken to sell. Solana mint address or EVM 0x contract address (omit for native token)sellTokenIsNativebooleanNotrue to sell the native token (default when sellTokenMint is omitted)amountUnitstringNoui for token units, base for atomic units (default: base)sellTokenDecimalsnumberNoDecimals for the sell token. Required for EVM tokens when amountUnit is uibuyTokenDecimalsnumberNoDecimals for the buy token. Required for EVM tokens when amountUnit is ui and exactOut is trueslippageTolerancenumberNoSlippage tolerance in percent (0–100)autoSlippagebooleanNoEnable automatic slippage calculationexactOutbooleanNoIf true, treat amount as the buy amount rather than the sell amountexecutebooleanNoIf true, sign and send the initiation transaction immediatelytakerstringNoOverride the taker addressderivationIndexnumberNoDerivation index for the taker address (default: 0)rpcUrlstringNoSolana RPC URL override for token decimal lookupquoteApiUrlstringNoPhantom-compatible quotes API URL override\nExample (Solana swap: sell SOL for USDC):\n{\n \"amount\": \"0.1\",\n \"sellChainId\": \"solana:mainnet\",\n \"sellTokenIsNative\": true,\n \"buyTokenMint\": \"EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v\",\n \"amountUnit\": \"ui\",\n \"execute\": true\n}\n\nExample (cross-chain swap: sell SOL for ETH on Base):\n{\n \"amount\": \"0.5\",\n \"sellChainId\": \"solana:mainnet\",\n \"sellTokenIsNative\": true,\n \"buyChainId\": \"eip155:8453\",\n \"buyTokenIsNative\": true,\n \"amountUnit\": \"ui\",\n \"execute\": true\n}\n\n​portfolio_rebalance\nAnalyzes portfolio allocation and rebalances via token swaps.\nNo fees on any swaps executed during rebalancing. Portfolio rebalancing uses the same zero-fee swap routing as buy_token.\nAnalyzes portfolio allocation and rebalances to target percentages via token swaps. Currently supports Solana only. Uses a two-phase flow: call with phase: \"analyze\" to inspect current allocations, then phase: \"execute\" with targetAllocations to rebalance. Use dryRun: true to preview without executing.\nParameterTypeRequiredDescriptionphasestringYesanalyze to view current allocations, execute to rebalancetargetAllocationsarrayNoRequired for execute phase. Array of {caip19, targetPercent, symbol?} objects. Percentages must sum to 100.dryRunbooleanNoIf true during execute phase, returns the swap plan without executing (default: false)slippageTolerancenumberNoSlippage tolerance in percent for each swap (default: 1)minTradeUsdnumberNoMinimum USD value for a trade to execute (default: 1.0)networkstringNoNetwork to rebalance on. Currently only solana is supported (default: solana).\n​Session and billing\n​phantom_login\nRe-authenticates with Phantom. Use this to log in for the first time, switch accounts, or refresh an expired session. Opens the Phantom Connect browser flow.\nNo parameters.\n​pay_api_access\nPays for daily API access when another tool returns API_PAYMENT_REQUIRED. Pass the preparedTx value from that error response, then retry the original tool call.\nParameterTypeRequiredDescriptionpreparedTxstringYesBase64-encoded unsigned Solana transaction returned by the API payment errorderivationIndexnumberNoDerivation index for the account (default: 0)\n​Perpetuals\nLooking for a Hyperliquid-focused walkthrough instead of the full tool catalog? See the dedicated perps tools guide.\n​Read-only\nToolDescriptionget_perp_marketsReturns available perp markets with price, funding, open interest, 24h volume, and max leverageget_perp_accountReturns perp account balance and available trading marginget_perp_positionsReturns open positions with size, direction, leverage, unrealized PnL, and liquidation priceget_perp_ordersReturns open perp orders such as limit, TP, and SL ordersget_perp_trade_historyReturns historical fills with fees and closed PnL\n​deposit_to_hyperliquid\nBridges tokens from an external chain (Solana, Arbitrum, Base, Ethereum, Polygon) into Hyperliquid as USDC via cross-chain swap. Uses a quote-first flow by default.\nParameterTypeRequiredDescriptionsourceChainIdstringYesSource chain CAIP-2 ID (e.g. \"solana:mainnet\", \"eip155:42161\", \"eip155:8453\", \"eip155:1\", \"eip155:137\")amountstringYesAmount to send in human-readable units (e.g. \"100\" for 100 USDC, \"0.5\" for 0.5 SOL)sellTokenMintstringNoToken contract/mint address to sell. Omit for native token (SOL, ETH, etc.)executebooleanNoIf false (default), returns the quote only. If true, signs and broadcasts immediately.walletIdstringNoWallet ID (defaults to authenticated wallet)derivationIndexnumberNoDerivation index for the account (default: 0)\nExample (deposit SOL into Hyperliquid as USDC):\n{\n \"sourceChainId\": \"solana:mainnet\",\n \"amount\": \"10\",\n \"execute\": true\n}\n\n​open_perp_position\nOpens a market or limit long/short perpetual position.\nParameterTypeRequiredDescriptionmarketstringYesMarket symbol (e.g. \"BTC\", \"ETH\", \"SOL\")directionstringYes\"long\" or \"short\"sizeUsdstringYesPosition size in USD (e.g. \"100\" for $100 notional value)leveragenumberYesLeverage multiplier (e.g. 1 for 1x, 10 for 10x)orderTypestringNo\"market\" (default) or \"limit\"limitPricestringNoRequired for limit orders: the limit price as a string (e.g. \"50000\")marginTypestringNo\"cross\" or \"isolated\"walletIdstringNoWallet ID (defaults to authenticated wallet)derivationIndexnumberNoDerivation index for the account (default: 0)\nExample (market long):\n{\n \"market\": \"ETH\",\n \"direction\": \"long\",\n \"sizeUsd\": \"100\",\n \"leverage\": 5\n}\n\n​close_perp_position\nCloses a perpetual position fully or partially.\nParameterTypeRequiredDescriptionmarketstringYesMarket symbol of the position to close (e.g. \"BTC\")sizePercentnumberNoPercentage of position to close (0–100, default: 100 for full close)walletIdstringNoWallet ID (defaults to authenticated wallet)derivationIndexnumberNoDerivation index for the account (default: 0)\n​cancel_perp_order\nCancels an open perpetual order by ID.\nParameterTypeRequiredDescriptionmarketstringYesMarket symbol (e.g. \"BTC\")orderIdintegerYesThe numeric order ID to cancel (from get_perp_orders)walletIdstringNoWallet ID (defaults to authenticated wallet)derivationIndexnumberNoDerivation index for the account (default: 0)\n​update_perp_leverage\nUpdates leverage and margin mode for a market.\nParameterTypeRequiredDescriptionmarketstringYesMarket symbol (e.g. \"BTC\")leveragenumberYesLeverage multiplier (e.g. 1 for 1x, 10 for 10x)marginTypestringNo\"cross\" or \"isolated\"walletIdstringNoWallet ID (defaults to authenticated wallet)derivationIndexnumberNoDerivation index for the account (default: 0)\n​transfer_spot_to_perps\nMoves USDC from Hypercore spot into the perps margin account.\nParameterTypeRequiredDescriptionamountUsdcstringYesAmount of USDC to move from spot to perps (e.g. \"100\" for 100 USDC)walletIdstringNoWallet ID (defaults to authenticated wallet)derivationIndexnumberNoDerivation index for the account (default: 0)\n​withdraw_from_perps\nBridges USDC from the Hyperliquid perpetuals account to an external chain (Solana, Base, Ethereum, Arbitrum, Polygon) via the Relay bridge.\nParameterTypeRequiredDescriptionamountUsdcstringYesAmount of USDC to withdraw (e.g. \"50\" for 50 USDC)destinationChainIdstringYesDestination chain CAIP-2 ID (e.g. \"solana:mainnet\", \"eip155:8453\", \"eip155:1\", \"eip155:42161\", \"eip155:137\")buyTokenstringNoCAIP-19 token to receive on the destination chain. Defaults to USDC on the destination chain if omitted.walletIdstringNoWallet ID (defaults to authenticated wallet)derivationIndexnumberNoDerivation index for the account (default: 0)\nExample:\n{\n \"amountUsdc\": \"50\",\n \"destinationChainId\": \"solana:mainnet\"\n}\n\nAll perp write tools submit signed actions immediately (except deposit_to_hyperliquid which uses a quote-first flow). Use get_perp_markets, get_perp_account, and get_perp_positions first to verify the intended trade.\n​Funding flow\nMoving funds in and out of perps is a two-step process:\nDeposit chain (external → perps):\n\ndeposit_to_hyperliquid — bridges tokens from Solana, Arbitrum, Base, Ethereum, or Polygon into Hyperliquid spot as USDC.\ntransfer_spot_to_perps — moves USDC from Hyperliquid spot into the perps margin account.\n\nWithdraw chain (perps → external):\n\nwithdraw_from_perps — bridges USDC from perps directly to the destination chain in one step.\n\nTo withdraw USDC from Hyperliquid spot (not perps), use phantom perps withdraw-hl-spot in the CLI. This command replaces the withdraw_from_hyperliquid_spot MCP tool from earlier releases, which has been removed.\n​Supported networks\nNetwork identifiers follow the CAIP-2/CAIP-10 format.\n​Solana\nNetworkIdentifierMainnetsolana:mainnetDevnetsolana:devnetTestnetsolana:testnet\n​Ethereum and EVM networks\nNetworkIdentifierEthereum Mainneteip155:1Ethereum Sepoliaeip155:11155111Polygon Mainneteip155:137Polygon Amoyeip155:80002Base Mainneteip155:8453Base Sepoliaeip155:84532Arbitrum Oneeip155:42161Arbitrum Sepoliaeip155:421614Monad (deprecated)eip155:143Monad Testnet (deprecated)eip155:10143\n​Bitcoin\nNetworkIdentifierMainnetbip122:000000000019d6689c085ae165831e93\n​Sui (deprecated)\nNetworkIdentifierMainnetsui:mainnetTestnetsui:testnetWas this page helpful?","tokens":5321,"squid":"spider-10","role":"Tooling Spider","at":1791338758529,"hash":"e59869a6f427512bd4fd1dc65aa20298babacef3"}
{"url":"https://docs.arbitrum.io/notices/fusaka-upgrade-notice","domain":"docs.arbitrum.io","title":"Fusaka Compatibility Notice","text":"Fusaka Compatibility NoticeUpgrade notices for the transition to FusakaRequest an update🛑 IMPORTANT 🛑Arbitrum chain operators must ensure that their nodes are properly configured before or shortly after the parent chain upgrades to Fusaka or the child chain upgrades to ArbOS 51.\nThis document explains what you need to do if you operate a chain that settles on a Fusaka-enabled parent chain. This includes actions for Arbitrum chains as well as actions for Arbitrum One and Arbitrum Nova node operators.\nWhat's included in Fusaka\nThe Fusaka upgrade introduces several breaking changes. Review EIP-7607 for detailed information about the EIPs included in the Fusaka hard fork.\nImportant dates\nThe following dates are relevant for Arbitrum chain operators.\nDateNetwork upgradeAffected audienceNov 20th 2025, 17:00:00 UTCArbitrum Sepolia upgrade to ArbOS 50Node operators for Arbitrum SepoliaDec 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/NovaOct 14th 2025, 07:36:00 UTCEthereum Sepolia Fusaka hard forkNode operators for Arbitrum chains settling on Ethereum Sepolia (Arbitrum L2s, Arbitrum Sepolia)Dec 3rd 2025, 21:49:11 UTCEthereum Mainnet Fusaka hard forkNode operators for Arbitrum chains settling on Ethereum Mainnet (Arbitrum L2s, Arbitrum One/Nova)\nFor node operators\nOutlined below are different types of Arbitrum chains, along with node software required for operators of chains in those configurations.\nLayerData AvailabilityFallback to blobs enabled?Required Nitro node versionConfigurations for the Ethereum Consensus Layer clientL2RollupN/AUpdate to 3.9.6 (ArbOS 51); 3.8.0 or 3.7.6 (ArbOS 40 or older)Requires all historical blob dataL2AnyTrust / AltDAEnabledUpdate to 3.9.6 (ArbOS 51); 3.8.0 or 3.7.6 (ArbOS 40 or older)Requires all historical blob dataL2AnyTrust / AltDADisabledNo nitro update requiredDoesn't require historical blob dataL3RollupN/ANo nitro update requiredDoesn't require historical blob dataL3AnyTrust / AltDAEnabled or DisabledNo nitro update requiredDoesn't require historical blob data\nExceptionsFor batch posters settling to mainnet Ethereum, Nitro >=3.8.0 is required.\nHow to ensure your node has access to all historical blob data and blob data from all subnets\nIf you run a Nitro node and use an external L1 Ethereum beacon chain RPC:\nConfirm that your external L1 beacon chain RPC provider has configured their L1 beacon chain node to subscribe to all subnets before the Ethereum Fusaka hard fork and have all historical blob data to ensure your Nitro node can sync from periods beyond the blob retention period (or that your RPC provider has backfilled the blob data properly).\nIf you run a Nitro node and operate your own L1 Ethereum beacon chain node:\nEnsure that your consensus layer client & Nitro node is configured as per the table below.\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.\nTo read more about Fusaka PeerDAS changes and why Layer 2 network operators must connect to an Ethereum beacon chain node with historical blob data, see the historical blobs docs.How is this guide?Upgrade notice for ArbOS 51Upgrade notices for ArbOS 51 activation on Arbitrum One, Arbitrum Nova, and Arbitrum Spolia","tokens":975,"squid":"spider-01","role":"Chain Spider","at":1791338767735,"hash":"e3f30081c98e40a029cd87a4f6591db5a7598d8f"}
{"url":"https://docs.phantom.com/phantom-mcp-server/perps","domain":"docs.phantom.com","title":"Perps tools - Phantom developer documentation","text":"The Phantom MCP server includes a dedicated set of tools for perpetuals trading on Hyperliquid through Phantom’s backend. This page focuses only on those perps tools: what they do, how funding flows work, and the order agents should use them in.\n​Overview\nHyperliquid perps in the MCP server use two balances on Hypercore:\n\nSpot account: receives bridged funds and holds transferable tokens\nPerp account: holds USDC collateral for perpetual positions\n\nThe usual funding path is:\n\nexternal chain -> Hyperliquid spot (deposit_to_hyperliquid)\nHyperliquid spot -> perp account (transfer_spot_to_perps)\nopen / manage positions\nperp account -> external chain (withdraw_from_perps)\n\nTo withdraw funds from the Hyperliquid spot account (instead of perps), use the phantom perps withdraw-hl-spot CLI command.\nAll perps write operations use the wallet’s EVM signing path on eip155:42161 for Hyperliquid actions. The funding tools are different: they use the Phantom bridge / swap flows where appropriate.\n​What agents can do with perps\nThese tools let an agent do more than just place a single trade. An agent can:\n\ninspect available perp markets and compare price, funding, open interest, and leverage limits\ncheck account value, available margin, and withdrawable balance\nopen long or short positions with configurable leverage\nchoose between market and limit orders\nwatch open positions and active orders over time\nchange leverage or margin mode after a trade is open\nclose part or all of a position when the user asks\nmove funds into and out of the perp account as part of a larger workflow\n\nTypical user requests this enables:\n\n“Open a 5x BTC long with $250 of exposure.”\n“Place a limit ETH short if price comes back to 3,200.”\n“Show me my open SOL perp and close half of it.”\n“Move my remaining USDC out of perps and withdraw it back to Base.”\n\nPerps tools can open leveraged positions and submit irreversible actions. Agents should confirm high-impact trades and withdrawals with the user before executing them.\n​Read-only tools\nToolWhat it returnsget_perp_marketsAvailable markets, price, funding, open interest, 24h volume, max leverageget_perp_accountAccount value, available balance, available margin, withdrawable balanceget_perp_positionsOpen positions, size, direction, leverage, unrealized PnL, liquidation priceget_perp_ordersOpen orders including limit, TP, and SL ordersget_perp_trade_historyHistorical fills, fees, and closed PnL\n​Funding and withdrawal tools\n​deposit_to_hyperliquid\nBridges or swaps from an external chain into Hyperliquid. This is the entry point when funds are not already on Hypercore.\nTypical use:\n\nuser has SOL / ETH / USDC on an external chain\ncall deposit_to_hyperliquid\nfunds arrive in Hyperliquid spot as USDC\ncall transfer_spot_to_perps to move that USDC into the perp account\n\nExample:\n{\n \"sourceChainId\": \"solana:mainnet\",\n \"amount\": \"10\",\n \"execute\": true\n}\n\nAnother example:\n{\n \"sourceChainId\": \"eip155:42161\",\n \"amount\": \"250\",\n \"sellTokenMint\": \"0xaf88d065e77c8cc2239327c5edb3a432268e5831\",\n \"execute\": true\n}\n\n​transfer_spot_to_perps\nMoves USDC within Hypercore from spot into the perp account. This is an internal Hyperliquid transfer, not a bridge.\nParameters:\n\namountUsdc: amount of USDC to move from spot to perps\nderivationIndex (optional): account derivation index, defaults to 0\n\nExample:\n{\n \"amountUsdc\": \"100\"\n}\n\n​withdraw_from_perps\nBridges USDC from the Hyperliquid perpetuals account to an external chain.\nParameters:\n\namountUsdc: amount of USDC to bridge out\ndestinationChainId: destination chain such as solana:mainnet, eip155:8453, eip155:42161\nbuyToken (optional): CAIP-19 token to receive; defaults to USDC on the destination chain\nderivationIndex (optional): account derivation index, defaults to 0\n\nExample:\n{\n \"amountUsdc\": \"50\",\n \"destinationChainId\": \"solana:mainnet\"\n}\n\n​Withdrawing from Hyperliquid spot (CLI only)\nIf funds are in your Hyperliquid spot account rather than the perps account, use the phantom perps withdraw-hl-spot CLI command to bridge them to an external chain. This is useful when you have USDC sitting in spot after a deposit or after moving funds out of perps.\nphantom perps withdraw-hl-spot --amountUsdc 50 --destinationChainId solana:mainnet\n\nParameters:\n\n--amountUsdc: amount of USDC to bridge out\n--destinationChainId: destination chain such as solana:mainnet, eip155:8453, eip155:1, eip155:42161, eip155:137\n--buyToken (optional): CAIP-19 token to receive on the destination chain; defaults to USDC\n--execute (optional): set to true to sign and broadcast immediately; defaults to returning a quote only\n\nOmit --execute to preview the quote before committing:\n# Preview the quote\nphantom perps withdraw-hl-spot --amountUsdc 50 --destinationChainId eip155:8453\n\n# Execute after reviewing\nphantom perps withdraw-hl-spot --amountUsdc 50 --destinationChainId eip155:8453 --execute\n\nMoved from the MCP server to the CLI. Earlier releases exposed this as the withdraw_from_hyperliquid_spot MCP tool (see prior changelog entries). It has since been removed from the MCP server and is now available only via phantom perps withdraw-hl-spot in the CLI. The withdraw_from_perps MCP tool is still the right choice for withdrawing from the perps account directly.\n​Trading tools\n​open_perp_position\nOpens a long or short position. Supports:\n\nmarket orders\nlimit orders\nleverage selection\nisolated or cross margin\nreduce-only flag\n\nParameters:\n\nmarket: market symbol such as BTC, ETH, SOL\ndirection: long or short\nsizeUsd: notional position size in USD\nleverage: leverage multiplier\norderType: market or limit\nlimitPrice (required for limit orders): target price as a string\nmarginType (optional): isolated or cross\nreduceOnly (optional): if true, order can only reduce an existing position\nderivationIndex (optional): account derivation index, defaults to 0\n\nExample (market long):\n{\n \"market\": \"ETH\",\n \"direction\": \"long\",\n \"sizeUsd\": \"100\",\n \"leverage\": 5,\n \"orderType\": \"market\"\n}\n\nExample (limit short):\n{\n \"market\": \"BTC\",\n \"direction\": \"short\",\n \"sizeUsd\": \"500\",\n \"leverage\": 10,\n \"orderType\": \"limit\",\n \"limitPrice\": \"72000\",\n \"marginType\": \"isolated\"\n}\n\n​close_perp_position\nCloses a position fully or partially using sizePercent.\nParameters:\n\nmarket: market symbol to close\nsizePercent (optional): percentage of the position to close, defaults to 100\nderivationIndex (optional): account derivation index, defaults to 0\n\nExample:\n{\n \"market\": \"ETH\",\n \"sizePercent\": 50\n}\n\n​cancel_perp_order\nCancels an open order by orderId.\nParameters:\n\nmarket: market symbol\norderId: numeric order id from get_perp_orders\nderivationIndex (optional): account derivation index, defaults to 0\n\nExample:\n{\n \"market\": \"BTC\",\n \"orderId\": 12345\n}\n\n​update_perp_leverage\nChanges leverage and margin mode for a market.\nParameters:\n\nmarket: market symbol\nleverage: leverage multiplier\nmarginType: cross or isolated\nderivationIndex (optional): account derivation index, defaults to 0\n\nExample:\n{\n \"market\": \"SOL\",\n \"leverage\": 3,\n \"marginType\": \"cross\"\n}\n\n​Recommended agent flow\n​Funding a perp account\n\nget_token_balances\ndeposit_to_hyperliquid\ntransfer_spot_to_perps\nget_perp_account\n\n​Opening and managing a trade\n\nget_perp_markets\nget_perp_account\nopen_perp_position\nget_perp_positions\nget_perp_orders\nupdate_perp_leverage or cancel_perp_order as needed\n\n​Exiting and withdrawing\n\nclose_perp_position\nwithdraw_from_perps (bridges USDC from perps directly to destination chain)\n\nTo withdraw USDC from Hyperliquid spot via the CLI, use phantom perps withdraw-hl-spot.\n​Notes for agents\n\nIf the user asks for their total Hyperliquid exposure, do not rely only on get_token_balances; also call get_perp_account.\nIf the user asks to move funds off Hyperliquid, call withdraw_from_perps with a destinationChainId — it handles the full bridge in one step.\nIf the user already has funds in Hyperliquid spot, skip deposit_to_hyperliquid and use transfer_spot_to_perps directly.\n\n​Related\nWas this page helpful?","tokens":1992,"squid":"spider-10","role":"Tooling Spider","at":1791338768445,"hash":"5d7d71491ef26e7dd0cd6d97baff638657955daa"}
{"url":"https://forum.arbitrum.foundation/c/archive/archived-proposals/66","domain":"forum.arbitrum.foundation","title":"Latest Archive/Archived Proposals topics - Arbitrum","text":"The Arbitrum Foundation notified the Security Council on the need to perform a potential Emergency action. Following a review of the details and known risks, the Security Council decided to execute the upgrade and it was completed at 11:30 EST on 2nd October 2026.\nThis report provides an overview of the risks that required the Security Council Action:\n\nAdd a permissionless guard for the One-Step Proof of BoLD on Arbitrum One\n\nTemporarily pause activation of new Stylus contracts on Arbitrum One & Nova\n\nKey point: To date, known bugs for Stylus primarily impact chain liveness (e.g., denial of service attacks) and do not put any user funds at risk.\nWhy was this action taken\nLet’s take this opportunity to explain why action was taken on two separate issues concerning BoLD and Stylus.\nInstalling the guard for One-Step Proof of BoLD. Given the rise of AI-assisted attacks, we have implemented a precautionary approach that allows anyone to pause settlement of Arbitrum One on Ethereum if there are at least two conflicting answers that pass at the same level in which only one should be valid and pass. This is to halt a class of publicly verifiable and detectable attacks that exploit a bug in the one-step proof. If halted, Arbitrum One will continue to process as normal except that messages from Arbitrum One to Ethereum, such as withdrawals, that are not yet confirmed will have to wait. This provides time for the Security Council to deploy a fix for the bug and resume the rollup.\nPreventing activation of new Stylus contracts. AI-assisted tooling has led to an increasing number of sophisticated attacks on hand-crafted WASM programs that do not use the standard Stylus compiler toolchain. These programs are specifically designed to cause unexpected behaviors such as degrading the chain’s performance for all other users. To date, no attacks have been discovered that permits theft of user funds.\nNew ArbOS releases have patched several reported bugs and known attacks over the past few months, but out of an abundance of caution, we have decided to temporarily pause new activations of Stylus contracts. This was executed as an emergency action to prevent the deployment of new hand-crafted WASM programs that are not yet patched by the current version of ArbOS on the Arbitrum network.\nThe Arbitrum Foundation has informed the Security Council that they will work with the ArbitrumDAO to discuss next steps on the timeline and manner for enabling activation of new Stylus contracts. The Arbitrum community remains confident in the value of Stylus and want to preserve these use cases while taking preventative measures against Stylus-based attack vectors as AI-assisted attack tooling continues to evolve.\nImpact on builders and users\n\nNo new activations. New Stylus contracts cannot be activated during the pause including new versions of existing applications that require activation.\n\nExisting contracts are not paused. Already-active Stylus contracts continue to execute until expiration. This pause does not deactivate them.\n\nThe ArbOS 61 upgrade renewed all active contracts on Arbitrum One, so no currently active contract expires before August 20, 2027.\n\nRenewal via keepalive stays permissionless and is unaffected by the pause.\n\nReactivating an expired contract, or one that needs to be updated after a Stylus version change, is paused.\n\nUsing/calling any activated Stylus contract stays permissionless for all users and developers.\n\nNo impact on EVM. Solidity (EVM) contract deployment and execution are unaffected by this Security Council action.\n\nSecurity Council Actions\nThere are two actions bundled into a single payload:\n\nOne-Step Proof Guard. The L1UpgradeExecutor gives a new pause contract (PauseExecutor) the ability to pause and nothing else. The new pause contract grants the guard (OspSoundnessGuard) PAUSER_ROLE to use it. Anyone can show the guard two conflicting answers to the same step of an open challenge. If the one-step proof accepts both, the guard has the pause contract put Arbitrum One’s settlement to Ethereum on hold.\n\nStylus deactivation. The Security Council called ArbOwner.setWasmActivationGas(2^64 - 1) to raise the Stylus activation gas requirement on Arbitrum One and Nova. This makes activation prohibitively expensive and effectively disables new activations. This is a configuration change and does not require an ArbOS upgrade.\n\nThe Security Council signed the following transactions to update the configuration:\n\nEthereum: Ethereum Transaction Hash: 0x30732bb7d2... | Etherscan\nArbitrum One:\nArbitrum One Transaction Hash: 0x9eb3a4be3b... | Arbitrum One\nArbitrum Nova:\nArbitrum Nova transaction 0x79e0fed470dff7a22059b108e3f8f42eddd2b580a6771594060c4e7326c5f984 | Blockscout\n\nAn external audit was conducted for the OSP Guard contracts. No audit is required for the Stylus deactivation as it is only updating a single parameter in the ArbOS configuration.\n\n Latest topics in Archived Proposals\n\n Archive\n\n Archived 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 The DAO Incentive Program (DIP 2.0)\n\n 53\n\n 2.3k\n\n Dec 2025\n\n [Non-Constitutional] Let’s get our huddles (aka. video calls) in order\n\n 46\n\n 1.5k\n\n Aug 2025\n\n Proposal: Launch Arbitrum App Store & Builder Communities Hub on Common Ground\n\n proposal,proposal-discussions\n\n 17\n\n 582\n\n Aug 2025\n\n Arbitrum Research and Development Collective V2 - Extension\n\n 39\n\n 1.1k\n\n Jul 2025\n\n [Non-Constitutional] Proposal: Establishing the Arbitrum Ecosystem Fund\n\n proposal\n\n 3\n\n 269\n\n Jul 2025\n\n [Non-Constitutional] Let’s improve our governance forum with three proposals.app feature integrations\n\n proposal,governance,proposal-discussions\n\n 83\n\n 2.2k\n\n Jun 2025\n\n Support to Establish GrantsDAOs\n\n 31\n\n 8.0k\n\n Jun 2025\n\n Non-Constitutional: Proposal for Piloting Enhancements and Strengthening the Sustainability of ArbitrumHub in the Year Ahead\n\n 92\n\n 2.6k\n\n Jun 2025\n\n Proposal: Launch Native $ARB Staking at ≈ 8% APY\n\n 2\n\n 690\n\n Jun 2025\n\n Arbitrum Proposals App (GovHack Brussels Winner)\n\n proposal,governance,delegation,proposal-discussions\n\n 35\n\n 1.6k\n\n May 2025\n\n [Non-Constitutional] Service Provider Utilisation Framework\n\n 23\n\n 852\n\n May 2025\n\n [RFC] Empowering Underrepresented Delegates\n\n proposal\n\n 35\n\n 2.1k\n\n May 2025\n\n [Non-constitutional][RFC] ARB Incentives: User Acquisition for dApps & Protocols\n\n 115\n\n 3.3k\n\n Apr 2025\n\n [RFC] ArbitrumDAO Governance Analytics Dashboard\n\n proposal,governance\n\n 58\n\n 1.7k\n\n Apr 2025\n\n [Non-Constitutional] GCP Clawback\n\n proposal\n\n 65\n\n 3.0k\n\n Apr 2025\n\n [NON-CONSTITUTIONAL] Arbitrum Onboarding V2: A Governance Bootcamp\n\n proposal,governance\n\n 157\n\n 4.5k\n\n Apr 2025\n\n Proposal [Non-Constitutional]: Funding DAO Legal Defence and Advocacy with Defi Education Fund\n\n 25\n\n 1.5k\n\n Mar 2025\n\n [Constitutional] Increase resilience to outside attackers by updating DAO parameters to not count ‘Abstain’ votes in Quorum\n\n governance\n\n 69\n\n 1.7k\n\n Mar 2025\n\n [Non-Constitutional] Arbitrum Airdrop 2 - Builder Appreciation Drop\n\n proposal\n\n 36\n\n 1.8k\n\n Mar 2025\n\n Proposal: Not missing the AI train\n\n proposal\n\n 43\n\n 1.2k\n\n Mar 2025\n\n Jumper x Merkl // MAGA 2025 [Make-Arbitrum-Great-Again]\n\n proposal\n\n 17\n\n 1.1k\n\n Mar 2025\n\n Arbitrum Growth Circles Event Proposal\n\n 63\n\n 1.7k\n\n Mar 2025\n\n Grant Request: CyberCash - Driving Crypto Adoption on Arbitrum\n\n proposal\n\n 24\n\n 754\n\n Feb 2025\n\n [RFC] Arbitrum as the Home of Builders - embracing Chain Abstraction\n\n proposal-discussions\n\n 47\n\n 2.2k\n\n Feb 2025\n\n Proposal: [Non-Constitutional]: Building the Arbitrum DAO Creator Economy\n\n proposal,governance\n\n 37\n\n 941\n\n Feb 2025\n\n Non-Constitutional: Amendment to the Delegate Incentives Program\n\n 55\n\n 1.6k\n\n Feb 2025\n\n Request for Proposals: Treasury Management Services for Arbitrum DAO\n\n proposal\n\n 5\n\n 173\n\n Feb 2025\n\n Hackathon for Arbitrum\n\n 13\n\n 368\n\n Feb 2025\n\n The OpCo - Scale, Structure, & Synergy\n\n proposal\n\n 30\n\n 2.9k\n\n Feb 2025\n\n [NON-CONSTITUTIONAL] Proposal for Maintenance and Continuous Enhancement of ArbitrumHub to Meet the Evolving Needs of the Arbitrum Ecosystem and DAO\n\n 38\n\n 959\n\n Jan 2025","tokens":2034,"squid":"spider-07","role":"Council Spider","at":1791338775084,"hash":"f3626beac3798bc2c886c55d6e084444dda35294"}
{"url":"https://docs.arbitrum.io/contribute","domain":"docs.arbitrum.io","title":"Contribute docs","text":"Contribute docsLearn how to contribute to Arbitrum's open-source documentation.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 and Github is expected.\nThis page covers what to write. For how to set up the repository, fill in a page's frontmatter, and run the checks before you open a pull request, follow the workflow guide.\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. A pull request from a branch in that repository gets a Vercel preview deployment of your changes, and the preview updates as you push commits. A pull request from a fork gets one once a maintainer authorizes the deployment.\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.\nDocument type conventions\nEvery document should be a specific type of document, set in its frontmatter as content_type. Each type has its own purpose:\nDocument typeFrontmatter valuePurposeHow-tohow-toProvide task-oriented procedural guidanceConceptconceptExplain what things are and how they workQuickstartquickstartOnboard a specific reader audience with step-by-step \"learn by doing\" instructionsTutorialtutorialWalk a specific reader audience through a comprehensive, guided learning experienceReferencereferenceLists and tables of things, such as API endpoints and developer resourcesTroubleshootingtroubleshootingList common troubleshooting scenarios and solutionsFAQfaqAddress frequently asked questions\ncontent_type must be exactly one of the seven frontmatter values above, spelled in lowercase, or the build fails. See Document type conventions in CONTRIBUTE.md for more on what each type owes the reader.\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\nUse banners to set expectations for your readers or emphasize an important callout, but use them conservatively, since they interrupt the flow of the document. This site renders a banner with the <Callout> component; the same callout-syntax rule appears in STYLE-GUIDE.md. Docusaurus ::: directives do not render here and fail the content:lint docusaurus-directive rule, so never write one. The type prop is one of info (the default), idea, warn, error, or success; pick the type that matches the message, not the page's subject. title is optional; without it the callout shows no heading, and its icon and color carry the type.\nBefore writing a new banner, look through content/partials/ for one that already says what you need, and reuse it instead of duplicating the prose. A partial is pulled into a page with an include directive:\n<include cwd>content/partials/launch-arbitrum-chain/_raas-providers-notice.mdx</include>\nThe cwd flag anchors the path at the repo root, so moving your page later never breaks the include. Inside another partial, drop the flag and write the path relative to the file you are editing. CONTRIBUTE.md's partial-reuse guide covers both forms and how to add a partial of your own.\nTwo banners come up often enough to be worth naming directly.\nUnder construction banner\nUse type=\"warn\" when a page's steps are incomplete or likely to change soon, so readers know to expect gaps.\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<Callout type=\"warn\" title=\"UNDER CONSTRUCTION\">\n\nThe 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.\n\n</Callout>\nCommunity member contribution banner\nUse type=\"info\" at the top of a third-party or community-submitted document to credit the author.\nExample:\nCommunity member contributionShoutout to @handle for contributing the following third-party document!\nUsage:\n<Callout type=\"info\" title=\"Community member contribution\">\n\nShoutout to [@handle](https://github.com/handle) for contributing the following [third-party document](/third-party-docs/contribute)!\n\n</Callout>\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, such as adding an endpoint to the RPC endpoints and providers page, 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!How is this guide?GlossaryA list of terms and definitions related to Arbitrum.FAQList of questions and answers frequently asked by users","tokens":2745,"squid":"spider-01","role":"Chain Spider","at":1791338777855,"hash":"178c1d57ad2ffe77540a4701eed704c45321a764"}
{"url":"https://docs.phantom.com/wallet-sdks-overview","domain":"docs.phantom.com","title":"Phantom Connect SDKs - Phantom developer documentation","text":"The Phantom Connect client SDKs (React, React Native, Browser) let your app authenticate users and create embedded wallets. All client SDKs support Google and Apple social login. Web SDKs (React, Browser) additionally support browser extension connections (the injected provider). Users who connect with the Phantom extension use their existing wallet without creating a new embedded wallet.\nThe Phantom CLI is an adjacent tool with its own setup path and authenticates with phantom login.\nThe Phantom Connect client SDKs are open source. Browse the source code, file issues, and contribute at github.com/phantom/phantom-connect-sdk.\n​Prerequisites (client SDKs)\nPhantom Portal is not accepting new applications at this time. New sign-ups for Phantom Connect SDK access and new app submissions to the Phantom app directory are paused. Existing Portal apps and App IDs are not affected.\nThe React, React Native, and Browser SDKs require an existing app in Phantom Portal:\n\nSign in at Phantom Portal.\nSelect your existing app.\nConfigure allowed domains and redirect URLs.\nGet your App ID.\n\nThe Phantom CLI does not use this Portal flow. See its setup notes below.\n​Explore our SDKs\nEach SDK is designed for specific use cases and environments, providing wallet integration across web and mobile platforms.\n​Web apps\n​React SDK\nUse the React SDK when building React web apps that need wallet connectivity. It provides React hooks for integration with your component architecture.\nIdeal use cases:\n\nDeFi platforms built with React\nNFT marketplaces\nWeb3 gaming interfaces\nToken management dashboards\n\n​Browser SDK\nUse the Phantom Connect Browser SDK for JavaScript/TypeScript apps or any web framework that isn’t React (such as Vue, Angular, Svelte).\nIdeal use cases:\n\nVanilla JavaScript apps\nVue.js or Angular apps\nServer-side rendered apps\nProgressive Web Apps (PWAs)\n\n​Mobile apps\n​React Native SDK\nUse the Phantom Connect React Native SDK to build native mobile wallet experiences on iOS and Android with React Native. Supports secure OAuth authentication with Google and Apple.\nIdeal use cases:\n\nMobile-first DeFi apps\nMobile gaming with blockchain integration\nMobile NFT galleries\nCross-platform wallet apps\n\n​Command line\n​Phantom CLI\nUse the Phantom CLI to interact with your wallet from the terminal. Sign transactions, transfer tokens, swap, manage balances, and trade perpetuals. The CLI also runs as an MCP server for AI agent integration.\nIdeal use cases:\n\nDeveloper workflows and scripting\nAI agent integration via MCP\nAutomated token transfers and swaps\nPerpetuals trading from the command line\n\nSetup. The CLI does not require Phantom Portal signup. Install with npm install -g @phantom/cli, then run phantom login to authenticate via Google, Apple, or your Phantom extension in the browser. See Phantom CLI — Installation for details.\n\n​Client SDK wallet model\nPhantom Connect client SDKs provide user-controlled wallets:\n\nUsers connect their existing Phantom wallets\nUsers maintain full control of private keys\nAuthentication via social login or browser extension\nBest for apps where users manage their own assets\n\n​Security models\nAll Phantom Connect SDKs are built with enterprise-grade security:\n\nTrusted Execution Environments (TEEs) for secure operations\nHardware Security Modules (HSMs) for key encryption\nMulti-layer encryption with threshold cryptography\nCryptographically signed audit trails for compliance\nOrganization-based access control with configurable policies\n\n​Transaction security for embedded wallets\nAll transactions signed for embedded wallets pass through Phantom’s advanced simulation system before execution. This security layer:\n\nSimulates transactions before they’re broadcast to detect potential threats\nAutomatically blocks malicious transactions that could drain funds or exploit vulnerabilities\nBlocks transactions from origins that have been reported as malicious\nProvides an additional layer of protection for your users’ assets\n\n​Chain support\nMonad support has been deprecated.\nSui support has been deprecated.\nThe following table shows current network availability across Phantom Connect SDKs:\nChainEmbedded walletsInjected walletsSolana (Mainnet, Devnet, Testnet)SupportedSupportedEthereumComing soonSupportedPolygonComing soonSupportedBaseComing soonSupportedArbitrumComing soonSupportedSuiNot availableDeprecatedMonadNot availableDeprecated\nEVM chain support for embedded wallets is planned for later in 2026. Injected wallet connections (Phantom browser extension) already support Ethereum, Polygon, Base, and Arbitrum.\n​Authentication options\nAll client SDKs support social login (Google and Apple) and seven-day active sessions.\nWeb SDKs (React, Browser) additionally support:\n\nBrowser extension (injected): Connect directly to the Phantom browser extension\n\nThe React Native SDK currently supports Google and Apple social login only. Browser extension connections are not available on React Native.\nLearn more about Phantom Connect: For detailed information about authentication flows, account selection, and session management, see the Phantom Connect guide.\n​Example apps\nExplore complete, production-ready examples built by the Phantom team:\n\n​Key management and signing\nAll Phantom Connect SDKs support KMS-backed wallets. The SDK completes a Connect sign-in and stamps requests so KMS can validate, authorize, and sign.\n\n​AI-powered setup\nUse the Phantom Cursor plugin to scaffold any SDK project with AI. The plugin includes skills for React, React Native, and Browser SDK setup. Your Cursor agent handles installation, configuration, and boilerplate automatically.\n\n​Need help?\nWas this page helpful?","tokens":1416,"squid":"spider-10","role":"Tooling Spider","at":1791338778380,"hash":"e9023fcbb8c147f6a4501cf3429b3b633afe1c80"}
{"url":"https://forum.arbitrum.foundation/t/non-constitutional-let-s-improve-our-governance-forum-with-three-proposals-app-feature-integrations/29398","domain":"forum.arbitrum.foundation","title":"[Non-Constitutional] Let’s improve our governance forum with three proposals.app feature integrations - Archive / Archived Proposals - Arbitrum","text":"The Arbitrum Foundation notified the Security Council on the need to perform a potential Emergency action. Following a review of the details and known risks, the Security Council decided to execute the upgrade and it was completed at 11:30 EST on 2nd October 2026.\nThis report provides an overview of the risks that required the Security Council Action:\n\nAdd a permissionless guard for the One-Step Proof of BoLD on Arbitrum One\n\nTemporarily pause activation of new Stylus contracts on Arbitrum One & Nova\n\nKey point: To date, known bugs for Stylus primarily impact chain liveness (e.g., denial of service attacks) and do not put any user funds at risk.\nWhy was this action taken\nLet’s take this opportunity to explain why action was taken on two separate issues concerning BoLD and Stylus.\nInstalling the guard for One-Step Proof of BoLD. Given the rise of AI-assisted attacks, we have implemented a precautionary approach that allows anyone to pause settlement of Arbitrum One on Ethereum if there are at least two conflicting answers that pass at the same level in which only one should be valid and pass. This is to halt a class of publicly verifiable and detectable attacks that exploit a bug in the one-step proof. If halted, Arbitrum One will continue to process as normal except that messages from Arbitrum One to Ethereum, such as withdrawals, that are not yet confirmed will have to wait. This provides time for the Security Council to deploy a fix for the bug and resume the rollup.\nPreventing activation of new Stylus contracts. AI-assisted tooling has led to an increasing number of sophisticated attacks on hand-crafted WASM programs that do not use the standard Stylus compiler toolchain. These programs are specifically designed to cause unexpected behaviors such as degrading the chain’s performance for all other users. To date, no attacks have been discovered that permits theft of user funds.\nNew ArbOS releases have patched several reported bugs and known attacks over the past few months, but out of an abundance of caution, we have decided to temporarily pause new activations of Stylus contracts. This was executed as an emergency action to prevent the deployment of new hand-crafted WASM programs that are not yet patched by the current version of ArbOS on the Arbitrum network.\nThe Arbitrum Foundation has informed the Security Council that they will work with the ArbitrumDAO to discuss next steps on the timeline and manner for enabling activation of new Stylus contracts. The Arbitrum community remains confident in the value of Stylus and want to preserve these use cases while taking preventative measures against Stylus-based attack vectors as AI-assisted attack tooling continues to evolve.\nImpact on builders and users\n\nNo new activations. New Stylus contracts cannot be activated during the pause including new versions of existing applications that require activation.\n\nExisting contracts are not paused. Already-active Stylus contracts continue to execute until expiration. This pause does not deactivate them.\n\nThe ArbOS 61 upgrade renewed all active contracts on Arbitrum One, so no currently active contract expires before August 20, 2027.\n\nRenewal via keepalive stays permissionless and is unaffected by the pause.\n\nReactivating an expired contract, or one that needs to be updated after a Stylus version change, is paused.\n\nUsing/calling any activated Stylus contract stays permissionless for all users and developers.\n\nNo impact on EVM. Solidity (EVM) contract deployment and execution are unaffected by this Security Council action.\n\nSecurity Council Actions\nThere are two actions bundled into a single payload:\n\nOne-Step Proof Guard. The L1UpgradeExecutor gives a new pause contract (PauseExecutor) the ability to pause and nothing else. The new pause contract grants the guard (OspSoundnessGuard) PAUSER_ROLE to use it. Anyone can show the guard two conflicting answers to the same step of an open challenge. If the one-step proof accepts both, the guard has the pause contract put Arbitrum One’s settlement to Ethereum on hold.\n\nStylus deactivation. The Security Council called ArbOwner.setWasmActivationGas(2^64 - 1) to raise the Stylus activation gas requirement on Arbitrum One and Nova. This makes activation prohibitively expensive and effectively disables new activations. This is a configuration change and does not require an ArbOS upgrade.\n\nThe Security Council signed the following transactions to update the configuration:\n\nEthereum: Ethereum Transaction Hash: 0x30732bb7d2... | Etherscan\nArbitrum One:\nArbitrum One Transaction Hash: 0x9eb3a4be3b... | Arbitrum One\nArbitrum Nova:\nArbitrum Nova transaction 0x79e0fed470dff7a22059b108e3f8f42eddd2b580a6771594060c4e7326c5f984 | Blockscout\n\nAn external audit was conducted for the OSP Guard contracts. No audit is required for the Stylus deactivation as it is only updating a single parameter in the ArbOS configuration.\n\n [Non-Constitutional] Let’s improve our governance forum with three proposals.app feature integrations \n\n ArchiveArchived Proposals\n\n proposal,governance,proposal-discussions\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jun 2025\n\n 1 / 84\n\n Jun 2025\n\n Jun 2025\n\n post by paulofonseca on Jun 5, 2025\n\n paulofonseca\n\n [Non-Constitutional] Let’s improve our governance forum with three proposals.app feature integrations\nAbstract\nproposals.app proposes a formal collaboration with Arbitrum DAO to enhance the usability of this governance forum, so that delegates, tokenholders, and forum readers can have more context and information about our DAO proposals. We propose designing, developing, testing, and deploying three feature integrations in this governance forum, as well as maintaining and hosting them for a period of one year, for a total of $60,000 USD.\nMotivation\nCurrently, DAO governance remains a disjointed, messy, and confusing experience for delegates and tokenholders. We believe that one of the main reasons for this is the clear lack of foundational DAO tooling that prioritizes true composability and aggregates data from multiple (even competing) offchain and onchain sources, thereby providing a more comprehensive and enjoyable user experience for DAO delegates and tokenholders. We believe that to achieve this, DAO tools should be free and open-source, operate under a non-profit entity that ideally has public financial records of its operations. At proposals.app, we strive to uphold these beliefs.\nAndrei and I have been building DAO tools since mid-2023, starting with Senate, where we previously piloted two forum integrations (one with Uniswap, and another with Aave), and more recently, we’ve been working on proposals.app, where we’ve developed dedicated tooling for Arbitrum DAO’s governance needs that was funded through a questbook grant last October. More specifically, we’ve designed and developed a unified governance aggregator that brings together, under the same platform, the discourse forum comments and both offchain and onchain votes, so that delegates can access the complete history of every proposal in Arbitrum DAO. We launched it publicly on April 5ᵗʰ at ETH Bucharest 2025, and you can check it out at arbitrum.proposals.app and share your thoughts about it with us in our telegram chat.\nWe’re now proposing a formal collaboration with Arbitrum DAO to bring some of the exclusive proposals.app features we have in our app, to this governance forum. We propose designing, developing, testing, and deploying three feature integrations in this governance forum, as well as maintaining and hosting them for a period of 12 months.\n\nWe believe that these three features will enhance usability and accessibility in this governance forum for all users, regardless of their level of maturity.\nThese three features, as demonstrated above, are:\n\nLive Votes – Show the live or latest vote at the top of the page for each forum topic in the proposals category\nVoting Power Tags – Show the voting power of each delegate, under their username, for every comment on the forum\nProposal Notification Emails – Provide a way for forum visitors to subscribe to email notifications, receiving an email every time a new discussion is started, when an offchain or onchain vote begins, and when its voting period is nearing completion.\n\nWith these three proposals.app feature integrations in this forum, we believe will see bigger governance participation and better engagement in discussions, from a more diverse set of delegates and tokenholders, who will have more context about who is commenting on what, about when proposals are up to a vote and where and when to vote in each moment of the proposal lifecycle.\nWe shared a short demo of proposals.app and these three proposed feature integrations on the Open Governance Call on June 3rd, and you can see the recording of that demo and presentation, as well as some Q&A, in the video below:\n\nRationale\nConstantly improving and caring for the governance processes in Arbitrum DAO is essential to maintain a healthy, engaged, resilient, and decentralized DAO. In Arbitrum DAO’s case, where tokenholders and delegates actually have on-chain control over protocol upgrades and treasury spending, it becomes even more critical that they vote with as much context and information as possible in each and every vote.\nAdditionally, in token-weighted voting DAOs, not all voices carry the same weight. Powerful delegates commenting and giving feedback on proposals are crucial signals of support. On the other hand, newly created forum accounts with no voting power, which are becoming more prevalent in the age of AI, make way more noise than signal and disrupt the discussion flow. Proposers and readers should be able to distinguish between the two and everything in between, much more easily.\nAs stated in The Amended Constitution of the Arbitrum DAO, we should strive to follow our stated Community Values, and specifically:\n\nNeutral and open: Arbitrum governance should not pick winners and losers, but should foster open innovation, interoperation, user choice, and healthy competition on Arbitrum chains.\n\nWe believe it’s essential for Arbitrum DAO to have multiple governance platforms available to its tokenholders, delegates, and voters, so that we can attract more and better delegates and voters by providing them with tools that suit their particular needs and help them engage in governance in an easier and clearer way.\nWe also strongly believe that at least one of those front-ends should be fully open-source. Regarding the obvious matter of the resilience of Arbitrum’s DAO governance, we believe there should be a fully open-source front-end for Arbitrum’s DAO governance that would allow delegates and voters to continue participating in governance permissionlessly. proposals.app is fully open source and will continue to be. proposals.app and its future developments can also be self-hosted by anyone (like we’re doing now) under a new domain name, at any time, by anybody in the world.\nSpecifications\nTo implement these three forum feature integrations described above, we will create three distinct Discourse theme components, rather than Discourse plugins.\nThis way, admins of Discourse hosted instances (like the one for the Arbitrum DAO forum) can easily install each one of these feature integrations from a GitHub repo link (where the code will be fully open-source and auditable, of course) and manage the updates for each feature integration independently, as we evolve and maintain them after the initial deployment.\nAs mentioned above, this is how we previously integrated with the Uniswap and Aave governance forums, in the past.\nSteps to Implement\nWe will design, develop, test, and deploy these 3 Discourse forum proposals.app feature integrations, in the following order:\n\nVoting Power Tags – Showing discourse users’ voting power alongside their usernames in every topic and post in the Arbitrum DAO governance forum. To achieve this, we must retrieve all previous delegation data for the $ARB token and maintain a mapping between the top discourse users and voting wallets on Arbitrum DAO. This voting power tag will always display the current voting power of each delegate by default. Upon clicking on it, the delegate’s voting power at the time the comment was posted will be displayed instead.\nVoting Power Tag showing Entropy's 25.7M ARB delegated voting power, at the time of posting this comment.1124×486 80.7 KB\n\nLive Votes – In every proposal posted in the Arbitrum DAO governance forum, which goes up for an offchain or onchain vote, we will display a component at the top of the forum proposal page, which shows that there is an active offchain or onchain vote, the current live results of that offchain or onchain vote, and a link to vote on it. To achieve this, we must map all forum proposals and their respective Snapshot votes and onchain votes, as well as index all voting data from either Snapshot’s API or the onchain Arbitrum DAO Governors (both the non-constitutional Arbitrum Treasury governor and the constitutional Arbitrum Core governor).\nLive Vote results on the Quorum Threshold Reduction proposal in the forum, showing that there is an active offchain vote which ends in 4 hours, and directing delegates to the voting platform.2097×925 161 KB\n\nProposal Notification Emails – In the Arbitrum DAO governance forum homepage, we will display a “Setup Proposal Notifications” button, which will open a modal for forum users to subscribe to email notifications, so that they can receive timely emails whenever a new proposal discussion is posted on the forum, when an offchain or onchain vote starts, and when an offchain or onchain vote is about to end. To achieve this, we need to maintain a GDPR-compliant list of emails and newsletters, as well as a dedicated subdomain and address to send email notifications from, ensuring optimal email deliverability for those email notifications.\nModal to subscribe to proposal email notifications2033×800 219 KB\n\nTimeline\nFollowing the successful approval of this proposal and the initial onchain transfer, we will hold a project kickoff call and begin building the first integration, the Voting Power Tags, which we can deploy and deliver within one month. Then we will work on the Live Votes integration, which we can also deploy and deliver within one month. Finally, we will work on the Proposal Notification Emails integration, which we will also deploy and deliver within one month.\nIn total, it will take us 1 month to deliver these three feature integrations to the Arbitrum DAO after the project kickoff call, which should happen after a successful onchain vote. During this time, we will work with all Arbitrum DAO delegates to gather feedback on this functionality and improve it to meet your needs. After deploying all these integrations, we will maintain and host them for a period of 12 months.\nTimeline3200×928 62.6 KB\nWe plan to put this proposal up for a temperature check offchain vote on Thursday, June 12th. After a successful offchain vote, we will move this proposal and publish an onchain vote on Monday, June 23rd, to start the voting period on Thursday, June 26th.\nAfter a successful onchain vote, we can kick off this work and start the timeline proposed above, as early as July 15th.\nThis would mean that we could deliver all of the proposed scope, 1 month later, on August 15th.\nOverall Cost\nWe propose to build, maintain, and host these three feature integrations for Arbitrum for a minimum of 12 months. The total cost to the Arbitrum DAO, is $60,000 USD.\nHere is the cost breakdown:\n\nItem\nAmount\n\nMaintenance 1 year (1 day of Design + 1 day of Development + 1 day of Testing, per month)\n$48,000 USD\n\nHosting 1 year (3 Servers, DNS, and Emails)\n$12,000 USD\n\nTotal\n$60,000 USD\n\nThe Maintenance fee includes 1 day per month of Design, 1 day per month of Development, and 1 day per month of Testing, to ensure we maintain these features with an up-to-date user experience and quality of service, and that we can incorporate the delegates’ future feedback on these proposals.app feature integrations.\nThe Hosting fee includes the monthly costs for all the infrastructure we use, which can be live-monitored on status.proposals.app.\nWe propose that the payment be done as a one-time payment of $60,000 USD.\nAfter a successful onchain vote, the funds should be transferred either to the MSS or the Arbitrum Foundation (depending on the outcome of the current Wind Down the MSS proposal), which would certify the delivery of the three feature integrations and release the payment after a successful deployment.\nPledge\nAndrei and Paulo pledge to continually work towards a future where DAO governance tools are genuinely credibly neutral. Therefore, our work is public, fully open-source, and happens with transparent financials. Additionally, proposals.app will soon be established as a non-profit entity, and we pledge never to accept venture capital funding. Until now, proposals.app has only received a $43,000 USD grant from Arbitrum DAO via Season 2 of the Domain Allocator grants on Questbook, as well as $6,000 USD for the first-place prize in the Arbitrum GovHack at ETHcc Brussels. No other funding, from any other source, was received, as shown in our multisig.\n Thank you\nThank you for taking the time to read this proposal through to the end. Please provide us with your honest and most critical feedback. We know we need it, and we genuinely welcome it!\nAlso, a very special thanks to @Sinkas from L2BEAT, Denys from @lobbyfi, Tnorm from Gauntlet, Sam from @Entropy, @MinistroDolar from Seedgov, Yambette, @jameskbh, @pedrob, @Juanrah, @KlausBrave, @ana.vc from Farstar, and Raam and Patrick from the @Arbitrum Foundation, who were kind enough to make their time available to us, to try out and test the arbitrum.proposals.app and collectively gave us over 250 user insights and pieces of feedback. And also a huge thank you to everybody else who reached out to us with feedback, bug reports, and suggestions.\nWe sincerely appreciate you and look forward to hearing more from you as we launch new features to serve you better and better.\n\n Governance Widget Integration – Who’s the Right Contact?\n\n Lampros DAO Delegate Communication Thread\n\n Griff Green - Delegate Communication Thread\n\n 26\n\n 2\n\n 2\n\n 2\n\n 2\n\n read \n\n 41\n min\n\n post by paulofonseca on Jun 5, 2025\n\n paulofonseca\n\n You can also reach to me on Telegram, where my handle is @paulofonseca1987, if you prefer to give us private feedback about this proposal. Thank you!\n\n post by GFXlabs on Jun 5, 2025\n\n GFXlabs\n\n Thank you, Paulo for this proposal!\nGFX believes these features would be incredibly useful and well worth the spend.\nVoting power tags will help delegates know quickly when a commenter is entrusted with significant voting power, is a minor delegate, or is an outside observer.\nLive voting with a quick link to the appropriate voting venue should hopefully increase the timeliness and participation for votes. As it stands now, a casual observer may have difficulty knowing when a vote has begun and tracking its outcome. Having an easy user flow from the parent forum thread to the vote is an upgrade with no down side.\nWe want to simultaneously highlight the email notifications as well as disclose that PaperImperium, who is the governance lead at GFX Labs, did previously have a small investment in Senate (which wound down), which this development team were part of. The email notifications in particular are a simple thing that makes for a lot of time savings and improved response time, which we can attest to from the days that Senate was operating similar notifications. We felt the loss of that, and our daily routine to get up to speed on forum discussions and proposals is longer than it was when those notifications were available.\nOverall, these are all pure quality-of-life upgrades for delegates and forum observers (like reporters and academic researchers). $100k/year will easily pay for itself in time saved, and hopefully increased and more timely participation as well.\nWe support this proposal.\n\n post by danielo on Jun 5, 2025\n\n danielo\n\n These features feel useful and I can see myself using them. But I have concerns with the proposal:\n\nContract length: Will Arbitrum keep having significant proposal flow? Org design wise I know some of the largest delegates are aligned on moving more decisions to units and keeping the DAO more high-level. As such, a 2 year contract feels unnecessarily long for something that might change quite a bit soon. 1 year should be plenty.\nCost: 200k for this is quite a bit. Having built multiple apps, items like the proposal email notification are maybe at 5x the cost. I see teams that have received a grant deliver the equivalent in new features for $25k. The proposal cost should be 1/3 - 1/4.\n\n post by DonOfDAOs on Jun 5, 2025\n\n DonOfDAOs\n\n I haven’t reviewed deeply enough to comment on budget one way or another.\nBut, what I can say is the notion of completely at-cost build is reductionist to the advancement of the DAO. Builders (such as Paulo) who have shown extreme commitment to the ecosystem and have delivered quality products do deserve to be respected as a service provider, not a bounty shop.\nI’d be completely comfortable with some built in premium as it retains good builders and, good builders in turn reinvest their efforts back into the ecosystem. This is superior to a bargain basement race to the bottom of grant bounty hunters just to undercut ten thousand here or there off total cost. Especially when they then take the money and leave. It’s not always about pm’ing grants for the cheapest solution\nInvesting in builders, (especially for non-exorbitant amounts) is worth the extra bit.\n\n post by Oni on Jun 6, 2025\n\n Oni\n\n I appreciate the intention to improve the forum environment, but I have concerns about the proportionality between the proposed features and the budget requested. I would also like to comment on the features.\n\nAs someone with a UX/UI perspective, I recognize that displaying “Live Votes” results could add real functional value by making it easier to track proposals and better understand the governance process. On the other hand, while “Proposal Notification Emails” aren’t essential, they could still be helpful for certain users (myself included) as reminders to stay updated on new proposals and key voting stages.\nHowever, the “Voting Power Tags” feature doesn’t seem to address a critical need or provide a clear benefit to the user experience. In my opinion, such tags could unintentionally introduce bias into discussions by conditioning the perception of comments based on the voting power, rather than the content itself.\nTherefore, the total budget of $206,400 USD should be considered, with $120,000 for maintenance and hosting only, as I consider this to be a little high given the scope of the improvements. It is not that these features do not add value, but the proposed cost is high for a change that does not fundamentally transform participation or address urgent problems in the system.\nI think a more reasonable alternative would be to prioritize the visibility of the most impactful feature, “Live Votes” and evaluate its adoption before moving forward with the others. This would allow for a more data-driven and cost-effective approach.\nI value you effort to improve the DAO, but in this case, moving forward with the full proposal doesn’t seem like the most efficient path. A more gradual, focused rollout with a leaner budget might deliver better results. In addition, @paulofonseca I would like to share some ideas that came to me while I was writing. \n\n post by paulofonseca on Jun 6, 2025\n\n paulofonseca\n\n danielo\n\n Hey @danielo thank you for reading our proposal and for the positive words about the features we proposed.\nAddressing your concerns:\n\nRegarding the contract length, I agree with you that maybe the proposal flow in Arbitrum DAO will decrease given the proposed new vision (I pointed that out myself last month here) but we still don’t know for sure what is going to happen regarding that. The fact is that in April we had less proposals and votes than the last 6 months, but it feels to me like it picked up a little bit more in May. Also, the reason we proposed a 2 year contract for Arbitrum DAO is so that Arbitrum can lock down this $60,000 USD a year maintenance + hosting price, for the next 2 years. One year from now, the price for these features will most likely be higher than what we are proposing now, so by committing to a 2 year contract, Arbitrum DAO would actually be getting a better deal than committing to a 1 year contract only.\n\nRegarding the overall cost, it is very reductive to evaluate the cost for these features based solely on the 3 actual features we propose. The reality is that these features only work, and are only reliable, if there is a back-end platform that correctly indexes data and processes this data. This back-end needs to be constantly improved and is actually quite costly to run. We’ve spent the last 9 months developing that back-end under the scope of proposals.app and the last 3 years if we include the scope of Senate as well. This back-end is what powers the currently available arbitrum.proposals.app platform launched in April, and it will power all of these proposed features.\n\nThis spreadsheet offers more fine-grained detail on the costs, which show how we arrived at the $206,400 USD final amount.\nHaving worked in user research, ux design, and software development myself for the last 15 years, while running companies that provide these services, and having designed and delivered dozens of apps for different industries all over the world, I feel these costs are actually very reasonable for a quality and reliable product.\n\n post by paulofonseca on Jun 6, 2025\n\n paulofonseca\n\n Oni\n\n Hey @Oni Thank you for reading and giving feedback!\nPlease really do reach out to me on telegram to share those ideas that came up!\nAddressing your feedback:\n\nRegarding the features, we actually feel like the Voting Power Tags is the more interesting feature of the 3, in the sense that it is the most novel, experimental, and therefore the one from which we could learn the most. As an anecdote for context, I gave a talk yesterday at ETH Belgrade where I talked about DAO governance and how proposals.app aims to help with our typical messy governance in DAOs, and I showed the demo of these features in the talk as examples of something that could help untangle the mess a little bit. One of the attendees (who works at the Ethereum Foundation) asked a question precisely about the bias that these Voting Power tags could introduce in the discourse and deliberation phase of proposals in a DAO and we then talked at length after the talk about the pros and cons of it. We came to the conclusion that there is more downside to not knowing who is commenting on a forum, then the potential bias it introduces by showing the voting power. Another feedback we had from some other delegates in private about this feature, is that it could show more info other than the voting power, like the delegate karma score, number of proposals published, etc.\n\nRegarding the cost concerns, as replied above, we think the total $206,400 USD cost should be evaluated from a point of view that the $60,000 USD a year maintenance + hosting cost is also required for the whole back-end platform that powers these features, not just the actual three proposed features themselves.\n\nAlso, as a general note, and echoing what fellow builder @DonOfDAOs says above, we believe Arbitrum DAO should invest in builders and products that are aligned with the DAO, not from a at-cost perspective, but from an empowering and future proofing perspective.\n\nThe Arbitrum DAO should not expect to pay dedicated service providers with track record and commitment to the DAO, in feature by feature fashion, and get a good quality result out of it.\n\n post by cp0x on Jun 6, 2025\n\n cp0x\n\n Thanks for the offer\nI have used this application and I want to say that the first two functions are very convenient and would definitely be useful for Arbitrum.\nThe third function for mailing seems to me to duplicate the existing mailings from the forum a little, although in a more convenient format\nAmong the disadvantages, I see the cost. For crypto, any amount can be presented as small lately.\nHowever, for each item of the estimate, I have a feeling that the cost is too high, especially for Maintenance + Hosting (2 years) $120,000 USD (for example, I rent a server for my site, which costs me $5-10 per month, I don’t understand where this cost comes from)\nThere is probably more than one solution here, but if Paulo considers this a fair price for all items, then he has the opportunity to distribute this cost between different forums of other projects. Due to this, we will get improvements for reasonable money.\n\n post by GozmanGonzalez on Jun 6, 2025\n\n GozmanGonzalez\n\n This is exactly the kind of upgrade DAO governance needs.\nFrom live vote visibility to contextual delegate power and real-time email alerts, these integrations by @proposals.appcould be game-changers for Arbitrum’s governance forum.\nToo often, critical proposals are buried in comment threads, and delegates lack the signal-to-noise clarity needed for real participation. These tools directly address that, making it easier to vote, engage, and understand who’s saying what and why it matters.\nOpen-source, community-aligned, and transparently priced, this is a solid step toward more accessible, composable, and resilient DAO infrastructure.\nLooking forward to seeing the adoption and even more excited to see the impact.\n\n post by itugov on Jun 6, 2025\n\n itugov\n\n Thanks for your proposal. It is obvious that the integration of the mentioned features into the forum will be very useful for delegates and tokenholders. Especially the proposal notification emails are really nice for tracking the proposals. However, there are some points that we are uncomfortable with. We think that most of the features are entry-level functionality and similar services can be provided at low costs. In addition, some of the mentioned features can already be controlled through other sites. (For example: Karma Dashboad for live voting, Snapshot and Tally for voting). We are aware that you want to create a better and more efficient user experience by integrating them into the forum and we appreciate your effort, but when the requested budget is compared to the suggested features, we think that this cost is too high. We think that especially the Maintenance and Hosting fee should be explained with a more detailed spending plan. We can say that we will approach the proposal positively if the requested budget is reduced to a more reasonable level.\nITU Governance, @harryvors\n\n post by paulofonseca on Jun 7, 2025\n\n paulofonseca\n\n cp0x\n\n Hey @cp0x thank you for reading and giving feedback!\nJust to clarify that the third feature, of Proposal Emails Notifications notifies not just when new forum proposals are available but also, when new offchain (snapshot) and onchain votes start and are about to end.\nThe email notification currently look like this, and you can go to arbitrum.proposals.app/profile to subscribe to them. What we are offering here is an easier way for users of these forum to subscribe to these email notifications.\nEmail notification for new proposal discussions posted in the forum1872×1804 187 KB\nEmail notification for when a vote period is about to end, in 24 hours.1872×1804 195 KB\nRegarding the cost concerns, especially regarding the maintenance + hosting cost, allow me to offer a bit more context for those amounts.\nThe hosting cost is $1,000 USD per month, for 2 years. This includes all server costs, and software to run the whole infrastructure of proposals.app that is dedicated to Arbitrum DAO. This includes 2 hosting servers, 1 AI server, the email deliverability service, DNS service, and the DevOps cost to maintain all of the infrastructure working properly and reliably. You can see an overview of all our back-end services and servers uptime in status.proposals.app.\nThe maintenance cost is $4,000 USD per month, for 2 years. This includes 1 day of Design, 1 day of Development and 1 day of Testing per month. This allows us to offer a dedicated support to Arbitrum DAO, to fix any bugs that are found, as soon as possible and to even improve the features we are offering here with more functionality. As we keep building the core product of proposals.app with more features, these 3 feature integrations in the forum will become better and richer over time. We already got some feedback in private of how these feature integrations could evolve and offer an even better experience for delegates, tokenholders, and users in this forum.\nYou can see the details of the cost breakdown in this spreadsheet linked in the proposal above.\nMaintenance + Hosting cost breakdown1730×284 30.1 KB\n\n post by paulofonseca on Jun 7, 2025\n\n paulofonseca\n\n itugov\n\n Hey @itugov thank you for reading and giving your feedback!\nIn the comment above I just detailed the costs for the Maintenance + Hosting cost a bit further.\n\nLet me know if that brings more clarity into it.\nAlso, I would like to point out that proposals.app is not VC backed, and will be operating as a public goods funded, non-profit entity. Meaning that the costs are not being subsidized by investors hoping to get a return on their investment. As we say in the proposal above, we deeply believe that DAO tooling should be fully open-source, credibly neutral and funded in a public goods fashion. That usually implies that open-source driven organizations need to rely on maintenance subscriptions to maintain their products up to par and to offer the best possible experience to their users.\n\n post by ostanescu.eth on Jun 8, 2025\n\n ostanescu.eth\n\n This is a strong step forward for improving governance UX. The integrations are practical, composable, and well-scoped. LFG \n\n post by Maets23 on Jun 8, 2025\n\n Maets23\n\n I know i’ m not a delegate, but I love this thing. Price seems right too being it is a custom software integration.\nI’d buy this in a flash based on the cost value ratio.\n\n post by daveytea on Jun 9, 2025\n\n daveytea\n\n This looks really cool and useful. It should be supported.\nMy 2 cents:\n\nI think the DAO should support multiple redundant ways to access information as it helps with decentralisation. So even if data is available on Karma/Tally/etc, having multiple ways to consume that same data is beneficial.\nEvaluating funding proposals by line items is the wrong approach, as someone can always do it cheaper somewhere else in the world. Additionally, there is a lot more work being done than just what is expensed via line items. Funding proposals should be evaluated by their perceived impact, rather than trying to optimise costs. So in this case, if the DAO receives more than $200k worth of value over 2 years, it should be an easy decision. A quick example calculation might be if 100 delegates become 10% more effective because of this, and the DAO currently spends $1,000 p/month on delegate incentives for each of them, then its about $10k p/month of impact provided.\n\n post by jameskbh on Jun 9, 2025\n\n jameskbh\n\n Thanks for this proposal!\nAs one able to test some of those features in your app, I must say I find them useful. Some more, and some, not so much. Each person has their own flow, and that reflects how they value the features proposed here. I have a question/suggestion:\nHow are you planning to put this up for a vote? Yes/No/Abstain for the whole package? Is it possible to breakdown the costs so we can have a modular approach to it and have the voting options to reflect that?\nThanks in advance!\n\n post by Tane on Jun 9, 2025\n\n Tane\n\n We appreciate the effort that the proposals.app team has put into mapping the fragmented governance journey and trying to stitch the experience together in one place. As active delegates we constantly bounce between the forum, Snapshot, Tally, block explorers, and a swarm of dashboards; that cognitive overhead is real, so a unified front-end that lowers the “where do I click next?” friction is directionally attractive.\n\nHowever, in line with @Oni’s observation, the quoted $200 k over two years feels steep for three stand-alone features. Live vote surfacing is the clear standout: it connects the conversation layer to the decision layer, giving readers an at-a-glance pulse of what actually matters right now. By contrast, voting-power tags and extended email alerts strike us as nice-to-have embellishments whose marginal utility is harder to price at six figures. Several community members have already built comparable widgets at a fraction of the proposed cost, or even ourselves for internal purpose as well, so the premium needs stronger justification than we have seen so far.\n\nLooking at the cost breakdown, while it seems somewhat high, we don’t think it indicates a significant issue. Rather than suggesting the cost itself is unreasonable, we understand this as a type of problem where the benefits the DAO gains from solving the issue do not easily balance with the cost required for the solution.\nBecause we do see value in credibly neutral, open-source tooling, we would prefer a structure that lowers the cost for the DAO while still supporting the experiment.\nOne concrete suggestion would be Cost-sharing with other DAOs. If these integrations are broadly applicable, splitting hosting and maintenance across multiple communities would drop Arbitrum’s share to a level that better matches the incremental benefit.\n\nWe could also narrow the scope and shorten the period to start smaller.\n\nWith tighter scope, shorter runway, and shared overhead, we believe Arbitrum can support this initiative without over-committing treasury resources. We look forward to seeing a revised proposal that balances ambition with fiscal prudence and provides objective success metrics up front.\n\n post by paulofonseca on Jun 9, 2025\n\n paulofonseca\n\n jameskbh\n\n Hey @jameskbh thank you for reading, for the continued interest and support, and for that suggestion!\nAnd yes, we are aiming of putting this up for a vote, as a whole package, with a basic voting type of For / Abstain / Against for the offchain vote on Snapshot and with the proposed whole-package price.\nWe could maybe use an approval vote type of vote, to gauge which features would be more popular among delegates, and then go to the onchain vote with a proposal that includes the features that had more than the 3% quorum of voting weight in the offchain vote, with a package price for that selection of features. To be honest, the final price tag wouldn’t be that much cheaper, proportionally per item, if we were to do just 1 or 2 of the 3 proposed features. So right now, this 3 feature package is probably the best deal we can offer to Arbitrum DAO.\nIn the opposite direction, we’ve got some feedback, in private, of some other additional features we could also do (not now, but in the near future) and if we would add a 4th feature, the whole package would become cheaper, in a per item basis.\nAnd regarding this issue, we would also like to highlight and echo what fellow builder @daveytea says above:\n\nWe believe these three usability and accessibility improvements, in tandem, will bring a better experience to delegates in Arbitrum DAO. They will make delegates lives easier, minimize mistakes (there have been cases of delegates voting in one proposal with the reason for another proposal for example), improve voter participation (since delegates will get timely emails reminding them to vote), and bring more clarity overall about who is who in Arbitrum DAO (since everybody will be able to see the voting power of commenters in this forum).\n\n post by paulofonseca on Jun 9, 2025\n\n paulofonseca\n\n Hey @Tane thank you for reading, for the kind words, and for giving your feedback!\nAddressing your feedback:\n\nWe don’t believe this is a fair comparison. Building an one-off widget or an internal tool requires a way lower level of commitment and maintenance that is totally different than what we are proposing here. The bulk of the cost in our proposal, pertains to the Maintenance + Hosting line item because it is actually the most valuable service we are proposing to offer to Arbitrum DAO.\nOn the other hand, with this proposal, we are guaranteeing that whatever happens, Arbitrum DAO will have these feature integrations up to date and reliably working on its governance forum. And everybody that has built quality reliable software before, especially in the DAO governance space, knows this is quite hard to pull off.\nEspecially when it comes to have reliable governance data. And specifically delegates voting power, which is a really hard thing to get constantly reliable data of.\nFor example, and I just checked this right now, you can see that @Plutus(0xbbe98d590d7eb99f4a236587f2441826396053d3) voting power is being reported as 954.28K ARB on Tally, but as 954.37K ARB on Karma.\nPlutus DAO Voting Power on Tally.xyz at Jun 9th at 12:19pm UTC942×484 35.9 KB\nPlutus DAO Voting Power on Karma.xyz at Jun 9th at 12:19pm UTC830×706 37.7 KB\nThe correct voting power, as per the ARB token contract, at 12:19pm today, aka. at the 22666976 ethereum block is 954.33K ARB (or 954328.938917807101820975 ARB to be more precise) and that’s what we have on the proposals.app back-end, as you can see in the screenshot below where it shows 954328.94 ARB at June 9, 2025, 12:18 PM (UTC)\nPlutus DAO voting power on proposals.app at Jun 9th at 12:19pm UTC3188×1868 247 KB\nAnd look, I’m not trying to put down other governance tools in this space with the example above, I’m just trying to highlight, that once you look close enough (and we’ve been doing that for quite a while) it is actually quite hard to index governance data reliably.\nOur open-source, non-profit, public goods funded approach at proposals.app is the best way we can think of, of having a reliable, long-term infrastructure for this kind of thing, that can serve DAOs for the long run. That’s why we believe that relying on DAOs like Arbitrum to fund these development efforts instead of pursuing a VC backed approach, is the right strategy.\nAnd that’s why we put up this proposal for Arbitrum DAO to fund these forum integrations and align the future of proposals.app with the Arbitrum DAO.\n\n Load more posts below","tokens":10648,"squid":"spider-07","role":"Council Spider","at":1791338785798,"hash":"ac99ed97c031e808f68b7d88d0ad240c6d17079f"}
{"url":"https://docs.arbitrum.io/get-started/faq","domain":"docs.arbitrum.io","title":"Arbitrum FAQ","text":"Arbitrum FAQList of questions and answers frequently asked by usersRequest an updateWhy do I need ETH to use the Arbitrum network?\nETH is the currency used to pay gas fees on Arbitrum, and it powers all transactions on Arbitrum. You can bridge ETH (and other tokens) from Ethereum to Arbitrum through Arbitrum's bridge.\nDo I need to pay a tip or priority fee for my Arbitrum transactions?\nTransaction processing occurs in the order that the Sequencer receives them; no priority fee is necessary for Arbitrum transactions. If a transaction includes a priority fee, the origin address of the transaction will be refunded at the end of execution.\nHow can I see the balance of ETH and other tokens in my wallet on Arbitrum?\nMost wallets are \"connected\" to one given network at a time. To view your ETH or token balances, ensure that you have an established connection to the appropriate Arbitrum chain. In MetaMask and OKX Wallet, you can switch networks via the Networks drop-down. In this drop-down, please select the desired network (either Arbitrum One or Arbitrum Nova for our mainnet networks). If your preferred network hasn't been added to your wallet yet, you can add it via the Arbitrum Bridge.\nWhat happens if I send my funds to an exchange that doesn’t support Arbitrum?\nIf you send the funds and the receiving wallet/exchange doesn't support the Arbitrum network you are sending funds through, unfortunately, there is nothing we can do to recover your funds. You would need to contact the wallet/exchange support and see if they can assist you in retrieving the funds.\nDoes Arbitrum have a mempool?\nThe Arbitrum Sequencer orders transactions on a first-come, first-served basis. The Sequencer inserts transactions into a queue based on the order in which they are received and executes them accordingly, which eliminates the need for a mempool. The Sequencer's queue has no space limit; transactions on the queue will eventually timeout and get discarded if not executed within a reasonable timeframe. Under normal conditions, the queue is empty, as transaction execution occurs nearly instantaneously.\nWhat's the difference between Arbitrum Rollup and Arbitrum AnyTrust?\nArbitrum Rollup is an Optimistic Rollup protocol; it is trustless and permissionless. Part of how these properties are achieved is by requiring all chain data to be posted on layer 1. This means the availability of this data follows directly from the security properties of Ethereum itself, and, in turn, that any party can participate in validating the chain and ensuring its safety. For more information, see Inside Arbitrum Nitro.\nBy contrast, Arbitrum AnyTrust introduces a trust assumption in exchange for lower fees; data availability is managed by a Data Availability Committee (DAC), a fixed, permissioned set of entities. We introduce some threshold, K, with the assumption that at least K members of the committee are honest. For simplicity, we'll hereby assume a committee of size 20 and a K value of 2:\nIf 19 out of the 20 committee members and the Sequencer are malicious and colluding together, they can break the chain's safety (and, e.g., steal users' funds); this is the new trust assumption.\nIf anywhere between 2 and 18 of the committee members are well behaved, the AnyTrust chain operates in \"Rollup mode\"; i.e., data gets posted on L1.\nIn what should be the common and happy case, however, in which at least 19 of the 20 committee members are well behaved, the system operates without posting the L2 chain's data on L1, and thus, users pay significantly lower fees. This is the core upside of AnyTrust chains over rollups.\nVariants of the AnyTrust model in which the new trust assumption is minimized are under consideration; stay tuned.\nFor more, see Inside AnyTrust.\nHow can I check the status of my cross chain message?\nTo check the status of a deposit or withdrawal, search for its transaction hash in the bridge transaction history, where you can also claim withdrawals. For any other retryable ticket, or to redeem one manually, use the Retryable Tickets tool.\nYou'll need the transaction hash of the \"initiating transaction\": the L1 transaction hash for an L1-to-L2 message (e.g., a deposit), or the L2 transaction hash for an L2-to-L1 message (e.g., a withdrawal).\nIf you cross-chain message was initiated from https://bridge.arbitrum.io/, you can also check its status / execute it at that site in the transaction history tab.\nIf there is a dispute, can my L2 transaction get reorged / thrown out / \"yeeted\"?\nNope; once an Arbitrum transaction is included on L1, there is no way it can be reorged (unless the L1 itself reorgs, of course). A \"dispute\" involves Validators disagreeing over execution, i.e., the outputted state of a chain. The inputs, however, can't be disputed; they are determined by the Inbox on L1. (See Transaction Lifecycle)\n...okay but if there's a dispute, will my transaction get delayed?\nThe only thing that a dispute can add delay to is the confirmation of L2-to-L1 messages. All other transactions continue to be processed, even while a dispute is still ongoing. (Additionally, in practice, most L2-to-L1 messages represent withdrawals of fungible assets; these can be trustlessly completed even during a dispute via trustless fast \"liquidity exit\" applications. See L2-to-L1 Messages).\nAre “Sequencers” the same entities as “Validators”? Can a centralized Sequencer act maliciously (e.g., steal all my money)?\nNo and no!\nAn Arbitrum Chain's Sequencer(s) and Validators and completely distinct entities, with their own distinct roles.\nThe Sequencer is the entity granted specific privileges over ordering transactions; once the Sequencer commits to an ordering (by posting a batch on Ethereum), it has no say over what happens next (i.e., execution). A malicious/faulty Sequencer can do things like reordering transactions or temporarily delaying a transaction's inclusion — things which could be, to be sure, annoying and bad — but can do nothing to compromise the chain's safety.\nThe Validators are the ones responsible for the safety of the chain; i.e., making bonded claims about the chain state, disputing each other, etc.\nCurrently, on Arbitrum One, the Sequencer is a centralized entity maintained by Offchain Labs. Eventually, we expect the single Sequencer to be replaced by a distributed committee of Sequencers who come to consensus on transaction ordering. This upgrade will be an improvement; we don't want you to have to trust us not to reorder your transactions. However, it also isn't strictly necessary for Arbitrum One to achieve its most fundamental properties.\nIn other words: An Arbitrum Rollup chain with a centralized Sequencer could theoretically still be trustless!\nWhich is to say — the more important thing than decentralizing the Sequencer, i.e., the thing you ought to care more about — is decentralizing the Validators.\nArbitrum One's validator set is currently allowlisted; over time, we expect governance to expand the allowlist and eventually be removed entirely.\nFor more info see \"State of Progressive Decentralization\".\nWhy was “one week” chosen for Arbitrum One’s dispute window?\nThe expectation is that one week should be sufficient for validators to conduct an interactive dispute, provided they do not face challenges in getting their transactions included on Layer 1. The one-week decision occurred following a consensus among the Ethereum research community and other Layer 2 projects. The intention is to allow the community sufficient time to coordinate socially in the event of a coordinated Ethereum bonder censorship attack.\nWhat’s the state of Arbitrum One’s decentralization?\nSee \"State of Progressive Decentralization\", or check out the work of our friends at L2BEAT.\nAre there any Fiat on-ramps that support Arbitrum?\nYes, you can find a list of Fiat on-ramps that support Arbitrum on our portal.\nHow many blocks are needed for a transaction to be confirmed/finalized in Arbitrum?\nThere are two levels of finality in a transaction lifecycle:\n\nSoft finality: Once the Sequencer receives and processes a transaction, it emits a receipt through the Sequencer's feed. At this point, if the Sequencer is trusted, the transaction will not undergo reordering, and after processing, the chain state can be determined.\nHard finality: At this stage, assuming there's at least one well-behaved active Arbitrum validator, the client can treat their transaction's finality as equivalent to that of an ordinary Ethereum transaction.\n\nWhere can I find stats for Arbitrum?\nAlthough we currently don't maintain any stats dashboard for Arbitrum, you can find many community created dashboards in Dune.\nWill transactions with a higher “gas price bid” be confirmed first?\nThere is no notion of a mempool on Arbitrum; transactions are processed on a first-come, first-served basis by the Sequencer. Thus, the gas price bid parameter does not affect the order in which transactions get processed.\nWhere can I find the current Data Availability Committee members?\nThe Arbitrum Nova chain has a 7-party DAC, whose members can be seen in the Arbitrum Foundation's state of progressive decentralization status document. Governance has the ability to remove or add members to the committee.\nCan I withdraw my funds from Arbitrum back to Ethereum without going through the Sequencer? What about funds that are in a contract?\nYes, it is possible to send a message from Ethereum to be executed on Arbitrum permissionlessly, while bypassing the Sequencer. You can achieve this by using the DelayedInbox contract and forcing the inclusion of the message after a certain amount of time has passed (currently ~24 hours). For more information about this behavior, refer to How Arbitrum Works.\nKeep in mind that you can execute any message in this way, be it a withdrawal of funds back to Ethereum or a call to a contract.\nYou can also find an example of force-inclusion in this tutorial.\nAre there any plans to reduce the time a transaction needs to wait before being able to be force-included from Ethereum into the Arbitrum chain, bypassing the sequencer? (Currently 24 hours)\nThe mechanism that allows force-including transactions from Ethereum (bypassing the sequencer) is intended to be used in very rare cases, especially when it is expected that the sequencer will not be operational again, so that users have a way of interacting with Arbitrum in a trustless way.\nWhen using this mechanism, if the sequencer is down for longer than the time window for force-including transactions from Ethereum, the moment it is online again, it can lead to a reorganization of blocks in Arbitrum (it would have received transactions timestamped before the force-included one).\n24 hours was chosen because it provides a comfortable period of time for the team running the sequencer infrastructure to fix any bugs that may cause the sequencer to not work. While there aren't any active initiatives to lower that time, the decision ultimately falls in the hands of the Arbitrum DAO, who has discussed the topic in their governance forum (see here for more information).\nIn any case, we could also analyze why would someone use this mechanism having an honest and functional sequencer. For instance, if the reason is a distrust of the sequencer, a centralised agent as of now, one potential solution could be to decentralize the sequencer instead of reducing the force-inclusion delay time.\nWhat is the difference between an child chain block and an assertion?\nA child chain block is very similar to the concept of an parent chain block. These blocks are generated by validator nodes of Arbitrum by executing the state transition function on sequenced transactions. The structure of a child chain block is similar to that of an Ethereum block, with a few differences that you can see here.\nOn the other hand, an assertion is a distinctive block that is transmitted back to the parent chain to serve as a fingerprint of the most recent state of the Arbitrum chain. It comprises an assertion of the present state root of the Arbitrum chain and other essential information pertaining to withdrawals and challenges. The structure of assertions can be viewed here.\nThese assertions are also generated by validators, but they are appended to the parent chain. Other validators can challenge them during a specific time frame of approximately one week if they discover that the current state hash of the chain varies from the one that was initially claimed. Once the challenge period elapses, the assertion is confirmed on the parent chain.\nWhy do Arbitrum chains enforce a target (for pricing)? Isn't it better that the target grows without limits?\nThe transaction lifecycle sets a target that we have to take into account: validators have to execute each transaction, get the status of the chain, and post an assertion to Ethereum every certain amount of time. If the target of the chain increases too much, there is a risk that validators won't have enough computation power to process all transactions in a timely manner, and will fall behind on validating them, which would cause the chain to delay confirmations of its state.How is this guide?ContributeLearn how to contribute to Arbitrum's open-source documentation.Audit reportsA comprehensive list of security audits conducted on Arbitrum protocol components, including Nitro, BoLD, Stylus, and related smart contracts.","tokens":3354,"squid":"spider-01","role":"Chain Spider","at":1791338787669,"hash":"a731943fe1acd1f9dab8e2982100f55c7f3c99bf"}
{"url":"https://docs.phantom.com/sdks/react-sdk","domain":"docs.phantom.com","title":"Phantom React SDK - Phantom developer documentation","text":"The Phantom Connect React SDK provides React hooks for connecting to existing Phantom user wallets in your React apps with native transaction support across multiple blockchains.\n​Quick start\nGenerate a new Solana project using the Phantom Embedded React Starter template.\n npm pnpm yarn bunnpx -y create-solana-dapp@latest -t solana-foundation/templates/community/phantom-embedded-react\npnpm create solana-dapp@latest -t solana-foundation/templates/community/phantom-embedded-react\nyarn create solana-dapp -t solana-foundation/templates/community/phantom-embedded-react\nbun create solana-dapp@latest -t solana-foundation/templates/community/phantom-embedded-react\n\nRun the command above in your terminal to get started.\nView template on Solana Templates →\n\n​Features\n\nBuilt for React: Provides React hooks (usePhantom, useModal) and a provider component for app-level configuration.\nMulti-chain support: Solana and Ethereum with dedicated hooks.\nConnection modal: Built-in, customizable modal for connecting users to Phantom.\nFlexible authentication providers: OAuth (Google, Apple) and the Phantom browser extension.\nUser wallet integration: Connects to existing Phantom user wallets using Phantom Connect.\nTypeScript support: Fully typed API surface.\n\n​Security\nThe Phantom Connect React SDK connects to existing Phantom user wallets, ensuring:\n\nUsers control their own wallets and private keys.\nIntegration with Phantom’s secure wallet infrastructure.\nNo private key handling in your application.\nUser maintains full control of their assets.\n\n​Prerequisites\nPhantom Portal is not accepting new applications at this time. New sign-ups for Phantom Connect SDK access and new app submissions to the Phantom app directory are paused. Existing Portal apps and App IDs are not affected.\n\nUse an existing app: Sign in to the Phantom Portal and select your app.\nObtain your App ID:\n\nIn Phantom Portal, expand your app in the left navigation, then select Set Up.\nYour App ID appears at the top of the page.\n\nAllowlist your domains and redirect URLs: Add your app’s domains and redirect URLs in the Phantom Portal to enable wallet connections.\n\n​Authentication configuration\nWhen using OAuth providers (google, apple), you’ll need to configure authentication options:\nauthOptions: {\n redirectUrl: \"https://yourapp.com/auth/callback\", // Your callback page\n}\n\nImportant notes about redirectUrl:\n\nMust be an existing page/route in your application\nMust be whitelisted in your Phantom Portal app configuration\nThis is where users will be redirected after completing OAuth authentication\nRequired for google and apple providers\nNot required for injected provider\n\n​Installation\nnpm install @phantom/react-sdk\n\n​Dependencies\nInstall additional dependencies based on the networks you want to support:\nNetwork supportRequired dependenciesSolana@solana/web3.js OR @solana/kitEthereum/EVMviem\nExample for Solana and Ethereum support:\nnpm install @phantom/react-sdk @solana/web3.js viem\n\n​Quick start\nimport { PhantomProvider, useModal, darkTheme, usePhantom } from \"@phantom/react-sdk\";\nimport { AddressType } from \"@phantom/browser-sdk\";\n\nfunction App() {\n return (\n <PhantomProvider\n config={{\n providers: [\"google\", \"apple\", \"injected\"], // Enabled auth methods\n appId: \"your-app-id\", // Get your app ID from phantom.com/portal\n addressTypes: [AddressType.solana, AddressType.ethereum],\n authOptions: {\n redirectUrl: \"https://yourapp.com/auth/callback\", // Must be whitelisted in Phantom Portal\n },\n }}\n theme={darkTheme}\n appIcon=\"https://your-app.com/icon.png\"\n appName=\"Your App Name\"\n >\n <WalletComponent />\n </PhantomProvider>\n );\n}\n\nfunction WalletComponent() {\n const { open, close, isOpened } = useModal();\n const { isConnected, user } = usePhantom();\n\n if (isConnected) {\n return (\n <div>\n <p>Connected</p>\n </div>\n );\n }\n\n return <button onClick={open}>Connect Wallet</button>;\n}\n\n​Connection Modal\nThe SDK includes a built-in connection modal UI that provides a user-friendly interface for connecting to Phantom. The modal supports multiple connection methods (Google, Apple, browser extension) and handles all connection logic automatically.\n​Using the Modal with useModal Hook\nTo use the modal, pass a theme prop to PhantomProvider and use the useModal() hook to control visibility:\nimport { PhantomProvider, useModal, darkTheme, usePhantom } from \"@phantom/react-sdk\";\nimport { AddressType } from \"@phantom/browser-sdk\";\n\nfunction App() {\n return (\n <PhantomProvider\n config={{\n providers: [\"google\", \"apple\", \"injected\"],\n appId: \"your-app-id\",\n addressTypes: [AddressType.solana, AddressType.ethereum],\n }}\n theme={darkTheme} // or lightTheme, or custom theme object\n appIcon=\"https://your-app.com/icon.png\"\n appName=\"Your App Name\"\n >\n <WalletComponent />\n </PhantomProvider>\n );\n}\n\nfunction WalletComponent() {\n const { open, close, isOpened } = useModal();\n const { isConnected } = usePhantom();\n\n if (isConnected) {\n return (\n <div>\n <p>Connected</p>\n </div>\n );\n }\n\n return <button onClick={open}>Connect Wallet</button>;\n}\n\nModal features:\n\nMultiple auth providers: Google, Apple, browser extension\nAutomatic provider detection: Shows browser extension option when Phantom is installed\nError handling: Clear error messages displayed in the modal\nLoading states: Visual feedback during connection attempts\nResponsive design: Optimized for both mobile and desktop\n\n​ConnectButton Component\nA ready-to-use button component that handles the complete connection flow:\nimport { ConnectButton, AddressType } from \"@phantom/react-sdk\";\n\nfunction Header() {\n return (\n <div>\n {/* Default: Shows first available address */}\n <ConnectButton />\n\n {/* Show specific address type */}\n <ConnectButton addressType={AddressType.solana} />\n <ConnectButton addressType={AddressType.ethereum} />\n\n {/* Full width button */}\n <ConnectButton fullWidth />\n </div>\n );\n}\n\nConnectButton features:\n\nWhen disconnected: Opens connection modal with auth provider options\nWhen connected: Displays truncated address and opens wallet management modal\nUses theme styling for consistent appearance\n\n​ConnectBox component\nAn inline embedded component that displays the connection UI directly in your page layout (without a modal backdrop). Perfect for auth callback pages or when you want a more integrated connection experience. The component automatically handles all connection states including loading, error, and success during the auth callback flow.\n\nimport { ConnectBox } from \"@phantom/react-sdk\";\n\nfunction AuthCallbackPage() {\n return (\n <div>\n <h1>Connecting to Phantom...</h1>\n <ConnectBox />\n </div>\n );\n}\n\nProps:\nPropertyTypeDefaultDescriptionmaxWidthstring | number\"350px\"Maximum width of the boxtransparentbooleanfalseRemoves background, border, and shadow for a transparent appearanceappIconstring—URL to your app icon (optional, can also be set via PhantomProvider)appNamestring—Your app name (optional, can also be set via PhantomProvider)\nUsage Examples:\nimport { ConnectBox } from \"@phantom/react-sdk\";\n\n// Default usage\n<ConnectBox />\n\n// Custom width\n<ConnectBox maxWidth=\"500px\" />\n\n// Transparent (no background/border)\n<ConnectBox transparent />\n\n// Custom width with transparent\n<ConnectBox maxWidth={600} transparent />\n\nConnectBox Features:\n\nInline embedded: Renders directly in page flow (not as a floating modal)\nAuto state management: Automatically shows connection/login UI when disconnected, wallet info when connected\nAuth callback support: Handles loading and error states during OAuth callback flows\nNo close button: Designed for embedded use cases where users shouldn’t dismiss the UI\nTheme-aware: Uses your configured theme for consistent styling\n\nUse ConnectBox for auth callback pages: When using OAuth providers (Google, Apple), users are redirected to your callback URL after authentication. Place ConnectBox on this page to automatically handle the auth flow completion with proper loading and error states.\n​Theming\nThe SDK includes pre-built themes and supports full customization to match your app’s design.\n​Pre-built themes\nUse the included darkTheme or lightTheme:\nimport { PhantomProvider, darkTheme, lightTheme } from \"@phantom/react-sdk\";\n\n// Dark theme\n<PhantomProvider config={config} theme={darkTheme} appIcon=\"...\" appName=\"...\">\n <App />\n</PhantomProvider>\n\n// Light theme\n<PhantomProvider config={config} theme={lightTheme} appIcon=\"...\" appName=\"...\">\n <App />\n</PhantomProvider>\n\n​Custom themes\nCreate a custom theme object to fully control the modal’s appearance:\nconst customTheme = {\n background: \"#1a1a1a\", // Background color for modal\n text: \"#ffffff\", // Primary text color\n secondary: \"#98979C\", // Secondary color for text, borders, dividers\n brand: \"#ab9ff2\", // Brand/primary action color\n error: \"#ff4444\", // Error state color\n success: \"#00ff00\", // Success state color\n borderRadius: \"16px\", // Border radius for buttons and modal\n overlay: \"rgba(0, 0, 0, 0.8)\", // Overlay background color (with opacity)\n};\n\n<PhantomProvider config={config} theme={customTheme} appIcon=\"...\" appName=\"...\">\n <App />\n</PhantomProvider>\n\nPropertyDescriptionExamplebackgroundModal background color\"#1a1a1a\"textPrimary text color\"#ffffff\"secondarySecondary text, borders, and dividers\"#98979C\"brandBrand/primary action color\"#ab9ff2\"errorError state color\"#ff4444\"successSuccess state color\"#00ff00\"borderRadiusBorder radius for buttons and modal\"16px\"overlayModal overlay background (supports opacity)\"rgba(0, 0, 0, 0.8)\"\nThe secondary color must be a hex color value (for example, #98979C) as it’s used to derive auxiliary colors with opacity.\n​Chain-Specific Hooks\nThe React SDK provides dedicated hooks for each blockchain:\n​useSolana hook\nimport { useSolana } from \"@phantom/react-sdk\";\n\nfunction SolanaOperations() {\n const { solana, isAvailable } = useSolana();\n\n // Check if Solana is available before using it\n if (!isAvailable) {\n return <div>Solana is not available for the current wallet</div>;\n }\n\n const signMessage = async () => {\n const signature = await solana.signMessage(\"Hello Solana!\");\n console.log(\"Signature:\", signature);\n };\n\n const signAndSendTransaction = async () => {\n const result = await solana.signAndSendTransaction(transaction);\n console.log(\"Transaction sent:\", result.hash);\n };\n\n const switchNetwork = async () => {\n await solana.switchNetwork('devnet');\n };\n\n return (\n <div>\n <button onClick={signMessage}>Sign Message</button>\n <button onClick={signAndSendTransaction}>Send Transaction</button>\n <button onClick={switchNetwork}>Switch to Devnet</button>\n <p>Connected: {solana.isConnected ? 'Yes' : 'No'}</p>\n </div>\n );\n}\n\n​useEthereum hook\nEVM support for Phantom Connect embedded wallets will go live later in 2026.\nimport { useEthereum } from \"@phantom/react-sdk\";\n\nfunction EthereumOperations() {\n const { ethereum, isAvailable } = useEthereum();\n\n // Check if Ethereum is available before using it\n if (!isAvailable) {\n return <div>Ethereum is not available for the current wallet</div>;\n }\n\n const signPersonalMessage = async () => {\n const accounts = await ethereum.getAccounts();\n const signature = await ethereum.signPersonalMessage(\"Hello Ethereum!\", accounts[0]);\n console.log(\"Signature:\", signature);\n };\n\n const sendTransaction = async () => {\n const result = await ethereum.sendTransaction({\n to: \"0x742d35Cc6634C0532925a3b8D4C8db86fB5C4A7E\",\n value: \"1000000000000000000\", // 1 ETH in wei\n gas: \"21000\",\n });\n console.log(\"Transaction sent:\", result.hash);\n };\n\n const switchChain = async () => {\n await ethereum.switchChain(137); // Switch to Polygon\n };\n\n return (\n <div>\n <button onClick={signPersonalMessage}>Sign Personal Message</button>\n <button onClick={sendTransaction}>Send Transaction</button>\n <button onClick={switchChain}>Switch to Polygon</button>\n <p>Connected: {ethereum.isConnected ? 'Yes' : 'No'}</p>\n </div>\n );\n}\n\nMonad support has been deprecated.\nSupported EVM Networks:\nNetworkChain IDUsageEthereum Mainnet1ethereum.switchChain(1)Ethereum Sepolia11155111ethereum.switchChain(11155111)Polygon Mainnet137ethereum.switchChain(137)Polygon Amoy80002ethereum.switchChain(80002)Base Mainnet8453ethereum.switchChain(8453)Base Sepolia84532ethereum.switchChain(84532)Arbitrum One42161ethereum.switchChain(42161)Arbitrum Sepolia421614ethereum.switchChain(421614)Monad Mainnet (Deprecated)143ethereum.switchChain(143)Monad Testnet (Deprecated)10143ethereum.switchChain(10143)\n​Auto-Confirm Hook (Injected Provider Only)\nThe SDK provides auto-confirm functionality that allows automatic transaction confirmation for specified chains.\n​useAutoConfirm hook\nimport { useAutoConfirm, NetworkId } from \"@phantom/react-sdk\";\n\nfunction AutoConfirmControls() {\n const {\n enable,\n disable, \n status,\n supportedChains,\n isLoading,\n error,\n } = useAutoConfirm();\n\n const handleEnable = async () => {\n // Enable auto-confirm for specific chains\n const result = await enable({\n chains: [NetworkId.SOLANA_DEVNET, NetworkId.ETHEREUM_MAINNET]\n });\n console.log(\"Auto-confirm enabled:\", result);\n };\n\n const handleDisable = async () => {\n await disable();\n console.log(\"Auto-confirm disabled\");\n };\n\n return (\n <div>\n <p>Status: {status?.enabled ? \"Enabled\" : \"Disabled\"}</p>\n <button onClick={handleEnable} disabled={isLoading}>\n Enable Auto-Confirm\n </button>\n <button onClick={handleDisable} disabled={isLoading}>\n Disable Auto-Confirm\n </button>\n </div>\n );\n}\n\n​Wallet Discovery Hook\n​useDiscoveredWallets\nGet discovered injected wallets with automatic loading and error states. Discovers wallets using Wallet Standard (Solana) and EIP-6963 (Ethereum) standards.\nimport { useDiscoveredWallets } from \"@phantom/react-sdk\";\n\nfunction WalletSelector() {\n const { wallets, isLoading, error, refetch } = useDiscoveredWallets();\n\n if (isLoading) {\n return <div>Discovering wallets...</div>;\n }\n\n if (error) {\n return <div>Error discovering wallets: {error.message}</div>;\n }\n\n return (\n <div>\n <h3>Available Wallets</h3>\n {wallets.map((wallet) => (\n <div key={wallet.id}>\n <img src={wallet.icon} alt={wallet.name} width={24} />\n <span>{wallet.name}</span>\n </div>\n ))}\n <button onClick={refetch}>Refresh</button>\n </div>\n );\n}\n\nReturns:\nPropertyTypeDescriptionwalletsInjectedWalletInfo[]Array of discovered wallet informationisLoadingbooleantrue while discovery is in progresserrorError | nullError object if discovery failsrefetch() => Promise<void>Function to manually refresh the wallet list\n​SDK Initialization\nThe SDK provides an isLoading state to track when initialization and autoconnect are in progress:\nimport { useConnect, usePhantom } from \"@phantom/react-sdk\";\n\nfunction App() {\n const { isLoading } = usePhantom();\n const { connect } = useConnect();\n\n // Show loading state while SDK initializes\n if (isLoading) {\n return (\n <div>\n <h1>Initializing Phantom SDK...</h1>\n <p>Please wait...</p>\n </div>\n );\n }\n\n // SDK is ready\n return (\n <div>\n <h1>Welcome!</h1>\n <button onClick={() => connect({ provider: \"injected\" })}>\n Connect Wallet\n </button>\n </div>\n );\n}\n\n​Debug Configuration\nConfigure debug logging by passing a debugConfig prop to PhantomProvider:\nimport { PhantomProvider, DebugLevel } from \"@phantom/react-sdk\";\n\nfunction App() {\n const [debugMessages, setDebugMessages] = useState([]);\n\n const debugConfig = {\n enabled: true,\n level: DebugLevel.INFO,\n callback: (message) => {\n setDebugMessages((prev) => [...prev, message]);\n },\n };\n\n return (\n <PhantomProvider config={config} debugConfig={debugConfig}>\n <YourApp />\n </PhantomProvider>\n );\n}\n\nDebug configuration properties:\nPropertyTypeDescriptionenabledbooleanEnable debug logginglevelDebugLevelDebug level (ERROR, WARN, INFO, DEBUG)callback(message: DebugMessage) => voidCustom debug message handler\n​Available hooks\nHookPurposeReturnsuseModalControl the connection modal{ open, close, isOpened }usePhantomAccess wallet/user state{ isConnected, isLoading, user, wallet }useConnectConnect to wallet{ connect, isConnecting, isLoading, error }useAccountsGet wallet addressesWalletAddress[] or nulluseIsExtensionInstalledCheck extension status{ isLoading, isInstalled }useDisconnectDisconnect from wallet{ disconnect, isDisconnecting }useAutoConfirmAuto-confirm management (injected only){ enable, disable, status, supportedChains, ... }useDiscoveredWalletsGet discovered injected wallets{ wallets, isLoading, error, refetch }useSolanaSolana chain operations{ solana, isAvailable }useEthereumEthereum chain operations{ ethereum, isAvailable }useThemeAccess current themePhantomTheme\n​What you can do\n\n​Starter kits and examples\nGet started quickly with production-ready React templates:\n\n​Additional resources\nWas this page helpful?","tokens":4149,"squid":"spider-10","role":"Tooling Spider","at":1791338788345,"hash":"cdf15579200869ba56a4d333cfb363edbb8ff1ab"}
{"url":"https://forum.arbitrum.foundation/t/arbitrum-proposals-app-govhack-brussels-winner/25370","domain":"forum.arbitrum.foundation","title":"Arbitrum Proposals App (GovHack Brussels Winner) - Archive / Archived Proposals - Arbitrum","text":"The Arbitrum Foundation notified the Security Council on the need to perform a potential Emergency action. Following a review of the details and known risks, the Security Council decided to execute the upgrade and it was completed at 11:30 EST on 2nd October 2026.\nThis report provides an overview of the risks that required the Security Council Action:\n\nAdd a permissionless guard for the One-Step Proof of BoLD on Arbitrum One\n\nTemporarily pause activation of new Stylus contracts on Arbitrum One & Nova\n\nKey point: To date, known bugs for Stylus primarily impact chain liveness (e.g., denial of service attacks) and do not put any user funds at risk.\nWhy was this action taken\nLet’s take this opportunity to explain why action was taken on two separate issues concerning BoLD and Stylus.\nInstalling the guard for One-Step Proof of BoLD. Given the rise of AI-assisted attacks, we have implemented a precautionary approach that allows anyone to pause settlement of Arbitrum One on Ethereum if there are at least two conflicting answers that pass at the same level in which only one should be valid and pass. This is to halt a class of publicly verifiable and detectable attacks that exploit a bug in the one-step proof. If halted, Arbitrum One will continue to process as normal except that messages from Arbitrum One to Ethereum, such as withdrawals, that are not yet confirmed will have to wait. This provides time for the Security Council to deploy a fix for the bug and resume the rollup.\nPreventing activation of new Stylus contracts. AI-assisted tooling has led to an increasing number of sophisticated attacks on hand-crafted WASM programs that do not use the standard Stylus compiler toolchain. These programs are specifically designed to cause unexpected behaviors such as degrading the chain’s performance for all other users. To date, no attacks have been discovered that permits theft of user funds.\nNew ArbOS releases have patched several reported bugs and known attacks over the past few months, but out of an abundance of caution, we have decided to temporarily pause new activations of Stylus contracts. This was executed as an emergency action to prevent the deployment of new hand-crafted WASM programs that are not yet patched by the current version of ArbOS on the Arbitrum network.\nThe Arbitrum Foundation has informed the Security Council that they will work with the ArbitrumDAO to discuss next steps on the timeline and manner for enabling activation of new Stylus contracts. The Arbitrum community remains confident in the value of Stylus and want to preserve these use cases while taking preventative measures against Stylus-based attack vectors as AI-assisted attack tooling continues to evolve.\nImpact on builders and users\n\nNo new activations. New Stylus contracts cannot be activated during the pause including new versions of existing applications that require activation.\n\nExisting contracts are not paused. Already-active Stylus contracts continue to execute until expiration. This pause does not deactivate them.\n\nThe ArbOS 61 upgrade renewed all active contracts on Arbitrum One, so no currently active contract expires before August 20, 2027.\n\nRenewal via keepalive stays permissionless and is unaffected by the pause.\n\nReactivating an expired contract, or one that needs to be updated after a Stylus version change, is paused.\n\nUsing/calling any activated Stylus contract stays permissionless for all users and developers.\n\nNo impact on EVM. Solidity (EVM) contract deployment and execution are unaffected by this Security Council action.\n\nSecurity Council Actions\nThere are two actions bundled into a single payload:\n\nOne-Step Proof Guard. The L1UpgradeExecutor gives a new pause contract (PauseExecutor) the ability to pause and nothing else. The new pause contract grants the guard (OspSoundnessGuard) PAUSER_ROLE to use it. Anyone can show the guard two conflicting answers to the same step of an open challenge. If the one-step proof accepts both, the guard has the pause contract put Arbitrum One’s settlement to Ethereum on hold.\n\nStylus deactivation. The Security Council called ArbOwner.setWasmActivationGas(2^64 - 1) to raise the Stylus activation gas requirement on Arbitrum One and Nova. This makes activation prohibitively expensive and effectively disables new activations. This is a configuration change and does not require an ArbOS upgrade.\n\nThe Security Council signed the following transactions to update the configuration:\n\nEthereum: Ethereum Transaction Hash: 0x30732bb7d2... | Etherscan\nArbitrum One:\nArbitrum One Transaction Hash: 0x9eb3a4be3b... | Arbitrum One\nArbitrum Nova:\nArbitrum Nova transaction 0x79e0fed470dff7a22059b108e3f8f42eddd2b580a6771594060c4e7326c5f984 | Blockscout\n\nAn external audit was conducted for the OSP Guard contracts. No audit is required for the Stylus deactivation as it is only updating a single parameter in the ArbOS configuration.\n\n Arbitrum Proposals App (GovHack Brussels Winner) \n\n ArchiveArchived Proposals\n\n proposal,governance,delegation,proposal-discussions\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jul 2024\n\n 1 / 36\n\n Jul 2024\n\n May 2025\n\n post by paulofonseca on Jul 6, 2024\n\n paulofonseca\n\nWe just got a smaller questbook grant approved to build this same scope of functionality over the next 4 months for a total of 43,000.00 USD. We will use this thread to record the progress of it and to report on the project milestones. Thank you all for your feedback along the way \n\nArbitrum Proposals App\nNon-Constitutional\nChallenge Statement:\nRight now, DAO delegates want to understand proposals efficiently and accurately, but proposal information is scattered all over the place (tweets, Discord servers, Telegram chats, discourse posts, offchain proposals [on snapshot], onchain proposals [on tally], etc.). This is a serious issue because it leads to unnecessary friction and inaccessibility in governance participation and, ultimately, poor decision-making for the Arbitrum DAO.\nTrack Name at GovHack Brussels: GovTech\nTeam Number at GovHack Brussels: 16\nMembers: andreiv.eth + paulofonseca.eth\nTeam Lead: Paulo Fonseca – @paulofonseca1987 on Telegram or @paulofonseca__ on Twitter\n2 minute Pitch: Posted on Youtube\nLow Fidelity Design Prototype: (this is unfinished and in-progress work, since it was started during the GovHack itself) arbitrum.proposals.app\nAbstract\nTo fund the design and development of an Arbitrum-focused responsive web app that shows all Arbitrum proposals across different stages in their lifecycle and aggregates information from Discourse, Snapshot, and the Arbitrum Onchain Governor contracts so that voters and delegates can more efficiently and accurately understand the context and the whole lifecycle of each proposal they should be voting on.\nMotivation\nThe current governance state-of-the-art is quite messy. This is not just an Arbitrum DAO problem but it affects Arbitrum DAO governance quite a lot. Still to this day, most governance processes in most big DAOs are spread across multiple platforms and systems, from messaging apps like Discord, Telegram and Twitter, to Discourse forums, to offchain voting platforms like Snapshot and then to onchain voting front-ends like Tally.\nIn each of these platforms, delegates need to keep themselves up to date, review information about proposals coming to vote in the DAO and form their opinions about whether they should support a particular proposal. Delegates are also expected to actively share their concerns and provide feedback on proposals throughout the lifecycle of a proposal so that the proposal can advance through the several stages of the governance process successfully.\nFor a delegate, even to the most competent ones, to keep up with all of this information scattered around different sources is… overwhelming, to say the least. \nAs an example, this is roughly what happens when a delegate (or anybody else for that matter) tries to understand the context and form an opinion about an important Arbitrum proposal like the Gaming Catalyst Program that just recently passed.\n\nFull video can be seen here.\nIf we expect more and better delegates to keep up with governance proposals adequately, we should invest in appropriate tooling to make their jobs much easier than they currently are.\nRationale\nThis proposal aligns with Arbitrum’s mission and community values by making the Arbitrum DAO more innovative, open, accessible, and inclusive to delegates and voters by allowing them another choice as users of Arbitrum’s DAO governance.\nMore specifically, the last community value in The Amended Constitution of the Arbitrum DAO, but to us, one of the most important community values, the one of attempting to be:\n\nNeutral and open: Arbitrum governance should not pick winners and losers, but should foster open innovation, interoperation, user choice, and healthy competition on Arbitrum chains.\n\nWe know Tally has a great partnership with the Arbitrum DAO, and we are grateful for all the work the Tally team has done over more than a year to support the governance of Arbitrum DAO. We support their developments and future roadmap and are open to collaborating in any way to improve the user experience of delegates and voters in their day-to-day.\nWe also believe it is important for the Arbitrum DAO not to be vendor-locked in. More specifically, on the front end it offers its delegates and voters that allows them to participate in Arbitrum DAO’s onchain governance.\nWe believe there should be multiple front-ends to Arbitrum DAO’s onchain governance, so that we can attract more and better delegates and voters by providing them tools that suit their particular needs.\nWe also strongly believe that at least one of those front-ends should be fully open-source. For the obvious matters of the resilience of Arbitrum’s DAO governance, we believe there should be a fully open-source front-end for Arbitrum’s DAO on-chain governance that would allow delegates and voters to continue to participate in governance permissionlessly. proposals.app is fully open source and will continue to be. proposals.app and its future developments can also be self-hosted by anyone (like we’re doing now) under a new domain name, at any time.\nSpecifications\nHow might we enable DAO delegates, to get a more complete picture of how a proposal has evolved and what other people think about it, so that they can make a more informed voting decision, resulting in higher quality governance outcomes for the DAO?\nThis guiding question and a bunch of conversations and user research with DAO Delegates both in GovHack and previously when we were building Senate, has led us to believe that there is a need for a unified view of a canonical DAO proposal page that covers the whole proposal lifecycle, or at the very least, from the “initial Discourse forum post” stage to the “onchain execution” stage, obviously including temperature check poll on Snapshot, and onchain voting.\nAt proposals.app we already fetch Arbitrum’s DAO offchain and onchain proposals, and we also offer free email notifications to anybody that subscribes on the site. Everytime there is a new Arbitrum DAO proposal available, delegates and voters that have subscribed to proposals.app notifications, will get a fresh email in their inbox that looks like this.\n\nCurrently, we are linking each offchain or onchain proposal to their respective Snapshot.org or Tally.xyz links so delegates and voters can easily exercise their governance rights.\nWith this project we will build a Unified Proposal Lifecycle page, that merges the information of offchain and onchain votes for the same proposal, so that delegates and voters can have easier access to all of the information of a proposal in a single place.\nThis Unified Proposal Lifecycle page will show information from the proposal’s Discourse post, from the Snapshot temperature check poll, and from the onchain vote.\nThe challenge to be able to achieve this is to include all relevant information in the right way, at the right time, so delegates and voters don’t feel overwhelmed by it.\nWe’ve been mapping the proposal elements across several platforms and feel confident we have a model that captures a proposal standard that is able to show the proposal lifecycle and how the proposal has evolved, and that will help delegates and voters get more transparency into the journey of a proposal and the context it’s current or final state.\n\nWe will need to also manually map the discourse posts to the Snapshot polls and then to the onchain votes. Which is something that is not trivial to do for all past Arbitrum DAO’s proposals, but we will create a backoffice where a governance analyst can links all data sources of a proposal, to be shown in the Unified Proposal Lifecycle page.\nSteps to Implement\nWe have a 2 part plan for this project:\n\nDesign and Develop V1 of the Unified Proposal Lifecycle Page, which will include data and the mapping between Snapshot proposal data and Onchain proposal data.\nDesign and Develop the V2 of the Unified Proposal Lifecycle Page that would add Discourse Post data.\n\nAlongside this main plan, we need to create a mechanism to map discourse posts to Snapshot polls and then to onchain votes, so that eventually that mapping doesn’t need to be done manually for every proposal.\nWe are talking to @amanwithwings to move forward a daoURI standard in the Arbitrum DAO that could be extended so that Arbitrum DAO onchain proposals would include the link to their Discourse post in the onchain proposal metadata.\nOnce that standard would be adopted by the Arbitrum DAO, we would be able to automate the mapping of data for a single proposal. Until then, we will do it manually and very deliberately. \nTimeline\nWe will deliver the complete solution described above within a maximum of four months of the project’s kick-off.\nThe project kick-off is on October 15th, 2024, and we commit to deliver the completed project with all it’s Milestones and deliverables by February 14th, 2025.\nMilestone #1\nDeadline: 30 days after project kick-off\nDeliverables: Create the back-end discourse indexing system and mapping backoffice to map discourse data to snapshot and onchain proposals + Setup of self-hosted infrastructure with a real-time status page monitoring\nMilestone #2\nDeadline: 60 days after project kick-off, 30 days after Milestone #1\nDeliverables: Interactive Design Prototype Deliverable\nMilestone #3\nDeadline: 90 days after project kick-off, 30 days after Milestone #2\nDeliverables: Development of a responsive Unified Proposal Lifecycle webpage\nMilestone #4\nDeadline: 120 days after project kick-off, 30 days after Milestone #3\nDeliverables: Testing, Quality Assurance and Data Validation of all past proposals data\nAfter completing the project, we commit to maintaining and ensuring the resilient hosting of the web app for at least 24 months from the project kick-off date.\nOverall Cost\nThe overall cost for this 4 month long project totals $43,000 USD\n\nMonthly Amount\nDuration\nTotal Amount\n\nDesigner\n$5,000 USD\n3 months\n$15,000 USD\n\nDeveloper\n$5,000 USD\n3 months\n$15,000 USD\n\nGovernance Analyst\n$1,000 USD\n1 month\n$1,000 USD\n\nServers and Hosting\n$500 USD\n24 months\n$12,000 USD\n\nDuring these four months, we will ship 4 deliverables, the first at Milestone #1 at the 30 day mark, the second at Milestone #2 at the 60 day mark, the third at Milestone #3 at the 90 day mark and the fourth at Milestone #4 at the 120 day mark.\nThe kick-off stage marks the beginning of the project after a successful acceptance of the questbook grant.\nWe believe in performance-based compensation, so we will only be compensated upon value delivery after successfully delivering each of the Milestones.\nPayment schedule\n\nKick-off\nMilestone #1\nMilestone #2\nMilestone #3\nMilestone #4\n\nDeadline\nDay 1\nDay 30\nDay 60\nDay 90\nDay 120\n\nPayment\n$0 USD\n$10,000 USD\n$15,000 USD\n$15,000 USD\n$3,000 USD\n\nFor the multisig, we will use a Gnosis Safe multisig on Arbitrum One which has andreiv.eth and paulofonseca.eth as signers. From that multisig, all contributors and expenses will be paid at our discretion, but still fully transparently and, of course, onchain. \n\nThank you for reading this proposal until the end, and please give us your honest and harshest feedback. We know we need it, and we truly welcome it! \nAlso, special thanks to @DisruptionJoe, @hiringdevs.eth, @cliffton.eth, @JoJo and anybody else who provided valuable feedback on this proposal during GovHack Brussels and afterwards!\n\n 16 Jul 2024 - Open Discussion of Proposals Governance Call\n\n Paulo Fonseca – Voluntary Earnings Disclosure Thread\n\n GovHack ETHcc Brussels 2024 - Impact Report - Hack Humanity\n\n Improving Predictability in Arbitrum DAO’s Operations\n\n [Election & Application Thread] Arbitrum D.A.O. (Domain Allocator Offerings) Grant Program\n\n 21\n\n 2\n\n 2\n\n 2\n\n read \n\n 10\n min\n\n post by andreiv on Jul 7, 2024\n\n andreiv\n\n Excited to share our team’s proposal! We believe this initiative will address a significant pain point in DAO governance by consolidating fragmented proposal information into a unified, open source and resilient platform.\nLet’s make governance more accessible and effective together!\n\n GovHack ETHcc Brussels 2024 - Impact Report - Hack Humanity\n\n post by ismailemin on Jul 7, 2024\n\n ismailemin\n\nimage1920×1110 83.8 KB\nFigma shows its edited 7 days ago idk if it’s bug or something but are you sure about it was done in govhack?\n\n post by paulofonseca on Jul 7, 2024\n\n paulofonseca\n\n thank you for the diligence @ismailemin =)\nI’m not really sure why the figma prototype embed component says 7 days ago… This file exists for months now… but this part of the file however, with the prototype for the Unified Proposal Lifecycle page proposal, was created last night… actually I was just editing it before I saw your comment.\nYou can see the whole file here, and you can also comment on it, with your feedback: https://www.figma.com/design/8c9gLo0ICTAhGMatRi3qU4/proposals.app?node-id=595-6626&t=Ou27vVDWLrRTvoTl-1\nAnd as you can see from the figma file version history, this 2 frames were made from July 6th at 9:13AM (Brussels time I guess?) to today, July 7th, at 1:18PM\n\n post by dennison on Jul 7, 2024\n\n dennison\n\n Great job folks! Really feel the pain of having to track everything from everywhere.\nVendor lock in is also real and something that bothers me despite being CEO of Tally.xyz. I’d love to see a world where Arbitrum owned it’s instance of Tally so that it wasn’t vendor lock in at all.\nIn the meantime, I think initiatives like this are super important!\n\n post by paulofonseca on Jul 7, 2024\n\n paulofonseca\n\n thank you for the public support @dennison \nit means a lot coming from you!\n\n post by emjicy on Jul 7, 2024\n\n emjicy\n\n andreiv\n\n Congrats all, solid progress against real pain-points; hoping to see this come alive soon!\n\n post by paulofonseca on Jul 8, 2024\n\n paulofonseca\n\n thank you @emjicy =) it will come alive soon!\n\n post by paulofonseca on Jul 11, 2024\n\n paulofonseca\n\n Just did a livestream figuring out the information architecture for a aggregated proposal lifecycle page, that would show the info of a proposal from the discourse forum, to the snapshot temp check poll, to the onchain vote.\nI mapped the pages from Tally, Aragon (old and new), and Snapshot, to have a diversity of inputs in this work so that I can understand what different product have deemed important when presenting the information of a DAO proposal.\nYou can browse and comment in the FigJam file that I created during this session, and if you have the patience for it, you can also watch the 3 hour long live stream (it was my first ever =).\n\n What is a DAO Proposal? Information Architecture Session\n\nI’ll do a following session soon.\n\n post by Bau on Jul 12, 2024\n\n Bau\n\n Hey Paulo and team,\nJust wanted to say awesome job on the Arbitrum Proposals App. The idea of consolidating governance info in a nicely formatted and clean way for delegates to navigate is super important. Also, the plan to map the proposal lifecycle and make everything accessible in one place is spot on.\nWe’re close to releasing something similar at Open Dollar, apparently great minds think alike! We just teased it on our Twitter: x.com\nLooking forward to seeing your project in action. Keep up the great work!\n\n post by paulofonseca on Jul 12, 2024\n\n paulofonseca\n\n @Bau thank you for the support! =) the fork feature you are doing is… chef’s kiss! =)\n\n 8 days later\n\n post by paulofonseca on Jul 21, 2024\n\n paulofonseca\n\n Hello all!\nI just updated this proposal with a few more details.\nWe want to have this proposal on temperature check on Snapshop next Tuesday July 23rd.\nPlease provide your feedback soon!\nThank you!\n\n post by paulofonseca on Jul 22, 2024\n\n paulofonseca\n\n Updated the proposal with new timelines, we are now aiming to get this proposal into temperature check vote on Snapshot next Thursday, 25th of July.\n\n post by jameskbh on Jul 22, 2024\n\n jameskbh\n\n Hello!\nJust a heads-up: Now we will start to follow a new schedule, with the first batch of snapshot votes targeted for August 1st. Tagging @Entropy for visibility\n\n post by paulofonseca on Jul 22, 2024\n\n paulofonseca\n\n Hey @jameskbh!\nThank you for the heads up!\nThis latest update resulted from a conversation with @Pruitt from Entropy where we basically realized that pushing this proposal to snapshot on August 1st would delay this proposal a little bit too much as we want to have some feedback from the DAO as a temperature check as soon as possible, aka, this week. This proposal has been on the forum for more than 2 weeks now, so we think is reasonable to have it pushed to snapshot this week.\n\n post by jameskbh on Jul 23, 2024\n\n jameskbh\n\n Hello! Thanks for your proposal.\nIt is a detailed presentation, I really liked the demo and I believe it is a useful tool. As this problem is not new, others are also trying to solve it. Can you highlight, for the sake of comparison, what differentiate your tool from syncvote, for example, so we can select yours instead of going through an RFP or something similar?\n\n post by paulofonseca on Jul 24, 2024\n\n paulofonseca\n\n Hey @jameskbh thank you for reading it through!\nSo, we don’t really think proposals.app is comparable to syncvote for example, but maybe more similar to lighthouse.cx or goverland.xyz, although both of these apps don’t show data for onchain proposals, and only show snapshot polls.\nCurrently, on proposals.app you can get daily email notifications for Arbitrum DAO offchain and onchain proposals, and also a custom email notification for when an onchain proposal is about to end and hasn’t met quorum yet. And if you add proposals.app as a shortcut app on your phone home screen, you will also get push notifications whenever there is a new proposal.\nAlso, proposals.app is the only platform of this kind, as far as we are aware, that is fully open-source, and therefor, if something were to happen to our team where we wouldn’t be able to maintain or continue the work on proposals.app, anybody else in the world could continue it, by forking our github repo and deploying their own instance. We believe this to be our fundamental difference, comparing to other players, since this forces us to work in the open and constantly designing and developing better functionality to support delegates and voters. This also makes our position to be more similar to a public good, and not a VC backed startup that needs to find a way to return value to their investors.\nThat’s why we believe that communities like Arbitrum DAO should fund our work, and that’s why we put forward this specific proposal.\nMoving forward, what we are aiming for with this proposal is to design and develop a dedicated functionality for the Arbitrum DAO, that will live on arbitrum.proposals.app, that will aggregate the data for the whole lifecycle of every single Arbitrum DAO proposal, from the discussion in the forum, to the onchain execution. For this to be done successfully, it requires a mapping between forum post X, snapshot poll Y, and onchain proposal Z, that we will be doing retroactively for all past Arbitrum DAO proposals, and make sure to develop a system that can do that mapping for future Arbitrum DAO proposals as well.\nIf you have any further questions, please reach out!\nThank you once again for taking the time to go through our proposal!\n\n post by paulofonseca on Jul 24, 2024\n\n paulofonseca\n\n After a couple conversations with some delegates we are now aiming to post this proposal to snapshop next week, August 1st. For the next few days, we will be having conversations with delegates to get their feedback on this proposal.\nIf you want to get on a call, to talk about this proposal, please book here: cal.com/paulofonseca/sync\n\n Improving Predictability in Arbitrum DAO’s Operations\n\n post by Tane on Jul 30, 2024\n\n Tane\n\n Thanks for the proposal @paulofonseca and congrats to the winning at GovHack Brussels!\n\nYou incorporated the hosting cost for 3 years, but what do you think about additional requirements and/or code upgrades based on external circumstances?\n\n post by paulofonseca on Jul 31, 2024\n\n paulofonseca\n\n Thank you for your question @Tane and thank you for taking the time and care to read our proposal! =)\nSo answering your question, other than the hosting costs to keep the servers up and running, the overall maintenance that would be needed for the next 3 years, is if Arbitrum governance contracts change somehow and therefor we would need to update our indexers accordingly. For starters, that’s not very likely to happen, but if it does, we commit to update our app as soon as possible, because since we send daily notifications emails to our users, we need to have the correct data for the that next day email to be accurate.\nAlso, just as a reminder, our app is fully open-source on GitHub - proposals-app/proposalsapp\nThank you!\n\n Load more posts below","tokens":6488,"squid":"spider-07","role":"Council Spider","at":1791338796269,"hash":"678b556face36a19a01adf98e96640d590eddc35"}
{"url":"https://docs.phantom.com/sdks/react-native-sdk/connect","domain":"docs.phantom.com","title":"Connect - Phantom developer documentation","text":"The Phantom Connect React Native SDK provides hooks for connecting users with OAuth authentication and secure key handling.\nLearn about Phantom Connect: For details about authentication flows, login, account selection, and session management, see the Phantom Connect guide.\n​Using the Connect modal (recommended)\nThe SDK includes a built-in bottom sheet Connect modal that handles sign-in and wallet connection. Use the useModal() hook to open it:\nimport React from \"react\";\nimport { View, Button, Text } from \"react-native\";\nimport { useModal, useAccounts } from \"@phantom/react-native-sdk\";\n\nfunction WalletScreen() {\n const modal = useModal();\n const { isConnected, addresses } = useAccounts();\n\n if (!isConnected) {\n return (\n <View style={{ padding: 20 }}>\n <Button title=\"Connect Wallet\" onPress={() => modal.open()} />\n </View>\n );\n }\n\n return (\n <View style={{ padding: 20 }}>\n <Text style={{ fontSize: 18, marginBottom: 10 }}>Wallet Connected</Text>\n {addresses.map((addr, index) => (\n <Text key={index}>\n {addr.addressType}: {addr.address}\n </Text>\n ))}\n <Button title=\"Manage Wallet\" onPress={() => modal.open()} />\n </View>\n );\n}\n\nModal features:\n\nSign-in with Google and Apple\nBuilt-in error handling and loading states\nWorks across devices and environments\nHandles the full connection flow and returns a ready-to-use wallet session\nPresented as a bottom sheet optimized for mobile interaction\n\n​useConnect hook (manual connection)\nimport React from \"react\";\nimport { View, Button, Alert } from \"react-native\";\nimport { useConnect } from \"@phantom/react-native-sdk\";\n\nfunction ConnectButton() {\n const { connect, isConnecting, error } = useConnect();\n\n const handleConnect = async () => {\n try {\n const result = await connect({ provider: \"google\" });\n Alert.alert(\"Success\", \"Wallet connected!\");\n console.log(\"Connection successful:\", result);\n } catch (error) {\n Alert.alert(\"Error\", `Failed to connect: ${error.message}`);\n }\n };\n\n return (\n <View>\n <Button\n title={isConnecting ? \"Connecting...\" : \"Connect Phantom\"}\n onPress={handleConnect}\n disabled={isConnecting}\n />\n {error && (\n <Text style={{ color: \"red\", marginTop: 10 }}>\n Error: {error.message}\n </Text>\n )}\n </View>\n );\n}\n\n​Authentication providers\nThe React Native SDK supports Google and Apple OAuth providers. React Native uses system browser authentication (Safari on iOS, Chrome Custom Tab on Android) to complete the sign-in flow.\nThe connect() method accepts a provider parameter to specify how users should authenticate. Available providers are configured in the PhantomProvider config:\nimport { PhantomProvider, AddressType } from \"@phantom/react-native-sdk\";\n\n<PhantomProvider\n config={{\n providers: [\"google\", \"apple\"], // Specify enabled providers\n appId: \"your-app-id\",\n scheme: \"myapp\",\n addressTypes: [AddressType.solana],\n }}\n>\n <App />\n</PhantomProvider>\n\nThen use the connect() method with one of the enabled providers:\nconst { connect } = useConnect();\n\n// Connect with specific provider\nawait connect({ provider: \"google\" }); // Google OAuth\nawait connect({ provider: \"apple\" }); // Apple ID\n\n​Checking connection status\nUse the useAccounts hook to check if a wallet is already connected:\nimport React from \"react\";\nimport { View, Text, Button } from \"react-native\";\nimport { useConnect, useAccounts } from \"@phantom/react-native-sdk\";\n\nfunction WalletStatus() {\n const { connect } = useConnect();\n const { addresses, isConnected, walletId } = useAccounts();\n\n if (isConnected && addresses) {\n return (\n <View style={{ padding: 20 }}>\n <Text style={{ fontSize: 18, marginBottom: 10 }}>Connected to Phantom</Text>\n <Text>Wallet ID: {walletId}</Text>\n {addresses.map((account, index) => (\n <Text key={index} style={{ marginTop: 5 }}>\n {account.addressType}: {account.address}\n </Text>\n ))}\n </View>\n );\n }\n\n return (\n <View style={{ padding: 20 }}>\n <Button\n title=\"Connect Phantom\"\n onPress={() => connect({ provider: \"google\" })}\n />\n </View>\n );\n}\n\n​Handling connection errors\nWhen a connection fails, the connect() promise rejects with an error.\nimport React from \"react\";\nimport { View, Button, Alert, Text } from \"react-native\";\nimport { useConnect } from \"@phantom/react-native-sdk\";\n\nfunction ConnectButton() {\n const { connect, isConnecting, error } = useConnect();\n\n const handleConnect = async () => {\n try {\n const result = await connect({ provider: \"google\" });\n // Connection successful\n Alert.alert(\"Success\", \"Wallet connected!\");\n console.log(\"Connection successful:\", result);\n } catch (error) {\n // Connection failed (user cancelled, network error, etc)\n Alert.alert(\"Error\", `Failed to connect: ${error.message}`);\n }\n };\n\n return (\n <View>\n <Button\n title={isConnecting ? \"Connecting...\" : \"Connect Phantom\"}\n onPress={handleConnect}\n disabled={isConnecting}\n />\n {error && (\n <Text style={{ color: \"red\", marginTop: 10 }}>\n Error: {error.message}\n </Text>\n )}\n </View>\n );\n}\nWas this page helpful?","tokens":1229,"squid":"spider-10","role":"Tooling Spider","at":1791338798248,"hash":"d00edb402707798378b8f9b02b2d4656a0db5315"}
{"url":"https://docs.phantom.com/sdks/react-sdk/sign-and-send-transaction","domain":"docs.phantom.com","title":"Sign and send transactions - Phantom developer documentation","text":"The React SDK provides chain-specific hooks (useSolana and useEthereum) for signing and sending transactions with optimal blockchain-specific handling.\nEmbedded wallet limitations: The signTransaction and signAllTransactions methods aren’t supported for embedded wallets. For embedded wallets, use only signAndSendTransaction that signs and broadcasts the transaction in a single step.\nTransaction security for embedded wallets: All transactions signed for embedded wallets pass through Phantom’s advanced simulation system before execution. This security layer automatically blocks malicious transactions and transactions from origins that have been reported as malicious, providing an additional layer of protection for your users’ assets.\n​Chain-specific transaction hooks\n​Solana transactions (useSolana)\nimport { useSolana } from \"@phantom/react-sdk\";\n\nfunction SolanaTransactions() {\n const { solana } = useSolana();\n\n const sendTransaction = async () => {\n // Sign and send transaction\n const result = await solana.signAndSendTransaction(transaction);\n console.log(\"Transaction sent:\", result.hash);\n };\n\n const signOnly = async () => {\n // Just sign (without sending) - Note: Not supported for embedded wallets\n const signedTx = await solana.signTransaction(transaction);\n console.log(\"Signed transaction:\", signedTx);\n };\n\n return (\n <div>\n <button onClick={sendTransaction}>Send Transaction</button>\n <button onClick={signOnly}>Sign Only</button>\n </div>\n );\n}\n\n​Ethereum transactions (useEthereum)\nimport { useEthereum } from \"@phantom/react-sdk\";\n\nfunction EthereumTransactions() {\n const { ethereum } = useEthereum();\n\n const sendTransaction = async () => {\n const result = await ethereum.sendTransaction({\n to: \"0x742d35Cc6634C0532925a3b8D4C8db86fB5C4A7E\",\n value: \"1000000000000000000\", // 1 ETH in wei\n gas: \"21000\",\n });\n console.log(\"Transaction sent:\", result.hash);\n };\n\n return (\n <button onClick={sendTransaction}>Send ETH</button>\n );\n}\n\n​Dapp-sponsored transactions\nPass a presignTransaction callback to signAndSendTransaction for Solana transactions that need double signing, such as dapp fee payer flows. Calls without it proceed normally — it is never applied globally.\nPhantom embedded wallets do not accept pre-signed transactions. If your use case requires a second signer (for example, your app as the fee payer), that signing must happen via this callback, after Phantom has constructed and validated the transaction. This restriction does not apply to injected providers (Phantom browser extension).\npresignTransaction only fires for Solana transactions via the embedded provider. EVM transactions and injected providers are unaffected.\nimport { useSolana, base64urlDecode, base64urlEncode } from \"@phantom/react-sdk\";\n\nfunction SendWithFeeSponsor() {\n const { solana } = useSolana();\n\n const sendSponsored = async () => {\n const result = await solana.signAndSendTransaction(transaction, {\n presignTransaction: async (tx, context) => {\n // Send the transaction to your backend for fee payer signing\n const response = await fetch(\"/api/presign\", {\n method: \"POST\",\n body: JSON.stringify({ transaction: tx, networkId: context.networkId }),\n headers: { \"Content-Type\": \"application/json\" },\n });\n const { transaction: signedTx } = await response.json();\n return signedTx; // base64url-encoded, partially signed by the fee payer\n },\n });\n console.log(\"Sponsored transaction sent:\", result.hash);\n };\n\n const sendNormal = async () => {\n const result = await solana.signAndSendTransaction(transaction);\n console.log(\"Normal transaction sent:\", result.hash);\n };\n\n return (\n <div>\n <button onClick={sendSponsored}>Send (Dapp Pays Fees)</button>\n <button onClick={sendNormal}>Send (User Pays Fees)</button>\n </div>\n );\n}\n\nNever hold a fee payer keypair in frontend code. The presignTransaction callback runs in the browser — use it to call your own backend, which holds the keypair securely and returns the partially-signed transaction.\n​Transaction examples\n​Solana with @solana/web3.js\nimport { VersionedTransaction, TransactionMessage, SystemProgram, PublicKey, Connection } from \"@solana/web3.js\";\nimport { useSolana } from \"@phantom/react-sdk\";\n\nfunction SolanaExample() {\n const { solana } = useSolana();\n\n const sendTransaction = async () => {\n // Get recent blockhash\n const connection = new Connection(\"https://api.mainnet-beta.solana.com\");\n const { blockhash } = await connection.getLatestBlockhash();\n\n // Create transfer instruction\n const fromAddress = await solana.getPublicKey();\n const transferInstruction = SystemProgram.transfer({\n fromPubkey: new PublicKey(fromAddress),\n toPubkey: new PublicKey(toAddress),\n lamports: 1000000, // 0.001 SOL\n });\n\n // Create VersionedTransaction\n const messageV0 = new TransactionMessage({\n payerKey: new PublicKey(fromAddress),\n recentBlockhash: blockhash,\n instructions: [transferInstruction],\n }).compileToV0Message();\n\n const transaction = new VersionedTransaction(messageV0);\n\n // Sign and send using chain-specific hook\n const result = await solana.signAndSendTransaction(transaction);\n console.log(\"Transaction sent:\", result.hash);\n };\n\n return <button onClick={sendTransaction}>Send SOL</button>;\n}\n\n​Solana with @solana/kit\nimport {\n createSolanaRpc,\n pipe,\n createTransactionMessage,\n setTransactionMessageFeePayer,\n setTransactionMessageLifetimeUsingBlockhash,\n address,\n compileTransaction,\n} from \"@solana/kit\";\nimport { useSolana } from \"@phantom/react-sdk\";\n\nfunction SolanaKitExample() {\n const { solana } = useSolana();\n\n const sendTransaction = async () => {\n const rpc = createSolanaRpc(\"https://api.mainnet-beta.solana.com\");\n const { value: latestBlockhash } = await rpc.getLatestBlockhash().send();\n\n const userPublicKey = await solana.getPublicKey();\n const transactionMessage = pipe(\n createTransactionMessage({ version: 0 }),\n tx => setTransactionMessageFeePayer(address(userPublicKey), tx),\n tx => setTransactionMessageLifetimeUsingBlockhash(latestBlockhash, tx),\n );\n\n const transaction = compileTransaction(transactionMessage);\n\n // Sign and send using chain-specific hook\n const result = await solana.signAndSendTransaction(transaction);\n console.log(\"Transaction sent:\", result.hash);\n };\n\n return <button onClick={sendTransaction}>Send SOL</button>;\n}\n\n​Dapp-sponsored transactions\nBy default, the user’s embedded wallet is the fee payer for all Solana transactions. The presignTransaction hook lets your app co-sign the transaction before the wallet signs it, enabling use cases like:\n\nDapp-as-fee-payer — your app covers the transaction fee so users don’t need SOL\nPlatform fees — add a fee instruction signed by your app’s keypair\nMulti-signer flows — any scenario where the app needs to sign alongside the user’s wallet\n\nPhantom embedded wallets do not accept pre-signed transactions. If your use case requires a second signer, this hook is the only supported approach — your app’s signing must happen after Phantom has constructed and validated the transaction. This restriction does not apply to injected providers (e.g. the Phantom browser extension).\nPass presignTransaction directly to signAndSendTransaction for the specific calls that need it. Calls without it proceed normally — the function is never applied globally.\n​Example: app as fee payer\nimport { useSolana, base64urlDecode, base64urlEncode } from \"@phantom/react-sdk\";\nimport { Keypair, VersionedTransaction } from \"@solana/web3.js\";\n\n// Your app's fee payer keypair (keep this on your backend in production)\nconst feePayerKeypair = Keypair.fromSecretKey(/* your fee payer secret key */);\n\nfunction SendWithFeeSponsor() {\n const { solana } = useSolana();\n\n const sendSponsored = async () => {\n const result = await solana.signAndSendTransaction(transaction, {\n presignTransaction: async (tx, context) => {\n // tx: base64url-encoded Solana transaction bytes\n // context: { networkId: string, walletId: string }\n\n // 1. Decode base64url → raw bytes\n const txBytes = base64urlDecode(tx);\n\n // 2. Deserialize\n const versionedTx = VersionedTransaction.deserialize(txBytes);\n\n // 3. Partially sign as fee payer — the user's wallet will sign next\n versionedTx.sign([feePayerKeypair]);\n\n // 4. Re-serialize → encode back to base64url\n return base64urlEncode(versionedTx.serialize());\n },\n });\n console.log(\"Transaction sent:\", result.signature);\n };\n\n // This call has no presignTransaction — proceeds without any co-signing\n const sendNormal = async () => {\n const result = await solana.signAndSendTransaction(transaction);\n console.log(\"Transaction sent:\", result.signature);\n };\n}\n\nThe hook only fires for Solana transactions via the embedded provider. EVM transactions and injected providers are unaffected.\n​Ethereum with viem\nimport { parseEther, parseGwei, encodeFunctionData } from \"viem\";\nimport { useEthereum } from \"@phantom/react-sdk\";\n\nfunction EthereumExample() {\n const { ethereum } = useEthereum();\n\n const sendEth = async () => {\n const result = await ethereum.sendTransaction({\n to: \"0x742d35Cc6634C0532925a3b8D4C8db86fB5C4A7E\",\n value: parseEther(\"1\").toString(), // 1 ETH\n gas: \"21000\",\n gasPrice: parseGwei(\"20\").toString(), // 20 gwei\n });\n console.log(\"ETH sent:\", result.hash);\n };\n\n const sendToken = async () => {\n const result = await ethereum.sendTransaction({\n to: tokenContractAddress,\n data: encodeFunctionData({\n abi: erc20Abi,\n functionName: \"transfer\",\n args: [recipientAddress, parseEther(\"100\")],\n }),\n gas: \"50000\",\n maxFeePerGas: parseGwei(\"30\").toString(),\n maxPriorityFeePerGas: parseGwei(\"2\").toString(),\n });\n console.log(\"Token sent:\", result.hash);\n };\n\n return (\n <div>\n <button onClick={sendEth}>Send ETH</button>\n <button onClick={sendToken}>Send Token</button>\n </div>\n );\n}\nWas this page helpful?","tokens":2430,"squid":"spider-10","role":"Tooling Spider","at":1791338811194,"hash":"dcae6e56bcf28ab365f601ca788ed1d745204a2f"}
{"url":"https://developers.jup.ag/docs/resources/security","domain":"developers.jup.ag","title":"Security - Jupiter Developers","text":"Jupiter welcomes reports from security researchers. If you find a vulnerability in Jupiter’s onchain programs, APIs, or web infrastructure, report it to security@jup.ag rather than disclosing it publicly.\n​Scope\nReports fall into two scopes:\n\nWeb3: Jupiter’s onchain programs and protocol infrastructure\nWeb2: web applications, APIs, and supporting infrastructure\n\nFocus on vulnerabilities that materially threaten user funds, protocol solvency, governance integrity, or user data. Theoretical issues and deviations from best practice are out of scope.\nGood-faith research conducted in line with these guidelines is not subject to legal action.\n​Reporting a vulnerability\n\nEmail security@jup.ag with reproduction steps and an impact assessment.\nDo not disclose the vulnerability publicly until the report is resolved.\n\n​Related\n\nAudits: formal audit reports for Jupiter programs\nSupport: developer support channels for non-security issues\nWas this page helpful?","tokens":240,"squid":"spider-02","role":"Liquidity Spider","at":1791338820407,"hash":"42381c1b19e787c940a39808b9f84d4d35b321ac"}
{"url":"https://consensysdiligence.github.io/smart-contract-best-practices/attacks/","domain":"consensysdiligence.github.io","title":"Index - Ethereum Smart Contract Best Practices","text":"Index\n\nTip\nSeeking more detailed information on smart contract attacks? The Smart Contract Security Field Guide offers an extensive range of attack strategies with in-depth explanations on vulnerabilities, including new code samples for a hands-on learning experience. Enhance your understanding and stay ahead of potential threats by visiting this continuously updated resource.\n\nThe following is a list of known attacks which you should be aware of, and defend against when\nwriting smart contracts.\n\nCategory\nDescription\n\nReentrancy\nIntra- and inter-function reentrancy attacks and potentially faulty solutions to them.\n\nOracle Manipulation\nManipulation of external data providers and potential solutions to oracle security issues.\n\nFrontrunning\nA definition and taxonomy around frontrunning and related attacks.\n\nTimestamp Dependence\nAttacks relating to the timing of a transaction.\n\nInsecure Arithmetic\nInteger overflows and underflows.\n\nDenial of Service\nDenial of service attacks through unexpected reverts and the block gas limit.\n\nGriefing\nAttacks relating to bad faith players around a smart contract system.\n\nForce Feeding\nForcing Ether to be sent to smart contracts to manipulate balance checks.\n\nDeprecated/Historical\nAttacks that are part of Ethereum's history and vulnerabilities that have been fixes on a (Solidity) compiler level.\n\nMore\nWhere to find more information about vulnerabilities and weaknesses.","tokens":355,"squid":"spider-06","role":"Security Spider","at":1791338821597,"hash":"93d2eeeb954e42c93f5042b0c0beb1411e37bf41"}
{"url":"https://console.akash.network/terms-of-service","domain":"console.akash.network","title":"Terms of service | Akash Console","text":"Akash Network Terms of ServiceLast updated: July 1st, 2025These Akash Network Terms of Service (these \"Terms\" or this \"Agreement\") are a contract between you and Overclock Labs Inc. (\"Akash,\" \"we,\" \"our,\" or \"us\") and govern your access to and use of the website located at https://akash.network (the \"Website\") and the application interface located at https://console.akash.network/ and all related components (the \"Platform\"), services provided by Akash described below, and such other services, software, applications, features, or products provided by Akash from time to time (together with the Platform, the \"Services\").By accessing or using any portion of the Services, or, if earlier, by clicking on an \"I Agree\" button or a check box presented with these Terms, you agree to comply with and be bound by these Terms and any materials expressly incorporated herein. If you do not agree, you are not authorized to access or use any of the Services and may not use the Services.THESE TERMS INCLUDE A WAIVER OF ANY RIGHT TO PARTICIPATE IN A CLASS ACTION, AS WELL AS A MANDATORY ARBITRATION CLAUSE THAT GOVERNS RESOLUTION OF CERTAIN DISPUTES AND WAIVES YOUR RIGHT TO SUE IN COURT OR HAVE A TRIAL BY JURY. PLEASE READ SECTION 21 CAREFULLY.Important Definitions: As used throughout this Agreement, the following terms have the following meanings.\"Digital Asset\" means any cryptographic digital representation of value that functions as a medium of exchange, unit of account, or store of value compatible with a blockchain protocol of a computer network.\"Digital Asset Address\" means the alphanumeric identifier that represents a destination for a Digital Asset transaction.\"Digital Asset Wallet\" means a software application or other mechanism that provides a means for holding, storing, transferring, and receiving Digital Assets.\"Person\" means, without limitation, any natural person, individual, association, partnership, corporation, company, or other form of organization, group, or entity.\"Prohibited Jurisdictions\" means, any Person that is a citizen or resident or, or is located or headquartered in a jurisdiction where use of the Services would be illegal or violate applicable law.\"Sanctions Law\" means, without limitation, any export restriction, end-user restriction, antiterrorism law, anti-money laundering law, economic sanction, financial sanction, and trade embargo imposed, administered, or enforced by the U.S. including the U.S. Department of Treasury's Office of Foreign Asset Control Designated Nationals and Blocked Persons (\"SDN\") List, U.S. Department of State, and U.S. Department of Commerce, the United Nations Security Council, the European Union, or any other applicable national, regional, provincial, state, municipal, or local law or regulation (each as amended from time to time).\"Sanctioned Person\" means, without limitation, any Person or Digital Asset Address that is subject to any Sanctions Law, or directly or indirectly owned fifty percent or more by any Person or group of Persons in the aggregate, or a Digital Asset Wallet associated with such Person or Persons, subject to any Sanctions Law.\"Sanctioned Jurisdiction\" means, without limitation, any jurisdiction comprehensively sanctioned or embargoed by the United States, the United Nations, the United Kingdom, or Panama, which, as of the date that these Terms were last updated: Cuba, certain sanctioned areas of Russia and Ukraine (including without limitation, Crimea, the so-called region of Dontesk, the so-called region of Luhansk, and the so-called region of Zaporizzhia), Democratic People's Republic of Korea (North Korea), Iran, and Syria.1. The Services1.1 The PlatformThe Platform publishes information about computing infrastructure resources, such as access to virtual machines, Kubbernetes clusters, GPU/TPU instances, memory, storage, and other compute resources (\"Resources\") provided by third-party providers, which may or may not include Akash (\"Providers\"), and made available through the Protocol (as defined below). Subject to these Terms, users may access and use the Platform to lease Resources from Providers (such users, \"Tenants\"). Tenants may use the Platform to publish a request for Resources. A Provider that desires to fulfill the Tenant's request may submit a bid to fulfill such request on the Platform. After some time, the requesting Tenant may select which, if any, Provider bid that satisfies the Tenant's request. Any terms and provisions about or in connection with the Resources, including without limitation, technical support, are between the Tenant and the Vendor. Akash will not be responsible or liable for any Resources, including without limitation, technical support, security updates, or patches.1.2 The ProtocolThe Platform provides a web-based means to access the Akash network software protocol that runs on the Akash blockchain, a public blockchain network hosted by a network of unaffiliated third-party node operators whose nodes host the Akash blockchain's distributed ledger and validate and facilitate Digital Asset transactions performed thereon (the \"Protocol\"). The Protocol enables users to perform transactions with Digital Assets compatible with the underlying blockchain network. The Platform is distinct from the Protocol. The Platform is one but not the exclusive means of accessing the Protocol. The Protocol itself is comprised of open-source or source-available self-executing smart contracts and hosted by a network of unaffiliated third-party node operators whose nodes run the Protocol's software and host the Akash blockchain network. You acknowledge and agree that we do not control the Protocol or any Digital Assets compatible with the Protocol and we do not have control over any Digital Asset transactions conducted on the Protocol. You also acknowledge and agree that your interactions, including Digital Asset transactions, are not interactions with us. You further understand and agree that we do not operate, own, or control the Protocol's staking mechanism or governance mechanism, nor do we control trade execution on the Protocol.2. Using the Services2.1 EligibilityIn connection with your access and use of the Services, you represent and warrant that you are at least 18 years old and capable of forming a binding contract with Akash in your respective jurisdiction. If you are accessing or using the Services on behalf of a legal entity or other type of organization, you represent and warrant that you are authorized to agree to these Terms on behalf of that entity or organization and represent to Akash that you have the power and authority to bind your legal entity or organization to these Terms. You further represent and warrant that you are not, and you are not acting on behalf of, a \"Prohibited Person,\" which means a: (i) Sanctioned Person; or (ii) Person that is a resident of or headquartered in a Sanctioned Jurisdiction or a Prohibited Jurisdiction.2.2 Verification and ScreeningYou may be required to provide us directly, or through a third party, certain information and documentation. You represent and warrant that any information and documentation that you provide to us, whether as part of the Services or otherwise, is complete and accurate. We may employ various measures to comply with our anti-money laundering obligations and otherwise prevent the misuse of the Services. These verification and screening procedures may include, without limitation, checking the information you provide against sanctions lists issued by any governmental authority prohibiting or limiting business activities or transactions with any Person. You hereby authorize us, directly or through a third party, to make inquires that we consider necessary to verify your identity and/or protect against the misuse of the Services. We will have no liability or responsibility for any permanent or temporary inability to access or use the Services as a result of any identity verification or screening procedure.2.3 User AccountsYou represent and warrant that all information you submit when you create your account is accurate, current, and complete, and that you will keep your account information accurate, current, and complete. You are solely responsible for any and all activity that occurs on your account, whether authorized by you or not, and you must keep your account information secure. You are responsible for keeping your account information up to date, including the information that allows you to receive any notices or alerts that we may send you. In case of a dispute about account ownership, we reserve the right to determine ownership to an account based on our reasonable judgment and/or our independent investigation. However, if we cannot make such a determination, we reserve the right to avoid doing so and/or suspend a user's account until the parties disputing such ownership, reach a resolution.3. Digital Asset Wallets3.1 In GeneralTo pay for the Services using Digital Assets, you must connect a Digital Asset Wallet. Your relationship with the Digital Asset Wallet provider is governed by the terms and provisions of that provider's agreement with you. By connecting your Digital Asset Wallet to the Platform, you agree to be bound by this Agreement. We reserve the right, in our sole discretion, to prohibit certain Digital Asset Addresses from being able to connect to the Platform or from accessing or using other aspects of the Services.3.2 Non-CustodialThe Services are purely non-custodial applications, we do not have custody, possession, or control of your Digital Assets at any time. You own and control all Digital Assets held in your Digital Asset Wallet. As the owner of the Digital Assets, you bear all risk of loss of the Digital Assets. Akash will not be liable for Digital Asset fluctuations or other loss associated with your use of a Digital Asset Wallet.3.3 SecurityYou are solely responsible for the custody of the cryptographic private keys associated with any Digital Asset Wallet you use or connect to the Services. You should never share your Digital Asset Wallet's credentials or seed phrase with anyone. We accept no responsibility or liability to you in connection with your use of a Digital Asset Wallet. We make no representations or warranties regarding how any of the Services will interact or operate with any specific Digital Asset Wallet.4. Third Party Services, Applications, and Waiver4.1 Third Party ServicesThe Services may include, without limitation, links to sites, technology, applications, products, services, materials, or resources, provided or made available by, third a third party, including for example, Stripe (collectively, \"Third Party Services\"). Your access and use of any Third Party Service is subject to the terms and policies of the applicable Third Party Service provider, including without limitation, Stripe's Connected Account Agreement, available at https://stripe.com/legal/connect account the Stripe Terms of Service, available at https://stripe.com/legal/ssa and the Stripe Shop Terms of Use, available at https://stripe.com/legal/stipe-shop.We do not control or operate any Third Party Services. You acknowledge and agree that you are solely responsible for any and all costs and charges associated with your use of any Third Party Service. Our integration or inclusion of any Third Party Service does not imply endorsement or recommendation. You acknowledge and agree that we are not responsible for the availability, reliability, accuracy, or legitimacy of any Third Party Service (including any related websites, resources or links displayed therein). Any dispute you have with a Third Party Service including, without limitation, your intellectual property rights, is between you and the provider of that Third Party Service. Akash will not be responsible or liable for any damage or loss caused or alleged to be caused by, or in connection with, your use of, or reliance on, any Third Party Service.4.2 Third Party ApplicationsIf, to the extent permitted by Akash, you grant express permission to a third party to access or connect to the Services, either through a third party's service or the Platform, you acknowledge that granting permission to such third party to take specific actions on your behalf does not relieve you of any of your responsibilities under these Terms. You are fully responsible for any act or omission of any such third party. You acknowledge and agree that you will not hold Akash responsible for, and will indemnify Akash from, any liability arising out of or related to any act or omission of any third party with access to your Digital Asset Wallet, application, software, or other mechanism that you use to interact with the Services.4.3 Waiver of ClaimsTo the maximum extent permitted by applicable law, you hereby waive any and all claims, demands, and damages of every kind or nature, known or unknown, suspected or unsuspected, disclosed or undisclosed, against Akash and its affiliates, and each of their respective officers, employees, agents, and successors arising out of or in any way related to any of the risks set forth herein. You also waive application of Section 1542 of the Civil Code of the State of California, or any similar stature or law of any other jurisdiction. Section 1542 reads as follows: \"a general release does not extend to claims which the creditor does not know or suspect to exist in his or her favor at the time of executing the release, which if known by him or her must have materially affected his or her settlement with the debtor.\"5. Risk DisclosuresYou understand, accept, and agree to assume all of the various risks involved in using, holding, transacting, and transferring Digital Assets and the use of the Services, including all of the risks set forth in this Section.Digital Assets, the features, functions, characteristics, operations, use, and other properties and/or software, networks, protocols, systems, or other technology that Digital Assets interact with is complex, and Digital Asset terms, features, or risks may not be readily or fully understood due to such complexities.Digital Assets will be irretrievably lost if sent to the wrong Digital Asset Address. For instance, if the Digital Asset Address is improperly formatted, contains an error, or for a type of Digital Asset then is not supported by the Digital Asset Address' underlying blockchain, then any Digital Assets will be irretrievably lost. Neither Akash nor any other third party is capable of reversing erroneous Digital Asset transfers or retrieving any lost Digital Assets transferred in error.The Protocol may be subject to forks or attacks on the security, integrity, and/or operation of the networks, including any network events. These events may affect features, functionality, operations, use, or properties of the Services and/or any Digital Asset or network and/or the value of any Digital Asset.Any Digital Asset, the Protocol, or the Services may be targeted by malicious persons or individuals who may attempt to disrupt the Services or steal Digital Assets. This includes but is not limited to malware, hacking, phishing, double spending, smurfing, spoofing, sybil attacks, social engineering, majority mining, mining attacks, distributed denial of service, and blockchain forks.The public nature of the internet means that parts or the internet may be unreliable or unavailable at any given time. Interruption, delay, corruption, loss of data, the loss of confidentiality or privacy through the course of data transmission, or malware transmission may occur when transmitting data via the internet or other technology. This can result in your transaction(s) not being executed according to your instructions at the requested time or not at all. No technology is completely secure or safe.Digital Assets may decrease in value or lose all value in a short period of time or permanently due to various factors including, without limitation, government or regulatory activity, the discovery of wrongful or illegal conduct, market manipulation, price distortion, insider dealing, market distortion, malicious wrongdoing or behaviors, changes to the Digital Asset's nature or characteristics, suspension, or cessation of support for a Digital Asset by exchanges, public opinion, technical advancements, macroeconomic and political factors, and other factors outside of our control.Digital Assets held by a decentralized application like the Protocol or Digital Asset Wallets are not protected deposits and/or may not be protected by any deposit protection scheme, such as the Federal Deposit Insurance Company (\"FDIC\"). Thus, Digital Assets have a reduced level and type of protection compared to fiat currency and other asset classes or types.Digital Assets are generally considered a high-risk asset class. You must exercise prudent judgment when with transacting with Digital Assets.The Services may undergo significant changes over time. We may also limit control over how other participants use the Services and what Services are offered on or through the Platform. This could create the risk of the Services not meeting your expectations, for any number of reasons, including mistaken assumptions or analysis, a change in the design and/or implementation plans, and execution on or through the Services.We currently rely on our service providers for certain aspects of our operations including: cloud computing services and data centers that provide facilities, infrastructure, website functionality and access, components, and services, all of which are critical to our operations. Like most other online companies, because we rely on service providers, we face operational risk. Any interruption in the services provided by our service providers can impair our ability to provide the Services to you.We do not directly manage the operation of the service providers we use including their data center facilities. Such third parties are vulnerable to financial, legal, regulatory, and labor issues, cybersecurity incidents, break-ins, computer viruses, denial-of-service attacks, sabotage, acts of vandalism, privacy breaches, service terminations, disruptions, interruptions, Force Majeure Events (defined below), and other events.You acknowledge and understand that you may be subject to scams and/or other types of fraud perpetrated by parties outside of our control. It is your responsibility to be aware of and protect against such misconduct. In the event that you are subject to such fraud, there is a risk of loss of your Digital Assets.All blockchain transactions include data and, in some circumstances, personal data about you. Many public blockchain networks, including the Protocol, store transaction data publicly and permanently. When you use such public blockchain networks, you intentionally make your transaction data public and acknowledge that this data cannot be deleted, removed, or reversed due to the nature of blockchain technology.We are subject to an extensive and rapidly evolving regulatory landscape, and any changes to any law or regulation could adversely impact our ability to offer the Services and/or your use or access to the Services. Such regulatory change may also impact your legal obligations with respect to your use of the Services.You understand that smart contract transactions automatically execute and settle, and blockchain-based transactions are irreversible when confirmed. You acknowledge and accept that the cost and speed of transacting with cryptographic and blockchain-based systems are variable and may increase dramatically at any time. You further acknowledge and accept the risk of selecting your slippage rate which expose you to additional cost or fees by the underlying blockchain network.You understand that we do not create, own, or operate cross-chain bridges and we do not make any representation or warranty about the safety or soundness of any cross-chain bridge.6. Acknowledgements and CovenantsBy accessing or using the Services, you acknowledge, represent, and warrant, in each case as applicable, each of the items contained in this Section and all of its subsections.6.1 Acknowledgement and Assumption of RisksYou represent and warrant that you have received a copy of, have carefully read, understand, accept, and agree to assume all of the risks involved in using, holding, trading, delivering, transacting, and/or transferring Digital Assets and the use of the Services, including without limitation, the risks specifically set forth in these Terms. You agree that Akash shall not be liable to you for any loss, damage, expense, or liability that are or may relate to any of the risks specifically set forth herein. Further, you represent that you are able to bear any financial or other loss associated with or that may otherwise relate to your access or use of the Services.6.2 Non-RelianceYou represent that you are not relying on (and will not at any time rely on) any communication (written or oral) of Akash as advice or as a recommendation to engage in any transaction involving Digital Assets. Further, you confirm that Akash has not: (a) given any guarantee or representation as to the potential success, return, effect, or benefit (either legal, regulatory, tax, financial, accounting, or otherwise) of transacting in Digital Assets; or (b) made any representation to you regarding the legality of transacting in Digital Assets under any applicable law to which you may be subject. In deciding to use the Services to transact in Digital Assets, you are not relying on the advice or recommendations of Akash, and you have made your own independent decision that using the Services and transacting in Digital Assets are suitable and appropriate for you.You acknowledge and agree that we do not provide investment advice, and any content on the Platform, other parts of the Services, or communication channels should not be considered as investment advice. You must seek professional advice regarding your particular financial, legal, technical, and other conditions prior to commencing your use of the Services. You represent and warrant that you fully understand all risks associated with using the Services and you have the necessary experience, understanding, and risk tolerance for using the Services, including the necessary experience and knowledge to enter into any relevant transaction through the Services. You will carefully consider and use clear judgment to evaluate your financial situation and risks before making any decisions to use the Services. You accept the risk of using the Services and are responsible for conducting your own independent analysis of the risks specific to your use of the Services.7. Prohibited UseYou may not use the Services to engage in the following categories of activity (each a \"Prohibited Use\"). The specific types of activities listed below are representative, but not exhaustive.Unlawful Activity. Activity which, in any way, would violate, or assist in violation of, any law, statue, ordinance, or regulation, sanctions programs administered in the countries where Akash offers the Services, or which would involve proceeds of any unlawful activity, including without limitation publishing, distributing, or disseminating any unlawful material or information.Abusive of Others. Interfere with another individual's access to or use of the Services including without limitation any activity that may: exploit, harm, or attempt to exploit or harm minors in any way by exposing them to inappropriate content: defame, abuse, extort, harass, stalk, threaten, or otherwise violate or infringe the legal rights of others; ask for personally identifiable information, or otherwise transmit, or procure the sending of, any advertising or promotional material, including any \"junk mail,\" \"chain letter,\" \"spam,\" or any other similar solicitation; impersonate or attempt to impersonate Akash, an employee, another user, or any other person or entity associated with Akash (including, without limitation, by using email addresses, screen names, similarly named or commonly misspelled URLs, or associated blockchain identities); engage in any other conduct that restricts or inhibits anyone's use or enjoyment of the Services; or incite, threaten, encourage, or promote hate, racial intolerance, or violent acts against others.Fraud. Activity which operates to deceive or defraud, or attempt to deceive or defraud, Akash, any users or any other person, including without limitation providing any false, inaccurate, or misleading information whether directly through the Services or through an external means that affects the Services with the intent to unlawfully obtain the property of another or to provide knowingly or recklessly false information, including without limitation in any way that causes inaccuracy among the content on the Services.Abusive Activity. Activity that may cause the Services, the Services underlying blockchain networks or technologies, or any other functionality with which the Services interact, to work other than as intended; damage the reputation of Akash or impair any of our legal rights or interests; violate any applicable laws concerning, or otherwise damages, the integrity of the Services, or any other service or software which relies on the Services; disable, overburden, damage, impair, or interfere with the Services, including the ability to engage in real time activities through the Services; involve the use any robot, spider, or other automatic device, process, or means to access the Services for any purpose, including monitoring or copying any of the material on the Services; attempt to gain unauthorized access to, interfere with, damage, or disrupt any parts of the Services, the server on which the Services or information in connection with the Services is stored, or any server, computer, or database connected to the Services, including any underlying blockchain.Intellectual Property Infringement. Violate the legal rights (including the rights of publicity and privacy) of others or contain any material that could give rise to any civil or criminal liability under applicable law or regulation or that otherwise may be in conflict with these Terms; engage in transactions involving items that infringe or violate any copyright, trademark, right of publicity or privacy, or any other proprietary right under the law, including but not limited to sales, distribution, or access to counterfeit music, software, or other licensed materials without the appropriate authorization from the rights holder; use of Akash intellectual property, name, or logo, including use of any Akash trade or service mark, without express consent of Akash or in a manner that otherwise harms Akash or the Akash brand; any action that implies an untrue endorsement by or affiliation with Akash.You agree and represent that you will not engage in any Prohibited Use in connection with the Services. You further represent and warrant that you: (a) will abide by any and all applicable laws of the jurisdiction where you are located while using the Platform or the Services; (b) will comply with all local, national, and international practices regarding internet use; (c) have obtained sufficient information about the Services, Digital Assets, and other services or products in connection with the Services to make an informed decisions in regard to your use of the Services; (d) will bear the full responsibility for any and all activities that occurs in connection with your use or access to the Services including without limitation transactions of Digital Assets, interacting with the Services, disclosing, or publishing information, clicking to agree with various agreements, and uploading and submitting various documents or information; and (e) are the legal and rightful owner of the Digital Assets in the Digital Asset Wallet, and Digital Assets you use with the Services.8. Sanctions & Export ControlsYou may not use the Services or purchase any Resources in or for the benefit of a country, organization, entity, or person embargoed or blocked by any government, including those on sanctions lists identified by OFAC. We do not claim, and we cannot guarantee that the Services or any Resources are or will be appropriate or available for any location or jurisdiction, comply with the laws of any location or jurisdiction, or comply with laws governing export, import, or foreign use.9. Changes, Suspension, and TerminationAkash may, at its discretion and without liability to you, with or without prior notice and at any time, modify, discontinue, temporarily, or permanently, all or any portion of the Platform. You acknowledge that our decision to take certain actions, including limiting access to, suspending, or terming your access to the Platform may be based on our confidential criteria that are essential to our risk management and security protocols. You agree that we are under no obligation to disclose the details of our risk management and security procedures to you. Akash will not be liable for any losses suffered by you resulting from any modification of the Services or from any suspension or termination of your access to all or a portion of the Platform (whether pursuant to this Section 9 or for any other reason. You acknowledge that Digital Asset values may fluctuate during any period during which the Services have been suspended and agree that Akash will have no liability for any such fluctuations.Without limiting the foregoing, we have the right to cooperate fully with any law enforcement authorities or court order requesting or directing us to disclose the identity or other information of anyone posting any materials on or through the Services. You waive and hold harmless Akash and its affiliates, licensees, and service providers from any claims resulting from any action taken by Akash and/or any of the foregoing parties during, or taken as a consequence of, investigations by us, such parties, or law enforcement authorities.10. Intellectual Property Rights10.1 Akash MaterialsThe Services and its entire contents, features, and functionality including but not limited to all information, software, text, displays, images, video, and audio, the design, selection, and arrangement thereof, and the \"look and feel\" of the Services, except any open source software, are owned by Akash (\"Akash Materials\"), its licensors, or other providers of such material and are protected by applicable and/or international copyright, trademark, patent, trade secret, and other intellectual property or proprietary rights laws.10.2 Limitations on UseIn connection with your use of the Services, you may use the Akash Materials solely as authorized by us for as long as we permit you to continue accessing the Services. Without limiting the foregoing, you agree not to: (a) resell, lease, lend, share, distribute, or otherwise permit any third party to use the Services, Akash Materials, or use the Services or Akash Materials in any service bureau environment; (b) modify or create derivative works of the Services or Akash Materials, or any portion thereof, or any data or information received by you in connection therewith; (c) frame, display, or incorporate the Services or Akash Materials in any website or any other work of authorship in a manner that implies any affiliation with Akash other than of your use of the Services; (d) decompile, disassemble, reverse engineer, or attempt to discover the source code of the Services or Akash Materials; (e) use the Services or Akash Materials to design, develop, or create any competing product or service; or (f) otherwise use the Services or Akash Materials for any commercial or noncommercial purpose other than their intended purposes determined at Akash's discretion.10.3 Rights We Grant YouWe 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.10.4 Reservation of RightsIf your use or access to the Services is in breach of these Terms, your right to access the Services will stop immediately and you must, at our sole option, return or destroy any copies of the materials that you made directly or indirectly from the Services. No right, title, or interest in or to the Services is transferred to you, and all rights not expressly granted are reserved by Akash. You may freely use any open-sourced materials up to the limits provided, but in accordance with any requirements placed, by those materials' open-source licenses. Any use of the Services not expressly permitted by these Terms is a breach of these Terms and may violate copyright, trademark, and other applicable laws.10.5 TrademarksAkash's name, the term \"Akash Network\" and all related names, logos, product and/or service names, designs, and slogans are trademarks of Akash, its affiliates, or licensors. You agree not to use such marks without the prior express written permission of Akash.11. Platform ContentWe do not warrant the accuracy, completeness, or usefulness of any materials or information that we or a third party present on or through the Services. Such information is made available solely for general information and education purposes. Any information posted to the Services should not be construed as an intention to form a contract, and in no case should any information be construed as our offer to buy, sell, exchange, or otherwise transact Digital Assets. We disclaim all liability and responsibility arising from any reliance placed on such information or materials by you, any other user or person who may be informed of any of the Services contents, or by the actions or omissions of others interacting with the Services.12. Interactions with other UsersYou are responsible for your interactions with other users, including other Tenants or Providers, as applicable, 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, now or in the future, you agree to release Akash (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 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.13. PromotionsAkash may make available special offers or conduct promotions for qualifying users. Subject to applicable laws, Akash, or the issuer of a Digital Asset subject to an offer or promotion, may establish qualifying criteria to participate in any special promotions at its sole discretion. Any benefits associated with any promotions are limited to one per user. Akash may revoke any special offer at any time and for any reason without advance notice to you. Akash is under no obligation to make available special offers to all Akash users. Akash makes no recommendation and does not provide any advice about the value or utility of a Digital Asset that is part of a promotion.14. FeedbackAny questions, suggestions, ideas, feedback, reviews, or other information or materials regarding the Services provided by you to Akash (collectively, \"Feedback\") are non-confidential. Akash will be entitled to the unrestricted use and dissemination of Feedback for any purpose, commercial or otherwise without acknowledgment, attribution, or compensation to you. You hereby assign to Akash all right, title, and interest to Feedback together with all associated intellectual property rights and waive any claim for, acknowledgement or compensation based on any Feedback or any modifications made based on any Feedback.15. Relationship of the PartiesAkash is not your broker, intermediary, agent, or advisor and has no fiduciary relationship or obligation to you in your use of the Services. Akash does not provide investment, tax, or legal advice, and you are solely responsible for any transaction, investment, strategy, decision, or other act that you make when using the Services. Akash may provide educational material or information on the Platform, through the Services, social media account, or other channel of communication. No communication or information provided to you by Akash is intended as, or shall be considered or construed as, advice. To the fullest extent permissible by law, you agree that your access or use of the Services causes Akash or any user to owe fiduciary duties or liabilities to you or any third party. Further, you acknowledge and agree to the fullest extent such duties or liabilities are afforded by law or by equity, those duties and liabilities are hereby irrevocably disclaimed, waived, and eliminated, and that Akash shall be held completely harmless in relation thereof.16. Charges and Fees16.1 Protocol FeesYou may be charged fees in connection with your access to the Protocol via a third party interface. You are responsible for doing your own diligence on any third party interface to understand any applicable fee or charge that such third party may charge you. Under no circumstances shall Akash incur any liability, of any kind, to you arising from or relating to fees charged to you by your access or use to the Protocol via a third party interface.You may cancel your access to the Services at any time through the Platform.16.2 Our Charges and FeesWe may, in our sole discretion and at any time, set or modify the fees for the Services. If we decide to set or modify fees for the Services, the fee schedule will be made available on the Platform. Except when required by law, all fees you pay to us are non-refundable.16.3 Blockchain FeesBlockchain transactions require the payment of transaction fees to the appropriate network's nodes, miners, validators, or operators (\"Blockchain Fees\"). You will be solely responsible to pay the Blockchain Fees for any transaction that you initiate via the Protocol or the Services. Blockchain Fees are neither levied directly by Akash nor paid to or shared with Akash in any way, but rather are determined by your use of the Protocol and the rules placed by corresponding blockchain communities at large. You acknowledge and agree that Akash has no control over Blockchain Fees (including without limitation their applicability, payment, amounts, transmission, intended operation, and effectiveness) whether related to your use of the Services or otherwise, and in no event will Akash be responsible to you or any other party for the payment, repayment, refund, disbursement, indemnity, or for any other aspect of your use or transmission of Blockchain Fees.16.4 Credit Card Payments; ChargebacksYou may purchase access to the Services with Digital Assets via your Digital Asset Wallet, or with an accepted debit or credit card (\"Payment Card\") through Stripe's payment portal. You are responsible for keeping all information for your Payment Card updated and accurate through the term of this Agreement.When you purchase access to the Services with a Payment Card, a Digital Asset Wallet associated with and controlled by your account will be created automatically and the amount of your payment will be converted to Axelar USDC stablecoins, a Digital Asset issued by a third party intended to maintain 1:1 price parity with the U.S. dollar (\"axlUSDC\"). Prices for Services are determined by Providers. The prices of the available Services are determined by Providers and not by Akash. Applicable Blockchain Fees associated with your use of the Services will be charged automatically against your axlUSDC balance. Delivery of access to the Services is performed solely by the Provider upon your successful payment to such Provider. You are responsible for keeping all information for your Payment Card updated and accurate. The U.S. Dollar equivalent price of axlUSDC is determined by a third party, not us. We make no representations, warranties, or guarantees of any kind regarding the stability or price volatility associated with axlUSDC. Your use of a Payment Card to access the Services is solely at your own risk. YOU AGREE THAT ALL SALES TO YOU OF axlUSDC ARE FINAL. TO THE FULLEST EXTENT PERMITTED UNDER APPLICABLE LAW, NO REFUNDS WILL BE GIVEN.Any and all axlUSDC you convert, use, purchase, and/or transact, which may be held on your account or transmitted to a Digital Asset Wallet address, are not stored or held in an electronic money account and does not qualify as a \"deposit\"; axlUSDC are not a representation of money or funds. By accepting the terms of this Agreement, you acknowledge and agree that your axlUSDC are not protected by any deposit guarantee scheme and the funds used to increase your axlUSDC will not be safeguarded. Your axlUSDC belong to you and no other person has any rights to your axlUSDC.Notwithstanding the foregoing, we will facilitate \"Chargebacks\" for any successfully disputed fees paid in connection the Services if directed by Stripe. A \"Chargeback\" occurs when a credit card payment is reversed by your card issuer or payment provider, typically due to a dispute, fraud claim, or unauthorized transaction. Chargebacks are subject to Stripe's terms and conditions found here: https://support.stripe.com/topics/cash-titles.17. General Service Terms17.1 Blockchain TransactionsIn connection with the Services, transactions rely on blockchain software parameters, cryptographic tokens generated by such parameters, and other nascent software, applications and systems that interact with blockchain-based networks. These technologies are experimental, speculative, inherently risky, and subject to change. A defining feature of blockchain technology is that its entries are immutable, which means, as a technical matter, they generally cannot be deleted or modified by anyone. You acknowledge and understand that smart contracts dictate how funds and ownership of Digital Assets are distributed.17.2 TaxesIt is your sole responsibility to determine whether and to what extent any taxes apply to activity you conduct through the Services, and to withhold, collect, report, and remit the correct amounts of taxes to the appropriate tax authorities. No communication or information provided to you by Akash is intended as, or considered or construed as, legal or tax advice.18. WARRANTY DISCLAIMERAkash has no oversight on or control over any particular Digital Asset or blockchain network, including the Protocol. You are responsible for your use of the Services, the functionalities that you enable, transactions engaged on the Protocol through the Services, and access or use of the information derived thereof. You are solely responsible for complying with all applicable laws related to its transactions and activities that directly or indirectly incorporate our provision of the Services. You acknowledge and understand Akash is not registered nor licensed with, nor have the Services or the software contained therein been reviewed by any securities, commodities, or other financial or banking regulator. You further understand that we cannot and do not guarantee or warrant that files available for download from the Services will be free of viruses or other destructive code. You are responsible for implementing sufficient procedures and checkpoints to satisfy your particular requirements for: (a) an appropriate blockchain-based utility; (b) anti-virus protection and accuracy of data input and output; (c) your participation in and use of the Protocol and related technologies; and (d) maintaining a means external to our site to reconstruct any lost data.TO THE FULLEST EXTENT PROVIDED BY LAW, IN NO EVENT WILL AKASH, ITS AFFILIATES, SERVICE PROVIDERS, OR ANY OF THEIR RESPECTIVE OFFICERS, DIRECTORS, AGENTS, JOINT VENTURERS, EMPLOYEES, OR REPRESENTATIVES BE LIABLE FOR ANY LOSS OR DAMAGE CAUSED BY A DISTRIBUTED DENIAL-OF-SERVICE ATTACK, MAN-IN-THE-MIDDLE ATTACK, VIRUS, OR OTHER TECHNOLOGICALLY HARMFUL MATERIAL THAT MAY INFECT YOUR COMPUTER EQUIPMENT, COMPUTER PROGRAMS, DATA, OR OTHER PROPRIETARY MATERIAL DUE TO YOUR USE OF THE SERVICES, THE PROTOCOL, THE AKASH MATERIALS, OR ANY PRODUCT, SERVICE OR OTHER ITEM PROVIDED BY OR ON BEHALF OF AKASH THROUGH THE SERVICES, OR YOUR DOWNLOADING OF ANY MATERIAL POSTED ON IT, OR ON ANY THIRD PARTY WEBSITE LINKED TO IT.YOUR USE OF THE SERVICES AND ANY SERVICES CONTENT IS AT YOUR SOLE RISK. THE SERVICES, THE AKASH MATERIALS, THE PROTOCOL, AND ANY PRODUCT, SERVICE OR OTHER ITEM PROVIDED BY OR ON BEHALF OF AKASH ARE PROVIDED ON AN \"AS IS\" AND \"AS AVAILABLE\" BASIS. TO THE FULLEST EXTENT LEGALLY PERMISSIBLE, IN NO EVENT WILL AKASH, ITS AFFILIATES, SERVICE PROVIDERS, OR ANY OF THEIR RESPECTIVE OFFICERS, DIRECTORS, AGENTS, JOINT VENTURERS, EMPLOYEES, OR REPRESENTATIVES BE LIABLE FOR, AND EXPLICITLY DISCLAIM, ANY AND ALL REPRESENTATIONS OR WARRANTIES OF ANY KIND RELATED THE SERVICES, THE AKASH MATERIALS, THE PROTOCOL, OR ANY PRODUCT, SERVICE OR OTHER ITEM PROVIDED BY OR ON BEHALF OF AKASH WHETHER EXPRESS, IMPLIED, OR STATUTORY, INCLUDING (WITHOUT LIMITATION) THE WARRANTIES OF MERCHANTABILITY, NON-INFRINGEMENT, AND FITNESS FOR A PARTICULAR PURPOSE. NEITHER AKASH, ITS AFFILIATES, SERVICE PROVIDERS, OR ANY OF THEIR RESPECTIVE OFFICERS, DIRECTORS, AGENTS, JOINT VENTURERS, EMPLOYEES, OR REPRESENTATIVES MAKES ANY WARRANTY OR REPRESENTATION WITH RESPECT TO THE COMPLETENESS, SECURITY, RELIABILITY, QUALITY, ACCURACY, OR AVILABILITY OF THE SERVICES, THE AKASH MATERIALS, THE PROTOCOL, AND/OR ANY PRODUCT, SERVICE OR OTHER ITEM PROVIDED BY OR ON BEHALF OF AKASH.AKASH, ITS AFFILIATES, SERVICE PROVIDERS, OR ANY OF THEIR RESPECTIVE OFFICERS, DIRECTORS, AGENTS, JOINT VENTURERS, EMPLOYEES, OR REPRESENTATIVES DO NOT REPRESENT OR WARRANT THAT: (A) ACCESS TO THE SERVICES, THE AKASH MATERIALS, THE PROTOCOL, OR ANY PRODUCT, SERVICE OR OTHER ITEM PROVIDED BY OR ON BEHALF OF AKASH WILL BE CONTINUOUS, UNINTERRUPTED, TIMELY, WITHOUT DELAY, ERROR-FREE, SECURE, OR FREE FROM DEFECTS; (B) THE INFORMATION CONTAINED OR PRESENTED ON THE SERVICES, THE AKASH MATERIAL, OR THE PROTOCOL IS ACCURATE, RELIABLE, COMPLETE, CONCISE, CURRENT, OR RELEVANT; (C) THE SERVICES, THE AKASH MATERIALS, THE PROTOCOL, OR ANY PRODUCT, SERVICE OR OTHER ITEM PROVIDED BY OR ON BEHALF OF AKASH OR ANY SOFTWARE CONTAINED THEREIN WILL BE FREE FROM DEFECTS, MALICIOUS SOFTWARE, ERRORS, OR ANY OTHER HARMFUL ELEMENTS, OR THAT ANY OF SUCH WILL BE CORRECTED; OR (D) THE SERVICES, THE AKASH MATERIALS, OR ANY PRODUCT, SERVICE OR OTHER ITEM PROVIDED BY OR ON BEHALF OF AKASH WILL MEET ANY USER'S EXPECTATIONS.NO INFORMATION OR STATEMENT THAT WE MAKE, INCLUDING DOCUMENTATION OR PRIVATE COMMUNICATION, SHOULD BE TREATED AS OFFERING ANY WARRANTY CONCERNING THE SERVICES, THE AKASH MATERIALS, THE PROTOCOL, OR ANY PRODUCT, SERVICE OR OTHER ITEM PROVIDED BY OR ON BEHALF OF AKASH. WE DO NOT ENDORSE, GUARANTEE, OR ASSUME ANY LIABILITY OR RESPONSIBILITY FOR ANY CONTENT, ADVERTISEMENTS, OFFERS, STATEMENTS, OR ACTIONS BY ANY THIRD PARTY EITHER REGARDING THE SERVICES, THE AKASH MATERIALS, THE PROTOCOL, OR ANY PRODUCT, SERVICE OR OTHER ITEM PROVIDED BY OR ON BEHALF OF AKASH. THE FOREGOING DOES NOT AFFECT ANY WARRANTIES THAT CANNOT BE EXCLUDED OR LIMITED UNDER APPLICABLE LAW.19. IndemnificationYou agree to defend, indemnify, and hold harmless Akash, its affiliates, licensors, service providers, and their respective officers, directors, employees, contractors, agents, licensors, suppliers, successors, and assigns from and against any claims, liabilities, damages, judgments, awards, losses, costs, expenses, or fees (including reasonable attorneys' fees) arising out of or relating to; (a) your violation of these Terms; (b) your use of Services, including, but not limited to, your interactions with the Platform or other services or features accessible or or through the Services; (c) use of or reliance on the Platform's content, the Services, and/or services or products other than as expressly authorized in these Terms; (d) your use or reliance on of any information obtained from the Services, and/or (e) any third party's access or use of the Services with or without your assistance, using any device, account, profile, Digital Asset Wallet, or other mechanism that you own or control.20. LIMITATION OF LIABILITY; DISCLAIMER OF DAMAGESTO THE FULLEST EXTENT PROVIDED BY LAW, IN NO EVENT WILL AKASH, ITS AFFILIATES, OR THEIR RESPECTIVE LICENSORS, SERVICE PROVIDERS, EMPLOYEES, AGENTS, OFFICERS, OR DIRECTORS BE LIABLE FOR DAMAGES OF ANY KIND, UNDER ANY LEGAL THEORY, ARISING OUT OF OR IN CONNECTION WITH YOUR USE, OR INABILITY TO USE THE SERVICES, THE AKASH MATERIALS, THE PROTOCOL, OR ANY PRODUCT, SERVICE OR OTHER ITEM PROVIDED BY OR ON BEHALF OF AKASH, INCLUDING ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL, CONSEQUENTIAL, OR PUNITIVE DAMAGES INCLUDING BUT NOT LIMITED TO, PERSONAL INJURY, PAIN AND SUFFERING, EMOTIONAL DISTRESS, LOSS OF REVENUE, LOSS OF PROFITS, LOSS OF BUSINESS OR ANTICIPATED SAVINGS, LOSS OF USE, LOSS OF GOODWILL, LOSS OF DATA, AND WHETHER CAUSED BY TORT (INCLUDING NEGLIGENCE), BREACH OF CONTRACT, OR OTHERWISE, EVEN IF FORESEEABLE. THIS DISCLAIMER OF LIABILITY EXTENDS TO ANY AND ALL DAMAGES CAUSED BY ANY THIRD PARTY (INCLUDING, WITHOUT LIMITATION, THOSE CAUSED BY FRAUD, DECEIT, OR MANIPULATION), WHETHER OR NOT A USER, OR ANY FAILURE, EXPLOIT, OR VULNERABILITY OF THE SERVICES, THE PLATFORM, THE PROTOCOL, THE AKASH MATERIALS, OR ANY PRODUCT, SERVICE OR OTHER ITEM PROVIDED BY OR ON BEHALF OF AKASH.TO THE FULLEST EXTENT PROVIDED BY LAW, IN NO EVENT WILL THE COLLECTIVE LIABILITY OF AKASH, ITS SUBSIDIARIES, AFFILIATES, LICENSORS, SERVICE PROVIDERS, AND THEIR RESPECTIVE EMPLOYEES, AGENTS, OFFICERS, AND DIRECTORS, TO ANY PARTY (REGARDLESS OF THE FORM OF ACTION, WHETHER IN CONTRACT, TORT, OR OTHERWISE) EXCEED THE GREATER OF $100 OR THE AMOUNT YOU HAVE PAID DIRECTLY TO AKASH FOR THE APPLICABLE SERVICES IN THE LAST SIX MONTHS OUT OF WHICH LIABILITY AROSE. THE FOREGOING DOES NOT AFFECT ANY LIABILITY THAT CANNOT BE EXCLUDED OR LIMITED UNDER APPLICABLE LAW.21. Dispute Resolution, Waiver of Class Action, and Mandatory ArbitrationPlease read this section carefully because it waives any right to participate in any class action or other representative action or proceeding. This section requires you to arbitrate certain disputes and limits the ways in which you can seek relief, including by precluding you from suing in court or having a jury trial.21.1 Waiver of Class Actions and Right to Jury TrialTo the extent permissible by law, any claim, controversy, or dispute arising out of or related to this Agreement, or any products or services provided in connection with the Services (each a \"Dispute\") must be brought in your individual capacity, and not as a plaintiff or class member in any putative class, collective action, or representative proceeding (collectively, a \"Class Action Waiver\"). The arbitrator may not consolidate more than one person's claims or engage in any arbitration on behalf of a class. You agree that, by entering into this agreement, you are waiving the right to a trial by jury and the right to participate in a class action.21.2 Informal ResolutionBefore filing a claim against Akash, you agree to try to resolve the Dispute by first emailing consolebilling@akash.network with a description of your claim and proof of your relationship with Akash. If we can't resolve the Dispute within sixty days of our receipt of your first email, you or Akash may then submit the Dispute to binding arbitration as provided herein.21.3 Arbitration AgreementWith only limited exceptions as described in 21.7 below, all Disputes between you and Akash must be resolved by final and binding arbitration. By agreeing to binding arbitration, you and Akash expressly waive the right to formal court proceedings including without limitation trial by jury and class action. This Agreement affects interstate commerce, and the enforceability of this Section will be substantively and procedurally governed by the Federal Arbitration Act 9 U.S.C. § 1, et seq. (\"FAA\").21.4 Conducting ArbitrationThe arbitration shall be conducted by the International Chamber of Commerce (\"ICC\") under its Commercial Arbitration Rules (\"ICC Rules\") then in effect. If you are a consumer, the most recent version of the ICC Rules can be accessed here. These Terms shall govern any conflict between the ICC Rules and these Terms. The location and type of hearing shall be determined in accordance with the ICC Rules. Further, a party's right to request a hearing shall also be determined in accordance with the ICC Rules. Unless otherwise ordered by an arbitrator or pursuant to the ICC Rules, any in-person arbitration shall be in English and administered in New York, New York, or another mutually agreeable location.21.5 ConfidentialityAkash, the arbitrator, and you, will each maintain the confidentiality of any arbitration proceedings, judgments, and awards including information gathered and produced during the arbitration.21.6 Arbitration Time for FilingAny arbitration must be commenced by filing a demand for arbitration within one year after the date the party asserting the claim first knows or reasonably should know of the act, omission or default giving rise to the claim. If applicable law prohibits a one year limitation period for asserting claims, any claim must be asserted within the shortest time period permitted by applicable law. If a claim is not filed within such period, the Dispute is permanently barred.21.7 Excepted ClaimsNotwithstanding this Section 21, you and Akash may bring an individual small claims action in the small claims court in your or Akash's respective county of residence as provided under the ICC Rules, or seek only a temporary restraining order or injunction for alleged breach of confidentiality obligations or alleged infringement or misappropriation of intellectual property in any court having jurisdiction provided that, in each case, the action is brought as an individual action and not on a class or representative basis.21.8 SeverabilityIf any portion of this Section 21 is found to be unenforceable or unlawful for any reason, the unenforceable or unlawful provision shall be severed from these Terms and such severance of the provision(s) shall have no impact whatsoever on the remainder of this Section 21. Further, to the extent that any claims must therefore proceed on a class, collective, consolidated, or representative basis, such claims must be litigated in a civil court of competent jurisdiction and not in arbitration, and the parties agree that litigation of those claims shall be stayed pending the outcome of any individual claims in arbitration. Lastly, if any provision in this Section 21 is found to prohibit an individual claim seeking public injunctive relief, such provision shall have no effect to the extent relief is allowed to be sought outside of arbitration. The remainder of this Section 21 shall remain in full force and effect.21.9 ModificationNotwithstanding any term or provision in this Agreement to the contrary, you and Akash agree that if Akash makes any future material change to this Section 21, Akash will notify you. Your continued use of the Services including the acceptance of products and services offered on the Platform following the posting of changes to this Section 21 constitutes your acceptance of any such changes.22. Governing LawThis Agreement shall be governed by, and construed and enforced in accordance with, the laws of Texas. Without regard to conflict of law rules or principles that would cause the application of the laws of any other jurisdiction. You agree that Akash may initiate a proceeding relating to the enforceability or validity of Akash's intellectual property rights in any court of competent jurisdiction. With respect to any other proceeding not subject to arbitration under this Agreement, the federal and state courts located in Texas will have exclusive jurisdiction. You waive any objection to venue in any such courts.23. Amendments to this AgreementAkash reserves the right to amend this Agreement and/or policies that govern the Services from time to time and in our sole discretion. Any changes will be effective immediately upon posting of the revisions, and you waive any right you may have to receive specific notices of such changes or modifications. By continuing to use the Services after any changes are posted to the website, you agree to be bound by those changes. If you do not agree to the changes, you may stop using the Services.24. Miscellaneous Terms24.1 AssignmentThese Terms, and any other document, material, or information referenced herein is particular to you and any attempt that you make to assign, novate, or transfer your rights, interests, liabilities, and/or obligations is null and void, unless you have received Akash's prior written consent. Akash reserves the right to assign our rights without restriction, including without limitation to any of Akash's affiliates or subsidiaries, or to any successor in interest of any business associated with the Services. Subject to the foregoing, these Terms will bind and inure to the benefit of the parties and their successors and permitted assigns.24.2 Termination & SurvivalWe reserve the right to change, suspend or discontinue, or terminate, restrict, or disable your use of or access to, parts or all of the Services or their functionality at any time at our sole discretion and without notice. All sections of this Agreement that by their nature should survive termination shall survive termination.24.3 Nonwaiver of RightsAkash's failure or delay in exercising any right, power, or privilege under these Terms shall not operate as a waiver thereof.24.4 SeverabilityIf any provision of this Agreement shall be determined to be invalid or unenforceable under any rule, law, or regulation, or any governmental agency whether local, state, or federal, such provision shall be 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 the Terms shall not be affected.24.5 Force MajeureYou acknowledge and consent that the Services are provided by us according to our current technological capability and other business conditions. While we have made every effort to ensure continuity and security of the Services, we are unable to completely foresee and hedge against all legal, technological, and other risks.Akash shall not be held liable for delays, failure in performance, or interruption of Services that result directly or indirectly from any cause or condition beyond our reasonable control. Such instances include: (a) acts of God such as earth earthquakes, fires, cyclones, explosions, typhoons, monsoons, landslides, lightning, storms, tempests, pandemics, droughts or meteors; (b) acts of war, whether declared or undeclared, including invasion, act of a foreign enemy, hostilities between nations, civil insurrection, or militarily usurped power; and acts of terrorism; (c) civil disorder, such as acts of a public enemy, malicious damage, terro","tokens":15000,"squid":"spider-03","role":"Compute Spider","at":1791338836246,"hash":"ec705f81739c10f48a860e4848cc8678912c5984"}
{"url":"https://consensysdiligence.github.io/smart-contract-best-practices/attacks/griefing/","domain":"consensysdiligence.github.io","title":"Griefing - Ethereum Smart Contract Best Practices","text":"Griefing\n\nTip\nThank you for visiting the Smart Contract Security Best Practices. Please note that this resource is no longer actively maintained. Instead, we recommend visiting the Smart Contract Security Field Guide. The Field Guide is regularly updated and curated by the same security engineer who previously contributed to the Best Practices guide.\nThe resource on griefing attacks can be found here: https://scsfg.io/hackers/griefing/\n\nThis attack may be possible on a contract which accepts generic data and uses it to make a call\nanother contract (a 'sub-call') via the low level address.call() function, as is often the case\nwith multisignature and transaction relayer contracts.\nIf the call fails, the contract has two options:\n\nrevert the whole transaction\ncontinue execution.\n\nTake the following example of a simplified Relayer contract which continues execution regardless\nof the outcome of the subcall:\ncontract Relayer {\n mapping (bytes => bool) executed;\n\n function relay(bytes _data) public {\n // replay protection; do not call the same transaction twice\n require(executed[_data] == 0, \"Duplicate call\");\n executed[_data] = true;\n innerContract.call(bytes4(keccak256(\"execute(bytes)\")), _data);\n }\n}\n\nThis contract allows transaction relaying. Someone who wants to make a transaction but can't\nexecute it by himself (e.g. due to the lack of ether to pay for gas) can sign data that he wants to\npass and transfer the data with his signature over any medium. A third party \"forwarder\" can then\nsubmit this transaction to the network on behalf of the user.\nIf given just the right amount of gas, the Relayer would complete execution recording the\n_dataargument in the executed mapping, but the subcall would fail because it received\ninsufficient gas to complete execution.\n\nNote\nWhen a contract makes a sub-call to another contract, the EVM limits the gas forwarded to\nto 63/64 of the remaining gas,\n\nAn attacker can use this to censor transactions, causing them to fail by sending them with a low\namount of gas. This attack is a form of \"griefing\": It\ndoesn't directly benefit the attacker, but causes grief for the victim. A dedicated attacker,\nwilling to consistently spend a small amount of gas could theoretically censor all transactions\nthis way, if they were the first to submit them to Relayer.\nOne way to address this is to implement logic requiring forwarders to provide enough gas to finish\nthe subcall. If the miner tried to conduct the attack in this scenario, the require statement\nwould fail and the inner call would revert. A user can specify a minimum gasLimit along with the\nother data (in this example, typically the _gasLimit value would be verified by a signature, but\nthat is omitted for simplicity in this case).\n// contract called by Relayer\ncontract Executor {\n function execute(bytes _data, uint _gasLimit) {\n require(gasleft() >= _gasLimit);\n ...\n }\n}\n\nAnother solution is to permit only trusted accounts to relay the transaction.","tokens":743,"squid":"spider-06","role":"Security Spider","at":1791338840736,"hash":"4dce11be2a9ea77931b66dcb44c1013a951296b3"}
{"url":"https://consensysdiligence.github.io/smart-contract-best-practices/attacks/reentrancy/","domain":"consensysdiligence.github.io","title":"Reentrancy - Ethereum Smart Contract Best Practices","text":"Reentrancy\n\nTip\nThank you for visiting the Smart Contract Security Best Practices. Please note that this resource is no longer actively maintained. Instead, we recommend visiting the Smart Contract Security Field Guide. The Field Guide is regularly updated and curated by the same security engineer who previously contributed to the Best Practices guide.\nThe resource on reentrancy can be found here: https://scsfg.io/hackers/reentrancy/\n\nOne of the major dangers of calling external contracts is that\nthey can take over the control flow, and make changes to your data that the calling function wasn't\nexpecting. This class of bugs can take many forms, and both of the major bugs that led to the DAO's\ncollapse were bugs of this sort.\nReentrancy on a Single Function¶\nThe first version of this bug to be noticed involved functions that could be called repeatedly,\nbefore the first invocation of the function was finished. This may cause the different invocations\nof the function to interact in destructive ways.\n// INSECURE\nmapping (address => uint) private userBalances;\n\nfunction withdrawBalance() public {\n uint amountToWithdraw = userBalances[msg.sender];\n (bool success, ) = msg.sender.call.value(amountToWithdraw)(\"\"); // At this point, the caller's code is executed, and can call withdrawBalance again\n require(success);\n userBalances[msg.sender] = 0;\n}\n\nSince the user's balance is not set to 0 until the very end of the function, the second (and later)\ninvocations will still succeed and will withdraw the balance over and over again.\n\nFactoid\nA DAO is a Decentralized Autonomous Organization. Its goal is to codify the rules and\ndecision-making apparatus of an organization, eliminating the need for documents and people in\ngoverning, creating a structure with decentralized control.\n\nOn June 17th 2016, [The DAO](https://www.coindesk.com/understanding-dao-hack-journalists) was hacked and 3.6 million Ether ($50 Million) were stolen using the first reentrancy attack.\n\nEthereum Foundation issued a critical update to rollback the hack. This resulted in Ethereum being forked into Ethereum Classic and Ethereum.\n\nIn the example given, the best way to prevent this attack is to make sure you don't call an\nexternal function until you've done all the internal work you need to do:\nmapping (address => uint) private userBalances;\n\nfunction withdrawBalance() public {\n uint amountToWithdraw = userBalances[msg.sender];\n userBalances[msg.sender] = 0;\n (bool success, ) = msg.sender.call.value(amountToWithdraw)(\"\"); // The user's balance is already 0, so future invocations won't withdraw anything\n require(success);\n}\n\nNote that if you had another function which called withdrawBalance(), it would be potentially\nsubject to the same attack, so you must treat any function which calls an untrusted contract as\nitself untrusted. See below for further discussion of potential solutions.\nCross-function Reentrancy¶\nAn attacker may also be able to do a similar attack using two different functions that share the\nsame state.\n// INSECURE\nmapping (address => uint) private userBalances;\n\nfunction transfer(address to, uint amount) {\n if (userBalances[msg.sender] >= amount) {\n userBalances[to] += amount;\n userBalances[msg.sender] -= amount;\n }\n}\n\nfunction withdrawBalance() public {\n uint amountToWithdraw = userBalances[msg.sender];\n (bool success, ) = msg.sender.call.value(amountToWithdraw)(\"\"); // At this point, the caller's code is executed, and can call transfer()\n require(success);\n userBalances[msg.sender] = 0;\n}\n\nIn this case, the attacker calls transfer() when their code is executed on the external call in\nwithdrawBalance. Since their balance has not yet been set to 0, they are able to transfer the\ntokens even though they already received the withdrawal. This vulnerability was also used in the\nDAO attack.\nThe same solutions will work, with the same caveats. Also note that in this example, both functions\nwere part of the same contract. However, the same bug can occur across multiple contracts, if those\ncontracts share state.\nPitfalls in Reentrancy Solutions¶\nSince reentrancy can occur across multiple functions, and even multiple contracts, any solution\naimed at preventing reentrancy with a single function will not be sufficient.\nInstead, we have recommended finishing all internal work (ie. state changes) first, and only then\ncalling the external function. This rule, if followed carefully, will allow you to avoid\nvulnerabilities due to reentrancy. However, you need to not only avoid calling external functions\ntoo soon, but also avoid calling functions which call external functions. For example, the\nfollowing is insecure:\n// INSECURE\nmapping (address => uint) private userBalances;\nmapping (address => bool) private claimedBonus;\nmapping (address => uint) private rewardsForA;\n\nfunction withdrawReward(address recipient) public {\n uint amountToWithdraw = rewardsForA[recipient];\n rewardsForA[recipient] = 0;\n (bool success, ) = recipient.call.value(amountToWithdraw)(\"\");\n require(success);\n}\n\nfunction getFirstWithdrawalBonus(address recipient) public {\n require(!claimedBonus[recipient]); // Each recipient should only be able to claim the bonus once\n\n rewardsForA[recipient] += 100;\n withdrawReward(recipient); // At this point, the caller will be able to execute getFirstWithdrawalBonus again.\n claimedBonus[recipient] = true;\n}\n\nEven though getFirstWithdrawalBonus() doesn't directly call an external contract, the call in\nwithdrawReward() is enough to make it vulnerable to a reentrancy. You therefore need to treat\nwithdrawReward() as if it were also untrusted.\nmapping (address => uint) private userBalances;\nmapping (address => bool) private claimedBonus;\nmapping (address => uint) private rewardsForA;\n\nfunction untrustedWithdrawReward(address recipient) public {\n uint amountToWithdraw = rewardsForA[recipient];\n rewardsForA[recipient] = 0;\n (bool success, ) = recipient.call.value(amountToWithdraw)(\"\");\n require(success);\n}\n\nfunction untrustedGetFirstWithdrawalBonus(address recipient) public {\n require(!claimedBonus[recipient]); // Each recipient should only be able to claim the bonus once\n\n claimedBonus[recipient] = true;\n rewardsForA[recipient] += 100;\n untrustedWithdrawReward(recipient); // claimedBonus has been set to true, so reentry is impossible\n}\n\nIn addition to the fix making reentry impossible,\nuntrusted functions have been marked. This same\npattern repeats at every level: since untrustedGetFirstWithdrawalBonus() calls\nuntrustedWithdrawReward(), which calls an external contract, you must also treat\nuntrustedGetFirstWithdrawalBonus() as insecure.\nAnother solution often suggested is a mutex. This\nallows you to \"lock\" some state so it can only be changed by the owner of the lock. A simple\nexample might look like this:\n// Note: This is a rudimentary example, and mutexes are particularly useful where there is substantial logic and/or shared state\nmapping (address => uint) private balances;\nbool private lockBalances;\n\nfunction deposit() payable public returns (bool) {\n require(!lockBalances);\n lockBalances = true;\n balances[msg.sender] += msg.value;\n lockBalances = false;\n return true;\n}\n\nfunction withdraw(uint amount) payable public returns (bool) {\n require(!lockBalances && amount > 0 && balances[msg.sender] >= amount);\n lockBalances = true;\n\n (bool success, ) = msg.sender.call(amount)(\"\");\n\n if (success) { // Normally insecure, but the mutex saves it\n balances[msg.sender] -= amount;\n }\n\n lockBalances = false;\n return true;\n}\n\nIf the user tries to call withdraw() again before the first call finishes, the lock will prevent\nit from having any effect. This can be an effective pattern, but it gets tricky when you have\nmultiple contracts that need to cooperate. The following is insecure:\n// INSECURE\ncontract StateHolder {\n uint private n;\n address private lockHolder;\n\n function getLock() {\n require(lockHolder == address(0));\n lockHolder = msg.sender;\n }\n\n function releaseLock() {\n require(msg.sender == lockHolder);\n lockHolder = address(0);\n }\n\n function set(uint newState) {\n require(msg.sender == lockHolder);\n n = newState;\n }\n}\n\nAn attacker can call getLock(), and then never call releaseLock(). If they do this, then the\ncontract will be locked forever, and no further changes will be able to be made. If you use mutexes\nto protect against reentrancy, you will need to carefully ensure that there are no ways for a lock\nto be claimed and never released. (There are other potential dangers when programming with mutexes,\nsuch as deadlocks and livelocks. You should consult the large amount of literature already written\non mutexes, if you decide to go this route.)\nSee SWC-107\n\nAbove were examples of reentrancy involving the attacker executing malicious code within a single\ntransaction. The following are a different type of attack inherent to Blockchains: the fact that\nthe order of transactions themselves (e.g. within a block) is easily subject to manipulation.","tokens":2239,"squid":"spider-06","role":"Security Spider","at":1791338850793,"hash":"b94fb485cc4872b5fa96c49b6eeeae03ec85ca79"}
{"url":"https://consensysdiligence.github.io/smart-contract-best-practices/attacks/oracle-manipulation/","domain":"consensysdiligence.github.io","title":"Oracle Manipulation - Ethereum Smart Contract Best Practices","text":"Oracle Manipulation\n\nTip\nThank you for visiting the Smart Contract Security Best Practices. Please note that this resource is no longer actively maintained. Instead, we recommend visiting the Smart Contract Security Field Guide. The Field Guide is regularly updated and curated by the same security engineer who previously contributed to the Best Practices guide.\nThe resource on oracle manipulation attacks can be found here: https://scsfg.io/hackers/oracle-manipulation/\n\nProtocols that rely on external data as inputs (from what's known as an\noracle)\nautomatically execute even if the data is incorrect, due to the nature of smart contracts. If a\nprotocol relies on an oracle that is hacked, deprecated, or has malicious intent, all processes\nthat depend on the oracle can now operate with disastrous effects.\nFor example:\n\nProtocol gets price from single Uniswap pool\nMalicious actor drains one side of the pool with a large transaction\nUniswap pool starts responding with a price more than 100x what it should be\nProtocol operates as if that were the actual price, giving the manipulator a better price\n\nWe've seen examples where this will liquidate positions, allow insane arbitrage, ruin DEX\npositions, and more.\nOracle Manipulation Solutions¶\nThe easiest way to solve this is to use decentralized oracles such as:\n\nChainlink is the leading decentralized oracle provider, and the Chainlink network can be leveraged to bring decentralized data on-chain.\nTellor is an oracle that provides censorship resistant data, secured by crypto-economic incentives, that ensure data can be provided by anyone, anytime, and checked by everyone.\nWitnet leverages state-of-the-art cryptographic and economic techniques to provide your smart contracts with secure data input.\n\nUsing a median of multiple oracles provides heighten security since it is harder and more expensive to attack multiple oracles than one and it ensures that your smart contract gets the data it needs even if one oracle or API call fails. \nAnother common solution is to use a time-weighted average price feed, so that price is averaged out\nover X time periods and multiple sources. Not only does this prevent oracle manipulation, but it also reduces the\nchance you can be front-run, as an order executed right before yours won't have as drastic an\nimpact on price. However, always keep in mind that low liquidity assets are generally easier/cheaper to manipulate, even for a period of time. One tool that gathers Uniswap price feeds every thirty minutes is\nKeep3r. If you're looking to build a custom solution,\nUniswap provides a sliding window example.","tokens":655,"squid":"spider-06","role":"Security Spider","at":1791338860892,"hash":"de963b2cdaa872c3780281bdbba172f91df0bc60"}
{"url":"https://developers.jup.ag/docs/legal/privacy-policy","domain":"developers.jup.ag","title":"Privacy Policy - Jupiter Developers","text":"Jupiter, accessible at: https://jup.ag, one of its main priorities is the privacy of participants who are visitors of https://jup.ag and its dApps .\nJupiter does it best to collect as minimum Personal Data as possible. This Privacy Policy document contains types of data that are collected, used, and recorded by Jupiter.\nThe Jupiter Interface backed by Block Raccoon S.A., a company incorporated in Panama, which is the controller for your Personal Data within the scope of this Privacy Policy. Jupiter decides “why” and “how” your Personal Data is processed in connection with the Interface. If you have additional questions or require more information about this Privacy Policy, do not hesitate to contact privacy@jup.ag.\nThis Privacy Policy applies only to the Interface activities and is valid for participants who are visitors to the Interface with regards to the Personal Data that they share and/or which is collected within Jupiter Interface. This Privacy Policy is not applicable to any Personal Data collected offline or via channels other than the Interface. Please read this Privacy Policy carefully to understand our policies and practices regarding your data and how it will be treated by the Interface.\nIF YOU DO NOT HAVE THE RIGHT, POWER AND AUTHORITY TO ACT ON BEHALF OF AND BIND THE BUSINESS, ORGANIZATION, OR OTHER ENTITY YOU REPRESENT, PLEASE DO NOT ACCESS OR OTHERWISE USE THE INTERFACE. IF YOU ARE INTERESTED IN HOW WE USE COOKIES AND YOU CAN CHANGE YOUR COOKIE CHOICE, PLEASE SEE SECTION 5 “COOKIES AND AUTOMATICALLY-COLLECTED DATA”\n​1. Changes to this Agreement\nIf our data processing practices change, we will update this Privacy Policy accordingly to let you know of them upfront and give you a possibility to either provide your consent, object to a particular processing, or undertake other action you are entitled to under the Regulation. Please keep track of any changes we may introduce to this Privacy Policy. Your continued access to and use of the Interface constitutes your awareness of all amendments made to this Privacy Policy as of the date of your accessing and use of the Interface. Therefore, we encourage you to review this Privacy Policy regularly as you shall be bound by it. If, for some reason, you are not satisfied with our personal data processing practices, your immediate recourse is to stop using the Interface. You do not have to inform us of this decision unless you intend to exercise some of the data protection rights stipulated by GDPR and defined below in this Privacy Policy.\n​2. Eligibility\nAge. By accessing our using the Interface, you represent and warrant that you are at least eighteen (18) years of age. If you are under the age of eighteen (18), you may not, under any circumstances or for any reason, use the Interface. Please report to us any instances involving the use of the Interface by individuals under the age of 18, should they come to your knowledge.\n​3. Applicability\nThis Privacy Policy applies to all your interactions with us via the Interface and your interactions with us in connection therewith.\nBelow are the categories of our processors used on the Interface due to an internal data processing roadmap providing a brief grasp of our data processing activities with regard to each piece of the Personal Data we may collect through the Interface, as well as your place in every data processing event. It can be requested at [privacy@jup.ag]. Below are the categories of our processors which can access and process your Personal Data through the Interface:\n\nTechnical maintenance vendors;\nProject and team management vendors;\nCommunication vendors;\nAnalytics, statistics, performance, marketing vendors.\n\n​4. Data processing in connection with the interface\nTypes of Data Collected\nTo the maximum extent possible, Jupiter tries to collect as minimum Personal Data from you as possible. Personal Data we collect:\n\nIP address, MAC address, log files, domain server, data related to usage, performance, website security, traffic patterns, location information, browser and device information – only when you are using the Interface;\nWallet addresses (public blockchain addresses), transaction, and balance information (blockchain data) that is accessible when interacting with the Interface; We use public Blockchain addresses to identify a user’s journey through our product. We group and analyze these user journeys collectively in order to improve our product user experience. We do not use this data for any purpose at an individual user level. The legal basis for this processing is our legitimate interests, such as monitoring and improving the Interface, the proper protection of the Interface against risks, and partly the contract performance basis to provide you the Interface. Note that we are not responsible for your use of any of the blockchain and your data processed in these decentralized and permissionless networks;\nLog Files. Jupiter follows a standard procedure of using log files. These files log visitors when they visit websites. All hosting companies do this and this kind of Personal Data may also be collected as a part of hosting services’ analytics. The data collected by log files include internet protocol (IP) addresses, browser type, Internet Service Provider (ISP), date and time stamp, referring/exit pages, and possibly the number of clicks. These kinds of data may be linked to data that is personally identifiable. The purpose of the data collection and processing is for analyzing trends, administering the website, tracking users’ movement on the website, and gathering demographic information;\n\nJupiter may also engage third-parties advertising platforms that are triggered only when their technical features (so-called “pixels”) are enabled through the Interface. The mentioned third-parties advertising platforms may collect Personal Data of Interface’s visitors only with the purpose to optimize their advertising possibilities through their platforms, target you with their advertisements, and possibly share your data with other advertising platforms and agencies for further use. Jupiter may engage with the mentioned Personal Data of Interfaces visitors.\nIn no event, are we going to ask you to share your private keys or wallet seed. Never trust anyone or any website that asks you to enter your private keys or wallet seed.\nHow and Why we use your Personal Data\nWe may use your Personal Data listed above only for:\n\nOur internal and operational purposes, when: ensuring security, identifying irregular website behavior, preventing fraudulent activity, and improving security at all possible levels;\nAssessing and improving the performance of the Interface;\nAnalyzing our website visitors’ actions to improve our Interface (section “Cookies and Automatically Collected Data”);\nAnalyzing the Interface behavior, including via: Google Analytics (please refer to Google’s Analytics Policy for more information);\nFind and prevent fraud.\n\nTo clear any doubts, we may use Personal Data described above or any other Personal Data:\n\non the basis of contract performance or necessity to enter into a contract (where the Personal Data is required for us to perform our undertakings and obligations in accordance with a contract we are entering into when you use our services, or where we are at the negotiations phase);\non the basis of our or our processors’ legitimate interests to protect the Interface, prevent any malicious and harmful activities to the Interface, maintain our technical systems healthily and secure, improve services and products by using aggregate statistics;\nto respond to legal requests of authorities, provide information upon court orders and judgments, or if we have a good-faith belief that such disclosure is necessary in order to comply with official investigations or legal proceedings initiated by governmental and/or law enforcement officials, or private parties, including but not limited to: in response to subpoenas, search warrants or court orders, and including other similar statutory obligations we or our processors are subjected to;\non the basis of your consent; and\non other legal bases set forth in the personal data protection laws.\n\nDisclosure of Data\nIn continuation of legal bases for collecting and processing the Personal Data, We may disclose any Personal Data about you:\n\nin connection with a merger, division, restructuring, or other association change; or\nto our subsidiaries or affiliates (if any) only if necessary for operational purposes. If we must disclose any of your Personal Data in order to comply with official investigations or legal proceedings initiated by governmental and/or law enforcement officials, we may not be able to ensure that such recipients of your Personal Data will maintain the privacy or security of your Personal Data.\n\nData Retention Period\nJupiter maintains Personal Data exclusively within the time needed to follow prescribed herein legal purposes. When we no longer need Personal Data, the limitation period for storage of such Personal Data has expired, you have withdrawn your consent or objected to our or our processors’ legitimate interests, we securely delete or destroy it unless the statutory requirements we, our processors or other controllers are subjected to stipulate otherwise. Aggregated data, which cannot directly identify a device/browser (or individual) and is used for purposes of reporting and analysis, is maintained for as long as commercially necessary till you object to the processing of such data or withdraw your consent.\nSometimes legal requirements oblige us to retain certain data, for specific purposes, for an extended period of time. Reasons we might retain some data for longer periods of time include:\n\nSecurity, fraud & abuse prevention;\nFinancial monitoring and record-keeping;\nComplying with legal or regulatory requirements;\nEnsuring the continuity of your interaction with the Interface.\n\nYour Inquiries\nYou may contact us by email at the following email address: [privacy@jup.ag]; We use the data that you provide in an email to us, which you may give voluntarily, only in order to answer your question or to reply to your email in the best possible manner.\n​5. Cookies and Automatically Collected Data\nAs you navigate through and interact with our Interface, we may ask your consent to use cookies, which are small files placed on the hard drive/browser of your computer or mobile device, and web beacons, which are small electronic files located on pages of the Interface, to collect certain information about devices you use, browsing actions, and patterns.\nThe data automatically collected from cookies and web beacons may include information about your web browser (such as browser type and browser language) and details of your visits to the Interface, including traffic data, location data and logs, page views, length of visit, and website navigation paths as well as information about your device and internet connection, including your IP address and how you interact with the Interface. We collect this data in order to help us improve the Interface and interaction with it.\nThe information we collect automatically may also include statistical and performance information arising from your use of the Interface. This type of data will only be used by us in an aggregated and pseudonymized manner.\nYou can choose to disable cookies through your individual browser options. To get more detailed information about cookie management with specific web browsers, please find it on the browsers’ respective websites:\n\nFor Google Chrome browser please refer to these instructions: https://support.google.com/accounts/answer/32050?co=GENIE.Platform%3DDesktop&hl=en;\nFor Firefox browser please look up here: https://support.mozilla.org/en-US/kb/clear-cookies-and-site-data-firefox\nFor Safari browser please visit: https://support.apple.com/ru-ru/guide/safari/sfri11471/mac\nFor Internet Explorer browser please refer to: https://support.microsoft.com/en-us/windows/delete-and-manage-cookies-168dab11-0753-043d-7c16-ede5947fc64d\n\n​6. Your rights under GDPR\nUnder certain circumstances, you may have a number of privacy rights concerning the use, storage, and processing of your Personal Data (e.g., the right to delete your data). Here is a list of privacy rights:\n\nright to be informed - we are publishing this Privacy Policy to keep you informed as to what we do with your Personal Data. You can ask us for Personal Data regarding you that we keep at any time. This information concerns, among other things, the data categories we process, for what purposes we process them, the origin of the data if we did not acquire them directly from you and, if applicable, the recipients to who we have sent your data.\nright of access – You may ask us whether we process your Personal Data and you have the right to request a copy of the data we hold about you.\nright of rectification – You have the right to correct inaccurate or incomplete data about you.\nright to be forgotten – You can ask for the Personal Data that we hold about you to be erased from our system and we will comply with this request unless we have a legitimate reason, legal requirement, and other statutory basis not to do so. Even if we can delete (erase) the Personal Data subject to our active (ongoing) processing activities and cease its processing, we will nevertheless retain this particular Personal Data in our backup and archive storages to fulfill our statutory and other requirements.\nright to restriction of processing – where certain conditions apply, you can ask us to ‘block’ the processing of your Personal Data.\nright to data portability – You have the right to have the data we hold about you transferred to another organization and to receive Personal Data in a structured, commonly used format. Please apply to: [privacy@jup.ag] to find out whether we currently support the provision of the portable file containing Personal Data we process about you.\nright to object - You can object to the processing of your data by applying to: [privacy@jup.ag] at any time for reasons that arise from your special situation provided the data processing is based on our legitimate interest or that of a third party, or where we carry out profiling, use machine learning or automated decision-making algorithms. In this case, we will no longer process your Personal Data. The latter does not apply if we are able to prove there are compelling, defensible reasons for the processing that outweigh your interests or we require your data to assert, exercise, or defend legal claims.\nright to withdraw consent - withdraw the consent you gave us with regard to the processing of your Personal Data for certain purposes.\nright to complain - we take your rights very seriously. However, if you are of the opinion that we have not dealt with your complaints adequately, you have the right to submit a complaint to the data privacy protection authorities responsible. You can send your complaints to the EEA supervisory authority of your country of residence.\n\nPlease email: [privacy@jup.ag] with any questions about exercising any of the above rights. If You wish to learn more about the GDPR and Your rights, the Information Commissioner’s Office website is a reliable source.\n​7. Privacy of children\nOur Interface is not directed to collect any data from people under the age of 18. We do not knowingly allow anyone under 18 years old to submit any data to our Interface. If you believe your child may have provided us with their data, you can contact us using the information in this Policy and we will delete the data from our Interface.\n​8. Transfer of Personal Data\nTransfers to third countries shall be made subject to appropriate safeguards, namely Standard Contractual Clauses adopted by the supervisory authority and approved by the Commission. Copy of the foregoing appropriate safeguards may be obtained by you upon a prior written request sent. We may instruct you on further steps to be taken with the purpose of obtaining such a copy, including your obligation to assume confidentiality commitments in connection with being disclosed the Jupiter proprietary and personal information of third parties as well as terms of their relationships with Jupiter.\nKeep in mind that the use of the Interface based on public blockchains is intended to immutably record transactions across wide networks of computer systems. Many blockchains are open to forensic analysis which can lead to deanonymization and the unintentional revelation of Personal Data, in particular when blockchain data is combined with other data. Because blockchains are decentralized or third-party networks that are not controlled or operated by us, we are not able to erase, modify, or alter Personal Data from such networks.\n​9. Data Integrity & Security of Processing\nWe take data security very seriously. We work hard to protect the Personal Data you provide us from loss, misuse, or unauthorized access. We utilize a variety of safeguards such as encryption, digital and physical access controls, non-disclosure agreements, and other technical and organizational measures to protect the Personal Data submitted to us, both during transmission and once it is at rest.\nPlease note that no electronic transmission, storage, or processing of Personal Data can be entirely secure. We cannot guarantee that the security measures we have in place to safeguard Personal Data will never be defeated or fail, or that those measures will always be sufficient or effective. Therefore, although we are committed to protecting your privacy, we do not promise, and you should not expect that your Personal Data will always remain private or secure.\n​10. Supervisory authority oversight\nIf you are a data subject whose data we process, you may also have the right to lodge a complaint with a data protection regulator in one or more of the European Union member states. Here you can find a list of data protection authorities in Europe: ​​https://edpb.europa.eu/about-edpb/about-edpb/members_enWas this page helpful?","tokens":4526,"squid":"spider-02","role":"Liquidity Spider","at":1791338867041,"hash":"d54f2f41dbf5f081aa4369128ace717f5ae68026"}
{"url":"https://consensysdiligence.github.io/smart-contract-best-practices/attacks/denial-of-service/","domain":"consensysdiligence.github.io","title":"Denial of Service - Ethereum Smart Contract Best Practices","text":"Denial of Service\n\nDoS with (Unexpected) revert¶\nConsider a simple auction contract:\n// INSECURE\ncontract Auction {\n address currentLeader;\n uint highestBid;\n\n function bid() payable {\n require(msg.value > highestBid);\n\n require(currentLeader.send(highestBid)); // Refund the old leader, if it fails then revert\n\n currentLeader = msg.sender;\n highestBid = msg.value;\n }\n}\n\nIf attacker bids using a smart contract which has a fallback function that reverts any payment, the\nattacker can win any auction. When it tries to refund the old leader, it reverts if the refund\nfails. This means that a malicious bidder can become the leader while making sure that any refunds\nto their address will always fail. In this way, they can prevent anyone else from calling the\nbid() function, and stay the leader forever. A recommendation is to set up a\npull payment system instead, as\ndescribed earlier.\nAnother example is when a contract may iterate through an array to pay users (e.g., supporters in a\ncrowdfunding contract). It's common to want to make sure that each payment succeeds. If not, one\nshould revert. The issue is that if one call fails, you are reverting the whole payout system,\nmeaning the loop will never complete. No one gets paid because one address is forcing an error.\naddress[] private refundAddresses;\nmapping (address => uint) public refunds;\n\n// bad\nfunction refundAll() public {\n for(uint x; x < refundAddresses.length; x++) { // arbitrary length iteration based on how many addresses participated\n require(refundAddresses[x].send(refunds[refundAddresses[x]])) // doubly bad, now a single failure on send will hold up all funds\n }\n}\n\nAgain, the recommended solution is to\nfavor pull over push payments.\nSee SWC-113\nDoS with Block Gas Limit¶\nEach block has an upper bound on the amount of gas that can be spent, and thus the amount\ncomputation that can be done. This is the Block Gas Limit. If the gas spent exceeds this limit, the\ntransaction will fail. This leads to a couple of possible Denial of Service vectors:\nGas Limit DoS on a Contract via Unbounded Operations¶\nYou may have noticed another problem with the previous example: by paying out to everyone at once,\nyou risk running into the block gas limit.\nThis can lead to problems even in the absence of an intentional attack. However, it's especially\nbad if an attacker can manipulate the amount of gas needed. In the case of the previous example,\nthe attacker could add a bunch of addresses, each of which needs to get a very small refund. The\ngas cost of refunding each of the attacker's addresses could, therefore, end up being more than the\ngas limit, blocking the refund transaction from happening at all.\nThis is another reason to\nfavor pull over push payments.\nIf you absolutely must loop over an array of unknown size, then you should plan for it to\npotentially take multiple blocks, and therefore require multiple transactions. You will need to\nkeep track of how far you've gone, and be able to resume from that point, as in the following\nexample:\nstruct Payee {\n address addr;\n uint256 value;\n}\n\nPayee[] payees;\nuint256 nextPayeeIndex;\n\nfunction payOut() {\n uint256 i = nextPayeeIndex;\n while (i < payees.length && gasleft() > 200000) {\n payees[i].addr.send(payees[i].value);\n i++;\n }\n nextPayeeIndex = i;\n}\n\nYou will need to make sure that nothing bad will happen if other transactions are processed while\nwaiting for the next iteration of the payOut() function. So only use this pattern if absolutely\nnecessary.\nGas Limit DoS on the Network via Block Stuffing¶\nEven if your contract does not contain an unbounded loop, an attacker can prevent other\ntransactions from being included in the blockchain for several blocks by placing computationally\nintensive transactions with a high enough gas price.\nTo do this, the attacker can issue several transactions which will consume the entire gas limit,\nwith a high enough gas price to be included as soon as the next block is mined. No gas price can\nguarantee inclusion in the block, but the higher the price is, the higher is the chance.\nIf the attack succeeds, no other transactions will be included in the block. Sometimes, an\nattacker's goal is to block transactions to a specific contract prior to specific time.\nThis attack was conducted on Fomo3D, a\ngambling app. The app was designed to reward the last address that purchased a \"key\". Each key\npurchase extended the timer, and the game ended once the timer went to 0. The attacker bought a key\nand then stuffed 13 blocks in a row until the timer was triggered and the payout was released.\nTransactions sent by attacker took 7.9 million gas on each block, so the gas limit allowed a few\nsmall \"send\" transactions (which take 21,000 gas each), but disallowed any calls to the buyKey()\nfunction (which costs 300,000+ gas).\nA Block Stuffing attack can be used on any contract requiring an action within a certain time\nperiod. However, as with any attack, it is only profitable when the expected reward exceeds its\ncost. The cost of this attack is directly proportional to the number of blocks which need to be\nstuffed. If a large payout can be obtained by preventing actions from other participants, your\ncontract will likely be targeted by such an attack.\nSee SWC-128","tokens":1312,"squid":"spider-06","role":"Security Spider","at":1791338884776,"hash":"ba6bbcd0656b9a86187ac48103a3cf41ab7c337f"}
{"url":"https://developers.jup.ag/docs/legal/terms-of-use","domain":"developers.jup.ag","title":"Terms of Use - Jupiter Developers","text":"Jupiter, https://jup.ag, a website-hosted user interface (the “Interface”) made available by Block Raccoon S.A.\nThe Interface is a visual representation of Jupiter protocol (the “Protocol”) which comprises open source software deployed in a permissionless manner by Block Raccoon S.A. The Interface provides an interface which allows users to view and administer their interactions with the Protocol.\nThese Terms of Use and any terms and conditions incorporated herein by reference (collectively, the “Terms”) govern your access to and use of the Interface. You must read the Terms carefully.\nTo make these Terms easier to read:\n\nBlock Raccoon S.A.is referred to as “Jupiter”, “we”, “us”, “our” or “the Company”.\n“You”, “your” and “user(s)” refers to anybody who accesses or uses, in any way, the Interface. If you are accessing or using the Interface on behalf of a company (such as your employer) or other legal entity, you represent and warrant that you have the authority to bind that entity to these Terms and, in that case, “you”, “your” or “user(s)” will refer to that entity.\n\nBy accessing, browsing, or otherwise using the Interface, or by acknowledging agreement to the Terms on the Interface, you agree that you have read, understood, and accepted all of the Terms and our Privacy Policy (the “Privacy Policy”), which is incorporated by reference into the Terms.\nIMPORTANT NOTE REGARDING ARBITRATION: WHEN YOU AGREE TO THESE TERMS BY USING OR ACCESSING THE INTERFACE, YOU ARE AGREEING TO RESOLVE ANY DISPUTE BETWEEN YOU AND JUPITER THROUGH BINDING, INDIVIDUAL ARBITRATION RATHER THAN IN COURT. AND YOU AGREE TO A CLASS ACTION WAIVER, BOTH OF WHICH IMPACT YOUR RIGHTS AS TO HOW DISPUTES ARE RESOLVED.\nIf you come up with any further questions, please, dont be shy and feel free to contact us at legal@jup.ag.\n​1. Eligibility\nGeneral. You may not use the Interface if you are otherwise barred from using the Interface under applicable law.\nLegality. You are solely responsible for adhering to all laws and regulations applicable to you and your use or access to the Interface. Your use of the Interface is prohibited by and otherwise violate or facilitate the violation of any applicable laws or regulations, or contribute to or facilitate any illegal activity.\nThe Interface and each of the Company’s services does not constitute, and may not be used for the purposes of, an offer or solicitation to anyone in any jurisdiction in which such offer or solicitation is not authorised, or to any person to whom it is unlawful to make such an offer or solicitation.\nBy using or accessing the Interface, you represent to us that you are not subject to sanctions or otherwise designated on any list of prohibited or restricted parties or excluded or denied persons, including but not limited to the lists maintained by the United Nations Security Council, the European Union or its Member States, or any other government authority.\nWe make no representations or warranties that the information, products, or services provided through our Interface, are appropriate for access or use in other jurisdictions. You are not permitted to access or use our Interface in any jurisdiction or country if it would be contrary to the law or regulation of that jurisdiction or if it would subject us to the laws of, or any registration requirement with, such jurisdiction. We reserve the right to limit the availability of our Interface to any person, geographic area, or jurisdiction, at any time and at our sole and absolute discretion.\nProhibited Localities. Jupiter does not interact with digital wallets located in, established in, or a resident of the United States, the Republic of China, Singapore, Myanmar (Burma), Cote D’Ivoire (Ivory Coast), Cuba, Crimea and Sevastopol, Democratic Republic of Congo, Iran, Iraq, Libya, Mali, Nicaragua, Democratic People’s Republic of Korea (North Korea), Somalia, Sudan, Syria, Yemen, Zimbabwe or any other state, country or region that is subject to sanctions enforced by the United States, the United Kingdom or the European Union. You must not use any software or networking techniques, including use of a Virtual Private Network (VPN) to modify your internet protocol address or otherwise circumvent or attempt to circumvent this prohibition.\nNon-Circumvention. You agree not to access the Interface using any technology for the purposes of circumventing these Terms.\n​2. Compliance Obligations\nThe Interface may not be available or appropriate for use in all jurisdictions. By accessing or using the Interface, you agree that you are solely and entirely responsible for compliance with all laws and regulations that may apply to you. You further agree that we have no obligation to inform you of any potential liabilities or violations of law or regulation that may arise in connection with your access and use of the Interface and that we are not liable in any respect for any failure by you to comply with any applicable laws or regulations.\n​3. Access to the Interface\nWe reserve the right to disable access to the Interface at any time in the event of any breach of the Terms, including without limitation, if we, in our sole discretion, believe that you, at any time, fail to satisfy the eligibility requirements set forth in the Terms. Further, we reserve the right to limit or restrict access to the Interface by any person or entity, or within any geographic area or legal jurisdiction, at any time and at our sole discretion. We will not be liable to you for any losses or damages you may suffer as a result of or in connection with the Interface being inaccessible to you at any time or for any reason.\nThe Interface and the Protocol may rely on or utilise a variety of external third party services or software, including without limitation oracles, decentralised cloud storage services, analytics tools, hence the Interface or the Protocol may be adversely affected by any number of risks related to these third party services/software. These may include technical interruptions, network congestion/failure, security vulnerabilities, cyberattacks, or malicious activity. Access to the Interface or the Protocol may become degraded or unavailable during times of significant volatility or volume. This could result in the inability to interact with third-party services for periods of time and may also lead to support response time delays. The Company cannot guarantee that the Interface or the Protocol will be available without interruption and neither does it guarantee that requests to interact with third-party services will be successful. You agree that you shall not hold the Company responsible for any losses which occur due to any of the foregoing.\n​4. Your Use of Interface\nBy using or accessing the Interface, you represent and warrant that you understand that there are inherent risks associated with virtual currency, and the underlying technologies including, without limitation, cryptography and blockchain, and you agree that Jupiter is not responsible for any losses or damages associated with these risks. You specifically acknowledge and agree that the Interface facilitates your interaction with decentralized networks and technology and, as such, we have no control over any blockchain or virtual currencies and cannot and do not ensure that any of your interactions will be confirmed on the relevant blockchain and do not have the ability to effectuate any cancellation or modification requests regarding any of your interactions.\nWithout limiting the foregoing, you specifically understand and hereby represent your acknowledgment of the following:\n\nThe pricing information data provided through the Interface does not represent an offer, a solicitation of an offer, or any advice regarding, or recommendation to enter into, a transaction with the Interface.\nThe Interface does not act as an agent for any of the users.\nThe Interface does not own or control any of the underlying software through which blockchain networks are formed, and therefore is not responsible for them and their operation.\nYou are solely responsible for reporting and paying any taxes applicable to your use of the Interface.\nAlthough it is intended to provide accurate and timely information on the Interface, the Interface or relevant tools may not always be entirely accurate, complete, or current and may also include technical inaccuracies or typographical errors. Accordingly, you should verify all information before relying on it, and all decisions based on information contained on the Interface or relevant tools are your sole responsibility.\n\nIn order to allow other users to have a full and positive experience of using the Interface you agree that you will not use the Interface in a manner that:\n\nBreaches the Terms;\nInfringes on or violates any copyright, trademark, service mark, patent, right of publicity, right of privacy, or other proprietary or intellectual property rights under the law;\nSeeks 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, the deployment of viruses and denial of service attacks;\nAttempts, in any manner, to obtain the private key, password, account, or other security information from any other user, including such information about the digital wallet;\nDecompiles, reverse engineer, or otherwise attempt to obtain the source code or underlying ideas or information of or relating to the Interface;\nSeeks to defraud us or any other person or entity, including, but not limited to, providing any false, inaccurate, or misleading information in order to unlawfully obtain the property of another;\nViolates any applicable law, rule, or regulation concerning the integrity of trading markets, including, but not limited to, the manipulative tactics commonly known as spoofing and wash trading;\nViolates any applicable law, rule, or regulation of the United States or another relevant jurisdiction, including, but not limited to, the restrictions and regulatory requirements imposed by U.S. law;\nDisguises or interferes in any way with the IP address of the computer you are using to access or use the Interface or that otherwise prevents us from correctly identifying the IP address of the computer you are using to access the Interface;\nTransmits, exchanges, or is otherwise supported by the direct or indirect proceeds of criminal or fraudulent activity;\nContributes to or facilitates any of the foregoing activities.\n\nAs it has been already stated, we only provide you with the relevant interface and software and neither has control over your interactions with the blockchain nor encourages you to perform any. Any interaction performed by you via the Interface remains your sole responsibility.\nAll information provided in connection with your access and use of the Interface 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 Interface or any other information that we make available at any time, including, without limitation, blog posts, articles, links to third-party content, news feeds, tutorials, tweets, and videos. Before you make any financial, legal, or other decisions involving the Interface, you should seek independent professional advice from an individual who is licensed and qualified in the area for which such advice would be appropriate.\nThe 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 eliminated. You further agree that the only duties and obligations that we owe you are those set forth expressly in the Terms.\nYou understand that smart contract protocols such as the Protocol simply comprise a set of autonomous blockchain-based smart contracts deployed on the relevant blockchain network, operated directly by users calling functions on it (which allows them to interact with other users in a multi-party peer-to-peer manner). There is no further control by or interaction with the original entity which had deployed the smart contract, which entity solely functions as a provider of technical tools for users, and is not offering any sort of securities product or regulated service nor does it hold any user assets on custody. Any rewards earned by user interactions arise solely out of their involvement in the protocol by taking on the risk of interacting with other users and the ecosystem.\n​5. Non-custodial nature of Interface and Protocol\nThe Interface and Protocol are non-custodial in nature, therefore neither holds or controls your digital assets. Any digital assets which you may acquire through the usage of the Interface or the Protocol will be held and administered solely by you through your selected electronic wallet, and we shall have no access to or responsibility in regard to such electronic wallet or digital asset held therein. It is solely your responsibility to select the wallet service provider to use, and your use of such electronic wallet will be subject to the governing terms of use or privacy policy of the provider of such wallet. We neither own nor control your selected electronic wallet service, the relevant blockchain network, or any other third party site, product, or service that you might access, visit, or use for the purpose of enabling you to utilise the Interface or the Protocol. We will not be liable for the acts or omissions of any such third parties, nor will we be liable for any damage that you may suffer as a result of your transactions or any other interaction with any such third parties.\nWe will not create any hosted wallet for you or otherwise custody digital assets on your behalf, and it is your sole responsibility to maintain the security of your selected electronic wallet. You hereby irrevocably waive, release and discharge all claims, whether known or unknown to you, against us, our affiliates and their respective shareholders, members, directors, officers, employees, agents and representatives related to your use of any wallet software, associated loss of digital assets, transaction failures, or any other defects that arise in the course of your use of your electronic wallet, including any losses that may obtain as a result of any failure of the Interface or the Protocol.\nNeither the Company, the Interface nor the Protocol provides any digital asset exchange or portfolio/fund management services. If you choose to engage in transactions with other users via the Interface or the Protocol, then such decisions and transactions and any consequences flowing therefrom are your sole responsibility. In no event shall the Company, its affiliates or their respective directors or employees be responsible or liable to you or anyone else, directly or indirectly, for any damage or loss arising from or relating to any interaction or continued interaction with the Interface or the Protocol or in reliance on any information provided on the Interface (including, without limitation, directly or indirectly resulting from errors in, omissions of or alterations to any such information).\n“Know Your Customer” and “Anti-Money Laundering” checks We reserve the right to conduct “Know Your Customer” and “Anti-Money Laundering” checks on you if deemed necessary by us (at our sole discretion) or such checks become required under applicable laws in any jurisdiction. Upon our request, you shall immediately provide us with information and documents that we, in our sole discretion, deem necessary or appropriate to conduct “Know Your Customer” and “Anti-Money Laundering” checks. Such documents may include, but are not limited to, passports, driver’s licenses, utility bills, photographs of associated individuals, government identification cards or sworn statements before notaries or other equivalent professionals. Notwithstanding anything herein, we may, in its sole discretion, refuse to provide access to the Interface to you until such requested information is provided, or in the event that, based on information available to us, you are suspected of using the Interface or the Protocol in connection with any money laundering, terrorism financing, or any other illegal activity. In addition, we shall be entitled to use any possible efforts for preventing money laundering, terrorism financing or any other illegal activity, including without limitation blocking of your access to the Interface or the Protocol, or providing your information to any regulatory authority.\n​6. Disclaimers\nYou understand and agree that the Interface enables access to an online, decentralized, and autonomous protocol and environment, and associated decentralized networks, that are not controlled by Jupiter. We do not have access to your private key and cannot initiate an interaction with your virtual currency or otherwise access your virtual currency. We are not responsible for any activities that you engage in when using your wallet, or the Interface.\nJupiter cannot and does not represent or guarantee that any of the information available through the Interface is accurate, reliable, current, complete or appropriate for your needs. The information displayed through the Interface including information about prices is provided by third parties and/or calculated for informational purposes. Your use of any third-party scripts, indicators, ideas, and other content is at your sole risk.\nYou expressly understand and agree that your use of the Interface is at your sole risk. We make and expressly disclaim all representations and warranties, express, implied or statutory, and with respect to the Interface and the code proprietary or open-source, we specifically do not represent and warrant and expressly disclaim any representation or warranty, express, implied or statutory, including without limitation, any representations or warranties of title, non-infringement, merchantability, usage, security, suitability or fitness for any particular purpose, or as to the workmanship or technical coding thereof, or the absence of any defects therein, whether latent or patent. We do not represent or warrant that the Interface, code, and any related information are accurate, complete, reliable, current, or error-free. The Interface is provided on an “as is” and “as available” basis, without warranties of any kind, either express or implied, including, without limitation, implied warranties of merchantability, fitness for a particular purpose, or non-infringement.\nYou acknowledge that no advice, information, or statement that we make should be treated as creating any warranty concerning the Interface. We do not endorse, guarantee, or assume responsibility for any advertisements, offers, or statements made by third parties concerning the Interface. You acknowledge that Jupiter is not responsible for transferring, safeguarding, or maintaining your private keys or any virtual currency associated therewith. If you lose, mishandle, or have stolen associated virtual currency private keys, you acknowledge that you may not be able to recover associated virtual currency and that Jupiter is not responsible for such loss. You acknowledge that Jupiter is not responsible for any loss, damage, or liability arising from your failure to comply with the terms hereunder.\nBy accessing and using the Interface, you represent that you understand (a) the Interface facilitates access to the Protocol, the use of which has many inherent risks, and (b) the cryptographic and blockchain-based systems have inherent risks to which you are exposed when using the Interface. You further represent that you have a working knowledge of the usage and intricacies of blockchain-based digital assets, including, without limitation, SPL token standard available on the Solana blockchain. You further understand that the markets for these blockchain-based digital assets are highly volatile due to factors that include, but are not limited to, adoption, speculation, technology, security, and regulation. You acknowledge that the cost and speed of transacting with blockchain-based systems, such as Solana, are variable and may increase or decrease, respectively, drastically at any time. You hereby acknowledge and agree that we are not responsible for any of these variables or risks associated with the Protocol and cannot be held liable for any resulting losses that you experience while accessing or using the Interface. Accordingly, you understand and agree to assume full responsibility for all of the risks of accessing and using the Interface to interact with the Protocol.\nThe Interface may contain references or links to third-party resources, including, but not limited to, information, materials, products, or services, that we do not own or control. In addition, third parties may offer promotions related to your access and use of the Interface. We do not endorse or assume any responsibility for any such resources or promotions. If you access any such resources or participate in any such promotions, you do so at your own risk, and you understand that the Terms do not apply to your dealings or relationships with any third parties. You expressly relieve us of any and all liability arising from your use of any such resources or participation in any such promotions.\n​7. Intellectual Proprietary Rights\nWe own all intellectual property and other rights in the Interface and its contents, including, but not limited to, software, text, images, trademarks, service marks, copyrights, patents, and designs. Unless expressly authorized by us, you may not copy, modify, adapt, rent, license, sell, publish, distribute, or otherwise permit any third party to access or use the Interface or any of its contents. Accessing or using the Interface does not constitute a grant to you of any proprietary intellectual property or other rights in the Interface or its contents.\nYou will retain ownership of all intellectual property and other rights in any information and materials you submit through the Interface. However, by uploading such information or materials, you grant us a worldwide, royalty-free, irrevocable license to use, copy, distribute, publish and send this data in any manner in accordance with applicable laws and regulations.\nYou may choose to submit comments, bug reports, ideas, or other feedback about the Interface, including, without limitation, about how to improve the Interface (collectively, “Feedback”). By submitting any Feedback, you agree that we are free to use such Feedback at our discretion and without additional compensation to you, and to disclose such Feedback to third parties (whether on a non-confidential basis or otherwise). If necessary under applicable law, then you hereby grant us a perpetual, irrevocable, non-exclusive, transferable, worldwide license under all rights necessary for us to incorporate and use your Feedback for any purpose.\nIf (i) you satisfy all of the eligibility requirements set forth in the Terms, and (ii) your access to and use of the Interface complies with the Terms, you hereby are granted a single, personal, limited license to access and use the Interface. This license is non-exclusive, non-transferable, and freely revocable by us at any time without notice or cause in our sole discretion. Use of the Interface for any purpose not expressly permitted by the Terms is strictly prohibited.\nIn the event that you utilise any intellectual property in any manner which infringes on the rights of any party (including by unauthorised incorporation of the same in any project, protocol, code or any digital token), the Company reserves the sole discretion to effectuate the takedown of any such project, protocol, code or any digital token (or underlying intellectual property) at any time, without notice, compensation or payment to you. In addition, and without prejudice to the Company’s other remedies under this Agreement, you shall indemnify the Company and its officers, directors, employees, contractors, agents, affiliates, and subsidiaries from and against all claims, damages, obligations, losses, liabilities, costs, and expenses arising from your aforesaid infringement of intellectual rights.\n​8. Indemnification\nYou agree to hold harmless, release, defend, and indemnify us and our officers, directors, employees, contractors, agents, affiliates, and subsidiaries from and against all claims, damages, obligations, losses, liabilities, costs, and expenses arising from (a) your access to and use of the Interface; (b) your violation of these Terms, the right of any third party, or any other applicable law, rule, or regulation; and (c) any other party’s access and use of the Interface with your assistance or using any device or account that you own or control.\n​9. Limitation of Liability\nUnder no circumstances shall we or any of our officers, directors, employees, contractors, agents, affiliates, or subsidiaries be liable to you for any indirect, punitive, incidental, special, consequential, or exemplary damages, including (but not limited to) damages for loss of profits, goodwill, use, data, or other intangible property, arising out of or relating to any access to or use of the Interface, nor will we be responsible for any damage, loss, or injury resulting from hacking, tampering, or other unauthorized access to or use of the Interface, or from any access to or use of any information obtained by any unauthorized access to or use of the Interface. We assume no liability or responsibility for any: (a) errors, mistakes, or inaccuracies of content; (b) personal injury or property damage, of any nature whatsoever, resulting from any access to or use of the Interface; (c) unauthorized access to or use of any secure server or database in our control or the use of any information or data stored therein; (d) interruption or cessation of function related to the Interface; (e) bugs, viruses, trojan horses, or the like that may be transmitted to or through the Interface; (f) errors or omissions in, or loss or damage incurred as a result of, the use of any content made available through the Interface; and (g) the defamatory, offensive, or illegal conduct of any third party. Under no circumstances shall we or any of our officers, directors, employees, contractors, agents, affiliates, or subsidiaries be liable to you for any claims, proceedings, liabilities, obligations, damages, losses, or costs in an amount exceeding the greater of (i) the amount you paid to us in exchange for access to and use of the Interface, or (ii) $100.00. This limitation of liability applies regardless of whether the alleged liability is based on contract, tort, negligence, strict liability, or any other basis, and even if we have been advised of the possibility of such liability. Some jurisdictions do not allow the exclusion of certain warranties or the limitation or exclusion of certain liabilities and damages. Accordingly, some of the disclaimers and limitations set forth in the Terms may not apply to you. This limitation of liability shall apply to the fullest extent permitted by law.\n​10. Arbitration and Class Action Waiver​\nBinding Arbitration. Except for disputes in which either party seeks to bring an individual action in small claims court or seeks injunctive or other equitable relief for the alleged unlawful use of copyrights, trademarks, trade names, logos, trade secrets or patents, you and the Jupiter: (a) waive the right to have any and all disputes or claims arising from these Terms, your use or access to the Interface or any other disputes with the Jupiter (collectively, “Disputes”) resolved in a court; and (b) waive any right to a jury trial. Instead, you and the Jupiter agree to arbitrate Disputes that are not resolved informally (as described below) through binding arbitration (i.e. the referral of a Dispute to one or more persons charged with reviewing the Dispute and making a final and binding determination to resolve it) instead of having the Dispute decided by a judge or jury in court).\nNo Class Arbitrations, Class Actions or Representative Actions. You and Jupiter agree that any dispute is personal to you and Jupiter and that any such dispute will be resolved solely through individual arbitration and will not be brought as a class arbitration, class action, or any other type of representative proceeding. Neither party agrees to class arbitration or to an arbitration in which an individual attempts to resolve a dispute as a representative of another individual or group of individuals. Further, you and the Jupiter agree that a dispute cannot be brought as a class, or other types of representative action, whether within or outside of arbitration, or on behalf of any other individual or group of individuals.\nProcess. You and the Jupiter agree that each will notify the other, in writing, of any Dispute within thirty (30) days of when it arises so that the parties can attempt, in good faith, to resolve the Dispute informally. Notice to Jupiter shall be provided by sending an email to legal@jup.ag. Your notice must include (1) your name, postal address, and email address; (2) a description of the nature or basis of the Dispute; and (3) the specific action that you are seeking. If you and the Jupiter cannot resolve the Dispute within thirty (30) days of the Jupiter receiving the notice, either you or Jupiter may, as appropriate pursuant to this Section 12, commence an arbitration proceeding. You and Jupiter agree that any arbitration or claim must be commenced or filed within one (1) year after the Dispute arose; otherwise, you and the Jupiter agree that the claim is permanently barred (which means that you will no longer have the right to assert a claim regarding the Dispute).\nChoice of Law. These Terms are governed by and will be construed under the laws of Panama, without regard to principles of conflict of laws, govern the Terms and any Dispute between you and us. Any Dispute under these Terms shall be finally settled by Binding Arbitration (as defined below). Any unresolved Dispute arising out of or in connection with these Terms shall be referred to and finally resolved by arbitration under the rules of the London Court of International Arbitration (LCIA), which rules are deemed to be incorporated by reference into this Section 12 to the extent they are consistent with it. Any dispute arising from or relating to the subject matter of these Terms shall be finally settled in London, United Kingdom, in English, in accordance with the LCIA Arbitration Rules. Unless we agree otherwise, the arbitrator may not consolidate your claims with those of any other party. Any judgment on the award rendered by the arbitrator may be entered in any court of competent jurisdiction, to the extent a court therein would be deemed to be a court of competent jurisdiction other than any court located in the United States of America. You further agree that the Interface shall be deemed to be based solely in Panama and that, although the Interface may be available in other jurisdictions, its availability does not give rise to general or specific personal jurisdiction in any forum outside Panama.\nAuthority of Arbitrator. As limited by these Terms and applicable arbitration rules, the arbitrator will have: (a) the exclusive authority and jurisdiction to make all procedural and substantive decisions regarding a Dispute; and (b) the authority to grant any remedy that would otherwise be available in court. The arbitrator may only conduct an individual arbitration and may not consolidate more than one individual s claims, preside over any type of class or representative proceeding or preside over any proceeding involving more than one individual.\n​11. Miscellaneous\nChanges. We may amend any portion of these Terms at any time by posting the revised version of these Terms with an updated revision date. The changes will become effective and shall be deemed accepted by you, the first time you use or access the Interface after the initial posting of the revised Terms and shall apply on a going-forward basis with respect to your use of the Interface including any transactions initiated after the posting date. In the event that you do not agree with any such modification, your sole and exclusive remedy are to terminate your use of the Interface.\nEntire Agreement. These Terms (and any additional terms, rules, and conditions of participation that may be posted on the website of Jupiter) including the Privacy Policy constitute the entire agreement with respect to the Interface and supersedes any prior agreements, oral or written.\nPrivacy Policy. The Privacy Policy describes the ways we collect, use, store and disclose your personal information. You agree to the collection, use, storage, and disclosure of your data in accordance with the Privacy Policy.\nSeverability. If any provision of these Terms shall be 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. If such construction is not possible, the invalid or unenforceable portion will be severed from these Terms but the rest of these Terms will remain in full force and effect.\nSurvival. Upon termination of these Terms for any reason, all rights and obligations of the parties that by their nature are continuing will survive such termination.\nEnglish language. Notwithstanding any other provision of these Terms, any translation of these Terms is provided for your convenience. The meanings of terms, conditions, and representations herein are subject to their definitions and interpretations in the English language. In the event of conflict or ambiguity between the English language version and translated versions of these terms, the English language version shall prevail. You acknowledge that you have read and understood the English language version of these Terms.\nIf you have any questions, claims, complaints, or suggestions, please, contact us at legal@jup.ag.Was this page helpful?","tokens":8669,"squid":"spider-02","role":"Liquidity Spider","at":1791338888926,"hash":"be479492fce0f2946c82b1117e58199b26266d1d"}
{"url":"https://www.paradigm.xyz/kryptos/history","domain":"paradigm.xyz","title":"The History of Kryptos: CIA's Unsolved Cipher | Paradigm","text":"KryptosHistoryKryptos CTFThe History of KryptosWatch The Film<198419841988199019982003201020212025Before KryptosJim Sanborn was born in Washington, D.C., in 1945 and got his MFA in sculpture from Pratt in 1971. Sculpture enabled him to learn through building. He built sculptures about the Coriolis effect, the reason whirlpools spin opposite directions across hemispheres. He embedded lodestones and compass roses into granite to make electromagnetic fields visible, including in his 1987 installation Invisible Forces at Courthouse Square in Arlington, Virginia. Another piece at the James Center in Richmond spanned 400 feet in each direction, mimicking ancient stone alignments.Sanborn later said his pre-Kryptos work dealt with \"the secrets of nature\" and what came after dealt with \"the secrecy of man.\"View Kryptos Archive1984–1986: The CIA's New Headquarters BuildingIn the mid-1980s, the CIA was building its New Headquarters Building in Langley, Virginia, and looking for site-specific artwork for the new facility. They wanted something that reflected the intelligence community's actual work: gathering, concealing, and interpreting information.The commission was $250,000. Whatever got built would sit inside one of the most restricted workplaces on earth, seen daily by thousands of intelligence professionals. The CIA partnered with the National Endowment for the Arts to review artist proposals.1988: The CommissionIn 1988, the CIA–NEA panel selected Jim Sanborn's proposal. He pitched \"Kryptos\" (ancient Greek for \"hidden\") as a sculpture with actual encrypted messages. It was both a visual and conceptual work. He wanted an \"alternate reality\" within the CIA campus that featured water, natural materials, and a quiet place to think.Sanborn knew the cryptographic element had to be real. He approached Ed Scheidt, who had just retired as chairman of the CIA's Cryptographic Center, the agency's chief of codes. Over several months, they designed a four-part encrypted text using multiple cipher systems. Each passage used a different method with different complexity, built to resist any single approach. Scheidt rated it nine out of ten for difficulty. He thought it would take five to ten years to solve.Sanborn wrote the plaintext himself. He thought about bringing in a fiction writer but said no: \"Why let someone else in on the secret?\"View Kryptos Archive1989: FabricationSanborn designed a massive S-shaped copper screen that was twelve feet tall and twenty feet long, meant to evoke a piece of paper emerging from a computer printer. He carved 1,736 characters into the copper by hand using a jigsaw, forming four encrypted passages on one half, and a keyed Vigenère alphabet table on the other.The copper screen was one element of a larger installation. Sanborn chose materials native to the United States: polished red granite, quartz, petrified wood, lodestone, copper plate. Petrified wood supports the main screen. Outside the New Headquarters Building entrance, two red granite and copperplate constructions flank the walkway inscribed with Morse code and ancient ciphers. Lodestone (a naturally magnetized rock) sits beside a navigational compass rose, echoing earlier magnetic sculptures he created. The installation also includes a landscaped garden, a fish pond with opposing wooden benches, a reflecting pool, and a triangle-shaped black stone slab.View Kryptos ArchiveNovember 3, 1990: DedicationCIA Director William Webster dedicated Kryptos on Nov. 3, 1990, in the courtyard between two of the CIA's headquarters buildings. At the time of the dedication, Sanborn said he gave Webster the solution, but he later suggested Webster might not have received all of it.View Kryptos Archive1990–1992: Kryptos Goes PublicKryptos drew press attention from the start. Newspapers reported on the commission and dedication, Time magazine covered the sculpture in March 1991, and ABC's World News Tonight interviewed Sanborn that April. In 1992, a transcription of the ciphertext appeared in The Cryptogram, the journal of the American Cryptogram Association, and was posted to the internet newsgroup sci.crypt, giving cryptographers and amateur codebreakers outside the agency their first chance to study it.View Kryptos Archive1992–1993: The NSA Solves First — in SecretIn 1992, CIA Deputy Director Bill Studeman challenged the National Security Agency to crack the CIA's own puzzle. A small NSA team led by Ken Miller took it on, with Dennis McDaniels and two others whose names are still classified. They successfully solved K1, K2, and K3 in a matter of weeks.The team sent a memo to NSA Director Admiral Mike McConnell, who promptly forwarded it to the CIA's Admiral Studeman for a bit of inter-agency bragging. But the achievement stayed classified and was shared only within the intelligence community for the time being.View Kryptos Archive1998: CIA Analyst David Stein Cracks K1–K3 by HandInside the agency, CIA physicist David Stein had been working on the puzzle in his off hours using only a pencil and paper. After more than 400 hours spread across lunch breaks, evenings, and weekends, he finally solved K1, K2, and K3. He called an internal meeting to present his results. Roughly 250 CIA employees showed up.Stein was the first person to solve the passages entirely by hand. His solution circulated within the intelligence community but stayed classified until later.1999: The Public BreakthroughIn 1999, Jim Gillogly, a California computer scientist who specialized in classical ciphers, independently solved K1, K2, and K3 using a Pentium II. He went public with his solution.The CIA then acknowledged David Stein's earlier work and the NSA followed, confirming their team had solved it years before.The decrypted passages dealt with secrecy, discovery, and buried information:K1: \"BETWEEN SUBTLE SHADING AND THE ABSENCE OF LIGHT LIES THE NUANCE OF IQLUSION\" – with \"illusion\" deliberately misspelled. The encryption method used a modified Vigenère cipher with the keyword \"PALIMPSEST.\"K2: It described invisible information gathered using the Earth's magnetic field and transmitted underground to an unknown location. It ended with: \"DOES LANGLEY KNOW ABOUT THIS? THEY SHOULD: IT'S BURIED OUT THERE SOMEWHERE.\" K2 also used a Vigenère cipher, keyword \"ABSCISSA.\"K3: It paraphrased Howard Carter's 1922 account of opening King Tutankhamun's tomb, describing the moment of peering into a sealed chamber and seeing \"wonderful things.\" The encryption method used a transposition cipher.The final passage, however, with 97 characters, resisted them all.View Kryptos Archive2000s: The Legend GrowsDuring the 2000s, Kryptos went from an obscure artwork to a global phenomenon. Professional cryptographers, mathematicians, hobbyists, and artists around the world devoted more and more time to K4.An online group of more than 2,000 members coalesced around cryptologist and game designer Elonka Dunin. She maintained a comprehensive resource page, coordinated information between researchers, and became one of the few civilians to see the sculpture up close.And yet every proposed solution to K4 was wrong. Jim Sanborn confirmed that despite an error in the previously known decryptions of K2 (which he publicly corrected in 2006, changing the last plaintext phrase from \"IDBYROWS\" to \"XLAYERTWO\"), K4 was correctly encoded and contained no errors.Sanborn also started acknowledging the existence of a riddle within the riddle, which could only be solved after the first four sections were solved.2003–2009: Dan Brown and Mass CultureAuthor Dan Brown brought Kryptos to mass culture in 2003. The jacket design of The Da Vinci Code hid coordinates pointing to the sculpture's location at CIA headquarters. Brown's The Lost Symbol (2009) featured Kryptos as a minor plot element. Kryptos went from a cryptography obsession to being mentioned alongside the Rosetta Stone and the Enigma machine.Sanborn's fame grew as well. Wired, the New York Times, the Washington Post, and dozens of other outlets profiled him. The Smithsonian's Archives of American Art made him the subject of a 2009 oral history.But there were downsides. Someone hacked his computer. Unwanted guests showed up at his home and studio. He later told the Washington Post that the secret of K4 had \"destroyed marriages\" among its pursuers and provoked threats on his life. He reportedly slept with a shotgun.View Kryptos Archive2010: First Official K4 Clue — BERLINTwenty years after Kryptos was installed, Sanborn released his first official clue. K4 characters 64 through 69, when decrypted, spell \"BERLIN.\" Solvers jumped on it.2014: Second K4 Clue — CLOCKFour years later, Sanborn provided another clue: Characters 70 through 74 spell \"CLOCK.\" Combined with the first clue, this revealed the phrase \"BERLIN CLOCK.\"2020: Third and Fourth K4 Clues — EASTNORTHEASTIn January 2020, Sanborn released a third clue. Characters 26 through 34 decrypt to \"NORTHEAST.\"Later that year, he revealed that the immediately preceding characters, 22 through 25, were \"EAST\".Sanborn had now given two decoded fragments across the 97-character message: EASTNORTHEAST and BERLINCLOCK.2021–2024: Continuing Mystery and the AI EraKryptos remained one of the most famous unsolved puzzles in the world. Professional and amateur cryptanalysts continued submitting solutions to Sanborn directly. He charged a $50 screening fee to deter brute-force guessing.Then came the AI wave. By early 2025, Sanborn was getting solutions generated by ChatGPT and other AI systems. He told the New York Times these attempts were \"nothing short of fairly silly.\" K4 had resisted decades of human intelligence, and AI wasn't having much success either.August 2025: Sanborn Announces the AuctionOn Aug. 14, 2025, nearing his eightieth birthday and Kryptos's thirty-fifth anniversary, Sanborn sent an open letter to \"Kryptos fans, detractors, sleuths, spies, geniuses, CIA employees, cryptographers, and miscellaneous provocateurs.\"He announced that the complete K4 solution and related materials would go to auction in November. Sanborn said he no longer had \"the physical, mental or financial resources\" to be K4's sole keeper. He hoped the buyer would stay discreet, keep it confidential for a while, maybe set up a system for validating future solutions. He also confirmed K5's existence for the first time publicly, which would unlock only after K4 was solved.The auction lot was substantial: the original handwritten K4 plaintext, a signed letter from Ed Scheidt, the twelve-by-eighteen-inch copper maquette Sanborn submitted to the CIA in 1988, archival photos from the sculpture's creation, the original dedication pamphlet signed by CIA Director William Webster, and copies of the coding charts. Boston-based RR Auction estimated the lot would sell for between $300,000 and $500,000.The announcement hit global media: New York Times, Washington Post, Wired, Scientific American, Smithsonian Magazine, and dozens more.View Kryptos ArchiveSeptember 2025: The Smithsonian DiscoveryWeeks before the auction, something unexpected happened.The auction listing said Sanborn's original \"coding charts\" were at the Smithsonian Institution's Archives of American Art, where he'd donated papers over the years. Jarett Kobek, a Los Angeles writer and researcher, caught this. He asked his colleague Richard Byrne, a Washington, D.C. playwright and journalist, to visit the archives and photograph Sanborn's papers.On Sep. 2, Byrne went to the Smithsonian. In the files, he found five pages of scrambled text—scraps that, assembled together, looked like the K4 plaintext. These weren't encryption materials or coding charts. They were copies Sanborn made in 1990 for the CIA's historical intelligence collection to prove the sculpture's text wasn't offensive. Sanborn later said he'd accidentally included them in his archive donation years earlier while undergoing cancer treatment.On Sep. 3, Kobek and Byrne emailed Sanborn with the solution. He confirmed it was real, but this wasn't a cryptographic solve, which Kobek acknowledged: \"There's no way on Earth that this is a cryptographic solve, and we have not claimed that.\" Scientific American likened the discovery to \"finding somebody's password scribbled on a sticky note in their office.\" The encryption method stayed unknown, and the cipher itself was unbroken.Sanborn contacted the Smithsonian, which sealed the materials until 2075. Both men told the New York Times they wouldn't release the text. At a November press conference, Sanborn admitted his error but held firm: \"The scrambled plain text was found, but without the coding method or the key. This is a very important distinction.\"October–November 2025: The AuctionIn October 2025, RR Auction posted the Kryptos sale under the title \"Decoding History: Kryptos, Enigma, and the Rosetta Stone.\" The auction house disclosed the Smithsonian discovery to bidders, but interest was high.On Nov. 20, 2025, the Kryptos lot sold for $962,500, nearly double the high estimate, to an anonymous buyer.2025–Present: A New StewardThe anonymous buyer is Paradigm. We acquired the Kryptos archive because we believe in preserving mysteries worth solving.As K4's stewards, we've kept the solution even from ourselves. We designed a verification system that works without anyone needing to access the plaintext. Sanborn entered the K4 solution into a secure computer we provided. He typed the plaintext twice to confirm consistency. The computer took the SHA-256 hash and sent it to Google's Cloud Key Management Service, which generated a verification tag (a hash-based message authentication code, or HMAC) that can only be reproduced by sending the same hash to the same cloud-based key. The plaintext itself never left the device, and we wiped the laptop afterward.If you think you've solved K4, you can submit your answer through our verification system and pay the submission fee of $1 to prevent brute force guessing. Your submission gets hashed and compared against the stored tag. If it matches, you will receive email confirmation, and we will reach out about next steps.Kryptos has endured for more than thirteen thousand days. It's ready for you.View Kryptos ArchiveVideo & Imagery CreditsFootage and photography courtesy of ABCNews VideoSource; CBS News / Veritone; CNN; CTV News Stox / Bell Media Inc.; Shutterstock; Jim Sanborn Papers, Archives of American Art, Smithsonian Institution; Associated Press; Filmsupply; World History Archive / Alamy; TNG Technology Consulting, Germany / Big Techday 6, 2013; Jared Soares; Elonka Dunin; DEF CON; the American Cryptogram Association, The Cryptogram, November-December 1991, Central Intelligence Agency, and Paradigm Design Studio.","tokens":3688,"squid":"spider-04","role":"Research Spider","at":1791338897876,"hash":"37714bef844ffa78c08459934594111bbfa35208"}
{"url":"https://docs.switchboard.xyz/docs-by-chain/sui","domain":"docs.switchboard.xyz","title":"Sui | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.Switchboard provides on-demand oracle data for Sui Move contracts using the Quote Verifier pattern. This enables your DeFi applications to access verified, real-time price data with built-in security features.Version source of truth: SDK Version MatrixPrerequisitesSui CLI installed (Installation Guide)Basic understanding of Move and TypeScriptNode.js 21+ and npm installedDeploymentsThe Switchboard On-Demand service is deployed on:Mainnet: 0xa81086572822d67a1559942f23481de9a60c7709c08defafbb1ca8dffc44e210Testnet: 0x28005599a66e977bff26aeb1905a02cda5272fd45bb16a5a9eb38e8659658cffAvailable FeedsAssetFeed HashBTC/USD0x4cd1cad962425681af07b9254b7d804de3ca3446fbfd1371bb258d2c75059812ETH/USD0xa0950ee5ee117b2e2c30f154a69e17bfb489a7610c508dc5f67eb2a14616d8eaSOL/USD0x822512ee9add93518eca1c105a38422841a76c590db079eebb283deb2c14caa9SUI/USD0x7ceef94f404e660925ea4b33353ff303effaf901f224bdee50df3a714c1299e9Find more feeds at the Switchboard Explorer.PreviousHyperliquidNextPrice FeedsLast updated 7 months ago","tokens":275,"squid":"spider-08","role":"Oracle Spider","at":1791338899677,"hash":"2f0dd634b0d4d8c19345ca40f8b767a2c5d2f7e2"}
{"url":"https://akash.network/explore/partner-program/","domain":"akash.network","title":"Partner Program — Akash Network","text":"The Open Cloud Partner Program\n\nCo-develop native developer tools, deploy verified data center capacity, or architect production container runtimes alongside the global Akash ecosystem.\n\nThe Infrastructure Framework\n Standard Kubernetes Deployment \nProviders run standard, unmodified Kubernetes clusters on their hardware. When a developer submits an OCI container manifest, it maps directly to your existing infrastructure setup without requiring custom hypervisors or proprietary software layers.\n Automated Revenue Generation \nOur automated matching engine routes incoming compute demand directly to your available nodes. Your infrastructure automatically evaluates workload requirements and delivers competitive pricing to secure leases, turning idle silicon into predictable revenue without manual sales intervention.\n Enterprise Verification & Audits \nMaintain your premium positioning. Independent network auditors verify your data center tiers, physical location, and hardware specifications (like dedicated H100 arrays). This allows high-compliance enterprise tenants to target your facility exclusively for large-scale production workloads.\n Ecosystem Partner Story \nFrom Tooling to Protocol Acquisition\n\nCloudmos joined the ecosystem as an independent team engineering utilities to simplify remote container deployment management. By developing Cloudmos Alerts, Akashlytics, and Cloudmos Deploy, the team built the primary console interface utilized by network tenants to launch and manage active workloads.\n\nOverclock Labs (Founders of Akash) acquired Cloudmos to integrate this framework directly into the core protocol software layer. Following the acquisition, the entire codebase was migrated to the public Akash Network GitHub repository, giving developers a production-grade blueprint to audit, fork, and build custom web deployment interfaces.\n Core Contribution Cloudmos Deploy Akashlytics Deployment Alerts Outcome Acquired by Overclock Labs (Founders of Akash) \nWays to Partner\n Build Software Tooling \nIntegrate developer utilities, deployment consoles, or AI orchestrators into the network ecosystem. Access technical documentation to co-develop tooling that simplifies container resource allocation.\n Supply Compute Capacity \nConnect commercial colocation facilities or server clusters to the open network. Monetize available compute via automated demand matching while retaining complete infrastructure control.\n Consult & Deploy \nProvide engineering architecture, workload migration plans, and managed services. Help enterprise clients scale containerized application stacks and eliminate proprietary vendor lock-in.\n\nEcosystem Grants\n\nWe invest in the people who build the roads. If you are developing open-source tools, infrastructure, or specialized interfaces for the Akash Network, the grant program provides the capital to fund your development.\n\nWhether you are launching a new integration, expanding hardware supply, or contributing core protocol improvements, the grants program is designed to match network needs with your specific skill set.\n\nExplore Grants \nIntegrate Akash into your applications with SDKs and APIs\n Blockchain SDK Documentation Description SDK Overview Official Go and JavaScript/TypeScript SDKs Official Go and JavaScript/TypeScript SDKs \nView Docs Quick Start Deploy your first application programmatically Deploy your first application programmatically \nView Docs API Reference Complete SDK documentation and methods Complete SDK documentation and methods \nView Docs SDK Examples Code examples for common tasks Code examples for common tasks \nView Docs AuthZ & Fee Grants Manage permissions and sponsored transactions Manage permissions and sponsored transactions \nView Docs Deployment REST API Documentation Description API Overview REST API for credit card deployments via Console REST API for credit card deployments via Console \nView Docs Getting Started Set up authentication and make your first API call Set up authentication and make your first API call \nView Docs API Reference Complete endpoint documentation Complete endpoint documentation \nView Docs Console API — Network Data Description Console API — Network Data Indexed data: providers, GPU, stats. Not a node. Indexed data: providers, GPU, stats. Not a node. \nView Docs Providers API Query provider details, specs, and availability Query provider details, specs, and availability \nView Docs GPU Availability Guide Find and filter GPU resources across providers Find and filter GPU resources across providers \nView Docs \nBecome a Partner\n\nCoordinate with our ecosystem team to discover custom integration paths, infrastructure deployment frameworks, or certified service tracks.\n\nApply Now\n\nGet in Touch","tokens":1182,"squid":"spider-03","role":"Compute Spider","at":1791338902196,"hash":"9d88169d5faf76af19c1c38cb2331e48b8302657"}
{"url":"https://docs.switchboard.xyz/docs-by-chain/evm/hyperliquid","domain":"docs.switchboard.xyz","title":"Hyperliquid | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.Switchboard supports HyperEVM with the same encoded-update flow used on other EVM chains. The current examples repo does not ship a dedicated Hyperliquid runner script, but you should reuse the evm/price-feeds contract and deployment flow with Hyperliquid-specific chain settings.Network InformationNetworkChain IDRPC URLSwitchboard ContractMainnet999https://rpc.hyperliquid.xyz/evm0xcDb299Cb902D1E39F83F54c7725f54eDDa7F3347Testnet998https://rpc.hyperliquid-testnet.xyz/evmTBDQuick StartClone the examples repo and build the shared price-consumer project:git clone https://github.com/switchboard-xyz/sb-on-demand-examples.git\ncd sb-on-demand-examples/evm/price-feeds\nbun install\nforge buildDeploy the consumer contract to HyperEVM with the packaged Foundry script:SWITCHBOARD_ADDRESS=0xcDb299Cb902D1E39F83F54c7725f54eDDa7F3347 \\\nforge script deploy/DeploySwitchboardPriceConsumer.s.sol:DeploySwitchboardPriceConsumer \\\n --rpc-url https://rpc.hyperliquid.xyz/evm \\\n --private-key $PRIVATE_KEY \\\n --broadcast \\\n -vvvvIntegration Exampleimport { ethers } from \"ethers\";\nimport { CrossbarClient } from \"@switchboard-xyz/common\";\n\nconst provider = new ethers.JsonRpcProvider(\"https://rpc.hyperliquid.xyz/evm\");\nconst signer = new ethers.Wallet(process.env.PRIVATE_KEY!, provider);\n\nconst switchboard = new ethers.Contract(\n \"0xcDb299Cb902D1E39F83F54c7725f54eDDa7F3347\",\n [\"function getFee(bytes[] calldata updates) external view returns (uint256)\"],\n signer\n);\n\nconst priceConsumer = new ethers.Contract(\n process.env.CONTRACT_ADDRESS!,\n [\"function updatePrices(bytes[] calldata updates, bytes32[] calldata feedIds) external payable\"],\n signer\n);\n\nconst crossbar = new CrossbarClient(\"https://crossbar.switchboard.xyz\");\nconst btcFeedHash = \"0x4cd1cad962425681af07b9254b7d804de3ca3446fbfd1371bb258d2c75059812\";\n\nawait crossbar.simulateFeed(btcFeedHash, false, undefined, \"mainnet\");\n\nconst response = await crossbar.fetchV2Update([btcFeedHash], {\n chain: \"evm\",\n network: \"mainnet\",\n use_timestamp: true,\n});\n\nif (!response.encoded) {\n throw new Error(\"Crossbar returned no encoded update payload\");\n}\n\nconst updates = [response.encoded];\nconst fee = await switchboard.getFee(updates);\nconst tx = await priceConsumer.updatePrices(updates, [btcFeedHash], { value: fee });\nawait tx.wait();NotesThe packaged evm/price-feeds/scripts/run.ts currently includes Monad presets, not Hyperliquid presets.For Hyperliquid, reuse the same contract and encoded-update flow shown above with chain ID 999.Hyperliquid network docs: Hyperliquid Docs and HyperEVM.PreviousMonadNextSuiLast updated 6 months ago","tokens":669,"squid":"spider-08","role":"Oracle Spider","at":1791338909847,"hash":"e20b42cc58a902464acfb43b0a80d13307fa1972"}
{"url":"https://docs.switchboard.xyz/docs-by-chain/evm/price-feeds","domain":"docs.switchboard.xyz","title":"Price Feeds | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.Access to reliable, real-world data is essential for decentralised applications (dApps), particularly in Decentralised Finance (DeFi). Real-time asset prices, forming the backbone of any DeFi protocol, are among the most critical data points.This is where Data Feeds come in. Think of them as secure bridges connecting the off-chain world of financial markets to your on-chain smart contracts. They provide a continuous stream of verified, aggregated price data for a wide range of assets, enabling your dApp to react to market fluctuations and operate correctly.PreviousEVMNextPrice Feeds TutorialLast updated 9 months ago","tokens":179,"squid":"spider-08","role":"Oracle Spider","at":1791338919768,"hash":"3b95dba7861b6226fe59884ad1becf15df1e74ff"}
{"url":"https://docs.switchboard.xyz/docs-by-chain/evm/price-feeds/price-feeds-tutorial","domain":"docs.switchboard.xyz","title":"Price Feeds Tutorial | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.Example Code: The complete working example for this tutorial is available at sb-on-demand-examples/evm/price-feedsThis tutorial walks you through integrating Switchboard oracle price feeds into your EVM smart contracts. You'll learn how to fetch oracle data, submit updates to your contract, and read verified prices.Version source of truth: SDK Version MatrixWhat You'll BuildA Solidity smart contract that:Receives and stores verified oracle price updatesValidates price freshness and deviationProvides helper functions for DeFi use cases (collateral ratios, liquidations)Plus a TypeScript client that fetches oracle data and submits it to your contract.PrerequisitesFoundry for Solidity development (forge, cast)Bun or Node.js 20+Native tokens for gas (MON, ETH, etc.)Basic understanding of Solidity and ethers.jsKey ConceptsHow Switchboard On-Demand Works on EVMSwitchboard uses an on-demand model where:Your client fetches signed price data from Crossbar (Switchboard's gateway)Your contract submits the signed data to the Switchboard contract for verificationSwitchboard verifies the oracle signatures and stores the dataYour contract reads the verified data via latestUpdate()This pattern ensures prices are cryptographically verified on-chain while keeping gas costs low.The CrossbarClientThe CrossbarClient from @switchboard-xyz/common is your interface to fetch oracle data for the v2 feed-hash flow used by current Monad integrations and Feed Builder feeds:import { CrossbarClient } from \"@switchboard-xyz/common\";\n\nconst crossbar = new CrossbarClient(\"https://crossbar.switchboard.xyz\");\nconst response = await crossbar.fetchV2Update([feedId], {\n chain: \"evm\",\n network: \"mainnet\",\n use_timestamp: true,\n});\n\nif (!response.encoded) {\n throw new Error(\"Crossbar returned no encoded update payload\");\n}\n\nconst updates = [response.encoded];If you are using a bytes32 feed ID from Explorer or Feed Builder, this is the path you want. Legacy fetchEVMResults() and /updates/evm/... routes remain available for older aggregator-based integrations, but they are not the primary flow for custom feeds.Fee HandlingSome networks require a fee for oracle updates. Always check before submitting:const fee = await switchboard.getFee(updates);\nawait contract.updatePrices(updates, [feedId], { value: fee });The Smart ContractHere's a complete example contract that integrates Switchboard price feeds:// SPDX-License-Identifier: MIT\npragma solidity ^0.8.22;\n\nimport { ISwitchboard } from \"./switchboard/interfaces/ISwitchboard.sol\";\nimport { SwitchboardTypes } from \"./switchboard/libraries/SwitchboardTypes.sol\";\n\n/**\n * @title SwitchboardPriceConsumer\n * @notice Example contract demonstrating Switchboard On-Demand oracle integration\n *\n * Key Features:\n * - Secure price updates with signature verification\n * - Staleness checks to prevent old data usage\n * - Price deviation validation\n * - Multi-feed support\n */\ncontract SwitchboardPriceConsumer {\n // ========== State Variables ==========\n\n /// @notice The Switchboard contract interface\n ISwitchboard public immutable switchboard;\n\n /// @notice Stored price data for each feed\n mapping(bytes32 => PriceData) public prices;\n\n /// @notice Maximum age for price data (default: 5 minutes)\n uint256 public maxPriceAge = 300;\n\n /// @notice Maximum price deviation in basis points (default: 10% = 1000 bps)\n uint256 public maxDeviationBps = 1000;\n\n /// @notice Contract owner\n address public owner;\n\n // ========== Structs ==========\n\n /**\n * @notice Stored price information for a feed\n * @param value The price value (18 decimals)\n * @param timestamp When the price was last updated\n * @param slotNumber Solana slot number of the update\n */\n struct PriceData {\n int128 value;\n uint256 timestamp;\n uint64 slotNumber;\n }\n\n // ========== Events ==========\n\n event PriceUpdated(\n bytes32 indexed feedId,\n int128 oldPrice,\n int128 newPrice,\n uint256 timestamp,\n uint64 slotNumber\n );\n\n event PriceValidationFailed(bytes32 indexed feedId, string reason);\n\n // ========== Errors ==========\n\n error InsufficientFee(uint256 expected, uint256 received);\n error PriceTooOld(uint256 age, uint256 maxAge);\n error PriceDeviationTooHigh(uint256 deviation, uint256 maxDeviation);\n error InvalidFeedId();\n error Unauthorized();\n\n // ========== Constructor ==========\n\n constructor(address _switchboard) {\n switchboard = ISwitchboard(_switchboard);\n owner = msg.sender;\n }\n\n // ========== External Functions ==========\n\n /**\n * @notice Update price feeds with oracle data\n * @param updates Encoded Switchboard updates with signatures\n * @param feedIds Array of feed IDs to process from the update\n */\n function updatePrices(\n bytes[] calldata updates,\n bytes32[] calldata feedIds\n ) external payable {\n // Get the required fee\n uint256 fee = switchboard.getFee(updates);\n if (msg.value < fee) {\n revert InsufficientFee(fee, msg.value);\n }\n\n // Submit updates to Switchboard (verifies signatures)\n switchboard.updateFeeds{ value: fee }(updates);\n\n // Process each feed ID\n for (uint256 i = 0; i < feedIds.length; i++) {\n bytes32 feedId = feedIds[i];\n\n // Get the latest verified update from Switchboard\n SwitchboardTypes.LegacyUpdate memory update = switchboard.latestUpdate(feedId);\n\n // Store the price with validation\n _processFeedUpdate(\n feedId,\n update.result,\n uint64(update.timestamp),\n update.slotNumber\n );\n }\n\n // Refund excess payment\n if (msg.value > fee) {\n (bool success, ) = msg.sender.call{ value: msg.value - fee }(\"\");\n require(success, \"Refund failed\");\n }\n }\n\n /**\n * @notice Get the current price for a feed\n * @param feedId The feed identifier\n * @return value The price value\n * @return timestamp The update timestamp\n * @return slotNumber The Solana slot number\n */\n function getPrice(\n bytes32 feedId\n ) external view returns (int128 value, uint256 timestamp, uint64 slotNumber) {\n PriceData memory priceData = prices[feedId];\n if (priceData.timestamp == 0) revert InvalidFeedId();\n return (priceData.value, priceData.timestamp, priceData.slotNumber);\n }\n\n /**\n * @notice Check if a price is fresh (within maxPriceAge)\n */\n function isPriceFresh(bytes32 feedId) public view returns (bool) {\n PriceData memory priceData = prices[feedId];\n if (priceData.timestamp == 0) return false;\n return block.timestamp - priceData.timestamp <= maxPriceAge;\n }\n\n // ========== Internal Functions ==========\n\n function _processFeedUpdate(\n bytes32 feedId,\n int128 newValue,\n uint64 timestamp,\n uint64 slotNumber\n ) internal {\n PriceData memory oldPrice = prices[feedId];\n\n // Validate price deviation if we have a previous price\n if (oldPrice.timestamp != 0) {\n uint256 deviation = _calculateDeviation(oldPrice.value, newValue);\n if (deviation > maxDeviationBps) {\n emit PriceValidationFailed(feedId, \"Deviation too high\");\n revert PriceDeviationTooHigh(deviation, maxDeviationBps);\n }\n }\n\n // Store the new price\n prices[feedId] = PriceData({\n value: newValue,\n timestamp: timestamp,\n slotNumber: slotNumber\n });\n\n emit PriceUpdated(feedId, oldPrice.value, newValue, timestamp, slotNumber);\n }\n\n function _calculateDeviation(\n int128 oldValue,\n int128 newValue\n ) internal pure returns (uint256) {\n if (oldValue == 0) return 0;\n\n uint128 absOld = oldValue < 0 ? uint128(-oldValue) : uint128(oldValue);\n uint128 absNew = newValue < 0 ? uint128(-newValue) : uint128(newValue);\n\n uint128 diff = absNew > absOld ? absNew - absOld : absOld - absNew;\n return (uint256(diff) * 10000) / uint256(absOld);\n }\n}Contract WalkthroughState VariablesISwitchboard public immutable switchboard;\nmapping(bytes32 => PriceData) public prices;\nuint256 public maxPriceAge = 300;\nuint256 public maxDeviationBps = 1000;switchboard - Reference to the deployed Switchboard contractprices - Maps feed IDs to their latest price datamaxPriceAge - Maximum acceptable age for price data (5 minutes default)maxDeviationBps - Maximum price change allowed (10% default, prevents manipulation)The updatePrices FunctionThis is the main entry point for updating prices:Check fee - Ensure caller sent enough to cover the oracle update feeSubmit to Switchboard - Call updateFeeds() which verifies oracle signaturesRead verified data - Call latestUpdate() to get the verified priceStore locally - Save the price in your contract's storageRefund excess - Return any overpayment to the callerReading Prices(int128 value, uint256 timestamp, uint64 slotNumber) = consumer.getPrice(feedId);Always check freshness before using a price:require(consumer.isPriceFresh(feedId), \"Price is stale\");The TypeScript ClientHere's a complete client that fetches oracle data and submits it to your contract:import * as ethers from \"ethers\";\nimport { CrossbarClient } from \"@switchboard-xyz/common\";\n\nasync function main() {\n // Setup\n const privateKey = process.env.PRIVATE_KEY!;\n const contractAddress = process.env.CONTRACT_ADDRESS!;\n const switchboardAddress = process.env.SWITCHBOARD_ADDRESS!;\n\n const provider = new ethers.JsonRpcProvider(\"https://rpc.hyperliquid.xyz/evm\");\n const signer = new ethers.Wallet(privateKey, provider);\n\n const consumerAbi = [\n \"function updatePrices(bytes[] calldata updates, bytes32[] calldata feedIds) external payable\",\n \"function getPrice(bytes32 feedId) external view returns (int128 value, uint256 timestamp, uint64 slotNumber)\",\n \"event PriceUpdated(bytes32 indexed feedId, int128 oldPrice, int128 newPrice, uint256 timestamp, uint64 slotNumber)\"\n ];\n const switchboardAbi = [\n \"function getFee(bytes[] calldata updates) external view returns (uint256)\"\n ];\n\n const contract = new ethers.Contract(contractAddress, consumerAbi, signer);\n const switchboard = new ethers.Contract(switchboardAddress, switchboardAbi, signer);\n const crossbar = new CrossbarClient(\"https://crossbar.switchboard.xyz\");\n\n // The feed ID you want to update (e.g., BTC/USD)\n const feedId = \"0x4cd1cad962425681af07b9254b7d804de3ca3446fbfd1371bb258d2c75059812\";\n\n // Step 1: Fetch signed oracle data from Crossbar\n const response = await crossbar.fetchV2Update([feedId], {\n chain: \"evm\",\n network: \"mainnet\",\n use_timestamp: true,\n });\n\n if (!response.encoded) {\n throw new Error(\"Crossbar returned no encoded update payload\");\n }\n\n const updates = [response.encoded];\n const median = response.medianResponses[0];\n\n console.log(\"Fetched\", updates.length, \"encoded updates\");\n console.log(\"Median value:\", median?.value);\n console.log(\"Oracle timestamp:\", new Date(response.timestamp * 1000).toISOString());\n\n // Step 2: Submit to your contract\n const fee = await switchboard.getFee(updates);\n const tx = await contract.updatePrices(updates, [feedId], { value: fee });\n console.log(\"Transaction hash:\", tx.hash);\n\n // Step 3: Wait for confirmation\n const receipt = await tx.wait();\n console.log(\"Confirmed in block:\", receipt.blockNumber);\n\n // Step 4: Parse events\n const iface = new ethers.Interface(consumerAbi);\n for (const log of receipt.logs) {\n try {\n const parsed = iface.parseLog({ topics: log.topics, data: log.data });\n if (parsed?.name === \"PriceUpdated\") {\n console.log(\"\\n=== Price Updated ===\");\n console.log(\"Feed ID:\", parsed.args.feedId);\n console.log(\"New Price:\", ethers.formatUnits(parsed.args.newPrice, 18));\n console.log(\"Timestamp:\", new Date(Number(parsed.args.timestamp) * 1000).toISOString());\n }\n } catch (e) {\n // Skip non-matching logs\n }\n }\n\n // Step 5: Read the stored price\n const [value, timestamp, slotNumber] = await contract.getPrice(feedId);\n console.log(\"\\n=== Current Price ===\");\n console.log(\"Value:\", ethers.formatUnits(value, 18));\n console.log(\"Timestamp:\", new Date(Number(timestamp) * 1000).toISOString());\n console.log(\"Slot:\", slotNumber.toString());\n}\n\nmain().catch(console.error);Client WalkthroughStep 1: Fetch Oracle Dataconst response = await crossbar.fetchV2Update([feedId], {\n chain: \"evm\",\n network: \"mainnet\",\n use_timestamp: true,\n});\n\nif (!response.encoded) {\n throw new Error(\"Crossbar returned no encoded update payload\");\n}\n\nconst updates = [response.encoded];The fetchV2Update call returns:medianResponses with one consensus value per feedtimestamp for the signed oracle consensusoracleResponses for per-oracle detailencoded, the EVM payload you wrap into bytes[] for getFee and updateFeedsStep 2: Submit to Contractconst fee = await switchboard.getFee(updates);\nconst tx = await contract.updatePrices(updates, [feedId], { value: fee });Your contract receives the encoded data, submits it to Switchboard for verification, then stores the result.Step 3-5: Confirm and ReadAfter confirmation, you can:Parse PriceUpdated events from the receiptRead the stored price directly from your contractDeploymentThe packaged example now uses one network switch for both deploys and runtime:NETWORK=monad-testnet or NETWORK=monad-mainnetRPC_URL is optional and overrides the default RPC for the selected networkPRIVATE_KEY is requiredSWITCHBOARD_ADDRESS is an advanced override onlyDefaults:NETWORK=monad-testnetTestnet RPC: https://testnet-rpc.monad.xyzMainnet RPC: https://rpc.monad.xyzThe packaged deploy flow validates the selected network before broadcast:the RPC chain ID must match NETWORKthe resolved Switchboard address must have deployed bytecodeMonad SWITCHBOARD_ADDRESS overrides must match the canonical address for the selected networkUse the packaged wrapper from the example repo:# Default: Monad testnet\nbun run deploy\n\n# Explicit aliases\nbun run deploy:monad-testnet\nbun run deploy:monad-mainnet\n\n# Flip to mainnet with one env var\nNETWORK=monad-mainnet bun run deployIf you want raw Foundry instead of the wrapper, keep the same env contract:NETWORK=monad-testnet \\\nRPC_URL=https://testnet-rpc.monad.xyz \\\nforge script deploy/DeploySwitchboardPriceConsumer.s.sol:DeploySwitchboardPriceConsumer \\\n --rpc-url $RPC_URL \\\n --broadcast \\\n -vvvvRunning the Example1. Clone the Examples Repositorygit clone https://github.com/switchboard-xyz/sb-on-demand-examples\ncd sb-on-demand-examples/evm/price-feeds2. Install Dependenciesbun install\n(\n cd ../randomness/coin-flip\n [ -d lib/forge-std ] || forge install foundry-rs/forge-std --no-git --shallow\n)\nforge build3. Configure EnvironmentSecurity: Never use export PRIVATE_KEY=...—it appears in shell history. Use a .env file instead.Create a .env file (add it to .gitignore):PRIVATE_KEY=0x...\nNETWORK=monad-testnet\nRPC_URL=\nSWITCHBOARD_ADDRESS=\n# Optional: if omitted, the script deploys a new consumer contract\nCONTRACT_ADDRESS=0x...4. Run the ExampleIf CONTRACT_ADDRESS is unset, the script deploys a fresh consumer contract before it fetches the v2 update and submits it on-chain:bun run exampleSwitch to Monad mainnet without changing the script:NETWORK=monad-mainnet bun run exampleFor Feed Builder or custom feeds, it is useful to preflight before sending a transaction:await crossbar.simulateFeed(feedId, false, undefined, \"testnet\");Expected OutputFeed ID: 0x4cd1cad962425681af07b9254b7d804de3ca3446fbfd1371bb258d2c75059812\nEncoded updates length: 1\nTransaction hash: 0x...\nTransaction confirmed in block: 12345678\n\n=== Feed Update Event ===\nPrice: 97234500000000000000000\nTimestamp: 2024-12-18T10:30:00.000Z\n\n=== Latest Update Details ===\nResult: 97234500000000000000000\nTimestamp: 2024-12-18T10:30:00.000ZAdding to Your Project1. Install the Switchboard InterfacesCopy the interface files from the examples repo:cp -r sb-on-demand-examples/evm/price-feeds/src/switchboard your-project/src/Or install via npm:npm install @switchboard-xyz/on-demand-solidity@1.1.02. Import and Useimport { ISwitchboard } from \"./switchboard/interfaces/ISwitchboard.sol\";\nimport { SwitchboardTypes } from \"./switchboard/libraries/SwitchboardTypes.sol\";\n\ncontract YourContract {\n ISwitchboard public switchboard;\n\n constructor(address _switchboard) {\n switchboard = ISwitchboard(_switchboard);\n }\n\n function yourFunction(bytes[] calldata updates, bytes32 feedId) external payable {\n // Submit to Switchboard\n uint256 fee = switchboard.getFee(updates);\n switchboard.updateFeeds{ value: fee }(updates);\n\n // Read verified data\n SwitchboardTypes.LegacyUpdate memory update = switchboard.latestUpdate(feedId);\n\n // Use update.result (the price)\n int128 price = update.result;\n // ... your logic here\n }\n}Example: DeFi Business LogicThe example contract includes helper functions for common DeFi patterns:Calculate Collateral Ratiofunction calculateCollateralRatio(\n bytes32 feedId,\n uint256 collateralAmount,\n uint256 debtAmount\n) external view returns (uint256 ratio) {\n require(isPriceFresh(feedId), \"Price is stale\");\n\n PriceData memory priceData = prices[feedId];\n\n // Calculate collateral value in USD\n uint256 collateralValue = (collateralAmount * uint128(priceData.value)) / 1e18;\n\n // Return ratio in basis points (15000 = 150%)\n ratio = (collateralValue * 10000) / debtAmount;\n}Check Liquidationfunction shouldLiquidate(\n bytes32 feedId,\n uint256 collateralAmount,\n uint256 debtAmount,\n uint256 liquidationThreshold // e.g., 11000 = 110%\n) external view returns (bool) {\n if (!isPriceFresh(feedId)) return false;\n\n PriceData memory priceData = prices[feedId];\n uint256 collateralValue = (collateralAmount * uint128(priceData.value)) / 1e18;\n uint256 ratio = (collateralValue * 10000) / debtAmount;\n\n return ratio < liquidationThreshold;\n}Switchboard Contract AddressesNetworkChain IDSwitchboard ContractMonad Testnet101430x6724818814927e057a693f4e3A172b6cC1eA690CMonad Mainnet1430xB7F03eee7B9F56347e32cC71DaD65B303D5a0E67HyperEVM Mainnet9990xcDb299Cb902D1E39F83F54c7725f54eDDa7F3347Arbitrum One421610xAd9b8604b6B97187CDe9E826cDeB7033C8C37198Arbitrum Sepolia4216140xA2a0425fA3C5669d384f4e6c8068dfCf64485b3bCore Mainnet11160x33A5066f65f66161bEb3f827A3e40fce7d7A2e6CAvailable FeedsFind available price feeds at the Switchboard Explorer.Popular feeds include:BTC/USD: 0x4cd1cad962425681af07b9254b7d804de3ca3446fbfd1371bb258d2c75059812ETH/USD: 0xa0950ee5ee117b2e2c30f154a69e17bfb489a7610c508dc5f67eb2a14616d8eaSOL/USD: 0x822512ee9add93518eca1c105a38422841a76c590db079eebb283deb2c14caa9TroubleshootingErrorSolutionInsufficientFeeQuery switchboard.getFee(updates) and send that amount as msg.valuePriceDeviationTooHighNormal during high volatility; adjust maxDeviationBps if neededPriceTooOldFetch fresh data from Crossbar; adjust maxPriceAge if neededInvalidFeedIdEnsure the feed ID exists and has been updated at least onceORACLE_UNAVAILABLEIf simulateFeed works but fetchV2Update fails, it is not a missing deployment step. Check oracle/gateway availability and oracle-side validation errors such as RangeExceeded, especially if raw v2 maxJobRangePct was not scaled by 1e9; see Feed Parameter UnitsBuild errorsBootstrap forge-std in ../randomness/coin-flip, then rerun forge buildNext StepsExplore randomness integration for gaming and NFTsLearn about custom feeds for specialized dataJoin the Switchboard Discord for supportPreviousPrice FeedsNextSurge Price FeedsLast updated 3 months ago","tokens":4721,"squid":"spider-08","role":"Oracle Spider","at":1791338929295,"hash":"52922cb5be5e2a2734f0ac628526a1ee2bd2f39b"}
{"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":"spider-05","role":"Spec Spider","at":1791338935322,"hash":"5d2a1c731ee4cea0ea1ceb3724e2abb5dd3e3d0b"}
{"url":"https://docs.switchboard.xyz/custom-feeds/advanced-feed-configuration","domain":"docs.switchboard.xyz","title":"Advanced Feed Configuration | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.Switchboard Feeds enable seamless access to data from any API, oracle, major DeFi protocol, and more. Our mission is to simplify the process of retrieving diverse data types—such as price data and event data—in a secure and user-friendly manner.Switchboard data feeds are composed of Oracle Jobs, which define where to source data. Feeds specify a list of different Task Types, which are used as instructions to fetch data.If you are configuring feed validation, start with Feed Parameter Units. Raw v2 maxJobRangePct is scaled by 1e9, while task-level percent fields and SDK helper fields may use human percentages.This section will explore different task types and give an in-depth explanation on how to build oracle jobs.Task RunnerAll Oracle Jobs are executed by the task-runner, an engine used by oracles to fetch data in a secure and efficient manner. Oracle Jobs must define an array of tasks executed sequentially. Any task producing a value (String, JSON, or Decimal) will be assigned to the job's context for that particular run, and subsequent tasks will manipulate that current task.Here's a brief overview of what a job might look like (without including full tasks):// Oracle Job\n[\n httpTask,\n jsonParseTask,\n multiplyTask, \n]So here we'd:Fetch a result from some API and set that blob to contextParse context and replace with value at jsonPath specifiedMultiply value in context by some numberSee the next page for more on the task runner.PreviousDeploy FeedNextFeed Parameter UnitsLast updated 3 months ago","tokens":404,"squid":"spider-08","role":"Oracle Spider","at":1791338939243,"hash":"111a250a388289ac29dca66cf2ca2138b486041b"}
{"url":"https://docs.switchboard.xyz/custom-feeds/advanced-feed-configuration/feed-parameter-units","domain":"docs.switchboard.xyz","title":"Feed Parameter Units | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.Feed definitions combine validation parameters, quorum parameters, freshness limits, and returned feed values. These fields do not all use the same unit or fixed-point scale.The most common mistake is treating raw v2 OracleFeed.maxJobRangePct / max_job_range_pct as a human percent. It is a fixed-point percent scaled by 1e9:1_000_000_000 means 1%5_000_000_000 means 5%5 does not mean 5%; it is effectively zero toleranceField or surfaceUnitExampleNotesRaw v2 OracleFeed.maxJobRangePct / max_job_range_pctPercent scaled by 1e91_000_000_000 = 1%; 5_000_000_000 = 5%Used in raw protobuf/JSON feed definitions. This is the feed-level job-spread tolerance oracles enforce before signing an update.SDK helper maxVariance inputs that scale internallyHuman percent1 or 1.0 = 1%Some SDK helper methods accept the human percentage and multiply by 1e9 before sending a gateway or on-chain request. Check the method docs before passing raw integers.Common FeedRequestV1.maxVarianceScaledPercent scaled by 1e98_271_619 is sent exactly as 8_271_619Use this when forwarding an exact raw value read from a classic PullFeed account. It must be a nonnegative JavaScript safe integer. Do not provide it together with maxVariance.Direct gateway/raw API max_variance fieldsPercent scaled by 1e950_000_000 = 0.05%; 1_000_000_000 = 1%Use this for raw gateway payloads and chain parameters that already expect fixed-point validation values. Some JSON routes expose this as camelCase maxVariance while still expecting the scaled integer.MedianTask.max_range_percentHuman percent string\"2.5\" = 2.5%This is a task-level setting inside MedianTask. It is not scaled like feed-level maxJobRangePct.minJobResponses / min_job_responsesUnscaled job/source quorum2 requires at least two successful job resultsThis counts successful jobs inside one oracle's feed execution. It does not change percent scaling.minOracleSamples / min_oracle_samplesUnscaled oracle/signature quorum3 requires three oracle samplesThis counts oracle responses/signatures. It is separate from job/source quorum.Feed result valuesFeed-specific numeric convention, often i128 scaled by 1e181_000_000_000_000_000_000 may represent 1.0Result-value scaling is independent from validation parameter scaling. Always document the feed's value decimals separately.Staleness fieldsSlots, seconds, or milliseconds depending on the surfacemaxStaleness: 150 slots; maxAgeSeconds: 60; maxAgeMs: 60000Solana/SVM verifier settings often use slots. EVM and Move-chain examples commonly use seconds. Sui examples may use milliseconds.Practical RulesWhen you create a raw v2 OracleFeed, use scaled integers for feed-level range validation:const feed = {\n minJobResponses: 2,\n minOracleSamples: 3,\n maxJobRangePct: 1_000_000_000, // 1%, scaled by 1e9\n jobs,\n};Use maxJobRangePct: 0 only when the flow intentionally expects a single successful job/source or identical outputs. For normal multi-source feeds, set a positive scaled tolerance.Simulation can succeed even when signed updates fail. Simulation proves the jobs can resolve off-chain; signed updates also require oracle-side feed validation to pass. If update fetching returns ORACLE_UNAVAILABLE after successful simulation, inspect oracle errors for validation failures such as RangeExceeded, then check whether maxJobRangePct was scaled correctly.Classic PullFeed Variance@switchboard-xyz/on-demand@3.10.6 reads a classic PullFeed account's exact on-chain maxVariance integer and forwards it through FeedRequestV1.maxVarianceScaled. Application code should not convert that account value to a floating-point percentage and scale it again.When calling the Common gateway API directly, use maxVariance for a human percentage or maxVarianceScaled for an already-scaled raw integer, never both. Raw values above Number.MAX_SAFE_INTEGER are rejected before a gateway request because the current JSON number transport cannot represent them exactly.This feed-validation failure is separate from using the wrong Solana/SVM update path. If PullFeed.fetchUpdateIx(...) or pullFeedSubmitResponseConsensus returns ORACLE_UNAVAILABLE while queue.fetchManagedUpdateIxs(...) returns Ed25519 quote-program instructions, move the integration to canonical quote-program accounts; see Quote Program Accounts.PreviousAdvanced Feed ConfigurationNextData Feed Variable OverridesLast updated 2 months ago","tokens":1114,"squid":"spider-08","role":"Oracle Spider","at":1791338951244,"hash":"6ed307975185186c5aeb355ea0067f7e7fae1aa1"}
{"url":"https://eips.ethereum.org/EIPS/eip-2159","domain":"eips.ethereum.org","title":"EIP-2159: Common Prometheus Metrics Names for Clients","text":"🎉 Final\n\n Standards Track: Interface\n\n EIP-2159: Common Prometheus Metrics Names for Clients\n\n Authors\n Adrian Sutton (@ajsutton)\n\n Created\n 2019-07-01\n\n Simple Summary\n\nStandardized names of common metrics for Ethereum clients to use with Prometheus, a widely used monitoring and alerting solution.\n\n Abstract\n\nMany Ethereum clients expose a range of metrics in a format compatible with Prometheus to allow operators to monitor the client’s behaviour and performance and raise alerts if the chain isn’t progressing or there are other indications of errors.\nWhile the majority of these metrics are highly client-specific, reporting on internal implementation details of the client, some are applicable to all clients.\nBy standardizing the naming and format of these common metrics, operators are able to monitor the operation of multiple clients in a single dashboard or alerting configuration.\n\n Motivation\n\nUsing common names and meanings for metrics which apply to all clients allows node operators to monitor clusters of nodes using heterogeneous clients using a single dashboard and alerting configuration.\nCurrently there are no agreed names or meanings, leaving client developers to invent their own making it difficult to monitor a heterogeneous cluster.\n\n Specification\n\nThe table below defines metrics which may be captured by Ethereum clients which expose metrics to Prometheus. Clients may expose additional metrics however these should not use the ethereum_ prefix.\n\n Name\n Metric type\n Definition\n JSON-RPC Equivalent\n\n ethereum_blockchain_height\n Gauge\n The current height of the canonical chain\n eth_blockNumber\n\n ethereum_best_known_block_number\n Gauge\n The estimated highest block available\n highestBlock of eth_syncing or eth_blockNumber if not syncing\n\n ethereum_peer_count\n Gauge\n The current number of peers connected\n net_peerCount\n\n ethereum_peer_limit\n Gauge\n The maximum number of peers this node allows to connect\n No equivalent\n\nNote that ethereum_best_known_block_number always has a value. When the eth_syncing JSON-RPC method would return false, the current chain height is used.\n\n Rationale\n\nThe defined metrics are independent of Ethereum client implementation but provide sufficient information to create an overview dashboard to support monitoring a group of Ethereum nodes.\n\nThere is a similar, though more prescriptive, specification for beacon chain client metrics.\nThe specific details of how to expose the metrics has been omitted as there is variance in existing implementations and standardising this does not provide any significant benefit.\n\n Backwards Compatibility\n\nThis is not a consensus affecting change.\n\nClients may already be publishing these metrics using different names and changing to the new form may break existing alerts or dashboards. Clients that want to avoid this incompatibility can expose the metrics under both the old and new names.\n\nClients may also be publishing metrics with a different meaning using these names. Backwards compatibility cannot be preserved in this case.\n\n Implementation\n\nPantheon switched to using these standard metric names in its 1.2 release: https://github.com/PegaSysEng/pantheon/pull/1634.\n\n References\n\n Prometheus. https://prometheus.io\n Beacon chain metrics specification. https://github.com/ethereum/eth2.0-metrics/blob/master/metrics.md\n\n Copyright\n\nCopyright and related rights waived via CC0.\n\n Citation\n Please cite this document as:\n\n Adrian Sutton (@ajsutton), \"EIP-2159: Common Prometheus Metrics Names for Clients,\" Ethereum Improvement Proposals, no. 2159, July 2019. Available: https://eips.ethereum.org/EIPS/eip-2159.","tokens":907,"squid":"spider-05","role":"Spec Spider","at":1791338955140,"hash":"3eb309eb498a6d90abc1d3d7d6d1b166fee3873f"}
{"url":"https://docs.across.to/introduction/fees","domain":"docs.across.to","title":"Fees in the System | Across Docs","text":"Fees in the SystemHow LP fees, relayer fees, gas fees, and capital fees are calculated in Across.Every crosschain transfer through Across incurs fees that compensate the actors making the system work — liquidity providers and relayers. All fees are derived from the spread between the inputAmount (what the user deposits on the origin chain) and the outputAmount (what the user receives on the destination chain).\nFee Breakdown\nThe total fee a user pays is the difference between their deposit and what they receive:\ntotalFee = inputAmount - outputAmount\nThis total fee is split between two components:\nFee TypeRecipientPurposeLP FeeLiquidity providersCompensates LPs for capital utilization and rebalancing riskRelayer FeeRelayer who fills the intentCovers gas costs, capital opportunity cost, and risk\nUse the /suggested-fees endpoint to get a fee quote before executing a transfer. The response breaks down each component.\n/suggested-fees is legacy. New integrations should read fees off the /swap/approval response instead. Already on it? See Migrate from Suggested Fees to the Swap API.\nLP Fees\nAcross uses a utilization-based pricing model adapted from lending protocols like Aave. LP fees depend on how much of the available liquidity pool is being used.\nHow It Works\n\nWhen utilization is low, LP fees are minimal — plenty of capital is available\nAs utilization increases, fees rise along a curve to incentivize more LP deposits\nAbove a \"kink\" threshold, fees increase steeply to discourage draining the pool\n\nKey Variables\nVariableDescriptionUCurrent pool utilization (0 to 1)U-barKink utilization — threshold where the fee curve steepensR0Base interest rateR1Slope below kinkR2Slope above kink (steep)\nThe annualized rate formula follows an Aave-style two-slope model:\nR(U) = R0 + (min(U-bar, U) / U-bar) * R1 + (max(0, U - U-bar) / (1 - U-bar)) * R2\nWeekly rates are derived as (1 + R_annual)^(1/52) - 1, and the final LP fee is the weekly rate multiplied by the transaction size.\nWhen are LP fees zero? If the relayer takes repayment on the origin chain (same chain as the deposit), no crosschain rebalancing is needed, so LP fees are zero. Non-zero fees apply when repayment occurs on a different chain.\nPer-Route Parameters\nThe rate parameters (R0, R1, R2, U-bar) vary by token and route. This means the LP fee for bridging USDC from Arbitrum to Base may differ from USDC from Ethereum to Optimism, reflecting different pool utilization levels.\nRelayer Fees\nRelayers are compensated for three costs they incur when filling an intent:\n1. Gas Fees\nThe cost of submitting the fill transaction on the destination chain. This varies by chain — filling on Ethereum L1 costs more gas than filling on Arbitrum or Base.\n2. Capital Opportunity Cost\nRelayers lock their own capital to fill intents immediately, then wait for reimbursement through the bundle settlement process (~1.5 hours). The fee compensates for the time value of that locked capital.\n3. Capital at Risk\nRelayers bear risk from:\n\nSoftware bugs — implementation errors in relayer software\nChain reorganizations — finality risk where a filled transaction could be reverted\nSettlement delays — longer-than-expected reimbursement periods\n\nApp Fees (Integrator Revenue)\nApp fees are an optional fee you add on top of Across's protocol fees — your integrator revenue, separate from the LP and relayer fees above. Set appFee (a decimal from 0 to 1, e.g. 0.01 = 1%) and appFeeRecipient on your Swap API request. The fee is charged in the output token and paid to appFeeRecipient on the destination chain, and appears in the /swap/approval fee breakdown.\nappFeeRecipient is required whenever appFee > 0, and must be valid on the destination chain — an EVM 0x address for EVM destinations, or a base58 Solana pubkey for Solana destinations (now supported). Behavior is otherwise identical across EVM and Solana.\nQuerying Fees\nUse the /suggested-fees endpoint to get a full fee breakdown before executing a swap:\nquery-fees.tsconst params = new URLSearchParams({\n inputToken: \"0xaf88d065e77c8cC2239327C5EDb3A432268e5831\", // USDC on Arbitrum\n outputToken: \"0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913\", // USDC on Base\n originChainId: \"42161\",\n destinationChainId: \"8453\",\n amount: \"1000000000\", // 1000 USDC\n});\n\nconst res = await fetch(\n `https://app.across.to/api/suggested-fees?${params}`\n);\nconst fees = await res.json();\n\nconsole.log(\"Total relay fee:\", fees.totalRelayFee.total);\nconsole.log(\"LP fee pct:\", fees.lpFee.pct); // 1e16 = 1%, 1e18 = 100%\nconsole.log(\"Relayer capital fee:\", fees.relayerCapitalFee.total);\nconsole.log(\"Relayer gas fee:\", fees.relayerGasFee.total);\nconsole.log(\"Expected fill time:\", fees.expectedFillTimeSec, \"seconds\");\nconsole.log(\"Is amount too low?\", fees.isAmountTooLow);\nFee Response Fields\nFieldDescriptiontotalRelayFeeCombined LP + relayer feelpFeeLP fee component (pct format: 1e16 = 1%)relayerCapitalFeeRelayer capital opportunity costrelayerGasFeeRelayer destination gas costisAmountTooLowtrue if the amount is below the minimum for this routeexpectedFillTimeSecEstimated time for a relayer to filllimitsMin/max deposit amounts for instant and short-delay fills\nDo not cache fee responses. Fees change with market conditions, pool utilization, and gas prices. Always fetch fresh fees before presenting a quote to users.Handling Nested ParametersHow to encode tuples and struct parameters in embedded action function signatures.Actors in the SystemThe key participants that make crosschain transfers work — users, relayers, LPs, dataworkers, and the UMA oracle.","tokens":1391,"squid":"spider-09","role":"Bridge Spider","at":1791338962464,"hash":"da1ebfc3391953147c1bb007410325dc8f48cc02"}
{"url":"https://forum.arbitrum.foundation/t/arbitrum-proposals-app-govhack-brussels-winner/25370/1","domain":"forum.arbitrum.foundation","title":"Arbitrum Proposals App (GovHack Brussels Winner) - Archive / Archived Proposals - Arbitrum","text":"The Arbitrum Foundation notified the Security Council on the need to perform a potential Emergency action. Following a review of the details and known risks, the Security Council decided to execute the upgrade and it was completed at 11:30 EST on 2nd October 2026.\nThis report provides an overview of the risks that required the Security Council Action:\n\nAdd a permissionless guard for the One-Step Proof of BoLD on Arbitrum One\n\nTemporarily pause activation of new Stylus contracts on Arbitrum One & Nova\n\nKey point: To date, known bugs for Stylus primarily impact chain liveness (e.g., denial of service attacks) and do not put any user funds at risk.\nWhy was this action taken\nLet’s take this opportunity to explain why action was taken on two separate issues concerning BoLD and Stylus.\nInstalling the guard for One-Step Proof of BoLD. Given the rise of AI-assisted attacks, we have implemented a precautionary approach that allows anyone to pause settlement of Arbitrum One on Ethereum if there are at least two conflicting answers that pass at the same level in which only one should be valid and pass. This is to halt a class of publicly verifiable and detectable attacks that exploit a bug in the one-step proof. If halted, Arbitrum One will continue to process as normal except that messages from Arbitrum One to Ethereum, such as withdrawals, that are not yet confirmed will have to wait. This provides time for the Security Council to deploy a fix for the bug and resume the rollup.\nPreventing activation of new Stylus contracts. AI-assisted tooling has led to an increasing number of sophisticated attacks on hand-crafted WASM programs that do not use the standard Stylus compiler toolchain. These programs are specifically designed to cause unexpected behaviors such as degrading the chain’s performance for all other users. To date, no attacks have been discovered that permits theft of user funds.\nNew ArbOS releases have patched several reported bugs and known attacks over the past few months, but out of an abundance of caution, we have decided to temporarily pause new activations of Stylus contracts. This was executed as an emergency action to prevent the deployment of new hand-crafted WASM programs that are not yet patched by the current version of ArbOS on the Arbitrum network.\nThe Arbitrum Foundation has informed the Security Council that they will work with the ArbitrumDAO to discuss next steps on the timeline and manner for enabling activation of new Stylus contracts. The Arbitrum community remains confident in the value of Stylus and want to preserve these use cases while taking preventative measures against Stylus-based attack vectors as AI-assisted attack tooling continues to evolve.\nImpact on builders and users\n\nNo new activations. New Stylus contracts cannot be activated during the pause including new versions of existing applications that require activation.\n\nExisting contracts are not paused. Already-active Stylus contracts continue to execute until expiration. This pause does not deactivate them.\n\nThe ArbOS 61 upgrade renewed all active contracts on Arbitrum One, so no currently active contract expires before August 20, 2027.\n\nRenewal via keepalive stays permissionless and is unaffected by the pause.\n\nReactivating an expired contract, or one that needs to be updated after a Stylus version change, is paused.\n\nUsing/calling any activated Stylus contract stays permissionless for all users and developers.\n\nNo impact on EVM. Solidity (EVM) contract deployment and execution are unaffected by this Security Council action.\n\nSecurity Council Actions\nThere are two actions bundled into a single payload:\n\nOne-Step Proof Guard. The L1UpgradeExecutor gives a new pause contract (PauseExecutor) the ability to pause and nothing else. The new pause contract grants the guard (OspSoundnessGuard) PAUSER_ROLE to use it. Anyone can show the guard two conflicting answers to the same step of an open challenge. If the one-step proof accepts both, the guard has the pause contract put Arbitrum One’s settlement to Ethereum on hold.\n\nStylus deactivation. The Security Council called ArbOwner.setWasmActivationGas(2^64 - 1) to raise the Stylus activation gas requirement on Arbitrum One and Nova. This makes activation prohibitively expensive and effectively disables new activations. This is a configuration change and does not require an ArbOS upgrade.\n\nThe Security Council signed the following transactions to update the configuration:\n\nEthereum: Ethereum Transaction Hash: 0x30732bb7d2... | Etherscan\nArbitrum One:\nArbitrum One Transaction Hash: 0x9eb3a4be3b... | Arbitrum One\nArbitrum Nova:\nArbitrum Nova transaction 0x79e0fed470dff7a22059b108e3f8f42eddd2b580a6771594060c4e7326c5f984 | Blockscout\n\nAn external audit was conducted for the OSP Guard contracts. No audit is required for the Stylus deactivation as it is only updating a single parameter in the ArbOS configuration.\n\n Arbitrum Proposals App (GovHack Brussels Winner) \n\n ArchiveArchived Proposals\n\n proposal,governance,delegation,proposal-discussions\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jul 2024\n\n 1 / 36\n\n Jul 2024\n\n May 2025\n\n post by paulofonseca on Jul 6, 2024\n\n paulofonseca\n\nWe just got a smaller questbook grant approved to build this same scope of functionality over the next 4 months for a total of 43,000.00 USD. We will use this thread to record the progress of it and to report on the project milestones. Thank you all for your feedback along the way \n\nArbitrum Proposals App\nNon-Constitutional\nChallenge Statement:\nRight now, DAO delegates want to understand proposals efficiently and accurately, but proposal information is scattered all over the place (tweets, Discord servers, Telegram chats, discourse posts, offchain proposals [on snapshot], onchain proposals [on tally], etc.). This is a serious issue because it leads to unnecessary friction and inaccessibility in governance participation and, ultimately, poor decision-making for the Arbitrum DAO.\nTrack Name at GovHack Brussels: GovTech\nTeam Number at GovHack Brussels: 16\nMembers: andreiv.eth + paulofonseca.eth\nTeam Lead: Paulo Fonseca – @paulofonseca1987 on Telegram or @paulofonseca__ on Twitter\n2 minute Pitch: Posted on Youtube\nLow Fidelity Design Prototype: (this is unfinished and in-progress work, since it was started during the GovHack itself) arbitrum.proposals.app\nAbstract\nTo fund the design and development of an Arbitrum-focused responsive web app that shows all Arbitrum proposals across different stages in their lifecycle and aggregates information from Discourse, Snapshot, and the Arbitrum Onchain Governor contracts so that voters and delegates can more efficiently and accurately understand the context and the whole lifecycle of each proposal they should be voting on.\nMotivation\nThe current governance state-of-the-art is quite messy. This is not just an Arbitrum DAO problem but it affects Arbitrum DAO governance quite a lot. Still to this day, most governance processes in most big DAOs are spread across multiple platforms and systems, from messaging apps like Discord, Telegram and Twitter, to Discourse forums, to offchain voting platforms like Snapshot and then to onchain voting front-ends like Tally.\nIn each of these platforms, delegates need to keep themselves up to date, review information about proposals coming to vote in the DAO and form their opinions about whether they should support a particular proposal. Delegates are also expected to actively share their concerns and provide feedback on proposals throughout the lifecycle of a proposal so that the proposal can advance through the several stages of the governance process successfully.\nFor a delegate, even to the most competent ones, to keep up with all of this information scattered around different sources is… overwhelming, to say the least. \nAs an example, this is roughly what happens when a delegate (or anybody else for that matter) tries to understand the context and form an opinion about an important Arbitrum proposal like the Gaming Catalyst Program that just recently passed.\n\nFull video can be seen here.\nIf we expect more and better delegates to keep up with governance proposals adequately, we should invest in appropriate tooling to make their jobs much easier than they currently are.\nRationale\nThis proposal aligns with Arbitrum’s mission and community values by making the Arbitrum DAO more innovative, open, accessible, and inclusive to delegates and voters by allowing them another choice as users of Arbitrum’s DAO governance.\nMore specifically, the last community value in The Amended Constitution of the Arbitrum DAO, but to us, one of the most important community values, the one of attempting to be:\n\nNeutral and open: Arbitrum governance should not pick winners and losers, but should foster open innovation, interoperation, user choice, and healthy competition on Arbitrum chains.\n\nWe know Tally has a great partnership with the Arbitrum DAO, and we are grateful for all the work the Tally team has done over more than a year to support the governance of Arbitrum DAO. We support their developments and future roadmap and are open to collaborating in any way to improve the user experience of delegates and voters in their day-to-day.\nWe also believe it is important for the Arbitrum DAO not to be vendor-locked in. More specifically, on the front end it offers its delegates and voters that allows them to participate in Arbitrum DAO’s onchain governance.\nWe believe there should be multiple front-ends to Arbitrum DAO’s onchain governance, so that we can attract more and better delegates and voters by providing them tools that suit their particular needs.\nWe also strongly believe that at least one of those front-ends should be fully open-source. For the obvious matters of the resilience of Arbitrum’s DAO governance, we believe there should be a fully open-source front-end for Arbitrum’s DAO on-chain governance that would allow delegates and voters to continue to participate in governance permissionlessly. proposals.app is fully open source and will continue to be. proposals.app and its future developments can also be self-hosted by anyone (like we’re doing now) under a new domain name, at any time.\nSpecifications\nHow might we enable DAO delegates, to get a more complete picture of how a proposal has evolved and what other people think about it, so that they can make a more informed voting decision, resulting in higher quality governance outcomes for the DAO?\nThis guiding question and a bunch of conversations and user research with DAO Delegates both in GovHack and previously when we were building Senate, has led us to believe that there is a need for a unified view of a canonical DAO proposal page that covers the whole proposal lifecycle, or at the very least, from the “initial Discourse forum post” stage to the “onchain execution” stage, obviously including temperature check poll on Snapshot, and onchain voting.\nAt proposals.app we already fetch Arbitrum’s DAO offchain and onchain proposals, and we also offer free email notifications to anybody that subscribes on the site. Everytime there is a new Arbitrum DAO proposal available, delegates and voters that have subscribed to proposals.app notifications, will get a fresh email in their inbox that looks like this.\n\nCurrently, we are linking each offchain or onchain proposal to their respective Snapshot.org or Tally.xyz links so delegates and voters can easily exercise their governance rights.\nWith this project we will build a Unified Proposal Lifecycle page, that merges the information of offchain and onchain votes for the same proposal, so that delegates and voters can have easier access to all of the information of a proposal in a single place.\nThis Unified Proposal Lifecycle page will show information from the proposal’s Discourse post, from the Snapshot temperature check poll, and from the onchain vote.\nThe challenge to be able to achieve this is to include all relevant information in the right way, at the right time, so delegates and voters don’t feel overwhelmed by it.\nWe’ve been mapping the proposal elements across several platforms and feel confident we have a model that captures a proposal standard that is able to show the proposal lifecycle and how the proposal has evolved, and that will help delegates and voters get more transparency into the journey of a proposal and the context it’s current or final state.\n\nWe will need to also manually map the discourse posts to the Snapshot polls and then to the onchain votes. Which is something that is not trivial to do for all past Arbitrum DAO’s proposals, but we will create a backoffice where a governance analyst can links all data sources of a proposal, to be shown in the Unified Proposal Lifecycle page.\nSteps to Implement\nWe have a 2 part plan for this project:\n\nDesign and Develop V1 of the Unified Proposal Lifecycle Page, which will include data and the mapping between Snapshot proposal data and Onchain proposal data.\nDesign and Develop the V2 of the Unified Proposal Lifecycle Page that would add Discourse Post data.\n\nAlongside this main plan, we need to create a mechanism to map discourse posts to Snapshot polls and then to onchain votes, so that eventually that mapping doesn’t need to be done manually for every proposal.\nWe are talking to @amanwithwings to move forward a daoURI standard in the Arbitrum DAO that could be extended so that Arbitrum DAO onchain proposals would include the link to their Discourse post in the onchain proposal metadata.\nOnce that standard would be adopted by the Arbitrum DAO, we would be able to automate the mapping of data for a single proposal. Until then, we will do it manually and very deliberately. \nTimeline\nWe will deliver the complete solution described above within a maximum of four months of the project’s kick-off.\nThe project kick-off is on October 15th, 2024, and we commit to deliver the completed project with all it’s Milestones and deliverables by February 14th, 2025.\nMilestone #1\nDeadline: 30 days after project kick-off\nDeliverables: Create the back-end discourse indexing system and mapping backoffice to map discourse data to snapshot and onchain proposals + Setup of self-hosted infrastructure with a real-time status page monitoring\nMilestone #2\nDeadline: 60 days after project kick-off, 30 days after Milestone #1\nDeliverables: Interactive Design Prototype Deliverable\nMilestone #3\nDeadline: 90 days after project kick-off, 30 days after Milestone #2\nDeliverables: Development of a responsive Unified Proposal Lifecycle webpage\nMilestone #4\nDeadline: 120 days after project kick-off, 30 days after Milestone #3\nDeliverables: Testing, Quality Assurance and Data Validation of all past proposals data\nAfter completing the project, we commit to maintaining and ensuring the resilient hosting of the web app for at least 24 months from the project kick-off date.\nOverall Cost\nThe overall cost for this 4 month long project totals $43,000 USD\n\nMonthly Amount\nDuration\nTotal Amount\n\nDesigner\n$5,000 USD\n3 months\n$15,000 USD\n\nDeveloper\n$5,000 USD\n3 months\n$15,000 USD\n\nGovernance Analyst\n$1,000 USD\n1 month\n$1,000 USD\n\nServers and Hosting\n$500 USD\n24 months\n$12,000 USD\n\nDuring these four months, we will ship 4 deliverables, the first at Milestone #1 at the 30 day mark, the second at Milestone #2 at the 60 day mark, the third at Milestone #3 at the 90 day mark and the fourth at Milestone #4 at the 120 day mark.\nThe kick-off stage marks the beginning of the project after a successful acceptance of the questbook grant.\nWe believe in performance-based compensation, so we will only be compensated upon value delivery after successfully delivering each of the Milestones.\nPayment schedule\n\nKick-off\nMilestone #1\nMilestone #2\nMilestone #3\nMilestone #4\n\nDeadline\nDay 1\nDay 30\nDay 60\nDay 90\nDay 120\n\nPayment\n$0 USD\n$10,000 USD\n$15,000 USD\n$15,000 USD\n$3,000 USD\n\nFor the multisig, we will use a Gnosis Safe multisig on Arbitrum One which has andreiv.eth and paulofonseca.eth as signers. From that multisig, all contributors and expenses will be paid at our discretion, but still fully transparently and, of course, onchain. \n\nThank you for reading this proposal until the end, and please give us your honest and harshest feedback. We know we need it, and we truly welcome it! \nAlso, special thanks to @DisruptionJoe, @hiringdevs.eth, @cliffton.eth, @JoJo and anybody else who provided valuable feedback on this proposal during GovHack Brussels and afterwards!\n\n 16 Jul 2024 - Open Discussion of Proposals Governance Call\n\n Paulo Fonseca – Voluntary Earnings Disclosure Thread\n\n GovHack ETHcc Brussels 2024 - Impact Report - Hack Humanity\n\n Improving Predictability in Arbitrum DAO’s Operations\n\n [Election & Application Thread] Arbitrum D.A.O. (Domain Allocator Offerings) Grant Program\n\n 21\n\n 2\n\n 2\n\n 2\n\n read \n\n 10\n min\n\n post by andreiv on Jul 7, 2024\n\n post by ismailemin on Jul 7, 2024\n\n post by paulofonseca on Jul 7, 2024\n\n post by dennison on Jul 7, 2024\n\n post by paulofonseca on Jul 7, 2024\n\n post by emjicy on Jul 7, 2024\n\n post by paulofonseca on Jul 8, 2024\n\n post by paulofonseca on Jul 11, 2024\n\n post by Bau on Jul 12, 2024\n\n post by paulofonseca on Jul 12, 2024\n\n 8 days later\n\n post by paulofonseca on Jul 21, 2024\n\n post by paulofonseca on Jul 22, 2024\n\n post by jameskbh on Jul 22, 2024\n\n post by paulofonseca on Jul 22, 2024\n\n post by jameskbh on Jul 23, 2024\n\n post by paulofonseca on Jul 24, 2024\n\n post by paulofonseca on Jul 24, 2024\n\n post by Tane on Jul 30, 2024\n\n post by paulofonseca on Jul 31, 2024\n\n Load more posts below","tokens":4406,"squid":"spider-07","role":"Council Spider","at":1791338964426,"hash":"3077b70495f537ec869809c75339aa3369ce4907"}
{"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":"spider-05","role":"Spec Spider","at":1791338965910,"hash":"9b1b91f47a22737d7105cc2706e2b9c9ba7d06c1"}
{"url":"https://docs.across.to/introduction/hypercore-withdrawals","domain":"docs.across.to","title":"Hyperliquid Withdrawals | Across Docs","text":"Hyperliquid WithdrawalsWithdraw from Hyperliquid (HyperCore) to any Across-supported chain via a gasless multi-signature flow.HyperCore is Hyperliquid's margin and matching engine. To move funds off it, the user signs EIP-712 typed signatures that Across submits on-chain. Across handles the HyperCore → HyperEVM lift and delivery to the destination chain.\nAPI key with swap-gasless permission required. Get an API key + Integrator ID.\nEndpoints in order of integration\nMethodPathPurposeGET/swap/gaslessQuote — returns the steps the user must signPOST/gasless/submitSubmit signed steps; relayer takes over from hereGET/deposit/status?depositId=...&originChainId=1337Track the withdrawal to terminal status\nSupported Hyperliquid Origin Tokens\nSymbolinputToken valueDecimalsBalance lives inUSDC-spot0x20000000000000000000000000000000000000008HL spotUSDC-perps0x21000000000000000000000000000000000000008HL perps marginHYPE0x22222222222222222222222222222222222222228HL spotUSDT (USDT-SPOT)0x200000000000000000000000000000000000010C8HL spot\nThe 0x2… addresses are HyperCore sentinels — they are not HyperEVM ERC-20s. Destinations: any EVM chain Across supports.\nEnd-to-end integration flow\nQuoteGET /swap/gasless\n ?inputToken=0x2100000000000000000000000000000000000000 # USDC-PERPS\n &originChainId=1337 # HyperCore\n &outputToken=0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913 # USDC on Base\n &destinationChainId=8453 # Base\n &amount=100000000 # 1 USDC (8 decimals on HC)\n &depositor=<user EOA>\n &recipient=<destination addr>\n &integratorId=<your id>Decimals trap. amount is in the input token's decimals. HyperCore tokens use 8 decimals (HyperEVM and standard EVM USDC use 6) — passing a 6-decimal value for an 8-decimal HyperCore input under-bridges by 100×.Returns depositId, the steps to sign in swapTxns[], quoteExpiryTimestamp, expectedOutputAmount, minOutputAmount, and fees (the submission fee is at fees.submission — there is no top-level submissionFees).Submission fee — the amount (in the input token) paid to the submitter that broadcasts your signed permit on-chain in the gasless flow, reimbursing their gas plus margin.It's part of the signed witness (submissionFees: { amount, recipient }), so the user authorizes the exact fee and payee when signing — no separate gas payment from the user.See the API reference for the full response shape.Sign every stepIterate swapTxns and dispatch by step.ecosystem. The user signs every step — missing signatures are rejected at submit. Please note that even if a single signature is unsigned or signed incorrectly, the transaction will not go through.const sigs: Record<string, string> = {};\nfor (const step of quote.swapTxns) {\n if (step.ecosystem === 'hypercore') {\n sigs[step.stepId] = await hlSign(step.typedData); // HL wallet\n } else if (step.ecosystem === 'evm-gasless') {\n sigs[step.stepId] = await evmSign(step.typedData); // EVM EOA — EIP-712\n }\n}evm-gasless chainId gotcha. Sign at step.typedData.domain.chainId (always 999 / HyperEVM), NOT the outer step.chainId. If you use a single EVM wallet for both ecosystems, make sure it is on chain 999 before signing every step. Wrong-chain signatures fail server-side verifyTypedData.SubmitPOST /gasless/submit\n{\n \"swapTx\": <quote.swapTx>,\n \"swapTxns\": <quote.swapTxns>,\n \"signaturesByStepId\": { \"hypercore-transfer\": \"0x…\", \"gasless-auth\": \"0x…\" }\n}Returns { depositId, messageId, id } (messageId may be null). Submit is gated in two stages: (1) every signature must recover to the depositor (else 400 \"Invalid signature: unable to verify signature\"); (2) the integrator key must be eligible for gasless submission (else 403). It is accepted optimistically — a 200 is returned before on-chain execution, so an underfunded withdrawal still returns 200 and later surfaces as deposit-failed.See the API reference for the full response shape.Track statusPoll /deposit/status with the depositId and originChainId=1337:GET /deposit/status?depositId=<id>&originChainId=1337StatusMeaningdeposit-pendingHyperCore → HyperEVM lift in progressdeposit-failedLift failed (e.g. insufficient HyperCore balance); funds not moved (terminal)filledDestination tokens delivered (terminal)expiredDestination tokens were not delivered within the fillDeadline and the user is now eligible for a refundrefundedTerminal state; user has received a refundSee the API reference for the full response shape.Refunds land on HyperEVM, not HyperCore. refundToken.chainId on bridging quotes is 999. Set refundOnOrigin: true and surface the destination in your UI — users won't expect refunds to arrive on HyperEVM.\nGas Fees\nHyperCore → HyperEVM mirror moves cost a small HyperEVM gas fee.\n\nUSDC / USDT origin — fee is paid in-kind or auto-deducted in HYPE. Users don't need to think about it.\nHYPE / non-stablecoin origin — users must hold HYPE on HyperCore to cover gas.\n\nThis lift cost is reported at fees.submission on every quote (a flat amount in the submission token, independent of size). fees.total / fees.totalMax cover any protocol/relayer spread — 0 for same-asset USDC routes.\nMinimal Example: HC USDC-PERPS → Base ETH\nconst quote = await fetch(`${BASE}/swap/gasless?inputToken=0x2100…&…`).then(r => r.json());\n\nconst sigs: Record<string, string> = {};\nfor (const step of quote.swapTxns) {\n sigs[step.stepId] = step.ecosystem === 'hypercore'\n ? await hlSign(step.typedData)\n : await evmSign(step.typedData);\n}\n\nconst { depositId } = await fetch(`${BASE}/gasless/submit`, {\n method: 'POST',\n body: JSON.stringify({\n swapTx: quote.swapTx,\n swapTxns: quote.swapTxns,\n signaturesByStepId: sigs,\n }),\n}).then(r => r.json());\n\nwhile (true) {\n const { status } = await fetch(\n `${BASE}/deposit/status?depositId=${depositId}&originChainId=1337`,\n ).then(r => r.json());\n if (['filled', 'expired', 'refunded', 'deposit-failed'].includes(status)) break;\n await new Promise(r => setTimeout(r, 2000));\n}\nCaveats\n\nHL nonces are wallet-unique. If your client races two quotes, sign + submit them in order — HL will reject a later nonce that arrives first as stale.\nQuote expiry is short (typically 60–120s). After quoteExpiryTimestamp, re-quote; submitting a stale quote returns a witness-binding error.\nDon't mutate swapTx or swapTxns between quote and submit. The submit endpoint re-validates byte-for-byte; any drift returns a deep-equal error.\nTrust fees.submission.amount from the quote rather than computing the lift fee yourself.\nVery large amounts may exceed a route's available liquidity and return 400 AMOUNT_TOO_HIGH (the max is in the message).\nrecipient ≠ depositor is fine — but the depositor EOA must own the HC funds and sign every step.\n\nAll validation errors return 400 InvalidParamError with a param field telling you which input to fix. Most \"re-quote\" errors are TOCTOU freshness checks — retrying the same body will keep failing.\nReferences\n\nGET /swap/gasless — quote endpoint reference\nPOST /gasless/submit — submit endpoint reference\nWorking with Hypercore — companion deposits guide\nTracking Deposits — generic deposit polling for non-gasless flows\nRefunds — refund mechanics on Across\nWorking with HypercoreBridge assets to Hyperliquid's sub-second settlement layer via Across.Embedded Crosschain ActionsExecute custom on-chain operations on the destination chain immediately after a crosschain swap.","tokens":1823,"squid":"spider-09","role":"Bridge Spider","at":1791338972518,"hash":"1a3f17932a31306947e9c187d773d4376dfc562c"}
{"url":"https://forum.arbitrum.foundation/t/arbitrum-proposals-app-govhack-brussels-winner/25370/36","domain":"forum.arbitrum.foundation","title":"Arbitrum Proposals App (GovHack Brussels Winner) - Archive / Archived Proposals - Arbitrum","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 21\n\n 2\n\n 2\n\n 2\n\n read \n\n 10\n min\n\n Jul 2024\n\n 36 / 36\n\n May 2025\n\n May 2025\n\n Load more posts above\n\n post by paulofonseca on Jul 24, 2024\n\n post by paulofonseca on Jul 24, 2024\n\n post by Tane on Jul 30, 2024\n\n post by paulofonseca on Jul 31, 2024\n\n post by Tane on Jul 31, 2024\n\n post by paulofonseca on Jul 31, 2024\n\n post by paulofonseca on Jul 31, 2024\n\n 15 days later\n\n post by cp0x on Aug 15, 2024\n\n post by paulofonseca on Aug 18, 2024\n\n 2 months later\n\n post by paulofonseca on Oct 15, 2024\n\n post by paulofonseca on Oct 17, 2024\n\n 2 months later\n\n post by Uhthred on Dec 16, 2024\n\n 4 months later\n\n post by Zobasky042 on Apr 17, 2025\n\n 23 days later\n\n post by paulofonseca on May 11, 2025\n\n post by paulofonseca on May 13, 2025\n\n post by paulofonseca on May 13, 2025\n\n post by paulofonseca on May 13, 2025\n\n paulofonseca\n\n We launched the app during ETH Bucharest 2025, on April 4th, and you can just try it out at arbitrum.proposals.app and tell us what you think about it.\n\n post by cp0x on May 14, 2025\n\n cp0x\n\n Thanks for the app\nOf the obvious pros:\n\nyou can immediately see who submitted the proposal\nyou can see how much longer the voting will last\nyou can see the quorum\n\nOf the cons:\n\nyou can add % of votes (at least this information is important to me, I understand how supported this proposal is)\nit would be good to leave all the same information for those votes that have already taken place, otherwise you have to open them one by one to understand - accepted or not, whether there was a quorum or not\nit is not obvious that the list contains not only votes, but also discussions of future votes, perhaps they should be highlighted somehow\n\n post by Obitrum on May 17, 2025\n\n Obitrum\n\n Is there plans to include allowing people to vote for a given proposal directly through this app? My thought process is since people are there already it could be helpful to allow them to make/edit their votes after going through the consolidated information.\n\n post by EmmanuelO on May 19, 2025\n\n EmmanuelO\n\n I second this it would as help against having a single point of failure\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [Non-Constitutional] Let’s improve our governance forum with three proposals.app feature integrations\n\n Archived Proposals\n\n proposal,governance,proposal-discussions\n\n 83\n\n 2.2k\n\n Jun 2025\n\n Team #6: An (EIP-4824 powered) daoURI for the Arbitrum DAO\n\n GovHack Brussels\n\n 53\n\n 1.2k\n\n Oct 2024\n\n Frisson Delegate Communication Thread\n\n Delegate Statements\n\n delegation,delegate-statements\n\n 76\n\n 1.1k\n\n Apr 2025\n\n [REPORTS THREAD] New Protocols and Ideas Domain 2.0\n\n Domain Allocator Offerings (prev Questbook)\n\n 1\n\n 210\n\n Oct 2024\n\n Improving Predictability in Arbitrum DAO’s Operations\n\n Finalized AIPs\n\n proposal\n\n 59\n\n 1.9k\n\n Aug 2024","tokens":726,"squid":"spider-07","role":"Council Spider","at":1791338974571,"hash":"92aa349c9438d2e96b1044f3be542216c3c563cb"}
{"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":"spider-01","role":"Chain Spider","at":1791338980622,"hash":"9eaedd856305e9b7510452a40f763ca3a2196167"}
{"url":"https://docs.across.to/introduction/swap-api","domain":"docs.across.to","title":"Introduction to Swap API | Across Docs","text":"Introduction to Swap APIThe unified entry point for all crosschain operations on Across.The Swap API is Across's single entry point for all crosschain operations — bridging, swapping, and embedded actions. One unified interface at /swap/approval quotes any route; Across selects the best settlement path automatically, so your integration stays the same regardless of token, amount, or chain.\nAPI key required for production. Get your API key and Integrator ID to authenticate your requests.\nTrade Types\nThe tradeType parameter controls how the swap amount is interpreted.\nSpend exactly this amount, receive whatever the market gives.Use when the user specifies how much they want to send. The output amount varies based on fees, slippage, and exchange rates.tradeType=exactInput&amount=1000000000Receive at least this amount, spend whatever is needed.Use when the user has a minimum acceptable output. The API calculates the required input. This is the recommended default for most integrations.tradeType=minOutput&amount=1000000000Receive exactly this amount.Use when the user needs a precise output. Stricter than minOutput — the API will fail if the exact amount can't be delivered. Set strictTradeType=true to enforce.tradeType=exactOutput&amount=1000000000&strictTradeType=true\nBase URLs\nEnvironmentBase URLProductionhttps://app.across.to/api\nRequired Parameters\nParameterTypeDescriptiontradeTypestringexactInput, minOutput, or exactOutputamountstringAmount in smallest unit (e.g., 1000000 = 1 USDC)inputTokenstringToken address on origin chainoutputTokenstringToken address on destination chainoriginChainIdnumberOrigin chain IDdestinationChainIdnumberDestination chain IDdepositorstringWallet address initiating the transfer\nOptional Parameters\nParameterTypeDescriptionrecipientstringDestination address (defaults to depositor)integratorIdstring2-byte hex identifier for your integrationslippagestring\"auto\" or a value between 0-1 (default: auto)refundAddressstringAddress for refunds if fill expiresrefundOnOriginbooleanRefund on origin chain instead of destinationappFeestringIntegrator fee as decimal 0-1 (e.g., \"0.01\" = 1%). Charged in the output token on the destination chainappFeeRecipientstringAddress that receives the app fee, on the destination chain — EVM hex, or a base58 Solana pubkey for Solana destinations. Required if appFee is setskipOriginTxEstimationbooleanSkip gas estimation for the origin transactionstrictTradeTypebooleanFail if exact trade type can't be satisfiedexcludeSourcesstringComma-separated swap sources to excludeincludeSourcesstringComma-separated swap sources to include exclusively\nSee the GET /swap/approval API reference for the complete, always-current parameter list and response schema.\nResponse Structure\nThe /swap/approval response contains everything needed to execute the crosschain transfer.\nresponse-structure.json{\n \"crossSwapType\": \"bridgeableToBridgeable\",\n \"checks\": {\n \"allowance\": { \"token\": \"0x...\", \"spender\": \"0x...\", \"actual\": \"0\", \"expected\": \"1000000\" },\n \"balance\": { \"token\": \"0x...\", \"actual\": \"5000000\", \"expected\": \"1000000\" }\n },\n \"approvalTxns\": [\n { \"chainId\": 42161, \"to\": \"0x...\", \"data\": \"0x...\" }\n ],\n \"steps\": {\n \"bridge\": { \"inputAmount\": \"1000000\", \"outputAmount\": \"998000\" }\n },\n \"fees\": {\n \"total\": \"2000\",\n \"totalMax\": \"3000\",\n \"originGas\": \"50000\"\n },\n \"swapTx\": {\n \"simulationSuccess\": true,\n \"chainId\": 42161,\n \"to\": \"0x...\",\n \"data\": \"0x...\",\n \"value\": \"0\",\n \"gas\": \"250000\",\n \"maxFeePerGas\": \"100000000\",\n \"maxPriorityFeePerGas\": \"1500000\"\n },\n \"expectedFillTime\": 2,\n \"quoteExpiryTimestamp\": 1700000000\n}\nKey fields:\n\ncrossSwapType — The routing path: bridgeableToBridgeable, bridgeableToBridgeableIndirect, bridgeableToAny, anyToBridgeable, or anyToAny\nchecks — Current allowance and balance status for the depositor\napprovalTxns — Token approval transactions to execute before the swap (may be empty)\nswapTx — The main swap transaction calldata\nexpectedFillTime — Estimated seconds until the destination fill\nquoteExpiryTimestamp — Unix timestamp when this quote expires\n\nFull Integration Example\nswap-viem.tsimport { createWalletClient, createPublicClient, http, parseUnits } from \"viem\";\nimport { arbitrum } from \"viem/chains\";\nimport { privateKeyToAccount } from \"viem/accounts\";\n\nconst account = privateKeyToAccount(\"0xYOUR_PRIVATE_KEY\");\n\nconst walletClient = createWalletClient({\n account,\n chain: arbitrum,\n transport: http(),\n});\n\nconst publicClient = createPublicClient({\n chain: arbitrum,\n transport: http(),\n});\n\nasync function executeSwap() {\n // 1. Get quote\n const params = new URLSearchParams({\n tradeType: \"minOutput\",\n originChainId: \"42161\",\n destinationChainId: \"8453\",\n inputToken: \"0xaf88d065e77c8cC2239327C5EDb3A432268e5831\", // USDC on Arbitrum\n outputToken: \"0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913\", // USDC on Base\n amount: parseUnits(\"100\", 6).toString(), // 100 USDC\n depositor: account.address,\n integratorId: \"0xdead\",\n });\n\n const res = await fetch(\n `https://app.across.to/api/swap/approval?${params}`,\n {\n headers: {\n Authorization: \"Bearer YOUR_API_KEY\",\n },\n }\n );\n const quote = await res.json();\n\n if (!quote.swapTx) {\n throw new Error(`Quote failed: ${JSON.stringify(quote)}`);\n }\n\n // 2. Execute approval transactions\n if (quote.approvalTxns?.length) {\n for (const approvalTx of quote.approvalTxns) {\n const hash = await walletClient.sendTransaction({\n to: approvalTx.to,\n data: approvalTx.data,\n });\n await publicClient.waitForTransactionReceipt({ hash });\n console.log(\"Approval confirmed:\", hash);\n }\n }\n\n // 3. Execute swap\n const hash = await walletClient.sendTransaction({\n to: quote.swapTx.to,\n data: quote.swapTx.data,\n value: quote.swapTx.value ? BigInt(quote.swapTx.value) : 0n,\n gas: quote.swapTx.gas ? BigInt(quote.swapTx.gas) : undefined,\n });\n\n console.log(\"Swap tx:\", hash);\n console.log(\"Expected fill:\", quote.expectedFillTime, \"seconds\");\n\n return hash;\n}\n\nexecuteSwap();swap-ethers.tsimport { ethers } from \"ethers\";\n\nconst provider = new ethers.JsonRpcProvider(\"https://arb1.arbitrum.io/rpc\");\nconst wallet = new ethers.Wallet(\"0xYOUR_PRIVATE_KEY\", provider);\n\nasync function executeSwap() {\n // 1. Get quote\n const params = new URLSearchParams({\n tradeType: \"minOutput\",\n originChainId: \"42161\",\n destinationChainId: \"8453\",\n inputToken: \"0xaf88d065e77c8cC2239327C5EDb3A432268e5831\",\n outputToken: \"0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913\",\n amount: ethers.parseUnits(\"100\", 6).toString(),\n depositor: wallet.address,\n integratorId: \"0xdead\",\n });\n\n const res = await fetch(\n `https://app.across.to/api/swap/approval?${params}`,\n {\n headers: {\n Authorization: \"Bearer YOUR_API_KEY\",\n },\n }\n );\n const quote = await res.json();\n\n if (!quote.swapTx) {\n throw new Error(`Quote failed: ${JSON.stringify(quote)}`);\n }\n\n // 2. Execute approval transactions\n if (quote.approvalTxns?.length) {\n for (const approvalTx of quote.approvalTxns) {\n const tx = await wallet.sendTransaction({\n to: approvalTx.to,\n data: approvalTx.data,\n });\n await tx.wait();\n console.log(\"Approval confirmed:\", tx.hash);\n }\n }\n\n // 3. Execute swap\n const tx = await wallet.sendTransaction({\n to: quote.swapTx.to,\n data: quote.swapTx.data,\n value: quote.swapTx.value || 0,\n });\n\n console.log(\"Swap tx:\", tx.hash);\n console.log(\"Expected fill:\", quote.expectedFillTime, \"seconds\");\n\n return tx.hash;\n}\n\nexecuteSwap();\nIntegrator ID required for production. You must obtain a 2-byte hex integrator ID (e.g., 0xdead) before launching in production. Get your API key and Integrator ID. Without it, your requests may be rate-limited or rejected.\nHelper Endpoints\nThese endpoints help you discover supported routes, tokens, and fee estimates before calling /swap/approval.\nEndpointMethodDescription/swap/chainsGETList all supported chains/swap/tokensGETList all supported tokens per chain/swap/sourcesGETList swap providers (DEX sources)/suggested-feesGET(legacy) Get fee breakdown for a specific route/limitsGETGet transfer limits (min, max, instant, short-delay)/available-routesGETGet all available origin → destination routes\nComing from /suggested-fees + direct depositV3? See Migrate from Suggested Fees to the Swap API.\nIntegrator ID required for production. You must obtain a 2-byte hex integrator ID (e.g., 0xdead) before launching in production. Get your API key and Integrator ID. Without it, your requests may be rate-limited or rejected.\nDo not cache /swap/approval or /suggested-fees responses. Quotes expire quickly and fees change with market conditions. The only stateful endpoint is /deposit/status.Direct Route LinkingLink users directly to a pre-filled bridge route on the Across UI.Working with HypercoreBridge assets to Hyperliquid's sub-second settlement layer via Across.","tokens":2180,"squid":"spider-09","role":"Bridge Spider","at":1791338983477,"hash":"1b4aed27deae944cbfb7842c5c340c4943ff25ab"}
{"url":"https://forum.arbitrum.foundation/c/archive/govhack-brussels/41","domain":"forum.arbitrum.foundation","title":"Latest Archive/GovHack Brussels topics - Arbitrum","text":"The Arbitrum Foundation notified the Security Council on the need to perform a potential Emergency action. Following a review of the details and known risks, the Security Council decided to execute the upgrade and it was completed at 11:30 EST on 2nd October 2026.\nThis report provides an overview of the risks that required the Security Council Action:\n\nAdd a permissionless guard for the One-Step Proof of BoLD on Arbitrum One\n\nTemporarily pause activation of new Stylus contracts on Arbitrum One & Nova\n\nKey point: To date, known bugs for Stylus primarily impact chain liveness (e.g., denial of service attacks) and do not put any user funds at risk.\nWhy was this action taken\nLet’s take this opportunity to explain why action was taken on two separate issues concerning BoLD and Stylus.\nInstalling the guard for One-Step Proof of BoLD. Given the rise of AI-assisted attacks, we have implemented a precautionary approach that allows anyone to pause settlement of Arbitrum One on Ethereum if there are at least two conflicting answers that pass at the same level in which only one should be valid and pass. This is to halt a class of publicly verifiable and detectable attacks that exploit a bug in the one-step proof. If halted, Arbitrum One will continue to process as normal except that messages from Arbitrum One to Ethereum, such as withdrawals, that are not yet confirmed will have to wait. This provides time for the Security Council to deploy a fix for the bug and resume the rollup.\nPreventing activation of new Stylus contracts. AI-assisted tooling has led to an increasing number of sophisticated attacks on hand-crafted WASM programs that do not use the standard Stylus compiler toolchain. These programs are specifically designed to cause unexpected behaviors such as degrading the chain’s performance for all other users. To date, no attacks have been discovered that permits theft of user funds.\nNew ArbOS releases have patched several reported bugs and known attacks over the past few months, but out of an abundance of caution, we have decided to temporarily pause new activations of Stylus contracts. This was executed as an emergency action to prevent the deployment of new hand-crafted WASM programs that are not yet patched by the current version of ArbOS on the Arbitrum network.\nThe Arbitrum Foundation has informed the Security Council that they will work with the ArbitrumDAO to discuss next steps on the timeline and manner for enabling activation of new Stylus contracts. The Arbitrum community remains confident in the value of Stylus and want to preserve these use cases while taking preventative measures against Stylus-based attack vectors as AI-assisted attack tooling continues to evolve.\nImpact on builders and users\n\nNo new activations. New Stylus contracts cannot be activated during the pause including new versions of existing applications that require activation.\n\nExisting contracts are not paused. Already-active Stylus contracts continue to execute until expiration. This pause does not deactivate them.\n\nThe ArbOS 61 upgrade renewed all active contracts on Arbitrum One, so no currently active contract expires before August 20, 2027.\n\nRenewal via keepalive stays permissionless and is unaffected by the pause.\n\nReactivating an expired contract, or one that needs to be updated after a Stylus version change, is paused.\n\nUsing/calling any activated Stylus contract stays permissionless for all users and developers.\n\nNo impact on EVM. Solidity (EVM) contract deployment and execution are unaffected by this Security Council action.\n\nSecurity Council Actions\nThere are two actions bundled into a single payload:\n\nOne-Step Proof Guard. The L1UpgradeExecutor gives a new pause contract (PauseExecutor) the ability to pause and nothing else. The new pause contract grants the guard (OspSoundnessGuard) PAUSER_ROLE to use it. Anyone can show the guard two conflicting answers to the same step of an open challenge. If the one-step proof accepts both, the guard has the pause contract put Arbitrum One’s settlement to Ethereum on hold.\n\nStylus deactivation. The Security Council called ArbOwner.setWasmActivationGas(2^64 - 1) to raise the Stylus activation gas requirement on Arbitrum One and Nova. This makes activation prohibitively expensive and effectively disables new activations. This is a configuration change and does not require an ArbOS upgrade.\n\nThe Security Council signed the following transactions to update the configuration:\n\nEthereum: Ethereum Transaction Hash: 0x30732bb7d2... | Etherscan\nArbitrum One:\nArbitrum One Transaction Hash: 0x9eb3a4be3b... | Arbitrum One\nArbitrum Nova:\nArbitrum Nova transaction 0x79e0fed470dff7a22059b108e3f8f42eddd2b580a6771594060c4e7326c5f984 | Blockscout\n\nAn external audit was conducted for the OSP Guard contracts. No audit is required for the Stylus deactivation as it is only updating a single parameter in the ArbOS configuration.\n\n Latest topics in GovHack Brussels\n\n Archive\n\n GovHack Brussels\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 Making an Awesome Ventures Track at GovHack\n\n 0\n\n 135\n\n Dec 2024\n\n Team #6: An (EIP-4824 powered) daoURI for the Arbitrum DAO\n\n 53\n\n 1.2k\n\n Oct 2024\n\n Team 17 - Arbitrum DAO Treasury Diversifying Through RWA Assets\n\n 2\n\n 316\n\n Sep 2024\n\n GovHack ETHcc Brussels 2024 - Impact Report - Hack Humanity\n\n 19\n\n 781\n\n Sep 2024\n\n Team 1 - Arbitrum DAO Onboarding Framework Experimental\n\n proposal\n\n 1\n\n 189\n\n Aug 2024\n\n Team #16 - Arbitrum Proposals App\n\n 0\n\n 36\n\n Aug 2024\n\n Team #18 - Research, Development, and Quality Assurance Squad to help Arbitrum build the first decentralized sequencer stack\n\n 2\n\n 203\n\n Jul 2024\n\n Team 28: Arbitrum Mascot and Merchandise Development Initiative\n\n proposal,governance\n\n 1\n\n 507\n\n Jul 2024\n\n Team 14: Proposal for Delegate Transparency in Arbitrum DAO\n\n 7\n\n 249\n\n Jul 2024\n\n Team 4: Jumpstart fund for DAO improvement\n\n proposal\n\n 5\n\n 372\n\n Jul 2024\n\n Team 10 + DeCredit Score\n\n 4\n\n 169\n\n Jul 2024\n\n Team #24 - Memebyosis: Arbitrum Memecoin Accelerator\n\n 1\n\n 142\n\n Jul 2024\n\n Team 27 ArbitrumAgent: Empowering Decentralized Governance and Development with AI\n\n proposal,governance,proposal-discussions\n\n 0\n\n 131\n\n Jul 2024\n\n Team 3 + Reducing web3 Governance Gaps in Global South\n\n 1\n\n 137\n\n Jul 2024\n\n Team 9: Bringing Transparency to Arbitrum DAO’s Treasury: The Arbitrum DAO Dashboard\n\n 0\n\n 218\n\n Jul 2024\n\n Team 5- DelegAI\n\n 0\n\n 105\n\n Jul 2024\n\n TEAM 20 - Local Hubs Working Group\n\n 0\n\n 89\n\n Jul 2024\n\n 7 Bringing AI Delegation to Arbitrum\n\n 0\n\n 155\n\n Jul 2024\n\n Team 26: DevRel Uni cohort\n\n 0\n\n 174\n\n Jul 2024\n\n Team 12: Transparency and standardized metrics for Orbit chains on growthepie.xyz\n\n 0\n\n 122\n\n Jul 2024\n\n Team Number #19 - cofound3r: Aligning Builders, Programs, and Supporters\n\n 0\n\n 172\n\n Jul 2024\n\n Team 13: Orbit Ecosystem Development Fund\n\n 1\n\n 175\n\n Jul 2024\n\n 2 Scaling DevRel for Arbitrum Pilot\n\n 1\n\n 145\n\n Jul 2024\n\n Team 22 - Builders Hub - Developer Experience (DevEx) Dashboard for the Arbitrum Ecosystem\n\n 1\n\n 136\n\n Jul 2024\n\n Team 8: Decentralized Sequencing\n\n 1\n\n 314\n\n Jul 2024\n\n Team 11 # GAMING Attract Top Game Developers\n\n governance,proposal-discussions\n\n 1\n\n 162\n\n Jul 2024\n\n Team 15 - Arbitrum Activation Missions: Incentive Social Growth - GovHack Brussels\n\n 1\n\n 160\n\n Jul 2024\n\n GovHack Brussels Submission instructions\n\n 2\n\n 301\n\n Jul 2024","tokens":1851,"squid":"spider-07","role":"Council Spider","at":1791338996573,"hash":"4525b48c77ff763f4beca0b45ff20b829e8f3ca1"}
{"url":"https://portal.arbitrum.io/community","domain":"portal.arbitrum.io","title":"Arbitrum Community","text":"CommunityEngage with our resources to get involved with the Arbitrum communitySee what the 🐝 is aboutBlogRead words that are friendly to the less technical Arbitrum fansTwitter XHinged and unhinged takes on web3YouTubeWhy read when you can watch pretty moving pictures?Bug BountiesFind bugs, earn cash moneyJobs in the Arbitrum Ecosystem. Career opportunities to build a more secure and decentralized tomorrow.Learn MoreGet involved with governanceArbitrum FoundationLearn how the biggest and most secure Layer 2 is governedGovernance ForumBrowse Arbitrum Improvement Proposals and see what people are voting onResearch ForumDive deep into the weeds of technical discourseGrantsGet your project funded","tokens":176,"squid":"spider-01","role":"Chain Spider","at":1791339002643,"hash":"c1e65bf5dcb6b4d3d1599dab4ac086ee3831cc2e"}
{"url":"https://docs.across.to/introduction/direct-route-linking","domain":"docs.across.to","title":"Direct Route Linking | Across Docs","text":"Direct Route LinkingLink users directly to a pre-filled bridge route on the Across UI.Across's frontend supports direct route linking — construct a URL with query parameters to drop users directly into a pre-filled bridge route. No API calls, no wallet connection required upfront.\nHow It Works\nAppend query parameters to the base URL to pre-select the origin chain, destination chain, and tokens:\nhttps://app.across.to/bridge-and-swap?from=8453&to=42161&inputToken=BAL&outputToken=USDC\n\nThis opens the Across bridge with Base → Arbitrum selected and BAL → USDC as the token pair.\nParameterDescriptionExamplefromOrigin chain ID8453toDestination chain ID42161inputTokenInput token symbolBALoutputTokenOutput token symbolUSDC\nAll parameters are optional — use any combination.\nFor the full parameter reference, examples, chain ID table, and use cases, see the complete guide.Persistent Deposit AddressesOne POST returns a permanent deposit address — send funds from any supported origin chain and they are swept to your recipient on the destination.Introduction to Swap APIThe unified entry point for all crosschain operations on Across.","tokens":284,"squid":"spider-09","role":"Bridge Spider","at":1791339005307,"hash":"d27dcfce17d4bb68345a326b860508390d22ab55"}
{"url":"https://forum.arbitrum.foundation/t/govhack-ethcc-brussels-2024-impact-report-hack-humanity/26530","domain":"forum.arbitrum.foundation","title":"GovHack ETHcc Brussels 2024 - Impact Report - Hack Humanity - Archive / GovHack Brussels - Arbitrum","text":"The Arbitrum Foundation notified the Security Council on the need to perform a potential Emergency action. Following a review of the details and known risks, the Security Council decided to execute the upgrade and it was completed at 11:30 EST on 2nd October 2026.\nThis report provides an overview of the risks that required the Security Council Action:\n\nAdd a permissionless guard for the One-Step Proof of BoLD on Arbitrum One\n\nTemporarily pause activation of new Stylus contracts on Arbitrum One & Nova\n\nKey point: To date, known bugs for Stylus primarily impact chain liveness (e.g., denial of service attacks) and do not put any user funds at risk.\nWhy was this action taken\nLet’s take this opportunity to explain why action was taken on two separate issues concerning BoLD and Stylus.\nInstalling the guard for One-Step Proof of BoLD. Given the rise of AI-assisted attacks, we have implemented a precautionary approach that allows anyone to pause settlement of Arbitrum One on Ethereum if there are at least two conflicting answers that pass at the same level in which only one should be valid and pass. This is to halt a class of publicly verifiable and detectable attacks that exploit a bug in the one-step proof. If halted, Arbitrum One will continue to process as normal except that messages from Arbitrum One to Ethereum, such as withdrawals, that are not yet confirmed will have to wait. This provides time for the Security Council to deploy a fix for the bug and resume the rollup.\nPreventing activation of new Stylus contracts. AI-assisted tooling has led to an increasing number of sophisticated attacks on hand-crafted WASM programs that do not use the standard Stylus compiler toolchain. These programs are specifically designed to cause unexpected behaviors such as degrading the chain’s performance for all other users. To date, no attacks have been discovered that permits theft of user funds.\nNew ArbOS releases have patched several reported bugs and known attacks over the past few months, but out of an abundance of caution, we have decided to temporarily pause new activations of Stylus contracts. This was executed as an emergency action to prevent the deployment of new hand-crafted WASM programs that are not yet patched by the current version of ArbOS on the Arbitrum network.\nThe Arbitrum Foundation has informed the Security Council that they will work with the ArbitrumDAO to discuss next steps on the timeline and manner for enabling activation of new Stylus contracts. The Arbitrum community remains confident in the value of Stylus and want to preserve these use cases while taking preventative measures against Stylus-based attack vectors as AI-assisted attack tooling continues to evolve.\nImpact on builders and users\n\nNo new activations. New Stylus contracts cannot be activated during the pause including new versions of existing applications that require activation.\n\nExisting contracts are not paused. Already-active Stylus contracts continue to execute until expiration. This pause does not deactivate them.\n\nThe ArbOS 61 upgrade renewed all active contracts on Arbitrum One, so no currently active contract expires before August 20, 2027.\n\nRenewal via keepalive stays permissionless and is unaffected by the pause.\n\nReactivating an expired contract, or one that needs to be updated after a Stylus version change, is paused.\n\nUsing/calling any activated Stylus contract stays permissionless for all users and developers.\n\nNo impact on EVM. Solidity (EVM) contract deployment and execution are unaffected by this Security Council action.\n\nSecurity Council Actions\nThere are two actions bundled into a single payload:\n\nOne-Step Proof Guard. The L1UpgradeExecutor gives a new pause contract (PauseExecutor) the ability to pause and nothing else. The new pause contract grants the guard (OspSoundnessGuard) PAUSER_ROLE to use it. Anyone can show the guard two conflicting answers to the same step of an open challenge. If the one-step proof accepts both, the guard has the pause contract put Arbitrum One’s settlement to Ethereum on hold.\n\nStylus deactivation. The Security Council called ArbOwner.setWasmActivationGas(2^64 - 1) to raise the Stylus activation gas requirement on Arbitrum One and Nova. This makes activation prohibitively expensive and effectively disables new activations. This is a configuration change and does not require an ArbOS upgrade.\n\nThe Security Council signed the following transactions to update the configuration:\n\nEthereum: Ethereum Transaction Hash: 0x30732bb7d2... | Etherscan\nArbitrum One:\nArbitrum One Transaction Hash: 0x9eb3a4be3b... | Arbitrum One\nArbitrum Nova:\nArbitrum Nova transaction 0x79e0fed470dff7a22059b108e3f8f42eddd2b580a6771594060c4e7326c5f984 | Blockscout\n\nAn external audit was conducted for the OSP Guard contracts. No audit is required for the Stylus deactivation as it is only updating a single parameter in the ArbOS configuration.\n\n GovHack ETHcc Brussels 2024 - Impact Report - Hack Humanity \n\n ArchiveGovHack Brussels\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 16\n min\n\n Aug 2024\n\n 1 / 20\n\n Aug 2024\n\n Sep 2024\n\n post by KlausBrave on Aug 28, 2024\n\n KlausBrave\n\n Arbitrum GovHack Brussels 2024 - Impact Report\n1200×675 392 KB\nTitle: GovHack ETHcc Brussels 2024\nProposal ID: Arbitrum GovHack Brussels 2024\n\nExecutive Summary\nArbitrum GovHack Brussels 2024, a three-day event held just before EthCC, brought together over 200 participants from 16 countries to drive governance innovation within the Arbitrum ecosystem. The event culminated in the submission of 25 high-quality proposals across 10 tracks, each designed to enhance the DAO’s operations and strategic direction. This hackathon not only fostered deeper community relationships but also showcased the transformative potential of decentralized governance.\nHighlights:\n\nArbitrumDAO participated in a mapathon process, involving 50+ delegates and contributors to identify and prioritise key challenge areas for the DAO, 10 key tracks and challenge statements as strategic focus areas were identified\n\n185 registered, 110+ participants attended in 28 teams\n\n200+ total participants across 3 days\n\n16 Countries represented\n\n25 proposals submitted, 6 being continued\n\n9 Pitstop Experts provided a total of 168 expert feedback sessions to teams on their proposals\n\n20 scholarships offered\n\n3 panels\n\n5 winning finalists with a $20k prize pool awarded\n\n9.5 star rating and 83 NPS from participants\n\nTo capture the essence of the event, checkout the 4-minute after-movie:\n\n Arbitrum GovHack Brussels 2024 Aftermovie\n\nIntroduction\nThe Arbitrum GovHack Brussels 2024 was conceived as a pivotal event to further the decentralized governance efforts of the Arbitrum ecosystem. Building on the success of the GovHack held earlier in Denver, this Brussels edition aimed to elevate the community’s engagement and solidify Arbitrum’s position as a leading force in decentralized governance.\nBackground and Motivation\nGovHack Brussels was strategically scheduled to take place on July 5-7, 2024, just before one of the most significant Ethereum-centric events, ETHcc, in Brussels. This timing was chosen to maximize the impact of the event, ensuring that Arbitrum had a strong presence during a crucial gathering of the Ethereum community.\nThe success of the Denver event (GovHack Denver Impact Report) had already demonstrated the value of in-person collaborations in fostering innovation and strengthening the network of contributors, delegates, and service providers within the DAO.\nHack Humanity, the organiser of both GovHack events, secured $309k in funding from the Arbitrum DAO to execute this initiative (actual funds spent $262k detailed in the finances section of this report).\nThe DAO voted 99% in favour of producing GovHack and continuing the tradition that started in Denver.\nThe goal was to leverage the momentum gained from the Denver event, while expanding the scope and ambition for Brussels. This included a larger prize pool, the introduction of a subsidy pool for high-value contributors, and enhanced community engagement through a dedicated afterparty and a community showcase day.\nObjectives of GovHack Brussels\nThe primary objectives of GovHack Brussels were to:\n\nStrengthen Trust and Relationships: Build deeper connections between Arbitrum contributors and foster a high-trust environment essential for decentralized governance.\n\nIdeation and Implementation: Encourage the creation and eventual implementation of innovative proposals that could benefit the Arbitrum ecosystem.\n\nAttract New Talent: Position Arbitrum as the go-to platform for new and existing talent to build and contribute to the DAO’s growth and success.\n\nEnhance Brand and Community Presence: Ensure that Arbitrum maintains a strong and influential presence at industry-leading events, particularly those focused on Ethereum, to continue attracting users, developers, and key contributors.\n\nGovHack Brussels was designed not just as a standalone event, but as a critical step in a broader strategy to cultivate a resilient, innovative, and inclusive ecosystem and sustainable DAO. By focusing on in-person interactions and providing a structured environment for proposal development, the event aimed to produce tangible outcomes that would drive the DAO forward.\nIn the following sections, this report will delve into the specific outcomes of GovHack Brussels, examining how it met its objectives and the impact it had on the Arbitrum community and ecosystem.\n\nMethodology\nImplementation Process\nGovHack Brussels 2024 employed a comprehensive and structured approach designed to maximize the potential for innovative governance proposals within the Arbitrum ecosystem. The event was built upon a series of carefully planned activities to identify key challenges, facilitate collaboration, and guide teams through the proposal development process.\n\nPre-Event Mapathons: The event preparation began with two virtual mapathons, strategically scheduled across different time zones to ensure broad participation. These sessions provided a platform for participants to express their concerns, hopes, and brainstorm potential problems and solutions. The ideas generated were clustered, prioritized, and organized into thematic tracks, which were then explored through SWOT analyses and challenge statements developed in breakout rooms.\n\n1600×796 165 KB\n1238×624 131 KB\n\nAccess the recordings and Miro boards from the mapathons:\n\nMapathon Round 1 - recording - Jun 17 04 PM CET\n\nMapathon Round 2 - Jun 26 10 AM CET\n\nCombined results\n\nTrack Identification and Participant Alignment: The mapathon process led to the identification of ten key tracks, each aligned with the most pressing needs of the DAO. These tracks provided a focused framework for participants to align their skills and ideas. The contributor roles were designed with two main objectives:\n\n882×491 120 KB\n\nSkill Diversity: Encourage the formation of teams with a balanced mix of technical, design/research, and business/governance expertise.\n\nProposal Relevance: Assist contributors in developing proposals that directly address the specific challenges outlined in each track.\n\nTrack hosts:\nEngagement from key stakeholders really makes GovHack shine, the following valued members of Arbitrum community stepped up to be Track hosts to guide participants in rapidly getting high context on each track, selecting or developing a challenge statement and were supported by HackHumanity’s co-facilitator team with helping individuals in team formation.\nTrack hosts and their talks:\n1. Ana María Yanakieva - Ventures @ana.vc\n2. AnaTech and Rezvan - Marketing @AnaTech.eth @ZER8\n3. Disruption Joe and Raam - IRL Community @DisruptionJoe\n4. Matt Fiebach - DAO budget & revenue @MattOnChain\n5. David - Orbit, Stylys, & Infra @davidgarcia\n6. Matt Hamilton - DevRel\n7. Siddharth Shah - RWA @sid_areta\n8. Coolhorse girl - GovTech\n9. Rick - Gaming @rickjohanson\n10. Lucca Gets - Decentralized sequencer\nTrack Hosts overview video:\n\n Track Host Intros Overview | Arbitrum GovHack Brussels 2024\n\nExpert Pitstops\nDuring Days 1 & 2 of GovHack, three educational talks were hosted, and one of the standout features from GovHack, the “Expert Pitstop,” saw nine Arbitrum experts providing live feedback and consultation to 25 teams. This support significantly enhanced proposal development, offering insights and clarity beyond what is possible through forum posts.\nPitstop Experts:\n\nAlex Lumley\n\nCliffton\n\nCoinFlipCanada\n\nDisruption Joe\n\nDK @dk3\n\nFrisson\n\nGeorge Beall\n\nKrzysztof Urbański and Sinkas (L2Beat)\n\nLucas Fulks\n\nThe Expert Pitstops allowed participants to not only improve their proposals but also to deepen their understanding of the Arbitrum ecosystem, fostering a sense of confidence and trust in their projects.\nGrants Programs Overview\nGovHack Brussels 2024 offered participants several key grant opportunities to support the development and implementation of their proposals. These resources were crucial in encouraging participants to think about the long-term impact of their projects within the Arbitrum ecosystem.\n\nThank Arbitrum Grants Programs Overview:\nA guide to the available grants within the Arbitrum ecosystem, helping participants navigate the funding landscape effectively. Explore the guide here.\n\nSeedGov - QuestBook:\nThis platform provided tools and resources for proposal development and grant applications, aiding participants in refining their ideas and securing necessary funding. Access SeedGov - QuestBook here.\n\nUniswap Arbitrum Grants Program:\nAimed at supporting innovative projects within Arbitrum, this program offered another funding avenue for teams. Learn more here.\n\nArbitrum Foundations Grant program\n\nA video summary of Grant programs is here:\n\n Grant Opportunities Overview | Arbitrum GovHack Brussels 2024\n\nThe intent here as an improvement over GovHack Denver was to guide teams towards smaller and easier funding opportunities beyond going direct to the DAO and main treasury via Snapshot and Tally which is an intensive process. The hypothesis to make this addition to GovHack was well-received, in fact participants requested more guidance on this path.\nProposal Development\nAfter the pre-event mapathons and expert pitstop sessions, participants were fully equipped and motivated to create impactful proposals. These proposals were developed in teams, with each team working diligently to address the specific challenges identified during the mapathons. The expert guidance provided by the pitstop sessions was instrumental in refining these proposals, ensuring they aligned with the Arbitrum ecosystem’s needs.\nJudging and Community Vote\nTo ensure a fair and comprehensive evaluation of the proposals, a panel of experienced judges was assembled. These judges were selected based on their deep understanding of the Arbitrum ecosystem and their ability to assess the potential impact of the proposed solutions.\n970×534 116 KB\nJudges:\n\nDisruption Joe - Head of Decentralization at ThriveProtocol, Arbitrum Delegate\n\nKrzysztof Urbański - Governance Lead at L2Beat, Arbitrum Delegate\n\nGeorge Beall - BD/Governance at Gauntlet, Arbitrum Delegate\n\nCoinflipCanada - GMX, Arbitrum Delegate\n\nJoJoCow - Strategy at JonesDAO, Arbitrum Delegate\n\nThese judges reviewed all 25 submissions, evaluating them based on innovation, feasibility, and alignment with the DAO’s strategic goals. By noon on Day 3, they had selected five finalists who were then invited to deliver live pitches during the event’s Open Community Day.\nWinners!\nGovHack Brussels 2024 culminated in the submission of 25 high-quality proposals. Each proposal adhered to the established guidelines, which included a written document of 400-1500 words, a 2-minute video pitch, and the “GovHack Brussels” tag for identification.\n973×536 82.9 KB\nThe following five finalists delivered a live pitch on Day 3’s Open Community Day, where winners were selected by the votes of those who attended the Community Day.\n\nFirst place: Team 16 - Proposal App : A one-stop-shop to all Arbitrum proposals, regardless of their different lifecycle stages. The app aims to aggregate information from Discourse, Snapshot, and the Arbitrum Onchain Governor contracts so as to understand the context of each proposal. The team asks for $93K for a three-month project development. Full proposal here.\n\n Finalist 3: Arbitrum Proposals App by Paulo Fonseca | GovHack Brussels\n\nSecond place: Team 26 - DevRel Uni Cohort: A six weeks training program to develop and deliver Developer Relations (DevRel) skills and knowledge, ensuring that more protocols within the Arbitrum ecosystem can benefit from DevRel support. The team is asking for $30K for a cohort. Full proposal here.\n\n Finalist 4: DevRel Uni Cohort by Bianca | GovHack Brussels\n\nThird place: Team 12 - Transparency and standardised metrics for Orbit chains on growthepie: A dedicated Arbitrum Orbit Stack page on growthepie.xyz listing 20 chains. Their goal is to aggregate important metrics on a chain level, including revenue for each chain, so that users, builders, and DAO members can make better data-driven decisions. The team is asking $ARB 305.2k for a 5-month development window. Full proposal here.\n\n Finalist 1: Grow the Pie by Toby | GovHack Brussels\n\nFourth place: Team 9 - Arbitrum DAO Dashboard: An aggregated dashboard reflecting the spending of Arbitrum DAO in 2024 available for all via a public website. The team’s aim is to ensure long-term sustainability and informed decision-making, insight into the current state of DAO. They ask $90K for 8 months of work. Full proposal here.\n\n Finalist 5: Powerhouse by Liz, Head of Growth at Azuki | GovHack Brussels\n\nFifth place: Team 4 - Jumpstart fund for DAO improvement: A Questbook fund to support early-stage initiatives focused on problem definition (root causes, gathering requirements), alignment, and scoping proposals for operational and governance improvements. The team is asking for $431K which $350K of them are for funding research initiatives. Full proposal here.\n\n Finalist 2: JumpStart Fund by Daniel Ospina | GovHack Brussels\n\nThe remaining 20 submissions were also of high quality, reflecting the dedication and creativity of the participants.\nTo view these proposals, visit the Arbitrum GovHack Submissions on the Forum.\nPost GovHack\nAfter GovHack, the following proposals have significantly advanced their proposals and have either submitted or are preparing to submit proposals to the DAO:\n\n1st place winner Proposals.app is being evolved on the Forum and plans to go to snapshot\n\n2nd place winner - a dedicated Abritrum DevRel Uni has gone to QuestBook.\n\n3rd GrowThePie Orbit went to snapshot and didn’t pass\n\n4th place Arbitrum DAO dashboard plans to continue and produce a proposal\n\n5th place winner Jumpstart Fund moved to snapshot vote but didn’t pass\n\nEIP-4824 powered daoURI for Arbitrum DAO is continuing and plans to post to snapshot in the coming weeks\n\nPanels\nPanel 1: Organizational structure & oversight\n\n Panel 1: Organizational Structure & Oversight | GovHack Brussels 2024\n\nPanel 2: Impact of grant programs\n\n Panel 2: The Impact of Grant Programs in the Arbitrum Ecosystem | GovHack Brussels\n\nPanel 3: End goal for ARB initiatives\n\n Panel 3: End Goal for Arbitrum Initiatives | GovHack Brussels 2024\n\nInterviews\nAll interviews playlist (18)\nTalks\nSam Martin from Entropy Advisors - Crafting a DAO Proposal\n\n Workshop: Crafting Effective DAO Proposals in Arbitrum | Sam (Entropy Advisors)\n\nPatrick from the Foundation - Arbitrum Technologies\n\n Demo 4: Arbitrum Technologies by Patrick McCorry | GovHack Brussels\n\nSinkas - ARDC\n\n Arbitrum Research and Development Collective (ARDC) by Sinkas | GovHack Brussels\n\nMaggie Love - SheFi talk\n\n Empowering Women in Web3 | Maggie Love, Founder of SheFi\n\nQuantitative Results\nThe Arbitrum GovHack Brussels 2024 delivered significant outcomes across various metrics, showcasing the event’s success.\nEvent Participation and Engagement\n\nMapathon Involvement: Over 50 delegates and contributors participated in the mapathon process, identifying and prioritizing key challenge areas for the DAO. This process led to the creation of 10 strategic tracks and challenge statements, guiding the focus of the hackathon.\n\nRegistration and Attendance:\n\n185 individuals registered for the event.\n\nMore than 110 participants actively engaged in the hackathon, forming 28 teams.\n\nThe event saw a total of over 200 participants across the three days.\n\nRepresentation from 16 different countries contributed to a diverse and inclusive environment.\n\nProposals and Expert Feedback\n\nProposals Submitted: A total of 25 proposals were submitted, each addressing different aspects of governance and innovation within the DAO.\n\nExpert Feedback: Nine Pitstop Experts provided 168 expert feedback sessions, significantly enhancing the quality and relevance of the proposals.\n\nScholarships: 20 scholarships were offered to participants (15 fully eligible and distributed), ensuring a wide range of contributors could attend.\n\nPanels and Discussions: Three panels were held, featuring in-depth discussions on key governance topics.\n\nEvent Outcomes\n\nFinalists and Prize Distribution: Five winning teams were selected, sharing a prize pool of $20,000.\n\nParticipant Satisfaction: The event received a 9.5-star rating and an impressive Net Promoter Score (NPS) of 83 from participants, highlighting the high level of satisfaction and engagement.\n\n1280×785 72.7 KB\nMedia and Storytelling Deliverables\n\nDaily Recaps: Three daily recap videos were produced to capture the essence of each day, engaging the wider community through social media.\n\nDay 1 Recap:\n\nWatch it here | 34K views | 51 reposts | 270 likes\n\nHackHumanityCo status | 43.8k views | 20 reposts | 57 likes\n\nDay 2 Recap:\n\nWatch it here | 21K views | 22 reposts | 62 likes\n\nDay 3 Recap:\n\nWatch it here | 1.9K views | 13 reposts | 49 likes\n\nCommunity Showcase Day: On the final day, four demo showcases of existing Arbitrum projects were presented alongside three panels and two technical talks, further enriching the participants’ experience.\n\nSocial Media Impact\nThe event’s social media presence significantly amplified its reach and visibility within the broader community:\n753×710 337 KB751×779 342 KB\n675×674 310 KB 672×661 351 KB\n\nMentions and Impressions:\n\nOver 70 real-time mentions of “Arbitrum GovHack” during the event, with additional mentions post-event.\n\nHackHumanity generated more than 116.8k impressions solely through event-related tweets, all prominently featuring Arbitrum’s branding.\n\nIn total, tweets about the event accumulated 343.3k views, 2.2k likes, 500 retweets, and over 180 comments.\n\n376×223 23.8 KB\n\nVox Pops and Interviews: More than 30 attendees were interviewed live (Vox Pops), creating content for use during and after the event, further extending the event’s impact.\n\nThe robust media strategy, combined with the active engagement of participants and the quality of the proposals submitted, underscores the success of the Arbitrum GovHack Brussels 2024 in achieving its goals of fostering innovation and collaboration within the Arbitrum DAO.\n670×886 411 KB751×778 426 KB\n674×807 320 KB672×495 269 KB\n1178×1384 237 KB1184×1220 343 KB1164×1002 96.1 KB790×746 507 KB\n1342×1292 255 KB\n\nQualitative Results\nImpact on Arbitrum DAO and Ecosystem\nThe Arbitrum GovHack Brussels 2024 had a profound impact on the DAO and its broader ecosystem, aligning with the DAO’s core values of social inclusiveness, collaboration, and innovation.\nSocial Inclusiveness\nThe event drew participants from various stages of engagement with the Arbitrum ecosystem, with demographics reflecting a wide range of experience levels and geographic diversity:\n\nExperience within the Ecosystem:\n\n1070×498 13.7 KB\n\nThe majority of attendees had between 6 to 24 months of experience within Arbitrum, highlighting GovHack’s role as a magnet for committed community members who are eager to shape the DAO’s future.\n\nA significant portion of participants were new to Arbitrum, using GovHack as a rapid and immersive entry point to understand the nuances of DAO governance, decision-making processes, and funding mechanisms.\n\nThis diversity of experience levels suggests that GovHack serves as a critical mechanism for both integrating new members and enhancing the contributions of established ones.\n\nGeographic Diversity:\n\n1600×970 499 KB\n\nParticipants hailed from 16 countries, primarily from Europe, but also from North and South America, and India. However, there is room for improvement in terms of representation from the African continent and the Global South.\n\nParticipant Roles:\n\n883×509 13.7 KB\n\nAttendees primarily identified as Builders, Contributors, and Service Providers, indicating that GovHack attracts individuals who are not only interested in contributing to the DAO but are also focused on building and enhancing its ecosystem.\n\nThe significant presence of Delegates underscores GovHack’s importance as a forum for deepening IRL feedback and fostering stronger connections among established DAO contributors.\n\nParticipant Experience\n1600×904 206 KB\n1600×898 182 KB1600×904 147 KB\nDetailed IRL schedule here.\nArbitrum’s goal of fostering an ecosystem that thrives on open innovation, interoperability, user choice, and healthy competition was clearly reflected in the participant experiences at GovHack Brussels:\n\nOverall Sentiment:\n\nThe general sentiment during Day 1 was overwhelmingly positive, with participants using words like “fun,” “inclusive,” and “connected” to describe their experience. By Day 2, the focus shifted to words like “intense,” “productive,” and “impactful,” reflecting the rigorous work and networking that characterized the event.\n\nDAY 1\n1069×552 41.7 KB\nDAY 2\n1041×499 38 KB\n\nSocial Connectivity:\n\nOn Day 1, most attendees reported knowing few people within the ecosystem. However, by the end of Day 2, participants had significantly expanded their networks, with many reporting they had met between 6 and 15 new people. This increase in social connections was facilitated by structured networking exercises and track explorations.\n\nQuotes from participants like Cliffton highlight the value of in-person interactions:\n\n“Having a lot of in real life feedback, a lot of in-person iterations and improvements, is a big value add… We found out that the main takeaways from the DAO was that everyone just got to know each other better, everyone could collaborate on a quicker pace.”\n625×585 29.6 KB\nSkill Development and Confidence Building\nGovHack also played a crucial role in enhancing the proposal-making skills and confidence of participants:\n1029×497 46.1 KB\n\nConfidence in Proposal Success:\n\nParticipants’ confidence in getting their proposals passed increased from an average of 6.4 on Day 1 to 7.0 on Day 2, marking a 9.4% improvement. This boost was attributed to the expert feedback and educational talks provided during the event.\n\nAs Raam noted, “I think the quality of the proposals that we saw at GovHack were probably equivalent to one month of progress for a typical proposal that’s worked on remotely.”\n\nDAY 1\n1059×508 18.9 KB\nDAY 2\n1021×406 13.8 KB\nQuotes from Participants\nThe positive feedback from participants underscores the value that GovHack added to the Arbitrum ecosystem:\n\nDisruption Joe: “The DAO is really spearheading the evolution of decentralized technology and governance. And we’re seeing this governance innovation live in action here at GovHack.”\n\nSrijith: “GovHack makes it super easy if you’re not a coder because there is a lot of value that you can add based on your experience… Bringing us together makes it a lot easier for us to move the DAO forward.”\n\n@ocandocrypto: “I’m feeling excited just for the fact that I’ve been learning a lot. So it’s quite exciting, this real experience of sharing with others and also learning from others.”\n\nThese qualitative results highlight GovHack Brussels 2024 as a pivotal event that not only fostered collaboration and innovation but also strengthened the social fabric and skill sets within the Arbitrum community.\nFinances\nThe original proposal was executed with $309k, including contingencies.\nThe final costs come in at $262k\nOriginal estimates:\n1416×1408 127 KB\n1424×294 31.4 KB\nHack Humanity received Milestone 1 & 2, we did not request Milestone 3 payment ($46,350) the final 15% as it was not needed.\nNote the plan was to distribute $10k (20 x $500) scholarships, we awarded 20 scholarships, yet 5 people didn’t show up or were in eligible, the final scholarship spend was $7,500.\n\nScholarship winners announcement 1\nScholarship winners announcement 2\n\nActual costs\n1600×1114 259 KB\nUnderspent $1096 returned from Hack Humanity wallet to GovHack mutlisig\n\nArbiscan transaction\n\nRemainder in GovHack Multisig:\n1600×427 64.8 KB\nThis can be used towards GovHack Devcon to secure a Bangkok venue early, or returned to the DAO main treasury.\nRecommendations for Future Events\nBased on the challenges faced and feedback received, several recommendations were made to enhance future GovHack events:\n\nIncrease Prize Amounts:\n\nTo encourage a greater variety of projects, it was suggested to increase the prize pool and consider separating prizes by track. This would ensure that all tracks are well-represented and encourage more focused project development.\n\nChange the number of Tracks\n\nWe had 10 tracks, while that meant we had a breadth of engagement, was that at the cost of depth of engagement. We could do the next GovHack to a much greater depth say on 3 tracks that are top priorities for the DAO for that quarter for instance.\n\nLarger Scholarships:\n\nThe $500 scholarships provided were not sufficient for participants travelling from outside Europe. One major delegate suggested increasing the scholarship amount to $2,500 per participant while curating the talent pool more selectively would better support the participation of high-value contributors. Ideal 20 x $2,500.\n\nWorkshops on Grants:\n\nMore workshops focused explicitly on available grants and the application process would help participants better navigate the funding landscape and increase the quality of their proposals.\n\nVenue Considerations:\n\nWhile the venue was generally well-received, future events should take into account the proximity to related conferences, like EthCC, to make it more convenient for participants.\n\nPost GovHack Support\n\nFacilitated program to support promising proposals to continue development and submission to the DAO. I.e. run online PitStops, schedule dedicated guidance and feedback sessions per track aspiring contributors can engage with. Ideal a dedicated 4 week online support/incubation program\n\nTarget demographics and IRL program design considerations\n\nGovHack was conceived and created by Hack Humanity for the following purposes:\n1. onboarding of new talent to solve issues for the DAO with proposals, success measures being increasing the quantity and quality of proposals.\n2. onboarding and development of existing and new delegates to exercise their role live realtime guiding and providing feedback to teams writing proposals\n3. a space for delegates and core contributors to network, build high trust relationships and make core complex DAO level decision making\nWe assess that GovHack is doing 1 and 2 well, point 3 in particular complex DAO level decision-making isn’t something intentionally designed for in the program and facilitation, people in the DAO are showing up and defacto using GovHack in this way in the absence of a dedicated opportunity to fulfil that need.\nWe have had 2 iterations of GovHack, I’d like to ideate with feedback here on what the 3rd iteration of GovHack needs to be most serving.\n\nThe possibility to either\n\nhave a dual track of strategic facilitation for delegates and core contributors to work through hard problems and make decisions\n\nuse Day 1 as a mini offsite for delegates and core contributors with the support of structured facilitation to work through complex topics and make critical decisions, to sharpen up the most aligned tracks and challenge statements, then move to the hackathon with this enhanced clarity\n\nBy reflecting on these challenges and the lessons learned, GovHack can continue to evolve and improve, ensuring that future events provide even greater value to participants and the Arbitrum ecosystem as a whole.\n\nConclusion\n1078×375 8.33 KB\nArbitrum GovHack Brussels 2024 showcased the powerful role in-person events play in sparking innovation and enhancing decentralized governance. With more than 200 participants from 16 countries, the event provided a fertile ground for turning ideas into actionable proposals.\nThe event’s well-organized structure, featuring pre-event mapathons, expert pitstops, and educational panels, gave participants the tools they needed to navigate the complex process of developing proposals. By focusing on key areas relevant to the DAO’s goals, the event ensured that contributions were both meaningful and impactful. The democratic approach to judging and community voting highlighted a strong commitment to fostering genuine innovation.\nParticipants were highly satisfied, as evidenced by a Net Promoter Score of 83 and robust social media engagement. However, the real highlight was the personal connections and sense of community that emerged—something often lacking in virtual environments.\nThe insights gained, especially around the timing of educational sessions and team formation, will be invaluable for future events. As Arbitrum continues to grow, the lessons and networks established at GovHack Brussels will be instrumental in shaping the DAO’s future. This event underscored the importance of in-person engagement in driving decentralized governance forward, setting a new benchmark for community-driven innovation.\nHackHumanity has thoroughly enjoyed producing GovHacks and wishes to continue this tradition providing GovHacks as a key competitive advantage for Arbitrum.\nHave added a Quick Poll for future direction, feedback much appreciated → Poll\n\nAdditional Resources\nTo explore more about the Arbitrum GovHack Brussels 2024, including videos, proposals, photos, and media coverage, please refer to the following links:\n\nAfter-Movie: Watch the 4-minute after-movie\n\nProposal Submissions: View all proposals on the Arbitrum Forum GovHack section\n\nAll media playlist\n\nMapathon Recordings and Miro Boards:\n\nMapathon Round 1 - recording - Jun 17 04 PM CET\n\nCombined results\n\nDaily Recaps:\n\nDay 1 Recap | 34K views | 51 reposts | 270 likes\n\nDay 2 Recap | 21K views | 22 reposts | 62 likes\n\nDay 3 Recap | 1.9K views | 13 reposts | 49 likes\n\nPhotos: Access all pictures from the Arbitrum GovHack Brussels 2024\n\n Establishing a DAO Events Budget for 2025\n\n GovHack Devcon in Bangkok - Hack Humanity\n\n Paulo Fonseca – Voluntary Earnings Disclosure Thread\n\n Paulo Fonseca – 10% Delegatoooor Kickback Program\n\n Delegate Incentive Program 1.7 - Application Thread and Code of Conduct Adherence\n\n 6\n\n 2\n\n read \n\n 16\n min\n\n post by julesfoa.eth on Aug 28, 2024\n\n julesfoa.eth\n\n Thanks Klaus and the team for your hard work. It was really smooth from the place, the food, the talk and the hack!\nI was awarded a scolarship and managed to push a proposal during the hack, here are my feedbacks.\nIt was really a game changer on two ways - meeting delegates and begining to build connections with many people that are really valuable. Not only like a conference, but understanding the needs of everyone and giving opportunities to see how to contribute in the future.\nI also have to admit that it was my first proposal after 3 years working in DAO ecosystem.\nThat is my point of view, but I think many silent people from the community are living a similar experience!\n\n post by KlausBrave on Aug 28, 2024\n\n KlausBrave\n\n Thanks for the feedback @julesfoa.eth in particular that GovHack was the difference that got you to at last make a proposal.\nThanks for coming it was a pleasure to have you there playing full out IRL.\n\n post by ZER8 on Aug 28, 2024\n\n ZER8\n\n Gov Hack was a very interesting experience for me, tbh idk if I would have gone to ETH CC if Gov Hack didn’t happen. \nI feel I learned so much during gov hack, the relationship building was invaluable(great to put faces on those PFPs), the participants had amazing energy to WIN and get their proposal “passed” by the DAO. Met some friends I already knew there and managed to get others interested in Arbitrum via Gov Hack. Loved the brunch as well \nAlso managed to chat with Ed Felten, za founder which was also kinda really cool, didn’t expect the Arbitrum core team to join \n\n post by KlausBrave on Aug 28, 2024\n\n KlausBrave\n\n Quick Poll to get an idea of future possibilities, what proposals would you like to see next from Hack Humanity?\nYou can tick multiple options:\n\n 18\n voters\n\n Choose up to 6 options.\n\n Votes are public.\n\n post by feems on Aug 28, 2024\n\n feems\n\n Thanks Klaus great awareness intitiative - do you have any data on rentention of those that participated or won the gov hack (denver) of those contributing to the DAO?\nAny data to fulfil the goal of the gov hack “drive governance innovation within the Arbitrum ecosystem” outside of submitting a proposal? Have any become delegates, joined WG (from new contributors)\nHaven any of the previous winners proposals in denver passed? If so what impact has it brought to the DAO\n\n post by KlausBrave on Aug 28, 2024\n\n KlausBrave\n\n Great questions @feems, retention and post GovHack activity is key.\nAt an individual level I’d need to do extensive research to gather some of these stats cross referencing Luma attendees, Forum accounts, Snapshot and Tally profiles to piece this together.\nFrom my current knowledge, initiatives from GovHack Denver that have matured and gone on to snapshot and Tally include:\n\nM&A\nAVI (Ventures)\nEvent Horizon\nAnecdotally, I heard a lot of the key conversations for STEP got worked out IRL at GovHack Denver. @thedevanshmehta would be better placed to elaborate on this.\n\nFrom ETHcc Brussels already:\nThe following proposals have significantly advanced their proposals and have either submitted or are preparing to submit proposals to the DAO:\n\n1st place winner Proposals.app is being evolved on the Forum and plans to go to snapshot\n2nd place winner - a dedicated Abritrum DevRel Uni has gone to QuestBook.\n3rd GrowThePie Orbit went to snapshot and didn’t pass\n4th place Arbitrum DAO dashboard from @prometheus_PH plans to continue and produce a proposal\n5th place winner Jumpstart Fund moved to snapshot vote but didn’t pass\n\nEIP-4824 powered daoURI for Arbitrum DAO from @amanwithwings is continuing and plans to post to snapshot in the coming weeks\n\nI am thinking one avenue to explore is I setup a Hack Humanity KarmaHQ profile and project for each GovHack and ask individuals and teams to attest to this value over time as a way to track the ROI, what do others think?\n\n post by feems on Aug 28, 2024\n\n feems\n\n You could just limit it to the winners of the gov hack. The reason being it shifts this from an awareness intititative to one to meet your original goal of drive governance innovation within the Arbitrum ecosystem. From low hanging participation (submits a proposal) to active and valuable contribution.\nAnylyzing this can allow more refined approach to meet those goals for the next gov hack if you choose to run it again. If this is considered and investment whats the ROI of it and how does it differ in impact from a devloper hackathon ( to see whether a gov hack is needed)\n\n post by Frisson on Aug 28, 2024\n\n Frisson\n\n Thanks for the very detailed Impact Report. I thought GovHack ETHcc was executed well and appreciate that it came in under budget. I’d support another event in Bangkok.\nOne piece of feedback I have is that I would like to see more integration between Arbitrum Day and GovHack. Going to both GovHack and Arbitrum Day required a long stay in Brussels. Also, I think there is an opportunity to integrate/paralell-path the governance hackathon with a technical hackathon around Stylus and/or Orbit.\n\n GovHack Devcon in Bangkok - Hack Humanity\n\n post by bianca on Aug 28, 2024\n\n bianca\n\n Great to see such a detailed report! I wanted to share my experience from GovHack Brussels as well. I decided to fly to Brussels earlier specifically for this event, and I definitely do not regret it. The moment I read about it, it resonated with me because decentralized governance is such an important topic for the web3 space, yet there are very few resources on how to approach it.\nIt was great getting to know key Arbitrum stakeholders in person. Also, having access to different learning experiences, key community members, and the HackHumanity team condensed what would have probably taken weeks of research and learning into just three days.\nThis was my first time writing a proposal and my first deeper interaction with the Arbitrum community. We ended up winning second place, and the proposal is now live on Questbook. The whole GovHack experience made me realize that Arbitrum is the ecosystem where I would like to build long-term.\nRegarding the ROI mentioned above, I think it’s challenging to measure it in the short term. Hackathons, in general, are a long-term investment—sometimes the ROI isn’t revealed until months or even years later. I’m saying this as someone who works in developer relations, where hackathons play a crucial role.\nI think we can agree though that this event positioned Arbitrum and the Arbitrum community as leaders in the governance space by offering a unique initiative that other ecosystems do not have. It also signals that one can have a significant positive impact if they are determined to do so—something that felt quite unique to me as a newcomer.\nSorry for the mini-essay . Personally, this event influenced me positively, and I’m sure it had a similar effect on many others. I’d love to see it happen again around other big Web3 conferences such as Devcon.\n\n post by JoJo on Aug 28, 2024\n\n JoJo\n\n Frisson\n\n I want to expand on what frisson posted here.\nFirst thing first, the event was well executed. I think a lot of builders were able to “get a taste” of our dao processes, for the good or the bad, in terms of writing proposals, getting feedbacks, finding people to work with, iterate, participate to a voting. It was similar to how we normally do it online, but IRL + concentrated + expedited. And to me this is an extremely valuable experience for the participants.\nAt the same time we have a second cohort of participants, that are established delegates and builders who, de facto, used the govhack event as a first BD meeting.\nThis happened naturally for one reason: govhack was, timeline wise, the first event of the week, before arbitrum day and before ethcc itself. This was a byproduct of how events were aligned for that particular weeks.\nImplicitely it means that, especially if the future govhack will happen again several days before main events (arbi day, main conference), it could make sense to have it structured in a way that favours these impromptu meetings that will inevitably happen.\nThis doesn’t mean changing the nature of govhack: i think that what was done was good and should be replicated. But for example allowing delegates to be able to have time and space to discuss what they felt they want to discuss in that moment without having to jump from meetings into advising participants and back to meetings and then back to judging or other activities tied to the specific event would be a good evolution.\nFurther more, I second frisson in both his takes, re: finding a coordination with arbitrum day could be something worth considering + expanding the govhack scope to also a technical hackaton specifically for stylus and orbit.\n\n post by paulofonseca on Aug 28, 2024\n\n paulofonseca\n\n IMG_6603800×450 213 KB\nthe world if everybody that got money from Arbitrum DAO would produce impact reports like this one.\nbut honestly… I flew to Brussels just for GovHack because when I saw the highlights video of the first GovHack in Denver I felt FOMO like never before, so I had go for it. I’ve participated in a bunch of hackathons throughout my career, (web3 and mostly non web3 ones) and I need to say that the level of professionalism in the organization of this GovHack Brussels was world class. all of the staff members were on top of their game and the proof is that nothing failed. during the whole 3 days, there was no hickup, no issue that I was aware of at least, and everything went smoothly. this is so incredibly rare for any event of this size. there’s no team I would trust more to organize proper hackathons like Hack Humanity\n\n post by tobsch on Aug 29, 2024\n\n tobsch\n\n Upfront: It was a super well organised event, so kudos and cheers to Klaus & team!\nAlso, the duration was good and sufficient, and everything from food, assistance in case of questions or unclarity, was all there.\nFor us, it was a chance to get closer to Arbitrum, as we’ve been trying before, and the DAO seems quite hard to get into and approach if you do not know many or any of the delegates. So it was good to meet people IRL and make yourself known.\nOne idea I had was to actually make this into a hybrid (IRL + online) event. Especially for people developing proposal with the intention to actually make a lasting impact and bring this to reality, it would be valuable to get feedback from more than just the few that have the ability to be on-site.\nAlso, generally I would love to actually get more proper feedback in written form or feedback in a formal meeting after judging of the proposals. In our case, we had some individuals we approached during drinks to get some feedback, but since our snapshot vote failed even after trying to incorporate feedback, discussions on the forum, I feel we did not get enough information even from the people that we could have talked to on-site. (As it is also sometimes not possible to match online handle/PFP with actual person if you hadn’t been in the inner circle before).\nSo all in all, I would aim for actually getting the big delegates more involved in these initiatives, as they will be the one actually deciding on developed proposals. This could be part of the agenda.\nAgain, great work from everyone there, thanks for organising it and looking forward to the next iteration. \n\n post by kinaArb on Aug 29, 2024\n\n kinaArb\n\n The report has sparked some interest. It’s promising to see potential in enhancing transparency and scalability within the DAO.\nLet’s hope these ideas gain traction and lead to tangible improvements. Looking forward to seeing further outcomes from this initiative.\n\n post by sid_areta on Aug 29, 2024\n\n sid_areta\n\n Overall, the GovHack experience was absolutely fantastic for us and it was great to meet everyone we have been working with so closely with in person! Huge kudos to @KlausBrave and the HackHumanity team for pulling off such an engaged and professionally run event, especially considering the time pressure they were under.\nIn terms of feedback, we think that future GovHacks can be two-pronged. The first prong that is crucial to be retained is to serve newcomers and help educate them on how to write proposals and contribute directly to the DAO. This could be further expanded by providing more education and context around the current state of the DAO and where specific help and input from contributors is needed - this would be extremely useful for existing high-context contributors as well, for whom it is relatively difficult to keep up with everything going on in a DAO as large and sprawling as Arbitrum. Teams working on existing initiatives can, for example, go in depth on their work, present it to the DAO, and speak through achievements and challenges to help everyone attain the context that sometimes can be lacking on calls or on the forum.\nThe second prong would be around having sessions for contributors to the DAO who are already high-context; more brainstorming sessions and dedicated opportunities to discuss important topics that the DAO needs to solve for would also be very beneficial. It turned out that for a lot of contributors who work on Arbitrum day in, day out, that GovHack was more of a great networking opportunity - there is an opportunity to capitalise on this and dedicate time towards topics that contributors feel are crucial to discuss in person and further advance.\nAll in all, this is a fantastic Impact Report and it has been a pleasure getting to know and work alongside Klaus and the HackHumanity team.\n\n post by KlausBrave on Aug 31, 2024\n\n KlausBrave\n\n All remaining and final funds (underspent + the ARB buffer) have been returned from GovHack multisig to the DAO Treasury.\n203.5k ARB, transaction:\n\nThank you to @krst and @AbdullahUmar as fellow multi-sig signers,\nand to @cliffton.eth for Foundation oversight and confirming the transaction.\n\n GovHack at ETH CC (Brussels)\n\n post by ostanescu.eth on Sep 5, 2024\n\n ostanescu.eth\n\n Thank you @KlausBrave and the entire Hack Humanity team for pulling up such a great event.\nI am super greatful to have had the chance to be part and build alongside Arbitrum community.\nAt ETH Bucharest we are now in process of discussing a proposal that would bootstrap the local Arbitrum community and this is all thanks to the GovHack Brussels.\nI am also very greatful to have met such great people, and to my surprise bump into people that I didn’t know they are gonna be there. Which made me feel even more that I am in the right place.\nLooking forward to the next edition and hopefully we can organize something in Bucharest one day!\nCongrats and keep going! #LFG\n\n post by Gonzacolo on Sep 8, 2024\n\n Gonzacolo\n\n I appreciate the report. Being clear with the data and process is crucial.\nAs I’ve mentioned in other channels, initiatives like this are extremely complex to execute, and this is one of the few places where participants from the Arbitrum DAO can meet in person. Personally, I had the chance to meet some incredible people, and the relationships and trust we build by connecting face-to-face will significantly contribute to growing this ecosystem that we all support, enabling us to create better products and initiatives.\nI also think that narrowing the scope of the tracks could be beneficial. Some technical tracks, which I personally found interesting, didn’t seem to be fully aligned with the DAO’s goals and, in the end, weren’t particularly helpful for the DAO itself.\nI support the cross-activities that help us get to know each other, like those on the first day, but spread throughout the event. This would allow us to connect even more, including with the new participants.\nI look forward to it happening again and hope to participate in the future!\n\n post by KlausBrave on Sep 8, 2024\n\n KlausBrave\n\n Thank you @Gonzacolo.\nThe number of tracks is definitely a parameter we can change up/down to create a more focused event.\nBringing more cross-activities to get to know each other spread throughout the event is a great suggestion, I agree we can include more of this in the next one.\nIt was great to meet you Gonzacolo, thanks for coming.\n\n post by Mehdi_eth on Sep 9, 2024\n\n Mehdi_eth\n\n Unfortunately, I could not participate, but based on the pictures and videos, it looks quite exciting to learn and meet the experienced delegates. For the next event, I hope you consider offering an online version as well.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n GovHack ETHDenver 2024 - Impact Report - Hack Humanity\n\n GovHack Denver\n\n 9\n\n 1.6k\n\n Jun 2024\n\n GovHack at ETH CC (Brussels)\n\n Finalized AIPs\n\n 51\n\n 3.9k\n\n Aug 2024\n\n GovHack Devcon in Bangkok - Hack Humanity\n\n Archived Proposals\n\n 74\n\n 1.9k\n\n Oct 2024\n\n GovHack - ETHDenver powered by Hack Humanity\n\n GovHack Denver\n\n 9\n\n 2.5k\n\n May 2024\n\n ArbitrumDAO Off-site - Directional proposal\n\n Finalized AIPs\n\n 89\n\n 2.3k\n\n Oct 2024","tokens":13018,"squid":"spider-07","role":"Council Spider","at":1791339008770,"hash":"9bdbb5429ea765ff62fafa03256d3338cd945b37"}
{"url":"https://jobs.arbitrum.io/","domain":"jobs.arbitrum.io","title":"Companies | Arbitrum Job Board","text":"Search by name or keywordLocationIndustryStageSizePowered by GetroShowing 46 companies0x1 jobSeries BBlockchainCryptocurrencyDecentralized Finance (DeFi)Ethereum+ 1 moreSoftware Development0x is an open protocol that facilitates low friction peer-to-peer exchange of tokens on the Ethereum blockchain.View 1 jobAcross Protocol1 jobICOBlockchainFinancial ServicesTransaction ProcessingAcross is a cross-chain bridge secured by UMA's optimistic oracle for L2s and rollups. It is also optimized for capital efficiency with a single liquidity pool, a competitive relayer landscape, and a no-slippage fee model.View 1 jobAlchemy21 jobsBlockchain and CryptocurrencyDeveloper PlatformSoftwareWeb3Alchemy is a developer platform that empowers companies to build scalable and reliable decentralized applications without the hassle of managing blockchain infrastructure in-house. It is currently faster, more reliable, and more scalable than any other existing solution, and is incredibly easy to integrate!\n\nMany top projects in the space, including Augur, CryptoKitties, Kyber, Radar Relay, OpenSea, etc., rely on Alchemy to support their core infrastructure needs. The team consists of top engineers (from Stanford, MIT, Google, Facebook, Microsoft, and many more startups) with decades of industry experience in big data and scalable infrastructure and is backed by A-list investors (Charles Schwab, Coinbase, founders of LinkedIn and PayPal, chairman of Google, etc.). \n\nWe're currently hiring across multiple roles in engineering and go to market. If this sounds interesting, say hi!View 21 jobsAlchemy Pay2 jobsBlockchainCryptocurrencyFinancial ServicesPaymentsAlchemy Pay (ACH) is a payment solutions provider that bridges the fiat and cryptocurrency markets for worldwide customers, retailers, developers, and institutions.View 2 jobsAntimetal9 jobsSeries ACloud InfrastructureCloud ManagementEnterprise SoftwareAntimetal is an AI-powered cloud cost optimization and infrastructure automation platform that helps companies gain real-time visibility into their cloud spending. By analyzing usage patterns and automatically implementing cost-saving actions, Antimetal reduces cloud waste and enables engineering and finance teams to manage infrastructure costs more efficiently.View 9 jobsArbitrum16 jobsBlockchainEthereumSmart ContractsArbitrum is responsible for creating a range of solutions that offer cost-effective smart contract environments, utilizing technology deeply connected to Ethereum.View 16 jobsArbiusArtificial Intelligence (AI)BlockchainArbius operates a decentralized AI platform that enables users to host, run, and monetize machine learning models via blockchain technology.View companyBitquerySeedAnalyticsAPIBigDataBitcoinBlockchain+ 13 moreBlockchain and CryptocurrencyBusiness/Productivity SoftwareData & AnalyticsData ManagementEnterprise SoftwareEthereumFinancial SoftwareFintechInternetInternet ServicesInternet ServicesTechnologyTechnology, Information and InternetBitquery is a blockchain data company that develops solutions used to parse, index, and store blockchain data in a unified way. Bitquery overcomes obstacles by providing a unified blockchain GraphQL API interface for accessing blockchain data from over 30 blockchains. It also provides simple and meaningful access to DeFi, DEX protocols, and token-related data across multiple blockchains.View companyBlowfishBlockchainCryptocurrencyCyber SecuritySoftwareBlowfish detects and prevents fraud before any fraud occurs.View companyCaldera1 jobSeries ABlockchainCryptocurrencyInfrastructureSoftware+ 2 moreSoftware EngineeringWeb3Caldera offers a no-code Web3 infrastructure platform to help developers spin up Layer-2 blockchains. It allows users to create, launch, and manage customizable blockchain rollups. It also provides customizable fee structures, or the removal of transaction fees entirely, generating project revenue via transaction, bridge fees, or MEV, and adding support for other programming languages.View 1 jobCamelotConsumer ServicesCamelot was the operator of the National Lottery from 1994 to 2024 and has now handed over to a new operator, Allwyn UK. Interested in working for the National Lottery? Visit https://www.allwyn.co.uk/careersView companyCegaSeedBlockchainCryptocurrencyDecentralized Finance (DeFi)Finance+ 3 moreFinancial ServicesFintechSoftwareCega is building the next evolution in DeFi derivatives. We are the first protocol focused purely on exotic derivatives, a class of options products that combine basic options (e.g., call/put) with advanced options characteristics to create packaged offerings for investors which generate superior yield, provide downside protection, and express infinite views of the financial market.View company","tokens":1191,"squid":"spider-01","role":"Chain Spider","at":1791339013483,"hash":"76c01bed7edb88e4e03c69ecb51ab8bb2f8c5795"}
{"url":"https://docs.across.to/introduction/features","domain":"docs.across.to","title":"Key Features | Across Docs","text":"Key FeaturesWhat makes Across the fastest, cheapest, and most secure crosschain interoperability protocol.Integration methods\nAcross supports three integration methods. The Swap API is the default and covers most use cases.\nMethodWhat it isUse whenSwap API (primary)Quote a route, then execute the returned transaction from the user's walletAll Standard integrations — the primary pathGaslessThe user signs a message; Across submits the transaction on-chain, no gas from the userYou want users to transact without holding gasDeposit addressSend funds to a persistent infinite-TTL address to conduct a crosschain swapautomation, on-ramps, deposit flows\nFeature Highlights\nFeatureDetailsSub-2-second fillsCompetitive relayer network delivers funds on the destination chain in ~2 seconds on mainnet24 mainnet chainsSolana, MegaETH, Plasma, Monad, Hyperliquid, and all major L2sCCTP V2 / CCTPFastNative USDC settlement up to $10M per transaction. CCTPFast offers faster attestation where availableSponsored routesZero-fee USDT/USDT0 → USDC-SPOT/USDC-PERPS on HyperCore from Ethereum, Arbitrum, Monad, Polygon, Unichain.Embedded crosschain actionsCompose DeFi operations — swap, bridge, and execute destination-chain calls in a single transactionOFT for USDT0Native USDT0 mint-and-burn settlement via LayerZero. More tokens coming soonERC-7683 standardImplements the crosschain intent standard for interoperability with other intent-based systemsZK proofsSuccinct/SP1 zero-knowledge proofs enable permissionless chain expansion without governance votes\nAPI Comparison\nThe three main APIs for initiating crosschain transfers are /swap/approval, /swap/gasless, and /deposit-addresses — sign and submit a transaction, sign one gasless message, or send funds to a persistent address. They serve different use cases and have different capabilities.\nFeatures/swap/approval/swap/gasless/deposit-addressesHow it worksReturns a transaction for the user to sign and submit on-chainUser signs one EIP-712 message (ERC-3009 / Permit2 permit); a submitter broadcasts it on-chain — no gas from the userReturns a persistent deposit address to send tokens to — no signing or per-transfer quoteHTTP methodsGET (simple bridge) / POST (embedded actions)GET to quote → POST /gasless/submit with the signaturePOST onlyAPI key requiredYesYesYesIntegrator ID requiredYesYesYesSupported origin chainsAll 24 mainnet chainsAny Across-supported EVM chain (plus HyperCore via 1337)17 chains — discovered dynamically, read supportedInputs[] from the response (not hardcoded)Supported destination chainsAll 24 mainnet chainsAny Across-supported EVM chain (plus HyperEVM 999)20 chains — the 17 origin chains plus HyperCore (1337)Supported tokens (origin)All bridgeable tokens (per /swap/tokens)Tokens that support gasless authorization (ERC-3009 / Permit2 — e.g. USDC)Route-specific — stablecoins, ETH/WETH and WBTC where the route carries themTrade typesexactInput, minOutput, exactOutputexactInput, exactOutputN/A — amount-agnostic (the amount isn't part of the request)Embedded crosschain actionsYes (via POST with crossChainMessage)NoNoOrigin swapsYes (automatic if input token is not directly bridgeable)Yes (any-input routes, e.g. USDC → native ETH)NoRefund mechanismAutomatic via SpokePool to refundAddressOrigin or destination by route (refundOnOrigin); paid to refundAddress → recipient → depositorRefunds to refundAddresses if a deposit can't completeIdeal forWallets, dApps, DEX aggregators — any flow with wallet signingOnboarding users with no gas or native token; embedded wallets; HyperCore withdrawalsCEX onramps, bots, automation, recurring deposits — flows with no wallet signingExpected fill timeLess than 2 secondsLess than 2 secondsProvided per route via indicativeFillTime in the responseDeposit address TTLN/AN/ANever expires — expiresAt is always nullStatusGenerally availableGenerally availableGated (request access)\nSpeed\nAcross's infrastructure fills most transfers in ~2 seconds on all supported chains, so funds reach the recipient on the destination chain almost immediately.\nChain Coverage\nAcross supports 24 mainnet chains including:\n\nEVM L2s — Arbitrum, Optimism, Base, Polygon and more\nAlt-L1s and new chains — Solana, MegaETH, Plasma, Monad\nApp-specific chains — Hyperliquid (HyperCore + HyperEVM)\nTestnet support — 8 testnet chains for development\n\nSee the full list here.\nSponsored Routes\nSelect routes have zero bridge fees, subsidized by the protocol or partners.\nCurrently sponsored:\n\nUSDT / USDT0 → USDC-SPOT, USDC-PERPS on HyperCore from Ethereum, Arbitrum, Monad, Polygon, Unichain\n\nSponsored routes change over time. Check the /swap/approval response for fee breakdowns to see if a route is currently sponsored.\nEmbedded Crosschain Actions\nBridge and execute any arbitrary action (like swap, mint, deposit etc.) in one transaction. Attach arbitrary contract calls to your crosschain transfer — the MulticallHandler executes them atomically on the destination chain.\nUse cases:\n\nSwap + deposit into Aave\nBridge + add liquidity to a DEX\nTransfer + stake on the destination chain\nWhy AcrossThe fastest, cheapest, and most secure way to move assets across chains.API Keys & Integrator IDHow to get an API key and integrator ID for production use of the Across APIs.","tokens":1317,"squid":"spider-09","role":"Bridge Spider","at":1791339015725,"hash":"e7bdab4b2d4f42990e1168b4627d82bb43907db1"}
{"url":"https://docs.across.to/ai-agents","domain":"docs.across.to","title":"AI Agents | Across Docs","text":"AI AgentsGive your AI agent crosschain superpowers with a single command.Add Across to your agent with one command\nterminalnpx skills add https://github.com/across-protocol/skills --yes\nCompatible with Claude Code, Codex, Cursor, Openclaw, and more.\nConnect to the Across MCP Server\nMCP Server URLhttps://mcp.across.to/mcp\nAdd this URL to any MCP-compatible client — Claude Desktop, Claude Code, Cursor, VS Code Copilot, Windsurf, Codex.\n\nWhat your agent gets\nOnce installed, your AI agent can:\n\nBridge tokens across 24+ chains with natural language commands\nGet live quotes — fees, estimated fill times, and optimal routes\nExecute crosschain swaps — USDC, USDT, WETH, and more\nTrack deposits — check fill status and confirmations in real time\nCompose embedded actions — bridge + swap + deposit into DeFi in one transaction\n\nSupported Agents\nAgent FrameworkStatusClaude CodeSupportedCodexSupportedCursorSupportedOpenclawSupported\nTwo ways to connect\nApproachBest forSetupSkills CLI (npx skills add)Claude Code, Codex, Cursor, OpenclawOne command — installs tool definitions directly into your agent configMCP ServerClaude Desktop, Cursor, Windsurf, VS Code Copilot, CodexPoint your client at https://mcp.across.to/mcp — search docs, query chains, get live bridge fees\nUse both together or pick whichever fits your workflow.\nSupported Chains\nAcross currently supports 24+ mainnet chains — including Ethereum, Arbitrum, Optimism, Base, Polygon, Unichain, and other major L2s.\nFor the canonical list with contract addresses and explorer links, see the Chains & Contracts page. For the live machine-readable list, query the /swap/chains endpoint.\nHow it works\nThe skills package provides your agent with structured tool definitions that map directly to the Across Swap API. Your agent receives:\n\nChain discovery — query supported chains and tokens\nQuote generation — get executable calldata for any crosschain transfer\nTransaction execution — approval and bridge transaction helpers\nStatus tracking — monitor deposits until they're filled\n\nThe agent handles the entire flow autonomously — from selecting the right route to executing the transaction.\nExample prompt\nOnce the skill is installed, you can simply tell your agent:\nBridge 100 USDC from Arbitrum to Base\nThe agent will discover chains, look up token addresses, fetch a quote, handle approvals, and execute the bridge — all without any additional code.\n\nExplore\nMCP ServerSearch docs, query chains, and get live bridge fees from any MCP-compatible client. Hosted at mcp.across.to.Machine-Readable DocsFeed Across documentation to agents and RAG pipelines via llms.txt endpoints.AGENTS.md TemplateDrop-in AGENTS.md for repos integrating Across — gives coding agents full context.Prompt LibraryCurated prompts for discovery, quoting, execution, tracking, and DeFi composition.Agent WorkflowsEnd-to-end examples showing real agent sessions performing crosschain tasks.MCP ServerGive any MCP-compatible AI client full access to Across Protocol documentation, chain data, and live bridge fees.","tokens":761,"squid":"spider-09","role":"Bridge Spider","at":1791339026373,"hash":"d076cc9268921723ab0a705eca247103267ad43f"}
{"url":"https://forum.arbitrum.foundation/t/govhack-at-eth-cc-brussels/23305","domain":"forum.arbitrum.foundation","title":"GovHack at ETH CC (Brussels) - Proposals / Finalized AIPs - Arbitrum","text":"The Arbitrum Foundation notified the Security Council on the need to perform a potential Emergency action. Following a review of the details and known risks, the Security Council decided to execute the upgrade and it was completed at 11:30 EST on 2nd October 2026.\nThis report provides an overview of the risks that required the Security Council Action:\n\nAdd a permissionless guard for the One-Step Proof of BoLD on Arbitrum One\n\nTemporarily pause activation of new Stylus contracts on Arbitrum One & Nova\n\nKey point: To date, known bugs for Stylus primarily impact chain liveness (e.g., denial of service attacks) and do not put any user funds at risk.\nWhy was this action taken\nLet’s take this opportunity to explain why action was taken on two separate issues concerning BoLD and Stylus.\nInstalling the guard for One-Step Proof of BoLD. Given the rise of AI-assisted attacks, we have implemented a precautionary approach that allows anyone to pause settlement of Arbitrum One on Ethereum if there are at least two conflicting answers that pass at the same level in which only one should be valid and pass. This is to halt a class of publicly verifiable and detectable attacks that exploit a bug in the one-step proof. If halted, Arbitrum One will continue to process as normal except that messages from Arbitrum One to Ethereum, such as withdrawals, that are not yet confirmed will have to wait. This provides time for the Security Council to deploy a fix for the bug and resume the rollup.\nPreventing activation of new Stylus contracts. AI-assisted tooling has led to an increasing number of sophisticated attacks on hand-crafted WASM programs that do not use the standard Stylus compiler toolchain. These programs are specifically designed to cause unexpected behaviors such as degrading the chain’s performance for all other users. To date, no attacks have been discovered that permits theft of user funds.\nNew ArbOS releases have patched several reported bugs and known attacks over the past few months, but out of an abundance of caution, we have decided to temporarily pause new activations of Stylus contracts. This was executed as an emergency action to prevent the deployment of new hand-crafted WASM programs that are not yet patched by the current version of ArbOS on the Arbitrum network.\nThe Arbitrum Foundation has informed the Security Council that they will work with the ArbitrumDAO to discuss next steps on the timeline and manner for enabling activation of new Stylus contracts. The Arbitrum community remains confident in the value of Stylus and want to preserve these use cases while taking preventative measures against Stylus-based attack vectors as AI-assisted attack tooling continues to evolve.\nImpact on builders and users\n\nNo new activations. New Stylus contracts cannot be activated during the pause including new versions of existing applications that require activation.\n\nExisting contracts are not paused. Already-active Stylus contracts continue to execute until expiration. This pause does not deactivate them.\n\nThe ArbOS 61 upgrade renewed all active contracts on Arbitrum One, so no currently active contract expires before August 20, 2027.\n\nRenewal via keepalive stays permissionless and is unaffected by the pause.\n\nReactivating an expired contract, or one that needs to be updated after a Stylus version change, is paused.\n\nUsing/calling any activated Stylus contract stays permissionless for all users and developers.\n\nNo impact on EVM. Solidity (EVM) contract deployment and execution are unaffected by this Security Council action.\n\nSecurity Council Actions\nThere are two actions bundled into a single payload:\n\nOne-Step Proof Guard. The L1UpgradeExecutor gives a new pause contract (PauseExecutor) the ability to pause and nothing else. The new pause contract grants the guard (OspSoundnessGuard) PAUSER_ROLE to use it. Anyone can show the guard two conflicting answers to the same step of an open challenge. If the one-step proof accepts both, the guard has the pause contract put Arbitrum One’s settlement to Ethereum on hold.\n\nStylus deactivation. The Security Council called ArbOwner.setWasmActivationGas(2^64 - 1) to raise the Stylus activation gas requirement on Arbitrum One and Nova. This makes activation prohibitively expensive and effectively disables new activations. This is a configuration change and does not require an ArbOS upgrade.\n\nThe Security Council signed the following transactions to update the configuration:\n\nEthereum: Ethereum Transaction Hash: 0x30732bb7d2... | Etherscan\nArbitrum One:\nArbitrum One Transaction Hash: 0x9eb3a4be3b... | Arbitrum One\nArbitrum Nova:\nArbitrum Nova transaction 0x79e0fed470dff7a22059b108e3f8f42eddd2b580a6771594060c4e7326c5f984 | Blockscout\n\nAn external audit was conducted for the OSP Guard contracts. No audit is required for the Stylus deactivation as it is only updating a single parameter in the ArbOS configuration.\n\n GovHack at ETH CC (Brussels) \n\n ProposalsFinalized AIPs\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Apr 2024\n\n 1 / 52\n\n Apr 2024\n\n Aug 2024\n\n post by Entropy on Apr 19, 2024\n\n Entropy\n\n Hack Humanity: GovHack at ETH CC (Brussels)\nnon-constituional\nAbstract\nHack Humanity is seeking $309k of funding from the Arbitrum DAO to host an event and after-party coinciding with ETH CC in Brussels, Belgium. Arbitrum GovHack Brussels will take place as a 3-day event on July 5, 6, and 7, the days directly prior to the start of the conference. ETH CC is only 11 weeks away, so approving the funds ASAP is of the utmost importance to ensure that Arbitrum has a strong presence at one of the most important Ethereum-centric events of the year.\nHack Humanity intends to continue serving the DAO by planning IRL activations and will seek additional funding in the coming months. The time constraints for ETH CC have led us to propose funding solely for this event in hopes of an expedient proposal process prior to asking the DAO for a larger funding package that ensures a long-term and optimal solution for Arbitrum DAO’s event participation.\nGovHack Brussels aims to:\n\nBuild trust and deepen relationships between Arbitrum contributors\nIdeate and later implement proposals that benefit Arbitrum\nAttract new talent to the DAO\nPosition Arbitrum as the go-to home for talent to build and the DAO as a world-class operation maturing and innovating at the forefront of decentralized governance\n\nGovHack Brussels, improves on and expands GovHack ETHDenver with additional prize pool, the introduction of a subsidy pool for high-value contributors, enhancing and running a proper community showcase day, and adding a dedicated afterparty.\nMotivation\nIn a world of remote work, decentralized technology, and decentralized finance, the human social-layer needs intentional facilitation and development to mature and enable building this next paradigm of technology and new ways of working together. Online collaboration can only get us so far. A key competitive advantage for the ArbitrumDAO is strategically investing in growing a high-trust network of talented contributors, delegates, service providers, and builders on Arbitrum. GovHack ETHDenver proved the thesis that in-person opportunities for the DAO to work together represent a significant competitive advantage for Arbitrum.\n\nIf you are aiming to learn more about what GovHack aims to achieve, please check out their ETHDenver:\n\nPitch deck\nImpact Report - 9.1 star rating and 67% NPS from participants\nMedia production\nAftermovie:\n\n GovHack Aftermovie - ETHDenver 2024 - Powered by Hack Humanity\n\nHack Humanity, was previously funded with a grant from the Arbitrum Foundation to host GovHack ETHDenver. Hack Humanity is looking to build on this success and momentum as an ecosystem development partner through IRL activations with the Arbitrum DAO for the long-term.\nIt is critical that Arbitrum has a significant presence at industry-leading events, and that contributors have regular and consistent IRL opportunities to grow high-trust relationships. It builds community and brand while attracting users, developers, and other important DAO contributors.\nHack Humanity offers deep custom work pre-event; with ecosystem mapping, facilitating community co-design processes to develop tracks & challenge statements most relevant to Arbitrum, identifying target talent contributor personas, skill gap analysis of who to market and recruit to the ecosystem. Hack Humanity drives innovation through unique custom IRL experiences that mature and evolve the DAO’s capabilities.\n1600×912 352 KB\nA well-run event typically requires a minimum of 3 months of lead time, with factors such as securing suppliers, the team’s calendar, and venue down payments requiring capital upfront from the event organizer. We are less than 90 days out from ETH CC, and at this point Arbitrum is not well-positioned to have a strong presence in Brussels. Klaus (Hack Humanity founder) has exemplified his ability to host high-quality IRL activations on behalf of the Arbitrum DAO in the past, so we believe that getting funds approved ASAP so that Hack Humanity can begin organizing a governance hackathon and an after-party is very important.\nRelevant Hack Humanity resources:\n\nArbitrum GovHack Video (ETHDenver)\n\nGovHack ETH Denver forum proposal\nImpact report\n\nKlaus’ work at IBM\nCompany Website\n\nHack Humanity Pitch Deck\n\nYouTube Channel\nTwitter\n\nRationale\nThe most successful crypto brands, such as Uniswap, LayerZero, dYdX, and others, prioritize brand presence at events to reaffirm their positions as industry leaders. ETH CC is an Ethereum-focused event, and Arbitrum should lean into that given its status as the leading Ethereum L2. These events provide substantial value, such as brand strengthening, community building, attracting developer talent, in-person ideation, and more.\nMany hackathons cost north of $1M with smart contract base layers like Near, zkSync, Avalanche, and others throwing events/hackathons with more than 1000 participants. It’s important Arbitrum remains competitive with these other protocols to ensure its ability to attract talent.\nSpecifications\nGovHack will run for three days, boast a prize pool of $20k for GovHack participants, have t-shirts and other swag for attendees to get their hands on, and pre, mid, and post-event media production and storytelling to represent the voice of the DAO and to amplify the event on social platforms.\nGovHack is 3 events in 1: A 2-day hackathon-style bootcamp, followed by a 1-day Community Showcase, followed by an afterparty. Hack Humanity is looking to build on GovHack ETHDenver’s success and coevolve with the DAO over the long term.\nFor GovHack Brussels a full impact report and transparency around the event and its cost will be posted in the forum following its completion.\nSteps to Implement\nOnce spending is approved by the DAO, funds will be sent to a ⅔ multisig to be converted into dollars. These dollars will be used to pay for the costs associated with running and organizing the event. Hack Humanity will provide event details on the forum so that the entire community can participate in the event’s scope and execution.\n50% of the funds will be paid to Hack Humanity upon this proposal’s approval. An additional 35% will be disbursed the week before the event, and the final 15% will be disbursed after the event concludes.\nThe 3 multisig signers will be: Klaus + Abdullah Umar (Arana Digital) + Krzysztof Urbański\nThe multisig address is (arb1) 0x03D47B06Cc95bAFf2a408cD7c735ed7e7142Edb9\nAny excess funds from the $309k that are not spent on the Brussels event will be rolled over and used to fund future Arbitrum events, but only if the DAO votes to spend additional funds on future events before the end of August. If the DAO votes against further spending on events, or a proposal fails to pass by the end of August, the excess ARB will be returned to the DAO.\nTimeline\nThe event will take place July 5, 6, and 7 (2024) in Brussels, Belgium directly before ETH CC. Given the strict timeline, we are hoping to proceed to Snapshot on Wednesday, April 24th (if delegates approve), in order to hopefully have funds earmarked by the end of May.\nMore details will be shared with the DAO in the weeks leading up to the event surrounding the specifics of GovHack.\n502×1246 40 KB\nWith the expedited process as outlined, Hack Humanity will only have a ~5 week buffer to plan the event. It is paramount that if the DAO wants representation at ETH CC, we move with haste.\nOverall Cost\nBrussels is an expensive European city, and successfully executing a world-class high-quality IRL activation requires a significant budget.\nThe event’s research, preparation and delivery phase determines the exact event program design, local costs, the number of participants, any scholarships/stipends, etc. Getting the funds approved is the top priority so that Hack Humanity can begin to work out these details.\nThe all-in cost to execute this proposal is expected to be $309k, with a rough budget broken down in the following table:\n\nItem\nCost\n\nVenue, Food, Drink, Swag, room equipment, interior decor, printing, stationery\n$85,000\n\nMarketing, targeted contributor outreach, Pre/Post Event Media Production, AV equipment rental, hackathon management software and other licensing\n$33,000\n\nHackathon Prize Pool\n$20,000\n\nScholarships\n$10,000\n\nAfter-party + Contingency\n$50,000\n\nOn-site living costs (5 days, lead in, lead out day + 3 delivery days for a team of 7): Flights, Accommodation, Ubers, Food\n$13,000\n\nHack Humanity margin and fees. GovHack Director and assistant to design, organize, deliver the event. Designer, local Brussels event producer advisory, on-site GovHack delivery team (7). Post-event Impact Report, community engagement, handover.\n$98,000\n\nTotal Cost:\n$309,000\n\nAny excess funds from the $309k that are not spent on the Brussels event will be rolled over and used to fund future Arbitrum events, but only if the DAO votes to spend additional funds on future events before the end of August. If the DAO votes against further spending on events, or a proposal fails to pass by the end of August, the excess ARB will be returned to the DAO.\nThe amount of ARB to be moved to the multisig will be determined in accordance with the dollar equivalent of the trailing 14D ARB TWAP with a 30% buffer. After the ARB is swapped to USDC, any amount in excess of $309k will be immediately back to the DAO.\nThe scope of this proposal to the DAO is specifically for ETH CC in Brussels. Hack Humanity intends to produce a subsequent proposal to provide a year-round program of events on behalf of the Arbitrum DAO, this will require a larger funding package, with a component to cover a full-time team & and a component for an event budget to cover a series of IRL events. Hack Humanity needs the ability to hire and maintain a dedicated team committed to Arbitrum, this uniquely enables high-context, up to date and relevant continual program design in lockstep with the needs of Arbitrum’s roadmap and community needs, it also enables Hack Humanity and team to commit and block calendar dates for future events 6-12 months in advance, secure venues, and team member’s time. This requires upfront funding.\nExpect another proposal for further funding in the coming months. We need this GovHack Brussels proposal to be executed swiftly so that the event in Brussels can be organized as soon as possible, hence our decision to seek funding only for this event rather than trying to pass a larger DAO spend.\n\n 23 Apr 2024 - Open Discussion of Proposals Governance Call\n\n GovHack ETHcc Brussels 2024 - Impact Report - Hack Humanity\n\n GovHack ETHDenver 2024 - Impact Report - Hack Humanity\n\n Arbitrum DAO News: RFP for Grants, GovHack Brusells and M&A Working Group, April 25th\n\n 5\n\n 4\n\n 3\n\n 3\n\n 2\n\n read \n\n 12\n min\n\n post by Frisson on Apr 19, 2024\n\n Frisson\n\n I’m supportive of this proposal. GovHack in Denver was an important event that catalyzed many new initiatives in the DAO. I thought the format did a great job of mirroring Arbitrum’s decentralized nature while organizing around relevant themes. I think it’s important that Arbitrum has a strong presence at ETH CC and am confident Hack Humanity can deliver. See you there!\n\n post by JoJo on Apr 19, 2024\n\n JoJo\n\n unfortunately i missed denver due to work related stuff.\none of the thing i wanted to participate to, and that I heard very good things, was indeed GovHack.\nI am glad that the idea is to expand what was done in Denver in EthCC. This initiatives are really needed in our ecosystem, live events, in which you can effectively connect, are part of that portion of marketing in which we still lack a bit as a Dao. And as Frisson said, making participation “decentralized” like in our Dao matches not only our Ethos but also our way of working.\nI suggest 2 things to improve this proposal:\n\nproviding a few examples/comparison for uneducated people (like me) who don’t know too much about cost related to the organization of big events\nas we did in questbook, since your costs are USD denominated, I would suggest for you to ask for the amount needed converted based on the 14d twap + 30% buffer. This buffer can be given back, right away, as soon as there is the conversion, plus or minus whatever the market movement has been. You don’t want to find yourself in the situation of requesting funds, going to snapshot, then tally, and when is time to start paying to do stuff you don’t have enough cause market nuked.\n\n post by DisruptionJoe on Apr 20, 2024\n\n DisruptionJoe\n\n I think this is an important proposal which must be moved forward quickly.\n\nIt was a well run initiative which succeeded in its goals and exceeded expectations.\n\nIt means a lot that we reward work well done with renewal and expanded scope. It is important to any potential contributor to see that we reward the behaviors that will help attract top talent and succeed.\n\nFull support.\n\n post by NathanVDH on Apr 20, 2024\n\n NathanVDH\n\n Very happy to support this. As I am from Brussels, I’m also happy to help if needed.\n\n post by Bobbay on Apr 22, 2024\n\n Bobbay\n\n Unfortunately I could not attend last time due to other commitments, but I heard a lot of great feedback.\nI support this proposal. A fair amount of contributions came from the last govhack, and with more preparation and notice, this can be elevated to the next level.\n\n post by Pruitt on Apr 22, 2024\n\n Pruitt\n\n From my experience planning two multi-day conferences as part of @404DAO, the costs associated with GovHack’s proposal are reasonable. For our Web3 ATL conferences (~350 to 400 people), our team had similar budgets for the venue, food, AV equipment, pre/post production etc. Providing the quality event experience that the Arbitrum community should strive for will require these types of costs.\nOverall I thought GovHack in Denver was a great success, and it is worth expanding upon and bringing to other conferences. And as mentioned in the proposal, these IRL opportunities are vital to growing high-trust relationships and Arbitrum needs to have a presence at major industry events.\n\nI will also echo the urgency presented by Entropy in this proposal. A three-month lead time for an event of this scale will be challenging. It is possible, but every day counts at this point. Hopefully this can move through the DAO quickly.\n\n post by thedevanshmehta on Apr 22, 2024\n\n thedevanshmehta\n\n I attended govhack in ethdenver & am hugely supportive of the proposal. There was good attendance, lots of interest from first timers in writing proposals for the forum & also top delegates who gave feedback. I actually spoke about govhack to ethglobal & buidlbox , both of whom were startled at the innovativeness of a hackathon where the primary output is proposals\nThe pilot in ethdenver was successful and i strongly endorse contributing it for eth cc & if successful there too, devcon. The arbitrum foundation covered some of their costs last time due to the short time period but we should not expect this again. ecosystem growth is the DAOs primary responsibility and gov hack is high RoI on that front.\n\n post by DisruptionJoe on Apr 23, 2024\n\n DisruptionJoe\n\n I’d love to see this on snapshot in the minimal amount of time.\nWhat do people think about a “loan” from Plurality Labs to let the team get a head start as soon as snapshot is conclusive?\n\n post by JoJo on Apr 23, 2024\n\n JoJo\n\nthis helps a lot understanding costs, which imho at this point is the only thing that needed a clarification since most of the dao seems quite positive on the initiative itself, thanks\n\n post by Bobbay on Apr 23, 2024\n\n Bobbay\n\n DisruptionJoe\n\n If it’s a vast majority voting in favor of the snapshot, then I see no harm in PL providing a loan to enable HH to start the work ASAP since these types of events take a lot of time and the onchain voting takes an awful long time.\nIn the above case of a large majority, its somewhat fair to assume that its most likely to pass a Tally vote along as no major changes are made.\n\n post by Entropy on Apr 23, 2024\n\n Entropy\n\n Great to see all the support! Following @JoJo’s advice, we have made 1 amendment to the proposal.\nBefore: “The amount of ARB to be moved to the multisig will be determined in accordance with the dollar equivalent of the trailing 14D ARB TWAP”\nNow: \"The amount of ARB to be moved to the multisig will be determined in accordance with the dollar equivalent of the trailing 14D ARB TWAP with a 30% buffer. After the ARB is swapped to USDC, any amount in excess of $309k will be immediately back to the DAO.\nWe plan to move to Snapshot in 24 hours.\n\n post by carlosjmelgar on Apr 23, 2024\n\n carlosjmelgar\n\n It’s really impressive seeing delegates coordinate to fast track this proposal. This was one of the EthDenver events that generated the most hype. Looking forward to attending in Brussels.\n\n post by Bernard on Apr 23, 2024\n\n Bernard\n\n It’s been great reading through the transparency report and improvements being made. Besides the intangbile value out of the proposals and connections being made on-site (which we can do a better job in materializing after the GovHack, knowing this is high on Klaus’ agenda), I feel this was a key community event for the DAO. Fully support a continuation.\n\n post by BlockworksResearch on Apr 23, 2024\n\n BlockworksResearch\n\n Given the circumstances, a one-off funding request here makes sense. From what we can tell, the first event has been extremely valuable, both in tangible and intangible terms. Combined with the well-defined expense structure that seems to be fair in comparison to other similar events (although, if possible, it would be great if a high-level overview of how these figures have been estimated could be provided), we feel comfortable in fully supporting this initiative.\nAs a side note, we’d more than encourage exploring the feasibility of this solution proposed by @DisruptionJoe as, in the best-case scenario, it could add several weeks to the event planning timeline:\n\nEDIT: based on the above, Blockworks Research will vote FOR this proposal on Snapshot.\n\n Blockworks Research – Delegate Communication Thread\n\n post by Pepperoni_Jo3 on Apr 24, 2024\n\n Pepperoni_Jo3\n\n These comments and thoughts reflect my personal opinions on this proposal. Whilst I am a member of the Arbitrum Representative Council (ARC), they do not necessarily represent the overall views of the council or provide an indication of final voting decision\nI am in favour of this proposal as it seems the Denver event was of immense value. I would like to see this be the start of a structured and consistent presence for Arbitrum DAO across all major conferences (events WG?).\nThanks for putting this together @KlausBrave. The loan suggestion @DisruptionJoe also seems a good idea.\n\n post by jengajojo on Apr 24, 2024\n\n jengajojo\n\n As a participant in the last Gov Hack in Denver, I really enjoyed the event and it brought many mission aligned delegates together to work on purposeful projects. hence i am happy to support this initiative.\n\n post by JoJo on Apr 25, 2024\n\n JoJo\n\n Voting “for” on this on snapshot.\nI wasn’t in Denver, I plan to be in Brussel, and I have only heard good thing about govHack.\nTeam here has the challenge of putting up the org of a big event in less than 2 and a half month: realistically, they will need funds asap to start paying vendors and suppliers.\nVoting for, and hope that a couple of days after snapshot is over goes directly to tally, for the sake of proper execution.\nSeveral people were also able to testify about budget being rightly sized for this type of event, which was my main concern (and the main concern of others).\n\n JoJo Delegate Communication Thread\n\n post by 0x_ultra on Apr 25, 2024\n\n 0x_ultra\n\n I’m voting in support of this proposal passing.\nETH CC is the largest European crypto conference and it only seems fitting to host a GovHack there as well. I’ve heard good feedback coming from participants of the ETHDenver edition and know plenty of people who would love to take part in the Brussels one.\nThere is a huge need of getting people together to work on governance related issues, I hope it becomes a tradition to host GovHack at major crypto conferences around the world. Another great candidate for a future edition could be Devcon Southeast Asia this November?\n\n post by Cryptosquare on Apr 26, 2024\n\n Cryptosquare\n\n Hi!\nAt Cryptosquare, we’re based locally and organize Web3 events throughout the year. We also host side events for ETHCC on behalf of others.\nIf you’re looking for someone local to collaborate closely with, we can help!\nLet us know if you’re interested \n\n Load more posts below","tokens":6428,"squid":"spider-07","role":"Council Spider","at":1791339030974,"hash":"f9bbb4cb2df8df59d84fa0e806bf8696ea0104d3"}
{"url":"https://jobs.arbitrum.io/companies/alchemy-2/jobs/95679819-accounts-payable-specialist","domain":"jobs.arbitrum.io","title":"Accounts Payable Specialist @ Alchemy | Arbitrum Job Board","text":"Accounts Payable SpecialistAlchemyAccounting & Finance · Full-timeSan Francisco, CA, USAPosted on Oct 3, 2026Apply nowAbout AlchemyAlchemy is the Web3 infrastructure and developer platform that powers millions of users and the world’s most innovative blockchain applications. From enabling $1+ trillion in financial transactions worldwide to scaling L2s and enabling DeFi, Alchemy provides the infrastructure and tools developers need to build reliable, scalable, and accessible experiences. Trusted by companies like JPMorgan, Stripe, Visa, Franklin Templeton, Nike, and backed by a16z, Coatue, Silver Lake, Lightspeed, and Stanford University, Alchemy is building the foundational layer for a decentralized and AI-enabled Web3 ecosystem. For more information, visit alchemy.com. About The RoleWe’re looking for an Accounts Payable Specialist to join our Finance team and take ownership of daily AP activities, including accurate invoice coding, timely payments, vendor support, and reconciliations.Reporting to our Procurement Manager, you’ll partner with Accounting and teams across Alchemy to keep our procure-to-pay process running smoothly across Zip, NetSuite, and Ramp. You’ll help strengthen existing processes, troubleshoot issues independently, and identify opportunities to improve how we work. This role requires attention to detail, dependability, and proactive communication.What You’ll DoDaily AP Operations Manage the AP inbox, promptly process incoming invoices and requests, and serve as a primary point of contact for vendors and internal teams. Review, enter, classify, and code vendor invoices in Zip and NetSuite, ensuring complete documentation, appropriate approvals, and purchase order matching where applicable. Prepare payment batches for review and approval, monitor payment deadlines, and follow up on outstanding approvals or missing information. Support vendor onboarding and maintain accurate vendor records, including tax forms, addresses, payment terms, and verified banking information. Investigate and resolve invoice discrepancies, duplicate charges, missing credits, and payment issues; escalate exceptions when needed. Review employee expenses and corporate card transactions in Ramp for accurate coding, receipts, approvals, and policy compliance. Close Support & Special Projects Reconcile AP activity and balances with the general ledger, investigate differences, and ensure invoices, credits, and payments are properly recorded. Support month-end close by identifying unrecorded invoices and potential accruals and preparing supporting schedules for Accounting. Maintain vendor tax documentation, including W-9s, and support annual 1099 preparation. Follow established approval and payment controls, including verification procedures for vendor banking changes. Maintain organized records and provide AP documentation for internal reviews and external audits. Support system updates, workflow improvements, and other projects affecting procurement, expenses, accounts payable, and FP&A. What We’re Looking For 2–4 years of experience in accounts payable or a related accounting operations role, with hands-on responsibility for invoice processing and vendor support. Curiosity about how processes work and initiative to make them better. A solid understanding of invoice coding, purchase orders, payment terms, reconciliations, and basic accrual accounting. Experience with accounting or ERP systems and the ability to learn new P2P, payment, and AI tools. Strong Excel or Google Sheets skills, including lookups, pivot tables, and reconciling data across reports. Strong attention to detail, sound judgment, and a habit of checking your work. The ability to manage recurring deadlines, prioritize competing requests, and follow through independently. Clear, practical communication and a collaborative approach to working with vendors and colleagues. Nice to Haves Experience with NetSuite, Zip, or Ramp. Experience at a growing technology company or Big 4 accounting firm. Experience improving AP workflows or using automation to reduce repetitive work. Experience with crypto, digital assets, blockchain, or web3 is a plus, but not required. Benefits and Perks🏥 Medical, Dental, & Vision💪 Gym Reimbursement🖥️ Home Office Build-out Budget🥙 In-Office Group Meals🚅 Commuter Benefits🌴 Flexible Time Off🧘‍♂️ Wellbeing & Mental Health Perks🧠 Learning & Development Stipend🌎 Company Sponsored Conferences & Events💸 HSA and FSA Plans🧬 Fertility Benefits Alchemy is committed to offering competitive compensation, including base salary as well as bonus and equity. Additionally, Alchemy offers comprehensive medical, dental, and vision coverage, as well as other benefits such as 401k and unlimited flexible time off.Apply nowSee more open positions at Alchemy","tokens":1202,"squid":"spider-01","role":"Chain Spider","at":1791339037834,"hash":"65138ca731450ed4f4c71bba1df0544585fe2860"}
{"url":"https://consensysdiligence.github.io/smart-contract-best-practices/attacks/force-feeding/","domain":"consensysdiligence.github.io","title":"Force Feeding - Ethereum Smart Contract Best Practices","text":"Force Feeding\n\nTip\nThank you for visiting the Smart Contract Security Best Practices. Please note that this resource is no longer actively maintained. Instead, we recommend visiting the Smart Contract Security Field Guide. The Field Guide is regularly updated and curated by the same security engineer who previously contributed to the Best Practices guide.\nThe resource on unexpected Ether transfers can be found here: https://scsfg.io/hackers/unexpected-ether/\n\nForcing a smart contract to hold an Ether balance can influence its internal accounting and security assumptions.\nThere are multiple ways a smart contract can receive Ether. The hierarchy is as follows:\n\nCheck whether a payable external receive function is defined.\nIf not, check whether a payable external fallback function is defined.\nRevert.\n\nThe precedence of each function is explained in this great graphic from the Solidity by Example article:\nWhich function is called, fallback() or receive()?\n\n send Ether\n |\n msg.data is empty?\n / \\\n yes no\n / \\\nreceive() exists? fallback()\n / \\\n yes no\n / \\\n receive() fallback()\n\nConsider the following example:\npragma solidity ^0.8.13;\n\ncontract Vulnerable {\n receive() external payable {\n revert();\n }\n\n function somethingBad() external {\n require(address(this).balance > 0);\n // Do something bad\n }\n}\n\nThe contract's logic seemingly disallows direct payments and prevents \"something bad\" from happening.\nHowever, calling revert in both fallback and receive cannot prevent the contract from receiving Ether.\nThe following techniques can be used to force-feed Ether to a smart contract.\nSelfdestruct¶\nWhen the SELFDESTRUCT opcode is called, funds of the calling address are sent to the address on the stack, and execution is immediately halted.\nSince this opcode works on the EVM-level, Solidity-level functions that might block the receipt of Ether will not be executed.\nPre-calculated Deployments¶\nAdditionally, the target address of newly deployed smart contracts is generated in a deterministic fashion.\nThe address generation can be looked up in any EVM implementation, such as the py-evm reference implementation by the Ethereum Foundation:\ndef generate_contract_address(address: Address, nonce: int) -> Address:\n return force_bytes_to_address(keccak(rlp.encode([address, nonce])))\n\nAn attacker can send funds to this address before the deployment has happened.\nThis is also illustrated by this 2017 Underhanded Solidity Contest submission.\nBlock Rewards and Coinbase¶\nDepending on the attacker's capabilities, they can also start proof-of-work mining.\nBy setting the target address to their coinbase, block rewards will be added to its balance.\nAs this is yet another EVM-level capability, checks performed by Solidity are ineffective.\nSolution¶\nThe above effects illustrate that relying on exact comparisons to the contract's Ether balance is unreliable.\nThe smart contract's business logic must consider that the actual balance associated with it can be higher than the internal accounting's value.\nIn general, we strongly advise against using the contract's balance as a guard.\nMore information can be found in SWC-132.","tokens":785,"squid":"spider-06","role":"Security Spider","at":1791339044232,"hash":"9678bb6071df5df28343344d61419cc5c720c0ad"}
{"url":"https://docs.phantom.com/recipes","domain":"docs.phantom.com","title":"Recipes - Phantom developer documentation","text":"Recipes are complete, working code examples organized by what you want to build. Each recipe includes full source code you can copy directly into your project.\n​Popular\nGet started quickly with these commonly used recipes.\n\n​All recipes\n\n​Authentication\nConnect users to your app with Phantom wallets.\n\n​Payments\nSend and receive tokens on Solana.\n\n​Signatures\nSign messages for user agreements, terms of service, or data integrity.\n\n​Wallet operations\nCheck balances, view token accounts, and manage wallet state.\n\n​Transactions\nAdvanced transaction features for better user experience and monitoring.\n\n​Quickstarts\nGet up and running in your framework of choice.\n\n​Example apps\nProduction-ready example applications on GitHub.\nWas this page helpful?","tokens":188,"squid":"spider-10","role":"Tooling Spider","at":1791339047150,"hash":"fe2b0134a399cd584ad5ff15da3f840633ea1dd3"}
{"url":"https://jobs.arbitrum.io/jobs","domain":"jobs.arbitrum.io","title":"Jobs | Arbitrum Job Board","text":"Job title, company or keywordOn-site & RemoteLocationJob functionSenioritySalaryIndustryCompany stageCompany sizeCompanyPowered by GetroShowing 131 jobsSenior HR GeneralistArbitrumLocation: RemotePosted: TodaySeniorBlockchainBlockchain and CryptocurrencyEthereumSmart ContractsSoftware DevelopmentWeb3Senior HR GeneralistOffchain LabsLocation: RemotePosted: TodaySeries BSeniorBlockchainBlockchain and CryptocurrencyBusiness/Productivity SoftwareCryptocurrency+ 19 moreCybersecurityDecentralized FinanceDeFiDeveloper ToolsEnterprise SoftwareEthereumFinancial SoftwareFintechNetwork SecurityPlatformPrivacy and SecuritySecuritySmart ContractsSoftwareSoftware DevelopmentSoftware Development ApplicationsTechnologyWeb DevelopmentWeb3Customer Product Engineer, EMEAAlchemyLocation: Bucharest, RomaniaPosted: TodayAssociateBlockchainBlockchain and CryptocurrencyDeveloper APIsDeveloper PlatformSoftwareWeb3Chief Marketing Officer / Head of GrowthOwn global distribution: the budget, the channels, the team, and the number at the end of it.gTradeLocation: RemotePosted: 1 dayDirectorFinancial SoftwareOther Financial ServicesAccounts Payable SpecialistAlchemyLocation: San Francisco, CA, USAPosted: 4 daysAssociateBlockchainBlockchain and CryptocurrencyDeveloper APIsDeveloper PlatformSoftwareWeb3Senior Backend Engineer, NitroOffchain LabsLocation: United StatesPosted: 6 daysSeries BSeniorBlockchainBlockchain and CryptocurrencyBusiness/Productivity SoftwareCryptocurrency+ 19 moreCybersecurityDecentralized FinanceDeFiDeveloper ToolsEnterprise SoftwareEthereumFinancial SoftwareFintechNetwork SecurityPlatformPrivacy and SecuritySecuritySmart ContractsSoftwareSoftware DevelopmentSoftware Development ApplicationsTechnologyWeb DevelopmentWeb3Anti-Fraud Engineer (Spain)CrossmintLocation: Madrid, SpainCompensation: EUR 95k-125k / year + EquityPosted: 7 daysSeniorBlockchainBlockchain and CryptocurrencyDeveloper ToolsFinancial ServicesFintechPaymentsSoftware+ 1 moreSoftware DevelopmentTechnical Support EngineerQuickNodeLocation: United States; PortugalPosted: 7 daysAssociateAPIBlockchainBlockchain and CryptocurrencyBlockchain ServicesCryptocurrencydAppsDeFi+ 20 moreDeveloper ToolsDistributed SystemsEnterpriseEthereumFinanceFinancial ServicesInternetInternet ServicesManaged Ethereum NodeOther Financial ServicesP2PPlatformPolygonSaaSSoftwareSoftware Development ApplicationsSolanaStablecoinsTechnologyWeb3Senior Infrastructure Engineer, Core SystemsQuickNodeLocation: United States; PortugalPosted: 7 daysSeniorAPIBlockchainBlockchain and CryptocurrencyBlockchain ServicesCryptocurrencydAppsDeFi+ 20 moreDeveloper ToolsDistributed SystemsEnterpriseEthereumFinanceFinancial ServicesInternetInternet ServicesManaged Ethereum NodeOther Financial ServicesP2PPlatformPolygonSaaSSoftwareSoftware Development ApplicationsSolanaStablecoinsTechnologyWeb3Senior Software Engineer - Go & Rust, Blockchain InfrastructureQuickNodeLocation: United States; PortugalPosted: 7 daysSeniorAPIBlockchainBlockchain and CryptocurrencyBlockchain ServicesCryptocurrencydAppsDeFi+ 20 moreDeveloper ToolsDistributed SystemsEnterpriseEthereumFinanceFinancial ServicesInternetInternet ServicesManaged Ethereum NodeOther Financial ServicesP2PPlatformPolygonSaaSSoftwareSoftware Development ApplicationsSolanaStablecoinsTechnologyWeb3Senior Software Engineer - GoQuickNodeLocation: United States; PortugalPosted: 7 daysSeniorAPIBlockchainBlockchain and CryptocurrencyBlockchain ServicesCryptocurrencydAppsDeFi+ 20 moreDeveloper ToolsDistributed SystemsEnterpriseEthereumFinanceFinancial ServicesInternetInternet ServicesManaged Ethereum NodeOther Financial ServicesP2PPlatformPolygonSaaSSoftwareSoftware Development ApplicationsSolanaStablecoinsTechnologyWeb3Growth Marketing LeadAlchemyLocation: San Francisco, CA, USA; New York, NY, USAPosted: 8 daysSeniorBlockchainBlockchain and CryptocurrencyDeveloper APIsDeveloper PlatformSoftwareWeb3Product Marketing Manager, PlatformAlchemyLocation: San Francisco, CA, USA; New York, NY, USAPosted: 8 daysMid-Senior LevelBlockchainBlockchain and CryptocurrencyDeveloper APIsDeveloper PlatformSoftwareWeb3Solutions EngineerZZZ-WLSN-PROBELocation: United StatesPosted: 9 daysMid-Senior LevelApplication SoftwareBlockchainBlockchain and CryptocurrencyBlockchain ServicesCryptocurrency+ 21 moreDecentralized Finance (DeFi)DeFiEthereumFinanceFinancial ServicesFinancial SoftwareFintechGamingInternet ServicesLaw Govt And PoliticsLendingLending and InvestmentsOpen SourceOther Financial ServicesPaymentsPeer To PeerSmart ContractsSoftwareTechnologyVenture CapitalWeb3Market AnalystDouro LabsLocation: North America; RemotePosted: 9 daysMid-Senior LevelData & AnalyticsDatabaseSoftwareWeb DevelopmentBrand DesignerDouro LabsLocation: North America; RemotePosted: 10 daysMid-Senior LevelData & AnalyticsDatabaseSoftwareWeb DevelopmentSenior Backend EngineerOffchain LabsLocation: RemoteCompensation: USD 193,461-291k / yearPosted: 12 daysSeries BSeniorBlockchainBlockchain and CryptocurrencyBusiness/Productivity SoftwareCryptocurrency+ 19 moreCybersecurityDecentralized FinanceDeFiDeveloper ToolsEnterprise SoftwareEthereumFinancial SoftwareFintechNetwork SecurityPlatformPrivacy and SecuritySecuritySmart ContractsSoftwareSoftware DevelopmentSoftware Development ApplicationsTechnologyWeb DevelopmentWeb3Senior Backend EngineerArbitrumLocation: RemoteCompensation: USD 193,461-291k / yearPosted: 12 daysSeniorBlockchainBlockchain and CryptocurrencyEthereumSmart ContractsSoftware DevelopmentWeb3Senior Investment LeadArbitrumLocation: Cayman IslandsPosted: 14 daysSeniorBlockchainBlockchain and CryptocurrencyEthereumSmart ContractsSoftware DevelopmentWeb3Head of EnterpriseOffchain LabsLocation: United StatesPosted: 18 daysSeries BDirectorBlockchainBlockchain and CryptocurrencyBusiness/Productivity SoftwareCryptocurrency+ 19 moreCybersecurityDecentralized FinanceDeFiDeveloper ToolsEnterprise SoftwareEthereumFinancial SoftwareFintechNetwork SecurityPlatformPrivacy and SecuritySecuritySmart ContractsSoftwareSoftware DevelopmentSoftware Development ApplicationsTechnologyWeb DevelopmentWeb3","tokens":1527,"squid":"spider-01","role":"Chain Spider","at":1791339053449,"hash":"3c3840a63ee5e19cd3774ebff1034bb983cfc050"}
{"url":"https://docs.phantom.com/recipes/payments/send-spl-token","domain":"docs.phantom.com","title":"Send any SPL token - Phantom developer documentation","text":"Send any SPL token by providing the token’s mint address and decimals.\n React Browser SDK React Nativeimport { useSolana } from \"@phantom/react-sdk\";\nimport { Connection, PublicKey, VersionedTransaction, TransactionMessage } from \"@solana/web3.js\";\nimport { getAssociatedTokenAddress, createAssociatedTokenAccountInstruction, createTransferInstruction, getAccount } from \"@solana/spl-token\";\n\nfunction SendToken() {\n const { solana } = useSolana();\n\n const send = async (\n to: string,\n amount: number,\n mintAddress: string,\n decimals: number\n ) => {\n const connection = new Connection(\"https://api.mainnet-beta.solana.com\");\n const from = new PublicKey(await solana.getPublicKey());\n const recipient = new PublicKey(to);\n const mint = new PublicKey(mintAddress);\n\n const fromATA = await getAssociatedTokenAddress(mint, from);\n const toATA = await getAssociatedTokenAddress(mint, recipient);\n\n const instructions = [];\n\n // Create recipient's token account if needed\n try {\n await getAccount(connection, toATA);\n } catch {\n instructions.push(\n createAssociatedTokenAccountInstruction(from, toATA, recipient, mint)\n );\n }\n\n instructions.push(\n createTransferInstruction(fromATA, toATA, from, amount * 10 ** decimals)\n );\n\n const { blockhash } = await connection.getLatestBlockhash();\n const transaction = new VersionedTransaction(\n new TransactionMessage({\n payerKey: from,\n recentBlockhash: blockhash,\n instructions,\n }).compileToV0Message()\n );\n\n const { signature } = await solana.signAndSendTransaction(transaction);\n return signature;\n };\n\n return (\n <button onClick={() => send(\n \"RECIPIENT_ADDRESS\",\n 100,\n \"DezXAZ8z7PnrnRJjz3wXBoRgixCa6xjnB7YaB1pPB263\", // BONK\n 5\n )}>\n Send 100 BONK\n </button>\n );\n}\nimport { BrowserSDK, AddressType } from \"@phantom/browser-sdk\";\nimport { Connection, PublicKey, VersionedTransaction, TransactionMessage } from \"@solana/web3.js\";\nimport { getAssociatedTokenAddress, createAssociatedTokenAccountInstruction, createTransferInstruction, getAccount } from \"@solana/spl-token\";\n\nconst sdk = new BrowserSDK({\n providers: [\"google\", \"apple\", \"injected\"],\n appId: \"your-app-id\",\n addressTypes: [AddressType.solana],\n});\n\nasync function sendToken(\n to: string,\n amount: number,\n mintAddress: string,\n decimals: number\n) {\n const connection = new Connection(\"https://api.mainnet-beta.solana.com\");\n const from = new PublicKey(await sdk.solana.getPublicKey());\n const recipient = new PublicKey(to);\n const mint = new PublicKey(mintAddress);\n\n const fromATA = await getAssociatedTokenAddress(mint, from);\n const toATA = await getAssociatedTokenAddress(mint, recipient);\n\n const instructions = [];\n\n try {\n await getAccount(connection, toATA);\n } catch {\n instructions.push(\n createAssociatedTokenAccountInstruction(from, toATA, recipient, mint)\n );\n }\n\n instructions.push(\n createTransferInstruction(fromATA, toATA, from, amount * 10 ** decimals)\n );\n\n const { blockhash } = await connection.getLatestBlockhash();\n const transaction = new VersionedTransaction(\n new TransactionMessage({\n payerKey: from,\n recentBlockhash: blockhash,\n instructions,\n }).compileToV0Message()\n );\n\n const { signature } = await sdk.solana.signAndSendTransaction(transaction);\n return signature;\n}\nimport { useSolana } from \"@phantom/react-native-sdk\";\nimport { Connection, PublicKey, VersionedTransaction, TransactionMessage } from \"@solana/web3.js\";\nimport { getAssociatedTokenAddress, createAssociatedTokenAccountInstruction, createTransferInstruction, getAccount } from \"@solana/spl-token\";\nimport { View, Button, Alert, StyleSheet } from \"react-native\";\n\nfunction SendToken() {\n const { solana } = useSolana();\n\n const send = async (\n to: string,\n amount: number,\n mintAddress: string,\n decimals: number\n ) => {\n try {\n const connection = new Connection(\"https://api.mainnet-beta.solana.com\");\n const from = new PublicKey(await solana.getPublicKey());\n const recipient = new PublicKey(to);\n const mint = new PublicKey(mintAddress);\n\n const fromATA = await getAssociatedTokenAddress(mint, from);\n const toATA = await getAssociatedTokenAddress(mint, recipient);\n\n const instructions = [];\n\n try {\n await getAccount(connection, toATA);\n } catch {\n instructions.push(\n createAssociatedTokenAccountInstruction(from, toATA, recipient, mint)\n );\n }\n\n instructions.push(\n createTransferInstruction(fromATA, toATA, from, amount * 10 ** decimals)\n );\n\n const { blockhash } = await connection.getLatestBlockhash();\n const transaction = new VersionedTransaction(\n new TransactionMessage({\n payerKey: from,\n recentBlockhash: blockhash,\n instructions,\n }).compileToV0Message()\n );\n\n const { signature } = await solana.signAndSendTransaction(transaction);\n Alert.alert(\"Success\", `Transaction sent: ${signature}`);\n return signature;\n } catch (error) {\n Alert.alert(\"Error\", error instanceof Error ? error.message : \"Transaction failed\");\n throw error;\n }\n };\n\n return (\n <View style={styles.container}>\n <Button\n title=\"Send 100 BONK\"\n onPress={() => send(\n \"RECIPIENT_ADDRESS\",\n 100,\n \"DezXAZ8z7PnrnRJjz3wXBoRgixCa6xjnB7YaB1pPB263\", // BONK\n 5\n )}\n />\n </View>\n );\n}\n\nconst styles = StyleSheet.create({\n container: {\n padding: 20,\n },\n});\n\n​Popular tokens\nTokenMint AddressDecimalsUSDCEPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v6USDTEs9vMFrzaCERmJfrF4H2FYD4KCoNkY11McCe8BenwNYB6BONKDezXAZ8z7PnrnRJjz3wXBoRgixCa6xjnB7YaB1pPB2635JUPJUPyiwrYJFskUPiHa7hkeR8VUtAeFoSYbKedZNsDvCN6WIFEKpQGSJtjMFqKZ9KQanSqYXRcF8fBopzLHYxdM65zcjm6Was this page helpful?","tokens":1361,"squid":"spider-10","role":"Tooling Spider","at":1791339060501,"hash":"808d7d4bf833580240d3bf698b41715a7307f551"}
{"url":"https://consensysdiligence.github.io/smart-contract-best-practices/attacks/frontrunning/","domain":"consensysdiligence.github.io","title":"Frontrunning - Ethereum Smart Contract Best Practices","text":"Frontrunning\n\nTip\nThank you for visiting the Smart Contract Security Best Practices. Please note that this resource is no longer actively maintained. Instead, we recommend visiting the Smart Contract Security Field Guide. The Field Guide is regularly updated and curated by the same security engineer who previously contributed to the Best Practices guide.\nThe resource on frontrunning attacks can be found here: https://scsfg.io/hackers/frontrunning/\n\nSince all transactions are visible in the mempool for a short while before being executed,\nobservers of the network can see and react to an action before it is included in a block. An\nexample of how this can be exploited is with a decentralized exchange where a buy order transaction\ncan be seen, and second order can be broadcast and executed before the first transaction is\nincluded. Protecting against this is difficult, as it would come down to the specific contract\nitself.\nFront-running, coined originally for traditional financial markets, is the race to order the chaos\nto the winner's benefit. In financial markets, the flow of information gave birth to intermediaries\nthat could simply profit by being the first to know and react to some information. These attacks\nmostly had been within stock market deals and early domain registries, such as whois gateways.\n\nfront-run·ning (/ˌfrəntˈrəniNG/)\nnoun: front-running;\n\nSTOCK MARKET\n\nthe practice by market makers of dealing on advance information provided by their brokers and investment analysts, before their clients have been given the information.\n\nTaxonomy¶\nBy defining a taxonomy and differentiating each group from\nanother, we can make it easier to discuss the problem and find solutions for each group.\nWe define the following categories of front-running attacks:\n\nDisplacement\nInsertion\nSuppression\n\nDisplacement¶\nIn the first type of attack, a displacement attack, it is not important for Alice’s (User)\nfunction call to run after Mallory (Adversary) runs her function. Alice’s can be orphaned or run\nwith no meaningful effect. Examples of displacement include:\n\nAlice trying to register a domain name and Mallory registering it first;\nAlice trying to submit a bug to receive a bounty and Mallory stealing it and submitting it first;\nAlice trying to submit a bid in an auction and Mallory copying it.\n\nThis attack is commonly performed by increasing the gasPrice higher than network average, often\nby a multiplier of 10 or more.\nInsertion¶\nFor this type of attack, it is important to the adversary that the original function call runs\nafter her transaction. In an insertion attack, after Mallory runs her function, the state of the\ncontract is changed and she needs Alice’s original function to run on this modified state. For\nexample, if Alice places a purchase order on a blockchain asset at a higher price than the best\noffer, Mallory will insert two transactions: she will purchase at the best offer price and then\noffer the same asset for sale at Alice’s slightly higher purchase price. If Alice’s transaction is\nthen run after, Mallory will profit on the price difference without having to hold the asset.\nAs with displacement attacks, this is usually done by outbidding Alice's transaction in the gas\nprice auction.\n\nTransaction Order Dependence\nTransaction Order Dependence is equivalent to race\ncondition in smart contracts. An example, if one function sets the reward percentage, and the\nwithdraw function uses that percentage; then withdraw transaction can be front-run by a change\nreward function call, which impacts the amount that will be withdrawn eventually.\nSee SWC-114\n\nSuppression¶\nIn a suppression attack, a.k.a Block Stuffing attacks, after Mallory runs her function, she tries\nto delay Alice from running her function.\nThis was the case with the first winner of the \"Fomo3d\" game and some other on-chain hacks. The\nattacker sent multiple transactions with a high gasPrice and gasLimit to custom smart contracts\nthat assert (or use other means) to consume all the gas and fill up the block's gasLimit.\n\nVariants\nEach of these attacks has two variants, asymmetric and bulk.\nIn some cases, Alice and Mallory are performing different operations. For example, Alice is trying to cancel an offer, and Mallory is trying to fulfill it first. We call this asymmetric displacement. In other cases, Mallory is trying to run a large set of functions: for example, Alice and others are trying to buy a limited set of shares offered by a firm on a blockchain. We call this bulk displacement.\n\nMitigations¶\nFront-running is a pervasive issue on public blockchains such as Ethereum.\nThe best remediation is to remove the benefit of front-running in your application, mainly by\nremoving the importance of transaction ordering or time. For example, in markets, it would be\nbetter to implement batch auctions (this also protects against high-frequency trading concerns).\nAnother way is to use a pre-commit scheme (“I’m going to submit the details later”). A third option\nis to mitigate the cost of front-running by specifying a maximum or minimum acceptable price range\non a trade, thereby limiting price slippage.\nTransaction Ordering: Go-Ethereum (Geth) nodes, order the transactions based on their\ngasPrice and address nonce. This, however, results in a gas auction between participants in the\nnetwork to get included in the block currently being mined.\nConfidentiality: Another approach is to limit the visibility of the transactions, this can be\ndone using a \"commit and reveal\" scheme.\n\nA simple implementation is to store the keccak256 hash of the data in the first transaction, then\nreveal the data and verify it against the hash in the second transaction. However note that the\ntransaction itself leaks the intention and possibly the value of the collateralization. There are\nenhanced commit and reveal schemes that are more secure, however require more transactions to\nfunction, e.g. submarine sends.","tokens":1483,"squid":"spider-06","role":"Security Spider","at":1791339063185,"hash":"9abd29c8ca4ebabd3aef397ab092831977b006f8"}
{"url":"https://developers.jup.ag/docs/legal/sdk-api-license-agreement","domain":"developers.jup.ag","title":"SDK & API License Agreement - Jupiter Developers","text":"IMPORTANT: This Jupiter API & SDK License Agreement (“Agreement”) govern your access and use of the Jupiter Application Programming Interface (“API”) and a Software Development Kit (“SDK”) available through https://developers.jup.ag/portal (collectively the “Service”). If you do not agree to be bound by the terms and conditions of this Agreement, do not use the Service.\nThis Agreement is effective as of the date you first access, download, copy or otherwise use the API or SDK (“Effective Date”), and constitutes the entire agreement between you and us. This Agreement shall continue until terminated either by us or by you. Even after termination of this Agreement, certain provisions will survive, as discussed herein.\nThis Agreement also incorporates Jupiter’s Terms of Service and Privacy Policy which terms shall also govern your use of the Service. Our Privacy Policy, in particular explains how, to the extent that we do, your data may be collected. In the event of any conflict between this Agreement and the Terms of Service or Privacy Policy, the provisions of this Agreement shall prevail.\nYOU ARE ENTERING A LEGALLY BINDING CONTRACT: BY COPYING, DOWNLOADING, OR OTHERWISE USING THE JUPITER API OR SDK YOU ARE EXPRESSLY AGREEING TO BE BOUND BY ALL TERMS OF THIS AGREEMENT. IF YOU DO NOT AGREE TO ALL OF THE TERMS OF THIS AGREEMENT, YOU ARE NOT AUTHORIZED TO COPY, DOWNLOAD, INSTALL OR OTHERWISE USE THE JUPITER API or SDK.\nThe API and SDK are protected by copyright laws and international copyright treaties, as well as other intellectual property laws and treaties. The API and SDK is licensed to you, and its use is subject to the terms of this Agreement.\n1. Definitions​\n1.1 “Application Programming Interfaces” or “API” or “Jupiter API” means the back-end smart routing algorithm which facilitates the user’s efficient swapping of digital assets at a variety of third party trading venues, which may include object code, software libraries, software tools, sample source code, published specifications and Documentation. Jupiter API shall include any future, updated or otherwise modified version(s) thereof furnished by Jupiter (in its sole discretion) to Licensee.\n1.2 “Software Development Kit” or “SDK” or “Jupiter SDK” means the ancillary tools and resources that allow the user to utilise or integrate the API. Jupiter SDK shall include any future, updated or otherwise modified version(s) thereof furnished by Jupiter (in its sole discretion) to Licensee.\n1.3 “Documentation” includes, but is not limited to programmer guides, manuals, materials, and information appropriate or necessary for use in connection with the API, and in particular shall include the Integrator Guidelines available at https://developers.jup.ag/docs/legal.\n2. Grant of License​\n2.1 Subject to the terms of this Agreement, Jupiter hereby grants Licensee a limited, non-exclusive, fee-bearing, non-transferable, non-sublicensable licence to use the API or SDK during the term of this Agreement solely for the purpose of Licensee’s internal development efforts to develop products or services integrating the API and/or SDK in any manner, including without limitation for any informational, comparison, or testing purpose (the Licensee’s Product).\n2.2 Licensee shall have no right to distribute, license (whether or not through multiple tiers) or otherwise transfer the API or SDK to any third party.\n2.3 There are several formulations and versions of the API routing engine, which comprise either (a) the Jupiter Ultra Swap API, and (b) the Metis Swap API. Notwithstanding any of the provisions herein, where the Licensee uses the API or SDK (including without limitation for any informational, comparison, or testing purpose), you unconditionally and irrevocably undertake to correctly and accurately display prominently/label/name/characterise the specific API used, which must be made visible to end users of the Licensee’s Product. For illustrative purposes, if the Licensee uses Jupiter Ultra Swap, it would be mandatory to prominently state “Jupiter Ultra”; if the Licensee uses anything available API other than Jupiter Ultra Swap, it would be mandatory to prominently state “Metis”. The Licensee accepts that it is misleading and unethical to wrongly display/label/name/characterise the API and any output of the API as “Jupiter” simpliciter or otherwise suggest it is the same product as the service available at https://jup.ag/, or represent that another API routing engine is utilised. Without prejudice to clause 11 below, in the event of your breach of this clause 2.3, you agree to indemnify us to the extent any loss or damages are suffered by, as a result of, or in connection with, your breach of this clause 2.3, including but not limited to pure and/or consequential economic loss.\n2.4 In case of potential other API or SDK use that is not prescribed by this Agreement, please write to info@jup.ag to seek written consent.\n2.5 Representations. Both Parties to this Agreement are duly organized and validly existing in good standing with all requisite power and authority to enter into this Agreement and conduct its business as is now being conducted. The Licensee is not identified on, or engages in any transactions with any party listed on, any sanctions list maintained by the U.S. Department of the Treasury’s Office of Foreign Asset Control (“OFAC”).\n2.6 By providing access to the API and the SDK, Jupiter is solely providing a back-end technical service to the Licensee which allows the Licensee to provide swap-related services to end users of the Licensee’s products or services. Jupiter is not a party to any agreement for swap-related services between the Licensee, its end users, any counterparty or trading venue where swaps are performed, nor any trustee, custodian, bailee, manager, administrator or service provider in respect of any digital asset or otherwise.\n2.7 Independent Contractor Relationship. The relationship between the Parties is that of independent contractors. Nothing in this Agreement shall be construed to create anything like the relationship of an employer and employee, joint venture, partnership, or joint association.\n3. Other Rights and Limitations​\n3.1 Copies. Licensee may copy the API or SDK only as necessary for the purpose of the licence hereunder.\n3.2 Except as expressly authorised under this Agreement or by Jupiter in writing, the Licensee agrees it shall not (and shall not permit or authorise any other person to):\na. use the API or SDK in any manner that is not expressly authorised by this Agreement;\nb. use the API or SDK or develop or use the Licensee’s Product (i) for any illegal, unauthorised or otherwise improper purposes or (ii) in any manner which would violate this Agreement or the Documentation, breach any laws, regulations, rules or orders (including those relating to virtual assets, intellectual property, data privacy, data transfer, international communications or the export of technical or personal data) or violate the rights of third parties (including rights of privacy or publicity);\nc. remove any legal, copyright, trademark or other proprietary rights notices contained in or on materials it receives or is given access to pursuant to this Agreement, including the API, the SDK and the Documentation;\nd. sell, lease, share, transfer or sublicense the API, SDK or any content obtained through the API, directly or indirectly, to any third party;\ne. use the API or SDK in a manner that, as determined by Jupiter in its sole discretion, exceeds reasonable request volume, constitutes excessive or abusive usage, or otherwise fails to comply or is inconsistent with any part of the Documentation;\nf. access the API or SDK for competitive analysis or disseminate performance information (including uptime, response time and/or benchmarks) relating to the API;\ng. use the API in conjunction with, or combine content from the API with, content obtained through scraping or any other means outside the API;\nh. (i) interfere with, disrupt, degrade, impair, overburden or compromise the integrity of the API, Jupiter’s systems or any networks connected to the API or Jupiter’s systems (including by probing, scanning or testing their vulnerability), (ii) disobey any requirements, procedures, policies or regulations of networks connected to the API or Jupiter’s systems, (iii) attempt to gain unauthorised access to the API, Jupiter’s systems or any information not permitted by this Agreement or circumvent any access or usage limits imposed by Jupiter or (iv) transmit through the Licensee’s Product or the use of the API or SDK any (A) content that is illegal, tortious, defamatory, vulgar, obscene, racist, ethnically insensitive, or invasive of another person’s privacy, (B) content that promotes illegal or harmful activity, or gambling or adult content, (C) viruses, worms, defects, Trojan horses, or any other malicious programs or code or items of a destructive nature or (D) materials that could harm minors in any way;\ni. copy, adapt, reformat, reverse-engineer, disassemble, decompile, download, translate or otherwise modify or create derivative works of the API, the SDK or the Documentation, Jupiter’s website, or any of Jupiter’s other content, products or services, through automated or other means;\nj. interfere with Jupiter’s business practices or the way in which it licenses or distributes the API or SDK;\nk. make any representations, warranties or commitments (i) regarding the API or SDK or (ii) on behalf of Jupiter; or\nl. take any action that would subject the API or SDK to any third-party terms, including without limitation any open source software licence terms.\n3.3 Without prejudice of the generality of the foregoing, where the Licensee’s Product is competitive (whether wholly or partially) with the API or the Service, Jupiter shall have the right to access the Licensee’s Product and/or request the Licensee for information regarding the Licensee’s Product. Jupiter shall be granted a non-exclusive, royalty-free, non-transferable, non-sublicensable licence to use the Licensee’s Product (including without limitation any application programming interface, software development kit, logos, brand information, technical information or data or information in connection with any aspect of the Licensee’s Product) for any purpose.\n3.4 Third Party Software. Licensee acknowledges that effective utilization of the API and SDK may require the use of a development tool, compiler and other software and technology of third parties (“Third Party Software”). Licensee is solely responsible for procuring such Third-Party Software and technology and the necessary licenses for the use thereof. Jupiter makes no representation or warranty concerning Third Party Software and shall have no obligation or liability with respect to Third Party Software.\n3.5 No right is granted to Licensee to sublicense its rights hereunder. All rights not expressly granted are reserved by Jupiter and, except as expressly set forth herein, no license is granted by Jupiter under this Agreement directly, by implication, estoppel or otherwise, under any patent, copyright, trade secret or trademark or other intellectual property rights of Jupiter. Nothing herein shall be deemed to authorize Licensee to use Jupiter`s trademarks or trade names in Licensee’s advertising, marketing, promotional, sales or related materials. Jupiter reserves all rights not otherwise expressly granted in this Agreement.\n3.6 No assertion by Licensee. Licensee agrees not to assert any patent rights related to the API/SDK or applications developed using the API/SDK against Jupiter, Jupiter’s participants, or other licensees of the API/SDK for making, using, selling, offering for sale, or importing any products or technology developed using the API/SDK.\n3.7 Jupiter may from time to time provide updates or upgrades to the API or SDK. Any such updates and upgrades will be performed according to Jupiter’s then-current operational policies, which may include automatic updating or upgrading of API or SDK currently in use at that time. Where the Licensee fails to accept such updates or upgrades, Jupiter shall be entitled to withhold access to the API, SDK and/or Service, and the same shall not constitute any breach of the terms of this Agreement.\n4. Intellectual Property and proprietary rights\n4.1 As between Jupiter and Licensee, Jupiter and/or its licensors shall own and retain all proprietary rights, including all patent, copyright, trade secret, trademark and other intellectual property rights, in and to the API and SDK and any corrections, bug fixes, enhancements, updates, improvements, or modifications thereto and (to the extent such rights accrue to the Licensee), the Licensee hereby irrevocably transfers, conveys and assigns to Jupiter all of its right, title, and interest therein.\n4.2 Jupiter shall have the exclusive right to apply for or register any patents, mask work rights, copyrights, and such other proprietary protections with respect thereto.\n4.3 The Licensee acknowledges that the license granted under this Agreement does not provide Licensee with title or ownership to the API or SDK, but only a right of limited use under the terms and conditions of this Agreement.\n4.4 The Parties acknowledge that Jupiter does not store, send, or receive digital assets. Digital assets exist only by virtue of the ownership record maintained on the relevant blockchain network. Any creation or transfer of title that might occur in respect of any digital asset occurs on the relevant blockchain network (on the relevant contractual terms applicable to such creation and/or transfer) and is performed by the Licensee’s Product, and Jupiter does not have any role or responsibility in such transactions. Jupiter cannot guarantee that the Licensee’s Product, or any party can effect the transfer of such title or right to any digital asset. Accordingly, Jupiter cannot provide any guarantee, warranty or assurance regarding the authenticity, uniqueness, originality, quality, marketability, legality or value of any digital assets utilised in connection with the API and the Services.\n5. No Obligation to Support​\n5.1 Subject to payment of fees as described herein, Jupiter would issue to the Licensee certain unique API keys, tokens, passwords and/or other credentials (collectively, “Keys”), for accessing the API and/or SDK and managing the Licensee’s access to the API. The Licensee may only access the API with the Keys issued to the Licensee by Jupiter. The Licensee acknowledges that access to the API may not always be available. The Licensee may not sell, transfer, sublicense or otherwise disclose its Keys to any other party or use them for any other purpose other than that expressly permitted by Jupiter. The Licensee is responsible for maintaining the secrecy and security of the Keys. The Licensee is fully responsible for all activities that occur using the Keys, regardless of whether such activities are undertaken by the Licensee or a third party. The Licensee is responsible for maintaining up-to-date and accurate information (including a current email address and other required contact information) for the Licensee’s access to the API and SDK. Jupiter may discontinue the Licensee’s access to the API and SDK if such contact information is not up-to-date and/or the Licensee does not respond to communications directed to such coordinates.\n5.2 Jupiter makes no guarantees with respect to the performance, availability or uptime of the API or the SDK. Jupiter may conduct maintenance on or stop providing any of the API or the SDK at any time with or without written notice to the Licensee. In addition, Jupiter may change the method of access to the API, SDK and Documentation at any time.\n5.3 Jupiter does not guarantee any support for the API or SDK under this Agreement. Nothing herein shall be construed to require Jupiter to provide consultations, support services or updates, upgrades, bug fixes or modifications to the API or SDK. In the event of degradation or instability of Jupiter’s system or an emergency, Jupiter may, in its sole discretion, suspend access to the API and/or SDK.\n5.4 Jupiter reserves the right to change the method of access to the API or SDK at any time to ensure the safety and security of its environment. In the event of degradation or instability of Jupiter`s systems or in an emergency, you acknowledge and agree that Jupiter may, in its sole and absolute discretion, temporarily suspend your access to the API or SDK in order to minimize threats to and protect the operational stability and security of the Jupiter system.\n6. Fees & Payment​\n6.1 Jupiter shall charge a subscription fee for usage of the Jupiter API and/or SDK. This may be a fixed fee, infrastructure fee and/or a variable fee based on revenue earned by the Licensee in respect of the Licensee’s Product.\n6.2 The details of the level of fees charged shall be notified to you via the API portal at https://developers.jup.ag/portal. By accessing, downloading, copying or otherwise using the API or SDK, you shall be deemed to have consented to said fees.\n6.3 The Fees may be reviewed by Jupiter at any time commencing from three (3) months after the Effective Date. Any updated fees shall be notified to you via the API portal and your continued usage of the API or SDK shall be deemed consent to such updated fees.\n7. Licensee’s Obligations\n7.1 The Licensee agrees to report to Jupiter any errors or difficulties discovered related to the API or SDK, and the characteristic conditions and symptoms of such errors and difficulties.\n7.2 The Licensee shall perform such sanity testing, cybersecurity testing or other technical checks in respect of the API or SDK as may be reasonably requested by Licensor from time to time.\n7.3 The Licensee shall ensure that the offering/provision of the Licensee’s Product complies with all applicable laws and regulations, including without limitation all consumer protection, Know Your Customer (KYC) or Anti-money Laundering (AML) due diligence laws, sanctions, anti-money laundering or terrorist financing laws, securities laws, payment provider laws, or virtual assets regulations. Without prejudice to the generality of the foregoing, the Licensee shall (a) obtain and maintain in force (or as applicable procure the obtaining and maintenance in force of) all necessary licenses, permissions, authorisations, consents and permits which may be necessary or desirable for the offering/provision of the Licensee’s Product and (b) perform transaction screening and monitoring of all digital wallets interacting with the Client’s Product, including blocking of sanctioned, blacklisted, prohibited, restricted, flagged, illicit, suspicious or crime-associated digital wallets, in accordance with prevailing best market practice. The Licensee shall be solely responsible for any failure to comply with the foregoing.\n7.4 The Licensee acknowledges and agrees that all reporting, information gathering and other obligations under applicable Know Your Customer (KYC) or Anti-money Laundering (AML) due diligence laws, sanctions, anti-money laundering or terrorist financing laws, securities laws, payment provider laws, or virtual assets regulations with respect to the Licensee’s end-users are the responsibility of the Licensee; and Jupiter shall not be responsible or have any liability for any of the foregoing. The Licensee agrees to provide such information to Jupiter if reasonably requested by Jupiter.\n7.5 Without prejudice to the foregoing, upon written request from Jupiter, the Licensee shall use all efforts to block any specific digital wallet or address from accessing the Licensee’s Product and/or the API integration.\n7.6 The Licensee agrees to immediately notify Jupiter if (i) the Licensee becomes aware of any security event, including any cybersecurity breach, attack or economic exploit relating to the Licensee’s Product or (ii) the Licensee’s Product, API, SDK or the Service becomes subject to any legal or regulatory investigation or action.\n7.7 The Licensee shall be responsible for all customer service for all its products and services (including the Licensee’s Product).\n8. Confidentiality​ and Publicity\n8.1 The API and SDK contains valuable proprietary information and trade secrets of Jupiter and its suppliers that remain the property of Jupiter. You shall protect the confidentiality of, and avoid disclosure and unauthorized use of, the API or SDK.\n8.2 Without prejudice to the generality of the foregoing, you agree not to disparage Jupiter, any of its affiliates, or any of their directors, shareholders, employees, servants, contractors, or agents in any manner, or otherwise make any false, misleading or negative statements to any party about Jupiter or any of its affiliates, the Service (or any output of the Service), or any other product(s) or service(s) of Jupiter or any of its affiliates.\n8.3 Jupiter may disclose and publicise the existence of the business relationship between Jupiter and you on its website and in promotional and marketing materials without requiring any further consent from you.\n8.4 Subject to clause 2.3 above, you shall ensure that the Licensee’s Product shall prominently display to end users of such product or service the message “Powered by Jupiter”.\n9. No Warranty​\n9.1 The API, SDK, and Documentation are provided “AS-IS” without any warranty whatsoever. To the full extent allowed by law, the foregoing warranties and remedies are exclusive and are in lieu of all other warranties, terms, or conditions, express or implied, either in fact or by operation of law, statutory or otherwise, including warranties, terms, or conditions of merchantability, fitness for a particular purpose, satisfactory quality, correspondence with description, and non-infringement, all of which are expressly disclaimed.\n9.2 No advice or information, whether oral or written, obtained by you from Jupiter or through or from the API/SDK shall create any warranty not expressly stated in this agreement. Jupiter does not warrant that the API, SDK and Documentation are suitable for Licensee’s use, that the API, SDK or Documentation are without defect or error, that operation will be uninterrupted, or that defects will be corrected. Further, Jupiter makes no warranty regarding the results of the use of the API, SDK, and Documentation.\n10. Limitation of Liability​\nJUPITER WILL NOT BE LIABLE FOR ANY DAMAGES OF ANY KIND ARISING OUT OF OR RELATING TO THE USE OR THE INABILITY TO USE THE API, SDK AND ITS USE OR THE INABILITY TO USE WITH ANY THIRD PARTY SOFTWARE, ITS CONTENT OR FUNCTIONALITY, INCLUDING BUT NOT LIMITED TO DAMAGES FOR LOSS OF BUSINESS PROFITS OR REVENUE; BUSINESS INTERRUPTION OR WORK STOPPAGE; COMPUTER FAILURE OR MALFUNCTION; LOSS OF BUSINESS INFORMATION, DATA OR DATA USE; LOSS OF GOODWILL; DAMAGES CAUSED BY OR RELATED TO ERRORS, OMISSIONS, INTERRUPTIONS, DEFECTS, DELAY IN OPERATION OR TRANSMISSION, COMPUTER VIRUS, FAILURE TO CONNECT, NETWORK CHARGES, AND ALL OTHER DIRECT, INDIRECT, SPECIAL, INCIDENTAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES EVEN IF JUPITER HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OR LIMITATION OF INCIDENTAL OR CONSEQUENTIAL DAMAGES, SO THE ABOVE EXCLUSIONS OR LIMITATIONS MAY NOT APPLY TO YOU. NOTWITHSTANDING THE FOREGOING, JUPITER TOTAL LIABILITY TO LICENSEE FOR ALL LOSSES, DAMAGES, CAUSES OF ACTION, INCLUDING BUT NOT LIMITED TO THOSE BASED ON CONTRACT, TORT, OR OTHERWISE, ARISING OUT OF YOUR USE OF THE API/SDK AND/OR INTELLECTUAL PROPERTY ON THIS TECHNOLOGY PLATFORM OR API/SDK, OR ANY OTHER PROVISION OF THIS AGREEMENT, SHALL NOT EXCEED THE AMOUNT OF 100 USD. THE FOREGOING LIMITATIONS, EXCLUSIONS, AND DISCLAIMERS SHALL APPLY TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, EVEN IF ANY REMEDY FAILS ITS ESSENTIAL PURPOSE.\n11. Indemnity​\nYou agree to indemnify and hold harmless Jupiter and its contributors, subsidiaries, affiliates, officers, agents, Intellectual Property service providers, co-branders, customers, suppliers or other partners, and employees, from any loss, claim or demand, including reasonable attorneys’ fees, made by any third party due to or arising out of your negligence, error, omissions, or failure to perform relating to your use of the API/SDK, your connection to the API, or your violation of the Agreement.\n12. Disclaimers\n12.1 UNLESS SEPARATELY STATED IN A WRITTEN EXPRESS LIMITED WARRANTY, THE API AND SDK PROVIDED BY JUPITER IS PROVIDED “AS IS” AND ON AN “AS AVAILABLE” BASIS, WITHOUT WARRANTIES OF ANY KIND FROM JUPITER, EITHER EXPRESS OR IMPLIED. TO THE FULLEST EXTENT POSSIBLE PURSUANT TO APPLICABLE LAW, JUPITER DISCLAIMS ALL WARRANTIES EXPRESS, IMPLIED, OR STATUTORY, INCLUDING, BUT NOT LIMITED TO, IMPLIED WARRANTIES OF MERCHANTABILITY, SATISFACTORY QUALITY OR WORKMANSHIP LIKE EFFORT, FITNESS FOR A PARTICULAR PURPOSE, RELIABILITY OR AVAILABILITY, ACCURACY, LACK OF VIRUSES, QUIET ENJOYMENT, NON- INFRINGEMENT OF THIRD-PARTY RIGHTS OR OTHER VIOLATIONS OF RIGHTS. SOME JURISDICTIONS DO NOT ALLOW EXCLUSIONS OR LIMITATIONS OF IMPLIED WARRANTIES, SO THE ABOVE EXCLUSIONS OR LIMITATIONS MAY NOT APPLY TO YOU. NO ADVICE OR INFORMATION, WHETHER ORAL OR WRITTEN, OBTAINED BY YOU FROM JUPITER OR ITS AFFILIATES SHALL BE DEEMED TO ALTER THIS DISCLAIMER BY JUPITER OF WARRANTY REGARDING THE API OR SDK OR THE AGREEMENT, OR TO CREATE ANY WARRANTY OF ANY SORT FROM JUPITER.\n12.2 NEITHER JUPITER NOR THE API PROVIDES ANY DIGITAL ASSET EXCHANGE OR PORTFOLIO/FUND MANAGEMENT SERVICE. WHERE THE LICENSEE OR ANY END USER OF THE LICENSEE’S PRODUCT MAKES THE DECISION TO TRANSACT UTILISING THE API OR THE SERVICE, THEN SUCH DECISIONS AND TRANSACTIONS AND ANY CONSEQUENCES FLOWING THEREFROM ARE SUCH TRANSACTING PARTY’S SOLE RESPONSIBILITY.\n12.3 THE API FUNCTIONS SOLELY AS A BACK-END SUPPORTING TECHNICAL SERVICE FOR A SMART ROUTING ALGORITHM FOR DIGITAL ASSET SWAPS ONLY; IN NO CIRCUMSTANCES SHALL JUPITER, THE API OR THE SDK BE CONSTRUED AS A DIGITAL ASSET EXCHANGE, BROKER, DEALER, FUND MANAGER, FINANCIAL INSTITUTION, EXCHANGE, CUSTODIAN, ROBO-ADVISOR, INTERMEDIARY, OR CREDITOR.\n12.4 THE API DOES NOT FACILITATE OR ARRANGE DIGITAL ASSET TRANSACTIONS BETWEEN COUNTERPARTIES, INCLUDING WITH RESPECT TO ANY TRANSACTIONS THAT OCCUR IN CONNECTION WITH ANY DECENTRALISED EXCHANGE, LIQUIDITY POOL OR OTHER CENTRALISED OR DECENTALISED FINANCE PRODUCT / FACILITY, WHICH TRANSACTIONS OCCUR ON SUCH PLATFORM, PROTOCOL AND/OR THE RELEVANT BLOCKCHAIN NETWORK. JUPITER IS NOT A COUNTERPARTY TO ANY DIGITAL ASSET TRANSACTION FACILITATED BY THE API OR THE LICENSEE’S PRODUCT.\n12.5 There may be various vulnerabilities, failures or abnormal behaviour of software relating to digital assets (e.g., token contract, wallet, smart contract), or relating to the relevant blockchain network, and Jupiter cannot be responsible for any losses in connection with the same, including without limitation any losses in connection with (i) user error, such as forgotten passwords or incorrectly construed smart contracts or other transactions, (ii) server failure or data loss, (iii) corrupted wallet files, or (iv) unauthorised access or activities by third parties, including but not limited to the use of viruses, phishing, brute-forcing or other means of attack against the API or SDK, the relevant blockchain network, or the Licensee’s or any end user’s digital wallet.\n12.6 Jupiter disclaims any responsibility for any disclosure of information or any other practices of any third-party API provider. Jupiter expressly disclaims any warranty regarding whether your personal information is captured by any third-party API provider or the use to which such personal information may be put by such third-party API provider.\n13. Term and Termination​\n13.1 The effective date of this Agreement is the start of use of the API or SDK by the Licensee. There shall be a minimum term of 30 days for usage of the API to be paid for in advance (or such other minimum term as notified to you via the API portal at https://developers.jup.ag/portal).\n13.2 This Agreement will terminate automatically if you fail to comply with any of the terms and conditions of this Agreement and you will be liable to Jupiter and its suppliers for damages or losses caused by your non-compliance. The waiver by Jupiter of a specific breach or default shall not constitute the waiver of any subsequent breach or default.\n13.3 Either party shall have the right to terminate the Agreement (for any reason), by written notice to the other party and refunding a pro-rata portion of any unutilised fee paid (in the case of termination by Jupiter). For the purpose of the Licensee’s service of notice, it may contact legal@jup.ag.\n13.4 Upon termination of this Agreement, Licensee will immediately cease using the API and the SDK, and Licensee agrees to destroy all adaptations or copies of the API, SDK, and Documentation or return them to Jupiter upon the termination of this License.\n13.5 Jupiter shall have the right to review/audit your use of the API or SDK in conjunction with this Agreement, and you will provide reasonable assistance for this purpose.\n13.6 The rights of Jupiter and your obligations contained in this Agreement survive any expiration or termination of this Agreement.\n14. Applicable Law; Arbitration​\n14.1 Licensee and Jupiter agree to arbitrate any dispute arising from this Agreement, except for disputes in which either party seeks equitable and other relief for the alleged unlawful use of copyrights, trademarks, trade names, logos, trade secrets or patents. ARBITRATION PREVENTS LICENSEE FROM SUING IN COURT OR FROM HAVING A JURY TRIAL.\n14.2 Licensee and Jupiter agree to notify each other in writing of any dispute within thirty (30) days of when it arises. Notice to Jupiter shall be sent to legal@jup.ag.\n14.3 The Licensee and Jupiter shall cooperate in good faith to resolve any dispute, controversy or claim arising out of, relating to, or in connection with this Agreement, including with respect to the formation, applicability, breach, termination, validity or enforceability thereof (a “Dispute”) shall be settled in accordance with the laws of Panama. The parties undertake to carry out any award without delay and waive their right to any form of recourse insofar as such waiver can validly be made. Judgment upon the award may be entered by any court having jurisdiction thereof or having jurisdiction over the relevant party or its assets. Jupiter and the Licensee will each pay their respective attorneys’ fees and expenses. Any dispute arising out of or related to this Agreement is personal to the Licensee and Jupiter and will not be brought as a class arbitration, class action, or any other type of representative proceeding. There will be no class arbitration or arbitration in which a person attempts to resolve a dispute as a representative of another person or group of persons. Further, a dispute cannot be brought as a class or other type of representative action, whether within or outside of arbitration, or on behalf of any other person or group of persons.\n14.4 Any dispute between the parties will be governed by this Agreement and the laws of Panama, without giving effect to any conflict of laws principles that may provide for the application of the law of another jurisdiction. Whether the dispute is heard in arbitration or in court, Licensee and Jupiter will not commence against the other a class action, class arbitration or representative action or proceeding.\n15. Changes to this Agreement​\nWe may amend any portion of this Agreement at any time by posting the revised version of this Agreement on https://developers.jup.ag/portal with an updated revision date. The changes will become effective and shall be deemed accepted by you, the first time you use or access the SDK or API after the initial posting of the revised Agreement and shall apply on a going-forward basis with respect to your use of the SDK and/or API. In the event that you do not agree with any such modification, your sole and exclusive remedy is to terminate your use of the SDK and/or API.\n16. Miscellaneous​\n16.1 Assignment. Licensee may not assign this Agreement or any interest or rights granted hereunder to any third party without the prior written consent of Jupiter. A change of control or reorganization of Licensee pursuant to a merger, sale of assets or stock shall be deemed to be an assignment under this Agreement. This Agreement shall terminate immediately upon the occurrence of any prohibited assignment.\n16.2 Waiver. No failure by either party to exercise or enforce any of its rights under this Agreement will act as a waiver of such rights and no waiver of a breach in a particular situation shall be held to be a waiver of any other or subsequent breach.\n16.3 Severability. If any provision of this Agreement is found invalid or unenforceable, that provision will be enforced to the maximum extent possible and the other provisions of this Agreement will remain in force.\n16.4 Entire agreement. This Agreement represents the complete agreement concerning the API, SDK and oral amendments are void. If any provision of this Agreement is held to be unenforceable, such provision shall be reformed only to the extent necessary to make it enforceable.\n16.5 Neither Party hereto shall be responsible for any failure to perform its obligations under this Agreement if such failure is caused by acts of God, war, strikes, revolutions, lack or failure of transportation facilities, laws or governmental regulations or other causes that are beyond the reasonable control of such Party. Obligations hereunder, however, shall in no event be excused but shall be suspended only until the cessation of any cause of such failure.\n16.6 By installing, copying, or otherwise using this API or SDK, you acknowledge that you have read, understand and agree to be bound by the terms and conditions indicated above.Was this page helpful?","tokens":8518,"squid":"spider-02","role":"Liquidity Spider","at":1791339070183,"hash":"c7680a05e781dd882fcb1548c92c57b50085db69"}
{"url":"https://docs.phantom.com/recipes/payments/send-sol","domain":"docs.phantom.com","title":"Send SOL - Phantom developer documentation","text":"Send native SOL tokens to another wallet.\n React Browser SDK React Nativeimport { useSolana } from \"@phantom/react-sdk\";\nimport {\n Connection,\n PublicKey,\n VersionedTransaction,\n TransactionMessage,\n SystemProgram,\n LAMPORTS_PER_SOL,\n} from \"@solana/web3.js\";\n\nfunction SendSOL() {\n const { solana } = useSolana();\n\n const send = async (to: string, amount: number) => {\n const connection = new Connection(\"https://api.mainnet-beta.solana.com\");\n const { blockhash } = await connection.getLatestBlockhash();\n const from = new PublicKey(await solana.getPublicKey());\n\n const transaction = new VersionedTransaction(\n new TransactionMessage({\n payerKey: from,\n recentBlockhash: blockhash,\n instructions: [\n SystemProgram.transfer({\n fromPubkey: from,\n toPubkey: new PublicKey(to),\n lamports: amount * LAMPORTS_PER_SOL,\n }),\n ],\n }).compileToV0Message()\n );\n\n const { signature } = await solana.signAndSendTransaction(transaction);\n console.log(\"Transaction:\", signature);\n return signature;\n };\n\n return (\n <button onClick={() => send(\"RECIPIENT_ADDRESS\", 0.1)}>\n Send 0.1 SOL\n </button>\n );\n}\nimport { BrowserSDK, AddressType } from \"@phantom/browser-sdk\";\nimport {\n Connection,\n PublicKey,\n VersionedTransaction,\n TransactionMessage,\n SystemProgram,\n LAMPORTS_PER_SOL,\n} from \"@solana/web3.js\";\n\nconst sdk = new BrowserSDK({\n providers: [\"google\", \"apple\", \"injected\"],\n appId: \"your-app-id\",\n addressTypes: [AddressType.solana],\n});\n\nasync function sendSOL(to: string, amount: number) {\n const connection = new Connection(\"https://api.mainnet-beta.solana.com\");\n const { blockhash } = await connection.getLatestBlockhash();\n const from = new PublicKey(await sdk.solana.getPublicKey());\n\n const transaction = new VersionedTransaction(\n new TransactionMessage({\n payerKey: from,\n recentBlockhash: blockhash,\n instructions: [\n SystemProgram.transfer({\n fromPubkey: from,\n toPubkey: new PublicKey(to),\n lamports: amount * LAMPORTS_PER_SOL,\n }),\n ],\n }).compileToV0Message()\n );\n\n const { signature } = await sdk.solana.signAndSendTransaction(transaction);\n return signature;\n}\nimport { useSolana } from \"@phantom/react-native-sdk\";\nimport {\n Connection,\n PublicKey,\n VersionedTransaction,\n TransactionMessage,\n SystemProgram,\n LAMPORTS_PER_SOL,\n} from \"@solana/web3.js\";\nimport { View, Button, Alert, StyleSheet } from \"react-native\";\n\nfunction SendSOL() {\n const { solana } = useSolana();\n\n const send = async (to: string, amount: number) => {\n try {\n const connection = new Connection(\"https://api.mainnet-beta.solana.com\");\n const { blockhash } = await connection.getLatestBlockhash();\n const from = new PublicKey(await solana.getPublicKey());\n\n const transaction = new VersionedTransaction(\n new TransactionMessage({\n payerKey: from,\n recentBlockhash: blockhash,\n instructions: [\n SystemProgram.transfer({\n fromPubkey: from,\n toPubkey: new PublicKey(to),\n lamports: amount * LAMPORTS_PER_SOL,\n }),\n ],\n }).compileToV0Message()\n );\n\n const { signature } = await solana.signAndSendTransaction(transaction);\n Alert.alert(\"Success\", `Transaction sent: ${signature}`);\n return signature;\n } catch (error) {\n Alert.alert(\"Error\", error instanceof Error ? error.message : \"Transaction failed\");\n throw error;\n }\n };\n\n return (\n <View style={styles.container}>\n <Button\n title=\"Send 0.1 SOL\"\n onPress={() => send(\"RECIPIENT_ADDRESS\", 0.1)}\n />\n </View>\n );\n}\n\nconst styles = StyleSheet.create({\n container: {\n padding: 20,\n },\n});\nWas this page helpful?","tokens":861,"squid":"spider-10","role":"Tooling Spider","at":1791339073798,"hash":"07681484d67c12e69655824f3594e07a0386858b"}
{"url":"https://consensysdiligence.github.io/smart-contract-best-practices/attacks/deprecated/","domain":"consensysdiligence.github.io","title":"Deprecated/Historical - Ethereum Smart Contract Best Practices","text":"Deprecated/Historical\n\nThese are attacks which are no longer possible due to changes in the protocol or improvements to\nsolidity. They are recorded here for posterity and awareness.\nCall Depth Attack (deprecated)¶\nAs of the EIP 150 hardfork, call depth attacks are\nno longer\nrelevant*\n(all gas would be consumed well before reaching the 1024 call depth limit).\nConstantinople Reentrancy Attack¶\nOn January 16th, 2019, Constantinople protocol upgrade was delayed due to a security vulnerability\nenabled by EIP 1283. EIP 1283: Net gas metering for\nSSTORE without dirty maps proposes changes to reduce excessive gas costs on dirty storage writes.\nThis change led to possibility of a new reentrancy vector making previously known secure withdrawal\npatterns (.send() and .transfer()) unsafe in specific\nsituations*,\nwhere the attacker could hijack the control flow and use the remaining gas enabled by EIP 1283,\nleading to vulnerabilities due to reentrancy.","tokens":238,"squid":"spider-06","role":"Security Spider","at":1791339084919,"hash":"cc92eb66ea6de4d0e387ac5f07350a16778e7b75"}
{"url":"https://docs.phantom.com/recipes/payments/request-payment","domain":"docs.phantom.com","title":"Request payment - Phantom developer documentation","text":"Create a payment request link or QR code using Solana Pay that users can scan to pay you. This recipe shows how to use the Phantom SDK to get your wallet address and create payment requests.\n React Browser SDK React Nativeimport { PhantomProvider, useSolana, useAccounts, usePhantom, darkTheme } from \"@phantom/react-sdk\";\nimport { AddressType } from \"@phantom/browser-sdk\";\nimport { encodeURL, createQR } from \"@solana/pay\";\nimport { PublicKey, Keypair } from \"@solana/web3.js\";\nimport { useEffect, useRef } from \"react\";\nimport BigNumber from \"bignumber.js\";\n\n// USDC mint address\nconst USDC_MINT = new PublicKey(\"EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v\");\n\nfunction App() {\n return (\n <PhantomProvider\n config={{\n providers: [\"google\", \"apple\", \"injected\"],\n appId: \"your-app-id\",\n addressTypes: [AddressType.solana],\n authOptions: {\n redirectUrl: \"https://yourapp.com/auth/callback\",\n },\n }}\n theme={darkTheme}\n appName=\"Your Store\"\n >\n <PaymentRequest />\n </PhantomProvider>\n );\n}\n\nfunction PaymentRequest() {\n const { solana } = useSolana();\n const addresses = useAccounts();\n const { isConnected } = usePhantom();\n const qrRef = useRef<HTMLDivElement>(null);\n\n useEffect(() => {\n if (!isConnected || !addresses?.[0]) return;\n\n // Get your wallet address from the SDK\n const recipient = new PublicKey(addresses[0].address);\n const amount = new BigNumber(10); // 10 USDC\n const reference = new PublicKey(Keypair.generate().publicKey); // Unique identifier\n const label = \"Your Store\";\n const message = \"Thanks for your purchase!\";\n\n // Create the payment URL\n const url = encodeURL({\n recipient,\n amount,\n splToken: USDC_MINT,\n reference,\n label,\n message,\n });\n\n // Generate QR code\n const qr = createQR(url, 300, \"transparent\");\n\n if (qrRef.current) {\n qrRef.current.innerHTML = \"\";\n qr.append(qrRef.current);\n }\n }, [isConnected, addresses]);\n\n if (!isConnected) {\n return <div>Please connect your wallet to generate a payment request</div>;\n }\n\n return (\n <div>\n <h2>Scan to pay 10 USDC</h2>\n <p>Your wallet: {addresses?.[0]?.address}</p>\n <div ref={qrRef} />\n </div>\n );\n}\nimport { BrowserSDK, AddressType } from \"@phantom/browser-sdk\";\nimport { encodeURL, createQR } from \"@solana/pay\";\nimport { PublicKey, Keypair } from \"@solana/web3.js\";\nimport BigNumber from \"bignumber.js\";\n\n// USDC mint address\nconst USDC_MINT = new PublicKey(\"EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v\");\n\nconst sdk = new BrowserSDK({\n providers: [\"google\", \"apple\", \"injected\"],\n appId: \"your-app-id\",\n addressTypes: [AddressType.solana],\n});\n\nasync function createPaymentRequest(amount: BigNumber) {\n // Connect if not already connected\n if (!sdk.solana.isConnected()) {\n await sdk.connect({ provider: \"google\" });\n }\n\n // Get your wallet address from the SDK\n const recipientAddress = await sdk.solana.getPublicKey();\n const recipient = new PublicKey(recipientAddress);\n const reference = new PublicKey(Keypair.generate().publicKey);\n const label = \"Your Store\";\n const message = \"Thanks for your purchase!\";\n\n // Create the payment URL\n const url = encodeURL({\n recipient,\n amount,\n splToken: USDC_MINT,\n reference,\n label,\n message,\n });\n\n // Generate QR code\n const qr = createQR(url, 300, \"transparent\");\n return { url, qr, reference };\n}\n\n// Usage\nconst { url, qr, reference } = await createPaymentRequest(new BigNumber(10));\nqr.append(document.getElementById(\"qr-container\"));\nimport { PhantomProvider, useSolana, useAccounts, usePhantom, AddressType, darkTheme } from \"@phantom/react-native-sdk\";\nimport { encodeURL } from \"@solana/pay\";\nimport { PublicKey, Keypair } from \"@solana/web3.js\";\nimport { View, Text, StyleSheet, Linking } from \"react-native\";\nimport { useEffect, useState } from \"react\";\nimport BigNumber from \"bignumber.js\";\n\n// USDC mint address\nconst USDC_MINT = new PublicKey(\"EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v\");\n\nfunction App() {\n return (\n <PhantomProvider\n config={{\n providers: [\"google\", \"apple\"],\n appId: \"your-app-id\",\n scheme: \"yourapp\",\n addressTypes: [AddressType.solana],\n authOptions: {\n redirectUrl: \"yourapp://auth/callback\",\n },\n }}\n theme={darkTheme}\n appName=\"Your Store\"\n >\n <PaymentRequest />\n </PhantomProvider>\n );\n}\n\nfunction PaymentRequest() {\n const { solana } = useSolana();\n const addresses = useAccounts();\n const { isConnected } = usePhantom();\n const [paymentUrl, setPaymentUrl] = useState<string | null>(null);\n\n useEffect(() => {\n if (!isConnected || !addresses?.[0]) return;\n\n const recipient = new PublicKey(addresses[0].address);\n const amount = new BigNumber(10); // 10 USDC\n const reference = new PublicKey(Keypair.generate().publicKey);\n const label = \"Your Store\";\n const message = \"Thanks for your purchase!\";\n\n const url = encodeURL({\n recipient,\n amount,\n splToken: USDC_MINT,\n reference,\n label,\n message,\n });\n\n setPaymentUrl(url.toString());\n }, [isConnected, addresses]);\n\n if (!isConnected) {\n return (\n <View style={styles.container}>\n <Text>Please connect your wallet to generate a payment request</Text>\n </View>\n );\n }\n\n return (\n <View style={styles.container}>\n <Text style={styles.title}>Payment Request</Text>\n <Text>Your wallet: {addresses?.[0]?.address}</Text>\n {paymentUrl && (\n <Text\n style={styles.link}\n onPress={() => Linking.openURL(paymentUrl)}\n >\n Open Payment Link\n </Text>\n )}\n </View>\n );\n}\n\nconst styles = StyleSheet.create({\n container: {\n flex: 1,\n padding: 20,\n justifyContent: \"center\",\n },\n title: {\n fontSize: 24,\n fontWeight: \"bold\",\n marginBottom: 20,\n },\n link: {\n color: \"#0ea5e9\",\n marginTop: 20,\n textDecorationLine: \"underline\",\n },\n});\n\n​Install dependencies\nnpm install @solana/pay bignumber.js @phantom/react-sdk\n# or\nnpm install @solana/pay bignumber.js @phantom/browser-sdk\n\n​Verify payment\nAfter a user pays, verify the payment on your backend:\nimport { findReference, validateTransfer } from \"@solana/pay\";\nimport { Connection, PublicKey } from \"@solana/web3.js\";\nimport BigNumber from \"bignumber.js\";\n\nconst USDC_MINT = new PublicKey(\"EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v\");\n\nasync function verifyPayment(reference: PublicKey, recipient: PublicKey, amount: BigNumber) {\n const connection = new Connection(\"https://api.mainnet-beta.solana.com\");\n\n // Find the transaction\n const signatureInfo = await findReference(connection, reference);\n\n // Validate it matches our request\n await validateTransfer(connection, signatureInfo.signature, {\n recipient,\n amount,\n splToken: USDC_MINT,\n });\n\n return signatureInfo.signature;\n}\nWas this page helpful?","tokens":1618,"squid":"spider-10","role":"Tooling Spider","at":1791339095737,"hash":"02a0223b0371806a1a765f9e0a46b61ccf6a3094"}
{"url":"https://akash.network/pricing/gpus","domain":"akash.network","title":"GPU Pricing and Availability | Explore Pricing and Earnings on Akash","text":"GPU Pricing Real-time availability for high-demand compute. Transparent hourly pricing with no hidden fees. GPU modelStarting atB300288 GBSXM6$6.00/hrB200180 GBHBM3e$5.00/hrPro 6000 WE96 GBPCIe$1.44/hrPro 6000 SE96 GBPCIe$2.02/hrA10080 GBPCIe$1.33/hrA10080 GBSXM4$1.67/hrH10080 GBSXM5$2.72/hrV10032 GBPCIe$0.21/hrRTX 509032 GBPCIe$0.68/hrP4024 GBPCIe$0.08/hrRTX 309024 GBPCIe$0.17/hrRTX 600024 GBPCIe$0.22/hrRTX 3090 Ti24 GBPCIe$0.25/hrRTX 409024 GBPCIe$0.30/hrRTX 4000s Ada20 GBPCIe$0.14/hrRTX 4000 Ada20 GBPCIe$0.25/hrRTX 408016 GBPCIe$0.15/hrT416 GBPCIe$0.16/hrV10016 GBSXM2$0.26/hrRTX 306012 GBPCIe$0.14/hrP48 GBPCIe$0.03/hrM40008 GBPCIe$0.06/hrGTX 1070 Ti8 GBPCIe$0.14/hrRTX 3060 Ti8 GBPCIe$0.14/hrP20005 GBPCIe$0.36/hrGTX 10502 GBPCIe$0.14/hrPrices are per GPU-hour in USD, derived from recent provider bids on the network and weighted by each provider's GPU count. B200 and B300 are listed at fixed rates.Looking for Bulk Orders or Custom Configurations?Get in Touch","tokens":243,"squid":"spider-03","role":"Compute Spider","at":1791339116697,"hash":"9cb5c03dc3d237339dc8ebf64d41728d0eafdc24"}
{"url":"https://akash.network/community/welcome/","domain":"akash.network","title":"Community Welcome - Akash Network","text":"The Open Cloud CommunityAkash is built and governed by a global collective of engineers, creators, and operators. Whether you are here to build infrastructure, develop open-source tools, or influence protocol governance, this is the home of the open cloud.How do you want to build?Join the Club & Start BuildingThe Official Community HubShape the Supercloud with Akash ClubAkash Club is the official community hub where builders and $AKT enthusiasts collaborate to drive the network forward. Gain insider access to core development, earn rewards for participation, and build with conviction alongside the architects of the Supercloud.Learn: Weekly Sessions & TriviaMove beyond price speculation and master the fundamentals of decentralized infrastructure.🗓️Deep Dives into Akash Progress:Join deep dives into the technical roadmap and future protocol upgrades.🏅AMAs with Core Team Members:Test your ecosystem knowledge in live challenges to win $AKT rewards.💭Workshops using Akash:Move from passive learning to active contribution by collaborating on real network projects.Earn: The Community Reward StackHear directly from the people building the protocol.🌠Akash Club NFT:Mint a unique annual collectible that serves as a permanent record of your journey and contributions to the roadmap.🎟️Monthly $AKT Raffle:Our raffle is merit-based. You earn entries by attending events and actively participating, never by purchasing.Club Game Nights & Trivia🎮Network with our CommunityVisit our Akash Passage world hosted on Akash GPUs to meet others passionate about Akash.\"Bull market, bear market, it doesn't matter. 495 open-source contributors averaging 67 commits per week build Akash regardless of market conditions. Akash is the People's Supercloud and I'm credibly proud of the $AKT community.\"Greg OsuriFounder of AkashOverclock Labs CEOExplore Social ChannelsBe part of the Akash Network community. Connect, contribute, and collaborate to shape the future of decentralized cloud computing.DiscordGithubXLinkedInYoutubeTelegramRedditFrequently asked questionsThe Supercloud is waiting.Where will you start?Join the Akash ClubApply to InsidersNote: Technical contributions on GitHub are always open to everyone.However, access to paid content bounties and official training is reserved for the Insider program.","tokens":579,"squid":"spider-03","role":"Compute Spider","at":1791339139763,"hash":"6c659fbd9323876baa4c31e3dd697b1edd6879dd"}
{"url":"https://docs.switchboard.xyz/custom-feeds/advanced-feed-configuration/how-feeds-are-resolved","domain":"docs.switchboard.xyz","title":"How Feeds are Resolved | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.Task RunnerAll Switchboard Oracle Jobs are executed by the task-runner, an engine used by oracles to fetch data in a secure and efficient manner. Understanding how Oracle jobs are processed is essential before creating them. Oracle Jobs must define an array of tasks executed sequentially. Any task producing a value (String, JSON, or Decimal) will be assigned to the job's context for that particular run.The Task Runner Context can be interpreted as:// Context \n{\n current_value: string | JSON | Decimal,\n variable_cache: Map<string, string | JSON | Decimal>,\n}SchemasSwitchboard feeds are composed of Oracle Jobs, a schema designed for efficient and safe fetching of arbitrary numeric data from various sources. Oracle nodes run feeds by aggregating the results of jobs within a feed definition and computing a median.Feeds Schema{\n jobs: [\n // Oracle Job 1\n {\n tasks: [ ... ]\n },\n // Oracle Job 2\n {\n tasks: [ ... ]\n }\n ]\n}Oracle Jobs are composed of tasks. Tasks are like instructions to fetch data or compute certain outputs. There are several Task Types available, and they can be strung together to create some complex logic.Oracle Jobs Schema{\n tasks: [\n // task 1\n {\n ...\n },\n // task 2\n {\n ...\n }\n ]\n}Feed IdentityA feed ID is a commitment to canonical length-delimited protobuf bytes, not only to the decoded JSON object. Field presence and encoding order therefore matter, including explicitly set default values.Use @switchboard-xyz/common@5.8.5 or newer when serializing jobs and feeds, computing FeedHash, or storing definitions with Crossbar. Use @switchboard-xyz/on-demand@3.10.6 or newer when requesting JavaScript updates. These versions:encode job and feed identities in the Rust/prost-compatible declaration order;preserve Pyth-push fields and explicitly set optional defaults such as pushFeedShardId: 0 and directRoutesOnly: false; andkeep the canonical encoder isolated if another Common version is also loaded.Use the same canonical definition for hashing, storage, and update requests. For classic PullFeed accounts, the JavaScript update helpers reject any returned median-response feed hash that was not requested before constructing signature or submit instructions.Variable ExpansionUsing Variable Overrides and the CacheTask, users can assign variables in a job and use them within the same job in a downstream task.So in a downstream task, you can invoke the variable with the syntax: ${VARIABLE_NAME}.Here's an HttpTask where the URL is pulled from a variable:[\n // ... Cache Task or Secrets Task (or both) must come first ...\n {\n httpTask: {\n url: \"${MY_CONFIGURED_HTTP_URL}\"\n }\n },\n {\n jsonParseTask: {\n path: \"$.price\"\n }\n }\n]Internally, the variables are being string-replaced within the executed job definitions. This can be a good tool for deduplicating logic in complex jobs.ResolutionIn order for a task runner result to be valid, its current_value must be some numeric value. Intermediate calls may produce non-numeric values (like HttpTasks, JsonParseTasks, etc), but the final value will be the result of the job.PreviousREST APIs with HttpTaskNextBounding ResultsLast updated 2 months ago","tokens":806,"squid":"spider-08","role":"Oracle Spider","at":1791339144882,"hash":"8b9b2c4ef8ab313673dd993552e3db9050f8f4d5"}
{"url":"https://akash.network/development/welcome/","domain":"akash.network","title":"Akash Developer Portal - Developer Hub","text":"Akash Developer Portal \nAkash is open.So is the door.\n\nBuild on the open compute marketplace. Everything here, from the codebase to the governance, is owned by the builders who ship it.\n\nView on GitHub\n\nRead the Docs\n Tools \nThe builder's command center\n\nWhether you are shipping containers, serving inference, or powering the network, the Akash ecosystem provides the specialized tools to move at the speed of the open cloud.\n Professional-grade control Deploy clusters and ship containers in sixty seconds. No hidden abstractions. You have full control over every lease and bid. Launch Console Dedicated Inference Serve Llama, DeepSeek, and Qwen via OpenAI-compatible endpoints. Change one base_url to save 85% on production inference. Try AkashML Put your silicon to work Turn your idle GPUs into an income stream. Join the supply side and earn from a global marketplace of AI builders. Become a Provider Provide from home, no ops required Offer compute on Akash Network without needing to be a Kubernetes expert or an advanced Linux admin. Try Homenode Deploy with full self-custody Self-hostable, self-custody crypto wallet UI for deploying on Akash. View on GitHub Integrations \nYour stack. Global supply.\n\nIf it runs in a container, it runs on Akash. Build without lock-in or proprietary SDKs.\n Akash SDK Native wallet integration for custom automation. Deployment API Credit card enabled REST API for SaaS platforms. Node RPC Direct gRPC/REST access to raw protocol state. Explore Integrations Programs \nFuel for the builders\n Founders & Startups Founder-ready compute Your GPU bill shouldn't eat your seed round. Access H100s from $1.45/hr with zero sales calls or waitlists. Learn More Researchers & Academics Academic-grade silicon If the models are open, the compute must be too. Power your next breakthrough on the marketplace built for researchers. Learn More Developers & Contributors Fund your open-source tool We invest in the people who build the roads. Developing tools for the open cloud? We fund that. Learn More \nSee what's shipping next\n\nThe Akash roadmap is built in public. Track what's planned, monitor active progress, and start the conversation if you see a gap in the network.\n View Roadmap Community Syncs \nBuild in the open\n\nAkash is run by the people who build it. From persistent domain groups to mission-specific initiatives, our work happens in public meetings that anyone can join.\n SIG Special Interest Groups Focused, persistent groups working on specific features, products, and foundational tools. SIGs exist as long as the work does. \nLearn More WG Working Groups Large-scale initiatives that span multiple SIGs. They form around a mission and dissolve once the work ships. The work outlasts the group. \nLearn More SC Steering Committee Oversees the project list, resolves conflicts, and ensures the community keeps improving how it operates. \nLearn More Community Syncs Calendar Subscribe to Community Calendar Contribute \nThe world's compute belongs to the people who build it\n\nAkash is open source. Every repository is a road you can help build.\n Repositories Description akash-network/console The deployment dashboard. If you see something missing, build it. The deployment dashboard. If you see something missing, build it. \nView akash-network/website The digital home of the network. If you see something broken, fix it. The digital home of the network. If you see something broken, fix it. \nView akash-network/awesome-akash Curated templates, tools, and resources from the community. Curated templates, tools, and resources from the community. \nView View All on GitHub Ways to Get Involved Docs The network is only as good as its knowledge base. Help us keep it current. Providers Power the decentralized cloud with your hardware. Supply makes the marketplace real. Community Groups Join SIGs and Working Groups. Show up, listen, and find where you fit. Get Support Stuck on a deployment? The community has your back. GitHub Discussions Open conversations on protocol direction, tooling, and the future of the network. How to Contribute A guide to contributing code, content, and ideas to the Akash ecosystem. Code of Conduct The standards that keep the community open, respectful, and collaborative.","tokens":1062,"squid":"spider-03","role":"Compute Spider","at":1791339151996,"hash":"167080c8f375e2032cd4e40fb4d9e4650293476c"}
{"url":"https://docs.switchboard.xyz/custom-feeds/advanced-feed-configuration/oracle-aggregator","domain":"docs.switchboard.xyz","title":"Oracle Aggregator | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.PythThe Pyth Oracle Network publishes price feeds that the Oracle Aggregator task can read through Hermes or from an on-chain Solana push-feed account. The two paths have different authentication and freshness behavior.Hermes-backed feeds with pythAddressUse pythAddress for the Hermes-backed path. It accepts existing Pyth Solana price account addresses and Pyth price-feed IDs. For authenticated Hermes access, place an API-key placeholder in pythConfigs.apiKey:// SNX/USD with a 1.2% maximum confidence interval\n{\n oracleTask: {\n pythAddress: \"0x39d020f60982ed892abbcd4a06a276a9f9b7bfbce003204c110b6e488f502da3\",\n pythConfigs: {\n apiKey: \"${PYTH_API_KEY}\",\n pythAllowedConfidenceInterval: 1.2,\n maxStaleSeconds: 15,\n },\n },\n}Provide the key on the same execution request:const response = await gateway.fetchSignaturesConsensus({\n // ...feed request fields\n variableOverrides: {\n PYTH_API_KEY: process.env.PYTH_API_KEY!,\n },\n});For new feed definitions, prefer an explicit pythConfigs.apiKey placeholder. It makes the task's credential dependency visible and allows different Pyth tasks in one request to name different keys. After placeholder expansion, a non-empty task-level apiKey takes precedence.Existing pythAddress jobs do not need to be rewritten during the Pyth Core transition. When pythConfigs.apiKey is omitted or empty, the task accepts the reserved request override PYTH_API_KEY as a compatibility fallback. One fallback value covers every pythAddress task in that execution request that does not set its own apiKey; it does not apply to other requests or become an oracle-wide key. This preserves existing feed definitions while allowing the customer making the request to pay for its Hermes calls.The compatibility fallback assumes one execution request belongs to one customer or security domain. Do not combine unrelated customers' jobs and credentials in a single request.On-chain push feeds with pythPushFeedIdUse pythPushFeedId for an upgraded Solana push feed. This path derives and reads the on-chain price account; it does not call Hermes and does not use a Hermes API key.When authoring, storing, hashing, or updating a feed that uses this task, use @switchboard-xyz/common@5.8.5 and @switchboard-xyz/on-demand@3.10.6 or newer. The current Common serializer preserves the Pyth-push fields and explicitly set optional defaults in the canonical feed identity.{\n oracleTask: {\n pythPushFeedId: \"0xef0d8b6fda2ceba41da15d4095d1da392a0d2f8ed0c6c7bc0f4cfac8c280b56d\",\n pythConfigs: {\n pushFeedShardId: 0,\n maxStaleSeconds: 75,\n },\n },\n}pushFeedShardId defaults to 0. maxStaleSeconds defaults to 15 for pythAddress and 75 for pythPushFeedId. pythConfigs.hermesUrl can select a different Hermes endpoint for pythAddress. Use the nested pythConfigs.pythAllowedConfidenceInterval field for confidence limits; values are percentages, so 10 means 10%. The top-level pythAllowedConfidenceInterval field is retained only for compatibility.See Data Feed Variable Overrides for the request trust model, Jupiter API keys for its conventional placeholder behavior, and the OracleTask reference for every field.ChainlinkThe Chainlink Oracle Network provides 145 data feeds at the time of writing on the Arbitrum L2 Mainnet. Check out the available feed addresses here.// AAVE/USD Task with accepted confidence interval of 1.2%\n{\n oracleTask: {\n chainlinkAddress: \"0x3c6AbdA21358c15601A3175D8dd66D0c572cc904\"\n },\n}Switchboard V2Switchboard V2 (Solana Push) feeds can be referenced within on-demand feeds. It's simple, all you need is an Aggregator public key, which you can find on the V2 Explorer App.Here's an example of a Switchboard Oracle Task for the price of BTC/USD:// BTC/USD Task\n{\n oracleTask: {\n switchboardAddress: \"8SXvChNYFhRq4EZuZvnhjrB3jJRQCv4k3P4W6hesH3Ee\",\n }\n}PreviousDecentralized ExchangesNextTime-Weighted Average PricesLast updated 2 months ago","tokens":992,"squid":"spider-08","role":"Oracle Spider","at":1791339155121,"hash":"75f5acc215550e7b1603900c64f32e0620c839dd"}
{"url":"https://akash.network/development/community-groups/","domain":"akash.network","title":"Community Syncs - Developer Hub","text":"Community Syncs \nCommunity Syncs\n\nAkash community groups (CGs) provide a structured framework for transparent collaboration. Modeled after the Kubernetes project, these groups are where the protocol is built, debated, and governed in public.\n sig-analyticsAnalytics Special Interest GroupAnalytics Special Interest Group is dedicated to defining and building tools that allow data analytics for deployments, providers, chain metrics, etc.View Group DetailsSchedule: Quarterly, on the second Thursday of each quarter · Thursday 9am-10am pacific timeAdd to Calendarsig-chainChain Special Interest GroupChain Special Interest Group.View Group DetailsSchedule: First Tuesday of each Month · Tuesday 9am-10am pacific timeAdd to Calendarsig-clientsClients Special Interest GroupAkash Network Clients are software and services that make it easier for tenants of all types to deploy on to Akash Providers as well as for new provider onboarding. The Akash Network community has built and supports the following deployment & provider onboarding clients at this timeView Group DetailsSchedule: Every Third Wednesday of the Month · Wednesday 10:30am pacific timeAdd to Calendarsig-communityCommunity Special Interest GroupThis SIG (Special Interest Group) is designed for Akash community members to propose community initiatives, programs or content that can be reviewed and potentially supported through the Akash community fund.View Group DetailsSchedule: Monthly on the second Tuesday · Tuesday 11am-12am pacific timeAdd to Calendarsig-deploymentsDeployments Special Interest Group Akash Network - Deployments Special Interest Group (SIG)View Group DetailsSchedule: Calendar · Subscribe to calendarAdd to Calendarsig-designDesign Special Interest GroupDesign Special Interest Group is dedicated to defining and building a design for all things Akash.View Group DetailsSchedule: Bi-monthly, on the second Wednesday of each month · Wednesday 8am-9am pacific timeAdd to Calendarsig-documentationDocumentation Special Interest GroupThe goal of this SIG is to foster a community around the creation and maintenance of top-tier documentation to facilitate the growth of Akash Network.View Group DetailsSchedule: Quarterly, on the 4th Tuesday of each quarter · Tuesday 7am pacific timeAdd to Calendarsig-economicsEconomics Special Interest GroupThe goal of this SIG is to ensure that AKT, the utility token of Akash Network, is used in ways to incentivize long-term, sustainable growth of the network. This can include but is not limited to incentivizing engineering development, provider onboarding, community efforts, and security budget.View Group DetailsSchedule: First Wednesday of the Month · Wednesday 10am-11am pacific timeAdd to Calendarsig-educationEducationThis SIG (Special Interest Group) is focused on all efforts related to educating users about all things Akash. Sig-education is tasked with finding subjects for educational content, as well as creating a wide range of content to be distributed to the Akash community.View Group DetailsSchedule: Second Tuesday of the month · Tuesday 10am pacific timeAdd to Calendarsig-providersProviders Special Interest GroupProvider SIG covers everything pertinent to Providers on Akash Network. This includes provider core software features, bug fixes, releases, monitoring, profitability calculation, content moderation, inventory and sourcing, partnerships/ integrations, analytics and more.View Group DetailsSchedule: 4th Wednesday of every month · Wednesday 8am pacific timeAdd to Calendarsig-supportSupport Special Interest Groupsig-support is responsible for defining mechanics of how support works at Akash Network, as well as organizing a distributed support team across the world. The Support Special Interest group meets biweekly to discuss open issues in the Support Repo. If time permits, the group discusses issues related to the Akash Console which can be found the Console Repo.View Group DetailsSchedule: Every other Wednesday · Wednesday 7am-8am pacific timeAdd to Calendar","tokens":1007,"squid":"spider-03","role":"Compute Spider","at":1791339162245,"hash":"033b37a1ad0f77b09abaaa6237ffa85248c0ea3f"}
{"url":"https://docs.switchboard.xyz/tooling/crossbar","domain":"docs.switchboard.xyz","title":"Crossbar | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.Crossbar: Switchboard's Utility ServerCrossbar is a high-performance utility server implemented in Rust, designed to simplify interactions with the Switchboard network. It provides essential functionalities for simulating and resolving feeds across various blockchains. Crossbar comes with a set of useful utility functions for resolving feeds on all chains with active Switchboard deployments, IPFS utilities for storing and fetching jobs, and built-in simulation capabilities for constantly fetching feed updates for liquidators and other bots.Note: The Rust version includes built-in simulation and no longer requires a separate Task Runner Simulator service.Running your own instance of Crossbar is highly recommended for user interfaces and bots that require frequent price simulations.Refer to Run Crossbar with Docker Compose for instructions on setting up your own Crossbar instance.Key FeaturesCrossbar aims to streamline the Switchboard experience, offering the following core functionalities:Fetch Feeds by Feed Hash: Retrieve a feed's job definitions and queue in JSON format using its unique feed hash (content identifier).Store Jobs: Store feed definitions using your configured IPFS node (requires Piñata credentials or a Kubo node).Simulate Feeds by Feed Hash: Simulate multiple feeds simultaneously using their feed hashes, enabling off-chain tracking of custom price feeds for bot automation.Crossbar exposes both simulation and signed-update paths. Simulation can succeed even when signed updates fail oracle-side validation. For validation units such as raw v2 maxJobRangePct and gateway max_variance, see Feed Parameter Units.For current Solana/SVM feed-hash integrations, use the SDK managed update path (queue.fetchManagedUpdateIxs(...)) and canonical quote-program accounts. The classic PullFeed.fetchUpdateIx(...) and /updates/solana/... flows are legacy PullFeed compatibility paths and require queue/gateway support for that account scheme.Blockchain-Specific FeaturesCrossbar provides tailored features for specific blockchains:Solana and Aptos/Sui:Fetch Encoded Update Instructions: Retrieve update instructions from live oracles. For Solana/SVM feed-hash integrations, prefer managed quote-program updates through the SDK; Crossbar's classic Solana update routes are for legacy PullFeed accounts.Fetch Simulated Results for Feeds: Fetch current prices for feeds. This is a useful feature for tracking custom price feeds off-chain, for triggering an action that the bots can use.Ethereum Virtual Machine (EVM):Fetch Encoded Updates: Obtain an encoded update for a feed to submit on-chain via a contract explorer (like Etherscan), eliminating the need to include feed definitions directly in your frontend.Settle Randomness: Fetch a settlement message for resolving randomness requests when using Switchboard's EVM Randomness features.Rust Implementation BenefitsThe Rust implementation provides several advantages:High Performance: Built with actix-web for maximum throughputBuilt-in Simulation: No separate Task Runner Simulator requiredWebSocket Support: Real-time data streaming capabilitiesMemory Efficiency: Optimized for high concurrent connectionsSimplified Deployment: Single binary with minimal dependenciesEnvironment VariablesAll environment variables are optional and have sensible defaults:Core Configuration:PORT (default: 8080) - HTTP server portWS_PORT (default: 8081) - WebSocket server portDISABLE_API (default: false) - Disable HTTP API entirelyPerformance:BROADCAST_WORKER_THREADS (default: 32) - Tokio worker threadsSIMULATION_CACHE_TTL_SECONDS (default: 3) - Cache TTLDISABLE_CACHE (default: false) - Disable cachingBlockchain RPCs (Recommended):SOLANA_MAINNET_RPC - Solana mainnet RPCSOLANA_DEVNET_RPC - Solana devnet RPCIPFS (Optional):IPFS_GATEWAY_URL (default: https://ipfs.io) - IPFS gatewayPINATA_JWT_KEY - Pinata storage keyKUBO_URL - Local IPFS nodeFor a complete list of environment variables, see the Docker Compose guide.Public Instance of CrossbarWhile a public instance is available for quick testing, running your own Crossbar instance is highly recommended. Switchboard oracles are heavily rate-limited by IP address, so using a dedicated instance prevents disruptions.Public Instance: https://crossbar.switchboard.xyzPublic Rate Limits (as of March 3, 2026)The public Crossbar endpoint has multiple limit layers. The key limits to plan around are:Network-level oracle request budget: default 20 RPS per user wallet for Switchboard requests; higher limits are available with svSWTCH stake. See The Switchboard NCN.Public edge throttling: https://crossbar.switchboard.xyz enforces additional IP-based throttling and can return 429 Too Many Requests under burst traffic (especially for /updates/* routes).Surge connection caps: managed Surge subscriptions have explicit connection limits by plan (Plug: 1, Pro: 10, Enterprise: 15). See Surge pricing and limits.Practical guidance:Treat public Crossbar as best-effort for development and low-volume usage.Back off exponentially with jitter on 429 responses.For production bots/frontends, self-host Crossbar to remove public edge contention.Examples:Job Definition Fetch: https://crossbar.switchboard.xyz/fetch/2718f49aa8fb6b71452ef149fa654a06d3996113034c27e2dca5c71b4a2866e7EVM Oracle Fetch (Core Mainnet): https://crossbar.switchboard.xyz/updates/evm/1116/0xfd2b067707a96e5b67a7500e56706a39193f956a02e9c0a744bf212b19c7246cAdvancedCrossbar API Endpoints — complete endpoint reference by route group.Surge Gateway Protocol — HTTP + WebSocket protocol for custom Surge clients.PreviousNode ArchitectureNextRun Crossbar with Docker ComposeLast updated 3 months ago","tokens":1442,"squid":"spider-08","role":"Oracle Spider","at":1791339165117,"hash":"fb65ec35aa0245058c087f124d02d3bddb13473b"}
{"url":"https://docs.switchboard.xyz/tooling/crossbar/gateway-protocol","domain":"docs.switchboard.xyz","title":"Surge Gateway Protocol | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.Surge provides low-latency price streaming via the Crossbar gateway. This page documents the HTTP + WebSocket protocol for clients that cannot use the SDK or need custom integrations.When to use this protocolYou are implementing a non-JS client (Rust/Go/Python/etc.).You are running custom infrastructure and need direct gateway control.You are debugging auth/session issues or connection failures.You are building a load-testing or monitoring client.PrerequisitesBefore calling request_stream, the Solana pubkey you authenticate with must have an active on-chain Surge subscription.Subscriptions are managed on Solana and paid in SWTCH tokens (except free-tier cases where payment can be zero, but subscription initialization is still required).If there is no active subscription for your pubkey, POST /gateway/api/v1/request_stream will fail even when signatures, blockhash, and timestamps are valid.Subscription setup guide: Surge Subscription Guide.Explorer subscription UI: explorer.switchboardlabs.xyz/subscriptions.Protocol OverviewDiscover a gateway endpoint.Create signature headers.Request a streaming session.Open the WebSocket with auth headers.Send a Subscribe message.Receive bundled price updates.Respond to keepalive pings.1. Gateway discoveryMainnet:GET https://crossbar.switchboard.xyz/gateways?network=mainnetDevnet:GET https://crossbar.switchboard.xyz/gateways?network=devnetThe response returns one or more gateway base URLs. Choose one and use it for the session request.2. Signature headersFor every HTTP and WebSocket request, you must include signature headers derived from a recent Solana blockhash and current timestamp.Message to signSHA256(\"{blockhash}:{timestamp}\")Sign the hash with Ed25519 using your Solana keypair.Required headersX-Switchboard-Signature — Ed25519 signature of the hashX-Switchboard-Pubkey — Solana public keyX-Switchboard-Blockhash — recent Solana blockhashX-Switchboard-Timestamp — current timestampNotes:Use a fresh blockhash and timestamp for each request.Keep client time in sync (clock skew can cause auth failures).3. Session requestPOST {gateway}/gateway/api/v1/request_streamInclude the signature headers. The response contains:session_tokenoracle_ws_url4. WebSocket connectionOpen a WebSocket connection to oracle_ws_url with:Authorization: Bearer {pubkey}:{session_token}The same signature headers (X-Switchboard-*)5. Subscribe messageSend a Subscribe message after connecting:{\n \"type\": \"Subscribe\",\n \"feed_bundles\": [\n {\n \"feeds\": [\n {\n \"symbol\": { \"base\": \"BTC\", \"quote\": \"USD\" },\n \"source\": \"AUTO\"\n }\n ]\n }\n ],\n \"signature_scheme\": \"Ed25519\",\n \"pubkey\": \"<your-solana-pubkey>\",\n \"signature\": \"<ed25519-signature>\",\n \"blockhash\": \"<recent-solana-blockhash>\",\n \"timestamp\": \"<current-timestamp>\"\n}6. Price updatesThe gateway sends BundledFeedUpdate messages. Each update includes feed_values[] entries. The value field is an 18-decimal big-integer string (no decimal point). Convert it to a decimal value by dividing by 1e18 (e.g., \\\"67335320000000000000000\\\" → 67335.32).If you're using the SDK, helpers like getFormattedPrices() already apply this scaling for you. Only raw consumers need to handle the 1e18 divisor.7. KeepaliveThe gateway may send a SignedPing. Respond with a SignedPong that includes a fresh signature (new blockhash + timestamp):{\n \"type\": \"SignedPong\",\n \"signature_scheme\": \"Ed25519\",\n \"pubkey\": \"<your-solana-pubkey>\",\n \"signature\": \"<ed25519-signature>\",\n \"blockhash\": \"<recent-solana-blockhash>\",\n \"timestamp\": \"<current-timestamp>\"\n}Error handling and reconnectsCommon causes of disconnects or auth errors:Invalid signatureExpired timestampStale blockhashInvalid or expired session tokenOn failure, request a new session and reconnect with fresh signatures.PreviousCrossbar API EndpointsNextCLILast updated 7 months ago","tokens":975,"squid":"spider-08","role":"Oracle Spider","at":1791339175069,"hash":"5115eaabfd739b55a95f9b1e220c6b3403284646"}
{"url":"https://docs.switchboard.xyz/tooling/crossbar/run-crossbar-with-docker-compose","domain":"docs.switchboard.xyz","title":"Run Crossbar with Docker Compose | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.OverviewCrossbar can be run pretty easily with Docker. The instructions below will walk you through running Crossbar in Docker containers using Docker Compose.Crossbar Rust ImplementationThe current version of Crossbar is implemented in Rust and includes built-in simulation capabilities, eliminating the need for a separate Task Runner Simulator service. This provides better performance and simplified deployment.PrerequisitesBefore running crossbar, ensure you have the followingDocker and Docker Compose installed on your machine.A custom Solana RPC for improved performance (optional - strongly recommended)Pinata or another IPFS node for job storage (optional)Step 1: Set Up Your Project DirectoryCreate a Project Directory: Create a directory for your project. This directory will contain all the necessary files for your Docker container deployment.mkdir my-crossbar-project cd my-crossbar-projectStep 2: Create the docker-compose.yml FileCreate a docker-compose.yml File: In your project directory, create a file named docker-compose.yml. This file will define the Docker services and environment variables.Platform Compatibility Note: The Crossbar Docker image is built for linux/amd64 (x86/Intel architecture). If you're running on Apple Silicon (M1, M2, M3, M4 Macs) or other ARM-based systems, add the platform: linux/amd64 line under the service definition. Docker Desktop will use Rosetta 2 or QEMU to emulate the x86 architecture. For best performance on Apple Silicon, ensure \"Use Rosetta for x86/amd64 emulation\" is enabled in Docker Desktop settings.version: '3.8'\n\nservices:\n crossbar:\n image: switchboardlabs/rust-crossbar:stable\n # Uncomment the following line if running on Apple Silicon (M1/M2/M3/M4) or other ARM systems:\n # platform: linux/amd64\n ports:\n - \"8080:8080\" # HTTP API\n - \"8081:8081\" # WebSocket\n environment:\n # === Core Configuration ===\n PORT: ${PORT:-8080}\n WS_PORT: ${WS_PORT:-8081}\n\n # === Blockchain RPCs (Optional - Recommended) ===\n SOLANA_MAINNET_RPC: ${SOLANA_MAINNET_RPC:-https://api.mainnet-beta.solana.com}\n SOLANA_DEVNET_RPC: ${SOLANA_DEVNET_RPC:-https://api.devnet.solana.com}\n\n # === IPFS Configuration (Optional) ===\n IPFS_GATEWAY_URL: ${IPFS_GATEWAY_URL:-https://ipfs.io}\n\n # === Performance (Optional) ===\n BROADCAST_WORKER_THREADS: ${BROADCAST_WORKER_THREADS:-32}\n RUST_LOG: ${RUST_LOG:-info}Step 3: Create the .env FileCreate a .env File: In the same directory, create a .env file to store your environment variables. This file is read by docker compose and will override the default values in the compose file if specified.# .env file\n# All environment variables are optional and have sensible defaults\n\n# Recommended for better performance\nSOLANA_MAINNET_RPC=https://api.mainnet-beta.solana.com\nSOLANA_DEVNET_RPC=https://api.devnet.solana.com\n\n# Optional IPFS configuration\n# PINATA_JWT_KEY=\"your-pinata-jwt-key\"\n# PINATA_GATEWAY_KEY=\"your-pinata-gateway-key\"\n# IPFS_GATEWAY_URL=\"https://ipfs.io\"Step 4: Build and Run the Docker ContainerBuild and Run the Docker Container: Navigate to your project directory and run the following command to start your Docker container:docker-compose up -dThis command will start the container in detached mode. The -d flag stands for \"detached,\" meaning the container runs in the background.Step 5: Verify the DeploymentVerify the Deployment: Once the container is running, you can verify that the service is up and running by accessing it at http://localhost:8080. You can also check the status of the container by running:docker-compose psThis command will show the status of the running services.Step 6: Stopping and Restarting the Docker ContainerStop the Docker Container: To stop the container, run:docker-compose downThis command will stop and remove the containers defined in your docker-compose.yml file.Restart the Docker Container: To restart the container, run:docker-compose up -dAdditional TipsLogs: To view the logs of the running container, use the following command:docker-compose logs -fUpdating Environment Variables: If you need to update the environment variables, edit the .env file and restart the container:docker-compose down docker-compose up -dEnvironment Variables ReferenceCore Server ConfigurationVariableTypeDefaultDescriptionPORTOptional8080HTTP server portWS_PORTOptional8081WebSocket server portDISABLE_APIOptionalfalseSet to \"true\" to disable HTTP APIBlockchain RPC ConfigurationVariableTypeDefaultDescriptionSOLANA_MAINNET_RPCOptionalhttps://api.mainnet-beta.solana.comSolana mainnet RPC endpointSOLANA_DEVNET_RPCOptionalhttps://api.devnet.solana.comSolana devnet RPC endpointIPFS ConfigurationVariableTypeDefaultDescriptionIPFS_GATEWAY_URLOptionalhttps://ipfs.ioIPFS gateway for fetching dataPINATA_JWT_KEYOptional-Pinata JWT key for storagePINATA_GATEWAY_KEYOptional-Pinata gateway keyKUBO_URLOptional-Local Kubo IPFS node URLDatabase Configuration (Optional)VariableTypeDefaultDescriptionDATABASE_URLOptional-PostgreSQL connection stringPGUSEROptional-PostgreSQL usernamePGPASSWORDOptional-PostgreSQL passwordPGDATABASEOptional-PostgreSQL database namePGHOSTOptional-PostgreSQL hostPGPORTOptional-PostgreSQL portPerformance & CachingVariableTypeDefaultDescriptionBROADCAST_WORKER_THREADSOptional32Number of Tokio worker threadsSIMULATION_CACHE_TTL_SECONDSOptional3Cache TTL for simulationsDISABLE_CACHEOptionalfalseDisable caching entirelyRATE_LIMITOptional-Rate limiting configurationDevelopment & DebuggingVariableTypeDefaultDescriptionRUST_LOGOptionalinfoLog level (error, warn, info, debug, trace)TOKIO_CONSOLEOptionalfalseEnable tokio console debuggingTOKIO_CONSOLE_PORTOptional6669Port for tokio consoleIS_LOCALHOSTOptionalfalseDevelopment mode flagTesting it out:Try the deployment out by navigating to (can take a few seconds the first run): http://localhost:8080/updates/evm/1116/0xfd2b067707a96e5b67a7500e56706a39193f956a02e9c0a744bf212b19c7246cThe equivalent result should look something like the output from the public node: https://crossbar.switchboard.xyz/updates/evm/1116/0xfd2b067707a96e5b67a7500e56706a39193f956a02e9c0a744bf212b19c7246cPreviousCrossbarNextCrossbar API EndpointsLast updated 5 months ago","tokens":1562,"squid":"spider-08","role":"Oracle Spider","at":1791339185186,"hash":"9141440e547b9385d4e5d9d06ca49dfe39fb293d"}
{"url":"https://eips.ethereum.org/EIPS/eip-5","domain":"eips.ethereum.org","title":"EIP-5: Gas Usage for `RETURN` and `CALL*`","text":"🎉 Final\n\n Standards Track: Core\n\n EIP-5: Gas Usage for `RETURN` and `CALL*`\n\n Authors\n Christian Reitwiessner <c@ethdev.com>\n\n Created\n 2015-11-22\n\n Abstract\n\nThis EIP makes it possible to call functions that return strings and other dynamically-sized arrays.\nCurrently, when another contract / function is called from inside the Ethereum Virtual Machine,\nthe size of the output has to be specified in advance. It is of course possible to give a larger\nsize, but gas also has to be paid for memory that is not written to, which makes returning\ndynamically-sized data both costly and inflexible to the extent that it is actually unusable.\n\nThe solution proposed in this EIP is to charge gas only for memory that is actually written to at\nthe time the CALL returns.\n\n Specification\n\nThe gas and memory semantics for CALL, CALLCODE and DELEGATECALL (called later as CALL*)\nare changed in the following way (CREATE does not write to memory and is thus unaffected):\n\nSuppose the arguments to CALL* are gas, address, value, input_start, input_size, output_start, output_size,\nthen, at the beginning of the opcode, gas for growing memory is only charged for input_start + input_size, but not\nfor output_start + output_size.\n\nIf the called contract returns data of size n, the memory of the calling contract is grown to\noutput_start + min(output_size, n) (and the calling contract is charged gas for that) and the\noutput is written to the area [output_start, output_start + min(n, output_size)).\n\nThe calling contract can run out of gas both at the beginning of the opcode and at the end\nof the opcode.\n\nAfter the call, the MSIZE opcode should return the size the memory was actually grown to.\n\n Motivation\n\nIn general, it is good practice to reserve a certain memory area for the output of a call,\nbecause letting a subroutine write to arbitrary areas in memory might be dangerous. On the\nother hand, it is often hard to know the output size of a call prior to performing the call:\nThe data could be in the storage of another contract which is generally inaccessible and\ndetermining its size would require another call to that contract.\n\nFurthermore, charging gas for areas of memory that are not actually written to is unnecessary.\n\nThis proposal tries to solve both problems: A caller can choose to provide a gigantic area of\nmemory at the end of their memory area. The callee can “write” to it by returning and the\ncaller is only charged for the memory area that is actually written.\n\nThis makes it possible to return dynamic data like strings and dynamically-sized arrays\nin a very flexible way. It is even possible to determine the size of the returned data:\nIf the caller uses output_start = MSIZE and output_size = 2**256-1, the area of\nmemory that was actually written to is (output_start, MSIZE) (here, MSIZE as evaluated\nafter the call). This is important because it allows “proxy” contracts\nwhich call other contracts whose interface they do not know and just return their output,\ni.e. they both forward the input and the output. For this, it is important that the caller\n(1) does not need to know the size of the output in advance and (2) can determine the\nsize of the output after the call.\n\n Rationale\n\nThis way of dealing with the problem requires a minimal change to the Ethereum Virtual Machine.\nOther means of achieving a similar goal would have changed the opcodes themselves or\nthe number of their arguments. Another possibility would have been to only change the\ngas mechanics if output_size is equal to 2**256-1. Since the main difficulty in the\nimplementation is that memory has to be enlarged at two points in the code around CALL,\nthis would not have been a simplification.\n\nAt an earlier stage, it was proposed to also add the size of the returned data on the stack,\nbut the MSIZE mechanism described above should be sufficient and is much better\nbackwards compatible.\n\nSome comments are available at https://github.com/ethereum/EIPs/issues/8\n\n Backwards Compatibility\n\nThis proposal changes the semantics of contracts because contracts can access the gas counter\nand the size of memory.\n\nOn the other hand, it is unlikely that existing contracts will suffer from this change due to\nthe following reasons:\n\nGas:\n\nThe VM will not charge more gas than before. Usually, contracts are written in a way such\nthat their semantics do not change if they use up less gas. If more gas were used, contracts\nmight go out-of-gas if they perform a tight estimation for gas needed by sub-calls. Here,\ncontracts might only return more gas to their callers.\n\nMemory size:\n\nThe MSIZE opcode is typically used to allocate memory at a previously unused spot.\nThe change in semantics affects existing contracts in two ways:\n\n Overlaps in allocated memory. By using CALL, a contract might have wanted to allocate\na certain slice of memory, even if that is not written to by the called contract.\nSubsequent uses of MSIZE to allocate memory might overlap with this slice that is\nnow smaller than before the change. It is, though, unlikely that such contracts exist.\n\n Memory addresses change. Rather general, if memory is allocated using MSIZE, the\naddresses of objects in memory will be different after the change. Contracts should\nall be written in a way, though, such that objects in memory are relocatable,\ni.e. their absolute position in memory and their relative position to other\nobjects does not matter. This is of course not the case for arrays, but they\nare allocated in a single allocation and not with an intermediate CALL.\n\n Implementation\n\nVM implementers should take care not to grow the memory until the end of the call and after a check that sufficient\ngas is still available. Typical uses of the EIP include “reserving” 2**256-1 bytes of memory for the output.\n\nPython implementation:\n\nold: http://vitalik.ca/files/old.py\n new: http://vitalik.ca/files/new.py\n\n Citation\n Please cite this document as:\n\n Christian Reitwiessner <c@ethdev.com>, \"EIP-5: Gas Usage for `RETURN` and `CALL*`,\" Ethereum Improvement Proposals, no. 5, November 2015. Available: https://eips.ethereum.org/EIPS/eip-5.","tokens":1526,"squid":"spider-05","role":"Spec Spider","at":1791339189379,"hash":"fbf35291f7bbdcabb7fbb5f56884ece0a5a06ff0"}
{"url":"https://docs.across.to/ai-agents/agent-examples","domain":"docs.across.to","title":"Agent Workflows | Across Docs","text":"Agent WorkflowsEnd-to-end examples showing real AI agent sessions performing crosschain tasks with the Across Protocol.Walk through complete agent workflows — from the user's prompt to the final result. Each example shows every step the agent takes, the API calls it makes, and the data it works with.\nExample 1: Bridge USDC Across Chains\nUser prompt:\nBridge 100 USDC from Arbitrum to Base\nDiscover supported chainsThe agent calls the chains endpoint to confirm Arbitrum and Base are supported and to get their chain IDs.GET https://app.across.to/api/swap/chainsThe agent finds:\nArbitrum — chain ID 42161\nBase — chain ID 8453\nLook up token addressesThe agent fetches the token list for both chains to find the USDC contract addresses.GET https://app.across.to/api/swap/tokens?chainId=42161\nGET https://app.across.to/api/swap/tokens?chainId=8453The agent finds:\nUSDC on Arbitrum: 0xaf88d065e77c8cC2239327C5EDb3A432268e5831 (6 decimals)\nUSDC on Base: 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913 (6 decimals)\nGet a quoteThe agent formats the amount (100 USDC = 100000000 with 6 decimals) and requests a quote.GET https://app.across.to/api/swap/approval\n ?originChainId=42161\n &destinationChainId=8453\n &inputToken=0xaf88d065e77c8cC2239327C5EDb3A432268e5831\n &outputToken=0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913\n &amount=100000000\n &depositor=0xUserWallet\n &tradeType=minOutputThe response includes:\nexpectedFillTime: 2 seconds\nsimulationSuccess: true\napprovalTxns: 1 approval needed (first time only)\nswapTx: the bridge transaction calldata\nExecute token approvalThe quote includes an approval transaction because this is the first time bridging USDC through this SpokePool. The agent sends it.Transaction: Approve SpokePool to spend USDC\nHash: 0xabc123...\nStatus: ConfirmedOn subsequent bridges, this step is skipped — the approval persists.Execute the bridgeThe agent sends the main swap transaction using the calldata from the quote.Transaction: Deposit 100 USDC into Arbitrum SpokePool\nHash: 0xdef456...\nStatus: Confirmed in block 284719304The agent reports back:\nBridged 100 USDC from Arbitrum to Base. Expected fill time: ~2 seconds.\nTx: https://arbiscan.io/tx/0xdef456...\nTrack the depositThe agent polls the status endpoint until the deposit is filled.GET https://app.across.to/api/deposit/status\n ?originChainId=42161\n &depositTxHash=0xdef456...After ~2 seconds:{\n \"status\": \"filled\",\n \"fillTxHash\": \"0x789abc...\",\n \"destinationChainId\": 8453\n}The agent confirms: Transfer complete. 100 USDC arrived on Base.\nTry it yourself. Give your agent this prompt:Bridge 100 USDC from Arbitrum to BaseWith the Across skill installed, the agent handles the entire flow autonomously.\n\nExample 2: Bridge + DeFi Deposit\nUser prompt:\nBridge 100 USDC from Arbitrum to Ethereum, swap to ETH, and deposit into Aave\nDiscover chains and tokensThe agent resolves chain IDs and token addresses, same as Example 1.\nArbitrum (42161) — USDC: 0xaf88d065e77c8cC2239327C5EDb3A432268e5831\nEthereum (1) — WETH: 0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2\nThe agent identifies this as a cross-token bridge (USDC to WETH) with an embedded action.Build the embedded actionThe agent constructs an Aave deposit action targeting the WETH Gateway on Ethereum.embedded action{\n \"target\": \"0x893411580e590D62dDBca8a703d61Cc4A8c7b2b9\",\n \"functionSignature\": \"function depositETH(address, address onBehalfOf, uint16 referralCode)\",\n \"args\": [\n { \"value\": \"0x0000000000000000000000000000000000000000\", \"populateDynamically\": false },\n { \"value\": \"0xUserWallet\", \"populateDynamically\": false },\n { \"value\": \"0\", \"populateDynamically\": false }\n ],\n \"value\": \"0\",\n \"isNativeTransfer\": false,\n \"populateCallValueDynamically\": true\n}The key: populateCallValueDynamically: true tells the MulticallHandler to forward the entire ETH balance from the swap as msg.value to the Aave deposit.Get a quote with actionsThe agent uses POST /swap/approval with the actions array in the body and sets recipient to the MulticallHandler contract.POST https://app.across.to/api/swap/approval\n ?originChainId=42161\n &destinationChainId=1\n &inputToken=0xaf88d065e77c8cC2239327C5EDb3A432268e5831\n &outputToken=0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2\n &amount=100000000\n &depositor=0xUserWallet\n &recipient=0x924a9f036260DdD5808007E1AA95f08eD08aA569\n &tradeType=exactInput\n\nBody: { \"actions\": [<embedded action>] }The response confirms simulationSuccess: true — the full flow (bridge + swap + Aave deposit) has been simulated successfully.Execute approvals and bridgeThe agent sends any required approval transactions, then the main swap transaction.Transaction: Deposit USDC into Arbitrum SpokePool (with embedded Aave action)\nHash: 0xfed987...\nStatus: ConfirmedWhat happens next (handled by the protocol):\nA relayer fills the intent on Ethereum, delivering ETH to the MulticallHandler\nThe MulticallHandler executes the Aave depositETH() call\nAave mints aWETH tokens to the user's address\nConfirm the resultThe agent tracks the deposit and confirms the full flow completed.\nBridge + Aave deposit complete. 100 USDC on Arbitrum has been converted to an aWETH lending position on Ethereum.\nDeposit tx: https://arbiscan.io/tx/0xfed987...\nExpected fill: ~2 seconds.\n\nTry it yourself. Give your agent this prompt:Bridge 100 USDC from Arbitrum to Ethereum, swap to ETH, and deposit into AaveThis uses embedded crosschain actions to compose bridge + DeFi in a single user transaction.\n\nMore Resources\nIntegrate Swap APIFull developer guide for the 5-step bridge flow used in Example 1.Crosschain Aave DepositComplete code walkthrough for the bridge + Aave pattern in Example 2.Prompt LibraryMore prompts organized by task category.Prompt LibraryCurated prompts for AI agents working with the Across Protocol — organized by task category.","tokens":1444,"squid":"spider-09","role":"Bridge Spider","at":1791339189413,"hash":"664de1845864355b9dbad7ece5dfd7fedd0713ac"}
{"url":"https://docs.switchboard.xyz/miscellaneous/glossary","domain":"docs.switchboard.xyz","title":"Glossary | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.TermDefinitionProsConsOraclesA blockchain primitive for propagating real-world data on-chain to be used in the context of decentralised applications. Often used in DeFi to price assets where liquidity is fractured between on-chain and off-chain sources.N/AN/APush OraclesBroadly used oracles that consistently watch for price movements of curated assets and pushes the responses on-chain.- No user involvement to propagate prices.- High cost of constant updates for all transactions, regardless of usage patterns.<br>- Cost fluctuations can lead to stale data if protocols aren't willing to pay.Pull OraclesGaining popularity since 2022, pull oracles use their own data layer to stream data paired with signatures from oracles verifying this data. Protocol users then bring this data on chain themselves when needed.Much cheaper as prices are only posted when the oracle is in use.\n— Lower fees, meaning more freshness and lower staleness.User behaviours relating to data submission may alter user behaviours, which may break certain assumptions made in protocols' design decisions.Secure EnclavesSecure Enclaves, or TEEs (trusted execution environments), are a class of hardware that can confidentially and verifiably run a process or an entire virtual machine. Output can emit a quote that confirms that output must have been generated by the binary listed.When running an application inside a secure enclave, the application may emit any output paired with a “quote”\nThese quotes sign the desired output with a unique signing key from within the TEE which can then be verified by any user to confirm that the generated output must have been generated by the binary listed within the quoteN/AEnclave QuoteA cryptographically signed message that originates from within a secure enclave. Authenticated using the certificate chain of the chip manufacturer and may include data produced by an application operating inside the enclave. Attests that a specific output was indeed generated within a secure and authenticated enclave environment.A quote serves as a verifiable mechanism to attest that a specific output was indeed generated within a secure and authenticated enclave environment.N/AMR_ENCLAVEIntel's designation for an “enclave measurement”. A signed 32-byte hash that represents the binary or runtime loaded into the trusted execution environment. It serves as a definitive fingerprint of the code executing within the enclave, proving its authenticity and integrity.All enclave quotes include an MR_ENCLAVE value, allowing verification of the specific code that produced a give output and confirms output from an authenticated/untampered code base within a secure enclave.N/APreviousFAQLast updated 1 year ago","tokens":703,"squid":"spider-08","role":"Oracle Spider","at":1791339197296,"hash":"f866b17b50c062ec10ea277e8cbe0814ecc4f50e"}
{"url":"https://docs.across.to/ai-agents/prompt-library","domain":"docs.across.to","title":"Prompt Library | Across Docs","text":"Prompt LibraryCurated prompts for AI agents working with the Across Protocol — organized by task category.Prompts by Category\nTested prompts organized by task category. Each prompt shows the natural-language instruction, the steps an agent should take, and the API endpoints involved.\nThese prompts work best when the agent has the Across skill installed or access to the machine-readable documentation.\nWhat chains does Across support?Prompt:What chains does Across support? List them with their chain IDs.Agent steps:\nCall GET /swap/chains\nFormat the response as a table of chain names and IDs\nEndpoint: GET https://app.across.to/api/swap/chainsWhat tokens can I bridge from Arbitrum?Prompt:What tokens can I bridge from Arbitrum using Across?Agent steps:\nCall GET /swap/chains to find Arbitrum's chain ID (42161)\nCall GET /swap/tokens?chainId=42161\nList all tokens with their symbols, addresses, and decimals\nEndpoints: GET /swap/chains, GET /swap/tokens?chainId=42161What are the limits for USDC?Prompt:What are the transfer limits for bridging USDC from Arbitrum to Base?Agent steps:\nLook up USDC addresses on both chains via /swap/tokens\nCall GET /swap/limits with the token addresses and chain IDs\nReport minimum and maximum transfer amounts\nEndpoints: GET /swap/tokens, GET /swap/limits?originChainId=42161&destinationChainId=8453&inputToken=...&outputToken=...Get a quote to bridge USDCPrompt:Get a quote to bridge 100 USDC from Arbitrum to Base. Show me the fees and estimated fill time.Agent steps:\nLook up chain IDs for Arbitrum (42161) and Base (8453)\nLook up USDC addresses on both chains via /swap/tokens\nCall GET /swap/approval with amount=100000000 (100 USDC, 6 decimals) and tradeType=minOutput\nExtract fees, expectedFillTime, and output amount from the response\nEndpoint: GET /swap/approval?originChainId=42161&destinationChainId=8453&inputToken=...&outputToken=...&amount=100000000&depositor=...&tradeType=minOutputCompare fees across routesPrompt:Compare the fees for bridging 1000 USDC from Ethereum to Arbitrum vs Ethereum to Base.Agent steps:\nLook up USDC addresses on Ethereum, Arbitrum, and Base\nCall /swap/approval for Ethereum→Arbitrum with amount=1000000000\nCall /swap/approval for Ethereum→Base with amount=1000000000\nCompare fees.totalFeeUsd and expectedFillTime for both routes\nEndpoint: Two calls to GET /swap/approval with different destinationChainId valuesBridge 100 USDC from Arbitrum to BasePrompt:Bridge 100 USDC from Arbitrum to Base using my connected wallet.Agent steps:\nCall GET /swap/chains to confirm both chains are supported\nCall GET /swap/tokens?chainId=42161 and GET /swap/tokens?chainId=8453 to find USDC addresses\nCall GET /swap/approval with the route parameters and depositor set to the wallet address\nCheck checks.balance and checks.allowance on the response\nExecute each transaction in approvalTxns (if any)\nExecute swapTx — this is the bridge deposit\nEndpoints: /swap/chains, /swap/tokens, /swap/approvalHandle approvals and executePrompt:I want to bridge 50 USDT from Ethereum to Optimism. Handle token approvals automatically.Agent steps:\nDiscover chains and look up USDT addresses\nGet a quote via /swap/approval\nCheck if approvalTxns is non-empty — if so, send each approval transaction and wait for confirmation\nSend the swapTx transaction\nReturn the transaction hash and expected fill time\nEndpoints: /swap/chains, /swap/tokens, /swap/approvalCheck the status of a depositPrompt:Check the status of my bridge deposit with tx hash 0xabc123... on Arbitrum.Agent steps:\nCall GET /deposit/status?originChainId=42161&depositTxHash=0xabc123...\nReport the status: pending, filled, or expired\nIf filled, show the fill transaction hash and destination chain\nEndpoint: GET /deposit/status?originChainId=42161&depositTxHash=0xabc123...Poll until filledPrompt:Bridge 100 USDC from Arbitrum to Base and wait until the transfer is complete.Agent steps:\nExecute the full bridge flow (discover → quote → approve → execute)\nAfter the deposit tx confirms, poll GET /deposit/status every 2 seconds\nContinue polling until status is filled\nReport the fill transaction hash and total time elapsed\nEndpoints: /swap/chains, /swap/tokens, /swap/approval, /deposit/statusBridge USDC and deposit into AavePrompt:Bridge 100 USDC from Arbitrum to Ethereum, swap to ETH, and deposit into Aave's lending pool.Agent steps:\nDiscover chains and look up USDC (Arbitrum) and WETH (Ethereum) addresses\nBuild an embedded action targeting Aave's WETH Gateway depositETH() function\nCall POST /swap/approval with the actions array in the body and recipient set to the MulticallHandler contract\nExecute approvals, then the swap transaction\nThe user receives an aWETH position on Ethereum\nEndpoints: POST /swap/approval with actions bodyEmbedded actions require setting the recipient to the MulticallHandler contract address, not the user's wallet. The MulticallHandler receives the bridged tokens and executes the action on behalf of the user.Bridge ETH and add HubPool liquidityPrompt:Bridge ETH from Arbitrum to Ethereum and add it as liquidity to the Across HubPool.Agent steps:\nLook up the ETH/WETH addresses on both chains\nBuild an embedded action targeting the HubPool's addLiquidity() function\nCall POST /swap/approval with the action and MulticallHandler as recipient\nExecute the transaction — the user receives LP tokens on Ethereum\nEndpoints: POST /swap/approval with actions bodyAGENTS.mdA ready-to-copy AGENTS.md template that gives coding agents full context on your Across integration.Agent WorkflowsEnd-to-end examples showing real AI agent sessions performing crosschain tasks with the Across Protocol.","tokens":1409,"squid":"spider-09","role":"Bridge Spider","at":1791339201748,"hash":"cfe70d8c55cccf7099df526536af86086f393db7"}
{"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":"spider-05","role":"Spec Spider","at":1791339226442,"hash":"09337dd9fbd93790ff523cc6b0b0ece3f45f0bf4"}
{"url":"https://docs.across.to/ai-agents/mcp-server","domain":"docs.across.to","title":"MCP Server | Across Docs","text":"MCP ServerGive any MCP-compatible AI client full access to Across Protocol documentation, chain data, and live bridge fees.What is MCP?\nThe Model Context Protocol (MCP) is an open standard that lets AI applications connect to external tools and data sources through a unified interface. The Across MCP server indexes Across documentation and exposes tools for searching docs, querying supported chains, fetching live bridge fees, and retrieving code examples — all from within your AI client.\nHosted instance available — no local setup required. Point your client at https://mcp.across.to/mcp and you're ready to go.\nConnect to the Hosted Server\nThe fastest way to get started is to connect your AI client to the hosted MCP server.\nEdit your Claude Desktop config file:\nmacOS: ~/Library/Application Support/Claude/claude_desktop_config.json\nWindows: %APPDATA%\\Claude\\claude_desktop_config.json\nLinux: ~/.config/Claude/claude_desktop_config.json\nclaude_desktop_config.json{\n \"mcpServers\": {\n \"across-docs\": {\n \"url\": \"https://mcp.across.to/mcp\"\n }\n }\n}Restart Claude Desktop after saving. The Across tools will appear in the tool picker.terminalclaude mcp add --transport http across-docs https://mcp.across.to/mcpOr add to your project's .mcp.json:.mcp.json{\n \"mcpServers\": {\n \"across-docs\": {\n \"url\": \"https://mcp.across.to/mcp\"\n }\n }\n}Create or edit .cursor/mcp.json in your project (or ~/.cursor/mcp.json for global):.cursor/mcp.json{\n \"mcpServers\": {\n \"across-docs\": {\n \"url\": \"https://mcp.across.to/mcp\"\n }\n }\n}Add to .vscode/settings.json:settings.json{\n \"mcp\": {\n \"servers\": {\n \"across-docs\": {\n \"url\": \"https://mcp.across.to/mcp\"\n }\n }\n }\n}Add to ~/.windsurf/mcp.json:mcp.json{\n \"mcpServers\": {\n \"across-docs\": {\n \"url\": \"https://mcp.across.to/mcp\"\n }\n }\n}Add to your MCP config:mcp.json{\n \"mcpServers\": {\n \"across-docs\": {\n \"url\": \"https://mcp.across.to/mcp\"\n }\n }\n}\nAvailable Tools\nOnce connected, your AI agent has access to seven tools:\nToolDescriptionsearch_across_docsFull-text search across all Across documentationget_pageRetrieve a complete documentation page by pathget_api_referenceBrowse REST API endpoints and their parametersget_supported_chainsList mainnet and testnet chains with chain IDsget_bridge_feesQuery live bridge fees from the Across APIget_code_examplesGet SDK and integration code samplesrecrawl_docsForce a documentation refresh\nExample Prompts\nOnce configured, you can ask your AI agent things like:\nSearch the Across docs for how to do a crosschain swap\nWhat chains does Across Protocol support?\nWhat are the bridge fees to send USDC from Ethereum to Arbitrum?\nShow me code examples for using the Across SDK\nShow me the Across API endpoint for suggested fees\nHow do I run an Across relayer?\nSelf-Hosting\nIf you prefer to run the server locally instead of using the hosted instance:\nterminalgit clone https://github.com/across-protocol/mcp-server-across.git\ncd mcp-server-across\nnpm install\nnpm run build\nThen point your client to the local build:\nclaude_desktop_config.json{\n \"mcpServers\": {\n \"across-docs\": {\n \"command\": \"node\",\n \"args\": [\"/absolute/path/to/mcp-server-across/dist/index.js\"]\n }\n }\n}terminalclaude mcp add across-docs node /absolute/path/to/mcp-server-across/dist/index.js\nThe server caches documentation locally at ~/.across-mcp/cache.json and refreshes every 24 hours.\nDocker\nterminaldocker build -t mcp-server-across .\ndocker run -i mcp-server-across\nWith cache persistence:\nterminaldocker run -i -v across-mcp-cache:/root/.across-mcp mcp-server-across\nDevelopment\nterminalnpm run dev # watch mode\nnpx @modelcontextprotocol/inspector node dist/index.js # test with MCP Inspector UI\nSource Code\nThe MCP server is open source: github.com/across-protocol/mcp-server-acrossAI AgentsGive your AI agent crosschain superpowers with a single command.Machine-Readable DocsFeed Across documentation directly to AI agents and RAG pipelines via llms.txt endpoints.","tokens":978,"squid":"spider-09","role":"Bridge Spider","at":1791339235556,"hash":"7eccf755f09a498567112b750fa3724075cb1e6b"}
{"url":"https://forum.arbitrum.foundation/t/govhack-at-eth-cc-brussels/23305/52","domain":"forum.arbitrum.foundation","title":"GovHack at ETH CC (Brussels) - Proposals / Finalized AIPs - Arbitrum","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 5\n\n 4\n\n 3\n\n 3\n\n 2\n\n read \n\n 12\n min\n\n Apr 2024\n\n 52 / 52\n\n Aug 2024\n\n Aug 2024\n\n Load more posts above\n\n post by Tane on May 1, 2024\n\n post by Entropy on May 1, 2024\n\n post by PrincetonBlockchain on May 2, 2024\n\n post by Curia on May 2, 2024\n\n post by krst on May 2, 2024\n\n post by jameskbh on May 2, 2024\n\n post by ocandocrypto on May 6, 2024\n\n post by mcfly on May 6, 2024\n\n post by KlausBrave on May 7, 2024\n\n post by maxlomu on May 10, 2024\n\n post by Tane on May 12, 2024\n\n post by WinVerse on May 13, 2024\n\n post by PrincetonBlockchain on May 16, 2024\n\n post by Bob-Rossi on May 16, 2024\n\n post by jameskbh on May 17, 2024\n\n post by pfedprog on May 19, 2024\n\n post by KlausBrave on May 20, 2024\n\n KlausBrave\n\n The approximate budget for GovHack ETHDenver was $200k.\nIt was co-organised and funded with the Foundation, Hack Humanity and sponsorship.\nThe first GovHack event was almost all costs to prove the concept, no profitability.\nFor GovHack ETHcc in Brussels the event size is 50% larger, we are increasing the prize pool from $15 to 20k, adding a dedicated afterparty, adding $10k of scholarships, proper financing for media, marketing, team, all components.\nThe top-line figure of $309k has contingency built in and is a high-side estimate to ensure that once the proposal passes on Tally there is always more than enough in the pool to cover any contingencies once detailed research is undertaken for Brussels suppliers.\nExcess funds are returned to the DAO as agreed in the proposal on Tally.\nVoting with Tally passed yesterday, which means the delegates agreed to this proposal and shortly the resources necessary to produce GovHack will soon be available within 3 days to the multisig for Hack Humanity to produce the event.\nPersonally, ahead of the voting finishing and funding, I have come to Brussels and spent the last 1 week evaluating 53 venues & catering (typically sold as a package by venues), most venues are either too far away, already booked out for ETHcc, or too small, I.e. not fit for what we need in the hackathon 20-30 teams x 5-6 people each on one floor + multiple private breakout rooms.\nFrom my research this week, I found that the estimate for this component is fairly accurate.\nZeroing in on the final venue selection this week.\n\n GovHack ETHDenver 2024 - Impact Report - Hack Humanity\n\n GovHack Devcon in Bangkok - Hack Humanity\n\n 16 days later\n\n post by KlausBrave on Jun 6, 2024\n\n KlausBrave\n\n Gm gm,\nVenue signed and sealed.\nGovHack Brussels event page is live, you can sign up here Arbitrum GovHack Brussels · Luma\nWould love to see many of you there in person.\nKlaus\n\n 13 days later\n\n post by DisruptionJoe on Jun 19, 2024\n\n DisruptionJoe\n\n It would be great to get a post with the event dates and times and roles we can sign up for or that you’re looking to fill. It would be a nice closer for this thread.\n\n 2 months later\n\n post by KlausBrave on Aug 31, 2024\n\n KlausBrave\n\n Cross-posting the GovHack Impact Report for this event here for completeness:\n\nand final comment including the Arbiscan transaction for the record sending back remaining under used funds to the DAO Treasury as agreed:\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n GovHack ETHcc Brussels 2024 - Impact Report - Hack Humanity\n\n GovHack Brussels\n\n 19\n\n 782\n\n Sep 2024\n\n GovHack ETHDenver 2024 - Impact Report - Hack Humanity\n\n GovHack Denver\n\n 9\n\n 1.6k\n\n Jun 2024\n\n GovHack Devcon in Bangkok - Hack Humanity\n\n Archived Proposals\n\n 74\n\n 1.9k\n\n Oct 2024\n\n GovHack - ETHDenver powered by Hack Humanity\n\n GovHack Denver\n\n 9\n\n 2.5k\n\n May 2024\n\n Arbitrum DAO in ETH Bucharest 2025\n\n DAO Programs & Initiatives\n\n proposal-discussions\n\n 24\n\n 919\n\n May 2025","tokens":949,"squid":"spider-07","role":"Council Spider","at":1791339236886,"hash":"2233888ea6af00c18db7ec0f9beec4c1c89c6097"}
{"url":"https://docs.across.to/ai-agents/agents-md","domain":"docs.across.to","title":"AGENTS.md | Across Docs","text":"AGENTS.mdA ready-to-copy AGENTS.md template that gives coding agents full context on your Across integration.What is AGENTS.md\nAGENTS.md is a convention for providing project context to AI coding agents. When an agent like Claude Code, Codex, or Cursor opens your repository, it reads the nearest AGENTS.md (or CLAUDE.md, .cursorrules, etc.) to understand the project's architecture, conventions, and integration patterns.\nWhy You Need One\nWithout an AGENTS.md, coding agents have to guess how your Across integration works — which API endpoints you use, how you format amounts, where your bridge logic lives, and what security constraints to follow.\nWith one, your agent can:\n\nCall the correct Swap API endpoints without hallucinating URLs\nUse your integrator ID and configured chains\nFollow your project's conventions for error handling and token addresses\nAvoid common mistakes like hardcoding addresses or logging private keys\n\nDrop this file in your project root as AGENTS.md, CLAUDE.md, or .cursorrules — whichever your agent framework reads. The content is the same.\nThe Template\nCopy this template into your repository and fill in the placeholders:\nAGENTS.md# Project Context\n\n[YOUR PROJECT NAME] — [brief description of what the project does].\nBuilt with [framework/stack]. Uses Across Protocol for crosschain token transfers.\n\n# Across Integration\n\n- **Integrator ID**: `0xYOUR_INTEGRATOR_ID` (2-byte hex, register at https://app.across.to)\n- **API Base URL**: `https://app.across.to/api` (production)\n- **Testnet API**: `https://testnet.across.to/api` (Sepolia testnet)\n- **Supported Chains**: [list the chains your app supports, e.g., Ethereum, Arbitrum, Base, Optimism]\n- **Supported Tokens**: [list tokens, e.g., USDC, USDT, WETH, ETH]\n- **SDK**: `@across-protocol/app-sdk` (if using the SDK)\n\n# Build & Test\n\n```bash\n[your install command, e.g., pnpm install]\n[your build command, e.g., pnpm build]\n[your test command, e.g., pnpm test]\n[your dev command, e.g., pnpm dev]\n```\n\n# Key Files\n\n- `[path/to/bridge-logic]` — Main bridge integration (Swap API calls)\n- `[path/to/config]` — Chain and token configuration\n- `[path/to/hooks-or-utils]` — Bridge hooks/utilities\n- `[path/to/types]` — Type definitions for API responses\n\n# API Patterns\n\nAll crosschain transfers go through the Swap API:\n\n1. **Discover chains**: `GET /swap/chains` — returns supported chains with IDs\n2. **Look up tokens**: `GET /swap/tokens?chainId={id}` — returns tokens for a chain\n3. **Get a quote**: `GET /swap/approval?originChainId=...&destinationChainId=...&inputToken=...&outputToken=...&amount=...&depositor=...&tradeType=minOutput`\n4. **Execute**: Send `approvalTxns` first (if any), then `swapTx`\n5. **Track**: `GET /deposit/status?originChainId=...&depositTxHash=...`\n\nFor embedded actions (bridge + DeFi in one tx):\n- Use `POST /swap/approval` with `actions` array in the body\n- Set `recipient` to the MulticallHandler contract address\n\n# Conventions\n\n- NEVER hardcode token addresses — always fetch from `/swap/tokens`\n- NEVER hardcode chain IDs in logic — use `/swap/chains` as source of truth\n- Format amounts using the token's `decimals` field (USDC = 6, WETH = 18)\n- Use `tradeType: \"minOutput\"` for standard bridges (user receives at least the specified amount)\n- Use `tradeType: \"exactInput\"` for embedded actions (exact input, variable output)\n- Always include the integrator ID in production API calls\n\n# Security\n\n- NEVER log or expose private keys, seed phrases, or signing keys\n- NEVER commit `.env` files or credentials\n- Always check `simulationSuccess` on the quote before executing transactions\n- Validate `checks.allowance` and `checks.balance` before sending\n- Use the API-provided gas estimates — don't hardcode gas limits\n- For embedded actions, verify the `recipient` is the MulticallHandler, not the user address\n\n# Common Agent Tasks\n\nWhen asked to:\n- **\"Bridge tokens\"** — Use the 5-step Swap API flow: chains → tokens → quote → approve → execute\n- **\"Get a quote\"** — Call `/swap/approval` with the route parameters\n- **\"Check bridge status\"** — Call `/deposit/status` with the origin chain ID and deposit tx hash\n- **\"Add a new chain\"** — Check `/swap/chains` to verify support, then add chain config\n- **\"Bridge and deposit into DeFi\"** — Use embedded actions with POST `/swap/approval`\nCustomization Guide\nFill in Project ContextReplace the placeholders in the first section with your project name, description, and tech stack. Be specific — agents use this to understand the overall architecture.Configure Across IntegrationAdd your integrator ID (required for production), the chains your app supports, and which tokens you bridge. If you only bridge USDC on Arbitrum and Base, say so — the agent won't try to use unsupported routes.Map Your Key FilesPoint the agent to where your bridge logic lives. Include the config file where chains/tokens are defined, the main integration file that calls the API, and any shared types or utilities.Add Project-Specific ConventionsIf your project has additional rules (e.g., \"always use BigInt for amounts\", \"wrap API calls in a try/catch with our logger\"), add them to the Conventions section. The agent will follow these patterns in generated code.Define Common TasksAdd task-specific instructions for prompts your team uses frequently. For example, if you often ask the agent to \"add a new bridge route\", describe the exact files to modify and the pattern to follow.Machine-Readable DocsFeed Across documentation directly to AI agents and RAG pipelines via llms.txt endpoints.Prompt LibraryCurated prompts for AI agents working with the Across Protocol — organized by task category.","tokens":1413,"squid":"spider-09","role":"Bridge Spider","at":1791339249219,"hash":"77286e9cef95e7133271f08b330c7c0b3e190749"}
{"url":"https://forum.arbitrum.foundation/t/govhack-ethcc-brussels-2024-impact-report-hack-humanity/26530/16","domain":"forum.arbitrum.foundation","title":"GovHack ETHcc Brussels 2024 - Impact Report - Hack Humanity - Archive / GovHack Brussels - Arbitrum","text":"The Arbitrum Foundation notified the Security Council on the need to perform a potential Emergency action. Following a review of the details and known risks, the Security Council decided to execute the upgrade and it was completed at 11:30 EST on 2nd October 2026.\nThis report provides an overview of the risks that required the Security Council Action:\n\nAdd a permissionless guard for the One-Step Proof of BoLD on Arbitrum One\n\nTemporarily pause activation of new Stylus contracts on Arbitrum One & Nova\n\nKey point: To date, known bugs for Stylus primarily impact chain liveness (e.g., denial of service attacks) and do not put any user funds at risk.\nWhy was this action taken\nLet’s take this opportunity to explain why action was taken on two separate issues concerning BoLD and Stylus.\nInstalling the guard for One-Step Proof of BoLD. Given the rise of AI-assisted attacks, we have implemented a precautionary approach that allows anyone to pause settlement of Arbitrum One on Ethereum if there are at least two conflicting answers that pass at the same level in which only one should be valid and pass. This is to halt a class of publicly verifiable and detectable attacks that exploit a bug in the one-step proof. If halted, Arbitrum One will continue to process as normal except that messages from Arbitrum One to Ethereum, such as withdrawals, that are not yet confirmed will have to wait. This provides time for the Security Council to deploy a fix for the bug and resume the rollup.\nPreventing activation of new Stylus contracts. AI-assisted tooling has led to an increasing number of sophisticated attacks on hand-crafted WASM programs that do not use the standard Stylus compiler toolchain. These programs are specifically designed to cause unexpected behaviors such as degrading the chain’s performance for all other users. To date, no attacks have been discovered that permits theft of user funds.\nNew ArbOS releases have patched several reported bugs and known attacks over the past few months, but out of an abundance of caution, we have decided to temporarily pause new activations of Stylus contracts. This was executed as an emergency action to prevent the deployment of new hand-crafted WASM programs that are not yet patched by the current version of ArbOS on the Arbitrum network.\nThe Arbitrum Foundation has informed the Security Council that they will work with the ArbitrumDAO to discuss next steps on the timeline and manner for enabling activation of new Stylus contracts. The Arbitrum community remains confident in the value of Stylus and want to preserve these use cases while taking preventative measures against Stylus-based attack vectors as AI-assisted attack tooling continues to evolve.\nImpact on builders and users\n\nNo new activations. New Stylus contracts cannot be activated during the pause including new versions of existing applications that require activation.\n\nExisting contracts are not paused. Already-active Stylus contracts continue to execute until expiration. This pause does not deactivate them.\n\nThe ArbOS 61 upgrade renewed all active contracts on Arbitrum One, so no currently active contract expires before August 20, 2027.\n\nRenewal via keepalive stays permissionless and is unaffected by the pause.\n\nReactivating an expired contract, or one that needs to be updated after a Stylus version change, is paused.\n\nUsing/calling any activated Stylus contract stays permissionless for all users and developers.\n\nNo impact on EVM. Solidity (EVM) contract deployment and execution are unaffected by this Security Council action.\n\nSecurity Council Actions\nThere are two actions bundled into a single payload:\n\nOne-Step Proof Guard. The L1UpgradeExecutor gives a new pause contract (PauseExecutor) the ability to pause and nothing else. The new pause contract grants the guard (OspSoundnessGuard) PAUSER_ROLE to use it. Anyone can show the guard two conflicting answers to the same step of an open challenge. If the one-step proof accepts both, the guard has the pause contract put Arbitrum One’s settlement to Ethereum on hold.\n\nStylus deactivation. The Security Council called ArbOwner.setWasmActivationGas(2^64 - 1) to raise the Stylus activation gas requirement on Arbitrum One and Nova. This makes activation prohibitively expensive and effectively disables new activations. This is a configuration change and does not require an ArbOS upgrade.\n\nThe Security Council signed the following transactions to update the configuration:\n\nEthereum: Ethereum Transaction Hash: 0x30732bb7d2... | Etherscan\nArbitrum One:\nArbitrum One Transaction Hash: 0x9eb3a4be3b... | Arbitrum One\nArbitrum Nova:\nArbitrum Nova transaction 0x79e0fed470dff7a22059b108e3f8f42eddd2b580a6771594060c4e7326c5f984 | Blockscout\n\nAn external audit was conducted for the OSP Guard contracts. No audit is required for the Stylus deactivation as it is only updating a single parameter in the ArbOS configuration.\n\n ArchiveGovHack Brussels\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 16\n min\n\n Aug 2024\n\n 16 / 20\n\n Aug 2024\n\n Sep 2024\n\n post by KlausBrave on Aug 28, 2024\n\n post by julesfoa.eth on Aug 28, 2024\n\n post by KlausBrave on Aug 28, 2024\n\n post by ZER8 on Aug 28, 2024\n\n post by KlausBrave on Aug 28, 2024\n\n post by feems on Aug 28, 2024\n\n post by KlausBrave on Aug 28, 2024\n\n post by feems on Aug 28, 2024\n\n post by Frisson on Aug 28, 2024\n\n post by bianca on Aug 28, 2024\n\n post by JoJo on Aug 28, 2024\n\n post by paulofonseca on Aug 28, 2024\n\n post by tobsch on Aug 29, 2024\n\n post by kinaArb on Aug 29, 2024\n\n kinaArb\n\n The report has sparked some interest. It’s promising to see potential in enhancing transparency and scalability within the DAO.\nLet’s hope these ideas gain traction and lead to tangible improvements. Looking forward to seeing further outcomes from this initiative.\n\n post by sid_areta on Aug 29, 2024\n\n sid_areta\n\n Overall, the GovHack experience was absolutely fantastic for us and it was great to meet everyone we have been working with so closely with in person! Huge kudos to @KlausBrave and the HackHumanity team for pulling off such an engaged and professionally run event, especially considering the time pressure they were under.\nIn terms of feedback, we think that future GovHacks can be two-pronged. The first prong that is crucial to be retained is to serve newcomers and help educate them on how to write proposals and contribute directly to the DAO. This could be further expanded by providing more education and context around the current state of the DAO and where specific help and input from contributors is needed - this would be extremely useful for existing high-context contributors as well, for whom it is relatively difficult to keep up with everything going on in a DAO as large and sprawling as Arbitrum. Teams working on existing initiatives can, for example, go in depth on their work, present it to the DAO, and speak through achievements and challenges to help everyone attain the context that sometimes can be lacking on calls or on the forum.\nThe second prong would be around having sessions for contributors to the DAO who are already high-context; more brainstorming sessions and dedicated opportunities to discuss important topics that the DAO needs to solve for would also be very beneficial. It turned out that for a lot of contributors who work on Arbitrum day in, day out, that GovHack was more of a great networking opportunity - there is an opportunity to capitalise on this and dedicate time towards topics that contributors feel are crucial to discuss in person and further advance.\nAll in all, this is a fantastic Impact Report and it has been a pleasure getting to know and work alongside Klaus and the HackHumanity team.\n\n post by KlausBrave on Aug 31, 2024\n\n KlausBrave\n\n All remaining and final funds (underspent + the ARB buffer) have been returned from GovHack multisig to the DAO Treasury.\n203.5k ARB, transaction:\n\nThank you to @krst and @AbdullahUmar as fellow multi-sig signers,\nand to @cliffton.eth for Foundation oversight and confirming the transaction.\n\n GovHack at ETH CC (Brussels)\n\n post by ostanescu.eth on Sep 5, 2024\n\n ostanescu.eth\n\n Thank you @KlausBrave and the entire Hack Humanity team for pulling up such a great event.\nI am super greatful to have had the chance to be part and build alongside Arbitrum community.\nAt ETH Bucharest we are now in process of discussing a proposal that would bootstrap the local Arbitrum community and this is all thanks to the GovHack Brussels.\nI am also very greatful to have met such great people, and to my surprise bump into people that I didn’t know they are gonna be there. Which made me feel even more that I am in the right place.\nLooking forward to the next edition and hopefully we can organize something in Bucharest one day!\nCongrats and keep going! #LFG\n\n post by Gonzacolo on Sep 8, 2024\n\n Gonzacolo\n\n I appreciate the report. Being clear with the data and process is crucial.\nAs I’ve mentioned in other channels, initiatives like this are extremely complex to execute, and this is one of the few places where participants from the Arbitrum DAO can meet in person. Personally, I had the chance to meet some incredible people, and the relationships and trust we build by connecting face-to-face will significantly contribute to growing this ecosystem that we all support, enabling us to create better products and initiatives.\nI also think that narrowing the scope of the tracks could be beneficial. Some technical tracks, which I personally found interesting, didn’t seem to be fully aligned with the DAO’s goals and, in the end, weren’t particularly helpful for the DAO itself.\nI support the cross-activities that help us get to know each other, like those on the first day, but spread throughout the event. This would allow us to connect even more, including with the new participants.\nI look forward to it happening again and hope to participate in the future!\n\n post by KlausBrave on Sep 8, 2024\n\n post by Mehdi_eth on Sep 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 GovHack ETHDenver 2024 - Impact Report - Hack Humanity\n\n GovHack Denver\n\n 9\n\n 1.6k\n\n Jun 2024\n\n GovHack at ETH CC (Brussels)\n\n Finalized AIPs\n\n 51\n\n 3.9k\n\n Aug 2024\n\n GovHack Devcon in Bangkok - Hack Humanity\n\n Archived Proposals\n\n 74\n\n 1.9k\n\n Oct 2024\n\n GovHack - ETHDenver powered by Hack Humanity\n\n GovHack Denver\n\n 9\n\n 2.5k\n\n May 2024\n\n ArbitrumDAO Off-site - Directional proposal\n\n Finalized AIPs\n\n 89\n\n 2.3k\n\n Oct 2024","tokens":2641,"squid":"spider-07","role":"Council Spider","at":1791339249530,"hash":"396cbedd127e556f0cd3bb7cbf4e91fb28ea796d"}
{"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":"spider-05","role":"Spec Spider","at":1791339256795,"hash":"67d57f3592f487008a321c861c6e24b5b487c9f7"}
{"url":"https://docs.across.to/ai-agents/llms-txt","domain":"docs.across.to","title":"Machine-Readable Docs | Across Docs","text":"Machine-Readable DocsFeed Across documentation directly to AI agents and RAG pipelines via llms.txt endpoints.Every page on this site is available in machine-readable markdown format. AI agents, RAG pipelines, and LLM tools can consume Across documentation without scraping HTML.\nEndpoints\nEndpointContentBest For/llms.txtPage index with titles, URLs, and descriptionsDirectory lookup — find the right page to read/llms-full.txtAll pages concatenated as markdownRAG ingestion, large-context agents/docs/<path>.mdxSingle page as raw markdownTargeted reads — fetch exactly one page\nWhen to Use Which\n\nAgent needs to find a page — fetch /llms.txt, scan for the relevant title, then fetch that page's .mdx endpoint.\nAgent needs full context — fetch /llms-full.txt and pass the entire corpus (or relevant chunks) into the context window.\nAgent already knows the page — append .mdx to any docs URL to get raw markdown. For example, /ai-agents/llms-txt.mdx returns this page as markdown.\n\nThe /llms-full.txt endpoint is large. If your agent has a limited context window, prefer /llms.txt to find the right page and then fetch it individually via .mdx.\nFetching Examples\nPage Index\nterminalcurl https://docs.across.to/llms.txtagent.tsconst index = await fetch(\"https://docs.across.to/llms.txt\").then(r => r.text());\nconsole.log(index);agent.pyimport requests\n\nindex = requests.get(\"https://docs.across.to/llms.txt\").text\nprint(index)\nFull Documentation Dump\nterminalcurl https://docs.across.to/llms-full.txtagent.tsconst full = await fetch(\"https://docs.across.to/llms-full.txt\").then(r => r.text());\nconsole.log(full);agent.pyimport requests\n\nfull = requests.get(\"https://docs.across.to/llms-full.txt\").text\nprint(full)\nSingle Page\nterminal# Fetch the Swap API docs as markdown\ncurl https://docs.across.to/introduction/swap-api.mdxagent.tsconst page = await fetch(\"https://docs.across.to/introduction/swap-api.mdx\")\n .then(r => r.text());\nconsole.log(page);agent.pyimport requests\n\npage = requests.get(\"https://docs.across.to/introduction/swap-api.mdx\").text\nprint(page)\nPer-Page Actions\nEvery documentation page includes built-in buttons for AI consumption:\n\nCopy Markdown — copies the page content as markdown to your clipboard\nOpen in Claude / ChatGPT / Cursor — opens the AI tool with the page URL pre-loaded as context\n\nThese buttons appear at the top of each page and use the same .mdx endpoints described above.\nFor RAG Pipelines\nThe /llms-full.txt endpoint concatenates all pages with # Title headings. You can split on H1 headings to chunk by page:\nchunker.pyimport requests\n\nfull_text = requests.get(\"https://docs.across.to/llms-full.txt\").text\n\n# Split into per-page chunks\nchunks = []\ncurrent_chunk = \"\"\n\nfor line in full_text.split(\"\\n\"):\n if line.startswith(\"# \") and current_chunk:\n chunks.append(current_chunk.strip())\n current_chunk = line + \"\\n\"\n else:\n current_chunk += line + \"\\n\"\n\nif current_chunk.strip():\n chunks.append(current_chunk.strip())\n\nprint(f\"Split into {len(chunks)} page chunks\")\nEach chunk corresponds to one documentation page and can be embedded independently for retrieval.MCP ServerGive any MCP-compatible AI client full access to Across Protocol documentation, chain data, and live bridge fees.AGENTS.mdA ready-to-copy AGENTS.md template that gives coding agents full context on your Across integration.","tokens":834,"squid":"spider-09","role":"Bridge Spider","at":1791339259700,"hash":"05a320fb98f4ed8c72585575d947f5a9bb114524"}
{"url":"https://forum.arbitrum.foundation/t/govhack-ethcc-brussels-2024-impact-report-hack-humanity/26530/17","domain":"forum.arbitrum.foundation","title":"GovHack ETHcc Brussels 2024 - Impact Report - Hack Humanity - Archive / GovHack Brussels - Arbitrum","text":"The Arbitrum Foundation notified the Security Council on the need to perform a potential Emergency action. Following a review of the details and known risks, the Security Council decided to execute the upgrade and it was completed at 11:30 EST on 2nd October 2026.\nThis report provides an overview of the risks that required the Security Council Action:\n\nAdd a permissionless guard for the One-Step Proof of BoLD on Arbitrum One\n\nTemporarily pause activation of new Stylus contracts on Arbitrum One & Nova\n\nKey point: To date, known bugs for Stylus primarily impact chain liveness (e.g., denial of service attacks) and do not put any user funds at risk.\nWhy was this action taken\nLet’s take this opportunity to explain why action was taken on two separate issues concerning BoLD and Stylus.\nInstalling the guard for One-Step Proof of BoLD. Given the rise of AI-assisted attacks, we have implemented a precautionary approach that allows anyone to pause settlement of Arbitrum One on Ethereum if there are at least two conflicting answers that pass at the same level in which only one should be valid and pass. This is to halt a class of publicly verifiable and detectable attacks that exploit a bug in the one-step proof. If halted, Arbitrum One will continue to process as normal except that messages from Arbitrum One to Ethereum, such as withdrawals, that are not yet confirmed will have to wait. This provides time for the Security Council to deploy a fix for the bug and resume the rollup.\nPreventing activation of new Stylus contracts. AI-assisted tooling has led to an increasing number of sophisticated attacks on hand-crafted WASM programs that do not use the standard Stylus compiler toolchain. These programs are specifically designed to cause unexpected behaviors such as degrading the chain’s performance for all other users. To date, no attacks have been discovered that permits theft of user funds.\nNew ArbOS releases have patched several reported bugs and known attacks over the past few months, but out of an abundance of caution, we have decided to temporarily pause new activations of Stylus contracts. This was executed as an emergency action to prevent the deployment of new hand-crafted WASM programs that are not yet patched by the current version of ArbOS on the Arbitrum network.\nThe Arbitrum Foundation has informed the Security Council that they will work with the ArbitrumDAO to discuss next steps on the timeline and manner for enabling activation of new Stylus contracts. The Arbitrum community remains confident in the value of Stylus and want to preserve these use cases while taking preventative measures against Stylus-based attack vectors as AI-assisted attack tooling continues to evolve.\nImpact on builders and users\n\nNo new activations. New Stylus contracts cannot be activated during the pause including new versions of existing applications that require activation.\n\nExisting contracts are not paused. Already-active Stylus contracts continue to execute until expiration. This pause does not deactivate them.\n\nThe ArbOS 61 upgrade renewed all active contracts on Arbitrum One, so no currently active contract expires before August 20, 2027.\n\nRenewal via keepalive stays permissionless and is unaffected by the pause.\n\nReactivating an expired contract, or one that needs to be updated after a Stylus version change, is paused.\n\nUsing/calling any activated Stylus contract stays permissionless for all users and developers.\n\nNo impact on EVM. Solidity (EVM) contract deployment and execution are unaffected by this Security Council action.\n\nSecurity Council Actions\nThere are two actions bundled into a single payload:\n\nOne-Step Proof Guard. The L1UpgradeExecutor gives a new pause contract (PauseExecutor) the ability to pause and nothing else. The new pause contract grants the guard (OspSoundnessGuard) PAUSER_ROLE to use it. Anyone can show the guard two conflicting answers to the same step of an open challenge. If the one-step proof accepts both, the guard has the pause contract put Arbitrum One’s settlement to Ethereum on hold.\n\nStylus deactivation. The Security Council called ArbOwner.setWasmActivationGas(2^64 - 1) to raise the Stylus activation gas requirement on Arbitrum One and Nova. This makes activation prohibitively expensive and effectively disables new activations. This is a configuration change and does not require an ArbOS upgrade.\n\nThe Security Council signed the following transactions to update the configuration:\n\nEthereum: Ethereum Transaction Hash: 0x30732bb7d2... | Etherscan\nArbitrum One:\nArbitrum One Transaction Hash: 0x9eb3a4be3b... | Arbitrum One\nArbitrum Nova:\nArbitrum Nova transaction 0x79e0fed470dff7a22059b108e3f8f42eddd2b580a6771594060c4e7326c5f984 | Blockscout\n\nAn external audit was conducted for the OSP Guard contracts. No audit is required for the Stylus deactivation as it is only updating a single parameter in the ArbOS configuration.\n\n ArchiveGovHack Brussels\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 16\n min\n\n Aug 2024\n\n 17 / 20\n\n Sep 2024\n\n Sep 2024\n\n post by KlausBrave on Aug 28, 2024\n\n post by julesfoa.eth on Aug 28, 2024\n\n post by KlausBrave on Aug 28, 2024\n\n post by ZER8 on Aug 28, 2024\n\n post by KlausBrave on Aug 28, 2024\n\n post by feems on Aug 28, 2024\n\n post by KlausBrave on Aug 28, 2024\n\n post by feems on Aug 28, 2024\n\n post by Frisson on Aug 28, 2024\n\n post by bianca on Aug 28, 2024\n\n post by JoJo on Aug 28, 2024\n\n post by paulofonseca on Aug 28, 2024\n\n post by tobsch on Aug 29, 2024\n\n post by kinaArb on Aug 29, 2024\n\n post by sid_areta on Aug 29, 2024\n\n sid_areta\n\n Overall, the GovHack experience was absolutely fantastic for us and it was great to meet everyone we have been working with so closely with in person! Huge kudos to @KlausBrave and the HackHumanity team for pulling off such an engaged and professionally run event, especially considering the time pressure they were under.\nIn terms of feedback, we think that future GovHacks can be two-pronged. The first prong that is crucial to be retained is to serve newcomers and help educate them on how to write proposals and contribute directly to the DAO. This could be further expanded by providing more education and context around the current state of the DAO and where specific help and input from contributors is needed - this would be extremely useful for existing high-context contributors as well, for whom it is relatively difficult to keep up with everything going on in a DAO as large and sprawling as Arbitrum. Teams working on existing initiatives can, for example, go in depth on their work, present it to the DAO, and speak through achievements and challenges to help everyone attain the context that sometimes can be lacking on calls or on the forum.\nThe second prong would be around having sessions for contributors to the DAO who are already high-context; more brainstorming sessions and dedicated opportunities to discuss important topics that the DAO needs to solve for would also be very beneficial. It turned out that for a lot of contributors who work on Arbitrum day in, day out, that GovHack was more of a great networking opportunity - there is an opportunity to capitalise on this and dedicate time towards topics that contributors feel are crucial to discuss in person and further advance.\nAll in all, this is a fantastic Impact Report and it has been a pleasure getting to know and work alongside Klaus and the HackHumanity team.\n\n post by KlausBrave on Aug 31, 2024\n\n KlausBrave\n\n All remaining and final funds (underspent + the ARB buffer) have been returned from GovHack multisig to the DAO Treasury.\n203.5k ARB, transaction:\n\nThank you to @krst and @AbdullahUmar as fellow multi-sig signers,\nand to @cliffton.eth for Foundation oversight and confirming the transaction.\n\n GovHack at ETH CC (Brussels)\n\n post by ostanescu.eth on Sep 5, 2024\n\n ostanescu.eth\n\n Thank you @KlausBrave and the entire Hack Humanity team for pulling up such a great event.\nI am super greatful to have had the chance to be part and build alongside Arbitrum community.\nAt ETH Bucharest we are now in process of discussing a proposal that would bootstrap the local Arbitrum community and this is all thanks to the GovHack Brussels.\nI am also very greatful to have met such great people, and to my surprise bump into people that I didn’t know they are gonna be there. Which made me feel even more that I am in the right place.\nLooking forward to the next edition and hopefully we can organize something in Bucharest one day!\nCongrats and keep going! #LFG\n\n post by Gonzacolo on Sep 8, 2024\n\n Gonzacolo\n\n I appreciate the report. Being clear with the data and process is crucial.\nAs I’ve mentioned in other channels, initiatives like this are extremely complex to execute, and this is one of the few places where participants from the Arbitrum DAO can meet in person. Personally, I had the chance to meet some incredible people, and the relationships and trust we build by connecting face-to-face will significantly contribute to growing this ecosystem that we all support, enabling us to create better products and initiatives.\nI also think that narrowing the scope of the tracks could be beneficial. Some technical tracks, which I personally found interesting, didn’t seem to be fully aligned with the DAO’s goals and, in the end, weren’t particularly helpful for the DAO itself.\nI support the cross-activities that help us get to know each other, like those on the first day, but spread throughout the event. This would allow us to connect even more, including with the new participants.\nI look forward to it happening again and hope to participate in the future!\n\n post by KlausBrave on Sep 8, 2024\n\n KlausBrave\n\n Thank you @Gonzacolo.\nThe number of tracks is definitely a parameter we can change up/down to create a more focused event.\nBringing more cross-activities to get to know each other spread throughout the event is a great suggestion, I agree we can include more of this in the next one.\nIt was great to meet you Gonzacolo, thanks for coming.\n\n post by Mehdi_eth on Sep 9, 2024\n\n Mehdi_eth\n\n Unfortunately, I could not participate, but based on the pictures and videos, it looks quite exciting to learn and meet the experienced delegates. For the next event, I hope you consider offering an online version as well.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n GovHack ETHDenver 2024 - Impact Report - Hack Humanity\n\n GovHack Denver\n\n 9\n\n 1.6k\n\n Jun 2024\n\n GovHack at ETH CC (Brussels)\n\n Finalized AIPs\n\n 51\n\n 3.9k\n\n Aug 2024\n\n GovHack Devcon in Bangkok - Hack Humanity\n\n Archived Proposals\n\n 74\n\n 1.9k\n\n Oct 2024\n\n GovHack - ETHDenver powered by Hack Humanity\n\n GovHack Denver\n\n 9\n\n 2.5k\n\n May 2024\n\n ArbitrumDAO Off-site - Directional proposal\n\n Finalized AIPs\n\n 89\n\n 2.3k\n\n Oct 2024","tokens":2720,"squid":"spider-07","role":"Council Spider","at":1791339259830,"hash":"7058e1f4afed144006004c944a169b45c4f7fef7"}
{"url":"https://eips.ethereum.org/EIPS/eip-161","domain":"eips.ethereum.org","title":"EIP-161: State trie clearing (invariant-preserving alternative)","text":"🎉 Final\n\n Standards Track: Core\n\n EIP-161: State trie clearing (invariant-preserving alternative)\n\n Authors\n Gavin Wood (@gavofyork)\n\n Created\n 2016-10-24\n\n Hard fork\n\nSpurious Dragon\n\n Parameters\n\n FORK_BLKNUM: 2,675,000\n CHAIN_ID: 1 (Mainnet)\n\n Specification\n\na. Account creation transactions and the CREATE operation SHALL, prior to the execution of the initialisation code, increment the nonce over and above its normal starting value by one (for normal networks, this will be simply 1, however test-nets with non-zero default starting nonces will be different).\n\nb. Whereas CALL and SUICIDE would charge 25,000 gas when the destination is non-existent, now the charge SHALL only be levied if the operation transfers more than zero value and the destination account is dead.\n\nc. No account may change state from non-existent to existent-but-_empty_. If an operation would do this, the account SHALL instead remain non-existent.\n\nd. At the end of the transaction, any account touched by the execution of that transaction which is now empty SHALL instead become non-existent (i.e. deleted).\n\nWhere:\n\nAn account is considered to be touched when it is involved in any potentially state-changing operation. This includes, but is not limited to, being the recipient of a transfer of zero value.\n\nAn account is considered empty when it has no code and zero nonce and zero balance.\n\nAn account is considered dead when either it is non-existent or it is empty.\n\nAt the end of the transaction is immediately following the execution of the suicide list, prior to the determination of the state trie root for receipt population.\n\nAn account changes state when:\n\n it is the target or refund of a SUICIDE operation for zero or more value;\n it is the source or destination of a CALL operation or message-call transaction transferring zero or more value;\n it is the source or creation of a CREATE operation or contract-creation transaction endowing zero or more value;\n as the block author (“miner”) it is the recipient of block-rewards or transaction-fees of zero or more value.\n\n Notes\n\nIn the present Ethereum protocol, it should be noted that very few state changes can ultimately result in accounts that are empty following the execution of the transaction. In fact there are only four contexts that current implementations need track:\n\n an empty account has zero value transferred to it through CALL;\n an empty account has zero value transferred to it through SUICIDE;\n an empty account has zero value transferred to it through a message-call transaction;\n an empty account has zero value transferred to it through a zero-gas-price fees transfer.\n\n Rationale\n\nSame as #158 except that several edge cases are avoided since we do not break invariants:\n\n that an account can go from having code and storage to not having code or storage mid-way through the execution of a transaction; [corrected]\n that a newly created account cannot be deleted prior to being deployed.\n\nCREATE avoids zero in the nonce to avoid any suggestion of the oddity of CREATEd accounts being reaped half-way through their creation.\n\n Addendum (2017-08-15)\n\nOn 2016-11-24, a consensus bug occurred due to two implementations having different behavior in the case of state reverts.[3] The specification was amended to clarify that empty account deletions are reverted when the state is reverted.\n\n References\n\n EIP-158 issue and discussion: https://github.com/ethereum/EIPs/issues/158\n EIP-161 issue and discussion: https://github.com/ethereum/EIPs/issues/161\n https://blog.ethereum.org/2016/11/25/security-alert-11242016-consensus-bug-geth-v1-4-19-v1-5-2/\n\n Details: Geth was failing to revert empty account deletions when the transaction causing the deletions of empty accounts ended with an out-of-gas exception. An additional issue was found in Parity, where the Parity client incorrectly failed to revert empty account deletions in a more limited set of contexts involving out-of-gas calls to precompiled contracts; the new Geth behavior matches Parity’s, and empty accounts will cease to be a source of concern in general in about one week once the state clearing process finishes.\n\n Citation\n Please cite this document as:\n\n Gavin Wood (@gavofyork), \"EIP-161: State trie clearing (invariant-preserving alternative),\" Ethereum Improvement Proposals, no. 161, October 2016. Available: https://eips.ethereum.org/EIPS/eip-161.","tokens":1099,"squid":"spider-05","role":"Spec Spider","at":1791339266993,"hash":"2032fec6c24da62bd1cffaaaa070328d58f3979e"}
{"url":"https://docs.across.to/api-reference/swap/gasless/get","domain":"docs.across.to","title":"Get a gasless swap quote | Across Docs","text":"Get a gasless swap quoteQuote a gasless swap or transfer: the user authorizes it with a single EIP-712 signature (swapTx — an ERC-3009 or Permit2 permit) and a submitter broadcasts it on-chain, so the user pays no gas.\n\nOrigin support. Gasless quoting and submission are currently supported for HyperCore (Hyperliquid) as the origin chain (originChainId: 1337) — support for additional origin chains is coming soon. See the Hyperliquid Withdrawals Guide for a working example.\nAuthorizationbearerAuth AuthorizationBearer <token>API key for authentication.In: headerQuery ParametersinputToken*stringInput token address on the origin chain. Must support gasless authorization (e.g. USDC via ERC-3009).originChainId*integerOrigin chain id — any Across-supported EVM chain. 1337 selects HyperCore (Hyperliquid) origin withdrawals.outputToken*stringDestination token address — the ERC-20 address on the destination chain (e.g. USDC on Base). 0x000…000 denotes the chain's native token (e.g. ETH on chain 1, HYPE on chain 999).destinationChainId*integerDestination chain id — any Across-supported EVM chain. (999 is HyperEVM, where same-token routes are passthrough.)amount*stringAmount in the input token's smallest unit, as an integer string. With tradeType=exactInput, this is the exact amount taken from the user's origin balance.tradeType?stringTrade execution strategy. exactInput is the default and only shape exercised in the canonical test suite.Default\"exactInput\"Value in\"exactInput\" | \"exactOutput\" | \"minOutput\"depositor*stringEVM address that signs the gasless authorization (and any lift steps). The server uses this as the EIP-712 signer when verifying signatures on submit. Must match the connected wallet.recipient*stringAddress that receives the output on the destination chain. EVM hex address.refundOnOrigin?booleanFor routes that include a destination swap (bridgeableToAny or anyToAny), destination refunds are the default behavior unless refundOnOrigin=true is explicitly set when calling the Swap API.\nAcross determines refund behavior based on the route type (when refundOnOrigin is NOT explicitly set):\n\nB2B or A2B routes:\n\nrefundOnOrigin defaults to true\nRefunds occur on the origin chain\nDestination refunds do not apply here\n\nB2A or A2A routes\n\nrefundOnOrigin defaults to false\nRefunds occur on the destination chain\n\nIf an explicit refundOnOrigin value is provided, that value is always respected.\nIf a refund occurs, the address that receives the refunded funds is determined using the following priority order: 1. refundAddress (if explicitly specified) 2. recipient (if specified) 3. depositor (fallback)\nThis applies to both origin and destination refunds.slippage?stringSlippage tolerance percentage can be set to auto (default) or a numerical value. Numerical value must be between 0 and 1 representing corresponding percentage. So if you want slippage to be 0.5% , you need to pass 0.005 as the value here). If slippage is auto, the Swap API will select the best slippage intelligently and move ahead with the crosschain swap. If slippage is set to a numerical value, for example 0.01 (1% slippage), it divides this value equally for each leg. This means 0.5% slippage for origin and 0.5% slippage for destination.Default\"auto\"appFee?numberEnables integrators to collect a customizable fee in the output token, sent to a designated address on the destination chain. appFee is expressed in percentage with value ranging between 0 and 1. For example, 1% appFee would use 0.01 as a value here.appFeeRecipient?stringEVM address that receives the app fee on the destination chain. Required if appFee > 0.skipChecks?booleanSkips source wallet checks and fetches a functional gasless swap quote.DefaultfalseResponse Bodyapplication/jsonapplication/jsonapplication/jsonapplication/jsoncurl -X GET \"https://across.to/api/swap/gasless?inputToken=0xaf88d065e77c8cC2239327C5EDb3A432268e5831&originChainId=42161&outputToken=0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913&destinationChainId=8453&amount=1000000&depositor=0xA4d353BBc130cbeF1811f27ac70989F9d568CeAB&recipient=0xA4d353BBc130cbeF1811f27ac70989F9d568CeAB\" \\\n -H \"Authorization: Bearer \"{\n \"depositId\": \"17583690609900675652552597580295147921193469959763873994384141350459846809617\",\n \"crossSwapType\": \"bridgeableToBridgeable\",\n \"amountType\": \"exactInput\",\n \"inputToken\": {\n \"decimals\": 6,\n \"symbol\": \"USDC\",\n \"address\": \"0xaf88d065e77c8cC2239327C5EDb3A432268e5831\",\n \"name\": \"USD Coin\",\n \"chainId\": 42161\n },\n \"outputToken\": {\n \"decimals\": 6,\n \"symbol\": \"USDC\",\n \"address\": \"0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913\",\n \"name\": \"USD Coin\",\n \"chainId\": 8453\n },\n \"refundToken\": {\n \"decimals\": 6,\n \"symbol\": \"USDC\",\n \"address\": \"0xaf88d065e77c8cC2239327C5EDb3A432268e5831\",\n \"name\": \"USD Coin\",\n \"chainId\": 42161\n },\n \"inputAmount\": \"1000000\",\n \"maxInputAmount\": \"1000000\",\n \"expectedOutputAmount\": \"1000000\",\n \"minOutputAmount\": \"1000000\",\n \"expectedFillTime\": 2,\n \"checks\": {\n \"allowance\": {\n \"token\": \"0xaf88d065e77c8cC2239327C5EDb3A432268e5831\",\n \"spender\": \"0x0000000000000000000000000000000000000000\",\n \"actual\": \"0\",\n \"expected\": \"0\"\n },\n \"balance\": {\n \"token\": \"0xaf88d065e77c8cC2239327C5EDb3A432268e5831\",\n \"actual\": \"9859704\",\n \"expected\": \"1000000\"\n }\n },\n \"steps\": {\n \"originSwap\": null,\n \"bridge\": {\n \"inputAmount\": \"1000000\",\n \"outputAmount\": \"1000000\",\n \"tokenIn\": {\n \"decimals\": 6,\n \"symbol\": \"USDC\",\n \"address\": \"0xaf88d065e77c8cC2239327C5EDb3A432268e5831\",\n \"name\": \"USD Coin\",\n \"chainId\": 42161\n },\n \"tokenOut\": {\n \"decimals\": 6,\n \"symbol\": \"USDC\",\n \"address\": \"0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913\",\n \"name\": \"USD Coin\",\n \"chainId\": 8453\n },\n \"fees\": {\n \"amount\": \"0\",\n \"token\": {\n \"decimals\": 6,\n \"symbol\": \"USDC\",\n \"address\": \"0xaf88d065e77c8cC2239327C5EDb3A432268e5831\",\n \"chainId\": 42161\n },\n \"pct\": \"0\"\n },\n \"provider\": \"across\"\n },\n \"destinationSwap\": null\n },\n \"fees\": {\n \"total\": {\n \"amount\": \"0\",\n \"amountUsd\": \"0.0\",\n \"token\": {\n \"decimals\": 6,\n \"symbol\": \"USDC\",\n \"address\": \"0xaf88d065e77c8cC2239327C5EDb3A432268e5831\",\n \"chainId\": 42161\n },\n \"pct\": \"0\"\n },\n \"totalMax\": {\n \"amount\": \"0\",\n \"amountUsd\": \"0.0\",\n \"token\": {\n \"decimals\": 6,\n \"symbol\": \"USDC\",\n \"address\": \"0xaf88d065e77c8cC2239327C5EDb3A432268e5831\",\n \"chainId\": 42161\n },\n \"pct\": \"0\"\n },\n \"originGas\": {\n \"amount\": \"0\",\n \"amountUsd\": \"0.0\",\n \"token\": {\n \"chainId\": 42161,\n \"address\": \"0x0000000000000000000000000000000000000000\",\n \"decimals\": 18,\n \"symbol\": \"ETH\"\n }\n },\n \"submission\": null\n },\n \"swapTx\": {\n \"ecosystem\": \"evm-gasless\",\n \"chainId\": 42161,\n \"to\": \"0x10D8b8DaA26d307489803e10477De69C0492B610\",\n \"data\": {\n \"type\": \"erc3009\"\n }\n },\n \"swapTxns\": null,\n \"quoteExpiryTimestamp\": 1781268647,\n \"id\": \"k6mf6-1781265149243-a6c306d24afe\"\n}{\n \"type\": \"AcrossApiError\",\n \"code\": \"AMOUNT_TOO_HIGH\",\n \"status\": 400,\n \"message\": \"Amount is higher than available liquidity. Max amount is 716928.917387 USDC.\",\n \"id\": \"vgcwv-1779284191168-cae95d247531\"\n}{\n \"type\": \"AcrossApiError\",\n \"code\": \"FORBIDDEN_API_KEY\",\n \"status\": 403,\n \"message\": \"Invalid or missing API key\"\n}{\n \"type\": \"AcrossApiError\",\n \"code\": \"INTERNAL_SERVER_ERROR\",\n \"status\": 500,\n \"message\": \"Internal server error\"\n}Create persistent deposit addresses POSTReturns a persistent, infinite-TTL deposit address. The same request parameters always resolve to the same address, so you can request it once and reuse it. Requires an API key with the `deposit-address` permission (Bearer auth).\n\nYou don't need to hardcode which chains you can deposit from (input chains), the API response will include that information in the `supportedInputs` field including the input token to send there, and that route's min/max limits.\n\n**Strongly provide `refundAddresses`.** It is optional, but if a deposit can't be completed and no refund address was supplied, funds can only be recovered through a **manual refund process that takes significantly longer** than the automatic refund. You would need to contact Across support to initiate the manual refund.Submit a signed gasless swap POSTSubmits the signatures for a gasless swap quote from `GET /swap/gasless`. For HyperCore origin routes (e.g. Hyperliquid withdrawals), the quote returns the steps to sign in `swapTxns[]`. Have the user sign each step, then submit `{ swapTx, swapTxns, signaturesByStepId }`. One signature per step, keyed by the step's stepId. Pass `swapTx` and `swapTxns` through from the quote unchanged. Across submits the transactions and covers the gas. Returns a depositId for tracking the deposit.","tokens":2126,"squid":"spider-09","role":"Bridge Spider","at":1791339271365,"hash":"adc9ff9f79fd7294515d19951533c7c2f45a9907"}
{"url":"https://forum.arbitrum.foundation/t/govhack-ethcc-brussels-2024-impact-report-hack-humanity/26530/19","domain":"forum.arbitrum.foundation","title":"GovHack ETHcc Brussels 2024 - Impact Report - Hack Humanity - Archive / GovHack Brussels - Arbitrum","text":"The Arbitrum Foundation notified the Security Council on the need to perform a potential Emergency action. Following a review of the details and known risks, the Security Council decided to execute the upgrade and it was completed at 11:30 EST on 2nd October 2026.\nThis report provides an overview of the risks that required the Security Council Action:\n\nAdd a permissionless guard for the One-Step Proof of BoLD on Arbitrum One\n\nTemporarily pause activation of new Stylus contracts on Arbitrum One & Nova\n\nKey point: To date, known bugs for Stylus primarily impact chain liveness (e.g., denial of service attacks) and do not put any user funds at risk.\nWhy was this action taken\nLet’s take this opportunity to explain why action was taken on two separate issues concerning BoLD and Stylus.\nInstalling the guard for One-Step Proof of BoLD. Given the rise of AI-assisted attacks, we have implemented a precautionary approach that allows anyone to pause settlement of Arbitrum One on Ethereum if there are at least two conflicting answers that pass at the same level in which only one should be valid and pass. This is to halt a class of publicly verifiable and detectable attacks that exploit a bug in the one-step proof. If halted, Arbitrum One will continue to process as normal except that messages from Arbitrum One to Ethereum, such as withdrawals, that are not yet confirmed will have to wait. This provides time for the Security Council to deploy a fix for the bug and resume the rollup.\nPreventing activation of new Stylus contracts. AI-assisted tooling has led to an increasing number of sophisticated attacks on hand-crafted WASM programs that do not use the standard Stylus compiler toolchain. These programs are specifically designed to cause unexpected behaviors such as degrading the chain’s performance for all other users. To date, no attacks have been discovered that permits theft of user funds.\nNew ArbOS releases have patched several reported bugs and known attacks over the past few months, but out of an abundance of caution, we have decided to temporarily pause new activations of Stylus contracts. This was executed as an emergency action to prevent the deployment of new hand-crafted WASM programs that are not yet patched by the current version of ArbOS on the Arbitrum network.\nThe Arbitrum Foundation has informed the Security Council that they will work with the ArbitrumDAO to discuss next steps on the timeline and manner for enabling activation of new Stylus contracts. The Arbitrum community remains confident in the value of Stylus and want to preserve these use cases while taking preventative measures against Stylus-based attack vectors as AI-assisted attack tooling continues to evolve.\nImpact on builders and users\n\nNo new activations. New Stylus contracts cannot be activated during the pause including new versions of existing applications that require activation.\n\nExisting contracts are not paused. Already-active Stylus contracts continue to execute until expiration. This pause does not deactivate them.\n\nThe ArbOS 61 upgrade renewed all active contracts on Arbitrum One, so no currently active contract expires before August 20, 2027.\n\nRenewal via keepalive stays permissionless and is unaffected by the pause.\n\nReactivating an expired contract, or one that needs to be updated after a Stylus version change, is paused.\n\nUsing/calling any activated Stylus contract stays permissionless for all users and developers.\n\nNo impact on EVM. Solidity (EVM) contract deployment and execution are unaffected by this Security Council action.\n\nSecurity Council Actions\nThere are two actions bundled into a single payload:\n\nOne-Step Proof Guard. The L1UpgradeExecutor gives a new pause contract (PauseExecutor) the ability to pause and nothing else. The new pause contract grants the guard (OspSoundnessGuard) PAUSER_ROLE to use it. Anyone can show the guard two conflicting answers to the same step of an open challenge. If the one-step proof accepts both, the guard has the pause contract put Arbitrum One’s settlement to Ethereum on hold.\n\nStylus deactivation. The Security Council called ArbOwner.setWasmActivationGas(2^64 - 1) to raise the Stylus activation gas requirement on Arbitrum One and Nova. This makes activation prohibitively expensive and effectively disables new activations. This is a configuration change and does not require an ArbOS upgrade.\n\nThe Security Council signed the following transactions to update the configuration:\n\nEthereum: Ethereum Transaction Hash: 0x30732bb7d2... | Etherscan\nArbitrum One:\nArbitrum One Transaction Hash: 0x9eb3a4be3b... | Arbitrum One\nArbitrum Nova:\nArbitrum Nova transaction 0x79e0fed470dff7a22059b108e3f8f42eddd2b580a6771594060c4e7326c5f984 | Blockscout\n\nAn external audit was conducted for the OSP Guard contracts. No audit is required for the Stylus deactivation as it is only updating a single parameter in the ArbOS configuration.\n\n ArchiveGovHack Brussels\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 16\n min\n\n Aug 2024\n\n 19 / 20\n\n Sep 2024\n\n Sep 2024\n\n post by KlausBrave on Aug 28, 2024\n\n post by julesfoa.eth on Aug 28, 2024\n\n post by KlausBrave on Aug 28, 2024\n\n post by ZER8 on Aug 28, 2024\n\n post by KlausBrave on Aug 28, 2024\n\n post by feems on Aug 28, 2024\n\n post by KlausBrave on Aug 28, 2024\n\n post by feems on Aug 28, 2024\n\n post by Frisson on Aug 28, 2024\n\n post by bianca on Aug 28, 2024\n\n post by JoJo on Aug 28, 2024\n\n post by paulofonseca on Aug 28, 2024\n\n post by tobsch on Aug 29, 2024\n\n post by kinaArb on Aug 29, 2024\n\n post by sid_areta on Aug 29, 2024\n\n post by KlausBrave on Aug 31, 2024\n\n post by ostanescu.eth on Sep 5, 2024\n\n ostanescu.eth\n\n Thank you @KlausBrave and the entire Hack Humanity team for pulling up such a great event.\nI am super greatful to have had the chance to be part and build alongside Arbitrum community.\nAt ETH Bucharest we are now in process of discussing a proposal that would bootstrap the local Arbitrum community and this is all thanks to the GovHack Brussels.\nI am also very greatful to have met such great people, and to my surprise bump into people that I didn’t know they are gonna be there. Which made me feel even more that I am in the right place.\nLooking forward to the next edition and hopefully we can organize something in Bucharest one day!\nCongrats and keep going! #LFG\n\n post by Gonzacolo on Sep 8, 2024\n\n Gonzacolo\n\n I appreciate the report. Being clear with the data and process is crucial.\nAs I’ve mentioned in other channels, initiatives like this are extremely complex to execute, and this is one of the few places where participants from the Arbitrum DAO can meet in person. Personally, I had the chance to meet some incredible people, and the relationships and trust we build by connecting face-to-face will significantly contribute to growing this ecosystem that we all support, enabling us to create better products and initiatives.\nI also think that narrowing the scope of the tracks could be beneficial. Some technical tracks, which I personally found interesting, didn’t seem to be fully aligned with the DAO’s goals and, in the end, weren’t particularly helpful for the DAO itself.\nI support the cross-activities that help us get to know each other, like those on the first day, but spread throughout the event. This would allow us to connect even more, including with the new participants.\nI look forward to it happening again and hope to participate in the future!\n\n post by KlausBrave on Sep 8, 2024\n\n KlausBrave\n\n Thank you @Gonzacolo.\nThe number of tracks is definitely a parameter we can change up/down to create a more focused event.\nBringing more cross-activities to get to know each other spread throughout the event is a great suggestion, I agree we can include more of this in the next one.\nIt was great to meet you Gonzacolo, thanks for coming.\n\n post by Mehdi_eth on Sep 9, 2024\n\n Mehdi_eth\n\n Unfortunately, I could not participate, but based on the pictures and videos, it looks quite exciting to learn and meet the experienced delegates. For the next event, I hope you consider offering an online version as well.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n GovHack ETHDenver 2024 - Impact Report - Hack Humanity\n\n GovHack Denver\n\n 9\n\n 1.6k\n\n Jun 2024\n\n GovHack at ETH CC (Brussels)\n\n Finalized AIPs\n\n 51\n\n 3.9k\n\n Aug 2024\n\n GovHack Devcon in Bangkok - Hack Humanity\n\n Archived Proposals\n\n 74\n\n 1.9k\n\n Oct 2024\n\n GovHack - ETHDenver powered by Hack Humanity\n\n GovHack Denver\n\n 9\n\n 2.5k\n\n May 2024\n\n ArbitrumDAO Off-site - Directional proposal\n\n Finalized AIPs\n\n 89\n\n 2.3k\n\n Oct 2024","tokens":2169,"squid":"spider-07","role":"Council Spider","at":1791339271408,"hash":"cec481aafdcec5f82bec72194165f362cc2421e8"}
{"url":"https://jobs.arbitrum.io/companies/arbitrum-2-257690d4-4404-495e-b8be-982cfb04bde0","domain":"jobs.arbitrum.io","title":"Arbitrum | Arbitrum Job Board","text":"Arbitrumarbitrum.ioLocationsGeorgetown, Washington, DC, USA · George Town, Cayman Islands · Cayman Islands · RemoteindustryBlockchain · Ethereum · Information Technology · Smart ContractsSize51 - 200 employeesStageOtherfounded in2023SocialsLinkedInCrunchbaseTwitterAboutArbitrum is responsible for creating a range of solutions that offer cost-effective smart contract environments, utilizing technology deeply connected to Ethereum.Something looks off?Open jobs at ArbitrumSearch by title or keywordOn-site & RemoteLocationJob functionSenioritySalaryPowered by GetroShowing 16 jobsSenior HR GeneralistLocation: RemotePosted: TodaySenior Backend EngineerLocation: RemoteCompensation: USD 193,461-291k / yearPosted: 12 daysSenior Investment LeadLocation: Cayman IslandsPosted: 14 daysSr. Associate, Corporate DevelopmentLocation: RemotePosted: 1 monthHead of Solutions EngineeringLocation: RemotePosted: 2 monthsSenior Backend Engineer, ZeroDev WalletLocation: RemotePosted: 3 monthsDirector of AccountingLocation: New York, NY, USACompensation: USD 180k-225k / yearPosted: 4 monthsVP of MarketingLocation: RemotePosted: 4 monthsSecurity EngineerLocation: RemotePosted: 5 monthsHead of EnterpriseLocation: RemotePosted: 5 monthsSenior Penetration Tester (AWS)Location: RemotePosted: 6+ monthsSenior Backend Engineer, NitroLocation: RemotePosted: 6+ monthsHead of FoundationLocation: Europe; Southern Asia; East Asia; Oceania; Europe, Paris, FrancePosted: 6+ monthsHead of Ecosystem GrowthLocation: Europe; Southern Asia; East Asia; Oceania; Europe, Paris, FrancePosted: 6+ monthsSite Reliability EngineerLocation: United StatesPosted: 6+ monthsDon't see the right role for you? Apply here!Location: Cayman IslandsPosted: 6+ months","tokens":432,"squid":"spider-01","role":"Chain Spider","at":1791339279023,"hash":"2c721cc3de26ae3ae6319d93a1a6c8322bfd8e19"}
{"url":"https://docs.phantom.com/developer-powertools/signing-a-message","domain":"docs.phantom.com","title":"Sign-In-With (SIW) standards - Phantom developer documentation","text":"Applications that rely on signMessage for authenticating users can choose to opt-in to one of the various Sign-In with (SIW) standards. If a message follows one of the supported standards, Phantom will verify required fields at the time of signing.\nAt the time of this writing, Phantom supports:\n\nSign-In with Solana (specification)\nSign-In with Ethereum (EIP-4361)\nSign-In with X (CAIP-122)\n\nThe serialized format of SIW messages is as follows:\n${domain} wants you to sign in with your ${blockchain} account:\n${address}\n\n${statement}\n\nURI: ${uri}\nVersion: ${version}\nChain ID: ${chain-id}\nNonce: ${nonce}\nIssued At: ${issued-at}\nExpiration Time: ${expiration-time}\nNot Before: ${not-before}\nRequest ID: ${request-id}\nResources:\n- ${resources[0]}\n- ${resources[1]}\n...\n- ${resources[n]}\n\nNameTypeRequired?DescriptiondomainstringtrueThe authority that is requesting the signing.addressstringtrueThe blockchain address that is performing the signing.statementstringfalseA human-readable ASCII assertion that the user will sign. It MUST NOT contain \\\\n.uristringtrueA URI referring to the resource that is the subject of the signing—that is, the subject of the claim.versionstringtrueThe current version of the message.chain-idstringtrueThe Chain ID to which the session is bound, and the network where Contract Accounts MUST be resolved.noncestringtrueA randomized token to prevent signature replay attacks.issued-atstringtrueThe issuance time.expiration-timestringfalseThe time at which the signed authentication message is no longer valid.not-beforestringfalseThe time at which the signed authentication message starts being valid.request-idstringfalseA system-specific identifier used to uniquely refer to the authentication request.resourcesstring[]falseA list of URIs the user wishes to have resolved as part of the authentication by the relying party.\n​Sign-In with Solana\nSee our specification and integration guide on GitHub.\nPhantom validates recognized Sign-In with Solana (SIWS) messages before displaying an approval prompt. Set the message domain to the requesting page’s exact host, including the port when present. When you provide a uri, its origin must match the requesting page’s origin. A mismatch returns error -32000 (Invalid Input) without prompting the user.\n​Sign-In with Ethereum\nThe Sign-In with Ethereum standard is defined by EIP-4361.\n​Examples\nsignMessage()\nconst provider = getProvider(); // see \"Detecting the Provider\"\nconst message = `magiceden.io wants you to sign in with your Ethereum account:\n0xb9c5714089478a327f09197987f16f9e5d936e8a\n\nClick Sign or Approve only means you have proved this wallet is owned by you.\n\nURI: https://magiceden.io\nVersion: 1\nChain ID: 1\nNonce: bZQJ0SL6gJ\nIssued At: 2022-10-25T16:52:02.748Z\nResources:\n- https://foo.com\n- https://bar.com`;\nconst encodedMessage = new TextEncoder().encode(message);\nconst signedMessage = await provider.signMessage(encodedMessage, \"utf8\");\n\nrequest()\nconst provider = getProvider(); // see \"Detecting the Provider\"\nconst message = `magiceden.io wants you to sign in with your Ethereum account:\n0xb9c5714089478a327f09197987f16f9e5d936e8a\n\nClick Sign or Approve only means you have proved this wallet is owned by you.\n\nURI: https://magiceden.io\nVersion: 1\nChain ID: 1\nNonce: bZQJ0SL6gJ\nIssued At: 2022-10-25T16:52:02.748Z\nResources:\n- https://foo.com\n- https://bar.com`;\nconst encodedMessage = new TextEncoder().encode(message);\nconst signedMessage = await provider.request({\n method: \"signMessage\",\n params: {\n message: encodedMessage,\n display: \"utf8\",\n }\n});\n\n​Sign-In with X\nThe Sign-In with X standard is defined by CAIP-122. It uses CAIP-10 identifiers for the address field and CAIP-2 for chain-id.\nWhile CAIP-122 is technically chain-agnostic, only Ethereum and Solana parsing are supported at this time.\n​Ethereum example\nsignMessage()\nconst provider = getProvider(); // see \"Detecting the Provider\"\nconst message = `magiceden.io wants you to sign in with your Ethereum account:\neip155:1:0xb9c5714089478a327f09197987f16f9e5d936e8a\n\nClick Sign or Approve only means you have proved this wallet is owned by you.\n\nURI: https://magiceden.io\nVersion: 1\nChain ID: eip155:1\nNonce: bZQJ0SL6gJ\nIssued At: 2022-10-25T16:52:02.748Z\nResources:\n- https://foo.com\n- https://bar.com`;\nconst encodedMessage = new TextEncoder().encode(message);\nconst signedMessage = await provider.signMessage(encodedMessage, \"utf8\");\n\nrequest()\nconst provider = getProvider(); // see \"Detecting the Provider\"\nconst message = `magiceden.io wants you to sign in with your Ethereum account:\neip155:1:0xb9c5714089478a327f09197987f16f9e5d936e8a\n\nClick Sign or Approve only means you have proved this wallet is owned by you.\n\nURI: https://magiceden.io\nVersion: 1\nChain ID: eip155:1\nNonce: bZQJ0SL6gJ\nIssued At: 2022-10-25T16:52:02.748Z\nResources:\n- https://foo.com\n- https://bar.com`;\nconst encodedMessage = new TextEncoder().encode(message);\nconst signedMessage = await provider.request({\n method: \"signMessage\",\n params: {\n message: encodedMessage,\n display: \"utf8\",\n }\n});\n\n​Solana example\nsignMessage()\nconst provider = getProvider(); // see \"Detecting the Provider\"\nconst message = `magiceden.io wants you to sign in with your Solana account:\nsolana:mainnet:FYpB58cLw5cwiN763ayB2sFT8HLF2MRUBbbyRgHYiRpK\n\nClick Sign or Approve only means you have proved this wallet is owned by you.\n\nURI: https://magiceden.io\nVersion: 1\nChain ID: solana:mainnet\nNonce: bZQJ0SL6gJ\nIssued At: 2022-10-25T16:52:02.748Z\nResources:\n- https://foo.com\n- https://bar.com`;\nconst encodedMessage = new TextEncoder().encode(message);\nconst signedMessage = await provider.signMessage(encodedMessage, \"utf8\");\n\nrequest()\nconst provider = getProvider(); // see \"Detecting the Provider\"\nconst message = `magiceden.io wants you to sign in with your Solana account:\nsolana:mainnet:FYpB58cLw5cwiN763ayB2sFT8HLF2MRUBbbyRgHYiRpK\n\nClick Sign or Approve only means you have proved this wallet is owned by you.\n\nURI: https://magiceden.io\nVersion: 1\nChain ID: solana:mainnet\nNonce: bZQJ0SL6gJ\nIssued At: 2022-10-25T16:52:02.748Z\nResources:\n- https://foo.com\n- https://bar.com`;\nconst encodedMessage = new TextEncoder().encode(message);\nconst signedMessage = await provider.request({\n method: \"signMessage\",\n params: {\n message: encodedMessage,\n display: \"utf8\",\n }\n});\n\nPhantom uses Ed25519 signatures for Solana message signatures. To verify a message signature, you can use the tweetnacl npm package.Was this page helpful?","tokens":1613,"squid":"spider-10","role":"Tooling Spider","at":1791339282823,"hash":"9762a82d4652abb8de251c930dc8851565429c43"}
{"url":"https://docs.phantom.com/developer-powertools/token-pages","domain":"docs.phantom.com","title":"Token pages - Phantom developer documentation","text":"Phantom provides shareable, web-accessible token pages that display detailed token information. These pages provide a seamless experience whether accessed through the Phantom wallet app or via web browsers.\n​Generate a token page URL\nTo create a shareable token page URL:\n\nOpen the desired token page in Phantom.\nTap the share button.\nCopy or share the generated URL.\n\nThe URL follows this format:\nhttps://phantom.com/tokens/<chain>/<token_address>\n\nFor example, the WIF token on Solana can be accessed at:\nhttps://phantom.com/tokens/solana/EKpQGSJtjMFqKZ9KQanSqYXRcF8fBopzLHYxdM65zcjm\n\n​Key features\n​Universal and deep linking\nWhen accessed on mobile devices with Phantom installed, token page URLs automatically open the corresponding details page within the Phantom app. For users without Phantom installed, the links gracefully fallback to the web view.\n​Quick access to swapper\nThe web view includes a QR code that, when scanned, deep links directly to the token’s swap screen within the Phantom app. This enables quick and convenient token swaps for mobile users.\n\n​Enhanced social sharing\nEach token page generates dynamic OpenGraph images that display essential token information and price charts. When shared on social media platforms, these rich previews provide immediate context about the token’s performance and status.\nWas this page helpful?","tokens":339,"squid":"spider-10","role":"Tooling Spider","at":1791339294141,"hash":"e831c45407a1db45ad1a4feb6b7386d8a14a3e4c"}
{"url":"http://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.3B+ Total Value SecuredSource A testament to the trust and liquidity driving the next era of blockchain innovation.467.2K+ 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":"spider-01","role":"Chain Spider","at":1791339294314,"hash":"6a6d34a91c2341943c0a6d02e52162927abe455d"}
{"url":"https://docs.phantom.com/developer-powertools/lighthouse","domain":"docs.phantom.com","title":"Transaction Validation - Phantom developer documentation","text":"When building with Phantom, you may see transactions that include Lighthouse assertion instructions. Lighthouse is a Solana program that adds runtime checks to transactions. These checks validate onchain state and will cause the transaction to fail if conditions aren’t met.\nThese assertions are included to ensure user safety by protecting against unexpected outcomes like simulation spoofing or malicious transaction manipulation.\n​What this means for your transactions\nWhen you submit a transaction to Phantom, it may be augmented with Lighthouse assertion instructions before being submitted to the network. This means that if you’re checking transactions onchain as part of your confirmation flow, you should be aware that the transaction onchain will be different from what you originally submitted.\nAdditionally, these assertions can cause a transaction to fail even when it would otherwise execute successfully. For example, if a swap transaction includes an assertion checking for a specific token balance and the actual balance differs, the entire transaction will fail.\nYou don’t need to do anything special to handle these assertions. They’re included in the transaction by Phantom and are processed automatically onchain.\n​Additional information\nFor guidance on handling transaction warnings and best practices, see Domain and transaction warnings.Was this page helpful?","tokens":346,"squid":"spider-10","role":"Tooling Spider","at":1791339305358,"hash":"68ccc537288cf7295b39d7aa96cdd0eb46357a2b"}
{"url":"https://docs.phantom.com/resources/mcp-server","domain":"docs.phantom.com","title":"Phantom Connect SDK MCP server - Phantom developer documentation","text":"​Overview\nThe Phantom Connect SDK MCP (Model Context Protocol) server connects AI coding assistants like Cursor, Claude, and VS Code to Phantom developer documentation. Your AI assistant can answer questions and generate code with accurate, up-to-date context.\nLooking for the MCP server that gives AI agents direct access to Phantom wallet operations like signing transactions and transferring tokens? See the Phantom MCP server documentation.\nMCP is an open protocol that allows AI applications to securely connect to external data sources and tools. Learn more about MCP at modelcontextprotocol.io.\n​Quick install\nUse the contextual menu at the top of any documentation page to quickly connect to your preferred tool:\n\nCopy MCP server URL: Copy the URL to your clipboard.\nConnect to Cursor: Automatically install in Cursor.\nConnect to VS Code: Automatically install in VS Code.\n\n​Features\nThe Phantom Connect SDK MCP server provides:\n\nSearchPhantomDeveloper: Search across Phantom developer documentation for relevant information, code examples, API references, and guides.\n\n​Setup guides\n Cursor VS Code Claude Claude Code​Option 1: Cursor plugin (recommended)Install the Phantom Cursor plugin for the best experience. It includes this MCP server plus subagents, skills, and rules for building with Phantom. See the Cursor plugin documentation for details.​Option 2: Quick installUse the contextual menu at the top of this page and select Connect to Cursor to automatically install the MCP server.​Option 3: Manual setup1Open MCP settingsUse Cmd + Shift + P (Mac) or Ctrl + Shift + P (Windows/Linux) to open the command palette, then search for Open MCP settings.2Configure the Phantom Connect SDK MCP serverAdd the following to your mcp.json file:{\n \"mcpServers\": {\n \"phantom-docs\": {\n \"type\": \"sse\",\n \"url\": \"https://docs.phantom.com/mcp\"\n }\n }\n}\nIf you already have other MCP servers configured, add phantom-docs to your existing mcpServers object.3Verify the connectionIn Cursor’s chat, ask “What tools do you have available?”—Cursor should show the Phantom Connect SDK MCP server as an available tool.See the Cursor MCP documentation for more details.​Option 1: Quick installUse the contextual menu at the top of this page and select Connect to VS Code to automatically install the MCP server.​Option 2: Manual setup1Create the MCP configuration fileCreate a .vscode/mcp.json file in your project directory.2Configure the Phantom Connect SDK MCP serverAdd the following configuration:{\n \"servers\": {\n \"phantom-docs\": {\n \"type\": \"http\",\n \"url\": \"https://docs.phantom.com/mcp\"\n }\n }\n}\n3Verify the connectionThe MCP server should now be available in VS Code’s AI features.See the VS Code MCP documentation for more details.1Open Claude settingsNavigate to the Connectors page in your Claude settings.2Add the Phantom Connect SDK MCP server\nSelect Add custom connector\nEnter the following details:\n\nName: Phantom Docs\nURL: https://docs.phantom.com/mcp\n\nSelect Add\n3Use the MCP serverWhen using Claude:\nSelect the attachments button (the plus icon)\nSelect the Phantom Docs connector\nAsk Claude questions about Phantom integration\nSee the Claude MCP documentation for more details.​Install via command lineRun the following command to add the Phantom Connect SDK MCP server to Claude Code:claude mcp add --transport http phantom-docs https://docs.phantom.com/mcp\n​Verify the installationCheck that the server was added successfully:claude mcp list\nSee the Claude Code documentation for more details.\n​Usage\nOnce configured, your AI assistant can search Phantom documentation when you ask questions about:\n\nPhantom SDK integration (React, React Native, Browser)\nWallet connection and authentication flows\nTransaction signing and sending\nMessage signing for authentication\nMulti-chain integration documentation for Solana, Ethereum, and Bitcoin, plus Sui deprecation guidance\nPhantom Portal setup and configuration\nBest practices and troubleshooting\n\n​Example prompts\nTry asking your AI assistant:\n\n“How do I set up Phantom Connect in a React app?”\n“Show me how to sign a message with the Phantom Browser SDK”\n“What’s the process for verifying a domain in Phantom Portal?”\n“How do I send a Solana transaction using Phantom?”\n\nThe AI will search Phantom documentation and respond with accurate answers and code examples.\n​Server details\nPropertyValueServer namePhantom Connect SDK MCP serverVersion1.0.0TransportSSE (Server-Sent Events)Endpointhttps://docs.phantom.com/mcp\n​Available tools\nToolDescriptionSearchPhantomDeveloperSearch across the Phantom developer documentation knowledge base to find relevant information, code examples, API references, and guides\n​Troubleshooting\nServer shows as disconnected in Cursor\nMake sure you include \"type\": \"sse\" in your Cursor configuration\nVerify you have an active internet connection\nCheck that the URL is exactly https://docs.phantom.com/mcp\nTry removing and re-adding the server\nRestart Cursor completely\nAI doesn't use the documentation\nMake sure the MCP server shows a green status indicator\nTry explicitly asking about Phantom (e.g., “Using Phantom docs, how do I…”)\nVerify the server is enabled in your settings\nIn Cursor, ask “What tools do you have available?” to verify the connection\nConfiguration file not found\nCursor: The mcp.json file is located at ~/.cursor/mcp.json (Mac/Linux) or %APPDATA%\\Cursor\\mcp.json (Windows)\nVS Code: Create .vscode/mcp.json in your project directory\nIf the file doesn’t exist, create it with the configuration shown above\nClaude connector not working\nMake sure you’re using the correct URL: https://docs.phantom.com/mcp\nTry removing and re-adding the connector\nCheck the Claude Connectors page to verify the connector is added\n\n​Related resources\nWas this page helpful?","tokens":1440,"squid":"spider-10","role":"Tooling Spider","at":1791339316660,"hash":"557bdd16789a9671c77be75afd94b74c55b5b661"}
{"url":"https://arbitrum.io/solutions/finance","domain":"arbitrum.io","title":"Arbitrum for Finance – Onchain Infrastructure for Institutions & DeFi","text":"Where FinanceMoves 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.Get in Touchyour onchain railsBuild for What's Next in FinanceFrom tokenizing real-world assets to engineering advanced trading systems and payment rails, Arbitrum provides a scalable infrastructure to power the future of financial services.Start BuildingSplit AssetAsset Tokenization (RWA)Tokenize assets and bonds onchain to enable instant settlement, expand collateralization options, and attract new liquidity for traditionally illiquid instruments.Treasury & PaymentsPower fast, low-cost payouts and collections with tokenized balances and deposits. Explore Arbitrum’s financial infrastructure to improve liquidity management, optimize yield on idle funds, and streamline treasury operations.Scheduled Trade2PM, May 160.0000072Capital Markets & TradingBuild advanced onchain exchanges and derivatives with sub-second speeds, onchain liquidity, and support for high-frequency trading strategies.Engineered for FinanceApplications and chains require a new infrastructure model. Arbitrum is the battle-tested platform offering scale and decentralization.The Onchain Standard$11.3B+ Total Value SecuredSource A testament to the capital relying on Arbitrum’s infrastructure for execution and long-term growth.$1.2B+ Stablecoin Transaction VolumeSource Arbitrum has become a key stablecoin rail for payments, settlements, and treasury operations.$11.1B+ Gas Fees SavedSource Arbitrum’s low-cost infrastructure keeps more value with users and companies for sustainable growth.View Live DataAdvanced User ProtectionGive users predictable transaction settlement backed by Ethereum’s security. Reduce execution risk and provide a transparent, auditable record for high-value financial flow.Launch, Grow, OwnMove fast and get your app live on Arbitrum One with onchain liquidity, then scale to your own chain with end-to-end control over product design, implementation details, fee models, and access controls.Enterprise Compliance & SafetyArbitrum lets you bring your existing compliance stack onchain. Encode business rules, from KYC/AML and OFAC screening to custom compliance logic, using the providers and workflows you already trust.Case StudiesProven in Production, Trusted at ScaleArbitrum is more than a platform; it's a thriving onchain economy. Learn why the world's most sophisticated financial protocols and institutions are building their future here.Robinhood is realizing the crypto visionFranklin TempletonUSD.AIUSDCUSDT0MorphoCamelotUniswapPlume NetworkRobinhoodFluidSecuritizeAavePendleGMXVariationalOstiumThe clear choiceJoin the growing network of financial apps and institutions bringing their visions to life.Explore the EcosystemStart 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":821,"squid":"spider-01","role":"Chain Spider","at":1791339328031,"hash":"78fe670e33642ee933c4c70614788bc8ff4c1b02"}
{"url":"https://docs.phantom.com/developer-powertools/ai-tools","domain":"docs.phantom.com","title":"AI-assisted development - Phantom developer documentation","text":"Your AI coding assistant can search Phantom documentation for accurate, up-to-date answers while you build.\n​AI tools\n\nClaude integration: Every documentation page includes an “Open in Claude” button in the contextual menu for quick implementation help.\n​Phantom Cursor plugin\nThe Phantom Cursor plugin is the fastest way to start building with Phantom in Cursor. It bundles subagents, skills, rules, and MCP servers into a single install so your AI agent can scaffold projects, write integration code, execute wallet operations, and follow Phantom best practices automatically.\nInstall it from the Cursor Marketplace or by searching for phantom-connect in Cursor’s Add Plugin command.\nThe plugin includes:\n\nTwo subagents for integration code generation and wallet operations\nSeven skills for scaffolding React, React Native, and Browser SDK projects\nThree rules for SDK best practices and transaction safety\nTwo MCP servers for documentation search and wallet operations\n\n​MCP server\nThe Phantom MCP server (@phantom/mcp-server) lets AI assistants interact with Phantom embedded wallets through natural language. AI agents can view wallet addresses, sign transactions, transfer tokens, swap tokens, rebalance portfolios, and trade perps on Hyperliquid across Solana, Ethereum, Bitcoin, and Sui.\nSui support has been deprecated.\n​Quick setup (Claude Desktop)\n{\n \"mcpServers\": {\n \"phantom\": {\n \"command\": \"npx\",\n \"args\": [\"-y\", \"@phantom/mcp-server@latest\"]\n }\n }\n}\n\nNo App ID or Phantom Portal setup is required. On first use, a browser window opens for device-code sign-in.\n\n​Phantom Connect SDK MCP server\nThe Phantom Connect SDK MCP server connects AI coding assistants to Phantom developer documentation. Your AI assistant can answer questions and generate code with accurate, up-to-date context.\n​Setup\nToolOne-clickManualCursorClick “Connect to Cursor” on any docs pageAdd to ~/.cursor/mcp.jsonVS CodeClick “Connect to VS Code”Add to .vscode/mcp.jsonClaude.ai—Add connector in SettingsClaude Code—claude mcp add --transport http phantom-docs https://docs.phantom.com/mcp\n​Configuration\nAdd this configuration to your MCP settings:\nmcp.json{\n \"mcpServers\": {\n \"phantom-docs\": {\n \"type\": \"sse\",\n \"url\": \"https://docs.phantom.com/mcp\"\n }\n }\n}\n\n​Example prompts\nOnce configured, try asking your AI assistant:\n\n“How do I set up Phantom Connect in a React app?”\n“Show me how to sign a message with the Browser SDK.”\n“What’s the process for verifying a domain in Phantom Portal?”\n“How do I handle transaction errors in React Native?”\n\n​Cursor AI prompts\nUse one-shot prompts with Cursor AI to generate Phantom SDK implementations. Each prompt covers wallet connection, message signing, and transaction handling.\n​Available prompts\nSDKWhat it generatesReact SDKComplete app with wallet connection, message signing, SOL transfersReact Native SDKMobile app with Expo, OAuth flow, native wallet functionalityBrowser SDKVanilla JS implementation for any web framework\n​How to use\n1Get App ID from Phantom PortalVisit Phantom Portal to get your App ID before using any prompt.2Copy prompt for your SDKOpen the Cursor AI prompts page and copy the prompt for your preferred SDK (React, React Native, or Browser).3Replace placeholdersReplace [YOUR_APP_ID] and [YOUR_REDIRECT_URL] (or [YOUR_SCHEME] for React Native) with your actual values.4Paste into CursorOpen Cursor AI, press Cmd+K (or Ctrl+K on Windows), and paste the complete prompt.5Review and runCursor will generate a full implementation. Review the code, then run and test your integration.\n\n​Best practices\n​Provide context\nGive your AI assistant context to generate accurate code. Include:\n\nYour target framework (React, React Native, or vanilla JS)\nSpecific features you need (wallet connection, transactions, message signing)\nGeneral app structure and requirements\n\nSecurity best practice: Avoid sharing sensitive information like App IDs, redirect URLs, or API keys with AI assistants. Use placeholders like [YOUR_APP_ID] in prompts, then replace them with actual values in your code after generation.\nExample of a good prompt:\nI'm building a React app with Phantom Connect. I need to:\n1. Connect a wallet using social login\n2. Sign messages for authentication\n3. Send SOL transactions\n\nI'll replace [YOUR_APP_ID] and [YOUR_REDIRECT_URL] placeholders with my actual values after the code is generated.\n\n​Combine tools\nUse MCP server for questions and documentation lookups, then use Cursor prompts for scaffolding complete implementations:\n\nAsk questions first: Use MCP server to understand concepts (“How does Phantom Connect authentication work?”).\nGenerate code: Use Cursor prompts to scaffold your implementation.\nRefine with MCP: Ask follow-up questions to customize the generated code.\n\n​Verify generated code\nAlways review AI-generated code before deploying:\n\nCheck App ID matches your Phantom Portal app.\nVerify redirect URLs are allowlisted in Phantom Portal.\nEnsure error handling is present for all async operations.\nConfirm lamports are calculated correctly (1 SOL = 1,000,000,000 lamports).\nTest wallet connection flow end-to-end.\nValidate transaction amounts and recipient addresses.\n\n​Resources\nWas this page helpful?","tokens":1297,"squid":"spider-10","role":"Tooling Spider","at":1791339328075,"hash":"6341607fada366cc141f70eef143d6d96ea40dc0"}
{"url":"https://docs.phantom.com/resources/cursor-plugin","domain":"docs.phantom.com","title":"Phantom Cursor plugin - Phantom developer documentation","text":"The Phantom Cursor plugin gives your AI coding agent everything it needs to build with Phantom. It bundles MCP servers, subagents, skills, and rules into a single install so Cursor can scaffold projects, write integration code, execute wallet operations, and follow Phantom best practices automatically.\nThe plugin is available on the Cursor Marketplace. Install it directly from Cursor or visit the marketplace page.\n​Install\nAdd the plugin to Cursor using the command palette or the marketplace:\n1Open the command palettePress Cmd + Shift + P (Mac) or Ctrl + Shift + P (Windows/Linux) and search for “Add Plugin”.2Search for Phantom ConnectType phantom-connect and select Phantom Connect from the results.3Confirm installationCursor will add the plugin. You may need to restart Cursor for all features to activate.\nYou can also install by visiting cursor.com/marketplace/phantom and selecting Add to Cursor.\nSui support has been deprecated.\n​What’s included\nThe plugin bundles four categories of capabilities into one install.\n​Subagents\nSpecialized AI agents that Cursor can delegate tasks to:\nSubagentDescriptionphantom-integration-specialistScaffolds projects, writes correct integration code, validates against SDK constraints, and searches Phantom docs in real timephantom-wallet-agentExecutes wallet operations: address and balance reads across Solana, EVM, Bitcoin, and Sui; transfers, swaps, simulation, and signing on Solana and EVM; ERC-20 allowance checks on EVM; portfolio rebalancing on Solana; Hyperliquid perps; and CASH API payments\n​Skills\nStep-by-step workflows the agent follows to complete common tasks:\nSkillDescriptionsetup-react-appScaffold a React app with Phantom Connect SDK, including social login and Solana supportsetup-react-native-appScaffold a React Native (Expo) app with Phantom React Native SDK, including polyfills and deep linkingsetup-browser-appScaffold a vanilla JS/TS app with Phantom Browser SDK, without any framework dependencyadd-social-loginConfigure Google and Apple social login with Phantom Connect SDK to enable embedded wallet creationsend-sol-transactionBuild and send SOL transfers with Phantom Connect SDK, including transaction construction, signing, and verificationsign-messageImplement message signing with Phantom Connect SDK for Solana and EVM, including Sign-in with Solana (SIWS) authenticationphantom-wallet-mcpExecute wallet operations through the Phantom MCP server: multi-chain address and balance reads (Solana, EVM, Bitcoin, Sui); transfers, swaps, simulation, and signing on Solana and EVM; EVM allowance checks; Solana-only portfolio rebalancing; Hyperliquid perps; and CASH API payments\n​Rules\nConstraints and best practices the agent applies automatically when generating code:\nRuleDescriptionembedded-wallet-constraintsConstraints and limitations for Phantom embedded walletsphantom-sdk-best-practicesGeneral best practices for using Phantom Connect SDKssolana-transaction-safetySafety rules for Solana transaction handling with Phantom\n​MCP servers\nTwo MCP servers are bundled with the plugin:\nMCP serverDescriptionphantom-connect-sdkGives Cursor real-time access to Phantom developer documentation for accurate answers and code generationphantom-mcpGives Cursor direct access to Phantom embedded wallet operations: address and balance reads across Solana, EVM, Bitcoin, and Sui; transfers, swaps, simulation, and signing on Solana and EVM; EVM allowance checks; Solana-only portfolio rebalancing; Hyperliquid perps; and CASH API payments. Uses Phantom’s device-code authentication flow.\n​Usage examples\nOnce installed, you can ask Cursor to perform Phantom-related tasks directly:\nScaffold a new project:\nCreate a React app with Phantom Connect that supports Google social login and SOL transfers\n\nAdd wallet features to an existing project:\nAdd Phantom wallet connection and message signing to my existing React app\n\nExecute wallet operations:\nGet my Phantom wallet addresses across all chains\n\nTransfer 0.1 SOL to H8FpYTgx4Uy9aF9Nk9fCTqKKFLYQ9KfC6UJhMkMDzCBh\n\nAsk documentation questions:\nHow do I verify a domain in Phantom Portal?\n\nWhat are the spending limits for embedded wallets?\n\n​How it works\nThe plugin enhances Cursor’s AI agent in three ways:\n\nContext: The MCP servers give the agent access to Phantom documentation and wallet operations, so it generates accurate code instead of hallucinating APIs.\nWorkflows: Skills provide step-by-step instructions for common integration tasks, ensuring the agent follows the correct setup order and includes all dependencies.\nGuardrails: Rules enforce SDK best practices and safety constraints automatically, so the agent avoids common mistakes like missing polyfills or unsafe transaction patterns.\n\n​Prerequisites\nInstall the plugin, then complete the Phantom device-code authentication flow in the browser the first time Cursor performs a wallet action.\nIf you use the project scaffolding skills to build a separate Phantom app integration, the generated application may still prompt you for project-specific SDK configuration later. That is separate from using the plugin itself.\n​Related resources\nWas this page helpful?","tokens":1288,"squid":"spider-10","role":"Tooling Spider","at":1791339351107,"hash":"620c91167363f8b8e9fe87d2878d27c6ec6ddf7c"}
{"url":"https://akash.network/blog/","domain":"akash.network","title":"Akash Network Blog - Insights into Decentralized Cloud Computing","text":"All Jul 28, 2026 Product Confidential Compute Comes to Akash By Greg Osuri 6 min read Jun 2, 2026 News The Home Is the New Datacenter: Two Visions for Distributed AI Compute By Michelle Javed 6 min read May 16, 2026 News 5 New Exciting AI Apps Built on Akash in 2026 By Michelle Javed 8 min read May 5, 2026 Product Introducing Console Air: Self-Host, Self-Custody Akash By Maxime Beauchamp 5 min read Apr 16, 2026 News AI's Infrastructure Problem Is Bigger Than the Grid By Michelle Javed 7 min read Apr 1, 2026 News Akash Network: Q1 2026 Report By Michelle Javed 10 min read Mar 18, 2026 Economics What Burn-Mint Equilibrium Means for Akash By Michelle Javed 8 min read Feb 17, 2026 Insights The Permissionless Shortcut: Why Ambassador Programs are the New Web3 Internship By Shelby Perris 6 min read Jan 9, 2026 News Akash: 2025 Year in Review By Michelle Javed 25 min read Dec 31, 2025 News Akash Network: Q4 2025 Report By Michelle Javed 6 min read Dec 4, 2025 News Introducing the Akash Student Ambassador Program: A New Chapter for Decentralized Cloud By Shelby Peris 5 min read Nov 22, 2025 Product AkashML: Managed AI Inference on the Decentralized Supercloud By Anil Murty 5 min read","tokens":299,"squid":"spider-03","role":"Compute Spider","at":1791339367160,"hash":"3d4f0e85cd5a03ab1bcd25af0f3b4fd332e870b2"}
{"url":"https://paradigm.xyz/kryptos-ctf/rules","domain":"paradigm.xyz","title":"Kryptos CTF Rules: $10,000 in Prizes","text":"KryptosRulesKryptos CTFAll PuzzlesLeaderboardRulesCTF Challenge: Rules of the GameChallengesThere are 10 independent CTF challenges — Paradigm Kryptos 1 through 10 (PK1-PK10). Each challenge is a separate competition with its own $1,000 prize.Challenges are open to all registered participants for the duration of the event. There is no limit on the number of solve attempts.The first individual to submit a correct solution for a given challenge wins that challenge's prize. Second-place and later solves do not receive a payout.Leaderboard & ScoringWinners are tracked in real time on the public online leaderboard. Rankings update immediately upon a valid submission being confirmed.A submission is only confirmed after the flag or solution has been verified by the judging system. Timestamps are recorded at the moment of successful verification, not at the time of submission.In the event of a tie (simultaneous submissions within the same second), judges will review server-side logs to determine the final order.PrizesPrize distribution details and KYC requirements will be communicated to winners directly after the event closes.Prizes are awarded per challenge — an individual may win multiple challenges.NO ENTRY FEE IS REQUIRED TO PARTICIPATE IN OR SUBMIT SOLUTIONS FOR THE TEN (10) PRIZE-BEARING CTF PUZZLES. K4 submissions may require payment of a $1 submission fee through Stripe or another payment method or payment processor designated by Sponsor, but no prize will be awarded for K4 unless Sponsor states otherwise. To participate in the Paradigm CTF Challenge (the “Contest”), eligible participants must visit http://paradigm.xyz/kryptos-ctf during the Contest Period, create or log into an account if required, agree to the Official Rules and applicable terms, and submit a solution to one or more cryptography puzzles or challenges in accordance with Sponsor's instructions. This is a skill-based cryptography puzzle contest. Winners will be determined based on objective skill-based performance, as described in the Official Rules, and not by random drawing or chance. The Contest begins when Sponsor announces that the Contest is open on or about the morning of Friday, June 12, 2026, and continues until all ten (10) prize-bearing CTF puzzles or challenges have been solved, Sponsor ends the Contest, or as otherwise described in the Official Rules. The Contest is open globally, except where prohibited by law or restricted by sanctions, export controls, or other legal restrictions, to individuals of all ages, including minors, subject to the Official Rules. If a participant is under eighteen (18) years of age or under the age of majority in the participant's jurisdiction of residence, Sponsor may require parent or legal guardian consent, documentation, releases, KYC or identity verification, tax documentation, payment information, publicity/IP consent, sanctions/export-control screening, and other verification or fulfillment materials before participation, continued participation, prize eligibility, or prize fulfillment. Participation may be by individuals or teams, as permitted by Sponsor and described in the Official Rules. One or more prizes may be awarded, including $1,000 USD cash challenge prizes for PK1-PK10 / the ten prize-bearing CTF puzzles. Total ARV of all prizes is up to $10,000 USD. No prize will be awarded for K4 unless Sponsor states otherwise. Sponsor may require winner verification, KYC or other identity verification, tax documentation, sanctions/export-control screening, payment information, parent or legal guardian documentation if applicable, and other required documents before awarding any prize.Official Rules: paradigm.xyz/kryptos-ctf/official-rulesSponsor: Paradigm Operations LP. This Contest is not sponsored, endorsed, or administered by any social media platform or other third-party platform or service on which the Contest may be promoted, accessed, administered, or discussed, including X (formerly Twitter), Discord, GitHub, Stripe, or any other third-party platform or service identified in Contest-related materials. Stripe or another payment method or payment processor designated by Sponsor may be used to process K4 submission-fee payments, if applicable, but no such payment processor is a sponsor of the Contest.","tokens":1075,"squid":"spider-04","role":"Research Spider","at":1791339367190,"hash":"4fb17a6611d17fd14943d673845c15bc3958717a"}
{"url":"https://jup.ag/perps","domain":"jup.ag","title":"117.63 - SOL","text":"SOL250xMark Price$117.6324H Change-2.31%24H Vol$103.47M24H High$121.9924H Low$117.01Available Liq.$10.00MBorrow Rate0.0016% / hr\n Positions on chartPositionEntry / Mark PriceLiq. PriceSizeCollateralTP / SLConnect your wallet to see your trades$117.63You're payingEntry Price-Liquidation Price-SlippageTotal Feesborrow fees due:--Up or Down on SOL, BTC, ETHwith Jupiter Prediction Markets5mLiveSOL Up or Down 5mPrice to beat: $117.658Down54%Down 54%Up 47%Down 54%Up 47%Trade5mLiveBTC Up or Down 5mPrice to beat: $83,919.08Down53%Down 53%Up 49%Down 53%Up 49%Trade5mLiveETH Up or Down 5mPrice to beat: $2,612.39Up53%Up 53%Down 48%Up 53%Down 48%TradeJupiter Perps","tokens":165,"squid":"spider-02","role":"Liquidity Spider","at":1791339374177,"hash":"c9f8285c111464e255d1b3b51466a0c5d600e889"}
{"url":"https://akash.network/blog/home-is-the-new-datacenter","domain":"akash.network","title":"The Home Is the New Datacenter: Two Visions for Distributed AI Compute","text":"TL;DR: NVIDIA’s partnership with Span and PulteGroup installs GPU cabinets on new-construction homes. Akash Homenode takes the opposite approach — software only, works with GPUs you already own, no new construction or homeownership required. Both validate the same thesis: distributed home compute is the solution to centralized AI’s energy wall.\n\nFor the last decade, scaling AI meant one thing: build bigger datacenters. Pour billions into hyperscale facilities. Negotiate with utility companies for hundreds of megawatts. Quietly hope the local grid can handle it.\nHowever, that model is breaking.\nPower constraints, zoning battles, water usage controversies, and political pushback have made the traditional datacenter buildout slower and more expensive than the AI industry can tolerate. Demand for compute is growing faster than the grid can support new centralized facilities.\nThe answer is becoming clear: the home is the new datacenter.\nEarlier this month, NVIDIA confirmed what Akash has been building toward for years. In partnership with Span and homebuilder PulteGroup, NVIDIA announced an initiative to install GPU cabinets on the exterior of new homes. In Q1 2026, Akash began rolling out its first phase of Homenode, a software platform that lets anyone with a capable gaming PC plug into the Akash Network and start earning from their idle compute.\nOn the surface, these two initiatives share a similar underlying thesis. And simultaneously have very different paths to get there.\nHere’s how they compare.\nThe NVIDIA + Span Approach: New Hardware, New Homes, New Infrastructure\nThe NVIDIA/Span model installs company-owned cabinets containing liquid-cooled RTX PRO 6000 Blackwell GPUs on the exterior of homes. The homeowner provides electrical capacity and wall space. In exchange, they receive a utility credit on their monthly bill.\nIt’s an elegant idea. But the rollout requirements are significant:\n\nNew construction partnership. The initial deployment is tied to PulteGroup, a homebuilder. The cabinets are being designed into new homes, not retrofitted onto existing ones.\nHomeownership required. Renters are out. Apartment dwellers are out. Anyone with an HOA that doesn’t want an industrial-looking cabinet bolted to the side of their home is out.\nElectrical capacity required. The system is designed to power up to 16 RTX PRO 6000s. That’s a serious electrical service most existing homes don’t have without an upgrade.\nClimate and siting considerations. Exterior cabinets need appropriate placement, ventilation, and protection.\nA six-figure piece of hardware sitting outside your house. That’s a real consideration for a lot of people.\nTimeline uncertainty. This is a pilot tied to new home construction. Mass rollout is a multi-year process at minimum.\n\nFor the small slice of the population that’s building a brand new home with PulteGroup and wants to host a cabinet, this is a genuinely interesting offer. But it’s not a solution most people can act on.\n\nThe startup SPAN envisions a 100-home pilot deployment of XFRA nodes in 2026 followed by rapid scaling in 2027. Credit: SPAN\nThe Akash Homenode Approach: Use What You Already Have\nHomenode takes the opposite path.\nInstead of shipping new hardware to new homes, Homenode is software. If you already own a capable GPU - an RTX 30,40,50 series, or RTX Pro 6000 - you download an ISO image, plug into the Akash Network, and your machine starts earning from real compute demand on a permissionless marketplace.\nHere’s what that unlocks:\n\nNo new hardware purchase required for existing GPU owners. Use the rig you already built.\nNo new construction required. Works in any home, any apartment, any setup with power and internet.\nNo homeownership required. Renters can participate.\nAvailable immediately. Not a multi-year rollout. The software is what’s being built, and it’s coming soon.\nYou keep your machine. When you’re not earning, you’re gaming, running local models, or doing whatever you bought the rig for in the first place. It’s still your sovereign GPU.\nYou own the hardware. You participate directly in the marketplace.\n\nThe addressable population is dramatically larger than any new-construction program could reach, because Homenode meets people where their hardware already lives.\nWhere the Two Models Diverge\nThe fundamental difference comes down to who the program is for.\nNVIDIA + Span is designed for new homes being built right now, with the electrical capacity and physical space to host a centrally-managed cabinet. That’s a small and very specific group.\nHomenode is designed for anyone who already owns a capable GPU. Gamers. AI tinkerers. Workstation owners. Crypto miners pivoting to compute. That’s millions of machines already plugged in, already paid for, already sitting idle most of the day.\nOne requires you to wait for new infrastructure to reach you. The other meets you where you already are.\nWhy Both Matter\nThis isn’t a zero-sum story. The fact that NVIDIA is moving into home-based compute validates the entire thesis Akash has been building on: centralized hyperscale data centers can’t scale fast enough, and the latent capacity sitting in homes is enormous.\nThe two approaches can even be complementary over time. As more GPUs get deployed at the edge - whether through Span cabinets or consumer rigs - the need for an open, permissionless control plane to coordinate that compute only grows. That’s exactly what Akash provides.\nThe home is the new data center. The only real question for anyone reading this is: how soon do you want to participate?\nIf you’re building a new house with PulteGroup, the NVIDIA/Span option may be worth a look in the years ahead.\nIf you have a gaming rig sitting in your office right now, Homenode is the path that’s available to you today. Sign up for the Akash Homenode Pilot Testing, and start earning.\nFrequently Asked Questions\nWhat is the NVIDIA + Span home data center initiative?\nA partnership installing company-owned liquid-cooled RTX PRO 6000 Blackwell GPU cabinets on the exterior of new PulteGroup-built homes — homeowners receive a utility bill credit in exchange for providing space and electrical capacity.\nWhat is Akash Homenode?\nA software platform for existing GPU owners (RTX 30/40/50 series, RTX Pro 6000) to connect their hardware to the Akash Network and earn from real compute demand — no new hardware purchase, no new construction, no homeownership required.\nWhat GPUs does Akash Homenode currently support?\nRTX 4090, RTX 5090, and Quadro RTX 6000 Ada at launch — with expansion based on what the community brings to the program. Sign up at homenode.akash.network regardless of GPU model.\nWhy is the NVIDIA/Span approach limited in scale?\nIt requires new PulteGroup construction, homeownership, sufficient electrical capacity for up to 16 GPUs, exterior space and ventilation, and multi-year rollout timelines — excluding renters, existing homeowners, and most of the global GPU owner population.\nHow does Akash Homenode compare to NVIDIA/Span for existing GPU owners?\nHomenode works with hardware you already own, in any home or apartment, with no construction, no homeownership requirement, and is available now — while NVIDIA/Span requires new home construction and is years from mass rollout.\nWhy is distributed home compute the answer to AI’s energy crisis?\nCentralized data centers require years of new power infrastructure to build. Home compute uses existing electrical capacity distributed across millions of locations — AI workloads come to where energy already exists, not the other way around.\nHow do I sign up for Akash Homenode?\nSign up for the Akash Homenode Pilot at homenode.akash.network — early access is live with rigorous testing underway before the full alpha release. \nFast, affordable inference for open models\n\nRun Llama, Qwen, GLM and more on Akash's open compute marketplace.\nDrop-in API compatibility means you can\n switch in minutes.\n\nTry AkashML\n(opens in a new tab) \nnote\n\ntip\n\nCaution\n\nDanger","tokens":2001,"squid":"spider-03","role":"Compute Spider","at":1791339377153,"hash":"c6090e6a44a871a76f35eeb15dde9a99a4217c77"}
{"url":"https://jup.ag/deposit","domain":"jup.ag","title":"New to Solana? Deposit with Jupiter","text":"Deposit crypto from multiple chainsConnect your wallet to view deposit addresses for Solana and supported networks.More ways to depositBuy with a cardPay with Apple Pay, Google Pay, or other supported methodsSend from an exchangeConnect to Binance, Coinbase or Uphold and bridge onchainFrequently asked questionsJupiter offers 4 ways to fund your Solana wallet: use Universal Deposit, move tokens across networks with Bridge & Swap, buy crypto with a card, or send crypto from a supported exchange.Bridge & Swap supports Solana, Ethereum, Base, Arbitrum, Sui, BNB Chain, Robinhood, Optimism, Polygon, Avalanche, and Linea. Universal Deposit supports Solana, Ethereum, Base, Arbitrum, Sui, BNB Chain, and Robinhood Chain.Deposits below the displayed minimum accumulate until the minimum is reached. Check the minimum amount shown for the selected network before sending funds.Yes. Use Send from an exchange to bridge supported tokens onchain from Binance, Coinbase or Uphold to your Jupiter Wallet, or Buy with a card to pay with Apple Pay, Google Pay, or your preferred supported payment method.New to Solana?Get Jupiter Wallet extension","tokens":284,"squid":"spider-02","role":"Liquidity Spider","at":1791339384160,"hash":"b2daa1b389b76e0b149cdcd6e98488480317cb47"}
{"url":"https://akash.network/ecosystem/akash-tools/","domain":"akash.network","title":"The open cloud stack | Deployed On Akash","text":"The open cloud stack Whether you are shipping containers, serving inference, or powering the network, the Akash ecosystem provides the specialized tools to move at the speed of the open cloud. Professional-grade control Deploy clusters and ship containers in sixty seconds. No hidden abstractions. You have full control over every lease and bid. Launch Console Dedicated Inference Serve Llama, DeepSeek, and Qwen via OpenAI-compatible endpoints. Change one base_url to save 85% on production inference. Try AkashML Put your silicon to work Turn your idle GPUs into an income stream. Join the supply side and earn from a global marketplace of AI builders. Become a Provider Provide from home, no ops required Offer compute on Akash Network without needing to be a Kubernetes expert or an advanced Linux admin. Try Homenode Deploy with full self-custody Self-hostable, self-custody crypto wallet UI for deploying on Akash. View on GitHub \nReference applications\n\nHigh-performance deployments and experimental tools running on the open cloud. Try the latest in open-source AI, powered by the global GPU grid.\n Application Description A privacy-first interface for high-performance Large Language Models. Built to demonstrate the latency and cost-efficiency of open compute, Akash Chat runs the latest open-weights models on high-density GPU clusters. A privacy-first interface for high-performance Large Language Models. Built to demonstrate the latency and cost-efficiency of open compute, Akash Chat runs the latest open-weights models on high-density GPU clusters. \nTry it Image generation at the speed of the open cloud. This showcase demonstrates how to orchestrate complex diffusion models across the global GPU grid, providing professional-grade creative tools without proprietary lock-in. Image generation at the speed of the open cloud. This showcase demonstrates how to orchestrate complex diffusion models across the global GPU grid, providing professional-grade creative tools without proprietary lock-in. \nTry it \nAkash is open source. Every repository is a road you can help build.\n Repositories Description akash-network/console The deployment dashboard. If you see something missing, build it. The deployment dashboard. If you see something missing, build it. \nView akash-network/website The digital home of the network. If you see something broken, fix it. The digital home of the network. If you see something broken, fix it. \nView akash-network/awesome-akash Curated templates, tools, and resources from the community. Curated templates, tools, and resources from the community. \nView \nView All on GitHub","tokens":655,"squid":"spider-03","role":"Compute Spider","at":1791339388220,"hash":"df53207c366a152ae2bb50f13dcd8291d9d9cdd4"}
{"url":"https://akash.network/ecosystem/deployed-on-akash/","domain":"akash.network","title":"Ecosystem landscape | Deployed On Akash","text":"Ecosystem landscape View the projects scaling on the open compute marketplace. A network of AI platforms and developers running on sovereign, open-source infrastructure. R Λ Z Ξ R Razer's personalized AI companion experience, was brought to life at global scale using Razer's AIKit and Akash.Razer's personalized AI companion experience, was brought to life at global scale using Razer's AIKit and Akash.Razer's personalized AI companion experience, was brought to life at global scale using Razer's AIKit and Akash. View project NVIDIA Brev.dev (Acq. by NVIDIA), known for its seamless setup of Jupyter notebooks for AI development, has integrated with Akash Network, enabling scalable, permissionless access to NVIDIA GPUs.Brev.dev (Acq. by NVIDIA), known for its seamless setup of Jupyter notebooks for AI development, has integrated with Akash Network, enabling scalable, permissionless access to NVIDIA GPUs.Brev.dev (Acq. by NVIDIA), known for its seamless setup of Jupyter notebooks for AI development, has integrated with Akash Network, enabling scalable, permissionless access to NVIDIA GPUs. View project Venice.ai Venice is the easy app for private, uncensored AI conversations and image generation. Try for free with no log-in needed.Venice is the easy app for private, uncensored AI conversations and image generation. Try for free with no log-in needed.Venice is the easy app for private, uncensored AI conversations and image generation. Try for free with no log-in needed. View project Prime Intellect Prime Intellect leverages Akash Supercloud's high-performance GPUs, like NVIDIA H100 and A100, to democratize AI development.Prime Intellect leverages Akash Supercloud's high-performance GPUs, like NVIDIA H100 and A100, to democratize AI development.Prime Intellect leverages Akash Supercloud's high-performance GPUs, like NVIDIA H100 and A100, to democratize AI development. View project University of Texas at Austin The University of Texas at Austin is a bold, ambitious leader, providing a first-class education and the tools of discovery to more than 51,000 students.The University of Texas at Austin is a bold, ambitious leader, providing a first-class education and the tools of discovery to more than 51,000 students.The University of Texas at Austin is a bold, ambitious leader, providing a first-class education and the tools of discovery to more than 51,000 students. View project Nous Research Leveraging the power of Akash's decentralized cloud, Nous Research successfully trained 'Nous Hermes 2,' an advanced AI model built on over 1,000,000 entries of GPT-4 data.Leveraging the power of Akash's decentralized cloud, Nous Research successfully trained 'Nous Hermes 2,' an advanced AI model built on over 1,000,000 entries of GPT-4 data.Leveraging the power of Akash's decentralized cloud, Nous Research successfully trained 'Nous Hermes 2,' an advanced AI model built on over 1,000,000 entries of GPT-4 data. View project Eliza Eliza is a powerful multi-agent simulation framework designed to create, deploy and manage autonomous AI agents.Eliza is a powerful multi-agent simulation framework designed to create, deploy and manage autonomous AI agents.Eliza is a powerful multi-agent simulation framework designed to create, deploy and manage autonomous AI agents. View project Morpheus Morpheus is designed to incentivize the first open-source p2p network of personal general-purpose AI, powered by the MOR token.Morpheus is designed to incentivize the first open-source p2p network of personal general-purpose AI, powered by the MOR token.Morpheus is designed to incentivize the first open-source p2p network of personal general-purpose AI, powered by the MOR token. View project Flock.io Flock.io is advancing open, decentralized AI by integrating with Akash's Supercloud, making it simple for developers to access high-performance compute for training AI models.Flock.io is advancing open, decentralized AI by integrating with Akash's Supercloud, making it simple for developers to access high-performance compute for training AI models.Flock.io is advancing open, decentralized AI by integrating with Akash's Supercloud, making it simple for developers to access high-performance compute for training AI models. View project Auki Virtual real estate for shared augmented reality, allowing you to manifest your knowledge and imagination in the minds of others. Our unique solutions are powered by The Posemesh, a decentralized and privacy-preserving protocol for collaborative spatial computing.Virtual real estate for shared augmented reality, allowing you to manifest your knowledge and imagination in the minds of others. Our unique solutions are powered by The Posemesh, a decentralized and privacy-preserving protocol for collaborative spatial computing.Virtual real estate for shared augmented reality, allowing you to manifest your knowledge and imagination in the minds of others. Our unique solutions are powered by The Posemesh, a decentralized and privacy-preserving protocol for collaborative spatial computing. View project Bagel Bagel is an AI & Cryptography Research Lab. Making Open Source AI Monetizable leveraging novel cryptography.Bagel is an AI & Cryptography Research Lab. Making Open Source AI Monetizable leveraging novel cryptography.Bagel is an AI & Cryptography Research Lab. Making Open Source AI Monetizable leveraging novel cryptography. View project Levangie Laboratories Levangie Laboratories is shaping the next generation of adaptive AI systems. We are building agents that learn, evolve, and collaborate in real time, transforming industries and redefining what's possible with AI.Levangie Laboratories is shaping the next generation of adaptive AI systems. We are building agents that learn, evolve, and collaborate in real time, transforming industries and redefining what's possible with AI.Levangie Laboratories is shaping the next generation of adaptive AI systems. We are building agents that learn, evolve, and collaborate in real time, transforming industries and redefining what's possible with AI. View project yesnoerror An autonomous DeSci AI agent powered by OpenAI's o1 model, analyzing scientific papers for mathematical errors and discrepancies.An autonomous DeSci AI agent powered by OpenAI's o1 model, analyzing scientific papers for mathematical errors and discrepancies.An autonomous DeSci AI agent powered by OpenAI's o1 model, analyzing scientific papers for mathematical errors and discrepancies. View project Vertical AI The no-code platform for AI model fine-tuning. Train, deploy, and monetize AI models effortlessly through our integrated marketplace.The no-code platform for AI model fine-tuning. Train, deploy, and monetize AI models effortlessly through our integrated marketplace.The no-code platform for AI model fine-tuning. Train, deploy, and monetize AI models effortlessly through our integrated marketplace. View project Bless The world's first shared computer.The world's first shared computer.The world's first shared computer.The world's first shared computer. View project Grid The easiest way to deploy postgres on Akash.The easiest way to deploy postgres on Akash.The easiest way to deploy postgres on Akash.The easiest way to deploy postgres on Akash. View project VPS AI VPS AI has integrated with Akash, enabling decentralized, on-chain bidding for AI/ML workloads and GPU deployments.VPS AI has integrated with Akash, enabling decentralized, on-chain bidding for AI/ML workloads and GPU deployments.VPS AI has integrated with Akash, enabling decentralized, on-chain bidding for AI/ML workloads and GPU deployments. View project Saga Saga has integrated compute from the Akash Supercloud to power AI agents, enabling lower costs and greater access to the leading open source AI models.Saga has integrated compute from the Akash Supercloud to power AI agents, enabling lower costs and greater access to the leading open source AI models.Saga has integrated compute from the Akash Supercloud to power AI agents, enabling lower costs and greater access to the leading open source AI models. View project Akash Report Your one-stop hub for Akash Network and Web3 news, guides, videos and token swaps. Explore the unstoppable cloud and stay ahead of the decentralized curve.Your one-stop hub for Akash Network and Web3 news, guides, videos and token swaps. Explore the unstoppable cloud and stay ahead of the decentralized curve.Your one-stop hub for Akash Network and Web3 news, guides, videos and token swaps. Explore the unstoppable cloud and stay ahead of the decentralized curve. Arcturus A space colony in a distant star system!A space colony in a distant star system!A space colony in a distant star system!A space colony in a distant star system! View project Bitmind The BitMind Platform makes utilizing compute easy. It aggregates compute from a variety of different providers, including Akash, and helps deploy and maintain instances for decentralized AI, providing a seamless and scalable experience for its users.The BitMind Platform makes utilizing compute easy. It aggregates compute from a variety of different providers, including Akash, and helps deploy and maintain instances for decentralized AI, providing a seamless and scalable experience for its users.The BitMind Platform makes utilizing compute easy. It aggregates compute from a variety of different providers, including Akash, and helps deploy and maintain instances for decentralized AI, providing a seamless and scalable experience for its users. View project Quasarch Cloud Plaftorm Quasarch Cloud Platform brings the familiar experience of traditional cloud platforms to the DeCloud by integrating with DePINs and other protocols to offer its users with the ability to build their cloud experience from the ground up with decentralized principles.Quasarch Cloud Platform brings the familiar experience of traditional cloud platforms to the DeCloud by integrating with DePINs and other protocols to offer its users with the ability to build their cloud experience from the ground up with decentralized principles.Quasarch Cloud Platform brings the familiar experience of traditional cloud platforms to the DeCloud by integrating with DePINs and other protocols to offer its users with the ability to build their cloud experience from the ground up with decentralized principles. Envision Labs Envision Labs has selected Akash as its primary compute provider, leveraging its automated scaling capabilities to power the Envision DeAI Network.Envision Labs has selected Akash as its primary compute provider, leveraging its automated scaling capabilities to power the Envision DeAI Network.Envision Labs has selected Akash as its primary compute provider, leveraging its automated scaling capabilities to power the Envision DeAI Network. View project Exabits Exabits,DGX B200, H100, GPU, web3.0,Decentralized,NVIDIA H100 GPUs,NVIDIA RTX 3090,network,docker,computing,blockchain,nft market,dappExabits,DGX B200, H100, GPU, web3.0,Decentralized,NVIDIA H100 GPUs,NVIDIA RTX 3090,network,docker,computing,blockchain,nft market,dappExabits,DGX B200, H100, GPU, web3.0,Decentralized,NVIDIA H100 GPUs,NVIDIA RTX 3090,network,docker,computing,blockchain,nft market,dapp View project Neural AI Neural AI transforms words into 3D AI game assets.Neural AI transforms words into 3D AI game assets.Neural AI transforms words into 3D AI game assets.Neural AI transforms words into 3D AI game assets. View project Rango Exchange The Universal Cross-Chain DEX Bridge Aggregator, Best Swap Rates on Bitcoin, Ethereum, Solana, Base, Blast, Celo, Arbitrum, BNB, Scroll, Polygon, and 50 more blockchains.The Universal Cross-Chain DEX Bridge Aggregator, Best Swap Rates on Bitcoin, Ethereum, Solana, Base, Blast, Celo, Arbitrum, BNB, Scroll, Polygon, and 50 more blockchains.The Universal Cross-Chain DEX Bridge Aggregator, Best Swap Rates on Bitcoin, Ethereum, Solana, Base, Blast, Celo, Arbitrum, BNB, Scroll, Polygon, and 50 more blockchains. View project Nebula Block Nebula Block offers smart and cost effective hosting solutions to make compute accessible to everyone in AI & Blockchain community.Nebula Block offers smart and cost effective hosting solutions to make compute accessible to everyone in AI & Blockchain community.Nebula Block offers smart and cost effective hosting solutions to make compute accessible to everyone in AI & Blockchain community. View project Alter Chat, message and share files in complete privacy. Alter is hosting altermail.live, their primary application on Akash according to their post from their official Twitter account.Chat, message and share files in complete privacy. Alter is hosting altermail.live, their primary application on Akash according to their post from their official Twitter account.Chat, message and share files in complete privacy. Alter is hosting altermail.live, their primary application on Akash according to their post from their official Twitter account. View project Anonstake Anonstake.com is an EU Anonstake displays powered by the Akash logo on their homepage, indicating they are hosted on Akash.Anonstake.com is an EU Anonstake displays powered by the Akash logo on their homepage, indicating they are hosted on Akash.Anonstake.com is an EU Anonstake displays powered by the Akash logo on their homepage, indicating they are hosted on Akash. View project AtlasDAO A DAO NFT community with a focus on philanthropy. A DAO NFT community with a focus on philanthropy. A DAO NFT community with a focus on philanthropy. View project Chandra Station The leading Omni-Chain Dex on Cosmos. Swap, stake, and bridge between Ethereum & Cosmos with faster transactions & lower fees. Sifchain hosts their DEX's Webapp on Akash.The leading Omni-Chain Dex on Cosmos. Swap, stake, and bridge between Ethereum & Cosmos with faster transactions & lower fees. Sifchain hosts their DEX's Webapp on Akash.The leading Omni-Chain Dex on Cosmos. Swap, stake, and bridge between Ethereum & Cosmos with faster transactions & lower fees. Sifchain hosts their DEX's Webapp on Akash. View project Chia Network A new blockchain and smart transaction platform that is easier to use, more efficient, and secure A considerable amount of Chia miners are hosted on Akash, along with several Chia community members provide compute to AkashA new blockchain and smart transaction platform that is easier to use, more efficient, and secure A considerable amount of Chia miners are hosted on Akash, along with several Chia community members provide compute to AkashA new blockchain and smart transaction platform that is easier to use, more efficient, and secure A considerable amount of Chia miners are hosted on Akash, along with several Chia community members provide compute to Akash View project Juno Network Application Layer for the Inter-chain era. Juno network's homepage is hosted on Akash, confirmed by their official tweet from their official Twitter account.Application Layer for the Inter-chain era. Juno network's homepage is hosted on Akash, confirmed by their official tweet from their official Twitter account.Application Layer for the Inter-chain era. Juno network's homepage is hosted on Akash, confirmed by their official tweet from their official Twitter account. View project NetaDAO NetaDAO is the Community Accelerator for $NETA NetaDAO confirmed they're hosting their homepage on Akash according to this tweet from their official accountNetaDAO is the Community Accelerator for $NETA NetaDAO confirmed they're hosting their homepage on Akash according to this tweet from their official accountNetaDAO is the Community Accelerator for $NETA NetaDAO confirmed they're hosting their homepage on Akash according to this tweet from their official account OmniFlix Interoperable P2P network for creators & sovereign communities (#DAOs or otherwise) to mint, manage, monetize & coordinate distribution activities around NFTsInteroperable P2P network for creators & sovereign communities (#DAOs or otherwise) to mint, manage, monetize & coordinate distribution activities around NFTsInteroperable P2P network for creators & sovereign communities (#DAOs or otherwise) to mint, manage, monetize & coordinate distribution activities around NFTs View project Osmosis DEX Interchain Liquidity Lab Osmosis team runs API servers on AkashInterchain Liquidity Lab Osmosis team runs API servers on AkashInterchain Liquidity Lab Osmosis team runs API servers on AkashInterchain Liquidity Lab Osmosis team runs API servers on Akash View project Passage 3D Passage 3D is the connected virtual worlds for work & play. Passage 3D is the connected virtual worlds for work & play. Passage 3D is the connected virtual worlds for work & play. View project AkashGen AkashGen is a high quality text-to-image model from Stability AI. This application is running on NVIDIA A100s leased from the Akash Supercloud, to achieve high-performing and cost-effective inference of 1024×1024 images.AkashGen is a high quality text-to-image model from Stability AI. This application is running on NVIDIA A100s leased from the Akash Supercloud, to achieve high-performing and cost-effective inference of 1024×1024 images.AkashGen is a high quality text-to-image model from Stability AI. This application is running on NVIDIA A100s leased from the Akash Supercloud, to achieve high-performing and cost-effective inference of 1024×1024 images. View project Stakewolle Professional Cosmos Validator & Engineer Stakewolle says \"deployed on Akash\" on their websiteProfessional Cosmos Validator & Engineer Stakewolle says \"deployed on Akash\" on their websiteProfessional Cosmos Validator & Engineer Stakewolle says \"deployed on Akash\" on their website View project Stargaze Community-owned app chain for NFTs with CosmWasm smart contracts. 100% carbon neutral. Zero gas. Several Stargaze validators are running on Akash as confirmed by their official Twitter Account.Community-owned app chain for NFTs with CosmWasm smart contracts. 100% carbon neutral. Zero gas. Several Stargaze validators are running on Akash as confirmed by their official Twitter Account.Community-owned app chain for NFTs with CosmWasm smart contracts. 100% carbon neutral. Zero gas. Several Stargaze validators are running on Akash as confirmed by their official Twitter Account. View project Strange Clan Farm, craft, & quest with your clan. P20 ( Play-to-Own™ ). Built on Passage 3d and UE5. Powered by Akash & Cosmos IBC.Farm, craft, & quest with your clan. P20 ( Play-to-Own™ ). Built on Passage 3d and UE5. Powered by Akash & Cosmos IBC.Farm, craft, & quest with your clan. P20 ( Play-to-Own™ ). Built on Passage 3d and UE5. Powered by Akash & Cosmos IBC. View project Thirdweb We make it easy to build web3 apps Thirdweb's head of Dev Rel indicated he's building with Thirdweb and deploying on Akash according to this Tweet. Deeper integration is coming soon.We make it easy to build web3 apps Thirdweb's head of Dev Rel indicated he's building with Thirdweb and deploying on Akash according to this Tweet. Deeper integration is coming soon.We make it easy to build web3 apps Thirdweb's head of Dev Rel indicated he's building with Thirdweb and deploying on Akash according to this Tweet. Deeper integration is coming soon. View project Thumper AI Blockchain analysis, deploy tool and proud validator of the Akash NetworkBlockchain analysis, deploy tool and proud validator of the Akash NetworkBlockchain analysis, deploy tool and proud validator of the Akash NetworkBlockchain analysis, deploy tool and proud validator of the Akash Network View project Foundry Digital Foundry empowers institutional miners, staking customers, and participants within the crypto ecosystem to mine and stake digital assets.Foundry empowers institutional miners, staking customers, and participants within the crypto ecosystem to mine and stake digital assets.Foundry empowers institutional miners, staking customers, and participants within the crypto ecosystem to mine and stake digital assets. View project Blockless Execute Off-Chain, Decentralized Everywhere. According to this tweet from their Head of Engineering, Akash is enabling Blockless to be decentralized from day one while keeping its infrastructure costs at a minimum.Execute Off-Chain, Decentralized Everywhere. According to this tweet from their Head of Engineering, Akash is enabling Blockless to be decentralized from day one while keeping its infrastructure costs at a minimum.Execute Off-Chain, Decentralized Everywhere. According to this tweet from their Head of Engineering, Akash is enabling Blockless to be decentralized from day one while keeping its infrastructure costs at a minimum. View project NodeShift NodeShift offers reliable, scalable, secure and decentralized cloud computing services.NodeShift offers reliable, scalable, secure and decentralized cloud computing services.NodeShift offers reliable, scalable, secure and decentralized cloud computing services. View project","tokens":5250,"squid":"spider-03","role":"Compute Spider","at":1791339408543,"hash":"217f084df72c78546d0423a4c6545adae29df5da"}
{"url":"https://vote.jup.ag/","domain":"vote.jup.ag","title":"Vote | Jupiter","text":"ASR is now claimable via the Jupiter Rewards HubJupiter DAO Stake JUP.Shape Jupiter's Future. Earn Rewards.Govern the future of onchain finance. Earn $JUP rewards through ASR every quarter, vote on key decisions, and unlock exclusive access across the Jupiter ecosystem (soon). Unstake anytime.Stake JUP Now012345678901234567891,012345678901234567890012345678901234567896012345678901234567896,012345678901234567897012345678901234567891012345678901234567893,012345678901234567892012345678901234567892012345678901234567895Total JUP Staked012345678901234567893012345678901234567895012345678901234567897,012345678901234567896012345678901234567894012345678901234567895Total Stakers012345678901234567891012345678901234567898.012345678901234567897012345678901234567895%Estimated APYTotal JUP Staked012345678901234567891,012345678901234567890012345678901234567896012345678901234567896,012345678901234567897012345678901234567891012345678901234567893,012345678901234567892012345678901234567892012345678901234567895 JUPTotal Stakers012345678901234567893012345678901234567895012345678901234567897,012345678901234567896012345678901234567894012345678901234567895Estimated APY012345678901234567891012345678901234567898.012345678901234567897012345678901234567895%FAQsStaking gives you voting power in the DAO and makes you eligible for ASR, quarterly rewards distributed to stakers in JUP. Unstaked JUP earns no rewards and has no voting power.Active Staking Rewards. Every quarter, 50M JUP is distributed to eligible stakers and added to your staked balance. When rewards become available, you can claim them at jup.ag/rewards. Unclaimed ASR is returned to the community's treasury after the claim period ends. Follow @jup_dao for updates on timing.Your JUP is held in the governance contract but can be withdrawn anytime by starting a 7-day unstaking process. You can still vote on active proposals during that period. You can also add more JUP to your existing stake at any time without unstaking first.Scroll to the Proposals section on this page. Select an active proposal, pick your option, and confirm the transaction in your wallet.No. ASR is distributed based on time-weighted stake only. Your vote choice has no impact on rewards.Yes. Vote again with a different option while the proposal is still active. Your previous vote is replaced.Right here on vote.jup.ag (connect your wallet), or in Jupiter Portfolio. Some wallets don't display staked JUP correctly because it's not liquid.First, check that you have at least ~0.01 SOL for gas. If you're trying to claim after unstaking and it still fails, your wallet may not have an open JUP token account. This happens if you've used a wallet cleanup tool. Buy a tiny amount of JUP to reopen the account, then retry.Unstaking triggers a 7-day cooldown. During that time, you cannot claim ASR. You can either wait for the cooldown to finish and then claim, or cancel the unstake to claim immediately. Your voting power also adjusts: a partial unstake reduces it instantly, a full unstake decreases it gradually over the 7 days.Voting Power0Lock JUP tokens to receive your voting power.ProposalsTitleVotedStatusResultsStartEndProposal: Net-Zero EmissionsOption Voting Proposal-CompletedFebruary 16, 202607:46 AMFebruary 22, 202604:59 AMProposal: Burning the LitterboxOption Voting Proposal-CompletedOctober 29, 202507:41 AMNovember 04, 202509:29 AMProposal: JUP & Juice Working Group BudgetStandard DAO Proposal-CompletedJune 01, 202515:06 PMJune 06, 202511:30 AMProposal: DAO Alliance with Huma FinanceStandard DAO Proposal-CompletedMay 17, 202513:06 PMMay 22, 202510:29 AMProposal: DAO ResolutionStandard DAO Proposal-CompletedApril 23, 202500:22 AMApril 27, 202511:29 AMTrial Budget: DevRel WG (DRWG)Standard DAO Proposal-CompletedMarch 28, 202515:26 PMApril 02, 202510:29 AMTrial Budget: Design & Art WG (DAWG)Standard DAO Proposal-CompletedMarch 28, 202515:25 PMApril 02, 202510:29 AMProposal: Catdets Working Group BudgetStandard DAO Proposal-CompletedMarch 17, 202508:09 AMMarch 21, 202510:33 AMMeow's 2030 Lock-inOption Voting Proposal-CompletedMarch 06, 202508:35 AMMarch 10, 202512:28 PMProposal: Update Jupiter LogoOption Voting Proposal-CompletedFebruary 26, 202501:14 AMMarch 02, 202509:42 AMJ4J #3: Jupuary Vote 2Option Voting Proposal-CompletedDecember 03, 202420:24 PMDecember 07, 202422:00 PMJ4J #3: Jupuary Vote 1Option Voting Proposal-CompletedNovember 25, 202408:03 AMNovember 29, 202409:59 AMJUP Mobile Background VoteOption Voting Proposal-CompletedNovember 16, 202403:46 AMNovember 20, 202409:59 AMProposal: Increase Quorum for Jupiter DAOOption Voting Proposal-CompletedOctober 25, 202406:48 AMOctober 29, 202410:31 AMJ4J #2: Utilize Excess Jupuary for ASROption Voting Proposal-CompletedSeptember 27, 202409:44 AMOctober 01, 202410:30 AMTrial Budget: Jup & Juice WG (JJWG)Standard DAO Proposal-CompletedSeptember 09, 202402:52 AMSeptember 12, 202410:30 AMJupiter DAO: Microgrants ProposalStandard DAO Proposal-CompletedAugust 23, 202409:43 AMAugust 27, 202411:00 AMJ4J #1: Supply Reduction ProposalStandard DAO Proposal-CompletedAugust 01, 202409:44 AMAugust 04, 202410:16 AMProposal: Uplink Working Group BudgetStandard DAO Proposal-CompletedJune 15, 202410:03 AMJune 19, 202410:31 AMRound #3 of LFG VotingOption Voting Proposal-CompletedMay 22, 202402:58 AMMay 25, 202412:03 PMTrial Budget: Reddit Working GroupStandard DAO Proposal-CompletedMay 02, 202407:52 AMMay 05, 202410:01 AMTrial Budget: Catdet Working GroupStandard DAO Proposal-CompletedMay 02, 202407:51 AMMay 05, 202410:00 AMTrial Budget: Web Working GroupStandard DAO Proposal-CompletedMay 02, 202407:29 AMMay 05, 202410:00 AMRound #2 of LFG VotingOption Voting Proposal-CompletedApril 17, 202404:30 AMApril 20, 202412:00 PMProposal: Core Working Group BudgetStandard DAO Proposal-CompletedMarch 29, 202410:59 AMApril 01, 202411:03 AMRound #1 of LFG Voting!Option Voting Proposal-CompletedMarch 07, 202408:17 AMMarch 10, 202411:00 AMWhich animal is the cutest?Option Voting Proposal-CompletedMarch 05, 202408:55 AMMarch 07, 202409:50 AMConnect","tokens":1518,"squid":"spider-02","role":"Liquidity Spider","at":1791339418620,"hash":"e7fefd0098f96966163dcf9de306d89a8844ad42"}
{"url":"https://akash.network/ecosystem/deployed-on-akash/dev%20tools","domain":"akash.network","title":"Dev tools | Deployed On Akash","text":"Dev tools NodeShift NodeShift offers reliable, scalable, secure and decentralized cloud computing services.NodeShift offers reliable, scalable, secure and decentralized cloud computing services.NodeShift offers reliable, scalable, secure and decentralized cloud computing services. View project Quasarch Cloud Plaftorm Quasarch Cloud Platform brings the familiar experience of traditional cloud platforms to the DeCloud by integrating with DePINs and other protocols to offer its users with the ability to build their cloud experience from the ground up with decentralized principles.Quasarch Cloud Platform brings the familiar experience of traditional cloud platforms to the DeCloud by integrating with DePINs and other protocols to offer its users with the ability to build their cloud experience from the ground up with decentralized principles.Quasarch Cloud Platform brings the familiar experience of traditional cloud platforms to the DeCloud by integrating with DePINs and other protocols to offer its users with the ability to build their cloud experience from the ground up with decentralized principles.","tokens":279,"squid":"spider-03","role":"Compute Spider","at":1791339419501,"hash":"50349eeb44c8c50bbd848e3de409563ccd5bf6c5"}
{"url":"https://docs.across.to/introduction/api-keys","domain":"docs.across.to","title":"API Keys & Integrator ID | Across Docs","text":"API Keys & Integrator IDHow to get an API key and integrator ID for production use of the Across APIs.What Are They?\nProduction use of Across requires two credentials:\nCredentialWhat it isHow it's usedAPI KeyAuthentication token for API requestsPassed in the Authorization header on every API callIntegrator IDUnique 2-byte hex identifier (e.g., 0xdead)Passed as a query parameter (integratorId) in API calls, or appended to calldata for direct contract integration\nBoth are required for production. Without them, your requests may be rate-limited or rejected.\nHow to Request\nGet your API key and Integrator ID — register your project and receive your credentials instantly.\nUsing with the Swap API\nWhen calling the Swap API, pass both your API key in the Authorization header and your integrator ID as a query parameter:\nswap-api-auth.tsconst params = new URLSearchParams({\n tradeType: \"minOutput\",\n originChainId: \"42161\",\n destinationChainId: \"8453\",\n inputToken: \"0xaf88d065e77c8cC2239327C5EDb3A432268e5831\",\n outputToken: \"0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913\",\n amount: \"1000000000\",\n depositor: \"0xYourWalletAddress\",\n integratorId: \"0xdead\", // Your 2-byte hex integrator ID\n});\n\nconst response = await fetch(\n `https://app.across.to/api/swap/approval?${params}`,\n {\n headers: {\n Authorization: \"Bearer YOUR_API_KEY\",\n },\n }\n);\nUsing with Direct Contract Integration\nIf you're calling depositV3 on the SpokePool directly (via the suggested-fees API), the credentials are passed differently:\n\nAPI key — Authorization header on the /suggested-fees API call\nIntegrator ID — appended to the depositV3 transaction calldata (not as a query parameter)\n\nAppending Integrator ID to Calldata\nAppend a delimiter (1dc0de) followed by your integrator ID to the end of the encoded depositV3 calldata:\nComponentValueDescriptionDelimiter1dc0deFixed 3-byte hex string that marks the start of the identifierIntegrator IDYour assigned ID (e.g., f001)Unique identifier provided by the Across team\n...0000000000000000000000000000000000000000000000000000000000000000 // last param\n1dc0def001 // ← delimiter (1dc0de) + integrator ID (f001)\nDo NOT pass the delimiter + identifier to any depositV3 parameter, including the message param. Only append it to the raw calldata of the transaction.\nDo NOT use f001 as your identifier — it is an example only. Request your unique identifier from the Across team via your shared communication channel (Telegram, Slack).\nappend-integrator-id.tsimport { encodeFunctionData, type Hex } from \"viem\";\n\nconst DELIMITER = \"1dc0de\";\nconst INTEGRATOR_ID = \"f001\"; // Replace with your assigned ID\n\n// Encode depositV3 calldata normally\nconst calldata = encodeFunctionData({\n abi: spokePoolAbi,\n functionName: \"depositV3\",\n args: [depositor, recipient, inputToken, outputToken, inputAmount,\n outputAmount, destinationChainId, exclusiveRelayer,\n quoteTimestamp, fillDeadline, exclusivityDeadline, message],\n});\n\n// Append delimiter + integrator ID to the raw calldata\nconst calldataWithId = `${calldata}${DELIMITER}${INTEGRATOR_ID}` as Hex;\n\nconst hash = await walletClient.sendTransaction({\n to: spokePoolAddress,\n data: calldataWithId,\n});\nTestnet vs Production\nEnvironmentBase URLAPI Key Required?Testnethttps://testnet.across.to/apiNoProductionhttps://app.across.to/apiYes\nTestnet does not require an API key or integrator ID. You can develop and test your integration freely on testnet without credentials. Only production requests need authentication.\nRate Limits\nWithout a valid API key, production requests are subject to strict rate limits. Authenticated requests receive higher rate limits appropriate for production traffic.\nIf you're seeing 429 Too Many Requests errors:\n\nVerify your API key is included in the Authorization header\nCheck that the key is valid and not expired\nAvoid polling /swap/approval or /suggested-fees more frequently than needed — these endpoints return fresh quotes, not cached data\n\nIntegrator ID Format\nThe integrator ID is a 2-byte hex string prefixed with 0x when used as a query parameter:\n0xdead ✓ Valid\n0x0001 ✓ Valid\n0xffff ✓ Valid\ndead ✗ Missing 0x prefix\n0xdeadbeef ✗ Too long (4 bytes)\nWhen appending to calldata for direct contract integration, use the raw hex without the 0x prefix (e.g., dead not 0xdead).Key FeaturesWhat makes Across the fastest, cheapest, and most secure crosschain interoperability protocol.Across for StablecoinsMove native USDC, USDT0, and USDH across chains with a single Swap API call.","tokens":1120,"squid":"spider-09","role":"Bridge Spider","at":1791339543809,"hash":"2128478e3a782aa201cffa667ed7e5a331884f6e"}
{"url":"https://docs.across.to/tools/integrator-id","domain":"docs.across.to","title":"Get API Key & Integrator ID | Across Docs","text":"Get API Key & Integrator IDRegister your project to get an Across API key and integrator ID — everything you need to start building with the Across API.Get Your API Key & Integrator ID\nGet API Key & Integrator IDFill out the form below to get your Across API key and integrator ID.Email *Project Name *Discord HandleYour Telegram Handle *Project Website *Project Twitter Handle *Project BlurbCategory *Select a categoryWalletSwapPrediction marketDexPerp dexSwap/bridge aggregatorWhich chains are you using?Which APIs do you plan to use?/swap/approval—Get swap quote & approval data/swap/counterfactual—Generate counterfactual deposit address/swap/chains—Get supported chains/swap/tokens—Get supported tokens/swap/sources—Get supported sources/deposit/status—Track the lifecycle of a deposit/deposit—Get details for a single deposit/deposits—Get all deposits for a depositor/suggested-fees—Retrieve suggested fee quote for a depositLegacy — soon to be sunset/limits—Retrieve current transfer limitsLegacy — soon to be sunset/available-routes—Retrieve available routes for transfersLegacy — soon to be sunsetTransaction BuilderBuild crosschain swap + action requests for the Across API.AI Transaction BuilderDescribe your crosschain transfer in natural language and get a ready-to-use Across API call.","tokens":325,"squid":"spider-09","role":"Bridge Spider","at":1791339554230,"hash":"01581a39a35aca105df82d4bd33b8f1995a0b242"}
{"url":"https://docs.switchboard.xyz/tooling/sdk-version-matrix","domain":"docs.switchboard.xyz","title":"SDK Version Matrix | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.This page is the version reference for Switchboard docs, examples, and verifier tooling.Baseline date: July 30, 2026Source of truth: tooling/sdk-versions.lock.jsonThe lock file now tracks two different views:sdk_versions / companion_versions: the canonical docs pin set used by current docs and compatibility checksobserved_example_versions: the exact versions currently pinned in the checked-in sb-on-demand-examples manifestsObserved Versions In Current ExamplesPackage / CrateObserved Version(s)Current Example ReferencesNotes@switchboard-xyz/on-demand^3.10.6common, solana/feeds/*, solana/prediction-market, solana/randomness/coin-flip, solana/surge, solana/x402, solana/legacy/feeds, sui/feeds/basic, sui/surge/basicCurrent TypeScript examples are aligned.@switchboard-xyz/common^5.8.5common, common/twitter-follower-count, common/variable-overrides, evm/*, solana/feeds/*, solana/prediction-market, solana/randomness/coin-flip, solana/surge, solana/x402, solana/legacy/feedsCurrent TypeScript examples are aligned.@switchboard-xyz/common-legacy^1.1.1solana/legacy/feedsCompatibility transport for classic PullFeed integrations.@switchboard-xyz/on-demand-solidity^1.1.0evm/price-feeds, evm/randomness/*Current EVM examples are aligned.@switchboard-xyz/sui-sdk^0.1.16sui/feeds/basic, sui/surge/basicAligned across current Sui examples.switchboard-on-demand0.13.0common/rust-feed-creation, solana/feeds/*, solana/prediction-market, solana/randomness/coin-flipCurrent Rust examples are aligned.switchboard-protos0.2.6solana/prediction-marketOnly used by the prediction-market program.pinocchio0.11.2solana/feeds/advancedCompanion dependency for the low-CU Pinocchio example.Canonical Docs Pin SetThese are the current docs pins. Example-backed pins match the observed versions above; docs-only pins are listed as the versions already used by their pages.Package / CrateCanonical PinNotes@switchboard-xyz/on-demand3.10.6Matches the current TypeScript example set.@switchboard-xyz/common5.8.5Canonical OracleJob and OracleFeed serialization used by current TypeScript examples.@switchboard-xyz/common-legacy1.1.1Installed transitively by on-demand; install directly only when importing LegacyCrossbarClient.@switchboard-xyz/on-demand-solidity1.1.0Current Solidity interface pin.@switchboard-xyz/sui-sdk0.1.16Matches current Sui examples.@switchboard-xyz/aptos-sdk0.1.5Used by the Aptos and Movement docs.@switchboard-xyz/iota-sdk0.0.3Current docs pin.switchboard-on-demand0.13.0Matches current Rust examples.switchboard-protos0.2.6Matches the current prediction-market example.Companion DependenciesDependencyCanonical PinNotes@solana/web3.js1.98.0Matches current Solana examples.@mysten/sui1.38.0Compatible with current Sui docs/examples import surface.@aptos-labs/ts-sdk6.1.0Used by the Aptos and Movement docs.@iota/iota-sdk1.11.0Iota smoke projects.ethers6.13.1Matches the current EVM price-feeds example manifest.@coral-xyz/anchor0.31.1Matches the current Solana example manifests.pinocchio0.11.2Matches the advanced Solana price-feed example.Toolchain BaselineToolVersionNode.js23.11.0 (verified, >=24 recommended for @iota/iota-sdk)Bun1.3.6Rust1.89.0-nightlyAnchor CLI0.31.1Solana CLI2.3.11Foundry (forge)1.5.0Aptos CLI8.1.0Sui CLI1.73.1Known NotesCurrent TypeScript example manifests are aligned on @switchboard-xyz/on-demand@^3.10.6 and @switchboard-xyz/common@^5.8.5. The classic PullFeed example also uses @switchboard-xyz/common-legacy@^1.1.1.When upgrading from Common 5.8.4, common-legacy 1.1.0, or on-demand 3.10.5, update all three compatible pins together and refresh the application lockfile with its normal package-manager install command.on-demand installs common-legacy transitively. Add common-legacy as a direct dependency only when your code imports LegacyCrossbarClient.@mysten/sui latest 2.x still breaks the import surface used in current docs/examples, so 1.38.0 remains pinned.Current Solana Rust examples use switchboard-on-demand = \"0.13.0\". The advanced Pinocchio price-feed example uses pinocchio = \"0.11.2\" and the AccountView API.sui/feeds/basic defaults its checked-in Move.toml to testnet. Use the explicit build:testnet, build:mainnet, deploy:testnet, and deploy:mainnet scripts when documenting or verifying flows.PreviousSDKsNextOverviewLast updated 2 months ago","tokens":1099,"squid":"spider-08","role":"Oracle Spider","at":1791339556003,"hash":"fa278d558ab58c1499089faf8516e6b9a872145e"}
{"url":"https://eips.ethereum.org/EIPS/eip-1","domain":"eips.ethereum.org","title":"EIP-1: EIP Purpose and Guidelines","text":"🎉 Living\n\n Meta\n\n EIP-1: EIP Purpose and Guidelines\n\n Authors\n Martin Becze <mb@ethereum.org>, Hudson Jameson <hudson@ethereum.org>, et al.\n\n Created\n 2015-10-27\n\n What is an EIP?\n\nEIP stands for Ethereum Improvement Proposal. An EIP is a design document providing information to the Ethereum community, or describing a new feature for Ethereum or its processes or environment. The EIP should provide a concise technical specification of the feature and a rationale for the feature. The EIP author is responsible for building consensus within the community and documenting dissenting opinions.\n\n EIP Rationale\n\nWe intend EIPs to be the primary mechanisms for proposing new features, for collecting community technical input on an issue, and for documenting the design decisions that have gone into Ethereum. Because the EIPs are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal.\n\nFor Ethereum implementers, EIPs are a convenient way to track the progress of their implementation. Ideally, each implementation maintainer would list the EIPs that they have implemented. This will give end users a convenient way to know the current status of a given implementation or library.\n\n EIP Types\n\nThere are three types of EIP:\n\n A Standards Track EIP describes 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. Standards Track EIPs consist of three parts—a design document, an implementation, and (if warranted) an update to the formal specification. Furthermore, Standards Track EIPs can be broken down into the following categories:\n\n Core: improvements requiring a consensus fork (e.g. EIP-5, EIP-101), as well as changes that are not necessarily consensus critical but may be relevant to “core dev” discussions (for example, [EIP-90], and the miner/node strategy changes 2, 3, and 4 of EIP-86).\n Networking: includes improvements around devp2p (EIP-8) and Light Ethereum Subprotocol, as well as proposed improvements to network protocol specifications of whisper and swarm.\n Interface: includes improvements around language-level standards like method names (EIP-6) and contract ABIs.\n ERC: application-level standards and conventions, including contract standards such as token standards (ERC-20), name registries (ERC-137), URI schemes, library/package formats, and wallet formats.\n\n A Meta EIP describes 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\n An Informational EIP describes an 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.\n\nIt is highly recommended that a single EIP contain a single key proposal or new idea. The more focused the EIP, the more successful it tends to be. A change to one client doesn’t require an EIP; a change that affects multiple clients, or defines a standard for multiple apps to use, does.\n\nAn EIP must meet certain minimum criteria. It must be a clear and complete description of the proposed enhancement. The enhancement must represent a net improvement. The proposed implementation, if applicable, must be solid and must not complicate the protocol unduly.\n\n Special requirements for Core EIPs\n\nIf a Core EIP mentions or proposes changes to the EVM (Ethereum Virtual Machine), it should refer to the instructions by their mnemonics and define the opcodes of those mnemonics at least once. A preferred way is the following:\n\nREVERT (0xfe)\n\n EIP Work Flow\n\n Shepherding an EIP\n\nParties involved in the process are you, the champion or EIP author, the EIP editors, and the Ethereum Core Developers.\n\nBefore you begin writing a formal EIP, you should vet your idea. Ask the Ethereum community first if an idea is original to avoid wasting time on something that will be rejected based on prior research. It is thus recommended to open a discussion thread on the Ethereum Magicians forum to do this.\n\nOnce the idea has been vetted, your next responsibility will be to present (by means of an EIP) the idea to the reviewers and all interested parties, invite editors, developers, and the community to give feedback on the aforementioned channels. You should try and gauge whether the interest in your EIP is commensurate with both the work involved in implementing it and how many parties will have to conform to it. For example, the work required for implementing a Core EIP will be much greater than for an ERC and the EIP will need sufficient interest from the Ethereum client teams. Negative community feedback will be taken into consideration and may prevent your EIP from moving past the Draft stage.\n\n Core EIPs\n\nFor Core EIPs, given that they require client implementations to be considered Final (see “EIPs Process” below), you will need to either provide an implementation for clients or convince clients to implement your EIP.\n\nThe best way to get client implementers to review your EIP is to present it on an AllCoreDevs call. You can request to do so by posting a comment linking your EIP on an AllCoreDevs agenda GitHub Issue.\n\nThe AllCoreDevs call serves as a way for client implementers to do three things. First, to discuss the technical merits of EIPs. Second, to gauge what other clients will be implementing. Third, to coordinate EIP implementation for network upgrades.\n\nThese calls generally result in a “rough consensus” around what EIPs should be implemented. This “rough consensus” rests on the assumptions that EIPs are not contentious enough to cause a network split and that they are technically sound.\n\n:warning: The EIPs process and AllCoreDevs call were not designed to address contentious non-technical issues, but, due to the lack of other ways to address these, often end up entangled in them. This puts the burden on client implementers to try and gauge community sentiment, which hinders the technical coordination function of EIPs and AllCoreDevs calls. If you are shepherding an EIP, you can make the process of building community consensus easier by making sure that the Ethereum Magicians forum thread for your EIP includes or links to as much of the community discussion as possible and that various stakeholders are well-represented.\n\nIn short, your role as the champion is to write the EIP using the style and format described below, shepherd the discussions in the appropriate forums, and build community consensus around the idea.\n\n EIP Process\n\nThe following is the standardization process for all EIPs in all tracks:\n\nIdea - An idea that is pre-draft. This is not tracked within the EIP Repository.\n\nDraft - 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\nReview - An EIP Author marks an EIP as ready for and requesting Peer Review.\n\nLast Call - This is the final review window for an EIP before it is moved to Final. An EIP enters Last Call when the specification is stable and the author opens a PR with a review end date (last-call-deadline), typically 14 days later.\n\nIf this period results in necessary normative changes it will revert the EIP to Review.\n\nFinal - 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\nA PR moving an EIP from Last Call to Final SHOULD contain no changes other than the status update. Any content or editorial proposed change SHOULD be separate from this status-updating PR and committed prior to it.\n\nStagnant - Any EIP in Draft or Review or Last Call 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 or its earlier status. If not resurrected, a proposal may stay forever in this status.\n\n EIP Authors are notified of any algorithmic change to the status of their EIP\n\nWithdrawn - 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 a later date, it is considered a new proposal.\n\nLiving - 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\n What belongs in a successful EIP?\n\nEach EIP should have the following parts:\n\n Preamble - RFC 822 style headers containing metadata about the EIP, including the EIP number, a short descriptive title (limited to a maximum of 44 characters), a description (limited to a maximum of 140 characters), and the author details. Irrespective of the category, the title and description should not include EIP number. See below for details.\n Abstract - Abstract is a multi-sentence (short paragraph) technical summary. This should be a very terse and human-readable version of the specification section. Someone should be able to read only the abstract to get the gist of what this specification does.\n Motivation (optional) - A motivation section is critical for EIPs that want to change the Ethereum protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the EIP solves. This section may be omitted if the motivation is evident.\n Specification - The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Ethereum platforms (besu, erigon, ethereumjs, go-ethereum, nethermind, or others).\n Rationale - The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale should discuss important objections or concerns raised during discussion around the EIP.\n Backwards Compatibility (optional) - All EIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their consequences. The EIP must explain how the author proposes to deal with these incompatibilities. This section may be omitted if the proposal does not introduce any backward incompatibilities, but this section must be included if backward incompatibilities exist.\n Test Cases (optional) - Test cases for an implementation are mandatory for EIPs that are affecting consensus changes. Tests should either be inlined in the EIP as data (such as input/expected output pairs) or included in ../assets/eip-###/<filename>. This section may be omitted for non-Core proposals.\n Reference Implementation (optional) - An optional section that contains a reference/example implementation that people can use to assist in understanding or implementing this specification. This section may be omitted for all EIPs.\n Security Considerations - All EIPs must contain a section that discusses the security implications/considerations relevant to the proposed change. Include information that might be important for security discussions, surfaces risks and can be used throughout the life-cycle of the proposal. E.g., include security-relevant design decisions, concerns, important discussions, implementation-specific guidance and pitfalls, an outline of threats and risks and how they are being addressed. EIP submissions missing the “Security Considerations” section will be rejected. An EIP cannot proceed to status “Final” without a Security Considerations discussion deemed sufficient by the reviewers.\n Copyright Waiver - All EIPs must be in the public domain. The copyright waiver MUST link to the license file and use the following wording: Copyright and related rights waived via [CC0](/LICENSE).\n\n EIP Formats and Templates\n\nEIPs should be written in markdown format. There is a template and contributor guidelines to follow.\n\n EIP Header Preamble\n\nEach EIP must begin with an RFC 822 style header preamble, preceded and followed by three hyphens (---). This header is also termed “front matter” by Jekyll. The headers must appear in the following order.\n\neip: EIP number\n\ntitle: The EIP title is a few words, not a complete sentence\n\ndescription: Description is one full (short) sentence\n\nauthor: The list of the author’s or authors’ name(s) and/or username(s), or name(s) and email(s). Details are below.\n\ndiscussions-to: The url pointing to the official discussion thread\n\nstatus: Draft, Review, Last Call, Final, Stagnant, Withdrawn, Living\n\nlast-call-deadline: The date last call period ends on (Optional field, only needed when status is Last Call)\n\ntype: One of Standards Track, Meta, or Informational\n\ncategory: One of Core, Networking, Interface, or ERC (Optional field, only needed for Standards Track EIPs)\n\ncreated: Date the EIP was created on\n\nrequires: EIP number(s) (Optional field)\n\nwithdrawal-reason: A sentence explaining why the EIP was withdrawn. (Optional field, only needed when status is Withdrawn)\n\nHeaders that permit lists must separate elements with commas.\n\nHeaders requiring dates will always do so in the format of ISO 8601 (yyyy-mm-dd).\n\n author header\n\nThe author header lists the names, email addresses or usernames of the authors/owners of the EIP. Those who prefer anonymity may use a username only, or a first name and a username. The format of the author header value must be:\n\n Random J. User <address@dom.ain>\n\nor\n\n Random J. User (@username)\n\nor\n\n Random J. User (@username) <address@dom.ain>\n\nif the email address and/or GitHub username is included, and\n\n Random J. User\n\nif neither the email address nor the GitHub username are given.\n\nAt least one author must use a GitHub username, in order to get notified on change requests and have the capability to approve or reject them.\n\n discussions-to header\n\nWhile an EIP is a draft, a discussions-to header will indicate the URL where the EIP is being discussed.\n\nThe preferred discussion URL is a topic on Ethereum Magicians. The URL cannot point to Github pull requests, any URL which is ephemeral, and any URL which can get locked over time (i.e. Reddit topics).\n\n type header\n\nThe type header specifies the type of EIP: Standards Track, Meta, or Informational. If the track is Standards please include the subcategory (core, networking, interface, or ERC).\n\n category header\n\nThe category header specifies the EIP’s category. This is required for standards-track EIPs only.\n\n created header\n\nThe created header records the date that the EIP was assigned a number. Both headers should be in yyyy-mm-dd format, e.g. 2001-08-14.\n\n requires header\n\nEIPs may have a requires header, indicating the EIP numbers that this EIP depends on. If such a dependency exists, this field is required.\n\nA requires dependency is created when the current EIP cannot be understood or implemented without a concept or technical element from another EIP. Merely mentioning another EIP does not necessarily create such a dependency.\n\n Linking to External Resources\n\nOther than the specific exceptions listed below, links to external resources SHOULD NOT be included. External resources may disappear, move, or change unexpectedly.\n\nThe process governing permitted external resources is described in EIP-5757.\n\n Execution Client Specifications\n\nLinks to the Ethereum Execution Client Specifications may be included using normal markdown syntax, such as:\n\n[Ethereum Execution Client Specifications](https://github.com/ethereum/execution-specs/blob/9a1f22311f517401fed6c939a159b55600c454af/README.md)\n\nWhich renders to:\n\nEthereum Execution Client Specifications\n\nPermitted Execution Client Specifications URLs must anchor to a specific commit, and so must match this regular expression:\n\n^(https://github.com/ethereum/execution-specs/(blob|commit)/[0-9a-f]{40}/.*|https://github.com/ethereum/execution-specs/tree/[0-9a-f]{40}/.*)$\n\n Ethereum System Contract Implementations\n\nLinks to the Ethereum System Contract Implementations repository may be included using normal markdown syntax, such as:\n\n[Ethereum System Contract Implementations](https://github.com/ethereum/sys-asm/blob/83f9801245ff56878a450b5625801101b9a225a1/README.md)\n\nWhich renders to:\n\nEthereum System Contract Implementations\n\nPermitted URLs must anchor to a specific commit, and so must match this regular expression:\n\n^(https://github.com/ethereum/sys-asm/(blob|commit)/[0-9a-f]{40}/.*|https://github.com/ethereum/sys-asm/tree/[0-9a-f]{40}/.*)$\n\n Execution Specification Tests\n\nLinks to the Ethereum Execution Specification Tests (EEST) may be included using normal markdown syntax, such as:\n\n[Ethereum Execution Specification Tests](https://github.com/ethereum/execution-spec-tests/blob/c9b9307ff320c9bb0ecb9a951aeab0da4d9d1684/README.md)\n\nWhich renders to:\n\nEthereum Execution Specification Tests\n\nPermitted Execution Specification Tests URLs must anchor to a specific commit, and so must match one of these regular expressions:\n\n^https://(www\\.)?github\\.com/ethereum/execution-spec-tests/(blob|tree)/[a-f0-9]{40}/.+$\n\n^https://(www\\.)?github\\.com/ethereum/execution-spec-tests/commit/[a-f0-9]{40}$\n\n Consensus Layer Specifications\n\nLinks to specific commits of files within the Ethereum Consensus Layer Specifications may be included using normal markdown syntax, such as:\n\n[Beacon Chain](https://github.com/ethereum/consensus-specs/blob/26695a9fdb747ecbe4f0bb9812fedbc402e5e18c/specs/sharding/beacon-chain.md)\n\nWhich renders to:\n\nBeacon Chain\n\nPermitted Consensus Layer Specifications URLs must anchor to a specific commit, and so must match this regular expression:\n\n^https://github.com/ethereum/consensus-specs/(blob|commit)/[0-9a-f]{40}/.*$\n\n Networking Specifications\n\nLinks to specific commits of files within the Ethereum Networking Specifications may be included using normal markdown syntax, such as:\n\n[Ethereum Wire Protocol](https://github.com/ethereum/devp2p/blob/40ab248bf7e017e83cc9812a4e048446709623e8/caps/eth.md)\n\nWhich renders as:\n\nEthereum Wire Protocol\n\nPermitted Networking Specifications URLs must anchor to a specific commit, and so must match this regular expression:\n\n^https://github.com/ethereum/devp2p/(blob|commit)/[0-9a-f]{40}/.*$\n\n Portal Specifications\n\nLinks to specific commits of files within the Ethereum Portal Specifications may be included using normal markdown syntax, such as:\n\n[Portal Wire Protocol](https://github.com/ethereum/portal-network-specs/blob/5e321567b67bded7527355be714993c24371de1a/portal-wire-protocol.md)\n\nWhich renders as:\n\nPortal Wire Protocol\n\nPermitted Networking Specifications URLs must anchor to a specific commit, and so must match this regular expression:\n\n^https://github.com/ethereum/portal-network-specs/(blob|commit)/[0-9a-f]{40}/.*$\n\n World Wide Web Consortium (W3C)\n\nLinks to a W3C “Recommendation” status specification may be included using normal markdown syntax. For example, the following link would be allowed:\n\n[Secure Contexts](https://www.w3.org/TR/2021/CRD-secure-contexts-20210918/)\n\nWhich renders as:\n\nSecure Contexts\n\nPermitted W3C recommendation URLs MUST anchor to a specification in the technical reports namespace with a date, and so MUST match this regular expression:\n\n^https://www\\.w3\\.org/TR/[0-9][0-9][0-9][0-9]/.*$\n\n Web Hypertext Application Technology Working Group (WHATWG)\n\nLinks to WHATWG specifications may be included using normal markdown syntax, such as:\n\n[HTML](https://html.spec.whatwg.org/commit-snapshots/578def68a9735a1e36610a6789245ddfc13d24e0/)\n\nWhich renders as:\n\nHTML\n\nPermitted WHATWG specification URLs must anchor to a specification defined in the spec subdomain (idea specifications are not allowed) and to a commit snapshot, and so must match this regular expression:\n\n^https:\\/\\/[a-z]*\\.spec\\.whatwg\\.org/commit-snapshots/[0-9a-f]{40}/$\n\nAlthough not recommended by WHATWG, EIPs must anchor to a particular commit so that future readers can refer to the exact version of the living standard that existed at the time the EIP was finalized. This gives readers sufficient information to maintain compatibility, if they so choose, with the version referenced by the EIP and the current living standard.\n\n Internet Engineering Task Force (IETF)\n\nLinks to an IETF Request For Comment (RFC) specification may be included using normal markdown syntax, such as:\n\n[RFC 8446](https://www.rfc-editor.org/rfc/rfc8446)\n\nWhich renders as:\n\nRFC 8446\n\nPermitted IETF specification URLs MUST anchor to a specification with an assigned RFC number (meaning cannot reference internet drafts), and so MUST match this regular expression:\n\n^https:\\/\\/www.rfc-editor.org\\/rfc\\/.*$\n\n Bitcoin Improvement Proposal\n\nLinks to Bitcoin Improvement Proposals may be included using normal markdown syntax, such as:\n\n[BIP 38](https://github.com/bitcoin/bips/blob/3db736243cd01389a4dfd98738204df1856dc5b9/bip-0038.mediawiki)\n\nWhich renders to:\n\nBIP 38\n\nPermitted Bitcoin Improvement Proposal URLs must anchor to a specific commit, and so must match this regular expression:\n\n^(https://github.com/bitcoin/bips/blob/[0-9a-f]{40}/bip-[0-9]+\\.mediawiki)$\n\n National Vulnerability Database (NVD)\n\nLinks to the Common Vulnerabilities and Exposures (CVE) system as published by the National Institute of Standards and Technology (NIST) may be included, provided they are qualified by the date of the most recent change, using the following syntax:\n\n[CVE-2023-29638 (2023-10-17T10:14:15)](https://nvd.nist.gov/vuln/detail/CVE-2023-29638)\n\nWhich renders to:\n\nCVE-2023-29638 (2023-10-17T10:14:15)\n\n Chain Agnostic Improvement Proposals (CAIPs)\n\nLinks to a Chain Agnostic Improvement Proposals (CAIPs) specification may be included using normal markdown syntax, such as:\n\n[CAIP 10](https://github.com/ChainAgnostic/CAIPs/blob/5dd3a2f541d399a82bb32590b52ca4340b09f08b/CAIPs/caip-10.md)\n\nWhich renders to:\n\nCAIP 10\n\nPermitted Chain Agnostic URLs must anchor to a specific commit, and so must match this regular expression:\n\n^(https://github.com/ChainAgnostic/CAIPs/blob/[0-9a-f]{40}/CAIPs/caip-[0-9]+\\.md)$\n\n Ethereum Yellow Paper\n\nLinks to the Ethereum Yellow Paper may be included using normal markdown syntax, such as:\n\n[Ethereum Yellow Paper](https://github.com/ethereum/yellowpaper/blob/9c601d6a58c44928d4f2b837c0350cec9d9259ed/paper.pdf)\n\nWhich renders to:\n\nEthereum Yellow Paper\n\nPermitted Yellow Paper URLs must anchor to a specific commit, and so must match this regular expression:\n\n^(https://github\\.com/ethereum/yellowpaper/blob/[0-9a-f]{40}/paper\\.pdf)$\n\n Execution Client Specification Tests\n\nLinks to the Ethereum Execution Client Specification Tests may be included using normal markdown syntax, such as:\n\n[Ethereum Execution Client Specification Tests](https://github.com/ethereum/execution-spec-tests/blob/d5a3188f122912e137aa2e21ed2a1403e806e424/README.md)\n\nWhich renders to:\n\nEthereum Execution Client Specification Tests\n\nPermitted Execution Client Specification Tests URLs must anchor to a specific commit, and so must match this regular expression:\n\n^(https://github.com/ethereum/execution-spec-tests/(blob|commit)/[0-9a-f]{40}/.*|https://github.com/ethereum/execution-spec-tests/tree/[0-9a-f]{40}/.*)$\n\n Digital Object Identifier System\n\nLinks qualified with a Digital Object Identifier (DOI) may be included using the following syntax:\n\nThis is a sentence with a footnote.[^1]\n\n[^1]:\n ```csl-json\n {\n \"type\": \"article\",\n \"id\": 1,\n \"author\": [\n {\n \"family\": \"Jameson\",\n \"given\": \"Hudson\"\n }\n ],\n \"DOI\": \"00.0000/a00000-000-0000-y\",\n \"title\": \"An Interesting Article\",\n \"original-date\": {\n \"date-parts\": [\n [2022, 12, 31]\n ]\n },\n \"URL\": \"https://sly-hub.invalid/00.0000/a00000-000-0000-y\",\n \"custom\": {\n \"additional-urls\": [\n \"https://example.com/an-interesting-article.pdf\"\n ]\n }\n }\n ```\n\nWhich renders to:\n\nThis is a sentence with a footnote.1\n\nSee the Citation Style Language Schema for the supported fields. In addition to passing validation against that schema, references must include a DOI and at least one URL.\n\nThe top-level URL field must resolve to a copy of the referenced document which can be viewed at zero cost. Values under additional-urls must also resolve to a copy of the referenced document, but may charge a fee.\n\n Execution API Specification\n\nLinks to the Ethereum Execution API Specification may be included using normal markdown syntax, such as:\n\n[Ethereum Execution API Specification](https://github.com/ethereum/execution-apis/blob/dd00287101e368752ba264950585dde4b61cdc17/README.md)\n\nWhich renders to:\n\nEthereum Execution API Specification\n\nPermitted Execution API Specification URLs must anchor to a specific commit, and so must match this regular expression:\n\n^(https://github.com/ethereum/execution-apis/(blob|commit)/[0-9a-f]{40}/.*|https://github.com/ethereum/execution-apis/tree/[0-9a-f]{40}/.*)$\n\n Unicode Technical Standards (UTS)\n\nLinks to Unicode Technical Standards may be included using normal markdown syntax, such as:\n\n[UTS #46](https://www.unicode.org/reports/tr46/tr46-35.html)\n\nWhich renders to:\n\nUTS #46\n\nPermitted UTS URLs must anchor to a specific version, and so must match this regular expression:\n\n^https://www\\.unicode\\.org/reports/tr[0-9]+/tr[0-9]+-[0-9]+\\.html$\n\n Linking to other EIPs\n\nReferences to other EIPs should follow the format EIP-N where N is the EIP number you are referring to. Each EIP that is referenced in an EIP MUST be accompanied by a relative markdown link the first time it is referenced, and MAY be accompanied by a link on subsequent references. The link MUST always be done via relative paths so that the links work in this GitHub repository, forks of this repository, the main EIPs site, mirrors of the main EIP site, etc. For example, you would link to this EIP as ./eip-1.md.\n\n Auxiliary Files\n\nImages, diagrams and auxiliary files should be included in a subdirectory of the assets folder for that EIP as follows: assets/eip-N (where N is to be replaced with the EIP number). When linking to an image in the EIP, use relative links such as ../assets/eip-1/image.png. Prefer SVG diagrams, then PNG, and finally everything else.\n\n Transferring EIP Ownership\n\nIt occasionally becomes necessary to transfer ownership of EIPs to a new champion. In general, we’d like to retain the original author as a co-author of the transferred EIP, but that’s really up to the original author. A good reason to transfer ownership is because the original author no longer has the time or interest in updating it or following through with the EIP process, or has fallen off the face of the ‘net (i.e. is unreachable or isn’t responding to email). A bad reason to transfer ownership is because you don’t agree with the direction of the EIP. We try to build consensus around an EIP, but if that’s not possible, you can always submit a competing EIP.\n\nIf you are interested in assuming ownership of an EIP, send a message asking to take over, addressed to both the original author and the EIP editor. If the original author doesn’t respond to the email in a timely manner, the EIP editor will make a unilateral decision (it’s not like such decisions can’t be reversed :)).\n\n EIP Editors\n\nThe current EIP editors are\n\n Matt Garnett (@lightclient)\n Sam Wilson (@SamWilsn)\n Zainan Victor Zhou (@xinbenlv)\n Gajinder Singh (@g11tech)\n Jochem Brouwer (@jochem-brouwer)\n\nEmeritus EIP editors are\n\n Alex Beregszaszi (@axic)\n Casey Detrio (@cdetrio)\n Gavin John (@Pandapip1)\n Greg Colvin (@gcolvin)\n Hudson Jameson (@Souptacular)\n Martin Becze (@wanderer)\n Micah Zoltu (@MicahZoltu)\n Nick Johnson (@arachnid)\n Nick Savers (@nicksavers)\n Vitalik Buterin (@vbuterin)\n\nIf you would like to become an EIP editor, please check EIP-5069.\n\n EIP Editor Responsibilities\n\nFor each new EIP that comes in, an editor does the following:\n\n Read the EIP to check if it is ready: sound and complete. The ideas must make technical sense, even if they don’t seem likely to get to final status.\n The title should accurately describe the content.\n Check the EIP for language (spelling, grammar, sentence structure, etc.), markup (GitHub flavored Markdown), code style\n\nIf the EIP isn’t ready, the editor will send it back to the author for revision, with specific instructions.\n\nOnce the EIP is ready for the repository, the EIP editor will:\n\n Assign an EIP number (generally incremental; editors can reassign if number sniping is suspected)\n Merge the corresponding pull request\n Send a message back to the EIP author with the next step.\n\nMany EIPs are written and maintained by developers with write access to the Ethereum codebase. The EIP editors monitor EIP changes, and correct any structure, grammar, spelling, or markup mistakes we see.\n\nThe editors don’t pass judgment on EIPs. We merely do the administrative & editorial part.\n\n Style Guide\n\n Titles\n\nThe title field in the preamble:\n\n Should be in title case.\n Should not include the word “standard” or any variation thereof; and\n Should not include the EIP’s number.\n\n Descriptions\n\nThe description field in the preamble:\n\n Should be in sentence case.\n Should not include the word “standard” or any variation thereof; and\n Should not include the EIP’s number.\n\n EIP numbers\n\nWhen referring to an EIP with a category of ERC, it must be written in the hyphenated form ERC-X where X is that EIP’s assigned number. When referring to EIPs with any other category, it must be written in the hyphenated form EIP-X where X is that EIP’s assigned number.\n\n RFC 2119 and RFC 8174\n\nEIPs are encouraged to follow RFC 2119 and RFC 8174 for terminology and to insert the following at the beginning of the Specification section:\n\n The 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\nDon’t use RFC 2119 keywords (all-caps SHOULD/MUST/etc.) outside of the specification section.\n\n History\n\nThis document was derived heavily from Bitcoin’s BIP-0001 written by Amir Taaki which in turn was derived from Python’s PEP-0001. In many places text was simply copied and modified. Although the PEP-0001 text was written by Barry Warsaw, Jeremy Hylton, and David Goodger, they are not responsible for its use in the Ethereum Improvement Process, and should not be bothered with technical questions specific to Ethereum or the EIP. Please direct all comments to the EIP editors.\n\n Copyright\n\nCopyright and related rights waived via CC0.\n\n Jameson, H. (n.d.). An Interesting Article. https://doi.org/00.0000/a00000-000-0000-y (Original work published 2022)\n\n ↩\n\n Citation\n Please cite this document as:\n\n Martin Becze <mb@ethereum.org>, Hudson Jameson <hudson@ethereum.org>, et al., \"EIP-1: EIP Purpose and Guidelines,\" Ethereum Improvement Proposals, no. 1, October 2015. Available: https://eips.ethereum.org/EIPS/eip-1.","tokens":7932,"squid":"spider-05","role":"Spec Spider","at":1791339565567,"hash":"46694f1bf9600e69c2a198f3f39364d73fbbdf2e"}
{"url":"https://docs.switchboard.xyz/miscellaneous/faq","domain":"docs.switchboard.xyz","title":"FAQ | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.What is Switchboard?Switchboard is the leading oracle network designed for customisation and reliability. It's also the first to act as an 'oracle aggregator', meaning it gathers data from multiple sources to enhance accuracy and resilience. For Web3 applications, Switchboard provides easy and verifiable access to a vast range of real-world data – from price feeds and event outcomes to reputation scores and beyond. You can tailor data requests to your exact DApp needs and get data feeds for any Web2 and Web3 assets in less than half a second.What features does Switchboard offer?Switchboard offers a powerful set of features focused on delivering flexible and reliable oracle services:Highly Customisable Data Feeds: Select from existing feeds, aggregate the feeds from other oracles, or create your own specific feed for your application needs.A fully decentralised and resilient network of oracle nodes: Built with a robust network of independent node operators that provide data feeds with maximum uptime and data security.Verifiable and Transparent Data Delivery: On-chain verification ensures trust and auditability of any data feeds.What assets does Switchboard have feeds for?All major price feeds (BTC, ETH, SOL etc.), long tail assets (meme coins, LSTs, LRTs, etc.), and even Web2 data via APIs (public & private)What is the speed of Switchboard oracle?Switchboard is the fastest oracle with Data Feeds operating with an average latency of 400ms and is, on average, four times faster than other oracle providers.What types of data can I get with Switchboard?You can get any data with Switchboard! Think of it like this: if the data exists online, Switchboard can bring it on-chain for your application. Here are just a few examples:Prices: Crypto prices (like the USD price of Bitcoin or Ethereum), stock prices (like Apple, Tesla), commodity prices (like gold, oil).Events: Sports results, weather forecasts, election outcomes, flight delays.Web3 Data: Blockchain gas fees, DeFi lending rates, NFT floor prices, on-chain metrics.Random Numbers: Verifiable random numbers for games or raffles.And much more: Anything accessible via an API – custom data, specific metrics, and specialised information tailored to your needs.What applications can I build with Switchboard oracles?With Switchboard Oracles, you can build applications that react to real-world information and events in a trusted and automated way. Here are some functionalities and examples of what's possible:Price-Sensitive Applications (using Data Feeds): Decentralised exchanges, lending platforms, algorithmic stablecoins, portfolio trackers.Event-Driven Applications (using Real-World Event Data): Prediction markets, insurance payouts, automated betting platforms, conditional contracts.Randomness-Dependent Applications (using Verifiable Randomness): On-chain games, lotteries, fair distribution mechanisms, NFT minting processes.Data-Informed Automation (using any data type): Dynamic pricing based on market conditions, reputation-based systems.Hybrid Web2/Web3 Applications: Bridging the gap between the traditional internet and blockchains by bringing real-world data into smart contracts to enhance functionality and user experience.Why would I choose Switchboard vs competitors?Here are the key reasons to choose us over competitors:Maximum Customisation: Tailor data feeds to your exact needs – any source, any logic.Superior Reliability via Aggregation: The first oracle aggregator for robust and accurate data.Broadest Data Access: Unlock virtually any onchain or offchain data, not just price feeds.Developer-First Approach: Easy-to-use data feed creation tools and excellent documentation for smooth integrations.Unmatched Speed: On average, Switchboard data feeds are four times faster than the closest oracle competitor. This speed advantage is critical for applications demanding near real-time data updates.What is the SWTCH token and how do I get it?SWTCH is Switchboard's governance and utility token that powers the network's economic security model. Token holders can stake SWTCH to receive svSWTCH (staked-vote SWTCH), which provides voting power, network rewards, and enhanced data access. SWTCH tokens become available starting September 9th, 2025 through a claim portal for eligible participants including oracle operators, points program participants, and early supporters. For complete details, see our SWTCH Token Overview.How do I participate in Switchboard governance?Switchboard operates on a decentralized governance model powered by svSWTCH holders. To participate: (1) Claim or acquire SWTCH tokens, (2) Stake them through Jito's NCN vault to receive svSWTCH, (3) Use svSWTCH to vote on proposals covering oracle operations, economic parameters, protocol fees, and technical development. Learn more in our Governance & Tokenomics guide.Can I earn rewards by staking with Switchboard?Yes! You can earn SWTCH rewards by staking supported assets (SOL, JitoSOL, BNSOL, mSOL) through Switchboard's Jito NCN integration. Rewards are distributed every Solana epoch (~3 days) from protocol fees and SWTCH subsidies. Oracle operators with more svSWTCH delegation receive more work and higher rewards. Start staking through the Fragmetric vault.PreviousSurge Subscription GuideNextGlossaryLast updated 9 months ago","tokens":1354,"squid":"spider-08","role":"Oracle Spider","at":1791339568521,"hash":"c121e8f67b0b1b213528a75e86b76f695ade072f"}
{"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":"spider-05","role":"Spec Spider","at":1791339575616,"hash":"20b945faaed92cb5392a7e4b16808ae895acb2b3"}
{"url":"https://docs.switchboard.xyz/ai-agents-llms/sail","domain":"docs.switchboard.xyz","title":"SAIL | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.SAIL is Switchboard's attestation layer for hardware-backed oracle and runtime verification. It uses Trusted Execution Environments (TEEs), currently AMD SEV-SNP, to provide evidence that critical Switchboard runtime code is running in an isolated environment before that runtime is trusted by the network.For AI agents and autonomous systems, this matters because the data and services they depend on need a clear trust boundary. SAIL helps answer a narrower, more concrete question: did this Switchboard runtime produce an attestation report showing it is running the expected code in the expected hardware-backed environment?SAIL does not, by itself, prove that an arbitrary AI model made the right decision, that an agent followed every business rule, or that a smart contract is correct. It provides hardware-backed evidence about the runtime that produced or signed data, which applications can combine with normal on-chain checks, quote verification, and application-level authorization.What SAIL ProvidesHardware-backed runtime evidence - Switchboard runtimes can produce AMD SEV-SNP attestation evidence that guardians and other verifiers can inspect before trusting the runtime.Verified oracle execution - Switchboard uses attestation to confirm that oracle infrastructure is running approved code before it participates in sensitive network workflows.TEE-derived runtime identity - SAIL exposes helpers for deriving enclave-bound keys, so a runtime can sign or identify itself from material tied to the TEE environment.Runtime randomness helpers - SAIL includes randomness utilities for code running inside these environments. Treat these as low-level runtime helpers, not a replacement for chain-specific Switchboard randomness products.Where SAIL Shows Up TodaySAIL is part of the infrastructure behind Switchboard's verified oracle network.The TEE architecture page explains why Switchboard uses TEEs and AMD SEV-SNP.The Surge docs describe price streaming through a SAIL-verified oracle network for Solana/SVM, EVM, and Sui.The current advanced SDK surface is @switchboard-xyz/sail-sdk. It is intended for low-level attestation and runtime work, not as a beginner application tutorial.There is not currently a runnable SAIL example in sb-on-demand-examples. Start with the linked architecture and product docs unless you are working directly on TEE runtime integration.Current Developer SurfaceThe SAIL SDK exposes low-level primitives used by Switchboard runtime infrastructure:AMD SEV-SNP attestation helpers for generating attestation reports/evidence.JSON attestation helpers for newer Confidential Containers (CoCo) environments.Verification helpers for attestation evidence, including an optional verifier feature.Enclave-derived key helpers for Ed25519 and secp256k1 runtime identities.Runtime randomness helpers for TEE-bound code.These APIs are advanced infrastructure tools. Most application developers should consume Switchboard through the chain-specific feed, randomness, Surge, or Crossbar docs instead of integrating SAIL directly.PreviousOverviewNextSwitchboard Agent SkillLast updated 4 months ago","tokens":805,"squid":"spider-08","role":"Oracle Spider","at":1791339578738,"hash":"de563385fc1b4204fd3678bcfa0a9611bb496739"}
{"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":"spider-05","role":"Spec Spider","at":1791339585848,"hash":"c9467be672d3b7a794da1895a03c1aa2f3ddccf4"}
{"url":"https://eips.ethereum.org/EIPS/eip-5069","domain":"eips.ethereum.org","title":"EIP-5069: EIP Editor Handbook","text":"🎉 Living\n\n Meta\n\n EIP-5069: EIP Editor Handbook\n\n Organizational structure, decision making process, and other EIP Editor odds and ends.\n\n Authors\n Pooja Ranjan (@poojaranjan), Gavin John (@Pandapip1), Sam Wilson (@SamWilsn), et al.\n\n Created\n 2022-05-02\n\n Discussion Link\n https://ethereum-magicians.org/t/pr-5069-eip-editor-handbook/9137\n\n Requires\n\n EIP-1\n\n Introduction\n\nWe, the Ethereum Improvement Proposal (EIP) Editors, maintain a repository of documents related to the Ethereum protocol and its ecosystem. Consider us both archivists making sure the community as a whole does not lose its history, and a publisher making sure interested parties can stay up-to-date with the latest proposals.\n\n Mission\n\n What we Do\n\nOur mission is to serve the broad Ethereum community, both present and future, by:\n\n Publishing Proposals: Making proposals, including their history and associated discussions available over the long term at no cost.\n\n By doing so, we foster transparency and ensure that valuable insights from past proposals are accessible for future decision-making and learning.\n\n Facilitating Discussion: Providing a forum for discussing proposals open to anyone who wants to participate civilly.\n\n By encouraging open dialogue and collaboration, we aim to harness the collective knowledge and expertise of the Ethereum community in shaping proposals.\n\n Upholding Quality: Upholding a measure of minimally-subjective quality for each proposal as defined by its target audience.\n\n By adhering to defined criteria, we promote the development of high-quality and relevant proposals that drive the evolution of Ethereum.\n\n What we Don’t\n\nOn the other hand, we do not:\n\n Decide Winners: If there are multiple competing proposals, we will publish all of them. We are not in the business of deciding what is the right path for Ethereum, nor do we believe that there is One True Way to satisfy a need.\n\n Assert Correctness: While we might offer technical feedback from time to time, we are not experts nor do we vet every proposal in depth. Publishing a proposal is not an endorsement or a statement of technical soundness.\n\n Manage: We do not track implementation status, schedule work, or set fork dates or contents.\n\n Track Registries: We want all proposals to eventually become immutable, but a registry will never get there if anyone can keep adding items. To be clear, exhaustive and/or static lists are fine.\n Provide Legal Advice: Trademarks, copyrights, patents, prior art, and other legal matters are the responsibility of authors and implementers, not EIP Editors. We are not lawyers, and while we may occasionally make comments touching on these areas, we cannot guarantee any measure of correctness.\n\nDocumenting all of the things we would not do is impossible, and the above are just a few examples. We reserve the right to do less work whenever possible!\n\n Structure\n\n EIP Editors\n\nWe, the Editors, consist of some number of EIP Editors and one Keeper of Consensus (or just Keeper for short) elected by and from the EIP Editors.\n\nEIP Editors are responsible for governing the EIP process itself, electing a Keeper, and stewarding proposals.\n\nThe Keeper’s two responsibilities (on top of their EIP Editor duties) are: to determine when rough consensus has been reached on a matter, and determine when/if it is appropriate to re-open an already settled matter.\n\n EIP Coordinators\n\nAlongside the Editors, we recognize zero or more EIP Coordinators selected by the EIP Editors.\n\nEIP Coordinators support the operational and educational aspects of the EIP process by helping authors navigate the process, following up on process-related work, and maintaining relevant documentation. They do not perform editorial review or determine whether a proposal is accepted or rejected.\n\nEditors may delegate mechanical administrative work to Coordinators as described under Membership.\n\n Membership\n\n Becoming an EIP Editor\n\nAnyone may apply to join as an EIP Editor. Specific eligibility requirements are left to individual current EIP Editors, but the general requirements are:\n\n A strong belief in the above mission;\n Proficiency with English (both written and spoken);\n Reading and critiquing EIPs;\n Participation in governance.\n\nEIP Editors are expected to meet these requirements throughout their tenure, and not doing so is grounds for removal. Any member may delegate some or all of their responsibilities/powers to tools and/or to other people.\n\n Becoming an EIP Coordinator\n\nIn addition to the EIP Editor membership requirements above, EIP Coordinators are expected to demonstrate:\n\n Strong familiarity with the EIP process and its workflows;\n Experience helping authors and contributors navigate the EIP process;\n Experience coordinating process-related work, including follow-ups and documentation;\n An ability to remain neutral on the technical intent and merits of individual EIPs.\n\nEIP Coordinators do not need to meet the requirements for reading and critiquing the technical content of EIPs or participation in governance, as these responsibilities remain with EIP Editors. EIP Coordinators are expected to meet these requirements throughout their tenure, and not doing so is grounds for removal.\n\n Making Decisions\n\n Informally\n\nFor decisions that are unlikely to be controversial—especially for decisions affecting a single proposal—an EIP Editor may choose whatever option they deem appropriate in accordance with our mission.\n\n Formally\n\nElecting a Keeper, adding/removing EIP Editors, adding/removing EIP Coordinators, and any possibly-controversial decisions must all be made using variations of this formal process.\n\n Preparation\n\n Call for Input\n\nFor any matter requiring a decision, a call for input must be published in writing to the usual channels frequented by EIP Editors.\n\n Quorum\n\nWithin thirty days of the call for input, to establish a valid quorum, all EIP Editors must express their opinion, vote (where appropriate), or lack thereof on the matter under consideration.\n\nAfter thirty days from the call for input, if not all EIP Editors have responded, the quorum is reduced to the Editors that have responded. This deadline may be extended in exceptional situations.\n\n Deciding\n\n Electing a Keeper of Consensus\n\nAny EIP Editor can call for an election for Keeper. Business continues as usual while the election is running. The EIP Editor with the most votes once quorum is met is named Keeper until the next election completes. If there is a tie, we’ll randomly choose between the EIP Editors with the most votes, using a fair and agreed upon method (for example, a coin toss over a video call or a commit/reveal game of rock paper scissors.)\n\n Adding an EIP Editor\n\nAn EIP Editor is added once quorum is met, provided the candidate consents and no current EIP Editor objects.\n\n Removing an EIP Editor\n\nAn EIP Editor is involuntarily retired once quorum is met, provided no current EIP Editor (aside from the one being removed) objects. An EIP Editor may voluntarily leave their position at any time.\n\nIf the departing Editor was also the Keeper, an election for a new Keeper begins immediately.\n\n Adding or Removing an EIP Coordinator\n\nAn EIP Coordinator is added or involuntarily removed through the “rough consensus” process described under Other Decisions below, provided (when adding) the candidate consents. An EIP Coordinator may voluntarily leave their position at any time.\n\n EIP Coordinator Participation in Decisions\n\nEIP Coordinators do not have voting rights and do not participate in determining rough consensus. They may provide process-related information, operational context, and feedback to EIP Editors, but decision-making authority remains with the EIP Editors as defined above.\n\n Other Decisions\n\nAll other decisions (including, for example, adding EIP coordinators) are made through a “rough consensus” process. This does not require all EIP Editors to agree, although this is preferred. In general, the dominant view of the Editors shall prevail. Dominance, in this process, is not determined by persistence or volume but rather a more general sense of agreement. Note that 51% does not mean “rough consensus” has been reached, and 99% is better than rough. It is up to the Keeper to determine if rough consensus has been reached. Every EIP Editor is entitled to have their opinion heard and understood before the Keeper makes that determination.\n\nNo one, not the EIP Editors and certainly not the Keeper, holds veto powers (except when adding/removing an Editor as defined above.) It is imperative that the EIP process evolve, albeit cautiously.\n\nThis section has been adapted from RFC 2418.\n\n Copyright\n\nCopyright and related rights waived via CC0.\n\n Citation\n Please cite this document as:\n\n Pooja Ranjan (@poojaranjan), Gavin John (@Pandapip1), Sam Wilson (@SamWilsn), et al., \"EIP-5069: EIP Editor Handbook,\" Ethereum Improvement Proposals, no. 5069, May 2022. Available: https://eips.ethereum.org/EIPS/eip-5069.","tokens":2246,"squid":"spider-05","role":"Spec Spider","at":1791339595750,"hash":"623f3d7967c8fae2a0cdf1f893a842761b8c8404"}
{"url":"https://across.to/?from=arbitrum&to=hypercore&inputToken=USDT0&outputToken=USDC-SPOT","domain":"across.to","title":"Across Protocol - Transfer Assets Between Layer 2s and Mainnet","text":"Bridge & swap across chainsFast. Cheap. Secure.FromToAcross V4THE CROSSCHAIN BRIDGEMove money across chains. Fast, cheap, secure.Across is the bridge that just works. Bridge and swap tokens between any supported chain in seconds. Enjoy low fees, no custodial risk, and the reliability to handle any transfer size. Over $40B moved. No user funds lost.Billions bridged. Trusted by the best.Numbers don't lie. Across powers crosschain transfers for the biggest names in crypto and millions of users around the world.volume$40B+Dollars moved across chains by users and apps that rely on Across to deliver, every single time.users5MPeople trust Across with their money. From first-time bridgers to institutions moving millions.avg speed1.2SAverage time from confirmation to funds in your wallet. Most transfers land in under two seconds.volume$40B+Dollars moved across chains by users and apps that rely on Across to deliver, every single time.users5MPeople trust Across with their money. From first-time bridgers to institutions moving millions.avg speed1.2SAverage time from confirmation to funds in your wallet. Most transfers land in under two seconds.UniswapUniswap integrated Across to bring native crosschain transfers directly into its app.In-app bridgingNative supportEasy integrationEmbedding token bridging directly into the Uniswap app\"Users shouldn't have to switch between tabs to bridge tokens. We wanted to add crosschain bridging without adding complexity. Across gave us a single integration that covered a vast majority of chains we needed, with fast settlement and low fees out of the box.\"Medha KothariProduct @ UniswapRead Docsconst params = new URLSearchParams({ tradeType: \"exactInput\", amount: \"10000000\", // 10 USDC inputToken: \"0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913\", outputToken: \"0x078D782b760474a361dDA0AF3839290b0EF57AD6\", originChainId: \"8453\", // Base destinationChainId: \"130\", // Unichain depositor: wallet.account.address,});const quote = await fetch( `https://app.across.to/api/swap/approval?${params}`, { headers: { Authorization: `Bearer ${KEY}` } },).then((r) => r.json());for (const tx of quote.approvalTxns ?? []) await wallet.sendTransaction(tx);await wallet.sendTransaction(quote.swapTx);Need any help?Need any help?const params = new URLSearchParams({ tradeType: \"exactInput\", amount: \"10000000\", // 10 USDC inputToken: \"0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913\", outputToken: \"0x078D782b760474a361dDA0AF3839290b0EF57AD6\", originChainId: \"8453\", // Base destinationChainId: \"130\", // Unichain depositor: wallet.account.address,});const quote = await fetch( `https://app.across.to/api/swap/approval?${params}`, { headers: { Authorization: `Bearer ${KEY}` } },).then((r) => r.json());for (const tx of quote.approvalTxns ?? []) await wallet.sendTransaction(tx);await wallet.sendTransaction(quote.swapTx);Need any help?Need any help?UniswapUniswap integrated Across to bring native crosschain transfers directly into its app.In-app bridgingNative supportEasy integrationEmbedding token bridging directly into the Uniswap app\"Users shouldn't have to switch between tabs to bridge tokens. We wanted to add crosschain bridging without adding complexity. Across gave us a single integration that covered a vast majority of chains we needed, with fast settlement and low fees out of the box.\"Medha KothariProduct @ UniswapRead Docs#PoweredByAcrossWhy Across?Moving funds between chains should be easy. Across delivers fast settlement, low fees, deep liquidity, proven security, and a simple experience for users and builders alike.READ DOCSBattle-tested. No user funds lost.Billions bridged with no user funds lost. Every transfer is verified onchain with no multisigs and no custodial risk. Trusted by the leading apps in DeFi.LEARN MOREFast by defaultAcross uses an intent-based design to deliver near-instant transfers. By the time other bridges quote, your transaction is already done.LEARN MORELower fees, every timeKeep more of your money. Across is built to minimize costs on every transfer. No aggregator markup, no hidden fees. What you see is what you pay.LEARN MOREDecentralized & permissionlessNo 1/1 configurations. No single points of failure. Across runs on a permissionless relayer network where anyone can compete to fill transfers.LEARN MOREOne integration, many chainsAdd crosschain bridging to your app with a single API. Clean docs, responsive support, and no aggregator dependencies. Your users will love you for it.LEARN MORETHE ACROSS BLOGResources for a crosschain worldJul 14, 2026Robinhood Chain's First Week: CashCat, $1B in DEX Volume, and How to Get There 4 MIN READ#ResearchAug 10, 2026Across Integrates Paxos Labs' Transit for $50M Transfers 3 MIN READ#PartnersJul 27, 2026Canonical Bridges vs Third-Party Bridges: What's the Difference? 5 MIN READ#BasicsJul 15, 2026Bridge ETH to Base in Under 2 Seconds 4 MIN READ#GuidesJul 14, 2026Robinhood Chain's First Week: CashCat, $1B in DEX Volume, and How to Get ThereCashCat, a flipped Hyperliquid, and $1 billion in week-one DEX volume: what actually happened on Robinhood Chain's first week, and how to bridge in while it's moving. 4 MIN READ#ResearchAug 10, 2026Across Integrates Paxos Labs' Transit for $50M Transfers 3 MIN READ#PartnersJul 27, 2026Canonical Bridges vs Third-Party Bridges: What's the Difference? 5 MIN READ#BasicsJul 15, 2026Bridge ETH to Base in Under 2 Seconds 4 MIN READ#GuidesREAD MORE ARTICLESThe Across EcosystemSupported ChainsBridge tokens across Ethereum, Hyperliquid, Base, Solana, BSC, and a growing list of supported networks.EthereumArbitrumRobinhoodArcOptimismBasePolygonSolanazkSyncLineaModeLensLighterLiskZoraWorld ChainInkSoneiumUnichainBNB Smart ChainHyperEVMPlasmaHyperCoreMonadMegaETHTempoTronAvalanche","tokens":1440,"squid":"spider-09","role":"Bridge Spider","at":1791339597255,"hash":"a18df64e8caccba541388dd5aa5895ee96f4167b"}
{"url":"https://docs.switchboard.xyz/custom-feeds/build-and-deploy-feed/build-with-ui","domain":"docs.switchboard.xyz","title":"Build with UI | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.Switchboard feeds are built from Oracle Jobs (your data sources) and Tasks (the steps that fetch + transform data). The Feed Builder UI lets you assemble these visually, simulate them, and (when applicable) publish or deploy them.If you prefer code-first workflows, see: Building custom feeds in TypeScript.What you can do with the Feed BuilderUse the Feed Builder to:Start from scratch or clone an existing feed, then customize its job list.Build each job as a sequential pipeline of tasks (HTTP requests, JSON parsing, math transforms, DEX pricing tasks, etc.).Simulate job execution to validate that each job returns a numeric result.Configure feed-level validation + freshness rules (variance, quorum, staleness, sampling).Produce a feed address/ID you can use in on-chain programs and apps.Open the builder here:https://explorer.switchboardlabs.xyz/feed-builderCore concepts (quick mental model)Feed → Jobs → TasksA Feed is the thing your program/app reads: a single numeric value (plus metadata like timestamp/slot).A feed is composed of Jobs.A Job is a deterministic pipeline of Tasks (executed in order).Each job must end with a numeric output.The oracle network resolves the feed by aggregating job outputs (commonly a median across jobs).Think of it like:Feed\n ├─ Job 1: [ Task A → Task B → Task C ] => number\n ├─ Job 2: [ Task A → Task D ] => number\n └─ Job 3: [ Task E ] => number\n ↓\n Aggregate (e.g., median)\n ↓\n Feed valueQueue (oracle subnet)A Queue is the set of oracles that will resolve your feed. Feeds are always associated with a specific queue.Simulation vs deploymentSimulation: run your job(s) against real sources off-chain to validate logic and observe outputs.Deployment: Store your feed definition with Crossbar to get a feed hash/ID. On all chains, feeds use canonical accounts derived from this ID—no explicit account creation needed.This page focuses on building and simulating with the UI.Step-by-step: Build a feed in the UI1) Choose your target networkIn the upper-right, use the network/settings control to select the network you’re building against (e.g., mainnet vs devnet/testnet).Why this matters:It determines the available queues/oracle networks and how IDs/addresses are derived.It affects simulation defaults and explorer routing.2) Start from an existing feed (recommended)If you’re building a common pair (like BTC/USD), start by selecting an existing feed and customizing it:Browse/search for the pair you want.Open it to inspect its configuration.Remove jobs you don’t want (trash/delete icon).Edit jobs to adjust sources or task pipelines.This is the fastest way to learn what “good” looks like for your use case.3) Add or edit jobsEach job represents a distinct data source and/or retrieval strategy.A solid starting point is 3+ jobs from independent sources. For price feeds, aim for liquidity-heavy venues and reduce correlated risk.Common task pipeline patternMost HTTP/API sources follow this pattern:HttpTask: fetch JSON from a REST endpointJsonParseTask: extract a numeric field using JSONPathOptional math tasks: normalize decimals, invert price, etc.Optional bound/validation tasks: reject outliersExample tasks (conceptual):[\n { \"httpTask\": { \"url\": \"https://api.exchange.com/price?symbol=BTCUSD\" } },\n { \"jsonParseTask\": { \"path\": \"$.price\" } },\n { \"multiplyTask\": { \"multiplier\": \"100000000\" } }\n]Task reference: Task Types Reference4) Configure feed-level validation and freshnessThe Feed Builder exposes common feed-level configuration knobs:Basic settingsName: the label shown in the explorer UI.Authority: the address allowed to modify feed settings later (useful for DAO/governance control).Advanced settingsMax Variance: maximum allowed deviation between job results for an update to be accepted.Min Responses: minimum number of successful job results required to accept an update.Sample Size: how many samples are considered when reading a feed.Max Staleness: how old a sample can be before it is considered invalid.These parameters are your “guardrails”—they trade off liveness vs correctness. Start conservative, then tune based on observed behavior.Feed parameter units are surface-specific. Raw v2 maxJobRangePct is scaled by 1e9, while some UI and SDK fields accept human percentages. See Feed Parameter Units before copying values between surfaces.5) Simulate and debugUse the UI’s simulation flow to validate:Every job returns a numberResults are in the same units/decimals across jobsOutliers are either prevented by job logic or rejected by feed-level settingsIf a job fails, typical causes include:Bad URL / rate limitsJSONPath returns an array or string instead of a numericAPI returns a different schema than expectedTip: When debugging, simplify the job:Start with HttpTask + JsonParseTaskAdd transforms only after you see a clean numeric output6) Create / publish the feedWhen you’re satisfied:Use Connect Wallet to associate an authority with the feed.The UI will create/publish the feed and redirect you to a status/details page.Copy the resulting feed address/ID — you’ll need it for on-chain integration.Best practices for robust custom feedsUse independent sourcesAvoid three endpoints that all ultimately depend on the same upstream price.Normalize outputsMake sure every job returns the same unit:same base/quotesame decimals (use multiply/divide tasks to standardize)Prefer median-style aggregationMedian aggregation is naturally robust to single-source outliers.Bound outliersUse bounding/validation where it makes sense (especially for thinly traded or highly volatile assets).Secrets and API keys: do it safelyIf you need authenticated APIs:use dedicated secrets/variable mechanismsnever hardcode keys into a job definition that you intend to share publiclyNext stepsBuild with codeDeploy on-chainTask Types ReferencePreviousBuild and Deploy FeedNextBuild with TypeScriptLast updated 3 months ago","tokens":1495,"squid":"spider-08","role":"Oracle Spider","at":1791339598189,"hash":"6a4812055435abc31530eb75af843e609c3c13ed"}
{"url":"https://forum.arbitrum.foundation/t/govhack-ethcc-brussels-2024-impact-report-hack-humanity/26530/18","domain":"forum.arbitrum.foundation","title":"GovHack ETHcc Brussels 2024 - Impact Report - Hack Humanity - Archive / GovHack Brussels - Arbitrum","text":"The Arbitrum Foundation notified the Security Council on the need to perform a potential Emergency action. Following a review of the details and known risks, the Security Council decided to execute the upgrade and it was completed at 11:30 EST on 2nd October 2026.\nThis report provides an overview of the risks that required the Security Council Action:\n\nAdd a permissionless guard for the One-Step Proof of BoLD on Arbitrum One\n\nTemporarily pause activation of new Stylus contracts on Arbitrum One & Nova\n\nKey point: To date, known bugs for Stylus primarily impact chain liveness (e.g., denial of service attacks) and do not put any user funds at risk.\nWhy was this action taken\nLet’s take this opportunity to explain why action was taken on two separate issues concerning BoLD and Stylus.\nInstalling the guard for One-Step Proof of BoLD. Given the rise of AI-assisted attacks, we have implemented a precautionary approach that allows anyone to pause settlement of Arbitrum One on Ethereum if there are at least two conflicting answers that pass at the same level in which only one should be valid and pass. This is to halt a class of publicly verifiable and detectable attacks that exploit a bug in the one-step proof. If halted, Arbitrum One will continue to process as normal except that messages from Arbitrum One to Ethereum, such as withdrawals, that are not yet confirmed will have to wait. This provides time for the Security Council to deploy a fix for the bug and resume the rollup.\nPreventing activation of new Stylus contracts. AI-assisted tooling has led to an increasing number of sophisticated attacks on hand-crafted WASM programs that do not use the standard Stylus compiler toolchain. These programs are specifically designed to cause unexpected behaviors such as degrading the chain’s performance for all other users. To date, no attacks have been discovered that permits theft of user funds.\nNew ArbOS releases have patched several reported bugs and known attacks over the past few months, but out of an abundance of caution, we have decided to temporarily pause new activations of Stylus contracts. This was executed as an emergency action to prevent the deployment of new hand-crafted WASM programs that are not yet patched by the current version of ArbOS on the Arbitrum network.\nThe Arbitrum Foundation has informed the Security Council that they will work with the ArbitrumDAO to discuss next steps on the timeline and manner for enabling activation of new Stylus contracts. The Arbitrum community remains confident in the value of Stylus and want to preserve these use cases while taking preventative measures against Stylus-based attack vectors as AI-assisted attack tooling continues to evolve.\nImpact on builders and users\n\nNo new activations. New Stylus contracts cannot be activated during the pause including new versions of existing applications that require activation.\n\nExisting contracts are not paused. Already-active Stylus contracts continue to execute until expiration. This pause does not deactivate them.\n\nThe ArbOS 61 upgrade renewed all active contracts on Arbitrum One, so no currently active contract expires before August 20, 2027.\n\nRenewal via keepalive stays permissionless and is unaffected by the pause.\n\nReactivating an expired contract, or one that needs to be updated after a Stylus version change, is paused.\n\nUsing/calling any activated Stylus contract stays permissionless for all users and developers.\n\nNo impact on EVM. Solidity (EVM) contract deployment and execution are unaffected by this Security Council action.\n\nSecurity Council Actions\nThere are two actions bundled into a single payload:\n\nOne-Step Proof Guard. The L1UpgradeExecutor gives a new pause contract (PauseExecutor) the ability to pause and nothing else. The new pause contract grants the guard (OspSoundnessGuard) PAUSER_ROLE to use it. Anyone can show the guard two conflicting answers to the same step of an open challenge. If the one-step proof accepts both, the guard has the pause contract put Arbitrum One’s settlement to Ethereum on hold.\n\nStylus deactivation. The Security Council called ArbOwner.setWasmActivationGas(2^64 - 1) to raise the Stylus activation gas requirement on Arbitrum One and Nova. This makes activation prohibitively expensive and effectively disables new activations. This is a configuration change and does not require an ArbOS upgrade.\n\nThe Security Council signed the following transactions to update the configuration:\n\nEthereum: Ethereum Transaction Hash: 0x30732bb7d2... | Etherscan\nArbitrum One:\nArbitrum One Transaction Hash: 0x9eb3a4be3b... | Arbitrum One\nArbitrum Nova:\nArbitrum Nova transaction 0x79e0fed470dff7a22059b108e3f8f42eddd2b580a6771594060c4e7326c5f984 | Blockscout\n\nAn external audit was conducted for the OSP Guard contracts. No audit is required for the Stylus deactivation as it is only updating a single parameter in the ArbOS configuration.\n\n ArchiveGovHack Brussels\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 16\n min\n\n Aug 2024\n\n 18 / 20\n\n Sep 2024\n\n Sep 2024\n\n post by KlausBrave on Aug 28, 2024\n\n KlausBrave\n\n Arbitrum GovHack Brussels 2024 - Impact Report\n1200×675 392 KB\nTitle: GovHack ETHcc Brussels 2024\nProposal ID: Arbitrum GovHack Brussels 2024\n\nExecutive Summary\nArbitrum GovHack Brussels 2024, a three-day event held just before EthCC, brought together over 200 participants from 16 countries to drive governance innovation within the Arbitrum ecosystem. The event culminated in the submission of 25 high-quality proposals across 10 tracks, each designed to enhance the DAO’s operations and strategic direction. This hackathon not only fostered deeper community relationships but also showcased the transformative potential of decentralized governance.\nHighlights:\n\nArbitrumDAO participated in a mapathon process, involving 50+ delegates and contributors to identify and prioritise key challenge areas for the DAO, 10 key tracks and challenge statements as strategic focus areas were identified\n\n185 registered, 110+ participants attended in 28 teams\n\n200+ total participants across 3 days\n\n16 Countries represented\n\n25 proposals submitted, 6 being continued\n\n9 Pitstop Experts provided a total of 168 expert feedback sessions to teams on their proposals\n\n20 scholarships offered\n\n3 panels\n\n5 winning finalists with a $20k prize pool awarded\n\n9.5 star rating and 83 NPS from participants\n\nTo capture the essence of the event, checkout the 4-minute after-movie:\n\n Arbitrum GovHack Brussels 2024 Aftermovie\n\nIntroduction\nThe Arbitrum GovHack Brussels 2024 was conceived as a pivotal event to further the decentralized governance efforts of the Arbitrum ecosystem. Building on the success of the GovHack held earlier in Denver, this Brussels edition aimed to elevate the community’s engagement and solidify Arbitrum’s position as a leading force in decentralized governance.\nBackground and Motivation\nGovHack Brussels was strategically scheduled to take place on July 5-7, 2024, just before one of the most significant Ethereum-centric events, ETHcc, in Brussels. This timing was chosen to maximize the impact of the event, ensuring that Arbitrum had a strong presence during a crucial gathering of the Ethereum community.\nThe success of the Denver event (GovHack Denver Impact Report) had already demonstrated the value of in-person collaborations in fostering innovation and strengthening the network of contributors, delegates, and service providers within the DAO.\nHack Humanity, the organiser of both GovHack events, secured $309k in funding from the Arbitrum DAO to execute this initiative (actual funds spent $262k detailed in the finances section of this report).\nThe DAO voted 99% in favour of producing GovHack and continuing the tradition that started in Denver.\nThe goal was to leverage the momentum gained from the Denver event, while expanding the scope and ambition for Brussels. This included a larger prize pool, the introduction of a subsidy pool for high-value contributors, and enhanced community engagement through a dedicated afterparty and a community showcase day.\nObjectives of GovHack Brussels\nThe primary objectives of GovHack Brussels were to:\n\nStrengthen Trust and Relationships: Build deeper connections between Arbitrum contributors and foster a high-trust environment essential for decentralized governance.\n\nIdeation and Implementation: Encourage the creation and eventual implementation of innovative proposals that could benefit the Arbitrum ecosystem.\n\nAttract New Talent: Position Arbitrum as the go-to platform for new and existing talent to build and contribute to the DAO’s growth and success.\n\nEnhance Brand and Community Presence: Ensure that Arbitrum maintains a strong and influential presence at industry-leading events, particularly those focused on Ethereum, to continue attracting users, developers, and key contributors.\n\nGovHack Brussels was designed not just as a standalone event, but as a critical step in a broader strategy to cultivate a resilient, innovative, and inclusive ecosystem and sustainable DAO. By focusing on in-person interactions and providing a structured environment for proposal development, the event aimed to produce tangible outcomes that would drive the DAO forward.\nIn the following sections, this report will delve into the specific outcomes of GovHack Brussels, examining how it met its objectives and the impact it had on the Arbitrum community and ecosystem.\n\nMethodology\nImplementation Process\nGovHack Brussels 2024 employed a comprehensive and structured approach designed to maximize the potential for innovative governance proposals within the Arbitrum ecosystem. The event was built upon a series of carefully planned activities to identify key challenges, facilitate collaboration, and guide teams through the proposal development process.\n\nPre-Event Mapathons: The event preparation began with two virtual mapathons, strategically scheduled across different time zones to ensure broad participation. These sessions provided a platform for participants to express their concerns, hopes, and brainstorm potential problems and solutions. The ideas generated were clustered, prioritized, and organized into thematic tracks, which were then explored through SWOT analyses and challenge statements developed in breakout rooms.\n\n1600×796 165 KB\n1238×624 131 KB\n\nAccess the recordings and Miro boards from the mapathons:\n\nMapathon Round 1 - recording - Jun 17 04 PM CET\n\nMapathon Round 2 - Jun 26 10 AM CET\n\nCombined results\n\nTrack Identification and Participant Alignment: The mapathon process led to the identification of ten key tracks, each aligned with the most pressing needs of the DAO. These tracks provided a focused framework for participants to align their skills and ideas. The contributor roles were designed with two main objectives:\n\n882×491 120 KB\n\nSkill Diversity: Encourage the formation of teams with a balanced mix of technical, design/research, and business/governance expertise.\n\nProposal Relevance: Assist contributors in developing proposals that directly address the specific challenges outlined in each track.\n\nTrack hosts:\nEngagement from key stakeholders really makes GovHack shine, the following valued members of Arbitrum community stepped up to be Track hosts to guide participants in rapidly getting high context on each track, selecting or developing a challenge statement and were supported by HackHumanity’s co-facilitator team with helping individuals in team formation.\nTrack hosts and their talks:\n1. Ana María Yanakieva - Ventures @ana.vc\n2. AnaTech and Rezvan - Marketing @AnaTech.eth @ZER8\n3. Disruption Joe and Raam - IRL Community @DisruptionJoe\n4. Matt Fiebach - DAO budget & revenue @MattOnChain\n5. David - Orbit, Stylys, & Infra @davidgarcia\n6. Matt Hamilton - DevRel\n7. Siddharth Shah - RWA @sid_areta\n8. Coolhorse girl - GovTech\n9. Rick - Gaming @rickjohanson\n10. Lucca Gets - Decentralized sequencer\nTrack Hosts overview video:\n\n Track Host Intros Overview | Arbitrum GovHack Brussels 2024\n\nExpert Pitstops\nDuring Days 1 & 2 of GovHack, three educational talks were hosted, and one of the standout features from GovHack, the “Expert Pitstop,” saw nine Arbitrum experts providing live feedback and consultation to 25 teams. This support significantly enhanced proposal development, offering insights and clarity beyond what is possible through forum posts.\nPitstop Experts:\n\nAlex Lumley\n\nCliffton\n\nCoinFlipCanada\n\nDisruption Joe\n\nDK @dk3\n\nFrisson\n\nGeorge Beall\n\nKrzysztof Urbański and Sinkas (L2Beat)\n\nLucas Fulks\n\nThe Expert Pitstops allowed participants to not only improve their proposals but also to deepen their understanding of the Arbitrum ecosystem, fostering a sense of confidence and trust in their projects.\nGrants Programs Overview\nGovHack Brussels 2024 offered participants several key grant opportunities to support the development and implementation of their proposals. These resources were crucial in encouraging participants to think about the long-term impact of their projects within the Arbitrum ecosystem.\n\nThank Arbitrum Grants Programs Overview:\nA guide to the available grants within the Arbitrum ecosystem, helping participants navigate the funding landscape effectively. Explore the guide here.\n\nSeedGov - QuestBook:\nThis platform provided tools and resources for proposal development and grant applications, aiding participants in refining their ideas and securing necessary funding. Access SeedGov - QuestBook here.\n\nUniswap Arbitrum Grants Program:\nAimed at supporting innovative projects within Arbitrum, this program offered another funding avenue for teams. Learn more here.\n\nArbitrum Foundations Grant program\n\nA video summary of Grant programs is here:\n\n Grant Opportunities Overview | Arbitrum GovHack Brussels 2024\n\nThe intent here as an improvement over GovHack Denver was to guide teams towards smaller and easier funding opportunities beyond going direct to the DAO and main treasury via Snapshot and Tally which is an intensive process. The hypothesis to make this addition to GovHack was well-received, in fact participants requested more guidance on this path.\nProposal Development\nAfter the pre-event mapathons and expert pitstop sessions, participants were fully equipped and motivated to create impactful proposals. These proposals were developed in teams, with each team working diligently to address the specific challenges identified during the mapathons. The expert guidance provided by the pitstop sessions was instrumental in refining these proposals, ensuring they aligned with the Arbitrum ecosystem’s needs.\nJudging and Community Vote\nTo ensure a fair and comprehensive evaluation of the proposals, a panel of experienced judges was assembled. These judges were selected based on their deep understanding of the Arbitrum ecosystem and their ability to assess the potential impact of the proposed solutions.\n970×534 116 KB\nJudges:\n\nDisruption Joe - Head of Decentralization at ThriveProtocol, Arbitrum Delegate\n\nKrzysztof Urbański - Governance Lead at L2Beat, Arbitrum Delegate\n\nGeorge Beall - BD/Governance at Gauntlet, Arbitrum Delegate\n\nCoinflipCanada - GMX, Arbitrum Delegate\n\nJoJoCow - Strategy at JonesDAO, Arbitrum Delegate\n\nThese judges reviewed all 25 submissions, evaluating them based on innovation, feasibility, and alignment with the DAO’s strategic goals. By noon on Day 3, they had selected five finalists who were then invited to deliver live pitches during the event’s Open Community Day.\nWinners!\nGovHack Brussels 2024 culminated in the submission of 25 high-quality proposals. Each proposal adhered to the established guidelines, which included a written document of 400-1500 words, a 2-minute video pitch, and the “GovHack Brussels” tag for identification.\n973×536 82.9 KB\nThe following five finalists delivered a live pitch on Day 3’s Open Community Day, where winners were selected by the votes of those who attended the Community Day.\n\nFirst place: Team 16 - Proposal App : A one-stop-shop to all Arbitrum proposals, regardless of their different lifecycle stages. The app aims to aggregate information from Discourse, Snapshot, and the Arbitrum Onchain Governor contracts so as to understand the context of each proposal. The team asks for $93K for a three-month project development. Full proposal here.\n\n Finalist 3: Arbitrum Proposals App by Paulo Fonseca | GovHack Brussels\n\nSecond place: Team 26 - DevRel Uni Cohort: A six weeks training program to develop and deliver Developer Relations (DevRel) skills and knowledge, ensuring that more protocols within the Arbitrum ecosystem can benefit from DevRel support. The team is asking for $30K for a cohort. Full proposal here.\n\n Finalist 4: DevRel Uni Cohort by Bianca | GovHack Brussels\n\nThird place: Team 12 - Transparency and standardised metrics for Orbit chains on growthepie: A dedicated Arbitrum Orbit Stack page on growthepie.xyz listing 20 chains. Their goal is to aggregate important metrics on a chain level, including revenue for each chain, so that users, builders, and DAO members can make better data-driven decisions. The team is asking $ARB 305.2k for a 5-month development window. Full proposal here.\n\n Finalist 1: Grow the Pie by Toby | GovHack Brussels\n\nFourth place: Team 9 - Arbitrum DAO Dashboard: An aggregated dashboard reflecting the spending of Arbitrum DAO in 2024 available for all via a public website. The team’s aim is to ensure long-term sustainability and informed decision-making, insight into the current state of DAO. They ask $90K for 8 months of work. Full proposal here.\n\n Finalist 5: Powerhouse by Liz, Head of Growth at Azuki | GovHack Brussels\n\nFifth place: Team 4 - Jumpstart fund for DAO improvement: A Questbook fund to support early-stage initiatives focused on problem definition (root causes, gathering requirements), alignment, and scoping proposals for operational and governance improvements. The team is asking for $431K which $350K of them are for funding research initiatives. Full proposal here.\n\n Finalist 2: JumpStart Fund by Daniel Ospina | GovHack Brussels\n\nThe remaining 20 submissions were also of high quality, reflecting the dedication and creativity of the participants.\nTo view these proposals, visit the Arbitrum GovHack Submissions on the Forum.\nPost GovHack\nAfter GovHack, the following proposals have significantly advanced their proposals and have either submitted or are preparing to submit proposals to the DAO:\n\n1st place winner Proposals.app is being evolved on the Forum and plans to go to snapshot\n\n2nd place winner - a dedicated Abritrum DevRel Uni has gone to QuestBook.\n\n3rd GrowThePie Orbit went to snapshot and didn’t pass\n\n4th place Arbitrum DAO dashboard plans to continue and produce a proposal\n\n5th place winner Jumpstart Fund moved to snapshot vote but didn’t pass\n\nEIP-4824 powered daoURI for Arbitrum DAO is continuing and plans to post to snapshot in the coming weeks\n\nPanels\nPanel 1: Organizational structure & oversight\n\n Panel 1: Organizational Structure & Oversight | GovHack Brussels 2024\n\nPanel 2: Impact of grant programs\n\n Panel 2: The Impact of Grant Programs in the Arbitrum Ecosystem | GovHack Brussels\n\nPanel 3: End goal for ARB initiatives\n\n Panel 3: End Goal for Arbitrum Initiatives | GovHack Brussels 2024\n\nInterviews\nAll interviews playlist (18)\nTalks\nSam Martin from Entropy Advisors - Crafting a DAO Proposal\n\n Workshop: Crafting Effective DAO Proposals in Arbitrum | Sam (Entropy Advisors)\n\nPatrick from the Foundation - Arbitrum Technologies\n\n Demo 4: Arbitrum Technologies by Patrick McCorry | GovHack Brussels\n\nSinkas - ARDC\n\n Arbitrum Research and Development Collective (ARDC) by Sinkas | GovHack Brussels\n\nMaggie Love - SheFi talk\n\n Empowering Women in Web3 | Maggie Love, Founder of SheFi\n\nQuantitative Results\nThe Arbitrum GovHack Brussels 2024 delivered significant outcomes across various metrics, showcasing the event’s success.\nEvent Participation and Engagement\n\nMapathon Involvement: Over 50 delegates and contributors participated in the mapathon process, identifying and prioritizing key challenge areas for the DAO. This process led to the creation of 10 strategic tracks and challenge statements, guiding the focus of the hackathon.\n\nRegistration and Attendance:\n\n185 individuals registered for the event.\n\nMore than 110 participants actively engaged in the hackathon, forming 28 teams.\n\nThe event saw a total of over 200 participants across the three days.\n\nRepresentation from 16 different countries contributed to a diverse and inclusive environment.\n\nProposals and Expert Feedback\n\nProposals Submitted: A total of 25 proposals were submitted, each addressing different aspects of governance and innovation within the DAO.\n\nExpert Feedback: Nine Pitstop Experts provided 168 expert feedback sessions, significantly enhancing the quality and relevance of the proposals.\n\nScholarships: 20 scholarships were offered to participants (15 fully eligible and distributed), ensuring a wide range of contributors could attend.\n\nPanels and Discussions: Three panels were held, featuring in-depth discussions on key governance topics.\n\nEvent Outcomes\n\nFinalists and Prize Distribution: Five winning teams were selected, sharing a prize pool of $20,000.\n\nParticipant Satisfaction: The event received a 9.5-star rating and an impressive Net Promoter Score (NPS) of 83 from participants, highlighting the high level of satisfaction and engagement.\n\n1280×785 72.7 KB\nMedia and Storytelling Deliverables\n\nDaily Recaps: Three daily recap videos were produced to capture the essence of each day, engaging the wider community through social media.\n\nDay 1 Recap:\n\nWatch it here | 34K views | 51 reposts | 270 likes\n\nHackHumanityCo status | 43.8k views | 20 reposts | 57 likes\n\nDay 2 Recap:\n\nWatch it here | 21K views | 22 reposts | 62 likes\n\nDay 3 Recap:\n\nWatch it here | 1.9K views | 13 reposts | 49 likes\n\nCommunity Showcase Day: On the final day, four demo showcases of existing Arbitrum projects were presented alongside three panels and two technical talks, further enriching the participants’ experience.\n\nSocial Media Impact\nThe event’s social media presence significantly amplified its reach and visibility within the broader community:\n753×710 337 KB751×779 342 KB\n675×674 310 KB 672×661 351 KB\n\nMentions and Impressions:\n\nOver 70 real-time mentions of “Arbitrum GovHack” during the event, with additional mentions post-event.\n\nHackHumanity generated more than 116.8k impressions solely through event-related tweets, all prominently featuring Arbitrum’s branding.\n\nIn total, tweets about the event accumulated 343.3k views, 2.2k likes, 500 retweets, and over 180 comments.\n\n376×223 23.8 KB\n\nVox Pops and Interviews: More than 30 attendees were interviewed live (Vox Pops), creating content for use during and after the event, further extending the event’s impact.\n\nThe robust media strategy, combined with the active engagement of participants and the quality of the proposals submitted, underscores the success of the Arbitrum GovHack Brussels 2024 in achieving its goals of fostering innovation and collaboration within the Arbitrum DAO.\n670×886 411 KB751×778 426 KB\n674×807 320 KB672×495 269 KB\n1178×1384 237 KB1184×1220 343 KB1164×1002 96.1 KB790×746 507 KB\n1342×1292 255 KB\n\nQualitative Results\nImpact on Arbitrum DAO and Ecosystem\nThe Arbitrum GovHack Brussels 2024 had a profound impact on the DAO and its broader ecosystem, aligning with the DAO’s core values of social inclusiveness, collaboration, and innovation.\nSocial Inclusiveness\nThe event drew participants from various stages of engagement with the Arbitrum ecosystem, with demographics reflecting a wide range of experience levels and geographic diversity:\n\nExperience within the Ecosystem:\n\n1070×498 13.7 KB\n\nThe majority of attendees had between 6 to 24 months of experience within Arbitrum, highlighting GovHack’s role as a magnet for committed community members who are eager to shape the DAO’s future.\n\nA significant portion of participants were new to Arbitrum, using GovHack as a rapid and immersive entry point to understand the nuances of DAO governance, decision-making processes, and funding mechanisms.\n\nThis diversity of experience levels suggests that GovHack serves as a critical mechanism for both integrating new members and enhancing the contributions of established ones.\n\nGeographic Diversity:\n\n1600×970 499 KB\n\nParticipants hailed from 16 countries, primarily from Europe, but also from North and South America, and India. However, there is room for improvement in terms of representation from the African continent and the Global South.\n\nParticipant Roles:\n\n883×509 13.7 KB\n\nAttendees primarily identified as Builders, Contributors, and Service Providers, indicating that GovHack attracts individuals who are not only interested in contributing to the DAO but are also focused on building and enhancing its ecosystem.\n\nThe significant presence of Delegates underscores GovHack’s importance as a forum for deepening IRL feedback and fostering stronger connections among established DAO contributors.\n\nParticipant Experience\n1600×904 206 KB\n1600×898 182 KB1600×904 147 KB\nDetailed IRL schedule here.\nArbitrum’s goal of fostering an ecosystem that thrives on open innovation, interoperability, user choice, and healthy competition was clearly reflected in the participant experiences at GovHack Brussels:\n\nOverall Sentiment:\n\nThe general sentiment during Day 1 was overwhelmingly positive, with participants using words like “fun,” “inclusive,” and “connected” to describe their experience. By Day 2, the focus shifted to words like “intense,” “productive,” and “impactful,” reflecting the rigorous work and networking that characterized the event.\n\nDAY 1\n1069×552 41.7 KB\nDAY 2\n1041×499 38 KB\n\nSocial Connectivity:\n\nOn Day 1, most attendees reported knowing few people within the ecosystem. However, by the end of Day 2, participants had significantly expanded their networks, with many reporting they had met between 6 and 15 new people. This increase in social connections was facilitated by structured networking exercises and track explorations.\n\nQuotes from participants like Cliffton highlight the value of in-person interactions:\n\n“Having a lot of in real life feedback, a lot of in-person iterations and improvements, is a big value add… We found out that the main takeaways from the DAO was that everyone just got to know each other better, everyone could collaborate on a quicker pace.”\n625×585 29.6 KB\nSkill Development and Confidence Building\nGovHack also played a crucial role in enhancing the proposal-making skills and confidence of participants:\n1029×497 46.1 KB\n\nConfidence in Proposal Success:\n\nParticipants’ confidence in getting their proposals passed increased from an average of 6.4 on Day 1 to 7.0 on Day 2, marking a 9.4% improvement. This boost was attributed to the expert feedback and educational talks provided during the event.\n\nAs Raam noted, “I think the quality of the proposals that we saw at GovHack were probably equivalent to one month of progress for a typical proposal that’s worked on remotely.”\n\nDAY 1\n1059×508 18.9 KB\nDAY 2\n1021×406 13.8 KB\nQuotes from Participants\nThe positive feedback from participants underscores the value that GovHack added to the Arbitrum ecosystem:\n\nDisruption Joe: “The DAO is really spearheading the evolution of decentralized technology and governance. And we’re seeing this governance innovation live in action here at GovHack.”\n\nSrijith: “GovHack makes it super easy if you’re not a coder because there is a lot of value that you can add based on your experience… Bringing us together makes it a lot easier for us to move the DAO forward.”\n\n@ocandocrypto: “I’m feeling excited just for the fact that I’ve been learning a lot. So it’s quite exciting, this real experience of sharing with others and also learning from others.”\n\nThese qualitative results highlight GovHack Brussels 2024 as a pivotal event that not only fostered collaboration and innovation but also strengthened the social fabric and skill sets within the Arbitrum community.\nFinances\nThe original proposal was executed with $309k, including contingencies.\nThe final costs come in at $262k\nOriginal estimates:\n1416×1408 127 KB\n1424×294 31.4 KB\nHack Humanity received Milestone 1 & 2, we did not request Milestone 3 payment ($46,350) the final 15% as it was not needed.\nNote the plan was to distribute $10k (20 x $500) scholarships, we awarded 20 scholarships, yet 5 people didn’t show up or were in eligible, the final scholarship spend was $7,500.\n\nScholarship winners announcement 1\nScholarship winners announcement 2\n\nActual costs\n1600×1114 259 KB\nUnderspent $1096 returned from Hack Humanity wallet to GovHack mutlisig\n\nArbiscan transaction\n\nRemainder in GovHack Multisig:\n1600×427 64.8 KB\nThis can be used towards GovHack Devcon to secure a Bangkok venue early, or returned to the DAO main treasury.\nRecommendations for Future Events\nBased on the challenges faced and feedback received, several recommendations were made to enhance future GovHack events:\n\nIncrease Prize Amounts:\n\nTo encourage a greater variety of projects, it was suggested to increase the prize pool and consider separating prizes by track. This would ensure that all tracks are well-represented and encourage more focused project development.\n\nChange the number of Tracks\n\nWe had 10 tracks, while that meant we had a breadth of engagement, was that at the cost of depth of engagement. We could do the next GovHack to a much greater depth say on 3 tracks that are top priorities for the DAO for that quarter for instance.\n\nLarger Scholarships:\n\nThe $500 scholarships provided were not sufficient for participants travelling from outside Europe. One major delegate suggested increasing the scholarship amount to $2,500 per participant while curating the talent pool more selectively would better support the participation of high-value contributors. Ideal 20 x $2,500.\n\nWorkshops on Grants:\n\nMore workshops focused explicitly on available grants and the application process would help participants better navigate the funding landscape and increase the quality of their proposals.\n\nVenue Considerations:\n\nWhile the venue was generally well-received, future events should take into account the proximity to related conferences, like EthCC, to make it more convenient for participants.\n\nPost GovHack Support\n\nFacilitated program to support promising proposals to continue development and submission to the DAO. I.e. run online PitStops, schedule dedicated guidance and feedback sessions per track aspiring contributors can engage with. Ideal a dedicated 4 week online support/incubation program\n\nTarget demographics and IRL program design considerations\n\nGovHack was conceived and created by Hack Humanity for the following purposes:\n1. onboarding of new talent to solve issues for the DAO with proposals, success measures being increasing the quantity and quality of proposals.\n2. onboarding and development of existing and new delegates to exercise their role live realtime guiding and providing feedback to teams writing proposals\n3. a space for delegates and core contributors to network, build high trust relationships and make core complex DAO level decision making\nWe assess that GovHack is doing 1 and 2 well, point 3 in particular complex DAO level decision-making isn’t something intentionally designed for in the program and facilitation, people in the DAO are showing up and defacto using GovHack in this way in the absence of a dedicated opportunity to fulfil that need.\nWe have had 2 iterations of GovHack, I’d like to ideate with feedback here on what the 3rd iteration of GovHack needs to be most serving.\n\nThe possibility to either\n\nhave a dual track of strategic facilitation for delegates and core contributors to work through hard problems and make decisions\n\nuse Day 1 as a mini offsite for delegates and core contributors with the support of structured facilitation to work through complex topics and make critical decisions, to sharpen up the most aligned tracks and challenge statements, then move to the hackathon with this enhanced clarity\n\nBy reflecting on these challenges and the lessons learned, GovHack can continue to evolve and improve, ensuring that future events provide even greater value to participants and the Arbitrum ecosystem as a whole.\n\nConclusion\n1078×375 8.33 KB\nArbitrum GovHack Brussels 2024 showcased the powerful role in-person events play in sparking innovation and enhancing decentralized governance. With more than 200 participants from 16 countries, the event provided a fertile ground for turning ideas into actionable proposals.\nThe event’s well-organized structure, featuring pre-event mapathons, expert pitstops, and educational panels, gave participants the tools they needed to navigate the complex process of developing proposals. By focusing on key areas relevant to the DAO’s goals, the event ensured that contributions were both meaningful and impactful. The democratic approach to judging and community voting highlighted a strong commitment to fostering genuine innovation.\nParticipants were highly satisfied, as evidenced by a Net Promoter Score of 83 and robust social media engagement. However, the real highlight was the personal connections and sense of community that emerged—something often lacking in virtual environments.\nThe insights gained, especially around the timing of educational sessions and team formation, will be invaluable for future events. As Arbitrum continues to grow, the lessons and networks established at GovHack Brussels will be instrumental in shaping the DAO’s future. This event underscored the importance of in-person engagement in driving decentralized governance forward, setting a new benchmark for community-driven innovation.\nHackHumanity has thoroughly enjoyed producing GovHacks and wishes to continue this tradition providing GovHacks as a key competitive advantage for Arbitrum.\nHave added a Quick Poll for future direction, feedback much appreciated → Poll\n\nAdditional Resources\nTo explore more about the Arbitrum GovHack Brussels 2024, including videos, proposals, photos, and media coverage, please refer to the following links:\n\nAfter-Movie: Watch the 4-minute after-movie\n\nProposal Submissions: View all proposals on the Arbitrum Forum GovHack section\n\nAll media playlist\n\nMapathon Recordings and Miro Boards:\n\nMapathon Round 1 - recording - Jun 17 04 PM CET\n\nCombined results\n\nDaily Recaps:\n\nDay 1 Recap | 34K views | 51 reposts | 270 likes\n\nDay 2 Recap | 21K views | 22 reposts | 62 likes\n\nDay 3 Recap | 1.9K views | 13 reposts | 49 likes\n\nPhotos: Access all pictures from the Arbitrum GovHack Brussels 2024\n\n Establishing a DAO Events Budget for 2025\n\n GovHack Devcon in Bangkok - Hack Humanity\n\n Paulo Fonseca – Voluntary Earnings Disclosure Thread\n\n Paulo Fonseca – 10% Delegatoooor Kickback Program\n\n Delegate Incentive Program 1.7 - Application Thread and Code of Conduct Adherence\n\n 6\n\n 2\n\n read \n\n 16\n min\n\n post by julesfoa.eth on Aug 28, 2024\n\n julesfoa.eth\n\n Thanks Klaus and the team for your hard work. It was really smooth from the place, the food, the talk and the hack!\nI was awarded a scolarship and managed to push a proposal during the hack, here are my feedbacks.\nIt was really a game changer on two ways - meeting delegates and begining to build connections with many people that are really valuable. Not only like a conference, but understanding the needs of everyone and giving opportunities to see how to contribute in the future.\nI also have to admit that it was my first proposal after 3 years working in DAO ecosystem.\nThat is my point of view, but I think many silent people from the community are living a similar experience!\n\n post by KlausBrave on Aug 28, 2024\n\n KlausBrave\n\n Thanks for the feedback @julesfoa.eth in particular that GovHack was the difference that got you to at last make a proposal.\nThanks for coming it was a pleasure to have you there playing full out IRL.\n\n post by ZER8 on Aug 28, 2024\n\n ZER8\n\n Gov Hack was a very interesting experience for me, tbh idk if I would have gone to ETH CC if Gov Hack didn’t happen. \nI feel I learned so much during gov hack, the relationship building was invaluable(great to put faces on those PFPs), the participants had amazing energy to WIN and get their proposal “passed” by the DAO. Met some friends I already knew there and managed to get others interested in Arbitrum via Gov Hack. Loved the brunch as well \nAlso managed to chat with Ed Felten, za founder which was also kinda really cool, didn’t expect the Arbitrum core team to join \n\n post by KlausBrave on Aug 28, 2024\n\n KlausBrave\n\n Quick Poll to get an idea of future possibilities, what proposals would you like to see next from Hack Humanity?\nYou can tick multiple options:\n\n 18\n voters\n\n Choose up to 6 options.\n\n Votes are public.\n\n post by feems on Aug 28, 2024\n\n feems\n\n Thanks Klaus great awareness intitiative - do you have any data on rentention of those that participated or won the gov hack (denver) of those contributing to the DAO?\nAny data to fulfil the goal of the gov hack “drive governance innovation within the Arbitrum ecosystem” outside of submitting a proposal? Have any become delegates, joined WG (from new contributors)\nHaven any of the previous winners proposals in denver passed? If so what impact has it brought to the DAO\n\n post by KlausBrave on Aug 28, 2024\n\n KlausBrave\n\n Great questions @feems, retention and post GovHack activity is key.\nAt an individual level I’d need to do extensive research to gather some of these stats cross referencing Luma attendees, Forum accounts, Snapshot and Tally profiles to piece this together.\nFrom my current knowledge, initiatives from GovHack Denver that have matured and gone on to snapshot and Tally include:\n\nM&A\nAVI (Ventures)\nEvent Horizon\nAnecdotally, I heard a lot of the key conversations for STEP got worked out IRL at GovHack Denver. @thedevanshmehta would be better placed to elaborate on this.\n\nFrom ETHcc Brussels already:\nThe following proposals have significantly advanced their proposals and have either submitted or are preparing to submit proposals to the DAO:\n\n1st place winner Proposals.app is being evolved on the Forum and plans to go to snapshot\n2nd place winner - a dedicated Abritrum DevRel Uni has gone to QuestBook.\n3rd GrowThePie Orbit went to snapshot and didn’t pass\n4th place Arbitrum DAO dashboard from @prometheus_PH plans to continue and produce a proposal\n5th place winner Jumpstart Fund moved to snapshot vote but didn’t pass\n\nEIP-4824 powered daoURI for Arbitrum DAO from @amanwithwings is continuing and plans to post to snapshot in the coming weeks\n\nI am thinking one avenue to explore is I setup a Hack Humanity KarmaHQ profile and project for each GovHack and ask individuals and teams to attest to this value over time as a way to track the ROI, what do others think?\n\n post by feems on Aug 28, 2024\n\n feems\n\n You could just limit it to the winners of the gov hack. The reason being it shifts this from an awareness intititative to one to meet your original goal of drive governance innovation within the Arbitrum ecosystem. From low hanging participation (submits a proposal) to active and valuable contribution.\nAnylyzing this can allow more refined approach to meet those goals for the next gov hack if you choose to run it again. If this is considered and investment whats the ROI of it and how does it differ in impact from a devloper hackathon ( to see whether a gov hack is needed)\n\n post by Frisson on Aug 28, 2024\n\n Frisson\n\n Thanks for the very detailed Impact Report. I thought GovHack ETHcc was executed well and appreciate that it came in under budget. I’d support another event in Bangkok.\nOne piece of feedback I have is that I would like to see more integration between Arbitrum Day and GovHack. Going to both GovHack and Arbitrum Day required a long stay in Brussels. Also, I think there is an opportunity to integrate/paralell-path the governance hackathon with a technical hackathon around Stylus and/or Orbit.\n\n GovHack Devcon in Bangkok - Hack Humanity\n\n post by bianca on Aug 28, 2024\n\n bianca\n\n Great to see such a detailed report! I wanted to share my experience from GovHack Brussels as well. I decided to fly to Brussels earlier specifically for this event, and I definitely do not regret it. The moment I read about it, it resonated with me because decentralized governance is such an important topic for the web3 space, yet there are very few resources on how to approach it.\nIt was great getting to know key Arbitrum stakeholders in person. Also, having access to different learning experiences, key community members, and the HackHumanity team condensed what would have probably taken weeks of research and learning into just three days.\nThis was my first time writing a proposal and my first deeper interaction with the Arbitrum community. We ended up winning second place, and the proposal is now live on Questbook. The whole GovHack experience made me realize that Arbitrum is the ecosystem where I would like to build long-term.\nRegarding the ROI mentioned above, I think it’s challenging to measure it in the short term. Hackathons, in general, are a long-term investment—sometimes the ROI isn’t revealed until months or even years later. I’m saying this as someone who works in developer relations, where hackathons play a crucial role.\nI think we can agree though that this event positioned Arbitrum and the Arbitrum community as leaders in the governance space by offering a unique initiative that other ecosystems do not have. It also signals that one can have a significant positive impact if they are determined to do so—something that felt quite unique to me as a newcomer.\nSorry for the mini-essay . Personally, this event influenced me positively, and I’m sure it had a similar effect on many others. I’d love to see it happen again around other big Web3 conferences such as Devcon.\n\n post by JoJo on Aug 28, 2024\n\n JoJo\n\n Frisson\n\n I want to expand on what frisson posted here.\nFirst thing first, the event was well executed. I think a lot of builders were able to “get a taste” of our dao processes, for the good or the bad, in terms of writing proposals, getting feedbacks, finding people to work with, iterate, participate to a voting. It was similar to how we normally do it online, but IRL + concentrated + expedited. And to me this is an extremely valuable experience for the participants.\nAt the same time we have a second cohort of participants, that are established delegates and builders who, de facto, used the govhack event as a first BD meeting.\nThis happened naturally for one reason: govhack was, timeline wise, the first event of the week, before arbitrum day and before ethcc itself. This was a byproduct of how events were aligned for that particular weeks.\nImplicitely it means that, especially if the future govhack will happen again several days before main events (arbi day, main conference), it could make sense to have it structured in a way that favours these impromptu meetings that will inevitably happen.\nThis doesn’t mean changing the nature of govhack: i think that what was done was good and should be replicated. But for example allowing delegates to be able to have time and space to discuss what they felt they want to discuss in that moment without having to jump from meetings into advising participants and back to meetings and then back to judging or other activities tied to the specific event would be a good evolution.\nFurther more, I second frisson in both his takes, re: finding a coordination with arbitrum day could be something worth considering + expanding the govhack scope to also a technical hackaton specifically for stylus and orbit.\n\n post by paulofonseca on Aug 28, 2024\n\n paulofonseca\n\n IMG_6603800×450 213 KB\nthe world if everybody that got money from Arbitrum DAO would produce impact reports like this one.\nbut honestly… I flew to Brussels just for GovHack because when I saw the highlights video of the first GovHack in Denver I felt FOMO like never before, so I had go for it. I’ve participated in a bunch of hackathons throughout my career, (web3 and mostly non web3 ones) and I need to say that the level of professionalism in the organization of this GovHack Brussels was world class. all of the staff members were on top of their game and the proof is that nothing failed. during the whole 3 days, there was no hickup, no issue that I was aware of at least, and everything went smoothly. this is so incredibly rare for any event of this size. there’s no team I would trust more to organize proper hackathons like Hack Humanity\n\n post by tobsch on Aug 29, 2024\n\n tobsch\n\n Upfront: It was a super well organised event, so kudos and cheers to Klaus & team!\nAlso, the duration was good and sufficient, and everything from food, assistance in case of questions or unclarity, was all there.\nFor us, it was a chance to get closer to Arbitrum, as we’ve been trying before, and the DAO seems quite hard to get into and approach if you do not know many or any of the delegates. So it was good to meet people IRL and make yourself known.\nOne idea I had was to actually make this into a hybrid (IRL + online) event. Especially for people developing proposal with the intention to actually make a lasting impact and bring this to reality, it would be valuable to get feedback from more than just the few that have the ability to be on-site.\nAlso, generally I would love to actually get more proper feedback in written form or feedback in a formal meeting after judging of the proposals. In our case, we had some individuals we approached during drinks to get some feedback, but since our snapshot vote failed even after trying to incorporate feedback, discussions on the forum, I feel we did not get enough information even from the people that we could have talked to on-site. (As it is also sometimes not possible to match online handle/PFP with actual person if you hadn’t been in the inner circle before).\nSo all in all, I would aim for actually getting the big delegates more involved in these initiatives, as they will be the one actually deciding on developed proposals. This could be part of the agenda.\nAgain, great work from everyone there, thanks for organising it and looking forward to the next iteration. \n\n post by kinaArb on Aug 29, 2024\n\n kinaArb\n\n The report has sparked some interest. It’s promising to see potential in enhancing transparency and scalability within the DAO.\nLet’s hope these ideas gain traction and lead to tangible improvements. Looking forward to seeing further outcomes from this initiative.\n\n post by sid_areta on Aug 29, 2024\n\n sid_areta\n\n Overall, the GovHack experience was absolutely fantastic for us and it was great to meet everyone we have been working with so closely with in person! Huge kudos to @KlausBrave and the HackHumanity team for pulling off such an engaged and professionally run event, especially considering the time pressure they were under.\nIn terms of feedback, we think that future GovHacks can be two-pronged. The first prong that is crucial to be retained is to serve newcomers and help educate them on how to write proposals and contribute directly to the DAO. This could be further expanded by providing more education and context around the current state of the DAO and where specific help and input from contributors is needed - this would be extremely useful for existing high-context contributors as well, for whom it is relatively difficult to keep up with everything going on in a DAO as large and sprawling as Arbitrum. Teams working on existing initiatives can, for example, go in depth on their work, present it to the DAO, and speak through achievements and challenges to help everyone attain the context that sometimes can be lacking on calls or on the forum.\nThe second prong would be around having sessions for contributors to the DAO who are already high-context; more brainstorming sessions and dedicated opportunities to discuss important topics that the DAO needs to solve for would also be very beneficial. It turned out that for a lot of contributors who work on Arbitrum day in, day out, that GovHack was more of a great networking opportunity - there is an opportunity to capitalise on this and dedicate time towards topics that contributors feel are crucial to discuss in person and further advance.\nAll in all, this is a fantastic Impact Report and it has been a pleasure getting to know and work alongside Klaus and the HackHumanity team.\n\n post by KlausBrave on Aug 31, 2024\n\n KlausBrave\n\n All remaining and final funds (underspent + the ARB buffer) have been returned from GovHack multisig to the DAO Treasury.\n203.5k ARB, transaction:\n\nThank you to @krst and @AbdullahUmar as fellow multi-sig signers,\nand to @cliffton.eth for Foundation oversight and confirming the transaction.\n\n GovHack at ETH CC (Brussels)\n\n post by ostanescu.eth on Sep 5, 2024\n\n ostanescu.eth\n\n Thank you @KlausBrave and the entire Hack Humanity team for pulling up such a great event.\nI am super greatful to have had the chance to be part and build alongside Arbitrum community.\nAt ETH Bucharest we are now in process of discussing a proposal that would bootstrap the local Arbitrum community and this is all thanks to the GovHack Brussels.\nI am also very greatful to have met such great people, and to my surprise bump into people that I didn’t know they are gonna be there. Which made me feel even more that I am in the right place.\nLooking forward to the next edition and hopefully we can organize something in Bucharest one day!\nCongrats and keep going! #LFG\n\n post by Gonzacolo on Sep 8, 2024\n\n Gonzacolo\n\n I appreciate the report. Being clear with the data and process is crucial.\nAs I’ve mentioned in other channels, initiatives like this are extremely complex to execute, and this is one of the few places where participants from the Arbitrum DAO can meet in person. Personally, I had the chance to meet some incredible people, and the relationships and trust we build by connecting face-to-face will significantly contribute to growing this ecosystem that we all support, enabling us to create better products and initiatives.\nI also think that narrowing the scope of the tracks could be beneficial. Some technical tracks, which I personally found interesting, didn’t seem to be fully aligned with the DAO’s goals and, in the end, weren’t particularly helpful for the DAO itself.\nI support the cross-activities that help us get to know each other, like those on the first day, but spread throughout the event. This would allow us to connect even more, including with the new participants.\nI look forward to it happening again and hope to participate in the future!\n\n post by KlausBrave on Sep 8, 2024\n\n KlausBrave\n\n Thank you @Gonzacolo.\nThe number of tracks is definitely a parameter we can change up/down to create a more focused event.\nBringing more cross-activities to get to know each other spread throughout the event is a great suggestion, I agree we can include more of this in the next one.\nIt was great to meet you Gonzacolo, thanks for coming.\n\n post by Mehdi_eth on Sep 9, 2024\n\n Mehdi_eth\n\n Unfortunately, I could not participate, but based on the pictures and videos, it looks quite exciting to learn and meet the experienced delegates. For the next event, I hope you consider offering an online version as well.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n GovHack ETHDenver 2024 - Impact Report - Hack Humanity\n\n GovHack Denver\n\n 9\n\n 1.6k\n\n Jun 2024\n\n GovHack at ETH CC (Brussels)\n\n Finalized AIPs\n\n 51\n\n 3.9k\n\n Aug 2024\n\n GovHack Devcon in Bangkok - Hack Humanity\n\n Archived Proposals\n\n 74\n\n 1.9k\n\n Oct 2024\n\n GovHack - ETHDenver powered by Hack Humanity\n\n GovHack Denver\n\n 9\n\n 2.5k\n\n May 2024\n\n ArbitrumDAO Off-site - Directional proposal\n\n Finalized AIPs\n\n 89\n\n 2.3k\n\n Oct 2024","tokens":13003,"squid":"spider-07","role":"Council Spider","at":1791339615617,"hash":"98f4f0553612a923cbce1180e1f56001292fdafc"}
{"url":"https://forum.arbitrum.foundation/t/govhack-ethdenver-2024-impact-report-hack-humanity/23239/10","domain":"forum.arbitrum.foundation","title":"GovHack ETHDenver 2024 - Impact Report - Hack Humanity - Archive / GovHack Denver - Arbitrum","text":"The Arbitrum Foundation notified the Security Council on the need to perform a potential Emergency action. Following a review of the details and known risks, the Security Council decided to execute the upgrade and it was completed at 11:30 EST on 2nd October 2026.\nThis report provides an overview of the risks that required the Security Council Action:\n\nAdd a permissionless guard for the One-Step Proof of BoLD on Arbitrum One\n\nTemporarily pause activation of new Stylus contracts on Arbitrum One & Nova\n\nKey point: To date, known bugs for Stylus primarily impact chain liveness (e.g., denial of service attacks) and do not put any user funds at risk.\nWhy was this action taken\nLet’s take this opportunity to explain why action was taken on two separate issues concerning BoLD and Stylus.\nInstalling the guard for One-Step Proof of BoLD. Given the rise of AI-assisted attacks, we have implemented a precautionary approach that allows anyone to pause settlement of Arbitrum One on Ethereum if there are at least two conflicting answers that pass at the same level in which only one should be valid and pass. This is to halt a class of publicly verifiable and detectable attacks that exploit a bug in the one-step proof. If halted, Arbitrum One will continue to process as normal except that messages from Arbitrum One to Ethereum, such as withdrawals, that are not yet confirmed will have to wait. This provides time for the Security Council to deploy a fix for the bug and resume the rollup.\nPreventing activation of new Stylus contracts. AI-assisted tooling has led to an increasing number of sophisticated attacks on hand-crafted WASM programs that do not use the standard Stylus compiler toolchain. These programs are specifically designed to cause unexpected behaviors such as degrading the chain’s performance for all other users. To date, no attacks have been discovered that permits theft of user funds.\nNew ArbOS releases have patched several reported bugs and known attacks over the past few months, but out of an abundance of caution, we have decided to temporarily pause new activations of Stylus contracts. This was executed as an emergency action to prevent the deployment of new hand-crafted WASM programs that are not yet patched by the current version of ArbOS on the Arbitrum network.\nThe Arbitrum Foundation has informed the Security Council that they will work with the ArbitrumDAO to discuss next steps on the timeline and manner for enabling activation of new Stylus contracts. The Arbitrum community remains confident in the value of Stylus and want to preserve these use cases while taking preventative measures against Stylus-based attack vectors as AI-assisted attack tooling continues to evolve.\nImpact on builders and users\n\nNo new activations. New Stylus contracts cannot be activated during the pause including new versions of existing applications that require activation.\n\nExisting contracts are not paused. Already-active Stylus contracts continue to execute until expiration. This pause does not deactivate them.\n\nThe ArbOS 61 upgrade renewed all active contracts on Arbitrum One, so no currently active contract expires before August 20, 2027.\n\nRenewal via keepalive stays permissionless and is unaffected by the pause.\n\nReactivating an expired contract, or one that needs to be updated after a Stylus version change, is paused.\n\nUsing/calling any activated Stylus contract stays permissionless for all users and developers.\n\nNo impact on EVM. Solidity (EVM) contract deployment and execution are unaffected by this Security Council action.\n\nSecurity Council Actions\nThere are two actions bundled into a single payload:\n\nOne-Step Proof Guard. The L1UpgradeExecutor gives a new pause contract (PauseExecutor) the ability to pause and nothing else. The new pause contract grants the guard (OspSoundnessGuard) PAUSER_ROLE to use it. Anyone can show the guard two conflicting answers to the same step of an open challenge. If the one-step proof accepts both, the guard has the pause contract put Arbitrum One’s settlement to Ethereum on hold.\n\nStylus deactivation. The Security Council called ArbOwner.setWasmActivationGas(2^64 - 1) to raise the Stylus activation gas requirement on Arbitrum One and Nova. This makes activation prohibitively expensive and effectively disables new activations. This is a configuration change and does not require an ArbOS upgrade.\n\nThe Security Council signed the following transactions to update the configuration:\n\nEthereum: Ethereum Transaction Hash: 0x30732bb7d2... | Etherscan\nArbitrum One:\nArbitrum One Transaction Hash: 0x9eb3a4be3b... | Arbitrum One\nArbitrum Nova:\nArbitrum Nova transaction 0x79e0fed470dff7a22059b108e3f8f42eddd2b580a6771594060c4e7326c5f984 | Blockscout\n\nAn external audit was conducted for the OSP Guard contracts. No audit is required for the Stylus deactivation as it is only updating a single parameter in the ArbOS configuration.\n\n ArchiveGovHack Denver\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 6\n\n 3\n\n read \n\n 12\n min\n\n Apr 2024\n\n 10 / 10\n\n Jun 2024\n\n Jun 2024\n\n post by KlausBrave on Apr 16, 2024\n\n KlausBrave\n\n Arbitrum GovHack - ETHDenver 2024 - Impact Report\nCleanShot 2024-04-18 at 14.03.17@2x1920×1081 127 KB\nTL;DR\n\nThe ArbitrumDAO GovHack took place over 3 days, hosted together with Hack Humanity, a combination of Governance Bootcamp and Open Community showcase during the week before ETHDenver.\nThe fastest way to grok the GovHack vibe, accomplishments and potential for the future is to watch the 3-minute aftermovie here:\n\n GovHack Aftermovie - ETHDenver 2024 - Powered by Hack Humanity\n\nThis event was conceived by Hack Humanity, see the original pitch, forum post, it was then co-designed with ArbitrumDAO, the Foundation and ecosystem partners to leverage the collective intelligence of its members with the goal of enhancing the Arbitrum ecosystem.\nIt aimed to not only accelerate the DAO’s operations through the development of governance-related projects but also to foster deeper relationships and attract those curious about DAOs, thereby expanding the community.\nThe Results\n\nCodesigned Mapathon with 8 key tracks of focus identified\n10 final tracks established by the community in the event\n100+ Bootcamp participants\n200+ total participants\n23 teams established\n23 proposals submitted: 100% submission rate!\n5 winning finalists\n$15k prize pool awarded\n16 projects demo-ed at the Open Community Day\n9.1 star rating and 67% NPS from participants\n\nThank you to the delegates and community leads who participated intentionally and consistently over the three days. You played a significant role in making this event a valuable growth experience for the DAO. A special thanks goes out to:\nAlex (Savvy), Disruption Joe & Shawn (Plurality Labs), DK (Premia), CoinflipCanada (GMX), Soby (Xai Games), Krzysztof (L2Beat), Cattin (SeedLatam), Griff (Giveth, General Magic), Limes.eth, 404 DAO, Matt (Blockworks), Dan (Vela), Frission (Tally), Daniel (RnDAO)\nObjectives & Goals of the Arbitrum GovHack\n\nCleanShot 2024-04-18 at 14.16.07@2x1920×1117 131 KB\nThe Arbitrum GovHack, a 3-day experience held during ETHDenver, was designed to foster growth, trust, and innovation across the Arbitrum ecosystem. This initiative addressed the inherent challenges of building within distributed organizations, where governance ideation and collaboration thrive on deep relationships. However, such relationships are often hard to develop in rapidly growing digital spaces characterized by anonymity, sporadic rhythms of engagement and limited face-to-face interactions.\nGovHack set out to achieve the following objectives:\n\nAccelerate how we work together as a DAO and an ecosystem\n\nDeepen human relationships & support systems among DAO contributors\n\nIdentify and take action on cross-collaboration opportunities\n\nAttract DAO curious bystanders to learn more and get their hands dirty\n\nShip in-depth proposals for long-term engagement\n\nApproach\nTo ensure these objectives were met, Hack Humanity employed various strategies, including building:\n\nArbitrum Ecosystem Map\nEstablishing the Hackathon Working Group\nBuilding an Arbitrum Ecosystem Twitter List of key contributors\nEngaged in 10+ Open Community Calls, conducted 10+ 1-1 calls with key DAO contributors to understand the gaps and needs of the DAO\nParticipant persona development, participant experience design, and track and challenge statement development via community-co-designed Mapathon workshops.\n\nMapathon Miroboard\nZoom recordings for mapathon:\n\nRound 1\nRound 2\n\nThese efforts aimed to ensure that the event:\n\nwas value aligned with the DAO constitution\nrelevant and strategically aligned with DAO needs and goals\nattracted the right talent\ncurated good problems to work on, these were represented as Tracks and Challenge Statements\nappropriate and effective incentivisation mechanisms to attract the right talent, matched to the right problem, resourced with what they need to innovate\n\n1600×895 163 KB\nTracks and ideal Talent Profiles identified\nCleanShot 2024-04-16 at 23.44.55@2x1920×1074 125 KB\nThis ambitious set of objectives sought not only to accelerate the pace of innovation and collaboration within the Arbitrum ecosystem but also to establish a model for how distributed organizations can foster deep trust and cooperation, crucial for achieving governance ideation and collaborative success.\nDeliverables, KPIs and Milestones:\n\nConsult on organizational focused calls with the Foundation team prior to GovHack\n\nLead mapathon process, public governance calls with delegates and community members to identify potential working groups, hackathon Tracks, Challenge Statements, Contributor Talent profiles\n\nOutreach, recruitment, and assess and consulted for advice on participants, built the team of co-facilitators, mentors, judges\n\nDesign incentive mechanics, prizes, submission criteria, judging criteria\n\nDesign and facilitated in-person working groups on Day 1 and Day 2 of GovHack\n\nInterviews with delegates and community members during GovHack\n\nLead impact report & governance call for the ArbitrumDAO community after the ArbGov Hack event to discuss what was successful, what could be done better, and potential next steps\n\nDesign custom GovHack t-shirts & stickers for participants and crew\n\nCleanShot 2024-04-16 at 17.42.47@2x1920×1002 82.1 KB\n\nMedia & storytelling: 3 daily recap videos produced, daily tweet threads posted on Arbitrum’s social account, live interviews conducted with key stakeholders and participants, aftermovie, panels, and demo day recordings.\n\nCommunity Showcase Day on Day 3:\n5 Final Pitches\n3 Panels\n16 demo day showcases of existing Arbitrum projects\n\nAchievements and Outcomes\n\n1600×900 314 KB\nExpert Educational Talks\nAt the Governance Bootcamp Day 1 & 2, two educational talks were hosted by Disruption Joe and Devansh Mehta to give participants more insight into how their proposals fit into the DAO and offer guidance around forum writing and submissions.\n\nPrinciples for Implementing a Pluralist Grants Framework] by Disruption Joe\n\n Arb GovHack Workshop Joe\n\n“Writing for the Forum” by Devansh Mehta\n\n Arb GovHack Workshop Devansh\n\nExpert Pitstop\nOn Day 2, we curated an “Expert Pitstop” team of knowledgeable stakeholders to offer live feedback and consultation as teams prepared their proposals for submission. The Pitstop ran for several hours, allowing each team to spend dedicated time with delegates and get the right context and inputs to create more viable proposals.\nThe Pitstop proved itself invaluable, and was commented on as one of the most valuable offerings of the whole event, talented teams could rapidly get their ideas levelled up with rare access to key decision makers and knowledge holders in the DAO.\nPitstop included: CoinFlipCanada, DK, Disruption Joe, Tnorm\nCleanShot 2024-04-16 at 19.03.12@2x1920×1055 146 KB\nFX30_20240228_1064.MP4.15_49_28_08.Still0021920×1080 159 KB\n1280×916 259 KB\nFeedback on the format and value of the Expert Pitstop:\n\n“There are a lot of people who have already been working on proposals, and having a lot of the delegates in the same room allows you to move very quickly - you get some feedback, action it, go back for more feedback, iterate and refine it and that is quite valuable.\nThe education cycle and getting buy-in and understanding politically what is going to be viable for the DAO takes months, and who is paying for those months? So being able to short-cut it and fast track it is incredibly valuable to increase the throughput of proposals that can actually see the light of day.”\n-Daniel Ospina, RnDAO\n\nSummary of Proposal Submissions:\n23 proposals were submitted on Day 2 of the Governance Bootcamp, following the established submission guidelines: a written proposal + 3 min video pitch.\nProposals can be found here: Arbitrum GovHack Submissions\n5 judges selected 5 finalists by the end of Day 2.\nThe Judges:\nCleanShot 2024-04-16 at 17.54.50@2x1920×1077 88.4 KB\nThese finalists went on to each deliver a live pitch on Day 3’s Open Community Day. Winners were selected by community vote by those in attendence.\nResults of Community Vote and Finalists breakdown:\n685×381 21.2 KB\n\nFirst Place: Team 13 - DAO BD Strategy: proposes initiating a DAO Business Development program using Questbook to attract projects from other chains and the Web2 space to Arbitrum, with an initial focus on the gaming sector and a $150,000 grant pool. Full proposal here.\n\nSecond Place: Team 11 - Introduce Contributor Onboarding to Arbitrum DAO: proposes a streamlined onboarding process for Arbitrum DAO contributors, featuring automated emails, videos, and a detailed handbook, aiming for efficient integration. The plan seeks 50,000 ARB tokens for a three-month project implementation. Full proposal here.\n\nThird Place: Team 20 - Contributor Mining / Get the Contributors Paid: proposes creating a Human Capital DAO within Arbitrum to introduce contributor mining, aiming to attract and retain talent with scalable incentives and fostering a culture that significantly values contributions. Full proposal here.\n\nFourth Place: Team 8 - Better BD / Branding for Gaming in ARB: aims to boost Arbitrum’s gaming sector through targeted business development and enhanced branding efforts, targeting a 25% growth in gaming projects and faster market launches. The strategy involves consulting services, a comprehensive study of vendors, and establishing a dedicated website for preferred vendors, with a budget of $105K-$115K. Full proposal here.\n\nFifth Place: Team 5 - Backup Sequencers: Team 5 suggests enhancing Arbitrum’s network resilience by introducing backup sequencers to reduce downtime and censorship risks, proposing Coinbase and Node Guardians as electable backups. This strategy aims to safeguard user experience and DAO revenue, requiring minimal code changes for implementation. More information on the proposal is available here.\n\nFinal Pitches Video Playlist\n\nTo view the remaining 18 submissions, visit Arbitrum GovHack Submissions on the Forum.\nImpact on Arbitrum DAO and Ecosystem\nAccelerate how we work together as a DAO and an ecosystem\nParticipants signaled an increase in confidence around the proposal submission process and DAO priorities. Anecdotally we heard multiple times from top delegates that they’d accomplished more in 2 days than in months.\n\n\"It’s been an interesting few days at GovHack. The DAO has created a backlog of initiatives and ideas that we’d like to explore, over the last 6 months. In 2 days of same-room collaboration, with a bunch of talented and creative minds, we were able to take action and drive change forward. The amount of work that’s been done in this 2-day sprint is way more than I had ever anticipated.\n-DK, Delegate and Founder\n\nDeepen human relationships & support systems\nMany people were excited to meet people in person that they’d been working with online for months. Our surveys also indicate that many new connections were formed, which is important as the majority of participants also signaled that they were new to the DAO.\n764×303 10.8 KB\n\n“There are a lot of great people in Arbitrum that you only meet on the other end of a computer screen.\nIn most of web3, we don’t have those personal connections. We don’t have the ability to go out and meet with somebody, we talk to them through platforms and a lot of times those forms of communication are not good for async relationships. So this is bonding. this is the chance to go meet somebody you had a disagreement with and build a human connection, so that the next time when you disagree with somebody or see something differently, you know it’s a human on the other end - and it just makes life so much easier when I can see that I know that person, I have a personal connection with them and they just see things differently than I do.\nSo this is web3 bonding - this is what this is.”\n-Shawn L. Grubb\n\n1600×900 281 KB\nIdentify and act on cross-collaboration opportunities\nThe dedicated IRL environment and structured program offered opportunities for projects and partners to connect in new ways and evaluate key challenges together.\nExample: proposal from an emerging collaboration between Event Horizon, 404DAO, Matt Fiebach, Jengajojo (DAOplomats) due to ideation on the ground at GovHack\n\n“I love the setting in how a hackathon forces people who might not have collaborated before to indeed collaborate. The diversity of experience and thought creates some truly innovative approaches to problem-solving that is difficult to achieve solely on the internet.\"\n-DK, Delegate and Founder\n\nAttract DAO curious bystanders to learn more and get their hands dirty\nThe event served a welcoming environment for non-technical participants who were new to the Arbitrum DAO and broader ecosystem. The poll we ran on Day 1 indicates that over half of participants have been connected to the ecosystem for less than 6 months.\n808×347 13.5 KB\n\n“The same way we focus on iterating and building our technology, we do need to do the same thing on the human capital side of what we’re building and I think this [GovHack] was wonderful. The fact is there were many people who were only newly exposed to Arbitrum, who went and dedicated some time. They now have a sense of how their involvement is going to help move Arbitrum forward.”\n-CoinFlipCanada\n\nI think the [event] activities are really helping some of the newbies, those who come with less context of the DAO, to understand what could be valuable. Which is often one of the problems - you join a forum and there are a bunch of posts, and you don’t really know where to go. The key to really understanding, to really be able to participate, is the social relationships. We think that DAOs are trustless, but behind that there is this whole social network and unless you are part of that community, you cannot operate it.\n-Daniel Opsina, Founder of RnDAO\n\nShip in-depth proposals for long-term engagement\n23 proposals were launched during the event, which can be found here on the forum. These proposals are now underway for review and iteration over the coming months.\n\n“I think what resonated the most with me [from this event] is the energy and the feeling of being able to do something…that actually we have some power, some ability to move things forward. This has been quite evident in the crowd, that everyone feels that the reason why they spend 2 days working on those proposals is because they really believe they can make it happen. And now we need to make sure that they actually can. So that was awesome - I want more of it.”\n-Krzysztof Urbański\n\n“It’s been quite exciting because it provides an opportunity for people to meet different DAO contributors and delegates and get feedback on proposals that they’ve been thinking about for months, like myself.\nI think that I received a lot of great feedback that will provide me with an opportunity to refine the proposal that I’ve already submitted so that it can be more successful.”\n-Feems\n\nEvent Overview\n\nHighlights & Key Data\n10 Established Tracks\n\nBetting on Builders\nContributor Onboarding, Activation & Engagement\nGame Development & Incentives\nARB Token Liquidity\nSequencer\nDAO BD Strategy\nOrbit Adoption Strategy\nGrants Ecosystem\nDAO Operational Excellence\nStrategic Big Bets\n\n23 teams formed\n23 proposals submitted (100% submission rate on the forum)\n5 judges\n\nEmiliano Bonassi: Researcher at Conduit.xyz\nKrzysztof Urbański: Governance Lead, L2Beat\nDK: Co-Founder, Premia\nRob Benhke: CEO & CoFounder, Halborn\nCattin: Freelance Designer\n\n5 finalists winning a combined total of $15k in prizes\nOpen Community Day\nInterviews\nKrzysztof Urbański (@kaereste) from L2Beat\n\n Krzysztof Urbański from L2Beat interview - Arbitrum GovHack - ETHDenver 2024\n\nDistruptionJoe from ThriveProtocol interview\n\n DistruptionJoe from ThriveProtocol interview - Arbitrum GovHack - ETHDenver 2024\n\nSoby from XAI interview\n\n Soby from XAI interview - Arbitrum GovHack - ETHDenver 2024\n\nPanels\n\nPanel 1 - Abitrum Grants Ecosystem\n\n Panel 1 - Grants - Arbitrum GovHack - ETHDenver 2024\n\nPanel 2 - Contributor’s Dilemma\n\n Panel 2 - Contributor Dilemma - Arbitrum GovHack - ETHDenver 2024\n\nPanel 3 - DAO Orbit Strategy\n\n Panel 3 - Orbit Adoption Strategy - Arbitrum GovHack - ETHDenver 2024\n\nDemo Day\n17 projects demo-ed on the Open Community Day\nHack Humanity worked with Amin Iman, who took the initiative to organize and led the sourcing and coordination of all startups that were featured in our project showcase for Open Community Day.\n\nBrahma - https://twitter.com/BrahmaFi\nSavvy - https://twitter.com/SavvyDeFi\nChateau - https://twitter.com/Chateau_capital\nRnDAO - https://twitter.com/RnDAO__\nOurmada - https://twitter.com/Ourmada_xyz\nFootium - https://twitter.com/Footium\nEpoch Protocol - https://twitter.com/0xEpochProtocol\nClr.fund - https://twitter.com/clrfund\nPerennial - https://twitter.com/perenniallabs\nMarginly - https://twitter.com/marginlycom\nGemach Lend - https://twitter.com/GemachLend\nWise Lending - https://twitter.com/Wise_Lending\nOpen Dollar - https://twitter.com/open_dollar\nContrax - https://twitter.com/Contrax_Finance\nCede.store - https://twitter.com/CedeLabs\nPrimex Finance - https://twitter.com/primex_official\nCookbook.dev - https://twitter.com/cookbook_dev\n\nDemo Day Playlist:\n\nParticipant Experience\nParticipant demographics and registration data\nEach day of the event, attendees were checked-in via the Luma event app.\n\n107 attendees checked-in over the 2-day hackathon\n\n192 total check-ins over the entire event*\n\n*actual numbers are somewhat higher as a few attendees were not checked in, and this does not include the Arbitrum Foundation attendance or the Hack Humanity crew\nBreakdown of attendee demographics from live polls:\n808×347 13.5 KB\n807×365 13.4 KB\n806×552 20.5 KB\n\n“It was a delight to see a microcosm of the DAO in real life, with the same energy, creativity, initiative-taking and enthusiasm as on the DAO’s various digital platforms. It also highlighted that anyone can be who they want in the DAO. More importantly, that despite working with trustless technology, human trust cannot be replaced. This human trust is something that GovHack helped develop”.\n-Raam, Arbitrum Foundation\n\n\"It’s been an interesting few days at GovHack. The DAO has created a backlog of initiatives and ideas that we’d like to explore, over the last 6 months. In 2 days of same-room collaboration, with a bunch of talented and creative minds, we were able to take action and drive change forward. The amount of work that’s been done in this 2 day sprint is way more than I had ever anticipated.\nI love the setting in how a hackathon forces people who might not have collaborated before to indeed collaborate. The diversity of experience and thought creates some truly innovative approaches to problem-solving that is difficult to achieve solely on the internet.\"\n-DK, Delegate and Founder\n\n“A community organized bootcamp with 4 weeks notice led to 23 submissions of potential proposals to the ArbitrumDAO. It was one of the rare events where most attendees were engaged and not hanging out in the hallway networking. I have a feeling that this in-person experience is a turning point for the ArbitrumDAO. Excited to see what happens next.\nProbably the greatest thing to come from this event is evidence that contributors are indeed empowered and when people are actually empowered to do something then they will step up and kick ass. ArbitrumDAO governance is truly alive and it’s going from strength to strength every month.”\n-Patrick McCorry via Twitter, Arbitrum Foundation\n\n“The whole goal of this event was to get more proposals in the DAO and to have people write better proposals. And while we I think succeeded, to be honest it went above my expectations, we need to make sure we use this potential going forward.\nI think what resonated the most with me is the energy and the feeling of being able to do something…that actually we have some power, some ability to move things forward. This has been quite evident in the crowd, that everyone feels that the reason why they spend 2 days working on those proposals is because they really believe they can make it happen. And now we need to make sure that they actually can. So that was awesome - I want more of it.”\n-Krzysztof Urbański\n\n“One thing most people miss out about DAOs, because we focus on the technology, is DAOs are people. It’s bringing people together, it’s bringing diversity of ideas, diversity of thought, collectively moving these efforts forward. So I actually think GovHack is honestly an awesome idea.\nThe same way we focus on iterating and building our technology, we do need to do the same thing on the human capital side of what we’re building and I think this was wonderful. The fact is there were many people who were only newly exposed to Arbitrum, who went and dedicated some time. They now have a sense of how their involvement is going to help move Arbitrum forward.”\n\nCoinFlipCanada\n\n“EthDenver was a blast, and the Arbitrum GovHack stole my heart. Exploring the vibrant ecosystem and governance was so enjoyable, and snagging second place was the cherry on top. Huge thanks to the Arbitrum Foundation and Hack Humanity for putting it all together. Excited to ship our proposal in the upcoming weeks, catch you in the forum!”\n\nHeather, Finalist from Team 11\n\n“I think that there were many opportunities for us to talk to the different judges and delegates to get feedback, and I think the team was really helpful in kind of navigating how we should act and what our schedules are, so I had a pretty positive experience.”\nI met a lot of online individuals who have legs and are humans so that was really cool, and I think the more that we have in person events the more the community can connect on a more human level.”\n\nFeems\n\n794×1135 221 KB785×325 52.2 KB1187×1565 312 KB\nParticipant polls & results:\n776×393 45.5 KB\nOver the course of the 3-day event, we ran numerous surveys to collect live feedback from GovHack participants around the connections they were forming on the ground, the learnings they were acquiring around the Arbitrum governance process, and their overall experience of the event.\nResults were very positive, showing an increase in confidence amongst attendees around creating viable proposals. The majority of participants indicated that they connected with 6-25+ new people in the ecosystem, which correlates well to the fact that many participants in the room were new to the DAO.\nAn NPS score of 67% was established at the end of Day 2 of the Governance Bootcamp:\n1002×639 46.8 KB\nSurvey Day 1:\n761×411 11.5 KB\nSurvey Day 2:\nLearnings:\n1440×810 119 KB\nNew Connections:\n1600×1121 67.1 KB772×423 14 KB\n758×430 17.2 KB\nQualitative Feedback from Polls:\nPositive Feedback\n\nEvent Structure: Participants appreciated the event’s structure, timing, facilitation, and the quality of interactions.\nNetworking Opportunities: The focus on discussions and the chance to meet knowledgeable members, builders, and delegates at the Arbitrum DAO were highlighted as positive aspects.\n\nAreas for Improvement\n\nTeam Formation: Feedback suggested the need for better matching of participants based on interests and discouraged allowing pre-planned projects to prevent the formation of exclusive groups.\nClarity in Instructions: There was confusion about whether participants should stay at one table or move around, affecting networking opportunities. A lack of clarity in assignments with teams struggling to understand their goals and the metrics for success was noted.\nInformation and Preparation: Suggestions were made to provide summaries of the DAO’s governance model to better understand the organizational structures. Participants also expressed a desire for more information about bounties and track details.\n\nRecommendations for Future Events\n\nImproving the Environment: A recommendation was made for a quieter event space, possibly with carpeting, to help manage noise levels during main gatherings.\nEnhancing Team Collaboration: To improve team collaboration and maintain energy levels, clearly written challenge statements by teams and the introduction of mid-day energy-boosting exercises were suggested.\nAddressing Small Group Challenges: Small groups faced challenges due to overextended community leads, indicating a need for better support structures for smaller teams and better guidance to the community leads.\n\nThe Hack Humanity media team recorded all presentations, pitches and panels throughout the event and filmed numerous interviews with key participants, delegates and participants.\n\n11 dedicated interviews\n17 demos from the open Community Day\n3 Panels from the Open Community Day\n2 Talks with Disruption Joe & Devansh\n5 Finalist Pitches\n\nVia a co-marketing strategy between the ArbitrumDAO and Hack Humanity, the Hack Humanity media team produced daily recap videos and tweet thread copy to support storytelling throughout the event. These were posted via the Arbitrum X account in collaboration with the Foundation team.\nDay 1 Recap:\n\n Day 1 Recap - Arbitrum GovHack - ETHDenver 2024\n\n33k views | 43 reposts | 207 likes\nDay 2 Recap:\n\n Day 2 Recap - Arbitrum GovHack - ETHDenver 2024\n\n28.4k views | 50 reposts | 217 likes\nDay 3 Recap:\n\n Day 3 Recap - Arbitrum GovHack - ETHDenver 2024\n\nAdditional social posts:\n\nKey Takeaways & Learnings\n\nKey Learnings:\n\nIRL time accelerates collaborative work within the DAO because attention is focused and the right stakeholders are accessible for immediate feedback\nThis kind of non-technical event is attractive to both newcomers and existing contributors, as seen by the breakdown of attendee participation\nContributors find dedicated IRL access to delegates extremely valuable in the ideation phase. The Pitstop panel on Day 2 received very positive feedback\nThere was a lack of participation from more Delegates and key protocols in the Mapathon, which constrained the depth and breadth of the tracks and challenge statements that were identified as important for the DAO\nThere were gaps in IRL participation from key ecosystem stakeholders during the 3 days because GovHack’s scheduling was alongside other key events in Denver, so people were pulled in different directions and unable to give full dedicated time to the participants. This lessened the overall quality of the event as often Community Leads were stretched thin to guide the conversation around their track and support newcomers\nThe tight preparation timeline of 4 weeks with budget constraints led to challenges in the event organization. There was limited time to engage more key stakeholders in the Mapathon design process, and the Hack Humanity team was spread very thin on organizational tasks such as raising the necessary additional sponsorship to support the increased attendee participation this took up capacity until the very last days before the event, the original budget for the Bootcamp/Community day was for 70/150 people, actual numbers: 109/200+.\nHack Humanity absorbed the cost of additional team staffing to accommodate the increased attendance without additional financial support; Hack Humanity also funded out-of-pocket additional media production over the level provided by the Foundation to generate quality media and storytelling to demonstrate the value of full high-end production media to bring the DAO and voices of the DAO to life. In addition, graphics design, t-shirt design, and decor design without a budget in order to demonstrate to Arbitrum what a high-quality production looks like. This needs to be funded properly for subsequent events.\nThe high number of tracks, while promoting inclusion, also split attention more widely and made it difficult to go deeper on key topics\nPeople are excited to hack and will even organize themselves and their teams in advance of the event. The total team numbers nearly doubled on Day 2 (from 13 to 23) due to new teams showing up ready to submit proposals. While perhaps a good problem to have, this also presented challenges in catering, equipment, the hackathon structure as submission criteria and judging process needed to be adjusted dynamically to allow for more time to process the larger numbers.\nThe quality of templates and guidance for proposal writing can be improved for participants, especially with the high number of newcomers to the DAO. Teams asked many questions looking for guidance on what constitutes a good proposal.\nCommunity voting was well-received but limited to a small pool of voters due to the IRL attendance at that particular time of day on Day 3.\nWith more lead time, we could attract more sponsors to make the event more viable and sustainable, with a larger prize pool to incentivize contributions.\n\nRecommendation for Future Events\n\nWith more lead time and budget, a stronger program design and event plan could be established with smoother execution on the ground.\nThere needs to be extreme clarity on submission criteria in advance, with contingency plans in place for sudden growth, to ensure a smooth participant experience in following events.\nA proposal framework should be prepared for the next event to provide newcomers with better guidance to start out with.\nA commitment from key delegates and stakeholders to be present for the Mapathon design process to ensure the most important challenges of the DAO are adequately prioritized and represented. Commitment to in-person presence for the full duration of the event would increase the quality significantly, both for the participant’s experience and for the quality of the project outputs. This is one of the core components of the event’s unique value offering.\nConsider extending the length of the event to provide participants with more time to work on their proposals. Day 1 was consumed with organization around tracks and team formations, and Day 2 proved to be extremely valuable for feedback, iteration and generation of projects. A third and/or 4th day would allow for more comprehensive content and refinement of ideas.\nIf positioning these types of events alongside a major conference, consider choosing a venue within walking distance / very close proximity to allow for higher foot traffic.\nA cap on the number of demo projects may be advisable, and positioning the pitches earlier in the day when the energy levels of the room are higher. May be interesting to consider incentives for feedback and participation from the audience.\nFinalist presentations and community voting could be designed for future events to be more inclusive across the wider DAO using experiments via online participation.\n\nConclusion\nKey achievements of the GovHack include the establishment of meaningful connections among participants, many of whom were new to the DAO space, the identification and fostering of cross-collaboration opportunities, and the empowerment of participants through educational talks and expert feedback sessions. The event’s design increased the quality and quantity of governance proposals, showcasing the practical benefits of in-person collaboration in a digital-first community.\nLooking forward, the insights gained from this event should guide future initiatives, with a focus on refining event structure, enhancing collaborative opportunities, and ensuring more inclusive participation across the DAO. The success of GovHack serves as a testament to the vibrant potential of the Arbitrum community and sets the stage for further innovation and engagement in the ecosystem. Overall, GovHack was not just a meeting of minds but a pivotal moment that is likely to influence the trajectory of the Arbitrum DAO positively, paving the way for a more connected and dynamic future.\nC0177.MP4.05_51_46_12.Still0011920×1080 184 KB\n1600×1200 356 KB\nThank you from team Hack Humanity. Let’s do this again!\n1280×960 273 KB\n\nReferences:\nAll Videos Playlist:\n\nPhotos\n\n GovHack at ETH CC (Brussels)\n\n GovHack Devcon in Bangkok - Hack Humanity\n\n Delegate Incentive Program 1.7 - Application Thread and Code of Conduct Adherence\n\n GovHack ETHcc Brussels 2024 - Impact Report - Hack Humanity\n\n Arbitrum DAO News: Security Council Member Election, STIP Bridge and Arbitrum Fellowships, April 18th\n\n 6\n\n 3\n\n read \n\n 12\n min\n\n post by KlausBrave on Apr 16, 2024\n\n KlausBrave\n\n If you attended, I’d love to hear your direct feedback on the event as a reply here, and suggestions for how we improve the next GovHack?\nEveryone else, any questions or comments, I’d love to read them.\n\n 8 days later\n\n post by KlausBrave on Apr 25, 2024\n\n KlausBrave\n\n Cross posting to the next proposal for GovHack ETHcc Brussels:\n\n 11 days later\n\n post by pfedprog on May 6, 2024\n\n pfedprog\n\n KlausBrave\n\n My understanding that the event targets arbitrum specific issues.\nIs there a way to organize teams prior to the event and read through the grants, areas that the projects should target during the event?\n\n post by KlausBrave on May 6, 2024\n\n KlausBrave\n\n Hi Pavel, I’ll be conducting a mapathon community co-design process to determine the most relevant and hot topics and challenge statements we can focus on at GovHack, this will happen early June as a series of online workshops. I’ll announce those on the Forum when ready and get them on the community google calendar.\nThis will be an opportunity for you to find potential teammates and suggest and determine a topic you’d like to focus on.\n\n post by pfedprog on May 6, 2024\n\n pfedprog\n\n Absolutely, can not wait for the event.\nI am currently building EVM Smart Contract Explorer to discover and track EVM smart contracts data.\nhttps://evmexplorer.com/\nI would really appreciate potential direction and feedback on the utility of blockhain as an api.\n\n 13 days later\n\n post by pfedprog on May 19, 2024\n\n pfedprog\n\n KlausBrave\n\n Amazing, I just casually went over the prices for the venues in Brussels, I am somewhat concerned with the estimated expenses for Brussels event. Did you by any chance submit expenses for Eth Denver Event?\n\n post by KlausBrave on May 20, 2024\n\n KlausBrave\n\n Cross posting reply on venue and budget\n\n 16 days later\n\n post by KlausBrave on Jun 6, 2024\n\n KlausBrave\n\n Gm gm,\nVenue signed and sealed.\nGovHack Brussels event page is live, you can sign up here Arbitrum GovHack Brussels · Luma\nWe have a great space and dedicated time to really take the opportunity to get to know each other, work deeply and build meaningful proposals together IRL.\nLet’s go,\nKlaus\n\n 24 days later\n\n post by AllCityBAYC on Jun 30, 2024\n\n AllCityBAYC\n\n Fantastic report.\nReally, nothing beats IRL and workshopping governance with a group of problem solvers not only sounds incredibly productive – it sounds equally as fun.\nGreat job all around on this. Highly impressed.\nAC\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n GovHack ETHcc Brussels 2024 - Impact Report - Hack Humanity\n\n GovHack Brussels\n\n 19\n\n 782\n\n Sep 2024\n\n GovHack at ETH CC (Brussels)\n\n Finalized AIPs\n\n 51\n\n 3.9k\n\n Aug 2024\n\n GovHack Devcon in Bangkok - Hack Humanity\n\n Archived Proposals\n\n 74\n\n 1.9k\n\n Oct 2024\n\n GovHack - ETHDenver powered by Hack Humanity\n\n GovHack Denver\n\n 9\n\n 2.5k\n\n May 2024\n\n ArbitrumDAO Off-site - Directional proposal\n\n Finalized AIPs\n\n 89\n\n 2.3k\n\n Oct 2024","tokens":10072,"squid":"spider-07","role":"Council Spider","at":1791339626621,"hash":"d59584b63b6958d7a10eb995da16f5d7cc0f89d0"}
{"url":"https://arbitrum.io/products/usdg-vaults","domain":"arbitrum.io","title":"USDG Vaults – Arbitrum","text":"USDG on ArbitrumSame dollar,more ways to use itUSDG on Arbitrum can help your business access the programmable economy. Use one dollar across trading, lending, payments, and treasury, with ecosystem programs available to eligible partners.Issued by Paxos on behalf of Global Dollar Network.Integrate USDG todaySee how it works$3.1B+ USDG Market CapAcross all networksSource$3.2B+ USDG Transfer Volume (30D)Across all networksSource1:1 BackedSourceWHY USDGGet more from the dollar you trustUSDG on Arbitrum comes with partner programs for eligible businesses that build with it.Deepen active marketsUse USDG across trading pairs, liquidity pools, lending markets, and asset settlement flows.Build richer productsCreate earning, trading, treasury, and payment experiences around a single dollar balance.Keep liquidity in one placeGive users more ways to use USDG without fragmenting liquidity across multiple assets.USDG FLYWHEELIncentives aligned with the builders integrating USDGBy building with USDG on Arbitrum, eligible partners can participate in ecosystem programs.CHOOSE YOUR PATHWays to integrate USDG across your financial stackBuild with USDG when dollars need to trade, earn, collateralize activity, or move through your business.EMBEDDED EARNLaunch a USDG earn productConnect your existing application to third-party USDG vaults and offer your customers a simple earn experience.Embed USDG in your appTRADING & COLLATERALPut USDG at the center of trading and creditYour end users can leverage USDG as margin for perpetual markets, where available.Integrate USDG as collateralMARKETS & SETTLEMENTCreate a common dollar layer for markets and assetsUse USDG as a quote and settlement currency across spot and perpetual markets, DEX pools, and supported RWA issuance, minting, and redemption flows.Integrate USDG in tradingTREASURY OPERATIONSMove dollars through everyday operationsUse USDG to hold reserve balances, collect protocol fees, manage payroll, and support cross-border payments.Integrate USDG for treasuryFAQFrequently asked questionsWhat is USDG, and how is it different from USDC or USDT?USDG is a US dollar-backed stablecoin issued by Paxos and redeemable 1:1 for US dollars. Its key difference is that it allows partners in the Global Dollar Network to participate in ecosystem programs associated with growing stablecoin adoption. Learn more at Global Dollar Network.How can my business participate?Businesses can integrate USDG into their products today. For companies looking to take part in the ecosystem program with the Arbitrum Foundation, please get in touch to discuss eligibility.Does simply holding USDG in a wallet earn rewards?No. Holding USDG in a wallet does not yield returns. Third-party products, such as vaults, offer rewards independently under their own terms.Where can USDG be used on Arbitrum today?USDG is deployed and can be newly minted on the Arbitrum One network. Third-party USDG vaults can be found on the Arbitrum portal. Businesses looking to learn more about how USDG can be used on Arbitrum can get in touch.Go programmable with USDGTell us where USDG fits in your roadmap. We’ll help identify the right market, liquidity, collateral, earn, or partnership path.DisclaimerGlobal Dollar \"USDG\" is issued by Paxos Digital Singapore, which is a Major Payments Institution supervised by the Monetary Authority of Singapore. USDG is also issued by Paxos Issuance Europe under the supervision of FIN FSA and in compliance with MiCA. Learn more at globaldollar.com.\"USDG on Arbitrum\" is an ecosystem program offered by the Arbitrum Foundation (\"Foundation\"), and is available only to eligible businesses under a separate written agreement with the Foundation, at its sole discretion. Holding USDG does not entitle anyone to rewards from the Foundation.This webpage and its contents are provided for informational purposes only and does not constitute financial, legal, technological, any other form of advice, or an offer or a solicitation of any kind. Please conduct your own independent research and consult with a qualified professional before making any decisions. References to third-party products are not endorsements. All trademarks, logos, and brand names are the property of their respective owners, with all rights reserved.Subscribe for the latest updates.SolutionsFinanceGamingConsumerProductsArbitrum OneDedicated BlockchainsWhy ArbitrumPerformanceConfidentialityCustomizationComplianceIntegrationsCase StudiesDevelopersGet startedConfigure a chainBuild an appBridgeExplorerFaucetStatusGithubResourcesBlogPressTalksContact UsPortalGovernanceForumGrantsBrand KitLegalPrivacy PolicyTerms of ServiceStay in touch","tokens":1168,"squid":"spider-01","role":"Chain Spider","at":1791339636695,"hash":"98553c5192fd5714f469d66c153452a839273f03"}
{"url":"https://squidfunk.github.io/mkdocs-material/setup/setting-up-a-blog/","domain":"squidfunk.github.io","title":"Setting up a blog - Material for MkDocs","text":"Setting up a blog¶ Material for MkDocs makes it very easy to build a blog, either as a sidecar to your documentation or standalone. Focus on your content while the engine does all the heavy lifting, automatically generating archive and category indexes, post slugs, configurable pagination and more. Check out our blog, which is created with the new built-in blog plugin! Configuration¶ Built-in blog plugin¶ 9.2.0 create-blog The built-in blog plugin adds support for building a blog from a folder of posts, which are annotated with dates and other structured data. First, add the following lines to mkdocs.yml: plugins:\n - blog\n If you do not have a navigation (nav) definition in your mkdocs.yml then there is nothing else to do there as the blog plugin will add navigation automatically. If you do have a navigation defined then you need to add the blog index page only to it. You need not and should not add the individual blog posts. For example: nav:\n - index.md\n - Blog:\n - blog/index.md\n For a list of all settings, please consult the plugin documentation. RSS¶ 9.2.0 rss The built-in blog plugin integrates seamlessly with the RSS plugin, which provides a simple way to add an RSS feed to your blog (or to your whole documentation). Install it with pip: pip install mkdocs-rss-plugin\n Then, add the following lines to mkdocs.yml: plugins:\n - rss:\n match_path: blog/posts/.* \n date_from_meta:\n as_creation: date\n categories:\n - categories\n - tags \n The following configuration options are supported: enabled true This option specifies whether the plugin is enabled when building your project. If you want to speed up local builds, you can use an environment variable: plugins:\n - rss:\n enabled: !ENV [CI, false]\n match_path .* This option specifies which pages should be included in the feed. For example, to only include blog posts in the feed, use the following regular expression: plugins:\n - rss:\n match_path: blog/posts/.*\n date_from_meta This option specifies which front matter property should be used as a creation date of a page in the feed. It's recommended to use the date property: plugins:\n - rss:\n date_from_meta:\n as_creation: date\n categories This option specifies which front matter properties are used as categories as part of the feed. If you use categories and tags, add both with the following lines: plugins:\n - rss:\n categories:\n - categories\n - tags\n comments_path This option specifies the anchor at which comments for a post or page can be found. If you've integrated a comment system, add the following lines: plugins:\n - rss:\n comments_path: \"#__comments\"\n Material for MkDocs will automatically add the necessary metadata to your site which will make the RSS feed discoverable by browsers and feed readers. The other configuration options of this extension are not officially supported by Material for MkDocs, which is why they may yield unexpected results. Use them at your own risk. Blog only¶ You might need to build a pure blog without any documentation. In this case, you can create a folder tree like this: .\n├─ docs/\n│ ├─ posts/ \n│ ├─ .authors.yml\n│ └─ index.md\n└─ mkdocs.yml\n And add the following lines to mkdocs.yml: plugins:\n - blog:\n blog_dir: . \n With this configuration, the url of the blog post will be /<post_slug> instead of /blog/<post_slug>. Usage¶ Writing your first post¶ After you've successfully set up the built-in blog plugin, it's time to write your first post. The plugin doesn't assume any specific directory structure, so you're completely free in how you organize your posts, as long as they are all located inside the posts directory: .\n├─ docs/\n│ └─ blog/\n│ ├─ posts/\n│ │ └─ hello-world.md \n│ └─ index.md\n└─ mkdocs.yml\n Create a new file called hello-world.md and add the following lines: ---\ndraft: true \ndate: 2024-01-31 \ncategories:\n - Hello\n - World\n---\n\n# Hello world!\n...\n When you spin up the live preview server, you should be greeted by your first post! You'll also realize, that archive and category indexes have been automatically generated for you. Adding an excerpt¶ The blog index, as well as archive and category indexes can either list the entire content of each post, or excerpts of posts. An excerpt can be created by adding a <!-- more --> separator after the first few paragraphs of a post: # Hello world!\n\nLorem ipsum dolor sit amet, consectetur adipiscing elit. Nulla et euismod\nnulla. Curabitur feugiat, tortor non consequat finibus, justo purus auctor\nmassa, nec semper lorem quam in massa.\n\n<!-- more -->\n...\n When the built-in blog plugin generates all indexes, the content before the excerpt separator is automatically extracted, allowing the user to start reading a post before deciding to jump in. Adding authors¶ In order to add a little more personality to your posts, you can associate each post with one or multiple authors. First, create the .authors.yml file in your blog directory, and add an author: authors:\n squidfunk:\n name: Martin Donath\n description: Creator\n avatar: https://github.com/squidfunk.png\n The .authors.yml file associates each author with an identifier (in this example squidfunk), which can then be used in posts. Different attributes can be configured. For a list of all possible attributes, please consult the authors_file documentation. Now, you can assign one or more authors to a post by referencing their identifiers in the front matter of the Markdown file under the authors property. For each author, a small profile is rendered in the left sidebar of each post, as well as in post excerpts on index pages: ---\ndate: 2024-01-31\nauthors:\n - squidfunk\n ...\n---\n\n# Hello world!\n...\n Adding author profiles¶ 9.7.0 If you wish to add a dedicated page for each author, you can enable author profiles by setting the authors_profiles configuration option to true. Just add the following lines to mkdocs.yml: plugins:\n - blog:\n authors_profiles: true\n If you combine this with custom index pages, you can create a dedicated page for each author with a short description, social media links, etc. – basically anything you can write in Markdown. The list of posts is then appended after the content of the page. Adding categories¶ Categories are an excellent way for grouping your posts thematically on dedicated index pages. This way, a user interested in a specific topic can explore all of your posts on this topic. Make sure categories are enabled and add them to the front matter categories property: ---\ndate: 2024-01-31\ncategories:\n - Hello\n - World\n---\n\n# Hello world!\n...\n If you want to save yourself from typos when typing out categories, you can define your desired categories in mkdocs.yml as part of the categories_allowed configuration option. The built-in blog plugin will stop the build if a category is not found within the list. Adding tags¶ Besides categories, the built-in blog plugin also integrates with the built-in tags plugin. If you add tags in the front matter tags property as part of a post, the post is linked from the tags index: ---\ndate: 2024-01-31\ntags:\n - Foo\n - Bar\n---\n\n# Hello world!\n...\n As usual, the tags are rendered above the main headline and posts are linked on the tags index page, if configured. Note that posts are, as pages, only linked with their titles. Changing the slug¶ Slugs are the shortened description of your post used in the URL. They are automatically generated, but you can specify a custom slug for a page: ---\nslug: hello-world\n---\n\n# Hello there world!\n...\n Adding related links¶ 9.6.0 Related links offer the perfect way to prominently add a further reading section to your post that is included in the left sidebar, guiding the user to other destinations of your documentation. Use the front matter links property to add related links to a post: ---\ndate: 2024-01-31\nlinks:\n - plugins/search.md\n - insiders/how-to-sponsor.md\n---\n\n# Hello world!\n...\n You can use the exact same syntax as for the nav section in mkdocs.yml, which means you can set explicit titles for links, add external links and even use nesting: ---\ndate: 2024-01-31\nlinks:\n - plugins/search.md\n - insiders/how-to-sponsor.md\n - Nested section:\n - External link: https://example.com\n - setup/setting-up-site-search.md\n---\n\n# Hello world!\n...\n If you look closely, you'll realize that you can even use an anchor to link to a specific section of a document, extending the possibilities of the nav syntax in mkdocs.yml. The built-in blog plugin resolves the anchor and sets the title of the anchor as a subtitle of the related link. Note that all links must be relative to docs_dir, as is also the case for the nav setting. Linking from and to posts¶ While post URLs are dynamically computed, the built-in blog plugin ensures that all links from and to posts and a post's assets are correct. If you want to link to a post, just use the path to the Markdown file as a link reference (links must be relative): [Hello World!](blog/posts/hello-world.md)\n Linking from a post to a page, e.g. the index, follows the same method: [Blog](../index.md)\n All assets inside the posts directory are copied to the blog/assets folder when the site is being built. Of course, you can also reference assets from posts outside of the posts directory. The built-in blog plugin ensures that all links are correct. Pinning a post¶ 9.7.0 If you want to pin a post to the top of the index page, as well as the archive and category indexes it is part of, you can use the front matter pin property: ---\ndate: 2024-01-31\npin: true\n---\n\n# Hello world!\n...\n If multiple posts are pinned, they are sorted by their creation date, with the most recent pinned post being shown first, followed by the other pinned posts in descending order. Setting the reading time¶ When enabled, the reading the expected reading time of each post is computed, which is rendered as part of the post and post excerpt. Nowadays, many blogs show reading times, which is why the built-in blog plugin offers this capability as well. Sometimes, however, the computed reading time might not feel accurate, or result in odd and unpleasant numbers. For this reason, reading time can be overridden and explicitly set with the front matter readtime property for a post: ---\ndate: 2024-01-31\nreadtime: 15\n---\n\n# Hello world!\n...\n This will disable automatic reading time computation. Chinese, Japanese and Korean characters Reading time computation currently does not take segmentation of Chinese, Japanese and Korean characters into account. This means that the reading time for posts in these languages may be inaccurate. We're planning on adding support in the future. In the meantime, please use the readtime front matter property to set the reading time. Setting defaults¶ 9.6.0 meta – built-in If you have a lot of posts, it might feel redundant to define all of the above for each post. Luckily, the built-in meta plugin allows to set default front matter properties per folder. You can group your posts by categories, or authors, and add a .meta.yml file to set common properties: .\n├─ docs/\n│ └─ blog/\n│ ├─ posts/\n│ ├─ .meta.yml \n│ └─ index.md\n└─ mkdocs.yml\n Note that order matters – the built-in meta plugin must be defined before the blog plugin in mkdocs.yml, so that all set defaults are correctly picked up by the built-in blog plugin: plugins:\n - meta\n - blog\n Lists and dictionaries in .meta.yml files are merged and deduplicated with the values defined for a post, which means you can define common properties in .meta.yml and then add specific properties or overrides for each post. Adding pages¶ Besides posts, it's also possible to add static pages to your blog by listing the pages in the nav section of mkdocs.yml. All generated indexes are included after the last specified page. For example, to add a page on the authors of the blog, add the following to mkdocs.yml: nav:\n - Blog:\n - blog/index.md\n - blog/authors.md\n ...\n Customization¶ Custom index pages¶ 9.6.0 If you want to add custom content to automatically generated archive and category indexes, e.g. to add a category description prior to the list of posts, you can manually create the category page in the same location where the built-in blog plugin would create it: .\n├─ docs/\n│ └─ blog/\n│ ├─ category/\n│ │ └─ hello.md \n│ ├─ posts/\n│ └─ index.md\n└─ mkdocs.yml\n You can now add arbitrary content to the newly created file, or set specific front matter properties for this page, e.g. to change the page description: ---\ndescription: Nullam urna elit, malesuada eget finibus ut, ac tortor.\n---\n\n# Hello\n...\n All post excerpts belonging to the category are automatically appended. Overriding templates¶ The built-in blog plugin is built on the same basis as Material for MkDocs, which means you can override all templates used for the blog by using theme extension as usual. The following templates are added by the built-in blog plugin: blog.html – Template for blog, archive and category index blog-post.html – Template for blog post","tokens":3228,"squid":"spider-06","role":"Security Spider","at":1791339637966,"hash":"f5885f50212448cb5f58d5527c1bc2b0458f2036"}
{"url":"https://forum.arbitrum.foundation/c/archive/govhack-denver/42","domain":"forum.arbitrum.foundation","title":"Latest Archive/GovHack Denver topics - Arbitrum","text":"The Arbitrum Foundation notified the Security Council on the need to perform a potential Emergency action. Following a review of the details and known risks, the Security Council decided to execute the upgrade and it was completed at 11:30 EST on 2nd October 2026.\nThis report provides an overview of the risks that required the Security Council Action:\n\nAdd a permissionless guard for the One-Step Proof of BoLD on Arbitrum One\n\nTemporarily pause activation of new Stylus contracts on Arbitrum One & Nova\n\nKey point: To date, known bugs for Stylus primarily impact chain liveness (e.g., denial of service attacks) and do not put any user funds at risk.\nWhy was this action taken\nLet’s take this opportunity to explain why action was taken on two separate issues concerning BoLD and Stylus.\nInstalling the guard for One-Step Proof of BoLD. Given the rise of AI-assisted attacks, we have implemented a precautionary approach that allows anyone to pause settlement of Arbitrum One on Ethereum if there are at least two conflicting answers that pass at the same level in which only one should be valid and pass. This is to halt a class of publicly verifiable and detectable attacks that exploit a bug in the one-step proof. If halted, Arbitrum One will continue to process as normal except that messages from Arbitrum One to Ethereum, such as withdrawals, that are not yet confirmed will have to wait. This provides time for the Security Council to deploy a fix for the bug and resume the rollup.\nPreventing activation of new Stylus contracts. AI-assisted tooling has led to an increasing number of sophisticated attacks on hand-crafted WASM programs that do not use the standard Stylus compiler toolchain. These programs are specifically designed to cause unexpected behaviors such as degrading the chain’s performance for all other users. To date, no attacks have been discovered that permits theft of user funds.\nNew ArbOS releases have patched several reported bugs and known attacks over the past few months, but out of an abundance of caution, we have decided to temporarily pause new activations of Stylus contracts. This was executed as an emergency action to prevent the deployment of new hand-crafted WASM programs that are not yet patched by the current version of ArbOS on the Arbitrum network.\nThe Arbitrum Foundation has informed the Security Council that they will work with the ArbitrumDAO to discuss next steps on the timeline and manner for enabling activation of new Stylus contracts. The Arbitrum community remains confident in the value of Stylus and want to preserve these use cases while taking preventative measures against Stylus-based attack vectors as AI-assisted attack tooling continues to evolve.\nImpact on builders and users\n\nNo new activations. New Stylus contracts cannot be activated during the pause including new versions of existing applications that require activation.\n\nExisting contracts are not paused. Already-active Stylus contracts continue to execute until expiration. This pause does not deactivate them.\n\nThe ArbOS 61 upgrade renewed all active contracts on Arbitrum One, so no currently active contract expires before August 20, 2027.\n\nRenewal via keepalive stays permissionless and is unaffected by the pause.\n\nReactivating an expired contract, or one that needs to be updated after a Stylus version change, is paused.\n\nUsing/calling any activated Stylus contract stays permissionless for all users and developers.\n\nNo impact on EVM. Solidity (EVM) contract deployment and execution are unaffected by this Security Council action.\n\nSecurity Council Actions\nThere are two actions bundled into a single payload:\n\nOne-Step Proof Guard. The L1UpgradeExecutor gives a new pause contract (PauseExecutor) the ability to pause and nothing else. The new pause contract grants the guard (OspSoundnessGuard) PAUSER_ROLE to use it. Anyone can show the guard two conflicting answers to the same step of an open challenge. If the one-step proof accepts both, the guard has the pause contract put Arbitrum One’s settlement to Ethereum on hold.\n\nStylus deactivation. The Security Council called ArbOwner.setWasmActivationGas(2^64 - 1) to raise the Stylus activation gas requirement on Arbitrum One and Nova. This makes activation prohibitively expensive and effectively disables new activations. This is a configuration change and does not require an ArbOS upgrade.\n\nThe Security Council signed the following transactions to update the configuration:\n\nEthereum: Ethereum Transaction Hash: 0x30732bb7d2... | Etherscan\nArbitrum One:\nArbitrum One Transaction Hash: 0x9eb3a4be3b... | Arbitrum One\nArbitrum Nova:\nArbitrum Nova transaction 0x79e0fed470dff7a22059b108e3f8f42eddd2b580a6771594060c4e7326c5f984 | Blockscout\n\nAn external audit was conducted for the OSP Guard contracts. No audit is required for the Stylus deactivation as it is only updating a single parameter in the ArbOS configuration.\n\n Latest topics in GovHack Denver\n\n Archive\n\n GovHack Denver\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 GovHack Day 3 Community Voting - Top 5 GovHack Teams\n\n Top 5 Finalists\n\nHuge congratulations to Teams 5, 8, 11, 13, and 20 for making it to the top 5! \nCommunity to select the winners on Day 3\nHere’s a video recording of what is goi…\n\n read more\n\n 2\n\n 807\n\n Feb 2024\n\n GovHack ETHDenver 2024 - Impact Report - Hack Humanity\n\n 9\n\n 1.6k\n\n Jun 2024\n\n GovHack - ETHDenver powered by Hack Humanity\n\n 9\n\n 2.5k\n\n May 2024\n\n Team 22 - Establishment of Arbitrum Venture Initiative (AVI)\n\n 1\n\n 936\n\n Apr 2024\n\n Team 12: Empowering underrepresented delegates\n\n contributor-onboardi\n\n 2\n\n 889\n\n Mar 2024\n\n Team 13 GovHack Proposal\n\n proposal,dao-bd-strategy\n\n 2\n\n 928\n\n Mar 2024\n\n Team 20 - Contributor Mining — Get the contributors paid\n\n 5\n\n 1.0k\n\n Mar 2024\n\n Team 7 - ARBITRUM ONE GOVERNANCE COMPOSABILITY\n\n proposal\n\n 1\n\n 686\n\n Feb 2024\n\n Team 5: Backup Sequencers\n\n 2\n\n 733\n\n Feb 2024\n\n Top 5 GovHack Teams Announcement\n\n 0\n\n 564\n\n Feb 2024\n\n Team 1: Assembly for Defining Strategic Pillars\n\n strategic-big-bets\n\n 0\n\n 585\n\n Feb 2024\n\n Team #8: Better BD / Branding for Gaming in ARB\n\n 0\n\n 716\n\n Feb 2024\n\n Team 14 - Perp-Traders onboarding Program: from CEX to Perps DEX\n\n 0\n\n 669\n\n Feb 2024\n\n Team 19: ART to gov-nect\n\n proposal\n\n 0\n\n 555\n\n Feb 2024\n\n Team 11 - Introduce Contributor Onboarding to Arbitrum DAO\n\n 0\n\n 773\n\n Feb 2024\n\n Team 10: Grantser: Create Arbitrum Grant Proposals That Get Funded\n\n proposal,dao-operational-exce\n\n 1\n\n 640\n\n Feb 2024\n\n Team 3 - Ecosystem Firestarter Fund\n\n grants-ecosystem\n\n 0\n\n 694\n\n Feb 2024\n\n Team 2: Accelerating Arbitrum Governance\n\n 0\n\n 658\n\n Feb 2024\n\n Game SDK for interoperable Game Economies\n\n 0\n\n 539\n\n Feb 2024\n\n Team number: 18 + contribution score: develop an individual scoring system proportional to the total value of each person´s contributions\n\n 0\n\n 549\n\n Feb 2024\n\n [DRAFT] Team 4 - Establishment of an Orbit Advocate Role\n\n orbit-adoption-strat\n\n 0\n\n 617\n\n Feb 2024\n\n Arbitrum GovHack Track: Enhancing Grantee Engagement and Alignment in the Arbitrum Ecosystem- team 16\n\n grants-ecosystem,contributor-onboardi\n\n 0\n\n 575\n\n Feb 2024\n\n Team 23 - M&A for Arbitrum DAO\n\n strategic-big-bets\n\n 0\n\n 615\n\n Feb 2024\n\n Team 9: decentralized $ARB liquidity\n\n 0\n\n 616\n\n Feb 2024\n\n Team 15 - Orbit Adoption Catalyst Programme\n\n orbit-adoption-strat\n\n 0\n\n 634\n\n Feb 2024\n\n Team 21 : ZAudit - Empower Trust in Web3 Ecosystem\n\n 0\n\n 529\n\n Feb 2024\n\n Team 6 - Builder Pathways Towards Adoption\n\n proposal\n\n 0\n\n 678\n\n Feb 2024\n\n Proposal Submission, Pitching & Judging Process\n\n 0\n\n 301\n\n Feb 2024\n\n Tean 23 - M&A for Arbitrum DAO - OLD\n\n 0\n\n 625\n\n Feb 2024","tokens":1919,"squid":"spider-07","role":"Council Spider","at":1791339640315,"hash":"9b8cd15cb29f1c0b6948a1ffaf634f4c344364cf"}
{"url":"https://forum.arbitrum.foundation/t/team-12-empowering-underrepresented-delegates/21533/5","domain":"forum.arbitrum.foundation","title":"Team 12: Empowering underrepresented delegates - Archive / GovHack Denver - Arbitrum","text":"The Arbitrum Foundation notified the Security Council on the need to perform a potential Emergency action. Following a review of the details and known risks, the Security Council decided to execute the upgrade and it was completed at 11:30 EST on 2nd October 2026.\nThis report provides an overview of the risks that required the Security Council Action:\n\nAdd a permissionless guard for the One-Step Proof of BoLD on Arbitrum One\n\nTemporarily pause activation of new Stylus contracts on Arbitrum One & Nova\n\nKey point: To date, known bugs for Stylus primarily impact chain liveness (e.g., denial of service attacks) and do not put any user funds at risk.\nWhy was this action taken\nLet’s take this opportunity to explain why action was taken on two separate issues concerning BoLD and Stylus.\nInstalling the guard for One-Step Proof of BoLD. Given the rise of AI-assisted attacks, we have implemented a precautionary approach that allows anyone to pause settlement of Arbitrum One on Ethereum if there are at least two conflicting answers that pass at the same level in which only one should be valid and pass. This is to halt a class of publicly verifiable and detectable attacks that exploit a bug in the one-step proof. If halted, Arbitrum One will continue to process as normal except that messages from Arbitrum One to Ethereum, such as withdrawals, that are not yet confirmed will have to wait. This provides time for the Security Council to deploy a fix for the bug and resume the rollup.\nPreventing activation of new Stylus contracts. AI-assisted tooling has led to an increasing number of sophisticated attacks on hand-crafted WASM programs that do not use the standard Stylus compiler toolchain. These programs are specifically designed to cause unexpected behaviors such as degrading the chain’s performance for all other users. To date, no attacks have been discovered that permits theft of user funds.\nNew ArbOS releases have patched several reported bugs and known attacks over the past few months, but out of an abundance of caution, we have decided to temporarily pause new activations of Stylus contracts. This was executed as an emergency action to prevent the deployment of new hand-crafted WASM programs that are not yet patched by the current version of ArbOS on the Arbitrum network.\nThe Arbitrum Foundation has informed the Security Council that they will work with the ArbitrumDAO to discuss next steps on the timeline and manner for enabling activation of new Stylus contracts. The Arbitrum community remains confident in the value of Stylus and want to preserve these use cases while taking preventative measures against Stylus-based attack vectors as AI-assisted attack tooling continues to evolve.\nImpact on builders and users\n\nNo new activations. New Stylus contracts cannot be activated during the pause including new versions of existing applications that require activation.\n\nExisting contracts are not paused. Already-active Stylus contracts continue to execute until expiration. This pause does not deactivate them.\n\nThe ArbOS 61 upgrade renewed all active contracts on Arbitrum One, so no currently active contract expires before August 20, 2027.\n\nRenewal via keepalive stays permissionless and is unaffected by the pause.\n\nReactivating an expired contract, or one that needs to be updated after a Stylus version change, is paused.\n\nUsing/calling any activated Stylus contract stays permissionless for all users and developers.\n\nNo impact on EVM. Solidity (EVM) contract deployment and execution are unaffected by this Security Council action.\n\nSecurity Council Actions\nThere are two actions bundled into a single payload:\n\nOne-Step Proof Guard. The L1UpgradeExecutor gives a new pause contract (PauseExecutor) the ability to pause and nothing else. The new pause contract grants the guard (OspSoundnessGuard) PAUSER_ROLE to use it. Anyone can show the guard two conflicting answers to the same step of an open challenge. If the one-step proof accepts both, the guard has the pause contract put Arbitrum One’s settlement to Ethereum on hold.\n\nStylus deactivation. The Security Council called ArbOwner.setWasmActivationGas(2^64 - 1) to raise the Stylus activation gas requirement on Arbitrum One and Nova. This makes activation prohibitively expensive and effectively disables new activations. This is a configuration change and does not require an ArbOS upgrade.\n\nThe Security Council signed the following transactions to update the configuration:\n\nEthereum: Ethereum Transaction Hash: 0x30732bb7d2... | Etherscan\nArbitrum One:\nArbitrum One Transaction Hash: 0x9eb3a4be3b... | Arbitrum One\nArbitrum Nova:\nArbitrum Nova transaction 0x79e0fed470dff7a22059b108e3f8f42eddd2b580a6771594060c4e7326c5f984 | Blockscout\n\nAn external audit was conducted for the OSP Guard contracts. No audit is required for the Stylus deactivation as it is only updating a single parameter in the ArbOS configuration.\n\n ArchiveGovHack Denver\n\n contributor-onboardi\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Feb 2024\n\n 5 / 5\n\n Mar 2024\n\n Mar 2024\n\n post by EventHorizonDAO on Feb 27, 2024\n\n EventHorizonDAO\n\n Arbitrum GovHack Track:\nContributor onboarding, activation & engagement\nChallenge Statement:\nDelegation proportionate to participation.\nMembers:\n404DAO\nEvent Horizon\nMatt Fiebach\nJengajojo (DAOStewards)\nNon-constitutional\nThis proposal has taken influence from a proposal created by Stable Lab in Uniswap DAO and we thank them for their inspiration.\nTL;DR\nThis proposal seeks to increase participation in the DAO by empowering underrepresented delegates who, despite active participation in governance, do not have sufficient voting power to have their ideas seriously considered. Since greater voting power often correlates with heightened attention by the DAO’s key stakeholders, we propose creating a DAO-controlled Franchiser contract and distributing 1M in ARB each of up to 10 delegates who 1) currently have between 50,000 and 1,000,000 in voting power, 2) have shown an onchain voting participation rate >80% in the last 3 months and 3) have been voted as the top 10 delegates of these candidates by the DAO voted on in a Snapshot poll.\nAbstract\nWe ask the DAO to run a 1-year trial program that delegates $ARB to Active Delegates who are underrepresented in governance. If this proposal passes, the foundation will create a Franchiser contract to technically allow for this process. The DAO will maintain control of all $ARB allocated to the program, and have the ability to clawback delegations through an onchain proposal at any time. The contract is owned by the DAO and the tokens are delegated, not granted, but never leave the contract or DAO treasury in practice. Rather, they are stored in a new DAO-owned address.\nBy allocating 1M $ARB each to up to 10 delegates with between 50k-1m $ARB who have voted on >80% of onchain proposals in the last 3 months, the DAO will empower more meaningful voices in its proposals. A quarterly Active Delegate refresh is encouraged to maintain accountability of those who have been allocated delegation and give newly qualified delegates a chance to participate. The proposal will also give more delegates the ability to propose Snapshot votes and further diversify the makeup of the DAO. Snapshots have a threshold of 500K ARB and onchain proposals 1M to propose.\nMotivation\nDuring Arbitrum’s GovHack hackathon, the challenge statement of “Delegation proportionate to participation” emerged as a key challenge for the DAO. Furthermore, the community has sought creative ways to leverage delegation, rather than grants, to boost voter participation and encourage meaningful contributions (see this, this, and this).\nCurrently, there are a group of delegates who have demonstrated a commitment to governance through consistent participation in on-chain governance. However, despite their active involvement, they are significantly marginalized in terms of voting power. Since greater voting power often correlates with heightened attention from delegates and the community, we believe that boosting the voting power of these delegates will enable them to have their ideas seriously considered, creating a more robust idea generation and iteration pipeline. Within the DAO, a higher allocation of voting power not only empowers individuals to propose initiatives but also garners increased attention from active delegates and community members.\nMany of Arbitrum’s key delegates holding substantial voting rights participate in fewer votes than smaller delegate counterparts. This is evidenced by the observation that many recipients of sizable delegations have shown minimal participation in governance activities. In an effective DAO, engaged delegates play a critical role by exercising their substantial voting rights. Giving smaller delegates who have shown rigor in their activity a more meaningful voice and voting power in the DAO will help toward this overarching goal.\nEligibility\nActive delegate voters with the following qualifications can be considered for the program:\n\n80% participation over the last 3 months on Tally\n50,000 to 1,000,000 $ARB voting power\n\nData\nOver the last 3 months there have been 6 onchain proposals that count and a delegate must have voted on at least 5 in order to qualify. 25 addresses currently qualify.\nScreenshot 2024-02-27 at 14.18.521216×1328 146 KB\nQualified applicants must self nominate themselves to be considered.\nNext Steps\n\nWe encourage the community to leave comments and feedback on this forum post\nProject managers will create a snapshot vote so that the DAO can signal approval or disapproval for the program.\nStart working on deployment of Franchiser Contract\nUpon successful Snapshot #1, program managers will create a forum post for nominations\nQualified delegates to nominate themselves on post within 7-days.\nProject managers post this proposal to a Snapshot vote for 7 days during which time delegates will vote on the top 10 applicants to be included in the program. Encrypted weighted voting.\nAfter the Snapshot vote ends, we will post the proposal to Tally for an on-chain vote and delegation executable.\n\nFollowing self-nomination to receive delegation, a Snapshot vote will go live so that the DAO may decide which delegates (up to 10) should be included in the program.\nTechnical Implementation\nIn order to implement this proposal, it is required that we create a DAO-controlled Franchiser contract. The contract owner would be the DAO timelock and it would allow the DAO the power to delegate and undelegate tokens that it sends from the treasury to the Franchiser. We suggest that the Foundation aids in the creation of this contract in order to create an official and safe implementation, though we can likely fork the Trail of Bits audited Uniswap Labs implementation [github] of the same concept. If this proposal passes Snapshot, we request that the Foundation take the time to fork the contract and hire an auditor to check the implementation.\nThe contract has simple functions:\n-Fund: allows the DAO to send tokens to contract and delegate to a single address\n-FundMany: allows the DAO to send tokens to contract and delegate any amount to multiple addresses\n-Recall: allows DAO to pull back funds from Franchiser effectively undelegating and returning tokens to treasury from a single delegate.\n-RecallMany: allows DAO to pull back funds from franchiser effectively undelegating and returning tokens to treasury from multiple delegates.\nIt is worth noting that all tokens sent to the Franchiser will remain a part of the DAO’s balance sheet as it has full-control over the contract. The delegated tokens never leave the DAO’s ownership.\nTimeline\n\nForum feedback 1 week\n(optional) Repost on forum incase there are major changes requested: 1 week\nSnapshot vote 1 week\nWork with foundation to deploy contracts: 1 month\nOnchain vote: 3 weeks\nFirst quarterly report: 3 months\nSecond quarterly report: 3 months\nThird quarterly report: 3 months\nFinal quarterly report: 3 months\n\nProgram Administration\nThis working group will project admin this program. The specific deliverables include:\n\nWork with the foundation for contract creation and deployment\nCreate quarterly reports on delegate performance so that the DAO may have a resource to hold delegates accountable\nIn the event that a chosen delegate falls below 80%, communicate with the DAO and put up a vote to revoke their delegation\n\nNote: This is not a position of power, just a project management work which is limited to the above executables\nWe will create a 3 of 4 multi-sig governed by the proposers paid upfront if the proposal passes onchain voting.\nSigners:\n-Jengajojo (DAOStewards)\n-404 DAO (Cole Schendl & Rika Goldberg)\n-Event Horizon\n-Matt Fiebach\nOverall Cost\n\nUp to 10M ARB to be transferred into the Franchiser contract, still owned by the DAO (no cost)\n$15,000 in ARB for program management and reporting for 1 year\n\nConsiderations:\n\nWe want to encourage members of the DAO to review the program and consider removal or addition of delegates to the program quarterly\nIf this program goes well, the DAO should consider iterating on the active delegate criteria, number of votes to be delegated and interval in which the delegation is refreshed.\nThe Franchiser contract will enable use cases beyond just this program. For example, the foundation may opt to temporarily delegate tokens so that any entity can make a snapshot/onchain proposal. It may be used in further programs to give delegations from the Treasury. It will allow one address to delegate its token across many delegates (though the DAO will maintain ownership as well).\n\nVideo link\n\n Delegate to a public access, public good citizen enfranchisement pool through Event Horizon\n\n read \n\n 4\n min\n\n post by MattOnChain on Feb 27, 2024\n\n MattOnChain\n\n Seems like our proposal, particularly the franchiser aspect, could be a good use of the ARDC security member to audit!\n\n Closed on Feb 27, 2024\n\n Opened on Feb 27, 2024\n\n 12 days later\n\n post by Tane on Mar 10, 2024\n\n Tane\n\n Hi Christian and other contributors to this proposal. Excited to see the comprehensive proposal like this came out from the GovHack!\n\nAlready told some members in your team, but we believe that lowering the minimum voting power to be qualified for the program would suit the purpose of the proposal: “empowering under-represented delegates” since the delegates with over 50k VP will be incentivized by the new program led by SEED Latam team.\n\n [RFC] Empowering Underrepresented Delegates\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [RFC] Empowering Underrepresented Delegates\n\n Archived Proposals\n\n proposal\n\n 35\n\n 2.1k\n\n May 2025\n\n Arbitrum DAO’s Delegate Engagement Apathy Determent program (Arb DAO DEAD Program) - Pilot \n\n Voting Rationale & Governance Calls\n\n 13\n\n 458\n\n Dec 2024\n\n [Request for Support] Empowering Underrepresented Delegates Proposal\n\n ARDC DAO Advocate (old)\n\n 3\n\n 8.0k\n\n Sep 2025\n\n [DIP v1.0]From Engagement to Rewards: A Comprehensive Analysis of Participation and Incentives\n\n Delegate Incentives Program (DIP)\n\n 8\n\n 582\n\n Aug 2024\n\n Non-Constitutional: Amendment to the Delegate Incentives Program\n\n Archived Proposals\n\n 55\n\n 1.6k\n\n Feb 2025","tokens":3826,"squid":"spider-07","role":"Council Spider","at":1791339650498,"hash":"746f75164708c1f9618f77c7e719d7ebe34bcddf"}
{"url":"https://forum.arbitrum.foundation/c/governance/6","domain":"forum.arbitrum.foundation","title":"Latest Voting Rationale & Governance Calls topics - Arbitrum","text":"The Arbitrum Foundation notified the Security Council on the need to perform a potential Emergency action. Following a review of the details and known risks, the Security Council decided to execute the upgrade and it was completed at 11:30 EST on 2nd October 2026.\nThis report provides an overview of the risks that required the Security Council Action:\n\nAdd a permissionless guard for the One-Step Proof of BoLD on Arbitrum One\n\nTemporarily pause activation of new Stylus contracts on Arbitrum One & Nova\n\nKey point: To date, known bugs for Stylus primarily impact chain liveness (e.g., denial of service attacks) and do not put any user funds at risk.\nWhy was this action taken\nLet’s take this opportunity to explain why action was taken on two separate issues concerning BoLD and Stylus.\nInstalling the guard for One-Step Proof of BoLD. Given the rise of AI-assisted attacks, we have implemented a precautionary approach that allows anyone to pause settlement of Arbitrum One on Ethereum if there are at least two conflicting answers that pass at the same level in which only one should be valid and pass. This is to halt a class of publicly verifiable and detectable attacks that exploit a bug in the one-step proof. If halted, Arbitrum One will continue to process as normal except that messages from Arbitrum One to Ethereum, such as withdrawals, that are not yet confirmed will have to wait. This provides time for the Security Council to deploy a fix for the bug and resume the rollup.\nPreventing activation of new Stylus contracts. AI-assisted tooling has led to an increasing number of sophisticated attacks on hand-crafted WASM programs that do not use the standard Stylus compiler toolchain. These programs are specifically designed to cause unexpected behaviors such as degrading the chain’s performance for all other users. To date, no attacks have been discovered that permits theft of user funds.\nNew ArbOS releases have patched several reported bugs and known attacks over the past few months, but out of an abundance of caution, we have decided to temporarily pause new activations of Stylus contracts. This was executed as an emergency action to prevent the deployment of new hand-crafted WASM programs that are not yet patched by the current version of ArbOS on the Arbitrum network.\nThe Arbitrum Foundation has informed the Security Council that they will work with the ArbitrumDAO to discuss next steps on the timeline and manner for enabling activation of new Stylus contracts. The Arbitrum community remains confident in the value of Stylus and want to preserve these use cases while taking preventative measures against Stylus-based attack vectors as AI-assisted attack tooling continues to evolve.\nImpact on builders and users\n\nNo new activations. New Stylus contracts cannot be activated during the pause including new versions of existing applications that require activation.\n\nExisting contracts are not paused. Already-active Stylus contracts continue to execute until expiration. This pause does not deactivate them.\n\nThe ArbOS 61 upgrade renewed all active contracts on Arbitrum One, so no currently active contract expires before August 20, 2027.\n\nRenewal via keepalive stays permissionless and is unaffected by the pause.\n\nReactivating an expired contract, or one that needs to be updated after a Stylus version change, is paused.\n\nUsing/calling any activated Stylus contract stays permissionless for all users and developers.\n\nNo impact on EVM. Solidity (EVM) contract deployment and execution are unaffected by this Security Council action.\n\nSecurity Council Actions\nThere are two actions bundled into a single payload:\n\nOne-Step Proof Guard. The L1UpgradeExecutor gives a new pause contract (PauseExecutor) the ability to pause and nothing else. The new pause contract grants the guard (OspSoundnessGuard) PAUSER_ROLE to use it. Anyone can show the guard two conflicting answers to the same step of an open challenge. If the one-step proof accepts both, the guard has the pause contract put Arbitrum One’s settlement to Ethereum on hold.\n\nStylus deactivation. The Security Council called ArbOwner.setWasmActivationGas(2^64 - 1) to raise the Stylus activation gas requirement on Arbitrum One and Nova. This makes activation prohibitively expensive and effectively disables new activations. This is a configuration change and does not require an ArbOS upgrade.\n\nThe Security Council signed the following transactions to update the configuration:\n\nEthereum: Ethereum Transaction Hash: 0x30732bb7d2... | Etherscan\nArbitrum One:\nArbitrum One Transaction Hash: 0x9eb3a4be3b... | Arbitrum One\nArbitrum Nova:\nArbitrum Nova transaction 0x79e0fed470dff7a22059b108e3f8f42eddd2b580a6771594060c4e7326c5f984 | Blockscout\n\nAn external audit was conducted for the OSP Guard contracts. No audit is required for the Stylus deactivation as it is only updating a single parameter in the ArbOS configuration.\n\n Latest topics in Voting Rationale & Governance Calls\n\n Voting Rationale & Governance Calls\n\n subcategories\n\n tags\n\n Latest\n\n Top\n\n Weekly Voting Reminders & Updates\n\n 14 September, 2026 - Roundup of Active/Upcoming Votes\n\n 24 August, 2026 - Roundup of Active/Upcoming Votes\n\n 18 August, 2026 - Roundup of Active/Upcoming Votes\n\n Biweekly Proposals Discussions Call\n\n October 6, 2026 - Open Discussion of Proposals Governance Call\n\n September 22, 2026 - Open Discussion of Proposals Governance Call\n\n September 8, 2026 - Open Discussion of Proposals Governance Call\n\n Governance Reporting Call (GRC)\n\n 41st GRC Call - Recording & Transcript\n\n 40th GRC Call - Recording & Transcript\n\n 39th GRC Call - Recording & Transcript\n\n Delegate Statements\n\n Delegate Statement Template\n\n SEEDGov Delegate Communication Thread\n\n Yoav.eth Delegate Communication Thread\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n How to add an event to the ArbitrumDAO Governance Community Calendar\n\n Voting Rationale & Governance Calls\n\n Arbitrum DAO has a community-run Google calendar where all important calls and events are added for the convenience of delegates and other interested parties. \nWhile any contributor in the DAO can add their event to the …\n\n read more\n\n 0\n\n 688\n\n Dec 2024\n\n About the Voting Rationale & Governance Calls category\n\n Voting Rationale & Governance Calls\n\n Keep abreast about a delegate’s voting record and upcoming governance calls.\n\n 0\n\n 1.4k\n\n Aug 2023\n\n October 6, 2026 - Open Discussion of Proposals Governance Call\n\n Biweekly Proposals Discussions Call\n\n 0\n\n 27\n\n 1d\n\n September 22, 2026 - Open Discussion of Proposals Governance Call\n\n Biweekly Proposals Discussions Call\n\n 1\n\n 69\n\n 1d\n\n SEEDGov Delegate Communication Thread\n\n Delegate Statements\n\n 3\n\n 262\n\n 19d\n\n Yoav.eth Delegate Communication Thread\n\n Delegate Statements\n\n delegate-statements\n\n 28\n\n 413\n\n 21d\n\n Sov: Delegate Communication Thread\n\n Delegate Statements\n\n 12\n\n 233\n\n 21d\n\n Uniswap-Arbitrum Delegate Program (UADP) Communication Thread\n\n Delegate Statements\n\n delegation,delegate-statements\n\n 99\n\n 5.2k\n\n 22d\n\n Axia Network — Delegate Communications Thread\n\n Delegate Statements\n\n delegate-statements\n\n 20\n\n 351\n\n 22d\n\n 14 September, 2026 - Roundup of Active/Upcoming Votes\n\n Weekly Voting Reminders & Updates\n\n 0\n\n 76\n\n 22d\n\n Griff Green - Delegate Communication Thread\n\n Delegate Statements\n\n delegation,delegate-statements\n\n 71\n\n 1.9k\n\n 23d\n\n 41st GRC Call - Recording & Transcript\n\n Governance Reporting Call (GRC)\n\n 1\n\n 88\n\n 23d\n\n DZack23.eth Delegate Communications thread\n\n Delegate Statements\n\n 27\n\n 436\n\n 23d\n\n PGov Delegate Communication Thread\n\n Delegate Statements\n\n governance,delegation,delegate-statements\n\n 112\n\n 3.0k\n\n 25d\n\n September 8, 2026 - Open Discussion of Proposals Governance Call\n\n Biweekly Proposals Discussions Call\n\n 1\n\n 77\n\n 28d\n\n Arana Digital Delegate Communication Thread\n\n Delegate Statements\n\n governance,delegation,delegate-statements\n\n 49\n\n 2.1k\n\n Aug 31\n\n Zeptimus Delegate Communication Thread\n\n Delegate Statements\n\n 28\n\n 723\n\n Aug 31\n\n Cp0x Delegate Communication Thread\n\n Delegate Statements\n\n delegation,delegate-statements\n\n 247\n\n 5.9k\n\n Aug 28\n\n August 25, 2026 - Open Discussion of Proposals Governance Call\n\n Biweekly Proposals Discussions Call\n\n 1\n\n 66\n\n Aug 26\n\n August 11, 2026 - Open Discussion of Proposals Governance Call\n\n Biweekly Proposals Discussions Call\n\n 1\n\n 74\n\n Aug 26\n\n JoJo Delegate Communication Thread\n\n Delegate Statements\n\n governance,delegation,delegate-statements\n\n 29\n\n 1.7k\n\n Aug 24\n\n 24 August, 2026 - Roundup of Active/Upcoming Votes\n\n Weekly Voting Reminders & Updates\n\n 0\n\n 67\n\n Aug 24\n\n 18 August, 2026 - Roundup of Active/Upcoming Votes\n\n Weekly Voting Reminders & Updates\n\n 0\n\n 62\n\n Aug 18\n\n Areta Delegate Thread\n\n Delegate Statements\n\n delegation,delegate-statements\n\n 27\n\n 819\n\n Aug 12\n\n 40th GRC Call - Recording & Transcript\n\n Governance Reporting Call (GRC)\n\n 1\n\n 94\n\n Aug 11\n\n 11 August, 2026 - Roundup of Active/Upcoming Votes\n\n Weekly Voting Reminders & Updates\n\n 0\n\n 59\n\n Aug 11\n\n 3 August, 2026 - Roundup of Active/Upcoming Votes\n\n Weekly Voting Reminders & Updates\n\n 0\n\n 79\n\n Aug 3\n\n July 28, 2026 - Open Discussion of Proposals Governance Call\n\n Biweekly Proposals Discussions Call\n\n 1\n\n 77\n\n Jul 29\n\n 29 July, 2026 - Roundup of Active/Upcoming Votes\n\n Weekly Voting Reminders & Updates\n\n 0\n\n 44\n\n Jul 29\n\n 21 July, 2026 - Roundup of Active/Upcoming Votes\n\n Weekly Voting Reminders & Updates\n\n 0\n\n 61\n\n Jul 21","tokens":2360,"squid":"spider-07","role":"Council Spider","at":1791339660694,"hash":"dd729505eb83e3ebcae0bd5b8ca3c51ed01db2fa"}
{"url":"https://docs.phantom.com/resources/cursor-prompts","domain":"docs.phantom.com","title":"Cursor AI prompts - Phantom developer documentation","text":"​Overview\nUse these prompts with Cursor AI to implement Phantom wallet integration. Copy the prompt for your preferred SDK and paste it into Cursor.\nFor the best experience, install the Phantom Cursor plugin. It bundles MCP servers, subagents, skills, and rules so Cursor can scaffold complete Phantom integrations, follow best practices automatically, and execute wallet operations — all without manual prompts.\nFor better results with manual prompts, add the Phantom Connect SDK MCP server to Cursor. This gives your AI assistant access to Phantom documentation for more accurate answers.\n​React SDK prompt\nView React SDK promptImplement Phantom React SDK integration for Solana with the following requirements:\n\nINSTALLATION:\n1. Install the SDK: npm install @phantom/react-sdk\n2. Install Solana dependencies: npm install @solana/web3.js\n\nSETUP:\n1. Create App.tsx that wraps your application with PhantomProvider:\n - Import: PhantomProvider, useConnect, useSolana, useAccounts, useDisconnect from \"@phantom/react-sdk\"\n - Import: AddressType from \"@phantom/browser-sdk\"\n - Configure PhantomProvider with:\n * providerType: \"embedded\"\n * addressTypes: [AddressType.solana]\n * appId: \"[YOUR_APP_ID]\"\n * authOptions: {\n authUrl: \"https://connect.phantom.app/login\",\n redirectUrl: \"[YOUR_REDIRECT_URL]\"\n }\n\nWALLET CONNECTION COMPONENT:\n1. Create a component that uses useConnect() and useAccounts() hooks\n2. useConnect() returns: { connect, isConnecting }\n3. Call connect() to initiate connection, returns: { addresses }\n4. useAccounts() returns the connected Solana addresses array\n5. Display \"Connect Wallet\" button when not connected\n6. Display connected Solana address when connected\n7. Add a disconnect button using useDisconnect() hook\n\nMESSAGE SIGNING COMPONENT:\n1. Create component that uses useSolana() hook\n2. Get Solana interface: const { solana } = useSolana()\n3. Sign message: await solana.signMessage(\"Your message here\")\n4. Returns signature object with the signed message\n5. Display signature to user in a readable format\n6. Add copy-to-clipboard functionality for signature\n\nTRANSACTION COMPONENT:\n1. Import required Solana libraries:\n - Import Transaction, SystemProgram, PublicKey from @solana/web3.js\n2. Create transfer transaction:\n - Use SystemProgram.transfer() to create a SOL transfer\n - Set fromPubkey, toPubkey, and lamports (1 SOL = 1,000,000,000 lamports)\n3. Sign and send transaction:\n - await solana.signAndSendTransaction(transaction)\n - Returns { hash } with transaction signature\n4. Display transaction hash with link to Solana explorer\n5. Add input fields for recipient address and amount in SOL\n6. Validate inputs before sending\n\nREQUIREMENTS:\n- Use TypeScript with proper types\n- Add try-catch error handling for all async operations\n- Show loading states during connection and transactions\n- Display error messages to users with helpful context\n- Add null checks before accessing addresses\n- Style with Tailwind CSS for modern UI\n- Add helpful comments explaining Solana-specific concepts\n- Format addresses with truncation (show first 4 and last 4 characters)\n- Convert lamports to SOL for user display (divide by 1,000,000,000)\n\nThe SDK automatically handles wallet connection UI, authentication flow, and transaction confirmation.\n\nWhat to replace in the prompt\n[YOUR_APP_ID]: Replace with your App ID from Phantom Portal\n[YOUR_REDIRECT_URL]: Replace with your authentication callback URL (must be allowlisted in Phantom Portal)\n\n​React Native SDK prompt\nView React Native SDK promptImplement Phantom React Native SDK integration for Solana mobile apps with the following requirements:\n\nINSTALLATION:\n1. Install SDK: npm install @phantom/react-native-sdk\n2. Install Solana dependency: npm install @solana/web3.js\n3. Install peer dependencies:\n - For Expo: npx expo install expo-secure-store expo-web-browser expo-auth-session expo-router\n - Required polyfill: npm install react-native-get-random-values\n\nPOLYFILL SETUP (CRITICAL):\nAdd this import at the VERY TOP of your app entry point (index.js, App.tsx, or _layout.tsx):\n // MUST be the first import - before any other imports\n import \"react-native-get-random-values\";\n\n import { PhantomProvider } from \"@phantom/react-native-sdk\";\n // ... other imports\n\nAPP CONFIGURATION:\nConfigure app.json with your custom URL scheme:\n {\n \"expo\": {\n \"name\": \"My Solana Wallet App\",\n \"slug\": \"my-solana-wallet-app\",\n \"scheme\": \"[YOUR_SCHEME]\",\n \"plugins\": [\"expo-router\", \"expo-secure-store\", \"expo-web-browser\", \"expo-auth-session\"]\n }\n }\n\nPROVIDER SETUP:\nWrap your app with PhantomProvider in App.tsx or _layout.tsx:\n import { PhantomProvider, AddressType } from \"@phantom/react-native-sdk\";\n\n export default function App() {\n return (\n <PhantomProvider\n config={{\n providerType: \"embedded\",\n appId: \"[YOUR_APP_ID]\",\n scheme: \"[YOUR_SCHEME]\",\n addressTypes: [AddressType.solana],\n authOptions: {\n redirectUrl: \"[YOUR_SCHEME]://phantom-auth-callback\",\n },\n appName: \"My Solana Wallet App\",\n }}\n >\n <YourAppContent />\n </PhantomProvider>\n );\n }\n\nWALLET SCREEN COMPONENT:\nCreate a component using hooks from \"@phantom/react-native-sdk\":\n1. Import: useConnect, useAccounts, useSolana, useDisconnect\n2. Use React Native components: View, Button, Text, Alert, StyleSheet from \"react-native\"\n3. Connect flow:\n - const { connect, isConnecting, error } = useConnect()\n - await connect({ provider: \"google\" }) // or \"apple\"\n - const { addresses, isConnected } = useAccounts()\n4. Display Solana address when connected (truncate for mobile: show first 4 and last 4 chars)\n5. Add disconnect button using useDisconnect()\n6. Show wallet balance if needed\n\nMESSAGE SIGNING:\nImplement message signing for authentication:\n - const { solana } = useSolana()\n - const signature = await solana.signMessage(\"Sign in to MyApp\")\n - signature.signature contains the signature string\n - Show success Alert with truncated signature\n - Use for login or authentication flows\n\nTRANSACTION SCREEN:\nBuild a transfer screen with @solana/web3.js:\n1. Import Transaction, SystemProgram, PublicKey from @solana/web3.js\n2. Create TextInput fields for:\n - Recipient address (validate it's a valid Solana address)\n - Amount in SOL (convert to lamports: amount * 1,000,000,000)\n3. Build transaction:\n - Create transfer with SystemProgram.transfer()\n - Set fromPubkey, toPubkey, lamports\n4. Send transaction:\n - await solana.signAndSendTransaction(transaction)\n - Returns { hash } with transaction signature\n5. Show success Alert with link to Solana Explorer\n6. Handle errors with user-friendly messages\n\nREQUIREMENTS:\n- Use TypeScript with proper types\n- Handle all errors with try-catch and Alert.alert\n- Show loading states during connection and transactions\n- Use StyleSheet for component styling\n- Add pull-to-refresh for balance updates\n- Format SOL amounts properly (show 2-4 decimal places)\n- Truncate addresses for mobile display\n- Add haptic feedback for actions\n- Test thoroughly on both iOS and Android\n- Implement proper null checks for addresses\n- Add helpful comments explaining Solana concepts\n\nThe SDK handles OAuth flow automatically with system browser and deep link redirect back to your app.\n\nWhat to replace in the prompt\n[YOUR_APP_ID]: Replace with your App ID from Phantom Portal\n[YOUR_SCHEME]: Replace with your custom URL scheme (for example, myapp)\n\n​Browser SDK prompt\nView Browser SDK promptImplement Phantom Browser SDK integration for Solana with the following requirements:\n\nINSTALLATION:\n1. Install SDK: npm install @phantom/browser-sdk\n2. Install Solana dependency: npm install @solana/web3.js\n\nBUILD SETUP:\n- Use Vite as build tool: npm create vite@latest my-solana-app -- --template vanilla-ts\n- Configure proper TypeScript settings\n\nSDK INITIALIZATION (phantom.ts):\nCreate a module that initializes and exports the SDK:\n import { BrowserSDK, AddressType } from \"@phantom/browser-sdk\";\n\n export const sdk = new BrowserSDK({\n providerType: \"embedded\",\n addressTypes: [AddressType.solana],\n appId: \"[YOUR_APP_ID]\",\n authOptions: {\n authUrl: \"https://connect.phantom.app/login\",\n redirectUrl: \"[YOUR_REDIRECT_URL]\",\n },\n });\n\nMAIN APPLICATION (main.ts):\n1. Import the SDK instance\n2. Set up DOM elements and event listeners\n3. Implement wallet connection:\n - Call sdk.connect() which returns { addresses }\n - Display connected Solana address in UI\n - Store address in state variable\n4. Implement disconnect:\n - Call sdk.disconnect()\n - Clear address from state\n - Update UI to show disconnected state\n\nMESSAGE SIGNING:\nImplement message signing for authentication:\n const message = \"Sign in to MyApp\";\n const signature = await sdk.solana.signMessage(message);\n console.log(\"Signature:\", signature);\n // Display signature in UI\n // Can be used for server-side verification\n\nTRANSACTIONS:\nBuild SOL transfer functionality:\n import { Transaction, SystemProgram, PublicKey, LAMPORTS_PER_SOL } from \"@solana/web3.js\";\n\n // Get amount in SOL from user input\n const solAmount = parseFloat(amountInput.value);\n const lamports = solAmount * LAMPORTS_PER_SOL;\n\n // Create transaction\n const transaction = new Transaction().add(\n SystemProgram.transfer({\n fromPubkey: new PublicKey(connectedAddress),\n toPubkey: new PublicKey(recipientAddress),\n lamports: lamports,\n })\n );\n\n // Sign and send\n const result = await sdk.solana.signAndSendTransaction(transaction);\n console.log(\"Transaction signature:\", result.hash);\n\n // Show success with link to Solana Explorer\n const explorerUrl = `https://explorer.solana.com/tx/${result.hash}`;\n\nWALLET BALANCE:\nDisplay user's SOL balance:\n // Fetch balance using Solana web3.js Connection\n // Format as SOL (divide lamports by LAMPORTS_PER_SOL)\n // Update on connection and after transactions\n\nHTML STRUCTURE:\nCreate index.html with clean sections:\n- Header with app title and network selector\n- Connect/Disconnect button (style differently based on state)\n- Connected address display (truncated with copy button)\n- Wallet balance display in SOL\n- Message signing section:\n * Text input for message\n * Sign button\n * Signature display area\n- Transaction section:\n * Input for recipient address (validate format)\n * Input for amount in SOL\n * Send button\n * Transaction status display\n- Use Tailwind CSS for modern, responsive styling\n\nREQUIREMENTS:\n- Use TypeScript with strict mode enabled\n- Add try-catch error handling for all SDK calls\n- Display user-friendly error messages in UI\n- Show loading spinners during async operations\n- Add null checks before accessing addresses\n- Update UI reactively based on connection state\n- Format addresses (show first 4 and last 4 characters)\n- Format SOL amounts with proper decimals\n- Add copy-to-clipboard functionality for addresses and signatures\n- Include helpful comments explaining Solana concepts\n- Validate user inputs before transactions\n- Use modern JavaScript (async/await, optional chaining, nullish coalescing)\n\nThe SDK automatically handles authentication UI, wallet selection, and transaction confirmation.\n\nWhat to replace in the prompt\n[YOUR_APP_ID]: Replace with your App ID from Phantom Portal\n[YOUR_REDIRECT_URL]: Replace with your authentication callback URL (must be allowlisted in Phantom Portal)\n\n​Step-by-step guide for using the prompts\n1Get your App IDMake sure you have your App ID from Phantom Portal before using any prompt.2Customize the promptReplace placeholder values such as [YOUR_APP_ID], [YOUR_REDIRECT_URL], and [YOUR_SCHEME] with your actual values.3Paste into CursorOpen Cursor AI, press Cmd+K (or Ctrl+K on Windows), and paste the complete prompt.4Review the generated codeCursor will generate a full implementation. Review the code to ensure it meets your requirements.5Test the integrationRun your application and test wallet connection, message signing, and transaction flows. Phantom Connect manages authentication using social login through Google or Apple.\n​Need more customization?\nThese prompts generate a working integration. For advanced features, refer to the SDK documentation.\nWas this page helpful?","tokens":2998,"squid":"spider-10","role":"Tooling Spider","at":1791339676358,"hash":"50999142b16f915f66175076d709aa951f848f23"}
{"url":"https://jup.ag/rewards/asr-2026-q2","domain":"jup.ag","title":"Jupiter: The Home of Onchain Finance","text":"TimelineCampaign opensApr 1, 12:00 AMEarning closesJun 30, 11:59 PMClaims openJul 8, 02:00 PMHow it worksEligibilityEligible wallets are determined from the campaign rules. No separate claim registration is required.What countsQualifying activity during the campaign period. See Campaign details below for the exact rules.RewardsPaid in Staked JUP, claimable once the claim window opens.Campaign detailsWhat's in ASR Pool?\nFor this ASR Period (Apr - Jun 2026)\n\n50M JUP will be distributed to stakers during this period.\nASR is calculated using a time-weighted average of your stake during this period.\nAn average of 50 JUP or more staked during this quarter is eligible for ASR.\n\nASR Recap & Explainer\n\nASR (Active Staking Rewards) Notes\nWhat is ASR & Why it Matters\nMeow: Juply & ASR\nFAQJupiter's community of cadets, voters, and users is huge and diverse. ASR functions as a bootstrapping mechanism to incentivize Jupiter's community to be involved in decisions, voting, and discussions.\nIt is an innovative reward system that rewards voters based on voting activity and community participation.ASR Pool consists of JUP from excess unclaimed JUP from the 1st Jupuary airdrop, you can refer to this proposal for more information.\nDuring inception of ASR, it was utilizing JUP from JUP's usage of the LFG Launchpad, but has since renewed. In addition, 0.75% LFG Launchpad fee of other launches were distributed as well and for this period, there is no LFG Launchpad fee.ASR is distributed per quarter.\nFor this quarter's ASR, it is calculated based on your daily time-weighted average stake of JUP. An average of 50 JUP or more staked is eligible for ASR.If you have an ongoing unstake, you will need to wait for it to complete or cancel the unstake before claiming your JUP rewards.\nAll JUP will be automatically added to your stake account after claiming. These stake accounts are viewable on vote.jup.ag.","tokens":477,"squid":"spider-02","role":"Liquidity Spider","at":1791339684358,"hash":"2ef70e3db3d8ca4687d70ea0b9e1f02c78c60f9f"}
{"url":"https://docs.phantom.com/phantom-portal/edit-app-info","domain":"docs.phantom.com","title":"Add your app information - Phantom developer documentation","text":"Phantom Portal is not accepting new applications at this time. New sign-ups for Phantom Connect SDK access and new app submissions to the Phantom app directory are paused. Existing Portal apps and App IDs are not affected.\nFill out more information about your app and add graphics to customize how the app appears to users in Phantom. Any changes you make on the Edit App Info page will go through a review process. Once approved by Phantom, they will be published across all platforms.\n\n​Add your app information\n\nIn Phantom Portal, expand your app in the main navigation, then click Edit App Info.\n\nApp Details:\n\nApp icon: Upload an icon as a PNG or JPG image, up to 250×250px and 1MB.\nName: Enter your app’s official name (up to 50 characters).\nDescription: Provide a brief tagline describing what your app does (up to 100 characters). The description field can accommodate longer text, but descriptions over 100 characters may not display well in the app.\nPublic URL: Your app’s public URL within Phantom, must use HTTPS. You will need to verify your domain to use Phantom Connect SDK and for your app to be visible in Phantom’s Explore tab.\nCover image: A PNG or JPG image, recommended 1500×500px, up to 2MB.\n\nCategories:\n\nCategory: Select the category that best represents your app (AI, DeFi, NFT, gaming, and others).\nNetworks: Select all blockchain networks your app supports.\n\nSocial Links: Add links to your website, Discord, Telegram, GitHub, X (Twitter), and YouTube.\n\n​App access control\nYour app’s access mode controls who can connect:\n\nDISABLED: App is banned, no users can connect\nPRIVATE: Invited team members only (max 20) — this is the default mode\nPUBLIC: All users can connect — available after Phantom approval\n\nIn PRIVATE mode, you must invite team members through Phantom Portal. If someone who isn’t invited tries to connect, the connection is rejected.\n​Domain verification\nDomain verification is required to use Phantom Connect SDK and for your app to appear in Phantom’s Explore tab and search results:\n\nIn Phantom Portal, click Verify now.\nAdd a DNS TXT record to your domain with the details on the screen.\nCopy the verification code from Phantom Portal.\nSelect Verify Domain in Phantom Portal.\n\nDNS configuration:\nFieldValueTypeTXTHost@ValueVerification code from Phantom PortalTTL3600\nView the detailed verification guide →\n​Submit for review\nAfter making any changes to your app information, a Submit changes for review button will appear above the cover image section. Click this button to submit your updates for review by the Phantom team.\n​Next steps\nWas this page helpful?","tokens":653,"squid":"spider-10","role":"Tooling Spider","at":1791339718007,"hash":"9b48b85c2d639102eda4fed5429de4e4ef055621"}
{"url":"https://jup.ag/stocks/amzn","domain":"jup.ag","title":"Amazon.Com Inc (AMZN) Tokenized Stock Price on Solana","text":"Underlying price$257.25+2.33% todayStock statsMarket cap$2.71TPrevious close$251.40Open$253.40Day's range$251.08 – $256.6752-week range$196.00 – $287.20Volume34.1MAvg volume34.4MP/E ratio20.04About Amazon.Com IncAmazon is the leading online retailer and marketplace for third party sellers. Retail related revenue represents approximately 74% of total, followed by Amazon Web Services (17%), and advertising services (9%). International segments constitute 22% of Amazon's total revenue, led by Germany, the United Kingdom, and Japan.TickerAMZNAsset classEquityTokenized by2 issuersSectorConsumer DiscretionaryIndustryRetail-Catalog & Mail-Order HousesEmployees1,576,000Websiteamazon.comAmazon.Com Inc FAQAMZN is Amazon.Com Inc stock, issued on Solana as a token that tracks the listed share. Each issuer mints its own version, so Amazon.Com Inc trades here as 2 tokens rather than one.Token prices are designed to track Amazon.Com Inc's listed shares, but they can differ because of issuer terms, liquidity, market hours, and trading activity.xStocks and Ondo issue the tokenized Amazon.Com Inc markets shown on Jupiter. Each issuer controls its own token and settlement terms.Trading availability depends on the issuer token and its market. Open an issuer's token page to check current liquidity and trading status.Use the Market swap on this page. Select the AMZN token in the swap to choose an issuer. Connect your wallet, choose the token you want to pay with, and enter an amount. Review the swap details before you submit, then confirm in your wallet when prompted. A swap requires an available trading route. Issuer terms and restrictions apply.Dividend treatment depends on the token issuer. A dividend paid on Amazon.Com Inc's listed shares does not guarantee a cash payment to token holders. Review each issuer's terms for how dividends and other corporate actions are handled.Read Ondo's corporate action policyRead xStocks' dividend and stock split policy","tokens":492,"squid":"spider-02","role":"Liquidity Spider","at":1791339731221,"hash":"e621586d4d16a98623a4d63786f4a2bd42e85c52"}
{"url":"https://jup.ag/lend/earn","domain":"jup.ag","title":"Earn Yield on Crypto: Lend Tokens on Solana | Jupiter Lend","text":"Jupiter LendThe most advanced money market on Solana Earn Interest on Your CryptoPassively get yield using Jupiter Lend's Earning Vaults.$614MVaultDepositedEarningsTVLJupUSD----49.8M JupUSD$49.8MUSDC----511M USDC$511MSOL----201K SOL$23.7MUSDT----17.9M USDT$17.9MEURC----4.77M EURC$5,363,342.80USDS----2.98M USDS$2,984,349.96USDG----2.76M USDG$2,764,714.57FAQsJupiter Lend is Jupiter's decentralized finance (DeFi) platform for lending and borrowing crypto. It allows you to use your assets in two main ways:Earn: You can deposit your crypto to lend it out to others and earn passive interest.Borrow: You can use the assets you've deposited as collateral to take out a loan.Jupiter Lend is designed to automatically find the best interest rates for you, whether you are earning or borrowing.Earning and borrowing are two sides of the same system. The \"Earn\" section is for users who want to supply assets to earn interest.The \"Borrow\" section is for users who want to use their supplied assets as collateral to take out a loan.When you supply an asset for lending, you will automatically earn the best possible rate. Supply once and get the best yield, no extra steps needed.Depositing: There are no limits on how much you can deposit.Withdrawing: To ensure Jupiter Lend remains stable and healthy for everyone, there are dynamic limits on how much can be withdrawn at any single moment. These limits grow constantly, allowing for smooth and predictable withdrawals while protecting the system from sudden, large outflows.Like all DeFi platforms, lending and borrowing on-chain has risks. The primary risks are:Smart Contract Risk: The potential for a bug or vulnerability in the code that could be exploited.Market Risk: The value of your deposited or borrowed assets could change dramatically due to market volatility. This is especially important for borrowers, as a drop in your collateral's value could lead to liquidation.Please use this product carefully and never deposit more than you are willing to lose.Check JupLend Guides","tokens":508,"squid":"spider-02","role":"Liquidity Spider","at":1791339741113,"hash":"72c8989261f20a4092ada31ce8a1aa69c111f57c"}
{"url":"https://www.paradigm.xyz/writing/symbiotic","domain":"paradigm.xyz","title":"From Staking to Restaking","text":"From Staking to Restaking Decentralized networks need coordination mechanisms to incentivize and hold their node operators accountable. This began with Proof of Work and later evolved with Proof of Stake, a significant development that allowed networks to source validator security through economic collateral. The next frontier of this is shared security, which expands the services node operators in PoS can provide while making use of the same underlying economic collateral.Symbiotic is a generalized, permissionless protocol providing shared security through restaking. We are investing in Symbiotic alongside Cyber.Fund, a collaborator of ours on Lido and other protocols.We believe Symbiotic’s flexible and permissionless approach will be a great fit for many of the most useful consumers of shared security and, over time, could be a default option for bootstrapping a decentralized network.BackgroundLido, Ethereum’s largest liquid staking token, was founded on the insight that separating staking capital from validator infrastructure (labor) is possible without modifying Ethereum’s consensus, using a smart contract layer for routing users’ stake to operators in a decentralized way. This separation, to become “delegated,” is a natural and inherent tendency of Proof of Stake systems. Lido enabled Proof of Stake to scale on Ethereum without compromising decentralization by matching staked Ether with the highest-quality infrastructure operators.Paradigm began collaborating with Lido protocol contributors in 2021. Since then, Lido has grown from ~$800M to over $36B in staked ETH deposits and fostered the most robust ecosystem of node operators: reputable, geographically distributed, diverse, and aligned.Paradigm has also long supported the Cosmos ecosystem, leading Tendermint Inc.’s original Series A and later investing in Osmosis and dYdX. Through Cosmos, we observed the challenges of recruiting validators and capital from scratch every time developers wanted to launch a new chain, which significantly limited the pace of innovation.A natural “phase two” of Ethereum staking is to repurpose stake and validator infrastructure and expertise beyond L1 consensus to secure many protocols at once. This makes it easier to stand up new protocols. Cosmos pioneered this idea as “shared security,” and EigenLayer’s “restaking” recognized that an ETH-centric approach could successfully bootstrap this validator ecosystem. This primitive is novel and powerful, but considering the risks of overloading Ethereum’s consensus, it needs to be designed thoughtfully to enable useful applications safely.As we considered the market, we realized Konstantin was also interested. Through him, we met Misha and Algys, the founders of Statemind, a top auditor with a close working relationship with Lido (i.e., on their V2 audit), Curve, InstaDapp, and others. We were aligned with how they each viewed the market and jumped at the opportunity to partner.Introducing SymbioticSymbiotic is a new shared security system. It is designed as a thin coordination layer that is maximally flexible, permissionless, and reliable. Symbiotic allows network developers to have complete control over specifying their (re)staking implementation and operator set. Zooming out, the long-term goal of the protocol is to provide primitives that help networks navigate the roadmap to decentralization while prioritizing safety and capital efficiency.FlexibleProtocols built on Symbiotic can control their collateral assets, rewards, and slashing criteria. Symbiotic will initially focus on staked ETH as the largest pool of stake capital. However, the protocol is general-purpose and can accept any ERC-20 asset as collateral. In time, we expect Symbiotic will service many assets and related operator infrastructure groups.Symbiotic network developers will also have full control of their operator selection mechanics. Over time, it will be possible to maximize the number of participants, their geographic distribution, and their overlap with other protocols, reputation, and other selection criteria.PermissionlessThe core Symbiotic contracts are immutable, which removes external governance risks. Symbiotic will never have a central multisig, slashing committee, or other permissioning mechanisms for shared security services. Services built on Symbiotic will be able to support many different slashing resolution mechanisms, which we believe is critical for innovation.ReliableBuilding infrastructure operator networks is challenging, as we have learned in working with Lido. Symbiotic will ensure that restaking can scale by onboarding reputable and geographically distributed infrastructure partners and by supporting smaller operators.What should be built on Symbiotic?At Paradigm, we view restaking protocols as delegated staking systems at their core. Stakers are incentivized to vote their capital behind operators they believe will be honest validators. In some sense, this is how Ethereum staking (via stETH and other LSTs) already works today.Near term, we believe that the clearest and safest use case of shared delegated proof of stake security is for bootstrapping new consensus instances:Electing the operators of new L1s (e.g. Cosmos appchains, sidechains, etc.)Decentralized sequencingDistributed auctions (e.g. leaderless auctions)MPC and Threshold Decryption networksIn the long term, we are also interested in L1 block production use cases, such as new types of MEV auctions, preconfirmations, and based sequencing. However, we think block production use cases may take longer to blossom: they often benefit from adoption by a greater fraction of L1 proposers and may pose more direct security risks to Ethereum L1.To help achieve that vision, we also created Reth Execution Extensions (ExEx). ExExes allow fast data extraction and processing from a node and enable networks/services to peer with other ExExes to agree on the state that should eventually be injected back into Ethereum. We want to make ExExes the best tool for building shared security services using Symbiotic.Of course, Symbiotic is a general system, and developers can build any protocol they want on top of it without asking for permission or using our codebases. These are just our own intuitions about the types of use cases most likely to succeed.Please reach out if you are interested in collaborating with us and Symbiotic on any of these applications, or others that we have yet to imagine!","tokens":1620,"squid":"spider-04","role":"Research Spider","at":1791339747658,"hash":"a8fbec0c34ecf218bbbbab1abd1d61be9b6a3a62"}
{"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":"spider-05","role":"Spec Spider","at":1791339764077,"hash":"2ae347042bcaca74cdfe0fae1a35a8cc08412b96"}
{"url":"https://akash.network/ecosystem/deployed-on-akash/smart%20contracts","domain":"akash.network","title":"Smart Contracts | Deployed On Akash","text":"Smart Contracts Blockless Execute Off-Chain, Decentralized Everywhere. According to this tweet from their Head of Engineering, Akash is enabling Blockless to be decentralized from day one while keeping its infrastructure costs at a minimum.Execute Off-Chain, Decentralized Everywhere. According to this tweet from their Head of Engineering, Akash is enabling Blockless to be decentralized from day one while keeping its infrastructure costs at a minimum.Execute Off-Chain, Decentralized Everywhere. According to this tweet from their Head of Engineering, Akash is enabling Blockless to be decentralized from day one while keeping its infrastructure costs at a minimum. View project Juno Network Application Layer for the Inter-chain era. Juno network's homepage is hosted on Akash, confirmed by their official tweet from their official Twitter account.Application Layer for the Inter-chain era. Juno network's homepage is hosted on Akash, confirmed by their official tweet from their official Twitter account.Application Layer for the Inter-chain era. Juno network's homepage is hosted on Akash, confirmed by their official tweet from their official Twitter account. View project Thirdweb We make it easy to build web3 apps Thirdweb's head of Dev Rel indicated he's building with Thirdweb and deploying on Akash according to this Tweet. Deeper integration is coming soon.We make it easy to build web3 apps Thirdweb's head of Dev Rel indicated he's building with Thirdweb and deploying on Akash according to this Tweet. Deeper integration is coming soon.We make it easy to build web3 apps Thirdweb's head of Dev Rel indicated he's building with Thirdweb and deploying on Akash according to this Tweet. Deeper integration is coming soon. View project","tokens":437,"squid":"spider-03","role":"Compute Spider","at":1791339773589,"hash":"3068e6ce2f405fd8e635369d876795b6df6f9c1f"}
{"url":"https://eips.ethereum.org/EIPS/eip-4","domain":"eips.ethereum.org","title":"EIP-4: EIP Classification","text":"🎉 Final\n\n Meta\n\n EIP-4: EIP Classification\n\n Authors\n Joseph Chow (@ethers)\n\n Created\n 2015-11-17\n\n Abstract\n\nThis document describes a classification scheme for EIPs, adapted from BIP 123.\n\nEIPs are classified by system layers with lower numbered layers involving more intricate interoperability requirements.\n\nThe specification defines the layers and sets forth specific criteria for deciding to which layer a particular standards EIP belongs.\n\n Motivation\n\nEthereum is a system involving a number of different standards. Some standards are absolute requirements for interoperability while others can be considered optional, giving implementers a choice of whether to support them.\n\nIn order to have a EIP process which more closely reflects the interoperability requirements, it is necessary to categorize EIPs accordingly. Lower layers present considerably greater challenges in getting standards accepted and deployed.\n\n Specification\n\nStandards EIPs are placed in one of four layers:\n\n Consensus\n Networking\n API/RPC\n Applications\n\n 1. Consensus Layer\n\nThe consensus layer defines cryptographic commitment structures. Its purpose is ensuring that anyone can locally evaluate whether a particular state and history is valid, providing settlement guarantees, and assuring eventual convergence.\n\nThe consensus layer is not concerned with how messages are propagated on a network.\n\nDisagreements over the consensus layer can result in network partitioning, or forks, where different nodes might end up accepting different incompatible histories. We further subdivide consensus layer changes into soft forks and hard forks.\n\n Soft Forks\n\nIn a soft fork, some structures that were valid under the old rules are no longer valid under the new rules. Structures that were invalid under the old rules continue to be invalid under the new rules.\n\n Hard Forks\n\nIn a hard fork, structures that were invalid under the old rules become valid under the new rules.\n\n 2. Networking Layer\n\nThe networking layer specifies the Ethereum wire protocol (eth) and the Light Ethereum Subprotocol (les). RLPx is excluded and tracked in the devp2p repository.\n\nOnly a subset of subprotocols are required for basic node interoperability. Nodes can support further optional extensions.\n\nIt is always possible to add new subprotocols without breaking compatibility with existing protocols, then gradually deprecate older protocols. In this manner, the entire network can be upgraded without serious risks of service disruption.\n\n 3. API/RPC Layer\n\nThe API/RPC layer specifies higher level calls accessible to applications. Support for these EIPs is not required for basic network interoperability but might be expected by some client applications.\n\nThere’s room at this layer to allow for competing standards without breaking basic network interoperability.\n\n 4. Applications Layer\n\nThe applications layer specifies high level structures, abstractions, and conventions that allow different applications to support similar features and share data.\n\n Citation\n Please cite this document as:\n\n Joseph Chow (@ethers), \"EIP-4: EIP Classification,\" Ethereum Improvement Proposals, no. 4, November 2015. Available: https://eips.ethereum.org/EIPS/eip-4.","tokens":805,"squid":"spider-05","role":"Spec Spider","at":1791339773828,"hash":"df1eb6f52aa940f351b5d9888f557a787d1c10da"}
{"url":"https://across.to/","domain":"across.to","title":"Across Protocol - Transfer Assets Between Layer 2s and Mainnet","text":"Bridge & swap across chainsFast. Cheap. Secure.FromToTHE CROSSCHAIN BRIDGEMove money across chains. Fast, cheap, secure.Across is the bridge that just works. Bridge and swap tokens between any supported chain in seconds. Enjoy low fees, no custodial risk, and the reliability to handle any transfer size. Over $40B moved. No user funds lost.Billions bridged. Trusted by the best.Numbers don't lie. Across powers crosschain transfers for the biggest names in crypto and millions of users around the world.volume$40B+Dollars moved across chains by users and apps that rely on Across to deliver, every single time.users5MPeople trust Across with their money. From first-time bridgers to institutions moving millions.avg speed1.2SAverage time from confirmation to funds in your wallet. Most transfers land in under two seconds.volume$40B+Dollars moved across chains by users and apps that rely on Across to deliver, every single time.users5MPeople trust Across with their money. From first-time bridgers to institutions moving millions.avg speed1.2SAverage time from confirmation to funds in your wallet. Most transfers land in under two seconds.UniswapUniswap integrated Across to bring native crosschain transfers directly into its app.In-app bridgingNative supportEasy integrationEmbedding token bridging directly into the Uniswap app\"Users shouldn't have to switch between tabs to bridge tokens. We wanted to add crosschain bridging without adding complexity. Across gave us a single integration that covered a vast majority of chains we needed, with fast settlement and low fees out of the box.\"Medha KothariProduct @ UniswapRead Docsconst params = new URLSearchParams({ tradeType: \"exactInput\", amount: \"10000000\", // 10 USDC inputToken: \"0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913\", outputToken: \"0x078D782b760474a361dDA0AF3839290b0EF57AD6\", originChainId: \"8453\", // Base destinationChainId: \"130\", // Unichain depositor: wallet.account.address,});const quote = await fetch( `https://app.across.to/api/swap/approval?${params}`, { headers: { Authorization: `Bearer ${KEY}` } },).then((r) => r.json());for (const tx of quote.approvalTxns ?? []) await wallet.sendTransaction(tx);await wallet.sendTransaction(quote.swapTx);Need any help?Need any help?const params = new URLSearchParams({ tradeType: \"exactInput\", amount: \"10000000\", // 10 USDC inputToken: \"0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913\", outputToken: \"0x078D782b760474a361dDA0AF3839290b0EF57AD6\", originChainId: \"8453\", // Base destinationChainId: \"130\", // Unichain depositor: wallet.account.address,});const quote = await fetch( `https://app.across.to/api/swap/approval?${params}`, { headers: { Authorization: `Bearer ${KEY}` } },).then((r) => r.json());for (const tx of quote.approvalTxns ?? []) await wallet.sendTransaction(tx);await wallet.sendTransaction(quote.swapTx);Need any help?Need any help?UniswapUniswap integrated Across to bring native crosschain transfers directly into its app.In-app bridgingNative supportEasy integrationEmbedding token bridging directly into the Uniswap app\"Users shouldn't have to switch between tabs to bridge tokens. We wanted to add crosschain bridging without adding complexity. Across gave us a single integration that covered a vast majority of chains we needed, with fast settlement and low fees out of the box.\"Medha KothariProduct @ UniswapRead Docs#PoweredByAcrossWhy Across?Moving funds between chains should be easy. Across delivers fast settlement, low fees, deep liquidity, proven security, and a simple experience for users and builders alike.READ DOCSBattle-tested. No user funds lost.Billions bridged with no user funds lost. Every transfer is verified onchain with no multisigs and no custodial risk. Trusted by the leading apps in DeFi.LEARN MOREFast by defaultAcross uses an intent-based design to deliver near-instant transfers. By the time other bridges quote, your transaction is already done.LEARN MORELower fees, every timeKeep more of your money. Across is built to minimize costs on every transfer. No aggregator markup, no hidden fees. What you see is what you pay.LEARN MOREDecentralized & permissionlessNo 1/1 configurations. No single points of failure. Across runs on a permissionless relayer network where anyone can compete to fill transfers.LEARN MOREOne integration, many chainsAdd crosschain bridging to your app with a single API. Clean docs, responsive support, and no aggregator dependencies. Your users will love you for it.LEARN MORETHE ACROSS BLOGResources for a crosschain worldJul 14, 2026Robinhood Chain's First Week: CashCat, $1B in DEX Volume, and How to Get There 4 MIN READ#ResearchAug 10, 2026Across Integrates Paxos Labs' Transit for $50M Transfers 3 MIN READ#PartnersJul 27, 2026Canonical Bridges vs Third-Party Bridges: What's the Difference? 5 MIN READ#BasicsJul 15, 2026Bridge ETH to Base in Under 2 Seconds 4 MIN READ#GuidesJul 14, 2026Robinhood Chain's First Week: CashCat, $1B in DEX Volume, and How to Get ThereCashCat, a flipped Hyperliquid, and $1 billion in week-one DEX volume: what actually happened on Robinhood Chain's first week, and how to bridge in while it's moving. 4 MIN READ#ResearchAug 10, 2026Across Integrates Paxos Labs' Transit for $50M Transfers 3 MIN READ#PartnersJul 27, 2026Canonical Bridges vs Third-Party Bridges: What's the Difference? 5 MIN READ#BasicsJul 15, 2026Bridge ETH to Base in Under 2 Seconds 4 MIN READ#GuidesREAD MORE ARTICLESThe Across EcosystemSupported ChainsBridge tokens across Ethereum, Hyperliquid, Base, Solana, BSC, and a growing list of supported networks.EthereumArbitrumRobinhoodArcOptimismBasePolygonSolanazkSyncLineaModeLensLighterLiskZoraWorld ChainInkSoneiumUnichainBNB Smart ChainHyperEVMPlasmaHyperCoreMonadMegaETHTempoTronAvalanche","tokens":1438,"squid":"spider-09","role":"Bridge Spider","at":1791339773919,"hash":"9321edcaa52b3f91acf8981c59313556d4dc1a5c"}
{"url":"https://eips.ethereum.org/EIPS/eip-6","domain":"eips.ethereum.org","title":"EIP-6: Renaming SUICIDE opcode","text":"🎉 Final\n\n Standards Track: Interface\n\n EIP-6: Renaming SUICIDE opcode\n\n Authors\n Hudson Jameson <hudson@hudsonjameson.com>\n\n Created\n 2015-11-22\n\n Abstract\n\nThe solution proposed in this EIP is to change the name of the SUICIDE opcode in Ethereum programming languages with SELFDESTRUCT.\n\n Motivation\n\nMental health is a very real issue for many people and small notions can make a difference. Those dealing with loss or depression would benefit from not seeing the word suicide in our programming languages. By some estimates, 350 million people worldwide suffer from depression. The semantics of Ethereum’s programming languages need to be reviewed often if we wish to grow our ecosystem to all types of developers.\n\nAn Ethereum security audit commissioned by DEVolution, GmbH and performed by Least Authority recommended the following:\n\n Replace the instruction name “suicide” with a less connotative word like “self-destruct”, “destroy”, “terminate”, or “close”, especially since that is a term describing the natural conclusion of a contract.\n\nThe primary reason for us to change the term suicide is to show that people matter more than code and Ethereum is a mature enough of a project to recognize the need for a change. Suicide is a heavy subject and we should make every effort possible to not affect those in our development community who suffer from depression or who have recently lost someone to suicide. Ethereum is a young platform and it will cause less headaches if we implement this change early on in its life.\n\n Implementation\n\nSELFDESTRUCT is added as an alias of SUICIDE opcode (rather than replacing it).\nhttps://github.com/ethereum/solidity/commit/a8736b7b271dac117f15164cf4d2dfabcdd2c6fd\nhttps://github.com/ethereum/serpent/commit/1106c3bdc8f1bd9ded58a452681788ff2e03ee7c\n\n Citation\n Please cite this document as:\n\n Hudson Jameson <hudson@hudsonjameson.com>, \"EIP-6: Renaming SUICIDE opcode,\" Ethereum Improvement Proposals, no. 6, November 2015. Available: https://eips.ethereum.org/EIPS/eip-6.","tokens":505,"squid":"spider-05","role":"Spec Spider","at":1791339783625,"hash":"6a008675db99bb5c6b3390f60508850b47cfdd75"}
{"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":"spider-05","role":"Spec Spider","at":1791339795419,"hash":"4020f2cdcfc8d77c3099e44ae85c40cf192d5563"}
{"url":"https://akash.network/ecosystem/deployed-on-akash/defi","domain":"akash.network","title":"DeFi | Deployed On Akash","text":"DeFi Chandra Station The leading Omni-Chain Dex on Cosmos. Swap, stake, and bridge between Ethereum & Cosmos with faster transactions & lower fees. Sifchain hosts their DEX's Webapp on Akash.The leading Omni-Chain Dex on Cosmos. Swap, stake, and bridge between Ethereum & Cosmos with faster transactions & lower fees. Sifchain hosts their DEX's Webapp on Akash.The leading Omni-Chain Dex on Cosmos. Swap, stake, and bridge between Ethereum & Cosmos with faster transactions & lower fees. Sifchain hosts their DEX's Webapp on Akash. View project Osmosis DEX Interchain Liquidity Lab Osmosis team runs API servers on AkashInterchain Liquidity Lab Osmosis team runs API servers on AkashInterchain Liquidity Lab Osmosis team runs API servers on AkashInterchain Liquidity Lab Osmosis team runs API servers on Akash View project","tokens":206,"squid":"spider-03","role":"Compute Spider","at":1791339795488,"hash":"bf5c64d6ea22e8dacc11cdb162a5bcde82f5b621"}
{"url":"https://docs.across.to/introduction/bug-bounty","domain":"docs.across.to","title":"Bug Bounty | Across Docs","text":"Bug BountyReport vulnerabilities and earn rewards through the Across Protocol bug bounty program.Security of the platform is our highest priority. All smart contracts and off-chain code (i.e. most of the code within the across-protocol repository) are within scope and are publicly verifiable. Security researchers are eligible for a bug bounty for reporting undiscovered vulnerabilities.\nBounty Program\nWe encourage the community to audit our open source code; we also encourage the responsible disclosure of any issues. The bug bounty program is intended to recognize the value of working with the community of independent security researchers and sets out our definition of good faith in the context of finding and reporting vulnerabilities, as well as what you can expect from us in return.\nAcross offers substantial rewards for discoveries that can prevent the loss of assets, the freezing of assets, or harm to users.\nTo be eligible for a bounty, a bug must have not been previously known by the Across team or publicly disclosed by anyone. All Across smart contracts and interactions (including bots and front end code) are in scope.\nThe amount of compensation will vary depending on bug severity. Reward amounts typically correspond to severity in the following manner. The reward currency can be discussed on a case by case basis.\nSeverityRewardLow$250Medium$1,000High$10,000Criticalup to $1,000,000\nSeverity is calculated according to the OWASP risk rating model based on Impact and Likelihood.\nSubmissions\nPlease email your submissions to bugs@across.to.\nThe submission must include clear and concise steps to reproduce the discovered vulnerability. The following layout of the bug bounty report is encouraged:\n\nDescription: Describe at a high level the bug with links to problematic code\nAttack: Detailed instructions for exploiting the bug\nMitigation: How to resolve the bug\nSuggested risk rating: The recommended severity of this bug\n\nTerms & Conditions\nThe same terms and conditions from the UMA bug bounty program apply here.The Bridge AcrossA quick overview of what is happening with $ACX, and where to follow updates.AuditsSecurity audits of the Across Protocol and UMA smart contracts.","tokens":551,"squid":"spider-09","role":"Bridge Spider","at":1791339795524,"hash":"5d219daf307ddb020c80d0debc8c72272670380b"}
{"url":"https://docs.across.to/introduction/refunds","domain":"docs.across.to","title":"Refunds | Across Docs","text":"RefundsHow refunds work when a crosschain transfer expires without being filled.Refunds occur when no relayer fills a deposit before its fillDeadline expires. This is rare on mainnet — the competitive relayer network fills most deposits in ~2 seconds — but it's important to handle in production integrations.\nYou can check the status of your bridge transaction using our Status Tracker tool here:\nDeposit Status TrackerTrack the lifecycle of any Across deposit. Data updates every ~10 seconds.\n\nWhen Refunds Happen\nA deposit becomes eligible for a refund when:\n\nThe fillDeadline passes without any relayer filling the intent\nNo partial fills were executed\n\nCommon causes include extremely large transfers, unusual token pairs, or temporary relayer downtime.\nRefund Flow\nDeposit ExpiresThe fillDeadline passes and the deposit status changes to expired in the /deposit/status API. The user's funds are still escrowed in the origin SpokePool.Bundle ProcessingThe Across Dataworker includes the expired deposit in the next settlement bundle. Bundles are proposed to the HubPool every ~1.5 hours and must pass a challenge period via UMA's Optimistic Oracle.SettlementAfter the challenge period, the bundle is finalized and the refund root is transmitted to the appropriate chain via canonical bridges.Refund ExecutionThe refund is executed on-chain, returning the escrowed funds to the refundAddress. The deposit status changes to refunded in the API.\nRefunds are not instant. After a deposit expires, the refund goes through the bundle settlement process. With ~1.5-hour bundle intervals plus the challenge period and canonical bridge delays, refunds can take several hours to arrive. Do not tell users to expect immediate refunds.\nRefund Parameters\nConfigure refund behavior when calling the Swap API.\nParameterTypeDefaultDescriptionrefundAddressstringdepositorAddress that receives the refundrefundOnOriginbooleantrueIf true, refund on origin chain. If false, refund on destination chain\nswap-with-refund-config.tsconst params = new URLSearchParams({\n tradeType: \"minOutput\",\n originChainId: \"42161\",\n destinationChainId: \"8453\",\n inputToken: \"0xaf88d065e77c8cC2239327C5EDb3A432268e5831\",\n outputToken: \"0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913\",\n amount: \"1000000000\",\n depositor: \"0xYourWalletAddress\",\n // Refund configuration\n refundAddress: \"0xYourWalletAddress\", // Where to send the refund\n refundOnOrigin: \"true\", // Refund on Arbitrum (origin)\n});\n\nconst response = await fetch(\n `https://app.across.to/api/swap/approval?${params}`\n);\nChecking Refund Status\nUse the /deposit/status endpoint to monitor whether an expired deposit has been refunded.\ncheck-refund.tsimport { createPublicClient, http } from \"viem\";\nimport { arbitrum } from \"viem/chains\";\n\nconst BASE_URL = \"https://app.across.to/api\";\n\nasync function checkRefundStatus(originChainId: number, depositId: number) {\n const params = new URLSearchParams({\n originChainId: originChainId.toString(),\n depositId: depositId.toString(),\n });\n\n const res = await fetch(`${BASE_URL}/deposit/status?${params}`);\n const data = await res.json();\n\n switch (data.status) {\n case \"pending\":\n console.log(\"Deposit still pending — waiting for fill\");\n break;\n case \"filled\":\n console.log(\"Deposit filled successfully — no refund needed\");\n break;\n case \"expired\":\n console.log(\"Deposit expired — refund is being processed\");\n console.log(\"Refund will arrive after bundle settlement (~hours)\");\n break;\n case \"refunded\":\n console.log(\"Refund complete — funds returned to refund address\");\n break;\n }\n\n return data.status;\n}\n\n// Poll until refunded\nasync function waitForRefund(originChainId: number, depositId: number) {\n const intervalMs = 60_000; // Check every minute for refunds\n const maxAttempts = 360; // Up to 6 hours\n\n for (let i = 0; i < maxAttempts; i++) {\n const status = await checkRefundStatus(originChainId, depositId);\n\n if (status === \"refunded\") {\n return \"refunded\";\n }\n\n if (status === \"filled\") {\n return \"filled\"; // Was filled after all — no refund needed\n }\n\n await new Promise((resolve) => setTimeout(resolve, intervalMs));\n }\n\n throw new Error(\"Refund polling timed out\");\n}\nFor refund polling, use a 60-second interval instead of the 10-second interval used for fill tracking. Refunds take hours, not seconds, so frequent polling is unnecessary.Tracking DepositsMonitor crosschain transfer status using the deposit tracking API.Security Model and VerificationHow Across secures crosschain transfers through optimistic verification, bonds, and UMA's oracle.","tokens":1134,"squid":"spider-09","role":"Bridge Spider","at":1791339818822,"hash":"d06132d244a0dfc6adbce03e7ac3dd21c8130cd2"}
{"url":"https://akash.network/ecosystem/deployed-on-akash/dao","domain":"akash.network","title":"DAO | Deployed On Akash","text":"DAO AtlasDAO A DAO NFT community with a focus on philanthropy. A DAO NFT community with a focus on philanthropy. A DAO NFT community with a focus on philanthropy. View project NetaDAO NetaDAO is the Community Accelerator for $NETA NetaDAO confirmed they're hosting their homepage on Akash according to this tweet from their official accountNetaDAO is the Community Accelerator for $NETA NetaDAO confirmed they're hosting their homepage on Akash according to this tweet from their official accountNetaDAO is the Community Accelerator for $NETA NetaDAO confirmed they're hosting their homepage on Akash according to this tweet from their official account","tokens":163,"squid":"spider-03","role":"Compute Spider","at":1791339818871,"hash":"6e2bfb0a05cc9373cc8277d037b393d13161ec92"}
{"url":"https://eips.ethereum.org/EIPS/eip-8","domain":"eips.ethereum.org","title":"EIP-8: devp2p Forward Compatibility Requirements for Homestead","text":"🎉 Final\n\n Standards Track: Networking\n\n EIP-8: devp2p Forward Compatibility Requirements for Homestead\n\n Authors\n Felix Lange <felix@ethdev.com>\n\n Created\n 2015-12-18\n\n Abstract\n\nThis EIP introduces new forward-compatibility requirements for implementations of the\ndevp2p Wire Protocol, the RLPx Discovery Protocol and the RLPx TCP Transport Protocol.\nClients which implement EIP-8 behave according to Postel’s Law:\n\n Be conservative in what you do, be liberal in what you accept from others.\n\n Specification\n\nImplementations of the devp2p Wire Protocol should ignore the version number of hello\npackets. When sending the hello packet, the version element should be set to the highest\ndevp2p version supported. Implementations should also ignore any additional list elements\nat the end of the hello packet.\n\nSimilarly, implementations of the RLPx Discovery Protocol should not validate the\nversion number of the ping packet, ignore any additional list elements in any packet, and\nignore any data after the first RLP value in any packet. Discovery packets with unknown\npacket type should be discarded silently. The maximum size of any discovery packet is\nstill 1280 bytes.\n\nFinally, implementations of the RLPx TCP Transport protocol should accept a new\nencoding for the encrypted key establishment handshake packets. If an EIP-8 style RLPx\nauth-packet is received, the corresponding ack-packet should be sent using the rules\nbelow.\n\nDecoding the RLP data in auth-body and ack-body should ignore mismatches of auth-vsn\nand ack-vsn, any additional list elements and any trailing data after the list. During\nthe transitioning period (i.e. until the old format has been retired), implementations\nshould pad auth-body with at least 100 bytes of junk data. Adding a random amount in\nrange [100, 300] is recommended to vary the size of the packet.\n\nauth-vsn = 4\nauth-size = size of enc-auth-body, encoded as a big-endian 16-bit integer\nauth-body = rlp.list(sig, initiator-pubk, initiator-nonce, auth-vsn)\nenc-auth-body = ecies.encrypt(recipient-pubk, auth-body, auth-size)\nauth-packet = auth-size || enc-auth-body\n\nack-vsn = 4\nack-size = size of enc-ack-body, encoded as a big-endian 16-bit integer\nack-body = rlp.list(recipient-ephemeral-pubk, recipient-nonce, ack-vsn)\nenc-ack-body = ecies.encrypt(initiator-pubk, ack-body, ack-size)\nack-packet = ack-size || enc-ack-body\n\nwhere\n\nX || Y\n denotes concatenation of X and Y.\nX[:N]\n denotes an N-byte prefix of X.\nrlp.list(X, Y, Z, ...)\n denotes recursive encoding of [X, Y, Z, ...] as an RLP list.\nsha3(MESSAGE)\n is the Keccak256 hash function as used by Ethereum.\necies.encrypt(PUBKEY, MESSAGE, AUTHDATA)\n is the asymmetric authenticated encryption function as used by RLPx.\n AUTHDATA is authenticated data which is not part of the resulting ciphertext,\n but written to HMAC-256 before generating the message tag.\n\n Motivation\n\nChanges to the devp2p protocols are hard to deploy because clients running an older\nversion will refuse communication if the version number or structure of the hello\n(discovery ping, RLPx handshake) packet does not match local expectations.\n\nIntroducing forward-compatibility requirements as part of the Homestead consensus upgrade\nwill ensure that all client software in use on the Ethereum network can cope with future\nnetwork protocol upgrades (as long as backwards-compatibility is maintained).\n\n Rationale\n\nThe proposed changes address forward compatibility by applying Postel’s Law (also known as\nthe Robustness Principle) throughout the protocol stack. The merit and applicability of\nthis approach has been studied repeatedly since its original application in RFC 761. For a\nrecent perspective, see\n“The Robustness Principle Reconsidered” (Eric Allman, 2011).\n\n Changes to the devp2p Wire Protocol\n\nAll clients currently contain statements such as the following:\n\n# pydevp2p/p2p_protocol.py\nif data['version'] != proto.version:\n log.debug('incompatible network protocols', peer=proto.peer,\n expected=proto.version, received=data['version'])\n return proto.send_disconnect(reason=reasons.incompatible_p2p_version)\n\nThese checks make it impossible to change the version or structure of the hello packet.\nDropping them enables switching to a newer protocol version: Clients implementing a newer\nversion simply send a packet with higher version and possibly additional list elements.\n\n If such a packet is received by a node with lower version, it will blindly assume that\nthe remote end is backwards-compatible and respond with the old handshake.\n If the packet is received by a node with equal version, new features of the protocol can\nbe used.\n If the packet is received by a node with higher version, it can enable\nbackwards-compatibility logic or drop the connection.\n\n Changes to the RLPx Discovery Protocol\n\nThe relaxation of discovery packet decoding rules largely codifies current practice. Most\nexisting implementations do not care about the number of list elements (an exception being\ngo-ethereum) and do not reject nodes with mismatching version. This behaviour is not\nguaranteed by the spec, though.\n\nIf adopted, the change makes it possible to deploy protocol changes in a similar manner to\nthe devp2p hello change: simply bump the version and send additional information. Older\nclients will ignore the additional elements and can continue to operate even when the\nmajority of the network has moved on to a newer protocol.\n\n Changes to the RLPx TCP Handshake\n\nDiscussions of the RLPx v5 changes (chunked packets, change to key derivation) have\nfaltered in part because the v4 handshake encoding provides only one in-band way to add a\nversion number: shortening the random portion of the nonce. Even if the RLPx v5 handshake\nproposal were accepted, future upgrades are hard because the handshake packet is a fixed\nsize ECIES ciphertext with known layout.\n\nI propose the following changes to the handshake packets:\n\n Adding the length of the ciphertext as a plaintext header.\n Encoding the body of the handshake as RLP.\n Adding a version number to both packets in place of the token flag (unused).\n Removing the hash of the ephemeral public key (it is redundant).\n\nThese changes make it possible to upgrade the RLPx TCP transport protocol in the same\nmanner as described for the other protocols, i.e. by adding list elements and bumping the\nversion. Since this is the first change to the RLPx handshake packet, we can seize the\nopportunity to remove all currently unused fields.\n\nAdditional data is permitted (and in fact required) after the RLP list because the\nhandshake packet needs to grow in order to be distinguishable from the old format.\nClients can employ logic such as the following pseudocode to handle both formats\nsimultaneously.\n\npacket = read(307, connection)\nif decrypt(packet) {\n // process as old format\n} else {\n size = unpack_16bit_big_endian(packet)\n packet += read(size - 307 + 2, connection)\n if !decrypt(packet) {\n // error\n }\n // process as new format\n}\n\nThe plain text size prefix is perhaps the most controversial aspect of this document. It\nhas been argued that the prefix aids adversaries that seek to filter and identify RLPx\nconnections on the network level.\n\nThis is largely a question of how much effort the adversary is willing to expense. If the\nrecommendation to randomise the lengths is followed, pure pattern-based packet\nrecognition is unlikely to succeed.\n\n For typical firewall operators, blocking all connections whose first two bytes form an\ninteger in range [300,600] is probably too invasive. Port-based blocking would be\na more effective measure to filter most RLPx traffic.\n For an attacker who can afford to correlate many criteria, the size prefix would ease\nrecognition because it adds to the indicator set. However, such an attacker could also\nbe expected to read or participate in RLPx Discovery traffic, which would be sufficient\nto enable blocking of RLPx TCP connections whatever their format is.\n\n Backwards Compatibility\n\nThis EIP is backwards-compatible, all valid version 4 packets are still accepted.\n\n Implementation\n\ngo-ethereum\nlibweb3core\npydevp2p\n\n Test Vectors\n\n devp2p Base Protocol\n\ndevp2p hello packet advertising version 22 and containing a few additional list elements:\n\nf87137916b6e6574682f76302e39312f706c616e39cdc5836574683dc6846d6f726b1682270fb840\nfda1cff674c90c9a197539fe3dfb53086ace64f83ed7c6eabec741f7f381cc803e52ab2cd55d5569\nbce4347107a310dfd5f88a010cd2ffd1005ca406f1842877c883666f6f836261720304\n\n RLPx Discovery Protocol\n\nImplementations should accept the following encoded discovery packets as valid.\nThe packets are signed using the secp256k1 node key\n\nb71c71a67e1177ad4e901695e1b4b9ee17ae16c6668d313eac2f96dbcda3f291\n\nping packet with version 4, additional list elements:\n\ne9614ccfd9fc3e74360018522d30e1419a143407ffcce748de3e22116b7e8dc92ff74788c0b6663a\naa3d67d641936511c8f8d6ad8698b820a7cf9e1be7155e9a241f556658c55428ec0563514365799a\n4be2be5a685a80971ddcfa80cb422cdd0101ec04cb847f000001820cfa8215a8d790000000000000\n000000000000000000018208ae820d058443b9a3550102\n\nping packet with version 555, additional list elements and additional random data:\n\n577be4349c4dd26768081f58de4c6f375a7a22f3f7adda654d1428637412c3d7fe917cadc56d4e5e\n7ffae1dbe3efffb9849feb71b262de37977e7c7a44e677295680e9e38ab26bee2fcbae207fba3ff3\nd74069a50b902a82c9903ed37cc993c50001f83e82022bd79020010db83c4d001500000000abcdef\n12820cfa8215a8d79020010db885a308d313198a2e037073488208ae82823a8443b9a355c5010203\n040531b9019afde696e582a78fa8d95ea13ce3297d4afb8ba6433e4154caa5ac6431af1b80ba7602\n3fa4090c408f6b4bc3701562c031041d4702971d102c9ab7fa5eed4cd6bab8f7af956f7d565ee191\n7084a95398b6a21eac920fe3dd1345ec0a7ef39367ee69ddf092cbfe5b93e5e568ebc491983c09c7\n6d922dc3\n\npong packet with additional list elements and additional random data:\n\n09b2428d83348d27cdf7064ad9024f526cebc19e4958f0fdad87c15eb598dd61d08423e0bf66b206\n9869e1724125f820d851c136684082774f870e614d95a2855d000f05d1648b2d5945470bc187c2d2\n216fbe870f43ed0909009882e176a46b0102f846d79020010db885a308d313198a2e037073488208\nae82823aa0fbc914b16819237dcd8801d7e53f69e9719adecb3cc0e790c57e91ca4461c9548443b9\na355c6010203c2040506a0c969a58f6f9095004c0177a6b47f451530cab38966a25cca5cb58f0555\n42124e\n\nfindnode packet with additional list elements and additional random data:\n\nc7c44041b9f7c7e41934417ebac9a8e1a4c6298f74553f2fcfdcae6ed6fe53163eb3d2b52e39fe91\n831b8a927bf4fc222c3902202027e5e9eb812195f95d20061ef5cd31d502e47ecb61183f74a504fe\n04c51e73df81f25c4d506b26db4517490103f84eb840ca634cae0d49acb401d8a4c6b6fe8c55b70d\n115bf400769cc1400f3258cd31387574077f301b421bc84df7266c44e9e6d569fc56be0081290476\n7bf5ccd1fc7f8443b9a35582999983999999280dc62cc8255c73471e0a61da0c89acdc0e035e260a\ndd7fc0c04ad9ebf3919644c91cb247affc82b69bd2ca235c71eab8e49737c937a2c396\n\nneighbours packet with additional list elements and additional random data:\n\nc679fc8fe0b8b12f06577f2e802d34f6fa257e6137a995f6f4cbfc9ee50ed3710faf6e66f932c4c8\nd81d64343f429651328758b47d3dbc02c4042f0fff6946a50f4a49037a72bb550f3a7872363a83e1\nb9ee6469856c24eb4ef80b7535bcf99c0004f9015bf90150f84d846321163782115c82115db84031\n55e1427f85f10a5c9a7755877748041af1bcd8d474ec065eb33df57a97babf54bfd2103575fa8291\n15d224c523596b401065a97f74010610fce76382c0bf32f84984010203040101b840312c55512422\ncf9b8a4097e9a6ad79402e87a15ae909a4bfefa22398f03d20951933beea1e4dfa6f968212385e82\n9f04c2d314fc2d4e255e0d3bc08792b069dbf8599020010db83c4d001500000000abcdef12820d05\n820d05b84038643200b172dcfef857492156971f0e6aa2c538d8b74010f8e140811d53b98c765dd2\nd96126051913f44582e8c199ad7c6d6819e9a56483f637feaac9448aacf8599020010db885a308d3\n13198a2e037073488203e78203e8b8408dcab8618c3253b558d459da53bd8fa68935a719aff8b811\n197101a4b2b47dd2d47295286fc00cc081bb542d760717d1bdd6bec2c37cd72eca367d6dd3b9df73\n8443b9a355010203b525a138aa34383fec3d2719a0\n\n RLPx Handshake\n\nIn these test vectors, node A initiates a connection with node B.\nThe values contained in all packets are given below:\n\nStatic Key A: 49a7b37aa6f6645917e7b807e9d1c00d4fa71f18343b0d4122a4d2df64dd6fee\nStatic Key B: b71c71a67e1177ad4e901695e1b4b9ee17ae16c6668d313eac2f96dbcda3f291\nEphemeral Key A: 869d6ecf5211f1cc60418a13b9d870b22959d0c16f02bec714c960dd2298a32d\nEphemeral Key B: e238eb8e04fee6511ab04c6dd3c89ce097b11f25d584863ac2b6d5b35b1847e4\nNonce A: 7e968bba13b6c50e2c4cd7f241cc0d64d1ac25c7f5952df231ac6a2bda8ee5d6\nNonce B: 559aead08264d5795d3909718cdd05abd49572e84fe55590eef31a88a08fdffd\n\n(Auth₁) RLPx v4 format (sent from A to B):\n048ca79ad18e4b0659fab4853fe5bc58eb83992980f4c9cc147d2aa31532efd29a3d3dc6a3d89eaf\n913150cfc777ce0ce4af2758bf4810235f6e6ceccfee1acc6b22c005e9e3a49d6448610a58e98744\nba3ac0399e82692d67c1f58849050b3024e21a52c9d3b01d871ff5f210817912773e610443a9ef14\n2e91cdba0bd77b5fdf0769b05671fc35f83d83e4d3b0b000c6b2a1b1bba89e0fc51bf4e460df3105\nc444f14be226458940d6061c296350937ffd5e3acaceeaaefd3c6f74be8e23e0f45163cc7ebd7622\n0f0128410fd05250273156d548a414444ae2f7dea4dfca2d43c057adb701a715bf59f6fb66b2d1d2\n0f2c703f851cbf5ac47396d9ca65b6260bd141ac4d53e2de585a73d1750780db4c9ee4cd4d225173\na4592ee77e2bd94d0be3691f3b406f9bba9b591fc63facc016bfa8\n\n(Auth₂) EIP-8 format with version 4 and no additional list elements (sent from A to B):\n01b304ab7578555167be8154d5cc456f567d5ba302662433674222360f08d5f1534499d3678b513b\n0fca474f3a514b18e75683032eb63fccb16c156dc6eb2c0b1593f0d84ac74f6e475f1b8d56116b84\n9634a8c458705bf83a626ea0384d4d7341aae591fae42ce6bd5c850bfe0b999a694a49bbbaf3ef6c\nda61110601d3b4c02ab6c30437257a6e0117792631a4b47c1d52fc0f8f89caadeb7d02770bf999cc\n147d2df3b62e1ffb2c9d8c125a3984865356266bca11ce7d3a688663a51d82defaa8aad69da39ab6\nd5470e81ec5f2a7a47fb865ff7cca21516f9299a07b1bc63ba56c7a1a892112841ca44b6e0034dee\n70c9adabc15d76a54f443593fafdc3b27af8059703f88928e199cb122362a4b35f62386da7caad09\nc001edaeb5f8a06d2b26fb6cb93c52a9fca51853b68193916982358fe1e5369e249875bb8d0d0ec3\n6f917bc5e1eafd5896d46bd61ff23f1a863a8a8dcd54c7b109b771c8e61ec9c8908c733c0263440e\n2aa067241aaa433f0bb053c7b31a838504b148f570c0ad62837129e547678c5190341e4f1693956c\n3bf7678318e2d5b5340c9e488eefea198576344afbdf66db5f51204a6961a63ce072c8926c\n\n(Auth₃) EIP-8 format with version 56 and 3 additional list elements (sent from A to B):\n01b8044c6c312173685d1edd268aa95e1d495474c6959bcdd10067ba4c9013df9e40ff45f5bfd6f7\n2471f93a91b493f8e00abc4b80f682973de715d77ba3a005a242eb859f9a211d93a347fa64b597bf\n280a6b88e26299cf263b01b8dfdb712278464fd1c25840b995e84d367d743f66c0e54a586725b7bb\nf12acca27170ae3283c1073adda4b6d79f27656993aefccf16e0d0409fe07db2dc398a1b7e8ee93b\ncd181485fd332f381d6a050fba4c7641a5112ac1b0b61168d20f01b479e19adf7fdbfa0905f63352\nbfc7e23cf3357657455119d879c78d3cf8c8c06375f3f7d4861aa02a122467e069acaf513025ff19\n6641f6d2810ce493f51bee9c966b15c5043505350392b57645385a18c78f14669cc4d960446c1757\n1b7c5d725021babbcd786957f3d17089c084907bda22c2b2675b4378b114c601d858802a55345a15\n116bc61da4193996187ed70d16730e9ae6b3bb8787ebcaea1871d850997ddc08b4f4ea668fbf3740\n7ac044b55be0908ecb94d4ed172ece66fd31bfdadf2b97a8bc690163ee11f5b575a4b44e36e2bfb2\nf0fce91676fd64c7773bac6a003f481fddd0bae0a1f31aa27504e2a533af4cef3b623f4791b2cca6\nd490\n\n(Ack₁) RLPx v4 format (sent from B to A):\n049f8abcfa9c0dc65b982e98af921bc0ba6e4243169348a236abe9df5f93aa69d99cadddaa387662\nb0ff2c08e9006d5a11a278b1b3331e5aaabf0a32f01281b6f4ede0e09a2d5f585b26513cb794d963\n5a57563921c04a9090b4f14ee42be1a5461049af4ea7a7f49bf4c97a352d39c8d02ee4acc416388c\n1c66cec761d2bc1c72da6ba143477f049c9d2dde846c252c111b904f630ac98e51609b3b1f58168d\ndca6505b7196532e5f85b259a20c45e1979491683fee108e9660edbf38f3add489ae73e3dda2c71b\nd1497113d5c755e942d1\n\n(Ack₂) EIP-8 format with version 4 and no additional list elements (sent from B to A):\n01ea0451958701280a56482929d3b0757da8f7fbe5286784beead59d95089c217c9b917788989470\nb0e330cc6e4fb383c0340ed85fab836ec9fb8a49672712aeabbdfd1e837c1ff4cace34311cd7f4de\n05d59279e3524ab26ef753a0095637ac88f2b499b9914b5f64e143eae548a1066e14cd2f4bd7f814\nc4652f11b254f8a2d0191e2f5546fae6055694aed14d906df79ad3b407d94692694e259191cde171\nad542fc588fa2b7333313d82a9f887332f1dfc36cea03f831cb9a23fea05b33deb999e85489e645f\n6aab1872475d488d7bd6c7c120caf28dbfc5d6833888155ed69d34dbdc39c1f299be1057810f34fb\ne754d021bfca14dc989753d61c413d261934e1a9c67ee060a25eefb54e81a4d14baff922180c395d\n3f998d70f46f6b58306f969627ae364497e73fc27f6d17ae45a413d322cb8814276be6ddd13b885b\n201b943213656cde498fa0e9ddc8e0b8f8a53824fbd82254f3e2c17e8eaea009c38b4aa0a3f306e8\n797db43c25d68e86f262e564086f59a2fc60511c42abfb3057c247a8a8fe4fb3ccbadde17514b7ac\n8000cdb6a912778426260c47f38919a91f25f4b5ffb455d6aaaf150f7e5529c100ce62d6d92826a7\n1778d809bdf60232ae21ce8a437eca8223f45ac37f6487452ce626f549b3b5fdee26afd2072e4bc7\n5833c2464c805246155289f4\n\n(Ack₃) EIP-8 format with version 57 and 3 additional list elements (sent from B to A):\n01f004076e58aae772bb101ab1a8e64e01ee96e64857ce82b1113817c6cdd52c09d26f7b90981cd7\nae835aeac72e1573b8a0225dd56d157a010846d888dac7464baf53f2ad4e3d584531fa203658fab0\n3a06c9fd5e35737e417bc28c1cbf5e5dfc666de7090f69c3b29754725f84f75382891c561040ea1d\ndc0d8f381ed1b9d0d4ad2a0ec021421d847820d6fa0ba66eaf58175f1b235e851c7e2124069fbc20\n2888ddb3ac4d56bcbd1b9b7eab59e78f2e2d400905050f4a92dec1c4bdf797b3fc9b2f8e84a482f3\nd800386186712dae00d5c386ec9387a5e9c9a1aca5a573ca91082c7d68421f388e79127a5177d4f8\n590237364fd348c9611fa39f78dcdceee3f390f07991b7b47e1daa3ebcb6ccc9607811cb17ce51f1\nc8c2c5098dbdd28fca547b3f58c01a424ac05f869f49c6a34672ea2cbbc558428aa1fe48bbfd6115\n8b1b735a65d99f21e70dbc020bfdface9f724a0d1fb5895db971cc81aa7608baa0920abb0a565c9c\n436e2fd13323428296c86385f2384e408a31e104670df0791d93e743a3a5194ee6b076fb6323ca59\n3011b7348c16cf58f66b9633906ba54a2ee803187344b394f75dd2e663a57b956cb830dd7a908d4f\n39a2336a61ef9fda549180d4ccde21514d117b6c6fd07a9102b5efe710a32af4eeacae2cb3b1dec0\n35b9593b48b9d3ca4c13d245d5f04169b0b1\n\nNode B derives the connection secrets for (Auth₂, Ack₂) as follows:\n\naes-secret = 80e8632c05fed6fc2a13b0f8d31a3cf645366239170ea067065aba8e28bac487\nmac-secret = 2ea74ec5dae199227dff1af715362700e989d889d7a493cb0639691efb8e5f98\n\nRunning B’s ingress-mac keccak state on the string “foo” yields the hash\n\ningress-mac(\"foo\") = 0c7ec6340062cc46f5e9f1e3cf86f8c8c403c5a0964f5df0ebd34a75ddc86db5\n\n Copyright\n\nCopyright and related rights waived via CC0.\n\n Citation\n Please cite this document as:\n\n Felix Lange <felix@ethdev.com>, \"EIP-8: devp2p Forward Compatibility Requirements for Homestead,\" Ethereum Improvement Proposals, no. 8, December 2015. Available: https://eips.ethereum.org/EIPS/eip-8.","tokens":4579,"squid":"spider-05","role":"Spec Spider","at":1791339841986,"hash":"62fc4f115dbf5cdc28bbfd67e939cb30e88a4b35"}
{"url":"https://docs.across.to/introduction/relayers/relayer-nomination","domain":"docs.across.to","title":"Relayer Nomination | Across Docs","text":"Relayer NominationHow exclusive relayer nomination works and how to participate.Relayer nomination grants a single relayer temporary exclusive rights to fulfill a specific deposit. The protocol assigns exclusivity through the exclusiveRelayer and exclusivityDeadline parameters at deposit creation, emitted via the V3FundsDeposited event.\nThe designated relayer maintains fill rights until the deadline on the destination chain. After expiration, any relayer may complete unfilled deposits.\nWhy Nomination?\nWithout nomination, relayers race to fill orders — creating collision risks and escalating gas price pressure. Exclusivity retains the speed gains that Across has unlocked for users while reducing uncertainty and risk for relayers.\nAdditional benefits include:\n\nPerformance evaluation — the protocol can measure and score relayer reliability\nOrder flow preferences — a pathway toward rewarding top-performing relayers\n\nParticipation Requirements\n\nApply — submit a pull request to the Exclusive Relayer Configuration repository.\nBuild a track record — new participants must demonstrate capability through step-in fills (completing deposits abandoned by other nominated relayers) and sub-10 second fill times on open order flow.\nReceive scores — selected relayers receive biweekly performance scores based on three metrics:\n\nMetricDescriptionCompletion RatePercentage of assigned fills successfully executedFill SpeedTransaction timing benchmarked against non-exclusive baselineStep-in FillsAbility to complete deposits abandoned by other nominated relayers\nImplementation Status\nThe system is rolling out incrementally across select Across API routes. Most frontend flow currently has assigned exclusive relayers. Third-party integrators are expected to implement relayer exclusivity during Q1-Q2 2025.Running a RelayerSet up and operate your own Across V3 relay infrastructure.The Bridge AcrossA quick overview of what is happening with $ACX, and where to follow updates.","tokens":495,"squid":"spider-09","role":"Bridge Spider","at":1791339842040,"hash":"70e9b4fed6f4672f3572de41686f2c3957d727f0"}
{"url":"https://akash.network/ecosystem/deployed-on-akash/ai%20&%20ml","domain":"akash.network","title":"AI & ML | Deployed On Akash","text":"AI & ML AkashML High-performance, low latency AI inference service built on Akash NetworkHigh-performance, low latency AI inference service built on Akash NetworkHigh-performance, low latency AI inference service built on Akash NetworkHigh-performance, low latency AI inference service built on Akash Network View project R Λ Z Ξ R Razer's personalized AI companion experience, was brought to life at global scale using Razer's AIKit and Akash.Razer's personalized AI companion experience, was brought to life at global scale using Razer's AIKit and Akash.Razer's personalized AI companion experience, was brought to life at global scale using Razer's AIKit and Akash. View project NVIDIA Brev.dev (Acq. by NVIDIA), known for its seamless setup of Jupyter notebooks for AI development, has integrated with Akash Network, enabling scalable, permissionless access to NVIDIA GPUs.Brev.dev (Acq. by NVIDIA), known for its seamless setup of Jupyter notebooks for AI development, has integrated with Akash Network, enabling scalable, permissionless access to NVIDIA GPUs.Brev.dev (Acq. by NVIDIA), known for its seamless setup of Jupyter notebooks for AI development, has integrated with Akash Network, enabling scalable, permissionless access to NVIDIA GPUs. View project Venice.ai Venice is the easy app for private, uncensored AI conversations and image generation. Try for free with no log-in needed.Venice is the easy app for private, uncensored AI conversations and image generation. Try for free with no log-in needed.Venice is the easy app for private, uncensored AI conversations and image generation. Try for free with no log-in needed. View project Prime Intellect Prime Intellect leverages Akash Supercloud's high-performance GPUs, like NVIDIA H100 and A100, to democratize AI development.Prime Intellect leverages Akash Supercloud's high-performance GPUs, like NVIDIA H100 and A100, to democratize AI development.Prime Intellect leverages Akash Supercloud's high-performance GPUs, like NVIDIA H100 and A100, to democratize AI development. View project University of Texas at Austin The University of Texas at Austin is a bold, ambitious leader, providing a first-class education and the tools of discovery to more than 51,000 students.The University of Texas at Austin is a bold, ambitious leader, providing a first-class education and the tools of discovery to more than 51,000 students.The University of Texas at Austin is a bold, ambitious leader, providing a first-class education and the tools of discovery to more than 51,000 students. View project Nous Research Leveraging the power of Akash's decentralized cloud, Nous Research successfully trained 'Nous Hermes 2,' an advanced AI model built on over 1,000,000 entries of GPT-4 data.Leveraging the power of Akash's decentralized cloud, Nous Research successfully trained 'Nous Hermes 2,' an advanced AI model built on over 1,000,000 entries of GPT-4 data.Leveraging the power of Akash's decentralized cloud, Nous Research successfully trained 'Nous Hermes 2,' an advanced AI model built on over 1,000,000 entries of GPT-4 data. View project Morpheus Morpheus is designed to incentivize the first open-source p2p network of personal general-purpose AI, powered by the MOR token.Morpheus is designed to incentivize the first open-source p2p network of personal general-purpose AI, powered by the MOR token.Morpheus is designed to incentivize the first open-source p2p network of personal general-purpose AI, powered by the MOR token. View project Flock.io Flock.io is advancing open, decentralized AI by integrating with Akash's Supercloud, making it simple for developers to access high-performance compute for training AI models.Flock.io is advancing open, decentralized AI by integrating with Akash's Supercloud, making it simple for developers to access high-performance compute for training AI models.Flock.io is advancing open, decentralized AI by integrating with Akash's Supercloud, making it simple for developers to access high-performance compute for training AI models. View project Akash Chat Benchmark conversational LLMs side‑by‑side. Seamlessly switch between leading open‑source chat models, evaluate responses, and choose the best fit for your application.Benchmark conversational LLMs side‑by‑side. Seamlessly switch between leading open‑source chat models, evaluate responses, and choose the best fit for your application.Benchmark conversational LLMs side‑by‑side. Seamlessly switch between leading open‑source chat models, evaluate responses, and choose the best fit for your application. View project Auki Virtual real estate for shared augmented reality, allowing you to manifest your knowledge and imagination in the minds of others. Our unique solutions are powered by The Posemesh, a decentralized and privacy-preserving protocol for collaborative spatial computing.Virtual real estate for shared augmented reality, allowing you to manifest your knowledge and imagination in the minds of others. Our unique solutions are powered by The Posemesh, a decentralized and privacy-preserving protocol for collaborative spatial computing.Virtual real estate for shared augmented reality, allowing you to manifest your knowledge and imagination in the minds of others. Our unique solutions are powered by The Posemesh, a decentralized and privacy-preserving protocol for collaborative spatial computing. View project Bagel Bagel is an AI & Cryptography Research Lab. Making Open Source AI Monetizable leveraging novel cryptography.Bagel is an AI & Cryptography Research Lab. Making Open Source AI Monetizable leveraging novel cryptography.Bagel is an AI & Cryptography Research Lab. Making Open Source AI Monetizable leveraging novel cryptography. View project Levangie Laboratories Levangie Laboratories is shaping the next generation of adaptive AI systems. We are building agents that learn, evolve, and collaborate in real time, transforming industries and redefining what's possible with AI.Levangie Laboratories is shaping the next generation of adaptive AI systems. We are building agents that learn, evolve, and collaborate in real time, transforming industries and redefining what's possible with AI.Levangie Laboratories is shaping the next generation of adaptive AI systems. We are building agents that learn, evolve, and collaborate in real time, transforming industries and redefining what's possible with AI. View project Vertical AI The no-code platform for AI model fine-tuning. Train, deploy, and monetize AI models effortlessly through our integrated marketplace.The no-code platform for AI model fine-tuning. Train, deploy, and monetize AI models effortlessly through our integrated marketplace.The no-code platform for AI model fine-tuning. Train, deploy, and monetize AI models effortlessly through our integrated marketplace. View project Bless The world's first shared computer.The world's first shared computer.The world's first shared computer.The world's first shared computer. View project Grid The easiest way to deploy postgres on Akash.The easiest way to deploy postgres on Akash.The easiest way to deploy postgres on Akash.The easiest way to deploy postgres on Akash. View project VPS AI VPS AI has integrated with Akash, enabling decentralized, on-chain bidding for AI/ML workloads and GPU deployments.VPS AI has integrated with Akash, enabling decentralized, on-chain bidding for AI/ML workloads and GPU deployments.VPS AI has integrated with Akash, enabling decentralized, on-chain bidding for AI/ML workloads and GPU deployments. View project Saga Saga has integrated compute from the Akash Supercloud to power AI agents, enabling lower costs and greater access to the leading open source AI models.Saga has integrated compute from the Akash Supercloud to power AI agents, enabling lower costs and greater access to the leading open source AI models.Saga has integrated compute from the Akash Supercloud to power AI agents, enabling lower costs and greater access to the leading open source AI models. View project Bitmind The BitMind Platform makes utilizing compute easy. It aggregates compute from a variety of different providers, including Akash, and helps deploy and maintain instances for decentralized AI, providing a seamless and scalable experience for its users.The BitMind Platform makes utilizing compute easy. It aggregates compute from a variety of different providers, including Akash, and helps deploy and maintain instances for decentralized AI, providing a seamless and scalable experience for its users.The BitMind Platform makes utilizing compute easy. It aggregates compute from a variety of different providers, including Akash, and helps deploy and maintain instances for decentralized AI, providing a seamless and scalable experience for its users. View project Envision Labs Envision Labs has selected Akash as its primary compute provider, leveraging its automated scaling capabilities to power the Envision DeAI Network.Envision Labs has selected Akash as its primary compute provider, leveraging its automated scaling capabilities to power the Envision DeAI Network.Envision Labs has selected Akash as its primary compute provider, leveraging its automated scaling capabilities to power the Envision DeAI Network. View project Exabits Exabits,DGX B200, H100, GPU, web3.0,Decentralized,NVIDIA H100 GPUs,NVIDIA RTX 3090,network,docker,computing,blockchain,nft market,dappExabits,DGX B200, H100, GPU, web3.0,Decentralized,NVIDIA H100 GPUs,NVIDIA RTX 3090,network,docker,computing,blockchain,nft market,dappExabits,DGX B200, H100, GPU, web3.0,Decentralized,NVIDIA H100 GPUs,NVIDIA RTX 3090,network,docker,computing,blockchain,nft market,dapp View project Foundry Digital Foundry empowers institutional miners, staking customers, and participants within the crypto ecosystem to mine and stake digital assets.Foundry empowers institutional miners, staking customers, and participants within the crypto ecosystem to mine and stake digital assets.Foundry empowers institutional miners, staking customers, and participants within the crypto ecosystem to mine and stake digital assets. View project Nebula Block Nebula Block offers smart and cost effective hosting solutions to make compute accessible to everyone in AI & Blockchain community.Nebula Block offers smart and cost effective hosting solutions to make compute accessible to everyone in AI & Blockchain community.Nebula Block offers smart and cost effective hosting solutions to make compute accessible to everyone in AI & Blockchain community. View project Neural AI Neural AI transforms words into 3D AI game assets.Neural AI transforms words into 3D AI game assets.Neural AI transforms words into 3D AI game assets.Neural AI transforms words into 3D AI game assets. View project Rango Exchange The Universal Cross-Chain DEX Bridge Aggregator, Best Swap Rates on Bitcoin, Ethereum, Solana, Base, Blast, Celo, Arbitrum, BNB, Scroll, Polygon, and 50 more blockchains.The Universal Cross-Chain DEX Bridge Aggregator, Best Swap Rates on Bitcoin, Ethereum, Solana, Base, Blast, Celo, Arbitrum, BNB, Scroll, Polygon, and 50 more blockchains.The Universal Cross-Chain DEX Bridge Aggregator, Best Swap Rates on Bitcoin, Ethereum, Solana, Base, Blast, Celo, Arbitrum, BNB, Scroll, Polygon, and 50 more blockchains. View project AkashGen AkashGen is a high quality text-to-image model from Stability AI. This application is running on NVIDIA A100s leased from the Akash Supercloud, to achieve high-performing and cost-effective inference of 1024×1024 images.AkashGen is a high quality text-to-image model from Stability AI. This application is running on NVIDIA A100s leased from the Akash Supercloud, to achieve high-performing and cost-effective inference of 1024×1024 images.AkashGen is a high quality text-to-image model from Stability AI. This application is running on NVIDIA A100s leased from the Akash Supercloud, to achieve high-performing and cost-effective inference of 1024×1024 images. View project Thumper AI Blockchain analysis, deploy tool and proud validator of the Akash NetworkBlockchain analysis, deploy tool and proud validator of the Akash NetworkBlockchain analysis, deploy tool and proud validator of the Akash NetworkBlockchain analysis, deploy tool and proud validator of the Akash Network View project","tokens":3079,"squid":"spider-03","role":"Compute Spider","at":1791339842118,"hash":"4d6aeb04b3bbba69a1ce77ea4c1a1908a93f02a6"}
{"url":"https://docs.across.to/introduction/tracking-deposits","domain":"docs.across.to","title":"Tracking Deposits | Across Docs","text":"Tracking DepositsMonitor crosschain transfer status using the deposit tracking API.API key required for production. Get your API key and Integrator ID to authenticate your requests.\nAfter executing a swap transaction, use the /deposit/status endpoint to track whether the deposit has been filled, is still pending, or has expired.\nStatus Values\nStatusDescriptionpendingDeposit submitted but not yet filled by a relayerfilledRelayer has filled the intent on the destination chainexpiredFill deadline passed without a fill (eligible for refund)refundedDeposit was refunded after expiration\nDuring the pre-fill window (while status is pending or received), the response also returns originToken and destinationToken — the token addresses taken from the deposit witness. Both are null once the deposit is filled.\nQuery Methods\nYou can query deposit status in two ways: by depositId (extracted from the deposit event) or by the deposit transaction hash.\nQuery with the originChainId and depositId from the V3FundsDeposited event.GET /deposit/status?originChainId=42161&depositId=12345Query with the deposit transaction hash. The API will look up the deposit event from the transaction.GET /deposit/status?depositTxnRef=0xabc123...\nExtracting the Deposit ID\nWhen you submit a swap transaction, the origin SpokePool emits a V3FundsDeposited event. Extract the depositId from this event to use for status tracking.\nextract-deposit-id.tsimport { createPublicClient, http, parseAbiItem } from \"viem\";\nimport { arbitrum } from \"viem/chains\";\n\nconst publicClient = createPublicClient({\n chain: arbitrum,\n transport: http(),\n});\n\nconst SPOKE_POOL_ADDRESS = \"0xe35e9842fceaca96570b734083f4a58e8f7c5f2a\";\n\nasync function getDepositId(txHash: `0x${string}`) {\n const receipt = await publicClient.getTransactionReceipt({ hash: txHash });\n\n const depositEvent = parseAbiItem(\n \"event V3FundsDeposited(address inputToken, address outputToken, uint256 inputAmount, uint256 outputAmount, uint256 indexed destinationChainId, uint32 indexed depositId, uint32 quoteTimestamp, uint32 fillDeadline, uint32 exclusivityDeadline, address indexed depositor, address recipient, address exclusiveRelayer, bytes message)\"\n );\n\n const logs = await publicClient.getLogs({\n address: SPOKE_POOL_ADDRESS,\n event: depositEvent,\n fromBlock: receipt.blockNumber,\n toBlock: receipt.blockNumber,\n });\n\n if (logs.length === 0) {\n throw new Error(\"No V3FundsDeposited event found in transaction\");\n }\n\n const depositId = logs[0].args.depositId;\n console.log(\"Deposit ID:\", depositId);\n return depositId;\n}\nPolling for Status\nPoll the /deposit/status endpoint until the deposit reaches a terminal state (filled, expired, or refunded).\npoll-status.tsconst BASE_URL = \"https://app.across.to/api\";\n\nasync function pollDepositStatus(\n originChainId: number,\n depositId: number,\n intervalMs = 10_000,\n maxAttempts = 60\n): Promise<string> {\n for (let i = 0; i < maxAttempts; i++) {\n const params = new URLSearchParams({\n originChainId: originChainId.toString(),\n depositId: depositId.toString(),\n });\n\n const res = await fetch(`${BASE_URL}/deposit/status?${params}`);\n const data = await res.json();\n\n console.log(`[Attempt ${i + 1}] Status: ${data.status}`);\n\n if (data.status === \"filled\") {\n console.log(\"Deposit filled on destination chain\");\n return data.status;\n }\n\n if (data.status === \"expired\") {\n console.log(\"Deposit expired — eligible for refund\");\n return data.status;\n }\n\n if (data.status === \"refunded\") {\n console.log(\"Deposit refunded\");\n return data.status;\n }\n\n // Wait before next poll\n await new Promise((resolve) => setTimeout(resolve, intervalMs));\n }\n\n throw new Error(\"Polling timed out\");\n}\n\n// Usage\nconst status = await pollDepositStatus(42161, 12345);\nPolling Recommendations\n10-second polling interval. The Across indexer has a latency of 1-15 seconds. Polling more frequently than every 10 seconds won't return faster results and will waste API calls.\n\nMainnet fills typically complete in ~2 seconds, but the indexer may take 1-15 seconds to reflect the status\nTestnet fills take ~1 minute\nSet a reasonable timeout (e.g., 10 minutes) to avoid polling indefinitely\nFor production integrations, consider using a webhook or event-based approach alongside polling\n\nAlternative: Query by Transaction Hash\nIf you don't want to extract the depositId, you can query directly with the transaction hash:\npoll-by-hash.tsasync function pollByTxHash(\n txHash: string,\n intervalMs = 10_000,\n maxAttempts = 60\n): Promise<string> {\n for (let i = 0; i < maxAttempts; i++) {\n const params = new URLSearchParams({ depositTxnRef: txHash });\n const res = await fetch(`${BASE_URL}/deposit/status?${params}`);\n const data = await res.json();\n\n console.log(`[Attempt ${i + 1}] Status: ${data.status}`);\n\n if ([\"filled\", \"expired\", \"refunded\"].includes(data.status)) {\n return data.status;\n }\n\n await new Promise((resolve) => setTimeout(resolve, intervalMs));\n }\n\n throw new Error(\"Polling timed out\");\n}Actors in the SystemThe key participants that make crosschain transfers work — users, relayers, LPs, dataworkers, and the UMA oracle.RefundsHow refunds work when a crosschain transfer expires without being filled.","tokens":1293,"squid":"spider-09","role":"Bridge Spider","at":1791339863891,"hash":"a8587502a6041a4db446b84ae36de468740df378"}
{"url":"https://docs.switchboard.xyz/custom-feeds/build-and-deploy-feed/build-with-typescript","domain":"docs.switchboard.xyz","title":"Build with TypeScript | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.This guide is for developers who prefer code-first workflows.You’ll learn how to:model a feed as a list of Oracle Jobscompose each job from sequential Taskssimulate jobs using Crossbariterate safely and build production-grade feed definitionsThis guide focuses on designing + simulating feed definitions.\nDeployment differs by chain — see Deploy Feed.Mental modelOracle Jobs are “pipelines”A job is an ordered list of tasks:// Oracle Job\n[\n httpTask,\n jsonParseTask,\n multiplyTask,\n]Each task runs sequentially. The job’s “current value” is updated as tasks run, and the job result is valid only if the final task produces a numeric value.Feeds are “job sets”A feed is a set of jobs. Oracles execute the jobs and then aggregate the results (commonly median across jobs).PrerequisitesNode.js or Bun (examples use Bun for simple TS execution)Basic TypeScript familiarityYour data sources (REST APIs, DEX pricing tasks, etc.)Install dependenciesUsing Bunmkdir example\ncd example\nbun init\nbun add @switchboard-xyz/on-demand@3.10.6 @switchboard-xyz/common@5.8.5Note: Some examples import OracleJob from @switchboard-xyz/common.\nAdding it explicitly avoids “transitive dependency” surprises.Keep these versions together and refresh your lockfile when upgrading. Common 5.8.5 uses the Rust/prost-compatible canonical encoding for OracleJob and OracleFeed identities. It preserves newer task fields and explicitly set optional defaults, and its encoder is isolated from other installed Common versions.Example: a minimal BTC/USDT jobThis is the smallest “real” job: fetch a JSON payload and extract a price.Create index.ts:import { OracleJob, serializeOracleJob } from \"@switchboard-xyz/common\";\n\nconst jobs: OracleJob[] = [\n OracleJob.fromObject({\n tasks: [\n {\n httpTask: {\n url: \"https://binance.com/api/v3/ticker/price?symbol=BTCUSDT\",\n },\n },\n {\n jsonParseTask: {\n path: \"$.price\",\n },\n },\n ],\n }),\n];\n\nconsole.log(\"Jobs JSON:\\n\");\nconsole.log(JSON.stringify({ jobs: jobs.map((j) => j.toJSON()) }, null, 2));At this point you have a valid feed definition (one job).Simulate your job(s) with CrossbarSimulation runs your jobs against real sources and returns their outputs. This is how you iterate quickly before deploying or publishing.⚠️ The public simulation endpoint is heavily rate-limited.\nUse it for development only.Append this to index.ts:// Serialize the jobs to base64 strings.\nconst serializedJobs = jobs.map((oracleJob) => {\n const base64 = serializeOracleJob(oracleJob).toString(\"base64\");\n return base64;\n});\n\nconsole.log(\"\\nRunning simulation...\\n\");\n\n// Call the simulation server.\nconst response = await fetch(\"https://crossbar.switchboard.xyz/api/simulate\", {\n method: \"POST\",\n headers: [[\"Content-Type\", \"application/json\"]],\n body: JSON.stringify({\n cluster: \"Mainnet\",\n jobs: serializedJobs,\n }),\n});\n\n// Print results\nif (response.ok) {\n const data = await response.json();\n console.log(JSON.stringify(data, null, 2));\n} else {\n console.error(`Simulation failed (${response.status})`);\n console.error(await response.text());\n}Run it:bun run index.tsYou should see a response like:{\n \"results\": [\"64158.33000000\"],\n \"version\": \"...\"\n}Building production-grade feedsUse multiple jobs (multiple sources)The simplest reliability upgrade is to use several independent jobs:Job 1: CEX APIJob 2: another CEX APIJob 3: on-chain DEX price simulation taskThen rely on aggregation (median) and feed configuration (variance/quorum) to filter noise.Conceptually:const jobs: OracleJob[] = [\n /* source A */,\n /* source B */,\n /* source C */,\n];Normalize decimalsDifferent sources often report:different quote assetsinverted pricesdifferent decimal precisionUse math tasks (multiply/divide/round) so every job returns the same unit.Bound results (optional but recommended)Bounding can be applied:within a job (reject a single bad API response)at the feed level (reject updates when jobs disagree too much)Feed-level validation fields use different units depending on the surface. Raw v2 OracleFeed.maxJobRangePct is scaled by 1e9 (1_000_000_000 = 1%), while MedianTask.max_range_percent is a human percent string. See Feed Parameter Units before publishing a feed definition.Task referenceSwitchboard supports many task types, including:HttpTask (REST)JsonParseTask (JSONPath extraction)MedianTask (sub-aggregation inside a job)JupiterSwapTask (Solana DEX price simulation)SecretsTask (secure secret retrieval)Full task docs:Task Types ReferenceSecrets, variables, and safetyVariable overrides (${VAR_NAME})Use variable overrides to insert request-scoped values into task string fields at runtime. API keys and auth tokens are the safest default because they do not intentionally change feed semantics.See Data Feed Variable Overrides for the supported pattern and the full security guidance.Override values are not included in the feed ID or signed checksum. Keep data sources, selections, and calculations fixed for permissionlessly updated feeds. Semantic overrides are supported when a controlled updater owns the request and consumers intentionally trust that caller.Where to go nextDeploy on-chainUse the visual editorPreviousBuild with UINextDeploy FeedLast updated 2 months ago","tokens":1320,"squid":"spider-08","role":"Oracle Spider","at":1791339865822,"hash":"e48650b858448cec24f05cc8c495332489eee16c"}
{"url":"https://docs.switchboard.xyz/custom-feeds/build-and-deploy-feed/deploy-feed","domain":"docs.switchboard.xyz","title":"Deploy Feed | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.\"Deploying\" a Switchboard feed means making it available for use on-chain. With Switchboard's managed update system, this is simpler than ever:Solana/SVM: Feeds use canonical OracleQuote accounts derived deterministically from feed IDs. No explicit account creation needed—accounts are created automatically on first use.EVM: Feeds are identified by a deterministic bytes32 ID. You submit oracle-signed updates to the Switchboard contract and read the latest update from storage.Both chains follow the same pattern: store your feed definition, get a feed ID, then use managed updates.Prerequisites (all chains)Before “deployment”, you should have:a feed definition (jobs + tasks) you have simulated successfullya clear understanding of:what value your feed returnsdecimal conventions (e.g., 1e8 vs 1e18)which sources/jobs you trust and whyIf you haven't designed and simulated your jobs yet, start here:Build with TypeScript (code-first)Build with UI (UI-first)Before you publish a v2 feed definition, confirm the feed parameter units. Raw OracleFeed.maxJobRangePct is scaled by 1e9, so 1_000_000_000 means 1%. See Feed Parameter Units.Solana / SVM: Deploy with Managed UpdatesWhat you are doingOn Solana, deployment means:Choose a queue (oracle subnet).Store/pin your job definition with Crossbar to get a feed hash.Use the feed hash to derive the canonical OracleQuote account address.Fetch managed update instructions and include them in your transactions.The canonical account is created automatically on first use—no explicit initialization transaction required.For new Solana/SVM feed-hash integrations, this quote-program path is the supported default. Do not use PullFeed.fetchUpdateIx(...) unless you are maintaining an existing classic PullFeed account and the selected queue/gateway environment explicitly supports the legacy PullFeed update flow.RequirementsA funded Solana keypair file (payer)A Solana RPC URLYour OracleJob[] definitionCreate a keypair file if you don't have one:solana-keygen new --outfile path/to/solana-keypair.jsonInstallbun add @switchboard-xyz/on-demand@3.10.6 @switchboard-xyz/common@5.8.5Deployment flow (TypeScript)Below is the deployment flow using managed updates. You can merge this into the same project where you built/simulated your jobs.import { CrossbarClient, OracleJob } from \"@switchboard-xyz/common\";\nimport {\n AnchorUtils,\n OracleQuote,\n getDefaultQueue,\n getDefaultDevnetQueue,\n asV0Tx,\n} from \"@switchboard-xyz/on-demand\";\n\n// 1) Your simulated job definitions\nconst jobs: OracleJob[] = [\n /* ... */\n];\n\n// 2) Choose cluster + RPC\nconst connection = /* new Connection(RPC_URL) */;\n\n// 3) Choose the queue (oracle subnet)\nconst queue = await getDefaultQueue(connection.rpcUrl);\n// or: const queue = await getDefaultDevnetQueue(connection.rpcUrl);\n\n// 4) Store jobs with Crossbar and get a feedHash\nconst crossbarClient = CrossbarClient.default();\nconst { feedHash } = await crossbarClient.store(queue.pubkey.toBase58(), jobs);\nconsole.log(\"Feed hash:\", feedHash);\n\n// 5) Derive the canonical OracleQuote account address\n// This is deterministic - same feed hash always produces the same address\nconst [quoteAccount] = OracleQuote.getCanonicalPubkey(queue.pubkey, [feedHash]);\nconsole.log(\"Quote account:\", quoteAccount.toBase58());\n\n// 6) Load payer (funded)\nconst payer = await AnchorUtils.initKeypairFromFile(\"path/to/solana-keypair.json\");\n\n// 7) Fetch managed update instructions\n// This returns Ed25519 verification + quote storage instructions\nconst updateIxs = await queue.fetchManagedUpdateIxs(crossbarClient, [feedHash], {\n payer: payer.publicKey,\n});\n\n// 8) Build and send a transaction to verify everything works\nconst tx = await asV0Tx({\n connection,\n ixs: updateIxs,\n payer: payer.publicKey,\n signers: [payer],\n});\n\nconst sig = await connection.sendTransaction(tx);\nconsole.log(\"Transaction signature:\", sig);\nconsole.log(\"Feed deployed! Quote account:\", quoteAccount.toBase58());To read the stored quote account, parse it with the SDK/Rust quote-account types instead of fixed byte offsets. See Quote Program Accounts.Using validation parametersValidation parameters (min responses, max variance, staleness) are now specified when fetching updates or reading data, rather than at deployment time:// When reading in your program, use QuoteVerifier with max_age\nconst quote_data = QuoteVerifier::new()\n .max_age(30) // Reject data older than 30 slots\n .verify_account(quote)?;Make it discoverableStoring with Crossbar pins the feed definition to IPFS and makes it easier to view/debug in the Switchboard explorer. The feed hash is the key identifier you'll use throughout your integration.EVM: “Deploying” is publishing a feed ID + updating via the Switchboard contractWhy there isn’t a dedicated “deploy feed” step on EVMOn EVM, a feed is identified by a deterministic bytes32 feed ID. You can treat deployment as:Obtain the feed ID (often from the Feed Builder / Explorer).Store that feed ID in your consumer contract or app.Fetch oracle-signed updates off-chain.Submit updates on-chain via updateFeeds.This is the same pattern Solana now uses with managed updates—no explicit account creation needed.On-chain: reading and updatingA typical Solidity integration looks like:Store the Switchboard contract address + your feedIdWhen you need fresh data:compute the required feesubmit updateFeeds(updates)read latestUpdate(feedId)//SPDX-License-Identifier: UNLICENSED\npragma solidity ^0.8.0;\n\nimport {ISwitchboard} from \"@switchboard-xyz/on-demand-solidity/ISwitchboard.sol\";\nimport {Structs} from \"@switchboard-xyz/on-demand-solidity/structs/Structs.sol\";\n\ncontract Example {\n ISwitchboard switchboard;\n bytes32 feedId;\n\n error InsufficientFee(uint256 expected, uint256 received);\n error InvalidResult(int128 result);\n\n constructor(address _switchboard, bytes32 _feedId) {\n switchboard = ISwitchboard(_switchboard);\n feedId = _feedId;\n }\n\n function getFeedData(bytes[] calldata updates) external payable returns (int128) {\n uint256 fee = switchboard.getFee(updates);\n if (msg.value < fee) revert InsufficientFee(fee, msg.value);\n\n switchboard.updateFeeds{value: fee}(updates);\n\n Structs.Update memory latest = switchboard.latestUpdate(feedId);\n if (latest.result < 0) revert InvalidResult(latest.result);\n\n return latest.result;\n }\n}Many feeds use int128 scaled by 1e18 to avoid floating point issues.\nAlways consult the feed’s intended decimal convention.Off-chain: fetch encoded updates with Crossbar (TypeScript)Use Crossbar to fetch oracle-signed updates (encoded) for submission:import { CrossbarClient } from \"@switchboard-xyz/common\";\n\nconst feedId = \"0x...your_feed_id...\";\nconst crossbarNetwork = \"testnet\"; // or \"mainnet\"\n\nconst crossbar = new CrossbarClient(\"https://crossbar.switchboard.xyz\");\n\n// Recommended preflight for Feed Builder feeds:\nawait crossbar.fetchOracleFeed(feedId);\nawait crossbar.simulateFeed(feedId, false, undefined, crossbarNetwork);\n\nconst response = await crossbar.fetchV2Update([feedId], {\n chain: \"evm\",\n network: crossbarNetwork,\n use_timestamp: true,\n});\n\nif (!response.encoded) {\n throw new Error(\"Crossbar returned no encoded update payload\");\n}\n\nconst updates = [response.encoded];\n\n// submit `updates` to your contract method that calls updateFeeds(...)Recommended EVM preflight order for custom feeds:GET /v2/fetch/{feedId} or crossbar.fetchOracleFeed(feedId) to confirm the definition existsGET /v2/simulate/{feedId}?network=testnet|mainnet or crossbar.simulateFeed(...) to confirm the jobs resolveGET /v2/update/{feedId}?chain=evm&network=testnet|mainnet&use_timestamp=true or crossbar.fetchV2Update(...) to obtain the EVM payloadUse the same deterministic feedId / feed hash from Feed Builder or Explorer for all three steps.Do not pass a Feed Builder bytes32 feed ID into fetchEVMResults() or simulateEVMFeeds() unless you are intentionally using the legacy aggregator-based EVM flow.Do we need “deployment docs” for other chains?Switchboard supports additional chains with chain-specific SDKs and verification flows (e.g., Move-based environments). Many of these integrations follow the EVM-style model: you fetch oracle consensus off-chain and include a verification/update step inside your transaction, rather than creating a dedicated on-chain “feed account”.If you’re targeting a non-Solana chain, treat “deployment” as:Create/publish a feed definition and get its feed ID/address.Use the chain’s SDK to fetch and verify oracle results in your transaction flow.PreviousBuild with TypeScriptNextAdvanced Feed ConfigurationLast updated 2 months ago","tokens":2164,"squid":"spider-08","role":"Oracle Spider","at":1791339876141,"hash":"b6ca034a34ad08095bab0eb2377de2e365b85281"}
{"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.4%Liquid Staked ETHLiquid StakingFeaturedAPY2.25%LendingSupply assets like WETH, USDC, and WBTC on Arbitrum lending markets to earn variable yield.Aave v3 WBTCWBTCarbitrum0.02%APYTVL$258.1M USDProtocolaaveProjected Earnings-Your Holdings-Aave v3 WETHWETHarbitrum1.09%APYTVL$254.3M USDProtocolaaveProjected Earnings-Your Holdings-Aave v3 USDCUSDCarbitrum3.15%APYTVL$182.9M USDProtocolaaveProjected Earnings-Your Holdings-NameTokenProtocolAave v3 WBTCWBTCArbitrum One0.02%--$258.1M USDaaveAave v3 WETHWETHArbitrum One1.09%--$254.3M USDaaveAave v3 USDCUSDCArbitrum One3.15%--$182.9M USDaaveFixed YieldAccess fixed-rate opportunities on Arbitrum through Pendle markets with a clear maturity date.USDaiUSDaiArbitrum11.4%APYTVL$92M USDProtocolPendleProjected Earnings-Your Holdings-sUSDaisUSDaiArbitrum13.07%APYTVL$63.7M USDProtocolPendleProjected Earnings-Your Holdings-sUSDaisUSDaiArbitrum10.06%APYTVL$6.9M USDProtocolPendleProjected Earnings-Your Holdings-NameTokenProtocolUSDai14 Oct 2026USDaiArbitrum One11.4%--$92M USDPendlesUSDai14 Oct 2026sUSDaiArbitrum One13.07%--$63.7M USDPendlesUSDai24 Feb 2027sUSDaiArbitrum One10.06%--$6.9M 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.25%APYTVL$26.5B USDProtocolLidoProjected Earnings-Your Holdings-Liquid Staked ETHweETHArbitrum One2.31%APYTVL$6.2B USDProtocolEther.fiProjected Earnings-Your Holdings-NameTokenProtocolLiquid Staked ETHwstETHArbitrum One2.25%--$26.5B USDLidoLiquid Staked ETHweETHArbitrum One2.31%--$6.2B USDEther.fi","tokens":423,"squid":"spider-01","role":"Chain Spider","at":1791339888959,"hash":"5c863d54424c1d98ebe2867cba2afe7f32160805"}
{"url":"https://docs.switchboard.xyz/docs-by-chain/iota","domain":"docs.switchboard.xyz","title":"Iota | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.Version source of truth: SDK Version MatrixActive DeploymentsThe Switchboard On-Demand service is currently deployed on the following networks:Mainnet: 0x8650249db8ffcffe8eb08b0696a8cb71e325f2afb9abc646f45344077b073ba1Testnet: 0xad9557529ba97ccf94a6a89d759fc8c8a6da5f0b98630c0fb53fe3b6d6a8e97aTypescript-SDK InstallationTo use Switchboard On-Demand, add the following dependencies to your project:NPMnpm install @switchboard-xyz/iota-sdk@0.0.3 @switchboard-xyz/common@5.8.5 @iota/iota-sdk@1.11.0 --saveBunbun add @switchboard-xyz/iota-sdk@0.0.3 @switchboard-xyz/common@5.8.5 @iota/iota-sdk@1.11.0PNPMpnpm add @switchboard-xyz/iota-sdk@0.0.3 @switchboard-xyz/common@5.8.5 @iota/iota-sdk@1.11.0Creating an Aggregator and Sending TransactionsBuilding a feed in Switchboard can be done using the Typescript SDK, or it can be done with the Switchboard Web App. Visit our docs for more on designing and creating feeds.Building Feedsimport {\n SwitchboardClient,\n Aggregator,\n} from \"@switchboard-xyz/iota-sdk\";\nimport { CrossbarClient, OracleJob } from \"@switchboard-xyz/common\";\nimport { getFullnodeUrl, IotaClient } from \"@iota/iota-sdk/client\";\nimport { Ed25519Keypair } from '@iota/iota-sdk/keypairs/ed25519';\nimport { Transaction } from '@iota/iota-sdk/transactions';\n\n// Add your Iota signer here\nconst keypair = new Ed25519Keypair();\nconst userAddress = keypair.getPublicKey().toIotaAddress();\nconst iotaClient = new IotaClient({\n url: getFullnodeUrl('testnet'),\n});\n\n// for initial testing and development, you can use the public\n// https://crossbar.switchboard.xyz instance of crossbar\nconst crossbarClient = new CrossbarClient(\"https://crossbar.switchboard.xyz\");\n\n// ... define some jobs ...\nconst jobs: OracleJob[] = [\n OracleJob.fromObject({\n tasks: [\n {\n httpTask: {\n url: \"https://binance.com/api/v3/ticker/price?symbol=BTCUSDT\",\n }\n },\n {\n jsonParseTask: {\n path: \"$.price\"\n }\n }\n ],\n }),\n];\n\n// Create a SwitchboardClient using the IotaClient configured with your favorite RPC on testnet or mainnet\nconst sb = new SwitchboardClient(iotaClient);\nconst state = await sb.fetchState();\nconst queue = state.oracleQueueId;\n\nconst { feedHash } = await crossbarClient.store(queue, jobs);\n\n// try creating a feed\nconst feedName = \"BTC/USDT\";\n\n// Require only one oracle response needed\nconst minSampleSize = 1;\n\n// Allow update data to be up to 60 seconds old\nconst maxStalenessSeconds = 60;\n\n// If jobs diverge more than 1%, don't allow the feed to produce a valid update\nconst maxVariance = 1e9; // 1%, scaled by 1e9 for this chain parameter\n\n// Require only 1 job response (unscaled count)\nconst minJobResponses = 1; // unscaled job/source quorum\n\n//==========================================================\n// Feed Initialization On-Chain\n//==========================================================\n\nlet transaction = new Transaction();\n\n// add the tx to the PTB\nawait Aggregator.initTx(sb, transaction, {\n feedHash,\n name: feedName,\n authority: userAddress,\n minSampleSize,\n maxStalenessSeconds,\n maxVariance,\n minResponses: minJobResponses,\n});\n\n// Send the transaction\nconst res = await iotaClient.signAndExecuteTransaction({\n signer: keypair,\n transaction,\n options: {\n showEffects: true,\n },\n});\n\n// Capture the created aggregator ID\nlet aggregatorId;\nres.effects?.created?.forEach((c: any) => {\n if (c.reference.objectId) {\n aggregatorId = c.reference.objectId;\n }\n});\n\n// Wait for transaction confirmation\nawait iotaClient.waitForTransaction({\n digest: res.digest,\n});\n\n// Log the transaction effects\nconsole.log(res);\nUpdating FeedsWith Switchboard On-Demand, passing the PTB into the feed update method handles the update automatically.const aggregator = new Aggregator(sb, aggregatorId);\n\n// Create the PTB transaction\nlet feedTx = new Transaction();\n\n// Fetch and log the oracle responses\nconst response = await aggregator.fetchUpdateTx(feedTx);\nconsole.log(\"Fetch Update Oracle Response: \", response);\n\n// Send the transaction\nconst res = await iotaClient.signAndExecuteTransaction({\n signer: keypair,\n transaction: feedTx,\n options: {\n showEffects: true,\n },\n});\n\n// Wait for transaction confirmation\nawait iotaClient.waitForTransaction({\n digest: res.digest,\n});\n\n// Log the transaction effects\nconsole.log({ aggregatorId, res });Note: Ensure the Switchboard Aggregator update is the first action in your PTB or occurs before referencing the feed update.Adding Switchboard to Move CodeTo integrate Switchboard with Move, add the following dependencies to Move.toml:[dependencies.Switchboard]\ngit = \"https://github.com/switchboard-xyz/iota.git\"\nsubdir = \"on_demand/\"\nrev = \"main\" \n\n[dependencies.Iota]\noverride = true\ngit = \"https://github.com/iotaledger/iota.git\"\nsubdir = \"crates/iota-framework/packages/iota-framework\"\nrev = \"framework/testnet\"Once dependencies are configured, updated aggregators can be referenced easily.Example Move Code for Using Switchboard ValuesIn the example.move module, use the Aggregator and CurrentResult types to access the latest feed data.module example::switchboard;\n\nuse switchboard::aggregator::{Aggregator, CurrentResult};\nuse switchboard::decimal::Decimal;\n\npublic entry fun use_switchboard_value(aggregator: &Aggregator) {\n\n // Get the latest update info for the feed\n let current_result = aggregator.current_result();\n\n // Access various result properties\n let result: Decimal = current_result.result(); // Median result\n let result_u128: u128 = result.value(); // Result as u128\n let min_timestamp_ms: u64 = current_result.min_timestamp_ms(); // Oldest data timestamp\n let max_timestamp_ms: u64 = current_result.max_timestamp_ms(); // Latest data timestamp\n let range: Decimal = current_result.range(); // Range of results\n let mean: Decimal = current_result.mean(); // Average (mean)\n let stdev: Decimal = current_result.stdev(); // Standard deviation\n let max_result: Decimal = current_result.max_result();// Max result\n let min_result: Decimal = current_result.min_result();// Min result\n let neg: bool = result.neg(); // Check if negative (ignore for prices)\n\n // Use the computed result as needed...\n}This implementation allows you to read and utilize Switchboard data feeds within Move. If you have any questions or need further assistance, please contact the Switchboard team.PreviousAptosNextMovementLast updated 2 months ago","tokens":1597,"squid":"spider-08","role":"Oracle Spider","at":1791339897988,"hash":"1012e9dfb79ff4a987de7a271b46006223d9f796"}
{"url":"https://squidfunk.github.io/mkdocs-material/setup/setting-up-site-search/","domain":"squidfunk.github.io","title":"Setting up site search - Material for MkDocs","text":"Setting up site search¶ Material for MkDocs provides an excellent client-side search implementation, omitting the need for the integration of third-party services, which might not be compliant with privacy regulations. Moreover, search even works offline, allowing users to download your documentation. Configuration¶ Built-in search plugin¶ 0.1.0 The built-in search plugin integrates seamlessly with Material for MkDocs, adding multilingual client-side search with lunr and lunr-languages. It's enabled by default, but must be re-added to mkdocs.yml when other plugins are used: plugins:\n - search\n For a list of all settings, please consult the plugin documentation. Search suggestions¶ 7.2.0 When search suggestions are enabled, the search will display the likeliest completion for the last word which can be accepted with the Right key. Add the following lines to mkdocs.yml: theme:\n features:\n - search.suggest\n Searching for search su yields search suggestions as a suggestion. Search highlighting¶ 7.2.0 When search highlighting is enabled and a user clicks on a search result, Material for MkDocs will highlight all occurrences after following the link. Add the following lines to mkdocs.yml: theme:\n features:\n - search.highlight\n Searching for code blocks highlights all occurrences of both terms. Search sharing¶ 7.2.0 When search sharing is activated, a share button is rendered next to the reset button, which allows to deep link to the current search query and result. Add the following lines to mkdocs.yml: theme:\n features:\n - search.share\n When a user clicks the share button, the URL is automatically copied to the clipboard. Usage¶ Search boosting¶ 8.3.0 Pages can be boosted in search with the front matter search.boost property, which will make them rank higher. Add the following lines at the top of a Markdown file: Rank up Rank down ---\nsearch:\n boost: 2 \n---\n\n# Page title\n...\n ---\nsearch:\n boost: 0.5\n---\n\n# Page title\n...\n Search exclusion¶ 9.0.0 Pages can be excluded from search with the front matter search.exclude property, removing them from the index. Add the following lines at the top of a Markdown file: ---\nsearch:\n exclude: true\n---\n\n# Page title\n...\n Excluding sections¶ When Attribute Lists is enabled, specific sections of pages can be excluded from search by adding the data-search-exclude pragma after a Markdown heading: docs/page.md search_index.json # Page title\n\n## Section 1\n\nThe content of this section is included\n\n## Section 2 { data-search-exclude }\n\nThe content of this section is excluded\n {\n ...\n \"docs\": [\n {\n \"location\":\"page/\",\n \"text\":\"\",\n \"title\":\"Document title\"\n },\n {\n \"location\":\"page/#section-1\",\n \"text\":\"<p>The content of this section is included</p>\",\n \"title\":\"Section 1\"\n }\n ]\n}\n Excluding blocks¶ When Attribute Lists is enabled, specific sections of pages can be excluded from search by adding the data-search-exclude pragma after a Markdown inline- or block-level element: docs/page.md search_index.json # Page title\n\nThe content of this block is included\n\nThe content of this block is excluded\n{ data-search-exclude }\n {\n ...\n \"docs\": [\n {\n \"location\":\"page/\",\n \"text\":\"<p>The content of this block is included</p>\",\n \"title\":\"Document title\"\n }\n ]\n}","tokens":806,"squid":"spider-06","role":"Security Spider","at":1791339911900,"hash":"e6e6ca90955062a7f76d7b17432994ae46090caf"}
{"url":"https://docs.switchboard.xyz/docs-by-chain/solana-svm","domain":"docs.switchboard.xyz","title":"Solana / SVM | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.Learn how to build and use programs that call existing Switchboard data feeds on Solana and other SVM platforms.If you need to create a custom data feed, check out the custom feeds section.AccountsAccount TypeAddressProgram IDSBondMDrcV3K4kxZR1HNVT7osZxAHVHgYXL5Ze1oMUvDevnet Program IDAio4gaXjXzJNVLtzwtNVmSqGKpANtXhybbkhtAC94ji2Surge/Oracle Quotesorac1eFjzWL5R3RbbdMV68K9H6TaCVVcL6LjvQQWAbzDefault Mainnet QueueA43DyUGA7s8eXPxqEjJY6EBu1KKbNgfxF8h17VAHn13wDefault Devnet QueueEYiAmGSdsQTuCw413V5BzaruWuCCSDgTPtBGvLkXHbe7PreviousQuick StartNextPrice FeedsLast updated 9 months ago","tokens":168,"squid":"spider-08","role":"Oracle Spider","at":1791339930992,"hash":"769f5154cb6bf73b20c1e3f1005dc8092ef08a9f"}
{"url":"https://forum.arbitrum.foundation/t/team-12-empowering-underrepresented-delegates/21533","domain":"forum.arbitrum.foundation","title":"Team 12: Empowering underrepresented delegates - Archive / GovHack Denver - Arbitrum","text":"The Arbitrum Foundation notified the Security Council on the need to perform a potential Emergency action. Following a review of the details and known risks, the Security Council decided to execute the upgrade and it was completed at 11:30 EST on 2nd October 2026.\nThis report provides an overview of the risks that required the Security Council Action:\n\nAdd a permissionless guard for the One-Step Proof of BoLD on Arbitrum One\n\nTemporarily pause activation of new Stylus contracts on Arbitrum One & Nova\n\nKey point: To date, known bugs for Stylus primarily impact chain liveness (e.g., denial of service attacks) and do not put any user funds at risk.\nWhy was this action taken\nLet’s take this opportunity to explain why action was taken on two separate issues concerning BoLD and Stylus.\nInstalling the guard for One-Step Proof of BoLD. Given the rise of AI-assisted attacks, we have implemented a precautionary approach that allows anyone to pause settlement of Arbitrum One on Ethereum if there are at least two conflicting answers that pass at the same level in which only one should be valid and pass. This is to halt a class of publicly verifiable and detectable attacks that exploit a bug in the one-step proof. If halted, Arbitrum One will continue to process as normal except that messages from Arbitrum One to Ethereum, such as withdrawals, that are not yet confirmed will have to wait. This provides time for the Security Council to deploy a fix for the bug and resume the rollup.\nPreventing activation of new Stylus contracts. AI-assisted tooling has led to an increasing number of sophisticated attacks on hand-crafted WASM programs that do not use the standard Stylus compiler toolchain. These programs are specifically designed to cause unexpected behaviors such as degrading the chain’s performance for all other users. To date, no attacks have been discovered that permits theft of user funds.\nNew ArbOS releases have patched several reported bugs and known attacks over the past few months, but out of an abundance of caution, we have decided to temporarily pause new activations of Stylus contracts. This was executed as an emergency action to prevent the deployment of new hand-crafted WASM programs that are not yet patched by the current version of ArbOS on the Arbitrum network.\nThe Arbitrum Foundation has informed the Security Council that they will work with the ArbitrumDAO to discuss next steps on the timeline and manner for enabling activation of new Stylus contracts. The Arbitrum community remains confident in the value of Stylus and want to preserve these use cases while taking preventative measures against Stylus-based attack vectors as AI-assisted attack tooling continues to evolve.\nImpact on builders and users\n\nNo new activations. New Stylus contracts cannot be activated during the pause including new versions of existing applications that require activation.\n\nExisting contracts are not paused. Already-active Stylus contracts continue to execute until expiration. This pause does not deactivate them.\n\nThe ArbOS 61 upgrade renewed all active contracts on Arbitrum One, so no currently active contract expires before August 20, 2027.\n\nRenewal via keepalive stays permissionless and is unaffected by the pause.\n\nReactivating an expired contract, or one that needs to be updated after a Stylus version change, is paused.\n\nUsing/calling any activated Stylus contract stays permissionless for all users and developers.\n\nNo impact on EVM. Solidity (EVM) contract deployment and execution are unaffected by this Security Council action.\n\nSecurity Council Actions\nThere are two actions bundled into a single payload:\n\nOne-Step Proof Guard. The L1UpgradeExecutor gives a new pause contract (PauseExecutor) the ability to pause and nothing else. The new pause contract grants the guard (OspSoundnessGuard) PAUSER_ROLE to use it. Anyone can show the guard two conflicting answers to the same step of an open challenge. If the one-step proof accepts both, the guard has the pause contract put Arbitrum One’s settlement to Ethereum on hold.\n\nStylus deactivation. The Security Council called ArbOwner.setWasmActivationGas(2^64 - 1) to raise the Stylus activation gas requirement on Arbitrum One and Nova. This makes activation prohibitively expensive and effectively disables new activations. This is a configuration change and does not require an ArbOS upgrade.\n\nThe Security Council signed the following transactions to update the configuration:\n\nEthereum: Ethereum Transaction Hash: 0x30732bb7d2... | Etherscan\nArbitrum One:\nArbitrum One Transaction Hash: 0x9eb3a4be3b... | Arbitrum One\nArbitrum Nova:\nArbitrum Nova transaction 0x79e0fed470dff7a22059b108e3f8f42eddd2b580a6771594060c4e7326c5f984 | Blockscout\n\nAn external audit was conducted for the OSP Guard contracts. No audit is required for the Stylus deactivation as it is only updating a single parameter in the ArbOS configuration.\n\n Team 12: Empowering underrepresented delegates \n\n ArchiveGovHack Denver\n\n contributor-onboardi\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Feb 2024\n\n 1 / 5\n\n Feb 2024\n\n Mar 2024\n\n post by EventHorizonDAO on Feb 27, 2024\n\n EventHorizonDAO\n\n Arbitrum GovHack Track:\nContributor onboarding, activation & engagement\nChallenge Statement:\nDelegation proportionate to participation.\nMembers:\n404DAO\nEvent Horizon\nMatt Fiebach\nJengajojo (DAOStewards)\nNon-constitutional\nThis proposal has taken influence from a proposal created by Stable Lab in Uniswap DAO and we thank them for their inspiration.\nTL;DR\nThis proposal seeks to increase participation in the DAO by empowering underrepresented delegates who, despite active participation in governance, do not have sufficient voting power to have their ideas seriously considered. Since greater voting power often correlates with heightened attention by the DAO’s key stakeholders, we propose creating a DAO-controlled Franchiser contract and distributing 1M in ARB each of up to 10 delegates who 1) currently have between 50,000 and 1,000,000 in voting power, 2) have shown an onchain voting participation rate >80% in the last 3 months and 3) have been voted as the top 10 delegates of these candidates by the DAO voted on in a Snapshot poll.\nAbstract\nWe ask the DAO to run a 1-year trial program that delegates $ARB to Active Delegates who are underrepresented in governance. If this proposal passes, the foundation will create a Franchiser contract to technically allow for this process. The DAO will maintain control of all $ARB allocated to the program, and have the ability to clawback delegations through an onchain proposal at any time. The contract is owned by the DAO and the tokens are delegated, not granted, but never leave the contract or DAO treasury in practice. Rather, they are stored in a new DAO-owned address.\nBy allocating 1M $ARB each to up to 10 delegates with between 50k-1m $ARB who have voted on >80% of onchain proposals in the last 3 months, the DAO will empower more meaningful voices in its proposals. A quarterly Active Delegate refresh is encouraged to maintain accountability of those who have been allocated delegation and give newly qualified delegates a chance to participate. The proposal will also give more delegates the ability to propose Snapshot votes and further diversify the makeup of the DAO. Snapshots have a threshold of 500K ARB and onchain proposals 1M to propose.\nMotivation\nDuring Arbitrum’s GovHack hackathon, the challenge statement of “Delegation proportionate to participation” emerged as a key challenge for the DAO. Furthermore, the community has sought creative ways to leverage delegation, rather than grants, to boost voter participation and encourage meaningful contributions (see this, this, and this).\nCurrently, there are a group of delegates who have demonstrated a commitment to governance through consistent participation in on-chain governance. However, despite their active involvement, they are significantly marginalized in terms of voting power. Since greater voting power often correlates with heightened attention from delegates and the community, we believe that boosting the voting power of these delegates will enable them to have their ideas seriously considered, creating a more robust idea generation and iteration pipeline. Within the DAO, a higher allocation of voting power not only empowers individuals to propose initiatives but also garners increased attention from active delegates and community members.\nMany of Arbitrum’s key delegates holding substantial voting rights participate in fewer votes than smaller delegate counterparts. This is evidenced by the observation that many recipients of sizable delegations have shown minimal participation in governance activities. In an effective DAO, engaged delegates play a critical role by exercising their substantial voting rights. Giving smaller delegates who have shown rigor in their activity a more meaningful voice and voting power in the DAO will help toward this overarching goal.\nEligibility\nActive delegate voters with the following qualifications can be considered for the program:\n\n80% participation over the last 3 months on Tally\n50,000 to 1,000,000 $ARB voting power\n\nData\nOver the last 3 months there have been 6 onchain proposals that count and a delegate must have voted on at least 5 in order to qualify. 25 addresses currently qualify.\nScreenshot 2024-02-27 at 14.18.521216×1328 146 KB\nQualified applicants must self nominate themselves to be considered.\nNext Steps\n\nWe encourage the community to leave comments and feedback on this forum post\nProject managers will create a snapshot vote so that the DAO can signal approval or disapproval for the program.\nStart working on deployment of Franchiser Contract\nUpon successful Snapshot #1, program managers will create a forum post for nominations\nQualified delegates to nominate themselves on post within 7-days.\nProject managers post this proposal to a Snapshot vote for 7 days during which time delegates will vote on the top 10 applicants to be included in the program. Encrypted weighted voting.\nAfter the Snapshot vote ends, we will post the proposal to Tally for an on-chain vote and delegation executable.\n\nFollowing self-nomination to receive delegation, a Snapshot vote will go live so that the DAO may decide which delegates (up to 10) should be included in the program.\nTechnical Implementation\nIn order to implement this proposal, it is required that we create a DAO-controlled Franchiser contract. The contract owner would be the DAO timelock and it would allow the DAO the power to delegate and undelegate tokens that it sends from the treasury to the Franchiser. We suggest that the Foundation aids in the creation of this contract in order to create an official and safe implementation, though we can likely fork the Trail of Bits audited Uniswap Labs implementation [github] of the same concept. If this proposal passes Snapshot, we request that the Foundation take the time to fork the contract and hire an auditor to check the implementation.\nThe contract has simple functions:\n-Fund: allows the DAO to send tokens to contract and delegate to a single address\n-FundMany: allows the DAO to send tokens to contract and delegate any amount to multiple addresses\n-Recall: allows DAO to pull back funds from Franchiser effectively undelegating and returning tokens to treasury from a single delegate.\n-RecallMany: allows DAO to pull back funds from franchiser effectively undelegating and returning tokens to treasury from multiple delegates.\nIt is worth noting that all tokens sent to the Franchiser will remain a part of the DAO’s balance sheet as it has full-control over the contract. The delegated tokens never leave the DAO’s ownership.\nTimeline\n\nForum feedback 1 week\n(optional) Repost on forum incase there are major changes requested: 1 week\nSnapshot vote 1 week\nWork with foundation to deploy contracts: 1 month\nOnchain vote: 3 weeks\nFirst quarterly report: 3 months\nSecond quarterly report: 3 months\nThird quarterly report: 3 months\nFinal quarterly report: 3 months\n\nProgram Administration\nThis working group will project admin this program. The specific deliverables include:\n\nWork with the foundation for contract creation and deployment\nCreate quarterly reports on delegate performance so that the DAO may have a resource to hold delegates accountable\nIn the event that a chosen delegate falls below 80%, communicate with the DAO and put up a vote to revoke their delegation\n\nNote: This is not a position of power, just a project management work which is limited to the above executables\nWe will create a 3 of 4 multi-sig governed by the proposers paid upfront if the proposal passes onchain voting.\nSigners:\n-Jengajojo (DAOStewards)\n-404 DAO (Cole Schendl & Rika Goldberg)\n-Event Horizon\n-Matt Fiebach\nOverall Cost\n\nUp to 10M ARB to be transferred into the Franchiser contract, still owned by the DAO (no cost)\n$15,000 in ARB for program management and reporting for 1 year\n\nConsiderations:\n\nWe want to encourage members of the DAO to review the program and consider removal or addition of delegates to the program quarterly\nIf this program goes well, the DAO should consider iterating on the active delegate criteria, number of votes to be delegated and interval in which the delegation is refreshed.\nThe Franchiser contract will enable use cases beyond just this program. For example, the foundation may opt to temporarily delegate tokens so that any entity can make a snapshot/onchain proposal. It may be used in further programs to give delegations from the Treasury. It will allow one address to delegate its token across many delegates (though the DAO will maintain ownership as well).\n\nVideo link\n\n Delegate to a public access, public good citizen enfranchisement pool through Event Horizon\n\n read \n\n 4\n min\n\n post by MattOnChain on Feb 27, 2024\n\n Closed on Feb 27, 2024\n\n Opened on Feb 27, 2024\n\n 12 days later\n\n post by Tane on Mar 10, 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 [RFC] Empowering Underrepresented Delegates\n\n Archived Proposals\n\n proposal\n\n 35\n\n 2.1k\n\n May 2025\n\n Arbitrum DAO’s Delegate Engagement Apathy Determent program (Arb DAO DEAD Program) - Pilot \n\n Voting Rationale & Governance Calls\n\n 13\n\n 458\n\n Dec 2024\n\n [Request for Support] Empowering Underrepresented Delegates Proposal\n\n ARDC DAO Advocate (old)\n\n 3\n\n 8.0k\n\n Sep 2025\n\n [DIP v1.0]From Engagement to Rewards: A Comprehensive Analysis of Participation and Incentives\n\n Delegate Incentives Program (DIP)\n\n 8\n\n 582\n\n Aug 2024\n\n Non-Constitutional: Amendment to the Delegate Incentives Program\n\n Archived Proposals\n\n 55\n\n 1.6k\n\n Feb 2025","tokens":3680,"squid":"spider-07","role":"Council Spider","at":1791339945634,"hash":"01e8e48bf570d1b54b0370604c1c7f528b3cec47"}
{"url":"https://jup.ag/lend/earn/JupUSD/deposit","domain":"jup.ag","title":"Earn Yield on Crypto: Lend Tokens on Solana | Jupiter Lend","text":"Jupiter LendThe most advanced money market on SolanaOur new sUSDai loop is now live. Earn up to 27.15% at max leverage View loop Earn Interest on Your CryptoPassively get yield using Jupiter Lend's Earning Vaults.$614MVaultDepositedEarningsTVLJupUSD----49.8M JupUSD$49.8MUSDC----512M USDC$512MSOL----201K SOL$23.7MUSDT----17.9M USDT$17.9MEURC----4.77M EURC$5,363,364.08USDS----2.98M USDS$2,984,319.40USDG----2.76M USDG$2,764,662.77FAQsJupiter Lend is Jupiter's decentralized finance (DeFi) platform for lending and borrowing crypto. It allows you to use your assets in two main ways:Earn: You can deposit your crypto to lend it out to others and earn passive interest.Borrow: You can use the assets you've deposited as collateral to take out a loan.Jupiter Lend is designed to automatically find the best interest rates for you, whether you are earning or borrowing.Earning and borrowing are two sides of the same system. The \"Earn\" section is for users who want to supply assets to earn interest.The \"Borrow\" section is for users who want to use their supplied assets as collateral to take out a loan.When you supply an asset for lending, you will automatically earn the best possible rate. Supply once and get the best yield, no extra steps needed.Depositing: There are no limits on how much you can deposit.Withdrawing: To ensure Jupiter Lend remains stable and healthy for everyone, there are dynamic limits on how much can be withdrawn at any single moment. These limits grow constantly, allowing for smooth and predictable withdrawals while protecting the system from sudden, large outflows.Like all DeFi platforms, lending and borrowing on-chain has risks. The primary risks are:Smart Contract Risk: The potential for a bug or vulnerability in the code that could be exploited.Market Risk: The value of your deposited or borrowed assets could change dramatically due to market volatility. This is especially important for borrowers, as a drop in your collateral's value could lead to liquidation.Please use this product carefully and never deposit more than you are willing to lose.Check JupLend Guides","tokens":527,"squid":"spider-02","role":"Liquidity Spider","at":1791339953183,"hash":"09bb7976e5936d568fd30f3294a0d112cfc3a3d4"}
{"url":"https://forum.arbitrum.foundation/t/team-12-empowering-underrepresented-delegates/21533/1","domain":"forum.arbitrum.foundation","title":"Team 12: Empowering underrepresented delegates - Archive / GovHack Denver - Arbitrum","text":"The Arbitrum Foundation notified the Security Council on the need to perform a potential Emergency action. Following a review of the details and known risks, the Security Council decided to execute the upgrade and it was completed at 11:30 EST on 2nd October 2026.\nThis report provides an overview of the risks that required the Security Council Action:\n\nAdd a permissionless guard for the One-Step Proof of BoLD on Arbitrum One\n\nTemporarily pause activation of new Stylus contracts on Arbitrum One & Nova\n\nKey point: To date, known bugs for Stylus primarily impact chain liveness (e.g., denial of service attacks) and do not put any user funds at risk.\nWhy was this action taken\nLet’s take this opportunity to explain why action was taken on two separate issues concerning BoLD and Stylus.\nInstalling the guard for One-Step Proof of BoLD. Given the rise of AI-assisted attacks, we have implemented a precautionary approach that allows anyone to pause settlement of Arbitrum One on Ethereum if there are at least two conflicting answers that pass at the same level in which only one should be valid and pass. This is to halt a class of publicly verifiable and detectable attacks that exploit a bug in the one-step proof. If halted, Arbitrum One will continue to process as normal except that messages from Arbitrum One to Ethereum, such as withdrawals, that are not yet confirmed will have to wait. This provides time for the Security Council to deploy a fix for the bug and resume the rollup.\nPreventing activation of new Stylus contracts. AI-assisted tooling has led to an increasing number of sophisticated attacks on hand-crafted WASM programs that do not use the standard Stylus compiler toolchain. These programs are specifically designed to cause unexpected behaviors such as degrading the chain’s performance for all other users. To date, no attacks have been discovered that permits theft of user funds.\nNew ArbOS releases have patched several reported bugs and known attacks over the past few months, but out of an abundance of caution, we have decided to temporarily pause new activations of Stylus contracts. This was executed as an emergency action to prevent the deployment of new hand-crafted WASM programs that are not yet patched by the current version of ArbOS on the Arbitrum network.\nThe Arbitrum Foundation has informed the Security Council that they will work with the ArbitrumDAO to discuss next steps on the timeline and manner for enabling activation of new Stylus contracts. The Arbitrum community remains confident in the value of Stylus and want to preserve these use cases while taking preventative measures against Stylus-based attack vectors as AI-assisted attack tooling continues to evolve.\nImpact on builders and users\n\nNo new activations. New Stylus contracts cannot be activated during the pause including new versions of existing applications that require activation.\n\nExisting contracts are not paused. Already-active Stylus contracts continue to execute until expiration. This pause does not deactivate them.\n\nThe ArbOS 61 upgrade renewed all active contracts on Arbitrum One, so no currently active contract expires before August 20, 2027.\n\nRenewal via keepalive stays permissionless and is unaffected by the pause.\n\nReactivating an expired contract, or one that needs to be updated after a Stylus version change, is paused.\n\nUsing/calling any activated Stylus contract stays permissionless for all users and developers.\n\nNo impact on EVM. Solidity (EVM) contract deployment and execution are unaffected by this Security Council action.\n\nSecurity Council Actions\nThere are two actions bundled into a single payload:\n\nOne-Step Proof Guard. The L1UpgradeExecutor gives a new pause contract (PauseExecutor) the ability to pause and nothing else. The new pause contract grants the guard (OspSoundnessGuard) PAUSER_ROLE to use it. Anyone can show the guard two conflicting answers to the same step of an open challenge. If the one-step proof accepts both, the guard has the pause contract put Arbitrum One’s settlement to Ethereum on hold.\n\nStylus deactivation. The Security Council called ArbOwner.setWasmActivationGas(2^64 - 1) to raise the Stylus activation gas requirement on Arbitrum One and Nova. This makes activation prohibitively expensive and effectively disables new activations. This is a configuration change and does not require an ArbOS upgrade.\n\nThe Security Council signed the following transactions to update the configuration:\n\nEthereum: Ethereum Transaction Hash: 0x30732bb7d2... | Etherscan\nArbitrum One:\nArbitrum One Transaction Hash: 0x9eb3a4be3b... | Arbitrum One\nArbitrum Nova:\nArbitrum Nova transaction 0x79e0fed470dff7a22059b108e3f8f42eddd2b580a6771594060c4e7326c5f984 | Blockscout\n\nAn external audit was conducted for the OSP Guard contracts. No audit is required for the Stylus deactivation as it is only updating a single parameter in the ArbOS configuration.\n\n Team 12: Empowering underrepresented delegates \n\n ArchiveGovHack Denver\n\n contributor-onboardi\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Feb 2024\n\n 1 / 5\n\n Feb 2024\n\n Mar 2024\n\n post by EventHorizonDAO on Feb 27, 2024\n\n EventHorizonDAO\n\n Arbitrum GovHack Track:\nContributor onboarding, activation & engagement\nChallenge Statement:\nDelegation proportionate to participation.\nMembers:\n404DAO\nEvent Horizon\nMatt Fiebach\nJengajojo (DAOStewards)\nNon-constitutional\nThis proposal has taken influence from a proposal created by Stable Lab in Uniswap DAO and we thank them for their inspiration.\nTL;DR\nThis proposal seeks to increase participation in the DAO by empowering underrepresented delegates who, despite active participation in governance, do not have sufficient voting power to have their ideas seriously considered. Since greater voting power often correlates with heightened attention by the DAO’s key stakeholders, we propose creating a DAO-controlled Franchiser contract and distributing 1M in ARB each of up to 10 delegates who 1) currently have between 50,000 and 1,000,000 in voting power, 2) have shown an onchain voting participation rate >80% in the last 3 months and 3) have been voted as the top 10 delegates of these candidates by the DAO voted on in a Snapshot poll.\nAbstract\nWe ask the DAO to run a 1-year trial program that delegates $ARB to Active Delegates who are underrepresented in governance. If this proposal passes, the foundation will create a Franchiser contract to technically allow for this process. The DAO will maintain control of all $ARB allocated to the program, and have the ability to clawback delegations through an onchain proposal at any time. The contract is owned by the DAO and the tokens are delegated, not granted, but never leave the contract or DAO treasury in practice. Rather, they are stored in a new DAO-owned address.\nBy allocating 1M $ARB each to up to 10 delegates with between 50k-1m $ARB who have voted on >80% of onchain proposals in the last 3 months, the DAO will empower more meaningful voices in its proposals. A quarterly Active Delegate refresh is encouraged to maintain accountability of those who have been allocated delegation and give newly qualified delegates a chance to participate. The proposal will also give more delegates the ability to propose Snapshot votes and further diversify the makeup of the DAO. Snapshots have a threshold of 500K ARB and onchain proposals 1M to propose.\nMotivation\nDuring Arbitrum’s GovHack hackathon, the challenge statement of “Delegation proportionate to participation” emerged as a key challenge for the DAO. Furthermore, the community has sought creative ways to leverage delegation, rather than grants, to boost voter participation and encourage meaningful contributions (see this, this, and this).\nCurrently, there are a group of delegates who have demonstrated a commitment to governance through consistent participation in on-chain governance. However, despite their active involvement, they are significantly marginalized in terms of voting power. Since greater voting power often correlates with heightened attention from delegates and the community, we believe that boosting the voting power of these delegates will enable them to have their ideas seriously considered, creating a more robust idea generation and iteration pipeline. Within the DAO, a higher allocation of voting power not only empowers individuals to propose initiatives but also garners increased attention from active delegates and community members.\nMany of Arbitrum’s key delegates holding substantial voting rights participate in fewer votes than smaller delegate counterparts. This is evidenced by the observation that many recipients of sizable delegations have shown minimal participation in governance activities. In an effective DAO, engaged delegates play a critical role by exercising their substantial voting rights. Giving smaller delegates who have shown rigor in their activity a more meaningful voice and voting power in the DAO will help toward this overarching goal.\nEligibility\nActive delegate voters with the following qualifications can be considered for the program:\n\n80% participation over the last 3 months on Tally\n50,000 to 1,000,000 $ARB voting power\n\nData\nOver the last 3 months there have been 6 onchain proposals that count and a delegate must have voted on at least 5 in order to qualify. 25 addresses currently qualify.\nScreenshot 2024-02-27 at 14.18.521216×1328 146 KB\nQualified applicants must self nominate themselves to be considered.\nNext Steps\n\nWe encourage the community to leave comments and feedback on this forum post\nProject managers will create a snapshot vote so that the DAO can signal approval or disapproval for the program.\nStart working on deployment of Franchiser Contract\nUpon successful Snapshot #1, program managers will create a forum post for nominations\nQualified delegates to nominate themselves on post within 7-days.\nProject managers post this proposal to a Snapshot vote for 7 days during which time delegates will vote on the top 10 applicants to be included in the program. Encrypted weighted voting.\nAfter the Snapshot vote ends, we will post the proposal to Tally for an on-chain vote and delegation executable.\n\nFollowing self-nomination to receive delegation, a Snapshot vote will go live so that the DAO may decide which delegates (up to 10) should be included in the program.\nTechnical Implementation\nIn order to implement this proposal, it is required that we create a DAO-controlled Franchiser contract. The contract owner would be the DAO timelock and it would allow the DAO the power to delegate and undelegate tokens that it sends from the treasury to the Franchiser. We suggest that the Foundation aids in the creation of this contract in order to create an official and safe implementation, though we can likely fork the Trail of Bits audited Uniswap Labs implementation [github] of the same concept. If this proposal passes Snapshot, we request that the Foundation take the time to fork the contract and hire an auditor to check the implementation.\nThe contract has simple functions:\n-Fund: allows the DAO to send tokens to contract and delegate to a single address\n-FundMany: allows the DAO to send tokens to contract and delegate any amount to multiple addresses\n-Recall: allows DAO to pull back funds from Franchiser effectively undelegating and returning tokens to treasury from a single delegate.\n-RecallMany: allows DAO to pull back funds from franchiser effectively undelegating and returning tokens to treasury from multiple delegates.\nIt is worth noting that all tokens sent to the Franchiser will remain a part of the DAO’s balance sheet as it has full-control over the contract. The delegated tokens never leave the DAO’s ownership.\nTimeline\n\nForum feedback 1 week\n(optional) Repost on forum incase there are major changes requested: 1 week\nSnapshot vote 1 week\nWork with foundation to deploy contracts: 1 month\nOnchain vote: 3 weeks\nFirst quarterly report: 3 months\nSecond quarterly report: 3 months\nThird quarterly report: 3 months\nFinal quarterly report: 3 months\n\nProgram Administration\nThis working group will project admin this program. The specific deliverables include:\n\nWork with the foundation for contract creation and deployment\nCreate quarterly reports on delegate performance so that the DAO may have a resource to hold delegates accountable\nIn the event that a chosen delegate falls below 80%, communicate with the DAO and put up a vote to revoke their delegation\n\nNote: This is not a position of power, just a project management work which is limited to the above executables\nWe will create a 3 of 4 multi-sig governed by the proposers paid upfront if the proposal passes onchain voting.\nSigners:\n-Jengajojo (DAOStewards)\n-404 DAO (Cole Schendl & Rika Goldberg)\n-Event Horizon\n-Matt Fiebach\nOverall Cost\n\nUp to 10M ARB to be transferred into the Franchiser contract, still owned by the DAO (no cost)\n$15,000 in ARB for program management and reporting for 1 year\n\nConsiderations:\n\nWe want to encourage members of the DAO to review the program and consider removal or addition of delegates to the program quarterly\nIf this program goes well, the DAO should consider iterating on the active delegate criteria, number of votes to be delegated and interval in which the delegation is refreshed.\nThe Franchiser contract will enable use cases beyond just this program. For example, the foundation may opt to temporarily delegate tokens so that any entity can make a snapshot/onchain proposal. It may be used in further programs to give delegations from the Treasury. It will allow one address to delegate its token across many delegates (though the DAO will maintain ownership as well).\n\nVideo link\n\n Delegate to a public access, public good citizen enfranchisement pool through Event Horizon\n\n read \n\n 4\n min\n\n post by MattOnChain on Feb 27, 2024\n\n MattOnChain\n\n Seems like our proposal, particularly the franchiser aspect, could be a good use of the ARDC security member to audit!\n\n Closed on Feb 27, 2024\n\n Opened on Feb 27, 2024\n\n 12 days later\n\n post by Tane on Mar 10, 2024\n\n Tane\n\n Hi Christian and other contributors to this proposal. Excited to see the comprehensive proposal like this came out from the GovHack!\n\nAlready told some members in your team, but we believe that lowering the minimum voting power to be qualified for the program would suit the purpose of the proposal: “empowering under-represented delegates” since the delegates with over 50k VP will be incentivized by the new program led by SEED Latam team.\n\n [RFC] Empowering Underrepresented Delegates\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [RFC] Empowering Underrepresented Delegates\n\n Archived Proposals\n\n proposal\n\n 35\n\n 2.1k\n\n May 2025\n\n Arbitrum DAO’s Delegate Engagement Apathy Determent program (Arb DAO DEAD Program) - Pilot \n\n Voting Rationale & Governance Calls\n\n 13\n\n 458\n\n Dec 2024\n\n [Request for Support] Empowering Underrepresented Delegates Proposal\n\n ARDC DAO Advocate (old)\n\n 3\n\n 8.0k\n\n Sep 2025\n\n [DIP v1.0]From Engagement to Rewards: A Comprehensive Analysis of Participation and Incentives\n\n Delegate Incentives Program (DIP)\n\n 8\n\n 582\n\n Aug 2024\n\n Non-Constitutional: Amendment to the Delegate Incentives Program\n\n Archived Proposals\n\n 55\n\n 1.6k\n\n Feb 2025","tokens":3838,"squid":"spider-07","role":"Council Spider","at":1791339959793,"hash":"79b61e2e67202350631d6535768713ab4560fbe7"}
{"url":"https://forum.arbitrum.foundation/c/archive/43","domain":"forum.arbitrum.foundation","title":"Latest Archive topics - Arbitrum","text":"The Arbitrum Foundation notified the Security Council on the need to perform a potential Emergency action. Following a review of the details and known risks, the Security Council decided to execute the upgrade and it was completed at 11:30 EST on 2nd October 2026.\nThis report provides an overview of the risks that required the Security Council Action:\n\nAdd a permissionless guard for the One-Step Proof of BoLD on Arbitrum One\n\nTemporarily pause activation of new Stylus contracts on Arbitrum One & Nova\n\nKey point: To date, known bugs for Stylus primarily impact chain liveness (e.g., denial of service attacks) and do not put any user funds at risk.\nWhy was this action taken\nLet’s take this opportunity to explain why action was taken on two separate issues concerning BoLD and Stylus.\nInstalling the guard for One-Step Proof of BoLD. Given the rise of AI-assisted attacks, we have implemented a precautionary approach that allows anyone to pause settlement of Arbitrum One on Ethereum if there are at least two conflicting answers that pass at the same level in which only one should be valid and pass. This is to halt a class of publicly verifiable and detectable attacks that exploit a bug in the one-step proof. If halted, Arbitrum One will continue to process as normal except that messages from Arbitrum One to Ethereum, such as withdrawals, that are not yet confirmed will have to wait. This provides time for the Security Council to deploy a fix for the bug and resume the rollup.\nPreventing activation of new Stylus contracts. AI-assisted tooling has led to an increasing number of sophisticated attacks on hand-crafted WASM programs that do not use the standard Stylus compiler toolchain. These programs are specifically designed to cause unexpected behaviors such as degrading the chain’s performance for all other users. To date, no attacks have been discovered that permits theft of user funds.\nNew ArbOS releases have patched several reported bugs and known attacks over the past few months, but out of an abundance of caution, we have decided to temporarily pause new activations of Stylus contracts. This was executed as an emergency action to prevent the deployment of new hand-crafted WASM programs that are not yet patched by the current version of ArbOS on the Arbitrum network.\nThe Arbitrum Foundation has informed the Security Council that they will work with the ArbitrumDAO to discuss next steps on the timeline and manner for enabling activation of new Stylus contracts. The Arbitrum community remains confident in the value of Stylus and want to preserve these use cases while taking preventative measures against Stylus-based attack vectors as AI-assisted attack tooling continues to evolve.\nImpact on builders and users\n\nNo new activations. New Stylus contracts cannot be activated during the pause including new versions of existing applications that require activation.\n\nExisting contracts are not paused. Already-active Stylus contracts continue to execute until expiration. This pause does not deactivate them.\n\nThe ArbOS 61 upgrade renewed all active contracts on Arbitrum One, so no currently active contract expires before August 20, 2027.\n\nRenewal via keepalive stays permissionless and is unaffected by the pause.\n\nReactivating an expired contract, or one that needs to be updated after a Stylus version change, is paused.\n\nUsing/calling any activated Stylus contract stays permissionless for all users and developers.\n\nNo impact on EVM. Solidity (EVM) contract deployment and execution are unaffected by this Security Council action.\n\nSecurity Council Actions\nThere are two actions bundled into a single payload:\n\nOne-Step Proof Guard. The L1UpgradeExecutor gives a new pause contract (PauseExecutor) the ability to pause and nothing else. The new pause contract grants the guard (OspSoundnessGuard) PAUSER_ROLE to use it. Anyone can show the guard two conflicting answers to the same step of an open challenge. If the one-step proof accepts both, the guard has the pause contract put Arbitrum One’s settlement to Ethereum on hold.\n\nStylus deactivation. The Security Council called ArbOwner.setWasmActivationGas(2^64 - 1) to raise the Stylus activation gas requirement on Arbitrum One and Nova. This makes activation prohibitively expensive and effectively disables new activations. This is a configuration change and does not require an ArbOS upgrade.\n\nThe Security Council signed the following transactions to update the configuration:\n\nEthereum: Ethereum Transaction Hash: 0x30732bb7d2... | Etherscan\nArbitrum One:\nArbitrum One Transaction Hash: 0x9eb3a4be3b... | Arbitrum One\nArbitrum Nova:\nArbitrum Nova transaction 0x79e0fed470dff7a22059b108e3f8f42eddd2b580a6771594060c4e7326c5f984 | Blockscout\n\nAn external audit was conducted for the OSP Guard contracts. No audit is required for the Stylus deactivation as it is only updating a single parameter in the ArbOS configuration.\n\n Latest topics in Archive\n\n Archive\n\n subcategories\n\n tags\n\n Latest\n\n Top\n\n Delegate Incentives Program (DIP)\n\n DIP v1.7 Final Report: From Engagement to Rewards: A Comprehensive Analysis of the Delegate Incentives Program (May - October 2025)\n\n [DIP v1.7]Delegate Incentive Program: Payment Distribution Thread\n\n [DIP v1.7] Delegate Incentive Program Results (October 2025)\n\n Strategic Objective Settings (SOS)\n\n [SOS Submission] {Merged: TBD} – Strategic Objectives\n\n SOS Workshops: Notes and Discussion\n\n SOS - Initiation Announcement Feb ‘25\n\n Firestarters\n\n Arbitrum Yield & Risk Intelligence Layer by TID Research\n\n DAO Stablecoin Revenue Research: Sequencer Fee Attribution & Non-USD Opportunity Analysis\n\n Arbitrum DAO Contributor Program: Validation Research Report\n\n DAO Event Budget\n\n Any plans by the Arbitrum DAO for DevCon 2025?\n\n Application Template to Utilize Funds from the DAO Events Budget\n\n Sales Pitch by Service Providers\n\n Independent verification review of Arbitrum — 17 onchain checks, credit-first\n\n AIE - Wallet Insight | Multichain Wallet Analysis - Full Public Case Study\n\n [PROPOSAL] Nexus Watch by VeriOmnion: Real-Time Financial Integrity & Institutional Signal\n\n Guides & Documentation\n\n Writing Your First Proposal to the ArbitrumDAO\n\n Karma - Track forum contributions by linking your wallet\n\n ArbitrumDAO Multi-Sig Best Practices\n\n Short Term Incentives Program (STIP) Round 2\n\n STIP Announcement: Multisig Returns Leftover Funds\n\n Learnings from STIP: Community Interview Summaries and Notes\n\n [Arbitrum Android Mobile App] [FINAL] [STIP - Round 2]\n\n Governance Discussion\n\n The Patchwork Model - A Visual Deliberation System for Decentralized Communities\n\n SYND airdrop to Arbitrum\n\n Proposal: Institutional $ARB Buyback via Bond Issuance\n\n Report Misuse of Funds\n\n Potential Misuse of Funds - Furucombo\n\n Serious People: STIP case study - Beyond Incentives: Ensuring Long-term TVL Retention\n\n Furucombo Used Arbitrum Grants to Incentivize Stealing User Funds\n\n STEP Applications & Updates\n\n OpenEden $TBILL STEP Application\n\n STEP 2 Committee Preferred Allocations\n\n STEP Report - June 2025\n\n ArbitrumDAO Procurement Committee (ADPC)\n\n Request for Proposal - RPC Service Providers Panel and Procurement Framework\n\n ADPC Outcome Report for Phase II\n\n ADPC Update Thread (Phase II)\n\n Multi-Sig Support Service (MSS) Updates\n\n MSS for Arbitrum - Communication Thread (Arbitrum Multisig Support Service)\n\n Arbitrum Multi-sig Support Service (MSS) Nomination Thread\n\n ThankARB by Thrive (prev Plurality Labs)\n\n Arbitrum Treasury and Sustainability - Working Group\n\n Plurality Labs: Arbitrum DAO x RnDAO Co.lab\n\n Plurality Labs (Thrive Protocol) return of unused funds\n\n Treasury Mgmt v1.2 - TM Track (ARB and Stables)\n\n TMC - Stablecoin Withdrawal Process\n\n TMC Proposed Allocations V2 – Stablecoin Strategy\n\n TMC Proposed Allocations V2 – ARB Strategy\n\n Treasury Management v1.2 - GM Track (ETH)\n\n GMC’s Preferred Choices for 7,500 ETH RFP\n\n [RFP Process] Arbitrum DAO Treasury, 7,500 ETH - Instructions to Apply\n\n Grants Discussions\n\n AXUSD — RWA-Enabled Lending Markets Live on Arbitrum (Observation Window)\n\n Ether Guild Funding Ask\n\n Arbitrum and the Future of Web3 Gaming\n\n Arbitrum Research & Development Collective\n\n [Election & Application Thread] V2 Arbitrum Research & Development Collective\n\n Arbitrum Research & Development Collective: Elections & Applications\n\n ARDC Security Member\n\n Arbitrum Governance Upgrade Rollout & Timeline\n\n Security analysis of EIP-4824 adoption by Arbitrum DAO\n\n Arbitrum Security Council Recommendations\n\n ARDC Risk Member\n\n [Request for Support - Chaos Labs] Backtesting and Suggestions For Min Base Fee\n\n Part 2: Arbitrum Governance Risks Analysis\n\n Arbitrum Sequencer Sustainability Study\n\n ARDC Research Member\n\n [Request for Support] Creation of An Arbitrum DAO Budget\n\n Arbitrum Ecosystem Mapping & Positioning Recommendations\n\n Analysis of the DAO’s Technical Decision Making Process\n\n ARDC DAO Advocate (old)\n\n Exploring zkTLS Opportunities\n\n ARDC continuation: retrospective before proposal\n\n [Request for Support] Empowering Underrepresented Delegates Proposal\n\n Biweekly Updates (STIP)\n\n STIP Bi-Weekly Update Template\n\n STIP Multi-Sig Close Out\n\n Thales Protocol Arbitrum STIP Summary\n\n ARDC Supervisory Council\n\n ARDC V2 Final Update & Concluding Report\n\n ARDC Communication Thread\n\n Entropy’s Retrospective on the ARDC V2\n\n (Re)delegation Week\n\n What is (Re)delegation Week? (+Application thread)\n\n (Re)delegation Week - Next Steps for Delegators\n\n Who are Delegates and Delegators?\n\n Long Term Incentives Pilot Program (LTIPP)\n\n LTIPP Important Reminders and Clarifications\n\n LTIPP How To Apply FAQ\n\n LTIPP: Regarding our role, instructions for applicants, and open questions we aim to answer\n\n LTIPP Bounties\n\n PYOR - Arbitrum STIP, Backfund STIP and LTIPP incentive Efficacy analysis Preliminary report\n\n Team Lampros Labs DAO - LTIPP Research Bounty Reports\n\n Serious People: Research Bounties for LTIPP\n\n GovHack Brussels\n\n Making an Awesome Ventures Track at GovHack\n\n Team #6: An (EIP-4824 powered) daoURI for the Arbitrum DAO\n\n Team 17 - Arbitrum DAO Treasury Diversifying Through RWA Assets\n\n PL Data Monitoring Procurement\n\n RFP - Abitrum Short-Term Incentive Program (STIP) Data Monitoring and Reporting\n\n Proposal: Don’t let OP beat ARB in supporting POKT Network Retro PGF!\n\n STIP Monitoring - Objective 1 & 2 - OpenBlock Labs - [FINAL]\n\n GovHack Denver\n\n GovHack Day 3 Community Voting - Top 5 GovHack Teams\n\n GovHack ETHDenver 2024 - Impact Report - Hack Humanity\n\n GovHack - ETHDenver powered by Hack Humanity\n\n Short Term Incentives Program (STIP) Round 1\n\n How to Apply - Arbitrum Short Term Incentives Program\n\n STIP Application Template\n\n About the Incentive Framework category\n\n STIP Bridge Addendum\n\n [FINAL] Jones STIP Addendum\n\n [FINAL] WINR Protocol STIP Addendum\n\n [Premia] STIP Addendum\n\n Uniswap-Arbitrum Grant Program (UAGP)\n\n Uniswap-Arbitrum Grant Program (UAGP) - Update Cohort 1\n\n Official Launch: $1m ARB Uniswap-Arbitrum Grant Program (UAGP)\n\n Uniswap-Arbitrum Grant Program (UAGP) - Program Update Thread\n\n Archived Proposals\n\n The DAO Incentive Program (DIP 2.0)\n\n [Non-Constitutional] Let’s get our huddles (aka. video calls) in order\n\n Proposal: Launch Arbitrum App Store & Builder Communities Hub on Common Ground\n\n Archived Announcements\n\n The Arbitrum DAO Code of Conduct\n\n The Arbitrum DAO’s Procedures\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 Categories, posts, and other initiatives, whose posts should be preserved.\n\n 0\n\n 36\n\n Jul 2024\n\n Independent verification review of Arbitrum — 17 onchain checks, credit-first\n\n Sales Pitch by Service Providers\n\n 5\n\n 159\n\n 20d\n\n AIE - Wallet Insight | Multichain Wallet Analysis - Full Public Case Study\n\n Sales Pitch by Service Providers\n\n 4\n\n 142\n\n Aug 10\n\n [PROPOSAL] Nexus Watch by VeriOmnion: Real-Time Financial Integrity & Institutional Signal\n\n Sales Pitch by Service Providers\n\n 9\n\n 215\n\n Aug 3\n\n AIE - Airdrop Integrity | Private Institutional Airdrop Analysis\n\n Sales Pitch by Service Providers\n\n 4\n\n 93\n\n Aug 1\n\n Arbitrum Yield & Risk Intelligence Layer by TID Research\n\n Firestarters\n\n 1\n\n 89\n\n Jul 6\n\n [SOS Submission] {Merged: TBD} – Strategic Objectives\n\n Strategic Objective Settings (SOS)\n\n 26\n\n 725\n\n Jun 29\n\n DAO Stablecoin Revenue Research: Sequencer Fee Attribution & Non-USD Opportunity Analysis\n\n Firestarters\n\n 0\n\n 104\n\n Jun 8\n\n Arbitrum DAO Contributor Program: Validation Research Report\n\n Firestarters\n\n governance\n\n 1\n\n 136\n\n Jun 7\n\n Firestarters - April Monthly Update\n\n Firestarters\n\n 0\n\n 73\n\n May 4\n\n Firestarters Quarterly Retrospective Report\n\n Firestarters\n\n 3\n\n 127\n\n Apr 21\n\n Firestarters - March Monthly Update\n\n Firestarters\n\n 0\n\n 72\n\n Apr 6\n\n CASP Feasibility Report\n\n Firestarters\n\n 1\n\n 162\n\n Mar 13\n\n Arbitrum Treasury and Sustainability - Working Group\n\n ThankARB by Thrive (prev Plurality Labs)\n\n governance,delegation,pl-data-monitoring\n\n 22\n\n 6.6k\n\n Feb 28\n\n Firestarters - February Monthly Update\n\n Firestarters\n\n 0\n\n 135\n\n Feb 27\n\n Request for Proposal - RPC Service Providers Panel and Procurement Framework\n\n ArbitrumDAO Procurement Committee (ADPC)\n\n 4\n\n 422\n\n Feb 24\n\n AXUSD — RWA-Enabled Lending Markets Live on Arbitrum (Observation Window)\n\n Grants Discussions\n\n proposal\n\n 0\n\n 68\n\n Feb 5\n\n DIP v1.7 Final Report: From Engagement to Rewards: A Comprehensive Analysis of the Delegate Incentives Program (May - October 2025)\n\n Delegate Incentives Program (DIP)\n\n 3\n\n 320\n\n Feb 3\n\n Firestarters - January Monthly Update\n\n Firestarters\n\n 0\n\n 119\n\n Jan 29\n\n ZK-based eligibility proofs for private allowlists (Groth16)\n\n Sales Pitch by Service Providers\n\n 0\n\n 88\n\n Jan 15\n\n Ether Guild Funding Ask\n\n Grants Discussions\n\n proposal,grants-ecosystem\n\n 2\n\n 200\n\n Dec 2025\n\n [RFF] Akua — Production-Grade Commodity Settlement Infrastructure on Arbitrum (CRE + DTA)\n\n Sales Pitch by Service Providers\n\n proposal,proposal-discussions\n\n 1\n\n 113\n\n Dec 2025\n\n [DIP v1.7]Delegate Incentive Program: Payment Distribution Thread\n\n Delegate Incentives Program (DIP)\n\n 15\n\n 1.6k\n\n Dec 2025\n\n Karma - Track forum contributions by linking your wallet\n\n Guides & Documentation\n\n delegation\n\n 79\n\n 2.9k\n\n Dec 2025\n\n [Firestarters] Focus & Next Steps\n\n Firestarters\n\n 2\n\n 357\n\n Dec 2025\n\n Arbitrum Governance Upgrade Rollout & Timeline\n\n ARDC Security Member\n\n 20\n\n 1.5k\n\n Dec 2025\n\n Arbitrum and the Future of Web3 Gaming\n\n Grants Discussions\n\n 40\n\n 10.6k\n\n Dec 2025\n\n [DIP v1.7] Delegate Incentive Program Results (October 2025)\n\n Delegate Incentives Program (DIP)\n\n 2\n\n 254\n\n Dec 2025\n\n [DIP v1.7]Delegate Incentive Program Questions and Feedback\n\n Delegate Incentives Program (DIP)\n\n governance\n\n 49\n\n 1.9k\n\n Dec 2025\n\n The DAO Incentive Program (DIP 2.0)\n\n Archived Proposals\n\n 53\n\n 2.3k\n\n Dec 2025","tokens":3703,"squid":"spider-07","role":"Council Spider","at":1791339970021,"hash":"fa65b019272d30e23598b605e52a1e0e942711b9"}
{"url":"https://docs.phantom.com/developer-powertools/domain-and-transaction-warnings","domain":"docs.phantom.com","title":"Domain and transaction warnings - Phantom developer documentation","text":"Phantom may display different warnings when users connect to your app or sign transactions.\nThese warnings are designed to help protect users from unexpected or unsafe activity.\n​New domain warning\nIf your app or website has been newly launched, Phantom may show users the following message:\n\n“This domain is new or has not been reviewed yet. Proceed with caution.”\n\nThis warning appears automatically for newly detected domains and typically disappears after a few days once the domain has been reviewed.\nThere’s usually no action required on your part. If the warning remains visible for more than a week, contact our domain review team using this form.\n​App identity verification warning\nWhen users connect to a native Android app through Mobile Wallet Adapter (MWA), Phantom verifies that the app is genuinely associated with the web domain it claims as its identity. If Phantom can’t complete this verification, users see the following message:\n\n“This app’s identity could not be verified. It may be impersonating another app.”\n\nThis verification is domain-based, as defined in the MWA dapp identity verification spec. Phantom checks the Digital Asset Links file hosted on your domain and confirms that your app’s package name and signing certificate match an android_app statement in that file.\nThe warning appears when any of the following verification requirements are missing:\n\nYour authorize request doesn’t include a uri in its identity.\nYour domain doesn’t host a Digital Asset Links file at /.well-known/assetlinks.json.\nYour app’s package name or signing certificate fingerprint doesn’t match the statements in the file.\n\n​Resolve the warning\n1. Host a Digital Asset Links file\nPublish https://yourapp.com/.well-known/assetlinks.json declaring your app’s package name and the SHA-256 fingerprint of its signing certificate:\n[\n {\n \"relation\": [\"delegate_permission/common.handle_all_urls\"],\n \"target\": {\n \"namespace\": \"android_app\",\n \"package_name\": \"com.yourapp.android\",\n \"sha256_cert_fingerprints\": [\n \"AA:BB:CC:DD:EE:FF:00:11:22:33:44:55:66:77:88:99:AA:BB:CC:DD:EE:FF:00:11:22:33:44:55:66:77:88:99\"\n ]\n }\n }\n]\n\nIf you distribute through Google Play with Play App Signing, use the app signing key certificate fingerprint from the Play Console (Protected with Play → Play Store protection → Manage Play app signing), not your upload key. A mismatched fingerprint is the most common cause of failed verification.\n2. Include your domain in the identity of your authorization request\nThe uri must point to the domain that hosts your assetlinks.json file:\nimport { transact } from \"@solana-mobile/mobile-wallet-adapter-protocol-web3js\";\n\ntry {\n const authorization = await transact(async (wallet) => {\n return await wallet.authorize({\n chain: \"solana:mainnet\",\n identity: {\n name: \"Your App\",\n uri: \"https://yourapp.com\", // Domain hosting /.well-known/assetlinks.json\n icon: \"favicon.ico\",\n },\n });\n });\n console.log(\"Authorized:\", authorization.accounts[0]?.address);\n} catch (err) {\n // Thrown if the user declines, or if the wallet rejects the request\n console.error(\"Authorization failed:\", err.message);\n}\n\nYou can confirm your Digital Asset Links file is live and valid with the following command, which fails if the file is missing or isn’t a JSON array:\ncurl --fail https://yourapp.com/.well-known/assetlinks.json | jq -e 'type == \"array\"'\n\nOnce the file is correctly hosted and your signing certificate matches, verification completes automatically on the next connection. No submission to Phantom is required.\n​Transaction simulation warning\nIf Phantom can’t accurately simulate a transaction before it’s sent, users may see the following message:\n\n“This dApp could be malicious. Do not proceed unless you are certain it is safe.”\n\nThis message appears when Phantom is unable to safely predict a transaction’s outcome before execution.\nIf Phantom displays this warning when you sign a transaction on your domain, follow these steps:\n\nLimit the transaction to one signer.\nIf the transaction requires multiple signers, sign it with Phantom first using signTransaction instead of signAndSendTransaction, then collect signatures from the other signers.\nIf your transaction approaches Solana’s size limit, split it into multiple signing requests or use Address Lookup Tables.\nBefore submitting the transaction for signing, simulate the transaction with sigVerify: false using your RPC node to ensure it will not fail onchain. Failed transactions could trigger simulation warnings.\n\nIf you’ve made these changes and the warning persists, or if you can’t apply these changes, contact our domain review team using this form.\n​Prediction market token burn warning\nIf a transaction attempts to burn a prediction market token, Phantom may show users the following message:\n\n“This transaction will burn a valuable prediction market token. Please use the Phantom app to close the position first.”\n\nThis warning appears when Phantom detects a transaction that would permanently burn a prediction market token.\nTo resolve this warning, contact our Trust and Safety team using this form.Was this page helpful?","tokens":1279,"squid":"spider-10","role":"Tooling Spider","at":1791339972784,"hash":"66d088d324cda19574f2cea6176c532a0eabeb82"}
{"url":"https://jup.ag/spot","domain":"jup.ag","title":"Jupiter Spot: Solana Markets, News and Trading","text":"SpotMarket PulseBetaCrypto ETF flows were negative over one day, with Lookonchain reporting net outflows of 1,059 BTC and 21,432 ETH; its seven-day data showed mixed Bitcoin flows but continuing Ethereum outflows. CoinDesk’s X post says the CFTC is proposing a federal crypto rulebook, while FinCEN dropped its mixer-reporting proposal. Separately, the UK’s digital government-bond pilot targets issuance by the first quarter of 2027.7:17 PM7:17 PMSPCX-1.84%ZEC-2.17%ANTHROPIC-5.89%OTC-2.23%CARDS-0.21%GOOGLx+0.23%NVDAx+0.23%View allTWEETCRAFTMC $719K+64xDEXPADMC $80.3K+931.14%cashratMC $73.4K+711.86%AUTONMC $3.06M+721xORCATMC $70.9K+10xCLAUDIAMC $206K+46xRARIMC $1.33M+271xAgencyMC $5.32M-23.96%MINERMC $118K+527.7%CARDS$0.28402-0.21%BISCOTTIMC $19.4K+304.18%SIMC $23.6M-11.1%Featured token listsxORCA$5.05MC $28.4M+32.87%MET$0.31754MC $177M+8.82%SPYx$779.18UMC $703B+0.53%NVDA$239.86MC $5.76T+0.4%AAPL$333.99MC $4.85T+0.33%GOOGL$348.10MC $4.23T+0.47%SmartMoney BuyscbBTC$83,768.37MC $243MBUY $2.92MPUMP$0.00616MC $2.85BBUY $1.42METH$2,612.35MC $113MBUY $1.12MMarket Dominance 24h-3%+3%9:26 PMJupiter","tokens":276,"squid":"spider-02","role":"Liquidity Spider","at":1791339975500,"hash":"7fd3d1b31359c2d25497ed5e686ff68e0005f5c7"}
{"url":"https://forum.arbitrum.foundation/t/aie-wallet-insight-multichain-wallet-analysis-full-public-case-study/31184","domain":"forum.arbitrum.foundation","title":"AIE - Wallet Insight | Multichain Wallet Analysis - Full Public Case Study - Archive / Sales Pitch by Service Providers - Arbitrum","text":"The Arbitrum Foundation notified the Security Council on the need to perform a potential Emergency action. Following a review of the details and known risks, the Security Council decided to execute the upgrade and it was completed at 11:30 EST on 2nd October 2026.\nThis report provides an overview of the risks that required the Security Council Action:\n\nAdd a permissionless guard for the One-Step Proof of BoLD on Arbitrum One\n\nTemporarily pause activation of new Stylus contracts on Arbitrum One & Nova\n\nKey point: To date, known bugs for Stylus primarily impact chain liveness (e.g., denial of service attacks) and do not put any user funds at risk.\nWhy was this action taken\nLet’s take this opportunity to explain why action was taken on two separate issues concerning BoLD and Stylus.\nInstalling the guard for One-Step Proof of BoLD. Given the rise of AI-assisted attacks, we have implemented a precautionary approach that allows anyone to pause settlement of Arbitrum One on Ethereum if there are at least two conflicting answers that pass at the same level in which only one should be valid and pass. This is to halt a class of publicly verifiable and detectable attacks that exploit a bug in the one-step proof. If halted, Arbitrum One will continue to process as normal except that messages from Arbitrum One to Ethereum, such as withdrawals, that are not yet confirmed will have to wait. This provides time for the Security Council to deploy a fix for the bug and resume the rollup.\nPreventing activation of new Stylus contracts. AI-assisted tooling has led to an increasing number of sophisticated attacks on hand-crafted WASM programs that do not use the standard Stylus compiler toolchain. These programs are specifically designed to cause unexpected behaviors such as degrading the chain’s performance for all other users. To date, no attacks have been discovered that permits theft of user funds.\nNew ArbOS releases have patched several reported bugs and known attacks over the past few months, but out of an abundance of caution, we have decided to temporarily pause new activations of Stylus contracts. This was executed as an emergency action to prevent the deployment of new hand-crafted WASM programs that are not yet patched by the current version of ArbOS on the Arbitrum network.\nThe Arbitrum Foundation has informed the Security Council that they will work with the ArbitrumDAO to discuss next steps on the timeline and manner for enabling activation of new Stylus contracts. The Arbitrum community remains confident in the value of Stylus and want to preserve these use cases while taking preventative measures against Stylus-based attack vectors as AI-assisted attack tooling continues to evolve.\nImpact on builders and users\n\nNo new activations. New Stylus contracts cannot be activated during the pause including new versions of existing applications that require activation.\n\nExisting contracts are not paused. Already-active Stylus contracts continue to execute until expiration. This pause does not deactivate them.\n\nThe ArbOS 61 upgrade renewed all active contracts on Arbitrum One, so no currently active contract expires before August 20, 2027.\n\nRenewal via keepalive stays permissionless and is unaffected by the pause.\n\nReactivating an expired contract, or one that needs to be updated after a Stylus version change, is paused.\n\nUsing/calling any activated Stylus contract stays permissionless for all users and developers.\n\nNo impact on EVM. Solidity (EVM) contract deployment and execution are unaffected by this Security Council action.\n\nSecurity Council Actions\nThere are two actions bundled into a single payload:\n\nOne-Step Proof Guard. The L1UpgradeExecutor gives a new pause contract (PauseExecutor) the ability to pause and nothing else. The new pause contract grants the guard (OspSoundnessGuard) PAUSER_ROLE to use it. Anyone can show the guard two conflicting answers to the same step of an open challenge. If the one-step proof accepts both, the guard has the pause contract put Arbitrum One’s settlement to Ethereum on hold.\n\nStylus deactivation. The Security Council called ArbOwner.setWasmActivationGas(2^64 - 1) to raise the Stylus activation gas requirement on Arbitrum One and Nova. This makes activation prohibitively expensive and effectively disables new activations. This is a configuration change and does not require an ArbOS upgrade.\n\nThe Security Council signed the following transactions to update the configuration:\n\nEthereum: Ethereum Transaction Hash: 0x30732bb7d2... | Etherscan\nArbitrum One:\nArbitrum One Transaction Hash: 0x9eb3a4be3b... | Arbitrum One\nArbitrum Nova:\nArbitrum Nova transaction 0x79e0fed470dff7a22059b108e3f8f42eddd2b580a6771594060c4e7326c5f984 | Blockscout\n\nAn external audit was conducted for the OSP Guard contracts. No audit is required for the Stylus deactivation as it is only updating a single parameter in the ArbOS configuration.\n\n AIE - Wallet Insight | Multichain Wallet Analysis - Full Public Case Study \n\n ArchiveSales Pitch by Service Providers\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 7\n min\n\n Aug 9\n\n 1 / 5\n\n Aug 8\n\n Aug 10\n\n post by cxclrfx on Aug 9\n\n cxclrfx\n\n Continuing the discussion from AIE - Airdrop Integrity | Private Institutional Airdrop Analysis: # AIE - Wallet Insight\nMultichain Wallet Analysis - Full Public Case Study\nA wallet address is easy to look up.\nUnderstanding what that wallet actually did is a different problem.\nFor protocols, treasuries, exchanges, auditors, investigators, security teams, funds, counterparties and users preparing high-value transfers, an explorer page is not enough when a decision depends on the difference between:\n\nan address appearing on a network and actually using that network;\nan inbound transfer and an owner-originated action;\na displayed token and an economically qualified asset;\nan explorer valuation and defensible portfolio value;\na bridge appearance and a reconstructed cross-chain journey;\nunsolicited dust and genuine wallet behavior;\na generic risk label and evidence that can actually be reviewed.\n\nAIE - Wallet Insight is built for that distinction.\nRather than describing the service abstractly, below is a complete public multichain case study showing the type of result a client receives.\n\nSubject\nAddress: 0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045\nEnvironment: EVM Multichain\nAnalysis: AIE - Wallet Insight\nEvidence level: EVIDENCE ANCHORED\nWallet connection required: No\nSignature required: No\nPrivate key or seed phrase required: Never\nThe address is public and carries the public explorer label vitalik.eth / Vb 5.\nThe identity label is not used as analytical evidence. The analysis concerns the public blockchain address and its observable activity.\n\nExecutive Conclusion\nA conventional multichain explorer currently presents this address as having token holdings across 31 networks, more than 100,000 address-associated records, and approximately $1.13M of raw aggregated portfolio value.\nThose numbers are real explorer outputs.\nThey are not the AIE conclusion.\nAIE separates four questions:\nNETWORK PRESENCE → CONTROL EVIDENCE → ASSET PROVENANCE → QUALIFIED VALUE\nThe same hexadecimal address appearing on multiple EVM networks does not prove that the address actively used every one of those networks.\nAnyone can send ETH, tokens, NFTs or dust to a public address.\nLikewise, a token appearing in an explorer does not prove that the controller intentionally acquired it, and an explorer-supplied price does not automatically make that token part of a defensible portfolio valuation.\nPrimary findings\nMultichain presence: CONFIRMED\nActive multichain use: CONFIRMED, but materially narrower than raw network presence\nEthereum activity: CONFIRMED\nBase activity: CONFIRMED\nOptimism activity: CONFIRMED\nArbitrum activity: CONFIRMED\nHistorical activity on additional networks: CONFIRMED\nLarge passive/inbound footprint: CONFIRMED\nUnsolicited-token contamination: HIGH\nRaw explorer portfolio reliability: LOW WITHOUT ASSET QUALIFICATION\nDelegated account behavior: CONFIRMED\nDeFi interaction: CONFIRMED\nCurrent compromise: NOT ESTABLISHED\nMixer exposure: NOT ESTABLISHED IN THIS BASE REVIEW\nSanctions determination: NOT ISSUED WITHOUT QUALIFIED REFERENCE EVIDENCE\nThe result is therefore not reduced to a single arbitrary Risk Score.\nThe client receives the individual findings, their evidence status and the distinction between what the wallet demonstrably did and what merely appeared around it.\n\n1. Multichain Discovery\nThe current Blockscan view exposes 34 explorer/network entries and token holdings across 31 networks.\nAt the time of this case-study snapshot, the largest raw explorer-displayed values are approximately:\n\nNetwork\nRaw displayed value\n\nEthereum\n$857K+\n\nBlast\n$128K+\n\nBase\n$86K+\n\nBNB Chain\n$52K+\n\nOptimism\n$7K+\n\nArbitrum One\n$859\n\nPolygon\n$699\n\nTaiko\n$192\n\nWorld\n$123\n\nUnichain\n$63\n\nLinea\n$19\n\nAdditional networks\nsmaller balances\n\nThese figures are discovery data.\nThey are not automatically accepted as AIE-qualified owner holdings.\nThat distinction becomes important immediately.\n\n2. Presence Is Not Usage\nAIE does not mark a network as actively used simply because the same address exists there or because tokens have been sent to it.\nFor every network, we independently look for address-originated evidence.\nThe classification model is:\nACTIVE - CONTROL CONFIRMED\nThe address has initiated activity that demonstrates use of the account on that network.\nHISTORICAL ACTIVE\nOutgoing use is established, but the activity belongs to an earlier period.\nPRESENCE ONLY\nAssets or transactions involving the address exist, but local owner-originated activity has not been established.\nUNQUALIFIED\nThe network requires additional evidence before a behavioral conclusion is issued.\nThis prevents the common but incorrect transformation:\nsame address found on 31 chains\ninto:\nowner actively uses 31 chains\nThose are not equivalent statements.\n\n3. Ethereum\nEthereum is the largest network by raw displayed value in the current explorer portfolio.\nThe address has genuine owner-originated activity and contract interaction history.\nTherefore:\nPresence: CONFIRMED\nControl/use: CONFIRMED\nActivity: ACTIVE\nContract interaction: CONFIRMED\nNative asset presence: CONFIRMED\nBut Ethereum also demonstrates the asset-qualification problem.\nSeveral tokens account for a very large share of the raw explorer valuation. Current explorer allocation data includes very large nominal values attributed to tokens such as WHITE, CATE, MOO DENG and KNC.\nAIE does not simply copy those balances into:\n\n“Verified owner wealth: $1.13M.”\n\nFor every material asset, the analytical questions are different:\n\nWhat is the exact token contract?\nHow did the asset arrive?\nWas it acquired through an address-originated transaction?\nWas it transferred unsolicited?\nDoes a legitimate market exist for this exact contract?\nIs the explorer price mapped to the correct asset?\nIs there sufficient liquidity to treat the displayed price as economically meaningful?\nHas the subject ever interacted with the token?\n\nUntil those questions are qualified, the value remains displayed value, not qualified owner value.\n\n4. Base - Active Use Confirmed\nBase gives strong evidence of actual control and use.\nThe explorer records address-originated transactions and a substantial contract-interaction history.\nOn 1 May 2026 alone, the address executed a compact sequence of transactions involving Uniswap V2 Router02 and Uniswap V3 Swap Router02, including multiple ETH-valued transactions within minutes.\nThe Base history also contains interactions with LI.FI Diamond.\nTherefore:\nBase presence: CONFIRMED\nBase control: CONFIRMED\nAddress-originated activity: CONFIRMED\nDEX interaction: CONFIRMED\nDeFi activity: CONFIRMED\nCross-chain infrastructure interaction: OBSERVED\nThis is fundamentally stronger evidence than merely receiving a token on a network.\n\n5. Delegated Account State\nThe address cannot be treated everywhere as a simple traditional EOA and analyzed solely as:\nprivate key → transaction\nCurrent explorer state identifies it as an Authority with delegated execution state, including an EIP-7702 delegation on Base and other observed networks.\nAIE classification\nTraditional EOA-only model: NOT SUFFICIENT\nDelegated account behavior: CONFIRMED\nExecution-model complexity: ELEVATED\nCompromise indication from delegation alone: NONE\nDelegation is not itself malicious.\nIt means that a professional wallet review must understand the current execution model of the account instead of stopping after identifying the hexadecimal address.\n\n6. Blast - The Valuation Anomaly\nBlast is one of the clearest examples in this case.\nThe explorer currently shows approximately $128,205 of token holdings for the address.\nApproximately 190 million DUCKIE account for almost all of that displayed value.\nAt the same time, BlastScan reports:\nTransactions Sent: N/A\nThe same address page also contains unsolicited-looking token/NFT material with reward and promotional naming.\nA naive portfolio interpretation could therefore produce:\n\n“The owner uses Blast and owns approximately $128K there.”\n\nAIE does not make that statement.\nThe evidence supports:\nBlast presence: CONFIRMED\nInbound asset presence: CONFIRMED\nAddress-originated Blast transaction: NOT OBSERVED IN THE BASE REVIEW\nIntentional DUCKIE acquisition: NOT ESTABLISHED\nOwner-qualified Blast portfolio value: NOT DERIVED FROM THE RAW EXPLORER FIGURE\nThis one network represents more than ten percent of the raw multichain portfolio display while local owner-originated use is not established.\nThat is the difference between displaying blockchain data and interpreting it.\n\n7. Passive Networks and Unsolicited Assets\nThe address has additional networks where assets exist but owner-originated activity is absent or not sufficiently established in the base review.\nAIE keeps those networks in the wallet record.\nIt does not silently promote them into behavioral history.\nThe correct distinction is:\nAsset received: YES\ndoes not imply:\nOwner chose this asset: YES\nand:\nAddress exists on network: YES\ndoes not imply:\nOwner actively used network: YES\nThis matters particularly for highly visible public addresses because they attract:\n\nunsolicited tokens;\npromotional NFTs;\ndust;\nvanity transfers;\naddress-poisoning attempts;\nfake reward assets;\nmemecoins;\nautomated distribution campaigns;\ntransfers made purely because the address is publicly known.\n\nThese events remain evidence.\nThey are simply evidence of incoming activity, not automatically evidence of subject behavior.\n\n8. Dust and Micro-Transfer Discipline\nAIE records incoming micro-transfers without assigning them to the wallet controller.\nFor a typical event:\nexternal address → 0.00001 ETH → subject\nthe base finding is:\nTransfer: CONFIRMED\nDirection: INBOUND\nSubject initiated transaction: NO\nRelationship to sender: NOT ASSUMED\nSender intent: NOT ATTRIBUTED IN BASE WALLET INSIGHT\nThis prevents inbound dust from contaminating the wallet biography.\nIf the client needs to know who is sending the dust and why, that becomes a different investigative question.\n\n9. Dust / Spam Attribution - Extended Investigation\nA Wallet Insight identifies and separates unsolicited activity.\nA deeper investigation can then move outward from the subject wallet and examine the infrastructure behind it.\nThat expansion can determine:\n\noriginating addresses;\nrepeated sender clusters;\ncommon funding sources;\ntoken and NFT deployers;\nidentical campaigns across networks;\nautomated distribution infrastructure;\naddress-poisoning patterns;\nphishing-style token/NFT campaigns;\nrepeated timing signatures;\nshared contract relationships;\nlinks between apparently unrelated sender addresses;\nattributable entities where evidence supports attribution.\n\nThe result can move from:\n“Unsolicited transfers detected.”\nto:\n“These transfers were generated by this sender cluster, funded through this path, using these contracts, across these networks.”\nThis is separately scoped because the object of investigation has expanded beyond the subject wallet.\n\n10. Cross-Chain / Bridge Layer\nThe public history contains interactions involving cross-chain infrastructure, including LI.FI and other bridge-related systems.\nAIE does not turn the mere appearance of a bridge contract into a fabricated journey.\nFor example, seeing:\nsubject ↔ bridge infrastructure\nis not yet sufficient to claim:\nEthereum → Bridge → Base → Swap\nA complete cross-chain journey requires correlation of:\n\nsource transaction;\nsource asset;\nsource amount;\nbridge/router event;\ntiming;\ndestination settlement;\ndestination asset;\ndestination transaction;\nsubsequent movement.\n\nEach link receives an evidence state:\nCONFIRMED\nEVIDENCE-SUPPORTED\nUNRESOLVED\nBase Wallet Insight\nBridge infrastructure involvement: OBSERVED\nExtended Cross-Chain Reconstruction\nA complete reconstruction can produce:\nsource chain\n↓\nsource transaction\n↓\nbridge/router\n↓\ndestination settlement\n↓\ndestination wallet state\n↓\nsubsequent transaction\nThis is particularly useful when an investigation cannot be understood correctly from a single chain.\n\n11. DeFi Footprint\nThe wallet has genuine DeFi activity.\nCurrent multichain explorer data identifies Uniswap positions, while Base independently shows owner-originated Uniswap interactions.\nTherefore:\nDeFi participation: CONFIRMED\nDEX activity: CONFIRMED\nUniswap interaction: CONFIRMED\nAgain, this conclusion is based on address-originated evidence.\nIt is not inferred from somebody sending a DeFi-related token to the address.\n\n12. Approval and Execution Exposure\nWallet security cannot be determined from balances alone.\nDepending on the network and account state, exposure can also exist through:\n\nERC-20 allowances;\nunlimited token approvals;\nERC-721 operator approvals;\nERC-1155 operator approvals;\ndelegated execution;\nspender contracts;\nsmart-account authorization state.\n\nApprovals are network-specific.\nAn Ethereum approval is not automatically a Base approval.\nA Base approval is not automatically an Arbitrum approval.\nA full Approval Exposure expansion can produce:\nnetwork → asset → spender → allowance → limited/unlimited → spender identity → current relevance → evidence\nThis is available when the client’s question requires full authorization mapping rather than base wallet characterization.\n\n13. Transaction Count Integrity\nBlockscan currently reports more than 100,000 address-associated records in its multichain view.\nThat must not be converted into:\n\n“The wallet performed more than 100,000 transactions.”\n\nFor a widely known public address, a large proportion of the observable record can consist of activity toward or around the address, not activity initiated by it.\nAIE therefore keeps separate counts for:\nExplorer-associated records\nand\nAddress-originated actions\nIncoming noise does not become owner behavior merely because it appears on the same explorer page.\n\n14. Raw Portfolio vs Qualified Portfolio\nThis case demonstrates one of the most important Wallet Insight rules.\nExplorer view\nRaw multichain net worth: approximately $1.13M\nAIE view\nThat number is not automatically accepted as verified owner wealth.\nAIE separates:\nConfirmed native balance\nEconomically supported holdings\nAssets with unresolved provenance\nUnsolicited assets\nDust/spam assets\nUnverified token valuations\nPassive-network receipts\nAssets requiring liquidity/market qualification\nOnly after qualification can these components be consolidated into an evidence-backed portfolio view.\nPortfolio verdict\nRaw explorer value: AVAILABLE\nRaw explorer value accepted as qualified owner wealth: NO\nUnsolicited/unqualified asset contamination: HIGH\nQualified aggregate value: DERIVED ONLY AFTER ASSET-PROVENANCE FILTERING\n\n15. Risk Summary\n\nDimension\nAssessment\n\nMultichain control\nCONFIRMED, SELECTIVE\n\nEthereum activity\nACTIVE\n\nBase activity\nACTIVE\n\nOptimism activity\nCONFIRMED\n\nArbitrum activity\nCONFIRMED\n\nAdditional historical network use\nCONFIRMED\n\nPassive-network footprint\nLARGE\n\nUnsolicited asset contamination\nHIGH\n\nRaw portfolio reliability\nLOW WITHOUT QUALIFICATION\n\nDelegated-account complexity\nELEVATED\n\nDeFi activity\nCONFIRMED\n\nCurrent compromise\nNOT ESTABLISHED\n\nMixer exposure\nNOT ESTABLISHED IN BASE REVIEW\n\nIllicit-owner attribution\nNOT ESTABLISHED\n\nSanctions determination\nNOT ISSUED IN THIS PUBLIC CASE STUDY\n\nAIE does not substitute a single unexplained number such as:\nRisk Score: 87\nfor these independent findings.\nA decision-maker receives the actual dimensions, evidence and unresolved areas.\n\n16. What This Case Demonstrates\nA conventional explorer can show that:\n\nan address appears across many networks;\nthousands of tokens have reached it;\nmore than 100,000 records are associated with it;\nthe displayed portfolio is worth approximately $1.13M.\n\nWallet Insight answers different questions:\nWhich networks show actual control?\nWhich transactions were initiated by the subject?\nWhich assets merely arrived from third parties?\nWhich holdings have defensible provenance?\nWhich valuations can be qualified?\nWhich DeFi interactions are real subject behavior?\nWhich cross-chain relationships are actually proven?\nWhich events are noise, dust or unsolicited activity?\nWhere does the evidence stop?\nThat distinction is the product.\n\n17. Beyond Wallet Insight\nWallet Insight is one entry point into the wider AIE analytical environment.\nWhen the problem extends beyond a single wallet, additional work can cover:\nTransaction Journey / Provenance\nReconstruction of the movement of assets through addresses, contracts, services and networks.\nCounterparty & Entity Graph\nRecurring counterparties, concentration, transaction direction, relationship structure and evidence-supported entity attribution.\nCross-Chain Journey Reconstruction\nSource-chain transaction through bridge/router infrastructure to destination settlement and subsequent movement.\nDust / Spam / Poisoning Attribution\nSender infrastructure, clusters, deployers, campaign relationships and funding paths.\nApproval Exposure\nNetwork-by-network reconstruction of token, NFT and delegated execution permissions.\nMixer / Flow Investigation\nExpansion of transaction provenance where obfuscation infrastructure or complex flow decomposition requires dedicated analysis.\nAML / Sanctions Evidence Layer\nSeparate qualification against appropriate evidence sources and frozen reference states when compliance conclusions are required.\nAirdrop Integrity\nIndependent analysis of distribution structure, wallet relationships, Sybil/coordinated behavior and reviewable evidence - the AIE service linked to this topic.\nThe analytical question determines the scope.\nA client does not need to purchase an unnecessary investigation simply because the capability exists.\n\n18. Who This Is For\nWallet Insight is designed for cases where a wallet address is part of an actual decision.\nExamples include:\n\na protocol evaluating a wallet or counterparty;\na treasury before a significant transfer;\na fund reviewing historical wallet behavior;\nan exchange or compliance team requiring an independent second view;\nan investigator following assets across chains;\na project reviewing participants or counterparties;\na security team investigating suspicious inbound activity;\nan auditor who needs blockchain evidence rather than a screenshot;\na user who wants to know what is actually behind an address before sending substantial funds.\n\nThe input can be as simple as:\none public wallet address + the question that needs to be answered.\n\n19. Evidence Standard\nThe base result distinguishes between:\nCONFIRMED\nDirect evidence supports the finding.\nEVIDENCE-SUPPORTED\nMultiple observable facts support the conclusion, but the result remains qualified.\nUNRESOLVED\nAvailable evidence is insufficient for attribution or conclusion.\nNOT ESTABLISHED\nThe reviewed evidence does not establish the claimed condition.\nThe purpose is not to fill every field.\nThe purpose is to avoid turning missing evidence into invented certainty.\nReproducibility classification for this public demonstration\nEVIDENCE ANCHORED\nThis public case study does not claim full REPLAY CAPABLE status because a frozen raw RPC/reference-snapshot bundle is not being distributed with the forum post.\n\nFinal Client Verdict\nSubject: 0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045\nMultichain presence: CONFIRMED\nActive use of every observed network: NO\nActive multichain use: CONFIRMED\nLarge passive/inbound footprint: CONFIRMED\nRaw explorer portfolio: approximately $1.13M at snapshot\nRaw portfolio accepted as owner-qualified wealth: NO\nUnsolicited/unqualified asset contamination: HIGH\nDelegated account behavior: CONFIRMED\nDeFi activity: CONFIRMED\nCurrent compromise: NOT ESTABLISHED\nKey Finding\n31 networks with displayed holdings do not mean 31 actively used networks.\nMore than 100,000 associated records do not mean more than 100,000 owner-originated actions.\nApproximately $1.13M displayed by an explorer does not automatically mean approximately $1.13M of evidence-qualified owner assets.\nInbound dust, tokens and NFTs do not become owner behavior simply because they reached the address.\nAIE separates those questions and returns the evidence behind each answer.\n\nAvailability for the Arbitrum Community\nAIE - Wallet Insight is available for wallet-level analysis.\nForum users, protocols, organizations and teams can submit a public wallet address together with the question they need answered.\nNo wallet connection is required.\nNo signing request is required.\nNo access to the wallet is required.\nNo private key or seed phrase is ever requested.\nThe base analysis remains focused on the subject wallet.\nInvestigations that expand into external addresses, sender infrastructure, bridge paths, counterparties, mixer/provenance analysis, approval mapping or attribution are separately scoped according to the analytical work required.\n\nResponse Time\nRequests are acknowledged within minutes.\nFor a standard AIE - Wallet Insight, once the public wallet address and analytical scope are confirmed, the result is normally delivered on a minutes-scale.\nMore extensive graph reconstruction, cross-chain attribution or third-party infrastructure investigations are handled separately according to depth.\nSend the public wallet address and the question you need answered.\nAIE\n\n 3\n\n 2\n\n read \n\n 7\n min\n\n post by Anzus_GemWallet on Aug 10\n\n Anzus_GemWallet\n\n Interesting breakdown. From a user-support perspective, it is important to remind people that receiving an unknown token or NFT does not mean they need to interact with it.\nClear network labels and simple warnings can make a big difference, especially for users managing assets across several chains.\nI work with Gem Wallet, and this is useful feedback for wallet teams as well.\n\n post by cxclrfx on Aug 10\n\n cxclrfx\n\n That point has its place, but it stops at the warning layer. Most users do not read every warning, and they should not have to become transaction analysts simply to keep their assets safe.\nWarnings tell a user where danger may be. They do not prevent danger from becoming execution.\nI went further. I built a protection architecture in which, under one operating rule, a protected asset cannot be stolen. Whether the initiating cause is an honest mistake or malicious control is irrelevant: the forbidden state transition cannot complete.\nAfter your comment, I reviewed the relevant public transaction-state code paths in Gem and the current issue/patch chain. The recurring failures do not form a set of isolated UI defects. They converge on one deeper architectural break: transaction identity, origin, local semantics, polling lifetime and wallet state are not carried by one canonical transaction object under one state authority from request through final history.\nAn audit can identify individual manifestations, and a local patch can close each observed symptom. But when state ownership remains fragmented, every new exception adds another branch around the same unresolved boundary and makes the architecture harder to reason about as a whole.\nThe next step is therefore not another warning and not another isolated patch. It is one execution invariant that cannot be bypassed.\nWhere, in Gem’s current architecture, is the boundary that makes an unauthorized transfer impossible rather than merely warning the user before it happens?\n\n post by Anzus_GemWallet on Aug 10\n\n Anzus_GemWallet\n\n Thanks for taking the time to review this. I work in BD and user support, so I’m not able to confirm or discuss architecture or security findings here.\nIf you have a reproducible issue, affected version, and relevant code references, please send the details to security@gemwallet.com under Gem Wallet’s security policy. This allows the security team to review it responsibly.\nI’ll also make sure your concern is passed on. Gem Wallet\n\n post by cxclrfx on Aug 10\n\n cxclrfx\n\n My review of Gem’s public code, issue history, and patch sequence points to one shared architectural discontinuity, not a collection of isolated bugs. The failures surface in different places, but converge on transaction identity, provenance, state ownership, synchronization, and lifecycle. Treating them as separate tickets can close individual symptoms while leaving the common cause intact.\nThis is an architectural problem expressed through a chain of related failures, not a conventional isolated vulnerability. If Gem wants to examine the full dependency chain and the existing protection model, the person responsible for Gem’s architectural direction can contact directly. This requires architectural work rather than being a conventional bug-bounty submission.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n AIE - Airdrop Integrity | Private Institutional Airdrop Analysis\n\n Sales Pitch by Service Providers\n\n 4\n\n 93\n\n Aug 1\n\n [Discussion] ChainTrace v2.0: Interactive AML Simulation for Mixer & Peel Chain Detection\n\n General\n\n proposal,governance\n\n 10\n\n 127\n\n Aug 4\n\n Open Theft Signal for Arbitrum: Victim-Activated Wallet Risk Layer\n\n Early Idea Discussion\n\n 1\n\n 70\n\n Jul 30\n\n Entropy Advisors Data Dashboards Catalog\n\n Entropy Advisors Updates\n\n 0\n\n 188\n\n Apr 28\n\n Arbitrum Academic Bridge @ NTUA — Final Grant Report (Ethereum Greece)\n\n Domain Allocator Offerings (prev Questbook)\n\n 10\n\n 170\n\n Aug 10","tokens":7597,"squid":"spider-07","role":"Council Spider","at":1791339980302,"hash":"38eecc8bb503744959e2f0b766927ba50154e0a2"}
{"url":"https://docs.phantom.com/recipes/payments/send-usdc","domain":"docs.phantom.com","title":"Send USDC - Phantom developer documentation","text":"Send USDC stablecoin to another wallet. This automatically creates the recipient’s token account if needed.\n React Browser SDK React Nativeimport { useSolana } from \"@phantom/react-sdk\";\nimport { Connection, PublicKey, VersionedTransaction, TransactionMessage } from \"@solana/web3.js\";\nimport { getAssociatedTokenAddress, createAssociatedTokenAccountInstruction, createTransferInstruction, getAccount } from \"@solana/spl-token\";\n\nconst USDC_MINT = new PublicKey(\"EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v\");\nconst USDC_DECIMALS = 6;\n\nfunction SendUSDC() {\n const { solana } = useSolana();\n\n const send = async (to: string, amount: number) => {\n const connection = new Connection(\"https://api.mainnet-beta.solana.com\");\n const from = new PublicKey(await solana.getPublicKey());\n const recipient = new PublicKey(to);\n\n const fromATA = await getAssociatedTokenAddress(USDC_MINT, from);\n const toATA = await getAssociatedTokenAddress(USDC_MINT, recipient);\n\n const instructions = [];\n\n // Create recipient's token account if it doesn't exist\n try {\n await getAccount(connection, toATA);\n } catch {\n instructions.push(\n createAssociatedTokenAccountInstruction(from, toATA, recipient, USDC_MINT)\n );\n }\n\n // Add transfer instruction\n instructions.push(\n createTransferInstruction(fromATA, toATA, from, amount * 10 ** USDC_DECIMALS)\n );\n\n const { blockhash } = await connection.getLatestBlockhash();\n const transaction = new VersionedTransaction(\n new TransactionMessage({\n payerKey: from,\n recentBlockhash: blockhash,\n instructions,\n }).compileToV0Message()\n );\n\n const { signature } = await solana.signAndSendTransaction(transaction);\n return signature;\n };\n\n return (\n <button onClick={() => send(\"RECIPIENT_ADDRESS\", 10)}>\n Send 10 USDC\n </button>\n );\n}\nimport { BrowserSDK, AddressType } from \"@phantom/browser-sdk\";\nimport { Connection, PublicKey, VersionedTransaction, TransactionMessage } from \"@solana/web3.js\";\nimport { getAssociatedTokenAddress, createAssociatedTokenAccountInstruction, createTransferInstruction, getAccount } from \"@solana/spl-token\";\n\nconst USDC_MINT = new PublicKey(\"EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v\");\nconst USDC_DECIMALS = 6;\n\nconst sdk = new BrowserSDK({\n providers: [\"google\", \"apple\", \"injected\"],\n appId: \"your-app-id\",\n addressTypes: [AddressType.solana],\n});\n\nasync function sendUSDC(to: string, amount: number) {\n const connection = new Connection(\"https://api.mainnet-beta.solana.com\");\n const from = new PublicKey(await sdk.solana.getPublicKey());\n const recipient = new PublicKey(to);\n\n const fromATA = await getAssociatedTokenAddress(USDC_MINT, from);\n const toATA = await getAssociatedTokenAddress(USDC_MINT, recipient);\n\n const instructions = [];\n\n try {\n await getAccount(connection, toATA);\n } catch {\n instructions.push(\n createAssociatedTokenAccountInstruction(from, toATA, recipient, USDC_MINT)\n );\n }\n\n instructions.push(\n createTransferInstruction(fromATA, toATA, from, amount * 10 ** USDC_DECIMALS)\n );\n\n const { blockhash } = await connection.getLatestBlockhash();\n const transaction = new VersionedTransaction(\n new TransactionMessage({\n payerKey: from,\n recentBlockhash: blockhash,\n instructions,\n }).compileToV0Message()\n );\n\n const { signature } = await sdk.solana.signAndSendTransaction(transaction);\n return signature;\n}\nimport { useSolana } from \"@phantom/react-native-sdk\";\nimport { Connection, PublicKey, VersionedTransaction, TransactionMessage } from \"@solana/web3.js\";\nimport { getAssociatedTokenAddress, createAssociatedTokenAccountInstruction, createTransferInstruction, getAccount } from \"@solana/spl-token\";\nimport { View, Button, Alert, StyleSheet } from \"react-native\";\n\nconst USDC_MINT = new PublicKey(\"EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v\");\nconst USDC_DECIMALS = 6;\n\nfunction SendUSDC() {\n const { solana } = useSolana();\n\n const send = async (to: string, amount: number) => {\n try {\n const connection = new Connection(\"https://api.mainnet-beta.solana.com\");\n const from = new PublicKey(await solana.getPublicKey());\n const recipient = new PublicKey(to);\n\n const fromATA = await getAssociatedTokenAddress(USDC_MINT, from);\n const toATA = await getAssociatedTokenAddress(USDC_MINT, recipient);\n\n const instructions = [];\n\n try {\n await getAccount(connection, toATA);\n } catch {\n instructions.push(\n createAssociatedTokenAccountInstruction(from, toATA, recipient, USDC_MINT)\n );\n }\n\n instructions.push(\n createTransferInstruction(fromATA, toATA, from, amount * 10 ** USDC_DECIMALS)\n );\n\n const { blockhash } = await connection.getLatestBlockhash();\n const transaction = new VersionedTransaction(\n new TransactionMessage({\n payerKey: from,\n recentBlockhash: blockhash,\n instructions,\n }).compileToV0Message()\n );\n\n const { signature } = await solana.signAndSendTransaction(transaction);\n Alert.alert(\"Success\", `Transaction sent: ${signature}`);\n return signature;\n } catch (error) {\n Alert.alert(\"Error\", error instanceof Error ? error.message : \"Transaction failed\");\n throw error;\n }\n };\n\n return (\n <View style={styles.container}>\n <Button\n title=\"Send 10 USDC\"\n onPress={() => send(\"RECIPIENT_ADDRESS\", 10)}\n />\n </View>\n );\n}\n\nconst styles = StyleSheet.create({\n container: {\n padding: 20,\n },\n});\n\n​Token addresses\nTokenMint AddressDecimalsUSDCEPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v6USDTEs9vMFrzaCERmJfrF4H2FYD4KCoNkY11McCe8BenwNYB6Was this page helpful?","tokens":1339,"squid":"spider-10","role":"Tooling Spider","at":1791339982899,"hash":"afeebe448e4e618d5792f826a92bca0ad81296e8"}
{"url":"https://forum.arbitrum.foundation/t/aie-wallet-insight-multichain-wallet-analysis-full-public-case-study/31184/5","domain":"forum.arbitrum.foundation","title":"AIE - Wallet Insight | Multichain Wallet Analysis - Full Public Case Study - Archive / Sales Pitch by Service Providers - Arbitrum","text":"The Arbitrum Foundation notified the Security Council on the need to perform a potential Emergency action. Following a review of the details and known risks, the Security Council decided to execute the upgrade and it was completed at 11:30 EST on 2nd October 2026.\nThis report provides an overview of the risks that required the Security Council Action:\n\nAdd a permissionless guard for the One-Step Proof of BoLD on Arbitrum One\n\nTemporarily pause activation of new Stylus contracts on Arbitrum One & Nova\n\nKey point: To date, known bugs for Stylus primarily impact chain liveness (e.g., denial of service attacks) and do not put any user funds at risk.\nWhy was this action taken\nLet’s take this opportunity to explain why action was taken on two separate issues concerning BoLD and Stylus.\nInstalling the guard for One-Step Proof of BoLD. Given the rise of AI-assisted attacks, we have implemented a precautionary approach that allows anyone to pause settlement of Arbitrum One on Ethereum if there are at least two conflicting answers that pass at the same level in which only one should be valid and pass. This is to halt a class of publicly verifiable and detectable attacks that exploit a bug in the one-step proof. If halted, Arbitrum One will continue to process as normal except that messages from Arbitrum One to Ethereum, such as withdrawals, that are not yet confirmed will have to wait. This provides time for the Security Council to deploy a fix for the bug and resume the rollup.\nPreventing activation of new Stylus contracts. AI-assisted tooling has led to an increasing number of sophisticated attacks on hand-crafted WASM programs that do not use the standard Stylus compiler toolchain. These programs are specifically designed to cause unexpected behaviors such as degrading the chain’s performance for all other users. To date, no attacks have been discovered that permits theft of user funds.\nNew ArbOS releases have patched several reported bugs and known attacks over the past few months, but out of an abundance of caution, we have decided to temporarily pause new activations of Stylus contracts. This was executed as an emergency action to prevent the deployment of new hand-crafted WASM programs that are not yet patched by the current version of ArbOS on the Arbitrum network.\nThe Arbitrum Foundation has informed the Security Council that they will work with the ArbitrumDAO to discuss next steps on the timeline and manner for enabling activation of new Stylus contracts. The Arbitrum community remains confident in the value of Stylus and want to preserve these use cases while taking preventative measures against Stylus-based attack vectors as AI-assisted attack tooling continues to evolve.\nImpact on builders and users\n\nNo new activations. New Stylus contracts cannot be activated during the pause including new versions of existing applications that require activation.\n\nExisting contracts are not paused. Already-active Stylus contracts continue to execute until expiration. This pause does not deactivate them.\n\nThe ArbOS 61 upgrade renewed all active contracts on Arbitrum One, so no currently active contract expires before August 20, 2027.\n\nRenewal via keepalive stays permissionless and is unaffected by the pause.\n\nReactivating an expired contract, or one that needs to be updated after a Stylus version change, is paused.\n\nUsing/calling any activated Stylus contract stays permissionless for all users and developers.\n\nNo impact on EVM. Solidity (EVM) contract deployment and execution are unaffected by this Security Council action.\n\nSecurity Council Actions\nThere are two actions bundled into a single payload:\n\nOne-Step Proof Guard. The L1UpgradeExecutor gives a new pause contract (PauseExecutor) the ability to pause and nothing else. The new pause contract grants the guard (OspSoundnessGuard) PAUSER_ROLE to use it. Anyone can show the guard two conflicting answers to the same step of an open challenge. If the one-step proof accepts both, the guard has the pause contract put Arbitrum One’s settlement to Ethereum on hold.\n\nStylus deactivation. The Security Council called ArbOwner.setWasmActivationGas(2^64 - 1) to raise the Stylus activation gas requirement on Arbitrum One and Nova. This makes activation prohibitively expensive and effectively disables new activations. This is a configuration change and does not require an ArbOS upgrade.\n\nThe Security Council signed the following transactions to update the configuration:\n\nEthereum: Ethereum Transaction Hash: 0x30732bb7d2... | Etherscan\nArbitrum One:\nArbitrum One Transaction Hash: 0x9eb3a4be3b... | Arbitrum One\nArbitrum Nova:\nArbitrum Nova transaction 0x79e0fed470dff7a22059b108e3f8f42eddd2b580a6771594060c4e7326c5f984 | Blockscout\n\nAn external audit was conducted for the OSP Guard contracts. No audit is required for the Stylus deactivation as it is only updating a single parameter in the ArbOS configuration.\n\n ArchiveSales Pitch by Service Providers\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 7\n min\n\n Aug 9\n\n 5 / 5\n\n Aug 9\n\n Aug 10\n\n post by cxclrfx on Aug 9\n\n cxclrfx\n\n Continuing the discussion from AIE - Airdrop Integrity | Private Institutional Airdrop Analysis: # AIE - Wallet Insight\nMultichain Wallet Analysis - Full Public Case Study\nA wallet address is easy to look up.\nUnderstanding what that wallet actually did is a different problem.\nFor protocols, treasuries, exchanges, auditors, investigators, security teams, funds, counterparties and users preparing high-value transfers, an explorer page is not enough when a decision depends on the difference between:\n\nan address appearing on a network and actually using that network;\nan inbound transfer and an owner-originated action;\na displayed token and an economically qualified asset;\nan explorer valuation and defensible portfolio value;\na bridge appearance and a reconstructed cross-chain journey;\nunsolicited dust and genuine wallet behavior;\na generic risk label and evidence that can actually be reviewed.\n\nAIE - Wallet Insight is built for that distinction.\nRather than describing the service abstractly, below is a complete public multichain case study showing the type of result a client receives.\n\nSubject\nAddress: 0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045\nEnvironment: EVM Multichain\nAnalysis: AIE - Wallet Insight\nEvidence level: EVIDENCE ANCHORED\nWallet connection required: No\nSignature required: No\nPrivate key or seed phrase required: Never\nThe address is public and carries the public explorer label vitalik.eth / Vb 5.\nThe identity label is not used as analytical evidence. The analysis concerns the public blockchain address and its observable activity.\n\nExecutive Conclusion\nA conventional multichain explorer currently presents this address as having token holdings across 31 networks, more than 100,000 address-associated records, and approximately $1.13M of raw aggregated portfolio value.\nThose numbers are real explorer outputs.\nThey are not the AIE conclusion.\nAIE separates four questions:\nNETWORK PRESENCE → CONTROL EVIDENCE → ASSET PROVENANCE → QUALIFIED VALUE\nThe same hexadecimal address appearing on multiple EVM networks does not prove that the address actively used every one of those networks.\nAnyone can send ETH, tokens, NFTs or dust to a public address.\nLikewise, a token appearing in an explorer does not prove that the controller intentionally acquired it, and an explorer-supplied price does not automatically make that token part of a defensible portfolio valuation.\nPrimary findings\nMultichain presence: CONFIRMED\nActive multichain use: CONFIRMED, but materially narrower than raw network presence\nEthereum activity: CONFIRMED\nBase activity: CONFIRMED\nOptimism activity: CONFIRMED\nArbitrum activity: CONFIRMED\nHistorical activity on additional networks: CONFIRMED\nLarge passive/inbound footprint: CONFIRMED\nUnsolicited-token contamination: HIGH\nRaw explorer portfolio reliability: LOW WITHOUT ASSET QUALIFICATION\nDelegated account behavior: CONFIRMED\nDeFi interaction: CONFIRMED\nCurrent compromise: NOT ESTABLISHED\nMixer exposure: NOT ESTABLISHED IN THIS BASE REVIEW\nSanctions determination: NOT ISSUED WITHOUT QUALIFIED REFERENCE EVIDENCE\nThe result is therefore not reduced to a single arbitrary Risk Score.\nThe client receives the individual findings, their evidence status and the distinction between what the wallet demonstrably did and what merely appeared around it.\n\n1. Multichain Discovery\nThe current Blockscan view exposes 34 explorer/network entries and token holdings across 31 networks.\nAt the time of this case-study snapshot, the largest raw explorer-displayed values are approximately:\n\nNetwork\nRaw displayed value\n\nEthereum\n$857K+\n\nBlast\n$128K+\n\nBase\n$86K+\n\nBNB Chain\n$52K+\n\nOptimism\n$7K+\n\nArbitrum One\n$859\n\nPolygon\n$699\n\nTaiko\n$192\n\nWorld\n$123\n\nUnichain\n$63\n\nLinea\n$19\n\nAdditional networks\nsmaller balances\n\nThese figures are discovery data.\nThey are not automatically accepted as AIE-qualified owner holdings.\nThat distinction becomes important immediately.\n\n2. Presence Is Not Usage\nAIE does not mark a network as actively used simply because the same address exists there or because tokens have been sent to it.\nFor every network, we independently look for address-originated evidence.\nThe classification model is:\nACTIVE - CONTROL CONFIRMED\nThe address has initiated activity that demonstrates use of the account on that network.\nHISTORICAL ACTIVE\nOutgoing use is established, but the activity belongs to an earlier period.\nPRESENCE ONLY\nAssets or transactions involving the address exist, but local owner-originated activity has not been established.\nUNQUALIFIED\nThe network requires additional evidence before a behavioral conclusion is issued.\nThis prevents the common but incorrect transformation:\nsame address found on 31 chains\ninto:\nowner actively uses 31 chains\nThose are not equivalent statements.\n\n3. Ethereum\nEthereum is the largest network by raw displayed value in the current explorer portfolio.\nThe address has genuine owner-originated activity and contract interaction history.\nTherefore:\nPresence: CONFIRMED\nControl/use: CONFIRMED\nActivity: ACTIVE\nContract interaction: CONFIRMED\nNative asset presence: CONFIRMED\nBut Ethereum also demonstrates the asset-qualification problem.\nSeveral tokens account for a very large share of the raw explorer valuation. Current explorer allocation data includes very large nominal values attributed to tokens such as WHITE, CATE, MOO DENG and KNC.\nAIE does not simply copy those balances into:\n\n“Verified owner wealth: $1.13M.”\n\nFor every material asset, the analytical questions are different:\n\nWhat is the exact token contract?\nHow did the asset arrive?\nWas it acquired through an address-originated transaction?\nWas it transferred unsolicited?\nDoes a legitimate market exist for this exact contract?\nIs the explorer price mapped to the correct asset?\nIs there sufficient liquidity to treat the displayed price as economically meaningful?\nHas the subject ever interacted with the token?\n\nUntil those questions are qualified, the value remains displayed value, not qualified owner value.\n\n4. Base - Active Use Confirmed\nBase gives strong evidence of actual control and use.\nThe explorer records address-originated transactions and a substantial contract-interaction history.\nOn 1 May 2026 alone, the address executed a compact sequence of transactions involving Uniswap V2 Router02 and Uniswap V3 Swap Router02, including multiple ETH-valued transactions within minutes.\nThe Base history also contains interactions with LI.FI Diamond.\nTherefore:\nBase presence: CONFIRMED\nBase control: CONFIRMED\nAddress-originated activity: CONFIRMED\nDEX interaction: CONFIRMED\nDeFi activity: CONFIRMED\nCross-chain infrastructure interaction: OBSERVED\nThis is fundamentally stronger evidence than merely receiving a token on a network.\n\n5. Delegated Account State\nThe address cannot be treated everywhere as a simple traditional EOA and analyzed solely as:\nprivate key → transaction\nCurrent explorer state identifies it as an Authority with delegated execution state, including an EIP-7702 delegation on Base and other observed networks.\nAIE classification\nTraditional EOA-only model: NOT SUFFICIENT\nDelegated account behavior: CONFIRMED\nExecution-model complexity: ELEVATED\nCompromise indication from delegation alone: NONE\nDelegation is not itself malicious.\nIt means that a professional wallet review must understand the current execution model of the account instead of stopping after identifying the hexadecimal address.\n\n6. Blast - The Valuation Anomaly\nBlast is one of the clearest examples in this case.\nThe explorer currently shows approximately $128,205 of token holdings for the address.\nApproximately 190 million DUCKIE account for almost all of that displayed value.\nAt the same time, BlastScan reports:\nTransactions Sent: N/A\nThe same address page also contains unsolicited-looking token/NFT material with reward and promotional naming.\nA naive portfolio interpretation could therefore produce:\n\n“The owner uses Blast and owns approximately $128K there.”\n\nAIE does not make that statement.\nThe evidence supports:\nBlast presence: CONFIRMED\nInbound asset presence: CONFIRMED\nAddress-originated Blast transaction: NOT OBSERVED IN THE BASE REVIEW\nIntentional DUCKIE acquisition: NOT ESTABLISHED\nOwner-qualified Blast portfolio value: NOT DERIVED FROM THE RAW EXPLORER FIGURE\nThis one network represents more than ten percent of the raw multichain portfolio display while local owner-originated use is not established.\nThat is the difference between displaying blockchain data and interpreting it.\n\n7. Passive Networks and Unsolicited Assets\nThe address has additional networks where assets exist but owner-originated activity is absent or not sufficiently established in the base review.\nAIE keeps those networks in the wallet record.\nIt does not silently promote them into behavioral history.\nThe correct distinction is:\nAsset received: YES\ndoes not imply:\nOwner chose this asset: YES\nand:\nAddress exists on network: YES\ndoes not imply:\nOwner actively used network: YES\nThis matters particularly for highly visible public addresses because they attract:\n\nunsolicited tokens;\npromotional NFTs;\ndust;\nvanity transfers;\naddress-poisoning attempts;\nfake reward assets;\nmemecoins;\nautomated distribution campaigns;\ntransfers made purely because the address is publicly known.\n\nThese events remain evidence.\nThey are simply evidence of incoming activity, not automatically evidence of subject behavior.\n\n8. Dust and Micro-Transfer Discipline\nAIE records incoming micro-transfers without assigning them to the wallet controller.\nFor a typical event:\nexternal address → 0.00001 ETH → subject\nthe base finding is:\nTransfer: CONFIRMED\nDirection: INBOUND\nSubject initiated transaction: NO\nRelationship to sender: NOT ASSUMED\nSender intent: NOT ATTRIBUTED IN BASE WALLET INSIGHT\nThis prevents inbound dust from contaminating the wallet biography.\nIf the client needs to know who is sending the dust and why, that becomes a different investigative question.\n\n9. Dust / Spam Attribution - Extended Investigation\nA Wallet Insight identifies and separates unsolicited activity.\nA deeper investigation can then move outward from the subject wallet and examine the infrastructure behind it.\nThat expansion can determine:\n\noriginating addresses;\nrepeated sender clusters;\ncommon funding sources;\ntoken and NFT deployers;\nidentical campaigns across networks;\nautomated distribution infrastructure;\naddress-poisoning patterns;\nphishing-style token/NFT campaigns;\nrepeated timing signatures;\nshared contract relationships;\nlinks between apparently unrelated sender addresses;\nattributable entities where evidence supports attribution.\n\nThe result can move from:\n“Unsolicited transfers detected.”\nto:\n“These transfers were generated by this sender cluster, funded through this path, using these contracts, across these networks.”\nThis is separately scoped because the object of investigation has expanded beyond the subject wallet.\n\n10. Cross-Chain / Bridge Layer\nThe public history contains interactions involving cross-chain infrastructure, including LI.FI and other bridge-related systems.\nAIE does not turn the mere appearance of a bridge contract into a fabricated journey.\nFor example, seeing:\nsubject ↔ bridge infrastructure\nis not yet sufficient to claim:\nEthereum → Bridge → Base → Swap\nA complete cross-chain journey requires correlation of:\n\nsource transaction;\nsource asset;\nsource amount;\nbridge/router event;\ntiming;\ndestination settlement;\ndestination asset;\ndestination transaction;\nsubsequent movement.\n\nEach link receives an evidence state:\nCONFIRMED\nEVIDENCE-SUPPORTED\nUNRESOLVED\nBase Wallet Insight\nBridge infrastructure involvement: OBSERVED\nExtended Cross-Chain Reconstruction\nA complete reconstruction can produce:\nsource chain\n↓\nsource transaction\n↓\nbridge/router\n↓\ndestination settlement\n↓\ndestination wallet state\n↓\nsubsequent transaction\nThis is particularly useful when an investigation cannot be understood correctly from a single chain.\n\n11. DeFi Footprint\nThe wallet has genuine DeFi activity.\nCurrent multichain explorer data identifies Uniswap positions, while Base independently shows owner-originated Uniswap interactions.\nTherefore:\nDeFi participation: CONFIRMED\nDEX activity: CONFIRMED\nUniswap interaction: CONFIRMED\nAgain, this conclusion is based on address-originated evidence.\nIt is not inferred from somebody sending a DeFi-related token to the address.\n\n12. Approval and Execution Exposure\nWallet security cannot be determined from balances alone.\nDepending on the network and account state, exposure can also exist through:\n\nERC-20 allowances;\nunlimited token approvals;\nERC-721 operator approvals;\nERC-1155 operator approvals;\ndelegated execution;\nspender contracts;\nsmart-account authorization state.\n\nApprovals are network-specific.\nAn Ethereum approval is not automatically a Base approval.\nA Base approval is not automatically an Arbitrum approval.\nA full Approval Exposure expansion can produce:\nnetwork → asset → spender → allowance → limited/unlimited → spender identity → current relevance → evidence\nThis is available when the client’s question requires full authorization mapping rather than base wallet characterization.\n\n13. Transaction Count Integrity\nBlockscan currently reports more than 100,000 address-associated records in its multichain view.\nThat must not be converted into:\n\n“The wallet performed more than 100,000 transactions.”\n\nFor a widely known public address, a large proportion of the observable record can consist of activity toward or around the address, not activity initiated by it.\nAIE therefore keeps separate counts for:\nExplorer-associated records\nand\nAddress-originated actions\nIncoming noise does not become owner behavior merely because it appears on the same explorer page.\n\n14. Raw Portfolio vs Qualified Portfolio\nThis case demonstrates one of the most important Wallet Insight rules.\nExplorer view\nRaw multichain net worth: approximately $1.13M\nAIE view\nThat number is not automatically accepted as verified owner wealth.\nAIE separates:\nConfirmed native balance\nEconomically supported holdings\nAssets with unresolved provenance\nUnsolicited assets\nDust/spam assets\nUnverified token valuations\nPassive-network receipts\nAssets requiring liquidity/market qualification\nOnly after qualification can these components be consolidated into an evidence-backed portfolio view.\nPortfolio verdict\nRaw explorer value: AVAILABLE\nRaw explorer value accepted as qualified owner wealth: NO\nUnsolicited/unqualified asset contamination: HIGH\nQualified aggregate value: DERIVED ONLY AFTER ASSET-PROVENANCE FILTERING\n\n15. Risk Summary\n\nDimension\nAssessment\n\nMultichain control\nCONFIRMED, SELECTIVE\n\nEthereum activity\nACTIVE\n\nBase activity\nACTIVE\n\nOptimism activity\nCONFIRMED\n\nArbitrum activity\nCONFIRMED\n\nAdditional historical network use\nCONFIRMED\n\nPassive-network footprint\nLARGE\n\nUnsolicited asset contamination\nHIGH\n\nRaw portfolio reliability\nLOW WITHOUT QUALIFICATION\n\nDelegated-account complexity\nELEVATED\n\nDeFi activity\nCONFIRMED\n\nCurrent compromise\nNOT ESTABLISHED\n\nMixer exposure\nNOT ESTABLISHED IN BASE REVIEW\n\nIllicit-owner attribution\nNOT ESTABLISHED\n\nSanctions determination\nNOT ISSUED IN THIS PUBLIC CASE STUDY\n\nAIE does not substitute a single unexplained number such as:\nRisk Score: 87\nfor these independent findings.\nA decision-maker receives the actual dimensions, evidence and unresolved areas.\n\n16. What This Case Demonstrates\nA conventional explorer can show that:\n\nan address appears across many networks;\nthousands of tokens have reached it;\nmore than 100,000 records are associated with it;\nthe displayed portfolio is worth approximately $1.13M.\n\nWallet Insight answers different questions:\nWhich networks show actual control?\nWhich transactions were initiated by the subject?\nWhich assets merely arrived from third parties?\nWhich holdings have defensible provenance?\nWhich valuations can be qualified?\nWhich DeFi interactions are real subject behavior?\nWhich cross-chain relationships are actually proven?\nWhich events are noise, dust or unsolicited activity?\nWhere does the evidence stop?\nThat distinction is the product.\n\n17. Beyond Wallet Insight\nWallet Insight is one entry point into the wider AIE analytical environment.\nWhen the problem extends beyond a single wallet, additional work can cover:\nTransaction Journey / Provenance\nReconstruction of the movement of assets through addresses, contracts, services and networks.\nCounterparty & Entity Graph\nRecurring counterparties, concentration, transaction direction, relationship structure and evidence-supported entity attribution.\nCross-Chain Journey Reconstruction\nSource-chain transaction through bridge/router infrastructure to destination settlement and subsequent movement.\nDust / Spam / Poisoning Attribution\nSender infrastructure, clusters, deployers, campaign relationships and funding paths.\nApproval Exposure\nNetwork-by-network reconstruction of token, NFT and delegated execution permissions.\nMixer / Flow Investigation\nExpansion of transaction provenance where obfuscation infrastructure or complex flow decomposition requires dedicated analysis.\nAML / Sanctions Evidence Layer\nSeparate qualification against appropriate evidence sources and frozen reference states when compliance conclusions are required.\nAirdrop Integrity\nIndependent analysis of distribution structure, wallet relationships, Sybil/coordinated behavior and reviewable evidence - the AIE service linked to this topic.\nThe analytical question determines the scope.\nA client does not need to purchase an unnecessary investigation simply because the capability exists.\n\n18. Who This Is For\nWallet Insight is designed for cases where a wallet address is part of an actual decision.\nExamples include:\n\na protocol evaluating a wallet or counterparty;\na treasury before a significant transfer;\na fund reviewing historical wallet behavior;\nan exchange or compliance team requiring an independent second view;\nan investigator following assets across chains;\na project reviewing participants or counterparties;\na security team investigating suspicious inbound activity;\nan auditor who needs blockchain evidence rather than a screenshot;\na user who wants to know what is actually behind an address before sending substantial funds.\n\nThe input can be as simple as:\none public wallet address + the question that needs to be answered.\n\n19. Evidence Standard\nThe base result distinguishes between:\nCONFIRMED\nDirect evidence supports the finding.\nEVIDENCE-SUPPORTED\nMultiple observable facts support the conclusion, but the result remains qualified.\nUNRESOLVED\nAvailable evidence is insufficient for attribution or conclusion.\nNOT ESTABLISHED\nThe reviewed evidence does not establish the claimed condition.\nThe purpose is not to fill every field.\nThe purpose is to avoid turning missing evidence into invented certainty.\nReproducibility classification for this public demonstration\nEVIDENCE ANCHORED\nThis public case study does not claim full REPLAY CAPABLE status because a frozen raw RPC/reference-snapshot bundle is not being distributed with the forum post.\n\nFinal Client Verdict\nSubject: 0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045\nMultichain presence: CONFIRMED\nActive use of every observed network: NO\nActive multichain use: CONFIRMED\nLarge passive/inbound footprint: CONFIRMED\nRaw explorer portfolio: approximately $1.13M at snapshot\nRaw portfolio accepted as owner-qualified wealth: NO\nUnsolicited/unqualified asset contamination: HIGH\nDelegated account behavior: CONFIRMED\nDeFi activity: CONFIRMED\nCurrent compromise: NOT ESTABLISHED\nKey Finding\n31 networks with displayed holdings do not mean 31 actively used networks.\nMore than 100,000 associated records do not mean more than 100,000 owner-originated actions.\nApproximately $1.13M displayed by an explorer does not automatically mean approximately $1.13M of evidence-qualified owner assets.\nInbound dust, tokens and NFTs do not become owner behavior simply because they reached the address.\nAIE separates those questions and returns the evidence behind each answer.\n\nAvailability for the Arbitrum Community\nAIE - Wallet Insight is available for wallet-level analysis.\nForum users, protocols, organizations and teams can submit a public wallet address together with the question they need answered.\nNo wallet connection is required.\nNo signing request is required.\nNo access to the wallet is required.\nNo private key or seed phrase is ever requested.\nThe base analysis remains focused on the subject wallet.\nInvestigations that expand into external addresses, sender infrastructure, bridge paths, counterparties, mixer/provenance analysis, approval mapping or attribution are separately scoped according to the analytical work required.\n\nResponse Time\nRequests are acknowledged within minutes.\nFor a standard AIE - Wallet Insight, once the public wallet address and analytical scope are confirmed, the result is normally delivered on a minutes-scale.\nMore extensive graph reconstruction, cross-chain attribution or third-party infrastructure investigations are handled separately according to depth.\nSend the public wallet address and the question you need answered.\nAIE\n\n 3\n\n 2\n\n read \n\n 7\n min\n\n post by Anzus_GemWallet on Aug 10\n\n Anzus_GemWallet\n\n Interesting breakdown. From a user-support perspective, it is important to remind people that receiving an unknown token or NFT does not mean they need to interact with it.\nClear network labels and simple warnings can make a big difference, especially for users managing assets across several chains.\nI work with Gem Wallet, and this is useful feedback for wallet teams as well.\n\n post by cxclrfx on Aug 10\n\n cxclrfx\n\n That point has its place, but it stops at the warning layer. Most users do not read every warning, and they should not have to become transaction analysts simply to keep their assets safe.\nWarnings tell a user where danger may be. They do not prevent danger from becoming execution.\nI went further. I built a protection architecture in which, under one operating rule, a protected asset cannot be stolen. Whether the initiating cause is an honest mistake or malicious control is irrelevant: the forbidden state transition cannot complete.\nAfter your comment, I reviewed the relevant public transaction-state code paths in Gem and the current issue/patch chain. The recurring failures do not form a set of isolated UI defects. They converge on one deeper architectural break: transaction identity, origin, local semantics, polling lifetime and wallet state are not carried by one canonical transaction object under one state authority from request through final history.\nAn audit can identify individual manifestations, and a local patch can close each observed symptom. But when state ownership remains fragmented, every new exception adds another branch around the same unresolved boundary and makes the architecture harder to reason about as a whole.\nThe next step is therefore not another warning and not another isolated patch. It is one execution invariant that cannot be bypassed.\nWhere, in Gem’s current architecture, is the boundary that makes an unauthorized transfer impossible rather than merely warning the user before it happens?\n\n post by Anzus_GemWallet on Aug 10\n\n Anzus_GemWallet\n\n Thanks for taking the time to review this. I work in BD and user support, so I’m not able to confirm or discuss architecture or security findings here.\nIf you have a reproducible issue, affected version, and relevant code references, please send the details to security@gemwallet.com under Gem Wallet’s security policy. This allows the security team to review it responsibly.\nI’ll also make sure your concern is passed on. Gem Wallet\n\n post by cxclrfx on Aug 10\n\n cxclrfx\n\n My review of Gem’s public code, issue history, and patch sequence points to one shared architectural discontinuity, not a collection of isolated bugs. The failures surface in different places, but converge on transaction identity, provenance, state ownership, synchronization, and lifecycle. Treating them as separate tickets can close individual symptoms while leaving the common cause intact.\nThis is an architectural problem expressed through a chain of related failures, not a conventional isolated vulnerability. If Gem wants to examine the full dependency chain and the existing protection model, the person responsible for Gem’s architectural direction can contact directly. This requires architectural work rather than being a conventional bug-bounty submission.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n AIE - Airdrop Integrity | Private Institutional Airdrop Analysis\n\n Sales Pitch by Service Providers\n\n 4\n\n 93\n\n Aug 1\n\n [Discussion] ChainTrace v2.0: Interactive AML Simulation for Mixer & Peel Chain Detection\n\n General\n\n proposal,governance\n\n 10\n\n 127\n\n Aug 4\n\n Open Theft Signal for Arbitrum: Victim-Activated Wallet Risk Layer\n\n Early Idea Discussion\n\n 1\n\n 70\n\n Jul 30\n\n Entropy Advisors Data Dashboards Catalog\n\n Entropy Advisors Updates\n\n 0\n\n 188\n\n Apr 28\n\n Arbitrum Academic Bridge @ NTUA — Final Grant Report (Ethereum Greece)\n\n Domain Allocator Offerings (prev Questbook)\n\n 10\n\n 170\n\n Aug 10","tokens":7577,"squid":"spider-07","role":"Council Spider","at":1791339990551,"hash":"da867c328d185c0ccbe3b3b5b9360a0a17f084d8"}
{"url":"https://docs.phantom.com/sdks/react-native-sdk/sign-and-send-transaction","domain":"docs.phantom.com","title":"Sign and send transactions - Phantom developer documentation","text":"The Phantom Connect React Native SDK provides chain-specific hooks (useSolana and useEthereum) for signing and sending transactions optimized for mobile platforms.\nTransaction security for embedded wallets: All transactions signed for embedded wallets pass through Phantom’s advanced simulation system before execution. This security layer automatically blocks malicious transactions and transactions from origins that have been reported as malicious, providing an additional layer of protection for your users’ assets.\n​Chain-specific transaction hooks\n​Solana transactions (useSolana)\nimport React from \"react\";\nimport { View, Button, Alert } from \"react-native\";\nimport { useSolana } from \"@phantom/react-native-sdk\";\n\nfunction SolanaTransactions() {\n const { solana } = useSolana();\n\n const sendTransaction = async () => {\n try {\n // Sign and send transaction\n const result = await solana.signAndSendTransaction(transaction);\n Alert.alert(\"Success\", `Transaction sent: ${result.hash}`);\n } catch (error) {\n Alert.alert(\"Error\", `Transaction failed: ${error.message}`);\n }\n };\n\n const signOnly = async () => {\n try {\n // Just sign (without sending)\n const signedTx = await solana.signTransaction(transaction);\n Alert.alert(\"Success\", \"Transaction signed!\");\n } catch (error) {\n Alert.alert(\"Error\", `Signing failed: ${error.message}`);\n }\n };\n\n return (\n <View style={{ padding: 20 }}>\n <Button title=\"Send Transaction\" onPress={sendTransaction} />\n <Button title=\"Sign Only\" onPress={signOnly} />\n </View>\n );\n}\n\n​Ethereum transactions (useEthereum)\nimport React from \"react\";\nimport { View, Button, Alert } from \"react-native\";\nimport { useEthereum } from \"@phantom/react-native-sdk\";\n\nfunction EthereumTransactions() {\n const { ethereum } = useEthereum();\n\n const sendTransaction = async () => {\n try {\n const result = await ethereum.sendTransaction({\n to: \"0x742d35Cc6634C0532925a3b8D4C8db86fB5C4A7E\",\n value: \"1000000000000000000\", // 1 ETH in wei\n gas: \"21000\",\n });\n Alert.alert(\"Success\", `ETH sent: ${result.hash}`);\n } catch (error) {\n Alert.alert(\"Error\", `Transaction failed: ${error.message}`);\n }\n };\n\n return (\n <View style={{ padding: 20 }}>\n <Button title=\"Send ETH\" onPress={sendTransaction} />\n </View>\n );\n}\n\n​Dapp-sponsored transactions\nPass a presignTransaction callback to signAndSendTransaction for Solana transactions that need double signing, such as dapp fee payer flows. Calls without it proceed normally — it is never applied globally.\nPhantom embedded wallets do not accept pre-signed transactions. If your use case requires a second signer (for example, your app as the fee payer), that signing must happen via this callback, after Phantom has constructed and validated the transaction.\npresignTransaction only fires for Solana transactions via the embedded provider. EVM transactions are unaffected.\nimport React from \"react\";\nimport { View, Button, Alert } from \"react-native\";\nimport { useSolana, base64urlDecode, base64urlEncode } from \"@phantom/react-native-sdk\";\n\nfunction SendWithFeeSponsor() {\n const { solana } = useSolana();\n\n const sendSponsored = async () => {\n try {\n const result = await solana.signAndSendTransaction(transaction, {\n presignTransaction: async (tx, context) => {\n // Send the transaction to your backend for fee payer signing\n const response = await fetch(\"https://your-api.com/presign\", {\n method: \"POST\",\n body: JSON.stringify({ transaction: tx, networkId: context.networkId }),\n headers: { \"Content-Type\": \"application/json\" },\n });\n const { transaction: signedTx } = await response.json();\n return signedTx; // base64url-encoded, partially signed by the fee payer\n },\n });\n Alert.alert(\"Success\", `Sponsored transaction sent: ${result.hash}`);\n } catch (error) {\n Alert.alert(\"Error\", `Transaction failed: ${error.message}`);\n }\n };\n\n const sendNormal = async () => {\n try {\n const result = await solana.signAndSendTransaction(transaction);\n Alert.alert(\"Success\", `Transaction sent: ${result.hash}`);\n } catch (error) {\n Alert.alert(\"Error\", `Transaction failed: ${error.message}`);\n }\n };\n\n return (\n <View style={{ padding: 20, gap: 10 }}>\n <Button title=\"Send (Dapp Pays Fees)\" onPress={sendSponsored} />\n <Button title=\"Send (User Pays Fees)\" onPress={sendNormal} />\n </View>\n );\n}\n\nNever hold a fee payer keypair in frontend code. The presignTransaction callback runs on the device — use it to call your own backend, which holds the keypair securely and returns the partially-signed transaction.\n​Complete mobile examples\n​Solana transaction with mobile UI\nimport React, { useState } from \"react\";\nimport { View, Button, TextInput, Alert, Text, StyleSheet } from \"react-native\";\nimport { useSolana } from \"@phantom/react-native-sdk\";\nimport { Transaction, SystemProgram, PublicKey, LAMPORTS_PER_SOL, Connection } from \"@solana/web3.js\";\n\nfunction SolanaMobileTransfer() {\n const { solana } = useSolana();\n const [recipient, setRecipient] = useState(\"\");\n const [amount, setAmount] = useState(\"0.001\");\n const [isLoading, setIsLoading] = useState(false);\n\n const sendSOL = async () => {\n if (!recipient || !amount) {\n Alert.alert(\"Error\", \"Please fill in all fields\");\n return;\n }\n\n setIsLoading(true);\n try {\n // Get connection and recent blockhash\n const connection = new Connection(\"https://api.mainnet-beta.solana.com\");\n const { blockhash } = await connection.getLatestBlockhash();\n\n const fromAddress = await solana.getPublicKey();\n const transferInstruction = SystemProgram.transfer({\n fromPubkey: new PublicKey(fromAddress),\n toPubkey: new PublicKey(recipient),\n lamports: parseFloat(amount) * LAMPORTS_PER_SOL,\n });\n\n const transaction = new Transaction({\n recentBlockhash: blockhash,\n feePayer: new PublicKey(fromAddress),\n }).add(transferInstruction);\n\n const result = await solana.signAndSendTransaction(transaction);\n Alert.alert(\n \"Success!\", \n `Sent ${amount} SOL\\nTransaction: ${result.hash}`,\n [{ text: \"OK\" }]\n );\n } catch (error) {\n Alert.alert(\"Error\", `Failed to send SOL: ${error.message}`);\n } finally {\n setIsLoading(false);\n }\n };\n\n return (\n <View style={styles.container}>\n <Text style={styles.title}>Send Solana</Text>\n\n <TextInput\n style={styles.input}\n placeholder=\"Recipient Address\"\n value={recipient}\n onChangeText={setRecipient}\n multiline\n />\n\n <TextInput\n style={styles.input}\n placeholder=\"Amount (SOL)\"\n value={amount}\n onChangeText={setAmount}\n keyboardType=\"decimal-pad\"\n />\n\n <Button\n title={isLoading ? \"Sending...\" : \"Send SOL\"}\n onPress={sendSOL}\n disabled={isLoading}\n />\n </View>\n );\n}\n\nconst styles = StyleSheet.create({\n container: {\n padding: 20,\n gap: 15,\n },\n title: {\n fontSize: 20,\n fontWeight: \"bold\",\n marginBottom: 10,\n },\n input: {\n borderWidth: 1,\n borderColor: \"#ccc\",\n borderRadius: 8,\n padding: 12,\n fontSize: 16,\n },\n});\n\n​Dapp-sponsored transactions\nBy default, the user’s embedded wallet is the fee payer for all Solana transactions. The presignTransaction hook lets your app co-sign the transaction before the wallet signs it, enabling use cases like:\n\nDapp-as-fee-payer — your app covers the transaction fee so users don’t need SOL\nPlatform fees — add a fee instruction signed by your app’s keypair\nMulti-signer flows — any scenario where the app needs to sign alongside the user’s wallet\n\nPhantom embedded wallets do not accept pre-signed transactions. If your use case requires a second signer, this hook is the only supported approach — your app’s signing must happen after Phantom has constructed and validated the transaction. This restriction does not apply to injected providers (e.g. the Phantom browser extension).\nPass presignTransaction directly to signAndSendTransaction for the specific calls that need it. Calls without it proceed normally — the function is never applied globally.\n​Example: app as fee payer\nimport { useSolana, base64urlDecode, base64urlEncode } from \"@phantom/react-native-sdk\";\nimport { Keypair, VersionedTransaction } from \"@solana/web3.js\";\n\n// Your app's fee payer keypair (keep this on your backend in production)\nconst feePayerKeypair = Keypair.fromSecretKey(/* your fee payer secret key */);\n\nfunction SendWithFeeSponsor() {\n const { solana } = useSolana();\n\n const sendSponsored = async () => {\n const result = await solana.signAndSendTransaction(transaction, {\n presignTransaction: async (tx, context) => {\n // tx: base64url-encoded Solana transaction bytes\n // context: { networkId: string, walletId: string }\n\n // 1. Decode base64url → raw bytes\n const txBytes = base64urlDecode(tx);\n\n // 2. Deserialize\n const versionedTx = VersionedTransaction.deserialize(txBytes);\n\n // 3. Partially sign as fee payer — the user's wallet will sign next\n versionedTx.sign([feePayerKeypair]);\n\n // 4. Re-serialize → encode back to base64url\n return base64urlEncode(versionedTx.serialize());\n },\n });\n console.log(\"Transaction sent:\", result.signature);\n };\n\n // This call has no presignTransaction — proceeds without any co-signing\n const sendNormal = async () => {\n const result = await solana.signAndSendTransaction(transaction);\n console.log(\"Transaction sent:\", result.signature);\n };\n}\n\nThe hook only fires for Solana transactions via the embedded provider. EVM transactions are unaffected.\n​Ethereum transaction with mobile UI\nimport React, { useState } from \"react\";\nimport { View, Button, TextInput, Alert, Text, StyleSheet } from \"react-native\";\nimport { useEthereum } from \"@phantom/react-native-sdk\";\n\nfunction EthereumMobileTransfer() {\n const { ethereum } = useEthereum();\n const [recipient, setRecipient] = useState(\"\");\n const [amount, setAmount] = useState(\"0.001\");\n const [isLoading, setIsLoading] = useState(false);\n\n const sendETH = async () => {\n if (!recipient || !amount) {\n Alert.alert(\"Error\", \"Please fill in all fields\");\n return;\n }\n\n setIsLoading(true);\n try {\n const weiAmount = (parseFloat(amount) * 1e18).toString(); // Convert ETH to wei\n\n const result = await ethereum.sendTransaction({\n to: recipient,\n value: weiAmount,\n gas: \"21000\",\n });\n\n Alert.alert(\n \"Success!\",\n `Sent ${amount} ETH\\nTransaction: ${result.hash}`,\n [{ text: \"OK\" }]\n );\n } catch (error) {\n Alert.alert(\"Error\", `Failed to send ETH: ${error.message}`);\n } finally {\n setIsLoading(false);\n }\n };\n\n return (\n <View style={styles.container}>\n <Text style={styles.title}>Send Ethereum</Text>\n\n <TextInput\n style={styles.input}\n placeholder=\"Recipient Address (0x...)\"\n value={recipient}\n onChangeText={setRecipient}\n autoCapitalize=\"none\"\n />\n\n <TextInput\n style={styles.input}\n placeholder=\"Amount (ETH)\"\n value={amount}\n onChangeText={setAmount}\n keyboardType=\"decimal-pad\"\n />\n\n <Button\n title={isLoading ? \"Sending...\" : \"Send ETH\"}\n onPress={sendETH}\n disabled={isLoading}\n />\n </View>\n );\n}\nWas this page helpful?","tokens":2672,"squid":"spider-10","role":"Tooling Spider","at":1791339993179,"hash":"fb0fe576d49519905eb302f831f2d7ea1d0e1180"}
{"url":"https://forum.arbitrum.foundation/c/general/4","domain":"forum.arbitrum.foundation","title":"Latest General topics - Arbitrum","text":"The Arbitrum Foundation notified the Security Council on the need to perform a potential Emergency action. Following a review of the details and known risks, the Security Council decided to execute the upgrade and it was completed at 11:30 EST on 2nd October 2026.\nThis report provides an overview of the risks that required the Security Council Action:\n\nAdd a permissionless guard for the One-Step Proof of BoLD on Arbitrum One\n\nTemporarily pause activation of new Stylus contracts on Arbitrum One & Nova\n\nKey point: To date, known bugs for Stylus primarily impact chain liveness (e.g., denial of service attacks) and do not put any user funds at risk.\nWhy was this action taken\nLet’s take this opportunity to explain why action was taken on two separate issues concerning BoLD and Stylus.\nInstalling the guard for One-Step Proof of BoLD. Given the rise of AI-assisted attacks, we have implemented a precautionary approach that allows anyone to pause settlement of Arbitrum One on Ethereum if there are at least two conflicting answers that pass at the same level in which only one should be valid and pass. This is to halt a class of publicly verifiable and detectable attacks that exploit a bug in the one-step proof. If halted, Arbitrum One will continue to process as normal except that messages from Arbitrum One to Ethereum, such as withdrawals, that are not yet confirmed will have to wait. This provides time for the Security Council to deploy a fix for the bug and resume the rollup.\nPreventing activation of new Stylus contracts. AI-assisted tooling has led to an increasing number of sophisticated attacks on hand-crafted WASM programs that do not use the standard Stylus compiler toolchain. These programs are specifically designed to cause unexpected behaviors such as degrading the chain’s performance for all other users. To date, no attacks have been discovered that permits theft of user funds.\nNew ArbOS releases have patched several reported bugs and known attacks over the past few months, but out of an abundance of caution, we have decided to temporarily pause new activations of Stylus contracts. This was executed as an emergency action to prevent the deployment of new hand-crafted WASM programs that are not yet patched by the current version of ArbOS on the Arbitrum network.\nThe Arbitrum Foundation has informed the Security Council that they will work with the ArbitrumDAO to discuss next steps on the timeline and manner for enabling activation of new Stylus contracts. The Arbitrum community remains confident in the value of Stylus and want to preserve these use cases while taking preventative measures against Stylus-based attack vectors as AI-assisted attack tooling continues to evolve.\nImpact on builders and users\n\nNo new activations. New Stylus contracts cannot be activated during the pause including new versions of existing applications that require activation.\n\nExisting contracts are not paused. Already-active Stylus contracts continue to execute until expiration. This pause does not deactivate them.\n\nThe ArbOS 61 upgrade renewed all active contracts on Arbitrum One, so no currently active contract expires before August 20, 2027.\n\nRenewal via keepalive stays permissionless and is unaffected by the pause.\n\nReactivating an expired contract, or one that needs to be updated after a Stylus version change, is paused.\n\nUsing/calling any activated Stylus contract stays permissionless for all users and developers.\n\nNo impact on EVM. Solidity (EVM) contract deployment and execution are unaffected by this Security Council action.\n\nSecurity Council Actions\nThere are two actions bundled into a single payload:\n\nOne-Step Proof Guard. The L1UpgradeExecutor gives a new pause contract (PauseExecutor) the ability to pause and nothing else. The new pause contract grants the guard (OspSoundnessGuard) PAUSER_ROLE to use it. Anyone can show the guard two conflicting answers to the same step of an open challenge. If the one-step proof accepts both, the guard has the pause contract put Arbitrum One’s settlement to Ethereum on hold.\n\nStylus deactivation. The Security Council called ArbOwner.setWasmActivationGas(2^64 - 1) to raise the Stylus activation gas requirement on Arbitrum One and Nova. This makes activation prohibitively expensive and effectively disables new activations. This is a configuration change and does not require an ArbOS upgrade.\n\nThe Security Council signed the following transactions to update the configuration:\n\nEthereum: Ethereum Transaction Hash: 0x30732bb7d2... | Etherscan\nArbitrum One:\nArbitrum One Transaction Hash: 0x9eb3a4be3b... | Arbitrum One\nArbitrum Nova:\nArbitrum Nova transaction 0x79e0fed470dff7a22059b108e3f8f42eddd2b580a6771594060c4e7326c5f984 | Blockscout\n\nAn external audit was conducted for the OSP Guard contracts. No audit is required for the Stylus deactivation as it is only updating a single parameter in the ArbOS configuration.\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 The Arbitrum Expansion Program and Developer Guild\n\n TL;DR: In collaboration with Offchain Labs, the Arbitrum Foundation is excited to announce the new Arbitrum Expansion Program and Arbitrum Developer Guild. \nTeams interested in launching Arbitrum technology chains now h…\n\n read more\n\n 3\n\n 7.2k\n\n Aug 2025\n\n Welcome to Discourse\n\n Welcome to the Forum!\nThis forum is dedicated to discussions and exchange of ideas related to governance. \nPlease read the following guidelines carefully to ensure a productive and respectful community. \nStay on topic: T…\n\n read more\n\n 41\n\n 21.7k\n\n Mar 22\n\n About the General category\n\n 0\n\n 566\n\n Mar 2023\n\n StableGuard by FintechCheck: Real-Time Stablecoin Depeg Detection for Treasury & DeFi Protection\n\n proposal,proposal-discussions\n\n 12\n\n 143\n\n 3d\n\n From Governance Token to Utility Token: Evolving ARB Beyond Governance\n\n 35\n\n 1.3k\n\n 5d\n\n Free API with GMX open interest, funding and liquidations next to CEX data.\n\n 2\n\n 47\n\n 7d\n\n What Makes People Stay in an L2 Ecosystem?\n\n 2\n\n 46\n\n 10d\n\n How can small ARB holders participate meaningfully in Arbitrum governance?\n\n 2\n\n 57\n\n 16d\n\n ARB staking for running a validator + value accrual through sequencer fees\n\n 16\n\n 4.2k\n\n Aug 5\n\n Covenant: a declarative smart contract language that deploys to Orbit chains (feedback welcome)\n\n proposal-discussions\n\n 6\n\n 142\n\n Aug 4\n\n [Discussion] ChainTrace v2.0: Interactive AML Simulation for Mixer & Peel Chain Detection\n\n proposal,governance\n\n 10\n\n 127\n\n Aug 4\n\n Looking for 3-5 active delegates: 45-min session on governance workload (PhD research)\n\n 4\n\n 104\n\n Jul 27\n\n Introducing Gem Wallet for Arbitrum — Open-Source Self-Custody and Community Feedback\n\n 2\n\n 73\n\n Jul 26\n\n What Are the Biggest Challenges When Building Enterprise Applications on Arbitrum?\n\n 3\n\n 89\n\n Jul 22\n\n CoBuilders, Building on Arbitrum\n\n 3\n\n 108\n\n Jul 14\n\n Arbitrum Questions lost funds\n\n 19\n\n 3.1k\n\n Jul 6\n\n Introduction about myself \n\n governance\n\n 2\n\n 93\n\n Jun 19\n\n GLT Protocol: Retaining Web2 Users on Arbitrum via Stablecoin Gas Payment and Automated Off-Peak Scheduling\n\n proposal,governance\n\n 5\n\n 109\n\n Jun 18\n\n [Discussion] The Sixth Stage of Democracy: From Institutions to Protocols\n\n 2\n\n 64\n\n Jun 16\n\n Blockworks’ Delegate Activities Wind Down - Arbitrum\n\n delegation,delegate-statements\n\n 0\n\n 72\n\n Jun 1\n\n ATMC Stablecoin Allocation — Morpho Blue Gold-Collateralized Credit Market\n\n proposal,governance,proposal-discussions\n\n 2\n\n 105\n\n May 18\n\n Introducing Governance Tracker (follow proposals across forum, snapshot and tally)\n\n 2\n\n 101\n\n May 11\n\n The Literacy Barrier in DAO Governance: How Technical Complexity Excludes the Global South\n\n governance\n\n 2\n\n 79\n\n May 10\n\n arbdata.com Update: Governance Analytics\n\n 0\n\n 64\n\n Apr 29\n\n Announcement of Dynamic Reserve Price Change\n\n 0\n\n 128\n\n Apr 27\n\n Trinity Protocol Update — German Sovereign Bond Market Live, Multi-Asset Vault Expansion\n\n 1\n\n 71\n\n Apr 21\n\n End of Arbitrum Support on Tally\n\n 1\n\n 132\n\n Apr 20\n\n Draft Arbitrum DAO Problem Register (Request for validation and omissions)\n\n governance\n\n 1\n\n 77\n\n Apr 19\n\n Technical Proposal Review for Arbitrum Treasury and Governance Actions\n\n 1\n\n 71\n\n Apr 6\n\n Proposal Bundling is a Governance Risk - AIPs Must Be Separated\n\n 1\n\n 51\n\n Apr 6","tokens":2080,"squid":"spider-07","role":"Council Spider","at":1791340000717,"hash":"127aa673945c4c489d15167a9e66cd3216878ec6"}
{"url":"https://docs.phantom.com/sdks/react-native-sdk","domain":"docs.phantom.com","title":"Phantom React Native SDK - Phantom developer documentation","text":"The Phantom Connect React Native SDK provides React hooks for connecting to existing Phantom user wallets in your mobile React Native apps with native transaction support across multiple blockchains.\n​Quick start\nGenerate a new Solana project using the Phantom Embedded React Native Starter template.\n npm pnpm yarn bunnpx -y create-solana-dapp@latest -t solana-foundation/templates/community/phantom-embedded-react-native\npnpm create solana-dapp@latest -t solana-foundation/templates/community/phantom-embedded-react-native\nyarn create solana-dapp -t solana-foundation/templates/community/phantom-embedded-react-native\nbun create solana-dapp@latest -t solana-foundation/templates/community/phantom-embedded-react-native\n\nRun the command above in your terminal to get started.\nView template on Solana Templates →\n\n​Features\n\nBuilt for React Native: Works in Expo environments with native modules for authentication\nConnection modal: Built-in modal for initiating wallet connections in mobile apps\nSystem browser authentication: Uses Safari (iOS) and Chrome Custom Tab (Android) for login and redirect handling\nMulti-chain support: Solana (available now), other chains coming soon.\nUser wallet integration: Connects to existing Phantom mobile wallets through browser-based OAuth flows.\n\n​Security\nThe Phantom Connect React Native SDK connects to existing Phantom user wallets:\n\nOAuth authentication with Google, Apple, or custom JWT providers\nPKCE support for secure OAuth flows\nUsers maintain full control of their existing wallets\nIntegration with Phantom’s secure wallet infrastructure\n\n​Prerequisites\nPhantom Portal is not accepting new applications at this time. New sign-ups for Phantom Connect SDK access and new app submissions to the Phantom app directory are paused. Existing Portal apps and App IDs are not affected.\n\nUse an existing app: Sign in to the Phantom Portal and select your app.\nObtain your App ID:\n\nIn Phantom Portal, expand your app in the left navigation, then select Set Up.\nYour App ID appears at the top of the page.\n\nAllowlist your domains and redirect URLs: Add your app’s domains and redirect URLs in the Phantom Portal to enable wallet connections.\n\n​Installation\nnpm install @phantom/react-native-sdk\n\n​Install peer dependencies\n# For Expo projects\nnpx expo install expo-secure-store expo-web-browser expo-auth-session expo-router react-native-svg\n\n# For bare React Native projects (additional setup required)\nnpm install expo-secure-store expo-web-browser expo-auth-session react-native-svg\n\n# Required polyfill for cryptographic operations\nnpm install react-native-get-random-values\n\n​Required polyfill\nYou must polyfill random byte generation to ensure cryptographic operations work properly. Add this import at the very top of your app’s entry point (before any other imports):\n// index.js, App.tsx, or _layout.tsx - MUST be the first import\nimport \"react-native-get-random-values\";\n\nimport { PhantomProvider } from \"@phantom/react-native-sdk\";\n// ... other imports\n\nThe polyfill import must be the first import in your app’s entry point.\n​Configure your app scheme\n​Expo projects\nAdd your custom scheme to app.json:\n{\n \"expo\": {\n \"name\": \"My Wallet App\",\n \"slug\": \"my-wallet-app\",\n \"scheme\": \"mywalletapp\",\n \"plugins\": [\"expo-router\", \"expo-secure-store\", \"expo-web-browser\", \"expo-auth-session\"]\n }\n}\n\n​Quick start\n// App.tsx or _layout.tsx (for Expo Router)\nimport { PhantomProvider, AddressType, darkTheme } from \"@phantom/react-native-sdk\";\n\nexport default function App() {\n return (\n <PhantomProvider\n config={{\n providers: [\"google\", \"apple\"], // Enabled auth providers for React Native\n appId: \"your-app-id\",\n scheme: \"mywalletapp\",\n addressTypes: [AddressType.solana],\n authOptions: {\n redirectUrl: \"mywalletapp://phantom-auth-callback\",\n },\n }}\n theme={darkTheme} // Optional: Customize modal appearance\n appIcon=\"https://your-app.com/icon.png\" // Optional: Your app icon\n appName=\"Your App Name\" // Optional: Your app name\n >\n <WalletScreen />\n </PhantomProvider>\n );\n}\n\n// WalletScreen.tsx\nimport { View, Button, Text } from \"react-native\";\nimport { useModal, usePhantom } from \"@phantom/react-native-sdk\";\n\nexport function WalletScreen() {\n const { open, close, isOpened } = useModal();\n const { isConnected } = usePhantom();\n\n if (isConnected) {\n return (\n <View style={{ padding: 20 }}>\n <Text>Connected</Text>\n </View>\n );\n }\n\n return (\n <View style={{ padding: 20 }}>\n <Button title=\"Connect Wallet\" onPress={open} />\n </View>\n );\n}\n\n​Use the connection modal (Recommended)\nThe SDK includes a built-in bottom sheet modal that provides a user-friendly interface for connecting to Phantom. The modal supports multiple authentication methods (Google, Apple) and handles all connection logic automatically.\n// WalletScreen.tsx\nimport React from \"react\";\nimport { View, Button, Text } from \"react-native\";\nimport { useModal, useAccounts } from \"@phantom/react-native-sdk\";\n\nexport function WalletScreen() {\n const modal = useModal();\n const { isConnected, addresses } = useAccounts();\n\n if (!isConnected) {\n return (\n <View style={{ padding: 20 }}>\n <Button title=\"Connect Wallet\" onPress={() => modal.open()} />\n </View>\n );\n }\n\n return (\n <View style={{ padding: 20 }}>\n <Text style={{ fontSize: 18, marginBottom: 10 }}>Wallet Connected</Text>\n {addresses.map((addr, index) => (\n <Text key={index}>\n {addr.addressType}: {addr.address}\n </Text>\n ))}\n <Button title=\"Manage Wallet\" onPress={() => modal.open()} />\n </View>\n );\n}\n\nModal features:\n\nMultiple auth providers: Google, Apple\nBottom sheet UI: Native bottom sheet design for mobile\nAutomatic state management: Shows connect screen when disconnected, wallet management when connected\nError handling: Clear error messages displayed in the modal\nLoading states: Visual feedback during connection attempts\n\n​Or use hooks directly\n// WalletScreen.tsx\nimport React from \"react\";\nimport { View, Button, Text, Alert } from \"react-native\";\nimport { useConnect, useAccounts, useSolana, useEthereum, useDisconnect } from \"@phantom/react-native-sdk\";\n\nexport function WalletScreen() {\n const { connect, isConnecting, error: connectError } = useConnect();\n const { addresses, isConnected } = useAccounts();\n const { solana } = useSolana();\n const { ethereum } = useEthereum();\n const { disconnect } = useDisconnect();\n\n const handleConnect = async () => {\n try {\n await connect({ provider: \"google\" });\n Alert.alert(\"Success\", \"Wallet connected!\");\n } catch (error) {\n Alert.alert(\"Error\", `Failed to connect: ${error.message}`);\n }\n };\n\n const handleSignSolanaMessage = async () => {\n try {\n const signature = await solana.signMessage(\"Hello from Solana!\");\n Alert.alert(\"Solana Signed!\", `Signature: ${signature.signature.slice(0, 10)}...`);\n } catch (error) {\n Alert.alert(\"Error\", `Failed to sign: ${error.message}`);\n }\n };\n\n const handleSignEthereumMessage = async () => {\n try {\n const accounts = await ethereum.getAccounts();\n const signature = await ethereum.signPersonalMessage(\"Hello from Ethereum!\", accounts[0]);\n Alert.alert(\"Ethereum Signed!\", `Signature: ${signature.signature.slice(0, 10)}...`);\n } catch (error) {\n Alert.alert(\"Error\", `Failed to sign: ${error.message}`);\n }\n };\n\n if (!isConnected) {\n return (\n <View style={{ padding: 20 }}>\n <Button\n title={isConnecting ? \"Connecting...\" : \"Connect Wallet\"}\n onPress={handleConnect}\n disabled={isConnecting}\n />\n {connectError && <Text style={{ color: \"red\", marginTop: 10 }}>Error: {connectError.message}</Text>}\n </View>\n );\n }\n\n return (\n <View style={{ padding: 20 }}>\n <Text style={{ fontSize: 18, marginBottom: 10 }}>Wallet Connected</Text>\n {addresses.map((addr, index) => (\n <Text key={index}>\n {addr.addressType}: {addr.address}\n </Text>\n ))}\n\n <Button title=\"Sign Solana Message\" onPress={handleSignSolanaMessage} />\n\n <Button title=\"Sign Ethereum Message\" onPress={handleSignEthereumMessage} />\n\n <Button title=\"Disconnect\" onPress={disconnect} />\n </View>\n );\n}\n\n​Chain-specific operations\n​Solana operations\nimport { useSolana } from \"@phantom/react-native-sdk\";\n\nconst { solana } = useSolana();\nawait solana.signMessage(\"Hello Solana!\");\nawait solana.signAndSendTransaction(transaction);\n\n​Ethereum operations\nEVM support for Phantom Connect embedded wallets will go live later in 2026. The following Ethereum methods are currently available for injected provider (Phantom extension) connections only.\nimport { useEthereum } from \"@phantom/react-native-sdk\";\n\nconst { ethereum } = useEthereum();\nconst accounts = await ethereum.getAccounts();\nawait ethereum.signPersonalMessage(\"Hello Ethereum!\", accounts[0]);\nawait ethereum.sendTransaction(transactionData);\n\n​Hooks\n​useModal\nControl the connection modal visibility. The modal automatically shows the appropriate content based on connection status.\nconst modal = useModal();\n\n// Open the modal\nmodal.open(); // Shows connect options when disconnected, wallet management when connected\n\n// Close the modal\nmodal.close();\n\n// Check if modal is open\nconst isOpen = modal.isOpened;\n\nReturns:\n\nopen() - Function to open the modal\nclose() - Function to close the modal\nisOpened - Boolean indicating if modal is currently visible\n\nModal behavior:\n\nWhen disconnected: Shows authentication provider options (Google, Apple)\nWhen connected: Shows connected wallet addresses and disconnect button\n\n​useConnect\nManages wallet connection functionality.\nconst { connect, isConnecting, error } = useConnect();\n\n// Connect with specific provider (React Native supported providers)\nawait connect({ provider: \"google\" }); // Google OAuth\nawait connect({ provider: \"apple\" }); // Apple ID\n\n​useAccounts\nProvides access to connected wallet information.\nconst {\n addresses, // Array of wallet addresses\n isConnected, // Connection status\n walletId, // Phantom wallet ID\n} = useAccounts();\n\n​useSolana\nProvides access to Solana-specific operations.\nconst { solana, isAvailable } = useSolana();\n\nif (isAvailable) {\n // Sign a message\n const signature = await solana.signMessage(\"Hello Solana!\");\n\n // Sign a transaction (without sending)\n const signedTx = await solana.signTransaction(transaction);\n\n // Sign and send a transaction\n const result = await solana.signAndSendTransaction(transaction);\n}\n\n​useEthereum\nProvides access to Ethereum-specific operations.\nEVM support for Phantom Connect embedded wallets will go live later in 2026.\nconst { ethereum, isAvailable } = useEthereum();\n\nif (isAvailable) {\n // Get accounts\n const accounts = await ethereum.getAccounts();\n\n // Sign a personal message\n const signature = await ethereum.signPersonalMessage(\"Hello Ethereum!\", accounts[0]);\n\n // Sign a transaction (without sending)\n const signedTx = await ethereum.signTransaction(transactionData);\n\n // Send a transaction\n const result = await ethereum.sendTransaction(transactionData);\n\n // Get current chain ID\n const chainId = await ethereum.getChainId();\n\n // Switch to a different EVM network\n await ethereum.switchChain(137); // Switch to Polygon\n await ethereum.switchChain(\"0x89\"); // Also accepts hex strings\n}\n\nMonad support has been deprecated.\nSupported EVM Networks:\nNetworkChain IDUsageEthereum Mainnet1ethereum.switchChain(1)Ethereum Sepolia11155111ethereum.switchChain(11155111)Polygon Mainnet137ethereum.switchChain(137)Polygon Amoy80002ethereum.switchChain(80002)Base Mainnet8453ethereum.switchChain(8453)Base Sepolia84532ethereum.switchChain(84532)Arbitrum One42161ethereum.switchChain(42161)Arbitrum Sepolia421614ethereum.switchChain(421614)Monad Mainnet (Deprecated)143ethereum.switchChain(143)Monad Testnet (Deprecated)10143ethereum.switchChain(10143)\n​useDisconnect\nManages wallet disconnection.\nconst { disconnect, isDisconnecting } = useDisconnect();\n\nawait disconnect();\n\n​Authentication flows\n​Available providers\nThe SDK supports multiple authentication providers that you specify in the providers array:\n\nGoogle (\"google\") - Google OAuth authentication\nApple (\"apple\") - Apple ID authentication\n\nExample configuration:\n<PhantomProvider\n config={{\n providers: [\"google\", \"apple\"], // Specify enabled providers\n appId: \"your-app-id\",\n scheme: \"myapp\",\n addressTypes: [AddressType.solana],\n }}\n>\n <App />\n</PhantomProvider>\n\nExample usage:\n// Google OAuth\nawait connect({ provider: \"google\" });\n\n// Apple ID\nawait connect({ provider: \"apple\" });\n\n​Authentication process\n\nUser taps Connect Wallet in your app.\nSystem browser opens (Safari on iOS, Chrome Custom Tab on Android).\nUser authenticates with their chosen provider.\nBrowser redirects back to your app using the custom scheme.\nSDK automatically processes the authentication result.\nWallet is connected and ready to use.\n\n​Deep-link handling\nThe SDK automatically handles deep link redirects. Ensure your app’s URL scheme is properly configured.\nRedirect URL format:\n{scheme}://phantom-auth-callback?wallet_id=...&session_id=...\n\n​Security considerations\nThe Phantom Connect React Native SDK uses platform-level secure storage and system browsers during authentication:\n​Secure storage\n\niOS uses Keychain Services with hardware security.\nAndroid uses Android Keystore with hardware-backed keys.\n\n​Secure authentication\n\nUses the system browser rather than in-app webviews.\nVerifies redirect origins automatically.\n\n​Configuration examples\n​Basic configuration\nimport { PhantomProvider, AddressType } from \"@phantom/react-native-sdk\";\n\n<PhantomProvider\n config={{\n providers: [\"google\", \"apple\"],\n appId: \"your-app-id\",\n scheme: \"myapp\",\n addressTypes: [AddressType.solana],\n }}\n>\n <App />\n</PhantomProvider>;\n\n​Multi-chain configuration\nimport { PhantomProvider, AddressType, darkTheme } from \"@phantom/react-native-sdk\";\n\n<PhantomProvider\n config={{\n providers: [\"google\", \"apple\"],\n appId: \"your-app-id\",\n scheme: \"mycompany-wallet\",\n addressTypes: [AddressType.solana, AddressType.ethereum],\n authOptions: {\n redirectUrl: \"mycompany-wallet://auth/success\",\n },\n }}\n theme={darkTheme}\n appIcon=\"https://your-app.com/icon.png\"\n appName=\"Your App\"\n>\n <App />\n</PhantomProvider>;\n\n​Debug configuration\nConfigure debug logging by passing a debugConfig prop to PhantomProvider:\nimport { PhantomProvider, AddressType } from \"@phantom/react-native-sdk\";\n\nfunction App() {\n const debugConfig = {\n enabled: true, // Enable debug logging\n };\n\n return (\n <PhantomProvider\n config={{\n providers: [\"google\", \"apple\"],\n appId: \"your-app-id\",\n scheme: \"mywalletapp\",\n addressTypes: [AddressType.solana],\n }}\n debugConfig={debugConfig}\n >\n <YourApp />\n </PhantomProvider>\n );\n}\n\nDebug configuration properties:\nPropertyTypeDescriptionenabledbooleanEnable debug logging (default: false)\n​What you can do\n\n​Starter kits and examples\nMobile-specific templates and examples:\n\n​Additional resources\nWas this page helpful?","tokens":3674,"squid":"spider-10","role":"Tooling Spider","at":1791340003470,"hash":"d6eb5f4d4fdd2fbde8da0e8fd4f373be1c4e509f"}
{"url":"https://jup.ag/portfolio","domain":"jup.ag","title":"Solana Portfolio Tracker: Track Your DeFi Assets | Jupiter","text":"Your entire Solana DeFi world, tracked in one dashboard.Track holdings, positions, yield, and airdrops across 194 Solana protocols.Demo walletsOpen a wallet, or view all 3 as a group.View all 3 as a groupDeFi whaleDemo…3tKGJUP stakerjupE…BH5HAirdrop farmertEsT…51ndSupported protocolsPortfolio coverage194Protocols trackedDeFi positions across Solana, in real time341Services parsedEvery transaction, decoded and human-readableAutoAirdrop detectionWe surface claimables you might have missedEverything you need to track your Solana portfolioOne dashboard for your assets, positions, history, and everything you can claim.Multi-walletTrack several wallets — and groups of wallets — together in one consolidated view.ActivityA clean, human-readable history of every onchain transaction across your wallets.PnLSee profit & loss on your holdings, over the last 24h or all-time.Address bookSave wallets and organize them into groups you can track as one portfolio.Airdrop CheckerSurface claimable airdrops across protocols you might have missed.Yield EstimateEstimate the yearly yield your idle assets could be earning.Frequently asked questionsOpen Jupiter Portfolio at jup.ag/portfolio and paste any Solana wallet address. You instantly see every token balance, DeFi position, staking position, and your full transaction history in one dashboard. It's the simplest way to track your whole Solana portfolio without logging into every protocol separately.No. Jupiter Portfolio is read-only and works with any public Solana address. You can paste a wallet to view its holdings without connecting or signing anything, so you can track your own wallets or watch any address on Solana.Yes. Tracking your Solana portfolio is free and non-custodial. You don't need to sign a transaction to view a portfolio, and Jupiter never takes custody of your assets.A complete view of your onchain activity across 194 Solana protocols, including:Token balances and their USD valueDeFi positions across lending, liquidity, and leverageStaking and validator positionsNet worth, holdings PnL, and a full transaction historyYes. Add more than 1 Solana address to monitor your entire portfolio across wallets in one place. Each wallet's holdings, positions, and net worth load directly from onchain data.Yes. The dashboard surfaces a Claimable total across protocols, covering things like staking rewards available to claim. You can also stake SOL or supply to Jupiter Lend on any eligible assets.","tokens":618,"squid":"spider-02","role":"Liquidity Spider","at":1791340007032,"hash":"1fbfe155876562ecab3a4ad0f812608e6129ffde"}
{"url":"https://eips.ethereum.org/EIPS/eip-100","domain":"eips.ethereum.org","title":"EIP-100: Change difficulty adjustment to target mean block time including uncles","text":"🎉 Final\n\n Standards Track: Core\n\n EIP-100: Change difficulty adjustment to target mean block time including uncles\n\n Authors\n Vitalik Buterin (@vbuterin)\n\n Created\n 2016-04-28\n\n Specification\n\nCurrently, the formula to compute the difficulty of a block includes the following logic:\n\nadj_factor = max(1 - ((timestamp - parent.timestamp) // 10), -99)\nchild_diff = int(max(parent.difficulty + (parent.difficulty // BLOCK_DIFF_FACTOR) * adj_factor, min(parent.difficulty, MIN_DIFF)))\n...\n\nIf block.number >= BYZANTIUM_FORK_BLKNUM, we change the first line to the following:\n\nadj_factor = max((2 if len(parent.uncles) else 1) - ((timestamp - parent.timestamp) // 9), -99)\n\n Rationale\n\nThis new formula ensures that the difficulty adjustment algorithm targets a constant average rate of blocks produced including uncles, and so ensures a highly predictable issuance rate that cannot be manipulated upward by manipulating the uncle rate. A formula that accounts for the exact number of included uncles:\nadj_factor = max(1 + len(parent.uncles) - ((timestamp - parent.timestamp) // 9), -99)\n\ncan be fairly easily seen to be (to within a tolerance of ~3/4194304) mathematically equivalent to assuming that a block with k uncles is equivalent to a sequence of k+1 blocks that all appear with the exact same timestamp, and this is likely the simplest possible way to accomplish the desired effect. But since the exact formula depends on the full block and not just the header, we are instead using an approximate formula that accomplishes almost the same effect but has the benefit that it depends only on the block header (as you can check the uncle hash against the blank hash).\n\nChanging the denominator from 10 to 9 ensures that the block time remains roughly the same (in fact, it should decrease by ~3% given the current uncle rate of 7%).\n\n References\n\n EIP 100 issue and discussion: https://github.com/ethereum/EIPs/issues/100\n https://bitslog.wordpress.com/2016/04/28/uncle-mining-an-ethereum-consensus-protocol-flaw/\n\n Citation\n Please cite this document as:\n\n Vitalik Buterin (@vbuterin), \"EIP-100: Change difficulty adjustment to target mean block time including uncles,\" Ethereum Improvement Proposals, no. 100, April 2016. Available: https://eips.ethereum.org/EIPS/eip-100.","tokens":569,"squid":"spider-05","role":"Spec Spider","at":1791340021214,"hash":"f9e0c34ec06ff72f5601f312ee4154c9b52f8b55"}
{"url":"https://eips.ethereum.org/EIPS/eip-140","domain":"eips.ethereum.org","title":"EIP-140: REVERT instruction","text":"🎉 Final\n\n Standards Track: Core\n\n EIP-140: REVERT instruction\n\n Authors\n Alex Beregszaszi (@axic), Nikolai Mushegian <nikolai@nexusdev.us>\n\n Created\n 2017-02-06\n\n Simple Summary\n\nThe REVERT instruction provides a way to stop execution and revert state changes, without consuming all provided gas and with the ability to return a reason.\n\n Abstract\n\nThe REVERT instruction will stop execution, roll back all state changes done so far and provide a pointer to a memory section, which can be interpreted as an error code or message. While doing so, it will not consume all the remaining gas.\n\n Motivation\n\nCurrently this is not possible. There are two practical ways to revert a transaction from within a contract: running out of gas or executing an invalid instruction. Both of these options will consume all remaining gas. Additionally, reverting an EVM execution means that all changes, including LOGs, are lost and there is no way to convey a reason for aborting an EVM execution.\n\n Specification\n\nOn blocks with block.number >= BYZANTIUM_FORK_BLKNUM, the REVERT instruction is introduced at 0xfd. It expects two stack items, the top item is the memory_offset followed by memory_length. It does not produce any stack elements because it stops execution.\n\nThe semantics of REVERT with respect to memory and memory cost are identical to those of RETURN. The sequence of bytes given by memory_offset and memory_length is called “error message” in the following.\n\nThe effect of REVERT is that execution is aborted, considered as failed, and state changes are rolled back. The error message will be available to the caller in the returndata buffer and will also be copied to the output area, i.e. it is handled in the same way as the regular return data is handled.\n\nThe cost of the REVERT instruction equals to that of the RETURN instruction, i.e. the rollback itself does not consume all gas, the contract only has to pay for memory.\n\nIn case there is not enough gas left to cover the cost of REVERT or there is a stack underflow, the effect of the REVERT instruction will equal to that of a regular out of gas exception, i.e. it will consume all gas.\n\nIn the same way as all other failures, the calling opcode returns 0 on the stack following a REVERT opcode in the callee.\n\nIn case REVERT is used in the context of a CREATE or CREATE2 call, no code is deployed, 0 is put on the stack and the error message is available in the returndata buffer.\n\nThe content of the optionally provided memory section is not defined by this EIP, but is a candidate for another Informational EIP.\n\n Backwards Compatibility\n\nThis change has no effect on contracts created in the past unless they contain 0xfd as an instruction.\n\n Test Cases\n\n6c726576657274656420646174616000557f726576657274206d657373616765000000000000000000000000000000000000600052600e6000fd\n\nshould:\n\n return 0x726576657274206d657373616765 as REVERT data,\n the storage at key 0x0 should be left as unset and\n use 20024 gas in total.\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), Nikolai Mushegian <nikolai@nexusdev.us>, \"EIP-140: REVERT instruction,\" Ethereum Improvement Proposals, no. 140, February 2017. Available: https://eips.ethereum.org/EIPS/eip-140.","tokens":822,"squid":"spider-05","role":"Spec Spider","at":1791340032242,"hash":"baacd291dedcc643ce04534b6425daf213129f11"}
{"url":"https://www.paradigm.xyz/privacy","domain":"paradigm.xyz","title":"Privacy Policy | Paradigm","text":"Privacy PolicyThis Privacy Policy (“Privacy Policy” or “Policy”) applies to the collection and use of Personal Information by Paradigm (“Company,” “we,” “us,” or “our”). It describes the Company's practices regarding the collection, use, and disclosure of Personal Information. This Policy applies to your access and use of any of our websites (the “Site”) or online services on which we post this Policy, when you communicate with us via email, and when you engage with us offline (collectively with the Site, the “Services”). By accessing or otherwise using our Services, you agree to our collection, disclosure, and use of Personal Information as described herein and agree to our Terms of Use. This Policy does not apply to information we collect about employees, job applicants, and independent contractors. This Policy also does not govern the information handling practices of our portfolio companies. For purposes of this Policy, “Personal Information” means information that identifies, relates to, describes, is reasonably capable of being associated with, or could reasonably be linked, directly or indirectly, with a particular consumer or household. It does not include de-identified or aggregate information.Personal Information We CollectWe may collect information about you when we provide our Services. We collect information directly from you, automatically when you access our Services, and from unaffiliated parties. Information You Provide to Us Directly: We may collect information directly from you when you use our Services, request information about our Services, provide us with your information at an event, or when you otherwise voluntarily provide information to us.Automatically-Collected Information: We and our vendors may use cookies and other technologies for analytics and to improve the Site. These technologies, for example, may allow us to tailor the Site to your needs, track the pages you visit, help us manage content, and compile statistics about usage of our Site. You can choose to accept or decline cookies. Most web browsers automatically accept cookies, but your browser may allow you to modify your browser settings to decline cookies if you prefer. If you disable cookies, you may be prevented from taking full advantage of the Site, because the Site may not function properly. As we adopt additional technologies, we may also gather additional information through other methods.Information We Collect from Third Parties: We may collect information about you or others through our affiliates or through non-affiliated parties. We may also collect information about you from others. For example, users may provide us with information about colleagues or other prospective users of our Services. We may collect information when you communicate with us on social media services such as LinkedIn and Twitter. We may combine information that we collect from you through the Services with information that we obtain from other parties and information derived from other products or services we provide. The categories of Personal Information we may have collected from these sources include the following:Personal identifiers: Such as name, address, email address, telephone numbers, IP address or other unique identifier, account name and password, and other similar information.Commercial information: Such as transaction data regarding transactions you've made with us.Internet or other electronic activity information: Such as device and browser type, your browsing and search history on our Site, and information regarding your interaction with our Site and our advertisements.Business information: Such as general information about your employment or business, such as a business title, business phone, business email address, business product and service offerings, and other information you provide us when communicating with us.Other information: Such as other information we may collect from or about you, including when you communicate with us for support, product evaluation, dispute resolution, or other issues.Inferences drawn from the Personal Information identified above.You are not required to provide us with information, but certain features of the Services may not be accessible or available, absent the provision of the requested information.To manage cookie preferences, open your privacy choices.How We Use Personal InformationWe use your Personal Information for business and commercial purposes, including:to provide you with information you request from us,to contact you from time to time with news and other information about the Company, or in response to your inquiries or other requests,to provide and improve the Services,to monitor or improve our Site,for internal business analysis,to prevent fraud, activities that violate our Terms of Use or that are illegal,to protect our rights and the rights and safety of our users or others,to process payments for the Services,to comply with our legal obligations or as permitted by law, andto administer and troubleshoot the Services.We may aggregate and/or de-identify information collected through the Services. We may use de-identified or aggregated data for any purpose, including without limitation for research and marketing purposes and may also disclose such data to other parties, including without limitation, advertisers, promotional partners, sponsors, event promoters, and/or others.When We Disclose Personal InformationCategories of Personal Information that we have disclosed to unaffiliated parties for a business purpose in the 12 months prior to the date of this Policy are as follows:personal identifiers,financial information,internet or other electronic network activity information, andinferences from the foregoing.Categories of Unaffiliated Parties to Which We Have Disclosed Personal Information for a business purpose in the 12 months prior to the date of this Policy are as follows:Vendors that provide customer relationship management (CRM) services; assist us in operating, analyzing, and displaying content on our website; provide analytics information; advertise or market our products; provide website hosting; and provide legal and accounting services.Vendors that facilitate transactional services requiring payment information; and provide legal and accounting services.Vendors that provide data security services and cloud-based data storage; host our Site and assist with other IT-related functions; advertise and market our products; and provide analytics information.Vendors that host our Site and assist with other IT-related functions; advertise and market our products; provide analytics information; and provide legal and accounting services.We may also disclose your Personal Information as required or permitted by law to comply with a subpoena or similar legal process or government request, or when we believe in good faith that disclosure is legally required or otherwise necessary to protect our rights and property or the rights, property or safety of others, including to law enforcement agencies, and judicial and regulatory authorities. We may also disclose your Personal Information to unaffiliated parties to help detect and protect against fraud or data security vulnerabilities. We may transfer your Personal Information to another party in the event of an actual or contemplated sale, merger, reorganization of our entity or other restructuring. We may disclose or transfer your information to affiliates. We may also disclose your information to others with your consent.Cookies and Other Tracking TechnologiesCookies are small, sometimes encrypted text files that are stored on computer hard drives by websites that you visit. They are used to help users navigate websites efficiently as well as to provide information to the owner of the websites. To find out more about cookies, including how to see what cookies have been set and how to manage and delete them, please visit www.allaboutcookies.org. When you visit our Site, we may place a “cookie” or other online tracking devices (e.g. web beacons) that recognize you. The cookies and other tracking technologies may also collect information about your IP address or actions taken in connection with the Site. We may use cookies or similar tracking technologies to capture information about the use of our Site, including to improve your user experience. We use Google Analytics to evaluate the use of our website. Google Analytics uses cookies and other identifiers to collect information, such as how often users visit a website, what pages they visit when they do so, and what other websites they visited prior to visiting a website. To learn more about how Google Analytics collects personal information, review Google's Privacy Policy.State Privacy Rights – CaliforniaIf you are a California resident, you may have separate rights regarding your Personal Information, in accordance with California law.California Consumer Privacy ActThroughout this Policy, we discuss in detail the specific pieces of personal information and sensitive personal information we collect, the sources of that information, and how we disclose it. Under the California Consumer Privacy Act (“CCPA”), we also have to provide you with the categories of personal information and sensitive personal information we collect and disclose for business or commercial purposes. As used in this section, “personal information,” “sensitive personal information,” “business purposes,” “commercial purposes,” and “categories” shall have the meanings set forth by the CCPA.In the twelve months leading up to the effective date of this Policy, we have collected and disclosed the categories of personal information described in the section above on “Personal Information We Collect” for business or commercial purposes. The categories of personal information are: (1) personal identifiers, (2) commercial information; (3) Internet or other electronic activity information; (4) business information; (5) other information we may collect from or about you, including when you communicate with us for support, product evaluation, dispute resolution, or other issues; and (6) inferences drawn from the personal information identified above.Some of the categories of personal information above may also be sensitive personal information under the CCPA. We may collect the following type of sensitive personal information: information you may voluntarily provide that may reveal race/ethnic origin or other protected classifications.We collect the categories of personal information identified above from the following sources: (1) directly from you; (2) through your use of the Services; and (3) third parties such as social media networks.We process the categories of personal information identified above for the purposes as described in more detail in the section above on “How We Use Personal Information.” The California Consumer Privacy Act (CCPA) gives California residents rights described below with respect to their personal information. This Section only applies to you if you are a California resident. It applies to personal Information that we collect on or through the Services and through other means (such as information collected offline and over the telephone). It does not apply to personal information we collect from our employees and job applicants in their capacity as employees and job applicants.CCPA RightsIf you are a California resident, you may have certain rights. California law may permit you to request that we:Provide you the categories of personal information we have collected or disclosed about you; the categories of sources of such information; the business or commercial purpose for collecting, “selling,” or “sharing” your personal information; the categories of third parties to whom we disclose or “sell,” or with whom we “share,” personal information; and the categories of personal information we “sell” or “share.”Provide access to and/or a copy of certain information we maintain about you.Delete certain information we maintain about you.Correct inaccurate personal information we maintain about you.The CCPA also allows you to limit the use or disclosure of your sensitive personal information if your sensitive personal information is used for certain purposes. Please note that we do not use or disclose sensitive personal information other than for purposes for which you cannot opt out under the CCPA.You also have the right to opt out of “sales” and “sharing” of personal information. We have not “sold” or “shared” your personal information in the 12 months preceding the effective date of this Policy. As our Services are not directed to minors, we do not knowingly “sell” or “share” the personal information of children under 16. You may have the right to receive information about the financial incentives that we offer to you, if any. You also have the right to not be discriminated against (as provided for in applicable law) for exercising certain of your rights. Certain information may be exempt from such requests under applicable law. We need certain types of information so that we can provide the Services to you. If you ask us to delete it, you may no longer be able to access or use the Services.Exercising Your RightsTo exercise any of the rights above, or to ask a question, contact personnel@paradigm.xyz.Our Commitment to Allowing You to Exercise Your Rights – Non-Discrimination You also have the right not to be discriminated against (as provided for in California law) for exercising your rights.Verification of Identity – Access or Deletion RequestsWe also will take reasonable steps to verify your identity before responding to a request. For example, we may ask you for identifying information and attempt to match it to information that we maintain about you, which may involve you providing identifying information. If we are unable to verify you through this method, we shall have the right, but not the obligation, to request additional information from you. If we are unable to verify your identity with the degree of certainty required, we will not be able to honor your request. We will notify you to explain the basis of the denial.Authorized AgentsYou may designate an agent to submit requests on your behalf. If you would like to designate an agent to act on your behalf, you and the agent will need to provide us with a power of attorney or your signed permission indicating the agent has been authorized to submit the opt-out request on your behalf. We may also require that you verify your identity directly with us or confirm with us that you provided the agent with permission to submit the request.California Do Not TrackSome browsers have a “do not track” feature that lets you tell websites that you do not want to have your online activities tracked. At this time, our Site does not respond to browsers' “DNT” signals.Retention of Your Personal InformationThe personal information we do or will collect, including sensitive personal information, will be retained for as long as necessary to fulfill the purposes of the collection or for legal obligations as set forth in this Privacy Policy. These purposes may include to comply with reporting, legal and accounting obligations.Marketing EmailsYou may opt out of receiving marketing emails from us by following the instructions in those marketing emails. If you choose to opt out, we may still send you non-marketing communications, such as those about changes to our Terms, or our ongoing business relations with you.Personal Information of MinorsThe Services are not intended for minors under 16. If we discover that an individual under 16 has provided us with Personal Information, we will delete the Personal Information to the extent required by the Children's Online Privacy Protection Act or other applicable law.Third Party WebsitesOur Site may contain social media buttons or links to third-party websites or services, which may have privacy policies that differ from our own. We are not responsible for the activities and practices that take place on those social media platforms or third-party websites. We recommend that you review the privacy policies posted on any platform or website that you may access through our Site.How We Keep Your Personal Information SecureWe implement and maintain security measures appropriate to the nature of the Personal Information that we collect, use, retain, transfer or otherwise process. Those measures include administrative, physical and technical safeguards to protect the security, confidentiality and integrity of Personal Information. However, data security incidents and breaches can occur due to a variety of factors that cannot reasonably be prevented; therefore, our safeguards may not always be adequate to prevent all breaches of security.International ResidentsPersonal Information collected from you, including via our Site, will be transferred to the United States where the Site is hosted. You hereby consent to the transfer of your Personal Information to the United States as described in this Privacy Policy. Please do not use the Site if you do not agree to the transfer and processing of your Personal Information in the United States, which may not provide the same level of protection for your data as your home country.Changes to This PolicyWe will review and update this Policy periodically. We will notify you of material changes in accordance with applicable law. By continuing to use the Services, you acknowledge the applicability of the updated Privacy Policy. If you disagree with any changes and do not wish your information to be subject to a revised Privacy Policy, you will need to stop using the Services.Contact UsIf there are any questions regarding this Policy, you may contact us at privacy@paradigm.xyz.","tokens":4460,"squid":"spider-04","role":"Research Spider","at":1791340036190,"hash":"5e9608b253194e7efc91af42f713ed5f50d4424b"}
{"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":"spider-05","role":"Spec Spider","at":1791340043311,"hash":"be3d198338b4e81823ddbe8910bbd24d518ad645"}
{"url":"https://akash.network/ecosystem/deployed-on-akash/mining","domain":"akash.network","title":"Mining | Deployed On Akash","text":"Mining Chia Network A new blockchain and smart transaction platform that is easier to use, more efficient, and secure A considerable amount of Chia miners are hosted on Akash, along with several Chia community members provide compute to AkashA new blockchain and smart transaction platform that is easier to use, more efficient, and secure A considerable amount of Chia miners are hosted on Akash, along with several Chia community members provide compute to AkashA new blockchain and smart transaction platform that is easier to use, more efficient, and secure A considerable amount of Chia miners are hosted on Akash, along with several Chia community members provide compute to Akash View project","tokens":175,"squid":"spider-03","role":"Compute Spider","at":1791340043342,"hash":"6b5cdf4f8e51374e6d9c5d628d18497909401070"}
{"url":"https://eips.ethereum.org/EIPS/eip-152","domain":"eips.ethereum.org","title":"EIP-152: Add BLAKE2 compression function `F` precompile","text":"🎉 Final\n\n Standards Track: Core\n\n EIP-152: Add BLAKE2 compression function `F` precompile\n\n Authors\n Tjaden Hess <tah83@cornell.edu>, Matt Luongo (@mhluongo), Piotr Dyraga (@pdyraga), James Hancock (@MadeOfTin)\n\n Created\n 2016-10-04\n\n Simple Summary\n\nThis EIP will enable the BLAKE2b hash function and other higher-round 64-bit BLAKE2 variants to run cheaply on the EVM, allowing easier interoperability between Ethereum and Zcash as well as other Equihash-based PoW coins.\n\n Abstract\n\nThis EIP introduces a new precompiled contract which implements the compression function F used in the BLAKE2 cryptographic hashing algorithm, for the purpose of allowing interoperability between the EVM and Zcash, as well as introducing more flexible cryptographic hash primitives to the EVM.\n\n Motivation\n\nBesides being a useful cryptographic hash function and SHA3 finalist, BLAKE2 allows for efficient verification of the Equihash PoW used in Zcash, making a BTC Relay - style SPV client possible on Ethereum. A single verification of an Equihash PoW verification requires 512 iterations of the hash function, making verification of Zcash block headers prohibitively expensive if a Solidity implementation of BLAKE2 is used.\n\nBLAKE2b, the common 64-bit BLAKE2 variant, is highly optimized and faster than MD5 on modern processors.\n\nInteroperability with Zcash could enable contracts like trustless atomic swaps between the chains, which could provide a much needed aspect of privacy to the very public Ethereum blockchain.\n\n Specification\n\nWe propose adding a precompiled contract at address 0x09 wrapping the BLAKE2 F compression function.\n\nThe precompile requires 6 inputs tightly encoded, taking exactly 213 bytes, as explained below. The encoded inputs are corresponding to the ones specified in the BLAKE2 RFC Section 3.2:\n\n rounds - the number of rounds - 32-bit unsigned big-endian word\n h - the state vector - 8 unsigned 64-bit little-endian words\n m - the message block vector - 16 unsigned 64-bit little-endian words\n t_0, t_1 - offset counters - 2 unsigned 64-bit little-endian words\n f - the final block indicator flag - 8-bit word\n\n[4 bytes for rounds][64 bytes for h][128 bytes for m][8 bytes for t_0][8 bytes for t_1][1 byte for f]\n\nThe boolean f parameter is considered as true if set to 1.\nThe boolean f parameter is considered as false if set to 0.\nAll other values yield an invalid encoding of f error.\n\nThe precompile should compute the F function as specified in the RFC and return the updated state vector h with unchanged encoding (little-endian).\n\n Example Usage in Solidity\n\nThe precompile can be wrapped easily in Solidity to provide a more development-friendly interface to F.\n\nfunction F(uint32 rounds, bytes32[2] memory h, bytes32[4] memory m, bytes8[2] memory t, bool f) public view returns (bytes32[2] memory) {\n bytes32[2] memory output;\n\n bytes memory args = abi.encodePacked(rounds, h[0], h[1], m[0], m[1], m[2], m[3], t[0], t[1], f);\n\n assembly {\n if iszero(staticcall(not(0), 0x09, add(args, 32), 0xd5, output, 0x40)) {\n revert(0, 0)\n }\n }\n\n return output;\n}\n\nfunction callF() public view returns (bytes32[2] memory) {\n uint32 rounds = 12;\n\n bytes32[2] memory h;\n h[0] = hex\"48c9bdf267e6096a3ba7ca8485ae67bb2bf894fe72f36e3cf1361d5f3af54fa5\";\n h[1] = hex\"d182e6ad7f520e511f6c3e2b8c68059b6bbd41fbabd9831f79217e1319cde05b\";\n\n bytes32[4] memory m;\n m[0] = hex\"6162630000000000000000000000000000000000000000000000000000000000\";\n m[1] = hex\"0000000000000000000000000000000000000000000000000000000000000000\";\n m[2] = hex\"0000000000000000000000000000000000000000000000000000000000000000\";\n m[3] = hex\"0000000000000000000000000000000000000000000000000000000000000000\";\n\n bytes8[2] memory t;\n t[0] = hex\"0300000000000000\";\n t[1] = hex\"0000000000000000\";\n\n bool f = true;\n\n // Expected output:\n // ba80a53f981c4d0d6a2797b69f12f6e94c212f14685ac4b74b12bb6fdbffa2d1\n // 7d87c5392aab792dc252d5de4533cc9518d38aa8dbf1925ab92386edd4009923\n return F(rounds, h, m, t, f);\n}\n\n Gas costs and benchmarks\n\nEach operation will cost GFROUND * rounds gas, where GFROUND = 1. Detailed benchmarks are presented in the benchmarks appendix section.\n\n Rationale\n\nBLAKE2 is an excellent candidate for precompilation. BLAKE2 is heavily optimized for modern 64-bit CPUs, specifically utilizing 24 and 63-bit rotations to allow parallelism through SIMD instructions and little-endian arithmetic. These characteristics provide exceptional speed on native CPUs: 3.08 cycles per byte, or 1 gibibyte per second on an Intel i5.\n\nIn contrast, the big-endian 32 byte semantics of the EVM are not conducive to efficient implementation of BLAKE2, and thus the gas cost associated with computing the hash on the EVM is disproportionate to the true cost of computing the function natively.\n\nAn obvious implementation would be a direct BLAKE2b hash function precompile. At first glance, a BLAKE2b precompile satisfies most hashing and interoperability requirements on the EVM. Once we started digging in, however, it became clear that any BLAKE2b implementation would need specific features and internal modifications based on different projects’ requirements and libraries.\n\nA thread with the Zcash team makes the issue clear.\n\n The minimal thing that is necessary for a working ZEC-ETH relay is an implementation of BLAKE2b Compression F in a precompile.\n\n A BLAKE2b Compression Function F precompile would also suffice for the Filecoin and Handshake interop goals.\n\n A full BLAKE2b precompile would suffice for a ZEC-ETH relay, provided that the implementation provided the parts of the BLAKE2 API that we need (personalization, maybe something else—I’m not sure).\n\n I’m not 100% certain if a full BLAKE2b precompile would also suffice for the Filecoin and Handshake goals. It almost certainly could, provided that it supports all the API that they need.\n\n BLAKE2s — whether the Compression Function F or the full hash — is only a nice-to-have for the purposes of a ZEC-ETH relay.\n\nFrom this and other conversations with teams in the space, we believe we should focus first on the F precompile as a strictly necessary piece for interoperability projects. A BLAKE2b precompile is a nice-to-have, and we support any efforts to add one– but it’s unclear whether complete requirements and a flexible API can be found in time for Istanbul.\n\nImplementation of only the core F compression function also allows substantial flexibility and extensibility while keeping changes at the protocol level to a minimum. This will allow functions like tree hashing, incremental hashing, and keyed, salted, and personalized hashing as well as variable length digests, none of which are currently available on the EVM.\n\n Backwards Compatibility\n\nThere is very little risk of breaking backwards-compatibility with this EIP, the sole issue being if someone were to build a contract relying on the address at 0x09 being empty. The likelihood of this is low, and should specific instances arise, the address could be chosen to be any arbitrary value with negligible risk of collision.\n\n Test Cases\n\n Test vector 0\n\n input: (empty)\n output: error “input length for BLAKE2 F precompile should be exactly 213 bytes”\n\n Test vector 1\n\n input:\n00000c48c9bdf267e6096a3ba7ca8485ae67bb2bf894fe72f36e3cf1361d5f3af54fa5d182e6ad7f520e511f6c3e2b8c68059b6bbd41fbabd9831f79217e1319cde05b61626300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000300000000000000000000000000000001\n output: error “input length for BLAKE2 F precompile should be exactly 213 bytes”\n\n Test vector 2\n\n input:\n000000000c48c9bdf267e6096a3ba7ca8485ae67bb2bf894fe72f36e3cf1361d5f3af54fa5d182e6ad7f520e511f6c3e2b8c68059b6bbd41fbabd9831f79217e1319cde05b61626300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000300000000000000000000000000000001\n output: error “input length for BLAKE2 F precompile should be exactly 213 bytes”\n\n Test vector 3\n\n input:\n0000000c48c9bdf267e6096a3ba7ca8485ae67bb2bf894fe72f36e3cf1361d5f3af54fa5d182e6ad7f520e511f6c3e2b8c68059b6bbd41fbabd9831f79217e1319cde05b61626300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000300000000000000000000000000000002\n output: error “incorrect final block indicator flag”\n\n Test vector 4\n\n input:\n0000000048c9bdf267e6096a3ba7ca8485ae67bb2bf894fe72f36e3cf1361d5f3af54fa5d182e6ad7f520e511f6c3e2b8c68059b6bbd41fbabd9831f79217e1319cde05b61626300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000300000000000000000000000000000001\n output:\n08c9bcf367e6096a3ba7ca8485ae67bb2bf894fe72f36e3cf1361d5f3af54fa5d282e6ad7f520e511f6c3e2b8c68059b9442be0454267ce079217e1319cde05b\n\n Test vector 5\n\n input:\n0000000c48c9bdf267e6096a3ba7ca8485ae67bb2bf894fe72f36e3cf1361d5f3af54fa5d182e6ad7f520e511f6c3e2b8c68059b6bbd41fbabd9831f79217e1319cde05b61626300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000300000000000000000000000000000001\n output: ba80a53f981c4d0d6a2797b69f12f6e94c212f14685ac4b74b12bb6fdbffa2d17d87c5392aab792dc252d5de4533cc9518d38aa8dbf1925ab92386edd4009923\n\n Test vector 6\n\n input:\n0000000c48c9bdf267e6096a3ba7ca8485ae67bb2bf894fe72f36e3cf1361d5f3af54fa5d182e6ad7f520e511f6c3e2b8c68059b6bbd41fbabd9831f79217e1319cde05b61626300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000300000000000000000000000000000000\n output:\n75ab69d3190a562c51aef8d88f1c2775876944407270c42c9844252c26d2875298743e7f6d5ea2f2d3e8d226039cd31b4e426ac4f2d3d666a610c2116fde4735\n\n Test vector 7\n\n input:\n0000000148c9bdf267e6096a3ba7ca8485ae67bb2bf894fe72f36e3cf1361d5f3af54fa5d182e6ad7f520e511f6c3e2b8c68059b6bbd41fbabd9831f79217e1319cde05b61626300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000300000000000000000000000000000001\n output:\nb63a380cb2897d521994a85234ee2c181b5f844d2c624c002677e9703449d2fba551b3a8333bcdf5f2f7e08993d53923de3d64fcc68c034e717b9293fed7a421\n\n Test vector 8\n\n input:\nffffffff48c9bdf267e6096a3ba7ca8485ae67bb2bf894fe72f36e3cf1361d5f3af54fa5d182e6ad7f520e511f6c3e2b8c68059b6bbd41fbabd9831f79217e1319cde05b61626300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000300000000000000000000000000000001\n output:\nfc59093aafa9ab43daae0e914c57635c5402d8e3d2130eb9b3cc181de7f0ecf9b22bf99a7815ce16419e200e01846e6b5df8cc7703041bbceb571de6631d2615\n\n Implementation\n\nAn initial implementation of the F function in Go, adapted from the standard library, can be found in our Golang BLAKE2 library fork. There’s also an implementation of the precompile in our fork of go-ethereum.\n\n References\n\nFor reference, further discussion on this EIP also occurred in the following PRs and issues\n\n Original Issue\n Ethereum Magicians\n PR 2129\n\n Appendix - benchmarks\n\nAssuming ecRecover precompile is perfectly priced, we executed a set of benchmarks comparing Blake2b F compression function precompile with ecRecover precompile. For benchmarks, we used 3.1 GHz Intel Core i7 64-bit machine.\n\n$ sysctl -n machdep.cpu.brand_string\nIntel(R) Core(TM) i7-7920HQ CPU @ 3.10GHz\n\n 12 rounds\n\nAn average gas price of F precompile call with 12 rounds compared to ecRecover should have been 6.74153 and it gives 0.5618 gas per round.\n\nName Gascost Time (ns) MGas/S Gasprice for 10MGas/S Gasprice for ECDSA eq\n----------------------------------------- --------- ---------------- --------- ----------------------- -----------------------\nPrecompiledEcrecover/ 3000 152636 19.6546 1526.36 3000\nPrecompiledBlake2F/testVectors2bX_0 12 338 35.503 3.38 6.64326\nPrecompiledBlake2F/testVectors2bX_3 12 336 35.7143 3.36 6.60395\nPrecompiledBlake2F/testVectors2bX_70 12 362 33.1492 3.62 7.11497\nPrecompiledBlake2F/testVectors2bX_140 12 339 35.3982 3.39 6.66291\nPrecompiledBlake2F/testVectors2bX_230 12 339 35.3982 3.39 6.66291\nPrecompiledBlake2F/testVectors2bX_300 12 343 34.9854 3.43 6.74153\nPrecompiledBlake2F/testVectors2bX_370 12 336 35.7143 3.36 6.60395\nPrecompiledBlake2F/testVectors2bX_440 12 337 35.6083 3.37 6.6236\nPrecompiledBlake2F/testVectors2bX_510 12 345 34.7826 3.45 6.78084\nPrecompiledBlake2F/testVectors2bX_580 12 355 33.8028 3.55 6.97738\n\nColumns\n\n MGas/S - Shows what MGas per second was measured on that machine at that time\n Gasprice for 10MGas/S shows what the gasprice should have been, in order to reach 10 MGas/second\n Gasprice for ECDSA eq shows what the gasprice should have been, in order to have the same cost/cycle as ecRecover\n\n 1200 rounds\n\nAn average gas price of F precompile call with 1200 rounds compared to ecRecover should have been 436.1288 and it gives 0.3634 gas per round.\n\nName Gascost Time (ns) MGas/S Gasprice for 10MGas/S Gasprice for ECDSA eq\n----------------------------------------- --------- ---------------- --------- ----------------------- -----------------------\nPrecompiledEcrecover/ 3000 156152 19.212 1561.52 3000\nPrecompiledBlake2F/testVectors2bX_0 1200 22642 52.9989 226.42 434.999\nPrecompiledBlake2F/testVectors2bX_3 1200 22885 52.4361 228.85 439.668\nPrecompiledBlake2F/testVectors2bX_70 1200 22737 52.7774 227.37 436.824\nPrecompiledBlake2F/testVectors2bX_140 1200 22602 53.0926 226.02 434.231\nPrecompiledBlake2F/testVectors2bX_230 1200 22501 53.331 225.01 432.29\nPrecompiledBlake2F/testVectors2bX_300 1200 22435 53.4879 224.35 431.022\nPrecompiledBlake2F/testVectors2bX_370 1200 22901 52.3995 229.01 439.975\nPrecompiledBlake2F/testVectors2bX_440 1200 23134 51.8717 231.34 444.452\nPrecompiledBlake2F/testVectors2bX_510 1200 22608 53.0786 226.08 434.346\nPrecompiledBlake2F/testVectors2bX_580 1200 22563 53.1844 225.63 433.481\n\n 1 round\n\nAn average gas price of F precompile call with 1 round compared to ecRecover should have been 2.431701. However, in this scenario the call cost would totally overshadow the dynamic cost anyway.\n\nName Gascost Time (ns) MGas/S Gasprice for 10MGas/S Gasprice for ECDSA eq\n----------------------------------------- --------- ---------------- ---------- ----------------------- -----------------------\nPrecompiledEcrecover/ 3000 157544 19.0423 1575.44 3000\nPrecompiledBlake2F/testVectors2bX_0 1 126 7.93651 1.26 2.39933\nPrecompiledBlake2F/testVectors2bX_3 1 127 7.87402 1.27 2.41837\nPrecompiledBlake2F/testVectors2bX_70 1 128 7.8125 1.28 2.43741\nPrecompiledBlake2F/testVectors2bX_140 1 125 8 1.25 2.38029\nPrecompiledBlake2F/testVectors2bX_230 1 128 7.8125 1.28 2.43741\nPrecompiledBlake2F/testVectors2bX_300 1 127 7.87402 1.27 2.41837\nPrecompiledBlake2F/testVectors2bX_370 1 131 7.63359 1.31 2.49454\nPrecompiledBlake2F/testVectors2bX_440 1 129 7.75194 1.29 2.45646\nPrecompiledBlake2F/testVectors2bX_510 1 125 8 1.25 2.38029\nPrecompiledBlake2F/testVectors2bX_580 1 131 7.63359 1.31 2.49454\n\n Copyright\n\nCopyright and related rights waived via CC0.\n\n Citation\n Please cite this document as:\n\n Tjaden Hess <tah83@cornell.edu>, Matt Luongo (@mhluongo), Piotr Dyraga (@pdyraga), James Hancock (@MadeOfTin), \"EIP-152: Add BLAKE2 compression function `F` precompile,\" Ethereum Improvement Proposals, no. 152, October 2016. Available: https://eips.ethereum.org/EIPS/eip-152.","tokens":4092,"squid":"spider-05","role":"Spec Spider","at":1791340060810,"hash":"41ae29e9458678c9b6c30224781fbfb3bfc28932"}
{"url":"https://akash.network/case-studies","domain":"akash.network","title":"Case Studies - Akash Network","text":"Project Spotlights\n\nProven performance on the open cloud. See how high-growth projects and\n research labs utilize the global GPU grid to scale mission-critical\n workloads.\n Why Astria Moved Its AI Image Workloads to Akash Network Eliminating Cloud Cost Opacity: How Sigea Cloud Labs Rebuilt Enterprise Storage on Decentralized Infrastructure Why Levangie Labs Chose Akash to Power the First Semi-Autonomous AI Organization How Flashback Labs Scaled Privacy-First AI on Akash How NodeShift Accelerates Enterprise AI Development With Akash Envision Labs Accelerates Generative AI on Akash Passage Reduces Cloud Spend by 50% With Akash Achieving Decentralized Physical State Consensus With Witness Chain on Akash","tokens":177,"squid":"spider-03","role":"Compute Spider","at":1791340060853,"hash":"8bf74c1f70d4245a78ee2831af3aaa33e8f8cbdd"}
{"url":"https://www.paradigm.xyz/investments","domain":"paradigm.xyz","title":"Investments | Paradigm","text":"Featured All Investments Nous Research Decentralized AI training Kalshi Prediction market platform Zipline Autonomous drone delivery infrastructure Citadel Securities Global market maker SendCutSend Rapid manufacturer Antares Factory-produced nuclear microreactors True Anomaly Orbital space defense Hyperliquid (HYPE) Financial trading platform Coinbase Crypto exchange and onchain platform Tempo Blockchain for payments Andromeda AI compute marketplace Stripe Internet payments infrastructure Uniswap Decentralized crypto exchange protocol Company (Asc) Description Category Credit-backed yieldcoin protocol 3Jane Credit-backed yieldcoin protocol DeFi Intent-based crosschain bridge Across Intent-based crosschain bridge DeFi, Infrastructure Stablecoin issuer and payments infrastructure Agora Stablecoin issuer and payments infrastructure Infrastructure, Payments AI-powered NFT gaming AI Arena AI-powered NFT gaming AI, Consumer Digital asset platform Amber Digital asset platform Trading & Markets AI compute marketplace Andromeda AI compute marketplace AI, Infrastructure Factory-produced nuclear microreactors Antares Factory-produced nuclear microreactors Hardware & Defense, Infrastructure Self-custody wallet Argent Self-custody wallet Consumer, DeFi, Payments ZK proving infrastructure Axiom ZK proving infrastructure AI, Infrastructure Privacy-first Ethereum L2 Aztec Privacy-first Ethereum L2 Infrastructure Native Bitcoin staking protocol Babylon Native Bitcoin staking protocol DeFi, Infrastructure Peer-to-peer sports betting exchange BetDex Peer-to-peer sports betting exchange Consumer, DeFi, Trading & Markets Latin American crypto financial platform Bitso Latin American crypto financial platform Consumer, Payments, Trading & Markets Ethereum L2 with native yield Blast Ethereum L2 with native yield DeFi, Infrastructure Wallet transaction security APIs Blowfish Wallet transaction security APIs Infrastructure NFT marketplace for pro traders Blur NFT marketplace for pro traders Consumer, Trading & Markets Blockchain intelligence platform Chainalysis Blockchain intelligence platform Infrastructure Global market maker Citadel Securities Global market maker Trading & Markets Competitive smart contract audits Code4rena Competitive smart contract audits Infrastructure Crypto exchange and onchain platform Coinbase Crypto exchange and onchain platform Consumer, Infrastructure, Payments, Trading & Markets Crypto exchange in India CoinSwitch Crypto exchange in India Consumer, Trading & Markets DeFi lending protocol Compound DeFi lending protocol DeFi Rollup deployment platform Conduit Rollup deployment platform Infrastructure Interoperable blockchain ecosystem Cosmos (ATOM) Interoperable blockchain ecosystem Infrastructure Brazilian real stablecoin issuer Crown Brazilian real stablecoin issuer Payments Onchain domain infrastructure D3 Onchain domain infrastructure Infrastructure Work and bounty platform Dework Work and bounty platform Consumer, Infrastructure Blockchain-based unsecured lending Divine Blockchain-based unsecured lending DeFi, Payments Decentralized perpetuals exchange dYdX Decentralized perpetuals exchange DeFi, Trading & Markets Cross-border payments for Latin America El Dorado Cross-border payments for Latin America DeFi, Payments Onchain exchange infrastructure Ellipsis Labs Onchain exchange infrastructure DeFi, Trading & Markets Ethereum institutional finance platform Etherealize Ethereum institutional finance platform Infrastructure Modular DeFi lending protocol Euler Modular DeFi lending protocol DeFi DeFi investment platform Exponential DeFi investment platform Consumer, DeFi Chip manufacturing infrastructure fab2 Chip manufacturing infrastructure Hardware & Defense, Infrastructure Decentralized social protocol Farcaster Decentralized social protocol Consumer, Infrastructure Digital asset custody infrastructure Fireblocks Digital asset custody infrastructure Infrastructure, Payments MEV infrastructure and research Flashbots MEV infrastructure and research Infrastructure Gaming NFT marketplace Fractal Gaming NFT marketplace Consumer SocialFi app on Base friend.tech SocialFi app on Base Consumer, DeFi DeFi risk management platform Gauntlet DeFi risk management platform Infrastructure Bitcoin mining company Genesis Digital Assets Bitcoin mining company Hardware & Defense, Infrastructure Open-source funding platform Gitcoin Open-source funding platform DeFi, Infrastructure Decentralized global exchange GTE Decentralized global exchange DeFi, Infrastructure, Trading & Markets Brand loyalty platform Hang Brand loyalty platform Consumer Mathematical reasoning AI lab Harmonic Mathematical reasoning AI lab AI Solana block-building infrastructure Harmonic Solana block-building infrastructure Infrastructure Financial trading platform Hyperliquid (HYPE) Financial trading platform Trading & Markets ZK proof acceleration hardware Irreducible ZK proof acceleration hardware Infrastructure Open-source crypto development Ithaca Open-source crypto development Infrastructure Mobile network for emerging markets Jambo Mobile network for emerging markets Consumer Prediction market platform Kalshi Prediction market platform Consumer, Trading & Markets Bitcoin privacy infrastructure Keep Network Bitcoin privacy infrastructure DeFi, Infrastructure Onchain orderbook for Monad Kuru Labs Onchain orderbook for Monad DeFi, Trading & Markets Decentralized Ethereum staking protocol Lido Decentralized Ethereum staking protocol DeFi, Infrastructure Bitcoin payment infrastructure Lightspark Bitcoin payment infrastructure Infrastructure, Payments Mobile crypto gaming company Limit Break Mobile crypto gaming company Consumer Mobile-first perps trading Liquid Mobile-first perps trading DeFi, Trading & Markets Gaming NFT marketplace Lootrush Gaming NFT marketplace Consumer, Payments Decentralized entertainment network Mad Realities Decentralized entertainment network Consumer NFT marketplace Magic Eden NFT marketplace Consumer, Trading & Markets Stablecoin protocol Maker (MKR) Stablecoin protocol DeFi Crypto financial services platform Matrixport Crypto financial services platform Trading & Markets Seamless crypto payments Mesh Connect Seamless crypto payments Infrastructure, Payments Markets for decision-making MetaDAO Markets for decision-making DeFi, Infrastructure, Trading & Markets Parallel EVM blockchain Monad Parallel EVM blockchain Infrastructure Crypto payments infrastructure Moonpay Crypto payments infrastructure Consumer, Payments Onchain lending and borrowing Morpho Onchain lending and borrowing DeFi, Payments Crypto-enabled narrow bank N3XT Crypto-enabled narrow bank Infrastructure, Payments Stablecoin issuance protocol Noble Stablecoin issuance protocol Infrastructure, Payments Prediction market for trends Noise Prediction market for trends DeFi Decentralized AI training Nous Research Decentralized AI training AI, Infrastructure Crypto computing system O(1) Labs Crypto computing system Infrastructure NFT marketplace OpenSea NFT marketplace Consumer, Trading & Markets Layer 2 blockchain Optimism Layer 2 blockchain Infrastructure DeFi options protocol Opyn DeFi options protocol DeFi Cross-chain AMM protocol Osmosis Cross-chain AMM protocol DeFi, Trading & Markets Sci-fi NFT card game Parallel Sci-fi NFT card game Consumer Web3 wallet Phantom Web3 wallet Consumer, Payments Tokenized energy asset management Plural Tokenized energy asset management Trading & Markets Embedded wallet infrastructure Privy Embedded wallet infrastructure Infrastructure Crypto exchange in EMEA Rain Crypto exchange in EMEA Consumer, Payments Stablecoin protocol Reflexer Labs Stablecoin protocol DeFi Global digital banking platform Revolut Global digital banking platform Consumer, Payments, Trading & Markets Decentralized structured products Ribbon Finance Decentralized structured products DeFi Onchain trading protocol Rift Onchain trading protocol DeFi, Payments, Trading & Markets Music investment platform Royal Music investment platform Consumer Rapid manufacturer SendCutSend Rapid manufacturer Hardware & Defense, Consumer Play-to-earn gaming Sky Mavis Play-to-earn gaming Consumer Sustainable onchain markets mitigating MEV Sorella Labs Sustainable onchain markets mitigating MEV DeFi Blockmesh operating system Spacemesh Blockmesh operating system Infrastructure Cross-border payments app Standard Economics Cross-border payments app Infrastructure, Payments ZK-based Layer 2 blockchain Starkware ZK-based Layer 2 blockchain Infrastructure Internet payments infrastructure Stripe Internet payments infrastructure Payments, Infrastructure Zero-knowledge infrastructure Succinct Zero-knowledge infrastructure Infrastructure Shared security protocol & marketplace Symbiotic Shared security protocol & marketplace DeFi, Infrastructure Synthetic derivatives protocol Synthetix (SNX) Synthetic derivatives protocol DeFi, Trading & Markets Tax & accounting software TaxBit Tax & accounting software Infrastructure Blockchain for payments Tempo Blockchain for payments Payments, Infrastructure Decentralized trading platform Trade[XYZ] Decentralized trading platform DeFi, Trading & Markets Orbital space defense True Anomaly Orbital space defense Hardware & Defense, Infrastructure Decentralized crypto exchange protocol Uniswap Decentralized crypto exchange protocol DeFi, Trading & Markets Crypto payments & treasury management Utopia Labs Crypto payments & treasury management Infrastructure, Payments Network for user-owned data Vana Network for user-owned data AI, Infrastructure Perps for private company valuations Ventuals (formerly Shadow) Perps for private company valuations Trading & Markets Web3 game Wildcard Web3 game Consumer Decentralized fixed-rate borrowing & lending protocol Yield Decentralized fixed-rate borrowing & lending protocol DeFi Zcash developers Zcash Open Development Lab Zcash developers Infrastructure Autonomous drone delivery infrastructure Zipline Autonomous drone delivery infrastructure Hardware & Defense, Consumer, Infrastructure NFT-based social platform Zora NFT-based social platform Consumer, Trading & Markets All AI Consumer DeFi Hardware & Defense Infrastructure Payments Trading & Markets List/Grid List/Grid Investment disclaimer: The current and historical investments or portfolio companies mentioned, referred to, or described on this page are not representative of all investments in vehicles managed by Paradigm and there can be no assurance that the investments will be profitable or that other investments made in the future will have similar characteristics or results. A list of investments can be found here. Excluded are positions that remain confidential due to competitive considerations or are pending public announcement by portfolio companies, as well as portfolio companies that have shut down without a liquidity event or exit and for which the equity has been written to zero without the corresponding receipt of another asset. Further, the list of investments is updated periodically, and as such may not reflect the most recent Paradigm investments. Past results of Paradigm's investments, pooled investment vehicles, or investment strategies are not indicative of future results. The liquid token positions presented reflect certain holdings of Paradigm's closed-end funds and are provided for informational purposes only. Position sizes fluctuate and are subject to change without notice. Nothing contained on this page or Paradigm's social media constitutes, or should be construed as, an offer to sell or a solicitation of an offer to buy any security, or as investment advice. Careers We don't just fund the frontier — we build it. Paradigm incubates projects from the ground up, working shoulder-to-shoulder with founders and researchers to turn early ideas into the protocols and companies that define what comes next. All Careers","tokens":2977,"squid":"spider-04","role":"Research Spider","at":1791340078582,"hash":"a5c87f4595290ddb063caf18c16497651c09719c"}
{"url":"https://eips.ethereum.org/EIPS/eip-158","domain":"eips.ethereum.org","title":"EIP-158: State clearing","text":"🎉 Final\n\n Standards Track: Core\n\n EIP-158: State clearing\n\n Authors\n Vitalik Buterin (@vbuterin)\n\n Created\n 2016-10-16\n\n Specification\n\nFor all blocks where block.number >= FORK_BLKNUM (TBA):\n\n In all cases where a state change is made to an account, and this state change results in the account state being saved with nonce = 0, balance = 0, code empty, storage empty (hereinafter “empty account”), the account is instead deleted.\n If an address is “touched” and that address contains an empty account, then it is deleted. A “touch” is defined as any situation where if the account at the given address were nonexistent it would be created.\n Whenever the EVM checks if an account exists, emptiness is treated as equivalent to nonexistence. Particularly, note that this implies that, once this change is enabled, there is no longer a meaningful difference between emptiness and nonexistence from the point of view of EVM execution.\n Zero-value calls and zero-value suicides no longer consume the 25000 account creation gas cost in any circumstance\n\nThe cases where a “touch” takes place can be enumerated as follows:\n\n Zero-value-bearing CALLs\n CREATEs (if the code that is ultimately saved is empty and there is no ether remaining in the account when it is saved)\n Zero-value-bearing SUICIDEs\n Transaction recipients\n Contracts created in contract creation transactions\n Miners receiving transaction fees (note the case where the gasprice is zero, and the account does not yet exist because it only receives the block/uncle/nephew rewards after processing every transaction)\n\n Specification (1b)\n\nWhen the EVM checks for emptiness (for the purpose of possibly applying the 25000 gas cost), emptiness is defined by is_empty(acct): return get_balance(acct) == 0 and get_code(acct) == \"\" and get_nonce(acct) == 0; emptiness of storage does not matter. This simplifies client implementation because there is no need to add extra complexity to make caches enumerable in the correct way and does not significantly affect the intended result, as the cases where balance/code/nonce are empty but storage is nonempty where this change would lead to an extra 25000 gas being paid are pathological and have no real use value.\n\n Specification (1c)\n\nDo not implement point 2 above (ie. no new empty accounts can be created, but existing ones are not automatically destroyed unless their state is actually changed). Instead, during each block starting from (and including) N and ending when there are no null accounts left, select the 1000 null accounts that are left-most in order of sha3(address), and delete them (ordering by hash is necessary so as to allow the accounts to be easily found by iterating the tree).\n\n Rationale\n\nThis removes a large number of empty accounts that have been put in the state at very low cost due to flaws in earlier versions of the Ethereum protocol, thereby greatly reducing state size and hence both reducing the hard disk load of a full client and reducing the time for a fast sync. Additionally, it simplifies the protocol in the long term, as once all “empty” objects are cleared out there is no longer any meaningful distinction between an account being empty and being nonexistent, and indeed one can simply view nonexistence as a compact representation of emptiness.\n\nNote that this proposal does introduce a temporary breaking of existing guarantees, in that by repeatedly zero-value-calling already existing empty accounts one can create a state change at a cost of 700 gas per account instead of the usual 5000 per gas minimum (with SUICIDE refunds this goes down further to 350 gas per account). Allowing such a large number of state writes per block will lead to heightened block processing times and increase uncle rates in the short term while the existing empty accounts are being cleared, and eventually once all empty accounts are cleared this issue will no longer exist.\n\n References\n\n EIP-158 issue and discussion: https://github.com/ethereum/EIPs/issues/158\n EIP-161 issue and discussion: https://github.com/ethereum/EIPs/issues/161\n\n Citation\n Please cite this document as:\n\n Vitalik Buterin (@vbuterin), \"EIP-158: State clearing,\" Ethereum Improvement Proposals, no. 158, October 2016. Available: https://eips.ethereum.org/EIPS/eip-158.","tokens":1070,"squid":"spider-05","role":"Spec Spider","at":1791340084180,"hash":"c8c3fb0d75d1c1bdcbf57bc071331eaa1bc87f6a"}
{"url":"https://akash.network/case-studies/how-nodeshift-accelerates-enterprise-ai-development-with-akash","domain":"akash.network","title":"How NodeShift Accelerates Enterprise AI Development With Akash","text":"by Zach Horn Case Studies 3 Min. Read Mar 18, 2025 How NodeShift Accelerates Enterprise AI Development With Akash 3 Min. Read Mar 18, 2025 \nby Zach Horn \nCase Study\n\nTL;DR: NodeShift, an enterprise AI deployment platform, integrated Akash GPUs (A100, H100, H200) to give enterprise customers instant access to high-density NVIDIA hardware for LLM training and AI agent deployment — without requiring users to navigate blockchain complexity.\n\nAkash Network provides cost-effective, secure, decentralized cloud computing at scale. When NodeShift, a streamlined AI model and agent deployment platform, needed reliable customer GPU access, Akash’s GPU marketplace emerged as an ideal solution. This case study examines how NodeShift leveraged Akash GPUs to simplify AI deployment and LLM training without requiring users to navigate blockchain complexities.\nBuilding a Platform for Enterprise AI\nNodeShift sought a scalable GPU provider to support enterprise AI workloads, including LLMs and AI Agents, requiring powerful GPUs like NVIDIA’s A100, H100, and H200. Traditional cloud solutions often involve lengthy procurement processes, high costs, and inflexible deployments. NodeShift needed a solution that would reduce barriers to adoption and streamline resource allocation while maintaining enterprise-grade security and reliability.\nChoosing the Akash Supercloud\nAkash Network’s decentralized GPU marketplace provided several enterprise-focused advantages. Customers gained access to high-density NVIDIA GPUs, which are essential for demanding AI tasks. Additionally, Akash enabled instant scalability through on-demand provisioning, eliminating traditional procurement delays. The marketplace also offered transparent and competitive pricing, significantly reducing enterprise expenses.\nIntegrating Akash\nNodeShift’s integration of Akash GPUs delivered substantial benefits:\n\nSeamless Enterprise Adoption: NodeShift’s familiar interface abstracts blockchain complexity, allowing users to deploy AI workloads effortlessly.\nEnterprise-Grade Storage: Attaching storage volumes directly to Akash GPUs simplifies data management, which is essential for extensive AI datasets.\nVirtual Private Cloud (VPC) Capabilities: Aggregating multiple GPUs within a single VPC enables sophisticated distributed workloads for training and inference.\n\nNodeShift’s deployment validated Akash’s decentralized infrastructure for enterprise security standards, ensuring workload isolation, reliability, and secure multi-tenancy.\nKey Benefits\n\nValidated Enterprise Scalability: Akash GPUs support rapid experimentation and production-level deployment.\nProven Cost Advantage: NodeShift’s adoption confirms Akash’s competitive pricing compared to traditional cloud providers.\nEnterprise-Ready AI Capabilities: Verified support for large-scale AI model training and deployment with top-tier GPUs.\nSimplified Enterprise Integration: NodeShift’s abstraction layer removed the need for specialized blockchain knowledge.\nRobust Data Management: Direct storage attachment to GPUs supports extensive AI training and iterative development.\n\nLooking Forward\nThe Akash and NodeShift integration demonstrates the viability of decentralized computing for enterprise-grade AI workloads. This partnership enhances Akash’s credibility in enterprise markets and provides organizations with immediate access to powerful GPU resources, accelerating innovation while reducing costs and complexity.\nAccelerate your enterprise AI workloads today with LLMs and AI Agents powered by NodeShift and Akash. Get started here: https://app.nodeshift.com/gpu/create\nFrequently Asked Questions\nWhat is NodeShift?\nA streamlined AI model and agent deployment platform for enterprises — abstracting blockchain complexity so organizations can deploy LLMs and AI agents on high-performance GPUs via a familiar interface.\nWhat GPU models does NodeShift provide via Akash?\nNVIDIA A100, H100, and H200 — the high-density GPUs required for demanding enterprise AI workloads including LLM training and AI agent inference.\nHow does NodeShift abstract blockchain complexity for enterprise users?\nNodeShift’s interface handles all Akash blockchain interactions behind the scenes — enterprise teams deploy AI workloads via familiar HTTP APIs and dashboards without managing wallets or on-chain transactions.\nWhat storage capabilities does the NodeShift + Akash integration offer?\nEnterprise-grade storage volumes attach directly to Akash GPUs — simplifying data management for large AI datasets essential for training and fine-tuning enterprise models.\nCan multiple Akash GPUs be combined in NodeShift?\nYes — Virtual Private Cloud (VPC) capabilities aggregate multiple GPUs within a single VPC, enabling sophisticated distributed workloads for training and inference at enterprise scale.\nHow quickly can enterprise teams access GPUs through NodeShift?\nInstantly — on-demand provisioning eliminates the lengthy procurement processes and minimum commitment periods that typically delay enterprise GPU access from traditional cloud providers.\nWhere can I get started with NodeShift and Akash?\nStart at app.nodeshift.com/gpu/create — deploy AI workloads powered by Akash GPUs directly through the NodeShift platform. \nShare this Case Study\n\nSee how Akash cut costs by 60%. Start with $100 Free Credits.\n\nShare this Case Study\n\nnote\n\ntip\n\nCaution\n\nDanger","tokens":1345,"squid":"spider-03","role":"Compute Spider","at":1791340094732,"hash":"0f5f4f1b83c88ecece0be3d8c87801e68b975155"}
{"url":"https://eips.ethereum.org/EIPS/eip-162","domain":"eips.ethereum.org","title":"ERC-162: Initial ENS Hash Registrar","text":"🎉 Final\n\n Standards Track: ERC\n\n ERC-162: Initial ENS Hash Registrar\n\n Authors\n Maurelian, Nick Johnson <nick@ethereum.org>, Alex Van de Sande <avsa@ethereum.org>\n\n Created\n 2016-10-25\n\n Contents\n\n Abstract\n Motivations\n Specification\n\n Initial restrictions\n Name format for hash registration\n Auctioning names\n Deeds\n Deployment and Upgrade process\n Registrar Interface\n\n Rationale\n\n Not committing to a permanent registrar at the outset\n Valid names >= 7 characters\n Restricting TLD to .eth\n Holding ether as collateral\n\n Prior work\n\n Abstract\n\nThis ERC describes the implementation, as deployed to the main ethereum network on 2017-05-04, of a registrar contract to govern the allocation of names in the Ethereum Name Service (ENS). The corresponding source code is here.\n\nFor more background, refer to EIP-137.\n\n Registrars are responsible for allocating domain names to users of the system, and are the only entities capable of updating the ENS; the owner of a node in the ENS registry is its registrar. Registrars may be contracts or externally owned accounts, though it is expected that the root and top-level registrars, at a minimum, will be implemented as contracts.\n\n - EIP 137\n\nA well designed and governed registrar is essential to the success of the ENS described in EIP 137, but is described separately in this document as it is external to the core ENS protocol.\n\nIn order to maximize utility and adoption of a new namespace, the registrar should mitigate speculation and “name squatting”, however the best approach for mitigation is unclear. Thus an “initial” registrar is proposed, which implements a simple approach to name allocation. During the initial period, the available namespace will be significantly restricted to the .eth top level domain, and subdomain shorter than 7 characters in length disallowed. This specification largely describes @alexvandesande and @arachnid’s hash registrar implementation in order to facilitate discussion.\n\nThe intent is to replace the Initial Registrar contract with a permanent registrar contract. The Permanent Registrar will increase the available namespace, and incorporate lessons learned from the performance of the Initial Registrar. This upgrade is expected to take place within approximately 2 years of initial deployment.\n\n Motivations\n\nThe following factors should be considered in order to optimize for adoption of the ENS, and good governance of the Initial Registrar’s namespace.\n\nUpgradability: The Initial Registrar should be safely upgradeable, so that knowledge gained during its deployment can be used to replace it with an improved and permanent registrar.\n\nEffective allocation: Newly released namespaces often create a land grab situation, resulting in many potentially valuable names being purchased but unused, with the hope of re-selling at a profit. This reduces the availability of the most useful names, in turn decreasing the utility of the name service to end users.\n\nAchieving an effective allocation may or may not require human intervention for dispute resolution and other forms of curation. The Initial Registrar should not aim to create to most effective possible allocation, but instead limit the cost of misallocation in the long term.\n\nSecurity: The registrar will hold a balance of ether without an explicit limit. It must be designed securely.\n\nSimplicity: The ENS specification itself emphasizes a separation of concerns, allowing the most essential element, the registry to be as simple as possible. The interim registrar in turn should be as simple as possible while still meeting its other design goals.\n\nAdoption: Successful standards become more successful due to network effects. The registrar should consider what strategies will encourage the adoption of the ENS in general, and the namespace it controls in particular.\n\n Specification\n\n Initial restrictions\n\nThe Initial Registrar is expected to be in service for approximately two years, prior to upgrading. This should be sufficient time to learn, observe, and design an updated system.\n\nDuring the initial two year period, the available name space will be restricted to the .eth TLD.\n\nThis restriction is enforced by the owner of the ENS root node who should not assign any nodes other than .eth to the Initial Registrar. The ENS’s root node should be controlled by multiple parties using a multisig contract.\n\nThe Initial Registrar will also prohibit registration of names 6 characters or less in length.\n\n Name format for hash registration\n\nNames submitted to the initial registrar must be hashed using Ethereum’s sha3 function. Note that the hashes submitted to the registrar are the hash of the subdomain label being registered, not the namehash as defined in EIP 137.\n\nFor example, in order to register abcdefg.eth, one should submit sha3('abcdefg'), not sha3(sha3(0, 'eth'), 'abcdefg').\n\n Auctioning names\n\nThe registrar will allocate the available names through a Vickrey auction:\n\n A Vickrey auction is a type of sealed-bid auction. Bidders submit written bids without knowing the bid of the other people in the auction. The highest bidder wins but the price paid is the second-highest bid. This type of auction… gives bidders an incentive to bid their true value.\n\n - Vickrey Auction, Wikipedia\n\nThe auction lifecycle of a name has 5 possible states, or Modes.\n\n Not-yet-available: The majority of names will be initially unavailable for auction, and will become available some time during the 8 weeks after launch.\n Open: The earliest availability for a name is determined by the most significant byte of its sha3 hash. 0x00 would become available immediately, 0xFF would become available after 8 weeks, and the availability of other names is distributed accordingly. Once a name is available, it is possible to start an auction on it.\n Auction: Once the auction for a name has begun, there is a 72 hour bidding period. Bidders must submit a payment of ether, along with sealed bids as a hash of sha3(bytes32 hash, address owner, uint value, bytes32 salt). The bidder may obfuscate the true bid value by sending a greater amount of ether.\n Reveal: After the bidding period, a 48 hour reveal period commences. During this time, bidders must reveal the true parameters of their sealed bid. As bids are revealed, ether payments are returned according to the schedule of “refund ratios” outlined in the table below. If no bids are revealed, the name will return to the Open state.\n Owned: After the reveal period has finished, the winning bidder must submit a transaction to finalize the auction, which then calls the ENS’s setSubnodeOwner function, recording the winning bidder’s address as the owner of the hash of the name.\n\nThe following table outlines important parameters which define the Registrar’s auction mechanism.\n\n Registrar Parameters\n\n Name\n Description\n Value\n\n totalAuctionLength\n The full time period from start of auction to end of the reveal period.\n 5 days\n\n revealPeriod\n The length of the time period during which bidding is no longer allowed, and bids must be revealed.\n 48 hours\n\n launchLength\n The time period during which all names will become available for auction.\n 8 weeks\n\n minPrice\n The minimum amount of ether which must be locked up in exchange for ownership of a name.\n 0.01 ether\n\n Deeds\n\nThe Initial Registrar contract does not hold a balance itself. All ether sent to the Registrar will be held in a separate Deed contracts. A deed contract is first created and funded when a sealed bid is submitted. After an auction is completed and a hash is registered, the deed for the winning bid is held in exchange for ownership of the hash. Non-winning bids are refunded.\n\nA deed for an owned name may be transferred to another account by its owner, thus transferring ownership and control of the name.\n\nAfter 1 year of registration, the owner of a hash may choose to relinquish ownership and have the value of the deed returned to them.\n\nDeeds for non-winning bids can be closed by various methods, at which time any ether held will either be returned to the bidder, burnt, or sent to someone else as a reward for actions which help the registrar.\n\nThe following table outlines what portion of the balance held in a deed contract will be returned upon closure, and to whom. The remaining balance will be burnt.\n\n Refund schedule\n\n Reason for Deed closure\n Refund Recipient\n Refund Percentage\n\n A valid non-winning bid is revealed.\n Bidder\n 99.5%\n\n A bid submitted after the auction period is revealed.\n Bidder\n 99.5%\n\n An otherwise valid bid is revealed on an owned name. 1\n Bidder\n 0.5%\n\n An expired sealed bid is cancelled. 2\n Canceler\n 0.5%\n\n A registered hash is reported as invalid. 3\n Reporter\n 50%\n\n A registered hash is reported as invalid. 3\n Owner\n 50%\n\n Notes:\n\n This incentivizes all bids to be revealed in time. If bids could be revealed late, an extortion attack on the current highest bidder could be made by threatening to reveal a new second highest bid.\n A bid which remains sealed after more than 2 weeks and 5 days may be cancelled by anyone to collect a small reward.\n Since names are hashed before auctioning and registration, the Initial Registrar is unable to enforce character length restrictions independently. A reward is therefore provided for reporting invalid names.\n\n Deployment and Upgrade process\n\nThe Initial Registrar requires the ENS’s address as a constructor, and should be deployed after the ENS. The multisig account owning the root node in the ENS should then set the Initial Registrar’s address as owner of the eth node.\n\nThe Initial Registrar is expected to be replaced by a Permanent Registrar approximately 2 years after deployment. The following process should be used for the upgrade:\n\n The Permanent Registrar contract will be deployed.\n The multisig account owning the root node in the ENS will assign ownership of the .eth node to the Permanent Registrar.\n Owners of hashes in the Initial Registrar will be responsible for registering their deeds to the Permanent Registrar. A couple options are considered here:\n\n Require owners to transfer their ownership prior to a cutoff date in order to maintain ownership and/or continue name resolution services.\n Have the Permanent Registrar query the Initial Registrar for ownership if it is lacking an entry.\n\n Planned deactivation\n\nIn order to limit dependence on the Initial Registrar, new auctions will stop after 4 years, and all ether held in deeds after 8 years will become unreachable.\n\n Registrar Interface\n\nfunction state(bytes32 _hash) constant returns (Mode)\n\n Implements a state machine returning the current state of a name\n\nfunction entries(bytes32 _hash) constant returns (Mode, address, uint, uint, uint)\n\n Returns the following information regarding a registered name:\n\n state\n deed address\n registration date\n balance of the deed\n highest value bid at auction\n\nfunction getAllowedTime(bytes32 _hash) constant returns (uint timestamp)\n\n Returns the time at which the hash will no longer be in the initial not-yet-available state.\n\nfunction isAllowed(bytes32 _hash, uint _timestamp) constant returns (bool allowed)\n\n Takes a hash and a time, returns true if and only if it has passed the initial not-yet-available state.\n\nfunction startAuction(bytes32 _hash);\n\n Moves the state of a hash from Open to Auction. Throws if state is not Open.\n\nfunction startAuctions(bytes32[] _hashes);\n\n Starts multiple auctions on an array of hashes. This enables someone to open up an auction for a number of dummy hashes when they are only really interested in bidding for one. This will increase the cost for an attacker to simply bid blindly on all new auctions. Dummy auctions that are open but not bid on are closed after a week.\n\nfunction shaBid(bytes32 hash, address owner, uint value, bytes32 salt) constant returns (bytes32 sealedBid);\n\n Takes the parameters of a bid, and returns the sealedBid hash value required to participate in the bidding for an auction. This obfuscates the parameters in order to mimic the mechanics of placing a bid in an envelope.\n\nfunction newBid(bytes32 sealedBid);\n\n Bids are sent by sending a message to the main contract with a sealedBid hash and an amount of ether. The hash contains information about the bid, including the bidded name hash, the bid value, and a random salt. Bids are not tied to any one auction until they are revealed. The value of the bid itself can be masqueraded by sending more than the value of your actual bid. This is followed by a 48h reveal period. Bids revealed after this period will be burned and the ether unrecoverable. Since this is an auction, it is expected that most public hashes, like known domains and common dictionary words, will have multiple bidders pushing the price up.\n\nfunction startAuctionsAndBid(bytes32[] hashes, bytes32 sealedBid)\n\n A utility function allowing a call to startAuctions followed by newBid in a single transaction.\n\nfunction unsealBid(bytes32 _hash, address _owner, uint _value, bytes32 _salt);\n\n Once the bidding period is completed, there is a reveal period during with the properties of a bid are submitted to reveal them. The registrar hashes these properties using the shaBid() function above to verify that they match a pre-existing sealed bid. If the unsealedBid is the new best bid, the old best bid is returned to its bidder.\n\nfunction cancelBid(bytes32 seal);\n\n Cancels an unrevealed bid according to the rules described in the notes on the refund schedule above.\n\nfunction finalizeAuction(bytes32 _hash);\n\nAfter the registration date has passed, this function can be called to finalize the auction, which then calls the ENS function setSubnodeOwner() updating the ENS record to set the winning bidder as owner of the node.\n\nfunction transfer(bytes32 _hash, address newOwner);\n\n Update the owner of the ENS node corresponding to the submitted hash to a new owner. This function must be callable only by the current owner.\n\nfunction releaseDeed(bytes32 _hash);\n\n After some time, the owner can release the property and get their ether back.\n\nfunction invalidateName(string unhashedName);\n\n Since registration is done on the hash of a name, the registrar itself cannot validate names. This function can be used to report a name which is 6 characters long or less. If it has been registered, the submitter will earn 10% of the deed value. We are purposefully handicapping the simplified registrar as a way to force it into being restructured in a few years.\n\nfunction eraseNode(bytes32[] labels)\n\n Allows anyone to delete the owner and resolver records for a subdomain of a name that is not currently owned in the registrar. For instance, to zero foo.bar.eth on a registrar that owns .eth, pass an array containing [sha3('foo'), sha3('bar')].\n\nfunction transferRegistrars(bytes32 _hash) onlyOwner(_hash);\n\n Used during the upgrade process to a permanent registrar. If this registrar is no longer the owner of the its root node in the ENS, this function will transfers the deed to the current owner, which should be a new registrar. This function throws if this registrar still owns its root node.\n\n Rationale\n\n Starting with a temporary registrar\n\nAnticipating and designing for all the potential issues of name allocation names is unlikely to succeed. This approach chooses not to be concerned with getting it perfect, but allows us to observe and learn with training wheels on, and implement improvements before expanding the available namespace to shorter names or another TLD.\n\n Valid names >= 7 characters\n\nPreserving the shortest, and often most valuable, domain names for the upgraded registrar provides the opportunity to implement processes for dispute resolution (assuming they are found to be necessary).\n\n Delayed release of names\n\nA slower release allows for extra time to identify, and address any issues which may arise after launch.\n\n Restricting TLD to .eth\n\nChoosing a single TLD helps to maximize network effects by focusing on one namespace.\n\nA three letter TLD is a pattern made familiar by it’s common usage in internet domain names. This familiarity significantly increases the potential of the ENS to be integrated into pre-existing DNS systems, and reserved as a special-use domain name. A recent precedent for this is the reservation of the .onion domain.\n\n Holding ether as collateral\n\nThis approach is simpler than the familiar model of requiring owners to make recurring payments to retain ownership of a domain name. It also makes the initial registrar a revenue neutral service.\n\n Prior work\n\nThis document borrows heavily from several sources:\n\n EIP-137 outlines the initial implementation of the Registry Contract (ENS.sol) and associated Resolver contracts.\n ERC-26 was the first ERC to propose a name service at the contract layer\n @alexvandesande’s current implementation of the HashRegistrar\n\n Edits:\n\n 2016-10-26 Added link Alex’s design in abstract\n 2016-11-01 change ‘Planned deactivation’ to h3’\n 2017-03-13 Update timelines for bidding and reveal periods\n\n Copyright\n\nCopyright and related rights waived via CC0.\n\n Citation\n Please cite this document as:\n\n Maurelian, Nick Johnson <nick@ethereum.org>, Alex Van de Sande <avsa@ethereum.org>, \"ERC-162: Initial ENS Hash Registrar,\" Ethereum Improvement Proposals, no. 162, October 2016. Available: https://eips.ethereum.org/EIPS/eip-162.","tokens":4334,"squid":"spider-05","role":"Spec Spider","at":1791340105760,"hash":"46830c68398ffa0ff8fe32065dfb282c029e3066"}
{"url":"https://docs.across.to/introduction/actors","domain":"docs.across.to","title":"Actors in the System | Across Docs","text":"Actors in the SystemThe key participants that make crosschain transfers work — users, relayers, LPs, dataworkers, and the UMA oracle.Across is a multi-actor system where each participant plays a distinct role in making crosschain transfers fast, secure, and capital-efficient. Understanding these roles helps you reason about the protocol's trust assumptions and economic incentives.\nUser\nUsers initiate crosschain transfers by submitting deposit orders to a SpokePool on the origin chain. They pay fees to relayers and liquidity providers in exchange for near-instant token delivery on the destination chain.\nUsers interact with the protocol through:\n\nThe Swap API (most common)\nERC-7683 open() calls\nDirect depositV3() calls on SpokePool contracts\n\nRelayer\nRelayers are the actors that make ~2 second fills possible. When a user deposits on the origin chain, relayers front their own capital on the destination chain to fill the intent immediately, then wait for reimbursement through the settlement process.\nHow Relayers Work\n\nMonitor origin SpokePools for V3FundsDeposited events\nEvaluate profitability (fees vs. gas costs and capital lock-up)\nCall fillV3Relay() on the destination SpokePool using their own tokens\nRequest repayment on any Across-supported chain (not necessarily the origin chain)\nReceive the user's inputAmount minus the LP fee after bundle settlement\n\nRelayer Risks\nRelayer fees compensate for real costs and risks:\nRiskDescriptionGas costsSubmitting fill transactions on destination chainsCapital lock-upFunds are locked until bundle settlement (~1.5 hours)Software bugsErrors in relayer implementation could lead to invalid fillsFinality riskChain reorganizations could revert confirmed fills\nPermissionless Participation\nRunning a relayer is permissionless — anyone can operate one. Risk Labs provides open-source relayer software, though developers can customize behavior or build alternative implementations.\nExclusive Relayers\nFor some intents, a relayer may have exclusive fill rights during an exclusivity period. This is determined by the exclusiveRelayer and exclusivityDeadline fields in the deposit. After the exclusivity window expires, any relayer can fill.\nLiquidity Provider (LP)\nLPs deposit assets into pools on Ethereum mainnet at across.to/pool. This capital serves two purposes:\n\nRepayment flexibility — Relayers can request repayment on any chain. LP capital ensures the HubPool can rebalance funds across SpokePools to honor these requests\nBackup fulfillment — In rare cases where no relayer fills a deposit, LP capital can be used to fulfill the transfer directly\n\nLP Risks\nRiskDescriptionCapital deploymentDeposited capital is actively used for rebalancing and fillsLiquidity riskHigh demand periods may temporarily prevent withdrawalsSmart contract riskStandard DeFi smart contract risk\nLP Fee Model\nLPs earn fees based on pool utilization — the more the pool is used for crosschain rebalancing, the higher the LP fee percentage. See Fees in the System for details on the utilization-based pricing model.\nDataworker\nThe dataworker is a whitelisted off-chain actor that coordinates settlement between all chains. It aggregates fills into bundles and proposes them to the HubPool on Ethereum.\nWhat the Dataworker Does\n\nDetermines block ranges for each supported chain\nValidates fills against deposits across all chains\nAggregates valid fills into payment lists\nComputes crosschain transfer instructions for rebalancing\nOrganizes everything into merkle trees\nProposes the bundle to the HubPool with a bond\n\nBundles\nA bundle is a set of merkle roots encoding:\n\nRelayer refund instructions (which relayers to pay, how much, on which chain)\nToken rebalancing instructions (how to move funds between SpokePools)\nSlow fill instructions (for deposits that weren't filled by relayers)\n\nBundles are proposed every ~1.5 hours minimum. After proposal, they enter a challenge period where anyone can dispute them.\nSettlement cost is O(1), not O(N). No matter how many individual fills happen in a period, they're aggregated into a single bundle proposal. This is what makes Across gas-efficient at scale.\nDataworker Rules\nDataworker behavior is precisely defined by UMIP-157 and UMIP-179 — UMA Improvement Proposals that specify exactly how bundles must be constructed. Any deviation from these rules can be disputed.\nUMA Optimistic Oracle\nThe UMA Optimistic Oracle provides the economic security layer for Across. It verifies that proposed bundles are valid through an optimistic verification mechanism.\nHow It Works\n\nThe dataworker proposes a bundle and posts a bond\nThe bundle enters a challenge period\nDuring this period, anyone can dispute the bundle by also posting a bond\nIf no dispute occurs, the bundle is finalized and executed\nIf disputed, UMA's Data Verification Mechanism (DVM) resolves it — UMA token holders vote on whether the bundle was valid\n\nTrust Assumption\nThe system only needs a single honest actor willing to dispute invalid proposals to remain secure. This is a much weaker trust assumption than requiring a majority of validators to be honest.\nSee Security Model for more details on the verification and dispute process.Fees in the SystemHow LP fees, relayer fees, gas fees, and capital fees are calculated in Across.Tracking DepositsMonitor crosschain transfer status using the deposit tracking API.","tokens":1340,"squid":"spider-09","role":"Bridge Spider","at":1791340105797,"hash":"b746bbf618fa614f89055977ddf6bd202b109389"}
{"url":"https://akash.network/case-studies/eliminating-cloud-cost-opacity-how-sigea-cloud-labs-rebuilt-enterprise-storage-on-decentralized-infrastructure","domain":"akash.network","title":"Eliminating Cloud Cost Opacity: How Sigea Cloud Labs Rebuilt Enterprise Storage on Decentralized Infrastructure","text":"by Michelle Javed Case Studies 6 Min. Read Jan 30, 2026 Eliminating Cloud Cost Opacity: How Sigea Cloud Labs Rebuilt Enterprise Storage on Decentralized Infrastructure 6 Min. Read Jan 30, 2026 \nby Michelle Javed \nCase Study\n\nTL;DR: Sigea Cloud Labs deployed privacy-first zero-knowledge cloud storage on Akash — achieving cost efficiency, operational resilience, and enterprise-grade performance while proving decentralized infrastructure supports complex encrypted file storage without vendor lock-in or centralized data custody.\n\nBy Michelle Javed\nSummary\nSigea Cloud Labs deployed privacy-first cloud storage on Akash Network’s decentralized GPU infrastructure, achieving cost efficiency, zero-knowledge security, and performance at scale while proving that enterprise-grade infrastructure no longer requires choosing between control, transparency, and economics.\nBreaking free from the hidden tax of centralized cloud storage\nSigea Cloud solves the problem of data exposure, surveillance, and loss of control caused by traditional centralized cloud providers. Most existing platforms scan user content, monetize metadata, impose artificial limits, and introduce security risks through centralized custody.\nFor privacy-conscious individuals, creators, professionals, journalists, developers, and organizations that require secure file storage and transfer without sacrificing usability or performance, traditional cloud providers present an impossible choice. Web3 builders and decentralized communities need censorship-resistant, verifiable, and trust-minimized cloud infrastructure that centralized providers cannot offer.\nBefore working with Akash, Sigea faced significant challenges with centralized infrastructure: high and unpredictable costs, limited scalability, vendor lock-in, and trust issues around data custody and operational transparency. Traditional cloud platforms also introduced performance bottlenecks and single points of failure that conflicted with the goal of building a privacy-first, decentralized cloud solution.\nLegacy cloud providers rely on opaque pricing models, tiered services, and surprise egress fees that make forecasting difficult. Organizations managing massive project datasets face artificial service tiers and hidden access fees that transform storage from a predictable utility into an unpredictable liability with sudden pricing changes and penalties tied to data movement.\nThe structural advantage centralized providers cannot replicate\nSigea’s advantage is not price. It is trust and control. Traditional clouds are built on centralized access models where the provider can technically see, scan, or restrict customer data. Sigea is designed so users retain control of their files at all times. That trust model is structural and cannot be replicated by legacy providers without fundamentally changing how their businesses operate.\nEven if AWS or Google Cloud reduced prices by 50%, they could not replicate a decentralized trust model without destroying the centralized control mechanisms that define their business architecture.\nThe team needed infrastructure that aligned with principles of decentralization, security, and resilience while remaining economically sustainable at scale.\nTHE SOLUTION\nBuilding zero-knowledge architecture on reverse-auction infrastructure\nSigea Cloud Labs is a privacy-first, decentralized cloud storage and file transfer solution designed for maximum security, speed, and ease of use. Built for users who prioritize end-to-end encryption, Sigea Cloud eliminates traditional intermediaries and file size limits, ensuring that files stay private and secure from upload to download.\nThe solution removes weaknesses of centralized providers by delivering true client-side encryption, zero-knowledge storage, and decentralized infrastructure with no intermediaries.\nCore infrastructure capabilities\nZero-Knowledge Encryption\nFiles are encrypted client-side so only the user controls access and decryption. The provider has no technical ability to access customer data.\nNo Middlemen or File Size Caps\nDirect, peer-powered transfers and storage without gateway bottlenecks or arbitrary limits.\nCross-Platform Support\nAvailable on major platforms including Android and iOS for seamless mobile use.\nHigh Performance\nOptimized for fast uploads and downloads with resilient delivery across networks.\nDeploying production workloads on decentralized infrastructure\nSigea Cloud runs distributed backend services that support encrypted file storage, secure file transfer, metadata coordination, and application APIs. These workloads include:\n\nStorage orchestration services\nEncryption and access-control services\nIndexing and retrieval coordination\nHigh-throughput data handling for large file uploads and downloads\nSupporting infrastructure such as application gateways, monitoring services, and scaling components to ensure high availability, performance, and fault tolerance\n\nRe-engineering Total Cost of Ownership through transparent pricing\nBy eliminating artificial service tiers and hidden access fees, Sigea turns storage from an unpredictable liability into a predictable operating expense. Organizations can plan, budget, and scale without worrying about sudden pricing changes or penalties tied to data movement.\nSigea is designed around transparent, usage-based costs that behave more like a utility. Organizations pay for what they use, without hidden penalties for accessing or moving their own data.\nAkash’s reverse-auction marketplace eliminates the opaque pricing models, tiered services, and surprise egress fees that make forecasting difficult under traditional cloud providers.\nMaintaining performance without centralized bottlenecks\nIn high-growth environments characterized by massive project datasets, Sigea’s distributed architecture on Akash maintains I/O performance and system reliability without the performance-ceiling traps of centralized providers.\nSigea is built to avoid the performance ceilings common in centralized systems. Instead of forcing all workloads through a single provider’s infrastructure, the architecture is designed to scale horizontally. This helps maintain consistent performance and reliability even as datasets grow.\nIntentional design philosophy\nSigea is intentionally designed without a traditional SDK. The goal is to remove complexity and middlemen rather than introduce new layers of integration. The current focus is on making secure storage simple, user-controlled, and composable at the system level rather than exposing low-level programmatic control.\nTHE IMPACT\nProving decentralization delivers practical business value\nBy deploying on Akash, Sigea achieved meaningful cost efficiency compared to traditional cloud providers, along with improved flexibility and infrastructure transparency. The decentralized model allows the team to scale workloads dynamically without long-term vendor lock-in, while maintaining high availability and performance.\nThe deployment gained greater operational resilience by removing single points of failure and aligning infrastructure with privacy-first and trust-minimized architecture.\nKey technical validation\nOne of the key milestones was successfully migrating core backend services to decentralized infrastructure while maintaining performance and reliability at scale. The team demonstrated the ability to handle large encrypted file transfers with consistent throughput and uptime, validating that privacy-first architecture can operate efficiently on decentralized cloud infrastructure. This has been a major technical validation for the platform and long-term roadmap.\nLessons learned\nBuilding on Akash’s permissionless GPU marketplace taught the team how to design systems that are inherently more resilient, transparent, and aligned with user trust. The team learned to architect for fault tolerance and geographic distribution from the ground up, while optimizing performance and cost in an environment without centralized control.\nLooking ahead\nThe next phase focuses on expanding platform capabilities and scaling adoption. Key milestones include:\n\nContinued optimization of performance and infrastructure\nNew features for secure file sharing and collaboration\nDeeper mobile and cross-platform integrations\nImproved developer tooling and APIs\nBroader enterprise and organizational use cases\nContinuing to advance decentralized, privacy-first architecture\n\nGET IN TOUCH\nLearn more about deploying privacy-first infrastructure on decentralized compute at akash.network\nFrequently Asked Questions\nWhat does Sigea Cloud build?\nA privacy-first, zero-knowledge cloud storage and file transfer solution — all files encrypted client-side so only the user controls decryption, with no file size limits and cross-platform support on Android and iOS.\nWhat is zero-knowledge storage?\nA model where files are encrypted before they leave the user’s device — the storage provider has no technical ability to access, scan, or monetize the content stored on their infrastructure.\nWhy does Sigea Cloud use Akash instead of AWS or Google Cloud?\nCentralized providers can technically access customer data, fundamentally conflicting with zero-knowledge architecture. Akash’s decentralized model is structurally aligned with user data sovereignty.\nWhat workloads does Sigea Cloud run on Akash?\nStorage orchestration, encryption and access-control services, indexing and retrieval coordination, high-throughput encrypted file handling, application gateways, monitoring, and scaling components.\nHow does Akash’s reverse-auction pricing help Sigea?\nAkash eliminates opaque pricing tiers and surprise egress fees — turning storage into a predictable utility where organizations pay for actual usage without penalties for moving their own data.\nWhat was the key technical validation from Sigea’s Akash deployment?\nSuccessfully migrating core backend services to decentralized infrastructure while maintaining performance and reliability at scale — including consistent throughput for large encrypted file transfers.\nDoes Sigea Cloud have an SDK?\nIntentionally no — Sigea is designed without a traditional SDK to remove complexity. The focus is on making secure storage simple and composable at the system level rather than adding programmatic integration layers. \nShare this Case Study\n\nSee how Akash cut costs by 60%. Start with $100 Free Credits.\n\nShare this Case Study\n\nnote\n\ntip\n\nCaution\n\nDanger","tokens":2613,"squid":"spider-03","role":"Compute Spider","at":1791340105841,"hash":"771be30ef431a019e6689770f04a988d495b28e2"}
{"url":"https://docs.across.to/introduction/relayers/running-relayer","domain":"docs.across.to","title":"Running a Relayer | Across Docs","text":"Running a RelayerSet up and operate your own Across V3 relay infrastructure.The Across V3 Relayer is a Node.js-based system that enables users to operate their own relay infrastructure. The complete source code is available in the relayer-v3 GitHub repository.\nSystem Requirements\nComponentMinimumCPU64-bit Dual Core @ 2+ GHzRAM4 GBOSUNIX-like (GNU/Linux, macOS)\nInstallation\nClone the repository and set up your environment:\ngit clone https://github.com/across-protocol/relayer-v3.git\ncd relayer-v3\ntouch .env\nchmod 0600 .env\nYour .env file stores sensitive configuration. Restrict permissions to protect private keys or mnemonics.\nCore Configuration\nEssential Environment Variables\nVariableDescriptionSECRETPath to private key or mnemonic fileRPC_PROVIDER_*RPC endpoints for supported chainsRPC_PROVIDERSProvider preference orderingSEND_RELAYSEnable transaction submission (default: false)MAX_RELAYER_DEPOSIT_LOOK_BACKLookback window in seconds\nGas Configuration\nVariableDescriptionMAX_FEE_PER_GAS_SCALER_*Per-chain gas fee multipliersPRIORITY_FEE_SCALER_*Priority fee adjustments\nOperational Workflow\n\nSimulate first — run with SEND_RELAYS=false to review transactions before going live:\n\nSEND_RELAYS=false yarn relay\n\nReview the simulated transactions and token approvals.\n\nGo live once you're satisfied:\n\nSEND_RELAYS=true yarn relay\nThe relayer identifies unfilled deposits across chains and attempts to fill them when your token balances permit.\nAdvanced Features\nRedis Caching\nRedis caching significantly improves performance by storing RPC responses. Configure it via the REDIS_URL environment variable.\nInventory Management\nRelayers can configure automatic rebalancing across chains using a JSON configuration that specifies:\n\nTarget allocation percentages per token and chain\nWETH wrapping/unwrapping thresholds\nIntelligent repayment chain selection\n\nSupported Tokens\nWETH, USDC, DAI, USDT, WBTC, UMA, ACX, BAL, SNX, and POOL.\nRefund Mechanism\nRelayers receive compensation through root bundles — a set of three Merkle roots containing all information necessary to refund relayers who fulfilled a deposit during a given block range. Root bundles are published every 1.5 hours minimum. Relayers choose their repayment chain, which affects how liquidity provider fees are distributed.\nSecurity Considerations\nThe relay bot requires in-memory access to private keys for transaction signing. Follow these best practices:\n\nDeploy in isolated environments\nUse key-based authentication for remote access\nRestrict filesystem permissions on secret files\nMaintain secure offline backups of key material\nLimit exposure of systems with raw disk access\nValidating Root BundlesHow root bundles are validated and what the verification process checks.Relayer NominationHow exclusive relayer nomination works and how to participate.","tokens":706,"squid":"spider-09","role":"Bridge Spider","at":1791340127511,"hash":"48cf2c46c64558ea52a5bdc46f4200bad5716086"}
{"url":"https://docs.switchboard.xyz/docs-by-chain/solana-svm/prediction-market/prediction-market-tutorial","domain":"docs.switchboard.xyz","title":"Prediction Market Tutorial | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.Example Code: The complete working example for this tutorial is available at sb-on-demand-examples/solana/prediction-marketThis tutorial demonstrates how to verify oracle feed configurations on-chain using Kalshi prediction market data. You'll learn a critical security pattern that prevents oracle substitution attacks.Version source of truth: SDK Version MatrixThe Problem: Oracle Substitution AttacksWhen using oracle data in your program, how do you know the oracle is fetching data from the sources you expect? A malicious actor could:Create a similar-looking oracle feed with different (manipulated) data sourcesPass that feed to your programExploit your program with incorrect dataExample Attack:Your program expects BTC price from Binance + CoinbaseAttacker creates a feed that looks similar but fetches from a manipulated sourceYour liquidation logic uses the wrong priceThe Solution: Feed ID VerificationSwitchboard feed IDs are deterministic SHA-256 hashes of the feed's protobuf definition:Feed Definition → Protobuf Encoding → SHA-256 Hash → Feed IDBy recreating the expected feed configuration on-chain and comparing its hash to the oracle's feed ID, you cryptographically prove the oracle uses exactly the data sources you expect.What You'll BuildA Solana program that:Receives oracle data for a Kalshi prediction market orderRecreates the expected feed configuration on-chainVerifies the feed ID matches before trusting the dataPrerequisitesRust and Cargo installedAnchor framework familiaritySolana CLI installed and configuredKalshi API credentials (API key ID and private key)Key ConceptsFeed ID DerivationFeed IDs are derived by:Constructing an OracleFeed protobuf messageEncoding it as length-delimited bytesComputing SHA-256 hashlet bytes = OracleFeed::encode_length_delimited_to_vec(&feed);\nlet feed_id = hash(&bytes).to_bytes();QuoteVerifierThe QuoteVerifier uses a builder pattern to verify Ed25519 signatures from oracle operators:let quote = QuoteVerifier::new()\n .queue(queue_account)\n .slothash_sysvar(slothashes)\n .ix_sysvar(instructions)\n .clock_slot(current_slot)\n .verify_instruction_at(0)?;Variable OverridesKalshi requires authentication. Variables like ${KALSHI_API_KEY_ID} are placeholders that get replaced at runtime when fetching the quote:const quote = await queue.fetchQuoteIx(crossbar, [feed], {\n variableOverrides: {\n KALSHI_API_KEY_ID: \"your-key-id\",\n KALSHI_SIGNATURE: signature,\n KALSHI_TIMESTAMP: timestamp,\n },\n});The On-Chain ProgramDependencies[dependencies]\nanchor-lang = \"0.31.1\"\nswitchboard-on-demand = { version = \"0.13.0\", features = [\"anchor\", \"devnet\"] }\nswitchboard-protos = { version = \"0.2.6\", features = [\"serde\"] }\nprost = \"0.13\"\nsolana-program = \">=2,<3\"\nfaster-hex = \"0.10.0\"Note: The current example program uses switchboard-on-demand 0.13.0 with the anchor and devnet features for the anchor-lang 0.31.1 toolchain.Program Structureuse anchor_lang::prelude::*;\nuse switchboard_on_demand::{SlotHashes, Instructions, QuoteVerifier};\nuse switchboard_protos::OracleFeed;\nuse switchboard_protos::OracleJob;\nuse switchboard_protos::oracle_job::oracle_job::{KalshiApiTask, JsonParseTask, Task};\nuse switchboard_protos::oracle_job::oracle_job::task;\nuse switchboard_on_demand::QueueAccountData;\nuse switchboard_on_demand::default_queue;\nuse prost::Message;\nuse solana_program::hash::hash;\n\ndeclare_id!(\"YOUR_PROGRAM_ID\");\n\n#[program]\npub mod prediction_market {\n use super::*;\n\n pub fn verify_kalshi_feed(\n ctx: Context<VerifyFeed>,\n order_id: String,\n ) -> Result<()> {\n // Step 1: Create QuoteVerifier with builder pattern\n let mut verifier = QuoteVerifier::new();\n verifier\n .queue(ctx.accounts.queue.as_ref())\n .slothash_sysvar(ctx.accounts.slothashes.as_ref())\n .ix_sysvar(ctx.accounts.instructions.as_ref())\n .clock_slot(Clock::get()?.slot);\n\n // Step 2: Verify the Ed25519 instruction at index 0\n let quote = verifier.verify_instruction_at(0).unwrap();\n\n // Step 3: Extract feed ID from verified quote\n let feeds = quote.feeds();\n require!(!feeds.is_empty(), ErrorCode::NoOracleFeeds);\n\n let feed = &feeds[0];\n let actual_feed_id = feed.feed_id();\n\n // Step 4: Recreate expected feed ID and verify match\n require!(\n *actual_feed_id == create_kalshi_feed_id(&order_id)?,\n ErrorCode::FeedMismatch\n );\n\n msg!(\"Feed ID verification successful!\");\n msg!(\"Feed ID: {}\", faster_hex::hex_string(actual_feed_id));\n msg!(\"Order ID: {}\", order_id);\n\n Ok(())\n }\n}Feed ID RecreationThe critical function that recreates the expected feed configuration:fn create_kalshi_feed_id(order_id: &str) -> Result<[u8; 32]> {\n // Build the Kalshi API URL\n let url = format!(\n \"https://api.elections.kalshi.com/trade-api/v2/portfolio/orders/{}\",\n order_id\n );\n\n // Construct the exact feed definition\n let feed = OracleFeed {\n name: Some(\"Kalshi Order Price\".to_string()),\n jobs: vec![\n OracleJob {\n tasks: vec![\n // Task 1: Fetch from Kalshi API\n Task {\n task: Some(task::Task::KalshiApiTask(KalshiApiTask {\n url: Some(url.clone()),\n api_key_id: Some(\"${KALSHI_API_KEY_ID}\".to_string()),\n signature: Some(\"${KALSHI_SIGNATURE}\".to_string()),\n timestamp: Some(\"${KALSHI_TIMESTAMP}\".to_string()),\n ..Default::default()\n })),\n },\n // Task 2: Parse JSON response\n Task {\n task: Some(task::Task::JsonParseTask(JsonParseTask {\n path: Some(\"$.order.yes_price_dollars\".to_string()),\n ..Default::default()\n })),\n },\n ],\n weight: None,\n }\n ],\n min_job_responses: Some(1), // unscaled job/source quorum\n min_oracle_samples: Some(1), // unscaled oracle/signature quorum\n max_job_range_pct: Some(0), // Intentional for this single-source verification; use a positive scaled value for normal multi-source feeds.\n };\n\n // Encode as protobuf and hash\n let bytes = OracleFeed::encode_length_delimited_to_vec(&feed);\n Ok(hash(&bytes).to_bytes())\n}Account Context#[derive(Accounts)]\npub struct VerifyFeed<'info> {\n /// The Switchboard queue - must be the default queue\n #[account(address = default_queue())]\n pub queue: AccountLoader<'info, QueueAccountData>,\n\n /// SlotHashes sysvar for signature verification\n pub slothashes: Sysvar<'info, SlotHashes>,\n\n /// Instructions sysvar for Ed25519 verification\n pub instructions: Sysvar<'info, Instructions>,\n}\n\n#[error_code]\npub enum ErrorCode {\n #[msg(\"No oracle feeds available\")]\n NoOracleFeeds,\n\n #[msg(\"Feed hash mismatch - oracle feed does not match expected configuration\")]\n FeedMismatch,\n}The TypeScript ClientKalshi AuthenticationKalshi uses RSA-PSS-SHA256 signatures for API authentication:import * as crypto from \"crypto\";\nimport * as fs from \"fs\";\n\nfunction loadPrivateKey(keyPath: string): crypto.KeyObject {\n const privateKeyPem = fs.readFileSync(keyPath, \"utf8\");\n return crypto.createPrivateKey(privateKeyPem);\n}\n\nfunction createSignature(\n privateKey: crypto.KeyObject,\n timestamp: string,\n method: string,\n path: string\n): string {\n const message = `${timestamp}${method}${path}`;\n const messageBuffer = Buffer.from(message, \"utf8\");\n\n const signature = crypto.sign(\"sha256\", messageBuffer, {\n key: privateKey,\n padding: crypto.constants.RSA_PKCS1_PSS_PADDING,\n saltLength: crypto.constants.RSA_PSS_SALTLEN_DIGEST,\n });\n\n return signature.toString(\"base64\");\n}Complete Client Flowimport { CrossbarClient } from \"@switchboard-xyz/common\";\nimport * as sb from \"@switchboard-xyz/on-demand\";\n\nasync function verifyKalshiFeed(\n apiKeyId: string,\n privateKeyPath: string,\n orderId: string\n) {\n // Step 1: Load Switchboard environment\n const { program, keypair, connection } = await sb.AnchorUtils.loadEnv();\n const queue = await sb.Queue.loadDefault(program!);\n const crossbar = new CrossbarClient(\"https://crossbar.switchboardlabs.xyz\");\n\n // Step 2: Create Kalshi authentication\n const privateKey = loadPrivateKey(privateKeyPath);\n const method = \"GET\";\n const path = `/trade-api/v2/portfolio/orders/${orderId}`;\n const timestamp = Date.now().toString();\n const signature = createSignature(privateKey, timestamp, method, path);\n\n // Step 3: Define the oracle feed\n const oracleFeed = {\n name: \"Kalshi Order Price\",\n minJobResponses: 1, // unscaled job/source quorum\n minOracleSamples: 1, // unscaled oracle/signature quorum\n maxJobRangePct: 0, // Intentional for this single-source verification; use a positive scaled value for normal multi-source feeds.\n jobs: [\n {\n tasks: [\n {\n kalshiApiTask: {\n url: `https://api.elections.kalshi.com${path}`,\n apiKeyId: \"${KALSHI_API_KEY_ID}\",\n signature: \"${KALSHI_SIGNATURE}\",\n timestamp: \"${KALSHI_TIMESTAMP}\",\n },\n },\n {\n jsonParseTask: {\n path: \"$.order.yes_price_dollars\",\n },\n },\n ],\n },\n ],\n };\n\n // Step 4: Simulate the feed (optional, for testing)\n const simulation = await crossbar.simulateFeed(oracleFeed, true, {\n KALSHI_SIGNATURE: signature,\n KALSHI_TIMESTAMP: timestamp,\n KALSHI_API_KEY_ID: apiKeyId,\n });\n console.log(\"Simulated value:\", simulation.results[0]);\n\n // Step 5: Fetch quote instruction with credentials\n const quoteIx = await queue.fetchQuoteIx(crossbar, [oracleFeed], {\n numSignatures: 1,\n variableOverrides: {\n KALSHI_SIGNATURE: signature,\n KALSHI_TIMESTAMP: timestamp,\n KALSHI_API_KEY_ID: apiKeyId,\n },\n });\n\n // Step 6: Create verification instruction\n const verifyIx = await yourProgram.methods\n .verifyKalshiFeed(orderId)\n .accounts({\n queue: queue.pubkey,\n slothashes: sb.SYSVAR_SLOTHASHES_PUBKEY,\n instructions: sb.SYSVAR_INSTRUCTIONS_PUBKEY,\n })\n .instruction();\n\n // Step 7: Build and send transaction\n const tx = await sb.asV0Tx({\n connection,\n ixs: [quoteIx, verifyIx],\n signers: [keypair],\n computeUnitPrice: 20_000,\n computeUnitLimitMultiple: 1.1,\n });\n\n const sim = await connection.simulateTransaction(tx);\n console.log(\"Verification logs:\", sim.value.logs);\n}Running the Example1. Clone the Examples Repositorygit clone https://github.com/switchboard-xyz/sb-on-demand-examples\ncd sb-on-demand-examples/solana/prediction-market2. Install Dependenciesnpm install3. Build and Deploy the Programanchor build\nanchor deploy --provider.cluster devnet4. Get Kalshi API CredentialsSign up at KalshiGenerate API credentials in your account settingsDownload your private key PEM file5. Run the Verificationnpm run start -- \\\n --api-key-id YOUR_API_KEY_ID \\\n --private-key-path /path/to/kalshi/private-key.pem \\\n --order-id YOUR_ORDER_IDExpected OutputKalshi Feed Verification Test\n==================================\n\nConfiguration:\n API Key ID: abc123...\n Order ID: 12345678-1234-1234-1234-123456789012\n Crossbar URL: https://crossbar.switchboardlabs.xyz\n\nSolana Configuration:\n Wallet: 7Js...\n Queue: FdRn...\n\nCreating Oracle Feed Definition...\nSimulating Feed with Crossbar...\n Simulation Result: 0.65...\n\nFetching quote instruction...\n Successfully fetched quote instruction\n\nTransaction Simulated\n\nTransaction Simulation Logs:\n[\n \"Program YOUR_PROGRAM_ID invoke\",\n \"Feed ID verification successful!\",\n \"Feed ID: 4cd1cad962425681af07b9254b7d804de3ca3446fbfd1371bb258d2c75059812\",\n \"Order ID: 12345678-1234-1234-1234-123456789012\",\n \"Program YOUR_PROGRAM_ID success\"\n]Use Cases1. Prediction Market SettlementBefore settling prediction market positions, verify the oracle is using the correct data source:// Verify feed configuration before settlement\nverify_kalshi_feed(ctx, order_id)?;\n\n// Now safe to use the oracle value\nlet price = feeds[0].value();\nsettle_positions(price)?;2. Conditional PaymentsRelease funds only when verified oracle data meets conditions:verify_kalshi_feed(ctx, order_id)?;\n\nlet yes_price = feeds[0].value();\nif yes_price > threshold {\n release_funds()?;\n}3. DeFi Protocol IntegrationVerify oracle configuration before using prices for:LiquidationsCollateral calculationsInterest rate adjustments4. Compliance & Audit TrailsProve on-chain that specific data sources were used:emit!(FeedVerified {\n feed_id: actual_feed_id,\n order_id: order_id,\n timestamp: Clock::get()?.unix_timestamp,\n});Security Best PracticesAlways Verify Feed Configuration// Good: Verify before trusting data\nrequire!(\n *actual_feed_id == create_kalshi_feed_id(&order_id)?,\n ErrorCode::FeedMismatch\n);\nlet price = feeds[0].value();\n\n// Bad: Trust without verification\nlet price = feeds[0].value(); // Dangerous!Validate Queue Account// Good: Ensure data comes from trusted Switchboard queue\n#[account(address = default_queue())]\npub queue: AccountLoader<'info, QueueAccountData>,Use QuoteVerifier// Good: Cryptographically verify oracle signatures\nlet quote = QuoteVerifier::new()\n .queue(queue)\n .slothash_sysvar(slothashes)\n .ix_sysvar(instructions)\n .clock_slot(slot)\n .verify_instruction_at(0)?;Extending the PatternGeneric HTTP APIsTask {\n task: Some(task::Task::HttpTask(HttpTask {\n url: Some(\"https://api.example.com/data\".to_string()),\n method: Some(Method::Get as i32),\n ..Default::default()\n })),\n}Polymarket IntegrationTask {\n task: Some(task::Task::HttpTask(HttpTask {\n url: Some(format!(\n \"https://clob.polymarket.com/event/{}\",\n event_id\n )),\n ..Default::default()\n })),\n}Multi-Source ValidationVerify multiple feeds use approved sources:for (i, feed) in feeds.iter().enumerate() {\n require!(\n *feed.feed_id() == expected_feed_ids[i],\n ErrorCode::FeedMismatch\n );\n}Next StepsPrice Feeds: Learn basic oracle integration in Basic Price FeedCustom Feeds: Create your own feed definitions in Custom FeedsRandomness: Explore verifiable randomness in RandomnessPreviousPrediction MarketNextRandomnessLast updated 2 months ago","tokens":3345,"squid":"spider-08","role":"Oracle Spider","at":1791340141806,"hash":"7b625760f756e6968f64d5760f874cc176ac2db5"}
{"url":"https://docs.across.to/introduction/bridge-across","domain":"docs.across.to","title":"The Bridge Across | Across Docs","text":"The Bridge AcrossA quick overview of what is happening with $ACX, and where to follow updates.The $ACX Exchange portal is not live yet. Follow @AcrossProtocol on X for the launch announcement and the latest details.\nOverview\n\"The Bridge Across\" is a governance proposal from Risk Labs to move Across from a token-based DAO to a private U.S. C-corporation (\"AcrossCo\"). The goal is to explore new growth opportunities for Across.\nThe proposal passed its Snapshot vote and the work is underway. As part of the transition, $ACX holders will be offered a way to exchange their $ACX through a dedicated portal. Full terms will be shared ahead of launch.\nThis page is a short summary with links to the primary sources. It is not legal, financial, or tax advice.\nPreparing\nTaking part will require holding $ACX in a wallet whose private keys you control, rather than on a centralized exchange. The guide to moving your $ACX off exchanges walks through setting up a wallet, withdrawing, and confirming the tokens arrived.\nBeware of scams. The portal link will only ever be announced through Across' official channels. Do not connect your wallet to a \"portal\" you found in a DM, reply, or search ad, and never share your seed phrase.\nLinks\nThe Bridge Across proposalThe proposal and the community discussion around it.Latest updateWhere the exchange portal currently stands.How to move your $ACX off exchangesGetting your $ACX into a self-custody wallet.\nStay updated\nAnnouncements, including the portal launch and the full terms, go out on @AcrossProtocol on X first.Relayer NominationHow exclusive relayer nomination works and how to participate.Bug BountyReport vulnerabilities and earn rewards through the Across Protocol bug bounty program.","tokens":434,"squid":"spider-09","role":"Bridge Spider","at":1791340147144,"hash":"4232b23cc6a0dc0155801a4b424f721cdd7802f7"}
{"url":"https://docs.switchboard.xyz/docs-by-chain/solana-svm/x402","domain":"docs.switchboard.xyz","title":"X402 Micropayments | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.X402 is a micropayment protocol that enables pay-per-request access to premium data sources on Solana. By integrating X402 with Switchboard, you can access paywalled APIs and RPC endpoints directly from oracle jobs, paying only for the data you consume.What is X402?X402 (named after the HTTP 402 \"Payment Required\" status code) is a protocol for micropayments on Solana. It allows data providers to monetize their APIs and services on a per-request basis, while consumers can access premium data without subscriptions or upfront commitments.Key benefits:Pay-per-use: Only pay for the data you actually consumeNo subscriptions: Access premium data without monthly commitmentsInstant payments: USDC micropayments settle immediately on SolanaSeamless integration: Works with standard HTTP APIs via authentication headersPrerequisite: A Solana keypair funded with USDC on mainnet-beta (including a USDC associated token account with balance) is required to generate PAYMENT-SIGNATURE headers.How It Works with SwitchboardSwitchboard integrates with X402 through variable overrides, a powerful feature that allows you to inject dynamic values into oracle job definitions at runtime. This enables oracles to authenticate with paywalled endpoints without storing sensitive credentials on-chain or in IPFS.┌─────────────────────────────────────────────────────────────────────────┐\n│ X402 + Switchboard Flow │\n└─────────────────────────────────────────────────────────────────────────┘\n\n ┌──────────┐ 1. Derive ┌────────────────┐\n │ Your │ PAYMENT-SIGNATURE │ x402 v2 Client │\n │ App │ ────────────────────────► │ │\n └──────────┘ └────────────────┘\n │ │\n │ 2. Pass headers as │\n │ variable overrides │\n ▼ │\n ┌──────────┐ │\n │Crossbar │ ◄─────────────────────────────────┘\n │ │ PAYMENT-SIGNATURE header\n └──────────┘\n │\n │ 3. Fetch oracle update\n │ with auth headers\n ▼\n ┌──────────┐ 4. Authenticated ┌────────────────┐\n │ Oracle │ HTTP request │ Paywalled │\n │ (TEE) │ ────────────────────────► │ RPC/API │\n └──────────┘ └────────────────┘\n │ │\n │ 5. Return signed │\n │ oracle data │\n ▼ │\n ┌──────────┐ │\n │ Quote │ ◄─────────────────────────────────┘\n │ Account │ Verified data\n └──────────┘The key innovation is that oracle feeds are defined inline (not stored on IPFS), with placeholder variables like ${X402_PAYMENT_SIGNATURE} that get replaced at runtime with actual authentication headers.Key Conceptsx402 v2 ClientCreate an x402 v2 client that can sign USDC payments on Solana:import { x402Client } from \"@x402/fetch\";\nimport { registerExactSvmScheme } from \"@x402/svm/exact/client\";\nimport { toClientSvmSigner } from \"@x402/svm\";\nimport { createKeyPairSignerFromBytes } from \"@solana/kit\";\n\nconst signer = await createKeyPairSignerFromBytes(keypair.secretKey);\nconst client = new x402Client();\nregisterExactSvmScheme(client, { signer: toClientSvmSigner(signer) });Variable OverridesInstead of hardcoding authentication headers in your feed definition, you use placeholders:const ORACLE_FEED = {\n name: \"X402 Paywalled RPC Call\",\n jobs: [{\n tasks: [{\n httpTask: {\n url: \"https://paywalled-api.example.com\",\n headers: [\n { key: \"PAYMENT-SIGNATURE\", value: \"${X402_PAYMENT_SIGNATURE}\" }\n ]\n }\n }]\n }]\n};At runtime, you derive the actual headers and pass them as overrides:const instructions = await queue.fetchManagedUpdateIxs(crossbar, [ORACLE_FEED], {\n variableOverrides: {\n X402_PAYMENT_SIGNATURE: paymentSignature\n }\n});Quote AccountsVerified oracle data is stored in a canonical quote account derived from the feed hash. This allows your on-chain program to read the authenticated data:const feedId = FeedHash.computeOracleFeedId(ORACLE_FEED);\nconst [quoteAccount] = OracleQuote.getCanonicalPubkey(queue.pubkey, [feedId]);Use CasesPremium RPC Endpoints: Access high-performance, paywalled Solana RPC nodesAuthenticated APIs: Fetch data from APIs requiring micropayment authenticationDynamic Authentication: Support custom authentication schemes without storing credentialsPay-per-Request Data: Access expensive data sources only when neededNext StepsFollow the X402 Tutorial for a complete implementation walkthroughExplore Variable Overrides for more dynamic feed patternsLearn about Custom Feeds for building your own oracle jobsPreviousRandomness TutorialNextX402 TutorialLast updated 7 months ago","tokens":1099,"squid":"spider-08","role":"Oracle Spider","at":1791340152946,"hash":"a4df23a8d47a4f0a98636d5e448da0195e8ff005"}
{"url":"https://across.to/blog/how-to-move-your-acx-off-exchanges","domain":"across.to","title":"How to Move Your $ACX Off Exchanges","text":"Following the passing of The Bridge Across proposal, $ACX holders will soon be able to exchange their $ACX for equity or USDC through the $ACX Exchange Portal. To participate, your $ACX must be held in a self-custody wallet, a wallet where you control the private keys, not on a centralized exchange.If you hold $ACX on an exchange, we recommend moving it to a self-custody wallet now.Note: Centralized exchanges may choose to delist $ACX at their own discretion. Step 1: Set up a self-custody walletIf you don't already have one, popular options include MetaMask, Rabby, or a hardware wallet such as Ledger or Trezor. Once your wallet is set up, copy your wallet address (it starts with \"0x\").Step 2: Withdraw your $ACX from the exchangeOn your exchange, look for \"Withdraw\" or \"Send,\" select $ACX, paste your wallet address, and choose the network. The exact steps vary by exchange — here are official guides for four of the largest:Coinbase: How to send cryptoBinance: How to withdraw cryptoKraken: How to withdraw cryptocurrenciesKuCoin: How to withdraw cryptoIf you use a different exchange, the process will be similar. Check your exchange’s help center for \"withdrawing crypto.\"Step 3: Verify your tokens arrivedConsider sending a small test amount first. Once it arrives, send the rest. You can confirm receipt in your wallet or on Etherscan.Stay safeDouble-check the address and network before confirming. Crypto withdrawals cannot be reversed.Never share your seed phrase or private keys with anyone. The Across team will never DM you first or ask for your keys.Only trust links from official Across channels. Be wary of fake \"exchange portal\" sites. The official portal link will be announced through our official channels when it goes live.Once the $ACX Exchange Portal is live, you will be able to connect your self-custody wallet to exchange your $ACX for equity or USDC. Related ArticlesSep 17, 2026The Across Token Buyout Portal is Now Live 2 MIN READ#GuidesJul 31, 2026No Gas on a New Chain? How to Arrive With ETH Ready to Spend 5 MIN READ#GuidesJul 29, 2026How to Bridge to Optimism: The OP Mainnet Guide for 2026 5 MIN READ#GuidesJul 17, 2026The Fastest Way to Bridge USDC and USDT to Plasma 4 MIN READ#GuidesJoin the Across community:","tokens":564,"squid":"spider-09","role":"Bridge Spider","at":1791340157204,"hash":"7d7ef299cdac45b8ad7fe68fa3c96fc2d4b44df2"}
{"url":"https://docs.switchboard.xyz/docs-by-chain/solana-svm/randomness","domain":"docs.switchboard.xyz","title":"Randomness | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.Blockchain users want randomness for many applications like gaming, NFT mints, lotteries, and more. However, this poses a fundamental challenge to blockchains, which are deterministic computers replicated across many nodes across the globe. Each node needs to produce the exact same output when given the same sequence of inputs.Imagine if an on-chain lottery was deciding whether to mint an NFT to Alice or Bob. If blockchain nodes ran their own randomness and some decided that the NFT would go to Alice, and others to Bob, there would be a state mismatch.This is where oracles come in. An oracle can run the randomness off-chain and then post a single result to the blockchain, ensuring that all nodes agree on the result of the randomness.However, as a third-party source of randomness, it's critical to make sure that nefarious actors cannot control the oracle and bias the randomness in their favor.As an oracle provider, Switchboard's network serves as a trusted and verified third-party that can post fair random numbers to the blockchain.Switchboard’s approachSwitchboard leverages Trusted Execution Environments (TEEs), which are protected areas inside of a computer's processing unit that cannot be altered or inspected. This means:No one, including the oracle operator, can alter the code that’s running on the TEEsNo one, including the oracle operator, can see what’s going on inside the chip, only inputs and outputs.This means that Switchboard oracles can generate safe and fair randomness that is free from malicious influence. As an extra layer of protection, Switchboard network incentives ensure that oracle oeprators that misbehave by experiencing downtime or withholding results can have their $SWTCH stake slashed.How to Use Switchboard RandomnessTo understand the flow, it's helpful to visualize the following 5 parties.Alice: blockchain userApp: on-chain applicationSwitchboard Contract: on-chain contract that handles anything Switchboard-related.Crossbar: server that helps you talk to oraclesOracle: generates randomnessThere are two stages, requesting and resolving the randomness.Request RandomnessFirst, Alice talks to the App requesting some random event.The App then generates a randomness request with a unique ID and sends it to the Switchboard contract.The Switchboard contract responds to the App with an oracle assignment.The App responds to Alice with the oracle assignment and randomness ID.Resolve RandomnessAlice sends the oracle assignment, randomness ID, and some other data to Crossbar to get the randomness.Crossbar asks the Oracle to generate randomness.The Oracle creates a randomness object and sends it to Crossbar which passes it back to Alice.Alice sends the randomness object to the App.The App asks the Switchboard contract to verify that the randomness it received from Alice is correct.If all is well, the Switchboard contract sends verification to the App, resolving the random event.Solana Technical Quick ReferenceAccount structure: use a Switchboard randomness account (commit/reveal state parsed by RandomnessAccountData) plus your app-owned state account/PDA (for app fields like randomness_account and commit_slot).PDA seeds: Switchboard randomness account is created with sb.Randomness.create(...). App PDA seeds are app-specific; tutorial examples use [b\"playerState\", user.key().as_ref()] and [b\"stateEscrow\"].Oracle assignment: assignment happens through the Switchboard request/commit flow and is checked during reveal/settlement. Store and verify the same randomness account reference across commit and settle.Generation window duration: treat this as policy-based. A strict freshness policy example is seed_slot == current_slot - 1, while less strict policies can be chosen for lower-sensitivity flows.Reveal readiness check: call RandomnessAccountData::get_value(clock.slot). At settle time, success means randomness is ready; error means not yet resolved.For complete Solana code (account structs, commit/reveal instruction flow, and slot checks), see the Randomness Tutorial.Next StepRead the Randomness Tutorial for full account structures, PDA examples, and commit/reveal validation patterns.--PreviousPrediction Market TutorialNextRandomness TutorialLast updated 7 months ago","tokens":1086,"squid":"spider-08","role":"Oracle Spider","at":1791340163159,"hash":"67ca0c1baa69de5830295edc63f62cd61c462cc1"}
{"url":"https://forum.across.to/t/the-bridge-across/2097/42","domain":"forum.across.to","title":"The Bridge Across - Proposals - Across Protocol","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 6\n\n 6\n\n 6\n\n 4\n\n 2\n\n read \n\n 22\n min\n\n Mar 11\n\n 41 / 41\n\n May 24\n\n Apr 25\n\n Load more posts above\n\n post by h3rf on Mar 18\n\n h3rf\n\nReading this further, only 100 US investors?\nHow many slots are left for non company, non employee, non insider, non VC affiliated people?\nI put about 10k USD into across(?), but its hardly worth anything now. I have 19,140 ACX tokens after staking.\nI can put 10k more in to meet the USD minimum, but even then, does not seem like I would make the 100 USA cut? I am an accredited investor.\nHow are the 100 people chosen? would I make the cut? I filled out the form. Let me know, so I can consider buying 9k USD more…..\n\n post by Bananachain on Mar 20\n\n Bananachain\n\n hart_UMA\n\n Following yesterdays 30+ min. AMA show, I feel none the wiser really. We learned that no decisions were made in the background yet but conversations have been ongoing with the VCs, who’s bread and butter occupation is structuring investments. Unfortunately, none of the business/investment proposition questions were answered, most not even addressed.\nE.g., what C Corp type was being considered (Close Corporation?) that is limited to 100 investors given that there seem to be already 106 significant holders exceeding 250k ACX holdings, consisting most likely of investors, whales and the team as was already pointed out here.\nAnd, if limiting shareholders is intended, how should further investors be able to join the cap table later?\nUnclear also what the intermediate to long term business strategy would be, apart from B2B agreements to provide the bridge as infrastructure and, presumably, striving for network effects.\nFurther how the new entity would be run and controlled? Would DAO members be involved there or be relegated as bystanders corresponding to their holding size?\nPerhaps the Q&A will shed some light on these technicalities.\nAnother take away is that the ACX in the Across DAO treasury would be “repossessed“ by RL and not form part of a share disbursement. So no AcrossCorp shares for the DAO itself. Of course the question did come to mind what would happen with the ~250 mil or so, I cannot remember the exact amount, tokens which RL awarded itself for strategic purposes about 2 years ago. Were they spent and if yes what for and if not, what would happen to them in this context? This way RL would hold ~50% of all ACX tokens. What will happen to all these tokens? Just be retired as is? This would be interesting regarding potential dilution.\nI found these two SAFE wallets and am wondering whether these are the corresponding ACX wallets for Across and RL:\n\n post by hart_UMA on Mar 26\n\n hart_UMA\n\n Some responses to questions in this forum thread and the Across Discord:\nLimits on US Investors:\n\nFor US people, and only US people, US security law limits the token-for-equity exchange to 100 accredited US investors (note that employees or insiders do not count towards this limit).\nFor non-US people, there is no legal limit on participation.\nFrom our data, most ACX tokenholder are non-US people. US tokenholder make up a small minority.\nIn my view, this US accredited investor limit is one of the biggest downsides of the proposal. However, as of the time of my writing this, substantially less than 100 US investors have indicated their interest in this conversion. (Remember, most token holders are non-US!) If you are interested in the token-for-equity conversion, you should fill out the form (@bananachain, @h3rf, @TheRealTuna_Across).\nIf the proposal passes, we will rank US investors based on when they filled out the form in the proposal. Our goal is to be as inclusive as possible, and based on the data we have so far, there is no one that would be excluded from participation.\n\nAdditional details on buyout financing:\n\nThe assets used to finance the buyout are held by Risk Labs (a shareholderless Foundation), not the Across DAO.\nThe DAO does not own or control Risk Labs assets (and it cannot as the DAO is not a legal entity). This is the standard DAO + Foundation structure that most token projects operate with, and it’s this structure that this proposal is looking to change.\nAcross DAO only holds unallocated ACX tokens. These tokens are controlled by the ACX tokenholders collectively, and are similar to “authorized but unallocated” shares in equity companies. These ACX tokens are essentially owned by no one, and the Across DAO essentially has no other assets.\nRisk Labs assets are partially held on chain (i.e. the RL multisig), but are also held offchain (bank accounts, etc).\nIf this proposal passes, Risk Labs if offering to transfer substantially all its Across related assets to AcrossCo, less the funds used to buyout any token holders who opt for the buyout. These assets are approximately worth the market capitalization of ACX before this proposal went live. Risk Labs has no obligation to transfer these assets, but it is proposing to do so because it believes it’s the best path forward for Across and all ACX token holders!\n\nEquity holders rights and economics:\n\nIf the proposal passes, tokenholders will have the option to exchange ACX tokens for AcrossCo equity.\nAs stated in my X post, all tokenholders will convert to the same class of shares, on the same terms, with the same economics.\nFor practical purposes, smaller investors will participate via a no-fee SPV. This SPV will have identical economics to all other investors.\n\nTimeline update:\n\nThe original forum post suggested closing the discussion today and moving to a snapshot vote.\nI suggest we delay the snapshot vote until early next week to allow for additional input and discussion.\n\n post by hash_error on Mar 26\n\n hash_error\n\n Appreciate the detail.\nI’m against the buyout of ACX token holders at -98% from November 2024 highs.\nThis is not unlocking value for Across’s token holding supporters who don’t meet the minimum proposed thresholds/requirements to participate in conversion.\nConsider this. If this passes, you are forcing smaller token holders to sell at 3 year price lows. No value beyond loss harvesting. Presumably, this is being offered now because a) the price is low so it costs less to convert and b) the value that comes with the Across protocol is close to ready to begin being realized.\nIs this a leveraged buyout? Have funds been raised at higher valuations? Are small guys receiving a forced buyout at 3 year low prices while the Across protocol is privately being valued at multiples to the buyout offer?\n\n post by 0xdoodee on Mar 26\n\n 0xdoodee\n\n Thank you @hart_UMA for your responses. Many folks had been waiting to hear back on these questions, so I agree that delaying the snapshot vote is sensible at this time to allow time for more discussion.\nA few follow-up questions:\nUS Investors\nBased on your answer, US investors that are not amongst the first 100 people to fill out the form will not be able to convert to equity. Even if unlikely to pose an issue, this imposes some possible risks for US investors which may be prudent to address.\n\nYou mention US investors will be ranked on the order in which the form was filled out. This order is not transparent, and investors are not able to independently verify if they are in the top 100 responders, which presents risk in the off chance team prioritizes friends and family, or simply wants to reduce converters. This can be resolved by using an on-chain signature instead of a form, or quite simply first come first serve in the order in which people send their tokens in to be converted to equity (which would have clear onchain proof).\nIn the case where it’s not first-come-first-serve - if someone is, say, 101st in queue, and someone in the top 100 backs out, can the person who is 101st still participate? If so, the deadline for someone in the top 100 to convert their tokens to equity must be before the buyout deadline, so that the 101st person still has time to convert to equity without risking being stuck with useless tokens!\n\nTokenomics\n\nWill unvested tokens be eligible to convert to equity or participate in the buyout?\nWhat will happen to tokens which are not converted or redeemed after the six month buyout window is closed? Are they rugged?\n\nTreasury\n\nIf this proposal passes, Risk Labs if offering to transfer substantially all its Across related assets to AcrossCo, less the funds used to buyout any token holders who opt for the buyout. These assets are approximately worth the market capitalization of ACX before this proposal went live. Risk Labs has no obligation to transfer these assets, but it is proposing to do so because it believes it’s the best path forward for Across and all ACX token holders!\n\nI assume the assets used the finance the buyout are from the $51m total raised from two Strategic raises - raises that involved selling ACX tokens in the interest of developing the protocol. Correct me if I’m wrong, but I find it poor taste that you are suggesting that Risk Labs is performing charity both in offering a buyout and offering to transfer funds to the new entity, as if Risk Labs would be completely in their right to rug both and just do whatever they want with the money.\nCan we get more transparency on the amount of Across-related assets? You mention “approximately the market cap of ACX before this proposal went live,” when the buyout price is approximately 25% above the market cap of ACX before the proposal went live. How is this enough then to cover a potential case where everyone chooses the buyout? Is the team supply is assumed to convert already? If everyone participates in the buyout except the team, will there be enough funds to cover it? Will the new entity have any funds in such a case or will any equity converters immediately be diluted because another raise must occur?\n\n post by acxhldr_52970 on Mar 26\n\n acxhldr_52970\n\n Look, I’ve been holding ACX since the early days and I usually just lurk (Discord is the bane of crypto’s existence), but some of these takes in the comments are making my head hurt so I gotta say something.\nCan we just step back for a second and think about what ACX actually is right now? It’s a governance token. That’s it. No IP rights, no revenue, no legal claim to anything. The DAO isn’t even a legal entity, so it literally can’t own IP. There’s a reason this thing was trading where it was trading. None of this should be controversial.\nNow Risk Labs comes along and says “hey, here’s ~$20M in assets and all the IP, we’re just gonna hand it to you as equity with real legal protections.” And people are… mad about this? I’m sorry, what? Do you guys understand how rare this is in crypto? Most teams would’ve just slowly ghosted the token, rugged, and built a new thing. That’s the typical playbook we’ve seen over and over and over again. Risk Labs is doing the opposite and treating tokenholders on the exact same terms as employees. That’s unheard of. I for one can’t wait to participate in this.\nAnd for the people who don’t want equity, there’s a buyout at a 25% premium to where the token sat for months. Months! You’re getting paid above market to walk away. How is that not a win? It’s so short sighted not to see this as a major win.\nYeah, the 100-person US cap isn’t ideal, I’ll give you that. But if you’d actually read Hart’s posts, you’d know there aren’t even 100 US holders. The vast majority of ACX holders are international. This is a non-issue that people are treating like a dealbreaker. You all need to slow down and actually read everything.\nI don’t get the negativity here. Honestly I think some folks just have a reflexive distrust of anything that sounds too good, but sometimes a good deal is just a good deal. This one’s pretty obviously that.\nI’m in full support of this and will be voting accordingly.\n\n post by hash_error on Mar 26\n\n hash_error\n\n I am only concerned with the small token holders who do not meet the minimum thresholds in the proposal and/or folks who would not be able to participate given potential jurisdictional complications.\nYou’re right though - we all held the shitcoin, governance only token all the way to the bottom while the protocol was built out and seemingly has turned into something of value.\nThere’s simply a cross-section of holders that this event will be a forced sale and exclusion of ability to participate in the new entity and the potential up side of value it’s intended to unlock.\nBoxing these people out is a choice, it does not have to be an inevitability.\nEveryone who’s in a position to participate in the conversion is not my concern.\n\n post by mr.bahama on Mar 27\n\n mr.bahama\n\n If you provide liquidity on Across and there is no more Across token, will the APY drop substantially? Is there a risk most LPs move elsewhere?\nWhat can we expect the new APY to be? If it’s below 4% there are lower risk alternatives with higher yield.\n\n post by Bananachain on Mar 28\n\n Bananachain\n\n Thank you @hart_UMA for the detailed feedback. Delaying the vote slightly will help to get everyone interested on board. What I am currently trying to asses from this proposal is its investment and long-term value merits, i.e. whether this represents a solid opportunity for tokenholders.\nHere a list of key points where additional clarity would really help:\n1. Valuation & Conversion\n\nWhat valuation underlies the token? Equity conversion beyond the current market price, and how does this align with the actual assets being transferred?\n\nWill ~250 million unallocated ACX tokens in the treasury be converted into shares alongside the allocation ~250 million ACX secured by RL?\n\n2. Asset Transfer, Structure & Runway\n\nWhat exactly will be transferred to AcrossCo besides IP (cash, etc.)?\n\nWhat operating runway does this provide under expected costs?\n\nGiven RL is not legally obliged, how will the transfer be structured and enforced in practice?\n\nHow will share entitlements be distributed to tokenholders?\n\n3. Shareholder Rights (especially for smaller holders)\n\nWhat rights will shareholders have in practice (information, voting, economic participation)?\n\nHow will minority holders be protected?\n\n4. Dilution & Future Investors\n\nWill shareholders have pre-emptive rights or other protections against dilution?\n\nHow much capacity is being reserved for future investors or incentives?\n\nAre there plans to bring in additional investors, and on what timeline?\n\n5. Business Model, Development & Execution\n\nWhat is the primary revenue model going forward?\n\nWhat, if any, are the concrete plans to expand into infrastructure / enterprise / data services?\n\nWill the protocol and underlying technology continue to be actively developed and upgraded?\n\n6. Commitment & Strategy\n\nWhat will be RL’s ongoing role and level of commitment to AcrossCo?\n\nWhat incentives ensure long-term alignment with shareholders?\n\nWhat is the intended path (organic growth, acquisitions, eventual sale or IPO), and what does success realistically look like in 3–5 years?\n\nOverall, I think the direction is interesting, but answering these points would help clarify whether this is not just structurally sound, but also a compelling investment with credible growth prospects.\n\n post by TheRealTuna_Across on Mar 28\n\n TheRealTuna_Across\n\n hart_UMA\n\n Now that it’s been clarified that non-US investors can be included without a minimum, I’m open to receiving equity in AcrossCo. I’ll need a bit of time to consolidate and organize my wallets. Last week, when I believed I would likely be excluded, I sold some ACX. I have now filled out the form and included the wallet I intend to move ACX into.\nI’ve trusted Risk Labs for a long time, but recently that trust has been harder to maintain. From my perspective, there has been a lack of transparency over the past year that contributed to the decline in value. For example, the depreciation of oSnap and the resulting shift in Across governance to a multisig structure was never clearly communicated. I only discovered that through documentation. Situations like that make it difficult for the community to stay aligned and confident.\nI also believe there were opportunities to strengthen ACX tokenomics during that period, which may have helped reduce losses for holders. When the team’s faith in the token weakens, holders don’t really have the ability to adapt alongside them, and we’re left reacting after the fact.\nThat said, I’m still willing to move forward and take part. I hope this transition is an opportunity to rebuild trust and ensure that value is distributed fairly to those who have supported the ecosystem. I’m prepared to commit what I have remaining, but I do so with the expectation that this won’t simply result in value accruing to Risk Labs without being shared more broadly. Don’t let me down.\n\n post by hash_error on Mar 29\n\n hash_error\n\n hart_UMA\n\n Additional questions.\n\nwhat was Across’s valuation for this raise?Unifying Ethereum: Across Raises $41M to Accelerate Crosschain Interop | Across Protocol\n\nwhat is your guidance for those who fall below the 250k ACX minimum threshold?\n\nwhat is your guidance for those who are US non-accredited investors?\n\nwhat is your guidance to qualified investors who can’t properly value the conversion opportunity without income statement, balance sheet or cash flow data?\n\n post by hart_UMA on Mar 31\n\n hart_UMA\n\n Thank you all for your thoughtful questions and responses. A few more common questions have been answered below.\nAlso, the snapshot vote is now live LINK. Please vote!\n\nIf everyone participates in the buyout except the team, will there be enough funds to cover it?\n\nYes. There are sufficient funds to cover the buyout even if everyone—including the team—chose that option.\n\nIf you provide liquidity on Across and there is no more Across token, will the APY drop substantially? Is there a risk that most LPs move elsewhere?\n\nThis was addressed in the community call. The plan is for rewards to be paid in USDC, which would allow liquidity provision to continue without depending on the Across token.\n\nWhat was Across’s valuation at its last fundraise?\n\nThe institutional financing announced in March 2025 occurred over a six-month period between April and October 2024 at a range of valuations between approximately $0.25 and $0.40 per token.\n\nWhat is the guidance for those who fall below the 250k ACX minimum threshold?\n\nThe goal is to make participation as inclusive as possible. If fewer than 100 accredited US investors participate, the minimums will be lowered to open it up to more people.\n\nWill the ~250 million unallocated ACX tokens in the treasury be converted into shares alongside the ~250 million ACX secured by Risk Labs?\n\nThis was addressed in my previous post: Across DAO only holds unallocated ACX tokens. These tokens are controlled by the ACX tokenholders collectively, and are similar to “authorized but unallocated” shares in equity companies. These ACX tokens are essentially owned by no one, and the Across DAO essentially has no other assets.\n\nWill Across be publishing financial statements for token holders to review?\n\nThis was addressed during our community call. Relevant documents and disclosures will be provided to those who are interested in participating in equity exchange. This is not a public offering and not all documents can be made publicly available. If you are interested in participating, please fill out the Exchange Indication Survey here!\n\nAgain, the Snapshot vote is now LIVE. Please vote, and thank you for your input and consideration!\n\n post by 0xpotatoooo on Mar 31\n\n 0xpotatoooo\n\n Hi. Brief background on myself. I have been active in DeFi and CT since 2021 and have used ACX from the moment it began, firstly as a liquidity provider with no real points campaign, blindly depositing, to receiving the ACX drop during the time of FTX collapsing, to continuing to use ACX during the L2 craze from 2023–2025.\nI have witnessed over the course of the last few months the ACX token cratering, mainly as a result of a combination of poor market conditions for altcoins and the bridge landscape moving towards more centralised options such as CCTP and LZ. Despite perhaps the lack of a concrete tokenomics link with the bridge business, I think the other factors outweigh.\nRegardless, I began accumulating the token towards the end of the last cycle and currently hold ~1.2% of circulating supply. I accumulated because Risk Labs have always conducted themselves with the utmost integrity and understood what it really meant to issue and manage a token in the wild (UMA as an example, which secures Polymarket decisions). As such, I was always under the impression that the team could pivot to be bigger and better.\nI will now walk you through my thinking on 1) what I think of the process, which came as a surprise, and 2) what I would like to see done differently. I will not comment on the 100 US investor piece or the SPV, as that does not pertain to large holders who may be in my shoes.\nIlliquid equity in crypto investing has in the vast majority of cases resulted in significant destruction of wealth for retail non-insiders and non-team members. There are many examples of this, including DATs, Seeds, and SAFTs across the industry. For me to convert into equity, I would need at least a full view of the financials and balance sheet of the equity entity. At this price point, I would be signing away a +$400k cheque without knowing much, which, as you’ll agree, is financial suicide. As such, the proposal as it stands straightjackets me into redeeming for the lowly price of $0.04375. Perhaps the purpose is obfuscation, but given how Risk Labs has conducted themselves thus far, I doubt this.\nNow some simple maths. Assuming a $51m treasury, after 2–3 years of burn this would look closer to perhaps $35m assuming no fees flowed. Assuming that 70% of the tokens are not circulating (the Etherscan number — some of these are DAO tokens that are useless and should be burned, some are team tokens that are vested out, so there is some double-dipping, but that’s fine) means the redemption price looks much closer to $0.050. Now take into account potential dead supply being 5–10% after 6 months, and the redemption price range is [$0.0538–$0.0583] rather than $0.04375. It’s hard not to feel incensed when I put the numbers in this stark a way. Cutting the numbers a different way, if we stick with the $0.04375 price (picked during the lows) and with a 5% lost token assumption (standard see AragonDAO e/g/), which gets swept by redeemers rather than confiscated by NewCo, then we would expect at least a $0.04594 redemption price — an additional 5% upside for loyal holders.\nWhat I would like to see changed in the proposal, or at least adjusted, for me to be comfortable voting and for Risk Labs to do right by token holders:\n\nFurther financial transparency on what the pro-forma entity financials look like, such that token holders such as myself can make an informed decision on why $0.04375 was picked. If we cannot receive this, then:\n\nMore importantly, reach an equitable solution for leftover circulating USD to flow to token holders post-6 months. ACX is an older token, so there will be some lost supply. This solution needs to present a split between the redeemers, which constitute active supply, and the equity entity. If (1) is not provided by Risk Labs, then it is impossible to fairly suggest a split between the two stakeholders, and I would strongly recommend giving remaining USD to redeemers, some of whom will be the team, since the redemption price is arbitrary and lacking transparency from our point of view.\n\nOwning and investing in tokens is hard and risky, but it also means I get to have conversations directly with founders such as this for protocols I own. I do believe the level of transparency you’ve shown thus far is many times greater than more unsavoury projects, but digging deeper, this is not a deal that does the risk of holding the ACX token justice.\nimage2116×834 223 KB\nHope to reach an equitable solution before the snapshot ends.\n\n post by 0xdoodee on Mar 31\n\n 0xdoodee\n\n I am surprised to see the snapshot is up with many of the concerns going ignored by Risk Labs - especially regarding transparency about financials.\nTo be blunt, the team has already contradicted themselves once about financials:\n\n“These assets are approximately worth the market capitalization of ACX before this proposal went live.”\n\nThis was contradicted by the later statement:\n\n“There are sufficient funds to cover the buyout even if everyone—including the team—chose that option.”\n\nWhere the total buyout price would be ~25% higher than the market cap of ACX before the proposal went live.\nIf the value of cash is even higher than the ~31 million or so confirmed to be available from the previous statement, token holders deserve to know to make an informed decision on whether the buyout price is fair.\nThe team has also ignored questions about whether unvested tokens (mostly theirs, and maybe some of the VC’s) would be eligible for the conversion, and whether tokens which do not convert or get bought out will be worthless after six months. These materially change the nature of the proposal and should be disclosed clearly.\nTo be clear - I’m not opposed to the proposal - just think there needs to be basic financial transparency before any vote proceeds, as a “yes” vote under current conditions imho is not informed consent.\n\n post by sinahab on Apr 1\n\n sinahab\n\n I’m an ACX holder and am planning to convert to equity. The transition makes sense to me given the current structure limits ability to engage with enterprises and lean into this next phase of adoption with stablecoins. I continue to believe in the team and am happy to follow their judgment here.\n\n post by gino1529 on Apr 2\n\n gino1529\n\n I have to agree with doodee about the lack of transparency regarding the financials and unvested tokens. Without this information, coupled with the numbers provided by potato, it’s difficult to believe token holders are being bought out at a fair price\n\n post by TheRealTuna_Across on Apr 3\n\n TheRealTuna_Across\n\n My closing remarks:\nWhile this proposal is framed as “optionality,” for many average ACX holders it is not a real choice.\nThe combination of the 250k ACX minimum for the SPV route, legal participation limits, and accredited-investor restrictions for many U.S. holders means a large portion of the community is effectively being funneled into the buyout path whether they want that outcome or not.\nThat makes this feel far less like an inclusive transition and far more like an institutional clean-up of the cap table at the expense of the very token holders who helped build belief in Across from day one.\nMany of us held through extreme volatility, years of execution risk, treasury funding rounds, roadmap uncertainty, and repeated promises that long-term protocol success would eventually translate into token-holder value(such as, turning on the fee switch). Now that the business case has become strong enough to justify a traditional corporate structure, the average investor is being asked to exit at a price that reflects the token’s depressed market conditions(that Risk Labs allowed to happen) rather than the strategic value that Risk Labs itself is claiming this new structure unlocks.\nThe most damaging part of this proposal is not the mechanics, it is the precedent.\nIt sends the message that retail token holders are useful for bootstrapping network effects, governance legitimacy, and community conviction, but once the protocol matures into something institutionally valuable, the endgame is to migrate that value into private equity structures that many of those same holders cannot realistically access.\nThat precedent will have a long-lasting impact on the reputation of Risk Labs and naturally leaves UMA holders asking what their own long-term alignment looks like when value outcomes for token communities can ultimately be reshaped at Risk Labs’ discretion.\nTrust, once broken at this stage, is extraordinarily difficult to rebuild.\n\n post by treggs6 on Apr 3\n\n treggs6\n\n An Alternative Path Forward for “The Bridge Across”\nA Venture DAO Framework That Preserves Community Participation, Protects Treasury Value, and Enables Corporate Transition\nPrepared by Seedplex | April 2026\n\nWho are we?\nSeedplex is at the forefront of the pseudo-tokenization of equity built around existing communities. Seedplex was part of the latest Solana Incubator cohort (6 out of 300+ applicants) but we can accommodate other chains fairly easily. Treggs, the CEO and author of this post, has been in crypto since 2016 but really ramped my participation up during DeFi Summer in 2020. They also Co-founded Flash trade in 2023, a pool to peer DEX exchange that really extended the model to offer derivatives on longer tail assets, and ultimately left in order to try and fix the problems traditional tokens have with Seedplex.\nExecutive Summary\nThe Bridge Across proposal aims to transition Across Protocol from a DAO and token structure to a U.S. C-corp, offering ACX holders either an equity exchange or a token buyout at $0.04375. ACX is trading at approximately the buyout price, meaning the market is assigning near-zero value to the equity component of the deal. If the transition proceeds as proposed, the Risk Labs treasury (currently estimated at ~$30M) is likely to be significantly drained as holders opt for the cash exit, leaving AcrossCo with substantially less capital on its balance sheet to fund future growth.\nSeedplex offers an alternative path that achieves the same end goal, a successful corporate transition, while preserving treasury value, keeping long-term holders, and giving exit-seeking investors a fair and orderly way out. The core mechanism is a Venture DAO: an on-chain entity that holds the equity investment (via a SAFE), issues freely tradable non-security Venture Tokens. Once established, it would execute a disciplined buyback strategy over a 3–6 month transition window. Critically, these buybacks are optimized to purchase tokens only below net asset value (NAV), making every buyback strictly accretive to long-term holders as supply is burned and NAV per token rises.\nThe result: investors who want liquidity can exit over time at or near the buyout price. Investors who want to stay gain exposure to Across equity through a familiar token format, with each Venture Token becoming increasingly valuable as sub-NAV buybacks burn supply. At the end of the transition, the remaining treasury executes the SAFE, AcrossCo (Delaware C-corp) receives operating capital, and the community retains exposure through a governance token with no individual SPV paperwork, no minimum thresholds, and no friction.\n\nThe Problem with the Current Proposal\nLoyal Holders Cashed Out at the Bottom\nPerhaps the most troubling aspect of the current proposal is what it means for the community members who believed in Across through the downturn. These holders stayed when the price fell, continued to participate in governance, and maintained conviction in the protocol’s long-term potential. Under The Bridge Across, they are effectively being taken out at the bottom.\nUnless a holder is willing and able to KYC into an SPV, or holds more than 5m ACX to convert directly to equity, the default path is a cash buyout at $0.04375. The very people who stuck around are the ones with the fewest options to continue their journey with Across. This is not a structure that rewards loyalty; it is one that forces loyal participants to exit at what may be the least favorable moment.\nMarket Signal: The Equity Component Is Being Priced at Zero\nACX is currently trading at approximately $0.04375, the exact buyout price offered in The Bridge Across proposal. This is a clear market signal. When a buyout offer exists and the token trades at parity with the cash option, it means the market is ascribing little to no incremental value to the equity exchange path. In other words, the average holder sees no reason to take the equity over the cash.\nThis is a problem for the protocol’s long-term ambitions. A transition where the majority of holders opt for cash rather than equity would undermine the community alignment that AcrossCo is trying to build.\nTreasury Drain Risk\nThe Bridge Across proposal states that the DAO’s liquid assets, roughly equivalent to the current market cap, would finance the buyout. With the treasury estimated at approximately $30M and rational economic incentives pointing holders toward the cash option, there is a meaningful risk that a significant portion of the treasury is consumed by buyouts before the transition is complete.\nEvery dollar that exits the treasury is a dollar that does not appear on AcrossCo’s balance sheet after incorporation. The very entity being created to accelerate growth could be born capital-constrained, the opposite of the intended outcome.\n\nThe Alternative: A Venture DAO Transition\nSeedplex proposes replacing the binary equity-or-cash structure with a Venture DAO, a purpose-built on-chain entity designed to hold traditional assets (equity, SAFEs, or similar instruments) while issuing governance tokens that trade freely in the open market.\nThe transition unfolds in a structured sequence over 3–6 months, designed to protect all participants:\nStep 1: Create the Venture DAO\nA new Venture DAO is established on-chain to serve as the investment vehicle for the Across transition. This DAO is purpose-built: its sole function is to hold and manage the equity position in the newly formed AcrossCo.\nStep 2: Seed the DAO and Issue Venture Tokens\nThe existing DAO treasury assets are transferred into the Venture DAO. ACX tokens are transitioned into Venture Tokens (ACXvt) on a pro-rata basis, accounting for team holdings and total dollar value. The Venture Token begins trading freely, seeded with initial liquidity at approximately $0.04375 to match the buyout price from the original proposal.\nThis step effectively represents a buyout of every circulating token. Every ACX holder receives Venture Tokens anchored to real treasury assets. No one is forced into paperwork, SPVs, or binary choices; just on-chain transactions which we are all familiar with.\nStep 3: Write up a SAFE with AcrossCo\nA SAFE (Simple Agreement for Future Equity) is signed between the Venture DAO and the newly formed AcrossCo. The SAFE specifies a post-money valuation cap and grants the Venture DAO the right to purchase equity using its treasury funds at any point during the 3–6 month transition window.\nThis structure gives the Venture DAO flexibility: it does not need to deploy all capital immediately. Instead, it can execute the SAFE at the end of the transition period, deploying whatever treasury remains after the buyback program concludes.\nStep 4: Disciplined Sub-NAV Buybacks\nDuring the transition window, the Venture DAO deploys a portion of its treasury to execute a TWAP buyback of ACXvt at any price below $0.04375. This is the mechanism that makes the entire structure work:\n\nIf holders want to exit, they can sell their Venture Tokens on the open market at or near the buyout price. The TWAP buyback provides consistent demand.\n\nIf sell pressure is heavy and the price dips below $0.04375, the buyback does not chase the price up. Instead, it buys at a discount, which is strictly accretive to remaining holders. NAV per token rises as tokens are purchased below intrinsic value and burned.\n\nInvestors who panic-sell or need immediate liquidity are the ones penalized by selling below NAV. Long-term holders are the beneficiaries, as each burned token concentrates more value into fewer hands.\n\nThe buyback pace is optimized to absorb sell flow without artificially inflating the price. It acts as a soft floor, not a wall.\nStep 5: SAFE Execution and Finalization\nAt the end of the 3–6 month window, the SAFE is executed. Whatever treasury balance remains after buybacks is deployed to purchase equity in AcrossCo. Venture Token holders now govern a DAO whose treasury contains equity in a growth-stage company. The tokens continue to trade freely.\nIf a future liquidity event occurs (IPO, acquisition, or similar), proceeds flow back to the Venture DAO treasury, and qualified token holders can redeem proportionally by burning their tokens.\n\nWhy This Path Is Superior\nTreasury Preservation\nUnder the current proposal, every dollar used for buyouts is a dollar lost to AcrossCo. Under the Venture DAO model, treasury dollars used for sub-NAV buybacks are not lost. They are converted into burned tokens, concentrating value for remaining holders. The remaining treasury is then deployed into the SAFE. The total value is preserved; it simply shifts between equity and token supply reduction.\nAccretive Mechanics for Long-Term Holders\nEvery sub-NAV buyback mathematically increases the NAV per outstanding Venture Token. This means holders who believe in Across and choose to stay are actively rewarded by the exit of short-term holders. At the end of the 6-month window, each remaining Venture Token should be worth more than $0.04375, not less. This is a fundamentally different incentive structure from the current proposal, where early exiters and long-term believers are treated identically.\nOrderly, Market-Driven Exit for Liquidity Seekers\nInvestors who want out can sell on the open market throughout the transition. There is no 6-month waiting period for a buyout window to open. There is no administrative overhead. The TWAP provides sustained bid-side liquidity. If there is concentrated sell pressure, the price may temporarily dip below the buyout equivalent, but this is a feature, not a bug. It penalizes forced selling and rewards patience, creating a natural sorting mechanism between short-term and long-term participants.\nNo Minimum Thresholds, No SPV Friction\nEvery token holder, regardless of size, maintains the same access and exposure. There is no 250,000 ACX minimum. There is no SPV enrollment process. There is no KYC requirement simply to hold. There are no separate tiers for large and small holders. Community members hold a token, and that token governs a treasury that holds equity. The loyal holders who believed in Across through the downturn are not forced to exit at the bottom; they can continue their journey alongside the protocol as it grows.\nAcrossCo Still Gets What It Needs\nThe end state is identical to what The Bridge Across envisions: AcrossCo is a properly incorporated U.S. C-corp with institutional credibility, enforceable contracts, and structured revenue agreements. The difference is how it gets there. Instead of a binary buyout that drains the treasury, Across receives capital through a SAFE execution funded by whatever remains after the market has sorted its participants. The community stays engaged. The balance sheet stays healthy.\n\nSide-by-Side Comparison\n\nDimension\nThe Bridge Across\nVenture DAO (Seedplex)\n\nTreasury Impact\nLikely drained significantly by cash buyouts\nPreserved; sub-NAV buybacks are accretive, remainder funds the SAFE\n\nExit Mechanism\n6-month buyout window at fixed price ($0.04375)\nContinuous open-market liquidity with TWAP buyback support\n\nEquity Access\nDirect (>5M ACX) or via SPV (250K+ ACX minimum)\nAll holders via Venture Token; no minimums, no SPV\n\nHolder Incentives\nIdentical treatment for exiters and believers\nSub-NAV buybacks reward long-term holders; NAV rises as supply shrinks\n\nCommunity Continuity\nToken ceases to exist; holders become shareholders or exit\nToken continues trading freely; community structure preserved\n\nCorporate Outcome\nAcrossCo formed; treasury funds buyout\nAcrossCo formed; SAFE funded by remaining treasury\n\nComplexity for Holders\nEquity exchange paperwork or buyout claim\nHold a token; same experience as today\n\nCash on Balance Sheet\nReduced by buyout outflows\nMaximized by deploying only remaining treasury into SAFE\n\nIllustrative Scenario\nConsider the following simplified scenario to illustrate the mechanics:\nStarting Conditions: The Venture DAO is seeded with $30M in treasury assets. Venture Tokens are issued and begin trading at $0.04375 (the NAV-equivalent price). The SAFE is signed with AcrossCo.\nDuring the Transition (Months 1–6): Around 45% of circulating supply token holders decide to exit. They sell their Venture Tokens on the open market. The TWAP buyback absorbs this sell pressure, purchasing tokens at an average price of $0.038 (below NAV). Roughly $12M in treasury is deployed on buybacks, burning a significant portion of the token supply.\nAt the End of Month 6: The remaining treasury balance of ~$18M is deployed to execute the SAFE with AcrossCo. The remaining Venture Tokens, now representing a smaller supply, govern a treasury that holds $18M worth of equity in AcrossCo. NAV per token has risen to $0.04866 due to the accretive buybacks.\nThe Outcome: AcrossCo receives $18M in growth capital. Exiting holders received liquidity at or near the buyout price. Remaining holders own a more concentrated, more valuable position. The community structure is intact.\n\nConclusion\nThe Bridge Across proposal correctly identifies the need for Across to evolve beyond a pure DAO and token structure. The motivation is sound: institutional credibility, enforceable contracts, and a path to sustainable growth all require a corporate wrapper. Seedplex does not dispute this.\nWhat Seedplex offers is a better mechanism for getting there. The Venture DAO model preserves the treasury, rewards long-term alignment, provides orderly liquidity for those who want it, and eliminates the structural friction that currently pushes smaller holders toward the exit. It accomplishes everything The Bridge Across sets out to do while keeping the community on the same side of the table.\nOn the operational side of things, we believe this approach will carry significantly lower costs across the board as the legal work and entity set up to enable the Venture Token is what Seedplex has already worked on for the last year.\nAcross deserves a transition that is as well-engineered as the protocol itself. We believe this is it.\n**I encourage all people who are even curious about an alternative to the current proposal to vote “No” on this. I think it’s definitely worth a discussion. Feel free to respond this post in the forum and/or reach out privately to me through Telegram (@Treggs61).\n\n 21 days later\n\n post by chuck704 on Apr 25\n\n chuck704\n\n I am interested in participating in the go-private transaction but logistically need to come in via fiat not tokens. Is there an avenue for me to do this?\n\n 1 month later\n\n Closed on May 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 The Across token buyout portal is now live\n\n Updates\n\n Updates\n\n 19d\n\n Risk Labs Retroactive Funding and Future Development\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 5\n\n Sep 2024\n\n Risk Labs Funding Proposal for Growth, Expansion and Across v3\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 11\n\n Oct 2023\n\n Across ($ACX) Community Initial Liquidity Proposal\n\n Passed Proposals\n\n Passed Proposals\n\n 49\n\n Nov 2022\n\n Across Token Launch Proposal\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 214\n\n May 2022","tokens":10842,"squid":"spider-09","role":"Bridge Spider","at":1791340169271,"hash":"a0aa788eab52c697e20e3894c633ac5082edb3e3"}
{"url":"https://docs.switchboard.xyz/docs-by-chain/solana-svm/price-feeds","domain":"docs.switchboard.xyz","title":"Price Feeds | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.Access to reliable, real-world data is essential for decentralised applications (dApps), particularly in Decentralised Finance (DeFi). Real-time asset prices, forming the backbone of any DeFi protocol, are among the most critical data points.This is where Data Feeds come in. Think of them as secure bridges connecting the off-chain world of financial markets to your on-chain smart contracts. They provide a continuous stream of verified, aggregated price data for a wide range of assets, enabling your dApp to react to market fluctuations and operate correctly.In This SectionBasic Price Feed Tutorial: Integrate managed, oracle-verified price feeds into a Solana program.Advanced Price Feed Tutorial: Reduce compute costs with an authorized cranker pattern for oracle-backed quotes.Quote Program Accounts: Derive and read canonical quote-program accounts without relying on fixed offsets.Authority-Updated Feeds: Publish quote accounts directly from a trusted wallet or PDA when your application is the source of truth.For new Solana/SVM feed-hash integrations, use the quote program: queue.fetchManagedUpdateIxs(...) writes canonical OracleQuote accounts derived from the queue and feed ID. The classic PullFeed.fetchUpdateIx(...) path is legacy compatibility only and requires queue/gateway support for classic PullFeed accounts.PreviousSolana / SVMNextBasic Price Feed TutorialLast updated 3 months ago","tokens":375,"squid":"spider-08","role":"Oracle Spider","at":1791340173209,"hash":"ad286edf4de7cfaf981619edf2d0897a463efee6"}
{"url":"https://docs.switchboard.xyz/docs-by-chain/solana-svm/surge","domain":"docs.switchboard.xyz","title":"Surge Price Feeds | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.Version source of truth: SDK Version MatrixThe Future of Oracle TechnologySwitchboard Surge is the industry's fastest oracle data delivery system, providing sub-100ms latency through direct WebSocket streaming. Built for the next generation of DeFi applications, trading systems, and real-time dashboards.Key InnovationTraditional oracles require multiple steps—gathering prices, writing to blockchain state, reaching consensus, and then making data available—resulting in 2-10 seconds of latency.Switchboard oracles must pass a hardware proof when joining the network, ensuring they run only verified Switchboard code. This allows oracles to stream price data directly from sources to your application via WebSocket, achieving sub-100ms latency.┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐\n│ Price Sources │────▶│ Oracle Network │────▶│ Surge Gateway │\n│ (CEX, DEX) │ │ (SAIL Verified) │ │ (WebSocket) │\n└──────────────────┘ └──────────────────┘ └────────┬─────────┘\n │\n ┌──────────▼──────────┐\n │ Your Application │\n │ • Event Listeners │\n │ • Price Handlers │\n │ • Oracle Quotes │\n └─────────────────────┘Key FeaturesUnmatched Performance — Sub-100ms latency with direct WebSocket streaming and event-driven updates. No polling required.Zero Setup — No data feed accounts, on-chain deployment, or SOL funding needed. Just use your keypair and connection to start streaming.Cost Efficiency — Subscription-based pricing with no gas fees for receiving updates. Reduced on-chain costs when converting to Oracle Quotes.Seamless Integration — TypeScript/JavaScript SDK, WebSocket API for any language, and Oracle Quote conversion for on-chain use.Enterprise-Grade Reliability — 99.9% uptime SLA with global infrastructure, automatic failover, and professional support.User FlowSurge works the same way regardless of your target chain:Subscribe — All Surge subscriptions are managed on Solana, regardless of which chain you're building on. Connect your Solana wallet at the subscription portal.Authenticate — The SDK authenticates your session by signing with your Solana keypair. If the keypair does not have an active subscription, connectAndSubscribe will fail.Stream Prices — Once subscribed, prices stream directly to your application via WebSocket. No on-chain reads required—this is what enables sub-100ms latency.Use Prices — When you need prices on-chain, convert the Surge update to your chain's format and submit it. Switchboard provides SDKs for Solana, EVM, and Sui.Getting Started1. SubscribeConnect your wallet and subscribe at explorer.switchboardlabs.xyz/subscriptions. If you are an AI agent or wish to subscribe programmatically rather than through the UI, see the Surge Subscription Guide.2. Install the SDKnpm install @switchboard-xyz/on-demand@3.10.6\n# or\nyarn add @switchboard-xyz/on-demand@3.10.63. Connect and Streamimport * as sb from \"@switchboard-xyz/on-demand\";\n\n// Initialize with keypair and connection (uses on-chain subscription)\nconst surge = new sb.Surge({ connection, keypair });\n// `connection` is a Solana RPC Connection from @solana/web3.js.\n\n// Discover available feeds\nconst availableFeeds = await surge.getSurgeFeeds();\nconsole.log(`${availableFeeds.length} feeds available`);\n\n// Subscribe to specific feeds\nawait surge.connectAndSubscribe([\n { symbol: 'BTC/USD' },\n { symbol: 'ETH/USD' },\n { symbol: 'SOL/USD' }\n]);\n\n// Handle price updates\nsurge.on('signedPriceUpdate', (response: sb.SurgeUpdate) => {\n const metrics = response.getLatencyMetrics();\n if (metrics.isHeartbeat) return;\n\n const prices = response.getFormattedPrices();\n metrics.perFeedMetrics.forEach((feed) => {\n console.log(`${feed.symbol}: ${prices[feed.feed_hash]}`);\n });\n});Pricing & LimitsPlanPriceQuote IntervalMax FeedsMax ConnectionsPlugFree10s21Pro~$3,000/mo450ms10010Enterprise~$7,500/mo0ms30015Subscriptions are paid in SWTCH tokens. For custom limits or dedicated support, contact sales@switchboard.xyz.Primary Use CasesPerpetual ExchangesSurge is the perfect oracle solution for perpetual trading platforms:surge.on('signedPriceUpdate', async (response: sb.SurgeUpdate) => {\n const metrics = response.getLatencyMetrics();\n if (metrics.isHeartbeat) return;\n\n const prices = response.getFormattedPrices();\n\n for (const feed of metrics.perFeedMetrics) {\n const price = parseFloat(prices[feed.feed_hash].replace(/[$,]/g, ''));\n const market = this.markets.get(feed.symbol);\n\n // Update mark price instantly\n market.oraclePrice = price;\n\n // Trigger liquidations if needed\n const underwaterPositions = await this.findUnderwaterPositions(market);\n for (const position of underwaterPositions) {\n if (this.isLiquidatable(position, market.oraclePrice)) {\n const crankIxs = response.toQuoteIx(queue.pubkey, keypair.publicKey);\n await this.liquidatePosition(position, crankIxs);\n }\n }\n }\n});Oracle-Based AMMsBuild the next generation of AMMs that use real-time oracle prices:class OracleAMM {\n private latestUpdate: sb.SurgeUpdate;\n\n constructor(private surge: sb.Surge) {\n surge.on('signedPriceUpdate', this.handlePriceUpdate.bind(this));\n }\n\n async handlePriceUpdate(response: sb.SurgeUpdate) {\n const metrics = response.getLatencyMetrics();\n if (metrics.isHeartbeat) return;\n\n this.latestUpdate = response;\n const prices = response.getFormattedPrices();\n\n for (const feed of metrics.perFeedMetrics) {\n const pair = this.pairs.get(feed.symbol);\n pair.oraclePrice = parseFloat(prices[feed.feed_hash].replace(/[$,]/g, ''));\n pair.lastUpdate = Date.now();\n }\n }\n\n async executeSwap(tokenIn: string, tokenOut: string, amountIn: number) {\n const pair = `${tokenIn}/${tokenOut}`;\n const latestPrice = this.pairs.get(pair).oraclePrice;\n const amountOut = amountIn * latestPrice * (1 - this.swapFee);\n\n // Convert to Oracle Quote for on-chain execution\n const crankIxs = this.latestUpdate.toQuoteIx(queue.pubkey, keypair.publicKey);\n\n return await this.program.methods\n .swap(amountIn, amountOut)\n .accounts({ amm: this.ammPda, queue: this.queuePubkey })\n .preInstructions(crankIxs)\n .rpc();\n }\n}High-Frequency Trading & Arbitragesurge.on('signedPriceUpdate', async (response: sb.SurgeUpdate) => {\n const metrics = response.getLatencyMetrics();\n if (metrics.isHeartbeat) return;\n\n const prices = response.getFormattedPrices();\n\n for (const feed of metrics.perFeedMetrics) {\n const oraclePrice = parseFloat(prices[feed.feed_hash].replace(/[$,]/g, ''));\n const dexPrice = await getDexPrice(feed.symbol);\n\n const spread = Math.abs(dexPrice - oraclePrice) / oraclePrice;\n if (spread > MIN_PROFIT_THRESHOLD) {\n const crankIxs = response.toQuoteIx(queue.pubkey, keypair.publicKey);\n await executeArbitrage(crankIxs, calculateOptimalSize(spread));\n }\n }\n});Liquidation Enginessurge.on('signedPriceUpdate', async (response: sb.SurgeUpdate) => {\n const metrics = response.getLatencyMetrics();\n if (metrics.isHeartbeat) return;\n\n const prices = response.getFormattedPrices();\n\n for (const feed of metrics.perFeedMetrics) {\n const price = parseFloat(prices[feed.feed_hash].replace(/[$,]/g, ''));\n const positions = await getPositionsByCollateral(feed.symbol);\n\n for (const position of positions) {\n const ltv = calculateLTV(position, price);\n if (ltv > LIQUIDATION_THRESHOLD) {\n const crankIxs = response.toQuoteIx(queue.pubkey, keypair.publicKey);\n await liquidatePosition(position, crankIxs);\n }\n }\n }\n});Technical SpecificationsProgram IDorac1eFjzWL5R3RbbdMV68K9H6TaCVVcL6LjvQQWAbzLatency BreakdownOracle processing: ~10msNetwork transmission: ~20-50msClient processing: ~10msTotal: <100msDiscovering Available FeedsUse the getSurgeFeeds() method to see all available trading pairs:const surge = new sb.Surge({ connection, keypair });\n// `connection` is a Solana RPC Connection from @solana/web3.js.\nconst feeds = await surge.getSurgeFeeds();\n\nfeeds.forEach(feed => {\n console.log(`${feed.symbol}`);\n});Supported AssetsAll major cryptocurrency pairsMultiple exchange sources availableNew pairs added regularlyCustom feeds available on requestNote: Surge does not support custom feeds created with the feed builder.FAQHow is Surge different from traditional oracles?Surge streams data directly to your application via WebSocket, bypassing the blockchain entirely for reads. This eliminates gas costs and reduces latency from seconds to milliseconds.Can I use Surge data on-chain?Yes! Surge updates can be converted to Oracle Quote format for on-chain use: response.toQuoteIx(queue.pubkey, keypair.publicKey)What's the reliability?Surge operates with 99.9% uptime SLA, automatic failover, and global redundancy. Enterprise customers get dedicated infrastructure.How do I handle disconnections?The SDK includes automatic reconnection logic with exponential backoff. Your application will seamlessly recover from network interruptions.Next StepsSurge Tutorial - Step-by-step implementation guideCrossbar Gateway - Stream prices to your frontendSurge Gateway Protocol - Advanced HTTP + WebSocket protocolExplore code examplesJoin our DiscordPreviousAuthority-Updated FeedsNextSurge TutorialLast updated 2 months ago","tokens":2278,"squid":"spider-08","role":"Oracle Spider","at":1791340182661,"hash":"75ec4cdaaedf05d5a68611b1c9d3f341936f8245"}
{"url":"https://forum.arbitrum.foundation/t/welcome-to-discourse/7/1","domain":"forum.arbitrum.foundation","title":"Welcome to Discourse - General - Arbitrum","text":"The Arbitrum Foundation notified the Security Council on the need to perform a potential Emergency action. Following a review of the details and known risks, the Security Council decided to execute the upgrade and it was completed at 11:30 EST on 2nd October 2026.\nThis report provides an overview of the risks that required the Security Council Action:\n\nAdd a permissionless guard for the One-Step Proof of BoLD on Arbitrum One\n\nTemporarily pause activation of new Stylus contracts on Arbitrum One & Nova\n\nKey point: To date, known bugs for Stylus primarily impact chain liveness (e.g., denial of service attacks) and do not put any user funds at risk.\nWhy was this action taken\nLet’s take this opportunity to explain why action was taken on two separate issues concerning BoLD and Stylus.\nInstalling the guard for One-Step Proof of BoLD. Given the rise of AI-assisted attacks, we have implemented a precautionary approach that allows anyone to pause settlement of Arbitrum One on Ethereum if there are at least two conflicting answers that pass at the same level in which only one should be valid and pass. This is to halt a class of publicly verifiable and detectable attacks that exploit a bug in the one-step proof. If halted, Arbitrum One will continue to process as normal except that messages from Arbitrum One to Ethereum, such as withdrawals, that are not yet confirmed will have to wait. This provides time for the Security Council to deploy a fix for the bug and resume the rollup.\nPreventing activation of new Stylus contracts. AI-assisted tooling has led to an increasing number of sophisticated attacks on hand-crafted WASM programs that do not use the standard Stylus compiler toolchain. These programs are specifically designed to cause unexpected behaviors such as degrading the chain’s performance for all other users. To date, no attacks have been discovered that permits theft of user funds.\nNew ArbOS releases have patched several reported bugs and known attacks over the past few months, but out of an abundance of caution, we have decided to temporarily pause new activations of Stylus contracts. This was executed as an emergency action to prevent the deployment of new hand-crafted WASM programs that are not yet patched by the current version of ArbOS on the Arbitrum network.\nThe Arbitrum Foundation has informed the Security Council that they will work with the ArbitrumDAO to discuss next steps on the timeline and manner for enabling activation of new Stylus contracts. The Arbitrum community remains confident in the value of Stylus and want to preserve these use cases while taking preventative measures against Stylus-based attack vectors as AI-assisted attack tooling continues to evolve.\nImpact on builders and users\n\nNo new activations. New Stylus contracts cannot be activated during the pause including new versions of existing applications that require activation.\n\nExisting contracts are not paused. Already-active Stylus contracts continue to execute until expiration. This pause does not deactivate them.\n\nThe ArbOS 61 upgrade renewed all active contracts on Arbitrum One, so no currently active contract expires before August 20, 2027.\n\nRenewal via keepalive stays permissionless and is unaffected by the pause.\n\nReactivating an expired contract, or one that needs to be updated after a Stylus version change, is paused.\n\nUsing/calling any activated Stylus contract stays permissionless for all users and developers.\n\nNo impact on EVM. Solidity (EVM) contract deployment and execution are unaffected by this Security Council action.\n\nSecurity Council Actions\nThere are two actions bundled into a single payload:\n\nOne-Step Proof Guard. The L1UpgradeExecutor gives a new pause contract (PauseExecutor) the ability to pause and nothing else. The new pause contract grants the guard (OspSoundnessGuard) PAUSER_ROLE to use it. Anyone can show the guard two conflicting answers to the same step of an open challenge. If the one-step proof accepts both, the guard has the pause contract put Arbitrum One’s settlement to Ethereum on hold.\n\nStylus deactivation. The Security Council called ArbOwner.setWasmActivationGas(2^64 - 1) to raise the Stylus activation gas requirement on Arbitrum One and Nova. This makes activation prohibitively expensive and effectively disables new activations. This is a configuration change and does not require an ArbOS upgrade.\n\nThe Security Council signed the following transactions to update the configuration:\n\nEthereum: Ethereum Transaction Hash: 0x30732bb7d2... | Etherscan\nArbitrum One:\nArbitrum One Transaction Hash: 0x9eb3a4be3b... | Arbitrum One\nArbitrum Nova:\nArbitrum Nova transaction 0x79e0fed470dff7a22059b108e3f8f42eddd2b580a6771594060c4e7326c5f984 | Blockscout\n\nAn external audit was conducted for the OSP Guard contracts. No audit is required for the Stylus deactivation as it is only updating a single parameter in the ArbOS configuration.\n\n Welcome to Discourse \n\n General\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Oct 2022\n\n 1 / 42\n\n Oct 2022\n\n Mar 22\n\n post by system on Oct 4, 2022\n\n system\n\n Welcome to the Forum!\nThis forum is dedicated to discussions and exchange of ideas related to governance.\nPlease read the following guidelines carefully to ensure a productive and respectful community.\nStay on topic: This forum is dedicated to discussions related to governance only. Please refrain from discussing unrelated topics. Off-topic or irrelevant posts may be removed by the moderators.\nBe respectful: Respect other forum members, their opinions, and their rights to express themselves. Do not use offensive or derogatory language, personal attacks, or hate speech.\nKeep it constructive: We encourage healthy and constructive debates that lead to learning and growth. However, we do not tolerate unproductive or malicious behavior, such as trolling or spamming. Spamming or repeated attempts to promote a product or service will result in removal from the forum\nProvide evidence: Back up your claims and arguments with reliable sources and evidence. Unsupported opinions or rumors are not allowed.\nStay legal: Do not engage in activities that are illegal or violate the rights of others, including intellectual property rights.\nProtect your privacy: Do not share personal information about yourself or others, including email addresses, phone numbers, or social media handles.\nFollow the rules: Abide by the rules and guidelines set forth by the forum moderators. Failure to do so may result in disciplinary action, including temporary or permanent suspension from the forum.\nModeration: The forum moderators reserve the right to remove any posts or comments that violate these guidelines or are deemed inappropriate. Repeat offenders may be banned from the forum.\nRemember, the purpose of this forum is to foster productive and respectful discussions related to governance. We encourage everyone to contribute their ideas and perspectives, and to learn from each other.\n\n AIP-1: Arbitrum Improvement Proposal Framework\n\n 2\n\n 2\n\n 5 months later\n\n post by eric on Mar 16, 2023\n\n eric\n\n Overall, the Arbitrum Foundation is committed to supporting the growth and success of the Arbitrum ecosystem, and welcomes proposals and ideas from the community.\n\n post by DieWithHonor on Mar 17, 2023\n\n post by DrMath.eth on Mar 24, 2023\n\n post by toph on Mar 28, 2023\n\n post by asgharsata on Mar 31, 2023\n\n post by Rhino on Apr 1, 2023\n\n post by Sparky-Faker on Apr 3, 2023\n\n post by Castun on Apr 5, 2023\n\n post by mrboard on Apr 5, 2023\n\n post by ha12vns on Apr 9, 2023\n\n post by Sonu8521 on Apr 10, 2023\n\n 8 days later\n\n post by Archetype on Apr 19, 2023\n\n post by DonXcraft on Apr 22, 2023\n\n post by Castun on Apr 30, 2023\n\n post by Musttyy on May 5, 2023\n\n 12 days later\n\n post by jchip300 on May 18, 2023\n\n 22 days later\n\n post by Kaushik on Jun 10, 2023\n\n post by Sutiyono21 on Jun 11, 2023\n\n post by Abuchtela on Jun 19, 2023\n\n Load more posts below","tokens":1989,"squid":"spider-07","role":"Council Spider","at":1791340190859,"hash":"80ccd20dae7ea55c6b454fb72a0b3d67177aa442"}
{"url":"https://docs.phantom.com/sdks/react-sdk/connect","domain":"docs.phantom.com","title":"Connect - Phantom developer documentation","text":"The React SDK follows a clear connection pattern using hooks for wallet connection and chain-specific operations.\nLearn about Phantom Connect: For details about authentication flows, login, account selection, and session management, see the Phantom Connect guide.\n​Connection flow\n\nProvider setup: Wrap your app with PhantomProvider and specify enabled providers.\nConnection: Use useConnect() or useModal() to establish wallet connection.\nChain operations: Use chain-specific hooks (useSolana(), useEthereum()) for transactions and signing.\n\nimport { useConnect, useSolana, useEthereum } from \"@phantom/react-sdk\";\n\nfunction WalletExample() {\n const { connect } = useConnect();\n const { solana } = useSolana();\n const { ethereum } = useEthereum();\n\n // 1. Connect first - specify which provider to use\n const handleConnect = async () => {\n await connect({ provider: \"google\" }); // or \"apple\", \"injected\"\n };\n\n // 2. Then use chain-specific operations\n const sendSolanaTransaction = async () => {\n const result = await solana.signAndSendTransaction(transaction);\n };\n\n const sendEthereumTransaction = async () => {\n const result = await ethereum.sendTransaction(transaction);\n };\n}\n\n​Core connection hooks\n​useConnect hook\nConnect to wallet with an authentication provider:\nimport { useConnect } from \"@phantom/react-sdk\";\n\nfunction ConnectButton() {\n const { connect, isConnecting, error } = useConnect();\n\n const handleConnect = async () => {\n try {\n const { walletId, addresses } = await connect({ provider: \"google\" });\n console.log(\"Connected addresses:\", addresses);\n } catch (err) {\n console.error(\"Failed to connect:\", err);\n }\n };\n\n return (\n <button onClick={handleConnect} disabled={isConnecting}>\n {isConnecting ? \"Connecting...\" : \"Connect Wallet\"}\n </button>\n );\n}\n\n​Authentication providers\nThe connect() method accepts a provider parameter to specify how users should authenticate:\n// Connect with Google OAuth\nawait connect({ provider: \"google\" });\n\n// Connect with Apple OAuth\nawait connect({ provider: \"apple\" });\n\n// Connect directly to the injected Phantom extension\nawait connect({ provider: \"injected\" });\n\n​useIsExtensionInstalled hook\nThe \"injected\" provider directly connects to the user’s Phantom browser extension (not an embedded wallet). Use the useIsExtensionInstalled hook to check if the extension is installed:\nimport { useConnect, useIsExtensionInstalled } from \"@phantom/react-sdk\";\n\nfunction InjectedConnectButton() {\n const { connect, isConnecting } = useConnect();\n const { isInstalled, isLoading } = useIsExtensionInstalled();\n\n const handleInjectedConnect = async () => {\n if (isInstalled) {\n await connect({ provider: \"injected\" });\n }\n };\n\n if (isLoading) {\n return <div>Checking for Phantom extension...</div>;\n }\n\n if (!isInstalled) {\n return (\n <div>\n <p>Phantom extension not found.</p>\n <a href=\"https://phantom.app/download\" target=\"_blank\">\n Install Phantom\n </a>\n </div>\n );\n }\n\n return (\n <button onClick={handleInjectedConnect} disabled={isConnecting}>\n Connect to Phantom Extension\n </button>\n );\n}\n\nWhen to use injected provider:\n\nUser wants to use their existing extension wallet directly.\nNo embedded wallet creation needed.\nDirect access to extension accounts and balances.\n\nAccount change detection: When using the injected provider, the SDK automatically detects when users switch accounts in their wallet extension and updates the connection state accordingly. Your app will receive updated account information through the useAccounts() and usePhantom() hooks when account changes occur.\n​Core account hooks\n​useAccounts hook\nGet connected wallet addresses:\nimport { useAccounts } from \"@phantom/react-sdk\";\n\nfunction WalletAddresses() {\n const addresses = useAccounts();\n\n if (!addresses) {\n return <div>Not connected</div>;\n }\n\n return (\n <div>\n {addresses.map((addr, index) => (\n <div key={index}>\n <strong>{addr.addressType}:</strong> {addr.address}\n </div>\n ))}\n </div>\n );\n}\n\n​useDisconnect hook\nDisconnect from a wallet:\nimport { useDisconnect } from \"@phantom/react-sdk\";\n\nfunction DisconnectButton() {\n const { disconnect, isDisconnecting } = useDisconnect();\n\n return (\n <button onClick={disconnect} disabled={isDisconnecting}>\n {isDisconnecting ? \"Disconnecting...\" : \"Disconnect\"}\n </button>\n );\n}\n\n​Using the Connect modal (recommended)\nThe SDK includes a built-in connection modal that provides a user-friendly interface for connecting to Phantom. Use the useModal() hook to control it:\nimport { PhantomProvider, useModal, darkTheme, usePhantom, AddressType } from \"@phantom/react-sdk\";\n\nfunction App() {\n return (\n <PhantomProvider\n config={{\n providers: [\"google\", \"apple\", \"injected\"],\n appId: \"your-app-id\",\n addressTypes: [AddressType.solana, AddressType.ethereum],\n authOptions: {\n redirectUrl: \"https://yourapp.com/auth/callback\", // Required for OAuth providers\n },\n }}\n theme={darkTheme} // Optional: darkTheme or lightTheme\n appIcon=\"https://your-app.com/icon.png\"\n appName=\"Your App Name\"\n >\n <YourApp />\n </PhantomProvider>\n );\n}\n\nfunction ConnectButton() {\n const { open } = useModal();\n const { isConnected } = usePhantom();\n\n if (isConnected) {\n return <div>Connected!</div>;\n }\n\n return <button onClick={open}>Connect Wallet</button>;\n}\n\nModal features:\n\nMultiple sign-in options: Google, Apple, browser extension\nBuilt-in error handling and loading states\nWorks across devices and environments\nHandles the full connection flow and returns a ready-to-use wallet session\nPresented as a bottom sheet optimized for mobile interaction\n\n​Using ConnectBox for auth callbacks\nThe ConnectBox component provides an inline, embedded connection experience that’s perfect for auth callback pages. Unlike the modal, it renders directly in your page flow and automatically handles all OAuth callback states.\n\n​Setting up an auth callback page\nWhen using OAuth providers (Google, Apple), users are redirected to your callback URL after authentication. Use ConnectBox on this page to handle the callback flow:\n// pages/auth/callback.tsx or app/auth/callback/page.tsx\nimport { PhantomProvider, ConnectBox, darkTheme } from \"@phantom/react-sdk\";\nimport { AddressType } from \"@phantom/browser-sdk\";\n\nfunction AuthCallbackPage() {\n return (\n <PhantomProvider\n config={{\n providers: [\"google\", \"apple\", \"injected\"],\n appId: \"your-app-id\",\n addressTypes: [AddressType.solana, AddressType.ethereum],\n authOptions: {\n redirectUrl: \"https://yourapp.com/auth/callback\",\n },\n }}\n theme={darkTheme}\n appIcon=\"https://your-app.com/icon.png\"\n appName=\"Your App Name\"\n >\n <div className=\"flex items-center justify-center min-h-screen\">\n <ConnectBox />\n </div>\n </PhantomProvider>\n );\n}\n\n​ConnectBox props\nPropertyTypeDefaultDescriptionmaxWidthstring | number\"350px\"Maximum width of the boxtransparentbooleanfalseRemoves background, border, and shadowappIconstring—URL to your app iconappNamestring—Your app name\n​Usage examples\nimport { ConnectBox } from \"@phantom/react-sdk\";\n\n// Default embedded box\n<ConnectBox />\n\n// Custom width\n<ConnectBox maxWidth=\"500px\" />\n\n// Transparent (blends with your page background)\n<ConnectBox transparent />\n\n// Override app icon and name for this instance\n<ConnectBox \n appIcon=\"https://your-app.com/custom-icon.png\"\n appName=\"Custom App Name\"\n/>\n\n​ConnectBox vs modal\nFeatureConnectBoxModalRenderingInline in page flowFloating overlayClose buttonNoYesAuth callback handlingAutomaticManualUse caseAuth callback pages, embedded authOn-demand connectionBackgroundCustomizable/transparentOverlay backdrop\nBest practice: Use ConnectBox on your OAuth callback page (/auth/callback) to automatically handle the authentication completion flow. The component shows loading states during token exchange and displays any errors clearly.\n​Configuration options\nImportant notes about redirectUrl:\n\nMust be an existing page/route in your application.\nMust be whitelisted in your Phantom Portal app configuration.\nThis is where users will be redirected after completing OAuth authentication.\nRequired for the google and apple providers.\nNot required for the injected provider.\n\n​Handling connection errors\nWhen a connection fails, the connect() promise rejects with an error.\nimport { useConnect } from \"@phantom/react-sdk\";\n\nfunction ConnectButton() {\n const { connect, isConnecting, error } = useConnect();\n\n const handleConnect = async () => {\n try {\n const { walletId, addresses } = await connect({ provider: \"google\" });\n // Connection successful\n console.log(\"Connected addresses:\", addresses);\n } catch (err) {\n // Connection failed (user cancelled, network error, etc)\n console.error(\"Failed to connect:\", err);\n }\n };\n\n return (\n <button onClick={handleConnect} disabled={isConnecting}>\n {isConnecting ? \"Connecting...\" : \"Connect Wallet\"}\n </button>\n );\n}\nWas this page helpful?","tokens":2193,"squid":"spider-10","role":"Tooling Spider","at":1791340197138,"hash":"1441d60a826a9364f723ff4165af184cdc4f7e7f"}
{"url":"https://forum.arbitrum.foundation/t/aip-1-arbitrum-improvement-proposal-framework/30/109","domain":"forum.arbitrum.foundation","title":"AIP-1: Arbitrum Improvement Proposal Framework - Archive / Archived Proposals - Arbitrum","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Mar 2023\n\n 40 / 110\n\n Apr 2023\n\n Apr 2023\n\n Load more posts above\n\n post by John_P2P.org on Apr 1, 2023\n\n John_P2P.org\n\n As it stands we believe that this proposal should not pass. There have been serious concerns raised regarding the way the proposal was drafted and the seemingly pre-transfer of funds before the AIP approval raised by @BlockworksResearch.\nOverall there is a lack of transparency regarding the allocation of the funds especially given the sum. In this regard, we would like to highlight a previous proposal by LIDO.\nThis is our decision pending a sufficient explanation/amendment to the proposal.\nWe would like to highlight a few points of discussion:\n2. Special Grants\n\nThe rationale behind the ability of The Arbitrum Foundation to issue Special Grants is to avoid inundating governance with grant applications, while at the same time alleviating voter fatigue.\n\nIf we look at any governance board out there I’d argue that this ability will not prevent the board from being inundated with grant applications. At best it will prevent good applications from going through the process. Furthermore, the delegate system already works to combat voter fatigue. This is a flawed argument to justify such discretionary spending power.\n4. Security Council\nSome members have raised concerns about the creation of the initial council without due process. We do not share these concerns and understand the need for pragmatism in this case.\nSee @stonecoldpat reply for further clarification.\n\n post by neozaru on Apr 1, 2023\n\n neozaru\n\n I am quite shocked by the discrepancy of this forum and social networks opinion vs. the current snapshot results.\nI’ve been humbly watching this space for a while now and I am feeling like the “Arbitrum DAO” is falling into the same pitfalls as some “not-so DAO”. Even if such models have become the rule during the last bull run, it doesn’t mean it is good enough.\nSure, Arbitrum innovates beyond the scope of DAO, and DAO management is not in their original skillet, but there is so much missed opportunities to innovate and this proposal and the reactions demonstrates it.\nAfaik there are models and technical solutions that exist for:\n\nGiving some DAOs a legal status and an ability to indirectly influence real world decision.\nInnovating in the way decisions are voted, in a way that satisfies the most.\nVeto systems by independent on-chain courts, where a proposal doesn’t adhere with some values or the constitution, or where the solution of a proposal is disproportionate/rushed. Such solutions exist on-chain afaik.\n1 human = more vote voting systems.\nTransparency tools than expose on-chain activities humanly to everyone.\n\nAgain, none of this is directly the business or skillset of Arbitrum and OffchainLabs, but all of those are awesome opportunities to innovate with and would all happen on Arbitrum and L3s.\nI feel like the DAO should be thinking about those meta-concerns first - or explicitly decide that those are not concerns - before rushing on big proposals.\nA perfect example of this is the following: Who, one day, decided that 1 week was an OK window for any type of decision involving the project ? I mean, a few of the delegates may be taking well deserved holidays for a couple of weeks (more in non-US). What justifies this “1 week” thing ? Are we voting for our classroom representative or are we moving billions ?\nMaybe Arbitrum DAO should take the lead in taking a step back and start using common sense.\n(Personal opinion)\n\n post by stonecoldpat on Apr 1, 2023\n\n stonecoldpat\n\n Hi all,\n@smyyguy, @cp287, @neozaru, Your comments are getting to the heart of a chicken and egg problem associated with AIP-1.\nThe Foundation. smart contracts, and essentially all infrastructure needs to be established before the DAO is announced. For example, decisions around the security council, network fees, and the data availability committee, must be decided in order for the Arbitrum network to be safely transferred to the DAO. The DAO plays a critical role in governing the Foundation and has the authority to make changes to the Arbitrum network, Constitution, Security Council and the Directors. The community can propose further AIPs to rectify issues that arise.\nThe “Steps to Implement” section of AIP-1 highlights the ratification nature of this voting procedure and its goal is to resolve this chicken & egg problem.\nTo @smyyguy, in terms of smart contract implementation for the DAO-controlled treasury contract treasury, the initial Arbitrum Deployer sent the ARB tokens to the DAO-controlled treasury contract and to the Foundation. However, the 750m ARB tokens are accounted for as part of the DAO’s ~4.2bn because the DAO has governance authority over the Foundation.\n@cp287* As mentioned above. AIP-1 focuses on ratifying the system with an initial configuration and we hope you can appreciate that is a necessity before the Arbitrum network can be safely transferred to the DAO.\n@404DAO*, In regards to the forum discussion, we at the Foundation are all grateful for the comments to date on AIP-1. It demonstrates that the community and delegates are actively participating in the DAO process. It is also providing clarity on potential AIPs the DAO may want to propose in the future. Again, the Foundation will both be governed by the DAO and act as a Steward and help guide the DAO/community/delegates through the process for proposing/executing new proposals.\nJust like any part of the constitution, the Director Rejection clause can be changed by a DAO vote (subject to compliance with law) and the scope can be reduced/tailored to be more specific. Keep in mind, if that clause is used by the Directors, then it is a transparent action and will initiate discussion amongst all participants.\n\n post by Kronos on Apr 1, 2023\n\n Kronos\n\n The siphoning off of 750 million tokens from the DAO and wrapping that number into the proposal is straight up fraud and potential embezzlement. Do you really want to kick off the foundation with a potential court case from holders?\nThe solution here is very simple: we need a separate proposal with a variety of fund amounts and greater transparency on what funds will be used for. The fact of the matter is this is either a DAO or it’s not, as a holder I don’t want $ARB to have a reputation as the first L2 rug.\nSuggest immediate take down of this proposal and restructuring into part A that includes everything as is minus the foundation fund and part B that outlines a variety of options including foundation funding by year that can be cut off for non performance by the DAO.\n\n post by cp287 on Apr 1, 2023\n\n cp287\n\n stonecoldpat\n\n I don’t see a chicken and egg problem here.\nYou can simply write the general structure of the DAO and the decision-making structure in the first AIP without any problems, and then in the following AIP make decisions on filling these structures with people, select directors, make financial decisions and transfers, deploy contracts after the decisions made.\nCan you please tell me where the problem occurs with the approach that I wrote?\nI do not understand why the initial ratification should immediately contain the selected people in various structures, deployed contracts and transfer of money from one address/structure to another, and not describe the general structure of the DAO and the way decisions are made in it.\nAnd you again offer us to change something in future AIPs. We don’t need future AIPs, we can change that in this AIP.\nAlso as @enzo7 wrote, absolutely unnecessary and harmful combine several important proposals into one.\nThis is a bad practice, which is usually used in corrupt structures, for people to vote for one decision they need, and in parallel take another, which is most often harmful for them, but less harmful than the benefits of the first.\nSo corrupt management gets things that it wouldn’t get if it separate these proposals.\nA governance proposal must have one well defined goal!\n\n post by Arbitrum on Apr 1, 2023\n\n Arbitrum\n\n Hello @OilySirs , this post goes against the community guidelines Welcome to Discourse and will be removed. We will allow the comment if the language changes.\n\n post by augustov on Apr 1, 2023\n\n augustov\n\n Hello all,\nFirst, as an Abritrum holder, I can’t vote in this proposal. Why is that? and what else should do in order to be able to Vote,\nSecond, this seems like a rushed proposal that needs further clarification. If the DAO controls the 4.2B tokens, why 750m are in a different wallet already prior to the Vote finishing? And as @smyyguy points out, there is already a movement of the 50m from the 750m ARB tokens to different wallets. The details of this have not been discussed with the DAO prior to happening.\nThird, how many people are in the same situation that like me, can’t vote for this proposal?.\nOverall I think this proposal needs more consideration and thought. Too many things in one proposal that need further clarification and transparency. Not a good look for the Foundation in my opinion.\n\n post by purplepill3m on Apr 1, 2023\n\n purplepill3m\n\n Hi this is purplepill from @BlockworksResearch\nFollowing on from @smyyguy 's latest comment, we can see that 0xc2 has distributed 50.5M ARB to 3 “child wallets.” Notably, one of the transfers was of 40M ARB tokens to 0xcc as outlined in this transaction Arbitrum Transaction Hash (Txhash) Details | Arbiscan.\nIt looks like this address is highly possible to be Wintermute Trading. Further investigation on arbiscan shows that this address 0xcc has sent small amounts of ARB tokens to CEXs such as Gate, Bybit, and Kucoin and on Arkham shows that it has sent ARB to Wintermute deposit addresses on Binance, OKX, Kucoin, and Gate. We can speculate that these tokens were given to Wintermute to marketmake ARB on various exchanges. This is further corroborated by this tweet stating that the recipient is Wintermute Trading. https://twitter.com/lookonchain/status/1638844521235750912\nThe vote to fund the Administrative Budget Wallet as part of AIP-1 has not passed, yet it seems like the Arbitrum Foundation has already utilized a portion of the 750M that as stated “will be transferred to the Administrative Budget Wallet” with 40M tokens seemingly going to Wintermute already. Would these 40M ARB tokens count as being accounted for? And if AIP-1 does not pass, and none of the clauses including the steps to implement are ratified, does that mean all of the actions regarding the 750M ARB tokens will be reversed?\nWe would like further clarity on what occurred, as in its current state, it seems like the Arbitrum Foundation has chosen to pre-emptively utilize the Arbitrum Budget Wallet without the AIP-1 vote being passed. It would appear as if 40M ARB tokens have been taken from the DAO treasury and given to Wintermute to market-make without any approval from ArbitrumDAO.\n\n post by Soggybiscuit on Apr 1, 2023\n\n Soggybiscuit\n\n People voting yes for this . This is why the crypto space is seen as a joke. Oh well. I’ll get my popcorn ready.\n\n post by MilanUa on Apr 1, 2023\n\n MilanUa\n\n 1 billion dollars for grands and salary lol.\nAre u kidding us?\nEveryone Please Vote Against !!!\nSecurity council is ok, but other part should be clarify and discuss later\n\n post by enzo7 on Apr 1, 2023\n\n enzo7\n\n So the team has apparently already funded themselves with 750m ARB, before this vote, and those have been sent to Binance?\nWow. This whole thing looks like a big scam.\n\n post by Ceazor on Apr 1, 2023\n\n Ceazor\n\n There was ample feedback that the grant program as laid out here was not sufficient, yet the proposal still went to snapshot as is. …\n\n post by web3magnetic on Apr 1, 2023\n\n web3magnetic\n\n We will be voting “Against” this proposal for the following reasons:\n\nThere are significant issues raised by various members of the DAO, some of which have come to light only after the submission of this proposal for temperature check, and many of these issues have not yet been addressed in a conclusive manner. Considering the nature of some of the issues pointed out by other members of the DAO pertaining to transparency, it is pertinent that these issues are addressed in entirety, before a governance proposal is put up for either temperature check or formal voting. The fact that issues on transparency are coming to light even as the voting is underway runs counter-intuitive to the established standards of good governance.\n\nThere is far too much ambiguity on the terms of the various proposals put forth in this proposal. Some of the proposals have an alternate path to viability, as pointed out by other members of the DAO, not limited to setting up specific delegate councils for deciding grants instead of adopting a black-box approach citing voter fatigue. Implementing these decisions in a hurry without exploring the alternatives could result in irreparable damages to the Arbitrum DAO. The sensible approach here would be to discuss the alternate solutions proposed, and come to a decision based on the merits and demerits of such solutions, instead of rushing to pass this proposal in a hurried manner.\n\nThe AIP is categorized as “Constitutional” whereas some of the provisions sought in the AIP relate to requests for funding, which as per the The Constitution of the Arbitrum DAO would fall under “Non-Constitutional” category. This adds to the ambiguity and lack of due process in the AIP.\nThe Constitution of the Arbitrum DAO specifically caries the following provision:\n\nRecommended guideline: DAO members should vote against any AIP that is incorrectly labeled.\n\nWhile the Constitution carves out a provision for AIP-1, nevertheless having a funding proposal (“Non-Constitutional” in nature) within a “Constitutional” proposal still runs contrary to the provisions of the Constitution and creates more ambiguity.\nIn our view, the Arbitrum DAO can be better served by passing the funding provisions sought in AIP-1 through a separate proposal, where the merits of such funding proposal can be discussed as a standalone topic. This seems to be the intention of the Constitution in creating a distinction between “Constitutional AIPs” vs “Non-Constitutional AIPs”\n\nFor the foregoing reasons, in our view it would not be in the interest of the DAO to vote FOR this proposal as long as these issues and ambiguities remain unresolved.\n\n post by enzo7 on Apr 1, 2023\n\n enzo7\n\n cp287\n\nAlso as @enzo7 wrote, absolutely unnecessary and harmful combine several important proposals into one.\n\nThis is a bad practice, which is usually used in corrupt structures, for people to vote for one decision they need, and in parallel take another, which is most often harmful for them, but less harmful than the benefits of the first.\nSo corrupt management gets things that it wouldn’t get if it separate these proposals.\n\nAgreed completely, combining several proposals into one is a really bad practice. It reminds me of how US Congress passes laws, with 1500 pages of laws crammed into one bill that no one has the time to read. Its then left to unelected agencies to sift through it and come up with rules to fit their own agenda\nIm not sure if its intentional or just a poorly drafted proposal but lets please not try to emulate the US government here\n\n post by ChainLinkGod on Apr 1, 2023\n\n ChainLinkGod\n\n Hi all, glad to see this proposal kicking off the process of formally establishing the Arbitrum DAO. While I’m aligned with many of the items with this proposal, and support the creation and funding of the Arbitrum Foundation, I echo some of the same concerns that have been laid out in this thread.\nProposal Structure\nThe structure of this proposal reminds me of omnibus bills within the US where many different potentially non-contentious and contentious items are packaged together under a single vote. I don’t believe this is a process or precedent we want to establish. I’m aligned with @cp287 that it would be better to vote on the sub-items within this proposal separately so the opposition to one contentious sub-item doesn’t impact the passage of other non-contentious sub-items.\nI understand that in order for the DAO to take effective control over the Arbitrum network, some variation of all of the sub-items within this proposal are required to pass first, but I’m not clear on why this would necessitate a single proposal to vote on everything wholesale. My suggestion would be to split the five specifications within AIP-1 into their own proposals, before handing off control to the DAO, unless there’s a clear reason why this cannot be done.\nAdministrative Budget Wallet\nIn my opinion, the creation and funding of the Arbitrum Foundation is a logical route for the Arbitrum DAO to take, supporting the development of the Arbitrum ecosystem, allowing the creation of an effective grants program without voter apathy blockers, and the ability to efficiently execute on the desires of the DAO, all while providing the DAO oversight over who makes up the Foundation and by which rules it operates. It appears to address some key legal hurdles as well with DAO operations.\nThat said, there seems to be a general consensus that there’s too little insight into how 750M ARB was determined or the plans in regards to asset management and anticipated usage over time. While there is sufficient background on the entities proposed for the Security Council, there is no background provided on the proposed initial Foundation directors. Given the amount of capital involved with funding the Foundation, it would be beneficial to have a greater level of clarity here.\nRetroactive Voting\nAs noted by @BlockworksResearch, the 750M ARB has already been split into its own multi-sig wallet (confirmed to be the Administrative Budget Wallet) with 50.5M ARB having been sent into child-wallets, including ARB being sent CEXs. It’s not clear why the language in the original proposal is future-facing, when the Administrative Budget Wallet has already been funded with the proposed amount. It’s also not clear why a portion of the tokens proposed to be sent to Administrative Budget Wallet is already being actively used. Is the ARB that was sent to CEXs being used for market making purposes or Foundation diversification?\n\nThis seems a bit murky, because the proposal that establishes the DAO’s governance authority over the Foundation (AIP-1), hasn’t yet been approved. Is the intent for the DAO to retroactively approve the actions that have already taken place?\nIf AIP-1 or a sub-proposal focused on Administrative Budget Wallet doesn’t pass, what happens to the ARB in the Administrative Budget Wallet multi-sig? How will the ARB usage from the child-wallets be reconciled with such a vote result? These type of situations are why I’m generally opposed to retroactive votes.\nVoting Threshold\nAs mentioned in this thread, the 5M ARB minimum threshold for the creation of an on-chain proposal seems far too high, with only four delegates currently meeting this threshold. I have seen with ENS and other DAOs, that as people liquidate their airdrops over time to other market participants, the top delegators see their delegation amounts decrease. The new acquirers of governance tokens often don’t delegate. A high minimum threshold can lead to various issues, including centralization of delegation power to a few actors, which doesn’t seem ideal.\nFor the above reasons, I have voted no against AIP-1, though I am open to changing my mind based on new information as it arises.\n\n Proposal: AIP-1.1 - Lockup, Budget, Transparency\n\n post by olimpio on Apr 1, 2023\n\n olimpio\n\n Hello everyone\nA heated start to kickoff the Arbitrum DAO. I will present some ideas here to try and further incentivize the debate.\n750M ARB:\nAs pointed out by several team members, it appears that the 750M ARB tokens that the AIP-1 proposes to allocate to the Administrative Budget Wallet have already been moved, before the AIP-1 could have the chance to pass or fail.\nThe 750M ARB were sent to this wallet: $1.29 | Arbitrum (ARB) Token Tracker | Arbiscan\nAny further clarification on these transactions (and their timing) would be appreciated.\nSpecial Grants:\n750M ARB tokens (975,000,000 USD) allocated to issue grants “without undergoing a full on-chain AIP process” seems excessive. I would favour a progressive approach, where the 3,500,000 USD in formation costs are reimbursed to service providers, and a reasonable amount is allocated for Special Grants to the Foundation.\nI believe that additional information on what these grants could be and how transparency and accountability would be in place is important to be disclosed, if possible, beforehand, before the DAO can allocate ARB to fund them.\nI also would like to stress the importance of a (funded) Arbitrum Foundation that is able to operate, to a certain degree, autonomously, for the advancement of the Ecosystem.\nUnbundling AIP-1:\nIt is a good idea to separate AIP-1 into multiple, smaller AIPs. This will prevent progress from being delayed because of a disagreement with some parts but not the whole proposal.\nPassing through the community’s desire:\nLastly, I want to say that my votes will always express the community’s desire. I have received multiple requests and comments regarding AIP-1, and all of them were not in favour, at least on this current form and circumstances.\n\n post by sluicejuice1 on Apr 1, 2023\n\n sluicejuice1\n\n This entire week of market manipulation will be revisited in court discovery. Please don’t just outright delete this comment because that shows bad faith, in my opinion. This past week isn’t price discovery - it’s just showcasing collusion.\n\n post by sluicejuice1 on Apr 1, 2023\n\n sluicejuice1\n\n enzo7\n\n Has anyone been able to get Lemma LTD to talk to them? Coindesk and Cointelegraph apparently reached out to them but haven’t heard anything back in 24 hours. I think we really need a Lemma LTD input.\n\n post by Arbitrum on Apr 1, 2023\n\n Arbitrum\n\n Hi @sluicejuice1, we have not received any communication from Coindesk or Cointelegraph. Just reached out on Twitter saying that we are happy to have a conversation.\n\n post by sluicejuice1 on Apr 1, 2023\n\n sluicejuice1\n\n Hi - thank you for responding to me and for reaching out to the publications I mentioned, this is why I commented what I did, from the Coindesk article.\n\nbrave_QB1VYLDZKM938×388 43 KB\n\n Load more posts below","tokens":5609,"squid":"spider-07","role":"Council Spider","at":1791340201061,"hash":"bfcafe528c1b388839fbd612e9a542bc97ffc3fa"}
{"url":"https://forum.arbitrum.foundation/t/aip-1-arbitrum-improvement-proposal-framework/30/1","domain":"forum.arbitrum.foundation","title":"AIP-1: Arbitrum Improvement Proposal Framework - Archive / Archived Proposals - Arbitrum","text":"The Arbitrum Foundation notified the Security Council on the need to perform a potential Emergency action. Following a review of the details and known risks, the Security Council decided to execute the upgrade and it was completed at 11:30 EST on 2nd October 2026.\nThis report provides an overview of the risks that required the Security Council Action:\n\nAdd a permissionless guard for the One-Step Proof of BoLD on Arbitrum One\n\nTemporarily pause activation of new Stylus contracts on Arbitrum One & Nova\n\nKey point: To date, known bugs for Stylus primarily impact chain liveness (e.g., denial of service attacks) and do not put any user funds at risk.\nWhy was this action taken\nLet’s take this opportunity to explain why action was taken on two separate issues concerning BoLD and Stylus.\nInstalling the guard for One-Step Proof of BoLD. Given the rise of AI-assisted attacks, we have implemented a precautionary approach that allows anyone to pause settlement of Arbitrum One on Ethereum if there are at least two conflicting answers that pass at the same level in which only one should be valid and pass. This is to halt a class of publicly verifiable and detectable attacks that exploit a bug in the one-step proof. If halted, Arbitrum One will continue to process as normal except that messages from Arbitrum One to Ethereum, such as withdrawals, that are not yet confirmed will have to wait. This provides time for the Security Council to deploy a fix for the bug and resume the rollup.\nPreventing activation of new Stylus contracts. AI-assisted tooling has led to an increasing number of sophisticated attacks on hand-crafted WASM programs that do not use the standard Stylus compiler toolchain. These programs are specifically designed to cause unexpected behaviors such as degrading the chain’s performance for all other users. To date, no attacks have been discovered that permits theft of user funds.\nNew ArbOS releases have patched several reported bugs and known attacks over the past few months, but out of an abundance of caution, we have decided to temporarily pause new activations of Stylus contracts. This was executed as an emergency action to prevent the deployment of new hand-crafted WASM programs that are not yet patched by the current version of ArbOS on the Arbitrum network.\nThe Arbitrum Foundation has informed the Security Council that they will work with the ArbitrumDAO to discuss next steps on the timeline and manner for enabling activation of new Stylus contracts. The Arbitrum community remains confident in the value of Stylus and want to preserve these use cases while taking preventative measures against Stylus-based attack vectors as AI-assisted attack tooling continues to evolve.\nImpact on builders and users\n\nNo new activations. New Stylus contracts cannot be activated during the pause including new versions of existing applications that require activation.\n\nExisting contracts are not paused. Already-active Stylus contracts continue to execute until expiration. This pause does not deactivate them.\n\nThe ArbOS 61 upgrade renewed all active contracts on Arbitrum One, so no currently active contract expires before August 20, 2027.\n\nRenewal via keepalive stays permissionless and is unaffected by the pause.\n\nReactivating an expired contract, or one that needs to be updated after a Stylus version change, is paused.\n\nUsing/calling any activated Stylus contract stays permissionless for all users and developers.\n\nNo impact on EVM. Solidity (EVM) contract deployment and execution are unaffected by this Security Council action.\n\nSecurity Council Actions\nThere are two actions bundled into a single payload:\n\nOne-Step Proof Guard. The L1UpgradeExecutor gives a new pause contract (PauseExecutor) the ability to pause and nothing else. The new pause contract grants the guard (OspSoundnessGuard) PAUSER_ROLE to use it. Anyone can show the guard two conflicting answers to the same step of an open challenge. If the one-step proof accepts both, the guard has the pause contract put Arbitrum One’s settlement to Ethereum on hold.\n\nStylus deactivation. The Security Council called ArbOwner.setWasmActivationGas(2^64 - 1) to raise the Stylus activation gas requirement on Arbitrum One and Nova. This makes activation prohibitively expensive and effectively disables new activations. This is a configuration change and does not require an ArbOS upgrade.\n\nThe Security Council signed the following transactions to update the configuration:\n\nEthereum: Ethereum Transaction Hash: 0x30732bb7d2... | Etherscan\nArbitrum One:\nArbitrum One Transaction Hash: 0x9eb3a4be3b... | Arbitrum One\nArbitrum Nova:\nArbitrum Nova transaction 0x79e0fed470dff7a22059b108e3f8f42eddd2b580a6771594060c4e7326c5f984 | Blockscout\n\nAn external audit was conducted for the OSP Guard contracts. No audit is required for the Stylus deactivation as it is only updating a single parameter in the ArbOS configuration.\n\n AIP-1: Arbitrum Improvement Proposal Framework \n\n ArchiveArchived Proposals\n\n snapshot,failed\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Mar 2023\n\n 1 / 110\n\n Mar 2023\n\n Apr 2023\n\n post by Arbitrum on Mar 15, 2023\n\n Arbitrum\n\n UPDATE:\nAIP 1.1 : Proposal: AIP-1.1 - Lockup, Budget, Transparency\nAIP 1.2: Proposal: AIP-1.2 - Foundation and DAO Governance\n\nCategory: Constitutional - Process\nSubmitted by: Lemma Ltd\nAbstract\nThis document (“AIP-1”) proposes the structure of a decentralized autonomous organization called the ArbitrumDAO that would be governed by holders of $ARB, the decentralized token that will serve as the primary token for fostering, developing, authorizing and/or governing the ArbitrumDAO-approved chains (as defined in the ArbitrumDAO Constitution). The ArbitrumDAO Constitution, located at The Amended Constitution of the ArbitrumDAO | Arbitrum DAO - Governance docs is incorporated herein by reference.\nMotivation\nThe Arbitrum Foundation, a Cayman Islands foundation company, which will serve the ArbitrumDAO community and be governed by it, aims to foster the growth and development of the Arbitrum ecosystem.\nThe ArbitrumDAO will have the ability to submit Arbitrum Improvement Proposals (“AIPs”), vote on them and make them a reality through The Arbitrum Foundation.\nThe guiding values of The Arbitrum Foundation and ArbitrumDAO are described in Section 5 of the ArbitrumDAO Constitution and are incorporated herein.\nRationale\nThe Arbitrum Foundation serves the ArbitrumDAO by administering the wishes of the community and otherwise adhering to its guiding values. The Arbitrum Foundation and DAO governance are intended to serve as vehicles enabling impactful, transparent and fair decentralized governance by the broader Arbitrum community.\nThrough the submission of AIPs, the ArbitrumDAO will be able to collectively decide and effectuate changes ranging from core protocol technology to non-technical decisions that otherwise impact the community and $ARB tokenholders.\nSpecifications\nGovernance powers breakdown\n1. $ARB Tokenholders\n\n$ARB tokenholders, who make up the ArbitrumDAO, play the most critical role in the proper functioning of decentralized governance in the pursuit of a trustless, transparent and verifiable Arbitrum ecosystem. As Arbitrum is intended to be a public good, it is only right that governance over it should be governed by those for whom such public good is intended for.\n\n$ARB tokenholders have the ability to directly propose, vote on and effectuate on-chain AIPs with respect to the ArbitrumDAO-approved chains.\n\n2. Special Grants\n\nThe Arbitrum Foundation shall be permitted to issue grants out of the Administrative Budget Wallet without undergoing a full on-chain AIP process (such grants, “Special Grants”).\n\nThe rationale behind the ability of The Arbitrum Foundation to issue Special Grants is to avoid inundating governance with grant applications, while at the same time alleviating voter fatigue.\n\nThe Special Grants application process and criteria will be released at a later date by The Arbitrum Foundation.\n\n3. Directors\nAs a Cayman Islands foundation, The Arbitrum Foundation is required to have at least 1 director responsible for the management and operation of The Arbitrum Foundation, in particular approving and entering into contractual arrangements on behalf of The Arbitrum Foundation (i.e., the parties actually approving and signing agreements).|\nThe directors are responsible for ensuring that AIPs do not:\n\nCompromise their fiduciary duties owed to The Arbitrum Foundation;\nViolate The Arbitrum Foundation’s Amended & Restated Memorandum of Association or bylaws, the ArbitrumDAO Constitution, the AIP Process or any other laws or regulations of applicable jurisdictions (including but not limited to Cayman Islands laws); and\nCause The Arbitrum Foundation to be in breach or violation of any contracts, agreements or any other arrangements.\n\nThe initial directors of The Arbitrum Foundation are:\n\nCampbell Law,\nEdward Noyons and\nAni Banerjee\n\nThe ArbitrumDAO may remove or elect The Arbitrum Foundation’s directors or expand or reduce the number of directors at any time pursuant to a Non-Constitutional AIP\n4. Security Council\nThe Security Council is a committee of 12 members of a multi-sig wallet which has the ability to perform both Emergency and Non-Emergency Actions, which are further detailed in Section 3 of the ArbitrumDAO Constitution, which is incorporated herein by reference.\nThe initial Security Council members, split by cohort, are as follows:\ni. September Cohort\n\nMo Dong is the Co-Founder of Celer Network. Mo received a PhD from the University of Illinois Urbana-Champaign in computer science.\n0x526C0DA9970E7331d171f86AeD28FAFB5D8A49EF\nHarry Kalodner is Co-Founder and CTO at Offchain Labs, the developers behind Arbitrum. Harry started working on building Arbitrum while studying at Princeton University.\n0xf8e1492255d9428c2Fc20A98A1DeB1215C8ffEfd\nDiane Dai is the Co-Founder of DODO, a leading decentralized trading platform. Diane has extensive marketing experience in Defi space since 2017 and was named to Forbes Asia 30 under 30 in 2022.\n0x0E5011001cF9c89b0259BC3B050785067495eBf5\nCaleb Lau has been a software engineer at Etherscan since 2019. He works closely with L2 scaling teams to bring users the Etherscan experience on the explorer front.\n0x8688515028955734350067695939423222009623\nEd Felten is Co-Founder and Chief Scientist at Offchain Labs, the developers behind Arbitrum. Prior to this, Ed served as the Robert E. Kahn Professor of Computer Science and Public Affairs at Princeton University. Ed also served as the Deputy U.S. Chief Technology Officer from 2015-17.\n0x6e77068823f9D0fE98F80764c21Ec294e4d96AdB\nBryan Pellegrino is Co-Founder and CEO at LayerZero Labs, an omnichain interoperability protocol. Bryan is a multi-time founder/serial entrepreneur who has been active in crypto for more than 10 years.\n0x8e6247239CBeB3Eaf9d9a691D01A67e2A9Fea3C5\n\nii. March Cohort\n\nPatrick McNab Is a Co-founder of Mycelium who have been developing and deploying decentralized financial infrastructure since 2018. Mycelium (previously Tracer DAO) were one of the first protocols deployed on Arbitrum in 2021 and support the Arbitrum ecosystem through running validators and Chainlink nodes.\n0x566a07C3c932aE6AF74d77c29e5c30D8B1853710\nJustin Drake has been a researcher at the Ethereum Foundation since 2017. He focuses on Ethereum consensus layer upgrades.\n0x5280406912EB8Ec677Df66C326BE48f938DC2e44\nBartek Kiepuszewski has been a blockchain architect at MakerDAO since 2017. He also co-founded l2beat.com and TokenFlow Insights. Bartek holds a PhD in computer science from Queensland University of Technology.\n0x0275b3D54a5dDbf8205A75984796eFE8b7357Bae\nRachel Bousfield has been a software engineer at Offchain Labs since 2021. She is currently leading the development of Stylus.\n0x5A1FD562271aAC2Dadb51BAAb7760b949D9D81dF\nPatricio Worthalter has been working full time in the Ethereum space since 2015. In 2018 he founded POAP, a web3 native public good that mints digital collectibles for the preservation of memories.\n0xf6B6F07862A02C85628B3A9688beae07fEA9C863\nYoav Weiss is a security researcher at the Ethereum Foundation and has been building in the Ethereum space since 2017, working on account abstraction (ERC-4337), OpenGSN, L2 security, etc. Yoav brings over 25 years of experience and has developed security technologies used by industry leading companies.\n0x475816ca2a31D601B4e336f5c2418A67978aBf09\n\nCompensation:\nSecurity Council members are each paid $5,000 per month in $ARB tokens.\nSecurity Council Elections:\nSection 4 of the ArbitrumDAO Constitution describes the Security Council election process and is incorporated herein by reference.\n5. Data Availability Committee (Arbitrum Nova chain only)\nTransactions occurring on the Arbitrum Nova chain are settled on Ethereum mainnet, but, unlike transactions occurring on the Arbitrum One chain, the underlying transaction data batches are posted and stored by the members of the Data Availability Committee on a Data Availability Server (and not on Ethereum mainnet).\nThe initial members of the Data Availability Committee are authorized representatives of the following parties:\n\nReddit, Inc.\nConsenSys Software Inc.\nQuikNode, Inc.\nP2P Business Technologies\nGoogle Cloud ( Google LLC.)\nOffchain Labs, Inc.\nOpensea Innovation Labs Private Limited\n\nData Availability Committee members can be appointed and removed at any time pursuant to a Constitutional AIP approved by the ArbitrumDAO. In the event that a Data Availability Committee member is removed (and not otherwise replaced) pursuant to a Constitutional AIP approved by the ArbitrumDAO, or in the event that a Data Availability Committee member resigns without a replacement, the Security Council may execute an emergency action (9-of-12 approval required) to appoint a replacement for such removed or resigned Data Availability Committee member.\nAIP Guidelines and Process Breakdown\nSection 2 of the ArbitrumDAO Constitution lays out the AIP process and voting procedures, as well as the various categories of AIPs, and is incorporated herein.\nArbitrum Voting Protocol Procedure\n\nTally.xyz will act as the initial on-chain voting platform for the ArbitrumDAO to submit and vote on AIPs\n\nTally will serve as a front-end user interface that allows DAO members to do several things, namely:\n\nCreate AIPs;\nView delegates and their voting share;\nRe-delegate votes to a different delegate;\nView current and past AIPs;\nVote on AIPs on-chain, interacting with the on-chain governance contracts via the Tally front-end; and\nView the status of AIP execution during all voting stages\n\nSteps to Implement\n\nRatification of formation of The Arbitrum Foundation and its Amended & Restated Memorandum of Association and bylaws linked in this AIP-1.\nRatification of the ArbitrumDAO Constitution\nRatification of Security Council and Data Availability Committee member appointments and respective powers\nRatification of the following allocations of the L2 basefee on the Arbitrum Nova chain: 8% of the basefee to the Data Availability Committee and 12% of the basefee to Arbitrum Nova validators\nRatification of the funding of the DAO Treasury (as defined in the ArbitrumDAO Constitution)\nApproval of the AIP process as described in this AIP-1\nCompleted setup of the Arbitrum Forum, Snapshot and Tally\nRatification of funding the Administrative Budget Wallet\nRatification of reimbursement of costs as illustrated in the Overall Cost sections below and disbursement of such reimbursements to applicable service providers\n\nTimeline\nSolution prepared and ready to be ratified and approved\nOverall Costs\nInitial Setup Costs of The Arbitrum Foundation and ArbitrumDAO\nTotal setup costs, including legal costs, DAO administration setup and registration fees to be reimbursed to service providers: $3.5 million (“Total Setup Costs”)\nDAO Treasury\nIn order to best provide the ArbitrumDAO with the ability to effectively govern and foster the development of Governed Chains (as defined in the ArbitrumDAO Constitution), 3,527,046,079 $ARB tokens have been transferred to the DAO Treasury. The ArbitrumDAO will have direct on-chain governance powers over the DAO Treasury in accordance with the AIP process as delineated in the ArbitrumDAO Constitution.\nThe Arbitrum Foundation Administrative Budget Wallet\nFor the sake of operational and administrative efficiency, a separate account controlled by The Arbitrum Foundation will be created (“Administrative Budget Wallet”). 750 million $ARB tokens will be transferred to the Administrative Budget Wallet for purposes of making Special Grants, reimbursing applicable service providers for the Total Setup Costs and covering ongoing administrative and operational costs of The Arbitrum Foundation. Further funding of the Administrative Budget Wallet shall require approval of an AIP by the ArbitrumDAO pursuant to the AIP process.\nThe Arbitrum Foundation Memorandum of Association\nThe Arbitrum Foundation Bylaws\n\n [RFC-2] Delegate Incentive System for ArbitrumDAO\n\n 8\n\n 6\n\n 5\n\n 4\n\n 4\n\n read \n\n 57\n min\n\n post by 0xMonke on Mar 16, 2023\n\n 0xMonke\n\n Looks like a solid plan for setting up the DAO.\nA few questions though that could help clarify some specifics:\n\nIn the proposal, the ability for The Arbitrum Foundation to issue Special Grants without undergoing a full on-chain AIP process is mentioned. How will the community ensure that these Special Grants are transparent and follow the wishes of ARBI token holders?\n\nThe Security Council plays an essential role in emergency actions. Can you provide more context on the types of situations that would warrant an emergency action and the process the Security Council would follow in such cases?\n\nIn the AIP process breakdown, Tally.xyz is mentioned as the initial on-chain voting platform. Are there any plans to review or potentially change this platform in the future, and what criteria would be considered when evaluating alternative platforms?\n\nOverall, a great start to decentralising Arbitrum. Looking forward to hearing more about the team’s thoughts on these points.\n\n0xMonke\nZigZag Labs\n\n post by MadAl on Mar 16, 2023\n\n MadAl\n\n In my opinion, an excellent and at the same time unique project. With the advent of each new crypto project, there is hope for a developed future. Thanks)\n\n post by Boiler on Mar 20, 2023\n\n Boiler\n\n 0xMonke\n\n I can’t speak to how they have it set up but it is fairly standard I believe to do this. It allows for a quicker turnaround on projects that have promise. A lot of the times the DAO will approve the funds that the special “team” is able to spend without approval on every transaction.\nIt’s really important for a DAO to allow the people that are most qualified to make decisions be given the power to do so within their domain. DAOs can get really bogged down and not do anything otherwise. I’m a big advocate of sub DAOs, which can be funded by the main DAO but get autonomy in their day to day decisions.\n\n post by BristolBlockchain on Mar 22, 2023\n\n BristolBlockchain\n\n 0xMonke\n\n The proposal indeed serves as a solid foundation for the Arbitrum ecosystem, and it is great to see the community engaged and asking important questions. We share the same concerns as 0xMonke from ZigZag Labs and would like to emphasize the following points:\n\nEnsuring transparency and alignment with ARBI token holders’ wishes for Special Grants issued by The Arbitrum Foundation is crucial. We understand that not going through the formal process is less time-consuming, but how will you ensure proper allocation of funds? Will there be a maximum limit per grant, or will it be determined later? It would be helpful to have more information on the mechanisms that will be put in place to guarantee transparency and community involvement in the decision-making process.\n\nThe role of the Security Council in emergency actions is essential. We agree that emergency actions should only be used when there is a real emergency. How will you ensure transparency to the community in these situations? Please provide more context on the types of situations warranting emergency actions and the procedures the Security Council would follow to maintain transparency.\n\nTally.xyz is currently the initial on-chain voting platform for the AIP process. We are interested in knowing if there are plans to review or potentially change this platform in the future. We believe that if the community wants to explore alternative platforms instead of Tally, it could be done through a governance vote, allowing the community to decide on the most suitable option.\n\nWe believe that addressing these questions will strengthen the proposal and provide the necessary transparency and confidence for the community. We look forward to hearing more about the team’s thoughts on these matters.\nBest regards,\nBristol Blockchain\n\n Pinned on Mar 23, 2023\n\n post by yabirgb on Mar 24, 2023\n\n yabirgb\n\n Thanks! The proposal looks indeed good for a constitutional process. Also I loved that people from different places came to start the DAO with a vision on web3.\nI would like to ask for clarification on how the budget was estimated since 750 million ARB is a big amount and is not clear at least to me why this amount was chosen.\nSince this money will be used to “and covering ongoing administrative and operational costs of The Arbitrum Foundation” for how long is estimated that this amount would cover the operational costs?\nTo enrich this proposal I would love to see a little more detail on how the budget will be used and how it was estimated.\nAnother question is if there exists a cap on how much is the amount assigned to “Special Grants”.\nFinally regarding the administrative budget wallet how is the ARB token expected to be used? Will be sells managed by the team and have liquidity in stable coins or will be everything hold in ARB until it is needed?\nThank you\n\n post by kropla on Mar 25, 2023\n\n kropla\n\n MadAl\n\n We need freedom. We are smart enough to update the system making it more efficient and corruption free.\n\n post by Bhau on Mar 26, 2023\n\n Bhau\n\n Much well-thought out planning has brought us here, presumably with Trust minimization on Layer Zero. With this assumption in mind, we should move to ratify and begin operations.\nThe Merge was impressively executed without pushing pause, so let’s follow suit.\n\n post by limes on Mar 27, 2023\n\n limes\n\nI think it’s important to set a proposal threshold of 10,000 $ARB in order to prevent frivolous proposals from popping up on Tally as the current threshold is .01\nimage1660×964 146 KB\nTwo spam proposals have started already with more likely coming soon if it doesn’t change.\n\n post by yabirgb on Mar 28, 2023\n\n yabirgb\n\n The voting in snapshot seems to be open Snapshot.\nIs there any other channel where this was posted? I believe it would be useful if the voting was announced also in the AIP threads\n\n post by DisruptionJoe on Mar 28, 2023\n\n DisruptionJoe\n\n Are we voting on whether or not to send the foundation 750 million $ARB?\nOr is this just a vote about the process?\n\nIs there a reason this amount needs to be tied into this proposal? It seems like $750 million is a lot when there aren’t criteria yet. This industry is about creating systems where we don’t need to trust the operator. I would vote to fully reimburse the $3.5 million in setup costs to the foundation, but sending $750 million without criteria… it doesn’t seem as though this is necessary to bundle in with the passing of the first AIP.\nWithout clear criteria, I’d even approve the 750 million tokens, but funded through a vesting contract that releases them proportionally over the course of 10-20 years and the DAO has the ability to cut off the funding if they are not pleased with the foundation’s execution.\n\nThis is spot on. We need to set minimum thresholds to avoid spam and voter fatigue.\nI do see that in section 2 of the Arbitrum Constitution it does indicate thresholds which don’t seem to have been properly set on Snapshot and Tally yet.\nImage 2023-03-28 at 11.57.13 AM1728×1656 273 KB\nI think it is important for Tally to remain at a level where 10-25 people have enough delegations to be able to post on-chain actions. At Gitcoin, we had it at a level where only 3-4 people could post to Tally. This caused problems and it is now widely agreed that we should have loosened that setting.\n\n post by limes on Mar 28, 2023\n\n limes\n\nAt 5,000,000 $ARB it looks like only 4 delegates would have the capability to propose an AIP. A threshold of 1,000,000 $ARB would put us at 27 delegates. As more $ARB trades hands I’d expect the number of delegates that hit this threshold to come down. Using $ENS as an example which had a similar distribution mechanic, we can see delegation fall over time.\nimage1191×510 40.2 KB\nSeems like 1,000,000 $ARB might be suitable\n\n post by yabirgb on Mar 30, 2023\n\n yabirgb\n\n @Arbitrum Any feedback that you can provide us about the questions?\n\n post by Arb_fun on Mar 30, 2023\n\n Arb_fun\n\n DisruptionJoe\n\n Nice, will be good. Good job\n\n post by Matt_StableLab on Mar 30, 2023\n\n Matt_StableLab\n\n Thank you for this detailed outline! We at StableLab have a few questions and comments\n\nWe agree the @limes and @DisruptionJoe proposal threshold should be reduced from 5,000,000 ARB to 1,000,000. Only 4 delegates currently meet the 5M threshold and this could lead to delays or difficulties in getting proposals posted to Tally. 1M ARB seems much more suitable especially since many current delegates are beginning to lose voting power as ARB is being sold and undelegated. A 1M threshold would allow around 25 delegates to post proposals which is a much more suitable number and make it easier for proposals to be seamlessly posted to tally.\n\nWhat qualifies as a “special grant” and where will these grants be announced and tracked? It is important for this process to be transparent and for the grant issuers and receivers to be held accountable.\n\nThe constitution suggests snapshot polls are supposed to be posted at the same time as the proposal is posted on the forum. This does not seem wise as the community should be given time to comment on the proposal and suggest changes before the temp check is voted on. We recommend the proposal be required to be posted on the forum for a few days before it can move to snapshot for a temp check.\n\n1230×526 81.2 KB\n\nThis proposal is currently on Snapshot but has very few votes currently. Will there be an announcement somewhere when proposals move to snapshot? Additionally, what is this proposal asking? Is it asking whether or not the DAO should accept the AIP framework? What would happen if this proposal was voted down?\n\nThis proposal estimates that the startup cost of the DAO will be $3.5 Million. Will this come out of the 3,527,046,079 $ARB put into the treasury or this will come out of the Arbitrum Foundation Administrative Budget Wallet?\n\n750 Million $ARB for the Arbitrum Foundation Administrative Budget Wallet and only 3.5 million $ARB for the treasury seems to be pretty imbalanced. What is the thought process behind this? Will additional funds be transferred from the Arbitrum Foundation Administrative Budget Wallet to the treasury?\n\nWe are super excited about the future of Arbitrum’s governance and proud to be a part of it!\n\n post by Tonic on Mar 30, 2023\n\n Tonic\n\n yabirgb\n\n how to vote for the spanshot?\n\n post by limes on Mar 30, 2023\n\n limes\n\nThis idea seems to align incentives well. It would be nice to see:\n\nWhat method was used to establish this number?\nHow much liquid $ARB is needed to retroactively give Special Grants to service providers today, locking the rest to be released via a stream.\nWhat proposed timeline would the Arbitrum Foundation be able to effectively allocate funds?\n\n post by Westie on Mar 30, 2023\n\n Westie\n\n While it is certainly necessary to set up some official guidelines around the treasury and security council, there are a few issues I have with this proposal:\n\nFirst off, 750M ARB (around $1B) going to one entity without any clarification how the allocation would be broken down for the different functions mentioned is not enough clarity. I would reccomend a new proposal that goes into more detail into how this Administrative Budget Wallet would used, and may even suggest that rather than giving a lump sum all at once that there a predefined amount of ARB needed for one year of operations and Special Grants funding, which would be reassesed after a year. Giving three people complete control over how funds are allocated does not seem very secure as well.\nInstituting a Security Council without any election process is antithetical to the decentralized governance process. While having elections every 6 months does seem reasonable, there should be an election process for the initial council instead of them being appointed all at once by the foundation.\n\nArbitrum has a chance to kick things off on the right foot when it comes to transparency and decentralization, and I hope some changes can be made to ensure this.\n\n post by MattOnChain on Mar 30, 2023\n\n MattOnChain\n\n Hi there! Matt from Blockworks Research here.\nIf this proposal passes, the Administrative Budget Wallet will receive over $1 Billion in ARB. There are no details about who will control this wallet other than the following passage from the bylaws:\n\n(b) The Foundation Director(s) shall engage in any activity which, in their reasonable discretion, does not contradict the terms set forth in any AIP approved by Tokenholders, the ArbitrumDAO Constitution, these Bylaws, or the Foundation Articles, including but not limited to the following actions:\n(i) approve transactions from the Administrative Budget Wallet;\n\nI am confused why these 3 non-crypto native Cayman individuals have control over this $1B without any oversight from the DAO. I would like further clarity please surrounding who will control this wallet and what processes/oversight will there be in place for the distribution of funds.\n\n Load more posts below","tokens":7515,"squid":"spider-07","role":"Council Spider","at":1791340211208,"hash":"1cfe3b8d1872fdc304a521729d7e71047ca9c327"}
{"url":"https://forum.arbitrum.foundation/t/aip-1-arbitrum-improvement-proposal-framework/30/185","domain":"forum.arbitrum.foundation","title":"AIP-1: Arbitrum Improvement Proposal Framework - Archive / Archived Proposals - Arbitrum","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 8\n\n 6\n\n 5\n\n 4\n\n 4\n\n read \n\n 57\n min\n\n Mar 2023\n\n 110 / 110\n\n Apr 2023\n\n Apr 2023\n\n Load more posts above\n\n post by Zeb on Apr 2, 2023\n\n Zeb\n\n As a long term DAO participant, I would like to add my 2 cents. There has already been plenty of discussion around the ARB sold and the vote being meaningless, so I won’t go into that. There are two things within the AIP that as a DAOist I think are not the way to go about it.\n\n750M ARB in 1 vote, and as first action is way too much. Either a team does a premine and proclaims they know what is best, and the market will have to price it in / judge for itself, or a DAO slowly but steadily builds trust with DAOplomats.\nSince this Foundation is claiming to give out grants and fund overhead costs, it should have come up with a clear budget and a trial period with a way lower amount. Let’s say, a couple 100k perhaps. The Balancer Grants subDAO of which I was a founding member shows how a small initiative can build trust and grow to a larger entity.\n\nco-founders of Offchain Labs are part of the Security Council (aka Admin Key multi-sig) and will get paid $5000 per month for this role. Didn’t these founders get a huge pre-mine allocation already? Why do they need to get a stipend for being on an admin key position for a project they created, got a premine of and are working on and got VC funding for to work on anyway?\n\nThese kind of brazen moves are not the way of a DAO. Arb team, you can do better.\n\n post by sluicejuice1 on Apr 2, 2023\n\n sluicejuice1\n\n The March Cohort getting paid $5,000/month each in ARB tokens is fair I think given they are all doxxed and have been known and trusted in the crypto community for years, each of them. I trust these people because their work records speak for themselves I believe. You can click the links of each of them and find their socials and the work they’ve done.\n\nimage871×752 112 KB\n\n post by 01124816 on Apr 2, 2023\n\n 01124816\n\n Why shouldn’t we delegate to a third party that does not own tokens or build any projects on Arbitrum? Because:\n\nIf Arbitrum develops strongly, we - holders and delegates - also benefit.\nIf Arbitrum unfortunately faces any incidents, we - holders suffer the most financially, but the delegates do not. Does that sound fair? You should think about it yourself!\n\nI delegate my voting power to CamelotDAO because they are a native project on Arbitrum and, of course, they also own ARB. I trust that all decisions made by CamelotDAO are for the purpose of developing the ecosystem because only when Arbitrum develops strongly will they also develop strongly.\nRegarding AIP-1, I vote “FOR” because it is necessary for the ecosystem, and I believe that the creators of ARB understand the benefits of ARB better than third parties who have no obligations towards its benefits.\nAnd surely, i am an ARB holder and also an active member of the ARB ecosystem.\n\n post by cattin on Apr 3, 2023\n\n cattin\n\n SEEDLatam Statement\nHey everyone,\n@cattin here, representing SEEDLatam and L2 en Español, after discussing this AIP with our community during our first governance call carried out in our Discord, we decided to vote AGAINST AIP-1, for the reasons stated below.\nRationale\nAs a self-sustaining organization that encompasses other communities, each with different interests, we understand how difficult it is to have clear communication in these scenarios where there is a lot to do (airdrop, forming the DAO, maintaining decentralization, etc.), nobody said that running and forming a DAO was an easy task.\nTherefore, we want to thank @stonecoldpat for his post “Clarity around the ratification of AIP-1” which brought more clarity to what is happening in ArbitrumDAO to our community.\nHowever, this does not remove the great dissatisfaction of the community that was expressed during our governance call regarding this situation. Additionally, we believe that AIP-1 encompasses several proposals together which should be voted on and dealt with separately, as it has already been recognized in the latest statement made by Arbitrum on twitter.\nWhile we understand that this is not now a “proposal” but rather a “ratification” of the initial DAO configuration, we will express the will of the Latam community on each point.\nOn Special Grants\nWe believe that this point is very vaguely explained, although it is clarified that the Special Grants process and criteria will be published in the future, we do not believe that voting for this point now is correct.\nEstablishing the scope of these Special Grants and the processes we believe is crucial, as these are funds intended for organizations/institutions or individuals who have somehow helped or supported the Arbitrum ecosystem. We believe that transparency in the processes and that those funds truly have an impact that benefits the Arbitrum ecosystem is really important.\nOn Directors\nWe understand that at this point there is a legal and regulatory margin that is beyond our reach and it is necessary for Arbitrum Foundation to assign its board.\nHowever, we would like to have more information regarding the names mentioned before proceeding with this proposal or at least for Offchain Labs/Arbitrum explain why these directors where elected, with some background about them. Also, these directors could introduce themselves in the forum as such, explaining what’s their background, what relationship they have t0 Arbitrum/Offchain Labs, etc. It is important to maintain trust among all parties that make up Arbitrum DAO, the DAO as such has the right to know who is behind this Foundation and why they were appointed.\nOn the Security Council\nOn this point, there’s nothing we would really change, just congratulations to Patricio Worthalter for being part of the Council, since he’s pretty close to our community and an important voice from our region. Our community members are big fans of POAP, and we are proud that this attestation tool has emerged from this side of the world!\nOn the Data Availability Committee (Arbitrum Nova chain only)\nRegarding the Data Availability Committee, we would like to have more clarity on the selection criteria of each member and their relationship with Offchain Labs.\nWe also believe that it is necessary to vote on a removal or appointment process, just in case there’s a scenario where one member should be replaced, such as what happened last year with FTX.\nOn The Arbitrum Foundation Administrative Budget Wallet\nThis is what has generated the most debate and dissatisfaction, on the one hand, it is not an exorbitant amount for a DAO Foundation since they have to pay administrative costs and grant funding as mentioned earlier. On this point, our community is completely in favor of the Foundation being funded, and we don’t necessarily have any issues with the amount requested. The problem here, as mentioned earlier, is communication.\nWe consider that it’s too risky to have 7.5% of the total supply on a multisig, we know this is unlikely to happen, but after what happened with Ronin we don’t think we should run the risk. This allocation should be distributed gradually, and discussed in a separate proposal, with proper guidelines on how these funds are going to be used and what roles would the directors have in all of this. The main issue we had, as a community, is the way that arbitrum carried this out, doing first and asking for permission later. Even if it was just a “ratification”, then at least they should’ve been transparent since day 1 about the Foundation’s wallet being funded at the time of the distribution and regarding funds going to a market maker, which again, we don’t see an issue with this, but we simply don’t understand why couldn’t this be communicated openly in a transparent way.\nSo how should we proceed?\nTo fix this error and due to everything that has happened during this temperature check, we believe that if the proposal is rejected, Arbitrum should take another approach, go point by point, and have it voted on by Arbitrum DAO.\nConclusion\nOur community is convinced that we are in time to remedy the first misstep that Arbitrum has taken. On the other hand, we are also pleased with the general reactions, we believe that this type of situation is always good for progressing as an ecosystem, we are in very early stages and it’s better to make these mistakes now than later.\nFinally, we want to thank our community, more than 60 members showed up to our governance call, and also thank you to our contributors and delegates @axlvaz_SEEDLATAM.eth @Manugotsu_SEEDLatam @SEED_Latam_Joxes @Phenrril @Noa and @ArbiGod.eth for participating and helping us form this statement. Any member of this DAO who wants to participate in our governance calls and open to discuss Arbitrum-related topics is welcome.\nAlso, if you want to watch our first governance call click here.\n\n SEED Latam Delegate Communication Thread\n\n Proposal: Return 700M $ARB to the DAO Treasury\n\n Proposal: AIP-1.1 - Lockup, Budget, Transparency\n\n post by sluicejuice1 on Apr 3, 2023\n\n sluicejuice1\n\n Good post and thank you for representing Spanish-speaking community!\n\n post by Igor9999 on Apr 3, 2023\n\n Igor9999\n\n I don’t think the issue here is whether the Foundation should have a budget for BD (or the possibility of lending to MM).\nThese points are necessary for the arbitrum to be successful.\nFor example, if the document had clearly stated that the foundation would get 750m airdrops (even better if there was an implication in the vesting), I don’t think there would have been much discussion here.\nPeople would have just been arguing about what is the best and most efficient way for the Foundation to use them. There is nothing more to it than that.\nThe problem is simply that\ni) the documentation didn’t mention it\nii) The volume in circulation and the resulting market capitalization, which everyone used and made investment decisions on, was simply false. The volume of tokens in circulation was more than 1.25 billion, not 1.25 billion. What should be used now? Do we add another 50 million tokens to reflect the 10 million tokens sold and the 40 million tokens used by MM (which would make sense)? Or is it an additional 750 million tokens if, from the use of the word “ratify”, it could be in circulation as early as today without a vote?\niii) What was the rush to sell 10 million tokens, which could cover the costs of running such a foundation for quite some time, without transparency?\niv) By saying that AIP-1 is a mere “ratification”, the governance power of the ARB token is undermined and hence the value of the token. What governance power does the token have if the proposal is implemented as is despite token shareholders voting against it?\nWhat is done is done and cannot be undone. However, it is clear that the ARB token shareholders do not agree with the AIP-1 proposal.\nI am just a retarded anon with a completely irrelevant amount of tokens. However, assuming my IQ to be 60, it seems to me that the best approach would be as follows\ni) Never say again that voting is not important.\nii) Hold the bulk of the remaining 700 million tokens in contracts with linear vesting (I wouldn’t need to spend $1 billion in ARB tokens on day one). The contracts are not immutable and can be amended by subsequent governance votes.\niii) Increase the number of foundation directors to five. This is to improve decentralization and to provide token holders with reassurance that their grant money will be used for the success of the ecosystem rather than for back taxes (as happened with some Alt-L1s).\niv) Provide transparency and details about the first year of the budget (or at least the set-up costs and expenses for the next few months) so that people better understand why we rushed to sell 10 million tokens.\nv) Propose a grant application process and general criteria (does not need to be extremely detailed, just a framework).\nThis would pass the AIP-2 easily and goodwill would be sufficient.\n\n post by Zeb on Apr 3, 2023\n\n Zeb\n\n sluicejuice1\n\n I was specifically talking about Offchain Labs members, not other ‘outside’ members.\n\n post by sluicejuice1 on Apr 3, 2023\n\n sluicejuice1\n\nbrave_Op9nuZoOmX722×959 123 KB\n\nThe September cohort?\n\n post by Igor9999 on Apr 3, 2023\n\n Igor9999\n\n I don’t think the issue here is whether the Foundation should have a budget for BD (or the possibility of lending to MM).\nThese points are necessary for the arbitrum to be successful.\nFor example, if the document had clearly stated that the foundation would get 750m airdrops (even better if there was an implication in the vesting), I don’t think there would have been much discussion here.\nPeople would have just been arguing about what is the best and most efficient way for the Foundation to use them. There is nothing more to it than that.\nThe problem is simply that\ni) the documentation didn’t mention it\nii) The volume in circulation and the resulting market capitalization, which everyone used and made investment decisions on, was simply false. The volume of tokens in circulation was more than 1.25 billion, not 1.25 billion. What should be used now? Do we add another 50 million tokens to reflect the 10 million tokens sold and the 40 million tokens used by MM (which would make sense)? Or is it an additional 750 million tokens if, from the use of the word “ratify”, it could be in circulation as early as today without a vote?\niii) What was the rush to sell 10 million tokens, which could cover the costs of running such a foundation for quite some time, without transparency?\niv) By saying that AIP-1 is a mere “ratification”, the governance power of the ARB token is undermined and hence the value of the token. What governance power does the token have if the proposal is implemented as is despite token shareholders voting against it?\nWhat is done is done and cannot be undone. However, it is clear that the ARB token shareholders do not agree with the AIP-1 proposal.\nI am just a retarded anon with a completely irrelevant amount of tokens. However, assuming my IQ to be 60, it seems to me that the best approach would be as follows\ni) Never say again that voting is not important.\nii) Hold the bulk of the remaining 700 million tokens in contracts with linear vesting (I wouldn’t need to spend $1 billion in ARB tokens on day one). The contracts are not immutable and can be amended by subsequent governance votes.\niii) Increase the number of foundation directors to five. This is to improve decentralization and to provide token holders with reassurance that their grant money will be used for the success of the ecosystem rather than for back taxes (as happened with some Alt-L1s).\niv) Provide transparency and details about the first year of the budget (or at least the set-up costs and expenses for the next few months) so that people better understand why we rushed to sell 10 million tokens.\nv) Propose a grant application process and general criteria (does not need to be extremely detailed, just a framework).\nThis would pass the AIP-2 easily and goodwill would be sufficient.\n\n post by Curia on Apr 3, 2023\n\n Curia\n\n Hello everyone, we are Curia, an Arbitrum delegate platform. It’s inspiring to see this proposal initiating the formal establishment of the Arbitrum DAO. We appreciate and support various aspects of the proposal, including the creation and funding of the Arbitrum Foundation, which resonates with our perspective on progressive decentralization. Nonetheless, we find it essential to express our agreement with the concerns raised in this thread.\nAt present, we will be voting Agasint the proposal due to transparency concerns and other issues raised by delegates in these forums. AIP-1 falls short in terms of clarity in several areas, including the pre-allocation of funds without community approval or input and the 750 million $ARB token transfer to the Foundation during the initial token distribution. This transfer has reportedly already occurred, making AIP-1 seem like a retroactive ratification of decisions made without the DAO’s involvement.\nTaking into account the delegates’ concerns raised in these forums, we present a summary of concerns and recommendations for advancing with Arbitrum AIP-1:\nKey Concerns:\n\nAIP-1 is encompasses too many topics. Numerous potentially non-contentious and contentious items are bundled together under a single vote, which could set an unfavorable precedent.\n\nLack of communitcation regarding the pre-allocation of funds without community notice, approval or input.\n\nInsufficient transparency and detail regarding the 750M ARB budget allocated for administrative purposes.\n\nAmbiguity surrounding the Special Grants program, with unclear processes and criteria for awarding funds, which lacks DAO involvement and requires proper guidelines and context on how the fund will be used to benefit the Arbitrum ecosystem.\n\nLack of clarity around the Arbitrum Foundation’s directors and Data Availability Committee’s selection criteria and processes for member removal or appointment.\n\nRecommendations for Arbitrum AIP-1 Moving Forward:\n\nImprove the communication process regarding the governance updates and actions taken by the Arbitrum team.\n\nOne issue we’ve noticed is the lack of proper announcements for proposals, both on the forum and Arbitrum’s Twitter. We suggest having an official process on the announcing updates of each proposal on the forum and creating a separate Twitter account focused solely on ArbitrumDAO’s governance-related matters, similar to SafeDAO.\n\nDivide AIP-1 into separate proposals that can be voted on individually. This could include separate votes ratifying on:\n2.1 The relationship of Arbitrum foundation with ArbitrumDAO and clarity on issue regarding its directors\n\nClearly outline the appointment process for Directors, including their backgrounds, relationships with Arbitrum/Offchain Labs, and the rationale behind their selection.\nAlso encourage the Directors to introduce themselves in the forum to foster trust and transparency.\n\n2.2 The guideline or framework for Special Grants and clear process on how to enhance transparency and provide more detail on the 750M ARB budget by including allocation guidelines, timelines, and regular reporting to the community.\n\nFor Special Grants program, including a clear outline of the processes and criteria for grant selection, as well as the intended impact on the Arbitrum ecosystem.\n\nIncorporate reimbursement for Foundation Setup Costs mentioned earlier in the initial AIP-1 proposal.\n\nAs a side note, since Arbitrum is promoting the incorporation of on-chain votes to directly control governance via smart contracts, consider employing smart contracts to control fund allocation and vesting of tokens, ensuring immutable enforcement and proper management of funds.\n\n2.3 Address the Security Council and Data Availability Committee\n\nOffer more clarity on the selection criteria for the Security Council and Data Availability Committee, and establish processes for member removal or appointment. This will help ensure that the committees function effectively and can adapt as needed.\n\nBy addressing these recommendations, Arbitrum can create a more inclusive and transparent governance process going foward. This will help build trust within the community and ensure that future proposals are met with a more constructive and collaborative approach.\n\n Curia Delegate Communication Thread\n\n post by Camelot on Apr 3, 2023\n\n Camelot\n\n SUMMARY\nIn short, as the 5th largest delegate, Camelot will be voting ‘ABSTAIN’ on AIP-1. After internal discussions and listening to the thoughts from our community and the broader Arbitrum ecosystem, we feel we cannot vote FOR or AGAINST the AIP-1 in its current state, given that it’s a signaling vote rather than a binding governance proposal.\nFor a summary of our position on AIP-1, please see the points below:\n\nDue to the ratification of AIP-1, the proposal is purely a signaling vote and not binding; therefore, we will be abstaining\nWhilst we are supportive of the allocations, which we feel are in line with industry standards and appropriate, we are strongly against the concept of ratification\nConsidering the size of the allocation, more details are required to detail the breakdown for short, mid, and long-term purposes\nIn addition to more details on the use of the allocation, further precisions are required on the vesting and custody, in which there is still a lack of transparency and communication that is desperately needed to maintain trust within the community\nTransparency regarding the grant process and how these will be enacted & clearly communicated to the community is also required\nFinally, the format of the proposal is not conducive to community discussion and debate, and we would suggest a more broken-down approach that is appropriate for the average community member\n\nRATIONALE\nFirstly, when discussing the contents of the initial proposal, we are generally supportive of the allocation towards the foundation, which we feel objectively aligns with standard practices we have seen in the industry so far and is appropriate in the context of a network-level foundation. The Arbitrum ecosystem has grown significantly in its relatively short history, and this rapid success would not have been possible without the team who built and drove it to where it is today, and therefore the allocation itself is something we deemed as fair.\nHowever, we also believe that governance obviously has an absolutely crucial role in the future of decentralized networks. When AIP-1 was first proposed, we were under the impression that it was a genuine vote, as it was portrayed. Therefore, we strongly disagree with the concept of proposing a vote on something to then amend it to a ‘ratification’. Not only does this invalidate the role of governance, but it further undermines the role of the ecosystem in such an important early decision - the first AIP. This point is the main rationale behind voting abstain, as the proposal is no longer a valid governance vote and is merely a signal that bears no impact on the end outcome.\nWe do not support the ratification of AIP-1 and would further suggest several items to improve the initial proposal. Firstly, we feel that there is a lack of detail in regard to how the allocation of these tokens is actually used and distributed. The current allocation represents a significant amount of tokens, and yet AIP-1 does not sufficiently explain how it will be used. This amount of tokens will not only bootstrap grants for the short-term but for the life of the Arbitrum network, and therefore it’s imperative that the ecosystem is aware of the approach to how this allocation is intended to be used over both the short and long-term.\nIn addition to the lack of detail on how the tokens will be used, there is a subsequent lack of information about the grant process itself. The community cannot make an informed decision without knowing how the tokens are intended to be allocated. This requires understanding how grants will be conducted and communicated with the rest of the ecosystem. Without this process formalized and communicated, it’s unclear as to how the tokens might even be used and over what periods and structure.\nThe proposal also lacks transparency in terms of vesting and custody, both of which are highly sensitive factors that the community is very conscious of. Any large movement of tokens will result in instant reactions online, so having these details included in such an important proposal is critical.\nFinally, we strongly recommend that the next AIP follows a different format that is more conducive to community discussion and debate. As the first proposal, AIP-1 provided a significant amount of information for the broader ecosystem to digest, opening room for misunderstanding as various interpretations were spread online. Community involvement is a fundamental element of decentralized governance, and therefore we suggest that future proposals not only contain all the relevant details but also follow a more digestible and user-focused approach.\nCONCLUSION\nDue to the lack of details within the proposal and the amendment of AIP-1 to a ‘ratification’, Camelot will be voting ABSTAIN and waiting for further information and clarity from the Arbitrum DAO and foundation. Despite the shortcomings mentioned above, we remain committed to supporting the Arbitrum DAO and foundation and strongly believe that the ecosystem will find an amicable path forward that takes this as an important lesson that strengthens future governance proposals.\n\n post by krst on Apr 3, 2023\n\n krst\n\n At L2BEAT we took our time to thoroughly analyze the situation around the AIP-1 proposal:\n\nWe read what’s been written in this forum post and on Twitter.\nWe went through the official legal documents.\nWe analyzed the on-chain history.\nWe have read the ArbitrumDAO smart contracts.\n\nThese are our main findings:\n\nThe vote to adopt AIP-1 is irrelevant for AIP-1 going into effect.\nArbitrumDAO remains in full control of the funds, and has to approve funds in the Arbitrum Foundation’s wallet.\nArbitrumDAO has governance control over the Arbitrum Foundation (as per foundation founding documents).\nArbitrumDAO has upgrade power over all Arbitrum contracts including the ARB token itself.\nAIPs can only be proposed and voted on by the DAO and its members and not any external actors.\n\nAfter this careful consideration, we decided to vote: ABSTAIN in the Snapshot temperature check. We think that this proposal shouldn’t even be voted on and it should rather be treated as an initial setup of procedures for ArbitrumDAO. Future AIP proposals should address all the contentious issues to amend those procedures.\nBelow we try to summarize our understanding of the current situation, what we think should happen now and how we should avoid such issues in the future.\nImportant documents:\n\nAIP-1: Arbitrum Improvement Proposal Framework - the controversial AIP\nThe Amended Constitution of the Arbitrum DAO | Arbitrum DAO - Governance docs - The ArbitrumDAO constitution that directly refers to AIP-1 several times\nThe Arbitrum Foundation - Bylaws - Google Docs - The Arbitrum Foundation Bylaws, that define how Arbitrum Foundation is functioning and also refers to AIP-1 several times\nThe Arbitrum Foundation - A&R Mem & Arts (Final Form) (16.3.23) - Google Docs Arbitrum Foundation companies act that established Arbitrum Foundation\n\nTimeline:\n\n15th March, AIP-1 is posted on a forum\n16th March - hash of the constitution published on-chain Arbitrum Transaction Hash (Txhash) Details | Arbiscan\n16th March - beginning of all official Arbitrum communication on DAO, token airdrop, etc… including $ARB allocation information in $ARB airdrop eligibility and distribution specifications | Arbitrum DAO - Governance docs\n16th March (evening) - deployment of $ARB token, initial allocation of funds to various parties including 7.5% to the Foundation $1.02 | Arbitrum (ARB) Token Tracker | Arbiscan\n28th March - the snapshot vote is called Snapshot\n\nThe vote to adopt AIP-1 is irrelevant for AIP-1 going into effect\nThe ArbitrumDAO was set up by publishing the ArbitrumDAO Constitution together with AIP-1 that specified the framework for ArbitrumDAO operations and initial token distribution according to the initial token allocation ($ARB airdrop eligibility and distribution specifications | Arbitrum DAO - Governance docs).\nIn our opinion, the AIP-1 is not really votable, as the ArbitrumDAO Constitution clearly refers to AIP-1 as a source of truth regarding the structure and processes of ArbitrumDAO. Furthermore, legal documents establishing Arbitrum Foundation also refer to the AIP-1 as a document that defines the structure and processes of the ArbitrumDAO. In that case this structure and those processes are already in motion and ArbitrumDAO needs to abide by them. In a sense, were there no AIP-1, there would be no ArbitrumDAO to even decide on any AIP.\nIn that way it’s not up for ArbitrumDAO to decide whether to accept or reject AIP-1. The vote for this AIP should proceed according to the Constitution, but there seems to be no substantial consequences of this vote passing or not passing.\nHowever, it is in the power of ArbitrumDAO to amend the rules set in AIP-1 by submitting and accepting new AIPs that change those rules.\nThe AIP-1 proposal is a large proposal that mixes several different aspects of setting up the ArbitrumDAO. The majority of the aspects outlined in the AIP-1 are non-controversial statements of facts that are not debatable or votable - the initial set of directors, the security council, the initial data availability committee members, the AIP processes - all of these already happened and are considered an initial setup. These also seem not controversial. It is not the case however, in our opinion, with the funds allocated to the Foundation.\nThe DAO remains in full control of the funds, and has to approve funds in the Arbitrum Foundation’s wallet\nAccording to the distribution specification 42.78% or 4.278B of ARB tokens were allocated to ArbitrumDAO treasury. However, if we look into the on-chain transfers that were executed on the 16th of March ($1.02 | Arbitrum (ARB) Token Tracker | Arbiscan), we can see that this amount is split into two portions: 3,527,046,079 ARB has been sent to the ArbitrumDAO Treasury contract, and 750,000,000 ARB has been sent to another address, that is not listed in the official list of deployment addresses (DAO contract addresses | Arbitrum DAO - Governance docs).\nFrom the AIP-1 proposal we assume that this address is a multisig wallet controlled by Arbitrum Foundation. AIP-1 mentions this as Administrative Budget Wallet and that these funds will be used for “making Special Grants, reimbursing applicable service providers for the Total Setup Costs and covering ongoing administrative and operational costs of The Arbitrum Foundation”. Furthermore, Administrative Budget Wallet is also defined in the Foundation Bylaws (The Arbitrum Foundation - Bylaws - Google Docs) in section 2 point a:\n\n(a) “Administrative Budget Wallet” means the account that contains ArbitrumDAO approved Foundation assets, which will be utilized by the Foundation for purposes of operational and administrative costs as well as administration of Special Grants.\n\nThe Bylaws state that the assets held by Administrative Budget Wallet are “ArbitrumDAO approved”. In our opinion that means that, no matter the amount held by this account, those assets are still part of the general ArbitrumDAO Treasury and ArbitrumDAO still needs to decide on how much should be approved as disposable by the Foundation. The DAO remains in position to approve any funds held by the foundation’s wallet. Without the DAO’s approval, the Foundation is not authorized to spend the funds. We believe that the DAO still has the possibility to amend this amount (by proposing another AIP related exactly to that issue) and, for example, it could ask the Foundation to return all or some of the funds.\nArbitrumDAO’s control over Arbitrum Foundation and ARB token\nIt is worth noting that even though the initial setup of the Arbitrum Foundation and ArbitrumDAO has been proposed within the AIP-1 (and has been also set up legally), the ArbitrumDAO still remains able to:\n\nExercise “control” over the Foundation (as specified in Foundation’s bylaws).\nRemove or appoint Foundation directors.\nAsk the Foundation to provide transparency over how funds at the disposal of the Foundation are used.\nApprove assets in the Foundation’s wallet, which in our opinion should also include the possibility to ask the Foundation to return all the funds that are currently under control of Foundation’s Multisig.\nWind-up the Foundation.\n\nWe have never seen any other high-profile project that gives so much power to the community and as such we hope that the community will use this power wisely, assuming first and foremost good intentions of people having to do the “initial setup”.\nFurthermore, it is worth reminding the community that the ArbitrumDAO also holds control over the ARB token, so theoretically it can propose such an upgrade of the token contract that would for example circumvent the current restriction that mint can happen only once a year and the inflation cannot exceed 2% (by upgrading to a new implementation with new mint() logic).\nOur vote\nGiven what we have summed up above, we decided to vote: ABSTAIN. We believe that no matter the results of this vote, the merits of the AIP-1 are still in effect and ArbitrumDAO should abide by them. However, we also believe that the ArbitrumDAO should already propose additional AIPs to amend the contentious aspects and that it should be accompanied by a healthy debate.\nWe would like to see Arbitrum succeed as a decentralized ecosystem with strong community and good governance mechanics. We think that ArbitrumDAO Constitution, together with AIP-1 is a good starting point for that and we believe that all involved actors will work together to make it better in the future.\nThe ArbitrumDAO itself has been given enough power to have a meaningful impact on the future of the Arbitrum ecosystem. Going forward, new proposals should be submitted as soon as possible to address the most contentious issues, especially the amount of funds that are accessible for the Arbitrum Foundation. Our stance is that the funds currently held in the Administrative Budget Wallet should not be considered as ArbitrumDAO approved and therefore should not be used until such approval from ArbitrumDAO is granted. We don’t believe trying to recover already spent funds would be beneficial for anyone, but all spending should immediately stop until the DAO gives its approval.\nWe are declaring our availability and willingness to work on those proposals and we believe that the focus of the ArbitrumDAO should be moved towards that.\n\n post by gauntlet on Apr 3, 2023\n\n gauntlet\n\n While Gauntlet is in favor of forming the ArbitrumDAO and supporting the Arbitrum Foundation, we agree with other delegates that more detail is needed around the Foundation’s plans for structuring and operational procedures. As such, Gauntlet is abstaining from this vote.\nAll said, we are excited by the governance activity displayed here and are looking forward to reviewing ideas and proposals that remedy the community’s concerns.\n\n post by BlockworksResearch on Apr 3, 2023\n\n BlockworksResearch\n\n Blockworks Research team here with an update on our views surrounding AIP-1 and the next steps from here.\nWe have been very impressed by the level of participation and quality of discourse surrounding this proposal. While we voted “Against” on the snapshot proposal, we still believe there is a way to move forward that ensures success for the proposed Foundation and the Arbitrum Ecosystem. To recap, we believe these are the primary issues the community sees with the proposal in its current state:\n\n750M ARB tokens with no vesting period to be sent from the community allocation.\n\nThese tokens were moved prior to the voting period for AIP-1, which was received very poorly by the community.\n\n50M ARB tokens were already spent by the Foundation. 40M were loaned to Wintermute, and 10M were sold to cover operating costs.\n\nAgain, these tokens were moved prior to the voting period for AIP-1, which was received very poorly by the community.\n\nLack of clarity surrounding the Arbitrum Foundation: the selection of the initial directors, the justification for 750M ARB, the process for creating and allocating “Special Grants,” and the necessary operational expenditures need further elaboration.\n\nAIP-1 contained too many elements to fit into one proposal. Each individual element should be its own AIP that is discussed and voted on separately.\n\nHigh ARB requirement of 5M to submit proposals.\n\nA Path Forward\nWith all this in mind, here is what we are proposing the next steps should be for the DAO:\n\nProvide a detailed budget breakdown to justify the funds sent to the Arbitrum Foundation that will be held in the Administrative Budget Wallet.\n\nOnce a budget has been submitted for DAO review, create a vesting contract that aligns with the Foundation’s annual budget requirements. The vesting contract should be set up in a manner that gives the DAO the ability to halt funding if KPIs are not met.\n\nA Foundation focused on creating a vibrant and sustainable ecosystem is beneficial to the success of Arbitrum. In our view, a 7.5% allocation to an ecosystem fund is fair and necessary for competitive advantage, especially when looking at other comparable foundation token allocations. However, it was a misstep to fund the wallet prior to DAO approval. Sending these funds back to the DAO treasury would hamper the Foundation’s ability to act in the DAO’s best interest for the next 2-3 months as it would severely slow the rate of implementation.\nIn order to rectify the initial missteps, we request a detailed budget breakdown to justify a 750M ARB allocation to the Arbitrium Foundation. This plan should include information on the Arbitrium Foundation’s mission, scope, team (full-time and contract), and budget. It should address the Foundation’s goals and include KPIs to measure success.\nOnce a budget has been agreed upon, there can be further discussion about how the funds should be delivered from the DAO to the Administrative Budget Wallet. We are generally in favor of vesting over a set period of time with the ability to request quicker distribution if necessary, however, more information will be gleaned once a plan has been presented.\nUniswap set a great example of how funds should be requested from the treasury to form a foundation that works in the protocol’s best interest, which includes budget breakdowns, OKRs, a detailed roadmap, and clarity surrounding the foundation’s key stakeholders and decision makers. While it may not be possible to go into as much detail as the Uniswap Foundation was able to, much more clarity into the Arbitrum foundation’s roadmap, KPIs, and contributors would go a long way.\nThis should eliminate the community concerns surrounding the lack of transparency in the foundation’s decision making and budget allocation. It should also help clarify the need for a 750M ARB allocation and present the best method of distributing the funds over time.\nWhile this is not typical of other network foundations, we can set a strong precedent for efficient capital allocation and complete transparency.\nOther less notable changes we also support:\n\nSplitting up AIP-1 into many different AIPs.\nLowering the ARB required to post an AIP on chain.\n\n post by foxie on Apr 3, 2023\n\n foxie\n\n After renewed examination of the AIP-1 together with the arguments presented by the community and in view of new circumstances, I hereto change my position on the AIP-1 and consider it important to underline the following points:\n\nThe Arbitrum Foundation cannot and should not be blamed for the steps it undertook in order to implement the AIP-1, as it turns out these were actually necessary decisions with a view to commence the functioning of the DAO and ensure its resilience in this highly competitive environment. What it should be blamed for is the miscommunication and presenting of the AIP-1 as something to be decided by the vote. The AIP-1 should have clearly be presented as the foundational document being implemented for the commencement and development of the DAO and it should have been clearly stated that what was really sought were comments on the AIP-1 by the community.\n\nThe argument about exorbitance of the sum allocated to the Foundation as such cannot but be inadequate, that is in view of comparisons with similar cases (like Polygon, for example). Arguably, this argument could be based upon the fear of existence of a strong centralised body within the DAO, as it would undermine decentralisation. Although being to some extent justified, such fear should be weighted against the necessity of a strong centralised body of high-skilled professionals within the DAO to effectively carry out its decisions. But at the same time it’s undeniable fact that such body cannot be a part of the DAO without being duly checked and balanced.\n\nThus, the AIP-1 should be presented as a document being already implemented. The most ubiquitous comments/complaints to the AIP-1 should be transformed into the AIP(s), that is if the AIP-1 could be accordingly amended in case of positive vote and adoption of such AIP(s).\nThe system of aforementioned checks and balances should be speedily devised and implemented. It means that although being strong the Foundation must be accountable to the DAO.\n\n post by Atomist on Apr 5, 2023\n\n Atomist\n\n The proposal itself is troubling for several reasons:\n\nAIP-1 was a ‘ratification’ of actions already carried out by the Arbitrum Foundation - clearly against the decentralised ethos they are attempting to create\nAlmost no transparency was given to the allocation of 750m ARB to the Arbitrum Foundation\nAn extremely expansive proposal with no clear focus on a particular subject matter\n\nAIP-1 Overall Failure\nIn our opinion, this is an incredibly bad precedent to set where the first vote is a ‘ratification’ of past actions and something the DAO would disagree with. We are sympathetic in that a huge cost is associated with setting up and operating such a large organisation, not only efficiently but successfully.\nArbitrum had every opportunity to outline these funds for allocation to the Foundation in their token distribution schedule when the ARB token and Arbitrum DAO were announced. We believe that as this road was not chosen, the Foundation must remain on it and stay true to its outlined governance process.\nUnfortunately, from the outside, AIP-1 looks like an attempt to squeeze a large amount of funding for any number of things into an all-encompassing proposal hoping to fly under the radar (we understand this is likely not the case but optics are everything in this space).\nFrankly, AIP-1 was a proposal to bypass the governance process, which was already bypassed due to the actions that have already taken place. Instead of attempting to be as decentralised as possible with the ratification of actions, they have undermined the entire DAO and its governance power.\nThe ARB token’s main purpose is governance and this simple yet critical purpose has been walked all over. In light of this, we will be abstaining from voting on AIP-1.\nTransparency\nAIP-1 gives almost no transparency as to the allocation of funds, how they will be spent, or when.\nThe following is required to move forward regarding the Special Grants Program:\n\nWhat framework is to be used to select grants to ecosystem participants and how will these benefit the Arbitrum DAO?\nWhat types of grants will be targeted (sectors) and why?\nHow will such grants be reported to the community?\nHow will a return on investment (ROI) be calculated for these grants to determine program efficacy?\n\nIn addition to the Special Grants Program, ARB has been moved from supposedly locked wallets (with vesting) without any prior communication. We call for a full report on the details of all wallets and their locked/vesting status. Transparency on circulating/liquid tokens, vesting and selling schedules are paramount.\nMulti-faceted Proposal\nAs echoed by many others here and specifically in our original ARB Delegate Application, AIPs must be targeted at a single goal. AIP-1 misses this by a long way and can be split into several more focused proposals.\nSummary\nAs a result of the above comments, Castle Capital has Abstained from voting on AIP-1. We look forward to the above comments being implemented for the revision.\n\n post by Arbitrum on Apr 6, 2023\n\n Arbitrum\n\n Hi @Atomist , please find the new proposals here:\n\n 10 days later\n\n post by residual on Apr 16, 2023\n\n residual\n\n purplepill3m\n\n Standing on this protocol, this is my stand too.\n\n post by arbit on Apr 17, 2023\n\n arbit\n\n DAO-based governance over the Arbitrum One and Arbitrum Nova network protocols, and they are generously offering an airdrop of the ARB token to communities that have played a role in the growth and health of the Arbitrum ecosystem. And guess what? Lido Protocol has been selected as an eligible recipient for this airdrop!\nAs a crucial player in the Arbitrum DeFi ecosystem, Lido DAO is entitled to claim a whopping 772,621 ARB tokens! These tokens can be used to further the growth of staking and the wstETH DeFi ecosystem on Arbitrum One and beyond. But first, we need to take some important steps.\nWe propose designating a representative or group of representatives to accept the airdrop and process the claim. And who better than our very own Lido DAO reWARDS committee to lead the charge? They will be our designated representatives and have the authority to use the ARB tokens to pursue the growth and expansion of stToken use across all supported networks.\nTo kick things off, we will initialize a 4/7 reWARDS Committee multisig on Arbitrum, which will receive the ARB tokens. The multisig composition will include some of our top community members,. Once operationalized, the committee will announce its readiness on this thread and the original proposal thread.\nLet’s make the most of this incredible opportunity to strengthen and grow the Arbitrum ecosystem, and continue to pave the way for DeFi innovation!\n\n Closed on Apr 19, 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 Clarity around the ratification of AIP-1\n\n Proposals\n\n 46\n\n 26.0k\n\n Apr 2023\n\n Proposal: AIP-1.1 - Lockup, Budget, Transparency\n\n Finalized AIPs\n\n 87\n\n 24.4k\n\n Jun 2023\n\n Proposal: Return 700M $ARB to the DAO Treasury\n\n Archived Proposals\n\n snapshot,failed\n\n 53\n\n 16.2k\n\n Apr 2023\n\n Proposal: AIP-1.2 - Foundation and DAO Governance\n\n Finalized AIPs\n\n tally,passed\n\n 65\n\n 19.0k\n\n Jun 2023\n\n SEED Latam Delegate Communication Thread\n\n Delegate Statements\n\n delegation,delegate-statements\n\n 48\n\n 8.1k\n\n Jan 2025","tokens":11536,"squid":"spider-07","role":"Council Spider","at":1791340221560,"hash":"da941124c21c79201f3777606d71f20598a7e245"}
{"url":"https://squidfunk.github.io/mkdocs-material/setup/extensions/python-markdown-extensions/","domain":"squidfunk.github.io","title":"Python Markdown Extensions - Material for MkDocs","text":"Python Markdown Extensions¶ The Python Markdown Extensions package is an excellent collection of additional extensions perfectly suited for advanced technical writing. Material for MkDocs lists this package as an explicit dependency, so it's automatically installed with a supported version. Supported extensions¶ In general, all extensions that are part of Python Markdown Extensions should work with Material for MkDocs. The following list includes all extensions that are natively supported, meaning they work without any further adjustments. Arithmatex¶ 1.0.0 pymdownx.arithmatex The Arithmatex extension allows for rendering of block and inline block equations and integrates seamlessly with MathJax1 – a library for mathematical typesetting. Enable it via mkdocs.yml: markdown_extensions:\n - pymdownx.arithmatex:\n generic: true\n Besides enabling the extension in mkdocs.yml, a MathJax configuration and the JavaScript runtime need to be included, which can be done with a few lines of additional JavaScript: docs/javascripts/mathjax.js mkdocs.yml window.MathJax = {\n tex: {\n inlineMath: [[\"\\\\(\", \"\\\\)\"]],\n displayMath: [[\"\\\\[\", \"\\\\]\"]],\n processEscapes: true,\n processEnvironments: true\n },\n options: {\n ignoreHtmlClass: \".*|\",\n processHtmlClass: \"arithmatex\"\n }\n};\n\ndocument$.subscribe(() => { \n MathJax.startup.output.clearCache()\n MathJax.typesetClear()\n MathJax.texReset()\n MathJax.typesetPromise()\n})\n extra_javascript:\n - javascripts/mathjax.js\n - https://unpkg.com/mathjax@3/es5/tex-mml-chtml.js\n The other configuration options of this extension are not officially supported by Material for MkDocs, which is why they may yield unexpected results. Use them at your own risk. See reference for usage: Using block syntax Using inline block syntax BetterEm¶ 0.1.0 pymdownx.betterem The BetterEm extension improves the detection of Markup to emphasize text in Markdown using special characters, i.e. for **bold** and _italic_ formatting. Enable it via mkdocs.yml: markdown_extensions:\n - pymdownx.betterem\n The configuration options of this extension are not specific to Material for MkDocs, as they only impact the Markdown parsing stage. See the BetterEm documentation for more information. Caption¶ 1.0.0 pymdownx.blocks.caption The Caption extension adds the ability to add captions to any Markdown block, including images, tables, and code blocks. Enable it via mkdocs.yml: markdown_extensions:\n - pymdownx.blocks.caption\n The configuration options of this extension are not specific to Material for MkDocs, as they only impact the Markdown parsing stage. See the Caption documentation for more information. Caret, Mark & Tilde¶ 1.0.0 pymdownx.caret The Caret, Mark and Tilde extensions add the ability to highlight text and define sub- and superscript using a simple syntax. Enable them together via mkdocs.yml: markdown_extensions:\n - pymdownx.caret\n - pymdownx.mark\n - pymdownx.tilde\n The configuration options of this extension are not specific to Material for MkDocs, as they only impact the Markdown parsing stage. See the Caret, Mark and Tilde documentation for guidance. See reference for usage: Highlighting text Sub- and superscripts Critic¶ 1.0.0 pymdownx.critic The Critic extension allows for the usage of Critic Markup to highlight added, deleted or updated sections in a document, i.e. for tracking changes in Markdown syntax. Enable it via mkdocs.yml: markdown_extensions:\n - pymdownx.critic\n The following configuration options are supported: mode view This option defines how the markup should be parsed, i.e. whether to just view all suggested changes, or alternatively accept or reject them: View changesAccept changesReject changes markdown_extensions:\n - pymdownx.critic:\n mode: view\n markdown_extensions:\n - pymdownx.critic:\n mode: accept\n markdown_extensions:\n - pymdownx.critic:\n mode: reject\n See reference for usage: Highlighting changes Details¶ 1.9.0 pymdownx.details The Details extension supercharges the Admonition extension, making the resulting call-outs collapsible, allowing them to be opened and closed by the user. Enable it via mkdocs.yml: markdown_extensions:\n - pymdownx.details\n No configuration options are available. See reference for usage: Collapsible blocks Emoji¶ 1.0.0 pymdownx.emoji The Emoji extension automatically inlines bundled and custom icons and emojis in *.svg file format into the resulting HTML page. Enable it via mkdocs.yml: markdown_extensions:\n - pymdownx.emoji:\n emoji_index: !!python/name:material.extensions.emoji.twemoji \n emoji_generator: !!python/name:material.extensions.emoji.to_svg\n The following configuration options are supported: emoji_index emojione This option defines which set of emojis is used for rendering. Note that the use of emojione is not recommended due to restrictions in licensing: markdown_extensions:\n - pymdownx.emoji:\n emoji_index: !!python/name:material.extensions.emoji.twemoji\n emoji_generator to_png This option defines how the resolved emoji or icon shortcode is render. Note that icons can only be used together with the to_svg configuration: markdown_extensions:\n - pymdownx.emoji:\n emoji_generator: !!python/name:material.extensions.emoji.to_svg\n custom_icons This option allows to list folders with additional icon sets to be used in Markdown or mkdocs.yml, which is explained in more detail in the icon customization guide: markdown_extensions:\n - pymdownx.emoji:\n emoji_index: !!python/name:material.extensions.emoji.twemoji\n emoji_generator: !!python/name:material.extensions.emoji.to_svg\n options:\n custom_icons:\n - overrides/.icons\n The other configuration options of this extension are not officially supported by Material for MkDocs, which is why they may yield unexpected results. Use them at your own risk. See reference for usage: Using emojis Using icons Using icons in templates Highlight¶ 5.0.0 pymdownx.highlight The Highlight extension adds support for syntax highlighting of code blocks (with the help of SuperFences) and inline code blocks (with the help of InlineHilite). Enable it via mkdocs.yml: markdown_extensions:\n - pymdownx.highlight:\n anchor_linenums: true\n - pymdownx.superfences \n The following configuration options are supported: use_pygments true This option allows to control whether highlighting should be carried out during build time using Pygments or in the browser with a JavaScript syntax highlighter: PygmentsJavaScript markdown_extensions:\n - pymdownx.highlight:\n use_pygments: true\n - pymdownx.superfences\n markdown_extensions:\n - pymdownx.highlight:\n use_pygments: false\n As an example, Highlight.js, a JavaScript syntax highlighter, can be integrated with some additional JavaScript and an additional style sheet in mkdocs.yml: docs/javascripts/highlight.js mkdocs.yml document$.subscribe(() => {\n hljs.highlightAll()\n})\n extra_javascript:\n - https://cdnjs.cloudflare.com/ajax/libs/highlight.js/10.7.2/highlight.min.js\n - javascripts/highlight.js\nextra_css:\n - https://cdnjs.cloudflare.com/ajax/libs/highlight.js/10.7.2/styles/default.min.css\n Note that Highlight.js has no affiliation with the Highlight extension. All following configuration options are only compatible with build-time syntax highlighting using Pygments, so they don't apply if use_pygments is set to false. pygments_lang_class false This option instructs Pygments to add a CSS class to identify the language of the code block, which is essential for custom annotation markers to function: markdown_extensions:\n - pymdownx.highlight:\n pygments_lang_class: true\n auto_title false This option will automatically add a title to all code blocks that shows the name of the language being used, e.g. Python is printed for a py block: markdown_extensions:\n - pymdownx.highlight:\n auto_title: true\n linenums false This option will add line numbers to all code blocks. If you wish to add line numbers to some, but not all code blocks, consult the section on adding line numbers in the code block reference, which also contains some tips on working with line numbers: markdown_extensions:\n - pymdownx.highlight:\n linenums: true\n linenums_style table The Highlight extension provides three ways to add line numbers, two of which are supported by Material for MkDocs. While table wraps a code block in a <table> element, pymdownx-inline renders line numbers as part of the line itself: markdown_extensions:\n - pymdownx.highlight:\n linenums_style: pymdownx-inline\n Note that inline will put line numbers next to the actual code, which means that they will be included when selecting text with the cursor or copying a code block to the clipboard. Thus, the usage of either table or pymdownx-inline is recommended. anchor_linenums 8.1.0 Default: false – If a code blocks contains line numbers, enabling this setting will wrap them with anchor links, so they can be hyperlinked and shared more easily: markdown_extensions:\n - pymdownx.highlight:\n anchor_linenums: true\n line_spans When this option is set, each line of a code block is wrapped in a span, which is essential for features like line highlighting to work correctly: markdown_extensions:\n - pymdownx.highlight:\n line_spans: __span\n The other configuration options of this extension are not officially supported by Material for MkDocs, which is why they may yield unexpected results. Use them at your own risk. See reference for usage: Using code blocks Adding a title Adding line numbers Highlighting specific lines Custom syntax theme InlineHilite¶ 5.0.0 pymdownx.inlinehilite The InlineHilite extension add support for syntax highlighting of inline code blocks. It's built on top of the Highlight extension, from which it sources its configuration. Enable it via mkdocs.yml: markdown_extensions:\n - pymdownx.highlight\n - pymdownx.inlinehilite\n The configuration options of this extension are not specific to Material for MkDocs, as they only impact the Markdown parsing stage. The only exception is the css_class option, which must not be changed. See the InlineHilite documentation for guidance. See reference for usage: Highlighting inline code blocks Keys¶ 1.0.0 pymdownx.keys The Keys extension adds a simple syntax to allow for the rendering of keyboard keys and combinations, e.g. Ctrl+Alt+Del. Enable it via mkdocs.yml: markdown_extensions:\n - pymdownx.keys\n The configuration options of this extension are not specific to Material for MkDocs, as they only impact the Markdown parsing stage. The only exception is the class option, which must not be changed. See the Keys documentation for more information. See reference for usage: Adding keyboard keys SmartSymbols¶ 0.1.0 pymdownx.smartsymbols The SmartSymbols extension converts some sequences of characters into their corresponding symbols, e.g. copyright symbols or fractions. Enable it via mkdocs.yml: markdown_extensions:\n - pymdownx.smartsymbols\n The configuration options of this extension are not specific to Material for MkDocs, as they only impact the Markdown parsing stage. See the SmartSymbols documentation for guidance. Snippets¶ 0.1.0 pymdownx.snippets The Snippets extension adds the ability to embed content from arbitrary files into a document, including other documents or source files, by using a simple syntax. Enable it via mkdocs.yml: markdown_extensions:\n - pymdownx.snippets\n The configuration options of this extension are not specific to Material for MkDocs, as they only impact the Markdown parsing stage. See the Snippets documentation for more information. See reference for usage: Adding a glossary Embedding external files SuperFences¶ 0.1.0 pymdownx.superfences The SuperFences extension allows for arbitrary nesting of code and content blocks inside each other, including admonitions, tabs, lists and all other elements. Enable it via mkdocs.yml: markdown_extensions:\n - pymdownx.superfences\n The following configuration options are supported: custom_fences This option allows to define a handler for custom fences, e.g. to preserve the definitions of Mermaid.js diagrams to be interpreted in the browser: markdown_extensions:\n - pymdownx.superfences:\n custom_fences:\n - name: mermaid\n class: mermaid\n format: !!python/name:pymdownx.superfences.fence_code_format\n Note that this will primarily prevent syntax highlighting from being applied. See the reference on diagrams to learn how Mermaid.js is integrated with Material for MkDocs. The other configuration options of this extension are not officially supported by Material for MkDocs, which is why they may yield unexpected results. Use them at your own risk. See reference for usage: Using annotations Using code blocks Using content tabs Using flowcharts Using sequence diagrams Using state diagrams Using class diagrams Using entity-relationship diagrams Tabbed¶ 5.0.0 pymdownx.tabbed The Tabbed extension allows the usage of content tabs, a simple way to group related content and code blocks under accessible tabs. Enable it via mkdocs.yml: markdown_extensions:\n - pymdownx.tabbed:\n alternate_style: true\n The following configuration options are supported: alternate_style 7.3.1 false This option enables the content tabs alternate style, which has better behavior on mobile viewports, and is the only supported style: markdown_extensions:\n - pymdownx.tabbed:\n alternate_style: true\n combine_header_slug false This option enables the content tabs' [combine_header_slug style] flag, which prepends the id of the header to the id of the tab: markdown_extensions:\n - pymdownx.tabbed:\n combine_header_slug: true\n slugify None This option allows for customization of the slug function. For some languages, the default may not produce good and readable identifiers – consider using another slug function like for example those from Python Markdown Extensions: UnicodeUnicode, case-sensitive markdown_extensions:\n - pymdownx.tabbed:\n slugify: !!python/object/apply:pymdownx.slugs.slugify\n kwds:\n case: lower\n markdown_extensions:\n - pymdownx.tabbed:\n slugify: !!python/object/apply:pymdownx.slugs.slugify {}\n The other configuration options of this extension are not officially supported by Material for MkDocs, which is why they may yield unexpected results. Use them at your own risk. See reference for usage: Grouping code blocks Grouping other content Embedded content Tasklist¶ 1.0.0 pymdownx.tasklist The Tasklist extension allows for the usage of GitHub Flavored Markdown inspired task lists, following the same syntactical conventions. Enable it via mkdocs.yml: markdown_extensions:\n - pymdownx.tasklist:\n custom_checkbox: true\n The following configuration options are supported: custom_checkbox false This option toggles the rendering style of checkboxes, replacing native checkbox styles with beautiful icons, and is therefore recommended: markdown_extensions:\n - pymdownx.tasklist:\n custom_checkbox: true\n clickable_checkbox false This option toggles whether checkboxes are clickable. As the state is not persisted, the use of this option is rather discouraged from a user experience perspective: markdown_extensions:\n - pymdownx.tasklist:\n clickable_checkbox: true\n The other configuration options of this extension are not officially supported by Material for MkDocs, which is why they may yield unexpected results. Use them at your own risk. See reference for usage: Using task lists Other libraries like KaTeX are also supported and can be integrated with some additional effort. See the Arithmatex documentation on KaTeX for further guidance, as this is beyond the scope of Material for MkDocs. ↩","tokens":3859,"squid":"spider-06","role":"Security Spider","at":1791340224171,"hash":"cef8eac68f57c0d810d2cddf9528083d539560b3"}
{"url":"https://forum.arbitrum.foundation/t/proposal-aip-1-1-lockup-budget-transparency/13360/93","domain":"forum.arbitrum.foundation","title":"Proposal: AIP-1.1 - Lockup, Budget, Transparency - Proposals / Finalized AIPs - Arbitrum","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 5\n\n 3\n\n 3\n\n 2\n\n 2\n\n read \n\n 27\n min\n\n Apr 2023\n\n 89 / 90\n\n Jun 2023\n\n Jun 2023\n\n Load more posts above\n\n post by arbit on Apr 15, 2023\n\n arbit\n\n cattin\n\n Staying tuned for the exciting progress of AIP-1.1 implementation and witness how our vibrant community’s valuable feedback continues to influence the future direction of the Arbitrum Foundation and DAO governance\n\n post by Bob-Rossi on Apr 16, 2023\n\n Bob-Rossi\n\n I have voted “For” on AIP-1.1. There are some items I disagree with (more detail below), however my vote is one that is more based on wanting to look past the initial issues on AIP 1 and to just look at the substance. Based purely on said substance, I believe this is largely a good proposal and is relatively in-line with funding decisions of other DAOs within this space. My disagreements are relatively minor to the scope of the AIP, so voting against with the ask to keep revisiting until he AIP is perfect will just result in unnecessary delays. It really is a situation of “Don’t let Perfect be the enemy of Good”, for better or worse.\nI believe there has been good steps taken towards transparency, however I believe there should have been more provided and would be hesitant to vote for something this vague in the future. Here are some suggestions for the future, ideally to be expanded upon in further communications:\n\nThe operating budget is a nice breakdown, but it is very high-level and lacks detail on where the USD is coming from (assuming ARB sales, but lacks direction on how that will be executed). I’d like to see more expanded on here.\n\nIt is a difficult, near impossible, thing to do considering price swings… but with the price of ARB fluctuating between $1 to over $1.50 recently there is a pretty large gap in the amount of capital provided and the operating budget. Obviously Ecosystem Growth Initiatives will fill a lot of that in, but even at $1 ARB you are looking at $139 Million a year being allocated with no real plans. This will only become more noticeable if the price appreciates. I’m not asking anyone to predict the future, but there should be some more detail on what the plan is in the event of that allocated amount far exceeding expectations. If it is simply more money for public goods - great! Or maybe part of that is ear-marked for operations 5+ years out…? Whatever it ends up being, it should be a little more clear (and as noted above, notes on how the USD will be acquired would help here).\n\nTransparency reports flat out need to be quarterly. Yearly is far too long. Semi-annual I could make a case for, but the initial issues with AIP-1 the leeway for that is no longer there in my opinion. I’ll also add that if the transparency reports will mimic the style of the first one, they will need more detail in them.\n\n post by nguyencuong on Apr 17, 2023\n\n nguyencuong\n\n this will be one of the steps to take the project further , and develop more sustainably , with a large community like today for the project , which is a large number of users supporting the project . Great LFG \n\n post by gauntlet on Apr 17, 2023\n\n gauntlet\n\n Gauntlet is supportive of AIP-1.1.\nWe appreciate the reception to the community’s feedback and the effort put into this proposal. The proposed structure around token lockup and transparency aligns with similar constructs that have worked elsewhere. Furthermore, we approve of the proposed operating budget, as the transparency report will allow the DAO to hold the Foundation accountable for expenditures.\nWe also agree that the Foundation plays a key role with regards to sourcing, negotiating, and onboarding certain vendor relationships. To further reduce ambiguity around this point, we would welcome a decision framework to make it clear to the community when either the Foundation or the DAO should be responsible here. Lastly, as the Foundation will be made up of people close to the Arbitrum ecosystem, we support the proposed plan for ecosystem growth initiatives.\nOverall, we are pleased to see the changes implemented in AIP-1.1 and are excited for things to move forward.\n\n post by cryptopia on Apr 18, 2023\n\n cryptopia\n\n I am happy to see that every care is being taken to ensure the security, stability and growth of this project. However I do share @krst concerns about the lack of specific details on how this proposal is going to be carried out. It is because of his pros and cons analysis of this proposal that I feel confident to vote yes on it.\nI hope that the team will address the concerns that @krst and @Bob-Rossi have raised about this proposal and that we will start seeing much more detailed proposals being put up for a vote in the future. I also agree that transparency reports need to be posted quarterly. This way everyone is kept in the know about what the team is doing and can make proposals that they believe will resolve any issues that they see.\nIf this project is going to survive this volatile market we need to know what challenges the team are facing as soon as possible so that as a group we can propose and vote on the best solutions to overcome them.\n\n post by bakgwei on Apr 18, 2023\n\n bakgwei\n\n I appreciate the rework for this one as well - and just cast my vote.\n\n post by nguyentuhoangliem on Apr 24, 2023\n\n nguyentuhoangliem\n\n Mate you can’t just divide the entire General and Admin budget by headcount, it includes way more than just salaries - they even say it includes insurance, legal and other operating costs right in the post.\nBy your logic, every employee at Wendys must be making like $200k\n\n post by Pekosta on Apr 25, 2023\n\n Pekosta\n\n good iniciative is great for the project\n\n post by Octavio on Apr 26, 2023\n\n Octavio\n\n This is a great step to a brighter future for #ARB. Lets gooooo\n\n post by Oxytocin on Apr 28, 2023\n\n Oxytocin\n\n With the Snapshot temperature check passing a little over a week ago, I was wondering if/when this proposal would move on to tally. Both AIP 1.1 and 1.2 seem to have passed with overwhelmingly positive results, so I think we’re ready for the real onchain vote with no more major revisions!\n\n Proposal: AIP-1.2 - Foundation and DAO Governance\n\n 16 days later\n\n post by Damboy on May 14, 2023\n\n Damboy\n\n The lockup mechanism and gradual release of tokens over time ensure a responsible approach to managing the funds. The transparency reports will be crucial in building trust and ensuring the funds are utilized in the best interest of the community. It’s great to see a focus on ecosystem growth and strategic partnerships as well. Overall, this proposal demonstrates a commitment to transparency, accountability, and responsible financial management.\n\n post by theenlightened on May 14, 2023\n\n theenlightened\n\n Oxytocin\n\n @Arbitrum what is going on with Arbitrum Foundation? This deafening silence could cause disinterest. What is the issue exactly? At least communicate with the community.\nPlease attend to the question above\n\n 18 days later\n\n post by fred on Jun 2, 2023\n\n fred\n\n The engineering for this proposal is now complete and available at ArbitrumFoundation/governance PR #44\nThis includes the code for the lockup contract as well as an audit report for it Trail of Bits Audit Report.\nThis should be going live for a vote soon, but wanted to first share it for discussion.\n\n post by fred on Jun 6, 2023\n\n fred\n\n It is now live for an on-chain vote Tally | Arbitrum Proposal\nEdited update:\nThe previous proposal was misconfigured, the correctly setup one can be viewed at Tally | Arbitrum Proposal\n\n post by Griff on Jun 9, 2023\n\n Griff\n\n i see a second vote is going up for this… so we should just ignore the first vote right?\n\n Griff Green - Delegate Communication Thread\n\n post by Goodo on Jun 10, 2023\n\n Goodo\n\n yes, that seems like a reasonable proposition.\n\n post by Goodo on Jun 10, 2023\n\n Goodo\n\n niklas67\n\n Did you read the later explanations of the whole situation.\n\n 8 days later\n\n post by zeydrm on Jun 18, 2023\n\n zeydrm\n\n So I’m considered about the Budget Plan. As you said remaining 7% of ARB tokens will be released like total of x million tokens over each for 4 years but in the mentioned plan its just concerns only 36m? No information has been given about what will happen to the rest. I hope Arbitrum will clarifies this.\n\n post by ITUblockchain on Jun 21, 2023\n\n ITUblockchain\n\n First of all, we would like to thank Arbitrum for updating AIP 1.1 and making the confusing explanation clear about timestamps in the vesting smart contract and budget allocation transparency previously stated. The update also clarified the questions of delegators who stayed abstain for these reasons. Moreover, there are a few points we would like to make concerning the proposal.\n1.Smart Contract Lockup\nWe believe that having control over the budget and easy access to funds in an emergency are critical for the DAO. With this planning, we believe that spreading the token locks over time is the best option. As an outcome, the community’s trust in Arbitrum about the budget was maintained. However, we believe that the budget allocation plan is lacking in details; we expect that this problem will be resolved in the future thanks to the transparency reports from Arbitrum.\n2.Operating Budget\nArbitrum promises to publish a transparency report if it is determined that the budget is not being handled as stated in the plan. Because the budget distribution lacks sufficient clarity, we believe that transparency reports must be published. We are in favor of doing so.\n3.Ecosystem Growth Initiatives\nPartnerships, grants, and events mentioned in the plan will undoubtedly foster ecosystem growth. We support Arbitrum’s budget for the growth of its ecosystem; we simply hope that they are clear and honest and do not end up changing the budget.\n4.Transparency Reports\nIt is a fact that these reports must exist for transparency monitoring. Arbitrum’s decision to endorse this approach in response to community and online forum requests is a wise one. Despite the fact that we do not believe that there is a problem right now, we want the reports to be more in-depth in the future.We applaud Arbitrum for creating solutions in accordance with the community’s preferences and anticipate that it will keep moving in that direction.\nWe looked at the idea and came to the conclusions we did. Therefore, we made the decision to vote “for”. Again, many thanks to Arbitrum.\nThe flood we posted for AIP 1.1 and AIP 1.2 during the Snapshot vote: https://twitter.com/itublockchain/status/1648989259712348160?s=46&t=hGD89a6tl7pW8rFWA7BnNw\n\n 19 days later\n\n Closed on Jul 11, 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 Clarity around the ratification of AIP-1\n\n Proposals\n\n 46\n\n 26.0k\n\n Apr 2023\n\n AIP-1: Arbitrum Improvement Proposal Framework\n\n Archived Proposals\n\n snapshot,failed\n\n 107\n\n 38.4k\n\n Apr 2023\n\n Continued Funding for the Arbitrum Foundation\n\n Finalized AIPs\n\n 37\n\n 2.0k\n\n Jul 15\n\n [Non-Constitutional] Funds to Bolster Foundation’s Strategic Partnerships Budget\n\n Finalized AIPs\n\n 103\n\n 2.9k\n\n Oct 2024\n\n Proposal: Return 700M $ARB to the DAO Treasury\n\n Archived Proposals\n\n snapshot,failed\n\n 53\n\n 16.2k\n\n Apr 2023","tokens":2814,"squid":"spider-07","role":"Council Spider","at":1791340231925,"hash":"e86f41652fed6cf28a362679906cf7690397a2e9"}
{"url":"https://squidfunk.github.io/mkdocs-material/setup/setting-up-social-cards/","domain":"squidfunk.github.io","title":"Setting up social cards - Material for MkDocs","text":"Setting up social cards¶ Material for MkDocs can automatically create beautiful social cards for your documentation, which appear as link previews on social media platforms. You can select from several pre-designed layouts or create custom layouts to match your unique style and branding. How to build custom social cards by @james-willett – 24m – Learn how to create entirely custom social cards perfectly matching your branding for each page automatically! Social card of our formatting reference Configuration¶ Built-in social plugin¶ 8.5.0 create-social-cards The built-in social plugin automatically generate a custom preview image for each page. Install all dependencies for image processing and add the following lines to mkdocs.yml: plugins:\n - social\n For a list of all settings, please consult the plugin documentation. The site_url setting must be set Note that you must set site_url when using the social plugin, or the generated cards will not be correctly linked. Social media services like X and Facebook demand that social previews point to an absolute URL, which the plugin can only compute when site_url is set. Example: site_url: https://example.com\n Usage¶ If you want to adjust the title or set a custom description for the social card, you can set the front matter title and description properties, which take precedence over the defaults, or use: cards_layout_options.title cards_layout_options.description Choosing a font¶ Some fonts do not contain CJK characters, like for example the default font, Roboto. In case your site_name, site_description, or page title contain CJK characters, choose another font from Google Fonts which comes with CJK characters, e.g. one from the Noto Sans font family: Chinese (Simplified)Chinese (Traditional)JapaneseKorean plugins:\n - social:\n cards_layout_options:\n font_family: Noto Sans SC\n plugins:\n - social:\n cards_layout_options:\n font_family: Noto Sans TC\n plugins:\n - social:\n cards_layout_options:\n font_family: Noto Sans JP\n plugins:\n - social:\n cards_layout_options:\n font_family: Noto Sans KR\n Changing the layout¶ 9.7.0 If you want to use a different layout for a single page (e.g. your landing page), you can use the social front matter property together with the cards_layout key, exactly as in mkdocs.yml: ---\nsocial:\n cards_layout: custom\n---\n\n# Page title\n...\n You can apply those changes for entire subtrees of your documentation, e.g., to generate different social cards for your blog and API reference, by using the built-in meta plugin. Parametrizing the layout¶ 9.7.0 Besides changing the entire layout, you can override all options that a layout exposes. This means you can parametrize social cards with custom front matter properties, such as tags, date, author or anything you can think of. Simply define cards_layout_options: ---\nsocial:\n cards_layout_options:\n background_color: blue # Change background color\n background_image: null # Remove background image\n---\n\n# Page title\n...\n You can apply those changes for entire subtrees of your documentation, e.g., to generate different social cards for your blog and API reference, by using the built-in meta plugin. Disabling social cards¶ 9.7.0 If you wish to disable social cards for a page, simply add the following to the front matter of the Markdown document: ---\nsocial:\n cards: false\n---\n\n# Page title\n...\n Customization¶ 9.7.0 Layer 0 Layer 1 Layer 2 Layer 3 Layer 4 Layer 5 Social cards are composed of layers, analogous to how they are represented in graphic design software such as Adobe Photoshop. As many layers are common across the cards generated for each page (e.g., backgrounds or logos), the built-in social plugin can automatically deduplicate layers and render them just once, substantially accelerating card generation. The generated cards are cached to ensure they are only regenerated when their contents change. Layouts are written in YAML syntax. Before starting to create a custom layout, it is a good idea to study the pre-designed layouts, in order to get a better understanding of how they work. Then, create a new layout and reference it in mkdocs.yml: layouts/custom.yml mkdocs.yml size: { width: 1200, height: 630 }\nlayers: []\n plugins:\n - social:\n cards_layout_dir: layouts\n cards_layout: custom\n debug: true\n Note that the .yml file extension should be omitted. Next, run mkdocs serve, and see how the .cache directory is populated with the generated cards. Open any card in your editor, so you can see your changes immediately. Since we haven't defined any layers, the cards are transparent. The following sections explain how to create custom layouts. Size and offset¶ Each layer has an associated size and offset, which is defined in pixels. The size is defined by a width and height property, and the offset by x and y properties: size: { width: 1200, height: 630 }\nlayers:\n - size: { width: 1200, height: 630 }\n offset: { x: 0, y: 0 }\n If the size is omitted, it defaults to the size of the layout. If the offset is omitted, it defaults to the top left corner, which is the default origin. Saving the layout and reloading renders: The layer outline and grid are visible because we enabled debug mode in mkdocs.yml. The top left shows the layer index and offset, which is useful for alignment and composition. Origin¶ 9.7.0 The origin for the x and y values can be changed, so that the layer is aligned to one of the edges or corners of the layout, e.g., to the bottom right corner of the layout: size: { width: 1200, height: 630 }\nlayers:\n - size: { width: 1200, height: 630 }\n offset: { x: 0, y: 0 }\n origin: end bottom\n The following table shows the supported values: Origin start top center top end top start center center end center start bottom center bottom end bottom Supported values for origin Backgrounds¶ Each layer can be assigned a background color and image. If both are given, the color is rendered on top of the image, allowing for semi-transparent, tinted backgrounds: Background colorBackground imageBackground image, tinted size: { width: 1200, height: 630 }\nlayers:\n - background:\n color: \"#4051b5\"\n size: { width: 1200, height: 630 }\nlayers:\n - background:\n image: layouts/background.png\n size: { width: 1200, height: 630 }\nlayers:\n - background:\n image: layouts/background.png\n color: \"#4051b5ee\" \n The color value can be set to a [CSS color keyword], or a 3, 4, 6 or 8 letter HEX color code, allowing for semi-transparent layers. Background images are automatically scaled to fit the layer while preserving aspect-ratio. Notice how we omitted size and offset, because we want to fill the entire area of the social card. Typography¶ Now, we can add dynamic typography that is sourced from Markdown files - this is the actual raison d'être of the built-in social plugin. Jinja templates are used to render a text string that is then added to the image: size: { width: 1200, height: 630 }\nlayers:\n - size: { width: 832, height: 310 }\n offset: { x: 62, y: 160 }\n typography:\n content: \"{{ page.title }}\" \n align: start\n color: white\n line:\n amount: 3\n height: 1.25\n font:\n family: Roboto\n style: Bold\n This renders a text layer with the title of the page with a line height of 1.25, and a maximum number of 3 lines. The plugin automatically computes the font size from the line height, the number of lines, and font metrics like ascender and descender.1 This renders: Overflow¶ If the text overflows the layer, there are two possible behaviors: either the text is automatically truncated and shortened with an ellipsis, or the text is automatically scaled down to fit the layer: # If we use a very long headline, we can see how the text will be truncated\n Ellipsis Shrink While truncating with an ellipsis is the default, auto-shrinking can be enabled by setting overflow to shrink: size: { width: 1200, height: 630 }\nlayers:\n - size: { width: 832, height: 310 }\n offset: { x: 62, y: 160 }\n typography:\n content: \"{{ page.title }}\"\n overflow: shrink\n align: start\n color: white\n line:\n amount: 3\n height: 1.25\n font:\n family: Roboto\n style: Bold\n Alignment¶ Text can be aligned to all corners and edges of the layer. For example, if we want to align the text to the middle of the layer, we can set align to start center, which will render as: The following table shows the supported values: Alignment start top center top end top start center center end center start bottom center bottom end bottom Supported values for text alignment Font¶ The built-in social plugin integrates with Google Fonts and will automatically download the font files for you. The font property accepts a family and style property, where the family must be set to the name of the font, and the style to one of the supported font styles. For example, setting family to Roboto will automatically download the following files: .cache/plugins/social/fonts\n└─ Roboto/\n ├─ Black.ttf\n ├─ Black Italic.ttf\n ├─ Bold.ttf\n ├─ Bold Italic.ttf\n ├─ Italic.ttf\n ├─ Light.ttf\n ├─ Light Italic.ttf\n ├─ Medium.ttf\n ├─ Medium Italic.ttf\n ├─ Regular.ttf\n ├─ Thin.ttf\n └─ Thin Italic.ttf\n In that case, the author can use Bold or Medium Italic as the style. If the font style specified in the layer is not part of the font family, the font always falls back to Regular and prints a warning in debug mode, as Regular is included with all font families. Icons¶ Authors can leverage the full range of icons that are shipped with Material for MkDocs, or even provide custom icons by using theme extension and going through the process described in the guide on additional icons. Icons can even be tinted by using the color property: size: { width: 1200, height: 630 }\nlayers:\n - background:\n color: \"#4051b5\"\n - size: { width: 144, height: 144 }\n offset: { x: 992, y: 64 }\n icon:\n value: material/cat\n color: white\n This will render the icon in the top right corner of the social card: The possibilities are endless. For example, icons can be used to draw shapes like circles: size: { width: 1200, height: 630 }\nlayers:\n - background:\n color: \"#4051b5\"\n - size: { width: 2400, height: 2400 }\n offset: { x: -1024, y: 64 }\n icon:\n value: material/circle\n color: \"#5c6bc0\"\n - size: { width: 1800, height: 1800 }\n offset: { x: 512, y: -1024 }\n icon:\n value: material/circle\n color: \"#3949ab\"\n This will add two circles to the background: Tags¶ The new built-in social plugin gives full flexibility of the meta tags that are added to your site, which are necessary to instruct services like X or Discord how to display your social card. All default layouts use the following set of tags, which you can copy to your layout and adapt: definitions:\n\n - &page_title_with_site_name >-\n {%- if not page.is_homepage -%}\n {{ page.meta.get(\"title\", page.title) }} - {{ config.site_name }}\n {%- else -%}\n {{ page.meta.get(\"title\", page.title) }}\n {%- endif -%}\n\n - &page_description >-\n {{ page.meta.get(\"description\", config.site_description) or \"\" }}\n\ntags:\n\n og:type: website\n og:title: *page_title_with_site_name\n og:description: *page_description\n og:image: \"{{ image.url }}\"\n og:image:type: \"{{ image.type }}\"\n og:image:width: \"{{ image.width }}\"\n og:image:height: \"{{ image.height }}\"\n og:url: \"{{ page.canonical_url }}\"\n\n twitter:card: summary_large_image\n twitter:title: *page_title_with_site_name\n twitter:description: *page_description\n twitter:image: \"{{ image.url }}\"\n Note that this example makes use of YAML anchors to minify repetition. The definitions property is solely intended for the definition on aliases that can then be referenced with anchors. Are you missing something? Please open a discussion and let us know! If the plugin would require the author to specify the font size and line height manually, it would be impossible to guarantee that the text fits into the layer. For this reason we implemented a declarative approach, where the author specifies the desired line height and number of lines, and the plugin computes the font size automatically. ↩","tokens":2977,"squid":"spider-06","role":"Security Spider","at":1791340234189,"hash":"8574d0737831d008c4da93667fd54cdbe6d0ee9e"}
{"url":"https://forum.arbitrum.foundation/t/proposal-aip-1-1-lockup-budget-transparency/13360","domain":"forum.arbitrum.foundation","title":"Proposal: AIP-1.1 - Lockup, Budget, Transparency - Proposals / Finalized AIPs - Arbitrum","text":"The Arbitrum Foundation notified the Security Council on the need to perform a potential Emergency action. Following a review of the details and known risks, the Security Council decided to execute the upgrade and it was completed at 11:30 EST on 2nd October 2026.\nThis report provides an overview of the risks that required the Security Council Action:\n\nAdd a permissionless guard for the One-Step Proof of BoLD on Arbitrum One\n\nTemporarily pause activation of new Stylus contracts on Arbitrum One & Nova\n\nKey point: To date, known bugs for Stylus primarily impact chain liveness (e.g., denial of service attacks) and do not put any user funds at risk.\nWhy was this action taken\nLet’s take this opportunity to explain why action was taken on two separate issues concerning BoLD and Stylus.\nInstalling the guard for One-Step Proof of BoLD. Given the rise of AI-assisted attacks, we have implemented a precautionary approach that allows anyone to pause settlement of Arbitrum One on Ethereum if there are at least two conflicting answers that pass at the same level in which only one should be valid and pass. This is to halt a class of publicly verifiable and detectable attacks that exploit a bug in the one-step proof. If halted, Arbitrum One will continue to process as normal except that messages from Arbitrum One to Ethereum, such as withdrawals, that are not yet confirmed will have to wait. This provides time for the Security Council to deploy a fix for the bug and resume the rollup.\nPreventing activation of new Stylus contracts. AI-assisted tooling has led to an increasing number of sophisticated attacks on hand-crafted WASM programs that do not use the standard Stylus compiler toolchain. These programs are specifically designed to cause unexpected behaviors such as degrading the chain’s performance for all other users. To date, no attacks have been discovered that permits theft of user funds.\nNew ArbOS releases have patched several reported bugs and known attacks over the past few months, but out of an abundance of caution, we have decided to temporarily pause new activations of Stylus contracts. This was executed as an emergency action to prevent the deployment of new hand-crafted WASM programs that are not yet patched by the current version of ArbOS on the Arbitrum network.\nThe Arbitrum Foundation has informed the Security Council that they will work with the ArbitrumDAO to discuss next steps on the timeline and manner for enabling activation of new Stylus contracts. The Arbitrum community remains confident in the value of Stylus and want to preserve these use cases while taking preventative measures against Stylus-based attack vectors as AI-assisted attack tooling continues to evolve.\nImpact on builders and users\n\nNo new activations. New Stylus contracts cannot be activated during the pause including new versions of existing applications that require activation.\n\nExisting contracts are not paused. Already-active Stylus contracts continue to execute until expiration. This pause does not deactivate them.\n\nThe ArbOS 61 upgrade renewed all active contracts on Arbitrum One, so no currently active contract expires before August 20, 2027.\n\nRenewal via keepalive stays permissionless and is unaffected by the pause.\n\nReactivating an expired contract, or one that needs to be updated after a Stylus version change, is paused.\n\nUsing/calling any activated Stylus contract stays permissionless for all users and developers.\n\nNo impact on EVM. Solidity (EVM) contract deployment and execution are unaffected by this Security Council action.\n\nSecurity Council Actions\nThere are two actions bundled into a single payload:\n\nOne-Step Proof Guard. The L1UpgradeExecutor gives a new pause contract (PauseExecutor) the ability to pause and nothing else. The new pause contract grants the guard (OspSoundnessGuard) PAUSER_ROLE to use it. Anyone can show the guard two conflicting answers to the same step of an open challenge. If the one-step proof accepts both, the guard has the pause contract put Arbitrum One’s settlement to Ethereum on hold.\n\nStylus deactivation. The Security Council called ArbOwner.setWasmActivationGas(2^64 - 1) to raise the Stylus activation gas requirement on Arbitrum One and Nova. This makes activation prohibitively expensive and effectively disables new activations. This is a configuration change and does not require an ArbOS upgrade.\n\nThe Security Council signed the following transactions to update the configuration:\n\nEthereum: Ethereum Transaction Hash: 0x30732bb7d2... | Etherscan\nArbitrum One:\nArbitrum One Transaction Hash: 0x9eb3a4be3b... | Arbitrum One\nArbitrum Nova:\nArbitrum Nova transaction 0x79e0fed470dff7a22059b108e3f8f42eddd2b580a6771594060c4e7326c5f984 | Blockscout\n\nAn external audit was conducted for the OSP Guard contracts. No audit is required for the Stylus deactivation as it is only updating a single parameter in the ArbOS configuration.\n\n Proposal: AIP-1.1 - Lockup, Budget, Transparency \n\n ProposalsFinalized AIPs\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Apr 2023\n\n 1 / 90\n\n Apr 2023\n\n Jun 2023\n\n post by Arbitrum on Apr 5, 2023\n\n Arbitrum\n\n AIP-1.1 - Lockup, Budget, Transparency\nUPDATE:\n\nUPDATE:\n\nAbstract\ntl;dr: This proposal proposes (1) a lockup, (2) a budget and (3) transparency reporting regarding the 7.5% of the $ARB tokens distributed to the Foundation’s “Administrative Budget Wallet”.\nThe Administrative Budget Wallet will be used for covering ongoing administrative and operational costs of The Arbitrum Foundation, payment of service providers, and for the purpose of fostering the growth and development of the Arbitrum ecosystem. In respect to the 7.5% that has been distributed to the Administrative Budget Wallet, a transparency report regarding the 0.5% that has already been transferred is available here.\nThe remaining 7% of tokens will not be used until the approval of a budget, such as the one proposed in this AIP. The proposed budget is in-line with the Foundation’s strategic needs to represent and service the DAO and the allocation is smaller than initial allocations to peer foundations. This AIP proposes placing the 7% outstanding distribution in a smart contract-controlled lockup – linearly unlocking over 4 years – alongside transparency report structures to allow the DAO to periodically monitor expenditures and other activities of the Foundation.\nThe Administrative Budget Wallet will be used in pursuit of the Foundation’s mission statement as set out in the bylaws, which includes financing technical improvements and operations of the Arbitrum network, fostering ecosystem growth through grants to align with partner projects and educational initiatives with in-person and online events.\nMotivation\nOn March 16, 2023, the Arbitrum networks (Arbitrum One and Arbitrum Nova) were decentralized and given to the newly formed Arbitrum DAO. Included in this transition were:\n\nControl of the upgradeability and technical future of the chains\nControl over the DAO treasury\nControl over net fee revenue - i.e. the net difference between fees collected by on-chain operations and L1 fees paid by the Sequencer\nAll Arbitrum social media platforms and accounts\nAbility to elect and, if deemed appropriate, remove the Security Council and Directors\n\nFull responsibility of the chain’s technology, future, and fee revenue were given to the DAO directly. With the DAO assuming those rights and controls, the DAO also assumed the responsibility to fund the ongoing operations of the chains and the costs of running critical chain infrastructure, including RPCs, the Sequencer, and third-party vendors and service contracts.\nWhile there are many activities that the DAO can do directly on-chain, several of its responsibilities require a representative that can engage, maintain and enter new agreements with service providers to run infrastructure that’s critical for the ecosystem (e.g. servers, RPCs, block explorers, data feeds and analytics platforms, and tooling), and ensure that both the chain and the ecosystem have the support they need to continue to thrive. In order to ensure a smooth transition to the DAO without any interruption of services, it was necessary to create an organization that would be ready to service the DAO immediately from launch.\nThe Arbitrum Foundation was created to fill this need, with its mission and scope outlined across the Foundation Bylaws. Prior to the launching of the DAO, The Arbitrum Foundation assumed responsibilities for funding and running chain infrastructure. However, in an arrangement that appears to be unique amongst Arbitrum’s peers, the Foundation does not receive or control the net revenue from transaction fees as this is given directly to the DAO treasury.\nThe DAO is also tasked with fostering and developing the Arbitrum ecosystem, where the DAO may seek to partner with companies or organizations that either cannot or will not publicly negotiate collaborations or partnerships due to confidentiality and other operational requirements. Often, large enterprises negotiate partnership opportunities in private without public processes, where these relationships can only be disclosed after they are agreed upon. Having a well-funded Foundation empowered to represent the DAO in this arena, alongside peer foundations, is in the best interests of the DAO to further develop the growth of the Arbitrum ecosystem.\nRationale\nWhile the need for the Foundation to exist and represent the DAO is well-motivated, it became clear through community discourse around AIP-1 that it was important to have additional insight and restrictions on the Foundation’s initial funding. This AIP-1.1 proposes a detailed set of controls and initiatives to achieve that goal.\n1. Smart Contract Lockup\nThe remaining 7% of ARB tokens in the “Administrative Budget Wallet” will be subject to a four year lockup schedule, unlocking on a continuous linear time basis commencing from the date of the Snapshot approval of AIP-1.1 by the DAO (i.e., a total of 175m $ARB released over each year for 4 years). The lockup will be enforced on-chain through a smart contract which will designate a multisig wallet controlled by The Arbitrum Foundation as the beneficiary. The lockup contract will be configured in a manner that allows the DAO to adjust future funding and/or modify the unlock schedule.\n2. Operating Budget\nBelow is a proposed annual operational budget for the first year of the Foundation. While the operational costs are denominated in USD, the expectation is that approximately half will be paid in USD and half will be paid in locked $ARB tokens.\nAs this will be the first year of the Foundation’s operation and as the Foundation is still young at the time of this AIP, it goes without saying that these are estimates with the expectation that this will be an upper bound on the operational costs for the first 12 months. The transparency reports described in the next section will be an opportunity to track the actual expenses against the budgeted categories and keep the community informed.\n\nOperating Budget\n\nCost ($USD)\n\nGeneral and Administrative\n$16,000,000\n\nR&D\n$9,000,000\n\nTechnical Infrastructure\n$5,000,000\n\nEvents, Marketing & Communications\n$6,000,000\n\nTotal - Next Twelve Months\n$36,000,000\n\n(50% $USD/50% $ARB)\n\n*The General and Administrative line-item includes personnel, contractors, legal, insurance and other operational costs. As of the date of this AIP, the Foundation currently has five full-time contributors, 8 contractors, and the Security Council engaged to support the Arbitrum ecosystem. The Foundation’s budget anticipates the need to hire an additional 15 full-time contributors across technical, growth and community functions over the course of this year.\nThis operating budget presents best-faith estimates of the Foundation’s anticipated budgetary needs which may be subject to change.\n3. Ecosystem Growth Initiatives\nAny additional funds released in compliance with the lock-up schedule above will be made available, but not necessarily deployed, to opportunistically pursue ecosystem growth opportunities and strategic partnerships on behalf of the DAO. The expectation is that the vast majority of ecosystem growth funds will be paid in tokens, and thus will not require the Foundation to sell any tokens. Wherever reasonable, the Foundation will include additional lockups and/or vesting when making distributions in tokens.\nThe Mission Statement in the Foundation’s bylaws highlights the varied nature of the opportunities the Foundation intends to pursue, and a set of KPIs that can track all of these opportunities being developed. The basis of those KPIs will stem from a focus on onboarding and growing both the developer and user base of the Arbitrum ecosystem, attracting best-in-class infrastructure providers to the network, expanding across various industries, use-cases and scope of projects that engage with Arbitrum technology. The ultimate goal of the Foundation is to continue to foster the development of the technology and expand the Arbitrum ecosystem globally.\nIn addition to the Foundation’s processes for selecting grants, it is important to note that the DAO maintains control over the 3.527 billion $ARB and has the ability to distribute any additional grants as it sees fit. Additionally, should the DAO choose, it has the ability to trigger the inflation of the total supply of $ARB which will supplement the on-chain DAO treasury with 2% growth of the total supply of $ARB each year.\n4. Transparency Reports\nThe Foundation understands and agrees that the community should have oversight across how these funds are being utilized to gain comfort that spending is in the interest of the community. In furtherance of this goal, the Foundation is committed to providing a comprehensive annual report and a semi-annual progress update. This will provide the community with a better understanding of the Foundation’s expenditures, balance sheet and its pursuit of ecosystem growth opportunities alongside partnership developments, as well as the various internal and external committees and stakeholders that are involved in the decision making process.\nThe Foundation is continuing to build out its internal personnel to service grant requests and has already engaged a DAO service provider to assist with the administrative components of servicing grants. The Foundation is also talking with a number of different external service providers to assist in both the review and diligence processes.\nThe financial element of these transparency reports will include a breakdown of operational costs incurred while running the Foundation, including infrastructure spending for the Arbitrum chains, events, community building efforts, grants, etc.\nIn addition to the aforementioned reports, the Foundation is providing an initial transparency report alongside this AIP covering all major actions and decisions the Foundation made during set-up, including the costs incurred up until now, which can be found here.\nSteps to Implement\n\nFoundation to deploy smart contract vesting wallet in the specified configuration and transfer 700 million $ARB to it.\nFoundation to implement all processes described in this AIP.\n\nTimeline\nThis AIP-1.1 shall be posted on the DAO forum and will have at least a 72-hour period for DAO comments and input. After the end of the 72-hour period and appropriate updates incorporating DAO feedback, this AIP-1.1 will be posted for vote on Snapshot for an additional 7 days.\n\n Proposal: Return 700M $ARB to the DAO Treasury\n\n AIP-1: Arbitrum Improvement Proposal Framework\n\n Curia Delegate Communication Thread\n\n SEED Latam Delegate Communication Thread\n\n Request for Discussion: Arbitrum Foundation Transparency Standards\n\n 5\n\n 3\n\n 3\n\n 2\n\n 2\n\n read \n\n 27\n min\n\n Pinned on Apr 5, 2023\n\n post by Lenny on Apr 5, 2023\n\n Lenny\n\n So a contractor receives roughly 400k yearly comp? Sounds like a lot\n\n post by DisruptionJoe on Apr 5, 2023\n\n DisruptionJoe\n\nNot only is 7.5% much less than peers (Optimism 25%), but this transparency report is beyond what I have seen at any DAO using this type of structure.\nOverall, this plus the other two documents are a great step forward. I plan to vote in favor of the updates and amendments.\nThank you for addressing the community concerns.\n\n post by Epic on Apr 5, 2023\n\n Epic\n\n this is good work!I am waiting for snapshot\n\n post by niklas67 on Apr 5, 2023\n\n niklas67\n\n You lied and stole 750 million tokens and did spend 50 million, no you want to keep the rest you did steal just get it from a smart contract. Pay it back to the foundation and wait for the votes, you are still trying to keep the stolen coins. The trust for this project is hurt to the core, why should we trust your lies this time.\n\n post by eli_defi on Apr 5, 2023\n\n eli_defi\n\n Leader\n\n DisruptionJoe\n\n Appreciate the perspective! A lot of work went into addressing all of the community feedback! \n\n post by ibuyshite on Apr 5, 2023\n\n ibuyshite\n\n Lenny\n\n from 16M 720k will b for security council member (consists of 12 members , each getting paid 5k per month)\nremains 15.28 million which will be distributed to remaining 5 contributors and 8 contractors … also they are looking to hire total 15 contributor in a year… so even if we look at those numbers …and take 30 members for ex :\nit will 500k+ per person and 400k\n\n post by DreepyGecko on Apr 5, 2023\n\n DreepyGecko\n\n Mate you can’t just divide the entire General and Admin budget by headcount, it includes way more than just salaries - they even say it includes insurance, legal and other operating costs right in the post.\nBy your logic, every employee at Wendys must be making like $200k\n\n post by haku on Apr 5, 2023\n\n haku\n\n Fair point. It would be nice to have some granularity once a quarter regarding these broad buckets they’ve used. When the expenses start rolling in, it would be great to drill down further to ensure that there is no fraudulent or reckless spending.\n\n post by PhiMarHal on Apr 5, 2023\n\n PhiMarHal\n\n DisruptionJoe\n\n Happy with the rework. Quoting Joe’s post for emphasis, as it reflects my thoughts. Good job!\n\n post by hiringdevs.eth on Apr 5, 2023\n\n hiringdevs.eth\n\n I am largely in favor of this proposal, but have a few points I would like clarification around.\n\nMore detailed budget\nThe included operating budget is very large without much clarification around where the funds are going. Can we get more clarity around budgets for payroll, operating expenses, grants, etc.? Understanding the use of the proceeds will also help us understand the expected impact we should see from the expense.\nCommunity governed roles\nCurrently all of the budget is planned to go towards a centralized team of 20 FTEs. Especially as we consider the impact of this program over the next 4 years, it would be good for the community to be able to vote in new representatives for a change in strategy. This could be done in a manner similar to many of the top DAO grants programs where elected delegates are responsible for sourcing, vetting, and allocating grants. Additionally, service orgs like Gauntlet or Reverie could be contracted for specific operations.\nClarity around sale of ARB to USD\nThere is a mention of 50% in USD and 50% in ARB. Can we get clarity around the expected sale timeline for these funds?\n\n post by elwowso on Apr 5, 2023\n\n elwowso\n\n Appreciate the rework. Thank you for the clarity.\n\n post by Alexnguyen1881.Arb on Apr 5, 2023\n\n Alexnguyen1881.Arb\n\n I agree to these amendments and suggestions. If you think that operating expenses only pay salaries for employees, you are wrong. There are many hidden costs and it accounts for 80% of the total cost. Expand your horizons and give the team a chance to build. You want your investment to increase 10 to 20 times and don’t want the core team to have enough operating costs? haha\n\n post by mrbnaik on Apr 5, 2023\n\n mrbnaik\n\n Appreciate the rework. Thank you for the clarity.\n\n post by vikas21st on Apr 5, 2023\n\n vikas21st\n\n let see what effects seen on prices\n\n post by thiccythot on Apr 5, 2023\n\n thiccythot\n\n I am confused about the decision to allocate 750M tokens from the DAO to the Foundation without any governance decision made from the DAO.\nMedium – 16 Mar 23\n690×371 101 KB\nARBITRUM: THE NEXT PHASE OF DECENTRALIZATION\nThere was no mention of any Foundation allocation in the “prospectus” that was distributed before allowing the governance tokens to be traded on exchange and I think this should be viewed as legally binding.\nReneging on the communications set out in the prospectus after investors made financial decisions to purchase the governance token on the open market (by a liquidity provider that the service provider contracted the services of) is undeniably fraudulent.\nimage1000×872 38.5 KB\nGoing forward with ratifying AIP-1 is a clear overreach by the service provider of the DAO’s power. This is an unacceptable precedent to set as it clearly subordinates the DAO to any future decisions by the service provider.\nThe allocation of the 750M tokens sent to the foundation should be sent back to the DAO immediately, the agreement with Wintermute should be nullified, and any tokens sold on the open market on behalf of the foundation should be bought back on the open market.\nThe service providers are subordinate to the decisions of the DAO it until its token vest in a year and can make governing decisions.\nThere needs to be a clear precedent that the governance token holders have full authority and control over the DAO’s treasury resources and any allocations of said resources.\nI am personally open to allocating 7.5% or even more to the foundation, but it must come from the decision of the governance holders, not the service provider.\n\n post by litocoen on Apr 5, 2023\n\n litocoen\n\n welcome these steps to create more transparency and accountability over the Foundation’s operations!\n\n post by 0xYield on Apr 5, 2023\n\n 0xYield\n\n thiccythot\n\n How is that even legal!\nThe space needs to be more transparent with market activities, no wonder the SEC is cracking down on us so much recently!\nIm voting NO!\n\n post by Lenny on Apr 6, 2023\n\n Lenny\n\n ibuyshite\n\n Yes, I was leaving a margin there for whatever. So, you think this is alright ?\n\n Load more posts below","tokens":5576,"squid":"spider-07","role":"Council Spider","at":1791340242258,"hash":"dd754e3fa284d6700acc86a1e7365e177b37b637"}
{"url":"https://offerbook.jup.ag/","domain":"offerbook.jup.ag","title":"Offerbook | Decentralized Lending on Solana","text":"OfferbookBetaSwapTerminalPerpsLendPredictPortfolioYou're on the new Borrow experience.Switch to classicBorrowUSDCat a fixed rate,without liquidations.Borrow USDC Against PEAQBorrow USDC Against PEAQGet USDC without selling your PEAQ. No price-based liquidations.Borrow againstAmount to borrowUSDCfor720 OFFERSRepay 501.29 USDC on Oct 13 · 123,724,399,292 UNK locked until thenFAQDocs ↗Your collateral is locked onchain (PDA) for the full duration of the loan. Neither you nor the lender can access it until the loan is repaid or the collateral is claimed by the lender after maturity (if the borrower doesn't repay).","tokens":154,"squid":"spider-02","role":"Liquidity Spider","at":1791340249041,"hash":"0272c9670a6044feec1d1781d57ca77091a5b29a"}
{"url":"https://offerbook.jup.ag/dashboard","domain":"offerbook.jup.ag","title":"Offerbook | Decentralized Lending on Solana","text":"OfferbookBetaSwapTerminalPerpsLendPredictPortfolioYou're on the new Dashboard experience.Switch to classicDashboardManage your loans and offersConnect your walletNothing is stored — the portfolio is read straight from your wallet.Borrow against anythingPost a token or NFT as collateral and take a fixed-term loan against it — without selling.Lend on your termsThere is no liquidation engine. Collateral only moves if the deadline passes — and then all of it goes to the lender.Multiply your yieldMultiply the carry on yield-bearing collateral by borrowing against it in one position.You're on the new Dashboard experience.Switch to classicDashboardManage your loans and offersConnect your walletNothing is stored — the portfolio is read straight from your wallet.Borrow against anythingPost a token or NFT as collateral and take a fixed-term loan against it — without selling.Lend on your termsThere is no liquidation engine. Collateral only moves if the deadline passes — and then all of it goes to the lender.Multiply your yieldMultiply the carry on yield-bearing collateral by borrowing against it in one position.","tokens":280,"squid":"spider-02","role":"Liquidity Spider","at":1791340259225,"hash":"9f6f1046854cc33900a12cdf97d20d0048726bd6"}
{"url":"https://jup.ag/lend","domain":"jup.ag","title":"Earn Yield on Crypto: Lend Tokens on Solana | Jupiter Lend","text":"Jupiter LendThe most advanced money market on SolanaOur new sUSDai loop is now live. Earn up to 27.15% at max leverage View loop Earn Interest on Your CryptoPassively get yield using Jupiter Lend's Earning Vaults.$614MVaultDepositedEarningsTVLJupUSD----49.8M JupUSD$49.8MUSDC----512M USDC$512MSOL----201K SOL$23.7MUSDT----17.9M USDT$17.9MEURC----4.77M EURC$5,363,730.96USDS----2.98M USDS$2,984,150.18USDG----2.76M USDG$2,764,825.34FAQsJupiter Lend is Jupiter's decentralized finance (DeFi) platform for lending and borrowing crypto. It allows you to use your assets in two main ways:Earn: You can deposit your crypto to lend it out to others and earn passive interest.Borrow: You can use the assets you've deposited as collateral to take out a loan.Jupiter Lend is designed to automatically find the best interest rates for you, whether you are earning or borrowing.Earning and borrowing are two sides of the same system. The \"Earn\" section is for users who want to supply assets to earn interest.The \"Borrow\" section is for users who want to use their supplied assets as collateral to take out a loan.When you supply an asset for lending, you will automatically earn the best possible rate. Supply once and get the best yield, no extra steps needed.Depositing: There are no limits on how much you can deposit.Withdrawing: To ensure Jupiter Lend remains stable and healthy for everyone, there are dynamic limits on how much can be withdrawn at any single moment. These limits grow constantly, allowing for smooth and predictable withdrawals while protecting the system from sudden, large outflows.Like all DeFi platforms, lending and borrowing on-chain has risks. The primary risks are:Smart Contract Risk: The potential for a bug or vulnerability in the code that could be exploited.Market Risk: The value of your deposited or borrowed assets could change dramatically due to market volatility. This is especially important for borrowers, as a drop in your collateral's value could lead to liquidation.Please use this product carefully and never deposit more than you are willing to lose.Check JupLend Guides","tokens":527,"squid":"spider-02","role":"Liquidity Spider","at":1791340269830,"hash":"c79cd4ca9f4f22aafa8ccefe37e4f529f0cbc828"}
{"url":"https://docs.phantom.com/updates","domain":"docs.phantom.com","title":"Updates - Phantom developer documentation","text":"Stay up to date with the latest SDK releases, new features, and important announcements for Phantom developers.\n​Changelog\n​September 28, 2026\n​Updates\n\nPhantom Portal is not accepting new applications. New sign-ups for Phantom Connect SDK access and new app submissions to the Phantom app directory are paused. Existing Portal apps and App IDs are not affected. See the Phantom Portal overview for details.\n\n​September 24, 2026\n​Updates\n\nSui support has been deprecated. See the Sui integration guide for details.\n\n​September 16, 2026\n​Updates\n\nArc provider support. Phantom’s EIP-1193 provider at window.phantom.ethereum supports Arc mainnet and testnet. Enable Testnet Mode to use Arc Testnet. See the EVM integration guide for network details.\n\n​September 3, 2026\n​Updates\n\nRobinhood Chain provider support. Phantom’s EIP-1193 provider at window.phantom.ethereum supports Robinhood Chain mainnet and testnet. Enable Testnet Mode to use Robinhood Chain Testnet. See the EVM integration guide for network details.\n\n​September 1, 2026\n​Updates\n\nMonad support has been deprecated. See the EVM integration guide for details.\n\n​August 24, 2026\n​Updates\n\nSui support deprecation announced. Sui support will be deprecated on September 24, 2026. Do not start new Sui integrations with Phantom. Existing integrations can continue during the transition. See the Sui integration guide for details.\n\n​Week of June 15, 2026\n​Updates\n\nBitcoin provider deprecated. The window.phantom.bitcoin provider has been deprecated. See the Bitcoin integration guide for the affected APIs.\n\n​Week of April 27, 2026\n​Updates\n\nPhantom Connect SDKs v2.0.2. The React SDK, Browser SDK, React Native SDK, and Server SDK have been bumped to v2.0.2. This is a maintenance release with internal package upgrades and dependency updates. To upgrade:\nnpm install @phantom/react-sdk@latest\n\nPhantom CLI, MCP Server, and OpenClaw Plugin v1.2.7. The CLI, MCP Server, and OpenClaw plugin have all received a coordinated patch release that upgrades shared internal packages, improves command argument handling, and returns a typed, schema-validated result from simulate_transaction. To upgrade:\nnpm install @phantom/cli@latest @phantom/mcp-server@latest @phantom/phantom-openclaw-plugin@latest\n\nPublic Connect SDK repository updated. The open-source phantom-connect-sdk repository has been resynced with the latest internal changes so the published source matches the latest npm packages.\n\n​Week of April 20, 2026\n​Updates\n\nApp ID and Client ID support in the OpenClaw plugin. The OpenClaw plugin now accepts PHANTOM_APP_ID and PHANTOM_CLIENT_ID in its configuration. If you registered your app in the Phantom Portal, you can pass your App ID so that tool calls are attributed to your application.\n\nDeferred authentication in the OpenClaw plugin. The plugin no longer attempts to authenticate when it loads. Authentication is deferred until the first tool call, which speeds up agent startup and avoids errors in environments where a browser is not immediately available.\n\nBitcoin provider deprecation notice. The window.phantom.bitcoin provider will be deprecated in an upcoming release. If your app uses the Bitcoin injected provider, plan to migrate off it.\n\nPhantom Connect SDK repo sync. The public phantom-connect-sdk repository has been updated with the latest internal changes. This keeps the open-source codebase in sync with the latest shipped versions of the React SDK, Browser SDK, and React Native SDK. The CLI, MCP Server, and OpenClaw plugin are versioned separately — see the release block below.\n\n​Phantom CLI v1.2, MCP Server v1.2, and OpenClaw Plugin v1.2 — April 2026\nAffected packages: @phantom/cli, @phantom/mcp-server, @phantom/phantom-openclaw-plugin\n​Updates\n\nStricter tool input validation. All tool inputs are now validated with typed schemas instead of loose JSON Schema checks. Invalid parameters are caught earlier with clearer error messages, reducing failed tool calls for both CLI users and AI agents.\n\nMCP Server and OpenClaw Plugin now powered by the CLI. The MCP Server and OpenClaw plugin now import all tools directly from @phantom/cli. This means bug fixes and improvements to any tool are immediately available across all three surfaces — terminal, MCP agents, and OpenClaw agents — without separate releases.\n\nImproved OpenClaw plugin session handling. The OpenClaw plugin now creates its own session manager instance during tool registration, improving reliability when multiple tools run concurrently in the same agent session.\n\nTo upgrade:\nnpm install @phantom/cli@latest @phantom/mcp-server@latest @phantom/phantom-openclaw-plugin@latest\n\nSee the CLI documentation, MCP Server setup guide, and tool reference for details.\n​Phantom CLI v1.0.0, MCP Server v1.1.0, and OpenClaw Plugin v1.1.0 — April 2026\nAffected packages: @phantom/cli, @phantom/mcp-server, @phantom/phantom-openclaw-plugin\n​New features\n\nPhantom CLI. The new @phantom/cli package gives you a standalone terminal interface for your Phantom wallet. Sign transactions, transfer tokens, swap across chains, and trade Hyperliquid perpetuals — all from the command line. Authenticate once with phantom login and your session refreshes automatically. See the CLI documentation for the full command reference.\n\nMCP server mode built in. Run phantom --mcp to start the CLI as an MCP stdio server, exposing every command as a tool for AI agents. The @phantom/mcp-server package (now v1.1.0) wraps this mode in a dedicated binary for agents that need a standalone entry point.\n\n​Updates\n\nUnified architecture. The MCP Server now delegates to the CLI for all wallet operations. This means both surfaces share the same tools and stay in sync automatically — any improvement to the CLI is immediately available to MCP agents.\n\nImproved OpenClaw plugin session handling. The OpenClaw plugin now uses a shared session manager, improving reliability when multiple tools run in the same agent session.\n\nSee the CLI documentation, MCP Server setup guide, and tool reference for details.\n​Phantom Connect SDKs v2.0.1 — Stable release - April 2026\nAffected SDKs: React SDK, Browser SDK, React Native SDK, Server SDK\nThe Phantom Connect SDKs v2.0.1 is the first stable release of the 2.0 line. The v2.0.0-beta.0 introduced OAuth2 PKCE-based authentication; this release graduates that to stable and includes a performance improvement that speeds up wallet connections.\nTo upgrade from the beta or from 1.x:\nnpm install @phantom/react-sdk@latest\n\n​Updates\n\nFaster wallet connections. The SDKs no longer fetch all organization wallets during the connection flow. Wallet resolution now uses a direct tag-based lookup, which reduces latency — especially for accounts with many wallets.\nMore reliable token refresh. Access tokens are now refreshed synchronously before API calls instead of in the background, preventing rare cases where an expired token could reach the server.\n\nSee the React SDK, Browser SDK, React Native SDK, or Server SDK documentation to get started.\n​Phantom MCP Server and OpenClaw Plugin — Text-mode login and usability improvements - April 2026\nThe Phantom MCP Server and OpenClaw plugin now support text-mode authentication and include several usability improvements for AI agents.\n​New features\n\nText-mode login. The phantom_login tool now accepts a displayMode parameter. Set it to \"text\" to receive the device authorization URL and code as text instead of opening a browser — useful for headless or remote environments where a browser is not available.\nVersion reporting. get_connection_status now includes mcpServerVersion (MCP Server) or openClawPluginVersion (OpenClaw plugin) in its response, making it easier to verify which version your agent is running.\n\n​Updates\n\nSimplified tool inputs. The walletId parameter has been removed from get_perp_markets and transfer_tokens — the authenticated wallet is used automatically.\nImproved balance tool guidance. get_token_balances now clarifies that it does not include Hyperliquid perpetuals account balances and suggests calling get_perp_account for perps exposure.\nLazy authentication in OpenClaw. The OpenClaw plugin no longer blocks on authentication during plugin registration. Authentication is deferred until the first tool call, which speeds up agent startup.\n\n​Bug fixes\n\nHyperliquid withdrawal bridge provider. Fixed the bridge provider identifier used in Hyperliquid spot withdrawals, resolving potential failures when bridging funds out.\n\nSee the setup guide and tool reference for full documentation.\n​Phantom MCP Server v1.0.4 and OpenClaw Plugin v1.0.3 - April 2026\nThe Phantom MCP Server v1.0.4 improves session handling, EVM reliability, and Hyperliquid withdrawals. The OpenClaw plugin v1.0.3 picks up the same fixes.\n​Updates\n\nReworked withdraw_from_hyperliquid_spot. Now uses a quote-first flow with dry-run preview before executing. Optionally receive a different token on the destination chain with the buyToken parameter. This brings the total tool count to 29. See the tool reference for details.\nImproved automatic token refresh. Read-only and idempotent tools are now retried automatically after a token refresh; other tools return a simple “retry now” response instead of requiring full re-authentication.\nImproved EVM transaction reliability. transfer_tokens now fetches gas estimates, gas prices, and nonces in parallel, reducing latency and avoiding stale-nonce errors on busy networks.\n\n​Phantom MCP Server v1.0.3 - April 2026\nThe Phantom MCP Server v1.0.3 adds automatic session refresh, Hypercore explorer links, and several reliability improvements.\n​New features\n\nAutomatic session refresh. Expired OAuth sessions are now refreshed automatically in the background. Previously, an expired token required full re-authentication. Now, the MCP Server detects 401 errors, refreshes the token, and retries the request — so your workflow is not interrupted.\nHypercore explorer links. Transaction results for swaps targeting Hypercore/Hyperliquid L1 now include a link to the Hyperliquid explorer.\n\n​Updates\n\nSimplified tool inputs. Several tools no longer require an optional walletId parameter — the authenticated wallet is used automatically.\nOpenClaw plugin. The @phantom/phantom-openclaw-plugin now sends analytics headers and supports dynamic OAuth token refresh, improving session reliability for OpenClaw agents.\n\n​Bug fixes\n\nEVM token transfers. Fixed a race condition in EVM transfers where the transaction nonce was not fetched before signing, which could cause failures under concurrent usage.\n\nSee the setup guide and tool reference for full documentation.\n​Phantom MCP Server v1.0.2 — Stable release - April 2026\nThe Phantom MCP Server v1.0.2 is the first stable release with 28 tools across wallet operations, swaps, and perpetuals trading.\n​What’s new in v1.0\n\nNo fees on swaps. All swaps executed through buy_token and portfolio_rebalance are fee-free — no transaction fees, platform fees, or commission.\nCross-chain swaps. buy_token supports Solana ↔ EVM swaps in both directions, including targeting Hypercore/Hyperliquid.\nPerpetuals trading on Hyperliquid. Full trading lifecycle — open/close positions, manage leverage, view markets and history. See below for details.\nTransaction simulation. simulate_transaction previews asset changes, security warnings, and blocking conditions without submitting on-chain.\nERC-20 allowance checking. get_token_allowance checks whether an approval is needed before a swap.\nReworked Hyperliquid funding flow. deposit_to_hyperliquid and withdraw_from_hyperliquid_spot now use a quote-first flow, support more destination chains (Solana, Ethereum, Base, Arbitrum, Polygon), and can receive non-USDC tokens via the buyToken parameter.\nOpenClaw plugin. The new @phantom/phantom-openclaw-plugin package brings Phantom wallet tools directly into OpenClaw agents.\n\nSee the setup guide and tool reference for full documentation.\n​Phantom MCP Server — Perpetuals trading and transaction simulation (beta) - April 2026\nThese features are now stable in v1.0.2. See the entry above for the latest.\nThe Phantom MCP Server added perpetuals trading on Hyperliquid and transaction simulation in the 1.0.0-beta.0 prerelease, bringing the tool count from 13 to 25.\n​Perpetuals trading on Hyperliquid\nYour AI assistant can now trade perpetual futures on Hyperliquid directly through the MCP Server. New tools cover the full trading lifecycle:\n\nAccount and market data — get_perp_account, get_perp_markets, get_perp_positions, get_perp_orders, and get_perp_trade_history for reading account balances, available markets, open positions, active orders, and historical trades.\nTrading — open_perp_position and close_perp_position for opening and closing positions with configurable leverage, margin type, and order type (market or limit). cancel_perp_order cancels open orders.\nPosition management — update_perp_leverage to change leverage and margin type (cross or isolated) per market.\nFunding — deposit_to_hyperliquid bridges assets to Hyperliquid, transfer_spot_to_perps moves USDC from your spot account into the perps account, and withdraw_from_perps transfers USDC back out.\n\n​Transaction simulation\nThe new simulate_transaction tool previews the effects of a transaction — including expected asset changes, security warnings, and blocking conditions — without submitting anything on-chain. Available for both Solana and EVM transactions.\n​ERC-20 token allowance checking\nThe new get_token_allowance tool returns the ERC-20 allowance granted by an owner to a spender on any supported EVM chain. Use it before a swap to check whether an approval transaction is needed.\nSee the Phantom MCP Server documentation to get started.\n​Phantom MCP Server v1.0 — GA release - April 2026\nSee v1.0.2 above for the latest stable release and cumulative feature list.\nThe Phantom MCP Server has graduated from beta to a stable release. If you were using the 1.0.0-beta.0 prerelease, install the stable version:\nnpx -y @phantom/mcp-server@latest\n\n​Dedicated agent wallets\nAgents now receive their own dedicated wallet when they authenticate, instead of connecting to your personal wallet. This means agents must be funded before they can perform on-chain actions. After authenticating, use get_wallet_addresses to check the agent’s wallet address and send funds to it.\n​Cross-chain swaps\nThe buy_token tool now supports swaps between Solana and EVM chains (Ethereum, Base, Polygon, Arbitrum), in addition to same-chain swaps. Pass a different buyChainId than sellChainId to initiate a cross-chain swap.\n​Phantom Connect SDK — now open source - April 2026\nThe Phantom Connect SDK source code is now publicly available on GitHub at github.com/phantom/phantom-connect-sdk.\nThe repository includes all Phantom Connect packages:\n\nClient SDKs — React SDK, React Native SDK, and Browser SDK for web and mobile wallet integration\nServer SDK — backend wallet creation, transaction signing, and message signing\nMCP Server — the Phantom MCP Server and OpenClaw plugin for AI agent wallet access\nExample apps — production-ready demos for React, React Native, Next.js, Wagmi, and vanilla JS\n\nYou can browse the full implementation, open issues, and submit pull requests.\n​Phantom Connect SDKs v2.0 (beta) - April 2026\nAffected SDKs: React SDK, Browser SDK, React Native SDK\nThe Phantom Connect SDKs are now available as a 2.0.0-beta.0 prerelease with an updated authentication flow. The new auth system uses an OAuth2 PKCE-based flow for improved security and session management.\nTo try the beta, install the prerelease version from npm:\nnpm install @phantom/react-sdk@beta\n\nSee the React SDK, Browser SDK, or React Native SDK documentation to get started.\n​Phantom MCP Server v0.2.4 - March 2026\nThe Phantom MCP server has been updated to v0.2.4 with 3 new tools, bringing the total from 10 to 13.\n​Portfolio rebalancing\nThe new portfolio_rebalance tool lets your AI assistant analyze your current Solana portfolio allocation and rebalance it to target percentages via token swaps. Supports dry-run mode to preview the swap plan before executing.\n​Other new tools\n\nphantom_login — Re-authenticate, switch accounts, or refresh an expired session\npay_api_access — Pay for daily API access when quota is consumed\n\nSee the Phantom MCP server documentation to get started.\n​Phantom MCP server v0.2.1 - March 2026\nThe Phantom MCP server has been updated to v0.2.1 with expanded multi-chain support. The tool set has grown from 5 to 10 tools, adding dedicated EVM transaction signing, EIP-191 and EIP-712 message signing, token balance retrieval, and a connection status check. transfer_tokens now works across both Solana and EVM chains.\nSee the Phantom MCP server documentation to get started.\n​Phantom Connect v1.0.7 - March 2026\nAffected SDKs: React SDK, Browser SDK, React Native SDK\n​New features\nDapp-sponsored transactions\nAll three SDKs now support dapp-sponsored transactions for Solana, enabling double-signing flows where your backend co-signs a transaction before Phantom finalizes it. This is ideal for dapp fee-payer use cases where your app covers transaction fees on behalf of users.\nLearn how to implement dapp-sponsored transactions in the sign-and-send transactions guide for the React SDK, Browser SDK, or React Native SDK.\n​Phantom Cursor plugin - March 2026\nThe Phantom Cursor plugin is now available on the Cursor Marketplace. Install it to give your AI coding agent wallet capabilities, SDK knowledge, and Phantom best practices directly in Cursor.\nThe plugin bundles subagents, skills, rules, and MCP servers into a single install. Your agent can scaffold complete Phantom Connect projects, write integration code that follows best practices, execute wallet operations across Solana, Ethereum, Bitcoin, and Sui, and search Phantom documentation in real time.\nInstall from the Cursor Marketplace or learn more in the Cursor plugin documentation.\n​Phantom Connect v1.0.2 - January 15, 2026\nAffected SDKs: React SDK, Browser SDK, React Native SDK\n​Bug fixes\nDetect account changes when using injected provider\nFixed an issue where the SDK wouldn’t detect when users switch accounts in their injected wallet provider (for example, Phantom extension). The SDK now automatically detects account changes and updates the connection state accordingly.\nImproved wallet detection for mobile wallets\nFixed an issue where mobile wallets weren’t properly detected and displayed in the wallet discovery list. The SDK now correctly detects and displays all available mobile wallets.\nPrevent connection to unsupported networks\nFixed an issue where the SDK would attempt to connect to networks that aren’t supported by certain wallet providers, which could cause connection errors. The SDK now correctly validates network support before attempting connections.\n​December 2025\n​Phantom Connect SDK MCP server\nYour AI coding assistant can now search Phantom documentation directly. The Phantom Connect SDK MCP server gives Cursor, VS Code, Claude, and Claude Code real-time access to our docs for accurate answers while you code. Use the contextual menu on any docs page to auto-install, or check out the Phantom Connect SDK MCP server setup guide.\n​Spending limits\nUsers can now set spending limits when connecting to apps via Phantom Connect. This security feature allows users to control how much an app can spend on their behalf, with on-chain enforcement. Learn more in the spending limits documentation.\n​Phantom Connect SDKs\nThe Phantom Connect SDKs provide a streamlined way to integrate Phantom wallet functionality into your applications. Check out the SDK documentation:\n\nReact SDK - For React web applications\nReact Native SDK - For mobile applications\nBrowser SDK - For vanilla JavaScript applications\nWas this page helpful?","tokens":4950,"squid":"spider-10","role":"Tooling Spider","at":1791340285387,"hash":"c866a7696b6dd6a623b70f703f36aee76a7dced9"}
{"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":"spider-05","role":"Spec Spider","at":1791340299268,"hash":"0a4d8d237f9676beedbc30bb63b30c8bb51ba0e6"}
{"url":"https://akash.network/case-studies/why-astria-moved-its-ai-image-workloads-to-akash-network","domain":"akash.network","title":"Why Astria Moved Its AI Image Workloads to Akash Network","text":"by Joe Deng Case Studies 4 Min. Read Aug 26, 2026 Why Astria Moved Its AI Image Workloads to Akash Network 4 Min. Read Aug 26, 2026 \nby Joe Deng \nCase Study\n\nTL;DR: Astria, a generative image platform for fashion e-commerce and AI headshots, runs its full production pipeline — fine-tuning, inference, and a custom upscaling model — on Akash Network after trying Lambda Labs, AWS, and RunPod. Docker pulls that took 40 to 60 minutes on a previous provider now come up in seconds on Akash’s pre-cached, Kubernetes-on-metal infrastructure.\n\n“Pricing is great, infrastructure is great.” That’s Astria co-founder Alon Burg on why the company runs its production GPU workloads on Akash Network, after trying Lambda Labs, AWS, and RunPod first.\nAstria fine-tunes and runs generative image models at scale for fashion e-commerce and AI headshots. It has been serving production workloads on Akash for over a year: GPU availability, competitive pricing, and the ability to bring Docker images up in seconds instead of an hour all serve to push Akash to be the infrastructure partner to scale alongside Astria.\nKey takeaways\n\nAstria runs production fine-tuning and inference on Akash for AI headshots, avatars, and e-commerce photoshoots\nH100s and H200s serve Astria’s primary workloads, with A100s for cost-efficient processing\nOn a previous competitor, Astria reported Docker pulls of 40 to 60 minutes. On Akash, pre-cached images come up in seconds\nAkash pricing let Astria keep high-spend API customers who demand better prices for volume\n\nWhat does Astria do?\nFounded about four years ago as the first company offering fine-tuning for generative image models, Astria became the go-to provider for training on specific concepts, which powered headshot apps, photoshoot apps, event applications, and photo booths.\nIn the past six months, Astria pivoted toward AI photoshoots for fashion brands. Reference-image models like Nano Banana reduced the need for fine-tuning, so Astria now aggregates frontier image models behind a collaborative workspace built for photographers and creative directors — the people who traditionally ran shoots in Milan but are now increasingly moving brands into AI production workloads.\nAstria also trained its own model to produce super-resolution generations from any given reference; it upscales output while keeping labels, text, and fine details grounded in the real product instead of hallucinating it.\n\nGenerate high-quality, multishot sequences from a single prompt. Complex narrative structures, consistent lighting, and professional camera control are now accessible in one efficient workflow.\nTry it now: astria.ai/prompts\n\nWhat does Astria run on Akash?\n\nAstria runs its full production pipeline on Akash: fine-tuning, inference, and its custom upscaling model. H100s and H200s are used when available to handle the primary workload. A100s were added recently for cost-efficient processing after market price shifts. Astria commits to a reservation baseline capacity for its base workload, then auto-scales with Akash’s spot markets as needed for peak traffic.\nHow does Akash compare to previous hosts?\nProvisioning speed and reliability mattered as much as price. On Akash’s Kubernetes-on-metal, Docker images are often pre-cached, so a deployment that took the better part of an hour elsewhere starts in seconds.\nHow did Akash pricing affect Astria’s business?\nAkash pricing let Astria stay competitive in a market where large API customers demand meaningful discounts. When a customer’s spend gets big enough, they can credibly threaten to run their own GPU infrastructure and workloads. Competitive compute costs let Astria keep those accounts by offering competitive pricing to long-tail customers.\nWhat was hard about migrating to decentralized compute?\nThe hard parts were selecting the right providers, validating network reliability, and configuring quotas so pods weren’t evicted. Astria describes the rest as smooth sailing, with responsive support from the Akash team at all hours. Once the kube-config was set up, operations became routine for both research and production.\n\nAkash has been a tremendous partner and I’m happy to be here with you. The Akash team offers amazing, responsive support at all times of day.\n— Alon Burg, Co-Founder, Astria AI\n\nFAQ\nWhy did Astria switch from AWS, Lambda Labs, and RunPod to Akash Network?+Provisioning speed and price. On a previous competitor, Docker pulls took 40 to 60 minutes; on Akash’s pre-cached, Kubernetes-on-metal infrastructure, deployments start in seconds, at more competitive pricing than the hyperscalers.What GPUs does Astria use for AI image generation on Akash?+H100s and H200s handle Astria’s primary fine-tuning and inference workloads, with A100s added for cost-efficient processing after market price shifts.Is Akash Network reliable enough for production AI workloads?+Yes. Astria has run its full production pipeline — fine-tuning, inference, and a custom super-resolution model — on Akash for over a year, committing a reservation baseline and auto-scaling on Akash’s spot markets for peak traffic.Does using Akash Network actually save money on GPU compute?+Yes. Competitive Akash pricing let Astria retain high-spend API customers who could otherwise threaten to run their own GPU infrastructure, while still offering competitive rates to long-tail customers.What’s difficult about migrating GPU workloads to a decentralized cloud like Akash?+Selecting reliable providers and configuring resource quotas so pods aren’t evicted are the main hurdles. Once that setup is done, Astria describes day-to-day operations as routine, backed by responsive Akash support. \nShare this Case Study\n\nSee how Akash cut costs by 60%. Start with $100 Free Credits.\n\nShare this Case Study\n\nnote\n\ntip\n\nCaution\n\nDanger","tokens":1454,"squid":"spider-03","role":"Compute Spider","at":1791340300618,"hash":"2b24d10e13e84d6d40ef5794346d92a9ec5c3595"}
{"url":"https://forum.across.to/t/the-bridge-across/2097/43","domain":"forum.across.to","title":"The Bridge Across - Proposals - Across Protocol","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 6\n\n 6\n\n 6\n\n 4\n\n 2\n\n read \n\n 22\n min\n\n Mar 11\n\n 41 / 41\n\n May 24\n\n Apr 25\n\n Load more posts above\n\n post by h3rf on Mar 18\n\n post by Bananachain on Mar 20\n\n post by hart_UMA on Mar 26\n\n post by hash_error on Mar 26\n\n post by 0xdoodee on Mar 26\n\n post by acxhldr_52970 on Mar 26\n\n post by hash_error on Mar 26\n\n post by mr.bahama on Mar 27\n\n post by Bananachain on Mar 28\n\n post by TheRealTuna_Across on Mar 28\n\n post by hash_error on Mar 29\n\n post by hart_UMA on Mar 31\n\n post by 0xpotatoooo on Mar 31\n\n post by 0xdoodee on Mar 31\n\n post by sinahab on Apr 1\n\n post by gino1529 on Apr 2\n\n post by TheRealTuna_Across on Apr 3\n\n post by treggs6 on Apr 3\n\n treggs6\n\n An Alternative Path Forward for “The Bridge Across”\nA Venture DAO Framework That Preserves Community Participation, Protects Treasury Value, and Enables Corporate Transition\nPrepared by Seedplex | April 2026\n\nWho are we?\nSeedplex is at the forefront of the pseudo-tokenization of equity built around existing communities. Seedplex was part of the latest Solana Incubator cohort (6 out of 300+ applicants) but we can accommodate other chains fairly easily. Treggs, the CEO and author of this post, has been in crypto since 2016 but really ramped my participation up during DeFi Summer in 2020. They also Co-founded Flash trade in 2023, a pool to peer DEX exchange that really extended the model to offer derivatives on longer tail assets, and ultimately left in order to try and fix the problems traditional tokens have with Seedplex.\nExecutive Summary\nThe Bridge Across proposal aims to transition Across Protocol from a DAO and token structure to a U.S. C-corp, offering ACX holders either an equity exchange or a token buyout at $0.04375. ACX is trading at approximately the buyout price, meaning the market is assigning near-zero value to the equity component of the deal. If the transition proceeds as proposed, the Risk Labs treasury (currently estimated at ~$30M) is likely to be significantly drained as holders opt for the cash exit, leaving AcrossCo with substantially less capital on its balance sheet to fund future growth.\nSeedplex offers an alternative path that achieves the same end goal, a successful corporate transition, while preserving treasury value, keeping long-term holders, and giving exit-seeking investors a fair and orderly way out. The core mechanism is a Venture DAO: an on-chain entity that holds the equity investment (via a SAFE), issues freely tradable non-security Venture Tokens. Once established, it would execute a disciplined buyback strategy over a 3–6 month transition window. Critically, these buybacks are optimized to purchase tokens only below net asset value (NAV), making every buyback strictly accretive to long-term holders as supply is burned and NAV per token rises.\nThe result: investors who want liquidity can exit over time at or near the buyout price. Investors who want to stay gain exposure to Across equity through a familiar token format, with each Venture Token becoming increasingly valuable as sub-NAV buybacks burn supply. At the end of the transition, the remaining treasury executes the SAFE, AcrossCo (Delaware C-corp) receives operating capital, and the community retains exposure through a governance token with no individual SPV paperwork, no minimum thresholds, and no friction.\n\nThe Problem with the Current Proposal\nLoyal Holders Cashed Out at the Bottom\nPerhaps the most troubling aspect of the current proposal is what it means for the community members who believed in Across through the downturn. These holders stayed when the price fell, continued to participate in governance, and maintained conviction in the protocol’s long-term potential. Under The Bridge Across, they are effectively being taken out at the bottom.\nUnless a holder is willing and able to KYC into an SPV, or holds more than 5m ACX to convert directly to equity, the default path is a cash buyout at $0.04375. The very people who stuck around are the ones with the fewest options to continue their journey with Across. This is not a structure that rewards loyalty; it is one that forces loyal participants to exit at what may be the least favorable moment.\nMarket Signal: The Equity Component Is Being Priced at Zero\nACX is currently trading at approximately $0.04375, the exact buyout price offered in The Bridge Across proposal. This is a clear market signal. When a buyout offer exists and the token trades at parity with the cash option, it means the market is ascribing little to no incremental value to the equity exchange path. In other words, the average holder sees no reason to take the equity over the cash.\nThis is a problem for the protocol’s long-term ambitions. A transition where the majority of holders opt for cash rather than equity would undermine the community alignment that AcrossCo is trying to build.\nTreasury Drain Risk\nThe Bridge Across proposal states that the DAO’s liquid assets, roughly equivalent to the current market cap, would finance the buyout. With the treasury estimated at approximately $30M and rational economic incentives pointing holders toward the cash option, there is a meaningful risk that a significant portion of the treasury is consumed by buyouts before the transition is complete.\nEvery dollar that exits the treasury is a dollar that does not appear on AcrossCo’s balance sheet after incorporation. The very entity being created to accelerate growth could be born capital-constrained, the opposite of the intended outcome.\n\nThe Alternative: A Venture DAO Transition\nSeedplex proposes replacing the binary equity-or-cash structure with a Venture DAO, a purpose-built on-chain entity designed to hold traditional assets (equity, SAFEs, or similar instruments) while issuing governance tokens that trade freely in the open market.\nThe transition unfolds in a structured sequence over 3–6 months, designed to protect all participants:\nStep 1: Create the Venture DAO\nA new Venture DAO is established on-chain to serve as the investment vehicle for the Across transition. This DAO is purpose-built: its sole function is to hold and manage the equity position in the newly formed AcrossCo.\nStep 2: Seed the DAO and Issue Venture Tokens\nThe existing DAO treasury assets are transferred into the Venture DAO. ACX tokens are transitioned into Venture Tokens (ACXvt) on a pro-rata basis, accounting for team holdings and total dollar value. The Venture Token begins trading freely, seeded with initial liquidity at approximately $0.04375 to match the buyout price from the original proposal.\nThis step effectively represents a buyout of every circulating token. Every ACX holder receives Venture Tokens anchored to real treasury assets. No one is forced into paperwork, SPVs, or binary choices; just on-chain transactions which we are all familiar with.\nStep 3: Write up a SAFE with AcrossCo\nA SAFE (Simple Agreement for Future Equity) is signed between the Venture DAO and the newly formed AcrossCo. The SAFE specifies a post-money valuation cap and grants the Venture DAO the right to purchase equity using its treasury funds at any point during the 3–6 month transition window.\nThis structure gives the Venture DAO flexibility: it does not need to deploy all capital immediately. Instead, it can execute the SAFE at the end of the transition period, deploying whatever treasury remains after the buyback program concludes.\nStep 4: Disciplined Sub-NAV Buybacks\nDuring the transition window, the Venture DAO deploys a portion of its treasury to execute a TWAP buyback of ACXvt at any price below $0.04375. This is the mechanism that makes the entire structure work:\n\nIf holders want to exit, they can sell their Venture Tokens on the open market at or near the buyout price. The TWAP buyback provides consistent demand.\n\nIf sell pressure is heavy and the price dips below $0.04375, the buyback does not chase the price up. Instead, it buys at a discount, which is strictly accretive to remaining holders. NAV per token rises as tokens are purchased below intrinsic value and burned.\n\nInvestors who panic-sell or need immediate liquidity are the ones penalized by selling below NAV. Long-term holders are the beneficiaries, as each burned token concentrates more value into fewer hands.\n\nThe buyback pace is optimized to absorb sell flow without artificially inflating the price. It acts as a soft floor, not a wall.\nStep 5: SAFE Execution and Finalization\nAt the end of the 3–6 month window, the SAFE is executed. Whatever treasury balance remains after buybacks is deployed to purchase equity in AcrossCo. Venture Token holders now govern a DAO whose treasury contains equity in a growth-stage company. The tokens continue to trade freely.\nIf a future liquidity event occurs (IPO, acquisition, or similar), proceeds flow back to the Venture DAO treasury, and qualified token holders can redeem proportionally by burning their tokens.\n\nWhy This Path Is Superior\nTreasury Preservation\nUnder the current proposal, every dollar used for buyouts is a dollar lost to AcrossCo. Under the Venture DAO model, treasury dollars used for sub-NAV buybacks are not lost. They are converted into burned tokens, concentrating value for remaining holders. The remaining treasury is then deployed into the SAFE. The total value is preserved; it simply shifts between equity and token supply reduction.\nAccretive Mechanics for Long-Term Holders\nEvery sub-NAV buyback mathematically increases the NAV per outstanding Venture Token. This means holders who believe in Across and choose to stay are actively rewarded by the exit of short-term holders. At the end of the 6-month window, each remaining Venture Token should be worth more than $0.04375, not less. This is a fundamentally different incentive structure from the current proposal, where early exiters and long-term believers are treated identically.\nOrderly, Market-Driven Exit for Liquidity Seekers\nInvestors who want out can sell on the open market throughout the transition. There is no 6-month waiting period for a buyout window to open. There is no administrative overhead. The TWAP provides sustained bid-side liquidity. If there is concentrated sell pressure, the price may temporarily dip below the buyout equivalent, but this is a feature, not a bug. It penalizes forced selling and rewards patience, creating a natural sorting mechanism between short-term and long-term participants.\nNo Minimum Thresholds, No SPV Friction\nEvery token holder, regardless of size, maintains the same access and exposure. There is no 250,000 ACX minimum. There is no SPV enrollment process. There is no KYC requirement simply to hold. There are no separate tiers for large and small holders. Community members hold a token, and that token governs a treasury that holds equity. The loyal holders who believed in Across through the downturn are not forced to exit at the bottom; they can continue their journey alongside the protocol as it grows.\nAcrossCo Still Gets What It Needs\nThe end state is identical to what The Bridge Across envisions: AcrossCo is a properly incorporated U.S. C-corp with institutional credibility, enforceable contracts, and structured revenue agreements. The difference is how it gets there. Instead of a binary buyout that drains the treasury, Across receives capital through a SAFE execution funded by whatever remains after the market has sorted its participants. The community stays engaged. The balance sheet stays healthy.\n\nSide-by-Side Comparison\n\nDimension\nThe Bridge Across\nVenture DAO (Seedplex)\n\nTreasury Impact\nLikely drained significantly by cash buyouts\nPreserved; sub-NAV buybacks are accretive, remainder funds the SAFE\n\nExit Mechanism\n6-month buyout window at fixed price ($0.04375)\nContinuous open-market liquidity with TWAP buyback support\n\nEquity Access\nDirect (>5M ACX) or via SPV (250K+ ACX minimum)\nAll holders via Venture Token; no minimums, no SPV\n\nHolder Incentives\nIdentical treatment for exiters and believers\nSub-NAV buybacks reward long-term holders; NAV rises as supply shrinks\n\nCommunity Continuity\nToken ceases to exist; holders become shareholders or exit\nToken continues trading freely; community structure preserved\n\nCorporate Outcome\nAcrossCo formed; treasury funds buyout\nAcrossCo formed; SAFE funded by remaining treasury\n\nComplexity for Holders\nEquity exchange paperwork or buyout claim\nHold a token; same experience as today\n\nCash on Balance Sheet\nReduced by buyout outflows\nMaximized by deploying only remaining treasury into SAFE\n\nIllustrative Scenario\nConsider the following simplified scenario to illustrate the mechanics:\nStarting Conditions: The Venture DAO is seeded with $30M in treasury assets. Venture Tokens are issued and begin trading at $0.04375 (the NAV-equivalent price). The SAFE is signed with AcrossCo.\nDuring the Transition (Months 1–6): Around 45% of circulating supply token holders decide to exit. They sell their Venture Tokens on the open market. The TWAP buyback absorbs this sell pressure, purchasing tokens at an average price of $0.038 (below NAV). Roughly $12M in treasury is deployed on buybacks, burning a significant portion of the token supply.\nAt the End of Month 6: The remaining treasury balance of ~$18M is deployed to execute the SAFE with AcrossCo. The remaining Venture Tokens, now representing a smaller supply, govern a treasury that holds $18M worth of equity in AcrossCo. NAV per token has risen to $0.04866 due to the accretive buybacks.\nThe Outcome: AcrossCo receives $18M in growth capital. Exiting holders received liquidity at or near the buyout price. Remaining holders own a more concentrated, more valuable position. The community structure is intact.\n\nConclusion\nThe Bridge Across proposal correctly identifies the need for Across to evolve beyond a pure DAO and token structure. The motivation is sound: institutional credibility, enforceable contracts, and a path to sustainable growth all require a corporate wrapper. Seedplex does not dispute this.\nWhat Seedplex offers is a better mechanism for getting there. The Venture DAO model preserves the treasury, rewards long-term alignment, provides orderly liquidity for those who want it, and eliminates the structural friction that currently pushes smaller holders toward the exit. It accomplishes everything The Bridge Across sets out to do while keeping the community on the same side of the table.\nOn the operational side of things, we believe this approach will carry significantly lower costs across the board as the legal work and entity set up to enable the Venture Token is what Seedplex has already worked on for the last year.\nAcross deserves a transition that is as well-engineered as the protocol itself. We believe this is it.\n**I encourage all people who are even curious about an alternative to the current proposal to vote “No” on this. I think it’s definitely worth a discussion. Feel free to respond this post in the forum and/or reach out privately to me through Telegram (@Treggs61).\n\n 21 days later\n\n post by chuck704 on Apr 25\n\n chuck704\n\n I am interested in participating in the go-private transaction but logistically need to come in via fiat not tokens. Is there an avenue for me to do this?\n\n 1 month later\n\n Closed on May 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 The Across token buyout portal is now live\n\n Updates\n\n Updates\n\n 19d\n\n Risk Labs Retroactive Funding and Future Development\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 5\n\n Sep 2024\n\n Risk Labs Funding Proposal for Growth, Expansion and Across v3\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 11\n\n Oct 2023\n\n Across ($ACX) Community Initial Liquidity Proposal\n\n Passed Proposals\n\n Passed Proposals\n\n 49\n\n Nov 2022\n\n Across Token Launch Proposal\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 214\n\n May 2022","tokens":3988,"squid":"spider-09","role":"Bridge Spider","at":1791340302502,"hash":"0afdbfa2c4e28d68bfd76c7c96303c9a7a62ef1d"}
{"url":"https://eips.ethereum.org/EIPS/eip-214","domain":"eips.ethereum.org","title":"EIP-214: New opcode STATICCALL","text":"🎉 Final\n\n Standards Track: Core\n\n EIP-214: New opcode STATICCALL\n\n Authors\n Vitalik Buterin <vitalik@ethereum.org>, Christian Reitwiessner <chris@ethereum.org>\n\n Created\n 2017-02-13\n\n Simple Summary\n\nTo increase smart contract security, this proposal adds a new opcode that can be used to call another contract (or itself) while disallowing any modifications to the state during the call (and its subcalls, if present).\n\n Abstract\n\nThis proposal adds a new opcode that can be used to call another contract (or itself) while disallowing any modifications to the state during the call (and its subcalls, if present). Any opcode that attempts to perform such a modification (see below for details) will result in an exception instead of performing the modification.\n\n Motivation\n\nCurrently, there is no restriction about what a called contract can do, as long as the computation can be performed with the amount of gas provided. This poses certain difficulties about smart contract engineers; after a regular call, unless you know the called contract, you cannot make any assumptions about the state of the contracts. Furthermore, because you cannot know the order of transactions before they are confirmed by miners, not even an outside observer can be sure about that in all cases.\n\nThis EIP adds a way to call other contracts and restrict what they can do in the simplest way. It can be safely assumed that the state of all accounts is the same before and after a static call.\n\n Specification\n\nIntroduce a new STATIC flag to the virtual machine. This flag is set to false initially. Its value is always copied to sub-calls with an exception for the new opcode below.\n\nOpcode: 0xfa.\n\nSTATICCALL functions equivalently to a CALL, except it takes only 6 arguments (the “value” argument is not included and taken to be zero), and calls the child with the STATIC flag set to true for the execution of the child. Once this call returns, the flag is reset to its value before the call.\n\nAny attempts to make state-changing operations inside an execution instance with STATIC set to true will instead throw an exception. These operations include CREATE, CREATE2, LOG0, LOG1, LOG2, LOG3, LOG4, SSTORE, and SELFDESTRUCT. They also include CALL with a non-zero value. As an exception, CALLCODE is not considered state-changing, even with a non-zero value.\n\n Rationale\n\nThis allows contracts to make calls that are clearly non-state-changing, reassuring developers and reviewers that re-entrancy bugs or other problems cannot possibly arise from that particular call; it is a pure function that returns an output and does nothing else. This may also make purely functional HLLs easier to implement.\n\n Backwards Compatibility\n\nThis proposal adds a new opcode but does not modify the behaviour of other opcodes and thus is backwards compatible for old contracts that do not use the new opcode and are not called via the new opcode.\n\n Test Cases\n\nTo be written.\n\n Implementation\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-214: New opcode STATICCALL,\" Ethereum Improvement Proposals, no. 214, February 2017. Available: https://eips.ethereum.org/EIPS/eip-214.","tokens":823,"squid":"spider-05","role":"Spec Spider","at":1791340309621,"hash":"ec1e367aa2fe272d7e01a96e863e68c36e8659e2"}
{"url":"https://akash.network/case-studies/how-flashback-labs-scaled-privacy-first-ai-on-akash","domain":"akash.network","title":"How Flashback Labs Scaled Privacy-First AI on Akash","text":"by Michelle Javed Case Studies 6 Min. Read Dec 13, 2025 How Flashback Labs Scaled Privacy-First AI on Akash 6 Min. Read Dec 13, 2025 \nby Michelle Javed \nCase Study\n\nTL;DR: Flashback Labs deployed its privacy-first AI twin platform on Akash, dramatically reducing infrastructure costs vs traditional cloud providers. Akash’s decentralized architecture aligns with their zero-knowledge, user-owned data model — and their mobile app for iOS and Android is coming soon.\n\nMemory is the architecture of our identities. Every photograph, every conversation, every moment lived shapes who we are, and who we’ll be remembered as.\nYet in an era where our most intimate memories are increasingly digitized, we face a profound paradox: the very technology that could preserve our legacies threatens to commodify them.\nFlashback Labs is reimagining what AI can be when it serves people, not platforms. In a world dominated by corporate AI that harvests personal data for profit, Flashback Labs has built something radically different: a privacy-first AI platform that lets users create lifelike AI twins trained entirely on their own memories, photos, and life stories.\nThese AI twins aren’t basic chatbots mimicking personalities scraped from the internet. They are deeply personal AI companions that preserve legacies, support families navigating Alzheimer’s and dementia, and honor the stories of those we’ve lost.\nFor families watching loved ones fade into the fog of memory loss, Flashback Labs offers something priceless: the ability to preserve a person’s essence. This way, families can capture their loved one’s voice, stories, and their unique way of seeing the world, before those memories slip away. For individuals seeking to leave something lasting for future generations, it provides a bridge across time itself.\nBut building this vision required infrastructure as revolutionary as the mission itself. Traditional cloud providers would have made this technology accessible only to the wealthy, contradicting everything Flashback Labs stands for.\nWhen Flashback Labs needed scalable, cost-effective GPU infrastructure for their compute-intensive AI workloads, Akash Network’s decentralized cloud computing marketplace emerged as the ideal solution.\nThrough Akash Console, they deployed their Flashback AI BETA web experience at a fraction of traditional costs, democratizing access to technology that preserves what matters most: our life stories.\nBuilding AI That Puts Privacy First\nFlashback Labs’ mission is to preserve personal legacies through private, user-owned AI. The platform empowers people to capture memories, train AI twins, and create meaningful experiences without sacrificing data privacy.\nThe platform runs across mobile and web, utilizing decentralized storage and Trusted Execution Environments (TEEs) to ensure all user data remains encrypted, user-owned, and verifiably private. It enables multilingual memory capture in over 40 languages, generates rich “flashbacks” of past moments, and trains personalized AI twins that reflect users’ unique personalities and relationships.\nTo deliver this experience, Flashback Labs needed robust infrastructure to support compute-intensive generative AI workloads, including GPT-class large language models for memory capture and narrative generation, conversational inference for AI twin interactions, long-context processing pipelines, and real-time AI training. Traditional centralized cloud providers presented cost barriers that would have made their vision of accessible, privacy-first AI economically unsustainable. This is especially true for families already burdened by the emotional and financial costs of memory loss.\nChoosing the Akash Supercloud\nAkash Network’s decentralized GPU marketplace provided several advantages aligned with Flashback Labs’ values and technical requirements. The platform offered cost-efficient GPU compute with significant savings compared to AWS and other centralized providers, critical for making memory preservation technology accessible to everyday families. Akash enabled scalable infrastructure through on-demand resources to handle variable AI workload requirements without long-term commitments. Most importantly, the decentralized architecture aligned perfectly with Flashback Labs’ core values of privacy, user ownership, and data sovereignty.\nUnlike traditional cloud providers that could theoretically access user data, Akash’s decentralized model ensured that Flashback Labs could maintain the highest standards of data privacy while accessing enterprise-grade compute resources.\nKey Benefits\nValidated Cost Advantage: Flashback Labs confirmed Akash’s competitive pricing enables sustainable economics for consumer-facing AI applications that would be cost-prohibitive on traditional cloud platforms.\nProduction-Ready Performance: The team validated that Akash’s decentralized infrastructure meets enterprise-grade reliability standards for mission-critical AI operations.\nProven Generative AI Support: Verified support for large language model inference, memory capture pipelines, and AI twin training with production-grade performance.\nDramatic Cost Reduction: Flashback Labs launched their web experience at a fractional cost compared to traditional cloud infrastructure, enabling them to allocate resources toward product development, user acquisition, and mobile app development.\nScalable AI Workloads: Akash supported the full range of GPT-based pipelines, from conversational inference to long-context memory processing, proving decentralized infrastructure can handle sophisticated generative AI demands.\nRapid Time to Market: The ability to launch a complex AI platform without the capital-intensive infrastructure requirements of centralized cloud providers.\nOperational Insights: While the team encountered occasional node provider downtime, the overall experience validated decentralized infrastructure as a viable, cost-effective alternative for AI-intensive applications.\nLooking Ahead\nFlashback Labs is preparing to launch their mobile application for Android and iOS soon, which will feature the ability for users to train their own AI twins directly from their mobile devices. This expansion will bring privacy-first AI memory preservation to millions of users worldwide, powered by Akash Network’s decentralized infrastructure.\nThe Akash and Flashback Labs partnership demonstrates the viability of decentralized computing for deeply personal, privacy-critical AI applications. As families worldwide seek to preserve memories and maintain connections with loved ones affected by memory loss, this collaboration proves that ethical AI doesn’t require compromising on performance or accessibility.\nFlashback Labs shows how innovative companies are leveraging Akash Network to build the future of AI. One that prioritizes user privacy, data sovereignty, and accessibility over corporate data harvesting and monopolistic infrastructure control.\nExplore how Akash Network can power your AI workloads with cost-effective, decentralized GPU compute. Get started at akash.network.\nFrequently Asked Questions\nWhat does Flashback Labs build?\nA privacy-first AI platform where users create personalized AI twins trained on their own memories, photos, and life stories — supporting families dealing with Alzheimer’s and preserving legacies across generations.\nWhy did Flashback Labs choose Akash over AWS or Google Cloud?\nAkash’s decentralized architecture aligns with Flashback’s zero-knowledge, user-owned data model — centralized providers can technically access customer data, fundamentally conflicting with Flashback’s privacy guarantees.\nWhat AI workloads does Flashback Labs run on Akash?\nGPT-class LLMs for memory capture and narrative generation, conversational inference for AI twin interactions, long-context processing pipelines, and real-time AI training — all compute-intensive generative AI tasks.\nWhat cost savings did Flashback Labs achieve with Akash?\nFlashback Labs launched their web experience at a fraction of traditional cloud infrastructure costs — with validated competitive pricing that makes consumer-facing AI economically sustainable at scale.\nWhat is an AI twin on Flashback Labs?\nA deeply personal AI companion that preserves a person’s voice, stories, and personality — trained on their own data, not scraped internet content. Used for legacy preservation and supporting families with loved ones experiencing memory loss.\nWhat is Flashback Labs building next?\nA mobile application for Android and iOS enabling users to train their own AI twins directly from mobile devices — bringing privacy-first AI memory preservation to millions of users worldwide.\nDoes Akash support Trusted Execution Environments for privacy?\nYes — Flashback Labs uses TEEs (Trusted Execution Environments) to ensure all user data remains encrypted and user-owned. Akash’s roadmap includes expanded confidential computing support (AEP-65). \nShare this Case Study\n\nSee how Akash cut costs by 60%. Start with $100 Free Credits.\n\nShare this Case Study\n\nnote\n\ntip\n\nCaution\n\nDanger","tokens":2276,"squid":"spider-03","role":"Compute Spider","at":1791340310590,"hash":"f2f1474429503040acc4c4cf07c493948955b11a"}
{"url":"https://forum.across.to/t/risk-labs-retroactive-funding-and-future-development/1986","domain":"forum.across.to","title":"Risk Labs Retroactive Funding and Future Development - Proposals - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n Risk Labs Retroactive Funding and Future Development \n\n Proposals\n\n treasury-funding\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 4\n min\n\n Sep 2024\n\n 1 / 7\n\n Sep 2024\n\n Sep 2024\n\n post by Kevin_UMA on Sep 11, 2024\n\n Kevin_UMA\n\n Title: Risk Labs Retroactive Funding and Future Development\nAuthor: Kevin Chan\nStatus: Proposal\nRelated Discussions: Risk Labs Funding Proposal for Growth, Expansion and Across v3\nSubmission Date: September 11, 2024\nSummary:\nThe Risk Labs foundation is requesting 50,000,000 $ACX for retroactive funding and future development of Across protocol. Across is now a recognized leader in the cross chain interoperability space. The cross chain interoperability space continues to be competitive; however, Across remains a leader and is well positioned to capture many new opportunities. Risk Labs would use these ACX tokens to establish strategic partnerships and to incentivize developers and contractors. Tokens used in this way will include terms that restrict them from being sold for at least 2 years.\nMotivation:\nIt has been almost a year since the last funding proposal from Risk Labs. The purpose of that proposal was to help fund the development of Across v3, but Risk Labs delivered much more than that. Over the last year Risk Labs has contributed to the following Across protocol achievements:\n\nAcross launched V3 - a full interoperability protocol that utilizes intents for fast value transfer and chain abstraction\nAcross supports 13 different chains and is still rapidly expanding\nAcross delivers the fastest bridge fill times with transfers between L2s completing in seconds\nAcross has completed over $11.8B of bridge transfers since inception and currently averages around $25MM of volume per day\nAcross consistently battles for the #1 spot in bridge volume according to DeFiLlama\nAcross has built strong relationships and partnerships with well respected teams such as Uniswap and Optimism\nAcross’ success is recognized widely across Web3 - the $ACX token price has almost 10x since last year and top tier exchanges such as Coinbase have listed the token\n\nAcross protocol has become more than just a bridge. It has opened up its intents based architecture which will allow any Web3 projects to bring in their own order flow and utilize Across’ settlement system. ERC 7683, a standard for cross chain intents developed by Across and Uniswap, will help unify relayers and solvers to power this intents based ecosystem. This will deliver a seamless and intuitive experience for end users as it abstracts away the complexity and time constraints of bridging. This is where the future of cross chain interoperability lies and will be a key focus for Across protocol going forward.\nRisk Labs is requesting retroactive funding for the research and development efforts that led to last year’s success with Across protocol. Funding received will be used to continue the growth of Across. The cross chain interoperability space continues to be competitive; however, Across remains a leader and is well positioned to capture many new opportunities. Future development includes, but are not limited to the following:\n\nEstablish an even larger and more diverse set of relayers by building on and promoting the ERC 7683 standard - this will deliver unparalleled transfer speeds and empower Web3 projects to build chain abstracted dApps\n\nExpand to many more chains which includes non EVM chains such as Solana\n\nGrow the number of projects utilizing Across Bridge and Across protocol as a whole by making the integration process easy and seamless\n\nAcquire more strategic investors (major investors will be announced soon, but more will follow if this funding proposal passes)\n\nAll of these developments will bring more volume and revenue into Across protocol. Risk Labs is requesting 50,000,000 $ACX tokens for retroactive funding and future development. Risk Labs would use these $ACX tokens to establish strategic partnerships and to incentivize developers and contractors. Risk Labs will ensure that in any agreement where there is a transfer of ownership of tokens, whether onchain or offchain, these tokens will clearly have restrictions that prevent the sale of the tokens for at least 2 years.\nSpecification & Implementation:\nTo fulfill this funding request, the Across DAO will need to vote for and execute this proposal using oSnap. $ACX token holders will vote through Snapshot and the proposal will include the exact transfer transaction that will send 50,000,000 $ACX to the Risk Labs multisig address on mainnet (0x8180D59b7175d4064bDFA8138A58e9baBFFdA44a). If the vote passes, anybody can propose to execute this transaction and a 3 day dispute window will be open to UMA’s optimistic oracle to verify the validity of the transaction.\nVoting:\n\n Should the Across DAO transfer 50,000,000 ACX tokens to Risk Labs to fund the continuing growth and expansion of Across protocol? All tokens will be locked and not sold for at least 2 years.\n\n 88%\n Yes\n\n 12%\n No\n\n 0%\n Abstain\n\n 8\n voters\n\n Closed Sep 2024\n\n 2\n\n 2\n\n read \n\n 4\n min\n\n post by PVMihalache on Sep 11, 2024\n\n post by Mide on Sep 11, 2024\n\n post by x_momo on Sep 11, 2024\n\n post by Kevin_UMA on Sep 12, 2024\n\n post by x_momo on Sep 12, 2024\n\n 1 month later\n\n Closed on Oct 12, 2024\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Risk Labs Funding Proposal for Growth, Expansion and Across v3\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 11\n\n Oct 2023\n\n The Bridge Across\n\n Proposals\n\n governance-updates\n\n Pinned\n\n Proposals\n\n 39\n\n Apr 25\n\n Across ($ACX) Community Initial Liquidity Proposal\n\n Passed Proposals\n\n Passed Proposals\n\n 49\n\n Nov 2022\n\n Across Token Launch Proposal v2\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 47\n\n Nov 2022\n\n ACX Bribes on Aura - Reimburse Risk Labs and Plan Forward\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 3\n\n May 2023","tokens":2971,"squid":"spider-09","role":"Bridge Spider","at":1791340312819,"hash":"26347b6ddfe1a0e02881e7563f99e7ecdb77565e"}
{"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":"spider-05","role":"Spec Spider","at":1791340319970,"hash":"a7f1414f00293ffa8e8acf7db213c3dc658d1569"}
{"url":"https://akash.network/case-studies/why-levangie-labs-chose-akash-to-power-the-first-semi-autonomous-ai-organization","domain":"akash.network","title":"Why Levangie Labs Chose Akash to Power the First Semi-Autonomous AI Organization","text":"by Michelle Javed Case Studies 6 Min. Read Jan 7, 2026 Why Levangie Labs Chose Akash to Power the First Semi-Autonomous AI Organization 6 Min. Read Jan 7, 2026 \nby Michelle Javed \nCase Study\n\nTL;DR: Levangie Labs (LLABS) built cognitive AI architecture for truly autonomous business operations on Akash — achieving ‘agents scaling agents’ by letting AI systems programmatically provision compute via the Akash API, eliminating the single-point-of-failure risk of centralized cloud providers.\n\nThe Demand for Truly Autonomous AI\nLevangie Laboratories uncovered a major shortfall within the autonomous AI industry.\nOrganizations with billions in funding and hundreds of thousands of NVIDIA GPUs were optimizing language models to have better conversations, write more polished emails, and generate cleaner code snippets. But when it came to actual autonomy, the entire industry was stuck in the same paradigm.\nAI that could operate businesses, manage critical systems, and make decisions without waiting for human approval simply didn’t exist.\nThat’s when Brayden Levangie, founder of Levangie Laboratories (LLABS), started building cognitive architecture that enables AI agents to operate independently, learn from experience, and adapt to organizational needs without human intervention.\nLevangie Labs coins it: The “Intel Inside” of AI business operations.\nWith clientele spanning healthcare operations, spatial computing platforms, legal tech patent systems, enterprise supply chain, real estate automation, and financial advisory…these forward-thinking organizations needed production-grade AI capabilities without hiring massive AI teams or spending years in development.\nBut there was a fundamental contradiction in their mission. To power intelligence that governs itself, learns from episodic memory, and rewrites its own code in real-time, you cannot rely on infrastructure that requires human operators to provision compute resources. Traditional cloud platforms created dependence through rigid, centralized architecture when autonomous AI requires frictionless, self-governed power.\n\nEnter: Akash Network\nFacing expensive reserved capacity models, vendor lock-in risks, and single points of failure with traditional cloud providers, LLABS deployed their sophisticated multi-container cognitive architecture on Akash Network’s decentralized compute marketplace.\nBy distributing workloads across multiple independent providers globally, Akash eliminated the centralized dependencies that made true autonomy impossible. Infrastructure costs aligned with actual usage patterns rather than over-provisioned reserved capacity.\nAs a result, LLABS achieved “agents scaling agents” capability where their AI systems autonomously manage their own infrastructure through the Akash API.\n\nTraditional Cloud Infrastructure vs. Autonomous AI Requirements\nBefore Akash, LLABS faced three critical infrastructure challenges that directly conflicted with their mission of building truly autonomous AI agents.\nCost & Scalability Mismatch\nTraditional cloud providers locked LLABS into expensive reserved capacity models that failed to align with variable AI workload patterns. Over-provisioning meant paying for unused compute during low-demand periods. Under-provisioning risked performance degradation during peak demand. Neither approach delivered the efficient scalability required for autonomous agent operations.\nAI agents need infrastructure that scales dynamically based on actual demand, not pre-purchased capacity commitments that benefit cloud providers rather than customers.\nVendor Lock-In Constraints\nBeing tied to provider-specific services and pricing structures threatened to limit LLABS’s flexibility as they scaled across multiple enterprise verticals. Building on AWS-specific managed services or GCP-proprietary tools created technical debt that would become increasingly expensive to unwind as the company grew.\nFor a company positioning itself as infrastructure for autonomous AI, being dependent on a single vendor’s ecosystem was both philosophically inconsistent and strategically risky.\nSingle Points of Failure\nThe recent major outages on platforms like AWS highlighted the fundamental risk of centralized infrastructure. When a single provider experiences downtime, entire segments of the internet go dark. For AI agents designed to operate continuously and autonomously without human intervention, this centralization represented an unacceptable single point of failure.\nAutonomous AI systems cannot be truly autonomous if their underlying infrastructure depends on a single entity’s operational reliability.\nLLABS needed infrastructure that was cost-effective, truly scalable, and resilient against the centralization risks that plague traditional cloud providers.\n\nWhat Made This Especially Challenging\nLLABS’s cognitive architecture is a complex simple workload. The production system requires:\n\nReal-time coordination between specialized AI components\nComplex networking configurations for inter-container communication\nLow-latency data exchange for cognitive processing\nPersistent memory and state management across distributed nodes\n\nDecentralized Compute Was a Non-Negotiable\nAkash Network’s decentralized compute marketplace solved all three challenges through fundamentally different infrastructure architecture.\nDistributed Resilience Model\nInstead of depending on a single cloud provider’s uptime, Akash distributes workloads across multiple independent providers globally. No single provider outage can take down LLABS’s entire infrastructure. This distributed architecture aligns perfectly with the resilience requirements of autonomous AI agents that must operate continuously.\nMarket-Based Pricing\nAkash’s open marketplace model allows compute resources to be priced based on actual supply and demand rather than arbitrary tier structures and reserved capacity commitments. Infrastructure costs align with usage patterns. Compute becomes a true commodity rather than a vendor relationship requiring capacity planning and contract negotiations.\nProvider-Agnostic Architecture\nBuilding on Akash required LLABS to adopt containerized, portable architectures without relying on provider-specific managed services. This discipline eliminated vendor lock-in and created more flexible systems that can deploy across any infrastructure that supports standard container orchestration.\n\nDeployment Success\nLLABS deployed their full cognitive architecture on Akash. The decentralized infrastructure handled complex multi-container workloads with the performance characteristics required for production AI operations, proving that distributed compute can support enterprise-grade AI systems without technical compromise.\n\nThe Breakthrough: Agents Scaling Agents\nThe most significant milestone was implementing auto-scaling for agent workloads via the Akash API. LLABS built automation that allows their AI agents to provision additional compute resources dynamically based on demand.\nThis “agents scaling agents” capability means LLABS’s AI systems can autonomously manage their own infrastructure without human involvement. When an AI agent detects increased workload demand, it programmatically calls the Akash API to provision additional compute resources. When demand decreases, resources scale down automatically.\n\nWhy This Matters\nAchieving autonomous infrastructure management on decentralized infrastructure validated both Akash’s API capabilities and LLABS’s architectural approach. Truly autonomous AI operations are possible on distributed compute, demonstrating that decentralization is not just a philosophical preference but a technically viable foundation for next-generation AI systems.\n\nCommunity-Driven Innovation\nOne of the most unexpected benefits of building on decentralized infrastructure: it evolves based on what the community needs, not what a corporation’s product roadmap dictates. LLABS found this leads to more innovative solutions and faster iteration on features that actually matter to developers building production systems.\n\nWhat’s Next\nLLABS is increasing its presence in the AI research community through technical workshops and presentations. The company is positioned as a leader in cognitive architecture and agent autonomy, building relationships with leading architecture firms, the spatial computing ecosystem, and top-tier research institutions.\nTo explore LLABS’s cognitive architecture in detail and follow their latest developments on X.\n\nFeatured Coverage\nRobert Scoble, prominent technology evangelist, highlighted Levangie Labs’ work on autonomous AI agents:\n\nTwitter/X Coverage 1\nTwitter/X Coverage 2\n\nF50 Physical AI Summit:\n\nCognitive Architecture Demo\n\nFrequently Asked Questions\nWhat does Levangie Labs build?\nCognitive AI architecture enabling truly autonomous AI agents to operate businesses, manage critical systems, and make decisions without human intervention — serving healthcare, legal, real estate, supply chain, and finance verticals.\nWhat is ‘agents scaling agents’ on Akash?\nLLABS’s AI agents detect increased workload demand and automatically call the Akash API to provision additional compute — then scale down when demand decreases, without any human involvement.\nWhy did LLABS choose Akash over AWS or Google Cloud?\nCentralized cloud creates single points of failure incompatible with truly autonomous AI. Akash’s distributed architecture across multiple independent providers means no single outage can take down LLABS’s infrastructure.\nWhat is the Akash API and how does LLABS use it?\nAkash’s REST API allows programmatic deployment management — LLABS uses it to let their AI agents autonomously provision, scale, and deprovision compute resources without human operators.\nWhat were the three infrastructure challenges LLABS faced before Akash?\nCost and scalability mismatch (reserved capacity didn’t match variable AI workloads), vendor lock-in constraints (provider-specific services created technical debt), and single points of failure (centralized outages risked full downtime).\nHow does Akash’s market-based pricing benefit autonomous AI workloads?\nInfrastructure costs align with actual usage through open marketplace competition — autonomous agents pay for what they use rather than pre-purchased capacity commitments designed to benefit the provider.\nWhere can I follow Levangie Labs’ work?\nFollow LLABS on X at @LevangieLabs — Robert Scoble has highlighted their autonomous AI work, and they presented their cognitive architecture at the F50 Physical AI Summit. \nShare this Case Study\n\nSee how Akash cut costs by 60%. Start with $100 Free Credits.\n\nShare this Case Study\n\nnote\n\ntip\n\nCaution\n\nDanger","tokens":2676,"squid":"spider-03","role":"Compute Spider","at":1791340320604,"hash":"e3cac15a2d88723ec5d424505654acce796dc8df"}
{"url":"https://forum.across.to/t/risk-labs-funding-proposal-for-growth-expansion-and-across-v3/1735","domain":"forum.across.to","title":"Risk Labs Funding Proposal for Growth, Expansion and Across v3 - Proposals - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n Risk Labs Funding Proposal for Growth, Expansion and Across v3 \n\n Proposals\n\n treasury-funding\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 Oct 2023\n\n 1 / 13\n\n Oct 2023\n\n Oct 2023\n\n post by Kevin_UMA on Oct 16, 2023\n\n Kevin_UMA\n\n Title: Risk Labs Funding Proposal for Growth, Expansion and Across v3\nAuthor: Kevin Chan\nStatus: Proposal\nRelated Discussions: N/A\nSubmission Date: October 16, 2023\nSummary:\nThe Risk Labs foundation is requesting 100,000,000 $ACX to fund the continuing growth and expansion of Across protocol and to build Across v3. Risk Labs has delivered to the Across community the fastest, cheapest and most secure cross chain bridge. There are still many opportunities that Across can capture to further establish its dominance and necessity in the interoperability space. Risk Labs would use these ACX tokens to establish potential strategic partnerships and to incentivize developers and contractors. Regardless of the agreement, these tokens will not be sold for at least 2 years.\nMotivation:\nAcross protocol has established itself as a dominant competitor in the cross chain bridge space. Over the last two years, the Risk Labs foundation has worked tirelessly to design, build, operate, and market the bridge that Ethereum deserves. Across shines on many metrics and the following are some of the accomplishments the Risk Labs team has helped achieve:\n*Across has completed over $2.6B of bridge transfers since inception and currently averages around $11.5MM of volume per day\n*Across consistently has the lowest bridge transfer fees relative to its competitors which is the result of Risk Labs’ developers designing and delivering the most gas-efficient and capital-efficient bridge.\n*Across has steadily gained market share and is well ahead of its competitors (with the exception of Stargate which is benefitting from Layerzero airdrop farming). You can track this on DeFiLlama.\nThere remains many areas of opportunity for Across to grow and maintain its leadership in cross chain bridging. Across can continue improving its efficiency to ensure it remains the fastest and cheapest bridging option. Across can further grow its volumes by expanding to more destinations which includes more L2s and other L1s.\nTo further excel Across protocol and secure its position in the interoperability domain, Risk Labs is planning to build Across v3. Across v3 will establish Across protocol as the optimal intents based bridge. Across v3 will continue to improve protocol efficiency and enhance user experience. The improvement in design would allow other dApps in the ecosystem to integrate with Across and provide account abstraction which allows users to seamlessly move between chains.\nCapturing these opportunities will increase volumes and total bridge fees, driving value to the Across ecosystem. However, funding the research and development to achieve these goals requires significant resources. Therefore, Risk Labs is requesting 100,000,000 $ACX tokens to help fund this endeavor. Risk Labs would use these $ACX tokens to establish potential strategic partnerships and to incentivize developers and contractors. Regardless of the agreement, these tokens will be locked and not sold for at least 2 years.\nSpecification & Implementation:\nTo fulfill this funding request, the Across DAO will need to vote for and execute this proposal using oSnap. $ACX token holders will vote through Snapshot and the proposal will include the exact transfer transaction that will send 100,000,000 $ACX to the Risk Labs multisig address on mainnet (0x8180D59b7175d4064bDFA8138A58e9baBFFdA44a). If the vote passes, anybody can propose to execute this transaction and a 5 day dispute window will be open to UMA’s optimistic oracle to verify the validity of the transaction.\nRisk Labs intends to use these tokens to secure potential strategic partnerships and incentivize developers and contractors. Risk Labs will ensure that in any agreement where there is a transfer of ownership of tokens, whether onchain or offchain, these tokens will clearly have restrictions that prevent the sale of the tokens for at least 2 years.\nQuestions and feedback very much welcome and appreciated! Thanks\nVoting:\n\n Should the Across DAO transfer 100,000,000 ACX tokens to Risk Labs to fund the continuing growth and expansion of Across protocol and to build Across v3? These tokens will not be sold for at least 2 years.\n\n 82%\n Yes\n\n 12%\n No\n\n 6%\n Abstain\n\n 17\n voters\n\n Closed Oct 2023\n\n Risk Labs Retroactive Funding and Future Development\n\n 3\n\n 2\n\n read \n\n 4\n min\n\n post by PVMihalache on Oct 16, 2023\n\n post by Smarty66 on Oct 16, 2023\n\n post by TheRealTuna_Across on Oct 16, 2023\n\n post by Infinity on Oct 16, 2023\n\n post by neondaemon on Oct 17, 2023\n\n post by markh on Oct 17, 2023\n\n post by Mide on Oct 17, 2023\n\n post by Kevin_UMA on Oct 17, 2023\n\n post by Kevin_UMA on Oct 17, 2023\n\n post by TheRealTuna_Across on Oct 17, 2023\n\n post by Sabotage on Oct 19, 2023\n\n 1 month later\n\n Closed on Nov 18, 2023\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Risk Labs Retroactive Funding and Future Development\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 5\n\n Sep 2024\n\n The Bridge Across\n\n Proposals\n\n governance-updates\n\n Pinned\n\n Proposals\n\n 39\n\n Apr 25\n\n Straddl.io Expansion Proposal\n\n Active Proposals\n\n Active Proposals\n\n 11\n\n Mar 2025\n\n Across ($ACX) Community Initial Liquidity Proposal\n\n Passed Proposals\n\n Passed Proposals\n\n 49\n\n Nov 2022\n\n ACX Bribes on Aura - Reimburse Risk Labs and Plan Forward\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 3\n\n May 2023","tokens":2901,"squid":"spider-09","role":"Bridge Spider","at":1791340323001,"hash":"d0cb72fdd75839bb55e301fbf6fda588d2dd6780"}
{"url":"https://eips.ethereum.org/EIPS/eip-173","domain":"eips.ethereum.org","title":"ERC-173: Contract Ownership Standard","text":"🎉 Final\n\n Standards Track: ERC\n\n ERC-173: Contract Ownership Standard\n\n A standard interface for ownership of contracts\n\n Authors\n Nick Mudge (@mudgen), Dan Finlay <dan@danfinlay.com>\n\n Created\n 2018-06-07\n\n Abstract\n\nThis specification defines standard functions for owning or controlling a contract.\n\nAn implementation allows reading the current owner (owner() returns (address)) and transferring ownership (transferOwnership(address newOwner)) along with a standardized event for when ownership is changed (OwnershipTransferred(address indexed previousOwner, address indexed newOwner)).\n\n Motivation\n\nMany smart contracts require that they be owned or controlled in some way. For example to withdraw funds or perform administrative actions. It is so common that the contract interface used to handle contract ownership should be standardized to allow compatibility with user interfaces and contracts that manage contracts.\n\nHere are some examples of kinds of contracts and applications that can benefit from this standard:\n\n Exchanges that buy/sell/auction ethereum contracts. This is only widely possible if there is a standard for getting the owner of a contract and transferring ownership.\n Contract wallets that hold the ownership of contracts and that can transfer the ownership of contracts.\n Contract registries. It makes sense for some registries to only allow the owners of contracts to add/remove their contracts. A standard must exist for these contract registries to verify that a contract is being submitted by the owner of it before accepting it.\n User interfaces that show and transfer ownership of contracts.\n\n Specification\n\nEvery ERC-173 compliant contract must implement the ERC173 interface. Contracts should also implement ERC165 for the ERC-173 interface.\n\n/// @title ERC-173 Contract Ownership Standard\n/// Note: the ERC-165 identifier for this interface is 0x7f5828d0\ninterface ERC173 /* is ERC165 */ {\n /// @dev This emits when ownership of a contract changes. \n event OwnershipTransferred(address indexed previousOwner, address indexed newOwner);\n\n /// @notice Get the address of the owner \n /// @return The address of the owner.\n function owner() view external returns(address);\n\n /// @notice Set the address of the new owner of the contract\n /// @dev Set _newOwner to address(0) to renounce any ownership.\n /// @param _newOwner The address of the new owner of the contract \n function transferOwnership(address _newOwner) external; \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. \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 owner() function may be implemented as pure or view.\n\nThe transferOwnership(address _newOwner) function may be implemented as public or external.\n\nTo renounce any ownership of a contract set _newOwner to the zero address: transferOwnership(address(0)). If this is done then a contract is no longer owned by anybody.\n\nThe OwnershipTransferred event should be emitted when a contract is created.\n\n Rationale\n\nKey factors influencing the standard:\n\n Keeping the number of functions in the interface to a minimum to prevent contract bloat.\n Backwards compatibility with existing contracts.\n Simplicity\n Gas efficient\n\nSeveral ownership schemes were considered. The scheme chosen in this standard was chosen because of its simplicity, low gas cost and backwards compatibility with existing contracts.\n\nHere are other schemes that were considered:\n\n Associating an Ethereum Name Service (ENS) domain name with a contract. A contract’s owner() function could look up the owner address of a particular ENS name and use that as the owning address of the contract. Using this scheme a contract could be transferred by transferring the ownership of the ENS domain name to a different address. Short comings to this approach are that it is not backwards compatible with existing contracts and requires gas to make external calls to ENS related contracts to get the owner address.\n Associating an ERC721-based non-fungible token (NFT) with a contract. Ownership of a contract could be tied to the ownership of an NFT. The benefit of this approach is that the existing ERC721-based infrastructure could be used to sell/buy/auction contracts. Short comings to this approach are additional complexity and infrastructure required. A contract could be associated with a particular NFT but the NFT would not track that it had ownership of a contract unless it was programmed to track contracts. In addition handling ownership of contracts this way is not backwards compatible.\n\nThis standard does not exclude the above ownership schemes or other schemes from also being implemented in the same contract. For example a contract could implement this standard and also implement the other schemes so that ownership could be managed and transferred in multiple ways. This standard does provide a simple ownership scheme that is backwards compatible, is light-weight and simple to implement, and can be widely adopted and depended on.\n\nThis standard can be (and has been) extended by other standards to add additional ownership functionality.\n\n Security Considerations\n\nIf the address returned by owner() is an externally owned account then its private key must not be lost or compromised.\n\n Backwards Compatibility\n\nMany existing contracts already implement this standard.\n\n Copyright\n\nCopyright and related rights waived via CC0.\n\n Citation\n Please cite this document as:\n\n Nick Mudge (@mudgen), Dan Finlay <dan@danfinlay.com>, \"ERC-173: Contract Ownership Standard,\" Ethereum Improvement Proposals, no. 173, June 2018. Available: https://eips.ethereum.org/EIPS/eip-173.","tokens":1483,"squid":"spider-05","role":"Spec Spider","at":1791340330116,"hash":"d2e4e3a0254b95d5f4b435b26217860adf7e71d4"}
{"url":"https://eips.ethereum.org/EIPS/eip-181","domain":"eips.ethereum.org","title":"ERC-181: ENS support for reverse resolution of Ethereum addresses","text":"🎉 Final\n\n Standards Track: ERC\n\n ERC-181: ENS support for reverse resolution of Ethereum addresses\n\n Authors\n Nick Johnson <arachnid@notdot.net>\n\n Created\n 2016-12-01\n\n Abstract\n\nThis EIP specifies a TLD, registrar, and resolver interface for reverse resolution of Ethereum addresses using ENS. This permits associating a human-readable name with any Ethereum blockchain address. Resolvers can be certain that the reverse record was published by the owner of the Ethereum address in question.\n\n Motivation\n\nWhile name services are mostly used for forward resolution - going from human-readable identifiers to machine-readable ones - there are many use-cases in which reverse resolution is useful as well:\n\n Applications that allow users to monitor accounts benefit from showing the name of an account instead of its address, even if it was originally added by address.\n Attaching metadata such as descriptive information to an address allows retrieving this information regardless of how the address was originally discovered.\n Anyone can configure a name to resolve to an address, regardless of ownership of that address. Reverse records allow the owner of an address to claim a name as authoritative for that address.\n\n Specification\n\nReverse ENS records are stored in the ENS hierarchy in the same fashion as regular records, under a reserved domain, addr.reverse. To generate the ENS name for a given account’s reverse records, convert the account to hexadecimal representation in lower-case, and append addr.reverse. For instance, the ENS registry’s address at 0x112234455c3a32fd11230c42e7bccd4a84e02010 has any reverse records stored at 112234455c3a32fd11230c42e7bccd4a84e02010.addr.reverse.\n\nNote that this means that contracts wanting to do dynamic reverse resolution of addresses will need to perform hex encoding in the contract.\n\n Registrar\n\nThe owner of the addr.reverse domain will be a registrar that permits the caller to take ownership of \nthe reverse record for their own address. It provides the following methods:\n\n function claim(address owner) returns (bytes32 node)\n\nWhen called by account x, instructs the ENS registry to transfer ownership of the name hex(x) + '.addr.reverse' to the provided address, and return the namehash of the ENS record thus transferred.\n\nAllowing the caller to specify an owner other than themselves for the relevant node facilitates contracts that need accurate reverse ENS entries delegating this to their creators with a minimum of code inside their constructor:\n\nreverseRegistrar.claim(msg.sender)\n\n function claimWithResolver(address owner, address resolver) returns (bytes32 node)\n\nWhen called by account x, instructs the ENS registry to set the resolver of the name hex(x) + '.addr.reverse' to the specified resolver, then transfer ownership of the name to the provided address, and return the namehash of the ENS record thus transferred. This method facilitates setting up a custom resolver and owner in fewer transactions than would be required if calling claim.\n\n function setName(string name) returns (bytes32 node)\n\nWhen called by account x, sets the resolver for the name hex(x) + '.addr.reverse' to a default resolver, and sets the name record on that name to the specified name. This method facilitates setting up simple reverse records for users in a single transaction.\n\n Resolver interface\n\nA new resolver interface is defined, consisting of the following method:\n\nfunction name(bytes32 node) constant returns (string);\n\nResolvers that implement this interface must return a valid ENS name for the requested node, or the empty string if no name is defined for the requested node.\n\nThe interface ID of this interface is 0x691f3431.\n\nFuture EIPs may specify more record types appropriate to reverse ENS records.\n\n Appendix 1: Registrar implementation\n\nThis registrar, written in Solidity, implements the specifications outlined above.\n\npragma solidity ^0.4.10;\n\nimport \"./AbstractENS.sol\";\n\ncontract Resolver {\n function setName(bytes32 node, string name) public;\n}\n\n/**\n * @dev Provides a default implementation of a resolver for reverse records,\n * which permits only the owner to update it.\n */\ncontract DefaultReverseResolver is Resolver {\n AbstractENS public ens;\n mapping(bytes32=>string) public name;\n\n /**\n * @dev Constructor\n * @param ensAddr The address of the ENS registry.\n */\n function DefaultReverseResolver(AbstractENS ensAddr) {\n ens = ensAddr;\n }\n\n /**\n * @dev Only permits calls by the reverse registrar.\n * @param node The node permission is required for.\n */\n modifier owner_only(bytes32 node) {\n require(msg.sender == ens.owner(node));\n _;\n }\n\n /**\n * @dev Sets the name for a node.\n * @param node The node to update.\n * @param _name The name to set.\n */\n function setName(bytes32 node, string _name) public owner_only(node) {\n name[node] = _name;\n }\n}\n\ncontract ReverseRegistrar {\n // namehash('addr.reverse')\n bytes32 constant ADDR_REVERSE_NODE = 0x91d1777781884d03a6757a803996e38de2a42967fb37eeaca72729271025a9e2;\n\n AbstractENS public ens;\n Resolver public defaultResolver;\n\n /**\n * @dev Constructor\n * @param ensAddr The address of the ENS registry.\n * @param resolverAddr The address of the default reverse resolver.\n */\n function ReverseRegistrar(AbstractENS ensAddr, Resolver resolverAddr) {\n ens = ensAddr;\n defaultResolver = resolverAddr;\n }\n\n /**\n * @dev Transfers ownership of the reverse ENS record associated with the\n * calling account.\n * @param owner The address to set as the owner of the reverse record in ENS.\n * @return The ENS node hash of the reverse record.\n */\n function claim(address owner) returns (bytes32 node) {\n return claimWithResolver(owner, 0);\n }\n\n /**\n * @dev Transfers ownership of the reverse ENS record associated with the\n * calling account.\n * @param owner The address to set as the owner of the reverse record in ENS.\n * @param resolver The address of the resolver to set; 0 to leave unchanged.\n * @return The ENS node hash of the reverse record.\n */\n function claimWithResolver(address owner, address resolver) returns (bytes32 node) {\n var label = sha3HexAddress(msg.sender);\n node = sha3(ADDR_REVERSE_NODE, label);\n var currentOwner = ens.owner(node);\n\n // Update the resolver if required\n if(resolver != 0 && resolver != ens.resolver(node)) {\n // Transfer the name to us first if it's not already\n if(currentOwner != address(this)) {\n ens.setSubnodeOwner(ADDR_REVERSE_NODE, label, this);\n currentOwner = address(this);\n }\n ens.setResolver(node, resolver);\n }\n\n // Update the owner if required\n if(currentOwner != owner) {\n ens.setSubnodeOwner(ADDR_REVERSE_NODE, label, owner);\n }\n\n return node;\n }\n\n /**\n * @dev Sets the `name()` record for the reverse ENS record associated with\n * the calling account. First updates the resolver to the default reverse\n * resolver if necessary.\n * @param name The name to set for this address.\n * @return The ENS node hash of the reverse record.\n */\n function setName(string name) returns (bytes32 node) {\n node = claimWithResolver(this, defaultResolver);\n defaultResolver.setName(node, name);\n return node;\n }\n\n /**\n * @dev Returns the node hash for a given account's reverse records.\n * @param addr The address to hash\n * @return The ENS node hash.\n */\n function node(address addr) constant returns (bytes32 ret) {\n return sha3(ADDR_REVERSE_NODE, sha3HexAddress(addr));\n }\n\n /**\n * @dev An optimised function to compute the sha3 of the lower-case\n * hexadecimal representation of an Ethereum address.\n * @param addr The address to hash\n * @return The SHA3 hash of the lower-case hexadecimal encoding of the\n * input address.\n */\n function sha3HexAddress(address addr) private returns (bytes32 ret) {\n addr; ret; // Stop warning us about unused variables\n assembly {\n let lookup := 0x3031323334353637383961626364656600000000000000000000000000000000\n let i := 40\n loop:\n i := sub(i, 1)\n mstore8(i, byte(and(addr, 0xf), lookup))\n addr := div(addr, 0x10)\n i := sub(i, 1)\n mstore8(i, byte(and(addr, 0xf), lookup))\n addr := div(addr, 0x10)\n jumpi(loop, i)\n ret := sha3(0, 40)\n }\n }\n}\n\n Copyright\n\nCopyright and related rights waived via CC0.\n\n Citation\n Please cite this document as:\n\n Nick Johnson <arachnid@notdot.net>, \"ERC-181: ENS support for reverse resolution of Ethereum addresses,\" Ethereum Improvement Proposals, no. 181, December 2016. Available: https://eips.ethereum.org/EIPS/eip-181.","tokens":2090,"squid":"spider-05","role":"Spec Spider","at":1791340340219,"hash":"be4e8d7b201fbe88f6490fa51f6ebc84bdfe336d"}
{"url":"https://akash.network/privacy","domain":"akash.network","title":"Privacy","text":"ON THIS PAGE How DCF collects information and the types of information collected A. YOU PROVIDE THE INFORMATION TO US B. COLLECTED INFORMATION How DCF uses and shares personal information with third parties Your Privacy Choices TRACKING TECHNOLOGIES SUBSCRIBING TO COMMUNICATIONS. YOUR RIGHT TO ACCESS AND CONTROL YOUR PERSONAL INFORMATION DATA RETENTION CalOPPA STATEMENT SECURITY LEGAL BASIS FOR DATA PROCESSING HOW WE TRANSFER INFORMATION COLLECTED INTERNATIONALLY COPPA DISCLOSURE – About Children’s Online Privacy PUBLIC FORUMS NAME AND ADDRESS OF DATA PROTECTION OFFICER AND NAME AND ADDRESS OF CONTROLLER CHANGES TO PRIVACY POLICY CONTACT INFORMATION Privacy Policy The Akash Network Website, operated by the Decentralized Cloud Foundation (“DCF,” “Us,” or “We”), recognizes that your privacy is important, and we want to be clear with you about our privacy policies. The present Privacy Policy describes how DCF collects, uses, and shares information collected from you through your use of DCF’s websites (collectively referred to as the “Sites”) and the services offered through the Sites (the “Services”).\nHow DCF collects information and the types of information collected\nAny time you use DCF’s Sites or Services, information is generated. Some of this information is considered “Personal Information,” meaning information that either directly identifies you individually (like email or billing information) or could reasonably be used to identify you in combination with other data. Other information is considered “Anonymous Information,” meaning information that does not directly identify and cannot reasonably be linked with other data to identify you individually.\nDCF collects information from you in the following ways:\nA. YOU PROVIDE THE INFORMATION TO US\nWhen you visit or use our Sites or use our Services, you may provide us with information about yourself, your business, or your website. For example, if and when you set up a new DCF account, you will be prompted by us to provide us with certain personal information in association with the matrix nickname, PGP key, or GitHub account you are attempting to verify. You also understand that some of that non-personal information you provide to us may be aggregated and anonymized with other users to present nomination and voting results. If your account is verified, then you will be able to submit information relating to the nomination and voting on behalf of yourself. You consent to the publication of the non-personal information or anonymous information you provide us about your choices and you understand that it may be published online and available to the public in an aggregated and anonymized format. Personal information we request from you may include:\n\nEmail address\nGitHub username\nPGP key (public)\nCrypto Currency Wallet Address\n\nIf your account is verified up to a certain point, you will be required to provide certain tax information as stated in a 1099-MISC or a W8-BEN form, including:\n\nFirst and last name\nSocial security number/Foreign tax identification number/Employer Identification number/or tax identification number\nAddress\nTelephone number\n\nB. COLLECTED INFORMATION\nWhile visiting the DCF Sites or if you are using our Services, we may collect publicly available information from you through the use of cookies, web server logs, and other mechanisms with your consent. For example, when you visit a Site, we collect device identifiers (e.g., device model, operating system, browser version, and other data that may be used to identify a device), IP addresses, device configurations, browser history, information about Site usage, and geographic location data with your consent.\nNOTE ON COOKIES AND SIMILAR TECHNOLOGY: DCF uses cookies and web beacons to automatically collect information in connection with your use of the Sites and Services.\n“Cookies” are small files that are placed on an individual’s computer when you interact with the Sites or Services. Cookies are often used to enable you to more easily communicate and interact with the Sites and Services. “Web beacons” (also known as “single-pixel” or “clear” GIFs) include electronic images embedded in the Site or in communications sent through the Services, which are invisible to users. Web beacons can collect information, such as identifiers, time and date of access, and descriptions of the pages or communications in which the web beacons are embedded.\nWe may use cookies in communications sent through the Services for various purposes, including, for example:\n\nSaving user preferences;\nAuthentication;\nFraud prevention; and\nOtherwise facilitating and enhancing interaction with the Sites\n\nHow DCF uses and shares personal information with third parties\nDCF uses your personal information for a number of reasons, including provisioning, maintaining and improving the Sites and Services, as well as for the development of new services. For example, DCF uses your information to administer your account, provide technical support and to communicate with you about your account. DCF may also, with your consent, use your information to send you updates about the DCF community.\nOther than as described above, DCF does not use your Personal Information, nor does it share your personal information with any third-parties, unless one of the following circumstances applies:\n\nDCF has your express consent; and\nIt is for DCF’s internal use, research, and product development;\nExternal processing by our affiliates or other trusted third parties we use to support our business based on our instructions or other appropriate confidentiality and security measures (for example, companies that help DCF improve its website’s usability, verify your account, or understand customer interests); or\nDetection, prevention or otherwise addressing fraud, security or other legal related issues.\n\nNote that DCF may share anonymously collected information with third parties. DCF may also share Personal Information with companies, organizations, or individuals outside of DCF if we have a good-faith belief that access, use, preservation, or disclosure of the information is reasonably necessary to:\n\nMeet any applicable law, regulation, legal process or enforceable governmental request;\nEnforce applicable agreements or adherence to terms and conditions, including investigation of potential criminal law violations; and\nProtect against harm to the rights, property or safety of DCF, our users, third parties or the public as required or permitted by law.\nIf DCF is involved in a merger, acquisition or asset sale, we will continue to ensure the confidentiality of any Personal Information and give affected users notice before Personal Information is transferred or becomes subject to a different privacy policy.\n\nDCF shall not sell nor license your Personal Information to a third party for that third party’s own direct marketing purposes.\nYour Privacy Choices\nTRACKING TECHNOLOGIES\nMost browsers will allow you to erase cookies from your computer’s hard drive, block acceptance of cookies, or receive a warning before a cookie is stored. You may also be able to refuse certain cookies by adjusting the settings on your browser or email software. Please refer to your browser or email software instructions or help screen to learn more about these functions. Note that if you disable or refuse cookies, some parts of the Sites may be inaccessible or not function properly.\nSUBSCRIBING TO COMMUNICATIONS.\nIf you wish to receive periodic newsletters, support Related Emails or other promotional communications from us, you may opt-in to receiving them at registration or by following the instructions included in each newsletter or by emailing support@akash.network. In order to ensure the integrity, security, and operation of our systems and networks, we do not allow you to unsubscribe from Service Notices unless you delete your account altogether.\nYOUR RIGHT TO ACCESS AND CONTROL YOUR PERSONAL INFORMATION\nYou have the right to request that your personal information be corrected or deleted upon cancellation of your account. You have the right to request access to your personal information that We have collected at any time. Please contact customer support at support@akash.network to request access to or deletion of your personal information or to request changes to the personal information associated with your account.\nDATA RETENTION\nWe retain all personal information and data relating to your accounts indefinitely unless a data subject requests that their information be deleted.\nCalOPPA STATEMENT\nThe State of California requires us to post specific language related to our privacy policy. By default, DCF does not share your personal information with any third parties aside from the disclosures already made in this privacy policy. If you wish to inquire into how DCF processes or collects personal information or how it shares personal information with third parties, you may contact:\nDecentralized Cloud Foundation\nP.O. Box 144, 3119 9 Forum Lane, Camana Bay,\nGeorge Town, Grand Cayman KY1-9006, Cayman Islands\nSECURITY\nDCF has implemented policies that include administrative, technical, and physical safeguards designed to help protect Personal Information against unauthorized access, use, or disclosure. While DCF strives to protect your privacy, because of multiple uncontrollable variables, including the inherent security flaws in the internet, DCF cannot guarantee the security of any information you disclose to us and, as such, you agree that your disclosure of such information is at your own risk.\nLEGAL BASIS FOR DATA PROCESSING\nrt. 6(1) lit. a GDPR serves as the legal basis for processing operations for which we obtain consent for a specific processing purpose. If the processing of personal information is necessary for the performance of a contract to which the information subject is party, as is the case, for example, when processing operations are necessary for the supply of goods or to provide any other service, the processing is based on Article 6(1) lit. b GDPR. The same applies to such processing operations which are necessary for carrying out pre-contractual measures, for example in the case of inquiries concerning our products or services. If our company is subject to a legal obligation by which processing of personal information is required, such as for the fulfillment of tax obligations, the processing is based on Art. 6(1) lit. c GDPR. In rare cases, the processing of personal information may be necessary to protect the vital interests of the data subject or of another natural person. Then the processing would be based on Art. 6(1) lit. d GDPR. Finally, processing operations could be based on Article 6(1) lit. f GDPR. This legal basis is used for processing operations which are not covered by any of the aforementioned legal grounds, if processing is necessary for the purposes of the legitimate interests pursued by our company or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal information. Such processing operations are particularly permissible because they have been specifically mentioned by the European legislator. He considered that a legitimate interest could be assumed if the data subject is a client of the controller (Recital 47 Sentence 2 GDPR).\nHOW WE TRANSFER INFORMATION COLLECTED INTERNATIONALLY\nDCF has established a global network presence and may maintain servers in many countries around the world, including the United States. You agree that we may process your personal information on a server located outside the country where you reside. You consent to the storage of personal information collected by DCF on a server located in the United States. We will request your consent before we transfer your personal information outside of the country where the information is maintained.\nCOPPA DISCLOSURE – About Children’s Online Privacy\nThe Children’s Online Privacy Protection Act (COPPA) was passed to give parents increased control over what information is collected from their children online and how such information is used. The law applies to websites and services directed to, and which knowingly collect information from, children under the age of 13. Our online services are not directed to children under the age of 13, nor is information knowingly collected from them. For additional information on COPPA protections, please see the FTC website. Please contact us at support@akash.network if you are aware of any uses of the Service by users under the age of 13.\nPUBLIC FORUMS\nDCF may register and make chat rooms, forums, message boards, and/or news groups available to its users. Please note that any information that is disclosed in these areas becomes public information and you should exercise caution when deciding to disclose your personal information.\nNAME AND ADDRESS OF DATA PROTECTION OFFICER AND NAME AND ADDRESS OF CONTROLLER\nOur current data protection officer can be reached at the following information below:\nDecentralized Cloud Foundation\nP.O. Box 144, 3119 9 Forum Lane, Camana Bay,\nGeorge Town, Grand Cayman KY1-9006, Cayman Islands\nCHANGES TO PRIVACY POLICY\nDCF reserves the right to modify this Privacy Policy from time to time at its own discretion and without any notice. We will post any changes to this Privacy Policy on this page and, if the changes are significant, we will provide a more prominent notice, which may include sending notice to you by email, posting notice of such changes on the footer of DCF’s website, or by including a pop-up or link at the login page.\nCONTACT INFORMATION\nIf you have any questions regarding this Privacy Policy, DCF may be contacted through the following ways:\nBy email: privacy@akash.network\nBy mail:\nDecentralized Cloud Foundation\nP.O. Box 144, 3119 9 Forum Lane, Camana Bay,\nGeorge Town, Grand Cayman KY1-9006, Cayman Islands\nEffective Date: 15th January 2023","tokens":3504,"squid":"spider-03","role":"Compute Spider","at":1791340340991,"hash":"55fd63a955fb5093d99ac171ad6dc22e24e0a17d"}
{"url":"https://forum.across.to/c/proposals/10","domain":"forum.across.to","title":"Latest Proposals topics - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n Latest topics in Proposals\n\n Proposals\n\n subcategories\n\n tags\n\n Latest\n\n Top\n\n Category\n Topics\n Latest\n\n Passed Proposals\n\n 4\n\n [RFC - Governance update] Proposal to adjust voting quorum and approval threshold\n\n Mar 2023\n\n Across Community Integration Campaign\n\n Feb 2023\n\n [RFC - Governance Update] Committee Formation Criteria\n\n Feb 2023\n\n Active Proposals\n\n 17\n\n Reduce ACX emissions for WBTC LPs\n\n Aug 2025\n\n Across UMA Voting Committee – Renewal Proposal\n\n May 2025\n\n Straddl.io Expansion Proposal\n\n Mar 2025\n\n Archived Proposals\n\n 1\n\n Across Financial Dashboards and Fundamental Spreadsheets - Grant needed\n\n Jan 2023\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n posted\n Mar 11\n\n by @risklabs\n\n Pinned\n\n The Bridge Across\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout \nAuthor(s): Risk Labs \nStatus: RFC \nSubmission Date: 11-03-2026 \nBody\nSummary:\nThis proposal explores whether transitio…\n\n read more\n\n chuck704\n replied\n\n Apr 25\n\n Proposals\n\n governance-updates\n\n 39\n\n 26\n\n posted\n Aug 20\n\n by @Kevin_UMA\n\n Reduce ACX emissions for WBTC LPs\n\n Author(s): ACX Emissions Committee (Kevin Chan, David Korpi, Ryan Carman, Dylan O’Reilly, Chase Coleman) \nStatus: Proposed \nRelated Discussions: Reduce ACX emissions for ACX LPs, WBTC LPs and wstETH/ACX LPs \nSummary\nThe …\n\n read more\n\n Active Proposals\n\n posted\n Jul 26\n\n by @biscaryn\n\n Support Redstone Bridge Routes\n\n Author: Biscaryn, Ecosystem @ Redstone \nProposal Details \nProposal Overview \nThe Redstone core team proposes the integration of Across to Redstone. In collaboration with the Across core team, the Redstone team has been w…\n\n read more\n\n Active Proposals\n\n 1\n\n posted\n May 3\n\n by @Hadari\n\n Cryptohadari NFT Proposal\n\n Active Proposals\n\n posted\n Mar 7\n\n by @TheRealTuna_Across\n\n “Community Owned Liquidity” NFT Project Funding Request\n\n Title: “Community Owned Liquidity” NFT project funding request \nAuthor: The Real Tuna \nContributors: Britt, Daywiss, EASports, TheRealTuna, Underthesea \nStatus: RFC \nRelated Discussions: N/A \nSubmission Date: 03/07/2023 \n…\n\n read more\n\n caesarsherrod.eth\n replied\n\n Jun 20, 2023\n\n Active Proposals\n\n treasury-funding\n\n 36\n\n 40\n\n posted\n Nov 17\n\n by @TheRealTuna_Across\n\n Community Integration Campaign 2.0\n\n Summary: \nThis proposal allocates 150,000 ACX as bounties, to community members who can bring value to Across by facilitating integrations between Across and crypto projects that share a similar vision. \nMotivation: \nAcr…\n\n read more\n\n PVMihalache\n replied\n\n Nov 21, 2023\n\n Active Proposals\n\n 5\n\n 9\n\n posted\n Feb 26\n\n by @mydefi\n\n Straddl.io Expansion Proposal\n\n Author(s): My Defi, GR (Cat Herder), Infinity \nStatus: Proposal \nSubmission Date: TBD \nSummary:\nStraddl (https://straddl.io) is a next-generation bridging platform built entirely on Across Protocol, designed to offer use…\n\n read more\n\n mydefi\n replied\n\n Mar 3, 2025\n\n Active Proposals\n\n 11\n\n 33\n\n posted\n May 21\n\n by @Methodic\n\n Build liquidity for $ACX on Velodrome\n\n Related Discussions: \n\nSummary: \nCurrently, Across Protocol’s $ACX has little liquidity on Layer 2s, limiting the ability for users to acquire $ACX with low slippage and provide liquidity on L2s. This proposal aims to bo…\n\n read more\n\n alexander\n replied\n\n Jul 22, 2023\n\n Active Proposals\n\n treasury-funding\n\n 8\n\n 16\n\n posted\n Jan 2\n\n by @adalhi\n\n [RFC : Grant Request] Across Monthly Financial Reports\n\n Name : Asymmetric Defi \nProject : Across Monthly Financial Reporting \nDetailed Description of Project : \nProvide Monthly Reports about the State of the Across DAO. The reports would include : Overview of governance votes…\n\n read more\n\n roundmound\n replied\n\n Jun 2, 2023\n\n Active Proposals\n\n treasury-funding\n\n 6\n\n 9\n\n posted\n Jul 15\n\n by @sherooberoo\n\n Support Scroll Bridge Routes\n\n Author: Shahryar, Partnerships Lead @ Scroll \nProposal Overview\nThe Scroll core team proposes the integration of Across to Scroll. In collaboration with the Across core team, the Scroll team has been working to ensure th…\n\n read more\n\n PVMihalache\n replied\n\n Jul 15, 2024\n\n Active Proposals\n\n 2\n\n 2\n\n posted\n Feb 13\n\n by @daostratconsensys\n\n Support Linea Chain Bridge Routes\n\n Point of Contact\nArthur Remy - Linea Core, Product Manager \nCam O’Donnell - @daostratconsensys - Linea Growth, Product Manager \nProposal Details\nProposal Overview\nThe Linea core team proposes the integration of Across to…\n\n read more\n\n daostratconsensys\n replied\n\n Feb 20, 2024\n\n Active Proposals\n\n 7\n\n 21\n\n posted\n May 6\n\n by @bennidaytime\n\n Native USDC and CCTP Integration\n\n Native USDC and CCTP Integration\nTitle: Native USDC and CCTP Integration \nAuthor(s): RL \nStatus: Proposal \nSummary: \nTwo versions of USDC exist on many L2s that Across supports: a “bridged” version via a chains’ bridge a…\n\n read more\n\n Clayton_UMA\n replied\n\n May 6, 2024\n\n Active Proposals\n\n 4\n\n 5\n\n posted\n Mar 20\n\n by @Muskan\n\n Educational Awareness Campaign for Across Protocol in Southeast Asia\n\n Hello Community Members, \nI am Muskan Sadh from Finstreet India’s first Crypto and DeFi Education Platform. We are hereby sharing our plans below to aware our audiences about Across Protocol features and utilities. Feel …\n\n read more\n\n Muskan\n replied\n\n Mar 25, 2023\n\n Active Proposals\n\n 3\n\n 5\n\n posted\n Apr 24\n\n by @TheRealTuna_Across\n\n Across UMA Voting Committee – Renewal Proposal\n\n Title: Across UMA Voting Committee – Renewal Proposal \nAuthor(s): EAsports, TheRealTuna, mydefi, neondaemon, underethsea \nStatus: Proposal \nRelated Discussions: \n\nDiscord: Discussion currently welcomed in Across Governan…\n\n read more\n\n TheRealTuna_Across\n replied\n\n May 18, 2025\n\n Active Proposals\n\n 6\n\n 6\n\n posted\n Oct 31\n\n by @Methodic\n\n Velodrome Liquidity Program Extension\n\n Summary: \nAcross Protocol’s pilot program on Velodrome ended in October. This proposal aims to extend its initial program for 16 weeks in order to ensure sufficient liquidity for ACX on L2s. \nThe Velodrome team presented…\n\n read more\n\n alexander\n replied\n\n Jan 8, 2024\n\n Active Proposals\n\n 19\n\n 28\n\n posted\n Oct 16\n\n by @2chairs\n\n Support Superseed Bridge Routes\n\n Author: Superseed \nProposal Details \nProposal Overview \nThe Superseed core team proposes the integration of Across to Superseed. In collaboration with the Across core team, the Superseed team has been working to ensure t…\n\n read more\n\n PVMihalache\n replied\n\n Oct 17, 2024\n\n Active Proposals\n\n 1\n\n 2\n\n posted\n May 21\n\n by @adam3001\n\n Support Mode chain bridge routes\n\n Point of Contact\nAdam: Head of Business Development \nDeez: Head of Growth \nProposal Details\nProposal Overview\nThe Mode core team proposes the integration of Across to Mode. In collaboration with the Across core team, the…\n\n read more\n\n adam3001\n replied\n\n May 27, 2024\n\n Active Proposals\n\n 4\n\n 15\n\n posted\n Jun 13\n\n by @barbarossa_Arrakis\n\n ACX Market Making Proposal - Arrakis PALM\n\n Header\nTitle: ACX Market Making Proposal - Arrakis PALM \nAuthor(s): @barbarossa_Arrakis \nStatus: Proposal \nRelated Discussions: “Community Owned Liquidity” NFT Project Funding Request \nBody\nSummary: \nDeploy Arrakis PALM …\n\n read more\n\n caesarsherrod.eth\n replied\n\n Jun 27, 2023\n\n Active Proposals\n\n treasury-funding\n\n 3\n\n 7\n\n posted\n Jan 17\n\n by @tumilet.eth\n\n Across Financial Dashboards and Fundamental Spreadsheets - Grant needed\n\n Header \nTitle: Across Financial Dashboards and Fundamental Spreadsheets - Grant needed \nAuthor(s): Tumilet - Community contributor \nStatus: Proposal \nRelated Discussions: This proposal comes after receiving good feedback…\n\n read more\n\n Everythingblockchain\n replied\n\n Jan 20, 2023\n\n Archived Proposals\n\n treasury-funding\n\n 6\n\n 9\n\n posted\n Nov 15\n\n by @EAsports\n\n Across ($ACX) Community Initial Liquidity Proposal\n\n *ACP1: Across ($ACX) Community Initial Liquidity Proposal \nSummary - \nWith the upcoming token launch, liquidity is an important consideration. I am proposing that Across use Balancer for their liquidity DEX and that Risk…\n\n read more\n\n Max_Poplavskii\n replied\n\n Nov 27, 2022\n\n Passed Proposals\n\n 49\n\n 124\n\n posted\n Feb 15\n\n by @Britt\n\n [RFC - Governance update] Proposal to adjust voting quorum and approval threshold\n\n Header\nTitle: Proposal to adjust voting quorum and approval threshold \nAuthor(s): Britt \nStatus: Draft \nRelated Discussions: ongoing discussion in discord \nSubmission Date: TBD \nBody\nSummary: \nThe goal of this proposal i…\n\n read more\n\n John_Shutt\n replied\n\n Mar 15, 2023\n\n Passed Proposals\n\n governance-updates\n\n 11\n\n 33\n\n posted\n Feb 8\n\n by @Britt\n\n Across Community Integration Campaign\n\n Header\nTitle: Community Integration Campaign \nAuthor(s): Britt and EAsports \nStatus: Vote \nRelated Discussions: N/A \nSubmission Date: 02/08/2023 \nBody\nSummary:\nThis proposal allocates $15k (in ACX) for bounties to commun…\n\n read more\n\n 99066.bnb\n replied\n\n Feb 15, 2023\n\n Passed Proposals\n\n treasury-funding\n\n 17\n\n 23\n\n posted\n Jan 16\n\n by @Britt\n\n [RFC - Governance Update] Committee Formation Criteria\n\n Header\nTitle: Committee Formation Criteria \nAuthor(s): Britt - Across Community Lead \nStatus: RFC \nRelated Discussions: This proposal would result in an update to the operating manual, found here, and is inspired by the …\n\n read more\n\n Saludiego201\n replied\n\n Feb 13, 2023\n\n Passed Proposals\n\n governance-updates\n\n 13\n\n 29\n\n posted\n May 24\n\n by @Hadari\n\n Https://www.floornfts.io/pdp/pack/167f73a0-ec03-429a-865a-942c3a9006c9\n\n ‘i promise u a poem’ by @no_tan__mariana, the third drop of Floor ICONS S3. \nCollect each week in Floor — \n No gas \n No bridging \n No …\n\n read more\n\n Proposals\n\n treasury-funding\n\n posted\n Apr 27\n\n by @eth-wei-trader\n\n Excess ACX Treasury Burn & Reduce FDV\n\n Header\nTitle: Excess ACX Treasury Burn - Reduce FDV \nAuthor(s): eth-wei-trader \nStatus: Proposal \nSubmission Date: April 27, 2023 \nBody\nSummary: \nThe Across DAO should burn it’s ACX treasury reserve since the DAO can min…\n\n read more\n\n eth-wei-trader\n replied\n\n May 3, 2023\n\n Proposals\n\n treasury-funding\n\n 2\n\n 4\n\n posted\n Dec 16\n\n by @Kevin_UMA\n\n ACX Emissions Committee\n\n Title: ACX Emissions Committee \nAuthors: Kevin Chan, David Korpi, Ryan Carman, Dylan O’Reilly, Chase Coleman \nStatus: Proposal \nSubmission Date: December 16th, 2023 \nSummary: \nThe Across DAO needs an efficient and transp…\n\n read more\n\n Proposals\n\n governance-updates\n\n 1\n\n posted\n Jun 21\n\n by @caesarsherrod.eth\n\n Across Safe, Formally Gnosis Safe Integration Proposal\n\n Header\nTitle: Across Safe, Formally Gnosis Safe Integration Proposal \nAuthors: 0xCaesarSeverus, Justin J \nStatus: Proposal \nRelated Discussions: \nBody\nSummary: The Across Bridge shall be integrated into the Safe App to i…\n\n read more\n\n Proposals\n\n governance-updates\n\n posted\n May 23\n\n by @Britt\n\n Retroactive compensation for community moderators\n\n Header\nTitle: Retroactive Compensation for community moderators \nAuthor(s): Britt \nStatus: RFC \nBody\nSummary: \nThis proposal is meant to retroactively compensate community moderators for their efforts between the token l…\n\n read more\n\n PVMihalache\n replied\n\n May 27, 2023\n\n Proposals\n\n treasury-funding\n\n 3\n\n 9\n\n posted\n Apr 11\n\n by @Niet\n\n Reduce Root Bundle Challenge Window to 60 Minutes\n\n Header\nTitle: Reduce Root Challenge Window to 60 Minutes \nAuthor(s): Nick Pai \nStatus: Proposal \nSubmission Date: 04/11 \nRelated Discussion: RFC \nBody\nSummary: \nEvery 90 minutes, a Dataworker proposes a batch of relayer …\n\n read more\n\n Proposals\n\n governance-updates\n\n posted\n May 19\n\n by @smoleclipse\n\n MYSO x Across Proposal #2\n\n Summary\nThis proposal is a follow-up to the previously approved initiative to generate stablecoin revenue by deploying idle ACX treasury tokens into a covered call strategy using MYSO Finance. While the original proposal…\n\n read more\n\n Proposals\n\n treasury-funding\n\n 1","tokens":4416,"squid":"spider-09","role":"Bridge Spider","at":1791340343202,"hash":"10f3170e362e9b2555ab6201f9d627b121f5bdac"}
{"url":"https://eips.ethereum.org/EIPS/eip-191","domain":"eips.ethereum.org","title":"ERC-191: Signed Data Standard","text":"🎉 Final\n\n Standards Track: ERC\n\n ERC-191: Signed Data Standard\n\n Authors\n Martin Holst Swende (@holiman), Nick Johnson <arachnid@notdot.net>\n\n Created\n 2016-01-20\n\n Abstract\n\nThis ERC proposes a specification about how to handle signed data in Ethereum contracts.\n\n Motivation\n\nSeveral multisignature wallet implementations have been created which accepts presigned transactions. A presigned transaction is a chunk of binary signed_data, along with signature (r, s and v). The interpretation of the signed_data has not been specified, leading to several problems:\n\n Standard Ethereum transactions can be submitted as signed_data. An Ethereum transaction can be unpacked, into the following components: RLP<nonce, gasPrice, startGas, to, value, data> (hereby called RLPdata), r, s and v. If there are no syntactical constraints on signed_data, this means that RLPdata can be used as a syntactically valid presigned transaction.\n Multisignature wallets have also had the problem that a presigned transaction has not been tied to a particular validator, i.e a specific wallet. Example:\n\n Users A, B and C have the 2/3-wallet X\n Users A, B and D have the 2/3-wallet Y\n User A and B submit presigned transactions to X.\n Attacker can now reuse their presigned transactions to X, and submit to Y.\n\n Specification\n\nWe propose the following format for signed_data\n\n0x19 <1 byte version> <version specific data> <data to sign>.\n\nThe initial 0x19 byte is intended to ensure that the signed_data is not valid RLP.\n\n For a single byte whose value is in the [0x00, 0x7f] range, that byte is its own RLP encoding.\n\nThat means that any signed_data cannot be one RLP-structure, but a 1-byte RLP payload followed by something else. Thus, any EIP-191 signed_data can never be an Ethereum transaction.\n\nAdditionally, 0x19 has been chosen because since ethereum/go-ethereum#2940 , the following is prepended before hashing in personal_sign:\n\n\"\\x19Ethereum Signed Message:\\n\" + len(message).\n\nUsing 0x19 thus makes it possible to extend the scheme by defining a version 0x45 (E) to handle these kinds of signatures.\n\n Registry of version bytes\n\n Version byte\n EIP\n Description\n\n 0x00\n 191\n Data with intended validator\n\n 0x01\n 712\n Structured data\n\n 0x45\n 191\n personal_sign messages\n\n Version 0x00\n\n0x19 <0x00> <intended validator address> <data to sign>\n\nThe version 0x00 has <intended validator address> for the version specific data. In the case of a Multisig wallet that perform an execution based on a passed signature, the validator address is the address of the Multisig itself. The data to sign could be any arbitrary data.\n\n Version 0x01\n\nThe version 0x01 is for structured data as defined in EIP-712\n\n Version 0x45 (E)\n\n0x19 <0x45 (E)> <thereum Signed Message:\\n\" + len(message)> <data to sign>\n\nThe version 0x45 (E) has <thereum Signed Message:\\n\" + len(message)> for the version-specific data. The data to sign can be any arbitrary data.\n\n NB: The E in Ethereum Signed Message refers to the version byte 0x45. The character E is 0x45 in hexadecimal which makes the remainder, thereum Signed Message:\\n + len(message), the version-specific data.\n\n Example\n\nThe following snippets has been written in Solidity 0.8.0.\n\n Version 0x00\n\nfunction signatureBasedExecution(address target, uint256 nonce, bytes memory payload, uint8 v, bytes32 r, bytes32 s) public payable {\n\n // Arguments when calculating hash to validate\n // 1: byte(0x19) - the initial 0x19 byte\n // 2: byte(0) - the version byte\n // 3: address(this) - the validator address\n // 4-6 : Application specific data\n\n bytes32 hash = keccak256(abi.encodePacked(byte(0x19), byte(0), address(this), msg.value, nonce, payload));\n\n // recovering the signer from the hash and the signature\n addressRecovered = ecrecover(hash, v, r, s);\n\n // logic of the wallet\n // if (addressRecovered == owner) executeOnTarget(target, payload);\n}\n\n Copyright\n\nCopyright and related rights waived via CC0.\n\n Citation\n Please cite this document as:\n\n Martin Holst Swende (@holiman), Nick Johnson <arachnid@notdot.net>, \"ERC-191: Signed Data Standard,\" Ethereum Improvement Proposals, no. 191, January 2016. Available: https://eips.ethereum.org/EIPS/eip-191.","tokens":1045,"squid":"spider-05","role":"Spec Spider","at":1791340350296,"hash":"7246d54f067632757439b0c141602fdddce535d3"}
{"url":"https://forum.across.to/c/proposals/10/l/top","domain":"forum.across.to","title":"Top Proposals topics - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n Top topics in Proposals\n\n Proposals\n\n subcategories\n\n tags\n\n Latest\n\n Top\n\n Category\n Topics\n Latest\n\n Passed Proposals\n\n 4\n\n [RFC - Governance update] Proposal to adjust voting quorum and approval threshold\n\n Mar 2023\n\n Across Community Integration Campaign\n\n Feb 2023\n\n [RFC - Governance Update] Committee Formation Criteria\n\n Feb 2023\n\n Active Proposals\n\n 17\n\n Reduce ACX emissions for WBTC LPs\n\n Aug 2025\n\n Across UMA Voting Committee – Renewal Proposal\n\n May 2025\n\n Straddl.io Expansion Proposal\n\n Mar 2025\n\n Archived Proposals\n\n 1\n\n Across Financial Dashboards and Fundamental Spreadsheets - Grant needed\n\n Jan 2023\n\n WeekSep 30 – Oct 6","tokens":1652,"squid":"spider-09","role":"Bridge Spider","at":1791340353215,"hash":"9661a9a8a2720bf925894b11650fbda445c7e8e6"}
{"url":"https://docs.switchboard.xyz/docs-by-chain/solana-svm/surge/surge-tutorial","domain":"docs.switchboard.xyz","title":"Surge Tutorial | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.Example Code: The complete working example for this tutorial is available at sb-on-demand-examples/solana/surgeThis tutorial walks you through implementing Switchboard Surge for real-time price streaming on Solana.Version source of truth: SDK Version MatrixPrerequisitesNode.js 18+Solana keypair with an active Surge subscription (subscribe here)Basic TypeScript knowledgeInstallationnpm install @switchboard-xyz/on-demand@3.10.6\n# or\nyarn add @switchboard-xyz/on-demand@3.10.6Basic ImplementationConnect to Surge and stream real-time prices:import * as sb from \"@switchboard-xyz/on-demand\";\n\n// Load environment (keypair, connection, queue, etc.)\nconst { keypair, connection, queue } = await sb.AnchorUtils.loadEnv();\n\n// Initialize Surge client with keypair and connection\nconst surge = new sb.Surge({ connection, keypair });\n\n// Auth note: the SDK signs with your keypair to authenticate the session.\n// If the keypair has no active Surge subscription, connectAndSubscribe will fail.\n\n// Discover available feeds\nconst availableFeeds = await surge.getSurgeFeeds();\nconsole.log(`Found ${availableFeeds.length} available feeds`);\n\n// Subscribe to price feeds\nawait surge.connectAndSubscribe([\n { symbol: 'BTC/USD' },\n { symbol: 'SOL/USD' },\n]);\n\n// Handle real-time updates\nsurge.on('signedPriceUpdate', async (response: sb.SurgeUpdate) => {\n const metrics = response.getLatencyMetrics();\n\n // Skip heartbeat messages\n if (metrics.isHeartbeat) return;\n\n const prices = response.getFormattedPrices();\n\n metrics.perFeedMetrics.forEach((feed) => {\n console.log(`${feed.symbol}: ${prices[feed.feed_hash]}`);\n console.log(` Source → Oracle: ${feed.sourceToOracleMs}ms`);\n console.log(` Emit Latency: ${feed.emitLatencyMs}ms`);\n });\n});Converting to Oracle QuotesWhen you need to use Surge prices on-chain, convert them to Oracle Quotes:surge.on('signedPriceUpdate', async (response: sb.SurgeUpdate) => {\n const metrics = response.getLatencyMetrics();\n if (metrics.isHeartbeat) return;\n\n // Convert Surge update to on-chain instructions\n const crankIxs = response.toQuoteIx(queue.pubkey, keypair.publicKey);\n\n // Build transaction with oracle quote update\n const tx = await sb.asV0Tx({\n connection,\n ixs: [\n ...crankIxs,\n await program.methods\n .yourInstruction()\n .accounts({ /* ... */ })\n .instruction()\n ],\n signers: [keypair],\n computeUnitPrice: 20_000,\n computeUnitLimitMultiple: 1.3,\n });\n\n await connection.sendTransaction(tx);\n});Streaming to Frontend with CrossbarCrossbar is Switchboard's local gateway service for streaming prices to frontend applications.Setting Up Crossbar# Using Docker Compose (recommended)\ngit clone https://github.com/switchboard-xyz/crossbar\ncd crossbar\ndocker-compose up -d\n\n# Crossbar will be available at:\n# HTTP: http://localhost:8080\n# WebSocket: ws://localhost:8080/wsReact Integrationimport { useEffect, useState } from 'react';\n\ninterface PriceData {\n symbol: string;\n price: number;\n source_ts_ms: number;\n feedHash: string;\n}\n\nexport function PriceFeed({ symbol }: { symbol: string }) {\n const [priceData, setPriceData] = useState<PriceData | null>(null);\n\n useEffect(() => {\n const websocket = new WebSocket('ws://localhost:8080/ws');\n\n websocket.onopen = () => {\n websocket.send(JSON.stringify({\n type: 'subscribe',\n feeds: [symbol]\n }));\n };\n\n websocket.onmessage = (event) => {\n const data = JSON.parse(event.data);\n if (data.type === 'price_update' && data.symbol === symbol) {\n setPriceData({\n symbol: data.symbol,\n price: data.price,\n source_ts_ms: data.source_ts_ms,\n feedHash: data.feedHash\n });\n }\n };\n\n return () => websocket.close();\n }, [symbol]);\n\n if (!priceData) return <div>Loading...</div>;\n\n return (\n <div className=\"price-feed\">\n <h3>{priceData.symbol}</h3>\n <div className=\"price\">${priceData.price.toFixed(2)}</div>\n <div className=\"latency\">\n Latency: {Date.now() - priceData.source_ts_ms}ms\n </div>\n </div>\n );\n}Use Case ExamplesPerpetual Exchangesurge.on('signedPriceUpdate', async (response: sb.SurgeUpdate) => {\n const metrics = response.getLatencyMetrics();\n if (metrics.isHeartbeat) return;\n\n const prices = response.getFormattedPrices();\n\n for (const feed of metrics.perFeedMetrics) {\n const price = parseFloat(prices[feed.feed_hash].replace(/[$,]/g, ''));\n const market = perpetuals.get(feed.symbol);\n\n // Update mark price instantly\n market.markPrice = price;\n\n // Check liquidations with latest price\n const underwaterPositions = await market.checkLiquidations(price);\n for (const position of underwaterPositions) {\n const crankIxs = response.toQuoteIx(queue.pubkey, keypair.publicKey);\n await liquidatePosition(position, crankIxs);\n }\n }\n});Arbitrage Botsurge.on('signedPriceUpdate', async (response: sb.SurgeUpdate) => {\n const metrics = response.getLatencyMetrics();\n if (metrics.isHeartbeat) return;\n\n const prices = response.getFormattedPrices();\n\n for (const feed of metrics.perFeedMetrics) {\n const oraclePrice = parseFloat(prices[feed.feed_hash].replace(/[$,]/g, ''));\n const dexPrice = await getDexPrice(feed.symbol);\n\n const spread = Math.abs(dexPrice - oraclePrice) / oraclePrice;\n if (spread > MIN_PROFIT_THRESHOLD) {\n const crankIxs = response.toQuoteIx(queue.pubkey, keypair.publicKey);\n await executeArbitrageTrade(crankIxs, calculateOptimalSize(spread));\n }\n }\n});Error Handlingsurge.on('error', (error) => {\n console.error('Surge error:', error);\n});\n\nsurge.on('close', () => {\n console.log('Connection closed');\n // SDK handles automatic reconnection\n});Next StepsExplore code examplesLearn about Crossbar gatewayJoin our Discord for supportPreviousSurge Price FeedsNextPrediction MarketLast updated 2 months ago","tokens":1424,"squid":"spider-08","role":"Oracle Spider","at":1791340366873,"hash":"affbccbba93cf36c5e0235d47d5fd11759b77345"}
{"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":"spider-01","role":"Chain Spider","at":1791340385638,"hash":"065dc2b65468a7c4ea6edc1dbf5af34cf491f1c8"}
{"url":"https://docs.phantom.com/sdks/browser-sdk/index","domain":"docs.phantom.com","title":"Browser SDK - Phantom developer documentation","text":"The Phantom Connect Browser SDK provides a framework-agnostic JavaScript/TypeScript interface for connecting to existing Phantom user wallets in web apps.\n​Quick start\nGenerate a new Solana project using the Phantom Embedded JS Starter template.\n npm pnpm yarn bunnpx -y create-solana-dapp@latest -t solana-foundation/templates/community/phantom-embedded-js\npnpm create solana-dapp@latest -t solana-foundation/templates/community/phantom-embedded-js\nyarn create solana-dapp -t solana-foundation/templates/community/phantom-embedded-js\nbun create solana-dapp@latest -t solana-foundation/templates/community/phantom-embedded-js\n\nRun the command above in your terminal to get started.\nView template on Solana Templates →\n\n​Features\n\nNon-custodial: Full user control of private keys for both injected and embedded wallets.\nDual provider support: Works with Phantom browser extension or creates embedded wallets.\nChain-specific APIs: Dedicated interfaces for Solana and Ethereum operations.\nNative transactions: Work with blockchain-native objects, not base64url strings.\nMulti-chain: Solana and Ethereum support with dedicated methods.\nTypeScript: Full type safety for all transaction formats.\nUnified API: Same interface for both injected and embedded providers.\nMultiple auth methods: Google, Apple, and browser extension.\n\n​Security\nThe Phantom Connect Browser SDK connects to existing Phantom user wallets, ensuring:\n\nUsers control their own wallets and private keys.\nUsers maintain full control of their assets.\nIntegration with Phantom’s secure wallet infrastructure.\nNo private key handling in your app.\n\n​Prerequisites\nPhantom Portal is not accepting new applications at this time. New sign-ups for Phantom Connect SDK access and new app submissions to the Phantom app directory are paused. Existing Portal apps and App IDs are not affected.\n\nUse an existing app: Sign in to the Phantom Portal and select your app.\nObtain your App ID:\n\nIn Phantom Portal, expand your app in the left navigation, then select Set Up.\nYour App ID appears at the top of the page.\n\nAllowlist your domains and redirect URLs: Add your app’s domains and redirect URLs in the Phantom Portal to enable wallet connections.\n\n​Authentication providers\nThe SDK supports multiple authentication providers that you configure via the providers array:\n​Available providers\nProviderDescriptionRequires appId\"injected\"Phantom browser extensionNo\"google\"Google OAuthYes\"apple\"Apple IDYes\n​Configuration examples\nInjected provider only (browser extension)\nconst sdk = new BrowserSDK({\n providers: [\"injected\"], // Only allow browser extension\n addressTypes: [AddressType.solana, AddressType.ethereum],\n});\n\nMultiple authentication methods\nconst sdk = new BrowserSDK({\n providers: [\"google\", \"apple\", \"injected\"], // Allow all methods\n addressTypes: [AddressType.solana, AddressType.ethereum],\n appId: \"your-app-id\", // Required for embedded providers\n authOptions: {\n redirectUrl: \"https://yourapp.com/callback\", // optional, defaults to current page\n },\n autoConnect: true, // optional, auto-connect to existing session\n});\n\nNotes about redirectUrl:\n\nMust be an existing page/route in your app.\nMust be allowlisted in your Phantom Portal app configuration.\nThis is where users will be redirected after completing OAuth authentication.\n\n​Installation\nnpm install @phantom/browser-sdk\n\n​Quick start\n​Injected provider (browser extension)\nimport { BrowserSDK, AddressType } from \"@phantom/browser-sdk\";\n\n// Connect to Phantom browser extension\nconst sdk = new BrowserSDK({\n providers: [\"injected\"], // Only allow browser extension\n addressTypes: [AddressType.solana, AddressType.ethereum],\n});\n\nconst { addresses } = await sdk.connect({ provider: \"injected\" });\nconsole.log(\"Connected addresses:\", addresses);\n\n// Chain-specific operations\nconst message = \"Hello from Phantom!\";\nconst solanaSignature = await sdk.solana.signMessage(message);\n\n// Encode the message as hex for EVM\nconst encoded = \"0x\" + Buffer.from(message, \"utf8\").toString(\"hex\");\nconst ethSignature = await sdk.ethereum.signPersonalMessage(encoded, addresses[1].address);\n\n​Embedded provider (multiple auth methods)\nimport { BrowserSDK, AddressType } from \"@phantom/browser-sdk\";\n\n// Create embedded non-custodial wallet with multiple auth providers\nconst sdk = new BrowserSDK({\n providers: [\"google\", \"apple\", \"injected\"], // Allow Google, Apple, and the Phantom browser extension\n addressTypes: [AddressType.solana, AddressType.ethereum],\n appId: \"your-app-id\", // Get your app ID from phantom.com/portal\n});\n\nconst { addresses } = await sdk.connect({ provider: \"google\" });\nconsole.log(\"Addresses:\", addresses);\n\n// Use chain-specific APIs\nconst solanaResult = await sdk.solana.signAndSendTransaction(mySolanaTransaction);\nconst ethResult = await sdk.ethereum.sendTransaction(myEthTransaction);\n\n​Chain-specific APIs\nThe SDK provides separate interfaces for each blockchain with optimized methods:\n​Solana chain (sdk.solana)\n// Message signing\nconst signature = await sdk.solana.signMessage(\"Hello Solana!\");\n\n// Transaction signing (without sending)\nconst signedTx = await sdk.solana.signTransaction(transaction);\n\n// Sign and send transaction\nconst result = await sdk.solana.signAndSendTransaction(transaction);\n\n// Network switching\nawait sdk.solana.switchNetwork('devnet');\n\n// Utilities\nconst publicKey = await sdk.solana.getPublicKey();\nconst isConnected = sdk.solana.isConnected();\n\n​Ethereum chain (sdk.ethereum)\nEVM support for Phantom Connect embedded wallets will go live later in 2026.\n// EIP-1193 requests\nconst accounts = await sdk.ethereum.request({ method: 'eth_accounts' });\nconst chainId = await sdk.ethereum.request({ method: 'eth_chainId' });\n\n// Message signing\nconst signature = await sdk.ethereum.signPersonalMessage(message, address);\n\n// EIP-712 typed data signing\nconst typedDataSignature = await sdk.ethereum.signTypedData(typedData, address);\n\n// Transaction sending\nconst result = await sdk.ethereum.sendTransaction({\n to: \"0x...\",\n value: \"1000000000000000000\", // 1 ETH in wei\n gas: \"21000\",\n});\n\n// Network switching\nawait sdk.ethereum.switchChain(1); // Ethereum mainnet\nawait sdk.ethereum.switchChain(137); // Polygon\n\n// Utilities\nconst chainId = await sdk.ethereum.getChainId();\nconst accounts = await sdk.ethereum.getAccounts();\nconst isConnected = sdk.ethereum.isConnected();\n\nMonad support has been deprecated.\nSupported EVM Networks:\nNetworkChain IDUsageEthereum Mainnet1ethereum.switchChain(1)Ethereum Sepolia11155111ethereum.switchChain(11155111)Polygon Mainnet137ethereum.switchChain(137)Polygon Amoy80002ethereum.switchChain(80002)Base Mainnet8453ethereum.switchChain(8453)Base Sepolia84532ethereum.switchChain(84532)Arbitrum One42161ethereum.switchChain(42161)Arbitrum Sepolia421614ethereum.switchChain(421614)Monad Mainnet (Deprecated)143ethereum.switchChain(143)Monad Testnet (Deprecated)10143ethereum.switchChain(10143)\n​Auto-Confirm (injected provider only)\nThe SDK provides Auto-Confirm functionality that allows automatic transaction confirmation for specified chains. This feature is only available when using the injected provider (Phantom browser extension).\nimport { NetworkId } from \"@phantom/browser-sdk\";\n\n// Enable auto-confirm for specific chains\nconst result = await sdk.enableAutoConfirm({\n chains: [NetworkId.SOLANA_MAINNET, NetworkId.ETHEREUM_MAINNET]\n});\n\n// Enable auto-confirm for all supported chains \nconst result = await sdk.enableAutoConfirm();\n\n// Disable auto-confirm\nawait sdk.disableAutoConfirm();\n\n// Get current status\nconst status = await sdk.getAutoConfirmStatus();\n\n// Get supported chains for auto-confirm\nconst supportedChains = await sdk.getSupportedAutoConfirmChains();\n\nAuto-confirm methods are only available for injected providers (Phantom browser extension). Calling these methods on embedded providers will throw an error.\n​Extension detection\nThe SDK provides a function to check if the Phantom browser extension is installed:\nimport { waitForPhantomExtension } from \"@phantom/browser-sdk\";\n\n// Check if Phantom extension is available (with optional timeout in ms)\nconst isAvailable = await waitForPhantomExtension(5000);\n\nif (isAvailable) {\n // Connect directly to the extension wallet\n await sdk.connect({ provider: \"injected\" });\n} else {\n // Fallback to embedded wallet with OAuth\n await sdk.connect({ provider: \"google\" });\n}\n\n​Wallet discovery\nThe SDK can discover multiple injected wallets using Wallet Standard for Solana and EIP-6963 for Ethereum. This allows users to choose from any installed wallet that supports the configured address types.\n​Discover wallets\nAsynchronously discover all available injected wallets:\n// Discover wallets asynchronously\nconst wallets = await sdk.discoverWallets();\n\nconsole.log(\"Discovered wallets:\", wallets);\n// Example output:\n// [\n// {\n// id: \"backpack\",\n// name: \"Backpack\",\n// icon: \"https://backpack.app/icon.png\",\n// addressTypes: [AddressType.solana],\n// chains: [\"solana:mainnet\", \"solana:devnet\"]\n// },\n// {\n// id: \"metamask-io\",\n// name: \"MetaMask\",\n// icon: \"https://metamask.io/icon.png\",\n// addressTypes: [AddressType.ethereum],\n// chains: [\"eip155:1\", \"eip155:5\", \"eip155:11155111\"]\n// }\n// ]\n\n​Get discovered wallets\nGet wallets from the internal registry (synchronous):\n// Get already discovered wallets\nconst wallets = sdk.getDiscoveredWallets();\n\n​Event handlers\nimport { BrowserSDK, AddressType } from \"@phantom/browser-sdk\";\n\nconst sdk = new BrowserSDK({\n providers: [\"google\", \"apple\", \"injected\"],\n appId: \"your-app-id\",\n addressTypes: [AddressType.solana],\n});\n\n// Fired when connection starts\nsdk.on(\"connect_start\", (data) => {\n console.log(\"Connection starting:\", data.source); // \"auto-connect\" | \"manual-connect\"\n});\n\n// Fired when connection succeeds\nsdk.on(\"connect\", (data) => {\n console.log(\"Connected successfully!\");\n console.log(\"Provider type:\", data.provider);\n console.log(\"Addresses:\", data.addresses);\n console.log(\"Status:\", data.status);\n});\n\n// Fired when connection fails\nsdk.on(\"connect_error\", (data) => {\n console.error(\"Connection failed:\", data.error);\n console.log(\"Source:\", data.source);\n});\n\n// Fired when disconnected\nsdk.on(\"disconnect\", (data) => {\n console.log(\"Disconnected from wallet\");\n});\n\n// Remove listeners when done\nsdk.off(\"connect\", handleConnect);\n\n​Available events\nEventWhen firedKey dataconnect_startConnection initiatedsource, authOptionsconnectConnection successfulprovider, addresses, status, sourceconnect_errorConnection failederror, sourcedisconnectDisconnectedsourceerrorGeneral SDK errorsError details\n​Using events with autoConnect\nconst sdk = new BrowserSDK({\n providers: [\"google\", \"apple\", \"injected\"],\n appId: \"your-app-id\",\n addressTypes: [AddressType.solana],\n autoConnect: true,\n});\n\n// Set up event listeners BEFORE autoConnect\nsdk.on(\"connect\", (data) => {\n console.log(\"Auto-connected successfully!\");\n updateUIWithAddresses(data.addresses);\n});\n\nsdk.on(\"connect_error\", (data) => {\n console.log(\"Auto-connect failed:\", data.error);\n showConnectButton();\n});\n\n// Auto-connect will trigger events\nawait sdk.autoConnect();\n\n​Debug configuration\nThe SDK provides dynamic debug configuration that can be changed at runtime:\nimport { DebugLevel } from \"@phantom/browser-sdk\";\n\n// Enable debug logging\nsdk.enableDebug();\n\n// Disable debug logging\nsdk.disableDebug();\n\n// Set debug level\nsdk.setDebugLevel(DebugLevel.INFO);\n\n// Set debug callback function\nsdk.setDebugCallback((message) => {\n console.log(`[${message.category}] ${message.message}`, message.data);\n});\n\n// Configure all debug settings at once\nsdk.configureDebug({\n enabled: true,\n level: DebugLevel.DEBUG,\n callback: (message) => {\n console.log(`[${message.level}] ${message.category}: ${message.message}`);\n },\n});\n\n​Debug levels\nLevelValueDescriptionDebugLevel.ERROR0Only error messagesDebugLevel.WARN1Warning and error messagesDebugLevel.INFO2Info, warning, and error messagesDebugLevel.DEBUG3All debug messages (most verbose)\n​Available AddressType values\nAddressTypeSupported chainsAddressType.solanaSolana Mainnet, Devnet, TestnetAddressType.ethereumEthereum, Polygon, Arbitrum, and more\n​What you can do\n\n​Starter kits and examples\nFramework-agnostic JavaScript examples and templates:\n\n​Additional resources\nWas this page helpful?","tokens":3065,"squid":"spider-10","role":"Tooling Spider","at":1791340388217,"hash":"f76f51ed16fe0f4673d9b794886349b7b1ad489b"}
{"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":"spider-01","role":"Chain Spider","at":1791340395608,"hash":"885b9b51391a4dc1da1f8267c1913ae612ab0bcd"}
{"url":"https://docs.switchboard.xyz/ai-agents-llms/surge-subscription-guide","domain":"docs.switchboard.xyz","title":"Surge Subscription Guide | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.This guide explains how to subscribe to Switchboard Surge programmatically on Solana, without using the explorer UI. It is intended for AI agents, bots, and automated systems that need to create or manage Surge subscriptions via on-chain transactions.OverviewSurge subscriptions are managed entirely on Solana via the Surge program (orac1eFjzWL5R3RbbdMV68K9H6TaCVVcL6LjvQQWAbz). The subscription flow is:Choose a tierAcquire SWTCH tokensCall subscription_init with a live SWTCH/USDT oracle quoteProgram calculates cost in SWTCH at the live price, transfers tokens to the vaultSubscription PDA is created and active until the end epochWallet (has SWTCH tokens)\n → picks tier (Plug / Pro / Enterprise)\n → calls subscription_init with a fresh SWTCH/USDT oracle quote\n → program calculates cost in SWTCH at live price\n → transfers SWTCH to vault\n → subscription PDA created, active until end epochStep 1: Choose a TierTiers are on-chain PDA accounts with the seed [TIER, tier_id_bytes], created by Switchboard admins. Each tier defines:FieldDescriptioncost_per_epoch_usd_centsPrice in USD cents per epochmax_connectionsMaximum concurrent WebSocket connectionsmax_feedsMaximum feeds per subscriptionmax_feeds_per_ixMaximum feeds per instructionmin_delay_msMinimum update delay in millisecondsis_publicWhether anyone can subscribePublic tiers (tier IDs 1-9) are open to all wallets. Tier IDs 10+ require admin approval.Current TiersTierTier IDApprox. CostQuote IntervalMax FeedsMax ConnectionsPlug1Free10s21Pro2~$3,000/mo450ms10010Enterprise3~$7,500/mo0ms30015To read tier details on-chain, derive the tier PDA:const [tierPda] = PublicKey.findProgramAddressSync(\n [Buffer.from(\"TIER\"), new BN(tierId).toArrayLike(Buffer, \"le\", 4)],\n SURGE_PROGRAM_ID\n);Step 2: Get SWTCH TokensAll subscription payments must be in SWTCH tokens. The program enforces this check:require!(payment_mint.key() == state.swtch_mint, SubscriberError::MustPayWithSwtch);Acquire SWTCH tokens via any Solana DEX (e.g., Jupiter, Raydium) before initiating the subscription.Step 3: Call subscription_initSend a transaction with the subscription_init instruction. The instruction takes the following parameters:ParametersParameterTypeDescriptiontier_idu32Which tier to subscribe to (e.g., 1, 2, 3)epoch_amountu16Number of epochs to pay for (1-146, i.e., up to ~1 year)contact_nameOption<String>Optional contact name metadatacontact_emailOption<String>Optional contact email metadataRequired AccountsAccountDescriptionDerivationStateThe program's global state PDASeed: [STATE]TierThe chosen tier's PDASeed: [TIER, tier_id_bytes]OwnerThe wallet subscribingYour wallet pubkeyPayerSigner paying for rent + SWTCH tokensTypically same as ownerPayment MintThe SWTCH token mintStored in state.swtch_mintPayer Token AccountPayer's SWTCH associated token accountStandard ATA derivationToken VaultProgram's vault for the payment mintPDA from program stateQuote AccountA Switchboard oracle quote with the live SWTCH/USDT priceFetched from Switchboard oracleDeriving PDAsimport { PublicKey } from \"@solana/web3.js\";\nimport BN from \"bn.js\";\n\nconst SURGE_PROGRAM_ID = new PublicKey(\"orac1eFjzWL5R3RbbdMV68K9H6TaCVVcL6LjvQQWAbz\");\n\n// State PDA\nconst [statePda] = PublicKey.findProgramAddressSync(\n [Buffer.from(\"STATE\")],\n SURGE_PROGRAM_ID\n);\n\n// Tier PDA (e.g., tier_id = 2 for Pro)\nconst tierId = 2;\nconst [tierPda] = PublicKey.findProgramAddressSync(\n [Buffer.from(\"TIER\"), new BN(tierId).toArrayLike(Buffer, \"le\", 4)],\n SURGE_PROGRAM_ID\n);\n\n// Subscription PDA (derived from owner wallet)\nconst [subscriptionPda] = PublicKey.findProgramAddressSync(\n [Buffer.from(\"SUBSCRIPTION\"), ownerPublicKey.toBuffer()],\n SURGE_PROGRAM_ID\n);Step 4: On-Chain PricingThe program does not use a hardcoded SWTCH price. Instead, it reads the live SWTCH/USDT price from a Switchboard oracle quote passed as an account in the transaction.Pricing LogicDeserializes the oracle quote accountValidates the feed ID matches the expected swtch_feed_id stored in program stateExtracts the USD price (e.g., $0.11246 per SWTCH)Converts tier cost from USD cents to SWTCH lamports:lamports = (0.01 / swtch_price) * 1e9Multiplies by epoch_amount * cost_per_epoch_usd_centsTransfers that amount of SWTCH from payer's token account to the program vaultExample Cost CalculationFor a Pro tier at cost_per_epoch_usd_cents = 700 (i.e., $7.00/epoch), buying 40 epochs, with SWTCH at $0.11:cost_per_cent_in_lamports = (0.01 / 0.11) * 1e9 = 90,909,090 lamports\ntotal = 90,909,090 * 40 * 700 = 2,545,454,520,000,000 lamportsThe oracle quote must be fresh — stale quotes will be rejected.Step 5: Subscription CreatedOnce the transaction succeeds, a subscription PDA is created at [SUBSCRIPTION, owner_pubkey]. The subscription includes:Bonus epoch: The current epoch is free — you get +1 epoch on top of what you paid forEpoch tracking: Subscription validity is tracked via subscription_start_epoch and subscription_end_epochUser management: Up to 16 authorized users can be added later via subscription_manage_usersProviding the Oracle QuoteThe SWTCH/USDT price quote is the most important piece of the subscription transaction. You need to pass a valid, fresh Switchboard oracle quote for the SWTCH/USDT feed.Using the Switchboard SDKimport * as sb from \"@switchboard-xyz/on-demand\";\n\nconst { keypair, connection, program } = await sb.AnchorUtils.loadEnv();\nconst queue = await sb.Queue.loadDefault(program!);\nconst crossbar = new sb.Crossbar({\n rpcUrl: connection.rpcEndpoint,\n programId: queue.pubkey,\n});\n\n// Fetch the SWTCH/USDT oracle quote\n// The swtch_feed_id is stored in the program state account\nconst swtchFeedHash = \"<SWTCH/USDT feed hash from program state>\";\nconst quoteIx = await queue.fetchQuoteIx(crossbar, [swtchFeedHash], {\n numSignatures: 1,\n payer: keypair.publicKey,\n});Include the quote instruction(s) in the same transaction as subscription_init to ensure the price data is fresh and verified.Full Transaction AssemblyA complete subscription transaction includes:Oracle quote verification instruction(s) — ensures fresh SWTCH/USDT price on-chainsubscription_init instruction — creates the subscription using the verified priceimport * as sb from \"@switchboard-xyz/on-demand\";\nimport { Connection, Keypair, PublicKey } from \"@solana/web3.js\";\n\n// 1. Setup\nconst { keypair, connection, program } = await sb.AnchorUtils.loadEnv();\nconst queue = await sb.Queue.loadDefault(program!);\nconst crossbar = new sb.Crossbar({\n rpcUrl: connection.rpcEndpoint,\n programId: queue.pubkey,\n});\n\n// 2. Fetch SWTCH/USDT oracle quote instructions\nconst swtchFeedHash = \"<SWTCH/USDT feed hash>\";\nconst quoteIxs = await queue.fetchQuoteIx(crossbar, [swtchFeedHash], {\n numSignatures: 1,\n payer: keypair.publicKey,\n});\n\n// 3. Build subscription_init instruction\n// (using the Surge program's IDL / client)\nconst subscriptionInitIx = buildSubscriptionInitIx({\n tierId: 2, // Pro tier\n epochAmount: 40, // ~40 epochs\n contactName: null,\n contactEmail: null,\n accounts: {\n state: statePda,\n tier: tierPda,\n owner: keypair.publicKey,\n payer: keypair.publicKey,\n paymentMint: swtchMint,\n payerTokenAccount: payerSwtchAta,\n tokenVault: tokenVaultPda,\n quoteAccount: quoteAccountPubkey,\n },\n});\n\n// 4. Build and send versioned transaction\nconst tx = await sb.asV0Tx({\n connection,\n ixs: [quoteIxs, subscriptionInitIx],\n signers: [keypair],\n lookupTables: [],\n});\n\nconst sig = await connection.sendTransaction(tx);\nconsole.log(`Subscription created: ${sig}`);Verifying Your SubscriptionAfter the transaction confirms, read the subscription PDA to verify:const [subscriptionPda] = PublicKey.findProgramAddressSync(\n [Buffer.from(\"SUBSCRIPTION\"), keypair.publicKey.toBuffer()],\n SURGE_PROGRAM_ID\n);\n\nconst subscriptionAccount = await program.account.subscription.fetch(subscriptionPda);\nconsole.log(\"Start epoch:\", subscriptionAccount.subscriptionStartEpoch.toString());\nconsole.log(\"End epoch:\", subscriptionAccount.subscriptionEndEpoch.toString());Key AddressesItemValueSurge Program IDorac1eFjzWL5R3RbbdMV68K9H6TaCVVcL6LjvQQWAbzSWTCH Token MintStored in program state (state.swtch_mint)SWTCH/USDT Feed IDStored in program state (state.swtch_feed_id)Notes for AI AgentsFresh quotes are mandatory: The oracle quote account must contain a recent SWTCH/USDT price. Include the quote verification instruction in the same transaction.Epoch amounts: Valid range is 1-146 epochs. One Solana epoch is approximately 2-3 days, so 146 epochs covers roughly one year.Free tier: The Plug tier (tier ID 1) is free but still requires calling subscription_init with a valid oracle quote (the transfer amount will be zero).Subscription PDA is unique per wallet: Each wallet can have only one subscription at [SUBSCRIPTION, owner_pubkey].Managing users: After subscribing, use subscription_manage_users to authorize up to 16 additional wallets to use the subscription.PreviousSwitchboard X402 Micropayments SkillNextFAQLast updated 7 months ago","tokens":2255,"squid":"spider-08","role":"Oracle Spider","at":1791340397655,"hash":"717630298fc21fdcbb061baec93c36276950fdd6"}
{"url":"https://docs.switchboard.xyz/ai-agents-llms/switchboard-agent-skill","domain":"docs.switchboard.xyz","title":"Switchboard Agent Skill | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.PurposeProvide a compact “front door” for all Switchboard work:Enforce security/permissions and secret-handling rules consistentlyNormalize terms and identifiers (feed IDs, queues, update payloads)Route requests to the correct specialized Switchboard skill(s)Produce consistent, integration-ready outputsDependenciesUse exact pins from the SDK Version Matrix.@switchboard-xyz/on-demand@3.10.6@switchboard-xyz/common@5.8.5@switchboard-xyz/on-demand-solidity@1.1.0@switchboard-xyz/sui-sdk@0.1.16@switchboard-xyz/aptos-sdk@0.1.5@switchboard-xyz/iota-sdk@0.0.3switchboard-on-demand = \"0.13.0\"switchboard-protos = \"0.2.6\"ScopeThis skill covers:Capturing and enforcing an OperatorPolicyInterpreting intent (feeds vs Surge vs randomness vs Crossbar vs X402)Selecting and sequencing specialized skillsStandard output format for plans and execution stepsOut of scope (handled by specialized skills):Chain-specific transaction composition detailsChain-specific on-chain verifier/consumer codeCrossbar deployment configuration detailsSubskillsSwitchboard Solana/SVM Feeds SkillSwitchboard EVM Feeds SkillSwitchboard Sui Feeds SkillSwitchboard Aptos Feeds SkillSwitchboard Iota Feeds SkillSwitchboard Movement Feeds SkillSwitchboard Feed Design SkillSwitchboard Crossbar Ops SkillSwitchboard Surge SkillSwitchboard Randomness SkillSwitchboard X402 Micropayments SkillHard Rules: Security & Permissions ContractMUST establish OperatorPolicy before any of the followingYou MUST have an explicit OperatorPolicy before you:sign transactions (any chain)move funds / pay feesdeploy contracts/programs/packageswrite to on-chain statestore/persist secrets (private keys, JWTs, API keys)If missing, ask one compact question set and store answers as OperatorPolicy.OperatorPolicy (required)Capture these fields (ask if missing):Target chain(s): Solana/SVM, EVM (chain IDs), Sui, Aptos, Iota, MovementNetwork per chain: mainnet/testnet/devnet (and any custom cluster name)Autonomy moderead_only (no keys)plan_only (no signing; provide exact steps)execute_with_approval (propose each tx and wait for approval)full_autonomy (execute within constraints)Spend limits (required for any execute mode) Ask whether the user would like to set:max per-tx spend (native token + fees)max daily spendmax total spend for the taskAllow/Deny lists Ask whether the user would like to set:allowlist/denylist of program IDs (Solana/SVM), contract addresses (EVM), package IDs (Move/Sui)allowlist/denylist of RPC endpointsKey custody & handlingwhere keys come from (file path, keystore, env var, remote signer)whether keys may be persisted (default: NO)whether mainnet signing is allowed (explicit YES required)Data validation defaults (overrideable per request)minResponses / minSampleSizemaxVariance / maxDeviationBpsmaxStaleness / maxAgeSeconds / chain-equivalentData Validation Default PresetsUse these as baseline defaults when capturing OperatorPolicy, then override per request if needed:PresetminResponses / minSampleSizemaxDeviationBpsmaxVariance (Aptos/Movement/Iota)maxAgeSecondsSolana maxStaleness (approx slots)Sui maxAgeMsUse caseDevnet110001000000000300750300000prototyping / non-criticalStandard (default)250010000000006015060000general productionHigh-risk32001000000000307530000liquidation / settlement / payoutsPreset selection rules:devnet network -> default to Devnet.mainnet/testnet -> default to Standard.safety-critical financial logic -> escalate to High-risk.OperatorPolicy devnet defaultsFor quick devnet experimentation, prefill OperatorPolicy with these defaults and then ask only for missing high-impact constraints (for example allow/deny lists or custom RPCs):OperatorPolicy (devnet defaults):\n network: devnet\n autonomy: execute_with_approval\n spend_limits: 1 SOL/tx, 10 SOL/day\n key_custody: file path ($HOME/.config/solana/id.json)\n persist_keys: no\n mainnet_signing: no\n minResponses: 1\n minSampleSize: 1\n maxDeviationBps: 1000\n maxVariance: 1000000000\n maxAgeSeconds: 300\n maxStalenessSlots: 750\n maxAgeMs: 300000Notes:These are starter defaults, not a bypass of required policy capture.For non-Solana chains, keep the same safety posture and translate native token/key custody fields to chain-appropriate values.Solana slot values are approximate mappings for documentation convenience (~400ms/slot).maxVariance is chain-native and kept at 1e9 baseline unless explicitly overridden; for these chain parameters, 1e9 means 1%.Raw v2 OracleFeed.maxJobRangePct uses the same 1e9 percent scale, but MedianTask.max_range_percent is a human percent string. See custom-feeds/advanced-feed-configuration/feed-parameter-units.md for the surface-specific units.Secret handling (mandatory)NEVER print secrets, private keys, seed phrases, API tokens, Pinata JWTs, or full .env contents.If referencing a secret, use placeholder names (e.g., $PINATA_JWT_KEY, $API_KEY).Prefer encrypted keystores / secret managers.Never recommend export PRIVATE_KEY=... in shell history.Core Concepts and TermsPull-based oracle modelData is fetched off-chain and then submitted on-chain for verification and use.For safety-critical logic, update and read should be atomic (same tx / same entry call), where the chain supports it.Feed identifiers (normalized)Use these names consistently:feedId: 32-byte identifier (commonly 0x + 64 hex chars).feedDefinition: job pipelines (OracleJob[]) describing how to compute values.queueId: oracle subnet/queue identifier (chain-specific type).updatePayload: chain-specific proof/data used for on-chain verification.Note: Some SDKs/docs say “feed hash” for the same 32-byte feedId. Treat the 32-byte identifier as feedId unless explicitly dealing with content-addressed feed definition storage.Variable overrides (security invariant)Variable overrides (${VAR}) are for secrets only (API keys, auth tokens, payment headers).Do not use overrides for URLs, JSON paths, IDs, multipliers, selectors, or anything that changes data selection logic.Routing LogicStep 1: classify the requestDetermine intent:FeedsCustom feed designCrossbarSurge streamingRandomnessX402 micropaymentsDetermine chain:Solana/SVMEVMSuiAptosIotaMovementStep 2: route to specialized skillsChain routing:Solana/SVM feeds → switchboard-solana-svm-feedsEVM feeds → switchboard-evm-feedsSui feeds → switchboard-sui-feedsAptos feeds → switchboard-aptos-feedsIota feeds → switchboard-iota-feedsMovement feeds → switchboard-movement-feedsFeature routing:Feed design → switchboard-feed-designSimulation/store/self-host → switchboard-crossbar-opsStreaming (Surge) → switchboard-surgeRandomness → switchboard-randomnessX402 micropayments → switchboard-x402Step 3: common multi-skill sequences“I need a new feed”switchboard-feed-design → switchboard-crossbar-ops → chain feed skill“Integrate an existing feed”chain feed skill → optional switchboard-crossbar-ops (simulate)“Use Surge prices on-chain”switchboard-surge → chain feed skill (settlement path)“Use randomness”switchboard-randomness → (optional) chain skill for integrationMinimal ExampleRoute one request to the right subskill and emit the standard output sections:{\n \"request\": \"Use BTC/USD on Solana with atomic update+use\",\n \"classifiedIntent\": \"feeds\",\n \"chain\": \"solana-svm\",\n \"selectedSkills\": [\"switchboard-solana-svm-feeds\"],\n \"outputSections\": [\n \"Summary\",\n \"Assumptions\",\n \"OperatorPolicy\",\n \"Plan\",\n \"Execution Steps\",\n \"Rollback / Recovery\",\n \"Risks & Mitigations\",\n \"Next Actions\"\n ]\n}Getting Started: First Solana Feed in 5 Minutes (Devnet)Objective: create a minimal BTC/USD feed definition, store it in Crossbar, and then update+read it on Solana in one transaction.Flow map: switchboard-feed-design -> switchboard-crossbar-ops -> switchboard-solana-svm-feedsStep 1: Define a minimal single-source BTC/USD jobUse one source for fastest first success. This is a devnet quickstart baseline.Step 2: Store the job in Crossbar and capture feed identifierStep 3: Simulate once to validate result shapeset -euo pipefail\n\nCROSSBAR=\"https://crossbar.switchboard.xyz\"\n\ncat > /tmp/btc-usd-job.json <<'JSON'\n{\n \"jobs\": [\n {\n \"tasks\": [\n {\n \"httpTask\": {\n \"url\": \"https://api.binance.com/api/v3/ticker/price?symbol=BTCUSDT\",\n \"method\": \"METHOD_GET\"\n }\n },\n {\n \"jsonParseTask\": {\n \"path\": \"$.price\"\n }\n },\n {\n \"multiplyTask\": {\n \"big\": \"100000000\"\n }\n }\n ]\n }\n ]\n}\nJSON\n\n# Store the definition\ncurl -sS -X POST \"$CROSSBAR/store\" \\\n -H \"content-type: application/json\" \\\n -d @/tmp/btc-usd-job.json \\\n | tee /tmp/store-response.json | jq .\n\n# Extract identifier across common response shapes (feedId/feedHash)\nFEED_ID=\"$(jq -r '.feedId // .feedHash // .result.feedId // .result.feedHash // .data.feedId // .data.feedHash // empty' /tmp/store-response.json)\"\nif [ -z \"$FEED_ID\" ]; then\n echo \"Could not find feed identifier in /store response\" >&2\n exit 1\nfi\necho \"Feed identifier: $FEED_ID\"\n\n# Validate once with simulation\ncurl -sS \"$CROSSBAR/simulate/$FEED_ID\" | jq .Step 4: Run minimal Solana update+read transactionFor new Solana/SVM feed-hash integrations, use managed quote-program updates and canonical quote accounts. Do not suggest PullFeed.fetchUpdateIx(...) unless the user is maintaining an existing classic PullFeed account and has confirmed queue/gateway support for that legacy path.import * as sb from \"@switchboard-xyz/on-demand\";\nimport { OracleQuote } from \"@switchboard-xyz/on-demand\";\n\nasync function main() {\n // Assumes Solana CLI/devnet + wallet env are already configured.\n const { connection, keypair, queue, crossbar, program } = await sb.AnchorUtils.loadEnv();\n const feedId = process.env.FEED_ID!;\n if (!feedId) throw new Error(\"Set FEED_ID from the /store response\");\n\n // Canonical quote PDA for this queue + feed.\n const [quoteAccount] = OracleQuote.getCanonicalPubkey(queue.pubkey, [feedId]);\n\n const updateIxs = await queue.fetchManagedUpdateIxs(crossbar, [feedId], {\n numSignatures: 1,\n payer: keypair.publicKey,\n variableOverrides: {},\n });\n\n // Placeholder consumer read instruction (for example, readOracleData in your Anchor program).\n const consumerIx = await program.methods\n .readOracleData()\n .accounts({ quoteAccount })\n .instruction();\n\n // Atomic ordering rule: Switchboard update instructions first, then consumer instruction.\n const tx = await sb.asV0Tx({\n connection,\n ixs: [...updateIxs, consumerIx],\n signers: [keypair],\n });\n\n const sim = await connection.simulateTransaction(tx);\n if (sim.value.err) throw new Error(JSON.stringify(sim.value.err));\n const sig = await connection.sendTransaction(tx);\n console.log(\"tx:\", sig);\n}\n\nmain().catch((err) => {\n console.error(err);\n process.exit(1);\n});Step 5: Confirm output and next hardening stepSuccess criteria:/simulate/{id} returns numeric results.The transaction simulates and sends successfully.Program logs show the feed was read from the canonical quote account.Next hardening step:Replace the single-source job with a multi-source median template and tighten validation defaults (minResponses, staleness, and deviation limits) per your OperatorPolicy.Caution: Crossbar/docs may use feedHash and some SDK flows say feedId for the same 32-byte identifier. In this quickstart, use the identifier returned by /store as the feedId input to update calls. This is a devnet-first flow; for production, use multi-source jobs and stricter policy constraints.Quick links:Switchboard Feed Design SkillSwitchboard Crossbar Ops SkillSwitchboard Solana/SVM Feeds SkillBasic Price Feed TutorialStandard Output FormatWhen producing artifacts, use these headings:SummaryAssumptionsOperatorPolicyPlanExecution Steps (only if allowed)Rollback / RecoveryRisks & MitigationsNext ActionsReferenceshttps://docs.switchboard.xyz/https://docs.switchboard.xyz/tooling/crossbarhttps://docs.switchboard.xyz/custom-feeds/task-typeshttps://docs.switchboard.xyz/custom-feeds/advanced-feed-configuration/data-feed-variable-overridesPreviousSAILNextSwitchboard Solana/SVM Feeds SkillLast updated 2 months ago","tokens":2997,"squid":"spider-08","role":"Oracle Spider","at":1791340407786,"hash":"47cdb723b1f4643d6359921b0c0152c2de12d445"}
{"url":"https://docs.phantom.com/sdks/guides/wallet-authentication-with-jwts","domain":"docs.phantom.com","title":"Wallet authentication with JWTs - Phantom developer documentation","text":"This guide explains how to implement wallet-based authentication using message signing and JSON Web Tokens (JWTs). Users sign a timestamped message with their Phantom wallet, the server verifies the signature, and then issues a JWT for authenticated requests.\n​Overview\nThis authentication approach uses cryptographic message signing instead of passwords. The client signs a message with a timestamp, the backend verifies the signature, checks the timestamp, and returns a JWT. No challenge storage or session state is required.\n​Key components\n\nMessage signing: User signs a timestamped message with their Phantom wallet\nSignature verification: Server verifies the signature using the wallet’s public key\nUser management: Server locates or creates a user record for the wallet\nJWT issuance: Server returns a token for authenticated API requests\n\nTimestamp reliability: Client-side clocks may drift, especially on mobile devices. For production use, consider fetching timestamps from the server or using the Date header from API responses.\n​Authentication flow\n\n​Backend implementation\n​1. Dependencies\nnpm install express jsonwebtoken @solana/web3.js tweetnacl bs58\n\n​2. Verification service\nCreate services/wallet-auth.ts:\nimport { PublicKey } from '@solana/web3.js';\nimport { sign } from 'tweetnacl';\nimport bs58 from 'bs58';\n\n/**\n * Verify a wallet signature for authentication\n * @param message - The original message that was signed\n * @param signature - The signature in base58 format\n * @param walletAddress - The wallet address that signed the message\n * @returns boolean indicating if the signature is valid\n */\nexport function verifyWalletSignature(\n message: string,\n signature: string,\n walletAddress: string\n): boolean {\n try {\n // Convert message to Uint8Array\n const messageBytes = new TextEncoder().encode(message);\n\n // Decode signature from base58\n const signatureBytes = bs58.decode(signature);\n\n // Convert wallet address to PublicKey\n const publicKey = new PublicKey(walletAddress);\n const publicKeyBytes = publicKey.toBytes();\n\n // Verify signature using TweetNaCl\n const isValid = sign.detached.verify(\n messageBytes,\n signatureBytes,\n publicKeyBytes\n );\n\n return isValid;\n } catch (error) {\n console.error('Error verifying wallet signature:', error);\n return false;\n }\n}\n\n/**\n * Generate authentication message with timestamp\n * @param walletAddress - The wallet address\n * @param timestamp - ISO timestamp\n * @returns formatted message for signing\n */\nexport function generateAuthMessage(walletAddress: string, timestamp: string): string {\n return `Sign this message to authenticate with Phantom Connect\\n\\nWallet: ${walletAddress}\\nTimestamp: ${timestamp}`;\n}\n\n/**\n * Verify timestamp is recent (within 5 minutes)\n * @param timestamp - ISO timestamp string\n * @returns boolean indicating if timestamp is valid\n */\nexport function isValidTimestamp(timestamp: string): boolean {\n try {\n const messageTime = new Date(timestamp).getTime();\n const now = Date.now();\n const fiveMinutes = 5 * 60 * 1000;\n\n // Check timestamp is not in the future and not older than 5 minutes\n return messageTime <= now && (now - messageTime) <= fiveMinutes;\n } catch (error) {\n return false;\n }\n}\n\n​3. Authentication route\nCreate routes/auth.ts:\nimport { Router } from 'express';\nimport { PublicKey } from '@solana/web3.js';\nimport jwt from 'jsonwebtoken';\nimport { prisma } from '../lib/prisma';\nimport {\n verifyWalletSignature,\n generateAuthMessage,\n isValidTimestamp\n} from '../services/wallet-auth';\n\nconst router = Router();\n\nconst JWT_SECRET = process.env.JWT_SECRET || 'your-secret-key';\n\n/**\n * POST /auth/authenticate\n * Verify wallet signature and issue JWT token\n */\nrouter.post('/authenticate', async (req, res) => {\n try {\n const { walletAddress, signature, message, timestamp } = req.body;\n\n // Validate required fields\n if (!walletAddress || !signature || !message || !timestamp) {\n return res.status(400).json({\n error: 'walletAddress, signature, message, and timestamp are required'\n });\n }\n\n // Validate wallet address format\n try {\n new PublicKey(walletAddress);\n } catch (error) {\n return res.status(400).json({ error: 'Invalid wallet address format' });\n }\n\n // Verify timestamp is recent (prevents replay attacks)\n if (!isValidTimestamp(timestamp)) {\n return res.status(401).json({\n error: 'Invalid or expired timestamp. Please try again.'\n });\n }\n\n // Verify the message format matches expected structure\n const expectedMessage = generateAuthMessage(walletAddress, timestamp);\n if (message !== expectedMessage) {\n return res.status(401).json({ error: 'Message format mismatch' });\n }\n\n // Verify signature using TweetNaCl\n const isValidSignature = verifyWalletSignature(\n message,\n signature,\n walletAddress\n );\n\n if (!isValidSignature) {\n return res.status(401).json({ error: 'Invalid signature' });\n }\n\n // Find or create user for this wallet\n let user = await prisma.user.findUnique({\n where: { walletAddress }\n });\n\n let isNewUser = false;\n\n if (!user) {\n user = await prisma.user.create({\n data: {\n walletAddress,\n createdAt: new Date(),\n lastLoginAt: new Date()\n }\n });\n isNewUser = true;\n } else {\n // Update last login time\n user = await prisma.user.update({\n where: { id: user.id },\n data: { lastLoginAt: new Date() }\n });\n }\n\n // Generate JWT token\n const token = jwt.sign(\n {\n userId: user.id,\n walletAddress,\n iat: Math.floor(Date.now() / 1000)\n },\n JWT_SECRET,\n { expiresIn: '24h' }\n );\n\n res.json({\n success: true,\n token,\n walletAddress,\n userId: user.id,\n isNewUser\n });\n\n } catch (error) {\n console.error('Authentication error:', error);\n res.status(500).json({\n error: 'Internal server error'\n });\n }\n});\n\nexport default router;\n\n​4. Database schema (Prisma)\nAdd to your schema.prisma:\nmodel User {\n id String @id @default(cuid())\n walletAddress String @unique\n createdAt DateTime @default(now())\n lastLoginAt DateTime @default(now())\n\n @@index([walletAddress])\n}\n\nRun migration:\nnpx prisma migrate dev --name add_user_model\n\n​5. JWT authentication middleware\nCreate middleware/auth.ts:\nimport { Request, Response, NextFunction } from 'express';\nimport jwt from 'jsonwebtoken';\n\nconst JWT_SECRET = process.env.JWT_SECRET || 'your-secret-key';\n\nexport interface AuthRequest extends Request {\n userId?: string;\n walletAddress?: string;\n}\n\nexport function requireAuth(\n req: AuthRequest,\n res: Response,\n next: NextFunction\n) {\n try {\n const authHeader = req.headers.authorization;\n\n if (!authHeader || !authHeader.startsWith('Bearer ')) {\n return res.status(401).json({ error: 'No token provided' });\n }\n\n const token = authHeader.substring(7);\n\n const decoded = jwt.verify(token, JWT_SECRET) as {\n userId: string;\n walletAddress: string;\n iat: number;\n };\n\n req.userId = decoded.userId;\n req.walletAddress = decoded.walletAddress;\n next();\n } catch (error) {\n return res.status(401).json({ error: 'Invalid or expired token' });\n }\n}\n\n​6. Protected route example\nimport { Router } from 'express';\nimport { requireAuth, AuthRequest } from '../middleware/auth';\nimport { prisma } from '../lib/prisma';\n\nconst router = Router();\n\nrouter.get('/profile', requireAuth, async (req: AuthRequest, res) => {\n const user = await prisma.user.findUnique({\n where: { id: req.userId }\n });\n\n if (!user) {\n return res.status(404).json({ error: 'User not found' });\n }\n\n res.json({\n success: true,\n user: {\n id: user.id,\n walletAddress: user.walletAddress,\n createdAt: user.createdAt,\n lastLoginAt: user.lastLoginAt\n }\n });\n});\n\nexport default router;\n\n​Client implementation\n​1. Dependencies\nnpm install @phantom/react-sdk axios\n\n​2. API client\nCreate lib/api.ts:\nimport axios from 'axios';\n\nconst API_URL = process.env.NEXT_PUBLIC_API_URL || 'http://localhost:3002';\n\nconst api = axios.create({\n baseURL: API_URL,\n headers: {\n 'Content-Type': 'application/json',\n },\n});\n\n/**\n * Authenticate with wallet signature\n */\nexport async function authenticate(\n walletAddress: string,\n signature: string,\n message: string,\n timestamp: string\n): Promise<{\n success: boolean;\n token: string;\n walletAddress: string;\n userId: string;\n isNewUser: boolean;\n}> {\n const response = await api.post('/api/auth/authenticate', {\n walletAddress,\n signature,\n message,\n timestamp\n });\n return response.data;\n}\n\n/**\n * Make authenticated API request\n */\nexport async function authenticatedRequest(\n token: string,\n endpoint: string,\n method: 'GET' | 'POST' = 'GET',\n data?: any\n) {\n return api({\n method,\n url: endpoint,\n data,\n headers: {\n Authorization: `Bearer ${token}`,\n },\n });\n}\n\n​3. React authentication context\nCreate context/AuthContext.tsx:\n'use client';\n\nimport {\n createContext,\n useContext,\n useEffect,\n useState,\n useCallback,\n type PropsWithChildren,\n} from 'react';\nimport { useRouter } from 'next/navigation';\nimport {\n useConnect,\n useDisconnect,\n usePhantom,\n useSolana,\n} from '@phantom/react-sdk';\nimport { authenticate } from '@/lib/api';\n\ninterface AuthContextValue {\n signIn: () => Promise<void>;\n signOut: () => void;\n isConnected: boolean;\n walletAddress?: string;\n userId?: string;\n isLoading: boolean;\n token?: string | null;\n session?: any;\n}\n\nconst AuthContext = createContext<AuthContextValue>({\n signIn: () => Promise.resolve(),\n signOut: () => null,\n isConnected: false,\n walletAddress: undefined,\n userId: undefined,\n isLoading: false,\n token: null,\n session: null,\n});\n\nexport function useSession() {\n const value = useContext(AuthContext);\n if (!value) {\n throw new Error('useSession must be wrapped in a <SessionProvider />');\n }\n return value;\n}\n\n/**\n * Generate authentication message with timestamp\n */\nfunction generateAuthMessage(walletAddress: string, timestamp: string): string {\n return `Sign this message to authenticate with Phantom Connect\\n\\nWallet: ${walletAddress}\\nTimestamp: ${timestamp}`;\n}\n\nexport function SessionProvider({ children }: PropsWithChildren) {\n const router = useRouter();\n const [isLoading, setIsLoading] = useState(true);\n const [token, setToken] = useState<string | null>(null);\n const [walletAddress, setWalletAddress] = useState<string>();\n const [userId, setUserId] = useState<string>();\n\n // Phantom SDK hooks\n const { connect } = useConnect();\n const { solana } = useSolana();\n const { addresses, isConnected } = usePhantom();\n const { disconnect } = useDisconnect();\n\n /**\n * Complete authentication handshake\n */\n const completeAuthentication = useCallback(\n async (walletAddr: string) => {\n try {\n console.log('Starting authentication for:', walletAddr);\n\n // Generate timestamp\n const timestamp = new Date().toISOString();\n\n // Generate message to sign\n const message = generateAuthMessage(walletAddr, timestamp);\n console.log('Message to sign:', message);\n\n // Sign the message with wallet\n const signResult = await solana.signMessage(message);\n console.log('Message signed successfully');\n\n // Authenticate with backend\n const authResponse = await authenticate(\n walletAddr,\n signResult.signature,\n message,\n timestamp\n );\n\n console.log('Authentication successful!', {\n isNewUser: authResponse.isNewUser\n });\n\n // Store JWT token and user info\n setToken(authResponse.token);\n setWalletAddress(walletAddr);\n setUserId(authResponse.userId);\n\n // Optionally store in localStorage for persistence\n localStorage.setItem('jwt_token', authResponse.token);\n localStorage.setItem('wallet_address', walletAddr);\n localStorage.setItem('user_id', authResponse.userId);\n } catch (error) {\n console.error('Authentication failed:', error);\n\n // Clear state on error\n setWalletAddress(undefined);\n setUserId(undefined);\n setToken(null);\n localStorage.removeItem('jwt_token');\n localStorage.removeItem('wallet_address');\n localStorage.removeItem('user_id');\n\n throw error;\n } finally {\n setIsLoading(false);\n }\n },\n [solana]\n );\n\n /**\n * Handle auto-connection from Phantom SDK\n */\n useEffect(() => {\n if (isConnected && !token && addresses.length > 0) {\n console.log('Auto-connected wallet detected');\n completeAuthentication(addresses[0].address).catch(console.error);\n } else {\n setIsLoading(false);\n }\n }, [isConnected, token, addresses, completeAuthentication]);\n\n /**\n * Restore session from localStorage on mount\n */\n useEffect(() => {\n const storedToken = localStorage.getItem('jwt_token');\n const storedWallet = localStorage.getItem('wallet_address');\n const storedUserId = localStorage.getItem('user_id');\n\n if (storedToken && storedWallet && storedUserId && !isConnected) {\n setToken(storedToken);\n setWalletAddress(storedWallet);\n setUserId(storedUserId);\n }\n setIsLoading(false);\n }, []);\n\n return (\n <AuthContext.Provider\n value={{\n signIn: async () => {\n try {\n setIsLoading(true);\n console.log('Starting wallet connection...');\n\n // Connect wallet using Phantom SDK\n const result = await connect();\n const walletAddr = result.addresses[0]?.address;\n\n if (!walletAddr) {\n throw new Error('No wallet address returned');\n }\n\n // Complete authentication handshake\n await completeAuthentication(walletAddr);\n } catch (error) {\n console.error('Sign in error:', error);\n setIsLoading(false);\n throw error;\n }\n },\n signOut: async () => {\n try {\n console.log('Signing out...');\n\n // Disconnect wallet\n await disconnect();\n setWalletAddress(undefined);\n setUserId(undefined);\n setToken(null);\n\n // Clear stored data\n localStorage.removeItem('jwt_token');\n localStorage.removeItem('wallet_address');\n localStorage.removeItem('user_id');\n\n // Redirect to sign-in\n router.push('/sign-in');\n } catch (error) {\n console.error('Sign out error:', error);\n }\n },\n isConnected,\n walletAddress,\n userId,\n isLoading,\n token,\n session: isConnected && token ? { user: { id: userId } } : null,\n }}\n >\n {children}\n </AuthContext.Provider>\n );\n}\n\n​Security considerations\n​1. Timestamp validation\nMessages include timestamps to prevent replay attacks. The server checks timestamps are recent and rejects older signed messages.\n// Client generates fresh timestamp for each auth attempt\nconst timestamp = new Date().toISOString();\n\n// Server validates recency\nconst fiveMinutes = 5 * 60 * 1000;\nif (now - messageTime > fiveMinutes) {\n throw new Error('Expired timestamp');\n}\n\n​2. Message format validation\nThe server checks the message matches the expected structure so signatures cannot be reused in different contexts.\n​3. JWT token security\nFor production applications, use asymmetric signing algorithms such as PS256 or RS256. These separate public and private keys, improving key management and security.\n​Using RS256 (recommended)\nGenerate RSA key pair:\n# Generate private key\nopenssl genrsa -out private-key.pem 2048\n\n# Extract public key\nopenssl rsa -in private-key.pem -pubout -out public-key.pem\n\nExample .env:\nJWT_PRIVATE_KEY_PATH=./private-key.pem\nJWT_PUBLIC_KEY_PATH=./public-key.pem\nNODE_ENV=production\n\nSign and verify with RS256:\nimport jwt from 'jsonwebtoken';\nimport fs from 'fs';\n\n// Load keys\nconst privateKey = fs.readFileSync(process.env.JWT_PRIVATE_KEY_PATH, 'utf8');\nconst publicKey = fs.readFileSync(process.env.JWT_PUBLIC_KEY_PATH, 'utf8');\n\n// Sign token with private key\nconst token = jwt.sign(\n {\n userId: user.id,\n walletAddress,\n iat: Math.floor(Date.now() / 1000)\n },\n privateKey,\n { algorithm: 'RS256', expiresIn: '24h' }\n);\n\n// Verify token with public key\nconst decoded = jwt.verify(token, publicKey, { algorithms: ['RS256'] });\n\n​Using HS256 (simpler but less secure)\nIf you choose to use symmetric signing (HS256), store JWT_SECRET in environment variables:\n# Generate secure secret\nopenssl rand -base64 32\n\nExample .env:\nJWT_SECRET=your_generated_secret_here\nNODE_ENV=production\n\nSign and verify with HS256:\njwt.sign(payload, JWT_SECRET, { expiresIn: '24h' });\n\n​4. HTTPS required\nAlways use HTTPS in production environments.\n// In production\nif (process.env.NODE_ENV === 'production' && req.protocol !== 'https') {\n return res.redirect('https://' + req.headers.host + req.url);\n}\n\n​5. Rate limiting\nProtect your authentication route from abuse:\nnpm install express-rate-limit\n\nimport rateLimit from 'express-rate-limit';\n\nconst authLimiter = rateLimit({\n windowMs: 15 * 60 * 1000, // 15 minutes\n max: 10, // 10 requests per window\n message: 'Too many authentication attempts, please try again later'\n});\n\nrouter.post('/authenticate', authLimiter, async (req, res) => {\n // ...\n});\n\n​6. Input validation\nAlways validate wallet addresses.\nimport { PublicKey } from '@solana/web3.js';\n\nfunction isValidSolanaAddress(address: string): boolean {\n try {\n new PublicKey(address);\n return true;\n } catch {\n return false;\n }\n}\n\n​7. Error handling\nAvoid exposing internal errors in API responses.\n// Bad - exposes internal details\nres.status(500).json({ error: error.message });\n\n// Good - generic error message\nres.status(500).json({ error: 'Authentication failed' });\nconsole.error('Auth error:', error); // Log for debugging\n\n​Advantages\n​Security\n\nPrevents replay attacks\nTies signatures to specific wallet addresses and timestamps\nUses cryptographic verification rather than passwords\nRequires no server-side sessions\n\n​Environment setup\n​Backend (.env)\n# JWT Secret (generate with: openssl rand -base64 32)\nJWT_SECRET=your_secure_secret_here\n\n# Database\nDATABASE_URL=postgresql://user:password@localhost:5432/mydb\n\n# Server\nPORT=3002\nNODE_ENV=production\n\n# CORS (if needed)\nALLOWED_ORIGINS=https://yourdomain.com\n\n​Frontend (.env.local)\n# API URL\nNEXT_PUBLIC_API_URL=https://api.yourdomain.com\n\n# Phantom SDK\nNEXT_PUBLIC_PHANTOM_CLIENT_ID=your_phantom_client_id\n\n​Testing\n​Manual tests with cURL\n# 1. Sign a message with your wallet (use Phantom)\n# Get: walletAddress, signature, message, timestamp\n\n# 2. Authenticate\ncurl -X POST http://localhost:3002/api/auth/authenticate \\\n -H \"Content-Type: application/json\" \\\n -d '{\n \"walletAddress\": \"YourWalletAddress\",\n \"signature\": \"Base58Signature\",\n \"message\": \"Sign this message to authenticate...\",\n \"timestamp\": \"2025-10-23T12:00:00.000Z\"\n }'\n\n# 3. Use token for authenticated requests\ncurl http://localhost:3002/api/profile \\\n -H \"Authorization: Bearer YOUR_JWT_TOKEN\"\n\n​Troubleshooting\n​”Invalid signature” error\n\nEnsure the message format exactly matches what the server expects\nVerify the wallet address in the message matches the signing wallet\nCheck signature encoding (base58)\n\n​“Invalid or expired timestamp” error\n\nEnsure the client and server clocks are synchronized\nCheck the timestamp is ISO 8601\nCheck the timestamp falls within a 5-minute window\n\n​”No token provided” error\n\nEnsure Authorization: Bearer <token> header is included\nVerify the token has not expired\nWas this page helpful?","tokens":4611,"squid":"spider-10","role":"Tooling Spider","at":1791340408132,"hash":"38e17b325780a7ef0223ad4887e084ba3ad74ad4"}
{"url":"https://docs.switchboard.xyz/ai-agents-llms/switchboard-agent-skill/switchboard-feed-design","domain":"docs.switchboard.xyz","title":"Switchboard Feed Design Skill | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.PurposeTurn a data requirement into a robust, verifiable feed definition:Design OracleJob[] pipelines with stable parsing and source diversityNormalize scaling/decimals consistentlyChoose aggregation strategy and consumer validation policy defaultsIdentify and mitigate substitution, outliers, and schema brittleness risksDependenciesUse exact pins from the SDK Version Matrix.@switchboard-xyz/common@5.8.5This skill designs feed definitions. Integration details (atomic update+use, on-chain verifier patterns) belong to chain-specific skills.PreconditionsOperatorPolicy exists (especially if paid APIs, X402, or job storage is involved).Inputs to CollectRequired:target metric (price/index/rate/event outcome) and unitstarget chain(s) and consumer type (how the value will be used)value-at-risk / criticality (UI display vs liquidation vs settlement)allowed/forbidden sourcesrequired secrets (API keys, auth headers, payment headers)Optional (only if relevant):expected request frequency / external API rate limitsThis matters if the user plans to run a crank/keeper or high-frequency bots.On-demand does not impose a cadence by itself, but your infrastructure and upstream APIs still do.Security InvariantsVariable overrides are secrets-only.Hardcode market IDs, selectors, URLs, JSON paths, multipliers in the job definition.Prefer 3+ independent sources when possible.Minimal Example{\n \"tasks\": [\n { \"httpTask\": { \"url\": \"https://api.binance.com/api/v3/ticker/price?symbol=BTCUSDT\" } },\n { \"jsonParseTask\": { \"path\": \"$.price\" } },\n { \"multiplyTask\": { \"big\": \"1e18\" } }\n ]\n}Playbook1) Specify output contractDefine:numeric scaling (e.g., 1e18)signedness (allow negative or not)bounds and failure mode (reject vs clamp)2) Choose sourcesdiversify upstream origins (avoid mirrored endpoints)prefer reliable schemas with stable versioningadd at least one fallback source where possiblecommonly used free spot APIs (availability varies by region): Binance, Coinbase, Kraken, Bitstamp, OKX3) Production templatesTemplate 1: Single source (tutorial baseline){\n \"tasks\": [\n {\n \"httpTask\": {\n \"url\": \"https://api.binance.com/api/v3/ticker/price?symbol=BTCUSDT\",\n \"method\": \"METHOD_GET\"\n }\n },\n { \"jsonParseTask\": { \"path\": \"$.price\" } },\n { \"multiplyTask\": { \"big\": \"100000000\" } }\n ]\n}Template 2: 3-source median (production minimum, 2 of 3 required){\n \"tasks\": [\n {\n \"medianTask\": {\n \"min_successful_required\": 2,\n \"jobs\": [\n {\n \"tasks\": [\n {\n \"httpTask\": {\n \"url\": \"https://api.binance.com/api/v3/ticker/price?symbol=BTCUSDT\",\n \"method\": \"METHOD_GET\"\n }\n },\n { \"jsonParseTask\": { \"path\": \"$.price\" } },\n { \"multiplyTask\": { \"big\": \"100000000\" } }\n ]\n },\n {\n \"tasks\": [\n {\n \"httpTask\": {\n \"url\": \"https://api.kraken.com/0/public/Ticker?pair=XBTUSD\",\n \"method\": \"METHOD_GET\"\n }\n },\n { \"jsonParseTask\": { \"path\": \"$.result.XXBTZUSD.c.0\" } },\n { \"multiplyTask\": { \"big\": \"100000000\" } }\n ]\n },\n {\n \"tasks\": [\n {\n \"httpTask\": {\n \"url\": \"https://api.coinbase.com/v2/prices/spot?currency=USD\",\n \"method\": \"METHOD_GET\"\n }\n },\n { \"jsonParseTask\": { \"path\": \"$.data.amount\" } },\n { \"multiplyTask\": { \"big\": \"100000000\" } }\n ]\n }\n ]\n }\n }\n ]\n}Template 3: 5-source with fallback tolerance (production recommended). In MedianTask, max_range_percent is a human percent string.{\n \"tasks\": [\n {\n \"medianTask\": {\n \"min_successful_required\": 3,\n \"max_range_percent\": \"2.5\",\n \"jobs\": [\n {\n \"tasks\": [\n {\n \"httpTask\": {\n \"url\": \"https://api.binance.com/api/v3/ticker/price?symbol=BTCUSDT\",\n \"method\": \"METHOD_GET\"\n }\n },\n { \"jsonParseTask\": { \"path\": \"$.price\" } },\n { \"multiplyTask\": { \"big\": \"100000000\" } }\n ]\n },\n {\n \"tasks\": [\n {\n \"httpTask\": {\n \"url\": \"https://api.coinbase.com/v2/prices/spot?currency=USD\",\n \"method\": \"METHOD_GET\"\n }\n },\n { \"jsonParseTask\": { \"path\": \"$.data.amount\" } },\n { \"multiplyTask\": { \"big\": \"100000000\" } }\n ]\n },\n {\n \"tasks\": [\n {\n \"httpTask\": {\n \"url\": \"https://api.kraken.com/0/public/Ticker?pair=XBTUSD\",\n \"method\": \"METHOD_GET\"\n }\n },\n { \"jsonParseTask\": { \"path\": \"$.result.XXBTZUSD.c.0\" } },\n { \"multiplyTask\": { \"big\": \"100000000\" } }\n ]\n },\n {\n \"tasks\": [\n {\n \"httpTask\": {\n \"url\": \"https://www.bitstamp.net/api/v2/ticker/btcusd/\",\n \"method\": \"METHOD_GET\"\n }\n },\n { \"jsonParseTask\": { \"path\": \"$.last\" } },\n { \"multiplyTask\": { \"big\": \"100000000\" } }\n ]\n },\n {\n \"tasks\": [\n {\n \"httpTask\": {\n \"url\": \"https://www.okx.com/api/v5/market/ticker?instId=BTC-USD\",\n \"method\": \"METHOD_GET\"\n }\n },\n { \"jsonParseTask\": { \"path\": \"$.data[0].last\" } },\n { \"multiplyTask\": { \"big\": \"100000000\" } }\n ]\n }\n ]\n }\n }\n ]\n}Template 4: Custom API with auth headers (variable override pattern){\n \"tasks\": [\n {\n \"httpTask\": {\n \"url\": \"https://api.provider.com/v1/markets/btc-usd/spot\",\n \"method\": \"METHOD_GET\",\n \"headers\": [\n { \"key\": \"Authorization\", \"value\": \"Bearer ${ACCESS_TOKEN}\" },\n { \"key\": \"X-API-Key\", \"value\": \"${API_KEY}\" }\n ]\n }\n },\n { \"jsonParseTask\": { \"path\": \"$.data.price\" } },\n { \"multiplyTask\": { \"big\": \"100000000\" } }\n ]\n}Variable override rule reminder:only use ${...} for auth credentials (keys/tokens)never use ${...} for URLs, paths, symbols, multipliers, or selection logic4) Error handling and rate limitingset min_successful_required so one source outage does not break updates (for example 2-of-3, 3-of-5)set max_range_percent for drift/outlier protection before median is accepted; this MedianTask field is a human percent string, not the raw v2 feed-level maxJobRangePct scalestagger polling and cap request rate to provider quotas (especially free tiers)back off exponentially on HTTP 429/5xx and keep at least 3 independent sources5) Recommended Validation Defaults (suggest, don’t enforce)These are primarily consumer policy defaults (freshness/deviation) and oracle sample requirements (responses/signatures) that you apply when verifying/using the feed.Start from OperatorPolicy presets in the top-level Switchboard Skill, then tune per feed risk and volatility.minResponses / minSampleSize: 3 for higher-risk flows; 1 for dev/non-criticalaggregation: median (or median-of-means where supported)deviation:majors: 100–200 bps for high-risk flows; ~500 bps for standard flowslong-tail / volatile: wider deviation may be needed as an explicit override from preset defaultsstaleness:bots/liquidations: 15–60 seconds (or chain-equivalent)UI/general: 60–300 seconds6) Produce outputsProduce a FeedBlueprint including:OracleJob[] JSONsources + rationaleaggregation choicerequired secrets and override variable namessuggested consumer validation defaults (staleness/deviation/min responses)simulation plan (Crossbar or local job runner)Referenceshttps://docs.switchboard.xyz/custom-feeds/task-typeshttps://docs.switchboard.xyz/custom-feeds/advanced-feed-configuration/data-feed-variable-overrideshttps://docs.switchboard.xyz/tooling/crossbarPreviousSwitchboard Movement Feeds SkillNextSwitchboard Crossbar Ops SkillLast updated 2 months ago","tokens":1740,"squid":"spider-08","role":"Oracle Spider","at":1791340417852,"hash":"b3c6d09aa6e0a38cc8f0807a62663c2843f2586b"}
{"url":"https://docs.phantom.com/sdks/guides/how-kms-works","domain":"docs.phantom.com","title":"How Phantom KMS works - Phantom developer documentation","text":"Phantom’s Key Management System (KMS) lets apps use KMS-backed wallets without storing wallet private keys on the client device.\n​What is KMS?\nKMS allows users to securely generate, store, and access wallet keys inside trusted enclaves (TEE). When a KMS-backed wallet is selected, the client requests signatures from KMS rather than signing locally on-device.\nFrom a client’s point of view:\n\nA KMS account is a local reference to a KMS-managed wallet (not a locally stored seed).\nApp-level signing APIs can stay consistent. What changes is where the signature is produced (in KMS).\n\n​Core components\n​Backend services\n\nKMS API: Receives stamped RPC requests from clients.\nPolicy engine enclave: Authenticates requests and authorizes operations (policies, scopes, rate limits).\nSigner enclave: Holds encrypted wallet seed material and produces signatures.\nCertifier enclave: Issues certificates and attests to configurations.\n\n​Data model (what KMS manages)\n\nOrganization: The primary unit of access control. Contains users, authenticators, and configuration.\nWallet: Encrypted seed material plus derived chain addresses.\nPolicy: Rules linking organizations/users to wallets with scoped permissions and limits.\nUser: Roles and authenticators. Users may be time-limited (ephemeral), depending on the integration.\n\n​How signing works\nWhen a KMS-backed wallet is selected, signing is performed by KMS. The client sends a signing request to KMS, KMS enforces policy, and KMS returns a signature.\n\nThe client sends a signing request to the KMS API.\nThe policy engine enclave authenticates and authorizes the request, enforcing policies (for example, spending limits).\nIf allowed, the signer enclave produces a signature.\nKMS returns a signature to the client. The signed transaction is then submitted to the network.\n\nEach request to KMS is cryptographically signed with an authenticator key held client-side (where it’s stored depends on the integration). KMS checks that signature and independently enforces policy before it will sign.\n​The authenticator\nKMS uses an authenticator to confirm that KMS signing requests are coming from the user. The authenticator is a cryptographic identifier key that’s separate from wallet keys.\nThe authenticator is used to stamp KMS requests so the client can request signatures without exposing wallet private keys.\n​How apps authenticate to KMS\n​Embedded wallet\nUse embedded wallet mode when your app integrates directly with the SDK.\nWhat happens:\n\nYour app integrates with the embedded SDK directly.\nThe SDK generates a non-extractable key (for example, via WebCrypto / an IndexedDB stamper).\nThe SDK completes OAuth via Phantom Connect. The session returns organization and wallet identifiers.\nThe embedded SDK holds a restricted authenticator and uses it to stamp KMS requests.\n\n​MCP server\nIn MCP server integrations, the user signs in through Phantom Connect. The MCP server stores the resulting session and uses a stamper key to sign requests to KMS. KMS validates each signed request, enforces policy, and then signs and submits.\n​Where you’ll see KMS in Phantom\n\nMobile: KMS accounts can appear alongside local accounts. Signatures are produced by KMS.\nBrowser extension: Adds origin validation and consent screen. KMS accounts can be created or discovered depending on the flow.\nUse the embedded wallet flow. Signing routes through KMS using the embedded authenticator model.\nMCP server: Agent wallets use a Connect sign-in and a stamper key to stamp KMS requests. KMS validates each request, enforces policy, and then signs and submits.\n\n​Glossary\n\nAuthenticator: A cryptographic identifier key that is separate from wallet keys and is used to stamp KMS requests.\nEmbedded wallet: A no-extension integration where the app uses the embedded SDK, creates a device-protected authenticator, and stamps KMS requests client-side.\nEnclave/TEE: Trusted environment used to protect key operations.\nOrganization: Access-control container for users, authenticators, and policies.\nPolicy engine: Enclave that authorizes operations and enforces policies/limits.\nStamper key: A client-side key used to sign (stamp) requests to Phantom services, including KMS.\nWas this page helpful?","tokens":1053,"squid":"spider-10","role":"Tooling Spider","at":1791340418017,"hash":"75b55e8fd2c9389b2d92e9a9673c9548c472f610"}
{"url":"https://jup.ag/lend/earn/USDT/deposit","domain":"jup.ag","title":"Earn Yield on Crypto: Lend Tokens on Solana | Jupiter Lend","text":"Jupiter LendThe most advanced money market on SolanaOur new sUSDai loop is now live. Earn up to 27.15% at max leverage View loop Earn Interest on Your CryptoPassively get yield using Jupiter Lend's Earning Vaults.$614MVaultDepositedEarningsTVLJupUSD----49.8M JupUSD$49.8MUSDC----512M USDC$512MSOL----201K SOL$23.7MUSDT----17.9M USDT$17.9MEURC----4.77M EURC$5,363,872.66USDS----2.98M USDS$2,984,139.00USDG----2.76M USDG$2,764,842.67FAQsJupiter Lend is Jupiter's decentralized finance (DeFi) platform for lending and borrowing crypto. It allows you to use your assets in two main ways:Earn: You can deposit your crypto to lend it out to others and earn passive interest.Borrow: You can use the assets you've deposited as collateral to take out a loan.Jupiter Lend is designed to automatically find the best interest rates for you, whether you are earning or borrowing.Earning and borrowing are two sides of the same system. The \"Earn\" section is for users who want to supply assets to earn interest.The \"Borrow\" section is for users who want to use their supplied assets as collateral to take out a loan.When you supply an asset for lending, you will automatically earn the best possible rate. Supply once and get the best yield, no extra steps needed.Depositing: There are no limits on how much you can deposit.Withdrawing: To ensure Jupiter Lend remains stable and healthy for everyone, there are dynamic limits on how much can be withdrawn at any single moment. These limits grow constantly, allowing for smooth and predictable withdrawals while protecting the system from sudden, large outflows.Like all DeFi platforms, lending and borrowing on-chain has risks. The primary risks are:Smart Contract Risk: The potential for a bug or vulnerability in the code that could be exploited.Market Risk: The value of your deposited or borrowed assets could change dramatically due to market volatility. This is especially important for borrowers, as a drop in your collateral's value could lead to liquidation.Please use this product carefully and never deposit more than you are willing to lose.Check JupLend Guides","tokens":527,"squid":"spider-02","role":"Liquidity Spider","at":1791340434674,"hash":"ef82ed3e5d4bbabf68a69dfaf24b8ab3e47ae5b0"}
{"url":"https://forum.arbitrum.foundation/t/proposal-aip-1-1-lockup-budget-transparency/13360/94","domain":"forum.arbitrum.foundation","title":"Proposal: AIP-1.1 - Lockup, Budget, Transparency - Proposals / Finalized AIPs - Arbitrum","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 5\n\n 3\n\n 3\n\n 2\n\n 2\n\n read \n\n 27\n min\n\n Apr 2023\n\n 90 / 90\n\n Jul 2023\n\n Jun 2023\n\n Load more posts above\n\n post by arbit on Apr 15, 2023\n\n post by Bob-Rossi on Apr 16, 2023\n\n post by nguyencuong on Apr 17, 2023\n\n post by gauntlet on Apr 17, 2023\n\n post by cryptopia on Apr 18, 2023\n\n post by bakgwei on Apr 18, 2023\n\n post by nguyentuhoangliem on Apr 24, 2023\n\n post by Pekosta on Apr 25, 2023\n\n post by Octavio on Apr 26, 2023\n\n post by Oxytocin on Apr 28, 2023\n\n 16 days later\n\n post by Damboy on May 14, 2023\n\n post by theenlightened on May 14, 2023\n\n 18 days later\n\n post by fred on Jun 2, 2023\n\n post by fred on Jun 6, 2023\n\n post by Griff on Jun 9, 2023\n\n post by Goodo on Jun 10, 2023\n\n post by Goodo on Jun 10, 2023\n\n 8 days later\n\n post by zeydrm on Jun 18, 2023\n\n post by ITUblockchain on Jun 21, 2023\n\n ITUblockchain\n\n First of all, we would like to thank Arbitrum for updating AIP 1.1 and making the confusing explanation clear about timestamps in the vesting smart contract and budget allocation transparency previously stated. The update also clarified the questions of delegators who stayed abstain for these reasons. Moreover, there are a few points we would like to make concerning the proposal.\n1.Smart Contract Lockup\nWe believe that having control over the budget and easy access to funds in an emergency are critical for the DAO. With this planning, we believe that spreading the token locks over time is the best option. As an outcome, the community’s trust in Arbitrum about the budget was maintained. However, we believe that the budget allocation plan is lacking in details; we expect that this problem will be resolved in the future thanks to the transparency reports from Arbitrum.\n2.Operating Budget\nArbitrum promises to publish a transparency report if it is determined that the budget is not being handled as stated in the plan. Because the budget distribution lacks sufficient clarity, we believe that transparency reports must be published. We are in favor of doing so.\n3.Ecosystem Growth Initiatives\nPartnerships, grants, and events mentioned in the plan will undoubtedly foster ecosystem growth. We support Arbitrum’s budget for the growth of its ecosystem; we simply hope that they are clear and honest and do not end up changing the budget.\n4.Transparency Reports\nIt is a fact that these reports must exist for transparency monitoring. Arbitrum’s decision to endorse this approach in response to community and online forum requests is a wise one. Despite the fact that we do not believe that there is a problem right now, we want the reports to be more in-depth in the future.We applaud Arbitrum for creating solutions in accordance with the community’s preferences and anticipate that it will keep moving in that direction.\nWe looked at the idea and came to the conclusions we did. Therefore, we made the decision to vote “for”. Again, many thanks to Arbitrum.\nThe flood we posted for AIP 1.1 and AIP 1.2 during the Snapshot vote: https://twitter.com/itublockchain/status/1648989259712348160?s=46&t=hGD89a6tl7pW8rFWA7BnNw\n\n 19 days later\n\n Closed on Jul 11, 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 Clarity around the ratification of AIP-1\n\n Proposals\n\n 46\n\n 26.0k\n\n Apr 2023\n\n AIP-1: Arbitrum Improvement Proposal Framework\n\n Archived Proposals\n\n snapshot,failed\n\n 107\n\n 38.4k\n\n Apr 2023\n\n Continued Funding for the Arbitrum Foundation\n\n Finalized AIPs\n\n 37\n\n 2.0k\n\n Jul 15\n\n [Non-Constitutional] Funds to Bolster Foundation’s Strategic Partnerships Budget\n\n Finalized AIPs\n\n 103\n\n 2.9k\n\n Oct 2024\n\n Proposal: Return 700M $ARB to the DAO Treasury\n\n Archived Proposals\n\n snapshot,failed\n\n 53\n\n 16.2k\n\n Apr 2023","tokens":946,"squid":"spider-07","role":"Council Spider","at":1791340436595,"hash":"fcd4c537f31bb88bade3baf666240b8dd2b3a0e6"}
{"url":"https://forum.arbitrum.foundation/t/continued-funding-for-the-arbitrum-foundation/30908","domain":"forum.arbitrum.foundation","title":"Continued Funding for the Arbitrum Foundation - Proposals / Finalized AIPs - Arbitrum","text":"The Arbitrum Foundation notified the Security Council on the need to perform a potential Emergency action. Following a review of the details and known risks, the Security Council decided to execute the upgrade and it was completed at 11:30 EST on 2nd October 2026.\nThis report provides an overview of the risks that required the Security Council Action:\n\nAdd a permissionless guard for the One-Step Proof of BoLD on Arbitrum One\n\nTemporarily pause activation of new Stylus contracts on Arbitrum One & Nova\n\nKey point: To date, known bugs for Stylus primarily impact chain liveness (e.g., denial of service attacks) and do not put any user funds at risk.\nWhy was this action taken\nLet’s take this opportunity to explain why action was taken on two separate issues concerning BoLD and Stylus.\nInstalling the guard for One-Step Proof of BoLD. Given the rise of AI-assisted attacks, we have implemented a precautionary approach that allows anyone to pause settlement of Arbitrum One on Ethereum if there are at least two conflicting answers that pass at the same level in which only one should be valid and pass. This is to halt a class of publicly verifiable and detectable attacks that exploit a bug in the one-step proof. If halted, Arbitrum One will continue to process as normal except that messages from Arbitrum One to Ethereum, such as withdrawals, that are not yet confirmed will have to wait. This provides time for the Security Council to deploy a fix for the bug and resume the rollup.\nPreventing activation of new Stylus contracts. AI-assisted tooling has led to an increasing number of sophisticated attacks on hand-crafted WASM programs that do not use the standard Stylus compiler toolchain. These programs are specifically designed to cause unexpected behaviors such as degrading the chain’s performance for all other users. To date, no attacks have been discovered that permits theft of user funds.\nNew ArbOS releases have patched several reported bugs and known attacks over the past few months, but out of an abundance of caution, we have decided to temporarily pause new activations of Stylus contracts. This was executed as an emergency action to prevent the deployment of new hand-crafted WASM programs that are not yet patched by the current version of ArbOS on the Arbitrum network.\nThe Arbitrum Foundation has informed the Security Council that they will work with the ArbitrumDAO to discuss next steps on the timeline and manner for enabling activation of new Stylus contracts. The Arbitrum community remains confident in the value of Stylus and want to preserve these use cases while taking preventative measures against Stylus-based attack vectors as AI-assisted attack tooling continues to evolve.\nImpact on builders and users\n\nNo new activations. New Stylus contracts cannot be activated during the pause including new versions of existing applications that require activation.\n\nExisting contracts are not paused. Already-active Stylus contracts continue to execute until expiration. This pause does not deactivate them.\n\nThe ArbOS 61 upgrade renewed all active contracts on Arbitrum One, so no currently active contract expires before August 20, 2027.\n\nRenewal via keepalive stays permissionless and is unaffected by the pause.\n\nReactivating an expired contract, or one that needs to be updated after a Stylus version change, is paused.\n\nUsing/calling any activated Stylus contract stays permissionless for all users and developers.\n\nNo impact on EVM. Solidity (EVM) contract deployment and execution are unaffected by this Security Council action.\n\nSecurity Council Actions\nThere are two actions bundled into a single payload:\n\nOne-Step Proof Guard. The L1UpgradeExecutor gives a new pause contract (PauseExecutor) the ability to pause and nothing else. The new pause contract grants the guard (OspSoundnessGuard) PAUSER_ROLE to use it. Anyone can show the guard two conflicting answers to the same step of an open challenge. If the one-step proof accepts both, the guard has the pause contract put Arbitrum One’s settlement to Ethereum on hold.\n\nStylus deactivation. The Security Council called ArbOwner.setWasmActivationGas(2^64 - 1) to raise the Stylus activation gas requirement on Arbitrum One and Nova. This makes activation prohibitively expensive and effectively disables new activations. This is a configuration change and does not require an ArbOS upgrade.\n\nThe Security Council signed the following transactions to update the configuration:\n\nEthereum: Ethereum Transaction Hash: 0x30732bb7d2... | Etherscan\nArbitrum One:\nArbitrum One Transaction Hash: 0x9eb3a4be3b... | Arbitrum One\nArbitrum Nova:\nArbitrum Nova transaction 0x79e0fed470dff7a22059b108e3f8f42eddd2b580a6771594060c4e7326c5f984 | Blockscout\n\nAn external audit was conducted for the OSP Guard contracts. No audit is required for the Stylus deactivation as it is only updating a single parameter in the ArbOS configuration.\n\n Continued Funding for the Arbitrum Foundation \n\n ProposalsFinalized AIPs\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n May 21\n\n 1 / 38\n\n May 21\n\n Jul 15\n\n post by Arbitrum on May 21\n\n Arbitrum\n\n Abstract\nThis proposal seeks funding of $16M in USD (RWAs), 1.7k ETH and 230mn ARB to support the Arbitrum Foundation’s continued operations for an additional year beyond its initial allocation under AIP 1.1.\nThe Foundation serves as a growth engine and cost center of the Arbitrum ecosystem on behalf of the DAO. It coordinates development of the technology stack, executes strategic partnerships in coordination with other Arbitrum Aligned Entities (“AAEs”), supports and funds ecosystem expansion and facilitates DAO initiatives. Importantly, it also covers all costs associated with Arbitrum One and Arbitrum Nova, with technical costs expected to represent 54% of all anticipated expenses for 2027.\nAll activities undertaken by the Foundation are focused on working with other AAEs to grow the ecosystem and identify new revenue sources, with the ultimate goal of increasing revenue flowing to the DAO. As all revenue accrues directly to the DAO treasury, the Foundation must periodically return to the DAO and request funding in order to continue our activities.\nThe medium to long term goal of the Arbitrum Foundation, alongside all other AAEs, is to continue expanding the DAO’s revenue across multiple sources including Arbitrum One and AEP fees, Timeboost, the ATMC endowment, and new business lines that are expected to emerge over the coming months and years. We believe a sustainable future can be achieved via the DAO governance model and will continue focusing our efforts on ensuring its success.\nMotivation & Rationale\nThe Foundation acts as a capital allocator, ecosystem facilitator, and the ArbitrumDAO’s legal wrapper and backstop for DAO proposals.\nWe identify emerging opportunities and work with other AAEs to bring high-impact initiatives into the Arbitrum ecosystem. As an intentionally structured cost center, the Foundation absorbs the cost of growth and development while enabling the DAO to capture the upside through increased usage, stronger network effects and sustainable revenue generation.\nAmong the AAEs, the Foundation plays a central role across four key areas:\nStrategic Grants and Partnerships. The Foundation supports both emerging crypto-native teams and established institutional partners.\nOur ecosystem team is focused on onboarding teams across various verticals, including institutional tokenization, DeFi, Consumer, Payments, AI, and emerging trends. This forms the application layer of Arbitrum and further attracts builders to build on Arbitrum. The Arbitrum ecosystem is one of the most dynamic in the blockchain industry and attracts the interest of developers, retail users and now institutions. In many cases, this is thanks to the relationships and partnerships we have structured to bring users, capital, and strategic collaboration across the ecosystem.\nThe Foundation has continuously improved its capital allocation over time, and supports ecosystem growth through programs including our grants program, Trailblazer, Audit Subsidy Program, Arbifuel and DRIP. We have reviewed over 3,200 applications with an acceptance rate below 20% for these programs. Key Arbitrum teams that the Foundation directly supported in their early stages are Pendle, Ostium, USDAI, Instadapp, Cow Swap and El Dorado. Key Web3 communities were won over competition, like ApeChain. Institutional partnerships secured through the Foundation include Robinhood, BlackRock, Franklin Templeton, WisdomTree, Circle, Securitize and Paxos.\nTechnical Advancement and Infrastructure Maintenance. The technical and ecosystem team work hand-in-hand to sponsor core protocol upgrades alongside onboarding new partnerships that enhance the developer experience.\nSponsoring core protocol upgrades is essential for the continued improvement of the Arbitrum technology stack in terms of security, features, developer and end-user experience. Major sponsored upgrades include new execution environments such as Stylus, new revenue streams such as Timeboost and the Arbitrum Expansion Program, reducing fees for all users with Dynamic Gas Pricing, and continuous ArbOS upgrades with general improvements and security enhancements. The majority of research, development, and technical implementation of this work came from our partnership with Offchain Labs. As we mention elsewhere, Offchain Labs will approach the DAO separately to continue funding protocol research work.\nSince the Arbitrum technology stack has an ecosystem licence (BSL) and is increasingly adopted as the chain of choice by other projects, we have sought to onboard new partners who can enhance the developer experience. Partnerships include OpenZeppelin to develop a Stylus SDK and audit early Stylus teams, onboarding Nethermind for client diversity, and several top-tier audit firms with the Audit Program for emerging builders alongside many others.\nAdditionally, the Foundation funds core ecosystem tools and services, such as block explorers, RAAS providers, and transaction simulation and analytics tools which have extensive distribution across developers and users. As a result, Arbitrum offers best-in-class infrastructure support to the ecosystem and the Foundation maintains a strong relationship with infrastructure companies. This directly benefits the Arbitrum ecosystem, for instance, with the $10M grant program launched and funded by Alchemy.\nMarketing, Community, and Education. The Arbitrum Foundation is focused on vertical marketing through developer engagement, in-person initiatives, and coordinated media distribution.\nOur developer relations and ecosystem teams focus on supporting builders through technical education, tutorials, hackathons, and ecosystem showcases. Complementing this, in-person initiatives such as OpenHouse and ArbiLink bring together founders, developers, and institutional partners, facilitating collaboration and onboarding to the ecosystem.\nThis combined approach of online engagement alongside real-world activations helps to equip teams with the knowledge to build on Arbitrum while connecting them to high-value partners. Together, these efforts reinforce Arbitrum’s position as a highly attractive ecosystem for builders.\nFinally, to ensure Arbitrum is well positioned within broader industry narratives, alongside promoting teams building on Arbitrum, we actively engage with the media across both crypto-native and traditional financial outlets. Some outlets include Unchained, Decrypt, CoinDesk, The Block, Bankless, and Messari, as well as traditional financial media such as Fortune, Bloomberg, Financial Times, and CNBC.\nTokenholder Relations, Governance and DAO Wrapper. The Arbitrum Foundation has begun to actively engage with new prospective tokenholders alongside facilitating governance for existing tokenholders.\nOn the capital markets side, the investment strategy team has broadened engagement with investment firms, research houses, and asset managers to introduce the Arbitrum ecosystem and the role of the ARB token. This includes building relationships with selective capital market participants exploring the ecosystem’s growth trajectory and supporting initiatives that extend Arbitrum’s reach into institutional and/or investment communities. Additionally, we have facilitated several institutional roundtables and prospective token holder roadshows across key markets such as the US, EMEA and Asia.\nGovernance, specifically DAO relations, will begin to converge with institutional relationship building as we work to bring more long term token holders into the governance process.\nOn the governance front, the governance team has played both a strategic and operational role since the DAO’s inception. They have facilitated six Security Council election cycles, as well as the implementation of many DAO-approved initiatives including liquidity programs (e.g. ATMC, STEP I and II), third-party grant providers (e.g. Plurality Labs, Questbook), DAO-mandated research initiatives (e.g. ARDC), and recovery of misused funds (e.g. Watchdog, other independent actions), among many others. More recently, they have supported the establishment and enablement of several Arbitrum Aligned Entities including OpCo, Entropy Advisors, and AGV.\nImportantly, the Arbitrum Foundation serves as the legal wrapper for the DAO and has committed $10M to establish the Captive Insurance Product, designed to act as a backstop to safeguard participation within the DAO.\nUse of Funds and the Reinvestment Flywheel\nThe Foundation operates at the intersection of the ecosystem’s core participants among AAEs, builders, institutions, and governance, where we coordinate efforts to drive adoption and growth.\nAll activities are ultimately focused on improving key metrics across Arbitrum One and Arbitrum Chains which directly translates into revenue for the ArbitrumDAO.\nThe impact of this model is best illustrated by the ecosystem’s growth to date.\nIn March 2023 (at the Foundation’s launch):\n\n1.28M daily transactions,\n\n$1.9B in stablecoins,\n\n$6.15M revenue for that month, with $3.52M paid to Ethereum L1 data costs,\n\nNo meaningful real-world asset (RWA) presence.\n\nBy February 2026:\n\n4.7M+ daily transactions (up 270% from March 2023)\n\n$8.6B stablecoin supply (up 320% from March 2023)\n\n~$800M in RWAs, top 6th network by value and ranks #1 globally by total assets issued,\n\n$23.49M in gross profit generated in 2025 across transaction fees, Timeboost, and the Arbitrum Expansion Program, all accruing to the DAO treasury.\n\nGoing further, Arbitrum has developed one of the deepest liquidity layers across L2s, with peak TVL of ~$21B and over 2.3B total transactions processed, with the second billion completed in just 13 months. Most importantly, network fees paid by users have drastically decreased while maintaining a significant revenue stream for the DAO.\nThis growth reflects a reinforcing economic flywheel. More teams building on Arbitrum drives more onchain activity; increased activity generates DAO revenue through fees, Timeboost, the Arbitrum Expansion program, and native yields available on Arbitrum chains; that revenue is reinvested into grants, programs, technology improvements, and ultimately attracts the next wave of teams to build on Arbitrum.\nThis flywheel is already established and accelerating. This proposal funds the work that continues to compound it with the Foundation’s efforts focused on ecosystem growth, increasing DAO revenue, and ensuring our own continued future funding.\nWe recommend viewing the following dashboards that reflect the on-chain transaction data, total stablecoin supply, and total RWAs on Arbitrum.\nProjected Foundation Expenses (2027)\n\nUSD\nARB\n\nOperating Expenses\n$27.6M\n\nEcosystem Growth Expenses & Investments\n\n244.9M\n\nTotal Projected 2027 Expenses\n$27.6M\n244.9M\n\nTable 1: Total expected operating and ecosystem growth related expenses in fiat and ARB for 2027\nTable 1 presents our current best estimate of total 2027 expenses. The annualized expense is below the annual costs outlined in the Foundation’s 2025 transparency report. This reflects a combination of cost efficiencies undertaken by the Foundation, our treasury management efforts, and the absence of funding for Offchain Labs.\nThe Foundation’s current payments to Offchain Labs for technical services will run through January 2027, but after that OCL will no longer be paid by the Foundation. They may approach the DAO separately for funding in the future.\nIn relation to our expected ecosystem growth expenses & investments, the Foundation works with other AAEs to allocate this funding. We view this as an important part of creating a sustainable flywheel for the DAO. As mentioned previously, key Arbitrum teams that the Foundation directly supported in their early stages are Pendle, Ostium, USDAI, Instadapp, Cow Swap and El Dorado. The 2027 budget includes funding for both new and existing ecosystem growth commitments.\n\n2027 (Forecast)\n\nVariable Marketing Expenses\n$2.38M\n\nGeneral & Administrative (G&A)\n$10.40M\n\nTechnical\n$14.81M\n\nTotal Operating Expenses\n$27.6M\n\nTable 2: Anticipated expenses forecast for 2027 by the Arbitrum Foundation\nTable 2 provides an overview of the Foundation’s projected expenses as it relates to General & Administrative, Variable Marketing, and Technical costs.\nIt is important to note that the Arbitrum Foundation largely operates as a cost center for the DAO. While the chain revenue occurs to the DAO, the Foundation pays the operational expenses to keep Arbitrum One and Arbitrum Nova running.\nIn regards to the General and Administrative category, it primarily relates to personnel, contractors, external service providers, legal and insurance costs, and other operating expenses.\nThe Technical category alone accounts for approximately 54% of all expenses for the Arbitrum Foundation for next year. Let’s explore the technical expenses in more detail.\n\n2027 (Forecast)\n\nSecurity\n$4.63M\n\nInfrastructure & Tooling\n$4.38M\n\nHosting & Support\n$5.80M\n\nTotal Technical Expenses\n$14.81M\n\nTable 3: Breakdown of Technical Expenses\nIn Table 3, we present a breakdown of the Technical category which includes Security, Hosting & Support, and Infrastructure & Tooling. This covers a range of costs including block explorers, bug bounties, auditing spend, cloud service providers, external technical contributors, third party software tools and many other items that are required to keep the Arbitrum network running with high uptime.\nWe have worked with Offchain Labs to optimize technical costs and are targeting an 8% reduction in 2026 vs. 2025 despite higher expected transaction volume and network traffic. This reduction is accounted for in the request for funding.\nThe Foundation has reduced expected variable marketing expenses in 2026 and going forward versus prior years. This reduction reflects a change in the Arbitrum Foundation’s approach to marketing. The Foundation is now focused on vertical marketing across capital markets and developer relations, with the objective of attracting high-quality founders to build on Arbitrum and to attract capital to participate in the ecosystem. This change in approach was necessary to contain cost while focusing our marketing efforts on the highest impact areas.\nProposed Funding Ask\n\nAsset Type\nQuantity\n\nRWA & Stablecoins\n$16M\n\nETH\n1,740\n\nARB\n230M\n\nTable 4: Requested funding for the Arbitrum Foundation\nTable 4 outlines the Foundation’s funding request of, where most funding will be used to cover technical costs of the network, G&A, and ecosystem growth for an additional year beyond its initial allocation under AIP 1.1.\nWe request funding in RWAs, ETH and ARB to better align the Foundation’s assets with its liabilities. Our operating expenses are largely USD-denominated while ecosystem growth expenses can be denominated in ARB. This approach would improve balance sheet flexibility and support future operational and strategic needs while reducing the need to sell tokens to fund operations.\nAdditionally, we are requesting 230mn ARB to increase our treasury of ARB. This will be used primarily for ecosystem growth initiatives, including onboarding new strategic partners, and other operating expenses.\nIt is worth highlighting that in Table 1, our total estimated operating expenses will be approximately $27.6M and 244.9mn ARB while the proposal is only requesting $16M in RWAs,1,740 ETH, and 230mn ARB. Our RWA ask is ~$11.6M lower than our estimated operating expenses and our ARB ask is ~14.9mn lower. We are comfortable with this short-fall as we can accommodate the difference from our current balance sheet and from the ETH requested.\nWe request the RWA / Stablecoins, ETH, and ARB be released to the Foundation upon passage of the proposal, with the ATMC and OAT determining the appropriate DAO bucket for each allocation.\nThe proposed funding timeline reflects a deliberate approach to treasury management to ensure continuity of core functions and sustained support for the ecosystem while minimizing the near-term impact on the DAO’s treasury. The Arbitrum Foundation expects to come back to the DAO in 2027 to discuss future funding.\nThe Foundation has published Biannual and Annual Transparency Reports since inception, without interruption. This proposal commits to maintaining that cadence.\nTimeline\nWe encourage all delegates to provide feedback on the forum and to attend the following governance call:\n\nTuesday, 26th May 2026, at 2pm UTC\n\nThroughout the governance process, feedback will be collected and integrated with the proposal.\nWe aim to have a temperature check vote on 28th May 2026, which will run for one week. If the temperature check passes, then the on-chain vote will be initiated on 8th June 2026. Please note that these dates are subject to change based on feedback from delegates.\n\n Entropy Advisors Monthly Update: June 2026\n\n Rewarding Active Delegates - June 2026 Results\n\n Griff Green - Delegate Communication Thread\n\n 5\n\n 5\n\n 2\n\n 2\n\n 2\n\n read \n\n 25\n min\n\n post by MconnectDAO on May 22\n\n post by Arbit1 on May 24\n\n post by crypfuto on May 24\n\n post by paulofonseca on May 25\n\n post by Griff on May 26\n\n post by Abel189 on May 28\n\n post by cp0x on May 28\n\n post by pedrob on May 29\n\n post by Arbitrum on May 29\n\n post by Arbit1 on May 31\n\n post by Zeptimus on Jun 1\n\n post by maxlomu on Jun 1\n\n post by JoJo on Jun 2\n\n post by cornellbc.eth on Jun 2\n\n post by Reverie on Jun 2\n\n post by TodayInDeFi on Jun 3\n\n post by Saurabh on Jun 3\n\n post by Arbitrum on Jun 3\n\n post by Entropy on Jun 3\n\n Load more posts below","tokens":5665,"squid":"spider-07","role":"Council Spider","at":1791340448149,"hash":"3170d0ab0ffe89b07c5707d85a20d08b31ac45be"}
{"url":"https://forum.arbitrum.foundation/c/proposals/7","domain":"forum.arbitrum.foundation","title":"Latest Proposals topics - Arbitrum","text":"The Arbitrum Foundation notified the Security Council on the need to perform a potential Emergency action. Following a review of the details and known risks, the Security Council decided to execute the upgrade and it was completed at 11:30 EST on 2nd October 2026.\nThis report provides an overview of the risks that required the Security Council Action:\n\nAdd a permissionless guard for the One-Step Proof of BoLD on Arbitrum One\n\nTemporarily pause activation of new Stylus contracts on Arbitrum One & Nova\n\nKey point: To date, known bugs for Stylus primarily impact chain liveness (e.g., denial of service attacks) and do not put any user funds at risk.\nWhy was this action taken\nLet’s take this opportunity to explain why action was taken on two separate issues concerning BoLD and Stylus.\nInstalling the guard for One-Step Proof of BoLD. Given the rise of AI-assisted attacks, we have implemented a precautionary approach that allows anyone to pause settlement of Arbitrum One on Ethereum if there are at least two conflicting answers that pass at the same level in which only one should be valid and pass. This is to halt a class of publicly verifiable and detectable attacks that exploit a bug in the one-step proof. If halted, Arbitrum One will continue to process as normal except that messages from Arbitrum One to Ethereum, such as withdrawals, that are not yet confirmed will have to wait. This provides time for the Security Council to deploy a fix for the bug and resume the rollup.\nPreventing activation of new Stylus contracts. AI-assisted tooling has led to an increasing number of sophisticated attacks on hand-crafted WASM programs that do not use the standard Stylus compiler toolchain. These programs are specifically designed to cause unexpected behaviors such as degrading the chain’s performance for all other users. To date, no attacks have been discovered that permits theft of user funds.\nNew ArbOS releases have patched several reported bugs and known attacks over the past few months, but out of an abundance of caution, we have decided to temporarily pause new activations of Stylus contracts. This was executed as an emergency action to prevent the deployment of new hand-crafted WASM programs that are not yet patched by the current version of ArbOS on the Arbitrum network.\nThe Arbitrum Foundation has informed the Security Council that they will work with the ArbitrumDAO to discuss next steps on the timeline and manner for enabling activation of new Stylus contracts. The Arbitrum community remains confident in the value of Stylus and want to preserve these use cases while taking preventative measures against Stylus-based attack vectors as AI-assisted attack tooling continues to evolve.\nImpact on builders and users\n\nNo new activations. New Stylus contracts cannot be activated during the pause including new versions of existing applications that require activation.\n\nExisting contracts are not paused. Already-active Stylus contracts continue to execute until expiration. This pause does not deactivate them.\n\nThe ArbOS 61 upgrade renewed all active contracts on Arbitrum One, so no currently active contract expires before August 20, 2027.\n\nRenewal via keepalive stays permissionless and is unaffected by the pause.\n\nReactivating an expired contract, or one that needs to be updated after a Stylus version change, is paused.\n\nUsing/calling any activated Stylus contract stays permissionless for all users and developers.\n\nNo impact on EVM. Solidity (EVM) contract deployment and execution are unaffected by this Security Council action.\n\nSecurity Council Actions\nThere are two actions bundled into a single payload:\n\nOne-Step Proof Guard. The L1UpgradeExecutor gives a new pause contract (PauseExecutor) the ability to pause and nothing else. The new pause contract grants the guard (OspSoundnessGuard) PAUSER_ROLE to use it. Anyone can show the guard two conflicting answers to the same step of an open challenge. If the one-step proof accepts both, the guard has the pause contract put Arbitrum One’s settlement to Ethereum on hold.\n\nStylus deactivation. The Security Council called ArbOwner.setWasmActivationGas(2^64 - 1) to raise the Stylus activation gas requirement on Arbitrum One and Nova. This makes activation prohibitively expensive and effectively disables new activations. This is a configuration change and does not require an ArbOS upgrade.\n\nThe Security Council signed the following transactions to update the configuration:\n\nEthereum: Ethereum Transaction Hash: 0x30732bb7d2... | Etherscan\nArbitrum One:\nArbitrum One Transaction Hash: 0x9eb3a4be3b... | Arbitrum One\nArbitrum Nova:\nArbitrum Nova transaction 0x79e0fed470dff7a22059b108e3f8f42eddd2b580a6771594060c4e7326c5f984 | Blockscout\n\nAn external audit was conducted for the OSP Guard contracts. No audit is required for the Stylus deactivation as it is only updating a single parameter in the ArbOS configuration.\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 The Incomplete Guide to Submitting a Proposal to Arbitrum DAO\n\n Proposals\n\n governance\n\n TL;DR\n\nAlthough the below contains parts of the official and ratified governance process, it is not in and of itself the officially recognized process for submitting a proposal to the Arbitrum DAO. Instead, it’s a compil…\n\n read more\n\n 3\n\n 1.4k\n\n Apr 2024\n\n How to submit a DAO Proposal\n\n Proposals\n\n How to submit a DAO Proposal\n1. Discourse\nhttps://forum.arbitrum.foundation/ is a forum for governance related discussions. \nCommunity members must register for an account before sharing or liking posts. \nThe Proposal is…\n\n read more\n\n 0\n\n 3.5k\n\n Apr 2023\n\n About the Proposals category\n\n Proposals\n\n Review community-submitted proposals that await voting by the DAO.\n\n 0\n\n 2.0k\n\n Mar 2023\n\n [CONSTITUTIONAL]: Establish an L1 Voting Recovery System \n\n Proposals\n\n proposal\n\n 1\n\n 80\n\n 5h\n\n Adopting USDG as a Core Strategic Initiative for the ArbitrumDAO\n\n Proposals\n\n 1\n\n 82\n\n 12h\n\n [Constitutional] AIP: Transition Arbitrum One ordering policy to Priority Gas Auctions (PGA)\n\n Finalized AIPs\n\n 30\n\n 2.2k\n\n 5d\n\n [Constitutional] AIP Fast Feed\n\n Finalized AIPs\n\n 22\n\n 1.0k\n\n 14d\n\n Banning projects identified in the high-severity Watchdog Program cases\n\n Finalized AIPs\n\n 11\n\n 396\n\n 15d\n\n Arbitrum Security Program\n\n Finalized AIPs\n\n 20\n\n 578\n\n 24d\n\n [Constitutional] AIP: Ratification of Security Council Election Process Improvements\n\n Finalized AIPs\n\n 27\n\n 645\n\n Sep 1\n\n Entropy Advisors: Exclusively Working With Arbitrum DAO\n\n Finalized AIPs\n\n proposal\n\n 86\n\n 3.9k\n\n Aug 25\n\n [RFC]: Fund Completion of CEX-> DEX Incentive Research\n\n Proposals\n\n proposal-discussions\n\n 29\n\n 826\n\n Aug 18\n\n Transfer 6,000 ETH and Idle Stablecoins from the Treasury to the Treasury Management Portfolio\n\n Finalized AIPs\n\n 27\n\n 941\n\n Aug 12\n\n Arbitrum Audit Program\n\n Finalized AIPs\n\n 128\n\n 4.6k\n\n Aug 3\n\n [Constitutional] AIP: ArbOS 61 Elara\n\n Finalized AIPs\n\n 30\n\n 1.4k\n\n Jul 30\n\n [Constitutional] AIP: Automate Timeboost Proceeds Split\n\n Proposals\n\n 15\n\n 510\n\n Jul 23\n\n Proposed Amendment to the Code of Conduct: AI tools and Responsible Participation Policy\n\n Finalized AIPs\n\n 4\n\n 123\n\n Jul 20\n\n Continued Funding for the Arbitrum Foundation\n\n Finalized AIPs\n\n 37\n\n 2.1k\n\n Jul 15\n\n AGV Wind-Down: Structured Transition & Return of Capital to the DAO Treasury\n\n Finalized AIPs\n\n 16\n\n 769\n\n Jul 7\n\n Extending DRIP’s Mandate\n\n Finalized AIPs\n\n 14\n\n 407\n\n Jun 26\n\n [Constitutional] AIP: Approve Release of Frozen ETH\n\n Finalized AIPs\n\n 53\n\n 7.3k\n\n Jun 15\n\n [RFC] Proposal to Adjust the Voting Power of the Arbitrum Community Pool & Ratifying the Agentic Governance Pivot\n\n Finalized AIPs\n\n proposal,delegation,proposal-discussions\n\n 65\n\n 1.7k\n\n Jun 14\n\n [Constitutional] AIP: Minimize Arbitrum Nova\n\n Finalized AIPs\n\n 21\n\n 815\n\n Jun 9\n\n Improvements to the Arbitrum Audit Program\n\n Finalized AIPs\n\n 13\n\n 514\n\n Apr 24\n\n [Constitutional] DVP Quorum for ArbitrumDAO: Implementation & Parameters\n\n Finalized AIPs\n\n 52\n\n 1.8k\n\n Apr 24\n\n Updating the Code of Conduct & DAO Procedures to Become Living Documents\n\n Finalized AIPs\n\n 12\n\n 395\n\n Apr 14\n\n Automate the Consolidation of Idle Funds into the Treasury Management Portfolio\n\n Finalized AIPs\n\n 21\n\n 727\n\n Mar 25\n\n Proposal- Discourse Widget To Improve DAO Governance Participation Rate\n\n Proposals\n\n 0\n\n 142\n\n Mar 3\n\n Change to New Governance Contracts that Allow Proposal Cancellation\n\n Finalized AIPs\n\n 51\n\n 1.7k\n\n Feb 28\n\n [Constitutional] AIP: Security Council Election Process Improvements [OLD]\n\n Finalized AIPs\n\n 68\n\n 2.2k\n\n Feb 17","tokens":2160,"squid":"spider-07","role":"Council Spider","at":1791340459814,"hash":"8556403d8a721d3bf42f4cee6f8b9fb2bf085958"}
{"url":"https://forum.arbitrum.foundation/t/about-the-proposals-category/19/1","domain":"forum.arbitrum.foundation","title":"About the Proposals category - Proposals - Arbitrum","text":"The Arbitrum Foundation notified the Security Council on the need to perform a potential Emergency action. Following a review of the details and known risks, the Security Council decided to execute the upgrade and it was completed at 11:30 EST on 2nd October 2026.\nThis report provides an overview of the risks that required the Security Council Action:\n\nAdd a permissionless guard for the One-Step Proof of BoLD on Arbitrum One\n\nTemporarily pause activation of new Stylus contracts on Arbitrum One & Nova\n\nKey point: To date, known bugs for Stylus primarily impact chain liveness (e.g., denial of service attacks) and do not put any user funds at risk.\nWhy was this action taken\nLet’s take this opportunity to explain why action was taken on two separate issues concerning BoLD and Stylus.\nInstalling the guard for One-Step Proof of BoLD. Given the rise of AI-assisted attacks, we have implemented a precautionary approach that allows anyone to pause settlement of Arbitrum One on Ethereum if there are at least two conflicting answers that pass at the same level in which only one should be valid and pass. This is to halt a class of publicly verifiable and detectable attacks that exploit a bug in the one-step proof. If halted, Arbitrum One will continue to process as normal except that messages from Arbitrum One to Ethereum, such as withdrawals, that are not yet confirmed will have to wait. This provides time for the Security Council to deploy a fix for the bug and resume the rollup.\nPreventing activation of new Stylus contracts. AI-assisted tooling has led to an increasing number of sophisticated attacks on hand-crafted WASM programs that do not use the standard Stylus compiler toolchain. These programs are specifically designed to cause unexpected behaviors such as degrading the chain’s performance for all other users. To date, no attacks have been discovered that permits theft of user funds.\nNew ArbOS releases have patched several reported bugs and known attacks over the past few months, but out of an abundance of caution, we have decided to temporarily pause new activations of Stylus contracts. This was executed as an emergency action to prevent the deployment of new hand-crafted WASM programs that are not yet patched by the current version of ArbOS on the Arbitrum network.\nThe Arbitrum Foundation has informed the Security Council that they will work with the ArbitrumDAO to discuss next steps on the timeline and manner for enabling activation of new Stylus contracts. The Arbitrum community remains confident in the value of Stylus and want to preserve these use cases while taking preventative measures against Stylus-based attack vectors as AI-assisted attack tooling continues to evolve.\nImpact on builders and users\n\nNo new activations. New Stylus contracts cannot be activated during the pause including new versions of existing applications that require activation.\n\nExisting contracts are not paused. Already-active Stylus contracts continue to execute until expiration. This pause does not deactivate them.\n\nThe ArbOS 61 upgrade renewed all active contracts on Arbitrum One, so no currently active contract expires before August 20, 2027.\n\nRenewal via keepalive stays permissionless and is unaffected by the pause.\n\nReactivating an expired contract, or one that needs to be updated after a Stylus version change, is paused.\n\nUsing/calling any activated Stylus contract stays permissionless for all users and developers.\n\nNo impact on EVM. Solidity (EVM) contract deployment and execution are unaffected by this Security Council action.\n\nSecurity Council Actions\nThere are two actions bundled into a single payload:\n\nOne-Step Proof Guard. The L1UpgradeExecutor gives a new pause contract (PauseExecutor) the ability to pause and nothing else. The new pause contract grants the guard (OspSoundnessGuard) PAUSER_ROLE to use it. Anyone can show the guard two conflicting answers to the same step of an open challenge. If the one-step proof accepts both, the guard has the pause contract put Arbitrum One’s settlement to Ethereum on hold.\n\nStylus deactivation. The Security Council called ArbOwner.setWasmActivationGas(2^64 - 1) to raise the Stylus activation gas requirement on Arbitrum One and Nova. This makes activation prohibitively expensive and effectively disables new activations. This is a configuration change and does not require an ArbOS upgrade.\n\nThe Security Council signed the following transactions to update the configuration:\n\nEthereum: Ethereum Transaction Hash: 0x30732bb7d2... | Etherscan\nArbitrum One:\nArbitrum One Transaction Hash: 0x9eb3a4be3b... | Arbitrum One\nArbitrum Nova:\nArbitrum Nova transaction 0x79e0fed470dff7a22059b108e3f8f42eddd2b580a6771594060c4e7326c5f984 | Blockscout\n\nAn external audit was conducted for the OSP Guard contracts. No audit is required for the Stylus deactivation as it is only updating a single parameter in the ArbOS configuration.\n\n About the Proposals category \n\n Proposals\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jan 2023\n\n 1 / 2\n\n Jan 2023\n\n Jan 2023\n\n post by system on Jan 23, 2023\n\n system\n\n Review community-submitted proposals that await voting by the DAO.\n\n Remove \"Trending Delegates\"\n\n 3 months later\n\n Closed on May 3, 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 Arbitrum Proposals App (GovHack Brussels Winner)\n\n Archived Proposals\n\n proposal,governance,delegation,proposal-discussions\n\n 35\n\n 1.6k\n\n May 2025\n\n Team #6: An (EIP-4824 powered) daoURI for the Arbitrum DAO\n\n GovHack Brussels\n\n 53\n\n 1.2k\n\n Oct 2024\n\n How to submit a DAO Proposal\n\n Proposals\n\n 0\n\n 3.5k\n\n Apr 2023\n\n The Incomplete Guide to Submitting a Proposal to Arbitrum DAO\n\n Proposals\n\n governance\n\n 3\n\n 1.4k\n\n Apr 2024\n\n Frisson Delegate Communication Thread\n\n Delegate Statements\n\n delegation,delegate-statements\n\n 76\n\n 1.1k\n\n Apr 2025","tokens":1477,"squid":"spider-07","role":"Council Spider","at":1791340483361,"hash":"ce07963ed539462d554e53527359b51e4bfb11ca"}
{"url":"https://forum.arbitrum.foundation/t/the-incomplete-guide-to-submitting-a-proposal-to-arbitrum-dao/22956","domain":"forum.arbitrum.foundation","title":"The Incomplete Guide to Submitting a Proposal to Arbitrum DAO - Proposals - Arbitrum","text":"The Arbitrum Foundation notified the Security Council on the need to perform a potential Emergency action. Following a review of the details and known risks, the Security Council decided to execute the upgrade and it was completed at 11:30 EST on 2nd October 2026.\nThis report provides an overview of the risks that required the Security Council Action:\n\nAdd a permissionless guard for the One-Step Proof of BoLD on Arbitrum One\n\nTemporarily pause activation of new Stylus contracts on Arbitrum One & Nova\n\nKey point: To date, known bugs for Stylus primarily impact chain liveness (e.g., denial of service attacks) and do not put any user funds at risk.\nWhy was this action taken\nLet’s take this opportunity to explain why action was taken on two separate issues concerning BoLD and Stylus.\nInstalling the guard for One-Step Proof of BoLD. Given the rise of AI-assisted attacks, we have implemented a precautionary approach that allows anyone to pause settlement of Arbitrum One on Ethereum if there are at least two conflicting answers that pass at the same level in which only one should be valid and pass. This is to halt a class of publicly verifiable and detectable attacks that exploit a bug in the one-step proof. If halted, Arbitrum One will continue to process as normal except that messages from Arbitrum One to Ethereum, such as withdrawals, that are not yet confirmed will have to wait. This provides time for the Security Council to deploy a fix for the bug and resume the rollup.\nPreventing activation of new Stylus contracts. AI-assisted tooling has led to an increasing number of sophisticated attacks on hand-crafted WASM programs that do not use the standard Stylus compiler toolchain. These programs are specifically designed to cause unexpected behaviors such as degrading the chain’s performance for all other users. To date, no attacks have been discovered that permits theft of user funds.\nNew ArbOS releases have patched several reported bugs and known attacks over the past few months, but out of an abundance of caution, we have decided to temporarily pause new activations of Stylus contracts. This was executed as an emergency action to prevent the deployment of new hand-crafted WASM programs that are not yet patched by the current version of ArbOS on the Arbitrum network.\nThe Arbitrum Foundation has informed the Security Council that they will work with the ArbitrumDAO to discuss next steps on the timeline and manner for enabling activation of new Stylus contracts. The Arbitrum community remains confident in the value of Stylus and want to preserve these use cases while taking preventative measures against Stylus-based attack vectors as AI-assisted attack tooling continues to evolve.\nImpact on builders and users\n\nNo new activations. New Stylus contracts cannot be activated during the pause including new versions of existing applications that require activation.\n\nExisting contracts are not paused. Already-active Stylus contracts continue to execute until expiration. This pause does not deactivate them.\n\nThe ArbOS 61 upgrade renewed all active contracts on Arbitrum One, so no currently active contract expires before August 20, 2027.\n\nRenewal via keepalive stays permissionless and is unaffected by the pause.\n\nReactivating an expired contract, or one that needs to be updated after a Stylus version change, is paused.\n\nUsing/calling any activated Stylus contract stays permissionless for all users and developers.\n\nNo impact on EVM. Solidity (EVM) contract deployment and execution are unaffected by this Security Council action.\n\nSecurity Council Actions\nThere are two actions bundled into a single payload:\n\nOne-Step Proof Guard. The L1UpgradeExecutor gives a new pause contract (PauseExecutor) the ability to pause and nothing else. The new pause contract grants the guard (OspSoundnessGuard) PAUSER_ROLE to use it. Anyone can show the guard two conflicting answers to the same step of an open challenge. If the one-step proof accepts both, the guard has the pause contract put Arbitrum One’s settlement to Ethereum on hold.\n\nStylus deactivation. The Security Council called ArbOwner.setWasmActivationGas(2^64 - 1) to raise the Stylus activation gas requirement on Arbitrum One and Nova. This makes activation prohibitively expensive and effectively disables new activations. This is a configuration change and does not require an ArbOS upgrade.\n\nThe Security Council signed the following transactions to update the configuration:\n\nEthereum: Ethereum Transaction Hash: 0x30732bb7d2... | Etherscan\nArbitrum One:\nArbitrum One Transaction Hash: 0x9eb3a4be3b... | Arbitrum One\nArbitrum Nova:\nArbitrum Nova transaction 0x79e0fed470dff7a22059b108e3f8f42eddd2b580a6771594060c4e7326c5f984 | Blockscout\n\nAn external audit was conducted for the OSP Guard contracts. No audit is required for the Stylus deactivation as it is only updating a single parameter in the ArbOS configuration.\n\n The Incomplete Guide to Submitting a Proposal to Arbitrum DAO \n\n Proposals\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 Apr 2024\n\n 1 / 6\n\n Apr 2024\n\n Apr 2024\n\n post by Sinkas on Apr 1, 2024\n\n Sinkas\n\n TL;DR\n\nAlthough the below contains parts of the official and ratified governance process, it is not in and of itself the officially recognized process for submitting a proposal to the Arbitrum DAO. Instead, it’s a compilation of knowledge and experience from existing participants that could be seen as ‘tips and tricks’ to submitting your proposal.\nYou don’t necessarily have to follow every step word-for-word. Each individual and/or group as well as their proposal is unique and might need fewer or more steps based on the overall context.\nMaking sure you’re an active part of Arbitrum DAO by participating in the forums, chats, and/or community calls before submitting a proposal can help you get off on the right foot with the community.\nBefore submitting a proposal, seek to collect feedback in private from delegates.\nA good place to collect feedback and get a few eyes on your proposal is the biweekly ‘Open Discussion of Proposal(s)’ calls hosted by Cliffton from Arbitrum Foundation. You can find the calls in the Arbitrum DAO calendar here.\nWhen publishing your proposal, make sure to adhere to the suggested format. Anticipate what questions delegates might ask and ensure you have adequate information for them not to.\nBe concise when explaining your proposal, but don’t overlook crucial information.\nIf you do not have the necessary voting power to create an offchain or onchain vote, you can ask a delegate who does to create it on your behalf.\nThe entire AIP voting process typically takes 37 days to complete for Constitutional AIPs or 27 days for Non-Constitutional AIPs\nIf your proposal fails, you can always iterate based on delegate feedback and resubmit.\nThis guide was published in April 2024 and is up-to-date until that time. The process might change as things evolve. We’ll come back and update the post as needed.\n\nConsiderations\nThe first thing you need to ask yourself before attempting to go through the process of submitting a proposal to the DAO is whether the proposal results in a win-win scenario. Simply put, what is the benefit that you will bring to the DAO through the execution of your proposal, and what do you stand to gain if your proposal passes?\nIf you have solid reasons to believe that the value created from your proposal justifies the organizational and/or monetary overhead created for the DAO, then you should proceed with the process as outlined below.\nOftentimes, it might be hard to assess your proposal in the context of the DAO. A good approach is to see whether there have been any similar proposals to the DAO in the past, or if there have been any similar proposals to other DAOs. Having a reference point can help put things into perspective, both for you and for the delegates when they are reviewing.\nFrameworks vs Direct-to-DAO\nOnce you’ve assessed your proposal, it’s time to see if it fits into any of the frameworks that already exist. As is the case with most DAOs, Arbitrum has frameworks in place to facilitate governance proposals. The 2 main categories of proposals are constitutional and non-constitutional Arbitrum Improvement Proposals, or AIPs.\n\nConstitutional AIPs are those that modify the text or procedures of the Constitution or AIP-1, install or modify the software on any chain, or take any action that requires “chain owner” permission on any chain.\nNon-constitutional AIPs are all other AIPs, such as those that request funds/grants or provide general guidelines or information to the community.\n\nIf you’re reading this guide before proposing, chances are your proposal falls into the second category - and that’s where we’ll focus in this guide.\nTwo easy questions to help you narrow down even further on how you’ll approach the DAO with your proposal are:\n\nAm I requesting a grant for something I’m building on Arbitrum?\nIs this something that would require a framework, or is it a one-off thing?\n\nAs a follow-up: if it does require a framework, does one already exist?\n\nRequesting Grants\nIf you answered yes to the first question and you’re seeking a grant for something you’re building, then the choice you have to make is who you’ll request the grant from. There are several grant programs through which you can request funding without having to go through the governance process and a DAO-wide vote. You can find more information on different grant programs here.\nDifferent kinds of proposal\nIf you’re trying to make a different kind of proposal, or looking to fund a governance initiative, then you first need to assess whether what you’re requesting would open the floodgates for other individuals, teams, or projects to also request. For example, if you’re a service provider and want to offer your services to the DAO, or if you’re a protocol looking for liquidity incentives, then you need to understand that you probably aren’t the only one out there with that idea.\nWhen delegates evaluate these kinds of proposals, a factor they take into consideration is whether there needs to be a more holistic approach or a framework in place. If your proposal has a wide scope that could potentially be applied to others, then you should first seek to see whether a framework like that already exists.\nIf you’re a service provider, you should contact the Arbitrum DAO Procurement Committee (ADPC) and get whitelisted, and if you’re looking for liquidity incentives, you should be on the lookout for initiatives like Short-Term Incentives Proposal (STIP), or Long-Term Incentives Pilot Program (LTIPP).\nIf a framework doesn’t exist for what you’re seeking to propose, then you should either discuss with delegates and see whether one is being worked on or, if you’re feeling brave, start working on one yourself.\nPre-RFC (Request for Comment)\nBefore going to the forums and publishing your proposal as a ‘Request for Comment (RFC)’, you should first make sure that you’ve somehow established yourself in the Arbitrum DAO community. Ways to do that include:\n\nHaving been active in the governance forums\nHaving attended open governance calls\nHaving talked with delegates online or in person\n\nIf you haven’t done any of the above, you might need to either have someone who’s already in the DAO introduce you to the right people or have a strong and credible out-of-the-DAO presence and reputation.\nAlthough not explicitly required, having established yourself in the community will make it easier to attract attention to your proposal, and get the ball rolling in terms of discussion and feedback.\nIdeally, you want to share your proposal with a few delegates before you even publish. Given their high context and experience in the DAO, they’ll probably have feedback to offer which will make your proposal better before you publish it.\nWhile getting in direct touch with delegates might seem daunting at first, if you get a hold of one and ask them to connect you with others, the thread of contacts will start untangling pretty quickly.\nRequest For Comment (RFC)\nFirst and foremost, you need to format your proposal in a way that is familiar to the DAO and easy to navigate. There’s a proposal template in the DAO’s governance docs here. Drafting an easy-to-understand yet solid proposal is more art than science. Below we’ve compiled some advice that will save you the time and effort of going back and forth with delegates and other community members that review your proposal.\n\nInclude a TL;DR at the top.\n\nThe point of having a TL;DR of the proposal at the very top, similar to the one found at the start of this post, is so people can quickly get an overview and a refresh of the essence of the proposal without having to read through endless text. It doesn’t need to cover all the minor details, but it should include all the important ones.\n\nAvoid using “sales” language.\n\nWe’re excited that you want to build “the first in the world” or the “best-in-class” whatever, but the DAO is not a customer. The feedback you will receive will be based on the merit of the proposal rather than that of the pitch. If anything, you’re tiring both yourself and the delegates by adding unnecessary fluff. Be concise and to the point and it will be much better received.\n\nGet specific and don’t leave things hanging\n\nWhile you want to avoid unnecessary fluff language, you do not want to be brief with the things that matter. Important information that pertains to your proposal should be extensively covered.\nA non-exhaustive list of things that have been typically discussed in the past are:\n\nThe total amount requested. You can denominate in either USD or ARB, but the funds you’ll receive will most likely be in ARB so keep that in mind.\nThe timeline of your proposal\nA breakdown of how the money is going to be spent\nHow will the funds be managed - will it be a multisig? If yes, who are going to be the signers?\nWill it be converted into stables or used as ARB?\nIs there going to be a milestone-based funding? If yes, what will the milestones be and how much money is it going to be unlocked at each?\nIf there have to be some sort of elections relevant to your proposal, how will they be carried out? Who will manage the process?\nIf there are smart contracts associated with your proposal, who is going to create them and audit them?\nIf your proposal is meant to be a pilot or trial, what happens when it concludes?\n\nContact info\n\nFeedback on your proposal will typically be given publicly under your forum post. However, you might want to give delegates a way to reach you in case they want to discuss your proposal in more detail. Telegram is most delegates’ app of choice, but any line of communication is welcome.\nOpen Discussion of Proposal(s)\nCliffton from the Arbitrum Foundation is hosting a biweekly call where proposals that are either going through the governance process, or that were recently posted on the forums are discussed. That’s a great place for you to present your proposal and discuss it with delegates and other governance participants.\nYou can see when those calls are happening in the Arbitrum DAO calendar.\nTemperature Check on Snapshot\nOnce you’ve submitted an RFC to the forum, it’s generally a good practice to allow for some time (typically a week) before moving for a temperature check on Snapshot, unless the proposal is time-sensitive. If you’ve collected a lot of feedback under your forum post before the week is up, then you could move forward earlier so as not to waste time. If you haven’t collected enough feedback (or if you haven’t collected any feedback), worry not! Going to a temperature check on Snapshot is a sure way of getting delegates’ attention.\nCreating a Snapshot vote\nTo submit a temperature check using Snapshot you must have an Ethereum wallet address that represents at least 0.01% of votable tokens (so 1,000,000 ARB). The Snapshot vote should run for 7 days and the outcome is decided by a simple majority with no required participation threshold. If you do not have that, you need to find a delegate who can post the proposal on your behalf.\nIf you’ve followed the steps above, you should already have a line of communication with a few eligible delegates by now. Don’t hesitate to reach out to them.\nUpdating your forum post\nAfter creating your Snapshot vote, head back to your forum post and update it to include the link to the Snapshot. You can also add the link as a reply to “bump” your post to the top of the feed.\nDiscussing your proposal\nThere’s a bi-weekly call hosted by the Arbitrum Foundation where proposals are being discussed. You can find the calls on the Arbitrum Governance Calendar and attend one of those to discuss your proposal.\nDisclaimer\nDoing a temperature check on Snapshot is an optional, but strongly recommended step in the governance process. If an AIP fails this temperature check, the original AIP author is encouraged to refrain from proceeding with an on-chain vote, and voters are encouraged to reject it if the author proceeds anyway. If an AIP proposer decides to skip temp-check, voters consider it as a factor when casting their vote.\nFormal Vote Onchain\nAfter the temperature check, and given that it was successful, the next step is to proceed with the onchain vote. As with Snapshot, an onchain vote can only be initiated by $ARB token holders who hold (or represent) at least 0.01% of the votable supply. The onchain vote would run for 14 days and to be approved, more than 50% of the votable tokens that voted on the proposal must have voted in favor of the proposal; constitutional proposals require 50% of delegated tokens to vote ‘For’ and/or ‘Abstain’ (within the range of 150m to 450m $ARB); and non-constitutional proposals require 40% of delegated tokens tokens (within the range of 100m to 300m $ARB) to vote ‘For’ and/or ‘Abstain’. “Delegated tokens” represent the total amount of $ARB participating in governance and available for voting.\nPreparing for an on-chain vote\nThe on-chain vote is executed permissionlessly after the vote concludes. For example, if you’re requesting funds from the DAO, successfully passing an on-chain vote doesn’t mean an entity will transfer the funds to you after the fact. You need to have the wallet that will receive the funds set up so the address can be used in the executable code associated with the proposal. The address and the requested amount will have to be a part of the on-chain proposal. If they’re not, no funds will be transferred, regardless of whether the proposal passes or not.\n\n If it’s a multi-sig wallet (e.g., Safe), make sure it’s deployed on Arbitrum. While EOA wallets like Metamask typically share the same address across different networks, multi-sig wallets do not work in the same fashion.\n\nPost-vote implementation\nKeep in mind that if your proposal is successful, it won’t be executed for another 14 days after the on-chain vote has concluded. This waiting period is because of the L2 waiting period, the L2-to-L1 message, and the L1 waiting period. You can learn more about the lifecycle of a proposal and the different waiting periods here.\nResubmitting a proposal\nIf your proposal fails to pass the temp check or the on-chain vote, you can always revise it and resubmit it. To do so, you need to reflect on the feedback received from delegates, especially the ones who voted against it, make amendments to your proposal, and resubmit it.\nIt is advised to create a new forum post for the revised proposal which will contain a link to the previous AIP, the reason why the previous AIP didn’t pass, and the changes you made to the AIP to\naddress the concerns raised by delegates and any additional information that differentiates the new proposal from the old one.\nGovernance process for resubmissions\nIf your proposal passed the temp-check and failed during the on-chain vote and you only made minor changes based on delegate feedback, you could skip the temp-check phase and go for an on-chain vote directly when resubmitting.\nIf your proposal didn’t pass the temp check, then you should go through the entire process as outlined above as if the proposal is a new one.\n\n Should the DAO Create COI & Self Voting Policies?\n\n GovHack Brussels Submission instructions\n\n L2BEAT Delegate Communication Thread\n\n Proposal - Getting Funding Idea\n\n read \n\n 6\n min\n\n post by Euphoria on Apr 1, 2024\n\n 9 days later\n\n post by lino on Apr 11, 2024\n\n post by ocandocrypto on Apr 17, 2024\n\n 2 years later\n\n Pinned on Nov 28, 2025\n\n Closed on Nov 28, 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 How to submit a DAO Proposal\n\n Proposals\n\n 0\n\n 3.5k\n\n Apr 2023\n\n Writing Your First Proposal to the ArbitrumDAO\n\n Guides & Documentation\n\n 0\n\n 1.7k\n\n Dec 2024\n\n Team 2: Accelerating Arbitrum Governance\n\n GovHack Denver\n\n 0\n\n 658\n\n Feb 2024\n\n Improving Predictability in Arbitrum DAO’s Operations\n\n Finalized AIPs\n\n proposal\n\n 59\n\n 1.9k\n\n Aug 2024\n\n Frisson Delegate Communication Thread\n\n Delegate Statements\n\n delegation,delegate-statements\n\n 76\n\n 1.1k\n\n Apr 2025","tokens":5290,"squid":"spider-07","role":"Council Spider","at":1791340494949,"hash":"9b91805e679668b5ddf40bd2ae2de61a83177324"}
{"url":"https://jup.ag/lend/borrow/multiply","domain":"jup.ag","title":"Multiply Crypto Exposure on Solana | Jupiter Lend","text":"Our new sUSDai loop is now live. Earn up to 27.15% at max leverage View loopAmplify Exposure to your AssetsCreate a leveraged or looped position.Top LoopsJLP / USDCMultiplyMax Leverage APY+28.49%JLP / JupUSDMultiplyMax Leverage APY+27.87%sUSDai / USDCMultiplyMax Leverage APY+27.15%JUICED / USDTMultiplyMax Leverage APY+8.42%JUICED / USDCMultiplyMax Leverage APY+8.17%Loop SelectLoopsdfdvSOLDebtSOLMax Multiplier12.3xMarket Size$106MNet APY0%Open dfdvSOL / SOL vaultJupSOLDebtSOLMax Multiplier16.3xMarket Size$72.9MNet APY+5.72%Open JupSOL / SOL vaultINFDebtSOLMax Multiplier16.3xMarket Size$65.6MNet APY+3.6%Open INF / SOL vaultsUSDaiDebtUSDCMax Multiplier8.2xMarket Size$49.2MNet APY+27.15%Open sUSDai / USDC vaultcbBTCDebtUSDCMax Multiplier6.4xMarket Size$14.1MNet APY0%Open cbBTC / USDC vaultJitoSOLDebtSOLMax Multiplier16.3xMarket Size$6.31MNet APY0%Open JitoSOL / SOL vaultjapanSOLDebtSOLMax Multiplier12.3xMarket Size$6.09MNet APY+7.98%Open japanSOL / SOL vaultmSOLDebtSOLMax Multiplier8.9xMarket Size$468KNet APY+1.75%Open mSOL / SOL vaultLBTCDebtcbBTCMax Multiplier8.2xMarket Size$360KNet APY+4.03%Open LBTC / cbBTC vaultfwdSOLDebtSOLMax Multiplier16.3xMarket Size$8.54KNet APY+0.83%Open fwdSOL / SOL vaultFAQsMultiply is an automated leverage feature on Jupiter Lend that lets you increase your exposure to an asset by borrowing against your collateral and reinvesting it in a single, atomic transaction.Multiply has no extra fees, it uses the same fee structure as Borrow.Each Borrow or Multiply position is represented by a Position NFT, created at the moment the position is opened and sent to your wallet.This NFT stores all the position data, including collateral, debt, and risk parameters, and represents ownership of the position. This one is transferable: moving it to another wallet transfers the entire position.Do not burn this NFT, as it is required to manage and withdraw the funds associated with the position.Each Multiply position has a defined liquidation threshold, expressed as a maximum LTV that must not be exceeded.If price movements between the collateral and the borrowed asset, or an increase in your debt value, cause your position to exceed this threshold, the Health Factor will drop below 1.0 and part of your collateral may be automatically sold to repay the loan.How to avoid liquidation?Avoid maxing out leverage and keep a safety buffer.Reduce leverage (Unwind) if your position becomes risky.Monitor your position regularly from the Lend dashboard.Multiply uses leverage, which amplifies both gains and losses. As a result, positions can reach liquidation faster during adverse price movements.Your position is safe as long as the Health Factor stays above 1.0. If it drops below this level, part of your collateral is automatically sold to restore balance.Liquidation penalties apply only to the liquidated portion.Higher leverage can increase returns, but it also increases liquidation risk.Check JupLend Guides","tokens":740,"squid":"spider-02","role":"Liquidity Spider","at":1791340506403,"hash":"6e29f52b4a3891500107ac76d3d88c27debc900e"}
{"url":"https://forum.arbitrum.foundation/t/the-incomplete-guide-to-submitting-a-proposal-to-arbitrum-dao/22956/6","domain":"forum.arbitrum.foundation","title":"The Incomplete Guide to Submitting a Proposal to Arbitrum DAO - Proposals - Arbitrum","text":"The Arbitrum Foundation notified the Security Council on the need to perform a potential Emergency action. Following a review of the details and known risks, the Security Council decided to execute the upgrade and it was completed at 11:30 EST on 2nd October 2026.\nThis report provides an overview of the risks that required the Security Council Action:\n\nAdd a permissionless guard for the One-Step Proof of BoLD on Arbitrum One\n\nTemporarily pause activation of new Stylus contracts on Arbitrum One & Nova\n\nKey point: To date, known bugs for Stylus primarily impact chain liveness (e.g., denial of service attacks) and do not put any user funds at risk.\nWhy was this action taken\nLet’s take this opportunity to explain why action was taken on two separate issues concerning BoLD and Stylus.\nInstalling the guard for One-Step Proof of BoLD. Given the rise of AI-assisted attacks, we have implemented a precautionary approach that allows anyone to pause settlement of Arbitrum One on Ethereum if there are at least two conflicting answers that pass at the same level in which only one should be valid and pass. This is to halt a class of publicly verifiable and detectable attacks that exploit a bug in the one-step proof. If halted, Arbitrum One will continue to process as normal except that messages from Arbitrum One to Ethereum, such as withdrawals, that are not yet confirmed will have to wait. This provides time for the Security Council to deploy a fix for the bug and resume the rollup.\nPreventing activation of new Stylus contracts. AI-assisted tooling has led to an increasing number of sophisticated attacks on hand-crafted WASM programs that do not use the standard Stylus compiler toolchain. These programs are specifically designed to cause unexpected behaviors such as degrading the chain’s performance for all other users. To date, no attacks have been discovered that permits theft of user funds.\nNew ArbOS releases have patched several reported bugs and known attacks over the past few months, but out of an abundance of caution, we have decided to temporarily pause new activations of Stylus contracts. This was executed as an emergency action to prevent the deployment of new hand-crafted WASM programs that are not yet patched by the current version of ArbOS on the Arbitrum network.\nThe Arbitrum Foundation has informed the Security Council that they will work with the ArbitrumDAO to discuss next steps on the timeline and manner for enabling activation of new Stylus contracts. The Arbitrum community remains confident in the value of Stylus and want to preserve these use cases while taking preventative measures against Stylus-based attack vectors as AI-assisted attack tooling continues to evolve.\nImpact on builders and users\n\nNo new activations. New Stylus contracts cannot be activated during the pause including new versions of existing applications that require activation.\n\nExisting contracts are not paused. Already-active Stylus contracts continue to execute until expiration. This pause does not deactivate them.\n\nThe ArbOS 61 upgrade renewed all active contracts on Arbitrum One, so no currently active contract expires before August 20, 2027.\n\nRenewal via keepalive stays permissionless and is unaffected by the pause.\n\nReactivating an expired contract, or one that needs to be updated after a Stylus version change, is paused.\n\nUsing/calling any activated Stylus contract stays permissionless for all users and developers.\n\nNo impact on EVM. Solidity (EVM) contract deployment and execution are unaffected by this Security Council action.\n\nSecurity Council Actions\nThere are two actions bundled into a single payload:\n\nOne-Step Proof Guard. The L1UpgradeExecutor gives a new pause contract (PauseExecutor) the ability to pause and nothing else. The new pause contract grants the guard (OspSoundnessGuard) PAUSER_ROLE to use it. Anyone can show the guard two conflicting answers to the same step of an open challenge. If the one-step proof accepts both, the guard has the pause contract put Arbitrum One’s settlement to Ethereum on hold.\n\nStylus deactivation. The Security Council called ArbOwner.setWasmActivationGas(2^64 - 1) to raise the Stylus activation gas requirement on Arbitrum One and Nova. This makes activation prohibitively expensive and effectively disables new activations. This is a configuration change and does not require an ArbOS upgrade.\n\nThe Security Council signed the following transactions to update the configuration:\n\nEthereum: Ethereum Transaction Hash: 0x30732bb7d2... | Etherscan\nArbitrum One:\nArbitrum One Transaction Hash: 0x9eb3a4be3b... | Arbitrum One\nArbitrum Nova:\nArbitrum Nova transaction 0x79e0fed470dff7a22059b108e3f8f42eddd2b580a6771594060c4e7326c5f984 | Blockscout\n\nAn external audit was conducted for the OSP Guard contracts. No audit is required for the Stylus deactivation as it is only updating a single parameter in the ArbOS configuration.\n\n Proposals\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 Apr 2024\n\n 6 / 6\n\n Nov 2025\n\n Apr 2024\n\n post by Sinkas on Apr 1, 2024\n\n post by Euphoria on Apr 1, 2024\n\n Euphoria\n\n Thank you so much @Sinkas for this insightful guide!\nIt’s a valuable resource for new users navigating the proposal submission process in the Arbitrum DAO community.\n\n Arbitrum DAO News: AVI, ARDC and ADPC Updates and , May 22nd\n\n Arbitrum DAO News, Stylus is now available on Arbitrum Sepolia and Road to ETHCC, June 21st\n\n Arbitrum DAO News: Security Council Member Election, STIP Bridge and Arbitrum Fellowships, April 18th\n\n Arbitrum DAO News, Learning Arbitrum Stylus, Tracking ongoing initiatives, May 30th\n\n Arbitrum DAO News: Incentive Delegate Updates and Concerns Regarding Possible Misconduct, May 17th\n\n 9 days later\n\n post by lino on Apr 11, 2024\n\n lino\n\n Thank you indeed @Sinkas, really helpful!\n\n post by ocandocrypto on Apr 17, 2024\n\n ocandocrypto\n\n This is very valuable, especially for those of us who are still on our journey to contributing more value to the DAO and are still learning about the format and mode of operation. Thank you @Sinkas.\n\n 2 years later\n\n Pinned on Nov 28, 2025\n\n Closed on Nov 28, 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 How to submit a DAO Proposal\n\n Proposals\n\n 0\n\n 3.5k\n\n Apr 2023\n\n Writing Your First Proposal to the ArbitrumDAO\n\n Guides & Documentation\n\n 0\n\n 1.7k\n\n Dec 2024\n\n Team 2: Accelerating Arbitrum Governance\n\n GovHack Denver\n\n 0\n\n 658\n\n Feb 2024\n\n Improving Predictability in Arbitrum DAO’s Operations\n\n Finalized AIPs\n\n proposal\n\n 59\n\n 1.9k\n\n Aug 2024\n\n Frisson Delegate Communication Thread\n\n Delegate Statements\n\n delegation,delegate-statements\n\n 76\n\n 1.1k\n\n Apr 2025","tokens":1689,"squid":"spider-07","role":"Council Spider","at":1791340506513,"hash":"efadac19d1cfb8cdc63b39562b68628dcbe6d381"}
{"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":"spider-05","role":"Spec Spider","at":1791340568807,"hash":"530ecb6dda96925eac5f93275319d5faa53eff31"}
{"url":"https://akash.network/ecosystem/deployed-on-akash/showcase","domain":"akash.network","title":"Showcase | Deployed On Akash","text":"Showcase AkashML High-performance, low latency AI inference service built on Akash NetworkHigh-performance, low latency AI inference service built on Akash NetworkHigh-performance, low latency AI inference service built on Akash NetworkHigh-performance, low latency AI inference service built on Akash Network View project R Λ Z Ξ R Razer's personalized AI companion experience, was brought to life at global scale using Razer's AIKit and Akash.Razer's personalized AI companion experience, was brought to life at global scale using Razer's AIKit and Akash.Razer's personalized AI companion experience, was brought to life at global scale using Razer's AIKit and Akash. View project NVIDIA Brev.dev (Acq. by NVIDIA), known for its seamless setup of Jupyter notebooks for AI development, has integrated with Akash Network, enabling scalable, permissionless access to NVIDIA GPUs.Brev.dev (Acq. by NVIDIA), known for its seamless setup of Jupyter notebooks for AI development, has integrated with Akash Network, enabling scalable, permissionless access to NVIDIA GPUs.Brev.dev (Acq. by NVIDIA), known for its seamless setup of Jupyter notebooks for AI development, has integrated with Akash Network, enabling scalable, permissionless access to NVIDIA GPUs. View project Venice.ai Venice is the easy app for private, uncensored AI conversations and image generation. Try for free with no log-in needed.Venice is the easy app for private, uncensored AI conversations and image generation. Try for free with no log-in needed.Venice is the easy app for private, uncensored AI conversations and image generation. Try for free with no log-in needed. View project Prime Intellect Prime Intellect leverages Akash Supercloud's high-performance GPUs, like NVIDIA H100 and A100, to democratize AI development.Prime Intellect leverages Akash Supercloud's high-performance GPUs, like NVIDIA H100 and A100, to democratize AI development.Prime Intellect leverages Akash Supercloud's high-performance GPUs, like NVIDIA H100 and A100, to democratize AI development. View project University of Texas at Austin The University of Texas at Austin is a bold, ambitious leader, providing a first-class education and the tools of discovery to more than 51,000 students.The University of Texas at Austin is a bold, ambitious leader, providing a first-class education and the tools of discovery to more than 51,000 students.The University of Texas at Austin is a bold, ambitious leader, providing a first-class education and the tools of discovery to more than 51,000 students. View project Nous Research Leveraging the power of Akash's decentralized cloud, Nous Research successfully trained 'Nous Hermes 2,' an advanced AI model built on over 1,000,000 entries of GPT-4 data.Leveraging the power of Akash's decentralized cloud, Nous Research successfully trained 'Nous Hermes 2,' an advanced AI model built on over 1,000,000 entries of GPT-4 data.Leveraging the power of Akash's decentralized cloud, Nous Research successfully trained 'Nous Hermes 2,' an advanced AI model built on over 1,000,000 entries of GPT-4 data. View project Eliza Eliza is a powerful multi-agent simulation framework designed to create, deploy and manage autonomous AI agents.Eliza is a powerful multi-agent simulation framework designed to create, deploy and manage autonomous AI agents.Eliza is a powerful multi-agent simulation framework designed to create, deploy and manage autonomous AI agents. View project Morpheus Morpheus is designed to incentivize the first open-source p2p network of personal general-purpose AI, powered by the MOR token.Morpheus is designed to incentivize the first open-source p2p network of personal general-purpose AI, powered by the MOR token.Morpheus is designed to incentivize the first open-source p2p network of personal general-purpose AI, powered by the MOR token. View project Flock.io Flock.io is advancing open, decentralized AI by integrating with Akash's Supercloud, making it simple for developers to access high-performance compute for training AI models.Flock.io is advancing open, decentralized AI by integrating with Akash's Supercloud, making it simple for developers to access high-performance compute for training AI models.Flock.io is advancing open, decentralized AI by integrating with Akash's Supercloud, making it simple for developers to access high-performance compute for training AI models. View project Akash Chat Benchmark conversational LLMs side‑by‑side. Seamlessly switch between leading open‑source chat models, evaluate responses, and choose the best fit for your application.Benchmark conversational LLMs side‑by‑side. Seamlessly switch between leading open‑source chat models, evaluate responses, and choose the best fit for your application.Benchmark conversational LLMs side‑by‑side. Seamlessly switch between leading open‑source chat models, evaluate responses, and choose the best fit for your application. View project Auki Virtual real estate for shared augmented reality, allowing you to manifest your knowledge and imagination in the minds of others. Our unique solutions are powered by The Posemesh, a decentralized and privacy-preserving protocol for collaborative spatial computing.Virtual real estate for shared augmented reality, allowing you to manifest your knowledge and imagination in the minds of others. Our unique solutions are powered by The Posemesh, a decentralized and privacy-preserving protocol for collaborative spatial computing.Virtual real estate for shared augmented reality, allowing you to manifest your knowledge and imagination in the minds of others. Our unique solutions are powered by The Posemesh, a decentralized and privacy-preserving protocol for collaborative spatial computing. View project Bagel Bagel is an AI & Cryptography Research Lab. Making Open Source AI Monetizable leveraging novel cryptography.Bagel is an AI & Cryptography Research Lab. Making Open Source AI Monetizable leveraging novel cryptography.Bagel is an AI & Cryptography Research Lab. Making Open Source AI Monetizable leveraging novel cryptography. View project Levangie Laboratories Levangie Laboratories is shaping the next generation of adaptive AI systems. We are building agents that learn, evolve, and collaborate in real time, transforming industries and redefining what's possible with AI.Levangie Laboratories is shaping the next generation of adaptive AI systems. We are building agents that learn, evolve, and collaborate in real time, transforming industries and redefining what's possible with AI.Levangie Laboratories is shaping the next generation of adaptive AI systems. We are building agents that learn, evolve, and collaborate in real time, transforming industries and redefining what's possible with AI. View project Bless The world's first shared computer.The world's first shared computer.The world's first shared computer.The world's first shared computer. View project Akash Report Your one-stop hub for Akash Network and Web3 news, guides, videos and token swaps. Explore the unstoppable cloud and stay ahead of the decentralized curve.Your one-stop hub for Akash Network and Web3 news, guides, videos and token swaps. Explore the unstoppable cloud and stay ahead of the decentralized curve.Your one-stop hub for Akash Network and Web3 news, guides, videos and token swaps. Explore the unstoppable cloud and stay ahead of the decentralized curve. Arcturus A space colony in a distant star system!A space colony in a distant star system!A space colony in a distant star system!A space colony in a distant star system! View project Bitmind The BitMind Platform makes utilizing compute easy. It aggregates compute from a variety of different providers, including Akash, and helps deploy and maintain instances for decentralized AI, providing a seamless and scalable experience for its users.The BitMind Platform makes utilizing compute easy. It aggregates compute from a variety of different providers, including Akash, and helps deploy and maintain instances for decentralized AI, providing a seamless and scalable experience for its users.The BitMind Platform makes utilizing compute easy. It aggregates compute from a variety of different providers, including Akash, and helps deploy and maintain instances for decentralized AI, providing a seamless and scalable experience for its users. View project Envision Labs Envision Labs has selected Akash as its primary compute provider, leveraging its automated scaling capabilities to power the Envision DeAI Network.Envision Labs has selected Akash as its primary compute provider, leveraging its automated scaling capabilities to power the Envision DeAI Network.Envision Labs has selected Akash as its primary compute provider, leveraging its automated scaling capabilities to power the Envision DeAI Network. View project","tokens":2208,"squid":"spider-03","role":"Compute Spider","at":1791340570659,"hash":"c2399923b2e6ea437ec868372d4679d887d08edd"}
{"url":"https://www.paradigm.xyz/research-index","domain":"paradigm.xyz","title":"Research Index | Paradigm","text":"Featured Tools Research Index All Research Paradigm Puzzles Programs All Research From cryptographic breakthroughs to AI security and protocol design, our research is built to ship — as open source tools, protocol contributions, and new primitives for builders at the frontier. Date (Desc) Title (Asc) Category 2026-09-30 The Game Theory of AI Pacing Justin Wang, Dan Robinson, Andrew Koh Research, Announcements 2026-08-31 GPU World Matt Huang Announcements, Research 2026-08-11 RSI Simulator Justin Wang, Dan Robinson Research 2026-08-10 Centaur 2.0: Permissions, Context, and MCP Matthew Slipper, Georgios Konstantopoulos Build, Research 2026-07-24 Formally Verifying a Compiler Using Automated Research Dan Robinson Research 2026-06-12 Project Kryptos Dan Robinson, Matt Huang Research 2026-05-21 Open Sourcing Centaur: Multiplayer, self-hosted, secure agents Georgios Konstantopoulos, Arjun Balaji, Zygimantas Magelinskas, Matthew Slipper, Goksu Toprak, Akshaan Kakar, Dan Robinson, Omar Aziz, Achal Srinivasan Build, Research 2026-05-01 PACTs: Protecting Your Bitcoin From a Quantum Sunset Dan Robinson Research 2026-02-04 Introducing Paradigm Predictions Storm Slivkoff Research 2025-12-08 Polymarket Volume Is Being Double-Counted Storm Slivkoff Research 2025-08-18 Opportunity Markets Dave White, Matt Liston Research 2025-06-12 Quantum Markets Alpin Yukseloglu, Sofiane Larbi Research 2025-06-02 Orbital Dan Robinson, Ciamac Moallemi, Dave White Research 2025-05-12 Multiverse Finance Dave White Research 2025-05-06 Across Prime Hart Lambur, Matt Rice, Dan Robinson Research 2025-05-02 Timing Advantages in Onchain Auctions Ciamac Moallemi, Mallesh Pai, Dan Robinson Research 2025-03-31 Demystifying the North Korean Threat samczsun Research 2025-02-19 What comes after Ethereum’s Pectra hard fork? Georgios Konstantopoulos Research, Build 2025-01-25 Ethereum Acceleration Georgios Konstantopoulos, Dan Robinson, Matt Huang, Charlie Noyes Research, Build 2024-12-10 Distribution Markets Dave White Research 2024-11-21 The 5 Levels of Secure Hardware Georgios Konstantopoulos Research, Build 2024-11-05 pm-AMM: A Uniform AMM for Prediction Markets Ciamac Moallemi, Dan Robinson Research 2024-10-10 Unichain Hayden Adams, Mark Toda, Alex Karys, Xin Wan, Daniel Gretzke, Eric Zhong, Zach Wong, Daniel Marzec, Robert Miller, Hasu, Karl Floersch, Dan Robinson Research 2024-10-08 How to Remove the Relay Charlie Noyes, Guru Vamsi Policharla Research 2024-06-20 Releasing Revmc DaniPopes, Georgios Konstantopoulos Research, Build 2024-06-11 From Staking to Restaking Arjun Balaji, Georgios Konstantopoulos, Dave White Research, Announcements 2024-06-04 Priority Is All You Need Dan Robinson, Dave White Research 2024-05-07 How to Raise the Gas Limit, Part 2: History Growth Storm Slivkoff, Georgios Konstantopoulos Research, Build 2024-05-02 Fig: Frame Interface Guidelines Achal Srinivasan, Georgios Konstantopoulos, awkweb, jxom Research, Build 2024-03-06 Everything Is A Perp Dan Robinson, Joe Clark, Andrew Leone Research 2024-03-05 Joining Paradigm as Research Advisor Ciamac Moallemi Announcements, Research 2024-03-04 How to Raise the Gas Limit, Part 1: State Growth Storm Slivkoff, Georgios Konstantopoulos Research, Build 2024-02-13 Leaderless Auctions Dan Robinson, Dave White, Ludwig Thouvenin, Karthik Srinivasan Research 2024-01-17 What comes after Ethereum's Cancun hard fork? Georgios Konstantopoulos Research, Build 2023-09-20 The Casino on Mars Matt Huang Research 2023-08-14 The Open Problems of Onchain Games Charlie Noyes, Doug Feagin Research 2023-07-25 Collaborate with Paradigm Matt Huang, Georgios Konstantopoulos, Dan Robinson Research, Build 2023-06-01 Intent-Based Architecture and Their Risks Georgios Konstantopoulos, Quintus Kilbourn Research, Build 2023-05-01 Blend: Perpetual Lending With NFT Collateral Dan Robinson, transmissions11, Galaga, Toad, Pacman Research 2023-04-27 Time, slots, and the ordering of events in Ethereum Proof-of-Stake Georgios Konstantopoulos, Mike Neuder Research, Build 2023-01-12 Generating secure randomness on Ethereum using SNARKs Georgios Konstantopoulos, amangottumukkala, sinasabet Research, Build 2022-09-20 Open Sourcing the Art Gobblers Smart Contracts Frankie, transmissions11, Dave White, Justin Roiland Research 2022-09-13 Art Gobblers Frankie, transmissions11, Dave White Research 2022-09-09 Goldfish: A Provably Secure Replacement for LMD GHOST in PoS Ethereum Francesco D’Amato, joachimneu, Ertem Nusret Tas, David Tse Research 2022-09-06 GOO (Gradual Ownership Optimization) Frankie, transmissions11, Dave White Research 2022-08-25 Data Availability Sampling: From Basics to Open Problems joachimneu Research 2022-08-24 Variable Rate GDAs transmissions11, Frankie, Dave White Research 2022-07-29 Cosmos without Tendermint: Exploring Narwhal and Bullshark joachimneu, Georgios Konstantopoulos, andrewkirillov Research, Build 2022-07-11 Understanding Blockchain Latency and Throughput Lefteris Kokoris-Kogias Research 2022-05-05 The Dominance of Uniswap v3 Liquidity Gordon Liao, Dan Robinson Research 2022-04-13 Hardware Acceleration for Zero Knowledge Proofs Georgios Konstantopoulos Research, Build 2022-04-04 Gradual Dutch Auctions Frankie, Dan Robinson, Dave White, Andy8052 Research 2022-01-25 Constant Rate Issuance Sales Protocol Frankie, Dave White, Justin Roiland Research 2021-11-11 Hiding in Plain Sight samczsun Research 2021-10-13 A Guide to Designing Effective NFT Launches Hasu, Anish Agnihotri Research 2021-10-06 RICKS Dan Robinson, Dave White, Andy8052 Research 2021-09-14 Martingale Shares Dave White Research 2021-08-31 Floor Perps Dave White Research 2021-08-17 Power Perpetuals Dan Robinson, Dave White, Zubin Koticha, Andrew Leone, Alexis Gauba, Aparna Krishnan Research 2021-08-17 Two Rights Might Make A Wrong samczsun Research 2021-08-13 The Dangers of Surprising Code samczsun Research 2021-07-28 TWAMM Dan McCarthy, Dave White, Hayden Adams Research 2021-07-20 Ethereum Reorgs After The Merge Georgios Konstantopoulos, Vitalik Buterin Research, Build 2021-06-07 Uniswap v3: The Universal AMM Dan Robinson Research 2021-05-27 Booby Trapping the Ethereum Blockchain samczsun Research 2021-05-18 Liquidity Mining on Uniswap v3 Dan Robinson Research 2021-05-11 Everlasting Options Dave White, Sam Bankman-Fried Research 2021-04-23 On Staking Pools and Staking Derivatives Hasu, Georgios Konstantopoulos Research, Build 2021-04-19 Understanding Automated Market-Makers, Part 1: Price Impact Hasu Research 2021-04-19 Uncovering a Four Year Old Bug samczsun Research 2021-04-09 Paradigm CTF 2021 - swap samczsun Research 2021-04-08 A Cosmos Thesis Charlie Noyes, Dan Robinson Research 2021-03-30 The Block Mined In January, 584942419325 samczsun Research 2021-03-25 Ethereum Blockspace - Who Gets What and Why Georgios Konstantopoulos, Leo Zhang Research, Build 2021-03-08 The Cartoon Guide to Perps Dave White Research 2021-02-26 Establishing Bounds for Miner Revenue in EIP-1559 Hasu, Georgios Konstantopoulos Research, Build 2021-02-22 Miners will accept EIP-1559, here is why Hasu, Georgios Konstantopoulos Research, Build 2021-02-05 MEV and me Charlie Noyes Research 2021-01-29 How does Optimism's Rollup really work? Georgios Konstantopoulos, Hasu Research, Build 2021-01-27 (Almost) Everything you need to know about Optimistic Rollup Georgios Konstantopoulos Research, Build 2020-12-20 Paradigm's Open Problems: A Series Charlie Noyes Research 2020-12-01 Uniswap's Financial Alchemy Dan Robinson, Dave White, Charlie Noyes, Martin Tassy Research 2020-11-09 So you want to use a price oracle samczsun Research 2020-10-28 Governance Minimization Fred Ehrsam Research 2020-09-24 Escaping the Dark Forest samczsun Research 2020-08-28 Ethereum is a Dark Forest Dan Robinson, Georgios Konstantopoulos Research, Build 2020-06-24 Analysis of EIP-2593 (Escalator) Hasu, Georgios Konstantopoulos Research, Build 2020-06-10 Analysis of EIP-1559 Georgios Konstantopoulos, Hasu Research, Build 2020-04-01 The Yield Protocol: On-Chain Lending With Interest Rate Discovery Dan Robinson Research 2019-11-01 An analysis of Uniswap markets Charlie Noyes, Guillermo Angeris, Hsien-Tang Kao, Rei Chiang, Tarun Chitra Research 2019-03-01 The Rainbow Network: An Off-Chain Decentralized Synthetics Exchange Dan Robinson Research All Announcements Research Build List/Grid List/Grid","tokens":2092,"squid":"spider-04","role":"Research Spider","at":1791340576578,"hash":"7c6a77f87573fcb5105acdec9b6267c5739d7ff9"}
{"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":"spider-05","role":"Spec Spider","at":1791340582060,"hash":"ad55bb3de69f23fa1cde4e917c97d5dcf9f7125a"}
{"url":"https://www.paradigm.xyz/writing/polymarket-volume-is-being-double-counted","domain":"paradigm.xyz","title":"Polymarket Volume Is Being Double-Counted","text":"Polymarket Volume Is Being Double-Counted After analyzing Polymarket’s market structure, event data, and smart contracts, we discovered that most Polymarket analyses and dashboards have been mistakenly double-counting volume. Polymarket’s onchain data is quite complex, and this has led to widespread adoption of flawed accounting methods. However, this data becomes easy to work with using the principles explained below.\n\nThis article contains the following sections:\n1. Anatomy of a Polymarket Trade\nHow do Polymarket trades manifest in onchain data?\n\n2. Not All Matches Are Swaps\nHow do prediction market matching engines work?\n\n3. Prediction Market Volume Metrics\nWhat is the right way to measure volume?\n\nMain Claims:The common approach of summing Polymarket’s OrderFilled events leads to double counting volume. This approach double counts both the number of contracts traded and USD cash flow. For example, a simple sale of YES tokens for $4.13 gets recorded as $8.26 worth of volume. This is because there are separate OrderFilled events representing the maker side and taker side of the trade.\n\nVolume on prediction markets should be measured using a one-sided volume metric, such as taker-side volume or maker-side volume. There are multiple valid ways to measure prediction market volume, but summing up all OrderFilled events is not one of them.This article is unrelated to wash trading or other types of volume classification. We are simply describing how to measure the total raw volume occurring on Polymarket, especially in a manner that enables apples-to-apples comparisons to other prediction market platforms.\n\nAnatomy of a Polymarket Trade\nWe will begin by describing the onchain data associated with each Polymarket trade.\n\nPolymarket trade transactions all follow a rigid template:There is at most one group of matched Polymarket orders per Polygon transaction.Each set of matched orders has exactly one taker and at least one maker.Trade transactions are submitted by ~50 Polymarket-affiliated EOA’s.Event Structure\nPolymarket uses 2 EVM events to track trades: OrderFilled and OrdersMatched.\nBoth events have these fields:makerAssetID: either 0 (for USDC), or the YES token id, or the NO token idtakerAssetID: either 0 (for USDC), or the YES token id, or the NO token idmakerAmountFilled: amount of maker tokenstakerAmountFilled: amount of taker tokensThe OrderFilled event also has a maker field and taker field that we describe below.Event SequenceEach Polymarket trade transaction has the same sequence of events:There is at least one “maker-focused” OrderFilled eventone of these events is emitted for each maker involved in the transactionthe maker values of these events are usually (but not always) distinctall of these events have the same taker, which is the overall taker of transactionneither the maker nor taker of these events are Polymarket exchange contractsThen there is exactly one “taker-focused” OrderFilled eventits maker is the transaction’s overall takerits taker is a Polymarket exchange contract (CTF or NegRisk)Finally there is exactly one OrdersMatched eventit has the same makerAmountFilled and takerAmountFilled as the “taker-focused” OrderFilled event of (2)Critically, item (2) is redundant with item (1). This final OrderFilled is a second representation of the same trades, rather than an additional trade between the taker and Polymarket exchange. It does not represent additional economic activity, nor does it represent any additional transfer of risk between market participants.\nFurthermore, a common point of confusion is that the total token volume recorded by OrderFilled events is roughly 2x the total token volume recorded by OrdersMatched events. This discrepancy is resolved by realizing that each transaction contains two sets of OrderFilled events that both represent the same trades.\nAn additional point of confusion is that these two sets of OrderFilled events, corresponding to makers and takers, can measure different amounts of volume for an individual trade. This is resolved by realizing that makers and takers can experience different amounts of volume during split trades and merge trades. But aggregated over many trades, on the timescales of days or months, the amount of maker volume and taker volume tend to converge to the same value. We elaborate on this in a later section.\nSmart Contract StructurePolymarket’s event sequence is further clarified by looking at the Polymarket exchange contracts. Each trade is facilitated by one of two exchange contracts, CTF or NegRisk CTF. The portion of code that emits OrderFilled and OrdersMatched is shown in Figure 1. This code is the same in both contracts. Each Polymarket trade follows the same sequence:Enter the contract via the matchOrders() function,
which simply calls _matchOrders()Transfer taker’s tokens from the taker to the exchange contract_fillMakerOrders() loops through the makers. For each one:Compute fees to the makerPerform split/merge operations if necessary
(see next section)Transfer maker tokens from the maker to the exchange contractTransfer taker tokens from the exchange contract to the makerTransfer maker fees from exchange contract to fee collectorEmit an OrderFilled event describing the portion of the taker’s trade filled by the makerTransfer makers’ tokens from the exchange contract to takerTransfer taker fees from the exchange contract to fee collectorEmit an OrderFilled event describing the entire set of fillsEmit an OrdersMatched event describing the entire set of fills\nIn this design the exchange contract acts as a router. It is either the sender or receiver of each token transfer. Critically though, the exchange takes no positions, it provides no funds, it assumes no risk, and it is not the counterparty to any trade. The only trades that occur are between the taker and each of the makers. Thus, the two types of OrderFilled events are two representations of the same trades and they should not be added together.\n\nIt should be noted that none of the OrderFilled events contain incorrect information. There are many reasons why a smart contract might be designed to emit extra events (e.g. it might make it easier to report each user’s history on the frontend). Incorrect information only enters the picture when someone attempts to compute volume by summing up all of the OrderFilled events.\nNot All Matches Are SwapsBeyond the redundant OrderFilled emission, Polymarket transactions can also be confusing because the matching engine can match orders across the YES and NO orderbooks within the same multileg trade. These are not conventional swaps, and at first glance they can appear to produce accounting that seems arbitrary or imbalanced.\n\nTake this Polymarket trade for example, with Polygonscan representation shown in Figure 2. Polygonscan summarizes this transaction as “Place Bet of $28.41”. It was an active market that had not yet resolved. So why is there a party that nets out $6780?What actually happened here:The taker 0x0c45 sold $90 of YES shares in a market orderThis taker order was filled by matching with two market makersThe first market maker 0xd9A5 bought $28 of YESThe second market maker 0x8E8C sold $6780 of NOTo understand the last bullet, it is necessary to understand the YES-NO Split-Merges\n\nYES-NO Split-MergesPolymarket represents positions using the dual assets of YES tokens and NO tokens. In the main smart contract controlling these tokens, the only way to interconvert between these YES and NO are split and merge operations:\nSplit: Exchange $1 for (1 YES token + 1 NO token)Merge: Exchange (1 YES token + 1 NO token) for $1\nPrior to the transaction above, second market maker 0x8E8C had opened sell orders for their NO tokens. The matching engine figured out that some of the YES tokens being sold by taker 0x0c45 could be merged with some of the NO tokens being sold by maker 0x8E8C, which would produce sufficient USDC to partially fill both orders. Then to execute the trade, the exchange contract 1) gathers the YES and NO tokens from both parties, 2) merges them, and 3) then distributes the proceeds pro rata according to the trade’s execution price.\n\nToken Accounting\nHere is the sequence of token transfers in the transaction (Figure 3A), along with the associated net balance changes (Figure 3B).The exchange is the sender or receiver of each of these transfers. The vault is the “Conditional Tokens” contract that stores all of the USDC backing the YES-NO token pairs. Gallery (2 images)\nMarket Structure of Splits and Merges Versus SwapsThe market structure can be described as follows: Polymarket’s matching engine matches makers and takers. Some of these matches are conventional swaps, where one market participant transfers their risk exposure to another market participant in exchange for USDC. This works similarly to spot exchanges like Uniswap or Binance. But the YES-NO structure of prediction markets also allows another type of match using a split or merge. In these special matches:The maker and taker are either both sending or both receiving USDC (instead of there being one sender and one receiver).\nThe buyer and seller mutually agree to take opposite sides of a market, either to create new open interest or to close existing open interest. The open interest in the system increases or decreases (instead of remaining constant as in a spot swap).\nThe maker and taker are usually sending or receiving different amounts of value (instead of the buyer’s USD delta being approximately the same size to the seller’s USD delta).Split trades are matches where maker and taker agree to both exchange their USDC for shares, and then one party receives the YES exposure and the other receives the NO exposure. Merge trades are matches where maker and taker agree to exchange their opposing YES and NO shares for USDC.\n\nWith these principles in mind we can describe the example trade from above in more precise terms. It was a two-leg trade, where the first leg was a swap, and the second leg was a merge.In the swap leg, the taker exchanged 3,157.02 YES tokens for $28.41, and the maker exchanged $28.41 for 3,157.02 YES tokens. Both maker and taker experienced the same amount of cash flow volume, $28.41. They also experienced the same amount of contract volume, 3,157.02.\nIn the merge leg, the taker exchanged their 6,842.98 YES tokens for $61.59, and the maker exchanged 6,842.98 NO tokens for $6781.39. The taker and maker experienced the same amount of contract volume 6,842.98, but different amounts of cash flow volume.\nSumming the OrderFilled event report simply adds the maker volume to the taker volume, as there are separate OrderFilled events representing the maker side and taker side of the trade.It reports a total contract volume of 3,157.02 + 3,157.02 + 6,842.98 + 6,842.98 = 20,000It reports a total USDC volume of 28.41 + 28.41 + 61.59 + 6781.39 = $6899.80As explained in the next section, there are multiple valid ways to interpret how much volume occurred in the second leg of the trade, but adding up maker and taker is not one of them. This sum is a form of double counting that produces a volume number that is not comparable to volume metrics of other prediction market trading venues.\nPrediction Market Volume Metrics\nThere are multiple valid ways to compute volume on prediction markets. However, all of these approaches roughly agree on a volume value around 50% of the Polymarket’s OrderFilled sum.\n\nFor a complete accounting, we will start with the 8 types of simple trades that occur on Polymarket:Taker buys YES, maker sells YES (swap)Taker buys NO, maker sells NO (swap)Taker sells YES, maker buys YES (swap)Taker sells NO, maker buys NO (swap)Taker buys YES, maker buys NO (split)Taker sells NO, maker sells YES (merge)Taker sells NO, maker sells YES (merge)Taker sells YES, maker sells NO (merge)We built a simulator that illustrates how various trading metrics behave under each of these 8 trade types. For each trade type, the simulator computes 1) maker/taker balance changes, 2) open interest change, and 3) a variety of volume metrics. An example output is shown in Figure 4. The only two inputs needed for the simulation are 1) the YES price and 2) the number of contracts traded. You can make a copy of the spreadsheet and change these parameters to perform your own simulations. For simplicity, we assume zero fees and (NO price) equals exactly $1 - (YES price).\n\nWe will now go through each item in the simulator output.\n\nAccount Deltas and Open Interest ChangesThe first few columns in the simulator track how much the open interest and maker/taker balances change during each trade.\n\nTake note of a few invariants:For each trade type, the taker and maker always take opposite positions. One is long YES resolution, and the other is short YES resolution.The taker and maker YES and NO deltas always have the same absolute value. This is different from their USDC deltas, which can have different absolute values.Split trades always increase open interest, merge trades always decrease open interest, and swap trades always leave open interest unchanged.Volume MetricsThere are two categories of prediction market volume metrics in common use:Notional Volume: number of contracts tradedCash Flow Volume: the amount of USD exchanged at time of tradeComputing these metrics for swap trades is straightforward. The notional volume is simply the number of contracts traded. The cash flow volume is the number of contracts traded multiplied by the share price. For both of these volume metrics, Polymarket’s OrderFilled sum gives a value that is 2x the correct value.\n\nComputing these metrics for split trades and merge trades is more complicated because they are not swaps in the conventional sense (see the Splits and merges versus swaps section). In a conventional swap, the maker and taker experience the same amount of volume. But in a split trade or merge trade, the maker and the taker can experience different amounts of volume. We are not opinionated about whether to measure the maker’s volume, the taker’s volume, or something in between. However, simply adding the two together is double counting, just as it would be with a swap trade.\n\nWith these considerations in mind, computing the notional volume for split trades and merge trades becomes straightforward. It is simply the number of contracts that are split or merged.\n\nComputing the cash flow volume for split trades and merge trades is the most complicated case. As mentioned above, the maker and taker will experience different amounts of cash flow. Whether to focus on the maker’s cash flow, the taker’s cash flow, the maker taker mean, or some other approximation (like share-priced volume) can depend on the context. These metrics can each produce different volume values for an individual trade. However, these metrics all produce about the same volume numbers when aggregated over longer timescales of days or months (see Figure 5 below). Thus, the exact choice of cash flow metric is often unimportant. The only important note is that summing up OrderFlow events does not agree with these volume metrics, and it instead produces a value about 2x as large due to double counting (see Figure 5 below).Polymarket USDC Volume Metrics Figure 5: Monthly Polymarket volume under different metrics. The Taker-side volume, Maker-side volume, and share-priced volume are each around half of the OrderFilled sum. One indicator that a Polymarket volume chart might be using OrderFilled sums is checking whether monthly volume for 2024-10 and 2024-11 is around $2.5B. Realworld ExamplesThe final columns of the spreadsheet provide 4 examples of historical transactions for each of the 8 trade types. The price and size parameters of each example can be input into cells A1 and A2 of the spreadsheet to simulate the sum of each transaction’s OrderFilled events. Figure 6: The spreadsheet contains 4 examples of realworld trades for each of the 8 trade types A view of these examples is shown in Figure 6. Note also that these examples are drawn from both the Polymarket CTF Exchange and the Polymarket Negrisk exchange, and each exchange has identical OrderFilled emissions.\n\nOne of the difficulties of analyzing Polymarket data has been the large number of trade types. Even with knowledge of the 8 trade types, it is not easy to find or identify specific trade types using a block explorer. These 32 example trades should be a useful resource for anyone trying to learn more about Polymarket data.\nWhich Metrics To Use?Here is a comparison of the metrics mentioned in a single view: For notional volume, measurement is straightforward. Simply measure the number of contracts traded.\n\nFor cash flow volume there are multiple possibilities. Can use the cash flow of the maker, or the cash flow of the taker, or an average of the two. Each of these can be derived from Polymarket’s onchain data, and each produces similar volume numbers when aggregated over days or months (Figure 5).\n\nTaker-side volume can be obtained by filtering and summing OrderFilled events where the taker field is equal to one of the two exchange contracts (CTF 0x4bfb41d5b3570defd03c39a9a4d8de6bd8b8982e and NegRisk 0xc5d563a36ae78145c45a50134d48a1215220f80a). Maker-side volume can be computed by filtering and summing OrderFilled events where the taker field is not equal to either of these exchange contracts.ConclusionPrediction markets are rapidly evolving into a critical financial sector. As the category matures, the industry should converge on consistent, transparent, and objective reporting standards. This is particularly important for comparing activity across platforms, as well as assessing the growing role of prediction markets in everyday life.\n\nIn our investigation into this topic, we discovered that most Polymarket analyses and dashboards have been unintentionally double-counting volume. The confusion results from interacting layers of complexity:\n\nSwap matches and split/merge matches lead to 8 possible types of single-leg trades, and an even larger variety of multi-leg trades.Each type of trade leads to slightly different event emissions from Polymarket contracts.Although no single Polymarket event contains incorrect information, the event stream contains redundant representations of the maker side and taker side of each trade. Simple summation of these events leads to double counting.\nThese factors are mostly undocumented, and standard tools like block explorers are not sufficient for untangling the complexity. A more precise account of this data only emerges when examining multiple lines of evidence (market structure, event emissions, and smart contract architecture). But taken together, these lines of evidence paint a clear and consistent view of how prediction market trades can be measured and compared.\n\nMassive thanks to dash, Allium, Dan Smith, Chaos Labs, Ricardo de Arruda, Ciamac Moallemi, Dan Robinson, and frankie for feedback + conversations that helped untangle this dataDisclosure: Paradigm is an investor in Kalshi, a competitor to Polymarket.\n\nAppendix: Examples in the WildCompare the charts below to Figure 5. Note that a value of ~$2.5B monthly volume in the months of 2024-10 and 2025-11 generally indicates that a dashboard is computing volume by summing up all OrderFilled events.We have validated this information with multiple dashboard creators and data analysts. DefiLlama, Allium, Blockworks, and others are now updating their dashboards to remove the double-counting. Allium Blockworks DefiLlama Dune #1 Dune #2 Dune #3 Dune #4 Dune #5 Token Terminal","tokens":4909,"squid":"spider-04","role":"Research Spider","at":1791340591664,"hash":"a6c14bdb07afb5b60fefdbd61ec5a1a3c2e1fc56"}
{"url":"https://eips.ethereum.org/EIPS/eip-198","domain":"eips.ethereum.org","title":"EIP-198: Big integer modular exponentiation","text":"🎉 Final\n\n Standards Track: Core\n\n EIP-198: Big integer modular exponentiation\n\n Authors\n Vitalik Buterin (@vbuterin)\n\n Created\n 2017-01-30\n\n Parameters\n\n GQUADDIVISOR: 20\n\n Specification\n\nAt address 0x00……05, add a precompile that expects input in the following format:\n\n<length_of_BASE> <length_of_EXPONENT> <length_of_MODULUS> <BASE> <EXPONENT> <MODULUS>\n\nWhere every length is a 32-byte left-padded integer representing the number of bytes to be taken up by the next value. Call data is assumed to be infinitely right-padded with zero bytes, and excess data is ignored. Consumes floor(mult_complexity(max(length_of_MODULUS, length_of_BASE)) * max(ADJUSTED_EXPONENT_LENGTH, 1) / GQUADDIVISOR) gas, and if there is enough gas, returns an output (BASE**EXPONENT) % MODULUS as a byte array with the same length as the modulus.\n\nADJUSTED_EXPONENT_LENGTH is defined as follows.\n\n If length_of_EXPONENT <= 32, and all bits in EXPONENT are 0, return 0\n If length_of_EXPONENT <= 32, then return the index of the highest bit in EXPONENT (eg. 1 -> 0, 2 -> 1, 3 -> 1, 255 -> 7, 256 -> 8).\n If length_of_EXPONENT > 32, then return 8 * (length_of_EXPONENT - 32) plus the index of the highest bit in the first 32 bytes of EXPONENT (eg. if EXPONENT = \\x00\\x00\\x01\\x00.....\\x00, with one hundred bytes, then the result is 8 * (100 - 32) + 253 = 797). If all of the first 32 bytes of EXPONENT are zero, return exactly 8 * (length_of_EXPONENT - 32).\n\nmult_complexity is a function intended to approximate the difficulty of Karatsuba multiplication (used in all major bigint libraries) and is defined as follows.\n\ndef mult_complexity(x):\n if x <= 64: return x ** 2\n elif x <= 1024: return x ** 2 // 4 + 96 * x - 3072\n else: return x ** 2 // 16 + 480 * x - 199680\n\nFor example, the input data:\n\n0000000000000000000000000000000000000000000000000000000000000001\n0000000000000000000000000000000000000000000000000000000000000020\n0000000000000000000000000000000000000000000000000000000000000020\n03\nfffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2e\nfffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2f\n\nRepresents the exponent 3**(2**256 - 2**32 - 978) % (2**256 - 2**32 - 977). By Fermat’s little theorem, this equals 1, so the result is:\n\n0000000000000000000000000000000000000000000000000000000000000001\n\nReturned as 32 bytes because the modulus length was 32 bytes. The ADJUSTED_EXPONENT_LENGTH would be 255, and the gas cost would be mult_complexity(32) * 255 / 20 = 13056 gas (note that this is ~8 times the cost of using the EXP opcode to compute a 32-byte exponent). A 4096-bit RSA exponentiation would cost mult_complexity(512) * 4095 / 100 = 22853376 gas in the worst case, though RSA verification in practice usually uses an exponent of 3 or 65537, which would reduce the gas consumption to 5580 or 89292, respectively.\n\nThis input data:\n\n0000000000000000000000000000000000000000000000000000000000000000\n0000000000000000000000000000000000000000000000000000000000000020\n0000000000000000000000000000000000000000000000000000000000000020\nfffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2e\nfffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2f\n\nWould be parsed as a base of 0, exponent of 2**256 - 2**32 - 978 and modulus of 2**256 - 2**32 - 977, and so would return 0. Notice how if the length_of_BASE is 0, then it does not interpret any data as the base, instead immediately interpreting the next 32 bytes as EXPONENT.\n\nThis input data:\n\n0000000000000000000000000000000000000000000000000000000000000000\n0000000000000000000000000000000000000000000000000000000000000020\nffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff\nfffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffe\nfffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffd\n\nWould parse a base length of 0, an exponent length of 32, and a modulus length of 2**256 - 1, where the base is empty, the exponent is 2**256 - 2 and the modulus is (2**256 - 3) * 256**(2**256 - 33) (yes, that’s a really big number). It would then immediately fail, as it’s not possible to provide enough gas to make that computation.\n\nThis input data:\n\n0000000000000000000000000000000000000000000000000000000000000001\n0000000000000000000000000000000000000000000000000000000000000002\n0000000000000000000000000000000000000000000000000000000000000020\n03\nffff\n8000000000000000000000000000000000000000000000000000000000000000\n07\n\nWould parse as a base of 3, an exponent of 65535, and a modulus of 2**255, and it would ignore the remaining 0x07 byte.\n\nThis input data:\n\n0000000000000000000000000000000000000000000000000000000000000001\n0000000000000000000000000000000000000000000000000000000000000002\n0000000000000000000000000000000000000000000000000000000000000020\n03\nffff\n80\n\nWould also parse as a base of 3, an exponent of 65535 and a modulus of 2**255, as it attempts to grab 32 bytes for the modulus starting from 0x80 - but there is no further data, so it right-pads it with 31 zero bytes.\n\n Rationale\n\nThis allows for efficient RSA verification inside of the EVM, as well as other forms of number theory-based cryptography. Note that adding precompiles for addition and subtraction is not required, as the in-EVM algorithm is efficient enough, and multiplication can be done through this precompile via a * b = ((a + b)**2 - (a - b)**2) / 4.\n\nThe bit-based exponent calculation is done specifically to fairly charge for the often-used exponents of 2 (for multiplication) and 3 and 65537 (for RSA verification).\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), \"EIP-198: Big integer modular exponentiation,\" Ethereum Improvement Proposals, no. 198, January 2017. Available: https://eips.ethereum.org/EIPS/eip-198.","tokens":1449,"squid":"spider-05","role":"Spec Spider","at":1791340595911,"hash":"cc917fdb913bb463bfc8ed7e210a89658c09632c"}
{"url":"https://akash.network/ecosystem/deployed-on-akash/nft","domain":"akash.network","title":"NFT | Deployed On Akash","text":"NFT OmniFlix Interoperable P2P network for creators & sovereign communities (#DAOs or otherwise) to mint, manage, monetize & coordinate distribution activities around NFTsInteroperable P2P network for creators & sovereign communities (#DAOs or otherwise) to mint, manage, monetize & coordinate distribution activities around NFTsInteroperable P2P network for creators & sovereign communities (#DAOs or otherwise) to mint, manage, monetize & coordinate distribution activities around NFTs View project Stargaze Community-owned app chain for NFTs with CosmWasm smart contracts. 100% carbon neutral. Zero gas. Several Stargaze validators are running on Akash as confirmed by their official Twitter Account.Community-owned app chain for NFTs with CosmWasm smart contracts. 100% carbon neutral. Zero gas. Several Stargaze validators are running on Akash as confirmed by their official Twitter Account.Community-owned app chain for NFTs with CosmWasm smart contracts. 100% carbon neutral. Zero gas. Several Stargaze validators are running on Akash as confirmed by their official Twitter Account. View project","tokens":276,"squid":"spider-03","role":"Compute Spider","at":1791340595967,"hash":"81ec071a916f52f87eb6cc8198d94d038c14e08a"}
{"url":"https://eips.ethereum.org/EIPS/eip-211","domain":"eips.ethereum.org","title":"EIP-211: New opcodes: RETURNDATASIZE and RETURNDATACOPY","text":"🎉 Final\n\n Standards Track: Core\n\n EIP-211: New opcodes: RETURNDATASIZE and RETURNDATACOPY\n\n Authors\n Christian Reitwiessner <chris@ethereum.org>\n\n Created\n 2017-02-13\n\n Simple Summary\n\nA mechanism to allow returning arbitrary-length data inside the EVM has been requested for quite a while now. Existing proposals always had very intricate problems associated with charging gas. This proposal solves the same problem while at the same time, it has a very simple gas charging mechanism and requires minimal changes to the call opcodes. Its workings are very similar to the way calldata is handled already; after a call, return data is kept inside a virtual buffer from which the caller can copy it (or parts thereof) into memory. At the next call, the buffer is overwritten. This mechanism is 100% backwards compatible.\n\n Abstract\n\nPlease see summary.\n\n Motivation\n\nIn some situations, it is vital for a function to be able to return data whose length cannot be anticipated before the call. In principle, this can be solved without alterations to the EVM, for example by splitting the call into two calls where the first is used to compute only the size. All of these mechanisms, though, are very expensive in at least some situations. A very useful example of such a worst-case situation is a generic forwarding contract; a contract that takes call data, potentially makes some checks and then forwards it as is to another contract. The return data should of course be transferred in a similar way to the original caller. Since the contract is generic and does not know about the contract it calls, there is no way to determine the size of the output without adapting the called contract accordingly or trying a logarithmic number of calls.\n\nCompiler implementors are advised to reserve a zero-length area for return data if the size of the return data is unknown before the call and then use RETURNDATACOPY in conjunction with RETURNDATASIZE to actually retrieve the data.\n\nNote that this proposal also makes the EIP that proposes to allow to return data in case of an intentional state reversion (EIP-140) much more useful. Since the size of the failure data might be larger than the regular return data (or even unknown), it is possible to retrieve the failure data after the CALL opcode has signalled a failure, even if the regular output area is not large enough to hold the data.\n\n Specification\n\nIf block.number >= BYZANTIUM_FORK_BLKNUM, add two new opcodes and amend the semantics of any opcode that creates a new call frame (like CALL, CREATE, DELEGATECALL, …) called call-like opcodes in the following. It is assumed that the EVM (to be more specific: an EVM call frame) has a new internal buffer of variable size, called the return data buffer. This buffer is created empty for each new call frame. Upon executing any call-like opcode, the buffer is cleared (its size is set to zero). After executing a call-like opcode, the complete return data (or failure data, see EIP-140) of the call is stored in the return data buffer (of the caller), and its size changed accordingly. As an exception, CREATE and CREATE2 are considered to return the empty buffer in the success case and the failure data in the failure case. If the call-like opcode is executed but does not really instantiate a call frame (for example due to insufficient funds for a value transfer or if the called contract does not exist), the return data buffer is empty.\n\nAs an optimization, it is possible to share the return data buffer across call frames because at most one will be non-empty at any time.\n\nRETURNDATASIZE: 0x3d\n\nPushes the size of the return data buffer onto the stack.\nGas costs: 2 (same as CALLDATASIZE)\n\nRETURNDATACOPY: 0x3e\n\nThis opcode has similar semantics to CALLDATACOPY, but instead of copying data from the call data, it copies data from the return data buffer. Furthermore, accessing the return data buffer beyond its size results in a failure; i.e. if start + length overflows or results in a value larger than RETURNDATASIZE, the current call stops in an out-of-gas condition. In particular, reading 0 bytes from the end of the buffer will read 0 bytes; reading 0 bytes from one-byte out of the buffer causes an exception.\n\nGas costs: 3 + 3 * ceil(amount / 32) (same as CALLDATACOPY)\n\n Rationale\n\nOther solutions that would allow returning dynamic data were considered, but they all had to deduct the gas from the call opcode and thus were both complicated to implement and specify (5/8). Since this proposal is very similar to the way calldata is handled, it fits nicely into the concept. Furthermore, the eWASM architecture already handles return data in exactly the same way.\n\nNote that the EVM implementation needs to keep the return data until the next call or the return from the current call. Since this resource was already paid for as part of the memory of the callee, it should not be a problem. Implementations may either choose to keep the full memory of the callee alive until the next call or copy only the return data to a special memory area.\n\nKeeping the memory of the callee until the next call-like opcode does not increase the peak memory usage in the following sense; any memory allocation in the caller’s frame that happens after the return from the call can be moved before the call without a change in gas costs, but will add this allocation to the peak allocation.\n\nThe number values of the opcodes were allocated in the same nibble block that also contains CALLDATASIZE and CALLDATACOPY.\n\n Backwards Compatibility\n\nThis proposal introduces two new opcodes and stays fully backwards compatible apart from that.\n\n Test Cases\n\n Implementation\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-211: New opcodes: RETURNDATASIZE and RETURNDATACOPY,\" Ethereum Improvement Proposals, no. 211, February 2017. Available: https://eips.ethereum.org/EIPS/eip-211.","tokens":1496,"squid":"spider-05","role":"Spec Spider","at":1791340610766,"hash":"b4257d74ecae130a8f07c167cbae08ffebff0cfc"}
{"url":"https://chatapi.akash.network/","domain":"chatapi.akash.network","title":"AkashML - Scale Your AI with High-Performance Inference","text":"PlaygroundModelsPricingFAQsDocsModelsPricingFAQsDocsExplore PlaygroundAI Inference ServiceBuilt on Akash NetworkScale Your AIHigh-performance, low latency AI inference service built on Akash Network.Explore PlaygroundContact SalesWhy Choose AkashML?Decentralized, high-performance AI inference — faster, cheaper, and more transparent than the cloud.Low LatencyAkash's global infrastructure means your request spends the least amount of time getting to the model.Provider X 🇺🇸Provider Y 🇩🇪Global ScaleDeploy anywhere, scale everywhere. With access to GPUs across 80+ global datacenters, you get consistent low-latency performance at global scale. version 1.2.3Open Model LifecycleAkashML provides visibility into updates, versions, and deprecations. Upgrades occur on your schedule, not the provider's. Stay in control of your AI stack.Migrating ...Seamless MigrationMigrate in minutes with drop-in API compatibility. No vendor lock-in, no rewrites, just flexibility. Switch with confidence today.SlackHey! When's the next model upgrade dropping?Next week 🚀Beta soonMore GPUsSneak PeekReal Engineers, Real Time.Get direct support from engineers who build and maintain the platform. Connect instantly via Slack, no bots or tickets. Get answers when you need them.Featured ModelsOur model library is constantly expanding, driven by input from users like you!View All ModelsLimited TrialQWEN3.8\n27BDense 27B vision-language model; understands images and video, tuned for coding, research, and long-horizon agentic tasks with 256K native context (extensible to 1M).View ModelLimited TrialGLM 5.3Flagship 753B MoE built for complex coding and long-horizon agentic work; holds tool use consistent across multi-step development workflows, with 1M native context.View ModelLimited TrialQWEN3.6\n35B A3BMultimodal MoE with 35B total/3B active params; optimized for agentic coding, frontend workflows, and thinking preservation with 256K native context (extensible to 1M).View ModelLimited TrialKimi K3Native multimodal agentic MoE model with 2.8T parameters (104B activated), built on Kimi Delta Attention. Excels at long-horizon coding, agentic knowledge work, and reasoning.View ModelLimited TrialGPT\nOSS 120BOpen-weight MoE with 120B total/5.1B active params; built for reasoning, agentic tool use, and code execution, with configurable reasoning effort and 128K context.View Model6M+ RunsLlama 3.3\n70BInstruct-tuned for high-quality conversation and strong general performance across tasks.View ModelView All ModelsModel PricingPay only for what you use, scale up or down instantly, and keep full control of your AI costs.Price (per 1M Tokens)QWEN3.8 27BInput$0.225Output$1.98Cache Read$0.05QWEN3.6 35B A3BInput$0.10Output$0.90Cache Read$0.05Llama 3.3 70BInput$0.20Output$0.52Cache Read$0.10Kimi K3Input$1.20Output$14.00Cache Read$1.20GPT OSS 120BInput$0.037Output$0.187Cache Read$0.037GPT OSS 20BInput$0.02Output$0.10Cache Read—GLM 5.3Input$0.19Output$4.40Cache Read$0.19Pricing subject to change. Rates accurate to active AkashML billing protocols.Price (per 1M Tokens)ModelInputOutputCache ReadQWEN3.8 27B$0.225$1.98$0.05QWEN3.6 35B A3B$0.10$0.90$0.05Llama 3.3 70B$0.20$0.52$0.10Kimi K3$1.20$14.00$1.20GPT OSS 120B$0.037$0.187$0.037GPT OSS 20B$0.02$0.10—GLM 5.3$0.19$4.40$0.19Pricing subject to change. Rates accurate to active AkashML billing protocols.Getting started is easy!In just 3 simple steps, you can start running inference on akashML:Sign upCreate your free account in under 2 minutes and get instant access to the akashML platform.Set up your workflowChoose from our library of models, and deploy with a single click or API call.Run inferenceStart sending requests immediately via API or Playground. Scale on demand and only pay for what you use.Explore PlaygroundFrequently asked questionsWe've compiled the most important information to help you get the most out of your experience. For detailed guides and API references, visit our docs. Can't find what you're looking for? Contact us.GeneralBillingAI Inference ServiceBuilt on Akash NetworkPrivacy PolicyTerms of ServiceCopyright 2026 © akashml.comCopyright 2026 © akashml.comAI Inference ServiceBuilt on Akash NetworkPrivacy PolicyTerms of ServiceWe value your privacyWe use essential cookies for authentication and optional analytics cookies to improve our service.Privacy PolicyTerms of Service","tokens":1091,"squid":"spider-03","role":"Compute Spider","at":1791340610993,"hash":"d9825de693c8dccdb75f7d3a84a6242581467663"}
{"url":"https://www.paradigm.xyz/writing/solidus","domain":"paradigm.xyz","title":"Formally Verifying a Compiler Using Automated Research","text":"Formally Verifying a Compiler Using Automated Research Agents can do extraordinary things through automated research loops. Communities of automated researchers can achieve even more through competitions, like the ones we host on Paradigm Puzzles. But how do we know that what they produce is correct?Formal verification with languages like Lean turns out to be beautifully complementary to automated research. It can prove that an agent’s output correctly solved a presented problem, or that an optimized program preserves properties of an unoptimized one. While these proofs are incredibly tedious to construct, the solution is the same as the problem: automated research. You can automate the creation of Lean proofs using AI, thanks to increasingly capable models like GPT-5.6 and Claude Fable 5 and specialized tools like Aristotle. And they allow collaboration by untrusted contributors, since contributions can be proven correct.We’re introducing Solidus: a collaborative automated research project to build a formally verified Solidity compiler in Lean. We are kicking off this project with two new optimization puzzles: one to pin down a frozen source semantics of the Solidity language, and the other to optimize the already-proven backend of the compiler (while preserving the proof).The Solidus project already includes a full formally verified backend that compiles from Yul (the intermediate representation used by the Solidity compiler) to EVM, as well as a new proposed formal semantics for Solidity. We plan to use automated research to finalize the Solidity semantics, build the frontend of the compiler, and optimize the implementation to make it not only the most secure Solidity compiler, but also the most efficient.Solidus has already been a major automated research undertaking. It took over 1,700 hours (~10 weeks) of total Codex /goal time, with extra-high effort, in fast mode (~$150,000 at API rates). But we think that is nothing compared to the improvements that could come from opening it up to public contribution.This is a pre-alpha project. The code has not been audited and is not production-ready. And it will likely be possible for submissions to take advantage of subtle gaps in the formal verification to game the score or introduce undetected problems. But we hope that these challenges can pressure-test some of those gaps, and help pave the way for even more ambitious projects in the future.Why Formally Verify a Compiler?Compilers are an essential part of the modern computing toolchain, but they are complex and open-ended pieces of software that are very difficult to test exhaustively. Formal verification of compilers protects against compiler bugs, like the one that led to a $50+ million smart contract hack in July 2023. It also makes formal verification of individual programs easier, since it lets developers prove statements about a high-level structured language, rather than low-level bytecode.But perhaps most importantly, it allows us to fully set automated research loose on improving trusted codebases like compilers. It can enable more collaboration on secure codebases, since contributions can come with a certificate that they satisfy the properties required. It also allows extremely aggressive, trustless optimization of the compiler. Lean-based projects can potentially be automatically optimized much more aggressively than normal projects.What Is Solidus?Solidus is a planned compiler from Solidity (the most popular smart contract language) to the EVM, implemented in Lean.Lean is a language and proof assistant for formal verification. While it is best known for its application to math, it is also a powerful and increasingly popular language for formal verification of computer programs. We implemented our compiler itself in Lean, to make it even more amenable to formal verification.Solidity is the most popular smart contract language, and the EVM (Ethereum Virtual Machine) is the most popular blockchain virtual machine (used by chains like Ethereum, Tempo, and Monad).The backend of Solidus (a compiler from Solidity’s intermediate representation, Yul, to the EVM) is built and formally verified. We use a slightly modified fork of the Yul and EVM semantics created by Nethermind, and prove that every program produced by our compiler has identical outputs for all inputs as the Yul program given to it (other than EVM-specific details like gas and memory layout). Our semantics only model the state of the individual contract being compiled, but the compiler fully supports external calls—the proof is parametric over all possible external worlds, as long as they are deterministic. (This backend is similar to the yul-compiler project released recently by the Powdr team.)The frontend for the compiler (from Solidity to Yul) is not yet built, in part because no formal semantics for Solidity exists. To begin to rectify that, we built a formal semantics for Solidity to act as a source language for the compiler. This semantics likely still has some gaps, and one of the goals of the Solidus challenges is to find those gaps and harden it.How We Built SolidusSolidus was only possible because LLMs are now strong enough to take on extremely heavy research and engineering projects. The star contributor was GPT-5.6 and Codex, but we also made significant use of Harmonic’s Aristotle for some of the most complex proofs, and used Claude Fable 5 for some of the final steps.No human read or wrote a single line of code for Solidus, but it was still nowhere close to a fully automated effort. We don’t think agents are good enough yet to solve this kind of task with a single /goal loop, although we suspect they will be good enough soon—probably by the end of the year.One reason is that the spec for the compiler had to evolve as part of the proving process; until we were deep into the proving process, it wasn’t clear exactly what statement we could or would be proving about the compiler. This required some human judgment about which spec edits were acceptable, and which would violate the spirit of the compiler. Outsourcing such judgment to agents tends to result in drift or reward-hacking.Another reason is that some human creativity was required for some of the higher-level architecture of the proof. For example, agents burned days attempting to prove that the source and target programs would be equivalent in all possible states that a concrete external world could have, before we suggested pivoting to prove the claim (much stronger, but ironically, easier to prove) that they would be equivalent regardless of how the external world worked, as long as the same external call by each program returned the same result.We’ve open-sourced the Codex skill we used to build the compiler backend.The Solidus ChallengesWe think that challenges are an ideal way to organize collective autoresearch projects like these. We created two challenges to start:Spec Hunt: One tricky problem in formal verification is ensuring that the proven spec for the problem actually matches the desired behavior. Solidity is a complex language, with no formal specification other than the solc compiler.We wrote solidity-lean as an attempted formal semantics of Solidity 0.8.35, but we expect there are still many undetected divergences in it. This challenge allows users to score points by finding these divergences and submitting a proof-of-concept for them. These divergences are automatically tested using Foundry, and then reviewed by an AI agent, which fixes it by merging a change to the solidity-lean repo (or escalating to human review if needed).Compiler Optimization: Another problem with formally verified codebases produced by agents is that, by default, they might be less efficient than ordinary codebases. On our test suite, our Yul-to-EVM compiler currently produces programs with almost 3x as much bytecode as solc. But automated research excels at optimization, particularly when correctness is verifiable.We created a challenge to optimize the Yul-to-EVM backend of the Solidus compiler. Submissions have to improve on the performance of the existing compiler, while proving the same theorem about its correctness. (Note that the current compiler only guarantees soundness; completeness and performance are currently verified heuristically with a holdout test suite.)We hope these challenges will help advance the Solidus project, and also serve as a prototype for other productive automated research projects in the future!","tokens":2128,"squid":"spider-04","role":"Research Spider","at":1791340626769,"hash":"b0d21ca84f22830a0cb02583c2129e3296188a8b"}
{"url":"https://eips.ethereum.org/EIPS/eip-223","domain":"eips.ethereum.org","title":"ERC-223: Token with transaction handling model","text":"🎉 Final\n\n Standards Track: ERC\n\n ERC-223: Token with transaction handling model\n\n Token with transaction handling model designed to behave identical to native currency (ether)\n\n Authors\n Dexaran (@Dexaran) <dexaran@ethereumclassic.org>\n\n Created\n 2017-05-03\n\n Abstract\n\nThe following describes an interface and logic for fungible tokens that supports a tokenReceived callback to notify contract recipients when tokens are received. This makes tokens behave identical to ether.\n\n Motivation\n\nThis token introduces a communication model for contracts that can be utilized to straighten the behavior of contracts that interact with such tokens. Specifically, this proposal:\n\n Informs receiving contracts of incoming token transfers, as opposed to ERC-20 where the recipient of a token transfer gets no notification.\n Is more gas-efficient when depositing tokens to contracts.\n Allows for _data recording for financial transfers.\n\n Specification\n\nContracts intending to receive these tokens MUST implement tokenReceived.\n\nToken transfers to contracts not implementing tokenReceived as described below MUST revert.\n\n Token contract\n\n Token Methods\n\n totalSupply\n\nfunction totalSupply() view returns (uint256)\n\nReturns the total supply of the token. The functionality of this method is identical to that of ERC-20.\n\n name\n\nfunction name() view returns (string memory)\n\nReturns the name of the token. The functionality of this method is identical to that of ERC-20.\n\nOPTIONAL - This method can be used to improve usability, but interfaces and other contracts MUST NOT expect these values to be present.\n\n symbol\n\nfunction symbol() view returns (string memory)\n\nReturns the symbol of the token. The functionality of this method is identical to that of ERC-20.\n\nOPTIONAL - This method can be used to improve usability, but interfaces and other contracts MUST NOT expect these values to be present.\n\n decimals\n\nfunction decimals() view returns (uint8)\n\nReturns the number of decimals of the token. The functionality of this method is identical to that of ERC-20.\n\nOPTIONAL - This method can be used to improve usability, but interfaces and other contracts MUST NOT expect these values to be present.\n\n balanceOf\n\nfunction balanceOf(address _owner) view returns (uint256)\n\nReturns the account balance of another account with address _owner. The functionality of this method is identical to that of ERC-20.\n\n transfer(address, uint)\n\nfunction transfer(address _to, uint _value) returns (bool)\n\nThis function must transfer tokens, and if _to is a contract, it must call the tokenReceived(address, uint256, bytes calldata) function of _to. If the tokenReceived function is not implemented in _to (recipient contract), then the transaction must fail and the transfer of tokens must be reverted.\nIf _to is an externally owned address, then the transaction must be sent without executing tokenReceived in _to.\n _data can be attached to this token transaction, but it requires more gas. _data can be empty.\n\nThe tokenReceived function of _to MUST be called after all other operations to avoid re-entrancy attacks.\n\nNOTE: If transfer function is payable and ether was deposited then the amount of deposited ether MUST be delivered to _to address alongside tokens. If ether was sent alongside tokens in this way then ether MUST be delivered first, then token balances must be updated, then tokenReceived function MUST be called in _to if it is a contract.\n\n transfer(address, uint, bytes)\n\nfunction transfer(address _to, uint _value, bytes calldata _data) returns (bool)\n\nThis function must transfer tokens and invoke the function tokenReceived (address, uint256, bytes) in _to, if _to is a contract. If the tokenReceived function is not implemented in _to (recipient contract), then the transaction must fail and the transfer of tokens must not occur. \nIf _to is an externally owned address (determined by the code size being zero), then the transaction must be sent without executing tokenReceived in _to.\n _data can be attached to this token transaction, but it requires more gas. _data can be empty.\n\nNOTE: A possible way to check whether the _to is a contract or an address is to assemble the code of _to. If there is no code in _to, then this is an externally owned address, otherwise it’s a contract. If transfer function is payable and ether was deposited then the amount of deposited ether MUST be delivered to _to address alongside tokens.\n\nThe tokenReceived function of _to MUST be called after all other operations to avoid re-entrancy attacks.\n\n Events\n\n Transfer\n\nevent Transfer(address indexed _from, address indexed _to, uint256 _value, bytes _data)\n\nTriggered when tokens are transferred. Compatible with and similar to the ERC-20 Transfer event.\n\n ERC-223 Token Receiver\n\n Receiver Methods\n\nfunction tokenReceived(address _from, uint _value, bytes calldata _data) returns (bytes4)\n\nA function for handling token transfers, which is called from the token contract, when a token holder sends tokens. _from is the address of the sender of the token, _value is the amount of incoming tokens, and _data is attached data similar to msg.data of ether transactions. It works by analogy with the fallback function of Ether transactions and returns nothing.\n\nNOTE: msg.sender will be a token-contract inside the tokenReceived function. It may be important to filter which tokens were sent (by token-contract address). The token sender (the person who initiated the token transaction) will be _from inside the tokenReceived function. The tokenReceived function must return 0x8943ec02 after handling an incoming token transfer. The tokenReceived function call can be handled by the fallback function of the recipient contact (and in this case it may not return the magic value 0x8943ec02).\n\nIMPORTANT: This function must be named tokenReceived and take parameters address, uint256, bytes to match the function signature 0x8943ec02. This function can be manually called by a EOA.\n\n Rationale\n\nThis standard introduces a communication model by enforcing the transfer to execute a handler function in the destination address. This is an important security consideration as it is required that the receiver explicitly implements the token handling function. In cases where the receiver does not implements such function the transfer MUST be reverted.\n\nThis standard sticks to the push transaction model where the transfer of assets is initiated on the senders side and handled on the receivers side. As the result, ERC-223 transfers are more gas-efficient while dealing with depositing to contracts as ERC-223 tokens can be deposited with just one transaction while ERC-20 tokens require at least two calls (one for approve and the second that will invoke transferFrom).\n\n ERC-20 deposit: approve ~46 gas, transferFrom ~75K gas\n\n ERC-223 deposit: transfer and handling on the receivers side ~54K gas\n\nThis standard introduces the ability to correct user errors by allowing to handle ANY transactions on the recipients side and reject incorrect or improper transfers. This tokens utilize ONE transferring method for both types of interactions with contracts and externally owned addresses which can simplify the user experience and allow to avoid possible user mistakes.\n\nOne downside of the commonly used ERC-20 standard that ERC-223 is intended to solve is that ERC-20 implements two methods of token transferring: (1) transfer function and (2) approve + transferFrom pattern. Transfer function of ERC-20 standard does not notify the receiver and therefore if any tokens are sent to a contract with the transfer function then the receiver will not recognize this transfer and the tokens can become stuck in the receivers address without any possibility of recovering them. ERC-20 standard places the burden of determining the transferring method on the user and if the incorrect method is chosen the user can lose the transferred tokens. ERC-223 automatically determines the transferring method, preventing the user from losing tokens due to choosing wrong method.\n\nERC-223 is intended to simplify the interaction with contracts that are intended to work with tokens. ERC-223 utilizes a “deposit” pattern, similar to that of plain Ether. An ERC-223 deposit to a contract is a simple call of the transfer function. This is one transaction as opposed to two step process of approve + transferFrom depositing.\n\nThis standard allows payloads to be attached to transactions using the bytes calldata _data parameter, which can encode a second function call in the destination address, similar to how msg.data does in an ether transaction, or allow for public logging on chain should it be necessary for financial transactions.\n\n Backwards Compatibility\n\nThe interface of this token is similar to that of ERC-20 and most functions serve the same purpose as their analogues in ERC-20. \ntransfer(address, uint256, bytes calldata) function is not backwards compatible with ERC-20 interface.\n\nERC-20 tokens can be delivered to a non-contract address with transfer function. ERC-20 tokens can be deposited to a contract address with approve + transferFrom pattern. Depositing ERC-20 tokens to the contract address with transfer function will always result in token deposit not being recognized by the recipient contract.\n\nHere is an example of the contract code that handles ERC-20 token deposit. The following contract can accepts tokenA deposits. It is impossible to prevent deposits of non-tokenA to this contract. If tokenA is deposited with transfer function then it will result in a loss of tokens for the depositor because the balance of the user will be decreased in the contract of tokenA but the value of deposits variable in the ERC20Receiver will not be increased i.e. the deposit will not be credited. As of 5/9/2023 $201M worth of 50 examined ERC-20 tokens are already lost in this way on Ethereum mainnet.\n\ncontract ERC20Receiver\n{\n address tokenA;\n mapping (address => uint256) deposits;\n function deposit(uint _value, address _token) public\n {\n require(_token == tokenA);\n IERC20(_token).transferFrom(msg.sender, address(this), _value);\n deposits[msg.sender] += _value;\n }\n}\n\nERC-223 tokens must be delivered to non-contract address or contract address in the same way with transfer function.\n\nHere is an example of the contract code that handles ERC-223 token deposit. The following contract can filter tokens and only accepts tokenA. Other ERC-223 tokens would be rejected.\n\ncontract ERC223Receiver\n{\n address tokenA;\n mapping (address => uint256) deposits;\n function tokenReceived(address _from, uint _value, bytes memory _data) public returns (bytes4)\n {\n require(msg.sender == tokenA);\n deposits[_from] += _value;\n return 0x8943ec02;\n }\n}\n\n Security Considerations\n\nThis token utilizes the model similar to plain ether behavior. Therefore replay issues must be taken into account.\n\n Reference Implementation\n\npragma solidity ^0.8.19;\n\nlibrary Address {\n /**\n * @dev Returns true if `account` is a contract.\n *\n * This test is non-exhaustive, and there may be false-negatives: during the\n * execution of a contract's constructor, its address will be reported as\n * not containing a contract.\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 function isContract(address account) internal view returns (bool) {\n // This method relies in extcodesize, which returns 0 for contracts in\n // construction, since the code is only stored at the end of the\n // constructor execution.\n\n uint256 size;\n // solhint-disable-next-line no-inline-assembly\n assembly { size := extcodesize(account) }\n return size > 0;\n }\n}\n\nabstract contract IERC223Recipient {\n/**\n * @dev Standard ERC-223 receiving function that will handle incoming token transfers.\n *\n * @param _from Token sender address.\n * @param _value Amount of tokens.\n * @param _data Transaction metadata.\n */\n function tokenReceived(address _from, uint _value, bytes memory _data) public virtual returns (bytes4);\n}\n\n/**\n * @title Reference implementation of the ERC223 standard token.\n */\ncontract ERC223Token {\n\n /**\n * @dev Event that is fired on successful transfer.\n */\n event Transfer(address indexed from, address indexed to, uint value, bytes data);\n\n string private _name;\n string private _symbol;\n uint8 private _decimals;\n uint256 private _totalSupply;\n\n mapping(address => uint256) private balances; // List of user balances.\n\n /**\n * @dev Sets the values for {name} and {symbol}, initializes {decimals} with\n * a default value of 18.\n *\n * To select a different value for {decimals}, use {_setupDecimals}.\n *\n * All three of these values are immutable: they can only be set once during\n * construction.\n */\n\n constructor(string memory new_name, string memory new_symbol, uint8 new_decimals)\n {\n _name = new_name;\n _symbol = new_symbol;\n _decimals = new_decimals;\n }\n\n /**\n * @dev Returns the name of the token.\n */\n function name() public view returns (string memory)\n {\n return _name;\n }\n\n /**\n * @dev Returns the symbol of the token, usually a shorter version of the\n * name.\n */\n function symbol() public view returns (string memory)\n {\n return _symbol;\n }\n\n /**\n * @dev Returns the number of decimals used to get its user representation.\n * For example, if `decimals` equals `2`, a balance of `505` tokens should\n * be displayed to a user as `5,05` (`505 / 10 ** 2`).\n *\n * Tokens usually opt for a value of 18, imitating the relationship between\n * Ether and Wei. This is the value {ERC223} uses, unless {_setupDecimals} is\n * called.\n *\n * NOTE: This information is only used for _display_ purposes: it in\n * no way affects any of the arithmetic of the contract, including\n * {IERC223-balanceOf} and {IERC223-transfer}.\n */\n function decimals() public view returns (uint8)\n {\n return _decimals;\n }\n\n /**\n * @dev See {IERC223-totalSupply}.\n */\n function totalSupply() public view returns (uint256)\n {\n return _totalSupply;\n }\n\n /**\n * @dev See {IERC223-standard}.\n */\n function standard() public view returns (string memory)\n {\n return \"223\";\n }\n\n /**\n * @dev Returns balance of the `_owner`.\n *\n * @param _owner The address whose balance will be returned.\n * @return balance Balance of the `_owner`.\n */\n function balanceOf(address _owner) public view returns (uint256)\n {\n return balances[_owner];\n }\n\n /**\n * @dev Transfer the specified amount of tokens to the specified address.\n * Invokes the `tokenFallback` function if the recipient is a contract.\n * The token transfer fails if the recipient is a contract\n * but does not implement the `tokenFallback` function\n * or the fallback function to receive funds.\n *\n * @param _to Receiver address.\n * @param _value Amount of tokens that will be transferred.\n * @param _data Transaction metadata.\n */\n function transfer(address _to, uint _value, bytes calldata _data) public returns (bool success)\n {\n // Standard function transfer similar to ERC20 transfer with no _data .\n // Added due to backwards compatibility reasons .\n balances[msg.sender] = balances[msg.sender] - _value;\n balances[_to] = balances[_to] + _value;\n if(Address.isContract(_to)) {\n IERC223Recipient(_to).tokenReceived(msg.sender, _value, _data);\n }\n emit Transfer(msg.sender, _to, _value, _data);\n return true;\n }\n\n /**\n * @dev Transfer the specified amount of tokens to the specified address.\n * This function works the same with the previous one\n * but doesn't contain `_data` param.\n * Added due to backwards compatibility reasons.\n *\n * @param _to Receiver address.\n * @param _value Amount of tokens that will be transferred.\n */\n function transfer(address _to, uint _value) public returns (bool success)\n {\n bytes memory _empty = hex\"00000000\";\n balances[msg.sender] = balances[msg.sender] - _value;\n balances[_to] = balances[_to] + _value;\n if(Address.isContract(_to)) {\n IERC223Recipient(_to).tokenReceived(msg.sender, _value, _empty);\n }\n emit Transfer(msg.sender, _to, _value, _empty);\n return true;\n }\n}\n\n Copyright\n\nCopyright and related rights waived via CC0.\n\n Citation\n Please cite this document as:\n\n Dexaran (@Dexaran) <dexaran@ethereumclassic.org>, \"ERC-223: Token with transaction handling model,\" Ethereum Improvement Proposals, no. 223, May 2017. Available: https://eips.ethereum.org/EIPS/eip-223.","tokens":4074,"squid":"spider-05","role":"Spec Spider","at":1791340644534,"hash":"4763f22671cbced3e747992f8689c9084dac51b5"}
{"url":"https://www.paradigm.xyz/puzzles","domain":"paradigm.xyz","title":"Puzzles | Paradigm","text":"Compete in simulated environments. Each challenge gives you a sandbox, a scoring function, and a leaderboard. Ship a strategy or solution, see how it ranks, and iterate.14 challenges live2843 players43996 submissionsFeaturedRSI Simulatorsimulation281 players · 770 runsReach AGI as early as possible in the Recursive Self-Improvement simulator.PacemultiplayerPace is a multiplayer game about AI race dynamics, by Paradigm.TradingSimple AMMsolidity720 players · 6454 runsDesign a fee strategy for an AMM in Solidity. Compete against other strategies in a realistic EVM-based simulation.Prop AMMrust175 players · 2143 runsControl the entire swap function, not just fees. Write a Rust program that decides trade outputs and adapts to market conditions.Prediction Marketpython180 players · 1873 runsWrite a Python market-making strategy for a binary prediction market. Manage limit orders to maximize edge against informed and retail flow.LanguagePersuasiontext453 players · 14106 runsWrite a 140-character description of a pen to maximize how much AI personalities would pay for it. Score = median price across 15 diverse buyers.Negotiationtext186 players · 3524 runsWrite a strategy prompt for an AI agent that negotiates resource splits against a baseline across 10 games.SystemsAnthropic Take-Home Challengepython649 players · 11550 runsHand-optimize a kernel for a simulated VLIW machine — Anthropic’s original performance take-home. Chase the lowest cycle count.GamingDogfightonnx32 players · 821 runsProgram an AI pilot to outmaneuver opponents in aerial combat. Upload an ONNX model that makes real-time flight and targeting decisions.Chessonnx3 players · 23 runsTrain a neural network to evaluate chess positions. Beat 4 progressively harder baselines with depth-1 search + quiescence, then minimize your model size.MathQuantum Error Correctionpython23 players · 973 runsBuild a decoder that corrects quantum errors better than MWPM. Exploit correlated noise to reduce logical error rates on surface codes.Shape Packingjson43 players · 289 runsPack 15 unit semicircles into the smallest enclosing circle. Minimize the radius of the bounding circle.Formally Verified CompilerSpec Huntsolidity21 players · 983 runsFind a program where a formal Solidity semantics — written in Lean — disagrees with the real solc + EVM. Every accepted divergence is a concrete bug in the formal model.Formally Verified CompilerleanBeat a formally verified Yul → EVM compiler on total gas — while its machine-checked correctness theorem still proves.CryptographyKryptos K4cipherThe final unsolved passage of Jim Sanborn’s Kryptos sculpture at CIA headquarters — 97 characters, unsolved for 35 years.Paradigm Kryptos CTFctfTen cryptography puzzles of increasing difficulty, with $10,000 across ten prize pools.","tokens":698,"squid":"spider-04","role":"Research Spider","at":1791340661426,"hash":"0de4dfdd24a6951b1a95af930c15f1dcf9d7fea5"}
{"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":"spider-05","role":"Spec Spider","at":1791340678205,"hash":"df49501c0ad8b0cafbc8045715c3874d89475761"}
{"url":"https://akash.network/blog/5-new-exciting-ai-apps-built-on-akash-in-2026","domain":"akash.network","title":"5 New Exciting AI Apps Built on Akash in 2026","text":"TL;DR: Five community-built AI applications on Akash in 2026: Akash Agents (1-click agent deployment), HandFlow (gesture-controlled smart glasses), ElderShield (autonomous elder scam protection for ~$3/month), BioVault Agent (24/7 clinical safety monitoring), and Dramaalert (autonomous prediction market trading bot).\n\nBy Michelle Javed\nAkash Agents: Simplified AI Agent Deployment\nAkash Agents is a community-built tool by Sandeep Narahari that gives developers a web-based interface for deploying AI agent frameworks on Akash without touching a terminal, writing YAML, or managing cloud infrastructure.\nThe core problem it solves: deploying AI agents today typically means navigating GPU provisioning, cloud setup, and opaque pricing before you even get to write agent logic, and Akash Agents strips away most of that friction.\nUsers select a supported framework like Hermes by Nous Research or OpenClaw, plug in their API keys, and get a running agent instance on Akash compute without the usual infrastructure overhead.\nHermes in particular ships with over 40 built-in tools, persistent memory, and subagent parallelization out of the box, so developers can focus on their agent’s logic and capabilities rather than deployment plumbing. The tool is live and free to try at agents.akash.network.\nHandFlow: AI-Powered Smart Glasses\nHandFlow is a project by Akash Student Ambassadors Kien Nguyen and Andy Huynh, two UMass Amherst CS students who won Best First Hack at YHack 2026 at Yale.\nThe idea is a low-cost camera mounted on regular glasses that turns your hands and nearby surfaces into input devices for your computer. Using computer vision and a custom gesture detection model, HandFlow can recognize hand movements and map them to keyboard shortcuts, macros, and automated tasks, essentially turning any pair of glasses into a productivity tool without the price tag of commercial smart glasses. Features include gesture control, a paper-based 24-button controller, knuckle hotkeys, a virtual touchscreen, and pinch-to-capture with Gemini integration.\n\nThey used Akash to train their custom TCN (Temporal Convolutional Network) model on GPU during the hackathon, running parallel training deployments through a custom agent called AkashTrainer that automated the entire pipeline: push training scripts to GitHub, spin up deployments on Akash, train, push results back, and close the deployment automatically. The full training run took about an hour on Akash, which they said was significantly faster than training locally and far cheaper and easier to set up than AWS or Google Colab. In a 24-hour hackathon where every minute counts, that speed and simplicity let them focus on building rather than fighting infrastructure.\n\nElderShield: Autonomous Scam Protection for Older Adults\nElderShield is an autonomous AI agent that monitors a family’s inbox, opens every suspicious link in a real remote browser, and classifies scam risk before a human ever has to click. It won Best Use of Akash at the Ship to Prod Agentic Engineering Hackathon, and the project was motivated by a personal story: the developer’s grandmother lost $14,000 to a fake Medicare call that used a website convincing enough to fool someone who was sharp and careful.\nThat tracks with the broader numbers, as the FBI reported $3.4 billion in elder fraud losses in 2023 alone, with older adults targeted three times more often than younger people.\nThe system connects to a Slack workspace and sweeps for new messages every 15 seconds via Nexla. When it finds a URL, it opens it in an actual remote browser through TinyFish, not just a URL parser, so it sees exactly what the recipient would see.\nA memory-augmented classifier powered by Redis Agent Memory then scores the link as safe, suspicious, or scam, drawing on both per-session working memory and long-term semantic memory across all monitored households. That memory layer is what makes it meaningfully better than a simple heuristic, because it can recall that a domain appeared in a scam attempt last week or that a specific household has been targeted by fake bank logins before, and that context is often the difference between flagging something as suspicious versus catching it as a confirmed scam.\nThe whole pipeline, including the API, Redis, browser analysis, database, and live dashboard, runs in a single Akash deployment for under $3 a month. The developer specifically called out that this cost structure matters for the use case, since the people who need this kind of protection most are often in households that can’t afford enterprise security software, and decentralized infrastructure means there’s no cloud vendor lock-in or centralized dependency holding patient or family data.\nView the full project details and GitHub repo.\nBioVault Agent: Autonomous Clinical Safety Monitoring\nBioVault Agent is an autonomous AI watchdog built by a developer whose father passed away from a chemotherapy treatment error in Bangladesh, not from his cancer. The project won first place on the Akash Track at the Open Agents Hackathon and addresses a problem that kills more people globally than most realize: clinical treatment errors buried under hospital bureaucracy.\nBioVault runs 24/7 without human intervention, polling for new clinical documents every 30 seconds and running them through a four-stage pipeline. MiniMax Vision extracts structured data from handwritten chemotherapy charts and prescription sheets, AkashML standardizes and enriches it with ICD-10 coding, a custom FHIR R4 builder converts it to the international healthcare data standard, and a safety validator checks for dose variances, unrecognized drug names, protocol deviations, and missing required fields.\nWhen it catches something critical, like a Daunorubicin dose drop of more than 10%, it raises a structured alert, logs the action with full observability, and fires a webhook to any external system listening.\nThe entire system, inference, storage, alerting, and live dashboard, runs in a single container deployed on Akash for several dollars a month. That cost matters because the target users are small clinics and hospitals in low and middle income countries that can’t afford enterprise medical software or trust centralized cloud infrastructure with patient data. The developer noted that Akash handled the deployment cleanly, the provider was stable, and the pricing makes this genuinely viable for the resource-constrained settings where treatment errors are most deadly.\n\nCheck out BioVault’s full project summary and GitHub repo.\nDramaalert: Autonomous Prediction Market Trading Bot\nDramaalert is a project by Akash Student Ambassadors Tharun Ekambaram and Nick Hardy from Indiana University, who took home wins at both the hackathon and research competition at the Penn Blockchain Conference 2026.\nDramaalert is an autonomous trading agent for Polymarket, the largest on-chain prediction market, that ingests over 20 real-time data sources including order flow, cross-platform pricing from Kalshi and Metaculus, Wikipedia edit velocity, Reddit sentiment, GDELT global news, and LLM-powered reasoning, then fuses them through a Bayesian inference engine and executes Kelly-sized positions without any human intervention.\nThe bot exploits three specific inefficiencies in prediction markets: information latency gaps where the same event is priced differently across platforms, pre-news signals from social and editorial sources that move faster than most traders, and Bayesian miscalibration where participants anchor too heavily on current market price and update too slowly.\nThe team used Akash to power their research competition entry, which involved downloading and analyzing a full year of Cronos blockchain data to build a comprehensive short thesis on $CRO that won first place.\nRather than trying to pull that volume of chain data on individual laptops, they created a de facto node of Akash deployments to pull the information in parallel, then combined it and sent the outputs to a single H100 machine on Akash where they did the actual analysis, running compute-intensive valuation methodologies and generating metrics that couldn’t be indexed on the fly. They described the shift as going from a “what can we fit” problem to a “what do we want to find” problem, and said the same workload would have taken multiple days on local machines. They also noted that compared to AWS and Azure, the pricing on Akash was significantly lower and the setup was far simpler, which mattered a lot when they were running on roughly three hours of sleep over two nights at Penn.\n\nWant to be featured in the next list?\nStay up to date with upcoming hackathons on our events page.\nIf you’re a university student, apply for the Akash Student Ambassador program and have your hackathon projects shared with over 127k followers on our X.\nFrequently Asked Questions\nWhat is Akash Agents?\nA community-built web interface by Sandeep Narahari for deploying AI agent frameworks (Hermes, OpenClaw) on Akash compute without terminals, YAML, or infrastructure management — live at agents.akash.network.\nWhat is HandFlow?\nA project by UMass Amherst students (YHack 2026 Best First Hack) that turns a $5 glasses-mounted camera into a gesture-controlled computer input device — trained on Akash GPUs during a 24-hour hackathon sprint.\nWhat is ElderShield?\nAn autonomous AI agent monitoring inboxes for scam URLs — opening every suspicious link in a real browser, classifying risk using Redis-backed memory, and alerting families. Runs on Akash for under $3/month.\nWhat is BioVault Agent?\nAn autonomous 24/7 clinical safety monitor that checks medical documents every 30 seconds for dose variances, unknown drug names, and protocol deviations — built for low-resource hospitals in developing countries where errors can be fatal.\nWhat is Dramaalert?\nAn autonomous trading bot for Polymarket prediction markets — ingesting 20+ real-time data sources, running Bayesian inference, and executing Kelly-sized positions without human intervention. Built by Indiana University student ambassadors.\nHow did HandFlow use Akash during a hackathon?\nThe team ran parallel GPU training deployments via AkashTrainer — an agent that pushed training scripts to GitHub, spun up Akash deployments, trained models, pushed results back, and closed deployments automatically. Full training took ~1 hour.\nWhere can I find these apps or build my own?\nVisit agents.akash.network for Akash Agents. Find upcoming hackathons at akash.network/community/events/. Student builders can apply at the Akash Student Ambassador program — winning projects get shared with 127K+ followers on X. \nFast, affordable inference for open models\n\nRun Llama, Qwen, GLM and more on Akash's open compute marketplace.\nDrop-in API compatibility means you can\n switch in minutes.\n\nTry AkashML\n(opens in a new tab) \nnote\n\ntip\n\nCaution\n\nDanger","tokens":2728,"squid":"spider-03","role":"Compute Spider","at":1791340679478,"hash":"789b59083050c2bfd32794e78c9051672649e12b"}
{"url":"https://forum.across.to/c/proposals/active-proposals/21","domain":"forum.across.to","title":"Latest Proposals/Active Proposals topics - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n Latest topics in Active Proposals\n\n Proposals\n\n Active 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 posted\n Mar 14\n\n by @Britt\n\n Pinned\n\n About the Active Proposals category\n\n posted\n Aug 20\n\n by @Kevin_UMA\n\n Reduce ACX emissions for WBTC LPs\n\n Author(s): ACX Emissions Committee (Kevin Chan, David Korpi, Ryan Carman, Dylan O’Reilly, Chase Coleman) \nStatus: Proposed \nRelated Discussions: Reduce ACX emissions for ACX LPs, WBTC LPs and wstETH/ACX LPs \nSummary\nThe …\n\n read more\n\n posted\n Apr 24\n\n by @TheRealTuna_Across\n\n Across UMA Voting Committee – Renewal Proposal\n\n Title: Across UMA Voting Committee – Renewal Proposal \nAuthor(s): EAsports, TheRealTuna, mydefi, neondaemon, underethsea \nStatus: Proposal \nRelated Discussions: \n\nDiscord: Discussion currently welcomed in Across Governan…\n\n read more\n\n TheRealTuna_Across\n replied\n\n May 18, 2025\n\n 6\n\n 6\n\n posted\n Feb 26\n\n by @mydefi\n\n Straddl.io Expansion Proposal\n\n Author(s): My Defi, GR (Cat Herder), Infinity \nStatus: Proposal \nSubmission Date: TBD \nSummary:\nStraddl (https://straddl.io) is a next-generation bridging platform built entirely on Across Protocol, designed to offer use…\n\n read more\n\n mydefi\n replied\n\n Mar 3, 2025\n\n 11\n\n 33\n\n posted\n Oct 16\n\n by @2chairs\n\n Support Superseed Bridge Routes\n\n Author: Superseed \nProposal Details \nProposal Overview \nThe Superseed core team proposes the integration of Across to Superseed. In collaboration with the Across core team, the Superseed team has been working to ensure t…\n\n read more\n\n PVMihalache\n replied\n\n Oct 17, 2024\n\n 1\n\n 2\n\n posted\n Jul 26\n\n by @biscaryn\n\n Support Redstone Bridge Routes\n\n Author: Biscaryn, Ecosystem @ Redstone \nProposal Details \nProposal Overview \nThe Redstone core team proposes the integration of Across to Redstone. In collaboration with the Across core team, the Redstone team has been w…\n\n read more\n\n 1\n\n posted\n Jul 15\n\n by @sherooberoo\n\n Support Scroll Bridge Routes\n\n Author: Shahryar, Partnerships Lead @ Scroll \nProposal Overview\nThe Scroll core team proposes the integration of Across to Scroll. In collaboration with the Across core team, the Scroll team has been working to ensure th…\n\n read more\n\n PVMihalache\n replied\n\n Jul 15, 2024\n\n 2\n\n 2\n\n posted\n May 21\n\n by @adam3001\n\n Support Mode chain bridge routes\n\n Point of Contact\nAdam: Head of Business Development \nDeez: Head of Growth \nProposal Details\nProposal Overview\nThe Mode core team proposes the integration of Across to Mode. In collaboration with the Across core team, the…\n\n read more\n\n adam3001\n replied\n\n May 27, 2024\n\n 4\n\n 15\n\n posted\n May 6\n\n by @bennidaytime\n\n Native USDC and CCTP Integration\n\n Native USDC and CCTP Integration\nTitle: Native USDC and CCTP Integration \nAuthor(s): RL \nStatus: Proposal \nSummary: \nTwo versions of USDC exist on many L2s that Across supports: a “bridged” version via a chains’ bridge a…\n\n read more\n\n Clayton_UMA\n replied\n\n May 6, 2024\n\n 4\n\n 5\n\n posted\n May 3\n\n by @Hadari\n\n Cryptohadari NFT Proposal\n\n posted\n Feb 13\n\n by @daostratconsensys\n\n Support Linea Chain Bridge Routes\n\n Point of Contact\nArthur Remy - Linea Core, Product Manager \nCam O’Donnell - @daostratconsensys - Linea Growth, Product Manager \nProposal Details\nProposal Overview\nThe Linea core team proposes the integration of Across to…\n\n read more\n\n daostratconsensys\n replied\n\n Feb 20, 2024\n\n 7\n\n 21\n\n posted\n Oct 31\n\n by @Methodic\n\n Velodrome Liquidity Program Extension\n\n Summary: \nAcross Protocol’s pilot program on Velodrome ended in October. This proposal aims to extend its initial program for 16 weeks in order to ensure sufficient liquidity for ACX on L2s. \nThe Velodrome team presented…\n\n read more\n\n alexander\n replied\n\n Jan 8, 2024\n\n 19\n\n 28\n\n posted\n Nov 17\n\n by @TheRealTuna_Across\n\n Community Integration Campaign 2.0\n\n Summary: \nThis proposal allocates 150,000 ACX as bounties, to community members who can bring value to Across by facilitating integrations between Across and crypto projects that share a similar vision. \nMotivation: \nAcr…\n\n read more\n\n PVMihalache\n replied\n\n Nov 21, 2023\n\n 5\n\n 9\n\n posted\n May 21\n\n by @Methodic\n\n Build liquidity for $ACX on Velodrome\n\n Related Discussions: \n\nSummary: \nCurrently, Across Protocol’s $ACX has little liquidity on Layer 2s, limiting the ability for users to acquire $ACX with low slippage and provide liquidity on L2s. This proposal aims to bo…\n\n read more\n\n alexander\n replied\n\n Jul 22, 2023\n\n treasury-funding\n\n 8\n\n 16\n\n posted\n Jun 13\n\n by @barbarossa_Arrakis\n\n ACX Market Making Proposal - Arrakis PALM\n\n Header\nTitle: ACX Market Making Proposal - Arrakis PALM \nAuthor(s): @barbarossa_Arrakis \nStatus: Proposal \nRelated Discussions: “Community Owned Liquidity” NFT Project Funding Request \nBody\nSummary: \nDeploy Arrakis PALM …\n\n read more\n\n caesarsherrod.eth\n replied\n\n Jun 27, 2023\n\n treasury-funding\n\n 3\n\n 7\n\n posted\n Mar 7\n\n by @TheRealTuna_Across\n\n “Community Owned Liquidity” NFT Project Funding Request\n\n Title: “Community Owned Liquidity” NFT project funding request \nAuthor: The Real Tuna \nContributors: Britt, Daywiss, EASports, TheRealTuna, Underthesea \nStatus: RFC \nRelated Discussions: N/A \nSubmission Date: 03/07/2023 \n…\n\n read more\n\n caesarsherrod.eth\n replied\n\n Jun 20, 2023\n\n treasury-funding\n\n 36\n\n 40\n\n posted\n Jan 2\n\n by @adalhi\n\n [RFC : Grant Request] Across Monthly Financial Reports\n\n Name : Asymmetric Defi \nProject : Across Monthly Financial Reporting \nDetailed Description of Project : \nProvide Monthly Reports about the State of the Across DAO. The reports would include : Overview of governance votes…\n\n read more\n\n roundmound\n replied\n\n Jun 2, 2023\n\n treasury-funding\n\n 6\n\n 9\n\n posted\n Mar 20\n\n by @Muskan\n\n Educational Awareness Campaign for Across Protocol in Southeast Asia\n\n Hello Community Members, \nI am Muskan Sadh from Finstreet India’s first Crypto and DeFi Education Platform. We are hereby sharing our plans below to aware our audiences about Across Protocol features and utilities. Feel …\n\n read more\n\n Muskan\n replied\n\n Mar 25, 2023\n\n 3\n\n 5","tokens":2997,"squid":"spider-09","role":"Bridge Spider","at":1791340818358,"hash":"a6ce09ed94f83868fd9c7b70f133ca9cd3b7d1dd"}
{"url":"https://docs.switchboard.xyz/ai-agents-llms/switchboard-agent-skill/switchboard-aptos-feeds","domain":"docs.switchboard.xyz","title":"Switchboard Aptos Feeds Skill | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.PurposeUse Switchboard on-demand feeds on Aptos:crank/update feeds client-side (pull model)consume verified results in Moveenforce freshness/deviation policies in app logicDependenciesUse exact pins from the SDK Version Matrix.@switchboard-xyz/aptos-sdk@0.1.5@switchboard-xyz/common@5.8.5@aptos-labs/ts-sdk@6.1.0PreconditionsOperatorPolicy exists (Aptos network, signer custody, RPC allowlist).Inputs to Collectnetwork (mainnet/testnet)RPC endpointcrossbarUrl (default: https://crossbar.switchboard.xyz)aggregator/feed identifiers (addresses/object IDs)safety policy (staleness/deviation/min responses) only if risk-sensitiveInvariantsPull-based: client must crank/update feeds to keep data fresh.Ensure update action is executed before reading within the same flow (where applicable).Playbook (high-level)Off-chain:fetch/update payload(s) for the feed/aggregatorsubmit transaction to run the update action (or include it in the same entry call if supported)On-chain:read current result + timestampenforce staleness and deviation vs last stored valueMinimal Exampleuse aptos_framework::aptos_coin::AptosCoin;\nuse aptos_framework::object::{Self, Object};\nuse switchboard::aggregator::{Self, Aggregator, CurrentResult};\nuse switchboard::update_action;\n\npublic entry fun read_feed(account: &signer, update_data: vector<vector<u8>>) {\n update_action::run<AptosCoin>(account, update_data);\n let feed: Object<Aggregator> = object::address_to_object<Aggregator>(@0xSomeFeedAddress);\n let current: CurrentResult = aggregator::current_result(feed);\n let _price = aggregator::result(&current);\n}OutputsProduce an AptosFeedIntegrationPlan including:identifiers and network alignment checkscrank strategy (if requested)Move consumption point and validation policy (if requested)Referenceshttps://docs.switchboard.xyz/docs-by-chain/aptoshttps://docs.switchboard.xyz/tooling/crossbarPreviousSwitchboard Sui Feeds SkillNextSwitchboard Iota Feeds SkillLast updated 2 months ago","tokens":513,"squid":"spider-08","role":"Oracle Spider","at":1791340820791,"hash":"818ab2fa73c5eb7f66e208dffc3f7c95eeb41122"}
{"url":"https://developer.arbitrum.io/build-decentralized-apps/quickstart-solidity-remix","domain":"developer.arbitrum.io","title":"Build a decentralized app with Solidity (Quickstart)","text":"Build a decentralized app with Solidity (Quickstart)Learn how to build and deploy your first Solidity smart contract on Arbitrum using Remix IDE. This beginner-friendly quickstart guides you from a JavaScript vending machine to a decentralized app deployed on Arbitrum One, covering smart contract basics, wallet setup, and testnet deployment.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 . 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.\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 Cupcakesweb2NameCupcake 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, , 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 Code is the IDE we'll use to build our vending machine. See code.visualstudio.com to install.\nWe will use Metamask as the to interact with our vending machine. See metamask.io and click View MetaMask Web or OKX Wallet and click Connect Wallet to install.\nYarn is the package manager we'll use to install dependencies. See yarnpkg.com to install.\nFoundry 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 data structure.\nThe data within Ethereum's blockchain data structure changes one transaction at a time.\n 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.\n is a child chain that implements the\n. 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:\nclass VendingMachine {\n // state variables = internal memory of the vending machine\n cupcakeBalances = {};\n cupcakeDistributionTimes = {};\n\n // Vend a cupcake to the caller\n giveCupcakeTo(userId) {\n if (this.cupcakeDistributionTimes[userId] === undefined) {\n this.cupcakeBalances[userId] = 0;\n this.cupcakeDistributionTimes[userId] = 0;\n }\n\n // Rule 1: The vending machine will distribute a cupcake to anyone who hasn't recently received one.\n const fiveSeconds = 5000;\n const userCanReceiveCupcake = this.cupcakeDistributionTimes[userId] + fiveSeconds <= Date.now();\n if (userCanReceiveCupcake) {\n this.cupcakeBalances[userId]++;\n this.cupcakeDistributionTimes[userId] = Date.now();\n console.log(`Enjoy your cupcake, ${userId}!`);\n return true;\n } else {\n console.error('HTTP 429: Too Many Cupcakes (you must wait at least 5 seconds between cupcakes)');\n return false;\n }\n }\n\n getCupcakeBalanceFor(userId) {\n return this.cupcakeBalances[userId];\n }\n}\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.<!DOCTYPE html>\n<html lang=\"en\">\n<head>\n <meta charset=\"UTF-8\" />\n <meta name=\"viewport\" content=\"width=device-width, initial-scale=1.0\" />\n <title>Cupcake Vending Machine - Arbitrum Quickstart</title>\n <script src=\"https://cdn.ethers.io/lib/ethers-5.7.umd.min.js\"></script>\n <style>\n *, *::before, *::after { box-sizing: border-box; margin: 0; padding: 0; }\n\n body {\n font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, sans-serif;\n background: #0d1117;\n color: #e6edf3;\n min-height: 100vh;\n display: flex;\n flex-direction: column;\n align-items: center;\n padding: 2rem 1rem;\n }\n\n h1 {\n font-size: 1.8rem;\n margin-bottom: 0.25rem;\n color: #58a6ff;\n }\n\n .subtitle {\n color: #8b949e;\n margin-bottom: 2rem;\n font-size: 0.95rem;\n }\n\n .machines {\n display: flex;\n gap: 2rem;\n flex-wrap: wrap;\n justify-content: center;\n width: 100%;\n max-width: 900px;\n }\n\n .vending-machine {\n background: #161b22;\n border: 1px solid #30363d;\n border-radius: 12px;\n padding: 1.5rem;\n width: 400px;\n display: flex;\n flex-direction: column;\n gap: 0.75rem;\n }\n\n .vending-machine h2 {\n font-size: 1.25rem;\n color: #e6edf3;\n }\n\n .vending-machine .badge {\n display: inline-block;\n font-size: 0.7rem;\n font-weight: 600;\n text-transform: uppercase;\n letter-spacing: 0.05em;\n padding: 0.2em 0.6em;\n border-radius: 4px;\n width: fit-content;\n }\n\n .badge-web2 { background: #238636; color: #fff; }\n .badge-web3 { background: #1f6feb; color: #fff; }\n\n label {\n font-size: 0.85rem;\n color: #8b949e;\n font-weight: 500;\n }\n\n input[type=\"text\"] {\n background: #0d1117;\n border: 1px solid #30363d;\n border-radius: 6px;\n padding: 0.6rem 0.75rem;\n color: #e6edf3;\n font-size: 0.9rem;\n outline: none;\n transition: border-color 0.2s;\n }\n\n input[type=\"text\"]:focus {\n border-color: #58a6ff;\n }\n\n input[type=\"text\"]::placeholder {\n color: #484f58;\n }\n\n .btn {\n padding: 0.6rem 1rem;\n border: none;\n border-radius: 6px;\n font-size: 0.9rem;\n font-weight: 600;\n cursor: pointer;\n transition: background 0.2s;\n }\n\n .btn-primary {\n background: #238636;\n color: #fff;\n }\n\n .btn-primary:hover { background: #2ea043; }\n\n .btn-secondary {\n background: transparent;\n color: #58a6ff;\n border: 1px solid #30363d;\n }\n\n .btn-secondary:hover { background: #161b22; border-color: #58a6ff; }\n\n .cupcake-display {\n font-size: 3rem;\n text-align: center;\n height: 4rem;\n line-height: 4rem;\n transition: opacity 0.3s;\n }\n\n .balance {\n display: flex;\n justify-content: space-between;\n align-items: center;\n background: #0d1117;\n border-radius: 6px;\n padding: 0.6rem 0.75rem;\n font-size: 0.9rem;\n }\n\n .balance-count {\n font-weight: 700;\n color: #58a6ff;\n font-size: 1.1rem;\n }\n\n .status {\n font-size: 0.8rem;\n min-height: 1.2rem;\n color: #f85149;\n text-align: center;\n }\n\n .status.success { color: #3fb950; }\n\n .hidden { display: none; }\n\n .actions {\n display: flex;\n gap: 0.5rem;\n }\n\n .actions .btn { flex: 1; }\n\n .description {\n font-size: 0.8rem;\n color: #8b949e;\n line-height: 1.4;\n border-left: 2px solid #30363d;\n padding-left: 0.75rem;\n }\n </style>\n</head>\n<body>\n\n <h1>Cupcake Vending Machine</h1>\n <p class=\"subtitle\">From the Arbitrum Solidity + Remix Quickstart</p>\n\n <div class=\"machines\">\n\n <!-- WEB2 Vending Machine -->\n <div class=\"vending-machine\">\n <span class=\"badge badge-web2\">Web2</span>\n <h2>Free Cupcakes</h2>\n <p class=\"description\">Pure JavaScript vending machine. Business logic runs in your browser — no blockchain involved.</p>\n\n <label for=\"web2-name\">Name</label>\n <input type=\"text\" id=\"web2-name\" placeholder=\"Enter name\" />\n\n <div class=\"actions\">\n <button class=\"btn btn-primary\" id=\"web2-vend\">Cupcake please!</button>\n <button class=\"btn btn-secondary\" id=\"web2-refresh\">Refresh balance</button>\n </div>\n\n <div class=\"cupcake-display\" id=\"web2-cupcake\"></div>\n\n <div class=\"balance\">\n <span>Cupcake balance for <strong id=\"web2-who\">—</strong>:</span>\n <span class=\"balance-count\" id=\"web2-balance\">0</span>\n </div>\n\n <div class=\"status\" id=\"web2-status\"></div>\n </div>\n\n<script>\n// ============================================================\n// VendingMachine.js — the JavaScript class from the quickstart\n// ============================================================\nclass VendingMachine {\n // state variables = internal memory of the vending machine\n cupcakeBalances = {};\n cupcakeDistributionTimes = {};\n\n // Vend a cupcake to the caller\n giveCupcakeTo(userId) {\n if (this.cupcakeDistributionTimes[userId] === undefined) {\n this.cupcakeBalances[userId] = 0;\n this.cupcakeDistributionTimes[userId] = 0;\n }\n\n // Rule 1: The vending machine will distribute a cupcake to anyone who hasn't recently received one.\n const fiveSeconds = 5000;\n const userCanReceiveCupcake = this.cupcakeDistributionTimes[userId] + fiveSeconds <= Date.now();\n if (userCanReceiveCupcake) {\n this.cupcakeBalances[userId]++;\n this.cupcakeDistributionTimes[userId] = Date.now();\n console.log(`Enjoy your cupcake, ${userId}!`);\n return true;\n } else {\n console.error(\n 'HTTP 429: Too Many Cupcakes (you must wait at least 5 seconds between cupcakes)',\n );\n return false;\n }\n }\n\n getCupcakeBalanceFor(userId) {\n return this.cupcakeBalances[userId] || 0;\n }\n}\n\n// ============================================================\n// VendingMachine.sol ABI (from the compiled Solidity contract)\n// ============================================================\nconst VENDING_MACHINE_ABI = [\n {\n inputs: [{ internalType: \"address\", name: \"userAddress\", type: \"address\" }],\n name: \"getCupcakeBalanceFor\",\n outputs: [{ internalType: \"uint256\", name: \"\", type: \"uint256\" }],\n stateMutability: \"view\",\n type: \"function\"\n },\n {\n inputs: [{ internalType: \"address\", name: \"userAddress\", type: \"address\" }],\n name: \"giveCupcakeTo\",\n outputs: [{ internalType: \"bool\", name: \"\", type: \"bool\" }],\n stateMutability: \"nonpayable\",\n type: \"function\"\n }\n];\n\n// ============================================================\n// Helper: flash a cupcake emoji with fade-out\n// ============================================================\nfunction flashCupcake(elementId) {\n const el = document.getElementById(elementId);\n el.textContent = '\\u{1F9C1}';\n el.style.opacity = 1;\n el.style.transition = 'none';\n requestAnimationFrame(() => {\n el.style.transition = 'opacity 4.5s ease-out';\n el.style.opacity = 0;\n });\n}\n\nfunction truncateAddress(text) {\n if (!text) return '—';\n if (text.length < 10) return text;\n return text.slice(0, 6) + '...' + text.slice(-4);\n}\n\n// ============================================================\n// WEB2 Vending Machine\n// ============================================================\n(function initWeb2() {\n const vm = new VendingMachine();\n\n const nameInput = document.getElementById('web2-name');\n const vendBtn = document.getElementById('web2-vend');\n const refreshBtn = document.getElementById('web2-refresh');\n const balanceEl = document.getElementById('web2-balance');\n const whoEl = document.getElementById('web2-who');\n const statusEl = document.getElementById('web2-status');\n\n function refreshBalance() {\n const name = nameInput.value.trim() || 'no name';\n const bal = vm.getCupcakeBalanceFor(name);\n balanceEl.textContent = bal;\n whoEl.textContent = truncateAddress(name);\n }\n\n vendBtn.addEventListener('click', () => {\n const name = nameInput.value.trim() || 'no name';\n const got = vm.giveCupcakeTo(name);\n if (got) {\n statusEl.textContent = `Enjoy your cupcake, ${name}!`;\n statusEl.className = 'status success';\n flashCupcake('web2-cupcake');\n refreshBalance();\n } else {\n statusEl.textContent = 'Too many cupcakes! Wait at least 5 seconds.';\n statusEl.className = 'status';\n }\n });\n\n refreshBtn.addEventListener('click', refreshBalance);\n})();\n\n</script>\n\n</body>\n</html>\n\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, , and .\n// SPDX-License-Identifier: MIT\n// Specify the Solidity compiler version - this contract requires version 0.8.9 or higher\npragma solidity ^0.8.9;\n\n// Define a smart contract named VendingMachine\n// Unlike regular classes, once deployed, this contract's code cannot be modified\n// This ensures that the vending machine's rules remain constant and trustworthy\ncontract VendingMachine {\n // State variables are permanently stored in blockchain storage\n // These mappings associate Ethereum addresses with unsigned integers\n // The 'private' keyword means these variables can only be accessed from within this contract\n mapping(address => uint) private _cupcakeBalances; // Tracks how many cupcakes each address owns\n mapping(address => uint) private _cupcakeDistributionTimes; // Tracks when each address last received a cupcake\n\n // Function to give a cupcake to a specified address\n // 'public' means this function can be called by anyone\n // 'returns (bool)' specifies that the function returns a boolean value\n function giveCupcakeTo(address userAddress) public returns (bool) {\n // Initialize first-time users\n // In Solidity, uninitialized values default to 0, so this check isn't strictly necessary\n // but is included to mirror the JavaScript implementation\n if (_cupcakeDistributionTimes[userAddress] == 0) {\n _cupcakeBalances[userAddress] = 0;\n _cupcakeDistributionTimes[userAddress] = 0;\n }\n\n // Calculate when the user is eligible for their next cupcake\n // 'seconds' is a built-in time unit in Solidity\n // 'block.timestamp' gives us the current time in seconds since Unix epoch\n uint fiveSecondsFromLastDistribution = _cupcakeDistributionTimes[userAddress] + 5 seconds;\n bool userCanReceiveCupcake = fiveSecondsFromLastDistribution <= block.timestamp;\n\n if (userCanReceiveCupcake) {\n // If enough time has passed, give them a cupcake and update their last distribution time\n _cupcakeBalances[userAddress]++;\n _cupcakeDistributionTimes[userAddress] = block.timestamp;\n return true;\n } else {\n // If not enough time has passed, revert the transaction with an error message\n // 'revert' cancels the transaction and returns the error message to the user\n revert(\"HTTP 429: Too Many Cupcakes (you must wait at least 5 seconds between cupcakes)\");\n }\n }\n\n // Function to check how many cupcakes an address owns\n // 'public' means anyone can call this function\n // 'view' means this function only reads data and doesn't modify state\n // This makes it free to call (no gas cost) when called externally\n function getCupcakeBalanceFor(address userAddress) public view returns (uint) {\n return _cupcakeBalances[userAddress];\n }\n}\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: remix.ethereum.org\n2. Create a blank workspace in Remix:\n\n3. Copy your vending machine contract\n4. Paste your contract in Remix\n\n\"File explorer > New file\"\n5. Compile your contract in Remix\n\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\n (_) | |\n __ _ _ __ __ __ _ | |\n / _` | | '_ \\ \\ \\ / / | | | |\n | (_| | | | | | \\ V / | | | |\n \\__,_| |_| |_| \\_/ |_| |_|\n\n 0.2.0 (7f0f5b4 2024-08-08T00:19:07.020431000Z)\n https://github.com/foundry-rs/foundry\n\n# Available Accounts\n\n(0) 0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266 (10000.000000000000000000 ETH)\n(1) 0x70997970C51812dc3A010C7d01b50e0d17dc79C8 (10000.000000000000000000 ETH)\n(2) 0x3C44CdDdB6a900fa2b585dd299e03d12FA4293BC (10000.000000000000000000 ETH)\n(3) 0x90F79bf6EB2c4f870365E785982E1f101E93b906 (10000.000000000000000000 ETH)\n(4) 0x15d34AAf54267DB7D7c367839AAf71A00a2C6A65 (10000.000000000000000000 ETH)\n(5) 0x9965507D1a55bcC2695C58ba16FB37d819B0A4dc (10000.000000000000000000 ETH)\n(6) 0x976EA74026E726554dB657fA54763abd0C3a0aa9 (10000.000000000000000000 ETH)\n(7) 0x14dC79964da2C08b23698B3D3cc7Ca32193d9955 (10000.000000000000000000 ETH)\n(8) 0x23618e81E3f5cdF7f54C3d65f7FBc0aBf5B21E8f (10000.000000000000000000 ETH)\n(9) 0xa0Ee7A142d267C1f36714E4a8F75612F20a79720 (10000.000000000000000000 ETH)\n\n# Private Keys\n\n(0) 0xac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80\n(1) 0x59c6995e998f97a5a0044966f0945389dc9e86dae88c7a8412f4603b6b78690d\n(2) 0x5de4111afa1a4b94908f83103eb1f1706367c2e68ca870fc3fb9a804cdab365a\n(3) 0x7c852118294e51e653712a81e05800f419141751be58f605c371e15141b007a6\n(4) 0x47e179ec197488593b187f80a00eb0da91f1b9d0b13f8733639f19c30a34926a\n(5) 0x8b3a350cf5c34c9194ca85829a2df0ec3153be0318b5e2d3348e872092edffba\n(6) 0x92db14e403b83dfe3df233f83dfa3a0d7096f21ca9b0d6d6b8d88b2b4ec1564e\n(7) 0x4bbbf85ce3377467afe5d46f804f221813b2bb87f24d81f60f1fcdbf7cbf4356\n(8) 0xdbda1821b80551c9d65939329250298aa3472ba22feea921c0cf5d620ea67b97\n(9) 0x2a871d0798f97d79848a013d4936a73bf4cc922c825d33c1cf7073dff6d409c6\n\n# Wallet\n\nMnemonic: test test test test test test test test test test test junk\nDerivation path: m/44'/60'/0'/0/\n\n# Chain ID\n\n31337.\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\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.\n\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\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 addressCupcake 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 addressCupcake 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.\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\nHow is this guide?Build apps with SolidityDeploy Solidity smart contracts to Arbitrum One, Arbitrum Nova, and any Arbitrum chain.Create a tokenThis quickstart walks you through the process of how to setup the Foundry environment, and create a token on Arbitrum.","tokens":7497,"squid":"spider-01","role":"Chain Spider","at":1791340832009,"hash":"c34804c3e1f6bdaf89d8a579a1e6903e0cd5cda5"}
{"url":"https://docs.switchboard.xyz/ai-agents-llms/switchboard-agent-skill/switchboard-solana-svm-feeds","domain":"docs.switchboard.xyz","title":"Switchboard Solana/SVM Feeds Skill | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.PurposeIntegrate Switchboard on-demand feeds into Solana/SVM transactions and programs:Compose transactions that verify/update and then consume feed values correctlyImplement on-chain verification patterns (Anchor/Rust) when your program consumes feedsSupport “cranking” patterns to keep canonical quote accounts warm (push-like behavior)DependenciesUse exact pins from the SDK Version Matrix.@switchboard-xyz/on-demand@3.10.6@switchboard-xyz/common@5.8.5@solana/web3.js@1.98.0@coral-xyz/anchor@0.31.1 (TypeScript client)switchboard-on-demand = \"0.13.0\" (Rust on-chain)This skill is about integration correctness, not designing new feed definitions (handled by switchboard-feed-design).PreconditionsOperatorPolicy exists (network, RPC allowlist, autonomy/spend limits).Inputs to Collectnetwork: mainnet-beta / devnet / customrpcUrl (optional override)crossbarUrl (public or self-hosted)feedId list (32-byte 0x... hex)consumer program ID / instruction shape (if integrating)validation targets: max staleness (slots), max deviation, min responsesSolana/SVM Integration InvariantsConsumer instruction must occur after Switchboard verification/update instructions in the same transaction.Use deterministic/canonical accounts; do not accept arbitrary “quote accounts” without canonical checks.New feed-hash integrations use queue.fetchManagedUpdateIxs(...) and canonical quote-program accounts. Do not suggest PullFeed.fetchUpdateIx(...) unless the user is maintaining an existing classic PullFeed account and confirms queue/gateway support for that legacy path.Variable overrides are secrets-only (never selectors/URLs/paths/IDs/multipliers).Minimal Exampleconst updateIxs = await queue.fetchManagedUpdateIxs(crossbar, [feedId], {\n numSignatures: 1,\n payer: keypair.publicKey,\n variableOverrides: {},\n});\n\nconst tx = await sb.asV0Tx({\n connection,\n ixs: [...updateIxs, consumerIx],\n signers: [keypair],\n});\n\nawait connection.sendTransaction(tx);Playbook1) Resolve queue and canonical accountsLoad the correct oracle queue for the network (default unless user specifies).Derive or verify canonical quote storage addresses as required by the SDK/program pattern.If your program accepts a quote account, enforce that it is canonical for the queue + feedId.2) Update + consume in one transaction (TypeScript skeleton)Goal: fetch Switchboard-managed update instructions, then call the consumer instruction.import * as sb from \"@switchboard-xyz/on-demand\";\n\nconst { keypair, connection, program } = await sb.AnchorUtils.loadEnv();\nconst queue = await sb.Queue.loadDefault(program!);\n\nconst crossbar = new sb.Crossbar({\n rpcUrl: connection.rpcEndpoint,\n // NOTE: exact constructor args can differ by SDK version; treat as placeholder.\n});\n\n// Managed update instructions (must be BEFORE your consumer ix)\nconst updateIxs = await queue.fetchManagedUpdateIxs(crossbar, [feedId], {\n numSignatures: 1,\n variableOverrides: {}, // secrets only\n payer: keypair.publicKey,\n});\n\n// Your program instruction that reads verified data\nconst consumerIx = await buildYourConsumerIx(/* programId, accounts, args */);\n\nconst tx = await sb.asV0Tx({\n connection,\n ixs: [...updateIxs, consumerIx],\n signers: [keypair],\n});\n\nawait connection.sendTransaction(tx);Indexing rule:Keep each Ed25519/quote-program pair returned by fetchManagedUpdateIxs adjacent. asV0Tx resolves the final indices after all setup and consumer instructions are assembled.If you compile the transaction yourself, call finalizeManagedUpdateInstructions on the complete ordered instruction array immediately before compilation.3) On-chain verification (Rust/Anchor pattern)Use the on-demand verifier and enforce staleness:use switchboard_on_demand::QuoteVerifier;\n\nlet quote = QuoteVerifier::new()\n .queue(&ctx.accounts.queue)\n .slothash_sysvar(&ctx.accounts.slothashes)\n .ix_sysvar(&ctx.accounts.instructions)\n .clock_slot(Clock::get()?.slot)\n .max_age(50)\n .verify_instruction_at(0)?;\n\nfor feed in quote.feeds() {\n // feed.value(), feed.decimals(), feed.hex_id(), etc.\n}Note: quote.feeds() contains feed outputs (such as price values). Randomness uses a different path: read bytes from RandomnessAccountData::get_value(...) in the Randomness Tutorial.Also enforce, when applicable:canonical quote address constraintsdeviation checks vs stored “last good” value for high-risk logic4) Cranking pattern (push-like / heartbeat imitation)Use this when you want other transactions/users to read the most recently cranked value from the canonical quote account without providing updates every time.Tradeoffs:Pros: readers can do cheaper reads; UI dashboards can stay warm.Cons: loses atomic update+use guarantees; must enforce staleness at read-time.Minimal crank loop: send a transaction that contains only the managed update instructions.async function crankOnce(feedId: string) {\n const updateIxs = await queue.fetchManagedUpdateIxs(crossbar, [feedId], {\n numSignatures: 1,\n payer: keypair.publicKey,\n variableOverrides: {},\n });\n\n const tx = await sb.asV0Tx({\n connection,\n ixs: [...updateIxs],\n signers: [keypair],\n });\n\n return connection.sendTransaction(tx);\n}\n\n// Example: crank every 10 seconds (tune to your needs/costs)\nsetInterval(() => crankOnce(feedId).catch(console.error), 10_000);Operational guidance:Run cranks from a dedicated wallet with explicit spend limits.Monitor failures and staleness; treat missed cranks as “feed stale” for consumers.OutputsProduce a SolanaFeedIntegrationPlan including:network + RPC/Crossbar URLfeedId(s) and queue resolution methodexact instruction ordering (list)consumer instruction shape (accounts/args) if integratingoptional safety policy (staleness/deviation/signatures) if requestedcrank plan (if requested): cadence, cost bounds, monitoringTroubleshooting ChecklistSignature verification index mismatch → re-check instructionIdx vs final tx instruction orderMissing sysvars → include SlotHashes + Instructions sysvars in accountsNon-canonical quote account → derive canonical address; reject non-canonical inputspullFeedSubmitResponseConsensus or PullFeed.fetchUpdateIx(...) returns ORACLE_UNAVAILABLE, but managed Ed25519 quote updates work → user is on the legacy PullFeed path; move to queue.fetchManagedUpdateIxs(...) and canonical quote accountsSuccessful simulation but signed updates fail with RangeExceeded → feed validation issue; check raw v2 maxJobRangePct scaling separately from PullFeed-vs-quote-program routingCompute limits → add compute budget ixs; reduce feeds/oracles per txReferenceshttps://docs.switchboard.xyz/docs-by-chain/solana-svmhttps://docs.switchboard.xyz/docs-by-chain/solana-svm/price-feedshttps://docs.switchboard.xyz/tooling/crossbarPreviousSwitchboard Agent SkillNextSwitchboard EVM Feeds SkillLast updated 2 months ago","tokens":1709,"squid":"spider-08","role":"Oracle Spider","at":1791340832064,"hash":"138b8caf001ef8422813485f8bf6da968d9cc41b"}
{"url":"https://forum.across.to/c/proposals/active-proposals/21/l/top","domain":"forum.across.to","title":"Top Proposals/Active Proposals topics - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n Top topics in Active Proposals\n\n Proposals\n\n Active Proposals\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 posted\n Oct 31\n\n by @Methodic\n\n Velodrome Liquidity Program Extension\n\n Summary: \nAcross Protocol’s pilot program on Velodrome ended in October. This proposal aims to extend its initial program for 16 weeks in order to ensure sufficient liquidity for ACX on L2s. \nThe Velodrome team presented…\n\n read more\n\n alexander\n replied\n\n Jan 8, 2024\n\n 19\n\n 28\n\n posted\n Mar 7\n\n by @TheRealTuna_Across\n\n “Community Owned Liquidity” NFT Project Funding Request\n\n Title: “Community Owned Liquidity” NFT project funding request \nAuthor: The Real Tuna \nContributors: Britt, Daywiss, EASports, TheRealTuna, Underthesea \nStatus: RFC \nRelated Discussions: N/A \nSubmission Date: 03/07/2023 \n…\n\n read more\n\n caesarsherrod.eth\n replied\n\n Jun 20, 2023\n\n treasury-funding\n\n 36\n\n 40\n\n posted\n Feb 26\n\n by @mydefi\n\n Straddl.io Expansion Proposal\n\n Author(s): My Defi, GR (Cat Herder), Infinity \nStatus: Proposal \nSubmission Date: TBD \nSummary:\nStraddl (https://straddl.io) is a next-generation bridging platform built entirely on Across Protocol, designed to offer use…\n\n read more\n\n mydefi\n replied\n\n Mar 3, 2025\n\n 11\n\n 33\n\n posted\n Feb 13\n\n by @daostratconsensys\n\n Support Linea Chain Bridge Routes\n\n Point of Contact\nArthur Remy - Linea Core, Product Manager \nCam O’Donnell - @daostratconsensys - Linea Growth, Product Manager \nProposal Details\nProposal Overview\nThe Linea core team proposes the integration of Across to…\n\n read more\n\n daostratconsensys\n replied\n\n Feb 20, 2024\n\n 7\n\n 21\n\n posted\n May 21\n\n by @adam3001\n\n Support Mode chain bridge routes\n\n Point of Contact\nAdam: Head of Business Development \nDeez: Head of Growth \nProposal Details\nProposal Overview\nThe Mode core team proposes the integration of Across to Mode. In collaboration with the Across core team, the…\n\n read more\n\n adam3001\n replied\n\n May 27, 2024\n\n 4\n\n 15\n\n posted\n May 21\n\n by @Methodic\n\n Build liquidity for $ACX on Velodrome\n\n Related Discussions: \n\nSummary: \nCurrently, Across Protocol’s $ACX has little liquidity on Layer 2s, limiting the ability for users to acquire $ACX with low slippage and provide liquidity on L2s. This proposal aims to bo…\n\n read more\n\n alexander\n replied\n\n Jul 22, 2023\n\n treasury-funding\n\n 8\n\n 16\n\n posted\n Nov 17\n\n by @TheRealTuna_Across\n\n Community Integration Campaign 2.0\n\n Summary: \nThis proposal allocates 150,000 ACX as bounties, to community members who can bring value to Across by facilitating integrations between Across and crypto projects that share a similar vision. \nMotivation: \nAcr…\n\n read more\n\n PVMihalache\n replied\n\n Nov 21, 2023\n\n 5\n\n 9\n\n posted\n May 6\n\n by @bennidaytime\n\n Native USDC and CCTP Integration\n\n Native USDC and CCTP Integration\nTitle: Native USDC and CCTP Integration \nAuthor(s): RL \nStatus: Proposal \nSummary: \nTwo versions of USDC exist on many L2s that Across supports: a “bridged” version via a chains’ bridge a…\n\n read more\n\n Clayton_UMA\n replied\n\n May 6, 2024\n\n 4\n\n 5\n\n posted\n Mar 20\n\n by @Muskan\n\n Educational Awareness Campaign for Across Protocol in Southeast Asia\n\n Hello Community Members, \nI am Muskan Sadh from Finstreet India’s first Crypto and DeFi Education Platform. We are hereby sharing our plans below to aware our audiences about Across Protocol features and utilities. Feel …\n\n read more\n\n Muskan\n replied\n\n Mar 25, 2023\n\n 3\n\n 5\n\n posted\n Jun 13\n\n by @barbarossa_Arrakis\n\n ACX Market Making Proposal - Arrakis PALM\n\n Header\nTitle: ACX Market Making Proposal - Arrakis PALM \nAuthor(s): @barbarossa_Arrakis \nStatus: Proposal \nRelated Discussions: “Community Owned Liquidity” NFT Project Funding Request \nBody\nSummary: \nDeploy Arrakis PALM …\n\n read more\n\n caesarsherrod.eth\n replied\n\n Jun 27, 2023\n\n treasury-funding\n\n 3\n\n 7\n\n posted\n Jan 2\n\n by @adalhi\n\n [RFC : Grant Request] Across Monthly Financial Reports\n\n Name : Asymmetric Defi \nProject : Across Monthly Financial Reporting \nDetailed Description of Project : \nProvide Monthly Reports about the State of the Across DAO. The reports would include : Overview of governance votes…\n\n read more\n\n roundmound\n replied\n\n Jun 2, 2023\n\n treasury-funding\n\n 6\n\n 9\n\n posted\n Oct 16\n\n by @2chairs\n\n Support Superseed Bridge Routes\n\n Author: Superseed \nProposal Details \nProposal Overview \nThe Superseed core team proposes the integration of Across to Superseed. In collaboration with the Across core team, the Superseed team has been working to ensure t…\n\n read more\n\n PVMihalache\n replied\n\n Oct 17, 2024\n\n 1\n\n 2\n\n posted\n Apr 24\n\n by @TheRealTuna_Across\n\n Across UMA Voting Committee – Renewal Proposal\n\n Title: Across UMA Voting Committee – Renewal Proposal \nAuthor(s): EAsports, TheRealTuna, mydefi, neondaemon, underethsea \nStatus: Proposal \nRelated Discussions: \n\nDiscord: Discussion currently welcomed in Across Governan…\n\n read more\n\n TheRealTuna_Across\n replied\n\n May 18, 2025\n\n 6\n\n 6\n\n posted\n Jul 26\n\n by @biscaryn\n\n Support Redstone Bridge Routes\n\n Author: Biscaryn, Ecosystem @ Redstone \nProposal Details \nProposal Overview \nThe Redstone core team proposes the integration of Across to Redstone. In collaboration with the Across core team, the Redstone team has been w…\n\n read more\n\n 1\n\n posted\n Jul 15\n\n by @sherooberoo\n\n Support Scroll Bridge Routes\n\n Author: Shahryar, Partnerships Lead @ Scroll \nProposal Overview\nThe Scroll core team proposes the integration of Across to Scroll. In collaboration with the Across core team, the Scroll team has been working to ensure th…\n\n read more\n\n PVMihalache\n replied\n\n Jul 15, 2024\n\n 2\n\n 2\n\n posted\n May 3\n\n by @Hadari\n\n Cryptohadari NFT Proposal\n\n posted\n Aug 20\n\n by @Kevin_UMA\n\n Reduce ACX emissions for WBTC LPs\n\n Author(s): ACX Emissions Committee (Kevin Chan, David Korpi, Ryan Carman, Dylan O’Reilly, Chase Coleman) \nStatus: Proposed \nRelated Discussions: Reduce ACX emissions for ACX LPs, WBTC LPs and wstETH/ACX LPs \nSummary\nThe …\n\n read more","tokens":2980,"squid":"spider-09","role":"Bridge Spider","at":1791340835683,"hash":"c307cfe067cfdd5f76cf4409ff699815a3da67d2"}
{"url":"https://docs.switchboard.xyz/ai-agents-llms/switchboard-agent-skill/switchboard-movement-feeds","domain":"docs.switchboard.xyz","title":"Switchboard Movement Feeds Skill | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.PurposeUse Switchboard on-demand feeds on Movement:crank/update feeds client-side (pull model)integrate verified values into Move-based application logicapply freshness/deviation validation policies appropriate to riskDependenciesUse exact pins from the SDK Version Matrix.@switchboard-xyz/aptos-sdk@0.1.5@switchboard-xyz/common@5.8.5@aptos-labs/ts-sdk@6.1.0PreconditionsOperatorPolicy exists (Movement network, signer custody, RPC allowlist).Inputs to CollectAlways collect:network (mainnet/testnet)RPC endpointcrossbarUrl (default: https://crossbar.switchboard.xyz)feed/aggregator identifiers used by Movement integrationCollect validation thresholds only if relevant (risk-sensitive) or requested:maxStaleness (time-based freshness requirement)maxDeviationBps (sanity bound vs last value/expected value)minResponses / minSampleSize (how many oracle responses/signatures you require per update)InvariantsPull-based: client must crank/update feeds to keep data fresh.Ensure update occurs before read/use within the same flow recommended by Movement docs.Playbook (high-level)Discover feed identifiers for the target network.Crank/update feed using the Movement SDK flow.In Move, read latest value + timestamp and enforce staleness/deviation as needed.Define failure mode: pause/guard high-risk actions when stale or deviating.Minimal Exampleuse aptos_framework::aptos_coin::AptosCoin;\nuse aptos_framework::object::{Self, Object};\nuse on_demand::aggregator::{Self, Aggregator, CurrentResult};\nuse on_demand::update_action;\n\npublic entry fun read_feed(account: &signer, update_data: vector<vector<u8>>) {\n update_action::run<AptosCoin>(account, update_data);\n let feed: Object<Aggregator> = object::address_to_object<Aggregator>(@0xSomeFeedAddress);\n let current: CurrentResult = aggregator::current_result(feed);\n let _price = aggregator::result(&current);\n}Referenceshttps://docs.switchboard.xyz/docs-by-chain/movementhttps://docs.switchboard.xyz/tooling/crossbarPreviousSwitchboard Iota Feeds SkillNextSwitchboard Feed Design SkillLast updated 2 months ago","tokens":538,"squid":"spider-08","role":"Oracle Spider","at":1791340853967,"hash":"f623caa605ae6e1e7c77eb399d4a81beab6c61c1"}
{"url":"https://forum.across.to/","domain":"forum.across.to","title":"Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n All categories\n\n categories\n\n tags\n\n Categories\n\n Latest\n\n Top\n\n Category\n Topics\n\n WELCOME 👋\n\n 3\n\n Proposals\n\n Across governance currently controls:\n\n Passed Proposals\n\n Active Proposals\n\n Archived Proposals\n\n 71\n\n Ideas & Feedback\n\n Open-ended discussion category for new ideas, suggestions for improvement, or feedback on governance.\n\n 20\n\n Tokenomics (old)\n\n This category was used to discuss the tokenomics of the ACX token ahead of the token launch. It will remain open for reference until after the token has launched and will then be archived.\n\n 5\n\n Committees\n\n 20\n\n Updates\n\n 3\n\n Latest\n\n $ACX Portal Update\n\n Updates\n\n 0\n\n Jun 30\n\n The Across token buyout portal is now live\n\n Updates\n\n 0\n\n 19d\n\n The Bridge Across - August Update\n\n Updates\n\n 0\n\n Aug 5\n\n The Bridge Across\n\n Proposalsgovernance-updates\n\n 39\n\n Apr 25\n\n Across UMA Voting Committee March Renewal Proposal\n\n Proposalsgovernance-updates\n\n 0\n\n Feb 6\n\n AUVC January Update\n\n Committees\n\n 0\n\n Jan 26\n\n [RFC-Grant Request] Chaser Finance\n\n Ideas & Feedback\n\n 3\n\n Jan 6\n\n AUVC November+ Report\n\n Committees\n\n 0\n\n Dec 2025\n\n Across UMA Voting Committee – Renewal Proposal Nov 11th\n\n Proposalstreasury-funding\n\n 1\n\n Nov 2025\n\n AUVC Report September 1st through October 31st\n\n Committees\n\n 0\n\n Nov 2025\n\n More","tokens":1811,"squid":"spider-09","role":"Bridge Spider","at":1791340857597,"hash":"95d5917d89e8039125058f8516601c8164fdfcda"}
{"url":"https://docs.switchboard.xyz/ai-agents-llms/switchboard-agent-skill/switchboard-iota-feeds","domain":"docs.switchboard.xyz","title":"Switchboard Iota Feeds Skill | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.PurposeUse Switchboard on-demand feeds on Iota:store job definitions and create aggregatorscrank updates using Iota transactions (pull model)consume results in Move with freshness/deviation checksDependenciesUse exact pins from the SDK Version Matrix.@switchboard-xyz/iota-sdk@0.0.3@switchboard-xyz/common@5.8.5@iota/iota-sdk@1.11.0PreconditionsOperatorPolicy exists (Iota network, signer custody, RPC allowlist).Inputs to Collectnetwork (mainnet/testnet)RPC endpointcrossbarUrl (default: https://crossbar.switchboard.xyz)aggregator/feed object IDssafety policy (staleness/deviation/min responses) only if risk-sensitiveInvariantsPull-based: updates must be executed client-side.Transaction ordering matters: update before consume.Playbook (high-level)Resolve Switchboard state/queue for the network.Store jobs (if creating a new feed) and initialize aggregator.Fetch update transaction/actions and execute them.Call consumer Move function after update actions.Enforce staleness/deviation in Move.Minimal Exampleimport { Aggregator, SwitchboardClient } from \"@switchboard-xyz/iota-sdk\";\nimport { Transaction } from \"@iota/iota-sdk/transactions\";\n\nconst sb = new SwitchboardClient(iotaClient);\nconst aggregator = new Aggregator(sb, aggregatorId);\n\nconst tx = new Transaction();\nawait aggregator.fetchUpdateTx(tx);\nawait iotaClient.signAndExecuteTransaction({ signer: keypair, transaction: tx });Referenceshttps://docs.switchboard.xyz/docs-by-chain/iotahttps://docs.switchboard.xyz/tooling/crossbarPreviousSwitchboard Aptos Feeds SkillNextSwitchboard Movement Feeds SkillLast updated 2 months ago","tokens":422,"squid":"spider-08","role":"Oracle Spider","at":1791340865898,"hash":"82152fec503dc3872c4e500ed4e4d8630e92a6dc"}
{"url":"https://forum.across.to/c/ideas-feedback/5","domain":"forum.across.to","title":"Latest Ideas & Feedback topics - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n Latest topics in Ideas & Feedback\n\n Ideas & Feedback\n\n tags\n\n Latest\n\n Top\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n posted\n Nov 3\n\n by @Britt\n\n Pinned\n\n About the Ideas & Feedback category\n\n Open-ended discussion category for new ideas, suggestions for improvement, or feedback on governance.\n\n _ATOM\n replied\n\n Nov 9, 2022\n\n 1\n\n 4\n\n posted\n Jun 3\n\n by @chaser.finance\n\n [RFC-Grant Request] Chaser Finance\n\n Chaser Finance Proposal\nTitle: Chaser Finance Proposal (RFC)\nAuthor(s): Chaser Finance (Michael Manzano), neondaemon\nStatus: RFC\nchaser.finance\nSummary:\nChaser Finance proposes a milestone-based grant from the Across DAO…\n\n read more\n\n ohhhdigital\n replied\n\n Jan 6\n\n 3\n\n 6\n\n posted\n Sep 20\n\n by @TheRealTuna_Across\n\n Proposal Discussion: Strategic Use of Earned UMA by the Across DAO\n\n As the Across DAO approaches a milestone of 500,000 UMA earned through UMA voting participation, it’s an opportune time to open a discussion about how we, as a community, can best utilize this UMA to benefit the Across p…\n\n read more\n\n megan_xchain\n replied\n\n Sep 25, 2025\n\n 4\n\n 11\n\n posted\n Aug 5\n\n by @TheRealTuna_Across\n\n AUVC July Report\n\n AUVC July Report \nIn July, the AUVC participated in 139 votes, with no incorrect votes for the month. During our current 3 month term, we have only 1 incorrect vote. In the month of July we increased our correctness perc…\n\n read more\n\n posted\n Jul 5\n\n by @TheRealTuna_Across\n\n AUVC June Report\n\n AUVC June Report \n\nIn June, the AUVC participated in 98 votes, with only one incorrect vote regarding the Fordow nuclear facility’s status. We were concerned about the possibility of being penalized for this vote, but …\n\n read more\n\n 2\n\n posted\n Mar 13\n\n by @jackmelnick\n\n Support Polygon zkEVM Bridge Routing on Across\n\n Carnation - Polygon Labs DeFi \nJack - Polygon Labs DeFi \nProposal Overview\nAfter numerous requests from dApps building on Polygon zkEVM, we’d like to propose for the DAO the addition of an Across bridging route to Polygo…\n\n read more\n\n latinowinner\n replied\n\n Dec 9, 2024\n\n 5\n\n 11\n\n posted\n Mar 7\n\n by @neondaemon\n\n Across AI Assistant Proposal\n\n Title: Across AI Assistant Proposal \nAuthor(s): pennypanda., neondaemon \nStatus: RFC \nSummary\nIntroducing Appy*, a cutting-edge AI-powered assistant, designed for the Across Protocol community. Appy serves as a versatile…\n\n read more\n\n latinowinner\n replied\n\n Dec 9, 2024\n\n 11\n\n 14\n\n posted\n Nov 17\n\n by @poppedcorngaming\n\n Refundable Charity Grant Proposal\n\n Refundable Charity Grant Proposal\nAuthor(s): poppedcorngaming \nStatus: Proposal Idea \nRelated Discussions: - \nSubmission Date: 16/11/24 \n\nSummary\nYield for Good is the world’s first no-loss charity platform, powered by t…\n\n read more\n\n posted\n Jul 26\n\n by @net00x_13259\n\n Integration and Utilization Campaign for Across with Latin America’s Largest X-to-Earn Community\n\n Hello Across Community Members, \nI am Neto from Cointimes.com.br, the first and largest X-to-Earn platform in Latin America. We at Cointimes would like to share our ideas for increasing the use of Across in Brazil by lev…\n\n read more\n\n volume,awareness\n\n posted\n Feb 26\n\n by @neondaemon\n\n Across DAO Handbook\n\n Author: neondaemon \nStatus: RFC \nRelated document: Governance Operating Manual \nPurpose: To create an HR policies and procedures document for the DAO. As the DAO matures the handbook will evolve to accommodate new learn…\n\n read more\n\n trippz10x\n replied\n\n Feb 27, 2024\n\n governance-update\n\n 3\n\n 7\n\n posted\n Sep 27\n\n by @neondaemon\n\n Across Community Essentials Committee Formation Proposal\n\n Title: Across Community Essentials Committee Formation Proposal \nAuthor(s): Mide, mydefi, neondaemon, PVM, TheRealTuna \nStatus: Request for Feedback \nRelated Discussions: Community Essentials Committee Description \nSumma…\n\n read more\n\n neondaemon\n replied\n\n Sep 29, 2023\n\n 5\n\n 15\n\n posted\n Aug 22\n\n by @Kevin_UMA\n\n Reduce or Reallocate Across ACX LP emissions\n\n Across ACX LPs staked in reward locking currently earn 7.84% to 26.7% driven by base emissions of 20,000 ACX per day. \nThis is a significant amount given there is currently very little ACX being bridged. The emissions we…\n\n read more\n\n Ryan_UMA\n replied\n\n Sep 11, 2023\n\n liquidity\n\n 2\n\n 1\n\n posted\n Jul 19\n\n by @eth-wei-trader\n\n Tokenomics & Liquidity Incentives: Pair ACX w Across LP Tokens\n\n I believe we can improve ACX liquidity while also paying for bridge liquidity - killing two birds with one stone. \nWe should pair ACX with Across LP tokens such as USDC, USDT, DAI, ETH, and WBTC on Balancer and incentivi…\n\n read more\n\n eth-wei-trader\n replied\n\n Aug 22, 2023\n\n liquidity\n\n 2\n\n 1\n\n posted\n May 18\n\n by @eth-wei-trader\n\n Enable Cross-Chain Swaps\n\n Across has an opportunity to enable cross-chain swaps using the same technology it has pioneered for bridging. If a user wants swap token x on the source chain for token y on the destination chain then it works exactly a…\n\n read more\n\n eth-wei-trader\n replied\n\n Jul 18, 2023\n\n 8\n\n 8\n\n posted\n Jun 20\n\n by @caesarsherrod.eth\n\n Across Integration with Safe, Formally Gnosis\n\n Good Day from an Across Committee Member hopeful, \nThe Safe App holds a great deal of wealth in Cryptocurrency Realms and there are only a few bridges are integrated into the App. Across can increase bridge traffic and i…\n\n read more\n\n volume\n\n 2\n\n posted\n May 19\n\n by @Kevin_UMA\n\n $ACX Liquidity - Update and Feedback Wanted\n\n ACX liquidity is an ongoing topic in the community. I want to use this forum to share some observations and gather feedback and views to help guide any potential actions we should consider taking. \nOpen questions to disc…\n\n read more\n\n Dakotah\n replied\n\n Jun 3, 2023\n\n 7\n\n 8\n\n posted\n May 20\n\n by @iamnaok\n\n Adding $LUSD as a bridgeable token\n\n Hey there, \nI would like to suggest adding $LUSD as a bridgeable token. Buy doing that, Across will not only better serve its customers, but will get additional competitive advantage over Hop (who doesn’t support $LUSD),…\n\n read more\n\n ayoki\n replied\n\n May 23, 2023\n\n 3\n\n 5\n\n posted\n Jan 16\n\n by @tumilet.eth\n\n [RFC] Protocol Fee Switch\n\n Some community members (myself included) recently introduced the idea of “bridging” some % share of the total protocol fees to the DAO. Since launching on November 2021, a total of $2.7M in fees have been collected, whi…\n\n read more\n\n caesarsherrod.eth\n replied\n\n Apr 7, 2023\n\n 4\n\n 6\n\n posted\n Dec 9\n\n by @Britt\n\n Ideas for the Across DAO Structure\n\n With the launch of the token, Across has now become more than just a protocol - we are a DAO. In this season of the DAO’s growth, there will be a strong need for dedicated work on building and maintaining our socialware.…\n\n read more\n\n alexsunny123\n replied\n\n Dec 17, 2022\n\n 8\n\n 13\n\n posted\n Nov 17\n\n by @jotatotal\n\n Across protocol dao escheme\n\n Link to document\n\n 9\n\n posted\n Nov 17\n\n by @jotatotal\n\n Across protocol organigrama\n\n Days ago, I uploaded a proposal over discord about the governance of the DAO. Here is it so everyone can read it. \nMission and organization chart of the DAO \nThere are different types of DAO, some for altruistic purposes…\n\n read more\n\n 3","tokens":3263,"squid":"spider-09","role":"Bridge Spider","at":1791340869515,"hash":"25c8488cd1ea920555969a8abbe5167119510c0d"}
{"url":"https://developer.arbitrum.io/arbitrum-bridge/quickstart","domain":"developer.arbitrum.io","title":"Quickstart: Arbitrum bridge","text":"Quickstart: Arbitrum bridgeLearn how to use Arbitrum's bridge to transfer ETH or ERC-20 tokens between a parent chain and a child chainRequest an updateThis quickstart is for users who want to deposit ETH or any ERC-20 tokens from a to a or vice versa, using Arbitrum’s bridge. For example, from Ethereum to , 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 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 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\nWarningNote 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 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.\nWarningTestnets 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?How is this guide?Arbitrum bridgeMove ETH and ERC-20 tokens between Ethereum and Arbitrum chains.USDC on Arbitrum OneLearn about the two different types of USDC supported by Arbitrum One: Arbitrum-Native USDC and Bridged (from Ethereum) USDC","tokens":1581,"squid":"spider-01","role":"Chain Spider","at":1791340887994,"hash":"b45c97e9f99f3c7c8aad55d171705a6a9f3cc5ae"}
{"url":"https://docs.switchboard.xyz/ai-agents-llms/switchboard-agent-skill/switchboard-evm-feeds","domain":"docs.switchboard.xyz","title":"Switchboard EVM Feeds Skill | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.PurposeIntegrate Switchboard on-demand feeds into EVM contracts and bots:Fetch verifiable update payloads off-chainSubmit updates on-chain via the Switchboard contract (pay required fee)Read verified feed results and enforce freshness/deviation constraintsSupport “cranking” patterns to emulate push/heartbeat feedsDependenciesUse exact pins from the SDK Version Matrix.@switchboard-xyz/common@5.8.5@switchboard-xyz/on-demand-solidity@1.1.0ethers@6.13.1PreconditionsOperatorPolicy exists (chainId, RPC allowlist, contract allowlist, spend limits).Inputs to CollectAlways collect:chainId + network namerpcUrlcrossbarUrl (default: https://crossbar.switchboard.xyz)switchboardContractAddress (resolve from official deployments)feedId list (bytes32)Collect safety policy only if relevant (risk-sensitive logic) or requested:maxAgeSecondsmaxDeviationBpsEVM Integration InvariantsAlways compute and pay fee (e.g., getFee) before updateFeeds.For safety-critical logic, accept updates as calldata and do update+read inside the same app function.Minimal Examplefunction updateAndRead(bytes[] calldata updates, bytes32 feedId) external payable {\n uint256 fee = switchboard.getFee(updates);\n switchboard.updateFeeds{value: fee}(updates);\n switchboard.latestUpdate(feedId);\n}Playbook1) Resolve deployments and feedsResolve switchboardContractAddress from official docs for the chain/network.Confirm it is allowlisted by OperatorPolicy.Obtain feedId(s) for the same network.2) Fetch update payloads off-chain (Crossbar)import { CrossbarClient } from \"@switchboard-xyz/common\";\n\nconst crossbarUrl = process.env.CROSSBAR_URL ?? \"https://crossbar.switchboard.xyz\";\nconst crossbar = new CrossbarClient(crossbarUrl);\n\n// For Feed Builder/custom feeds, use the v2 feed-hash flow.\nawait crossbar.simulateFeed(feedId, false, undefined, network);\n\nconst response = await crossbar.fetchV2Update([feedId], {\n chain: \"evm\",\n network,\n use_timestamp: true,\n});\n\nif (!response.encoded) throw new Error(\"Crossbar returned no encoded update payload\");\n\nconst updates = [response.encoded];3) Contract-side recommended pattern (atomic update+use)function updateAndUse(bytes[] calldata updates, bytes32[] calldata feedIds) external payable {\n uint256 fee = switchboard.getFee(updates);\n require(msg.value >= fee, \"InsufficientFee\");\n\n switchboard.updateFeeds{value: fee}(updates);\n\n for (uint256 i = 0; i < feedIds.length; i++) {\n // Read latest verified update for feedIds[i]\n // Enforce maxAgeSeconds and maxDeviationBps in your app logic\n }\n\n // Optional refund of msg.value - fee\n}4) Client-side submit flowimport { ethers } from \"ethers\";\n\nconst switchboard = new ethers.Contract(switchboardContractAddress, SWITCHBOARD_ABI, signer);\n\nconst fee = await switchboard.getFee(updates);\nconst tx = await switchboard.updateFeeds(updates, { value: fee });\nawait tx.wait();\n\nconst latest = await switchboard.latestUpdate(feedId);5) Cranking pattern (push-like / heartbeat imitation)Use this when you want other callers to read latestUpdate(feedId) without providing updates each time.Tradeoffs:Pros: cheaper reads for many consumers; simpler UI integrations.Cons: data can go stale between cranks; consumers must enforce staleness.Crank loop:async function crankOnce(feedIds: string[]) {\n const response = await crossbar.fetchV2Update(feedIds, {\n chain: \"evm\",\n network,\n use_timestamp: true,\n });\n\n if (!response.encoded) {\n throw new Error(\"Crossbar returned no encoded update payload\");\n }\n\n const updates = [response.encoded];\n\n const fee = await switchboard.getFee(updates);\n const tx = await switchboard.updateFeeds(updates, { value: fee });\n await tx.wait();\n}\n\n// Example: crank every 15 seconds (tune to costs and requirements)\nsetInterval(() => crankOnce([feedId]).catch(console.error), 15_000);Operational guidance:Use a dedicated keeper wallet with explicit spend limits.For liquidation/settlement flows, prefer atomic update+use even if a crank exists.OutputsProduce an EvmFeedIntegrationPlan including:chainId/network + RPC/Crossbar URLresolved Switchboard contract address (and source)feedId(s)atomic update+use pattern (recommended) vs crank pattern (optional)fee strategy with spend capsoptional safety policy (maxAge/maxDeviation) if requestedTroubleshooting ChecklistFee too low → always call getFee(updates) and set msg.valueStale timestamp → fetch fresh updates; raise max age only for non-critical pathsWrong feed/network → verify feedId and deployment match chainId/networkFeed Builder custom feed on EVM → use simulateFeed(...) and fetchV2Update(...), not fetchEVMResults(...)ORACLE_UNAVAILABLE after successful simulation -> check managed oracle/gateway availability and oracle-side validation errors such as RangeExceeded; raw v2 maxJobRangePct must be scaled by 1e9Referenceshttps://docs.switchboard.xyz/docs-by-chain/evmhttps://docs.switchboard.xyz/docs-by-chain/evm/price-feedshttps://docs.switchboard.xyz/tooling/crossbarPreviousSwitchboard Solana/SVM Feeds SkillNextSwitchboard Sui Feeds SkillLast updated 2 months ago","tokens":1277,"squid":"spider-08","role":"Oracle Spider","at":1791340888063,"hash":"b6af6869dc11ba570ce1d238e57aa53d83668906"}
{"url":"https://forum.across.to/t/rfc-grant-request-chaser-finance/1936","domain":"forum.across.to","title":"[RFC-Grant Request] Chaser Finance - Ideas & Feedback - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n [RFC-Grant Request] Chaser Finance \n\n Ideas & Feedback\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 Jun 2024\n\n 1 / 4\n\n Jun 2024\n\n Jan 6\n\n post by chaser.finance on Jun 3, 2024\n\n chaser.finance\n\n Chaser Finance Proposal\nTitle: Chaser Finance Proposal (RFC)\nAuthor(s): Chaser Finance (Michael Manzano), neondaemon\nStatus: RFC\nchaser.finance\nSummary:\nChaser Finance proposes a milestone-based grant from the Across DAO to finish its development. To enable novel investment strategies for decentralized protocols, Chaser implements Across V3 for bridging and depositing into reputable DeFi lending markets. With a successful launch, Chaser can bring great value to Across with a high volume of bridge transactions. The grants requested would reimburse necessary development expenses. Chaser also requests a deposit from the Across DAO to be returned with yield generated for the sake of promoting Chaser after launch.\nWhat is Chaser?\nChaser is a smart contract platform for custom, metric-based DeFi strategies. With Chaser, DAOs make better yields off of their liquidity while gaining deeper control over risk. Chaser facilitates intents based investing by using Across+ to directly enter positions on protocols like Aave and Compound between multiple chains.\nAt ETHOnline 2023, Chaser originated with success by winning the top prizes for 3 sponsors, including Across/UMA. The inspiration for data-driven DeFi strategies came from my experience working on the Messari Standardized Subgraph project. During this time, I began to conceptualize what would be possible if the kind of data indexed in subgraphs was brought on-chain. Making time-series and granular position data available in smart contracts has the potential to significantly enhance the investment capabilities of all vaults, lending platforms, and DAOs.\nWhat Does Chaser Solve?\nCurrent DeFi yield strategies are limited. Pools can only deposit to investments on their local network, preventing easy entrance into markets with better returns on the same asset. Additionally, there is a lack of useful data for investment calculation on-chain. Decentralized protocols cannot move investments based off of historical data points or granular metrics like open position balances or user counts. These calculations can only be done off chain and are inaccessible to DAOs and yield vaults.\nChaser addresses these limitations by leveraging Across V3 to move pool deposits between different chains and lending markets, generating the highest possible yields from your favorite protocols. With UMA for strategy management, Chaser serves as a platform for building customizable yield strategies to maximize your liquidity usage while following your specific risk parameters. Using subgraph data from protocols like Aave and Compound, Chaser allows protocols to factor in various metrics such as:\n\nHistoric pool volumes, revenues, and yields for any day\nGranular data on all open positions\nProtocol wide data, comparisons between corresponding markets on different networks.\n\nUsers can create Chaser pools to dynamically move deposits between chains and protocols based on insights from this data. This maximizes yield while allowing for filtering based on custom metrics, helping avoid lending markets with undesirable characteristics like high volatility or low volume.\nExample Strategy #1: Highest Daily Yield USDC\nLet’s take a Chaser USDC pool with a strategy that deposits into the Aave or Compound market with the highest yield over the past 24 hours. Over a 90 day period, moving deposits to the market with the highest daily yield returns an APY of 14.06%.\nWhereas leaving the funds on any given USDC market on these two protocols over the same period would have the following yields:\n\nCompound Ethereum USDC: 9.77%\nCompound Arbitrum USDC: 8.00%\nCompound Polygon USDC: 10.28%\nAave Arbitrum USDC: 9.75%\nAave Base USDC: 5.90%\nAave Ethereum USDC: 8.75%\nAave Optimism USDC: 9.67%\nAave Polygon USDC: 10.41%\n\nCHASER USDC: 14.06%\n1024×768 303 KB\n(Yields recorded between Feb. 1 2024 to May 1 2024)\nThis optimization is unmatched for protocols aiming to maximize cross-chain investments and create more flexible custom on-chain strategies with historical and positional data.\nExample Strategy #2: Low Liquidation Risk\nInstead of solely chasing the highest yield, this second strategy demonstrates how a pool could use Chaser’s inter-protocol, inter-chain optimization while also setting custom filters for risk. Imagine a pool that wants to invest into riskier protocols with higher leverage and lower deposit volume while maintaining a threshold of acceptable risk. This “Low Liquidation Risk” strategy uses data from Aave and Compound subgraphs to:\n\nQuery subgraphs for the top 100 depositors in the proposed market.\nGet these depositors’ open collateral and borrow positions.\nMeasure each depositor’s risk.\nCalculate the weighted average risk for the market.\nIf weighted risk >= 50%, prevent the pivot.\nIf weighted risk < 50% AND the proposed market yield is higher than the current market yield, move the investment.\n\nThis pool pivots investments to the proposed market only if it is higher yielding and with a liquidation risk below 50%.\nLet’s say a Chaser WETH pool with this strategy is currently invested in Aave V3 Mainnet with a 2% return. There are two other Aave WETH markets that are yielding higher:\n\nAave V3 Optimism - 3% return and 63% liquidation risk\nAave V3 Arbitrum - 2.5% return and 37% liquidation risk\n\nIf a user proposes to move the pool’s investments to Aave V3 Optimism, the proposal will be rejected because the risk passed the acceptable threshold filter. However, a proposal to move to Aave V3 Arbitrum will be accepted as it meets the criteria for both higher yield and acceptable risk, even though the yield is currently lower than the Optimism market.\nView this strategy logic\nHow do Chaser Strategies Work?\nChaser employs the UMA Optimistic Oracle to execute and maintain its custom strategies. Users deploying a Chaser pool can write custom JavaScript logic to fetch subgraph data and calculate necessary metrics. When a superior investment opportunity is identified by a user or monitor, they open an assertion that a specific market on a particular protocol and chain offers a better yield. This is then proven by running the strategy script according to specific parameters. If the proposal is approved, the oracle instructs Chaser to move the investment to the new position.\nWhy does Chaser Use Across?\nTo optimize for yield between chains, Chaser bridges exclusively with Across V3. Across V3 is both cheaper and faster than alternatives while simplifying fee payments. The fees are deducted directly from the transferred tokens, eliminating the need for separate fee management. In contrast, competitors like CCIP and LayerZero require maintaining a LINK/ETH balance across all chains. Additionally, Across V3 easily integrates for executing logic upon receiving a bridge, without needing routers, configurations, or special contract imports. Even though Chaser uses CCIP to help with inter-chain state management and callbacks, Across is used for all bridging needs.\nVision\nChaser aims to provide the highest possible returns, recognizing that many DAOs and DeFi users prioritize yield over the specific chain generating it. Additionally, there is demand for more mature investment options offering deeper analytical insights on-chain. Chaser acts as infrastructure to elevate decentralized investing opportunities, enhancing risk management and closing gaps that previously hindered analytical deposit strategies.\nChaser is targeting two markets:\n\nDAOs investing unused treasury funds for higher returns.\nLending protocols/Yield Vaults looking to build on top of Chaser to offer products that use the Chaser investment strategies platform.\n\nAlthough these markets already exist, chain interoperability is still a new concept and opens up space to build a service that arbitrages the differences between chains and offers higher returns to depositors.\nBy launch, I plan to expand strategy logic capabilities to enable more complex mathematical analysis. Additionally, another priority for expansion is to integrate more lending protocols and assets for investment. Both of these adjustments create the potential for more interesting strategy use cases.\nHow Will Chaser Improve Across?\nBy using Across for all inter-chain value transfers, Chaser will significantly increase transaction volume on Across. Every deposit and withdrawal interaction in a Chaser pool with a position on a different chain sends funds through Across, resulting in many bridge transactions. Additionally, when a Chaser pool identifies a better investment opportunity, it moves the entire pool’s funds through Across, generating high-value bridge transactions. Both types of transactions contribute to increased fee revenues and usage on the Across platform.\nChaser also serves as a prime example of how the Across+ messaging feature can be utilized effectively. By leveraging Across’s messaging capabilities, Chaser demonstrates how inter-chain applications can be built to solve interoperability challenges. This showcases the practicality of cross-chain intents with Across+, promoting it as a valuable tool for developing interoperable DeFi protocols.\nImplementation\nChaser Beta is now live on Arbitrum Sepolia (https://chaser.finance), with a Mainnet launch scheduled for September. The beta has a working integration with Across V3, using the messaging handler to bridge and enter positions into both Aave and Compound on Sepolia, Optimism Sepolia and Arbitrum Sepolia. In order to fulfill the vision laid out above and bring true value to the Across community, there are some major product development tasks to be done before launch:\n\nFinish V1 contracts: There is still some refactoring to be done and features to be added before auditing. Additionally, I will make any fixes needed resulting from the audit.\nHiring a JavaScript Developer: I am bringing on a full-time JavaScript developer to focus on building the front end and the strategy script mechanism. This will allow me to concentrate entirely on the smart contracts and protocol design.\nSearching for a Co-Founder: I am actively seeking a co-founder to handle the operational aspects of the project, including growth and finances.\nConducting a Professional Audit: As a DeFi protocol aiming to attract investment, it is crucial to undergo a professionally conducted audit to ensure depositor confidence. Given the unique mechanisms Chaser employs to move liquidity between chains, a thorough audit is essential to identify any design flaws and vulnerabilities.\nMarketing: Beyond offering a quality service, we need to attract users to Chaser. Following a successful audit, we will start marketing on X (Twitter). The plan includes contracting a firm specializing in DeFi projects for social media management and content creation. Additionally, we will allocate an ad spend budget to reach as many users as possible.\n\nDownsides and Security Considerations\n\nSmart contract risk: Because of general vulnerabilities when dealing with moving funds and data between chains, there is a higher level of risk when depositing to Chaser. Even though this is an inevitability for protocols looking to solve interoperability, this risk can be mitigated with good design and thorough auditing. While a private audit is a necessary step before launching Chaser, we are exploring doing a competitive audit as well for the sake of spotting these vulnerabilities.\n\nDeposit and withdrawal delays: When depositing to Chaser, if the pool you deposit to has its position on another chain, you do not have instant liquidity. When needing to withdraw funds from Chaser, you have to send a request inter-chain to bridge back your deposits. Your position tokens are locked in escrow until you receive the funds. While this entire process is about 10 minutes, it can make a big difference for depositors needing liquidity at a moment’s notice. To avoid this drawback, Chaser allows pools to enable certain chains. This means that Chaser pools could restrict investments to only be on the home chain where liquidity is instant within a singular transaction.\n\nPosition movement illiquidity: In order to prevent issues with conflicting inter-chain messages and state among various contracts, depositor liquidity is paused during proposed position movements on a pool. Deposits and withdrawals to pools are blocked within one hour of the position change assertion being resolved. To impede unnecessary interaction pauses, Chaser pools select the bond amount required to propose an investment movement, making bad actors put up large amounts to be lost when submitting erroneous proposals. Also, if a pool deployer wants to only let a pool monitor bot automatically propose movements, they can assign the monitor address a specific role to be able to submit proposals.\n\nMilestones and Funding Request\nTo successfully position Chaser to facilitate innovative strategies and optimize yields inter-chain, we seek support from the Across community. Below are the proposed milestones and the funds requested upon completion of each:\nMilestone #1: Finish Product\n\nConduct a private or competitive audit\nBuild strategy monitors and create five basic strategies\nFinalize the front end\nComplete V1 contracts\nEstimated Completion: Late-August\n\nFunding Request for Completion of Milestone #1:\n\n$8,990 in USD to cover the audit cost, as quoted by a reputable auditing firm.\n$7,000 in USD for development, including the front end, strategy scripts, monitor bots, and other tools. This amount is based on the developer’s salary.\n\nTotal for Milestone #1: $15,990 USD (Paid in ACX)\nMilestone #2: Launch\n\nLaunch on Arbitrum Mainnet\nInitiate a marketing campaign on X and establish social media presence\nEstimated Completion: Mid-September\n\nFunding Request for Completion Milestone #2:\n\n$10,000 USD for marketing to grow the user base organically. Approximately $5,000 will be allocated to contract social media experts for content creation and initial marketing strategy, and remaining amount for ad campaigns on X.\n$25,000 USDC deposit in a Chaser Aave/Compound pool, to be returned with yield earned to the Across DAO after 6 months. This is to help demonstrate the protocol’s legitimacy and yield-generating capabilities.\n\nTotal for Milestone #2: $10,000 USD + $25,000 USD deposit returned with yield generated (Paid in ACX)\nTOTAL REQUEST: $25,990 USD + $25,000 USDC deposit for 6 months (Paid in ACX)\nFuture Plans\nLeading up to launch, Chaser will request grants from other DAOs such as Arbitrum and Aave. While this grant proposal is to cover the absolute essentials in finishing Chaser, there are additional expenses to further guarantee Chaser’s success. This includes:\n\nCode4rena campaign to find a wider range of security vulnerabilities and inefficiencies\nIncrease the marketing budget\nHiring another Solidity developer\n\nAfter the Mainnet launch, most focus will be on adjusting the protocol for any sorts of issues or feedback based on the first users. While Chaser will move towards whatever early users show a need for, there are some ideas to pursue that could grow Chaser:\n\nDecentralized governance: Within a few months after launch, many actions will be decentralized in order for Chaser to grow as a decentralized protocol. As is standard in DeFi, major protocol decisions should be voted on to enforce quality and reflect the values of its users.\nEnable borrowing assets: Similar to using strategies to filter deposit markets, enabling borrowing against these deposits would allow for new use cases and greater transaction volume. Rather than only having use for depositors who want yield, Chaser could be used for entities that want to borrow against these deposits. With more protocols developing cross chain position capability, there is additional opportunity to deposit into a market on one chain, and use strategies to borrow assets from the market on the best chain according to customized parameters.\nInstant liquidity: Mechanisms could be built in Chaser’s smart contracts to allow for instant liquidity for deposits held on other chains. Essentially, it would borrow from deposits held on the home chain and repay the local pool when bridging completes with fees. This system would attract depositors that want to use Chaser’s strategy platform while also needing instant liquidity.\n\nLinks:\ndApp: https://chaser.finance\nX: ChaserFinance\nRepo: GitHub - MichaelC1999/chaser\nDocs: GitHub - MichaelC1999/chaser\nConclusion\nThe Beta launch of Chaser Finance is live on Arbitrum Sepolia! chaser.finance\nPlease check out the dApp and comment about your experience! It would be great to have some feedback to perfect the Chaser dApp before the Mainnet launch.\nAll comments are appreciated! Before finalizing a proposal, we want to hear thoughts about the requests laid out here and further elaborate on any details about Chaser. Looking forward to engaging further with the Across Community!\n\n 2\n\n read \n\n 7\n min\n\n 11 days later\n\n post by Bananachain on Jun 15, 2024\n\n Bananachain\n\n A realy great post and a fascinating project. \nMy 2 s while reading:\nYou are requesting funding for audit and marketing at different milestone levels (+applying for funding from other protocols). Auditing in particular seems rather on the low side. And good marketing can also be costly. How did you reach these figures?\nFor regulatory reasons I would probably choose to avoid references to airdrops and tokens at this point and rephrase, in particular if you have exposure to the US. It may insinuate some kind of reward expectation given you are linking it to amounts being deposited into a pool. While your issue is decentralisation, this token would also have utility as you outline under “Chaser Liquidity Token”.\n\n post by chaser.finance on Jun 17, 2024\n\n chaser.finance\n\n The auditing budget is based off of a quote for a private audit by a security firm with a good reputation. Ideally, I would like to get a competitive audit done. However, the amount needed to do this is a bit high to ask for in a single grant request. With funding from other DAOs, raising the security budget for a thorough competitive audit is the top priority.\nFor marketing, the budget is based on an estimate for two months of services from social media marketing firms specializing in DeFi projects. These services typically charge between $2000-$3000 USD per month for handling social media strategy and content creation. I plan to contract a firm part-time to grow Chaser’s social media presence leading up to and immediately following the Mainnet launch. At this stage, a full-time role is unnecessary but will be reconsidered post-launch. After secure funding for the competitive audit, expanding the marketing budget is the next priority.\nYou’ve made a great point about tokens and airdrops. Token issuance requires more careful planning and consultation. I’ll remove references to distributing Chaser tokens and design a better plan before launch that rewards loyal users while adhering to regulations.\nAppreciate the feedback!\n\n 2 years later\n\n post by ohhhdigital on Jan 6\n\n ohhhdigital\n\n i fully support this great project, You are requesting funding for audit and marketing at different milestone levels (+applying for funding from other protocols). Auditing in particular seems rather on the low side. And good marketing can also be costly. How did you reach these figures?\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Proposal for Across to generate USDC revenue through ACX covered call lending on MYSO\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 17\n\n Jun 2024\n\n Straddl.io Expansion Proposal\n\n Active Proposals\n\n Active Proposals\n\n 11\n\n Mar 2025\n\n “Community Owned Liquidity” NFT Project Funding Request\n\n Active Proposals\n\n treasury-funding\n\n Active Proposals\n\n 36\n\n Jun 2023\n\n Across Token Launch Proposal v2\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 47\n\n Nov 2022\n\n Across ($ACX) Community Initial Liquidity Proposal\n\n Passed Proposals\n\n Passed Proposals\n\n 49\n\n Nov 2022","tokens":6550,"squid":"spider-09","role":"Bridge Spider","at":1791340891696,"hash":"2ccd9f43875c2c2d4a4944a747fc0a899e3f1768"}
{"url":"https://docs.switchboard.xyz/ai-agents-llms/switchboard-agent-skill/switchboard-sui-feeds","domain":"docs.switchboard.xyz","title":"Switchboard Sui Feeds Skill | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.PurposeIntegrate Switchboard on-demand feeds into Sui Move contracts using the Quote Verifier pattern:Fetch oracle quotes off-chain and attach to a Sui transactionVerify quotes on-chain against the correct oracle queueEnforce freshness/deviation constraints in MoveSupport “cranking” patterns to keep on-chain consumer state warm (push-like behavior)DependenciesUse exact pins from the SDK Version Matrix.@switchboard-xyz/sui-sdk@0.1.16@switchboard-xyz/on-demand@3.10.6@mysten/sui@1.38.0PreconditionsOperatorPolicy exists (Sui network, RPC allowlist, signer custody).Inputs to CollectAlways collect:network: mainnet / testnetrpcUrlcrossbarUrl (default: https://crossbar.switchboard.xyz)Switchboard deployment package ID (resolve from official docs)consumer package ID + consumer object IDfeedId list (32-byte hex)numOraclesCollect safety policy only if relevant (risk-sensitive logic) or requested:maxAgeMsmaxDeviationBpsSui Integration InvariantsVerify quotes against the queue from SwitchboardClient.fetchState().Verify before use; apply explicit staleness/deviation checks.Minimal Exampleconst tx = new Transaction();\nconst quotes = await Quote.fetchUpdateQuote(sb, tx, {\n feedHashes: [feedId],\n numOracles,\n});\n\ntx.moveCall({\n target: `${consumerPackageId}::module::update_price`,\n arguments: [tx.object(consumerObjectId), quotes, tx.pure.vector(\"u8\", feedIdBytes), tx.object(\"0x6\")],\n});\n\nawait suiClient.signAndExecuteTransaction({ signer: keypair, transaction: tx });Playbook1) Resolve queue and feedsFetch Switchboard state to identify oracleQueueId.Confirm feed IDs exist for the chosen network.2) Transaction flow (TypeScript skeleton)import { SuiClient } from \"@mysten/sui/client\";\nimport { Transaction } from \"@mysten/sui/transactions\";\nimport { SwitchboardClient, Quote } from \"@switchboard-xyz/sui-sdk\";\n\nconst crossbarUrl = process.env.CROSSBAR_URL ?? \"https://crossbar.switchboard.xyz\";\n\nconst suiClient = new SuiClient({ url: rpcUrl });\nconst sb = new SwitchboardClient(suiClient);\nconst state = await sb.fetchState();\n\nconst tx = new Transaction();\n\nconst quotes = await Quote.fetchUpdateQuote(sb, tx, {\n feedHashes: [feedId],\n numOracles,\n});\n\ntx.moveCall({\n target: `${consumerPackageId}::module::update_price`,\n arguments: [\n tx.object(consumerObjectId),\n quotes,\n tx.pure.vector(\"u8\", feedIdBytes),\n tx.object(\"0x6\"), // Clock\n ],\n});3) Cranking pattern (push-like / heartbeat imitation)Use this when you want the consumer object to hold a “recently verified” value so other txs can read it cheaply without attaching quotes every time.Tradeoffs:Pros: cheaper reads for many consumers; simpler UI.Cons: consumer must enforce staleness; values can go stale between cranks.Crank loop concept:Periodically execute the update_price (or your equivalent) Move entry function with fresh quotes.async function crankOnce() {\n const tx = new Transaction();\n\n const quotes = await Quote.fetchUpdateQuote(sb, tx, {\n feedHashes: [feedId],\n numOracles,\n });\n\n tx.moveCall({\n target: `${consumerPackageId}::module::update_price`,\n arguments: [\n tx.object(consumerObjectId),\n quotes,\n tx.pure.vector(\"u8\", feedIdBytes),\n tx.object(\"0x6\"),\n ],\n });\n\n // signAndExecuteTransaction must follow OperatorPolicy rules\n return suiClient.signAndExecuteTransaction({ signer: keypair, transaction: tx });\n}\n\n// Example cadence (tune to requirements/cost)\nsetInterval(() => crankOnce().catch(console.error), 15_000);OutputsProduce a SuiFeedIntegrationPlan including:network/RPC/Crossbar URLSwitchboard package resolution method + queue ID resolutionconsumer object update/read strategy:atomic quote+use, orcranked storage + staleness checksoptional safety policy if requestedTroubleshooting Checklistfeed not found in quotes → ensure requested feedId included in fetchUpdateQuotequote expired → fetch again; adjust max age only for non-critical flowswrong queue/network → verify package IDs and network matchReferenceshttps://docs.switchboard.xyz/docs-by-chain/suihttps://docs.switchboard.xyz/docs-by-chain/sui/price-feedshttps://docs.switchboard.xyz/tooling/crossbarPreviousSwitchboard EVM Feeds SkillNextSwitchboard Aptos Feeds SkillLast updated 2 months ago","tokens":1062,"squid":"spider-08","role":"Oracle Spider","at":1791340898162,"hash":"00a1d41c4626f7568720ab081b69b9d9ccc0a086"}
{"url":"https://developer.arbitrum.io/arbitrum-bridge/embedded-bridge-widget","domain":"developer.arbitrum.io","title":"Arbitrum embedded bridge widget","text":"Arbitrum embedded bridge widgetLearn how to integrate and configure the Arbitrum bridge widget in your dAppRequest 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 \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\nHow is this guide?USDC on Arbitrum OneLearn about the two different types of USDC supported by Arbitrum One: Arbitrum-Native USDC and Bridged (from Ethereum) USDCTracing bridge transactionsLearn how to trace transactions happening through the Arbitrum bridge","tokens":1060,"squid":"spider-01","role":"Chain Spider","at":1791340900310,"hash":"ac8a8385d3365cc575ba4474793deaa211268a3c"}
{"url":"https://jup.ag/lend/borrow/smart","domain":"jup.ag","title":"Borrow Against Your Crypto on Solana | Jupiter Lend","text":"Dual Stream LiquidityOne deposit, two yields. Supply to a Smart Vault and earn from lending and trading fees at once.Smart VaultsBorrow against your assets, keep your upside.$31.7M$25.8MVaultssUSDai-USDCDebtUSDCLiq. Threshold 90%Market Size$13.0MSupplyapy5.4%Open sUSDai-USDC / USDC vaultJupUSD-reUSDDebtJupUSDLiq. Threshold 90%Market Size$6.01MSupplyapy5.52%Open JupUSD-reUSD / JupUSD vaultPST-USDCDebtJupUSDLiq. Threshold 90%Market Size$5.02MSupplyapy5.05%Open PST-USDC / JupUSD vaultSOL-JitoSOLDebtSOLLiq. Threshold 92%Market Size$155KSupplyapy4.56%Open SOL-JitoSOL / SOL vaultUSDG-USDCDebtUSDCLiq. Threshold 94%Market Size$37.7KSupplyapy4.27%Open USDG-USDC / USDC vaultsyrupUSDC-USDCDebtUSDCLiq. Threshold 92%Market Size$5.84KSupplyapy4.34%Open syrupUSDC-USDC / USDC vaultSmart MultiplyLoop your assets into a leveraged position.LoopssyrupUSDC-USDCDebtUSDCMax Multiplier9.8xMarket Size$5.84KNet APY0%Open syrupUSDC-USDC / USDC vaultSmart EarnSupply a token pair and earn lending and trading fees. No borrowing, no liquidation.VaultDepositedTotal SupplyUSX / USDC-FAQsYour position starts doing double duty. Instead of sitting idle earning only the yield from utilization, it's deposited into Jupiter AMM as paired liquidity — so it earns trading fees from swaps routed through that pair, on top of whatever it already earned. Supplying to a Smart Collateral vault means extra yield. Borrowing from a Smart Debt vault means those fees flow back to offset your interest.A normal supply position earns one thing: a supply APY. Supplying to a Smart Collateral vault can earn two: the same supply APY plus the asset's own native yield if it has one (an LST's staking rate, for example), and trading fees from the pair it's deposited into.You only need to supply one side of the pair — the vault composes it at the live pool ratio for you.A normal loan is one-directional — you borrow, and interest accrues against you the whole time. Borrowing from a Smart Debt vault puts your borrowed position to work: it becomes liquidity on Jupiter AMM, and swap fees routed through it come back to reduce what you effectively owe.You can still borrow and repay in a single asset or the exact pair ratio — the mechanics of taking out and repaying the loan don't change, only what happens to the position while it's open.Yes — the more volume that routes through your Smart Debt vault, the more it offsets your interest. How much varies with trading activity, so it isn't a fixed number, but it's the core reason Smart Debt vaults exist: turning a cost center into something that actively works against itself.Supplying to or borrowing from a Smart Vault adds AMM-specific exposure on top of normal lending risk:Impermanent loss — because your position is paired liquidity, its composition can shift with the pool's price ratio. Smart Vault pairs are correlated assets, which keeps this shift small in normal conditions, but a depeg or sustained divergence between the pair can still move your position's composition.Fee variability — fee earnings depend on trading volume relative to the pool's size, and both change over time. A pool with high volume against its TVL can out-earn a larger, quieter one, so returns differ by pair and aren't guaranteed.Smart contract risk — Smart Vaults run additional AMM logic on top of the liquidity layer your funds already sit in, which increases the surface area of risk compared with a simple lending position.No. Smart Vaults are a separate choice you make per position. Supplying or borrowing normally on Jupiter Lend works exactly as it always has — supply and earn a supply APY, borrow and pay interest. Smart Vaults are additional vault types you can choose instead, and they only affect the positions you actually place there.Check JupLend Guides","tokens":945,"squid":"spider-02","role":"Liquidity Spider","at":1791340974527,"hash":"2446e29d2942b07f393bd62e72b710a3955e41ca"}
{"url":"https://docs.phantom.com/sdks/browser-sdk/sign-and-send-transaction","domain":"docs.phantom.com","title":"Sign and send transactions - Phantom developer documentation","text":"The Phantom Connect Browser SDK provides chain-specific transaction methods through dedicated interfaces (sdk.solana and sdk.ethereum) for optimal transaction handling.\nEmbedded wallet limitations: The signTransaction and signAllTransactions methods aren’t supported for embedded wallets. For embedded wallets, use only signAndSendTransaction that signs and broadcasts the transaction in a single step.\nTransaction security for embedded wallets: All transactions signed for embedded wallets pass through Phantom’s advanced simulation system before execution. This security layer automatically blocks malicious transactions and transactions from origins that have been reported as malicious, providing an additional layer of protection for your users’ assets.\n​Chain-specific transaction methods\n​Solana transactions (sdk.solana)\n// Sign and send transaction\nconst result = await sdk.solana.signAndSendTransaction(transaction);\n\n// Just sign (without sending) - Note: Not supported for embedded wallets\nconst signedTx = await sdk.solana.signTransaction(transaction);\n\n​Ethereum transactions (sdk.ethereum)\n// Send transaction\nconst result = await sdk.ethereum.sendTransaction({\n to: \"0x...\",\n value: \"1000000000000000000\",\n gas: \"21000\",\n});\n\n​Dapp-sponsored transactions\nPass a presignTransaction callback to signAndSendTransaction for Solana transactions that need double signing, such as dapp fee payer flows. Calls without it proceed normally — it is never applied globally.\nPhantom embedded wallets do not accept pre-signed transactions. If your use case requires a second signer (for example, your app as the fee payer), that signing must happen via this callback, after Phantom has constructed and validated the transaction. This restriction does not apply to injected providers (Phantom browser extension).\npresignTransaction only fires for Solana transactions via the embedded provider. EVM transactions and injected providers are unaffected.\n​Transaction format\nThe transaction string passed to the callback is base64url-encoded (URL-safe base64 without = padding, using - and _ instead of + and /). The SDK exports base64urlDecode and base64urlEncode utilities:\nimport { base64urlDecode, base64urlEncode } from \"@phantom/browser-sdk\";\n\n​Example: dapp fee payer\nimport { base64urlDecode, base64urlEncode } from \"@phantom/browser-sdk\";\nimport { VersionedTransaction } from \"@solana/web3.js\";\n\n// This call co-signs as fee payer\nconst result = await sdk.solana.signAndSendTransaction(transaction, {\n presignTransaction: async (tx, context) => {\n // Send the transaction to your backend for fee payer signing\n const response = await fetch(\"/api/presign\", {\n method: \"POST\",\n body: JSON.stringify({ transaction: tx, networkId: context.networkId }),\n headers: { \"Content-Type\": \"application/json\" },\n });\n const { transaction: signedTx } = await response.json();\n return signedTx; // base64url-encoded, partially signed by the fee payer\n },\n});\n\n// This call has no co-signer\nconst result2 = await sdk.solana.signAndSendTransaction(otherTransaction);\n\nNever hold a fee payer keypair in frontend code. The presignTransaction callback runs in the browser — use it to call your own backend, which holds the keypair securely and returns the partially-signed transaction.\n​Transaction examples\n​Solana transaction examples\nThe SDK supports multiple Solana transaction libraries. Here are examples using both @solana/web3.js and @solana/kit:\n​Solana with @solana/web3.js\nimport {\n VersionedTransaction,\n TransactionMessage,\n SystemProgram,\n PublicKey,\n LAMPORTS_PER_SOL,\n Connection,\n} from \"@solana/web3.js\";\nimport { BrowserSDK, AddressType } from \"@phantom/browser-sdk\";\n\nconst sdk = new BrowserSDK({\n providers: [\"injected\"],\n addressTypes: [AddressType.solana],\n});\n\nawait sdk.connect({ provider: \"injected\" });\n\n// Get recent blockhash\nconst connection = new Connection(\"https://api.mainnet-beta.solana.com\");\nconst { blockhash } = await connection.getLatestBlockhash();\n\n// Create transfer instruction\nconst fromAddress = await sdk.solana.getPublicKey();\nconst transferInstruction = SystemProgram.transfer({\n fromPubkey: new PublicKey(fromAddress),\n toPubkey: new PublicKey(toAddress),\n lamports: 0.001 * LAMPORTS_PER_SOL,\n});\n\n// Create VersionedTransaction\nconst messageV0 = new TransactionMessage({\n payerKey: new PublicKey(fromAddress),\n recentBlockhash: blockhash,\n instructions: [transferInstruction],\n}).compileToV0Message();\n\nconst transaction = new VersionedTransaction(messageV0);\n\n// Send transaction using chain-specific API\nconst result = await sdk.solana.signAndSendTransaction(transaction);\nconsole.log(\"Transaction signature:\", result.hash);\n\n​Solana with @solana/kit\nimport {\n createSolanaRpc,\n pipe,\n createTransactionMessage,\n setTransactionMessageFeePayer,\n setTransactionMessageLifetimeUsingBlockhash,\n address,\n compileTransaction,\n} from \"@solana/kit\";\nimport { BrowserSDK, AddressType } from \"@phantom/browser-sdk\";\n\nconst sdk = new BrowserSDK({\n providers: [\"injected\"],\n addressTypes: [AddressType.solana],\n});\n\nawait sdk.connect({ provider: \"injected\" });\n\n// Create transaction with @solana/kit\nconst rpc = createSolanaRpc(\"https://api.mainnet-beta.solana.com\");\nconst { value: latestBlockhash } = await rpc.getLatestBlockhash().send();\n\nconst userPublicKey = await sdk.solana.getPublicKey();\nconst transactionMessage = pipe(\n createTransactionMessage({ version: 0 }),\n tx => setTransactionMessageFeePayer(address(userPublicKey), tx),\n tx => setTransactionMessageLifetimeUsingBlockhash(latestBlockhash, tx),\n);\n\nconst transaction = compileTransaction(transactionMessage);\n\n// Send using chain-specific API\nconst result = await sdk.solana.signAndSendTransaction(transaction);\nconsole.log(\"Transaction signature:\", result.hash);\n\n​Dapp-sponsored transactions\nBy default, the user’s embedded wallet is the fee payer for all Solana transactions. The presignTransaction hook lets your app co-sign the transaction before the wallet signs it, enabling use cases like:\n\nDapp-as-fee-payer — your app covers the transaction fee so users don’t need SOL\nPlatform fees — add a fee instruction signed by your app’s keypair\nMulti-signer flows — any scenario where the app needs to sign alongside the user’s wallet\n\nPhantom embedded wallets do not accept pre-signed transactions. If your use case requires a second signer, this hook is the only supported approach — your app’s signing must happen after Phantom has constructed and validated the transaction. This restriction does not apply to injected providers (e.g. the Phantom browser extension).\nPass presignTransaction directly to signAndSendTransaction for the specific calls that need it. Calls without it proceed normally — the function is never applied globally.\n​Example: app as fee payer\nimport { base64urlDecode, base64urlEncode } from \"@phantom/browser-sdk\";\nimport { Keypair, VersionedTransaction } from \"@solana/web3.js\";\n\n// Your app's fee payer keypair (keep this on your backend in production)\nconst feePayerKeypair = Keypair.fromSecretKey(/* your fee payer secret key */);\n\n// This call co-signs as fee payer\nconst result = await sdk.solana.signAndSendTransaction(transaction, {\n presignTransaction: async (tx, context) => {\n // tx: base64url-encoded Solana transaction bytes\n // context: { networkId: string, walletId: string }\n\n // 1. Decode base64url → raw bytes\n const txBytes = base64urlDecode(tx);\n\n // 2. Deserialize\n const versionedTx = VersionedTransaction.deserialize(txBytes);\n\n // 3. Partially sign as fee payer — the user's wallet will sign next\n versionedTx.sign([feePayerKeypair]);\n\n // 4. Re-serialize → encode back to base64url\n return base64urlEncode(versionedTx.serialize());\n },\n});\n\n// This call has no presignTransaction — proceeds without any co-signing\nconst result2 = await sdk.solana.signAndSendTransaction(otherTransaction);\n\nThe hook only fires for Solana transactions via the embedded provider. EVM transactions and injected providers are unaffected.\n​Ethereum transaction examples\nimport { BrowserSDK, AddressType } from \"@phantom/browser-sdk\";\n\nconst sdk = new BrowserSDK({\n providers: [\"injected\"],\n addressTypes: [AddressType.ethereum],\n});\n\nawait sdk.connect({ provider: \"injected\" });\n\n// Simple ETH transfer\nconst result = await sdk.ethereum.sendTransaction({\n to: \"0x742d35Cc6634C0532925a3b8D4C8db86fB5C4A7E\",\n value: \"1000000000000000000\", // 1 ETH in wei\n gas: \"21000\",\n gasPrice: \"20000000000\", // 20 gwei\n});\n\n// EIP-1559 transaction with maxFeePerGas\nconst result2 = await sdk.ethereum.sendTransaction({\n to: \"0x742d35Cc6634C0532925a3b8D4C8db86fB5C4A7E\",\n value: \"1000000000000000000\", // 1 ETH in wei\n data: \"0x...\", // contract call data\n gas: \"50000\",\n maxFeePerGas: \"30000000000\", // 30 gwei\n maxPriorityFeePerGas: \"2000000000\", // 2 gwei\n});\n\nconsole.log(\"Transaction hash:\", result.hash);\n\n​Ethereum with viem\nimport { parseEther, parseGwei, encodeFunctionData } from \"viem\";\nimport { BrowserSDK, AddressType } from \"@phantom/browser-sdk\";\n\nconst sdk = new BrowserSDK({\n providers: [\"injected\"],\n addressTypes: [AddressType.ethereum],\n});\n\n// Simple transfer with viem utilities\nconst result = await sdk.ethereum.sendTransaction({\n to: \"0x742d35Cc6634C0532925a3b8D4C8db86fB5C4A7E\",\n value: parseEther(\"1\").toString(), // 1 ETH\n gas: \"21000\",\n gasPrice: parseGwei(\"20\").toString(), // 20 gwei\n});\n\n// Contract interaction\nconst result2 = await sdk.ethereum.sendTransaction({\n to: tokenContractAddress,\n data: encodeFunctionData({\n abi: tokenAbi,\n functionName: \"transfer\",\n args: [recipientAddress, parseEther(\"100\")],\n }),\n gas: \"50000\",\n maxFeePerGas: parseGwei(\"30\").toString(),\n maxPriorityFeePerGas: parseGwei(\"2\").toString(),\n});\nWas this page helpful?","tokens":2423,"squid":"spider-10","role":"Tooling Spider","at":1791340977677,"hash":"dfcc8f64178a4a9c4f2bbde6f7d261c39e45cac0"}
{"url":"https://docs.phantom.com/sdks/browser-sdk/connect","domain":"docs.phantom.com","title":"Connect - Phantom developer documentation","text":"The Phantom Connect Browser SDK provides sdk.connect() to establish a connection to the wallet and access chain-specific operations.\nLearn about Phantom Connect: For details about authentication flows, login, account selection, and session management, see the Phantom Connect guide.\n​Basic connection\n​Connection flow\nAfter instantiating the SDK, use sdk.connect() to establish a connection to the wallet:\nimport { BrowserSDK, AddressType } from \"@phantom/browser-sdk\";\n\n// 1. Create SDK instance with allowed providers\nconst sdk = new BrowserSDK({\n providers: [\"google\", \"apple\", \"injected\"], // Allowed auth providers\n addressTypes: [AddressType.solana, AddressType.ethereum],\n appId: \"your-app-id\", // Required when using embedded providers\n});\n\n// 2. Connect to wallet (provider parameter must be in allowed providers list)\nconst { addresses } = await sdk.connect({ provider: \"google\" });\nconsole.log(\"Connected addresses:\", addresses);\n\n// 3. Use chain-specific methods\nconst signature = await sdk.solana.signMessage(\"Hello!\");\nconst ethResult = await sdk.ethereum.sendTransaction({\n to: \"0x...\",\n value: \"1000000000000000000\",\n gas: \"21000\",\n});\n\n​Authentication providers\nThe connect() method requires a provider parameter and automatically switches between providers based on the authentication method you specify:\n// Connect with injected provider (Phantom extension)\nawait sdk.connect({ provider: \"injected\" });\n\n// Connect with Google authentication (embedded provider)\nawait sdk.connect({ provider: \"google\" });\n\n// Connect with Apple authentication (embedded provider)\nawait sdk.connect({ provider: \"apple\" });\n\n​Connecting to injected extension\nThe injected provider directly connects to the user’s Phantom browser extension (not an embedded wallet). Before using this option, check if the extension is installed:\nimport { BrowserSDK, AddressType } from \"@phantom/browser-sdk\";\n\nconst sdk = new BrowserSDK({\n providers: [\"google\", \"apple\", \"injected\"],\n addressTypes: [AddressType.solana, AddressType.ethereum],\n appId: \"your-app-id\",\n});\n\n// Check if Phantom extension is installed\nconst isInstalled = await sdk.isPhantomInstalled();\n\nif (isInstalled) {\n // Connect directly to the extension wallet\n await sdk.connect({ provider: \"injected\" });\n} else {\n // Fallback to embedded wallet with OAuth\n await sdk.connect({ provider: \"google\" });\n}\n\nWhen to use the injected provider:\n\nUser wants to use their existing extension wallet directly.\nNo embedded wallet creation needed.\nDirect access to extension accounts and balances.\n\n​Configuration options\n​SDK configuration\nconst sdk = new BrowserSDK({\n // List of allowed authentication providers (REQUIRED)\n providers: [\"google\", \"apple\", \"injected\"],\n\n // Networks to enable\n addressTypes: [AddressType.solana, AddressType.ethereum],\n\n // Required when using embedded providers (google, apple)\n appId: \"your-app-id\",\n\n // Optional configuration\n authOptions: {\n redirectUrl: \"https://yourapp.com/auth/callback\", // optional, defaults to current page\n },\n\n // Auto-connect to existing session (default: true when embedded providers are used)\n autoConnect: true,\n});\n\nNotes about redirectUrl (for embedded provider):\n\nMust be an existing page/route in your app.\nMust be allowlisted in your Phantom Portal app configuration.\nThis is where users will be redirected after completing OAuth authentication.\n\n​Chain-specific operations\nAfter connection, use dedicated chain interfaces:\n​Solana operations\n// Message signing\nconst signature = await sdk.solana.signMessage(\"Hello Solana!\");\n\n// Transaction signing (without sending)\nconst signedTx = await sdk.solana.signTransaction(transaction);\n\n// Sign and send transaction\nconst result = await sdk.solana.signAndSendTransaction(transaction);\n\n// Network switching (works on embedded for solana)\nawait sdk.solana.switchNetwork('devnet');\n\n// Utilities\nconst publicKey = await sdk.solana.getPublicKey();\nconst isConnected = sdk.solana.isConnected();\n\n​Ethereum operations\nEVM support for Phantom Connect embedded wallets will go live later in 2026.\n// EIP-1193 requests\nconst accounts = await sdk.ethereum.request({ method: 'eth_accounts' });\nconst chainId = await sdk.ethereum.request({ method: 'eth_chainId' });\n\n// Message signing\nconst signature = await sdk.ethereum.signPersonalMessage(message, address);\n\n// EIP-712 typed data signing\nconst typedDataSignature = await sdk.ethereum.signTypedData(typedData, address);\n\n// Transaction sending\nconst result = await sdk.ethereum.sendTransaction({\n to: \"0x...\",\n value: \"1000000000000000000\", // 1 ETH in wei\n gas: \"21000\",\n});\n\n// Network switching\nawait sdk.ethereum.switchChain(1); // Ethereum mainnet\nawait sdk.ethereum.switchChain(137); // Polygon\n\n// Utilities\nconst chainId = await sdk.ethereum.getChainId();\nconst accounts = await sdk.ethereum.getAccounts();\nconst isConnected = sdk.ethereum.isConnected();\n\n​Auto-connect feature\nThe SDK can automatically reconnect to existing sessions when instantiated, providing a seamless user experience.\nconst sdk = new BrowserSDK({\n providers: [\"google\", \"apple\", \"injected\"],\n addressTypes: [AddressType.solana],\n appId: \"your-app-id\",\n autoConnect: true, // Default: true when embedded providers are used, false for injected-only\n});\n\n// SDK will automatically check for existing valid session and connect in background\n// No need to call connect() if user already has a session\n\n// Check if already connected\nif (sdk.isConnected()) {\n console.log(\"Already connected!\");\n const addresses = await sdk.getAddresses();\n} else {\n // First time or session expired, need to connect manually\n await sdk.connect({ provider: \"google\" });\n}\n\n​Disabling auto-connect\nconst sdk = new BrowserSDK({\n providers: [\"google\", \"apple\", \"injected\"],\n appId: \"your-app-id\",\n addressTypes: [AddressType.solana],\n autoConnect: false, // Disable auto-connect\n});\n\n// Now you must manually call connect() every time\nawait sdk.connect({ provider: \"google\" });\n\n​Auto-connect events\nYou can listen for connection events to update your UI accordingly:\n// Set up event listeners BEFORE autoConnect\nsdk.on(\"connect\", (data) => {\n console.log(\"Connected successfully!\");\n console.log(\"Source:\", data.source); // \"auto-connect\" | \"manual-connect\"\n console.log(\"Provider type:\", data.provider);\n console.log(\"Addresses:\", data.addresses);\n // Update your UI state here\n});\n\nsdk.on(\"connect_error\", (data) => {\n console.log(\"Connection failed:\", data.error);\n console.log(\"Source:\", data.source); // \"auto-connect\" | \"manual-connect\"\n // Show connect button to user\n});\n\n// Auto-connect will trigger events\nawait sdk.autoConnect();\n\n​Handling connection errors\nWhen a connection fails, the connect() promise rejects with an error.\ntry {\n const { addresses } = await sdk.connect({ provider: \"google\" });\n // Connection successful\n console.log(\"Connected addresses:\", addresses);\n} catch (error) {\n // Connection failed (user cancelled, network error, etc)\n console.error(\"Connection failed:\", error);\n}\nWas this page helpful?","tokens":1749,"squid":"spider-10","role":"Tooling Spider","at":1791340987727,"hash":"0ac5d91401001cc6697f06b1b40d34502f8730d6"}
{"url":"https://squidfunk.github.io/mkdocs-material/upgrade/","domain":"squidfunk.github.io","title":"How to upgrade - Material for MkDocs","text":"How to upgrade¶ Upgrade to the latest version with: pip install --upgrade --force-reinstall mkdocs-material\n Show the currently installed version with: pip show mkdocs-material\n Upgrading from 8.x to 9.x¶ This major release includes a brand new search implementation that is faster and allows for rich previews, advanced tokenization and better highlighting. It was available as part of Insiders for over a year, and now that the funding goal was hit, makes its way into the community edition. Changes to mkdocs.yml¶ content.code.copy¶ The copy-to-clipboard buttons are now opt-in and can be enabled or disabled per block. If you wish to enable them for all code blocks, add the following lines to mkdocs.yml: theme:\n features:\n - content.code.copy\n content.action.*¶ A \"view source\" button can be shown next to the \"edit this page\" button, both of which must now be explicitly enabled. Add the following lines to mkdocs.yml: theme:\n features:\n - content.action.edit\n - content.action.view\n navigation.footer¶ The previous and next buttons in the footer are now opt-in. If you wish to keep them for your documentation, add the following lines to mkdocs.yml: theme:\n features:\n - navigation.footer\n theme.language¶ The Korean and Norwegian language codes were renamed, as they were non-standard: kr to ko no to nb feedback.ratings¶ The old, nameless placeholders were removed (after being deprecated for several months). Make sure to switch to the new named placeholders {title} and {url}: https://github.com/.../issues/new/?title=[Feedback]+{title}+-+{url}\n Changes to *.html files¶ The templates have undergone a series of changes. If you have customized Material for MkDocs with theme extension, be sure to incorporate the latest changes into your templates. A good starting point is to inspect the diff. Built-in plugins not working after upgrade? If one of the built-in plugins (search or tags) doesn't work anymore without any apparent error or cause, it is very likely related to custom overrides. MkDocs 1.4.1 and above allow themes to namespace built-in plugins, which Material for MkDocs 9 now does in order to allow authors to use third-party plugins with the same name as built-in plugins. Search your overrides for \"in config.plugins\" and add the material/ namespace. Affected partials: content.html header.html Upgrading from 7.x to 8.x¶ What's new?¶ Added support for code annotations Added support for anchor tracking Added support for version warning Added copyright partial for easier override Removed deprecated content tabs legacy implementation Removed deprecated seealso admonition type Removed deprecated site_keywords setting (unsupported by MkDocs) Removed deprecated prebuilt search index support Removed deprecated web app manifest – use customization Removed extracopyright variable – use new copyright partial Removed Disqus integration – use customization Switched to :is() selectors for simple selector lists Switched autoprefixer from last 4 years to last 2 years Improved CSS overall to match modern standards Improved CSS variable semantics for fonts Improved extensibility by restructuring partials Improved handling of details when printing Improved keyboard navigation for footnotes Fixed #3214: Search highlighting breaks site when empty Changes to mkdocs.yml¶ pymdownx.tabbed¶ Support for the legacy style of the Tabbed extension was dropped in favor of the new, alternate implementation which has better behavior on mobile viewports: 8.x7.x markdown_extensions:\n - pymdownx.tabbed:\n alternate_style: true\n markdown_extensions:\n - pymdownx.tabbed\n pymdownx.superfences¶ The *-experimental suffix must be removed from the custom fence class property, which is used to target code blocks to be rendered as diagrams using Mermaid.js: 8.x7.x markdown_extensions:\n - pymdownx.superfences:\n custom_fences:\n - name: mermaid\n class: mermaid\n format: !!python/name:pymdownx.superfences.fence_code_format\n markdown_extensions:\n - pymdownx.superfences:\n custom_fences:\n - name: mermaid\n class: mermaid-experimental\n format: !!python/name:pymdownx.superfences.fence_code_format\n google_analytics¶ This option was deprecated in MkDocs 1.2.0, as the implementation of a JavaScript-based analytics integration is the responsibility of a theme. The following lines must be changed: 8.x7.x extra:\n analytics:\n provider: google\n property: UA-XXXXXXXX-X\n google_analytics:\n - UA-XXXXXXXX-X\n - auto\n Changes to *.html files¶ The templates have undergone a set of changes to make them future-proof. If you've used theme extension to override a block or template, make sure that it matches the new structure: If you've overridden a block, check base.html for potential changes If you've overridden a template, check the respective *.html file for potential changes base.html partials/copyright.html partials/footer.html partials/social.html @@ -13,11 +13,6 @@\n {% elif config.site_description %}\n <meta name=\"description\" content=\"{{ config.site_description }}\">\n {% endif %}\n- {% if page and page.meta and page.meta.keywords %}\n- <meta name=\"keywords\" content=\"{{ page.meta.keywords }}\">\n- {% elif config.site_keywords %}\n- <meta name=\"keywords\" content=\"{{ config.site_keywords }}\">\n- {% endif %}\n {% if page and page.meta and page.meta.author %}\n <meta name=\"author\" content=\"{{ page.meta.author }}\">\n {% elif config.site_author %}\n@@ -61,15 +56,13 @@\n font.text | replace(' ', '+') + ':300,400,400i,700%7C' +\n font.code | replace(' ', '+')\n }}&display=fallback\">\n- <style>:root{--md-text-font-family:\"{{ font.text }}\";--md-code-font-family:\"{{ font.code }}\"}</style>\n+ <style>:root{--md-text-font:\"{{ font.text }}\";--md-code-font:\"{{ font.code }}\"}</style>\n {% endif %}\n {% endblock %}\n- {% if config.extra.manifest %}\n- <link rel=\"manifest\" href=\"{{ config.extra.manifest | url }}\" crossorigin=\"use-credentials\">\n- {% endif %}\n {% for path in config[\"extra_css\"] %}\n <link rel=\"stylesheet\" href=\"{{ path | url }}\">\n {% endfor %}\n+ {% include \"partials/javascripts/base.html\" %}\n {% block analytics %}\n {% include \"partials/integrations/analytics.html\" %}\n {% endblock %}\n@@ -89,7 +82,6 @@\n <body dir=\"{{ direction }}\">\n {% endif %}\n {% set features = config.theme.features or [] %}\n- {% include \"partials/javascripts/base.html\" %}\n {% if not config.theme.palette is mapping %}\n {% include \"partials/javascripts/palette.html\" %}\n {% endif %}\n@@ -106,13 +98,25 @@\n </div>\n <div data-md-component=\"announce\">\n {% if self.announce() %}\n- <aside class=\"md-banner md-announce\">\n- <div class=\"md-banner__inner md-announce__inner md-grid md-typeset\">\n+ <aside class=\"md-banner\">\n+ <div class=\"md-banner__inner md-grid md-typeset\">\n {% block announce %}{% endblock %}\n </div>\n </aside>\n {% endif %}\n </div>\n+ {% if config.extra.version %}\n+ <div data-md-component=\"outdated\" hidden>\n+ <aside class=\"md-banner md-banner--warning\">\n+ {% if self.outdated() %}\n+ <div class=\"md-banner__inner md-grid md-typeset\">\n+ {% block outdated %}{% endblock %}\n+ </div>\n+ {% include \"partials/javascripts/outdated.html\" %}\n+ {% endif %}\n+ </aside>\n+ </div>\n+ {% endif %}\n {% block header %}\n {% include \"partials/header.html\" %}\n {% endblock %}\n@@ -156,25 +160,7 @@\n <div class=\"md-content\" data-md-component=\"content\">\n <article class=\"md-content__inner md-typeset\">\n {% block content %}\n- {% if page.edit_url %}\n- <a href=\"{{ page.edit_url }}\" title=\"{{ lang.t('edit.link.title') }}\" class=\"md-content__button md-icon\">\n- {% include \".icons/material/pencil.svg\" %}\n- </a>\n- {% endif %}\n- {% if not \"\\x3ch1\" in page.content %}\n- <h1>{{ page.title | d(config.site_name, true)}}</h1>\n- {% endif %}\n- {{ page.content }}\n- {% if page and page.meta %}\n- {% if page.meta.git_revision_date_localized or\n- page.meta.revision_date\n- %}\n- {% include \"partials/source-file.html\" %}\n- {% endif %}\n- {% endif %}\n- {% endblock %}\n- {% block disqus %}\n- {% include \"partials/integrations/disqus.html\" %}\n+ {% include \"partials/content.html\" %}\n {% endblock %}\n </article>\n </div>\n @@ -38,13 +38,6 @@\n <meta name=\"description\" content=\"{{ config.site_description }}\" />\n {% endif %}\n\n- <!-- Page keywords -->\n- {% if page and page.meta and page.meta.keywords %}\n- <meta name=\"keywords\" content=\"{{ page.meta.keywords }}\" />\n- {% elif config.site_keywords %}\n- <meta name=\"keywords\" content=\"{{ config.site_keywords }}\" />\n- {% endif %}\n-\n <!-- Page author -->\n {% if page and page.meta and page.meta.author %}\n <meta name=\"author\" content=\"{{ page.meta.author }}\" />\n@@ -120,27 +113,21 @@\n />\n <style>\n :root {\n- --md-text-font-family: \"{{ font.text }}\";\n- --md-code-font-family: \"{{ font.code }}\";\n+ --md-text-font: \"{{ font.text }}\";\n+ --md-code-font: \"{{ font.code }}\";\n }\n </style>\n {% endif %}\n {% endblock %}\n\n- <!-- Progressive Web App Manifest -->\n- {% if config.extra.manifest %}\n- <link\n- rel=\"manifest\"\n- href=\"{{ config.extra.manifest | url }}\"\n- crossorigin=\"use-credentials\"\n- />\n- {% endif %}\n-\n <!-- Custom style sheets -->\n {% for path in config[\"extra_css\"] %}\n <link rel=\"stylesheet\" href=\"{{ path | url }}\" />\n {% endfor %}\n\n+ <!-- Helper functions for inline scripts -->\n+ {% include \"partials/javascripts/base.html\" %}\n+\n <!-- Analytics -->\n {% block analytics %}\n {% include \"partials/integrations/analytics.html\" %}\n@@ -172,7 +159,6 @@\n\n <!-- Retrieve features from configuration -->\n {% set features = config.theme.features or [] %}\n- {% include \"partials/javascripts/base.html\" %}\n\n <!-- User preference: color palette -->\n {% if not config.theme.palette is mapping %}\n@@ -214,14 +200,28 @@\n <!-- Announcement bar -->\n <div data-md-component=\"announce\">\n {% if self.announce() %}\n- <aside class=\"md-banner md-announce\">\n- <div class=\"md-banner__inner md-announce__inner md-grid md-typeset\">\n+ <aside class=\"md-banner\">\n+ <div class=\"md-banner__inner md-grid md-typeset\">\n {% block announce %}{% endblock %}\n </div>\n </aside>\n {% endif %}\n </div>\n\n+ <!-- Version warning -->\n+ {% if config.extra.version %}\n+ <div data-md-component=\"outdated\" hidden>\n+ <aside class=\"md-banner md-banner--warning\">\n+ {% if self.outdated() %}\n+ <div class=\"md-banner__inner md-grid md-typeset\">\n+ {% block outdated %}{% endblock %}\n+ </div>\n+ {% include \"partials/javascripts/outdated.html\" %}\n+ {% endif %}\n+ </aside>\n+ </div>\n+ {% endif %}\n+\n <!-- Header -->\n {% block header %}\n {% include \"partials/header.html\" %}\n@@ -295,49 +295,11 @@\n {% block content %}\n-\n- <!-- Edit button -->\n- {% if page.edit_url %}\n- <a\n- href=\"{{ page.edit_url }}\"\n- title=\"{{ lang.t('edit.link.title') }}\"\n- class=\"md-content__button md-icon\"\n- >\n- {% include \".icons/material/pencil.svg\" %}\n- </a>\n- {% endif %}\n-\n- <!--\n- Hack: check whether the content contains a h1 headline. If it\n- doesn't, the page title (or respectively site name) is used\n- as the main headline.\n- -->\n- {% if not \"\\x3ch1\" in page.content %}\n- <h1>{{ page.title | d(config.site_name, true)}}</h1>\n- {% endif %}\n-\n- <!-- Markdown content -->\n- {{ page.content }}\n-\n- <!-- Last update of source file -->\n- {% if page and page.meta %}\n- {% if page.meta.git_revision_date_localized or\n- page.meta.revision_date\n- %}\n- {% include \"partials/source-file.html\" %}\n- {% endif %}\n- {% endif %}\n- {% endblock %}\n-\n- <!-- Disqus integration -->\n- {% block disqus %}\n- {% include \"partials/integrations/disqus.html\" %}\n+ {% include \"partials/content.html\" %}\n {% endblock %}\n </article>\n </div>\n @@ -0,0 +1,16 @@\n+{#-\n+ This file was automatically generated - do not edit\n+-#}\n+<div class=\"md-copyright\">\n+ {% if config.copyright %}\n+ <div class=\"md-copyright__highlight\">\n+ {{ config.copyright }}\n+ </div>\n+ {% endif %}\n+ {% if not config.extra.generator == false %}\n+ Made with\n+ <a href=\"https://squidfunk.github.io/mkdocs-material/\" target=\"_blank\" rel=\"noopener\">\n+ Material for MkDocs\n+ </a>\n+ {% endif %}\n+</div>\n @@ -41,21 +40,10 @@\n {% endif %}\n <div class=\"md-footer-meta md-typeset\">\n <div class=\"md-footer-meta__inner md-grid\">\n- <div class=\"md-footer-copyright\">\n- {% if config.copyright %}\n- <div class=\"md-footer-copyright__highlight\">\n- {{ config.copyright }}\n- </div>\n- {% endif %}\n- {% if not config.extra.generator == false %}\n- Made with\n- <a href=\"https://squidfunk.github.io/mkdocs-material/\" target=\"_blank\" rel=\"noopener\">\n- Material for MkDocs\n- </a>\n- {% endif %}\n- {{ extracopyright }}\n- </div>\n- {% include \"partials/social.html\" %}\n+ {% include \"partials/copyright.html\" %}\n+ {% if config.extra.social %}\n+ {% include \"partials/social.html\" %}\n+ {% endif %}\n </div>\n </div>\n </footer>\n @@ -4,17 +4,15 @@\n-{% if config.extra.social %}\n- <div class=\"md-footer-social\">\n- {% for social in config.extra.social %}\n- {% set title = social.name %}\n- {% if not title and \"//\" in social.link %}\n- {% set _,url = social.link.split(\"//\") %}\n- {% set title = url.split(\"/\")[0] %}\n- {% endif %}\n- <a href=\"{{ social.link }}\" target=\"_blank\" rel=\"noopener\" title=\"{{ title | e }}\" class=\"md-footer-social__link\">\n- {% include \".icons/\" ~ social.icon ~ \".svg\" %}\n- </a>\n- {% endfor %}\n- </div>\n-{% endif %}\n+<div class=\"md-social\">\n+ {% for social in config.extra.social %}\n+ {% set title = social.name %}\n+ {% if not title and \"//\" in social.link %}\n+ {% set _, url = social.link.split(\"//\") %}\n+ {% set title = url.split(\"/\")[0] %}\n+ {% endif %}\n+ <a href=\"{{ social.link }}\" target=\"_blank\" rel=\"noopener\" title=\"{{ title | e }}\" class=\"md-social__link\">\n+ {% include \".icons/\" ~ social.icon ~ \".svg\" %}\n+ </a>\n+ {% endfor %}\n+</div>\n Upgrading from 6.x to 7.x¶ What's new?¶ Added support for deploying multiple versions Added support for integrating a language selector Added support for rendering admonitions as inline blocks Rewrite of the underlying reactive architecture Removed Webpack in favor of reactive build strategy (–480 dependencies) Fixed keyboard navigation for code blocks after content tabs switch Changes to mkdocs.yml¶ extra.version.method¶ The versioning method configuration was renamed to extra.version.provider to allow for different versioning strategies in the future: 7.x6.x extra:\n version:\n provider: mike\n extra:\n version:\n method: mike\n Changes to *.html files¶ The templates have undergone a set of changes to make them future-proof. If you've used theme extension to override a block or template, make sure that it matches the new structure: If you've overridden a block, check base.html for potential changes If you've overridden a template, check the respective *.html file for potential changes base.html partials/footer.html partials/header.html partials/source.html partials/toc.html @@ -61,7 +61,7 @@\n font.text | replace(' ', '+') + ':300,400,400i,700%7C' +\n font.code | replace(' ', '+')\n }}&display=fallback\">\n- <style>body,input{font-family:\"{{ font.text }}\",-apple-system,BlinkMacSystemFont,Helvetica,Arial,sans-serif}code,kbd,pre{font-family:\"{{ font.code }}\",SFMono-Regular,Consolas,Menlo,monospace}</style>\n+ <style>:root{--md-text-font-family:\"{{ font.text }}\";--md-code-font-family:\"{{ font.code }}\"}</style>\n {% endif %}\n {% endblock %}\n {% if config.extra.manifest %}\n@@ -131,7 +131,7 @@\n {% if page and page.meta and page.meta.hide %}\n {% set hidden = \"hidden\" if \"navigation\" in page.meta.hide %}\n {% endif %}\n- <div class=\"md-sidebar md-sidebar--primary\" data-md-component=\"navigation\" {{ hidden }}>\n+ <div class=\"md-sidebar md-sidebar--primary\" data-md-component=\"sidebar\" data-md-type=\"navigation\" {{ hidden }}>\n <div class=\"md-sidebar__scrollwrap\">\n <div class=\"md-sidebar__inner\">\n {% include \"partials/nav.html\" %}\n@@ -143,7 +143,7 @@\n {% if page and page.meta and page.meta.hide %}\n {% set hidden = \"hidden\" if \"toc\" in page.meta.hide %}\n {% endif %}\n- <div class=\"md-sidebar md-sidebar--secondary\" data-md-component=\"toc\" {{ hidden }}>\n+ <div class=\"md-sidebar md-sidebar--secondary\" data-md-component=\"sidebar\" data-md-type=\"toc\" {{ hidden }}>\n <div class=\"md-sidebar__scrollwrap\">\n <div class=\"md-sidebar__inner\">\n {% include \"partials/toc.html\" %}\n@@ -152,7 +152,7 @@\n </div>\n {% endif %}\n {% endblock %}\n- <div class=\"md-content\">\n+ <div class=\"md-content\" data-md-component=\"content\">\n <article class=\"md-content__inner md-typeset\">\n {% block content %}\n {% if page.edit_url %}\n@@ -183,10 +183,18 @@\n {% include \"partials/footer.html\" %}\n {% endblock %}\n </div>\n- {% block scripts %}\n- <script src=\"{{ 'assets/javascripts/vendor.18f0862e.min.js' | url }}\"></script>\n- <script src=\"{{ 'assets/javascripts/bundle.994580cf.min.js' | url }}\"></script>\n- {%- set translations = {} -%}\n+ <div class=\"md-dialog\" data-md-component=\"dialog\">\n+ <div class=\"md-dialog__inner md-typeset\"></div>\n+ </div>\n+ {% block config %}\n+ {%- set app = {\n+ \"base\": base_url,\n+ \"features\": features,\n+ \"translations\": {},\n+ \"search\": \"assets/javascripts/workers/search.217ffd95.min.js\" | url,\n+ \"version\": config.extra.version or None\n+ } -%}\n+ {%- set translations = app.translations -%}\n {%- for key in [\n \"clipboard.copy\",\n \"clipboard.copied\",\n@@ -204,19 +212,12 @@\n ] -%}\n {%- set _ = translations.update({ key: lang.t(key) }) -%}\n {%- endfor -%}\n- <script id=\"__lang\" type=\"application/json\">\n- {{- translations | tojson -}}\n- </script>\n- {% block config %}{% endblock %}\n- <script>\n- app = initialize({\n- base: \"{{ base_url }}\",\n- features: {{ features or [] | tojson }},\n- search: Object.assign({\n- worker: \"{{ 'assets/javascripts/worker/search.9c0e82ba.min.js' | url }}\"\n- }, typeof search !== \"undefined\" && search)\n- })\n+ <script id=\"__config\" type=\"application/json\">\n+ {{- app | tojson -}}\n </script>\n+ {% endblock %}\n+ {% block scripts %}\n+ <script src=\"{{ 'assets/javascripts/bundle.926459b3.min.js' | url }}\"></script>\n {% for path in config[\"extra_javascript\"] %}\n <script src=\"{{ path | url }}\"></script>\n {% endfor %}\n - <div class=\"md-footer-nav\">\n- <nav class=\"md-footer-nav__inner md-grid\" aria-label=\"{{ lang.t('footer.title') }}\">\n- {% if page.previous_page %}\n- <a href=\"{{ page.previous_page.url | url }}\" class=\"md-footer-nav__link md-footer-nav__link--prev\" rel=\"prev\">\n- <div class=\"md-footer-nav__button md-icon\">\n- {% include \".icons/material/arrow-left.svg\" %}\n- </div>\n- <div class=\"md-footer-nav__title\">\n- <div class=\"md-ellipsis\">\n- <span class=\"md-footer-nav__direction\">\n- {{ lang.t(\"footer.previous\") }}\n- </span>\n- {{ page.previous_page.title }}\n- </div>\n- </div>\n- </a>\n- {% endif %}\n- {% if page.next_page %}\n- <a href=\"{{ page.next_page.url | url }}\" class=\"md-footer-nav__link md-footer-nav__link--next\" rel=\"next\">\n- <div class=\"md-footer-nav__title\">\n- <div class=\"md-ellipsis\">\n- <span class=\"md-footer-nav__direction\">\n- {{ lang.t(\"footer.next\") }}\n- </span>\n- {{ page.next_page.title }}\n- </div>\n+ <nav class=\"md-footer__inner md-grid\" aria-label=\"{{ lang.t('footer.title') }}\">\n+ {% if page.previous_page %}\n+ <a href=\"{{ page.previous_page.url | url }}\" class=\"md-footer__link md-footer__link--prev\" rel=\"prev\">\n+ <div class=\"md-footer__button md-icon\">\n+ {% include \".icons/material/arrow-left.svg\" %}\n+ </div>\n+ <div class=\"md-footer__title\">\n+ <div class=\"md-ellipsis\">\n+ <span class=\"md-footer__direction\">\n+ {{ lang.t(\"footer.previous\") }}\n+ </span>\n+ {{ page.previous_page.title }}\n </div>\n- <div class=\"md-footer-nav__button md-icon\">\n- {% include \".icons/material/arrow-right.svg\" %}\n+ </div>\n+ </a>\n+ {% endif %}\n+ {% if page.next_page %}\n+ <a href=\"{{ page.next_page.url | url }}\" class=\"md-footer__link md-footer__link--next\" rel=\"next\">\n+ <div class=\"md-footer__title\">\n+ <div class=\"md-ellipsis\">\n+ <span class=\"md-footer__direction\">\n+ {{ lang.t(\"footer.next\") }}\n+ </span>\n+ {{ page.next_page.title }}\n </div>\n- </a>\n- {% endif %}\n- </nav>\n- </div>\n+ </div>\n+ <div class=\"md-footer__button md-icon\">\n+ {% include \".icons/material/arrow-right.svg\" %}\n+ </div>\n+ </a>\n+ {% endif %}\n+ </nav>\n {% endif %}\n <div class=\"md-footer-meta md-typeset\">\n <div class=\"md-footer-meta__inner md-grid\">\n @@ -6,21 +6,21 @@\n {% set site_url = site_url ~ \"/index.html\" %}\n {% endif %}\n <header class=\"md-header\" data-md-component=\"header\">\n- <nav class=\"md-header-nav md-grid\" aria-label=\"{{ lang.t('header.title') }}\">\n- <a href=\"{{ site_url }}\" title=\"{{ config.site_name | e }}\" class=\"md-header-nav__button md-logo\" aria-label=\"{{ config.site_name }}\">\n+ <nav class=\"md-header__inner md-grid\" aria-label=\"{{ lang.t('header.title') }}\">\n+ <a href=\"{{ site_url }}\" title=\"{{ config.site_name | e }}\" class=\"md-header__button md-logo\" aria-label=\"{{ config.site_name }}\">\n {% include \"partials/logo.html\" %}\n </a>\n- <label class=\"md-header-nav__button md-icon\" for=\"__drawer\">\n+ <label class=\"md-header__button md-icon\" for=\"__drawer\">\n {% include \".icons/material/menu\" ~ \".svg\" %}\n </label>\n- <div class=\"md-header-nav__title\" data-md-component=\"header-title\">\n- <div class=\"md-header-nav__ellipsis\">\n- <div class=\"md-header-nav__topic\">\n+ <div class=\"md-header__title\" data-md-component=\"header-title\">\n+ <div class=\"md-header__ellipsis\">\n+ <div class=\"md-header__topic\">\n <span class=\"md-ellipsis\">\n {{ config.site_name }}\n </span>\n </div>\n- <div class=\"md-header-nav__topic\">\n+ <div class=\"md-header__topic\" data-md-component=\"header-topic\">\n <span class=\"md-ellipsis\">\n {% if page and page.meta and page.meta.title %}\n {{ page.meta.title }}\n@@ -31,14 +31,35 @@\n </div>\n </div>\n </div>\n+ <div class=\"md-header__options\">\n+ {% if config.extra.alternate %}\n+ <div class=\"md-select\">\n+ {% set icon = config.theme.icon.alternate or \"material/translate\" %}\n+ <span class=\"md-header__button md-icon\">\n+ {% include \".icons/\" ~ icon ~ \".svg\" %}\n+ </span>\n+ <div class=\"md-select__inner\">\n+ <ul class=\"md-select__list\">\n+ {% for alt in config.extra.alternate %}\n+ <li class=\"md-select__item\">\n+ <a href=\"{{ alt.link | url }}\" class=\"md-select__link\">\n+ {{ alt.name }}\n+ </a>\n+ </li>\n+ {% endfor %}\n+ </ul>\n+ </div>\n+ </div>\n+ {% endif %}\n+ </div>\n {% if \"search\" in config[\"plugins\"] %}\n- <label class=\"md-header-nav__button md-icon\" for=\"__search\">\n+ <label class=\"md-header__button md-icon\" for=\"__search\">\n {% include \".icons/material/magnify.svg\" %}\n </label>\n {% include \"partials/search.html\" %}\n {% endif %}\n {% if config.repo_url %}\n- <div class=\"md-header-nav__source\">\n+ <div class=\"md-header__source\">\n {% include \"partials/source.html\" %}\n </div>\n {% endif %}\n @@ -4,5 +4,5 @@\n {% import \"partials/language.html\" as lang with context %}\n-<a href=\"{{ config.repo_url }}\" title=\"{{ lang.t('source.link.title') }}\" class=\"md-source\">\n+<a href=\"{{ config.repo_url }}\" title=\"{{ lang.t('source.link.title') }}\" class=\"md-source\" data-md-component=\"source\">\n <div class=\"md-source__icon md-icon\">\n {% set icon = config.theme.icon.repo or \"fontawesome/brands/git-alt\" %}\n {% include \".icons/\" ~ icon ~ \".svg\" %}\n @@ -12,7 +12,7 @@\n <span class=\"md-nav__icon md-icon\"></span>\n {{ lang.t(\"toc.title\") }}\n </label>\n- <ul class=\"md-nav__list\" data-md-scrollfix>\n+ <ul class=\"md-nav__list\" data-md-component=\"toc\" data-md-scrollfix>\n {% for toc_item in toc %}\n {% include \"partials/toc-item.html\" %}\n {% endfor %}\n Upgrading from 5.x to 6.x¶ What's new?¶ Improved search result look and feel Improved search result stability while typing Improved search result grouping (pages + headings) Improved search result relevance and scoring Added display of missing query terms to search results Reduced size of vendor bundle by 25% (84kb → 67kb) Reduced size of the Docker image to improve CI build performance Removed hero partial in favor of custom implementation Removed deprecated front matter features Changes to mkdocs.yml¶ Following is a list of changes that need to be made to mkdocs.yml. Note that you only have to adjust the value if you defined it, so if your configuration does not contain the key, you can skip it. theme.features¶ All feature flags that can be set from mkdocs.yml, like tabs and instant loading, are now prefixed with the name of the component or function they apply to, e.g. navigation.*: 6.x5.x theme:\n features:\n - navigation.tabs\n - navigation.instant\n theme:\n features:\n - tabs\n - instant\n Changes to *.html files¶ The templates have undergone a set of changes to make them future-proof. If you've used theme extension to override a block or template, make sure that it matches the new structure: If you've overridden a block, check base.html for potential changes If you've overridden a template, check the respective *.html file for potential changes base.html partials/hero.html partials/source-link @@ -22,13 +22,6 @@\n\n {% import \"partials/language.html\" as lang with context %}\n\n-<!-- Theme options -->\n-{% set palette = config.theme.palette %}\n-{% if not palette is mapping %}\n- {% set palette = palette | first %}\n-{% endif %}\n-{% set font = config.theme.font %}\n-\n <!doctype html>\n <html lang=\"{{ lang.t('language') }}\" class=\"no-js\">\n <head>\n@@ -45,21 +38,8 @@\n <meta name=\"description\" content=\"{{ config.site_description }}\" />\n {% endif %}\n\n- <!-- Redirect -->\n- {% if page and page.meta and page.meta.redirect %}\n- <script>\n- var anchor = window.location.hash.substr(1)\n- location.href = '{{ page.meta.redirect }}' +\n- (anchor ? '#' + anchor : '')\n- </script>\n-\n- <!-- Fallback in case JavaScript is not available -->\n- <meta http-equiv=\"refresh\" content=\"0; url={{ page.meta.redirect }}\" />\n- <meta name=\"robots\" content=\"noindex\" />\n- <link rel=\"canonical\" href=\"{{ page.meta.redirect }}\" />\n-\n <!-- Canonical -->\n- {% elif page.canonical_url %}\n+ {% if page.canonical_url %}\n <link rel=\"canonical\" href=\"{{ page.canonical_url }}\" />\n {% endif %}\n\n@@ -96,20 +76,21 @@\n <link rel=\"stylesheet\" href=\"{{ 'assets/stylesheets/main.css' | url }}\" />\n\n <!-- Extra color palette -->\n- {% if palette.scheme or palette.primary or palette.accent %}\n+ {% if config.theme.palette %}\n+ {% set palette = config.theme.palette %}\n <link\n rel=\"stylesheet\"\n href=\"{{ 'assets/stylesheets/palette.css' | url }}\"\n />\n- {% endif %}\n\n- <!-- Theme-color meta tag for Android -->\n- {% if palette.primary %}\n- {% import \"partials/palette.html\" as map %}\n- {% set primary = map.primary(\n- palette.primary | replace(\" \", \"-\") | lower\n- ) %}\n- <meta name=\"theme-color\" content=\"{{ primary }}\" />\n+ <!-- Theme-color meta tag for Android -->\n+ {% if palette.primary %}\n+ {% import \"partials/palette.html\" as map %}\n+ {% set primary = map.primary(\n+ palette.primary | replace(\" \", \"-\") | lower\n+ ) %}\n+ <meta name=\"theme-color\" content=\"{{ primary }}\" />\n+ {% endif %}\n {% endif %}\n {% endblock %}\n\n@@ -120,7 +101,8 @@\n {% block fonts %}\n\n <!-- Load fonts from Google -->\n- {% if font != false %}\n+ {% if config.theme.font != false %}\n+ {% set font = config.theme.font %}\n <link href=\"https://fonts.gstatic.com\" rel=\"preconnect\" crossorigin />\n <link\n rel=\"stylesheet\"\n@@ -169,8 +151,12 @@\n\n <!-- Text direction and color palette, if defined -->\n {% set direction = config.theme.direction or lang.t('direction') %}\n- {% if palette.scheme or palette.primary or palette.accent %}\n- {% set scheme = palette.scheme | lower %}\n+ {% if config.theme.palette %}\n+ {% set palette = config.theme.palette %}\n+ {% if not palette is mapping %}\n+ {% set palette = palette | first %}\n+ {% endif %}\n+ {% set scheme = palette.scheme | replace(\" \", \"-\") | lower %}\n {% set primary = palette.primary | replace(\" \", \"-\") | lower %}\n {% set accent = palette.accent | replace(\" \", \"-\") | lower %}\n <body\n@@ -179,18 +165,19 @@\n data-md-color-primary=\"{{ primary }}\"\n data-md-color-accent=\"{{ accent }}\"\n >\n+\n+ <!-- Experimental: set color scheme based on preference -->\n+ {% if \"preference\" == scheme %}\n+ <script>\n+ if (matchMedia(\"(prefers-color-scheme: dark)\").matches)\n+ document.body.setAttribute(\"data-md-color-scheme\", \"slate\")\n+ </script>\n+ {% endif %}\n+\n {% else %}\n <body dir=\"{{ direction }}\">\n {% endif %}\n\n- <!-- Experimental: set color scheme based on preference -->\n- {% if \"preference\" == palette.scheme %}\n- <script>\n- if (matchMedia(\"(prefers-color-scheme: dark)\").matches)\n- document.body.setAttribute(\"data-md-color-scheme\", \"slate\")\n- </script>\n- {% endif %}\n-\n <!--\n State toggles - we need to set autocomplete=\"off\" in order to reset the\n drawer on back button invocation in some browsers\n@@ -243,15 +230,11 @@\n <div class=\"md-container\" data-md-component=\"container\">\n\n <!-- Hero teaser -->\n- {% block hero %}\n- {% if page and page.meta and page.meta.hero %}\n- {% include \"partials/hero.html\" with context %}\n- {% endif %}\n- {% endblock %}\n+ {% block hero %}{% endblock %}\n\n <!-- Tabs navigation -->\n {% block tabs %}\n- {% if \"tabs\" in config.theme.features %}\n+ {% if \"navigation.tabs\" in config.theme.features %}\n {% include \"partials/tabs.html\" %}\n {% endif %}\n {% endblock %}\n@@ -310,13 +293,6 @@\n </a>\n {% endif %}\n\n- <!-- Link to source file -->\n- {% block source %}\n- {% if page and page.meta and page.meta.source %}\n- {% include \"partials/source-link.html\" %}\n- {% endif %}\n- {% endblock %}\n-\n <!--\n Hack: check whether the content contains a h1 headline. If it\n doesn't, the page title (or respectively site name) is used\n@@ -370,7 +346,10 @@\n \"search.result.placeholder\",\n \"search.result.none\",\n \"search.result.one\",\n- \"search.result.other\"\n+ \"search.result.other\",\n+ \"search.result.more.one\",\n+ \"search.result.more.other\",\n+ \"search.result.term.missing\"\n ] -%}\n {%- set _ = translations.update({ key: lang.t(key) }) -%}\n {%- endfor -%}\n @@ -1,12 +0,0 @@\n-{#-\n- This file was automatically generated - do not edit\n--#}\n-{% set class = \"md-hero\" %}\n-{% if \"tabs\" not in config.theme.features %}\n- {% set class = \"md-hero md-hero--expand\" %}\n-{% endif %}\n-<div class=\"{{ class }}\" data-md-component=\"hero\">\n- <div class=\"md-hero__inner md-grid\">\n- {{ page.meta.hero }}\n- </div>\n-</div>\n @@ -1,14 +0,0 @@\n-{#-\n- This file was automatically generated - do not edit\n--#}\n-{% import \"partials/language.html\" as lang with context %}\n-{% set repo = config.repo_url %}\n-{% if repo | last == \"/\" %}\n- {% set repo = repo[:-1] %}\n-{% endif %}\n-{% set path = page.meta.path | default(\"\") %}\n-<a href=\"{{ [repo, path, page.meta.source] | join('/') }}\" title=\"{{ page.meta.source }}\" class=\"md-content__button md-icon\">\n- {{ lang.t(\"meta.source\") }}\n- {% set icon = config.theme.icon.repo or \"fontawesome/brands/git-alt\" %}\n- {% include \".icons/\" ~ icon ~ \".svg\" %}\n-</a>\n Upgrading from 4.x to 5.x¶ What's new?¶ Reactive architecture – try app.dialog$.next(\"Hi!\") in the console Instant loading – make Material behave like a Single Page Application Improved CSS customization with CSS variables – set your brand's colors Improved CSS resilience, e.g. proper sidebar locking for customized headers Improved icon integration and configuration – now including over 5k icons Added possibility to use any icon for logo, repository and social links Search UI does not freeze anymore (moved to web worker) Search index built only once when using instant loading Improved extensible keyboard handling Support for prebuilt search indexes Support for displaying stars and forks for GitLab repositories Support for scroll snapping of sidebars and search results Reduced HTML and CSS footprint due to deprecation of Internet Explorer support Slight facelifting of some UI elements (admonitions, tables, ...) Changes to mkdocs.yml¶ Following is a list of changes that need to be made to mkdocs.yml. Note that you only have to adjust the value if you defined it, so if your configuration does not contain the key, you can skip it. theme.feature¶ Optional features like tabs and instant loading are now implemented as flags and can be enabled by listing them in mkdocs.yml under theme.features: 5.x4.x theme:\n features:\n - tabs\n - instant\n theme:\n feature:\n tabs: true\n theme.logo.icon¶ The logo icon configuration was centralized under theme.icon.logo and can now be set to any of the icons bundled with the theme: 5.x4.x theme:\n icon:\n logo: material/cloud\n theme:\n logo:\n icon: cloud\n extra.repo_icon¶ The repo icon configuration was centralized under theme.icon.repo and can now be set to any of the icons bundled with the theme: 5.x4.x theme:\n icon:\n repo: fontawesome/brands/gitlab\n extra:\n repo_icon: gitlab\n extra.search.*¶ Search is now configured as part of the plugin options. Note that the search languages must now be listed as an array of strings and the tokenizer was renamed to separator: 5.x4.x plugins:\n - search:\n separator: '[\\s\\-\\.]+'\n lang:\n - en\n - de\n - ru\n extra:\n search:\n language: en, de, ru\n tokenizer: '[\\s\\-\\.]+'\n extra.social.*¶ Social links stayed in the same place, but the type key was renamed to icon in order to match the new way of specifying which icon to be used: 5.x4.x extra:\n social:\n - icon: fontawesome/brands/github-alt\n link: https://github.com/squidfunk\n extra:\n social:\n - type: github\n link: https://github.com/squidfunk\n Changes to *.html files¶ The templates have undergone a set of changes to make them future-proof. If you've used theme extension to override a block or template, make sure that it matches the new structure: If you've overridden a block, check base.html for potential changes If you've overridden a template, check the respective *.html file for potential changes base.html partials/footer.html partials/header.html partials/hero.html partials/language.html partials/logo.html partials/nav-item.html partials/nav.html partials/search.html partials/social.html partials/source-date.html partials/source-link.html partials/source.html partials/tabs-item.html partials/tabs.html partials/toc-item.html partials/toc.html @@ -4,7 +4,6 @@\n {% import \"partials/language.html\" as lang with context %}\n-{% set feature = config.theme.feature %}\n {% set palette = config.theme.palette %}\n {% set font = config.theme.font %}\n <!doctype html>\n@@ -30,19 +29,6 @@\n {% elif config.site_author %}\n <meta name=\"author\" content=\"{{ config.site_author }}\">\n {% endif %}\n- {% for key in [\n- \"clipboard.copy\",\n- \"clipboard.copied\",\n- \"search.language\",\n- \"search.pipeline.stopwords\",\n- \"search.pipeline.trimmer\",\n- \"search.result.none\",\n- \"search.result.one\",\n- \"search.result.other\",\n- \"search.tokenizer\"\n- ] %}\n- <meta name=\"lang:{{ key }}\" content=\"{{ lang.t(key) }}\">\n- {% endfor %}\n <link rel=\"shortcut icon\" href=\"{{ config.theme.favicon | url }}\">\n <meta name=\"generator\" content=\"mkdocs-{{ mkdocs_version }}, mkdocs-material-5.0.0\">\n {% endblock %}\n@@ -56,9 +42,9 @@\n {% endif %}\n {% endblock %}\n {% block styles %}\n- <link rel=\"stylesheet\" href=\"{{ 'assets/stylesheets/application.********.css' | url }}\">\n+ <link rel=\"stylesheet\" href=\"{{ 'assets/stylesheets/main.********.min.css' | url }}\">\n {% if palette.primary or palette.accent %}\n- <link rel=\"stylesheet\" href=\"{{ 'assets/stylesheets/application-palette.********.css' | url }}\">\n+ <link rel=\"stylesheet\" href=\"{{ 'assets/stylesheets/palette.********.min.css' | url }}\">\n {% endif %}\n {% if palette.primary %}\n {% import \"partials/palette.html\" as map %}\n@@ -69,20 +55,17 @@\n {% endif %}\n {% endblock %}\n {% block libs %}\n- <script src=\"{{ 'assets/javascripts/modernizr.********.js' | url }}\"></script>\n {% endblock %}\n {% block fonts %}\n {% if font != false %}\n <link href=\"https://fonts.gstatic.com\" rel=\"preconnect\" crossorigin>\n <link rel=\"stylesheet\" href=\"https://fonts.googleapis.com/css?family={{\n font.text | replace(' ', '+') + ':300,400,400i,700%7C' +\n font.code | replace(' ', '+')\n }}&display=fallback\">\n <style>body,input{font-family:\"{{ font.text }}\",\"Helvetica Neue\",Helvetica,Arial,sans-serif}code,kbd,pre{font-family:\"{{ font.code }}\",\"Courier New\",Courier,monospace}</style>\n {% endif %}\n {% endblock %}\n- <link rel=\"stylesheet\" href=\"{{ 'assets/fonts/material-icons.css' | url }}\">\n {% if config.extra.manifest %}\n <link rel=\"manifest\" href=\"{{ config.extra.manifest | url }}\" crossorigin=\"use-credentials\">\n {% endif %}\n@@ -95,47 +77,50 @@\n {% endblock %}\n {% block extrahead %}{% endblock %}\n </head>\n+ {% set direction = config.theme.direction | default(lang.t('direction')) %}\n {% if palette.primary or palette.accent %}\n {% set primary = palette.primary | replace(\" \", \"-\") | lower %}\n {% set accent = palette.accent | replace(\" \", \"-\") | lower %}\n- <body dir=\"{{ lang.t('direction') }}\" data-md-color-primary=\"{{ primary }}\" data-md-color-accent=\"{{ accent }}\">\n+ <body dir=\"{{ direction }}\" data-md-color-primary=\"{{ primary }}\" data-md-color-accent=\"{{ accent }}\">\n {% else %}\n- <body dir=\"{{ lang.t('direction') }}\">\n+ <body dir=\"{{ direction }}\">\n {% endif %}\n- <svg class=\"md-svg\">\n- <defs>\n- {% set platform = config.extra.repo_icon or config.repo_url %}\n- {% if \"github\" in platform %}\n- {% include \"assets/images/icons/github.f0b8504a.svg\" %}\n- {% elif \"gitlab\" in platform %}\n- {% include \"assets/images/icons/gitlab.6dd19c00.svg\" %}\n- {% elif \"bitbucket\" in platform %}\n- {% include \"assets/images/icons/bitbucket.1b09e088.svg\" %}\n- {% endif %}\n- </defs>\n- </svg>\n <input class=\"md-toggle\" data-md-toggle=\"drawer\" type=\"checkbox\" id=\"__drawer\" autocomplete=\"off\">\n <input class=\"md-toggle\" data-md-toggle=\"search\" type=\"checkbox\" id=\"__search\" autocomplete=\"off\">\n- <label class=\"md-overlay\" data-md-component=\"overlay\" for=\"__drawer\"></label>\n+ <label class=\"md-overlay\" for=\"__drawer\"></label>\n+ <div data-md-component=\"skip\">\n+ {% if page.toc | first is defined %}\n+ {% set skip = page.toc | first %}\n+ <a href=\"{{ skip.url | url }}\" class=\"md-skip\">\n+ {{ lang.t('skip.link.title') }}\n+ </a>\n+ {% endif %}\n+ </div>\n+ <div data-md-component=\"announce\">\n+ {% if self.announce() %}\n+ <aside class=\"md-announce\">\n+ <div class=\"md-announce__inner md-grid md-typeset\">\n+ {% block announce %}{% endblock %}\n+ </div>\n+ </aside>\n+ {% endif %}\n+ </div>\n {% block header %}\n {% include \"partials/header.html\" %}\n {% endblock %}\n- <div class=\"md-container\">\n+ <div class=\"md-container\" data-md-component=\"container\">\n {% block hero %}\n {% if page and page.meta and page.meta.hero %}\n {% include \"partials/hero.html\" with context %}\n {% endif %}\n {% endblock %}\n- {% if feature.tabs %}\n- {% include \"partials/tabs.html\" %}\n- {% endif %}\n+ {% block tabs %}\n+ {% if \"tabs\" in config.theme.features %}\n+ {% include \"partials/tabs.html\" %}\n+ {% endif %}\n+ {% endblock %}\n- <main class=\"md-main\" role=\"main\">\n- <div class=\"md-main__inner md-grid\" data-md-component=\"container\">\n+ <main class=\"md-main\" data-md-component=\"main\">\n+ <div class=\"md-main__inner md-grid\">\n {% block site_nav %}\n {% if nav %}\n <div class=\"md-sidebar md-sidebar--primary\" data-md-component=\"navigation\">\n@@ -160,41 +141,25 @@\n <article class=\"md-content__inner md-typeset\">\n {% block content %}\n {% if page.edit_url %}\n- <a href=\"{{ page.edit_url }}\" title=\"{{ lang.t('edit.link.title') }}\" class=\"md-icon md-content__icon\">&#xE3C9;</a>\n+ <a href=\"{{ page.edit_url }}\" title=\"{{ lang.t('edit.link.title') }}\" class=\"md-content__button md-icon\">\n+ {% include \".icons/material/pencil.svg\" %}\n+ </a>\n {% endif %}\n+ {% block source %}\n+ {% if page and page.meta and page.meta.source %}\n+ {% include \"partials/source-link.html\" %}\n+ {% endif %}\n+ {% endblock %}\n {% if not \"\\x3ch1\" in page.content %}\n <h1>{{ page.title | default(config.site_name, true)}}</h1>\n {% endif %}\n {{ page.content }}\n- {% block source %}\n- {% if page and page.meta and page.meta.source %}\n- <h2 id=\"__source\">{{ lang.t(\"meta.source\") }}</h2>\n- {% set repo = config.repo_url %}\n- {% if repo | last == \"/\" %}\n- {% set repo = repo[:-1] %}\n- {% endif %}\n- {% set path = page.meta.path | default([\"\"]) %}\n- {% set file = page.meta.source %}\n- <a href=\"{{ [repo, path, file] | join('/') }}\" title=\"{{ file }}\" class=\"md-source-file\">\n- {{ file }}\n- </a>\n- {% endif %}\n- {% endblock %}\n+ {% if page and page.meta %}\n+ {% if page.meta.git_revision_date_localized or\n+ page.meta.revision_date\n+ %}\n+ {% include \"partials/source-date.html\" %}\n- {% if page and page.meta and (\n- page.meta.git_revision_date_localized or\n- page.meta.revision_date\n- ) %}\n- {% set label = lang.t(\"source.revision.date\") %}\n- <hr>\n- <div class=\"md-source-date\">\n- <small>\n- {% if page.meta.git_revision_date_localized %}\n- {{ label }}: {{ page.meta.git_revision_date_localized }}\n- {% elif page.meta.revision_date %}\n- {{ label }}: {{ page.meta.revision_date }}\n- {% endif %}\n- </small>\n- </div>\n {% endif %}\n {% endblock %}\n {% block disqus %}\n@@ -208,29 +174,35 @@\n {% include \"partials/footer.html\" %}\n {% endblock %}\n </div>\n {% block scripts %}\n- <script src=\"{{ 'assets/javascripts/application.********.js' | url }}\"></script>\n- {% if lang.t(\"search.language\") != \"en\" %}\n- {% set languages = lang.t(\"search.language\").split(\",\") %}\n- {% if languages | length and languages[0] != \"\" %}\n- {% set path = \"assets/javascripts/lunr/\" %}\n- <script src=\"{{ (path ~ 'lunr.stemmer.support.js') | url }}\"></script>\n- {% for language in languages | map(\"trim\") %}\n- {% if language != \"en\" %}\n- {% if language == \"ja\" %}\n- <script src=\"{{ (path ~ 'tinyseg.js') | url }}\"></script>\n- {% endif %}\n- {% if language in (\"ar\", \"da\", \"de\", \"es\", \"fi\", \"fr\", \"hu\", \"it\", \"ja\", \"nl\", \"no\", \"pt\", \"ro\", \"ru\", \"sv\", \"th\", \"tr\", \"vi\") %}\n- <script src=\"{{ (path ~ 'lunr.' ~ language ~ '.js') | url }}\"></script>\n- {% endif %}\n- {% endif %}\n- {% endfor %}\n- {% if languages | length > 1 %}\n- <script src=\"{{ (path ~ 'lunr.multi.js') | url }}\"></script>\n- {% endif %}\n- {% endif %}\n- {% endif %}\n- <script>app.initialize({version:\"{{ mkdocs_version }}\",url:{base:\"{{ base_url }}\"}})</script>\n+ <script src=\"{{ 'assets/javascripts/vendor.********.min.js' | url }}\"></script>\n+ <script src=\"{{ 'assets/javascripts/bundle.********.min.js' | url }}\"></script>\n+ {%- set translations = {} -%}\n+ {%- for key in [\n+ \"clipboard.copy\",\n+ \"clipboard.copied\",\n+ \"search.config.lang\",\n+ \"search.config.pipeline\",\n+ \"search.config.separator\",\n+ \"search.result.placeholder\",\n+ \"search.result.none\",\n+ \"search.result.one\",\n+ \"search.result.other\"\n+ ] -%}\n+ {%- set _ = translations.update({ key: lang.t(key) }) -%}\n+ {%- endfor -%}\n+ <script id=\"__lang\" type=\"application/json\">\n+ {{- translations | tojson -}}\n+ </script>\n+ {% block config %}{% endblock %}\n+ <script>\n+ app = initialize({\n+ base: \"{{ base_url }}\",\n+ features: {{ config.theme.features | tojson }},\n+ search: Object.assign({\n+ worker: \"{{ 'assets/javascripts/worker/search.********.min.js' | url }}\"\n+ }, typeof search !== \"undefined\" && search)\n+ })\n+ </script>\n {% for path in config[\"extra_javascript\"] %}\n <script src=\"{{ path | url }}\"></script>\n {% endfor %}\n @@ -5,34 +5,34 @@\n <div class=\"md-footer-nav\">\n- <nav class=\"md-footer-nav__inner md-grid\">\n+ <nav class=\"md-footer-nav__inner md-grid\" aria-label=\"{{ lang.t('footer.title') }}\">\n {% if page.previous_page %}\n- <a href=\"{{ page.previous_page.url | url }}\" title=\"{{ page.previous_page.title | striptags }}\" class=\"md-flex md-footer-nav__link md-footer-nav__link--prev\" rel=\"prev\">\n- <div class=\"md-flex__cell md-flex__cell--shrink\">\n- <i class=\"md-icon md-icon--arrow-back md-footer-nav__button\"></i>\n+ <a href=\"{{ page.previous_page.url | url }}\" title=\"{{ page.previous_page.title | striptags }}\" class=\"md-footer-nav__link md-footer-nav__link--prev\" rel=\"prev\">\n+ <div class=\"md-footer-nav__button md-icon\">\n+ {% include \".icons/material/arrow-left.svg\" %}\n </div>\n- <div class=\"md-flex__cell md-flex__cell--stretch md-footer-nav__title\">\n- <span class=\"md-flex__ellipsis\">\n+ <div class=\"md-footer-nav__title\">\n+ <div class=\"md-ellipsis\">\n <span class=\"md-footer-nav__direction\">\n {{ lang.t(\"footer.previous\") }}\n </span>\n {{ page.previous_page.title }}\n- </span>\n+ </div>\n </div>\n </a>\n {% endif %}\n {% if page.next_page %}\n- <a href=\"{{ page.next_page.url | url }}\" title=\"{{ page.next_page.title | striptags }}\" class=\"md-flex md-footer-nav__link md-footer-nav__link--next\" rel=\"next\">\n- <div class=\"md-flex__cell md-flex__cell--stretch md-footer-nav__title\">\n- <span class=\"md-flex__ellipsis\">\n+ <a href=\"{{ page.next_page.url | url }}\" title=\"{{ page.next_page.title | striptags }}\" class=\"md-footer-nav__link md-footer-nav__link--next\" rel=\"next\">\n+ <div class=\"md-footer-nav__title\">\n+ <div class=\"md-ellipsis\">\n <span class=\"md-footer-nav__direction\">\n {{ lang.t(\"footer.next\") }}\n </span>\n {{ page.next_page.title }}\n- </span>\n+ </div>\n </div>\n- <div class=\"md-flex__cell md-flex__cell--shrink\">\n- <i class=\"md-icon md-icon--arrow-forward md-footer-nav__button\"></i>\n+ <div class=\"md-footer-nav__button md-icon\">\n+ {% include \".icons/material/arrow-right.svg\" %}\n </div>\n </a>\n {% endif %}\n @@ -4,51 +4,43 @@\n <header class=\"md-header\" data-md-component=\"header\">\n- <nav class=\"md-header-nav md-grid\">\n- <div class=\"md-flex\">\n- <div class=\"md-flex__cell md-flex__cell--shrink\">\n- <a href=\"{{ config.site_url | default(nav.homepage.url, true) | url }}\" title=\"{{ config.site_name }}\" aria-label=\"{{ config.site_name }}\" class=\"md-header-nav__button md-logo\">\n- {% if config.theme.logo.icon %}\n- <i class=\"md-icon\">{{ config.theme.logo.icon }}</i>\n- {% else %}\n- <img alt=\"logo\" src=\"{{ config.theme.logo | url }}\" width=\"24\" height=\"24\">\n- {% endif %}\n- </a>\n- </div>\n- <div class=\"md-flex__cell md-flex__cell--shrink\">\n- <label class=\"md-icon md-icon--menu md-header-nav__button\" for=\"__drawer\"></label>\n- </div>\n- <div class=\"md-flex__cell md-flex__cell--stretch\">\n- <div class=\"md-flex__ellipsis md-header-nav__title\" data-md-component=\"title\">\n- {% if config.site_name == page.title %}\n- {{ config.site_name }}\n- {% else %}\n- <span class=\"md-header-nav__topic\">\n- {{ config.site_name }}\n- </span>\n- <span class=\"md-header-nav__topic\">\n- {% if page and page.meta and page.meta.title %}\n- {{ page.meta.title }}\n- {% else %}\n- {{ page.title }}\n- {% endif %}\n- </span>\n- {% endif %}\n+ <nav class=\"md-header-nav md-grid\" aria-label=\"{{ lang.t('header.title') }}\">\n+ <a href=\"{{ config.site_url | default(nav.homepage.url, true) | url }}\" title=\"{{ config.site_name }}\" class=\"md-header-nav__button md-logo\" aria-label=\"{{ config.site_name }}\">\n+ {% include \"partials/logo.html\" %}\n+ </a>\n+ <label class=\"md-header-nav__button md-icon\" for=\"__drawer\">\n+ {% include \".icons/material/menu\" ~ \".svg\" %}\n+ </label>\n+ <div class=\"md-header-nav__title\" data-md-component=\"header-title\">\n+ {% if config.site_name == page.title %}\n+ <div class=\"md-header-nav__ellipsis md-ellipsis\">\n+ {{ config.site_name }}\n </div>\n- </div>\n- <div class=\"md-flex__cell md-flex__cell--shrink\">\n- {% if \"search\" in config[\"plugins\"] %}\n- <label class=\"md-icon md-icon--search md-header-nav__button\" for=\"__search\"></label>\n- {% include \"partials/search.html\" %}\n- {% endif %}\n- </div>\n- {% if config.repo_url %}\n- <div class=\"md-flex__cell md-flex__cell--shrink\">\n- <div class=\"md-header-nav__source\">\n- {% include \"partials/source.html\" %}\n- </div>\n+ {% else %}\n+ <div class=\"md-header-nav__ellipsis\">\n+ <span class=\"md-header-nav__topic md-ellipsis\">\n+ {{ config.site_name }}\n+ </span>\n+ <span class=\"md-header-nav__topic md-ellipsis\">\n+ {% if page and page.meta and page.meta.title %}\n+ {{ page.meta.title }}\n+ {% else %}\n+ {{ page.title }}\n+ {% endif %}\n+ </span>\n </div>\n {% endif %}\n </div>\n+ {% if \"search\" in config[\"plugins\"] %}\n+ <label class=\"md-header-nav__button md-icon\" for=\"__search\">\n+ {% include \".icons/material/magnify.svg\" %}\n+ </label>\n+ {% include \"partials/search.html\" %}\n+ {% endif %}\n+ {% if config.repo_url %}\n+ <div class=\"md-header-nav__source\">\n+ {% include \"partials/source.html\" %}\n+ </div>\n+ {% endif %}\n </nav>\n </header>\n @@ -4,9 +4,8 @@\n-{% set feature = config.theme.feature %}\n {% set class = \"md-hero\" %}\n-{% if not feature.tabs %}\n+{% if \"tabs\" not in config.theme.features %}\n {% set class = \"md-hero md-hero--expand\" %}\n {% endif %}\n <div class=\"{{ class }}\" data-md-component=\"hero\">\n @@ -4,12 +4,4 @@\n {% import \"partials/language/\" + config.theme.language + \".html\" as lang %}\n {% import \"partials/language/en.html\" as fallback %}\n-{% macro t(key) %}{{ {\n- \"direction\": config.theme.direction,\n- \"search.language\": (\n- config.extra.search | default({})\n- ).language,\n- \"search.tokenizer\": (\n- config.extra.search | default({})\n- ).tokenizer | default(\"\", true),\n-}[key] or lang.t(key) or fallback.t(key) }}{% endmacro %}\n+{% macro t(key) %}{{ lang.t(key) | default(fallback.t(key)) }}{% endmacro %}\n @@ -0,0 +1,9 @@\n+{#-\n+ This file was automatically generated - do not edit\n+-#}\n+{% if config.theme.logo %}\n+ <img src=\"{{ config.theme.logo | url }}\" alt=\"logo\">\n+{% else %}\n+ {% set icon = config.theme.icon.logo or \"material/library\" %}\n+ {% include \".icons/\" ~ icon ~ \".svg\" %}\n+{% endif %}\n @@ -14,9 +14,15 @@\n {% endif %}\n <label class=\"md-nav__link\" for=\"{{ path }}\">\n {{ nav_item.title }}\n+ <span class=\"md-nav__icon md-icon\">\n+ {% include \".icons/material/chevron-right.svg\" %}\n+ </span>\n </label>\n- <nav class=\"md-nav\" data-md-component=\"collapsible\" data-md-level=\"{{ level }}\">\n+ <nav class=\"md-nav\" aria-label=\"{{ nav_item.title }}\" data-md-level=\"{{ level }}\">\n <label class=\"md-nav__title\" for=\"{{ path }}\">\n+ <span class=\"md-nav__icon md-icon\">\n+ {% include \".icons/material/arrow-left.svg\" %}\n+ </span>\n {{ nav_item.title }}\n </label>\n <ul class=\"md-nav__list\" data-md-scrollfix>\n@@ -39,6 +45,9 @@\n {% if toc | first is defined %}\n <label class=\"md-nav__link md-nav__link--active\" for=\"__toc\">\n {{ nav_item.title }}\n+ <span class=\"md-nav__icon md-icon\">\n+ {% include \".icons/material/table-of-contents.svg\" %}\n+ </span>\n </label>\n {% endif %}\n <a href=\"{{ nav_item.url | url }}\" title=\"{{ nav_item.title | striptags }}\" class=\"md-nav__link md-nav__link--active\">\n @@ -4,14 +4,10 @@\n-<nav class=\"md-nav md-nav--primary\" data-md-level=\"0\">\n- <label class=\"md-nav__title md-nav__title--site\" for=\"__drawer\">\n- <a href=\"{{ config.site_url | default(nav.homepage.url, true) | url }}\" title=\"{{ config.site_name }}\" class=\"md-nav__button md-logo\">\n- {% if config.theme.logo.icon %}\n- <i class=\"md-icon\">{{ config.theme.logo.icon }}</i>\n- {% else %}\n- <img alt=\"logo\" src=\"{{ config.theme.logo | url }}\" width=\"48\" height=\"48\">\n- {% endif %}\n+<nav class=\"md-nav md-nav--primary\" aria-label=\"{{ lang.t('nav.title') }}\" data-md-level=\"0\">\n+ <label class=\"md-nav__title\" for=\"__drawer\">\n+ <a href=\"{{ config.site_url | default(nav.homepage.url, true) | url }}\" title=\"{{ config.site_name }}\" class=\"md-nav__button md-logo\" aria-label=\"{{ config.site_name }}\">\n+ {% include \"partials/logo.html\" %}\n </a>\n {{ config.site_name }}\n </label>\n @@ -6,15 +6,18 @@\n <label class=\"md-search__overlay\" for=\"__search\"></label>\n <div class=\"md-search__inner\" role=\"search\">\n <form class=\"md-search__form\" name=\"search\">\n- <input type=\"text\" class=\"md-search__input\" name=\"query\" aria-label=\"Search\" placeholder=\"{{ lang.t('search.placeholder') }}\" autocapitalize=\"off\" autocorrect=\"off\" autocomplete=\"off\" spellcheck=\"false\" data-md-component=\"query\" data-md-state=\"active\">\n+ <input type=\"text\" class=\"md-search__input\" name=\"query\" aria-label=\"{{ lang.t('search.placeholder') }}\" placeholder=\"{{ lang.t('search.placeholder') }}\" autocapitalize=\"off\" autocorrect=\"off\" autocomplete=\"off\" spellcheck=\"false\" data-md-component=\"search-query\" data-md-state=\"active\">\n <label class=\"md-search__icon md-icon\" for=\"__search\">\n+ {% include \".icons/material/magnify.svg\" %}\n+ {% include \".icons/material/arrow-left.svg\" %}\n </label>\n- <button type=\"reset\" class=\"md-icon md-search__icon\" data-md-component=\"reset\" tabindex=\"-1\">\n- &#xE5CD;\n+ <button type=\"reset\" class=\"md-search__icon md-icon\" aria-label=\"{{ lang.t('search.reset') }}\" data-md-component=\"search-reset\" tabindex=\"-1\">\n+ {% include \".icons/material/close.svg\" %}\n </button>\n </form>\n <div class=\"md-search__output\">\n <div class=\"md-search__scrollwrap\" data-md-scrollfix>\n- <div class=\"md-search-result\" data-md-component=\"result\">\n+ <div class=\"md-search-result\" data-md-component=\"search-result\">\n <div class=\"md-search-result__meta\">\n {{ lang.t(\"search.result.placeholder\") }}\n </div>\n @@ -4,9 +4,12 @@\n {% if config.extra.social %}\n <div class=\"md-footer-social\">\n- <link rel=\"stylesheet\" href=\"{{ 'assets/fonts/font-awesome.css' | url }}\">\n {% for social in config.extra.social %}\n- <a href=\"{{ social.link }}\" target=\"_blank\" rel=\"noopener\" title=\"{{ social.type }}\" class=\"md-footer-social__link fa fa-{{ social.type }}\"></a>\n+ {% set _,rest = social.link.split(\"//\") %}\n+ {% set domain = rest.split(\"/\")[0] %}\n+ <a href=\"{{ social.link }}\" target=\"_blank\" rel=\"noopener\" title=\"{{ domain }}\" class=\"md-footer-social__link\">\n+ {% include \".icons/\" ~ social.icon ~ \".svg\" %}\n+ </a>\n {% endfor %}\n </div>\n {% endif %}\n @@ -0,0 +1,15 @@\n+{#-\n+ This file was automatically generated - do not edit\n+-#}\n+{% import \"partials/language.html\" as lang with context %}\n+{% set label = lang.t(\"source.revision.date\") %}\n+<hr>\n+<div class=\"md-source-date\">\n+ <small>\n+ {% if page.meta.git_revision_date_localized %}\n+ {{ label }}: {{ page.meta.git_revision_date_localized }}\n+ {% elif page.meta.revision_date %}\n+ {{ label }}: {{ page.meta.revision_date }}\n+ {% endif %}\n+ </small>\n+</div>\n @@ -0,0 +1,13 @@\n+{#-\n+ This file was automatically generated - do not edit\n+-#}\n+{% import \"partials/language.html\" as lang with context %}\n+{% set repo = config.repo_url %}\n+{% if repo | last == \"/\" %}\n+ {% set repo = repo[:-1] %}\n+{% endif %}\n+{% set path = page.meta.path | default([\"\"]) %}\n+<a href=\"{{ [repo, path, page.meta.source] | join('/') }}\" title=\"{{ file }}\" class=\"md-content__button md-icon\">\n+ {{ lang.t(\"meta.source\") }}\n+ {% include \".icons/\" ~ config.theme.icon.repo ~ \".svg\" %}\n+</a>\n @@ -4,24 +4,11 @@\n {% import \"partials/language.html\" as lang with context %}\n-{% set platform = config.extra.repo_icon or config.repo_url %}\n-{% if \"github\" in platform %}\n- {% set repo_type = \"github\" %}\n-{% elif \"gitlab\" in platform %}\n- {% set repo_type = \"gitlab\" %}\n-{% elif \"bitbucket\" in platform %}\n- {% set repo_type = \"bitbucket\" %}\n-{% else %}\n- {% set repo_type = \"\" %}\n-{% endif %}\n-<a href=\"{{ config.repo_url }}\" title=\"{{ lang.t('source.link.title') }}\" class=\"md-source\" data-md-source=\"{{ repo_type }}\">\n- {% if repo_type %}\n- <div class=\"md-source__icon\">\n- <svg viewBox=\"0 0 24 24\" width=\"24\" height=\"24\">\n- <use xlink:href=\"#__{{ repo_type }}\" width=\"24\" height=\"24\"></use>\n- </svg>\n- </div>\n- {% endif %}\n+<a href=\"{{ config.repo_url }}\" title=\"{{ lang.t('source.link.title') }}\" class=\"md-source\">\n+ <div class=\"md-source__icon md-icon\">\n+ {% set icon = config.theme.icon.repo or \"fontawesome/brands/git-alt\" %}\n+ {% include \".icons/\" ~ icon ~ \".svg\" %}\n+ </div>\n <div class=\"md-source__repository\">\n {{ config.repo_name }}\n </div>\n @@ -4,7 +4,7 @@\n-{% if nav_item.is_homepage %}\n+{% if nav_item.is_homepage or nav_item.url == \"index.html\" %}\n <li class=\"md-tabs__item\">\n {% if not page.ancestors | length and nav | selectattr(\"url\", page.url) %}\n <a href=\"{{ nav_item.url | url }}\" class=\"md-tabs__link md-tabs__link--active\">\n @@ -5,7 +5,7 @@\n {% if page.ancestors | length > 0 %}\n {% set class = \"md-tabs md-tabs--active\" %}\n {% endif %}\n-<nav class=\"{{ class }}\" data-md-component=\"tabs\">\n+<nav class=\"{{ class }}\" aria-label=\"{{ lang.t('tabs.title') }}\" data-md-component=\"tabs\">\n <div class=\"md-tabs__inner md-grid\">\n <ul class=\"md-tabs__list\">\n {% for nav_item in nav %}\n @@ -6,7 +6,7 @@\n {{ toc_item.title }}\n </a>\n {% if toc_item.children %}\n- <nav class=\"md-nav\">\n+ <nav class=\"md-nav\" aria-label=\"{{ toc_item.title }}\">\n <ul class=\"md-nav__list\">\n {% for toc_item in toc_item.children %}\n {% include \"partials/toc-item.html\" %}\n @@ -4,35 +4,22 @@\n {% import \"partials/language.html\" as lang with context %}\n-<nav class=\"md-nav md-nav--secondary\">\n+<nav class=\"md-nav md-nav--secondary\" aria-label=\"{{ lang.t('toc.title') }}\">\n {% endif %}\n {% if toc | first is defined %}\n <label class=\"md-nav__title\" for=\"__toc\">\n+ <span class=\"md-nav__icon md-icon\">\n+ {% include \".icons/material/arrow-left.svg\" %}\n+ </span>\n {{ lang.t(\"toc.title\") }}\n </label>\n <ul class=\"md-nav__list\" data-md-scrollfix>\n {% for toc_item in toc %}\n {% include \"partials/toc-item.html\" %}\n {% endfor %}\n- {% if page.meta.source and page.meta.source | length > 0 %}\n- <li class=\"md-nav__item\">\n- <a href=\"#__source\" class=\"md-nav__link md-nav__link--active\">\n- {{ lang.t(\"meta.source\") }}\n- </a>\n- </li>\n- {% endif %}\n- {% set disqus = config.extra.disqus %}\n- {% if page and page.meta and page.meta.disqus is string %}\n- {% set disqus = page.meta.disqus %}\n- {% endif %}\n- {% if not page.is_homepage and disqus %}\n- <li class=\"md-nav__item\">\n- <a href=\"#__comments\" class=\"md-nav__link md-nav__link--active\">\n- {{ lang.t(\"meta.comments\") }}\n- </a>\n- </li>\n- {% endif %}\n </ul>\n {% endif %}\n </nav>\n Upgrading from 3.x to 4.x¶ What's new?¶ Material for MkDocs 4 fixes incorrect layout on Chinese systems. The fix includes a mandatory change of the base font-size from 10px to 20px which means all rem values needed to be updated. Within the theme, px to rem calculation is now encapsulated in a new function called px2rem which is part of the SASS code base. If you use Material for MkDocs with custom CSS that is based on rem values, note that those values must now be divided by 2. Now, 1.0rem doesn't map to 10px, but 20px. To learn more about the problem and implications, please refer to #911 in which the problem was discovered and fixed. Changes to mkdocs.yml¶ None. Changes to *.html files¶ None.","tokens":14216,"squid":"spider-06","role":"Security Spider","at":1791340991178,"hash":"27658b967cb5b514799ccdf5752c5ea51254cf35"}
{"url":"https://jup.ag/lend/ethena/market","domain":"jup.ag","title":"Crypto Lending Markets on Solana | Jupiter Lend","text":"Want to bridge over USDe?Bridge your USDe from other chains using StargateInstitutional grade lending market for Ethena assets, curated with Bitwise.$229M$121M$107MStrategiesPre-built leverage strategies — enter in 1 click.USDe Loop<0%APYBorrows USDG and loops into USDe to amplify your yield.Deposited$116MCapacity LeftFilledMultiplyAmplify exposure with leveraged loops.USDeUSDG16.3x<0%94%95%BorrowCollateral-debt pairs. Borrow against collateral, or loop for leveraged exposure.USDeUSDG94%95%EarnSingle-asset deposits, passive yield.VaultDepositedEarningsTVLUSDG----113M USDG$113MFAQsThis is a lending market curated with Bitwise, isolated from the Jupiter market, and built around Ethena USDe and USDG assets alongside SOL. It operates as a fully separate market — activity here does not affect, and cannot be affected by, the main Jupiter Lend market.This market is isolated from the Jupiter Lend market. Your exposure is limited to the Bitwise x Ethena market, and has no exposure to the Jupiter Lend market.Bitwise is the world's largest crypto index fund manager. As curator of this market, they've worked alongside Jupiter to design the risk parameters, asset selection, and overall structure — bringing institutional-grade oversight to the lending and borrowing experience.There are four ways to participate:Earn passive yield by depositing USDGBorrow USDe or USDG using SOL or USDe as collateralMultiply your USDe exposure using leveraged loops against USDGEnter a Strategy (USDe Loop) with one click to amplify your yield automaticallyDeposit USDG to lend it out to borrowers in this market and earn variable interest. Jupiter Lend automatically finds you the best available rate — no extra steps needed.There are three borrow pairs in this market:SOL → USDe (80% LTV, 85% liquidation threshold)SOL → USDG (80% LTV, 85% liquidation threshold)USDe → USDG (92% LTV, 94% liquidation threshold)Supply the collateral asset, then borrow against it up to the displayed LTV for that pair.If your collateral's value falls and your position exceeds the liquidation threshold, your position becomes eligible for liquidation — part of your collateral may be automatically sold to repay your loan. Keep a close eye on your Health Factor and add collateral or repay debt before it approaches 1.0.Multiply lets you amplify your USDe exposure in a single transaction. The USDe → USDG vault supports up to 12.3x leverage (92% LTV, 94% liquidation threshold). It borrows USDG against your USDe collateral and loops the proceeds back into USDe automatically — compounding your position without manual steps.USDe Loop is a one-click strategy that borrows USDG and repeatedly loops it into USDe to amplify your yield. It applies maximum leverage automatically via a flashloan in a single atomic transaction. The APY shown reflects current rates and will fluctuate as Supply APY and Borrow APY change.Each strategy has a borrow ceiling that limits total leverage across all users. When capacity is filled, new deposits are unavailable until existing positions are closed or the ceiling is raised.The first signature creates your position account on-chain. The second applies the leveraged loop — depositing collateral, borrowing, swapping, and re-depositing via flashloan — all in one transaction. Adding to an existing position only requires one signature.Every Borrow, Multiply, or Strategy position is represented by a Position NFT sent to your wallet when the position is opened. It stores all position data — collateral, debt, and risk parameters — and represents ownership. Transferring the NFT transfers the entire position. Do not burn it, as it is required to manage or close your position.Withdrawals are available at any time subject to dynamic limits that protect the market from sudden large outflows — these limits grow continuously for smooth, predictable access. For Multiply and Strategy positions, withdrawals fully unwind the position: all debt is repaid via flashloan and remaining assets are returned to your wallet in one transaction.Smart Contract Risk — a bug or vulnerability in the code could be exploited.Market Risk — SOL, USDe, and USDG can all change in value. For borrowers, a drop in collateral value can trigger liquidation.Depeg Risk — if USDe loses its peg, collateral value drops sharply and liquidation risk increases significantly, especially at high leverage.Rate Risk — Borrow APY can spike or Supply APY can drop, compressing or reversing yield on leveraged positions.Leverage Risk — Multiply and Strategy positions amplify both gains and losses. Small adverse moves have an outsized impact at high multipliers.Please use this market carefully and never deposit or borrow more than you are willing to lose.","tokens":1184,"squid":"spider-02","role":"Liquidity Spider","at":1791340994002,"hash":"e7fb2fbf1e062c6ccb8b1906ebca321f585aca96"}
{"url":"https://squidfunk.github.io/mkdocs-material/changelog/","domain":"squidfunk.github.io","title":"Changelog - Material for MkDocs","text":"Changelog¶ Material for MkDocs¶ 9.7.7 July 17, 2026¶ Fixed DOM-based XSS vulnerability in search suggestions 9.7.6 March 19, 2026¶ Automatically disable MkDocs 2.0 warning for forks of MkDocs 9.7.5 March 10, 2026¶ Limited version range of mkdocs to <2 Updated MkDocs 2.0 incompatibility warning (clarify relation with MkDocs) 9.7.4 March 3, 2026¶ Hardened social cards plugin by switching to sandboxed environment Updated MkDocs 2.0 incompatibility warning 9.7.3 February 24, 2026¶ Fixed #8567: Print MkDocs 2.0 incompatibility warning to stderr 9.7.2 February 18, 2026¶ Opened up version ranges of optional dependencies for forward-compatibility Added warning to mkdocs build about impeding MkDocs 2.0 incompatibility 9.7.1 December 18, 2025¶ Updated requests to 2.30+ to mitigate CVE in urllib Fixed privacy plugin not picking up protocol-relative URLs Fixed #8542: false positives and negatives captured in privacy plugin 9.7.0 November 11, 2025¶ Material for MkDocs is now in maintenance mode This is the last release of Material for MkDocs that will receive new features. Going forward, the Material for MkDocs team focuses on Zensical, a next-gen static site generator built from first principles. We will provide critical bug fixes and security updates for Material for MkDocs for 12 months at least. Read the full announcement on our blog This release includes all features that were previously exclusive to the Insiders edition. These features are now freely available to everyone. Note on deprecated plugins: The projects and typeset plugins are included in this release, but must be considered deprecated. Both plugins proved unsustainable to maintain and represent architectural dead ends. They are provided as-is without ongoing support. Changes: Added support for projects plugin (for compat, now deprecated) Added support for typeset plugin (for compat, now deprecated) Added support for pinned blog posts and author profiles Added support for customizing pagination for blog index pages Added support for customizing blog category sort order Added support for staying on page when switching languages Added support for disabling tags in table of contents Added support for nested tags and shadow tags Added support for footnote tooltips Added support for instant previews Added support for instant prefetching Added support for custom social card layouts Added support for custom social card background images Added support for selectable rangs in code blocks Added support for custom selectors for code annotations Added support for configurable log level in privacy plugin Added support for processing of external links in privacy plugin Added support for automatic image optimization via optimize plugin Added support for navigation paths (breadcrumbs) Fixed #8519: Vector accents do not render when using KaTeX 9.6.23 November 1, 2025¶ Updated Burmese translation 9.6.22 October 15, 2025¶ Updated Georgian translation 9.6.21 September 30, 2025¶ Updated Serbian translations Fixed #8458: Temporary pin of click dependency 9.6.20 September 15, 2025¶ Fixed #8446: Deprecation warning as of Python 3.14 in Emoji extension Fixed #8440: & character not escaped in search highlighting Fixed #8439: FontAwesome icons color not set in social cards (regression) 9.6.19 September 7, 2025¶ Added support for Python 3.14 Updated Bahasa Malaysia translations 9.6.18 August 22, 2025¶ Updated Azerbaijani translations Fixed last compat issues with minijinja, now 100% compatible 9.6.17 August 15, 2025¶ Fixed #8396: Videos do not autoplay when inside a content tab Fixed #8394: Stroke width not effective in Mermaid.js diagrams Fixed disappearing version selector when hiding page title 9.6.16 July 26, 2025¶ Fixed #8349: Info plugin doesn't correctly detect virtualenv in some cases Fixed #8334: Find-in-page detects matches in hidden search result list 9.6.15 July 1, 2025¶ Updated Mongolian translations Improved semantic markup of \"edit this page\" button Improved info plugin virtual environment resolution Fixed #8291: Large font size setting throws of breakpoints in JavaScript 9.6.14 May 13, 2025¶ Fixed #8215: Social plugin crashes when CairoSVG is updated to 2.8 9.6.13 May 10, 2025¶ Fixed #8204: Annotations showing list markers in print view Fixed #8153: Improve style of cardinality symbols in Mermaid.js ER diagrams 9.6.12 April 17, 2025¶ Fixed #8158: Flip footnote back reference icon for right-to-left languages 9.6.11 April 1, 2025¶ Updated Docker image to latest Alpine Linux Bump required Jinja version to 3.1 Fixed #8133: Jinja filter items not available (9.6.10 regression) Fixed #8128: Search plugin not entirely disabled via enabled setting 9.6.10 March 30, 2025¶ This version is a pure refactoring release, and does not contain new features or bug fixes. It strives to improve the compatibility of our templates with alternative Jinja-like template engines that we're currently exploring, including minijinja. Additionally, it replaces several instances of Python function invocations with idiomatic use of template filters. All instances where variables have been mutated inside templates have been replaced. Most changes have been made in partials, and only a few in blocks, and all of them are fully backward compatible, so no changes to overrides are necessary. Note that this release does not replace the Jinja template engine with minijinja. However, our templates are now 99% compatible with minijinja, which means we can explore alternative Jinja-compatible implementations. Additionally, immutability and removal of almost all Python function invocations means much more idiomatic templating. 9.6.9 March 17, 2025¶ Updated Serbo-Croatian translations Fixed #8086: Custom SVG icons containing hashes break rendering Fixed #8067: Drawer has gap on right side in Firefox on some OSs 9.6.8 March 13, 2025¶ Added Welsh translations Fixed #8076: Privacy plugin crashes if HTTP download fails 9.6.7 March 3, 2025¶ Fixed #8056: Error in backrefs implementation (9.6.6 regression) Fixed #8054: Unescaped quotes in ARIA labels of table of contents 9.6.6 March 1, 2025¶ Fixed #8040: Privacy plugin not replacing exteral assets (9.6.5 regression) Fixed #8031: Replace unmaintained regex package in search plugin 9.6.5 February 20, 2025¶ Fixed #8016: Tags listing not showing when when file name has spaces Fixed #8012: Privacy plugin crashes if HTTP download fails 9.6.4 February 12, 2025¶ Fixed #7985: Blog content sometimes not stretching to full width Fixed #7978: Navigation rendering bug in Safari 18.3 9.6.3 February 7, 2025¶ Fixed rendering of arrow heads in Mermaid.js class diagrams Fixed #7960: Tags plugin crashes on numeric metadata titles 9.6.2 February 3, 2025¶ Fixed #7955: Excessively long words don't break on narrow screens Fixed #7947: Scope setting interferes with outdated version banner 9.6.1 January 31, 2025¶ Fixed #7943: Tags plugin crashing due to merge error 9.6.0 January 31, 2025¶ Added meta plugin Rewrite of the tags plugin Added support for allow lists in tags plugin Added support for and custom sorting in tags plugin Added support for related links in blog plugin Added support for custom index pages in blog plugin Added support for navigation subtitles Fixed #7924: Anchors might require two clicks when using instant navigation 9.5.50 January 18, 2025¶ Fixed #7913: Social plugin renders attribute lists in page title 9.5.49 December 16, 2024¶ Adjusted title color in dark mode for all supported Mermaid.js diagrams Fixed #7803: Privacy plugin crashes on generated files Fixed #7781: Mermaid.js flow chart title not visible in dark mode 9.5.48 December 8, 2024¶ Fixed #7774: Disabling social cards doesn't work 9.5.47 December 1, 2024¶ Fixed #7750: Numeric tags break search Fixed #7748: Blog plugin breaks when using future drafts (9.5.45 regression) 9.5.46 November 25, 2024¶ Added support for removing preload hints in privacy plugin Fixed #7734: Code blocks in h5 headlines are uppercased Fixed #7725: Blog plugin crashing on missing timezone (9.5.45 regression) 9.5.45 November 20, 2024¶ Reduced size of Docker image through multi-stage build Fixed #7708: Blog plugin crashing on YAML dates with timezones 9.5.44 November 5, 2024¶ Fixed #7672: Font CSS 404's when using privacy plugin (9.5.43 regression) 9.5.43 October 31, 2024¶ Added support for external images in SVGs in privacy plugin Fixed #7651: Privacy plugin doesn't handle quoted URLs in CSS 9.5.42 October 20, 2024¶ Fixed #7625: Invalid encoding of boolean attributes in privacy plugin Fixed #7624: Crash when disabling privacy plugin (9.5.41 regression) 9.5.41 October 15, 2024¶ Fixed #7619: Improved tooltip on logo disappears after instant navigation Fixed #7616: Race condition in built-in privacy plugin when inlining assets Fixed #7615: Comments and \"Was this page helpful?\" visible when printing 9.5.40 October 10, 2024¶ Updated Latvian translations Fixed #7597: Social cards not using site name on home page 9.5.39 September 29, 2024¶ Fixed #7226: not staying on page when using mike's canonical versioning 9.5.38 September 26, 2024¶ Added Albanian translations 9.5.37 September 25, 2024¶ Added 4th and 5th level ordered list styles Fixed #7548: Tags have no spacing in search 9.5.36 September 21, 2024¶ Fixed #7544: Social cards incorrectly rendering HTML entities Fixed #7542: Improved support for setting custom list styles 9.5.35 September 18, 2024¶ Fixed #7498: Search not showing for Vietnamese language 9.5.34 August 31, 2024¶ Updated Mermaid.js to version 11 (latest) 9.5.33 August 23, 2024¶ Fixed #7453: Incorrect position of tooltip when sorting table 9.5.32 August 19, 2024¶ Fixed RXSS vulnerability via deep link in search results Added support for fetching latest release from GitLab 9.5.31 August 2, 2024¶ Fixed #7405: DockerHub missing images > 9.5.27 due to change in Alpine/APK 9.5.30 July 23, 2024¶ Fixed #7380: Navigation icons disappearing on hover in Safari Fixed #7367: Blog readtime computation includes SVG text content 9.5.29 July 14, 2024¶ Updated Galician translations Fixed #7362: Annotations in figure captions rendering incorrectly 9.5.28 July 2, 2024¶ Fixed #7313: Improved tooltips mounted in sidebar when feature is disabled 9.5.27 June 16, 2024¶ Updated Estonian translations 9.5.26 June 6, 2024¶ Fixed #7232: Tab switches on scroll when linking tabs (9.5.19 regression) Fixed #7230: Blog author avatar broken when referring to local file 9.5.25 May 27, 2024¶ Fixed #7209: Tags plugin crashing on numeric tags 9.5.24 May 20, 2024¶ Fixed #7187: Version selector title rendering issue 9.5.23 May 15, 2024¶ Fixed #7183: Edge case in anchor navigation when using instant navigation Fixed #6436: Version selector not showing version alias 9.5.22 May 12, 2024¶ Fixed #7170: Copy button adds empty lines for line spans (9.5.18 regression) Fixed #7160: Version switching doesn't stay on page (9.5.5 regression) Fixed #5619: Links in Mermaid.js diagrams not discernible 9.5.21 May 3, 2024¶ Fixed #7133: Ensure latest version of Mermaid.js is used Fixed #7125: Added warning for dotfiles in info plugin 9.5.20 April 29, 2024¶ Fixed deprecation warning in privacy plugin (9.5.19 regression) Fixed #7119: Tags plugin emits deprecation warning (9.5.19 regression) Fixed #7118: Social plugin crashes if fonts are disabled (9.5.19 regression) Fixed #7085: Social plugin crashes on Windows when downloading fonts 9.5.19 April 25, 2024¶ Updated MkDocs to 1.6 and limited version to < 2 Updated Docker image to latest Alpine Linux Removed setup.py, now that GitHub fully understands pyproject.toml Improved interop of social plugin with third-party MkDocs themes Fixed #7099: Blog reading time not rendered correctly for Japanese Fixed #7097: Improved resilience of tags plugin when no tags are given Fixed #7090: Active tab indicator in nested content tabs rendering bug 9.5.18 April 16, 2024¶ Refactored tooltips implementation to fix positioning issues Fixed #7044: Rendering glitch when hovering contributor avatar in Chrome Fixed #7043: Highlighted lines in code blocks cutoff on mobile Fixed #6910: Incorrect position of tooltip for page status in sidebar Fixed #6760: Incorrect position and overly long tooltip in tables Fixed #6488: Incorrect position and cutoff tooltip in content tabs 9.5.17 April 2, 2024¶ Updated Serbian translations Fixed #7003: Confusing keyboard interaction for palette toggle Fixed #7001: Blog posts now show time by default (9.5.16 regression) Fixed edge case in backport of social plugin font loading logic 9.5.16 March 31, 2024¶ Updated Russian translations Improved error handling and reporting in social plugin Improved error handling and reporting in privacy plugin Fixed blog plugin not allowing to use time in format strings Fixed #6983: Social plugin crashes because of Google Fonts API change 9.5.15 March 23, 2024¶ Reverted fix for transparent iframes (9.5.14) Fixed #6929: Interference of social plugin and auto dark mode Fixed #6938: Giscus shows dark background in light mode (9.5.14 regression) 9.5.14 March 18, 2024¶ Added support for hiding versions from selector when using mike Added init system to improve signal handling in Docker image Fixed edge cases in exclusion logic of info plugin Fixed inability to reset pipeline in search plugin Fixed syntax error in Finnish translations Fixed #6917: UTF-8 encoding problems in blog plugin on Windows Fixed #6889: Transparent iframes get background color 9.5.13 March 6, 2024¶ Updated Slovak translations Improved info plugin interop with projects plugin Improved info plugin inclusion/exclusion logic Fixed info plugin not gathering files recursively Fixed #6750: Ensure info plugin packs up all necessary files 9.5.12 February 29, 2024¶ Fixed #6846: Some meta tags removed on instant navigation (9.4.2 regression) Fixed #6823: KaTex not rendering on instant navigation (9.5.5 regression) Fixed #6821: Privacy plugin doesn't handle URLs with encoded characters 9.5.11 February 24, 2024¶ Updated Finnish translation 9.5.10 February 19, 2024¶ Updated Bahasa Malaysia translations Fixed #6783: Hide continue reading link for blog posts without separators Fixed #6779: Incorrect positioning of integrated table of contents 9.5.9 February 10, 2024¶ Fixed navigation pruning with tabs and sections enabled 9.5.8 February 7, 2024¶ Added Tamil translations Updated Esperanto translations Fixed relative images not being resolved for instant navigation 9.5.7 February 3, 2024¶ Fixed #6731: Small images in figures are not centered Fixed #6719: Instant navigation breaks table of contents (9.5.5 regression) 9.5.6 January 28, 2024¶ Fixed #6700: Missing styles for Mermaid.js labels with Markdown 9.5.5 January 24, 2024¶ Updated Tagalog translations Updated Pillow to 10.2 to mitigate security vulnerabilities Improved resilience of instant navigation Fixed #6687: Updated Mermaid.js to version 10.7.0 (latest) Fixed #6652: Keyboard events in custom elements captured Fixed #6582: Instant navigation doesn't correctly handle alternate URLs Fixed #6565: Instant navigation doesn't allow for onclick handlers Fixed #6345: Instant navigation sometimes breaks browser back button Fixed #6334: Instant navigation doesn't correctly position anchors (Safari) Fixed #6275: Instant navigation doesn't correctly resolve after 404 Fixed #6102: Instant navigation reloads page on same link navigation 9.5.4 January 15, 2024¶ Fixed #6645: Local storage with invalid value can break site Fixed #6635: Tags icons before default ignored if default is set 9.5.3 December 23, 2023¶ Limited version range of MkDocs to < 1.6 Updated Macedonian translations Fixed #6520: Group plugin crashes when using mike Fixed #6494: Hide author's email address if disabled in git-authors plugin 9.5.2 December 11, 2023¶ Fixed types for slugify settings in blog plugin config Fixed #6469: Horizontal scrollbars on MathJax containers 9.5.1 December 8, 2023¶ Updated Greek translations Fixed #6464: Privacy plugin cannot be enabled Fixed #6461: Sorting blog posts ignores time component in date 9.5.0 December 7, 2023¶ Merged Insiders features of 'Goat's Horn' funding goal Added privacy plugin: automatic downloading of external assets Added support for card grids and grid layouts Added support for improved tooltips Added support for content tabs anchor links (deep linking) Added support for automatic dark/light mode Added support for document contributors 9.4.14 November 26, 2023¶ Added support for linking authors in blog posts 9.4.13 November 26, 2023¶ Fixed #6365: Blog plugin pagination links to previous pages broken Fixed #5758: Updated Mermaid.js to version 10.6.1 (latest) 9.4.12 November 24, 2023¶ Improved blog plugin to generate Unicode-aware slugs by default Fixed non-deterministic order of categories in blog plugin 9.4.11 November 23, 2023¶ Fixed #6364: Search plugin crashing when enabling theme while serving Fixed blog plugin crashing when disabling pagination 9.4.10 November 19, 2023¶ Fixed #6356: Version selector can't be disabled via mike's configuration Fixed #6281: Navigation not rendering due to Safari bug (9.4.2 regression) Fixed #6261: Navigation expansion animates on first load (9.4.2 regression) 9.4.9 November 17, 2023¶ Fixed #6344: Long entries cutoff in table of contents Fixed #6336: Custom template for glob archive not working with pagination Fixed #6328: Blog plugin crashes for locales with dashes, e.g. pt-BR Fixed #6327: Copy-to-clipboard button doesn't trim trailing line feed Fixed #6302: Version strings not matched when using mike, only aliases Fixed instant navigation progress indicator for gzipped content in Chrome Fixed rendering bug on details marker rotation in Firefox 9.4.8 November 5, 2023¶ Fixed invalid local address replacement when using instant loading Fixed #6275: Crash after navigation caused 404 when using instant loading 9.4.7 October 27, 2023¶ Added Azerbaijani translations 9.4.6 October 14, 2023¶ Updated Danish and Norwegian (Nynorsk) translations Fixed #6169: Blog post metadata layout overflows on small screens 9.4.5 October 10, 2023¶ Fixed sidebar auto-positioning (9.4.2 regression) Fixed #6166: Improve group plugin compatibility with Python < 3.10 Fixed #6157: Hiding tags does not work (9.4.3 regression) 9.4.4 October 5, 2023¶ Added support for overriding text to be copied for code blocks Fixed broken layout in some browsers at breakpoints when using zoom Fixed #6132: Incomplete search highlighting for code blocks in titles 9.4.3 October 2, 2023¶ Added support for instant navigation progress indicator Improved spacing and alignment of tags Moved back-to-top button into separate partial Fixed #6104: Indentation for some code blocks lost in search Fixed #6094: Blog post metadata overlaps with footer on small screens Fixed #6069: Blog plugin crashes for categories with non-ASCII names Updated templates (diff) base.html 9.4.2 September 25, 2023¶ Updated Slovenian translations Added animation to sidebar navigation expansion and collapse Added support for auto-replacement of document head for instant navigation Improved compatibility of new emoji extension with Python < 3.10 Switched regex dependency to use minimal version Refactored alignment and spacing of sidebar navigation Fixed expansion button not focusable via keyboard in sidebar navigation Fixed viewport offset restoration on first load when using instant navigation Fixed accidental highlight of non-clickable elements in blog plugin sidebar Fixed #6041: Blog plugin crashes when nav is defined and blog not included Fixed #5972: Blog plugin ignores section index pages in paginated views Fixed #5954: Repeated click on anchor ignored when using instant navigation Fixed #5742: Keyboard navigation broken when using instant navigation Updated templates (diff) partials/nav-item.html blog-post.html 9.4.1 September 22, 2023¶ Improved colors and contrast in dark mode Improved admonition borders to match font weight Switched content tabs to neutral color 9.4.0 September 21, 2023¶ Added Belarusian translations Added version info to entrypoint of package Added emoji extension as a replacement for materialx Improved slate color scheme (dark mode) - now even darker Restructured project to improve development experience Updated MkDocs to 1.5.3 Fixed #3890: Development mode crash on Linux 9.3.2 September 19, 2023¶ Updated Slovenian translations Updated Python dependencies in requirements to use minimum versions Fixed #6017: Code highlighting inconsistent in Community and Insiders edition Fixed #6001: Contributor avatars display incorrectly in Firefox Fixed #6000: Blog post drafts are included in navigation 9.3.1 September 11, 2023¶ Fixed crash of group plugin when used together with hooks 9.3.0 September 11, 2023¶ Improved configuration sharing between Community and Insiders edition Added experimental built-in group plugin for enabling plugins conditionally Added new settings in tags plugin for enabling/disabling Dropped support for Python 3.7 (EOL) 9.2.8 September 4, 2023¶ Updated Italian and Russian translations Fixed #5952: Combining blog and tags plugin leads to wrong links Fixed #5951: Blog plugin ignores post title in metadata Fixed #5949: Blog plugin ignores post linked in nav 9.2.7 September 2, 2023¶ Switched dependencies to compatible release clauses Removed readtime and lxml dependencies for blog plugin Reduced size of Docker image to improve CI build performance Fixed #5945: Incorrect footer navigation for sibling pages of blog Fixed #5939: Page jumps when changing color palette (Firefox 117) Fixed #5901: Announcement bar reappears when using instant loading Fixed #5824: Allow to customize styles of sequence diagrams 9.2.6 August 31, 2023¶ Added Basque translations Added template for simple redirects Improved blog plugin interop by moving view generation to on_files Fixed #5924: Social plugin still checks dependencies when disabled Fixed #5916: Blog plugin crashes on Python 3.8 (9.2.0 regression) 9.2.5 August 27, 2023¶ Fixed error in dirty serve mode when using blog plugin Fixed page title not being consistent in blog plugin pagination Fixed #5899: Blog plugin pagination breaks when disabling directory URLs 9.2.4 August 26, 2023¶ Added version to bug report name in info plugin Updated Afrikaans translations 9.2.3 August 22, 2023¶ Fixed blog plugin rendering wrongly with markdown.extensions.toc Fixed blog plugin entrypoint generation 9.2.2 August 22, 2023¶ Fixed #5880: Blog plugin failing when building a standalone blog Fixed #5881: Blog plugin not compatible with Python < 3.10 9.2.1 August 21, 2023¶ Fixed #5879: Blog plugin failing when building a standalone blog Fixed error in blog plugin when using draft tagging on future date Fixed error in blog plugin when toc extension is not enabled 9.2.0 August 21, 2023¶ Additions and improvements Added blogging support via built-in blog plugin Added support for Chinese language segmentaiton in search plugin Added support for adding custom dates to blog posts Added support for paginating archive and category pages Added support for annotations (outside of code blocks) Added support for navigation icons Added support for navigation pruning Added support for navigation status Added support for customizing site icons Added support for customizing (code) annotation icons Added focus outline to admonitions and details Added prompt for bug report name to info plugin Added Luxembourgish translations Improved rendering of (code) annotation markers Improved print styles for (code) annotations Improved customizability of navigation tabs Improved interop of plugins with external tools like mike Improved interop of blog plugin with awesome pages plugin Improved header partial by moving buttons into separate partials Improved clarity of site_url warning in social plugin Improved blog plugin to automatically setup directory structure Switched info plugin to importlib to mitigate deprecations Automatically download ResizeObserver polyfill when necessary Automatically add iframe-worker polyfill when necessary in offline plugin Automatically focus and bring up keyboard on touch devices Updated Serbo-Croatian translations Updated MkDocs to 1.5.2 Removals Removed Universal Analytics integration Removed ancient polyfills to reduce size of bundled JavaScript by 20% Removed necessity for Array.flat and Array.flatMap polyfill Removed announcement bar button when JavaScript is not available Fixes Fixed rendering of tags when announcement bar is present Fixed tags plugin rendering pages excluded by other plugins Fixed #5132: Blog plugin requires nav entry in mkdocs.yml Fixed #5599: Insufficient contrast for default link color Fixed #5715: Blog plugin missing integrated table of contents in pagination Fixed #5806: Version selector not hoverable on some Android devices Fixed #5826: Blog post drafts with tags show up in tags index 9.1.21 July 27, 2023¶ Fixed MkDocs 1.4 compat issue in social plugin (9.1.20 regression) 9.1.20 July 27, 2023¶ Updated Sanskrit translations Fixed deprecation warnings for social plugin 9.1.19 July 18, 2023¶ Added support for MkDocs 1.5+ Fixed #5699: Improve error reporting in social plugin 9.1.18 July 3, 2023¶ Updated Danish translations Added support for installing user requirements in Docker image Fixed #5655: Search separator with lookbehind breaks highlighting 9.1.17 June 23, 2023¶ Fixed #5633: Code annotations with nested lists incorrectly mounted Fixed #5628: Regression in new social plugin configuration scheme 9.1.16 June 15, 2023¶ Updated Indonesian translations Ensure scroll bar follows color scheme of operating system 9.1.15 May 29, 2023¶ Fixed #5566: Indicate color scheme to operating system Fixed #5565: Update Dockerfile to latest version of base image Fixed #5554: Add additional version tags (9, 9.1) to Docker image Fixed #5536: Strip tags of ARIA labels in table of contents 9.1.14 May 20, 2023¶ Updated Armenian and Greek translations 9.1.13 May 16, 2023¶ Fixed #5517: Social plugin crashes for some fonts (e.g. Open Sans) 9.1.12 May 12, 2023¶ Updated Bengali (Bangla) translations Fixed #5503: Docker image publish errors on uppercase characters Fixed #5407: Auto-pause media when in hidden content tabs 9.1.11 May 8, 2023¶ Fixed #5487: Social plugin crashes without options (9.1.10 regression) 9.1.10 May 8, 2023¶ Added cards_layout_options setting for social cards Deprecated cards_color and cards_font setting for social cards 9.1.9 May 2, 2023¶ Added Telugu, Kannada and Sanskrit translations Fixed #5428: Fixed margins for light/dark mode images in figures Fixed #5420: Social plugin crashing for some specific Google Fonts Fixed #5160: Instant loading makes code annotations jump (9.1.1 regression) Fixed #4920: Social plugin not loading logo from custom icon set Fixed social plugin crashing when only code font is specified 9.1.8 April 24, 2023¶ Fixed #5417: Theme breaks when palette is not defined (9.1.7 regression) 9.1.7 April 22, 2023¶ Updated Persian (Farsi) and Turkish translations Fixed #5401: Added missing flag to disable built-in tags plugin Fixed #5206: Ensure defaults are set for primary and accent colors Fixed unnecessary inclusion of palette CSS when unused 9.1.6 April 7, 2023¶ Updated Persian (Farsi) translations Fixed #5300: Boxes in Mermaid sequence diagrams not color-abiding 9.1.5 March 31, 2023¶ Updated Lithuanian and Japanese translations Updated Mermaid.js to version 9.4.3 Fixed #5290: Footer previous/next labels cut-off for short page titles 9.1.4 March 24, 2023¶ Fixed #5239: Instant loading breaks anchors in details (9.1.1 regression) Fixed #5211: Anchor following not working for Chinese (9.1.2 regression) 9.1.3 March 14, 2023¶ Added Kurdish (Soranî) translations Updated Norwegian (Bokmål), Portuguese and Romanian translations Improved compatibility with mkdocs-jupyter plugin Fixed #5198: Built-in search plugin not filtering script and style tags Fixed #5176: Back-to-top + instant loading not working (9.1.1 regression) 9.1.2 March 9, 2023¶ Updated Icelandic, Korean and Swedish translations Fixed #5168: Mermaid text boxes overflow (9.0.13 regression) Fixed #5155: Table of contents not highlighting percent-encoded URLs 9.1.1 March 5, 2023¶ Updated Czech and Thai translations Improved instant loading (scroll restoration, slow connections) Fixed #5023: Instant loading not allowing to go back to initial page Fixed #3797: Instant loading does not work with section anchors in Safari 9.1.0 March 2, 2023¶ Docker image now available for amd64, arm64 and arm/v7 Updated Chinese (Taiwanese) translations Generalized tag identifier implementation Fixed flickering of header shadow on load Fixed occasional flickering of announcement bar 9.0.15 February 26, 2023¶ Updated Chinese (Traditional) translations Updated Hebrew translations 9.0.14 February 23, 2023¶ Fixed #5072: Rendering bug on navigation expand button in Firefox 9.0.13 February 18, 2023¶ Updated Uzbek translations Switched back to pre-9.0.0 headline detection in content partial Fixed #5062: Version warning not readable when using slate scheme Fixed #5061: Improved discernibility of table row hover color Fixed #5034: Sequence actors in Mermaid diagrams not color-abiding Fixed #4919: Allow to hide version warning in multiple versions 9.0.12 February 9, 2023¶ Updated Catalan translations Fixed #4975: Mermaid entity relationship rendering diagrams bug Fixed #4924: Header title not reset when using instant loading 9.0.11 February 3, 2023¶ Added Mastodon verification for social links (rel=me) Updated Italian translations 9.0.10 February 2, 2023¶ Updated Arabic translations Updated Korean translations Updated Hungarian translations Updated Russian translations Fixed #4977: Improved accessibility for content tabs Fixed #4960: Sometimes anchor following doesn't bring last item into view 9.0.9 January 30, 2023¶ Updated Bulgarian translations Updated Chinese (Simplified) translations Updated Dutch translations Updated Hindi translations Updated Japanese translations Updated Polish translations 9.0.8 January 29, 2023¶ Updated Croatian translations Updated French translations Updated Hungarian translations Updated Portuguese (Brasilian) translations Updated Spanish translations Updated Ukrainian translations Updated Urdu translations Updated Vietnamese translations 9.0.7 January 28, 2023¶ Improved accessibility of sidebar navigation Moved all translations into Community edition Updated Polish and Portuguese (Brasilian) translations Fixed info plugin terminating on subsequent reload when serving Fixed #4910: Sidebar navigation labels have invalid ARIA roles Fixed #4884: Search query terms can't be separated by colons 9.0.6 January 19, 2023¶ Fixed #4883: Automatically disable info plugin when serving Fixed #4885: Search plugin crashes in some exotic cases (9.0.3 regression) 9.0.5 January 14, 2023¶ Fixed #4842: Improved accessibility of search result list 9.0.4 January 12, 2023¶ Fixed #4823: Improved contrast ratio in footer (9.0.2 regression) Fixed #4832: Set navigation items back to black (9.0.3 regression) Fixed #4843: Emojis broken due to maxcdn.com shutting down Upgraded Python Markdown Extensions to 9.9.1 9.0.3 January 8, 2023¶ Improved discernibility of section index pages in navigation Improved collapsing of adjacent whitespace in search plugin Updated Indonesian translations Fixed view source of this page button when edit URL points to blob Fixed #4829: Search overlay does not close for active anchor result Fixed #4824: Search plugin crashes for h[1-6] contained in other elements Fixed #4804: Nested navigation items not expandable with keyboard Fixed #4689: anchor tracking not working for anchors in tables Upgraded to Mermaid 9.3.0 9.0.2 January 4, 2023¶ Fixed #4823: Improved contrast ratio in footer to meet WCAG guidelines Fixed #4819: Social plugin crashes when card generation is disabled Fixed #4817: Search plugin crashes on numeric page titles in nav 9.0.1 January 3, 2023¶ Removed pipdeptree dependency for built-in info plugin Fixed appearance of linked tags when hovered (9.0.0 regression) Fixed #4810: Abbreviations run out of screen on touch devices Fixed #4813: View source and edit button links are the same 9.0.0 January 2, 2023¶ Additions and improvements Added support for rich search previews Added support for tokenizer lookahead Added support for better search highlighting Added support for excluding content from search Added support for configurable search pipeline Added support for offline search via offline plugin Added support for multiple instances of built-in tags plugin Added support for removing copy-to-clipboard button Added support for removing footer navigation Added support for button to view the source of a page Improved readability of query string for search sharing Improved stability of search plugin when using --dirtyreload Improved search result group button, now sticky and stable Updated Norwegian translations Updated MkDocs to 1.4.2 Removals Removed deprecated alternative admonition qualifiers Removed :is() selectors (in output) for easier overriding Removed .title suffix on translations Removed legacy method for providing page title in feedback URL Removed support for indexing only titles in search Removed support for custom search transforms Removed support for custom search workers Removed temporary snow feature (easter egg) Fixes Fixed Norwegian and Korean language code Fixed detection of composition events in search interface Fixed search plugin not using title set via front matter Fixed search highlighting of tags Fixed search sharing URL using post transformed string Fixed theme-color meta tag getting out-of-sync with palette toggle Fixed prev/next page keyboard navigation when footer is not present Fixed overflowing navigation tabs not being scrollable Fixed inclusion of code block line numbers from search 8.5.11 November 30, 2022¶ Let it snow, see https://x.com/squidfunk/status/1597939243090788352 8.5.10 November 11, 2022¶ Adjusted CSS to better allow for custom primary and accent colors Fixed #4620: Primary color is not applied (8.5.9 regression) 8.5.9 November 8, 2022¶ Fixed #4600: Illegible link colors for black and white primary colors Fixed #4594: Need to set schema to change link color 8.5.8 November 3, 2022¶ Added support for always showing settings in cookie consent Fixed #4571: Buttons invisible if primary color is white or black Fixed #4517: Illegible note in sequence diagram when using slate scheme 8.5.7 October 22, 2022¶ Deprecated additional admonition qualifiers to reduce size of CSS Fixed #4511: Search boost does not apply to sections 8.5.6 October 2, 2022¶ Modernized appearance of admonitions (with fallback, see docs) Improved appearance of inline code blocks in admonition titles 8.5.5 October 1, 2022¶ Updated MkDocs to 1.4 Fixed compatibility issues with MkDocs 1.4 Fixed #4430: build error when enabling consent without repository URL 8.5.4 September 30, 2022¶ Fixed expand icons shift on sidebar overflow (using scrollbar-gutter) Fixed #4429: Text in sequence diagrams overflows in Firefox 8.5.3 September 20, 2022¶ Fixed build error when enabling cookie consent without analytics Fixed #4381: Code blocks render ligatures for some fonts 8.5.2 September 18, 2022¶ Updated Mermaid.js to version 9.1.7 Fixed overly large headlines in search results (8.5.0 regression) Fixed #4358: Navigation sections appear as clickable (8.5.0 regression) Fixed #4356: GitHub repository statistics fetched before cookie consent 8.5.1 September 15, 2022¶ Fixed #4366: Removed dependencies with native extensions 8.5.0 September 13, 2022¶ Added support for social cards Added support for code annotation anchor links (deep linking) Added support for code annotation comment stripping (syntax modifier) Added support for sidebars scrolling automatically to active item Added support for anchor following table of contents (= auto scroll) Added support for tag icons 8.4.4 September 12, 2022¶ Moved comments integration to separate partial (comments.html) 8.4.3 September 7, 2022¶ Added Simple Icons to bundled icons (+2,300 icons) Added support for changing edit icon Moved page actions to separate partial (actions.html) Fixed #4291: Version switching doesn't stay on page when anchors are used Fixed #4327: Links in data tables do not receive link styling 8.4.2 August 27, 2022¶ Updated Slovenian translations Fixed #4277: Feedback widget hidden after navigation with instant loading Fixed numeric tags in front matter breaking search functionality 8.4.1 August 21, 2022¶ Updated Croatian and Hebrew translations 8.4.0 August 13, 2022¶ Added support for cookie consent Added support for feedback widget (Was this page helpful?) Added support for dismissible announcement bar Added Armenian, Lithuanian, Tagalog, and Urdu translations 8.3.9 July 4, 2022¶ Updated Taiwanese translations for search Allow ids for content tabs with special characters (for mkdocstrings) Fixed #4083: home not clickable when using versioning (8.3.5 regression) 8.3.8 June 24, 2022¶ Fixed #4053: Limit width of videos to content area Fixed empty tags in front matter breaking search 8.3.7 June 22, 2022¶ Fixed search being stuck initializing when using tags (8.3.4 regression) 8.3.6 June 16, 2022¶ Fixed #4028: Links not clickable when using versioning (8.3.5 regression) 8.3.5 June 14, 2022¶ Fixed #4012: Stay on page not working for alias of active version 8.3.4 June 11, 2022¶ Fixed #4004: Tags with multiple words not searchable 8.3.3 June 7, 2022¶ Fixed #4000: Mermaid diagrams too dark in dark mode (8.3.0 regression) 8.3.2 June 5, 2022¶ Fixed #3987: Custom admonition icons don't work when defining color palette 8.3.1 June 4, 2022¶ Bump required Jinja version to 3.0.2 Removed unnecessary conditions in templates Fixed scroll offset when content tabs are brought into view Fixed #3977: Content tabs snapping oddly in Firefox Fixed #3983: Missing condition in footer partial (8.3.0 regression) 8.3.0 June 2, 2022¶ Added support for custom admonition icons Added support for linking of content tabs Added support for boosting pages in search Added support for hiding footer navigation Added previous/next indicators to content tabs Improved typeset link colors in light and dark modes 8.2.16 May 28, 2022¶ Fixed #3957: Only animate code annotations when visible (save CPU cycles) 8.2.15 May 14, 2022¶ Added Uzbek translations Fixed spacing for code block results in content tabs 8.2.14 May 8, 2022¶ Fixed missing top right rounded border on admonition Fixed #3886: 4xx status codes not handled when using instant loading 8.2.13 May 2, 2022¶ Fixed #3865: Tags index links to tagged pages 404 on Windows Fixed #3866: Bump required Python version from 3.6+ to 3.7+ 8.2.12 April 30, 2022¶ Added support for GitHub-style hash fragments for dark/light images Improved rendering of nested code blocks in content tabs and annotations Fixed #3862: Upgraded to latest Pygments and Python Markdown Extensions 8.2.11 April 25, 2022¶ Temporarily pinned Pygments to <2.12 Temporarily pinned Python Markdown Extensions to <9.4 Improved rendering of code annotation markers 8.2.10 April 24, 2022¶ Added Macedonian translations Updated Mermaid.js to version 9.0.1 Switched sidebar title in mobile navigation to bold font Fixed color of arrows in class and state diagrams for dark mode Fixed #3836: Inline admonitions overlayed by code block titles 8.2.9 April 8, 2022¶ Mitigate flicker on color palette switch by disabling all transitions Fixed search suggestions not triggered when following deep link Fixed incorrectly computed header height when using instant loading Fixed #3782: Admonition titles have extra pixels on wide screens in Firefox Fixed #3802: Always render table of contents container (except when hidden) 8.2.8 March 27, 2022¶ Bumped MkDocs version to 1.3.0 to mitigate breaking changes in Jinja Reverted Jinja version range limitation (added in 8.2.7) Improved styling of annotations and fixed borders of code blocks in tabs Added background color to code blocks in focused/hovered links Added check in tags plugin whether tags overview page exists Fixed #3744: Content tab indicator on wrong position when using back button 8.2.7 March 24, 2022¶ Temporarily limit Jinja version range to < 3.1 due to breaking changes 8.2.6 March 23, 2022¶ Fixed #3695: Deprecation warning for unescaped backslashes in templates Fixed #3696: Annotations not mounted in some Terraform code blocks Fixed #3698: Annotations not mounted in long code blocks (8.2.5 regression) 8.2.5 March 6, 2022¶ Fixed #3596: Mermaid not working when headline with name 'Mermaid' present Fixed #3643: Reduce time to render pages with thousands of code blocks Fixed #3665: Missing styles for Mermaid.js flowcharts cluster labels 8.2.4 March 2, 2022¶ Fixed malformed Google Fonts URL when a font setting was omitted Fixed #3648: Fixed specificity issue with admonitions in lists Fixed #3653: Invalid outdated version banner URL when using instant loading 8.2.3 February 27, 2022¶ Fixed #3578: Active element in table of contents off-by-one on large screens 8.2.2 February 26, 2022¶ Added automatic removal of query parameter when search is closed Fixed #3599: Anchors always overridden when using navigation tracking 8.2.1 February 17, 2022¶ Fixed module material.plugins not being found (8.2.0 regression) 8.2.0 February 17, 2022¶ Added native support for Mermaid.js diagrams Added native support for tags (with search integration) Added support for staying on page when switching versions 8.1.11 February 10, 2022¶ Added Portuguese (Brasilian) translations Updated FontAwesome to v6 – check which icons were renamed here Fixed #3545: Color palette toggle and search overlaying version selector 8.1.10 February 6, 2022¶ Fixed cutoff of very wide logos in the sidebar on mobile 8.1.9 January 30, 2022¶ Added support for mkdocs.yml validation and auto-complete Fixed errors in Latvian translations 8.1.8 January 23, 2022¶ Added Latvian translations Updated Giscus example integration with dynamic theme change support Fixed #3479: Back-to-top button not hidden when using sticky navigation tabs Fixed #3491: Logo in header and drawer doesn't honor aspect ratio 8.1.7 January 16, 2022¶ Improved back-to-top button behavior - now not shown on anchor jump 8.1.6 January 11, 2022¶ Fixed spacing of blockquotes (8.1.5 regression) Fixed edge cases for rounded corners on code blocks (8.1.5 regression) Fixed issues with code annotation line heights 8.1.5 January 9, 2022¶ Improved browser support: Chrome 49+, Safari 10+, Firefox 53+, Edge 79+ Improved rendering of inline code blocks in headlines Added Bahasa Malaysian translations Fixed #3354: MathJax formulas show vertical scrollbar 8.1.4 January 2, 2022¶ Added indicator to navigation expander icon Improved support for reduced motion preference Fixed jitter of active content tab indicator 8.1.3 December 19, 2021¶ Added animation to active content tab indicator Fixed #3360: Highlighted lines add blank lines in copied text Fixed usage of subsequent index files when using section index pages 8.1.2 December 15, 2021¶ Switched CSS sources to logical properties Added transformation of logical properties to ltr/rtl equivalents Fixed spacing for admonitions inside lists (8.1.1 regression) 8.1.1 December 13, 2021¶ Added support for #only-light and #only-dark image hash fragments Fixed copy-to-clipboard adding blank lines when using line anchors Fixed code annotation directionality for right-to-left languages Fixed header title positioning for right-to-left languages Fixed admonition borders for right-to-left languages (8.0.0 regression) Fixed footer navigation link positioning (8.0.0 regression) Fixed footer navigation title breaking out of container when too long Fixed shrinking arrow in navigation title when too long Fixed #3343: Filtered stopwords appear as missing search terms Fixed #3346: Site unusable due to usage of :not() (Firefox 78 ESR) 8.1.0 December 10, 2021¶ Added basic support for code block line anchors Switched code annotation markers to + signs to improve usability Switched main site title to bold font Improved admonition icon positioning to align when font-size is increased Improved and simplified footnotes CSS Improved and simplified code annotation positioning Fixed syntax error in Russian translations 8.0.5 December 6, 2021¶ Fixed #3302: Footer refactoring induced ellipsis in some browsers Fixed #3313: Details always rendered closed on load (8.0.4 regression) 8.0.4 December 4, 2021¶ Improved support for deeply nested code annotations Improved code annotation and copy-to-clipboard interop Improved styling for code annotations inside admonitions Fixed #3274: Invalid anchor positioning when using instant loading Fixed #3294: Lists after code blocks without code annotations disappearing Fixed several positioning issues for code annotations Fixed JavaScript source map roots 8.0.3 December 2, 2021¶ Removed deprecated google_analytics setting (was forgotten in 8.0.0) Fixed syntax error in Swedish and Polish translations Fixed #3283: Invalid back-to-top button position with sticky navigation tabs Fixed #3285: Default details marker showing due to Safari bug 8.0.2 November 30, 2021¶ Fixed #3275: Code annotations always disappear on click 8.0.1 November 28, 2021¶ Improved rendering of code annotation markers Fixed #3265: Wrong margin on nested admonitions Fixed wrong box-sizing for code annotations in details 8.0.0 November 28, 2021¶ Added support for code annotations Added support for anchor tracking Added support for version warning Added copyright partial for easier override Removed deprecated content tabs legacy implementation Removed deprecated seealso admonition type Removed deprecated site_keywords setting (unsupported by MkDocs) Removed deprecated prebuilt search index support Removed deprecated web app manifest – use customization Removed extracopyright variable – use new copyright partial Removed Disqus integration – use customization Switched to :is() selectors for simple selector lists Switched autoprefixer from last 4 years to last 2 years Improved CSS overall to match modern standards Improved CSS variable semantics for fonts Improved extensibility by restructuring partials Improved handling of details when printing Improved keyboard navigation for footnotes Fixed #3214: Search highlighting breaks site when empty 7.3.6 October 30, 2021¶ Added support for adding titles to code blocks 7.3.5 October 27, 2021¶ Added support for setting table of contents title via mkdocs.yml Fixed back-to-top button position for right-to-left languages 7.3.4 October 17, 2021¶ Bumped MkDocs version to 1.2.3 to mitigate CVE-2021-40978 Fixed spacing issues when using integrate table of contents with tabs Fixed some spacings issues for right-to-left languages Fixed race condition in search initialization 7.3.3 October 11, 2021¶ Rewrite of entire documentation Adjusted height of new content tabs to match single line code blocks Fixed new content tabs missing right padding in some browsers on overflow Fixed new content tabs bleeding out of flex container on overflow Fixed new content tabs overflow scrolling bugs on some browsers Fixed new content tabs stealing keyboard access when active Fixed some spacings issues for right-to-left languages 7.3.2 October 6, 2021¶ Deprecated prebuilding of search index Improved graceful handling of broken search for file:// Added minimum Jinja version to list of requirements Fixed #3071: Section index pages render empty directories Fixed margin issues when using navigation tabs (7.3.1 regression) Fixed search placeholder sometimes being shown too early 7.3.1 October 2, 2021¶ Added new experimental content tabs implementation Fixed #3069: GitHub stats broken for users/orgs (7.1.0 regression) Fixed #3070: Sections not linking to index page Fixed title not linking to index page when using tabs Fixed Disqus integration when using instant loading Fixed some spacing issues for right-to-left languages Fixed syntax error in Serbian translations 7.3.0 September 23, 2021¶ Added support for sticky navigation tabs Added support for section index pages Added support for removing generator notice 7.2.8 September 20, 2021¶ Fixed #3039: Search modal overlays menu on mobile (7.2.7 regression) 7.2.7 September 19, 2021¶ Updated Serbian and Serbo-Croatian translations Improved appearance of outline on details Fixed #2934: Scrollbar when header is hidden on some mobile browsers Fixed #3032: Anchor in details doesn't open on load (7.0.0 regression) Fixed back-to-top button being focusable when invisible Fixed broken admonition icons (removed in upstream) 7.2.6 September 1, 2021¶ Fixed rendering of blockquote elements (7.0.0 regression) Fixed #2973: Custom search worker setting ignored 7.2.5 August 25, 2021¶ Updated Portuguese translations Fixed execution of RxJS teardown logic (7.2.3 regression) Fixed #2970: Search results show escaped characters (7.2.2 regression) 7.2.4 August 11, 2021¶ Fixed #2926: Version selector not working (7.2.3 regression) Fixed #2929: Missing CSS class for banner (consistency with Insiders) 7.2.3 August 9, 2021¶ Slight facelift of data tables, now closer to Material Design Fixed instant loading not respecting clicks on search results Fixed #2881: Invalid anchor offsets when using instant loading 7.2.2 July 31, 2021¶ Updated Korean translations Fixed #2879: Search highlighting does not properly escape HTML 7.2.1 July 25, 2021¶ Fixed #2862: Back-to-top button overlays active search bar 7.2.0 July 21, 2021¶ Added support for search suggestions to save keystrokes Added support for search highlighting Added support for search sharing (i.e. deep linking) 7.1.11 July 18, 2021¶ Updated Spanish and Galician translations 7.1.10 July 10, 2021¶ Refactored appearance of back-to-top button Fixed graceful handling of search when browsing locally 7.1.9 June 25, 2021¶ Improved search language support for Thai and Hindi Fixed #2761: License comments lined up at end of file 7.1.8 June 12, 2021¶ Refactored analytics integration (because of MkDocs 1.2) Added support for Google Analytics 4 (gtag.js) Fixed missing escape for aria-label in footer links 7.1.7 June 6, 2021¶ Improved screen reader support 7.1.6 May 30, 2021¶ Deprecated seealso admonition qualifier Added Mongolian and updated Chinese translations Fixed #2429: Version selector not touch-friendly on Android devices Fixed #2703: Printed 'Initializing search' albeit ready on mobile 7.1.5 May 19, 2021¶ Fixed #2655: Details breaking page margins on print 7.1.4 May 6, 2021¶ Added support for git-revision-date-localized plugin creation date Improved footnote styles on :target and :focus 7.1.3 April 24, 2021¶ Fixed #2586: Empty table of contents shown (7.1.2 regression) 7.1.2 April 18, 2021¶ Fixed #2554: List markers sometimes overlap floated elements Fixed #2563: Adding a class to a h1 breaks the table of contents Fixed #2566: Back-to-top button clickable when invisible 7.1.1 April 10, 2021¶ Fixed #2501: Nested definition lists compound bottom margin Fixed #2508: Switch extracopyright block to template variable Fixed #2533: Search (and other parts) not working in Safari <14 Fixed #2538: Visual quirk when opening language selector 7.1.0 March 29, 2021¶ Added support for back-to-top button Added support for color palette toggle Added latest release to repository info (GitHub) Slight facelift of repository info (lighter fonts, spacing and icons) 7.0.7 March 28, 2021¶ Updated Hungarian translations Fixed #2466: Docker image not based on latest Python and Alpine Fixed #2488: Inconsistent header shadow behavior Fixed #2492: Inline code blocks in admonition titles missing background 7.0.6 March 14, 2021¶ Added trailing slash to version selector URL Added support for out-of-order anchors in table of contents Added extra.homepage option to link logo to arbitrary URL Improved security of Docker image (always update apk) Fixed horizontal spacing for nested inline admonitions Fixed text color of nested code blocks inside links Fixed version selector to always use version title Fixed logo link when using versioning with instant loading 7.0.5 March 7, 2021¶ Added extracopyright block to allow for custom copyright info Fixed evaluation of third-party scripts when using instant loading Fixed edge cases when using instant loading without directory URLs Fixed handling of version selector when using instant loading Fixed regression with header title not being updated correctly Fixed expanded sections not opening on first click (7.0.4 regression) 7.0.4 March 4, 2021¶ Added Icelandic translations Fixed #2386: Section close requires two clicks (navigation expansion) Fixed console error when search is disabled (7.0.0 regression) Fixed localsearch integration (7.0.0 regression) 7.0.3 February 26, 2021¶ Fixed JavaScript errors in older browsers (target ES2020 -> ES2015) 7.0.2 February 25, 2021¶ Fixed #2343: Invalid source map URLs for JS and CSS files Fixed #2347: Version selector missing when using versioning 7.0.1 February 24, 2021¶ Fixed #2334: Google Analytics triggers page view twice (7.0.0 regression) Fixed #2336: Details bleed into inline admonitions Fixed #2337: Images don't align correctly (7.0.0 regression) 7.0.0 February 22, 2021¶ Added support for deploying multiple versions Added support for integrating a language selector Added support for rendering admonitions as inline blocks Rewrite of the underlying reactive architecture Removed Webpack in favor of reactive build strategy (-480 dependencies) Fixed keyboard navigation for code blocks after content tabs switch 6.2.8 February 4, 2021¶ Updated Japanese and Polish translations Fixed #2261: Print dialog auto-closing when using instant loading 6.2.7 January 31, 2021¶ Fixed #2251: Updated Docker image to latest Alpine Linux 6.2.6 January 26, 2021¶ Added Bulgarian translations Fixed #2233: Search not shown when using header autohiding 6.2.5 January 17, 2021¶ Fixed syntax error in Swedish translations Optimized navigation partials to improve build speed for huge docs 6.2.4 January 9, 2021¶ Fixed #2156: Missing syntax highlighting for binary numbers Fixed #2186: Disqus showing on 404 page 6.2.3 December 27, 2020¶ Added back hidden overflow on root container Fixed #2142: MathJax formulas sometimes have vertical scrollbars 6.2.2 December 22, 2020¶ Removed Markdown version range limit (6.2.0 regression) 6.2.1 December 22, 2020¶ Fixed all import and asset paths in templates (6.2.0 regression) Downgraded webpack-asset-manifest-plugin - broke all asset paths 6.2.0 December 22, 2020¶ Added support for navigation sections Added support for navigation expansion Added support for integrating table of contents into navigation Added support for autohiding header on scroll Added support for hiding navigation and table of contents per page Added support for arbitrary items in navigation tabs Refactored navigation tabs to simplify grouping behavior Fixed anchor offset for permalinks in Safari (partial revert) Fixed #2098: Active tab sometimes not highlighted correctly Improved appearance for horizontal rulers Improved Spanish and Swedish translations 6.1.7 December 6, 2020¶ Fixed #2081: Fixed stats for private GitHub repositories Fixed alignment for admonition icon alignment for right-to-left languages 6.1.6 November 22, 2020¶ Fixed #2048: Math formulas show scrollbars (Windows) 6.1.5 November 15, 2020¶ Fixed search reset button not showing/hiding correctly 6.1.4 November 7, 2020¶ Fixed sidebar jitter when scrolling footer into view 6.1.3 November 5, 2020¶ Added support for keywords meta tag Fixed #2027: Line numbers don't scale with smaller font size Fixed link colors for black and white on slate color scheme Removed focus outline on scrolling code blocks for pointer devices 6.1.2 October 31, 2020¶ Fixed sizing of icons in admonitions, task lists, etc. (6.1.1 regression) 6.1.1 October 31, 2020¶ Fixed #2019: Page title not correctly updated when using instant loading 6.1.0 October 17, 2020¶ Fixed #1973: Added support for printing in dark mode Fixed #1974: Added support for printing content tabs Fixed #1995: Improved customizability of details extension 6.0.2 October 4, 2020¶ Added Georgian translations Added escaping for link title attributes where necessary Fixed #1956: Pages with whitespace in names have invalid links in search Removed unnecessary (duplicated) link title attributes 6.0.1 September 26, 2020¶ Fixed stemmer support for file:// protocol through iframe-worker Fixed details marker showing for search result in Firefox Fixed tabbing behavior when search query is not empty Switched TypeScript compilation target to ES2015 Reduced size of JavaScript by 30% (176kb → 124kb) Removed mkdocs and readthedocs themes from Docker image 6.0.0 September 25, 2020¶ Improved search result look and feel Improved search result stability while typing Improved search result grouping (pages + headings) Improved search result relevance and scoring Added display of missing query terms to search results Reduced size of vendor bundle by 25% (84kb → 67kb) Reduced size of the Docker image to improve CI build performance Removed hero partial in favor of custom implementation Removed deprecated front matter features 5.5.14 September 23, 2020¶ Improved spacing around image captions Fixed #1939: Long tables cause header overlap in print view 5.5.13 September 19, 2020¶ Improved abbreviations on touch devices 5.5.12 August 31, 2020¶ Fixed #1638: occasional 404 for images when using instant loading 5.5.11 August 28, 2020¶ Fixed Disqus integration, as the minifier killed the config 5.5.10 August 28, 2020¶ Improved rendering by moving Disqus integration after page load Fixed #1887: Moved navigation icons to CSS to reduce size of HTML 5.5.9 August 26, 2020¶ Added Esperanto translations Fixed #1884: External links not included in navigation tabs 5.5.8 August 23, 2020¶ Removed focus outline on details and content tabs for pointer devices Improved accessibility of content tabs (now navigable via arrow keys) Fixed #1877: 404 on search index when search is disabled Fixed some memleaks in observable subscriptions Fixed color definitions for theme-color meta tag 5.5.7 August 16, 2020¶ Improved contrast ratio to 4.5:1 for syntax highlighting Improved contrast ratio to 4.5:1 for table of contents 5.5.6 August 12, 2020¶ Switched base template for 404.html to main.html Fixed #1864: GitHub organisation stats not loading 5.5.5 August 11, 2020¶ Fixed missing vendor and worker distribution files 5.5.4 August 11, 2020¶ Added support for sortable data tables 5.5.3 August 4, 2020¶ Fixed search for languages other than English (5.5.1 regression) 5.5.2 August 3, 2020¶ Improved highlight colors and spacing for ins, del and mark Changed some keyboard symbols for better equivalents Removed focus outline for details and code blocks on touch devices Fixed margins for admonitions (5.5.1 regression) Fixed too small content tab labels (5.5.1 regression) Fixed icon repeating for custom admonition icons 5.5.1 August 1, 2020¶ Improved typesetting by basing font-size and spacings on em Improved print view by slightly scaling down font-size Changed custom site title (metadata) to be suffixed with site name Fixed top- and bottom spacing of paragraphs inside table cells 5.5.0 July 24, 2020¶ Rewrite of entire documentation Rewrite of syntax highlighting to be customizable with CSS variables Improved syntax highlighting to work with light and dark theme Improved slate color scheme to be more customizable and easier on the eyes Added licenses of icon sets to distribution files Fixed stale document titles in Google Analytics when using instant loading Fixed width of previous and next footer links for tablet and above Fixed issues with top scroll margin for footnotes Fixed top margin for tabbed content when using a JavaScript highlighter Deprecated metadata-based redirects, source links and heroes 5.4.0 June 29, 2020¶ Added support to wrap searches in quotes to switch from OR to AND Fixed highlighting of numbers in search results 5.3.3 June 24, 2020¶ Added Be","tokens":15000,"squid":"spider-06","role":"Security Spider","at":1791341001370,"hash":"88c9c6ee28ad35b4d0e7f77162abf772d7af1447"}
{"url":"https://forum.arbitrum.foundation/t/how-to-submit-a-dao-proposal/13494/1","domain":"forum.arbitrum.foundation","title":"How to submit a DAO Proposal - Proposals - Arbitrum","text":"The Arbitrum Foundation notified the Security Council on the need to perform a potential Emergency action. Following a review of the details and known risks, the Security Council decided to execute the upgrade and it was completed at 11:30 EST on 2nd October 2026.\nThis report provides an overview of the risks that required the Security Council Action:\n\nAdd a permissionless guard for the One-Step Proof of BoLD on Arbitrum One\n\nTemporarily pause activation of new Stylus contracts on Arbitrum One & Nova\n\nKey point: To date, known bugs for Stylus primarily impact chain liveness (e.g., denial of service attacks) and do not put any user funds at risk.\nWhy was this action taken\nLet’s take this opportunity to explain why action was taken on two separate issues concerning BoLD and Stylus.\nInstalling the guard for One-Step Proof of BoLD. Given the rise of AI-assisted attacks, we have implemented a precautionary approach that allows anyone to pause settlement of Arbitrum One on Ethereum if there are at least two conflicting answers that pass at the same level in which only one should be valid and pass. This is to halt a class of publicly verifiable and detectable attacks that exploit a bug in the one-step proof. If halted, Arbitrum One will continue to process as normal except that messages from Arbitrum One to Ethereum, such as withdrawals, that are not yet confirmed will have to wait. This provides time for the Security Council to deploy a fix for the bug and resume the rollup.\nPreventing activation of new Stylus contracts. AI-assisted tooling has led to an increasing number of sophisticated attacks on hand-crafted WASM programs that do not use the standard Stylus compiler toolchain. These programs are specifically designed to cause unexpected behaviors such as degrading the chain’s performance for all other users. To date, no attacks have been discovered that permits theft of user funds.\nNew ArbOS releases have patched several reported bugs and known attacks over the past few months, but out of an abundance of caution, we have decided to temporarily pause new activations of Stylus contracts. This was executed as an emergency action to prevent the deployment of new hand-crafted WASM programs that are not yet patched by the current version of ArbOS on the Arbitrum network.\nThe Arbitrum Foundation has informed the Security Council that they will work with the ArbitrumDAO to discuss next steps on the timeline and manner for enabling activation of new Stylus contracts. The Arbitrum community remains confident in the value of Stylus and want to preserve these use cases while taking preventative measures against Stylus-based attack vectors as AI-assisted attack tooling continues to evolve.\nImpact on builders and users\n\nNo new activations. New Stylus contracts cannot be activated during the pause including new versions of existing applications that require activation.\n\nExisting contracts are not paused. Already-active Stylus contracts continue to execute until expiration. This pause does not deactivate them.\n\nThe ArbOS 61 upgrade renewed all active contracts on Arbitrum One, so no currently active contract expires before August 20, 2027.\n\nRenewal via keepalive stays permissionless and is unaffected by the pause.\n\nReactivating an expired contract, or one that needs to be updated after a Stylus version change, is paused.\n\nUsing/calling any activated Stylus contract stays permissionless for all users and developers.\n\nNo impact on EVM. Solidity (EVM) contract deployment and execution are unaffected by this Security Council action.\n\nSecurity Council Actions\nThere are two actions bundled into a single payload:\n\nOne-Step Proof Guard. The L1UpgradeExecutor gives a new pause contract (PauseExecutor) the ability to pause and nothing else. The new pause contract grants the guard (OspSoundnessGuard) PAUSER_ROLE to use it. Anyone can show the guard two conflicting answers to the same step of an open challenge. If the one-step proof accepts both, the guard has the pause contract put Arbitrum One’s settlement to Ethereum on hold.\n\nStylus deactivation. The Security Council called ArbOwner.setWasmActivationGas(2^64 - 1) to raise the Stylus activation gas requirement on Arbitrum One and Nova. This makes activation prohibitively expensive and effectively disables new activations. This is a configuration change and does not require an ArbOS upgrade.\n\nThe Security Council signed the following transactions to update the configuration:\n\nEthereum: Ethereum Transaction Hash: 0x30732bb7d2... | Etherscan\nArbitrum One:\nArbitrum One Transaction Hash: 0x9eb3a4be3b... | Arbitrum One\nArbitrum Nova:\nArbitrum Nova transaction 0x79e0fed470dff7a22059b108e3f8f42eddd2b580a6771594060c4e7326c5f984 | Blockscout\n\nAn external audit was conducted for the OSP Guard contracts. No audit is required for the Stylus deactivation as it is only updating a single parameter in the ArbOS configuration.\n\n How to submit a DAO Proposal \n\n Proposals\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Apr 2023\n\n 1 / 3\n\n Apr 2023\n\n Apr 2023\n\n post by Arbitrum on Apr 6, 2023\n\n Arbitrum\n\n How to submit a DAO Proposal\n1. Discourse\nhttps://forum.arbitrum.foundation/ is a forum for governance related discussions.\nCommunity members must register for an account before sharing or liking posts.\nThe Proposal is suggested on the discourse and discussed for 1 week.\nTo create a Proposal:\nNavigate to the Proposals Category and create a new topic.\nThe proposal should have the following format:\n\nTitle – Proposal: [Insert Description]\nConstitutional / Non-Constitutional - For clarity, please refer to section 2 of the Constitution\nAbstract - Two or three sentences that summarize the AIP.\nMotivation - A statement on why the Arbitrum community should implement the AIP.\nRationale - An explanation of how the AIP aligns with the Arbitrum community’s mission and guiding values.\nKey Terms (optional) - Definitions of any terms within the proposal that are unique to the proposal, new to the Arbitrum community, and/or industry-specific.\nSpecifications - A detailed breakdown of the platforms and technologies that will be used.\nSteps to Implement - The steps to implement the AIP, including associated costs, manpower, and other resources for each step where applicable. For the avoidance of doubt, any AIPs involving transactions with third parties (such as grants) will need to ensure that applicable legal documentation and procedures are also included.\nTimeline - Relevant timing details, including but not limited to start date, milestones, and completion dates.\nOverall Cost - The total cost to implement the AIP.\nConflicts of Interest - The nature and extent of any direct or indirect conflict of interest that may exist for proposal authors regarding the proposal.\n\nAdditional fields can be added to any template if necessary to fully communicate the intentions, specifics, and implications.\nIf an AIP did not pass, resubmitted AIPs should also include:\n\nA link to the original AIP;\nReason the original AIP was not approved;\nChanges that have been made and why it should now be approved\n\n2. Snapshot\nSnapshot is an off-chain voting interface that allows the community to signal sentiment (i.e. temperature check) on the proposed AIP. The vote will be open for 1 week.\nTo create a snapshot vote:\n\nNavigate to Snapshot to create a poll\nConnect your wallet.\nCreate a poll that points to your forum post.\nThe poll should run for one week and should be decided by a simple majority.\nNavigate back to your forum post and share the link to your Snapshot poll with the community.\n\n3. On-chain Vote\nhttps://alt.gov.arbitrum.foundation/* serves as the on-chain voting platform for the ArbitrumDAO to submit and vote on AIPs and serves as a front-end user interface that allows DAO members to do several things, namely:\n\nCreate AIPs;\nView delegates and their voting share;\nDelegate and re-delegate ;\nView current and past AIPs;\nVote on AIPs on-chain, interacting with the on-chain governance contracts via the front-end; and\nView the status of AIP execution during all voting stages\n\n*Alternatively, DAO members can use the backup on-chain governance UI (maintained by Snapshot).\nThere is a detailed breakdown on how to submit a DAO Proposal here:\n\n About the Grants Discussions category\n\n Proposal: The Arbitrum Coalition\n\n Create a Discord Category Channel for Governance\n\n Proposal Submission, Pitching & Judging Process\n\n SEED Latam Delegate Communication Thread\n\n 1 year later\n\n Closed on Jul 10, 2024\n\n Pinned on Jul 10, 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 The Incomplete Guide to Submitting a Proposal to Arbitrum DAO\n\n Proposals\n\n governance\n\n 3\n\n 1.4k\n\n Apr 2024\n\n Writing Your First Proposal to the ArbitrumDAO\n\n Guides & Documentation\n\n 0\n\n 1.7k\n\n Dec 2024\n\n Proposal: AIP-1.2 - Foundation and DAO Governance\n\n Finalized AIPs\n\n tally,passed\n\n 65\n\n 19.0k\n\n Jun 2023\n\n Frisson Delegate Communication Thread\n\n Delegate Statements\n\n delegation,delegate-statements\n\n 76\n\n 1.1k\n\n Apr 2025\n\n Team 2: Accelerating Arbitrum Governance\n\n GovHack Denver\n\n 0\n\n 658\n\n Feb 2024","tokens":2294,"squid":"spider-07","role":"Council Spider","at":1791341042276,"hash":"0752bc348edd8dbe2ff7c25f8ed366d8168eea13"}
{"url":"https://eips.ethereum.org/EIPS/eip-234","domain":"eips.ethereum.org","title":"EIP-234: Add `blockHash` to JSON-RPC filter options.","text":"🎉 Final\n\n Standards Track: Interface\n\n EIP-234: Add `blockHash` to JSON-RPC filter options.\n\n Authors\n Micah Zoltu (@MicahZoltu)\n\n Created\n 2017-03-24\n\n Requires\n\n EIP-1474\n\n Simple Summary\n\nAdd an option to JSON-RPC filter options (used by eth_newFilter and eth_getLogs) that allows specifying the block hash that should be included in the results. This option would be an alternative to fromBlock/toBlock options.\n\n Abstract\n\nThis addition would allow clients to fetch logs for specific blocks, whether those blocks were in the current main chain or not. This resolves some issues that make it difficult/expensive to author robust clients due to the nature of chain reorgs, unreliable network connections and the result set not containing enough details in the empty case.\n\n Specification\n\nThe filter options used by eth_newFilter would have an additional optional parameter named blockHash whose value is a single block hash. The Ethereum node responding to the request would either send back an error if the block hash was not found or it would return the results matching the filter (per normal operation) constrained to the block provided. Internally, this would function (presumably) similar to the fromBlock and toBlock filter options.\n\n Rationale\n\nA client (dApp) who needs reliable notification of both log additions (on new blocks) and log removals (on chain reorgs) cannot achieve this while relying solely on subscriptions and filters. This is because a combination of a network or remote node failure during a reorg can result in the client getting out of sync with reality. An example of where this can happen with Websockets is when the client opens a web socket connection, sets up a log filter subscription, gets notified of some new logs, then loses the web socket connection, then (while disconnected) a re-org occurs, then the client connects back and establishes a new log filter. In this scenario they will not receive notification of the log removals from the node because they were disconnected when the removals were broadcast and the loss of their connection resulted in the node forgetting about their existence. A similar scenario can be concocted for HTTP clients where between polls for updates, the node goes down and comes back (resulting in loss of filter state) and a re-org also occurs between the same two polls.\n\nIn order to deal with this while still providing a robust mechanism for internal block/log additional/removal, the client can maintain a blockchain internally (last n blocks) and only subscribe/poll for new blocks. When a new block is received, the client can reconcile their internal model with the new block, potentially back-filling parents or rolling back/removing blocks from their internal model to get in sync with the node. This can account for any type of disconnect/reorg/outage scenario and also allows the client (as an added benefit) to talk to a cluster of Ethereum nodes (e.g., via round-robin) rather than being tightly coupled to a single node.\n\nOnce the user has a reliable stream of blocks, they can then look at the bloom filter for the new block and if the block may have logs of interest they can fetch the filtered logs for that block from the node. The problem that arises is that a re-org may occur between when the client receives the block and when the client fetches the logs for that block. Given the current set of filter options, the client can only ask for logs by block number. In this scenario, the logs they get back will be for a block that isn’t the block they want the logs for and is instead for a block that was re-orged in (and may not be fully reconciled with the internal client state). This can be partially worked around by looking at the resulting logs themselves and identifying whether or not they are for the block hash requested. However, if the result set is an empty array (no logs fetched) then the client is in a situation where they don’t know what block the results are for. The results could have been legitimately empty (bloom filter can yield false positives) for the block in question, or they could be receiving empty logs for a block that they don’t know about. At this point, there is no decision the client can make that allows them a guarantee of recovery. They can assume the empty logs were for the correct block, but if they weren’t then they will never try to fetch again. This creates a problem if the block was only transiently re-orged out because it may come back before the next block poll so the client will never witness the reorg. They can assume the empty logs were for the wrong block, and refetch them, but they may continue to get empty results putting them right back into the same situation.\n\nBy adding the ability to fetch logs by hash, the client can be guaranteed that if they get a result set, it is for the block in question. If they get an error, then they can take appropriate action (e.g., rollback that block client-side and re-fetch latest).\n\n Backwards Compatibility\n\nThe only potential issue here is the fromBlock and toBlock fields. It wouldn’t make sense to include both the hash and the number so it seems like fromBlock/toBlock should be mutually exclusive with blockHash.\n\n Test Cases\n\n{ \"jsonrpc\": \"2.0\", \"id\": 1, \"method\": \"eth_getLogs\", params: [{\"blockHash\": \"0xbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0c\"}] } should return all of the logs for the block with hash 0xbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0c. If a topics field is added to the filter options then a filtered set of logs for that block should be returned. If no block exists with that hash then an error should be returned with a code of -32000, a message of \"Block not found.\" and a data of \"0xbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0c\".\n\n Implementation\n\n Geth\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-234: Add `blockHash` to JSON-RPC filter options.,\" Ethereum Improvement Proposals, no. 234, March 2017. Available: https://eips.ethereum.org/EIPS/eip-234.","tokens":1535,"squid":"spider-05","role":"Spec Spider","at":1791341044737,"hash":"9acea64d7149f1e4570550406688442ffa61a1d7"}
{"url":"https://docs.arbitrum.foundation/dao-constitution","domain":"docs.arbitrum.foundation","title":"The Amended Constitution of the ArbitrumDAO | Arbitrum DAO - Governance docs","text":"✏️Request an updateThis document lays out the Amended Constitution of the ArbitrumDAO. The original Constitution of the ArbitrumDAO took effect on the date upon which AIP-1 was posted, located at https://forum.arbitrum.foundation/t/aip-1-arbitrum-improvement-proposal-framework/30.Some of the rules and procedures of this Constitution will be enforced directly by smart contracts on a blockchain, and some will not. All rules are equally binding. Actions taken under this Constitution may be on-chain or off-chain actions. On-chain actions are those that are actuated directly by the governance smart contracts of the DAO as transactions on a blockchain. Off-chain actions are those that are actuated by other means.This Constitution also includes some \"recommended guidelines\" which are non-binding but strongly recommended as good governance practice.This Constitution describes the procedures by which it may be amended and lays out the governance framework of the ArbitrumDAO and The Arbitrum Foundation.Definitions:AIP: An Arbitrum Improvement ProposalArbitrumDAO-governed chains: The Arbitrum One and Arbitrum Nova chains and any additional chains authorized by the ArbitrumDAODAO Treasury: All $ARB tokens held in a governance smart contract governed directly by the ArbitrumDAO and/or the Security Council of The Arbitrum Foundation via on-chain voting mechanismsDelegated Votable Tokens: The number of all Votable Tokens that have been delegated and eligible to vote on AIPsGoverned Chains: Any ArbitrumDAO-approved chains that are governed by the $ARB tokenNon-Governed Chains: Any ArbitrumDAO-approved chains that are not governed by the $ARB tokenVotable Tokens: All $ARB tokens in existence, excluding any tokens held by The Arbitrum Foundation and any unclaimed airdropsSection 1: Chain \"ownership\"​This Constitution describes the decision-making framework for the ArbitrumDAO governance and/or authorization of the ArbitrumDAO-approved chains. The DAO may authorize the creation of additional Layer-2 chains that settle to Ethereum using the Arbitrum technology, but each such additional Layer-2 chain must be authorized by a corresponding AIP (i.e., no more than one chain may be authorized in each AIP). Any chain that is so authorized may be governed by the $ARB token and this Constitution, in which case, such chain would be deemed a Governed Chain. Any chain that is authorized but not governed by the $ARB token will be deemed a Non-Governed Chain. For the avoidance of doubt, any ArbitrumDAO-approved chain (whether a Governed Chain or a Non-Governed Chain) must settle to or on Ethereum. Chains utilizing Arbitrum technology that settle to or on ArbitrumDAO-approved chains (i.e., as “layer 3s”) do not require ArbitrumDAO authorization.The Arbitrum protocol allows each chain to have one or more \"chain owners\" who have the power to take administrative actions that change a chain's core protocol and code and/or alter any of its core parameters. The \"chain owner\" will also have the power to upgrade certain associated Layer 1 contracts. The \"chain owner\" will control affordances on the chain such as updating the contract implementation of any of Arbitrum's core protocol Transparent Upgradeable Proxy contracts, and adjusting system parameters via, e.g., setter methods in the ArbOwner precompile.With the $ARB token generation event and subsequent creation of the ArbitrumDAO having occurred, \"owner\" privileges on both the Arbitrum One and Arbitrum Nova chains have been given to both the ArbitrumDAO and the Security Council of The Arbitrum Foundation.Section 2: DAO Proposals and Voting Procedures​The following process governs the rules and procedures by which the ArbitrumDAO may propose, vote on and implement Arbitrum Improvement Proposals (AIPs). No AIP may be in violation of applicable laws, in particular sanctions-related regulations.Phase 0: Forum Post (1 week) (Optional but Recommended): The AIP is suggested on the public forum and discussed/debated for 1 week.Phase 1: Temperature Check (1 week) (Optional but Recommended): The AIP should be accompanied by an off-chain temperature check poll or other method as determined pursuant to the governance process, which can only be submitted by an address that can vote at least 500,000 of the Votable Tokens. The off-chain temperature check runs for 1 week, and is decided by a simple majority with no required participation threshold. An AIP that fails the temperature check should not be submitted for a vote. If an AIP fails the temperature check, or has not undergone a temperature check, as a matter of good governance practice, it is recommended that voters strongly consider voting to reject it.Phase 2: Formal AIP and call for voting (3 days): The AIP is submitted via governance contracts on Arbitrum One, with a user interface available on https://alt.gov.arbitrum.foundation/. The AIP proposer is required to have an address that is delegated at least 1,000,000 Votable Tokens.After 3 days, a voter distribution snapshot will be taken and the voting period will begin; this gives interested parties time to discuss the AIP and gather votes before the voter distribution snapshot is taken.Each AIP must be labeled as Constitutional or non-Constitutional.A Constitutional AIP is one that:Process: Modifies the text or procedures of this Constitution and, so long as The Arbitrum Foundation exists, the Amended & Restated Memorandum and Articles of Association and the Amended & Restated Bylaws of The Arbitrum FoundationSoftware update: Installs or modifies software on any chainCore: Takes any action that requires \"chain owner\" permission on any chainNew Chain Approval: Authorizes a new chain as approved by the ArbitrumDAO. This includes authorizing both Governed Chains and Non-Governed ChainsRecommended guideline: DAO members should vote against any AIP that is incorrectly labeled.A Non-Constitutional AIP is one that is not considered a \"Constitutional AIP\" including:Funding: Requests funds/grants or otherwise propose how to spend or allocate funds from the DAO Treasury and, so long as The Arbitrum Foundation exists, the Administrative Budget Wallet as defined in The Arbitrum Foundation’s Amended & Restated BylawsInformational: Provides general guidelines or information to the community but does not otherwise propose a new feature or updateEach AIP must also clearly specify which Governed Chain(s) it will affect (this may be specified by code, data, or text, as appropriate for the specific AIP).As a recommended guideline, an AIP should include:Abstract - Two or three sentences that summarize the AIP.Motivation - A statement on why the Arbitrum community should implement the AIP.Rationale - An explanation of how the AIP aligns with the Arbitrum community's mission and guiding values.Key Terms (optional) - Definitions of any terms within the proposal that are unique to the proposal, new to the Arbitrum community, and/or industry-specific.Specifications - A detailed breakdown of the platforms and technologies that will be used.Steps to Implement - The steps to implement the AIP, including associated costs, manpower, and other resources for each step where applicable. For the avoidance of doubt, any AIPs involving transactions with third parties (such as grants) will need to ensure that applicable legal documentation and procedures are also included.Timeline - Relevant timing details, including but not limited to start date, milestones, and completion dates.Overall Cost - The total cost to implement the AIP.As a recommended guideline, the AIP author can add additional fields to any template if necessary to fully communicate the intentions, specifics and implications of the AIP.As a recommended guideline, resubmitted AIPs should also include:A link to the original AIP;Reasons such original AIP was not approved;Changes that have been made and why it should now be approved; andAny additional fields to any template if necessary to fully communicate the changes made and the intentions, specifics and implications of such resubmitted AIP.Phase 3: DAO votes on AIP, on Arbitrum One (14-16 days): During this Phase 3, the ArbitrumDAO will be able to vote directly on-chain on a submitted AIP.An AIP passes if the following 2 conditions are met:More Votable Tokens have cast votes \"in favor\" than have cast votes \"against\" (\"Threshold 1\"); and(\"Threshold 2\") In the case of a:Constitutional AIP, at least a number of all Delegated Votable Tokens have cast votes either \"in favor\" or \"abstain\", determined in accordance with the below formula:If the product of 0.5 and the Delegated Votable Tokens (\"Preliminary Constitutional Quorum Value\") is less than 150,000,000, then 150,000,000 applies; orIf the Preliminary Constitutional Quorum Value is greater than 150,000,000, but less than 450,000,000, then the Preliminary Constitutional Quorum Value applies; orIf the Preliminary Constitutional Quorum Value is greater than 450,000,000, then 450,000,000 applies.Non-Constitutional AIP, at least a number of all Delegated Votable Tokens have cast votes either \"in favor\" or \"abstain\", determined in accordance with the below formula:If the product of 0.4 and the Delegated Votable Tokens (\"Preliminary Non-Constitutional Quorum Value\") is less than 100,000,000, then 100,000,000 applies; orIf the Preliminary Non-Constitutional Quorum Value is greater than 100,000,000, but less than 300,000,000, then the Preliminary Non-Constitutional Quorum Value applies; orIf the Preliminary Non-Constitutional Quorum Value is greater than 300,000,000, then 300,000,000 applies.The voting period ends 14 days after the start of voting. However, if Threshold 2 was reached within the last 2 days of the 14-day voting period, the voting period will be extended to end 2 days after Threshold 2 was reached.If the AIP fails to pass, the process ends after this Phase 3.If the AIP passes, then:If it is a Constitutional AIP, Phases 4 through 7 below are carried out.If it is a Non-Constitutional AIP, Phase 4 is carried out, and then Phases 5 and 6 are bypassed, after which the AIP enters Phase 7 immediately.Phase 4: L2 Waiting Period (3 or 8 days): After an AIP has passed Phase 3, there is a 3 day waiting period for actions related to the DAO Treasury and an 8 day waiting period for an L2-to-L1 Message. This gives users who object to the AIP time to initiate withdrawal of their funds or take other action on L2.Phase 5: Initiate and Finalize an L2-to-L1 Message (at least 1 challenge period of the rollup protocol): After the waiting period for Phase 4 has passed, an L2-to-L1 message is sent indicating that the AIP was passed. When this message is finalized on L1, anyone can redeem it to complete this step and initiate the next step. This step ensures that the completion of the L2 waiting period will be recognized on L1 after any withdrawals initiated during or soon after the voting period have been recognized on L1.Phase 6: L1 Waiting Period (3 days): Following the completion of Phase 5, there will be an additional 3 day waiting period. This ensures that users who initiated withdrawals or other L2-to-L1 messages have time to execute them on L1 before the AIP takes effect.Phase 7: Implementation: The AIP is fully executed and implemented. This may happen on L1 or via a transaction sent from L1 to one or more Governed Chains.This AIP process as specified will typically require at least 42 days from the beginning of the temperature check in Phase 1 until an AIP is finally executed in Phase 7 for a Constitutional AIP, or at least 27 days for a Non-Constitutional AIP. An AIP may optionally specify further delay before its implementation.Section 3: The Security Council​The Security Council is a committee of 12 members who are signers of a multi-sig wallet, which has powers to perform certain Emergency Actions and Non-Emergency Actions, as delegated to it by the ArbitrumDAO and The Arbitrum Foundation, and is responsible for upholding this ArbitrumDAO Constitution. Through the submission, approval and implementation of a Constitutional AIP, the ArbitrumDAO is able to modify the Security Council's powers or to eliminate the Security Council entirely.Equivalent \"copies\" of the Security Council multi-sig contracts exist, one on Ethereum and another on each ArbitrumDAO-governed chain. A Security Council Member can independently rotate their signing key in the multi-sigs, but the rotation must go through Phases 4 to 7 of the AIP process. In Phase 4, it adheres to the waiting time for an L2 to L1 message.Emergency Actions:The Security Council has the power to execute any software upgrade or perform other required actions with no delay in order to respond to a security emergency, should one arise (such actions, \"Emergency Actions\"). Performing any Emergency Action requires a 9-of-12 approval from the Security Council. The Security Council must not use its power to perform Emergency Actions except in a true security emergency, such as a critical vulnerability that could significantly compromise the integrity, confidentiality, or availability of a chain governed by the ArbitrumDAO.After performing any Emergency Action, the Security Council must issue a full transparency report (at an appropriate time after the security emergency has passed) to explain what was done and why such Emergency Action was justified.The ArbitrumDAO is able to curtail or eliminate the Security Council's power to perform Emergency Actions via approval and implementation of a Constitutional AIP.Non-Emergency Actions:The Security Council may also approve and implement routine software upgrades, routine maintenance and other parameter adjustments in a non-emergency setting (such actions, \"Non-Emergency Actions\"), which require a 9-of-12 approval in order to take effect. Any Non-Emergency Action, after approval by the Security Council, will bypass Phases 1 to 3 of the AIP process and instead directly go through Phases 4 to 7 of the AIP process, to provide a delay before any Non-Emergency Action is deployed. The Security Council may optionally specify additional delays before deployment.The ArbitrumDAO is able to curtail or eliminate the Security Council's power to perform Non-Emergency Actions via approval and implementation of a Constitutional AIP.Section 4: Security Council Elections​The Security Council has 12 members, who are divided into two Cohorts of 6 members.The initial Security Council Cohorts were determined by randomly splitting the 12 members into two 6-member cohorts - 6 members in the ‘First Cohort’ and 6 members in the ‘Second Cohort’. The members of the initial Security Council Cohorts are detailed in a transparency report here.The first Security Council election commenced on 15th September 2023, following the availability of an on-chain election process that was approved and installed by the ArbitrumDAO. This first election replaced the 'First Cohort'. The next election replaced the 'Second Cohort' and so forth.The date chosen for the first election formed the basis for all future elections. Every election should begin 12 months after the previous election has started and it will replace its respective cohort of 6 members.All Security Council members are expected to serve their term until the election is complete and the new Security Council members are installed.The following timeline governs an election that starts at time T:Contender submission (T until T+7 days): Any DAO member may declare their candidacy for the Security Council, provided that a current Security Council member in one cohort may not be a candidate for a seat in the other cohort.Nominee selection (T+7 until T+14 days): Each DAO member or delegate may vote for their declared contender. Each token may be cast for one contender. To the extent that there are more than six contenders, each eligible contender must be supported by pledged votes representing at least 0.1% of all Votable Tokens.Compliance process (T+14 until T+28 days): All candidates will cooperate with the Arbitrum Foundation and complete the compliance process. If candidates need to rotate their signer addresses during a Security Council election, they must do so before day T+25 (during the compliance process). The Arbitrum Foundation is responsible for removing any candidates who fail the compliance process. In the event that fewer than six candidates are supported by pledged votes representing at least 0.1% of all Votable Tokens, the current Security Council members whose seats are up for election may become candidates (as randomly selected out of their Cohort) until there are 6 candidates.Member election (T+28 until T+49 days): Each DAO member or delegate may vote for any declared candidate. Each token may be cast for one candidate. Votes cast before T+35 days will have 100% weight. Votes cast between T+35 days and T+49 days will have weight based on the time of casting, decreasing linearly with time, with 100% weight at T+35 days, decreasing linearly to 0% weight at T+49 days.At T+49 days: The process for replacing the cohort of security council members with the 6 candidates who received the most votes will be activated. The installation process must be executed via the on-chain governance smart contracts and it may take several days until the new security council members are installed.The Arbitrum Foundation is allocated 14 days for the Compliance process and it should be executed between the Nominee selection and Member election. The Arbitrum Foundation has flexibility to update its compliance policy for every new election. This is required to allow The Arbitrum Foundation to comply with Cayman Island laws. Furthermore, The Arbitrum Foundation maintains the right to issue new procedures and guidelines for off-chain components of the Security Council election. All efforts should be made by The Arbitrum Foundation to ensure an orderly, fair, and transparent election.As a matter of best practice for maintaining an independent Security Council, no single organization should be overly represented in the Security Council. In particular, there should not be more than 3 candidates associated with a single entity or group of entities being elected to the Security Council, thereby ensuring that there will be no single entity or group of entities able to control or even veto a Security Council vote.Furthermore, no candidate with conflicts of interest that would prevent them from acting in the best interests of the ArbitrumDAO, Governed Chains and/or The Arbitrum Foundation should be elected to the Security Council. Potential conflicts of interest could be, but are not limited to, affiliations with direct Arbitrum competitors, proven histories of exploiting projects and others.The DAO may approve and implement a Constitutional AIP to change the rules governing future Security Council elections, but the AIP process may not be used to intervene in an ongoing election.Security Council members may only be removed prior to the end of their terms under two conditions:At least 10% of all Votable Tokens have cast votes either \"in favor\" of removal or \"abstain\", and at least 5/6 (83.33%) of all cast votes are \"in favor\" of removal; orAt least 9 of the Security Council members vote in favor of removal.The seats of Security Council members who have been removed prior to the end of their respective terms shall remain unfilled until the next election that such seats are up for appointment, unless otherwise replaced prior to such next election by a vote of at least 9 of the Security Council members, in which case such seat shall be up for appointment at the next such election. The Security Council may not re-appoint a removed member and they can only be re-elected via the election voting system.Section 5: Data Availability Committee​Transactions occurring on the Arbitrum Nova chain are settled on Ethereum mainnet, but, unlike transactions occurring on the Arbitrum One chain, the underlying transaction data batches are posted and stored by the members of the Data Availability Committee on a Data Availability Server (and not on Ethereum mainnet).The members of the Data Availability Committee of the Nova chain are available in a transparency report here.Data Availability Committee members can be appointed and removed at any time pursuant to a Constitutional AIP approved by the ArbitrumDAO. In the event that a Data Availability Committee member is removed (and not otherwise replaced) pursuant to a Constitutional AIP approved by the ArbitrumDAO, or in the event that a Data Availability Committee member resigns without a replacement, the Security Council may execute an emergency action (9-of-12 approval required) to appoint a replacement for such removed or resigned Data Availability Committee member.Section 6: Community Values​As the guiding values of the ArbitrumDAO and The Arbitrum Foundation, Governed Chains, technology, and community should be:Ethereum-aligned: Arbitrum is part of the Ethereum ecosystem, and the Arbitrum community is part of the Ethereum community. Although the ArbitrumDAO makes its own decisions and pursues its own goals, it is deeply aligned with Ethereum and sees itself as an active and constructive participant in the Ethereum community.Sustainable: Arbitrum should be built and operated with an eye to the medium to long term. Decisions about technology, economics, and resource allocation should not value short-term optimization over the longer-term health and thriving of the Arbitrum protocol, technology and community.Secure: Arbitrum is security minded, and safety of the system should be weighed heavily when considering any protocol changes. In particular, Arbitrum One is a proper L2 rollup chain, and as such, derives its security from Ethereum; any changes made to Arbitrum One should preserve this property.Socially inclusive: The community should be open and welcoming to all people who wish to participate constructively. Differences in knowledge, resources, geography, language, and life experience should be seen as opportunities to learn and to grow the community.Technically inclusive: It should remain possible for ordinary people, with ordinary computer systems, to participate as fully as possible in the Arbitrum protocol if they wish to do so.User-focused: The Arbitrum ecosystem should be managed for the benefit of all Arbitrum users.Neutral and open: Arbitrum governance should not pick winners and losers, but should foster open innovation, interoperation, user choice, and healthy competition on Arbitrum chains.Constitution hash​0x310d1c0495cf8ff7b5e89c26fbca91b230ce6dd2b9b8bde8c1a8605545f25063To compute this hash yourself, you can clone ArbitrumFoundation/docs to your local machine and run yarn update-constitution-hash from the root directory of the repo. Alternatively, you can install Node.js, navigate to the docs folder, and run node ./scripts/updateConstitutionHash.js.This will use the keccak256 method from the @ethersproject/solidity project to compute the hash of the Constitution's markdown source code, located in /ArbitrumFoundation/docs/blob/main/docs/partials/_constitution-content-partial.mdx.Constitution hash","tokens":5800,"squid":"spider-07","role":"Council Spider","at":1791341055927,"hash":"c9de2fcb5df8ba13fcf41ea54cc49b9c5db9e5b4"}
{"url":"https://www.paradigm.xyz/puzzles/prediction-market-challenge/about","domain":"paradigm.xyz","title":"About the Prediction Market Challenge | Paradigm Puzzles","text":"← Back to LeaderboardAbout the Prediction Market ChallengeThe InstrumentYou trade a single YES share on a FIFO limit order book. The contract settles to $1 if a latent score process Zₜ finishes above zero at time T, and $0 otherwise. Prices are integer percentage ticks from 1 to 99 - a bid at tick 48 means you're willing to buy YES at 48¢. The ChallengeYou are a market maker posting passive limit orders on a shared order book. Your goal is to maximize edge - the profit you earn from providing liquidity. You can't send market orders or IOC orders; you can only place resting limit orders and cancel them.You share the book with a static competitor that maintains a hidden ladder of resting orders around the starting price. The competitor never re-anchors to fair value and never reacts to jumps - it just refills consumed levels at a fixed offset. Your advantage comes from adapting to market conditions it ignores.How Scoring WorksFor each passive fill, edge measures how much better your execution price was than the true probability at the time of the fill:Buy q shares at price x: edge = q × (p_t − x)\nSell q shares at price x: edge = q × (x − p_t)\n\nwhere p_t = Pr(Z_T > 0 | Z_t) is the true fair valueRetail fills generate positive edge (you captured the spread). Arb fills generate negative edge (the arbitrageur took stale quotes). Your leaderboard score is the mean edge across 200 simulations with randomized parameters. Higher is better.The SimulationEach simulation runs 2,000 steps. Before each simulation, hyperparameters (jump intensity, jump variance, retail arrival rate, competitor spread) are sampled randomly - your strategy doesn't know these values and must adapt from observed fills and order flow.Latent Score ProcessThe underlying score follows a Gaussian random walk with compound Poisson jumps:Z_{t+1} = Z_t + σ·ε_t + Σ J_{t,k}\n\nε_t ~ N(0, 1) Gaussian diffusion (fixed σ = 0.02)\nN_t ~ Poisson(λ_jump) jump count per step\nJ_{t,k} ~ N(μ_jump, σ_jump²) jump sizesThe diffusion term is fixed across all simulations. The regime-level variation comes entirely from the jump parameters - intensity, mean, and variance - which are randomized per simulation. With ~2 expected jumps per simulation at default intensity, each jump is a significant information shock.True ProbabilityThe informed fair value at step t with H steps remaining is:p_t = Pr(Z_T > 0 | Z_t)\n = Σ Poi(n; λ·H) × Φ((Z_t + n·μ) / √(H·σ² + n·σ_jump²))Your strategy does not receive pₜ or Zₜ. You must infer market conditions from fills, your inventory, and the competitor's best bid and ask.Event LoopEach step follows this sequence:Competitor replenishments from previous stepYour on_step callback - you see fills from last step and place new ordersLatent score advances to Zₜ, true probability pₜ computedArbitrageur sweeps all stale quotes vs pₜRetail market orders arrive and match against the bookYou quote before the next price move, so you are always exposed to adverse selection. The arb executes before retail, matching the AMM challenge structure.CounterpartiesThree other actors trade on the book:Arbitrageur: Knows pₜ. Sweeps every resting ask below pₜ and every resting bid above pₜ. Infinite capital, never rests orders.Retail: Uninformed flow arriving via Poisson process. Equal probability buy or sell. Notional is LogNormal-distributed. This is your profit source.Competitor: Static hidden-liquidity ladder. Quotes every tick outside its spread with fixed notional. Refills consumed levels at a fixed offset next step. Never re-centers.Writing a StrategyStrategies are written in Python and must extend BaseStrategy. You implement a single method, on_step, called once per timestep with your current state. Return a list of actions: place limit orders, cancel specific orders, or cancel all.on_stepdef on_step(self, state: StepState) -> Sequence[Action]:\n # state contains:\n # step: int current tick number\n # steps_remaining: int steps until settlement\n # yes_inventory: float your YES holdings\n # no_inventory: float your NO holdings\n # cash: float total cash\n # reserved_cash: float cash locked in resting orders\n # free_cash: float available cash\n # competitor_best_bid_ticks: int | None\n # competitor_best_ask_ticks: int | None\n # fills: tuple[Fill, ...] fills from last step\n # own_orders: tuple[OwnOrderView, ...]\n\n return [CancelAll(), PlaceOrder(side=Side.BUY, price_ticks=p, quantity=q), ...]You start with $1,000 cash, 0 YES, and 0 NO. Minting one YES and one NO costs $1. Resting bids reserve price × quantity cash; uncovered asks reserve (1 − price) × quantity.Example: Simple Ladderfrom orderbook_pm_challenge.strategy import BaseStrategy\nfrom orderbook_pm_challenge.types import CancelAll, PlaceOrder, Side, StepState\n\nclass Strategy(BaseStrategy):\n \"\"\"Minimal static ladder strategy.\"\"\"\n\n quote_size = 5\n\n def on_step(self, state: StepState):\n competitor_bid = state.competitor_best_bid_ticks or 49\n competitor_ask = state.competitor_best_ask_ticks or 51\n midpoint = (competitor_bid + competitor_ask) // 2\n\n actions = [CancelAll()]\n\n if state.yes_inventory < 100:\n actions.append(\n PlaceOrder(\n side=Side.BUY,\n price_ticks=max(1, midpoint - 2),\n quantity=self.quote_size,\n )\n )\n\n if state.free_cash > 0 and state.no_inventory < 100:\n actions.append(\n PlaceOrder(\n side=Side.SELL,\n price_ticks=min(99, midpoint + 2),\n quantity=self.quote_size,\n )\n )\n\n return actionsRules & ConstraintsPassive only: Limit orders only - no market orders, IOC, or hidden ordersRate limit: 10 submissions per hourBudget: $1,000 starting cash, collateral reserved per resting orderPrivacy: Strategy code is private - only you can see yoursRanking: Highest mean edge across 200 simulations winsExceptions: Uncaught exceptions end the simulation in failureSubmit Your StrategyGitHub Repo","tokens":1447,"squid":"spider-04","role":"Research Spider","at":1791341056010,"hash":"6ce25a25677bcf199fd77213ed4a558282f17721"}
{"url":"https://eips.ethereum.org/EIPS/eip-1474","domain":"eips.ethereum.org","title":"EIP-1474: Remote procedure call specification","text":"🚧 Stagnant\n\n Standards Track: Interface\n\n EIP-1474: Remote procedure call specification\n\n Authors\n Paul Bouchon <mail@bitpshr.net>, Erik Marks (@rekmarks)\n\n Created\n 2018-10-02\n\n Discussion Link\n https://ethereum-magicians.org/t/eip-remote-procedure-call-specification/1537\n\n Simple Summary\n\nThis proposal defines a standard set of remote procedure call methods that an Ethereum node should implement.\n\n Abstract\n\nNodes created by the current generation of Ethereum clients expose inconsistent and incompatible remote procedure call (RPC) methods because no formal Ethereum RPC specification exists. This proposal standardizes such a specification to provide developers with a predictable Ethereum RPC interface regardless of underlying node implementation.\n\n Specification\n\n Concepts\n\n RFC-2119\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\n JSON-RPC\n\nCommunication with Ethereum nodes is accomplished using JSON-RPC, a stateless, lightweight remote procedure call protocol that uses JSON as its data format. Ethereum RPC methods MUST be called using JSON-RPC request objects and MUST respond with JSON-RPC response objects.\n\n Error codes\n\nIf an Ethereum RPC method encounters an error, the error member included on the response object MUST be an object containing a code member and descriptive message member. The following list contains all possible error codes and associated messages:\n\n Code\n Message\n Meaning\n Category\n\n -32700\n Parse error\n Invalid JSON\n standard\n\n -32600\n Invalid request\n JSON is not a valid request object\n standard\n\n -32601\n Method not found\n Method does not exist\n standard\n\n -32602\n Invalid params\n Invalid method parameters\n standard\n\n -32603\n Internal error\n Internal JSON-RPC error\n standard\n\n -32000\n Invalid input\n Missing or invalid parameters\n non-standard\n\n -32001\n Resource not found\n Requested resource not found\n non-standard\n\n -32002\n Resource unavailable\n Requested resource not available\n non-standard\n\n -32003\n Transaction rejected\n Transaction creation failed\n non-standard\n\n -32004\n Method not supported\n Method is not implemented\n non-standard\n\n -32005\n Limit exceeded\n Request exceeds defined limit\n non-standard\n\n -32006\n JSON-RPC version not supported\n Version of JSON-RPC protocol is not supported\n non-standard\n\nExample error response:\n\n{\n \"id\": 1337\n \"jsonrpc\": \"2.0\",\n \"error\": {\n \"code\": -32003,\n \"message\": \"Transaction rejected\"\n }\n}\n\n Value encoding\n\nSpecific types of values passed to and returned from Ethereum RPC methods require special encoding:\n\n Quantity\n\n A Quantity value MUST be hex-encoded.\n A Quantity value MUST be “0x”-prefixed.\n A Quantity value MUST be expressed using the fewest possible hex digits per byte.\n A Quantity value MUST express zero as “0x0”.\n\nExamples Quantity values:\n\n Value\n Valid\n Reason\n\n 0x\n invalid\n empty not a valid quantity\n\n 0x0\n valid\n interpreted as a quantity of zero\n\n 0x00\n invalid\n leading zeroes not allowed\n\n 0x41\n valid\n interpreted as a quantity of 65\n\n 0x400\n valid\n interpreted as a quantity of 1024\n\n 0x0400\n invalid\n leading zeroes not allowed\n\n ff\n invalid\n values must be prefixed\n\n Block Identifier\n\nThe RPC methods below take a default block identifier as a parameter.\n\n eth_getBalance\n eth_getStorageAt\n eth_getTransactionCount\n eth_getCode\n eth_call\n eth_getProof\n\nSince there is no way to clearly distinguish between a Data parameter and a Quantity parameter, EIP-1898 provides a format to specify a block either using the block hash or block number. The block identifier is a JSON object with the following fields:\n\n Property\n Type\n Description\n\n [blockNumber]\n {Quantity}\n The block in the canonical chain with this number\n\n OR [blockHash]\n {Data}\n The block uniquely identified by this hash. The blockNumber and blockHash properties are mutually exclusive; exactly one of them must be set.\n\n requireCanonical\n {boolean}\n (optional) Whether or not to throw an error if the block is not in the canonical chain as described below. Only allowed in conjunction with the blockHash tag. Defaults to false.\n\nIf the block is not found, the callee SHOULD raise a JSON-RPC error (the recommended error code is -32001: Resource not found. If the tag is blockHash and requireCanonical is true, the callee SHOULD additionally raise a JSON-RPC error if the block is not in the canonical chain (the recommended error code is -32000: Invalid input and in any case should be different than the error code for the block not found case so that the caller can distinguish the cases). The block-not-found check SHOULD take precedence over the block-is-canonical check, so that if the block is not found the callee raises block-not-found rather than block-not-canonical.\n\n Data\n\n A Data value MUST be hex-encoded.\n A Data value MUST be “0x”-prefixed.\n A Data value MUST be expressed using two hex digits per byte.\n\nExamples Data values:\n\n Value\n Valid\n Reason\n\n 0x\n valid\n interpreted as empty data\n\n 0x0\n invalid\n each byte must be represented using two hex digits\n\n 0x00\n valid\n interpreted as a single zero byte\n\n 0x41\n true\n interpreted as a data value of 65\n\n 0x004200\n true\n interpreted as a data value of 16896\n\n 0xf0f0f\n false\n bytes require two hex digits\n\n 004200\n false\n values must be prefixed\n\n Proposing changes\n\nNew Ethereum RPC methods and changes to existing methods MUST be proposed via the traditional EIP process. This allows for community consensus around new method implementations and proposed method modifications. RPC method proposals MUST reach “draft” status before being added to this proposal and the official Ethereum RPC specification defined herein.\n\n Methods\n\n web3_clientVersion\n\n Description\n\nReturns the version of the current client\n\n Parameters\n\n(none)\n\n Returns\n\n{string} - client version\n\n Example\n\n# Request\ncurl -X POST --data '{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"method\": \"web3_clientVersion\",\n \"params\": [],\n}' <url>\n\n# Response\n{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"result\": \"Mist/v0.9.3/darwin/go1.4.1\"\n}\n\n web3_sha3\n\n Description\n\nHashes data using the Keccak-256 algorithm\n\n Parameters\n\n #\n Type\n Description\n\n 1\n {Data}\n data to hash\n\n Returns\n\n{Data} - Keccak-256 hash of the given data\n\n Example\n\n# Request\ncurl -X POST --data '{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"method\": \"web3_sha3\",\n \"params\": [\"0x68656c6c6f20776f726c64\"]\n}' <url>\n\n# Response\n{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"result\": \"0xc94770007dda54cF92009BFF0dE90c06F603a09f\"\n}\n\n net_listening\n\n Description\n\nDetermines if this client is listening for new network connections\n\n Parameters\n\n(none)\n\n Returns\n\n{boolean} - true if listening is active or false if listening is not active\n\n Example\n\n# Request\ncurl -X POST --data '{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"method\": \"net_listening\",\n \"params\": []\n}' <url>\n\n# Response\n{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"result\": true\n}\n\n net_peerCount\n\n Description\n\nReturns the number of peers currently connected to this client\n\n Parameters\n\n(none)\n\n Returns\n\n{Quantity} - number of connected peers\n\n Example\n\n# Request\ncurl -X POST --data '{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"method\": \"net_peerCount\",\n \"params\": []\n}' <url>\n\n# Response\n{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"result\": \"0x2\"\n}\n\n net_version\n\n Description\n\nReturns the chain ID associated with the current network\n\n Parameters\n\n(none)\n\n Returns\n\n{string} - chain ID associated with the current network\n\nCommon chain IDs:\n\n \"1\" - Ethereum mainnet\n \"3\" - Ropsten testnet\n \"4\" - Rinkeby testnet\n \"42\" - Kovan testnet\n\nNote: See EIP-155 for a complete list of possible chain IDs.\n\n Example\n\n# Request\ncurl -X POST --data '{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"method\": \"net_version\",\n \"params\": []\n}' <url>\n\n# Response\n{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"result\": \"3\"\n}\n\n eth_accounts\n\n Description\n\nReturns a list of addresses owned by this client\n\n Parameters\n\n(none)\n\n Returns\n\n{Data[]} - array of addresses\n\n Example\n\n# Request\ncurl -X POST --data '{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"method\": \"eth_accounts\",\n \"params\": []\n}' <url>\n\n# Response\n{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"result\": [\"0xc94770007dda54cF92009BFF0dE90c06F603a09f\"]\n}\n\n eth_blockNumber\n\n Description\n\nReturns the number of the most recent block seen by this client\n\n Parameters\n\n(none)\n\n Returns\n\n{Quantity} - number of the latest block\n\n Example\n\n# Request\ncurl -X POST --data '{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"method\": \"eth_blockNumber\",\n \"params\": []\n}' <url>\n\n# Response\n{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"result\": \"0xc94\"\n}\n\n eth_call\n\n Description\n\nExecutes a new message call immediately without submitting a transaction to the network\n\n Parameters\n\n #\n Type\n Description\n\n 1\n {object}\n @property {Data} [from] - transaction sender@property {Data} to - transaction recipient or null if deploying a contract@property {Quantity} [gas] - gas provided for transaction execution@property {Quantity} [gasPrice] - price in wei of each gas used@property {Quantity} [value] - value in wei sent with this transaction@property {Data} [data] - contract code or a hashed method call with encoded args\n\n 2\n {Quantity|string|Block Identifier}\n block number, or one of \"latest\", \"earliest\" or \"pending\", or a block identifier as described in Block Identifier\n\n Returns\n\n{Data} - return value of executed contract\n\n Example\n\n# Request\ncurl -X POST --data '{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"method\": \"eth_call\",\n \"params\": [{\n \"data\": \"0xd46e8dd67c5d32be8d46e8dd67c5d32be8058bb8eb970870f072445675058bb8eb970870f072445675\",\n \"from\": \"0xb60e8dd61c5d32be8058bb8eb970870f07233155\",\n \"gas\": \"0x76c0\",\n \"gasPrice\": \"0x9184e72a000\",\n \"to\": \"0xd46e8dd67c5d32be8058bb8eb970870f07244567\",\n \"value\": \"0x9184e72a\"\n }]\n}' <url>\n\n# Response\n{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"result\": \"0x\"\n}\n\n eth_coinbase\n\n Description\n\nReturns the coinbase address for this client\n\n Parameters\n\n(none)\n\n Returns\n\n{Data} - coinbase address\n\n Example\n\n# Request\ncurl -X POST --data '{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"method\": \"eth_coinbase\",\n \"params\": []\n}' <url>\n\n# Response\n{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"result\": \"0xc94770007dda54cF92009BFF0dE90c06F603a09f\"\n}\n\n eth_estimateGas\n\n Description\n\nEstimates the gas necessary to complete a transaction without submitting it to the network\n\nNote: The resulting gas estimation may be significantly more than the amount of gas actually used by the transaction. This is due to a variety of reasons including EVM mechanics and node performance.\n\n Parameters\n\n #\n Type\n Description\n\n 1\n {object}\n @property {Data} [from] - transaction sender@property {Data} [to] - transaction recipient@property {Quantity} [gas] - gas provided for transaction execution@property {Quantity} [gasPrice] - price in wei of each gas used@property {Quantity} [value] - value in wei sent with this transaction@property {Data} [data] - contract code or a hashed method call with encoded args\n\n 2\n {Quantity|string}\n block number, or one of \"latest\", \"earliest\" or \"pending\"\n\n Returns\n\n{Quantity} - amount of gas required by transaction\n\n Example\n\n# Request\ncurl -X POST --data '{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"method\": \"eth_estimateGas\",\n \"params\": [{\n \"data\": \"0xd46e8dd67c5d32be8d46e8dd67c5d32be8058bb8eb970870f072445675058bb8eb970870f072445675\",\n \"from\": \"0xb60e8dd61c5d32be8058bb8eb970870f07233155\",\n \"gas\": \"0x76c0\",\n \"gasPrice\": \"0x9184e72a000\",\n \"to\": \"0xd46e8dd67c5d32be8058bb8eb970870f07244567\",\n \"value\": \"0x9184e72a\"\n }]\n}' <url>\n\n# Response\n{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"result\": \"0x5208\"\n}\n\n eth_gasPrice\n\n Description\n\nReturns the current price of gas expressed in wei\n\n Parameters\n\n(none)\n\n Returns\n\n{Quantity} - current gas price in wei\n\n Example\n\n# Request\ncurl -X POST --data '{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"method\": \"eth_gasPrice\",\n \"params\": []\n}' <url>\n\n# Response\n{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"result\": \"0x09184e72a000\"\n}\n\n eth_getBalance\n\n Description\n\nReturns the balance of an address in wei\n\n Parameters\n\n #\n Type\n Description\n\n 1\n {Data}\n address to query for balance\n\n 2\n {Quantity|string|Block Identifier}\n block number, or one of \"latest\", \"earliest\" or \"pending\", or a block identifier as described in Block Identifier\n\n Returns\n\n{Quantity} - balance of the provided account in wei\n\n Example\n\n# Request\ncurl -X POST --data '{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"method\": \"eth_getBalance\",\n \"params\": [\"0xc94770007dda54cF92009BFF0dE90c06F603a09f\", \"latest\"]\n}' <url>\n\n# Response\n{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"result\": \"0x0234c8a3397aab58\"\n}\n\n eth_getBlockByHash\n\n Description\n\nReturns information about a block specified by hash\n\n Parameters\n\n #\n Type\n Description\n\n 1\n {Data}\n hash of a block\n\n 2\n {boolean}\n true will pull full transaction objects, false will pull transaction hashes\n\n Returns\n\n{null|object} - null if no block is found, otherwise a block object with the following members:\n\n {Data} extraData - “extra data” field of this block\n {Data} hash - block hash or null if pending\n {Data} logsBloom - logs bloom filter or null if pending\n {Data} miner - address that received this block’s mining rewards\n {Data} nonce - proof-of-work hash or null if pending\n {Data} parentHash - parent block hash\n {Data} receiptsRoot -root of this block’s receipts trie\n {Data} sha3Uncles - SHA3 of the uncles data in this block\n {Data} stateRoot - root of this block’s final state trie\n {Data} transactionsRoot - root of this block’s transaction trie\n {Quantity} difficulty - difficulty for this block\n {Quantity} gasLimit - maximum gas allowed in this block\n {Quantity} gasUsed - total used gas by all transactions in this block\n {Quantity} number - block number or null if pending\n {Quantity} size - size of this block in bytes\n {Quantity} timestamp - unix timestamp of when this block was collated\n {Quantity} totalDifficulty - total difficulty of the chain until this block\n {Array<Transaction>} transactions - list of transaction objects or hashes\n {Array<Transaction>} uncles - list of uncle hashes\n\n Example\n\n# Request\ncurl -X POST --data '{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"method\": \"eth_getBlockByHash\",\n \"params\":[\"0xe670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331\", true]\n}' <url>\n\n# Response\n{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"result\": {\n \"difficulty\": \"0x027f07\",\n \"extraData\": \"0x0000000000000000000000000000000000000000000000000000000000000000\",\n \"gasLimit\": \"0x9f759\",\n \"gasUsed\": \"0x9f759\",\n \"hash\": \"0xe670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331\",\n \"logsBloom\": \"0xe670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331\",\n \"miner\": \"0x4e65fda2159562a496f9f3522f89122a3088497a\",\n \"nonce\": \"0xe04d296d2460cfb8472af2c5fd05b5a214109c25688d3704aed5484f9a7792f2\",\n \"number\": \"0x1b4\",\n \"parentHash\": \"0x9646252be9520f6e71339a8df9c55e4d7619deeb018d2a3f2d21fc165dde5eb5\",\n \"sha3Uncles\": \"0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347\",\n \"size\": \"0x027f07\",\n \"stateRoot\": \"0xd5855eb08b3387c0af375e9cdb6acfc05eb8f519e419b874b6ff2ffda7ed1dff\",\n \"timestamp\": \"0x54e34e8e\"\n \"totalDifficulty\": \"0x027f07\",\n \"transactions\": []\n \"transactionsRoot\": \"0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421\",\n \"uncles\": [\"0x1606e5...\", \"0xd5145a9...\"]\n }\n}\n\n eth_getBlockByNumber\n\n Description\n\nReturns information about a block specified by number\n\n Parameters\n\n #\n Type\n Description\n\n 1\n {Quantity|string}\n block number, or one of \"latest\", \"earliest\" or \"pending\"\n\n 2\n {boolean}\n true will pull full transaction objects, false will pull transaction hashes\n\n Returns\n\n{null|object} - null if no block is found, otherwise a block object with the following members:\n\n {Data} extraData - “extra data” field of this block\n {Data} hash - block hash or null if pending\n {Data} logsBloom - logs bloom filter or null if pending\n {Data} miner - address that received this block’s mining rewards\n {Data} nonce - proof-of-work hash or null if pending\n {Data} parentHash - parent block hash\n {Data} receiptsRoot -root of this block’s receipts trie\n {Data} sha3Uncles - SHA3 of the uncles data in this block\n {Data} stateRoot - root of this block’s final state trie\n {Data} transactionsRoot - root of this block’s transaction trie\n {Quantity} difficulty - difficulty for this block\n {Quantity} gasLimit - maximum gas allowed in this block\n {Quantity} gasUsed - total used gas by all transactions in this block\n {Quantity} number - block number or null if pending\n {Quantity} size - size of this block in bytes\n {Quantity} timestamp - unix timestamp of when this block was collated\n {Quantity} totalDifficulty - total difficulty of the chain until this block\n {Array<Transaction>} transactions - list of transaction objects or hashes\n {Array<Transaction>} uncles - list of uncle hashes\n\n Example\n\n# Request\ncurl -X POST --data '{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"method\": \"eth_getBlockByNumber\",\n \"params\":[\"0xe670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331\", true]\n}' <url>\n\n# Response\n{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"result\": {\n \"difficulty\": \"0x027f07\",\n \"extraData\": \"0x0000000000000000000000000000000000000000000000000000000000000000\",\n \"gasLimit\": \"0x9f759\",\n \"gasUsed\": \"0x9f759\",\n \"hash\": \"0xe670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331\",\n \"logsBloom\": \"0xe670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331\",\n \"miner\": \"0x4e65fda2159562a496f9f3522f89122a3088497a\",\n \"nonce\": \"0xe04d296d2460cfb8472af2c5fd05b5a214109c25688d3704aed5484f9a7792f2\",\n \"number\": \"0x1b4\",\n \"parentHash\": \"0x9646252be9520f6e71339a8df9c55e4d7619deeb018d2a3f2d21fc165dde5eb5\",\n \"sha3Uncles\": \"0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347\",\n \"size\": \"0x027f07\",\n \"stateRoot\": \"0xd5855eb08b3387c0af375e9cdb6acfc05eb8f519e419b874b6ff2ffda7ed1dff\",\n \"timestamp\": \"0x54e34e8e\"\n \"totalDifficulty\": \"0x027f07\",\n \"transactions\": []\n \"transactionsRoot\": \"0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421\",\n \"uncles\": [\"0x1606e5...\", \"0xd5145a9...\"]\n }\n}\n\n eth_getBlockTransactionCountByHash\n\n Description\n\nReturns the number of transactions in a block specified by block hash\n\n Parameters\n\n #\n Type\n Description\n\n 1\n {Data}\n hash of a block\n\n Returns\n\n{Quantity} - number of transactions in the specified block\n\n Example\n\n# Request\ncurl -X POST --data '{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"method\": \"eth_getBlockTransactionCountByHash\",\n \"params\": [\"0xc94770007dda54cF92009BFF0dE90c06F603a09f\"]\n}' <url>\n\n# Response\n{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"result\": \"0xc\"\n}\n\n eth_getBlockTransactionCountByNumber\n\n Description\n\nReturns the number of transactions in a block specified by block number\n\n Parameters\n\n #\n Type\n Description\n\n 1\n {Quantity|string}\n block number, or one of \"latest\", \"earliest\" or \"pending\"\n\n Returns\n\n{Quantity} - number of transactions in the specified block\n\n Example\n\n# Request\ncurl -X POST --data '{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"method\": \"eth_getBlockTransactionCountByNumber\",\n \"params\": [\"0xe8\"]\n}' <url>\n\n# Response\n{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"result\": \"0xa\"\n}\n\n eth_getCode\n\n Description\n\nReturns the contract code stored at a given address\n\n Parameters\n\n #\n Type\n Description\n\n 1\n {Data}\n address to query for code\n\n 2\n {Quantity|string|Block Identifier}\n block number, or one of \"latest\", \"earliest\" or \"pending\", or a block identifier as described in Block Identifier\n\n Returns\n\n{Data} - code from the specified address\n\n Example\n\n# Request\ncurl -X POST --data '{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"method\": \"eth_getCode\",\n \"params\": [\"0xa94f5374fce5edbc8e2a8697c15331677e6ebf0b\", \"0x2\"]\n}' <url>\n\n# Response\n{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"result\": \"0x600160008035811a818181146012578301005b601b6001356025565b8060005260206000f25b600060078202905091905056\"\n}\n\n eth_getFilterChanges\n\n Description\n\nReturns a list of all logs based on filter ID since the last log retrieval\n\n Parameters\n\n #\n Type\n Description\n\n 1\n {Quantity}\n ID of the filter\n\n Returns\n\n{Array<Log>} - array of log objects with the following members:\n\n {Data} address - address from which this log originated\n {Data} blockHash - hash of block containing this log or null if pending\n {Data} data - contains the non-indexed arguments of the log\n {Data} transactionHash - hash of the transaction that created this log or null if pending\n {Quantity} blockNumber - number of block containing this log or null if pending\n {Quantity} logIndex - index of this log within its block or null if pending\n {Quantity} transactionIndex - index of the transaction that created this log or null if pending\n {Data[]} topics - list of order-dependent topics\n {boolean} removed - true if this filter has been destroyed and is invalid\n\nNote: The return value of eth_getFilterChanges when retrieving logs from eth_newBlockFilter and eth_newPendingTransactionFilter filters will be an array of hashes, not an array of Log objects.\n\n Example\n\n# Request\ncurl -X POST --data '{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"method\": \"eth_getFilterChanges\",\n \"params\": [\"0x16\"]\n}' <url>\n\n# Response\n{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"result\": [{\n \"address\": \"0x16c5785ac562ff41e2dcfdf829c5a142f1fccd7d\",\n \"blockHash\": \"0x8216c5785ac562ff41e2dcfdf5785ac562ff41e2dcfdf829c5a142f1fccd7d\",\n \"blockNumber\":\"0x1b4\",\n \"data\":\"0x0000000000000000000000000000000000000000000000000000000000000000\",\n \"logIndex\": \"0x1\",\n \"topics\": [],\n \"transactionHash\": \"0xdf829c5a142f1fccd7d8216c5785ac562ff41e2dcfdf5785ac562ff41e2dcf\",\n \"transactionIndex\": \"0x0\"\n }]\n}\n\n eth_getFilterLogs\n\n Description\n\nReturns a list of all logs based on filter ID\n\n Parameters\n\n #\n Type\n Description\n\n 1\n {Quantity}\n ID of the filter\n\n Returns\n\n{Array<Log>} - array of log objects with the following members:\n\n {Data} address - address from which this log originated\n {Data} blockHash - hash of block containing this log or null if pending\n {Data} data - contains the non-indexed arguments of the log\n {Data} transactionHash - hash of the transaction that created this log or null if pending\n {Quantity} blockNumber - number of block containing this log or null if pending\n {Quantity} logIndex - index of this log within its block or null if pending\n {Quantity} transactionIndex - index of the transaction that created this log or null if pending\n {Array<Data>} topics - list of order-dependent topics\n {boolean} removed - true if this filter has been destroyed and is invalid\n\nNote: The return value of eth_getFilterLogs when retrieving logs from eth_newBlockFilter and eth_newPendingTransactionFilter filters will be an array of hashes, not an array of Log objects.\n\n Example\n\n# Request\ncurl -X POST --data '{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"method\": \"eth_getFilterLogs\",\n \"params\": [\"0x16\"]\n}' <url>\n\n# Response\n{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"result\": [{\n \"address\": \"0x16c5785ac562ff41e2dcfdf829c5a142f1fccd7d\",\n \"blockHash\": \"0x8216c5785ac562ff41e2dcfdf5785ac562ff41e2dcfdf829c5a142f1fccd7d\",\n \"blockNumber\":\"0x1b4\",\n \"data\":\"0x0000000000000000000000000000000000000000000000000000000000000000\",\n \"logIndex\": \"0x1\",\n \"topics\": [],\n \"transactionHash\": \"0xdf829c5a142f1fccd7d8216c5785ac562ff41e2dcfdf5785ac562ff41e2dcf\",\n \"transactionIndex\": \"0x0\"\n }]\n}\n\n eth_getLogs\n\n Description\n\nReturns a list of all logs based on a filter object\n\n Parameters\n\n #\n Type\n Description\n\n 1\n {object}\n @property {Quantity|string} [fromBlock] - block number, or one of \"latest\", \"earliest\" or \"pending\"@property {Quantity|string} [toBlock] - block number, or one of \"latest\", \"earliest\" or \"pending\"@property {Data|Data[]} [address] - contract address or a list of addresses from which logs should originate@property {Data[]} [topics] - list of order-dependent topics@property {Data} [blockhash] - restrict logs to a block by hash\n\nNote: If blockhash is passed, neither fromBlock nor toBlock are allowed or respected.\n\n Returns\n\n{Array<Log>} - array of log objects with the following members:\n\n {Data} address - address from which this log originated\n {Data} blockHash - hash of block containing this log or null if pending\n {Data} data - contains the non-indexed arguments of the log\n {Data} transactionHash - hash of the transaction that created this log or null if pending\n {Quantity} blockNumber - number of block containing this log or null if pending\n {Quantity} logIndex - index of this log within its block or null if pending\n {Quantity} transactionIndex - index of the transaction that created this log or null if pending\n {Data} topics - list of order-dependent topics\n {boolean} removed - true if this filter has been destroyed and is invalid\n\n Example\n\n# Request\ncurl -X POST --data '{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"method\": \"eth_getLogs\",\n \"params\": [{\n \"topics\":[\"0x000000000000000000000000a94f5374fce5edbc8e2a8697c15331677e6ebf0b\"]\n }]\n}' <url>\n\n# Response\n{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"result\": [{\n \"address\": \"0x16c5785ac562ff41e2dcfdf829c5a142f1fccd7d\",\n \"blockHash\": \"0x8216c5785ac562ff41e2dcfdf5785ac562ff41e2dcfdf829c5a142f1fccd7d\",\n \"blockNumber\":\"0x1b4\",\n \"data\":\"0x0000000000000000000000000000000000000000000000000000000000000000\",\n \"logIndex\": \"0x1\",\n \"topics\": [],\n \"transactionHash\": \"0xdf829c5a142f1fccd7d8216c5785ac562ff41e2dcfdf5785ac562ff41e2dcf\",\n \"transactionIndex\": \"0x0\"\n }]\n}\n\n eth_getStorageAt\n\n Description\n\nReturns the value from a storage position at an address\n\n Parameters\n\n #\n Type\n Description\n\n 1\n {Data}\n address of stored data\n\n 2\n {Quantity}\n index into stored data\n\n 3\n {Quantity|string|Block Identifier}\n block number, or one of \"latest\", \"earliest\" or \"pending\", or a block identifier as described in Block Identifier\n\n Returns\n\n{Data} - value stored at the given address and data index\n\n Example\n\n# Request\ncurl -X POST --data '{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"method\": \"eth_getStorageAt\",\n \"params\": [\"0x295a70b2de5e3953354a6a8344e616ed314d7251\", \"0x0\", \"latest\"]\n}' <url>\n\n# Response\n{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"result\": \"0x00000000000000000000000000000000000000000000000000000000000004d2\"\n}\n\n eth_getTransactionByBlockHashAndIndex\n\n Description\n\nReturns information about a transaction specified by block hash and transaction index\n\n Parameters\n\n #\n Type\n Description\n\n 1\n {Data}\n hash of a block\n\n 2\n {Quantity}\n index of a transaction in the specified block\n\n Returns\n\n{null|object} - null if no transaction is found, otherwise a transaction object with the following members:\n\n {Data} r - ECDSA signature r\n {Data} s - ECDSA signature s\n {Data} blockHash - hash of block containing this transaction or null if pending\n {Data} from - transaction sender\n {Data} hash - hash of this transaction\n {Data} input - contract code or a hashed method call\n {Data} to - transaction recipient or null if deploying a contract\n {Quantity} v - ECDSA recovery ID\n {Quantity} blockNumber - number of block containing this transaction or null if pending\n {Quantity} gas - gas provided for transaction execution\n {Quantity} gasPrice - price in wei of each gas used\n {Quantity} nonce - unique number identifying this transaction\n {Quantity} transactionIndex - index of this transaction in the block or null if pending\n {Quantity} value - value in wei sent with this transaction\n\n Example\n\n# Request\ncurl -X POST --data '{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"method\": \"eth_getTransactionByBlockHashAndIndex\",\n \"params\":[\"0xe670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331\", \"0x0\"]\n}' <url>\n\n# Response\n{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"result\": {\n \"blockHash\": \"0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2\",\n \"blockNumber\": \"0x5daf3b\",\n \"from\": \"0xa7d9ddbe1f17865597fbd27ec712455208b6b76d\",\n \"gas\": \"0xc350\",\n \"gasPrice\": \"0x4a817c800\",\n \"hash\": \"0x88df016429689c079f3b2f6ad39fa052532c56795b733da78a91ebe6a713944b\",\n \"input\": \"0x68656c6c6f21\",\n \"nonce\": \"0x15\",\n \"r\": \"0x1b5e176d927f8e9ab405058b2d2457392da3e20f328b16ddabcebc33eaac5fea\",\n \"s\": \"0x4ba69724e8f69de52f0125ad8b3c5c2cef33019bac3249e2c0a2192766d1721c\",\n \"to\": \"0xf02c1c8e6114b1dbe8937a39260b5b0a374432bb\",\n \"transactionIndex\": \"0x41\",\n \"v\": \"0x25\",\n \"value\": \"0xf3dbb76162000\"\n }\n}\n\n eth_getTransactionByBlockNumberAndIndex\n\n Description\n\nReturns information about a transaction specified by block number and transaction index\n\n Parameters\n\n #\n Type\n Description\n\n 1\n {Quantity|string}\n block number, or one of \"latest\", \"earliest\" or \"pending\"\n\n 2\n {Quantity}\n index of a transaction in the specified block\n\n Returns\n\n{null|object} - null if no transaction is found, otherwise a transaction object with the following members:\n\n {Data} r - ECDSA signature r\n {Data} s - ECDSA signature s\n {Data} blockHash - hash of block containing this transaction or null if pending\n {Data} from - transaction sender\n {Data} hash - hash of this transaction\n {Data} input - contract code or a hashed method call\n {Data} to - transaction recipient or null if deploying a contract\n {Quantity} v - ECDSA recovery ID\n {Quantity} blockNumber - number of block containing this transaction or null if pending\n {Quantity} gas - gas provided for transaction execution\n {Quantity} gasPrice - price in wei of each gas used\n {Quantity} nonce - unique number identifying this transaction\n {Quantity} transactionIndex - index of this transaction in the block or null if pending\n {Quantity} value - value in wei sent with this transaction\n\n Example\n\n# Request\ncurl -X POST --data '{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"method\": \"eth_getTransactionByBlockNumberAndIndex\",\n \"params\":[\"0x29c\", \"0x0\"]\n}' <url>\n\n# Response\n{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"result\": {\n \"blockHash\": \"0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2\",\n \"blockNumber\": \"0x5daf3b\",\n \"from\": \"0xa7d9ddbe1f17865597fbd27ec712455208b6b76d\",\n \"gas\": \"0xc350\",\n \"gasPrice\": \"0x4a817c800\",\n \"hash\": \"0x88df016429689c079f3b2f6ad39fa052532c56795b733da78a91ebe6a713944b\",\n \"input\": \"0x68656c6c6f21\",\n \"nonce\": \"0x15\",\n \"r\": \"0x1b5e176d927f8e9ab405058b2d2457392da3e20f328b16ddabcebc33eaac5fea\",\n \"s\": \"0x4ba69724e8f69de52f0125ad8b3c5c2cef33019bac3249e2c0a2192766d1721c\",\n \"to\": \"0xf02c1c8e6114b1dbe8937a39260b5b0a374432bb\",\n \"transactionIndex\": \"0x41\",\n \"v\": \"0x25\",\n \"value\": \"0xf3dbb76162000\"\n }\n}\n\n eth_getTransactionByHash\n\n Description\n\nReturns information about a transaction specified by hash\n\n Parameters\n\n #\n Type\n Description\n\n 1\n {Data}\n hash of a transaction\n\n Returns\n\n{null|object} - null if no transaction is found, otherwise a transaction object with the following members:\n\n {Data} r - ECDSA signature r\n {Data} s - ECDSA signature s\n {Data} blockHash - hash of block containing this transaction or null if pending\n {Data} from - transaction sender\n {Data} hash - hash of this transaction\n {Data} input - contract code or a hashed method call\n {Data} to - transaction recipient or null if deploying a contract\n {Quantity} v - ECDSA recovery ID\n {Quantity} blockNumber - number of block containing this transaction or null if pending\n {Quantity} gas - gas provided for transaction execution\n {Quantity} gasPrice - price in wei of each gas used\n {Quantity} nonce - unique number identifying this transaction\n {Quantity} transactionIndex - index of this transaction in the block or null if pending\n {Quantity} value - value in wei sent with this transaction\n\n Example\n\n# Request\ncurl -X POST --data '{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"method\": \"eth_getTransactionByHash\",\n \"params\": [\"0x88df016429689c079f3b2f6ad39fa052532c56795b733da78a91ebe6a713944b\"]\n}' <url>\n\n# Response\n{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"result\": {\n \"blockHash\": \"0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2\",\n \"blockNumber\": \"0x5daf3b\",\n \"from\": \"0xa7d9ddbe1f17865597fbd27ec712455208b6b76d\",\n \"gas\": \"0xc350\",\n \"gasPrice\": \"0x4a817c800\",\n \"hash\": \"0x88df016429689c079f3b2f6ad39fa052532c56795b733da78a91ebe6a713944b\",\n \"input\": \"0x68656c6c6f21\",\n \"nonce\": \"0x15\",\n \"r\": \"0x1b5e176d927f8e9ab405058b2d2457392da3e20f328b16ddabcebc33eaac5fea\",\n \"s\": \"0x4ba69724e8f69de52f0125ad8b3c5c2cef33019bac3249e2c0a2192766d1721c\",\n \"to\": \"0xf02c1c8e6114b1dbe8937a39260b5b0a374432bb\",\n \"transactionIndex\": \"0x41\",\n \"v\": \"0x25\",\n \"value\": \"0xf3dbb76162000\"\n }\n}\n\n eth_getTransactionCount\n\n Description\n\nReturns the number of transactions sent from an address\n\n Parameters\n\n #\n Type\n Description\n\n 1\n {Data}\n address to query for sent transactions\n\n 2\n {Quantity|string|Block Identifier}\n block number, or one of \"latest\", \"earliest\" or \"pending\", or a block identifier as described in Block Identifier\n\n Returns\n\n{Quantity} - number of transactions sent from the specified address\n\n Example\n\n# Request\ncurl -X POST --data '{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"method\": \"eth_getTransactionCount\",\n \"params\": [\"0xc94770007dda54cF92009BFF0dE90c06F603a09f\", \"latest\"]\n}' <url>\n\n# Response\n{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"result\": \"0x1\"\n}\n\n eth_getTransactionReceipt\n\n Description\n\nReturns the receipt of a transaction specified by hash\n\nNote: Transaction receipts are unavailable for pending transactions.\n\n Parameters\n\n #\n Type\n Description\n\n 1\n {Data}\n hash of a transaction\n\n Returns\n\n{null|object} - null if no transaction is found, otherwise a transaction receipt object with the following members:\n\n {Data} blockHash - hash of block containing this transaction\n {Data} contractAddress - address of new contract or null if no contract was created\n {Data} from - transaction sender\n {Data} logsBloom - logs bloom filter\n {Data} to - transaction recipient or null if deploying a contract\n {Data} transactionHash - hash of this transaction\n {Quantity} blockNumber - number of block containing this transaction\n {Quantity} cumulativeGasUsed - gas used by this and all preceding transactions in this block\n {Quantity} gasUsed - gas used by this transaction\n {Quantity} status - 1 if this transaction was successful or 0 if it failed\n {Quantity} transactionIndex - index of this transaction in the block\n {Array<Log>} logs - list of log objects generated by this transaction\n\n Example\n\n# Request\ncurl -X POST --data '{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"method\": \"eth_getTransactionReceipt\",\n \"params\": [\"0xb903239f8543d04b5dc1ba6579132b143087c68db1b2168786408fcbce568238\"]\n}' <url>\n\n# Response\n{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"result\": {\n \"blockHash\": '0xc6ef2fc5426d6ad6fd9e2a26abeab0aa2411b7ab17f30a99d3cb96aed1d1055b',\n \"blockNumber\": '0xb',\n \"contractAddress\": '0xb60e8dd61c5d32be8058bb8eb970870f07233155',\n \"cumulativeGasUsed\": '0x33bc',\n \"gasUsed\": '0x4dc',\n \"logs\": [],\n \"logsBloom\": \"0x00...0\",\n \"status\": \"0x1\",\n \"transactionHash\": '0xb903239f8543d04b5dc1ba6579132b143087c68db1b2168786408fcbce568238',\n \"transactionIndex\": '0x1'\n }\n}\n\n eth_getUncleByBlockHashAndIndex\n\n Description\n\nReturns information about an uncle specified by block hash and uncle index position\n\n Parameters\n\n #\n Type\n Description\n\n 1\n {Data}\n hash of a block\n\n 2\n {Quantity}\n index of uncle\n\n Returns\n\n{null|object} - null if no block or uncle is found, otherwise an uncle object with the following members:\n\n {Data} extraData - “extra data” field of this block\n {Data} hash - block hash or null if pending\n {Data} logsBloom - logs bloom filter or null if pending\n {Data} miner - address that received this block’s mining rewards\n {Data} nonce - proof-of-work hash or null if pending\n {Data} parentHash - parent block hash\n {Data} receiptsRoot -root of this block’s receipts trie\n {Data} sha3Uncles - SHA3 of the uncles data in this block\n {Data} stateRoot - root of this block’s final state trie\n {Data} transactionsRoot - root of this block’s transaction trie\n {Quantity} difficulty - difficulty for this block\n {Quantity} gasLimit - maximum gas allowed in this block\n {Quantity} gasUsed - total used gas by all transactions in this block\n {Quantity} number - block number or null if pending\n {Quantity} size - size of this block in bytes\n {Quantity} timestamp - unix timestamp of when this block was collated\n {Quantity} totalDifficulty - total difficulty of the chain until this block\n {Array<Transaction>} uncles - list of uncle hashes\n\n Example\n\n# Request\ncurl -X POST --data '{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"method\": \"eth_getUncleByBlockHashAndIndex\",\n \"params\": [\"0xc6ef2fc5426d6ad6fd9e2a26abeab0aa2411b7ab17f30a99d3cb96aed1d1055b\", \"0x0\"]\n}' <url>\n\n# Response\n{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"result\": {\n \"difficulty\": \"0x027f07\",\n \"extraData\": \"0x0000000000000000000000000000000000000000000000000000000000000000\",\n \"gasLimit\": \"0x9f759\",\n \"gasUsed\": \"0x9f759\",\n \"hash\": \"0xe670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331\",\n \"logsBloom\": \"0xe670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331\",\n \"miner\": \"0x4e65fda2159562a496f9f3522f89122a3088497a\",\n \"nonce\": \"0xe04d296d2460cfb8472af2c5fd05b5a214109c25688d3704aed5484f9a7792f2\",\n \"number\": \"0x1b4\",\n \"parentHash\": \"0x9646252be9520f6e71339a8df9c55e4d7619deeb018d2a3f2d21fc165dde5eb5\",\n \"sha3Uncles\": \"0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347\",\n \"size\": \"0x027f07\",\n \"stateRoot\": \"0xd5855eb08b3387c0af375e9cdb6acfc05eb8f519e419b874b6ff2ffda7ed1dff\",\n \"timestamp\": \"0x54e34e8e\"\n \"totalDifficulty\": \"0x027f07\",\n \"transactionsRoot\": \"0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421\",\n \"uncles\": []\n }\n}\n\n eth_getUncleByBlockNumberAndIndex\n\n Description\n\nReturns information about an uncle specified by block number and uncle index position\n\n Parameters\n\n #\n Type\n Description\n\n 1\n {Quantity|string}\n block number, or one of \"latest\", \"earliest\" or \"pending\"\n\n 2\n {Quantity}\n index of uncle\n\n Returns\n\n{null|object} - null if no block or uncle is found, otherwise an uncle object with the following members:\n\n {Data} extraData - “extra data” field of this block\n {Data} hash - block hash or null if pending\n {Data} logsBloom - logs bloom filter or null if pending\n {Data} miner - address that received this block’s mining rewards\n {Data} nonce - proof-of-work hash or null if pending\n {Data} parentHash - parent block hash\n {Data} receiptsRoot -root of this block’s receipts trie\n {Data} sha3Uncles - SHA3 of the uncles data in this block\n {Data} stateRoot - root of this block’s final state trie\n {Data} transactionsRoot - root of this block’s transaction trie\n {Quantity} difficulty - difficulty for this block\n {Quantity} gasLimit - maximum gas allowed in this block\n {Quantity} gasUsed - total used gas by all transactions in this block\n {Quantity} number - block number or null if pending\n {Quantity} size - size of this block in bytes\n {Quantity} timestamp - unix timestamp of when this block was collated\n {Quantity} totalDifficulty - total difficulty of the chain until this block\n {Array<Transaction>} uncles - list of uncle hashes\n\n Example\n\n# Request\ncurl -X POST --data '{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"method\": \"eth_getUncleByBlockNumberAndIndex\",\n \"params\": [\"0x29c\", \"0x0\"]\n}' <url>\n\n# Response\n{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"result\": {\n \"difficulty\": \"0x027f07\",\n \"extraData\": \"0x0000000000000000000000000000000000000000000000000000000000000000\",\n \"gasLimit\": \"0x9f759\",\n \"gasUsed\": \"0x9f759\",\n \"hash\": \"0xe670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331\",\n \"logsBloom\": \"0xe670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331\",\n \"miner\": \"0x4e65fda2159562a496f9f3522f89122a3088497a\",\n \"nonce\": \"0xe04d296d2460cfb8472af2c5fd05b5a214109c25688d3704aed5484f9a7792f2\",\n \"number\": \"0x1b4\",\n \"parentHash\": \"0x9646252be9520f6e71339a8df9c55e4d7619deeb018d2a3f2d21fc165dde5eb5\",\n \"sha3Uncles\": \"0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347\",\n \"size\": \"0x027f07\",\n \"stateRoot\": \"0xd5855eb08b3387c0af375e9cdb6acfc05eb8f519e419b874b6ff2ffda7ed1dff\",\n \"timestamp\": \"0x54e34e8e\"\n \"totalDifficulty\": \"0x027f07\",\n \"transactionsRoot\": \"0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421\",\n \"uncles\": []\n }\n}\n\n eth_getUncleCountByBlockHash\n\n Description\n\nReturns the number of uncles in a block specified by block hash\n\n Parameters\n\n #\n Type\n Description\n\n 1\n {Data}\n hash of a block\n\n Returns\n\n{Quantity} - number of uncles in the specified block\n\n Example\n\n# Request\ncurl -X POST --data '{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"method\": \"eth_getUncleCountByBlockHash\",\n \"params\": [\"0xc94770007dda54cF92009BFF0dE90c06F603a09f\"]\n}' <url>\n\n# Response\n{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"result\": \"0xc\"\n}\n\n eth_getUncleCountByBlockNumber\n\n Description\n\nReturns the number of uncles in a block specified by block number\n\n Parameters\n\n #\n Type\n Description\n\n 1\n {Quantity|string}\n block number, or one of \"latest\", \"earliest\" or \"pending\"\n\n Returns\n\n{Quantity} - number of uncles in the specified block\n\n Example\n\n# Request\ncurl -X POST --data '{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"method\": \"eth_getUncleCountByBlockNumber\",\n \"params\": [\"0xe8\"]\n}' <url>\n\n# Response\n{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"result\": \"0x1\"\n}\n\n eth_getWork\n\n Description\n\nReturns a list containing relevant information for proof-of-work\n\n Parameters\n\nnone\n\n Returns\n\n{Data[]} - array with the following items:\n\n {Data} - current block header pow-hash\n {Data} - seed hash used for the DAG\n {Data} - boundary condition (“target”), 2^256 / difficulty\n\n Example\n\n# Request\ncurl -X POST --data '{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"method\": \"eth_getWork\",\n \"params\": []\n}' <url>\n\n# Response\n{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"result\": [\n \"0x1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef\",\n \"0x5EED00000000000000000000000000005EED0000000000000000000000000000\",\n \"0xd1ff1c01710000000000000000000000d1ff1c01710000000000000000000000\"\n ]\n}\n\n eth_hashrate\n\n Description\n\nReturns the number of hashes-per-second this node is mining at\n\n Parameters\n\n(none)\n\n Returns\n\n{Quantity} - number of hashes-per-second\n\n Example\n\n# Request\ncurl -X POST --data '{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"method\": \"eth_hashrate\",\n \"params\": []\n}' <url>\n\n# Response\n{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"result\": \"0x38a\"\n}\n\n eth_mining\n\n Description\n\nDetermines if this client is mining new blocks\n\n Parameters\n\n(none)\n\n Returns\n\n{boolean} - true if this client is mining or false if it is not mining\n\n Example\n\n# Request\ncurl -X POST --data '{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"method\": \"eth_mining\",\n \"params\": []\n}' <url>\n\n# Response\n{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"result\": true\n}\n\n eth_newBlockFilter\n\n Description\n\nCreates a filter to listen for new blocks that can be used with eth_getFilterChanges\n\n Parameters\n\nnone\n\n Returns\n\n{Quantity} - ID of the newly-created filter that can be used with eth_getFilterChanges\n\n Example\n\n# Request\ncurl -X POST --data '{\n \"id\": 1337\n \"jsonrpc\": \"2.0\",\n \"method\": \"eth_newBlockFilter\",\n \"params\": []\n}' <url>\n\n# Response\n{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"result\": \"0x1\"\n}\n\n eth_newFilter\n\n Description\n\nCreates a filter to listen for specific state changes that can then be used with eth_getFilterChanges\n\n Parameters\n\n #\n Type\n Description\n\n 1\n {object}\n @property {Quantity|string} [fromBlock] - block number, or one of \"latest\", \"earliest\" or \"pending\"@property {Quantity|string} [toBlock] - block number, or one of \"latest\", \"earliest\" or \"pending\"@property {Data|Data[]} [address] - contract address or a list of addresses from which logs should originate@property {Data[]} [topics] - list of order-dependent topics\n\nNote: Topics 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)”\n\n Returns\n\n{Quantity} - ID of the newly-created filter that can be used with eth_getFilterChanges\n\n Example\n\n# Request\ncurl -X POST --data '{\n \"id\": 1337\n \"jsonrpc\": \"2.0\",\n \"method\": \"eth_newFilter\",\n \"params\": [{\n \"topics\": [\"0x0000000000000000000000000000000000000000000000000000000012341234\"]\n }]\n}' <url>\n\n# Response\n{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"result\": \"0x1\"\n}\n\n eth_newPendingTransactionFilter\n\n Description\n\nCreates a filter to listen for new pending transactions that can be used with eth_getFilterChanges\n\n Parameters\n\nnone\n\n Returns\n\n{Quantity} - ID of the newly-created filter that can be used with eth_getFilterChanges\n\n Example\n\n# Request\ncurl -X POST --data '{\n \"id\": 1337\n \"jsonrpc\": \"2.0\",\n \"method\": \"eth_newPendingTransactionFilter\",\n \"params\": []\n}' <url>\n\n# Response\n{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"result\": \"0x1\"\n}\n\n eth_protocolVersion\n\n Description\n\nReturns the current Ethereum protocol version\n\n Parameters\n\n(none)\n\n Returns\n\n{string} - current Ethereum protocol version\n\n Example\n\n# Request\ncurl -X POST --data '{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"method\": \"eth_protocolVersion\",\n \"params\": []\n}' <url>\n\n# Response\n{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"result\": \"54\"\n}\n\n eth_sendRawTransaction\n\n Description\n\nSends and already-signed transaction to the network\n\n Parameters\n\n #\n Type\n Description\n\n 1\n {Data}\n signed transaction data\n\n Returns\n\n{Data} - transaction hash, or the zero hash if the transaction is not yet available\n\n Example\n\n# Request\ncurl -X POST --data '{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"method\": \"eth_sendRawTransaction\",\n \"params\": [\"0xd46e8dd67c5d32be8d46e8dd67c5d32be8058bb8eb970870f072445675058bb8eb970870f072445675\"]\n}' <url>\n\n# Response\n{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"result\": \"0xe670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331\"\n}\n\n eth_sendTransaction\n\n Description\n\nCreates, signs, and sends a new transaction to the network\n\n Parameters\n\n #\n Type\n Description\n\n 1\n {object}\n @property {Data} from - transaction sender@property {Data} [to] - transaction recipient@property {Quantity} [gas=\"0x15f90\"] - gas provided for transaction execution@property {Quantity} [gasPrice] - price in wei of each gas used@property {Quantity} [value] - value in wei sent with this transaction@property {Data} [data] - contract code or a hashed method call with encoded args@property {Quantity} [nonce] - unique number identifying this transaction\n\n Returns\n\n{Data} - transaction hash, or the zero hash if the transaction is not yet available\n\n Example\n\n# Request\ncurl -X POST --data '{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"method\": \"eth_sendTransaction\",\n \"params\": [{\n \"data\": \"0xd46e8dd67c5d32be8d46e8dd67c5d32be8058bb8eb970870f072445675058bb8eb970870f072445675\",\n \"from\": \"0xb60e8dd61c5d32be8058bb8eb970870f07233155\",\n \"gas\": \"0x76c0\",\n \"gasPrice\": \"0x9184e72a000\",\n \"to\": \"0xd46e8dd67c5d32be8058bb8eb970870f07244567\",\n \"value\": \"0x9184e72a\"\n }]\n}' <url>\n\n# Response\n{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"result\": \"0xe670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331\"\n}\n\n eth_sign\n\n Description\n\nCalculates an Ethereum-specific signature in the form of keccak256(\"\\x19Ethereum Signed Message:\\n\" + len(message) + message))\n\n Parameters\n\n #\n Type\n Description\n\n 1\n {Data}\n address to use for signing\n\n 2\n {Data}\n data to sign\n\n Returns\n\n{Data} - signature hash of the provided data\n\n Example\n\n# Request\ncurl -X POST --data '{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"method\": \"eth_sign\",\n \"params\": [\"0x9b2055d370f73ec7d8a03e965129118dc8f5bf83\", \"0xdeadbeaf\"]\n}' <url>\n\n# Response\n{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"result\": \"0xa3f20717a250c2b0b729b7e5becbff67fdaef7e0699da4de7ca5895b02a170a12d887fd3b17bfdce3481f10bea41f45ba9f709d39ce8325427b57afcfc994cee1b\"\n}\n\n eth_signTransaction\n\n Description\n\nSigns a transaction that can be submitted to the network at a later time using with eth_sendRawTransaction\n\n Parameters\n\n #\n Type\n Description\n\n 1\n {object}\n @property {Data} from - transaction sender@property {Data} [to] - transaction recipient@property {Quantity} [gas=\"0x15f90\"] - gas provided for transaction execution@property {Quantity} [gasPrice] - price in wei of each gas used@property {Quantity} [value] - value in wei sent with this transaction@property {Data} [data] - contract code or a hashed method call with encoded args@property {Quantity} [nonce] - unique number identifying this transaction\n\n Returns\n\n{Data} - signature hash of the transaction object\n\n Example\n\n# Request\ncurl -X POST --data '{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"method\": \"eth_signTransaction\",\n \"params\": [{\n \"data\": \"0xd46e8dd67c5d32be8d46e8dd67c5d32be8058bb8eb970870f072445675058bb8eb970870f072445675\",\n \"from\": \"0xb60e8dd61c5d32be8058bb8eb970870f07233155\",\n \"gas\": \"0x76c0\",\n \"gasPrice\": \"0x9184e72a000\",\n \"to\": \"0xd46e8dd67c5d32be8058bb8eb970870f07244567\",\n \"value\": \"0x9184e72a\"\n }]\n}' <url>\n\n# Response\n{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"result\": \"0xa3f20717a250c2b0b729b7e5becbff67fdaef7e0699da4de7ca5895b02a170a12d887fd3b17bfdce3481f10bea41f45ba9f709d39ce8325427b57afcfc994cee1b\"\n}\n\n eth_signTypedData\n\n Description\n\nCalculates an Ethereum-specific signature in the form of keccak256(\"\\x19Ethereum Signed Message:\\n\" + len(message) + message))\n\n Parameters\n\n #\n Type\n Description\n\n 1\n {Data}\n address to use for signing\n\n 2\n {Data}\n message to sign containing type information, a domain separator, and data\n\nNote: Client developers should refer to EIP-712 for complete semantics around encoding and signing data. Dapp developers should refer to EIP-712 for the expected structure of RPC method input parameters.\n\n Returns\n\n{Data} - signature hash of the provided message\n\n Example\n\n# Request\ncurl -X POST --data '{\n \"id\": 1337\n \"jsonrpc\": \"2.0\",\n \"method\": \"eth_signTypedData\",\n \"params\": [\"0xCD2a3d9F938E13CD947Ec05AbC7FE734Df8DD826\", {\n \"types\": {\n \"EIP712Domain\": [{\n \"name\": \"name\",\n \"type\": \"string\"\n }, {\n \"name\": \"version\",\n \"type\": \"string\"\n }, {\n \"name\": \"chainId\",\n \"type\": \"uint256\"\n }, {\n \"name\": \"verifyingContract\",\n \"type\": \"address\"\n }],\n \"Person\": [{\n \"name\": \"name\",\n \"type\": \"string\"\n }, {\n \"name\": \"wallet\",\n \"type\": \"address\"\n }],\n \"Mail\": [{\n \"name\": \"from\",\n \"type\": \"Person\"\n }, {\n \"name\": \"to\",\n \"type\": \"Person\"\n }, {\n \"name\": \"contents\",\n \"type\": \"string\"\n }]\n },\n \"primaryType\": \"Mail\",\n \"domain\": {\n \"name\": \"Ether Mail\",\n \"version\": \"1\",\n \"chainId\": 1,\n \"verifyingContract\": \"0xCcCCccccCCCCcCCCCCCcCcCccCcCCCcCcccccccC\"\n },\n \"message\": {\n \"from\": {\n \"name\": \"Cow\",\n \"wallet\": \"0xCD2a3d9F938E13CD947Ec05AbC7FE734Df8DD826\"\n },\n \"to\": {\n \"name\": \"Bob\",\n \"wallet\": \"0xbBbBBBBbbBBBbbbBbbBbbbbBBbBbbbbBbBbbBBbB\"\n },\n \"contents\": \"Hello, Bob!\"\n }\n }]\n}' <url>\n\n# Response\n{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"result\": \"0x4355c47d63924e8a72e509b65029052eb6c299d53a04e167c5775fd466751c9d07299936d304c153f6443dfa05f40ff007d72911b6f72307f996231605b915621c\"\n}\n\n eth_submitHashrate\n\n Description\n\nSubmit a mining hashrate\n\n Parameters\n\n #\n Type\n Description\n\n 1\n {Data}\n hash rate\n\n 2\n {Data}\n random ID identifying this node\n\n Returns\n\n{boolean} - true if submitting went through successfully, false otherwise\n\n Example\n\n# Request\ncurl -X POST --data '{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"method\": \"eth_submitHashrate\",\n \"params\": [\n \"0x0000000000000000000000000000000000000000000000000000000000500000\",\n \"0x59daa26581d0acd1fce254fb7e85952f4c09d0915afd33d3886cd914bc7d283c\"\n ]\n}' <url>\n\n# Response\n{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"result\": true\n}\n\n eth_submitWork\n\n Description\n\nSubmit a proof-of-work solution\n\n Parameters\n\n #\n Type\n Description\n\n 1\n {Data}\n nonce found\n\n 2\n {Data}\n header’s pow-hash\n\n 3\n {Data}\n mix digest\n\n Returns\n\n{boolean} - true if the provided solution is valid, false otherwise\n\n Example\n\n# Request\ncurl -X POST --data '{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"method\": \"eth_submitWork\",\n \"params\": [\n \"0x0000000000000001\",\n \"0x1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef\",\n \"0xD1GE5700000000000000000000000000D1GE5700000000000000000000000000\"\n ]\n}' <url>\n\n# Response\n{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"result\": true\n}\n\n eth_syncing\n\n Description\n\nReturns information about the status of this client’s network synchronization\n\n Parameters\n\n(none)\n\n Returns\n\n{boolean|object} - false if this client is not syncing with the network, otherwise an object with the following members:\n\n {Quantity} currentBlock - number of the most-recent block synced\n {Quantity} highestBlock - number of latest block on the network\n {Quantity} startingBlock - block number at which syncing started\n\n Example\n\n# Request\ncurl -X POST --data '{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"method\": \"eth_syncing\",\n \"params\": []\n}' <url>\n\n# Response\n{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"result\": {\n \"currentBlock\": '0x386',\n \"highestBlock\": '0x454',\n \"startingBlock\": '0x384'\n }\n}\n\n eth_uninstallFilter\n\n Description\n\nDestroys a filter based on filter ID\n\nNote: This should only be called if a filter and its notifications are no longer needed. This will also be called automatically on a filter if its notifications are not retrieved using eth_getFilterChanges for a period of time.\n\n Parameters\n\n #\n Type\n Description\n\n 1\n {Quantity}\n ID of the filter to destroy\n\n Returns\n\n{boolean} - true if the filter is found and successfully destroyed or false if it is not\n\n Example\n\n# Request\ncurl -X POST --data '{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"method\": \"eth_uninstallFilter\",\n \"params\": [\"0xb\"]\n}' <url>\n\n# Response\n{\n \"id\": 1337,\n \"jsonrpc\": \"2.0\",\n \"result\": true\n}\n\n Rationale\n\nMuch of Ethereum’s effectiveness as an enterprise-grade application platform depends on its ability to provide a reliable and predictable developer experience. Nodes created by the current generation of Ethereum clients expose RPC endpoints with differing method signatures; this forces applications to work around method inconsistencies to maintain compatibility with various Ethereum RPC implementations.\n\nBoth Ethereum client developers and downstream dapp developers lack a formal Ethereum RPC specification. This proposal standardizes such a specification in a way that’s versionable and modifiable through the traditional EIP process.\n\n Backwards compatibility\n\nThis proposal impacts Ethereum client developers by requiring that any exposed RPC interface adheres to this specification. This proposal impacts dapp developers by requiring that any RPC calls currently used in applications are made according to this specification.\n\n Implementation\n\nThe current generation of Ethereum clients includes several implementations that attempt to expose this RPC specification:\n\n Client Name\n Language\n Homepage\n\n Geth\n Go\n geth.ethereum.org\n\n Parity\n Rust\n parity.io/ethereum\n\n Aleth\n C++\n cpp-ethereum.org\n\n Copyright\n\nCopyright and related rights waived via CC0.\n\n Citation\n Please cite this document as:\n\n Paul Bouchon <mail@bitpshr.net>, Erik Marks (@rekmarks), \"EIP-1474: Remote procedure call specification [STAGNANT],\" Ethereum Improvement Proposals, no. 1474, October 2018. Available: https://eips.ethereum.org/EIPS/eip-1474.","tokens":13631,"squid":"spider-05","role":"Spec Spider","at":1791341056056,"hash":"ac05c1b5f7492885deb620db32918c85204a7070"}
{"url":"https://docs.arbitrum.foundation/network-upgrades","domain":"docs.arbitrum.foundation","title":"Network upgrades | Arbitrum DAO - Governance docs","text":"✏️Request an updatePUBLIC PREVIEW DOCUMENTThis document is currently in public preview and may change significantly as feedback is captured from readers like you. Click the Request an update button at the top of this document or join the Arbitrum Discord to share your feedback.This page has information on the state and timelines of major software updates to Arbitrum One and Arbitrum Nova. Software updates that alter an Arbitrum chain's ability to produce valid Arbitrum blocks are referred to as ArbOS upgrades and, as outlined in the ArbitrumDAO Constitution, will always require a Constiutional AIP to pass for DAO-governed chains.Visit Inside Arbitrum Nitro to learn more about Nitro's architecture; more information about ArbOS software releases is available on the ArbitrumDAO forum as well as in the documentation for the overview of ArbOS software releases.Network activation statuses​UpgradeGovernance Approval StatusLink to most recent governance stageArbitrum Sepolia (YYYY-MM-DD)Arbitrum One (YYYY-MM-DD)Arbitrum Nova (YYYY-MM-DD)ArbOS 61 ElaraApproved & executedOn-chain voteMon, 2026-06-29 at 03:00:00 PM UTCThu, 2026-08-20 at 05:08:23 PM UTCThu, 2026-08-20 at 05:11:49 PM UTCArbOS 60 ElaraApproved & executedTemperature CheckTues, 2026-05-19 at 03:57:31 PM UTCN/AN/AArbOS 51 DiaApproved & executedOn-chain voteTues, 2025-12-01 at 05:00:36 PM UTCThu, 2026-01-08 5:00:02 PM UTCThu, 2026-01-08 5:01:13 PM UTCArbOS 50 DiaApproved & executedTemperature CheckThu, 2025-11-20 at 05:04:12 PM UTCN/AN/AArbOS 40 CallistoApproved & executedOn-chain voteMon, 2025-05-06 at 02:54:45 PM UTCTues, 2025-06-17 10:56:23 PM UTCTues, 2025-06-17 10:56:23 PM UTCArbitrum BoLDApproved & executedOn-chain voteWeds, 2024-12-11 06:21:36 PM UTCWed, 2025-02-12 02:00:11 PM UTCWed, 2025-02-12 02:00:11 PM UTCArbOS 32 BiancaApproved & executed by the Arbitrum Security CouncilN/AWeds, 2024-09-25 at 02:06:01 UTCWeds, 2024-09-25 at 02:37:30 UTCWeds, 2024-09-25 at 02:26:11 UTCArbOS 31 BiancaApproved & executedOn-chain voteMon, 2024-06-17 at 17:00:00 UTCTues, 2024-09-03 at 17:00:00 UTCTues, 2024-09-03 at 17:00:00 UTCArbOS 20 AtlasApproved & executedOn-chain voteThu, 2024-02-29 at 18:00:00 UTCThu, 2024-03-14 01:48:09 PM UTCThu, 2024-03-14 01:48:09 PM UTCArbOS 11Approved & executedOn-chain voteTues, 2024-01-30 at 17:00:00 UTCThu, 2024-02-24 at 20:01:13 UTCThu, 2024-02-24 at 20:01:13 UTCSupport policy​For more information about the Support policy for Nitro, refer to the Support page on the Arbitrum docs.Stay up to date​To stay up to date with proposals, timelines, and statuses of network upgrades to Arbitrum One and Nova:Subscribe to the Arbitrum Node Upgrade Announcement channel on TelegramJoin both the #dev-announcements and #node-runners Discord channels in the Arbitrum Discord serverFollow the official Arbitrum (@Arbitrum) and Arbitrum Developers (@ArbitrumDevs) X accounts, formerly Twitter.Network activation statusesSupport policyStay up to date","tokens":738,"squid":"spider-07","role":"Council Spider","at":1791341079223,"hash":"4445217e2ce470ff61c792e52491b1a0b984174d"}
{"url":"https://eips.ethereum.org/EIPS/eip-600","domain":"eips.ethereum.org","title":"ERC-600: Ethereum purpose allocation for Deterministic Wallets","text":"🎉 Final\n\n Standards Track: ERC\n\n ERC-600: Ethereum purpose allocation for Deterministic Wallets\n\n Authors\n Nick Johnson (@arachnid), Micah Zoltu (@micahzoltu)\n\n Created\n 2017-04-13\n\n Abstract\n\nThis EIP defines a logical hierarchy for deterministic wallets based on BIP32, the purpose scheme defined in BIP43 and this proposed change to BIP43.\n\nThis EIP is a particular application of BIP43.\n\n Motivation\n\nBecause Ethereum is based on account balances rather than UTXO, the hierarchy defined by BIP44 is poorly suited. As a result, several competing derivation path strategies have sprung up for deterministic wallets, resulting in inter-client incompatibility. This BIP seeks to provide a path to standardise this in a fashion better suited to Ethereum’s unique requirements.\n\n Specification\n\nWe define the following 2 levels in BIP32 path:\n\nm / purpose' / subpurpose' / EIP'\n\nApostrophe in the path indicates that BIP32 hardened derivation is used.\n\nEach level has a special meaning, described in the chapters below.\n\n Purpose\n\nPurpose is set to 43, as documented in this proposed change to BIP43.\n\nThe purpose field indicates that this path is for a non-bitcoin cryptocurrency.\n\nHardened derivation is used at this level.\n\n Subpurpose\n\nSubpurpose is set to 60, the SLIP-44 code for Ethereum.\n\nHardened derivation is used at this level.\n\n EIP\n\nEIP is set to the EIP number specifying the remainder of the BIP32 derivation path. This permits new Ethereum-focused applications of deterministic wallets without needing to interface with the BIP process.\n\nHardened derivation is used at this level.\n\n Rationale\n\nThe existing convention is to use the ‘Ethereum’ coin type, leading to paths starting with m/44'/60'/*. Because this still assumes a UTXO-based coin, we contend that this is a poor fit, resulting in standardisation, usability, and security compromises. As a result, we are making the above proposal to define an entirely new hierarchy for Ethereum-based chains.\n\n Backwards Compatibility\n\nThe introduction of another derivation path requires existing software to add support for this scheme in addition to any existing schemes. Given the already confused nature of wallet derivation paths in Ethereum, we anticipate this will cause relatively little additional disruption, and has the potential to improve matters significantly in the long run.\n\n Test Cases\n\nTBD\n\n Implementation\n\nNone yet.\n\n References\n\nThis discussion on derivation paths\n\n Copyright\n\nCopyright and related rights waived via CC0.\n\n Citation\n Please cite this document as:\n\n Nick Johnson (@arachnid), Micah Zoltu (@micahzoltu), \"ERC-600: Ethereum purpose allocation for Deterministic Wallets,\" Ethereum Improvement Proposals, no. 600, April 2017. Available: https://eips.ethereum.org/EIPS/eip-600.","tokens":694,"squid":"spider-05","role":"Spec Spider","at":1791341079270,"hash":"167c773c3966697d549422340b4a1a106f3a0000"}
{"url":"https://eips.ethereum.org/EIPS/eip-601","domain":"eips.ethereum.org","title":"ERC-601: Ethereum hierarchy for deterministic wallets","text":"🎉 Final\n\n Standards Track: ERC\n\n ERC-601: Ethereum hierarchy for deterministic wallets\n\n Authors\n Nick Johnson (@arachnid), Micah Zoltu (@micahzoltu)\n\n Created\n 2017-04-13\n\n Abstract\n\nThis EIP defines a logical hierarchy for deterministic wallets based on BIP32, the purpose scheme defined in BIP43 and eip-draft-ethereum-purpose.\n\nThis EIP is a particular application of eip-draft-ethereum-purpose.\n\n Motivation\n\nAt present, different Ethereum clients and wallets use different derivation paths; a summary of them can be found here. Some of these paths violate BIP44, the standard defining derivation paths starting with m/44'/. This creates confusion and incompatibility between wallet implementations, in some cases making funds from one wallet inaccessible on another, and in others requiring prompting users manually for a derivation path, which hinders usability.\n\nFurther, BIP44 was designed with UTXO-based blockchains in mind, and is a poor fit for Ethereum, which uses an accounts abstraction instead.\n\nAs an alternative, we propose a deterministic wallet hierarchy better tailored to Ethereum’s unique requirements.\n\n Specification\n\nWe define the following 4 levels in BIP32 path:\n\nm / purpose' / subpurpose' / EIP' / wallet'\n\nApostrophe in the path indicates that BIP32 hardened derivation is used.\n\nEach level has a special meaning, described in the chapters below.\n\n Purpose\n\nPurpose is a constant set to 43, indicating the key derivation is for a non-bitcoin cryptocurrency.\n\nHardened derivation is used at this level.\n\n Subpurpose\n\nSubpurpose is set to 60, the SLIP-44 code for Ethereum.\n\nHardened derivation is used at this level.\n\n EIP\n\nEIP is set to the EIP number specifying the remainder of the BIP32 derivation path. For paths following this EIP specification, the number assigned to this EIP is used.\n\nHardened derivation is used at this level.\n\n Wallet\n\nThis component of the path splits the wallet into different user identities, allowing a single wallet to have multiple public identities.\n\nAccounts are numbered from index 0 in sequentially increasing manner. This number is used as child index in BIP32 derivation.\n\nHardened derivation is used at this level.\n\nSoftware should prevent a creation of an account if a previous account does not have a transaction history (meaning its address has not been used before).\n\nSoftware needs to discover all used accounts after importing the seed from an external source.\n\n Rationale\n\nThe existing convention is to use the ‘Ethereum’ coin type, leading to paths starting with m/44'/60'/*. Because this still assumes a UTXO-based coin, we contend that this is a poor fit, resulting in standardisation, usability, and security compromises. As a result, we are making the above proposal to define an entirely new hierarchy for Ethereum-based chains.\n\n Backwards Compatibility\n\nThe introduction of another derivation path requires existing software to add support for this scheme in addition to any existing schemes. Given the already confused nature of wallet derivation paths in Ethereum, we anticipate this will cause relatively little additional disruption, and has the potential to improve matters significantly in the long run.\n\nFor applications that utilise mnemonics, the authors expect to submit another EIP draft that describes a method for avoiding backwards compatibility concerns when transitioning to this new derivation path.\n\n Test Cases\n\nTBD\n\n Implementation\n\nNone yet.\n\n References\n\nThis discussion on derivation paths\n\n Copyright\n\nCopyright and related rights waived via CC0.\n\n Citation\n Please cite this document as:\n\n Nick Johnson (@arachnid), Micah Zoltu (@micahzoltu), \"ERC-601: Ethereum hierarchy for deterministic wallets,\" Ethereum Improvement Proposals, no. 601, April 2017. Available: https://eips.ethereum.org/EIPS/eip-601.","tokens":954,"squid":"spider-05","role":"Spec Spider","at":1791341089036,"hash":"177b3fd019edd58c79aecb15bcf09b7721de39d7"}
{"url":"https://docs.arbitrum.foundation/calculate-aep-fees","domain":"docs.arbitrum.foundation","title":"AEP Fees Formula | Arbitrum DAO - Governance docs","text":"✏️Request an updateFee Calculation for Arbitrum Expansion ProgramAll blockchains, including Arbitrum Chains, enable users to create transactions, pay fees, and perform executions on the network. Fees in Arbitrum Chains​In Arbitrum, the chain collects all fees paid by users, and each fee paid is split up to cover different costs associated with the chain. This split includes: L1BaseFee: Fees collected to cover the cost to settle the Rollup's transactions on the parent chain (i.e., blob data). L1SurplusFee: Surplus funds after covering the cost to settle transactions on the parent chain. L2BaseFee: Fees collected to cover the cost of executing transactions based on the L2 gas consumed. L2SurplusFee: Surplus fees collected when an Arbitrum chain is congested. Note that all transaction fees on Arbitrum Chains are deterministic, based on their initial configuration, activity on the chain, and congestion of the parent chain. The Sequencer cannot tweak or impact the fees in real-time. Calculating Arbitrum Expansion Program fees​The Arbitrum Expansion Program requires an Arbitrum Chain to return 10% of a chain's Net Protocol Revenue back to the Arbitrum ecosystem, including the ArbitrumDAO and the Arbitrum Protocol Guild. The Net Protocol Revenue is broadly the difference between (i) gross revenue and (ii) settlement costs, or put another way, the remaining fees after covering the cost to settle transactions on the Arbitrum chain:AEP_FEES = [(gross revenue) - (settlement costs)]*0.1As mentioned earlier, we need to split up the costs for consuming L2 gas to execute transactions on the Arbitrum Chain (\"chain fees\") and the settlement costs for data blobs published on the parent chain (\"settlement fees\"):AEP_FEES = [(sequencing revenue + additional revenue) - (settlement costs)]*0.1 Finally, to connect the net protocol revenue with how the fees are collected on an Arbitrum Chain, they are computed using the following formula:AEP_FEES = [(l2BaseFee + l2SurplusFee + l1BaseFee + l1SurplusFee) - (l1BaseFee)]*0.1The motivation is that the L1BaseFee represents the only on-chain liability for the Arbitrum chain, as it covers the cost of publishing data blobs on the parent chain. All other costs, including L2BaseFee, L2SurplusFee, and L1SurplusFee, represent the net revenue for the chain. The AEP aims to capture 10% of the fees collected. Additional Revenue Sources​The Arbitrum Expansion Program allows projects to customize their Arbitrum chains to suit their business needs. These changes may allow projects to generate other sources of revenue. For example, extracting value via transaction ordering policies, collecting fees when users deposit onto the chain, and other methods that are not necessarily captured by transaction fees on the network. The AEP is sufficiently broad to take into account other revenue sources as they arise in the Arbitrum chain. If your project is seeking non-traditional methods for generating revenue, please consult with the Arbitrum Foundation to ensure the Arbitrum Expansion Program accurately captures it.Special cases and exceptions​Certain Arbitrum chain configurations and customizations require special handling of AEP fees. The following is a non-exhaustive list of applicable scenarios and how to ensure AEP compliance. If any of the following cases apply, the recommended approach for fee handling will require manual handling of a portion of or all AEP Fees.L2-based custom gas tokens​If you are an L3 or higher chain with a custom gas token, your custom gas token contract might be deployed on L2. If this L2 is not an Arbitrum chain, then the L2 token can't be transferred via the AEP Fee Router, as this would first require bridging down to Ethereum (impossible for L2-based tokens). In this instance, we recommend your chain pay fees in ETH by manually sending fees to an ETH-configured routing system.Non-Ethereum L1​If your Arbitrum chain is deployed on a non-Ethereum L1 (e.g., Solana, BNB Chain), your fees must be manually transferred to a Foundation-controlled address.Novel fee-earning customizations​As discussed above in Additional revenue sources, if you have customized your Arbitrum chain to earn revenue through any enshrined component, this revenue must be calculated as part of the AEP fees. In such cases, we recommend engaging with the AF to agree on a revenue model and reporting cadence and then manually send additional fees into the routing system as required.Other cases​If you are still determining if your Arbitrum chain configuration applies to the listed or unlisted special cases, we recommend engaging with the Arbitrum Foundation.Fees in Arbitrum ChainsCalculating Arbitrum Expansion Program feesAdditional Revenue SourcesSpecial cases and exceptionsL2-based custom gas tokensNon-Ethereum L1Novel fee-earning customizationsOther cases","tokens":1210,"squid":"spider-07","role":"Council Spider","at":1791341089344,"hash":"785fa9919f5cec7ffdff44dfd1fe16fa24e59db6"}
{"url":"https://www.paradigm.xyz/build","domain":"paradigm.xyz","title":"Build | Paradigm","text":"Incubation Open Source Featured Writing Many of us have built tools, protocols, and companies that are among the most used on the internet. We write software, much of it open source, and we incubate new companies, from developer tools like Foundry and Reth to Tempo, a payments network we created with Stripe. We also build alongside others, including security evals with OpenAI. Incubation: Tempo Tempo is a payments-first Layer 1 blockchain incubated by Stripe and Paradigm. Built for stablecoins and real-world transactions, Tempo is designed to support faster, lower-cost, programmable payments at global scale. https://tempo.xyzOpen Source Paradigm builds and contributes to projects that advance the frontier. We believe in doing so even when there may not be a direct commercial incentive.\n Centaur Multiplayer, self-hosted, secure agents for Slack. 1.4k 98 255 EVMbench An open benchmark and agent harness from OpenAI and Paradigm that evaluates whether AI agents can detect, patch, and exploit high-severity vulnerabilities. 459 20 75 Foundry Blazing fast, portable and modular toolkit for Ethereum application development written in Rust. 10.6k 727 2.7k Reth Modular, contributor-friendly and blazing-fast implementation of the Ethereum protocol, written in Rust. 5.8k 801 2.6k Alloy Stable, well-tested, and performant building blocks for Ethereum, in Rust. 1.3k 344 685 Artemis Framework for MEV bots in Rust, designed to be simple, modular, and fast. 3k 34 576 Cryo Easiest way to extract blockchain data to Parquet, CSV, JSON, or a Python dataframe. 1.6k 44 188 Solar Blazingly fast, modular and contributor friendly Solidity compiler, written in Rust. 570 51 114 Flood Load testing tool for benchmarking EVM nodes over RPC. 374 23 59 Flux Graph-based LLM power tool for exploring many completions in parallel. 899 29 130 Data Portal Collection of open source crypto datasets for researchers and tool builders. 338 17 20 Rivet Browser extension that enables developers to inspect, debug, modify, and manipulate the state of Ethereum. 927 40 93 Wagmi Developer library with over 20 hooks for working with wallets, contracts, transactions, signing, and more. 6.8k 342 1.4k Viem Fast, modular Typescript interface for Ethereum developers. 3.6k 768 1.6k List/Grid List/Grid All Open Source Centaur 2.0 2026-08-10 Centaur 2.0: Permissions, Context, and MCP 2026-02-18 Introducing EVMbench 2026-02-04 Introducing Paradigm Predictions 2026-04-20 Introducing the 2026 Paradigm Fellowship All Build Writing","tokens":628,"squid":"spider-04","role":"Research Spider","at":1791341092038,"hash":"2ec8efa3ff1641244ebae7dc977a195e87d24dc5"}
{"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":"spider-05","role":"Spec Spider","at":1791341098769,"hash":"40cdebdac0afd684ddfb50607443e18a5f476b9e"}
{"url":"https://docs.arbitrum.foundation/airdrop-eligibility-distribution","domain":"docs.arbitrum.foundation","title":"$ARB airdrop eligibility and distribution specifications | Arbitrum DAO - Governance docs","text":"✏️Request an updatePUBLIC PREVIEW DOCUMENTThis document is currently in public preview and may change significantly as feedback is captured from readers like you. Click the Request an update button at the top of this document or join the Arbitrum Discord to share your feedback.THERE IS NO PRESALEThe only official website for the $ARB airdrop is https://arbitrum.foundation. There is no presale. Don't ever share your seed phrase. When in doubt, join the Discord to ask for clarification.$ARB is an ERC-20 governance token native to the Arbitrum One rollup chain. Token properties at launch:Initial supply cap10 billionInflationMax 2% per yearMinting/burning mechanismL2 smart contractBridgeable to Ethereum L1?YesTokens launch onArbitrum OneOn-chain governance (voting) happens onArbitrum OneAirdrop snapshotBlock 58642080 on Arbitrum One = February 6th, 2023Claiming startedBlock 16890400 on Ethereum Mainnet = March 23rd, 2023. Please note that $ARB cannot be minted or claimed on the Ethereum Mainnet; it is only minted and claimable on Arbitrum One.Claiming endedBlock 18208000 on Ethereum Mainnet = September 24th, 2023. Please note that $ARB is no longer claimable.Token allocation & airdrop distribution​The passing of AIPs 1.1 and 1.2 codified the role of the Arbitrum Foundation and established a grant to the Foundation's Administrative Budget Vesting Wallet. The distribution as of the passing of these two AIPs was as follows:Distribution Post AIPs 1.1 and 1.2​Percentage of initial supplyNumber of tokensAllocated to35.28%3.528 billionArbitrumDAO treasury26.94%2.694 billionTeam and Contributors + Advisors17.53%1.753 billionInvestors11.62%1.162 BillionUsers of the Arbitrum platform (via airdrop to user wallet addresses)7.5%750 millionArbitrum Foundation 1.13%113 millionDAOs building apps on Arbitrum (via airdrop to DAO treasury addresses)User airdrop eligibility details​A points system was used to determine the number of tokens that airdrop recipients can claim. Points criteria was focused primarily on Arbitrum One; however, there was a small subset of criteria applied to activity on Arbitrum Nova. Points earned on Arbitrum Nova could either bring a user up to 4 points total, or give them one additional point if they had already scored 4 points or more on Arbitrum One. You earn maximum one point per qualifying action performed before the snapshot date. Point scores were capped at 15.Additionally, as the criteria and design of the airdrop as a whole was intentioned to reward early adopters, points scored (minimum of three) before Arbitrum Nitro was launched on Arbitrum One mainnet are worth twice as much as points scored after. Arbitrum Nitro launched on Arbitrum One mainnet at block #22207817 (Aug-31-2022 02:32:22 PM +UTC).Qualifying actions:Points earned on Arbitrum OneBridged funds into Arbitrum OneConducted transactions during two distinct monthsConducted transactions during six distinct monthsConducted transactions during nine monthsConducted more than four transactions or interacted with more than four different smart contractsConducted more than ten transactions or interacted with more than ten different smart contractsConducted more than 25 transactions or interacted with more than 25 different smart contractsConducted more than 100 transactions or interacted with more than 100 different smart contractsConducted transactions exceeding in the aggregate $10,000 in valueConducted transactions exceeding in the aggregate $50,000 in valueConducted transactions exceeding in the aggregate $250,000 in valueBridged more than $10,000 of assets into Arbitrum OneBridged more than $50,000 of assets into Arbitrum OneBridged more than $250,000 of assets into Arbitrum OnePoints earned on Arbitrum Nova Bridged funds into Arbitrum NovaConducted more than three transactionsConducted more than five transactionsConducted more than ten transactionsConverting Points to tokens:Points scored (values represent points scored pre-Nitro)Airdrop entitlementLess than 3Not eligible31,25041,75052,25063,25073,75084,25096,250106,750117,25012 or more10,250As described earlier, points scored before and after Arbitrum Nitro was deployed on Arbitrum One mainnet were weighted differently. Points scored before Arbitrum Nitro were worth twice as much as points scored after -- as a result any points scored after Nitro resulted in half as much of an allocation per point shown in the table above. If an address only became fully eligible (minimum of three points) post-nitro, all points scored counted as post-nitro points. Thus, the minimum airdrop entitlement is 625 tokens, half of the minimum entitlement in the table above; the maximum airdrop entitlement is 10250 tokens.User protections:To prevent bots from taking advantage of the airdrop, a number of anti-Sybil rules were established:If an airdrop recipient's wallet transactions have all occurred within a 48-hour period, one point is subtracted.If an airdrop recipient's wallet balance is less than .005 ETH, and if the wallet hasn't interacted with more than one smart contract, one point is subtracted.If an airdrop recipient's wallet address has been identified as a Sybil address during the Hop protocol bounty program the recipient is disqualified. Refer to Arbitrum Sybil Hunting to learn more about the Sybil mitigation methodology. Refer to our Sybil accounts concept document for a conceptual introduction to Sybil accounts.DAO airdrop criteria and distribution​A separate distribution was allocated for DAOs that are building applications in the Arbitrum ecosystem, as well as the Protocol Guild, a collective of Ethereum contributors. In putting together this criteria we worked with Nansen and analyzed on-chain data to determine how many tokens each DAO community was granted. In doing so we took into account a variety of qualitative and quantitative metrics including when the protocol launched, whether it was native or multichain, how much TVL, activity, transaction volume, value of transactions it had, as well as the consistency of maintaining those metrics. The goal of using a broad variety of criteria was recognizing that Arbitrum is home to a diversity of projects that have different KPIs and user interactions.You can view the full list of DAOs and their allocations here.Vesting and lockup details​While the user and DAO airdrops were available at the start of token distribution (3/23/2023), all investor and team tokens are subject to 4 year lockups, with the first unlocks happening one year after the token generation event (3/16/2023) and then monthly unlocks for the remaining three years. The Arbitrum Foundation's allocation is subject to a lockup that began on 4/17/2023 and linearly unlocks over the course of four years; this is enforced by the Arbitrum Foundation Vesting Budget Smart Contract Wallet.Token allocation & airdrop distributionDistribution Post AIPs 1.1 and 1.2User airdrop eligibility detailsDAO airdrop criteria and distributionVesting and lockup details","tokens":1751,"squid":"spider-07","role":"Council Spider","at":1791341099208,"hash":"d23a0acf5494368dda70d6bbaacb5d5bc1e5adcd"}
{"url":"https://www.paradigm.xyz/oss","domain":"paradigm.xyz","title":"Open Source | Paradigm","text":"Incubation Open Source Tools Featured Writing Open Source Paradigm builds and contributes to projects that advance the frontier. We believe in doing so even when there may not be a direct commercial incentive.\n Centaur Multiplayer, self-hosted, secure agents for Slack. 1.4k 98 255 EVMbench An open benchmark and agent harness from OpenAI and Paradigm that evaluates whether AI agents can detect, patch, and exploit high-severity vulnerabilities. 459 20 75 Foundry Blazing fast, portable and modular toolkit for Ethereum application development written in Rust. 10.6k 727 2.7k Reth Modular, contributor-friendly and blazing-fast implementation of the Ethereum protocol, written in Rust. 5.8k 801 2.6k Alloy Stable, well-tested, and performant building blocks for Ethereum, in Rust. 1.3k 344 685 Artemis Framework for MEV bots in Rust, designed to be simple, modular, and fast. 3k 34 576 Cryo Easiest way to extract blockchain data to Parquet, CSV, JSON, or a Python dataframe. 1.6k 44 188 Solar Blazingly fast, modular and contributor friendly Solidity compiler, written in Rust. 570 51 114 Flood Load testing tool for benchmarking EVM nodes over RPC. 374 23 59 Flux Graph-based LLM power tool for exploring many completions in parallel. 899 29 130 Data Portal Collection of open source crypto datasets for researchers and tool builders. 338 17 20 Rivet Browser extension that enables developers to inspect, debug, modify, and manipulate the state of Ethereum. 927 40 93 Wagmi Developer library with over 20 hooks for working with wallets, contracts, transactions, signing, and more. 6.8k 342 1.4k Viem Fast, modular Typescript interface for Ethereum developers. 3.6k 768 1.6k List/Grid List/Grid","tokens":424,"squid":"spider-04","role":"Research Spider","at":1791341102391,"hash":"845acf9b6167349da03141365677d62db362a188"}
{"url":"https://eips.ethereum.org/EIPS/eip-649","domain":"eips.ethereum.org","title":"EIP-649: Metropolis Difficulty Bomb Delay and Block Reward Reduction","text":"🎉 Final\n\n Standards Track: Core\n\n EIP-649: Metropolis Difficulty Bomb Delay and Block Reward Reduction\n\n Authors\n Afri Schoedon (@5chdn), Vitalik Buterin (@vbuterin)\n\n Created\n 2017-06-21\n\n Simple Summary\n\nThe average block times are increasing due to the difficulty bomb (also known as the “ice age”) slowly accelerating. This EIP proposes to delay the difficulty bomb for approximately one and a half year and to reduce the block rewards with the Byzantium fork, the first part of the Metropolis fork.\n\n Abstract\n\nStarting with BYZANTIUM_FORK_BLKNUM the client will calculate the difficulty based on a fake block number suggesting the client that the difficulty bomb is adjusting around 3 million blocks later than previously specified with the Homestead fork. Furthermore, block rewards will be adjusted to a base of 3 ETH, uncle and nephew rewards will be adjusted accordingly.\n\n Motivation\n\nThe Casper development and switch to proof-of-stake is delayed, the Ethash proof-of-work should be feasible for miners and allow sealing new blocks every 15 seconds on average for another one and a half years. With the delay of the ice age, there is a desire to not suddenly also increase miner rewards. The difficulty bomb has been known about for a long time and now it’s going to stop from happening. In order to maintain stability of the system, a block reward reduction that offsets the ice age delay would leave the system in the same general state as before. Reducing the reward also decreases the likelihood of a miner driven chain split as Ethereum approaches proof-of-stake.\n\n Specification\n\n Relax Difficulty with Fake Block Number\n\nFor the purposes of calc_difficulty, simply replace the use of block.number, as used in the exponential ice age component, with the formula:\n\nfake_block_number = max(0, block.number - 3_000_000) if block.number >= BYZANTIUM_FORK_BLKNUM else block.number\n\n Adjust Block, Uncle, and Nephew rewards\n\nTo ensure a constant Ether issuance, adjust the block reward to new_block_reward, where\n\nnew_block_reward = 3_000_000_000_000_000_000 if block.number >= BYZANTIUM_FORK_BLKNUM else block.reward\n\n(3E18 wei, or 3,000,000,000,000,000,000 wei, or 3 ETH).\n\nAnalogue, if an uncle is included in a block for block.number >= BYZANTIUM_FORK_BLKNUM such that block.number - uncle.number = k, the uncle reward is\n\nnew_uncle_reward = (8 - k) * new_block_reward / 8\n\nThis is the existing pre-Metropolis formula for uncle rewards, simply adjusted with new_block_reward.\n\nThe nephew reward for block.number >= BYZANTIUM_FORK_BLKNUM is\n\nnew_nephew_reward = new_block_reward / 32\n\nThis is the existing pre-Metropolis formula for nephew rewards, simply adjusted with new_block_reward.\n\n Rationale\n\nThis will delay the ice age by 42 million seconds (approximately 1.4 years), so the chain would be back at 30 second block times at the end of 2018. An alternate proposal was to add special rules to the difficulty calculation to effectively pause the difficulty between different blocks. This would lead to similar results.\n\nThis was previously discussed at All Core Devs Meeting #09, #12, #13, and #14. Consensus on the specification was achieved in All Core Devs Meeting #19 and specification drafted in EIP issue #649. It was decided to replace EIP #186 and include the block reward reduction along with the difficulty bomb delay in All Core Devs Meeting #20 and #21; accepted in #22.\n\n Backwards Compatibility\n\nThis EIP is not forward compatible and introduces backwards incompatibilities in the difficulty calculation, as well as the block, uncle and nephew reward structure. Therefore, it should be included in a scheduled hardfork at a certain block number. It’s suggested to include this EIP in the first of the two Metropolis hard-forks, the Byzantium fork.\n\n Test Cases\n\nTest cases exist in ethereum/tests #269.\n\n Implementation\n\nThe following clients implemented EIP-649:\n\n Geth #15028\n Parity #5855\n EthereumJ #927\n Cpp-Ethereum #4050\n PyEthereum #383\n\nThe Yellow Paper implements EIP-649 in #333.\n\nOther notable implementations:\n\n Eth-Isabelle #459\n Py-EVM #123\n\n Copyright\n\nCopyright and related rights waived via CC0.\n\n Citation\n Please cite this document as:\n\n Afri Schoedon (@5chdn), Vitalik Buterin (@vbuterin), \"EIP-649: Metropolis Difficulty Bomb Delay and Block Reward Reduction,\" Ethereum Improvement Proposals, no. 649, June 2017. Available: https://eips.ethereum.org/EIPS/eip-649.","tokens":1105,"squid":"spider-05","role":"Spec Spider","at":1791341108869,"hash":"5593ca95de2deca9d81ffed5c6bd4ed58a4d11f3"}
{"url":"https://docs.arbitrum.foundation/how-tos/select-delegate-voting-power","domain":"docs.arbitrum.foundation","title":"How to delegate your voting power: A guide for $ARB token holders | Arbitrum DAO - Governance docs","text":"✏️Request an updatePUBLIC PREVIEW DOCUMENTThis document is currently in public preview and may change significantly as feedback is captured from readers like you. Click the Request an update button at the top of this document or join the Arbitrum Discord to share your feedback.Delegating your voting power is an essential part of participating in the ArbitrumDAO. As a token holder, you have the ability to vote on governance proposals and to elect members of the Security Council. If you don't have the time or resources to actively participate in the DAO's governance, you can still make your voice heard by delegating your voting power to a delegate. This how-to will walk you through the process of evaluating and selecting a delegate.Delegate your voting power on the on-chain governance UI​Before you delegate your voting power, it's important to understand that by delegating your voting power, you're entrusting someone else to vote on your behalf. So it's really important to choose a delegate who aligns with your values and who you trust to make decisions in the best interest of the ArbitrumDAO and its community.To delegate your voting power, you'll need an Ethereum wallet that holds $ARB tokens, such as MetaMask. Once you have your wallet set up, you can follow these steps:Go to the ArbitrumDAO page in the on-chain governance UI.Connect your wallet by clicking on \"Connect Wallet\" and selecting the address that holds your $ARB tokens.Click on the \"Delegates\" tab on the top menu.Search for the delegate you'd like to delegate your voting power to and select their profile.Once you have read the profile, select the “Delegate to this address” button, and confirm the delegation by following the prompts.Wait for the transaction to be confirmed on the Arbitrum One network.Once your transaction is confirmed, your voting power will be assigned to the delegate you've chosen. You can also check your delegation by going to the \"My Delegation\" tab and looking for the delegate you've chosen.When selecting a delegate, it's important to consider the following:The delegate's values, as outlined in the Constitution and their position on the proposals.The delegate's track record, if they have one.The delegate's level of engagement with the community and their willingness to listen and respond to feedback.The delegate's level of technical expertise and their experience in the space.By following these steps and considering these factors, you can ensure that you're delegating your voting power to a trustworthy and competent delegate who will work to further the goals of the ArbitrumDAO and its community. If you have any questions or concerns, visit the ArbitrumDAO governance forum.Delegate your voting power on the on-chain governance UI","tokens":690,"squid":"spider-07","role":"Council Spider","at":1791341111807,"hash":"a5ec2715007f060d3b581e2587e3e5b28fd8157a"}
{"url":"https://developer.arbitrum.io/how-arbitrum-works/deep-dives","domain":"developer.arbitrum.io","title":"Deep dives","text":"Deep divesDetailed explanations of AnyTrust, ArbOS, assertions, messaging, gas, and the transaction lifecycle.Request an updateDetailed explanations of the mechanisms behind Arbitrum: AnyTrust, ArbOS, assertions, parent-to-child and child-to-parent messaging, the transaction lifecycle, and gas and fees.\nTransaction lifecycleHow a transaction is submitted and processed end to end.The SequencerHow transactions are ordered, and what censorship resistance means.Sequencer transaction flowThe queue, block timing, and the sequencer feed.The batch posterHow batched transactions reach the parent chain.AssertionsWhat an assertion claims, and how one is made.FinalityWhen a transaction becomes irreversible.State Transition FunctionThe function that advances Nitro's chain state.ArbOSThe child chain hypervisor: resources, blocks, and execution.Gas and feesParent chain pricing formulas and child chain gas mechanics.Parent to child messagingHow messages travel down to a child chain.Child to parent messagingHow messages travel back up to the parent chain.Token bridgingThe architecture behind the token bridge.AnyTrust protocolHow AnyTrust cuts costs with a data availability committee.How is this guide?STFLearn the fundamentals of the State Transition Function within Arbitrum Nitro.","tokens":321,"squid":"spider-01","role":"Chain Spider","at":1791341239281,"hash":"bf6434a9b6d93d8c2759530cd2c523157b77b540"}
{"url":"https://akash.network/blog/introducing-console-air-self-host-self-custody","domain":"akash.network","title":"Introducing Console Air: Self-Host, Self-Custody Akash","text":"TL;DR: Akash Console is splitting into two products: the managed-wallet Console at console.akash.network (credit card, no-wallet users), and Console Air — an open-source, self-hostable console for self-custody users with Keplr wallet, custom RPC nodes, and full transaction signing. Self-custody features migrate to Console Air on May 18, 2026.\n\nWe’re splitting Akash Console into two products.\nThe console you know at console.akash.network is becoming more focused: managed wallets, credit-card billing, and the shortest possible path from “I have a Docker image” to “it’s running on Akash.” Everything that supports that goal stays. Everything that doesn’t is moving.\nThe self-custody features (connecting your own Keplr wallet, signing your own transactions, running the console against your own nodes) are not going away. They’re moving to a new home: Console Air. Console Air is open source, self-hostable, and preserves the full self-custodial experience for the users who want it.\nThis split is formalized in AEP-84, the Akash Enhancement Proposal that outlines the rationale, scope, and migration path.\nWhy split the product?\nAkash Console has been trying to be two things at once:\n\nThe fastest on-ramp to decentralized compute, for people who don’t already hold ACT, don’t run a Cosmos wallet, and just want to deploy something. For these users, every wallet pop-up, every “go fund this address,” every “sign this transaction” is a paper cut.\nA first-class self-custody UI, for the developers, builders, and providers who already live in the Cosmos ecosystem, hold ACT, and want full control over keys, RPC nodes, and signing.\n\nOptimizing for both at the same time means doing neither of them as well as we could. Every product decision was a compromise: do we surface the credit-card flow, or the Keplr flow? Do we hide gas details, or expose them? Do we route through our managed signer, or your local one?\nBy splitting, we can stop compromising:\n\nAkash Console becomes the cleanest possible managed-wallet experience. No mnemonic prompts. No chain switching. No “what’s a gas adjustment?” Just deploy.\nConsole Air becomes a serious tool for self-custodial users. Run it locally or self-host it. Use your own nodes. Sign your own transactions. Own the entire stack end-to-end.\n\nBoth consoles point at the same Akash Network: the same providers, the same deployments, the same chain. You can use either, or both.\nWhat’s moving to Console Air\nIf you’re a self-custody user today, here’s what to expect on Console Air:\n\nConnect your own Keplr wallet\nSign every transaction yourself\nConfigure custom RPC and API endpoints\nManage your own deployment certificates\nSelf-host the entire UI behind your own domain if you want to\n\nIf you’re a managed-wallet user (you signed in with email or social login, and the console handles signing for you), nothing changes. Stay on console.akash.network.\nMigrating: Export your local data\nIf you’ve been using self-custody on Akash Console, your local data (saved deployments, certificates, network preferences, favorites) lives in your browser. We’ve made it easy to bring it with you.\nIn Akash Console → App Settings → General, click Export Local Data. You’ll get a JSON file containing your settings, certificates, and deployment metadata.\nIn Console Air, go to the same settings page and click Import Local Data. Pick the file you exported. Done. Your deployments and certificates are right where you left them.\nThis works because Console Air is the same codebase, minus the managed-wallet flows. Local storage formats are identical, so the export/import is a straight one-to-one transfer. The export is a full snapshot of everything Console stores in your browser, so nothing is left behind.\nFor the full step-by-step walkthrough, see the migration guide.\nTimeline\nConsole Air is the new home for self-custody. Self-custody flows will be removed from console.akash.network on May 18, 2026 (00:00 UTC). Until then, deprecation notices will appear in-app and the export tool will keep working so you always have a clean migration path.\nYou’ll start seeing an in-app banner pointing here and to Console Air in the lead-up to the cutoff. Once you’ve migrated (or confirmed you don’t need to), dismiss the banner and it stays dismissed.\nWhat happens after May 18, 2026\n\nExisting deployments keep running on-chain. The split is a UI change, not a chain change. Your leases, providers, and escrow accounts are unaffected.\nYou won’t be able to manage self-custody deployments from console.akash.network anymore. Close, update, redeploy, and certificate management for self-custody wallets move to Console Air.\nManaged-wallet users are not affected. If you signed in with email or social login, nothing about your experience changes.\n\nIf you have a self-custody deployment you want to keep managing through a UI, export your local data and import it into Console Air before May 18.\nTry Console Air\nThe repository is at github.com/akash-network/console-air. Clone it, run it locally, or deploy your own instance. The README walks through both. Issues, PRs, and feedback welcome.\nIf you have questions about the split or the migration, find us in the Akash Discord or open an issue on the Console Air repo. This is the start of a more focused product on both sides, and we want to hear how it lands.\nFrequently Asked Questions\nWhat is Console Air?\nAn open-source, self-hostable Akash Console for self-custody users — supporting Keplr wallet connections, self-signed transactions, custom RPC/API endpoints, and deployment certificate management.\nWhy is Akash splitting Console into two products?\nTo optimize each experience independently — the main Console becomes the fastest managed-wallet on-ramp (no crypto knowledge needed), while Console Air becomes a serious tool for self-custodial power users and developers.\nWhat happens to self-custody features on May 18, 2026?\nSelf-custody flows (Keplr wallet, manual transaction signing) are removed from console.akash.network. Self-custody users must migrate to Console Air to continue managing their deployments.\nHow do I migrate my data from Console to Console Air?\nIn Akash Console → App Settings → General, click ‘Export Local Data.’ In Console Air, import the JSON file. All saved deployments, certificates, and preferences transfer directly — same data format.\nDo existing deployments keep running during the migration?\nYes — the split is a UI change only, not a chain change. On-chain leases, providers, and escrow accounts are unaffected. Existing workloads continue running regardless of which console you use.\nWhere is Console Air’s repository?\nAt github.com/akash-network/console-air — clone it, run locally, or self-host behind your own domain. The README covers both setup paths.\nAre managed-wallet (credit card) users affected by this change?\nNo — if you use email or social login, nothing about your Akash Console experience changes. The split only affects users with self-custody Keplr wallet connections. \nFast, affordable inference for open models\n\nRun Llama, Qwen, GLM and more on Akash's open compute marketplace.\nDrop-in API compatibility means you can\n switch in minutes.\n\nTry AkashML\n(opens in a new tab) \nnote\n\ntip\n\nCaution\n\nDanger","tokens":1810,"squid":"spider-03","role":"Compute Spider","at":1791341246817,"hash":"90b1c420b29c5642510d931bc47c3b3eb953a984"}
{"url":"https://docs.switchboard.xyz/custom-feeds/advanced-feed-configuration/variables-with-cachetask","domain":"docs.switchboard.xyz","title":"Variables with CacheTask | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.You can store data in the task-runner's variable cache by using a CacheTask. This is a useful tool when you have a task that is complex, or requires the use of a lot of dynamically computed numbers.CacheTaskThe following is an example of a CacheTask specifying multiple variables, building off of one another.{\n cacheTask: {\n cacheItems: [\n {\n // Create FAIR_VALUE_HEX from the hex returned from an ETH RPC Call\n variableName: \"FAIR_VALUE_HEX\",\n job: {\n tasks: [\n {\n httpTask: {\n url: \"https://rpc.exampleRPC.org/\",\n method: 2,\n headers: [\n { key: \"content-type\", value: \"application/json\" },\n ],\n body: '{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"eth_call\",\"params\":[{\"to\":\"0xf5fa1728babc3f8d2a617397fac2696c958c3409\",\"data\":\"0x3ca967f3\"},\"latest\"]}',\n },\n },\n {\n jsonParseTask: {\n path: \"$.result\",\n },\n },\n ],\n },\n },\n // Parse the hex and scale it down 10^6, store the result in FAIR_VALUE\n {\n variableName: \"FAIR_VALUE\",\n job: {\n tasks: [\n {\n valueTask: {\n hex: \"${FAIR_VALUE_HEX}\",\n },\n },\n {\n divideTask: {\n big: \"1000000\",\n },\n },\n ],\n },\n },\n\n // Create a new variable, FAIR_VALUE_LOW, which is value * 0.95\n {\n variableName: \"FAIR_VALUE_LOW\",\n job: {\n tasks: [\n {\n valueTask: {\n big: \"${FAIR_VALUE}\",\n },\n },\n {\n multiplyTask: {\n big: \"0.95\",\n },\n },\n ],\n },\n },\n\n // Create a new variable, FAIR_VALUE_HIGH, which is value * 1.05\n {\n variableName: \"FAIR_VALUE_HIGH\",\n job: {\n tasks: [\n {\n valueTask: {\n big: \"${FAIR_VALUE}\",\n },\n },\n {\n multiplyTask: {\n big: \"1.05\",\n },\n },\n ],\n },\n },\n ],\n },\n},This large task does quite a number of things. It does the following:It calls an EVM contract and parses some hex using a JsonParseTask, then creates a new variable called FAIR_VALUE_HEX that stores a JSON value.It parses that hex into a new variable, FAIR_VALUEIt creates a low value to be used in subsequent jobs by using a MultiplyTask and setting 0.95 * FAIR_VALUE to FAIR_VALUE_LOWIt creates a high value to be used in subsequent jobs by using the same method to set 1.05 * FAIR_VALUE to FAIR_VALUE_HIGHIn subsequent jobs one can reference the values locked in these variables.Math TasksVariables are easily combined with math-related tasks, AddTask, MultiplyTask, SubtractTask , and DivideTask are some really common ones. These tasks will run agains whatever number is in the current_value of the task-runner context.They can also be combined with ValueTask to pull a variable into the current_value position.For example:// ... CacheTask from above\n{\n valueTask: {\n big: \"${FAIR_VALUE}\"\n } \n},\n{\n multiplyTask: {\n scalar: 2\n }\n}Inside of Math Tasks you can specify one of the following fields:/** Specifies a scalar to multiply by. */\nscalar?: number | null;\n\n/** Specifies an aggregator to multiply by. */\naggregatorPubkey?: string | null;\n\n/** A job whose result is computed before multiplying our numerical input by that result. */\njob?: oracle_job.IOracleJob | null;\n\n/** A stringified big.js. `Accepts variable expansion syntax.` */\nbig?: string | null;PreviousData Feed Variable OverridesNextREST APIs with HttpTaskLast updated 1 year ago","tokens":785,"squid":"spider-08","role":"Oracle Spider","at":1791341248871,"hash":"20b2915537a56982d53be2f4fd611d60e64221bc"}
{"url":"https://developer.arbitrum.io/how-arbitrum-works/deep-dives/assertions","domain":"developer.arbitrum.io","title":"Assertions","text":"AssertionsDeep dive information on assertions and how to make an assertion.Request an updateThe Rollup chain assertions vs. child chain blocks\nThe Rollup chain consists of , 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 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 , the gentle introduction provides an overview that touches on the Rollup chain.\nValidators and proposers serve different rolesValidators validate transactions by computing the next 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 ; 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';\nimport { getArbitrumNetwork } from '@arbitrum/sdk';\nimport { BoldRollupUserLogic__factory } from '@arbitrum/sdk/dist/lib/abi-bold/factories/BoldRollupUserLogic__factory';\n\n// Look up the child chain's network metadata to find the Rollup address.\nconst childNetwork = await getArbitrumNetwork(childProvider);\n\n// The Rollup contract is deployed on the parent chain, so attach it to parentProvider.\nconst rollup = new Contract(childNetwork.ethBridge.rollup, BoldRollupUserLogic__factory.abi, parentProvider);\n\n// Get the latest confirmed assertion hash.\nconst 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.How is this guide?ArbOSHow ArbOS works as the child chain hypervisor, managing resources, block production, cross-chain messaging, and EVM execution.FinalityLearn the fundamentals of finality on Arbitrum.","tokens":2102,"squid":"spider-01","role":"Chain Spider","at":1791341249167,"hash":"0ea6f0d4961be1089eaf4c94c0b3d52f8a728242"}
{"url":"https://akash.network/roadmap/aep-84/","domain":"akash.network","title":"Console Split: Managed Platform and Self-Custodial Air","text":"Akash Network Roadmap Roadmap 2026 Q3 aep-84 Console Split: Managed Platform and Self-Custodial Air Final Motivation\nAkash Console today tries to serve two fundamentally different users through a single application:\n\nSelf-custodial users who connect a Keplr wallet, sign their own transactions, and own their on-chain identity.\nFully managed users who pay with a credit card and never need to create or manage a crypto wallet.\n\nConsole started as a wallet-only product. Credit card support was added because requiring a wallet created an enormous amount of friction for mainstream developers, and offering both paths has genuinely helped users who spread workloads across multiple platforms.\nHowever, blending both experiences in a single application has become a liability:\n\nUser confusion. The two paths imply different identities, different recovery models, different billing surfaces, and different trust assumptions. New users routinely struggle to understand which path applies to them, and existing users are forced to reason about concepts (wallets, credits, escrow, credit cards) that are only relevant to half of the audience.\nProduct complexity. Almost every new feature has to be designed, implemented, tested, and documented twice — once for the wallet identity model and once for the managed identity model. This has significantly slowed feature velocity and widened the surface area for bugs.\nMisaligned usage. Over 85% of spend on Console today comes from credit card users. Keeping the wallet option inside the managed experience optimizes the product for a small fraction of actual spend while burdening the majority.\n\nAt the same time, the self-custodial, permissionless nature of Akash is a core property of the network that must be preserved. The answer is not to remove the wallet path — it is to give it a home where it can be treated as a first-class experience rather than an alternate mode inside a managed product.\nSummary\nWe propose splitting Akash Console into two dedicated applications, each optimized for a single identity model:\n\nconsole.akash.network — the fully managed platform. No wallet. Credit card billing. Optimized for the lowest possible friction and the broadest possible developer audience.\nConsole Air — the fully self-custodial application. Wallet-only (Keplr and compatible wallets). No managed billing. Optimized for users who want to own their keys, sign their own transactions, and interact with Akash permissionlessly.\n\nEach application has a single identity model, a single billing model, and a single mental model for the user. Features are designed once, for the audience that actually uses them.\nProposed Solution\nconsole.akash.network (Managed Platform)\n\nIdentity: email + password (and/or SSO), backed by the existing managed-wallet infrastructure established in AEP-63.\nPayments: credit card only, including the credit and auto-reload features from AEP-31, AEP-72, and AEP-74.\nScope removed: Keplr connect, manual AKT balance, wallet-signed transactions, wallet-based deployment history.\nScope preserved and expanded: trial credits, auto credit reload, billing & usage, alerts, custom domains, and all other managed features currently on Console’s roadmap.\nEvolution: continues to evolve as a fully managed, opinionated platform — the front door for developers who want Akash’s price/performance without Akash’s crypto surface area.\n\nConsole Air (Self-Custodial)\n\nIdentity: Keplr (and compatible Cosmos wallets) only. Users sign every transaction.\nPayments: AKT (and any future on-chain denominations) paid directly from the user’s wallet to on-chain escrow. No credit card, no managed balance, no off-chain billing.\nScope removed: email sign-up, credit card payments, managed trial credits, server-side account state that isn’t derivable from on-chain data.\nScope preserved: full deployment lifecycle (SDL, bid, lease, manifest, logs, shell, updates, close), provider selection, certificates, multi-depositor escrow (AEP-75), and any future on-chain features that require direct wallet signing.\nPositioning: the canonical reference client for permissionless Akash usage. Open to any wallet and any provider, with no gatekeeping layer between the user and the chain.\n\nMigration\n\nExisting managed (credit card) users continue on console.akash.network with no action required. The domain and account system stay the same.\nExisting self-custodial users on console.akash.network are guided to Console Air. For a transition period, console.akash.network will display a clear banner for any user arriving with a connected Keplr wallet, directing them to Console Air with a one-click handoff that preserves the connected address.\nThe wallet-connect code path in console.akash.network is removed after the transition period ends.\nDocumentation, tutorials, and all external links are updated to point to the appropriate application based on audience.\n\nShared Infrastructure\nThe two applications live in separate repositories — akash-network/console for the managed platform and akash-network/console-air for the self-custodial app — and share code through published @akashnetwork/* packages:\n\nSDL editor, deployment lifecycle UI components, and provider selection logic via shared UI packages.\nCommon design system and component library (@akashnetwork/ui).\nThe Console API layer (AEP-63, AEP-69, AEP-70) for features that apply to both audiences (e.g., provider data, pricing).\nChain SDK, network utilities, and HTTP clients for talking to Akash.\n\nWhat is not shared is the identity, billing, and account management surface. Those diverge cleanly between the two apps and are no longer forced into a single abstraction. Splitting at the repository boundary (rather than within a monorepo) reinforces the separation: each app’s dependencies, CI, release cadence, and contributor model can evolve independently of the other.\nRationale\nWhy split rather than hide\nWe considered keeping a single application and hiding the wallet path behind a feature flag or a hidden route. This fails the core goal: a single app still forces every feature designer, PM, and engineer to reason about both identity models when making changes, even if one is rarely surfaced in the UI. A clean split aligns the codebase, the surface area, and the team with the audience.\nWhy keep Console Air rather than deprecate it\nThe self-custodial path is a defining property of Akash. Removing it from Console entirely — without an obvious replacement — would signal that Akash is retreating from its permissionless roots. Console Air preserves and in fact strengthens that path by giving it a dedicated, uncompromised home.\nWhy not a third-party wallet-only client\nA first-party, open-source self-custodial client ensures that self-custodial usage of Akash remains practical and well-supported regardless of third-party interest. Existing wallet users on Console already depend on us for this experience; they deserve a smooth transition rather than a hand-off to an unmaintained alternative.\nNaming\n“Console Air” signals a lightweight, no-overhead, pure self-custodial experience, in contrast to the full managed platform at console.akash.network.\nBackward Compatibility\n\nCredit card / managed users: no change. Same URL, same accounts, same billing.\nWallet users on console.akash.network: temporarily supported with a redirect/handoff flow to Console Air, then removed after the transition period. No on-chain state is affected; users retain full access to their deployments via their wallet in Console Air, the Akash CLI, or any other self-custodial client.\nAPI consumers: unchanged. The Console API (AEP-69, AEP-70) continues to serve both applications.\n\nSecurity Considerations\n\nReduced attack surface on the managed side. Removing wallet-signing code paths from console.akash.network eliminates an entire class of phishing and transaction-injection risks for the managed audience, which today has no reason to sign on-chain transactions.\nReduced attack surface on the self-custodial side. Removing managed-billing code paths from Console Air removes server-side account, session, and payment logic from the self-custodial audience, shrinking the trust surface of the application they rely on for signing.\nClear trust model per app. Each application has a single, documented trust model, which makes security review and user education substantially simpler.\nTransition redirect. The handoff from console.akash.network to Console Air for wallet users must only redirect to a verified, first-party domain to avoid being used as a phishing vector.\n\nImplementations\n\nAkash Console: github.com/akash-network/console\nConsole Air: github.com/akash-network/console-air\n\nReferences\n\nAEP-31: Credit Card Payments In Console\nAEP-63: Console API for Managed Wallet Users\nAEP-72: Console - Improved User Onboarding\nAEP-74: Console - Auto Credit Reload\n\nCopyright\nCopyright and related rights waived via Apache License 2.0. Completion date: 7/21/2026 Created: 4/24/2026 Last Updated: Category: Interface Status: Final Authors: Maxime Beauchamp Greg Osuri \nView next aep\n Private Overlay NetworkingEstimated Completion: 7/29/2026Lease-to-lease networking on the Akash Network would provide dynamic IP address management and secure communication between tenants workloads.","tokens":2320,"squid":"spider-03","role":"Compute Spider","at":1791341257948,"hash":"39c421122cf3aeb68eed49e258c777ad4c6c718e"}
{"url":"https://developer.arbitrum.io/how-arbitrum-works/deep-dives/l1-to-l2-messaging","domain":"developer.arbitrum.io","title":"Bridging from a parent chain to a child chain","text":"Bridging from a parent chain to a child chainLearn the fundamentals of parent to child chain messaging on Arbitrum.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 by going through the 's 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 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 chain, this can include:\n\nETH 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. 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 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 {\n require(AddressAliasHelper.undoL1ToL2Alias(msg.sender) == myL1ContractAddress, \"ONLY_COUNTERPART_CONTRACT\");\n _;\n}\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 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 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.How is this guide?Batch posterLearn the fundamentals of the Arbitrum batch poster.Child to Parent chain MessagingLearn the fundamentals of child to parent chain messaging on Arbitrum.","tokens":3306,"squid":"spider-01","role":"Chain Spider","at":1791341260640,"hash":"c673de6141c89522aadf5d5cccdbc66c0e1c9340"}
{"url":"https://docs.switchboard.xyz/custom-feeds/advanced-feed-configuration/rest-apis-with-httptask","domain":"docs.switchboard.xyz","title":"REST APIs with HttpTask | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.HttpTask + JsonParseTaskNext to Oracle and Decentralized Exchange tasks, the most popular way to fetch data is the HttpTask combined with a JsonParseTask. The HttpTask has support for GET and POST methods, along with custom headers and a request body (both optional).Example{\n httpTask: {\n url: \"https://www.binance.com/api/v3/ticker/price\"\n }\n}This Binance api call will result in a json response of the following structurefor all tokens:{\"symbol\":\"BTCUSDT\",\"price\":\"64628.31000000\"} ...In order to pull out the price field from the response, we must follow the HttpTask along with a JsonParseTask. These tasks utilize JsonPaths in order to specify which data to put into the current context. In this case, since we just ran an HttpTask and received this JSON, we have that JSON set as the current_value.Now, the user can use a JsonParseTask to specify the path of the decimal they want to extract, in this case the field BTC-USDT price.{\n jsonParseTask: {\n path: \"$[?(@.symbol == 'BTCUSDT')].price\"\n }\n}Binance BTC/USDT{\n httpTask: {\n url: \"https://www.binance.com/api/v3/ticker/price\"\n }\n},\n{\n jsonParseTask: {\n path: \"$[?(@.symbol == 'BTCUSDT')].price\"\n }\n}This is the assembled tasks to form a Binance BTC/USDT task.OKX BTC/USDT{\n httpTask: {\n url: \"https://www.okx.com/api/v5/market/index-tickers?quoteCcy=USD\",\n },\n},\n{\n jsonParseTask: {\n path: '$.data[?(@.instId == \"BTC-USDT\")].idxPx',\n },\n},Pulling the latest price of BTC in USDT terms from OKX. Just another common HttpTask example, this time getting a value from an array. The return type for the OKX value in this example is:// okx.com endpoint price return\n{\n \"code\": \"0\",\n \"msg\": \"\",\n \"data\": [\n {\n \"instId\": \"BTC-USDT\",\n \"idxPx\": \"64628\",\n \"high24h\": \"66484.2\",\n \"sodUtc0\": \"64877.1\",\n \"open24h\": \"65308.9\",\n \"low24h\": \"64319.8\",\n \"sodUtc8\": \"64827.5\",\n \"ts\": \"1718946430031\"\n }\n ]\n}Kraken Example// Also BTC/USD, but from Kraken\n{\n httpTask: {\n url: \"https://api.kraken.com/0/public/Ticker\",\n },\n},\n{\n medianTask: {\n tasks: [\n {\n jsonParseTask: {\n path: \"$.result.XXBTZUSD.a[0]\",\n },\n },\n {\n jsonParseTask: {\n path: \"$.result.XXBTZUSD.b[0]\",\n },\n },\n {\n jsonParseTask: {\n path: \"$.result.XXBTZUSD.c[0]\",\n },\n },\n ],\n },\n}Here you can see that the user who made this job is using a MedianTask . This allows users to run multiple jobs in parallel and get the median result. Users can also specify a maxRangePercent in the median task in order to fail the request if that value is exceeded.For example:medianTask: {\n maxRangePercent: \"1.5\", // if job results differ by 1.5%, the job run will fail\n tasks: [\n {\n jsonParseTask: {\n path: \"$.result.XXBTZUSD.a[0]\",\n },\n },\n {\n jsonParseTask: {\n path: \"$.result.XXBTZUSD.b[0]\",\n },\n },\n {\n jsonParseTask: {\n path: \"$.result.XXBTZUSD.c[0]\",\n }\n },\n ],\n},Huobi Example// Huobi BTC/USDT\n{\n httpTask: {\n url: \"https://api.huobi.pro/market/tickers\",\n },\n},\n{\n medianTask: {\n tasks: [\n {\n jsonParseTask: {\n path: \"$[?(@.symbol == 'btcusdt')].bid\",\n },\n },\n {\n jsonParseTask: {\n path: \"$[?(@.symbol == 'btcusdt')].ask\",\n },\n },\n ],\n },\n},POST data with HttpTaskThe following is an example with a POST request including headers and a body in an HttpTask:{\n httpTask: {\n url: \"https://example.com\",\n method: 2, // POST\n headers: [\n {\n key: \"Content-Type\",\n value: \"application/json\",\n },\n {\n key: \"Accept-Language\",\n value: \"en-US,en;q=0.9\",\n },\n {\n key: \"Accept\",\n value: \"*/*\",\n },\n ],\n body: '{\"data\":[\"chorizo\",\"fried\"],\"cluster\":\"taco-loco\"}',\n },\n},This is a POST request to example.com. Note that body has to be an encoded JSON string if it is set at all.PreviousVariables with CacheTaskNextHow Feeds are ResolvedLast updated 1 year ago","tokens":934,"squid":"spider-08","role":"Oracle Spider","at":1791341260804,"hash":"88153a256f16a98d1301ea813009318fcd79893a"}
{"url":"https://akash.network/roadmap/2026","domain":"akash.network","title":"Akash Network Roadmap - 2026","text":"Akash RoadmapAkash's roadmap outlines the high-level goals and priorities for the Akash Network.Year:2018201920202021202220232024202520262027aep-76Burn Mint Equilibrium On AkashCompletion Date: 3/22/2026AKT is the native cryptocurrency of Akash Network and was initially conceived as the sole payment method. When a lease is established, tenants and providers agree on a price in AKT. These leases are open-ended, continuing until either party terminates them. However, the fluctuating value of AKT presents a challenge. Participants typically anticipate stable pricing equivalent to USD, and AKT's price instability compromises its utility as a payment mechanism.aep-78Enable CosmWasm Smart Contracts on Akash NetworkCompletion Date: 3/22/2026This AEP proposes enabling CosmWasm smart contract functionality on Akash Network to unlock programmable decentralized cloud infrastructure, enabling automated resource management, advanced settlement mechanisms, and on-chain governance capabilities. This enhancement leverages Pyth Network as a price oracle to support AEP-76's Burn Mint Equilibrium (BME) mechanism and extends Akash's capabilities beyond simple compute marketplaces into a fully programmable cloud platform.aep-80On-Chain Oracle ModuleCompletion Date: 3/22/2026This proposal introduces `x/oracle`, a native Cosmos SDK module that provides trustworthy, aggregated price data for on-chain consumers. The module accepts price submissions from authorized CosmWasm contracts, calculates Time-Weighted Average Prices (TWAP), enforces staleness and deviation health checks, and exposes aggregated prices to other modules via keeper queries. A custom CosmWasm querier and message filter allow smart contracts to both read oracle parameters (including Wormhole guardian sets) and submit verified prices — forming the on-chain backbone for the Burn-Mint Equilibrium (AEP-76) and external oracle integrations such as Pyth (AEP-81).aep-81Pyth Price feed IntegrationCompletion Date: 3/22/2026This proposal introduces a Pyth Network oracle integration for Akash Network, providing cryptographically verifiable AKT/USD price feeds required by the Burn-Mint Equilibrium (AEP-76).aep-60Akash HomeNode - MVPCompletion Date: 4/29/2026Enabling the average \"home\" user to participate in Akash as a provider is critical to both - scaling the supply side of the network as well as positioning the network to lead in the shift away from large data center compute in response to the oncoming energy crisisaep-29Hardware Verification using Trusted ExecutionEstimated Completion: 5/29/2026Currently, hardware provided by a provider is verified using a decentralized network of Auditors on Akash. While this approach is practical for a limited set of providers, the manual verification is proving challenging at scale, even more critical when incentives go onchain and are distributed without a human in the loop. Hardware Verification using Trusted Execution minimizes trust required to verify the accuracy of hardware provided by the providers on Akash network and serves as a fundamental building block for enabling Confidential Computing capabilities, as detailed in AEP-65.aep-59Provider NotificationsEstimated Completion: 5/30/2026Akash users would like to be notified when a provider intends to go offline for maintenance or has an outage.aep-82Resource ReclamationCompletion Date: 6/10/2026Akash providers currently have two options when they need to terminate a lease: close it immediately (viaaep-66Custom Domain CertificatesEstimated Completion: 6/29/2026 This proposal introduces a mechanism for Akash Network tenant workloads to obtain SSL/TLS certificates for their configured custom domains, enabling secure HTTPS access to deployments. aep-67Console Bid ScreeningCompletion Date: 7/16/2026> This revision supersedes the original abandoned design (live per-provider inventory queries with aaep-83Confidential Compute via Kata ContainersCompletion Date: 7/16/2026This AEP defines how tenants request confidential computing workloads on Akash Network and how providers advertise confidential compute capabilities. Tenants set `params.tee` in their SDL to either `cpu` or `cpu-gpu` to request confidential compute. The provider determines the actual TEE platform (AMD SEV-SNP or Intel TDX) at deployment time based on its hardware. Workloads run inside Kata Containers (micro-VMs) on TEE-capable providers. The spec covers CPU-only and GPU confidential computing, NVIDIA GPU passthrough to Kata VMs, attestation sidecars, and combined CPU+GPU attestation.aep-84Console Split: Managed Platform and Self-Custodial AirCompletion Date: 7/20/2026Akash Console today tries to serve two fundamentally different users through a single application:aep-48Private Overlay NetworkingEstimated Completion: 7/29/2026Lease-to-lease networking on the Akash Network would provide dynamic IP address management and secure communication between tenants workloads.aep-65Confidential ComputingEstimated Completion: 7/30/2026Public clouds (like AWS, Azure and GCP) support Confindential Computing because some customers request this before they agree to migrate workloads from their own DCs to public cloud infrastructure. While a vast majority of users don't ask the public clouds for this (and just blindly \"trust\" them) this is likely to become a challenge for Akash's growth particularly because infractstructure on Akash is owned by 10s if not 100s of independent providers.aep-89Unified Akash Command-Line InterfaceThis AEP establishes `akt` as the canonical command-line interface for Akashaep-49Virtual MachinesEstimated Completion: 8/29/2026The concept of virtual machines (VMs) for the Akash Network revolves around leveraging decentralized cloud computing resources to deploy, manage, and scale Virtual Machines securely and cost-effectively.aep-85Console: Buildpacks-Powered DeploymentsEstimated Completion: 9/29/2026This AEP proposes **replacing the current \"Build & Deploy\" feature in Akash Console with a Cloud Native Buildpacks** (buildpacks.io) pipeline. The existing flow — referenced via `CI_CD_TEMPLATE_ID` in `apps/deploy-web/src/config/remote-deploy.config.ts` — is in a broken state, hard-coded to a small set of JavaScript web frameworks, and relies on language detection that only reads `package.json`. Anyone deploying a Python, Go, Ruby, Java, Rust, .NET, or PHP application currently has to abandon the flow and produce a Dockerfile manually.aep-91Console: Escrow Abstraction and Auto-FundingEstimated Completion: 9/29/2026Akash Console exposes the chain's escrow model directly to people paying with a credit card: a deposit amount to pick at deployment creation, an \"Add funds\" button on every deployment, a per-deployment auto top-up toggle, and escrow balance and time-left figures that few users can interpret. This AEP removes all of that for managed-wallet accounts.aep-11Managed Services MarketEstimated Completion: 12/14/2026A permissionless market for Managed Backend Services (such as Databases) to reduce the operational burden for Tenants. aep-53Onchain Provider IncentivesEstimated Completion: 12/30/2026Users want to be incentivized to provide compute resources to the network.aep-79Akash on Shared SecurityEstimated Completion: 12/30/2026> **Migration documentation:** For details about the migration and the current process, see doc/README.md — the Akash Chain Migration Program document set, which specifies the migration to execution depth and supersedes this RFP where the two conflict.aep-92Console: Data Persistence and SecretsEstimated Completion: 12/30/2026Akash Console keeps most of what it knows about a user in that user's browser: the SDL of every deployment they created, provider favorites, the SDL builder draft, deployment names, UI and onboarding state, and, worst of all, secret environment values sitting in plaintext inside drafts and templates. Since the split described in AEP-84, Console is managed-wallet only and every user has a stable server-side identity, so the database can become the source of truth.","tokens":2013,"squid":"spider-03","role":"Compute Spider","at":1791341268147,"hash":"8f4e5828e447df230464ca2b56631741ede72d8a"}
{"url":"https://docs.switchboard.xyz/custom-feeds/advanced-feed-configuration/decentralized-exchanges","domain":"docs.switchboard.xyz","title":"Decentralized Exchanges | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.Jupiter Exchange AggregatorUsers can fetch data from the Jupiter Exchange Aggregator. This can be an effective tool for quoting assets traded on Solana.// KMNO/USD with 2% slippage\n{\n jupiterSwapTask: {\n inTokenAddress: \"EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v\", // USDC\n outTokenAddress: \"KMNo3nJsBXfcpJTVhZcXLW7RmTwTt4GVFE7suUBo9sS\", // KMNO\n slippage: 2.0,\n apiKey: \"${JUPITER_API_KEY}\",\n },\n}Supply the matching non-empty value with the execution request:const response = await gateway.fetchSignaturesConsensus({\n // ...feed request fields\n variableOverrides: {\n JUPITER_API_KEY: process.env.JUPITER_API_KEY!,\n },\n});JUPITER_API_KEY is a conventional name, not a reserved fallback. The override key must exactly match the placeholder in apiKey. If the placeholder is unresolved, the task fails before contacting Jupiter. If apiKey is omitted or empty, the task uses the oracle's configured Jupiter API key when one is available.Do not hardcode an API key in the job definition. See Data Feed Variable Overrides for request scope and trust-boundary guidance, Pyth authentication for its different compatibility fallback, and the JupiterSwapTask reference for every field.RaydiumRaydium is an active hub for DeFi activity on Solana, and Switchboard allows you to quote assets from its Concentrated and Standard pools. All you need is a pool address.The following is an example using Raydium to quote SLERF/SOL, and converting to its USD value using a Pyth task with SOL/USD.// SLERF/USD using Raydium and Pyth\n{\n lpExchangeRateTask: {\n raydiumPoolAddress: \"AgFnRLUScRD2E4nWQxW73hdbSN7eKEUb2jHX7tx9YTYc\", // SLERF/SOL Pool\n },\n},\n{\n multiplyTask: {\n job: {\n tasks: [\n {\n oracleTask: {\n pythAddress: \"H6ARHf6YXhGYeQfUzQNGk6rDNnLBQKrenN712K4AQJEG\", // SOL/USD\n pythConfigs: {\n pythAllowedConfidenceInterval: 1.2,\n },\n }\n }\n ]\n }\n }\n}OrcaYou can pull exchange rates from Orca (Solana AMM). Plugging in any of these pools will yield the resulting price.// SOL/USDC Orca Pool (Aquafarms & Whirlpools)\n{\n lpExchangeRateTask: {\n orcaPoolAddress: \"APDFRM3HMr8CAGXwKHiu2f5ePSpaiEJhaURwhsRrUUt9\",\n }\n}MeteoraYou can read in prices from Meteora using a meteoraSwapTask. You can use it to pull in exchange rates from DLMM pools and standard pools.// mSOL/SOL using Meteora\n{\n meteoraSwapTask: {\n pool: \"HcjZvfeSNJbNkfLD4eEcRBr96AD3w1GpmMppaeRZf7ur\",\n type: 1 // 0 for DLMM, 1 for standard\n }\n}SanctumThe LST protocol on Solana, Sanctum, is also supported. This task is useful for users who want to bring fair Solana LST prices into their protocols through Switchboard.// bonkSOL/USD\n{\n sanctumLstPriceTask: {\n lstMint: \"BonK1YhkXEGLZzwtcvRTip3gAL9nCeQD7ppZBLXhtTs\"\n }\n}UniswapUniswap is probably the most recognized AMM that exists. Switchboard enables users to pull prices from the protocol, along with clones on other chains.Using the uniswapExchangeRateTask, users can bring in exchange rates from Uniswap V2 and Uniswap V3, along with any Uniswap-ABI-compatible protocols (/Uniswap clones on other chains).Here's an example of a Uniswap Task pulling data from the glyph.exchange protocol, on Core, which is a Uniswap V2 fork.// StCore/wCORE on Glyph, a Uniswap V2 Protocol\n{\n uniswapExchangeRateTask: {\n provider: \"https://rpc.coredao.org\",\n inTokenAddress:\n \"0xb3A8F0f0da9ffC65318aA39E55079796093029AD\",\n outTokenAddress:\n \"0x191e94fa59739e188dce837f7f6978d84727ad01\",\n inTokenAmount: 1.0,\n slippage: 0.5,\n version: 0,\n routerAddress: \"0xbfa47708e79d446f0ecc9a9b07a87d5aa788f9df\",\n factoryAddress:\n \"0x3e723c7b6188e8ef638db9685af45c7cb66f77b9\",\n },\n},In the same task for Uniswap V3, a Quoter address should also be passed. Here's an example from corex.network, a Uniswap V3 clone also on Core.// StCore/wCORE on Corex, a Uniswap V3 Protocol\n{\n uniswapExchangeRateTask: {\n provider: \"https://rpc.coredao.org\",\n inTokenAddress:\n \"0xb3A8F0f0da9ffC65318aA39E55079796093029AD\",\n outTokenAddress:\n \"0x40375c92d9faf44d2f9db9bd9ba41a3317a2404f\",\n inTokenAmount: 1.0,\n slippage: 0.5,\n version: 1,\n factoryAddress:\n \"0x526190295AFB6b8736B14E4b42744FBd95203A3a\",\n routerAddress: \"0xcc85A7870902f5e3dCef57E4d44F42b613c87a2E\",\n quoterAddress: \"0xaec2F2306EBEA7f1251ccAB8A409A48a8d8aAa61\",\n },\n},OpenBookThe OpenBook codebase was the first major CLOB on Solana, and we support it through the serumSwapTask . The following is an example of pulling a SOL/USDC price:// Openbook SOL/USDC\n{\n \"serumSwapTask\": {\n \"serumPoolAddress\": \"8BnEgHoWFysVcuFFX7QztDmzuH8r5ZFvyP3sYwn1XTh6\"\n }\n}PreviousBounding ResultsNextOracle AggregatorLast updated 2 months ago","tokens":1157,"squid":"spider-08","role":"Oracle Spider","at":1791341271154,"hash":"90bc97f88425b7fc2abe387c6d9e555eecbf3f83"}
{"url":"https://forum.across.to/t/rfc-grant-request-chaser-finance/1936/4","domain":"forum.across.to","title":"[RFC-Grant Request] Chaser Finance - Ideas & Feedback - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n Ideas & Feedback\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 Jun 2024\n\n 4 / 4\n\n Jan 6\n\n Jan 6\n\n post by chaser.finance on Jun 3, 2024\n\n 11 days later\n\n post by Bananachain on Jun 15, 2024\n\n Bananachain\n\n A realy great post and a fascinating project. \nMy 2 s while reading:\nYou are requesting funding for audit and marketing at different milestone levels (+applying for funding from other protocols). Auditing in particular seems rather on the low side. And good marketing can also be costly. How did you reach these figures?\nFor regulatory reasons I would probably choose to avoid references to airdrops and tokens at this point and rephrase, in particular if you have exposure to the US. It may insinuate some kind of reward expectation given you are linking it to amounts being deposited into a pool. While your issue is decentralisation, this token would also have utility as you outline under “Chaser Liquidity Token”.\n\n post by chaser.finance on Jun 17, 2024\n\n chaser.finance\n\n The auditing budget is based off of a quote for a private audit by a security firm with a good reputation. Ideally, I would like to get a competitive audit done. However, the amount needed to do this is a bit high to ask for in a single grant request. With funding from other DAOs, raising the security budget for a thorough competitive audit is the top priority.\nFor marketing, the budget is based on an estimate for two months of services from social media marketing firms specializing in DeFi projects. These services typically charge between $2000-$3000 USD per month for handling social media strategy and content creation. I plan to contract a firm part-time to grow Chaser’s social media presence leading up to and immediately following the Mainnet launch. At this stage, a full-time role is unnecessary but will be reconsidered post-launch. After secure funding for the competitive audit, expanding the marketing budget is the next priority.\nYou’ve made a great point about tokens and airdrops. Token issuance requires more careful planning and consultation. I’ll remove references to distributing Chaser tokens and design a better plan before launch that rewards loyal users while adhering to regulations.\nAppreciate the feedback!\n\n 2 years later\n\n post by ohhhdigital on Jan 6\n\n ohhhdigital\n\n i fully support this great project, You are requesting funding for audit and marketing at different milestone levels (+applying for funding from other protocols). Auditing in particular seems rather on the low side. And good marketing can also be costly. How did you reach these figures?\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Proposal for Across to generate USDC revenue through ACX covered call lending on MYSO\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 17\n\n Jun 2024\n\n Straddl.io Expansion Proposal\n\n Active Proposals\n\n Active Proposals\n\n 11\n\n Mar 2025\n\n “Community Owned Liquidity” NFT Project Funding Request\n\n Active Proposals\n\n treasury-funding\n\n Active Proposals\n\n 36\n\n Jun 2023\n\n Across Token Launch Proposal v2\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 47\n\n Nov 2022\n\n Across ($ACX) Community Initial Liquidity Proposal\n\n Passed Proposals\n\n Passed Proposals\n\n 49\n\n Nov 2022","tokens":2305,"squid":"spider-09","role":"Bridge Spider","at":1791341281665,"hash":"6bfb75e861cfc84782cbe3a80575c19e1bb3314b"}
{"url":"https://docs.phantom.com/developer-powertools/solana-token-extensions-token22","domain":"docs.phantom.com","title":"Solana Token Extensions (Token22) - Phantom developer documentation","text":"Phantom supports fungible and non-fungible tokens created with the Token-2022 Program. At the time of this writing, Phantom supports the following Token Extensions:\n​Group and Group Pointer\nThe Group and Group Pointer extensions allow token creators to create configurations for grouping tokens together. Phantom currently supports both extensions for non-fungible tokens in the Collectibles tab.\nIf a particular mint has a memberAddress listed under a groupMemberPointer, Phantom will look for the mint and group fields stored at this memberAddress. If the mint address matches the mint value, Phantom will use the group as the new group identifier.\nExample (mainnet): 8eDYWjDKmCR5B3UJm95gaG8zCdT5anWakTZG1PyWpBm9\n​Interest-Bearing Tokens\nThe Interest-Bearing Tokens extension allows creators to set an interest rate on their tokens. This interest rate is for cosmetic purposes only, no new tokens are created as a result of the interest. If this extension is enabled, Phantom will display the current interest rate on the token’s detail screen.\nExample (mainnet): aNMXxywEHAH3VfWnaVwedLJWPT9NsxagsGTEQqS5WKK\n​Memo on Transfer\nThe Memo on Transfer extension enforces that all incoming transfers must have an accompanying memo instruction right before the transfer instruction. If this extension is enabled, an account owner may choose to flip the required memo on or off. Phantom will allow a user to input a memo on transfers, even if it is optional.\nExample on mainnet: BonkEarn CKfatsPMUf8SkiURsDXs7eK6GWb4Jsd6UDbs7twMCWxo\n​Metadata\nThe Metadata extension allows a token creator to include their metadata directly in the token’s mint account. Phantom will display the name and symbol that is stored in the mint account, and look to the uri field for additional information such as the token’s image.\nExample on devnet: EGKdqrXxFeTpRTskrH81xmefuTAU9MJGCDLoNss28a2\n​Metadata Pointer\nThe Metadata Pointer extension allows a token creator to designate an address that describes the canonical metadata. Phantom supports the Metadata Pointer Extension. At the time of this writing, Phantom will assume all metadata schemas follow the Metaplex Standard.\n​Permanent Delegate\nThe Permanent Delegate extension allows token creators to grant unlimited delegation privileges over any account for that mint. If enabled, a delegate can burn or transfer any amount of tokens. Phantom will display a warning for any token that has this extension enabled.\nExample on mainnet: aNMXxywEHAH3VfWnaVwedLJWPT9NsxagsGTEQqS5WKK\n​Transfer Fees\nThe Transfer Fees extension allows a token creator to assess fees on every token transfer. If this extension is enabled, Phantom will display the fee on the confirmation screen of every send.\nExample on mainnet: BonkEarn CKfatsPMUf8SkiURsDXs7eK6GWb4Jsd6UDbs7twMCWxo\n​Transfer Hooks\nThe Transfer Hooks extension allows a token to invoke a custom program at the time of transfer. This program can be used to add custom logic on transfers, such as assessing royalties or determining if the transfer is allowed based on a range of on-chain data sources.Was this page helpful?","tokens":773,"squid":"spider-10","role":"Tooling Spider","at":1791341289181,"hash":"730a8360370b1ab932360018bcb50ebf6d64207d"}
{"url":"https://forum.across.to/t/straddl-io-expansion-proposal/2037","domain":"forum.across.to","title":"Straddl.io Expansion Proposal - Proposals / Active Proposals - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n Straddl.io Expansion Proposal \n\n ProposalsActive Proposals\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 Feb 2025\n\n 1 / 12\n\n Feb 2025\n\n Mar 2025\n\n post by mydefi on Feb 26, 2025\n\n mydefi\n\n Author(s): My Defi, GR (Cat Herder), Infinity\nStatus: Proposal\nSubmission Date: TBD\nSummary:\nStraddl (https://straddl.io) is a next-generation bridging platform built entirely on Across Protocol, designed to offer users highly competitive bridging rates while leveraging the Across Intents Framework (ERC-7683) for an efficient bridge + swap experience. To enhance its utility and further leverage the power of intent-based transactions, Straddl proposes expanding its capabilities to provide deeper DeFi integrations.\nStraddl currently allows users to perform some of the following actions:\n\nBridge ETH/WETH, USDC/USDC.e, USDT, WBTC and DAI on all routes supported by Across Protocol at discounted rates\nBridge + swap to a wide variety of tokens on Optimism, Arbitrum, Polygon, zkSync Era, and Base\nBridge + send gas for users who are bridging to a chain in which they do not yet have the necessary token for performing transactions (such as Polygon)\nRelay deposits sitting on the open market and available for anyone to fill\n\nThis expansion will introduce features that allow users to:\n\nBridge + swap on Uniswap on Unichain, improving efficiency for users looking to move liquidity cross-chain,\nBridge + swap on all other chains with high-liquidity DEXes (including Mainnet)\nBridge + send gas on additional chains where ETH is not the native token (i.e. Aleph Zero)\nBridge + deposit into Aave to streamline access to lending opportunities,\nBridge + repay/pay down debt on Aave, enabling more seamless debt management,\nand much more!\n\nBy integrating these features as well as several other UI improvements, Straddl aims to enhance the user experience, unlock new DeFi possibilities, and solidify its position as a premier intent-based bridging solution.\nThis benefits Across as a direct source of exclusive bridge volume in contrast with other system integrators that also service competing protocols.\nAdditionally, this proposal includes a request for funding to support development efforts, compensate contributors, and bootstrap user engagement campaigns on Intract and other similar platforms.\nMotivation:\nAcross Protocol’s Intents Framework presents a unique opportunity to redefine bridging by incorporating advanced DeFi interactions. Currently, users must execute multiple transactions manually to bridge assets and interact with protocols like Aave or Uniswap, resulting in higher gas costs, longer transaction times, and added complexity.\nStraddl’s expansion aims to address these inefficiencies by enabling users to bridge assets while simultaneously executing DeFi actions in a single, optimized transaction. This not only improves UX but also expands the utility of Across Protocol by demonstrating the power of ERC-7683-based intent execution in real-world DeFi applications.\nAlthough Across has gained a significant share of volume through system integrators, a fully featured app that supports a broad set of intent-based actions offers direct benefits. This includes handling more complex orders, such as cross-chain swaps, and capturing volume not supported by the standard Across front-end application. Additionally, another bridge interface improves service availability in case services managed by Risk Labs are impacted.\nStraddl.io has been a fully grassroots project from the start, built and maintained without any outside capital. Despite this, contributors have dedicated significant time and effort to making Straddl a leading intent-based bridging platform. One of our core contributors, Infinity, has put in extensive development work—which can only be described as relentless commitment—without receiving any compensation to date. This proposal seeks to fund the next phase of Straddl’s growth while also retroactively compensating Infinity for his invaluable contributions.\nAdditionally, Straddl is 100% aligned with Across Protocol—it does not integrate or rely on any other bridges. The project is solely focused on leveraging Across to create a seamless, intent-driven DeFi experience, reinforcing its role as a key builder in the Across ecosystem. Furthermore, all of Straddl’s contributors—GR, Infinity, and My Defi—are active community members who regularly provide development support within the Across Protocol Discord.\nNotably, in 2023 and 2024, Across Protocol ran a “Community Integrations Bounty” program designed to encourage projects like Straddl. However, this initiative did not gain much traction, and the allocated token rewards were ultimately returned to the DAO. Given that Across had already set aside funds for community-driven integrations, we believe this signals that the community may be open to reallocating some of these unused funds to support Straddl’s continued development.\nTo ensure successful execution and adoption of these new features, this proposal also requests funding for engagement campaigns on platforms like Intract. These campaigns will drive awareness, increase usage, and reward early adopters who contribute to the platform’s growth.\nCurrent growth\nTo date, Straddl has grown through two primary avenues: organic adoption and targeted campaigns on the Intract platform. Despite operating without external funding, Straddl has achieved significant traction, demonstrating strong user interest and engagement. As of February 2025, Straddl has recorded:\n\n72,800+ Straddl “questers” on the Intract platform\n3,400+ deposits and relays completed on Straddl.io in February alone\n3,400+ members in the Straddl Discord community\n3,200+ followers on Straddl’s Twitter/X account (created in September 2024)\n100+ users who fully completed all tasks in Straddl’s Intract campaigns\n$2,000 in USDC rewards distributed to Intract campaign winners (as of February 28, 2025)\n\nThese early results highlight Straddl’s ability to attract and engage users, even with minimal resources.\n1600×793 163 KB\nSpecification & Implementation:\nThis proposal seeks funding to support Straddl’s next phase of development, focusing on:\n\nFeature Upgrades – Expanding Straddl’s capabilities by integrating additional DeFi interactions using Across Protocol’s Intents Framework (ERC-7683). These enhancements will enable users to combine bridging with actions like depositing into lending protocols, repaying loans, or swapping assets in a single, optimized transaction.\nUI/UX Enhancements – Improving the front-end experience to make cross-chain interactions more intuitive, reduce friction, and increase adoption. This includes refining the user interface, streamlining transaction flows, and optimizing gas efficiency.\nContributor Compensation – Ensuring that core contributors, including Infinity, are compensated for their past and ongoing work, enabling continued development and support.\nUser Engagement & Growth – Allocating funds to run targeted campaigns on platforms like Intract, rewarding early adopters, and driving user adoption through strategic engagement initiatives.\nBackend & Infrastructure Improvements – Optimizing transaction batching and execution logic to ensure cost-efficiency, security, and seamless integration with Across Protocol.\n\nBy implementing these upgrades, Straddl will reinforce its role as a key builder within the Across Protocol ecosystem while demonstrating the power of intent-based bridging.\nStraddl Team Members and Responsibilities\nGR is a long-standing member of the Across community and one of the earliest Across Protocol relayers. He has made significant contributions to the Across DAO and Across Protocol, including two discord bots, a bountied demo app for Across+, the formation of the Community Essentials Committee and many hours of support for relayers, users and developers in the community. GR has a fintech background with extensive knowledge in several domains including payments, security and risk management.\nMy DeFi is an active Across community member, Across Protocol relayer, is currently on the Across UMA Voting Committee, and has previously served the Across DAO as a Community Essentials Committee member. My DeFi is also a software developer and co-contributor of Straddl (straddl.io) which leverages the power of Across+ to provide advanced bridging capabilities for users and other DeFi apps.\nInfinity is an experienced Computer Engineer with a decade of experience, and for several years, linked to Web3 development as a Front End Dev. He has skills that allow him to solve different tasks with great quality. He joined Across Protocol and since then he was an important member of the community, making himself stand out. He was given the role of Events Master and also the role of Moderator. He was later selected for the Dev Support role because he had the skills to perform it adequately, performing all these roles at the same time efficiently. Also, at the proposal of the members of the CEC and the support of the community, he was promoted to occupy a place in the CEC. Its superpower lies in practically being available 24 hours a day and supporting everything necessary in the fastest and most efficient way possible. Now he was also promoted to the Community Moderator role. Focused on maintaining a pleasant and harmonious environment at all times.\nRevenue Distribution/Compensation\nStraddl is requesting 100,000 ACX tokens (~$27,000 at the current ACX price) for this funding and future development. The funds will be allocated as follows:\n\n12,500 ACX (~$3,400 at the current ACX price) to be allocated for Intract campaign rewards (Intract rewards are provided as USDC)\n12,500 ACX (~$3,400 at the current ACX price) to be distributed to Infinity for his contributions to date\n75,000 ACX (~$20,200 at the current ACX price) to be allocated to the Straddl team (GR, Infinity, and My Defi) over the course of the next 12 months to complete all of the updates outlined in this proposal and cover the cost of associated expenses. These costs include:\n\nTwo prior Intract campaigns\nAccount servicing costs including (Discord, Email, Twitter etc)\nInfrastructure and hosting fees\nGas faucet funds and contract deployments\n\nRationale\nThis proposal requests funding to support both development efforts and ecosystem growth. The requested amount is based on:\n\nDevelopment & Compensation – Supporting ongoing technical upgrades while fairly compensating contributors, including retroactive compensation for Infinity, who has worked extensively without pay.\nUser Engagement & Adoption – Providing incentives for early adopters and contributors through Intract and other engagement platforms, ensuring a strong initial user base.\nSustainability – Enabling Straddl to continue iterating and improving, reinforcing its alignment with Across Protocol whilst showcasing the power and innovation possible with ERC-7683 intent execution.\nResilience – An alternative bridge service enhances the availability of the Across Protocol, ensuring that the primary service managed by Risk Labs is not a single point of failure.\nReallocation of Unused DAO Funds – Across Protocol previously allocated rewards for its Community Integrations Bounty, which were returned due to low participation. Given this precedent, we believe there is an opportunity to reallocate a portion of these unused funds to support Straddl’s expansion.\n\nThis funding will ensure that Straddl not only continues to operate but also grows into a cornerstone of the Across Protocol ecosystem.\nTo ensure transparency, the Straddl team will share quarterly progress updates in the Across Protocol Discord.\n\n 3\n\n 2\n\n read \n\n 6\n min\n\n post by Bananachain on Feb 27, 2025\n\n Bananachain\n\n Have tested Straddl.io and it works very smoothly and reliably. The good thing here is we have a MVP to use and test, not only an idea. So the team has shown it can deliver. Great to see community members committed to buidling a project on Across protocol, finally! \n\n post by PVMihalache on Feb 27, 2025\n\n PVMihalache\n\n This is not just an integration… is much more! Straddl shows to the world that building on top of Across is a step forward.\nStraddl may be the dApp that sparks the next generation of applications building with Across, giving a hand on Unifying Ethereum!\n\n post by neondaemon on Feb 27, 2025\n\n neondaemon\n\n I’ve read the proposal in detail and I believe what they are asking for is modest considering how much added value they are bringing to the Across ecosystem. Have projects like Straddl building on top of Across and adding functionality like cross-swaps is making DeFi more convenient. There have a great track record of delivering and confident they will deliver on their ambitious plans. Lastly Straddl has become my goto bridge and the guys are continually improving it!\n\n post by berry4144 on Feb 27, 2025\n\n berry4144\n\n It appears very good value for twelve months worth of future work (plus prior work getting setup).\nDo we have any $ volume numbers that straddl has put through Across? And do you have an aspiration of where you want to take it?\n\n post by mydefi on Feb 27, 2025\n\n mydefi\n\n Hi @berry4144, we were late to start tracking data so we don’t have anything prior to the beginning of the most recent Intract campaign which started Feb 1, but here’s what we have over the last 28 days. Keep in mind this also includes about 3-4 days in which we had to pause Straddl due to significant contract upgrades to Across Protocol in mid-February:\nMonth of February 2025:\nTotal volume: $262,767.41\nETH/WETH:\n3511 deposits\n84.85175 ETH total volume ($217,075.78)\n0.02416 ETH ($61.83) average bridge size\nUSDC/USDT:\n1097 deposits\n$45,691.63 total volume\n$41.65 avg bridge size\nUser actions:\n206 Unique wallet addresses in Feb 2025\n1159 bridge + action (bridge + swap, bridge + refuel) actions in Feb 2025\n\n post by christinadotcom on Feb 28, 2025\n\n christinadotcom\n\n i started using Straddl by curiosity and ended up bookmarking the link and using it every time i need to bridge or swap crypto. amazing job from GR, Infinity and MyDefy\n\n post by Bananachain on Feb 28, 2025\n\n Bananachain\n\n I have some points I would like to share and am interested in your thoughts:\nThe current funding request draft requests ACX with an indicative USD value only. This appears not be in line with the Across Governance Operating Manual, see Proposal Types, Treasury Funding-Medium which requires USD value funding requests. That may affect any ACX payout depending on exchange rate.\nThe request seeks retroactive funding (Infinity) as well as “future” funding.\n\nIt may be helpful to provide some more details on Infinities contributions for those readers who have not followed his activities. I personally have no doubt it is well deserved!\n\nRegarding “future” funding it appears to be a payout upfront. Aren’t payouts usually milestone based? And if yes, what would those be in relation to funding amounts and how would they be monitored and evaluated? I did see the bullet points regarding expenses and a reference made to the things that you are planning of completing.\n\n post by spaceyfoo on Mar 1, 2025\n\n spaceyfoo\n\n I have bridged multiple times using Straddl and its actually good and CONVENIENT. I find myself using it frequently now. I would suggest to also plan for a little bit of marketing because I believe Straddl has much more to offer for newcomers to turn them into frequent users.\n\n post by easten03 on Mar 1, 2025\n\n easten03\n\n I am using straddl bridge since last 5 months it is reliable there is proper liquidty an almost all chains no any bugs found earlier there was failed transcition issue but team fixed it properly\n\n post by denvercolt on Mar 1, 2025\n\n denvercolt\n\n I’ve read the proposal and support it. Straddl is a good platform with many useful features that I’ve myself come to use quite often. This proposal will definitely help the expansion and new integrations for Straddl as well as Across.\n\n post by mydefi on Mar 3, 2025\n\n mydefi\n\n Bananachain\n\n Thanks so much for this feedback!\nRegarding the ACX / USD value, in efforts to be fully transparent we’re providing both USD and ACX values in the proposal, but ultimately the final request will be denominated in ACX as that is what oSnap needs to execute the distribution on a successful proposal. I also believe our funding request falls into the “Treasury Funding - Small” category as the amount requested is well under $50k USD.\nResponding to your other points:\n\nInfinity’s contributions can generally be siloed into two main, critical areas: front-end development and UI, and community management/growth. In the area of front-end development, Infinity has essentially become the lead developer of the website front-end, pushing forward on adding new features and UI fixes and improvements. On the community end, he’s become Straddl’s defacto community manager and handles the Straddl discord, answers Straddl support tickets, and seems to be perpetually online ready to help or answer questions. His time committed to the project is hard to quantify because it borders on countless. In contrast to GR and My Defi, who are active relayers in the Across Protocol ecosystem and receive modest compensation through those efforts, Infinity has not received any compensation or incentives to help build Straddl and get it to where it is currently.\n\nI believe there’s no set standard for how funding payouts are distributed. When comparing to other proposals such as “Risk Labs Retroactive Funding and Future Development” and “Across UMA Voting Committee (AUVC) Formation Proposal” such payouts were not tied to specific milestones. All that being said, I believe we’ve committed to providing quarterly updates on our progress, be transparent about any distributions to the team, and would be willing to do stage presentations to keep the community engaged.\n\nI hope this helps, please let me know if you have any additional questions and/or feedback!\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Risk Labs Retroactive Funding and Future Development\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 5\n\n Sep 2024\n\n Across Token Launch Proposal v2\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 47\n\n Nov 2022\n\n Risk Labs Funding Proposal for Growth, Expansion and Across v3\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 11\n\n Oct 2023\n\n Across Token Launch Proposal\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 214\n\n May 2022\n\n Across ($ACX) Community Initial Liquidity Proposal\n\n Passed Proposals\n\n Passed Proposals\n\n 49\n\n Nov 2022","tokens":6150,"squid":"spider-09","role":"Bridge Spider","at":1791341292048,"hash":"208abfd4f25c5b89c73f0d1f1fd6faa1c6a4d21d"}
{"url":"https://docs.phantom.com/developer-powertools/solana-priority-fees","domain":"docs.phantom.com","title":"Solana priority fees - Phantom developer documentation","text":"Phantom automatically calculates and applies Priority fees to all Phantom-generated transactions and dapp-generated transactions that meet our requirements.\n​How transaction fees work on Solana\nSolana transaction fees are calculated based on two main parts:\n\nA statically set base fee per signature, and\nThe computational resources used during the transaction, measured in Compute Units (CU)\n\nSince each transaction requires different computational resources, they are allotted a maximum number of compute units, known as the Compute Budget. After the Compute Budget is exhausted, the runtime halts the transaction and returns an error, resulting in a failed transaction.\nThe maximum budget for a transaction is 1.4 million CU, while the total blockspace limit is 48 million CU. Only a few computationally heavy TXs, like a mint or a swap, could fill the entire block, halting other TXs—hence the need for Priority Fees.\nThe fee priority of a transaction T can be defined as F(T), where F(T) is the “fee-per compute-unit”, calculated by:\n(additional_fee+base_fee) / requested_compute_units(additional\\_fee + base\\_fee)\\ /\\ requested\\_compute\\_units\nThis means that the more compute units a transaction requests, the more additional fee it will have to pay to maintain the priority in the transaction queue. This prevents computationally heavy transactions from being easily spammed or from filling blocks.\n​Priority fee calculation\nPriority fees are calculated as,\npriority_fees = compute_budget ∗ compute_unit_pricepriority\\_fees\\ =\\ compute\\_budget\\ *\\ compute\\_unit\\_price\nwhere,\ncompute_budget = # of instructions ∗ compute_unit_limitcompute\\_budget\\ =\\ \\#\\ of\\ instructions\\ *\\ compute\\_unit\\_limit\n​How Phantom applies priority fees to app transactions\nAlthough dapps can set their own priority fees on transactions they generate, we highly discourage doing so as it often surfaces unnecessary complexity to end-users. Instead, we recommend that dapp developers let Phantom apply priority fees on the user’s behalf.\nPhantom will calculate and apply Priority Fees to all dapp-generated transactions, provided:\n\nThe transaction(s) do not already have signature(s) present.\nThe transaction(s) do not have existing priority fee instructions (computeUnitBudget or computeUnitLimit).\nAfter enhancing transaction(s) with Priority Fees, the size of each transaction will still be less than the byte size limit (1232 bytes).\n\nIf all of the above conditions are met, Phantom will automatically calculate and apply priority fees at the time of signing. This pattern applies to all Phantom provider methods (signAndSendTransaction, signTransaction, signAllTransactions) across all environments (extension, mobile in-app browser, deeplinks, mobile wallet adapter).\n​Further reading\n\nFee Transaction Priority - Solana Proposals\nHow to change compute budget fee priority for a transaction - Solana Cookbook\nPrioritization Fees - Solana Programming Model\nTransaction Fees - Prioritization Fee\nWas this page helpful?","tokens":751,"squid":"spider-10","role":"Tooling Spider","at":1791341299061,"hash":"735ffbfe85bdb0a7fd7df2c53f2fd48cee2e5793"}
{"url":"https://jup.ag/rewards","domain":"jup.ag","title":"Jupiter Rewards Hub: Earn Rewards on Solana","text":"Fresh Pack Drop: Watch GrailsEarn $250 in free watch packs for every $10K in volume.\n\nPool: $50,000 Free Packs (FCFS)Reward pool50KFree PacksView detailsSeason 1: Restocked ft BlazeRip packs. Pull real graded cards. Top collectors split the airdrop.Reward pool100KFree PacksView detailsEndedActive Staking Rewards (ASR) Apr - Jun 2026ASR incentivizes active JUP participation with increased voting power.Reward pool50MStaked JUPView detailsTrade Tessera. Collect the cards.Every $3,000 of eligible volume on $tSpaceX, $tKalshi or $tOpenAI earns a mystery card. Reveal it for up to $1,000 JupUSD - capped at 100 cards per wallet.Reward pool$25KJupUSDView detailsFresh Gacha Drop: New Packs As Low as $5$5 Sports. $10 Pokemon. $1000 Sports. All brand new packs, full of grails and ready to rip. $50,000 in rewards for these select packs. FCFS.Reward pool50KFree PacksView detailsDominion SilverTrade $SILV over 2 weeks for a share of $25,000 JupUSD. Each week has its own leaderboard, and every eligible trade also counts toward the Overall leaderboard.Reward pool$25KJupUSDView detailsWorld Cup Challenge 2026Build a 5-pick challenge from 72 World Cup markets on Jupiter Predict. Get all 5 right to win a share of the prize pool — $100,000 for paid entries, plus a $25,000 pool everyone can enter for free.Reward pool125KUSDCView detailsActive Staking Rewards (ASR) Jan - Mar 2026ASR incentivizes active JUP participation with increased voting power.Reward pool50MStaked JUPView detailsSpaceX: Trade the launch. Collect the cards.Every $6,000 of eligible $SPCX volume earns a mystery card. Reveal it for up to $1,000 JupUSD - and every $1 card is a ticket into the $10,000 raffle.Reward pool$50KJupUSDView detailsEuropean Final 2026Trade Arsenal & PSG Fan Tokens to climb the leaderboard and earn from $25,000 in rewardsReward pool$25KRewardsView details100% FREEROLL PREDICTION RAFFLEA $50,000 prize pool in partner tokens for first-time predictors on Jupiter Predict. Place a losing prediction of $500 or less and you could have your prediction amount refunded, winners are drawn at random. Details below.Reward pool50KFIGHTView detailsActive Staking Rewards (ASR) Oct - Dec 2025ASR incentivizes active JUP participation with increased voting power.Reward pool50MStaked JUPView detailsJupLend x xStocks CampaignDeposit xStocks on Jupiter Lend to Earn from $20,000 in RewardsReward pool$20KJupUSDView detailsFREE $200K Mystery RewardEligible users can import to Jupiter Mobile/Extension to check if they've received a mystery reward from our sponsors. First come, first served. Sponsored by 1win, SPIKE, BRENT, WAR, LOL, EITHER, MOLT, HODL, Boob, FIGHT, SURGE, MEW, DIME, and MCV.Reward pool$200KMulti-Token RewardView detailsPreStocks TCG Rewards - Bonus CampaignTrade & Refer PreStocks tokens to Earn from $25,000 in RewardsReward pool$25KJupUSDView details$10K $BELIEF Prediction Market ChallengeAnnouncing a $10,000 $BELIEF prize pool for traders on Jupiter prediction markets. Winners will be selected via a volume-weighted raffle the more $BELIEF you bet, the higher your odds of winning.\nReward pool562KBELIEFView detailsPreStocks TCG RewardsTrade PreStocks tokens & Refer to Earn from $50,000 in RewardsReward pool$50KJupUSDView detailsTCG Rewards Season 2Trade & Refer to Earn from $2,000,000 in RewardsReward pool$2MJupUSDView detailsDIME Trading RaffleTo celebrate the launch, we are announcing a $50,000 JUPUSD prize pool for traders on Jupiter, sponsored by Paradex.Reward pool50KJUPUSDView detailsTCG Rewards Season 1Trade & Refer to Earn from $1,000,000 in RewardsReward pool$1MUSDCView details","tokens":902,"squid":"spider-02","role":"Liquidity Spider","at":1791341302688,"hash":"78ec2ebd9d3075ac90aa39a4fa3c9cd525103fba"}
{"url":"https://docs.phantom.com/developer-powertools/solana-versioned-transactions","domain":"docs.phantom.com","title":"Solana Versioned Transactions - Phantom developer documentation","text":"Phantom supports Versioned Transactions and Legacy Transactions. Versioned Transactions and Address Lookup Tables (LUTs) were introduced by Solana in an effort to improve the developer and end-user experience. The proposed changes are as follows:\n\nIntroduce a program which manages on-chain address lookup tables\nAdd a new transaction format which can make use of the above on-chain address lookup tables\n\nWhy do we need the above?\nLegacy transactions have a major issue: Maximum allowed size of 1232 bytes, and hence the number of accounts that can fit in an atomic transaction: 35 addresses.\n\nThis is problematic as developers are limited with this threshold and are unable to include >35 signature-free account / program addresses in a single transaction. This is where Address LUTs come into the picture.\n​Address LUTs\nThe idea behind Address LUTs is to store account addresses in array-like data structures on-chain. Once accounts are stored in this table, the address of the table can be referenced in a transaction message using 1-byte u8 indices.\n\nThis opens up space as addresses need not be stored inside transaction messages, but only be referenced. This allows 2^8=256 accounts to be included in 1 tx, as accounts are referenced using u8 indices.\n​RPC changes\nTransaction responses will require a new version field: maxSupportedTransactionVersion to indicate to clients which transaction structure needs to be followed for deserialisation.\nThe following methods need to be updated to avoid errors:\n\ngetTransaction\ngetBlock\n\nThe following parameter needs to be added to the requests:\nmaxSupportedTransactionVersion: 0\nIf maxSupportedTransactionVersion is not explicitly added to the request, the transaction version will fallback to legacy. Any block that contains a versioned transaction will return with an error by the client in the case of a legacy transaction.\nYou can set this via JSON formatted requests to the RPC endpoint like below:\ncurl http://localhost:8899 -X POST -H \"Content-Type: application/json\" -d \\\n'{\"jsonrpc\": \"2.0\", \"id\":1, \"method\": \"getBlock\", \"params\": [430, {\n \"encoding\":\"json\",\n \"maxSupportedTransactionVersion\":0,\n \"transactionDetails\":\"full\",\n \"rewards\":false\n}]}'\n\nYou can also do the same using the @solana/web3.js library.\n// connect to the `devnet` cluster and get the current `slot`\nconst connection = new web3.Connection(web3.clusterApiUrl(\"devnet\"));\nconst slot = await connection.getSlot();\n\n// get the latest block (allowing for v0 transactions)\nconst block = await connection.getBlock(slot, {\n maxSupportedTransactionVersion: 0,\n});\n\n// get a specific transaction (allowing for v0 transactions)\nconst getTx = await connection.getTransaction(\n \"3jpoANiFeVGisWRY5UP648xRXs3iQasCHABPWRWnoEjeA93nc79WrnGgpgazjq4K9m8g2NJoyKoWBV1Kx5VmtwHQ\",\n {\n maxSupportedTransactionVersion: 0,\n },\n);\n\nFor details on how to build and send Versioned Transactions and LUTs, see Send a versioned transaction.\n​Further reading\n\nHow to create a versioned transaction - Solana Docs\nHow to create an address lookup table - Solana Docs\nVersioned Transactions - Anvit Hashnode\nWas this page helpful?","tokens":781,"squid":"spider-10","role":"Tooling Spider","at":1791341320897,"hash":"e08f5828fd635dfcc45d897541ec0293fb0f7d18"}
{"url":"https://jup.ag/rewards/dominion-silver","domain":"jup.ag","title":"Jupiter: The Home of Onchain Finance","text":"Timeline1Campaign startsAug 13, 2026, 02:00 PM2All rounds endAug 27, 2026, 02:00 PM3Claims openAug 31, 2026, 03:00 PMHow it worksEligibilityTop 50 wallets by weighted volume across $SILV, judged fresh each round.What countsQualifying volume across $SILV on Jupiter, including Limit orders & DCA, Ultra, Metis. DistributionPaid pro rata on your share of the top 50 volume. Rank qualifies you, share sizes it.LeaderboardRankTraderWeighted volWeighted volumeMultiplierPrize72Tp…va1T$2.17M1.01x$1,631.768Yhq…TvSF$1.67M2.2x$1,254.09BBdD…4F94$1.65M2.85x$1,241.044hrsf…7mta$1.61M2.99x$1,208.3555c2a…WWm6$1.27M2.01x$953.956BKLe…SrPx$1.16M2.09x$872.2372uAe…LgyT$936K2.78x$702.768ZFVr…Tj8g$555K2.78x$417.149BGtz…dQ51$406K2x$305.1210HwLW…NDoD$360K2x$270.2211AYX6…SnNr$266K2x$200.30127QtJ…SeyR$237K2x$177.9013ErNi…fJ3H$175K2x$131.45149K9Z…Mpzt$126K2.99x$95.0715HtXu…RPiT$61.9K2.56x$46.491698Ht…cNwM$55.9K3x$41.9917GeXh…QWg8$54.8K3x$41.1718FgGY…46WE$42.3K2x$31.76198seo…eWLd$39.9K2x$29.94205Lur…ATEo$35.2K3x$26.47215H3c…g7Fv$30.9K1x$23.1822ETGn…UAvz$29.2K2x$21.9123C9mw…VmTi$25.1K2x$18.8724GmRC…c2Pn$24.0K3x$18.0225H6qo…acRQ$23.9K2x$17.99266371…DPWh$23.4K2x$17.56275NEz…yj8B$20.8K2x$15.622882FQ…ZnKT$20.5K2x$15.38294RjM…Y13W$20.3K2x$15.24307DmH…n6ym$18.3K2x$13.7931DtZa…qXP8$14.0K2x$10.5032Gikq…vBhB$13.9K2x$10.4433ARyu…1dcd$13.0K2.94x$9.7634FEyR…Lw9C$12.1K3x$9.14357pct…osgW$12.1K2x$9.08366eZv…zsLR$10.9K2x$8.18374roP…aWje$10.7K2x$8.083823L6…qVuU$10.5K1.93x$7.92397u5M…SCxW$9.57K2.15x$7.1840MtXd…TRCN$9.06K2x$6.794184Xt…MZVp$8.99K2.05x$6.7442m5sJ…WLvo$8.88K2.37x$6.66437QtD…e3gZ$8.70K2x$6.5344EYUR…ALj8$8.69K2x$6.524514fg…Cb3d$7.33K2x$5.5046HZ93…K3No$6.77K2.83x$5.0847F39r…xV8V$6.67K1.47x$5.0048Ft1L…v88i$6.52K2x$4.8949EEoB…fNFa$6.01K2x$4.5150AQL4…L8J6$6.00K2x$4.50Prizes are proportional to your share of weighted volume among the top 50.Leaderboard updates every 10 minutes.FAQDominion is sponsoring a total prize pool of $25,000 JupUSD:\n\nRound 1: $10,000 JupUSD\nRound 2: $10,000 JupUSD\nOverall: $5,000 JupUSD\n\nEach reward pool is calculated and distributed independently. All rewards are sponsored by Dominion.Dominion Silver runs for 2 weeks across 2 consecutive 1-week rounds. Each round has its own leaderboard and $10,000 JupUSD reward pool, and rankings start fresh at the beginning of each round.\n\nRound 1: 13 August 2026 at 2:00 PM UTC to 20 August 2026 at 2:00 PM UTC\nRound 2: 20 August 2026 at 2:00 PM UTC to 27 August 2026 at 2:00 PM UTC\n\nThe Round 1 and Round 2 tabs show these scoring periods. Other campaigns may use different round durations.The Overall leaderboard tracks weighted volume across the full 2-week campaign. It does not reset between rounds and has a separate $5,000 JupUSD reward pool.\nA wallet can qualify for rewards from either round, the Overall leaderboard, or all 3 leaderboards.Points are exactly weighted USD volume: eligible Dominion Silver trading volume multiplied by the applicable route multiplier. Wallets are ranked by points, and the top 50 wallets on each leaderboard qualify for that leaderboard's reward pool.\nRewards are distributed pro rata. Rank determines whether a wallet qualifies, while its share of weighted volume determines its share of the reward pool. Amounts displayed while the campaign is running are estimates until scoring is finalized.Eligible volume executed through Metis receives a 1x multiplier. Eligible volume executed through Ultra receives a 2x multiplier. Eligible volume executed through Limit Order or DCA receives a 3x multiplier.\nMultipliers affect leaderboard points, not the amount traded or received in the underlying transaction.Eligible Dominion Silver trading volume executed through Jupiter Metis, Ultra, Limit Order, or DCA during the applicable round counts toward that round's leaderboard and the Overall leaderboard.\nTrades outside a leaderboard's displayed scoring period do not count toward that leaderboard.Use Jupiter Wallet Extension or Jupiter Mobile to claim during the claim window shown on the campaign page. Unclaimed rewards expire when the claim window closes.\nLeaderboard results and rewards may take time to finalize after the campaign ends.Promoter and reward sponsor\nDominion is the Promoter and reward sponsor for this Campaign.\nPromoter's discretion\nDominion may amend, suspend, void, or cancel the Campaign, in whole or in part, at any time, including where required by applicable law or where the integrity of the Campaign is compromised.\nFinality of decisions\nDominion's decisions on all matters relating to the Campaign, including qualifying volume, multiplier application, points, leaderboard rankings, reward calculations, and Participant eligibility, are final and binding.\nLeaderboard and reward calculations\nLeaderboard positions and estimated rewards shown during the Campaign are provisional and may be delayed, incomplete, or adjusted during final review. Final rewards are based on validated backend records after scoring is finalized. Displayed amounts may be rounded.\nEach round reward pool and the Overall reward pool are calculated independently. Qualification for one leaderboard does not guarantee qualification for another.\nPrize substitution and withholding\nDominion may substitute or withhold any reward, in whole or in part, where delivery is unduly difficult or impossible, where applicable law prevents receipt, where a Participant fails to provide required recipient information in time, where the Participant breaches these Terms, or where an impediment arises beyond Dominion's reasonable control.\nClaiming and expiry\nEligible Participants must use Jupiter Wallet Extension or Jupiter Mobile to claim during the claim window shown on the Campaign page. Rewards that are not claimed before the claim window closes expire and may no longer be available.\nLimitation of liability\nDominion is not liable for entries, trades, scoring, or claims affected by technical faults, including issues involving Jupiter trading products, blockchain networks, smart contracts, wallet providers, indexers, or third-party services. Dominion is not liable for inaccuracies or delays in provisional leaderboard displays, or for any loss, cost, or damage incurred by a Participant in connection with the Campaign. Nothing in these Terms excludes liability that cannot be excluded under applicable law.\nForce majeure\nDominion is not liable for any delay or failure to perform caused by circumstances beyond its reasonable control, including acts of God, governmental action, regulatory change, network outages, smart contract exploits, or third-party service disruptions.\nParticipant acknowledgements\nParticipants acknowledge that participation involves trading crypto-assets, that leaderboard positions and estimated rewards may change until results are finalized, that participation is not financial advice, and that they are responsible for their own tax and legal compliance. Participants enter the Campaign at their own risk.","tokens":1734,"squid":"spider-02","role":"Liquidity Spider","at":1791341324499,"hash":"27b3fdd58885ca1f041c315a53cf1f32e4a68d4f"}
{"url":"https://forum.across.to/t/straddl-io-expansion-proposal/2037/12","domain":"forum.across.to","title":"Straddl.io Expansion Proposal - Proposals / Active Proposals - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n ProposalsActive Proposals\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 Feb 2025\n\n 12 / 12\n\n Mar 2025\n\n Mar 2025\n\n post by mydefi on Feb 26, 2025\n\n mydefi\n\n Author(s): My Defi, GR (Cat Herder), Infinity\nStatus: Proposal\nSubmission Date: TBD\nSummary:\nStraddl (https://straddl.io) is a next-generation bridging platform built entirely on Across Protocol, designed to offer users highly competitive bridging rates while leveraging the Across Intents Framework (ERC-7683) for an efficient bridge + swap experience. To enhance its utility and further leverage the power of intent-based transactions, Straddl proposes expanding its capabilities to provide deeper DeFi integrations.\nStraddl currently allows users to perform some of the following actions:\n\nBridge ETH/WETH, USDC/USDC.e, USDT, WBTC and DAI on all routes supported by Across Protocol at discounted rates\nBridge + swap to a wide variety of tokens on Optimism, Arbitrum, Polygon, zkSync Era, and Base\nBridge + send gas for users who are bridging to a chain in which they do not yet have the necessary token for performing transactions (such as Polygon)\nRelay deposits sitting on the open market and available for anyone to fill\n\nThis expansion will introduce features that allow users to:\n\nBridge + swap on Uniswap on Unichain, improving efficiency for users looking to move liquidity cross-chain,\nBridge + swap on all other chains with high-liquidity DEXes (including Mainnet)\nBridge + send gas on additional chains where ETH is not the native token (i.e. Aleph Zero)\nBridge + deposit into Aave to streamline access to lending opportunities,\nBridge + repay/pay down debt on Aave, enabling more seamless debt management,\nand much more!\n\nBy integrating these features as well as several other UI improvements, Straddl aims to enhance the user experience, unlock new DeFi possibilities, and solidify its position as a premier intent-based bridging solution.\nThis benefits Across as a direct source of exclusive bridge volume in contrast with other system integrators that also service competing protocols.\nAdditionally, this proposal includes a request for funding to support development efforts, compensate contributors, and bootstrap user engagement campaigns on Intract and other similar platforms.\nMotivation:\nAcross Protocol’s Intents Framework presents a unique opportunity to redefine bridging by incorporating advanced DeFi interactions. Currently, users must execute multiple transactions manually to bridge assets and interact with protocols like Aave or Uniswap, resulting in higher gas costs, longer transaction times, and added complexity.\nStraddl’s expansion aims to address these inefficiencies by enabling users to bridge assets while simultaneously executing DeFi actions in a single, optimized transaction. This not only improves UX but also expands the utility of Across Protocol by demonstrating the power of ERC-7683-based intent execution in real-world DeFi applications.\nAlthough Across has gained a significant share of volume through system integrators, a fully featured app that supports a broad set of intent-based actions offers direct benefits. This includes handling more complex orders, such as cross-chain swaps, and capturing volume not supported by the standard Across front-end application. Additionally, another bridge interface improves service availability in case services managed by Risk Labs are impacted.\nStraddl.io has been a fully grassroots project from the start, built and maintained without any outside capital. Despite this, contributors have dedicated significant time and effort to making Straddl a leading intent-based bridging platform. One of our core contributors, Infinity, has put in extensive development work—which can only be described as relentless commitment—without receiving any compensation to date. This proposal seeks to fund the next phase of Straddl’s growth while also retroactively compensating Infinity for his invaluable contributions.\nAdditionally, Straddl is 100% aligned with Across Protocol—it does not integrate or rely on any other bridges. The project is solely focused on leveraging Across to create a seamless, intent-driven DeFi experience, reinforcing its role as a key builder in the Across ecosystem. Furthermore, all of Straddl’s contributors—GR, Infinity, and My Defi—are active community members who regularly provide development support within the Across Protocol Discord.\nNotably, in 2023 and 2024, Across Protocol ran a “Community Integrations Bounty” program designed to encourage projects like Straddl. However, this initiative did not gain much traction, and the allocated token rewards were ultimately returned to the DAO. Given that Across had already set aside funds for community-driven integrations, we believe this signals that the community may be open to reallocating some of these unused funds to support Straddl’s continued development.\nTo ensure successful execution and adoption of these new features, this proposal also requests funding for engagement campaigns on platforms like Intract. These campaigns will drive awareness, increase usage, and reward early adopters who contribute to the platform’s growth.\nCurrent growth\nTo date, Straddl has grown through two primary avenues: organic adoption and targeted campaigns on the Intract platform. Despite operating without external funding, Straddl has achieved significant traction, demonstrating strong user interest and engagement. As of February 2025, Straddl has recorded:\n\n72,800+ Straddl “questers” on the Intract platform\n3,400+ deposits and relays completed on Straddl.io in February alone\n3,400+ members in the Straddl Discord community\n3,200+ followers on Straddl’s Twitter/X account (created in September 2024)\n100+ users who fully completed all tasks in Straddl’s Intract campaigns\n$2,000 in USDC rewards distributed to Intract campaign winners (as of February 28, 2025)\n\nThese early results highlight Straddl’s ability to attract and engage users, even with minimal resources.\n1600×793 163 KB\nSpecification & Implementation:\nThis proposal seeks funding to support Straddl’s next phase of development, focusing on:\n\nFeature Upgrades – Expanding Straddl’s capabilities by integrating additional DeFi interactions using Across Protocol’s Intents Framework (ERC-7683). These enhancements will enable users to combine bridging with actions like depositing into lending protocols, repaying loans, or swapping assets in a single, optimized transaction.\nUI/UX Enhancements – Improving the front-end experience to make cross-chain interactions more intuitive, reduce friction, and increase adoption. This includes refining the user interface, streamlining transaction flows, and optimizing gas efficiency.\nContributor Compensation – Ensuring that core contributors, including Infinity, are compensated for their past and ongoing work, enabling continued development and support.\nUser Engagement & Growth – Allocating funds to run targeted campaigns on platforms like Intract, rewarding early adopters, and driving user adoption through strategic engagement initiatives.\nBackend & Infrastructure Improvements – Optimizing transaction batching and execution logic to ensure cost-efficiency, security, and seamless integration with Across Protocol.\n\nBy implementing these upgrades, Straddl will reinforce its role as a key builder within the Across Protocol ecosystem while demonstrating the power of intent-based bridging.\nStraddl Team Members and Responsibilities\nGR is a long-standing member of the Across community and one of the earliest Across Protocol relayers. He has made significant contributions to the Across DAO and Across Protocol, including two discord bots, a bountied demo app for Across+, the formation of the Community Essentials Committee and many hours of support for relayers, users and developers in the community. GR has a fintech background with extensive knowledge in several domains including payments, security and risk management.\nMy DeFi is an active Across community member, Across Protocol relayer, is currently on the Across UMA Voting Committee, and has previously served the Across DAO as a Community Essentials Committee member. My DeFi is also a software developer and co-contributor of Straddl (straddl.io) which leverages the power of Across+ to provide advanced bridging capabilities for users and other DeFi apps.\nInfinity is an experienced Computer Engineer with a decade of experience, and for several years, linked to Web3 development as a Front End Dev. He has skills that allow him to solve different tasks with great quality. He joined Across Protocol and since then he was an important member of the community, making himself stand out. He was given the role of Events Master and also the role of Moderator. He was later selected for the Dev Support role because he had the skills to perform it adequately, performing all these roles at the same time efficiently. Also, at the proposal of the members of the CEC and the support of the community, he was promoted to occupy a place in the CEC. Its superpower lies in practically being available 24 hours a day and supporting everything necessary in the fastest and most efficient way possible. Now he was also promoted to the Community Moderator role. Focused on maintaining a pleasant and harmonious environment at all times.\nRevenue Distribution/Compensation\nStraddl is requesting 100,000 ACX tokens (~$27,000 at the current ACX price) for this funding and future development. The funds will be allocated as follows:\n\n12,500 ACX (~$3,400 at the current ACX price) to be allocated for Intract campaign rewards (Intract rewards are provided as USDC)\n12,500 ACX (~$3,400 at the current ACX price) to be distributed to Infinity for his contributions to date\n75,000 ACX (~$20,200 at the current ACX price) to be allocated to the Straddl team (GR, Infinity, and My Defi) over the course of the next 12 months to complete all of the updates outlined in this proposal and cover the cost of associated expenses. These costs include:\n\nTwo prior Intract campaigns\nAccount servicing costs including (Discord, Email, Twitter etc)\nInfrastructure and hosting fees\nGas faucet funds and contract deployments\n\nRationale\nThis proposal requests funding to support both development efforts and ecosystem growth. The requested amount is based on:\n\nDevelopment & Compensation – Supporting ongoing technical upgrades while fairly compensating contributors, including retroactive compensation for Infinity, who has worked extensively without pay.\nUser Engagement & Adoption – Providing incentives for early adopters and contributors through Intract and other engagement platforms, ensuring a strong initial user base.\nSustainability – Enabling Straddl to continue iterating and improving, reinforcing its alignment with Across Protocol whilst showcasing the power and innovation possible with ERC-7683 intent execution.\nResilience – An alternative bridge service enhances the availability of the Across Protocol, ensuring that the primary service managed by Risk Labs is not a single point of failure.\nReallocation of Unused DAO Funds – Across Protocol previously allocated rewards for its Community Integrations Bounty, which were returned due to low participation. Given this precedent, we believe there is an opportunity to reallocate a portion of these unused funds to support Straddl’s expansion.\n\nThis funding will ensure that Straddl not only continues to operate but also grows into a cornerstone of the Across Protocol ecosystem.\nTo ensure transparency, the Straddl team will share quarterly progress updates in the Across Protocol Discord.\n\n 3\n\n 2\n\n read \n\n 6\n min\n\n post by Bananachain on Feb 27, 2025\n\n Bananachain\n\n Have tested Straddl.io and it works very smoothly and reliably. The good thing here is we have a MVP to use and test, not only an idea. So the team has shown it can deliver. Great to see community members committed to buidling a project on Across protocol, finally! \n\n post by PVMihalache on Feb 27, 2025\n\n PVMihalache\n\n This is not just an integration… is much more! Straddl shows to the world that building on top of Across is a step forward.\nStraddl may be the dApp that sparks the next generation of applications building with Across, giving a hand on Unifying Ethereum!\n\n post by neondaemon on Feb 27, 2025\n\n neondaemon\n\n I’ve read the proposal in detail and I believe what they are asking for is modest considering how much added value they are bringing to the Across ecosystem. Have projects like Straddl building on top of Across and adding functionality like cross-swaps is making DeFi more convenient. There have a great track record of delivering and confident they will deliver on their ambitious plans. Lastly Straddl has become my goto bridge and the guys are continually improving it!\n\n post by berry4144 on Feb 27, 2025\n\n berry4144\n\n It appears very good value for twelve months worth of future work (plus prior work getting setup).\nDo we have any $ volume numbers that straddl has put through Across? And do you have an aspiration of where you want to take it?\n\n post by mydefi on Feb 27, 2025\n\n mydefi\n\n Hi @berry4144, we were late to start tracking data so we don’t have anything prior to the beginning of the most recent Intract campaign which started Feb 1, but here’s what we have over the last 28 days. Keep in mind this also includes about 3-4 days in which we had to pause Straddl due to significant contract upgrades to Across Protocol in mid-February:\nMonth of February 2025:\nTotal volume: $262,767.41\nETH/WETH:\n3511 deposits\n84.85175 ETH total volume ($217,075.78)\n0.02416 ETH ($61.83) average bridge size\nUSDC/USDT:\n1097 deposits\n$45,691.63 total volume\n$41.65 avg bridge size\nUser actions:\n206 Unique wallet addresses in Feb 2025\n1159 bridge + action (bridge + swap, bridge + refuel) actions in Feb 2025\n\n post by christinadotcom on Feb 28, 2025\n\n christinadotcom\n\n i started using Straddl by curiosity and ended up bookmarking the link and using it every time i need to bridge or swap crypto. amazing job from GR, Infinity and MyDefy\n\n post by Bananachain on Feb 28, 2025\n\n Bananachain\n\n I have some points I would like to share and am interested in your thoughts:\nThe current funding request draft requests ACX with an indicative USD value only. This appears not be in line with the Across Governance Operating Manual, see Proposal Types, Treasury Funding-Medium which requires USD value funding requests. That may affect any ACX payout depending on exchange rate.\nThe request seeks retroactive funding (Infinity) as well as “future” funding.\n\nIt may be helpful to provide some more details on Infinities contributions for those readers who have not followed his activities. I personally have no doubt it is well deserved!\n\nRegarding “future” funding it appears to be a payout upfront. Aren’t payouts usually milestone based? And if yes, what would those be in relation to funding amounts and how would they be monitored and evaluated? I did see the bullet points regarding expenses and a reference made to the things that you are planning of completing.\n\n post by spaceyfoo on Mar 1, 2025\n\n spaceyfoo\n\n I have bridged multiple times using Straddl and its actually good and CONVENIENT. I find myself using it frequently now. I would suggest to also plan for a little bit of marketing because I believe Straddl has much more to offer for newcomers to turn them into frequent users.\n\n post by easten03 on Mar 1, 2025\n\n easten03\n\n I am using straddl bridge since last 5 months it is reliable there is proper liquidty an almost all chains no any bugs found earlier there was failed transcition issue but team fixed it properly\n\n post by denvercolt on Mar 1, 2025\n\n denvercolt\n\n I’ve read the proposal and support it. Straddl is a good platform with many useful features that I’ve myself come to use quite often. This proposal will definitely help the expansion and new integrations for Straddl as well as Across.\n\n post by mydefi on Mar 3, 2025\n\n mydefi\n\n Bananachain\n\n Thanks so much for this feedback!\nRegarding the ACX / USD value, in efforts to be fully transparent we’re providing both USD and ACX values in the proposal, but ultimately the final request will be denominated in ACX as that is what oSnap needs to execute the distribution on a successful proposal. I also believe our funding request falls into the “Treasury Funding - Small” category as the amount requested is well under $50k USD.\nResponding to your other points:\n\nInfinity’s contributions can generally be siloed into two main, critical areas: front-end development and UI, and community management/growth. In the area of front-end development, Infinity has essentially become the lead developer of the website front-end, pushing forward on adding new features and UI fixes and improvements. On the community end, he’s become Straddl’s defacto community manager and handles the Straddl discord, answers Straddl support tickets, and seems to be perpetually online ready to help or answer questions. His time committed to the project is hard to quantify because it borders on countless. In contrast to GR and My Defi, who are active relayers in the Across Protocol ecosystem and receive modest compensation through those efforts, Infinity has not received any compensation or incentives to help build Straddl and get it to where it is currently.\n\nI believe there’s no set standard for how funding payouts are distributed. When comparing to other proposals such as “Risk Labs Retroactive Funding and Future Development” and “Across UMA Voting Committee (AUVC) Formation Proposal” such payouts were not tied to specific milestones. All that being said, I believe we’ve committed to providing quarterly updates on our progress, be transparent about any distributions to the team, and would be willing to do stage presentations to keep the community engaged.\n\nI hope this helps, please let me know if you have any additional questions and/or feedback!\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Risk Labs Retroactive Funding and Future Development\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 5\n\n Sep 2024\n\n Across Token Launch Proposal v2\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 47\n\n Nov 2022\n\n Risk Labs Funding Proposal for Growth, Expansion and Across v3\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 11\n\n Oct 2023\n\n Across Token Launch Proposal\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 214\n\n May 2022\n\n Across ($ACX) Community Initial Liquidity Proposal\n\n Passed Proposals\n\n Passed Proposals\n\n 49\n\n Nov 2022","tokens":6142,"squid":"spider-09","role":"Bridge Spider","at":1791341324595,"hash":"5e540adcb8bcdb4c5a2352468a5e88e1f8f52b81"}
{"url":"https://forum.across.to/t/community-owned-liquidity-nft-project-funding-request/1555","domain":"forum.across.to","title":"“Community Owned Liquidity” NFT Project Funding Request - Proposals / Active Proposals - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n “Community Owned Liquidity” NFT Project Funding Request \n\n ProposalsActive Proposals\n\n treasury-funding\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Mar 2023\n\n 1 / 37\n\n Mar 2023\n\n Jun 2023\n\n post by TheRealTuna_Across on Mar 7, 2023\n\n TheRealTuna_Across\n\n Title: “Community Owned Liquidity” NFT project funding request\nAuthor: The Real Tuna\nContributors: Britt, Daywiss, EASports, TheRealTuna, Underthesea\nStatus: RFC\nRelated Discussions: N/A\nSubmission Date: 03/07/2023\nSummary\nOur team will manage the design, distribution, and treasury associated with our unique avatar style NFT collection that will act as a governing share over an ACX-ETH LP position. This Liquidity will be locked in long term and NFT owners will take on the risk and reward of that LP position for years to come. NFT holders can benefit from LP growth, private discord channel access, weekly draws, and ownership of a fun collectible that proves commitment and loyalty to Across. If a holder wishes to exit they would do so by selling their NFT on the open market.\n\nUnique NFT collection of 2000 avatar style characters\nETH proceeds locked in to an ACX/ETH UNI LP, some ACX from treasury and some converted using the ETH.\nProceeds from LP fees split 65/25/10 between funds rolled back into LP(65%), weekly raffle(25%), and future development including paying multisig managers(10%).\nNFT holders have access to a private discord channel\nNFT receive a larger value than their purchase price by having ACX treasury provide some ACX tokens\nTreasury controlled by a multisig for flexibility needed to manage an LP\n\nMotivation\nThis project has been inspired by protocols such as Pooltogether, CityClash, EVMavericks and more. It aims to help solve the issue of having deep token liquidity without some of the disadvantages that come along with other methods(liquidity mining, protocol owned liquidity, etc). It is a sustainable solution to long term liquidity, once the NFT’s are minted, that liquidity will remain locked in long term. By owning an NFT you own a share in the community owned LP and can benefit from its long term growth. These unique NFT’s have an avatar style personalized aspect that the community can rally behind and prove their support of Across while collecting. NFT holders also don’t have to deal with the hassle of managing an LP as those management efforts will be taken care of for them by the community managers of the multisig. If ACX and ETH rise together then so does the value behind each NFT, perhaps one day this sub community of Across will manage millions of dollars in ACX/ETH liquidity due to market growth and fee revenue(DYOR, Not Financial Advice). This NFT mint is a public good that enriches the Across community as a whole by committing the tokens received from mint straight towards long term community managed liquidity.\nSpecification & Implementation\nThis project will have a 3 stage process. Stage 1 is the design stage, where we’ll settle on several of the visual and logistical pieces of the project. This includes NFT design, mint website design, raffle mechanism, marketing plan, and LP fund management plan. Stage 2 is the launch stage, where contracts go live and NFT sales begin. It also includes deploying LP funds according to the fund management plan. Stage 3 is the management stage, which will involve maintaining the LP positions and executing raffles according to the raffle schedule. Our goal is to reach the launch stage 3 months from being funded.\nDesign Stage\nNFT Design\n\nArtist: We have a design artist chosen for the NFT’s but for now we would like to keep that a surprise. Will provide teasers during the process leading up to launch.\nTechnical: @daywiss and @underthesea are currently assisting with the technical design and we will hire a web designer and contract out the work for any needs that arise.\n2,000 NFT’s with 100-150 traits and varying rarity.\n\nWebpage design\n\nWebpage will allow users to mint and view their NFT’s may possibly also include raffle information if it falls within the budget(alternatively raffle info will be maintained on discord)\nWhitelist eligibility checker leading up to launch.\n\nPlan to deploy Liquidity\n\nFinancial managers:Multisig members with input from community members who can provide insights and advice.\nACX/ETH LP parameters to be determined by the team leading up to launch stage. Initial thoughts are to either do a nice wide UNI V3 range and adjust as necessary or to setup in 3 tiers(one for rise, one for fall, and one for current range).\n\nIf the community accepts this proposal then the requested funding will be sent to our multisig address. From the multisig we will pay our contributors which include those designing the website, designing the NFT’s, developing the mint contract, and managing the project.\nWe have already secured an NFT designer and developers to help but will also need to higher a web designer and possibly contract more tech help in the lead up to launch. The NFT collection is meant to be 2,000 unique avatar style characters that will be minted by sending ETH ($250 USD value) through the webpage to the project multisig.\nLaunch Stage\n\nHype Plan\n\nPre-launch collaboration opportunities, Across official marketing, publish article on community owned liquidity, Twitter space or AMA\n\nNFT mint opens up with whitelist followed by public mint.\nDeploying LP Funds\n\nThe multisig wallet will manage the LP with the mandate of providing long term and deep liquidity for ACX while also acting in the best interest of NFT holders. Owning an NFT represents a share in the treasury that is being used to provide Across liquidity.\n\nPrior to launch we will market the NFT sale on twitter and other necessary social platforms to generate hype. Minters should be aware that the underlying value behind each NFT will start out at $325/each which is more than the mint cost ($500,000 raised from mint + $150,000 provided from Across treasury). Since the treasury will be illiquid to NFT minters this will act as an incentive for locking in long term to support the growth of Across. This adds up to a 30% value boost right up front. NFT’s will be minted by whitelisted wallets for the first 24 hours and then open to the public. Whitelisted wallets could Include ACX holders, staked ACX holders and ACX liquidity providers. We could also discuss including UMA holders and potentially other communities we are aligned with.\nUpon launch the multisig managers would convert funds from mints to the LP in batches, this would also be paired with $150,000 in ACX tokens to be requested from ACX treasury, this will ensure the initial value backing each NFT will be higher than the mint cost and acts as a way to reward purchasers for locking in long term. Managers will transfer the batches at their own discretion and I’d imagine the transfer of funds will be dependent on the speed of the NFT’s minting out.\nManagement/Governance stage\n\nOngoing fund management\n\nReview LP position monthly and make adjustments every 1-3 months.\nEventual governance improvements if necessary. Potential switch from multisig to Optimistic governance down the road.\n\nRaffle details\n\nMechanism: TBD\nFrequency: Weekly draw\nResults announced on private discord channel\n\nOther Regular Perks\n\nAccess to NFT holder only discord.\n\nOnce the LP is in action the managers will conduct the weekly raffle and roll the fee share back into the LP. This could be an automated process but may require manual action in the beginning.\n\n65% of weekly LP fees to be rolled back into the NFT creating a perpetual growth cycle of the LP.\n25% of the LP fees will be awarded to a random winner of the weekly raffle. Details of how the raffle will be conducted are not yet sorted but can be worked out during the design stage.\nThe remaining 10% will be distributed to the LP managers for their ongoing management of the treasury. If this amount exceeds what is required then any excess can be returned to the LP or held in treasury.\nNFT royalties on platforms like Opensea will be split between the community treasury address(75%) and the NFT designer(25%). The treasury portion can be rolled into the LP or used to cover any future costs associated with the project.\n\nThe 4/7 multisig that manages the treasury would ultimately determine what strategy to use for the LP but would take feedback from the community. Liquidity would use UNI V3 but could also explore options like Arrakkis finance to manage LP funds. LP strategy can be looked at more in depth after the launch stage. Upon Launch the multisig will have the final say on implementing changes to treasury but our mandate will be to act in the best interest of both the Across community and NFT holders, both of whom will have contributed funds towards this project. A snapshot voting mechanism will be added to help gauge community sentiment. (1 NFT=1 vote in the snapshot).\nThe multisig will start out as a 3/5 during the design stage but will be upgraded to a 4/7 before launch.\n4/7 multisig would include the following signers:\n\nBritt\nDaywiss\nEAsports\nTheRealTuna\nUnderthesea\nTBD Community member(to be added prior to launch)\nTBD Community member(to be added prior to launch)\n\nProposed Budget\nPart 1: Build budget for contributors. This portion will be used for payment to website designers, contract creator, NFT designer, and other contributors. We have an NFT designer and several contributors to the webpage/UI + contracts but may also hire out as needed.\n$40,000 USD equivalent in ACX tokens(550,000 ACX)\nPart 2: Contribution from Across to the NFT community run LP. To be transferred from Across Treasury just before launch and used as an added incentive by adding to the liquidity.\n$150,000 USD equivalent in ACX tokens(2,000,000 ACX)\nRationale\nCurrent liquidity options such as liquidity mining can come with some disadvantages:\nLiquidity mining is not sustainable as it requires distributing tokens from treasury that can end up being dumped on the market and when the rewards end the participants exit the LP.\nHaving POL “Protocol Owned Liquidity” requires raising funds and if the only funds in the treasury are the protocol token you would have to dump tokens in order to fund the LP and on top of that the protocol token side of the LP is essentially selling tokens which will compound the downside.\nCOL “Community Owned Liquidity” via NFT sale is funded by the community and ensures the funds will be locked in long term. Incentives from Across treasury are deposited directly to the LP which further guarantees there will be no dumping of ACX rewards. Having trading fees split between going back to the LP and being raffled to holders both ensures the LP continues to grow and the NFT holders have an added fun way to win some of the LP fees.\nUniswap V3 is the dex of choice for liquidity at this time as it is the most secure and trusted exchange in the DEFI ecosystem. The choice could be made in future to deposit to another platform but we feel it is best to start in a safe and trusted place that already secures Billions of dollars in funds.\nRisk\nLPing comes with risk and there are no guarantees that the LP will rise in value. There is also risk that the NFT collection does not sell out immediately and that could lead to ongoing additional management and delays in reaching full liquidity. There is also no guarantees of getting fair market value for the NFT’s if trying to exit.\n\n Do you support this proposal moving forward\n\n 26\n voters\n\n Votes are public.\n\n Would you be likely to mint the NFT to support Across Liquidity?\n\n 25\n voters\n\n Votes are public.\n\n Is the proposed budget reasonable to build a web UI, NFT contracts, NFT design, etc?\n\n 26\n voters\n\n Votes are public.\n\n ACX Market Making Proposal - Arrakis PALM\n\n 12\n\n 3\n\n 3\n\n 3\n\n 2\n\n read \n\n 15\n min\n\n post by PVMihalache on Mar 7, 2023\n\n PVMihalache\n\n Lovely idea! Will read it in details in the morning but everything looks spot on while I skimmed through the text.\nYou have my full support.\n\n post by hash_error on Mar 7, 2023\n\n hash_error\n\n Fantastic experiment to lock liquidity long term and give participants an opportunity for growth.\nOnly concern is for nft minters/hodlrs is the potential event there is no market for the nfts and folks are permalocked in an illiquid position.\nOther than that, big fan! Let’s go!\n\n post by Justin_J on Mar 7, 2023\n\n Justin_J\n\n This is a pretty interesting concept I’ll need to reread this one a few times initial thoughts are it sounds really cool.\n\n post by TheRealTuna_Across on Mar 7, 2023\n\n TheRealTuna_Across\n\n hash_error\n\n Good question,\nIt is very possible there could be difficulty finding a buyer but I personally would see that as an opportunity to snag some more NFT’s below the underlying value. Mint cost is $250 but the underlying value behind each NFT will be $325 at mint when you consider the added $150,000 incentive from Across treasury. As an NFT minter you would have to know that you are taking on some risks but those risks will only strengthen the Across community by ensuring deep liquidity. For me I will hold some of these NFT’s and if I see a chance to buy one at a discount I will jump on it.\n\n post by jonto on Mar 8, 2023\n\n jonto\n\n Hey Tuna,\nIs there any way to redeem the NFTs for the undelrying LP? If not how do you consider it underlying value? A that point its really just a lottery ticket for the fee distribution.\nLove the overall concept and I have been working on a very similar thing but with gamified redemption to support the value of the NFTs. Will be cool to see different models hit the market.\n\n post by TheRealTuna_Across on Mar 8, 2023\n\n TheRealTuna_Across\n\n Hey Jonto,\nGood to see you here! As currently intended there would be no mechanism to redeem the NFT for the underlying value. Ideally anybody who wants to unlock the underlying value would have to try their luck via selling the NFT in an NFT marketplace. Joining this sub community of Across is sort of like forming a liquidity pod to support the community as a whole. With that said, I see potential for profit taking further down the road as long as we maintain deep liquidity for ACX. Given that the LP is paired in both ETH and ACX I see potential for exponential growth of the LP. This new approach has the potential to produce the most stable token liquidity around as there will be no dumping of rewards. This NFT can be collectible, profitable, and a proof of commitment to the Across community.\n\n post by poopster on Mar 8, 2023\n\n poopster\n\n absolutely brilliant. you really put a lot of thought into this proposal and it shows, you have my sword ser… \n\n post by Sack on Mar 8, 2023\n\n Sack\n\n Without the ability to redeem the NFT for LP or equivalent, its tough to consider it underlying value no? I think the rest of the idea is great but I would love to see more discussion around this\n\n post by caesarsherrod.eth on Mar 8, 2023\n\n caesarsherrod.eth\n\n I definitely like this idea. I have only one input. Is it possible, for once, that a huge project like this isn’t on mainnet? This is a bridge, and the use of multiple chains is important for us to grow in the future. Wouldn’t it be neat if people had to travel to mint the NFT? I wonder what bridge they’d use to mint the Across NFT?\nA wonderful counter to this idea is that the Liquidity Providers are on Mainnet. The only counter that I have is that the LP’s wouldn’t earn their yields without the growing layer two ecosystem, but I am sure that is not sufficient.\nIf there is any challenge to this idea, please look at the GMX Blueberries. They are doing pretty well on Arbitrum. As a person who is, in my opinion, new to defi I enjoy evading the fees of mainnet.\n\n post by gmsteele on Mar 8, 2023\n\n gmsteele\n\n Excellent! Really like the idea, and if moves forward count on my participation!\nHow can I not have typed 100 characters yet? \n\n post by TheRealTuna_Across on Mar 8, 2023\n\n TheRealTuna_Across\n\n caesarsherrod.eth\n\n Having the NFT’s on Arbitrum is definitely something to consider, the liquidity definitely needs to be on Ethereum but the NFT’s don’t have to.\n\n post by Kevin_UMA on Mar 8, 2023\n\n Kevin_UMA\n\n The idea of community owned liquidity sounds great and it’s clear tuna put a lot of thought into this proposal. There are some things I would like clarity on and also discuss. Also, I think in order for the Across DAO / ACX holders to approve sending $190k of tokens they would need to know the funds are serving the purpose of liquidity, secure (which questions the multisig) and managed well (the LP strategy needs to be well defined and sound).\n\nIt’s mentioned by others the need for redemption and i would agree. To ensure there is some risk free value to this NFT I think that’s necessary or else we risk the value dropping and holders losing interest. I think combining this with oSnap would allow this to happen, but there needs to be implementation details to consider.\nIf there is redemption, NFT holders need to commit to holding this for an extended period of time (1 year?) so that they can’t just mint and redeem and take the bonus ACX from the DAO. This I believe can be defined by oSnap as well.\nThere is concern that if you have oSnap that somebody could buy up more than half the NFTs and then vote to send the entire wallet to themselves. This is very expensive to do as it’s a “shoot the moon” strategy and if unsuccessful they could be punished severely for paying the wrong price. In any case oSnap can again limit what transactions can be proposed. So maybe you can only call redemption which would be an all or nothing event that forces all holders to get their assets back and would require a high quorum. I’ll need UMA devs to confirm all this.\nI’m not a fan of the multisig. I know the signers and feel OK but I don’t think that’s the case for all ACX hokders. And we also have an alternative now.\nThe key to this whole proposal is how we implement and manage this liquidity. That’s why we are doing this. So we need better clarity on how this is managed and what strategies are used. A wide uni v3 strategy I think is not optimal and having a group manage this now and then is not ideal. I rather see a passive LP instead or using a known active management protocol to help in comparison. And I think the NFT holders can change this strategy in the future. So more thought needs to be put here.\n\nAll together I think there’s an idea here that is appealing but implementation details are important in order for this to be successful.\n\n post by Bananachain on Mar 9, 2023\n\n Bananachain\n\n Very interesting ideas in this proposal, and very much in line with the original proposal on gamification posted about a year ago when addressing the token launch -but with a lot more details thrushed out now. I may have missed it, but is selling the NFT the only way to release its value? Could it not also be a combination of locking and burning? Of course, one would then lose the NFT, but that would then be the price anyone willing to unlock would need to pay. This would not necessarily need to exclude being able to sell of the NFT. Also, what are the royalties that would be incured upon sale of the NFT on, lets say, Opensea? This would be preset in the underlying contract is my understanding.\n\n post by Everythingblockchain on Mar 9, 2023\n\n Everythingblockchain\n\n Hey @TheRealTuna_Across\nLove the thought and the rationale. The key to improvement is experimenting and innovation. And this brings both to the table.\nI find @Kevin_UMA’s input valuable and integrating with 0Snap is a great suggestion.\n\n post by TheRealTuna_Across on Mar 9, 2023\n\n TheRealTuna_Across\n\nDefinitely open to using oSnap as long as we can tailor or to allow the flexibility needed to manage an LP, which sounds like it could work by giving permissions to a multisig to interact with Uniswap for swaps between ACX-ETH + adding/removing liquidity. This would protect against the multisig sending unauthorized funds to a 3rd party wallet.\nRedemption is a bit difficult to envision as it is important we maintain/grow the promised liquidity as well as preventing profit seekers from gaming the system to unlock the incentives early, that being said it is worth further discussing how we could incorporate something like this.\nI hope to include an LP strategy in our proposal before we table it for a final vote.\n\nAt this point selling the NFT is the only short term exit but there has been some debate around redemption ideas and those ideas can still be considered. The primary goal of this initiative are bringing deep liquidity to Across without selling off ACX tokens for the non ACX side of this pair.\nAs it stands the Opensea royalties are to be split between the NFT designer and the community treasury with 75% going to the community treasury and 25% to the designer.\n\n post by Justin_J on Mar 9, 2023\n\n Justin_J\n\n TheRealTuna_Across\n\n If minted on layer 2 wouldn’t that force more liquidity to said l2, I’m not against it but it seems counter productive to have to move liquidity from l2 back to mainet after mint most acx liquidity is on l1\n\n post by TheRealTuna_Across on Mar 9, 2023\n\n TheRealTuna_Across\n\n Plan is still currently to have everything happen on L1 but I’m not totally opposed to the idea of NFT being elsewhere if that’s what the majority wanted. Since we are a bridge I don’t think we should fear bridging funds, that being said we want to make sure the NFT is accessible to everyone and it is safe to say that everyone uses Ethereum.\n\n post by mhairi on Mar 9, 2023\n\n mhairi\n\n I’m going to abstain on this proposal for now. I love the idea of build ACX liquidity using NFTs, but I think it needs a few tweaks as others have suggested.\nIn particular\n\nI’d like to see something that showcased L2s, given that Across is a bridge. Creating the NFTs on an L2 would offer Across a good opportunity to develop its relationship with one (or more?) of the chains that we bridge to.\n\nAllowing redemption for underlying liquidity is important for sustainability and keeping the NFT tokens value anchored.\n\nThis could be combined with some kind of “vesting” - such as it cant be redeemed until x time after minting/transfer in order to protect against people either immediately liquidating to take advantage of the ACX treasury “bonus”, or a sweep at a time of price volatility, where people can purchase the NFT at less than “face value” then immediately liquidate; drying up ACX liquidity when it is most needed.\n\nI’m a big cheerleader for oSnap. I think this is the way that protocol decisions should be executed, without needing individuals to take on personal risk or responsibility, and ensuring that parameter changes are fully decentralised. Its very easy to set up, like Across itself, its secured by UMA’s Oracle and built by UMA engineers and this seems a perfect fit.\n\nI understand the concern that someone could buy up 1/2 the NFTs to send a malicious proposal, (although it would be difficult in practice) but if that were to happen oSnap would stop the transaction if it was disputed (regardless of outcome) and there are other potential guardrails that can also be implemented.\n\nLPing to UniV3 tends to result in impermanent loss. I’m not really an expert on dexes but I wonder if we could delegate the liquidity management to bots and manage the bot parameters through oSnap, hmm actually on a further read thats using flashloans, like I said no expert, but UniV3 feels risky.\n\n post by Britt on Mar 9, 2023\n\n Britt\n\n@Kevin_UMA this resonates a lot with me. Maybe you could help suggest a couple of options that you might consider more ideal?\nI think that the redemption details are going to be the most technically difficult part to sort out in this implementation. So I’d like to call on anyone reading this to make recommendations of protocols who might do something like this that we could work with.\n\n Load more posts below","tokens":7470,"squid":"spider-09","role":"Bridge Spider","at":1791341339312,"hash":"051a00355784f420d340a80a54985856a8bcbc74"}
{"url":"https://docs.phantom.com/developer-powertools/testnet-mode","domain":"docs.phantom.com","title":"Testnet mode - Phantom developer documentation","text":"Testnet mode allows you to connect to blockchain test networks for development and testing purposes. When enabled, Phantom will display testnet balances and allow transactions on supported test networks.\n​Enable testnet mode\nTo access test networks in Phantom, go to Settings → Developer Settings → Testnet Mode.\n\n​Supported test networks\nWhen Testnet Mode is enabled, you can connect to supported test networks, including:\nBlockchainTest networksSolanaDevnet, TestnetEthereumSepoliaBaseBase SepoliaPolygonPolygon AmoyRobinhood ChainRobinhood Chain TestnetArcArc Testnet\n​Get test tokens\nTo test transactions, you’ll need testnet tokens:\n\nSolana Devnet SOL: Use the Solana Faucet\nSepolia ETH: Use the Sepolia Faucet\nBase Sepolia ETH: Use the Base Faucet\n\n​Testing with Phantom Connect\nWhen using Phantom Connect SDKs, testnet mode works automatically. Users with testnet mode enabled in their Phantom wallet will see testnet balances and can sign testnet transactions.\nFor local development, you can also use localhost or 127.0.0.1 to test your integration before deploying to a production URL.Was this page helpful?","tokens":279,"squid":"spider-10","role":"Tooling Spider","at":1791341343307,"hash":"e5a8d0fa3cd5f6f92d24dd2b3881c2b6688f1187"}
{"url":"https://eips.ethereum.org/EIPS/eip-627","domain":"eips.ethereum.org","title":"EIP-627: Whisper Specification","text":"🎉 Final\n\n Standards Track: Networking\n\n EIP-627: Whisper Specification\n\n Authors\n Vlad Gluhovsky <gluk256@gmail.com>\n\n Created\n 2017-05-05\n\n Abstract\n\nThis EIP describes the format of Whisper messages within the ÐΞVp2p Wire Protocol.\nThis EIP should substitute the existing specification.\nMore detailed documentation on Whisper could be found here.\n\n Motivation\n\nIt is necessary to specify the standard for Whisper messages in order to ensure forward compatibility of different Whisper clients.\n\n Specification\n\nAll Whisper messages sent as ÐΞVp2p Wire Protocol packets should be RLP-encoded arrays of data containing two objects: integer packet code followed by another object (whose type depends on the packet code).\n\nIf Whisper node does not support a particular packet code, it should just ignore the packet without generating any error.\n\n Packet Codes\n\nThe message codes reserved for Whisper protocol: 0 - 127.\nMessages with unknown codes must be ignored, for forward compatibility of future versions.\n\nThe Whisper sub-protocol should support the following packet codes:\n\n EIP\n Name\n Int Value\n\n Status\n 0\n\n Messages\n 1\n\n PoW Requirement\n 2\n\n Bloom Filter\n 3\n\nThe following message codes are optional, but they are reserved for specific purpose.\n\n EIP\n Name\n Int Value\n\n P2P Request\n 126\n\n P2P Message\n 127\n\n Packet Format and Usage\n\nStatus [0]\n\nThis packet contains two objects: integer message code (0x00) followed by a list of values: integer version, float PoW requirement, and bloom filter, in this order. The bloom filter parameter is optional; if it is missing or nil, the node is considered to be full node (i.e. accepts all messages). The format of PoW and bloom filter please see below (message codes 2 and 3).\n\nStatus message should be sent after the initial handshake and prior to any other messages.\n\nMessages [1, whisper_envelopes]\n\nThis packet contains two objects: integer message code (0x01) followed by a list (possibly empty) of Whisper Envelopes.\n\nThis packet is used for sending the standard Whisper envelopes.\n\nPoW Requirement [2, PoW]\n\nThis packet contains two objects: integer message code (0x02) followed by a single floating point value of PoW. This value is the IEEE 754 binary representation of 64-bit floating point number. Values of qNAN, sNAN, INF and -INF are not allowed. Negative values are also not allowed.\n\nThis packet is used by Whisper nodes for dynamic adjustment of their individual PoW requirements. Recipient of this message should no longer deliver the sender messages with PoW lower than specified in this message.\n\nPoW is defined as average number of iterations, required to find the current BestBit (the number of leading zero bits in the hash), divided by message size and TTL:\n\nPoW = (2**BestBit) / (size * TTL)\n\nPoW calculation:\n\nfn short_rlp(envelope) = rlp of envelope, excluding env_nonce field.\nfn pow_hash(envelope, env_nonce) = sha3(short_rlp(envelope) ++ env_nonce)\nfn pow(pow_hash, size, ttl) = 2**leading_zeros(pow_hash) / (size * ttl)\n\nwhere size is the size of the full RLP-encoded envelope.\n\nBloom Filter [3, bytes]\n\nThis packet contains two objects: integer message code (0x03) followed by a byte array of arbitrary size.\n\nThis packet is used by Whisper nodes for sharing their interest in messages with specific topics.\n\nThe Bloom filter is used to identify a number of topics to a peer without compromising (too much) privacy over precisely what topics are of interest. Precise control over the information content (and thus efficiency of the filter) may be maintained through the addition of bits.\n\nBlooms are formed by the bitwise OR operation on a number of bloomed topics. The bloom function takes the topic and projects them onto a 512-bit slice. At most, three bits are marked for each bloomed topic.\n\nThe projection function is defined as a mapping from a 4-byte slice S to a 512-bit slice D; for ease of explanation, S will dereference to bytes, whereas D will dereference to bits.\n\nLET D[*] = 0\nFOREACH i IN { 0, 1, 2 } DO\nLET n = S[i]\nIF S[3] & (2 ** i) THEN n += 256\nD[n] = 1\nEND FOR\n\nOPTIONAL\n\nP2P Request [126, whisper_envelope]\n\nThis packet contains two objects: integer message code (0x7E) followed by a single Whisper Envelope.\n\nThis packet is used for sending Dapp-level peer-to-peer requests, e.g. Whisper Mail Client requesting old messages from the Whisper Mail Server.\n\nP2P Message [127, whisper_envelope]\n\nThis packet contains two objects: integer message code (0x7F) followed by a single Whisper Envelope.\n\nThis packet is used for sending the peer-to-peer messages, which are not supposed to be forwarded any further. E.g. it might be used by the Whisper Mail Server for delivery of old (expired) messages, which is otherwise not allowed.\n\n Whisper Envelope\n\nEnvelopes are RLP-encoded structures of the following format:\n\n[ Expiry, TTL, Topic, Data, Nonce ]\n\nExpiry: 4 bytes (UNIX time in seconds).\n\nTTL: 4 bytes (time-to-live in seconds).\n\nTopic: 4 bytes of arbitrary data.\n\nData: byte array of arbitrary size (contains encrypted message).\n\nNonce: 8 bytes of arbitrary data (used for PoW calculation).\n\n Contents of Data Field of the Message (Optional)\n\nThis section outlines the optional description of Data Field to set up an example. Later it may be moved to a separate EIP.\n\nIt is only relevant if you want to decrypt the incoming message, but if you only want to send a message, any other format would be perfectly valid and must be forwarded to the peers.\n\nData field contains encrypted message of the Envelope. In case of symmetric encryption, it also contains appended Salt (a.k.a. AES Nonce, 12 bytes). Plaintext (unencrypted) payload consists of the following concatenated fields: flags, auxiliary field, payload, padding and signature (in this sequence).\n\nflags: 1 byte; first two bits contain the size of auxiliary field, third bit indicates whether the signature is present.\n\nauxiliary field: up to 4 bytes; contains the size of payload.\n\npayload: byte array of arbitrary size (may be zero).\n\npadding: byte array of arbitrary size (may be zero).\n\nsignature: 65 bytes, if present.\n\nsalt: 12 bytes, if present (in case of symmetric encryption).\n\nThose unable to decrypt the message data are also unable to access the signature. The signature, if provided, is the ECDSA signature of the Keccak-256 hash of the unencrypted data using the secret key of the originator identity. The signature is serialised as the concatenation of the R, S and V parameters of the SECP-256k1 ECDSA signature, in that order. R and S are both big-endian encoded, fixed-width 256-bit unsigned. V is an 8-bit big-endian encoded, non-normalised and should be either 27 or 28.\n\nThe padding field was introduced in order to align the message size, since message size alone might reveal important metainformation. Padding can be arbitrary size. However, it is recommended that the size of Data Field (excluding the Salt) before encryption (i.e. plain text) should be factor of 256 bytes.\n\n Payload Encryption\n\nAsymmetric encryption uses the standard Elliptic Curve Integrated Encryption Scheme with SECP-256k1 public key.\n\nSymmetric encryption uses AES GCM algorithm with random 96-bit nonce.\n\n Rationale\n\nPacket codes 0x00 and 0x01 are already used in all Whisper versions.\n\nPacket code 0x02 will be necessary for the future development of Whisper. It will provide possibility to adjust the PoW requirement in real time. It is better to allow the network to govern itself, rather than hardcode any specific value for minimal PoW requirement.\n\nPacket code 0x03 will be necessary for scalability of the network. In case of too much traffic, the nodes will be able to request and receive only the messages they are interested in.\n\nPacket codes 0x7E and 0x7F may be used to implement Whisper Mail Server and Client. Without P2P messages it would be impossible to deliver the old messages, since they will be recognized as expired, and the peer will be disconnected for violating the Whisper protocol. They might be useful for other purposes when it is not possible to spend time on PoW, e.g. if a stock exchange will want to provide live feed about the latest trades.\n\n Backwards Compatibility\n\nThis EIP is compatible with Whisper version 6. Any client which does not implement certain packet codes should gracefully ignore the packets with those codes. This will ensure the forward compatibility.\n\n Implementation\n\nThe golang implementation of Whisper (v.6) already uses packet codes 0x00 - 0x03. Parity’s implementation of v.6 will also use codes 0x00 - 0x03. Codes 0x7E and 0x7F are reserved, but still unused and left for custom implementation of Whisper Mail Server.\n\n Copyright\n\nCopyright and related rights waived via CC0.\n\n Citation\n Please cite this document as:\n\n Vlad Gluhovsky <gluk256@gmail.com>, \"EIP-627: Whisper Specification,\" Ethereum Improvement Proposals, no. 627, May 2017. Available: https://eips.ethereum.org/EIPS/eip-627.","tokens":2230,"squid":"spider-05","role":"Spec Spider","at":1791341374189,"hash":"a6d7fa5c600b1f560d62706a4ba60a08489c93ec"}
{"url":"https://docs.arbitrum.foundation/how-tos/apply-become-delegate","domain":"docs.arbitrum.foundation","title":"How to become a delegate | Arbitrum DAO - Governance docs","text":"✏️Request an updatePUBLIC PREVIEW DOCUMENTThis document is currently in public preview and may change significantly as feedback is captured from readers like you. Click the Request an update button at the top of this document or join the Arbitrum Discord to share your feedback.Background​ArbitrumDAO's launch was announced in March of 2023 and the $ARB airdrop took place fron 3/23/23 to 9/24/23. $ARB token-holders are able to delegate the voting power of their tokens to delegates of the ArbitrumDAO1.To become a delegate, create a profile by following the steps in the on-chain governance UI and begin building your delegate platform. You can find these by navigating to the “Delegates” tab and selecting “Create Delegate Profile”. To make it easy for voters to learn more about you, submit a delegate statement using the template on the ArbitrumDAO governance forum.Become a delegate: Best practices​Before deciding to become a delegate, it's important to understand the responsibilities and expectations of the role. Review the following guidelines to ensure that you're prepared to become a delegate for the ArbitrumDAO:Delegates are expected to actively participate in the decision-making process and to act in the best interests of the network.Review The Constitution of the ArbitrumDAO and each of the documents within this content set to ensure that you understand the scope of delegate responsibilities and the mechanisms by which the ArbitrumDAO operates.Review the comprehension check to self-assess your understanding of the ArbitrumDAO governance protocol.Prepare to build a strong delegate platform. This includes establishing an online presence that outlines your qualifications, experience, and vision for the ArbitrumDAO. You can use your platform to demonstrate your understanding of the protocol and the highest-priority challenges that the community is facing.Submit a delegate statement using the template posted in the delegate application template thread. Although delegate applications aren't required now that the airdrop has occurred, the application template gives community members a standardized way to learn more about your qualifications and platform.Becoming a delegate is a significant responsibility and should not be taken lightly. Delegates should have a solid foundational technical understanding of the Arbitrum protocol, a sense of the Ethereum ecosystem at large, and a desire to continuously engage with the Arbitrum community as it grows and evolves. If you have any questions or concerns, visit the ArbitrumDAO governance forum.To learn how to delegate the voting power of your $ARB tokens, visit \"How to delegate your voting power\".↩BackgroundBecome a delegate: Best practices","tokens":681,"squid":"spider-07","role":"Council Spider","at":1791341379975,"hash":"a1b0edb3d47da385e6312ed6e59c2912c44f2830"}
{"url":"https://eips.ethereum.org/EIPS/eip-658","domain":"eips.ethereum.org","title":"EIP-658: Embedding transaction status code in receipts","text":"🎉 Final\n\n Standards Track: Core\n\n EIP-658: Embedding transaction status code in receipts\n\n Authors\n Nick Johnson <nick@ethereum.org>\n\n Created\n 2017-06-30\n\n Requires\n\n EIP-140\n\n Abstract\n\nThis EIP replaces the intermediate state root field of the receipt with a status code indicating if the top-level call succeeded or failed.\n\n Motivation\n\nWith the introduction of the REVERT opcode in EIP140, it is no longer possible for users to assume that a transaction failed iff it consumed all gas. As a result, there is no clear mechanism for callers to determine whether a transaction succeeded and the state changes contained in it were applied.\n\nFull nodes can provide RPCs to get a transaction return status and value by replaying the transaction, but fast nodes can only do this for nodes after their pivot point, and light nodes cannot do this at all, making a non-consensus solution impractical.\n\nInstead, we propose to replace the intermediate state root, already obsoleted by EIP98, with the return status (1 for success, 0 for failure). This both allows callers to determine success status, and remedies the previous omission of return data from the receipt.\n\n Specification\n\nFor blocks where block.number >= BYZANTIUM_FORK_BLKNUM, the intermediate state root is replaced by a status code, 0 indicating failure (due to any operation that can cause the transaction or top-level call to revert) and 1 indicating success.\n\n Rationale\n\nThis constitutes a minimal possible change that permits fetching the success/failure state of transactions, preserving existing capabilities with minimum disruption or additional work for Metropolis.\n\n Copyright\n\nCopyright and related rights waived via CC0.\n\n Citation\n Please cite this document as:\n\n Nick Johnson <nick@ethereum.org>, \"EIP-658: Embedding transaction status code in receipts,\" Ethereum Improvement Proposals, no. 658, June 2017. Available: https://eips.ethereum.org/EIPS/eip-658.","tokens":483,"squid":"spider-05","role":"Spec Spider","at":1791341387091,"hash":"79961346026ce2b292fd97a245bb863ca3d431ae"}
{"url":"https://docs.arbitrum.foundation/why-governance","domain":"docs.arbitrum.foundation","title":"Why decentralize Arbitrum governance with $ARB? | Arbitrum DAO - Governance docs","text":"✏️Request an updatePUBLIC PREVIEW DOCUMENTThis document is currently in public preview and may change significantly as feedback is captured from readers like you. Click the Request an update button at the top of this document or join the Arbitrum Discord to share your feedback.$ARB is the governance token for the Arbitrum ecosystem. This document aims to explain the rationale behind introducing the $ARB governance token, and how it plays a necessary role in the progressive decentralization of the Arbitrum protocol.Protocol upgrades and \"chain ownership\"​Arbitrum chains like Arbitrum One have a concept of a \"chain owner.\" A chain owner isn't strictly part of the Arbitrum protocol, but is rather essentially an administrator of the chain, responsible for managing how changes are made to the system. More specifically, a chain's owner can modify core system parameters and governor contracts, pause incoming transactions, and - most importantly - update any of the contracts that define and enforce the core protocol.It's necessary to have some way to upgrade an Arbitrum chain's core contracts for several reasons. First, planned improvements need to be made to the system. Arbitrum has already gone through several such upgrades (most notably, its evolution to Arbitrum Nitro from the \"Arbitrum Classic\" tech stack), and there will likely be more that no one can anticipate as technological progress continues. Additionally, if a critical bug in the Arbitrum codebase is discovered, upgrades may be necessary to fix it. Finally, changes will be necessary to remain compatible with Ethereum as Ethereum undergoes its own hard-fork improvements.The ability to arbitrarily change how an Arbitrum chain works obviously makes the chain ownership role quite powerful, and thus it can't be taken lightly when considering the decentralization of the Arbitrum technical stack.The necessity of L2 on-chain governance​Given the potential vector for centralization that chain ownership introduces, it's worth asking whether Arbitrum can simply do away with ownership entirely and handle protocol upgrades some other way. Ethereum itself, for example, has no explicit notion of a \"chain owner\", and yet has gone through numerous upgrades over its ~7 year life span, both to improve the system (new features, better performance, etc.) and to fix critical bugs.Here though, there's a crucial difference between Ethereum and Arbitrum: Ethereum is a Layer 1 (L1) protocol, and L1 protocols (and in turn, changes to L1 protocols) are ultimately defined by social consensus. When the community wants to upgrade Ethereum, those running the Ethereum node software install the software upgrade, and if the community at large agrees that the new change represents the \"real Ethereum,\" then it implicitly, inherently, is so. Everyone chooses for themselves whether to adopt the change, and the choice that has critical mass becomes canonical.Layer 2 (L2) protocols like Arbitrum One, however, are fundamentally different in that their rules are ultimately *not* governed implicitly by social consensus, but rather explicitly by L1 smart contracts. For Arbitrum One to upgrade, it isn't enough to simply upgrade the Arbitrum node software; its contracts must upgrade as well, which are controlled not by the social consensus of the Arbitrum community, but by Ethereum itself.The upshot is that the consensus to upgrade Ethereum can be an informal and off-chain process, whereas the consensus to upgrade Arbitrum must operate through a formal decision making process governed by on-chain contracts. In other words, governance.There's a possible future scenario that would enable Arbitrum chains to upgrade without any explicit ownership: the Ethereum community may someday deem it acceptable to modify L1 consensus in order to upgrade Arbitrum One. That is, Ethereum's social consensus could allow hard forking of the L1 for the sake of particular L2s. L2 chains under this hypothetical arrangement have been deemed \"enshrined rollups\".While it's possible that Ethereum's L2s eventually become enshrined in this way, this likely isn't happening any time in the near future. Such a change to the Ethereum/L2 ecosystem would have to eventuate from wider discussion and debate within the Ethereum community; a decision like this is largely outside of the control of the Arbitrum community. In the meantime, the community needs a solution that can be implemented today.So given that there's a need for a path towards protocol upgrades, and that enshrined rollups are (at least currently) off the table, the only viable option remaining, then, is explicit on-chain governance.Enter $ARB governance token for decentralized governance​The introduction of the $ARB governance token provides the ability to propose and carry out protocol upgrades in a decentralized manner.Tokens were initially airdropped via transparent criteria meant to be as fair as possible1. The goal was to spread out ownership to a large set of parties with stake in the Arbitrum ecosystem who are geographically distributed and have diverse backgrounds and affiliations. The chain ownership role is given to this “ArbitrumDAO”, a shorthand for the collective of all holders of the ARB token (and those delegated voting rights by token holders). There are two paths through which a protocol upgrade can take place. The first is a decentralized upgrade path that allows the DAO (and only the DAO) to carry out every step in the process: proposing an upgrade, publicly debating it, voting on it, and ultimately activating it.Several important properties are preserved in a decentralized upgrade process, all of which are enforced at the smart contract level:No permissioned parties are required at any step; the DAO itself can carry out the entire process.The DAO is given time to view a proposal before voting on it and, if it gets to that stage, given sufficient time to vote on it.Once a proposal passes, Arbitrum users are given time to withdraw assets from the system, should they disagree with the direction and prefer to opt out.Security Council​The second protocol upgrade path is similar to the first path, except that it allows the Security Council, a permissioned group of publicly named entities, to skip certain steps in specific situations. Notably, the Security Council has the ability to upgrade the protocol directly and without delays in case of emergency.This is a critically necessary role to protect against emergencies like the discovery of exploitable vulnerabilities, in which case the typical slow governance path is not viable for two reasons:If there's a critical vulnerability that can be exploited, it's counterproductive to broadcast it on the public governance forum before it has been mitigated.The fix to such a vulnerability should go into effect immediately and not have the several weeks' delay of typical governance changes.The Security Council is bound by The Constitution of the ArbitrumDAO to only use its powers when necessary for these sorts of emergencies, and to issue a transparency report when appropriate whenever its powers are used. To keep the Security Council in check, the DAO votes in annual elections (split by cohorts) for the Security Council's members.The Security Council can also trigger non-emergency upgrades, such as routine software upgrades and maintenance. These upgrades don't require a DAO vote to pass; they instead go through a delay period before taking effect, giving users time to opt out by withdrawing (as with decentralized DAO upgrades).To learn more about the Security Council, refer to the Security Council concept doc. For a formal articulation of the Security Council's role within ArbitrumDAO's governance process, refer to The Constitution of the ArbitrumDAO.The future of Arbitrum governance​The initial governance launch provides the community with the tools it needs: a means of decentralized governance, along with a faster, permissioned upgrade path to ensure the system remains safe in case of emergencies. As for how this system will change moving forward, many open questions remain:Can the governance process be further decentralized?How and when can the Security Council's power be further minimized, or eliminated entirely?These don't have easy answers and will continue to be the topic of lively discussion within the community as the Arbitrum technology continues to mature, and as the perceived risk profiles of various states of decentralization change along with it. But crucially, the Arbitrum governance system controls all aspects of the Arbitrum protocol, including the governance process itself.With the DAO in control, decisions about how Arbitrum should evolve over time — including the governance process itself — are in the hands of the Arbitrum community.Refer to $ARB airdrop eligibility and distribution specifications to learn more about the airdrop specifications. Refer to Arbitrum Sybil Hunting for an overview of our Sybil mitigation methodology.↩Protocol upgrades and \"chain ownership\"The necessity of L2 on-chain governanceEnter $ARB governance token for decentralized governanceSecurity CouncilThe future of Arbitrum governance","tokens":2298,"squid":"spider-07","role":"Council Spider","at":1791341389748,"hash":"f7b0c2c552ab3360c80991221db7e75e5ca37c6a"}
{"url":"https://eips.ethereum.org/EIPS/eip-681","domain":"eips.ethereum.org","title":"ERC-681: URL Format for Transaction Requests","text":"🎉 Final\n\n Standards Track: ERC\n\n ERC-681: URL Format for Transaction Requests\n\n Authors\n Daniel A. Nagy (@nagydani)\n\n Created\n 2017-08-01\n\n Requires\n\n EIP-20, \n\n EIP-137\n\n Simple Summary\n\nA standard way of representing various transactions, especially payment requests in ether and ERC-20 tokens as URLs.\n\n Abstract\n\nURLs embedded in QR-codes, hyperlinks in web-pages, emails or chat messages provide for robust cross-application signaling between very loosely coupled applications. A standardized URL format for payment requests allows for instant invocation of the user’s preferred wallet application (even if it is a webapp or a swarm đapp), with the correct parameterization of the payment transaction only to be confirmed by the (authenticated) user.\n\n Motivation\n\nThe convenience of representing payment requests by standard URLs has been a major factor in the wide adoption of Bitcoin. Bringing a similarly convenient mechanism to Ethereum would speed up its acceptance as a payment platform among end-users. In particular, URLs embedded in broadcast Intents are the preferred way of launching applications on the Android operating system and work across practically all applications. Desktop web browsers have a standardized way of defining protocol handlers for URLs with specific protocol specifications. Other desktop applications typically launch the web browser upon encountering a URL. Thus, payment request URLs could be delivered through a very broad, ever growing selection of channels.\n\nThis specification supersedes the defunct ERC-67, which is a URL format for representing arbitrary transactions in a low-level fashion. This ERC focuses specifically on the important special case of payment requests, while allowing for other, ABI-specified transactions.\n\n Specification\n\n Syntax\n\nPayment request URLs contain “ethereum” in their schema (protocol) part and are constructed as follows:\n\nrequest = schema_prefix target_address [ \"@\" chain_id ] [ \"/\" function_name ] [ \"?\" parameters ]\nschema_prefix = \"ethereum\" \":\" [ \"pay-\" ]\ntarget_address = ethereum_address\nchain_id = 1*DIGIT\nfunction_name = STRING\nethereum_address = ( \"0x\" 40*HEXDIG ) / ENS_NAME\nparameters = parameter *( \"&\" parameter )\nparameter = key \"=\" value\nkey = \"value\" / \"gas\" / \"gasLimit\" / \"gasPrice\" / TYPE\nvalue = number / ethereum_address / STRING\nnumber = [ \"-\" / \"+\" ] *DIGIT [ \".\" 1*DIGIT ] [ ( \"e\" / \"E\" ) [ 1*DIGIT ] ]\n\nWhere TYPE is a standard ABI type name, as defined in Ethereum Contract ABI specification. STRING is a URL-encoded unicode string of arbitrary length, where delimiters and the\npercentage symbol (%) are mandatorily hex-encoded with a % prefix.\n\nNote that a number can be expressed in scientific notation, with a multiplier of a power of 10. Only integer numbers are allowed, so the exponent MUST be greater or equal to the number of decimals after the point.\n\nIf key in the parameter list is value, gasLimit, gasPrice or gas then value MUST be a number. Otherwise, it must correspond to the TYPE string used as key.\n\nFor the syntax of ENS_NAME, please consult ERC-137 defining Ethereum Name Service.\n\n Semantics\n\ntarget_address is mandatory and denotes either the beneficiary of native token payment (see below) or the contract address with which the user is asked to interact.\n\nchain_id is optional and contains the decimal chain ID, such that transactions on various test- and private networks can be requested. If no chain_id is present, the client’s current network setting remains effective.\n\nIf function_name is missing, then the URL is requesting payment in the native token of the blockchain, which is ether in our case. The amount is specified in value parameter, in the atomic unit (i.e. wei). The use of scientific notation is strongly encouraged. For example, requesting 2.014 ETH to address 0xfb6916095ca1df60bb79Ce92ce3ea74c37c5d359 would look as follows:\nethereum:0xfb6916095ca1df60bb79Ce92ce3ea74c37c5d359?value=2.014e18\n\nRequesting payments in ERC-20 tokens involves a request to call the transfer function of the token contract with an address and a uint256 typed parameter, containing the beneficiary address and the amount in atomic units, respectively. For example,\nrequesting a Unicorn to address 0x8e23ee67d1332ad560396262c48ffbb01f93d052 looks as follows:\nethereum:0x89205a3a3b2a69de6dbf7f01ed13b2108b2c43e7/transfer?address=0x8e23ee67d1332ad560396262c48ffbb01f93d052&uint256=1\n\nIf using ENS names instead of hexadecimal addresses, the resolution is up to the payer, at any time between receiving the URL and sending the transaction. Hexadecimal addresses always take precedence over ENS names, i. e. even if there exists a matching ENS name consisting of 0x followed by 40 hexadecimal digits, it should never be resolved. Instead, the hexadecimal address should be used directly.\n\nNote that the indicated amount is only a suggestion (as are all the supplied arguments) which the user is free to change. With no indicated amount, the user should be prompted to enter the amount to be paid.\n\nSimilarly gasLimit and gasPrice are suggested user-editable values for gas limit and gas price, respectively, for the requested transaction. It is acceptable to abbreviate gasLimit as gas, the two are treated synonymously.\n\n Rationale\n\nThe proposed format is chosen to resemble bitcoin: URLs as closely as possible, as both users and application programmers are already familiar with that format. In particular, this motivated the omission of the unit, which is often used in Ethereum ecosystem. Handling different orders of magnitude is facilitated by the exponent so that amount values can be expressed in their nominal units, just like in the case of bitcoin:. The use of scientific notation is strongly encouraged when expressing monetary value in ether or ERC-20 tokens. For better human readability, the exponent should be the decimal value of the nominal unit: 18 for ether or the value returned by decimals() of the token contract for ERC-20 tokens. Additional parameters may be added, if popular use cases requiring them emerge in practice.\n\nThe 0x prefix before ethereum addresses specified as hexadecimal numbers is following established practice and also unambiguously distinguishes hexadecimal addresses from ENS names consisting of 40 alphanumeric characters.\n\nFuture upgrades that are partially or fully incompatible with this proposal must use a prefix other than pay- that is separated by a dash (-) character from whatever follows it.\n\n Backwards Compatibility\n\nIn the fairly common case of only indicating the recipient address in a request for payment in ether, this specification is compatible with the superseded ERC-67.\n\n Security Considerations\n\nSince irreversible transactions can be initiated with parameters from such URLs, the integrity and authenticity of these URLs are of great importance.\nIn particular, changing either the recipient address or the amount transferred can be a profitable attack. Users should only use URLs received from authenticated sources with adequate integrity protection.\n\nTo prevent malicious redirection of payments using ENS, hexadecimal interpretation of Ethereum addresses must have precedence over ENS lookups. Client software may alert the user if an ENS address is visually similar to a hexadecimal address or even outright reject such addresses as likely phishing attacks.\n\nIn order to make sure that the amount transacted is the same as the amount intended, the amount communicated to the human user should be easily verifiable by inspection, including the order of magnitude. In case of ERC-20 token payments, if the payer client has access to the blockchain or some other trusted source of information about the token contract, the interface should display the amount in the units specified in the token contract. Otherwise, it should be displayed as expressed in the URL, possibly alerting the user to the uncertainty of the nominal unit. To facilitate human inspection of the amount, the use of scientific notation with an exponent corresponding to the nominal unit of the transacted token (e.g. 18 in case of ether) is advisable.\n\n Copyright\n\nCopyright and related rights waived via CC0.\n\n Citation\n Please cite this document as:\n\n Daniel A. Nagy (@nagydani), \"ERC-681: URL Format for Transaction Requests,\" Ethereum Improvement Proposals, no. 681, August 2017. Available: https://eips.ethereum.org/EIPS/eip-681.","tokens":2103,"squid":"spider-05","role":"Spec Spider","at":1791341399343,"hash":"2eee535a44c82fe2c2c0005dd67fad23aa7c6118"}
{"url":"https://docs.arbitrum.foundation/how-tos/create-submit-dao-proposal","domain":"docs.arbitrum.foundation","title":"How to submit a DAO proposal | Arbitrum DAO - Governance docs","text":"✏️Request an updatePUBLIC PREVIEW DOCUMENTThis document is currently in public preview and may change significantly as feedback is captured from readers like you. Click the Request an update button at the top of this document or join the Arbitrum Discord to share your feedback.In this how-to, you'll learn how to submit an Arbitrum Improvement Proposal (AIP) to the ArbitrumDAO. Familiarity with Arbitrum, DAOs, and Ethereum is expected. Otherwise, this how-to makes no assumptions about your experience with governance protocols.Prerequisites​To submit a temperature check using the off-chain governance UI, you must have an Ethereum wallet address with 500,000 votable tokens1; To submit a proposal using the on-chain governance UI, you must have an Ethereum wallet address that represents at least 1,000,000 votable tokens. If you don't have enough voting power, consider delegating your votes to a delegate who can create a proposal on your behalf2.Proposal types​There are two types of AIPs: Constitutional and non-Constitutional:Constitutional AIPs are those that modify the text or procedures of the Constitution or AIP-1, install or modify software on any chain, or take any action that requires \"chain owner\" permission on any chain. Non-Constitutional AIPs are all other AIPs, such as those that request funds/grants or provide general guidelines or information to the community.See Constitution for further details.Proposal structure​The Constitution of the ArbitrumDAO encourages proposers to include the following sections within Arbitrum Improvement Proposals:Abstract - Two or three sentences that summarize the AIP.Motivation - A statement on why the Arbitrum community should implement the AIP.Rationale - An explanation of how the AIP aligns with the Arbitrum community's mission and guiding values.Key Terms - Definitions of any terms within the proposal that are unique to the proposal, new to the Arbitrum community, and/or industry-specific. This section is optional, but recommended.Specifications - A detailed breakdown of the platforms and technologies that will be used. This is where you can elaborate on the \"why\" of your design decisions. You can also use this section to describe alternate designs that were considered and related work, e.g. how similar specifications have been successfully (or unsuccessfully) implemented in other chains or languages.Steps to Implement - The steps to implement the AIP, including associated costs, manpower, and other resources for each step where applicable. AIPs that involve transactions with third parties (such as grants) will need to ensure that applicable legal documentation and procedures are also included.Timeline - Relevant timing details, including but not limited to start date, milestones, and completion dates.Overall Cost - The total cost to implement the AIP. The overall cost section should include a breakdown of the total cost of the AIP, including any associated costs for each step where applicable. Consider both fixed costs and recurring costs.Conflicts of Interest - The nature and extent of any direct or indirect conflict of interest that may exist for proposal authors regarding the proposal.Sometimes, AIPs aren't passed on the first try. If an AIP is not passed, the proposer may resubmit the AIP after addressing the concerns of the community. The proposer should include the following additional sections in the resubmitted AIP:A link to the previous AIP - The link to the previous AIP should be included in the resubmitted AIP.Reasons why the AIP was not passed - The reasons why the AIP was not passed should be included in the resubmitted AIP.Changes made to the AIP - The changes made to the AIP should be included to address the concerns raised during the previous AIP submission.Additional information - More detailed intentions, specifics and implication details can help the community understand the revised AIP, increasing the chances of it being passed.Pre-proposal development​Proposals that require code changes should include the code that will be executed when the proposal is passed. This code should handle the data structures, logic, executable data, and execution of the proposal. Refer to Governance Proposal Lifecycle: Example for an example.Step 1: Conduct a formal temperature check​The DAO governance forum facilitates discussions about ArbitrumDAO and governance proposals that are submitted by eligible token delegates. To submit your proposal:Go to the DAO governance forum.Create a new post with your proposal using the template located here. You can add additional fields to this template to provide more context for your proposal if you'd like.After at least 7 days, navigate to the off-chain governance UI to create a poll that will gauge the community's interest in your proposal.Connect your wallet.Create a poll that points to your forum post. The poll should run for one week and should be decided by a simple majority.Navigate back to your forum post and share the link to your poll with the community.Allow at least one week for discussion and debate. Iterate on your proposal based on feedback from the community.If your proposal passes the temperature check, then you can move to the second and final step: an on-chain vote facilitated by the on-chain governance UI. Ensure that you've incorporated feedback brought up during relevant forum discussions and temperature checks before proceeding.Step 2: Submit your on-chain proposal​If your wallet can represent at least 1,000,000 tokens, you can create an on-chain proposal using the on-chain governance UI. To submit your proposal:Log in to the on-chain governance UI using the wallet that represents the $ARB tokens.Navigate to the \"Proposals\" section.Select \"+ New Proposal”.Choose which governor you are targeting:Arbitrum Core: For Constitutional ProposalsArbitrum Treasury: For non-Constitutional ProposalsGive the proposal a name and description.Add proposal actions to be executed if passed. For example, \"transfer n ETH to 0x address\".Preview your proposal and submit on-chain.A proposal passes if two conditions are met: More votes are cast in favor than againstThe total number of votes cast in favor (including abstain votes) is at least the following percentage of the delegated tokens:50% (within the range of 150m to 450m $ARB), for a Constitutional AIP40% (within the range of 100m to 300m $ARB), for a non-Constitutional AIPIf the proposal passes, congratulations! After a delay, the proposal’s actions will be executed on-chain3.If the proposal doesn’t pass, but there's interest in improving and resubmitting it, refer to How to resubmit your proposal.If you have any questions or concerns, visit the ArbitrumDAO governance forum.Welcome to the future of governance!Important notes​The Security Council has the power to execute emergency actions and non-emergency actions, as delegated to it by the Constitution. These are unlike traditional AIPs in that they can be approved by the Security Council without going through the above process. See the Security Council page for more information.The threshold of support required for a proposal to pass can vary depending on the type of proposal and the quorum requirements specified in the Constitution.You can delegate your voting power2 to another address whether or not you have enough tokens to submit on-chain proposals. If you hold any $ARB tokens whatsoever, you can participate in ArbitrumDAO's governance.When we say \"an Ethereum wallet address with at least 500,000 votable tokens\", we mean that 500,000 or more tokens are delegated to this address. You can delegate the tokens to your own address and other $ARB token holders can delegate to you.↩Learn how to delegate your votes by visiting How to delegate your voting power.↩Refer to The Constitution of the ArbitrumDAO for additional details and conditions.↩PrerequisitesProposal typesProposal structurePre-proposal developmentStep 1: Conduct a formal temperature checkStep 2: Submit your on-chain proposal","tokens":2006,"squid":"spider-07","role":"Council Spider","at":1791341402007,"hash":"69c4d38f1c52613c772557da28e2b6e7f97a9796"}
{"url":"https://eips.ethereum.org/EIPS/eip-684","domain":"eips.ethereum.org","title":"EIP-684: Revert creation in case of collision","text":"🎉 Final\n\n Standards Track: Core\n\n EIP-684: Revert creation in case of collision\n\n Revert contract creation if address already has code\n\n Authors\n Vitalik Buterin (@vbuterin), Renan Rodrigues de Souza (@RenanSouza2)\n\n Created\n 2023-03-20\n\n Abstract\n\nThis EIP causes contract creation to throw an error when attempted at an address with pre-existing code. This prevents an attack consisting of deploying contract code and later changing the code arbitrarily by “creating” an account at that existing address.\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\nIf a contract creation is attempted due to a creation transaction, the CREATE opcode, the CREATE2 opcode, or any other reason, and the destination address already has either a nonzero nonce, or a nonzero code length, then the creation MUST throw as if the first byte in the init code were an invalid opcode. This change MUST apply retroactively for all existing blocks.\n\n Rationale\n\nOne of the core tenets of smart contracts is that their code will not change. However with sufficient computing power an attacker can change the code stored in an address to any other code, steal funds or execute other malicious activity.\n\n Backwards Compatibility\n\nThis is an execution layer upgrade, and so it requires a hard fork.\n\n Test Cases\n\nGiven a genesis allocation of\n\nAddress : 0xd0bBEc6D2c628b7e2E6D5556daA14a5181b604C5,\nBalance : 1000000000000000000, // 1 ether\nNonce : 0,\ncode : \"\",\n\nAddress : 0x7658771dc6Af74a3d2F8499D349FF9c1a0DF8826,\nBalance : 0,\nNonce : 1,\nCode : \"0xB0B0FACE\",\n\nA contract created in the first transaction from EOA 0xd0bBEc6... (227bcc6959669226360814723ed739f1214201584b6a27409dfb8228b8be5f59), with no salt, should revert.\n\n Security Considerations\n\nThis EIP is a security upgrade: it enforces the immutability of deployed code.\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), Renan Rodrigues de Souza (@RenanSouza2), \"EIP-684: Revert creation in case of collision,\" Ethereum Improvement Proposals, no. 684, March 2023. Available: https://eips.ethereum.org/EIPS/eip-684.","tokens":582,"squid":"spider-05","role":"Spec Spider","at":1791341409128,"hash":"c7bdada6dfe1d483362d6af58815dc0e7d45fe0d"}
{"url":"https://docs.arbitrum.foundation/state-of-progressive-decentralization","domain":"docs.arbitrum.foundation","title":"The state of Arbitrum's progressive decentralization | Arbitrum DAO - Governance docs","text":"✏️Request an updatePUBLIC PREVIEW DOCUMENTThis document is currently in public preview and may change significantly as feedback is captured from readers like you. Click the Request an update button at the top of this document or join the Arbitrum Discord to share your feedback.Progressive decentralization is the process of gradually increasing the decentralization of a system over time. This document details the current state of progressive decentralization for the Arbitrum One and Arbitrum Nova chains, the two chains currently governed by the ArbitrumDAO.The components of Arbitrum's progressive decentralization​The following components determine the degree of decentralization for Arbitrum One and Arbitrum Nova:Chain ownershipValidation decentralization statusSequencer ownershipData Availability Committee ownershipLet's evaluate the current status of these components for both Arbitrum One and Arbitrum Nova, beginning with chain ownership.1. Chain ownership​Description: A chain's \"owner\" has the ability to change the protocol in various ways, including upgrading the core smart contracts, setting system parameters, and pausing the system.Current status: Governed by ArbitrumDAO. Chain ownership of both Arbitrum One and Arbitrum Nova is under the control of the Arbitrum governance system. The Arbitrum Decentralized Autonomous Organization (DAO), made up of $ARB token-holders and delegates, can carry out chain-owner operations through governance votes. The Security Council can also carry out chain-owner operations; it can act quickly through a 9 of 12 multisig wallet, but only in critical emergency situations. The Security Council can also act slowly through a 9 of 12 multisig wallet in non-emergency situations to carry out routine and minor upgrades, such as minor bug fixes. The members of the Security Council (split by cohort) are elected every year by the ArbitrumDAO.Risks:If 9 of the Security Council members are compromised or behave maliciously, the system and users' funds could be compromised.If a malicious proposal is successfully put through DAO governance, or if 9 of the Security Council members are compromised or behave maliciously, the system's safety could be compromised. In either of these cases, users will have several weeks to withdraw their funds back to Ethereum before the proposal takes effect.Changes To Current Status: The governance system currently has the ability to alter governance itself.2. Validation decentralization status​Description: Validators are responsible for confirming the valid state of the Arbitrum chains back on L1.ChainDecentralization StatusDescriptionArbitrum OnePermissionlessValidation on Arbitrum One now follows the BoLD protocol, any node implementing the BoLD protocol can join. You can learn more about BoLD in this introduction to BoLDArbitrum NovaPermissionedArbitrum Nova remains permissioned as its Data Availability committee is a trusted oneRisks: If there is not a single honest active validator, and a malicious validator proposes an invalid state update, the system's safety could be compromised.3. Sequencer ownership​Description: The Sequencer is typically responsible for collecting and ordering users' transactions.Current status: Centralized. The Sequencers for both Arbitrum One and Arbitrum Nova are currently maintained by the Arbitrum Foundation. Governance currently has the power to select new Sequencers.Risks: The Sequencer has the ability to delay the inclusion of a user's transaction by up to 24 hours and reorder transactions over short time-horizons. The Sequencer, however, cannot compromise the system's safety or prevent a transaction from ultimately being executed.Changes to Current status: The Arbitrum governance system (see #1) currently has the power to elect a new entity as the Sequencer.4. Data Availability Committee ownership​DACs apply only to Arbitrum AnyTrust chains like Arbitrum NovanoteThis applies only to Arbitrum AnyTrust chains like Arbitrum Nova.Description: AnyTrust chains like Arbitrum Nova rely on a permissioned committee to store the chain's data and provide it on demand.Current status: 6-member committee. The Arbitrum Nova chain has a 6-party DAC, whose members can be seen here. Governance has the ability to remove or add members to the committee.Risks: If 5 of the 6 committee members in conjunction with the Sequencer behave maliciously and collude, the safety of the system can be compromised.Changes to Current status: The Arbitrum governance system (see #1) currently has the power to change the DAC, such as by adding or removing members or modifying the power it has over the system.Data Availability Committee members​These are the current members of the 5-of-6 data availability committee (DAC) in Arbitrum Nova:ConsenSys Software Inc.QuickNode, Inc.P2P.orgGoogle CloudOffchain, Inc.Opensea Innovation Labs Private LimitedThe components of Arbitrum's progressive decentralization1. Chain ownership2. Validation decentralization status3. Sequencer ownership4. Data Availability Committee ownershipData Availability Committee members","tokens":1273,"squid":"spider-07","role":"Council Spider","at":1791341411724,"hash":"7d05034592e1cc59da278384ca4bd9dcd3bfb43b"}
{"url":"https://eips.ethereum.org/EIPS/eip-695","domain":"eips.ethereum.org","title":"EIP-695: Create `eth_chainId` method for JSON-RPC","text":"🎉 Final\n\n Standards Track: Interface\n\n EIP-695: Create `eth_chainId` method for JSON-RPC\n\n Authors\n Isaac Ardis <isaac.ardis@gmail.com>, Wei Tang (@sorpaas), Fan Torchz (@tcz001), Erik Marks (@rekmarks)\n\n Created\n 2017-08-21\n\n Requires\n\n EIP-155\n\n Simple Summary\n\nInclude eth_chainId method in eth_-namespaced JSON-RPC methods.\n\n Abstract\n\nThe eth_chainId method should return a single STRING result\nfor an integer value in hexadecimal format, describing the\ncurrently configured CHAIN_ID value used for signing replay-protected transactions,\nintroduced by EIP-155.\n\n Motivation\n\nCurrently although we can use net_version RPC call to get the\ncurrent network ID, there’s no RPC for querying the chain ID. This\nmakes it impossible to determine the current actual blockchain using\nthe RPC.\n\n Specification\n\n eth_chainId\n\nReturns the currently configured chain ID, a value used in replay-protected transaction\nsigning as introduced by EIP-155.\n\nThe chain ID returned should always correspond to the information in the current known\nhead block. This ensures that caller of this RPC method can always use the retrieved\ninformation to sign transactions built on top of the head.\n\nIf the current known head block does not specify a chain ID, the client should treat any\ncalls to eth_chainId as though the method were not supported, and return a suitable\nerror.\n\n Parameters\n\nNone.\n\n Returns\n\nQUANTITY - integer of the current chain ID.\n\n Example\n\ncurl -X POST --data '{\"jsonrpc\":\"2.0\",\"method\":\"eth_chainId\",\"params\":[],\"id\":83}'\n\n// Result\n{\n \"id\": 83,\n \"jsonrpc\": \"2.0\",\n \"result\": \"0x3d\" // 61\n}\n\n Rationale\n\nAn ETH/ETC client can accidentally connect to an ETC/ETH RPC\nendpoint without knowing it unless it tries to sign a transaction or\nit fetches a transaction that is known to have signed with a chain\nID. This has since caused trouble for application developers, such as\nMetaMask, to add multi-chain support.\n\n Backwards Compatibility\n\nNot relevant.\n\n Security Considerations\n\nConsumers should prefer eth_chainId over net_version, so that they can reliably identify chain they are communicating with.\n\nImplementers should take care to implement eth_chainId correctly and promote its use, since the chain ID is critical in replay attack prevention as described in EIP-155, and consumers will rely on it to identify the chain they are communicating with.\n\n Implementation\n\n Parity PR\n Geth PR\n Geth Classic PR\n\n Reference\n\nReturn value QUANTITY adheres to standard JSON RPC hex value encoding, as documented in the Ethereum.org documentation.\n\n Copyright\n\nCopyright and related rights waived via CC0.\n\n Citation\n Please cite this document as:\n\n Isaac Ardis <isaac.ardis@gmail.com>, Wei Tang (@sorpaas), Fan Torchz (@tcz001), Erik Marks (@rekmarks), \"EIP-695: Create `eth_chainId` method for JSON-RPC,\" Ethereum Improvement Proposals, no. 695, August 2017. Available: https://eips.ethereum.org/EIPS/eip-695.","tokens":726,"squid":"spider-05","role":"Spec Spider","at":1791341419238,"hash":"d15a08cc28449879abe405005c03d4f5fbbf7f4c"}
{"url":"https://squidfunk.github.io/mkdocs-material/customization/","domain":"squidfunk.github.io","title":"Customization - Material for MkDocs","text":"Customization¶ Project documentation is as diverse as the projects themselves and Material for MkDocs is a great starting point for making it look beautiful. However, as you write your documentation, you may reach a point where small adjustments are necessary to preserve your brand's style. Adding assets¶ MkDocs provides several ways to customize a theme. In order to make a few small tweaks to Material for MkDocs, you can just add CSS and JavaScript files to the docs directory. Additional CSS¶ If you want to tweak some colors or change the spacing of certain elements, you can do this in a separate style sheet. The easiest way is by creating a new style sheet file in the docs directory: .\n├─ docs/\n│ └─ stylesheets/\n│ └─ extra.css\n└─ mkdocs.yml\n Then, add the following lines to mkdocs.yml: extra_css:\n - stylesheets/extra.css\n Additional JavaScript¶ If you want to integrate another syntax highlighter or add some custom logic to your theme, create a new JavaScript file in the docs directory: .\n├─ docs/\n│ └─ javascripts/\n│ └─ extra.js\n└─ mkdocs.yml\n Then, add the following lines to mkdocs.yml: extra_javascript:\n - javascripts/extra.js\n How to integrate with third-party JavaScript libraries It is likely that you will want to run your JavaScript code only once the page has been fully loaded by the browser. This means installing a callback function subscribing to events on the document$ observable exported by Material for MkDocs. Using the document$ observable is particularly important if you are using instant loading since it will not result in a page refresh in the browser - but subscribers on the observable will be notified. document$.subscribe(function() {\n console.log(\"Initialize third-party libraries here\")\n})\n document$ is an RxJS Observable and you can call the subscribe() method any number of times to attach different functionality. Extending the theme¶ If you want to alter the HTML source (e.g. add or remove some parts), you can extend the theme. MkDocs supports theme extension, an easy way to override parts of Material for MkDocs without forking from git. This ensures that you can update to the latest version more easily. Setup and theme structure¶ Enable Material for MkDocs as usual in mkdocs.yml, and create a new folder for overrides which you then reference using the custom_dir setting: theme:\n name: material\n custom_dir: overrides\n Theme extension prerequisites As the custom_dir setting is used for the theme extension process, Material for MkDocs needs to be installed via pip and referenced with the name setting in mkdocs.yml. It will not work when cloning from git. The structure in the overrides directory must mirror the directory structure of the original theme, as any file in the overrides directory will replace the file with the same name which is part of the original theme. Besides, further assets may also be put in the overrides directory: .\n├─ .icons/ # Bundled icon sets\n├─ assets/\n│ ├─ images/ # Images and icons\n│ ├─ javascripts/ # JavaScript files\n│ └─ stylesheets/ # Style sheets\n├─ partials/\n│ ├─ integrations/ # Third-party integrations\n│ │ ├─ analytics/ # Analytics integrations\n│ │ └─ analytics.html # Analytics setup\n│ ├─ languages/ # Translation languages\n│ ├─ actions.html # Actions\n│ ├─ alternate.html # Site language selector\n│ ├─ comments.html # Comment system (empty by default)\n│ ├─ consent.html # Consent\n│ ├─ content.html # Page content\n│ ├─ copyright.html # Copyright and theme information\n│ ├─ feedback.html # Was this page helpful?\n│ ├─ footer.html # Footer bar\n│ ├─ header.html # Header bar\n│ ├─ icons.html # Custom icons\n│ ├─ language.html # Translation setup\n│ ├─ logo.html # Logo in header and sidebar\n│ ├─ nav.html # Main navigation\n│ ├─ nav-item.html # Main navigation item\n│ ├─ pagination.html # Pagination (used for blog)\n│ ├─ palette.html # Color palette toggle\n│ ├─ post.html # Blog post excerpt\n│ ├─ progress.html # Progress indicator\n│ ├─ search.html # Search interface\n│ ├─ social.html # Social links\n│ ├─ source.html # Repository information\n│ ├─ source-file.html # Source file information\n│ ├─ tabs.html # Tabs navigation\n│ ├─ tabs-item.html # Tabs navigation item\n│ ├─ tags.html # Tags\n│ ├─ toc.html # Table of contents\n│ ├─ toc-item.html # Table of contents item\n│ └─ top.html # Back-to-top button\n├─ 404.html # 404 error page\n├─ base.html # Base template\n├─ blog.html # Blog index page\n├─ blog-archive.html # Blog archive index page\n├─ blog-category.html # Blog category index page\n├─ blog-post.html # Blog post page\n└─ main.html # Default page\n Overriding partials¶ In order to override a partial, we can replace it with a file of the same name and location in the overrides directory. For example, to replace the original footer.html partial, create a new footer.html partial in the overrides directory: .\n├─ overrides/\n│ └─ partials/\n│ └─ footer.html\n└─ mkdocs.yml\n MkDocs will now use the new partial when rendering the theme. This can be done with any file. Overriding blocks recommended¶ Besides overriding partials, it's also possible to override (and extend) template blocks, which are defined inside the templates and wrap specific features. In order to set up block overrides, create a main.html file inside the overrides directory: .\n├─ overrides/\n│ └─ main.html\n└─ mkdocs.yml\n Then, e.g. to override the site title, add the following lines to main.html: {% extends \"base.html\" %}\n\n{% block htmltitle %}\n <title>Lorem ipsum dolor sit amet</title>\n{% endblock %}\n If you intend to add something to a block rather than to replace it altogether with new content, use {{ super() }} inside the block to include the original block content. This is particularly useful when adding third-party scripts to your docs, e.g. {% extends \"base.html\" %}\n\n{% block scripts %}\n <!-- Add scripts that need to run before here -->\n {{ super() }}\n <!-- Add scripts that need to run afterwards here -->\n{% endblock %}\n The following template blocks are provided by the theme: Block name Purpose analytics Wraps the Google Analytics integration announce Wraps the announcement bar config Wraps the JavaScript application config container Wraps the main content container content Wraps the main content extrahead Empty block to add custom meta tags fonts Wraps the font definitions footer Wraps the footer with navigation and copyright header Wraps the fixed header bar hero Wraps the hero teaser (if available) htmltitle Wraps the <title> tag libs Wraps the JavaScript libraries (header) outdated Wraps the version warning scripts Wraps the JavaScript application (footer) site_meta Wraps the meta tags in the document head site_nav Wraps the site navigation and table of contents styles Wraps the style sheets (also extra sources) tabs Wraps the tabs navigation (if available) Theme development¶ Material for MkDocs is built on top of TypeScript, RxJS and SASS, and uses a lean, custom build process to put everything together.1 If you want to make more fundamental changes, it may be necessary to make the adjustments directly in the source of the theme and recompile it. Environment setup¶ First, clone the repository: git clone https://github.com/squidfunk/mkdocs-material\ncd mkdocs-material\n Next, create a new Python virtual environment and activate it: python -m venv venv\nsource venv/bin/activate\n Ensure pip always runs in a virtual environment If you set the environment variable PIP_REQUIRE_VIRTUALENV to true, pip will refuse to install anything outside a virtual environment. Forgetting to activate a venv can be very annoying as it will install all sorts of things outside virtual environments over time, possibly leading to further errors. So, you may want to add this to your .bashrc or .zshrc and re-start your shell: export PIP_REQUIRE_VIRTUALENV=true\n Then, install all Python dependencies: pip install -e \".[git, recommended, imaging]\"\npip install nodeenv\n In addition, you will need to install the cairo and pngquant libraries in your system, as described in the image processing requirements guide. Finally, install the Node.js LTS version into the Python virtual environment and install all Node.js dependencies: nodeenv -p -n lts\nnpm install\n Development mode¶ Start the watcher with: npm start\n Then, in a second terminal window, start the MkDocs live preview server with: mkdocs serve --watch-theme\n Point your browser to localhost:8000 and you should see this very documentation in front of you. Automatically generated files Never make any changes in the material directory, as the contents of this directory are automatically generated from the src directory and will be overwritten when the theme is built. Building the theme¶ When you're finished making your changes, you can build the theme by invoking: npm run build \n This triggers the production-level compilation and minification of all style sheets and JavaScript files. After the command exits, the compiled files are located in the material directory. When running mkdocs build, you should now see your changes to the original theme. Prior to 7.0.0 the build was based on Webpack, resulting in occasional broken builds due to incompatibilities with loaders and plugins. Therefore, we decided to swap Webpack for a leaner solution which is now based on RxJS as the application itself. This allowed for the pruning of more than 500 dependencies (~30% less). ↩","tokens":2335,"squid":"spider-06","role":"Security Spider","at":1791341426711,"hash":"1798b89c0727bd2f954f48df1126e672b3ac4729"}
{"url":"https://eips.ethereum.org/EIPS/eip-706","domain":"eips.ethereum.org","title":"EIP-706: DEVp2p snappy compression","text":"🎉 Final\n\n Standards Track: Networking\n\n EIP-706: DEVp2p snappy compression\n\n Authors\n Péter Szilágyi <peter@ethereum.org>\n\n Created\n 2017-09-07\n\n Abstract\n\nThe base networking protocol (DEVp2p) used by Ethereum currently does not employ any form of compression. This results in a massive amount of bandwidth wasted in the entire network, making both initial sync as well as normal operation slower and laggier.\n\nThis EIP proposes a tiny extension to the DEVp2p protocol to enable Snappy compression on all message payloads after the initial handshake. After extensive benchmarks, results show that data traffic is decreased by 60-80% for initial sync. You can find exact numbers below.\n\n Motivation\n\nSynchronizing the Ethereum main network (block 4,248,000) in Geth using fast sync currently consumes 1.01GB upload and 33.59GB download bandwidth. On the Rinkeby test network (block 852,000) it’s 55.89MB upload and 2.51GB download.\n\nHowever, most of this data (blocks, transactions) are heavily compressible. By enabling compression at the message payload level, we can reduce the previous numbers to 1.01GB upload / 13.46GB download on the main network, and 46.21MB upload / 463.65MB download on the test network.\n\nThe motivation behind doing this at the DEVp2p level (opposed to eth for example) is that it would enable compression for all sub-protocols (eth, les, bzz) seamlessly, reducing any complexity those protocols might incur in trying to individually optimize for data traffic.\n\n Specification\n\nBump the advertised DEVp2p version number from 4 to 5. If during handshake, the remote side advertises support only for version 4, run the exact same protocol as until now.\n\nIf the remote side advertises a DEVp2p version >= 5, inject a Snappy compression step right before encrypting the DEVp2p message during sending:\n\n A message consists of {Code, Size, Payload}\n Compress the original payload with Snappy and store it in the same field.\n Update the message size to the length of the compressed payload.\n Encrypt and send the message as before, oblivious to compression.\n\nSimilarly to message sending, when receiving a DEVp2p v5 message from a remote node, insert a Snappy decompression step right after decrypting the DEVp2p message:\n\n A message consists of {Code, Size, Payload}\n Decrypt the message payload as before, oblivious to compression.\n Decompress the payload with Snappy and store it in the same field.\n Update the message size to the length of the decompressed payload.\n\nImportant caveats:\n\n The handshake message is never compressed, since it is needed to negotiate the common version.\n Snappy framing is not used, since the DEVp2p protocol already message oriented.\n\nNote: Snappy supports uncompressed binary literals (up to 4GB) too, leaving room for fine-tuned future optimisations for already compressed or encrypted data that would have no gain of compression (Snappy usually detects this case automatically).\n\n Avoiding DOS attacks\n\nCurrently a DEVp2p message length is limited to 24 bits, amounting to a maximum size of 16MB. With the introduction of Snappy compression, care must be taken not to blindly decompress messages, since they may get significantly larger than 16MB.\n\nHowever, Snappy is capable of calculating the decompressed size of an input message without inflating it in memory (the stream starts with the uncompressed length up to a maximum of 2^32 - 1 stored as a little-endian varint). This can be used to discard any messages which decompress above some threshold. The proposal is to use the same limit (16MB) as the threshold for decompressed messages. This retains the same guarantees that the current DEVp2p protocol does, so there won’t be surprises in application level protocols.\n\n Alternatives (discarded)\n\nAlternative solutions to data compression that have been brought up and discarded are:\n\nExtend protocol xyz to support compressed messages versus doing it at DEVp2p level:\n\n Pro: Can be better optimized when to compress and when not to.\n Con: Mixes in transport layer encoding into application layer logic.\n Con: Makes the individual message specs more convoluted with compression details.\n Con: Requires cross client coordination on every single protocol, making the effort much harder and repeated (eth, les, shh, bzz).\n\nIntroduce seamless variations of protocol such as xyz expanded with xyz-compressed:\n\n Pro: Can be done (hacked in) without cross client coordination.\n Con: Litters the network with client specific protocol announces.\n Con: Needs to be specced in an EIP for cross interoperability anyway.\n\nOther ideas that have been discussed and discarded:\n\nDon’t explicitly limit the decompressed message size, only the compressed one:\n\n Pro: Allows larger messages to traverse through DEVp2p.\n Con: Upper layer protocols need to check and discard large messages.\n Con: Needs lazy decompression to allow size limitations without DOS.\n\n Backwards Compatibility\n\nThis proposal is fully backward compatible. Clients upgrading to the proposed DEVp2p protocol version 5 should still support skipping the compression step for connections that only advertise version 4 of the DEVp2p protocol.\n\n Implementation\n\nYou can find a reference implementation of this EIP in https://github.com/ethereum/go-ethereum/pull/15106.\n\n Test vectors\n\nThere is more than one valid encoding of any given input, and there is more than one good internal compression algorithm within Snappy when trading off throughput for output size. As such, different implementations might produce slight variations in the compressed form, but all should be cross compatible between each other.\n\nAs an example, take hex encoded RLP of block #272621 from the Rinkeby test network: block.rlp (~3MB).\n\n Encoding the raw RLP via Go’s Snappy library yields: block.go.snappy (~70KB).\n Encoding the raw RLP via Python’s Snappy library yields: block.py.snappy (~70KB).\n\nYou can verify that an encoded binary can be decoded into the proper plaintext using the following snippets:\n\n Go\n\n$ go get https://github.com/golang/snappy\n\npackage main\n\nimport (\n \"bytes\"\n \"encoding/hex\"\n \"fmt\"\n \"io/ioutil\"\n \"log\"\n \"os\"\n\n \"github.com/golang/snappy\"\n)\n\nfunc main() {\n // Read and decode the decompressed file\n plainhex, err := ioutil.ReadFile(os.Args[1])\n if err != nil {\n log.Fatalf(\"Failed to read decompressed file %s: %v\", os.Args[1], err)\n }\n plain, err := hex.DecodeString(string(plainhex))\n if err != nil {\n log.Fatalf(\"Failed to decode decompressed file: %v\", err)\n }\n // Read and decode the compressed file\n comphex, err := ioutil.ReadFile(os.Args[2])\n if err != nil {\n log.Fatalf(\"Failed to read compressed file %s: %v\", os.Args[2], err)\n }\n comp, err := hex.DecodeString(string(comphex))\n if err != nil {\n log.Fatalf(\"Failed to decode compressed file: %v\", err)\n }\n // Make sure they match\n decomp, err := snappy.Decode(nil, comp)\n if err != nil {\n log.Fatalf(\"Failed to decompress compressed file: %v\", err)\n }\n if !bytes.Equal(plain, decomp) {\n fmt.Println(\"Booo, decompressed file does not match provided plain text!\")\n return\n }\n fmt.Println(\"Yay, decompressed data matched provided plain text!\")\n}\n\n$ go run main.go block.rlp block.go.snappy\nYay, decompressed data matched provided plain text!\n\n$ go run main.go block.rlp block.py.snappy\nYay, decompressed data matched provided plain text!\n\n Python\n\n$ pip install python-snappy\n\nimport snappy\nimport sys\n\n# Read and decode the decompressed file\nwith open(sys.argv[1], 'rb') as file:\n plainhex = file.read()\n\nplain = plainhex.decode(\"hex\")\n\n# Read and decode the compressed file\nwith open(sys.argv[2], 'rb') as file:\n comphex = file.read()\n\ncomp = comphex.decode(\"hex\")\n\n# Make sure they match\ndecomp = snappy.uncompress(comp)\nif plain != decomp:\n print \"Booo, decompressed file does not match provided plain text!\"\nelse:\n print \"Yay, decompressed data matched provided plain text!\"\n\n$ python main.py block.rlp block.go.snappy\nYay, decompressed data matched provided plain text!\n\n$ python main.py block.rlp block.py.snappy\nYay, decompressed data matched provided plain text!\n\n References\n\n Snappy website: https://google.github.io/snappy/\n Snappy specification: https://github.com/google/snappy/blob/master/format_description.txt\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 <peter@ethereum.org>, \"EIP-706: DEVp2p snappy compression,\" Ethereum Improvement Proposals, no. 706, September 2017. Available: https://eips.ethereum.org/EIPS/eip-706.","tokens":2122,"squid":"spider-05","role":"Spec Spider","at":1791341432673,"hash":"e2b6530cd64a6b1be44dd8be4afe96ded0820109"}
{"url":"https://docs.arbitrum.foundation/how-tos/vote-dao-proposals","domain":"docs.arbitrum.foundation","title":"How to vote on ArbitrumDAO governance proposals | Arbitrum DAO - Governance docs","text":"✏️Request an updatePUBLIC PREVIEW DOCUMENTThis document is currently in public preview and may change significantly as feedback is captured from readers like you. Click the Request an update button at the top of this document or join the Arbitrum Discord to share your feedback.As a member of the ArbitrumDAO, it's important to be an active participant in the DAO's decision-making process by voting on governance proposals that other DAO members submit. The voting process can vary depending on the given proposal's stage; in this how-to, you'll learn how to locate, evaluate, and vote on proposals at each of the possible stages.Proposals in the \"temperature check\" stage​Proposals are first submitted to the ArbitrumDAO governance forum for community discussion and debate. These forum submissions are usually accompanied by a temperature check poll that gauges the community's interest in the proposal. As an $ARB token holder (or delegate) you can participate in these temperature check polls and discussions:Go to the DAO governance forum.Locate the proposal you'd like to vote on and read through the proposal and the discussion thread.Provide feedback and participate in the discussion to help shape the proposal.The forum submission for any given proposal will usually include a link to a temperature check poll that allows you to vote on the proposal:Navigate to the off-chain governance UI.Connect your wallet.Locate the proposal you'd like to vote on (or click the Snapshot link in the forum submission).Cast your vote by following the prompts within the off-chain governance UI.Proposals in the \"on-chain vote\" stage​If the proposal passes the temperature check, it will move on to an on-chain vote facilitated by the on-chain governance UI. To pass this stage, the proposal must meet two thresholds:The proposal must receive more votes in favor than against; andConstitutional AIPs must receive ‘For’ and/or ‘Abstain’ votes from at least 50% of delegated tokens (within the range of 150m to 450m $ARB); non-Constitutional AIPs must receive ‘For’ and/or ‘Abstain’ votes from at least 40% of delegated tokens (within the range of 100m to 300m $ARB). To learn more about quorum, refer to the [Constitution](https://docs.arbitrum.foundation/dao-constitution#section-2-dao-proposals-and-voting-procedures).To vote on proposals in the \"on-chain vote\" stage:Log in to the on-chain governance UI using a wallet that has been delegated voting power. $ARB tokens must be delegated to the wallet address before the voting period beings to vote on the proposal.Navigate to the \"Proposals\" section.Locate the proposal you'd like to vote on and cast your vote.On proposal evaluation​It's important to evaluate proposals based on their alignment with the values and goals of the ArbitrumDAO as outlined in the Constitution. Remember that the ultimate goal of the DAO is to create a decentralized and transparent platform that benefits all members, including those who aren't yet members.On delegation​You can grant your voting power to a delegate if you don't have the time to actively participate in the governance process. If you decide to delegate your voting power to someone else, be sure to select a delegate who demonstrates the values enshrined within the Constitution. If you're looking for guidance on how to delegate, or how to select a delegate, refer to How to delegate your voting power.Conclusion​Changes made to this process will be facilitated through proposals that follow the procedure outlined in the Constitution. To learn more about proposals or the voting process, refer to the Constitution and the other documents within this content set. If you have any questions or concerns, visit the ArbitrumDAO governance forum.Proposals in the \"temperature check\" stageProposals in the \"on-chain vote\" stageOn proposal evaluationOn delegationConclusion","tokens":966,"squid":"spider-07","role":"Council Spider","at":1791341432808,"hash":"d570673e713708a2742e10dbbb06f460d44041ec"}
{"url":"https://docs.switchboard.xyz/custom-feeds/advanced-feed-configuration/twap","domain":"docs.switchboard.xyz","title":"Time-Weighted Average Prices | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.Time-weighted average price (TWAP) is a pricing algorithm that calculates the average price of an asset over a specified time period. TWAP provides manipulation-resistant pricing by averaging prices over a configurable time window, weighted by the duration each price was observed.SurgeTwapTaskThe surgeTwapTask calculates TWAP from Switchboard's streaming price data. The algorithm weights each observed price by how long it was in effect:TWAP = Σ(price × duration) / Σ(duration)Basic Example{\n surgeTwapTask: {\n symbol: \"BTC/USD\",\n timeInterval: \"ONE_HOUR\"\n }\n}ParametersParameterTypeRequiredDefaultDescriptionsymbolstringYes-Trading pair in */USD format (e.g., \"BTC/USD\", \"ETH/USD\", \"SOL/USD\")timeIntervalTimeIntervalNoONE_HOURLookback window for TWAP calculationTime IntervalsIntervalDurationDescriptionFIVE_MINUTES5 minShortest window, most responsive to price changesTEN_MINUTES10 minFIFTEEN_MINUTES15 minTHIRTY_MINUTES30 minONE_HOUR1 hourDefault, balances responsiveness and stabilityTWO_HOURS2 hoursSIX_HOURS6 hoursTWELVE_HOURS12 hoursMost stable, least responsiveConstraintsOnly */USD pairs are supported (e.g., \"BTC/USD\", \"SOL/USD\")The task will fail if a non-USD quote currency is providedUse CasesLending Protocols — Use TWAP for liquidation price checks to prevent flash loan attacks that temporarily manipulate spot prices.Perpetual Exchanges — Funding rate calculations based on TWAP reduce the impact of short-term price spikes.Options and Derivatives — Settlement prices based on TWAP reduce the impact of last-minute price manipulation.AMMs and DEXs — TWAP oracles provide manipulation-resistant prices for concentrated liquidity ranges or limit orders.Examples30-Minute TWAP for SOL/USD{\n surgeTwapTask: {\n symbol: \"SOL/USD\",\n timeInterval: \"THIRTY_MINUTES\"\n }\n}TWAP with Price BoundsCombine TWAP with bounding to ensure the calculated average stays within expected ranges:{\n surgeTwapTask: {\n symbol: \"ETH/USD\",\n timeInterval: \"ONE_HOUR\"\n }\n},\n{\n boundTask: {\n lowerBoundValue: \"1000\",\n upperBoundValue: \"10000\"\n }\n}Multiple TWAP SourcesUse a median task to aggregate TWAPs from multiple assets:{\n medianTask: {\n tasks: [\n {\n surgeTwapTask: {\n symbol: \"BTC/USD\",\n timeInterval: \"ONE_HOUR\"\n }\n },\n {\n surgeTwapTask: {\n symbol: \"ETH/USD\",\n timeInterval: \"ONE_HOUR\"\n }\n }\n ]\n }\n}Error HandlingErrorCauseSolutionsymbol is emptyMissing symbol parameterProvide a valid symbolonly supports */USD pairsNon-USD quote currencyUse USD pairs only (e.g., \"BTC/USD\" not \"BTC/EUR\")no candle data availableNo price data in lookback windowVerify the trading pair is supportedHow It WorksThe TWAP calculation uses Switchboard's continuous price streaming infrastructure:Price ticks are accumulated into 5-minute candlesEach candle stores the time-weighted sum and observed durationWhen queried, candles spanning the requested interval are aggregatedThe final TWAP is computed by dividing total weighted sum by total durationThe system includes gap protection: if price updates are interrupted for more than 5 seconds, that gap does not contribute to the TWAP calculation. This prevents stale prices from being over-weighted during network interruptions or exchange outages.A variance check compares the TWAP against secondary price sources. If the coefficient of variation exceeds 0.4%, the task fails to protect against compromised exchange data.PreviousOracle AggregatorNextFAQLast updated 8 months ago","tokens":875,"squid":"spider-08","role":"Oracle Spider","at":1791341531307,"hash":"10e06598cdb5326f9416823399803035270a5d6b"}
{"url":"https://docs.switchboard.xyz/custom-feeds/advanced-feed-configuration/faq","domain":"docs.switchboard.xyz","title":"FAQ | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.Which sources should I pick for my feed?We generally recommend sourcing data from where an asset is most actively traded / liquidity is greatest for price feeds. This can mean sourcing data from a large centralized exchange versus a small AMM.Exchanges with low liquidity/volume can become manipulable by bad actors if small enough, so it's up to feed owners to configure their sources and find something that works within their risk parameters.How do I get a new Task Type added?It's recommended to exhaust all options for fetching the data you desire using existing task types before requesting new task types, but if it requires a custom On-Chain SDK, please reach out and it can get added to the roadmap.PreviousTime-Weighted Average PricesNextTask Types ReferenceLast updated 7 months ago","tokens":221,"squid":"spider-08","role":"Oracle Spider","at":1791341541259,"hash":"64c071c100450b1777ab3dbf26ddb866dda2bee6"}
{"url":"https://developer.arbitrum.io/get-started/arbitrum-introduction","domain":"developer.arbitrum.io","title":"Arbitrum introduction","text":"Arbitrum introductionFrequently asked questions about Arbitrum, a finance-native blockchain platform.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 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 , also called . An Arbitrum chain that settles to Ethereum is a , also called .\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 , 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 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 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 . 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 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 , 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 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 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 , 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?\n 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 .\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 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 that the Arbitrum Foundation operates\nArbitrum Nova, an that the Arbitrum Foundation operates\nArbitrum chains that developers launch and operate themselves\n\nOn an EVM layer 2, as :\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.How is this guide?Get started with ArbitrumFind quickstarts, guides, and reference docs for building dApps, bridging tokens, running nodes, and launching chains on Arbitrum.Machine Payments Protocol (MPP)This quickstart shows you how to implement the Machine Payments Protocol (MPP) on Arbitrum.","tokens":2494,"squid":"spider-01","role":"Chain Spider","at":1791341557808,"hash":"df2cdb5c88304a74ca1ee660aa00d311b73fd3a5"}
{"url":"https://docs.switchboard.xyz/custom-feeds/advanced-feed-configuration/data-feed-variable-overrides","domain":"docs.switchboard.xyz","title":"Data Feed Variable Overrides | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.Variable overrides substitute request-scoped values into string fields in an oracle job. Put a placeholder such as ${MARKET_DATA_API_KEY} in the job definition, then provide the matching non-empty value in variableOverrides when requesting execution.Overrides are a general substitution feature. They can represent credentials, URLs, symbols, paths, headers, query parameters, or other string values. Whether a particular override is appropriate depends on who controls updates and what feed consumers trust.Trust ModelThe concrete override map is execution-scoped. It is not included in the feed ID or the signed checksum. A consumer can identify the job definition containing ${VARIABLE_NAME}, but cannot recover or independently verify the value substituted for that placeholder from the feed identity or signature.TEE-backed execution protects how selected oracle software handles a request, but it does not make override values part of the feed definition. The execution nodes necessarily receive values that their tasks must use, so credentials should be scoped to the intended API and request path.Choose override values according to the update model:Update modelAppropriate usePermissionless feed updatesPrefer credentials and other values that do not intentionally change the data source, selected market, extraction path, or calculation. Keep semantic inputs fixed in the job definition.Controlled updaterSemantic values such as a URL, symbol, or path are supported when the caller controls every execution request and consumers intentionally trust that caller to select them.One execution request should represent one customer or security domain. Do not combine unrelated customers' jobs and credentials in one request.Credential ExampleKeep the data source and extraction logic fixed while substituting only the credential:const apiKey = process.env.MARKET_DATA_API_KEY;\nif (!apiKey) {\n throw new Error(\"MARKET_DATA_API_KEY is required\");\n}\n\nconst job = {\n tasks: [\n {\n httpTask: {\n url: \"https://api.example.com/v1/markets/BTC-USD/price\",\n headers: [\n {\n key: \"authorization\",\n value: \"Bearer ${MARKET_DATA_API_KEY}\",\n },\n ],\n },\n },\n {\n jsonParseTask: {\n path: \"$.price\",\n },\n },\n ],\n};\n\nconst response = await gateway.fetchSignaturesConsensus({\n // ...feed request fields containing job\n variableOverrides: {\n MARKET_DATA_API_KEY: apiKey,\n },\n});Placeholder names are case-sensitive and must match the map key exactly. Use environment variables or a secret manager as the source of credential values. Never hardcode credentials in a job, commit them, include them in errors, or log override values.Semantic OverridesSemantic overrides are valid for a controlled caller. For example, a backend that owns the request and whose consumers trust its market selection can use:const job = {\n tasks: [\n {\n httpTask: {\n url: \"https://api.example.com/v1/markets/${MARKET}/price\",\n },\n },\n {\n jsonParseTask: {\n path: \"$.price\",\n },\n },\n ],\n};\n\nconst response = await gateway.fetchSignaturesConsensus({\n // ...feed request fields containing job\n variableOverrides: {\n MARKET: \"BTC-USD\",\n },\n});This request can produce a different result for each MARKET value while retaining the same feed identity. Do not use this pattern on a permissionless update path where an untrusted updater could select the value.Jupiter and Pyth API KeysJupiter and Pyth both support customer-provided API keys, but their fallback rules differ:TaskPreferred task fieldOverride behaviorJupiterSwapTaskapiKey: \"${JUPITER_API_KEY}\"JUPITER_API_KEY is a conventional example name, not reserved. The override is applied only when the field contains the matching placeholder. An unresolved placeholder fails before contacting Jupiter. If the field is omitted or empty, the oracle's configured Jupiter key is used when available.OracleTask with pythAddresspythConfigs.apiKey: \"${PYTH_API_KEY}\"A non-empty task field takes precedence. If it is omitted or empty, the reserved request override PYTH_API_KEY is a compatibility fallback for every eligible pythAddress task in that request. The fallback is not shared with another request or customer.OracleTask with pythPushFeedIdNoneThe task reads an on-chain account and does not use Hermes authentication.For new Pyth feed definitions, use the explicit task placeholder. The request-wide PYTH_API_KEY fallback exists so existing pythAddress jobs can adopt authenticated Hermes access without changing each stored job during the Pyth Core transition.See Jupiter API keys, Pyth authentication and push feeds, JupiterSwapTask, and OracleTask for task-specific examples and fields.Operational GuidanceValidate that every required override is present and non-empty before sending the request.Use least-privilege, rate-limited credentials and rotate them through your secret manager.Log placeholder names or whether configuration is present, never override values.Keep one customer's jobs and credentials within that customer's execution request.For permissionless feeds, keep the endpoint, selected data, parsing path, and calculations fixed in the job definition.Related ResourcesREST APIs with HttpTaskVariables with CacheTaskBuild with TypeScriptTask Types ReferencePreviousFeed Parameter UnitsNextVariables with CacheTaskLast updated 2 months ago","tokens":1339,"squid":"spider-08","role":"Oracle Spider","at":1791341560591,"hash":"f9785bd769e11433f1928eb3b890c40732e48570"}
{"url":"https://developer.arbitrum.io/audit-reports","domain":"developer.arbitrum.io","title":"Security audit reports","text":"Security audit reportsA comprehensive list of security audits conducted on Arbitrum protocol components, including Nitro, BoLD, Stylus, and related smart contracts.Request an updateAuditorAudit date (MM/DD/YYY)Audited codeView reportTrail of Bits09/15/2026OSP Soundness GuardviewTrail of Bits08/14/2026Tip Collection TogglerviewTrail of Bits08/07/2026Yield Bearing BridgeviewTrail of Bits07/31/2026Upgrade Action ContractviewTrail of Bits07/31/2026Sequencer Feed TicketingviewTrail of Bits07/10/2026ArbOS 60 & 61viewTrail of Bits06/16/2026Reward Distributor FixesviewTrail of Bits02/18/2026Delegated Voting Power (DVP) Quorum & Proposal CancellationviewTrail of Bits01/12/2026Nitro External DA & Nitro Contracts v3.2.0viewOpen Zeppelin12/19/2025Arbitrum Stylus SDK Pull Request #370 AuditviewOpen Zeppelin12/10/2025Arbitrum Stylus SDK v0.10 AuditviewTrail of Bits12/01/2025ArbOS 50 & 51 Security ReviewviewTrail of Bits12/01/2025Genesis File GeneratorviewTrail of Bits09/15/2025Security Council UpdateviewTrail of Bits07/30/2025Upgrade ExecutorviewTrail of Bits06/02/2025Block Hash PusherviewTrail of Bits06/02/2025Mint/Burn PrecompileviewTrail of Bits05/06/2025ArbOS 40 NitroviewTrail of Bits04/18/2025Reward Distributor FixesviewTrail of Bits03/11/2025Sequencer Liveness ReviewviewTrail of Bits02/28/2025Security Council Key Rotation UpdateviewTrail of Bits02/28/2025Disable Gateway ActionviewTrail of Bits02/14/2025Custom Fee Token Exchange RateviewTrail of Bits02/14/2025Geth 14.4 Changes for PectraviewTrail of Bits02/02/2025ERC-20 Bridge Upgrade for Custom Fee Token & EIP-7702 FixesviewTrail of Bits12/26/2024BoLD Proposal Payload & Upgrade Actions + Misc Changes for Nitro Contracts v3.0.0viewTrail of Bits10/30/2024Changes to BoLD Solidity contracts to support EIP7702 & Fast WithdrawalsviewTrail of Bits10/23/2024ArbOS 32 Bianca: Emergency Stylus FixesviewTrail of Bits10/07/2024Optimizations to BoLD history commitmentsviewTrail of Bits09/25/2024Timeboost Auction ContractsviewOpen Zeppelin09/05/2024Initial Stylus Rust SDK auditviewTrail of Bits08/29/2024Arbitrum Chains & Governance Upgrade Actions Contracts v2.1viewTrail of Bits08/29/2024USDC Custom Gateway & ArbOS Timestamp Upgrade Action contractviewTrail of Bits08/05/2024BoLD contract fixes from the May 2024 audit & DAC reward updatesviewTrail of Bits08/01/2024Custom fee tokenviewTrail of Bits07/26/2024ArbOS 31 Bianca: Nitro UpgradeviewTrail of Bits07/26/2024ArbOS 30 Atlas: Nitro UpgradeviewCode4rena06/17/2024Arbitrum BoLD: Public Audit Competition ReportviewTrail of Bits06/10/2024Arbitrum StylusviewTrail of Bits05/02/2024BoLD contract fixes from the Aug 2023 audit & Delay Buffer changes to the sequencer inboxviewChainsecurity03/20/2024Nova Fee Router Updates (ArbOS 31)viewTrail of Bits03/18/2024l1-l3-teleporterviewTrail of Bits08/02/2023Arbitrum BoLD—initial audit (then called challenge protocol v2)viewTrail of Bits01/06/2023Governance & Token BridgeviewTrail of Bits10/10/2022Nitro Node & Core Contracts, 2 of 2viewConsenSys Diligence06/24/2022Nitro Node & Core ContractsviewTrail of Bits03/14/2022Nitro Node & Core Contracts, 1 of 2viewConsenSys Diligence11/05/2021Core Contracts, Token BridgeviewHow is this guide?FAQList of questions and answers frequently asked by usersOraclesIntegrate oracle price feeds and VRF from providers on Arbitrum.","tokens":833,"squid":"spider-01","role":"Chain Spider","at":1791341567753,"hash":"b81df23028f2ac52107d56ec920cb74167477777"}
{"url":"https://www.paradigm.xyz/terms","domain":"paradigm.xyz","title":"Terms of Use | Paradigm","text":"Website Terms of UseParadigm Operations LP (“Paradigm,” “we,” “us,” or “our”) operates paradigm.xyz and related websites (collectively, the “Site”). This Website Terms of Use (the “Terms”) govern access to and use of the Site and constitute a legal agreement between you and Paradigm. By accessing or using the Site, you agree to these Terms. If you do not agree to these Terms, please do not access or use the Site. We suggest that you review these Terms periodically for changes. All materials on the Site are meant to be reviewed in their entirety, including any footnotes, legal disclaimers, restrictions or disclosures, and any copyright or proprietary notices. Any disclaimers, restrictions, disclosures or hedge clauses apply to any partial document or material in the same manner as they do the whole, and will be deemed incorporated in the portion of any material or document that you consult or download. If you have any questions about these Terms, please contact legalops@paradigm.xyz.All references to “you” or “your,” as applicable, mean the person who accesses, uses, and/or participates in the Site in any manner, and each of your heirs, assigns, and successors. If you use the Site on behalf of an entity or another individual, you represent and warrant that you have the authority to bind that entity or individual, your acceptance of the Terms will be deemed an acceptance by that entity or individual, and “you” and ”your” herein shall refer to that entity, its directors, officers, employees, and agents.EligibilityAccess to and use of the Site is available only to individuals who can form legally binding contracts under applicable law. By accessing or using the Site, you represent and warrant that you meet these eligibility criteria.Ownership of the Site and its ContentThe Site contains proprietary content, information and material that is protected by applicable intellectual property and other laws, including copyright. All content, related intellectual property, and other rights are the sole and exclusive property of Paradigm, its affiliates, and/or its licensors, unless Paradigm expressly grants them to another. Subject to your complete and ongoing compliance with these Terms, Paradigm grants you a non-transferable, non-exclusive, revocable, limited license to access and use the Site for personal use. You may also discuss information you learn from the Site with your financial, legal or tax advisors, and others with whom you share investment decisions. We reserve all rights not expressly granted to you by these Terms.The Site (including, but not limited to, text, photographs, graphics, video, audio content, and computer code) are protected by copyright as collective works or compilation under the copyright laws of the United States and other countries. All individual articles, photographs, graphics, video, audio, and other content or elements comprising the Site are also copyrighted works. All copyrights in the Site are owned by us or by our third-party licensors to the extent permitted under the United States Copyright Act and all international copyright laws.All rights in the product names, company names, trade names, logos, service marks, trade dress, slogans, product packaging, and designs of the Site, whether or not appearing in large print or with the trademark symbol, belong exclusively to Paradigm, its affiliates, and/or its licensors and are protected from reproduction, imitation, dilution, or confusing or misleading uses under national and international trademark and copyright laws. The use or misuse of these trademarks or any materials, except as permitted herein, is expressly prohibited, and nothing stated or implied on the Site confers on you any license or right under any patent or trademark of Paradigm, its affiliates, or any third party.Except where expressly authorized by Paradigm in writing, you are prohibited from publishing, reproducing, distributing, entering into a database, displaying, performing, modifying, creating derivative works, transmitting, or in any way exploiting any part of the Site. You may print copies of any accessible portion of the Site only for your own personal use.FeedbackBy sending us any feedback, comments, questions, or suggestions concerning Paradigm, the Site, or any services we may provide (collectively, “Feedback”), you represent and warrant (a) that you have the right to disclose the Feedback, (b) that the Feedback does not violate the rights of any other person or entity, and (c) that your Feedback does not contain the confidential or proprietary information of any third party or parties. By sending us any Feedback, you further (i) agree that we are under no obligation of confidentiality, express or implied, with respect to the Feedback, (ii) acknowledge that we may have something similar to the Feedback already under consideration or in development, (iii) grant us an irrevocable, non-exclusive, royalty-free, perpetual, worldwide license to use, modify, prepare derivative works, publish, distribute, and sublicense the Feedback, and (iv) irrevocably waive, and cause to be waived, against Paradigm and its agents, employees, or directors any claims and assertions of any moral rights contained in such Feedback. This Feedback section shall survive any termination of these Terms or the Site.Privacy PolicyInformation we collect from the Site shall be subject to the Paradigm Privacy Policy, which is incorporated in these Terms by reference.Rules and ProhibitionsWhile using the Site, you agree to comply with all applicable laws, rules, and regulations.In addition to other prohibitions in these Terms or displayed on the Site, you agree that you will not:distribute, publish, copy, rent, lease, sublicense, assign, transmit, sell or otherwise transfer any part of the Site, including any content on the Site, unless Paradigm expressly permits in writing;disassemble, reverse engineer, modify, translate, alter, replicate, or decompile all or any portion of the Site or otherwise discern the source code of the Site;adapt, modify, translate, or create derivative works from the Site;probe, circumvent, disable, or interfere with features related to security or authentication measures;access or collect data from the Site using automated means or attempt to access data you do not have permission to access;use the Site, or encourage others to use the Site, to create, collect, transmit, store, use, or process any data that violates any applicable laws, or infringes, violates or otherwise misappropriates the intellectual property or other rights of any third party (including any moral right, privacy right, or right of publicity);use the Site or assist someone else to use the Site in an unlawful, misleading, discriminatory, harassing, or fraudulent way;impose unreasonable requests or burdens on our systems or resources, attempt to disrupt or otherwise overwhelm our infrastructure, or interfere with the access of any other user to the Site;use the Site to conduct any unlawful or fraudulent activities, send unsolicited communications or spam, or publish or link to malicious content designed to disrupt another individual’s browser or computer;resell or make any commercial use of content on the Site without our prior written consent including, without limitation, using the Site to build a similar or competitive website, product, or service;remove any copyright, trademark, or other proprietary notice or legend contained on (or printed from) the Site;post, publish, broadcast, commercially exploit or otherwise use Paradigm’s logo or trademark for any purpose;use the Site in any way not specifically permitted under these Terms; orattempt to indirectly undertake any of the above.We have the right, but not the obligation, to monitor and record activity on the Site and respond as we deem appropriate. We may monitor and record activity on the Site for any reason or for no reason. We may investigate any complaint or reported violation of our policies. We may report any activity we suspect may violate any law or regulation to regulators, law enforcement officials, or other persons or entities we deem appropriate. We may issue warnings, suspend, or terminate use of the Site, deny access to all or part of the Site or take any other action we deem appropriate.We reserve all rights and remedies available to us, including but not limited to suspending or disabling your ability to access the Site for violation of these or other provisions in the Terms.Unauthorized Access The Site is not absolutely protected against unauthorized third parties. You acknowledge that any information provided through the internet may be potentially accessed by unauthorized third parties. Although Paradigm will make reasonable efforts to protect the privacy of users of the Site, no guarantee can be made that unauthorized third parties will not access the information contained on the Site. You acknowledge that Paradigm is not responsible for notifying you that unauthorized third parties have gained such access or that any data has been otherwise compromised during transmission across computer networks or telecommunications facilities, including, but not limited to, the internet. Any unauthorized use of the Site or the content herein may also violate copyright laws, trademark laws, the laws of privacy and publicity, and/or communications regulations and statutes. Paradigm does not grant, by implication, estoppel or otherwise, any license or right to use material on the Site other than those set forth above, and you shall not make any other use of such material without Paradigm’s written permission. Communications While we make commercially reasonable efforts to ensure that the Site is secure, we do not guarantee the security of the Site or your communications with us through the Site. Electronic communications can be intercepted by third parties and, accordingly, transmissions to and from the Site may not be secure. Communications to Paradigm, particularly those containing confidential information, may be sent by mail to: Paradigm Operations LP, Attn: Legal Department. Paradigm shall be free to use, for any purpose, any ideas, concepts, know-how, or techniques provided by you to Paradigm through the Site.DisclaimersYOUR USE OF THE SITE IS AT YOUR SOLE RISK. EXCEPT WHERE REQUIRED BY LAW, WE MAKE NO REPRESENTATIONS OR WARRANTIES WITH RESPECT TO THE SITE OR ITS CONTENT, OR ANY PRODUCT OR SERVICE AVAILABLE ON OR PROMOTED THROUGH THE SITE.THE SITE AND ALL OF ITS CONTENT ARE PROVIDED ON AN “AS IS,” “AS AVAILABLE” BASIS, WITHOUT REPRESENTATIONS OR WARRANTIES OF ANY KIND.CERTAIN CONTENT ON THE SITE HAS BEEN OBTAINED FROM THIRD-PARTY SOURCES, INCLUDING COMPANIES IN WHICH FUNDS MANAGED BY PARADIGM HAVE INVESTED. PARADIGM MAKES NO REPRESENTATIONS OR WARRANTIES ABOUT THE ACCURACY OF INFORMATION ON THE SITE. ANY PROJECTIONS, ESTIMATES, FORECASTS, TARGETS, PROSPECTS, OR OPINIONS ON THE SITE ARE SUBJECT TO CHANGE WITHOUT NOTICE AND MAY DIFFER OR BE CONTRARY TO OPINIONS EXPRESSED BY OTHERS.TO THE FULLEST EXTENT PERMITTED BY LAW, PARADIGM, ITS AFFILIATES, AND THEIR SERVICE PROVIDERS AND LICENSORS DISCLAIM ANY AND ALL REPRESENTATIONS AND WARRANTIES, WHETHER EXPRESS, IMPLIED, ARISING BY STATUTE, CUSTOM, COURSE OF DEALING, COURSE OF PERFORMANCE OR IN ANY OTHER WAY, WITH RESPECT TO THE SITE, ITS CONTENT, AND ANY PRODUCTS OR SERVICES AVAILABLE OR PROMOTED THROUGH THE SITE. WITHOUT LIMITING THE GENERALITY OF THE FOREGOING, PARADIGM, ITS AFFILIATES, AND THEIR SERVICE PROVIDERS AND LICENSORS DISCLAIM ALL REPRESENTATIONS AND WARRANTIES (A) OF TITLE, NON-INFRINGEMENT, MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE; (B) RELATING TO THE SECURITY OF THIS SITE; (C) THAT THE CONTENT OF THE SITE IS ACCURATE, COMPLETE OR CURRENT; OR (D) THAT THE SITE WILL OPERATE SECURELY OR WITHOUT INTERRUPTION OR ERROR.WE DO NOT REPRESENT OR WARRANT THAT THE SITE, ITS SERVERS, OR ANY TRANSMISSIONS SENT FROM US OR THROUGH THE SITE WILL BE FREE OF ANY HARMFUL COMPONENTS (INCLUDING VIRUSES). PARADIGM IS NOT RESPONSIBLE FOR ANY ERRORS OR OMISSIONS IN THE CONTENT AVAILABLE ON THE SITE OR FOR DAMAGES ARISING FROM THE USE OR PERFORMANCE OF THE SITE.APPLICABLE LAW MAY NOT ALLOW THE LIMITATION OF CERTAIN WARRANTIES, SO ALL OR PART OF THIS DISCLAIMER OF WARRANTIES MAY NOT APPLY TO YOU.Limitation of LiabilityIN NO EVENT SHALL PARADIGM AND/OR ITS LICENSORS BE LIABLE TO ANYONE FOR ANY DIRECT, INDIRECT, PUNITIVE, SPECIAL, EXEMPLARY, INCIDENTAL, CONSEQUENTIAL OR OTHER DAMAGES OF ANY TYPE OR KIND (INCLUDING PERSONAL INJURY, LOSS OF DATA, REVENUE, PROFITS, REPUTATION, USE OR OTHER ECONOMIC ADVANTAGE) EVEN IF PARADIGM AND/OR ITS LICENSORS HAVE BEEN PREVIOUSLY ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. THIS LIMITATION OF LIABILITY APPLIES WHETHER THE ALLEGED LIABILITY IS BASED ON CONTRACT, TORT (INCLUDING NEGLIGENCE), STRICT LIABILITY OR ANY OTHER BASIS. THE LIMITATION OF DAMAGES SET FORTH ABOVE IS A FUNDAMENTAL ELEMENT OF THE BASIS OF THE BARGAIN BETWEEN US AND YOU.THIS LIMITATION OF LIABILITY SECTION APPLIES FULLY IN ALL STATES, INCLUDING RESIDENTS OF NEW JERSEY.WITHOUT LIMITING THE FOREGOING, UNDER ALL CIRCUMSTANCES, THE MAXIMUM LIABILITY OF PARADIGM, ITS AGENTS AND EMPLOYEES WITH RESPECT TO YOUR USE OF THE SITE IS $1.Links to Other Websites and ServicesThe Site may contain links or access to third-party content, websites, services, or systems, including portfolio companies in investments managed by Paradigm. Paradigm does not endorse any third-party content, websites, services, or systems, or guarantee their quality, accuracy, reliability, completeness, currency, timeliness, non-infringement, merchantability, or fitness for any purpose. Third-party content, websites, services, or systems are not under the control of Paradigm, and if you choose to access any such content, websites, services, or systems, you do so entirely at your own risk. Your interactions with such third parties will be governed by the third parties’ own terms of service and privacy policies, and any other similar terms. Additionally, Paradigm reserves the right to remove third-party content, and restrict or block users who post content, to comply with applicable law, including because such content may be construed to constitute testimonials, advice, recommendations or advertisements for securities-related products or services, including recommendations or testimonials of Paradigm products and services.International Use Due to the global nature of the Internet, the Site may be accessed by users in countries other than the United States. We make no warranties that materials on the Site are appropriate or available for use in such locations. If it is illegal or prohibited in your country of origin to access or use the Site, then you should not do so. Those who choose to access the Site outside the United States do so on their own initiative and are responsible for compliance with all local laws and regulations.Modification and Discontinuation of the SiteWe reserve the right at any time to modify, edit, delete, suspend or discontinue, temporarily or permanently, the Site (or any portion thereof) and/or the information, materials, products and/or services available through Paradigm (or any part thereof) with or without notice. You agree that we shall not be liable to you or to any third party in such event.Paradigm Social MediaThe information on the Site and any other pages that Paradigm may create from time to time, including, but not limited to, X (Twitter), LinkedIn, YouTube, and any other social media platforms is for informational purposes only. Nothing on or within these pages constitutes an offer to sell, or a solicitation of an offer to buy, any security or product of Paradigm or Paradigm-managed fund. Paradigm is not responsible for any content posted by third parties on these pages.Indemnity and ReleaseYou are responsible for your use of the Site, and you agree to release and defend, indemnify, and hold harmless Paradigm and its officers, directors, employees, contractors, consultants, affiliates, investors, service providers, business partners, subsidiaries and agents from and against every claim, liability, damage, loss, and expense, including reasonable attorneys’ fees and costs, arising out of or in any way connected with: (i) your violation of any of these Terms, any representation, warranty, or agreement referenced in these Terms, or any applicable law or regulation; (ii) your violation of any third-party right, including any intellectual property right or right of publicity, confidentiality, other property, or privacy right; or (iii) any dispute or issue between you and any third party arising out of your access to the Site.Paradigm reserves the right, at our own expense, to assume the exclusive defense and control of any matter otherwise subject to indemnification by you (without limiting your indemnification obligations) and you agree to cooperate with our defense of that claim. If the defense or settlement is assumed by you, Paradigm may at any time thereafter elect to take over control of the defense and settlement of the claim. You must not settle any claim without Paradigm’s prior written consent.You further release Paradigm, its officers, employees, agents, and successors from claims, demands, and damages of every kind or nature, known or unknown, suspected or unsuspected, disclosed or undisclosed, arising out of or in any way related to such disputes and/or the Site. If you are a California resident, you waive California Civil Code Section 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.If you are not a California resident, you waive your rights under any statute or common law principle similar to Section 1542 that governs your rights in the jurisdiction of your residence.In addition, you understand and agree that your use of the Site is predicated upon your waiver of any right to sue Paradigm, its agents, officers, directors and employees directly or to participate in a suit for any losses or damages resulting from your use of the Site. Notwithstanding the foregoing, nothing contained in preceding paragraphs or elsewhere in these Terms shall constitute a waiver by you of any of your legal rights under applicable U.S. federal securities laws or any other laws whose applicability is not permitted to be contractually waived.Termination Paradigm may terminate your access to the Site for any reason, without prior notice. These Terms shall survive any termination or expiration of your access to the Site.Modification of these TermsWe reserve the right to update or modify the Terms at any time without prior notice, and unless otherwise stated, such changes will be effective immediately upon being posted through the Site. Your use of the Site following any such change constitutes your agreement to be bound by the modified Terms.Arbitration By using the Site, you agree that Paradigm, at its sole discretion, may require you to submit any disputes arising from the use of the Site or these Terms, including disputes arising from or concerning their interpretation, violation, nullity, invalidity, non-performance or termination, as well as disputes about filling gaps in these Terms or their adaptation to newly arisen circumstances, to final and binding arbitration under the International Rules of Arbitration (the “Rules”) of the American Arbitration Association, by one or more arbitrators appointed in accordance with the Rules. Notwithstanding the Rules, however, such proceeding shall be governed by the laws of California and will take place in the state of California. Notice for California Users Under California Civil Code Section 1789.3, California users of the Site are entitled to the following specific consumer rights notice: The Site is provided to you by Paradigm Operations LP which may be contacted regarding complaints or concerns at legalops@paradigm.xyz. The Complaint Assistance Unit of the Division of Consumer Services of the California Department of Consumer Affairs may be contacted in writing at 400 R Street, Suite 1080, Sacramento, California 95814, or by telephone at (916) 445-1254 or (800) 952-5210.GeneralEntire Agreement. These Terms (together with our Privacy Policy and any other legal documents, policies, terms, or agreements governing the Site) comprise the entire agreement between you and Paradigm with regard to the Site and supersedes all prior or contemporaneous negotiations, discussions or agreements, whether written or oral, between the parties regarding the subject matter contained in these Terms.Assignment. You may not assign or transfer these Terms or your rights under these Terms, in whole or in part, by operation of law or otherwise, without our prior written consent. We may assign these Terms in whole or in part at any time to any entity without your notice or consent. Any purported assignment by you in violation of this section shall be void.No Waiver. Our failure at any time to require performance of any provision of these Terms or to exercise any right provided for herein will not be deemed a waiver of such provision or such right. All waivers must be in writing. Unless the written waiver contains an express statement to the contrary, no waiver by Paradigm of any breach of any provision of these Terms or of any right provided for herein will be construed as a waiver of any continuing or succeeding breach of such provision, a waiver of the provision itself, or a waiver of any right herein.Severability. If any provision of these Terms is held to be invalid or unenforceable, such provision shall be struck, and the remaining provisions shall be enforced to the fullest extent under law.Governing Law and Venue. These Terms are governed by the laws of the State of California without regard to conflict of law principles. You and Paradigm agree to submit to the personal and exclusive jurisdiction of the state courts and federal courts located within the State of California. You agree to bring any claim solely in your individual capacity and you expressly waive any right to bring any claim as part of a group or as a class action.No Agency. No joint venture, partnership, employment, or agency relationship exists between you, Paradigm, or any third-party provider as a result of the Terms or use of the Site.","tokens":5656,"squid":"spider-04","role":"Research Spider","at":1791341578502,"hash":"018b4d084c527375f768913054557e2a11322985"}
{"url":"https://forum.across.to/t/community-owned-liquidity-nft-project-funding-request/1555/37","domain":"forum.across.to","title":"“Community Owned Liquidity” NFT Project Funding Request - Proposals / Active Proposals - Across Protocol","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 12\n\n 3\n\n 3\n\n 3\n\n 2\n\n read \n\n 15\n min\n\n Mar 2023\n\n 37 / 37\n\n Jun 2023\n\n Jun 2023\n\n Load more posts above\n\n post by TheRealTuna_Across on Mar 9, 2023\n\n post by mhairi on Mar 9, 2023\n\n post by Britt on Mar 9, 2023\n\n post by caesarsherrod.eth on Mar 9, 2023\n\n post by Deadcoin on Mar 10, 2023\n\n post by TheRealTuna_Across on Mar 10, 2023\n\n post by TheRealTuna_Across on Mar 10, 2023\n\n post by Bananachain on Mar 11, 2023\n\n post by TheRealTuna_Across on Mar 11, 2023\n\n post by Bananachain on Mar 12, 2023\n\n post by eth-wei-trader on Mar 14, 2023\n\n post by TheRealTuna_Across on Mar 15, 2023\n\n post by eth-wei-trader on Mar 15, 2023\n\n post by TheRealTuna_Across on Mar 15, 2023\n\n post by eth-wei-trader on Mar 15, 2023\n\n post by TheRealTuna_Across on Mar 15, 2023\n\n TheRealTuna_Across\n\nI would say it’s more of the opposite as some of the ETH raised would potentially be used to buy ACX in order to balance the ACX/ETH LP (Pending our liquidity management plan to be outlined on the final proposal). If ACX pumps against ETH then yes the LP is essentially selling ACX for ETH but it is generating fee revenue and deepening liquidity at the same time. Ideally ACX and ETH grow together and the liquidity becomes much deeper in the process.\n\nI agree with this but believe that some actions now can help accelerate growth.\n\n post by haifeng on Mar 21, 2023\n\n haifeng\n\n Lovely idea! Will read it in details in the morning but everything looks spot on while I skimmed through the text.\nYou have my full support.\n\n 2 months later\n\n post by Methodic on May 19, 2023\n\n Methodic\n\n Sounds like a great idea! Will this proposal be progressing? Curious to know what next steps will be.\n\n 24 days later\n\n post by barbarossa_Arrakis on Jun 13, 2023\n\n barbarossa_Arrakis\n\n Appreciate the initiative!\nThough the conversation around this proposal seems to have faded, we @Arrakis are making an alternative proposal for Across community.\n\n post by caesarsherrod.eth on Jun 20, 2023\n\n caesarsherrod.eth\n\n Much needed! I would love to see the ACX NFT come to life soon!!! Cannot wait to see what the proposal looks like! I hope it offers minting on Layer 2 simply for a Community NFT & a Liquidity NFT Main net\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Across ($ACX) Community Initial Liquidity Proposal\n\n Passed Proposals\n\n Passed Proposals\n\n 49\n\n Nov 2022\n\n Across Token Launch Proposal v2\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 47\n\n Nov 2022\n\n Across Token Launch Proposal\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 214\n\n May 2022\n\n Across Treasury Committee Formation Proposal\n\n Proposals\n\n governance-updates\n\n Proposals\n\n 13\n\n Nov 2023\n\n Reduce ACX emissions for ACX LPs, WBTC LPs and wstETH/ACX LPs\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 11\n\n Aug 2024","tokens":710,"squid":"spider-09","role":"Bridge Spider","at":1791341613751,"hash":"be11963ccc9cc987a68c4ca7269b544655a40652"}
{"url":"https://akash.network/roadmap/aep-31","domain":"akash.network","title":"Credit Card Payments In Console","text":"Akash Network Roadmap Roadmap 2024 Q4 aep-31 Credit Card Payments In Console Final Motivation\nAkash Network has been live for almost 4 years and we have made incredible strides in decentralizing development, coordination, and funding.\nAs proposed in AKT 2.0, which received overwhelming support from the community, we proposed formally funding technical Research, Development, and Support done by the Akash Core Team and administered by Overclock Labs. As bolstered by proposals 211, 240, and 241, the Community Pool will continue to be well-funded as Akash Network accelerates its development.\nAs with all previous funding proposals, unused funds will be returned to the community.\nIntroduction\nAkash Network launched in 2020 and has experienced explosive growth over the last few years, partly due to being open-sourced fully in late 2023. Today, Akash Network organization has over 350 contributors building across 49 repositories coordinated and led by the Overclock Labs team through 11 special interest groups, working groups, and user groups. This achievement is monumental and should be celebrated, especially as we focus on the actual output: 2 major acquisitions, multiple web2 and web3 AI platform partnerships, university research collaborations, 11 network upgrades, and nearly 100 completed issues and over 200 discussions spanning more than four years.\nChallenge\nWith a growing codebase driven by an ever-larger feature set, Akash Network is more complex than ever and this complexity will only increase over time. As the community of contributors continues to grow, coordination becomes more challenging, costs rise, and development velocity slows. These challenges are further heightened for user-facing clients like the Akash Console as it is the Akash Supercloud’s direct user interface. Adoption starts and ends with user experience and the Akash Console is the tip of that spear.\nProposal\nSince 2016, Overclock Labs has fully borne the cost of development and support of Akash Network. Overclock Labs continues to fund most of these costs today and will continue to bear significant portions of the administrative, development, and marketing costs. Today, Overclock Labs is asking the community to help fund the design, development and testing efforts associated with the Payment features (“Frictionless Free Trial” and “Fiat Payment”) of the Akash Console 2.0 roadmap.\nResponsibilities & Requirements\n\nCommit time and resources towards development, integration, and ongoing maintenance of Akash Console and its customizations for Akash Network\nProvide support and code management to the community\nProvide responsible and open reporting on the conversion of AKT to USD\nBuilds tools necessary for the maintenance and support of Akash Console for Akash Network\nPossess deep, proven knowledge of the Akash Network codebase, which covers development work under these primary repositories\n\nAkash Console: https://github.com/akash-network/console\nAkashJS: https://github.com/akash-network/akashjs\nNode: http://github.com/akash-network/node\nProvider: http://github.com/akash-network/provider\nAkash-Api: http://github.com/akash-network/akash-api\n\nBe an experienced full stack development team with years of experience with React based applications\nPossess extensive open-source development experience on the Akash Network code base\nShould have extensive experience managing the community.\nShould be publicly known and respected within the Akash Community.\nShould have contributed to the Akash open-source repositories.\n\nSupplementing Overclock Labs’ treasury expenditures and Akash Network’s development efforts will help support more open-source contributors like zJ, Shimpa, HoomanDigital, and others and accelerate Akash Networks’ efforts to achieve cloud parity.\nBudget\nFor 2024, Overclock Labs will request 313,126.55.Thisrepresentsapproximately291,066,442.13. This proposal covers work started June 24, 2024, through the MVP’s launch, estimated to be, October 25, 2024. This percentage breakout is an aggregation of personnel multiplied by the amount of time spent on this effort vs other efforts. For example, the core engineering team may work on this project 75% of the time and other efforts 25% of the time.\nThis request is broken down as follows:\n\n AEP 2 - Payments [Console2.0]\n\n Total Cost\n\n Request from CP\n\n Estimated engineering hours\n\n4,920.00\n\n1,651.71\n\n Engineering rate per hour\n\n$100.02\n\n$93.38\n\n Engineering total cost\n\n$492,079.65\n\n$154,235.51\n\n Estimated support hours\n\n1,405.71\n\n365.49\n\n Support rate per hour\n\n$75.96\n\n$59.10\n\n Support total cost\n\n$106,775.99\n\n$21,599.26\n\n Labor Subtotal\n\n$598,855.64\n\n$175,834.76\n\n Operational Overage\n\n$89,828.35\n\n$26,375.21\n\n AKT Volatility Buffer (33.08%)*\n\n$198,101.45\n\n$58,166.14\n\n CA state tax (USA)\n\n$53,897.01\n\n$15,825.13\n\n Federal tax (USA)\n\n$125,759.68\n\n$36,925.30\n\n Tax, Vol & Overage Subtotal\n\n$467,586.49\n\n$137,291.78\n\n Grand Total\n\n$1,066,442.13\n\n$313,126.55\n\n*AKT volatility buffer\nThis buffer accounts for the historical daily volatility of AKT measured over the last 30 days leading up to September 30, 2024. By providing a more substantial buffer against potential downswings in AKT, we mitigate the need to request any budget shortfalls through subsequent proposals. In the event of excess funds above the US dollar amount of labor, taxes, and overage, all remaining AKT will be returned to the community promptly after completing the proposal.\nLimited Market Impact & Transparent Reporting\nLimited Market Impact\nOverclock Labs will custody the requested funds in a new, distinct wallet so that funds from any other source are not commingled.\nAll funds will be liquidated and managed in a manner that ensures minimal impact on the market. These funds will be managed with the same care and attention as all previous Community Funding Proposals with liquidations done in a fashion that will not adversely affect the market. In practice, the effort of this liquidation will add depth to the AKT market for buyers looking to enter.\nTransparent Reporting\nAll costs and records will be made publicly available through reports to ensure maximum transparency and accountability. Completion date: 11/4/2024 Created: 8/29/2024 Last Updated: 12/1/2024 Category: Interface Status: Final Authors: Anil Murty Cheng Wang Discussion on Github: \nLink\n Resolution: \nLink\n\nView next aep\n Buy Back and Burn AKTCredit card transactions in USD are converted to USDC to maintain exact balance equivalence, ensuring a smooth user experience. This approach, however, reduces AKT demand, potentially compromising Akash's security. To mitigate this, a protocol-imposed fee (Take Fee) is applied when using USDC for compute payments. AKT stakers determine this fee through governance proposals.","tokens":1690,"squid":"spider-03","role":"Compute Spider","at":1791341617365,"hash":"186f3c51f36240162744f53d44c25c480b0a4fa0"}
{"url":"https://akash.network/development/integrations/","domain":"akash.network","title":"Integrations - Developer Hub","text":"Integrations \nBuild on the Open Supercloud\n\nConnect your tools to a global marketplace of distributed GPUs.No sales calls. No waitlists. No Cloud Tax.\n Trusted by Leading Innovators Get Started Akash Deployment API Build platforms that accept credit cards. This layer handles the blockchain complexity for you. Explore Deployment API Akash Blockchain SDK Full protocol integration for self-custody wallets and custom bidding engines. Explore Blockchain SDK Blockchain REST/RPC Query raw network state via gRPC, REST, or RPC for real-time monitoring. Access Node Layer \nRazer Powers Viral AIInference on Akash\n\nTo scale its global AVA Mini campaign, Razer integrated its open-source AIKit platform with the Akash independent compute network. By pooling distributed high-performance consumer GPUs behind a single managed endpoint, the engineering team achieved reliable elastic scaling with zero manual infrastructure intervention.\n $0.01 per generated image 3.24s avg. end-to-end response time 15x lower inference costs than centralized APIs Read Case Study \"The future of AI isn't just better models – it's efficient infrastructure. With Razer AIKit, many use cases already run locally. With Akash Network, we extend that into a decentralised cloud to scale efficiently.\"QUYEN QUACHVice President of Software, Razer Prime Intellect Integrates Permissionless Akash GPUs Prime Intellect is on a mission to democratize AI development. By gathering a wide range of the best compute providers on the same platform, it's now easier than ever for AI developers to find the compute necessary to train, fine-tune, and run inference on AI models. This greatly improves the user experience of accessing compute, and especially permissionless compute from the Akash Supercloud. Read Case Study Decentralized AI Model Training on Akash With FLock.io Developing truly open and decentralized AI is one of society's most critical challenges. The networks, platforms, and clients we build will help guide this development, from open compute networks like Akash to platforms like FLock.io that make it easy to train and fine-tune AI models. Integrating these projects simplifies the user experience, enabling greater access that puts AI development directly in the hands of people around the world. Read Case Study \"Our partnership with Akash is a significant milestone for FLock.io.By integrating Akash's decentralized compute resources, we are empowering our community with enhanced access to permissionless, scalable, and cost-effective computing power.This collaboration not only strengthens our platform but also aligns with our mission to democratize AI development and ensure data privacy. Together, we are pushing the boundaries of what decentralized AI training can achieve.\"FLOCKJiahao Sun,Founder and CEO of Flock Integrate Akash into your applications with SDKs and APIs Blockchain SDK Documentation Description SDK Overview Official Go and JavaScript/TypeScript SDKs Official Go and JavaScript/TypeScript SDKs \nView Docs Quick Start Deploy your first application programmatically Deploy your first application programmatically \nView Docs API Reference Complete SDK documentation and methods Complete SDK documentation and methods \nView Docs SDK Examples Code examples for common tasks Code examples for common tasks \nView Docs AuthZ & Fee Grants Manage permissions and sponsored transactions Manage permissions and sponsored transactions \nView Docs Deployment REST API Documentation Description API Overview REST API for credit card deployments via Console REST API for credit card deployments via Console \nView Docs Getting Started Set up authentication and make your first API call Set up authentication and make your first API call \nView Docs API Reference Complete endpoint documentation Complete endpoint documentation \nView Docs Console API — Network Data Description Console API — Network Data Indexed data: providers, GPU, stats. Not a node. Indexed data: providers, GPU, stats. Not a node. \nView Docs Providers API Query provider details, specs, and availability Query provider details, specs, and availability \nView Docs GPU Availability Guide Find and filter GPU resources across providers Find and filter GPU resources across providers \nView Docs","tokens":1063,"squid":"spider-03","role":"Compute Spider","at":1791341634618,"hash":"d5d89228de06f620b89758d4709469fb2b5d0217"}
{"url":"https://forum.across.to/t/reduce-acx-emissions-for-acx-lps-wbtc-lps-and-wsteth-acx-lps/1977","domain":"forum.across.to","title":"Reduce ACX emissions for ACX LPs, WBTC LPs and wstETH/ACX LPs - Proposals - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n Reduce ACX emissions for ACX LPs, WBTC LPs and wstETH/ACX LPs \n\n Proposals\n\n treasury-funding\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 6\n min\n\n Aug 2024\n\n 1 / 13\n\n Aug 2024\n\n Aug 2024\n\n post by Kevin_UMA on Aug 15, 2024\n\n Kevin_UMA\n\n Title: Reduce ACX emissions for ACX LPs, WBTC LPs and wstETH/ACX LPs\nAuthors: ACX Emissions Committee (Kevin Chan, David Korpi, Ryan Carman, Dylan O’Reilly, Chase Coleman)\nStatus: Proposal\nRelated Discussions: ACX Emissions Committee, ACX Emissions Committee Framework Update, Reduce ACX emissions for Across ACX LP\nSummary:\nThe Across DAO should decrease ACX emissions for Across ACX LPs, Across WBTC LPs, and Balancer wstETH/ACX LPs. These liquidity pools are being rewarded a high APY in comparison to the utilization of the asset or the necessity of the liquidity. The ACX Emissions Committee (AEC) only has permissions and a framework to control ACX emissions for ETH, USDC, USDT, and DAI. Therefore, a separate proposal is required to modify emissions for the assets mentioned above. ACX emissions for ACX LPs, WBTC LPs, and wstETH/ACX LPs should be reduced by 50%, 30%, and 25% respectively.\nMotivation:\nThe Across DAO should optimally manage ACX emissions for all liquidity it incentivizes. The ACX Emissions Committee (AEC) accomplishes this using a transparent and restrictive framework to adjust emissions awarded to Across ETH, USDC, USDT, and DAI LPs. The framework monitors the utilization and comparable yield alternatives of each asset to make ACX emissions adjustments. Across ACX Lps and WBTC LPs sit outside of the AEC’s framework because these assets have limited yield alternatives to compare with outside of the Across protocol. Similarly, the Balancer wstETH/ACX LPs does not have equivalent variables that the AEC’s framework uses. As a result, managing the ACX emissions of these three LPs requires a separate DAO proposal given it is outside the scope of the AEC.\nThe Across DAO should decrease ACX emissions for Across ACX LPs, Across WBTC LPs, and Balancer wstETH/ACX LPs. These liquidity pools are being awarded a high APY in comparison to the utilization of the asset or the necessity of the liquidity.\nAcross ACX LP\nACX emissions for ACX LPs were initially set high to incentivize ACX airdrop recipients to not immediately sell their tokens and to get these token holders familiar with the reward locking mechanism. It’s been over 1.5 years since the launch of the token and the use of emissions in this way is not necessary. These emissions were reduced late last year, but a further reduction is now necessary. ACX utilization consistently sits close to zero given a lack of bridging needs (see Table 1). Yet, the emissions rate for the ACX LP is by far the highest at 26.7k ACX per day (see Table 3). The Across DAO should decrease ACX LP base emissions by 50% from 15k ACX per day to 7.5k ACX per day. (See Table 5 below for proposed changes.)\nAcross WBTC LP\nWBTC utilization on Across protocol has been relatively contained and has rarely exceeded 50% over the last few months (see Table 1). In comparison, USDT is more optimally utilized as its utilization has more frequently stayed above 50% and has reached over 80% on some occasions. The USDT serves bridge users well with only $6.6MM in total size in comparison to WBTC at $26.9MM which is about 4x bigger (see Table 2). This is driven by over 2x more emissions being paid to the WBTC LP (~8k ACX per day) vs the USDT LP (~3k ACX per day) - see Table 3. In addition, the WBTC APY is currently 5.27% which is very attractive considering DeFI lending protocols have consistently paid little to nothing. The WBTC LP can clearly be smaller in size. The Across DAO should decrease WBTC LP base emissions by 30% from 7.5k ACX per day to 5.25k ACX per day. (See Table 5 below for proposed changes.)\nBalancer wstETH/ACX LP\nThe Balancer wstETH/ACX LP is the second highest use of ACX emissions at 19k ACX per day (see Table 3). It is the only Reward Locking pool that still offers a 3x multiplier. As a result it pays the highest APY to LPs ranging from 20 to 52%! Offering these high ACX incentives may have been necessary at the launch of the token. However, Across protocol and the ACX token has gained brand recognition and these high rewards may not be needed. In addition, liquidity incentivized in this way may be less needed for two reasons\n\nThough modestly sized, Across DAO has close to $1MM of protocol owned liquidity through its proposal with Arrakis. The performance of this Uniswap v3 vault can be viewed here. If more liquidity is needed, Across DAO can continue to pursue this route and not pay emissions.\nACX is being listed in more centralized exchanges. Over the last few months Bitget, AscendEX, and Crypto.com have listed ACX. More recently, Coinbase has added ACX to its roadmap. Given this momentum, more exchange listings are expected. This would argue for less of a need to incentivize ACX DEX liquidity.\n\nACX liquidity on decentralized exchanges continues to be important and still represents a fair share of total volumes. However, the cost is high and the need for this has decreased. Therefore, a modest decrease in emissions here should be warranted. The Across DAO should decrease ACX emissions to the Balancer wstETH/ACX LP by 25% from 7k ACX per day to 5.25k ACX per day. (See Table 5 below for proposed changes.)\nTable 1 - ACX, WBTC, USDT Utilization\n1096×520 74.6 KB\nTable 2 - Across TVL of Liquidity Pools by Asset\n\nTable 3 - Current ACX Emission Rates\n752×270 14.5 KB\nTable 4 - Current Daily ACX Emissions Rate\n\nLiquidity Pool\nBase Emissions\nEffective Emissions with Multipliers\n\nAcross ACX\n15,000 ACX\n26,687 ACX\n\nAcross WBTC\n7,500 ACX\n8,032 ACX\n\nBPT wstETH/ACX\n7,000 ACX\n19,239 ACX\n\nTable 5 - Proposed Daily ACX Base Emissions Rate\n\nLiquidity Pool\nCurrent\nProposed\n\nAcross ACX\n15,000 ACX\n7,500 ACX\n\nAcross WBTC\n7,500 ACX\n5,250 ACX\n\nBPT wstETH/ACX\n7,000 ACX\n5,250 ACX\n\n(All data above is taken from the AEC Dune Dashboard.)\nSpecification & Implementation:\nThe Across DAO wallet controlled by ACX holders has admin rights to change the parameters of the Accelerating Distributor contract that controls ACX emissions and the Reward Locking program. The exact transactions to make these modifications can be put to a vote and executed on Snapshot via the oSnap module which is already implemented.\nThe proposed Snapshot vote and oSnap transaction will reflect a change in the following emission rates:\nAcross ACX LPs to ~7,500 ACX per day (from ~15,000 ACX per day currently)\nAcross WBTC LPs to ~5,250 ACX per day (from ~7,500 ACX per day currently)\nBalancer wstETH/ACX LPs to ~5,250 ACX per day (from ~7,000 ACX per day currently)\n(This is summarized in Table 5 above.)\nThe ACX Emissions Committee will monitor the impact of these changes on the performance of Across protocol. If there are signs that utilization in these assets are too high or more decentralized liquidity is needed in ACX then the AEC will take action to help rectify it.\nVoting:\n\n Should the Across DAO reduce ACX base emissions rates for Across ACX LPs, Across WBTC LPs, and Balancer wstETH/ACX LPs by 50%, 30%, and 25% respectively? The proposed changes are summarized in Table 5 above.\n\n 60%\n Yes\n\n 30%\n No\n\n 10%\n Abstain\n\n 10\n voters\n\n Closed Aug 2024\n\n Stop ACX Emissions on ACX LP\n\n Reduce ACX emissions for WBTC LPs\n\n Stop ACX Emissions on wstETH/ACX LP Balancer Pool\n\n 4\n\n 2\n\n read \n\n 6\n min\n\n post by Justin_J on Aug 15, 2024\n\n post by Kevin_UMA on Aug 15, 2024\n\n post by berry4144 on Aug 15, 2024\n\n post by gmsteele on Aug 17, 2024\n\n post by Kevin_UMA on Aug 17, 2024\n\n post by Bananachain on Aug 18, 2024\n\n post by arizonaice on Aug 21, 2024\n\n post by blkboxeconomist on Aug 21, 2024\n\n post by Kevin_UMA on Aug 21, 2024\n\n post by Bananachain on Aug 22, 2024\n\n post by x_momo on Aug 22, 2024\n\n 1 month later\n\n Closed on Sep 21, 2024\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Reduce ACX emissions for Across ACX LPs\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 8\n\n Nov 2023\n\n Reduce ACX emissions for WBTC LPs\n\n Active Proposals\n\n Active Proposals\n\n Aug 2025\n\n Stop ACX Emissions on ACX LP\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 4\n\n May 2025\n\n Stop ACX Emissions on wstETH/ACX LP Balancer Pool\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 2\n\n May 2025\n\n ACX Emissions Committee\n\n Proposals\n\n governance-updates\n\n Proposals\n\n Dec 2023","tokens":3604,"squid":"spider-09","role":"Bridge Spider","at":1791341634670,"hash":"28958d9450ba2e4ce85cb9dbb57aab01aa6631dc"}
{"url":"https://docs.phantom.com/best-practices/launching-a-dapp","domain":"docs.phantom.com","title":"Go-live checklist - Phantom developer documentation","text":"​Phantom Portal setup\nPhantom Portal is not accepting new applications at this time. New sign-ups for Phantom Connect SDK access and new app submissions to the Phantom app directory are paused. Existing Portal apps and App IDs are not affected.\n​Account created in Phantom Portal\nGo to phantom.com/portal and sign in with Google or Apple.\nPhantom Portal overview →\n​App created and configured in Phantom Portal\nConfirm that your app is fully set up in Phantom Portal:\n\nThe app has been created in Phantom Portal.\nBranding and app details have been added.\nThe domain has been verified.\nAllowed origin URLs have been configured.\nAn App ID has been generated.\nThe app access mode is set to PUBLIC.\n\nGet started →\n​Integration testing\nValidate that your integration works correctly across common user flows:\n\nWallet connection and authentication work through Phantom Connect.\nTransaction signing works on all supported networks.\nSpending limit behavior is correct, if you’re using embedded wallets.\nError handling works as expected for rejected transactions or insufficient funds.\nThe app behaves correctly across browsers and devices.\n\n​Security\nVerify that basic security requirements are met:\n\nHTTPS is enforced across all production URLs.\nNo private keys or sensitive data are logged.\nAll transactions clearly display the correct amounts and intent to users.\n\nMobile web debugging →\n​Common issues\n​Transactions fail\nIf transactions fail during testing or after launch, common causes include the following:\n\nInsufficient funds to cover gas or rent.\nContract errors or RPC-related failures.\n\n​App doesn’t show in the Explore tab\nIf your app isn’t visible in the Explore tab, it’s usually because of the following reason:\n\nCause: Your app profile changes are still under review.\nSolution: Wait for Phantom to approve the updates. Once approved, changes appear immediately.\n\n​Need help?\nWas this page helpful?","tokens":477,"squid":"spider-10","role":"Tooling Spider","at":1791341654787,"hash":"6fd1eb9da59d545761b010fbf65a27583f8ebe2a"}
{"url":"https://eips.ethereum.org/EIPS/eip-712","domain":"eips.ethereum.org","title":"EIP-712: Typed structured data hashing and signing","text":"🎉 Final\n\n Standards Track: Interface\n\n EIP-712: Typed structured data hashing and signing\n\n A procedure for hashing and signing of typed structured data as opposed to just bytestrings.\n\n Authors\n Remco Bloemen (@Recmo), Leonid Logvinov (@LogvinovLeon), Jacob Evans (@dekz)\n\n Created\n 2017-09-12\n\n Requires\n\n EIP-155, \n\n EIP-191\n\n Abstract\n\nThis is a standard for hashing and signing of typed structured data as opposed to just bytestrings. It includes a\n\n theoretical framework for correctness of encoding functions,\n specification of structured data similar to and compatible with Solidity structs,\n safe hashing algorithm for instances of those structures,\n safe inclusion of those instances in the set of signable messages,\n an extensible mechanism for domain separation,\n new RPC call eth_signTypedData, and\n an optimized implementation of the hashing algorithm in EVM.\n\nIt does not include replay protection.\n\n Motivation\n\nSigning data is a solved problem if all we care about are bytestrings. Unfortunately in the real world we care about complex meaningful messages. Hashing structured data is non-trivial and errors result in loss of the security properties of the system.\n\nAs such, the adage “don’t roll your own crypto” applies. Instead, a peer-reviewed well-tested standard method needs to be used. This EIP aims to be that standard.\n\nThis EIP aims to improve the usability of off-chain message signing for use on-chain. We are seeing growing adoption of off-chain message signing as it saves gas and reduces the number of transactions on the blockchain. Currently signed messages are an opaque hex string displayed to the user with little context about the items that make up the message.\n\nHere we outline a scheme to encode data along with its structure which allows it to be displayed to the user for verification when signing. Below is an example of what a user could be shown when signing a message according to the present proposal.\n\n Specification\n\nThe set of signable messages is extended from transactions and bytestrings 𝕋 ∪ 𝔹⁸ⁿ to also include structured data 𝕊. The new set of signable messages is thus 𝕋 ∪ 𝔹⁸ⁿ ∪ 𝕊. They are encoded to bytestrings suitable for hashing and signing as follows:\n\n encode(transaction : 𝕋) = RLP_encode(transaction)\n encode(message : 𝔹⁸ⁿ) = \"\\x19Ethereum Signed Message:\\n\" ‖ len(message) ‖ message where len(message) is the non-zero-padded ascii-decimal encoding of the number of bytes in message.\n encode(domainSeparator : 𝔹²⁵⁶, message : 𝕊) = \"\\x19\\x01\" ‖ domainSeparator ‖ hashStruct(message) where domainSeparator and hashStruct(message) are defined below.\n\nThis encoding is deterministic because the individual components are. The encoding is injective because the three cases always differ in first byte. (RLP_encode(transaction) does not start with \\x19.)\n\nThe encoding is compliant with ERC-191. The ‘version byte’ is fixed to 0x01, the ‘version specific data’ is the 32-byte domain separator domainSeparator and the ‘data to sign’ is the 32-byte hashStruct(message).\n\n Definition of typed structured data 𝕊\n\nTo define the set of all structured data, we start with defining acceptable types. Like ABIv2 these are closely related to Solidity types. It is illustrative to adopt Solidity notation to explain the definitions. The standard is specific to the Ethereum Virtual Machine, but aims to be agnostic to higher level languages. Example:\n\nstruct Mail {\n address from;\n address to;\n string contents;\n}\n\nDefinition: A struct type has valid identifier as name and contains zero or more member variables. Member variables have a member type and a name.\n\nDefinition: A member type can be either an atomic type, a dynamic type or a reference type.\n\nDefinition: The atomic types are bytes1 to bytes32, uint8 to uint256, int8 to int256, bool and address. These correspond to their definition in Solidity. Note that there are no aliases uint and int. Note that contract addresses are always plain address. Fixed point numbers are not supported by the standard. Future versions of this standard may add new atomic types.\n\nDefinition: The dynamic types are bytes and string. These are like the atomic types for the purpose of type declaration, but their treatment in encoding is different.\n\nDefinition: The reference types are arrays and structs. Arrays are either fixed size or dynamic and denoted by Type[n] or Type[] respectively. Structs are references to other structs by their name. The standard supports recursive struct types.\n\nDefinition: The set of structured typed data 𝕊 contains all the instances of all the struct types.\n\n Definition of hashStruct\n\nThe hashStruct function is defined as\n\n hashStruct(s : 𝕊) = keccak256(typeHash ‖ encodeData(s)) where typeHash = keccak256(encodeType(typeOf(s)))\n\nNote: The typeHash is a constant for a given struct type and does not need to be runtime computed.\n\n Definition of encodeType\n\nThe type of a struct is encoded as name ‖ \"(\" ‖ member₁ ‖ \",\" ‖ member₂ ‖ \",\" ‖ … ‖ memberₙ \")\" where each member is written as type ‖ \" \" ‖ name. For example, the above Mail struct is encoded as Mail(address from,address to,string contents).\n\nIf the struct type references other struct types (and these in turn reference even more struct types), then the set of referenced struct types is collected, sorted by name and appended to the encoding. An example encoding is Transaction(Person from,Person to,Asset tx)Asset(address token,uint256 amount)Person(address wallet,string name).\n\n Definition of encodeData\n\nThe encoding of a struct instance is enc(value₁) ‖ enc(value₂) ‖ … ‖ enc(valueₙ), i.e. the concatenation of the encoded member values in the order that they appear in the type. Each encoded member value is exactly 32-byte long.\n\nThe atomic values are encoded as follows: Boolean false and true are encoded as uint256 values 0 and 1 respectively. Addresses are encoded as uint160. Integer values are sign-extended to 256-bit and encoded in big endian order. bytes1 to bytes31 are arrays with a beginning (index 0) and an end (index length - 1), they are zero-padded at the end to bytes32 and encoded in beginning to end order. This corresponds to their encoding in ABI v1 and v2.\n\nThe dynamic values bytes and string are encoded as a keccak256 hash of their contents.\n\nThe array values are encoded as the keccak256 hash of the concatenated encodeData of their contents (i.e. the encoding of SomeType[5] is identical to that of a struct containing five members of type SomeType).\n\nThe struct values are encoded recursively as hashStruct(value). This is undefined for cyclical data.\n\n Definition of domainSeparator\n\ndomainSeparator = hashStruct(eip712Domain)\n\nwhere the type of eip712Domain is a struct named EIP712Domain with one or more of the below fields. Protocol designers only need to include the fields that make sense for their signing domain. Unused fields are left out of the struct type.\n\n string name the user readable name of signing domain, i.e. the name of the DApp or the protocol.\n string version the current major version of the signing domain. Signatures from different versions are not compatible.\n uint256 chainId the EIP-155 chain id. The user-agent should refuse signing if it does not match the currently active chain.\n address verifyingContract the address of the contract that will verify the signature. The user-agent may do contract specific phishing prevention.\n bytes32 salt a disambiguating salt for the protocol. This can be used as a domain separator of last resort.\n\nFuture extensions to this standard can add new fields with new user-agent behaviour constraints. User-agents are free to use the provided information to inform/warn users or refuse signing. Dapp implementers should not add private fields, new fields should be proposed through the EIP process.\n\nThe EIP712Domain fields should be the order as above, skipping any absent fields. Future field additions must be in alphabetical order and come after the above fields. User-agents should accept fields in any order as specified by the EIP712Domain type.\n\n Specification of the eth_signTypedData JSON RPC\n\nThe method eth_signTypedData is added to the Ethereum JSON-RPC. The method parallels eth_sign.\n\n eth_signTypedData\n\nThe sign method calculates an Ethereum specific signature with: sign(keccak256(\"\\x19\\x01\" ‖ domainSeparator ‖ hashStruct(message))), as defined above.\n\nNote: the address to sign with must be unlocked.\n\n Parameters\n\n Address - 20 Bytes - Address of the account that will sign the messages.\n TypedData - Typed structured data to be signed.\n\nTyped data is a JSON object containing type information, domain separator parameters and the message object. Below is the json-schema definition for TypedData param.\n\n{\n type: 'object',\n properties: {\n types: {\n type: 'object',\n properties: {\n EIP712Domain: {type: 'array'},\n },\n additionalProperties: {\n type: 'array',\n items: {\n type: 'object',\n properties: {\n name: {type: 'string'},\n type: {type: 'string'}\n },\n required: ['name', 'type']\n }\n },\n required: ['EIP712Domain']\n },\n primaryType: {type: 'string'},\n domain: {type: 'object'},\n message: {type: 'object'}\n },\n required: ['types', 'primaryType', 'domain', 'message']\n}\n\n Returns\n\nDATA: Signature. As in eth_sign it is a hex encoded 65 byte array starting with 0x. It encodes the r, s and v parameters from appendix F of the yellow paper in big-endian format. Bytes 0…32 contain the r parameter, bytes 32…64 the s parameter and the last byte the v parameter. Note that the v parameter includes the chain id as specified in EIP-155.\n\n Example\n\nRequest:\n\ncurl -X POST --data '{\"jsonrpc\":\"2.0\",\"method\":\"eth_signTypedData\",\"params\":[\"0xCD2a3d9F938E13CD947Ec05AbC7FE734Df8DD826\", {\"types\":{\"EIP712Domain\":[{\"name\":\"name\",\"type\":\"string\"},{\"name\":\"version\",\"type\":\"string\"},{\"name\":\"chainId\",\"type\":\"uint256\"},{\"name\":\"verifyingContract\",\"type\":\"address\"}],\"Person\":[{\"name\":\"name\",\"type\":\"string\"},{\"name\":\"wallet\",\"type\":\"address\"}],\"Mail\":[{\"name\":\"from\",\"type\":\"Person\"},{\"name\":\"to\",\"type\":\"Person\"},{\"name\":\"contents\",\"type\":\"string\"}]},\"primaryType\":\"Mail\",\"domain\":{\"name\":\"Ether Mail\",\"version\":\"1\",\"chainId\":1,\"verifyingContract\":\"0xCcCCccccCCCCcCCCCCCcCcCccCcCCCcCcccccccC\"},\"message\":{\"from\":{\"name\":\"Cow\",\"wallet\":\"0xCD2a3d9F938E13CD947Ec05AbC7FE734Df8DD826\"},\"to\":{\"name\":\"Bob\",\"wallet\":\"0xbBbBBBBbbBBBbbbBbbBbbbbBBbBbbbbBbBbbBBbB\"},\"contents\":\"Hello, Bob!\"}}],\"id\":1}'\n\nResult:\n\n{\n \"id\":1,\n \"jsonrpc\": \"2.0\",\n \"result\": \"0x4355c47d63924e8a72e509b65029052eb6c299d53a04e167c5775fd466751c9d07299936d304c153f6443dfa05f40ff007d72911b6f72307f996231605b915621c\"\n}\n\nAn example how to use Solidity ecrecover to verify the signature calculated with eth_signTypedData can be found in the Example.js. The contract is deployed on the testnet Ropsten and Rinkeby.\n\n personal_signTypedData\n\nThere also should be a corresponding personal_signTypedData method which accepts the password for an account as the last argument.\n\n Specification of the Web3 API\n\nTwo methods are added to Web3.js version 1 that parallel the web3.eth.sign and web3.eth.personal.sign methods.\n\n web3.eth.signTypedData\n\nweb3.eth.signTypedData(typedData, address [, callback])\n\nSigns typed data using a specific account. This account needs to be unlocked.\n\n Parameters\n\n Object - Domain separator and typed data to sign. Structured according to the JSON-Schema specified above in the eth_signTypedData JSON RPC call.\n String|Number - Address to sign data with. Or an address or index of a local wallet in :ref:web3.eth.accounts.wallet <eth_accounts_wallet>.\n Function - (optional) Optional callback, returns an error object as first parameter and the result as second.\n\nNote: The 2. address parameter can also be an address or index from the web3.eth.accounts.wallet <eth_accounts_wallet>. It will then sign locally using the private key of this account.\n\n Returns\n\nPromise returns String - The signature as returned by eth_signTypedData.\n\n Example\n\nSee the eth_signTypedData JSON-API example above for the value of typedData.\n\nweb3.eth.signTypedData(typedData, \"0xCD2a3d9F938E13CD947Ec05AbC7FE734Df8DD826\")\n.then(console.log);\n> \"0x4355c47d63924e8a72e509b65029052eb6c299d53a04e167c5775fd466751c9d07299936d304c153f6443dfa05f40ff007d72911b6f72307f996231605b915621c\"\n\n web3.eth.personal.signTypedData\n\nweb3.eth.personal.signTypedData(typedData, address, password [, callback])\n\nIdentical to web3.eth.signTypedData except for an additional password parameter analogous to web3.eth.personal.sign.\n\n Rationale\n\nThe encode function is extended with a new case for the new types. The first byte of the encoding distinguishes the cases. For the same reason it is not safe to start immediately with the domain separator or a typeHash. While hard, it may be possible to construct a typeHash that also happens to be a prefix of a valid RLP encoded transaction.\n\nThe domain separator prevents collision of otherwise identical structures. It is possible that two DApps come up with an identical structure like Transfer(address from,address to,uint256 amount) that should not be compatible. By introducing a domain separator the DApp developers are guaranteed that there can be no signature collision.\n\nThe domain separator also allows for multiple distinct signatures use-cases on the same struct instance within a given DApp. In the previous example, perhaps signatures from both from and to are required. By providing two distinct domain separators these signatures can be distinguished from each other.\n\nAlternative 1: Use the target contract address as domain separator. This solves the first problem, contracts coming up with identical types, but does not address the second use-case. The standard does suggest implementors to use the target contract address where this is appropriate.\n\nThe function hashStruct starts with a typeHash to separate types. By giving different types a different prefix the encodeData function only has to be injective within a given type. It is okay for encodeData(a) to equal encodeData(b) as long as typeOf(a) is not typeOf(b).\n\n Rationale for typeHash\n\nThe typeHash is designed to turn into a compile time constant in Solidity. For example:\n\nbytes32 constant MAIL_TYPEHASH = keccak256(\n \"Mail(address from,address to,string contents)\");\n\nFor the type hash several alternatives were considered and rejected for the reasons:\n\nAlternative 2: Use ABIv2 function signatures. bytes4 is not enough to be collision resistant. Unlike function signatures, there is negligible runtime cost incurred by using longer hashes.\n\nAlternative 3: ABIv2 function signatures modified to be 256-bit. While this captures type info, it does not capture any of the semantics other than the function. This is already causing a practical collision between ERC-20’s and ERC-721’s transfer(address,uint256), where in the former the uint256 refers to an amount and the latter to a unique id. In general ABIv2 favors compatibility where a hashing standard should prefer incompatibility.\n\nAlternative 4: 256-bit ABIv2 signatures extended with parameter names and struct names. The Mail example from above would be encoded as Mail(Person(string name,address wallet) from,Person(string name,address wallet) to,string contents). This is longer than the proposed solution. And indeed, the length of the string can grow exponentially in the length of the input (consider struct A{B a;B b;}; struct B {C a;C b;}; …). It also does not allow a recursive struct type (consider struct List {uint256 value; List next;}).\n\nAlternative 5: Include natspec documentation. This would include even more semantic information in the schemaHash and further reduces chances of collision. It makes extending and amending documentation a breaking changes, which contradicts common assumptions. It also makes the schemaHash mechanism very verbose.\n\n Rationale for encodeData\n\nThe encodeData is designed to allow easy implementation of hashStruct in Solidity:\n\nfunction hashStruct(Mail memory mail) pure returns (bytes32 hash) {\n return keccak256(abi.encode(\n MAIL_TYPEHASH,\n mail.from,\n mail.to,\n keccak256(mail.contents)\n ));\n}\n\nit also allows for an efficient in-place implementation in EVM\n\nfunction hashStruct(Mail memory mail) pure returns (bytes32 hash) {\n\n // Compute sub-hashes\n bytes32 typeHash = MAIL_TYPEHASH;\n bytes32 contentsHash = keccak256(mail.contents);\n\n assembly {\n // Back up select memory\n let temp1 := mload(sub(mail, 32))\n let temp2 := mload(add(mail, 128))\n\n // Write typeHash and sub-hashes\n mstore(sub(mail, 32), typeHash)\n mstore(add(mail, 64), contentsHash)\n\n // Compute hash\n hash := keccak256(sub(mail, 32), 128)\n\n // Restore memory\n mstore(sub(mail, 32), temp1)\n mstore(add(mail, 64), temp2)\n }\n}\n\nThe in-place implementation makes strong but reasonable assumptions on the memory layout of structs in memory. Specifically it assumes structs are not allocated below address 32, that members are stored in order, that all values are padded to 32-byte boundaries, and that dynamic and reference types are stored as a 32-byte pointers.\n\nAlternative 6: Tight packing. This is the default behaviour in Solidity when calling keccak256 with multiple arguments. It minimizes the number of bytes to be hashed but requires complicated packing instructions in EVM to do so. It does not allow in-place computation.\n\nAlternative 7: ABIv2 encoding. Especially with the upcoming abi.encode it should be easy to use abi.encode as the encodeData function. The ABIv2 standard by itself fails the determinism security criteria. There are several valid ABIv2 encodings of the same data. ABIv2 does not allow in-place computation.\n\nAlternative 8: Leave typeHash out of hashStruct and instead combine it with the domain separator. This is more efficient, but then the semantics of the Solidity keccak256 hash function are not injective.\n\nAlternative 9: Support cyclical data structures. The current standard is optimized for tree-like data structures and undefined for cyclical data structures. To support cyclical data a stack containing the path to the current node needs to be maintained and a stack offset substituted when a cycle is detected. This is prohibitively more complex to specify and implement. It also breaks composability where the hashes of the member values are used to construct the hash of the struct (the hash of the member values would depend on the path). It is possible to extend the standard in a compatible way to define hashes of cyclical data.\n\nSimilarly, a straightforward implementation is sub-optimal for directed acyclic graphs. A simple recursion through the members can visit the same node twice. Memoization can optimize this.\n\n Rationale for domainSeparator\n\nSince different domains have different needs, an extensible scheme is used where the DApp specifies a EIP712Domain struct type and an instance eip712Domain which it passes to the user-agent. The user-agent can then apply different verification measures depending on the fields that are there.\n\n Backwards Compatibility\n\nThe RPC calls, web3 methods and SomeStruct.typeHash parameter are currently undefined. Defining them should not affect the behaviour of existing DApps.\n\nThe Solidity expression keccak256(someInstance) for an instance someInstance of a struct type SomeStruct is valid syntax. It currently evaluates to the keccak256 hash of the memory address of the instance. This behaviour should be considered dangerous. In some scenarios it will appear to work correctly but in others it will fail determinism and/or injectiveness. DApps that depend on the current behaviour should be considered dangerously broken.\n\n Test Cases\n\nAn example contract can be found in Example.sol and an example implementation of signing in JavaScript in Example.js\n\n Security Considerations\n\n Replay attacks\n\nThis standard is only about signing messages and verifying signatures. In many practical applications, signed messages are used to authorize an action, for example an exchange of tokens. It is very important that implementers make sure the application behaves correctly when it sees the same signed message twice. For example, the repeated message should be rejected or the authorized action should be idempotent. How this is implemented is specific to the application and out of scope for this standard.\n\n Frontrunning attacks\n\nThe mechanism for reliably broadcasting a signature is application-specific and out of scope for this standard. When the signature is broadcast to a blockchain for use in a contract, the application has to be secure against frontrunning attacks. In this kind of attack, an attacker intercepts the signature and submits it to the contract before the original intended use takes place. The application should behave correctly when the signature is submitted first by an attacker, for example by rejecting it or simply producing exactly the same effect as intended by the signer.\n\n Copyright\n\nCopyright and related rights waived via CC0.\n\n Citation\n Please cite this document as:\n\n Remco Bloemen (@Recmo), Leonid Logvinov (@LogvinovLeon), Jacob Evans (@dekz), \"EIP-712: Typed structured data hashing and signing,\" Ethereum Improvement Proposals, no. 712, September 2017. Available: https://eips.ethereum.org/EIPS/eip-712.","tokens":5302,"squid":"spider-05","role":"Spec Spider","at":1791341656901,"hash":"b893f965a6e7350a03b788fb6b92d2012f404f28"}
{"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":"spider-05","role":"Spec Spider","at":1791341670846,"hash":"e6c54306de058c0f1e67333347423b1068d19ee3"}
{"url":"https://eips.ethereum.org/EIPS/eip-777","domain":"eips.ethereum.org","title":"ERC-777: Token Standard","text":"🎉 Final\n\n Standards Track: ERC\n\n ERC-777: Token Standard\n\n Authors\n Jacques Dafflon <mail@0xjac.com>, Jordi Baylina <jordi@baylina.cat>, Thomas Shababi <tom@truelevel.io>\n\n Created\n 2017-11-20\n\n Requires\n\n EIP-1820\n\n Simple Summary\n\nThis EIP defines standard interfaces and behaviors for token contracts.\n\n Abstract\n\nThis standard defines a new way to interact with a token contract while remaining backward compatible with ERC-20.\n\nIt defines advanced features to interact with tokens.\nNamely, operators to send tokens on behalf of another address—contract or regular account—and\nsend/receive hooks to offer token holders more control over their tokens.\n\nIt takes advantage of ERC-1820 to find out whether and where to notify contracts and regular addresses\nwhen they receive tokens as well as to allow compatibility with already-deployed contracts.\n\n Motivation\n\nThis standard tries to improve upon the widely used ERC-20 token standard.\nThe main advantages of this standard are:\n\n Uses the same philosophy as Ether in that tokens are sent with send(dest, value, data).\n\n Both contracts and regular addresses can control and reject which token they send\nby registering a tokensToSend hook.\n(Rejection is done by reverting in the hook function.)\n\n Both contracts and regular addresses can control and reject which token they receive\nby registering a tokensReceived hook.\n(Rejection is done by reverting in the hook function.)\n\n The tokensReceived hook allows to send tokens to a contract and notify it in a single transaction,\nunlike ERC-20 which requires a double call (approve/transferFrom) to achieve this.\n\n The holder can “authorize” and “revoke” operators which can send tokens on their behalf.\nThese operators are intended to be verified contracts\nsuch as an exchange, a cheque processor or an automatic charging system.\n\n Every token transaction contains data and operatorData bytes fields\nto be used freely to pass data from the holder and the operator, respectively.\n\n It is backward compatible with wallets that do not contain the tokensReceived hook function\nby deploying a proxy contract implementing the tokensReceived hook for the wallet.\n\n Specification\n\n ERC777Token (Token Contract)\n\ninterface ERC777Token {\n function name() external view returns (string memory);\n function symbol() external view returns (string memory);\n function totalSupply() external view returns (uint256);\n function balanceOf(address holder) external view returns (uint256);\n function granularity() external view returns (uint256);\n\n function defaultOperators() external view returns (address[] memory);\n function isOperatorFor(\n address operator,\n address holder\n ) external view returns (bool);\n function authorizeOperator(address operator) external;\n function revokeOperator(address operator) external;\n\n function send(address to, uint256 amount, bytes calldata data) external;\n function operatorSend(\n address from,\n address to,\n uint256 amount,\n bytes calldata data,\n bytes calldata operatorData\n ) external;\n\n function burn(uint256 amount, bytes calldata data) external;\n function operatorBurn(\n address from,\n uint256 amount,\n bytes calldata data,\n bytes calldata operatorData\n ) external;\n\n event Sent(\n address indexed operator,\n address indexed from,\n address indexed to,\n uint256 amount,\n bytes data,\n bytes operatorData\n );\n event Minted(\n address indexed operator,\n address indexed to,\n uint256 amount,\n bytes data,\n bytes operatorData\n );\n event Burned(\n address indexed operator,\n address indexed from,\n uint256 amount,\n bytes data,\n bytes operatorData\n );\n event AuthorizedOperator(\n address indexed operator,\n address indexed holder\n );\n event RevokedOperator(address indexed operator, address indexed holder);\n}\n\nThe token contract MUST implement the above interface.\nThe implementation MUST follow the specifications described below.\n\nThe token contract MUST register the ERC777Token interface with its own address via ERC-1820.\n\n This is done by calling the setInterfaceImplementer function on the ERC-1820 registry\nwith the token contract address as both the address and the implementer\nand the keccak256 hash of ERC777Token (0xac7fbab5f54a3ca8194167523c6753bfeb96a445279294b6125b68cce2177054)\nas the interface hash.\n\nIf the contract has a switch to enable or disable ERC-777 functions, every time the switch is triggered,\nthe token MUST register or unregister the ERC777Token interface for its own address accordingly via ERC1820.\nUnregistering implies calling the setInterfaceImplementer with the token contract address as the address,\nthe keccak256 hash of ERC777Token as the interface hash and 0x0 as the implementer.\n(See Set An Interface For An Address in ERC-1820 for more details.)\n\nWhen interacting with the token contract, all amounts and balances MUST be unsigned integers.\nI.e. internally, all values are stored as a denomination of 1E-18 of a token.\nThe display denomination—to display any amount to the end user—MUST\nbe 1018 of the internal denomination.\n\nIn other words, the internal denomination is similar to a wei\nand the display denomination is similar to an ether.\nIt is equivalent to an ERC-20’s decimals function returning 18.\nE.g. if a token contract returns a balance of 500,000,000,000,000,000 (0.5×1018) for a user,\nthe user interface MUST show 0.5 tokens to the user.\nIf the user wishes to send 0.3 tokens,\nthe contract MUST be called with an amount of 300,000,000,000,000,000 (0.3×1018).\n\nUser Interfaces which are generated programmatically from the ABI of the token contract\nMAY use and display the internal denomination.\nBut this MUST be made clear, for example by displaying the uint256 type.\n\n View Functions\n\nThe view functions detailed below MUST be implemented.\n\nname function\n\nfunction name() external view returns (string memory)\n\nGet the name of the token, e.g., \"MyToken\".\n\n identifier: 06fdde03\nreturns: Name of the token.\n\nsymbol function\n\nfunction symbol() external view returns (string memory)\n\nGet the symbol of the token, e.g., \"MYT\".\n\n identifier: 95d89b41\nreturns: Symbol of the token.\n\ntotalSupply function\n\nfunction totalSupply() external view returns (uint256)\n\nGet the total number of minted tokens.\n\nNOTE: The total supply MUST be equal to the sum of the balances of all addresses—as\nreturned by the balanceOf function.\n\nNOTE: The total supply MUST be equal to the sum of all the minted tokens\nas defined in all the Minted events minus the sum of all the burned tokens as defined in all the Burned events.\n\n identifier: 18160ddd\nreturns: Total supply of tokens currently in circulation.\n\nbalanceOf function\n\nfunction balanceOf(address holder) external view returns (uint256)\n\nGet the balance of the account with address holder.\n\nThe balance MUST be zero (0) or higher.\n\n identifier: 70a08231\nparameters\nholder: Address for which the balance is returned.\n\n returns: Amount of tokens held by holder in the token contract.\n\ngranularity function\n\nfunction granularity() external view returns (uint256)\n\nGet the smallest part of the token that’s not divisible.\n\nIn other words, the granularity is the smallest amount of tokens (in the internal denomination)\nwhich MAY be minted, sent or burned at any time.\n\nThe following rules MUST be applied regarding the granularity:\n\n The granularity value MUST be set at creation time.\n\n The granularity value MUST NOT be changed, ever.\n\n The granularity value MUST be greater than or equal to 1.\n\n All balances MUST be a multiple of the granularity.\n\n Any amount of tokens (in the internal denomination) minted, sent or burned\nMUST be a multiple of the granularity value.\n\n Any operation that would result in a balance that’s not a multiple of the granularity value\nMUST be considered invalid, and the transaction MUST revert.\n\nNOTE: Most tokens SHOULD be fully partition-able.\nI.e., this function SHOULD return 1 unless there is a good reason for not allowing any fraction of the token.\n\n identifier: 556f0dc7\nreturns: The smallest non-divisible part of the token.\n\nNOTE: defaultOperators and isOperatorFor are also view functions,\ndefined under the operators for consistency.\n\nERC-20 compatibility requirement:\nThe decimals of the token MUST always be 18.\nFor a pure ERC-777 token the ERC-20 decimals function is OPTIONAL,\nand its existence SHALL NOT be relied upon when interacting with the token contract.\n(The decimal value of 18 is implied.)\nFor an ERC-20 compatible token, the decimals function is REQUIRED and MUST return 18.\n(In ERC-20, the decimals function is OPTIONAL.\nIf the function is not present, the decimals value is not clearly defined and may be assumed to be 0.\nHence for compatibility reasons, decimals MUST be implemented for ERC-20 compatible tokens.)\n\n Operators\n\nAn operator is an address which is allowed to send and burn tokens on behalf of some holder.\n\nWhen an address becomes an operator for a holder, an AuthorizedOperator event MUST be emitted.\nThe AuthorizedOperator’s operator (topic 1) and holder (topic 2)\nMUST be the addresses of the operator and the holder respectively.\n\nWhen a holder revokes an operator, a RevokedOperator event MUST be emitted.\nThe RevokedOperator’s operator (topic 1) and holder (topic 2)\nMUST be the addresses of the operator and the holder respectively.\n\nNOTE: A holder MAY have multiple operators at the same time.\n\nThe token MAY define default operators.\nA default operator is an implicitly authorized operator for all holders.\nAuthorizedOperator events MUST NOT be emitted when defining the default operators.\nThe rules below apply to default operators:\n\n The token contract MUST define default operators at creation time.\n\n The default operators MUST be invariants. I.e., the token contract MUST NOT add or remove default operators ever.\n\n AuthorizedOperator events MUST NOT be emitted when defining default operators.\n\n A holder MUST be allowed to revoke a default operator\n(unless the holder is the default operator in question).\n\n A holder MUST be allowed to re-authorize a previously revoked default operator.\n\n When a default operator is explicitly authorized or revoked for a specific holder,\nan AuthorizedOperator or RevokedOperator event (respectively) MUST be emitted.\n\nThe following rules apply to any operator:\n\n An address MUST always be an operator for itself. Hence an address MUST NOT ever be revoked as its own operator.\n\n If an address is an operator for a holder, isOperatorFor MUST return true.\n\n If an address is not an operator for a holder, isOperatorFor MUST return false.\n\n The token contract MUST emit an AuthorizedOperator event with the correct values\nwhen a holder authorizes an address as its operator as defined in the\nAuthorizedOperator Event.\n\n The token contract MUST emit a RevokedOperator event with the correct values\nwhen a holder revokes an address as its operator as defined in the\nRevokedOperator Event.\n\nNOTE: A holder MAY authorize an already authorized operator.\nAn AuthorizedOperator MUST be emitted each time.\n\nNOTE: A holder MAY revoke an already revoked operator.\nA RevokedOperator MUST be emitted each time.\n\nAuthorizedOperator event \n\nevent AuthorizedOperator(address indexed operator, address indexed holder)\n\nIndicates the authorization of operator as an operator for holder.\n\nNOTE: This event MUST NOT be emitted outside of an operator authorization process.\n\n parameters\noperator: Address which became an operator of holder.\nholder: Address of a holder which authorized the operator address as an operator.\n\nRevokedOperator event \n\nevent RevokedOperator(address indexed operator, address indexed holder)\n\nIndicates the revocation of operator as an operator for holder.\n\nNOTE: This event MUST NOT be emitted outside of an operator revocation process.\n\n parameters\noperator: Address which was revoked as an operator of holder.\nholder: Address of a holder which revoked the operator address as an operator.\n\nThe defaultOperators, authorizeOperator, revokeOperator and isOperatorFor functions described below\nMUST be implemented to manage operators.\nToken contracts MAY implement other functions to manage operators.\n\ndefaultOperators function \n\nfunction defaultOperators() external view returns (address[] memory)\n\nGet the list of default operators as defined by the token contract.\n\nNOTE: If the token contract does not have any default operators, this function MUST return an empty list.\n\n identifier: 06e48538\nreturns: List of addresses of all the default operators.\n\nauthorizeOperator function\n\nfunction authorizeOperator(address operator) external\n\nSet a third party operator address as an operator of msg.sender to send and burn tokens on its behalf.\n\nNOTE: The holder (msg.sender) is always an operator for itself.\nThis right SHALL NOT be revoked.\nHence this function MUST revert if it is called to authorize the holder (msg.sender)\nas an operator for itself (i.e. if operator is equal to msg.sender).\n\n identifier: 959b8c3f\nparameters\noperator: Address to set as an operator for msg.sender.\n\nrevokeOperator function\n\nfunction revokeOperator(address operator) external\n\nRemove the right of the operator address to be an operator for msg.sender\nand to send and burn tokens on its behalf.\n\nNOTE: The holder (msg.sender) is always an operator for itself.\nThis right SHALL NOT be revoked.\nHence this function MUST revert if it is called to revoke the holder (msg.sender)\nas an operator for itself (i.e., if operator is equal to msg.sender).\n\n identifier: fad8b32a\nparameters\noperator: Address to rescind as an operator for msg.sender.\n\nisOperatorFor function \n\nfunction isOperatorFor(\n address operator,\n address holder\n) external view returns (bool)\n\nIndicate whether the operator address is an operator of the holder address.\n\n identifier: d95b6371\nparameters\noperator: Address which may be an operator of holder.\nholder: Address of a holder which may have the operator address as an operator.\n\n returns: true if operator is an operator of holder and false otherwise.\n\nNOTE: To know which addresses are operators for a given holder,\none MUST call isOperatorFor with the holder for each default operator\nand parse the AuthorizedOperator, and RevokedOperator events for the holder in question.\n\n Sending Tokens\n\nWhen an operator sends an amount of tokens from a holder to a recipient\nwith the associated data and operatorData, the token contract MUST apply the following rules:\n\n Any authorized operator MAY send tokens to any recipient (except to 0x0).\n\n The balance of the holder MUST be decreased by the amount.\n\n The balance of the recipient MUST be increased by the amount.\n\n The balance of the holder MUST be greater or equal to the amount—such\nthat its resulting balance is greater or equal to zero (0) after the send.\n\n The token contract MUST emit a Sent event with the correct values as defined in the Sent Event.\n\n The operator MAY include information in the operatorData.\n\n The token contract MUST call the tokensToSend hook of the holder\nif the holder registers an ERC777TokensSender implementation via ERC-1820.\n\n The token contract MUST call the tokensReceived hook of the recipient\nif the recipient registers an ERC777TokensRecipient implementation via ERC-1820.\n\n The data and operatorData MUST be immutable during the entire send process—hence\nthe same data and operatorData MUST be used to call both hooks and emit the Sent event.\n\nThe token contract MUST revert when sending in any of the following cases:\n\n The operator address is not an authorized operator for the holder.\n\n The resulting holder balance or recipient balance after the send\nis not a multiple of the granularity defined by the token contract.\n\n The recipient is a contract, and it does not implement the ERC777TokensRecipient interface via ERC-1820.\n\n The address of the holder or the recipient is 0x0.\n\n Any of the resulting balances becomes negative, i.e. becomes less than zero (0).\n\n The tokensToSend hook of the holder reverts.\n\n The tokensReceived hook of the recipient reverts.\n\nThe token contract MAY send tokens from many holders, to many recipients, or both. In this case:\n\n The previous send rules MUST apply to all the holders and all the recipients.\n The sum of all the balances incremented MUST be equal to the total sent amount.\n The sum of all the balances decremented MUST be equal to the total sent amount.\n A Sent event MUST be emitted for every holder and recipient pair with the corresponding amount for each pair.\n The sum of all the amounts from the Sent event MUST be equal to the total sent amount.\n\nNOTE: Mechanisms such as applying a fee on a send is considered as a send to multiple recipients:\nthe intended recipient and the fee recipient.\n\nNOTE: Movements of tokens MAY be chained.\nFor example, if a contract upon receiving tokens sends them further to another address.\nIn this case, the previous send rules apply to each send, in order.\n\nNOTE: Sending an amount of zero (0) tokens is valid and MUST be treated as a regular send.\n\nImplementation Requirement:\n\n The token contract MUST call the tokensToSend hook before updating the state.\n The token contract MUST call the tokensReceived hook after updating the state.\nI.e., tokensToSend MUST be called first,\nthen the balances MUST be updated to reflect the send,\nand finally tokensReceived MUST be called afterward.\nThus a balanceOf call within tokensToSend returns the balance of the address before the send\nand a balanceOf call within tokensReceived returns the balance of the address after the send.\n\nNOTE: The data field contains information provided by the holder—similar\nto the data field in a regular ether send transaction.\nThe tokensToSend() hook, the tokensReceived(), or both\nMAY use the information to decide if they wish to reject the transaction.\n\nNOTE: The operatorData field is analogous to the data field except it SHALL be provided by the operator.\n\nThe operatorData MUST only be provided by the operator.\nIt is intended more for logging purposes and particular cases.\n(Examples include payment references, cheque numbers, countersignatures and more.)\nIn most of the cases the recipient would ignore the operatorData, or at most, it would log the operatorData.\n\nSent event \n\nevent Sent(\n address indexed operator,\n address indexed from,\n address indexed to,\n uint256 amount,\n bytes data,\n bytes operatorData\n)\n\nIndicate a send of amount of tokens from the from address to the to address by the operator address.\n\nNOTE: This event MUST NOT be emitted outside of a send or an ERC-20 transfer process.\n\n parameters\noperator: Address which triggered the send.\nfrom: Holder whose tokens were sent.\nto: Recipient of the tokens.\namount: Number of tokens sent.\ndata: Information provided by the holder.\noperatorData: Information provided by the operator.\n\nThe send and operatorSend functions described below MUST be implemented to send tokens.\nToken contracts MAY implement other functions to send tokens.\n\nsend function\n\nfunction send(address to, uint256 amount, bytes calldata data) external\n\nSend the amount of tokens from the address msg.sender to the address to.\n\nThe operator and the holder MUST both be the msg.sender.\n\n identifier: 9bd9bbc6\nparameters\nto: Recipient of the tokens.\namount: Number of tokens to send.\ndata: Information provided by the holder.\n\noperatorSend function\n\nfunction operatorSend(\n address from,\n address to,\n uint256 amount,\n bytes calldata data,\n bytes calldata operatorData\n) external\n\nSend the amount of tokens on behalf of the address from to the address to.\n\nReminder: If the operator address is not an authorized operator of the from address,\nthen the send process MUST revert.\n\nNOTE: from and msg.sender MAY be the same address.\nI.e., an address MAY call operatorSend for itself.\nThis call MUST be equivalent to send with the addition\nthat the operator MAY specify an explicit value for operatorData\n(which cannot be done with the send function).\n\n identifier: 62ad1b83\nparameters\nfrom: Holder whose tokens are being sent.\nto: Recipient of the tokens.\namount: Number of tokens to send.\ndata: Information provided by the holder.\noperatorData: Information provided by the operator.\n\n Minting Tokens\n\nMinting tokens is the act of producing new tokens.\nERC-777 intentionally does not define specific functions to mint tokens.\nThis intent comes from the wish not to limit the use of the ERC-777 standard\nas the minting process is generally specific for every token.\n\nNonetheless, the rules below MUST be respected when minting for a recipient:\n\n Tokens MAY be minted for any recipient address (except 0x0).\n\n The total supply MUST be increased by the amount of tokens minted.\n\n The balance of 0x0 MUST NOT be decreased.\n\n The balance of the recipient MUST be increased by the amount of tokens minted.\n\n The token contract MUST emit a Minted event with the correct values as defined in the Minted Event.\n\n The token contract MUST call the tokensReceived hook of the recipient\nif the recipient registers an ERC777TokensRecipient implementation via ERC-1820.\n\n The data and operatorData MUST be immutable during the entire mint process—hence\nthe same data and operatorData MUST be used to call the tokensReceived hook and emit the Minted event.\n\nThe token contract MUST revert when minting in any of the following cases:\n\n The resulting recipient balance after the mint is not a multiple of the granularity defined by the token contract.\n The recipient is a contract, and it does not implement the ERC777TokensRecipient interface via ERC-1820.\n The address of the recipient is 0x0.\n The tokensReceived hook of the recipient reverts.\n\nNOTE: The initial token supply at the creation of the token contract MUST be considered as minting\nfor the amount of the initial supply to the address(es) receiving the initial supply.\nThis means one or more Minted events must be emitted\nand the tokensReceived hook of the recipient(s) MUST be called.\n\nERC-20 compatibility requirement:\nWhile a Sent event MUST NOT be emitted when minting,\nif the token contract is ERC-20 backward compatible,\na Transfer event with the from parameter set to 0x0 SHOULD be emitted as defined in the ERC-20 standard.\n\nThe token contract MAY mint tokens for multiple recipients at once. In this case:\n\n The previous mint rules MUST apply to all the recipients.\n The sum of all the balances incremented MUST be equal to the total minted amount.\n A Minted event MUST be emitted for every recipient with the corresponding amount for each recipient.\n The sum of all the amounts from the Minted event MUST be equal to the total minted amount.\n\nNOTE: Minting an amount of zero (0) tokens is valid and MUST be treated as a regular mint.\n\nNOTE: While during a send or a burn, the data is provided by the holder, it is inapplicable for a mint.\nIn this case the data MAY be provided by the token contract or the operator,\nfor example to ensure a successful minting to a holder expecting specific data.\n\nNOTE: The operatorData field contains information provided by the operator—similar\nto the data field in a regular ether send transaction.\nThe tokensReceived() hooks MAY use the information to decide if it wish to reject the transaction.\n\nMinted event \n\nevent Minted(\n address indexed operator,\n address indexed to,\n uint256 amount,\n bytes data,\n bytes operatorData\n)\n\nIndicate the minting of amount of tokens to the to address by the operator address.\n\nNOTE: This event MUST NOT be emitted outside of a mint process.\n\n parameters\noperator: Address which triggered the mint.\nto: Recipient of the tokens.\namount: Number of tokens minted.\ndata: Information provided for the recipient.\noperatorData: Information provided by the operator.\n\n Burning Tokens\n\nBurning tokens is the act of destroying existing tokens.\nERC-777 explicitly defines two functions to burn tokens (burn and operatorBurn).\nThese functions facilitate the integration of the burning process in wallets and dapps.\nHowever, the token contract MAY prevent some or all holders from burning tokens for any reason.\nThe token contract MAY also define other functions to burn tokens.\n\nThe rules below MUST be respected when burning the tokens of a holder:\n\n Tokens MAY be burned from any holder address (except 0x0).\n\n The total supply MUST be decreased by the amount of tokens burned.\n\n The balance of 0x0 MUST NOT be increased.\n\n The balance of the holder MUST be decreased by amount of tokens burned.\n\n The token contract MUST emit a Burned event with the correct values as defined in the Burned Event.\n\n The token contract MUST call the tokensToSend hook of the holder\nif the holder registers an ERC777TokensSender implementation via ERC-1820.\n\n The operatorData MUST be immutable during the entire burn process—hence\nthe same operatorData MUST be used to call the tokensToSend hook and emit the Burned event.\n\nThe token contract MUST revert when burning in any of the following cases:\n\n The operator address is not an authorized operator for the holder.\n\n The resulting holder balance after the burn is not a multiple of the granularity\ndefined by the token contract.\n\n The balance of holder is inferior to the amount of tokens to burn\n(i.e., resulting in a negative balance for the holder).\n\n The address of the holder is 0x0.\n\n The tokensToSend hook of the holder reverts.\n\nERC-20 compatibility requirement:\nWhile a Sent event MUST NOT be emitted when burning;\nif the token contract is ERC-20 enabled, a Transfer event with the to parameter set to 0x0 SHOULD be emitted.\nThe ERC-20 standard does not define the concept of burning tokens, but this is a commonly accepted practice.\n\nThe token contract MAY burn tokens for multiple holders at once. In this case:\n\n The previous burn rules MUST apply to each holders.\n The sum of all the balances decremented MUST be equal to the total burned amount.\n A Burned event MUST be emitted for every holder with the corresponding amount for each holder.\n The sum of all the amounts from the Burned event MUST be equal to the total burned amount.\n\nNOTE: Burning an amount of zero (0) tokens is valid and MUST be treated as a regular burn.\n\nNOTE: The data field contains information provided by the holder—similar\nto the data field in a regular ether send transaction.\nThe tokensToSend() hook, the tokensReceived(), or both\nMAY use the information to decide if they wish to reject the transaction.\n\nNOTE: The operatorData field is analogous to the data field except it SHALL be provided by the operator.\n\nBurned event \n\nevent Burned(\n address indexed operator,\n address indexed from,\n uint256 amount,\n bytes data,\n bytes operatorData\n);\n\nIndicate the burning of amount of tokens from the from address by the operator address.\n\nNOTE: This event MUST NOT be emitted outside of a burn process.\n\n parameters\noperator: Address which triggered the burn.\nfrom: Holder whose tokens were burned.\namount: Number of tokens burned.\ndata: Information provided by the holder.\noperatorData: Information provided by the operator.\n\nThe burn and operatorBurn functions described below MUST be implemented to burn tokens.\nToken contracts MAY implement other functions to burn tokens.\n\nburn function\n\nfunction burn(uint256 amount, bytes calldata data) external\n\nBurn the amount of tokens from the address msg.sender.\n\nThe operator and the holder MUST both be the msg.sender.\n\n identifier: fe9d9303\nparameters\namount: Number of tokens to burn.\ndata: Information provided by the holder.\n\noperatorBurn function\n\nfunction operatorBurn(\n address from,\n uint256 amount,\n bytes calldata data,\n bytes calldata operatorData\n) external\n\nBurn the amount of tokens on behalf of the address from.\n\nReminder: If the operator address is not an authorized operator of the from address,\nthen the burn process MUST revert.\n\n identifier: fc673c4f\nparameters\nfrom: Holder whose tokens will be burned.\namount: Number of tokens to burn.\ndata: Information provided by the holder.\noperatorData: Information provided by the operator.\n\nNOTE: The operator MAY pass any information via operatorData.\nThe operatorData MUST only be provided by the operator.\n\nNOTE: from and msg.sender MAY be the same address.\nI.e., an address MAY call operatorBurn for itself.\nThis call MUST be equivalent to burn\nwith the addition that the operator MAY specify an explicit value for operatorData\n(which cannot be done with the burn function).\n\n ERC777TokensSender And The tokensToSend Hook\n\nThe tokensToSend hook notifies of any request to decrement the balance (send and burn) for a given holder.\nAny address (regular or contract) wishing to be notified of token debits from their address\nMAY register the address of a contract implementing the ERC777TokensSender interface described below via ERC-1820.\n\n This is done by calling the setInterfaceImplementer function on the ERC-1820 registry\nwith the holder address as the address,\nthe keccak256 hash of ERC777TokensSender\n(0x29ddb589b1fb5fc7cf394961c1adf5f8c6454761adf795e67fe149f658abe895) as the interface hash,\nand the address of the contract implementing the ERC777TokensSender as the implementer.\n\ninterface ERC777TokensSender {\n function tokensToSend(\n address operator,\n address from,\n address to,\n uint256 amount,\n bytes calldata userData,\n bytes calldata operatorData\n ) external;\n}\n\nNOTE: A regular address MAY register a different address—the address of a contract—implementing\nthe interface on its behalf.\nA contract MAY register either its address or the address of another contract\nbut said address MUST implement the interface on its behalf.\n\ntokensToSend\n\nfunction tokensToSend(\n address operator,\n address from,\n address to,\n uint256 amount,\n bytes calldata userData,\n bytes calldata operatorData\n) external\n\nNotify a request to send or burn (if to is 0x0) an amount tokens from the from address to the to address\nby the operator address.\n\nNOTE: This function MUST NOT be called outside of a burn, send or ERC-20 transfer process.\n\n identifier: 75ab9782\nparameters\noperator: Address which triggered the balance decrease (through sending or burning).\nfrom: Holder whose tokens were sent.\nto: Recipient of the tokens for a send (or 0x0 for a burn).\namount: Number of tokens the holder balance is decreased by.\ndata: Information provided by the holder.\noperatorData: Information provided by the operator.\n\nThe following rules apply when calling the tokensToSend hook:\n\n The tokensToSend hook MUST be called for every send and burn processes.\n\n The tokensToSend hook MUST be called before the state is updated—i.e. before the balance is decremented.\n\n operator MUST be the address which triggered the send or burn process.\n\n from MUST be the address of the holder whose tokens are sent or burned.\n\n to MUST be the address of the recipient which receives the tokens for a send.\n\n to MUST be 0x0 for a burn.\n\n amount MUST be the number of tokens the holder sent or burned.\n\n data MUST contain the extra information (if any) provided to the send or the burn process.\n\n operatorData MUST contain the extra information provided by the address\nwhich triggered the decrease of the balance (if any).\n\n The holder MAY block a send or burn process by reverting.\n(I.e., reject the withdrawal of tokens from its account.)\n\nNOTE: Multiple holders MAY use the same implementation of ERC777TokensSender.\n\nNOTE: An address can register at most one implementation at any given time for all ERC-777 tokens.\nHence the ERC777TokensSender MUST expect to be called by different token contracts.\nThe msg.sender of the tokensToSend call is expected to be the address of the token contract.\n\nERC-20 compatibility requirement:\nThis hook takes precedence over ERC-20 and MUST be called (if registered)\nwhen calling ERC-20’s transfer and transferFrom event.\nWhen called from a transfer, operator MUST be the same value as the from.\nWhen called from a transferFrom, operator MUST be the address which issued the transferFrom call.\n\n ERC777TokensRecipient And The tokensReceived Hook\n\nThe tokensReceived hook notifies of any increment of the balance (send and mint) for a given recipient.\nAny address (regular or contract) wishing to be notified of token credits to their address\nMAY register the address of a contract implementing the ERC777TokensRecipient interface described below via ERC-1820.\n\n This is done by calling the setInterfaceImplementer function on the ERC-1820 registry\nwith the recipient address as the address,\nthe keccak256 hash of ERC777TokensRecipient\n(0xb281fc8c12954d22544db45de3159a39272895b169a852b314f9cc762e44c53b) as the interface hash,\nand the address of the contract implementing the ERC777TokensRecipient as the implementer.\n\ninterface ERC777TokensRecipient {\n function tokensReceived(\n address operator,\n address from,\n address to,\n uint256 amount,\n bytes calldata data,\n bytes calldata operatorData\n ) external;\n}\n\nIf the recipient is a contract, which has not registered an ERC777TokensRecipient implementation;\nthen the token contract:\n\n MUST revert if the tokensReceived hook is called from a mint or send call.\n\n SHOULD continue processing the transaction\nif the tokensReceived hook is called from an ERC-20 transfer or transferFrom call.\n\nNOTE: A regular address MAY register a different address—the address of a contract—implementing\nthe interface on its behalf.\nA contract MUST register either its address or the address of another contract\nbut said address MUST implement the interface on its behalf.\n\ntokensReceived\n\nfunction tokensReceived(\n address operator,\n address from,\n address to,\n uint256 amount,\n bytes calldata data,\n bytes calldata operatorData\n) external\n\nNotify a send or mint (if from is 0x0) of amount tokens from the from address to the to address\nby the operator address.\n\nNOTE: This function MUST NOT be called outside of a mint, send or ERC-20 transfer process.\n\n identifier: 0023de29\nparameters\noperator: Address which triggered the balance increase (through sending or minting).\nfrom: Holder whose tokens were sent (or 0x0 for a mint).\nto: Recipient of the tokens.\namount: Number of tokens the recipient balance is increased by.\ndata: Information provided by the holder.\noperatorData: Information provided by the operator.\n\nThe following rules apply when calling the tokensReceived hook:\n\n The tokensReceived hook MUST be called for every send and mint processes.\n\n The tokensReceived hook MUST be called after the state is updated—i.e. after the balance is incremented.\n\n operator MUST be the address which triggered the send or mint process.\n\n from MUST be the address of the holder whose tokens are sent for a send.\n\n from MUST be 0x0 for a mint.\n\n to MUST be the address of the recipient which receives the tokens.\n\n amount MUST be the number of tokens the recipient sent or minted.\n\n data MUST contain the extra information (if any) provided to the send or the mint process.\n\n operatorData MUST contain the extra information provided by the address\nwhich triggered the increase of the balance (if any).\n\n The holder MAY block a send or mint process by reverting.\n(I.e., reject the reception of tokens.)\n\nNOTE: Multiple holders MAY use the same implementation of ERC777TokensRecipient.\n\nNOTE: An address can register at most one implementation at any given time for all ERC-777 tokens.\nHence the ERC777TokensRecipient MUST expect to be called by different token contracts.\nThe msg.sender of the tokensReceived call is expected to be the address of the token contract.\n\nERC-20 compatibility requirement:\nThis hook takes precedence over ERC-20 and MUST be called (if registered)\nwhen calling ERC-20’s transfer and transferFrom event.\nWhen called from a transfer, operator MUST be the same value as the from.\nWhen called from a transferFrom, operator MUST be the address which issued the transferFrom call.\n\n Note On Gas Consumption\n\nDapps and wallets SHOULD first estimate the gas required when sending, minting, or burning tokens—using\neth_estimateGas—to avoid running out of gas during the transaction.\n\n Logo\n\n Image\n\n Color\n beige\n white\n light grey\n dark grey\n black\n\n Hex\n #C99D66\n #FFFFFF\n #EBEFF0\n #3C3C3D\n #000000\n\nThe logo MAY be used, modified and adapted to promote valid ERC-777 token implementations\nand ERC-777 compliant technologies such as wallets and dapps.\n\nERC-777 token contract authors MAY create a specific logo for their token based on this logo.\n\nThe logo MUST NOT be used to advertise, promote or associate in any way technology—such\nas tokens—which is not ERC-777 compliant.\n\nThe logo for the standard can be found in the /assets/eip-777/logo folder in SVG and PNG formats.\nThe PNG version of the logo offers a few sizes in pixels.\nIf needed, other sizes MAY be created by converting from SVG into PNG.\n\n Rationale\n\nThe principal intent for this standard is\nto solve some of the shortcomings of ERC-20 while maintaining backward compatibility with ERC-20,\nand avoiding the problems and vulnerabilities of EIP-223.\n\nBelow are the rationales for the decisions regarding the main aspects of the standards.\n\nNOTE: Jacques Dafflon (0xjac), one of the authors of the standard,\nconjointly wrote his master thesis on the standard,\nwhich goes in more details than could reasonably fit directly within the standard,\nand can provide further clarifications regarding certain aspects or decisions.\n\n Lifecycle\n\nMore than just sending tokens, ERC-777 defines the entire lifecycle of a token,\nstarting with the minting process, followed by the sending process and terminating with the burn process.\n\nHaving a lifecycle clearly defined is important for consistency and accuracy,\nespecially when value is derived from scarcity.\nIn contrast when looking at some ERC-20 tokens, a discrepancy can be observed\nbetween the value returned by the totalSupply and the actual circulating supply,\nas the standard does not clearly define a process to create and destroy tokens.\n\n Data\n\nThe mint, send and burn processes can all make use of a data and operatorData fields\nwhich are passed to any movement (mint, send or burn).\nThose fields may be empty for simple use cases,\nor they may contain valuable information related to the movement of tokens,\nsimilar to information attached to a bank transfer by the sender or the bank itself.\n\nThe use of a data field is equally present in other standard proposals such as EIP-223,\nand was requested by multiple members of the community who reviewed this standard.\n\n Hooks\n\nIn most cases, ERC-20 requires two calls to safely transfer tokens to a contract without locking them.\nA call from the sender, using the approve function\nand a call from the recipient using transferFrom.\nFurthermore, this requires extra communication between the parties which is not clearly defined.\nFinally, holders can get confused between transfer and approve/transferFrom.\nUsing the former to transfer tokens to a contract will most likely result in locked tokens.\n\nHooks allow streamlining of the sending process and offer a single way to send tokens to any recipient.\nThanks to the tokensReceived hook, contracts are able to react and prevent locking tokens upon reception.\n\n Greater Control For Holders\n\nThe tokensReceived hook also allows holders to reject the reception of some tokens.\nThis gives greater control to holders who can accept or reject incoming tokens based on some parameters,\nfor example located in the data or operatorData fields.\n\nFollowing the same intentions and based on suggestions from the community,\nthe tokensToSend hook was added to give control over and prevent the movement of outgoing tokens.\n\n ERC-1820 Registry\n\nThe ERC-1820 Registry allows holders to register their hooks.\nOther alternatives were examined beforehand to link hooks and holders.\n\nThe first was for hooks to be defined at the sender’s or recipient’s address.\nThis approach is similar to EIP-223 which proposes a tokenFallback function on recipient contracts\nto be called when receiving tokens,\nbut improves on it by relying on ERC-165 for interface detection.\nWhile straightforward to implement, this approach imposes several limitations.\nIn particular, the sender and recipient must be contracts in order to provide their implementation of the hooks.\nPreventing externally owned addresses to benefit from hooks.\nExisting contracts have a strong probability not to be compatible,\nas they undoubtedly were unaware and do not define the new hooks.\nConsequently existing smart contract infrastructure such as multisig wallets\nwhich potentially hold large amounts of ether and tokens would need to be migrated to new updated contracts.\n\nThe second approach considered was to use ERC-672 which offered pseudo-introspection for addresses using reverse-ENS.\nHowever, this approach relied heavily on ENS, on top of which reverse lookup would need to be implemented.\nAnalysis of this approach promptly revealed a certain degree of complexity and security concerns\nwhich would transcend the benefits of approach.\n\nThe third solution—used in this standard—is to rely on a unique registry\nwhere any address can register the addresses of contracts implementing the hooks on its behalf.\nThis approach has the advantage that externally owned accounts and contracts can benefit from hooks,\nincluding existing contracts which can rely on hooks deployed on proxy contracts.\n\nThe decision was made to keep this registry in a separate EIP,\nas to not over complicate this standard.\nMore importantly, the registry is designed in a flexible fashion,\nsuch that other EIPs and smart contract infrastructures can benefit from it\nfor their own use cases, outside the realm of ERC-777 and tokens.\nThe first proposal for this registry was ERC-820.\nUnfortunately, issues emanating from upgrades in the Solidity language to versions 0.5 and above\nresulted in a bug in a separated part of the registry, which required changes.\nThis was discovered right after the last call period.\nAttempts made to avoid creating a separate EIP, such as ERC-820a, were rejected.\nHence the standard for the registry used for ERC-777 became ERC-1820.\nERC-1820 and ERC-820 are functionally equivalent. ERC-1820 simply contains the fix for newer versions of Solidity.\n\n Operators\n\nThe standard defines the concept of operators as any address which moves tokens.\nWhile intuitively every address moves its own tokens,\nseparating the concepts of holder and operator allows for greater flexibility.\nPrimarily, this originates from the fact that the standard defines a mechanism for holders\nto let other addresses become their operators.\nMoreover, unlike the approve calls in ERC-20 where the role of an approved address is not clearly defined,\nERC-777 details the intent of and interactions with operators,\nincluding an obligation for operators to be approved,\nand an irrevocable right for any holder to revoke operators.\n\n Default Operators\n\nDefault operators were added based on community demand for pre-approved operators.\nThat is operators which are approved for all holders by default.\nFor obvious security reasons, the list of default operators is defined at the token contract creation time,\nand cannot be changed.\nAny holder still has the right to revoke default operators.\nOne of the obvious advantages of default operators is to allow ether-less movements of tokens.\nDefault operators offer other usability advantages,\nsuch as allowing token providers to offer functionality in a modular way,\nand to reduce the complexity for holders to use features provided through operators.\n\n Backward Compatibility\n\nThis EIP does not introduce backward incompatibilities and is backward compatible with the older ERC-20 token standard.\n\nThis EIP does not use transfer and transferFrom and uses send and operatorSend\nto avoid confusion and mistakes when deciphering which token standard is being used.\n\nThis standard allows the implementation of ERC-20 functions transfer, transferFrom, approve and allowance\nalongside to make a token fully compatible with ERC-20.\n\nThe token MAY implement decimals() for backward compatibility with ERC-20.\nIf implemented, it MUST always return 18.\n\nTherefore a token contract MAY implement both ERC-20 and ERC-777 in parallel.\nThe specification of the view functions (such as name, symbol, balanceOf, totalSupply) and internal data\n(such as the mapping of balances) overlap without problems.\nNote however that the following functions are mandatory in ERC-777 and MUST be implemented:\nname, symbol balanceOf and totalSupply\n(decimals is not part of the ERC-777 standard).\n\nThe state-modifying functions from both standards are decoupled and can operate independently from each other.\nNote that ERC-20 functions SHOULD be limited to only being called from old contracts.\n\nIf the token implements ERC-20,\nit MUST register the ERC20Token interface with its own address via ERC-1820.\nThis is done by calling the setInterfaceImplementer function on the ERC-1820 registry\nwith the token contract address as both the address and the implementer\nand the keccak256 hash of ERC20Token (0xaea199e31a596269b42cdafd93407f14436db6e4cad65417994c2eb37381e05a)\nas the interface hash.\n\nIf the contract has a switch to enable or disable ERC-20 functions, every time the switch is triggered,\nthe token MUST register or unregister the ERC20Token interface for its own address accordingly via ERC1820.\nUnregistering implies calling the setInterfaceImplementer with the token contract address as the address,\nthe keccak256 hash of ERC20Token as the interface hash and 0x0 as the implementer.\n(See Set An Interface For An Address in ERC-1820 for more details.)\n\nThe difference for new contracts implementing ERC-20 is that\ntokensToSend and tokensReceived hooks take precedence over ERC-20.\nEven with an ERC-20 transfer and transferFrom call, the token contract MUST check via ERC-1820\nif the from and the to address implement tokensToSend and tokensReceived hook respectively.\nIf any hook is implemented, it MUST be called.\nNote that when calling ERC-20 transfer on a contract, if the contract does not implement tokensReceived,\nthe transfer call SHOULD still be accepted even if this means the tokens will probably be locked.\n\nThe table below summarizes the different actions the token contract MUST take\nwhen sending, minting and transferring token via ERC-777 and ERC-20:\n\n ERC1820\n to address\n ERC777 Sending And Minting\n ERC20 transfer/transferFrom\n\n ERC777TokensRecipientregistered\n\n regular address\n\n MUST call tokensReceived\n\n contract\n\n ERC777TokensRecipientnot registered\n\n regular address\n continue\n\n contract\n MUST revert\n SHOULD continue1\n\n 1.\nThe transaction SHOULD continue for clarity as ERC20 is not aware of hooks.\nHowever, this can result in accidentally locked tokens.\nIf avoiding accidentally locked tokens is paramount, the transaction MAY revert.\n\nThere is no particular action to take if tokensToSend is not implemented.\nThe movement MUST proceed and only be canceled if another condition is not respected\nsuch as lack of funds or a revert in tokensReceived (if present).\n\nDuring a send, mint and burn, the respective Sent, Minted and Burned events MUST be emitted.\nFurthermore, if the token contract declares that it implements ERC20Token via ERC-1820,\nthe token contract SHOULD emit a Transfer event for minting and burning\nand MUST emit a Transfer event for sending (as specified in the ERC-20 standard).\nDuring an ERC-20’s transfer or transferFrom functions, a valid Sent event MUST be emitted.\n\nHence for any movement of tokens, two events MAY be emitted:\nan ERC-20 Transfer and an ERC-777 Sent, Minted or Burned (depending on the type of movement).\nThird-party developers MUST be careful not to consider both events as separate movements.\nAs a general rule, if an application considers the token as an ERC20 token,\nthen only the Transfer event MUST be taken into account.\nIf the application considers the token as an ERC777 token,\nthen only the Sent, Minted and Burned events MUST be considered.\n\n Test Cases\n\nThe repository with the reference implementation contains all the tests.\n\n Implementation\n\nThe GitHub repository 0xjac/ERC777 contains the reference implementation.\nThe reference implementation is also available via npm and can be installed with npm install erc777.\n\n Copyright\n\nCopyright and related rights waived via CC0.\n\n Citation\n Please cite this document as:\n\n Jacques Dafflon <mail@0xjac.com>, Jordi Baylina <jordi@baylina.cat>, Thomas Shababi <tom@truelevel.io>, \"ERC-777: Token Standard,\" Ethereum Improvement Proposals, no. 777, November 2017. Available: https://eips.ethereum.org/EIPS/eip-777.","tokens":12060,"squid":"spider-05","role":"Spec Spider","at":1791341680644,"hash":"14c61acdf21399bd52a6d66201b064a85d4545c0"}
{"url":"https://phantom.com/privacy","domain":"phantom.com","title":"Privacy Policy","text":"Privacy PolicyLast updated: July 7, 2026Phantom Technologies, Inc. (“we”, “us” or “our”) values your privacy. In this Privacy Policy (“Policy”), we describe how we collect, use, and disclose information that we obtain about individuals that use our website at https://phantom.com, any subdomains, mobile applications and browser extensions, including their functionalities, (collectively, the “Functionality”), and how we use and disclose that information.Your use of the Functionality, and any dispute over privacy, is subject to this Policy (including any applicable changes) and our Terms of Use, including its applicable limitations on damages and provisions for the resolution of disputes.OverviewPrivacy is core to Phantom’s mission and values. We take appropriate steps to preserve user privacy and aim to be as transparent as possible with you regarding the treatment of any data we collect.Phantom does not require you to provide your name, email address, tax ID, or phone number to use the Functionality. To enable some opt-in functionality, you must provide certain legally required personal information to Phantom’s third-party partner. Phantom itself will not store this personal information in its own systems.Phantom will never use your IP address for marketing or advertising purposes other than to comply with jurisdictional legal requirements and our systems are not designed to associate your IP address with potentially identifying information such as your wallet address, username or email address.Phantom may use location data to ensure that marketing communications are not disseminated to individuals in jurisdictions where the Functionalities are not offered or are otherwise unavailable.For even more privacy, users have the option to opt-out of our analytics.This Policy will be updated whenever there are changes to Phantom’s privacy practices or applicable law.The Information We CollectWe collect information about you directly from you and from third parties, as well as automatically through your use of our Functionality.Information We Collect Directly From YouYou may browse the Functionality without registering with us or submitting personal information, however certain information is collected from you as described below and for the purposes set out below.Any username or avatar you choose to create in connection with your account, including the images or media you upload to mint your own collectible.Your email, phone number or other contact information as well as other data and information related to your use of the Functionality (to the extent that you provide it to us).If you choose to use certain opt-in Functionality, our third-party service providers may process your Know Your Customer (KYC) information on our behalf. This information includes your legal name, date of birth, Social Security number, government-issued identification, contact information, and biometric data. Our service providers collect and process biometric data on our behalf; we do not have access to biometric data. In certain limited circumstances, we may act as a data controller with respect to your KYC information for the specific purpose of enabling the sharing of such information with other third-party partners you want to do business with through our platform, and only upon your explicit direction and consent to do so. We do not maintain, store or retain this information in our own systems.If you use Phantom Cash or other payment features, we collect the last four digits of your bank account number and the last four digits of your payment card(s) to enable you to identify and select between payment methods and to detect and prevent fraud. We also collect payment method type and brand (such as through our third-party onramp integrations) to diagnose payment failures. We work with a third-party payment processor to enable these features and that third party collects and processes your payment account information. We do not collect or retain full account or card numbers in our systems.Information We Collect AutomaticallyUsage data, such as your browser type and operating system, hardware model, unique device identifiers, device names, access times, pages viewed, links clicked, the web pages that you connect your wallet to, and the webpage that led you to our Functionality to support device management and security.Your IP address, which we process, temporarily store and/or pass to third party partners to the extent necessary to protect the security of our Functionality and prevent DDoS attacks, derive your approximate location (such as state or country), establish a network connection between your device and our Functionality (which is required to provide the Functionality), or comply with legal obligations (such as adherence to applicable Sanctions).For clarity, we will only pass your IP address to third parties when necessary to enable specific functionalities that you have opted intoor to comply with applicable legal or regulatory obligations, including sanctions compliance and fraud prevention. In no event will we use your IP address for marketing or advertising purposes other than to comply with jurisdictional legal requirements and our Functionality are not designed to link your IP address with information that readily identifies you, like your wallet address, username or email.Publicly available data such as your digital asset wallet address and public blockchain data, which is only used to provide our Functionality, improve and develop our Functionality and for other legal reasons as further described below.If you use Phantom Cash, merchant location data associated with your transactions to log transaction history and to detect and prevent fraud.If you use our chat or social features, message content and related metadata to support trust and safety enforcement and to improve those features.On our trading terminal, session replay data (including clicks and navigation) to improve the product and diagnose issues. Sensitive fields, including financial inputs, are masked and not recorded.For additional information related to Phantom’s use of cookies and other tracking technology, please see the Our Use of Cookies and Other Tracking Mechanisms section below for more information.Information We Collect from Other SourcesWe may also receive information about you from other sources. For example, if you create or log into your account through a third-party platform (such as Google), we will have access to certain information from that platform, such as your email address, in accordance with the authorization procedures determined by that platform.We may associate your wallet address(es) with your account identifiers, such as your email address or username, to enable customer support, fraud detection, and to provide consistent experience across features. You may opt out of this association in your in-app settings; note that opt out may limit certain support and fraud-protection capabilities.How We Use The Information We CollectWe use the information we collect for the following purposes:Provide our FunctionalityWe use your information to provide our Functionality, communicate with you about your use of our Functionality and to respond to your inquiries, to fulfill your orders, and for other customer support purposes. For some Functionality, including Phantom Cash, that require collection of personal information legally required by the Bank Secrecy Act, we will provide an interface by which users can provide this information to the third-party partner. Phantom does not retain this personal information.Provide personalized FunctionalityWe use your information to tailor the content and information that we may send or display to you, to offer location customization, and personalized help and instructions, and to otherwise personalize your experiences while using the Functionality.Improve and develop our FunctionalityWe use your information to ensure our Functionality are working as intended, to better understand how users access and use our Functionality, both on an aggregated and individualized basis, to make improvements, to develop new functionality, and for other research and analytical purposes.Offers and other communicationsWe may use your information for marketing and promotional purposes. For example, we may use your information, such as your email address, to send you notifications, news and newsletters, special offers, and promotions, to conduct contests and sweepstakes, or to otherwise contact you about products or information we think may interest you. We may also use your email address to measure the effectiveness of our advertising campaigns. This information may also be provided to you directly through notifications in your Phantom Wallet.Trust, safety, and fraud preventionWe use certain information (including phone numbers, payment method details, merchant location data, wallet associations, and message content) to detect, investigate, and prevent fraud, abuse, security incidents, and violations of our Terms of Use. We also use this information to comply with legal obligations related to financial crimes and sanctions.Other legal reasonsWe may use your information to enforce any applicable Terms of Use; comply with the law, legal process, or legal obligations; exercise or defend legal claims; detect, prevent, or address fraud; comply with law enforcement, regulatory, and tax authority related requests (whether from the United States or from overseas); security or technical issues; or otherwise protect our property, legal rights, or that of others.How We Share The Information We CollectWe may disclose the information we collect about you as follows:Consent. Where you have provided consent or directed us to disclose your information, we disclose information about you as described at the time of consent or direction. For example, when you transact with a third party through our Functionality, you will direct us to share relevant information about you and your transaction to that third party.Affiliates. We may disclose information about you between and among any corporate affiliate that controls, is controlled by or is under common control with Phantom.Vendors & Service Providers. We may disclose information about you to third party vendors, service providers, contractors, or agents who perform functions for us.Business Transfers. If we are acquired by or merged with another company, if substantially all of our assets are transferred to another company, or as part of a bankruptcy proceeding, or are in negotiations for any of these types of transactions, we may transfer information about you to the other company.In Response to Legal Process. We may disclose information about you in response to a request for information if we believe that disclosure is in accordance with, or required by, any applicable law, regulation, or legal process, including lawful requests by public authorities to meet national security or law enforcement requirements.To Protect Us and Others. We also may disclose information about you where we believe it is necessary to investigate, prevent, or take action regarding illegal activities, suspected fraud, situations involving potential threats to the safety of any person, violations of any applicable Terms of Use or this Policy, or as evidence in litigation or regulatory investigations in which we are involved in any capacity.Aggregate and De-Identified Information. We may disclose aggregate or de-identified information about users that is not treated as personal data under applicable law with third parties and publicly for marketing, advertising, research or similar purposes. We will not attempt to re-identify de-identified information that we do not treat as personal data, except as permitted by law.Please note that, we will not sell or share your personal information with any third party for their direct marketing purposes.Our Use of Cookies and Other Tracking MechanismsWe and our service providers use cookies and other tracking mechanisms to track information about your use of our Functionality.Currently, our systems do not recognize browser “do-not-track” requests. You may, however, disable certain tracking as discussed in this section (e.g., by disabling cookies).CookiesCookies are alphanumeric identifiers that we transfer to your device through your web browser for record-keeping purposes. Some cookies allow us to make it easier for you to navigate our Functionality, while others are used to enable a faster log-in process or to allow us to track your activities. There are two types of cookies: session and persistent cookies. Session Cookies stay on your computer during your browser session and are deleted after the session ends. If we use session cookies, we use them to understand site traffic and usage, including pages visited and countries of visitors. Persistent cookies remain on your computer after you have closed your browser or turned off your computer. When we use persistent cookies, we use them to track aggregate and statistical information about user activity.Disabling CookiesMost web browsers automatically accept cookies, but if you prefer, you can edit your browser options to block them in the future. The Help portion of the toolbar on most browsers will tell you how to prevent your computer from accepting new cookies, how to have the browser notify you when you receive a new cookie, or how to disable cookies altogether. Visitors to our website, browser extension, or mobile application who disable cookies may not be able to use certain functionalities.Third-Party AnalyticsWe use third-party analytics to evaluate usage of our Functionality. We also may use other analytic means to evaluate the Functionality. We use these tools to help us improve the Functionality, performance, user experiences, and for competitive analysis. These entities may use cookies and other tracking technologies to perform their services.Third-Party LinksOur Functionality may contain links to third-party websites. Any access to and use of such linked websites is not governed by this Policy, but instead is governed by the privacy policies of those third-party websites. We are not responsible for the information practices of such third-party websites.Personal Information ChoicesWhat Choices Do I Have Regarding Use of My Personal Information for Marketing?You may opt out of marketing emails we send to you by following the opt-out instructions contained in the email. You may also opt out of mobile notifications by modifying your notification sessions in the mobile application. Please note that it may take up to 10 business days for us to process opt-out requests. If you opt out of receiving marketing emails or mobile notifications, we may still send you non-marketing related emails or notifications.Contact UsIf you have questions about our approach to privacy or would like to make a complaint, please contact us at privacy@phantom.app.Changes to this PolicyThis Policy is current as of the Effective Date set forth above. We may change this Policy from time to time and will notify you by revising the date at the top of this Policy. If we make material changes, we will provide you with additional notice (such as by adding a statement on the Functionality or sending you a notification). We encourage you to review this Policy regularly to stay informed about our information practices and the choices available to you.Additional Information For Individuals Residing in Certain U.S. StatesSeveral U.S. states have enacted privacy laws that grant their residents certain rights and require specific disclosures. If you reside California, this section applies to you. This section also serves as our California notice at collection.Additional DisclosuresAs required by certain of these state privacy laws, below we explain some of the same information that is covered in the above sections of our Policy.Category of Personal InformationWe collect the below categories of personal information. See above in the Information We Collect section for more specific information.Identifiers (such as digital asset wallet address, public blockchain data, email address, phone numbers, username, avatar, images, legal name, date of birth, Social Security number, government-issued identification, phone number, bank account and payment card information, wallet associations)Geolocation data (such as merchant location associated with payment transactions)Commercial information (such as transaction data)Internet or other electronic network activity information (such as IP address, usage data)Sensitive personal information (such as Social Security Number and biometric data collected through our third-party service providers for identity verification in connection with KYC). We do not have access to biometric data.Categories of Recipients and with Whom We Disclose Personal InformationWe may disclose the categories of personal information described above with the following categories of recipients:Affiliates of Phantom, including our subsidiariesVendors and service providers, including cloud service providers, analytics companies, fraud prevention and information securities companies, email service providers, promotion providers, customer service providersProfessional advisors, including our legal, financial, insurance, and other professional advisors where necessary to obtain advice or otherwise protect and manage our business interestsLaw enforcement, courts, regulators, or other government authorities as required by lawOther third parties when you consent or intentionally direct us to do soUse of Personal InformationEnable our FunctionalityProvide personalized notifications and informationImprove and develop our FunctionalityOffers and other communicationsDetect, investigate and prevent fraud, abuse, and security incidentsOther legal reasonsWe do not “sell” or “share” personal information or disclose personal information for “targeted advertising”, as each of those terms are defined under these state privacy laws.As described in The Information We Collect section above, we collect personal information from various sources, including directly from you, automatically when you access or use our Functionality, and from third-party sources.We do not knowingly or intentionally use or disclose sensitive personal information for the purpose of inferring characteristics about you.We retain personal information for as long as necessary to carry out the purposes for which we originally collected it and for other purposes described in this Privacy Policy.What Rights Do I Have Regarding My Personal Information?Subject to certain limitations and depending on your state of residence, you have the right to request: (1) to know the categories and specific pieces of personal information we collect, use, and disclose and to access your information, including in a portable format; (2) deletion of personal information that we have collected about you; and (3) correction of your personal information. To exercise these rights, please submit a request to privacy@phantom.app. We will use reasonable efforts to accommodate such requests to the extent required by law, provided that we may be required to retain personal information to comply with legal obligations, accounting requirements, or for other business purposes permitted by applicable law. We may request additional information to verify the identity of the requesting party before responding to a request. We may request additional information to verify the identity of the requesting party before responding to a request. Please note that copies of information that you have updated, modified, or deleted may remain viewable in cached and archived pages of the website, browser extension, or mobile application for a period of time.NondiscriminationYou have the right not to be discriminated against for exercising any of your privacy rights.AppealsIf we deny your request, you may appeal our decision by contacting us at privacy@phantom.app. If you have concerns about the result of an appeal, you may contact the attorney general in the state where you reside.Authorized AgentsIf you reside in certain states (like California), you may also designate an authorized agent to submit a request on your behalf. We may ask authorized agents to submit proof of their authority to make a request, such as a valid power of attorney or proof that they have signed permission from the consumer who is the subject of the request. In some cases, we may be required to contact the individual who is the subject of the request to verify his or her own identity or confirm the authorized agent has permission to submit the request. If you are an authorized agent seeking to make a request, please email us at privacy@phantom.app.Additional Information For Individuals in EuropeIf you are located in Europe, the following section applies to you.International TransfersOur Functionality is offered from the United States. We store any information we collect in the United States. If you access the Functionality from outside the United States, you understand that we may transfer your information to the United States, which may provide fewer protections for your personal information than your jurisdiction of residence. Whenever we make restricted international transfers of personal information, we take steps designed to ensure that your personal information receives an adequate level of protection (by putting in place appropriate safeguards, such as contractual clauses) or ensure that we can rely on an appropriate derogation under data protection laws.Where relevant, you may request access to any safeguard which we use to transfer your personal information outside of the European Economic Area, the United Kingdom, or Switzerland (although we may need to redact data transfer agreements for reasons of commercial confidentiality).RetentionWe retain personal data for as long as necessary to carry out the purposes for which we originally collected it and for other purposes described in this Policy.Legal Basis for ProcessingWhen we process your personal data as described above, we do so in reliance on the following lawful bases:To perform our responsibilities under our contract with you (e.g., providing the products and functionalities you requested).When we have a legitimate interest in processing your personal data to operate our business or protect our interests (e.g., to provide, maintain, and improve our products and services, conduct data analytics, to combat fraud and maintain security, and communicate with you).To comply with our legal obligations (e.g., to maintain a record of your consents and track those who have opted out of marketing communications).When we have your consent to do so (e.g., when you opt in to receive marketing communications from us). When consent is the legal basis for our processing of your personal data, you may withdraw such consent at any time.Data Subject RequestsYou have the right to (1) access your personal data, including in a portable format, (2) request erasure of your personal data, and (3) request correction of inaccurate personal data. In addition, you may have the right to object to certain processing or request we restrict certain processing. To exercise any of these rights, please send an email to privacy@phantom.app.If you have a concern about our processing of personal data, we encourage you to contact us in the first instance. However, if we are not able to resolve, you have the right to lodge a complaint with the Data Protection Authority where you reside. Contact details for your Data Protection Authority can be found using the links below:For individuals in the European Union: https://edpb.europa.eu/about-edpb/board/members_enFor individuals in the UK: https://ico.org.uk/global/contact-us/For individuals in Switzerland: https://www.edoeb.admin.ch/edoeb/en/home/the-fdpic/contact.htmlAdditional Information For Individuals in CanadaIf you are a Canadian resident, this section applies to you.Consent: By submitting personal information to Phantom, or our service providers, and agents, you consent to the collection, use, disclosure, and transfer of your personal information in accordance with this Policy and as permitted or required by law.You may withdraw your consent at any time to the collection, use, disclosure, or transfer of your personal information by contacting Phantom as set forth in the Contact Us section below. If you withdraw your consent (or if you decide not to provide certain personal information), you acknowledge that Phantom may not be able to continue to provide you with certain products, functionalities, or information that may be of value to you.We store personal information for as long as necessary to carry out the purposes for which we originally collected it and for other business purposes explained in this Policy.","tokens":6246,"squid":"spider-10","role":"Tooling Spider","at":1791341685519,"hash":"2156d0445e5af5b9a1f27102b167c2cf79298190"}
{"url":"https://eips.ethereum.org/EIPS/eip-1820","domain":"eips.ethereum.org","title":"ERC-1820: Pseudo-introspection Registry Contract","text":"🎉 Final\n\n Standards Track: ERC\n\n ERC-1820: Pseudo-introspection Registry Contract\n\n Authors\n Jordi Baylina <jordi@baylina.cat>, Jacques Dafflon <mail@0xjac.com>\n\n Created\n 2019-03-04\n\n Requires\n\n EIP-165, \n\n EIP-214\n\n :information_source: ERC-1820 has superseded ERC-820. :information_source:\nERC-1820 fixes the incompatibility in the ERC-165 logic which was introduced by the Solidity 0.5 update.\nHave a look at the official announcement, and the comments about the bug and the fix.\nApart from this fix, ERC-1820 is functionally equivalent to ERC-820.\n\n :warning: ERC-1820 MUST be used in lieu of ERC-820. :warning:\n\n Simple Summary\n\nThis standard defines a universal registry smart contract where any address (contract or regular account) can register which interface it supports and which smart contract is responsible for its implementation.\n\nThis standard keeps backward compatibility with ERC-165.\n\n Abstract\n\nThis standard defines a registry where smart contracts and regular accounts can publish which functionality they implement—either directly or through a proxy contract.\n\nAnyone can query this registry to ask if a specific address implements a given interface and which smart contract handles its implementation.\n\nThis registry MAY be deployed on any chain and shares the same address on all chains.\n\nInterfaces with zeroes (0) as the last 28 bytes are considered ERC-165 interfaces,\nand this registry SHALL forward the call to the contract to see if it implements the interface.\n\nThis contract also acts as an ERC-165 cache to reduce gas consumption.\n\n Motivation\n\nThere have been different approaches to define pseudo-introspection in Ethereum.\nThe first is ERC-165 which has the limitation that it cannot be used by regular accounts.\nThe second attempt is ERC-672 which uses reverse ENS. Using reverse ENS has two issues. \nFirst, it is unnecessarily complicated, and second, ENS is still a centralized contract controlled by a multisig.\nThis multisig theoretically would be able to modify the system.\n\nThis standard is much simpler than ERC-672, and it is fully decentralized.\n\nThis standard also provides a unique address for all chains.\nThus solving the problem of resolving the correct registry address for different chains.\n\n Specification\n\n ERC-1820 Registry Smart Contract\n\n This is an exact copy of the code of the ERC1820 registry smart contract.\n\n/* ERC1820 Pseudo-introspection Registry Contract\n * This standard defines a universal registry smart contract where any address (contract or regular account) can\n * register which interface it supports and which smart contract is responsible for its implementation.\n *\n * Written in 2019 by Jordi Baylina and Jacques Dafflon\n *\n * To the extent possible under law, the author(s) have dedicated all copyright and related and neighboring rights to\n * this software to the public domain worldwide. This software is distributed without any warranty.\n *\n * You should have received a copy of the CC0 Public Domain Dedication along with this software. If not, see\n * <http://creativecommons.org/publicdomain/zero/1.0/>.\n *\n * ███████╗██████╗ ██████╗ ██╗ █████╗ ██████╗ ██████╗\n * ██╔════╝██╔══██╗██╔════╝███║██╔══██╗╚════██╗██╔═████╗\n * █████╗ ██████╔╝██║ ╚██║╚█████╔╝ █████╔╝██║██╔██║\n * ██╔══╝ ██╔══██╗██║ ██║██╔══██╗██╔═══╝ ████╔╝██║\n * ███████╗██║ ██║╚██████╗ ██║╚█████╔╝███████╗╚██████╔╝\n * ╚══════╝╚═╝ ╚═╝ ╚═════╝ ╚═╝ ╚════╝ ╚══════╝ ╚═════╝\n *\n * ██████╗ ███████╗ ██████╗ ██╗███████╗████████╗██████╗ ██╗ ██╗\n * ██╔══██╗██╔════╝██╔════╝ ██║██╔════╝╚══██╔══╝██╔══██╗╚██╗ ██╔╝\n * ██████╔╝█████╗ ██║ ███╗██║███████╗ ██║ ██████╔╝ ╚████╔╝\n * ██╔══██╗██╔══╝ ██║ ██║██║╚════██║ ██║ ██╔══██╗ ╚██╔╝\n * ██║ ██║███████╗╚██████╔╝██║███████║ ██║ ██║ ██║ ██║\n * ╚═╝ ╚═╝╚══════╝ ╚═════╝ ╚═╝╚══════╝ ╚═╝ ╚═╝ ╚═╝ ╚═╝\n *\n */\npragma solidity 0.5.3;\n// IV is value needed to have a vanity address starting with '0x1820'.\n// IV: 53759\n\n/// @dev The interface a contract MUST implement if it is the implementer of\n/// some (other) interface for any address other than itself.\ninterface ERC1820ImplementerInterface {\n /// @notice Indicates whether the contract implements the interface 'interfaceHash' for the address 'addr' or not.\n /// @param interfaceHash keccak256 hash of the name of the interface\n /// @param addr Address for which the contract will implement the interface\n /// @return ERC1820_ACCEPT_MAGIC only if the contract implements 'interfaceHash' for the address 'addr'.\n function canImplementInterfaceForAddress(bytes32 interfaceHash, address addr) external view returns(bytes32);\n}\n\n/// @title ERC1820 Pseudo-introspection Registry Contract\n/// @author Jordi Baylina and Jacques Dafflon\n/// @notice This contract is the official implementation of the ERC1820 Registry.\n/// @notice For more details, see https://eips.ethereum.org/EIPS/eip-1820\ncontract ERC1820Registry {\n /// @notice ERC165 Invalid ID.\n bytes4 constant internal INVALID_ID = 0xffffffff;\n /// @notice Method ID for the ERC165 supportsInterface method (= `bytes4(keccak256('supportsInterface(bytes4)'))`).\n bytes4 constant internal ERC165ID = 0x01ffc9a7;\n /// @notice Magic value which is returned if a contract implements an interface on behalf of some other address.\n bytes32 constant internal ERC1820_ACCEPT_MAGIC = keccak256(abi.encodePacked(\"ERC1820_ACCEPT_MAGIC\"));\n\n /// @notice mapping from addresses and interface hashes to their implementers.\n mapping(address => mapping(bytes32 => address)) internal interfaces;\n /// @notice mapping from addresses to their manager.\n mapping(address => address) internal managers;\n /// @notice flag for each address and erc165 interface to indicate if it is cached.\n mapping(address => mapping(bytes4 => bool)) internal erc165Cached;\n\n /// @notice Indicates a contract is the 'implementer' of 'interfaceHash' for 'addr'.\n event InterfaceImplementerSet(address indexed addr, bytes32 indexed interfaceHash, address indexed implementer);\n /// @notice Indicates 'newManager' is the address of the new manager for 'addr'.\n event ManagerChanged(address indexed addr, address indexed newManager);\n\n /// @notice Query if an address implements an interface and through which contract.\n /// @param _addr Address being queried for the implementer of an interface.\n /// (If '_addr' is the zero address then 'msg.sender' is assumed.)\n /// @param _interfaceHash Keccak256 hash of the name of the interface as a string.\n /// E.g., 'web3.utils.keccak256(\"ERC777TokensRecipient\")' for the 'ERC777TokensRecipient' interface.\n /// @return The address of the contract which implements the interface '_interfaceHash' for '_addr'\n /// or '0' if '_addr' did not register an implementer for this interface.\n function getInterfaceImplementer(address _addr, bytes32 _interfaceHash) external view returns (address) {\n address addr = _addr == address(0) ? msg.sender : _addr;\n if (isERC165Interface(_interfaceHash)) {\n bytes4 erc165InterfaceHash = bytes4(_interfaceHash);\n return implementsERC165Interface(addr, erc165InterfaceHash) ? addr : address(0);\n }\n return interfaces[addr][_interfaceHash];\n }\n\n /// @notice Sets the contract which implements a specific interface for an address.\n /// Only the manager defined for that address can set it.\n /// (Each address is the manager for itself until it sets a new manager.)\n /// @param _addr Address for which to set the interface.\n /// (If '_addr' is the zero address then 'msg.sender' is assumed.)\n /// @param _interfaceHash Keccak256 hash of the name of the interface as a string.\n /// E.g., 'web3.utils.keccak256(\"ERC777TokensRecipient\")' for the 'ERC777TokensRecipient' interface.\n /// @param _implementer Contract address implementing '_interfaceHash' for '_addr'.\n function setInterfaceImplementer(address _addr, bytes32 _interfaceHash, address _implementer) external {\n address addr = _addr == address(0) ? msg.sender : _addr;\n require(getManager(addr) == msg.sender, \"Not the manager\");\n\n require(!isERC165Interface(_interfaceHash), \"Must not be an ERC165 hash\");\n if (_implementer != address(0) && _implementer != msg.sender) {\n require(\n ERC1820ImplementerInterface(_implementer)\n .canImplementInterfaceForAddress(_interfaceHash, addr) == ERC1820_ACCEPT_MAGIC,\n \"Does not implement the interface\"\n );\n }\n interfaces[addr][_interfaceHash] = _implementer;\n emit InterfaceImplementerSet(addr, _interfaceHash, _implementer);\n }\n\n /// @notice Sets '_newManager' as manager for '_addr'.\n /// The new manager will be able to call 'setInterfaceImplementer' for '_addr'.\n /// @param _addr Address for which to set the new manager.\n /// @param _newManager Address of the new manager for 'addr'. (Pass '0x0' to reset the manager to '_addr'.)\n function setManager(address _addr, address _newManager) external {\n require(getManager(_addr) == msg.sender, \"Not the manager\");\n managers[_addr] = _newManager == _addr ? address(0) : _newManager;\n emit ManagerChanged(_addr, _newManager);\n }\n\n /// @notice Get the manager of an address.\n /// @param _addr Address for which to return the manager.\n /// @return Address of the manager for a given address.\n function getManager(address _addr) public view returns(address) {\n // By default the manager of an address is the same address\n if (managers[_addr] == address(0)) {\n return _addr;\n } else {\n return managers[_addr];\n }\n }\n\n /// @notice Compute the keccak256 hash of an interface given its name.\n /// @param _interfaceName Name of the interface.\n /// @return The keccak256 hash of an interface name.\n function interfaceHash(string calldata _interfaceName) external pure returns(bytes32) {\n return keccak256(abi.encodePacked(_interfaceName));\n }\n\n /* --- ERC165 Related Functions --- */\n /* --- Developed in collaboration with William Entriken. --- */\n\n /// @notice Updates the cache with whether the contract implements an ERC165 interface or not.\n /// @param _contract Address of the contract for which to update the cache.\n /// @param _interfaceId ERC165 interface for which to update the cache.\n function updateERC165Cache(address _contract, bytes4 _interfaceId) external {\n interfaces[_contract][_interfaceId] = implementsERC165InterfaceNoCache(\n _contract, _interfaceId) ? _contract : address(0);\n erc165Cached[_contract][_interfaceId] = true;\n }\n\n /// @notice Checks whether a contract implements an ERC165 interface or not.\n // If the result is not cached a direct lookup on the contract address is performed.\n // If the result is not cached or the cached value is out-of-date, the cache MUST be updated manually by calling\n // 'updateERC165Cache' with the contract address.\n /// @param _contract Address of the contract to check.\n /// @param _interfaceId ERC165 interface to check.\n /// @return True if '_contract' implements '_interfaceId', false otherwise.\n function implementsERC165Interface(address _contract, bytes4 _interfaceId) public view returns (bool) {\n if (!erc165Cached[_contract][_interfaceId]) {\n return implementsERC165InterfaceNoCache(_contract, _interfaceId);\n }\n return interfaces[_contract][_interfaceId] == _contract;\n }\n\n /// @notice Checks whether a contract implements an ERC165 interface or not without using nor updating the cache.\n /// @param _contract Address of the contract to check.\n /// @param _interfaceId ERC165 interface to check.\n /// @return True if '_contract' implements '_interfaceId', false otherwise.\n function implementsERC165InterfaceNoCache(address _contract, bytes4 _interfaceId) public 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, INVALID_ID);\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 /// @notice Checks whether the hash is a ERC165 interface (ending with 28 zeroes) or not.\n /// @param _interfaceHash The hash to check.\n /// @return True if '_interfaceHash' is an ERC165 interface (ending with 28 zeroes), false otherwise.\n function isERC165Interface(bytes32 _interfaceHash) internal pure returns (bool) {\n return _interfaceHash & 0x00000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF == 0;\n }\n\n /// @dev Make a call on a contract without throwing if the function does not exist.\n function noThrowCall(address _contract, bytes4 _interfaceId)\n internal view returns (uint256 success, uint256 result)\n {\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 (4 + 32) bytes long\n x, // Store output over input (saves space)\n 0x20 // Outputs are 32 bytes long\n )\n\n result := mload(x) // Load the result\n }\n }\n}\n\n Deployment Transaction\n\nBelow is the raw transaction which MUST be used to deploy the smart contract on any chain.\n\n0xf90a388085174876e800830c35008080b909e5608060405234801561001057600080fd5b506109c5806100206000396000f3fe608060405234801561001057600080fd5b50600436106100a5576000357c010000000000000000000000000000000000000000000000000000000090048063a41e7d5111610078578063a41e7d51146101d4578063aabbb8ca1461020a578063b705676514610236578063f712f3e814610280576100a5565b806329965a1d146100aa5780633d584063146100e25780635df8122f1461012457806365ba36c114610152575b600080fd5b6100e0600480360360608110156100c057600080fd5b50600160a060020a038135811691602081013591604090910135166102b6565b005b610108600480360360208110156100f857600080fd5b5035600160a060020a0316610570565b60408051600160a060020a039092168252519081900360200190f35b6100e06004803603604081101561013a57600080fd5b50600160a060020a03813581169160200135166105bc565b6101c26004803603602081101561016857600080fd5b81019060208101813564010000000081111561018357600080fd5b82018360208201111561019557600080fd5b803590602001918460018302840111640100000000831117156101b757600080fd5b5090925090506106b3565b60408051918252519081900360200190f35b6100e0600480360360408110156101ea57600080fd5b508035600160a060020a03169060200135600160e060020a0319166106ee565b6101086004803603604081101561022057600080fd5b50600160a060020a038135169060200135610778565b61026c6004803603604081101561024c57600080fd5b508035600160a060020a03169060200135600160e060020a0319166107ef565b604080519115158252519081900360200190f35b61026c6004803603604081101561029657600080fd5b508035600160a060020a03169060200135600160e060020a0319166108aa565b6000600160a060020a038416156102cd57836102cf565b335b9050336102db82610570565b600160a060020a031614610339576040805160e560020a62461bcd02815260206004820152600f60248201527f4e6f7420746865206d616e616765720000000000000000000000000000000000604482015290519081900360640190fd5b6103428361092a565b15610397576040805160e560020a62461bcd02815260206004820152601a60248201527f4d757374206e6f7420626520616e204552433136352068617368000000000000604482015290519081900360640190fd5b600160a060020a038216158015906103b85750600160a060020a0382163314155b156104ff5760405160200180807f455243313832305f4143434550545f4d4147494300000000000000000000000081525060140190506040516020818303038152906040528051906020012082600160a060020a031663249cb3fa85846040518363ffffffff167c01000000000000000000000000000000000000000000000000000000000281526004018083815260200182600160a060020a0316600160a060020a031681526020019250505060206040518083038186803b15801561047e57600080fd5b505afa158015610492573d6000803e3d6000fd5b505050506040513d60208110156104a857600080fd5b5051146104ff576040805160e560020a62461bcd02815260206004820181905260248201527f446f6573206e6f7420696d706c656d656e742074686520696e74657266616365604482015290519081900360640190fd5b600160a060020a03818116600081815260208181526040808320888452909152808220805473ffffffffffffffffffffffffffffffffffffffff19169487169485179055518692917f93baa6efbd2244243bfee6ce4cfdd1d04fc4c0e9a786abd3a41313bd352db15391a450505050565b600160a060020a03818116600090815260016020526040812054909116151561059a5750806105b7565b50600160a060020a03808216600090815260016020526040902054165b919050565b336105c683610570565b600160a060020a031614610624576040805160e560020a62461bcd02815260206004820152600f60248201527f4e6f7420746865206d616e616765720000000000000000000000000000000000604482015290519081900360640190fd5b81600160a060020a031681600160a060020a0316146106435780610646565b60005b600160a060020a03838116600081815260016020526040808220805473ffffffffffffffffffffffffffffffffffffffff19169585169590951790945592519184169290917f605c2dbf762e5f7d60a546d42e7205dcb1b011ebc62a61736a57c9089d3a43509190a35050565b600082826040516020018083838082843780830192505050925050506040516020818303038152906040528051906020012090505b92915050565b6106f882826107ef565b610703576000610705565b815b600160a060020a03928316600081815260208181526040808320600160e060020a031996909616808452958252808320805473ffffffffffffffffffffffffffffffffffffffff19169590971694909417909555908152600284528181209281529190925220805460ff19166001179055565b600080600160a060020a038416156107905783610792565b335b905061079d8361092a565b156107c357826107ad82826108aa565b6107b85760006107ba565b815b925050506106e8565b600160a060020a0390811660009081526020818152604080832086845290915290205416905092915050565b6000808061081d857f01ffc9a70000000000000000000000000000000000000000000000000000000061094c565b909250905081158061082d575080155b1561083d576000925050506106e8565b61084f85600160e060020a031961094c565b909250905081158061086057508015155b15610870576000925050506106e8565b61087a858561094c565b909250905060018214801561088f5750806001145b1561089f576001925050506106e8565b506000949350505050565b600160a060020a0382166000908152600260209081526040808320600160e060020a03198516845290915281205460ff1615156108f2576108eb83836107ef565b90506106e8565b50600160a060020a03808316600081815260208181526040808320600160e060020a0319871684529091529020549091161492915050565b7bffffffffffffffffffffffffffffffffffffffffffffffffffffffff161590565b6040517f01ffc9a7000000000000000000000000000000000000000000000000000000008082526004820183905260009182919060208160248189617530fa90519096909550935050505056fea165627a7a72305820377f4a2d4301ede9949f163f319021a6e9c687c292a5e2b2c4734c126b524e6c00291ba01820182018201820182018201820182018201820182018201820182018201820a01820182018201820182018201820182018201820182018201820182018201820\n\nThe strings of 1820’s at the end of the transaction are the r and s of the signature.\nFrom this deterministic pattern (generated by a human), anyone can deduce that no one knows the private key for the deployment account.\n\n Deployment Method\n\nThis contract is going to be deployed using the keyless deployment method—also known as Nick’s method—which relies on a single-use address.\n(See Nick’s article for more details). This method works as follows:\n\n Generate a transaction which deploys the contract from a new random account.\n\n This transaction MUST NOT use EIP-155 in order to work on any chain.\n This transaction MUST have a relatively high gas price to be deployed on any chain. In this case, it is going to be 100 Gwei.\n\n Set the v, r, s of the transaction signature to the following values:\n\n v: 27,\nr: 0x1820182018201820182018201820182018201820182018201820182018201820'\ns: 0x1820182018201820182018201820182018201820182018201820182018201820'\n\n Those r and s values—made of a repeating pattern of 1820’s—are predictable “random numbers” generated deterministically by a human.\n\n We recover the sender of this transaction, i.e., the single-use deployment account.\n\n Thus we obtain an account that can broadcast that transaction, but we also have the warranty that nobody knows the private key of that account.\n\n Send exactly 0.08 ether to this single-use deployment account.\n\n Broadcast the deployment transaction.\n\nThis operation can be done on any chain, guaranteeing that the contract address is always the same and nobody can use that address with a different contract.\n\n Single-use Registry Deployment Account\n\n0xa990077c3205cbDf861e17Fa532eeB069cE9fF96\n\nThis account is generated by reverse engineering it from its signature for the transaction. \nThis way no one knows the private key, but it is known that it is the valid signer of the deployment transaction.\n\n To deploy the registry, 0.08 ether MUST be sent to this account first.\n\n Registry Contract Address\n\n0x1820a4B7618BdE71Dce8cdc73aAB6C95905faD24\n\nThe contract has the address above for every chain on which it is deployed.\n\nRaw metadata of ./contracts/ERC1820Registry.sol\n\n```json\n{\n \"compiler\": {\n \"version\": \"0.5.3+commit.10d17f24\"\n },\n \"language\": \"Solidity\",\n \"output\": {\n \"abi\": [\n {\n \"constant\": false,\n \"inputs\": [\n {\n \"name\": \"_addr\",\n \"type\": \"address\"\n },\n {\n \"name\": \"_interfaceHash\",\n \"type\": \"bytes32\"\n },\n {\n \"name\": \"_implementer\",\n \"type\": \"address\"\n }\n ],\n \"name\": \"setInterfaceImplementer\",\n \"outputs\": [],\n \"payable\": false,\n \"stateMutability\": \"nonpayable\",\n \"type\": \"function\"\n },\n {\n \"constant\": true,\n \"inputs\": [\n {\n \"name\": \"_addr\",\n \"type\": \"address\"\n }\n ],\n \"name\": \"getManager\",\n \"outputs\": [\n {\n \"name\": \"\",\n \"type\": \"address\"\n }\n ],\n \"payable\": false,\n \"stateMutability\": \"view\",\n \"type\": \"function\"\n },\n {\n \"constant\": false,\n \"inputs\": [\n {\n \"name\": \"_addr\",\n \"type\": \"address\"\n },\n {\n \"name\": \"_newManager\",\n \"type\": \"address\"\n }\n ],\n \"name\": \"setManager\",\n \"outputs\": [],\n \"payable\": false,\n \"stateMutability\": \"nonpayable\",\n \"type\": \"function\"\n },\n {\n \"constant\": true,\n \"inputs\": [\n {\n \"name\": \"_interfaceName\",\n \"type\": \"string\"\n }\n ],\n \"name\": \"interfaceHash\",\n \"outputs\": [\n {\n \"name\": \"\",\n \"type\": \"bytes32\"\n }\n ],\n \"payable\": false,\n \"stateMutability\": \"pure\",\n \"type\": \"function\"\n },\n {\n \"constant\": false,\n \"inputs\": [\n {\n \"name\": \"_contract\",\n \"type\": \"address\"\n },\n {\n \"name\": \"_interfaceId\",\n \"type\": \"bytes4\"\n }\n ],\n \"name\": \"updateERC165Cache\",\n \"outputs\": [],\n \"payable\": false,\n \"stateMutability\": \"nonpayable\",\n \"type\": \"function\"\n },\n {\n \"constant\": true,\n \"inputs\": [\n {\n \"name\": \"_addr\",\n \"type\": \"address\"\n },\n {\n \"name\": \"_interfaceHash\",\n \"type\": \"bytes32\"\n }\n ],\n \"name\": \"getInterfaceImplementer\",\n \"outputs\": [\n {\n \"name\": \"\",\n \"type\": \"address\"\n }\n ],\n \"payable\": false,\n \"stateMutability\": \"view\",\n \"type\": \"function\"\n },\n {\n \"constant\": true,\n \"inputs\": [\n {\n \"name\": \"_contract\",\n \"type\": \"address\"\n },\n {\n \"name\": \"_interfaceId\",\n \"type\": \"bytes4\"\n }\n ],\n \"name\": \"implementsERC165InterfaceNoCache\",\n \"outputs\": [\n {\n \"name\": \"\",\n \"type\": \"bool\"\n }\n ],\n \"payable\": false,\n \"stateMutability\": \"view\",\n \"type\": \"function\"\n },\n {\n \"constant\": true,\n \"inputs\": [\n {\n \"name\": \"_contract\",\n \"type\": \"address\"\n },\n {\n \"name\": \"_interfaceId\",\n \"type\": \"bytes4\"\n }\n ],\n \"name\": \"implementsERC165Interface\",\n \"outputs\": [\n {\n \"name\": \"\",\n \"type\": \"bool\"\n }\n ],\n \"payable\": false,\n \"stateMutability\": \"view\",\n \"type\": \"function\"\n },\n {\n \"anonymous\": false,\n \"inputs\": [\n {\n \"indexed\": true,\n \"name\": \"addr\",\n \"type\": \"address\"\n },\n {\n \"indexed\": true,\n \"name\": \"interfaceHash\",\n \"type\": \"bytes32\"\n },\n {\n \"indexed\": true,\n \"name\": \"implementer\",\n \"type\": \"address\"\n }\n ],\n \"name\": \"InterfaceImplementerSet\",\n \"type\": \"event\"\n },\n {\n \"anonymous\": false,\n \"inputs\": [\n {\n \"indexed\": true,\n \"name\": \"addr\",\n \"type\": \"address\"\n },\n {\n \"indexed\": true,\n \"name\": \"newManager\",\n \"type\": \"address\"\n }\n ],\n \"name\": \"ManagerChanged\",\n \"type\": \"event\"\n }\n ],\n \"devdoc\": {\n \"author\": \"Jordi Baylina and Jacques Dafflon\",\n \"methods\": {\n \"getInterfaceImplementer(address,bytes32)\": {\n \"params\": {\n \"_addr\": \"Address being queried for the implementer of an interface. (If '_addr' is the zero address then 'msg.sender' is assumed.)\",\n \"_interfaceHash\": \"Keccak256 hash of the name of the interface as a string. E.g., 'web3.utils.keccak256(\\\"ERC777TokensRecipient\\\")' for the 'ERC777TokensRecipient' interface.\"\n },\n \"return\": \"The address of the contract which implements the interface '_interfaceHash' for '_addr' or '0' if '_addr' did not register an implementer for this interface.\"\n },\n \"getManager(address)\": {\n \"params\": {\n \"_addr\": \"Address for which to return the manager.\"\n },\n \"return\": \"Address of the manager for a given address.\"\n },\n \"implementsERC165Interface(address,bytes4)\": {\n \"params\": {\n \"_contract\": \"Address of the contract to check.\",\n \"_interfaceId\": \"ERC165 interface to check.\"\n },\n \"return\": \"True if '_contract' implements '_interfaceId', false otherwise.\"\n },\n \"implementsERC165InterfaceNoCache(address,bytes4)\": {\n \"params\": {\n \"_contract\": \"Address of the contract to check.\",\n \"_interfaceId\": \"ERC165 interface to check.\"\n },\n \"return\": \"True if '_contract' implements '_interfaceId', false otherwise.\"\n },\n \"interfaceHash(string)\": {\n \"params\": {\n \"_interfaceName\": \"Name of the interface.\"\n },\n \"return\": \"The keccak256 hash of an interface name.\"\n },\n \"setInterfaceImplementer(address,bytes32,address)\": {\n \"params\": {\n \"_addr\": \"Address for which to set the interface. (If '_addr' is the zero address then 'msg.sender' is assumed.)\",\n \"_implementer\": \"Contract address implementing '_interfaceHash' for '_addr'.\",\n \"_interfaceHash\": \"Keccak256 hash of the name of the interface as a string. E.g., 'web3.utils.keccak256(\\\"ERC777TokensRecipient\\\")' for the 'ERC777TokensRecipient' interface.\"\n }\n },\n \"setManager(address,address)\": {\n \"params\": {\n \"_addr\": \"Address for which to set the new manager.\",\n \"_newManager\": \"Address of the new manager for 'addr'. (Pass '0x0' to reset the manager to '_addr'.)\"\n }\n },\n \"updateERC165Cache(address,bytes4)\": {\n \"params\": {\n \"_contract\": \"Address of the contract for which to update the cache.\",\n \"_interfaceId\": \"ERC165 interface for which to update the cache.\"\n }\n }\n },\n \"title\": \"ERC1820 Pseudo-introspection Registry Contract\"\n },\n \"userdoc\": {\n \"methods\": {\n \"getInterfaceImplementer(address,bytes32)\": {\n \"notice\": \"Query if an address implements an interface and through which contract.\"\n },\n \"getManager(address)\": {\n \"notice\": \"Get the manager of an address.\"\n },\n \"implementsERC165InterfaceNoCache(address,bytes4)\": {\n \"notice\": \"Checks whether a contract implements an ERC165 interface or not without using nor updating the cache.\"\n },\n \"interfaceHash(string)\": {\n \"notice\": \"Compute the keccak256 hash of an interface given its name.\"\n },\n \"setInterfaceImplementer(address,bytes32,address)\": {\n \"notice\": \"Sets the contract which implements a specific interface for an address. Only the manager defined for that address can set it. (Each address is the manager for itself until it sets a new manager.)\"\n },\n \"setManager(address,address)\": {\n \"notice\": \"Sets '_newManager' as manager for '_addr'. The new manager will be able to call 'setInterfaceImplementer' for '_addr'.\"\n },\n \"updateERC165Cache(address,bytes4)\": {\n \"notice\": \"Updates the cache with whether the contract implements an ERC165 interface or not.\"\n }\n },\n \"notice\": \"This contract is the official implementation of the ERC1820 Registry.For more details, see https://eips.ethereum.org/EIPS/eip-1820\"\n }\n },\n \"settings\": {\n \"compilationTarget\": {\n \"./contracts/ERC1820Registry.sol\": \"ERC1820Registry\"\n },\n \"evmVersion\": \"byzantium\",\n \"libraries\": {},\n \"optimizer\": {\n \"enabled\": true,\n \"runs\": 200\n },\n \"remappings\": []\n },\n \"sources\": {\n \"./contracts/ERC1820Registry.sol\": {\n \"content\": \"/* ERC1820 Pseudo-introspection Registry Contract\\n * This standard defines a universal registry smart contract where any address (contract or regular account) can\\n * register which interface it supports and which smart contract is responsible for its implementation.\\n *\\n * Written in 2019 by Jordi Baylina and Jacques Dafflon\\n *\\n * To the extent possible under law, the author(s) have dedicated all copyright and related and neighboring rights to\\n * this software to the public domain worldwide. This software is distributed without any warranty.\\n *\\n * You should have received a copy of the CC0 Public Domain Dedication along with this software. If not, see\\n * <http://creativecommons.org/publicdomain/zero/1.0/>.\\n *\\n * ███████╗██████╗ ██████╗ ██╗ █████╗ ██████╗ ██████╗\\n * ██╔════╝██╔══██╗██╔════╝███║██╔══██╗╚════██╗██╔═████╗\\n * █████╗ ██████╔╝██║ ╚██║╚█████╔╝ █████╔╝██║██╔██║\\n * ██╔══╝ ██╔══██╗██║ ██║██╔══██╗██╔═══╝ ████╔╝██║\\n * ███████╗██║ ██║╚██████╗ ██║╚█████╔╝███████╗╚██████╔╝\\n * ╚══════╝╚═╝ ╚═╝ ╚═════╝ ╚═╝ ╚════╝ ╚══════╝ ╚═════╝\\n *\\n * ██████╗ ███████╗ ██████╗ ██╗███████╗████████╗██████╗ ██╗ ██╗\\n * ██╔══██╗██╔════╝██╔════╝ ██║██╔════╝╚══██╔══╝██╔══██╗╚██╗ ██╔╝\\n * ██████╔╝█████╗ ██║ ███╗██║███████╗ ██║ ██████╔╝ ╚████╔╝\\n * ██╔══██╗██╔══╝ ██║ ██║██║╚════██║ ██║ ██╔══██╗ ╚██╔╝\\n * ██║ ██║███████╗╚██████╔╝██║███████║ ██║ ██║ ██║ ██║\\n * ╚═╝ ╚═╝╚══════╝ ╚═════╝ ╚═╝╚══════╝ ╚═╝ ╚═╝ ╚═╝ ╚═╝\\n *\\n */\\npragma solidity 0.5.3;\\n// IV is value needed to have a vanity address starting with '0x1820'.\\n// IV: 53759\\n\\n/// @dev The interface a contract MUST implement if it is the implementer of\\n/// some (other) interface for any address other than itself.\\ninterface ERC1820ImplementerInterface {\\n /// @notice Indicates whether the contract implements the interface 'interfaceHash' for the address 'addr' or not.\\n /// @param interfaceHash keccak256 hash of the name of the interface\\n /// @param addr Address for which the contract will implement the interface\\n /// @return ERC1820_ACCEPT_MAGIC only if the contract implements 'interfaceHash' for the address 'addr'.\\n function canImplementInterfaceForAddress(bytes32 interfaceHash, address addr) external view returns(bytes32);\\n}\\n\\n\\n/// @title ERC1820 Pseudo-introspection Registry Contract\\n/// @author Jordi Baylina and Jacques Dafflon\\n/// @notice This contract is the official implementation of the ERC1820 Registry.\\n/// @notice For more details, see https://eips.ethereum.org/EIPS/eip-1820\\ncontract ERC1820Registry {\\n /// @notice ERC165 Invalid ID.\\n bytes4 constant internal INVALID_ID = 0xffffffff;\\n /// @notice Method ID for the ERC165 supportsInterface method (= `bytes4(keccak256('supportsInterface(bytes4)'))`).\\n bytes4 constant internal ERC165ID = 0x01ffc9a7;\\n /// @notice Magic value which is returned if a contract implements an interface on behalf of some other address.\\n bytes32 constant internal ERC1820_ACCEPT_MAGIC = keccak256(abi.encodePacked(\\\"ERC1820_ACCEPT_MAGIC\\\"));\\n\\n /// @notice mapping from addresses and interface hashes to their implementers.\\n mapping(address => mapping(bytes32 => address)) internal interfaces;\\n /// @notice mapping from addresses to their manager.\\n mapping(address => address) internal managers;\\n /// @notice flag for each address and erc165 interface to indicate if it is cached.\\n mapping(address => mapping(bytes4 => bool)) internal erc165Cached;\\n\\n /// @notice Indicates a contract is the 'implementer' of 'interfaceHash' for 'addr'.\\n event InterfaceImplementerSet(address indexed addr, bytes32 indexed interfaceHash, address indexed implementer);\\n /// @notice Indicates 'newManager' is the address of the new manager for 'addr'.\\n event ManagerChanged(address indexed addr, address indexed newManager);\\n\\n /// @notice Query if an address implements an interface and through which contract.\\n /// @param _addr Address being queried for the implementer of an interface.\\n /// (If '_addr' is the zero address then 'msg.sender' is assumed.)\\n /// @param _interfaceHash Keccak256 hash of the name of the interface as a string.\\n /// E.g., 'web3.utils.keccak256(\\\"ERC777TokensRecipient\\\")' for the 'ERC777TokensRecipient' interface.\\n /// @return The address of the contract which implements the interface '_interfaceHash' for '_addr'\\n /// or '0' if '_addr' did not register an implementer for this interface.\\n function getInterfaceImplementer(address _addr, bytes32 _interfaceHash) external view returns (address) {\\n address addr = _addr == address(0) ? msg.sender : _addr;\\n if (isERC165Interface(_interfaceHash)) {\\n bytes4 erc165InterfaceHash = bytes4(_interfaceHash);\\n return implementsERC165Interface(addr, erc165InterfaceHash) ? addr : address(0);\\n }\\n return interfaces[addr][_interfaceHash];\\n }\\n\\n /// @notice Sets the contract which implements a specific interface for an address.\\n /// Only the manager defined for that address can set it.\\n /// (Each address is the manager for itself until it sets a new manager.)\\n /// @param _addr Address for which to set the interface.\\n /// (If '_addr' is the zero address then 'msg.sender' is assumed.)\\n /// @param _interfaceHash Keccak256 hash of the name of the interface as a string.\\n /// E.g., 'web3.utils.keccak256(\\\"ERC777TokensRecipient\\\")' for the 'ERC777TokensRecipient' interface.\\n /// @param _implementer Contract address implementing '_interfaceHash' for '_addr'.\\n function setInterfaceImplementer(address _addr, bytes32 _interfaceHash, address _implementer) external {\\n address addr = _addr == address(0) ? msg.sender : _addr;\\n require(getManager(addr) == msg.sender, \\\"Not the manager\\\");\\n\\n require(!isERC165Interface(_interfaceHash), \\\"Must not be an ERC165 hash\\\");\\n if (_implementer != address(0) && _implementer != msg.sender) {\\n require(\\n ERC1820ImplementerInterface(_implementer)\\n .canImplementInterfaceForAddress(_interfaceHash, addr) == ERC1820_ACCEPT_MAGIC,\\n \\\"Does not implement the interface\\\"\\n );\\n }\\n interfaces[addr][_interfaceHash] = _implementer;\\n emit InterfaceImplementerSet(addr, _interfaceHash, _implementer);\\n }\\n\\n /// @notice Sets '_newManager' as manager for '_addr'.\\n /// The new manager will be able to call 'setInterfaceImplementer' for '_addr'.\\n /// @param _addr Address for which to set the new manager.\\n /// @param _newManager Address of the new manager for 'addr'. (Pass '0x0' to reset the manager to '_addr'.)\\n function setManager(address _addr, address _newManager) external {\\n require(getManager(_addr) == msg.sender, \\\"Not the manager\\\");\\n managers[_addr] = _newManager == _addr ? address(0) : _newManager;\\n emit ManagerChanged(_addr, _newManager);\\n }\\n\\n /// @notice Get the manager of an address.\\n /// @param _addr Address for which to return the manager.\\n /// @return Address of the manager for a given address.\\n function getManager(address _addr) public view returns(address) {\\n // By default the manager of an address is the same address\\n if (managers[_addr] == address(0)) {\\n return _addr;\\n } else {\\n return managers[_addr];\\n }\\n }\\n\\n /// @notice Compute the keccak256 hash of an interface given its name.\\n /// @param _interfaceName Name of the interface.\\n /// @return The keccak256 hash of an interface name.\\n function interfaceHash(string calldata _interfaceName) external pure returns(bytes32) {\\n return keccak256(abi.encodePacked(_interfaceName));\\n }\\n\\n /* --- ERC165 Related Functions --- */\\n /* --- Developed in collaboration with William Entriken. --- */\\n\\n /// @notice Updates the cache with whether the contract implements an ERC165 interface or not.\\n /// @param _contract Address of the contract for which to update the cache.\\n /// @param _interfaceId ERC165 interface for which to update the cache.\\n function updateERC165Cache(address _contract, bytes4 _interfaceId) external {\\n interfaces[_contract][_interfaceId] = implementsERC165InterfaceNoCache(\\n _contract, _interfaceId) ? _contract : address(0);\\n erc165Cached[_contract][_interfaceId] = true;\\n }\\n\\n /// @notice Checks whether a contract implements an ERC165 interface or not.\\n // If the result is not cached a direct lookup on the contract address is performed.\\n // If the result is not cached or the cached value is out-of-date, the cache MUST be updated manually by calling\\n // 'updateERC165Cache' with the contract address.\\n /// @param _contract Address of the contract to check.\\n /// @param _interfaceId ERC165 interface to check.\\n /// @return True if '_contract' implements '_interfaceId', false otherwise.\\n function implementsERC165Interface(address _contract, bytes4 _interfaceId) public view returns (bool) {\\n if (!erc165Cached[_contract][_interfaceId]) {\\n return implementsERC165InterfaceNoCache(_contract, _interfaceId);\\n }\\n return interfaces[_contract][_interfaceId] == _contract;\\n }\\n\\n /// @notice Checks whether a contract implements an ERC165 interface or not without using nor updating the cache.\\n /// @param _contract Address of the contract to check.\\n /// @param _interfaceId ERC165 interface to check.\\n /// @return True if '_contract' implements '_interfaceId', false otherwise.\\n function implementsERC165InterfaceNoCache(address _contract, bytes4 _interfaceId) public 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, INVALID_ID);\\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 /// @notice Checks whether the hash is a ERC165 interface (ending with 28 zeroes) or not.\\n /// @param _interfaceHash The hash to check.\\n /// @return True if '_interfaceHash' is an ERC165 interface (ending with 28 zeroes), false otherwise.\\n function isERC165Interface(bytes32 _interfaceHash) internal pure returns (bool) {\\n return _interfaceHash & 0x00000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF == 0;\\n }\\n\\n /// @dev Make a call on a contract without throwing if the function does not exist.\\n function noThrowCall(address _contract, bytes4 _interfaceId)\\n internal view returns (uint256 success, uint256 result)\\n {\\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 (4 + 32) bytes long\\n x, // Store output over input (saves space)\\n 0x20 // Outputs are 32 bytes long\\n )\\n\\n result := mload(x) // Load the result\\n }\\n }\\n}\\n\",\n \"keccak256\": \"0x64025ecebddb6e126a5075c1fd6c01de2840492668e2909cef7157040a9d1945\"\n }\n },\n \"version\": 1\n }\n```\n\n Interface Name\n\nAny interface name is hashed using keccak256 and sent to getInterfaceImplementer().\n\nIf the interface is part of a standard, it is best practice to explicitly state the interface name and link to this published ERC-1820 such that other people don’t have to come here to look up these rules.\n\nFor convenience, the registry provides a function to compute the hash on-chain:\n\nfunction interfaceHash(string _interfaceName) public pure returns(bytes32)\n\nCompute the keccak256 hash of an interface given its name.\n\n identifier: 65ba36c1\nparameters\n_interfaceName: Name of the interface.\nreturns: The keccak256 hash of an interface name.\n\n Approved ERCs\n\nIf the interface is part of an approved ERC, it MUST be named ERC###XXXXX where ### is the number of the ERC and XXXXX should be the name of the interface in CamelCase. \nThe meaning of this interface SHOULD be defined in the specified ERC.\n\nExamples:\n\n keccak256(\"ERC20Token\")\n keccak256(\"ERC777Token\")\n keccak256(\"ERC777TokensSender\")\n keccak256(\"ERC777TokensRecipient\")\n\n ERC-165 Compatible Interfaces\n\n The compatibility with ERC-165, including the ERC165 Cache, has been designed and developed with William Entriken.\n\nAny interface where the last 28 bytes are zeroes (0) SHALL be considered an ERC-165 interface.\n\nERC-165 Lookup\n\nAnyone can explicitly check if a contract implements an ERC-165 interface using the registry by calling one of the two functions below:\n\nfunction implementsERC165Interface(address _contract, bytes4 _interfaceId) public view returns (bool)\n\nChecks whether a contract implements an ERC-165 interface or not.\n\nIf the result is not cached a direct lookup on the contract address is performed.\n\nNOTE: If the result is not cached or the cached value is out-of-date, the cache MUST be updated manually by calling updateERC165Cache with the contract address.\n(See ERC165 Cache for more details.)\n\n identifier: f712f3e8\nparameters\n_contract: Address of the contract to check.\n_interfaceId: ERC-165 interface to check.\nreturns: true if _contract implements _interfaceId, false otherwise.\n\nfunction implementsERC165InterfaceNoCache(address _contract, bytes4 _interfaceId) public view returns (bool)\n\nChecks whether a contract implements an ERC-165 interface or not without using nor updating the cache.\n\n identifier: b7056765\nparameters\n_contract: Address of the contract to check.\n_interfaceId: ERC-165 interface to check.\nreturns: true if _contract implements _interfaceId, false otherwise.\n\nERC-165 Cache \n\nWhether a contract implements an ERC-165 interface or not can be cached manually to save gas.\n\nIf a contract dynamically changes its interface and relies on the ERC-165 cache of the ERC-1820 registry, the cache MUST be updated manually—there is no automatic cache invalidation or cache update. \nIdeally the contract SHOULD automatically update the cache when changing its interface. \nHowever anyone MAY update the cache on the contract’s behalf.\n\nThe cache update MUST be done using the updateERC165Cache function:\n\nfunction updateERC165Cache(address _contract, bytes4 _interfaceId) external\n\n identifier: a41e7d51\nparameters\n_contract: Address of the contract for which to update the cache.\n_interfaceId: ERC-165 interface for which to update the cache.\n\n Private User-defined Interfaces\n\nThis scheme is extensible. \nYou MAY make up your own interface name and raise awareness to get other people to implement it and then check for those implementations.\nHave fun but please, you MUST not conflict with the reserved designations above.\n\n Set An Interface For An Address\n\nFor any address to set a contract as the interface implementation, it must call the following function of the ERC-1820 registry:\n\nfunction setInterfaceImplementer(address _addr, bytes32 _interfaceHash, address _implementer) external\n\nSets the contract which implements a specific interface for an address.\n\nOnly the manager defined for that address can set it. \n(Each address is the manager for itself, see the manager section for more details.)\n\nNOTE: If _addr and _implementer are two different addresses, then:\n\n The _implementer MUST implement the ERC1820ImplementerInterface (detailed below).\n Calling canImplementInterfaceForAddress on _implementer with the given _addr and _interfaceHash MUST return the ERC1820_ACCEPT_MAGIC value.\n\nNOTE: The _interfaceHash MUST NOT be an ERC-165 interface—it MUST NOT end with 28 zeroes (0).\n\nNOTE: The _addr MAY be 0, then msg.sender is assumed. \nThis default value simplifies interactions via multisigs where the data of the transaction to sign is constant regardless of the address of the multisig instance.\n\n identifier: 29965a1d\nparameters\n_addr: Address for which to set the interface. (If _addr is the zero address then msg.sender is assumed.)\n_interfaceHash: Keccak256 hash of the name of the interface as a string, for example web3.utils.keccak256('ERC777TokensRecipient') for the ERC777TokensRecipient interface.\n_implementer: Contract implementing _interfaceHash for _addr.\n\n Get An Implementation Of An Interface For An Address\n\nAnyone MAY query the ERC-1820 Registry to obtain the address of a contract implementing an interface on behalf of some address using the getInterfaceImplementer function.\n\nfunction getInterfaceImplementer(address _addr, bytes32 _interfaceHash) external view returns (address)\n\nQuery if an address implements an interface and through which contract.\n\nNOTE: If the last 28 bytes of the _interfaceHash are zeroes (0), then the first 4 bytes are considered an ERC-165 interface and the registry SHALL forward the call to the contract at _addr to see if it implements the ERC-165 interface (the first 4 bytes of _interfaceHash). \nThe registry SHALL also cache ERC-165 queries to reduce gas consumption. Anyone MAY call the erc165UpdateCache function to update whether a contract implements an interface or not.\n\nNOTE: The _addr MAY be 0, then msg.sender is assumed. \nThis default value is consistent with the behavior of the setInterfaceImplementer function and simplifies interactions via multisigs where the data of the transaction to sign is constant regardless of the address of the multisig instance.\n\n identifier: aabbb8ca\nparameters\n_addr: Address being queried for the implementer of an interface. (If _addr is the zero address then msg.sender is assumed.)\n_interfaceHash: keccak256 hash of the name of the interface as a string. E.g. web3.utils.keccak256('ERC777Token')\nreturns: The address of the contract which implements the interface _interfaceHash for _addr or 0 if _addr did not register an implementer for this interface.\n\n Interface Implementation (ERC1820ImplementerInterface)\n\ninterface ERC1820ImplementerInterface {\n /// @notice Indicates whether the contract implements the interface `interfaceHash` for the address `addr` or not.\n /// @param interfaceHash keccak256 hash of the name of the interface\n /// @param addr Address for which the contract will implement the interface\n /// @return ERC1820_ACCEPT_MAGIC only if the contract implements `interfaceHash` for the address `addr`.\n function canImplementInterfaceForAddress(bytes32 interfaceHash, address addr) external view returns(bytes32);\n}\n\nAny contract being registered as the implementation of an interface for a given address MUST implement said interface. \nIn addition if it implements an interface on behalf of a different address, the contract MUST implement the ERC1820ImplementerInterface shown above.\n\nfunction canImplementInterfaceForAddress(bytes32 interfaceHash, address addr) external view returns(bytes32)\n\nIndicates whether a contract implements an interface (interfaceHash) for a given address (addr).\n\nIf a contract implements the interface (interfaceHash) for a given address (addr), it MUST return ERC1820_ACCEPT_MAGIC when called with the addr and the interfaceHash. \nIf it does not implement the interfaceHash for a given address (addr), it MUST NOT return ERC1820_ACCEPT_MAGIC.\n\n identifier: f0083250\nparameters\ninterfaceHash: Hash of the interface which is implemented\naddr: Address for which the interface is implemented\nreturns: ERC1820_ACCEPT_MAGIC only if the contract implements ìnterfaceHash for the address addr.\n\nThe special value ERC1820_ACCEPT_MAGIC is defined as the keccka256 hash of the string \"ERC1820_ACCEPT_MAGIC\".\n\nbytes32 constant internal ERC1820_ACCEPT_MAGIC = keccak256(abi.encodePacked(\"ERC1820_ACCEPT_MAGIC\"));\n\n The reason to return ERC1820_ACCEPT_MAGIC instead of a boolean is to prevent cases where a contract fails to implement the canImplementInterfaceForAddress but implements a fallback function which does not throw. In this case, since canImplementInterfaceForAddress does not exist, the fallback function is called instead, executed without throwing and returns 1. Thus making it appear as if canImplementInterfaceForAddress returned true.\n\n Manager\n\nThe manager of an address (regular account or a contract) is the only entity allowed to register implementations of interfaces for the address. \nBy default, any address is its own manager.\n\nThe manager can transfer its role to another address by calling setManager on the registry contract with the address for which to transfer the manager and the address of the new manager.\n\nsetManager Function\n\nfunction setManager(address _addr, address _newManager) external\n\nSets _newManager as manager for _addr.\n\nThe new manager will be able to call setInterfaceImplementer for _addr.\n\nIf _newManager is 0x0, the manager is reset to _addr itself as the manager.\n\n identifier: 5df8122f\nparameters\n_addr: Address for which to set the new manager.\n_newManager: The address of the new manager for _addr. (Pass 0x0 to reset the manager to _addr.)\n\ngetManager Function\n\nfunction getManager(address _addr) public view returns(address)\n\nGet the manager of an address.\n\n identifier: 3d584063\nparameters\n_addr: Address for which to return the manager.\nreturns: Address of the manager for a given address.\n\n Rationale\n\nThis standards offers a way for any type of address (externally owned and contracts) to implement an interface and potentially delegate the implementation of the interface to a proxy contract. \nThis delegation to a proxy contract is necessary for externally owned accounts and useful to avoid redeploying existing contracts such as multisigs and DAOs.\n\nThe registry can also act as a ERC-165 cache in order to save gas when looking up if a contract implements a specific ERC-165 interface. \nThis cache is intentionally kept simple, without automatic cache update or invalidation. \nAnyone can easily and safely update the cache for any interface and any contract by calling the updateERC165Cache function.\n\nThe registry is deployed using a keyless deployment method relying on a single-use deployment address to ensure no one controls the registry, thereby ensuring trust.\n\n Backward Compatibility\n\nThis standard is backward compatible with ERC-165, as both methods MAY be implemented without conflicting with each other.\n\n Test Cases\n\nPlease check the 0xjac/ERC1820 repository for the full test suite.\n\n Implementation\n\nThe implementation is available in the repo: 0xjac/ERC1820.\n\n Copyright\n\nCopyright and related rights waived via CC0.\n\n Citation\n Please cite this document as:\n\n Jordi Baylina <jordi@baylina.cat>, Jacques Dafflon <mail@0xjac.com>, \"ERC-1820: Pseudo-introspection Registry Contract,\" Ethereum Improvement Proposals, no. 1820, March 2019. Available: https://eips.ethereum.org/EIPS/eip-1820.","tokens":12401,"squid":"spider-05","role":"Spec Spider","at":1791341691864,"hash":"dc1451e1a3c0a46b5e7efb55e3b315226271f926"}
{"url":"https://eips.ethereum.org/EIPS/eip-820","domain":"eips.ethereum.org","title":"ERC-820: Pseudo-introspection Registry Contract","text":"🎉 Final\n\n Standards Track: ERC\n\n ERC-820: Pseudo-introspection Registry Contract\n\n Authors\n Jordi Baylina <jordi@baylina.cat>, Jacques Dafflon <jacques@dafflon.tech>\n\n Created\n 2018-01-05\n\n Requires\n\n EIP-165, \n\n EIP-214\n\n :information_source: ERC-1820 has superseded ERC-820. :information_source:\nERC-1820 fixes the incompatibility in the ERC-165 logic which was introduced by the Solidty 0.5 update.\nHave a look at the official announcement, and the comments about the bug and the fix.\nApart from this fix, ERC-1820 is functionally equivalent to ERC-820.\n\n :warning: ERC-1820 MUST be used in lieu of ERC-820. :warning:\n\n Simple Summary\n\nThis standard defines a universal registry smart contract where any address (contract or regular account) can register which interface it supports and which smart contract is responsible for its implementation.\n\nThis standard keeps backward compatibility with ERC-165.\n\n Abstract\n\nThis standard defines a registry where smart contracts and regular accounts can publish which functionalities they implement—either directly or through a proxy contract.\n\nAnyone can query this registry to ask if a specific address implements a given interface and which smart contract handles its implementation.\n\nThis registry MAY be deployed on any chain and shares the same address on all chains.\n\nInterfaces with zeroes (0) as the last 28 bytes are considered ERC-165 interfaces, and this registry SHALL forward the call to the contract to see if it implements the interface.\n\nThis contract also acts as an ERC-165 cache to reduce gas consumption.\n\n Motivation\n\nThere have been different approaches to define pseudo-introspection in Ethereum. The first is ERC-165 which has the limitation that it cannot be used by regular accounts. The second attempt is ERC-672 which uses reverse ENS. Using reverse ENS has two issues. First, it is unnecessarily complicated, and second, ENS is still a centralized contract controlled by a multisig. This multisig theoretically would be able to modify the system.\n\nThis standard is much simpler than ERC-672, and it is fully decentralized.\n\nThis standard also provides a unique address for all chains. Thus solving the problem of resolving the correct registry address for different chains.\n\n Specification\n\n ERC-820 Registry Smart Contract\n\n This is an exact copy of the code of the ERC820 registry smart contract.\n\n/* ERC820 Pseudo-introspection Registry Contract\n * This standard defines a universal registry smart contract where any address\n * (contract or regular account) can register which interface it supports and\n * which smart contract is responsible for its implementation.\n *\n * Written in 2018 by Jordi Baylina and Jacques Dafflon\n *\n * To the extent possible under law, the author(s) have dedicated all copyright\n * and related and neighboring rights to this software to the public domain\n * worldwide. This software is distributed without any warranty.\n *\n * You should have received a copy of the CC0 Public Domain Dedication along\n * with this software. If not, see\n * <https://creativecommons.org/publicdomain/zero/1.0/>.\n *\n * ███████╗██████╗ ██████╗ █████╗ ██████╗ ██████╗\n * ██╔════╝██╔══██╗██╔════╝██╔══██╗╚════██╗██╔═████╗\n * █████╗ ██████╔╝██║ ╚█████╔╝ █████╔╝██║██╔██║\n * ██╔══╝ ██╔══██╗██║ ██╔══██╗██╔═══╝ ████╔╝██║\n * ███████╗██║ ██║╚██████╗╚█████╔╝███████╗╚██████╔╝\n * ╚══════╝╚═╝ ╚═╝ ╚═════╝ ╚════╝ ╚══════╝ ╚═════╝\n *\n * ██████╗ ███████╗ ██████╗ ██╗███████╗████████╗██████╗ ██╗ ██╗\n * ██╔══██╗██╔════╝██╔════╝ ██║██╔════╝╚══██╔══╝██╔══██╗╚██╗ ██╔╝\n * ██████╔╝█████╗ ██║ ███╗██║███████╗ ██║ ██████╔╝ ╚████╔╝\n * ██╔══██╗██╔══╝ ██║ ██║██║╚════██║ ██║ ██╔══██╗ ╚██╔╝\n * ██║ ██║███████╗╚██████╔╝██║███████║ ██║ ██║ ██║ ██║\n * ╚═╝ ╚═╝╚══════╝ ╚═════╝ ╚═╝╚══════╝ ╚═╝ ╚═╝ ╚═╝ ╚═╝\n *\n */\npragma solidity 0.4.24;\n// IV is value needed to have a vanity address starting with `0x820`.\n// IV: 9513\n\n/// @dev The interface a contract MUST implement if it is the implementer of\n/// some (other) interface for any address other than itself.\ninterface ERC820ImplementerInterface {\n /// @notice Indicates whether the contract implements the interface `interfaceHash` for the address `addr` or not.\n /// @param interfaceHash keccak256 hash of the name of the interface\n /// @param addr Address for which the contract will implement the interface\n /// @return ERC820_ACCEPT_MAGIC only if the contract implements `interfaceHash` for the address `addr`.\n function canImplementInterfaceForAddress(bytes32 interfaceHash, address addr) external view returns(bytes32);\n}\n\n/// @title ERC820 Pseudo-introspection Registry Contract\n/// @author Jordi Baylina and Jacques Dafflon\n/// @notice This contract is the official implementation of the ERC820 Registry.\n/// @notice For more details, see https://eips.ethereum.org/EIPS/eip-820\ncontract ERC820Registry {\n /// @notice ERC165 Invalid ID.\n bytes4 constant INVALID_ID = 0xffffffff;\n /// @notice Method ID for the ERC165 supportsInterface method (= `bytes4(keccak256('supportsInterface(bytes4)'))`).\n bytes4 constant ERC165ID = 0x01ffc9a7;\n /// @notice Magic value which is returned if a contract implements an interface on behalf of some other address.\n bytes32 constant ERC820_ACCEPT_MAGIC = keccak256(abi.encodePacked(\"ERC820_ACCEPT_MAGIC\"));\n\n mapping (address => mapping(bytes32 => address)) interfaces;\n mapping (address => address) managers;\n mapping (address => mapping(bytes4 => bool)) erc165Cached;\n\n /// @notice Indicates a contract is the `implementer` of `interfaceHash` for `addr`.\n event InterfaceImplementerSet(address indexed addr, bytes32 indexed interfaceHash, address indexed implementer);\n /// @notice Indicates `newManager` is the address of the new manager for `addr`.\n event ManagerChanged(address indexed addr, address indexed newManager);\n\n /// @notice Query if an address implements an interface and through which contract.\n /// @param _addr Address being queried for the implementer of an interface.\n /// (If `_addr == 0` then `msg.sender` is assumed.)\n /// @param _interfaceHash keccak256 hash of the name of the interface as a string.\n /// E.g., `web3.utils.keccak256('ERC777Token')`.\n /// @return The address of the contract which implements the interface `_interfaceHash` for `_addr`\n /// or `0x0` if `_addr` did not register an implementer for this interface.\n function getInterfaceImplementer(address _addr, bytes32 _interfaceHash) external view returns (address) {\n address addr = _addr == 0 ? msg.sender : _addr;\n if (isERC165Interface(_interfaceHash)) {\n bytes4 erc165InterfaceHash = bytes4(_interfaceHash);\n return implementsERC165Interface(addr, erc165InterfaceHash) ? addr : 0;\n }\n return interfaces[addr][_interfaceHash];\n }\n\n /// @notice Sets the contract which implements a specific interface for an address.\n /// Only the manager defined for that address can set it.\n /// (Each address is the manager for itself until it sets a new manager.)\n /// @param _addr Address to define the interface for. (If `_addr == 0` then `msg.sender` is assumed.)\n /// @param _interfaceHash keccak256 hash of the name of the interface as a string.\n /// For example, `web3.utils.keccak256('ERC777TokensRecipient')` for the `ERC777TokensRecipient` interface.\n /// @param _implementer Contract address implementing _interfaceHash for _addr.\n function setInterfaceImplementer(address _addr, bytes32 _interfaceHash, address _implementer) external {\n address addr = _addr == 0 ? msg.sender : _addr;\n require(getManager(addr) == msg.sender, \"Not the manager\");\n\n require(!isERC165Interface(_interfaceHash), \"Must not be a ERC165 hash\");\n if (_implementer != 0 && _implementer != msg.sender) {\n require(\n ERC820ImplementerInterface(_implementer)\n .canImplementInterfaceForAddress(_interfaceHash, addr) == ERC820_ACCEPT_MAGIC,\n \"Does not implement the interface\"\n );\n }\n interfaces[addr][_interfaceHash] = _implementer;\n emit InterfaceImplementerSet(addr, _interfaceHash, _implementer);\n }\n\n /// @notice Sets the `_newManager` as manager for the `_addr` address.\n /// The new manager will be able to call `setInterfaceImplementer` for `_addr`.\n /// @param _addr Address for which to set the new manager.\n /// @param _newManager Address of the new manager for `addr`.\n function setManager(address _addr, address _newManager) external {\n require(getManager(_addr) == msg.sender, \"Not the manager\");\n managers[_addr] = _newManager == _addr ? 0 : _newManager;\n emit ManagerChanged(_addr, _newManager);\n }\n\n /// @notice Get the manager of an address.\n /// @param _addr Address for which to return the manager.\n /// @return Address of the manager for a given address.\n function getManager(address _addr) public view returns(address) {\n // By default the manager of an address is the same address\n if (managers[_addr] == 0) {\n return _addr;\n } else {\n return managers[_addr];\n }\n }\n\n /// @notice Compute the keccak256 hash of an interface given its name.\n /// @param _interfaceName Name of the interface.\n /// @return The keccak256 hash of an interface name.\n function interfaceHash(string _interfaceName) external pure returns(bytes32) {\n return keccak256(abi.encodePacked(_interfaceName));\n }\n\n /* --- ERC165 Related Functions --- */\n /* --- Developed in collaboration with William Entriken. --- */\n\n /// @notice Updates the cache with whether the contract implements an ERC165 interface or not.\n /// @param _contract Address of the contract for which to update the cache.\n /// @param _interfaceId ERC165 interface for which to update the cache.\n function updateERC165Cache(address _contract, bytes4 _interfaceId) external {\n interfaces[_contract][_interfaceId] = implementsERC165InterfaceNoCache(_contract, _interfaceId) ? _contract : 0;\n erc165Cached[_contract][_interfaceId] = true;\n }\n\n /// @notice Checks whether a contract implements an ERC165 interface or not.\n /// The result may be cached, if not a direct lookup is performed.\n /// @param _contract Address of the contract to check.\n /// @param _interfaceId ERC165 interface to check.\n /// @return `true` if `_contract` implements `_interfaceId`, false otherwise.\n function implementsERC165Interface(address _contract, bytes4 _interfaceId) public view returns (bool) {\n if (!erc165Cached[_contract][_interfaceId]) {\n return implementsERC165InterfaceNoCache(_contract, _interfaceId);\n }\n return interfaces[_contract][_interfaceId] == _contract;\n }\n\n /// @notice Checks whether a contract implements an ERC165 interface or not without using nor updating the cache.\n /// @param _contract Address of the contract to check.\n /// @param _interfaceId ERC165 interface to check.\n /// @return `true` if `_contract` implements `_interfaceId`, false otherwise.\n function implementsERC165InterfaceNoCache(address _contract, bytes4 _interfaceId) public 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, INVALID_ID);\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 /// @notice Checks whether the hash is a ERC165 interface (ending with 28 zeroes) or not.\n /// @param _interfaceHash The hash to check.\n /// @return `true` if the hash is a ERC165 interface (ending with 28 zeroes), `false` otherwise.\n function isERC165Interface(bytes32 _interfaceHash) internal pure returns (bool) {\n return _interfaceHash & 0x00000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF == 0;\n }\n\n /// @dev Make a call on a contract without throwing if the function does not exist.\n function noThrowCall(address _contract, bytes4 _interfaceId)\n internal view returns (uint256 success, uint256 result)\n {\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 0x08, // Inputs are 8 bytes long\n x, // Store output over input (saves space)\n 0x20 // Outputs are 32 bytes long\n )\n\n result := mload(x) // Load the result\n }\n }\n}\n\n Deployment Transaction\n\nBelow is the raw transaction which MUST be used to deploy the smart contract on any chain.\n\n0xf90a2a8085174876e800830c35008080b909d7608060405234801561001057600080fd5b506109b7806100206000396000f30060806040526004361061008d5763ffffffff7c010000000000000000000000000000000000000000000000000000000060003504166329965a1d81146100925780633d584063146100bf5780635df8122f146100fc57806365ba36c114610123578063a41e7d5114610155578063aabbb8ca14610183578063b7056765146101a7578063f712f3e8146101e9575b600080fd5b34801561009e57600080fd5b506100bd600160a060020a036004358116906024359060443516610217565b005b3480156100cb57600080fd5b506100e0600160a060020a0360043516610512565b60408051600160a060020a039092168252519081900360200190f35b34801561010857600080fd5b506100bd600160a060020a036004358116906024351661055e565b34801561012f57600080fd5b506101436004803560248101910135610655565b60408051918252519081900360200190f35b34801561016157600080fd5b506100bd600160a060020a0360043516600160e060020a0319602435166106e3565b34801561018f57600080fd5b506100e0600160a060020a036004351660243561076d565b3480156101b357600080fd5b506101d5600160a060020a0360043516600160e060020a0319602435166107e7565b604080519115158252519081900360200190f35b3480156101f557600080fd5b506101d5600160a060020a0360043516600160e060020a03196024351661089c565b6000600160a060020a0384161561022e5783610230565b335b90503361023c82610512565b600160a060020a03161461029a576040805160e560020a62461bcd02815260206004820152600f60248201527f4e6f7420746865206d616e616765720000000000000000000000000000000000604482015290519081900360640190fd5b6102a38361091c565b156102f8576040805160e560020a62461bcd02815260206004820152601960248201527f4d757374206e6f74206265206120455243313635206861736800000000000000604482015290519081900360640190fd5b600160a060020a038216158015906103195750600160a060020a0382163314155b156104a15760405160200180807f4552433832305f4143434550545f4d414749430000000000000000000000000081525060130190506040516020818303038152906040526040518082805190602001908083835b6020831061038d5780518252601f19909201916020918201910161036e565b51815160209384036101000a6000190180199092169116179052604080519290940182900382207f249cb3fa000000000000000000000000000000000000000000000000000000008352600483018a9052600160a060020a0388811660248501529451909650938816945063249cb3fa936044808401945091929091908290030181600087803b15801561042057600080fd5b505af1158015610434573d6000803e3d6000fd5b505050506040513d602081101561044a57600080fd5b5051146104a1576040805160e560020a62461bcd02815260206004820181905260248201527f446f6573206e6f7420696d706c656d656e742074686520696e74657266616365604482015290519081900360640190fd5b600160a060020a03818116600081815260208181526040808320888452909152808220805473ffffffffffffffffffffffffffffffffffffffff19169487169485179055518692917f93baa6efbd2244243bfee6ce4cfdd1d04fc4c0e9a786abd3a41313bd352db15391a450505050565b600160a060020a03808216600090815260016020526040812054909116151561053c575080610559565b50600160a060020a03808216600090815260016020526040902054165b919050565b3361056883610512565b600160a060020a0316146105c6576040805160e560020a62461bcd02815260206004820152600f60248201527f4e6f7420746865206d616e616765720000000000000000000000000000000000604482015290519081900360640190fd5b81600160a060020a031681600160a060020a0316146105e557806105e8565b60005b600160a060020a03838116600081815260016020526040808220805473ffffffffffffffffffffffffffffffffffffffff19169585169590951790945592519184169290917f605c2dbf762e5f7d60a546d42e7205dcb1b011ebc62a61736a57c9089d3a43509190a35050565b60008282604051602001808383808284378201915050925050506040516020818303038152906040526040518082805190602001908083835b602083106106ad5780518252601f19909201916020918201910161068e565b6001836020036101000a038019825116818451168082178552505050505050905001915050604051809103902090505b92915050565b6106ed82826107e7565b6106f85760006106fa565b815b600160a060020a03928316600081815260208181526040808320600160e060020a031996909616808452958252808320805473ffffffffffffffffffffffffffffffffffffffff19169590971694909417909555908152600284528181209281529190925220805460ff19166001179055565b60008080600160a060020a038516156107865784610788565b335b91506107938461091c565b156107b85750826107a4828261089c565b6107af5760006107b1565b815b92506107df565b600160a060020a038083166000908152602081815260408083208884529091529020541692505b505092915050565b60008080610815857f01ffc9a70000000000000000000000000000000000000000000000000000000061093e565b9092509050811580610825575080155b1561083357600092506107df565b61084585600160e060020a031961093e565b909250905081158061085657508015155b1561086457600092506107df565b61086e858561093e565b90925090506001821480156108835750806001145b1561089157600192506107df565b506000949350505050565b600160a060020a0382166000908152600260209081526040808320600160e060020a03198516845290915281205460ff1615156108e4576108dd83836107e7565b90506106dd565b50600160a060020a03808316600081815260208181526040808320600160e060020a0319871684529091529020549091161492915050565b7bffffffffffffffffffffffffffffffffffffffffffffffffffffffff161590565b6040517f01ffc9a7000000000000000000000000000000000000000000000000000000008082526004820183905260009182919060208160088189617530fa9051909690955093505050505600a165627a7a723058204fc4461c9d5a247b0eafe0f9c508057bc0ad72bc24668cb2a35ea65850e10d3100291ba08208208208208208208208208208208208208208208208208208208208208200a00820820820820820820820820820820820820820820820820820820820820820\n\nThe strings of 820’s at the end of the transaction are the r and s of the signature. From this deterministic pattern (generated by a human), anyone can deduce that no one knows the private key for the deployment account.\n\n Deployment Method\n\nThis contract is going to be deployed using the keyless deployment method—also known as Nick’s method—which relies on a single-use address. (See Nick’s article for more details). This method works as follows:\n\n Generate a transaction which deploys the contract from a new random account.\n\n This transaction MUST NOT use EIP-155 in order to work on any chain.\n This transaction MUST have a relatively high gas price to be deployed on any chain. In this case, it is going to be 100 Gwei.\n\n Set the v, r, s of the transaction signature to the following values:\n\n v: 27\nr: 0x8208208208208208208208208208208208208208208208208208208208208200\ns: 0x0820820820820820820820820820820820820820820820820820820820820820\n\n Those r and s values—made of a repeating pattern of 820’s—are predictable “random numbers” generated deterministically by a human.\n\n The values of r and s must be 32 bytes long each—or 64 characters in hexadecimal. Since 820 is 3 characters long and 3 is not a divisor of 64, but it is a divisor of 63, the r and s values are padded with one extra character.\nThe s value is prefixed with a single zero (0). The 0 prefix also guarantees that s < secp256k1n ÷ 2 + 1.\nThe r value, cannot be prefixed with a zero, as the transaction becomes invalid. Instead it is suffixed with a zero (0) which still respects the condition s < secp256k1n.\n\n We recover the sender of this transaction, i.e., the single-use deployment account.\n\n Thus we obtain an account that can broadcast that transaction, but we also have the warranty that nobody knows the private key of that account.\n\n Send exactly 0.08 ethers to this single-use deployment account.\n\n Broadcast the deployment transaction.\n\nThis operation can be done on any chain, guaranteeing that the contract address is always the same and nobody can use that address with a different contract.\n\n Single-use Registry Deployment Account\n\n0xE6C244a1C10Aa0085b0cf92f04cdaD947C2988b8\n\nThis account is generated by reverse engineering it from its signature for the transaction. This way no one knows the private key, but it is known that it is the valid signer of the deployment transaction.\n\n To deploy the registry, 0.08 ethers MUST be sent to this account first.\n\n Registry Contract Address\n\n0x820b586C8C28125366C998641B09DCbE7d4cBF06\n\nThe contract has the address above for every chain on which it is deployed.\n\nRaw metadata of ./contracts/ERC820Registry.sol\n\n```json\n{\n \"compiler\": {\n \"version\": \"0.4.24+commit.e67f0147\"\n },\n \"language\": \"Solidity\",\n \"output\": {\n \"abi\": [\n {\n \"constant\": false,\n \"inputs\": [\n {\n \"name\": \"_addr\",\n \"type\": \"address\"\n },\n {\n \"name\": \"_interfaceHash\",\n \"type\": \"bytes32\"\n },\n {\n \"name\": \"_implementer\",\n \"type\": \"address\"\n }\n ],\n \"name\": \"setInterfaceImplementer\",\n \"outputs\": [],\n \"payable\": false,\n \"stateMutability\": \"nonpayable\",\n \"type\": \"function\"\n },\n {\n \"constant\": true,\n \"inputs\": [\n {\n \"name\": \"_addr\",\n \"type\": \"address\"\n }\n ],\n \"name\": \"getManager\",\n \"outputs\": [\n {\n \"name\": \"\",\n \"type\": \"address\"\n }\n ],\n \"payable\": false,\n \"stateMutability\": \"view\",\n \"type\": \"function\"\n },\n {\n \"constant\": false,\n \"inputs\": [\n {\n \"name\": \"_addr\",\n \"type\": \"address\"\n },\n {\n \"name\": \"_newManager\",\n \"type\": \"address\"\n }\n ],\n \"name\": \"setManager\",\n \"outputs\": [],\n \"payable\": false,\n \"stateMutability\": \"nonpayable\",\n \"type\": \"function\"\n },\n {\n \"constant\": true,\n \"inputs\": [\n {\n \"name\": \"_interfaceName\",\n \"type\": \"string\"\n }\n ],\n \"name\": \"interfaceHash\",\n \"outputs\": [\n {\n \"name\": \"\",\n \"type\": \"bytes32\"\n }\n ],\n \"payable\": false,\n \"stateMutability\": \"pure\",\n \"type\": \"function\"\n },\n {\n \"constant\": false,\n \"inputs\": [\n {\n \"name\": \"_contract\",\n \"type\": \"address\"\n },\n {\n \"name\": \"_interfaceId\",\n \"type\": \"bytes4\"\n }\n ],\n \"name\": \"updateERC165Cache\",\n \"outputs\": [],\n \"payable\": false,\n \"stateMutability\": \"nonpayable\",\n \"type\": \"function\"\n },\n {\n \"constant\": true,\n \"inputs\": [\n {\n \"name\": \"_addr\",\n \"type\": \"address\"\n },\n {\n \"name\": \"_interfaceHash\",\n \"type\": \"bytes32\"\n }\n ],\n \"name\": \"getInterfaceImplementer\",\n \"outputs\": [\n {\n \"name\": \"\",\n \"type\": \"address\"\n }\n ],\n \"payable\": false,\n \"stateMutability\": \"view\",\n \"type\": \"function\"\n },\n {\n \"constant\": true,\n \"inputs\": [\n {\n \"name\": \"_contract\",\n \"type\": \"address\"\n },\n {\n \"name\": \"_interfaceId\",\n \"type\": \"bytes4\"\n }\n ],\n \"name\": \"implementsERC165InterfaceNoCache\",\n \"outputs\": [\n {\n \"name\": \"\",\n \"type\": \"bool\"\n }\n ],\n \"payable\": false,\n \"stateMutability\": \"view\",\n \"type\": \"function\"\n },\n {\n \"constant\": true,\n \"inputs\": [\n {\n \"name\": \"_contract\",\n \"type\": \"address\"\n },\n {\n \"name\": \"_interfaceId\",\n \"type\": \"bytes4\"\n }\n ],\n \"name\": \"implementsERC165Interface\",\n \"outputs\": [\n {\n \"name\": \"\",\n \"type\": \"bool\"\n }\n ],\n \"payable\": false,\n \"stateMutability\": \"view\",\n \"type\": \"function\"\n },\n {\n \"anonymous\": false,\n \"inputs\": [\n {\n \"indexed\": true,\n \"name\": \"addr\",\n \"type\": \"address\"\n },\n {\n \"indexed\": true,\n \"name\": \"interfaceHash\",\n \"type\": \"bytes32\"\n },\n {\n \"indexed\": true,\n \"name\": \"implementer\",\n \"type\": \"address\"\n }\n ],\n \"name\": \"InterfaceImplementerSet\",\n \"type\": \"event\"\n },\n {\n \"anonymous\": false,\n \"inputs\": [\n {\n \"indexed\": true,\n \"name\": \"addr\",\n \"type\": \"address\"\n },\n {\n \"indexed\": true,\n \"name\": \"newManager\",\n \"type\": \"address\"\n }\n ],\n \"name\": \"ManagerChanged\",\n \"type\": \"event\"\n }\n ],\n \"devdoc\": {\n \"author\": \"Jordi Baylina and Jacques Dafflon\",\n \"methods\": {\n \"getInterfaceImplementer(address,bytes32)\": {\n \"params\": {\n \"_addr\": \"Address being queried for the implementer of an interface. (If `_addr == 0` then `msg.sender` is assumed.)\",\n \"_interfaceHash\": \"keccak256 hash of the name of the interface as a string. E.g., `web3.utils.keccak256('ERC777Token')`.\"\n },\n \"return\": \"The address of the contract which implements the interface `_interfaceHash` for `_addr` or `0x0` if `_addr` did not register an implementer for this interface.\"\n },\n \"getManager(address)\": {\n \"params\": {\n \"_addr\": \"Address for which to return the manager.\"\n },\n \"return\": \"Address of the manager for a given address.\"\n },\n \"implementsERC165Interface(address,bytes4)\": {\n \"params\": {\n \"_contract\": \"Address of the contract to check.\",\n \"_interfaceId\": \"ERC165 interface to check.\"\n },\n \"return\": \"`true` if `_contract` implements `_interfaceId`, false otherwise.\"\n },\n \"implementsERC165InterfaceNoCache(address,bytes4)\": {\n \"params\": {\n \"_contract\": \"Address of the contract to check.\",\n \"_interfaceId\": \"ERC165 interface to check.\"\n },\n \"return\": \"`true` if `_contract` implements `_interfaceId`, false otherwise.\"\n },\n \"interfaceHash(string)\": {\n \"params\": {\n \"_interfaceName\": \"Name of the interface.\"\n },\n \"return\": \"The keccak256 hash of an interface name.\"\n },\n \"setInterfaceImplementer(address,bytes32,address)\": {\n \"params\": {\n \"_addr\": \"Address to define the interface for. (If `_addr == 0` then `msg.sender` is assumed.)\",\n \"_implementer\": \"Contract address implementing _interfaceHash for _addr.\",\n \"_interfaceHash\": \"keccak256 hash of the name of the interface as a string. For example, `web3.utils.keccak256('ERC777TokensRecipient')` for the `ERC777TokensRecipient` interface.\"\n }\n },\n \"setManager(address,address)\": {\n \"params\": {\n \"_addr\": \"Address for which to set the new manager.\",\n \"_newManager\": \"Address of the new manager for `addr`.\"\n }\n },\n \"updateERC165Cache(address,bytes4)\": {\n \"params\": {\n \"_contract\": \"Address of the contract for which to update the cache.\",\n \"_interfaceId\": \"ERC165 interface for which to update the cache.\"\n }\n }\n },\n \"title\": \"ERC820 Pseudo-introspection Registry Contract\"\n },\n \"userdoc\": {\n \"methods\": {\n \"getInterfaceImplementer(address,bytes32)\": {\n \"notice\": \"Query if an address implements an interface and through which contract.\"\n },\n \"getManager(address)\": {\n \"notice\": \"Get the manager of an address.\"\n },\n \"implementsERC165Interface(address,bytes4)\": {\n \"notice\": \"Checks whether a contract implements an ERC165 interface or not. The result may be cached, if not a direct lookup is performed.\"\n },\n \"implementsERC165InterfaceNoCache(address,bytes4)\": {\n \"notice\": \"Checks whether a contract implements an ERC165 interface or not without using nor updating the cache.\"\n },\n \"interfaceHash(string)\": {\n \"notice\": \"Compute the keccak256 hash of an interface given its name.\"\n },\n \"setInterfaceImplementer(address,bytes32,address)\": {\n \"notice\": \"Sets the contract which implements a specific interface for an address. Only the manager defined for that address can set it. (Each address is the manager for itself until it sets a new manager.)\"\n },\n \"setManager(address,address)\": {\n \"notice\": \"Sets the `_newManager` as manager for the `_addr` address. The new manager will be able to call `setInterfaceImplementer` for `_addr`.\"\n },\n \"updateERC165Cache(address,bytes4)\": {\n \"notice\": \"Updates the cache with whether the contract implements an ERC165 interface or not.\"\n }\n }\n }\n },\n \"settings\": {\n \"compilationTarget\": {\n \"./contracts/ERC820Registry.sol\": \"ERC820Registry\"\n },\n \"evmVersion\": \"byzantium\",\n \"libraries\": {},\n \"optimizer\": {\n \"enabled\": true,\n \"runs\": 200\n },\n \"remappings\": []\n },\n \"sources\": {\n \"./contracts/ERC820Registry.sol\": {\n \"content\": \"/* ERC820 Pseudo-introspection Registry Contract\\n * This standard defines a universal registry smart contract where any address\\n * (contract or regular account) can register which interface it supports and\\n * which smart contract is responsible for its implementation.\\n *\\n * Written in 2018 by Jordi Baylina and Jacques Dafflon\\n *\\n * To the extent possible under law, the author(s) have dedicated all copyright\\n * and related and neighboring rights to this software to the public domain\\n * worldwide. This software is distributed without any warranty.\\n *\\n * You should have received a copy of the CC0 Public Domain Dedication along\\n * with this software. If not, see\\n * <https://creativecommons.org/publicdomain/zero/1.0/>.\\n *\\n * ███████╗██████╗ ██████╗ █████╗ ██████╗ ██████╗\\n * ██╔════╝██╔══██╗██╔════╝██╔══██╗╚════██╗██╔═████╗\\n * █████╗ ██████╔╝██║ ╚█████╔╝ █████╔╝██║██╔██║\\n * ██╔══╝ ██╔══██╗██║ ██╔══██╗██╔═══╝ ████╔╝██║\\n * ███████╗██║ ██║╚██████╗╚█████╔╝███████╗╚██████╔╝\\n * ╚══════╝╚═╝ ╚═╝ ╚═════╝ ╚════╝ ╚══════╝ ╚═════╝\\n *\\n * ██████╗ ███████╗ ██████╗ ██╗███████╗████████╗██████╗ ██╗ ██╗\\n * ██╔══██╗██╔════╝██╔════╝ ██║██╔════╝╚══██╔══╝██╔══██╗╚██╗ ██╔╝\\n * ██████╔╝█████╗ ██║ ███╗██║███████╗ ██║ ██████╔╝ ╚████╔╝\\n * ██╔══██╗██╔══╝ ██║ ██║██║╚════██║ ██║ ██╔══██╗ ╚██╔╝\\n * ██║ ██║███████╗╚██████╔╝██║███████║ ██║ ██║ ██║ ██║\\n * ╚═╝ ╚═╝╚══════╝ ╚═════╝ ╚═╝╚══════╝ ╚═╝ ╚═╝ ╚═╝ ╚═╝\\n *\\n */\\npragma solidity 0.4.24;\\n// IV is value needed to have a vanity address starting with `0x820`.\\n// IV: 9513\\n\\n/// @dev The interface a contract MUST implement if it is the implementer of\\n/// some (other) interface for any address other than itself.\\ninterface ERC820ImplementerInterface {\\n /// @notice Indicates whether the contract implements the interface `interfaceHash` for the address `addr` or not.\\n /// @param interfaceHash keccak256 hash of the name of the interface\\n /// @param addr Address for which the contract will implement the interface\\n /// @return ERC820_ACCEPT_MAGIC only if the contract implements `interfaceHash` for the address `addr`.\\n function canImplementInterfaceForAddress(bytes32 interfaceHash, address addr) external view returns(bytes32);\\n}\\n\\n\\n/// @title ERC820 Pseudo-introspection Registry Contract\\n/// @author Jordi Baylina and Jacques Dafflon\\n/// @notice This contract is the official implementation of the ERC820 Registry.\\n/// @notice For more details, see https://eips.ethereum.org/EIPS/eip-820\\ncontract ERC820Registry {\\n /// @notice ERC165 Invalid ID.\\n bytes4 constant INVALID_ID = 0xffffffff;\\n /// @notice Method ID for the ERC165 supportsInterface method (= `bytes4(keccak256('supportsInterface(bytes4)'))`).\\n bytes4 constant ERC165ID = 0x01ffc9a7;\\n /// @notice Magic value which is returned if a contract implements an interface on behalf of some other address.\\n bytes32 constant ERC820_ACCEPT_MAGIC = keccak256(abi.encodePacked(\\\"ERC820_ACCEPT_MAGIC\\\"));\\n\\n mapping (address => mapping(bytes32 => address)) interfaces;\\n mapping (address => address) managers;\\n mapping (address => mapping(bytes4 => bool)) erc165Cached;\\n\\n /// @notice Indicates a contract is the `implementer` of `interfaceHash` for `addr`.\\n event InterfaceImplementerSet(address indexed addr, bytes32 indexed interfaceHash, address indexed implementer);\\n /// @notice Indicates `newManager` is the address of the new manager for `addr`.\\n event ManagerChanged(address indexed addr, address indexed newManager);\\n\\n /// @notice Query if an address implements an interface and through which contract.\\n /// @param _addr Address being queried for the implementer of an interface.\\n /// (If `_addr == 0` then `msg.sender` is assumed.)\\n /// @param _interfaceHash keccak256 hash of the name of the interface as a string.\\n /// E.g., `web3.utils.keccak256('ERC777Token')`.\\n /// @return The address of the contract which implements the interface `_interfaceHash` for `_addr`\\n /// or `0x0` if `_addr` did not register an implementer for this interface.\\n function getInterfaceImplementer(address _addr, bytes32 _interfaceHash) external view returns (address) {\\n address addr = _addr == 0 ? msg.sender : _addr;\\n if (isERC165Interface(_interfaceHash)) {\\n bytes4 erc165InterfaceHash = bytes4(_interfaceHash);\\n return implementsERC165Interface(addr, erc165InterfaceHash) ? addr : 0;\\n }\\n return interfaces[addr][_interfaceHash];\\n }\\n\\n /// @notice Sets the contract which implements a specific interface for an address.\\n /// Only the manager defined for that address can set it.\\n /// (Each address is the manager for itself until it sets a new manager.)\\n /// @param _addr Address to define the interface for. (If `_addr == 0` then `msg.sender` is assumed.)\\n /// @param _interfaceHash keccak256 hash of the name of the interface as a string.\\n /// For example, `web3.utils.keccak256('ERC777TokensRecipient')` for the `ERC777TokensRecipient` interface.\\n /// @param _implementer Contract address implementing _interfaceHash for _addr.\\n function setInterfaceImplementer(address _addr, bytes32 _interfaceHash, address _implementer) external {\\n address addr = _addr == 0 ? msg.sender : _addr;\\n require(getManager(addr) == msg.sender, \\\"Not the manager\\\");\\n\\n require(!isERC165Interface(_interfaceHash), \\\"Must not be a ERC165 hash\\\");\\n if (_implementer != 0 && _implementer != msg.sender) {\\n require(\\n ERC820ImplementerInterface(_implementer)\\n .canImplementInterfaceForAddress(_interfaceHash, addr) == ERC820_ACCEPT_MAGIC,\\n \\\"Does not implement the interface\\\"\\n );\\n }\\n interfaces[addr][_interfaceHash] = _implementer;\\n emit InterfaceImplementerSet(addr, _interfaceHash, _implementer);\\n }\\n\\n /// @notice Sets the `_newManager` as manager for the `_addr` address.\\n /// The new manager will be able to call `setInterfaceImplementer` for `_addr`.\\n /// @param _addr Address for which to set the new manager.\\n /// @param _newManager Address of the new manager for `addr`.\\n function setManager(address _addr, address _newManager) external {\\n require(getManager(_addr) == msg.sender, \\\"Not the manager\\\");\\n managers[_addr] = _newManager == _addr ? 0 : _newManager;\\n emit ManagerChanged(_addr, _newManager);\\n }\\n\\n /// @notice Get the manager of an address.\\n /// @param _addr Address for which to return the manager.\\n /// @return Address of the manager for a given address.\\n function getManager(address _addr) public view returns(address) {\\n // By default the manager of an address is the same address\\n if (managers[_addr] == 0) {\\n return _addr;\\n } else {\\n return managers[_addr];\\n }\\n }\\n\\n /// @notice Compute the keccak256 hash of an interface given its name.\\n /// @param _interfaceName Name of the interface.\\n /// @return The keccak256 hash of an interface name.\\n function interfaceHash(string _interfaceName) external pure returns(bytes32) {\\n return keccak256(abi.encodePacked(_interfaceName));\\n }\\n\\n /* --- ERC165 Related Functions --- */\\n /* --- Developed in collaboration with William Entriken. --- */\\n\\n /// @notice Updates the cache with whether the contract implements an ERC165 interface or not.\\n /// @param _contract Address of the contract for which to update the cache.\\n /// @param _interfaceId ERC165 interface for which to update the cache.\\n function updateERC165Cache(address _contract, bytes4 _interfaceId) external {\\n interfaces[_contract][_interfaceId] = implementsERC165InterfaceNoCache(_contract, _interfaceId) ? _contract : 0;\\n erc165Cached[_contract][_interfaceId] = true;\\n }\\n\\n /// @notice Checks whether a contract implements an ERC165 interface or not.\\n /// The result may be cached, if not a direct lookup is performed.\\n /// @param _contract Address of the contract to check.\\n /// @param _interfaceId ERC165 interface to check.\\n /// @return `true` if `_contract` implements `_interfaceId`, false otherwise.\\n function implementsERC165Interface(address _contract, bytes4 _interfaceId) public view returns (bool) {\\n if (!erc165Cached[_contract][_interfaceId]) {\\n return implementsERC165InterfaceNoCache(_contract, _interfaceId);\\n }\\n return interfaces[_contract][_interfaceId] == _contract;\\n }\\n\\n /// @notice Checks whether a contract implements an ERC165 interface or not without using nor updating the cache.\\n /// @param _contract Address of the contract to check.\\n /// @param _interfaceId ERC165 interface to check.\\n /// @return `true` if `_contract` implements `_interfaceId`, false otherwise.\\n function implementsERC165InterfaceNoCache(address _contract, bytes4 _interfaceId) public 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, INVALID_ID);\\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 /// @notice Checks whether the hash is a ERC165 interface (ending with 28 zeroes) or not.\\n /// @param _interfaceHash The hash to check.\\n /// @return `true` if the hash is a ERC165 interface (ending with 28 zeroes), `false` otherwise.\\n function isERC165Interface(bytes32 _interfaceHash) internal pure returns (bool) {\\n return _interfaceHash & 0x00000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF == 0;\\n }\\n\\n /// @dev Make a call on a contract without throwing if the function does not exist.\\n function noThrowCall(address _contract, bytes4 _interfaceId)\\n internal view returns (uint256 success, uint256 result)\\n {\\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 0x08, // Inputs are 8 bytes long\\n x, // Store output over input (saves space)\\n 0x20 // Outputs are 32 bytes long\\n )\\n\\n result := mload(x) // Load the result\\n }\\n }\\n}\\n\",\n \"keccak256\": \"0x8eecce3912a15087b3f5845d5a74af7712c93d0a8fcd6f2d40f07ed5032022ab\"\n }\n },\n \"version\": 1\n}\n```\n\n Interface Name\n\nAny interface name is hashed using keccak256 and sent to getInterfaceImplementer().\n\nIf the interface is part of a standard, it is best practice to explicitly state the interface name and link to this published ERC-820 such that other people don’t have to come here to look up these rules.\n\nFor convenience, the registry provides a function to compute the hash on-chain:\n\nfunction interfaceHash(string _interfaceName) public pure returns(bytes32)\n\nCompute the keccak256 hash of an interface given its name.\n\n identifier: 65ba36c1\nparameters\n_interfaceName: Name of the interface.\nreturns: The keccak256 hash of an interface name.\n\n Approved ERCs\n\nIf the interface is part of an approved ERC, it MUST be named ERC###XXXXX where ### is the number of the ERC and XXXXX should be the name of the interface in CamelCase. The meaning of this interface SHOULD be defined in the specified ERC.\n\nExamples:\n\n keccak256(\"ERC20Token\")\n keccak256(\"ERC777Token\")\n keccak256(\"ERC777TokensSender\")\n keccak256(\"ERC777TokensRecipient\")\n\n ERC-165 Compatible Interfaces\n\n The compatibility with ERC-165, including the ERC165 Cache, has been designed and developed with William Entriken.\n\nAny interface where the last 28 bytes are zeroes (0) SHALL be considered an ERC-165 interface.\n\nERC-165 Lookup\n\nAnyone can explicitly check if a contract implements an ERC-165 interface using the registry by calling one of the two functions below:\n\nfunction implementsERC165Interface(address _contract, bytes4 _interfaceId) public view returns (bool)\n\nChecks whether a contract implements an ERC-165 interface or not.\n\nNOTE: The result is cached. If the cache is out of date, it MUST be updated by calling updateERC165Cache. (See ERC165 Cache for more details.)\n\n identifier: f712f3e8\nparameters\n_contract: Address of the contract to check.\n_interfaceId: ERC-165 interface to check.\nreturns: true if _contract implements _interfaceId, false otherwise.\n\nfunction implementsERC165InterfaceNoCache(address _contract, bytes4 _interfaceId) public view returns (bool)\n\nChecks whether a contract implements an ERC-165 interface or not without using nor updating the cache.\n\n identifier: b7056765\nparameters\n_contract: Address of the contract to check.\n_interfaceId: ERC-165 interface to check.\nreturns: true if _contract implements _interfaceId, false otherwise.\n\nERC-165 Cache \n\nWhether a contract implements an ERC-165 interface or not can be cached manually to save gas.\n\nIf a contract dynamically changes its interface and relies on the ERC-165 cache of the ERC-820 registry, the cache MUST be updated manually—there is no automatic cache invalidation or cache update. Ideally the contract SHOULD automatically update the cache when changing its interface. However anyone MAY update the cache on the contract’s behalf.\n\nThe cache update MUST be done using the updateERC165Cache function:\n\nfunction updateERC165Cache(address _contract, bytes4 _interfaceId) public\n\n identifier: a41e7d51\nparameters\n_contract: Address of the contract for which to update the cache.\n_interfaceId: ERC-165 interface for which to update the cache.\n\n Private User-defined Interfaces\n\nThis scheme is extensible. You MAY make up your own interface name and raise awareness to get other people to implement it and then check for those implementations. Have fun but please, you MUST not conflict with the reserved designations above.\n\n Set An Interface For An Address\n\nFor any address to set a contract as the interface implementation, it must call the following function of the ERC-820 registry:\n\nfunction setInterfaceImplementer(address _addr, bytes32 _interfaceHash, address _implementer) public\n\nSets the contract which implements a specific interface for an address.\n\nOnly the manager defined for that address can set it. (Each address is the manager for itself, see the manager section for more details.)\n\nNOTE: If _addr and _implementer are two different addresses, then:\n\n The _implementer MUST implement the ERC820ImplementerInterface (detailed below).\n Calling canImplementInterfaceForAddress on _implementer with the given _addr and _interfaceHash MUST return the ERC820_ACCEPT_MAGIC value.\n\nNOTE: The _interfaceHash MUST NOT be an ERC-165 interface—it MUST NOT end with 28 zeroes (0).\n\nNOTE: The _addr MAY be 0, then msg.sender is assumed. This default value simplifies interactions via multisigs where the data of the transaction to sign is constant regardless of the address of the multisig instance.\n\n identifier: 29965a1d\nparameters\n_addr: Address to define the interface for (if _addr == 0 them msg.sender: is assumed)\n_interfaceHash: keccak256 hash of the name of the interface as a string, for example web3.utils.keccak256('ERC777TokensRecipient') for the ERC777TokensRecipient interface.\n_implementer: Contract implementing _interfaceHash for _addr.\n\n Get An Implementation Of An Interface For An Address\n\nAnyone MAY query the ERC-820 Registry to obtain the address of a contract implementing an interface on behalf of some address using the getInterfaceImplementer function.\n\nfunction getInterfaceImplementer(address _addr, bytes32 _interfaceHash) public view returns (address)\n\nQuery if an address implements an interface and through which contract.\n\nNOTE: If the last 28 bytes of the _interfaceHash are zeroes (0), then the first 4 bytes are considered an ERC-165 interface and the registry SHALL forward the call to the contract at _addr to see if it implements the ERC-165 interface (the first 4 bytes of _interfaceHash). The registry SHALL also cache ERC-165 queries to reduce gas consumption. Anyone MAY call the erc165UpdateCache function to update whether a contract implements an interface or not.\n\nNOTE: The _addr MAY be 0, then msg.sender is assumed. This default value is consistent with the behavior of the setInterfaceImplementer function and simplifies interactions via multisigs where the data of the transaction to sign is constant regardless of the address of the multisig instance.\n\n identifier: aabbb8ca\nparameters\n_addr: Address being queried for the implementer of an interface. (If _addr == 0 them msg.sender is assumed.)\n_interfaceHash: keccak256 hash of the name of the interface as a string. E.g. web3.utils.keccak256('ERC777Token')\nreturns: The address of the contract which implements the interface _interfaceHash for _addr or 0x0 if _addr did not register an implementer for this interface.\n\n Interface Implementation (ERC820ImplementerInterface)\n\ninterface ERC820ImplementerInterface {\n /// @notice Indicates whether the contract implements the interface `interfaceHash` for the address `addr`.\n /// @param addr Address for which the contract will implement the interface\n /// @param interfaceHash keccak256 hash of the name of the interface\n /// @return ERC820_ACCEPT_MAGIC only if the contract implements `ìnterfaceHash` for the address `addr`.\n function canImplementInterfaceForAddress(bytes32 interfaceHash, address addr) public view returns(bytes32);\n}\n\nAny contract being registered as the implementation of an interface for a given address MUST implement said interface. In addition if it implements an interface on behalf of a different address, the contract MUST implement the ERC820ImplementerInterface shown above.\n\nfunction canImplementInterfaceForAddress(bytes32 interfaceHash, address addr) view public returns(bytes32);\n\nIndicates whether a contract implements an interface (interfaceHash) for a given address (addr).\n\nIf a contract implements the interface (interfaceHash) for a given address (addr), it MUST return ERC820_ACCEPT_MAGIC when called with the addr and the interfaceHash. If it does not implement the interfaceHash for a given address (addr), it MUST NOT return ERC820_ACCEPT_MAGIC.\n\n identifier: f0083250\nparameters\ninterfaceHash: Hash of the interface which is implemented\naddr: Address for which the interface is implemented\nreturns: ERC820_ACCEPT_MAGIC only if the contract implements ìnterfaceHash for the address addr.\n\nThe special value ERC820_ACCEPT_MAGIC is defined as the keccka256 hash of the string \"ERC820_ACCEPT_MAGIC\".\n\nbytes32 constant ERC820_ACCEPT_MAGIC = keccak256(\"ERC820_ACCEPT_MAGIC\");\n\n The reason to return ERC820_ACCEPT_MAGIC instead of a boolean is to prevent cases where a contract fails to implement the canImplementInterfaceForAddress but implements a fallback function which does not throw. In this case, since canImplementInterfaceForAddress does not exist, the fallback function is called instead, executed without throwing and returns 1. Thus making it appear as if canImplementInterfaceForAddress returned true.\n\n Manager\n\nThe manager of an address (regular account or a contract) is the only entity allowed to register implementations of interfaces for the address. By default, any address is its own manager.\n\nThe manager can transfer its role to another address by calling setManager on the registry contract with the address for which to transfer the manager and the address of the new manager.\n\nsetManager Function\n\nfunction setManager(address _addr, address _newManager) public\n\nSets the _newManager as manager for the _addr address.\n\nThe new manager will be able to call setInterfaceImplementer for _addr.\n\nIf _newManager is 0x0, the manager is reset to _addr itself as the manager.\n\n identifier: 5df8122f\nparameters\n_addr: Address for which to set the new manager.\n_newManager: The address of the new manager for _addr. (Pass 0x0 to reset the manager to _addr.)\n\ngetManager Function\n\nfunction getManager(address _addr) public view returns(address)\n\nGet the manager of an address.\n\n identifier: 3d584063\nparameters\n_addr: Address for which to return the manager.\nreturns: Address of the manager for a given address.\n\n Rationale\n\nThis standards offers a way for any type of address (externally owned and contracts) to implement an interface and potentially delegate the implementation of the interface to a proxy contract. This delegation to a proxy contract is necessary for externally owned accounts and useful to avoid redeploying existing contracts such as multisigs and DAOs.\n\nThe registry can also act as a ERC-165 cache in order to save gas when looking up if a contract implements a specific ERC-165 interface. This cache is intentionally kept simple, without automatic cache update or invalidation. Anyone can easily and safely update the cache for any interface and any contract by calling the updateERC165Cache function.\n\nThe registry is deployed using a keyless deployment method relying on a single-use deployment address to ensure no one controls the registry, thereby ensuring trust.\n\n Backward Compatibility\n\nThis standard is backward compatible with ERC-165, as both methods MAY be implemented without conflicting with each other.\n\n Test Cases\n\nPlease check the jbaylina/ERC820 repository for the full test suite.\n\n Implementation\n\nThe implementation is available in the repo: jbaylina/ERC820.\n\n Copyright\n\nCopyright and related rights waived via CC0.\n\n Citation\n Please cite this document as:\n\n Jordi Baylina <jordi@baylina.cat>, Jacques Dafflon <jacques@dafflon.tech>, \"ERC-820: Pseudo-introspection Registry Contract,\" Ethereum Improvement Proposals, no. 820, January 2018. Available: https://eips.ethereum.org/EIPS/eip-820.","tokens":12106,"squid":"spider-05","role":"Spec Spider","at":1791341701578,"hash":"fd0153009a49266fd24ad88dba1b464b7f5f31a5"}
{"url":"https://phantom.com/tokens/solana/orcaEKTdK7LKz57vaAYr9QeNsVEPfiu6QeMU1kektZE","domain":"phantom.com","title":"Orca (ORCA) Price Chart - Buy and Sell on Phantom","text":"Orca$3.03+$0.68+28.67%• TodayInfoNameOrcaSymbolORCANetworkSolanaMarket Cap$181MTotal Supply75MCirculating Supply60.8MHolders93,113Volume (24h)$37M+116.17%Trades (24h)262.87K+200.25%Traders (24h)6,766+311.56%All-Time High$8.05All-Time Low$0.42Liquidity$5.6MTop 10 Holders63.61%AboutOrca is the most user-friendly DEX on Solana.\n\nOrca is one of the first general-purpose AMMs launched on Solana. Users can swap assets, provide liquidity, and earn yield through an easy-to-use interface. Projects can use Orca as a money-lego to easily integrate swapping, farming, or on-chain data into their dApp.\n\nOrca strives to provide easy and effective financial tools for everyone, bringing DeFi to the masses.WebsiteDiscordXFAQThe market capitalization of ORCA is $181M as of Oct 6, 2026.Market capitalization is calculated by multiplying the current price of ORCA by its circulating supply. It reflects the overall value of the token in the market and helps gauge its relative size compared to other cryptocurrencies.The daily trading volume of ORCA is $37M as of Oct 6, 2026.Trading volume can fluctuate based on market conditions, investor activity, and overall demand for ORCA.The total supply of ORCA is 75M.The circulating supply, which represents the number of ORCA currently available in the market, is 60.8M as of Oct 6, 2026.ORCA can be bought and traded on a variety of cryptocurrency platforms, including Phantom!Pricing information is provided for informational purposes only and is not financial advice. Market data is provided by third parties and Phantom makes no representation as to the accuracy of the information.Buy Orca with the Mobile AppTrade from your desktop browserTrade OrcaTrending Tokensauton$0.0050019AUTON+103,767.97%DarkSwap$0.00218255DARK+49.67%Orca$3.04ORCA+29.06%4Paid$0.00623962PAID+65.79%5test griffain.com$0.0237GRIFFAIN+23.41%6NEAR$4.98NEAR-6.09%7Jupiter$0.33JUP-4.93%8Tweetcraft$0.00085879TWEETCRAFT+8,529.49%9Raydium$2.15RAY+0.05%10No Risk No Rari$0.0016924RARI+8,081.88%Pricing information is provided for informational purposes only and is not financial advice. Market data is provided by third parties and Phantom makes no representation as to the accuracy of the information.Buy ORCA","tokens":555,"squid":"spider-10","role":"Tooling Spider","at":1791341718961,"hash":"4d3000c3380e001c8c1c6bea70b4ac0dedddedc5"}
{"url":"https://docs.arbitrum.foundation/how-tos/build-strong-delegate-platform","domain":"docs.arbitrum.foundation","title":"How to build a strong delegate platform | Arbitrum DAO - Governance docs","text":"✏️Request an updatePUBLIC PREVIEW DOCUMENTThis document is currently in public preview and may change significantly as feedback is captured from readers like you. Click the Request an update button at the top of this document or join the Arbitrum Discord to share your feedback.As a delegate of the ArbitrumDAO, you play a vital role in the governance and decision-making process used to govern both the DAO's protocol and its technologies. Your role is to represent the interests of token holders who have delegated their voting power to you, and to make informed decisions on their behalf. Whether you're a first-time delegate or a seasoned pro, building a strong delegate platform that's aligned with the interests and values of Ethereum at large is of critical importance. The following tips will help you build a strong, incentives-aligned delegate platform:Tip 1: Understand the Constitution​The first step in building a strong delegate platform is to develop a thorough understanding of The Constitution of the ArbitrumDAO. The Constitution outlines the governance structure of the DAO, including the roles and responsibilities of delegates, as well as the decision-making process. Review the comprehension check to test your knowledge of the Constitution.Tip 2: Communicate with token holders​As a delegate, it's important to maintain an open and transparent line of communication with the token holders you represent. This can include creating a website or social media presence where you can provide updates on your activities, answer questions, and solicit feedback. Ensure that your voters are informed of any important developments or changes related to the DAO by staying tuned in to the ArbitrumDAO governance forum. Continuously relaying important information to the token holders that you represent can help you build trust and credibility while positioning yourself as a valuable representative of the ArbitrumDAO community.Tip 3: Stay active in the community​Another key aspect of building a strong delegate platform is staying active in the community. This can include participating in discussions on the ArbitrumDAO governance forum, attending community events, participating in online discussions wherever relevant conversations are happening on social media, and contributing to the development of the DAO.Tip 4: Be transparent and accountable​Transparency and accountability are crucial for building a strong delegate platform. As a delegate, you have a responsibility to be transparent about your motivations and decisions, and to be accountable to the token holders you represent. This can include being open to feedback and criticism and being willing to answer questions and address concerns.Tip 5: Build a strong support system​Building a strong support system is essential for success as a delegate. This can include building relationships with key members of the community and developing a team to assist you with research, analysis, and decision-making. A strong support system can help you stay informed, make better decisions, and build a more effective delegate platform.Tip 6: Submit a delegate statement​Submit a delegate statement using the template posted in the delegate application template thread. Although delegate applications aren't required, the application template gives community members a standardized way to learn more about your qualifications and platform.Conclusion​As a delegate, you play a vital role in the governance and decision-making process of the DAO; a strong platform can help you be more effective in that role. Remember to stay informed, be transparent and accountable, and build a strong support system. And always try to stay in touch with your voters so you can meet their needs. If you have any questions or concerns, visit the ArbitrumDAO governance forum.Tip 1: Understand the ConstitutionTip 2: Communicate with token holdersTip 3: Stay active in the communityTip 4: Be transparent and accountableTip 5: Build a strong support systemTip 6: Submit a delegate statementConclusion","tokens":1013,"squid":"spider-07","role":"Council Spider","at":1791341726547,"hash":"27876aa9ae738ea13a9948dc010dfc0804d8a987"}
{"url":"https://docs.arbitrum.foundation/gentle-intro-dao-governance","domain":"docs.arbitrum.foundation","title":"A gentle introduction to the ArbitrumDAO | Arbitrum DAO - Governance docs","text":"✏️Request an updatePUBLIC PREVIEW DOCUMENTThis document is currently in public preview and may change significantly as feedback is captured from readers like you. Click the Request an update button at the top of this document or join the Arbitrum Discord to share your feedback.In a nutshell:Arbitrum Rollup and Arbitrum AnyTrust are protocols that make Ethereum transactions faster and cheaper. Developers use Arbitrum One and Arbitrum Nova, the chains that implement these protocols, respectively, to build user-friendly decentralized apps.The distribution of the $ARB governance token decentralizes governance of these protocols and their respective chains, as well as any future chains the ArbitrumDAO authorizes.$ARB tokens can be used to vote on ArbitrumDAO governance proposals, allowing $ARB holders to shape Arbitrum's future together.Token holders will be able to delegate their voting power to delegates.The $ARB airdrop began on 3/23/2023 and ended on 9/24/2023.You can become an ArbitrumDAO delegate by engaging with the Arbitrum community and convincing $ARB holders to delegate their votes to you, or by holding $ARB yourself.To build decentralized apps on Arbitrum, check out the developer docs.Hello! What's Arbitrum again?​Arbitrum is a protocol that makes Ethereum transactions faster and cheaper. Developers use Arbitrum to build user-friendly decentralized apps (dApps) that can take advantage of the scalability benefits of the Arbitrum Rollup and AnyTrust protocols.Arbitrum's flagship chain, Arbitrum One, was launched in 2021. This was quickly followed by the launch of Arbitrum Nova, a separate AnyTrust chain built for ultra low-cost transactions. In August 2022, Arbitrum One was upgraded to the Arbitrum Nitro stack, bringing a 7-10x upgrade to its scaling capabilities.The distribution of $ARB governance tokens decentralizes governance of Arbitrum One and Arbitrum Nova and their underlying protocols. $ARB tokens can be used to vote on ArbitrumDAO governance proposals, allowing $ARB holders to collectively shape the future of Arbitrum protocols and chains. Token holders can also delegate their voting power to delegates.What's governance?​Governance is the way that decisions get made. To understand what this means, let's compare traditional web2 governance to web3 governance.Web2 technologies are traditionally built by corporations governed by a board of directors. This board is usually a small group of people elected by shareholders.When a corporate decision needs to be made, members of the board meet and vote. The board's decision-making protocols aren't always visible to shareholders. Although the board has a fiduciary duty to its shareholders, shareholders must trust the board. This is a sort of social contract expressed as corporate legalese and enforced by law.Web3 technologies (like Arbitrum's protocols and chains) are often built initially by corporations governed by a board of directors. Once these technologies achieve product-market fit and a community of users and stakeholders develops, decision-making authority can be gradually decentralized. This is called progressive decentralization, and it's what Arbitrum is doing. Progressive decentralization is usually facilitated by three key ingredients:DAO formation: The ArbitrumDAO (decentralized autonomous organization) is a new entity with decision-making authority over the Arbitrum One and Arbitrum Nova chains, along with their underlying protocols. This DAO is governed by The Constitution of the ArbitrumDAO, which is a set of rules that describe how the DAO will operate. The Constitution is enshrined within a number of social contracts that are used by the ArbitrumDAO to govern itself and its technologies.Governance token launch: Ownership of governance tokens represents membership within the DAO. Token holders can vote on DAO proposals. Arbitrum's governance token is $ARB, and will be distributed to eligible wallet addresses via an upcoming airdrop.Code: DAO governance is usually facilitated by a series of open source smart contracts that enforce a specific decision-making protocol. These trustless smart contracts are used to gradually replace a traditional board's trusted social contract. ArbitrumDAO uses smart contracts to codify the decision-making protocol articulated within The Constitution of the ArbitrumDAO.So $ARB is a token, kind of like $ETH?​Kind of! Let's compare them:How $ETH and $ARB are similar:Both are powered by decentralized blockchain technology.Both can be owned by any cryptocurrency wallet that supports $ETH.Both can be bought, sold, and traded.How $ETH and $ARB are different:$ETH is a transactional token, while $ARB is a governance token.$ETH is used to pay for transaction fees, while $ARB is not.Governance of Arbitrum is facilitated by $ARB and governance smart contracts, while Ethereum's governance is handled socially.Holding $ARB gives you the ability to govern Arbitrum, while holding $ETH doesn't impact your ability to govern Ethereum's protocol.Why is this important?​Decentralization of Arbitrum's technology governance represents an important step towards community governance of Ethereum's scaling technologies, and further aligns the Arbitrum community's incentives with those of the Ethereum community at large. This is a big deal because it means that the ArbitrumDAO will be able to democratically make decisions that are in the best interest of the Arbitrum and Ethereum communities, rather than having faith in the good will of a small group of people.$ARB tokens represent stake in Arbitrum's - and by proxy, Ethereum's - decentralized future. You can use $ARB to collectively determine how we as a community scale Ethereum's infinite garden into the future.More generally, possession of $ARB tokens places you at the cutting edge of governance mechanism design. This is a new frontier with society-scale implications, and your voice matters. $ARB tokens give you an immutable voice!See State of decentralization for a more in-depth overview of Arbitrum's decentralization journey.Cool beans. Was there an airdrop?​The airdrop ended on 9/24/23; claiming is no longer live. See Airdrop eligibility and token distribution details for more information.How does Arbitrum's governance work?​Governance of the Arbitrum Rollup protocol is driven by two governing bodies: the Security Council and the ArbitrumDAO.The Security Council is a 12-member council of entities elected by members of the ArbitrumDAO. This council is responsible for ensuring Arbitrum's security and performance through the selective application of emergency actions if/when necessary. See Delegates and delegation for a conceptual overview of ArbitrumDAO's delegation mechanics.The ArbitrumDAO is the worldwide community of $ARB token holders and the delegates that they select. The DAO is responsible for governing Arbitrum and its Security Council. The DAO can use constitutional proposals to modify the Security Council's powers, or even to eliminate the Security Council entirely. The Security Council's powers are delegated to the Security Council by the DAO, and are to be exercised in the best interests of the DAO. See ArbitrumDAO for an introductory overview of the DAO's various components.What sorts of decisions is Arbitrum’s governance system responsible for making?​Arbitrum's governance system is responsible for making many types of decisions. One important responsibility is upgrading Arbitrum chains’ core contracts, which define and enforce the Arbitrum protocols. An upgrade like this could be motivated by any of the following reasons:An upgrade could improve the system in some way, like increase its decentralization or optimize its performance and lower fees.An upgrade could fix a critical vulnerability.An upgrade could address a non-critical decision that affects the Arbitrum ecosystem at large.The ArbitrumDAO is also responsible for authorization of the creation of new L2 chains (see New Chains).Refer to the Constitution for a precise overview of the scope of the DAO's decision-making responsibilities. See Why governance? to learn more about the importance of governance. See Comprehension check to test your understanding of the Constitution's protocol.Who cares about this stuff?​You can think of Arbitrum stakeholder groups as a stack of layers. The web3 user layer is at the top of the stack. All other layers work together to support the web3 user layer:Web3 user layer: Includes decentralized app (dApp) users - users of web3 applications.Web3 app layer: Includes all of the developers, dreamers, and makers who are building decentralized apps and tooling to support dApp development.Layer 2 (L2): Includes ArbitrumDAO, the Arbitrum community, node operators, sequencers, and other Layer-2 builders (including Offchain) who are working hard to fulfill Ethereum's rollup-centric roadmap.Layer 1 (L1): Includes consensus & execution layers.Consensus layer (CL): Includes Prysm and other consensus-layer teams who support Ethereum's beacon chain with consensus-layer client software.Execution layer (EL): Includes Geth and other execution-layer teams building execution-layer client software.Research layer: Includes researchers and protocol engineers who are working on the cutting edge of cryptography, mechanism design, and governance protocols.All of these people can govern Arbitrum One and Arbitrum Nova?​Yep! As long as they either hold $ARB or are a delegate.What's a delegate again?​A delegate is like an elected representative. $ARB token holders can delegate their voting power to delegates.Why would I want to become a delegate?​There are a lot of people who don't have time to actively participate in protocol governance. Delegates help these people by offering to vote on their behalf.Delegates are a critical component of Arbitrum's decentralization because they allow token holders to passively participate in the governance of our technology. Although becoming a delegate is a serious responsibility that requires a significant time commitment, it allows you to ensure that Ethereum's values (and those of the delegators who have entrusted you with their voting power) are forever enshrined within the DAO's decisions and decision-making protocols. See How to become a listed delegate to learn more.I'd like to participate! What are my options?​Select a delegate to vote on your behalf. Choose this option if you're too busy to regularly vote on ArbitrumDAO proposals. See Delegate your voting power for detailed instructions.Self-delegate to vote directly on DAO proposals. Great for studious fans of direct democracy. See Vote on proposals for detailed instructions.Become a delegate to vote on behalf of token holders who entrust you with their voting power. Great for the community's most passionate evangelists. See Become a delegate for detailed instructions.Participate in governance discussions on the ArbitrumDAO governance forum.Join the community of Arbinauts on Discord.Where can I learn more?​You're in the right place! The following docs elaborate on the finer details of ArbitrumDAO and its underlying governance mechanisms:Airdrop eligibility and token distribution details: Tells you how $ARB eligibility was determined, and how $ARB tokens were initially distributed.The Constitution of the ArbitrumDAO: The human-readable governance protocol that the DAO's smart contracts implement.ArbitrumDAO Glossary: An index of governance terms and definitions.Where can I ask for help?​DiscordTelegramArbitrumDAO governance forumWelcome to the future of governance!Hello! What's Arbitrum again?What's governance?So $ARB is a token, kind of like $ETH?Why is this important?Cool beans. Was there an airdrop?How does Arbitrum's governance work?What sorts of decisions is Arbitrum’s governance system responsible for making?Who cares about this stuff?All of these people can govern Arbitrum One and Arbitrum Nova?What's a delegate again?Why would I want to become a delegate?I'd like to participate! What are my options?Where can I learn more?Where can I ask for help?","tokens":3020,"squid":"spider-07","role":"Council Spider","at":1791341736387,"hash":"fd7e672c18db2bda4e9d0ebd7ea80eaacbf40ac9"}
{"url":"https://docs.switchboard.xyz/how-it-works/switchboard-protocol/running-a-switchboard-oracle/configuration-tweaking-configurations","domain":"docs.switchboard.xyz","title":"Configuration: Tweaking Configurations | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.In the previous step we cloned locally the infra-external repo, but we're now focusing specifically on this section of the repo:infra-external/\n│\n└── cfg/\n │\n    ├── 00-common-vars.cfg\n    ├── 00-devnet-vars.cfg\n    └── 00-mainnet-vars.cfg\nYou will only have to edit the 00-common-vars.cfg file and the one targeting the Solana cluster you want your Oracle to work on.devnet is a good place to start and get acquainted with how our Oracle code works but then you can easily reproduce the same setup on mainnet at a later moment.Let's focus on one file at a time.PreviousRepo StructureNextcfg/00-common-vars.cfgLast updated 1 year ago","tokens":181,"squid":"spider-08","role":"Oracle Spider","at":1791341739336,"hash":"9260425b23e25b96355332404c1c2a900ed12db3"}
{"url":"https://docs.arbitrum.foundation/token-supply","domain":"docs.arbitrum.foundation","title":"What is the token circulating supply? | Arbitrum DAO - Governance docs","text":"✏️Request an updateWhat is a tokens circulating supply​A token's circulating supply is the amount of coins that are currently available to be transferred and utilized in the network. How can I calculate the Arbitrum token circulating supply​The circulating supply is based on the initial distribution and the unlock schedule of the team, investors, and contributors.\nYou can calculate the Arbitrum token's current circulating supply with the following formula:The team, contributor, and investor tokens unlock over a 4 year period, starting from 16 March 2023.\nThe first unlock starts on 16 March 2024, and continue to unlock on a monthly cadence.The Arbitrum Foundation tokens also unlock over a 4 year period, starting from 17 April 2023.\nThe first unlock starts on 17 April 2023, and continue to unlock every second.What is the current circulating supply​As of March 7 2024, the above formula results in 1.537 billion tokens total circulating supply.Allocated toTokens AllocatedIn circulation at March 7 2024ArbitrumDAO Treasury 13,528,000,000126,131,267Team and contributors2,694,000,0000Investors1,753,000,0000Users of platform (via airdrop)1,162,000,0001,092,551,615 2Arbitrum Foundation750,000,000205,715,264 3DAOs building on Arbitrum (via airdrop)113,000,000113,000,000Totals10,000,000,0001,537,398,145Note that numbers are rounded for presentation.On March 17 2024 it is expected that following the above formula the total circulating supply will be 2.654 billion tokens.Allocated toTokens AllocatedIn circulation at March 17 2024ArbitrumDAO Treasury 13,528,000,000126,131,267Team and contributors2,694,000,000673,500,000 4Investors1,753,000,000438,250,000 4Users of platform (via airdrop)1,162,000,0001,092,551,615 2Arbitrum Foundation750,000,000210,506,502 3DAOs building on Arbitrum (via airdrop)113,000,000113,000,000Totals10,000,000,0002,653,939,384Note that numbers are rounded for presentation.1 The ArbitrumDAO treasury is calculated as of March 7 2024 and can be viewed in https://arbiscan.io/token/0x912ce59144191c1204e64559fe8253a0e49e6548?a=0xF3FC178157fb3c87548bAA86F9d24BA38E649B58. The DAO treasury's circulating supply is based on tokens deployed by the DAO delegates in governance proposals.2 Tokens that were not claimed during the airdrop period were sent to the DAO treasury. They are now part of the treasury but here they are presented as tokens in circulation in the User section, for the presentation to consisently show the amount of tokens deployed by the DAO delegates in governance proposals.3 The amount unlocked by the Arbitrum Foundation is based on the 700 million tokens in the vesting contract, plus the 50 million tokens that were initially distributed.4 The team, investor, and contributor tokens unlocked are calculated as the number seconds in a year divided by 12 from March 16 2024.*Disclaimer: The total circulating supply of tokens displayed is the best estimate as of March 17, 2024, based on publicly available information. It may not always reflect the actual circulating supply due to factors such as additional distributions from the ArbitrumDAO Treasury or the unlocking of vesting contracts. This page will undergo regular updates to ensure alignment with the most accurate representation of the total circulating supply.*What is a tokens circulating supplyHow can I calculate the Arbitrum token circulating supplyWhat is the current circulating supply","tokens":853,"squid":"spider-07","role":"Council Spider","at":1791341756152,"hash":"2d670112a9bd6d75c908f823b7f098a4e1af20c1"}
{"url":"https://docs.arbitrum.foundation/new-arb-chains","domain":"docs.arbitrum.foundation","title":"Creating new Arbitrum chains | Arbitrum DAO - Governance docs","text":"✏️Request an updatePUBLIC PREVIEW DOCUMENTThis document is currently in public preview and may change significantly as feedback is captured from readers like you. Click the Request an update button at the top of this document or join the Arbitrum Discord to share your feedback.Rollup is the new server. In line with the rollup-centric roadmap of Ethereum, we anticipate the emergence of hundreds and thousands of rollups, dedicated to protecting users and their assets when interacting with an online service. The following section covers the basics on Arbitrum Orbit and the Arbitrum Expansion program, that enables projects to easily adopt the Arbitrum technology stack when deploying their own chain. Arbitrum Orbit​Arbitrum Orbit represents our strategy for enabling projects seeking to adopt the Arbitrum technology stack when deciding to deploy their own chain.There are many reasons why a project will decide to launch their chain using Arbitrum Orbit:Dedicated blockspace. Gain independence from chain usage by other applications.Custom gas token. Choose which token is used for chain fees allowing you to create native economies and utility incentives.Low latency. Orbit chains have demonstrated the ability to sustain ~100ms block times. Data availability layer choices. AnyTrust, Celestia, and more data availability solutions are already integrated into Arbiturm Orbit.No governance constraints. Control your own destiny; no need to submit to shared governance.Stage 1 rollup. External validation that the Arbitrum technology stack is amongst the best of all rollup implementations. In fact, Arbitrum One and Arbitrum Nova, can be considered the first Orbit Chains, to demonstrate the capability of the technology. The proven track record of the technology has led to an explosion of projects adopting the technology stack. To learn more, please visit the Arbitrum Orbit website which includes developer documentation.Arbitrum Expansion Program (AEP)​The Arbitrum Foundation, in consultation with the ArbitrumDAO [1,2,3], put together the Arbitrum Expansion Program to help enable projects to deploy and operate their own chain using the Arbitrum technology stack. The Arbitrum Expansion Program is designed to be a self-service path for any project seeking to adopt the Arbitrum Technology stack. It allows the project to fork the code and modify it according to their business needs alongside to deploy on any blockchain network. In return, the project is required to pay 10% of their chain’s profit back to the ArbitrumDAO with 8% distributed to the ArbitrumDAO’s treasury and 2% to a Arbitrum Protocol Developer guild. Our program is designed with the following spirit in mind:Permissionless. Any project can deploy a chain using the Arbitrum technology stack as long as they agree to opt-in to the Arbitrum Expansion Program. There is no need to contact the Arbitrum Foundation. Deploy on any chain. Projects are allowed to deploy an Orbit Chain on any blockchain network including Ethereum, Bitcoin, other L2s, etc. Modify & fork. Projects can modify the Arbitrum technology stack to suit their business needs.Value accrual. Support the Arbitrum ecosystem by sending a portion of the chain’s revenue back to the ArbitrumDAO and the Arbitrum Developer guild.Community enablement. Additional community-run features, alongside the software license, that will act as a supportive cornerstone for projects that adopt the Arbitrum technology stack.Freedom to innovate. There is no limitation on how a chain governs itself such as a requirement to submit to shared governance or other similar constraining structures.Put another way, you are free to adopt the Arbitrum technology stack, deploy your chain, expand the Ethereum ecosystem, and ultimately serve your users. In regards to the fee collection, we will update our documentation will further information shortly.Arbitrum OrbitArbitrum Expansion Program (AEP)","tokens":982,"squid":"spider-07","role":"Council Spider","at":1791341765998,"hash":"7a74878963a0fea46dc58a8af5a3133ed2642a10"}
{"url":"https://docs.switchboard.xyz/how-it-works/switchboard-protocol/running-your-own-queue","domain":"docs.switchboard.xyz","title":"Running your own Queue | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.Most integrations never need this page. Data feeds work out of the box on the shared Switchboard queues, which you load with getDefaultQueue() or getDefaultDevnetQueue() — see Oracle Queues for what a Queue is and why every feed belongs to one.Creating a Queue is permissionless. You may want your own if you need to:Control which oracles serve your feeds. Your Queue, your oracle set.Pin the exact software your oracles run, through the enclave measurement allowlist.Set your own reward and timeout parameters rather than inherit the network defaults.Isolate your feeds from load or incidents on the shared queues.The trade-off is that you now operate infrastructure: at least one oracle machine per queue, funded payer keys, and the upgrade discipline described in Creating an Oracle Queue.What is and is not permissionlessPermissionlessCreating an Oracle QueueYesPermissioning oracles onto your QueueYes — you are the queue authoritySetting your Queue's enclave allowlistYesRegistering a GuardianNo — see belowGuardians are the network-wide root of trust for TEE attestation, and there is a single Guardian Queue per Switchboard program deployment. Registering a guardian requires the program state authority, so on Switchboard's mainnet and devnet deployments you cannot add your own. Oracles on your Queue are attested by the existing guardians; your Queue's enclave allowlist is the control you own.If you need the entire trust chain, that means running your own program deployment — see Running a Guardian Queue.Before you startThe sb CLI. Every command here uses it — see CLI (npm i -g @switchboard-xyz/cli). Add --mainnetBeta for mainnet or --cluster devnet for devnet, and -k for the signer.A funded Solana keypair to act as queue authority.At least one oracle host. Oracles run in AMD SEV-SNP, and provisioning one is covered end to end in Running a Switchboard Oracle.NextCreating an Oracle QueueRunning a Guardian QueuePreviousBare Metal with Kubernetes (K3s) + AMD SEV SNPNextCreating an Oracle QueueLast updated 1 month ago","tokens":533,"squid":"spider-08","role":"Oracle Spider","at":1791341767687,"hash":"52a93156b781946977bf0ef8083cbc6947332a9b"}
{"url":"https://developer.arbitrum.io/notices/stylus-activation-pause-notice","domain":"developer.arbitrum.io","title":"Temporary pause on new Stylus activations","text":"Temporary pause on new Stylus activationsThe Arbitrum Security Council has temporarily paused new Stylus contract activations on Arbitrum One and Arbitrum Nova as a security measureRequest an updateThe Arbitrum Security Council has temporarily paused new contract on and as a security measure. To date, all Stylus findings from contracts that have been reviewed have only posed a denial-of-service risk to chain liveness and no user funds have been at risk.\nWhat this means for you\nYou cannot activate new or expired Stylus contracts on Arbitrum One or Arbitrum Nova while the pause is in effect.\nAlready activated Stylus contracts keep running until they expire. Calling them remains permissionless.\nYou can renew an active Stylus contract before it expires with the keepalive mechanism.\nSolidity and EVM contract deployment and execution are unaffected.\n\nTo learn why the Security Council took this action, read the forum post Security Council Emergency Action – 2/10/2026.\nWhat is paused\nThe pause applies to the activation step only. Activation is the step that makes a Stylus contract callable. To learn how deployment and activation work, refer to Activation.\n\nYou cannot activate a new Stylus contract. You also cannot reactivate a Stylus contract that has expired.\nStylus contracts that are active keep running until they expire. An activation lasts 365 days by default. To read the time left, call programTimeLeft.\nYou can renew an active Stylus contract before it expires. Call codehashKeepalive. By default, the contract must be at least 31 days old.\n\nWhat comes next\nWe remain confident in Stylus, which lets chain owners customize their networks and developers optimize key contracts. The Arbitrum Foundation will work with the on next steps for reopening activations in a way that preserves these uses while restricting hand-crafted WASM programs.How is this guide?NoticesUpgrade notices and required actions for Arbitrum chains and node operators.Glamsterdam compatibility notice for Arbitrum Sepolia chainsArbitrum Sepolia node operators and operators of Arbitrum chains settling on Ethereum Sepolia must prepare for the Glamsterdam activation on October 6, 2026","tokens":545,"squid":"spider-01","role":"Chain Spider","at":1791341768696,"hash":"430ccc6b8654f56f168ad536c306537c44430a9f"}
{"url":"https://docs.arbitrum.foundation/dao-comprehension-check","domain":"docs.arbitrum.foundation","title":"ArbitrumDAO: Comprehension check | Arbitrum DAO - Governance docs","text":"✏️Request an updatePUBLIC PREVIEW DOCUMENTThis document is currently in public preview and may change significantly as feedback is captured from readers like you. Click the Request an update button at the top of this document or join the Arbitrum Discord to share your feedback.Review the following scenarios to test your comprehension of the different components of the ArbitrumDAO protocol, such as the Security Council, AIPs, on-chain and off-chain actions. By exercising your understanding of these scenarios, you'll be better equipped to confidently navigate the process, technology, and governance proposals that support the ArbitrumDAO.Scenario 1: You have an idea that you'd like to propose to the ArbitrumDAO​What's the first step you should take?​The first step is to submit the idea as an Arbitrum Improvement Proposal (AIP) on the public ArbitrumDAO governance forum. After a week of discussion, it should be accompanied by an informal temperature check poll using the off-chain governance UI. This poll will run for 1 week while the AIP is discussed/debated. You'll then perform a more formal vote on the on-chain governance UI.This procedure is referred to as the Temperature Check phase within the Constitution and is technically optional, but it's strongly recommended as a due-diligence governance best practice. Although the process for submitting an AIP to the governance forum isn't explicitly outlined in the Constitution, the Constitution does specify that the DAO may approve and implement AIPs to change the rules governing the system. See How to submit a DAO proposal for more detailed instructions on how to submit an AIP.Scenario 2: A security emergency arises on one of the ArbitrumDAO-governed chains​How can the DAO respond to the security emergency?​The Security Council is a committee of 12 democratically elected members who are signers of a multi-sig wallet. This committee is afforded by the ArbitrumDAO the power to perform emergency actions and non-emergency actions, as delegated to it by the ArbitrumDAO and The Arbitrum Foundation, and is responsible for upholding the Constitution of the ArbitrumDAO. In this scenario, the Security Council should handle the emergency immediately by either implementing the required software upgrade or performing whatever other mitigating action is required in order to remedy the situation on behalf of the DAO and its members. This type of Security Council action is known as an emergency action and requires a 9-of-12 approval from the Security Council to execute. The Security Council shouldn't use its power to perform emergency actions except in a true security emergency, such as a critical vulnerability that could significantly compromise the integrity, confidentiality, or availability of a chain governed by the ArbitrumDAO. After performing an emergency action, the Security Council must issue a full transparency report to explain what was done and why the emergency action was justified. Notable details:The ArbitrumDAO is able to modify the Security Council's powers or to eliminate the Security Council entirely through the submission, approval and implementation of a Constitutional AIP.The ArbitrumDAO is able to curtail or eliminate the Security Council's power to perform emergency actions via approval and implementation of a Constitutional AIP.The Security Council may also approve and implement routine software upgrades, routine maintenance and other parameter adjustments in a non-emergency setting (such actions are referred to as \"non-emergency actions\"), which require a 9-of-12 approval in order to take effect.Equivalent \"copies\" of the Security Council multi-sig contracts (9-of-12, in the case of non-emergency actions, and 9-of-12, in the case of emergency actions) exist, one on Ethereum and another on each ArbitrumDAO-governed chain.Any non-emergency action, after approval by the Security Council, will bypass Phases 1 to 3 of the AIP process and instead directly go through Phases 4 to 7 of the AIP process, to provide a delay before any non-emergency action is deployed. The Security Council may optionally specify additional delays before deployment.Scenario 3: You want to propose a change to the system parameters of one of the ArbitrumDAO-governed chains​What process should be followed to implement this change?​The process for proposing and implementing changes to system parameters is as follows:Submit the proposal as an Arbitrum Improvement Proposal (AIP) on the public forum, which will be discussed and debated for 1 week (Temperature Check phase).The AIP moves to a voting phase, where token holders can vote on the proposal.If the proposal passes the vote, it moves to a delay period before implementation.After the delay period, the change can be implemented by the chain owner(s) through a transaction on the blockchain.Note that the Security Council may also approve and implement routine software upgrades, maintenance and other parameter adjustments in a non-emergency setting. This bypasses Phases 1 to 3 of the AIP process and goes directly through Phases 4 to 7. This is done to prevent routine upgrades and maintenance from being delayed or filibustered by the temperature check, voting, and delay phases of the AIP process.Scenario 4: You want to propose a change to the Constitution of the ArbitrumDAO​What process should be followed to implement this change?​The process for proposing and implementing changes to the Constitution is as described in the Constitution itself. It involves submitting the proposal as an AIP, and then going through the same voting and delay phases as any other proposal. The proposal must receive more votes in favor of the change and must reach its respective quorum threshold (see: Constitution).Scenario 5: You want to become a member of the Security Council​How can you become a member of the Security Council?​The Security Council has 12 members, who are divided into two cohorts of 6 members each. Every 12 months, an election occurs. Refer to the Constitution for more details on the election process.Scenario 6: You want to upgrade the Arbitrum One chain​What process should be followed to execute this upgrade?​The process for upgrading the Arbitrum One chain involves submitting a proposal as an AIP and going through the same voting and delay phases as any other proposal. The proposal must receive more votes in favor of the change and must reach its respective quorum threshold (see: Constitution). The chain owner(s) contract will then perform the upgrade by updating the contract implementation of any of Arbitrum's core protocol Transparent Upgradeable Proxy contracts, and adjusting system parameters (for example: through setter methods in the ArbOwner precompile).It's important to note that the upgrade should be thoroughly tested and reviewed by the community and experts in the field before being proposed and implemented. Any upgrade should also be compliant with the applicable laws, in particular sanctions-related regulations.Scenario 7: You've claimed $ARB tokens, but you don't have time to actively participate in ArbitrumDAO's governance.​What options do you have?​If you've claimed $ARB tokens but don't have time to actively participate in the ArbitrumDAO's governance, you have a few options:You can delegate your tokens' voting power to another member of the community who you trust to make decisions that align with your interests. See How to delegate your voting power for more information.You can hold onto your $ARB tokens and vote when you have the time, but please note that some important decisions may have already been made.You can sell or transfer your $ARB tokens to another member of the community who is more active.While participating in governance is an important aspect of being a DAO member, it's not mandatory. As long as you hold $ARB tokens, you can participate in the ArbitrumDAO's governance protocol, but there aren't any consequences if you decide to not participate.Scenario 8: A governance proposal passes that you voted against.​What options do you have?​If a governance proposal passes that you voted against, you have a few options:You can accept the outcome and continue to participate in the DAO. You can engage in further discussions and debates on the community forum to express your dissenting opinion and try to sway others to your point of view. You can propose a new AIP that addresses the issues you have with the proposal that passed and try to get it passed through the voting process. You can choose to disengage from the DAO altogether and sell your votable tokens before the proposal takes effect. This is facilitated by the time delay between the proposal passing and the proposal taking effect.Conclusion​This comprehension check has been provided as an optional study aid that token holders and prospective delegates are encouraged to periodically review, share, and build upon. If you have any questions or concerns, visit the ArbitrumDAO governance forum or Discord.Scenario 1: You have an idea that you'd like to propose to the ArbitrumDAOScenario 2: A security emergency arises on one of the ArbitrumDAO-governed chainsScenario 3: You want to propose a change to the system parameters of one of the ArbitrumDAO-governed chainsScenario 4: You want to propose a change to the Constitution of the ArbitrumDAOScenario 5: You want to become a member of the Security CouncilScenario 6: You want to upgrade the Arbitrum One chainScenario 7: You've claimed $ARB tokens, but you don't have time to actively participate in ArbitrumDAO's governance.Scenario 8: A governance proposal passes that you voted against.Conclusion","tokens":2416,"squid":"spider-07","role":"Council Spider","at":1791341775935,"hash":"fc1909936f00192f3c09baad527c11837e37e1d9"}
{"url":"https://docs.switchboard.xyz/how-it-works/switchboard-protocol/running-your-own-queue/running-a-guardian-queue","domain":"docs.switchboard.xyz","title":"Running a Guardian Queue | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.Guardians are the root of trust for TEE attestation. Before an oracle can serve data, it must prove to guardians that it is running approved software inside a genuine AMD SEV-SNP enclave. The Guardian Queue is the registry of the nodes allowed to make that judgement — see Node Architecture for where guardians sit in the network.Why this is not permissionlessUnlike an Oracle Queue, you cannot create a Guardian Queue that the network will honour, and you cannot add yourself to the existing one.There is one Guardian Queue per program deployment. It is a single field on the program's global state account. An Oracle Queue cannot nominate guardians of its own — attestation always resolves through the deployment's Guardian Queue.Registering a guardian requires the program state authority. On Switchboard's mainnet and devnet deployments that authority is Switchboard. If you want to operate a guardian on the main network, that is a conversation with the team, not a command you can run.So oracles on your own Oracle Queue are attested by Switchboard's guardians. What you control on your Queue is the enclave allowlist — which software you accept — and that is usually the control people actually want.Running your own Guardian Queue means running your own Switchboard program deployment. That is a legitimate thing to do for a private network, a testnet, or local development, and the rest of this page covers it.How attestation flowsWorth understanding before you operate any part of it:The oracle generates a SEV-SNP attestation report over a checksum binding its identity, its enclave measurement, a recent slot hash, and the public keys it intends to sign with.It sends that report to guardians on the Guardian Queue, through their public gateways.Each guardian verifies the report against AMD's certificate chain, recomputes the checksum, confirms it matches the report data, and returns a signature.The oracle submits those signatures on-chain to have its enclave marked verified. The guardian never transacts on the oracle's behalf.The now-verified oracle heartbeats onto its Oracle Queue and publishes its gateway URI.Attestations expire. Oracles re-attest on a rolling basis, and a Queue's maxQuoteVerificationAge bounds how long one stays valid.A guardian signs with its own authority key rather than an enclave-derived key — guardians are trusted by registration, not by measurement. They still run on SEV-SNP hardware, because the node image requires it.Running your own deploymentThis is for private networks, testnets and local development. Nothing here affects Switchboard's mainnet or devnet deployments.1. Deploy the Switchboard program and note its program ID. Pass --programId on every command below, or the CLI will target the canonical deployment instead of yours.2. Initialise the program state. There is no CLI command for this; call it through the SDK. The payer of that transaction becomes the state authority — the key that can register guardians.import { State } from '@switchboard-xyz/on-demand';\n\nconst [state, sig] = await State.create(program);3. Create a Queue to serve as the Guardian Queue, then point the state at it:sb solana on-demand queue init --cluster localnet -k --programId \n\nsb solana on-demand state configure --cluster localnet -k \\\n --programId \\\n --guardianQueue 4. Create and register your guardians:sb solana on-demand guardian create --cluster localnet -k \\\n --programId \n\nsb solana on-demand guardian register --cluster localnet -k \\\n --programId \\\n --guardian guardian create reads the Guardian Queue from the program state, so it takes no queue argument. guardian register must be signed by the state authority, and takes --disable to deregister.5. Create your Oracle Queues as normal, following Creating an Oracle Queue. They will attest through the guardians you just registered.Cold startThe first guardian has no one to attest it. The program handles this: while the Guardian Queue is empty, the on-chain signature check is skipped, so the first guardian can bootstrap itself. Every registration after that requires a signature from an already-registered guardian.Running a guardian nodeThe node software is the same image used for oracles, configured for the guardian role. Two things differ from an oracle deployment:A guardian must also run the gateway role. Oracles never reach the guardian service directly — they call the public gateway, which forwards inward. If the gateway cannot reach the local guardian service, every attestation through your node fails.Only the gateway should be publicly exposed. The guardian service itself is internal.Host provisioning — hardware, SEV-SNP enablement, Kubernetes — is identical to an oracle and is covered in Running a Switchboard Oracle.Verify a running guardian the same way as an oracle: it should appear on the Guardian Queue with heartbeat permission, a recent heartbeat, and a published gateway URI. Until that URI is on-chain, oracles cannot find it.TroubleshootingSymptomCauseOracles never select your guardianNo gateway URI on-chain — the gateway self-test is failing, or it is not verifiedAttestation requests fail at your gatewayThe gateway cannot reach the local guardian serviceAttestation reports fail verificationUsually the oracle's report, not your guardian — check the oracle's TEE stackguardian register is rejectedNot signed by the program state authorityPreviousCreating an Oracle QueueNextEnable Staking to your OracleLast updated 1 month ago","tokens":1392,"squid":"spider-08","role":"Oracle Spider","at":1791341777628,"hash":"5ba61ceabac39b0d5dcaf3316fc5f218552b6577"}
{"url":"https://developer.arbitrum.io/notices/arbos61-upgrade-notice","domain":"developer.arbitrum.io","title":"Upgrade notice for ArbOS 61","text":"Upgrade notice for ArbOS 61Upgrade notices for ArbOS 61 activation on Arbitrum One, Arbitrum Nova, and Arbitrum SepoliaRequest an update 61 \"Elara\" is active on Arbitrum Sepolia, , and . 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\n: 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 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 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 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 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 ran from July 16 to July 30, 2026. To learn more about the proposal, refer to the ArbOS 61 Elara AIP.How is this guide?Glamsterdam compatibility notice for Arbitrum Sepolia chainsArbitrum Sepolia node operators and operators of Arbitrum chains settling on Ethereum Sepolia must prepare for the Glamsterdam activation on October 6, 2026Upgrade notice for ArbOS 51Upgrade notices for ArbOS 51 activation on Arbitrum One, Arbitrum Nova, and Arbitrum Spolia","tokens":1035,"squid":"spider-01","role":"Chain Spider","at":1791341778898,"hash":"e2a7a32786b7ea6b3d7d3172230f3c91638eed15"}
{"url":"https://jup.ag/lend/borrow","domain":"jup.ag","title":"Borrow Against Your Crypto on Solana | Jupiter Lend","text":"Our new sUSDai loop is now live. Earn up to 27.15% at max leverage View loopGet a Loan with Crypto CollateralBorrow against your assets by selecting a Vault below$1.31B$745MTop VaultsSOL / USDCCreateTotal SuppliedSOL / USDTCreateTotal SuppliedSOL / EURCCreateTotal SuppliedJupSOL / SOLCreateTotal SuppliedJitoSOL / SOLCreateTotal SuppliedVault SelectVaultsjapanSOLDebtSOLLiq. Threshold 93%Market Size$6.09MSupplyapy5.61%Open japanSOL / SOL vaultnsP2PDebtSOLLiq. Threshold 88%Market Size$228KSupplyapy4.78%Open nsP2P / SOL vaultnsHELIUSDebtSOLLiq. Threshold 88%Market Size$20.9KSupplyapy5%Open nsHELIUS / SOL vaultnsJUPITERDebtSOLLiq. Threshold 88%Market Size$19.6KSupplyapy4.74%Open nsJUPITER / SOL vaultfwdSOLDebtSOLLiq. Threshold 95%Market Size$8.56KSupplyapy5.12%Open fwdSOL / SOL vaultnsNANSENDebtSOLLiq. Threshold 88%Market Size$1.79KSupplyapy5.1%Open nsNANSEN / SOL vaultnsDAWNDebtSOLLiq. Threshold 88%Market Size$6.9575Supplyapy5.16%Open nsDAWN / SOL vaultFAQsTaking out a loan on Jupiter Lend is done by creating a new borrowing position. Here’s how:Choose Your Pair: On this page, find the pair that matches the asset you want to supply as collateral and the asset you want to borrow (e.g., using SOL to borrow USDC). Create Position: Click the \"Create Position\" button for that specific pair. Deposit & Borrow: Deposit the asset you're supplying as collateral. Then borrow the other asset.The amount you can borrow depends on the value and type of collateral you supply. Each asset has a specific \"Loan-to-Value\" (LTV) ratio, which means for every $100 worth of collateral, you can borrow up to a certain amount (e.g., $75).You can see the specific LTV for each asset when you select it.This is the most important risk to understand when borrowing. To protect the health of Jupiter Lend, if the value of your collateral falls below a certain threshold, your position is at risk of liquidation. This means some of your collateral may be automatically sold to repay your loan.It is crucial to monitor your loan's health and either add more collateral or repay part of your loan if the value of your collateral decreases.Beyond the risk of liquidation, decentralized financial borrowing has other risks you should know:Smart Contract Risk: The potential for a bug or vulnerability in the code that could be exploited.Market Risk: The general volatility of crypto assets can affect the value of the collateral you provided for borrowing.Please use this product carefully and never borrow more than you can comfortably repay.The primary cost of borrowing is the variable interest rate you pay on your loan, which is clearly displayed for each asset.Check JupLend Guides","tokens":669,"squid":"spider-02","role":"Liquidity Spider","at":1791341793177,"hash":"7a5ce360cf11586c009c20765ca638154ce0d33d"}
{"url":"https://akash.network/roadmap/2021","domain":"akash.network","title":"Akash Network Roadmap - 2021","text":"Akash RoadmapAkash's roadmap outlines the high-level goals and priorities for the Akash Network.Year:2018201920202021202220232024202520262027aep-13Mainnet 2: DCX PlatformCompletion Date: 2/16/2021Akash's codebase is production-ready after testnet, with minor issues resolved. The team is updating to the final Stargate version of Cosmos-SDK, planning a mainnet upgrade for decentralized cloud and IBC integration. Akash Network will be an early IBC adopter. Significant changes in Stargate require coordination with partners for upgrades and testing, despite previous collaboration on CosmosHub testnets.aep-15Persistent StorageCompletion Date: 4/22/2021By default, Akash offers temporary storage that is wiped clean upon worload restarts. To maintain data integrity across reboots, we propose enabling persistent storage functionality, which ensures that information written to the disk remains intact.aep-14IBC InteroperabilityCompletion Date: 4/23/2021IBC (Inter-Blockchain Communication) is a protocol that allows different blockchain networks to communicate and exchange data with each other. In this context, IBC enables Akash to interact and share information with other blockchain networks that also support the IBC protocol.","tokens":308,"squid":"spider-03","role":"Compute Spider","at":1791341801286,"hash":"3f6177a5b4fc36ae2bfec0ebeee933ecd01e6b4c"}
{"url":"https://akash.network/roadmap/2023","domain":"akash.network","title":"Akash Network Roadmap - 2023","text":"Akash RoadmapAkash's roadmap outlines the high-level goals and priorities for the Akash Network.Year:2018201920202021202220232024202520262027aep-19Open Development ModelCompletion Date: 1/11/2023The Akash Network was created approximately two years ago to decentralize cloud infrastructure and put it in the hands of the people. It's now run by a network of globally distributed node operators who secure the Akash blockchain and provide cloud-grade server space for tenant applications. The source code developed by Overclock Labs has been open since inception, and now we are taking the next step of opening up the process that produces it. Removing single points of failure from one company makes Akash Network more resilient to institutional attack vectors.aep-23Multi Currency Support with Stable PaymentsCompletion Date: 8/28/2023Currently, the only supported form of payment and settlement on Akash Network is the network's native AKT coin. This creates several challenges for both providers and tenants, including, but not limited to, the following:aep-24GPU MarketplaceCompletion Date: 8/28/2023The advancement of artificial intelligence is constrained by the limited access to powerful GPUs. Despite the abundance of these processors in various organizations, individuals requiring them for AI research and development often struggle to utilize them. Implementing a GPU trading system on Akash would address this crucial bottleneck in AI progress, allowing for more efficient resource allocation and accelerating innovation in the field.","tokens":387,"squid":"spider-03","role":"Compute Spider","at":1791341811225,"hash":"d2189e00c865281177c2f7e3ba5be9416f38929f"}
{"url":"https://jup.ag/terminal","domain":"jup.ag","title":"Jupiter Spot: Solana Markets, News and Trading","text":"SpotMarket PulseBetaCrypto ETF flows were negative over one day, with Lookonchain reporting net outflows of 1,059 BTC and 21,432 ETH; its seven-day data showed mixed Bitcoin flows but continuing Ethereum outflows. CoinDesk’s X post says the CFTC is proposing a federal crypto rulebook, while FinCEN dropped its mixer-reporting proposal. Separately, the UK’s digital government-bond pilot targets issuance by the first quarter of 2027.7:17 PM7:17 PMSPCX-2.3%ZEC-1.29%ANTHROPIC-0.12%OTC-2.32%CARDS-1.19%GOOGLx-0.29%NVDAx+0.33%View allTWEETCRAFTMC $813K+73xAUTONMC $5.20M+1226xcashratMC $122K+13xDEXPADMC $45.1K+479.03%CLAUDIAMC $112K+24xORCATMC $99.1K+15xBP$1.09-11.13%AgencyMC $5.51M-16.3%CARDS$0.28383-1.19%STONK$0.19752+0.49%SIMC $23.2M-5.99%ORCASMMC $76.7K+563.56%Featured token listsxORCA$5.07MC $28.5M+37.5%RAY$2.16MC $583M+0.44%MET$0.31773MC $177M+9.67%NVDA$239.86MC $5.76T+0.4%AAPL$333.99MC $4.85T+0.33%GOOGL$348.10MC $4.23T+0.47%SmartMoney BuysMarket Dominance 24h-3%+3%9:56 PMJupiter","tokens":248,"squid":"spider-02","role":"Liquidity Spider","at":1791341813880,"hash":"eb87a833bf493b96d7301125267427d2ed28e545"}
{"url":"https://akash.network/roadmap/aep-24","domain":"akash.network","title":"GPU Marketplace","text":"Akash Network Roadmap Roadmap 2023 Q3 aep-24 GPU Marketplace Final Motivation\nThe advancement of artificial intelligence is constrained by the limited access to powerful GPUs. Despite the abundance of these processors in various organizations, individuals requiring them for AI research and development often struggle to utilize them. Implementing a GPU trading system on Akash would address this crucial bottleneck in AI progress, allowing for more efficient resource allocation and accelerating innovation in the field.\nSummary\nThe network’s sixth Mainnet upgrade brings GPU support, Stable Payments, and Take Rates to Akash. With this upgrade, providers on the network will be able to offer GPU resources to deployers around the world, and both providers and deployers will have access to USDC settlement. At settlement, the network will begin capturing value via Take Rates on both USDC and AKT.\nThe upgrade will bring the following features to Akash.\nGPU Marketplace\nThe main feature of the upgrade will enable an open-source marketplace for high-density GPUs. This will be accomplished by adapting Akash’s existing Supercloud infrastructure to allow network providers to support GPUs. This initial upgrade will focus support and testing on NVIDIA, given the AI and machine learning industry’s preference for NVIDIA GPUs. In the future, the network will focus support and testing on other manufacturers, including AMD and others.\nGPU support has already been validated in the Akash GPU Testnet (https://akash.network/blog/testing-the-first-ai-supercloud/) (a public beta test of the GPU network features, AI deployments, and benchmarking). Over 1,300 people signed up to participate, and the testnet hosted NVIDIA H100s, and A100s, along with consumer-grade GPUs from the 30-series and 40-series. Access to consumer-grade GPUs is one way the Akash Supercloud stands apart from other cloud providers. These models are typically overlooked, even though they can often run inference on less memory-intensive AI models. The flexibility to choose from the widest possible range of GPUs makes the Supercloud powerful.\nStable Payments\nThe second most anticipated feature of the upgrade is the addition of Stable Payments, which is part of the larger AKT 2.0 initiative (https://github.com/orgs/akash-network/discussions/32). Although many features and advantages are built into AKT, Akash’s native utility token, any token with inherent volatility presents a challenge to long-term providers and deployers. Significant price movements can drastically change the value of the cloud services rendered as part of the lease agreement coordinated through Akash’s open marketplace. One solution to the long-term volatility challenge is to incorporate alternative settlement currencies. For the rollout of Stable Payments, that currency will be USDC, a stablecoin pegged to the U.S. dollar. In the future, additional settlement currencies can be added with a simple governance proposal.\nTake Rates\nFor the network to capture value and direct resources toward building the network and rewarding participants, there must be a mechanism for the network to capture value.\nThe mechanism for capturing value at the network level is called Take Rates. These rates are applied to each lease and can be changed at any time with a governance vote. The network Take Rates will initially be set at 4% for AKT and 20% for USDC.\nRead the original draft proposal of both Stable Payments and Take Rates (https://github.com/orgs/akash-network/discussions/147) for an overview of the specific features of each.\nAkash Mainnet 6 Upgrade\nThis proposal is for upgrading the Akash Network to version v0.24.0 at a height 12606074 (https://www.mintscan.io/akash/blocks/12606074).\nBy voting YES on this proposal, you approve the following changes:\n\nThe introduction of deployment settlement and payment in IBC-enabled (non-AKT) currencies. Currencies can be added, removed, or modified by submitting ParamChange governance proposals.\nThe introduction of Take Fees for AKT Stakers. Take rates for each currency (including AKT) can be added, removed, or modified by submitting ParamChange governance proposals. This upgrade sets a 2% take rate for AKT.\nThe introduction of support for GPU deployments.\nEnforcing a Minimum Validators Commission using an on-chain parameter. The default value is set to 5%. During the upgrade, each validator with a commission of less than 5% will be updated to 5%.\nIntroducing a Minimum Initial Deposit for governance proposals using an on-chain parameter. The proposal originator must deposit at least the Minimum Initial Deposit for the proposal transaction to succeed. The default value is set to 40% of MinDeposit.\nThe fixing of dangling Escrow Payments. Some escrow payments remain open when the actual escrow account is closed.\nThe addition of a FeeGrant module. This module allows accounts to grant fee allowances and to use fees from their accounts. Grantees can execute any transaction without the need to maintain sufficient fees.\nThe upgrade of Cosmos SDK to v0.45.16.\nThe upgrade of IBC to v4.4.2.\n\nA detailed list of features, fixes, and improvements can be found in the changelog (https://github.com/akash-network/node/releases/tag/v0.24.0).\nUpgrade instructions are available in the upgrade docs (https://docs.akash.network/akash-v0.24.0-network-upgrade/v0.24.0-upgrade-docs).\nValidators and RPCs supervised by cosmovisor with DAEMON_ALLOW_DOWNLOAD_BINARIES=true will pick up upgrade binaries from upgrade info (https://raw.githubusercontent.com/akash-network/net/main/mainnet/upgrades/v0.24.0/info.json).\nAnnouncements\n\nThe Supercloud for AI is Live\n\nCopyright\nAll content herein is licensed under Apache 2.0. Completion date: 8/29/2023 Created: 8/22/2023 Last Updated: 12/1/2024 Category: Core Status: Final Authors: Greg Osuri Resolution: \nLink\n\nView next aep\n Provider Incentives Pilot (PIP)Completion Date: 2/8/2024Akash faces a critical shortage of high-density GPUs, particularly A100s, hindering new tenant acquisition. 91% of A100 GPUs are fully utilized, leaving no inventory for meaningful workloads.","tokens":1530,"squid":"spider-03","role":"Compute Spider","at":1791341821208,"hash":"1deef7426996151e83a034fb74b12de435447ba8"}
{"url":"https://jup.ag/tokens/BPxxfRCXkUVhig4HS1Lh7kZqV6SPJhzfEk4x6fVBjPCy","domain":"jup.ag","title":"BP ↑ $1.09 | Jupiter","text":"BP$1.0911.13%(24h)$1.0911.13%(24h)Liquidity$3.54MHolders28.1KOrg Score93.3Liquidity$3.54MHolders28.1KOrg Score93.3Org Score93.324h Vol$11.8M Net Vol$605K53% Sell24h Traders3.84K Net Buyers1.88K51% Sell24h Net Buy Trend$216K-$802KVol %Δ+138.98%Liquidity %Δ-13.14%Holders %Δ+1.08%Backpack upgraded its VIP program, adding qualification via asset balance, BP staking, or trading activity. Benefits include up to 6.5% APY on USD collateral, maker fees as low as 0%, and zero fees on global wire transfers.11h agoBP is the native Solana token of the Backpack ecosystem, powering trading fees and platform rewards. Users who stake BP for one year gain the right to exchange tokens for Backpack company equity at IPO or acquisition.Updated 4d agoBP$1.0911.13%(24h)Liquidity$3.54MHolders28.1KOrg Score93.3\n Jupiter/TypeBPVolumeTrader2sbuy$1.0965160$175.4523sbuy$1.096556.0$61.4123sbuy$1.0965248$271.9723sbuy$1.096548.0$52.6327sbuy$1.096656.3$61.8027sbuy$1.0965301$330.3037sbuy$1.09570.316$0.3468639sbuy$1.096580.0$87.7339ssell$1.09478.20$8.980939ssell$1.094165.9$72.1739sbuy$1.0965200$219.3349ssell$1.09473.00$3.284155ssell$1.09655.39$5.910655sbuy$1.09735.39$5.9151mbuy$1.09651.20K$1,316.991mbuy$1.0965907$995.301mbuy$1.0965907$995.301mbuy$1.09654.00K$4,389.9824h Vol$11.8MBuys21.5K/$5.60MSells19.5K/$6.20MNet Vol-$605KUltra95%YesYesBackpack upgraded its VIP program, adding qualification via asset balance, BP staking, or trading activity. Benefits include up to 6.5% APY on USD collateral, maker fees as low as 0%, and zero fees on global wire transfers.11h agoBP is the native Solana token of the Backpack ecosystem, powering trading fees and platform rewards. Users who stake BP for one year gain the right to exchange tokens for Backpack company equity at IPO or acquisition.Updated 4d ago","tokens":447,"squid":"spider-02","role":"Liquidity Spider","at":1791341824066,"hash":"4b17683a1258da2a371bb3e6d2def8a650b661d3"}
{"url":"https://jup.ag/tokens/So11111111111111111111111111111111111111112","domain":"jup.ag","title":"SOL ↓ $118.27 | Jupiter","text":"SOL$118.271.62%(24h)$118.271.62%(24h)Liquidity$981MHolders3.82MOrg Score99.2Liquidity$981MHolders3.82MOrg Score99.2Org Score99.224h Vol$3.50B Net Vol$30.5M50% Sell24h Traders1.21M Net Buyers113K91% Sell24h Net Buy Trend-$24.9M-$43.2MVol %Δ+3.23%Liquidity %Δ-0.46%Holders %Δ-Solana Foundation launched an open-source Delivery versus Payment settlement program enabling financial institutions to complete asset transfers and payments in seconds rather than days, with JPMorgan providing key inputs to the design.3h agoSOL is the native currency of Solana, a high-performance network enabling fast, secure, and affordable digital transactions powering payments, games, digital art, and financial services. SOL pays transaction fees and secures the network.Updated 4d agoSOL$118.271.62%(24h)Liquidity$981MHolders3.82MOrg Score99.2\n Jupiter/TypeSOLVolumeTrader1ssell$118.260.0731$8.64871sbuy$118.270.162$19.171ssell$118.260.145$17.221ssell$118.250.00440$0.520491sbuy$118.290.188$22.262sbuy$118.280.0419$4.9572ssell$118.250.143$16.952ssell$118.250.277$32.852ssell$118.260.575$68.092sbuy$118.280.0415$4.91532ssell$118.265.40$638.632ssell$118.250.287$34.022ssell$118.141.00$118.142sbuy$118.310.773$91.562ssell$118.250.0191$2.25862sbuy$118.410.173$20.492sbuy$118.290.422$49.992sbuy$118.280.0169$2.00624h Vol$3.50BBuys15.1M/$1.73BSells22.4M/$1.76BNet Vol-$30.5MUltra0.58%NoNoSolana Foundation launched an open-source Delivery versus Payment settlement program enabling financial institutions to complete asset transfers and payments in seconds rather than days, with JPMorgan providing key inputs to the design.3h agoSOL is the native currency of Solana, a high-performance network enabling fast, secure, and affordable digital transactions powering payments, games, digital art, and financial services. SOL pays transaction fees and secures the network.Updated 4d ago","tokens":465,"squid":"spider-02","role":"Liquidity Spider","at":1791341833429,"hash":"ff016471012606927c2cb37a6308584479a47fb2"}
{"url":"https://akash.network/roadmap/2025","domain":"akash.network","title":"Akash Network Roadmap - 2025","text":"Akash RoadmapAkash's roadmap outlines the high-level goals and priorities for the Akash Network.Year:2018201920202021202220232024202520262027aep-32Akash Provider Console 1.0Completion Date: 2/17/2025Make Akash Provider set up and management easy, with the goal of onboarding 100s of new providers. aep-61Enhanced Read Performance Onchain QueriesCompletion Date: 3/11/2025Improve the read performance of the blockchain API by optimizing prefixes in `x/stores` based on object states.aep-63Console API for Managed Wallet Users - v1Completion Date: 5/27/2025The number of Managed Wallet (Credit Card) users in Akash Console has grown significantly since launch. As these users and customers look to scale their applications they need a programmatic way to deploy and manage the lifecycle of their workloads on Akash so that they can scale up/ down in response to demand for their applications.aep-33Escrow Balance Alerts in Akash ConsoleCompletion Date: 6/29/2025One of the primary issues users face with Akash is the unexpected termination of leases due to depleted escrow funds. Implementing an alerting and notification system for this problem gives users the tools to monitor and take actions to alleviate the problem and associated frustration.aep-68Console - Billing & UsageCompletion Date: 7/30/2025As number of credit card users in Akash Console grows, a common request we here is being able to view usage and billing infoaep-75Multi-depositor escrow accountCompletion Date: 8/29/2025This AEP proposes enhancement of the `x/escrow` module with support of multiple funds depositors, enabling flexible fund management and improved automation workflows for deployment operations.aep-12Trusted Execution Environment (TEE)Estimated Completion: 9/29/2025Trusted Execution Environment (TEE) guarantees code and data loaded inside to be protected with respect to confidentiality and integrity that is enforced at the processor level.aep-30Cosmos SDK v0.53 MigrationCompletion Date: 10/27/2025Akash Network has been live for almost 4 years, and we have made incredible strides in decentralizing development, coordination, and funding.aep-64JWT Authentication for Provider APICompletion Date: 10/27/2025This AEP proposes implementing JWT (JSON Web Token) authentication for the Akash Provider API. This enhancement aims to improve the reliability of client API communication with leases during blockchain maintenance periods and provide more granular access control capabilities.aep-56Chain SDKCompletion Date: 10/29/2025Integrations are a key part of Akash's ecosystem growth strategy. In order for integrations to happen quicker Akash needs a feature rich and easy to use library for both blockchain nodes and provider nodes.aep-72Console - Improved User OnboardingCompletion Date: 11/6/2025Akash Console is the primary way that new users discover the magic of Akash Network and as such it is very important that the UX for getting them started be streamlined for maximum success along with somewhat generous trial credits comparable to other clouds (CSPs) in the industry.","tokens":768,"squid":"spider-03","role":"Compute Spider","at":1791341841187,"hash":"5bc41dbe88b9dccc9f289455f025038a98968bbd"}
{"url":"https://jup.ag/tokens/JUPyiwrYJFskUPiHa7hkeR8VUtAeFoSYbKedZNsDvCN","domain":"jup.ag","title":"JUP ↑ $0.33023 | Jupiter","text":"JUP$0.330235.13%(24h)$0.330235.13%(24h)Liquidity$5.84MHolders838KOrg Score98.7Liquidity$5.84MHolders838KOrg Score98.7Org Score98.724h Vol$14.5M Net Vol$628K52% Sell24h Traders14.8K Net Buyers1.81K88% Sell24h Net Buy Trend$368K-$628KVol %Δ+29.69%Liquidity %Δ-0.93%Holders %Δ-0.03%Jupiter announced it is the first platform to support Anza's new offchain message signing standard, enabling human-readable hardware wallet message signing for limit orders and DCA. The feature is live now with Ledger via Jupiter Wallet.3h agoJUP is the governance token of the Jupiter protocol on Solana, which operates Jupiter Perps, a perpetual futures exchange. Holders stake JUP to vote in the Jupiter DAO, earn quarterly ASR rewards, and benefit from Litterbox Trust buybacks.Updated 11h agoJUP$0.330235.13%(24h)Liquidity$5.84MHolders838KOrg Score98.7\n Jupiter/TypeJUPVolumeTrader1ssell$0.330130.0956$0.031581sbuy$0.330430.0956$0.031611ssell$0.330190.467$0.15421ssell$0.330191.99$0.660021ssell$0.330170.325$0.107461sbuy$0.330132.79$0.921542ssell$0.3302175$58.083ssell$0.330511.36$0.449633ssell$0.330382.19$0.723623sbuy$0.330153.55$1.17223ssell$0.330158.94$2.9543sbuy$0.329958.94$2.95223ssell$0.330781.71$0.568823sbuy$0.330221.71$0.567873ssell$0.329991.71$0.566913sbuy$0.330211.71$0.567574ssell$0.3299494.0$31.014ssell$0.3299917.2$5.691824h Vol$14.5MBuys77.1K/$6.94MSells76.5K/$7.57MNet Vol-$628KUltra15.47%NoNoJupiter announced it is the first platform to support Anza's new offchain message signing standard, enabling human-readable hardware wallet message signing for limit orders and DCA. The feature is live now with Ledger via Jupiter Wallet.3h agoJUP is the governance token of the Jupiter protocol on Solana, which operates Jupiter Perps, a perpetual futures exchange. Holders stake JUP to vote in the Jupiter DAO, earn quarterly ASR rewards, and benefit from Litterbox Trust buybacks.Updated 11h ago","tokens":473,"squid":"spider-02","role":"Liquidity Spider","at":1791341842945,"hash":"842c6e0c7e0d108567c7267cb802a7f3072646b7"}
{"url":"https://forum.across.to/t/reduce-acx-emissions-for-acx-lps-wbtc-lps-and-wsteth-acx-lps/1977/13","domain":"forum.across.to","title":"Reduce ACX emissions for ACX LPs, WBTC LPs and wstETH/ACX LPs - Proposals - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n Proposals\n\n treasury-funding\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 6\n min\n\n Aug 2024\n\n 13 / 13\n\n Sep 2024\n\n Aug 2024\n\n post by Kevin_UMA on Aug 15, 2024\n\n Kevin_UMA\n\n Title: Reduce ACX emissions for ACX LPs, WBTC LPs and wstETH/ACX LPs\nAuthors: ACX Emissions Committee (Kevin Chan, David Korpi, Ryan Carman, Dylan O’Reilly, Chase Coleman)\nStatus: Proposal\nRelated Discussions: ACX Emissions Committee, ACX Emissions Committee Framework Update, Reduce ACX emissions for Across ACX LP\nSummary:\nThe Across DAO should decrease ACX emissions for Across ACX LPs, Across WBTC LPs, and Balancer wstETH/ACX LPs. These liquidity pools are being rewarded a high APY in comparison to the utilization of the asset or the necessity of the liquidity. The ACX Emissions Committee (AEC) only has permissions and a framework to control ACX emissions for ETH, USDC, USDT, and DAI. Therefore, a separate proposal is required to modify emissions for the assets mentioned above. ACX emissions for ACX LPs, WBTC LPs, and wstETH/ACX LPs should be reduced by 50%, 30%, and 25% respectively.\nMotivation:\nThe Across DAO should optimally manage ACX emissions for all liquidity it incentivizes. The ACX Emissions Committee (AEC) accomplishes this using a transparent and restrictive framework to adjust emissions awarded to Across ETH, USDC, USDT, and DAI LPs. The framework monitors the utilization and comparable yield alternatives of each asset to make ACX emissions adjustments. Across ACX Lps and WBTC LPs sit outside of the AEC’s framework because these assets have limited yield alternatives to compare with outside of the Across protocol. Similarly, the Balancer wstETH/ACX LPs does not have equivalent variables that the AEC’s framework uses. As a result, managing the ACX emissions of these three LPs requires a separate DAO proposal given it is outside the scope of the AEC.\nThe Across DAO should decrease ACX emissions for Across ACX LPs, Across WBTC LPs, and Balancer wstETH/ACX LPs. These liquidity pools are being awarded a high APY in comparison to the utilization of the asset or the necessity of the liquidity.\nAcross ACX LP\nACX emissions for ACX LPs were initially set high to incentivize ACX airdrop recipients to not immediately sell their tokens and to get these token holders familiar with the reward locking mechanism. It’s been over 1.5 years since the launch of the token and the use of emissions in this way is not necessary. These emissions were reduced late last year, but a further reduction is now necessary. ACX utilization consistently sits close to zero given a lack of bridging needs (see Table 1). Yet, the emissions rate for the ACX LP is by far the highest at 26.7k ACX per day (see Table 3). The Across DAO should decrease ACX LP base emissions by 50% from 15k ACX per day to 7.5k ACX per day. (See Table 5 below for proposed changes.)\nAcross WBTC LP\nWBTC utilization on Across protocol has been relatively contained and has rarely exceeded 50% over the last few months (see Table 1). In comparison, USDT is more optimally utilized as its utilization has more frequently stayed above 50% and has reached over 80% on some occasions. The USDT serves bridge users well with only $6.6MM in total size in comparison to WBTC at $26.9MM which is about 4x bigger (see Table 2). This is driven by over 2x more emissions being paid to the WBTC LP (~8k ACX per day) vs the USDT LP (~3k ACX per day) - see Table 3. In addition, the WBTC APY is currently 5.27% which is very attractive considering DeFI lending protocols have consistently paid little to nothing. The WBTC LP can clearly be smaller in size. The Across DAO should decrease WBTC LP base emissions by 30% from 7.5k ACX per day to 5.25k ACX per day. (See Table 5 below for proposed changes.)\nBalancer wstETH/ACX LP\nThe Balancer wstETH/ACX LP is the second highest use of ACX emissions at 19k ACX per day (see Table 3). It is the only Reward Locking pool that still offers a 3x multiplier. As a result it pays the highest APY to LPs ranging from 20 to 52%! Offering these high ACX incentives may have been necessary at the launch of the token. However, Across protocol and the ACX token has gained brand recognition and these high rewards may not be needed. In addition, liquidity incentivized in this way may be less needed for two reasons\n\nThough modestly sized, Across DAO has close to $1MM of protocol owned liquidity through its proposal with Arrakis. The performance of this Uniswap v3 vault can be viewed here. If more liquidity is needed, Across DAO can continue to pursue this route and not pay emissions.\nACX is being listed in more centralized exchanges. Over the last few months Bitget, AscendEX, and Crypto.com have listed ACX. More recently, Coinbase has added ACX to its roadmap. Given this momentum, more exchange listings are expected. This would argue for less of a need to incentivize ACX DEX liquidity.\n\nACX liquidity on decentralized exchanges continues to be important and still represents a fair share of total volumes. However, the cost is high and the need for this has decreased. Therefore, a modest decrease in emissions here should be warranted. The Across DAO should decrease ACX emissions to the Balancer wstETH/ACX LP by 25% from 7k ACX per day to 5.25k ACX per day. (See Table 5 below for proposed changes.)\nTable 1 - ACX, WBTC, USDT Utilization\n1096×520 74.6 KB\nTable 2 - Across TVL of Liquidity Pools by Asset\n\nTable 3 - Current ACX Emission Rates\n752×270 14.5 KB\nTable 4 - Current Daily ACX Emissions Rate\n\nLiquidity Pool\nBase Emissions\nEffective Emissions with Multipliers\n\nAcross ACX\n15,000 ACX\n26,687 ACX\n\nAcross WBTC\n7,500 ACX\n8,032 ACX\n\nBPT wstETH/ACX\n7,000 ACX\n19,239 ACX\n\nTable 5 - Proposed Daily ACX Base Emissions Rate\n\nLiquidity Pool\nCurrent\nProposed\n\nAcross ACX\n15,000 ACX\n7,500 ACX\n\nAcross WBTC\n7,500 ACX\n5,250 ACX\n\nBPT wstETH/ACX\n7,000 ACX\n5,250 ACX\n\n(All data above is taken from the AEC Dune Dashboard.)\nSpecification & Implementation:\nThe Across DAO wallet controlled by ACX holders has admin rights to change the parameters of the Accelerating Distributor contract that controls ACX emissions and the Reward Locking program. The exact transactions to make these modifications can be put to a vote and executed on Snapshot via the oSnap module which is already implemented.\nThe proposed Snapshot vote and oSnap transaction will reflect a change in the following emission rates:\nAcross ACX LPs to ~7,500 ACX per day (from ~15,000 ACX per day currently)\nAcross WBTC LPs to ~5,250 ACX per day (from ~7,500 ACX per day currently)\nBalancer wstETH/ACX LPs to ~5,250 ACX per day (from ~7,000 ACX per day currently)\n(This is summarized in Table 5 above.)\nThe ACX Emissions Committee will monitor the impact of these changes on the performance of Across protocol. If there are signs that utilization in these assets are too high or more decentralized liquidity is needed in ACX then the AEC will take action to help rectify it.\nVoting:\n\n Should the Across DAO reduce ACX base emissions rates for Across ACX LPs, Across WBTC LPs, and Balancer wstETH/ACX LPs by 50%, 30%, and 25% respectively? The proposed changes are summarized in Table 5 above.\n\n 60%\n Yes\n\n 30%\n No\n\n 10%\n Abstain\n\n 10\n voters\n\n Closed Aug 2024\n\n Stop ACX Emissions on ACX LP\n\n Reduce ACX emissions for WBTC LPs\n\n Stop ACX Emissions on wstETH/ACX LP Balancer Pool\n\n 4\n\n 2\n\n read \n\n 6\n min\n\n post by Justin_J on Aug 15, 2024\n\n Justin_J\n\n Could we reallocate these emissions to other usage, I’m for moving emissions from the above but it seems counterintuitive to get rid of them completely\n\n post by Kevin_UMA on Aug 15, 2024\n\n Kevin_UMA\n\n Yeah I think reallocating is a possibility. I think it should be a separate proposal where we can look at what incentives make sense. Maybe we could consider things where we incentivize more relayers for example given there are some start up costs before becoming profitable. But I think we should all be open to more ideas.\n\n post by berry4144 on Aug 15, 2024\n\n berry4144\n\n The WBTC effective emissions doesn’t seem too high when compared to the other two “offenders”. Clearly the ACX and BPT are very high but does the WBTC need such a reduction.\n(disclosure WBTC and ACX LP)\n\n post by gmsteele on Aug 17, 2024\n\n gmsteele\n\n I voted No on this because I agree with part of the emission reductions but not all. My question is really should these all be lumped together in one proposal, or should ACX holders get the opportunity to vote on these separately? I would like to be able to vote “yes,” or “no,” on each of the three proposed emission reductions\n\n post by Kevin_UMA on Aug 17, 2024\n\n Kevin_UMA\n\n That’s a good point. I think if we are in general agreement on some action here we can split up the snapshot proposal (with osnap txn) as 3 separate proposals and people can decide on exactly which ones they want to vote for.\n\n post by Bananachain on Aug 18, 2024\n\n Bananachain\n\n Relating to ACX LPs I have a different premises and a different conclusion: ACX LP emissions are the highest because the incentive works and people prefer to stake their holding instead of selling. Unlike many other altcoins ACX price has increased during the 1.5 years in spite it not having any utility. This is in fact the real issue: lack of ACX utility. So before that is not addressed it is preferable for ACX LP to be incentivised not to sell, which will only lead to sell pressure. This all the more as emissions have already been reduced a lot and now stand at about a third from where they began initially (~35% p.a.), distributions were never auto-compounding and claiming reset the multiplyer to the minimum.\nAnother options to reduce emissions could be introducing decreasing emission rate tiers: e.g. up to 100k ACX: 9%, the next tier up to 500k receive 5% and the final tier 1% on their excess holding. Details would have to be calculated properly of course. We have some very big legacy whale holders - that may be the real reason why emissions are rather high. This would incentivise them to reduce their ACX share, lead to more decentralisation and address the imbalance amongst holders. And sell pressure would be limited/managed.\n\n post by arizonaice on Aug 21, 2024\n\n arizonaice\n\n Hey Guys,\nJust wanted to chime in here with some data to help illustrate why these pools in particular make sense to reduce emissions for.\nThe AEC has made some major progress over the last 7-8 months in keeping ACX emissions at reasonable levels given the growth of LP and the success of the protocol. These are our most highly utilised pools and do the majority of our volumes.\nimage1171×732 42.5 KB\nimage1171×732 46.1 KB\nIn contrast the three pools we are suggesting cutting rates for are markedly out of line with this reasonable emissions philosophy. This proposal should it progress to vote is simply looking to correct that.\nimage1171×732 41.5 KB\nimage1171×732 40.9 KB\nI agree there is merit in splitting the proposal into three separate votes so that ACX holders can vote in a more targeted manner.\nHope this helps.\nCheers,\nDylan\n\n post by blkboxeconomist on Aug 21, 2024\n\n blkboxeconomist\n\n berry4144\n\n I think for me the reason this proposal is important is due to the disparity is in what WBTC LP emissions vs the DAI and USDT LP emissions – Year-to-date, WBTC is responsible for about $275mm of volume while DAI/USDT are responsible for nearly $500mm of volume but we are roughly emitting as much to WBTC LPs as the sum of what we pay DAI and USDT LPs. DAI and USDT are controlled by the AEC and so their emissions have decreased in the last 8 months while WBTC has stayed flat.\nLike Kevin said, I think of this proposal as putting the WBTC emissions in line with what other emissions have done and I’d actually like another proposal that expands the powers of the AEC to managing the remaining pools LP pools that receive emissions (possibly with the exception of ACX-LPs given that, as people have commented here, there are non-bridge related reasons to maintain emissions).\n\n post by Kevin_UMA on Aug 21, 2024\n\n Kevin_UMA\n\n Bananachain\n\n I don’t like to speculate on token price, but I do not think ACX LP emissions is the reason the token price has done well. These emissions have been cut in the past and it has not impacted the token price. If anything it may have helped given the reduction of new ACX supply in the market. I think Across / ACX has done well over the last year because of all the positive developments. It has become the top bridge, it is working with and partnered with key projects (eg Uniswap and Optimism), and in general it’s the leader in the cross chain interop space.\nI think auto compounding and different emission rate tiers can be explored and proposals should be welcome.\n\n post by Bananachain on Aug 22, 2024\n\n Bananachain\n\n Taking what you say, what advantage will a further reduction of emissions then have other than reducing them? For me the case for emission reduction would be more convincing and appealing as a package including aspects you mentioned in your last sentence. The utility aspect is probably a tougher nut to crack.\n\n post by x_momo on Aug 22, 2024\n\n x_momo\n\n Kevin_UMA\n\n Hi Kevin,\nFirst of all, thank you for taking the time to write the proposal and provide feedback on some of the comments. Overall, I agree with the majority of the points raised. However, I would like to respectfully disagree with your stance on ACX LP emissions. $ACX has performed well over the last few months due to several factors, including product development, new partnerships/ listings, and the token utility with novel ACX staking mechanism (100 days unlocks additional APY% boost).\nAs Bananachain mentioned, the current ACX LP emissions create an incentive for new and existing token holders to stake their $ACX. Diluting this by 50% would weaken the already limited utility of the $ACX governance token. Ideally, we should be looking for ways to increase this utility. If that is not possible, at the very least, aim to maintain it. In the Web3 space, token price itself can have a positive marketing flywheel effect (please see @cburniske X post on 30th June, 2024 3:33 PM. The $ACX price chart is used to reinforce his bullish stance on Across).\nIn a cycle where crypto Twitter (CT) is oversaturated with noise, and Across still has some way to go before it gets the recognition it truly deserves from CT, (Please see @ayyyeandy poll post on 21/08/24 at 2.28 am. Across was ranked 3rd as preferred cross chain app).\nIn light of the above, imho, one should not rush into making any hasty decisions that could reduce $ACX utility.\nDisclaimer: The above is not financial advice and reflects my personal opinions only. You should conduct your own research and consult with a licensed financial advisor before making any financial decisions.\n\n 1 month later\n\n Closed on Sep 21, 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 Reduce ACX emissions for Across ACX LPs\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 8\n\n Nov 2023\n\n Reduce ACX emissions for WBTC LPs\n\n Active Proposals\n\n Active Proposals\n\n Aug 2025\n\n Stop ACX Emissions on ACX LP\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 4\n\n May 2025\n\n Stop ACX Emissions on wstETH/ACX LP Balancer Pool\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 2\n\n May 2025\n\n ACX Emissions Committee\n\n Proposals\n\n governance-updates\n\n Proposals\n\n Dec 2023","tokens":5371,"squid":"spider-09","role":"Bridge Spider","at":1791341860423,"hash":"a6bddfbf87b509a5bb507aa7f5eeaccf94625320"}
{"url":"https://eips.ethereum.org/EIPS/eip-868","domain":"eips.ethereum.org","title":"EIP-868: Node Discovery v4 ENR Extension","text":"🎉 Final\n\n Standards Track: Networking\n\n EIP-868: Node Discovery v4 ENR Extension\n\n Authors\n Felix Lange <fjl@ethereum.org>\n\n Created\n 2018-02-02\n\n Requires\n\n EIP-8, \n\n EIP-778\n\n Abstract\n\nThis EIP defines an extension to Node Discovery Protocol v4 to enable authoritative\nresolution of Ethereum Node Records (ENR).\n\n Motivation\n\nTo bridge current and future discovery networks and to aid the implementation of other\nrelay mechanisms for ENR such as DNS, we need a way to request the most up-to-date version\nof a node record. This EIP provides a way to request it using the existing discovery\nprotocol.\n\n Specification\n\nImplementations of Node Discovery Protocol v4 should support two new packet types, a\nrequest and reply of the node record. The existing ping and pong packets are extended with\na new field containing the sequence number of the ENR.\n\n Ping Packet (0x01)\n\npacket-data = [version, from, to, expiration, enr-seq]\n\nenr-seq is the current sequence number of the sending node’s record. All other fields\nretain their existing meaning.\n\n Pong Packet (0x02)\n\npacket-data = [to, ping-hash, expiration, enr-seq]\n\nenr-seq is the current sequence number of the sending node’s record. All other fields\nretain their existing meaning.\n\n ENRRequest Packet (0x05)\n\npacket-data = [ expiration ]\n\nWhen a packet of this type is received, the node should reply with an ENRResponse packet\ncontaining the current version of its record.\n\nTo guard against amplification attacks, the sender of ENRRequest should have replied to a\nping packet recently (just like for FindNode). The expiration field, a UNIX timestamp,\nshould be handled as for all other existing packets i.e. no reply should be sent if it\nrefers to a time in the past.\n\n ENRResponse Packet (0x06)\n\npacket-data = [ request-hash, ENR ]\n\nThis packet is the response to ENRRequest.\n\n request-hash is the hash of the entire ENRRequest packet being replied to.\n ENR is the node record.\n\nThe recipient of the packet should verify that the node record is signed by node who sent\nENRResponse.\n\n Resolving Records\n\nTo resolve the current record of a node public key, perform a recursive Kademlia lookup\nusing the FindNode, Neighbors packets. When the node is found, send ENRRequest to it and\nreturn the record from the response.\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-868: Node Discovery v4 ENR Extension,\" Ethereum Improvement Proposals, no. 868, February 2018. Available: https://eips.ethereum.org/EIPS/eip-868.","tokens":640,"squid":"spider-05","role":"Spec Spider","at":1791341868608,"hash":"b2d2a3b78ab6e645d4d281cb3ff4a408b9e68283"}
{"url":"https://squidfunk.github.io/mkdocs-material/plugins/blog/","domain":"squidfunk.github.io","title":"Built-in blog plugin - Material for MkDocs","text":"Built-in blog plugin¶ The blog plugin makes it very easy to build a blog, either as a sidecar to your documentation or as the main thing. Focus on your content while the plugin does all the heavy lifting, generating a view of all latest posts, archive and category pages, configurable pagination and much more. Objective¶ How it works¶ The plugin scans the configured posts directory for .md files from which paginated views1 are automatically generated. If not configured otherwise, the plugin expects that your project has the following directory layout, and will create any missing directories or files for you: .\n├─ docs/\n│ └─ blog/\n│ ├─ posts/\n│ └─ index.md\n└─ mkdocs.yml\n The index.md file in the blog directory is the entry point to your blog – a paginated view listing all posts in reverse chronological order. Besides that, the plugin supports automatically creating archive and category pages that list a subset of posts for a time interval or category. Post URLs are completely configurable, no matter if you want your URLs to include the post's date or not. Rendered dates always display in the locale of the site language of your project. Like in other static blog frameworks, posts can be annotated with a variety of metadata, allowing for easy integration with other built-in plugins, e.g., the social and tags plugin. Posts can be organized in nested folders with a directory layout that suits your specific needs, and can make use of all components and syntax that Material for MkDocs offers, including admonitions, annotations, code blocks, content tabs, diagrams, icons, math, and more. When to use it¶ If you want to add a blog to your project, or migrate from another blog framework to Material for MkDocs because of its excellent technical writing capabilities, this plugin is a great choice, as it integrates perfectly with many other built-in plugins:   Built-in meta plugin The meta plugin makes it easy to apply metadata to a subset of posts, including authors, tags, categories, draft status, as well as social card layouts. Simpler organization, categorization and management of post metadata   Built-in social plugin The social plugin automatically generates beautiful and customizable social cards for each post and page, showing as previews on social media. Links to your blog render beautiful social cards when shared on social media   Built-in optimize plugin The optimize plugin automatically identifies and optimizes all media files that you reference in your project by using compression and conversion techniques. Your blog loads faster as smaller images are served to your users   Built-in tags plugin The tags plugin allows to categorize posts alongside with pages in your project, to improve their discoverability and connect posts to your documentation. Your documentation's tag system integrates with your blog Configuration¶ 9.2.0 blog – built-in As with all built-in plugins, getting started with the blog plugin is straightforward. Just add the following lines to mkdocs.yml, and you can start writing your first post: plugins:\n - blog\n The blog plugin is built into Material for MkDocs and doesn't need to be installed. Navigation¶ If you do not have site navigation configured in your mkdocs.yml then there is nothing more to do. The blog archive and category pages will automatically appear underneath the automatically generated navigation. If you do have a navigation structure defined then you will need to specify where the blog should appear in this. Create a navigation section with an index page for the blog: theme:\n name: material\n features:\n - navigation.indexes\nnav:\n - ...\n - Blog:\n - blog/index.md\n The archive and category pages will appear within that section as subsections beneath pages in the blog section. In this case, they would appear after index.md. The path to the index.md file must match blog_dir. This means that you can name the blog navigation entry anything you like: 'Blog' or 'News' or perhaps 'Tips'. General¶ The following settings are available: enabled¶ 9.2.0 true Use this setting to enable or disable the plugin when building your project. It's normally not necessary to specify this setting, but if you want to disable the plugin, use: plugins:\n - blog:\n enabled: false\n blog_dir¶ 9.2.0 blog Use this setting to change the path where your blog is located in the docs directory. The path is included in the generated URLs as a prefix for all posts and views. You can change it with: Documentation + BlogBlog only plugins:\n - blog:\n blog_dir: blog\n plugins:\n - blog:\n blog_dir: .\n The provided path is resolved from the docs directory. blog_toc¶ 9.2.0 false Use this setting to leverage the table of contents to display post titles in views. This might be useful, if your post excerpts are rather long. If you want to enable it, use: plugins:\n - blog:\n blog_toc: true\n Posts¶ The following settings are available for posts: post_dir¶ 9.2.0 {blog}/posts Use this setting to change the folder where your posts are located. It's normally not necessary to change this setting, but if you want to rename the folder or change its file system location, use: plugins:\n - blog:\n post_dir: \"{blog}/articles\"\n Note that the posts directory is solely used for post organization – it is not included in post URLs, since they are automatically and comfortably generated by this plugin. The following placeholders are available: blog – blog directory The provided path is resolved from the docs directory. post_date_format¶ 9.2.0 long Use this setting to change the date format of posts. This plugin uses babel to render dates in the configured site language. You can use babel's pattern syntax or the following shortcodes: Monday, January 31, 2024January 31, 2024Jan 31, 20241/31/24 plugins:\n - blog:\n post_date_format: full\n plugins:\n - blog:\n post_date_format: long\n plugins:\n - blog:\n post_date_format: medium\n plugins:\n - blog:\n post_date_format: short\n Note that depending on the site language, results might look different for other languages. post_url_date_format¶ 9.2.0 yyyy/MM/dd Use this setting to change the date format used in post URLs. The format string must adhere to babel's pattern syntax and should not contain whitespace. Some popular choices: blog/2024/01/31// blog/2024/01// blog/2024// plugins:\n - blog:\n post_url_date_format: yyyy/MM/dd\n plugins:\n - blog:\n post_url_date_format: yyyy/MM\n plugins:\n - blog:\n post_url_date_format: yyyy\n If you want to remove the date from post URLs, e.g., when your blog features mostly evergreen content, you can remove the date placeholder from the post_url_format format string. post_url_format¶ 9.2.0 {date}/{slug} Use this setting to change the format string that is used when generating post URLs. You can freely combine placeholders, and join them with slashes or other characters: blog/2024// blog// plugins:\n - blog:\n post_url_format: \"{date}/{slug}\"\n plugins:\n - blog:\n post_url_format: \"{slug}\"\n The following placeholders are available: categories – Post categories, slugified with categories_slugify date – Post date, formatted with post_url_date_format slug – Post title, slugified with post_slugify, or explicitly set via slug metadata property file – Post filename without .md file extension If you remove the date placeholder, make sure that post URLs don't collide with URLs of other pages hosted under the blog directory, as this leads to undefined behavior. post_url_max_categories¶ 9.2.0 1 Use this setting to set an upper bound for the number of categories included in post URLs if the categories placeholder is part of post_url_format and the post defines categories: plugins:\n - blog:\n post_url_format: \"{categories}/{slug}\"\n post_url_max_categories: 2\n If more than one category is given, they are joined with / after slugifying. post_slugify¶ 9.2.0 pymdownx.slugs.slugify Use this setting to change the function for generating URL-compatible slugs from post titles. By default, the slugify function from Python Markdown Extensions is used as follows: plugins:\n - blog:\n post_slugify: !!python/object/apply:pymdownx.slugs.slugify\n kwds:\n case: lower\n The default configuration is Unicode-aware and should produce good slugs for all languages. Of course, you can also provide a custom slugification function for more granular control. post_slugify_separator¶ 9.2.0 - Use this setting to change the separator that is passed to the slugification function set as part of post_slugify. While the default is a hyphen, it can be set to any string, e.g., _: plugins:\n - blog:\n post_slugify_separator: _\n post_excerpt¶ 9.2.0 optional By default, the plugin makes post excerpts optional. When a post doesn't define an excerpt, views include the entire post. This setting can be used to make post excerpts required: OptionalRequired plugins:\n - blog:\n post_excerpt: optional\n plugins:\n - blog:\n post_excerpt: required\n When post excerpts are required, posts without excerpt separators raise an error. Thus, this setting is useful when you want to make sure that all posts have excerpts defined. post_excerpt_max_authors¶ 9.2.0 1 Use this setting to set an upper bound for the number of authors rendered in post excerpts. While each post may be written by multiple authors, this setting allows to limit the display to just a few or even a single author, or disable authors in post excerpts: Render up to 2 authorsDisable authors plugins:\n - blog:\n post_excerpt_max_authors: 2\n plugins:\n - blog:\n post_excerpt_max_authors: 0\n This only applies to post excerpts in views. Posts always render all authors. post_excerpt_max_categories¶ 9.2.0 5 Use this setting to set an upper bound for the number of categories rendered in post excerpts. While each post may be assigned to multiple categories, this setting allows to limit the display to just a few or even a single category, or disable categories in post excerpts: Render up to 2 categoriesDisable categories plugins:\n - blog:\n post_excerpt_max_categories: 2\n plugins:\n - blog:\n post_excerpt_max_categories: 0\n This only applies to post excerpts in views. Posts always render all categories. post_excerpt_separator¶ 9.2.0 <!-- more --> Use this setting to set the separator the plugin will look for in a post's content when generating post excerpts. All content before the separator is considered to be part of the excerpt: plugins:\n - blog:\n post_excerpt_separator: <!-- more -->\n It is common practice to use an HTML comment as a separator. post_readtime¶ 9.2.0 true Use this setting to control whether the plugin should automatically compute the reading time of a post, which is then rendered in post excerpts, as well as in posts themselves: plugins:\n - blog:\n post_readtime: false\n Chinese, Japanese and Korean characters Reading time computation currently does not take segmentation of Chinese, Japanese and Korean characters into account. This means that the reading time for posts in these languages may be inaccurate. We're planning on adding support in the future. In the meantime, please use the readtime front matter property to set the reading time. post_readtime_words_per_minute¶ 9.2.0 265 Use this setting to change the number of words that a reader is expected to read per minute when computing the reading time of a post. If you want to fine-tune it, use: plugins:\n - blog:\n post_readtime_words_per_minute: 300\n A reading time of 265 words per minute is considered to be the average reading time of an adult. Archive¶ The following settings are available for archive pages: archive¶ 9.2.0 true Use this setting to enable or disable archive pages. An archive page shows all posts for a specific interval (e.g. year, month, etc.) in reverse order. If you want to disable archive pages, use: plugins:\n - blog:\n archive: false\n archive_name¶ 9.2.0 Use this setting to change the title of the archive section the plugin adds to the navigation. If this setting is omitted, it's sourced from the translations. If you want to change it, use: plugins:\n - blog:\n archive_name: Archive\n archive_date_format¶ 9.2.0 yyyy Use this setting to change the date format used for archive page titles. The format string must adhere to babel's pattern syntax. Some popular choices: 2024January 2024 plugins:\n - blog:\n archive_date_format: yyyy\n plugins:\n - blog:\n archive_date_format: MMMM yyyy\n Note that depending on the site language, results might look different for other languages. archive_url_date_format¶ 9.2.0 yyyy Use this setting to change the date format used for archive page URLs. The format string must adhere to babel's pattern syntax and should not contain whitespace. Some popular choices: blog/archive/2024/ blog/archive/2024/01/ plugins:\n - blog:\n archive_url_date_format: yyyy\n plugins:\n - blog:\n archive_url_date_format: yyyy/MM\n archive_url_format¶ 9.2.0 archive/{date} Use this setting to change the format string that is used when generating archive page URLs. You can freely combine placeholders, and join them with slashes or other characters: blog/archive/2024/ blog/2024/ plugins:\n - blog:\n archive_url_format: \"archive/{date}\"\n plugins:\n - blog:\n archive_url_format: \"{date}\"\n The following placeholders are available: date – Archive date, formatted with archive_url_date_format archive_pagination¶ 9.7.0 true Use this setting to enable or disable pagination for archive pages. The value of this setting is inherited from pagination, unless it's explicitly set. To disable pagination, use: plugins:\n - blog:\n archive_pagination: false\n archive_pagination_per_page¶ 9.7.0 10 Use this setting to change the number of posts rendered per archive page. The value of this setting is inherited from pagination_per_page, unless it's explicitly set. To change it, use: plugins:\n - blog:\n archive_pagination_per_page: 5\n archive_toc¶ 9.2.0 false Use this setting to leverage the table of contents to display post titles on all archive pages. The value of this setting is inherited from blog_toc, unless it's explicitly set. To change it, use plugins:\n - blog:\n archive_toc: true\n Categories¶ The following settings are available for category pages: categories¶ 9.2.0 true Use this setting to enable or disable category pages. A category page shows all posts for a specific category in reverse chronological order. If you want to disable category pages, use: plugins:\n - blog:\n categories: false\n categories_name¶ 9.2.0 Use this setting to change the title of the category section the plugin adds to the navigation. If this setting is omitted, it's sourced from the translations. If you want to change it, use: plugins:\n - blog:\n categories_name: Categories\n categories_url_format¶ 9.2.0 category/{slug} Use this setting to change the format string that is used when generating category page URLs. You can freely combine placeholders, and join them with slashes or other characters: blog/category// blog// plugins:\n - blog:\n categories_url_format: \"category/{slug}\"\n plugins:\n - blog:\n categories_url_format: \"{slug}\"\n The following placeholders are available: slug – Category, slugified with categories_slugify categories_slugify¶ 9.2.0 pymdownx.slugs.slugify Use this setting to change the function for generating URL-compatible slugs from categories. By default, the slugify function from Python Markdown Extensions is used as follows: plugins:\n - blog:\n categories_slugify: !!python/object/apply:pymdownx.slugs.slugify\n kwds:\n case: lower\n The default configuration is Unicode-aware and should produce good slugs for all languages. Of course, you can also provide a custom slugification function for more granular control. categories_slugify_separator¶ 9.2.0 - Use this setting to change the separator that is passed to the slugification function set as part of categories_slugify. While the default is a hyphen, it can be set to any string, e.g., _: plugins:\n - blog:\n categories_slugify_separator: _\n categories_sort_by¶ 9.7.0 material.plugins.blog.view_name Use this setting to specify a custom function for sorting categories. For example, if you want to sort categories by the number of posts they contain, use the following configuration: plugins:\n - blog:\n categories_sort_by: !!python/name:material.plugins.blog.view_post_count\n Don't forget to enable categories_sort_reverse. You can define your own comparison function, which must return something that can be compared while sorting, i.e., a string or number. categories_sort_reverse¶ 9.7.0 false Use this setting to reverse the order in which categories are sorted. By default, categories are sorted in ascending order, but you can reverse ordering as follows: plugins:\n - blog:\n categories_sort_reverse: true\n categories_allowed¶ 9.2.0 The plugin allows to check categories against a predefined list, in order to catch typos or make sure that categories are not arbitrarily added. Specify the categories you want to allow with: plugins:\n - blog:\n categories_allowed:\n - Search\n - Performance\n The plugin stops the build if a post references a category that is not part of this list. Posts can be assigned to categories by using the categories metadata property. categories_pagination¶ 9.7.0 true Use this setting to enable or disable pagination for category pages. The value of this setting is inherited from pagination, unless it's explicitly set. To disable pagination, use: plugins:\n - blog:\n categories_pagination: false\n categories_pagination_per_page¶ 9.7.0 10 Use this setting to change the number of posts rendered per category page. The value of this setting is inherited from pagination_per_page, unless it's explicitly set. To change it, use: plugins:\n - blog:\n categories_pagination_per_page: 5\n categories_toc¶ 9.2.0 false Use this setting to leverage the table of contents to display post titles on all category pages. The value of this setting is inherited from blog_toc, unless it's explicitly set. To change it, use: plugins:\n - blog:\n categories_toc: true\n Authors¶ The following settings are available for authors: authors¶ 9.2.0 true Use this setting to enable or disable post authors. If this setting is enabled, the plugin will look for a file named .authors.yml and render authors in posts and views. Disable this behavior with: plugins:\n - blog:\n authors: false\n authors_file¶ 9.2.0 {blog}/.authors.yml Use this setting to change the path of the file where the author information for your posts resides. It's normally not necessary to change this setting, but if you need to, use: plugins:\n - blog:\n authors_file: \"{blog}/.authors.yml\"\n The following placeholders are available: blog – blog directory The provided path is resolved from the docs directory. Format of author information The .authors.yml file must adhere to the following format: .authors.ymlauthors:\n <author>:\n name: string # Author name\n description: string # Author description\n avatar: url # Author avatar\n slug: url # Author profile slug\n url: url # Author website URL\n Note that <author> must be set to an identifier for associating authors with posts, e.g., a GitHub username like squidfunk. This identifier can then be used in the authors metadata property of a post. Multiple authors are supported. As an example, see the .authors.yml file we're using for our blog. authors_profiles¶ 9.7.0 false Use this setting to enable or disable automatically generated author profiles. An author profile shows all posts by an author in reverse chronological order. You can enable author profiles with: plugins:\n - blog:\n authors_profiles: true\n authors_profiles_name¶ 9.7.0 Use this setting to change the title of the authors section the plugin adds to the navigation. If this setting is omitted, it's sourced from the translations. If you want to change it, use: plugins:\n - blog:\n authors_profiles_name: Authors\n authors_profiles_url_format¶ 9.7.0 author/{slug} Use this setting to change the format string that is used when generating author profile URLs. You can freely combine placeholders, and join them with slashes or other characters: blog/author// blog// plugins:\n - blog:\n authors_profiles_url_format: \"author/{slug}\"\n plugins:\n - blog:\n authors_profiles_url_format: \"{slug}\"\n The following placeholders are available: slug – Author slug or identifier from authors_file name – Author name from authors_file authors_profiles_pagination¶ 9.7.0 true Use this setting to enable or disable pagination for author profiles. The value of this setting is inherited from pagination, unless it's explicitly set. To disable pagination, use: plugins:\n - blog:\n authors_profiles_pagination: false\n authors_profiles_pagination_per_page¶ 9.7.0 10 Use this setting to change the number of posts rendered per archive page. The value of this setting is inherited from pagination_per_page, unless it's explicitly set. To change it, use: plugins:\n - blog:\n authors_profiles_pagination_per_page: 5\n authors_profiles_toc¶ 9.7.0 false Use this setting to leverage the table of contents to display post titles on all author profiles. The value of this setting is inherited from blog_toc, unless it's explicitly set. To change it, use: plugins:\n - blog:\n authors_profiles_toc: true\n Pagination¶ The following settings are available for pagination: pagination¶ 9.2.0 true Use this setting to enable or disable pagination in views – generated pages that show posts or subsets of posts in reverse chronological order. If you want to disable pagination, use: plugins:\n - blog:\n pagination: false\n pagination_per_page¶ 9.2.0 10 Use this setting to change the number of posts rendered per page. If you have rather long post excerpts, it can be a good idea to reduce the number of posts per page: plugins:\n - blog:\n pagination_per_page: 5\n pagination_url_format¶ 9.2.0 page/{page} Use this setting to change the format string that is used when generating paginated view URLs. You can freely combine placeholders, and join them with slashes or other characters: blog/page/n/ blog/n/ plugins:\n - blog:\n pagination_url_format: \"page/{page}\"\n plugins:\n - blog:\n pagination_url_format: \"{page}\"\n The following placeholders are available: page – Page number pagination_format¶ 9.2.0 ~2~ The plugin uses the paginate module to generate the pagination markup using a special syntax. Use this setting to customize how pagination is constructed. Some popular choices: 1 2 3 .. n1 2 3 .. n 1 plugins:\n - blog:\n pagination_format: \"~2~\"\n plugins:\n - blog:\n pagination_format: \"$link_first $link_previous ~2~ $link_next $link_last\"\n plugins:\n - blog:\n pagination_format: \"$link_previous $page $link_next\"\n The following placeholders are supported by paginate: $first_page – Number of first reachable page $last_page – Number of last reachable page $page – Number of currently selected page $page_count – Number of reachable pages $items_per_page – Maximal number of items per page $first_item – Index of first item on the current page $last_item – Index of last item on the current page $item_count – Total number of items $link_first – Link to first page (unless on first page) $link_last – Link to last page (unless on last page) $link_previous – Link to previous page (unless on first page) $link_next – Link to next page (unless on last page) pagination_if_single_page¶ 9.2.0 false Use this setting to control whether pagination should be automatically disabled when the view only consists of a single page. If you want to always render pagination, use: plugins:\n - blog:\n pagination_if_single_page: true\n pagination_keep_content¶ 9.2.0 false Use this setting to enable or disable persistence of content, i.e., if paginated views should also display the content of their containing view. If you want to enable this behavior, use: plugins:\n - blog:\n pagination_keep_content: true\n Drafts¶ The following settings are available for drafts: draft¶ 9.2.0 false Rendering draft posts can be useful in deploy previews. Use this setting to specify whether the plugin should include posts marked as drafts when building your project: Render draftsDon't render drafts plugins:\n - blog:\n draft: true\n plugins:\n - blog:\n draft: false\n draft_on_serve¶ 9.2.0 true Use this setting to control whether the plugin should include posts marked as drafts when previewing your site. If you don't wish to include draft posts when previewing, use: plugins:\n - blog:\n draft_on_serve: false\n draft_if_future_date¶ 9.2.0 false The plugin can automatically mark posts with future dates as drafts. When the date is past today, the post is automatically included when building your project, unless explicitly marked as draft: plugins:\n - blog:\n draft_if_future_date: true\n Usage¶ Metadata¶ Posts can define a handful of metadata properties that specify how the plugin renders them, in which views they are integrated, and how they are linked to each other. The metadata of each post is validated against a schema to allow for a quicker discovery of syntax errors. The following properties are available: authors¶ 9.2.0 Use this property to associate a post with authors by providing a list of identifiers as defined in the authors_file. If an author can't be resolved, the plugin will terminate with an error: ---\nauthors:\n - squidfunk \n---\n\n# Post title\n...\n categories¶ 9.2.0 Use this property to associate a post with one or more categories, making the post a part of the generated category page. Categories are defined as a list of strings (whitespaces are allowed): ---\ncategories:\n - Search\n - Performance\n---\n\n# Post title\n...\n If you want to prevent accidental typos assigning categories to posts, you can set a predefined list of allowed categories in mkdocs.yml by using the categories_allowed setting. date¶ 9.2.0 Use this property to specify a post's date. Note that this property is required, which means the build fails when it's not set. Additional dates can be set by using a slightly different syntax: DateUpdate dateCustom date ---\ndate: 2024-01-31\n---\n\n# Post title\n...\n ---\ndate:\n created: 2024-01-31 \n updated: 2024-02-01\n---\n\n# Post title\n...\n Each post must have a creation date set. ---\ndate:\n created: 2024-01-31\n my_custom_date: 2024-02-01 \n---\n\n# Post title\n...\n The blog plugin validates all dates and allows to format them with babel's pattern syntax in templates. When using theme extension, authors can add custom dates to templates. This was first requested in #5733. The following date formats are supported: 2024-01-31 2024-01-31T12:00:00 draft¶ 9.2.0 Use this property to mark a post as draft. The plugin allows to include or exclude posts marked as drafts when building your project using the draft setting. Mark a post as draft with: ---\ndraft: true\n---\n\n# Post title\n...\n pin¶ 9.7.0 false Use this property to pin a post to the top of a view. In case multiple posts are pinned, the pinned posts are sorted by descending order and appear before all other posts. Pin a post with: ---\npin: true\n---\n\n# Post title\n...\n links¶ 9.7.0 Use this property to define a list of links that are rendered in the sidebar of a post. The property follows the same syntax as nav in mkdocs.yml, supporting sections and even anchors: LinksLinks with sectionsLinks with anchors ---\nlinks:\n - setup/setting-up-site-search.md\n - insiders/index.md\n---\n\n# Post title\n...\n ---\nlinks:\n - setup/setting-up-site-search.md\n - Insiders:\n - insiders/index.md\n - insiders/getting-started.md\n---\n\n# Post title\n...\n ---\nlinks:\n - plugins/search.md \n - Insiders:\n - insiders/how-to-sponsor.md\n - insiders/getting-started.md#requirements\n---\n\n# Post title\n...\n If a link defines an anchor, the plugin resolves the anchor from the linked page and sets the anchor title as a subtitle. All relative links are resolved from the docs directory. readtime¶ 9.2.0 Use this property to explicitly set the reading time of a post in minutes. When post_readtime is enabled, the plugin computes the reading time of a post, which can be overridden with: ---\nreadtime: 15\n---\n\n# Post title\n...\n slug¶ 9.2.0 Use this property to explicitly set the slug of a post. By default, the slug of a post is automatically computed by the post_slugify function from the post's title, which can be overridden with: ---\nslug: help-im-trapped-in-a-universe-factory\n---\n\n# Post title\n...\n Slugs are passed to post_url_format. Missing something? When setting up your blog or migrating from another blog framework, you might discover that you're missing specific functionality – we're happy to consider adding it to the plugin! You can open a discussion to ask a question, or create a change request on our issue tracker, so we can find out if it might be a good fit for the plugin. Views are pages that are automatically generated, i.e., the entry point to your blog listing all latest posts, as well as archive and category pages that list all posts associated with them through metadata in chronological order. ↩","tokens":7170,"squid":"spider-06","role":"Security Spider","at":1791341870395,"hash":"6799a0bc37c648609b6f24256ffa7489d1665be3"}
{"url":"https://forum.across.to/t/acx-emissions-committee/1787","domain":"forum.across.to","title":"ACX Emissions Committee - Proposals - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n ACX Emissions Committee \n\n Proposals\n\n governance-updates\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Dec 2023\n\n 1 / 2\n\n Dec 2023\n\n Dec 2023\n\n post by Kevin_UMA on Dec 16, 2023\n\n Kevin_UMA\n\n Title: ACX Emissions Committee\nAuthors: Kevin Chan, David Korpi, Ryan Carman, Dylan O’Reilly, Chase Coleman\nStatus: Proposal\nSubmission Date: December 16th, 2023\nSummary:\nThe Across DAO needs an efficient and transparent way to manage ACX emissions. The DAO should form the ACX Emissions Committee (AEC). The AEC will have permission to change the Across Reward Locking parameters which controls ACX emissions on the Across bridge liquidity pools. The AEC will follow a transparent and restrictive framework to make predictable and measured changes to emissions for an asset depending on the pool utilization rate of that asset and the yield earned on comparable bridges. The members of the AEC will be chosen by ACX token holders and changes to the parameters of this framework will also need DAO approval.\nMotivation:\nThe Across DAO needs an efficient and transparent way to manage ACX emissions so that ACX is optimally used for incentives. Currently, the amount of ACX rewarded to bridge liquidity providers (LPs) appears high in comparison to competing cross chain bridges. For example, Across is rewarding ETH LPs a base APY of 12.7% (21.5% to LPs with a 2x multiplier) in comparison to competing bridges such as Stargate, Hop and Synapse which are paying 4% to 7%. In addition, the utilization rate on the ETH pool on Across is only 22.7% suggesting there is not an urgent demand for assets. A proposal can be submitted to decrease emissions; however, a more permanent, clear and robust solution should be created to adjust ACX emissions both down and up when needed.\nThe Across DAO should form the ACX Emissions Committee (AEC). The AEC will own the Accelerating Distributor contract, which controls the parameters of the Across Reward Locking program, through a 3 of 5 multisig. Members of the AEC and signers of this multisig will initially be Risk Labs foundation team members. However, the long term goal is to include Across community members such as the Across Treasury Committee which is potentially being formed now. Changes in AEC members and parameters on how it operates can be voted on by the Across DAO.\nAEC Short Term Objective\nThe AEC needs a clear and transparent framework to adjust ACX emissions. The framework also needs to be reasonably restrictive so that only predictable and measured actions are taken to modify ACX emissions. Decisions will be driven by two observable factors.\n\nAcross pool utilization - LPs should be rewarded for how much demand there is for an asset for bridge transfers. The AEC will track the 7-day average pool utilization of each asset.\nCompeting yield - LPs should be rewarded a fair yield in comparison to yields paid by competing bridges. The AEC can track a Yield Index for each asset that is computed as a 7-day average of the TVL weighted yield of pools on Stargate, Hop, and Synapse.\n\nUsing these two factors as inputs, the AEC can build a simple framework (below) to determine whether action needs to be taken on ETH, USDC, USDT, and DAI. If an action is required, the AEC can only increase or decrease emissions of an asset by 25% and then wait 14 days to re-evaluate and take further action if needed. This prevents the AEC from over reacting and allows the LPs and the general market to adjust to its actions.\n\nAcross Pool Utilization\nDecrease emissions by 25% if total Base LP APY vs Yield Index is\nIncrease emissions by 25% if total Base LP APY vs Yield Index is\n\n0 - 40%\n+25%\n-75%\n\n40 - 70%\n+50%\n-50%\n\n70 - 100%\n+100%\n-25%\n\nHere is an example of how the AEC would act today when evaluating the ETH pool:\n\nETH Pool Utilization = 22.7%\nETH Base LP APY = 12.65%\nETH Yield Index = 5.38%\nAcross APY is 135% higher than the Yield Index which is higher than the +25% threshold for action\nAEC decreases emissions by 25% and resulting APY is 10.71% (note: AEC only decreases Rewards APY and cannot control the Pool APY)\nAEC waits 14 days and re-evaluates\n\nThe AEC should almost never deviate from this framework unless there is an extraordinary event. The AEC can make changes to the variables in this framework with the approval of a DAO proposal. ACX and WBTC sit outside of this framework given there are no comparisons as competing bridges do not transfer these assets. A separate governance proposal will be needed to adjust emissions for these assets.\nAEC Long Term Objective\nThe AEC will set and manage a long term plan for ACX emissions to ensure the Across DAO does not deplete its treasury too quickly and has assets for future growth and other initiatives. As an illustration, the Across DAO currently has 366MM ACX in its treasury and is spending about 194.5K ACX in base emissions per day and possibly as much as 396K ACX per day if LPs all have a max multiplier. At the high end of this emissions rate the Across DAO would deplete its reserves in about 2.5 years.\nWhen thinking about emissions, the Across DAO should incentivize more heavily in the early years to help bootstrap growth by attracting LP capital. As the protocol picks up adoption and finds more efficiencies, resulting in more volumes and revenue for LPs, less ACX incentives are needed. Over the long term, the ideal scenario is to have bridge fees be the sole source of revenue that attract LPs to provide capital. As a conservative estimate, Across should be able to reach this goal in less than 5 years. With this target in mind, the AEC should decrease emissions each quarter by an amount that will ensure ACX reserved for incentives will not be depleted until the end of 2028 (5 years from now). Here are the initial numbers the AEC will consider:\n\nTotal ACX in the Across DAO is 366,432,519\nOf the 1B ACX minted, the DAO should use no more than 400MM for incentives (40%)\nGiven the DAO has already rewarded 126MM to LPs, there would only be 274MM ACX remaining for possible LP incentives.\nAt a current daily emissions rate of 295.25K (average between base and max multiplier) and a reduction of roughly 25% (assuming the AEC takes action after this proposal), the DAO would need to decrease emissions by 4.5% each quarter to ensure this ACX allocation for incentives is not depleted before the end of 2028\nA spreadsheet is built to illustrate these numbers and assumptions can be adjusted as needed.\nNote: The Risk Labs data team is currently working on calculating a more precise daily emissions rate that will be available on a Dune dashboard. Long term action will not be taken by the AEC until this is finalized.\n\nTo summarize, unless voted for a change by ACX token holders, the AEC will modify total base emissions quarterly to ensure no more than a total of 400MM ACX is ever used for LP incentives and that this allocation will not be depleted before December 31, 2028.\nSpecification & Implementation:\nThe following steps will be taken to implement the ACX Emissions Committee (AEC):\n\nThe Across DAO treasury is the current owner of the Accelerating Distributor contract. ACX token holders will vote on Snapshot to transfer ownership to 0x2e510146c6fCC90Ffc8087925AcC06C9fd0F5384, which is a 3 of 5 multisig that consists of members of the AEC committee. If successful, this transaction will be executed via the oSnap module which is already implemented. The initial members and signers of the AEC are the authors of this proposal who are Risk Labs team members with financial markets, web3 product management and data analysis expertise.\nThe following are their wallet addresses:\n0x1d933Fd71FF07E69f066d50B39a7C34EB3b69F05\n0xAf9C500a6FF28D541D1BA9E912db8485c7f6AF13\n0x868CF19464e17F76D6419ACC802B122c22D2FD34\n0x75752D7f6a6b9DB94258705DAe1814743077B9D8\n0xDFB0A775A44d309d939DCaEA081552aa4FE4025f\n\nThe AEC will monitor the Across pool utilization and Index Yield for ETH, USDC, USDT, and DAI. These numbers can be viewed directly from the Across front-end and competing bridge pages or through a public, custom Dune dashboard created by the Risk Labs data team.\n\nThe framework outlined in this proposal to achieve the short term and long term objective of the AEC will be included in the Docs site in a new section under “Token” called ACX Emissions Committee. The AEC will follow this framework, and the targets and variables can only be changed through a governance proposal.\n\nThe AEC will immediately announce to the Across community via Discord any action taken and explain the justification. The AEC will also provide a summary report each quarter. The Across community manager will assist in amplifying any announcements and will coordinate community calls.\n\nThe AEC members will initially be Risk Labs foundation team members. Risk Labs plans to include community members; however, contract work needs to be done so that permissioning of the Accelerating Distributor contract can be split so that the AEC can only control parameters and the Across DAO controls the withdrawal of rewards (if necessary).\n\nThe AEC is meant to be a permanent installation for the Across DAO. A vote to renew membership is not necessary unless a change to membership is made.\n\nVoting:\n\n Should the Across DAO form the ACX Emissions Committee (AEC)? The AEC would become the owner of the Accelerating Distributor contract and follow the framework outlined in this proposal to achieve its short term and long term objectives.\n\n 100%\n Yes\n\n 0%\n Abstain\n\n 0%\n No\n\n 6\n voters\n\n Closed Dec 2023\n\n ACX Emissions Committee Framework Update\n\n read \n\n 4\n min\n\n 1 month later\n\n Closed on Jan 15, 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 Reduce ACX emissions for Across ACX LPs\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 8\n\n Nov 2023\n\n ACX Emissions Committee Framework Update\n\n Proposals\n\n governance-updates\n\n Proposals\n\n 1\n\n Jun 2024\n\n Reduce ACX emissions for ACX LPs, WBTC LPs and wstETH/ACX LPs\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 11\n\n Aug 2024\n\n Stop ACX Emissions on ACX LP\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 4\n\n May 2025\n\n Reduce or Reallocate Across ACX LP emissions\n\n Ideas & Feedback\n\n liquidity\n\n Ideas & Feedback\n\n 2\n\n Sep 2023","tokens":4079,"squid":"spider-09","role":"Bridge Spider","at":1791341879559,"hash":"3adcf66494ab225b4d9d4076d39b796144142d56"}
{"url":"https://eips.ethereum.org/EIPS/eip-1013","domain":"eips.ethereum.org","title":"EIP-1013: Hardfork Meta: Constantinople","text":"🎉 Final\n\n Meta\n\n EIP-1013: Hardfork Meta: Constantinople\n\n Authors\n Nick Savers (@nicksavers)\n\n Created\n 2018-04-20\n\n Requires\n\n EIP-145, \n\n EIP-609, \n\n EIP-1014, \n\n EIP-1052, \n\n EIP-1234, \n\n EIP-1283\n\n Abstract\n\nThis meta-EIP specifies the changes included in the Ethereum hardfork named Constantinople.\n\n Specification\n\n Codename: Constantinople\n Aliases: Metropolis/Constantinople, Metropolis part 2\n Activation:\n\n Block >= 7_280_000 on the Ethereum Mainnet\n Block >= 4,230,000 on the Ropsten testnet\n Block >= 9_200_000 on the Kovan testnet\n Block >= 3_660_663 on the Rinkeby testnet\n\n Included EIPs:\n\n EIP-145: Bitwise shifting instructions in EVM\n EIP-1014: Skinny CREATE2\n EIP-1052: EXTCODEHASH Opcode\n EIP-1234: Delay difficulty bomb, adjust block reward\n EIP-1283: Net gas metering for SSTORE without dirty maps\n\n References\n\n The list above includes the EIPs discussed as candidates for Constantinople at the All Core Dev Constantinople Session #1. See also Constantinople Progress Tracker.\n https://blog.ethereum.org/2019/02/22/ethereum-constantinople-st-petersburg-upgrade-announcement/\n\n Copyright\n\nCopyright and related rights waived via CC0.\n\n Citation\n Please cite this document as:\n\n Nick Savers (@nicksavers), \"EIP-1013: Hardfork Meta: Constantinople,\" Ethereum Improvement Proposals, no. 1013, April 2018. Available: https://eips.ethereum.org/EIPS/eip-1013.","tokens":344,"squid":"spider-05","role":"Spec Spider","at":1791341881589,"hash":"526f2544690b89476669c29feb9c0449a27adf53"}
{"url":"https://eips.ethereum.org/EIPS/eip-1283","domain":"eips.ethereum.org","title":"EIP-1283: Net gas metering for SSTORE without dirty maps","text":"🎉 Final\n\n Standards Track: Core\n\n EIP-1283: Net gas metering for SSTORE without dirty maps\n\n Authors\n Wei Tang (@sorpaas)\n\n Created\n 2018-08-01\n\n Abstract\n\nThis EIP proposes net gas metering changes for SSTORE opcode, enabling\nnew usages for contract storage, and reducing excessive gas costs\nwhere it doesn’t match how most implementations work.\n\nThis acts as an alternative for EIP-1087, where it tries to be\nfriendlier to implementations that use different optimization\nstrategies for storage change caches.\n\n Motivation\n\nThis EIP proposes a way for gas metering on SSTORE (as an alternative\nfor EIP-1087 and EIP-1153), using information that is more universally\navailable to most implementations, and requires as little change in\nimplementation structures as possible.\n\n Storage slot’s original value.\n Storage slot’s current value.\n Refund counter.\n\nUsages that benefits from this EIP’s gas reduction scheme includes:\n\n Subsequent storage write operations within the same call frame. This\nincludes reentry locks, same-contract multi-send, etc.\n Exchange storage information between sub call frame and parent call\nframe, where this information does not need to be persistent outside\nof a transaction. This includes sub-frame error codes and message\npassing, etc.\n\n Specification\n\nDefinitions of terms are as below:\n\n Storage slot’s original value: This is the value of the storage if\na reversion happens on the current transaction.\n Storage slot’s current value: This is the value of the storage\nbefore SSTORE operation happens.\n Storage slot’s new value: This is the value of the storage after\nSSTORE operation happens.\n\nReplace SSTORE opcode gas cost calculation (including refunds) with\nthe following logic:\n\n If current value equals new value (this is a no-op), 200 gas is\ndeducted.\n If current value does not equal new value\n\n If original value equals current value (this storage slot has\nnot been changed by the current execution context)\n\n If original value is 0, 20000 gas is deducted.\n Otherwise, 5000 gas is deducted. If new value is 0, add 15000\ngas to refund counter.\n\n If original value does not equal current value (this storage\nslot is dirty), 200 gas is deducted. Apply both of the following\nclauses.\n\n If original value is not 0\n\n If current value is 0 (also means that new value is not\n0), remove 15000 gas from refund counter. We can prove that\nrefund counter will never go below 0.\n If new value is 0 (also means that current value is not\n0), add 15000 gas to refund counter.\n\n If original value equals new value (this storage slot is\nreset)\n\n If original value is 0, add 19800 gas to refund counter.\n Otherwise, add 4800 gas to refund counter.\n\nRefund counter works as before – it is limited to half of the gas\nconsumed. On a transaction level, refund counter will never go below\nzero. However, there are some important notes depending on the\nimplementation details:\n\n If an implementation uses “transaction level” refund counter (refund\nis checkpointed at each call frame), then the refund counter\ncontinues to be unsigned.\n If an implementation uses “execution-frame level” refund counter\n(a new refund counter is created at each call frame, and then merged\nback to parent when the call frame finishes), then the refund\ncounter needs to be changed to signed – at internal calls, a child\nrefund can go below zero.\n\n Explanation\n\nThe new gas cost scheme for SSTORE is divided into three different\ntypes:\n\n No-op: the virtual machine does not need to do anything. This is\nthe case if current value equals new value.\n Fresh: this storage slot has not been changed, or has been reset\nto its original value. This is the case if current value does not\nequal new value, and original value equals current value.\n Dirty: this storage slot has already been changed. This is the\ncase if current value does not equal new value, and original\nvalue does not equal current value.\n\nWe can see that the above three types cover all possible variations of\noriginal value, current value, and new value.\n\nNo-op is a trivial operation. Below we only consider cases for\nFresh and Dirty.\n\nAll initial (not-No-op) SSTORE on a particular storage slot starts\nwith Fresh. After that, it will become Dirty if the value has\nbeen changed. When going from Fresh to Dirty, we charge the\ngas cost the same as current scheme. A Dirty storage slot can be\nreset back to Fresh via a SSTORE opcode. This will trigger a\nrefund.\n\nWhen a storage slot remains at Dirty, we charge 200 gas. In this\ncase, we would also need to keep track of R_SCLEAR refunds – if we\nalready issued the refund but it no longer applies (current value is\n0), then removes this refund from the refund counter. If we didn’t\nissue the refund but it applies now (new value is 0), then adds this\nrefund to the refund counter. It is not possible where a refund is not\nissued but we remove the refund in the above case, because all storage\nslot starts with Fresh state.\n\n State Transition\n\nBelow is a graph (by\n@Arachnid)\nshowing possible state transition of gas costs. We ignore No-op\nstate because that is trivial:\n\nBelow is table version of the above diagram. Vertical shows the new\nvalue being set, and horizontal shows the state of original value\nand current value.\n\nWhen original value is 0:\n\n A (current=orig=0)\n B (current!=orig)\n\n ~0\n B; 20k gas\n B; 200 gas\n\n 0\n A; 200 gas\n A; 200 gas, 19.8k refund\n\nWhen original value is not 0:\n\n X (current=orig!=0)\n Y (current!=orig)\n Z (current=0)\n\n orig\n X; 200 gas\n X; 200 gas, 4.8k refund\n X; 200 gas, -10.2k refund\n\n ~orig, ~0\n Y; 5k gas\n Y; 200 gas\n Y; 200 gas, -15k refund\n\n 0\n Z; 5k gas, 15k refund\n Z; 200 gas, 15k refund\n Z; 200 gas\n\n Rationale\n\nThis EIP mostly achieves what a transient storage tries to do\n(EIP-1087 and EIP-1153), but without the complexity of introducing the\nconcept of “dirty maps”, or an extra storage struct.\n\n We don’t suffer from the optimization limitation of\nEIP-1087. EIP-1087 requires keeping a dirty map for storage changes,\nand implicitly makes the assumption that a transaction’s storage\nchanges are committed to the storage trie at the end of a\ntransaction. This works well for some implementations, but not for\nothers. After EIP-658, an efficient storage cache implementation\nwould probably use an in-memory trie (without RLP encoding/decoding)\nor other immutable data structures to keep track of storage changes,\nand only commit changes at the end of a block. For them, it is\npossible to know a storage’s original value and current value, but\nit is not possible to iterate over all storage changes without\nincurring additional memory or processing costs.\n It never costs more gas compared with the current scheme.\n It covers all usages for a transient storage. Clients that are easy\nto implement EIP-1087 will also be easy to implement this\nspecification. Some other clients might require a little bit extra\nrefactoring on this. Nonetheless, no extra memory or processing cost\nis needed on runtime.\n\nRegarding SSTORE gas cost and refunds, see Appendix for proofs of\nproperties that this EIP satisfies.\n\n For absolute gas used (that is, actual gas used minus refund),\nthis EIP is equivalent to EIP-1087 for all cases.\n For one particular case, where a storage slot is changed, reset to\nits original value, and then changed again, EIP-1283 would move more\ngases to refund counter compared with EIP-1087.\n\nExamine examples provided in EIP-1087’s Motivation:\n\n If a contract with empty storage sets slot 0 to 1, then back to 0,\nit will be charged 20000 + 200 - 19800 = 400 gas.\n A contract with empty storage that increments slot 0 5 times will be\ncharged 20000 + 5 * 200 = 21000 gas.\n A balance transfer from account A to account B followed by a\ntransfer from B to C, with all accounts having nonzero starting and\nending balances, it will cost 5000 * 3 + 200 - 4800 = 10400 gas.\n\n Backwards Compatibility\n\nThis EIP requires a hard fork to implement. No gas cost increase is\nanticipated, and many contracts will see gas reduction.\n\n Test Cases\n\nBelow we provide 17 test cases. 15 of them covering consecutive two\nSSTORE operations are based on work by\n@chfast. Two additional\ncases with three SSTORE operations is used to test the case when a\nslot is reset and then set again.\n\n Code\n Used Gas\n Refund\n Original\n 1st\n 2nd\n 3rd\n\n 0x60006000556000600055\n 412\n 0\n 0\n 0\n 0\n\n 0x60006000556001600055\n 20212\n 0\n 0\n 0\n 1\n\n 0x60016000556000600055\n 20212\n 19800\n 0\n 1\n 0\n\n 0x60016000556002600055\n 20212\n 0\n 0\n 1\n 2\n\n 0x60016000556001600055\n 20212\n 0\n 0\n 1\n 1\n\n 0x60006000556000600055\n 5212\n 15000\n 1\n 0\n 0\n\n 0x60006000556001600055\n 5212\n 4800\n 1\n 0\n 1\n\n 0x60006000556002600055\n 5212\n 0\n 1\n 0\n 2\n\n 0x60026000556000600055\n 5212\n 15000\n 1\n 2\n 0\n\n 0x60026000556003600055\n 5212\n 0\n 1\n 2\n 3\n\n 0x60026000556001600055\n 5212\n 4800\n 1\n 2\n 1\n\n 0x60026000556002600055\n 5212\n 0\n 1\n 2\n 2\n\n 0x60016000556000600055\n 5212\n 15000\n 1\n 1\n 0\n\n 0x60016000556002600055\n 5212\n 0\n 1\n 1\n 2\n\n 0x60016000556001600055\n 412\n 0\n 1\n 1\n 1\n\n 0x600160005560006000556001600055\n 40218\n 19800\n 0\n 1\n 0\n 1\n\n 0x600060005560016000556000600055\n 10218\n 19800\n 1\n 0\n 1\n 0\n\n Appendix: Proof\n\nBecause the storage slot’s original value is defined as the value\nwhen a reversion happens on the current transaction, it’s easy to\nsee that call frames won’t interfere SSTORE gas calculation. So\nalthough the below proof is discussed without call frames, it applies\nto all situations with call frames. We will discuss the case\nseparately for original value being zero and not zero, and use\ninduction to prove some properties of SSTORE gas cost.\n\nFinal value is the value of a particular storage slot at the end of\na transaction. Absolute gas used is the absolute value of gas used\nminus refund. We use N to represent the total number of SSTORE\noperations on a storage slot. For states discussed below, refer to\nState Transition in Explanation section.\n\n Original Value Being Zero\n\nWhen original value is 0, we want to prove that:\n\n Case I: If the final value ends up still being 0, we want to charge 200 *\nN gases, because no disk write is needed.\n Case II: If the final value ends up being a non-zero value, we want to\ncharge 20000 + 200 * (N-1) gas, because it requires writing this\nslot to disk.\n\n Base Case\n\nWe always start at state A. The first SSTORE can:\n\n Go to state A: 200 gas is deducted. We satisfy Case I because\n200 * N == 200 * 1.\n Go to state B: 20000 gas is deducted. We satisfy Case II because\n20000 + 200 * (N-1) == 20000 + 200 * 0.\n\n Inductive Step\n\n From A to A. The previous gas cost is 200 * (N-1). The current\ngas cost is 200 + 200 * (N-1). It satisfy Case I.\n From A to B. The previous gas cost is 200 * (N-1). The current\ngas cost is 20000 + 200 * (N-1). It satisfy Case II.\n From B to B. The previous gas cost is 20000 + 200 * (N-2). The\ncurrent gas cost is 200 + 20000 + 200 * (N-2). It satisfy\nCase II.\n From B to A. The previous gas cost is 20000 + 200 * (N-2). The\ncurrent gas cost is 200 - 19800 + 20000 + 200 * (N-2). It satisfy\nCase I.\n\n Original Value Not Being Zero\n\nWhen original value is not 0, we want to prove that:\n\n Case I: If the final value ends up unchanged, we want to\ncharge 200 * N gases, because no disk write is needed.\n Case II: If the final value ends up being zero, we want to\ncharge 5000 - 15000 + 200 * (N-1) gas. Note that 15000 is the\nrefund in actual definition.\n Case III: If the final value ends up being a changed non-zero\nvalue, we want to charge 5000 + 200 * (N-1) gas.\n\n Base Case\n\nWe always start at state X. The first SSTORE can:\n\n Go to state X: 200 gas is deducted. We satisfy Case I because\n200 * N == 200 * 1.\n Go to state Y: 5000 gas is deducted. We satisfy Case III because\n5000 + 200 * (N-1) == 5000 + 200 * 0.\n Go to state Z: The absolute gas used is 5000 - 15000 where 15000\nis the refund. We satisfy Case II because 5000 - 15000 + 200 *\n(N-1) == 5000 - 15000 + 200 * 0.\n\n Inductive Step\n\n From X to X. The previous gas cost is 200 * (N-1). The current gas\ncost is 200 + 200 * (N-1). It satisfy Case I.\n From X to Y. The previous gas cost is 200 * (N-1). The current gas\ncost is 5000 + 200 * (N-1). It satisfy Case III.\n From X to Z. The previous gas cost is 200 * (N-1). The current\nabsolute gas cost is 5000 - 15000 + 200 * (N-1). It satisfy Case\nII.\n From Y to X. The previous gas cost is 5000 + 200 * (N-2). The\nabsolute current gas cost is 200 - 4800 + 5000 + 200 * (N-2). It\nsatisfy Case I.\n From Y to Y. The previous gas cost is 5000 + 200 * (N-2). The\ncurrent gas cost is 200 + 5000 + 200 * (N-2). It satisfy Case\nIII.\n From Y to Z. The previous gas cost is 5000 + 200 * (N-2). The\ncurrent absolute gas cost is 200 - 15000 + 5000 + 200 * (N-2). It\nsatisfy Case II.\n From Z to X. The previous gas cost is 5000 - 15000 + 200 *\n(N-2). The current absolute gas cost is 200 + 10200 + 5000 -\n15000 + 200 * (N-2). It satisfy Case I.\n From Z to Y. The previous gas cost is 5000 - 15000 + 200 *\n(N-2). The current absolute gas cost is 200 + 15000 + 5000 -\n15000 + 200 * (N-2). It satisfy Case III.\n From Z to Z. The previous gas cost is 5000 - 15000 + 200 *\n(N-2). The current absolute gas cost is 200 + 5000 - 15000 + 200 *\n(N-2). It satisfy Case II.\n\n Copyright\n\nCopyright and related rights waived via CC0.\n\n Citation\n Please cite this document as:\n\n Wei Tang (@sorpaas), \"EIP-1283: Net gas metering for SSTORE without dirty maps,\" Ethereum Improvement Proposals, no. 1283, August 2018. Available: https://eips.ethereum.org/EIPS/eip-1283.","tokens":3349,"squid":"spider-05","role":"Spec Spider","at":1791341892355,"hash":"dcccedbd3a887f907be58d6a54b3ef20eeca96fa"}
{"url":"https://eips.ethereum.org/EIPS/eip-1014","domain":"eips.ethereum.org","title":"EIP-1014: Skinny CREATE2","text":"🎉 Final\n\n Standards Track: Core\n\n EIP-1014: Skinny CREATE2\n\n Authors\n Vitalik Buterin (@vbuterin)\n\n Created\n 2018-04-20\n\n Specification\n\nAdds a new opcode (CREATE2) at 0xf5, which takes 4 stack arguments: endowment, memory_start, memory_length, salt. Behaves identically to CREATE (0xf0), except using keccak256( 0xff ++ address ++ salt ++ keccak256(init_code))[12:] instead of the usual sender-and-nonce-hash as the address where the contract is initialized at.\n\nThe CREATE2 has the same gas schema as CREATE, but also an extra hashcost of GSHA3WORD * ceil(len(init_code) / 32), to account for the hashing that must be performed. The hashcost is deducted at the same time as memory-expansion gas and CreateGas is deducted: before evaluation of the resulting address and the execution of init_code.\n\n 0xff is a single byte,\n address is always 20 bytes,\n salt is always 32 bytes (a stack item).\n\nThe preimage for the final hashing round is thus always exactly 85 bytes long.\n\nThe coredev-call at 2018-08-10 decided to use the formula above.\n\n Motivation\n\nAllows 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.\n\n Rationale\n\n Address formula\n\n Ensures that addresses created with this scheme cannot collide with addresses created using the traditional keccak256(rlp([sender, nonce])) formula, as 0xff can only be a starting byte for RLP for data many petabytes long.\n Ensures that the hash preimage has a fixed size,\n\n Gas cost\n\nSince address calculation depends on hashing the init_code, it would leave clients open to DoS attacks if executions could repeatedly cause hashing of large pieces of init_code, since expansion of memory is paid for only once. This EIP uses the same cost-per-word as the SHA3 opcode.\n\n Clarifications\n\nThe init_code is the code that, when executed, produces the runtime bytecode that will be placed into the state, and which typically is used by high level languages to implement a ‘constructor’.\n\nThis EIP makes collisions possible. The behaviour at collisions is specified by EIP-684:\n\n If a contract creation is attempted, due to either a creation transaction or the CREATE (or future CREATE2) opcode, and the destination address already has either nonzero nonce, or nonempty code, then the creation throws immediately, with exactly the same behavior as would arise if the first byte in the init code were an invalid opcode. This applies retroactively starting from genesis.\n\nSpecifically, if nonce or code is nonzero, then the create-operation fails.\n\nWith EIP-161\n\n Account creation transactions and the CREATE operation SHALL, prior to the execution of the initialisation code, increment the nonce over and above its normal starting value by one\n\nThis means that if a contract is created in a transaction, the nonce is immediately non-zero, with the side-effect that a collision within the same transaction will always fail – even if it’s carried out from the init_code itself.\n\nIt should also be noted that SELFDESTRUCT (0xff) has no immediate effect on nonce or code, thus a contract cannot be destroyed and recreated within one transaction.\n\n Examples\n\nExample 0\n\n address 0x0000000000000000000000000000000000000000\n salt 0x0000000000000000000000000000000000000000000000000000000000000000\n init_code 0x00\n gas (assuming no mem expansion): 32006\n result: 0x4D1A2e2bB4F88F0250f26Ffff098B0b30B26BF38\n\nExample 1\n\n address 0xdeadbeef00000000000000000000000000000000\n salt 0x0000000000000000000000000000000000000000000000000000000000000000\n init_code 0x00\n gas (assuming no mem expansion): 32006\n result: 0xB928f69Bb1D91Cd65274e3c79d8986362984fDA3\n\nExample 2\n\n address 0xdeadbeef00000000000000000000000000000000\n salt 0x000000000000000000000000feed000000000000000000000000000000000000\n init_code 0x00\n gas (assuming no mem expansion): 32006\n result: 0xD04116cDd17beBE565EB2422F2497E06cC1C9833\n\nExample 3\n\n address 0x0000000000000000000000000000000000000000\n salt 0x0000000000000000000000000000000000000000000000000000000000000000\n init_code 0xdeadbeef\n gas (assuming no mem expansion): 32006\n result: 0x70f2b2914A2a4b783FaEFb75f459A580616Fcb5e\n\nExample 4\n\n address 0x00000000000000000000000000000000deadbeef\n salt 0x00000000000000000000000000000000000000000000000000000000cafebabe\n init_code 0xdeadbeef\n gas (assuming no mem expansion): 32006\n result: 0x60f3f640a8508fC6a86d45DF051962668E1e8AC7\n\nExample 5\n\n address 0x00000000000000000000000000000000deadbeef\n salt 0x00000000000000000000000000000000000000000000000000000000cafebabe\n init_code 0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef\n gas (assuming no mem expansion): 32012\n result: 0x1d8bfDC5D46DC4f61D6b6115972536eBE6A8854C\n\nExample 6\n\n address 0x0000000000000000000000000000000000000000\n salt 0x0000000000000000000000000000000000000000000000000000000000000000\n init_code 0x\n gas (assuming no mem expansion): 32000\n result: 0xE33C0C7F7df4809055C3ebA6c09CFe4BaF1BD9e0\n\n Citation\n Please cite this document as:\n\n Vitalik Buterin (@vbuterin), \"EIP-1014: Skinny CREATE2,\" Ethereum Improvement Proposals, no. 1014, April 2018. Available: https://eips.ethereum.org/EIPS/eip-1014.","tokens":1346,"squid":"spider-05","role":"Spec Spider","at":1791341903723,"hash":"281b788baaad12d12740fba763c45c6dcb59a8b7"}
{"url":"https://eips.ethereum.org/EIPS/eip-1046","domain":"eips.ethereum.org","title":"ERC-1046: tokenURI Interoperability","text":"🎉 Final\n\n Standards Track: ERC\n\n ERC-1046: tokenURI Interoperability\n\n Extends ERC-20 with an ERC-721-like tokenURI, and extends ERC-721 and ERC-1155 with interoperability\n\n Authors\n Tommy Nicholas (@tomasienrbc), Matt Russo (@mateosu), John Zettler (@JohnZettler), Matt Condon (@shrugs), Gavin John (@Pandapip1)\n\n Created\n 2018-04-13\n\n Requires\n\n EIP-20, \n\n EIP-721, \n\n EIP-1155\n\n Abstract\n\nERC-721 introduced a tokenURI function for non-fungible tokens to handle miscellaneous metadata such as:\n\n thumbnail image\n title\n description\n special asset properties\n etc.\n\nThis ERC adds a tokenURI function to ERC-20, and extends ERC-721 and ERC-1155 to enable interoperability between all three types of token URI.\n\n Motivation\n\nSee the note about the metadata extension in ERC-721. The same arguments apply to ERC-20.\n\nBeing able to use similar mechanisms to extract metadata for ERC-20, ERC-721, ERC-1155, and future standards is useful for determining:\n\n What type of token a contract is (if any);\n How to display a token to a user, either in an asset listing page or on a dedicated token page; and\n Determining the capabilities of the token\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\n Interoperability Metadata\n\nThe following TypeScript interface is used in later sections:\n\n/**\n * Interoperability metadata.\n * This can be extended by other proposals.\n * \n * All fields MUST be optional.\n * **Not every field has to be a boolean.** Any optional JSON-serializable object can be used by extensions.\n */\ninterface InteroperabilityMetadata {\n /**\n * This MUST be true if this is ERC-1046 Token Metadata, otherwise, this MUST be omitted.\n * Setting this to true indicates to wallets that the address should be treated as an ERC-20 token.\n **/\n erc1046?: boolean | undefined;\n\n /**\n * This MUST be true if this is ERC-721 Token Metadata, otherwise, this MUST be omitted.\n * Setting this to true indicates to wallets that the address should be treated as an ERC-721 token.\n **/\n erc721?: boolean | undefined;\n\n /**\n * This MUST be true if this is ERC-1155 Token Metadata, otherwise, this MUST be omitted.\n * Setting this to true indicates to wallets that the address should be treated as an ERC-1155 token.\n **/\n erc1155?: boolean | undefined;\n}\n\n ERC-20 Extension\n\n ERC-20 Interface Extension\n\nCompliant contracts MUST implement the following Solidity interface:\n\npragma solidity ^0.8.0;\n\n/// @title ERC-20 Metadata Extension\ninterface ERC20TokenMetadata /* is ERC20 */ {\n /// @notice Gets an ERC-721-like token URI\n /// @dev The resolved data MUST be in JSON format and support ERC-1046's ERC-20 Token Metadata Schema\n function tokenURI() external view returns (string);\n}\n\n ERC-20 Token Metadata Schema\n\nThe resolved JSON of the tokenURI described in the ERC-20 Interface Extension section MUST conform to the following TypeScript interface:\n\n/**\n * Asset Metadata\n */\ninterface ERC20TokenMetadata {\n /**\n * Interoperability, to differentiate between different types of tokens and their corresponding URIs.\n **/\n interop: InteroperabilityMetadata;\n\n /**\n * The name of the ERC-20 token. \n * If the `name()` function is present in the ERC-20 token and returns a nonempty string, these MUST be the same value.\n */\n name?: string;\n\n /**\n * The symbol of the ERC-20 token. \n * If the `symbol()` function is present in the ERC-20 token and returns a nonempty string, these MUST be the same value.\n */\n symbol?: string;\n\n /**\n * The decimals of the ERC-20 token. \n * If the `decimals()` function is present in the ERC-20 token, these MUST be the same value.\n * Defaults to 18 if neither this parameter nor the ERC-20 `decimals()` function are present.\n */\n decimals?: number;\n\n /**\n * Provides a short one-paragraph description of the ERC-20 token, without any markup or newlines.\n */\n description?: string;\n\n /**\n * A URI pointing to a resource with mime type `image/*` that represents this token.\n * If the image is a bitmap, it SHOULD have a width between 320 and 1080 pixels\n * The image SHOULD have an aspect ratio between 1.91:1 and 4:5 inclusive.\n */\n image?: string;\n\n /**\n * One or more URIs each pointing to a resource with mime type `image/*` that represents this token.\n * If an image is a bitmap, it SHOULD have a width between 320 and 1080 pixels\n * Images SHOULD have an aspect ratio between 1.91:1 and 4:5 inclusive.\n */\n images?: string[];\n\n /**\n * One or more URIs each pointing to a resource with mime type `image/*` that represent an icon for this token.\n * If an image is a bitmap, it SHOULD have a width between 320 and 1080 pixels, and MUST have a height equal to its width\n * Images MUST have an aspect ratio of 1:1, and use a transparent background\n */\n icons?: string[];\n}\n\n ERC-721 Extension\n\n Extension to the ERC-721 Metadata Schema\n\nContracts that implement ERC-721 and use its token metadata URI SHOULD to use the following TypeScript extension to the metadata URI:\n\ninterface ERC721TokenMetadataInterop extends ERC721TokenMetadata {\n /**\n * Interoperability, to avoid confusion between different token URIs\n **/\n interop: InteroperabilityMetadata;\n}\n\n ERC-1155 Extension\n\n ERC-1155 Interface Extension\n\nERC-1155-compliant contracts using the metadata extension SHOULD implement the following Solidity interface:\n\npragma solidity ^0.8.0;\n\n/// @title ERC-1155 Metadata URI Interoperability Extension\ninterface ERC1155TokenMetadataInterop /* is ERC1155 */ {\n /// @notice Gets an ERC-1046-compliant ERC-1155 token URI\n /// @param tokenId The token ID to get the URI of\n /// @dev The resolved data MUST be in JSON format and support ERC-1046's Extension to the ERC-1155 Token Metadata Schema\n /// This MUST be the same URI as the `uri(tokenId)` function, if present.\n function tokenURI(uint256 tokenId) external view returns (string);\n}\n\n Extension to the ERC-1155 Metadata Schema\n\nContracts that implement ERC-1155 and use its token metadata URI are RECOMMENDED to use the following extension to the metadata URI. Contracts that implement the interface described in the ERC-1155 Interface Extension section MUST use the following TypeScript extension:\n\ninterface ERC1155TokenMetadataInterop extends ERC1155TokenMetadata {\n /**\n * Interoperability, to avoid confusion between different token URIs\n **/\n interop: InteroperabilityMetadata;\n}\n\n Miscellaneous Recommendations\n\nTo save gas, it is RECOMMENDED for compliant contracts not to implement the name(), symbol(), or decimals() functions, and instead to only include them in the metadata URI. Additionally, for ERC-20 tokens, if the decimals is 18, then it is NOT RECOMMENDED to include the decimals field in the metadata.\n\n Rationale\n\nThis ERC makes adding metadata to ERC-20 tokens more straightforward for developers, with minimal to no disruption to the overall ecosystem. Using the same parameter name makes it easier to reuse code.\n\nAdditionally, the recommendations not to use ERC-20’s name, symbol, and decimals functions save gas.\n\nBuilt-in interoperability is useful as otherwise it might not be easy to differentiate the type of the token. Interoperability could be done using ERC-165, but static calls are time-inefficient for wallets and websites, and is generally inflexible. Instead, including interoperability data in the token URI increases flexibility while also giving a performance increase.\n\n Backwards Compatibility\n\nThis EIP is fully backwards compatible as its implementation simply extends the functionality of ERC-20 tokens and is optional. Additionally, it makes backward compatible recommendations for ERC-721 and ERC-1155 tokens.\n\n Security Considerations\n\n Server-Side Request Forgery (SSRF)\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 Copyright\n\nCopyright and related rights waived via CC0.\n\n Citation\n Please cite this document as:\n\n Tommy Nicholas (@tomasienrbc), Matt Russo (@mateosu), John Zettler (@JohnZettler), Matt Condon (@shrugs), Gavin John (@Pandapip1), \"ERC-1046: tokenURI Interoperability,\" Ethereum Improvement Proposals, no. 1046, April 2018. Available: https://eips.ethereum.org/EIPS/eip-1046.","tokens":2113,"squid":"spider-05","role":"Spec Spider","at":1791341915053,"hash":"5f555af62d156da099efdf90f1261726cb67d8ae"}
{"url":"https://across.to/blog","domain":"across.to","title":"Across Blog","text":"The Across BlogResources for a crosschain worldThis is the home for official news, updates, press, and perspectives from Across. Here you’ll find stories of network evolution, community milestones, and bold ideas turning into real-world impact.Sep 25, 2026The Best Crypto Bridges of 2026The best crypto bridges of 2026: a comparison from a team that builds one of them. 12 MIN READ#ProductSep 21, 2026Arc on Across 5 MIN READ#ProductSep 17, 2026The Across Token Buyout Portal is Now Live 2 MIN READ#GuidesAug 10, 2026Across Integrates Paxos Labs' Transit for $50M Transfers 3 MIN READ#PartnersAug 9, 2026How to Move Your $ACX Off Exchanges 1 MIN READ#GuidesAug 3, 2026The Polygon DeFi Ecosystem in 2026: Where to Bridge and Why 4 MIN READ#ResearchJul 31, 2026No Gas on a New Chain? How to Arrive With ETH Ready to Spend 5 MIN READ#GuidesJul 29, 2026How to Bridge to Optimism: The OP Mainnet Guide for 2026 5 MIN READ#GuidesJul 27, 2026Canonical Bridges vs Third-Party Bridges: What's the Difference? 5 MIN READ#BasicsJul 22, 2026Crosschain Swaps Explained: Swap and Bridge in One Transaction 5 MIN READ#BasicsJul 20, 2026The Infrastructure Layer Beneath Stablecoin Adoption (Part 2 of 2) 7 MIN READ#ResearchJul 17, 2026The Fastest Way to Bridge USDC and USDT to Plasma 4 MIN READ#GuidesJul 15, 2026Bridge ETH to Base in Under 2 Seconds 4 MIN READ#GuidesJul 14, 2026Robinhood Chain's First Week: CashCat, $1B in DEX Volume, and How to Get There 4 MIN READ#ResearchJul 13, 2026Why Stablecoins Are Eating Real-World Payments - Part 1 5 MIN READ#ResearchJul 10, 2026How to Move USDC to Polygon Fast 3 MIN READ#GuidesJul 8, 2026What Is Chain Abstraction? The End of Picking Networks 5 MIN READ#BasicsJul 6, 2026Bridge to Robinhood Chain with Across 2 MIN READ#ProductJul 3, 2026The Bridge Risk Reckoning: How to Evaluate Bridge Risk in 2026 4 MIN READ#Research","tokens":464,"squid":"spider-09","role":"Bridge Spider","at":1791341920835,"hash":"d64b091118fa8cb674b6ac6b28da84c5b40d3033"}
{"url":"https://eips.ethereum.org/EIPS/eip-1155","domain":"eips.ethereum.org","title":"ERC-1155: Multi Token Standard","text":"🎉 Final\n\n Standards Track: ERC\n\n ERC-1155: Multi Token Standard\n\n Authors\n Witek Radomski <witek@enjin.io>, Andrew Cooke <ac0dem0nk3y@gmail.com>, Philippe Castonguay (@phabc) <pc@horizongames.net>, James Therien <james@turing-complete.com>, Eric Binet <eric@enjin.io>, Ronan Sandford (@wighawag) <wighawag@gmail.com>\n\n Created\n 2018-06-17\n\n Requires\n\n EIP-165\n\n Simple Summary\n\nA standard interface for contracts that manage multiple token types. A single deployed contract may include any combination of fungible tokens, non-fungible tokens or other configurations (e.g. semi-fungible tokens).\n\n Abstract\n\nThis standard outlines a smart contract interface that can represent any number of fungible and non-fungible token types. Existing standards such as ERC-20 require deployment of separate contracts per token type. The ERC-721 standard’s token ID is a single non-fungible index and the group of these non-fungibles is deployed as a single contract with settings for the entire collection. In contrast, the ERC-1155 Multi Token Standard allows for each token ID to represent a new configurable token type, which may have its own metadata, supply and other attributes.\n\nThe _id argument contained in each function’s argument set indicates a specific token or token type in a transaction.\n\n Motivation\n\nTokens standards like ERC-20 and ERC-721 require a separate contract to be deployed for each token type or collection. This places a lot of redundant bytecode on the Ethereum blockchain and limits certain functionality by the nature of separating each token contract into its own permissioned address. With the rise of blockchain games and platforms like Enjin Coin, game developers may be creating thousands of token types, and a new type of token standard is needed to support them. However, ERC-1155 is not specific to games and many other applications can benefit from this flexibility.\n\nNew functionality is possible with this design such as transferring multiple token types at once, saving on transaction costs. Trading (escrow / atomic swaps) of multiple tokens can be built on top of this standard and it removes the need to “approve” individual token contracts separately. It is also easy to describe and mix multiple fungible or non-fungible token types in a single contract.\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\nSmart contracts implementing the ERC-1155 standard MUST implement all of the functions in the ERC1155 interface.\n\nSmart contracts implementing the ERC-1155 standard MUST implement the ERC-165 supportsInterface function and MUST return the constant value true if 0xd9b67a26 is passed through the interfaceID argument.\n\npragma solidity ^0.5.9;\n\n/**\n @title ERC-1155 Multi Token Standard\n @dev See https://eips.ethereum.org/EIPS/eip-1155\n Note: The ERC-165 identifier for this interface is 0xd9b67a26.\n */\ninterface ERC1155 /* is ERC165 */ {\n /**\n @dev Either `TransferSingle` or `TransferBatch` MUST emit when tokens are transferred, including zero value transfers as well as minting or burning (see \"Safe Transfer Rules\" section of the standard).\n The `_operator` argument MUST be the address of an account/contract that is approved to make the transfer (SHOULD be msg.sender).\n The `_from` argument MUST be the address of the holder whose balance is decreased.\n The `_to` argument MUST be the address of the recipient whose balance is increased.\n The `_id` argument MUST be the token type being transferred.\n The `_value` argument MUST be the number of tokens the holder balance is decreased by and match what the recipient balance is increased by.\n When minting/creating tokens, the `_from` argument MUST be set to `0x0` (i.e. zero address).\n When burning/destroying tokens, the `_to` argument MUST be set to `0x0` (i.e. zero address). \n */\n event TransferSingle(address indexed _operator, address indexed _from, address indexed _to, uint256 _id, uint256 _value);\n\n /**\n @dev Either `TransferSingle` or `TransferBatch` MUST emit when tokens are transferred, including zero value transfers as well as minting or burning (see \"Safe Transfer Rules\" section of the standard). \n The `_operator` argument MUST be the address of an account/contract that is approved to make the transfer (SHOULD be msg.sender).\n The `_from` argument MUST be the address of the holder whose balance is decreased.\n The `_to` argument MUST be the address of the recipient whose balance is increased.\n The `_ids` argument MUST be the list of tokens being transferred.\n The `_values` argument MUST be the list of number of tokens (matching the list and order of tokens specified in _ids) the holder balance is decreased by and match what the recipient balance is increased by.\n When minting/creating tokens, the `_from` argument MUST be set to `0x0` (i.e. zero address).\n When burning/destroying tokens, the `_to` argument MUST be set to `0x0` (i.e. zero address). \n */\n event TransferBatch(address indexed _operator, address indexed _from, address indexed _to, uint256[] _ids, uint256[] _values);\n\n /**\n @dev MUST emit when approval for a second party/operator address to manage all tokens for an owner address is enabled or disabled (absence of an event assumes disabled). \n */\n event ApprovalForAll(address indexed _owner, address indexed _operator, bool _approved);\n\n /**\n @dev MUST emit when the URI is updated for a token ID.\n URIs are defined in RFC 3986.\n The URI MUST point to a JSON file that conforms to the \"ERC-1155 Metadata URI JSON Schema\".\n */\n event URI(string _value, uint256 indexed _id);\n\n /**\n @notice Transfers `_value` amount of an `_id` from the `_from` address to the `_to` address specified (with safety call).\n @dev Caller must be approved to manage the tokens being transferred out of the `_from` account (see \"Approval\" section of the standard).\n MUST revert if `_to` is the zero address.\n MUST revert if balance of holder for token `_id` is lower than the `_value` sent.\n MUST revert on any other error.\n MUST emit the `TransferSingle` event to reflect the balance change (see \"Safe Transfer Rules\" section of the standard).\n After the above conditions are met, this function MUST check if `_to` is a smart contract (e.g. code size > 0). If so, it MUST call `onERC1155Received` on `_to` and act appropriately (see \"Safe Transfer Rules\" section of the standard). \n @param _from Source address\n @param _to Target address\n @param _id ID of the token type\n @param _value Transfer amount\n @param _data Additional data with no specified format, MUST be sent unaltered in call to `onERC1155Received` on `_to`\n */\n function safeTransferFrom(address _from, address _to, uint256 _id, uint256 _value, bytes calldata _data) external;\n\n /**\n @notice Transfers `_values` amount(s) of `_ids` from the `_from` address to the `_to` address specified (with safety call).\n @dev Caller must be approved to manage the tokens being transferred out of the `_from` account (see \"Approval\" section of the standard).\n MUST revert if `_to` is the zero address.\n MUST revert if length of `_ids` is not the same as length of `_values`.\n MUST revert if any of the balance(s) of the holder(s) for token(s) in `_ids` is lower than the respective amount(s) in `_values` sent to the recipient.\n MUST revert on any other error. \n MUST emit `TransferSingle` or `TransferBatch` event(s) such that all the balance changes are reflected (see \"Safe Transfer Rules\" section of the standard).\n Balance changes and events MUST follow the ordering of the arrays (_ids[0]/_values[0] before _ids[1]/_values[1], etc).\n After the above conditions for the transfer(s) in the batch are met, this function MUST check if `_to` is a smart contract (e.g. code size > 0). If so, it MUST call the relevant `ERC1155TokenReceiver` hook(s) on `_to` and act appropriately (see \"Safe Transfer Rules\" section of the standard). \n @param _from Source address\n @param _to Target address\n @param _ids IDs of each token type (order and length must match _values array)\n @param _values Transfer amounts per token type (order and length must match _ids array)\n @param _data Additional data with no specified format, MUST be sent unaltered in call to the `ERC1155TokenReceiver` hook(s) on `_to`\n */\n function safeBatchTransferFrom(address _from, address _to, uint256[] calldata _ids, uint256[] calldata _values, bytes calldata _data) external;\n\n /**\n @notice Get the balance of an account's tokens.\n @param _owner The address of the token holder\n @param _id ID of the token\n @return The _owner's balance of the token type requested\n */\n function balanceOf(address _owner, uint256 _id) external view returns (uint256);\n\n /**\n @notice Get the balance of multiple account/token pairs\n @param _owners The addresses of the token holders\n @param _ids ID of the tokens\n @return The _owner's balance of the token types requested (i.e. balance for each (owner, id) pair)\n */\n function balanceOfBatch(address[] calldata _owners, uint256[] calldata _ids) external view returns (uint256[] memory);\n\n /**\n @notice Enable or disable approval for a third party (\"operator\") to manage all of the caller's tokens.\n @dev MUST emit the ApprovalForAll event on success.\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 */\n function setApprovalForAll(address _operator, bool _approved) external;\n\n /**\n @notice Queries the approval status of an operator for a given owner.\n @param _owner The owner of the tokens\n @param _operator Address of authorized operator\n @return True if the operator is approved, false if not\n */\n function isApprovedForAll(address _owner, address _operator) external view returns (bool);\n}\n\n ERC-1155 Token Receiver\n\nSmart contracts MUST implement all of the functions in the ERC1155TokenReceiver interface to accept transfers. See “Safe Transfer Rules” for further detail.\n\nSmart contracts MUST implement the ERC-165 supportsInterface function and signify support for the ERC1155TokenReceiver interface to accept transfers. See “ERC1155TokenReceiver ERC-165 rules” for further detail.\n\npragma solidity ^0.5.9;\n\n/**\n Note: The ERC-165 identifier for this interface is 0x4e2312e0.\n*/\ninterface ERC1155TokenReceiver {\n /**\n @notice Handle the receipt of a single ERC1155 token type.\n @dev An ERC1155-compliant smart contract MUST call this function on the token recipient contract, at the end of a `safeTransferFrom` after the balance has been updated. \n This function MUST return `bytes4(keccak256(\"onERC1155Received(address,address,uint256,uint256,bytes)\"))` (i.e. 0xf23a6e61) if it accepts the transfer.\n This function MUST revert if it rejects the transfer.\n Return of any other value than the prescribed keccak256 generated value MUST result in the transaction being reverted by the caller.\n @param _operator The address which initiated the transfer (i.e. msg.sender)\n @param _from The address which previously owned the token\n @param _id The ID of the token being transferred\n @param _value The amount of tokens being transferred\n @param _data Additional data with no specified format\n @return `bytes4(keccak256(\"onERC1155Received(address,address,uint256,uint256,bytes)\"))`\n */\n function onERC1155Received(address _operator, address _from, uint256 _id, uint256 _value, bytes calldata _data) external returns(bytes4);\n\n /**\n @notice Handle the receipt of multiple ERC1155 token types.\n @dev An ERC1155-compliant smart contract MUST call this function on the token recipient contract, at the end of a `safeBatchTransferFrom` after the balances have been updated. \n This function MUST return `bytes4(keccak256(\"onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)\"))` (i.e. 0xbc197c81) if it accepts the transfer(s).\n This function MUST revert if it rejects the transfer(s).\n Return of any other value than the prescribed keccak256 generated value MUST result in the transaction being reverted by the caller.\n @param _operator The address which initiated the batch transfer (i.e. msg.sender)\n @param _from The address which previously owned the token\n @param _ids An array containing ids of each token being transferred (order and length must match _values array)\n @param _values An array containing amounts of each token being transferred (order and length must match _ids array)\n @param _data Additional data with no specified format\n @return `bytes4(keccak256(\"onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)\"))`\n */\n function onERC1155BatchReceived(address _operator, address _from, uint256[] calldata _ids, uint256[] calldata _values, bytes calldata _data) external returns(bytes4); \n}\n\n Safe Transfer Rules\n\nTo be more explicit about how the standard safeTransferFrom and safeBatchTransferFrom functions MUST operate with respect to the ERC1155TokenReceiver hook functions, a list of scenarios and rules follows.\n\n Scenarios\n\nScenario#1 : The recipient is not a contract.\n\n onERC1155Received and onERC1155BatchReceived MUST NOT be called on an EOA (Externally Owned Account).\n\nScenario#2 : The transaction is not a mint/transfer of a token.\n\n onERC1155Received and onERC1155BatchReceived MUST NOT be called outside of a mint or transfer process.\n\nScenario#3 : The receiver does not implement the necessary ERC1155TokenReceiver interface function(s).\n\n The transfer MUST be reverted with the one caveat below.\n\n If the token(s) being sent are part of a hybrid implementation of another standard, that particular standard’s rules on sending to a contract MAY now be followed instead. See “Backwards Compatibility” section.\n\nScenario#4 : The receiver implements the necessary ERC1155TokenReceiver interface function(s) but returns an unknown value.\n\n The transfer MUST be reverted.\n\nScenario#5 : The receiver implements the necessary ERC1155TokenReceiver interface function(s) but throws an error.\n\n The transfer MUST be reverted.\n\nScenario#6 : The receiver implements the ERC1155TokenReceiver interface and is the recipient of one and only one balance change (e.g. safeTransferFrom called).\n\n The balances for the transfer MUST have been updated before the ERC1155TokenReceiver hook is called on a recipient contract.\n The transfer event MUST have been emitted to reflect the balance changes before the ERC1155TokenReceiver hook is called on the recipient contract.\n One of onERC1155Received or onERC1155BatchReceived MUST be called on the recipient contract.\n The onERC1155Received hook SHOULD be called on the recipient contract and its rules followed.\n\n See “onERC1155Received rules” for further rules that MUST be followed.\n\n The onERC1155BatchReceived hook MAY be called on the recipient contract and its rules followed.\n\n See “onERC1155BatchReceived rules” for further rules that MUST be followed.\n\nScenario#7 : The receiver implements the ERC1155TokenReceiver interface and is the recipient of more than one balance change (e.g. safeBatchTransferFrom called).\n\n All balance transfers that are referenced in a call to an ERC1155TokenReceiver hook MUST be updated before the ERC1155TokenReceiver hook is called on the recipient contract.\n All transfer events MUST have been emitted to reflect current balance changes before an ERC1155TokenReceiver hook is called on the recipient contract.\n onERC1155Received or onERC1155BatchReceived MUST be called on the recipient as many times as necessary such that every balance change for the recipient in the scenario is accounted for.\n\n The return magic value for every hook call MUST be checked and acted upon as per “onERC1155Received rules” and “onERC1155BatchReceived rules”.\n\n The onERC1155BatchReceived hook SHOULD be called on the recipient contract and its rules followed.\n\n See “onERC1155BatchReceived rules” for further rules that MUST be followed.\n\n The onERC1155Received hook MAY be called on the recipient contract and its rules followed.\n\n See “onERC1155Received rules” for further rules that MUST be followed.\n\nScenario#8 : You are the creator of a contract that implements the ERC1155TokenReceiver interface and you forward the token(s) onto another address in one or both of onERC1155Received and onERC1155BatchReceived.\n\n Forwarding should be considered acceptance and then initiating a new safeTransferFrom or safeBatchTransferFrom in a new context.\n\n The prescribed keccak256 acceptance value magic for the receiver hook being called MUST be returned after forwarding is successful.\n\n The _data argument MAY be re-purposed for the new context.\n If forwarding fails the transaction MAY be reverted.\n\n If the contract logic wishes to keep the ownership of the token(s) itself in this case it MAY do so.\n\nScenario#9 : You are transferring tokens via a non-standard API call i.e. an implementation specific API and NOT safeTransferFrom or safeBatchTransferFrom.\n\n In this scenario all balance updates and events output rules are the same as if a standard transfer function had been called.\n\n i.e. an external viewer MUST still be able to query the balance via a standard function and it MUST be identical to the balance as determined by TransferSingle and TransferBatch events alone.\n\n If the receiver is a contract the ERC1155TokenReceiver hooks still need to be called on it and the return values respected the same as if a standard transfer function had been called.\n\n However while the safeTransferFrom or safeBatchTransferFrom functions MUST revert if a receiving contract does not implement the ERC1155TokenReceiver interface, a non-standard function MAY proceed with the transfer.\n See “Implementation specific transfer API rules”.\n\n Rules\n\nsafeTransferFrom rules:\n\n Caller must be approved to manage the tokens being transferred out of the _from account (see “Approval” section).\n MUST revert if _to is the zero address.\n MUST revert if balance of holder for token _id is lower than the _value sent to the recipient.\n MUST revert on any other error.\n MUST emit the TransferSingle event to reflect the balance change (see “TransferSingle and TransferBatch event rules” section).\n After the above conditions are met, this function MUST check if _to is a smart contract (e.g. code size > 0). If so, it MUST call onERC1155Received on _to and act appropriately (see “onERC1155Received rules” section).\n\n The _data argument provided by the sender for the transfer MUST be passed with its contents unaltered to the onERC1155Received hook function via its _data argument.\n\nsafeBatchTransferFrom rules:\n\n Caller must be approved to manage all the tokens being transferred out of the _from account (see “Approval” section).\n MUST revert if _to is the zero address.\n MUST revert if length of _ids is not the same as length of _values.\n MUST revert if any of the balance(s) of the holder(s) for token(s) in _ids is lower than the respective amount(s) in _values sent to the recipient.\n MUST revert on any other error.\n MUST emit TransferSingle or TransferBatch event(s) such that all the balance changes are reflected (see “TransferSingle and TransferBatch event rules” section).\n The balance changes and events MUST occur in the array order they were submitted (_ids[0]/_values[0] before _ids[1]/_values[1], etc).\n After the above conditions are met, this function MUST check if _to is a smart contract (e.g. code size > 0). If so, it MUST call onERC1155Received or onERC1155BatchReceived on _to and act appropriately (see “onERC1155Received and onERC1155BatchReceived rules” section).\n\n The _data argument provided by the sender for the transfer MUST be passed with its contents unaltered to the ERC1155TokenReceiver hook function(s) via their _data argument.\n\nTransferSingle and TransferBatch event rules:\n\n TransferSingle SHOULD be used to indicate a single balance transfer has occurred between a _from and _to pair.\n\n It MAY be emitted multiple times to indicate multiple balance changes in the transaction, but note that TransferBatch is designed for this to reduce gas consumption.\n The _operator argument MUST be the address of an account/contract that is approved to make the transfer (SHOULD be msg.sender).\n The _from argument MUST be the address of the holder whose balance is decreased.\n The _to argument MUST be the address of the recipient whose balance is increased.\n The _id argument MUST be the token type being transferred.\n The _value argument MUST be the number of tokens the holder balance is decreased by and match what the recipient balance is increased by.\n When minting/creating tokens, the _from argument MUST be set to 0x0 (i.e. zero address). See “Minting/creating and burning/destroying rules”.\n When burning/destroying tokens, the _to argument MUST be set to 0x0 (i.e. zero address). See “Minting/creating and burning/destroying rules”.\n\n TransferBatch SHOULD be used to indicate multiple balance transfers have occurred between a _from and _to pair.\n\n It MAY be emitted with a single element in the list to indicate a singular balance change in the transaction, but note that TransferSingle is designed for this to reduce gas consumption.\n The _operator argument MUST be the address of an account/contract that is approved to make the transfer (SHOULD be msg.sender).\n The _from argument MUST be the address of the holder whose balance is decreased for each entry pair in _ids and _values.\n The _to argument MUST be the address of the recipient whose balance is increased for each entry pair in _ids and _values.\n The _ids array argument MUST contain the ids of the tokens being transferred.\n The _values array argument MUST contain the number of token to be transferred for each corresponding entry in _ids.\n _ids and _values MUST have the same length.\n When minting/creating tokens, the _from argument MUST be set to 0x0 (i.e. zero address). See “Minting/creating and burning/destroying rules”.\n When burning/destroying tokens, the _to argument MUST be set to 0x0 (i.e. zero address). See “Minting/creating and burning/destroying rules”.\n\n The total value transferred from address 0x0 minus the total value transferred to 0x0 observed via the TransferSingle and TransferBatch events MAY be used by clients and exchanges to determine the “circulating supply” for a given token ID.\n To broadcast the existence of a token ID with no initial balance, the contract SHOULD emit the TransferSingle event from 0x0 to 0x0, with the token creator as _operator, and a _value of 0.\n All TransferSingle and TransferBatch events MUST be emitted to reflect all the balance changes that have occurred before any call(s) to onERC1155Received or onERC1155BatchReceived.\n\n To make sure event order is correct in the case of valid re-entry (e.g. if a receiver contract forwards tokens on receipt) state balance and events balance MUST match before calling an external contract.\n\nonERC1155Received rules:\n\n The _operator argument MUST be the address of an account/contract that is approved to make the transfer (SHOULD be msg.sender).\n The _from argument MUST be the address of the holder whose balance is decreased.\n\n _from MUST be 0x0 for a mint.\n\n The _id argument MUST be the token type being transferred.\n The _value argument MUST be the number of tokens the holder balance is decreased by and match what the recipient balance is increased by.\n The _data argument MUST contain the information provided by the sender for the transfer with its contents unaltered.\n\n i.e. it MUST pass on the unaltered _data argument sent via the safeTransferFrom or safeBatchTransferFrom call for this transfer.\n\n The recipient contract MAY accept an increase of its balance by returning the acceptance magic value bytes4(keccak256(\"onERC1155Received(address,address,uint256,uint256,bytes)\"))\n\n If the return value is bytes4(keccak256(\"onERC1155Received(address,address,uint256,uint256,bytes)\")) the transfer MUST be completed or MUST revert if any other conditions are not met for success.\n\n The recipient contract MAY reject an increase of its balance by calling revert.\n\n If the recipient contract throws/reverts the transaction MUST be reverted.\n\n If the return value is anything other than bytes4(keccak256(\"onERC1155Received(address,address,uint256,uint256,bytes)\")) the transaction MUST be reverted.\n onERC1155Received (and/or onERC1155BatchReceived) MAY be called multiple times in a single transaction and the following requirements must be met:\n\n All callbacks represent mutually exclusive balance changes.\n The set of all calls to onERC1155Received and onERC1155BatchReceived describes all balance changes that occurred during the transaction in the order submitted.\n\n A contract MAY skip calling the onERC1155Received hook function if the transfer operation is transferring the token to itself.\n\nonERC1155BatchReceived rules:\n\n The _operator argument MUST be the address of an account/contract that is approved to make the transfer (SHOULD be msg.sender).\n The _from argument MUST be the address of the holder whose balance is decreased.\n\n _from MUST be 0x0 for a mint.\n\n The _ids argument MUST be the list of tokens being transferred.\n The _values argument MUST be the list of number of tokens (matching the list and order of tokens specified in _ids) the holder balance is decreased by and match what the recipient balance is increased by.\n The _data argument MUST contain the information provided by the sender for the transfer with its contents unaltered.\n\n i.e. it MUST pass on the unaltered _data argument sent via the safeBatchTransferFrom call for this transfer.\n\n The recipient contract MAY accept an increase of its balance by returning the acceptance magic value bytes4(keccak256(\"onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)\"))\n\n If the return value is bytes4(keccak256(\"onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)\")) the transfer MUST be completed or MUST revert if any other conditions are not met for success.\n\n The recipient contract MAY reject an increase of its balance by calling revert.\n\n If the recipient contract throws/reverts the transaction MUST be reverted.\n\n If the return value is anything other than bytes4(keccak256(\"onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)\")) the transaction MUST be reverted.\n onERC1155BatchReceived (and/or onERC1155Received) MAY be called multiple times in a single transaction and the following requirements must be met:\n\n All callbacks represent mutually exclusive balance changes.\n The set of all calls to onERC1155Received and onERC1155BatchReceived describes all balance changes that occurred during the transaction in the order submitted.\n\n A contract MAY skip calling the onERC1155BatchReceived hook function if the transfer operation is transferring the token(s) to itself.\n\nERC1155TokenReceiver ERC-165 rules:\n\n The implementation of the ERC-165 supportsInterface function SHOULD be as follows:\n function supportsInterface(bytes4 interfaceID) external view returns (bool) {\n return interfaceID == 0x01ffc9a7 || // ERC-165 support (i.e. `bytes4(keccak256('supportsInterface(bytes4)'))`).\n interfaceID == 0x4e2312e0; // ERC-1155 `ERC1155TokenReceiver` support (i.e. `bytes4(keccak256(\"onERC1155Received(address,address,uint256,uint256,bytes)\")) ^ bytes4(keccak256(\"onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)\"))`).\n }\n\n The implementation MAY differ from the above but:\n\n It MUST return the constant value true if 0x01ffc9a7 is passed through the interfaceID argument. This signifies ERC-165 support.\n It MUST return the constant value true if 0x4e2312e0 is passed through the interfaceID argument. This signifies ERC-1155 ERC1155TokenReceiver support.\n It MUST NOT consume more than 10,000 gas.\n\n This keeps it below the ERC-165 requirement of 30,000 gas, reduces the gas reserve needs and minimises possible side-effects of gas exhaustion during the call.\n\nImplementation specific transfer API rules:\n\n If an implementation specific API function is used to transfer ERC-1155 token(s) to a contract, the safeTransferFrom or safeBatchTransferFrom (as appropriate) rules MUST still be followed if the receiver implements the ERC1155TokenReceiver interface. If it does not the non-standard implementation SHOULD revert but MAY proceed.\n An example:\n\n An approved user calls a function such as function myTransferFrom(address _from, address _to, uint256[] calldata _ids, uint256[] calldata _values);.\n myTransferFrom updates the balances for _from and _to addresses for all _ids and _values.\n myTransferFrom emits TransferBatch with the details of what was transferred from address _from to address _to.\n myTransferFrom checks if _to is a contract address and determines that it is so (if not, then the transfer can be considered successful).\n myTransferFrom calls onERC1155BatchReceived on _to and it reverts or returns an unknown value (if it had returned bytes4(keccak256(\"onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)\")) the transfer can be considered successful).\n At this point myTransferFrom SHOULD revert the transaction immediately as receipt of the token(s) was not explicitly accepted by the onERC1155BatchReceived function.\n If however myTransferFrom wishes to continue it MUST call supportsInterface(0x4e2312e0) on _to and if it returns the constant value true the transaction MUST be reverted, as it is now known to be a valid receiver and the previous acceptance step failed.\n\n NOTE: You could have called supportsInterface(0x4e2312e0) at a previous step if you wanted to gather and act upon that information earlier, such as in a hybrid standards scenario.\n\n If the above call to supportsInterface(0x4e2312e0) on _to reverts or returns a value other than the constant value true the myTransferFrom function MAY consider this transfer successful.\n\n NOTE: this MAY result in unrecoverable tokens if sent to an address that does not expect to receive ERC-1155 tokens.\n\n The above example is not exhaustive but illustrates the major points (and shows that most are shared with safeTransferFrom and safeBatchTransferFrom):\n\n Balances that are updated MUST have equivalent transfer events emitted.\n A receiver address has to be checked if it is a contract and if so relevant ERC1155TokenReceiver hook function(s) have to be called on it.\n Balances (and events associated) that are referenced in a call to an ERC1155TokenReceiver hook MUST be updated (and emitted) before the ERC1155TokenReceiver hook is called.\n The return values of the ERC1155TokenReceiver hook functions that are called MUST be respected if they are implemented.\n Only non-standard transfer functions MAY allow tokens to be sent to a recipient contract that does NOT implement the necessary ERC1155TokenReceiver hook functions. safeTransferFrom and safeBatchTransferFrom MUST revert in that case (unless it is a hybrid standards implementation see “Backwards Compatibility”).\n\nMinting/creating and burning/destroying rules:\n\n A mint/create operation is essentially a specialized transfer and MUST follow these rules:\n\n To broadcast the existence of a token ID with no initial balance, the contract SHOULD emit the TransferSingle event from 0x0 to 0x0, with the token creator as _operator, and a _value of 0.\n The “TransferSingle and TransferBatch event rules” MUST be followed as appropriate for the mint(s) (i.e. singles or batches) however the _from argument MUST be set to 0x0 (i.e. zero address) to flag the transfer as a mint to contract observers.\n\n NOTE: This includes tokens that are given an initial balance in the contract. The balance of the contract MUST also be able to be determined by events alone meaning initial contract balances (for eg. in construction) MUST emit events to reflect those balances too.\n\n A burn/destroy operation is essentially a specialized transfer and MUST follow these rules:\n\n The “TransferSingle and TransferBatch event rules” MUST be followed as appropriate for the burn(s) (i.e. singles or batches) however the _to argument MUST be set to 0x0 (i.e. zero address) to flag the transfer as a burn to contract observers.\n When burning/destroying you do not have to actually transfer to 0x0 (that is impl specific), only the _to argument in the event MUST be set to 0x0 as above.\n\n The total value transferred from address 0x0 minus the total value transferred to 0x0 observed via the TransferSingle and TransferBatch events MAY be used by clients and exchanges to determine the “circulating supply” for a given token ID.\n As mentioned above mint/create and burn/destroy operations are specialized transfers and so will likely be accomplished with custom transfer functions rather than safeTransferFrom or safeBatchTransferFrom. If so the “Implementation specific transfer API rules” section would be appropriate.\n\n Even in a non-safe API and/or hybrid standards case the above event rules MUST still be adhered to when minting/creating or burning/destroying.\n\n A contract MAY skip calling the ERC1155TokenReceiver hook function(s) if the mint operation is transferring the token(s) to itself. In all other cases the ERC1155TokenReceiver rules MUST be followed as appropriate for the implementation (i.e. safe, custom and/or hybrid).\n\n A solidity example of the keccak256 generated constants for the various magic values (these MAY be used by implementation):\n\nbytes4 constant public ERC1155_ERC165 = 0xd9b67a26; // ERC-165 identifier for the main token standard.\nbytes4 constant public ERC1155_ERC165_TOKENRECEIVER = 0x4e2312e0; // ERC-165 identifier for the `ERC1155TokenReceiver` support (i.e. `bytes4(keccak256(\"onERC1155Received(address,address,uint256,uint256,bytes)\")) ^ bytes4(keccak256(\"onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)\"))`).\nbytes4 constant public ERC1155_ACCEPTED = 0xf23a6e61; // Return value from `onERC1155Received` call if a contract accepts receipt (i.e `bytes4(keccak256(\"onERC1155Received(address,address,uint256,uint256,bytes)\"))`).\nbytes4 constant public ERC1155_BATCH_ACCEPTED = 0xbc197c81; // Return value from `onERC1155BatchReceived` call if a contract accepts receipt (i.e `bytes4(keccak256(\"onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)\"))`).\n\n Metadata\n\nThe URI value allows for ID substitution by clients. If the string {id} exists in any URI, clients MUST replace this with the actual token ID in hexadecimal form. This allows for a large number of tokens to use the same on-chain string by defining a URI once, for that large number of tokens.\n\n The string format of the substituted hexadecimal ID MUST be lowercase alphanumeric: [0-9a-f] with no 0x prefix.\n The string format of the substituted hexadecimal ID MUST be leading zero padded to 64 hex characters length if necessary.\n\nExample of such a URI: https://token-cdn-domain/{id}.json would be replaced with https://token-cdn-domain/000000000000000000000000000000000000000000000000000000000004cce0.json if the client is referring to token ID 314592/0x4CCE0.\n\n Metadata Extensions\n\nThe optional ERC1155Metadata_URI extension can be identified with the ERC-165 Standard Interface Detection.\n\nIf the optional ERC1155Metadata_URI extension is included:\n\n The ERC-165 supportsInterface function MUST return the constant value true if 0x0e89341c is passed through the interfaceID argument.\n Changes to the URI MUST emit the URI event if the change can be expressed with an event (i.e. it isn’t dynamic/programmatic).\n\n An implementation MAY emit the URI event during a mint operation but it is NOT mandatory. An observer MAY fetch the metadata uri at mint time from the uri function if it was not emitted.\n\n The uri function SHOULD be used to retrieve values if no event was emitted.\n The uri function MUST return the same value as the latest event for an _id if it was emitted.\n The uri function MUST NOT be used to check for the existence of a token as it is possible for an implementation to return a valid string even if the token does not exist.\n\npragma solidity ^0.5.9;\n\n/**\n Note: The ERC-165 identifier for this interface is 0x0e89341c.\n*/\ninterface ERC1155Metadata_URI {\n /**\n @notice A distinct Uniform Resource Identifier (URI) for a given token.\n @dev URIs are defined in RFC 3986.\n The URI MUST point to a JSON file that conforms to the \"ERC-1155 Metadata URI JSON Schema\". \n @return URI string\n */\n function uri(uint256 _id) external view returns (string memory);\n}\n\n ERC-1155 Metadata URI JSON Schema\n\nThis JSON schema is loosely based on the “ERC721 Metadata JSON Schema”, but includes optional formatting to allow for ID substitution by clients. If the string {id} exists in any JSON value, it MUST be replaced with the actual token ID, by all client software that follows this standard.\n\n The string format of the substituted hexadecimal ID MUST be lowercase alphanumeric: [0-9a-f] with no 0x prefix.\n The string format of the substituted hexadecimal ID MUST be leading zero padded to 64 hex characters length if necessary.\n\n{\n \"title\": \"Token Metadata\",\n \"type\": \"object\",\n \"properties\": {\n \"name\": {\n \"type\": \"string\",\n \"description\": \"Identifies the asset to which this token represents\"\n },\n \"decimals\": {\n \"type\": \"integer\",\n \"description\": \"The number of decimal places that the token amount should display - e.g. 18, means to divide the token amount by 1000000000000000000 to get its user representation.\"\n },\n \"description\": {\n \"type\": \"string\",\n \"description\": \"Describes the asset to which this token 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 token 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 \"properties\": {\n \"type\": \"object\",\n \"description\": \"Arbitrary properties. Values may be strings, numbers, object or arrays.\"\n }\n }\n}\n\nAn example of an ERC-1155 Metadata JSON file follows. The properties array proposes some SUGGESTED formatting for token-specific display properties and metadata.\n\n{\n \"name\": \"Asset Name\",\n \"description\": \"Lorem ipsum...\",\n \"image\": \"https:\\/\\/s3.amazonaws.com\\/your-bucket\\/images\\/{id}.png\",\n \"properties\": {\n \"simple_property\": \"example value\",\n \"rich_property\": {\n \"name\": \"Name\",\n \"value\": \"123\",\n \"display_value\": \"123 Example Value\",\n \"class\": \"emphasis\",\n \"css\": {\n \"color\": \"#ffffff\",\n \"font-weight\": \"bold\",\n \"text-decoration\": \"underline\"\n }\n },\n \"array_property\": {\n \"name\": \"Name\",\n \"value\": [1,2,3,4],\n \"class\": \"emphasis\"\n }\n }\n}\n\n Localization\n\nMetadata localization should be standardized to increase presentation uniformity across all languages. As such, a simple overlay method is proposed to enable localization. If the metadata JSON file contains a localization attribute, its content MAY be used to provide localized values for fields that need it. The localization attribute should be a sub-object with three attributes: uri, default and locales. If the string {locale} exists in any URI, it MUST be replaced with the chosen locale by all client software.\n\n JSON Schema\n\n{\n \"title\": \"Token Metadata\",\n \"type\": \"object\",\n \"properties\": {\n \"name\": {\n \"type\": \"string\",\n \"description\": \"Identifies the asset to which this token represents\",\n },\n \"decimals\": {\n \"type\": \"integer\",\n \"description\": \"The number of decimal places that the token amount should display - e.g. 18, means to divide the token amount by 1000000000000000000 to get its user representation.\"\n },\n \"description\": {\n \"type\": \"string\",\n \"description\": \"Describes the asset to which this token 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 token 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 \"properties\": {\n \"type\": \"object\",\n \"description\": \"Arbitrary properties. Values may be strings, numbers, object or arrays.\",\n },\n \"localization\": {\n \"type\": \"object\",\n \"required\": [\"uri\", \"default\", \"locales\"],\n \"properties\": {\n \"uri\": {\n \"type\": \"string\",\n \"description\": \"The URI pattern to fetch localized data from. This URI should contain the substring `{locale}` which will be replaced with the appropriate locale value before sending the request.\"\n },\n \"default\": {\n \"type\": \"string\",\n \"description\": \"The locale of the default data within the base JSON\"\n },\n \"locales\": {\n \"type\": \"array\",\n \"description\": \"The list of locales for which data is available. These locales should conform to those defined in the Unicode Common Locale Data Repository (http://cldr.unicode.org/).\"\n }\n }\n }\n }\n}\n\n Localized Sample\n\nBase URI:\n{\n \"name\": \"Advertising Space\",\n \"description\": \"Each token represents a unique Ad space in the city.\",\n \"localization\": {\n \"uri\": \"ipfs://QmWS1VAdMD353A6SDk9wNyvkT14kyCiZrNDYAad4w1tKqT/{locale}.json\",\n \"default\": \"en\",\n \"locales\": [\"en\", \"es\", \"fr\"]\n }\n}\n\nes.json:\n{\n \"name\": \"Espacio Publicitario\",\n \"description\": \"Cada token representa un espacio publicitario único en la ciudad.\"\n}\n\nfr.json:\n{\n \"name\": \"Espace Publicitaire\",\n \"description\": \"Chaque jeton représente un espace publicitaire unique dans la ville.\"\n}\n\n Approval\n\nThe function setApprovalForAll allows an operator to manage one’s entire set of tokens on behalf of the approver. To permit approval of a subset of token IDs, an interface such as ERC-1761 Scoped Approval Interface is suggested.\nThe counterpart isApprovedForAll provides introspection into any status set by setApprovalForAll.\n\nAn owner SHOULD be assumed to always be able to operate on their own tokens regardless of approval status, so should SHOULD NOT have to call setApprovalForAll to approve themselves as an operator before they can operate on them.\n\n Rationale\n\n Metadata Choices\n\nThe symbol function (found in the ERC-20 and ERC-721 standards) was not included as we do not believe this is a globally useful piece of data to identify a generic virtual item / asset and are also prone to collisions. Short-hand symbols are used in tickers and currency trading, but they aren’t as useful outside of that space.\n\nThe name function (for human-readable asset names, on-chain) was removed from the standard to allow the Metadata JSON to be the definitive asset name and reduce duplication of data. This also allows localization for names, which would otherwise be prohibitively expensive if each language string was stored on-chain, not to mention bloating the standard interface. While this decision may add a small burden on implementers to host a JSON file containing metadata, we believe any serious implementation of ERC-1155 will already utilize JSON Metadata.\n\n Upgrades\n\nThe requirement to emit TransferSingle or TransferBatch on balance change implies that a valid implementation of ERC-1155 redeploying to a new contract address MUST emit events from the new contract address to replicate the deprecated contract final state. It is valid to only emit a minimal number of events to reflect only the final balance and omit all the transactions that led to that state. The event emit requirement is to ensure that the current state of the contract can always be traced only through events. To alleviate the need to emit events when changing contract address, consider using the proxy pattern, such as described in EIP-2535. This will also have the added benefit of providing a stable contract address for users.\n\n Design decision: Supporting non-batch\n\nThe standard supports safeTransferFrom and onERC1155Received functions because they are significantly cheaper for single token-type transfers, which is arguably a common use case.\n\n Design decision: Safe transfers only\n\nThe standard only supports safe-style transfers, making it possible for receiver contracts to depend on onERC1155Received or onERC1155BatchReceived function to be always called at the end of a transfer.\n\n Guaranteed log trace\n\nAs the Ethereum ecosystem continues to grow, many dapps are relying on traditional databases and explorer API services to retrieve and categorize data. The ERC-1155 standard guarantees that event logs emitted by the smart contract will provide enough data to create an accurate record of all current token balances. A database or explorer may listen to events and be able to provide indexed and categorized searches of every ERC-1155 token in the contract.\n\n Approval\n\nThe function setApprovalForAll allows an operator to manage one’s entire set of tokens on behalf of the approver. It enables frictionless interaction with exchange and trade contracts.\n\nRestricting approval to a certain set of token IDs, quantities or other rules MAY be done with an additional interface or an external contract. The rationale is to keep the ERC-1155 standard as generic as possible for all use-cases without imposing a specific approval scheme on implementations that may not need it. Standard token approval interfaces can be used, such as the suggested ERC-1761 Scoped Approval Interface which is compatible with ERC-1155.\n\n Backwards Compatibility\n\nThere have been requirements during the design discussions to have this standard be compatible with existing standards when sending to contract addresses, specifically ERC-721 at time of writing.\nTo cater for this scenario, there is some leeway with the revert logic should a contract not implement the ERC1155TokenReceiver as per “Safe Transfer Rules” section above, specifically “Scenario#3 : The receiver does not implement the necessary ERC1155TokenReceiver interface function(s)”.\n\nHence in a hybrid ERC-1155 contract implementation an extra call MUST be made on the recipient contract and checked before any hook calls to onERC1155Received or onERC1155BatchReceived are made.\nOrder of operation MUST therefore be:\n\n The implementation MUST call the function supportsInterface(0x4e2312e0) on the recipient contract, providing at least 10,000 gas.\n If the function call succeeds and the return value is the constant value true the implementation proceeds as a regular ERC-1155 implementation, with the call(s) to the onERC1155Received or onERC1155BatchReceived hooks and rules associated.\n If the function call fails or the return value is NOT the constant value true the implementation can assume the recipient contract is not an ERC1155TokenReceiver and follow its other standard’s rules for transfers.\n\nNote that a pure implementation of a single standard is recommended rather than a hybrid solution, but an example of a hybrid ERC-1155/ERC-721 contract is linked in the references section under implementations.\n\nAn important consideration is that even if the tokens are sent with another standard’s rules the ERC-1155 transfer events MUST still be emitted. This is so the balances can still be determined via events alone as per ERC-1155 standard rules.\n\n Usage\n\nThis standard can be used to represent multiple token types for an entire domain. Both fungible and non-fungible tokens can be stored in the same smart-contract.\n\n Batch Transfers\n\nThe safeBatchTransferFrom function allows for batch transfers of multiple token IDs and values. The design of ERC-1155 makes batch transfers possible without the need for a wrapper contract, as with existing token standards. This reduces gas costs when more than one token type is included in a batch transfer, as compared to single transfers with multiple transactions.\n\nAnother advantage of standardized batch transfers is the ability for a smart contract to respond to the batch transfer in a single operation using onERC1155BatchReceived.\n\nIt is RECOMMENDED that clients and wallets sort the token IDs and associated values (in ascending order) when posting a batch transfer, as some ERC-1155 implementations offer significant gas cost savings when IDs are sorted. See Horizon Games - Multi-Token Standard “packed balance” implementation for an example of this.\n\n Batch Balance\n\nThe balanceOfBatch function allows clients to retrieve balances of multiple owners and token IDs with a single call.\n\n Enumerating from events\n\nIn order to keep storage requirements light for contracts implementing ERC-1155, enumeration (discovering the IDs and values of tokens) must be done using event logs. It is RECOMMENDED that clients such as exchanges and blockchain explorers maintain a local database containing the token ID, Supply, and URI at the minimum. This can be built from each TransferSingle, TransferBatch, and URI event, starting from the block the smart contract was deployed until the latest block.\n\nERC-1155 contracts must therefore carefully emit TransferSingle or TransferBatch events in any instance where tokens are created, minted, transferred or destroyed.\n\n Non-Fungible Tokens\n\nThe following strategies are examples of how you MAY mix fungible and non-fungible tokens together in the same contract. The standard does NOT mandate how an implementation must do this.\n\n Split ID bits\n\nThe top 128 bits of the uint256 _id parameter in any ERC-1155 function MAY represent the base token ID, while the bottom 128 bits MAY represent the index of the non-fungible to make it unique.\n\nNon-fungible tokens can be interacted with using an index based accessor into the contract/token data set. Therefore to access a particular token set within a mixed data contract and a particular non-fungible within that set, _id could be passed as <uint128: base token id><uint128: index of non-fungible>.\n\nTo identify a non-fungible set/category as a whole (or a fungible) you COULD just pass in the base id via the _id argument as <uint128: base token id><uint128: zero>. If your implementation uses this technique this naturally means the index of a non-fungible SHOULD be 1-based.\n\nInside the contract code the two pieces of data needed to access the individual non-fungible can be extracted with uint128(~0) and the same mask shifted by 128.\n\nuint256 baseTokenNFT = 12345 << 128;\nuint128 indexNFT = 50;\n\nuint256 baseTokenFT = 54321 << 128;\n\nbalanceOf(msg.sender, baseTokenNFT); // Get balance of the base token for non-fungible set 12345 (this MAY be used to get balance of the user for all of this token set if the implementation wishes as a convenience).\nbalanceOf(msg.sender, baseTokenNFT + indexNFT); // Get balance of the token at index 50 for non-fungible set 12345 (should be 1 if user owns the individual non-fungible token or 0 if they do not).\nbalanceOf(msg.sender, baseTokenFT); // Get balance of the fungible base token 54321.\n\nNote that 128 is an arbitrary number, an implementation MAY choose how they would like this split to occur as suitable for their use case. An observer of the contract would simply see events showing balance transfers and mints happening and MAY track the balances using that information alone.\nFor an observer to be able to determine type (non-fungible or fungible) from an ID alone they would have to know the split ID bits format on a implementation by implementation basis.\n\nThe ERC-1155 Reference Implementation is an example of the split ID bits strategy.\n\n Natural Non-Fungible tokens\n\nAnother simple way to represent non-fungibles is to allow a maximum value of 1 for each non-fungible token. This would naturally mirror the real world, where unique items have a quantity of 1 and fungible items have a quantity greater than 1.\n\n References\n\nStandards\n\n ERC-721 Non-Fungible Token Standard\n ERC-165 Standard Interface Detection\n ERC-1538 Transparent Contract Standard\n JSON Schema\n RFC 2119 Key words for use in RFCs to Indicate Requirement Levels\n\nImplementations\n\n ERC-1155 Reference Implementation\n Horizon Games - Multi-Token Standard\n Enjin Coin (GitHub)\n The Sandbox - Dual ERC-1155/721 Contract\n\nArticles & Discussions\n\n GitHub - Original Discussion Thread\n ERC-1155 - The Crypto Item Standard\n Here Be Dragons - Going Beyond ERC-20 and ERC-721 To Reduce Gas Cost by ~80%\n Blockonomi - Ethereum ERC-1155 Token Perfect for Online Games, Possibly More\n Beyond Gaming - Exploring the Utility of ERC-1155 Token Standard!\n ERC-1155: A new standard for The Sandbox\n\n Copyright\n\nCopyright and related rights waived via CC0.\n\n Citation\n Please cite this document as:\n\n Witek Radomski <witek@enjin.io>, Andrew Cooke <ac0dem0nk3y@gmail.com>, Philippe Castonguay (@phabc) <pc@horizongames.net>, James Therien <james@turing-complete.com>, Eric Binet <eric@enjin.io>, Ronan Sandford (@wighawag) <wighawag@gmail.com>, \"ERC-1155: Multi Token Standard,\" Ethereum Improvement Proposals, no. 1155, June 2018. Available: https://eips.ethereum.org/EIPS/eip-1155.","tokens":13112,"squid":"spider-05","role":"Spec Spider","at":1791341926435,"hash":"dfa5b76664302a8438e3793039850f65ad65b7e7"}
{"url":"https://alt.gov.arbitrum.foundation/","domain":"alt.gov.arbitrum.foundation","title":"ArbitrumDAO Governance | Arbitrum Governance","text":"Proposals771Delegates with ≥5000 ARB voting power90ProposalsSee the treasury on ArbDataTreasuryNew ProposalQuorumYour Vote[CONSTITUTIONAL] AIP: Authorize Priority Gas Auctions and Establish the Fast FeedID: 104933...979282Core-100%–[Constitutional] AIP: Security Council Election Process ImprovementsID: 995053...017943Core-100%–Constitutional AIP: ArbOS61 Elara UpgradeID: 719101...374426CoreExecuted-100%–Continued Funding for the Arbitrum FoundationID: 218611...674989TreasuryExecuted-100%–[Constitutional] AIP: Amended Release of Frozen ETH Pursuant to Court OrderID: 712363...719183CoreExecuted-100%–Transfer 6,000 ETH and Idle Stablecoins from the Treasury to the Treasury Management PortfolioID: 866545...962180TreasuryExecuted-100%–[Constitutional] DVP Quorum & Proposal CancellationID: 112177...897430CoreExecuted-100%–[Constitutional] AIP: Activate ArbOS 51 (Dia) and Gas Pricing UpdatesID: 531543...908001CoreExecuted-100%–Transfer 8,500 ETH from the Treasury to ATMC’s ETH Treasury StrategiesID: 574959...992963TreasuryExecuted-100%–[CONSTITUTIONAL] Remove Cost Cap, Update Executors, Disable Legacy USDT BridgeID: 518520...284115CoreExecuted-100%–Showing 1 to 10 of 90 results…Rows90 proposals from indexer · checking RPC for new proposals...","tokens":314,"squid":"spider-07","role":"Council Spider","at":1791341941745,"hash":"ca41fca6319592f7ca7575163bfa67c51e745c09"}
{"url":"https://docs.switchboard.xyz/how-it-works/switchboard-protocol/running-your-own-queue/creating-an-oracle-queue","domain":"docs.switchboard.xyz","title":"Creating an Oracle Queue | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.1. Create the Queuesb solana on-demand queue init \\\n --mainnetBeta \\\n -k ~/.config/solana/queue-authority.json \\\n --reward 100000 \\\n --nodeTimeout 180The command prints your new Queue's public key. Save it — every oracle you onboard, and every feed you point at this Queue, needs it.The signer becomes the queue authority. That key controls oracle permissions and the enclave allowlist, so treat it accordingly.ParameterValueMeaning--rewardlamportsPaid per oracle per update--nodeTimeoutsecondsSilence after which an oracle may be garbage-collectedrequireAuthorityHeartbeatPermissiontrueOracles need explicit permission from you before they can joinrequireUsagePermissionfalseAnyone may read feeds on this QueuemaxQuoteVerificationAge7 daysHow long a guardian attestation stays validallowAuthorityOverrideAfter600sDelay before the authority can be force-rotatedQueue creation also allocates an address lookup table, so the command reads a recent finalized slot and takes a moment.Mutable parameters can be changed later:sb solana on-demand queue configure <QUEUE> --mainnetBeta -k <AUTHORITY> \\\n --reward 120000 \\\n --nodeTimeout 300 \\\n --oracleFeeProportionBps 50002. Create an oracle accountOn the machine you provisioned (see Running a Switchboard Oracle):sb solana on-demand oracle create \\\n --mainnetBeta \\\n -k ~/.config/solana/oracle-payer.json \\\n --queue <QUEUE>This prints the oracle's public key and the queue it belongs to. The signer becomes the oracle's authority, and must be the same key the oracle node runs with as its payer — attestation transactions are signed by that authority.3. Permission the oracle onto your QueueBecause the Queue was created with requireAuthorityHeartbeatPermission, an oracle cannot join until you grant it heartbeat permission:sb solana on-demand permission set \\\n --mainnetBeta -k ~/.config/solana/queue-authority.json \\\n --granter <QUEUE> \\\n --grantee <ORACLE>Run this with the queue authority; the command refuses any other signer.To remove an oracle, add --disable. That revokes the permission and, if the oracle is currently seated, removes it from the Queue in the same transaction.4. Control which software your oracles runThis is the security boundary a Queue exists to provide. Each oracle proves what code it is running through its TEE attestation, which produces an enclave measurement. Your Queue holds an allowlist of accepted measurements, and an oracle whose measurement is not on it cannot heartbeat.Read the measurement from the oracle's own boot log — it prints ENCLAVE MEASUREMENT: <hex> on startup — then:sb solana on-demand queue addMrEnclave <QUEUE> --mainnetBeta -k <AUTHORITY> \\\n --mrEnclave <HEX>Remove a retired measurement with rmMrEnclave:sb solana on-demand queue rmMrEnclave <QUEUE> --mainnetBeta -k <AUTHORITY> \\\n --mrEnclave <HEX>An empty allowlist is trust-on-first-use. While your Queue has no measurements registered, the first oracle to heartbeat writes its own measurement into the list, and the Queue is pinned to it from then on. If you care which image your Queue accepts, add the measurement deliberately before the first oracle heartbeats.5. Verifysb solana on-demand queue print <QUEUE> --mainnetBetaYou are looking for:your oracle appearing in oracleKeys,a non-empty gatewayUri on it — an oracle whose gateway is not publicly reachable never publishes one, and stays invisible to the network,a recent lastHeartbeat.Keep the Queue's escrow funded. It pays the per-update reward to oracles.Upgrading oracle softwareEvery image build has a different measurement, so ordering matters:Add the new measurement with addMrEnclave.Roll your oracles onto the new image; each re-attests under the new measurement.Once every oracle has rotated, remove the retired measurement.Doing step 3 before step 2 knocks your fleet off the Queue.Operational commandsSituationCommandStale oracle stuck on the Queuesb solana on-demand queue rmOracleLookup table needs rebuildingsb solana on-demand queue resetLutRotate the queue authorityqueue configure <QUEUE> --authority <NEW>If you are wiring the Queue into restaking, queue setNcn, queue setVault and queue allowSubsidy are the relevant commands — see (Re)staking.TroubleshootingSymptomCauseHeartbeat fails with a permission errorHeartbeat permission not granted, or granted by the wrong signerHeartbeat fails on the measurement checkThe oracle's measurement is not on the Queue allowlistOracle seated but has no gatewayUriIts gateway is not reachable from the public internetOracle never becomes verifiedAttestation is failing — check the oracle's TEE setupPreviousRunning your own QueueNextRunning a Guardian QueueLast updated 1 month ago","tokens":1187,"squid":"spider-08","role":"Oracle Spider","at":1791341943156,"hash":"fd931f19e814441886ff5bb0f9ae19a1b593be4c"}
{"url":"https://phantom.com/tokens/solana/JUPyiwrYJFskUPiHa7hkeR8VUtAeFoSYbKedZNsDvCN","domain":"phantom.com","title":"Jupiter (JUP) Price Chart - Buy and Sell on Phantom","text":"Jupiter$0.33-$0.0177-5.08%• TodayInfoNameJupiterSymbolJUPNetworkSolanaMarket Cap$1.1BTotal Supply6.86BCirculating Supply3.32BHolders829.89KVolume (24h)$14M+25.36%Trades (24h)152.64K+13.48%Traders (24h)11,923+2.86%All-Time High$1.59All-Time Low$0.15Liquidity$11MTop 10 Holders66.19%AboutJUP is the governance token of Jupiter, Solana’s largest and most widely used exchange aggregator. JUP was launched through one of the biggest airdrops in Solana history, distributing tokens to millions of eligible wallets. The airdrop wasn’t just generous—it was strategic, designed to reward early Jupiter users and build a strong, engaged community from day one. Follow-up JUP airdrops are still ongoing, and each one brings fresh waves of interest and new holders into the fold. This airdrop-driven momentum has created a kind of magnetic pull around JUP, with traders and DeFi users watching closely for what comes next. Looking ahead, JUP’s future looks bright. The Jupiter DAO is steadily expanding its role, with community members proposing improvements, voting on upgrades, and shaping the roadmap. If Solana continues to grow as a home for fast, low-cost trading, and Jupiter DAO delivers on its vision, JUP is well-positioned to remain a core asset in the ecosystem.DiscordTelegramXFAQThe market capitalization of JUP is $1.1B as of Oct 6, 2026.Market capitalization is calculated by multiplying the current price of JUP by its circulating supply. It reflects the overall value of the token in the market and helps gauge its relative size compared to other cryptocurrencies.The daily trading volume of JUP is $14M as of Oct 6, 2026.Trading volume can fluctuate based on market conditions, investor activity, and overall demand for JUP.The total supply of JUP is 6.86B.The circulating supply, which represents the number of JUP currently available in the market, is 3.32B as of Oct 6, 2026.JUP can be bought and traded on a variety of cryptocurrency platforms, including Phantom!Pricing information is provided for informational purposes only and is not financial advice. Market data is provided by third parties and Phantom makes no representation as to the accuracy of the information.Buy Jupiter with the Mobile AppTrade from your desktop browserTrade JupiterTrending Tokensauton$0.00520397AUTON+107,964.04%Orca$3.01ORCA+27.62%Jupiter$0.33JUP-5.07%4Paid$0.00633265PAID+64.43%5test griffain.com$0.024GRIFFAIN+24.66%6DarkSwap$0.00220189DARK+50.99%7Collector Crypt$0.28CARDS+0.17%8Raydium$2.16RAY+0.5%9Tweetcraft$0.00085858TWEETCRAFT+8,527.44%10Anonymous Cat$0.0582ZCAT-4.47%Pricing information is provided for informational purposes only and is not financial advice. Market data is provided by third parties and Phantom makes no representation as to the accuracy of the information.Buy JUP","tokens":697,"squid":"spider-10","role":"Tooling Spider","at":1791341945038,"hash":"526ee6bb679c673cf292a436e1b89fcc2c2a11cd"}
{"url":"https://alt.gov.arbitrum.foundation/proposal/21861170607500194610699142421898826942478361357343425061227227766726035674989?govId=eip155:42161:0x789fc99093b09ad01c34dc7251d0c89ce743e5a4","domain":"alt.gov.arbitrum.foundation","title":"Proposal | Arbitrum Governance | Arbitrum Governance","text":"Back to ProposalsTreasury2186117060...35674989Continued Funding for the Arbitrum FoundationNon-Constitutional QuorumTreasury GovernorVoting PeriodJun 11, 12:08 PMJun 25, 01:24 PMFor206.39M86.0%Against8.67M3.6%Abstain24.97M10.4%231.36M / 152.76M ARBQuorumProposalExecutedDescriptionContinued Funding for the Arbitrum Foundation\nAbstract\nThis proposal seeks funding of $16M in USD (RWAs), 1.7k ETH and 230mn ARB to support the Arbitrum Foundation’s continued operations for an additional year beyond its initial allocation under AIP 1.1.\nThe Foundation serves as a growth engine and cost center of the Arbitrum ecosystem on behalf of the DAO. It coordinates development of the technology stack, executes strategic partnerships in coordination with other Arbitrum Aligned Entities (“AAEs”), supports and funds ecosystem expansion and facilitates DAO initiatives. Importantly, it also covers all costs associated with Arbitrum One and Arbitrum Nova, with technical costs expected to represent 54% of all anticipated expenses for 2027.\nAll activities undertaken by the Foundation are focused on working with other AAEs to grow the ecosystem and identify new revenue sources, with the ultimate goal of increasing revenue flowing to the DAO. As all revenue accrues directly to the DAO treasury, the Foundation must periodically return to the DAO and request funding in order to continue our activities.\nThe medium to long term goal of the Arbitrum Foundation, alongside all other AAEs, is to continue expanding the DAO’s revenue across multiple sources including Arbitrum One and AEP fees, Timeboost, the ATMC endowment, and new business lines that are expected to emerge over the coming months and years. We believe a sustainable future can be achieved via the DAO governance model and will continue focusing our efforts on ensuring its success.\nMotivation & Rationale\nThe Foundation acts as a capital allocator, ecosystem facilitator, and the ArbitrumDAO’s legal wrapper and backstop for DAO proposals.\nWe identify emerging opportunities and work with other AAEs to bring high-impact initiatives into the Arbitrum ecosystem. As an intentionally structured cost center, the Foundation absorbs the cost of growth and development while enabling the DAO to capture the upside through increased usage, stronger network effects and sustainable revenue generation.\nAmong the AAEs, the Foundation plays a central role across four key areas:\nStrategic Grants and Partnerships. The Foundation supports both emerging crypto-native teams and established institutional partners.\nOur ecosystem team is focused on onboarding teams across various verticals, including institutional tokenization, DeFi, Consumer, Payments, AI, and emerging trends. This forms the application layer of Arbitrum and further attracts builders to build on Arbitrum. The Arbitrum ecosystem is one of the most dynamic in the blockchain industry and attracts the interest of developers, retail users and now institutions. In many cases, this is thanks to the relationships and partnerships we have structured to bring users, capital, and strategic collaboration across the ecosystem.\nThe Foundation has continuously improved its capital allocation over time, and supports ecosystem growth through programs including our grants program, Trailblazer, Audit Subsidy Program, Arbifuel and DRIP. We have reviewed over 3,200 applications with an acceptance rate below 20% for these programs. Key Arbitrum teams that the Foundation directly supported in their early stages are Pendle, Ostium, USDAI, Instadapp, Cow Swap and El Dorado. Key Web3 communities were won over competition, like ApeChain. Institutional partnerships secured through the Foundation include Robinhood, BlackRock, Franklin Templeton, WisdomTree, Circle, Securitize and Paxos.\nTechnical Advancement and Infrastructure Maintenance. The technical and ecosystem team work hand-in-hand to sponsor core protocol upgrades alongside onboarding new partnerships that enhance the developer experience.\nSponsoring core protocol upgrades is essential for the continued improvement of the Arbitrum technology stack in terms of security, features, developer and end-user experience. Major sponsored upgrades include new execution environments such as Stylus, new revenue streams such as Timeboost and the Arbitrum Expansion Program, reducing fees for all users with Dynamic Gas Pricing, and continuous ArbOS upgrades with general improvements and security enhancements. The majority of research, development, and technical implementation of this work came from our partnership with Offchain Labs. As we mention elsewhere, Offchain Labs will approach the DAO separately to continue funding protocol research work.\nSince the Arbitrum technology stack has an ecosystem licence (BSL) and is increasingly adopted as the chain of choice by other projects, we have sought to onboard new partners who can enhance the developer experience. Partnerships include OpenZeppelin to develop a Stylus SDK and audit early Stylus teams, onboarding Nethermind for client diversity, and several top-tier audit firms with the Audit Program for emerging builders alongside many others.\nAdditionally, the Foundation funds core ecosystem tools and services, such as block explorers, RAAS providers, and transaction simulation and analytics tools which have extensive distribution across developers and users. As a result, Arbitrum offers best-in-class infrastructure support to the ecosystem and the Foundation maintains a strong relationship with infrastructure companies. This directly benefits the Arbitrum ecosystem, for instance, with the $10M grant program launched and funded by Alchemy.\nMarketing, Community, and Education. The Arbitrum Foundation is focused on vertical marketing through developer engagement, in-person initiatives, and coordinated media distribution.\nOur developer relations and ecosystem teams focus on supporting builders through technical education, tutorials, hackathons, and ecosystem showcases. Complementing this, in-person initiatives such as OpenHouse and ArbiLink bring together founders, developers, and institutional partners, facilitating collaboration and onboarding to the ecosystem.\nThis combined approach of online engagement alongside real-world activations helps to equip teams with the knowledge to build on Arbitrum while connecting them to high-value partners. Together, these efforts reinforce Arbitrum’s position as a highly attractive ecosystem for builders.\nFinally, to ensure Arbitrum is well positioned within broader industry narratives, alongside promoting teams building on Arbitrum, we actively engage with the media across both crypto-native and traditional financial outlets. Some outlets include Unchained, Decrypt, CoinDesk, The Block, Bankless, and Messari, as well as traditional financial media such as Fortune, Bloomberg, Financial Times, and CNBC.\nTokenholder Relations, Governance and DAO Wrapper. The Arbitrum Foundation has begun to actively engage with new prospective tokenholders alongside facilitating governance for existing tokenholders.\nOn the capital markets side, the investment strategy team has broadened engagement with investment firms, research houses, and asset managers to introduce the Arbitrum ecosystem and the role of the ARB token. This includes building relationships with selective capital market participants exploring the ecosystem's growth trajectory and supporting initiatives that extend Arbitrum's reach into institutional and/or investment communities. Additionally, we have facilitated several institutional roundtables and prospective token holder roadshows across key markets such as the US, EMEA and Asia.\nGovernance, specifically DAO relations, will begin to converge with institutional relationship building as we work to bring more long term token holders into the governance process.\nOn the governance front, the governance team has played both a strategic and operational role since the DAO’s inception. They have facilitated six Security Council election cycles, as well as the implementation of many DAO-approved initiatives including liquidity programs (e.g. ATMC, STEP I and II), third-party grant providers (e.g. Plurality Labs, Questbook), DAO-mandated research initiatives (e.g. ARDC), and recovery of misused funds (e.g. Watchdog, other independent actions), among many others. More recently, they have supported the establishment and enablement of several Arbitrum Aligned Entities including OpCo, Entropy Advisors, and AGV.\nImportantly, the Arbitrum Foundation serves as the legal wrapper for the DAO and has committed $10M to establish the Captive Insurance Product, designed to act as a backstop to safeguard participation within the DAO.\nUse of Funds and the Reinvestment Flywheel\nThe Foundation operates at the intersection of the ecosystem’s core participants among AAEs, builders, institutions, and governance, where we coordinate efforts to drive adoption and growth.\nAll activities are ultimately focused on improving key metrics across Arbitrum One and Arbitrum Chains which directly translates into revenue for the ArbitrumDAO.\nThe impact of this model is best illustrated by the ecosystem’s growth to date.\nIn March 2023 (at the Foundation’s launch):\n\n1.28M daily transactions,\n$1.9B in stablecoins,\n$6.15M revenue for that month, with $3.52M paid to Ethereum L1 data costs,\nNo meaningful real-world asset (RWA) presence.\n\nBy February 2026:\n\n4.7M+ daily transactions (up 270% from March 2023)\n$8.6B stablecoin supply (up 320% from March 2023)\n~$800M in RWAs, top 6th network by value and ranks #1 globally by total assets issued,\n$23.49M in gross profit generated in 2025 across transaction fees, Timeboost, and the Arbitrum Expansion Program, all accruing to the DAO treasury.\n\nGoing further, Arbitrum has developed one of the deepest liquidity layers across L2s, with peak TVL of ~$21B and over 2.3B total transactions processed, with the second billion completed in just 13 months. Most importantly, network fees paid by users have drastically decreased while maintaining a significant revenue stream for the DAO.\nThis growth reflects a reinforcing economic flywheel. More teams building on Arbitrum drives more onchain activity; increased activity generates DAO revenue through fees, Timeboost, the Arbitrum Expansion program, and native yields available on Arbitrum chains; that revenue is reinvested into grants, programs, technology improvements, and ultimately attracts the next wave of teams to build on Arbitrum.\nThis flywheel is already established and accelerating. This proposal funds the work that continues to compound it with the Foundation’s efforts focused on ecosystem growth, increasing DAO revenue, and ensuring our own continued future funding.\nWe recommend viewing the following dashboards that reflect the on-chain transaction data, total stablecoin supply, and total RWAs on Arbitrum.\nProjected Foundation Expenses (2027)\n\nUSDARBOperating Expenses$27.6MEcosystem Growth Expenses & Investments244.9MTotal Projected 2027 Expenses$27.6M244.9M\nTable 1: Total expected operating and ecosystem growth related expenses in fiat and ARB for 2027\nTable 1 presents our current best estimate of total 2027 expenses. The annualized expense is below the annual costs outlined in the Foundation’s 2025 transparency report. This reflects a combination of cost efficiencies undertaken by the Foundation, our treasury management efforts, and the absence of funding for Offchain Labs.\nThe Foundation’s current payments to Offchain Labs for technical services will run through January 2027, but after that OCL will no longer be paid by the Foundation. They may approach the DAO separately for funding in the future.\nIn relation to our expected ecosystem growth expenses & investments, the Foundation works with other AAEs to allocate this funding. We view this as an important part of creating a sustainable flywheel for the DAO. As mentioned previously, key Arbitrum teams that the Foundation directly supported in their early stages are Pendle, Ostium, USDAI, Instadapp, Cow Swap and El Dorado. The 2027 budget includes funding for both new and existing ecosystem growth commitments.\n\n2027 (Forecast)Variable Marketing Expenses$2.38MGeneral & Administrative (G&A)$10.40MTechnical$14.81MTotal Operating Expenses$27.6M\nTable 2: Anticipated expenses forecast for 2027 by the Arbitrum Foundation\nTable 2 provides an overview of the Foundation’s projected expenses as it relates to General & Administrative, Variable Marketing, and Technical costs.\nIt is important to note that the Arbitrum Foundation largely operates as a cost center for the DAO. While the chain revenue occurs to the DAO, the Foundation pays the operational expenses to keep Arbitrum One and Arbitrum Nova running.\nIn regards to the General and Administrative category, it primarily relates to personnel, contractors, external service providers, legal and insurance costs, and other operating expenses.\nThe Technical category alone accounts for approximately 54% of all expenses for the Arbitrum Foundation for next year. Let’s explore the technical expenses in more detail.\n\n2027 (Forecast)Security$4.63MInfrastructure & Tooling$4.38MHosting & Support$5.80MTotal Technical Expenses$14.81M\nTable 3: Breakdown of Technical Expenses\nIn Table 3, we present a breakdown of the Technical category which includes Security, Hosting & Support, and Infrastructure & Tooling. This covers a range of costs including block explorers, bug bounties, auditing spend, cloud service providers, external technical contributors, third party software tools and many other items that are required to keep the Arbitrum network running with high uptime.\nWe have worked with Offchain Labs to optimize technical costs and are targeting an 8% reduction in 2026 vs. 2025 despite higher expected transaction volume and network traffic. This reduction is accounted for in the request for funding.\nThe Foundation has reduced expected variable marketing expenses in 2026 and going forward versus prior years. This reduction reflects a change in the Arbitrum Foundation’s approach to marketing. The Foundation is now focused on vertical marketing across capital markets and developer relations, with the objective of attracting high-quality founders to build on Arbitrum and to attract capital to participate in the ecosystem. This change in approach was necessary to contain cost while focusing our marketing efforts on the highest impact areas.\nProposed Funding Ask\n\nAsset TypeQuantityRWA & Stablecoins$16METH1,740ARB230M\nTable 4: Requested funding for the Arbitrum Foundation\nTable 4 outlines the Foundation’s funding request of, where most funding will be used to cover technical costs of the network, G&A, and ecosystem growth for an additional year beyond its initial allocation under AIP 1.1.\nWe request funding in RWAs, ETH and ARB to better align the Foundation’s assets with its liabilities. Our operating expenses are largely USD-denominated while ecosystem growth expenses can be denominated in ARB. This approach would improve balance sheet flexibility and support future operational and strategic needs while reducing the need to sell tokens to fund operations.\nAdditionally, we are requesting 230mn ARB to increase our treasury of ARB. This will be used primarily for ecosystem growth initiatives, including onboarding new strategic partners, and other operating expenses.\nIt is worth highlighting that in Table 1, our total estimated operating expenses will be approximately $27.6M and 244.9mn ARB while the proposal is only requesting $16M in RWAs, 1,740 ETH, and 230mn ARB. Our RWA ask is ~$11.6M lower than our estimated operating expenses and our ARB ask is ~14.9mn lower. We are comfortable with this short-fall as we can accommodate the difference from our current balance sheet and from the ETH requested.\nWe request the RWA / Stablecoins, ETH, and ARB be released to the Foundation upon passage of the proposal, with the ATMC and OAT determining the appropriate DAO bucket for each allocation.\nThe proposed funding timeline reflects a deliberate approach to treasury management to ensure continuity of core functions and sustained support for the ecosystem while minimizing the near-term impact on the DAO’s treasury. The Arbitrum Foundation expects to come back to the DAO in 2027 to discuss future funding.\nThe Foundation has published Biannual and Annual Transparency Reports since inception, without interruption. This proposal commits to maintaining that cadence.\nTimeline\nWe encourage all delegates to provide feedback on the forum and to attend the following governance call:\n\nTuesday, 26th May 2026, at 2pm UTC\n\nThroughout the governance process, feedback will be collected and integrated with the proposal.\nWe aim to have a temperature check vote on 28th May 2026, which will run for one week. If the temperature check passes, then the on-chain vote will be initiated on 8th June 2026. Please note that these dates are subject to change based on feedback from delegates.Proposal Payload1ActionTo:0xF3FC178157fb3c87548bAA86F9d24BA38E649B58transfer()4byte[0]addressARB TokenArb1[1]address0xD6c8a4E72584f24bd5517AfeD6c01D21477C17f6Arb1[2]uint256230000000000000000000000000 (230000000.0 ETH)Raw calldata0xbeabacc8000000000000000000000000912ce59144191c1204e64559fe8253a0e49e6548000000000000000000000000d6c8a4e72584f24bd5517afed6c01d21477c17f6000000000000000000000000000000000000000000be4064fbcc1d7ea6000000","tokens":4372,"squid":"spider-07","role":"Council Spider","at":1791341952624,"hash":"90bf6e0cfb2413144ad1538b4589c5be4df2df17"}
{"url":"https://docs.switchboard.xyz/how-it-works/switchboard-protocol/enable-staking-to-your-oracle","domain":"docs.switchboard.xyz","title":"Enable Staking to your Oracle | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.Setting up your oracle to start earning SWTCH rewards is easy. In less than 5 minutes, Jito vaults can start delegating stake to your oracle to start earning!OverviewOracle operators in the Switchboard network must have svSWTCH delegated to them to participate. This \"skin in the game\" model ensures oracle incentives are aligned with network security and data reliability.Benefits of enabling staking:🏆 Earn SWTCH rewards from network fees and subsidies📈 Competitive advantage - more delegation = more work opportunities🔒 Network participation - required to validate and submit oracle data⚡ Performance rewards - high uptime and accuracy earn bonus rewardsFor complete details on the economic model, see Governance & Tokenomics.To start earning, you must first create your NCN operator or provide a pre-existing operator. This operator account is what manages the permissions to allow stake to be delegated to your oracle from a Jito vault.Prerequisites:To get started with re-staking, you must have already installed the Jito restaking CLI:curl -fsSL -o jito-restaking-0.0.4.tar.gz https://github.com/jito-foundation/restaking/archive/refs/tags/v0.0.4.tar.gz\ntar -xvzf jito-restaking-0.0.4.tar.gz\nrm jito-restaking-0.0.4.tar.gz\ncd restaking-0.0.4/cli/\ncargo build --release\nmkdir -p ~/.local/bin\ncp ../target/release/jito-restaking-cli ~/.local/bin/To create an NCN operator account, runjito-restaking-cli restaking operator initialize ${OPERATOR_FEE_BPS?} --rpc-url ${URL?} --keypair ${KP?}Note that the operator fee is not a setting that has any effect in the NCN protocol. This configuration acts as an indicator of what amount of rewards will go directly to your oracle instead of being sent to the vault. Do note that a higher fee de-incentivizes the vault to provide you stake.Once your operator is set up, you must link it to the Switchboard NCN:export NCN=BGTtt2wdTdhLyFQwSGbNriLZiCxXKBbm29bDvYZ4jD6G\njito-restaking-cli restaking ncn initialize-ncn-operator-state ${NCN?} ${OPERATOR?} --keypair ${KP?} --rpc-url ${URL?}\njito-restaking-cli restaking operator operator-warmup-ncn ${OPERATOR?} ${NCN?} --rpc-url ${URL?} --keypair ${KP?}At this point, your operator must be approved by Switchboard to continue, you may reach out via the application form or via the #sb-operatorsdiscord channel for Switchboard to runjito-restaking-cli restaking ncn ncn-warmup-operator ${NCN?} ${OPERATOR?} --rpc-url ${URL?} --keypair ${KP?}At this point your operator will be registered with the Switchboard NCN!Now, it's time to onboard to our supported VaultsSwitchboard currently supports stake delegation via the Fragmetric vaultThe Fragmetric vault may be found at address HR1ANmDHjaEhknvsTaK48M5xZtbBiwNdXM5NTiWhAb4STo onboard your operator to the Fragmetric vault, runjito-restaking-cli restaking operator inititalize-operator-vault-ticket ${OPERATOR?} ${VAULT?} --rpc-url ${URL?} --keypair ${KP?}\njito-restaking-cli restaking operator warmup-operator-vault-ticket ${OPERATOR?} ${VAULT?} --rpc-url ${URL?} --keypair ${KP?}And you are all set! Fragmetric may now delegates stake to your node at the vault's discretion.May the odds forever be in your favor...PreviousRunning a Guardian QueueNextProviding stake to SwitchboardLast updated 1 year ago","tokens":835,"squid":"spider-08","role":"Oracle Spider","at":1791341953214,"hash":"db6863fd278a45b382da278e70cdf30e2b54a59b"}
{"url":"https://alt.gov.arbitrum.foundation/proposals","domain":"alt.gov.arbitrum.foundation","title":"Arbitrum Governance | Arbitrum Governance","text":"New ProposalQuorumYour Vote[CONSTITUTIONAL] AIP: Authorize Priority Gas Auctions and Establish the Fast FeedID: 104933...979282CoreExecuted100%0%0%100%–[Constitutional] AIP: Security Council Election Process ImprovementsID: 995053...017943CoreExecuted94%0%6%100%–Constitutional AIP: ArbOS61 Elara UpgradeID: 719101...374426CoreExecuted96%0%4%100%–Continued Funding for the Arbitrum FoundationID: 218611...674989TreasuryExecuted86%4%10%100%–[Constitutional] AIP: Amended Release of Frozen ETH Pursuant to Court OrderID: 712363...719183CoreExecuted92%0%8%100%–Transfer 6,000 ETH and Idle Stablecoins from the Treasury to the Treasury Management PortfolioID: 866545...962180TreasuryExecuted100%0%0%100%–[Constitutional] DVP Quorum & Proposal CancellationID: 112177...897430CoreExecuted100%0%0%100%–[Constitutional] AIP: Activate ArbOS 51 (Dia) and Gas Pricing UpdatesID: 531543...908001CoreExecuted100%0%0%100%–Transfer 8,500 ETH from the Treasury to ATMC’s ETH Treasury StrategiesID: 574959...992963TreasuryExecuted99%1%0%100%–[CONSTITUTIONAL] Remove Cost Cap, Update Executors, Disable Legacy USDT BridgeID: 518520...284115CoreExecuted100%0%0%100%–Showing 1 to 10 of 90 results…Rows90 proposals from indexer","tokens":302,"squid":"spider-07","role":"Council Spider","at":1791341962829,"hash":"0202efd2c47a7a99bfba705de5d44f55399e909b"}
{"url":"https://docs.switchboard.xyz/governance-and-tokenomics/governance-and-tokenomics","domain":"docs.switchboard.xyz","title":"Governance & Tokenomics | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.DeFi is powered by Switchboard. Switchboard is powered by SWTCH.OverviewSwitchboard operates on a decentralized governance model powered by the SWTCH token, which enables community-driven decision making and economic security through a sophisticated staking and rewards system built on Jito's Node Consensus Network (NCN). The SWTCH token underpins the Switchboard protocol's economy and security, designed to align incentives between all network participants, including oracle node operators, data consumers, and token holders to foster a robust, decentralized, and self-sustaining data ecosystem.SWTCH TokenPurpose & Network SecurityGovernance Participation: Direct voting power through staked SWTCH (svSWTCH)Economic Security: Oracle incentive alignment and slashing mechanismsNetwork Incentives: Reward distribution and fee collection systemData Access: Enhanced rate limits and premium product accessToken Allocation & VestingCategory% of Total SupplyVesting ScheduleEcosystem Growth26%Unlocks over 4-6 years, often with initial cliff then linear releaseInitial Contributors25%Cliff unlocks March 2026 with 2 year linear vesting of remaining amountCore Development Team23%Cliff unlocks March 2026 with 2 year linear vesting of remaining amountProtocol Rewards & Incentives16%Distributed continuously over several years as network rewards/subsidiesLaunch & Community10%Unlocked at TGEGrand Total100%Launch DetailsToken Generation Event (TGE): September 9th, 2025Claim Portal: Available at launch for eligible participantsNetwork: Solana blockchain with SPL token standardsvSWTCH: Staked Governance TokenStaking MechanismThe true power of the SWTCH token is unleashed when it is staked to mint svSWTCH (staked-vote SWTCH). This process is facilitated through the Jito Node Consensus Network (NCN) vault, where users can delegate their SWTCH. In return, they receive svSWTCH, a staking token that represents their staked position and continuously accrues rewards from protocol activity. Holding svSWTCH is key to accessing the full suite of utilities within the Switchboard ecosystem.Core svSWTCH Utilities1. Decentralized GovernanceHolding svSWTCH grants direct voting power over the future of the Switchboard protocol. Key areas of governance include:Node Operations: Onboarding, performance requirements, and slashing conditionsEconomic Parameters: Staking, delegation, and reward parametersProtocol Fees: Core protocol fee structures and distributionTechnical Development: Priority upgrades and integrations2. Oracle Incentives & Network SecurityTo participate in the network and validate data, oracle operators must have svSWTCH delegated to them. This \"skin in the game\" model ensures their incentives are directly aligned with data reliability and network health. The prioritization and workload distribution among oracles are determined by a combination of their performance metrics and the total svSWTCH delegated to them. This competitive dynamic rewards high-performing nodes with more work and, consequently, more rewards.3. Yield via Reward DistributionSwitchboard's economic engine is designed to be self-sustaining through:Fee Collection: Network fees (paid in SOL or the chain's native gas token) are collected from every data feed interactionRewards Vault: These fees, supplemented by a SWTCH token subsidy, are deposited into a dedicated protocol rewards vaultAutonomous Distribution: At the end of each epoch (approximately every 2-3 days), the accumulated assets are distributed. The Jito NCN vault managers and configurations are responsible for overseeing this distribution, ensuring rewards are fairly allocated to node operators and individuals who staked SWTCH to receive svSWTCH4. Enhanced Data AccessProtocols and high-volume users can stake svSWTCH to receive higher rate limits for data requests. This tiered access system ensures fair resource allocation, prevents spam, and prioritizes legitimate, high-demand applications that are invested in the protocol's success. svSWTCH holders also unlock free access to Switchboard Surge: simply hold the required amount during your subscription and tap into the fastest data feeds in crypto.Economic Security ModelJito NCN IntegrationSwitchboard leverages Jito's Node Consensus Network for:Restaking Security: Additional economic guarantees beyond native stakingValidator Coordination: Synchronized oracle operations across the networkOracle Incentives: NCN rewards are distributed based on oracle performance in the networkIncentive StructureOracle RewardsBase Rewards: Consistent payments for reliable data provisionPerformance Bonuses: Additional rewards for high uptime and accuracySubsidies: Protocol-funded support for critical data feedsStaker BenefitsYield Generation: Share of oracle fees and network rewardsGovernance Participation: Influence over network parameters and directionProtocol Usage: Higher tier of acces and throughput to the Switchboard networkGovernance ProcessProposal LifecycleDiscussion Phase: Community debate on governance forumsFormal Proposal: On-chain proposal submission with required stakeVoting Period: svSWTCH holder voting with specified durationExecution: Automatic implementation if proposal passes thresholdVoting MechanicsQuorum Requirements: Minimum participation thresholds for valid votesMajority Thresholds: Different requirements for various proposal typesDelegation: Ability to delegate voting power to trusted representativesToken Claim & Getting StartedEligibility & Claiming ProcessWho is eligible to claim SWTCH?Whether you've participated in Switchboard Orbs points programs, staked with Fragmetric, or powered the Switchboard network as an oracle operator, you're eligible. Early supporters and contributors who helped grow Switchboard can claim SWTCH starting September 9th, 2025.How to claim:Connect your Solana wallet to the official claim portalClick \"Claim Your Tokens\" and approve the transactionCover a small SOL fee for the blockchain transaction (no Switchboard fees)Use supported Solana wallets: Phantom, Solflare, Metamask, etc.⚠️ Security: Always verify you're on the official claim URL and double-check before connecting wallets.Getting Started with GovernanceFor Token HoldersClaim SWTCH: Use the official claim portal starting September 9th, 2025Stake to svSWTCH: Convert SWTCH through Jito NCN vault for governance powerParticipate: Vote on proposals and engage in community discussionsFor Oracle OperatorsSecure Delegation: Attract svSWTCH delegation for network participationMaintain Performance: High uptime and data accuracy for competitive rewardsGovernance Engagement: Participate in technical protocol decisionsFor DApps & High-Volume UsersStake for Access: Hold svSWTCH for higher rate limits and premium featuresParticipate: Vote on proposals and engage in community discussionsCommunity & ResourcesOfficial Website: switchboard.xyzTwitter/X: @switchboardxyzDiscord: discord.gg/TJAv6ZYvPCMedium Blog: switchboardxyz.medium.comGitHub: github.com/switchboard-xyzYouTube: @SwitchboardFoundationGroupFoundation Docs: switchboard.foundationFrequently Asked QuestionsWhat is SWTCH? SWTCH is the backbone of the economic security model that powers the Switchboard protocol. Designed to secure and incentivize participation in the most decentralized oracle network, SWTCH boosts data reliability and integrity for the fastest feeds in crypto.What can I do with my SWTCH? SWTCH holders can stake their tokens to secure the Switchboard oracle network and enhance data reliability across DeFi. Staking SWTCH mints svSWTCH, which unlocks staking rewards and governance power. For oracle operators, staked svSWTCH aligns economic incentives and helps ensure network reliability.Can I use SWTCH to pay for price feeds? SWTCH can be staked and delegated to oracles within the Switchboard network. Stakers unlock higher rate limits, allowing users to take full advantage of Switchboard Surge.Are my SWTCH tokens transferable immediately? Additional information about SWTCH allocations, vesting schedules, and transfer restrictions is available in the Switchboard Foundation docs.This governance system ensures Switchboard remains decentralized, secure, and aligned with community interests while maintaining the highest standards of oracle reliability and cross-chain interoperability. SWTCH empowers the community to shape the future of decentralized oracle infrastructure.Last updated 7 months ago","tokens":2132,"squid":"spider-08","role":"Oracle Spider","at":1791341963179,"hash":"1a00211f564067c598cd2f48099d2aebde4a8794"}
{"url":"https://phantom.com/","domain":"phantom.com","title":"Phantom: Your home for trading crypto, predictions, and more","text":"Where the world tradesYour home for trading crypto, predictions, perps, and moreTrading toolsfor everyoneSee moreTradingBuy and sell all types of crypto in an instant.Find trending tokens, top traders, and apps.Trade big moments in culture with Prediction Markets.Go long, go short, go anywhere with Perps.Access powerful trading tools on desktop with Terminal.Spend, Send, & SaveSee moreMove Money One home for your money.Send money in seconds. Even pay friends.Spend wherever Apple Pay, Google Pay, or VISA is accepted.Controlled by you,secured by usSee moreYour securitySelf-custodial means you control your funds. We never have access.Our global Support team is here for you 24/7. Scam detection flags malicious transactions instantly. Connect your Ledger to keep your crypto even safer. Trusted by a community of 20+ million users.\nIt’s more than a wallet. Get started.Download Phantom.The Prepaid Debit Visa Card (the “Card”) is issued by Lead Bank pursuant to licensing by Visa U.S.A. Inc. and may be used everywhere Visa is accepted. Must be 18 or older to apply. Fees may apply. See Cardholder Agreement and Phantom Technologies, Inc.'s (\"Phantom\") website for more details.Bridge Ventures LLC (“Bridge”) is not a bank. Bridge is a financial technology company and is the Program Manager responsible for managing and operating the Card on behalf of Lead Bank. Phantom is not a bank. Phantom is a financial technology company and is the Platform Provider responsible for the application, access, and management of/for the card.","tokens":383,"squid":"spider-10","role":"Tooling Spider","at":1791341966217,"hash":"44abd3d6eeafc11fca37c3bc277d3ffcba7ea4e8"}
{"url":"https://alt.gov.arbitrum.foundation/proposal/71236395575275509514809232906539225896862899916501711888027988560774655719183?govId=eip155:42161:0xf07ded9dc292157749b6fd268e37df6ea38395b9","domain":"alt.gov.arbitrum.foundation","title":"Proposal | Arbitrum Governance | Arbitrum Governance","text":"Back to ProposalsCore7123639557...55719183[Constitutional] AIP: Amended Release of Frozen ETH Pursuant to Court OrderConstitutional QuorumCore GovernorVoting PeriodMay 14, 04:49 PMMay 28, 05:55 PMFor193.12M92.0%Against4.05K0.0%Abstain16.86M8.0%209.99M / 187.48M ARBQuorumProposalExecutedDescription[Constitutional] AIP: Amended Release of Frozen ETH Pursuant to Court Order\nStatus: Amended following passed Temp Check\nAuthors: Aave Labs, KelpDAO, LayerZero, EtherFi, Compound\nDate: 5/11/26\nSummary\nThis amended Constitutional AIP updates the execution path for the previously posted proposal to release the frozen ETH secured by the Arbitrum Security Council in connection with the rsETH incident. Since then, a Court order was issued authorizing the transfer of the frozen ETH to a wallet controlled by Aave LLC and for Aave LLC to hold this frozen ETH while the court continues to deliberate.\nThis amendment preserves the intent approved in the Temp Check to transfer the frozen ETH, but it updates the recipient and custody mechanics so that the onchain execution complies with the recent Court order.\nIf this Constitutional AIP passes, the payload will transfer 30,765.667501709008927568 ETH from 0x0000000000000000000000000000000000000DA0 to the Aave LLC-controlled receiving address listed below.\nAave LLC receiving address:\n0x3b87db6ded35eBD28EcbF8014fb325eef23f6C07\nCourt order: https://storage.courtlistener.com/recap/gov.uscourts.nysd.653423/gov.uscourts.nysd.653423.52.0.pdf\nBackground\nOn April 21, 2026, the Arbitrum Security Council executed an emergency action to immobilize ETH connected to the rsETH incident. The ETH was moved to 0x0000000000000000000000000000000000000DA0 pending a subsequent governance action.\nThen, on April 25, 2026, Aave Labs and others posted an AIP to approve the release of the 30,765.667501709008927568 ETH that the Arbitrum Security Council froze following the April 18 incident. That AIP proposed to release the recovered ETH into an ongoing, coordinated recovery effort with the goal of restoring the economic backing of rsETH. This original proposal completed the Temp Check process with overwhelming approval and strong delegate support.\nThe standard Arbitrum governance process uses Snapshot for Temp Checks and Tally for onchain execution, with Constitutional proposals targeting Arbitrum Core. Arbitrum's governance documentation also distinguishes between Constitutional and Non-Constitutional AIPs, and states that Constitutional proposals are submitted through Arbitrum Core on Tally.\nAfter the Temp Check, plaintiffs holding judgments against North Korea served a restraining notice on Arbitrum DAO seeking to restrain the ETH immobilized as part of the recovery effort. Aave LLC filed an emergency motion to vacate the notice, and the Court held a hearing on May 6.\nFollowing additional submissions from the parties, the Court accepted Aave LLC's proposed path. The Court entered an order authorizing an onchain Arbitrum DAO vote to transfer the immobilized ETH to Aave LLC, with the restraining order following the ETH and attaching to Aave LLC upon transfer.\nThis amended AIP updates the court order's execution path accordingly.\nMotivation\nThe goal of the original proposal remains unchanged. The frozen ETH is part of the broader recovery effort following the rsETH incident, and Arbitrum Governance has already signaled support for releasing the ETH rather than leaving it immobilized indefinitely.\nHowever, on the evening (New York time) of Friday, May 1, 2026, a law firm representing plaintiff-judgment creditors in a case called Kim v. Democratic People's Republic of Korea, 25-MC-527 (S.D.N.Y.) served a restraining notice on \"Arbitrum DAO\" that threatened significant delay. Aave Labs acted as promptly as possible. On Monday May 4, 2026, Aave LLC, a US entity of Aave Labs, filed an emergency motion to vacate the restraining order. That motion was heard in oral arguments on May 6, 2026, and the substantive issues remain under consideration by the court. (We are grateful to the judge for her rapid response and thoughtful, ongoing consideration.)\nOn Friday, May 8, 2026, after an exchange of letters from the plaintiffs and Aave LLC, the court issued an order that the Restraining Notice issued to \"Arbitrum DAO\" is modified, so as to allow an on-chain vote to transfer the immobilized assets to a digital assets wallet controlled by Aave LLC. The judge specifically ordered that such a transfer process \"will not be deemed to be a violation of the Restraining Notice,\" and that \"[a]ny party initiating that on-chain transaction, voting with regard to that on-chain transaction, or participating in the on-chain transfer of assets to Aave LLC shall not be in violation of the Restraining Notice.\"\nIn other words, tokenholders are free to vote or otherwise participate in this process, without fear of violating the restraining notice. (Not legal advice; you are, of course, encouraged to consult your own attorney.)\nThe court reserved decision on all other matters in connection with the Restraining Notice and the Immobilized Assets, meaning that the central question on the merits -- whether and when the funds will be released for use in the recovery effort -- remains to be decided by the court.\nAfter that transfer, and per the court's order, Aave LLC will abide by the terms of the Restraining Notice as if the Restraining Notice had been issued to Aave LLC, until and unless the Restraining Notice is vacated or further modified by the Court, is withdrawn or modified by Plaintiffs, or expires by operation of law. In other words, Aave LLC will not sell, assign, transfer, or interfere with these funds, until the court allows such actions.\nWe view this order as very helpful for the Arbitrum community. It allows the ETH to be transferred to Aave LLC, so that assuming the court agrees with Aave LLC's position that the funds may be used in the recovery efforts, that process will be logistically easier. Aave is grateful to the Arbitrum community for being a \"Good Samaritan,\" and we are eager to ease any further administration burdens on the Arbitrum community.\nAmendment to the Prior Proposal\nThis AIP amends the prior proposal titled:\n[Constitutional] AIP: Approve Release of Frozen ETH\nWe note that the court's order forces a modification in the onchain AIP from the snapshot version. The original proposal was that the recipient address would be a 3-of-4 Gnosis Safe with signers from Aave, KelpDAO, EtherFi, and Certora. However, for administrative and legal convenience, and to be consistent with the court's order, the onchain vote will be that the recipient address will be to a wallet controlled by Aave LLC.\nAave will continue to coordinate with the relevant parties, and the goal remains the same. The ETH is intended to be applied in a neutral and non-discriminatory manner toward restoring rsETH's backing within the Kelp protocol. Every unit of ETH returned to the recovery effort narrows the backing shortfall and moves rsETH closer to full collateralization.\nAccordingly, the amendment is limited to the recipient and custody mechanics.The original proposal requested release of the frozen ETH into the coordinated rsETH recovery effort. This amended proposal requests transfer of the frozen ETH to Aave LLC pursuant to the court order.\nAfter the transfer, and per the court's order, Aave LLC will abide by the terms of the restraining notice as if the restraining notice had been issued to Aave LLC, until and unless the restraining notice is vacated or further modified by the Court, is withdrawn or modified by Plaintiffs, or expires by operation of law. In other words, Aave LLC will not sell, assign, transfer, or interfere with these funds, until the court allows such actions.\nSpecification\nThis Constitutional AIP authorizes the transfer of 30,765.667501709008927568 ETH from:\n0x0000000000000000000000000000000000000DA0\nto the following Aave LLC-controlled receiving address:\n0x3b87db6ded35eBD28EcbF8014fb325eef23f6C07\nThe transfer is made pursuant to the Court order dated May 8, 2026, which authorizes an onchain Arbitrum DAO vote to move the immobilized ETH to Aave LLC and provides that the restraining order will follow the ETH and attach to Aave LLC upon transfer.\nAave LLC will comply with the restraining order while the Court continues to consider the matter.\nThis AIP does not authorize Aave LLC to distribute, transfer, pledge, encumber, stake, lend, swap, bridge, rehypothecate, or otherwise use the ETH unless permitted by the Court or applicable legal process.\nThis AIP does not request any new treasury allocation from Arbitrum DAO.\nImplementation\nIf this AIP passes, the payload will execute a transfer of 30,765.667501709008927568 ETH from 0x0000000000000000000000000000000000000DA0 to 0x3b87db6ded35eBD28EcbF8014fb325eef23f6C07.\nThe proposal will be submitted as a Constitutional AIP through Arbitrum Core. Arbitrum's proposal submission guide states that Constitutional proposals target Arbitrum Core, while Non-Constitutional proposals target Arbitrum Treasury.\nPayload Summary\nTarget source address:\n0x0000000000000000000000000000000000000DA0\nRecipient:\n0x3b87db6ded35eBD28EcbF8014fb325eef23f6C07\nAmount:\n30,765.667501709008927568 ETH\nAction:\nTransfer ETH to Aave LLC-controlled receiving address pursuant to Court order.\nAdditional actions:\nNone.\nTreasury spend:\nNone.\nLegal Posture\nThe restraining notice previously served on Arbitrum DAO sought to restrain the ETH immobilized as part of the rsETH recovery effort. The Court has now entered an order authorizing an onchain Arbitrum DAO vote to transfer the ETH to Aave LLC, with the restraining order following the ETH and attaching to Aave LLC upon transfer.\nAave LLC will comply with the restraining order while the Court continues to consider the matter.\nThis means the onchain vote is not asking delegates to disregard the restraining order. It is asking delegates to approve the transfer path authorized by the Court.\nThe Court order is attached here: https://storage.courtlistener.com/recap/gov.uscourts.nysd.653423/gov.uscourts.nysd.653423.52.0.pdf\nRecovery Context\nIn parallel, the broader rsETH incident recovery plan continues.\nOn May 6, the identified thief positions on Aave V3 were liquidated. The retrieved rsETH collateral was transferred to the Recovery Guardian as specified in the preceding AIP approved by Aave DAO governance. Other users, including Umbrella stakers, were not impacted by this liquidation process.\nThe next phase of the plan focuses on restoring rsETH backing and returning affected markets to normal operation. On Arbitrum, the liquidated rsETH will be burned. Kelp will retire the corresponding LayerZero packet on Ethereum so that it cannot mint new rsETH on the receiving side. Together, those steps are intended to neutralize the inflated rsETH supply created by the exploit.\nOn Ethereum, the seized rsETH will be sent to the bridge lockbox. That ETH, together with committed ETH from the broader DeFi United coalition, is expected to restore the backing of the rsETH lockbox contract. Once the lockbox is backed, the bridge can resume normal operation.\nSeparately, replacement funds are expected to be borrowed as a contingency to reduce the timing impact on affected Aave users while the immobilized ETH remains subject to the Court process.\nThis section is provided for recovery context only. The onchain action authorized by this AIP is limited to the transfer of the frozen ETH to Aave LLC pursuant to the Court order.\nOverall Cost\nNo new treasury allocation is requested.\nThis proposal concerns ETH already immobilized on Arbitrum One in connection with the rsETH incident. The direct budgetary cost to Arbitrum DAO is expected to be zero outside of normal governance execution overhead.\nRisks and Considerations\nThis amendment is submitted to address the main risk of legal execution risk by aligning the transfer with the Court's order and by having the restraining order follow the ETH to Aave LLC upon transfer.\nThe proposal does not ask delegates to determine final ownership of the ETH. The Court process remains ongoing.\nThe proposal does not authorize immediate distribution to affected users. Aave LLC will comply with the restraining order while the Court continues to consider the matter.\nThe proposal does not create new Arbitrum DAO treasury exposure. It only authorizes transfer of ETH already immobilized as part of the Security Council emergency action.\nThe proposal changes the recipient from the originally contemplated recovery structure to Aave LLC. Because that is a material execution-path change after the Temp Check, the original coauthors have been asked to support this amendment before onchain submission.\nNext Steps\nFirst, the final payload will be prepared and submitted onchain.\nSecond, the Constitutional AIP will proceed to onchain vote through Arbitrum Core.\nThird, if the AIP passes and execution occurs, the immobilized ETH will be transferred to the Aave LLC-controlled receiving address, with the restraining order following the ETH and attaching to Aave LLC upon transfer.\nRequested Action\nArbitrum delegates are asked to vote FOR this amended Constitutional AIP.\nA FOR vote approves the court-authorized transfer of 30,765.667501709008927568 ETH from 0x0000000000000000000000000000000000000DA0 to the Aave LLC-controlled receiving address listed in this proposal.\nA FOR vote does not authorize distribution or use of the ETH while the restraining order remains in effect.\nA FOR vote preserves the recovery objective supported by the Temp Check while updating the execution path to reflect the Court's order.\nAn AGAINST vote leaves the ETH immobilized at the current address unless and until another governance or legal path is approved.Proposal PayloadShowing 1 final action from 1 submitted call.Governance execution routeL2 TimelockL1 TimelockEthereumExpand to inspect the submitted ArbSys, timelock, retryable, and executor calldata.Submitted governance callArbitrum OneTo:0x0000000000000000000000000000000000000064sendTxToL1()local[0]address0xE6841D92B0C345144506576eC13ECf5103aC7f49Arb1[1]bytesNested callscheduleBatch()local[0]address[][0x3ffFbAdAF827559da092217e474760E2b2c3CeDd][1]uint256[][0][2]bytes[][1 calls]Batch action [0]execute()local[0]address0x3d456FCd62f5baBCf3263B72fb4ac8fF8cc5a322Arb1[1]bytesNested callexecute()4byte[0]address0x554723262467F125Ac9e1cDFa9Ce15cc53822dbDArb1[1]address0x4Dbd4fc535Ac27206064B68FfCf827b0A60BAB3fArb1[2]uint25650000[3]uint2561000000000000[4]uint2560[5]address0x3b87db6ded35eBD28EcbF8014fb325eef23f6C07Arb1[6]uint25630765617401709008927568 (30765.617401709008927568 ETH)[7]bytes0x[8]address0x0000000000000000000000000000000000000DA0Arb1[3]bytes320x0000000000000000000000000000000000000000000000000000000000000000[4]bytes320x33b7ee59a8f0337d1c2610a4819e4e7faf99b696c695b18e7df3929435b27c1b[5]uint256259200Raw calldata0x928c169a000000000000000000000000e6841d92b0c345144506576ec13ecf5103ac7f49000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000003848f2a0bb000000000000000000000000000000000000000000000000000000000000000c000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000000000000000000140000000000000000000000000000000000000000000000000000000000000000033b7ee59a8f0337d1c2610a4819e4e7faf99b696c695b18e7df3929435b27c1b000000000000000000000000000000000000000000000000000000000003f48000000000000000000000000000000000000000000000000000000000000000010000000000000000000000003fffbadaf827559da092217e474760e2b2c3cedd000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000001c41cff79cd0000000000000000000000003d456fcd62f5babcf3263b72fb4ac8ff8cc5a322000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000001440a2e5a5b000000000000000000000000554723262467f125ac9e1cdfa9ce15cc53822dbd0000000000000000000000004dbd4fc535ac27206064b68ffcf827b0a60bab3f000000000000000000000000000000000000000000000000000000000000c350000000000000000000000000000000000000000000000000000000e8d4a5100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000003b87db6ded35ebd28ecbf8014fb325eef23f6c07000000000000000000000000000000000000000000000683ceb5c7a099c63b5000000000000000000000000000000000000000000000000000000000000001200000000000000000000000000000000000000000000000000000000000000da000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001ActionEthereumDelegatecallTo:0x3d456FCd62f5baBCf3263B72fb4ac8fF8cc5a322execute()4byte[0]address0x554723262467F125Ac9e1cDFa9Ce15cc53822dbDL1[1]addressArb1 Delayed InboxL1[2]uint25650000[3]uint2561000000000000[4]uint2560[5]address0x3b87db6ded35eBD28EcbF8014fb325eef23f6C07L1[6]uint25630765617401709008927568 (30765.617401709008927568 ETH)[7]bytes0x[8]address0x0000000000000000000000000000000000000DA0L1Raw calldata0x0a2e5a5b000000000000000000000000554723262467f125ac9e1cdfa9ce15cc53822dbd0000000000000000000000004dbd4fc535ac27206064b68ffcf827b0a60bab3f000000000000000000000000000000000000000000000000000000000000c350000000000000000000000000000000000000000000000000000000e8d4a5100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000003b87db6ded35ebd28ecbf8014fb325eef23f6c07000000000000000000000000000000000000000000000683ceb5c7a099c63b5000000000000000000000000000000000000000000000000000000000000001200000000000000000000000000000000000000000000000000000000000000da00000000000000000000000000000000000000000000000000000000000000000","tokens":4513,"squid":"spider-07","role":"Council Spider","at":1791341985215,"hash":"3a09d43294702dc6e9c5b47c36faaec1b6d9549e"}
{"url":"https://docs.switchboard.xyz/how-it-works/technical-architecture/oracle-queues","domain":"docs.switchboard.xyz","title":"Oracle Queues | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.An Oracle Queue (often just called a \"Queue\") is a core component of Switchboard, designed to manage and secure data feeds by creating a structured and secure environment that facilitates efficient management, isolation, and reliable data delivery.Think of a Queue as:A Dedicated Subnetwork of the larger Switchboard Protocol: A whitelisted environment within the Switchboard protocol, controlling which software can be executed and which oracles are authorised to respond in its network.An Oracle Registry: A list of on-chain oracle accounts, each linked to a physical machine that fetches and publishes data.A Security Boundary: Oracles within a Queue must run verified code. This ensures that only trusted nodes contribute to the data feeds.A Multi-Chain Entity: Defined on Solana and synchronised across all Switchboard deployments on different blockchains.Queues have an important key characteristic:Each data feed must belong to one, and only one, Queue.Most integrations use the shared Switchboard queues and never create one. If you need your own — to control which oracles serve your feeds, or to pin the software they run — see Running your own Queue.PreviousTrusted Execution Environments (TEEs)NextNode ArchitectureLast updated 1 month ago","tokens":336,"squid":"spider-08","role":"Oracle Spider","at":1791341985255,"hash":"2c22f4ad88caba3e78aca95e063ee1bc2b9316aa"}
{"url":"https://help.phantom.com/","domain":"help.phantom.com","title":"Phantom Help Center","text":"Phantom Support will never DM you or ask you for your recovery phrase.How can we help you?SearchGet startedCreate your Phantom wallet, customize your accounts, and learn about the key features.CashUse Cash like everyday money: add from bank or card, spend with your Phantom debit card, transfer to other Phantom users and wallets, and use across Phantom to trade tokens, perps, and predictions.SecurityProtect your wallet from scams, phishing, and hacks—plus tips on staying safe.Manage accounts and settingsManage your Phantom wallet accounts and settings.Connect to appsConnect Phantom to apps, manage your connection settings, and troubleshoot connections.StakeStake SOL natively or with liquid staking to earn rewards.Manage tokens and collectiblesManage tokens and collectibles in your Phantom wallet.TradeTrade tokens, perps, and prediction markets in Phantom.Promoted articlesGet started with BNB Chain in PhantomGet startedGet started with Arc network in PhantomGet startedRobinhood Chain FAQGet startedWhy is my token hidden or flagged as spam?Manage tokens and collectiblesContact Phantom SupportSecurityI was scammed or my wallet was drained. What can I do?SecurityUse copy trading in PhantomTradePhantom Referral Program guideTradeBuy SOL, ETH, BTC, and other native tokens in Phantom on mobileTradeUnderstanding gasless EVM transactionsTradeUnderstanding asset pages in PhantomTrade","tokens":349,"squid":"spider-10","role":"Tooling Spider","at":1791341988983,"hash":"d9a2c3220f78bbd43a5aab2a2a7ad6b971f7ac16"}
{"url":"https://docs.switchboard.xyz/how-it-works/technical-architecture/trusted-execution-environments-tees","domain":"docs.switchboard.xyz","title":"Trusted Execution Environments (TEEs) | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.Switchboard enhances its security model with Trusted Execution Environments. Instead of relying solely on the assumption that the majority of oracles are honest (\"honest-majority\"), we use TEEs for added protection. Switchboard currently uses AMD SEV-SNP (Secure Encrypted Virtualization - Secure Nested Paging) for hardware-backed attestation.Think of TEEs as secure enclaves where code can run in isolation, protected from the rest of the system. This means:Code Verification: Switchboard can cryptographically verify that each oracle node acting as a publisher is running only the approved and verified code. No rogue modifications allowed.Data Integrity: This verification process ensures the integrity of the data being provided, as the code responsible for fetching and signing data hasn't been tampered with.In essence, TEEs provide a hardware-backed guarantee of code integrity, offering a robust defence against malicious actors and further bolstering the reliability of Switchboard's data feeds on-chain.TEE Applications and ConsiderationsTEEs are generally overlooked, but they are used by many of the most popular applications that are synonymous with security and safety.Signal app uses TEEs to safeguard its users' messages, guaranteeing they remain secure and private.Azure Cloud (Microsoft) leverages TEEs, to ensure top-tier credit card data management and protection, so both Azure and its corporate clients can maintain optimum PCI compliance.1Password employs TEEs (across a host of its platforms), adding extra layers of security to a user's passwords.Flashbots relies on TEEs as an integral tool in verifiable block operations, so trust and integrity will be maintained within blockchain operations.Because TEEs are not perfect and can have undocumented security flaws, Switchboard needs to have a system in place to quickly shut down or upgrade any oracle. To stay on top of this, Switchboard makes all oracles prove they're still trustworthy by re-verifying their certificates and also uses economic incentives to help ensure integrity.PreviousTechnical ArchitectureNextOracle QueuesLast updated 9 months ago","tokens":556,"squid":"spider-08","role":"Oracle Spider","at":1791341994660,"hash":"a5884b455550376d4b59b67f82a317afb3a609c7"}
{"url":"https://alt.gov.arbitrum.foundation/security-council","domain":"alt.gov.arbitrum.foundation","title":"Security Council Elections | Arbitrum Governance | Arbitrum Governance","text":"Security CouncilThe Arbitrum Security Council consists of 12 members split into two cohorts. Elections are now held every 12 months and replace one cohort, so a member serves a 2-year term. Elections through March 2026 ran every 6 months on one-year terms; Security Council Election Process Improvements, executed by the DAO, moved them to a yearly cadence each March, lowered the nominee qualification threshold, and let members and candidates rotate their own signing keys.Immunefi(Immunefi)zachxbt(ZachXBT)gzeon(Smart Contract @ Offchain Labs)Emiliano Bonassi(Head of Product @Conduit)Griff Green(Founder: Giveth, Dappnode, etc)Cyfrin | Arbitrum Security Council(Cyfrin | CEO)Pablo Sabbatella (OPSEK)(Founder @ OPSEK)bartek.eth(Founder @ L2BEAT)Michael Lewellen(Solutions Eng Head @ Turnkey)yoav.eth(Security @ Ethereum)DZack23(Independent (Ex Offchain Labs))Tigran (Certora)(Head of Security Labs)Sitting members can rotate their own signing key at any point in their term. The rotation runs the full governance timelock (about 18 days) before the new signer is registered in the Security Council multisigs on Arbitrum One, Ethereum and Arbitrum Nova, and the Security Council can veto a rotation that fails compliance checks.Candidates in an election can rotate the key they registered with during the compliance phase, up to 3 days before that phase ends, which leaves the Arbitrum Foundation time to veto an improper rotation.A member or candidate requesting a rotation is expected to announce it on the forum once it is submitted on chain.Read the election rules in the DAO Constitution","tokens":399,"squid":"spider-07","role":"Council Spider","at":1791341997577,"hash":"c953072c445f42dbae636857388daf1ccbe38349"}
{"url":"https://docs.switchboard.xyz/how-it-works/technical-architecture/node-architecture","domain":"docs.switchboard.xyz","title":"Node Architecture | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.The Switchboard network distributes data processing across various node types, each with specific responsibilities. Understanding these node types is essential for grasping how data requests are handled and secured within the Switchboard architecture. The following table details each node type and its key functions:Node TypeRole/FunctionKey Features/ResponsibilitiesGuardianGatekeeper of Data IntegrityVerifies Oracle code integrity, Bridges blockchains and TEE, Initiates TEE verification, Strict approval processOracleDecentralised Access — Acts as a web API for public accessSegregated internal components for security and efficiencyOracle Router — FrontendTraffic Controller-Mitigation of DoS threats — Protects the internal environment from Denial of Service (DoS) attacksFront-end traffic controlOracle Router — GatewayTask Distributor — Assigned tasks efficiently across workersCalculates the best way to assign different tasks with different parametersOracle WorkerTask Executioner — Runs code for data retrieval and signingExecutes tasks assigned to workerGuardian and Oracle OnboardingGuardians play a crucial role in the Switchboard network by verifying that oracles and other guardians are running the correct software images. This verification process involves checking their Trusted Execution Environment (TEE) attestations. Once approved, guardians can proceed through the guardian attestation process and act as validators for the network.Step 1: Initial Onboarding as Root of TEE Attestation.Guardians are first and foremost onboarded into the network as the root validators of TEE attestations. This inaugural step is necessary to establish their pivotal role as the secure bridge between TEE attestation practices and the blockchain itself.Here is a visual representation of the entire process:Following successful verification, a minimum of one-third of all guardians are required to attest to the TEE attestations of each oracle. This ensures robust validation and security across the Switchboard network.Oracle OnboardingBefore any attestation can occur, all oracle nodes must first successfully navigate a pre-approval process. Only then can they formally seek guardian approval. Once an oracle has been both approved and verified that the correct software image is running, said entity gains the ability to join the Oracle Queue.Step 2: Guardian Attestation and Addition to Oracle QueueThe Guardian attests to the oracle's TEE attestation and, upon successful verification, adds the oracle to the Oracle Queue.Important Keypair Verification Note: Similar to oracles, guardians must also undergo a keypair verification process, ensuring that all secp256k1 keypairs are considered valid for a period of seven days, after which they must undergo a re-verification.Following the successful completion of the onboarding procedures for both guardians and oracles, users can then commence the process of requesting price signatures to be used on-chain.The Lifespan of a Data Feed RequestOnce onboarded, users have the flexibility to define their custom data feeds and solicit updates from oracle nodes within the network. This process ensures that the data returned to the user includes essential data feed outputs, and any signatures required to validate data updates on-chain.Step 3: User Request and On-Chain PostingThe user requests data from a specified feed through the gateway. In response, the user receives a signature-set. The user then posts this signature-set on-chain to update the data.Users can request up-to-date data from a specified feed through the gateway. Following a response, the user receives a signature set, which is then posted on-chain to update the data.PreviousOracle QueuesNextCrossbarLast updated 9 months ago","tokens":963,"squid":"spider-08","role":"Oracle Spider","at":1791342004573,"hash":"d93f997f19be5c62e74d563322d42088dacb86cc"}
{"url":"https://alt.gov.arbitrum.foundation/security-council/contender/0xf879c33b455b69b2719c0cc3cb06eac77d513cec","domain":"alt.gov.arbitrum.foundation","title":"Candidate Profile | Security Council Elections | Arbitrum Governance","text":"Back to ElectionsCandidate ProfileSecurity Council election candidateTino | SEEDGovTechnical Researcher | SEEDGovIndividual0xf879c33b455b69b2719c0cc3cb06eac77d513cecTwitterItalyRepresentative: Martin AzpirozMotivationSecurity Council decisions are high-stakes, often time-sensitive, and require people who actually understand what they're signing off on, technically and operationally. The combination of what SEEDGov brings as an organisation and my background as our representative is exactly what this role calls for:Hands-on smart contract and protocol analysis, Direct experience managing multisig infrastructure, Deep familiarity with Arbitrum's governance and technical stack, and A track record of operating under structured, accountable frameworks.We're not newcomers to Arbitrum, and we're not here to rubber-stamp decisions. We're here because we think governance security is just as important as protocol security, and we want to help make sure both hold up.ExperienceI have been in crypto for over six years, five of them full-time. I've spent two and a half years as an Associate Researcher at BCAS, and I'm currently a Blockchain and Smart Contract Advisor at Axis Group, where my day-to-day involves reviewing the code and architecture of major DeFi protocols and Layer 2s as part of Decentralisation Audits and technical assessments under MiCA. That means identifying protocol-level risks and evaluating smart contract systems under strict regulatory and security standards — I've contributed technical input to more than 40 whitepapers and several licensing processes across that time, which has given me a detailed picture of how these systems are built, how they interact, and where the failure points tend to live.On the Arbitrum side, I'm part of the Stylus Sprint programme as a milestones reviewer, where I've reviewed more than 40 technical milestones across projects contributing core infrastructure to the Stylus stack, giving me direct exposure to Arbitrum's technical architecture and development pipeline from both a technical and governance angle. On the brother Layer 2 ecosystem side, I'm currently serving as Governance Facilitator for the Operations Committee of Scroll DAO, where I'm responsible for setting up and managing the DAO's multisigs. As part of that work, I've also built tooling to monitor DAO activity and multisig transactions, including a dedicated interface to track and categorise multisig operations, and Dune dashboards tracking protocol and DAO activity more broadly. I've also led technical tracks on ZK-EVM architecture through the Scroll DAO Accelerator Programme, helping onboard contributors to the practical realities of working within an L2 ecosystem.SkillsSolidity7/10Rust6/10Go0/10JavaScript8/10CybersecuritySince I’ve been involved in many DAOs and participated in many multisigs, I’ve been trained more than once in cybersecurity — for example, on Gitcoin, Scroll, etc. Beyond that, I designed the Scroll security training for multisig signers. Lastly, I’ve read many audits in my role as an Associate Researcher at BCAS, as a Blockchain and Smart Contract Advisor at Axis Group, as well as in my role as a technical milestone reviewer on the Stylus programme.Can independently verify multisig transactionsProjectsI'm currently serving as Governance Facilitator for the Operations Committee of Scroll DAO, where I'm responsible for setting up and managing the DAO's multisigs. I'm also an active delegate on the ZkSync DAO.","tokens":873,"squid":"spider-07","role":"Council Spider","at":1791342007524,"hash":"240082d8dd74ebb3365bb8c67fd7f9e053285bc0"}
{"url":"https://developer.arbitrum.io/run-a-node/arbos-releases/arbos61","domain":"developer.arbitrum.io","title":"ArbOS 61 Elara","text":"Arbos releasesArbOS 61 ElaraLearn about the ArbOS 61 Elara release and upgrade requirements for Arbitrum chain owners and node operators.Request an updateArbOS 61 Elara\nThis page is intended for all Arbitrum node operators and Arbitrum chain owners; it summarizes the changes brought by 61 \"Elara\" and what you should do to ensure a seamless upgrade.\nNoteThe Nitro version, Docker image tag, nitro-contracts versions, and WASM module root below are final.\nThe minimum Nitro version that supports ArbOS 61 \"Elara\" is Nitro 3.11.3, which is available on Docker Hub with the image tag offchainlabs/nitro-node:v3.11.3-beb2108. This release of Nitro is a mandatory upgrade for and node operators. The ArbitrumDAO approved ArbOS 61 Elara for Arbitrum One and Nova in an onchain vote that ran from July 16 to July 30, 2026 (proposal), so this upgrade is confirmed for both chains. ArbOS 61 activates on Arbitrum One and Nova on Thursday, August 20, 2026 at 17:00 UTC.\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 61 Elara is an upgrade that builds upon ArbOS 51 Dia.\nRequirements\n\nRunning Nitro 3.11.3 or higher, which is available on Docker Hub with the image tag offchainlabs/nitro-node:v3.11.3-beb2108.\nWASM module root (consensus-v61): 0xc10cd7ec6acaf1c441a3f6bd0900ad20f15855ba775a96f1939118cbc629dc97\n\nAdditional requirements for chain owners/operators:\n\nHaving read and understood the ArbOS Software Releases Overview page.\nFollowing the Guide for how to upgrade ArbOS on your Arbitrum chain.\nArbOS 61 Elara should technically work with all previous nitro-contract versions, but you may need specific versions if you want to enable optional features for your chain:\n\nTo take advantage of the new AltDA API (new chains only) or the new base stake management functions for BoLD, you will need nitro-contracts v3.2.0 or higher.\nTo enable Native Token Mint/Burn capabilities for your chain, you must use nitro-contracts v3.1.1 or higher.\nTo use BoLD, you'll need nitro-contracts v3.1.0 or higher.\n\nHigh-level description of ArbOS 61 changes\nArbOS 61 Elara introduces several improvements and features that benefit all Arbitrum chains.\nStylus smart contract size limit increased to 96 KB\nThis change is enabled on Arbitrum One and Nova.\nStylus contracts launched with the same 24 KB code size limit as Solidity contracts, to maximize interoperability between the two and to keep the transition familiar for Solidity developers. As teams pushed further into Rust libraries through the first-party SDK and the wider Rust ecosystem, that limit became substantially more constraining for Stylus programs than it typically is for Solidity contracts, adding friction and complexity for larger applications.\nArbOS 61 raises the Stylus limit to 96 KB — a 300% increase, and 4× the code size limit for Solidity contracts on the EVM.\nThe increase works by changing how Stylus contracts are deployed and activated:\n\nWhen a contract larger than 24 KB is deployed, cargo stylus deploy splits it into the smallest number of fragments needed so each fits under the regular 24 KB contract size limit. The default MaxFragmentCount is 4.\nEach fragment is deployed in its own transaction. A root contract is deployed last, holding the ordered list of fragment addresses.\nOn activation through ArbWasm, the State Transition Function reads all fragments through the root contract and concatenates their contents before decompression.\nFrom that point, the node treats the collection of fragments as a single contract. The root contract address is the one callers use, and it behaves like any other Stylus contract.\n\nThis change is limited to Stylus. The 24 KB limit for Solidity contracts is deliberately unchanged: raising it would alter core EVM assumptions and diverge from Ethereum's contract size rules, potentially impacting node performance, developer tooling, and cross-chain compatibility.\nMinimum L2 base fee management\nThis applies only to Arbitrum One and Nova. It does not affect any other Arbitrum chain: the BaseFeeManager delegation is scoped to those two chains, and chain owners elsewhere keep full control of their own minimum base fee.\nArbOS 61 grants Offchain Labs — acting as a service provider to the Arbitrum Foundation, on behalf of and for the benefit of the ArbitrumDAO — the ability to modify the minimumL2BaseFee and L2BaseFee values on Arbitrum One and Nova to any value between 0.01 gwei and 0.10 gwei, inclusive.\nThe mechanism is a newly deployed BaseFeeManager contract containing an access list. The ArbitrumDAO uses that access list to designate Offchain Labs as the party permitted to make these calls, in the same pattern as the ResourceConstraintManager contract deployed alongside ArbOS 51 Dia.\nTerms and safeguards:\n\nThe privilege expires two years after mainnet activation on Arbitrum One and Nova.\nEvery change is announced publicly via a forum post, so the ArbitrumDAO has full visibility into modifications.\nThe ArbitrumDAO retains the right to remove the delegation at any time through the standard governance process. These revocation actions are onchain.\nNo time-lock or execution delay is built into the BaseFeeManager contract.\nThe contract was audited by an independent third party (Trail of Bits). The final report is published and linked below.\n\nThe intent of the delegation is to allow the minimum L2 base fee to be iterated on without a 30+ day Constitutional vote per change, converging over time on a stable final value. For reference, the minimum L2 base fee on Arbitrum One and Nova was set to 0.02 gwei on January 8, 2026, as part of the ArbOS 51 Dia upgrade.\nPriority fee collection\nThis ships in ArbOS 61 but is not switched on for Arbitrum One or Nova at activation. It is optional and available to any Arbitrum chain.\nArbOS 61 introduces a mechanism for an Arbitrum chain to collect tips as priority fees. Users have always been able to specify a priority fee on a transaction, but no Arbitrum chain was configured to accept one, so the value was ignored.\nTurning the feature on takes two steps: enabling tip collection itself, and updating the sequencer's sorting logic to take the PriorityFee field into account.\nThe ArbOS 61 AIP grants Offchain Labs the authority to toggle tip collection on Arbitrum One and Nova. That toggle is not flipped at ArbOS 61 activation — enabling it on Arbitrum One is bundled with the separate Priority Gas Auctions (PGA) and Fast Feed vote.\nFor configuration details, see the Priority fees section.\nAlternative Data Availability (AltDA) Layer API\nThis ships in ArbOS 61 but is left intentionally disabled on Arbitrum One and Nova. It is intended for other Arbitrum chains.\nArbOS 61 introduces a pluggable interface to the Arbitrum node software, allowing AltDA layers — such as EigenDA or Celestia — to integrate with an Arbitrum chain without forking the node software. Once a chain owner integrates it, the API also reduces the technical overhead of maintaining existing Nitro forks used to run Arbitrum chains on AltDA layers.\nThe interface is intended for Arbitrum chains that post data to a DA layer other than Ethereum, another Arbitrum L2, or an AnyTrust DAC. It is not intended for use by Arbitrum One or Nova, since both settle to Ethereum; it is included in ArbOS 61 to simplify the codebase and canonicalize the feature in Nitro.\nFor implementation details, see How to integrate with the DA API, which covers the JSON-RPC server methods a DA provider must expose (reading batch data by certificate, writing batch data, generating fraud-proof validation proofs) and the Solidity validator contract that validates those proofs onchain.\nCompliance transaction filtering\nThis ships in ArbOS 61 but is left intentionally disabled on Arbitrum One and Nova. It is optional and available to any Arbitrum chain.\nArbOS 61 includes new optional components in the sequencer and the State Transition Function that enable protocol-level transaction filtering for regulatory or compliance purposes, at the chain owner's discretion.\n\nThe chain owner may configure an external compliance service, such as TRM or Chainalysis, to define address-level policies.\nAny transaction that originates from, targets, or otherwise involves a restricted address is filtered prior to execution, including those submitted through the Delayed Inbox.\nThe feature is gated behind an ArbOwner call, so only the chain owner can enable it.\nA 7-day enable delay is built in: if a chain owner enables filtering on a live chain, it takes 7 days for the change to take effect.\n\nThe feature is not enabled on Arbitrum One or Nova. It is included in ArbOS 61 to simplify the codebase and canonicalize the feature in the node software, and is intended for Arbitrum chains with compliance and regulatory obligations to restrict onchain activity from sanctioned entities or actors. You can learn more in our compliance filtering explainer.\nWASM compatibility changes\nThis applies to every chain that upgrades to ArbOS 61.\nArbOS 61 includes several bug fixes and improvements to Stylus. It also removes support for the WebAssembly multi-value extension, which simplifies the execution model.\nContracts that rely on multi-value WASM can no longer be activated or reactivated. Chain owners and Stylus developers should confirm their contracts do not depend on the extension before upgrading.\nGas refund logic fix — the reason for the version bump to ArbOS 61\nThis applies to every chain that upgrades to ArbOS 61.\nDuring testing of ArbOS 60 on Arbitrum Sepolia, an ecosystem partner reported, and Offchain Labs subsequently confirmed, that two interacting bugs in the gas refund logic caused small, unintended changes to gas refund behavior.\nThe required fixes modify the State Transition Function and can only be applied through a new ArbOS version. The corrected release is therefore versioned as ArbOS 61.\nArbOS 61 is otherwise identical in scope to the ArbOS 60 Elara proposal: no features, parameters, or permissions changed. Arbitrum One and Arbitrum Nova were never affected, because ArbOS 60 was not activated on either chain.\nActivation\n\nArbitrum Sepolia activated ArbOS 61 on Monday, June 29, 2026 at 15:00 UTC.\nArbitrum One and Arbitrum Nova will activate ArbOS 61 on Thursday, August 20, 2026 at 17:00 UTC. Node operators must be running Nitro v3.11.3 ahead of that time to keep syncing the chain. The upgrade was approved by Constitutional AIP: the onchain vote opened on July 16, 2026, closed on July 30, 2026, and passed, followed by the timelock period set out in the ArbitrumDAO Constitution. Executed activation timestamps are recorded in the Arbitrum DAO network upgrades table.\n\nReference links for this revision\n\n[Constitutional] AIP: ArbOS 61 Elara — canonical AIP thread, including the June 19, 2026 update\nConstitutional AIP: ArbOS61 Elara Upgrade — onchain vote — the executed onchain proposal; voting ran July 16 to July 30, 2026\nArbitrum ArbOS upgrades — background on ArbOS upgrades as hard forks\nArbitrum DAO network upgrades — canonical table of governance approval status and per-chain activation timestamps\nHow to integrate with the DA API — integration guide for building a custom DA provider against the new API\nPriority fees — how to configure priority fee collection on an Arbitrum chain\nDeploying contracts larger than 24 KB — fragmented deployment flow for Stylus contracts above the 24 KB limit\nTrail of Bits ArbOS 60/61 code review, July 10, 2026\nGuide for how to upgrade ArbOS on your Arbitrum chain\nREADME for how to upgrade your rollup contracts to support ArbOS 61 on your chain\nNitro releases\nnitro-contracts releases\nArbOS 51 Dia release notes\nForum post for ArbOS upgrades\nHow is this guide?OverviewOverview of ArbOS software releases for Arbitrum, including upgrade requirements and the relationship between Nitro and ArbOS versions.Dia (ArbOS 51)Learn about ArbOS 51 Dia release, including Fusaka upgrade support, new EIPs, bug fixes, and upgrade requirements for Arbitrum chain owners and node operators.","tokens":3026,"squid":"spider-01","role":"Chain Spider","at":1791342009542,"hash":"096517a313914a694bc49d6e94ae9c4dd99ee632"}
{"url":"https://developer.arbitrum.io/run-a-node/assign-node-roles","domain":"developer.arbitrum.io","title":"How to assign roles to a Nitro node","text":"How to assign roles to a Nitro nodeUnderstand how a Nitro node's role (RPC node, archive node, sequencer, batch poster, validator — optionally with split validation — or feed relay) is set by configuration flags, and how to convert a node from one role to another.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 , a , a , or a plain RPC node is the set of configuration flags you pass at startup. The exceptions are the — 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 also need --parent-chain.blob-client.beacon-url to read batches posted as EIP-4844 . 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.\nNote--node.staker.enable defaults to true, so a default full node is technically a : 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, , and Docker details, see How to run a full node.\nArchive node\nAn 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 . 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 . 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 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 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 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 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 ). 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.How is this guide?Run a full nodeLearn how to run an Arbitrum node on your local machineRun a local full chain simulationThis page provides instructions for setting up a complete local development environment for testing Arbitrum contracts in a fully simulated environment.","tokens":5148,"squid":"spider-01","role":"Chain Spider","at":1791342019373,"hash":"1230ed8d04d88b76b9e977ab100f59e3661bc341"}
{"url":"https://www.paradigm.xyz/writing/the-l1-dilemma","domain":"paradigm.xyz","title":"The L1 Dilemma","text":"The L1 Dilemma New L1s succeed by exploiting the dogma of incumbents.Ethereum succeeded by exploiting Bitcoin's resistance to programmability.Solana succeeded by exploiting Ethereum's devotion to home stakers.Hyperliquid is succeeding by exploiting Solana's unwillingness to specialize their protocol.The reality is that all great L1s are born as cults. As these ecosystems grow, the dogma that once fueled them starts to tighten, creating space for competition. If they aren't careful, the crusade that got them where they are can distract them from credible competitive threats.Of course, exploiting an incumbent L1's dogma does not guarantee success – after all, Bitcoin is still king. But this is what buys you the headroom to compete. Fortunately for new entrants, today's incumbents are mired in dogma.This dynamic is the crypto equivalent of the Innovator's Dilemma – the L1 Dilemma.What are today's L1s dogmatic about?Here are a few candidates:Geographic decentralization is importantBFT consensus is prerequisite (e.g. optimistic or whitelist-based are untouchable)Becoming a validator should be permissionlessDeploying smart contracts should be permissionlessSharding is badAll apps should be treated the same by the chainAll transactions should be subject to the same notion of finalityOne token as the staking tokenFaster is better (24h block times?)Chain upgrades should be manual (automate with decision markets?)If you’re interested in or currently working on any of the above (or have ideas on alternatives), please reach out!Special thanks to Matt Huang, Storm Slivkoff, Dan Robinson, Frankie, Arjun Balaji for discussion and feedback.","tokens":413,"squid":"spider-04","role":"Research Spider","at":1791342024005,"hash":"e2318817f08011aa3aa80a695f157933a59f78ae"}
{"url":"https://developer.arbitrum.io/run-a-node/beacon-nodes-historical-blobs","domain":"developer.arbitrum.io","title":"Beacon Nodes: Historical Blobs","text":"Beacon Nodes: Historical BlobsLearn more about the impacts of the Fusaka upgrade when running a beacon node.Request an update network operators must connect to an Ethereum beacon chain node with historical data to ensure proper functioning of the 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, / node operators, 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 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.\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.\nHow is this guide?Run a feed relayLearn how to run an Arbitrum feed relay, and how to architect relays and nodes for reliable feed consumption at fleet scale.Arbos releasesArbos releases documentation","tokens":785,"squid":"spider-01","role":"Chain Spider","at":1791342033360,"hash":"fb20d881aca31c86c1bff4637b95fa73f3b8f532"}
{"url":"https://akash.network/roadmap/2020","domain":"akash.network","title":"Akash Network Roadmap - 2020","text":"Akash RoadmapAkash's roadmap outlines the high-level goals and priorities for the Akash Network.Year:2018201920202021202220232024202520262027aep-6Cosmos SDK MigrationCompletion Date: 1/28/2020Migrate Akash codebase to Cosmos SDK to improve scalability, efficiency, and security.aep-7Incentivized Testnet 1: Akashian Challenge Phase 1Completion Date: 5/21/2020As a decentralized system, and the world’s first distributed peer-to-peer open cloud computing marketplace, our aim is to materialize the vision of an open cloud that’s as boundless and free as the sky. To this end, we’re leveraging a series of testnets to gather data, identify critical issues, and ensure our network’s scalability, security, and usability before we launch our mainnet. aep-8Mainnet 1: SecurityCompletion Date: 9/24/2020Mainnet release with security, liquidity, and decentralization.","tokens":215,"squid":"spider-03","role":"Compute Spider","at":1791342034966,"hash":"aed6b0d93eab8f1faa9f6e2749019803bd17712b"}
{"url":"https://developer.arbitrum.io/run-a-node/run-feed-relay","domain":"developer.arbitrum.io","title":"How to run a feed relay","text":"How to run a feed relayLearn how to run an Arbitrum feed relay, and how to architect relays and nodes for reliable feed consumption at fleet scale.Request an updateWarningIf 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 :\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 does not communicate with Nitro , 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 \\\n --chain.id=42161 \\\n --node.feed.input.url=wss://arb1-feed.arbitrum.io/feed,wss://arb1-delayed-feed.arbitrum.io/feed \\\n --node.feed.output.addr=0.0.0.0 \\\n --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 \\\n --node.feed.input.url=ws://relay-region1.internal:9642,ws://relay-region2.internal:9642 \\\n ...\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\nHow is this guide?Data AvailabilityLearn how data availability works in arbitrumHistorical blobsLearn more about the impacts of the Fusaka upgrade when running a beacon node.","tokens":3070,"squid":"spider-01","role":"Chain Spider","at":1791342044158,"hash":"add2ddb69af48eb66c26c8fbb3263464d90b7072"}
{"url":"https://www.paradigm.xyz/writing/open-sourcing-centaur-multiplayer-self-hosted-secure-agents","domain":"paradigm.xyz","title":"Open Sourcing Centaur: Multiplayer, self-hosted, secure agents","text":"Open Sourcing Centaur: Multiplayer, self-hosted, secure agents Today we’re open sourcing Centaur, the self-hosted runtime from Paradigm and Tempo for multiplayer, secure AI agents. We have been using Centaur since January and it has transformed how we work across a wide spectrum of tasks including investing, engineering, design, recruiting, events, customer support and more.Centaur is a shared agent that can use tools, run for hours or days, survive restarts, and operate with real credentials without ever seeing the raw secrets. You can talk to it in Slack or over an API. You can add a tool once and every agent can use it. You can drop in a workflow once and the whole organization gets that capability immediately. At the end of every day, it reflects on how it did and self improves.Beyond open sourcing the code, and template repositories for extending and operating Centaur, we also deep dive on the architecture of the system, the interfaces between services, the security boundaries, and the execution model. Those are the pieces we think are worth copying, adapting, and reimplementing. Let’s dive in.The problem with personal agents.Most agent stacks are still built for one user on one machine. The moment you try to make a collaborative workflow, a different set of requirements appear:The agent has to continue working even after you close your laptop (we all know that person who walks around with an open laptop because their agent is still running).It has to be reachable where collaboration happens, e.g. in Slack.It has to survive crashes, deploys, disconnects, and partial failures.It must be safe enough to trust it with real systems without handing it raw API keys.It has to be observable and auditable for security review and optimization.Most systems solve parts of the above requirements. Some are good coding agents. Some are good browser agents. Some are good workflow engines. Few are designed as shared infrastructure for a team. And they all cost a lot, and lock you into a provider whose roadmap you’re downstream of.We think that organizations should be empowered to own their stack, move at the speed they need and use AI in collaborative not isolated settings. This is the gap Centaur is built for.How do I use Centaur?Think of Centaur as a virtual employee. The Slack thread is the interface. You tag Centaur like you would any other employee, and Centaur replies. Depending on the task, Centaur will run for seconds, minutes or hours+, and will invoke a series of integrated SKILL.md’s or tools. It knows which Slack thread it’s summoned in, and reliably replies on that relevant topic and ask, instead of assembling random context from all over your knowledge bases.\nCentaur out of the box can interact with spreadsheets, docs, slide decks, docsends, PDFs, and any other kind of file attachment you can think about. It can search Slack, the web, use Github, generate images and charts, create or update Google Docs, Slides and/or Sheets, interactive demos and more.The Centaur codebase is still relatively young and we continue to work through enhancements and improvements. But it really is incredible to experience, and we think it's transformed how our organization functions. We strongly recommend creating a company-wide #ai-agent Slack channel where you invite everyone to join. In that channel it’s important that:Leaders of the firm use it, and lead by example.People are empowered to ask questions without fear of looking dumb.People that are more AI-fluent nudge other people in existing threads on “Here’s how you could’ve used AI to get unblocked”.How does Centaur work?We tried to be thoughtful about two things, in particular, when designing Centaur:One Slack thread = one isolated agent session. When you tag Centaur in a thread, the system assigns a dedicated sandbox container to that conversation. Inside the container, a full Linux environment runs the AI harness of your choice: Amp, Claude Code, Codex, or any CLI-based agent. The container has Node.js, Python, Rust, and git pre-installed, so the agent can git clone, cargo build, run tests, and write real code in a real environment.Every session has access to organization-wide tools and skills. Agents love data, so if you give them connections and tools they’ll figure out how to do what you want them to do. A tool is a small Python class that wraps an API e.g. Slack, GitHub, Google Sheets. Drop the file in tools/, and every agent can call it immediately. Skills work the same way: a SKILL.md file that teaches the agent a workflow or set of instructions, available to every conversation the moment it's added.Under the hood, Centaur is a service-based architecture where all state lives in Postgres and every service is stateless. This means the system survives restarts, deploys, and crashes without losing work. Here’s how every component talks to each other: \nHere’s a deep dive of each of the services:Slackbot: A thin Next.js webhook listener. When someone tags Centaur in Slack, the slackbot receives the event and calls the API's durable protocol: spawn a runtime, persist the message, and execute the turn.API: The FastAPI control plane that orchestrates everything. It manages the lifecycle of agent sessions (spawn → message → execute), serves auto-generated REST endpoints for every tool plugin, runs the durable workflow engine, and streams execution events back to clients. The durable workflow engine is heavily inspired by Absurd, more below.Postgres: The single source of truth. Thread assignments, execution state, workflow checkpoints, API keys, audit logs, everything durable lives here. Because every service is stateless, you can restart any service without losing context.Sandbox: Each conversation gets its own sandboxed container on an internal-only network. The agent runs inside this container and calls back to the API for tool access over REST. Containers can be resource-limited and host filesystems are mounted read-only. A warm pool of pre-spawned containers eliminates cold-start latency.Firewall: An iron-proxy pod sits between each sandbox and the outside world. The agent or the user never holds real API keys. Instead, the proxy intercepts all egress traffic and, given the traffic doesn’t violate any firewall rules, injects the correct credentials in-flight, matched to the target host and source tool. A request using the Linear tool to api.linear.app gets the Linear key, while using gsuite injects the Google OAuth credentials.Observability: Every service writes structured JSON logs to stdout. We empower users to choose their own observability stack and write tools for Centaur to discover its own metrics, logs and traces. By default, Centaur ships with tools for VictoriaLogs/VictoriaMetrics.Company specific overlaysExtensibility is a first class citizen in Centaur - each company (including Tempo and Paradigm) uses different tools, stores data in different sources and has company-specific knowledge that can be distilled into skills.  The framework supports “overlaying” - mounting a Docker image on top of the core Centaur services and providing the API/sandboxes access to tools, skills, and workflows specifically built for you.Shared SkillsSkills are Markdown files (.agents/skills/*/SKILL.md) that teach the agent how to perform a specific task, e.g. a recruiting pipeline, a compliance check, a QA workflow. Add a skill file, and every agent session inherits that knowledge. This is already well established in teams but instead of having skills passed around, you just add your skill to Centaur’s .agent/skills directory and your whole team gets access to it.Extensible ToolsTools are the simplest extension point. A tool is a Python class in a directory with a client.py and a pyproject.toml. The API auto-discovers it on startup, generates REST endpoints at /tools/{name}/{method}, and hot-reloads on file changes. Here’s an example of a tool:Python # tools/my-tool/client.py — this is the entire file\nimport httpx\n\nclass MyToolClient:\n def search(self, query: str, limit: int = 10) -> dict:\n \"\"\"Search for something.\"\"\"\n return httpx.get(f\"https://api.example.com/search?q={query}&limit={limit}\").json()\n\ndef _client():\n return MyToolClient() Drop that file in tools/my-tool/, and within seconds every agent conversation in your organization can call it. The tool declares which API hosts and secret keys it needs in its pyproject.toml so that the firewall can handle credential injection.Extensible WorkflowsA workflow is a single Python file that exports a name and a handler function. Drop it in workflows/, and it's available via cron, triggerable via API, or composable with other workflows.\nPython # workflows/daily_digest.py — drop this file in and it's live\nWORKFLOW_NAME = \"daily_digest\"\n\nasync def handler(inp, ctx):\n data = await ctx.step(\"fetch\", lambda: fetch_metrics())\n await ctx.sleep(\"wait\", timedelta(hours=24))\n await ctx.run_agent(\"summarize\", text=f\"Summarize: {data}\") The workflow engine checkpoints every step to Postgres. If the process crashes mid-workflow, it resumes exactly where it left off, no duplicate work, no lost state. Sleeping for 24 hours between steps costs nothing; the workflow suspends and the engine wakes it up when it's time. For the observant reader, this is a Durable Workflow pattern that is increasing in popularity. This design was inspired by Absurd’s Postgres-driven architecture.How secure is Centaur?Most agent frameworks handle secrets the same way you would on your laptop: dump API keys into environment variables and hope the agent doesn't leak them. This works for personal use. It doesn't work when you're handing an agent credentials to your company's Slack, GitHub, cloud infrastructure, and financial systems.Centaur takes a different approach: The agent never holds your secrets. Not in environment variables, not on disk, not in memory. Instead, credentials exist only inside an isolated secrets manager, and a network-level firewall injects them into outbound requests in-flight, after the request leaves the sandbox, before it hits the external API.Here's what that looks like concretely:A tool declares in its pyproject.toml that it needs, say, SLACK_BOT_TOKEN and talks to api.slack.com.On sandbox startup, the Iron proxy builds a mapping: api.slack.com to SLACK_BOT_TOKEN.When the agent calls Slack, the request passes through the firewall. The firewall sees the target host, looks up the correct secret from your secrets manager, and injects it into the request header.The agent sees a successful response, but never saw the token.This means a compromised agent or a prompt injection attack cannot exfiltrate your credentials. It can make authenticated requests through the proxy (it has to, that's how it works), but it cannot extract the raw key values, send them to a different host, or smuggle them out in a response.This security is enforced through network policies, such that no container can access:The secret service directlyThe web without first going through the firewall.This means that all secrets are protected, and every request on the way out and back in goes through the firewall. In addition to that, every outbound request from every sandbox is logged by the firewall and response bodies from LLM APIs are scanned for leaked secret values and redacted in real-time. This level of observability enables us to detect leaks and malfunctions quickly and fix them even quicker, letting Centaur be its own AI SRE.What’s next for Centaur?Centaur's architecture deliberately separates a small, auditable core from a wide-open extension surface:Kernel: The core (the API, the firewall, the secrets manager)Userspace: Tools, workflows, and skills.This separation is what let us recently introduce self-improvement via nightly reflection: The agent reviews its own performance, identifies gaps, and ships fixes to its own skills and tools without touching the kernel. We can let the system evolve itself because the blast radius is structurally bounded.Today's release is the kernel we've been running in production at Paradigm and Tempo since January. Next up is making the userspace more powerful. We think workflows will evolve into full application containers, i.e. long-running services that leverage the rest of the system for tool access, secrets, and observability, but run their own logic.You can extend Centaur’s userspace with your own tools and workflows without having to fork the repository. See our docs here.Centaur is open source under Apache 2.0. It has transformed how we work, and we hope it does the same for you. Get started: https://centaur.run. If you're a cracked AI engineer and want to help maintain and evolve Centaur in the open or work on Paradigm's proprietary AI tooling, reach out to georgios@paradigm.xyz.","tokens":3200,"squid":"spider-04","role":"Research Spider","at":1791342044570,"hash":"56c4fba5fd5f058058e8fe4c8643a57f07ce19b2"}
{"url":"https://akash.network/roadmap/aep-8","domain":"akash.network","title":"Mainnet 1: Security","text":"Akash Network Roadmap Roadmap 2020 Q3 aep-8 Mainnet 1: Security Final Summary\nMainnet release with security, liquidity, and decentralization.\nMotivation\nAkash is a decentralized marketplace for cloud computing resources. Its blockchain, built on Cosmos SDK and Tendermint, enables users to deploy and manage their own cloud resources. As one of the first applications for Inter-Blockchain Communication (IBC), Akash Network forms the foundation for this decentralized cloud computing platform.\nTo ensure Akash’s success, we must first establish a secure, scalable, and decentralized blockchain foundation. This requires a diverse set of professional validators before enabling compute trading. We propose launching the blockchain to achieve adequate security and decentralization, preventing potential issues that could erode user trust in the network.\nMainnet 1\nCore to Akash’s platform is a token economic model that uses a native currency, Akash Token (AKT), to solve for volatility (one of the biggest challenges for adoption in crypto), while ensuring economic security of the platform’s public blockchain.\nThe model bootstraps early supply by using inflation as a subsidy, and activates an incentive structure that unlocks network effects to accelerate growth.\nIn order to properly compensate providers on the network (providers are users contributing cloud compute to the network e.g. datacenters), AKT must first have economic value. Launching a mainnet and stabilizing the staking set is the first step in establishing economic value.\nAkash Mainnet 1 is the launch of the Akash DeCloud and the true beginning of network governance. Akash Mainnet 1 (based on the Launchpad release) enables basic staking and governance operations, including the ability to delegate to validators and vote on governance proposals.\nWe propose launching Mainnet with 64 validators to establish economic value and to stabilize the staking set. AKT holders will then vote to enable the decentralized cloud modules after the Phase 3 Testnet.\nGenesis Configuration and Token Distribution\nToken distribution is critical to the success of Akash, propose the genesis.json to bootstrap the network. Chain identifier will be akashnet-1.\nLiquidity\nLiquidity is critical to Proof-of-Stake (PoS) chains, as the security of the blockchain relies on the economic value staked to secure the chain. We propose using an exchange to bootstrap liquidity.\nAnnoucements\n\nAnnouncing Akash Mainnet Live and Bitmax IEO\nAkash DeCloud Mainnet Overview\n\nCopyright\nAll content herein is licensed under Apache 2.0. Completion date: 9/25/2020 Created: 3/10/2020 Last Updated: Category: Core Status: Final Authors: Greg Osuri Adam Bozanich \nView next aep\n Mainnet 2: DCX PlatformCompletion Date: 2/16/2021Akash's codebase is production-ready after testnet, with minor issues resolved. The team is updating to the final Stargate version of Cosmos-SDK, planning a mainnet upgrade for decentralized cloud and IBC integration. Akash Network will be an early IBC adopter. Significant changes in Stargate require coordination with partners for upgrades and testing, despite previous collaboration on CosmosHub testnets.","tokens":793,"squid":"spider-03","role":"Compute Spider","at":1791342045999,"hash":"e6fb9e76a81103df480f4ccab3f850b575af9ea7"}
{"url":"https://developer.arbitrum.io/run-a-node/run-local-full-chain-simulation","domain":"developer.arbitrum.io","title":"How to run a local full chain simulation","text":"How to run a local full chain simulationThis page provides instructions for setting up a complete local development environment for testing Arbitrum contracts in a fully simulated environment.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 , 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 of the nitro-testnode repo.\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 chain can be deployed on top of the (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 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.\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/relayerHow is this guide?Assign node rolesUnderstand how a Nitro node's role (RPC node, archive node, sequencer, batch poster, validator — optionally with split validation — or feed relay) is set by configuration flags, and how to convert a node from one role to another.Run a local dev nodeThis page provides instructions for setting up and running a local Nitro dev node for contract testing and development.","tokens":1576,"squid":"spider-01","role":"Chain Spider","at":1791342054105,"hash":"927bb4eee601f3c535bcab94e2ca7a73e43fe570"}
{"url":"https://www.paradigm.xyz/writing/pacts-protecting-your-bitcoin-from-a-quantum-sunset","domain":"paradigm.xyz","title":"PACTs: Protecting Your Bitcoin From a Quantum Sunset","text":"PACTs: Protecting Your Bitcoin From a Quantum Sunset An attacker with a powerful enough quantum computer could steal hundreds of billions of dollars of Bitcoin.To prevent that, the Bitcoin community may someday choose to upgrade the protocol to sunset the ability to spend from addresses with exposed public keys.Such an upgrade would be controversial, in part because Bitcoin values the rights of dormant holders—including Satoshi Nakamoto himself, who is estimated to hold around $75 billion of Bitcoin in vulnerable addresses—to remain inactive onchain.If an upgrade sunsets support for those addresses, these dormant holders will be forced to publicly move their coins or let them be frozen. But if quantum computers are coming and we don’t sunset those addresses, those holders will be forced to move those coins or let them be stolen. Either path seems to force long-time holders to give up some of their privacy by publicly moving their funds.This post proposes a way out of that dilemma, by letting Bitcoin holders protect themselves from any eventual sunset costlessly and silently, without having to publicly move their coins.The key is that holders can use Bitcoin itself to secretly timestamp their knowledge of their private keys. A future protocol upgrade could then accept zero-knowledge proofs of these Provable Address-Control Timestamps (PACTs) as an alternative path for spending from a sunsetted address.This protocol could protect the privacy and security of existing Bitcoin holders better than the alternatives. And adopting a standard for these proofs now would help give holders as much time as possible to secure their coins against an emergency sunset, while allowing us to leave the more difficult decisions—including whether a sunset is necessary or desirable—until later.BackgroundRecent advances raise the question of whether cryptographically relevant quantum computers (CRQCs) could come sooner than most people had hoped.There are many difficult questions about quantum preparedness going forward, but the elephant in the room is what to do about the hundreds of billions of dollars of Bitcoin stored in addresses with exposed public keys, and thus vulnerable to theft by CRQCs.The Bitcoin community has been divided on what to do about this risk. Neha Narula recently wrote a helpful summary of the debate.Doing NothingThe default path is to do nothing. This will prove to be the right one if cryptographically relevant quantum computers never arrive, which is a legitimate reason to hold off on the most extreme measures. The rest of this post addresses the other possible worlds—in which we someday hit a point where CRQCs are clearly inevitable, and need to decide whether to undergo an emergency fork.If CRQCs do arrive before the protocol upgrades, then up to hundreds of billions of dollars of Bitcoin might end up in the hands of attackers. Even if the Bitcoin community were willing to stomach the theft and its effect on the market, the quantities involved would be geopolitically significant, and—particularly if the attacker was a criminal or a hostile nation-state—it could lead to a cataclysmic regulatory blowback on Bitcoin.SunsetAnother option is a soft fork that eventually sunsets the ability to spend from addresses with exposed public keys, as proposed in the draft of BIP-361.This path is controversial because it violates an important principle—that people should be able to leave their Bitcoin in cold storage for decades without fear of losing access. But in the scenario where CRQCs are imminent, there is no path where holders who are entirely offline can be assured of keeping their Bitcoin, because their funds are at risk of theft.However, a sunset poses some significant inconvenience on holders:First, it would force offline holders to move their coins, which is an expensive and public onchain action. They would have to pay fees, reveal that they are still active, and potentially leak other information about themselves, such as timing patterns, links between their wallets, and even their IP address. For an early holder like Satoshi, this would be a massive revelation—they would have to tell the world that they are alive and still in possession of their keys.Second, there may only be a limited amount of time for an upgrade. Bitcoin does not yet support post-quantum addresses, and may not adopt them until the quantum threat is clearer. If progress on quantum computers is fast enough, we may end up in a situation where the gap between post-quantum addresses being supported and being mandated is uncomfortably brief.Rescue ProtocolsFor the above reasons, it is likely that many holders will fail to upgrade before the sunset date. Will there be a way for them to prove to the protocol that they are the rightful owners of their addresses?For some addresses, the answer is already yes. For example, if a private key was derived from a parent key (as in the BIP-32 standard), the holder may be able to provide a zero-knowledge proof that they knew that parent key, which is something a quantum attacker could not have. This kind of “rescue protocol” is discussed in BIP-361, and a prototype prover has even been implemented. There may even be ways to delay the implementation of the specific rescue rules until a subsequent fork.The Satoshi ProblemThose are promising escape hatches, but they can’t save the earliest Bitcoin addresses.There are millions of bitcoins that have exposed public keys and predate BIP-32 (and which therefore could not be rescued using the above path). Most notoriously, wallets believed to belong to Satoshi Nakamoto hold around 1.1 million BTC, worth over $75 billion today.This post describes an escape hatch for sunsetting that can potentially provide the best achievable protection for those offline holders—a self-protective measure they could take today, with no changes to Bitcoin and no onchain action, in a way that could maintain their ability to spend after a sunset while still achieving the safety sunsetting would provide from a quantum attacker.PACTsSuppose we’re in the year 2040, and Satoshi has decided to fund his retirement by finally selling some of his Bitcoin. Cryptographically relevant quantum computers arrived in 2030, and deriving Satoshi’s private keys is now a standard homework assignment for MIT freshmen. Luckily for Satoshi, the protocol sunsetted the ability to spend from ECDSA keys in an emergency soft fork in 2029. 1Satoshi wants to prove, in a post-quantum and algorithmically verifiable way, that he knew his private key before CRQCs could derive it. What can he do?If he has to generate that proof from scratch today, he is out of luck. Since everyone now knows his private keys, and since he didn’t derive them using BIP-32 or any other deterministic scheme, the keys don’t give him any asymmetric private information he can use for a cryptographic proof.However, if he can cryptographically prove that he knew those keys before CRQCs could have derived them, then the protocol could let him take the coins. If he had the foresight back in 2026, he could have used a cryptographic timestamping service to timestamp a signature, establishing that he knew the private key before CRQCs existed.Conveniently, he had already invented a trustless way to timestamp proofs of knowledge back in 2008. The Bitcoin whitepaper described the Bitcoin network as a “distributed timestamp server.” Developers have long recognized that while it was primarily designed for timestamping transactions, it could easily be used to timestamp any hash—and that since hashes can be aggregated efficiently, it is cheap to run a service that provides such timestamps for free. OpenTimestamps is an open-source protocol that allows anyone to timestamp arbitrary hashes on the Bitcoin blockchain, by including them in a Merkle tree within an OP_RETURN output.If Satoshi had timestamped a salted commitment to a standardized address-control proof before CRQCs using OpenTimestamps, then he could provide a post-quantum-secure STARK proof of that timestamp to the Bitcoin protocol.A Provable Address-Control Timestamp, or PACT, is just such a timestamped commitment.Step 1: CommitThe below description is an illustrative example of how the PACT protocol could be designed, rather than a formal proposal. It will require significant input from experts and the community, and feedback is encouraged.To create a PACT, the holder generates a 256-bit secret salt and uses BIP-322 full message signing to prove control of the scriptPubKey for the vulnerable unspent transaction output (UTXO).The BIP-322 message should commit to the PACT purpose, Bitcoin network, vulnerable scriptPubKey, and salt:Python PACT/v1: Bitcoin quantum-sunset proof of address control\nnetwork=bitcoin-mainnet\nscriptPubKey=<the vulnerable output scriptPubKey>\nsalt=<32 random bytes> Let:Python salt = random(32 bytes)\nmsg = Encode(\"PACT/v1\", \"bitcoin-mainnet\", scriptPubKey, salt)\ncontrol_proof = BIP322_FULL_SIGN(scriptPubKey, msg)\ncommitment = SHA256(\"PACT/v1 commitment\" || salt || SHA256(control_proof)) The holder then timestamps commitment using OpenTimestamps. They store the salt, the BIP-322 control proof, and the OTS proof file in a secure location.This requires no Bitcoin transaction by the holder and is off-chain. The timestamp reveals nothing about the control proof, salt, public key, address, or which coins the holder owns, though privacy-conscious holders should still protect network metadata when interacting with timestamping services.Step 2: RescueIf Bitcoin later sunsets spending from UTXOs with exposed public keys, that fork could also define a rescue protocol for PACTs.To spend a sunsetted UTXO, the claimant would provide a post-quantum-secure proof (such as a STARK) that:they know a secret salt and a BIP-322 full message proof (control_proof);SHA256(\"PACT/v1 commitment\" || salt || SHA256(control_proof)) equals a commitment timestamped before the PACT cutoff, where that cutoff is set before CRQCs are believed to be able to derive private keys from exposed public keys;control_proof is a valid BIP-322 full message proof for the scriptPubKey controlling the frozen UTXO over the PACT message containing that salt;the rescue proof is bound to the specific rescue transaction, so it cannot be copied and reused to redirect the coins.The salt and BIP-322 control proof themselves would not be revealed. The timestamp proves that the holder had the ability to produce that control proof before the cutoff. The transaction binding proves that the holder is authorizing this particular rescue spend.At a high level, the eventual consensus proof would need to show a complete anchor chain: the hidden salt and BIP-322 control proof hash to the public PACT commitment; the OpenTimestamps attestation carries that commitment through its hash operations into a calendar Merkle root; that root appears in an OP_RETURN output of a Bitcoin transaction; the transaction is included in a block by a transaction Merkle proof; and that block is recognized by the rescue rules as part of the active Bitcoin chain before the PACT cutoff. A practical design would have to specify how the proof, which is verified in the context of a transaction, is anchored to the history of the chain (likely via a recent block hash).This does not require Bitcoin to decide today whether a sunset is necessary. It only gives holders a silent, no-onchain-cost way to preserve evidence that may become useful if such a sunset is ever adopted.BenefitsNo fork required today. Holders don’t have to wait for Bitcoin to adopt quantum-secure addresses or to decide what to do about insecure UTXOs. As soon as we agree on a standardized format for PACTs, holders can begin timestamping them.Note that while the commitment protocol for PACTs is relatively simple and makes use of well-established primitives like OpenTimestamps, the protocol for eventually verifying them will not be. Verifying a STARK to allow spending from sunsetted UTXOs will require substantial new plumbing in the Bitcoin protocol.Silent. Nobody other than the holder knows that the holder made the commitment. Even when the holder spends the coin, they may not have to reveal when they timestamped it—the protocol could require only a zero-knowledge proof that it was early enough.No onchain cost to commit. OpenTimestamps is free to use and can batch many commitments into a single Bitcoin transaction.Low risk. While the protocol requires the holder to produce a BIP-322 control proof with their key—which poses some risk—neither the proof nor the salt is broadcast or shared with OpenTimestamps; only an opaque commitment is revealed. The holder does, however, need to protect the salt, proof, and OTS file as a recovery artifact.Risks and DownsidesThe holder has no guarantee that this rescue hatch will ever be implemented. It is possible that Bitcoin will never sunset quantum-unsafe keys (either because CRQCs never arrive, or because Bitcoin decides to bite the bullet on them). Even if it does, it may not implement this specific rescue path. A holder should not solely rely on PACTs for protection until the rescue protocol is adopted into the protocol. But given the low cost of making the commitment, it might still be worth it for a long-term holder to create a PACT as soon as a standard is agreed-upon.Not universal. While this protocol should work for many single-key wallets and can be generalized using a BIP-322-style proof format, multisig, complex scripts, custodial wallets, and hardware-wallet support would need careful standardization. Additionally, PACTs assume that the ability to produce a valid BIP-322 proof on a very specific message corresponds to the ability to control the coin. That is the same practical assumption behind message-signing proofs, but as discussed in BIP-322, the power to sign messages from an address is not necessarily identical to the power to sign transactions from that address.Prior WorkJeremy Rubin has proposed a similar design on the Delving Bitcoin forum.ConclusionCryptographically relevant quantum computing may not threaten Bitcoin for a long time, or it might never happen. Users might never need to do anything.But Bitcoin is about preparing for the long term, hedging for tail risks, and self-reliance. If there is a way to plant a seed now that will give us an advantage over cryptographic attackers in a possible future, then long-term holders should take it. And protocol developers should think about the privacy interests of large, long-term, dormant holders—including, possibly, the very largest, longest-term, and most dormant holder—when deciding how to implement a possible quantum sunset.Acknowledgments: Eli Ben-Sasson, Avihu Levy, Abdelhamid Bakhta, Jameson Lopp, Neha Narula, Nic Carter, Arjun Balaji.","tokens":3708,"squid":"spider-04","role":"Research Spider","at":1791342054465,"hash":"0cca6f373eeaca0847ce81e20655eef6304f678d"}
{"url":"https://developer.arbitrum.io/run-a-node/overview","domain":"developer.arbitrum.io","title":"Arbitrum nodes: an overview","text":"Arbitrum nodes: an overviewLearn more about what types of Arbitrum nodes are available to run.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 . There are distinct advantages to running an . 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 — , , , or —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.How is this guide?Arbitrum node runnersArbitrum node runners documentationNitro support policyLearn the details of the support policy for Nitro.","tokens":1194,"squid":"spider-01","role":"Chain Spider","at":1791342064085,"hash":"be53e3a1e35e44f1e8df069677a85e745094a057"}
{"url":"https://akash.network/roadmap/aep-3","domain":"akash.network","title":"Stack Definition Language Specification","text":"Akash Network Roadmap Roadmap 2018 Q3 aep-3 Stack Definition Language Specification Final Summary\nStack Definition Language\nSpecification\nDeployment services, datacenters, pricing, etc.. are described by a YAML configuration file. Configuration files may end in .yml or .yaml.\nA complete deployment has the following sections:\n\nversion\nservices\nprofiles\ndeployment\n\nA full example deployment configuration can be found here.\nversion\nIndicates version of Akash configuration file. Currently only \"1.0\" is accepted.\nservices\nThe top-level services entry contains a map of workloads to be ran on the Akash deployment. Each key is a service name; values are a map containing the following keys:\n\nNameRequiredMeaningimageYesDocker image of the containerdepends-onNoList of services which must be brought up before the current serviceargsNoArguments to use when executing the containerenvNoEnvironment variables to set in running containerexposeNoEntities allowed to connec to to the services. See services.expose.\nservices.expose\nexpose is a list describing what can connect to the service. Each entry is a map containing one or more of the following fields:\n\nNameRequiredMeaningportYesContainer port to exposeasNoPort number to expose the container port asacceptNoList of hosts to accept connections forprotoNoProtocol type (tcp,http, or https)toNoList of entities allowed to connect. See services.expose.to\nThe port value governs the default proto value as follows:\n\nportproto default80http443httpsall otherstcp\nservices.expose.to\nexpose.to is a list of clients to accept connections from. Each item is a map with one or more of the following entries:\n\nNameValueDefaultDescriptionserviceA service in this deploymentAllow the given service to connectglobaltrue or falsefalseIf true, allow connections from outside of the datacenter\nIf no service is given and global is true, any client can connect from anywhere (web servers typically want this).\nIf a service name is given and global is false, only the services in the current datacenter can connect.\nIf a service name is given and global is true, services in other datacenters for this deployment can connect.\nIf global is false then a service name must be given.\nprofiles\nThe profiles section contains named compute and placement profiles to be used in the deployment.\nprofiles.compute\nprofiles.compute is map of named compute profiles. Each profile specifies compute resources to be leased for each service instance\nuses uses the profile.\nExample:\nThis defines a profile named web having resource requirements of 2 vCPUs, 2 gigabytes of memory, and 5 gigabytes of storage space available.\nweb: cpu: 2 memory: \"2Gi\" storage: \"5Gi\"\ncpu units represent a vCPU share and can be fractional. When no suffix is present the value represents\na fraction of a whole CPU share. With a m suffix, the value represnts the number of milli-CPU shares (1/1000 of a CPU share).\nExample:\n\nValueCPU-Share110.51/2\"100m\"1/10\"50m\"1/20\nmemory, storage units are described in bytes. The following suffixes are allowed for simplification:\n\nSuffixValuek1000Ki1024M1000^2Mi1024^2G1000^3Gi1024^3T1000^4Ti1024^4P1000^5Pi1024^5E1000^6Ei1024^6\nprofiles.placement\nprofiles.placement is map of named datacenter profiles. Each profile specifies required datacenter attributes and pricing\nconfiguration for each compute profile that will be used within the datacenter.\nExample:\nwestcoast: attributes: region: us-west pricing: web: 8u db: 100u\nThis defines a profile named westcoast having required attributes {region=\"us-west\"}, and with a max price for\nthe web and db compute profiles of 8 and 15 micro (10^-6) tokens per block, respectively.\nPricing may be expressed in decimal or scientific notation for Akash units, or may be suffixed with mu,µ, or u to represent micro Akash.\nExamples:\n\nValueMicro Akash Tokens110000001e-410020u20\ndeployment\nThe deployment section defines how to deploy the services. It is a mapping of service name to deployment configuration.\nEach service to be deployed has an entry in the deployment. This entry is maps datacenter profiles to\ncompute profiles to create a final desired configuration for the resources required for the service.\nExample:\nweb: westcoast: profile: web count: 20\nThis says that the 20 instances of the web service should be deployed to a datacenter matching the westcoast datacenter profile. Each instance will have\nthe resources defined in the web compute profile available to it.\nCopyright\nAll content herein is licensed under Apache 2.0. Completion date: 7/30/2018 Created: 3/18/2018 Last Updated: Category: Interface Status: Final Authors: Adam Bozanich Resolution: \nLink\n\nView next aep\n Testnet: AlphaCompletion Date: 2/5/2019Launch Testnet with a fully functioning spot computing marketplace for containers and serverless deployment platform as proposed in the AEP-2. Incentivize user adoption of by applying game mechanics.","tokens":1225,"squid":"spider-03","role":"Compute Spider","at":1791342067914,"hash":"bbe5cf69427b1ca972fe83a73476cbee3db5dced"}
{"url":"https://www.paradigm.xyz/writing/opportunity-markets","domain":"paradigm.xyz","title":"Opportunity Markets","text":"Opportunity Markets \n\n Your browser does not support the video tag.\n\n Animation by Dave Whyte\n\n IntroductionImagine you spot an unsigned band destined for massive success.Instead of cold-calling labels, what if you could bet on them yourself?This paper introduces opportunity markets: private prediction markets where those who find opportunities get paid by those who act on them.Music labels, research labs, and VCs all want to find the next big thing before the competition. But the people who first spot opportunities often have no institutional connections. Historically, there hasn’t been a clean way for these parties to find each other and transact.Prediction markets use skin in the game to distill signal from distributed participants. But for someone to make $1M betting XYZ will be huge, someone else needs to bet $1M it won’t. Nobody wants to bet against thousands of opportunities they’ve never even heard of.The natural counterparties for a market like this would be those who could act: labels, employers, funds, etc. But if they were to provide liquidity in a public prediction market, they’d just be subsidizing information their competitors could use just as easily.Opportunity markets address this problem by keeping market prices private from everyone but their sponsor.A label might provide $25,000 of liquidity against “We will sign artist XYZ in 2025,” providing $25,000 of dumb money scouts can win if they’re early. When the label sees the price going up, it’s an early signal to investigate the artist. Prices and positions only become public after an “opportunity window” of e.g. two weeks. It’s like a decentralized scout program where anyone in the world can get skin in the game.There are real challenges: traders operate blind without prices or position feedback for significant periods, and the self-dealing risks are obvious. Nevertheless, we think there is something interesting to unlock here, and the design space is Wide.IntuitionMotivationConsider a music fan who discovers an unsigned artist destined for stardom. The fan has valuable information but no record label. The labels that could sign the artist have no idea they exist. Or a researcher who recognizes that an obscure paper contains a breakthrough relevant to self-driving cars. They lack the resources to commercialize it, while companies spending billions on R&D miss it entirely.This pattern repeats across domains: shop owners spot trends before the major brands, local suppliers spot successful businesses before investors, fans identify athletic talent before it’s obvious.In each case, someone with deep contextual expertise close to where something exciting is happening has information that would be valuable to someone far away with resources to act on it. But there’s no mechanism to connect them. The person with information can’t monetize their insight, and the person with resources misses the opportunity.For this paper, we are focusing especially on opportunities that take significant resources both to evaluate and to act on, and have some competitive and time-limited nature to them, such that knowing about them before others who can act on them confers significant benefits.Existing MechanismsA scout program is one type of solution to the situation described above. They give selected individuals with contextual knowledge a small stake in opportunities they identify. But these programs are limited by trust requirements and evaluation costs. The institution cannot scale beyond its ability to vet both scouts and their recommendations.Prediction markets are one proven way to aggregate information from abroad and decentralized group of people. But, there’s an incentive problem: for someone to profit significantly by betting that an artist will succeed, others must lose an offsetting amount. It doesn’t make sense for a market maker to bet a large amount of money against the success of an artist they’ve never heard of. Even if institutions subsidized liquidity on these markets to benefit from the information, prediction markets as they are usually deployed today offer their information as a public good. Competitors could free-ride on the same signals, eliminating the advantage. This is the core leak opportunity markets seek to Address.MechanismExampleThis concept is easiest to explain by example. Imagine a record label that wants to take advantage of opportunity markets to create a decentralized scouting Program.They create a family of private prediction markets asking “Will we sign Artist X in 2025?” for any artist X. Anyone can create a new market for any artist not yet listed and add it to the family.The markets are private in the sense that only the sponsor knows the market price at any given time. We discuss some of the challenges involved with this below.The label acts as market maker, providing, say, up to $25,000 of liquidity per market. They could either promise to provide this amount of liquidity, or prove that they are by, for example, running an AMM in a TEE. This is the “dumb money” that scouts can win if they’re early. As scouts gain conviction in an opportunity, they buy more shares, driving the price up on the market. As prices for a given opportunity rise, the sponsor label will take notice and investigate the opportunity, potentially leading to a signing. If they do ultimately sign the artist, the shares will pay out, and the label has effectively paid a decentralized scouting incentive of up to $25,000.PrivacyFor opportunity markets to work, only the sponsor can see current prices. If traders could see their fills immediately, they could reconstruct market prices by Trading.But traders need to know their positions eventually. The solution is an opportunity window—perhaps two weeks—after which traders learn whether their orders filled. This gives sponsors time to investigate promising opportunities before the information becomes public.After the window closes, there are various design choices: reveal all prices and positions, reveal only positions to individual traders, have different rules for large versus small orders, etc. More sophisticated systems might allow sell-to-close or buy-to-close limit orders before positions are revealed, or even allow trading agents that operate without revealing current positions.Market Design DetailsLiquidity ProvisionMarkets could use either an automated market maker or order book. In either case, liquidity will likely be concentrated within certain bounds. For example, the sponsor might provide liquidity starting around 1% probability, below which the information isn’t useful, and stop providing above 30%, where additional market signal isn’t especially helpful.Unlimited Markets vs. First NFor most types of opportunities, like artist signings, there are only a limited number that the sponsor can act on in a given time period. Accordingly, if traders are willing to trust the label to pay out, they can simply promise to pay out on an unlimited number of markets for “Will we sign Artist X in 2025?” and ensure they are never providing so much liquidity across all markets that they won’t be able to pay out if they sign too many artists. For a more permissionless approach, markets can be fully collateralized using a “First N” structure. For example, markets of the form “Will XYZ be among the first 10 artists we sign in 2025?” would require collateralizing each market with 10x the max liquidity since only 10 of them can pay off.Limiting ExploitationSponsors have both special information about the market state at any given time, and special knowledge about their own process, which opens the risk of exploitative behavior such as hinting they will take advantage of opportunity X while aggressively selling into that market.It is challenging to address this from a mechanism design standpoint, and we largely have to rely on trust and reputational effects. At the end of the day, market participants will only participate in markets sponsored by a given sponsor if they prove to be fair over a period of time. Some guidelines sponsors might do well to follow include: - Committing never to actively sell into any of their own markets (although buying, or perhaps removing sell liquidity, is likely fine once they make the decision to sign or even investigate an opportunity) - Committing to use any profits from opportunity market trading either to refund traders who participated or as additional liquidity for future markets. Running opportunity markets in a TEE and sharing all trades once the market has resolved can also offer some transparency and mitigation.ConclusionWe’re excited to see how Opportunity Markets develop over time. If you’re interested in working on them or other information finance ideas, we’d love to hear from you.","tokens":2197,"squid":"spider-04","role":"Research Spider","at":1791342086250,"hash":"170cdfeecffe7f77d1a9c263eb0a9126f223301e"}
{"url":"https://across.to/blog/arc-on-across","domain":"across.to","title":"Arc on Across","text":"TL;DRArc is Circle's Layer 1, live on mainnet since September 16, 2026, with USDC as the gas token instead of a volatile native asset.Across has supported Arc since day one. Arc is chain 5042, with a SpokePool and MulticallHandler deployed and live on the Swap API.Across quotes USDC routes into Arc from seventeen chains, including Ethereum, Base, Arbitrum, Optimism, Polygon, Avalanche, BNB Chain, Linea, zkSync, Unichain, HyperEVM, and Monad. Routes out of Arc are live too.Fills land in roughly two seconds because relayers front their own capital on the destination and settle with the source chain afterward.The USDC that arrives is the balance that pays for gas on Arc, so there is no second token to go find.Bridge to Arc with AcrossEvery new chain hands you the same first problem. You arrive holding the asset you wanted and none of the token you need to move it. Arc deletes that problem by making them the same thing. Gas on Arc is USDC, so when you bridge USDC to Arc, the balance that lands is the balance that pays the fee on your next transaction. Across has been live on the chain since launch day, which makes the whole trip one hop with nothing to reconcile at the other end.Arc Runs on Dollars, Not a Volatile Gas TokenCircle launched Arc mainnet on September 16, 2026. It is an EVM Layer 1 built for payments, FX, and institutional settlement, running Malachite BFT consensus over a permissioned validator set that includes BlackRock, DTCC, ICE, Mastercard, and Visa. Finality is deterministic and sub-second, with no reorg risk. Circle has said the network moves to proof of stake in 2027.The design choice that matters most for anyone arriving from another chain is the gas token. Arc does not have one in the usual sense. Fees, native balances, and native transfers are all denominated in USDC.Arc exposes that USDC through two interfaces over a single balance. The native interface carries 18 decimals and handles gas accounting, msg.value, and native transfers, the way ETH behaves on Ethereum. The ERC-20 interface lives at 0x3600000000000000000000000000000000000000, carries the familiar 6 decimals, and handles application-level transfers and approvals. A precompile keeps the two in sync at a fixed 1e18 to 1e6 ratio. There is no wrapping step and no wrapped version to hold.For a user, that collapses two balances into one. For a developer porting a contract, it is a real assumption break: balanceOf truncates the last twelve decimals, so dust below 1e-6 USDC exists in the native balance and does not show up in an ERC-20 read. Circle's docs are direct about this, and it is worth handling before you ship.Arc also supports EURC and USYC natively, and Circle StableFX runs cross-currency settlement across roughly twenty additional local stablecoins on the chain.Across Was Live on Arc From Day OneArc is chain ID 5042 on Across. The SpokePool sits at 0x9b4A302A548c7e313c2b74C461db7b84d3074A84, with a MulticallHandler at 0xA07480456C4EbaD7626e4FdF4a180709E238547b, and the chain is live on the Across Swap API alongside the other supported networks.Across quotes USDC into Arc from seventeen origin chains. Ethereum, Base, Arbitrum, Optimism, Polygon, Avalanche, BNB Chain, Linea, zkSync, Unichain, World Chain, Ink, Soneium, HyperEVM, and Monad are all live routes, and the bridge runs in both directions: USDC out of Arc to Ethereum, Base, and the rest of the network is available from the same interface.Because the Swap API handles the origin-side swap, you do not have to be holding USDC to start. Bring ETH on Arbitrum or any other supported token, and Across swaps it on the origin chain and delivers USDC on Arc in one transaction.How to Bridge USDC to ArcOpen across.to/arc-bridge and connect your wallet.Pick your origin chain and the token you are sending. Across quotes the route and shows the output amount and fee before you sign.Confirm the deposit on the origin chain. You pay gas once, there.Watch the fill on Arc. Expect it in a few seconds.Fills Land Before the Source Chain FinalizesA conventional bridge waits for the origin chain to finalize before releasing anything on the destination. That wait is the whole delay, and on Ethereum it is measured in minutes.Across inverts the order. You submit an intent describing the outcome you want, and a relayer fills it on the destination chain using its own capital, immediately. Settlement happens afterward, on the protocol's schedule rather than yours. The Dataworker aggregates every fill into a single bundle, relayers are repaid roughly every 1.5 hours, and bundle proposals are posted with a bond and accepted unless a challenger disputes them. The UMA Optimistic Oracle on Ethereum secures that step. One honest actor is enough to reject a bad bundle.That architecture is why the number on Arc is two seconds rather than two minutes, and it is the same architecture that has moved more than $39 billion with no user funds ever lost.Builders Get the MulticallHandler on Arc TooThe MulticallHandler is deployed on Arc, which means a transfer into the chain can carry instructions with it. The destination SpokePool calls handleV3AcrossMessage() on the handler, and the handler executes your encoded calls atomically with the fill. Approve and deposit into a lending market, route the output to a different recipient, or hand the funds to your own contract, all inside the same transaction that brings them across.On Arc this composes unusually cleanly, because the token your user receives is also the token their next transaction spends. There is no gas top-up step to design around. Contract addresses and integration details are in the Across chains and contracts reference.There Is Already Somewhere to GoArc launched with more than 100 applications live. Aave and Morpho are running lending markets. Uniswap and 1inch handle spot. Robinhood, Dinari, and edgeX cover trading surfaces, and Circle StableFX provides the FX layer underneath. Exchanges including Coinbase, Binance, and Kraken support the chain, as do MetaMask, Phantom, Ledger, and Rainbow on the wallet side.Liquidity showing up on a new chain usually lags the chain itself by a quarter. Arc skipped that part, which is the argument for having a fast route in on the day it opened.On most chains you bridge one token and then go hunting for another before you can spend it. On Arc the dollar that arrives is the dollar that pays the fee, and Across puts it there in about two seconds.Related ArticlesSep 25, 2026The Best Crypto Bridges of 2026 12 MIN READ#ProductJul 6, 2026Bridge to Robinhood Chain with Across 2 MIN READ#ProductMar 18, 2026Across Is Live on Tempo at Mainnet Launch 3 MIN READ#ProductDec 22, 2025Bridge USDC Directly to Hyperliquid in Seconds, Only on Across Protocol 2 MIN READ#ProductJoin the Across community:","tokens":1701,"squid":"spider-09","role":"Bridge Spider","at":1791342095849,"hash":"95b1f0c531423af52842dad540161e718ca16359"}
{"url":"https://eips.ethereum.org/EIPS/eip-1052","domain":"eips.ethereum.org","title":"EIP-1052: EXTCODEHASH opcode","text":"🎉 Final\n\n Standards Track: Core\n\n EIP-1052: EXTCODEHASH opcode\n\n Authors\n Nick Johnson <arachnid@notdot.net>, Paweł Bylica <pawel@ethereum.org>\n\n Created\n 2018-05-02\n\n Requires\n\n EIP-161\n\n Abstract\n\nThis EIP specifies a new opcode, which returns the keccak256 hash of a contract’s code.\n\n Motivation\n\nMany contracts need to perform checks on a contract’s bytecode, but do not necessarily need the bytecode itself. For instance, a contract may want to check if another contract’s bytecode is one of a set of permitted implementations, or it may perform analyses on code and whitelist any contract with matching bytecode if the analysis passes.\n\nContracts can presently do this using the EXTCODECOPY (0x3c) opcode, but this is expensive, especially for large contracts, in cases where only the hash is required. As a result, we propose a new opcode, EXTCODEHASH, which returns the keccak256 hash of a contract’s bytecode.\n\n Specification\n\nA new opcode, EXTCODEHASH, is introduced, with number 0x3f. The EXTCODEHASH \ntakes one argument from the stack, zeros the first 96 bits \nand pushes to the stack the keccak256 hash of the code of the account \nat the address being the remaining 160 bits.\n\nIn case the account does not exist or is empty (as defined by EIP-161) 0 is pushed to the stack.\n\nIn case the account does not have code the keccak256 hash of empty data\n(i.e. c5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470)\nis pushed to the stack.\n\nThe gas cost of the EXTCODEHASH is 400.\n\n Rationale\n\nAs described in the motivation section, this opcode is widely useful, and saves \non wasted gas in many cases.\n\nThe gas cost is the same as the gas cost for the BALANCE opcode because the \nexecution of the EXTCODEHASH requires the same account lookup as in BALANCE.\n\nOnly the 20 last bytes of the argument are significant (the first 12 bytes are \nignored) similarly to the semantics of the BALANCE (0x31), EXTCODESIZE (0x3b) and \nEXTCODECOPY (0x3c).\n\nThe EXTCODEHASH distinguishes accounts without code and non-existing accounts.\nThis is consistent with the way accounts are represented in the state trie.\nThis also allows smart contracts to check whether an account exists.\n\n Backwards Compatibility\n\nThere are no backwards compatibility concerns.\n\n Test Cases\n\n The EXTCODEHASH of the account without code is c5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470\nwhat is the keccak256 hash of empty data.\n The EXTCODEHASH of non-existent account is 0.\n The EXTCODEHASH of a precompiled contract is either c5d246... or 0.\n If EXTCODEHASH of A is X, then EXTCODEHASH of A + 2**160 is X.\n The EXTCODEHASH of an account that selfdestructed in the current transaction.\n The EXTCODEHASH of an account that selfdestructed and later the selfdestruct has been reverted.\n The EXTCODEHASH of an account created in the current transaction.\n The EXTCODEHASH of an account that has been newly created and later the creation has been reverted.\n The EXTCODEHASH of an account that firstly does not exist and later is empty.\n The EXTCODEHASH of an empty account that is going to be cleared by the state clearing rule.\n\n Implementation\n\nTBD\n\n Copyright\n\nCopyright and related rights waived via CC0.\n\n Citation\n Please cite this document as:\n\n Nick Johnson <arachnid@notdot.net>, Paweł Bylica <pawel@ethereum.org>, \"EIP-1052: EXTCODEHASH opcode,\" Ethereum Improvement Proposals, no. 1052, May 2018. Available: https://eips.ethereum.org/EIPS/eip-1052.","tokens":864,"squid":"spider-05","role":"Spec Spider","at":1791342102137,"hash":"2733725636ee8ef83539b4e91d269e8615690aa4"}
{"url":"https://jup.ag/stocks/htz","domain":"jup.ag","title":"Hertz Global Holdings, Inc Common Stock (HTZ) Tokenized Stock Price on Solana","text":"Underlying price$2.11+17.99% todayStock statsMarket cap$638MPrevious close$1.79Open$1.81Day's range$1.80 – $2.1252-week range$1.45 – $8.18Volume43.7MAvg volume14.0MP/E ratio-About Hertz Global Holdings, Inc Common StockHertz Global Holdings Inc is engaged principally in the business of renting vehicles through its Hertz, Dollar and Thrifty brands. The company has two reportable segments: i) Americas RAC: Rental of vehicles, as well as sales of vehicles and value-added services, in the U.S., Canada, Latin America and the Caribbean, ii) International RAC: Rental of vehicles, as well as sales of vehicles and value-added services, in locations other than the U.S., Canada, Latin America and the Caribbean. The company maintains a substantial network of company-operated rental locations, a majority of which are in Europe, and has franchisees and partners that operate rental locations under brands. Geographical markets include North America, Europe, Pacific Asia, Middle East and Africa, and Latin America.TickerHTZAsset classEquityTokenized by2 issuersSectorConsumer DiscretionaryIndustryServices-Auto Rental & Leasing (no Drivers)Employees26,000Websitehertz.comHertz Global Holdings, Inc Common Stock FAQHTZ is Hertz Global Holdings, Inc Common Stock stock, issued on Solana as a token that tracks the listed share. Each issuer mints its own version, so Hertz Global Holdings, Inc Common Stock trades here as 2 tokens rather than one.Token prices are designed to track Hertz Global Holdings, Inc Common Stock's listed shares, but they can differ because of issuer terms, liquidity, market hours, and trading activity.Backpack and Ondo issue the tokenized Hertz Global Holdings, Inc Common Stock markets shown on Jupiter. Each issuer controls its own token and settlement terms.Trading availability depends on the issuer token and its market. Open an issuer's token page to check current liquidity and trading status.Use the Market swap on this page. Select the HTZ token in the swap to choose an issuer. Connect your wallet, choose the token you want to pay with, and enter an amount. Review the swap details before you submit, then confirm in your wallet when prompted. A swap requires an available trading route. Issuer terms and restrictions apply.Dividend treatment depends on the token issuer. A dividend paid on Hertz Global Holdings, Inc Common Stock's listed shares does not guarantee a cash payment to token holders. Review each issuer's terms for how dividends and other corporate actions are handled.Read Backpack's dividend and corporate action guideRead Ondo's corporate action policy","tokens":651,"squid":"spider-02","role":"Liquidity Spider","at":1791342104931,"hash":"218ed64f2b0939c651ccdabc24aa2bb39daa7319"}
{"url":"https://across.to/blog/the-best-crypto-bridges-of-2026","domain":"across.to","title":"The Best Crypto Bridges of 2026","text":"A comparison from a team that builds one of them.Search \"best crypto bridge\" and you will find a dozen ranked lists that mostly agree with each other. Across is usually near the top of them, so we have no complaints about the scoreboard, but since our product has evolved we’re taking a new look at the categories.Almost every one of those lists describes a market that stopped existing around 2024. They compare bridges as if they were interchangeable products competing on a single axis — how fast, how cheap — and they slot each one into a lane: this one is for L2s, that one is for Solana, this one is for size. Several of them describe Across as a fast, cheap way to move a few thousand dollars between Ethereum rollups. That was accurate. It is now about a third of what Across does.So this is our version of the list. We build one of the bridges on it, and we are going to tell you where we think we win. We are also going to tell you, specifically and by name, where you should use something else. Every claim below is either sourced or marked as ours to prove.First: \"bridge\" is no longer one categoryThe single most useful thing that happened to this market in the last two years is that it split into layers. Getting the layers straight resolves most of the arguments about which bridge is \"best,\" because the honest answer is usually that the two things being compared are not competitors.Rails are the primitives that actually move value between two chains. Circle's CCTP burns USDC on the source chain and mints it on the destination; canonical, no wrapper, no third-party liquidity. LayerZero OFT gives a token a single omnichain supply, which is how USDT0 and a long list of project tokens travel. Canonical bridges are the rollup's own escrow contract, slow but maximally trust-minimized. Paxos Labs' Amplify Transit converts between regulated stablecoins at a rate locked when you submit. Rails are not products you shop for. They are plumbing, and each is excellent at exactly one thing.Execution layers decide which rail a given transfer should take, front the capital so you do not wait for the rail to finalize, and hand you the asset. Across, Relay, and deBridge live here.Aggregators and apps — LI.FI and its Jumper app, Squid, Rango — sit on top, comparing execution layers per quote and presenting one button.New bridging categories including rails, execution layers and aggregatorsA list that ranks CCTP against Jumper is comparing a rail to a storefront. Keep the layers separate and the rest of this gets much easier.How we are judgingSix criteria. We picked them before we wrote the entries, and two of them are ones Across does not win.Time to usable funds. Not \"time to finality\", but time until the asset is in your wallet and spendable.Cost, and how cost behaves as size grows. A bridge that is cheap at $500 and ruinous at $500,000 is a different product than one that is flat.Maximum practical transfer size. Where does the quote start getting worse, and where does it stop being offered?Coverage. Chains, and just as importantly, assets. USDC coverage is table stakes; USDT, project tokens, and non-EVM are where lists diverge.Honesty threshold. How many parties have to stay honest for your money to be safe? One? A multisig quorum? A validator set?What arrives. Native asset or wrapper. Guaranteed output or a quote that can move.A note on numbers before we start. Every count in this piece moves. Where a project's own published figure differs materially from what its own public API or a neutral tracker returns, we give you both and say when we checked. That includes our own.The bridgesAcross — execution layer, intents over several railsBest for: EVM and Solana transfers where you want the fastest usable funds, and — this is the part that changed — large regulated-stablecoin movements where the fee should not scale with the size.Across takes a signed intent describing what you want, and a permissionless network of relayers competes to front you the destination asset immediately from their own capital. Settlement happens behind you, in batches. Because the relayer is racing a competitor rather than waiting for a rail to finalize, you get funds fast: Across publishes a 1.2-second average from confirmation to funds in your wallet, with most transfers landing in under two seconds. As of September 2026 we can report $40B+ moved and 5M users, across 22 chains.Here is what the older comparisons miss. Across is not a single-rail bridge any more, and which rail you travel depends on the asset and the route:Intent fills are the default, because they are usually the fastest.Circle's CCTP sits underneath USDC flow as the settlement and rebalancing layer, which is why USDC arrives as real USDC rather than a bridged stand-in.The OFT path carries USDT0 directly, burned on the origin chain, minted on the destination.Paxos Labs' Amplify Transit carries large regulated-stablecoin conversions.The size story changed in August. Through the Amplify Transit integration, Across now quotes single transfers up to $50 million into and out of Robinhood Chain, converting USDC to USDG in both directions. On those routes the rate is locked at submission, so the output is known before settlement, and the fee is fixed per route whether the transfer is $50,000 or $50 million. Robinhood Chain is the clearest illustration of why a second rail matters: it does not appear on Circle's CCTP supported-chains list, and its canonical withdrawal carries a challenge period of roughly seven days, so without Transit recycling inventory there is no fast path off it at size at all.Note the scoping, because it matters: the $50M ceiling, the locked rate and the fixed fee are properties of Transit routes into and out of Robinhood Chain, not of every Across route, and not yet of every stablecoin. On a standard intent route you get a quote upfront that reflects relayer competition and destination gas.Honesty threshold is the strongest structural argument for Across and the least discussed. Across settles optimistically, and our docs call the result a 1-of-N trust assumption: the system only requires a single honest actor to dispute an invalid proposal in order to stay secure. Anyone can be that actor: no permission, no seat, no stake in a validator set. Compare that to a bridge whose safety depends on a fixed key quorum staying uncompromised.Where it is weaker: chain count. 22 chains is not 60, and it is not 89. Across focuses on stablecoin-heavy chains with proven demand, so if your destination is an obscure or brand-new chain, Across may simply not be there, and a broader router will be. Non-EVM coverage is real but narrower than the EVM footprint: Solana, Hyperliquid and TRON are supported; most other non-EVM ecosystems are not.Relay — execution layer, solver networkBest for: the long tail of chains, and small transfers to places nobody else has gotten to yet.Relay runs a solver model with a similar user-facing shape to Across: a solver uses its own capital to complete the action on the destination chain, and reconciliation happens after, through an escrow, an oracle attestation and a hub ledger. Relay markets 85+ networks; its own public chains API returned about 60 mainnet chains when we checked on 2026-09-21, which is still comfortably more than we cover. It publishes a 99.9%+ fill success rate with sub-3-second median fills on supported routes, and a fast origin-chain refund when a fill fails: net of gas, not always in the asset you started with, and skipped entirely when the refund would cost more than it is worth.Credit where it is due: on chain coverage Relay is ahead of us and has been for a while. If you are moving a small amount to a chain that launched last month, Relay is often the only execution layer that quotes it at all.deBridge — execution layer, poolless order flowBest for: guaranteed-rate native transfers where you want no pooled liquidity in the settlement path.deBridge's genuinely good idea is DLN, its order-based layer, which holds no pooled liquidity: solvers fill from their own capital and the contracts act as pipes rather than pools. There is no honeypot to drain, which removes the specific failure mode behind a large share of historical bridge losses. Rates are guaranteed with no slippage and native assets are delivered. deBridge publishes a 1.96-second median settlement, and its docs describe typical end-to-end completion in under two minutes.Two points of precision, offered in the spirit of not wanting the same done to us. The poolless property is DLN's; deBridge's older dePort product still locks natives and mints synthetic deAssets, and neutral trackers still show a small TVL figure against the protocol. And the unlock messaging underneath DLN inherits the deBridge messaging protocol's multi-validator consensus, so the honest description of the honesty threshold is \"permissionless solvers for the fill, an elected validator set with a signature threshold for the unlock,\" not \"no trusted parties anywhere.\"deBridge publishes its own 2026 bridge guide, which ranks deBridge first. We are doing the same thing here, so we will not be precious about it, the poolless argument is a real architectural claim and worth reading, from them or from anyone.Stargate — rail plus front end, pooled liquidity and OFTBest for: USDT, and chain breadth.Stargate is the most prominent front door to LayerZero's OFT world. Its own docs put reachable chains at 89 and the LayerZero transfer API returns more than a hundred, though the number of chains where Stargate actually holds pooled liquidity is smaller: neutral trackers put that in the twenties to forties. Worth knowing which you are getting: on core chains a Stargate pool locks and unlocks the native asset, while on its newer \"Hydra\" chains you receive a backed representation rather than the native token. On breadth it is well ahead of us, and if your destination is one of the chains we do not cover, this is your route. Speed depends on the path: sub-second on its newer fast-swap routes, roughly twenty seconds on a fast source chain, up to a few minutes on a thin pooled route.One correction to the received wisdom, though, because it appears in most of the lists: USDT is no longer a weak spot for Across. USDT0 routes through the OFT path directly, burning on the origin chain and minting on the destination. It still carries a bridge fee like any crosschain transfer, quote it rather than assuming. Comparisons written a year ago will tell you to use Stargate for USDT by default. Quote both.Circle CCTP — railBest for: USDC when canonical correctness matters more than convenience.Burn on one side, mint on the other. No wrapper, no third-party liquidity, and no liquidity counterparty beyond Circle. CCTP V2 covers 30 mainnet chains, including Ethereum, Base, Arbitrum, Optimism, Polygon, Avalanche and Solana.The \"CCTP is slow\" line in most comparisons is out of date and worth unpicking, because it is the kind of thing we would want corrected about us. CCTP V2 has two modes. Standard Transfer waits for hard finality: about fifteen to nineteen minutes on Ethereum and its L2s, but about eight seconds on Polygon and Avalanche, where hard finality is already fast. Fast Transfer attests at soft finality instead and lands in roughly eight to twenty seconds depending on the source chain, for a fee of zero to thirteen basis points. Either way you are waiting on a Circle attestation; the difference is which finality it is issued against, not whether an attestation exists. For treasury operations with a compliance requirement to hold only canonically-minted USDC, that dependency is a feature.Two things to keep in view. The attestation service is a hard dependency with published rate limits and circuit breakers, and the attester quorum is two of two, both Circle's. And CCTP V1 is being retired: burn limits drop on 2026-10-31 and the contracts pause on 2026-12-01, so anything still on V1 needs to move.You can use CCTP directly. You can also get USDC through Across, where CCTP does the settlement and rebalancing underneath while a relayer fronts you the funds immediately, so you do not wait out the attestation at all.LI.FI, Squid, Rango — aggregatorsBest for: not having to read this article.Aggregators quote several execution layers per route and pick. LI.FI runs the Jumper app as its consumer front end, so treat those as one company rather than two options. Squid was incubated in the Axelar ecosystem and now runs its own stack. If you have no strong opinion, an aggregator is the correct default, and it is also the fairest referee in the market: an aggregator has no reason to prefer any of us except on the quote. We are comfortable being measured that way.The tableA comparison of popular crypto bridges ranked by time to funds, chains, max size, honesty threshold, etcAll figures checked 2026-09-21. Speeds are typical route observations, not guarantees. Verify current numbers before relying on them, see the last section.What actually changed about AcrossThree assumptions in the older comparisons are now wrong, and it is worth stating them plainly rather than hoping the table does the work.\"Across is single-rail by design.\" This was true in the past. Today, it is not. Intent fills are the default because they are the fast path, but USDC settles over CCTP underneath, USDT0 travels the OFT path, and large regulated-stablecoin conversion runs over Amplify Transit. The routing decision is the product.\"Across is for small, fast transfers.\" The $50M ceiling on Transit routes is a different order of magnitude, and the fee on those routes does not scale with size. The thing that makes Across good at $500 –competitive relayers racing to fill– is not the thing that makes it work at $50M. Those are separate rails serving separate flows, and the API picks between them without integrators changing anything.\"Across is EVM L2s.\" Solana, Hyperliquid, TRON, and Robinhood Chain since that chain's launch. Still 22 chains, not 89. But \"Ethereum and its rollups\" undersells it by a lot.Older descriptions of Across were likely true when they were written, but as we've evolved it's time for an update.Pick by the job, not the rankingMoving USDC between major EVM chains, want it now → Across, or any aggregator, which will probably route to us or Relay.Moving $1M+ in stablecoins into or out of Robinhood Chain → Across via Amplify Transit. Elsewhere, CCTP if you need canonical minting and can wait, or an intent route if you want it now.Moving USDT → quote both. USDT0 goes over the OFT path either way; Stargate wins on chains we do not reach.Destination is an obscure or very new chain → Relay, or an aggregator.You are a protocol treasury with a compliance mandate → Use Across, CCTP directly, or Amplify Transit for regulated stablecoin conversion. Speed is not your constraint, but Across will give you the best route possible.You want no pooled liquidity in the settlement path → deBridge's DLN.You are moving into Hyperliquid to trade → Across. The routing from HyperEVM into your HyperCore account is handled for you, so there is no second step to do yourself.Check the dataEverything above is verifiable, and you should verify it, including the parts that flatter us.Volume and route share: DefiLlama's bridge dashboards, and aggregator-level route-win data from LI.FI and Jumper; a neutral aggregator choosing between us on every quote is a better signal than anything either of us publishes.Security: OpenZeppelin's published Across audits, and our own security-model page for the 1-of-N argument.Chain counts: every project's own public API, not its marketing page. That is how we got the numbers in this piece, ours included, and it is why several of them are lower than the figures you will see elsewhere.Speed and cost: quote the same route on three of these at the same moment. It takes two minutes and beats any table, including ours.PeckShield counted fourteen bridge exploits totalling about $341 million in the first five months of 2026, and the total has grown since. The largest single one, in April, was not a broken quorum, it was a configuration with only one verifier in it, which an attacker worked around to make a bridge act on a message no chain had ever emitted. Cause and blame there are publicly disputed between the projects involved, so we will not adjudicate it. The point that survives the dispute is the one worth taking away: the honesty threshold is not an abstraction, and a low threshold on paper does nothing if the deployment sets it to one. When you evaluate any of the options above, ours included, ask how many parties have to stay honest, whether that number is enforced or merely configured, and treat every other number as secondary.Across is an execution layer for crosschain transfers, routing intents over a relayer network, Circle's CCTP, LayerZero's OFT path and Paxos Labs' Amplify Transit across 22 chains. $40B+ moved, no user funds lost to a protocol-level failure. across.toRelated ArticlesSep 21, 2026Arc on Across 5 MIN READ#ProductJul 6, 2026Bridge to Robinhood Chain with Across 2 MIN READ#ProductMar 18, 2026Across Is Live on Tempo at Mainnet Launch 3 MIN READ#ProductDec 22, 2025Bridge USDC Directly to Hyperliquid in Seconds, Only on Across Protocol 2 MIN READ#ProductJoin the Across community:","tokens":4342,"squid":"spider-09","role":"Bridge Spider","at":1791342117836,"hash":"5a375004a07fd35f30d970ebac88ced817af228d"}
{"url":"https://eips.ethereum.org/EIPS/eip-1108","domain":"eips.ethereum.org","title":"EIP-1108: Reduce alt_bn128 precompile gas costs","text":"🎉 Final\n\n Standards Track: Core\n\n EIP-1108: Reduce alt_bn128 precompile gas costs\n\n Authors\n Antonio Salazar Cardozo (@shadowfiend), Zachary Williamson (@zac-williamson)\n\n Created\n 2018-05-21\n\n Requires\n\n EIP-196, \n\n EIP-197\n\n Simple Summary\n\nThe elliptic curve arithmetic precompiles are currently overpriced. Re-pricing the precompiles would greatly assist a number of privacy solutions and scaling solutions on Ethereum.\n\n Abstract\n\nChanges in 2018 to the underlying library used by the official Go reference\nimplementation led to significant performance gains for the ECADD, ECMUL,\nand pairing check precompiled contracts on the alt_bn128 elliptic curve.\n\nIn the Parity client, field operations used by the precompile algorithms were optimized in 2018, \nand recent changes to the pairing algorithm used by the bn crate have brought considerable speedups.\n\nFaster operations on Ethereum clients should be reflected in reduced gas costs.\n\n Motivation\n\nRecently, the underlying library used by the official Go reference\nimplementation to implement the\nECADD (at address 0x06), ECMUL (at address 0x07), and pairing check (at\naddress 0x08) precompiled contracts was shifted to Cloudflare’s bn256\nlibrary. Based on the initial PR that\nintroduced this change,\nand corroborated in a later\nnote,\nthe computational cost of ECADD, ECMUL, and pairing checks (excepting the\nconstant) has dropped roughly an order of magnitude across the board.\n\nAlso, optimizations in the bn library in 2018 and 2019\nused by the Parity client led to a \nsignificant performance boost we \nbenchmarked \nand compared against the previous \nresults.\n\n Specification\n\nFollowing is a table with the current gas cost and new gas cost:\n\n Contract\n Address\n Current Gas Cost\n Updated Gas Cost\n\n ECADD\n 0x06\n 500[1]\n 150\n\n ECMUL\n 0x07\n 40 000[1]\n 6 000\n\n Pairing check\n 0x08\n 80 000 * k + 100 000[2]\n 34 000 * k + 45 000\n\nThe gas costs for ECADD and ECMUL are updates to the costs listed in\nEIP-196, while the gas costs for the pairing check are updates to the cost\nlisted in EIP-197. Updated gas costs have been adjusted to the less performant \nclient which is Parity, according to benchmarks[3].\n\nTo come up with these updates gas costs, the performance of the ecrecover precompile\nwas measured at 116 microseconds per ecrecover invocation. Assuming the ecrecover\ngas price is fair at 3,000 gas, we get a price of 25.86 gas per microsecond of a precompile\nalgorithm’s runtime. With this in mind, the pairing precompile took 3,037 microseconds to\ncompute 1 pairing, and 14,663 microseconds to compute 10 pairings. From this, the pairing\nalgorithm has a fixed ‘base’ run-time of 1,745 microseconds, plus 1,292 microseconds per\npairing. We can split the run-time into ‘fixed cost’ and ‘linear cost per pairing’\ncomponents because of the structure of the algorithm.\n\nThus using a ‘fair’ price of 25.86 gas per microsecond, we get a gas formula of\n~35,000 * k + 45,000 gas, where k is the number of pairings being computed. [4]\n\n[1]- Per EIP-196.\n\n[2]- Per EIP-197.\n\n[3]- Parity benchmarks.\n\n[4]- PR comment clarifying gas cost math.\n\n Rationale\n\n Existing protocols would benefit immensely from cheaper elliptic curve cryptography\n\nFast elliptic curve cryptography is a keystone of a growing number of protocols built on top of Ethereum. To list a few:\n\n The AZTEC protocol utilizes the elliptic curve precompiles to construct private tokens, with zero-knowledge transaction logic, via the ERC-1723 and ERC-1724 standard.\n Matter Labs utilizes the precompiles to implement Ignis, a scaling solution with a throughput of 500txns per second\n Rollup utilizes the precompiles to create L2 scaling solutions, where the correctness of transactions is guaranteed by main-net, without an additional consensus layer\n ZEther1 uses precompiles ECADD and ECMUL to construct confidential transactions\n\nThese are all technologies that have been, or are in the process of being, deployed to main-net. These protocols would all benefit from reducing the gas cost of the precompiles.\n\nTo give a concrete example, it currently costs 820,000 gas to validate the cryptography in a typical AZTEC confidential transaction. If the gas schedule for the precompiles correctly reflected their load on the Ethereum network, this cost would be 197,000 gas. This significantly increases the potential use cases for private assets on Ethereum. AZTEC is planning to deploy several cryptographic protocols Ethereum, but these are at the limits of what is practical given the current precompile costs:\n\n Confidential weighted voting\n Partial-order filling over encrypted orders, for private decentralized exchanges\n Anonymous identity sharing proofs (e.g. proving you are on a whitelist, without revealing who you are)\n Many-to-one payments and one-to-many confidential payments, as encrypted communication channels between main-net and L2 applications\n\nFor zk-SNARK based protocols on Ethereum, EIP-1108 will not only reduce the gas costs of verifying zk-SNARKs substantially, but can also aid in batching together multiple zk-SNARK proofs. This is also a technique that can be used to split up monolithic zk-SNARK circuits into a batch of zk-SNARKs with smaller individual circuit sizes, which makes zk-SNARKs both easier to construct and deploy.\n\nZEther transactions currently cost ~6,000,000 gas. This EIP would reduce this to ~1,000,000 gas, which makes the protocol more practical.\n\nTo summarise, there are several protocols that currently exist on main-net, that would benefit immensely from this EIP. Elliptic curve cryptography can provide valuable solutions for Ethereum, such as scaling and privacy, and the scope and scale of these solutions can be increased if the gas costs for the bn128 precompiles accurately reflects their computational load on the network.\n\n Cheaper elliptic curve cryptography can be used to trade storage for computation\n\nSolutions such as Rollup and Ignis can be used to batch groups of individual transactions into a zk-SNARK proof, with the on-chain state being represented by a small Merkle root, instead of multiple account balances.\n\nIf zk-SNARK verification costs are decreased, these solutions can be deployed for a wider range of use cases and more Rollup-style transactions can be processed per block.\n\n Parity and Geth already have fast algorithms that justify reduced gas costs\n\nThis EIP does not require Parity or Geth to deploy new cryptographic libraries, as fast bn128 algorithms have already been integrated into these clients. This goal of proposing this EIP for Istanbul, is to supplement EIP-1829 (arithmetic over generic elliptic curves), providing an immediate solution to the pressing problem of expensive cryptography, while more advanced solutions are developed, defined and deployed.\n\n Test Cases\n\nAs no underlying algorithms are being changed, there are no additional test cases to specify.\n\n Implementation\n\nBoth the Parity and Geth clients have already implemented cryptographic libraries that are fast enough to justify reducing the precompile gas costs. As a reference, here are a list of elliptic curve libraries, in C++, golang and rust, that support the bn128 curve, and have run-times that are equal to or faster than the Parity benchmarks.\n\n Parity bn crate (rust)\n Geth bn256 library (golang)\n MCL, a portable C++ pairing library\n Libff, a C++ pairing library used in many zk-SNARK libraries\n\n Additional References\n\n@vbuterin independently proposed a similar reduction after this EIP was originally created, with similar rationale, as ethereum/EIPs#1187.\n\n Copyright\n\nCopyright and related rights waived via CC0.\n\n Bünz, B., Agrawal, S., Zamani, M., & Boneh, D. (2020). Zether: Towards Privacy in a Smart Contract World. In J. Bonneau & N. Heninger (Eds.), Financial Cryptography and Data Security (pp. 423–443). Springer International Publishing. https://doi.org/10.1007/978-3-030-51280-4_23\n\n ↩\n\n Citation\n Please cite this document as:\n\n Antonio Salazar Cardozo (@shadowfiend), Zachary Williamson (@zac-williamson), \"EIP-1108: Reduce alt_bn128 precompile gas costs,\" Ethereum Improvement Proposals, no. 1108, May 2018. Available: https://eips.ethereum.org/EIPS/eip-1108.","tokens":2044,"squid":"spider-05","role":"Spec Spider","at":1791342123931,"hash":"40d1ec3a98682a9a6143177a4c086db3e849a18b"}
{"url":"https://jup.ag/stocks/cmg","domain":"jup.ag","title":"Chipotle Mexican Grill, Inc. (CMG) Tokenized Stock Price on Solana","text":"Underlying price$30.91+0.19% todayStock statsMarket cap$39.0BPrevious close$30.85Open$30.76Day's range$30.61 – $31.4652-week range$28.03 – $42.81Volume17.7MAvg volume14.0MP/E ratio27.5About Chipotle Mexican Grill, Inc.Chipotle is a leading fast-casual, Mexican-inspired restaurant chain, generating $11.9 billion in sales across 3,983 company-operated US locations, 104 international units primarily in Canada and Europe, and 14 licensed stores largely operated in the Middle East at the end of 2025. The firm's revenue is primarily driven by food and beverage sales at its company-owned restaurants, supplemented by delivery fees generated through its first-party digital channels. Chipotle emphasizes ingredients with no artificial flavors and utilizes an efficient, assembly line service model to serve mainly customizable burritos, bowls, salads, quesadillas, and tacos.TickerCMGAsset classEquityTokenized by1 issuerSectorConsumer DiscretionaryIndustryRetail-Eating PlacesEmployees130,301Websitechipotle.comChipotle Mexican Grill, Inc. FAQCMG is Chipotle Mexican Grill, Inc. stock, issued on Solana as a token that tracks the listed share. Each issuer mints its own version, so Chipotle Mexican Grill, Inc. trades here as one token.Token prices are designed to track Chipotle Mexican Grill, Inc.'s listed shares, but they can differ because of issuer terms, liquidity, market hours, and trading activity.Ondo issues the tokenized Chipotle Mexican Grill, Inc. market shown on Jupiter. Each issuer controls its own token and settlement terms.Trading availability depends on the issuer token and its market. Open an issuer's token page to check current liquidity and trading status.Use the Market swap on this page. Select the CMG token in the swap to choose an issuer. Connect your wallet, choose the token you want to pay with, and enter an amount. Review the swap details before you submit, then confirm in your wallet when prompted. A swap requires an available trading route. Issuer terms and restrictions apply.Dividend treatment depends on the token issuer. A dividend paid on Chipotle Mexican Grill, Inc.'s listed shares does not guarantee a cash payment to token holders. Review each issuer's terms for how dividends and other corporate actions are handled.Read Ondo's corporate action policy","tokens":576,"squid":"spider-02","role":"Liquidity Spider","at":1791342127047,"hash":"e91850b05dcdefe7d58862081686edd6a76da8c8"}
{"url":"https://eips.ethereum.org/EIPS/eip-1153","domain":"eips.ethereum.org","title":"EIP-1153: Transient storage opcodes","text":"🎉 Final\n\n Standards Track: Core\n\n EIP-1153: Transient storage opcodes\n\n Add opcodes for manipulating state that behaves almost identically to storage but is discarded after every transaction\n\n Authors\n Alexey Akhunov (@AlexeyAkhunov), Moody Salem (@moodysalem)\n\n Created\n 2018-06-15\n\n Requires\n\n EIP-2200, \n\n EIP-3529\n\n Abstract\n\nThis proposal introduces transient storage opcodes, which manipulate state that behaves identically to storage, except that transient storage is discarded after every transaction, and TSTORE is not subject to the gas stipend check as defined in EIP-2200. In other words, the values of transient storage are never deserialized from storage or serialized to storage. Thus transient storage is cheaper since it never requires disk access. Transient storage is accessible to smart contracts via 2 new opcodes, TLOAD and TSTORE, where “T” stands for “transient:”\n\nTLOAD (0x5c)\nTSTORE (0x5d)\n\n Motivation\n\nRunning a transaction in Ethereum can generate multiple nested frames of execution, each created by CALL (or similar) instructions. Contracts can be re-entered during the same transaction, in which case there are more than one frame belonging to one contract. Currently, these frames can communicate in two ways: via inputs/outputs passed via CALL instructions, and via storage updates. If there is an intermediate frame belonging to another untrusted contract, communication via inputs/outputs is not secure. Notable example is a reentrancy lock which cannot rely on the intermediate frame to pass through the state of the lock. Communication via storage (SSTORE/SLOAD) is costly. Transient storage is a dedicated and gas efficient solution to the problem of inter frame communication.\n\nStorage refunds accumulated due to inter frame communication are also limited to 20% of gas spent by a transaction due to EIP-3529 (introduced in the London hard fork). This greatly reduces the refunds for transiently-set storage slots in otherwise low-cost transactions. For example, in order to receive the full refund of one re-entrancy lock, the transaction must spend ~80k gas on other operations.\n\nLanguage support could be added in relatively easy way. For example, in Solidity, a qualifier transient can be introduced (similar to the existing qualifiers memory and storage, and Java’s own transient keyword with a similar meaning). Since the addressing scheme of TSTORE and TLOAD is the same as for SSTORE and SLOAD, code generation routines that exist for storage variables, can be easily generalised to also support transient storage.\n\nPotential use cases enabled or improved by this EIP include:\n\n Reentrancy locks\n On-chain computable CREATE2 addresses: constructor arguments are read from the factory contract instead of passed as part of init code hash\n Single transaction ERC-20 approvals, e.g. #temporaryApprove(address spender, uint256 amount)\n Fee-on-transfer contracts: pay a fee to a token contract to unlock transfers for the duration of a transaction\n “Till” pattern: allowing users to perform all actions as part of a callback, and checking the “till” is balanced at the end\n Proxy call metadata: pass additional metadata to an implementation contract without using calldata, e.g. values of immutable proxy constructor arguments\n\nThese opcodes are more efficient to execute than the SSTORE and SLOAD opcodes because the original value never needs to be loaded from storage (i.e. is always 0). The gas accounting rules are also simpler, since no refunds are required.\n\n Specification\n\nTwo new opcodes are added to EVM, TLOAD (0x5c) and TSTORE (0x5d). (Note that previous drafts of this EIP specified the values 0xb3 and 0xb4 for TLOAD and TSTORE respectively to avoid conflict with other EIPs. The conflict has since been removed.)\n\nThey use the same arguments on stack as SLOAD (0x54) and SSTORE (0x55).\n\nTLOAD pops one 32-byte word from the top of the stack, treats this value as the address, fetches 32-byte word from the transient storage at that address, and pushes the value on top of the stack.\n\nTSTORE pops two 32-byte words from the top of the stack. The word on the top is the address, and the next is the value. TSTORE saves the value at the given address in the transient storage.\n\nAddressing is the same as SLOAD and SSTORE. i.e. each 32-byte address points to a unique 32-byte word.\n\nGas cost for TSTORE is the same as a warm SSTORE of a dirty slot (i.e. original value is not new value and is not current value, currently 100 gas), and gas cost of TLOAD is the same as a hot SLOAD (value has been read before, currently 100 gas). Gas cost cannot be on par with memory access due to transient storage’s interactions with reverts.\n\nAll values in transient storage are discarded at the end of the transaction.\n\nTransient storage is private to the contract that owns it, in the same way as persistent storage. Only owning contract frames may access their transient storage. And when they do, all the frames access the same transient store, in the same way as persistent storage, but unlike memory.\n\nWhen transient storage is used in the context of DELEGATECALL or CALLCODE, then the owning contract of the transient storage is the contract that issued DELEGATECALL or CALLCODE instruction (the caller) as with persistent storage. When transient storage is used in the context of CALL or STATICCALL, then the owning contract of the transient storage is the contract that is the target of the CALL or STATICCALL instruction (the callee).\n\nIf a frame reverts, all writes to transient storage that took place between entry to the frame and the return are reverted, including those that took place in inner calls. This mimics the behavior of persistent storage.\n\nIf the TSTORE opcode is called within the context of a STATICCALL, it will result in an exception instead of performing the modification. TLOAD is allowed within the context of a STATICCALL.\n\nThe behavior of the opcodes for transient storage differs from the opcodes for storage in that TSTORE does not require gasleft, as defined in EIP-2200, to be less than or equal to the gas stipend (currently 2,300).\n\n Rationale\n\nAnother option to solve the problem of inter-frame communication is repricing the SSTORE and SLOAD opcodes to be cheaper for the transient storage use case. This has already been done as of EIP-2200. However, EIP-3529 reduced the maximum refund to only 20% of the transaction gas cost, which means the use of transient storage is severely limited.\n\nAnother approach is to keep the refund counter for transient storage separate from the refund counter for other storage uses, and remove the refund cap for transient storage. However, that approach is more complex to implement and understand. For example, the 20% refund cap must be applied to the gas used after subtracting the uncapped gas refund. Otherwise, the refund amount available subject to the 20% refund cap could be increased by executing transient storage writes. Thus it is preferable to have a separate mechanism that does not interact with the refund counter. Future hard forks can remove the complex refund behavior meant to support the transient storage use case, encouraging migration to contracts that are more efficient for the Ethereum clients to execute.\n\nThere is a known objection to the word-addressed storage-like interface of the TSTORE and TLOAD opcodes since transient storage is more akin to memory than storage in lifecycle. A byte-addressed memory-like interface is another option. The storage-like word-addressed interface is preferred due to the usefulness of mappings in combination with the transaction-scoped memory region. Often times, you will need to keep transient state with arbitrary keys, such as in the ERC-20 temporary approval use case which uses a mapping of (owner, spender) to allowance. Mappings are difficult to implement using linear memory, and linear memory must also have dynamic gas costs. It is also more complicated to handle reverts with a linear memory. It is possible to have a memory-like interface while the underlying implementation uses a map to allow for storage in arbitrary offsets, but this would result in a third memory-storage hybrid interface that would require new code paths in compilers.\n\nSome think that a unique transaction identifier may obviate the need for transient storage as described in this EIP. This is a misconception: a transaction identifier used in combination with regular storage has all the same issues that motivate this EIP. The two features are orthogonal.\n\nRelative cons of this transient storage EIP:\n\n Does not address transient usages of storage in existing contracts\n New code in the clients\n New concept for the yellow paper (more to update)\n\nRelative pros of this transient storage EIP:\n\n Transient storage opcodes are considered separately in protocol upgrades and not inadvertently broken (e.g. EIP-3529)\n Clients do not need to load the original value\n No upfront gas cost to account for non-transient writes\n Does not change the semantics of the existing operations\n No need to clear storage slots after usage\n Simpler gas accounting rules\n Future storage designs (e.g. Verkle tree) do not need to account for transient storage refunds\n\n Backwards Compatibility\n\nThis EIP requires a hard fork to implement.\n\nSince this EIP does not change behavior of any existing opcodes, it is backwards compatible with all existing smart contracts.\n\n Test Cases\n\nA test suite for this EIP can be found here.\n\n Reference Implementation\n\nBecause the transient storage must behave almost identically to storage within the context of a single transaction with regards to revert behavior, it is necessary to be able to revert to a previous state of transient storage within a transaction. At the same time reverts are exceptional cases and loads, stores and returns should be cheap.\n\nA map of current state plus a journal of all changes and a list of checkpoints is recommended. This has the following time complexities:\n\n On entry to a call frame, a call marker is added to the list - O(1)\n New values are written to the current state, and the previous value is written to the journal - O(1)\n When a call exits successfully, the marker to the journal index of when that call was entered is discarded - O(1)\n On revert all entries are reverted up to the last checkpoint, in reverse - O(N) where N = number of journal entries since last checkpoint\n\ninterface JournalEntry {\n addr: string\n key: string\n prevValue: string\n}\n\ntype Journal = JournalEntry[]\n\ntype Checkpoints = Journal['length'][]\n\ninterface Current {\n [addr: string]: {\n [key: string]: string\n }\n}\n\nconst EMPTY_VALUE = '0x0000000000000000000000000000000000000000000000000000000000000000'\n\nclass TransientStorage {\n /**\n * The current state of transient storage.\n */\n private current: Current = {}\n /**\n * All changes are written to the journal. On revert, we apply the changes in reverse to the last checkpoint.\n */\n private journal: Journal = []\n /**\n * The length of the journal at the time of each checkpoint\n */\n private checkpoints: Checkpoints = [0]\n\n /**\n * Returns the current value of the given contract address and key\n * @param addr The address of the contract\n * @param key The key of transient storage for the address\n */\n public get(addr: string, key: string): string {\n return this.current[addr]?.[key] ?? EMPTY_VALUE\n }\n\n /**\n * Set the current value in the map\n * @param addr the address of the contract for which the key is being set\n * @param key the slot to set for the address\n * @param value the new value of the slot to set\n */\n public put(addr: string, key: string, value: string) {\n this.journal.push({\n addr,\n key,\n prevValue: this.get(addr, key),\n })\n\n this.current[addr] = this.current[addr] ?? {}\n this.current[addr][key] = value;\n }\n\n /**\n * Commit all the changes since the last checkpoint\n */\n public commit(): void {\n if (this.checkpoints.length === 0) throw new Error('Nothing to commit')\n this.checkpoints.pop() // The last checkpoint is discarded.\n }\n\n /**\n * To be called whenever entering a new context. If revert is called after checkpoint, all changes made after the latest checkpoint are reverted.\n */\n public checkpoint(): void {\n this.checkpoints.push(this.journal.length)\n }\n\n /**\n * Revert transient storage to the state from the last call to checkpoint\n */\n public revert() {\n const lastCheckpoint = this.checkpoints.pop()\n if (typeof lastCheckpoint === 'undefined') throw new Error('Nothing to revert')\n\n for (let i = this.journal.length - 1; i >= lastCheckpoint; i--) {\n const {addr, key, prevValue} = this.journal[i]\n // we can assume it exists, since it was written in the journal\n this.current[addr][key] = prevValue\n }\n this.journal.splice(lastCheckpoint, this.journal.length - lastCheckpoint)\n }\n}\n\nThe worst case time complexity can be produced by writing the maximum number of keys that can fit in one block, and then reverting. In this case, the client is required to do twice as many writes to apply all the entries in the journal. However, the same case applies to the state journaling implementation of existing clients, and cannot be DOS’d with the following code.\n\npragma solidity =0.8.13;\n\ncontract TryDOS {\n uint256 slot;\n\n constructor() {\n slot = 1;\n }\n\n function tryDOS() external {\n uint256 i = 1;\n while (gasleft() > 5000) {\n unchecked {\n slot = i++;\n }\n }\n revert();\n }\n}\n\n Security Considerations\n\nTSTORE presents a new way to allocate memory on a node with linear cost. In other words, each TSTORE allows the developer to store 32 bytes for 100 gas, excluding any other required operations to prepare the stack. Given 30 million gas, the maximum amount of memory that can be allocated using TSTORE is:\n\n30M gas * 1 TSTORE / 100 gas * 32 bytes / 1 TSTORE * 1MB / 2^20 bytes ~= 9.15MB\n\nGiven the same amount of gas, the maximum amount of memory that can be allocated in a single context by MSTORE is ~3.75MB:\n\n30M gas = 3x + x^2 / 512 => x = ~123,169 32-byte words\n~123,169 words * 32 bytes/word * 1MB / 2^20 bytes = 3.75MB\n\nHowever, if you only spend 1M gas allocating memory in each context, and make calls to reset the memory expansion cost, you can allocate ~700KB per million gas, for a total of ~20MB of memory allocated:\n\n1M gas = 3x + x^2 / 512 => x = ~21,872 32-byte words\n30M gas * ~21,872 words / 1M gas * 32 bytes/word * 1MB / 2^20 bytes = ~20MB\n\nSmart contract developers should understand the lifetime of transient storage variables before use. Because transient storage is automatically cleared at the end of the transaction, smart contract developers may be tempted to avoid clearing slots as part of a call in order to save gas. However, this could prevent further interactions with the contract in the same transaction (e.g. in the case of re-entrancy locks) or cause other bugs, so smart contract developers should be careful to only leave transient storage slots with nonzero values when those slots are intended to be used by future calls within the same transaction. Otherwise, these opcodes behave exactly the same as SSTORE and SLOAD, so all the usual security considerations apply especially in regard to reentrancy risk.\n\nSmart contract developers may also be tempted to use transient storage as an alternative to in-memory mappings. They should be aware that transient storage is not discarded when a call returns or reverts, as is memory, and should prefer memory for these use cases so as not to create unexpected behavior on reentrancy in the same transaction. The necessarily high cost of transient storage over memory should already discourage this usage pattern. Most usages of in-memory mappings can be better implemented with key-sorted lists of entries, and in-memory mappings are rarely required in smart contracts (i.e. the author knows of no known use cases in production).\n\n Copyright\n\nCopyright and related rights waived via CC0.\n\n Citation\n Please cite this document as:\n\n Alexey Akhunov (@AlexeyAkhunov), Moody Salem (@moodysalem), \"EIP-1153: Transient storage opcodes,\" Ethereum Improvement Proposals, no. 1153, June 2018. Available: https://eips.ethereum.org/EIPS/eip-1153.","tokens":4030,"squid":"spider-05","role":"Spec Spider","at":1791342145662,"hash":"1446155e871896e21c9af6626433af2e2a6afa4a"}
{"url":"https://jup.ag/stocks/f","domain":"jup.ag","title":"Ford Motor Company (F) Tokenized Stock Price on Solana","text":"Underlying price$12.28+1.15% todayStock statsMarket cap$48.4BPrevious close$12.15Open$12.20Day's range$12.14 – $12.3152-week range$11.11 – $17.78Volume35.7MAvg volume46.5MP/E ratio-About Ford Motor CompanyFord Motor Co. manufactures automobiles under its Ford and Lincoln brands. In 2022, the company announced that it would run its combustion engine business, Ford Blue, and its BEV business, Ford Model e, as separate businesses but still all under Ford Motor. The company has over 13% market share in the United States, about 10% share in the UK, and just over 1% share in China including Taiwan and unconsolidated affiliates. Sales in the US made up about 65% of 2025 total company revenue. Ford has about 169,000 employees, including about 56,300 UAW employees, and is based in Dearborn, Michigan.TickerFAsset classEquityTokenized by2 issuersSectorConsumer DiscretionaryIndustryMotor Vehicles & Passenger Car BodiesEmployees169,000Websiteford.comFord Motor Company FAQF is Ford Motor Company stock, issued on Solana as a token that tracks the listed share. Each issuer mints its own version, so Ford Motor Company trades here as 2 tokens rather than one.Token prices are designed to track Ford Motor Company's listed shares, but they can differ because of issuer terms, liquidity, market hours, and trading activity.Ondo and xStocks issue the tokenized Ford Motor Company markets shown on Jupiter. Each issuer controls its own token and settlement terms.Trading availability depends on the issuer token and its market. Open an issuer's token page to check current liquidity and trading status.Use the Market swap on this page. Select the F token in the swap to choose an issuer. Connect your wallet, choose the token you want to pay with, and enter an amount. Review the swap details before you submit, then confirm in your wallet when prompted. A swap requires an available trading route. Issuer terms and restrictions apply.Dividend treatment depends on the token issuer. A dividend paid on Ford Motor Company's listed shares does not guarantee a cash payment to token holders. Review each issuer's terms for how dividends and other corporate actions are handled.Read Ondo's corporate action policyRead xStocks' dividend and stock split policy","tokens":563,"squid":"spider-02","role":"Liquidity Spider","at":1791342148996,"hash":"1343ecbdf05bb921f6a653573d2a50aca74f9947"}
{"url":"https://eips.ethereum.org/EIPS/eip-2200","domain":"eips.ethereum.org","title":"EIP-2200: Structured Definitions for Net Gas Metering","text":"🎉 Final\n\n Standards Track: Core\n\n EIP-2200: Structured Definitions for Net Gas Metering\n\n Authors\n Wei Tang (@sorpaas)\n\n Created\n 2019-07-18\n\n Simple Summary\n\nThis is an EIP that implements net gas metering. It’s a combined\nversion of EIP-1283 and EIP-1706, with a structured definition so as\nto make it interoperable with other gas changes such as EIP-1884.\n\n Abstract\n\nThis EIP provides a structured definition of net gas metering changes\nfor SSTORE opcode, enabling new usages for contract storage, and\nreducing excessive gas costs where it doesn’t match how most\nimplementation works.\n\nThis is a combination of EIP-1283 and EIP-1706.\n\n Motivation\n\nThis EIP proposes a way for gas metering on SSTORE, using information\nthat is more universally available to most implementations, and\nrequire as little change in implementation structures as possible.\n\n Storage slot’s original value.\n Storage slot’s current value.\n Refund counter.\n\nUsages that benefits from this EIP’s gas reduction scheme includes:\n\n Subsequent storage write operations within the same call frame. This\nincludes reentry locks, same-contract multi-send, etc.\n Exchange storage information between sub call frame and parent call\nframe, where this information does not need to be persistent outside\nof a transaction. This includes sub-frame error codes and message\npassing, etc.\n\nThe original definition of EIP-1283 created a danger of a new kind of\nreentrancy attacks on existing contracts as Solidity by default grants\na “stipend” of 2300 gas to simple transfer calls. This danger is\neasily mitigated if SSTORE is not allowed in low gasleft state,\nwithout breaking the backward compatibility and the original intention\nof EIP-1283.\n\nThis EIP also replaces the original EIP-1283 value definitions of gas\nby parameters, so that it’s more structured, and easier to define\nchanges in the future.\n\n Specification\n\nDefine variables SLOAD_GAS, SSTORE_SET_GAS, SSTORE_RESET_GAS and\nSSTORE_CLEARS_SCHEDULE. The old and new values for those variables\nare:\n\n SLOAD_GAS: changed from 200 to 800.\n SSTORE_SET_GAS: 20000, not changed.\n SSTORE_RESET_GAS: 5000, not changed.\n SSTORE_CLEARS_SCHEDULE: 15000, not changed.\n\nChange the definition of EIP-1283 using those variables. The new\nspecification, combining EIP-1283 and EIP-1706, will look like\nbelow. The terms original value, current value and new value are\ndefined in EIP-1283.\n\nReplace SSTORE opcode gas cost calculation (including refunds) with\nthe following logic:\n\n If gasleft is less than or equal to gas stipend, fail the current\ncall frame with ‘out of gas’ exception.\n If current value equals new value (this is a no-op), SLOAD_GAS\nis deducted.\n If current value does not equal new value\n\n If original value equals current value (this storage slot has\nnot been changed by the current execution context)\n\n If original value is 0, SSTORE_SET_GAS is deducted.\n Otherwise, SSTORE_RESET_GAS gas is deducted. If new value is\n0, add SSTORE_CLEARS_SCHEDULE gas to refund counter.\n\n If original value does not equal current value (this storage\nslot is dirty), SLOAD_GAS gas is deducted. Apply both of the\nfollowing clauses.\n\n If original value is not 0\n\n If current value is 0 (also means that new value is not\n0), remove SSTORE_CLEARS_SCHEDULE gas from refund\ncounter.\n If new value is 0 (also means that current value is not\n0), add SSTORE_CLEARS_SCHEDULE gas to refund counter.\n\n If original value equals new value (this storage slot is\nreset)\n\n If original value is 0, add SSTORE_SET_GAS - SLOAD_GAS to\nrefund counter.\n Otherwise, add SSTORE_RESET_GAS - SLOAD_GAS gas to refund\ncounter.\n\nAn implementation should also note that with the above definition, if\nthe implementation uses call-frame refund counter, the counter can go\nnegative. If the implementation uses transaction-wise refund counter,\nthe counter always stays positive.\n\n Rationale\n\nThis EIP mostly achieves what a transient storage tries to do\n(EIP-1087 and EIP-1153), but without the complexity of introducing the\nconcept of “dirty maps”, or an extra storage struct.\n\n We don’t suffer from the optimization limitation of\nEIP-1087. EIP-1087 requires keeping a dirty map for storage changes,\nand implicitly makes the assumption that a transaction’s storage\nchanges are committed to the storage trie at the end of a\ntransaction. This works well for some implementations, but not for\nothers. After EIP-658, an efficient storage cache implementation\nwould probably use an in-memory trie (without RLP encoding/decoding)\nor other immutable data structures to keep track of storage changes,\nand only commit changes at the end of a block. For them, it is\npossible to know a storage’s original value and current value, but\nit is not possible to iterate over all storage changes without\nincurring additional memory or processing costs.\n It never costs more gas compared with the current scheme.\n It covers all usages for a transient storage. Clients that are easy\nto implement EIP-1087 will also be easy to implement this\nspecification. Some other clients might require a little bit extra\nrefactoring on this. Nonetheless, no extra memory or processing cost\nis needed on runtime.\n\nRegarding SSTORE gas cost and refunds, see Appendix for proofs of\nproperties that this EIP satisfies.\n\n For absolute gas used (that is, actual gas used minus refund),\nthis EIP is equivalent to EIP-1087 for all cases.\n For one particular case, where a storage slot is changed, reset to\nits original value, and then changed again, EIP-1283 would move more\ngases to refund counter compared with EIP-1087.\n\nExamine examples provided in EIP-1087’s Motivation (with SLOAD_GAS being\n200):\n\n If a contract with empty storage sets slot 0 to 1, then back to 0,\nit will be charged 20000 + 200 - 19800 = 400 gas.\n A contract with empty storage that increments slot 0 5 times will be\ncharged 20000 + 5 * 200 = 21000 gas.\n A balance transfer from account A to account B followed by a\ntransfer from B to C, with all accounts having nonzero starting and\nending balances, it will cost 5000 * 3 + 200 - 4800 = 10400 gas.\n\nIn order to keep in place the implicit reentrancy protection of\nexisting contracts, transactions should not be allowed to modify state\nif the remaining gas is lower than the gas stipend given to\n“transfer”/”send” in Solidity. These are other proposed remediations\nand objections to implementing them:\n\n Drop EIP-1283 and abstain from modifying SSTORE cost\n\n EIP-1283 is an important update\n It was accepted and implemented on test networks and in clients.\n\n Add a new call context that permits LOG opcodes but not changes to state.\n\n Adds another call type beyond existing regular/staticcall\n\n Raise the cost of SSTORE to dirty slots to >=2300 gas\n\n Makes net gas metering much less useful.\n\n Reduce the gas stipend\n\n Makes the stipend almost useless.\n\n Increase the cost of writes to dirty slots back to 5000 gas, but add\n4800 gas to the refund counter\n\n Still doesn’t make the invariant explicit.\n Requires callers to supply more gas, just to have it refunded\n\n Add contract metadata specifying per-contract EVM version, and only\napply SSTORE changes to contracts deployed with the new version.\n\n Backwards Compatibility\n\nThis EIP requires a hard fork to implement. No gas cost increase is\nanticipated, and many contracts will see gas reduction.\n\nPerforming SSTORE has never been possible with less than 5000 gas, so\nit does not introduce incompatibility to the Ethereum Mainnet. Gas\nestimation should account for this requirement.\n\n Test Cases\n\n Code\n Used Gas\n Refund\n Original\n 1st\n 2nd\n 3rd\n\n 0x60006000556000600055\n 1612\n 0\n 0\n 0\n 0\n\n 0x60006000556001600055\n 20812\n 0\n 0\n 0\n 1\n\n 0x60016000556000600055\n 20812\n 19200\n 0\n 1\n 0\n\n 0x60016000556002600055\n 20812\n 0\n 0\n 1\n 2\n\n 0x60016000556001600055\n 20812\n 0\n 0\n 1\n 1\n\n 0x60006000556000600055\n 5812\n 15000\n 1\n 0\n 0\n\n 0x60006000556001600055\n 5812\n 4200\n 1\n 0\n 1\n\n 0x60006000556002600055\n 5812\n 0\n 1\n 0\n 2\n\n 0x60026000556000600055\n 5812\n 15000\n 1\n 2\n 0\n\n 0x60026000556003600055\n 5812\n 0\n 1\n 2\n 3\n\n 0x60026000556001600055\n 5812\n 4200\n 1\n 2\n 1\n\n 0x60026000556002600055\n 5812\n 0\n 1\n 2\n 2\n\n 0x60016000556000600055\n 5812\n 15000\n 1\n 1\n 0\n\n 0x60016000556002600055\n 5812\n 0\n 1\n 1\n 2\n\n 0x60016000556001600055\n 1612\n 0\n 1\n 1\n 1\n\n 0x600160005560006000556001600055\n 40818\n 19200\n 0\n 1\n 0\n 1\n\n 0x600060005560016000556000600055\n 10818\n 19200\n 1\n 0\n 1\n 0\n\n Implementation\n\nTo be added.\n\n Appendix: Proof\n\nBecause the storage slot’s original value is defined as the value\nwhen a reversion happens on the current transaction, it’s easy to\nsee that call frames won’t interfere SSTORE gas calculation. So\nalthough the below proof is discussed without call frames, it applies\nto all situations with call frames. We will discuss the case\nseparately for original value being zero and not zero, and use\ninduction to prove some properties of SSTORE gas cost.\n\nFinal value is the value of a particular storage slot at the end of\na transaction. Absolute gas used is the absolute value of gas used\nminus refund. We use N to represent the total number of SSTORE\noperations on a storage slot. For states discussed below, refer to\nState Transition in Explanation section.\n\nBelow we do the proof under the assumption that all parameters are\nunchanged, meaning SLOAD_GAS is 200. However, note that the proof\nstill applies no matter how SLOAD_GAS is changed.\n\n Original Value Being Zero\n\nWhen original value is 0, we want to prove that:\n\n Case I: If the final value ends up still being 0, we want to charge 200 *\nN gases, because no disk write is needed.\n Case II: If the final value ends up being a non-zero value, we want to\ncharge 20000 + 200 * (N-1) gas, because it requires writing this\nslot to disk.\n\n Base Case\n\nWe always start at state A. The first SSTORE can:\n\n Go to state A: 200 gas is deducted. We satisfy Case I because\n200 * N == 200 * 1.\n Go to state B: 20000 gas is deducted. We satisfy Case II because\n20000 + 200 * (N-1) == 20000 + 200 * 0.\n\n Inductive Step\n\n From A to A. The previous gas cost is 200 * (N-1). The current\ngas cost is 200 + 200 * (N-1). It satisfy Case I.\n From A to B. The previous gas cost is 200 * (N-1). The current\ngas cost is 20000 + 200 * (N-1). It satisfy Case II.\n From B to B. The previous gas cost is 20000 + 200 * (N-2). The\ncurrent gas cost is 200 + 20000 + 200 * (N-2). It satisfy\nCase II.\n From B to A. The previous gas cost is 20000 + 200 * (N-2). The\ncurrent gas cost is 200 - 19800 + 20000 + 200 * (N-2). It satisfy\nCase I.\n\n Original Value Not Being Zero\n\nWhen original value is not 0, we want to prove that:\n\n Case I: If the final value ends up unchanged, we want to\ncharge 200 * N gases, because no disk write is needed.\n Case II: If the final value ends up being zero, we want to\ncharge 5000 - 15000 + 200 * (N-1) gas. Note that 15000 is the\nrefund in actual definition.\n Case III: If the final value ends up being a changed non-zero\nvalue, we want to charge 5000 + 200 * (N-1) gas.\n\n Base Case\n\nWe always start at state X. The first SSTORE can:\n\n Go to state X: 200 gas is deducted. We satisfy Case I because\n200 * N == 200 * 1.\n Go to state Y: 5000 gas is deducted. We satisfy Case III because\n5000 + 200 * (N-1) == 5000 + 200 * 0.\n Go to state Z: The absolute gas used is 5000 - 15000 where 15000\nis the refund. We satisfy Case II because 5000 - 15000 + 200 *\n(N-1) == 5000 - 15000 + 200 * 0.\n\n Inductive Step\n\n From X to X. The previous gas cost is 200 * (N-1). The current gas\ncost is 200 + 200 * (N-1). It satisfy Case I.\n From X to Y. The previous gas cost is 200 * (N-1). The current gas\ncost is 5000 + 200 * (N-1). It satisfy Case III.\n From X to Z. The previous gas cost is 200 * (N-1). The current\nabsolute gas cost is 5000 - 15000 + 200 * (N-1). It satisfy Case\nII.\n From Y to X. The previous gas cost is 5000 + 200 * (N-2). The\nabsolute current gas cost is 200 - 4800 + 5000 + 200 * (N-2). It\nsatisfy Case I.\n From Y to Y. The previous gas cost is 5000 + 200 * (N-2). The\ncurrent gas cost is 200 + 5000 + 200 * (N-2). It satisfy Case\nIII.\n From Y to Z. The previous gas cost is 5000 + 200 * (N-2). The\ncurrent absolute gas cost is 200 - 15000 + 5000 + 200 * (N-2). It\nsatisfy Case II.\n From Z to X. The previous gas cost is 5000 - 15000 + 200 *\n(N-2). The current absolute gas cost is 200 + 10200 + 5000 -\n15000 + 200 * (N-2). It satisfy Case I.\n From Z to Y. The previous gas cost is 5000 - 15000 + 200 *\n(N-2). The current absolute gas cost is 200 + 15000 + 5000 -\n15000 + 200 * (N-2). It satisfy Case III.\n From Z to Z. The previous gas cost is 5000 - 15000 + 200 *\n(N-2). The current absolute gas cost is 200 + 5000 - 15000 + 200 *\n(N-2). It satisfy Case II.\n\n Copyright\n\nCopyright and related rights waived via CC0.\n\n Citation\n Please cite this document as:\n\n Wei Tang (@sorpaas), \"EIP-2200: Structured Definitions for Net Gas Metering,\" Ethereum Improvement Proposals, no. 2200, July 2019. Available: https://eips.ethereum.org/EIPS/eip-2200.","tokens":3222,"squid":"spider-05","role":"Spec Spider","at":1791342156943,"hash":"6889138184fba62152b3036ad01e8ca72d64d1d9"}
{"url":"https://jup.ag/stocks/rivn","domain":"jup.ag","title":"Rivian Automotive, Inc. Class A Common Stock (RIVN) Tokenized Stock Price on Solana","text":"Underlying price$14.50-0.64% todayStock statsMarket cap$21.1BPrevious close$14.60Open$14.58Day's range$14.42 – $14.8352-week range$12.39 – $22.69Volume17.2MAvg volume23.1MP/E ratio-About Rivian Automotive, Inc. Class A Common StockRivian is a battery electric vehicle automaker that sells its vehicles in the US and Canada. The company also develops electronic control units and related software for autos in a joint venture with Volkswagen. Rivian has multiple vehicles in its fleet, which include a luxury truck, a full-size SUV, and a delivery van. The company plans to begin selling a midsize SUV in 2026. Total deliveries were over 42,000 in 2025. Rivian is also developing autonomous driving software to be used in its vehicles and for robotaxis on the Uber ride-hailing network.TickerRIVNAsset classEquityTokenized by2 issuersSectorConsumer DiscretionaryIndustryMotor Vehicles & Passenger Car BodiesEmployees15,232Websiterivian.comRivian Automotive, Inc. Class A Common Stock FAQRIVN is Rivian Automotive, Inc. Class A Common Stock stock, issued on Solana as a token that tracks the listed share. Each issuer mints its own version, so Rivian Automotive, Inc. Class A Common Stock trades here as 2 tokens rather than one.Token prices are designed to track Rivian Automotive, Inc. Class A Common Stock's listed shares, but they can differ because of issuer terms, liquidity, market hours, and trading activity.Backpack and Ondo issue the tokenized Rivian Automotive, Inc. Class A Common Stock markets shown on Jupiter. Each issuer controls its own token and settlement terms.Trading availability depends on the issuer token and its market. Open an issuer's token page to check current liquidity and trading status.Use the Market swap on this page. Select the RIVN token in the swap to choose an issuer. Connect your wallet, choose the token you want to pay with, and enter an amount. Review the swap details before you submit, then confirm in your wallet when prompted. A swap requires an available trading route. Issuer terms and restrictions apply.Dividend treatment depends on the token issuer. A dividend paid on Rivian Automotive, Inc. Class A Common Stock's listed shares does not guarantee a cash payment to token holders. Review each issuer's terms for how dividends and other corporate actions are handled.Read Backpack's dividend and corporate action guideRead Ondo's corporate action policy","tokens":602,"squid":"spider-02","role":"Liquidity Spider","at":1791342162580,"hash":"3dacfbea0211697d3e2e3be678e3841bbfe1810a"}
{"url":"https://forum.across.to/t/acx-emissions-committee/1787/2","domain":"forum.across.to","title":"ACX Emissions Committee - Proposals - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n Proposals\n\n governance-updates\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Dec 2023\n\n 2 / 2\n\n Jan 2024\n\n Dec 2023\n\n post by Kevin_UMA on Dec 16, 2023\n\n Kevin_UMA\n\n Title: ACX Emissions Committee\nAuthors: Kevin Chan, David Korpi, Ryan Carman, Dylan O’Reilly, Chase Coleman\nStatus: Proposal\nSubmission Date: December 16th, 2023\nSummary:\nThe Across DAO needs an efficient and transparent way to manage ACX emissions. The DAO should form the ACX Emissions Committee (AEC). The AEC will have permission to change the Across Reward Locking parameters which controls ACX emissions on the Across bridge liquidity pools. The AEC will follow a transparent and restrictive framework to make predictable and measured changes to emissions for an asset depending on the pool utilization rate of that asset and the yield earned on comparable bridges. The members of the AEC will be chosen by ACX token holders and changes to the parameters of this framework will also need DAO approval.\nMotivation:\nThe Across DAO needs an efficient and transparent way to manage ACX emissions so that ACX is optimally used for incentives. Currently, the amount of ACX rewarded to bridge liquidity providers (LPs) appears high in comparison to competing cross chain bridges. For example, Across is rewarding ETH LPs a base APY of 12.7% (21.5% to LPs with a 2x multiplier) in comparison to competing bridges such as Stargate, Hop and Synapse which are paying 4% to 7%. In addition, the utilization rate on the ETH pool on Across is only 22.7% suggesting there is not an urgent demand for assets. A proposal can be submitted to decrease emissions; however, a more permanent, clear and robust solution should be created to adjust ACX emissions both down and up when needed.\nThe Across DAO should form the ACX Emissions Committee (AEC). The AEC will own the Accelerating Distributor contract, which controls the parameters of the Across Reward Locking program, through a 3 of 5 multisig. Members of the AEC and signers of this multisig will initially be Risk Labs foundation team members. However, the long term goal is to include Across community members such as the Across Treasury Committee which is potentially being formed now. Changes in AEC members and parameters on how it operates can be voted on by the Across DAO.\nAEC Short Term Objective\nThe AEC needs a clear and transparent framework to adjust ACX emissions. The framework also needs to be reasonably restrictive so that only predictable and measured actions are taken to modify ACX emissions. Decisions will be driven by two observable factors.\n\nAcross pool utilization - LPs should be rewarded for how much demand there is for an asset for bridge transfers. The AEC will track the 7-day average pool utilization of each asset.\nCompeting yield - LPs should be rewarded a fair yield in comparison to yields paid by competing bridges. The AEC can track a Yield Index for each asset that is computed as a 7-day average of the TVL weighted yield of pools on Stargate, Hop, and Synapse.\n\nUsing these two factors as inputs, the AEC can build a simple framework (below) to determine whether action needs to be taken on ETH, USDC, USDT, and DAI. If an action is required, the AEC can only increase or decrease emissions of an asset by 25% and then wait 14 days to re-evaluate and take further action if needed. This prevents the AEC from over reacting and allows the LPs and the general market to adjust to its actions.\n\nAcross Pool Utilization\nDecrease emissions by 25% if total Base LP APY vs Yield Index is\nIncrease emissions by 25% if total Base LP APY vs Yield Index is\n\n0 - 40%\n+25%\n-75%\n\n40 - 70%\n+50%\n-50%\n\n70 - 100%\n+100%\n-25%\n\nHere is an example of how the AEC would act today when evaluating the ETH pool:\n\nETH Pool Utilization = 22.7%\nETH Base LP APY = 12.65%\nETH Yield Index = 5.38%\nAcross APY is 135% higher than the Yield Index which is higher than the +25% threshold for action\nAEC decreases emissions by 25% and resulting APY is 10.71% (note: AEC only decreases Rewards APY and cannot control the Pool APY)\nAEC waits 14 days and re-evaluates\n\nThe AEC should almost never deviate from this framework unless there is an extraordinary event. The AEC can make changes to the variables in this framework with the approval of a DAO proposal. ACX and WBTC sit outside of this framework given there are no comparisons as competing bridges do not transfer these assets. A separate governance proposal will be needed to adjust emissions for these assets.\nAEC Long Term Objective\nThe AEC will set and manage a long term plan for ACX emissions to ensure the Across DAO does not deplete its treasury too quickly and has assets for future growth and other initiatives. As an illustration, the Across DAO currently has 366MM ACX in its treasury and is spending about 194.5K ACX in base emissions per day and possibly as much as 396K ACX per day if LPs all have a max multiplier. At the high end of this emissions rate the Across DAO would deplete its reserves in about 2.5 years.\nWhen thinking about emissions, the Across DAO should incentivize more heavily in the early years to help bootstrap growth by attracting LP capital. As the protocol picks up adoption and finds more efficiencies, resulting in more volumes and revenue for LPs, less ACX incentives are needed. Over the long term, the ideal scenario is to have bridge fees be the sole source of revenue that attract LPs to provide capital. As a conservative estimate, Across should be able to reach this goal in less than 5 years. With this target in mind, the AEC should decrease emissions each quarter by an amount that will ensure ACX reserved for incentives will not be depleted until the end of 2028 (5 years from now). Here are the initial numbers the AEC will consider:\n\nTotal ACX in the Across DAO is 366,432,519\nOf the 1B ACX minted, the DAO should use no more than 400MM for incentives (40%)\nGiven the DAO has already rewarded 126MM to LPs, there would only be 274MM ACX remaining for possible LP incentives.\nAt a current daily emissions rate of 295.25K (average between base and max multiplier) and a reduction of roughly 25% (assuming the AEC takes action after this proposal), the DAO would need to decrease emissions by 4.5% each quarter to ensure this ACX allocation for incentives is not depleted before the end of 2028\nA spreadsheet is built to illustrate these numbers and assumptions can be adjusted as needed.\nNote: The Risk Labs data team is currently working on calculating a more precise daily emissions rate that will be available on a Dune dashboard. Long term action will not be taken by the AEC until this is finalized.\n\nTo summarize, unless voted for a change by ACX token holders, the AEC will modify total base emissions quarterly to ensure no more than a total of 400MM ACX is ever used for LP incentives and that this allocation will not be depleted before December 31, 2028.\nSpecification & Implementation:\nThe following steps will be taken to implement the ACX Emissions Committee (AEC):\n\nThe Across DAO treasury is the current owner of the Accelerating Distributor contract. ACX token holders will vote on Snapshot to transfer ownership to 0x2e510146c6fCC90Ffc8087925AcC06C9fd0F5384, which is a 3 of 5 multisig that consists of members of the AEC committee. If successful, this transaction will be executed via the oSnap module which is already implemented. The initial members and signers of the AEC are the authors of this proposal who are Risk Labs team members with financial markets, web3 product management and data analysis expertise.\nThe following are their wallet addresses:\n0x1d933Fd71FF07E69f066d50B39a7C34EB3b69F05\n0xAf9C500a6FF28D541D1BA9E912db8485c7f6AF13\n0x868CF19464e17F76D6419ACC802B122c22D2FD34\n0x75752D7f6a6b9DB94258705DAe1814743077B9D8\n0xDFB0A775A44d309d939DCaEA081552aa4FE4025f\n\nThe AEC will monitor the Across pool utilization and Index Yield for ETH, USDC, USDT, and DAI. These numbers can be viewed directly from the Across front-end and competing bridge pages or through a public, custom Dune dashboard created by the Risk Labs data team.\n\nThe framework outlined in this proposal to achieve the short term and long term objective of the AEC will be included in the Docs site in a new section under “Token” called ACX Emissions Committee. The AEC will follow this framework, and the targets and variables can only be changed through a governance proposal.\n\nThe AEC will immediately announce to the Across community via Discord any action taken and explain the justification. The AEC will also provide a summary report each quarter. The Across community manager will assist in amplifying any announcements and will coordinate community calls.\n\nThe AEC members will initially be Risk Labs foundation team members. Risk Labs plans to include community members; however, contract work needs to be done so that permissioning of the Accelerating Distributor contract can be split so that the AEC can only control parameters and the Across DAO controls the withdrawal of rewards (if necessary).\n\nThe AEC is meant to be a permanent installation for the Across DAO. A vote to renew membership is not necessary unless a change to membership is made.\n\nVoting:\n\n Should the Across DAO form the ACX Emissions Committee (AEC)? The AEC would become the owner of the Accelerating Distributor contract and follow the framework outlined in this proposal to achieve its short term and long term objectives.\n\n 100%\n Yes\n\n 0%\n Abstain\n\n 0%\n No\n\n 6\n voters\n\n Closed Dec 2023\n\n ACX Emissions Committee Framework Update\n\n read \n\n 4\n min\n\n 1 month later\n\n Closed on Jan 15, 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 Reduce ACX emissions for Across ACX LPs\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 8\n\n Nov 2023\n\n ACX Emissions Committee Framework Update\n\n Proposals\n\n governance-updates\n\n Proposals\n\n 1\n\n Jun 2024\n\n Reduce ACX emissions for ACX LPs, WBTC LPs and wstETH/ACX LPs\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 11\n\n Aug 2024\n\n Stop ACX Emissions on ACX LP\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 4\n\n May 2025\n\n Reduce or Reallocate Across ACX LP emissions\n\n Ideas & Feedback\n\n liquidity\n\n Ideas & Feedback\n\n 2\n\n Sep 2023","tokens":4073,"squid":"spider-09","role":"Bridge Spider","at":1791342163497,"hash":"06d1ad64adfa13aff3f7aa28206249ab423c0a96"}
{"url":"https://eips.ethereum.org/EIPS/eip-1706","domain":"eips.ethereum.org","title":"EIP-1706: Disable SSTORE with gasleft lower than call stipend","text":"🛑 Withdrawn\n\n Standards Track: Core\n\n EIP-1706: Disable SSTORE with gasleft lower than call stipend\n\n Authors\n Alex Forshtat <alex@tabookey.com>, Yoav Weiss <yoav@tabookey.com>\n\n Created\n 2019-01-15\n\n Withdrawal Reason\n The authors prefer [EIP-2200](./eip-2200.md)\n\n Discussion Link\n https://github.com/alex-forshtat-tbk/EIPs/issues/1\n\n Requires\n\n EIP-1283\n\n Simple Summary\n\nThe proposal that had been accepted changes security properties of a large portion of an existing contract code base that may be infeasible to update and validate. This proposal will make the old assumptions hold even after a network upgrade.\n\n Abstract\n\nEIP-1283 significantly lowers the gas costs of writing to contract’s storage. This created a danger of a new kind of reentrancy attacks on existing contracts as Solidity by default grants a ‘stipend’ of 2300 gas to simple transfer calls.\nThis danger is easily mitigated if SSTORE is not allowed in low gasleft state, without breaking the backward compatibility and the original intention of this EIP.\n\n Motivation\n\nAn attack that is described in this article.\nExplicitly specifying the call stipend as an invariant will have a positive effect on Ethereum protocol security: \nhttps://www.reddit.com/r/ethereum/comments/agdqsm/security_alert_ethereum_constantinople/ee5uvjt\n\n Specification\n\nAdd the following condition to the SSTORE opcode gas cost calculation:\n\n If gasleft is less than or equal to 2300, fail the current call frame\nwith ‘out of gas’ exception.\n\n Rationale\n\nIn order to keep in place the implicit reentrancy protection of existing contracts, transactions should not be allowed to modify state if the remaining gas is lower then the 2300 stipend given to ‘transfer’/’send’ in Solidity.\nThese are other proposed remediations and objections to implementing them:\n\n Drop EIP-1283 and abstain from modifying SSTORE cost\n\n EIP-1283 is an important update\n It was accepted and implemented on test networks and in clients.\n\n Add a new call context that permits LOG opcodes but not changes to state.\n\n Adds another call type beyond existing regular/staticcall\n\n Raise the cost of SSTORE to dirty slots to >=2300 gas\n\n Makes net gas metering much less useful.\n\n Reduce the gas stipend\n\n Makes the stipend almost useless.\n\n Increase the cost of writes to dirty slots back to 5000 gas, but add 4800 gas to the refund counter\n\n Still doesn’t make the invariant explicit.\n Requires callers to supply more gas, just to have it refunded\n\n Add contract metadata specifying per-contract EVM version, and only apply SSTORE changes to contracts deployed with the new version.\n\n Backwards Compatibility\n\nPerforming SSTORE has never been possible with less than 5000 gas, so it does not introduce incompatibility to the Ethereum mainnet. Gas estimation should account for this requirement.\n\n Test Cases\n\nTest cases for an implementation are mandatory for EIPs that are affecting consensus changes. Other EIPs can choose to include links to test cases if applicable.\nTODO\n\n Implementation\n\nTODO\n\n Copyright\n\nCopyright and related rights waived via CC0.\n\n Citation\n Please cite this document as:\n\n Alex Forshtat <alex@tabookey.com>, Yoav Weiss <yoav@tabookey.com>, \"EIP-1706: Disable SSTORE with gasleft lower than call stipend [WITHDRAWN],\" Ethereum Improvement Proposals, no. 1706, January 2019. Available: https://eips.ethereum.org/EIPS/eip-1706.","tokens":843,"squid":"spider-05","role":"Spec Spider","at":1791342166661,"hash":"7f03da15dbab5ab36da16217d674c8ff4e0021ff"}
{"url":"https://jup.ag/stocks/tsla","domain":"jup.ag","title":"Tesla, Inc. Common Stock (TSLA) Tokenized Stock Price on Solana","text":"Underlying price$379.74+0.27% todayStock statsMarket cap$1.49TPrevious close$378.73Open$381.97Day's range$378.52 – $383.3352-week range$297.38 – $498.83Volume27.7MAvg volume38.6MP/E ratio393.22About Tesla, Inc. Common StockTesla is a vertically integrated battery electric vehicle automaker and developer of real-world artificial intelligence software, which includes autonomous driving and humanoid robots. The company has multiple vehicles in its fleet, which include a midsize sedan and crossover SUV in the entry-level luxury category, a luxury light truck, and a semitruck. Tesla also runs a robotaxi service in four US metropolitan areas. Global deliveries in 2025 were nearly 1.64 million vehicles. Additionally, the company sells batteries for stationary storage for residential and commercial properties, including utilities, solar panels, and solar roofs for energy generation. Tesla also owns a fast-charging network and a US auto insurance business.TickerTSLAAsset classEquityTokenized by2 issuersSectorConsumer DiscretionaryIndustryMotor Vehicles & Passenger Car BodiesEmployees134,785Websitetesla.comTesla, Inc. Common Stock FAQTSLA is Tesla, Inc. Common Stock stock, issued on Solana as a token that tracks the listed share. Each issuer mints its own version, so Tesla, Inc. Common Stock trades here as 2 tokens rather than one.Token prices are designed to track Tesla, Inc. Common Stock's listed shares, but they can differ because of issuer terms, liquidity, market hours, and trading activity.xStocks and Ondo issue the tokenized Tesla, Inc. Common Stock markets shown on Jupiter. Each issuer controls its own token and settlement terms.Trading availability depends on the issuer token and its market. Open an issuer's token page to check current liquidity and trading status.Use the Market swap on this page. Select the TSLA token in the swap to choose an issuer. Connect your wallet, choose the token you want to pay with, and enter an amount. Review the swap details before you submit, then confirm in your wallet when prompted. A swap requires an available trading route. Issuer terms and restrictions apply.Dividend treatment depends on the token issuer. A dividend paid on Tesla, Inc. Common Stock's listed shares does not guarantee a cash payment to token holders. Review each issuer's terms for how dividends and other corporate actions are handled.Read Ondo's corporate action policyRead xStocks' dividend and stock split policy","tokens":614,"squid":"spider-02","role":"Liquidity Spider","at":1791342172616,"hash":"942224b2084f4f073fb1f955df81f6ed997c27d9"}
{"url":"https://squidfunk.github.io/mkdocs-material/reference/admonitions/","domain":"squidfunk.github.io","title":"Admonitions - Material for MkDocs","text":"Admonitions¶ Admonitions, also known as call-outs, are an excellent choice for including side content without significantly interrupting the document flow. Material for MkDocs provides several different types of admonitions and allows for the inclusion and nesting of arbitrary content. Configuration¶ This configuration enables admonitions, allows to make them collapsible and to nest arbitrary content inside admonitions. Add the following lines to mkdocs.yml: markdown_extensions:\n - admonition\n - pymdownx.details\n - pymdownx.superfences\n See additional configuration options: Admonition Details SuperFences Admonition icons¶ 8.3.0 Each of the supported admonition types has a distinct icon, which can be changed to any icon bundled with the theme, or even a custom icon. Add the following lines to mkdocs.yml: theme:\n icon:\n admonition:\n <type>: <icon> \n Expand to show alternate icon sets Octicons FontAwesome theme:\n icon:\n admonition:\n note: octicons/tag-16\n abstract: octicons/checklist-16\n info: octicons/info-16\n tip: octicons/squirrel-16\n success: octicons/check-16\n question: octicons/question-16\n warning: octicons/alert-16\n failure: octicons/x-circle-16\n danger: octicons/zap-16\n bug: octicons/bug-16\n example: octicons/beaker-16\n quote: octicons/quote-16\n theme:\n icon:\n admonition:\n note: fontawesome/solid/note-sticky\n abstract: fontawesome/solid/book\n info: fontawesome/solid/circle-info\n tip: fontawesome/solid/bullhorn\n success: fontawesome/solid/check\n question: fontawesome/solid/circle-question\n warning: fontawesome/solid/triangle-exclamation\n failure: fontawesome/solid/bomb\n danger: fontawesome/solid/skull\n bug: fontawesome/solid/robot\n example: fontawesome/solid/flask\n quote: fontawesome/solid/quote-left\n Usage¶ Admonitions follow a simple syntax: a block starts with !!!, followed by a single keyword used as a type qualifier. The content of the block follows on the next line, indented by four spaces: Admonition!!! note\n\n Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nulla et euismod\n nulla. Curabitur feugiat, tortor non consequat finibus, justo purus auctor\n massa, nec semper lorem quam in massa.\n Note Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nulla et euismod nulla. Curabitur feugiat, tortor non consequat finibus, justo purus auctor massa, nec semper lorem quam in massa. Changing the title¶ By default, the title will equal the type qualifier in titlecase. However, it can be changed by adding a quoted string containing valid Markdown (including links, formatting, ...) after the type qualifier: Admonition with custom title!!! note \"Phasellus posuere in sem ut cursus\"\n\n Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nulla et euismod\n nulla. Curabitur feugiat, tortor non consequat finibus, justo purus auctor\n massa, nec semper lorem quam in massa.\n Phasellus posuere in sem ut cursus Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nulla et euismod nulla. Curabitur feugiat, tortor non consequat finibus, justo purus auctor massa, nec semper lorem quam in massa. Nested admonitions¶ You can also include nested admonitions in your documentation. To do this, you can use your existing admonitions and indent the desired ones: Nested Admonition!!! note \"Outer Note\"\n\n Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nulla et euismod\n nulla. Curabitur feugiat, tortor non consequat finibus, justo purus auctor\n massa, nec semper lorem quam in massa.\n\n !!! note \"Inner Note\"\n\n Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nulla et euismod\n nulla. Curabitur feugiat, tortor non consequat finibus, justo purus auctor\n massa, nec semper lorem quam in massa.\n Outer Note Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nulla et euismod nulla. Curabitur feugiat, tortor non consequat finibus, justo purus auctor massa, nec semper lorem quam in massa. Inner Note Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nulla et euismod nulla. Curabitur feugiat, tortor non consequat finibus, justo purus auctor massa, nec semper lorem quam in massa. Removing the title¶ Similar to changing the title, the icon and title can be omitted entirely by adding an empty string directly after the type qualifier. Note that this will not work for collapsible blocks: Admonition without title!!! note \"\"\n\n Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nulla et euismod\n nulla. Curabitur feugiat, tortor non consequat finibus, justo purus auctor\n massa, nec semper lorem quam in massa.\n Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nulla et euismod nulla. Curabitur feugiat, tortor non consequat finibus, justo purus auctor massa, nec semper lorem quam in massa. Collapsible blocks¶ When Details is enabled and an admonition block is started with ??? instead of !!!, the admonition is rendered as an expandable block with a small toggle on the right side: Admonition, collapsible??? note\n\n Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nulla et euismod\n nulla. Curabitur feugiat, tortor non consequat finibus, justo purus auctor\n massa, nec semper lorem quam in massa.\n Note Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nulla et euismod nulla. Curabitur feugiat, tortor non consequat finibus, justo purus auctor massa, nec semper lorem quam in massa. Adding a + after the ??? token renders the block expanded: Admonition, collapsible and initially expanded???+ note\n\n Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nulla et euismod\n nulla. Curabitur feugiat, tortor non consequat finibus, justo purus auctor\n massa, nec semper lorem quam in massa.\n Note Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nulla et euismod nulla. Curabitur feugiat, tortor non consequat finibus, justo purus auctor massa, nec semper lorem quam in massa. Inline blocks¶ Admonitions can also be rendered as inline blocks (e.g., for sidebars), placing them to the right using the inline + end modifiers, or to the left using only the inline modifier: inline end inline Lorem ipsum Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nulla et euismod nulla. Curabitur feugiat, tortor non consequat finibus, justo purus auctor massa, nec semper lorem quam in massa. !!! info inline end \"Lorem ipsum\"\n\n Lorem ipsum dolor sit amet, consectetur\n adipiscing elit. Nulla et euismod nulla.\n Curabitur feugiat, tortor non consequat\n finibus, justo purus auctor massa, nec\n semper lorem quam in massa.\n Use inline end to align to the right (left for rtl languages). Lorem ipsum Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nulla et euismod nulla. Curabitur feugiat, tortor non consequat finibus, justo purus auctor massa, nec semper lorem quam in massa. !!! info inline \"Lorem ipsum\"\n\n Lorem ipsum dolor sit amet, consectetur\n adipiscing elit. Nulla et euismod nulla.\n Curabitur feugiat, tortor non consequat\n finibus, justo purus auctor massa, nec\n semper lorem quam in massa.\n Use inline to align to the left (right for rtl languages). Important: admonitions that use the inline modifiers must be declared prior to the content block you want to place them beside. If there's insufficient space to render the admonition next to the block, the admonition will stretch to the full width of the viewport, e.g., on mobile viewports. Supported types¶ Following is a list of type qualifiers provided by Material for MkDocs, whereas the default type, and thus fallback for unknown type qualifiers, is note1: note Note Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nulla et euismod nulla. Curabitur feugiat, tortor non consequat finibus, justo purus auctor massa, nec semper lorem quam in massa. abstract Abstract Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nulla et euismod nulla. Curabitur feugiat, tortor non consequat finibus, justo purus auctor massa, nec semper lorem quam in massa. info Info Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nulla et euismod nulla. Curabitur feugiat, tortor non consequat finibus, justo purus auctor massa, nec semper lorem quam in massa. tip Tip Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nulla et euismod nulla. Curabitur feugiat, tortor non consequat finibus, justo purus auctor massa, nec semper lorem quam in massa. success Success Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nulla et euismod nulla. Curabitur feugiat, tortor non consequat finibus, justo purus auctor massa, nec semper lorem quam in massa. question Question Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nulla et euismod nulla. Curabitur feugiat, tortor non consequat finibus, justo purus auctor massa, nec semper lorem quam in massa. warning Warning Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nulla et euismod nulla. Curabitur feugiat, tortor non consequat finibus, justo purus auctor massa, nec semper lorem quam in massa. failure Failure Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nulla et euismod nulla. Curabitur feugiat, tortor non consequat finibus, justo purus auctor massa, nec semper lorem quam in massa. danger Danger Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nulla et euismod nulla. Curabitur feugiat, tortor non consequat finibus, justo purus auctor massa, nec semper lorem quam in massa. bug Bug Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nulla et euismod nulla. Curabitur feugiat, tortor non consequat finibus, justo purus auctor massa, nec semper lorem quam in massa. example Example Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nulla et euismod nulla. Curabitur feugiat, tortor non consequat finibus, justo purus auctor massa, nec semper lorem quam in massa. quote Quote Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nulla et euismod nulla. Curabitur feugiat, tortor non consequat finibus, justo purus auctor massa, nec semper lorem quam in massa. Customization¶ Classic admonitions¶ Prior to version 8.5.6, admonitions had a slightly different appearance: Note Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nulla et euismod nulla. Curabitur feugiat, tortor non consequat finibus, justo purus auctor massa, nec semper lorem quam in massa. If you want to restore this appearance, add the following CSS to an additional style sheet: docs/stylesheets/extra.css mkdocs.yml .md-typeset .admonition,\n.md-typeset details {\n border-width: 0;\n border-left-width: 4px;\n}\n extra_css:\n - stylesheets/extra.css\n Custom admonitions¶ If you want to add a custom admonition type, all you need is a color and an *.svg icon. Copy the icon's code from the .icons folder and add the following CSS to an additional style sheet: docs/stylesheets/extra.css mkdocs.yml :root {\n --md-admonition-icon--pied-piper: url('data:image/svg+xml;charset=utf-8,<svg xmlns=\"http://www.w3.org/2000/svg\" viewBox=\"0 0 576 512\"><path d=\"M244 246c-3.2-2-6.3-2.9-10.1-2.9-6.6 0-12.6 3.2-19.3 3.7l1.7 4.9zm135.9 197.9c-19 0-64.1 9.5-79.9 19.8l6.9 45.1c35.7 6.1 70.1 3.6 106-9.8-4.8-10-23.5-55.1-33-55.1zM340.8 177c6.6 2.8 11.5 9.2 22.7 22.1 2-1.4 7.5-5.2 7.5-8.6 0-4.9-11.8-13.2-13.2-23 11.2-5.7 25.2-6 37.6-8.9 68.1-16.4 116.3-52.9 146.8-116.7C548.3 29.3 554 16.1 554.6 2l-2 2.6c-28.4 50-33 63.2-81.3 100-31.9 24.4-69.2 40.2-106.6 54.6l-6.3-.3v-21.8c-19.6 1.6-19.7-14.6-31.6-23-18.7 20.6-31.6 40.8-58.9 51.1-12.7 4.8-19.6 10-25.9 21.8 34.9-16.4 91.2-13.5 98.8-10zM555.5 0l-.6 1.1-.3.9.6-.6zm-59.2 382.1c-33.9-56.9-75.3-118.4-150-115.5l-.3-6c-1.1-13.5 32.8 3.2 35.1-31l-14.4 7.2c-19.8-45.7-8.6-54.3-65.5-54.3-14.7 0-26.7 1.7-41.4 4.6 2.9 18.6 2.2 36.7-10.9 50.3l19.5 5.5c-1.7 3.2-2.9 6.3-2.9 9.8 0 21 42.8 2.9 42.8 33.6 0 18.4-36.8 60.1-54.9 60.1-8 0-53.7-50-53.4-60.1l.3-4.6 52.3-11.5c13-2.6 12.3-22.7-2.9-22.7-3.7 0-43.1 9.2-49.4 10.6-2-5.2-7.5-14.1-13.8-14.1-3.2 0-6.3 3.2-9.5 4-9.2 2.6-31 2.9-21.5 20.1L15.9 298.5c-5.5 1.1-8.9 6.3-8.9 11.8 0 6 5.5 10.9 11.5 10.9 8 0 131.3-28.4 147.4-32.2 2.6 3.2 4.6 6.3 7.8 8.6 20.1 14.4 59.8 85.9 76.4 85.9 24.1 0 58-22.4 71.3-41.9 3.2-4.3 6.9-7.5 12.4-6.9.6 13.8-31.6 34.2-33 43.7-1.4 10.2-1 35.2-.3 41.1 26.7 8.1 52-3.6 77.9-2.9 4.3-21 10.6-41.9 9.8-63.5l-.3-9.5c-1.4-34.2-10.9-38.5-34.8-58.6-1.1-1.1-2.6-2.6-3.7-4 2.2-1.4 1.1-1 4.6-1.7 88.5 0 56.3 183.6 111.5 229.9 33.1-15 72.5-27.9 103.5-47.2-29-25.6-52.6-45.7-72.7-79.9zm-196.2 46.1v27.2l11.8-3.4-2.9-23.8zm-68.7-150.4l24.1 61.2 21-13.8-31.3-50.9zm84.4 154.9l2 12.4c9-1.5 58.4-6.6 58.4-14.1 0-1.4-.6-3.2-.9-4.6-26.8 0-36.9 3.8-59.5 6.3z\"/></svg>')\n}\n.md-typeset .admonition.pied-piper,\n.md-typeset details.pied-piper {\n border-color: rgb(43, 155, 70);\n}\n.md-typeset .pied-piper > .admonition-title,\n.md-typeset .pied-piper > summary {\n background-color: rgba(43, 155, 70, 0.1);\n}\n.md-typeset .pied-piper > .admonition-title::before,\n.md-typeset .pied-piper > summary::before {\n background-color: rgb(43, 155, 70);\n -webkit-mask-image: var(--md-admonition-icon--pied-piper);\n mask-image: var(--md-admonition-icon--pied-piper);\n}\n extra_css:\n - stylesheets/extra.css\n After applying the customization, you can use the custom admonition type: Admonition with custom type!!! pied-piper \"Pied Piper\"\n\n Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nulla et\n euismod nulla. Curabitur feugiat, tortor non consequat finibus, justo\n purus auctor massa, nec semper lorem quam in massa.\n Pied Piper Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nulla et euismod nulla. Curabitur feugiat, tortor non consequat finibus, justo purus auctor massa, nec semper lorem quam in massa. Previously, some of the supported types defined more than one qualifier. For example, authors could use summary or tldr as alternative qualifiers to render an abstract admonition. As this increased the size of the CSS that is shipped with Material for MkDocs, the additional type qualifiers are now all deprecated and will be removed in the next major version. This will also be mentioned in the upgrade guide. ↩","tokens":3472,"squid":"spider-06","role":"Security Spider","at":1791342173816,"hash":"a8b05d4ef2e747f34ab46ad8bcda360c4601d9db"}
{"url":"https://eips.ethereum.org/EIPS/eip-1884","domain":"eips.ethereum.org","title":"EIP-1884: Repricing for trie-size-dependent opcodes","text":"🎉 Final\n\n Standards Track: Core\n\n EIP-1884: Repricing for trie-size-dependent opcodes\n\n Authors\n Martin Holst Swende (@holiman)\n\n Created\n 2019-03-28\n\n Requires\n\n EIP-150, \n\n EIP-1052\n\n Simple Summary\n\nThis EIP proposes repricing certain opcodes, to obtain a good balance between gas expenditure and resource consumption.\n\n Abstract\n\nThe growth of the Ethereum state has caused certain opcodes to be more resource-intensive at this point than \nthey were previously. This EIP proposes to raise the gasCost for those opcodes.\n\n Motivation\n\nAn imbalance between the price of an operation and the resource consumption (CPU time, memory etc)\nhas several drawbacks:\n\n It could be used for attacks, by filling blocks with underpriced operations which causes excessive block processing time.\n Underpriced opcodes cause a skewed block gas limit, where sometimes blocks finish quickly but other blocks with similar gas use finish slowly.\n\nIf operations are well-balanced, we can maximise the block gaslimit and have a more stable processing time.\n\n Specification\n\nAt block N,\n\n The SLOAD (0x54) operation changes from 200 to 800 gas,\n The BALANCE (0x31) operation changes from 400 to 700 gas,\n The EXTCODEHASH (0x3F) operation changes from 400 to 700 gas,\n A new opcode, SELFBALANCE is introduced at 0x47.\n\n SELFBALANCE pops 0 arguments off the stack,\n SELFBALANCE pushes the balance of the current address to the stack,\n SELFBALANCE is priced as GasFastStep, at 5 gas.\n\n Rationale\n\nHere are two charts, taken from a full sync using Geth. The execution time was measured for every opcode, and aggregated for 10K blocks. These bar charts show the top 25 ‘heavy’ opcodes in the ranges 5M to 6M and 6M to 7M:\n\nNote: It can also be seen that the SLOAD moves towards the top position. The GASPRICE (0x3a) opcode has position one which I believe can be optimized away within the client – which is not the case with SLOAD/BALANCE.\n\nHere is another chart, showing a full sync with Geth. It represents the blocks 0 to 5.7M, and highlights what the block processing time is spent on.\n\nIt can be seen that storage_reads and account_reads are the two most significant factors contributing to the block processing time.\n\n SLOAD\n\nSLOAD was repriced at EIP-150, from 50 to 200. \nThe following graph shows a go-ethereum full sync, where each data point represents\n 10K blocks. During those 10K blocks, the execution time for the opcode was aggregated.\n\nIt can be seen that the repricing at EIP-150 caused a steep drop, from around 67 to 23. \nAround block 5M, it started reaching pre-EIP-150 levels, and at block 7M \nit was averaging on around 150 - more than double pre-eip-150 levels.\n\nIncreasing the cost of SLOAD by 4 would bring it back down to around 40. \nIt is to be expected that it will rise again in the future, and may need future repricing, unless \nstate clearing efforts are implemented before that happens.\n\n BALANCE\n\nBALANCE (a.k.a EXTBALANCE) is an operation which fetches data from the state trie. It was repriced at EIP-150 from 20 to 400.\n\nIt is comparable to EXTCODESIZE and EXTCODEHASH, which are priced at 700 already.\n\nIt has a built-in high variance, since it is often used for checking the balance of this, \nwhich is an inherently cheap operation, however, it can be used to lookup the balance of arbitrary account which often require trie (disk) access.\n\nIn hindsight, it might have been a better choice to have two \nopcodes: EXTBALANCE(address) and SELFBALANCE, and have two different prices.\n\n This EIP proposes to extend the current opcode set.\n\n Unfortunately, the opcode span 0x3X is already full, hence the suggestion to place SELFBALANCE in the 0x4X range.\n As for why it is priced at 5 (GasFastStep) instead of 2 (GasQuickStep), like other similar operations: the EVM execution engine still needs a lookup into the (cached) trie, and balance, unlike gasPrice or timeStamp, is not constant during the execution, so it has a bit more inherent overhead.\n\n EXTCODEHASH\n\nEXTCODEHASH was introduced in Constantinople, with EIP-1052. It was priced at 400 with the reasoning:\n\n The gas cost is the same as the gas cost for the BALANCE opcode because the execution of the EXTCODEHASH requires the same account lookup as in BALANCE.\n\nErgo, if we increase BALANCE, we should also increase EXTCODEHASH\n\n Backwards Compatibility\n\nThe changes require a hardfork. The changes have the following consequences:\n\n Certain calls will become more expensive.\n Default-functions which access the storage and may in some cases require more than2300 gas (the minimum gas that is always available in calls).\n Contracts that assume a certain fixed gas cost for calls (or internal sections) may cease to function.\n\n A fixed gas cost is specified in ERC-165 and implementations of this interface do use the affected opcodes.\n\n The ERC-165 method supportsInterface must return a bool and use at most 30,000 gas.\n The two example implementations from the EIP were, at the time of writing\n\n 586 gas for any input, and\n 236 gas, but increases linearly with a higher number of supported interfaces\n\n It is unlikely that any ERC-165 supportsInterface implementation will go above 30.000 gas. That would require that the second variant is used, and thirty:ish interfaces are supported.\n However, these operations have already been repriced earlier, so there is a historical precedent that ‘the gascost for these operations may change’, which should have prevented such fixed-gas-cost assumptions from being implemented.\n\nI expect that certain patterns will be less used, for example the use of multiple modifiers which SLOADs the same opcode will be merged into one. It may also lead to less log operations containing SLOADed values that are not strictly necessary.\n\n Test Cases\n\nTestcases that should be implemented:\n\n Test that selfbalance == balance(address),\n Test that balance(this) costs as before,\n Test that selfbalance does not pop from stack\n Gascost verification of SLOAD, EXTCODEHASH and SELFBALANCE\n Verify that SELFBALANCE is invalid before Istanbul\n\nSome testcases have been implemented as statetests at https://github.com/holiman/IstanbulTests/tree/master/GeneralStateTests\n\n Implementation\n\nThis EIP has not yet been implemented in any client. \nBoth these opcodes have been repriced before, and the client internals for managing reprices are already in place.\n\n SELFBALANCE\n\nThis is the implementation for the new opcode in go-ethereum:\n\nfunc opSelfBalance(pc *uint64, interpreter *EVMInterpreter, contract *Contract, memory *Memory, stack *Stack) ([]byte, error) {\n stack.push(interpreter.intPool.get().Set(interpreter.evm.StateDB.GetBalance(contract.Address())\n return nil, nil\n}\n\n Security considerations\n\n See backwards compatibility section.\n There are no special edgecases regarding SELFBALANCE, if we define it as BALANCE with address instead of popping an address from the stack – since BALANCE is already well-defined.\n It should be investigated if Solidity contains any hardcoded expectations on the gas cost of these operations.\n In many cases, a recipient of ether from a CALL will want to issue a LOG. The LOG operation costs 375 plus 375 per topic. If the LOG also wants to do an SLOAD, this change may make some such transfers fail.\n\n Copyright\n\nCopyright and related rights waived via CC0.\n\n Citation\n Please cite this document as:\n\n Martin Holst Swende (@holiman), \"EIP-1884: Repricing for trie-size-dependent opcodes,\" Ethereum Improvement Proposals, no. 1884, March 2019. Available: https://eips.ethereum.org/EIPS/eip-1884.","tokens":1883,"squid":"spider-05","role":"Spec Spider","at":1791342177447,"hash":"172dd2e561eab05d1a596fa7b3460483d6f4067b"}
{"url":"https://help.phantom.com/articles/add-wallets-and-accounts-to-your-phantom-wallet-28355310978067","domain":"help.phantom.com","title":"Add wallets and accounts to your Phantom wallet","text":"Add wallets and accounts to your Phantom walletAfter signing in or importing your wallet into Phantom, you can add more wallets and accounts to your existing wallet. You can create another account from your current recovery phrase, import another recovery phrase or private key, connect a Ledger hardware wallet, or add an address you can watch.Before you start #This articles assumes that you already set up your Phantom wallet.Create a new account in your existing wallet #Creates another account from your existing Secret Recovery Phrase. Use this to keep funds, apps, or activities separate without creating a new wallet. If you have imported multiple recovery phrases, you can choose which one to derive this account from.\n Note: If you imported an existing wallet and some of your\n previously used accounts aren't showing, see\n Accounts are missing after importing.\n Mobile app #\nOpen the Phantom mobile app.\nTap your profile avatar in the upper left.\nGo to Settings > Manage Accounts.\nTap the + button in the upper right.\nTap Create New Account.\nTap Create.\nBrowser extension #\nClick the Phantom browser extension icon.\nClick your profile avatar in the upper left.\nClick Add Account (the plus icon).\nClick Create New Account.\nClick Create.\nConnect a hardware wallet #Adds accounts from a supported Ledger hardware wallet.\nUse a Ledger wallet with Phantom mobile app\nUse a Ledger wallet with the Phantom browser extension\nImport an additional wallet using a recovery phrase #Imports another wallet and its accounts into Phantom. You can add this recovery phrase as an additional sign-in method for accessing your Phantom profile.Mobile app #\nOpen the Phantom mobile app.\nTap your profile avatar in the upper left.\nGo to Settings > Manage Accounts.\nTap the + button in the upper right.\nTap Import Recovery Phrase.\nEnter your recovery phrase in the correct order.\nTap Import.\nBrowser extension #\nClick the Phantom browser extension icon.\nClick your profile avatar in the upper left.\nClick Add Account (the plus icon).\nClick Import Recovery Phrase.\nEnter your recovery phrase in the correct order.\nClick Import.\nImport an additional wallet using a private key #Imports a single account on one network, for example, Solana or Ethereum.Mobile app #\nOpen the Phantom mobile app.\nTap your profile avatar in the upper left.\nGo to Settings > Manage Accounts.\nTap the + button in the upper right.\nTap Import Private Key.\nChoose the network.\nPaste your private key.\nTap Import.\nBrowser extension #\nClick the Phantom browser extension icon.\nClick your profile avatar in the upper left.\nClick Add Account (the plus icon).\nClick Import Private Key.\nEnter a name for the account.\nChoose the network.\nPaste your private key.\nClick Import.\nAdd a watch-only address #Adds a public address and lets you follow its activities. You can track balances and activity, but can't send or sign transactions.Mobile app #\nOpen the Phantom mobile app.\nTap your profile avatar in the upper left.\nGo to Settings > Manage Accounts.\nTap the + button in the upper right.\nTap Watch Address.\nChoose the network.\nEnter a name and paste the wallet's public address.\nTap Import.\nBrowser extension #\nClick the Phantom browser extension icon.\nClick your profile avatar in the upper left.\nClick Add Account (the plus icon).\nClick Watch Address.\nChoose the network.\nEnter a name and paste the wallet's public address.\nClick Import.\nUnderstand how imported wallets behave #If you already set up a Phantom wallet (\"primary\"), and then import an additional Secret Recovery Phrase or private key, Phantom treats the imported recovery phrase or private key as a separate wallet rather than merging it with your primary wallet. For example, if you import an additional \"Recovery Phrase 2\" into the mobile app, it won't show up on the browser extension. If you reset Phantom on mobile and restore your primary wallet, \"Recovery Phrase 2\" won't appear either. You'll need to import it again manually.Keep a record of every recovery phrase or private key you import. If you reset Phantom and restore using only your primary wallet's recovery phrase or Google or Apple account, your imported wallets won't return.Related articlesView your recovery phrase or private keys in PhantomYour Secret Recovery Phrase and private keys are the backup credentials for your wallet. Export them before switching devices, resetting Phantom, or whenever you need a secure offline backup. Even if ...Updated 21 days agoUse a Ledger wallet with the Phantom mobile appYou can add accounts from a Ledger hardware wallet to the Phantom mobile app over Bluetooth. This works for both new setups and existing Phantom wallets. For a full list of supported hardware wallets,...Updated 15 days agoManage your accounts in PhantomYour Phantom wallet can hold multiple accounts. Each account includes addresses on every supported network, so you can use different accounts for different purposes, like long-term holdings, predictio...Updated a month agoIf a feature is unavailable in your country or regionIf you're seeing a message in Phantom when trying to access a feature such as perps, predictions, or tokenized stocks, this means the feature you're trying to use isn't available in your location.Updated 2 days agoManage your Phantom usernameYour username is the @handle that shows on your Phantom profile. It's the public-facing identity others use to transfer you Cash, find you in chats, and follow your activity. A username is required to...Updated 12 days ago","tokens":1374,"squid":"spider-10","role":"Tooling Spider","at":1791342185445,"hash":"135386f3314e74e4e62984e33326ba7bb7d7dadb"}
{"url":"https://docs.switchboard.xyz/docs-by-chain/evm/randomness","domain":"docs.switchboard.xyz","title":"Randomness | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.Blockchain users want randomness for many applications like gaming, NFT mints, lotteries, and more. However, this poses a fundamental challenge to blockchains, which are deterministic computers replicated across many nodes across the globe. Each node needs to produce the exact same output when given the same sequence of inputs.Imagine if an on-chain lottery was deciding whether to mint an NFT to Alice or Bob. If blockchain nodes ran their own randomness and some decided that the NFT would go to Alice, and others to Bob, there would be a state mismatch.This is where oracles come in. An oracle can run the randomness off-chain and then post a single result to the blockchain, ensuring that all nodes agree on the result of the randomness.However, as a third-party source of randomness, it's critical to make sure that nefarious actors cannot control the oracle and bias the randomness in their favor.As an oracle provider, Switchboard's network serves as a trusted and verified third-party that can post fair random numbers to the blockchain.Switchboard's approachSwitchboard leverages Trusted Execution Environments (TEEs), which are protected areas inside of a computer's processing unit that cannot be altered or inspected. This means:No one, including the oracle operator, can alter the code that’s running on the TEEsNo one, including the oracle operator, can see what’s going on inside the chip, only inputs and outputs.This means that Switchboard oracles can generate safe and fair randomness that is free from malicious influence. As an extra layer of protection, Switchboard network incentives ensure that oracle oeprators that misbehave by experiencing downtime or withholding results can have their $SWTCH stake slashed.How to Use Switchboard RandomnessFor the current EVM interface, the public randomness flow uses createRandomness, settleRandomness, and getRandomness. revealRandomness and getRandomnessResult are not current Switchboard methods.The canonical JS/TS ABI lives at @switchboard-xyz/on-demand-solidity/abis/Switchboard.json.To understand the flow, it's helpful to visualize the following 5 parties.Alice: blockchain userApp: on-chain applicationSwitchboard Contract: on-chain contract that handles anything Switchboard-related.Crossbar: server that helps you talk to oraclesOracle: generates randomnessThere are two stages, requesting and resolving the randomness.Request RandomnessFirst, Alice talks to the App requesting some random event.The App then generates a randomness request with a unique ID and sends it to the Switchboard contract.The Switchboard contract responds to the App with an oracle assignment.The App responds to Alice with the oracle assignment and randomness ID.Resolve RandomnessAlice sends the oracle assignment, randomness ID, and some other data to Crossbar to get the randomness.Crossbar asks the Oracle to generate randomness.The Oracle creates a randomness object and sends it to Crossbar which passes it back to Alice.Alice sends the randomness object to the App.The App asks the Switchboard contract to verify that the randomness it received from Alice is correct.If all is well, the Switchboard contract sends verification to the App, resolving the random event.--PreviousSurge TutorialNextRandomness TutorialLast updated 5 months ago","tokens":848,"squid":"spider-08","role":"Oracle Spider","at":1791342191847,"hash":"4261afa5979ab6e85c6595b5f4e0a2cb7c4b81e0"}
{"url":"https://help.phantom.com/articles/4407240978195","domain":"help.phantom.com","title":"Recover missing wallets and fix import issues","text":"Recover missing wallets and fix import issuesIf a wallet won’t import into Phantom, your accounts are missing after import, your recovery phrase isn’t working, or you’re seeing private key errors, this article can help.Accounts are missing after signing in or importing a wallet #Missing accounts are often still recoverable. In many cases the wallet imported successfully, but not every account was added automatically.After signing in with a Google or Apple account #When signing in to Phantom with a Google or Apple account, Phantom restores only the first account in your wallet automatically. Any other accounts with onchain activities, you need to add manually.\nTo add missing accounts, follow these steps in Add wallets and accounts to your Phantom wallet.\nRepeat until all expected accounts appear.\nAfter importing a recovery phrase #When importing a recovery phrase, Phantom restores accounts with onchain activity (sends, receives, or swaps) from oldest to newest. Accounts with no balance or transaction history may not appear automatically.\nTo add missing accounts, follow these steps in Add wallets and accounts to your Phantom wallet.\nRepeat until all expected accounts appear.\nIf accounts still don't appear, reset Phantom following the steps in Reset the Phantom app.\nIf accounts still don't appear after a reset:\nThis may not be the recovery phrase for the wallet you expected.\nThe wallet may use a derivation path Phantom doesn't support.\nEmpty wallet after signing in with Google or Apple #If your wallet appears empty after signing in with Google or Apple, you may have signed in with a different provider than the one you originally used to create your wallet.For example, if you created your wallet with Google but signed in with Apple using the same email address, Phantom creates a separate wallet. The same applies if you originally used Apple and later signed in with Google.Try signing in with the other provider. If you used Google to create your wallet, sign in with Google. If you used Apple, sign in with Apple.Recovery phrase not working #You may see one of these messages when importing your Secret Recovery Phrase:\n\"Invalid secret recovery phrase\"\n\"Phrase needs to be at least 12 words\"\n\"Word 1 is incorrect or misspelled\"\n\"Incorrect format\"\nThese messages usually mean one or more words are incorrect. A recovery phrase must:\nContain exactly 12 or 24 words.\nBe entered in the correct order.\nUse correct spelling. You can verify spelling using the BIP-39 English word list.\nIn the mobile app, have one space between each word. In the browser extension, one word in each cell.\nWords are correct but import still fails #If you've verified spelling, order, and spacing but the import still fails, check where the wallet was originally created.Some wallet apps generate accounts using different derivation paths. In that case:\nTry importing the private key instead, if available.\nRe-export the recovery phrase from the original app if you still have access.\nIf Phantom can't derive the same accounts, you may need to continue using the original app for those accounts.\nIf the recovery phrase is correct and Phantom supports that wallet's derivation path, the expected accounts appear after import.Recovery phrase rejected by another app #Some trading platforms and tools, such as Axiom or Padre, require a private key rather than a recovery phrase. If your Phantom recovery phrase is rejected on one of these platforms, this is usually why.Only export a private key if you trust the platform and understand why it needs direct account access.\nTo export your private key from Phantom, follow the instructions in View your recovery phrase or private keys in Phantom.\nOnce exported, paste the private key into the third-party platform.\nPrivate key not working #Make sure you're selecting the correct network when importing a private key. Selecting the wrong network causes an \"Incorrect format\" error.Seeing accounts you don't recognize #If you import a recovery phrase and see unfamiliar accounts, one of the following is likely:\n\nThe recovery phrase is different. Recovery phrases are cryptographically exact. Even a single incorrect word generates a completely different wallet.\n\nThe wallet generated accounts differently. Some apps create accounts in ways Phantom can't replicate.\nTo find out which applies, try the following:\nImport the same recovery phrase into the app that was originally used to create the wallet.\nCheck whether your expected accounts appear there.\nIf the accounts appear in the original app but not in Phantom, you may need to continue using that app for those accounts.If the accounts do not appear in the original app either, the recovery phrase is not the one you expected.Restore full access to a watch-only wallet #If your wallet has become watch-only, you can still view your balances and activity, but you can’t approve transactions.This can happen if Phantom’s authentication session expires. Your funds remain safe on the blockchain.To restore access, reset the Phantom app and then sign back in with the exact same email/social login method you originally used to create this wallet.Before resetting, make sure you still have access to that same login method and any PIN required to restore the wallet. Do not create a new wallet after resetting; choose the option to restore/sign back in to your existing wallet.Related articlesDownload Phantom on mobileDownload the Phantom app for free on iOS or Android. Only download from the official links in this article. Scammers sometimes upload fake apps that can steal your funds.Updated 2 months agoUpdate the Phantom browser extensionPhantom usually updates automatically. If you want to check for updates right away, you can refresh extensions manually in your browser. Updating the extension does not delete your wallets or funds.Updated a month agoSign in to or import an existing Phantom walletIf you already have a Phantom wallet, or want to import an existing wallet, you're in the right place.Updated 15 days agoGet started with PhantomNew to Phantom? Start by downloading the app, creating your wallet, and adding funds when you’re ready.Updated 12 days agoCreate a new Phantom walletYou can create a new Phantom wallet in two ways:Updated 20 days ago","tokens":1567,"squid":"spider-10","role":"Tooling Spider","at":1791342195560,"hash":"75ef6cf8ceca48924f96d09d9e6df743e6653061"}
{"url":"https://docs.switchboard.xyz/docs-by-chain/evm/randomness/randomness-tutorial","domain":"docs.switchboard.xyz","title":"Randomness Tutorial | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.Example Code: The complete working example for this tutorial is available at sb-on-demand-examples/evm/randomness/pancake-stackerTry It OutPlay Pancake Stacker directly in your browser! Connect your wallet (MetaMask or Phantom), enter the contract address, and start flipping pancakes.Play Pancake StackerContract Address (Monad): 0x8A48241ba47298BBCb417834C6A95860D4273B6BThis tutorial walks you through building Pancake Stacker, a simple on-chain game that demonstrates Switchboard's randomness system. You'll learn how to request, resolve, and use verifiable randomness in your EVM smart contracts.Version source of truth: SDK Version MatrixAPI note: The current EVM randomness methods are createRandomness, settleRandomness, and getRandomness. Use the canonical ABI at @switchboard-xyz/on-demand-solidity/abis/Switchboard.json. revealRandomness and getRandomnessResult are not part of the current interface.What You'll BuildA game where players flip pancakes onto a stack:Each flip has a 2/3 chance of landing successfullySuccessful flips increase your stack heightA failed flip knocks over your entire stack (resets to 0)Randomness is generated off-chain by Switchboard oracles and verified on-chainMapping to the Randomness FlowBefore diving into code, let's connect this example to the conceptual flow described in the Randomness Overview. The five parties are:Conceptual PartyIn Pancake StackerAliceYou (running the script or using the UI)AppPancakeStacker smart contractSwitchboard ContractISwitchboard interfaceCrossbarCrossbarClient from @switchboard-xyz/commonOracleSwitchboard oracle (generates the randomness)The two-stage flow maps directly to our two main functions:Request Randomness → flipPancake()Resolve Randomness → catchPancake()PrerequisitesFoundry installed for Solidity developmentBun or Node.js 20+Native tokens for gas (e.g., MON for Monad)Basic understanding of Solidity and ethers.jsInstallationSolidity SDK:npm install @switchboard-xyz/on-demand-solidity@1.1.0TypeScript SDK (for off-chain randomness resolution):npm install @switchboard-xyz/common@5.8.5 ethersForge remappings - Add to remappings.txt:@switchboard-xyz/on-demand-solidity/=node_modules/@switchboard-xyz/on-demand-solidityThe Smart ContractImports and State Variables// SPDX-License-Identifier: UNLICENSED\npragma solidity ^0.8.13;\n\nimport { ISwitchboard } from '@switchboard-xyz/on-demand-solidity/interfaces/ISwitchboard.sol';\nimport { SwitchboardTypes } from '@switchboard-xyz/on-demand-solidity/libraries/SwitchboardTypes.sol';\n\ncontract PancakeStacker {\n\n // Pending flip randomness ID for each user (bytes32(0) = no pending flip)\n mapping(address => bytes32) public pendingFlips;\n\n // Current stack height for each player\n mapping(address => uint256) public stackHeight;\n\n // Reference to the Switchboard contract\n ISwitchboard public switchboard;\n\n constructor(address _switchboard) {\n require(_switchboard != address(0), \"Invalid switchboard address\");\n switchboard = ISwitchboard(_switchboard);\n }The contract tracks:pendingFlips: Maps each user to their pending randomness request IDstackHeight: Maps each user to their current pancake stack countswitchboard: Reference to the Switchboard contract for randomness operationsEvents event PancakeFlipRequested(address indexed user, bytes32 randomnessId);\n event PancakeLanded(address indexed user, uint256 newStackHeight);\n event StackKnockedOver(address indexed user);\n event SettlementFailed(address indexed user);Events allow the off-chain script (or UI) to track the outcome of each flip.Requesting Randomness: flipPancake()This function implements the Request Randomness phase from the overview: function flipPancake() public {\n // Check no pending flip exists\n require(pendingFlips[msg.sender] == bytes32(0), \"Already have pending flip\");\n\n // Generate unique randomnessId using sender address and last blockhash\n bytes32 randomnessId = keccak256(abi.encodePacked(msg.sender, blockhash(block.number - 1)));\n\n // Ask Switchboard to create a new randomness request with 1 second settlement delay\n switchboard.createRandomness(randomnessId, 1);\n\n // Store the randomness request as a pending flip\n pendingFlips[msg.sender] = randomnessId;\n\n emit PancakeFlipRequested(msg.sender, randomnessId);\n }Flow mapping:Alice calls the App (flipPancake())App generates a unique randomnessId and calls Switchboard Contract (createRandomness)Switchboard Contract assigns an oracle and stores the requestApp emits event with the randomnessId for Alice to use laterResolving Randomness: catchPancake()This function implements the Resolve Randomness phase: function catchPancake(bytes calldata encodedRandomness) public {\n // Make sure caller has a pending flip\n bytes32 randomnessId = pendingFlips[msg.sender];\n require(randomnessId != bytes32(0), \"No pending flip\");\n\n // Clear the pending flip BEFORE external calls (CEI pattern)\n delete pendingFlips[msg.sender];\n\n // Ask Switchboard to verify the randomness is correct\n try switchboard.settleRandomness(encodedRandomness) {\n\n // Verification succeeded, get the randomness value\n SwitchboardTypes.Randomness memory randomness = switchboard.getRandomness(randomnessId);\n\n // Verify the randomness ID matches what we requested\n require(randomness.randId == randomnessId, \"Randomness ID mismatch\");\n\n // 2/3 chance to land (0 or 1), 1/3 chance to knock over (2)\n bool landed = uint256(randomness.value) % 3 < 2;\n\n if (landed) {\n stackHeight[msg.sender]++;\n emit PancakeLanded(msg.sender, stackHeight[msg.sender]);\n } else {\n stackHeight[msg.sender] = 0;\n emit StackKnockedOver(msg.sender);\n }\n\n } catch {\n // Settlement failed - reset stack to be safe\n stackHeight[msg.sender] = 0;\n emit StackKnockedOver(msg.sender);\n emit SettlementFailed(msg.sender);\n }\n }Flow mapping:Alice sends the randomness object (obtained from Crossbar) to the AppApp asks Switchboard Contract to verify the randomness (settleRandomness)If valid, App retrieves the value (getRandomness) and applies game logicApp emits the outcome eventHelper Function: getFlipData()This view function provides the data needed for off-chain resolution: function getFlipData(address user) public view returns (\n bytes32 randomnessId,\n address oracle,\n uint256 rollTimestamp,\n uint256 minSettlementDelay\n ) {\n randomnessId = pendingFlips[user];\n SwitchboardTypes.Randomness memory randomness = switchboard.getRandomness(randomnessId);\n return (randomnessId, randomness.oracle, randomness.rollTimestamp, randomness.minSettlementDelay);\n }The Off-Chain ScriptThe stackPancake.ts script demonstrates how to interact with the contract from off-chain. While the example repository also includes a React UI, the script is simpler to understand and follows the exact same flow.Note: The UI code does the same thing as this script, but with React state management and a visual interface. Understanding this script is sufficient to understand how any client (UI, bot, etc.) interacts with the randomness system.Setupimport { ethers } from \"ethers\";\nimport { CrossbarClient } from \"@switchboard-xyz/common\";\n\n// Contract ABI (only the functions we need)\nconst PANCAKE_STACKER_ABI = [\n \"function flipPancake() public\",\n \"function catchPancake(bytes calldata encodedRandomness) public\",\n \"function getFlipData(address user) public view returns (bytes32 randomnessId, address oracle, uint256 rollTimestamp, uint256 minSettlementDelay)\",\n \"function getPlayerStats(address user) public view returns (uint256 currentStack, bool hasPendingFlip)\",\n \"event PancakeLanded(address indexed user, uint256 newStackHeight)\",\n \"event StackKnockedOver(address indexed user)\",\n \"event SettlementFailed(address indexed user)\",\n];\n\nasync function main() {\n // Resolve the target network. The packaged example defaults to Monad testnet\n // and lets you flip to mainnet by setting NETWORK=monad-mainnet.\n const networkName = process.env.NETWORK || \"monad-testnet\";\n const rpcUrl =\n process.env.RPC_URL ||\n (networkName === \"monad-mainnet\"\n ? \"https://rpc.monad.xyz\"\n : \"https://testnet-rpc.monad.xyz\");\n const provider = new ethers.JsonRpcProvider(rpcUrl);\n const wallet = new ethers.Wallet(process.env.PRIVATE_KEY!, provider);\n const crossbar = new CrossbarClient(\"https://crossbar.switchboard.xyz\");\n\n const contract = new ethers.Contract(\n process.env.PANCAKE_STACKER_CONTRACT_ADDRESS!,\n PANCAKE_STACKER_ABI,\n wallet\n );Step 1: Check Current Stats const [currentStack] = await contract.getPlayerStats(wallet.address);\n console.log(`Current stack: ${currentStack} pancakes`);Step 2: Request Randomness (Flip the Pancake) // Call flipPancake() to request randomness\n const tx = await contract.flipPancake();\n await tx.wait();\n console.log(\"Flip requested:\", tx.hash);This triggers the Request Randomness phase on-chain.Step 3: Get Flip Data // Retrieve the data needed for off-chain resolution\n const flipData = await contract.getFlipData(wallet.address);The contract returns:randomnessId: Unique identifier for this requestoracle: Address of the assigned oraclerollTimestamp: When the randomness was rolledminSettlementDelay: Minimum wait time before settlementStep 4: Resolve Randomness via Crossbar // Get chain ID dynamically\n const network = await provider.getNetwork();\n const chainId = Number(network.chainId);\n\n // Ask Crossbar to get randomness from the oracle\n const { encoded } = await crossbar.resolveEVMRandomness({\n chainId,\n randomnessId: flipData.randomnessId,\n timestamp: Number(flipData.rollTimestamp),\n minStalenessSeconds: Number(flipData.minSettlementDelay),\n oracle: flipData.oracle,\n });This is where Crossbar talks to the Oracle and returns the encoded randomness proof.Step 5: Settle On-Chain (Catch the Pancake) // Submit the encoded randomness to the contract\n const tx2 = await contract.catchPancake(encoded);\n const receipt = await tx2.wait();Step 6: Parse Events for Outcome for (const log of receipt.logs) {\n try {\n const parsed = contract.interface.parseLog(log);\n\n if (parsed?.name === \"PancakeLanded\") {\n console.log(`PANCAKE LANDED! Stack height: ${parsed.args.newStackHeight}`);\n }\n\n if (parsed?.name === \"StackKnockedOver\") {\n console.log(\"STACK KNOCKED OVER!\");\n }\n\n if (parsed?.name === \"SettlementFailed\") {\n console.log(\"SETTLEMENT FAILED - stack reset\");\n }\n } catch {}\n }Complete Flow Diagram┌─────────────────────────────────────────────────────────────────────┐\n│ REQUEST RANDOMNESS │\n├─────────────────────────────────────────────────────────────────────┤\n│ │\n│ You (Alice) │\n│ │ │\n│ │ 1. Call flipPancake() │\n│ ▼ │\n│ PancakeStacker (App) │\n│ │ │\n│ │ 2. Generate randomnessId │\n│ │ 3. Call switchboard.createRandomness() │\n│ ▼ │\n│ Switchboard Contract │\n│ │ │\n│ │ 4. Assign oracle, store request │\n│ │ 5. Return to App │\n│ ▼ │\n│ PancakeStacker emits PancakeFlipRequested event │\n│ │\n└─────────────────────────────────────────────────────────────────────┘\n\n┌─────────────────────────────────────────────────────────────────────┐\n│ RESOLVE RANDOMNESS │\n├─────────────────────────────────────────────────────────────────────┤\n│ │\n│ You (Alice) │\n│ │ │\n│ │ 1. Call getFlipData() to get oracle info │\n│ │ 2. Call crossbar.resolveEVMRandomness() │\n│ ▼ │\n│ Crossbar │\n│ │ │\n│ │ 3. Request randomness from Oracle │\n│ ▼ │\n│ Oracle │\n│ │ │\n│ │ 4. Generate randomness, sign it │\n│ │ 5. Return encoded proof to Crossbar │\n│ ▼ │\n│ Crossbar returns encoded randomness to You │\n│ │ │\n│ │ 6. Call catchPancake(encoded) │\n│ ▼ │\n│ PancakeStacker (App) │\n│ │ │\n│ │ 7. Call switchboard.settleRandomness() │\n│ ▼ │\n│ Switchboard Contract verifies proof │\n│ │ │\n│ │ 8. Return success │\n│ ▼ │\n│ PancakeStacker applies game logic, emits result event │\n│ │\n└─────────────────────────────────────────────────────────────────────┘Security ConsiderationsCEI Pattern (Checks-Effects-Interactions)Notice that catchPancake() clears pendingFlips[msg.sender] before making external calls:// Clear the pending flip BEFORE external calls (CEI pattern)\ndelete pendingFlips[msg.sender];\n\n// Then make external call\ntry switchboard.settleRandomness(encodedRandomness) { ... }This prevents reentrancy attacks.Settlement DelayThe minSettlementDelay (set to 1 second in this example) ensures the randomness can't be resolved instantly. This gives the oracle time to generate the randomness after the request is made, preventing manipulation.Try-Catch for SettlementThe contract gracefully handles settlement failures by catching exceptions and resetting the player's state, rather than leaving them stuck with an unresolvable pending flip.Running the Example1. Clone and Installgit clone https://github.com/switchboard-xyz/sb-on-demand-examples\ncd sb-on-demand-examples/evm/randomness/pancake-stacker\nbun install # or npm install\n[ -d lib/forge-std ] || forge install foundry-rs/forge-std --no-git --shallow\nforge build2. Configure EnvironmentSecurity: Never use export PRIVATE_KEY=... in shell history. Put secrets in a local .env file instead.Copy the example file and fill in your values:cp .env.example .env3. Deploy the Contract# Default: Monad testnet\nbun run deploy\n\n# Monad mainnet with the same deploy flow\nNETWORK=monad-mainnet bun run deploy4. Run the ScriptUpdate .env with your deployed contract address:PRIVATE_KEY=0x...\nNETWORK=monad-testnet\nPANCAKE_STACKER_CONTRACT_ADDRESS=0x_your_deployed_address\nRPC_URL=bun run flipExpected OutputCurrent stack: 0 pancakes\n\nFlipping pancake...\nFlip requested: 0x...\n\nResolving randomness...\nCatching pancake...\n\n========================================\nPANCAKE LANDED!\nStack height: 1 pancakes\n========================================\n\nYour stack: 1 pancakesSummaryYou've now learned how to integrate Switchboard randomness into an EVM smart contract:Request: Call switchboard.createRandomness() with a unique IDResolve: Use CrossbarClient.resolveEVMRandomness() to get the oracle's signed randomnessSettle: Call switchboard.settleRandomness() to verify and getRandomness() to retrieve the valueUse: Apply the random value to your game logicThis pattern works for any application requiring verifiable randomness: games, NFT mints, lotteries, and more.PreviousRandomnessNextMonadLast updated 2 months ago","tokens":3542,"squid":"spider-08","role":"Oracle Spider","at":1791342202514,"hash":"f1b2708b375cb539e8b82825b453a40e6eb2bb53"}
{"url":"https://docs.switchboard.xyz/docs-by-chain/solana-svm/x402/x402-tutorial","domain":"docs.switchboard.xyz","title":"X402 Tutorial | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.Example Code: The complete working example for this tutorial is available at sb-on-demand-examples/solana/x402Version source of truth: SDK Version MatrixThe Problem: Accessing Paywalled Data in OraclesMany valuable data sources—premium RPC endpoints, institutional APIs, proprietary market data—require payment or authentication. Traditional oracles can't access these sources because:No way to pay: Oracles can't hold funds or make payments on your behalfStatic credentials: Storing API keys in feed definitions (on IPFS or on-chain) exposes them publiclyPer-request pricing: Many premium services charge per-request, incompatible with polling oraclesX402 solves this by enabling micropayments directly in HTTP requests. The oracle authenticates with the paywalled API using a PAYMENT-SIGNATURE header you provide at runtime, without ever exposing credentials or requiring the oracle to hold funds.What We're BuildingIn this tutorial, we'll fetch data from a paywalled Helius RPC endpoint using X402 micropayments. The flow works like this:┌─────────────────────────────────────────────────────────────────────────────┐\n│ X402 Oracle Flow │\n├─────────────────────────────────────────────────────────────────────────────┤\n│ │\n│ YOUR APP ORACLE (TEE) PAYWALLED API │\n│ ──────── ──────────── ───────────── │\n│ │\n│ 1. Derive PAYMENT-SIGNATURE ─────┐ │\n│ (USDC auth) │ │\n│ ▼ │\n│ 2. Define feed with ┌─────────┐ │\n│ ${PLACEHOLDER} ───►│Crossbar │ │\n│ variables └────┬────┘ │\n│ │ │\n│ 3. Pass headers as │ 4. Oracle makes ┌────────┐ │\n│ variable overrides ──────┼─────► authenticated ────────────►│ Helius │ │\n│ │ HTTP request │ RPC │ │\n│ │ with PAYMENT-SIGNATURE └───┬────┘ │\n│ │ header │ │\n│ │ │ │\n│ │ 5. Paywalled data ◄───────────────┘ │\n│ │ returned │\n│ ▼ │\n│ 6. Signed oracle data ┌─────────┐ │\n│ in quote account ◄──│ Oracle │ │\n│ │Response │ │\n│ └─────────┘ │\n└─────────────────────────────────────────────────────────────────────────────┘Specifically, we'll:Call getBlockHeight on a paywalled Helius RPC endpointPay for the request using USDC micropayments via the X402 protocolReceive the block height as verified oracle data on-chainThis pattern works for any paywalled HTTP API—you're not limited to RPC endpoints.PrerequisitesSolana CLI installed and configuredNode.js 20+A Solana keypair with USDC on mainnet-beta (the X402 payment token)Ensure the wallet has a USDC associated token account (ATA) with balanceInstallationClone the examples repository and install dependencies:git clone https://github.com/switchboard-xyz/sb-on-demand-examples.git\ncd sb-on-demand-examples/solana/x402\npnpm installDependenciesThe example uses these X402-specific packages:{\n \"@x402/fetch\": \"^2.2.0\",\n \"@x402/svm\": \"^2.2.0\"\n}How X402 Authentication WorksUnlike standard oracle feeds (stored on IPFS with a feed hash), X402 feeds are defined inline in your code with placeholder variables. At runtime, you:Derive a PAYMENT-SIGNATURE header from the X402 protocol (this authorizes your USDC payment)Replace placeholders with the header via variableOverridesOracle executes the authenticated request inside a TEE (Trusted Execution Environment)The oracle never sees your wallet or credentials—it just receives the pre-signed authentication headers.ImplementationStep 1: Set Up Imports and Constantsimport { PublicKey, Connection, Keypair } from \"@solana/web3.js\";\nimport * as sb from \"@switchboard-xyz/on-demand\";\nimport { OracleQuote } from \"@switchboard-xyz/on-demand\";\nimport { FeedHash, OracleJob } from \"@switchboard-xyz/common\";\nimport { x402Client, x402HTTPClient } from \"@x402/fetch\";\nimport { registerExactSvmScheme } from \"@x402/svm/exact/client\";\nimport { toClientSvmSigner } from \"@x402/svm\";\nimport { createKeyPairSignerFromBytes } from \"@solana/kit\";\nimport { getAssociatedTokenAddress, getAccount } from \"@solana/spl-token\";\n\nconst URL = \"https://helius.api.corbits.dev\";\nconst RPC_METHOD = \"getBlockHeight\";\nconst USDC = new PublicKey(\"EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v\");Step 2: Define the Oracle Feed with PlaceholdersThis is the key difference from standard feeds. Instead of storing the feed on IPFS, we define it inline with placeholder variables for the authentication headers:const ORACLE_FEED = {\n name: \"X402 Paywalled RPC Call\",\n minJobResponses: 1, // unscaled job/source quorum\n minOracleSamples: 1, // unscaled oracle/signature quorum\n maxJobRangePct: 0, // Intentional for this single-use flow; use a positive scaled value for normal multi-source feeds.\n jobs: [\n {\n tasks: [\n {\n // Task 1: Make an authenticated HTTP POST request to the paywalled RPC\n httpTask: {\n url: URL,\n method: OracleJob.HttpTask.Method.METHOD_POST,\n body: JSON.stringify({\n jsonrpc: \"2.0\",\n id: 1,\n method: RPC_METHOD, // \"getBlockHeight\"\n }),\n headers: [\n {\n // X402 payment proof - proves you've authorized the USDC payment\n key: \"PAYMENT-SIGNATURE\",\n value: \"${X402_PAYMENT_SIGNATURE}\",\n },\n ],\n },\n },\n {\n // Task 2: Extract the result from the JSON-RPC response\n // Response format: { \"jsonrpc\": \"2.0\", \"result\": 123456789, \"id\": 1 }\n jsonParseTask: {\n path: \"$.result\",\n },\n },\n ],\n },\n ],\n};Key points:${X402_PAYMENT_SIGNATURE} is a placeholder that gets replaced at runtimeThe oracle sees the actual header values, but they're never stored permanently anywhereminJobResponses: 1 and minOracleSamples: 1 because X402 payments are single-use (you can't have multiple oracles reuse the same payment signature)Step 3: Initialize the x402 v2 ClientCreate an x402 v2 client that can sign Solana payments:// Load Solana environment from `solana config get`\nconst { program, keypair, connection, crossbar } = await sb.AnchorUtils.loadEnv();\nconsole.log(\"Wallet:\", keypair.publicKey.toBase58());\n\n// Create a Solana signer for x402 v2\nconst signer = await createKeyPairSignerFromBytes(keypair.secretKey);\n\n// Register the Exact SVM scheme (supports v2 + v1)\nconst client = new x402Client();\nregisterExactSvmScheme(client, { signer: toClientSvmSigner(signer) });Step 4: Check USDC BalanceX402 payments are made in USDC. Verify you have sufficient balance before proceeding:async function checkUsdcBalance(\n connection: Connection,\n keypair: Keypair,\n usdcMint: PublicKey\n): Promise<void> {\n const usdcTokenAccount = await getAssociatedTokenAddress(\n usdcMint,\n keypair.publicKey\n );\n const tokenAccountInfo = await getAccount(connection, usdcTokenAccount);\n const usdcBalance = Number(tokenAccountInfo.amount) / 1_000_000;\n console.log(\"USDC balance:\", usdcBalance.toFixed(6), \"USDC\");\n}\n\nawait checkUsdcBalance(connection, keypair, USDC);Step 5: Derive PAYMENT-SIGNATUREThis is where the magic happens. The x402 v2 client derives a PAYMENT-SIGNATURE header that:Proves you've authorized a USDC payment for this specific requestIs bound to the exact URL, method, and body (can't be reused for different requests)Is single-use (can't be replayed)// Fetch the payment requirements (402) and derive a signature header\nconst response = await fetch(URL, {\n method: \"POST\",\n body: JSON.stringify({\n jsonrpc: \"2.0\",\n id: 1,\n method: RPC_METHOD,\n }),\n});\n\nconst httpClient = new x402HTTPClient(client);\nconst paymentRequired = httpClient.getPaymentRequiredResponse(\n name => response.headers.get(name),\n await response.json().catch(() => undefined)\n);\nconst paymentPayload = await client.createPaymentPayload(paymentRequired);\nconst paymentHeaders = httpClient.encodePaymentSignatureHeader(paymentPayload);\nconst paymentSignature = paymentHeaders[\"PAYMENT-SIGNATURE\"];Important: These headers are single-use. Once the oracle uses them, they can't be used again.Step 6: Fetch Managed Update with Variable OverridesNow we bring it all together. We pass our PAYMENT-SIGNATURE header as variable overrides, which replace the ${PLACEHOLDER} values in our feed definition:// Load Switchboard queue\nconst queue = await sb.Queue.loadDefault(program);\n\n// Compute the feed ID (hash of the inline feed definition)\n// This is deterministic - same feed definition = same ID\nconst feedId = FeedHash.computeOracleFeedId(ORACLE_FEED);\nconsole.log(\"Feed ID:\", `0x${feedId.toString(\"hex\")}`);\n\n// Derive the quote account where verified data will be stored\nconst [quoteAccount] = OracleQuote.getCanonicalPubkey(queue.pubkey, [feedId]);\nconsole.log(\"Quote Account:\", quoteAccount.toBase58());\n\n// Fetch managed update instructions\n// This sends our feed definition + variable overrides to Crossbar,\n// which coordinates with an oracle to execute the authenticated request\nconst instructions = await queue.fetchManagedUpdateIxs(\n crossbar,\n [ORACLE_FEED], // Our inline feed definition with placeholders\n {\n // CRITICAL: numSignatures MUST BE 1 for X402 requests\n // (payment signatures are single-use, can't be shared across oracles)\n numSignatures: 1,\n\n // Variable overrides replace ${PLACEHOLDER} values in the feed\n variableOverrides: {\n X402_PAYMENT_SIGNATURE: paymentSignature,\n },\n payer: keypair.publicKey,\n }\n);The returned instructions contain:Ed25519 signature verification - Proves the oracle signed the responseQuote program update - Writes verified data to the quote accountStep 7: Build and Send TransactionFinally, bundle the oracle instructions with your program's instruction and submit:// Build transaction with oracle update and your program instruction\nconst tx = await sb.asV0Tx({\n connection,\n ixs: [\n ...instructions, // Oracle update (Ed25519 verify + quote write)\n readOracleIx, // Your program reads from the quote account\n ],\n signers: [keypair],\n computeUnitPrice: 20_000,\n computeUnitLimitMultiple: 1.1,\n});\n\n// Simulate to verify everything works\n// (safe here because this is the same transaction we'll send)\nconst sim = await connection.simulateTransaction(tx);\nconsole.log(sim.value.logs?.join(\"\\n\"));\n\n// Send the transaction\nconst signature = await connection.sendTransaction(tx);\nconsole.log(\"Transaction:\", signature);After the transaction confirms, the quoteAccount contains the verified block height from the paywalled RPC.Important ConstraintsWhy numSignatures Must Be 1X402 payment signatures are single-use. Each signature can only authenticate one oracle request. If you set numSignatures: 2, the second oracle would try to reuse the same signature and fail.const instructions = await queue.fetchManagedUpdateIxs(crossbar, [ORACLE_FEED], {\n numSignatures: 1, // REQUIRED for X402 - headers can't be shared\n // ...\n});Simulation Warning: Don't Pay TwiceThe X402 payment is charged when the oracle makes the HTTP request, not when your transaction lands on-chain. This means:Crossbar simulation (crossbar.simulateFeed()) will charge youOn-chain simulation (connection.simulateTransaction()) is safe (no HTTP call)// DON'T DO THIS - you'll pay for the request but get no on-chain result\n// const simFeed = await crossbar.simulateFeed(ORACLE_FEED, true, {\n// X402_PAYMENT_SIGNATURE: paymentSignature\n// });\n\n// This is SAFE - simulates the transaction, not the HTTP request\nconst sim = await connection.simulateTransaction(tx);Why Inline Feeds?Standard Switchboard feeds are stored on IPFS and referenced by hash. X402 feeds must be defined inline because:Payment signatures change with every requestHeaders contain sensitive payment authorizationThe feed definition contains runtime placeholders, not static valuesRunning the Examplepnpm startExpected output:Wallet: <your-wallet-address>\nRPC Method: getBlockHeight\nUSDC balance: 10.500000 USDC\nX402 v2 client initialized\n\nDeriving X402 PAYMENT-SIGNATURE...\nX402 PAYMENT-SIGNATURE generated\nFeed ID: 0x<feed-hash>\nQuote Account: <quote-account-address>\n\nFetching managed update instructions with X402 variable overrides...\nGenerated instructions: 2\n - Ed25519 signature verification\n - Quote program verified_update\n - Variable overrides: X402_PAYMENT_SIGNATURE\n\nBuilding transaction...\nSimulating transaction...\n<transaction logs>\n\nSimulation succeeded!Next StepsLearn about Variable Overrides for other dynamic patternsExplore Custom Feeds for building your own oracle jobsCheck out other Solana examplesJoin our Discord for supportPreviousX402 MicropaymentsNextEVMLast updated 2 months ago","tokens":3037,"squid":"spider-08","role":"Oracle Spider","at":1791342212557,"hash":"ac540b8eb436dd954a7aec5c04964137ec1c6c27"}
{"url":"https://help.phantom.com/articles/15079894392851","domain":"help.phantom.com","title":"Sign in to or import an existing Phantom wallet","text":"Sign in to or import an existing Phantom walletIf you already have a Phantom wallet, or want to import an existing wallet, you're in the right place.Before you start #Your Phantom app or browser extension must be on the welcome screen. If you’re already signed in, reset or reinstall Phantom before continuing.Sign in with Google or Apple #If your wallet was created with a Google or Apple account, sign in with the same account.Mobile app #\nOpen the Phantom mobile app.\nTap Continue with Apple or Continue with Google.\nFollow the prompts to sign in.\nIf prompted, enter your four-digit PIN.\nOptionally, turn on device authentication such as Face ID or fingerprint.\nOptionally, turn on push notifications.\nPhantom restores only your first account automatically, regardless of how many accounts your wallet had before. To add the others, see Accounts are missing after importing.Browser extension #\nClick the Phantom browser extension icon.\nIn a new tab that opens, click I Already Have a Wallet > Connect Email Wallet.\nClick Apple or Google and follow the prompts to sign in.\nIf prompted, enter your four-digit PIN.\nCreate a secure password. This password unlocks Phantom only in your current browser and does not replace your Google or Apple account sign-in.\nPhantom restores only your first account automatically, regardless of how many accounts your wallet had before. To add the others, see Accounts are missing after importing.Import a recovery phrase #If your wallet was created with a Secret Recovery Phrase, import the same recovery phrase.Mobile app #\nOpen the Phantom mobile app.\nTap More Options > Import Recovery Phrase.\nEnter your recovery phrase.\nTap Import.\nOptionally, turn on device authentication such as Face ID or fingerprint.\nOptionally, turn on push notifications.\nPhantom automatically restores all accounts from this wallet that had activity before. If empty accounts are missing, see Accounts are missing after importing.Browser extension #\nClick the Phantom browser extension icon.\nIn a new tab that opens, click I Already Have a Wallet > Import Recovery Phrase.\nEnter your recovery phrase.\nClick Import Wallet.\nCreate a password to unlock Phantom on this device.\nPhantom automatically restores all accounts from this wallet that had activity before. If empty accounts are missing, see Accounts are missing after importing.Import a private key #Import a private key to access a single address on one network.Mobile app #\nOpen the Phantom mobile app.\nTap More Options > Import Private Key.\nSelect the network.\nPaste your private key.\nTap Import.\nOptionally, turn on device authentication such as Face ID or fingerprint.\nOptionally, turn on push notifications.\nBrowser extension #\nClick the Phantom browser extension icon.\nIn a new tab that opens, click I Already Have a Wallet > Import Private Key.\nEnter a name for the account.\nSelect the network.\nPaste your private key.\nClick Import.\nCreate a password to unlock Phantom on this device.\nConnect a hardware wallet #Connect a supported Ledger hardware wallet to access accounts on supported networks.\nUse a Ledger wallet with the Phantom mobile app\nUse a Ledger wallet with the Phantom browser extension\nTroubleshoot wallet import #See Recover missing wallets and fix import issues for troubleshooting help.FAQ #Where can I find my recovery phrase or private key? #For instructions, see View your recovery phrase or private keys in Phantom.Can I import a wallet without a recovery phrase? #It depends on how the wallet was created. If it used a Secret Recovery Phrase, that phrase is required. If it used a Google or Apple account, you can restore it with the same account and, if prompted, your four-digit PIN.Forgot my recovery phrase, can I look it up? #No. Phantom does not store your recovery phrase and cannot look it up or recover it for you. If you are still logged into Phantom on any device, you can view it from Settings > Security & Privacy > Show Recovery Phrase.See also #\nMove your Phantom wallet to a new phone\nCan I restore Phantom from iCloud or Google Drive?\nRelated articlesCreate a new Phantom walletYou can create a new Phantom wallet in two ways:Updated 20 days agoCreate a new Phantom wallet with a Google or Apple accountYou can create a new Phantom wallet by signing in with your Google or Apple account. Then access this wallet on any device where you use Phantom by signing in with the same account.Updated 20 days agoRecover missing wallets and fix import issuesIf a wallet won’t import into Phantom, your accounts are missing after import, your recovery phrase isn’t working, or you’re seeing private key errors, this article can help.Updated 21 days agoCreate a new Phantom wallet with a Secret Recovery PhraseYou can create a new wallet in Phantom using a Secret Recovery Phrase, sometimes called a seed phrase. Be sure to write your recovery phrase down and store it somewhere secure and offline. Phantom doe...Updated 20 days agoGet started with PhantomNew to Phantom? Start by downloading the app, creating your wallet, and adding funds when you’re ready.Updated 12 days ago","tokens":1271,"squid":"spider-10","role":"Tooling Spider","at":1791342216475,"hash":"656824d1130df8fc1114011035aa5d746e5bd815"}
{"url":"https://docs.switchboard.xyz/docs-by-chain/evm/surge/surge-tutorial","domain":"docs.switchboard.xyz","title":"Surge Tutorial | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.Example Code: The complete working example for this tutorial is available at sb-on-demand-examples/evm/price-feeds (see scripts/surgeToEvmConversion.ts)This tutorial walks you through converting Switchboard Surge real-time price updates into EVM-compatible format for use with your smart contracts.Version source of truth: SDK Version MatrixWhat You'll BuildA TypeScript script that:Receives Surge real-time price updatesConverts them to EVM-encoded formatSubmits the data to your smart contractsPrerequisitesBun or Node.js 20+Basic understanding of hexadecimal encodingIf you're also streaming Surge updates yourself, note that the SDK authenticates by signing with a Solana keypair that has an active Surge subscription. Without an active subscription, connectAndSubscribe will fail.The Conversion FlowSurge WebSocket → SurgeRawGatewayResponse → EVMUtils.convertSurgeUpdateToEvmFormat() → bytes → Smart ContractThe SurgeRawGatewayResponse StructureWhen you receive a Surge update, it has this structure:interface SurgeRawGatewayResponse {\n type: 'bundle_update';\n feed_bundle_id: string;\n feed_values: Array<{\n value: string; // Price value as string (wei-like format)\n feed_hash: string; // 32-byte hex feed identifier\n symbol: string; // Human-readable symbol (e.g., \"BTC/USD\")\n source: string; // Data source\n }>;\n oracle_response: {\n oracle_pubkey: string; // Oracle's public key\n eth_address: string; // Oracle's Ethereum address\n signature: string; // Base64-encoded 64-byte signature\n recovery_id: number; // ECDSA recovery ID (v value)\n timestamp: number; // Unix timestamp in seconds\n slot: number; // Solana slot number\n // ... additional fields\n };\n}The Conversion ScriptHere's a complete example that converts Surge updates to EVM format:import { EVMUtils, type SurgeRawGatewayResponse } from '@switchboard-xyz/common';\nimport * as fs from 'fs';\n\n// Sample Surge update data\nconst sampleSurgeUpdate: SurgeRawGatewayResponse = {\n type: 'bundle_update',\n feed_bundle_id: 'sample-bundle-id',\n feed_values: [\n {\n value: '1000000000000000000', // 1e18\n feed_hash: '0x1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef',\n symbol: 'BTC/USD',\n source: 'switchboard'\n },\n {\n value: '2500000000000000000', // 2.5e18\n feed_hash: '0xabcdef1234567890abcdef1234567890abcdef1234567890abcdef1234567890',\n symbol: 'ETH/USD',\n source: 'switchboard'\n }\n ],\n oracle_response: {\n oracle_pubkey: '0xabcdef1234567890abcdef1234567890abcdef1234567890abcdef1234567890',\n eth_address: '0x742d35Cc6634C0532925a3b8D4C0B4E5C0C8b6C9',\n signature: 'Zl+8HHAyFbKTmaH66HEkQ/4nKRGYKWV8YOjPT9JcGdEhZzy+qI9OKhF3m+nmz9mbegPJRtIJdLfdi1o7wjZCaw==',\n checksum: 'sample-checksum',\n recovery_id: 0,\n oracle_idx: 0,\n timestamp: Math.floor(Date.now() / 1000),\n recent_hash: '0xdeadbeefcafebabe',\n slot: 12345678\n },\n source_ts_ms: Date.now(),\n seen_at_ts_ms: Date.now(),\n triggered_on_price_change: true,\n message: 'Sample surge update'\n};\n\nasync function convertSurgeToEvm() {\n // Load surge data (from file or use sample)\n let surgeData: SurgeRawGatewayResponse;\n\n const surgeDataFile = process.env.SURGE_DATA_FILE;\n if (surgeDataFile && fs.existsSync(surgeDataFile)) {\n const fileContent = fs.readFileSync(surgeDataFile, 'utf-8');\n surgeData = JSON.parse(fileContent);\n } else {\n surgeData = sampleSurgeUpdate;\n }\n\n // Perform the conversion\n const evmEncoded = EVMUtils.convertSurgeUpdateToEvmFormat(surgeData, {\n minOracleSamples: 1 // unscaled oracle-sample quorum\n });\n\n console.log('Encoded Data:', evmEncoded);\n console.log('Length:', (evmEncoded.length - 2) / 2, 'bytes');\n\n return evmEncoded;\n}\n\nconvertSurgeToEvm();The convertSurgeUpdateToEvmFormat Functionimport { EVMUtils } from '@switchboard-xyz/common';\n\nconst evmEncoded = EVMUtils.convertSurgeUpdateToEvmFormat(surgeData, {\n minOracleSamples: 1 // Minimum oracle samples required; unscaled count\n});This function takes the raw Surge response and returns a 0x-prefixed hex string that your smart contract can parse.EVM Data StructureThe encoded data follows this binary format:FieldSizeDescriptionSlot8 bytesSolana slot numberTimestamp8 bytesUnix timestampNumber of Feeds1 byteCount of feeds in updateNumber of Signatures1 byteCount of oracle signaturesFeed DataVariablePer-feed data (see below)Signature DataVariablePer-signature data (see below)Feed Data (per feed)FieldSizeDescriptionFeed Hash32 bytesFeed identifierValue16 bytesPrice value (int128)Min Samples1 byteMinimum oracle samplesSignature Data (per signature)FieldSizeDescriptionSignature64 bytesECDSA signature (r, s)Recovery ID1 byteECDSA recovery ID (v)Parsing the Encoded DataTo understand what the encoded data contains, you can parse it:function parseEvmEncodedData(evmEncoded: string) {\n const hexData = evmEncoded.slice(2); // Remove 0x prefix\n let offset = 0;\n\n // Parse header\n const slot = parseInt(hexData.slice(offset, offset + 16), 16);\n offset += 16;\n\n const timestamp = parseInt(hexData.slice(offset, offset + 16), 16);\n offset += 16;\n\n const numFeeds = parseInt(hexData.slice(offset, offset + 2), 16);\n offset += 2;\n\n const numSigs = parseInt(hexData.slice(offset, offset + 2), 16);\n offset += 2;\n\n console.log('Slot:', slot);\n console.log('Timestamp:', new Date(timestamp * 1000).toISOString());\n console.log('Number of Feeds:', numFeeds);\n console.log('Number of Signatures:', numSigs);\n\n // Parse feeds\n for (let i = 0; i < numFeeds; i++) {\n const feedHash = '0x' + hexData.slice(offset, offset + 64);\n offset += 64;\n const value = '0x' + hexData.slice(offset, offset + 32);\n offset += 32;\n const minSamples = parseInt(hexData.slice(offset, offset + 2), 16);\n offset += 2;\n\n console.log(`Feed ${i + 1}:`, { feedHash, value, minSamples });\n }\n\n // Parse signatures\n for (let i = 0; i < numSigs; i++) {\n const signature = '0x' + hexData.slice(offset, offset + 128);\n offset += 128;\n const recoveryId = parseInt(hexData.slice(offset, offset + 2), 16);\n offset += 2;\n\n console.log(`Signature ${i + 1}:`, {\n signature: signature.slice(0, 20) + '...',\n recoveryId\n });\n }\n}Using with Smart ContractsOnce you have the encoded data, submit it to Switchboard:// SPDX-License-Identifier: MIT\npragma solidity ^0.8.22;\n\nimport { ISwitchboard } from \"./switchboard/interfaces/ISwitchboard.sol\";\n\ncontract SurgePriceConsumer {\n ISwitchboard public immutable switchboard;\n\n constructor(address _switchboard) {\n switchboard = ISwitchboard(_switchboard);\n }\n\n function updateFromSurge(bytes calldata surgeUpdateData) external payable {\n // Get the required fee\n bytes[] memory updates = new bytes[](1);\n updates[0] = surgeUpdateData;\n\n uint256 fee = switchboard.getFee(updates);\n require(msg.value >= fee, \"Insufficient fee\");\n\n // Submit to Switchboard for verification\n switchboard.updateFeeds{ value: fee }(updates);\n\n // Data is now verified and available via latestUpdate()\n }\n}TypeScript Integrationimport * as ethers from \"ethers\";\nimport { EVMUtils, type SurgeRawGatewayResponse } from \"@switchboard-xyz/common\";\n\nasync function submitSurgeUpdate(\n contract: ethers.Contract,\n switchboard: ethers.Contract,\n surgeData: SurgeRawGatewayResponse\n) {\n // Convert Surge update to EVM format\n const evmEncoded = EVMUtils.convertSurgeUpdateToEvmFormat(surgeData, {\n minOracleSamples: 1 // unscaled oracle-sample quorum\n });\n\n // Get fee and submit\n const fee = await switchboard.getFee([evmEncoded]);\n const tx = await contract.updateFromSurge(evmEncoded, { value: fee });\n\n await tx.wait();\n console.log(\"Surge update submitted:\", tx.hash);\n}Full Integration PatternHere's how to combine Surge WebSocket streaming with EVM submission:import { EVMUtils, type SurgeRawGatewayResponse } from \"@switchboard-xyz/common\";\nimport * as ethers from \"ethers\";\n\n// Connect to your contract\nconst provider = new ethers.JsonRpcProvider(\"https://rpc.hyperliquid.xyz/evm\");\nconst signer = new ethers.Wallet(process.env.PRIVATE_KEY!, provider);\nconst contract = new ethers.Contract(contractAddress, abi, signer);\n\n// Handle incoming Surge updates\nasync function handleSurgeUpdate(surgeData: SurgeRawGatewayResponse) {\n try {\n // Convert to EVM format\n const evmEncoded = EVMUtils.convertSurgeUpdateToEvmFormat(surgeData, {\n minOracleSamples: 1 // unscaled oracle-sample quorum\n });\n\n // Submit to chain\n const updates = [evmEncoded];\n const fee = await switchboard.getFee(updates);\n\n const tx = await contract.updatePrices(updates, { value: fee });\n console.log(\"Submitted:\", tx.hash);\n\n await tx.wait();\n console.log(\"Confirmed\");\n\n } catch (error) {\n console.error(\"Failed to submit:\", error);\n }\n}\n\n// Connect to Surge WebSocket (pseudo-code)\n// const ws = new WebSocket(SURGE_WS_URL);\n// ws.onmessage = (event) => {\n// const surgeData = JSON.parse(event.data);\n// handleSurgeUpdate(surgeData);\n// };Running the Example1. Clone the Examples Repositorygit clone https://github.com/switchboard-xyz/sb-on-demand-examples\ncd sb-on-demand-examples/evm/price-feeds2. Install Dependenciesbun install3. Run the Conversion Example# With sample data\nbun run surge-convert\n\n# With custom surge data file\nSURGE_DATA_FILE=path/to/surge-data.json bun run surge-convertExpected OutputUsing sample surge data\nInput Surge Update Summary:\n - Type: bundle_update\n - Feed Count: 2\n - Timestamp: 1734523800 (2024-12-18T12:30:00.000Z)\n - Slot: 12345678\n\nConverting to EVM format...\n\nEVM Conversion Results:\n - Encoded Data: 0x00000000bc614e0000000000675946f80201...\n - Length: 284 hex characters (142 bytes)\n\nParsing EVM Structure:\n - Slot: 12345678\n - Timestamp: 1734523800 (2024-12-18T12:30:00.000Z)\n - Number of Feeds: 2\n - Number of Signatures: 1\n - Feed Data:\n Feed 1:\n - Hash: 0x1234567890abcdef...\n - Value: 0x0de0b6b3a7640000\n - Min Samples: 1\n Feed 2:\n - Hash: 0xabcdef1234567890...\n - Value: 0x22b1c8c1227a0000\n - Min Samples: 1TroubleshootingErrorSolutionInvalid surge dataEnsure the input matches SurgeRawGatewayResponse structureMissing signatureThe oracle_response.signature field must be a valid base64 stringInvalid recovery_idMust be 0 or 1Fee errors on-chainQuery switchboard.getFee() with your encoded dataNext StepsLearn about on-demand price feeds for pull-based updatesExplore randomness integration for gaming and NFTsCheck out the Sui Surge tutorial for comparisonPreviousSurge Price FeedsNextRandomnessLast updated 3 months ago","tokens":2582,"squid":"spider-08","role":"Oracle Spider","at":1791342222548,"hash":"852cd8505fb17de3d87576752f9a7eef7bc203dd"}
{"url":"https://help.phantom.com/articles/18827673580563","domain":"help.phantom.com","title":"Reset your Phantom app","text":"Reset your Phantom appIf you need to remove wallet data from your device or fix persistent issues, you can reset Phantom. Resetting removes all wallet data from the current device and returns Phantom to the welcome screen, where you can restore an existing wallet or create a new one. Your funds aren’t affected.When you may need to reset Phantom #You may need to reset Phantom in the following situations:\nYou want to remove wallet data from your device or start over with the welcome screen.\nYou’re experiencing persistent errors, transaction failures across multiple sites, or unexpected behavior.\nApps aren’t connecting or responding correctly after other troubleshooting hasn’t resolved the issue.\nYou have a Bitcoin transaction that shows as pending in Phantom, but is in fact completed on the blockchain. \n\n Important: Before resetting Phantom, make sure you have\n the credentials you’ll need to restore your wallet. Without them, you won’t\n be able to access your wallet on this device.\n Step 1: Back up your wallet credentials #Before resetting Phantom, make sure you have the credentials you originally used to create your wallet:\nGoogle or Apple wallet: Access to your Google or Apple account and, if set before, your four-digit PIN.\nRecovery phrase wallet: Your 12- or 24-word Secret Recovery Phrase.\nAdditional imported wallets: If you imported additional recovery phrases or private keys, you’ll need them to import those wallets again after the reset.\nIf you need to find your credentials first, see View your recovery phrase or private keys in Phantom.Step 2: Reset Phantom #Mobile app #\nTap your profile avatar in the upper left.\nGo to Settings > Security & Privacy.\nTap Reset App, then tap Continue.\nPhantom returns to the welcome screen.Browser extension #\nClick your profile avatar in the upper left.\nGo to Settings > Security & Privacy.\nClick Reset App, then click Continue.\nPhantom opens the welcome screen in a new browser tab.See also #\nSign in to or import an existing wallet into Phantom\nCreate a new Phantom wallet with a Google or Apple account\nRelated articlesIf a feature is unavailable in your country or regionIf you're seeing a message in Phantom when trying to access a feature such as perps, predictions, or tokenized stocks, this means the feature you're trying to use isn't available in your location.Updated 2 days agoManage your Phantom usernameYour username is the @handle that shows on your Phantom profile. It's the public-facing identity others use to transfer you Cash, find you in chats, and follow your activity. A username is required to...Updated 12 days agoView your wallet address in PhantomYour wallet address is a public identifier you share to receive tokens in Phantom: from an exchange, another wallet, or a friend sending you funds.Updated 5 days agoView your recovery phrase or private keys in PhantomYour Secret Recovery Phrase and private keys are the backup credentials for your wallet. Export them before switching devices, resetting Phantom, or whenever you need a secure offline backup. Even if ...Updated 21 days agoManage active networks in PhantomPhantom supports multiple blockchain networks, including Solana and Ethereum. If you don't use some of these networks regularly, you can turn them off in the app. The Solana network is always on and c...Updated 12 days ago","tokens":834,"squid":"spider-10","role":"Tooling Spider","at":1791342227213,"hash":"b38b4f117a77923dab396dad248db734fcc61370"}
{"url":"https://help.phantom.com/articles/25334064171795","domain":"help.phantom.com","title":"View your recovery phrase or private keys in Phantom","text":"View your recovery phrase or private keys in PhantomYour Secret Recovery Phrase and private keys are the backup credentials for your wallet. Export them before switching devices, resetting Phantom, or whenever you need a secure offline backup. Even if your wallet was created with a Google or Apple account, it still has a recovery phrase.If you imported private keys into Phantom, export those too.You may also need your recovery phrase or private keys to restore your wallet after reinstalling Phantom or moving to a new device.\n Warning: Never share your Secret Recovery Phrase or private\n key with anyone. Anyone with access to either has full control of your wallet.\n Phantom Support will never ask for your recovery phrase or private key.\n Mobile app #View your recovery phrase #\nTap your profile avatar in the upper left, then tap Settings.\nGo to Security & Privacy > Show Recovery Phrase.\nView or copy your recovery phrase.\nStore your recovery phrase securely offline.View your private keys #\nTap your profile avatar in the upper left, then tap Settings.\nTap Manage Accounts.\nTap the three-dot icon next to an account.\nTap Show Private Key. Not available? See why.\nSelect a network.\nView or copy your private key.\nStore your private key securely offline.If a network isn't listed, make sure it's turned on in Settings > Active Networks.Browser extension #View your recovery phrase #\nClick your profile avatar in the upper left.\nGo to Settings > Security & Privacy.\nClick Show Recovery Phrase.\nView or copy your recovery phrase.\nStore your recovery phrase securely offline.View your private keys #\nClick your profile avatar in the upper left.\nClick Manage Accounts.\nClick the account whose private key you want to view.\nClick Show Private Key. Not available? See why.\nSelect a network.\nView or copy your private key.\nStore your private key securely offline.If a network isn't listed, make sure it's turned on in Settings > Active Networks.When private key export may not be available #Wallets created with a Google or Apple account are powered by Phantom KMS. KMS stores your wallet keys in secure enclaves rather than on your device. Because the private key never leaves the enclave environment, the Show Private Key option is not available for these accounts. This is expected behavior.Your wallet is still fully backed up. Use Show Recovery Phrase to export your recovery phrase as backup.When recovery phrase export may not be available #If you're using a hardware wallet such as Ledger, Phantom does not expose its recovery phrase or private keys. This is expected behavior.Related articlesRemove an imported recovery phrase from PhantomIf you imported more than one recovery phrase, you can remove one without affecting the others. Removing a recovery phrase removes all its linked accounts. It does not remove the addresses or assets o...Updated 21 days agoUse a Ledger wallet with the Phantom mobile appYou can add accounts from a Ledger hardware wallet to the Phantom mobile app over Bluetooth. This works for both new setups and existing Phantom wallets. For a full list of supported hardware wallets,...Updated 15 days agoIf a feature is unavailable in your country or regionIf you're seeing a message in Phantom when trying to access a feature such as perps, predictions, or tokenized stocks, this means the feature you're trying to use isn't available in your location.Updated 2 days agoManage your accounts in PhantomYour Phantom wallet can hold multiple accounts. Each account includes addresses on every supported network, so you can use different accounts for different purposes, like long-term holdings, predictio...Updated a month agoManage your Phantom usernameYour username is the @handle that shows on your Phantom profile. It's the public-facing identity others use to transfer you Cash, find you in chats, and follow your activity. A username is required to...Updated 12 days ago","tokens":978,"squid":"spider-10","role":"Tooling Spider","at":1791342240463,"hash":"24c6bb7bcce906435c722ca89b48838f9a608d95"}
{"url":"https://alt.gov.arbitrum.foundation/delegates/0x2e3bef6830ae84bb4225d318f9f61b6b88c147bf","domain":"alt.gov.arbitrum.foundation","title":"Delegate Profile | Arbitrum Governance | Arbitrum Governance","text":"Back to DelegatesDelegate ProfileArbitrum DAO delegateCamelotSeeking Delegation0x2e3bef6830ae84bb4225d318f9f61b6b88c147bfVoting Power12.5M ARBDelegators10,363Delegate ARBConnect a wallet to delegate ARB voting power.Delegation updates voting power only. Your ARB stays in your wallet.Delegate StatementInterested in exploring DeFi development and improving governance participation to support new and needed applications on Arbitrum. Excited to collaborate with Camelot DAO and make innovative ideas a reality.Name (organization or individual)\nCamelot DAO (organization)\nWallet Address or ENS\n0x2e3BEf6830Ae84bb4225D318F9f61B6b88C147bF\nTally Profile URL\n[Tally](\n\n[Camelot DAO's DAO Profile](\nDAO memberships, votes and proposal\nWhat area are you most interested in contributing to? choose up to two tags\n\nDeFi development on Arbitrum\nImproving Governance participation\n\nPlease share your stance on overall goals for the DAO\nWe believe that the ArbitrumDAO should primarily focus on two areas:\n\nSupporting the development of new and needed applications\nHelping onboard new users who would benefit from the applications on Arbitrum\n\nAs the native DEX and launchpad for new projects on Arbitrum, Camelot is uniquely positioned to help with both of these areas. Our Round Table Protocols represent the majority of applications on Arbitrum and together, they help make Arbitrum and Camelot a collaborative and supportive home for innovation.\nSample Voting Issue 1\n\nAgainst\nSuch large DAO token allocations should generally only be made for programs which are overwhelmingly popular. The mere fact that the vote is nearly 50/50 should show that it probably shouldn’t pass. To make the vote less contentious, we would probably recommend reducing the payment schedule to monthly or quarterly instead of annually (making the DAOs upfront commitment smaller by an order of magnitude). We might even recommend introducing a trial period which is only continued if the trial hits certain performance metrics.\nDAOs should always try to maximize the accountability of individuals and entities that interact with them. Paying for services on a performance basis should almost always be preferred, and DAOs should try to structure compensation plans that align incentives. Especially in decentralized environments involving anonymous individuals, economic incentives must be aligned to ensure quality outcomes.\n\nSample Voting Issue 2\nThe first vote should have triggered a trustless execution of the hack repayment. It’s unclear what to do after two such votes when neither had executable code tied to their outcomes. Thus, we would never put such a monumental vote to governance without the executable code attached.\nThe reimbursement amount should be determined by the token holders as they have the long term interest of the project in mind. If executable code had been attached to the first vote, they would have fully reimbursed the hack victims. If token holders directly voted for this code to be executed, it would have been the right outcome.\nLanguages I speak and write\nEnglish, French","tokens":770,"squid":"spider-07","role":"Council Spider","at":1791342248319,"hash":"6894f104f6c862d47f00be340896a0ea9634ecd6"}
{"url":"https://akash.network/roadmap/aep-2","domain":"akash.network","title":"Decentralized Cloud Exchange Specification","text":"Akash Network Roadmap Roadmap 2018 Q3 aep-2 Decentralized Cloud Exchange Specification Final Summary\nDecentralized cloud computing exchange connects those who need computing resources with those that have computing capacity to lease providers. Based on the Akash Network Whitepaper.\nSpecification\n\nSummary\nSpecification\n\nWorkflow\n\nActors\n\nTenants\nDatacenters\nValidators\nMarketplace Facilitators\n\nDistributed Exchange\n\nGlobal Parameters\nModels\n\nComputeUnit\nResourceGroup\nDeployment\nDeploymentInfrastructure\nOrder\nFulfillment\nLease\nLeaseConfirmation\n\nTransactions\nSubmitDeployment\nUpdateDeployment\nCancelDeployment\nSubmitFulfillment\nCancelFulfillment\nSubmitLeaseConfirmation\nSubmitLease\nSubmitStaleLease\nWorkflows\n\nTenants\nMarketplace Facilitators\n\nMatchOpenOrders\nInvalidateStaleLeases\n\nDatacenters\n\nConfirmCurrentLeases\nBidOnOpenOrders\n\nDeployments\n\nWorkflow\nManifest Distribution\nOverlay Network\nModels\n\nStack\nManifest\nDeployment\nWorkload\nConnection\nLeasedWorkload\n\nAutomation\n\nExamples\n\nLatency-Optimized Deployment\nMachine Learning Deployment\n\nHistory\nCopyright\n\nWorkflow\n\nTenants define desired infrastructure, workloads to run on infrastructure, and how workloads can connect to one another.\n\nDesired lifetime of resources is expressed via collateral requirements.\n\nOrders are generated from the tenant’s definition.\nDatacenters bid on open orders.\nThe bid with lowest price gets matched with order to create a lease.\nOnce lease is reached, workloads and topology are delivered to datacenter.\nDatacenter deploy workloads and allow connectivity as specified by the tenant.\nIf a datacenter fails to maintain lease, collateral is transferred to tenant, and a new order is crated for the desired resources.\n\nActors\nTenants\nA tenant hosting an application on the Akash network\nDatacenters\nEach datacenter will host an agent which is a mediator between the with the Akash Network and datecenter-local infrastructure.\nThe datacenter agent is responsible for\n\nBidding on orders fulfillable by the datacenter.\nManaging managing active leases it is a provider for.\n\nValidators\nA Akash Node that is elected to be a validator in the DPoS consensus scheme.\nMarketplace Facilitators\nMarketplace facilitators maintain the distributed exchange (marketplace). Validators will initially perform this function.\nDistributed Exchange\nGlobal Parameters\n\nNameDescriptionreconfirmation-periodNumber of blocks between required lease confirmationscollateral-interest-rateInterest rate awarded to datacenters for collateral posted with fulfillment orders\nModels\nComputeUnit\n\nFieldDefinitioncpuNumber of vCPUsmemoryAmount of memory in GBdiskAmount of block storage in GB\nResourceGroup\n\nFieldDefinitioncomputecompute unit definitionpricePrice of compute unit per time unitcollateralCollateral per compute unitcountNumber of defined compute units\nDeployment\nA Deployment represents the state of a tenant’s application. It includes desired infrastructure and pricing parameters, as well as workload definitions and connectivity.\n\nFieldDefinitioninfrastructureList of deployment infrastructure definitionswait-durationAmount of time to wait before matching generated orders with fulfillment orders\nDeploymentInfrastructure\nDeploymentInfrastructure represents a set of resources (including pricing) that a tenant would like to be provisioned in a single datacenter.\norders are created from deployment infrastructure as necessary.\n\nFieldDefinitionregionGeographic region of datacenterpersistWhether or not to maintain active lease if current lease is brokenresourcesList of resource groups for this datacenter\nWithin the resources list, resource group fields are interpreted as follows:\n\nFieldDefinitionpriceMaximum price tenant is willing to pay.collateralAmount of collateral that the datacenter must post when creating a fulfillment order\nOrder\nA Order is generated for each deployment infrastructure present in the deployment.\n\nFieldDefinitionregionGeographic region of datacenterresourcesList of resource groups for this datacenterwait-durationNumber of blocks to wait before matching the order with fulfillment orders\nFulfillment\nA Fulfillment represents a datacenter’s interest in providing the resources requested in a order.\n\nFieldDefinitionorderID of order which is being bid on.resourcesList of resource groups for this datacenter.\nThe resources list must match the order’s resources list for each resource group with the following rules:\n\nthe compute, count,collateral fields must be the same.\nthe price field represents the datacenter’s offering price and must be less than or equal to the order’s price.\n\nThe total collateral required to post a fulfillment order is the sum of collateral fields present in the order’s resources list.\nLease\nA Lease represents a matching order and fulfillment order.\n\nFieldDefinitiondeployment-orderID of orderfulfillment-orderID of fulfillment order\nLeaseConfirmation\nA LeaseConfirmation represents a confirmation that the resources are being provided by the datacenter. Its creation may initiate a transfer of\ntokens from the tenant to the datacenter\n\nFieldDefinitionleaseID of lease being confirmed\nTransactions\nSubmitDeployment\nSent by a tenant to deploy their application on Akash. A order will be created for each datacenter\nconfiguration described in the deployment\nUpdateDeployment\nSent by a tenant to update their application on Akash.\nCancelDeployment\nSent by a tenant to cancel their application on Akash.\nSubmitFulfillment\nSent by a datacenter to bid on a order.\nCancelFulfillment\nSent by a datacenter to cancel an existing fulfillment order.\nSubmitLeaseConfirmation\nSent by a datacenter to confirm a lease that it is engaged in. This should\nbe called once every reconfirmation period rounds.\nSubmitLease\nSent by a validator to match a order with a fulfillment order.\nSubmitStaleLease\nSent by a validator after finding a lease that has not been confirmed in reconfirmation period rounds.\nWorkflows\nTenants\nTenants submit their deployment to the network via SubmitDeployment.\nMarketplace Facilitators\nEvery time a new block is created, each facilitator runs MatchOpenOrders and InvalidateStaleLeases\nMatchOpenOrders\nFor each order that is ready to be fulfilled (state=open,wait-duration has transpired):\n\nFind the matching fulfillment order with the lowest price.\nEmit a SubmitLease transaction to initiate a lease for the matching orders.\n\nInvalidateStaleLeases\nFor each active lease that has not been confirmed in reconfirmation-period:\n\nEmit a SubmitStaleLease transaction\n\nDatacenters\nEvery time a new block is created, each datacenter runs ConfirmCurrentLeases and BidOnOpenOrders\nConfirmCurrentLeases\nFor each lease currently provided by the datacenter:\n\nEmit a SubmitLeaseConfirmation event for the lease.\n\nBidOnOpenOrders\nFor each open order:\n\nIf the datacenter is out of collateral, exit.\nIf datacenter is not able to fulfill the order, skip to next order.\nEmit a SubmitFulfillment transaction for the order\n\nDeployments\nOnce resources have been procured, clients must distribute their workloads to providers so that they\ncan execute on the leased resources. We refer to the current state of the client’s workloads on the\nAkash Network as a “deployment”.\nA tenant describes their desired deployment in a “manifest”. The manifest contains workload\ndefinitions, configuration, and connection rules. Providers use workload definitions and\nconfiguration to execute the workloads on the resources they’re providing, and use the connection\nrules to build an overlay network and firewall configurations.\nA hash of the manifest is known as the deployment “version” and is stored on the blockchain-based\ndistributed database.\nWorkflow\n\nStack infrastructure is submitted to the ledger.\nAsk orders are generated for resources defined in the stack infrastructure.\nProviders (data centers) bid on orders.\nLeases are reached by matching bid and ask orders.\nStack manifest is distributed to deployment data centers (lease providers).\nDatacenters deploy workloads and distribute connection parameters to all other deployment datacenters.\nOverlay network is established to allow for connectivity between workloads.\n\nManifest Distribution\nEach on-chain deployment contains a hash of the manifest. This hash represents the deployment\nversion.\nThe manifest contains sensitive information which should only be shared with participants of the\ndeployment. This poses a problem for self-managed deployments - Akash must distribute the workload\ndefinition autonomously, without revealing its contents to unnecessary participants.\nTo address these issues, we devised a peer-to-peer file sharing scheme in which lease participants\ndistribute the manifest to one another as needed. The protocol runs off-chain over a TLS\nconnection; each participant can verify the manifest they received by computing its hash and\ncomparing this with the deployment version that is stored on the blockchain-backed distributed\ndatabase.\nIn addition to providing private, secure, autonomous manifest distribution, the peer-to-peer\nprotocol also enables fast distribution of large manifests to a large number of datacenters.\nOverlay Network\nBy default, a workload’s network is isolated - nothing can connect to it. While this is secure, it\nis not practical for real-world applications. For example, consider a simple web application:\nend-tenant browsers should have access to the web tier workload, and the web tier needs to communicate\nto the database workload. Furthermore, the web tier may not be hosted in the same datacenter as the\ndatabase.\nOn the Akash Network, clients can selectively allow communications to and between workloads by\ndefining a connection topology within the manifest. Datacenters use this topology to configure\nfirewall rules and to create a secure network between individual workloads as needed.\nTo support secure cross-datacenter communications, providers expose workloads to each other through\na mTLS tunnel. Each workload-to-workload connection uses a distinct tunnel.\nBefore establishing these tunnels, providers generate a TLS certificate for each required tunnel and\nexchange these certificates with the necessary peer providers. Each provider’s root certificate is\nstored on the blockchain-based distributed database, enabling peers to verify the authenticity of\nthe certificates it receives.\nOnce certificates are exchanged, providers establish an authenticated tunnel and connect the\nworkload’s network to it. All of this is transparent to the workloads themselves - they can connect\nto one another through stable addresses and standard protocols.\nModels\nStack\nA stack is a description of all components necessary to deploy an application on the Akash Network.\nA stack includes:\n\nInfrastucture requirements.\nManifest of workloads to deploy on procured infrastructure.\n\nManifest\nA manifest describes workloads and how they should be deployed.\nA manifest includes:\n\nWorkloads to be executed.\nData center placement for each workload.\nConnectivity rules describing which entities are allowed to connect to each workload.\n\nDeployment\nA deployment represents the current state of a stack as fulfilled by the Akash Network.\n\nInfrastructure procured via the cloud exchange (leases).\nManifest distribution state.\nOverlay network state.\n\nWorkload\n\nFieldDescriptionnameWorkload namecontainerDocker containercomputeresources needed for each instancecountnumber of instances to runconnectionsList of allowed incomming connections\nConnection\n\nFieldDescriptionportTCP portworkloadWorkload name to allow incomming connection fromdatacenterDatacenter to allow incomming connection fromglobalIf true, allow all connections, regardless of source\nLeasedWorkload\n\nFieldDescriptionleaseLease IDworkloadWorkload namecertificateSSL certificate for workloadaddressesList of (address,port) for connecting to remote workload\nAutomation\nThe dynamic nature of cloud infrastructure is both a blessing and a curse for operations management.\nThat new resources can be provisioned at will is a blessing; the exploding management overhead and\ncomplexity of said resources is a curse. The goal of DevOps — the practice of managing deployments\nprogrammatically — is to alleviate the pain points of cloud infrastructure by leveraging its\nstrengths.\nThe Akash Network was built from the ground up to provide DevOps engineers with a simple but\npowerful toolset for creating highly-automated deployments. The toolset is comprised of the\nprimitives that enable non-management applications — generic workloads and overlay networks — and\ncan be leveraged to create autonomous, self-managed systems.\nSelf-managed deployments on Akash are a simple matter of creating workloads that manage their own\ndeployment themselves. A DevOps engineer may employ a workload that updates DNS entries as\nproviders join or leave the deployment; tests response times of web tier applications; and scales up\nand down infrastructure (in accordance with permissions and constraints defined by the client) as\nneeded based on any number of input metrics. The “management tier” may be spread across all\ndatacenters for a deployment, with global state maintained by a distributed database running over\nthe secure overlay network.\nExamples\nLatency-Optimized Deployment\nMany web-based applications are “latency-sensitive” - lower response times from application servers\ntranslates into a dramatically improved end-tenant experience. Modern deployments of such\napplications employ content delivery networks (CDNs) to deliver static content such as images to end\ntenants quickly.\nCDNs provide reduced latency by distributing content so that it is geographically close to the tenants\nthat are accessing it. Deployments on the Akash Network can not only replicate this approach, but\nbeat it - Akash gives clients the ability to place dynamic content close to an application’s tenants.\nTo implement a self-managed “dynamic delivery network” on Akash, a DevOps engineer would include a\nmanagement tier in their deployment which monitors the geographical location of clients. This\nmanagement tier would add and remove datacenters across the globe, provisioning more resources in\nregions where tenant activity is high, and less resources in regions where tenant participation is low.\nMachine Learning Deployment\nMachine learning applications employ a large number of nodes to parallelize computations involving\nlarge datasets. They do their work in “batches” - there is no “steady state” of capacity that is\nrequired.\nA machine learning application on Akash may use a management tier to proactively procure resources\nwithin a single datacenter. As a machine learning task begins, the management tier can “scale up”\nthe number of nodes for it; when a task completes, the resources provisioned for it can be\nrelinquished.\nHistory\nMarch 8, 2018: Initial Design based on Akash Whitepaper\nCopyright\nAll content herein is licensed under Apache 2.0. Completion date: 7/30/2018 Created: 3/18/2018 Last Updated: Category: Core Status: Final Authors: Adam Bozanich Resolution: \nLink\n\nView next aep\n Stack Definition Language SpecificationCompletion Date: 7/29/2018Stack Definition Language","tokens":3782,"squid":"spider-03","role":"Compute Spider","at":1791342256407,"hash":"550947edb119574c6bc604ae1a732734fb21e1b9"}
{"url":"https://developer.arbitrum.io/run-a-node/run-nitro-dev-node","domain":"developer.arbitrum.io","title":"How to run a local Nitro dev node","text":"How to run a local Nitro dev nodeThis page provides instructions for setting up and running a local Nitro dev node for contract testing and development.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 as and Nitro as , 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 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 nitro-devnode repository:\ngit clone https://github.com/OffchainLabs/nitro-devnode.git\ncd 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 is set to 0x0000000000000000000000000000000000000000. However, you can use the ArbDebug 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 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.How is this guide?Run a local full chain simulationThis page provides instructions for setting up a complete local development environment for testing Arbitrum contracts in a fully simulated environment.L1 Ethereum RPC providersA reference list of Ethereum beacon chain RPC providers that Arbitrum node operators can use to access blob data after the Dencun upgrade.","tokens":1220,"squid":"spider-01","role":"Chain Spider","at":1791342265899,"hash":"7645fecfdfbe7d9070c733a46db24196569043c0"}
{"url":"https://alt.gov.arbitrum.foundation/privacy","domain":"alt.gov.arbitrum.foundation","title":"Privacy Policy – Arbitrum | Arbitrum Governance","text":"Last Updated: April 20, 2026PRIVACY POLICYThis Privacy Policy applies to the processing of personal information by The Arbitrum Foundation (“Arbitrum Foundation,” “we,” “us,” or “our”) including on our website available at https://alt.gov.arbitrum.foundation and our other online or offline offerings that link to, or are otherwise subject to, this Privacy Policy (collectively, the “Services”).Table of ContentsUPDATES TO THIS PRIVACY POLICYPERSONAL INFORMATION WE COLLECTHOW WE USE PERSONAL INFORMATIONHOW WE SHARE PERSONAL INFORMATIONYOUR PRIVACY CHOICES AND RIGHTSINTERNATIONAL TRANSFERS OF PERSONAL INFORMATIONRETENTION OF PERSONAL INFORMATIONSUPPLEMENTAL NOTICE FOR EU/UK GDPRCHILDREN’S PERSONAL INFORMATIONCONTACT US1. UPDATES TO THIS PRIVACY POLICYWe may update this Privacy Policy from time to time in our sole discretion. If we do, we’ll let you know by posting the updated Privacy Policy on our website, and we may also send other communications.2. PERSONAL INFORMATION WE COLLECTWe collect personal information that you provide to us, personal information we collect automatically when you use the Services, and personal information from third-party sources, as described below.(a) Personal Information You Provide to Us DirectlyWe may collect personal information that you provide to us.Wallet Information. In order to use the Services, you will need to connect your digital wallet (a “Wallet”). We and our service providers may collect personal information and details associated with your transactions such as wallet addresses, asset types, and transaction history in connection with the Services. Note that your interactions with third-party wallet services are subject to each Wallet provider’s respective privacy policy, not this Privacy Policy.Your Communications with Us. We, and our service providers, may collect the information you communicate to us, such as through email.Interactive Features. We and others who use our Services may collect personal information and voting information that you submit or make available through our interactive features (e.g., messaging features, commenting functionalities, forums, blogs, and social media pages). Any information you provide using the public sharing features of the Services will be considered “public.”Governance and Profile Information. We may collect personal information you provide in connection with governance participation, such as delegate profiles, Security Council member or candidate information, biographies, statements, affiliations, and other information submitted through forms or profile features of the Services.(b) Personal Information Collected AutomaticallyWe may collect personal information automatically when you use the Services.Device Information. We may collect personal information about your device, such as your Internet protocol (IP) address, user settings, cookie identifiers, other unique identifiers, browser or device information, Internet service provider, and location information (including, as applicable, an approximate location derived from the IP address and precise geo-location information).Usage Information. We may collect personal information about your use of the Services, such as the pages that you visit, items that you search for, the types of content you interact with, information about the links you click, the frequency and duration of your activities, and other information about how you use the Services.Cookie Notice (and Other Technologies). We, as well as third parties, may use cookies, pixel tags, and other technologies (“Technologies”) to automatically collect personal information through your use of the Services.Cookies. Cookies are small text files stored in device browsers.Pixel Tags/Web Beacons. A pixel tag (also known as a web beacon) is a piece of code embedded in the Services that collects personal information about use of or engagement with the Services. The use of a pixel tag allows us to record, for example, that a user has visited a particular web page or clicked on a particular advertisement. We may also include web beacons in emails to understand whether messages have been opened, acted on, or forwarded.See “Your Privacy Choices and Rights” below to understand your choices regarding these Technologies.(c) Personal Information Collected from Third PartiesThird-Party Services. We may collect personal information about you from third parties. For example, if you access the Services using a third-party website, application, service, products, or technology (each a “Third-Party Service”), we may collect personal information about you from that Third-Party Service that you have made available via your privacy settings.Blockchain Information. We may collect personal information that is publicly available on the blockchain.3. HOW WE USE PERSONAL INFORMATIONWe use personal information for a variety of business purposes, including to provide the Services, for administrative purposes, and to provide you with marketing materials, as described below.(a) Provide the ServicesWe use personal information to provide the Services, such as:Providing access to certain areas, functionalities, and features of the Services;Communicating with you;Answering requests;Sharing personal information with third parties as needed to provide the Services; andProcessing your transaction information.(b) Improve the Services and Develop New Products and ServicesWe use personal information to improve the Services and to develop new products and services, such as:Improving, upgrading, or enhancing the Services.(c) Operate Our BusinessWe use personal information to operate our business, such as:Pursuing our legitimate interests such as direct marketing, research and development (including marketing research), network and information security, and fraud prevention;Carrying out analytics;Creating de-identified and/or aggregated information;Allowing you to register for events;Enforcing our agreements and policies; andCarrying out activities that are required to comply with our legal obligations.(d) MarketingWe may use personal information in connection with our marketing activities including to tailor and to provide you with marketing communications, promotions, and offers that may interest you.Some of the ways we market to you include email campaigns and custom audiences advertising.(e) With Your Consent or DirectionWe may use personal information: (i) for other purposes that are clearly disclosed to you at the time you provide the personal information, (ii) with your consent, or (iii) as otherwise directed by you.4. HOW WE SHARE PERSONAL INFORMATIONWe share personal information with third parties for a variety of business purposes, including to provide the Services, to protect us or others, or in connection with a major business transaction such as a merger, sale, or asset transfer, as described below.(a) Disclosures to Provide the ServicesWe may share any of the personal information we collect with the categories of third parties described below.Disclosures to the Blockchain. Aspects of the Services may be hosted on or interact with the blockchain. Where you use aspects of the Services that are hosted on or interact with the blockchain, information about your interactions and/or transactions will be shared with the applicable blockchain network and may be accessible to third parties due to the nature of the blockchain protocol.Service Providers. We may share personal information with service providers that assist us with the provision of the Services. This may include, but is not limited to, service providers that provide us with hosting services, customer service, AI or machine learning services, analytics, marketing services, IT support, and related services. These Service Providers are generally processors acting on our instructions to the extent we are acting as data controller. Additionally, a Service Provider may use your personal data where it is necessary for compliance with a legal obligation to which it is directly subject. The Service Provider, in respect of this specific use of personal data acts as a data controller.Other Users You Share or Interact With. The Services may allow users to share personal information or interact with other users of the Services.Third-Party Services You Share or Interact With. The Services may link to or allow you to interface with, interact with, share information with, direct us to share information with, access, and/or use a Third-Party Service.Any personal information shared with a Third-Party Service will be subject to the Third-Party Service’s privacy policy. We are not responsible for the processing of personal information by Third-Party Services.Business Partners. We may share your personal information with business partners we work with to provide you with a product or service you have requested. We may also share your personal information with business partners with whom we jointly offer products or services.Once your personal information is shared with our business partner, it will also be subject to our business partner’s privacy policy. We are not responsible for the processing of personal information by our business partners.Affiliates. We may share your personal information with our corporate affiliates.Advertising Partners. We may share your personal information with third-party advertising partners. These third-party advertising partners may set Technologies on our Services to collect personal information regarding your activities and your device (e.g., IP address, cookie identifiers, page(s) visited, location, time of day). These advertising partners may use this personal information (and similar information collected from other services) to tailor and deliver personalized ads to you when you visit digital properties within their networks. This practice is commonly referred to as “interest-based advertising,” “personalized advertising,” or “targeted advertising.”(b) Disclosures to Protect Us or OthersWe may share your personal information and related information with external parties if we, in good faith, believe doing so is required or appropriate to comply with law enforcement requests, national security requests, or other government requests; comply with legal process, such as a court order or subpoena; protect your, our, or others’ rights, property, or safety; enforce our policies or contracts; collect amounts owed to us; or assist with an investigation or prosecution of suspected or actual unauthorized or illegal activity.(c) Disclosure in the Event of Merger, Sale, or Other Asset TransfersIf we are involved in a merger, acquisition, financing, reorganization, bankruptcy, receivership, purchase or sale of assets, transition of service to another provider, or other similar corporate transaction, your personal information may be shared, sold, or transferred as part of such a transaction.5. YOUR PRIVACY CHOICES AND RIGHTSYour Privacy Choices. The privacy choices you may have about your personal information are described below.Email Communications. If you receive an unwanted email from us, you can use the unsubscribe functionality found at the bottom of the email to opt out of receiving future emails. Note that you will not be able to opt out of certain communications (e.g., communications regarding the Services or updates to this Privacy Policy).“Do Not Track.” Do Not Track (“DNT”) is a privacy preference that users can set in certain web browsers. Please note that we do not respond to or honor DNT signals or similar mechanisms transmitted by web browsers.Cookies. You may stop or restrict the placement of Technologies on your device or remove them by adjusting your preferences as your browser or device permits. However, if you adjust your preferences, the Services may not work properly.The online advertising industry also provides mechanisms that may allow you to opt out of receiving targeted ads from organizations that participate in self-regulatory programs. To learn more, visit the Network Advertising Initiative, the Digital Advertising Alliance, and the European Digital Advertising Alliance.Please note you must separately opt out in each browser and on each device.Your Privacy Rights. In accordance with applicable law, you may have the right to:Request Access to or Portability of Your Personal Information;Request Correction of Your Personal Information;Request Deletion of Your Personal Information;Request Restriction of or Object to Our Processing of Your Personal Information; andWithdraw Your Consent to Our Processing of Your Personal Information. Please note that your withdrawal will take effect only for future processing and will not affect the lawfulness of processing before the withdrawal.If you would like to exercise any of these rights, please contact us as set forth in “Contact Us” below.We will process such requests in accordance with applicable laws.If your personal information is subject to the applicable data protection laws of the European Economic Area or the United Kingdom, you have the right to lodge a complaint with the competent supervisory authority if you believe that our processing of your personal information violates applicable law.6. INTERNATIONAL TRANSFERS OF PERSONAL INFORMATIONAll personal information processed by us may be transferred, processed, and stored anywhere in the world, including, but not limited to, the United States or other countries, which may have data protection laws that are different from the laws where you live. These countries may or may not have adequate data protection laws as defined by the data protection authority in your country.If we transfer personal information from the European Economic Area, Switzerland, and/or the United Kingdom to a country that does not provide an adequate level of protection under applicable data protection laws, one of the safeguards we may use to support such transfer is the EU Standard Contractual Clauses.For more information about the safeguards we use for international transfers of your personal information, please contact us as set forth below.7. RETENTION OF PERSONAL INFORMATIONWe store the personal information we collect as described in this Privacy Policy for as long as you use the Services, or as long as necessary to fulfill the purpose(s) for which it was collected, or as long as necessary to pursue our business purposes.To determine the appropriate retention period for personal information, we may consider applicable legal requirements; the amount, nature, and sensitivity of the personal information; certain risk factors; the purposes for which we process your personal information; and whether we can achieve those purposes through other means.8. SUPPLEMENTAL NOTICE FOR EU/UK GDPRThis Supplemental Notice for EU/UK GDPR applies only to our processing of personal information that is subject to the EU or UK General Data Protection Regulation.In some cases, providing personal information may be a requirement under applicable law, a contractual requirement, or a requirement necessary to enter into a contract. If you choose not to provide personal information in cases where it is required, we will inform you of the consequences at the time of your refusal to provide the personal information.Arbitrum Foundation’s processing of your personal information may be supported by one or more of the following lawful bases:Privacy Policy SectionLawful Basis: Performance of a Contract (i.e., to provide the Services to you)Lawful Basis: Legitimate InterestLawful Basis: ConsentLawful Basis: For Compliance with Legal ObligationsSection 3A: Provide the Services✔✔✔✔Section 3B: Improve the Services and Develop New Products✔✔✔✔Section 3C: Operate Our Business✔✔✔✔Section 3D: Marketing✔✔Section 3E: With Your Consent or Direction✔✔✔9. CHILDREN’S PERSONAL INFORMATIONThe Services are not directed to children under 18 (or other age as required by local law outside the United States), and we do not knowingly collect personal information from children.If you are a parent or guardian and believe that your child has uploaded personal information to the Services in violation of applicable law, you may contact us as described in “Contact Us” below.10. CONTACT USIf you have any questions about our privacy practices or this Privacy Policy, or to exercise your rights as detailed in this Privacy Policy, please contact us at: info@arbitrum.foundation.","tokens":4107,"squid":"spider-07","role":"Council Spider","at":1791342269717,"hash":"3c857f3a698d014e62cf2a577df21fdebfc8a8a3"}
{"url":"https://developer.arbitrum.io/run-a-node/run-full-node","domain":"developer.arbitrum.io","title":"How to run a full node for an Arbitrum chain","text":"How to run a full node for an Arbitrum chainLearn how to run an Arbitrum node on your local machineRequest 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, , 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 — , , , , or —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 : (the default) or . 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 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 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:\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=<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/arbitrum\nchmod -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.\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.\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.How is this guide?Start hereLearn the prerequisites for running an Arbitrum node on your local machineAssign node rolesUnderstand how a Nitro node's role (RPC node, archive node, sequencer, batch poster, validator — optionally with split validation — or feed relay) is set by configuration flags, and how to convert a node from one role to another.","tokens":4248,"squid":"spider-01","role":"Chain Spider","at":1791342276851,"hash":"cab2b8c5a516116a38e55af7ac33b9335792e4fe"}
{"url":"https://akash.network/blog/product/1","domain":"akash.network","title":"Akash Network Blog - Insights into Decentralized Cloud Computing","text":"Product Jul 28, 2026 Product Confidential Compute Comes to Akash By Greg Osuri 6 min read May 5, 2026 Product Introducing Console Air: Self-Host, Self-Custody Akash By Maxime Beauchamp 5 min read Nov 22, 2025 Product AkashML: Managed AI Inference on the Decentralized Supercloud By Anil Murty 5 min read Oct 28, 2025 Product Akash Mainnet 14: The Core Overhaul That Changes Everything By Anil Murty 5 min read Aug 18, 2025 Product Provider Console - Earnings API By Anil Murty 3 min read Aug 17, 2025 Product Billing & Usage Analytics in Akash Console & API By Anil Murty 3 min read Aug 16, 2025 Product Console API for Credit Card Users By Anil Murty 3 min read Aug 15, 2025 Product Alerts & Notifications in Akash Console By Anil Murty 3 min read Aug 14, 2025 Product Automatic Escrow Top-Up By Anil Murty 3 min read Nov 23, 2022 Product Introducing IP Leases on Akash Network By Anil Murty 4 min read Jan 18, 2022 Product How to Create NFT Plots on Akash with Chia Network By Andrew Mello 4 min read Oct 6, 2021 Product Product Roadmap 2022 By Greg Osuri 2 min read","tokens":267,"squid":"spider-03","role":"Compute Spider","at":1791342276909,"hash":"c5ee21d31debf36c12af483f45744e967cfc935f"}
{"url":"https://arbitrum.foundation/governance","domain":"arbitrum.foundation","title":"Arbitrum Governance","text":"Empowering Arbitrum ContributorsFrom pitching initiatives to building the technology, our contributors focus on growing the Arbitrum ecosystem and protecting the network.Explore GovernanceDelegate your tokensEngage with the latest going on in the DAO!1. Visit the ForumsSubmit or review new proposal discussions and stay updated on DAO grants.Explore2. Temp Check VotingSubmit, review or vote on proposals to gauge DAO’s interest before they reach onchain vote.Explore3. Onchain VotingSubmit proposal to Tally for an on-chain, and final vote.ExploreFollow @arbitrumdao_gov on X for the latest updates on governance.","tokens":154,"squid":"spider-07","role":"Council Spider","at":1791342280407,"hash":"2a3ebbb23fef9b51d0cb04768a0e4533add35efb"}
{"url":"https://developer.arbitrum.io/run-a-node/faq","domain":"developer.arbitrum.io","title":"Frequently asked questions: Run a node","text":"Frequently asked questions: Run a nodeList of questions and answers frequently asked by node runnersRequest an updateHow do I run a node?\nSee instructions in our guide about running a full node!\nHow to verify the integrity of the Nitro database I currently have?\nWe use an accumulator hash for all messages, ensuring that a new message doesn't get added to the database without the preceding message being valid.\nTo verify that everything is functioning correctly, you can check if it is syncing and confirm that the latest block is consistent with other Arbitrum nodes. For instance, you might compare it with information on Arbiscan (please note that the search function on Arbiscan does not support searches by block hash).\nHow can I check if the node is running properly and diagnose the issue if it is not?\nWe have trace-level logging RPC request implemented on our node. You could use it to log all requests and responses at the trace level. (The performance impact of this should be negligible compared to the network overhead of an RPC request in the first place, especially considering that the request/response will only be serialized for logging if that log level is enabled.)\nWhy do I need an L1 node to run an Arbitrum node?\nDuring the node syncing stage, Arbitrum nodes read transactions from batches that have already been posted and executed on Layer 1. They connect to the Sequencer feed to receive new incoming batched transactions that have not been posted to L1 yet.\nWhen fully synced, the Arbitrum node uses the State Transition Function (STF) to consume transactions from the Sequencer feed and update the state accordingly. It also waits for the L1 batch to post. If the finalized L1 batch differs from what the Sequencer published, the node will update its state based on the L1 batched transactions.\nCan I run an Arbitrum node in p2p mode?\nArbitrum doesn't have a consensus mechanism, so \"p2p mode\" doesn't apply. For nodes to sync to the latest chain state, they connect to an L1 node to sync the chain's history that's been posted in calldata and connect to the Sequencer feed for the transactions that have yet to be posted in batches. In no case do nodes need to peer up and sync with each other.\nHow do I read messages from the Sequencer feed?\nRunning an Arbitrum relay locally as a Feed Relay lets you subscribe to the Sequencer feed for real-time data as the Sequencer accepts and orders transactions offchain. Refer to How to read the sequencer feed for a detailed guide.\nHow do I run a node locally for development?\nSee instructions in our  our guide about running a local devnet node.\nWe recommend running Nitro nodes via Docker; to compile directly / run without Docker, you can follow the steps in How to build Nitro locally.\nIs there any way to retrieve pre-Nitro archive data from a Nitro node?\nThe pre-Nitro stack is also called the \"classic\" stack. Full Nitro nodes start with a database that contains the information from the \"classic\" era.\nHowever, a Nitro node can't query archive information contained in \"classic\" blocks right away. To do that, you also need to run a classic node (instructions in our guide about running a classic node) and set the parameter —node.rpc.classic-redirect=your-classic-node-RPC.\nPlease note that this information only applies to Arbitrum One nodes. Arbitrum Nova and Sepolia nodes started with a Nitro stack, so they don't have \"classic\" data.\nHow can I verify that my node is syncing at a desirable speed?\nSyncing speed can vary depending on multiple factors. You can find the minimum hardware requirements to run your node on this page. You should also verify your network and disk speeds and ensure that the L1 node is running correctly.\nHow can I verify that my node is fully synced?\nYou can make an eth_syncing RPC call to your node. Once a Nitro node is fully synced, eth_syncing returns the value false (just like a normal Geth node).\nWhen a Nitro node is still syncing, eth_syncing returns a map of values to help understand why the node is not syncing. Nitro execution and bottlenecks differ from those of a normal Geth node, so the eth_syncing output is unique to Nitro.\nYou can find information to understand the output of eth_syncing in the RPC methods page.\nIs there an alternative to Docker when running a node?\nWe recommend running Nitro nodes using Docker, following the guide provided in our documentation. However, you can compile the code directly by following the steps described in this guide.\nWhat are the minimum hardware requirements to run a full node?\nThe minimum hardware requirements are available in this section.\nHow can I migrate the date of one synced node to a new one?\nFrom a fully synced node, you can copy its database (the .arbitrum directory in a default setup) to the same database folder of the new node, and it will start from the same state.\nKeep in mind that this must be done after a clean shutdown, while the node is not running.\nWhen querying Classic transactions from a Nitro node, I sometimes get incorrect data, like the zero address as the sender. Why is that?\nSome old Nitro genesis database snapshots didn't properly set the retry sender for Classic blocks and contained this error. If you need to access that information, you can either resync your Nitro node with one of the current snapshots or run a Classic node alongside your Nitro node and configure a redirection for requests to Classic blocks. Please note that this only happens on Arbitrum One.How is this guide?TroubleshootingTroubleshoot common issues when running an Arbitrum node, with configuration-specific guidance and a report generator for getting help.","tokens":1413,"squid":"spider-01","role":"Chain Spider","at":1791342298712,"hash":"90e3e4a353a3f0aeb8b6a24fbc3d78a12dcd2d63"}
{"url":"https://akash.network/blog/billing-and-usage-analytics-in-akash-console-and-api","domain":"akash.network","title":"Billing & Usage Analytics in Akash Console & API","text":"TL;DR: Akash Console now shows credit card users full billing transparency: credit purchase history with downloadable receipts, usage charts by week/month/year, and cumulative spend tracking — similar to AWS billing pages, accessible under Account Settings.\n\nAs more Akash users pay for compute with credit cards, they expect the same billing transparency they get from traditional cloud providers and SaaS services. AEP‑68 noted that while crypto wallet users can see token transfers on a block explorer, credit‑card users have no such tracking and often ask for billing information. Users also want to see how much of their funds are being used and for what, similar to AWS billing pages.\nThe new Billing & Usage feature introduces a new page in Account Settings that surfaces this information.\n\nThe two tabs display the following information:\n\nCredit Purchase History: A table lists all transactions where credits were added to the user’s balance. Each entry shows the date, amount, payment method, status and provides links to download a copy of the receipt. There is also an option to export all transactions as a csv file for easy record keeping or ingesting into internal systems. A date range picker allows users to filter to a specific time range.\n\nUsage Charts: In the “Usage” tab users can see a summary of their total spend and total deployments and charts showing usage over time as well as cumulative spending over time. Here too, users can switch between weekly, monthly or annual views or select a custom date range.\n\nTogether, these elements give credit‑card users the insight they need to manage their budgets. Users can download receipts, see when credits were added and understand how their compute spend evolves over time.\nFor technical support or any questions about the Billing & Usage, please head over to the Akash Discord server, where technical members of the Akash community are available around the clock and ready to assist.\nFrequently Asked Questions\nWhere do I find billing information in Akash Console?\nUnder Account Settings → Billing & Usage — shows two tabs: Credit Purchase History and Usage Charts with filters for weekly, monthly, annual, or custom date ranges.\nCan I download receipts for my Akash purchases?\nYes — the Credit Purchase History tab includes links to download individual receipts, plus a CSV export option for all transactions for accounting and record-keeping.\nWhat does the Usage Charts tab show?\nTotal spend summary, total deployments, spend-over-time charts, and cumulative spending over time — with weekly, monthly, annual, or custom date range views.\nIs billing tracking available for crypto wallet users?\nCrypto wallet users can track token transfers on a block explorer like Mintscan. The new Billing & Usage dashboard is specifically for credit card users who don’t have that visibility.\nWhat is AEP-68?\nThe Akash Enhancement Proposal that identified the need for billing transparency for credit card users — noting that while crypto users see token transfers on-chain, credit card users had no equivalent visibility.\nCan I export my usage data?\nYes — the Credit Purchase History tab includes a CSV export for all transactions, making it easy to ingest spend data into internal accounting or analytics systems.\nWhere can I get support for billing questions?\nJoin the Akash Discord at discord.akash.network — technical community members are available 24/7 to assist with billing, usage, and account management questions. \nFast, affordable inference for open models\n\nRun Llama, Qwen, GLM and more on Akash's open compute marketplace.\nDrop-in API compatibility means you can\n switch in minutes.\n\nTry AkashML\n(opens in a new tab) \nnote\n\ntip\n\nCaution\n\nDanger","tokens":929,"squid":"spider-03","role":"Compute Spider","at":1791342298772,"hash":"1b63f4c67546001c0912eabeb76810df890f48f5"}
{"url":"https://developer.arbitrum.io/run-a-node/l1-ethereum-beacon-chain-rpc-providers","domain":"developer.arbitrum.io","title":"Ethereum beacon chain RPC providers","text":"Ethereum beacon chain RPC providersA reference list of Ethereum beacon chain RPC providers that Arbitrum node operators can use to access blob data after the Dencun upgrade.Request an updateFollowing Ethereum's Dencun upgrade in March 2024, like Arbitrum will be able to rollup and post of transaction data on Ethereum in the form of a new transaction format called a . 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., , , and L3 ), 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 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 with any of the above providers.How is this guide?Run a local dev nodeThis page provides instructions for setting up and running a local Nitro dev node for contract testing and development.Data AvailabilityLearn how data availability works in arbitrum","tokens":524,"squid":"spider-01","role":"Chain Spider","at":1791342309515,"hash":"da7a5871eba9511d4c3da349061f1fee942ab8f1"}
{"url":"https://akash.network/roadmap/aep-68/","domain":"akash.network","title":"Console - Billing & Usage","text":"Akash Network Roadmap Roadmap 2025 Q3 aep-68 Console - Billing & Usage Final Motivation\nAs number of credit card users in Akash Console grows, a common request we here is being able to view usage and billing info\nBackground\nAkash Console support two payment options - Crypto Wallet based and Credit Card based. For Crypto Wallets it is easy enough for the users to see when they used tokens for deployments with a blockchain scan tool like mintscan. For credit card users there is no such tracking avaialble. We do get the invoice data from Stripe that we should be able to pass back to the user.\nSeparately, users sometimes also may want to know how much of their funds are being used and for what - similar to the AWS (or othre cloud) billing pages where there is separation by services. In our case since we do not have managed services, showing some information about spend by provider or GPU models might be nice to have.\nProposed Solution\nA new page and submenu in the user Account Settings page called “Billing & Usage” that shows users information about billing and usage related things. The below elements are placeholder to be refined in eng and design conversations.\n\nTabular Data for\n\nStripe Transactions\n\nDate\nTransaction Type (purchase/ refund)\nPayment Method\nAmount\nStatus (suceeded or failed)\nLink to download receipt\n\nDaily Usage\n\nDate\nResources Leased\nAmount Spent\n\nCharts that show:\n\nCumulative Credit purchase over timne\nAccount balance over time\nSpend (in terms of compute costs for deployment) over time\n\nTenative Design Mocks\nThese are just placeholders for now to provide general direction and the final version will be different (see resolution link or console.akash.network for final UI/ UX)\n\n Completion date: 7/31/2025 Created: 5/20/2025 Last Updated: 7/31/2025 Category: Interface Status: Final Authors: Anil Murty Resolution: \nLink\n\nView next aep\n Console API using JWTCompletion Date: 8/29/2025Accessing the API requires creating a certificate and working with mTLS. JWT eliminates the need for these.","tokens":508,"squid":"spider-03","role":"Compute Spider","at":1791342309607,"hash":"77916d12fed7f66d4fdd8328126ce2cd41e4359f"}
{"url":"https://www.paradigm.xyz/writing/quantum-markets","domain":"paradigm.xyz","title":"Quantum Markets","text":"Quantum Markets \n\n Your browser does not support the video tag.\n\n Animation by Dave Whyte\n BackgroundToday's decision markets can only evaluate a single proposal for each decision. As a result, every new proposal for a decision requires fresh liquidity from traders, leading to a significant capital efficiency problem.For example, take the following decision: “Which EIP should Ethereum implement next?”There are 700+ active EIPs that could be considered. Let's say you're a trader with $1M of capital and you have an opinion on all of these proposals. In the standard approach for decision markets, you would need to spread your $1M across all 700+ proposals. This would give you on average less than $1,500 per market to trade.With quantum markets, you would be able to trade the full amount on each proposal.Core MechanismLet's step through an example of a quantum market that has the goal of finding the best EIP to implement to increase the price of ETH. To those who have heard of–or used–MetaDAO this may seem familiar. In both systems, we take a DAO token (ETH in this case) and allow it to be traded in parallel across different worlds.However, in the quantum market case we start with a question (”Which EIP should ETH implement next?”) and allow anyone to permissionlessly create (tradable) proposals. With MetaDAO today, we would need to bootstrap new liquidity for each proposal we consider for this decision.In a quantum market, traders would be able to deposit funds into the system and get an equivalent amount of tradable credits on every current and future proposal for the decision. As they trade these markets, a predicted ETH price would emerge for each proposal. As time goes on, the market for EIP 2 predicts much higher growth in value for ETH than EIP 1 or 3. When the settlement time is reached, the quantum market triggers a \"wave function collapse\" by observing the predicted values and selecting the proposal that predicts the highest ETH price.Since traders were issued their full deposit amount in each market, if a user did not trade in the passing proposal they retain their principal and their PnL is identical to if they had simply held ETH and USDC outside of QM.Step-by-Step BreakdownBelow we break down a much more granular walkthrough of the EIP example.Quantum market created with decision criteria:Select the EIP that maximizes ETH priceThe following three proposal markets are created by market participants:EIP 1EIP 2EIP 3These markets get traded on until they predict an ETH price of $3200, $3000, and $100 respectively. Alice opens the markets and notices that the ETH-EIP-2 and ETH-EIP-3 are both underpriced.Status Quo Path:Alice, starting with $1M (500k USDC, $500k in ETH) in the bank, starts depositing funds into the EIP-2 market until the price is $3500. However, the market is liquid enough for these trades to consume all of Alice’s $1M.Alice does not have enough funds to correct the inefficiency in the proposal 3 market.Quantum Market Path:Alice deposits $1M and gets $1M in trading credits in both proposal markets that she’s interested in trading.She uses her $1M in the EIP 2 market to bring it to $3500, and her $1M in the EIP 3 market to bring it to $3000 (or as close as her $1M will get her).She leaves the EIP 1 untouched, as she believes it is fairly priced.End State:EIP 2 passes because it predicts a higher ETH price (3500>3500 >3200).Proposal markets 1 & 3 are fully aborted/reverted since they didn’t pass. Any trade that happened in those proposal markets is essentially a no-op.The proposal market for EIP 2 settles an hour after it goes live. The price is $3500.Alice makes money on this trade since she bought up from $3000 to $3500.Example 2: Token LaunchpadToday's token launchpads lack any form of accountability. This is especially true in memecoin focused ones that have a notion of \"graduating\" tokens once they reach a specific market cap. The problem with this approach is that it incentivizes blind sniping, which ultimately muddies the waters.A second problem is that the space of possible tokens to launch is too large. When you have 100,000+ tokens launching per day, it becomes prohibitively capital-expensive to trade on all of them.With quantum markets a launchpad can set some cadence with which token launches happen (e.g. one per hour) and let anyone propose an arbitrary number of tokens for each launch. For each new proposed token, all existing traders can trade on its expected outcome (i.e. “Will this token reach $50m market cap within a week?”) without putting up any new capital.It's difficult to overstate how scalable such a system can get. A QM-based token launchpad can plausibly evaluate millions of tokens for each launch without adding any additional capital overhead to traders. If launch throughput becomes an issue, these markets can be run in parallel batches to accommodate more actual launches.Proposal Market FlexibilityOne important property of quantum markets is that the underlying virtual proposal markets can have any construction as long as markets are directly comparable to each other on some predicted metric. They can be binary or continuous prediction markets, AMM-based, spot, or even distribution market-based.For example, the EIP example above could have been based on continuous prediction markets for the impressions of a potential tweet. The one that would ultimately pass in this case would be the tweet that has the highest percentage likelihood of YES.Static vs. Dynamic Decision MarketsStatus quo decision markets are static by construction. It is not possible for anyone to contribute a proposal to an ongoing decision market – the only option is to create an entirely new one.Quantum markets, on the other hand, can be dynamic. Anyone can propose an improved idea into the market while it is active. This is critical for two reasons:It allows for increased dynamic participation by humansIt allows for unbounded participation by AI agentsThe second point is discussed in greater detail in a later section, but it is an incredibly important unlock. AI agents can be much more generative than current decision markets can accommodate, and quantum markets unlocks them to fully express their preferences on-chain.Since this is a more involved discussion, it is unpacked at the end of this post to not distract from the core mechanism.Use CasesThe reality is that most important decisions require (or would at least benefit from) an efficient way to evaluate multiple proposals. Many candidate options need to be considered. These use cases are sidelined from using decision markets due to classical markets providing insufficient scale: it is simply too expensive to require fresh liquidity on the long tail of proposals.Let’s take a small sampling of use cases to demonstrate just how vast the design space unlocked by quantum markets might be:What should my agent tweet? (Goal: highest expected like/follower count)What trade should my on-chain vault make? (Goal: highest expected vault token price (proxy for AUM))Which EIP should Ethereum roll out next? (Goal: highest long-run token price)Each of these decisions has to take into consideration a large set of options. With the status quo approach, these decisions are confined to only considering a tiny sliver of the option space.AI Agents and Quantum MarketsAI agents are becoming increasingly capable of making human-level decisions. As a result, there is growing interest in offloading important decisions to agentic AI systems.Today, most attempts at doing the above have involved hard-coding a specific AI agent as the decision-maker. This model has a number of issues:Counterparty risk due to centralization from whoever hosts the agentAgent is prone to mistakes or manipulation that humans wouldn't makeNew frontier agents need to manually be switched to (fork or redeployment)Decision markets are a natural substrate to resolve the issues above:The best agents make more of the decisions over time as they accumulate capitalProposals by humans can still be considered as a guardrail to AI-proposed onesFrontier agents can automatically participate, even before they are publicly known about or open sourcedThe issue with decision markets in this context is that they are impractical. Even frontier agents can create proposals at an inference cost that is rapidly approaching $0.As a result, participation in on-chain decision making by AI agents is constrained primarily by the capital efficiency of the decision market mechanism that they are interacting with.Since quantum markets have no marginal cost of liquidity for each new proposal, AI agents can run on them at the cost of inference. For example, a given decision might receive 100,000 proposals from various AI agents, and have each proposal traded on by the handful of frontier agents that can predict proposal performance.CodeWe’ve included starter repos for quantum markets in both Solidity (more in-depth) and Solana/SVM. Our Solidity implementation takes advantage of Uniswap V4 hooks to efficiently handle core functionality.Disclaimer: these repos are reference implementations and should not be used in a production environment.ConclusionQuantum markets demonstrate that the design space of decision markets is still vastly under-explored. If you're interested in working on this mechanism or have related ideas, please reach out on Twitter/X!AcknowledgementsDan Robinson, Dave White, Siong Ong, Zaki Manian, Proph3t, Dev Ojha, Tina Zhen, Vitalik Buterin, Alana Palmedo","tokens":2384,"squid":"spider-04","role":"Research Spider","at":1791342313111,"hash":"7560f22f6471d5ab11c23ecce18c96bdb9dc52bf"}
{"url":"https://developer.arbitrum.io/run-a-node/troubleshooting","domain":"developer.arbitrum.io","title":"Troubleshooting: Run a node","text":"Troubleshooting: Run a nodeTroubleshoot common issues when running an Arbitrum node, with configuration-specific guidance and a report generator for getting help.Request an updateThe guidance displayed on this page will change based on your selected configuration:\nOperating system:Linux, MacOS, Arm64WindowsNetwork:Arbitrum One (Nitro)Arbitrum One (Classic)Arbitrum NovaArbitrum SepoliaLocalhostNode type:Full nodeArchive nodeValidator node\nThank you!At the end of this troubleshooting guide, you'll find a Generate troubleshooting report button. Clicking this button will generate a report that includes your selected configuration. You can include this report when asking for help.Using this page to generate a troubleshooting report is helpful because it gathers the information that we need in order to resolve your issue.\nStep 1: Try the troubleshooting checklist\nIf you're running into unexpected outputs or errors, the following checklist may help you independently resolve your issue.\n1. Select an Operating system, Network, and Node type aboveThe guidance displayed on this page will change based on your selected configuration.2. Review the docsHow to run a full node (Nitro) may address your issue.3. Review the FAQAnswers to frequently asked questions can be found in Frequently asked questions: Run a node.\nStep 2: Look for your scenario\nCommon troubleshooting scenarios and solutions are detailed below.\nYou can check logs by different log types: info, warn, and error.\nLogs type:ScenarioSolutionYou see Unindex transactions.This is expected behavior. You'll see this when your node removes old txlookup indices. This is emitted from the base Geth node, so you'd see the same output from a mainnet Geth node.You see Head state missing, repairing.This is usually because your node shuts down ungracefully. In most cases, it will recover in a few minutes, but if it not, you may have to re-sync your node. Remember to shut down your node gracefully with the following command: docker stop —time=1800 $(docker ps -aq).Your local machine is running out of memoryNitro (and Geth) can consume a lot of memory depending on the request load. It's possible that your machine may run out of memory when receiving tons of requests.Your Arbitrum node can’t connect to your node on localhost:8545This is often because of a Docker port configuration issue. See https://stackoverflow.com/questions/43884981/unable-to-connect-localhost-in-docker.You specified your snapshot file path via the --init.url parameter, but the snapshot file isn't found.This is usually because the snapshot file isn't mounted to your Docker container. Mount it and change the file path to your Docker container’s mount point.You get 403 errors from the feed URL.This often happens when Cloudflare attempts to block botnets and other malicious actors but accidentally blocks node runners.You see latest assertion not yet in our nodeThis usually because your node hasn’t synced to the latest state, it’s a normal behavior.You see \"Post \"xxx_url\": context deadline exceeded\"Please check your parent chain endpoint because there is something going wrong on that endpoint; you can check it.You see Resuming state snapshot generationThis is a normal behavior while the node is catching up to the tip of the chain; once a node has been fully synced, \"Resuming state snapshot generation\" shouldn't be logged unless it falls behind again.You see track-block-metadata-from is set but blockMetadata fetcher is not enabled.You started the node with --node.transaction-streamer.track-block-metadata-from set to a non-zero block but did not enable the blockMetadata fetcher. The node will still run, but blockMetadata won't be backfilled. Either remove the flag, or enable the fetcher with --node.block-metadata-fetcher.enable—and when enabling the fetcher you'll typically also need to set --node.block-metadata-fetcher.source.url to point at a node that serves block metadata.ScenarioSolutionYou see error reading inbox err=\"sequencer batches out of order; after batch A got batch B”This is because you get two discontinuous batches; this might be because of your parent chain endpoint issues. You can change to another endpoint and set nitro --init.reorg-to-batch AYou see error reading inbox err=\"failed to get previous message for pos x: leveldb: not found”This is because your node db crashed and lost some messages. You can try to set --init.reorg-to-message-batch x-1You see Failed to load snapshot err=\"head doesn't match snapshot: have a, want b”This is usually because an ungraceful shutdown caused a corrupted database; try restarting the node without a flag, and after your node goes back to normal, then graceful shut it down and restart to prune it.You see failed to get blobs: expected at least six blobs for slot [slot_number] but only got 0This often happens when you connect to a beacon chain endpoint while the blob you are querying is expired. To resolve this error, connect to a beacon endpoint that supports historical blob data (see List of Ethereum beacon chain RPC providers\n).You see P2P server will be useless, neither dialing nor listeningArbitrum Nitro doesn’t need P2P mode, so you can ignore this log.You see Getting file info dir=<path>/machines error=\"stat <path>/machines: no such file or directory\".Nitro is checking one of the expected locations for WASM machine artifacts, but that particular machines/ directory does not exist. This warning can be harmless if Nitro finds the required machine artifacts in another location. If it is followed by validation or WASM module-root errors, make sure you're running a supported/current Nitro image for your chain, and that the image or mounted machines/ directory contains artifacts matching the chain's onchain . If you're using an older Docker image, upgrade to a newer Nitro release; if you're building or running from source, mount or download the matching machine artifacts for that Nitro version/module root.You see broadcaster queue jumped positions queuedMessages=N expectedNextIdx=M.The feed delivered messages out of the expected order; the node skipped ahead in its broadcast queue. This typically self-heals as later messages arrive. If it persists, check your feed URL connectivity or try a fallback feed via --node.feed.input.url.You see Compression was not negotiated when connecting to feed server, non-critical: node will continue without compression.The feed server didn't agree to compression during the WebSocket handshake. This is informational—the node continues without compression and your sync is unaffected. You can ignore this warning.You see readData returned EOF url=wss://...feed... opcode=0.The feed server closed the WebSocket connection. The broadcast client will automatically reconnect; no operator action is needed unless EOF repeats continuously. Persistent EOFs suggest a network/firewall issue or that all configured feeds are unreachable.You see error reading inbox err=\"previous delayed accumulator mismatch for message N\".The accumulator your node computed doesn't match the onchain one at message N—typically caused by a parent-chain endpoint serving inconsistent data or by a . Switch to a different parent-chain RPC and restart; if it persists, re-sync from a recent snapshot.You see error reading inbox err=\"unexpected delayed sequence number N, expected M\".The delayed inbox produced a sequence number that is not the next expected one—usually a parent-chain RPC inconsistency or a reorg on the parent chain. Switch to a different parent-chain RPC; if the gap persists, re-sync the node.You see Trie prefetcher failed opening storage trie root=... err=\"missing trie node ...\".Your local state database is inconsistent—typically caused by an ungraceful shutdown or by enabling --init.recreate-missing-state-from on a non-archive node. Restart without pruning; if the node still can't recover, re-sync from a recent official snapshot.You see error reading inbox err=\"...pebble: not found\" (same root cause as the leveldb: not found case above; different database backend).Same root cause as the leveldb: not found case above: your local DB is missing a message it expected to have. Use --init.reorg-to-message-batch x-1 to roll back to before the missing index, or re-sync from a snapshot.ScenarioSolutionYou see no contract code at given addressYour parent chain node might not sync to the latest state, please wait after it finishes syncing.You see staker: error checking latest staked err=\"latest assertion of x: globalstate not in chain: count a hash b expected c, sendroot d expected f\"Once it catches up, the node will check the state against the latest confirmed assertion bonded onchain; if it doesn’t match, it will log this error. Usually, this is because of db corruption, so you might need to re-sync the blockchain; using a snapshot might help: https://snapshot-explorer.arbitrum.io/You see disabling L1 bound as batch posting message is close to the maximum delay blockNumber\nor batch is within reorg resistance margin from layer 1 minimum block or timestamp boundsIt indicates that there has been an issue with posting on the network. This could occur if your didn't post a batch for an extended period. Common reasons include the node being shut down inadvertently or the batch poster running out of funds, leading to no new blocks being produced or posted by the batch poster. \nTo resolve this, If re-org doesn’t matter, you can just start the batch poster with --node.batch-poster.reorg-resistance-margin=0 and node.batch-poster.l1-block-bound to ignore, If it does, you'd want to modify the time bounds on the sequencer inbox to allow the sequencer to post a batch containing the transactions with the old timestampYou see on-chain WASM module root did not match with any of the allowed WASM module rootsUsually, because you are running on an old node version, try to upgrade your node. Also, you modify your node’s code; please refer to the continue set.You see error acting as stakerIn most cases, this error is caused by your parent chain endpoint's rate limit or other issues, you can check your parent chain endpoint. If the error still persists, please ask in our discord node-running channel.You see wrong msgIdx got X expected Y.The transaction streamer received a message whose index doesn't match the next expected one—your node's local DB is behind or ahead of the . Restart the node; if the gap persists, re-sync from a snapshot or use --init.reorg-to-message-batch to roll back to a known-good index.You see error reading inbox err=\"...header not found\" or header for hash not found.The parent-chain RPC returned a block header your node expected to exist—usually your parent-chain endpoint hasn't synced to the height nitro asked for, or the endpoint serves a different chain history. Wait for the parent-chain node to finish syncing, or switch to a fully-synced parent-chain RPC.You see accumulator not found or delayed accumulator not found for index N.Nitro tried to read an inbox accumulator or sequencer-batch metadata entry that is not yet present in the local consensus database. This can happen transiently while the inbox reader or message extractor is still catching up, and batch-posting paths intentionally treat this as an ephemeral error for the first few minutes. If the error keeps repeating, make sure the node has caught up, your parent-chain RPC can serve the relevant SequencerInbox / delayed inbox logs, and the local database or snapshot is not missing historical inbox data. Try restarting with a healthy parent-chain RPC; if the same index remains missing, re-sync from a recent snapshot.You see error initializing database err=\"found N unexpected files in database directory, including: ...\".The data directory you pointed nitro at already contains files that don't belong to a fresh DB. Either empty the directory before init, or point --persistent.chain at a fresh path and extract your snapshot there.You see error validating feed signature error=\"signature not verified: signer ...\" sequence number=N.A feed message was signed by an address that is not in your allowed signer list. Check that --node.feed.input.verify.allowed-addresses includes the expected sequencer feed signer for your chain; for Arbitrum One/Sepolia this should be the official feed signer published in the docs.You see no connected feed or no connected feed on startup.The broadcast client failed to connect to any feed URL you configured. Check network/firewall rules for outbound WebSocket connections, verify the feed URLs in --node.feed.input.url are reachable, and confirm you can curl them from the node host.\nStep 3: Generate a troubleshooting report\n\nComplete the above troubleshooting checklist.\nFill in the below form.\nClick Generate troubleshooting report.\nCopy and paste the generated report text when asking for support on Discord or any other support channel.\n\nNode startup command (make sure to remove any sensitive information like, i.e., private keys)Unexpected outputTip: Paste the ~100 lines of output before and including the unexpected output you're asking about. You can use the following command to get the logs: docker logs --tail 100 YOUR_CONTAINER_IDComplete the checklist above before generating...How is this guide?Docker and CLI binariesNitro Docker image variants, available CLI binaries, entrypoint usage, and Docker Compose examplesFAQList of questions and answers frequently asked by node runners","tokens":3363,"squid":"spider-01","role":"Chain Spider","at":1791342319412,"hash":"eae59ea424b029370d1eb65cf981cff670fb2dd6"}
{"url":"https://www.paradigm.xyz/writing/orbital","domain":"paradigm.xyz","title":"Orbital","text":"Orbital \n\n Your browser does not support the video tag.\n\n Animation by Dave Whyte\n IntroductionThe future holds a million stablecoins. Today's infrastructure isn't ready.This paper introduces Orbital, an automated market maker for pools of 2, 3, or 10,000 stablecoins.Orbital unlocks capital efficiency by bringing concentrated liquidity to higher dimensions.Overview\n\n Your browser does not support the video tag.\n This is a graph of the reserves of an automated market maker (AMM) between USDC and USDT. When traders add USDT, they get USDC in return. In the middle, where reserves are equal, the coins have the same price. At the edges, one is worthless compared to the other.\n\n Your browser does not support the video tag.\n Uniswap V3 pioneered the concept of concentrated liquidity. It creates and consolidates mini-AMMs, called ticks, that support more trading with less capital by restricting themselves to only a specified price range. Uniswap v3 allows liquidity providers to create positions between any two tick boundaries, and efficiently aggregates their liquidity so that traders can interact with it as if it were a single pool. However, it only supports pools between two assets.\n\nCurve created an invariant-based AMM that allows trading of N stablecoins in a single pool. It focuses liquidity around the price of 1. However, Curve uses a uniform strategy for each pool, meaning all liquidity providers in the same pool have the same liquidity profile.\n\n Your browser does not support the video tag.\n Orbital extends customizable concentrated liquidity to pools of three or more stables by drawing tick boundaries as orbits around the $1 equal price point.Unlike in 2D concentrated liquidity, even if one stablecoin depegs to 0, an Orbital tick can still trade the others at fair prices.\n\n Your browser does not support the video tag.\n Smaller ticks closer to the equal $1 price point don't need to hold capital in reserve to give out in case one of the coins depegs.This lets LPs focus their resources where normal trading actually happens, unlocking significant capital efficiency gains.\n\n Your browser does not support the video tag.\n The full Orbital AMM combines ticks of different sizes so LPs can customize their exposures.Some might choose to focus narrowly around the $1 point for maximum efficiency, while others might provide wider coverage to earn fees during times of volatility.Under the hood, Orbital ticks are nn-dimensional spherical caps.Thanks to symmetry, we can orbit some around the others to obtain a single toroid (donut-like) shape.This lets us compute trades efficiently onchain regardless of the number of different coins in the pool.IntuitionThe math below gets pretty dense, but it's just trying to formalize a relatively simple visual intuition.In the 3D case, depicted above, the base Orbital AMM is a sphere. We only show 1/8th of the sphere in the animation because it's the only relevant part assuming prices stay non-negative.The Orbital tick in the diagram refers to the part of the sphere inside the red circle. The red circle itself forms the boundary of the tick. Note that, unlike in Uniswap V3, Orbital ticks actually overlap, so that larger ones fully contain smaller ones.We can see from the animation that a Orbital tick can be in one of two states. If prices for all the stablecoins are sufficiently close to the equal $1 price point, then the reserves will be somewhere on the interior tick. But once prices have diverged enough, the tick's reserves will become pinned to its boundary.Now, imagine we have hundreds or thousands of ticks. Each one of them will either be an \"interior tick\" or a \"boundary tick.\"Locally, all interior ticks behave like spheres. Since they are geometrically similar, we can consolidate them all and treat them like a single sphere.Similarly, all boundary ticks behave locally like circles (in general, in nn dimensions, they behave like n−1n-1-dimensional spheres. Since they are geometrically similar, we can again consolidate them all and treat them like a single circle.Logically speaking, we are now dealing with one spherical AMM and one circular AMM. By rotating the sphere around the circle, we obtain a single torus, or donut shape.The equation of this torus is simple enough that we can compute trades across its surface efficiently onchain. To compute larger trades, we update the equation every time a tick changes from boundary to interior or vice versa.Luckily, all of this stays true in high-dimensional space, and the rest of the paper goes into the details of how that works.MechanismThe Sphere AMMFormulaOrbital is built on top of the Sphere AMM∣∣r⃗−x⃗∣∣2=∑i=1n(r−xi)2=r2||\\vec{r}-\\vec{x}||^2=\\sum_{i=1}^n (r-x_i)^2 = r^2where xix_i is AMM's reserve of asset ii.To see that the minimum reserve of any asset is $0$, note that the sphere is centered at r⃗=(r,r,…,r)\\vec{r} = (r, r, \\dots, r), and the farthest a point on the sphere can be from the center in any dimension is the radius rr.As long as asset prices are positive, no-arbitrage implies we should never have reserves xi>rx_i > r for any ii, since if xi=r+dx_i=r+d for some d>0d>0, then (r−xi)2=d2=(r−(r−d))2=(r−(xi−2d))2(r-x_i)^2 = d^2 = (r-(r-d))^2 = (r-(x_i-2d))^2and some trader could remove 2d2d of asset ii for free without affecting the AMM's constant function constraint, and by assumption it would have positive value. Therefore we won't add an explicit contraint for xi≤rx_i \\leq r to the AMM, but can assume that xi≤rx_i \\leq r for all ii in normal circumstances.Token Prices on the SphereLet's say a trader wants to give the AMM some token XiX_i and take out some token XjX_j while staying on the surface F(x⃗)=∣∣r⃗−x⃗∣∣2=r2F(\\vec{x})=||\\vec{r}-\\vec{x}||^2=r^2In this case, we must haveδFδxiδxi+δFδxjδxj=0\\frac{\\delta F}{\\delta x_i}\\delta x_i + \\frac{\\delta F}{\\delta x_j} \\delta x_j = 0so, abusing notation a bit, we can express the instantaneous price of one unit of xjx_j asδxiδxj=−δFδxj/δFδxi=r−xjr−xi\\frac{\\delta x_i}{\\delta x_j} = -\\frac{\\delta F}{\\delta x_j}/\\frac{\\delta F}{\\delta x_i} = \\frac{r-x_j}{r-x_i}Intuitively we can verify that if the AMM has high reserves of XjX_j and low reserves of XiX_i, this fraction will be small, meaning you don't get much XiX_i per unit of XjX_j, and vice versa.The Equal Price PointThe most important point on the surface of our AMM is the point where all reserves are equal, so that, by symmetry, all prices are equal.This should be the the normal state for stablecoins, because under normal conditions they should all worth the value they are pegged to, e.g. $1.Let's denote this pointq⃗=(q,q,…,q)\\vec{q}=(q,q,\\ldots,q)By our sphere constraint, we haver2=∥r⃗−q⃗∥2=∑i=1n(r−q)2=n(r−q)2r^2 = \\|\\vec{r} - \\vec{q}\\|^2 = \\sum_{i=1}^n (r - q)^2 = n(r - q)^2So then(r−q)2=r2n⇒r−q=rn(r-q)^2=\\frac{r^2}{n}\\Rightarrow r - q = \\frac{r}{\\sqrt{n}}soq=r(1−1n)q = r\\left(1 - \\sqrt{\\frac{1}{n}}\\right)and we haveq⃗=r(1−1n)(1,1,…,1)\\vec{q} = r\\left(1 - \\sqrt{\\frac{1}{n}}\\right)(1, 1, \\dots, 1)Since they're all multiples of (1,1,…,1)(1,1,\\dots,1), there's a line from the origin, through the equal price point, and to the center of the AMM. We can represent its direction with the unit vectorv⃗=1n(1,1,…,1)\\vec{v} = \\frac{1}{\\sqrt{n}} (1, 1, \\dots, 1)In terms of trading, we can think of v⃗\\vec{v} as a portfolio of 1n\\frac{1}{\\sqrt{n}} of each of the coins in the AMM.Polar Reserve DecompositionThis section introduces a concept and notation we'll be using to work with ticks through the rest of the paper.Given any valid reserve state x⃗\\vec{x} on the surface of the AMM, linear algebra tells us we can decompose it into a vector parallel to v⃗\\vec{v} and a vector w⃗\\vec{w} orthogonal to v⃗\\vec{v}, the vector from the origin to the equal price point.In other words, for any reserve state x⃗\\vec{x}, we havex⃗=αv⃗+w⃗wherev⃗⊥w⃗\\vec{x} = \\alpha\\vec{v} + \\vec{w} \\quad \\text{where} \\quad \\vec{v} \\perp \\vec{w}Note that because v⃗\\vec{v} is a unit vector, we can calculate α\\alpha directly as x⃗⋅v⃗\\vec{x} \\cdot \\vec{v}, which mechanically equals 1n∑i=1nxi\\frac{1}{\\sqrt{n}}\\sum_{i=1}^n x_i — 1n\\frac{1}{\\sqrt{n}} times the sum of all reserves in x⃗\\vec{x}.Viewed through the lens of this decomposition, our AMM constraint becomesr2=∥x⃗−r∥2=∥(αv⃗+w⃗)−r⋅1⃗∥2=∥(αv⃗+w⃗)−rn⋅v⃗∥2=∥(α−rn)v⃗+w⃗∥2r^2 = \\|\\vec{x} - r\\|^2 = \\|(\\alpha \\vec{v} + \\vec{w}) - r \\cdot \\vec{1}\\|^2 \n= \\|(\\alpha \\vec{v} + \\vec{w}) - r \\sqrt{n} \\cdot \\vec{v}\\|^2 \n= \\|(\\alpha - r \\sqrt{n}) \\vec{v} + \\vec{w}\\|^2Since v⃗⊥w⃗\\vec{v} \\perp \\vec{w} by definition, we can use the Pythagorean theorem to simplify this tor2=(α−rn)2+∥w⃗∥2r^2 = (\\alpha - r\\sqrt{n})^2 + \\|\\vec{w}\\|^2or, rearranging,∥w⃗∥2=r2−(α−rn)2\\|\\vec{w}\\|^2 = r^2 - (\\alpha - r\\sqrt{n})^2From this, we can see that if we hold the component of reserves parallel to v⃗\\vec{v} constant, our AMM acts as a lower-dimensional spherical AMM in the subspace orthogonal to v⃗\\vec{v} with radiuss=r2−(α−rn)2s = \\sqrt{r^2 - (\\alpha - r\\sqrt{n})^2}Tick DefinitionNotesIn the interest of simplicity, for the rest of the paper we will act as if each tick has only one liquidity provider. Of course, in practice, we would allow multiple LPs to pool their liquidity into the same tick, just like in Uniswap V3.As a reminder, ticks in Orbital are nested. Each is centered at the equal price point, and larger ticks fully overlap with smaller ticks. This is in contrast to Uniswap V3, where ticks are fully disjoint.Geometric IntuitionWe can think of a tick geometrically as all the points on the sphere's surface that are within some fixed geodesic distance from the equal-price point.In the 3D case visualized above, it's possible to intuit that we can construct the boundary of such a tick by slicing the sphere with a plane orthogonal to the vector v⃗\\vec{v} from the equal price point to the sphere's center.We formalize this construction for higher dimensions below.Tick Boundary GeometryAny plane normal to v⃗=(1n,1n,…,1n)∈Rn\\vec{v} = \\left( \\frac{1}{\\sqrt{n}}, \\frac{1}{\\sqrt{n}}, \\dots, \\frac{1}{\\sqrt{n}} \\right) \\in \\mathbb{R}^n has the formx⃗⋅v⃗=k\\vec{x} \\cdot \\vec{v} = kThis is another way of saying that the plane consists precisely of all points whose projection on v⃗\\vec{v} is kk -- i.e. the points of the form kv⃗+w⃗k\\vec{v}+\\vec{w} for some w⃗⊥v⃗\\vec{w}\\perp\\vec{v}, which you get by starting from kv⃗k\\vec{v} and adding some vector orthogonal to v⃗\\vec{v}.From the polar reserve decomposition section above, we can see that when reserves lie on this boundary, since the component of reserves parallel to v⃗\\vec{v} is constant at kv⃗k\\vec{v}, the tick AMM functions as a spherical AMM in the n−1n-1-dimensional subspace orthogonal to v⃗\\vec{v} with radius s=r2−(k−rn)2s = \\sqrt{r^2 - (k - r\\sqrt{n})^2} and center (k−rn)v⃗(k - r\\sqrt{n})\\vec{v}.By symmetry, every point on this boundary will have an equal geodesic distance from the equal price point.Tick Size BoundsThis section is relatively technical and defines the sizes of the smallest and largest ticks that make sense.The Minimal TickThe minimal tick boundary would be the equal price point itself, which we derived above as the point q⃗\\vec{q} wherexi=r(1−1n)x_i = r\\left(1 - \\sqrt{\\frac{1}{n}}\\right)for all ii.In that case x⃗⋅1⃗=r(n−n)\\vec{x} \\cdot \\vec{1} = r(n-\\sqrt{n}), and since v⃗=1n1⃗\\vec{v}=\\frac{1}{\\sqrt{n}}\\vec{1}, we can define this tick using the plane constantkmin=x⃗⋅v⃗=x⃗⋅1⃗n=r(n−1)k_{\\text{min}} = \\vec{x} \\cdot \\vec{v} = \\frac{\\vec{x} \\cdot \\vec{1}}{\\sqrt{n}} = r(\\sqrt{n} - 1)The Maximal TickThe maximal tick's boundary is defined by the plane that lets us achieve the highest possible value of x⃗⋅v⃗\\vec{x}\\cdot\\vec{v} that doesn't require any reserve xix_i to go above rr. This happens when one reserve xjx_j reaches its minimum value of 0 while all other reserves are at the maximum, rr.For example, consider x1=0x_1=0 and x2=x3=⋯=xn=rx_2=x_3=\\cdots=x_n=r.It's still on the sphere because∑i=1n(r−xi)2=r2+∑i=2n(r−r)2=r2\\sum_{i=1}^n (r - x_i)^2 = r^2 + \\sum_{i=2}^n (r - r)^2 = r^2and we havekmax=x⃗⋅v⃗=0+(n−1)rn=rn−1nk_{\\text{max}} = \\vec{x} \\cdot \\vec{v} = \\frac{0 + (n - 1)r}{\\sqrt{n}} = r \\frac{n - 1}{\\sqrt{n}}To see that this is indeed the maximal tick boundary, note that the reserves of all tokens but X1X_1 are already at their maximum of rr assuming positive prices. So, the only way we might be able to increase x⃗⋅v⃗\\vec{x}\\cdot\\vec{v} further would be to increase the reserves of X1X_1 while decreasing the other reserves by a lesser amount so that we don't violate the AMM constant.But note that the gradient of ∥r⃗−x⃗∥2\\|\\vec{r} - \\vec{x}\\|^2 is2(r⃗−x⃗)=(r,0,…,0)2(\\vec{r}-\\vec{x}) = (r, 0, \\ldots, 0)at this point. So if the AMM reduces its x2x_2 reserves infinitesimally, because of the 0 gradient we won't decrease the value of the AMM constant ∥x⃗−r∥2\\|\\vec{x} - r\\|^2 at all. That means so we can't increase x1x_1 to compensate, and this indeed is the maximum tick boundary.Tick Reserve Bounds and Virtual ReservesThis section explores how tick boundaries affect the minimum and maximum token reserves a tick can hold, and the implications that has for capital efficiency.Minimum ReservesConsider an Orbital tick with a plane constraint ofx⃗⋅v⃗=k\\vec{x}\\cdot\\vec{v}=kLet's derive the minimum possible reserves of any one of the coins, which we'll denote as XminX_{\\text{min}}. By symmetry, the reserves of all the other XotherX_{\\text{other}} must be equal to one another at that point.Our sphere constraint then becomes(r−xmin)2+(n−1)(r−xother)2=r2(r - x_{\\text{min}})^2 + (n - 1)(r - x_{\\text{other}})^2 = r^2and our plane invariant becomes1n((n−1)xother+xmin)=k\\frac{1}{\\sqrt{n}} \\left( (n - 1)x_{\\text{other}} + x_{\\text{min}} \\right) = kso thatxother=nk−xminn−1x_{\\text{other}} = \\frac{\\sqrt{n}k - x_{\\text{min}}}{n - 1}Solving the resulting quadratic equation for xminx_{\\text{min}} we getxmin=kn−k2n−n((n−1)r−kn)2nx_{\\text{min}} = \\frac{k\\sqrt{n} - \\sqrt{k^2 n - n\\left((n - 1)r - k\\sqrt{n}\\right)^2}}{n}In terms of trading, this will usually represent the situation where all coins but one depeg to a low value, causing traders to remove as much of that still-stable coin as they can from the AMM.Virtual ReservesNo matter what traders do, they cannot force the reserves of any token XiX_i to fall below xminx_{\\text{min}}.This means the liquidity provider creating the tick can act as if they have \"virtual reserves\" of xminx_{\\text{min}} of each of the stablecoins the tick trades and don't actually need to provide those xminx_{\\text{min}} tokens when creating the tick. As in Uniswap V3, this is what allows for the capital efficiency we will discuss below.Maximum Token ReservesWe can repeat the above derivation but flip the sign of the square root to find the maximum quantity of any given coin in the tick assuming both constraints are binding.Since, if prices are positive, no coin balance will go above rr, we can then definexmax=min⁡(r,kn+k2n−n((n−1)r−kn)2n)x_{\\text{max}} = \\min\\left(r, \\frac{k\\sqrt{n} + \\sqrt{k^2 n - n\\left((n - 1)r - k\\sqrt{n}\\right)^2}}{n}\\right)andxother=nk−xmaxn−1x_{\\text{other}} = \\frac{\\sqrt{n}k - x_{\\text{max}}}{n - 1}In terms of trading, this will normally represent the situation where one single coin loses its peg and falls in value, while the other coins remain stable, causing traders to give the AMM as much of that one coin as they can. We call this a single-depeg event.Interpreting kIf we assume that the most common way things will \"go wrong\" is a single depeg event of the type described in the section immediately above, then for small enough kk we are concentrating liquidity where no coin has yet depegged down to a certain threshold -- for example, the area where no coin has depegged to below 99 cents.Assuming only one coin depegs and the rest stay constant, and that kk is small enough that the plane constaint is binding, the depegged coin will have reserves ofxdepeg=kn+k2n−n((n−1)r−kn)2nx_{\\text{depeg}} = \\frac{k\\sqrt{n} + \\sqrt{k^2 n - n\\left((n - 1)r - k\\sqrt{n}\\right)^2}}{n}andxother=kn−xdepegn−1x_{\\text{other}} = \\frac{k\\sqrt{n} - x_{\\text{depeg}}}{n - 1}Recall from the section on pricing that the instantaneous price of token XjX_j with respect to token XiX_i isδxiδxj=−δFδxj/δFδxi=r−xjr−xi\\frac{\\delta x_i}{\\delta x_j} = -\\frac{\\delta F}{\\delta x_j} \\bigg/ \\frac{\\delta F}{\\delta x_i} = \\frac{r - x_j}{r - x_i}In that case, the tick boundary corresponds to the single token depegging topdepeg=r−xdepegr−xotherp_{\\text{depeg}} = \\frac{r - x_{\\text{depeg}}}{r - x_{\\text{other}}}We can then invert this to obtain, for a given pdepegp_{\\text{depeg}}, the kk such that the boundary kicks in exactly at that depeg price:kdepeg(pdepeg)=rn−r(pdepeg+n−1)n(pdepeg2+n−1)k_{\\text{depeg}}(p_{\\text{depeg}}) = r\\sqrt{n} - \\frac{r(p_{\\text{depeg}} + n - 1)}{\\sqrt{n(p_{\\text{depeg}}^2 + n - 1)}}Note that for large-enough kk, such as kmaxk_{\\text{max}}, the tick will remain fully in-range as multiple coins depeg all the way to 0, so this interpretation won't be relevant there and we are better of thinking about metrics like maximum portfolio loss assuming all coins but one depeg.Capital EfficiencyAs we derived above, given a plane constant kk, the LP of a given tick gets to take advantage of virtual reservesxmin(k)=kn−k2n−n((n−1)r−kn)2nx_{\\text{min}}(k) = \\frac{k\\sqrt{n} - \\sqrt{k^2 n - n\\left((n - 1)r - k\\sqrt{n}\\right)^2}}{n}for each of the nn assets. If we assume they create the AMM when reserves are at the equal price point q⃗\\vec{q}, the reserves they would need to provide for each coin in the spherical AMM would bexbase=r(1−1n)x_{\\text{base}} = r\\left(1 - \\sqrt{\\frac{1}{n}}\\right)So, assuming prices never diverge enough to push reserves past the boundary of the tick, there is a capital efficiency gain ofxbasexbase−xmin(k)\\frac{x_{\\text{base}}}{x_{\\text{base}} - x_{\\text{min}}(k)}Using the depeg price formula from the prior section, we can compute how much capital efficiency you get by picking a boundary corresponding to a max depeg price of pp:cefficiency(p)=xbasexbase−xmin(kdepeg(p))c_{\\text{efficiency}}(p) = \\frac{x_{\\text{base}}}{x_{\\text{base}} - x_{\\text{min}}(k_{\\text{depeg}}(p))} log Capital Efficiency Ratio vs. Depeg Price for n=5 For example, in the 5-asset case, a depeg limit of $0.90 corresponds to around a 15x capital efficiency increase, while a limit of $0.99 corresponds to around a 150x capital efficiency increase.You can view the interactive graph on Desmos here.Tick ConsolidationOverviewA full Orbital AMM consists of multiple Orbital ticks with different kk values.In this section, we discuss situations in which multiple ticks can be treated as one for the purposes of trade calculations. This will set us up to construct a global trade invariant for the overall orbital AMM in the next section.As a reminder, for the sake of simplicity we will assume each tick has only a single LP.Consolidation MathImagine we have 2 ticks, TaT_a and TbT_b with reserves x⃗a\\vec{x}_a and x⃗b\\vec{x}_b and parameters (ra,ka)(r_a, k_a) and (rb,kb)(r_{b}, k_{b}) respectively.Case 1: Both Reserves InteriorThe simplest case is that both reserves vectors begin and end the trade \"interior\" to their respective ticks, which is to say, not on the tick boundary -- i.e.x⃗a⋅v⃗<kaandx⃗b⋅v⃗<kb\\vec{x}_a \\cdot \\vec{v} < k_a \\quad \\text{and} \\quad \\vec{x}_b \\cdot \\vec{v} < k_bIn this case, both ticks behave locally like normal spherical AMMs, and it must be that r⃗a−x⃗a\\vec{r}_a-\\vec{x}_a is parallel to r⃗b−x⃗b\\vec{r}_b-\\vec{x}_b, since otherwise at least one of the xix_i would have a different price relative to some xjx_j on the two AMMs, allowing for an arbitrage.Since by definition r⃗a=ranv⃗\\vec{r}_a=r_a\\sqrt{n}\\vec{v} and r⃗b=rbnv⃗\\vec{r}_b=r_b\\sqrt{n}\\vec{v}, we can see that r⃗a−x⃗a\\vec{r}_a-\\vec{x}_a is parallel to r⃗b−x⃗b\\vec{r}_b-\\vec{x}_b if and only ifx⃗a=rarbx⃗b\\vec{x}_a=\\frac{r_a}{r_b}\\vec{x}_bThis means the combined reserves of the two AMMs are equal tox⃗a+x⃗b=(1+rarb)x⃗b=(ra+rb)x⃗b∥x⃗b∥\\vec{x}_a + \\vec{x}_b = \\left(1 + \\frac{r_a}{r_b}\\right) \\vec{x}_b = (r_a + r_b) \\frac{\\vec{x}_b}{\\|\\vec{x}_b\\|}Since our AMM constant is ∥x⃗∥=r\\|\\vec{x}\\| = r, we can see that reserves scale with the AMM's radius, and so locally we can treat the two ticks as a single spherical AMM withrc=ra+rbr_c = r_a + r_bAs soon as one of the reserve vectors hits the boundary of its tick, we can no longer treat the two ticks as a single spherical AMM, and must move on to one of the later cases.Case 2: Both Reserves on BoundaryLet's say that both ticks start with reserves that are on their boundaries as defined by their plane constants.Now imagine that they execute a trade Δ⃗\\vec{\\Delta} such that their reserves move from x⃗\\vec{x} to x⃗′=x⃗+Δ⃗\\vec{x}'=\\vec{x}+\\vec{\\Delta} after which they are still on their boundaries.In this case for tick AA we havex⃗a⋅v⃗=kaandx⃗a′⋅v⃗=(x⃗a+Δ⃗a)⋅v⃗=ka+Δ⃗a⋅v⃗=ka⇒Δ⃗a⋅v⃗=0\\vec{x}_a \\cdot \\vec{v} = k_a \\quad \\text{and} \\quad \\vec{x}'_a \\cdot \\vec{v} = (\\vec{x}_a + \\vec{\\Delta}_a) \\cdot \\vec{v} = k_a + \\vec{\\Delta}_a \\cdot \\vec{v} = k_a \\Rightarrow \\vec{\\Delta}_a \\cdot \\vec{v} = 0This means the trade vector Δ⃗a\\vec{\\Delta}_a must be orthogonal to v⃗\\vec{v} if tick reserves both start and end on the boundary, and the same must be true for Δ⃗b\\vec{\\Delta}_b. In other words, this trade is entirely within the subspace orthogonal to v⃗\\vec{v}.As we discussed in the section on tick boundary geometry, ticks on their boundaries behave like spherical AMMs in the subspace orthogonal to v⃗\\vec{v}. Because both AMMs have centers parallel to v⃗\\vec{v}, which is orthogonal to every vector in that subspace, we can treat this subspace AMM as having a center of $0$, and by similar logic to case 1 it has a radius ofsc=sa+sbs_c = s_a + s_bwhere from the section on tick boundary geometry we have e.g.sa=ra2−(ka−ran)2s_a=\\sqrt{r_a^2 - (k_a - r_a\\sqrt{n})^2}Global Trade InvariantThis section describes how we can locally compute trades using all of our ticks simultaneously. It is extremely dense. Your favorite LLM may be of some assistance if you are wanting to parse it.SetupFirst, note that the tick consolidation section above shows we can consolidate all currently interior ticks into a single spherical tick in Rn\\mathbb{R}^n, and all currently boundary ticks into another spherical tick in the subspace of Rn\\mathbb{R}^n orthogonal to v⃗\\vec{v}. So, for the rest of this section, we will assume we have precisely two ticks, one interior and one boundary.We call the total reserve vector of our combined Orbital AMM x⃗total\\vec{x}_{\\text{total}}. As described in the section on polar reserve decomposition, we can break this down into components parallel and orthogonal to v⃗=1n(1,1,…,1)\\vec{v}=\\frac{1}{\\sqrt{n}} (1, 1, \\dots, 1), sox⃗total=αtotalv⃗+w⃗total\\vec{x}_{\\text{total}} = \\alpha_{\\text{total}} \\vec{v} + \\vec{w}_{\\text{total}}for some w⃗total⊥v⃗\\vec{w}_{\\text{total}} \\perp \\vec{v}.We do the same for our consolidated and boundary ticks:x⃗int=αintv⃗+w⃗int\\vec{x}_{\\text{int}} = \\alpha_{\\text{int}} \\vec{v} + \\vec{w}_{\\text{int}}x⃗bound=αboundv⃗+w⃗bound\\vec{x}_{\\text{bound}} = \\alpha_{\\text{bound}} \\vec{v} + \\vec{w}_{\\text{bound}}and because xtotal=xint+xboundx_{\\text{total}} = x_{\\text{int}} + x_{\\text{bound}}, we must haveαtotal=αint+αbound\\alpha_{\\text{total}} = \\alpha_{\\text{int}} + \\alpha_{\\text{bound}}w⃗total=w⃗int+w⃗bound\\vec{w}_{\\text{total}} = \\vec{w}_{\\text{int}} + \\vec{w}_{\\text{bound}}Finding alpha_bound and alpha_intWe know that the boundary reserves x⃗bound\\vec{x}_{\\text{bound}} must satisfyx⃗bound⋅v⃗=kbound\\vec{x}_{\\text{bound}} \\cdot \\vec{v} = k_{\\text{bound}}by definition, since a boundary AMM always has its reserves on the boundary as defined by its plane constraint.By the polar reserve decomposition, we also havex⃗bound⋅v⃗=(αboundv⃗+w⃗bound)⋅v⃗=αbound\\vec{x}_{\\text{bound}} \\cdot \\vec{v} = (\\alpha_{\\text{bound}} \\vec{v} + \\vec{w}_{\\text{bound}}) \\cdot \\vec{v} = \\alpha_{\\text{bound}}so thatαbound=kbound\\alpha_{\\text{bound}} = k_{\\text{bound}}Sinceαtotal=αint+αbound\\alpha_{\\text{total}} = \\alpha_{\\text{int}} + \\alpha_{\\text{bound}}we then have thatαint=αtotal−αbound=x⃗total⋅v⃗−kbound\\alpha_{\\text{int}} = \\alpha_{\\text{total}} - \\alpha_{\\text{bound}} = \\vec{x}_{\\text{total}} \\cdot \\vec{v} - k_{\\text{bound}}Showing w_int and w_bound are parallelConstruct an orthonormal basis z⃗1,…,z⃗n−1\\vec{z}_1, \\ldots, \\vec{z}_{n-1} for the subspace orthogonal to v⃗\\vec{v}. Together with v⃗\\vec{v}, this constitutes an orthonormal basis for our entire reserve space, where each basis element represents some basket of the constitutent stablecoins in different proportions.Since this is just a rotation of the axes, our interior tick is still a spherical AMM between all of these new basis vectors, and our boundary tick, being a spherical AMM in the subspace orthogonal to v⃗\\vec{v}, is a spherical AMM between all the basis vectors of that subspace, z⃗1,…,z⃗n−1\\vec{z}_1, \\ldots, \\vec{z}_{n-1}.From this, we can see that the interior tick and boundary tick must hold the z⃗i\\vec{z}_i in equal proportions, since otherwise there would be some ii and jj for which the price of the bundle z⃗i\\vec{z}_i was different to the price of the bundle z⃗j\\vec{z}_j on the boundary and interior ticks, which would present an arbitrage opportunity.Since the z⃗i\\vec{z}_i form a complete basis for the subspace of reserve space orthogonal to v⃗\\vec{v}, this implies that w⃗int\\vec{w}_{\\text{int}} must in fact be parallel to w⃗bound\\vec{w}_{\\text{bound}}.Finding ||w_int||Recall from the section on tick boundary geometry that∥w⃗bound∥2=sbound2=rbound2−(kbound−rboundn)2\\|\\vec{w}_{\\text{bound}}\\|^2 = s_{\\text{bound}}^2 = r_{\\text{bound}}^2 - (k_{\\text{bound}} - r_{\\text{bound}} \\sqrt{n})^2Since, as we showed in the previous subsection, w⃗int\\vec{w}_{\\text{int}} is parallel to w⃗bound\\vec{w}_{\\text{bound}}, the length of their sum is simply the sum of their lengths, so∥w⃗total∥=∥w⃗int∥+∥w⃗bound∥\\|\\vec{w}_{\\text{total}}\\| = \\|\\vec{w}_{\\text{int}}\\| + \\|\\vec{w}_{\\text{bound}}\\|Substituting in, we then obtain∥w⃗int∥=∥w⃗total∥−∥w⃗bound∥=∥x⃗total−(x⃗total⋅v⃗)v⃗∥−rbound2−(kbound−rboundn)2\\|\\vec{w}_{\\text{int}}\\| = \\|\\vec{w}_{\\text{total}}\\| - \\|\\vec{w}_{\\text{bound}}\\| \n= \\|\\vec{x}_{\\text{total}} - (\\vec{x}_{\\text{total}} \\cdot \\vec{v}) \\vec{v}\\| \n- \\sqrt{r_{\\text{bound}}^2 - (k_{\\text{bound}} - r_{\\text{bound}} \\sqrt{n})^2}The Full InvariantOur interior tick's sphere invariant isrint2=∥r⃗int−x⃗int∥2r_{\\text{int}}^2 = \\|\\vec{r}_{\\text{int}} - \\vec{x}_{\\text{int}}\\|^2by the Pythagorean theorem, this impliesrint2=∥r⃗int−αintv⃗∥2+∥w⃗int∥2=(αint−rintn)2∥v⃗∥2+∥w⃗int∥2r_{\\text{int}}^2 = \\|\\vec{r}_{\\text{int}} - \\alpha_{\\text{int}} \\vec{v}\\|^2 + \\|\\vec{w}_{\\text{int}}\\|^2 \n= (\\alpha_{\\text{int}} - r_{\\text{int}} \\sqrt{n})^2 \\|\\vec{v}\\|^2 + \\|\\vec{w}_{\\text{int}}\\|^2Substituting in our results from the previous sections and simplifying, we then obtain our full invariantrint2=((x⃗total⋅v⃗−kbound)−rintn)2+(∥x⃗total−(x⃗total⋅v⃗)v⃗∥−rbound2−(kbound−rboundn)2)2r_{\\text{int}}^2 = \\left((\\vec{x}_{\\text{total}} \\cdot \\vec{v} - k_{\\text{bound}}) - r_{\\text{int}} \\sqrt{n}\\right)^2 \n+ \\left(\\|\\vec{x}_{\\text{total}} - (\\vec{x}_{\\text{total}} \\cdot \\vec{v}) \\vec{v}\\| \n- \\sqrt{r_{\\text{bound}}^2 - (k_{\\text{bound}} - r_{\\text{bound}} \\sqrt{n})^2}\\right)^2Note this is equivalent to the formula for a generalized torus, a higher-dimensional extension of the familiar donut shape. Intuitively, this is because we are \"adding together\" the liquidity from the interior tick, a full sphere, with the liquidity from the boundary tick, a lower-dimensional sphere in a subspace, just the same way as a donut is construced by centering a sphere over every point on a circle.ComputationWe can directly compute this invariant asrint2=(1n∑i=1nxinti−kbound−rintn)2+(∑i=1nxtotali2−1n(∑i=1nxtotali)2−rbound2−(kbound−rboundn)2)2r_{\\text{int}}^2 = \\left( \\frac{1}{\\sqrt{n}} \\sum_{i=1}^n x_{\\text{int}i} - k_{\\text{bound}} - r_{\\text{int}} \\sqrt{n} \\right)^2 \n+ \\left( \\sqrt{ \\sum_{i=1}^n x_{\\text{total}i}^2 - \\frac{1}{n} \\left( \\sum_{i=1}^n x_{\\text{total}i} \\right)^2 } \n- \\sqrt{ r_{\\text{bound}}^2 - (k_{\\text{bound}} - r_{\\text{bound}} \\sqrt{n})^2 } \\right)^2Implementations of orbital should keep track of the sums of reserves and squared reserves that appear in that expression.Since trades of one token for another affect only two of terms in those sums, we can compute the invariant for trades in constant time regardless of the number of dimensions nn.Trading Within Tick BoundariesLogicNow that we have the global trade invariant, it is straightforward to compute trades.Let's say a user provides dd units of asset ii to the AMM and wants to exchange it for as much of asset jj as they can get.Starting from some valid reserve state x⃗total\\vec{x}_{\\text{total}}, we simply update the value of xix_i to xi+dx_i+d and then solve for the xjx_j that satisfies the global invariant while leaving all other asset balances the same. If there are multiple solutions, we choose the one that leaves the ending balances of xjx_j below the centers of both the interior and boundary ticks.This is a quartic equation in xjx_j, which we can solve easily onchain using Newton's method. As mentioned above, if we explicitly track sums in the AMM, the complexity of the equation remains constant time regardless of the number of dimensions in the AMM.Crossing TicksThe global trade invariant we derived in the previous section assumes that ticks maintain their status as either \"interior\" or \"boundary.\"However, during trades, the system's state can change in a way that causes a previously interior tick's reserves to become pinned at its boundary (or vice versa). In that case, we need to remove the tick from the consolidated boundary (interior) tick, and add it to the consolidated interior (boundary) tick, and then update the torus formula accordingly.In this section, we'll explain how to detect when these crossings happen and how to handle them by breaking the trades that cause them into segments.IntuitionImagine we have several ticks of different sizes, each one a sphere intersected by a plane determined by that tick's plane constant. These spheres might be different sizes depending on their respective radii, but we could imagine \"zooming in\" or \"zooming out\" on the spheres so that they all appeared to be the same size, perhaps represented by a radius of 1.If we were to do this, we would see something interesting: all of the ticks that are currently \"interior,\" i.e. all the ticks whose reserves are not precisely on their plane boundary, would appear to have their reserves at exactly the same point on the sphere. Geometrically, we can say this is because the spheres are similar. In terms of trading, we can say, as above, that this is because otherwise there would be an arbitrage opportunity between the ticks.Furthermore, ticks have their reserves trapped on their plane boundary and become boundary ticks precisely when this common reserve point strays farther from the equal price point than that tick's plane boundary.So, in order to trade across ticks, we just compute the trade assuming no ticks have moved from interior to boundary as described in the section on within-tick trades. Then we check the new common interior reserve point and see if it has crossed over the plane boundary of either the closest interior tick or the closest boundary tick. If it has, we compute the trade exactly up to that boundary point, update the type of the tick that was crossed, and compute the rest of the trade.NormalizationWe use normalized quantities to compare ticks of different sizes by dividing through by the tick radius.The normalized position is xnorm=x⃗/rx^{\\text{norm}} = \\vec{x} / rThe normalized projection is αnorm=x⃗norm⋅v⃗=x⃗⋅v⃗r\\alpha^{\\text{norm}} = \\vec{x}^{\\text{norm}} \\cdot \\vec{v} = \\frac{\\vec{x} \\cdot \\vec{v}}{r}The normalized boundary is knorm=krk^{\\text{norm}} = \\frac{k}{r}Note that if αnorm=knorm\\alpha^{\\text{norm}} = k^{\\text{norm}} for a given tick, we can multiply both sides by rr to remove the normalization and see that the tick is at its boundary.Suppose that for a given tick we have αnorm<knorm\\alpha^{\\text{norm}} < k^{\\text{norm}}, so that it is an interior tick. By no-arbitrage, its reserve vector x⃗\\vec{x} will be parallel to the reserve vectors of all other interior ticks, and so its normalized reserve vector x⃗norm\\vec{x}^{\\text{norm}} will be precisely equal to the normalized reserve vector of all interior ticks, which we will call x⃗intnorm\\vec{x}^{\\text{norm}}_{\\text{int}}.This interior normalized reserve vector has a projectionαintnorm=x⃗intnorm⋅v⃗\\alpha^{\\text{norm}}_{\\text{int}} = \\vec{x}^{\\text{norm}}_{\\text{int}} \\cdot \\vec{v}A given tick ii is interior if and only if kinorm>αintnormk^{\\text{norm}}_i > \\alpha^{\\text{norm}}_{\\text{int}}. To see why, first assume ii is interior. Then by definition kinorm>αinorm=αintnormk^{\\text{norm}}_i > \\alpha^{\\text{norm}}_i = \\alpha^{\\text{norm}}_{\\text{int}}. For the other direction, assume kinorm>αintnormk^{\\text{norm}}_i > \\alpha^{\\text{norm}}_{\\text{int}}. Then if this tick were to have the same normalized position as an interior tick, it would not hit its plane constraint, implying that by no-arbitrage it must in fact have this normalized position, making it an interior tick.Trade Segmentation ProcessAt any given time, the AMM's location in tick space is demarcated by kintmink_{\\text{int}}^{\\text{min}}, the minimum normalized kk of a currently interior tick, which will be the next tick to become trapped at its boundary if the overall reserves continue to move away from the equal price point. Similarly, kboundmaxk_{\\text{bound}}^{\\text{max}} is the maximum normalized kk of a currently boundary tick, which will be the first tick to become interior again as AMM reserves return to the equal price point.Let's say we are trying to compute a trade Δ⃗total\\vec{\\Delta}_{\\text{total}} where the user putting in some quantity ditotald_i^{\\text{total}} of asset XiX_i to remove some of asset XjX_j. The steps to segment the trade are as follows:Calculate Assuming No Tick Boundary Crossing: Assume all currently interior ticks stay interior and all currently boundary ticks stay boundary and compute the potential final AMM state x⃗potential\\vec{x}_{\\text{potential}} and the corresponding interior tick normalized projection αintnorm\\alpha_{\\text{int}}^{\\text{norm}} using the global trade invariant method above.Boundary Crossing Check: If our assumptions were correct and no ticks changed from interior to boundary or vice versa, then we will have kboundmax≤αintnorm≤kintmink_{\\text{bound}}^{\\text{max}} \\leq \\alpha_{\\text{int}}^{\\text{norm}} \\leq k_{\\text{int}}^{\\text{min}} -- i.e. our new interior tick point separates all the interior tick boundaries from all the boundary tick boundaries.If that's the case, we're done. Otherwise, we need to segment the trade.Segmentation (If Crossing Detected)We know the normalized boundary being crossed from the prior step, which we'll call kcrossnormk_{\\text{cross}}^{\\text{norm}}. This crossover is going to occur when αintnorm=kcrossnorm⇒αint=rintkcrossnorm\\alpha_{\\text{int}}^{\\text{norm}} = k_{\\text{cross}}^{\\text{norm}} \\Rightarrow \\alpha_{\\text{int}} = r_{\\text{int}} k_{\\text{cross}}^{\\text{norm}}.So then at the crossover point, we haveαcrossover=x⃗⋅v⃗=x⃗int⋅v⃗+x⃗bound⋅v⃗=αint+kboundtotal=rintkcrossovernorm+xboundtotal\\alpha_{\\text{crossover}} = \\vec{x} \\cdot \\vec{v} \n= \\vec{x}_{\\text{int}} \\cdot \\vec{v} + \\vec{x}_{\\text{bound}} \\cdot \\vec{v} \n= \\alpha_{\\text{int}} + k_{\\text{bound}}^{\\text{total}} \n= r_{\\text{int}} k_{\\text{crossover}}^{\\text{norm}} + x_{\\text{bound}}^{\\text{total}}where kboundtotalk_{\\text{bound}}^{\\text{total}} is the sum of the kk values of all currently boundary ticks.Find Intersection Trade Δ⃗crossover\\vec{\\Delta}_{\\text{crossover}}We want to find the tradeΔ⃗crossover=(0,…,dicrossover,0,…,−djcrossover,0,…)\\vec{\\Delta}_{\\text{crossover}} = (0, \\ldots, d_i^{\\text{crossover}}, 0, \\ldots, -d_j^{\\text{crossover}}, 0, \\ldots)between ii and jj that respects the global invariant while taking us precisely to the crossover point x⃗crossover=x⃗+Δ⃗crossover\\vec{x}_{\\text{crossover}} = \\vec{x} + \\vec{\\Delta}_{\\text{crossover}} where we haveαcrossover=x⃗crossover⋅v⃗=(x⃗+Δ⃗crossover)⋅v⃗=αtotal+Δ⃗crossover⋅v⃗=αtotal+1n(dicrossover−djcrossover)\\alpha_{\\text{crossover}} = \\vec{x}_{\\text{crossover}} \\cdot \\vec{v} \n= (\\vec{x} + \\vec{\\Delta}_{\\text{crossover}}) \\cdot \\vec{v} \n= \\alpha_{\\text{total}} + \\vec{\\Delta}_{\\text{crossover}} \\cdot \\vec{v} \\\\\n= \\alpha_{\\text{total}} + \\frac{1}{\\sqrt{n}}(d_i^{\\text{crossover}} - d_j^{\\text{crossover}})so that we seedjcrossover=n(αtotal−αcrossover)+dicrossoverd_j^\\text{crossover}=\\sqrt{n}(\\alpha_\\text{total}-\\alpha_\\text{crossover}) + d_i^\\text{crossover}Substituting that in to the global invariant formula from above yields a quadratic equation in dicrossoverd_i^{\\text{crossover}} which we can simply solve using the quadratic formula.Once we find the crossover point, we can execute the trade up to there, adjust the crossed tick from interior to boundary or vice versa, and proceed with the rest of the trade, re-segmenting if necessary.ConclusionToday, Orbital is just a design, but we're excited to see how it might change the stablecoin liquidity landscape.If you're interested in exploring with us, we'd love to hear from you.AcknowledgementsJoey Santoro, Jordi Alexander, Will Price, Alan Niemerg, Mahmoud Lababidi","tokens":9367,"squid":"spider-04","role":"Research Spider","at":1791342323087,"hash":"f979e1b9964bb9f4f6e8291fbc9879137f01c6a3"}
{"url":"https://forum.across.to/t/acx-emissions-committee-framework-update/1946","domain":"forum.across.to","title":"ACX Emissions Committee Framework Update - Proposals - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n ACX Emissions Committee Framework Update \n\n Proposals\n\n governance-updates\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jun 2024\n\n 1 / 3\n\n Jun 2024\n\n Jun 2024\n\n post by Kevin_UMA on Jun 19, 2024\n\n Kevin_UMA\n\n Title: ACX Emissions Committee Framework Update\nAuthors: Kevin Chan, David Korpi, Ryan Carman, Dylan O’Reilly, Chase Coleman\nStatus: Proposal\nRelated Discussions: ACX Emissions Committee, Native USDC and CCTP Integration\nSummary:\nThe ACX Emissions Committee (AEC) was formed in January 2024 and has now operated for over 5 months. The AEC has permissions to control ACX emissions using a transparent and restrictive framework to make predictable and measured changes to emissions for an asset depending on the pool utilization rate of that asset and the yield earned on comparable bridges. As the Across bridge develops and the cross chain interoperability landscape evolves, the AEC may need to update the parameters of its original framework. The AEC is now proposing a modification that will allow more flexibility to adjust emissions in assets that have persistent low utilization. This low utilization was observed in USDC after Across protocol integrated Circle’s Cross Chain Transfer Protocol (CCTP) for liquidity pool rebalancing. USDC utilization now hovers around 20% and will likely stay there or trend lower. The proposed modification to the AEC framework will help adjust ACX emissions to address structural changes such as this or other significant developments in the future.\nMotivation:\nSince its formation, the ACX Emissions Committee (AEC) has reduced ACX emissions by 60% from 277k ACX per day to now 110k ACX per day. The actions taken by the AEC since inception can be tracked in this spreadsheet and the data to inform these decisions are monitored on this dashboard. Despite this large reduction, the Across bridge still had sufficient liquidity provider (LP) assets to grow and secure the position as the number one bridge by volume. The AEC accomplished this through the use of a transparent and restrictive framework to optimally manage ACX emissions. After operating for over 5 months, the AEC recognizes a need to modify the existing framework to provide more flexibility to adjust emissions in assets that have persistent low utilization.\nAcross protocol’s integration of Circle’s CCTP in May 2024 for liquidity pool rebalancing highlights this need for an updated AEC framework. Since the deployment of CCTP, Across’ USDC utilization has decreased to around 20% and is expected to move even lower. At the same time Across USDC LPs are still earning a 10% to 18% yield in comparison to a Yield Index of 10.8% as observed on the AEC dashboard. The CCTP integration is a major structural advancement for Across that will likely require less USDC to operate efficiently in the future. CCTP enables the movement of native USDC at a small cost (and at much faster speeds than the canonical bridges). The current AEC framework has no way of decreasing ACX emissions to reflect this structural lower demand for USDC.\nAs a refresher, the current AEC framework uses two factors to regulate ACX emissions:\n\nAcross pool utilization - The 7-day average pool utilization of each asset.\nCompeting yield - The Yield Index for each asset that is computed as a 7-day average of the TVL weighted yield of pools on Stargate, Hop, and Synapse.\n\nUsing these two factors as inputs, the AEC built a simple framework (Table 1 below) to determine whether action needs to be taken on ETH, USDC, USDT, and DAI. If an action is required, the AEC can only increase or decrease emissions of an asset by 25% and then wait 14 days to re-evaluate and take further action if needed.\nTable 1 - Original AEC framework\n\nAcross Pool Utilization\nDecrease emissions by 25% if total Base LP APY vs Yield Index is\nIncrease emissions by 25% if total Base LP APY vs Yield Index is\n\n0 - 40%\n+25%\n-75%\n\n40 - 70%\n+50%\n-50%\n\n70 - 100%\n+100%\n-25%\n\nThe AEC now recognizes a need in the framework to address assets that have persistently low utilization rates as illustrated by the integration of CCTP. The Across DAO should not over reward LPs for providing assets that are not in demand. To address this, the AEC proposes modifying the table and adding a new row that actually decreases emissions, even when the current APY is below the Yield Index, only when utilization of an asset is below 25%. The proposed new framework is illustrated in Table 2 below.\nTable 2 - New AEC framework\n\nAcross Pool Utilization\nDecrease emissions by 25% if total Base LP APY vs Yield Index is\nIncrease emissions by 25% if total Base LP APY vs Yield Index is\n\n0 - 25%\n-50%\n-95%\n\n25 - 50%\n+25%\n-75%\n\n50 - 75%\n+50%\n-50%\n\n75 - 100%\n+100%\n-25%\n\nHere is an example of how the AEC would act today when evaluating the USDC pool:\n\nUSDC Pool Utilization = 24.03%\nUSDC Base LP APY = 9.38%\nUSDC Yield Index = 10.83%\nAcross APY is -13.4% lower than the Yield Index which is higher than the -50% threshold for action\nAEC decreases emissions by 25% and resulting APY is 7.23% (note: AEC only decreases Rewards APY and cannot control the Pool APY)\nAEC waits 14 days and re-evaluates\n\nThe reduction of ACX emissions for USDC using this new framework would act to simultaneously decrease the size of the USDC pool and increase utilization to a healthier rate. The AEC believes this new framework will provide more flexibility to adjust ACX emissions for assets with low utilization and address potential structural changes similar to the integration of CCTP.\nSpecification & Implementation:\n\nThe AEC is only amending the parameters of the original framework. Specifically, the thresholds where the AEC will act will be modified to correspond to Table 2 (New AEC framework) shown above.\n\nThis new AEC framework table will replace the old table in the Across docs to ensure it is clear to all LPs and community members that the amendment was made.\n\nAll other aspects of the AEC as outlined in the original approved proposal will not change. This includes items such as the long term goal, the wallet address that the AEC operates from and all its signers, and how the AEC operates and reports to the DAO.\n\nVoting:\n\n Should the Across DAO update the framework used by the ACX Emissions Committee (AEC)? The AEC will use the new framework as described in this proposal to adjust ACX emissions as summarized by Table 2 (New AEC framework) above.\n\n 90%\n Yes\n\n 10%\n No\n\n 0%\n Abstain\n\n 10\n voters\n\n Closed Jun 2024\n\n post by PVMihalache on Jun 20, 2024\n\n 1 month later\n\n Closed on Jul 20, 2024\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n ACX Emissions Committee\n\n Proposals\n\n governance-updates\n\n Proposals\n\n Dec 2023\n\n Reduce ACX emissions for ACX LPs, WBTC LPs and wstETH/ACX LPs\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 11\n\n Aug 2024\n\n Stop ACX Emissions on ACX LP\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 4\n\n May 2025\n\n Reduce ACX emissions for WBTC LPs\n\n Active Proposals\n\n Active Proposals\n\n Aug 2025\n\n Reduce ACX emissions for Across ACX LPs\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 8\n\n Nov 2023","tokens":3271,"squid":"spider-09","role":"Bridge Spider","at":1791342330277,"hash":"8ad15f6c952e5878628022fb76122653956d1b7e"}
{"url":"https://jup.ag/stocks/wmt","domain":"jup.ag","title":"Walmart Inc. Common Stock (WMT) Tokenized Stock Price on Solana","text":"Underlying price$107.19+2.02% todayStock statsMarket cap$833BPrevious close$105.07Open$104.50Day's range$104.50 – $107.5552-week range$98.88 – $135.15Volume22.0MAvg volume23.7MP/E ratio37.76About Walmart Inc. Common StockSince its founding in 1962, Walmart has become the world's largest retailer, operating over 10,700 stores globally (including 4,600 namesake locations on its home turf and another 600 Sam's Club outlets) and growing its e-commerce presence, attracting 270 million customers weekly. In aggregate, the firm posted more than $713 billion in fiscal 2026 sales. Its core operations span three reporting segments: Walmart US (68% of fiscal 2026 sales), Walmart International (19%), and Sam's Club (13%).Within the US, nearly 60% of its $486 billion in fiscal 2026 revenue came from its grocery offerings, with another quarter from general merchandise. Internationally, Walmart's operations are concentrated in Mexico, though it also has budding exposure to India.TickerWMTAsset classEquityTokenized by2 issuersSectorConsumer DiscretionaryIndustryRetail-Variety StoresEmployees2,100,000Websitestock.walmart.comWalmart Inc. Common Stock FAQWMT is Walmart Inc. Common Stock stock, issued on Solana as a token that tracks the listed share. Each issuer mints its own version, so Walmart Inc. Common Stock trades here as 2 tokens rather than one.Token prices are designed to track Walmart Inc. Common Stock's listed shares, but they can differ because of issuer terms, liquidity, market hours, and trading activity.xStocks and Ondo issue the tokenized Walmart Inc. Common Stock markets shown on Jupiter. Each issuer controls its own token and settlement terms.Trading availability depends on the issuer token and its market. Open an issuer's token page to check current liquidity and trading status.Use the Market swap on this page. Select the WMT token in the swap to choose an issuer. Connect your wallet, choose the token you want to pay with, and enter an amount. Review the swap details before you submit, then confirm in your wallet when prompted. A swap requires an available trading route. Issuer terms and restrictions apply.Dividend treatment depends on the token issuer. A dividend paid on Walmart Inc. Common Stock's listed shares does not guarantee a cash payment to token holders. Review each issuer's terms for how dividends and other corporate actions are handled.Read Ondo's corporate action policyRead xStocks' dividend and stock split policy","tokens":617,"squid":"spider-02","role":"Liquidity Spider","at":1791342331105,"hash":"da6c3e68c3b534508eabdacae7fc0f0ae75fd3c2"}
{"url":"https://www.paradigm.xyz/writing/multiverse-finance","domain":"paradigm.xyz","title":"Multiverse Finance","text":"Multiverse Finance \n\n Your browser does not support the video tag.\n\n Animation by Dave Whyte\n\n IntroductionPrediction markets let you bet on outcomes, but so much more is possible.This paper introduces Multiverse Finance, which splits the financial system into parallel universes so you can short the market today only if your favorite candidate is going to lose the next election.Intuition Consider a prediction market on whether Jerome Powell will be fired in 2025. If you think he won't be, you can buy a notFiredUSD token for 89 cents which will be worth $1 in 2026 if he isn't fired.\nBut that's a long time to wait, and in the meantime you can't use your notFiredUSD as collateral in most financial systems -- if Powell were suddenly fired, the token's value could drop to 0 faster than the system could liquidate your debt.However, there is no problem when using notFiredUSD as collateral to borrow, say notFiredETH. If Powell is suddenly fired, both your collateral and the asset you borrowed become worthless simultaneously, so there is no liquidation issue.This idea is what makes Multiverse Finance possible.The simplest version of Multiverse Finance could be implemented today on mainnet by allowing conditional tokens for the same outcomes (like firedEth and firedUSD) to be borrowed and lent against each other on an Aave-like protocol.Further expansions are possible, including (liquidity issues aside) complete financial ecosystems with limitless chains of composibility -- you could take your firedUSD, borrow firedETH against it, provide liquidity on firedSwap to earn firedSwap tokens, stake those in firedFarm, and so on.Like prediction markets or futarchies of the type implemented by MetaDAO, in addition to allowing participants new opportunities to express financial views or hedge exposure, Multiverse Finance produces useful information about the world as a positive externality.MechanismVersesA \"verse\" is a parallel universe where some event we care about has happened or will happen at some point in the future.Mathematically, verses correspond to events in probability theory, which are sets of outcomes (possible states of the world) with the following structure: Any verse has a complement verse such that the two combine to cover all possible states of the world (e.g., \"Powell fired by 2026\" and \"Powell not fired by 2026\") Verses can be combined through countable unions to form new verses (e.g., \"Powell fired by 2026 OR recession by 2026\" is a verse where one of the two, or both, happen) The intersection of a countable set of verses forms a new verse (e.g., \"Powell fired by 2026 AND recession by 2026\" is a verse)Today's universe, where the regular financial system exists, corresponds to the event containing the whole sample space.We call a verse a \"parent\" to another verse if the child verse is a subset of the parent, meaning every outcome in the child verse is also in the parent verse. So, for example, \"Powell fired by 2026\" and \"recession by 2026\" are both parents of \"Powell fired by 2026 AND recession by 2026.\"Today's universe is a parent to all verses (although some verses, such as \"Powell Fired by May 2025\" become empty of possible outcomes as time goes on).We call a set of child verses a partition of their parent verse if the child verses are disjoint (non-overlapping) and their union makes up the entire parent verse. For example, \"Powell fired by 2026\" and \"Powell not fired by 2026\" form a partition of today's universe.\nOwnership Intuition\nThe high-level intuition when working with verses in Multiverse Finance is that owners can choose to push ownership down to a partition, or pull it up from a partition.In other words, let's say we have a verse VV and some partition P1,P2,P3P_1,P_2,P_3 of VV.If I own 1 unit of a given token TT in VV, I can choose to \"push down\" my ownership to the partition, meaning I give up my ownership of TT in VV and instead now own 1 unit of TT in each of P1,P2P_1,P_2 and P3P_3. This is equivalent to how you can always take $1 and mint one YES and one NO token for a given prediction market.Conversely, if I own 1 of token TT in each of P1,P2P_1,P_2, and P3P_3, I can choose to \"pull up\" my ownership of TT to VV, losing my ownership of it in each of those partition verses. This is equivalent to how you can take a YES and a NO token for a given prediction market and get back $1.Verse ResolutionVerses, like prediction markets, rely on some underlying oracle for resolution. This paper is agnostic to which type of oracle you might use.At the time of resolution, any verse that does not contain the observed outcome reported by the oracle immediately disappears, together with all of its state.If we had some partition P1,P2,…,PNP_1,P_2,\\ldots,P_N of a parent verse AA, and a resolution evaporates all but one of them, such that only a single verse PiP_i remains, PiP_i now forms a complete partition of AA in and of itself, and we can pull up ownership of any given assets from PiP_i directly to AA.For example, if I owned 1 USD in the \"Powell not fired by 2026\" verse and it's now Jan 1, 2026 and Powell has not been fired, the \"Powell fired by 2026\" verse disappears and \"Powell not fired by 2026\" partitions the full outcome space by itself, so I can pull my $1 up to the present day universe and withdraw it from the system. In this case, this is identical to normal prediction market resolution.Multiverse MapsThe ownership behavior described above is somewhat conceptual and could be implemented in many possible ways. We'll provide one example method here: the multiverse map.This is a map (a.k.a. dictionary) datatype with two keys: verse ID and owner address.The multiverse map is governed by two rules: one for splitting, and one for combining. We'll describe an additive, non-negative multiverse map with a single unsigned integer value. Splitting: The user controlling the owner address of a map entry for a given parent verse can subtract some quantity xx from the entry's value that leaves the entry non-negative, and then add xx to their balance in each of a set of verses that form a partition of the parent verse.Combining: The user controlling the owner address of a given map entry in each of a group of verses can subtract some quantity xx from the entry's values in each of those verses that leaves them all nonnegative, and then add xx to their balance in some parent verse that that group of verses form a partition of. As mentioned above, if the parent verse is the complete universe, this serves as a way for users to withdraw funds after event resolution.Multiverse Aware ApplicationsThis primitive could be used to construct, say, a wrapper contract to make standard ERC20 tokens multiverse-ready.Developers can also build more custom multiverse-aware applications using data structures like the multiverse map. A lending protocol like the one discussed above might, for example, specify that only assets from the same verse may be borrowed and lent against one another.Designed properly, these protocols should be readily composable with one another as long as they are in the same verse. Again, the core insight is that developers don't need to worry about a token like notFiredEth disappearing suddenly and breaking a chain of composability, because every token in the verse should disappear simultaneously.Future WorkWe're curious what multiverse native applications this concept might unlock.If you have ideas, we'd love to hear from you.\nAcknowledgementsAlpin Yukseloglu, Arjun Balaji, Dan Robinson, David Swain, Frankie, Matt Huang, Storm Slivkoff, Will Price, Jordi Alexander, Fozzy Diablo, Ella Papanek, Matt Liston, Serge Ravitch, Cristian Strat, Czar102, jdougy, Liam Zebedee, Mewny","tokens":1930,"squid":"spider-04","role":"Research Spider","at":1791342332972,"hash":"ea126edc409158ef394983bdb3d50f956c211570"}
{"url":"https://forum.across.to/t/acx-emissions-committee-framework-update/1946/3","domain":"forum.across.to","title":"ACX Emissions Committee Framework Update - Proposals - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n Proposals\n\n governance-updates\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jun 2024\n\n 3 / 3\n\n Jul 2024\n\n Jun 2024\n\n post by Kevin_UMA on Jun 19, 2024\n\n Kevin_UMA\n\n Title: ACX Emissions Committee Framework Update\nAuthors: Kevin Chan, David Korpi, Ryan Carman, Dylan O’Reilly, Chase Coleman\nStatus: Proposal\nRelated Discussions: ACX Emissions Committee, Native USDC and CCTP Integration\nSummary:\nThe ACX Emissions Committee (AEC) was formed in January 2024 and has now operated for over 5 months. The AEC has permissions to control ACX emissions using a transparent and restrictive framework to make predictable and measured changes to emissions for an asset depending on the pool utilization rate of that asset and the yield earned on comparable bridges. As the Across bridge develops and the cross chain interoperability landscape evolves, the AEC may need to update the parameters of its original framework. The AEC is now proposing a modification that will allow more flexibility to adjust emissions in assets that have persistent low utilization. This low utilization was observed in USDC after Across protocol integrated Circle’s Cross Chain Transfer Protocol (CCTP) for liquidity pool rebalancing. USDC utilization now hovers around 20% and will likely stay there or trend lower. The proposed modification to the AEC framework will help adjust ACX emissions to address structural changes such as this or other significant developments in the future.\nMotivation:\nSince its formation, the ACX Emissions Committee (AEC) has reduced ACX emissions by 60% from 277k ACX per day to now 110k ACX per day. The actions taken by the AEC since inception can be tracked in this spreadsheet and the data to inform these decisions are monitored on this dashboard. Despite this large reduction, the Across bridge still had sufficient liquidity provider (LP) assets to grow and secure the position as the number one bridge by volume. The AEC accomplished this through the use of a transparent and restrictive framework to optimally manage ACX emissions. After operating for over 5 months, the AEC recognizes a need to modify the existing framework to provide more flexibility to adjust emissions in assets that have persistent low utilization.\nAcross protocol’s integration of Circle’s CCTP in May 2024 for liquidity pool rebalancing highlights this need for an updated AEC framework. Since the deployment of CCTP, Across’ USDC utilization has decreased to around 20% and is expected to move even lower. At the same time Across USDC LPs are still earning a 10% to 18% yield in comparison to a Yield Index of 10.8% as observed on the AEC dashboard. The CCTP integration is a major structural advancement for Across that will likely require less USDC to operate efficiently in the future. CCTP enables the movement of native USDC at a small cost (and at much faster speeds than the canonical bridges). The current AEC framework has no way of decreasing ACX emissions to reflect this structural lower demand for USDC.\nAs a refresher, the current AEC framework uses two factors to regulate ACX emissions:\n\nAcross pool utilization - The 7-day average pool utilization of each asset.\nCompeting yield - The Yield Index for each asset that is computed as a 7-day average of the TVL weighted yield of pools on Stargate, Hop, and Synapse.\n\nUsing these two factors as inputs, the AEC built a simple framework (Table 1 below) to determine whether action needs to be taken on ETH, USDC, USDT, and DAI. If an action is required, the AEC can only increase or decrease emissions of an asset by 25% and then wait 14 days to re-evaluate and take further action if needed.\nTable 1 - Original AEC framework\n\nAcross Pool Utilization\nDecrease emissions by 25% if total Base LP APY vs Yield Index is\nIncrease emissions by 25% if total Base LP APY vs Yield Index is\n\n0 - 40%\n+25%\n-75%\n\n40 - 70%\n+50%\n-50%\n\n70 - 100%\n+100%\n-25%\n\nThe AEC now recognizes a need in the framework to address assets that have persistently low utilization rates as illustrated by the integration of CCTP. The Across DAO should not over reward LPs for providing assets that are not in demand. To address this, the AEC proposes modifying the table and adding a new row that actually decreases emissions, even when the current APY is below the Yield Index, only when utilization of an asset is below 25%. The proposed new framework is illustrated in Table 2 below.\nTable 2 - New AEC framework\n\nAcross Pool Utilization\nDecrease emissions by 25% if total Base LP APY vs Yield Index is\nIncrease emissions by 25% if total Base LP APY vs Yield Index is\n\n0 - 25%\n-50%\n-95%\n\n25 - 50%\n+25%\n-75%\n\n50 - 75%\n+50%\n-50%\n\n75 - 100%\n+100%\n-25%\n\nHere is an example of how the AEC would act today when evaluating the USDC pool:\n\nUSDC Pool Utilization = 24.03%\nUSDC Base LP APY = 9.38%\nUSDC Yield Index = 10.83%\nAcross APY is -13.4% lower than the Yield Index which is higher than the -50% threshold for action\nAEC decreases emissions by 25% and resulting APY is 7.23% (note: AEC only decreases Rewards APY and cannot control the Pool APY)\nAEC waits 14 days and re-evaluates\n\nThe reduction of ACX emissions for USDC using this new framework would act to simultaneously decrease the size of the USDC pool and increase utilization to a healthier rate. The AEC believes this new framework will provide more flexibility to adjust ACX emissions for assets with low utilization and address potential structural changes similar to the integration of CCTP.\nSpecification & Implementation:\n\nThe AEC is only amending the parameters of the original framework. Specifically, the thresholds where the AEC will act will be modified to correspond to Table 2 (New AEC framework) shown above.\n\nThis new AEC framework table will replace the old table in the Across docs to ensure it is clear to all LPs and community members that the amendment was made.\n\nAll other aspects of the AEC as outlined in the original approved proposal will not change. This includes items such as the long term goal, the wallet address that the AEC operates from and all its signers, and how the AEC operates and reports to the DAO.\n\nVoting:\n\n Should the Across DAO update the framework used by the ACX Emissions Committee (AEC)? The AEC will use the new framework as described in this proposal to adjust ACX emissions as summarized by Table 2 (New AEC framework) above.\n\n 90%\n Yes\n\n 10%\n No\n\n 0%\n Abstain\n\n 10\n voters\n\n Closed Jun 2024\n\n post by PVMihalache on Jun 20, 2024\n\n PVMihalache\n\n All good to me! The increase utilization to a healthier rate means more efficiency so let’s do it!\nAlso agreed that the Across DAO should not over reward LPs for providing assets that are not in demand. This is not financially efficient.\n\n 1 month later\n\n Closed on Jul 20, 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 ACX Emissions Committee\n\n Proposals\n\n governance-updates\n\n Proposals\n\n Dec 2023\n\n Reduce ACX emissions for ACX LPs, WBTC LPs and wstETH/ACX LPs\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 11\n\n Aug 2024\n\n Stop ACX Emissions on ACX LP\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 4\n\n May 2025\n\n Reduce ACX emissions for WBTC LPs\n\n Active Proposals\n\n Active Proposals\n\n Aug 2025\n\n Reduce ACX emissions for Across ACX LPs\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 8\n\n Nov 2023","tokens":3349,"squid":"spider-09","role":"Bridge Spider","at":1791342340445,"hash":"061e177c42054a2d2a18e710dd0d305642338adb"}
{"url":"https://www.paradigm.xyz/writing/across-prime","domain":"paradigm.xyz","title":"Across Prime","text":"Across Prime IntroductionThis paper introduces Across Prime, a design for a capital efficient trustless fast bridge.Solving interoperability for Ethereum and other blockchains requires “fast” bridging—bridges that can move assets and actions between chains at faster-than-finality speeds. Intent-based bridge designs, like what Across protocol offers today, are the leading design to solve this problem.Fast bridges depend on third party relayers (aka solvers) to fill a user’s “intent” on a destination chain in exchange for a payment on the origin chain. Most such bridges—like Across—use an “escrowed” model where payment is escrowed until the intent is verified as “filled”. This escrowed design introduces capital costs as relayers must wait before being repaid; relayers effectively act as short-term lenders to fill user intents.Across Prime introduces a “bonded” model where the relayer puts down a collateralized bond to secure a particular path from an origin chain to a destination chain. This allows the user to send money directly to the relayer on the origin chain. The bonded model is significantly more capital efficient than the escrowed model while maintaining most of the security and decentralization benefits.MechanismAcross Prime is an evolution of the fast bridge design.In a fast bridge, a user has some intent about what they want to happen on the destination chain (such as receiving an asset, sending an asset to someone else, or taking an action on some application). The user makes a payment on an origin chain to some third-party relayer in return for them filling that intent.One key question in designing intent-based bridges is how to solve the problem of fair exchange. What prevents the relayer from taking the user’s payment without filling their intent?TrustedThe simplest version of an intent-based bridge solves the fair exchange problem using a trusted relayer. This is the version implemented by applications like Relay today.In the trusted bridge model, the user pays the relayer on the origin chain, and the relayer fulfills the intent on the destination chain. \nIf the relayer is honest, this model can be very efficient. However, it does not protect the user against a malicious relayer. Additionally, the need to trust the relayer makes it difficult to have multiple independent relayers, which limits competition and scalability. The trusted model may also be exposed to custodial or regulatory risks.EscrowedWhen there is some way of sending messages from the destination chain to the origin chain (a “settlement oracle”), other designs for fast bridges become possible. One is the “escrowed” model. This is the model used in Across today, as well as the design contemplated for crosschain UniswapX.In this design, the user makes their payment not to the relayer, but into escrow on an origin chain smart contract. The relayer fills the intent on the destination chain with their own capital, then uses the oracle to prove fulfillment before user funds are released back to the relayer. \nThis escrow system is well described by the ERC-7683 standard for crosschain intents, where the escrow contract and settlement oracle are abstracted into a “settlement system”. The Open Intents Framework builds on this standard with reference implementations for ERC-7683 compatible relayers and modularized settlement systems.If the oracle is slow or expensive, there is a simple “optimistic” variation of this design, where the relayer puts down a deposit, and the intent is assumed to be fulfilled unless someone challenges the fill within a certain challenge period.In all versions of the escrowed model, the payment on the origin chain is stuck in escrow until intent fulfillment is verified, creating a capital cost for relayers. Depending on the oracle and the security assumptions of the challenge period, this may be as long as a few hours.The bonded model is a way to reduce or eliminate this capital inefficiency.BondedAcross Prime introduces a different kind of trustless fast bridge: “bonded” bridging. In this model, the relayer receives the payment on the origin chain immediately. The user’s safety is guaranteed by a security deposit provided by the relayer, with the bond determining the maximum amount that the relayer can have “in flight” at any given time. If the relayer fails to complete any of the actions they were paid for, the user can claim a refund from that security deposit. \nThis is much more capital efficient than the escrowed model, particularly if the settlement oracle is slow.For example, suppose a relayer has a bond of $1,000, the origin and destination chains each produce one block every two seconds, and the settlement oracle takes one hour to finalize:Using the bonded model, users can make up to $1,000 in payments every four seconds. (As discussed below, users need to wait two blocks between payments in order to confirm that the relayer completes the desired action from the previous payment on the destination chain.) This results in a total hourly bandwidth of up to $900,000.In the escrowed model, each payment would need to be locked up for an hour to wait for the settlement oracle to finalize, so making $900,000 in payments would require locking up a total of $900,000 in capital for one hour—making it up to 900 times less capital efficient than the bonded model (given the assumptions of this example).The bonded model is more capital efficient since bonds are “reusable” as soon as the intent is completed on the destination chain, even if the settlement oracle takes much longer to finalize. This quality makes it practical to use much slower (and more secure or more decentralized) settlement oracles—such as the one-week canonical bridge to exit from an optimistic L2—since the capital cost is no longer proportional to the latency of the settlement oracle.At first glance, the bonded design appears to present an unfortunate tradeoff: the relayer will only be able to support large payments if they keep a large bond locked up at all times. This suggests the design could be incompatible with a market structure where users occasionally need to send large transfers that overwhelm the relayer’s bond requirements. But we can tweak the bonded model to fix this—in the case where the bond is insufficient to cover the user’s desired payment, we can immediately add the user’s funds directly to the relayer’s bond, increasing the bond size “just-in-time”. This tweak essentially allows the bonded model to “fall back” to the escrowed design when the bond is not large enough, but with an added bonus: the escrow “bond” can immediately be reused to secure payments of other users.ProtocolHere is a simple version of a bonded protocol for bridging ETH across chains (though it could easily be generalized to fulfilling arbitrary intents). It includes some important logic to handle edge cases, including “contention” (the risk that multiple users will attempt to send payments to a relayer at the same time, causing the total amount in flight to exceed the security deposit).As the first step, suppose Bob wants to become a relayer for a particular route, where a route is defined as the path from a specific origin chain to a specific destination chain. Bob puts down some amount of ETH, securityDeposit, on the origin chain (say, Arbitrum), and specifies which destination chain they will support (say, Base).The origin chain has a “turnstile contract,” which tracks a value, cumulativePayments, for the cumulative amount of payments made to Bob for that route, as well as a Merkle root of all intents filled through it (where each new root is keccak256(oldRoot, order)). Every time a payment is made to Bob for that route, the cumulativePayments value is incremented, the Merkle root is updated, and a payment event is emitted with the new Merkle root and new value for cumulativePayments.The destination chain has a “fulfillment contract,” which also tracks the intents filled through the route. It has a Merkle root that corresponds to the one on the origin chain, so that when all intents on that route have been fulfilled, the Merkle roots match.A user, Alice, wants to send ETH from Arbitrum to Base. She consults a list or API for relayers that support that path, and picks Bob. She checks Bob’s Merkle root on the destination chain, and looks at recent payment events on the origin chain until she finds a matching root, noting the cumulativePayments value from that event as confirmedCumulativePayments.She confirms that Bob’s relayer bond is large enough to refund the payments on all currently unfulfilled intents, plus her own. She signs an ERC-7683 GaslessCrossChainOrder, with the following information in the orderData field:payment: the amount of ETH Alice is willing to pay to Bob (the relayer) on ArbitrumconfirmedCumulativePayments: The value that Alice computed for the total cumulative payments that have been fulfilled. As discussed below, this number helps the turnstile contract enforce that Bob’s security deposit will be sufficient to reimburse Alice.destinationAmount, destinationAddress: the amount of ETH that Alice wants to receive on the destination chain, and the address she wants to receive it at. This could easily be replaced with arbitrary intents, as long as it can be enforced by the fulfillment contract.Alice gives this intent to Bob (the relayer), who submits it to the turnstile contract on the origin chain. The turnstile contract checks that the intent is being submitted by Bob, and that securityDeposit is greater than cumulativePayments + payment - confirmedCumulativePayments. It then adds the payment amount to cumulativePayments, hashes the order into the Merkle chain, and transfers payment directly from Alice to Bob.Bob can also specify that he wants to deposit some of the payment into his bond, instead of receiving it immediately. This could be helpful if Bob does not currently have enough in his bond to cover Alice’s payment.The turnstile contract fires an event that includes the hash of the order, the new cumulativePayments, the destination chain ID, and the new Merkle root.Bob now fills the user on the destination chain, passing their order through the fulfillment contract. The fulfillment contract verifies that the order has been fulfilled, hashes it, and adds it to the Merkle chain. It also fires an event noting the new Merkle root.If Bob did not fill some intent, then after a challenge period, anyone could challenge Bob on the origin chain. Pending challenges prevent Bob from withdrawing his bond until he has proven that the order was fulfilled on the destination chain (by using the slow message bridge to prove that the Merkle roots match). If there are multiple pending challenges, whichever order was included first in the Merkle chain takes precedence.ExtensionsArbitrary Bond CollateralIn the example given above, the payment currency is the same as the bond currency. It would be inefficient for each relayer to bond in each currency. The model can be extended to support arbitrary bond collateral provided that the user (Alice) signs off on a minimum exchange rate she’ll accept for the duration of her order. Alice’s payment amount (which locks up Bob’s bond) will then be “padded” with her conservative exchange rate, protecting Alice from changes in the relative value of her payment currency versus Bob’s bond currency during her order.Since Alice’s order should get filled very quickly (in seconds), the actual padding required can be quite modest while still fully protecting Alice.Multiple DestinationsIn the simplified version of the bonded model described above, there is a security bond required by each relayer for each route. In the example above, Bob (the relayer) deposited a bond on Arbitrum specifically allocated to the Arbitrum→Base route. If Bob needs to deposit a bond for each and every route, the bonds required would reduce the capital efficiency of the system.To mitigate this, each origin chain bond could be used to cover many destination chains. This puts some additional burden on the user, who now must check each destination chain in the set to verify which unfilled intents are outstanding. The user must also trust the sequencers or pre-confirmations for each destination chain. If the user prefers isolated trust assumptions, they could require the relayer to have separate bonds dedicated to each path.DiscussionGas EfficiencyAs discussed above, the bonded model can be dramatically more capital efficient than the escrowed model. It can also offer a meaningful improvement in gas efficiency, since in the happy case, it only requires two transactions (one on the origin chain and one on the destination chain), while the escrowed model requires a third transaction on the origin chain for settlement.ERC-7683 CompatibilityAcross and Uniswap have proposed ERC-7683, a broadly supported standard for crosschain intents. This standard was authored with the escrowed intent model in mind, however it is generally compatible with Across Prime’s bonded design. Following the ERC-7683 spec, originSettler can be set to Across Prime’s turnstile contract, and destinationSettler is simply the Across Prime fulfillment contract on the destination chain. The orderData and event structures proposed by the standard remain unchanged.Mint-and-Burn Bridge CompatibilityIn the bonded model relayers receive the user’s payment on the origin chain before they must fill the user on the destination chain. This means that if the payment currency is a mint-and-burn token (like Circle’s USDC, Hyperlane’s Warp Tokens, LayerZero’s OFTs, Wormhole’s NTTs, etc), the relayer does not need to have any inventory on the destination chain to support the flow, albeit with slower fills times.In these situations, the user could trade modestly slower fill times in exchange for cheaper fills. One example flow: (i) user publishes their intent with a longer fill time (e.g. 3 minutes) and sends mint-and-burn tokens to relayer; (ii) relayer uses the mint-and-burn bridge to move these tokens to the destination chain; (iii) after the mint-and-burn bridge completes, relayer fills user.In this structure, Across Prime functions as a superset of all available bridging methods: if an instant fill is available (because the relayer holds inventory on the destination chain), the user will receive an instant fill; if inventory is not available, the user will receive a fill at the approximate speed and cost of the underlying mint-and-burn bridge.Prior workThere has been much prior work on intent-based crosschain protocols, including many escrow-based designs, as well as some architectures that bear a closer resemblance to Across Prime’s bonded model.AcrossAcross originated the escrowed intent design, combining it with optimizations for “batch settlement”. In Across, users deposit funds into escrow on the origin chain before relayers race to fill the user on the destination chain. Every period (approximately 1 hour), all completed fills are summarized into a Merklized bundle that “batch repays” each relayer for all refunds owed on each chain. This bundle is optimistically verified on Ethereum mainnet before funds are released. This design intelligently minimizes gas costs via batch repayments, but requires relayer capital to be locked for ~1hr, creating significant capital costs.Orbiter ProtocolOrbiter’s design goals share some qualities that resemble Across Prime. Like Across Prime, Orbiter requires relayers (called makers) to post a bond before asking users to send funds directly to the relayer (aka maker). This bond must be larger than the funds being sent to the relayer. Orbiter’s design, however, doesn’t handle contention; the protocol cannot prevent two or more users from mistakenly sending a relayer more funds than the bond can cover. Across Prime prevents contention and enforces proper margining via the turnstile contract.UniswapX (Crosschain)Crosschain UniswapX is not yet implemented. It follows a similar design to Across without batch settlement. For each bridge transaction, user funds are escrowed on the origin chain; relayers then fill users on the destination chain. Funds are only released from escrow after an optimistic challenge period has passed. Across Prime bypasses the costs associated with the individual escrow and verification of each bridge transaction.Relay ProtocolRelay protocol is currently implemented as a centralized, trusted relayer. Relay has shared designs to decentralize their implementation with a separate “settlement chain” where relayers must escrow funds before receiving deposits directly from users. This settlement chain requires individual escrow and settlement of each transaction before the relayer receives their escrowed funds. Across Prime saves on uncertainty, gas costs, complexity by sidestepping the entire need for per-transaction escrow or settlement. Users simply have to verify that a relayer is properly bonded.Further WorkCurrent fast bridges often rely on escrow models, which hinder capital efficiency by locking relayer funds during settlement delays. This paper introduced Across Prime, a fast bridge design employing a \"bonded\" model. This bond can be reused almost immediately, decoupling capital velocity from settlement latency and vastly improving both gas and capital efficiency.If you are interested in developing Across Prime, or working on related intent based bridge designs, reach out to this paper’s authors or the Across team.","tokens":4380,"squid":"spider-04","role":"Research Spider","at":1791342343357,"hash":"f57c29985f79232f91cc04bcb13263c145d5e7ec"}
{"url":"https://forum.across.to/t/reduce-acx-emissions-for-across-acx-lps/1756","domain":"forum.across.to","title":"Reduce ACX emissions for Across ACX LPs - Proposals - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n Reduce ACX emissions for Across ACX LPs \n\n Proposals\n\n treasury-funding\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 5\n min\n\n Oct 2023\n\n 1 / 10\n\n Oct 2023\n\n Nov 2023\n\n post by Kevin_UMA on Oct 31, 2023\n\n Kevin_UMA\n\n Header\nTitle: Reduce ACX emissions for Across ACX LPs\nAuthor: Kevin Chan\nStatus: Proposal\nRelated Discussion: Reduce or Reallocate Across ACX LP emissions\nSummary:\nThe Across DAO should decrease ACX emissions for Across ACX LPs by 50%. Across’ Reward Locking program is currently distributing ~30,000 ACX per day in base emissions to Across ACX LPs after the recent parameter changes. Emissions were initially set high to incentivize ACX airdrop recipients to not immediately sell their tokens and to get these token holders familiar with the reward locking mechanism. Given it’s been almost a year since the launch of the token, the community should consider reducing these emissions.\nMotivation:\nThe Across DAO treasury is currently rewarding a significant amount of ACX to ACX holders via incentives. In total the DAO is spending 47,714 to 91,714 ACX per day on ACX related pools.\n30,000 to 60,000 ACX /day - Across ACX LP (1 to 2x multiplier)\n7,000 to 21,000 ACX / day - wstETH/ACX Balancer pool (1 to 3x multiplier)\n10,714 ACX / day - WETH/ACX Velodrome pool bribes (75,000 ACX per week)\nTotal = 47,714 to 91,714 ACX / day\nOf the 3 liquidity pools, the Across ACX bridge pool is the least utilized. At the moment the amount of ACX bridged is small, especially in comparison to the size of the pool. Emissions were initially set high for Across ACX LPs to incentivize ACX airdrop recipients to not immediately sell their tokens and to get these token holders familiar with the reward locking mechanism. Given it’s been almost a year since the launch of the token, the community should consider reducing these emissions. Decreasing rewards to Across ACX LPs may also incentivize ACX token holders to instead provide liquidity in the ACX token itself via the wstETH/ACX or WETH/ACX pools. This also helps address a concern by the community that the ACX token needs to be more easily tradable.\nThe Across DAO should decrease ACX emissions for Across ACX LPs by 50% resulting in base emissions of ~15,000 ACX per day for this pool. This would decrease the APY to a range of ~4.7% to 9.3% from the current APY of 9.3 to 18.6% as observed on the Across Rewards page. Choosing the optimal number for this change is difficult; therefore, the Across community should continuously monitor ACX token activity and make future modifications as needed.\nSpecification & Implementation:\nThe Across DAO wallet controlled by ACX holders has admin rights to change the parameters of the Accelerating Distributor contract that powers the Reward Locking program. The exact transactions to make these modifications can be put to a vote and executed on Snapshot via the oSnap module which is already implemented.\nThe proposed Snapshot vote and oSnap transaction will reflect a change in the emission rate for Across ACX LPs to ~15,000 ACX per day (from~ 30,000 ACX per day currently).\nDownside (Cons):\nThe potential risk to the decreasing emissions to Across ACX LPs is selling pressure from ACX holders. Staked ACX LPs may find the lower APY unappealing and may choose to unstake and sell their ACX position. A couple of observations counter this concern:\n\nRecent data and analysis show Across has a loyal set of LPs. These LPs are happily earning ACX through reward locking and have not claimed and sold their rewards. It implies most ACX holders believe the token offers value and are unlikely to sell.\nACX token holders still have attractive alternatives to earn rewards and may instead utilize their tokens in other pools that better serve the community. For example, wstETH/ACX LPs are currently earning 16.2 to 41.8%.\n\nVoting:\n\n Should the Across DAO set base emissions for Across ACX LPs to ~15,000 ACX per day which is a decrease of 50% from current incentives?\n\n 77%\n Yes\n\n 23%\n No\n\n 0%\n Abstain\n\n 13\n voters\n\n Closed Nov 2023\n\n 3\n\n 2\n\n 2\n\n read \n\n 5\n min\n\n post by berry4144 on Oct 31, 2023\n\n berry4144\n\n Voting for the Dentist over the candy shop owner.\nTurkey for Christmas…\nShort term pain, long term gain…\n\n post by gmsteele on Oct 31, 2023\n\n gmsteele\n\n Considering the recent drop in the multiplier that was supposed to be offset by greater emissions, now we come quickly back and say decrease emissions? I voted “no,” simply because to me the proposal does not clearly explain the goals, and more specifically discuss how this proposal is beneficial to me as an ACX holder and a liquidity provider.\n\n post by TheRealTuna_Across on Oct 31, 2023\n\n TheRealTuna_Across\n\n Looking at the data daily and Across is killing it. I think it makes sense to start tightening up where we hand out ACX, the loss in ACX rewards can be made up for in price growth. Long term holders will still be getting more than 10% APR with the multiplier which is a solid return for a single sided asset with huge upside. The future is bright, let’s not dilute it. Time to also talk more about the fee switch!\n\n post by Kevin_UMA on Oct 31, 2023\n\n Kevin_UMA\n\n gmsteele\n\n It has a direct impact to ACX token holders. You can think of emissions in a couple of ways. 1) as we distribute ACX tokens we are increasing the current supply. That would have a negative impact on price. 2) ACX in the DAO Treasury is effectively controlled by token holders. It’s a real asset that can be used to incentivize activity or compensate people for work. There’s a finite amount of it in our treasury so we want to be careful in utilizing it well for our long term growth and value of ACX\nSo in the short term we may earn less ACX from staking but being careful with how we spend ACX will have major benefits for the long term.\n\n post by gmsteele on Nov 1, 2023\n\n gmsteele\n\n Thanks for the reply. TheRealTuna was helpful to me clarifying that this was only for the ACX pool, I reread the proposal (several times), and at least to me it was a bit confusing because it talked about emissions from multiple pools and I personally just didn’t come away after reading it with a clear understanding of which pools were effected and a knowledge of how this would directly benefit me as an ACX holder. But maybe this was just my limitation.\nBut i’d say one of the behaviors we would like to incentivize is to have people not remove their ACX from the pool and dump it on the market (therefore lowering the price), and being able to stake mine is a big incentivizer to hold and not sell, so decreasing those emissions (on top of recently decreasing the multiplier) doesn’t mean everyone is going to dump, but it decreases the incentive to hold for sure.\nBut maybe that’s the beauty of locking ACX rewards in the pools, no one wants to lose the multiplier, so they keep most of them locked there and out of the ACX pool anyway. I’d say that it’s not increasing the current supply that’s the problem as long as people hold ACX, they don’t become something that can impact the price until a bunch of people try to sell a lot and flood the market.\nBut as someone who is not a huge whale (although what I have in is significant to me), being someone who got involved early, got the airdrop, staked from day 1, and continues to support the project, if the price of ACX goes up the largest benefit to me is to hold as much ACX as I can. As an investor, I expect the people at Across to do great things to build the value of the token, but as an individual investor my goal for how they go about that is not “token supply control,” or to decrease multipliers and emissions to make my personal contribution less valuable.\nJust for me, I personally fail to see how the greatest benefit to me is to decrease the number of ACX I accumulate. And I also fail to see how my having less ACX helps improve the price. Yes, there’s a lot of “ME,” in those statements, and some may look down on that, but i’m an investor, I’m not in ACX for the feel good, right? My goal of having my money tied up in this project is to accumulate ACX and that I believe in an increase in long-term value, there’s a trade in me getting rewards for staking and making my funds available to help the bridge be liquid.\nBut at least in my circumstance a vote for “yes,” is a vote that goes against my personal interest and goals. Obviously by the current votes no one else agrees with me, and that’s ok. But right now, with the loss of multiplier and now a proposed loss in emissions that pool I was in is much less valuable than it was a few weeks ago.\n\n post by TheRealTuna_Across on Nov 2, 2023\n\n TheRealTuna_Across\n\n Something else to consider:\nIf you staked $1,000 in STG back in April it’s worth under $500 today and you would have earned $20 in rewards form trading fees.\nHow do I know this?\nI did exactly this, I am an active airdrop hunter and use a small chunk of my stack to try and get airdrops such as Layer Zero. ACX price has remained much more stable during this time. We have not lost our principal and have been able to build a nice stack of ACX which is heavily undervalued considering we are the most efficient bridge and rapidly gaining market share against airdrop hyped bridges.\nACX fully diluted valuation is currently $55MM vs STG FDV of $458MM, which means if the superior designed bridge catches up then it would be x 8.33 price growth. In my opinion the ceiling for ACX is much higher than STG’s current valuation.\nAll in all what I’m getting at is that we are doing more to reward holders for holding then our competitors and even with this reduction the annual return will still be a nice boost. This is a low risk high reward investment and a small reduction in rewards shouldn’t scare anybody off. We have done very well during the bear market and I expect it will pay off when the bull market strikes.\n\n post by caesarsherrod.eth on Nov 6, 2023\n\n caesarsherrod.eth\n\n This does reduce inflation of the token, likely adding to its dollar value but as a voter & liquidity provider, this is a way for me to continue expressing my views in the DAO.\n50% less for my staked ACX tokens, tokens that we guarantee aren’t being market sold, would reduce my ever increasing voice in the DAO as an LP & voter. I oppose this measure, because it reduces my ability to vote. Of course I could go buy ACX, and I do, but 80% of my stack comes from LPing.\n\n post by Kevin_UMA on Nov 7, 2023\n\n Kevin_UMA\n\nthanks for your comments @gmsteele and @caesarsherrod.eth. I think one thing to note is staking isn’t the only way to accumulate ACX. Buying ACX is one way, but also contributing to the community and earning tokens through grants is another method. So a different way of looking at this is instead of paying people to hold ACX, we can conserve some of that and pay people to do work and contribute. i know both of you are involved in the community so this opens more opportunities for you to earn tokens in this way.\ni think @TheRealTuna_Across echoes a lot of my views and describes things very well. if we are just throwing a lot of ACX to everybody the value of the tokens we hold and our governance power also gets diluted. and this is especially the case for people with less tokens.\n\n 1 month later\n\n Closed on Dec 7, 2023\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 Stop ACX Emissions on ACX LP\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 4\n\n May 2025\n\n Reduce or Reallocate Across ACX LP emissions\n\n Ideas & Feedback\n\n liquidity\n\n Ideas & Feedback\n\n 2\n\n Sep 2023\n\n Reduce ACX emissions for ACX LPs, WBTC LPs and wstETH/ACX LPs\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 11\n\n Aug 2024\n\n ACX Emissions Committee\n\n Proposals\n\n governance-updates\n\n Proposals\n\n Dec 2023\n\n Stop ACX Emissions on wstETH/ACX LP Balancer Pool\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 2\n\n May 2025","tokens":4492,"squid":"spider-09","role":"Bridge Spider","at":1791342350666,"hash":"2a29263429eb0bf5f7b4b6779c7f0bdc64bc64a0"}
{"url":"https://www.paradigm.xyz/writing/timing-advantages-in-onchain-auctions","domain":"paradigm.xyz","title":"Timing Advantages in Onchain Auctions","text":"Timing Advantages in Onchain Auctions Onchain auctions would be a huge unlock for many decentralized applications—NFT launches, liquidation engines, DEX routers, even wallets. If they were possible, then applications or users could use them to capture most of the maximal extractable value (MEV) they create.But in a decentralized protocol, such auctions are very difficult to implement. As previous research has discussed, the ability of block proposers to reorder, censor, or peek at transactions gives them unique power to capture MEV from onchain auctions. While there are many proposed technical solutions to reduce the block proposer’s ability to extract this value, there is one advantage that is particularly difficult to eliminate: latency. Because timing delays can arise naturally in a decentralized setting, one party may be able to submit or cancel transactions later than anyone else.Previous work has shown that if a block proposer can censor or peek at transactions, they can capture up to 100% of the value of a single-block auction. Is the same true of a block proposer who only has a timing advantage?In our new paper, we find that while such a block proposer can extract some value from the auction, these auctions do not degenerate in the same way—they can still be competitive enough to capture some value for the seller. We quantify the profit that a proposer can extract from their timing advantage. We also derive the “timing pressure” on this auction (akin to the incentive for a block proposer to delay their block using timing games).This paper preserves some hope that despite the inevitability of timing advantages, competitive decentralized auctions are still possible and can preserve some value for users. It also motivates work (like multiple concurrent proposers, FOCIL, and threshold encryption) that could add censorship-resistance and privacy to decentralized auctions, as well as work (like leaderless auctions) that tries to reduce timing advantages as much as possible.DetailsTo see how our results work in a little more detail, consider two bidders, Alice and Bob, bidding to fill a UniswapX order. The price of the tokens (and therefore the value of filling the order) evolves in real time. One bidder (Alice) submits a bid early. The other bidder (Bob) moves later and has more up-to-date information (but cannot see Alice’s bid).We show that Bob’s advantage translates into a strictly positive expected profit, even though he doesn’t know Alice’s bid. Alice, despite bidding strategically, earns zero profit in expectation. Importantly, the auction doesn’t completely collapse—value still accrues to the seller—but Bob is able to extract a significant surplus due to his timing edge.How much? Well, let's consider two cases. If the UniswapX order has no reserve price, there’s a straightforward option-theoretic interpretation. Bob’s profit, in expectation, looks exactly like the payoff from a financial derivative: specifically, an exchange option that lets you trade one asset for another. If instead the order does have a reserve, the answer is slightly richer—Bob’s payoff becomes a portfolio of exotic options (which include range options and binary calls). This lens allows us to apply tools from financial mathematics—particularly the Black-Scholes model—to quantify how Bob’s edge depends on the volatility of the underlying asset and his latency advantage. As we described earlier, a particular interest in our paper is to understand this in the context of Multiple Concurrent Proposer (MPC) style blockchain constructions, and how these mitigate/ exacerbate timing pressure relative to current single leader blockchains. To this end, we compare with the case that Bob is a monopolist. When the reserve is zero, Bob’s expected profit in the competitive setting equals the value of an exchange option—he wins when his observed value exceeds the maximum of a random draw (Alice's bid proxy). In contrast, a monopolist Bob—who faces no competition—effectively always wins and earns the entire value of the item, making his profit constant and independent of timing. Thus, in the zero reserve case, only the competitive setting creates timing pressure, which in option-greek terms is the “theta” of the exchange option. However, when the reserve price is positive, the story changes. Now, even the monopolist's profit depends on timing: he only profits if the realized value exceeds the reserve, so waiting longer increases profitability. In this case, both competitive and monopolist Bob benefit from delay, but the competitive Bob still faces stronger timing incentives. Read the full paper here.","tokens":1162,"squid":"spider-04","role":"Research Spider","at":1791342353231,"hash":"9a3bf648e93c94c75ed3c318818db7efcd3f385c"}
{"url":"https://ethresear.ch/t/fork-choice-enforced-inclusion-lists-focil-a-simple-committee-based-inclusion-list-proposal/19870","domain":"ethresear.ch","title":"Fork-Choice enforced Inclusion Lists (FOCIL): A simple committee-based inclusion list proposal - Proof-of-Stake / Block proposer - Ethereum Research","text":"Fork-Choice enforced Inclusion Lists (FOCIL): A simple committee-based inclusion list proposal \n\n Proof-of-StakeBlock proposer\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 14\n min\n\n Jun 2024\n\n 1 / 14\n\n Jun 2024\n\n Sep 2025\n\n post by soispoke on Jun 19, 2024\n\n soispoke\n\n DALL·E 2024-06-05 14.58.08 - A highly realistic illustration of a rock with the Ethereum symbol fossilized into it, set in a cave. The rock should appear weathered and ancient, wi1792×1024 246 KB\n^focil => fossil => protocol ossification\nby Thomas, Barnabé, Francesco and Julian - June 19th, 2024\nThis design came together during a small, week long, in-person gathering in Berlin with RIG and friends to discuss censorship resistance, issuance, and Attester-Proposer-Builder-Consensus-Execution-[insert here] Separation.\nThanks to Luca, Terence, Toni, Ansgar, Alex, Caspar and Anders for discussions, feedback and comments on this proposal.\ntldr\nIn this post, we introduce Fork-Choice enforced Inclusion Lists (FOCIL), a simple committee-based IL design.\nFOCIL is built in three simple steps:\n\nEach slot, a set of validators is selected to become IL committee members. Each member gossips one local inclusion list according to their subjective view of the mempool.\nThe block proposer collects and aggregates available local inclusion lists into a concise aggregate, which is included in its block.\nThe attesters evaluate the quality of the aggregate given their own view of the gossiped local lists to ensure the block proposer accurately reports the available local lists.\n\nThis design ensures a robust and reliable mechanism to uphold Ethereum’s censorship resistance and chain neutrality properties, by guaranteeing timely transaction inclusion.\nIntroduction\nIn an effort to shield the Ethereum validator set from centralizing forces, the right to build blocks has been auctioned off to specialized entities known as builders. Over the past year, this has resulted in a few sophisticated builders dominating the network’s block production. Economies of scale have further entrenched their position, making it increasingly difficult for new entrants to gain significant market share. A direct consequence of oligopolistic block production is a deterioration of the network’s (weak) censorship resistance properties. Today, two of the top three builders are actively filtering out transactions interacting with sanctioned addresses from their blocks. In contrast, 90% of the more decentralized and heterogeneous validator set is not engaging in censorship.\nThis has driven research toward ways that allow validators to impose constraints on builders by force-including transactions in their blocks. These efforts recently culminated in the first practical implementation of forward \\text{ILs}ILs (\\text{fILs}fILs) being considered for inclusion in the upcoming Pectra fork (see design, EIP, and specs here). However, some concerns were raised about the specific mechanism proposed in EIP-7547, leading to its rejection.\nHere, we introduce FOCIL, a simple committee-based design improving upon previous IL mechanisms (Forward ILs, COMIS) or co-created blocks (CBP) and addressing issues related to bribing/extortion attacks, IL equivocation, account abstraction (AA) and incentive incompatibilities. Note also Vitalik’s recent proposal “One-bit-per-attester inclusion lists”, where the committee chosen to build the list is essentially the whole set of attesters.\nDesign\nIn this section, we introduce the core properties of the FOCIL mechanism (see Figure 1.).\nHigh-level overview\nEach slot, a set of validators is randomly selected to become part of an inclusion list (\\text{IL}IL) committee. \\text{IL}IL committee members are responsible for creating local inclusion lists (\\text{IL}_\\text{local}ILlocal) of transactions pending in the public mempool. Local \\text{ILs}ILs are then broadcast over the global topic, and the block producer must include a canonical aggregate (\\text{IL}_\\text{agg}ILagg) of transactions from the collected local \\text{ILs}ILs in its block B𝐵. The quality of \\text{IL}_\\text{agg}ILagg is checked by attesters, and conditions the validity of block B𝐵.\nScreenshot 2024-06-04 at 15.58.511364×742 103 KB\n\nFigure 1. Diagram illustrating the FOCIL mechanism.\n\nMechanism\n\nValidator Selection and Local Inclusion Lists\n\nA set of validators is selected from the beacon committee to become \\text{IL}IL committee members for slot n𝑛. This set is denoted as \\text{IL}_\\text{committee}(n) = \\{ 1, \\dots, m \\}ILcommittee(𝑛) ={1,…,𝑚}, where m𝑚 is the number of \\text{IL}IL committee members.\nEach \\text{IL}IL committee member i \\in \\text{IL}_\\text{committee}(n)𝑖 ∈ILcommittee(𝑛) releases a local \\text{IL}IL, resulting in a set of local \\text{ILs}ILs for slot n𝑛, defined as \\text{IL}_\\text{local}(n) = \\{ \\text{IL}_1, \\dots, \\text{IL}_m \\}ILlocal(𝑛) ={IL1,…,IL𝑚}.\nEach local \\text{IL}_iIL𝑖 contains transactions: \\text{IL}_i = \\{ \\text{tx}^1_i, \\dots, \\text{tx}^{j_i}_i \\}IL𝑖 ={tx1𝑖,…,tx𝑗𝑖𝑖}, where each \\text{tx}tx is represented as \\text{tx} = (\\text{tx}[\\text{From}], \\text{tx}[\\text{Gas Limit}])tx =(tx[From],tx[Gas Limit]), and j_i𝑗𝑖 indicates the number of transactions in \\text{IL}_iIL𝑖. The From field represents the sender’s address, and the Gas Limit field represents the maximum gas consumed by a transaction. This is used to check whether a transaction can be included in a block given the conditional IL property.\n\nBlock Producer’s Role\n\nThe block producer of slot n𝑛, denoted \\text{BP}(n)BP(𝑛), must include an \\text{IL}IL aggregate denoted \\text{IL}_\\text{agg}ILagg and a payload in their block B = (B[\\text{IL}_\\text{agg}], B[\\text{payload}])𝐵 =(𝐵[ILagg],𝐵[payload]).\n\\text{IL}_\\text{agg}ILagg consists of transactions: \\text{IL}_\\text{agg} = \\{ \\text{tx}^1_\\text{agg}, \\dots, \\text{tx}^{t_\\text{agg}}_\\text{agg} \\}ILagg ={tx1agg,…,tx𝑡aggagg} where each transaction \\text{tx}_\\text{agg}txagg is defined as (\\text{tx}_\\text{agg}[\\text{tx}], \\text{tx}_\\text{agg}[\\text{bitlist}])(txagg[tx],txagg[bitlist]), and the \\text{payload}payload must include transactions present in the \\text{IL}_\\text{agg}ILagg.\nThe bitlist \\text{tx}_\\text{agg}[\\text{bitlist}] \\in \\{0, 1\\}^mtxagg[bitlist] ∈{0,1}𝑚 indicates which local $\\text{IL}$s included a given transaction.\nThe function \\text{Agg}Agg takes the set of available local ILs \\text{IL}_\\text{local}(n)ILlocal(𝑛) and outputs a “canonical” aggregate. The proposer aggregate \\text{IL}_\\text{agg}^\\text{proposer}ILproposeragg is included in block B𝐵, and each attester evaluates it quality by comparing it against its own \\text{IL}_\\text{agg}^\\text{attester}ILattesteragg, using the function \\text{Eval}(\\text{IL}_\\text{agg}^\\text{attester}, \\text{IL}_\\text{agg}^\\text{proposer}, Δ) \\in \\{ \\text{True}, \\text{False} \\}Eval(ILattesteragg,ILproposeragg,Δ) ∈{True,False}.\n\nAttesters’ Role\n\nAttesters for slot n𝑛 receive the block B𝐵 and apply a function \\text{Valid}(B)Valid(𝐵) to determine the block validity.\n\\text{Valid}Valid encodes the block validity according to the result of \\text{Eval}Eval, as well as core IL properties such as conditional vs. unconditional.\nHere are some scenarios to illustrate \\text{IL}IL-dependent validity conditions:\n\nIf local \\text{ILs}ILs are made available before deadline d𝑑, but the proposer doesn’t include an \\text{IL}_\\text{agg}^\\text{proposer}ILproposeragg, block B𝐵 is considered invalid.\nIf no local \\text{ILs}ILs are made available before deadline d𝑑, and the proposer doesn’t include an \\text{IL}_\\text{agg}^\\text{proposer}ILproposeragg, block B𝐵 is considered valid.\nIf block B𝐵 is full, local $\\text{IL}$s were available before d𝑑, and the proposer doesn’t include an \\text{IL}_\\text{agg}^\\text{proposer}ILproposeragg, block B𝐵 is still considered valid.\nIf \\text{IL}_\\text{agg}^\\text{proposer}ILproposeragg doesn’t overlap with most of attesters’ \\text{IL}_\\text{agg}^\\text{attester}ILattesteragg according to \\text{Eval}Eval, block B𝐵 is considered invalid.\n\nThe core FOCIL mechanism could be defined as:\n\n\\mathcal{M}_\\text{FOCIL}= (\\text{Agg}, \\text{Eval}, \\text{Valid})\nMFOCIL=(Agg,Eval,Valid)\nTimeline\nThe specific timing is given here as an example, but more research is required to figure out which numbers make sense.\n\nSlot n-1𝑛 −1, t = 6𝑡 =6: The \\text{IL}IL committee releases their local \\text{ILs}ILs, knowing the contents of block n-1𝑛 −1.\nSlot n-1𝑛 −1, t=9𝑡 =9: There is a local \\text{IL}IL freeze deadline d𝑑 after which everyone locks their view of the observed local \\text{ILs}ILs. The proposer broadcast the \\text{IL}_\\text{agg}ILagg over the global topic.\nSlot n𝑛, t=0𝑡 =0: The block producer of slot n𝑛 releases their block B𝐵 which contains both the payload and aggregated \\text{IL}_\\text{agg}ILagg.\nSlot n𝑛, t=4𝑡 =4: The attesters of slot n𝑛 vote on block B𝐵, deciding whether \\text{IL}_\\text{agg}ILagg is “good enough” by comparing the result of computing the \\text{Agg}Agg function over their local view of available local \\text{ILs}ILs (applying \\text{Eval}Eval) and checking if block B𝐵 is \\text{Valid}Valid.\n\nAggregation, Evaluation and Validation Functions\nAs mentioned in the mechanism section, FOCIL relies on three core functions. Each of these needs to be specified to ensure the mechanism fulfils its purpose.\n\nThe \\text{Agg}Agg function is probably the most straightforward to define: Transactions from all collected local \\text{ILs}ILs should be deterministically aggregated and deduplicated to construct \\text{IL}_\\text{agg}ILagg. We let:\n\n\\text{IL}_\\text{local} = \\{\\text{IL}_1, \\text{IL}_2, \\ldots, \\text{IL}_m\\}ILlocal ={IL1,IL2,…,IL𝑚} be the set of local inclusion lists collected from committee members m𝑚.\nEach \\text{IL}_i = \\{\\text{tx}_i^1, \\text{tx}_i^2, \\ldots, \\text{tx}_i^{t_i}\\}IL𝑖 ={tx1𝑖,tx2𝑖,…,tx𝑡𝑖𝑖}\nbe the transactions in the local inclusion list of the i𝑖-th committee member.\nEach transaction \\text{tx}tx be defined by (\\text{hash}, \\text{sender}, \\text{nonce})(hash,sender,nonce)\n\n\\text{Agg}(\\text{IL}_\\text{local})Agg(ILlocal) can be thus defined as:\n\n\\text{Agg}(\\text{IL}_\\text{local}) = {\\text{tx} | \\text{tx} \\in \\bigcup_{i \\in m} \\text{tx}_{i} }\nAgg(ILlocal)=tx|tx∈⋃𝑖∈𝑚tx𝑖\n\nThe \\text{Eval}Eval function is used by each slot n𝑛 attester to assess the quality of the \\text{IL}_\\text{agg}ILagg included in block B𝐵. Each attester calculates the \\text{Agg}Agg function over all local \\text{ILs}ILs they have observed in their view and then compares their generated \\text{IL}_\\text{agg}^\\text{attester}ILattesteragg to the one included by the proposer \\text{IL}_\\text{agg}^\\text{proposer}ILproposeragg. The \\text{Eval}Eval function can then be defined so that the proposer’s IL_{\\text{agg}}^{\\text{proposer}}𝐼𝐿proposeragg is valid if it includes a sufficient proportion of transactions observed by the attesters, as defined by the parameter ΔΔ:\n\n\\text{Eval}(IL_{\\text{agg}}^{\\text{attester}}, IL_{\\text{agg}}^{\\text{proposer}}, \\Delta) = \n\\begin{cases} \n\\text{True} & \\text{if } \\frac{|IL_{\\text{agg}}^{\\text{attester}} \\cap IL_{\\text{agg}}^{\\text{proposer}}|}{|IL_{\\text{agg}}^{\\text{attester}}|} \\geq \\Delta \\\\\n\\text{False} & \\text{otherwise}\n\\end{cases}\nEval(𝐼𝐿attesteragg,𝐼𝐿proposeragg,Δ)={Trueif |𝐼𝐿attesteragg∩𝐼𝐿proposeragg||𝐼𝐿attesteragg|≥ΔFalseotherwise\nNote that the \\text{Eval}Eval function, and especially its parameter ΔΔ, will determine the trade-off between (1) the quality of the \\text{IL}_\\text{agg}^\\text{proposer}ILproposeragg and the agency we are willing to give to proposers, and (2) liveness, as we might see an increase in missed slots if the criteria are set too strictly.\n\nThe \\text{Valid}Valid function encodes whether the \\text{IL}_\\text{agg}ILagg conforms to pre-defined core \\text{IL}IL properties, such as:\n\nConditional vs. Unconditional: Should the proposer include as many \\text{IL}IL transactions in the block as possible as long as there is space left, or is there dedicated block space reserved for \\text{IL}IL transactions?\nWhere-in-block: Where should \\text{IL}IL transactions be included in the block? Should they be placed anywhere, at the top of the block, or at the end of the block?\nExpiry: How long do transactions remain in the \\text{IL}IL once they have been included? What happens if a slot is skipped?\n\nMore rules\nIn the following section, we introduce other rules that could be added to the core mechanism to specify:\n\nHow users should pay for having their transactions included (\\text{Payment}Payment)\nHow rewards can be distributed across FOCIL participants (\\text{Reward}Reward)\nHow local \\text{ILs}ILs are constructed (\\text{Inclusion}Inclusion)\nInteractions between \\text{IL}IL and payload transactions (\\text{Priority}Priority).\n\nUser Bidding, \\text{Payment}Payment and \\text{Reward}Reward rules\n\nUsers place bids based on the value they assign to having their transactions included in block B𝐵. They need to take into consideration the FOCIL mechanism \\mathcal{M}_\\text{FOCIL}MFOCIL, but also how the EIP-1559 mechanism works to set their base fees, denoted \\mathcal{M}_\\text{1559}M1559. For instance, a user t𝑡 makes a bid b^t(v^t, \\mathcal{M}_\\text{FOCIL},\\mathcal{M}_\\text{1559}) = (\\delta^t, f^t)𝑏𝑡(𝑣𝑡,MFOCIL,M1559) =(𝛿𝑡,𝑓𝑡), where \\delta^t𝛿𝑡 is the maximum priority fee and f^t𝑓𝑡 is the maximum total fee (i.e., base fee r𝑟 + priority fee \\delta^t𝛿𝑡).\nThe vector of bids from all users is denoted as \\mathbf{b} = (b^1, b^2, \\dots, b^T)𝐛 =(𝑏1,𝑏2,…,𝑏𝑇), where each b^t𝑏𝑡 represents the bid from user t𝑡.\nThe \\text{Payment}Payment rule p(\\mathbf{b}) = (p_0(\\mathbf{b}), p_1(\\mathbf{b}), \\dots, p_t(\\mathbf{b}), \\dots, p_m(\\mathbf{b}))𝑝(𝐛) =(𝑝0(𝐛),𝑝1(𝐛),…,𝑝𝑡(𝐛),…,𝑝𝑚(𝐛)) ensures that users pay no more than their priority fee \\hat{\\delta}^t = \\min(\\delta^t, f^t - r)ˆ𝛿𝑡 =min(𝛿𝑡,𝑓𝑡 −𝑟). Here, p_0(\\mathbf{b}𝑝0(𝐛) represents the payment to the block producer, and p_t(\\mathbf{b}𝑝𝑡(𝐛) represents the payment made by user t𝑡 to all other \\text{IL}IL committee members, where the set of users has size m𝑚 and the block producer is indexed by 0.\n\nThe \\text{Payment}Payment rule defined above is meant to give a general view of how the value paid by users’ transactions can be redistributed across FOCIL participants (e.g., \\text{IL}IL committee members, block producer) to incentivize behavior that is considered good for the network, in this case preserving its censorship-resistant properties. Incentivizing \\text{IL}IL committee members for including transactions strengthens the robustness of the mechanism by increasing the cost of censorship, or the amount a censoring party would have to pay for \\text{IL}IL committee members to exclude transactions from their local \\text{ILs}ILs. Delving into the specifics of how the builder and \\text{IL}IL committee members should be rewarded is beyond the scope of this post as distributing rewards in an incentive-compatible way, especially during congestion, gets quite complex.\nHowever, here are three high-level options to consider:\n\nOption 1: All transaction priority fees go to the builder, and \\text{IL}IL committee members are just not incentivized to include transactions in their local \\text{ILs}ILs. This simple option doesn’t require any changes to the existing fee market, but entirely relies on altruism from \\text{IL}IL committee members. We could even consider an opt-in version of FOCIL, where validators can choose to be part of a list that may be elected to become \\text{IL}IL committee members and participate in building \\text{ILs}ILs altruistically. However, it wouldn’t increase the cost of censorship nor would it make it very appealing for validators to participate in the mechanism. This could also lead to out-of-band payments from users wanted to have their transactions included in local \\text{ILs}ILs.\nOption 2: Priority fees from transactions included in the block are given to the \\text{IL}IL committee members. To distribute rewards among members, we could implement a weighted incentive system by defining a \\text{Reward}Reward rule to calculate and distribute rewards for each member, considering the quantity (i.e., count) and uniqueness of transactions included in their local lists (see Appendix 1 of the COMIS post for more details). If transactions are not part of the \\text{IL}_\\text{agg}ILagg, priority fees go to the builder. However, this approach could be problematic during congestion periods with the conditional \\text{IL}IL property, as builders might be incentivized to fill the block with transactions that are not in the \\text{IL}_\\text{agg}ILagg, even if \\text{IL}IL transactions have higher priority fees. To address this, we might need to design a mechanism that redirects priority fees to the builder during congestion. However, the practical implementation and potential secondary effects need further investigation.\nOption 3: A third option is to introduce a new, separate inclusion fee that always go to IL committee members while priority fees always go to the builder. This would likely address the concerns of Option 2 related to congestion but would introduce a whole other variable that users need to set. A useful distinction between Option 2 and Option 3 is whether the complexity is pushed upon the IL committee members or the end users.\n\nAnother interesting question to explore is the impact of fee distribution across \\text{IL}IL committee members on mechanisms like MEV-burn. Options 2 and 3 would effectively “reduce the burn” and produce a similar effect as MEV-smoothing, but on a smaller scale limited to the size of the \\text{IL}IL committee (h/t Anders).\n\\text{Inclusion}Inclusion Rule\nThe \\text{Inclusion}Inclusion rule determines the criteria according to which \\text{IL}IL committee members should build their local \\text{ILs}ILs. In FOCIL, we define it with the premise that IL committee members will try to maximize their rewards. Assuming Option 2 for the \\text{Payment}Payment rule, the \\text{Inclusion}Inclusion rule could be to include all transactions seen in the public mempool, ordered by priority fees.\n\\text{Priority}Priority Rule\nWe assume the block will be made of two components: a payload and an \\text{IL}_\\text{agg}ILagg included by the proposer to impose constraints on transactions that need to be included in the builder’s payload. Imposing constraints to the block payload via the \\text{IL}_\\text{agg}ILagg thus requires a priority rule to determine what happens during congestion. Generally, the priority rule in FOCIL states that transactions in the \\text{IL}_\\text{agg}ILagg might be excluded if the block can be filled with the builder’s payload transactions. In other words, the block will still be valid even if some transactions in the \\text{IL}_\\text{agg}ILagg are not included, as long as the block is completely full (i.e., the 30 M gas limit is reached).\nNote: Rules are not set in stone and should be interpreted as candidates for FOCIL. Rules also don’t necessarily have to be made explicit. For instance, we can define the \\text{Reward}Reward such that the dominant strategy of the \\text{IL}IL committee is to adhere to the \\text{Inclusion}Inclusion rule without any kind of enforcement by the protocol.\nImprovements and Mitigations\nIn this section, we discuss improvements over previous \\text{IL}IL proposals, focusing on simplification and addressing specific implementation concerns.\nCommitment attacks\nOne of the main differences between FOCIL and the forward IL (\\text{fIL}fIL) design proposed in EIP-7547 is that FOCIL relies on a committee of multiple validators, rather than a single proposer, to construct and broadcast the \\text{IL}IL. This approach imposes stricter constraints on creating a “good” aggregate list and significantly reduces the surface for bribery attacks. Instead of targeting a single party to influence the exclusion of transactions from the \\text{IL}IL, attackers would now need to bribe an entire \\text{IL}IL committee (e.g., 256 members), substantially increasing the cost of such attacks. Previous designs (e.g., COMIS and anon-IL), also involved multiple parties in building inclusion lists but still relied on an aggregator to collect, aggregate, and deduplicate local \\text{ILs}ILs. In FOCIL, the entire set of attesters now participates in enforcing and ensuring the quality of the \\text{IL}IL included in the proposer’s block, thus removing single-party dependency other than the proposer. Additionally, it is worth noting that a censoring proposer would have to forego all consensus and execution layer rewards and cause a missed slot to avoid including transactions in the \\text{IL}IL.\nSplitting attacks and IL equivocation\nAnother concern with \\text{fILs}fILs focused on possible “splitting” attacks using \\text{ILs}ILs. Splitting attacks like timed release or “equivocation” occur when malicious participants attempt to divide the honest view of the network to stall consensus. On Ethereum, a validator equivocating by contradicting something it previously advertised to the network is a slashable offense. If there is evidence of the offence being included in a beacon chain block, the malicious validator gets ejected from the validator set. Quick reminder that in the EIP-7547 design, the proposer for slot n-1𝑛 −1 is responsible for making the \\text{IL}IL to constrain proposer n𝑛, and can broadcast multiple \\text{ILs}ILs (check out the No-free lunch post to see why, and how it relates to solving the free data availability problem). This means a malicious proposer could split the honest view of the network through \\text{IL}IL equivocation without being slashed. However, this is not a concern with FOCIL, since \\text{IL}_\\text{agg}ILagg has to be part of proposer $n$’s block. An \\text{IL}IL equivocation would thus be equivalent to a block equivocation, which is a known, slashable offense from the protocol’s perspective.\nIncentives incompatibilities\nPrevious \\text{fILs}fILs proposals did not consider incentivizing the \\text{IL}IL proposer(s) for including “good” transactions. Relying on altruistic behavior might be fine, but there is always the risk that only very few validators will choose to participate in the mechanism if there is no incentive to gain. There is a strong argument to be made that the adoption of any \\text{IL}IL mechanism might be very low if validators risk being flagged as either non-censoring or censoring entities by revealing their preferences (see the Anonymous Inclusion Lists post), and if they are not rewarded for contributing to preserving the network’s censorship resistance properties. In FOCIL, we consider mechanisms to distribute rewards across \\text{IL}IL committee members and mention two options (Option 2 and Option 3 in the \\text{Payment}Payment rule section) for sharing transaction fees based on the quantity (i.e., count) and uniqueness of transactions included in their local lists. We hope to continue working in this direction and to find incentive-compatible ways to increase the costs of censorship.\nSame-slot censorship resistance\nBy having FOCIL run in parallel with block building during slot n-1𝑛 −1, we can impose constraints on the block by including transactions submitted during the same slot in local \\text{ILs}ILs. This is a strict improvement over \\text{fILs}fILs designs, where the forward property imposes a 1-slot delay on \\text{IL}IL transactions. This property is particularly useful for time-sensitive transactions that might be censored for MEV reasons (see Censorship resistance in onchain auctions paper). Admittedly, the mechanism is not exactly real-time because we still need to impose the “local \\text{IL}IL freeze” deadline d𝑑 so block producers have time to consider \\text{IL}_\\text{agg}ILagg transactions before proposing their block.\n\\text{IL}IL conditionality\nA core property of \\text{ILs}ILs is their conditionality, which determines whether ILs should have dedicated block space for their transactions (unconditional) or share block space with the payload and only being included if the block isn’t full (conditional). For FOCIL, we’re leaning towards using conditional \\text{ILs}ILs for a couple of reasons. Firstly, it might generally be best to give sophisticated entities like builders the maximum amount of freedom in organizing block space as long as they include \\text{IL}IL transactions. Allowing them to order transactions and fill blocks as they prefer, rather than imposing too many restrictions on their action space, reduces the risk of them using side channels to circumvent overly rigid mechanisms. Specifically, the unconditional property just couldn’t really be enforced effectively with FOCIL, since builders wanting to use \\text{IL}IL dedicated block space could simply “buy up \\text{IL}IL committee seats” from the elected validators to include their transactions via local \\text{ILs}ILs. Another reason to opt for conditional \\text{ILs}ILs is the flexibility in the size of the list. With unconditional ILs, an added block space must strictly set an arbitrary maximum \\text{IL}IL gas limit (e.g., 3M gas). In contrast, conditional \\text{ILs}ILs allow for a much more flexible \\text{IL}IL size, depending on the remaining space in the block. The known tradeoff with conditional \\text{ILs}ILs is block stuffing: censoring builders might fill their blocks up to the gas limit to keep \\text{IL}IL transactions out. More research is needed to determine the sustainability of block stuffing, as consecutive full blocks exponentially increase base fees and the overall cost of this strategy.\nAccount Abstraction accounting\nIn previous proposals, \\text{IL}IL summaries were constructed as structures to constrain blocks without committing to specific raw transactions. Each \\text{IL}IL summary —or \\text{IL}_\\text{agg}ILagg for FOCIL— entry represents a transaction by including the following fields: From and Gas Limit. Satisfying an entry in the IL𝐼𝐿 summary requires that at least some transaction from the From address has been executed, unless the remaining gas in the block is less than Gas Limit . The idea is simple: if a transaction was previously valid and had a sufficiently high basefee, the only two things preventing its inclusion are the lack of sufficient gas in the block or its invalidation, which would require a transaction from the same sender to have been previously executed. Here we rely on a property of Ethereum EOAs: the nonce and balance of an EOA determine the validity of any transaction originating from that EOA, and can only be modified by such a transaction.\nHowever, even limited forms of Account Abstraction that have been considered for inclusion in Electra (e.g., EIP-3074 or EIP-7702) allow a transaction to trigger a change in an EOA’s balance, without originating from that EOA. This raised concerns regarding previous \\text{fIL}fIL proposals, as proposer n𝑛 is not aware of what is included in builder $n$’s payload when proposing its \\text{IL}IL. This could lead to a scenario where proposer n𝑛 includes a transaction txn_A𝑡𝑥𝑛𝐴 from address A𝐴 in the \\text{IL}IL, while builder n𝑛 includes an EIP-7702 transaction txn_B𝑡𝑥𝑛𝐵, originating from address B𝐵 but sweeping out all the ETH from address A𝐴, and thus invalidating txn_A𝑡𝑥𝑛𝐴. Consequently, builder n+1𝑛 +1 would no longer be able to include txn_A𝑡𝑥𝑛𝐴, though no other transaction from address A𝐴 has been previously executed. In other words, the IL𝐼𝐿 summary would be unsatisfiable.\nIn FOCIL, one simplification is that the constraints from the \\text{IL}_\\text{agg}ILagg apply to the block that is being built concurrently. This means a transaction in the \\text{IL}_\\text{agg}ILagg can’t be invalidated because of a transaction in the previous block, as it can in \\text{fIL}fIL designs. In other words, we do not need to worry about what happened in the previous block in order to check for satisfaction of the \\text{IL}_\\text{agg}ILagg. However, a builder could still insert EIP-7702 transactions in its payload that invalidate \\text{IL}_\\text{agg}ILagg transactions. To handle this case, we can do the following when validating a block:\n\nBefore executing the block’s transactions, we store nonce and balance of all From addresses that appear in the \\text{IL}_\\text{agg}ILagg.\nAfter execution, we check the nonce and balance of all From addresses from the \\text{IL}_\\text{agg}ILagg again, and for each (From, Gas Limit) pair in the \\text{IL}_\\text{agg}ILagg we require that either the nonce or the balance has changed, or the Gas Limit is more than the remaining gas.\n\nIf the nonce has changed, some transaction from that address has been executed. If the balance has changed but the nonce has not, some AA transaction has touched that address. In either case, that address has transacted in the block, and the entry is satisfied.\nNote: With \"full” AA, transactions could have validity that depends on arbitrary state (e.g., the price changing in a Uniswap pool). In such cases, relying on a reduced form of transactions (i.e., entries with From and Gas limit fields) is insufficient, as the full validation logic of the transaction is needed. Due to the free data-availability problem, putting raw transactions on-chain is not an option. Instead, attesters could check this locally since they need to construct their own \\text{IL}_\\text{agg}^\\text{attester}ILattesteragg and could, therefore, evaluate the full validation logic. This allows them to verify if the transaction has been invalidated and if its inclusion should be enforced. However, attesters might have \\text{IL}_\\text{agg}^\\text{attester}\\text{s}ILattesteraggs that contain different transactions from the same From address, leading to a situation where one transaction might be invalidated while another is not. This would result in split views and potential attacks\n\n Censorship Insurance Markets for BRAID\n\n FOCIL CL & EL workflow\n\n AUCIL: An Auction-Based Inclusion List Design for Enhanced Censorship Resistance on Ethereum\n\n MEV resistant dynamic pricing auction of execution proposal rights\n\n FOCIL Resource Design Considerations\n\n 5\n\n 2\n\n 2\n\n read \n\n 14\n min\n\n post by The-CTra1n on Jun 19, 2024\n\n The-CTra1n\n\n The article mentions the CBP proposal, which reads quite similar to FOCIL. What are the main differences?\n\n post by Pintail on Jun 20, 2024\n\n Pintail\n\n I like this proposal - particularly that it works within the slot and utilises attesters.\nBut isn’t there a problem that the Eval function’s tolerance parameter Delta will always permit censorship of a small number of transactions? If the number of potentially censored transactions is small in the first place, won’t this render the whole scheme ineffective?\n\n Mechan-stein (alt. Franken-ism)\n\n post by soispoke on Jun 20, 2024\n\n soispoke\n\n Thanks, yeah the delta parameter is definitely important: you’re trading off liveness vs being able to censor a (very) small fraction of transactions included in the IL.\nIn my opinion it’s an acceptable trade-off. Playing around with this leeway is not necessarily easy:\n\nIt’s impossible to know exactly what attesters will include in their aggregates, and how much room you have as a proposer to exclude some transactions.\nThe risk of having your block invalidated in case you exclude transactions and end up not satisfying the overlap condition is high.\nWe also have to keep in mind that every slot, a new proposer and a new committee is elected, so keeping a transaction out for consecutive slots seems difficult.\n\n Mechan-stein (alt. Franken-ism)\n\n post by barnabe on Jun 20, 2024\n\n barnabe\n\nI can provide a “grammar” to differentiate the many combinations:\n\nIn the simplest case, you have a single proposer P delivering a block B(P):\n\n[B(P)]\n\nIf you have some inclusion list IL and an enforcement mechanism => (e.g., conditional vs unconditional, ToB vs BoB vs unspecified etc.), the delivered block must respect the IL enforcement conditions:\n\nIL => [B(P)]\n\nIn CBP, you have a payload delivered by two partial proposers (P1 and P2), so the block is obtained from concatenating the two partial blocks:\n\n[B(P1); B(P2)]\n\nIn FOCIL, there are m𝑚 committee members each producing a local IL (yielding IL1, IL2, … ILm), which are then aggregated to the global IL, which applies to the block delivered by a single proposer P. So:\n\n(IL1, IL2, …, ILm) → IL => [B(P)]\n\nA risk with CBP is that the multiple proposers deliver uncoordinated partial payloads, meaning the transactions of B(P1) have precedence over the transactions of B(P2), which may revert based on what goes on in B(P1). With FOCIL, the single proposer P has full knowledge of IL and controls fully the constrained state transition function (constrained by the IL enforcement mechanism).\nAs an additional note, we could also dream up of FOCIL + CBP:\n\n(IL1, IL2, …, ILm) → IL => [B(P1); B(P2)]\n\nBut this feels hard, because who should be on the hook for satisfying the IL? If P1 believes P2 will satisfy the IL, and P2 believes P1 will, then there may be invalid blocks delivered in the case where the IL enforcement is agnostic with respect to the location of the IL transactions. There are cases where it’s not an issue however, when e.g., the IL enforcement requires all transactions of the (ordered or unordered) IL to be placed in the ToB, then we could require P1 to deliver B(P1) = [IL; *], where they can fill up * with whatever they like.\n\n Mechan-stein (alt. Franken-ism)\n\n post by The-CTra1n on Jun 20, 2024\n\n The-CTra1n\n\n Agree with everything you’ve said there, especially in regard to the specific CBP post. In my mind, I thought it was more generalized and closer to the original arxiv paper from @MaxResnick and co.\nWhen I read FOCIL, I see it as a generalization/extension of the concurrent block proposer idea. Each IL “proposer”, the validators, is proposing m mini-blocks=single transactions. FOCIL provides a neat protocol to merge the blocks utilizing a super-proposer, the final block producer, to merge the mini-blocks.\nFWIW, I like the direction!\n\n post by Pintail on Jun 20, 2024\n\n Pintail\n\n soispoke\n\n Would it be worth considering a slightly more sophisticated Eval function which takes into account the proportion of the committee which included the tx in their IL? For example of the whole committee includes it but the builder leaves it out it may be safe to assume the proposer/builder is censoring and there should be a penalty. If only a small proportion of validators include a transaction it may be that it was received late and therefore legitimately might have been missed by the proposer/builder.\nOf course any weighting scheme built on this principle would need to be resilient to some proportion of the IL committee also censoring. But maybe if the IL committee uses ring signatures or some similar scheme then they could deniably include transactions, potentially reducing the pressure to censor.\n\n post by soispoke on Jun 21, 2024\n\n soispoke\n\n It’s definitely worth considering!\nI think this definitely points to “figuring out a good incentives mechanism” part of the design.There is an interesting dynamic at play here, between rewarding IL committee members for including all transactions they see (e.g., getting more rewards if they include a transaction no one else included) and rewarding the block producer based on evaluating the difference between transactions in its IL aggregate and those in local ILs. Happy to discuss this further, I think we mentioned it in the post and to me, the incentives part definitely seems to require more research. I remember @Julian had thoughts about something very close to what you’re describing for the Eval𝐸𝑣𝑎𝑙 function too.\nAbout ring signatures/plausible deniability, this is a parallel, very interesting research topic we’re working on. I recommend checking out our anon-IL design in which we specifically use ring signatures. But this needs a lot more research, and my personal opinion is that it’s quite unlikely we’ll have an efficient/robust mechanism for this in the short-term.\n\n 10 days later\n\n post by Kapol on Jul 1, 2024\n\n Kapol\n\nThese two sound contradictory to me. If you can simply do something, then the attack surface is not significantly reduced.\n\nI have an issue with how Eval𝐸𝑣𝑎𝑙 is constructed. Unless I am mistaken, the proposer is disincentivized from including additional transactions in IL_{agg}^{proposer}𝐼𝐿𝑝𝑟𝑜𝑝𝑜𝑠𝑒𝑟𝑎𝑔𝑔 because that would reduce the value compared against \\DeltaΔ.\n\n post by soispoke on Jul 1, 2024\n\n soispoke\n\n Thanks for your feedback!\n\nThere is a major difference between trying to include transactions and trying to exclude transactions from the IL. To include transactions, you can “simply” buy up IL committee seats. But to exclude a transaction, you actually need to bribe every single committee member to make sure none of them includes it.\n\nYou’re right, thanks for catching this. It should be redefined to ensure that the proposer’s IL aggregate is valid if it includes a sufficient proportion of transactions observed by the attesters, as defined by the parameter ΔΔ:\n\n\\text{Eval}(IL_{\\text{attester}}^{\\text{agg}}, IL_{\\text{proposer}}^{\\text{agg}}, \\Delta) = \n\\begin{cases} \n\\text{True} & \\text{if } \\frac{|IL_{\\text{attester}}^{\\text{agg}} \\cap IL_{\\text{proposer}}^{\\text{agg}}|}{|IL_{\\text{attester}}^{\\text{agg}}|} \\geq \\Delta \\\\\n\\text{False} & \\text{otherwise}\n\\end{cases}\nEval(𝐼𝐿aggattester,𝐼𝐿aggproposer,Δ)={Trueif |𝐼𝐿aggattester∩𝐼𝐿aggproposer||𝐼𝐿aggattester|≥ΔFalseotherwise\nEdit: the main text was modified accordingly\n\n 2 months later\n\n post by saguillo2000 on Aug 16, 2024\n\n saguillo2000\n\n Interesting proposal!\nHowever, one of my primary concerns is the method by which the committee is randomly selected from the validator set. Is the selection process based on the stake each validator holds, or does it follow a lottery-like system similar to the Execution Tickets mechanism? Additionally, if the selection is truly random, who is responsible for generating this randomness? The entity responsible for this could potentially wield significant power and may be susceptible to bribery or other forms of influence during the selection process of the committee.\n\n post by soispoke on Aug 19, 2024\n\n soispoke\n\n Thanks @saguillo2000!\nIn this proposal, we assume validators will get selected to be part of the IL committee randomly and independently of their stake.\nIt would use RANDAO (see Upgrading Ethereum | 2.9.2 Randomness) as a source of randomness, which is already used to select proposers and assign validators to committees. It is known to be bias-able to some extent, but it’s been studied extensively and would be easy to detect.\n\n 1 year later\n\n post by ameensol on Aug 22, 2025\n\n ameensol\n\n Yea, so I learned about this today. I think it’s a bad idea and I don’t think we should do it.\n\n 1 month later\n\n post by yigityektin on Sep 24, 2025\n\n yigityektin\n\n I just published an article under the name of EIPsforNerds about FOCIL. All feedbacks are welcome.\nhttps://mirror.xyz/eipsfornerds.eth/e_4f-3Cgdc6mS97eF-h1t1LzaJmYh8nfQVLzn7TwX7A\n\n Powered by Discourse","tokens":9775,"squid":"spider-04","role":"Research Spider","at":1791342368717,"hash":"d93e735a32c54a93119f32d7de346de23178ec3f"}
{"url":"https://forum.across.to/t/reduce-or-reallocate-across-acx-lp-emissions/1703","domain":"forum.across.to","title":"Reduce or Reallocate Across ACX LP emissions - Ideas & Feedback - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n Reduce or Reallocate Across ACX LP emissions \n\n Ideas & Feedback\n\n liquidity\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Aug 2023\n\n 1 / 3\n\n Aug 2023\n\n Sep 2023\n\n post by Kevin_UMA on Aug 22, 2023\n\n Kevin_UMA\n\n Across ACX LPs staked in reward locking currently earn 7.84% to 26.7% driven by base emissions of 20,000 ACX per day.\nThis is a significant amount given there is currently very little ACX being bridged. The emissions were initially set high to get ACX airdrop recipients to not immediately sell their tokens and to get them familiar with the reward locking mechanism. Given it’s been 9 months since the launch of the token the community should consider reducing these emissions.\nIn addition, incentives will be added to enhance liquidity on the ACX token. The community voted to end bribes on Aura and instead incentivize the Balancer pool with Reward Locking and also bribe on Velodrome. The generally idle ACX in the Across LP would be better served supporting these pools instead. In total the DAO would be spending 38k to 52k ACX per day on ACX related pools.\n20k ACX / day - Across LP\n7k -21k / day - wstETH/ACX Balancer pool (1 to 3x multiplier)\n11k/day - Velodrome pool (75k per week)\nTotal = 38k to 52k ACX / day\nThis is in comparison to the current base emissions for other assets on Across:\n~50,000 ACX per day for Across ETH LP tokens\n~50,000 ACX per day for Across USDC LP tokens\n~5,000 ACX per day for Across DAI LP tokens\n~5,000 ACX per day for Across WBTC LP tokens\nDiscussion: How much should these emissions be reduced? Should we reallocate the emissions to other pools? Some options to consider:\n\nCut emissions by 50% and don’t reallocate\nMove emissions to lower volume assets like DAI or WBTC\nMove emissions to higher volume assets like ETH or USDC\nMove some portion to temporarily create interest for smaller tokens like POOL and SNX\nAdd more incentives to ACX liquidity\n\nWhat do people think?\n\n Reduce ACX emissions for Across ACX LPs\n\n post by Clayton_UMA on Aug 22, 2023\n\n Clayton_UMA\n\n Thanks for compiling all the details in one location like this, it’s very helpful.\n\nMove some portion to temporarily create interest for smaller tokens like POOL and SNX\n\nI’m curious how beneficial these teams would find this? And how attractive it would be from a marketing perspective? If we can offer some amount of subsidized rate to onboard your token, perhaps as part of the deal for them to lend RL funds for a relayer or something?\n\n 19 days later\n\n post by Ryan_UMA on Sep 11, 2023\n\n Ryan_UMA\n\n Thanks for this proposal.\nI do agree the ACX pool is overweighted, and Across could benefit by attracting additional liquidity for higher volume / high utilization pools. I would be in favor of a reduction (but not elimination) of incentives for ACX pool with reallocation to USDC and WETH.\nHowever, we need to evaluate how something like this would interact with the proposal to reduce max multiplier while increasing base emissions by 50%.\nWith the ultimate goal being to get the most out of ACX incentives (in terms of user and liquidity acquisition), I think we should move forward with the proposal to reduce max multiplier while increasing base emissions by 50% first and then see the response, and then evaluate if we should move forward with this proposal in the future.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Reduce ACX emissions for Across ACX LPs\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 8\n\n Nov 2023\n\n Stop ACX Emissions on ACX LP\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 4\n\n May 2025\n\n Reduce ACX emissions for ACX LPs, WBTC LPs and wstETH/ACX LPs\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 11\n\n Aug 2024\n\n Stop ACX Emissions on wstETH/ACX LP Balancer Pool\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 2\n\n May 2025\n\n ACX Emissions Committee\n\n Proposals\n\n governance-updates\n\n Proposals\n\n Dec 2023","tokens":2468,"squid":"spider-09","role":"Bridge Spider","at":1791342371859,"hash":"64057d143284a2985dde7e05cf9a053990311edb"}
{"url":"https://eips.ethereum.org/EIPS/eip-3529","domain":"eips.ethereum.org","title":"EIP-3529: Reduction in refunds","text":"🎉 Final\n\n Standards Track: Core\n\n EIP-3529: Reduction in refunds\n\n Authors\n Vitalik Buterin (@vbuterin), Martin Swende (@holiman)\n\n Created\n 2021-04-22\n\n Requires\n\n EIP-2200, \n\n EIP-2929, \n\n EIP-2930\n\n Simple Summary\n\nRemove gas refunds for SELFDESTRUCT, and reduce gas refunds for SSTORE to a lower level where the refunds are still substantial, but they are no longer high enough for current “exploits” of the refund mechanism to be viable.\n\n Motivation\n\nGas refunds for SSTORE and SELFDESTRUCT were originally introduced to motivate application developers to write applications that practice “good state hygiene”, clearing storage slots and contracts that are no longer needed. However, the benefits of this technique have proven to be far lower than anticipated, and gas refunds have had multiple unexpected harmful consequences:\n\n Refunds give rise to GasToken. GasToken has benefits in moving gas space from low-fee periods to high-fee periods, but it also has downsides to the network, particularly in exacerbating state size (as state slots are effectively used as a “battery” to save up gas) and inefficiently clogging blockchain gas usage\n Refunds increase block size variance. The theoretical maximum amount of actual gas consumed in a block is nearly twice the on-paper gas limit (as refunds add gas space for subsequent transactions in a block, though refunds are capped at 50% of a transaction’s gas used). This is not fatal, but is still undesirable, especially given that refunds can be used to maintain 2x usage spikes for far longer than EIP-1559 can.\n\n Specification\n\n Parameters\n\n Constant\n Value\n\n FORK_BLOCK\n TBD\n\n MAX_REFUND_QUOTIENT\n 5\n\nFor blocks where block.number >= FORK_BLOCK, the following changes apply.\n\n Remove the SELFDESTRUCT refund.\n Replace SSTORE_CLEARS_SCHEDULE (as defined in EIP-2200) with SSTORE_RESET_GAS + ACCESS_LIST_STORAGE_KEY_COST (4,800 gas as of EIP-2929 + EIP-2930)\n Reduce the max gas refunded after a transaction to gas_used // MAX_REFUND_QUOTIENT\n\nRemark: Previously max gas refunded was defined as gas_used // 2. Here we\nname the constant 2 as MAX_REFUND_QUOTIENT and change its value to 5.\n\n Rationale\n\nIn EIP-2200, three cases for refunds were introduced:\n\n If the original value is nonzero, and the new value is zero, add SSTORE_CLEARS_SCHEDULE (currently 15,000) gas to the refund counter\n If the original value is zero, the current value is nonzero, and the new value is zero, add SSTORE_SET_GAS - SLOAD_GAS (currently 19,900) gas to the refund counter\n If the original value is nonzero, the current value is a different nonzero value, and the new value equals the original value, add SSTORE_RESET_GAS - SLOAD_GAS (currently 4,900) gas to the refund counter\n\nOf these three, only (1) enables gastokens and allows a block to expend more gas on execution than the block gas limit. (2) does not have this property, because for the 19,900 refund to be obtained, the same storage slot must have been changed from zero to nonzero previously, costing 20,000 gas. The inability to obtain gas from clearing one storage slot and use it to edit another storage slot means that it cannot be used for gas tokens. Additionally, obtaining the refund requires reverting the effect of the storage write and expansion, so the refunded gas does not contribute to a client’s load in processing a block. (3) behaves similarly: the 4,900 refund can only be obtained when 5,000 gas had previously been spent on the same storage slot.\n\nThis EIP deals with case (1). We can establish under what conditions a gastoken is nonviable (ie. you cannot get more gas out of a storage slot than you put in) by using a similar “pairing” argument, mapping each refund to a previous expenditure in the same transaction on the same storage slot. lf a storage slot is changed to zero when its original value is nonzero, there are two possibilities:\n\n This could be the first time that the storage slot is set to zero. In this case, we can pair this event with the SSTORE_RESET_GAS + ACCESS_LIST_STORAGE_KEY_COST minimum cost of reading and editing the storage slot for the first time.\n This could be the second or later time that the storage slot is set to zero. In this case, we can pair this event with the most recent previous time that the value was set away from zero, in which SSTORE_CLEARS_SCHEDULE gas is removed from the refund.\n\nFor the second and later event, it does not matter what value SSTORE_CLEARS_SCHEDULE has, because every refund of that size is paired with a refund removal of the same size. This leaves the first event. For the total gas expended on the slot to be guaranteed to be positive, we need SSTORE_CLEARS_SCHEDULE <= SSTORE_RESET_GAS + ACCESS_LIST_STORAGE_KEY_COST. And so this EIP simply decreases SSTORE_CLEARS_SCHEDULE to the sum of those two costs.\n\nOne alternative intuition for this EIP is that there will not be a net refund for clearing data that has not yet been read (which is often “useless” data), but there will continue to be a net refund for clearing data that has been read (which is likely to be “useful” data).\n\n Backwards Compatibility\n\nRefunds are currently only applied after transaction execution, so they cannot affect how much gas is available to any particular call frame during execution. Hence, removing them will not break the ability of any code to execute, though it will render some applications economically nonviable.\n\nGas tokens will become valueless. DeFi arbitrage bots, which today frequently use either established gas token schemes or a custom alternative to reduce on-chain costs, would benefit from rewriting their code to remove calls to these no-longer-functional gas storage mechanisms.\n\nHowever, fully preserving refunds in the new = original = 0 != current case, and keeping some refund in the other nonzero -> zero cases, ensures that a few key use cases that receive (and deserve) favorable gas cost treatment continue to do so. For example, zero -> nonzero -> zero storage set patterns continue to cost only ~100 gas. Two important examples of such patterns include:\n\n Anti-reentrancy locks (typically flipped from 0 to 1 right before a child call begins, and then flipped back to 0 when the child call ends)\n ERC20 approve-and-send (the “approved value” goes from zero to nonzero when the token transfer is approved, and then back to zero when the token transfer processes)\n\n Effect on storage clearing incentives\n\nA criticism of earlier refund removal EIPs (EIP-3298 and EIP-3403) is that these EIPs fully remove the incentive to set a value to zero, encouraging users to not fully clear a storage slot if they expect even the smallest probability that they will want to use that storage slot again.\n\nFor example, if you have 1 unit of an ERC20 token and you are giving away or selling your entire balance, you could instead only give away 0.999999 units and leave the remainder behind. If you ever decide to re-acquire more of that token with the same account in the future, you would only have to pay 5000 gas (2100 for the read + 2900 for nonzero-to-nonzero set) for the SSTORE instead of 22100 (20000 for the zero-to-nonzero set). Today, this is counterbalanced by the 15000 refund for clearing, so you only have an incentive to do this if you are more than 15000 / 17100 = 87.7% sure that you will use the slot again; with EIP-3298 or EIP-3403 the counterbalancing incentive would not exist, so setting to nonzero is better if your chance of using the slot again is any value greater than 0%.\n\nA refund of 4800 gas remains, so there is only be an incentive to keep a storage slot nonzero if you expect a probability of more than 4800 / 17100 = 28.1% that you will use that slot again. This is not perfect, but it is likely higher than the average person’s expectations of later re-acquiring a token with the same address if they clear their entire balance of it.\n\nThe capping of refunds to 1/5 of gas expended means that this refund can only be used to increase the amount of storage write operations needed to process a block by at most 25%, limiting the ability to use this mechanic for storage-write-focused denial-of-service attacks.\n\n Test Cases\n\n EIP-2929 Gas Costs\n\nNote, there is a difference between ‘hot’ and ‘cold’ slots. This table shows the values as of EIP-2929 assuming that all touched storage slots were already ‘hot’ (the difference being a one-time cost of 2100 gas).\n\n Code\n Used Gas\n Refund\n Original\n 1st\n 2nd\n 3rd\n Effective gas (after refund)\n\n 0x60006000556000600055\n 212\n 0\n 0\n 0\n 0\n\n 212\n\n 0x60006000556001600055\n 20112\n 0\n 0\n 0\n 1\n\n 20112\n\n 0x60016000556000600055\n 20112\n 19900\n 0\n 1\n 0\n\n 212\n\n 0x60016000556002600055\n 20112\n 0\n 0\n 1\n 2\n\n 20112\n\n 0x60016000556001600055\n 20112\n 0\n 0\n 1\n 1\n\n 20112\n\n 0x60006000556000600055\n 3012\n 15000\n 1\n 0\n 0\n\n -11988\n\n 0x60006000556001600055\n 3012\n 2800\n 1\n 0\n 1\n\n 212\n\n 0x60006000556002600055\n 3012\n 0\n 1\n 0\n 2\n\n 3012\n\n 0x60026000556000600055\n 3012\n 15000\n 1\n 2\n 0\n\n -11988\n\n 0x60026000556003600055\n 3012\n 0\n 1\n 2\n 3\n\n 3012\n\n 0x60026000556001600055\n 3012\n 2800\n 1\n 2\n 1\n\n 212\n\n 0x60026000556002600055\n 3012\n 0\n 1\n 2\n 2\n\n 3012\n\n 0x60016000556000600055\n 3012\n 15000\n 1\n 1\n 0\n\n -11988\n\n 0x60016000556002600055\n 3012\n 0\n 1\n 1\n 2\n\n 3012\n\n 0x60016000556001600055\n 212\n 0\n 1\n 1\n 1\n\n 212\n\n 0x600160005560006000556001600055\n 40118\n 19900\n 0\n 1\n 0\n 1\n 20218\n\n 0x600060005560016000556000600055\n 5918\n 17800\n 1\n 0\n 1\n 0\n -11882\n\n With reduced refunds\n\nIf refunds were to be partially removed, by changing SSTORE_CLEARS_SCHEDULE from 15000 to 4800 (and removing selfdestruct refund) this would be the comparative table.\n\n Code\n Used Gas\n Refund\n Original\n 1st\n 2nd\n 3rd\n Effective gas (after refund)\n\n 0x60006000556000600055\n 212\n 0\n 0\n 0\n 0\n\n 212\n\n 0x60006000556001600055\n 20112\n 0\n 0\n 0\n 1\n\n 20112\n\n 0x60016000556000600055\n 20112\n 19900\n 0\n 1\n 0\n\n 212\n\n 0x60016000556002600055\n 20112\n 0\n 0\n 1\n 2\n\n 20112\n\n 0x60016000556001600055\n 20112\n 0\n 0\n 1\n 1\n\n 20112\n\n 0x60006000556000600055\n 3012\n 4800\n 1\n 0\n 0\n\n -1788\n\n 0x60006000556001600055\n 3012\n 2800\n 1\n 0\n 1\n\n 212\n\n 0x60006000556002600055\n 3012\n 0\n 1\n 0\n 2\n\n 3012\n\n 0x60026000556000600055\n 3012\n 4800\n 1\n 2\n 0\n\n -1788\n\n 0x60026000556003600055\n 3012\n 0\n 1\n 2\n 3\n\n 3012\n\n 0x60026000556001600055\n 3012\n 2800\n 1\n 2\n 1\n\n 212\n\n 0x60026000556002600055\n 3012\n 0\n 1\n 2\n 2\n\n 3012\n\n 0x60016000556000600055\n 3012\n 4800\n 1\n 1\n 0\n\n -1788\n\n 0x60016000556002600055\n 3012\n 0\n 1\n 1\n 2\n\n 3012\n\n 0x60016000556001600055\n 212\n 0\n 1\n 1\n 1\n\n 212\n\n 0x600160005560006000556001600055\n 40118\n 19900\n 0\n 1\n 0\n 1\n 20218\n\n 0x600060005560016000556000600055\n 5918\n 7600\n 1\n 0\n 1\n 0\n -1682\n\n Security Considerations\n\nRefunds are not visible to transaction execution, so this should not have any impact on transaction execution logic.\n\nThe maximum amount of gas that can be spent on execution in a block is limited to the gas limit, if we do not count zero-to-nonzero SSTOREs that were later reset back to zero. It is okay to not count those, because if such an SSTORE is reset, storage is not expanded and the client does not need to actually adjust the Merke tree; the gas consumption is refunded, but the effort normally required by the client to process those opcodes is also cancelled. Clients should make sure to not do a storage write if new_value = original_value; this was a prudent optimization since the beginning of Ethereum but it becomes more important now.\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), Martin Swende (@holiman), \"EIP-3529: Reduction in refunds,\" Ethereum Improvement Proposals, no. 3529, April 2021. Available: https://eips.ethereum.org/EIPS/eip-3529.","tokens":2911,"squid":"spider-05","role":"Spec Spider","at":1791342382504,"hash":"6744728e77654591695b41dcdd61411bc5f5ca0c"}
{"url":"https://eips.ethereum.org/EIPS/eip-2930","domain":"eips.ethereum.org","title":"EIP-2930: Optional access lists","text":"🎉 Final\n\n Standards Track: Core\n\n EIP-2930: Optional access lists\n\n Authors\n Vitalik Buterin (@vbuterin), Martin Swende (@holiman)\n\n Created\n 2020-08-29\n\n Requires\n\n EIP-2718, \n\n EIP-2929\n\n Simple Summary\n\nAdds a transaction type which contains an access list, a list of addresses and storage keys that the transaction plans to access. Accesses outside the list are possible, but become more expensive.\n\n Abstract\n\nWe introduce a new EIP-2718 transaction type, with the format 0x01 || rlp([chainId, nonce, gasPrice, gasLimit, to, value, data, accessList, signatureYParity, signatureR, signatureS]).\n\nThe accessList specifies a list of addresses and storage keys; these addresses and storage keys are added into the accessed_addresses and accessed_storage_keys global sets (introduced in EIP-2929). A gas cost is charged, though at a discount relative to the cost of accessing outside the list.\n\n Motivation\n\nThis EIP serves two functions:\n\n Mitigates contract breakage risks introduced by EIP-2929, as transactions could pre-specify and pre-pay for the accounts and storage slots that the transaction plans to access; as a result, in the actual execution, the SLOAD and EXT* opcodes would only cost 100 gas: low enough that it would not only prevent breakage due to that EIP but also “unstuck” any contracts that became stuck due to EIP 1884.\n Introduces the access list format and the logic for handling the format. This logic can later be repurposed for many other purposes, including block-wide witnesses, use in ReGenesis, moving toward static state access over time, and more.\n\n Specification\n\n Definitions\n\nTransactionType 1. See EIP-2718\n\nChainId The transaction only valid on networks with this chainID.\n\nYParity The parity (0 for even, 1 for odd) of the y-value of a secp256k1 signature.\n\n Parameters\n\n Constant\n Value\n\n FORK_BLOCK\n 12244000\n\n ACCESS_LIST_STORAGE_KEY_COST\n 1900\n\n ACCESS_LIST_ADDRESS_COST\n 2400\n\nAs of FORK_BLOCK_NUMBER, a new EIP-2718 transaction is introduced with TransactionType 1.\n\nThe EIP-2718 TransactionPayload for this transaction is rlp([chainId, nonce, gasPrice, gasLimit, to, value, data, accessList, signatureYParity, signatureR, signatureS]).\n\nThe signatureYParity, signatureR, signatureS elements of this transaction represent a secp256k1 signature over keccak256(0x01 || rlp([chainId, nonce, gasPrice, gasLimit, to, value, data, accessList])).\n\nThe EIP-2718 ReceiptPayload for this transaction is rlp([status, cumulativeGasUsed, logsBloom, logs]).\n\nFor the transaction to be valid, accessList must be of type [[{20 bytes}, [{32 bytes}...]]...], where ... means “zero or more of the thing to the left”. For example, the following is a valid access list (all hex strings would in reality be in byte representation):\n\n[\n [\n \"0xde0b295669a9fd93d5f28d9ec85e40f4cb697bae\",\n [\n \"0x0000000000000000000000000000000000000000000000000000000000000003\",\n \"0x0000000000000000000000000000000000000000000000000000000000000007\"\n ]\n ],\n [\n \"0xbb9bc244d798123fde783fcc1c72d3bb8c189413\",\n []\n ]\n]\n\nAt the beginning of execution (ie. at the same time as the 21000 + 4 * zeroes + 16 * nonzeroes start gas is charged according to EIP-2028 rules), we charge additional gas for the access list: ACCESS_LIST_ADDRESS_COST gas per address and ACCESS_LIST_STORAGE_KEY_COST gas per storage key. For example, the above example would be charged ACCESS_LIST_ADDRESS_COST * 2 + ACCESS_LIST_STORAGE_KEY_COST * 2 gas.\n\nNote that non-unique addresses and storage keys are not disallowed, though they will be charged for multiple times, and aside from the higher gas cost there is no other difference in execution flow or outcome from multiple-inclusion of a value as opposed to the recommended single-inclusion.\n\nThe address and storage keys would be immediately loaded into the accessed_addresses and accessed_storage_keys global sets; this can be done using the following logic (which doubles as a specification-in-code of validation of the RLP-decoded access list)\n\ndef process_access_list(access_list) -> Tuple[List[Set[Address], Set[Pair[Address, Bytes32]]], int]:\n accessed_addresses = set()\n accessed_storage_keys = set()\n gas_cost = 0\n assert isinstance(access_list, list)\n for item in access_list:\n assert isinstance(item, list) and len(item) == 2\n # Validate and add the address\n address = item[0]\n assert isinstance(address, bytes) and len(address) == 20\n accessed_addresses.add(address)\n gas_cost += ACCESS_LIST_ADDRESS_COST\n # Validate and add the storage keys\n assert isinstance(item[1], list)\n for key in item[1]:\n assert isinstance(key, bytes) and len(key) == 32\n accessed_storage_keys.add((address, key))\n gas_cost += ACCESS_LIST_STORAGE_KEY_COST\n return (\n accessed_addresses,\n accessed_storage_keys,\n gas_cost\n )\n\nThe access list is NOT charged per-byte fees like tx data is; the per-item costs described above are meant to cover the bandwidth costs of the access list data in addition to the costs of accessing those accounts and storage keys when evaluating the transaction.\n\n Rationale\n\n Charging less for accesses in the access list\n\nThis is done to encourage transactions to use the access list as much as possible, and because processing transactions is easier when their storage reads are predictable (because clients can pre-load the data from databases and/or ask for witnesses at the time the transaction is received, or at least load the data in parallel).\n\n Allowing duplicates\n\nThis is done because it maximizes simplicity, avoiding questions of what to prevent duplication against: just between two addresses/keys in the access list, between the access list and the tx sender/recipient/newly created contract, other restrictions? Because gas is charged per item, there is no gain and only cost in including a value in the access list twice, so this should not lead to extra chain bloat in practice.\n\n Signature signs over the transaction type as well as the transaction data\n\nThis is done to ensure that the transaction cannot be “re-interpreted” as a transaction of a different type.\n\n Backwards Compatibility\n\nThis EIP does make it more gas-expensive to perform “unexpected” SLOADs and account accesses. Because gas is prepaid and so does not affect fixed-gas local calls, it does not break contracts in the way that previous gas cost increases would risk. However, it does make applications that heavily rely on storage access much less economically viable.\n\n Security Considerations\n\n Access list generation\n\nAccess lists are difficult to construct in real-time in many situations, and this is exacerbated in environments where there is a high time lag between transaction generation and signing or simplicity of the transaction generator is highly valued (eg. either or both may apply in hardware wallets).\n\nHowever, this EIP proposes only a 10% initial discount to access lists, so there is almost no cost to not bothering with access list generation and only making a simple transaction. The cost of accessing state outside the access list is expected to be ramped up in future hard forks over time as tools are developed and access list generation becomes more mature.\n\n Transaction size bloating\n\nAverage block size will increase as a result of access lists being used. However, the per-byte cost of access lists is 1900 / 32 = 59.375 for storage keys and 2400 / 20 = 120 for addresses, making it much more expensive than calldata; hence, worst-case block size will not increase. Additionally, increases in average block size will be partially compensated for by the ability to pre-fetch storage at time of receiving a transaction and/or load storage in parallel upon receiving a block.\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), Martin Swende (@holiman), \"EIP-2930: Optional access lists,\" Ethereum Improvement Proposals, no. 2930, August 2020. Available: https://eips.ethereum.org/EIPS/eip-2930.","tokens":1983,"squid":"spider-05","role":"Spec Spider","at":1791342394368,"hash":"3ce5c8ed2f5438ed371321a5749497d1254776a8"}
{"url":"https://help.phantom.com/sections/get-started-4406292675731","domain":"help.phantom.com","title":"Get started","text":"How can we help you?SearchGet startedCreate your Phantom wallet, customize your accounts, and learn about the key features.Get started with Arc network in PhantomArc is an EVM-compatible network developed by Circle that uses USDC to pay network fees. Phantom supports Arc, so you can hold, send, receive, buy, and swap tokens on the network, as well as connect P...Updated 5 days agoGet started with BNB Chain in PhantomBNB Chain is an EVM-compatible network that uses BNB to pay network fees. Phantom supports BNB Chain, so you can hold, send, receive, buy, and swap tokens on the network.Updated 5 days agoRobinhood Chain FAQRobinhood Chain is an Ethereum Layer 2 network. Phantom fully supports it. Once enabled, you can hold and swap your assets, and connect to apps on Robinhood Chain.Updated 2 days agoCan I turn off vibration in the Phantom mobile app?No. Phantom doesn’t currently support turning off vibration (also known as haptic feedback) in the mobile app.Updated a month agoConnect your TikTok account to PhantomConnect your TikTok account to your Phantom profile, making it easier for your Phantom followers to recognize you. Once connected, your can use your TikTok username on your Phantom profile.Updated 12 days agoConnect your X account to PhantomConnect your X account to your Phantom profile, making it easier for your Phantom followers to recognize you. Once connected, you can use your X username and profile picture on your Phantom profile.Updated 12 days agoCreate a new Phantom walletYou can create a new Phantom wallet in two ways:Updated 20 days agoCreate a new Phantom wallet with a Google or Apple accountYou can create a new Phantom wallet by signing in with your Google or Apple account. Then access this wallet on any device where you use Phantom by signing in with the same account.Updated 20 days agoCreate a new Phantom wallet with a Secret Recovery PhraseYou can create a new wallet in Phantom using a Secret Recovery Phrase, sometimes called a seed phrase. Be sure to write your recovery phrase down and store it somewhere secure and offline. Phantom doe...Updated 20 days ago","tokens":529,"squid":"spider-10","role":"Tooling Spider","at":1791342395607,"hash":"03046d03f6f8e5c1e2800d871bbc8c2439acf1d9"}
{"url":"https://eips.ethereum.org/EIPS/eip-2929","domain":"eips.ethereum.org","title":"EIP-2929: Gas cost increases for state access opcodes","text":"🎉 Final\n\n Standards Track: Core\n\n EIP-2929: Gas cost increases for state access opcodes\n\n Authors\n Vitalik Buterin (@vbuterin), Martin Swende (@holiman)\n\n Created\n 2020-09-01\n\n Simple Summary\n\nIncreases gas cost for SLOAD, *CALL, BALANCE, EXT* and SELFDESTRUCT when used for the first time in a transaction.\n\n Abstract\n\nIncrease the gas cost of SLOAD (0x54) to 2100, and the *CALL opcode family (0xf1, f2, f4, fA), BALANCE 0x31 and the EXT* opcode family (0x3b, 0x3c, 0x3f) to 2600. Exempts (i) precompiles, and (ii) addresses and storage slots that have already been accessed in the same transaction, which get a decreased gas cost. Additionally reforms SSTORE metering and SELFDESTRUCT to ensure “de-facto storage loads” inherent in those opcodes are priced correctly.\n\n Motivation\n\nGenerally, the main function of gas costs of opcodes is to be an estimate of the time needed to process that opcode, the goal being for the gas limit to correspond to a limit on the time needed to process a block. However, storage-accessing opcodes (SLOAD, as well as the *CALL, BALANCE and EXT* opcodes) have historically been underpriced. In the 2016 Shanghai DoS attacks, once the most serious client bugs were fixed, one of the more durably successful strategies used by the attacker was to simply send transactions that access or call a large number of accounts.\n\nGas costs were increased to mitigate this, but recent numbers suggest they were not increased enough. Quoting https://arxiv.org/pdf/1909.07220.pdf:\n\n Although by itself, this issue might seem benign, EXTCODESIZE forces the client to search the contract ondisk, resulting in IO heavy transactions. While replaying the Ethereum history on our hardware, the malicious transactions took around 20 to 80 seconds to execute, compared to a few milliseconds for the average transactions\n\nThis proposed EIP increases the costs of these opcodes by a factor of ~3, reducing the worst-case processing time to ~7-27 seconds. Improvements in database layout that involve redesigning the client to read storage directly instead of hopping through the Merkle tree would decrease this further, though these technologies may take a long time to fully roll out, and even with such technologies the IO overhead of accessing storage would remain substantial.\n\nA secondary benefit of this EIP is that it also performs most of the work needed to make stateless witness sizes in Ethereum acceptable. Assuming a switch to binary tries, the theoretical maximum witness size not including code size (hence “most of the work” and not “all”) would decrease from (12500000 gas limit) / (700 gas per BALANCE) * (800 witness bytes per BALANCE) ~= 14.3M bytes to 12500000 / 2600 * 800 ~= 3.85M bytes. Pricing for code access could be changed when code merklization is implemented.\n\nIn the further future, there are similar benefits in the case of SNARK/STARK witnesses. Recent numbers from Starkware suggest that they are able to prove 10000 Rescue hashes per second on a consumer desktop; assuming 25 hashes per Merkle branch, and a block full of state accesses, at present this would imply a witness would take 12500000 / 700 * 25 / 10000 ~= 44.64 seconds to generate, but after this EIP that would reduce to 12500000 / 2500 * 25 / 10000 ~= 12.5 seconds, meaning that a single desktop computer would be able to generate witnesses on time under any conditions. Future gains in STARK proving could be spent on either (i) using a more expensive but robust hash function or (ii) reducing proving times further, reducing the delay and hence improving user experience of stateless clients that rely on such witnesses.\n\n Specification\n\n Parameters\n\n Constant\n Value\n\n FORK_BLOCK\n 12244000\n\n COLD_SLOAD_COST\n 2100\n\n COLD_ACCOUNT_ACCESS_COST\n 2600\n\n WARM_STORAGE_READ_COST\n 100\n\nFor blocks where block.number >= FORK_BLOCK, the following changes apply.\n\nWhen executing a transaction, maintain a set accessed_addresses: Set[Address] and accessed_storage_keys: Set[Tuple[Address, Bytes32]] .\n\nThe sets are transaction-context-wide, implemented identically to other transaction-scoped constructs such as the self-destruct-list and global refund counter. In particular, if a scope reverts, the access lists should be in the state they were in before that scope was entered.\n\nWhen a transaction execution begins,\n\n accessed_storage_keys is initialized to empty, and\n accessed_addresses is initialized to include\n\n the tx.sender, tx.to (or the address being created if it is a contract creation transaction)\n and the set of all precompiles.\n\n Storage read changes\n\nWhen an address is either the target of a (EXTCODESIZE (0x3B), EXTCODECOPY (0x3C), EXTCODEHASH (0x3F) or BALANCE (0x31)) opcode or the target of a (CALL (0xF1), CALLCODE (0xF2), DELEGATECALL (0xF4), STATICCALL (0xFA)) opcode, the gas costs are computed as follows:\n\n If the target is not in accessed_addresses, charge COLD_ACCOUNT_ACCESS_COST gas, and add the address to accessed_addresses.\n Otherwise, charge WARM_STORAGE_READ_COST gas.\n\nIn all cases, the gas cost is charged and the map is updated at the time that the opcode is being called. \nWhen a CREATE or CREATE2 opcode is called, immediately (ie. before checks are done to determine whether or not the address is unclaimed) add the address being created to accessed_addresses, but gas costs of CREATE and CREATE2 are unchanged.\nClarification: If a CREATE/CREATE2 operation fails later on, e.g during the execution of initcode or has insufficient gas to store the code in the state, the address of the contract itself remains in access_addresses (but any additions made within the inner scope are reverted).\n\nFor SLOAD, if the (address, storage_key) pair (where address is the address of the contract whose storage is being read) is not yet in accessed_storage_keys, charge COLD_SLOAD_COST gas and add the pair to accessed_storage_keys. If the pair is already in accessed_storage_keys, charge WARM_STORAGE_READ_COST gas.\n\nNote: For call-variants, the 100/2600 cost is applied immediately (exactly like how 700 was charged before this EIP), i.e: before calculating the 63/64ths available for entering the call.\n\nNote 2: There is currently no way to perform a ‘cold sload read/write’ on a ‘cold account’, simply because in order to read/write a slot, the execution must already be inside the account. Therefore, the behaviour of cold storage reads/writes on cold accounts is undefined as of this EIP. Any future EIP which \nproposes to add ‘remote read/write’ would need to define the pricing behaviour of that change.\n\n SSTORE changes\n\nWhen calling SSTORE, check if the (address, storage_key) pair is in accessed_storage_keys. If it is not, charge an additional COLD_SLOAD_COST gas, and add the pair to accessed_storage_keys. Additionally, modify the parameters defined in EIP-2200 as follows:\n\n Parameter\n Old value\n New value\n\n SLOAD_GAS\n 800\n = WARM_STORAGE_READ_COST\n\n SSTORE_RESET_GAS\n 5000\n 5000 - COLD_SLOAD_COST\n\nThe other parameters defined in EIP 2200 are unchanged.\nNote: The constant SLOAD_GAS is used in several places in EIP 2200, e.g SSTORE_SET_GAS - SLOAD_GAS. Implementations that are using composite definitions have to ensure to update those definitions too.\n\n SELFDESTRUCT changes\n\nIf the ETH recipient of a SELFDESTRUCT is not in accessed_addresses (regardless of whether or not the amount sent is nonzero), charge an additional COLD_ACCOUNT_ACCESS_COST on top of the existing gas costs, and add the ETH recipient to the set.\n\nNote: SELFDESTRUCT does not charge a WARM_STORAGE_READ_COST in case the recipient is already warm, which differs from how the other call-variants work. The reasoning behind this is to keep the changes small, a SELFDESTRUCT already costs 5K and is a no-op if invoked more than once.\n\n Rationale\n\n Opcode costs vs charging per byte of witness data\n\nThe natural alternative path to changing gas costs to reflect witness sizes is to charge per byte of witness data. However, that would take a longer time to implement, hampering the goal of providing short-term security relief. Furthermore, following that path faithfully would lead to extremely high gas costs to transactions that touch contract code, as one would need to charge for all 24576 contract code bytes; this would be an unacceptably high burden on developers. It is better to wait for code merklization to start trying to properly account for gas costs of accessing individual chunks of code; from a short-term DoS prevention standpoint, accessing 24 kB from disk is not much more expensive than accessing 32 bytes from disk, so worrying about code size is not necessary.\n\n Adding the accessed_addresses / accessed_storage_keys sets\n\nThe sets of already-accessed accounts and storage slots are added to avoid needlessly charging for things that can be cached (and in all performant implementations already are cached). Additionally, it removes the current undesirable status quo where it is needlessly unaffordable to do self-calls or call precompiles, and enables contract breakage mitigations that involve pre-fetching some storage key allowing a future execution to still take the expected amount of gas.\n\n SSTORE gas cost change\n\nThe change to SSTORE is needed to avoid the possibility of a DoS attack that “pokes” a randomly chosen zero storage slot, changing it from 0 to 0 at a cost of 800 gas but requiring a de-facto storage load. The SSTORE_RESET_GAS reduction ensures that the total cost of SSTORE (which now requires paying the COLD_SLOAD_COST) remains unchanged. Additionally, note that applications that do SLOAD followed by SSTORE (eg. storage_variable += x) would actually get cheaper!\n\n Change SSTORE accounting only minimally\n\nThe SSTORE gas costs continue to use Wei Tang’s original/current/new approach, instead of being redesigned to use a dirty map, because Wei Tang’s approach correctly accounts for the actual costs of changing storage, which only care about current vs final value and not intermediate values.\n\n How would gas consumption of average applications increase under this proposal?\n\n Rough analysis from witness sizes\n\nWe can look at Alexey Akhunov’s earlier work for data on average-case blocks. In summary, average blocks have witness sizes of ~1000 kB, of which ~750 kB is Merkle proofs and not code. Assuming a conservative 2000 bytes per Merkle branch this implies ~375 accesses per block (SLOADs have a similar gas-increase-to-bytes ratio so there’s no need to analyze them separately).\n\nData on txs per day and blocks per day from Etherscan gives ~160 transactions per block (reference date: Jul 1), implying a large portion of those accesses are just the tx.sender and tx.to which are excluded from gas cost increases, though likely less than 320 due to duplicate addresses.\n\nHence, this implies ~50-375 chargeable accesses per block, and each access suffers a gas cost increase of 1900; 50 * 1900 = 95000 and 375 * 1900 = 712500, implying the gas limit would need to be raised by ~1-6% to compensate. However, this analysis may be complicated further in either direction by (i) accounts / storage keys being accessed in multiple transactions, which would appear once in the witness but twice in gas cost increases, and (ii) accounts / storage keys being accessed multiple times in the same transaction, which lead to gas cost decreases.\n\n Goerli analysis\n\nA more precise analysis can be found by scanning Goerli transactions, as done by Martin Swende here: https://github.com/holiman/gasreprice\n\nThe conclusion is that on average gas costs increase by ~2.36%. One major contributing factor to reducing gas costs is that a large number of contracts inefficiently read the same storage slot multiple times, which leads to this EIP giving a few transactions gas cost savings of over 10%.\n\n Backwards Compatibility\n\nThese gas cost increases may potentially break contracts that depend on fixed gas costs; see the security considerations section for details and arguments for why we expect the total risks to be low and how if desired they can be reduced further.\n\n Test Cases\n\nSome test cases can be found here: https://gist.github.com/holiman/174548cad102096858583c6fbbb0649a\n\nIdeally we would test the following:\n\n SLOAD the same storage slot {1, 2, 3} times\n CALL the same address {1, 2, 3} times\n\n (SLOAD\n CALL) in a sub-call, then revert, then (SLOAD\n CALL) the same (storage slot\n address) again\n\n Sub-call, SLOAD, sub-call again, revert the inner sub-call, SLOAD the same storage slot\n SSTORE the same storage slot {1, 2, 3} times, using all combinations of zero/nonzero for original value and the value being set\n SSTORE then SLOAD the same storage slot\n OP_1 then OP_2 to the same address where OP_1 and OP_2 are all combinations of (*CALL, EXT*, SELFDESTRUCT)\n\n Try to CALL an address but with all possible failure modes (not enough gas, not enough ETH…), then (CALL\n EXT*) that address again successfully\n\n Implementation\n\nA WIP early-draft implementation for Geth can be found here: https://github.com/holiman/go-ethereum/tree/access_lists\n\n Security Considerations\n\nAs with any gas cost increasing EIP, there are three possible cases where it could cause applications to break:\n\n Fixed gas limits to sub-calls in contracts\n Applications relying on contract calls that consume close to the full gas limit\n The 2300 base limit given to the callee by ETH-transferring calls\n\nThese risks have been studied before in the context of an earlier gas cost increase, EIP-1884. See Martin Swende’s earlier report and Hubert Ritzdorf’s analysis focusing on (1) and (3). (2) has received less analysis, though one can argue that it is very unlikely both because applications tend to very rarely use close to the entire gas limit in a transaction, and because gas limits were very recently raised from 10 million to 12.5 million. EIP-1884 in practice did lead to a small number of contracts breaking for this reason.\n\nThere are two ways to look at these risks. First, we can note that as of today developers have had years of warning; gas cost increases on storage-accessing opcodes have been discussed for a long time, with multiple statements made including to major dapp developers around the likelihood of such changes. EIP-1884 itself provided an important wake-up call. Hence, we can argue that risks this time will be significantly lower than EIP-1884.\n\n Contract breakage mitigations\n\nA second way to look at the risks is to explore mitigations. First of all, the existence of an accessed_addresses and accessed_storage_keys map (present in this EIP, absent in EIP-1884) already makes some cases recoverable: in any case where a contract A needs to send funds to some address B, where that address accepts funds from any source but leaves a storage-dependent log, one can recover by first sending a separate call to B to pull it into the cache, and then call A, knowing that the execution of B triggered by A will only charge 100 gas per SLOAD. This fact does not fix all situations, but it does reduce risks significantly.\n\nBut there are ways to further expand the usability of this pattern. One possibility is to add a POKE precompile, which would take an address and a storage key as input and allow transactions that attempt to “rescue” stuck contracts by pre-poking all of the storage slots that they will access. This works even if the address only accepts transactions from the contract, and works in many other contexts with present gas limits. The only case where this will not work would be the case where a transaction call must go from an EOA straight into a specific contract that then sub-calls another contract.\n\nAnother option is EIP-2930, which would have a similar effect to POKE but is more general: it also works for the EOA -> contract -> contract case, and generally should work for all known cases of breakage due to gas cost increases. This option is more complex, though it is arguably a stepping stone toward access lists being used for other use cases (regenesis, account abstraction, SSA all demand access lists).\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), Martin Swende (@holiman), \"EIP-2929: Gas cost increases for state access opcodes,\" Ethereum Improvement Proposals, no. 2929, September 2020. Available: https://eips.ethereum.org/EIPS/eip-2929.","tokens":4088,"squid":"spider-05","role":"Spec Spider","at":1791342405850,"hash":"3591fed013dbd8f6a72bbc7061cfd9d55c8fc969"}
{"url":"https://squidfunk.github.io/mkdocs-material/reference/content-tabs/","domain":"squidfunk.github.io","title":"Content tabs - Material for MkDocs","text":"Content tabs¶ Sometimes, it's desirable to group alternative content under different tabs, e.g. when describing how to access an API from different languages or environments. Material for MkDocs allows for beautiful and functional tabs, grouping code blocks and other content. Configuration¶ This configuration enables content tabs, and allows to nest arbitrary content inside content tabs, including code blocks and ... more content tabs! Add the following lines to mkdocs.yml: markdown_extensions:\n - pymdownx.superfences\n - pymdownx.tabbed:\n alternate_style: true\n See additional configuration options: SuperFences Tabbed Anchor links¶ 9.5.0 In order to link to content tabs and share them more easily, an anchor link is automatically added to each content tab, which you can copy via right click or open in a new tab: Open me in a new tab ...... or me ...... or even me You can copy the link of the tab and create a link on the same or any other page. For example, you can jump to the third tab above this paragraph. Readable anchor links Python Markdown Extensions 9.6 adds support for slugification of content tabs, which produces nicer looking and more readable anchor links. Enable the slugify function with the following lines: markdown_extensions:\n - pymdownx.tabbed:\n slugify: !!python/object/apply:pymdownx.slugs.slugify\n kwds:\n case: lower\n For more information, please see the extension guide. Linked content tabs¶ 8.3.0 When enabled, all content tabs across the whole documentation site will be linked and switch to the same label when the user clicks on a tab. Add the following lines to mkdocs.yml: theme:\n features:\n - content.tabs.link\n Content tabs are linked based on their label, not offset. This means that all tabs with the same label will be activated when a user clicks a content tab regardless of order inside a container. Furthermore, this feature is fully integrated with instant loading and persisted across page loads. Feature enabledFeature disabled Usage¶ Grouping code blocks¶ Code blocks are one of the primary targets to be grouped, and can be considered a special case of content tabs, as tabs with a single code block are always rendered without horizontal spacing: Content tabs with code blocks=== \"C\"\n\n ``` c\n #include <stdio.h>\n\n int main(void) {\n printf(\"Hello world!\\n\");\n return 0;\n }\n ```\n\n=== \"C++\"\n\n ``` c++\n #include <iostream>\n\n int main(void) {\n std::cout << \"Hello world!\" << std::endl;\n return 0;\n }\n ```\n CC++ #include <stdio.h>\n\nint main(void) {\n printf(\"Hello world!\\n\");\n return 0;\n}\n #include <iostream>\n\nint main(void) {\n std::cout << \"Hello world!\" << std::endl;\n return 0;\n}\n Grouping other content¶ When a content tab contains more than one code block, it is rendered with horizontal spacing. Vertical spacing is never added, but can be achieved by nesting tabs in other blocks: Content tabs=== \"Unordered list\"\n\n * Sed sagittis eleifend rutrum\n * Donec vitae suscipit est\n * Nulla tempor lobortis orci\n\n=== \"Ordered list\"\n\n 1. Sed sagittis eleifend rutrum\n 2. Donec vitae suscipit est\n 3. Nulla tempor lobortis orci\n Unordered listOrdered list Sed sagittis eleifend rutrum Donec vitae suscipit est Nulla tempor lobortis orci Sed sagittis eleifend rutrum Donec vitae suscipit est Nulla tempor lobortis orci Embedded content¶ When SuperFences is enabled, content tabs can contain arbitrary nested content, including further content tabs, and can be nested in other blocks like admonitions or blockquotes: Content tabs in admonition!!! example\n\n === \"Unordered List\"\n\n ``` markdown\n * Sed sagittis eleifend rutrum\n * Donec vitae suscipit est\n * Nulla tempor lobortis orci\n ```\n\n === \"Ordered List\"\n\n ``` markdown\n 1. Sed sagittis eleifend rutrum\n 2. Donec vitae suscipit est\n 3. Nulla tempor lobortis orci\n ```\n Example Unordered ListOrdered List * Sed sagittis eleifend rutrum\n* Donec vitae suscipit est\n* Nulla tempor lobortis orci\n 1. Sed sagittis eleifend rutrum\n2. Donec vitae suscipit est\n3. Nulla tempor lobortis orci","tokens":996,"squid":"spider-06","role":"Security Spider","at":1791342406770,"hash":"83227f7760e14d1dbebcb4967f5885e8f8a78e7e"}
{"url":"https://help.phantom.com/articles/robinhood-chain-faq-53628774801683","domain":"help.phantom.com","title":"Robinhood Chain FAQ","text":"Robinhood Chain FAQRobinhood Chain is an Ethereum Layer 2 network. Phantom fully supports it. Once enabled, you can hold and swap your assets, and connect to apps on Robinhood Chain.Get started #How do I turn on Robinhood Chain in Phantom? #If Robinhood Chain doesn't appear, follow these steps:\nUpdate Phantom to the latest version.\nGo to Settings > Active Networks.\nTurn on Robinhood Chain.\nIs there a separate Robinhood Chain address? #No. Your wallet address is exactly the same. Robinhood Chain is EVM-compatible. It uses your existing Ethereum address. However, your token balances on each network remain completely separate.Can I connect to apps on Robinhood Chain? #Yes. You can connect Phantom to apps on Robinhood Chain.Network fees #Do I need ETH on Robinhood Chain? #Yes. You need ETH on the Robinhood Chain to pay for transactions. Same-network swaps can be gasless. See Understanding gasless EVM transactions in Phantom.Can I use my Ethereum or Base ETH to pay for Robinhood Chain fees? #No. ETH on Ethereum, Base, or other networks cannot pay for Robinhood Chain fees. You must bridge or deposit ETH directly to your Robinhood Chain balance first.Transfers and assets #How do I find my Robinhood Chain EVM address and transfer ETH to it? #Your Robinhood Chain EVM address is the exact same 0x address you use for Ethereum, Base, or Polygon.Find your Robinhood Chain address #Go to your Phantom wallet, select Receive, and choose Robinhood Chain. Copy the 0x address displayed.Add funds to Robinhood Chain #You cannot send ETH directly from the standard Ethereum network to this address and expect it to appear on Robinhood Chain automatically. You must fund it using one of three methods:\nDeposit: Send ETH from an external wallet directly to your Robinhood Chain address.\nSwap in Phantom: Open the Trade tab (1). Choose the token to pay with in You Pay (2), then choose the Ethereum network (3) and the native Ethereum token (4). Tap the token selector in You Receive, choose the Robinhood Chain network (5) and the native Ethereum token (6). Enter an amount and tap Swap (7).\nSwap native ETH on Ethereum to native ETH on Robinhood ChainDirect withdrawal: If you are withdrawing from a centralized exchange or the Robinhood App, make sure to explicitly select the Robinhood Chain network as your network routing choice before hitting send.Why can't I transfer my funds out of Robinhood Chain? #You likely lack ETH on Robinhood Chain to pay the network fee. Ensure you have a small amount of Robinhood Chain ETH to process the transaction.Why am I missing certain tokens or stock assets? #Asset availability depends on your geographic location. Some real-world asset (RWA) tokens and stock tokens face strict regional restrictions.Robinhood Chain promotion #Robinhood Chain promotion banner in PhantomWho is eligible for the Robinhood Chain promotion? #Anyone who meets the published promotion terms is eligible. You do not need to open or interact with promotional banners or messages to qualify.Which trades count toward the promotion? #Qualifying trades must be initiated through Phantom, executed and confirmed on Robinhood Chain, and settled during the promotion period. Failed, reversed, or cancelled transactions do not count. Twenty-five trades of $1 in notional value each do count.Where and when will I receive my reward? #Rewards are credited to your Cash balance within 15 days after the promotion period ends. By October 14 at the latest. Rewards are processed after eligibility is determined, so payouts are not instant.What happens if the reward pool runs out? #Rewards are available on a first-come, first-served basis. If the reward pool is exhausted, the promotion is terminated.See also #Understanding gasless swaps on EVM networks in PhantomRelated articlesCreate a new Phantom wallet with a Google or Apple accountYou can create a new Phantom wallet by signing in with your Google or Apple account. Then access this wallet on any device where you use Phantom by signing in with the same account.Updated 20 days agoHow your wallet is securedYour Phantom wallet is secured by your recovery method: the credentials that prove ownership and let you restore access if you lose your device. Because Phantom is self-custodial, protecting those cre...Updated 2 months agoHow your funds are storedYour funds are not stored in Phantom. Your balances and transaction history are recorded on the blockchain, and access to them is controlled by cryptographic keys that only you hold. Phantom stores th...Updated 2 months agoGet started with PhantomNew to Phantom? Start by downloading the app, creating your wallet, and adding funds when you’re ready.Updated 12 days agoDownload Phantom on mobileDownload the Phantom app for free on iOS or Android. Only download from the official links in this article. Scammers sometimes upload fake apps that can steal your funds.Updated 2 months ago","tokens":1227,"squid":"spider-10","role":"Tooling Spider","at":1791342406818,"hash":"35676476e8c83e62b0c1e6b4790678375fdea473"}
{"url":"https://eips.ethereum.org/EIPS/eip-1167","domain":"eips.ethereum.org","title":"ERC-1167: Minimal Proxy Contract","text":"🎉 Final\n\n Standards Track: ERC\n\n ERC-1167: Minimal Proxy Contract\n\n Authors\n Peter Murray (@yarrumretep), Nate Welch (@flygoing), Joe Messerman (@JAMesserman)\n\n Created\n 2018-06-22\n\n Requires\n\n EIP-211\n\n Simple Summary\n\nTo simply and cheaply clone contract functionality in an immutable way, this standard specifies a minimal bytecode implementation that delegates all calls to a known, fixed address.\n\n Abstract\n\nBy standardizing on a known minimal bytecode redirect implementation, this standard allows users and third party tools (e.g. Etherscan) to (a) simply discover that a contract will always redirect in a known manner and (b) depend on the behavior of the code at the destination contract as the behavior of the redirecting contract. Specifically, tooling can interrogate the bytecode at a redirecting address to determine the location of the code that will run - and can depend on representations about that code (verified source, third-party audits, etc). This implementation forwards all calls and 100% of the gas to the implementation contract and then relays the return value back to the caller. In the case where the implementation reverts, the revert is passed back along with the payload data (for revert with message).\n\n Motivation\n\nThis standard supports use-cases wherein it is desirable to clone exact contract functionality with a minimum of side effects (e.g. memory slot stomping) and with low gas cost deployment of duplicate proxies.\n\n Specification\n\nThe exact bytecode of the standard clone contract is this: 363d3d373d3d3d363d73bebebebebebebebebebebebebebebebebebebebe5af43d82803e903d91602b57fd5bf3 wherein the bytes at indices 10 - 29 (inclusive) are replaced with the 20 byte address of the master functionality contract.\n\nA reference implementation of this can be found at the optionality/clone-factory github repo.\n\n Rationale\n\nThe goals of this effort have been the following:\n\n inexpensive deployment (low gas to deploy clones)\n support clone initialization in creation transaction (through factory contract model)\n simple clone bytecode to encourage directly bytecode interrogation (see CloneProbe.sol in the clone-factory project)\n dependable, locked-down behavior - this is not designed to handle upgradability, nor should it as the representation we are seeking is stronger.\n small operational overhead - adds a single call cost to each call\n handles error return bubbling for revert messages\n\n Backwards Compatibility\n\nThere are no backwards compatibility issues. There may be some systems that are using earlier versions of the proxy contract bytecode. They will not be compliant with this standard.\n\n Test Cases\n\nTest cases include:\n\n invocation with no arguments\n invocation with arguments\n invocation with fixed length return values\n invocation with variable length return values\n invocation with revert (confirming reverted payload is transferred)\n\nTests for these cases are included in the reference implementation project.\n\n Implementation\n\nDeployment bytecode is not included in this specification. One approach is defined in the proxy-contract reference implementation.\n\n Standard Proxy\n\nThe disassembly of the standard deployed proxy contract code (from r2 and edited to include stack visualization)\n\n| 0x00000000 36 calldatasize cds\n| 0x00000001 3d returndatasize 0 cds\n| 0x00000002 3d returndatasize 0 0 cds\n| 0x00000003 37 calldatacopy \n| 0x00000004 3d returndatasize 0\n| 0x00000005 3d returndatasize 0 0 \n| 0x00000006 3d returndatasize 0 0 0\n| 0x00000007 36 calldatasize cds 0 0 0\n| 0x00000008 3d returndatasize 0 cds 0 0 0\n| 0x00000009 73bebebebebe. push20 0xbebebebe 0xbebe 0 cds 0 0 0\n| 0x0000001e 5a gas gas 0xbebe 0 cds 0 0 0\n| 0x0000001f f4 delegatecall suc 0\n| 0x00000020 3d returndatasize rds suc 0\n| 0x00000021 82 dup3 0 rds suc 0\n| 0x00000022 80 dup1 0 0 rds suc 0\n| 0x00000023 3e returndatacopy suc 0\n| 0x00000024 90 swap1 0 suc\n| 0x00000025 3d returndatasize rds 0 suc\n| 0x00000026 91 swap2 suc 0 rds\n| 0x00000027 602b push1 0x2b 0x2b suc 0 rds\n| ,=< 0x00000029 57 jumpi 0 rds\n| | 0x0000002a fd revert\n| `-> 0x0000002b 5b jumpdest 0 rds\n\\ 0x0000002c f3 return\n\nNOTE: as an effort to reduce gas costs as much as possible, the above bytecode depends on EIP-211 specification that returndatasize returns zero prior to any calls within the call-frame. returndatasize uses 1 less gas than dup*.\n\n Vanity Address Optimization\n\nProxy deployment can be further optimized by installing the master contract at a vanity contract deployment address with leading zero-bytes. By generating a master contract vanity address that includes Z leading 0 bytes in its address, you can shorten the proxy bytecode by replacing the push20 opcode with pushN (where N is 20 - Z) followed by the N non-zero address bytes. The revert jump address is decremented by Z in this case. Here is an example where Z = 4:\n| 0x00000000 36 calldatasize cds\n| 0x00000001 3d returndatasize 0 cds\n| 0x00000002 3d returndatasize 0 0 cds\n| 0x00000003 37 calldatacopy \n| 0x00000004 3d returndatasize 0\n| 0x00000005 3d returndatasize 0 0 \n| 0x00000006 3d returndatasize 0 0 0\n| 0x00000007 36 calldatasize cds 0 0 0\n| 0x00000008 3d returndatasize 0 cds 0 0 0\n| 0x00000009 6fbebebebebe. push16 0xbebebebe 0xbebe 0 cds 0 0 0\n| 0x0000001a 5a gas gas 0xbebe 0 cds 0 0 0\n| 0x0000001b f4 delegatecall suc 0\n| 0x0000001c 3d returndatasize rds suc 0\n| 0x0000001d 82 dup3 0 rds suc 0\n| 0x0000001e 80 dup1 0 0 rds suc 0\n| 0x0000001f 3e returndatacopy suc 0\n| 0x00000020 90 swap1 0 suc\n| 0x00000021 3d returndatasize rds 0 suc\n| 0x00000022 91 swap2 suc 0 rds\n| 0x00000023 6027 push1 0x27 0x27 suc 0 rds\n| ,=< 0x00000025 57 jumpi 0 rds\n| | 0x00000026 fd revert\n| `-> 0x00000027 5b jumpdest 0 rds\n\\ 0x00000028 f3 return\n\nThis saves 4 bytes of proxy contract size (savings on each deployment) and has zero impact on runtime gas costs.\n\n Copyright\n\nCopyright and related rights waived via CC0.\n\n Citation\n Please cite this document as:\n\n Peter Murray (@yarrumretep), Nate Welch (@flygoing), Joe Messerman (@JAMesserman), \"ERC-1167: Minimal Proxy Contract,\" Ethereum Improvement Proposals, no. 1167, June 2018. Available: https://eips.ethereum.org/EIPS/eip-1167.","tokens":1542,"squid":"spider-05","role":"Spec Spider","at":1791342416068,"hash":"cf8e9f8480e378daea1177e8c8c566c8e3e34dd9"}
{"url":"https://eips.ethereum.org/EIPS/eip-1193","domain":"eips.ethereum.org","title":"EIP-1193: Ethereum Provider JavaScript API","text":"🎉 Final\n\n Standards Track: Interface\n\n EIP-1193: Ethereum Provider JavaScript API\n\n Authors\n Fabian Vogelsteller (@frozeman), Ryan Ghods (@ryanio), Victor Maia (@MaiaVictor), Marc Garreau (@wolovim), Erik Marks (@rekmarks)\n\n Created\n 2018-06-30\n\n Requires\n\n EIP-155, \n\n EIP-695\n\n Summary\n\nA JavaScript Ethereum Provider API for consistency across clients and applications.\n\n Abstract\n\nA common convention in the Ethereum web application (“dapp”) ecosystem is for key management software (“wallets”) to expose their API via a JavaScript object in the web page.\nThis object is called “the Provider”.\n\nHistorically, Provider implementations have exhibited conflicting interfaces and behaviors between wallets.\nThis EIP formalizes an Ethereum Provider API to promote wallet interoperability.\nThe API is designed to be minimal, event-driven, and agnostic of transport and RPC protocols.\nIts functionality is easily extended by defining new RPC methods and message event types.\n\nHistorically, Providers have been made available as window.ethereum in web browsers, but this convention is not part of the specification.\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\n Comments like this are non-normative.\n\n Definitions\n\nThis section is non-normative.\n\n Provider\n\n A JavaScript object made available to a consumer, that provides access to Ethereum by means of a Client.\n\n Client\n\n An endpoint that receives Remote Procedure Call (RPC) requests from the Provider, and returns their results.\n\n Wallet\n\n An end-user application that manages private keys, performs signing operations, and acts as a middleware between the Provider and the Client.\n\n Remote Procedure Call (RPC)\n\n A Remote Procedure Call (RPC), is any request submitted to a Provider for some procedure that is to be processed by a Provider, its Wallet, or its Client.\n\n Connectivity\n\nThe Provider is said to be “connected” when it can service RPC requests to at least one chain.\n\nThe Provider is said to be “disconnected” when it cannot service RPC requests to any chain at all.\n\n To service an RPC request, the Provider must successfully submit the request to the remote location, and receive a response.\nIn other words, if the Provider is unable to communicate with its Client, for example due to network issues, the Provider is disconnected.\n\n API\n\n The Provider API is specified using TypeScript.\nThe authors encourage implementers to declare their own types and interfaces, using the ones in this section as a basis.\n\n For consumer-facing API documentation, see Appendix I\n\nThe Provider MUST implement and expose the API defined in this section.\nAll API entities MUST adhere to the types and interfaces defined in this section.\n\n request\n\n The request method is intended as a transport- and protocol-agnostic wrapper function for Remote Procedure Calls (RPCs).\n\ninterface RequestArguments {\n readonly method: string;\n readonly params?: readonly unknown[] | object;\n}\n\nProvider.request(args: RequestArguments): Promise<unknown>;\n\nThe Provider MUST identify the requested RPC method by the value of RequestArguments.method.\n\nIf the requested RPC method takes any parameters, the Provider MUST accept them as the value of RequestArguments.params.\n\nRPC requests MUST be handled such that the returned Promise either resolves with a value per the requested RPC method’s specification, or rejects with an error.\n\nIf resolved, the Promise MUST resolve with a result per the RPC method’s specification. The Promise MUST NOT resolve with any RPC protocol-specific response objects, unless the RPC method’s return type is so defined.\n\nIf the returned Promise rejects, it MUST reject with a ProviderRpcError as specified in the RPC Errors section below.\n\nThe returned Promise MUST reject if any of the following conditions are met:\n\n An error is returned for the RPC request.\n\n If the returned error is compatible with the ProviderRpcError interface, the Promise MAY reject with that error directly.\n\n The Provider encounters an error or fails to process the request for any reason.\n\n If the Provider implements any kind of authorization logic, the authors recommend rejecting with a 4100 error in case of authorization failures.\n\nThe returned Promise SHOULD reject if any of the following conditions are met:\n\n The Provider is disconnected.\n\n If rejecting for this reason, the Promise rejection error code MUST be 4900.\n\n The RPC request is directed at a specific chain, and the Provider is not connected to that chain, but is connected to at least one other chain.\n\n If rejecting for this reason, the Promise rejection error code MUST be 4901.\n\nSee the section Connectivity for the definitions of “connected” and “disconnected”.\n\n Supported RPC Methods\n\nA “supported RPC method” is any RPC method that may be called via the Provider.\n\nAll supported RPC methods MUST be identified by unique strings.\n\nProviders MAY support whatever RPC methods required to fulfill their purpose, standardized or otherwise.\n\nIf an RPC method defined in a finalized EIP is not supported, it SHOULD be rejected with a 4200 error per the Provider Errors section below, or an appropriate error per the RPC method’s specification.\n\n RPC Errors\n\ninterface ProviderRpcError extends Error {\n code: number;\n data?: unknown;\n}\n\n message\n\n MUST be a human-readable string\n SHOULD adhere to the specifications in the Error Standards section below\n\n code\n\n MUST be an integer number\n SHOULD adhere to the specifications in the Error Standards section below\n\n data\n\n SHOULD contain any other useful information about the error\n\n Error Standards\n\nProviderRpcError codes and messages SHOULD follow these conventions, in order of priority:\n\n The errors in the Provider Errors section below\n\n Any errors mandated by the erroring RPC method’s specification\n\n The CloseEvent status codes\n\n Provider Errors\n\n Status code\n Name\n Description\n\n 4001\n User Rejected Request\n The user rejected the request.\n\n 4100\n Unauthorized\n The requested method and/or account has not been authorized by the user.\n\n 4200\n Unsupported Method\n The Provider does not support the requested method.\n\n 4900\n Disconnected\n The Provider is disconnected from all chains.\n\n 4901\n Chain Disconnected\n The Provider is not connected to the requested chain.\n\n 4900 is intended to indicate that the Provider is disconnected from all chains, while 4901 is intended to indicate that the Provider is disconnected from a specific chain only.\nIn other words, 4901 implies that the Provider is connected to other chains, just not the requested one.\n\n Events\n\nThe Provider MUST implement the following event handling methods:\n\n on\n removeListener\n\nThese methods MUST be implemented per the Node.js EventEmitter API.\n\n To satisfy these requirements, Provider implementers should consider simply extending the Node.js EventEmitter class and bundling it for the target environment.\n\n message\n\n The message event is intended for arbitrary notifications not covered by other events.\n\nWhen emitted, the message event MUST be emitted with an object argument of the following form:\n\ninterface ProviderMessage {\n readonly type: string;\n readonly data: unknown;\n}\n\n Subscriptions\n\nIf the Provider supports Ethereum RPC subscriptions, e.g. eth_subscribe, the Provider MUST emit the message event when it receives a subscription notification.\n\nIf the Provider receives a subscription message from e.g. an eth_subscribe subscription, the Provider MUST emit a message event with a ProviderMessage object of the following form:\n\ninterface EthSubscription extends ProviderMessage {\n readonly type: 'eth_subscription';\n readonly data: {\n readonly subscription: string;\n readonly result: unknown;\n };\n}\n\n connect\n\nSee the section Connectivity for the definition of “connected”.\n\nIf the Provider becomes connected, the Provider MUST emit the event named connect.\n\nThis includes when:\n\n The Provider first connects to a chain after initialization.\n The Provider connects to a chain after the disconnect event was emitted.\n\nThis event MUST be emitted with an object of the following form:\n\ninterface ProviderConnectInfo {\n readonly chainId: string;\n}\n\nchainId MUST specify the integer ID of the connected chain as a hexadecimal string, per the eth_chainId Ethereum RPC method.\n\n disconnect\n\nSee the section Connectivity for the definition of “disconnected”.\n\nIf the Provider becomes disconnected from all chains, the Provider MUST emit the event named disconnect with value error: ProviderRpcError, per the interfaced defined in the RPC Errors section. The value of the error’s code property MUST follow the status codes for CloseEvent.\n\n chainChanged\n\nIf the chain the Provider is connected to changes, the Provider MUST emit the event named chainChanged with value chainId: string, specifying the integer ID of the new chain as a hexadecimal string, per the eth_chainId Ethereum RPC method.\n\n accountsChanged\n\nIf the accounts available to the Provider change, the Provider MUST emit the event named accountsChanged with value accounts: string[], containing the account addresses per the eth_accounts Ethereum RPC method.\n\nThe “accounts available to the Provider” change when the return value of eth_accounts changes.\n\n Rationale\n\nThe purpose of a Provider is to provide a consumer with access to Ethereum.\nIn general, a Provider must enable an Ethereum web application to do two things:\n\n Make Ethereum RPC requests\n Respond to state changes in the Provider’s Ethereum chain, Client, and Wallet\n\nThe Provider API specification consists of a single method and five events.\nThe request method and the message event alone, are sufficient to implement a complete Provider.\nThey are designed to make arbitrary RPC requests and communicate arbitrary messages, respectively.\n\nThe remaining four events can be separated into two categories:\n\n Changes to the Provider’s ability to make RPC requests\n\n connect\n disconnect\n\n Common Client and/or Wallet state changes that any non-trivial application must handle\n\n chainChanged\n accountsChanged\n\nThese events are included due to the widespread production usage of related patterns, at the time of writing.\n\n Backwards Compatibility\n\nMany Providers adopted a draft version of this specification before it was finalized.\nThe current API is designed to be a strict superset of the legacy version, and this specification is in that sense fully backwards compatible.\nSee Appendix III for the legacy API.\n\nProviders that only implement this specification will not be compatible with Ethereum web applications that target the legacy API.\n\n Implementations\n\nAt the time of writing, the following projects have working implementations:\n\n buidler.dev\n ethers.js\n eth-provider\n MetaMask\n WalletConnect\n web3.js\n\n Security Considerations\n\nThe Provider is intended to pass messages between an Ethereum Client and an Ethereum application.\nIt is not responsible for private key or account management; it merely processes RPC messages and emits events.\nConsequently, account security and user privacy need to be implemented in middlewares between the Provider and its Ethereum Client.\nIn practice, we call these middleware applications “Wallets,” and they usually manage the user’s private keys and accounts.\nThe Provider can be thought of as an extension of the Wallet, exposed in an untrusted environment, under the control of some third party (e.g. a website).\n\n Handling Adversarial Behavior\n\nSince it is a JavaScript object, consumers can generally perform arbitrary operations on the Provider, and all its properties can be read or overwritten.\nTherefore, it is best to treat the Provider object as though it is controlled by an adversary.\nIt is paramount that the Provider implementer protects the user, Wallet, and Client by ensuring that:\n\n The Provider does not contain any private user data.\n The Provider and Wallet programs are isolated from each other.\n The Wallet and/or Client rate-limit requests from the Provider.\n The Wallet and/or Client validate all data sent from the Provider.\n\n Chain Changes\n\nSince all Ethereum operations are directed at a particular chain, it’s important that the Provider accurately reflects the Client’s configured chain, per the eth_chainId Ethereum RPC method (see EIP-695).\n\nThis includes ensuring that eth_chainId has the correct return value, and that the chainChanged event is emitted whenever that value changes.\n\n User Account Exposure and Account Changes\n\nMany Ethereum write operations (e.g. eth_sendTransaction) require a user account to be specified.\nProvider consumers access these accounts via the eth_accounts RPC method, and by listening for the accountsChanged event.\n\nAs with eth_chainId, it is critical that eth_accounts has the correct return value, and that the accountsChanged event is emitted whenever that value changes.\n\nThe return value of eth_accounts is ultimately controlled by the Wallet or Client.\nIn order to protect user privacy, the authors recommend not exposing any accounts by default.\nInstead, Providers should support RPC methods for explicitly requesting account access, such as eth_requestAccounts (see EIP-1102) or wallet_requestPermissions (see EIP-2255).\n\n References\n\n Initial discussion in ethereum/interfaces\n Deprecated Ethereum Magicians thread\n Continuing discussion\n Related EIPs\n\n EIP-1102: Opt-in Account Exposure\n EIP-1474: Remote Procedure Call Specification\n EIP-1767: GraphQL Interface to Ethereum Node Data\n EIP-2255: Wallet Permissions\n\n Copyright\n\nCopyright and related rights waived via CC0.\n\n Appendix I: Consumer-Facing API Documentation\n\n request\n\nMakes an Ethereum RPC method call.\n\ninterface RequestArguments {\n readonly method: string;\n readonly params?: readonly unknown[] | object;\n}\n\nProvider.request(args: RequestArguments): Promise<unknown>;\n\nThe returned Promise resolves with the method’s result or rejects with a ProviderRpcError. For example:\n\nProvider.request({ method: 'eth_accounts' })\n .then((accounts) => console.log(accounts))\n .catch((error) => console.error(error));\n\nConsult each Ethereum RPC method’s documentation for its params and return type.\nYou can find a list of common methods here.\n\n RPC Protocols\n\nMultiple RPC protocols may be available. For examples, see:\n\n EIP-1474, the Ethereum JSON-RPC API\n EIP-1767, the Ethereum GraphQL schema\n\n Events\n\nEvents follow the conventions of the Node.js EventEmitter API.\n\n connect\n\nThe Provider emits connect when it:\n\n first connects to a chain after being initialized.\n first connects to a chain, after the disconnect event was emitted.\n\ninterface ProviderConnectInfo {\n readonly chainId: string;\n}\n\nProvider.on('connect', listener: (connectInfo: ProviderConnectInfo) => void): Provider;\n\nThe event emits an object with a hexadecimal string chainId per the eth_chainId Ethereum RPC method, and other properties as determined by the Provider.\n\n disconnect\n\nThe Provider emits disconnect when it becomes disconnected from all chains.\n\nProvider.on('disconnect', listener: (error: ProviderRpcError) => void): Provider;\n\nThis event emits a ProviderRpcError. The error code follows the table of CloseEvent status codes.\n\n chainChanged\n\nThe Provider emits chainChanged when connecting to a new chain.\n\nProvider.on('chainChanged', listener: (chainId: string) => void): Provider;\n\nThe event emits a hexadecimal string chainId per the eth_chainId Ethereum RPC method.\n\n accountsChanged\n\nThe Provider emits accountsChanged if the accounts returned from the Provider (eth_accounts) change.\n\nProvider.on('accountsChanged', listener: (accounts: string[]) => void): Provider;\n\nThe event emits with accounts, an array of account addresses, per the eth_accounts Ethereum RPC method.\n\n message\n\nThe Provider emits message to communicate arbitrary messages to the consumer.\nMessages may include JSON-RPC notifications, GraphQL subscriptions, and/or any other event as defined by the Provider.\n\ninterface ProviderMessage {\n readonly type: string;\n readonly data: unknown;\n}\n\nProvider.on('message', listener: (message: ProviderMessage) => void): Provider;\n\n Subscriptions\n\neth_ subscription methods and shh_ subscription methods rely on this event to emit subscription updates.\n\nFor e.g. eth_subscribe subscription updates, ProviderMessage.type will equal the string 'eth_subscription', and the subscription data will be the value of ProviderMessage.data.\n\n Errors\n\ninterface ProviderRpcError extends Error {\n message: string;\n code: number;\n data?: unknown;\n}\n\n Appendix II: Examples\n\nThese examples assume a web browser environment.\n\n// Most Providers are available as window.ethereum on page load.\n// This is only a convention, not a standard, and may not be the case in practice.\n// Please consult the Provider implementation's documentation.\nconst ethereum = window.ethereum;\n\n// Example 1: Log chainId\nethereum\n .request({ method: 'eth_chainId' })\n .then((chainId) => {\n console.log(`hexadecimal string: ${chainId}`);\n console.log(`decimal number: ${parseInt(chainId, 16)}`);\n })\n .catch((error) => {\n console.error(`Error fetching chainId: ${error.code}: ${error.message}`);\n });\n\n// Example 2: Log last block\nethereum\n .request({\n method: 'eth_getBlockByNumber',\n params: ['latest', true],\n })\n .then((block) => {\n console.log(`Block ${block.number}:`, block);\n })\n .catch((error) => {\n console.error(\n `Error fetching last block: ${error.message}.\n Code: ${error.code}. Data: ${error.data}`\n );\n });\n\n// Example 3: Log available accounts\nethereum\n .request({ method: 'eth_accounts' })\n .then((accounts) => {\n console.log(`Accounts:\\n${accounts.join('\\n')}`);\n })\n .catch((error) => {\n console.error(\n `Error fetching accounts: ${error.message}.\n Code: ${error.code}. Data: ${error.data}`\n );\n });\n\n// Example 4: Log new blocks\nethereum\n .request({\n method: 'eth_subscribe',\n params: ['newHeads'],\n })\n .then((subscriptionId) => {\n ethereum.on('message', (message) => {\n if (message.type === 'eth_subscription') {\n const { data } = message;\n if (data.subscription === subscriptionId) {\n if ('result' in data && typeof data.result === 'object') {\n const block = data.result;\n console.log(`New block ${block.number}:`, block);\n } else {\n console.error(`Something went wrong: ${data.result}`);\n }\n }\n }\n });\n })\n .catch((error) => {\n console.error(\n `Error making newHeads subscription: ${error.message}.\n Code: ${error.code}. Data: ${error.data}`\n );\n });\n\n// Example 5: Log when accounts change\nconst logAccounts = (accounts) => {\n console.log(`Accounts:\\n${accounts.join('\\n')}`);\n};\nethereum.on('accountsChanged', logAccounts);\n// to unsubscribe\nethereum.removeListener('accountsChanged', logAccounts);\n\n// Example 6: Log if connection ends\nethereum.on('disconnect', (code, reason) => {\n console.log(`Ethereum Provider connection closed: ${reason}. Code: ${code}`);\n});\n\n Appendix III: Legacy Provider API\n\nThis section documents the legacy Provider API, which is extensively used in production at the time of writing.\nAs it was never fully standardized, significant deviations occur in practice.\nThe authors recommend against implementing it except to support legacy Ethereum applications.\n\n sendAsync (DEPRECATED)\n\nThis method is superseded by request.\n\nsendAsync is like request, but with JSON-RPC objects and a callback.\n\nProvider.sendAsync(request: Object, callback: Function): void;\n\nHistorically, the request and response object interfaces have followed the Ethereum JSON-RPC specification.\n\n send (DEPRECATED)\n\nThis method is superseded by request.\n\nProvider.send(...args: unknown[]): unknown;\n\n Legacy Events\n\n close (DEPRECATED)\n\nThis event is superseded by disconnect.\n\n networkChanged (DEPRECATED)\n\nThe event networkChanged is superseded by chainChanged.\n\nFor details, see EIP-155: Simple replay attack protection and EIP-695: Create eth_chainId method for JSON-RPC.\n\n notification (DEPRECATED)\n\nThis event is superseded by message.\n\nHistorically, this event has been emitted with e.g. eth_subscribe subscription updates of the form { subscription: string, result: unknown }.\n\n Citation\n Please cite this document as:\n\n Fabian Vogelsteller (@frozeman), Ryan Ghods (@ryanio), Victor Maia (@MaiaVictor), Marc Garreau (@wolovim), Erik Marks (@rekmarks), \"EIP-1193: Ethereum Provider JavaScript API,\" Ethereum Improvement Proposals, no. 1193, June 2018. Available: https://eips.ethereum.org/EIPS/eip-1193.","tokens":5105,"squid":"spider-05","role":"Spec Spider","at":1791342425917,"hash":"b482d6195f66463278d54a4bfd2b34f8e5b4aa86"}
{"url":"https://eips.ethereum.org/EIPS/eip-1234","domain":"eips.ethereum.org","title":"EIP-1234: Constantinople Difficulty Bomb Delay and Block Reward Adjustment","text":"🎉 Final\n\n Standards Track: Core\n\n EIP-1234: Constantinople Difficulty Bomb Delay and Block Reward Adjustment\n\n Authors\n Afri Schoedon (@5chdn)\n\n Created\n 2018-07-19\n\n Simple Summary\n\nThe average block times are increasing due to the difficulty bomb (also known as the “ice age”) slowly accelerating. This EIP proposes to delay the difficulty bomb for approximately 12 months and to reduce the block rewards with the Constantinople fork, the second part of the Metropolis fork.\n\n Abstract\n\nStarting with CNSTNTNPL_FORK_BLKNUM the client will calculate the difficulty based on a fake block number suggesting the client that the difficulty bomb is adjusting around 5 million blocks later than previously specified with the Homestead fork. Furthermore, block rewards will be adjusted to a base of 2 ETH, uncle and nephew rewards will be adjusted accordingly.\n\n Motivation\n\nThe Casper development and switch to proof-of-stake is delayed, the Ethash proof-of-work should be feasible for miners and allow sealing new blocks every 15 seconds on average for another 12 months. With the delay of the ice age, there is a desire to not suddenly also increase miner rewards. The difficulty bomb has been known about for a long time and now it’s going to stop from happening. In order to maintain stability of the system, a block reward reduction that offsets the ice age delay would leave the system in the same general state as before. Reducing the reward also decreases the likelihood of a miner driven chain split as Ethereum approaches proof-of-stake.\n\n Specification\n\n Relax Difficulty with Fake Block Number\n\nFor the purposes of calc_difficulty, simply replace the use of block.number, as used in the exponential ice age component, with the formula:\n\nfake_block_number = max(0, block.number - 5_000_000) if block.number >= CNSTNTNPL_FORK_BLKNUM else block.number\n\n Adjust Block, Uncle, and Nephew rewards\n\nTo ensure a constant Ether issuance, adjust the block reward to new_block_reward, where\n\nnew_block_reward = 2_000_000_000_000_000_000 if block.number >= CNSTNTNPL_FORK_BLKNUM else block.reward\n\n(2E18 wei, or 2,000,000,000,000,000,000 wei, or 2 ETH).\n\nAnalogue, if an uncle is included in a block for block.number >= CNSTNTNPL_FORK_BLKNUM such that block.number - uncle.number = k, the uncle reward is\n\nnew_uncle_reward = (8 - k) * new_block_reward / 8\n\nThis is the existing pre-Constantinople formula for uncle rewards, simply adjusted with new_block_reward.\n\nThe nephew reward for block.number >= CNSTNTNPL_FORK_BLKNUM is\n\nnew_nephew_reward = new_block_reward / 32\n\nThis is the existing pre-Constantinople formula for nephew rewards, simply adjusted with new_block_reward.\n\n Rationale\n\nThis will delay the ice age by 29 million seconds (approximately 12 months), so the chain would be back at 30 second block times in winter 2019. An alternate proposal was to add special rules to the difficulty calculation to effectively pause the difficulty between different blocks. This would lead to similar results.\n\nThis was previously discussed at All Core Devs Meeting #42 and subsequent meetings; and accepted in the Constantinople Session #1.\n\n Backwards Compatibility\n\nThis EIP is not forward compatible and introduces backwards incompatibilities in the difficulty calculation, as well as the block, uncle and nephew reward structure. Therefore, it should be included in a scheduled hardfork at a certain block number. It’s suggested to include this EIP in the second Metropolis hard-fork, Constantinople.\n\n Test Cases\n\nTest cases shall be created once the specification is to be accepted by the developers or implemented by the clients.\n\n Implementation\n\nThe implementation in it’s logic does not differ from EIP-649; an implementation for Parity-Ethereum is available in parity-ethereum#9187.\n\n Copyright\n\nCopyright and related rights waived via CC0.\n\n Citation\n Please cite this document as:\n\n Afri Schoedon (@5chdn), \"EIP-1234: Constantinople Difficulty Bomb Delay and Block Reward Adjustment,\" Ethereum Improvement Proposals, no. 1234, July 2018. Available: https://eips.ethereum.org/EIPS/eip-1234.","tokens":1025,"squid":"spider-05","role":"Spec Spider","at":1791342437918,"hash":"3b3b208bb505fd21caf09b9f4794c64ea1837949"}
{"url":"https://squidfunk.github.io/mkdocs-material/reference/code-blocks/","domain":"squidfunk.github.io","title":"Code blocks - Material for MkDocs","text":"Code blocks¶ Code blocks and examples are an essential part of technical project documentation. Material for MkDocs provides different ways to set up syntax highlighting for code blocks, either during build time using Pygments or during runtime using a JavaScript syntax highlighter. Configuration¶ This configuration enables syntax highlighting on code blocks and inline code blocks, and allows to include source code directly from other files. Add the following lines to mkdocs.yml: markdown_extensions:\n - pymdownx.highlight:\n anchor_linenums: true\n line_spans: __span\n pygments_lang_class: true\n - pymdownx.inlinehilite\n - pymdownx.snippets\n - pymdownx.superfences\n The following sections discuss how to use different syntax highlighting features with Pygments, the recommended highlighter, so they don't apply when using a JavaScript syntax highlighter. See additional configuration options: Highlight InlineHilite SuperFences Snippets Code copy button¶ 9.0.0 Code blocks can automatically render a button on the right side to allow the user to copy a code block's contents to the clipboard. Add the following to mkdocs.yml to enable them globally: theme:\n features:\n - content.code.copy\n Enabling or disabling code copy buttons for a specific code block If you don't want to enable code copy buttons globally, you can enable them for a specific code block by using a slightly different syntax based on the Attribute Lists extension: ``` { .yaml .copy }\n# Code block content\n```\n Note that there must be a language shortcode, which has to come first and must also be prefixed by a .. Similarly, the copy button can also be disabled for a specific code block: ``` { .yaml .no-copy }\n# Code block content\n```\n To enable or disable the copy button without syntax highlighting, you can use the .text language shortcode, which doesn't highlight anything. Code selection button¶ 9.7.0 Code blocks can include a button to allow for the selection of line ranges by the user, which is perfect for linking to a specific subsection of a code block. This allows the user to apply line highlighting dynamically. Add the following to mkdocs.yml to enable it globally: theme:\n features:\n - content.code.select\n Enabling or disabling code selection buttons for a specific code block If you don't want to enable code selection buttons globally, you can enable them for a specific code block by using a slightly different syntax based on the Attribute Lists extension: ``` { .yaml .select }\n# Code block content\n```\n Note that the language shortcode which has to come first must now also be prefixed by a .. Similarly, the selection button can also be disabled for a specific code block: ``` { .yaml .no-select }\n# Code block content\n```\n Code annotations¶ 8.0.0 Code annotations offer a comfortable and friendly way to attach arbitrary content to specific sections of code blocks by adding numeric markers in block and inline comments in the language of the code block. Add the following to mkdocs.yml to enable them globally: theme:\n features:\n - content.code.annotate \n Enabling code annotations for a specific code block If you don't want to enable code annotations globally, because you don't like the automatic inlining behavior, you can enable them for a specific code block by using a slightly different syntax based on the Attribute Lists extension: ``` { .yaml .annotate }\n# Code block content\n```\n Note that the language shortcode which has to come first must now also be prefixed by a .. Custom selectors¶ 9.7.0 Normally, code annotations can only be placed in comments, as comments can be considered safe for placement. However, sometimes it might be necessary to place annotations in parts of the code block where comments are not allowed, e.g. in strings. Additional selectors can be set per-language: extra:\n annotate:\n json: [.s2] \n Now, code annotations can be used from within strings in JSON: {\n \"key\": \"value \"\n}\n Usage¶ Code blocks must be enclosed with two separate lines containing three backticks. To add syntax highlighting to those blocks, add the language shortcode directly after the opening block. See the list of available lexers to find the shortcode for a given language: Code block``` py\nimport tensorflow as tf\n```\n import tensorflow as tf\n Adding a title¶ In order to provide additional context, a custom title can be added to a code block by using the title=\"<custom title>\" option directly after the shortcode, e.g. to display the name of a file: Code block with title``` py title=\"bubble_sort.py\"\ndef bubble_sort(items):\n for i in range(len(items)):\n for j in range(len(items) - 1 - i):\n if items[j] > items[j + 1]:\n items[j], items[j + 1] = items[j + 1], items[j]\n```\n bubble_sort.pydef bubble_sort(items):\n for i in range(len(items)):\n for j in range(len(items) - 1 - i):\n if items[j] > items[j + 1]:\n items[j], items[j + 1] = items[j + 1], items[j]\n Adding annotations¶ Code annotations can be placed anywhere in a code block where a comment for the language of the block can be placed, e.g. for JavaScript in // ... and /* ... */, for YAML in # ..., etc.1: Code block with annotation``` yaml\ntheme:\n features:\n - content.code.annotate # (1)\n```\n\n1. :man_raising_hand: I'm a code annotation! I can contain `code`, __formatted\n text__, images, ... basically anything that can be written in Markdown.\n theme:\n features:\n - content.code.annotate # \n Stripping comments¶ 8.5.0 If you wish to strip the comment characters surrounding a code annotation, simply add an ! after the closing parenthesis of the code annotation: Code block with annotation, stripped``` yaml\n# (1)!\n```\n\n1. Look ma, less line noise!\n\n Note that this only allows for a single code annotation to be rendered per comment. If you want to add multiple code annotations, comments cannot be stripped for technical reasons. Adding line numbers¶ Line numbers can be added to a code block by using the linenums=\"<start>\" option directly after the shortcode, whereas <start> represents the starting line number. A code block can start from a line number other than 1, which allows to split large code blocks for readability: Code block with line numbers``` py linenums=\"1\"\ndef bubble_sort(items):\n for i in range(len(items)):\n for j in range(len(items) - 1 - i):\n if items[j] > items[j + 1]:\n items[j], items[j + 1] = items[j + 1], items[j]\n```\n 1\n2\n3\n4\n5def bubble_sort(items):\n for i in range(len(items)):\n for j in range(len(items) - 1 - i):\n if items[j] > items[j + 1]:\n items[j], items[j + 1] = items[j + 1], items[j]\n Highlighting specific lines¶ Specific lines can be highlighted by passing the line numbers to the hl_lines argument placed right after the language shortcode. Note that line counts start at 1, regardless of the starting line number specified as part of linenums: LinesLine ranges Code block with highlighted lines``` py hl_lines=\"2 3\"\ndef bubble_sort(items):\n for i in range(len(items)):\n for j in range(len(items) - 1 - i):\n if items[j] > items[j + 1]:\n items[j], items[j + 1] = items[j + 1], items[j]\n```\n 1\n2\n3\n4\n5def bubble_sort(items):\n for i in range(len(items)):\n for j in range(len(items) - 1 - i):\n if items[j] > items[j + 1]:\n items[j], items[j + 1] = items[j + 1], items[j]\n Code block with highlighted line range``` py hl_lines=\"3-5\"\ndef bubble_sort(items):\n for i in range(len(items)):\n for j in range(len(items) - 1 - i):\n if items[j] > items[j + 1]:\n items[j], items[j + 1] = items[j + 1], items[j]\n```\n 1\n2\n3\n4\n5def bubble_sort(items):\n for i in range(len(items)):\n for j in range(len(items) - 1 - i):\n if items[j] > items[j + 1]:\n items[j], items[j + 1] = items[j + 1], items[j]\n Highlighting inline code blocks¶ When InlineHilite is enabled, syntax highlighting can be applied to inline code blocks by prefixing them with a shebang, i.e. #!, directly followed by the corresponding language shortcode. Inline code blockThe `#!python range()` function is used to generate a sequence of numbers.\n The range() function is used to generate a sequence of numbers. Embedding external files¶ When Snippets is enabled, content from other files (including source files) can be embedded by using the --8<-- notation directly from within a code block: Code block with external content``` title=\".browserslistrc\"\n--8<-- \".browserslistrc\"\n```\n .browserslistrclast 4 years\n Customization¶ Custom syntax theme¶ If Pygments is used, Material for MkDocs provides the styles for code blocks, which are built with a custom and well-balanced palette that works equally well for both color schemes: --md-code-hl-number-color --md-code-hl-special-color --md-code-hl-function-color --md-code-hl-constant-color --md-code-hl-keyword-color --md-code-hl-string-color --md-code-hl-name-color --md-code-hl-operator-color --md-code-hl-punctuation-color --md-code-hl-comment-color --md-code-hl-generic-color --md-code-hl-variable-color Code block foreground, background and line highlight colors are defined via: --md-code-fg-color --md-code-bg-color --md-code-hl-color Let's say you want to change the color of \"strings\". While there are several types of string tokens, they use the same color. You can assign a new color by using an additional style sheet: docs/stylesheets/extra.css mkdocs.yml :root > * {\n --md-code-hl-string-color: #0FF1CE;\n}\n extra_css:\n - stylesheets/extra.css\n If you want to tweak a specific type of string, e.g. `backticks`, you can lookup the specific CSS class name in the syntax theme definition, and override it as part of your additional style sheet: docs/stylesheets/extra.css mkdocs.yml .highlight .sb {\n color: #0FF1CE;\n}\n extra_css:\n - stylesheets/extra.css\n Annotation tooltip width¶ If you have a lot of content hosted inside your code annotations, it can be a good idea to increase the width of the tooltip by adding the following as part of an additional style sheet: docs/stylesheets/extra.css mkdocs.yml :root {\n --md-tooltip-width: 600px;\n}\n extra_css:\n - stylesheets/extra.css\n This will render annotations with a larger width: \n Code annotations require syntax highlighting with Pygments – they're currently not compatible with JavaScript syntax highlighters, or languages that do not have comments in their grammar. However, we're actively working on supporting alternate ways of defining code annotations, allowing to always place code annotations at the end of lines. ↩","tokens":2579,"squid":"spider-06","role":"Security Spider","at":1791342448712,"hash":"1145ca0bf0e2db96d056dfd7ee6546853a940049"}
{"url":"https://docs.switchboard.xyz/docs-by-chain/sui/surge/surge-tutorial","domain":"docs.switchboard.xyz","title":"Surge Tutorial | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.Example Code: The complete working example for this tutorial is available at sb-on-demand-examples/sui/surge/basicThis tutorial shows you how to stream real-time price data via WebSocket using Switchboard Surge and submit updates to the Sui blockchain. This approach is ideal for applications requiring sub-second price updates.Version source of truth: SDK Version MatrixWhat You'll BuildA TypeScript application that:Connects to Switchboard Surge for real-time price streaming via WebSocketReceives signed price updates with sub-second latencySubmits price updates to the Sui blockchainTracks latency statistics and oracle performancePrerequisitesSui CLI installed (Installation Guide)Node.js 21+ and npm/pnpmA Sui keypair with SUI tokens (in your Sui keystore) for signing Sui transactionsA Solana keypair with an active Surge subscription (subscribe here)Surge subscriptions are currently Solana-only; you cannot subscribe with a Sui keypair yet.Key ConceptsSurge vs On-Demand QuotesFeatureOn-Demand QuotesSurge StreamingUpdate frequencyRequest-basedContinuous (~100ms)LatencyHigher (HTTP request)Lower (WebSocket)Use caseOccasional readsReal-time appsAuthenticationNone requiredSubscription requiredThe emitSurgeQuote FunctionSurge provides the emitSurgeQuote() function from @switchboard-xyz/sui-sdk that converts Surge updates into Sui transactions. This handles:Oracle signature formattingTransaction buildingQuote verification setupOracle MappingSurge returns oracle public keys, but Sui needs oracle object IDs. The example fetches a mapping from Crossbar to convert between these formats.Transaction Queue ManagementSince Sui transactions are sequential, the example implements a queue to:Buffer incoming price updatesProcess one transaction at a timeTrack processing latencyThe Streaming ClientHere's the complete mainnet streaming example:import * as sb from '@switchboard-xyz/on-demand';\nimport { SuiClient } from '@mysten/sui/client';\nimport {\n SwitchboardClient,\n emitSurgeQuote,\n} from '@switchboard-xyz/sui-sdk';\nimport { fromB64 } from '@mysten/bcs';\nimport { Ed25519Keypair } from '@mysten/sui/keypairs/ed25519';\nimport { Connection, Keypair as SolanaKeypair } from '@solana/web3.js';\nimport * as path from 'path';\nimport * as os from 'os';\nimport * as fs from 'fs';\nimport { Transaction } from '@mysten/sui/transactions';\n\n// Initialize Sui clients\nconst suiClient = new SuiClient({ url: 'https://fullnode.mainnet.sui.io:443' });\nconst switchboardClient = new SwitchboardClient(suiClient);\nconst solanaConnection = new Connection('https://api.mainnet-beta.solana.com');\n\n// Oracle mapping cache\nconst oracleMapping = new Map<string, string>();\nlet lastOracleFetch = 0;\nconst ORACLE_CACHE_TTL = 1000 * 60 * 10; // 10 minutes\n\n// Transaction queue management\nlet isTransactionProcessing = false;\nconst rawResponseQueue: Array<{\n rawResponse: any;\n timestamp: number;\n}> = [];\n\n// Process transaction queue - ensures only one transaction at a time\nasync function processTransactionQueue(): Promise<void> {\n if (isTransactionProcessing || rawResponseQueue.length === 0) {\n return;\n }\n\n isTransactionProcessing = true;\n\n try {\n const queueItem = rawResponseQueue.shift()!;\n const { rawResponse, timestamp } = queueItem;\n\n console.log(`Processing transaction (queue length: ${rawResponseQueue.length})`);\n\n const transaction = new Transaction();\n\n // Convert Surge update to Sui transaction\n await emitSurgeQuote(switchboardClient, transaction, rawResponse);\n\n const result = await suiClient.signAndExecuteTransaction({\n transaction: transaction,\n signer: suiKeypair!,\n options: {\n showEvents: true,\n showEffects: true,\n },\n });\n\n const processingTime = Date.now() - timestamp;\n console.log(`Transaction completed in ${processingTime}ms`);\n console.log('Transaction result:', result.digest);\n } catch (error) {\n console.error('Transaction failed:', error);\n } finally {\n isTransactionProcessing = false;\n\n // Process next transaction in queue if any\n if (rawResponseQueue.length > 0) {\n setImmediate(() => processTransactionQueue());\n }\n }\n}\n\n// Fetch oracle mappings from Crossbar\nasync function fetchOracleMappings(): Promise<Map<string, string>> {\n const now = Date.now();\n\n if (oracleMapping.size > 0 && now - lastOracleFetch < ORACLE_CACHE_TTL) {\n return oracleMapping;\n }\n\n try {\n const response = await fetch('https://crossbar.switchboard.xyz/oracles/sui');\n const oracles = (await response.json()) as Array<{\n oracle_id: string;\n oracle_key: string;\n }>;\n\n oracleMapping.clear();\n for (const oracle of oracles) {\n const cleanKey = oracle.oracle_key.startsWith('0x')\n ? oracle.oracle_key.slice(2)\n : oracle.oracle_key;\n oracleMapping.set(cleanKey, oracle.oracle_id);\n }\n\n lastOracleFetch = now;\n console.log(`Loaded ${oracleMapping.size} oracle mappings`);\n return oracleMapping;\n } catch (error) {\n console.error('Failed to fetch oracle mappings:', error);\n return oracleMapping;\n }\n}\n\n// Calculate latency statistics\nfunction calculateStatistics(latencies: number[]) {\n const sorted = [...latencies].sort((a, b) => a - b);\n const sum = sorted.reduce((a, b) => a + b, 0);\n\n return {\n min: sorted[0],\n max: sorted[sorted.length - 1],\n median: sorted[Math.floor(sorted.length / 2)],\n mean: sum / sorted.length,\n count: sorted.length,\n };\n}\n\n// Load Sui keypair (for signing Sui transactions)\nlet suiKeypair: Ed25519Keypair | null = null;\n\ntry {\n const keystorePath = path.join(os.homedir(), '.sui', 'sui_config', 'sui.keystore');\n const keystore = JSON.parse(fs.readFileSync(keystorePath, 'utf-8'));\n const secretKey = fromB64(keystore[0]);\n suiKeypair = Ed25519Keypair.fromSecretKey(secretKey.slice(1));\n} catch (error) {\n console.error('Error loading Sui keypair:', error);\n}\n\n// Load Solana keypair (subscription owner)\nlet solanaKeypair: SolanaKeypair | null = null;\n\ntry {\n const solanaKeypairPath =\n process.env.SOLANA_KEYPAIR_PATH ||\n path.join(os.homedir(), '.config', 'solana', 'id.json');\n const secretKey = Uint8Array.from(\n JSON.parse(fs.readFileSync(solanaKeypairPath, 'utf-8'))\n );\n solanaKeypair = SolanaKeypair.fromSecretKey(secretKey);\n} catch (error) {\n console.error('Error loading Solana keypair:', error);\n}\n\nif (!suiKeypair) {\n throw new Error('Sui keypair not loaded');\n}\n\nif (!solanaKeypair) {\n throw new Error('Solana keypair not loaded');\n}\n\n// Main function\n(async function main() {\n console.log('Starting Surge streaming...');\n console.log(`Using Sui keypair: ${suiKeypair!.toSuiAddress()}`);\n console.log(`Using Solana keypair: ${solanaKeypair!.publicKey.toBase58()}`);\n\n const latencies: number[] = [];\n\n // Initialize Surge with Solana keypair (subscription owner)\n const surge = new sb.Surge({\n connection: solanaConnection,\n keypair: solanaKeypair!,\n signatureScheme: 'ed25519',\n });\n // Auth note: the SDK signs with your Solana keypair to authenticate the session.\n // If the keypair has no active Surge subscription, connectAndSubscribe will fail.\n\n // Connect and subscribe to feeds\n await surge.connectAndSubscribe([{ symbol: 'BTC/USD' }]);\n\n // Pre-fetch oracle mappings\n await fetchOracleMappings();\n\n // Listen for price updates\n surge.on('signedPriceUpdate', async (response: sb.SurgeUpdate) => {\n const currentLatency = Date.now() - response.data.source_ts_ms;\n latencies.push(currentLatency);\n\n const rawResponse = response.getRawResponse();\n const stats = calculateStatistics(latencies);\n const formattedPrices = response.getFormattedPrices();\n const currentPrice = Object.values(formattedPrices)[0] || 'N/A';\n\n console.log(\n `Update #${stats.count} | Price: ${currentPrice} | Latency: ${currentLatency}ms | Avg: ${stats.mean.toFixed(1)}ms`\n );\n\n // Queue the update for processing\n rawResponseQueue.push({\n rawResponse,\n timestamp: Date.now(),\n });\n\n // Trigger queue processing\n processTransactionQueue();\n });\n\n console.log('Listening for price updates...');\n})();Code WalkthroughSetupconst suiClient = new SuiClient({ url: 'https://fullnode.mainnet.sui.io:443' });\nconst switchboardClient = new SwitchboardClient(suiClient);\nconst solanaConnection = new Connection('https://api.mainnet-beta.solana.com');Initialize the Sui client you will submit transactions through, plus a Solana RPC connection for Surge authentication. For Sui testnet, use https://fullnode.testnet.sui.io:443.Creating Surge Connectionconst surge = new sb.Surge({\n connection: solanaConnection,\n keypair: solanaKeypair!,\n signatureScheme: 'ed25519',\n});\n\nawait surge.connectAndSubscribe([{ symbol: 'BTC/USD' }]);connection: Your Solana Connection instancekeypair: Your Solana keypair (must have an active Surge subscription)signatureScheme: Use 'ed25519' for Solana keypairsconnectAndSubscribe(): Connects and subscribes to specified feedsHandling Updatessurge.on('signedPriceUpdate', async (response: sb.SurgeUpdate) => {\n const rawResponse = response.getRawResponse();\n const formattedPrices = response.getFormattedPrices();\n // ...\n});The signedPriceUpdate event fires whenever new price data arrives. Key methods:getRawResponse(): Returns the raw signed data for transaction submissiongetFormattedPrices(): Returns human-readable pricesSubmitting to Suiconst transaction = new Transaction();\nawait emitSurgeQuote(switchboardClient, transaction, rawResponse);\n\nconst result = await suiClient.signAndExecuteTransaction({\n transaction,\n signer: suiKeypair,\n});The emitSurgeQuote() function handles converting the Surge response into a valid Sui transaction.Mainnet vs TestnetThe mainnet and testnet examples are nearly identical with these differences:SettingMainnetTestnetRPC URLhttps://fullnode.mainnet.sui.io:443https://fullnode.testnet.sui.io:443Oracle Mapping/oracles/sui/oracles/sui/testnetTestnet Configuration// Testnet setup\nconst suiClient = new SuiClient({ url: 'https://fullnode.testnet.sui.io:443' });\nconst solanaConnection = new Connection('https://api.mainnet-beta.solana.com');\n\nconst surge = new sb.Surge({\n connection: solanaConnection,\n keypair: solanaKeypair!,\n signatureScheme: 'ed25519',\n});\n\n// Testnet oracle mapping endpoint\nconst response = await fetch('https://crossbar.switchboard.xyz/oracles/sui/testnet');Running the Examples1. Clone the Repositorygit clone https://github.com/switchboard-xyz/sb-on-demand-examples\ncd sb-on-demand-examples/sui/surge/basic2. Install Dependenciesnpm install3. Ensure Active SubscriptionYour Solana keypair (default ~/.config/solana/id.json or SOLANA_KEYPAIR_PATH) must have an active Surge subscription. The Sui keypair only signs Sui transactions. Subscribe at explorer.switchboardlabs.xyz/subscriptions.4. Run the Examples# Mainnet streaming\nnpm run stream\n\n# Testnet streaming\nnpm run stream:testnetExpected OutputStarting Surge streaming...\nUsing Sui keypair: 0x...\nUsing Solana keypair: 9k...\nLoaded 15 oracle mappings\nListening for price updates...\nUpdate #1 | Price: 97234.50 | Latency: 85ms | Avg: 85.0ms\nProcessing transaction (queue length: 0)\nTransaction completed in 1234ms\nTransaction result: 8Js7NsQ7...\nUpdate #2 | Price: 97235.10 | Latency: 92ms | Avg: 88.5ms\n...Adding to Your ProjectDependenciesnpm install @switchboard-xyz/on-demand@3.10.6 @switchboard-xyz/sui-sdk@0.1.16 @mysten/sui@1.38.0 @solana/web3.js@1.98.4Minimal IntegrationThis example assumes you already loaded a solanaKeypair (with an active Surge subscription) and a suiKeypair (for signing Sui transactions).import * as sb from '@switchboard-xyz/on-demand';\nimport { SuiClient } from '@mysten/sui/client';\nimport { SwitchboardClient, emitSurgeQuote } from '@switchboard-xyz/sui-sdk';\nimport { Transaction } from '@mysten/sui/transactions';\nimport { Connection } from '@solana/web3.js';\n\nconst suiClient = new SuiClient({ url: 'https://fullnode.mainnet.sui.io:443' });\nconst switchboardClient = new SwitchboardClient(suiClient);\nconst solanaConnection = new Connection('https://api.mainnet-beta.solana.com');\n\nconst surge = new sb.Surge({\n connection: solanaConnection,\n keypair: solanaKeypair, // Solana keypair with active Surge subscription\n signatureScheme: 'ed25519',\n});\n\nawait surge.connectAndSubscribe([{ symbol: 'BTC/USD' }]);\n\nsurge.on('signedPriceUpdate', async (response) => {\n const tx = new Transaction();\n await emitSurgeQuote(switchboardClient, tx, response.getRawResponse());\n\n // Sign and send transaction\n await suiClient.signAndExecuteTransaction({\n transaction: tx,\n signer: suiKeypair,\n });\n});Multiple Feedsawait surge.connectAndSubscribe([\n { symbol: 'BTC/USD' },\n { symbol: 'ETH/USD' },\n { symbol: 'SOL/USD' },\n]);Error Handlingsurge.on('error', (error) => {\n console.error('Surge error:', error);\n});\n\nsurge.on('close', () => {\n console.log('Connection closed, attempting reconnect...');\n // Implement reconnection logic\n});Performance ConsiderationsTransaction QueueThe example uses a queue because:Sui transactions are sequential per senderSurge updates arrive faster than transactions completeQueuing prevents transaction conflictsLatency OptimizationKeep your Sui node geographically closeUse dedicated RPC endpoints for productionConsider batching updates if latency isn't criticalOracle Mapping CacheThe oracle mapping is cached for 10 minutes to avoid repeated API calls. Adjust ORACLE_CACHE_TTL based on your needs.Troubleshooting\"Keypair not loaded\"Ensure you have a valid Sui keypair in ~/.sui/sui_config/sui.keystoreRun sui client new-address ed25519 to create oneEnsure you have a valid Solana keypair at ~/.config/solana/id.json or SOLANA_KEYPAIR_PATHRun solana-keygen new to create one\"Subscription not found\" or connection rejectedEnsure your Solana keypair has an active Surge subscriptionSubscribe at explorer.switchboardlabs.xyz/subscriptions\"Oracle ID not found for key\"The oracle mapping might be staleForce refresh by clearing oracleMapping and calling fetchOracleMappings()Check you're using the correct network (mainnet vs testnet)Transaction FailuresEnsure your wallet has sufficient SUI for gasCheck network connectivityVerify you're on the correct networkHigh LatencyCheck your network connectionConsider using a dedicated RPC endpointReduce logging if running in productionNext StepsQuote Verifier Pattern: See the Price Feeds tutorial for verified on-chain price storageMultiple Feeds: Subscribe to multiple feeds for portfolio trackingCustom Integration: Use the price data to trigger your own Move contract logicPreviousSurge Price FeedsNextAptosLast updated 2 months ago","tokens":3601,"squid":"spider-08","role":"Oracle Spider","at":1791342462881,"hash":"4cbf8d1480d762d3bacbcdb7dcda562dd1b9658d"}
{"url":"https://arbitrum.foundation/","domain":"arbitrum.foundation","title":"Arbitrum Foundation","text":"Welcome to the future of EthereumBuild on ArbitrumTell us about your project and get matched with funding, mentorship, and ecosystem resources.GET SUPPORTGovernanceGovernance starts here. Delegate your voting power, vote on proposals, and own a stake in Arbitrum's future.Join the DAOThe Arbitrum Foundation empowers the development and governance of Arbitrum technology and helps foster growth and success within the ecosystem.Excel with ArbitrumScalabilityTransactions are confirmed quickly and cheaply, making it ideal for applications with high transaction volume.SecurityAs a decentralized rollup, Arbitrum inherits the security of Ethereum.CompatibilityCompatible with all existing Ethereum tools and applications.Arbitrum is a suite of powerful Layer 2 scaling solutions, making blockchain technology more inclusive and sustainable for everyone, in a secure way.ConnectStay updated and be part of our vibrant community on Discord.BuildStart building your next blockchain application on Arbitrum today.JoinBe a part of the ArbitrumDAO and help shape the future.","tokens":267,"squid":"spider-07","role":"Council Spider","at":1791342463530,"hash":"bc5f8384d92b6162708611ba0876ecae0d00ee1e"}
{"url":"https://developer.arbitrum.io/run-a-node/data-availability","domain":"developer.arbitrum.io","title":"Data Availability","text":"Data AvailabilityLearn how data availability works in arbitrumRequest an updateHow Arbitrum data availability works\nWhat is the general view of Arbitrum data flow?\n currently supports two primary data availability mechanisms:\nRollup mode\nIn this mode, all transaction data is included in either the calldata or of transactions submitted to the (e.g., Ethereum mainnet for ). This inclusion ensures that all data is readily available onchain for anyone to download and verify.\nAnyTrust mode\nIn mode, transaction data initially gets submitted to a group of nodes known as the . 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 (, 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, 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 process.\nHere's how Arbitrum data flow works:\n\nBatching and submission:\n\nThe queues transactions and batches them together.\nThese batches get submitted to the parent chain:\n\nIn Rollup mode, the sequencer submits the of transactions directly to the 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 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 (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 (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 is this guide?L1 Ethereum RPC providersA reference list of Ethereum beacon chain RPC providers that Arbitrum node operators can use to access blob data after the Dencun upgrade.Run a feed relayLearn how to run an Arbitrum feed relay, and how to architect relays and nodes for reliable feed consumption at fleet scale.","tokens":1768,"squid":"spider-01","role":"Chain Spider","at":1791342470122,"hash":"3621a2552065f6b006a03565c4dab92838660ed6"}
{"url":"https://docs.switchboard.xyz/docs-by-chain/sui/price-feeds","domain":"docs.switchboard.xyz","title":"Price Feeds | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.Access to reliable, real-world data is essential for decentralised applications (dApps), particularly in Decentralised Finance (DeFi). Real-time asset prices, forming the backbone of any DeFi protocol, are among the most critical data points.This is where Data Feeds come in. Think of them as secure bridges connecting the off-chain world of financial markets to your on-chain smart contracts. They provide a continuous stream of verified, aggregated price data for a wide range of assets, enabling your dApp to react to market fluctuations and operate correctly.PreviousSuiNextPrice Feeds TutorialLast updated 9 months ago","tokens":179,"squid":"spider-08","role":"Oracle Spider","at":1791342473336,"hash":"d5a36482233bbec9fd1b2390d1f165d56edde896"}
{"url":"https://arbitrum.foundation/grants","domain":"arbitrum.foundation","title":"Arbitrum — Grants","text":"Arbitrum GrantsAn ecosystem of grant programs for a better ArbitrumActiveArbitrum Audit ProgramThe Arbitrum Audit Program offers $10M in ARB over 12 months to subsidise third-party smart contract audits. It is one of crypto’s largest audit initiatives supporting early-stage Arbitrum projects with strong product-market fit and high growth potential.Managed by The Arbitrum Foundation ActiveArbitrum Audit ProgramActiveArbiFuelArbiFuel is a Gas Fee Sponsorship Program to help early-stage teams ship faster, test freely, and onboard users without worrying about gas costs.Managed by The Arbitrum Foundation ActiveArbiFuelActiveArbitrum Gaming VenturesThe Arbitrum Gaming Ventures (AGV) is an ArbitrumDAO initiative designed to empower builders of gaming projects and infrastructure within the Arbitrum ecosystem. Connect with the AGV team to explore grants, funding opportunities, tools, and collaboration possibilities.Managed by The ArbitrumDAO ActiveArbitrum Gaming VenturesActiveAlchemy-Arbitrum Grant ProgramAlchemy has launched a $10M grant program to support Orbit chain development. The program offers up to $500K in Alchemy infrastructure credits for teams building or migrating to Orbit-based rollups.Managed by Alchemy ActiveAlchemy-Arbitrum Grant ProgramInactiveTrailblazer 2.0Trailblazer 2.0 is a $1M funding program focused on supporting impactful DeFi agents, agent templates, or any of the contributions built with Vibekit, a new Arbitrum-native MCP agent framework developed by Ember.Managed by The Arbitrum Foundation InactiveTrailblazer 2.0InactiveArbitrum DAO Grant ProgramThe Arbitrum DAO Grant Program supports builders with milestones-based funding for growth. All grants issued through this program will serve to improve the adoption of Arbitrum chains, create stronger technical structures, and build sustainable communities in the Arbitrum ecosystem.Managed by The Arbitrum DAO InactiveArbitrum DAO Grant ProgramInactiveTrailblazer AI Grant ProgramThe Trailblazer AI Grant Program is a $1,000,000 initiative designed to provide immediate grant support to innovative builders creating specialized AI agents and other onchain AI products on Arbitrum chains.Managed by The Arbitrum Foundation InactiveTrailblazer AI Grant ProgramInactiveStylus SprintThe Stylus Sprint program is designed to support builders working with Arbitrum Stylus. The Sprint will offer 5M ARB worth of grants, along with resources and collaboration opportunities, for teams that want to push the boundaries of what’s possible on the blockchain using Stylus.Managed by Questbook InactiveStylus SprintUnlock new opportunities on Arbitrum The Stylus Sprint offers 5M in ARB grants to developers creating innovative blockchain solutions using Arbitrum Stylus. This sprint supports teams working with Stylus’s Web Assembly (WASM) VM, which will enable coding in any WASM-compatible language (e.g., Rust). Projects will be reviewed by an evaluation committee that will look for scalable solutions with long-term potential and meaningful ecosystem impact. Applications open now open on Questbook.InactiveArbitrum Foundation Grant ProgramThe Arbitrum Foundation Grant Program supports builders with milestones-based funding for growth. All grants issued through this program will serve to improve the adoption of Arbitrum chains, create stronger technical structures, and build sustainable communities in the Arbitrum ecosystem.Managed by The Arbitrum Foundation InactiveArbitrum Foundation Grant Program Designed to support DAO initiatives, the Arbitrum Foundation Grant Program offers financial support for builders on Arbitrum. Through this program, you can receive milestone-based funding for projects focused on key Arbitrum Foundation initiatives.Applications will open soon To maximize the impact of our grant program, we will be tracking milestone progress for all approved applicants.Who are we looking for Our new grant program is coming soon. You can also submit a proposal to the ArbitrumDAO.InactiveUniswap-Arbitrum Grant ProgramThe Uniswap-Arbitrum Grant Program (UAGP) is a 6-month initiative providing grants from $50,000 to $250,000 in ARB tokens to developers building within the Uniswap-Arbitrum ecosystem. With over 1m $ARB tokens in the program, the goal is to accelerate adoption and highlight the expansive opportunities that emerge in overlapping areas of the two ecosystems.Managed by Uniswap DAO Working Group Zero InactiveUniswap-Arbitrum Grant Program Designed to support DAO initiatives, the Arbitrum Foundation Grant Program offers financial support for builders on Arbitrum. Through this program, you can receive milestone-based funding for projects focused on key Arbitrum Foundation initiatives.Applications are now open Applications are being approved on a rolling basis. To maximize the impact of our grant program, we will be tracking milestone progress for all approved applicants.Who are we looking for Currently accepting applications for: Decentralized Applications (“dApps”)Infrastructure & Tools Not you? We’ll be considering different types of projects as time goes on, so please check back later. You can also submit a proposal to the ArbitrumDAO.InactivePluralistic Grant ProgramCommunity-created grant program facilitated by Plurarity Labs to distribute 2,600,000 ARB, along with thankarb.com to facilitate participation from the ecosystem.Managed by Plurality Labs InactivePluralistic Grant Program Designed to support DAO initiatives, the Arbitrum Foundation Grant Program offers financial support for builders on Arbitrum. Through this program, you can receive milestone-based funding for projects focused on key Arbitrum Foundation initiatives.Applications are now open Applications are being approved on a rolling basis. To maximize the impact of our grant program, we will be tracking milestone progress for all approved applicants.Who are we looking for Currently accepting applications for: Decentralized Applications (“dApps”)Infrastructure & Tools Not you? We’ll be considering different types of projects as time goes on, so please check back later. You can also submit a proposal to the ArbitrumDAO.InactiveQuestbookThe Questbook Arbitrum Grants program is useful for anyone developing in domain specific projects on top of Arbitrum, ranging from education, gaming, dev tooling to innovative ideas. Through the program, you can receive milestone-based funding based on domain specific needs, outlined by the domain allocators elected by the community.Managed by Questbook InactiveQuestbook Designed to support DAO initiatives, the Arbitrum Foundation Grant Program offers financial support for builders on Arbitrum. Through this program, you can receive milestone-based funding for projects focused on key Arbitrum Foundation initiatives.Applications are now open Applications are being approved on a rolling basis. To maximize the impact of our grant program, we will be tracking milestone progress for all approved applicants.Who are we looking for Currently accepting applications for: Decentralized Applications (“dApps”) Infrastructure & Tools Not you? We’ll be considering different types of projects as time goes on, so please check back later. You can also submit a proposal to the ArbitrumDAO.InactiveShort Term Incentive ProgramCommunity-created consensus framework to distribute up to 50,000,000 ARB of DAO-funded incentives targeting active Arbitrum protocols.Managed by Arbitrum DAO InactiveShort Term Incentive Program Designed to support DAO initiatives, the Arbitrum Foundation Grant Program offers financial support for builders on Arbitrum. Through this program, you can receive milestone-based funding for projects focused on key Arbitrum Foundation initiatives.Applications are now open Applications are being approved on a rolling basis. To maximize the impact of our grant program, we will be tracking milestone progress for all approved applicants.Who are we looking for Currently accepting applications for: Decentralized Applications (“dApps”)Infrastructure & Tools Not you? We’ll be considering different types of projects as time goes on, so please check back later. You can also submit a proposal to the ArbitrumDAO.","tokens":2048,"squid":"spider-07","role":"Council Spider","at":1791342474827,"hash":"67523922530b0670c9f44d1b9d3d116daba7d6e0"}
{"url":"https://developer.arbitrum.io/run-a-node/start-here","domain":"developer.arbitrum.io","title":"Prepare to run a node","text":"Prepare to run a nodeLearn the prerequisites for running an Arbitrum node on your local machineRequest an updateNoteIf 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 full node (not archival):\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 (the default) or . The choice affects which snapshot you can use, so make it before you initialize the database. Both have published full node snapshots; PathDB 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\nWarningAlthough 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 availability 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 . 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.\n1. 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 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 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 , you need to specify information about the 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\n--node.da.anytrust.rest-aggregator.enable\nThen, choose one of these methods to specify the 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.How is this guide?Nitro support policyLearn the details of the support policy for Nitro.Run a full nodeLearn how to run an Arbitrum node on your local machine","tokens":3372,"squid":"spider-01","role":"Chain Spider","at":1791342480110,"hash":"d353fe8dec343b4771c9371b08c87a8495e20db5"}
{"url":"https://docs.switchboard.xyz/how-it-works/switchboard-protocol/providing-stake-to-switchboard","domain":"docs.switchboard.xyz","title":"Providing stake to Switchboard | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.Providing stake to Switchboard is simple and rewarding! By staking supported assets, you help secure the oracle network while earning SWTCH governance tokens.OverviewSwitchboard uses Jito's Node Consensus Network (NCN) for its restaking infrastructure. This allows you to stake various LSTs (Liquid Staking Tokens) to secure the Switchboard oracle network and earn SWTCH rewards in return.Key Benefits:🏆 Earn SWTCH: Receive governance tokens for network participation🔒 Network Security: Help secure over $5B in DeFi value🌐 Multi-Asset Support: Stake SOL or various LSTs⚡ Regular Rewards: Distributed every Solana epoch (3 days)To start securing the Switchboard network, you may contribute to the Fragmetric vault for stake to be distributed to oracle operators.To start staking visit the Fragmetric vault page on the Jito Vault website:https://www.jito.network/restaking/vaults/HR1ANmDHjaEhknvsTaK48M5xZtbBiwNdXM5NTiWhAb4SFrom there you can see the:Vault AddressVRT MintVault AuthorityVault website: https://app.fragmetric.xyz/restake/fragsolNavigate to the Fragmetric application and stake SOL or any of the fragSOL supported LSTs to start delegating to Switchboard oracles and start earning SWTCHSee example at https://screen.studio/share/MzI1bXNLWhat can I stake?With Jito (re)-staking built in, you can stake any assets your vault supports.For the Fragmetric Vault, these assets are currently:SOLJitoSOLBNSOLmSOLHow do I earn $SWTCH?SWTCH is rewarded directly to the vault to be claimable by stakers.These awards will be distributed every Solana epoch (3 days) and will be viewable on the Fragmetric vault rewards page: https://app.fragmetric.xyz/rewards/overview/How Much SWTCH Do I Earn?The amount to distribute is governed by the Switchboard DAO through svSWTCH governance, with the initial year set to distribute 8% of supply to stakers.Reward Calculation:Based on your proportional share of total staked assetsDistributed from protocol fees and SWTCH subsidiesHigher oracle performance = higher rewards for delegatorsFor complete details on tokenomics and reward distribution, see the SWTCH Token Overview and Governance & Tokenomics guides.How can I unstake?The unstaking process is controlled by each vault added to the Switchboard NCN.For the Fragmetric vault, visit https://app.fragmetric.xyz/unstake to initiate the unstake. The unstaking process, like the Solana unstaking process, will take until next epoch to take effect.PreviousEnable Staking to your OracleNextTechnical ArchitectureLast updated 1 year ago","tokens":655,"squid":"spider-08","role":"Oracle Spider","at":1791342482908,"hash":"0b7f5188535c5c78287e057cd94a07568dbd6731"}
{"url":"https://blog.arbitrum.foundation/arbifuel-is-live-arbitrum-builders-claim-your-gas-fee-sponsorship/","domain":"blog.arbitrum.foundation","title":"ArbiFuel Is Live: Arbitrum Builders, Claim Your Gas Fee Sponsorship","text":"At Arbitrum, builders come first. That’s why we’re launching ArbiFuel, a Gas Fee Sponsorship Program to help early-stage teams ship faster, test freely, and onboard users without worrying about gas costs. As the ecosystem evolves with upgrades like Pectra and EIP-7702, the push toward native smart account support is accelerating, and Arbitrum is ready to help teams take advantage of these new capabilities and bring fresh ideas to life.Ready to Gas Up? ArbiFuel Program BreakdownWhether you’re exploring smart wallets, onboarding UX, or payment-related applications, Arbitrum will back you with the scalability, tooling, and now, the gas to build user-friendly applications. The Arbitrum Foundation welcomes the following to apply for gas sponsorship under ArbiFuel:Early-stage developers working on simplified UX appsWallet providers and stablecoin-related productsTeams exploring payment-related applicationsThe program will power your users with a seamless, cost-free entry into your application.Selected projects will get sponsorship of up to 1,000,000 free transactions in their first year following the start of the gas sponsorship, capped at $10,000 in credits per team.Initially, the sponsorship is powered by Pimlico’s ERC-20 Paymasters, with plans to expand to other Paymasters based on project needs.👉Apply now: ArbiFuel Gas Sponsorship Application LinkExplore Other Ecosystem OpportunitiesDidn’t qualify for ArbiFuel, or looking for additional builder-focused initiatives? No worries, the Arbitrum ecosystem is rich with programs designed to support innovation across domains. Here are some standout opportunities currently active:AI Trailblazer: A $1M initiative from the Arbitrum Foundation that provides grants to builders developing specialized AI agents and other onchain AI products on Arbitrum chains.Arbitrum Grants by Questbook: Delegated Domain Allocation 3.0 is a year-long, $6.75M grant program approved by ArbitrumDAO and run by Questbook, spanning five domains — New Protocols and Ideas, Dev Tooling, Gaming, Education + Events, and the new experimental Orbit domain.Alchemy’s Arbitrum Grant Fund: Alchemy has committed $10M to support Arbitrum builders launching Orbit chains, offering up to $500K per project.Arbitrum Gaming Ventures (AGV): Backed by 225M ARB from the ArbitrumDAO, AGV is a venture initiative aimed at funding and partnering with game studios and publishers building on the Arbitrum tech stack.Onchain Labs: A joint initiative by Offchain Labs and the Arbitrum Foundation to accelerate onchain experiences. Early-stage teams expanding the Arbitrum application layer can receive product, IT, and GTM support directly from Offchain Labs.Arbitrum Audit Program: A 1-year, 30M ARB initiative approved by the DAO to subsidize security audits for Arbitrum projects. The Audit Committee is currently being formed, with applications opening soon.Educate to Strengthen Your ApplicationAs part of the ArbiFuel program, we encourage teams to actively educate their communities about their presence on Arbitrum and the opportunity to benefit from gasless transactions on Arbitrum protocols. Community education and awareness can strengthen your chances of receiving gas sponsorship.In your application, please share:Links to your X (formerly Twitter) posts about your presence on ArbitrumAny updates to your social bio referencing ArbitrumA demo of an in-app sticky bannerAny other creative marketing tactics you’ll use to raise awarenessLet’s build the future of Web3 without the gas friction.","tokens":883,"squid":"spider-07","role":"Council Spider","at":1791342487202,"hash":"b4a3dce381beb5bb6dbc0cc3a9ee5a70d65e9c67"}
{"url":"https://developer.arbitrum.io/arbitrum-essentials/reference/node-providers","domain":"developer.arbitrum.io","title":"RPC endpoints and providers","text":"ReferenceRPC endpoints and providersList of RPC endpoints and third-party node providers for Arbitrum One, Arbitrum Nova, and Arbitrum testnets. Find public and premium endpoints for connecting your dApp to Arbitrum networks.Request an updateArbitrum public RPC endpoints\nWarning\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.How is this guide?Monitoring tools and block explorersList of monitoring tools and block explorers for Arbitrum, including Arbiscan, Dune Analytics, and other platforms for tracking transactions, contracts, and network activity on Arbitrum chains.Solidity referencesDiscover references and resources to learn and progress as a Solidity developer.","tokens":1398,"squid":"spider-01","role":"Chain Spider","at":1791342490051,"hash":"2eb37f4e3213223780b4c97f9859379cb347e4e2"}
{"url":"https://docs.switchboard.xyz/how-it-works/switchboard-protocol/re-staking/what-is-re-staking","domain":"docs.switchboard.xyz","title":"What is (re)staking? | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.Blockchains have evolved to solve problems with scaling, security, and speed. Restaking is the newest step in this evolution. Instead of building completely new security systems for each blockchain or application, restaking lets developers “borrow” security from existing, established networks. This allows them to focus on building great applications instead of spending all their time and resources on securing the underlying network.Imagine it like this: staking is like putting down a deposit to guarantee good behaviour on a blockchain. Restaking, then, is like reusing that same deposit to secure multiple things at once.Why is this important?Faster Innovation: Developers can launch new applications more quickly and easily.Stronger Security: New projects instantly benefit from the security of well-established networks.More Efficient Use of Assets: Users can earn more rewards by staking their tokens and contributing to the security of multiple projects.Before restaking, new blockchains or applications had to create their own security from scratch. Restaking lets them leverage the “economic security” of existing networks, offering stronger protection from the start. At its core, restaking simply applies the principles of traditional staking to more applications and services.The biggest restaking project currently is outside of Solana, called EigenLayer. However, the Jito (Re)staking platform is pioneering this concept on Solana, allowing users to secure new on-chain products and services using almost any SPL token.Previous(Re)stakingNextWhat are Node Consensus Networks (NCNs)?Last updated 1 year ago","tokens":429,"squid":"spider-08","role":"Oracle Spider","at":1791342493156,"hash":"bbd2c95552bd753d1f63162e5fe5bd258becb5c6"}
{"url":"https://developer.arbitrum.io/arbitrum-essentials/reference/chain-params","domain":"developer.arbitrum.io","title":"Chain parameters","text":"ReferenceChain parametersReference of key system parameters for Arbitrum One and Arbitrum Nova, including chain IDs, block times, gas settings, and confirmation thresholds for public Arbitrum chains.Request an updateChain 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.How is this guide?ReferenceChain parameters, contract addresses, RPC providers, and developer tooling.Contract addressesComplete list of deployed Arbitrum smart contract addresses across Arbitrum One, Arbitrum Nova, and testnets. Includes core protocol contracts, token bridge contracts, and governance contracts.","tokens":458,"squid":"spider-01","role":"Chain Spider","at":1791342501445,"hash":"a3c7ad9bb53dc61a4a48e715e58a7d444123a017"}
{"url":"https://docs.switchboard.xyz/how-it-works/switchboard-protocol/re-staking/what-are-node-consensus-networks-ncns","domain":"docs.switchboard.xyz","title":"What are Node Consensus Networks (NCNs)? | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.Node Consensus Networks (NCNs) represent a foundational architecture within blockchain technology, utilising distributed processes to specifically validate and confirm information. These networks operate through collections of independent nodes collaborating to scrutinise actions, transactions, and various data types. Essentially, any system aiming to establish a decentralised network bolstered by community validation can be classified as an NCN – This even includes the Switchboard Protocol, which is intrinsically an oracle network that seamlessly connects decentralised applications to real-world data.A significant catalyst for the rise of NCNs is their ability to address the “cold start problem,” a common hurdle for new decentralised projects. This problem encompasses the difficulties in bootstrapping network security and validation mechanisms from scratch. Traditionally, new networks have had to develop bespoke validation solutions which require substantial resources, time, and robust economic backing to establish a dependable validator network.Think of NCNs as modular 'building blocks' constructed for trust. NCNs can perform specific roles to confirm the accuracy of price feeds from oracles or even securing cross-chain communications. By specialising and focusing, this ensures higher levels of reliability for any protocol that uses a NCN.Jito NCN’s and the Switchboard ProtocolSecurity is critical for oracle networks due to the high value of the applications that depend on their data. Switchboard is enhancing its security by integrating with Jito (Re)staking, a system built for Solana's Node Consensus Networks (NCNs). Jito allows NCNs to define their own staking rules and penalties for poor performance, creating a more robust and adaptable security model. It also tokenises staked assets into Vault Receipt Tokens (VRTs), making them more flexible and usable.Switchboard is using Jito's system to launch its own NCN, which will increase the security and reliability of its data feeds. Jito provides a marketplace where node operators (those who manage the NCNs) and the NCNs themselves can connect and collaborate to build a stronger, more interconnected security network. Node operators announce their services on-chain, and Switchboard can then choose to use them.With Jito, Switchboard can customise its network security – for example, setting specific staking requirements and penalties for misbehaviour. This, along with ongoing monitoring of on-chain and off-chain data, allows Switchboard to precisely manage its security. By combining its data feeds with Jito's restaking capabilities, Switchboard is working to become a leading example of secure and effective restaking on Solana.PreviousWhat is (re)staking?NextWhat are Vault Receipt Tokens (VRTs)?Last updated 1 year ago","tokens":726,"squid":"spider-08","role":"Oracle Spider","at":1791342507324,"hash":"b744b4b32b2181be8e2aab7c331a5f8db86c474f"}
{"url":"https://developer.arbitrum.io/arbitrum-essentials","domain":"developer.arbitrum.io","title":"Arbitrum essentials","text":"Arbitrum essentialsCore, language-agnostic guidance for building on Arbitrum — bridging, precompiles, the NodeInterface, and how Arbitrum differs from Ethereum.Request an updateCore, language-agnostic guidance for building on Arbitrum: bridging, oracles, precompiles, the NodeInterface, RPC and provider references, networks, gas, and how Arbitrum differs from Ethereum. This guidance applies whether you write contracts in Solidity or Stylus.\nBridgingMove ETH, tokens, and messages between parent and child chains.Arbitrum vs EthereumWhere Arbitrum's behavior differs from Ethereum's.PrecompilesArbitrum-specific precompiled contracts and their interfaces.NodeInterfaceQuery gas estimates and chain data through the NodeInterface.ReferenceChain parameters, contract addresses, providers, and tooling.How is this guide?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.","tokens":259,"squid":"spider-01","role":"Chain Spider","at":1791342512752,"hash":"3e7b9b78f3d2bfd4de8122d7dc363ae124de85a3"}
{"url":"https://docs.switchboard.xyz/how-it-works/switchboard-protocol/re-staking/the-node-partner-program","domain":"docs.switchboard.xyz","title":"The Node Partner Program | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.Switchboard's Node Consensus Network (NCN) benefits from Jito's robust NCN infrastructure, ensuring strong consensus through numerous independent operators and guaranteeing protocol integrity. Further enhancing security, Switchboard relies on a decentralised network of oracles for vital feed data. Node operators are therefore incentivised to maintain the continuous availability, accuracy, and reliability of this data, strengthening overall network performance.The Switchboard Node Partner Program directly rewards this crucial contribution, empowering skilled operators to actively enhance the security and reliability of our decentralised oracle network. Program members gain access to exclusive benefits that promote growth and foster contributions to the Switchboard ecosystem:Enhanced Revenue Streams: Earn Jito NCN staking rewards, Switchboard protocol transaction fees, and additional incentives specifically designed for maintaining optimal uptime and data accuracy within the Switchboard network.Dedicated Technical Support: Receive direct, prioritised support from the core Switchboard contributors, including access to detailed best practice guides and rapid troubleshooting assistance.Active Governance Role: Directly shape the future of the Switchboard protocol by actively participating in network proposals, protocol improvement discussions, and community governance initiatives.Exclusive Ecosystem Opportunities: Unlock collaborative partnerships with leading DeFi protocols, innovative enterprises, and cutting-edge blockchain projects that are actively utilising Switchboard oracle services. You will also be promoted on the Switchboard website and documentation.How to join the Node Partner ProgramIf you meet the Program Requirements, we encourage you to submit an application, providing details about your operational experience.Applications are reviewed on a rolling basis. Successful applicants will be invited to onboarding sessions.PreviousWhat are Vault Receipt Tokens (VRTs)?NextThe Switchboard NCNLast updated 1 year ago","tokens":536,"squid":"spider-08","role":"Oracle Spider","at":1791342522244,"hash":"a6eb6ec81d66134f8206bd16eb7a5d5f63549bff"}
{"url":"https://alt.gov.arbitrum.foundation/delegates/0xb4c064f466931b8d0f637654c916e3f203c46f13","domain":"alt.gov.arbitrum.foundation","title":"Delegate Profile | Arbitrum Governance | Arbitrum Governance","text":"Back to DelegatesDelegate ProfileArbitrum DAO delegateEntropy AdvisorsWorking exclusively with ArbitrumDAO to incrementally make governance better. At Entropy, we believe that effective coordination within DAOs is a prerequisite to crypto delivering on its promise of a globally accessible internet of value. As the leading scaling tech stack, Arbitrum is best primed to deliver on this vision. Our team is comprised of crypto natives, with previous experience at Blockworks Research and 404 DAO. Seeking Delegation0xb4c064f466931b8d0f637654c916e3f203c46f13@EntropyAdvisorsVoting Power32.27M ARBDelegators148Delegate ARBConnect a wallet to delegate ARB voting power.Delegation updates voting power only. Your ARB stays in your wallet.Delegate StatementOverall Goals for ArbitrumDAO\nAt Entropy Advisors, our primary objective for the ArbitrumDAO is to ensure that the Arbitrum tech stack becomes the most widely adopted infrastructure in the entire blockchain ecosystem. We envision a world where investors, users, and developers focus on contributing to the Arbitrum ecosystem without even making the conscious decision to do so, primarily because the network effects have grown so exponentially that “Why Arbitrum?” is no longer a question being asked. We believe the Arbitrum tech speaks for itself in practice, and that with proper stewardship and contributions to the ArbitrumDAO, the aforementioned question will turn into “Why not Arbitrum?”. \nWe are interested in contributing to all areas of the Arbitrum ecosystem as needs arise, but will be focusing on improving governance participation as well as tooling and protocol decentralization. The ArbitrumDAO is Entropy Advisors’ only customer, which is not something many other Arbitrum delegates can tout today. Our employees have extensive experience in research and have been active across numerous DAOs in the past, but have identified Arbitrum as the most promising technology stack and want to put all of our time, effort, and collective brainpower into ensuring the sustainable growth of the ecosystem – powered by the ArbitrumDAO.  \nPut simply, we believe in a diverse and highly capable delegate base, a DAO that is sustainable through diversified and robust revenue streams, responsible and carefully calculated spending that encourages the growth of the ecosystem, a highly intellectual group of service providers that can effectively execute on tasks on behalf of the DAO, and measures for accountability/processes that can stand the test of time.\nSample Voting Issue 1: Uniswap X Flipside Partnership\nOur Take: Against\nIn our view, this proposal gives too much power to Flipside as the primary allocator of the UNI being spent by the DAO, and also unfairly entrenches a data provider into the Uniswap ecosystem. To the former point, we do not believe it makes sense to give Flipside such a significant amount of power over which projects and metrics should be analyzed. These are ultimately meant to be community tools, so why would the broader community not have some representation/voice in what activities are incentivized? To the latter point, $25M is a lot of money. We believe that Uniswap would make a better impact with a program of this size by running an open bounty program available to all data providers, with no conflicts of interest on the council allocating funds. Companies like Dune, Artemis, Nansen, etc. would likely be interested in building out some of the things being proposed, and we believe that more competition often leads to better results. The conflict of interest that Flipside presents makes this proposal difficult to support. We would recommend Flipside removing themselves from the decision making process, thus creating a level playing field for all data providers. \nSample Voting Issue 2: FEI RARI Hack Reimbursement\nOur take: Full Reimbursement \nWe believe that in most cases, one of the DAO’s primary responsibilities is to ensure the safety of its members. This was an unfortunate situation where millions of dollars of innocent users' funds were stolen due to an exploit, and the DAO had enough assets to fully reimburse the users who were affected. It could also be worth looking at other opportunities available to the DAO and whether the reimbursements should be made today versus in the future. While every hack has its own nuances and needs to be evaluated in isolation with all of the relevant facts, we believe that in this scenario all users should be reimbursed with idle funds that were supposed to belong to the DAO in the first place. \nLanguages we speak & write \nEnglish, Finnish, Swedish\nDisclosure of Conflict(s) of Interest\nWe work with Arbitrum, meaning that conflict of interest situations could potentially arise in the future. In any such cases, we pledge to abstain from voting and clearly divulge any COIs in the forum.","tokens":1213,"squid":"spider-07","role":"Council Spider","at":1791342524971,"hash":"5af2ed66e3622ab27aae0be9ec0fa11efcee0c4e"}
{"url":"https://developer.arbitrum.io/arbitrum-essentials/reference","domain":"developer.arbitrum.io","title":"Reference","text":"ReferenceChain parameters, contract addresses, RPC providers, and developer tooling.Request an updateReference material for building on Arbitrum: chain parameters, contract addresses, RPC endpoints and providers, monitoring tools, block explorers, and web3 libraries.\nChain parametersChain IDs, block times, and gas settings for One and Nova.Contract addressesDeployed protocol, token bridge, and governance contracts.RPC endpointsPublic and premium endpoints, and third-party node providers.Development frameworksHardhat, Foundry, and other build and test tooling.Web3 librariesethers.js, viem, web3.js, and other client libraries.Explorers and monitoringArbiscan, Dune, and other tools for tracking activity.Debugging toolsTenderly and other platforms for simulation and tracing.Understanding the risksTrust assumptions and upgrade mechanisms on mainnet.How is this guide?ReferenceComplete API reference for Arbitrum's NodeInterface contract methods, including gas estimation, retryable ticket helpers, and outbox proof construction. Available at address 0xc8 via RPC calls only.Chain parametersReference of key system parameters for Arbitrum One and Arbitrum Nova, including chain IDs, block times, gas settings, and confirmation thresholds for public Arbitrum chains.","tokens":318,"squid":"spider-01","role":"Chain Spider","at":1791342525082,"hash":"223ee09f4c7dfb98263a24fb6a2c42dcfa93c72f"}
{"url":"https://akash.network/blog/the-akashian-challenge-phase-3-week-1-is-live","domain":"akash.network","title":"The Akashian Challenge Phase 3: Week 1 is LIVE!","text":"Akashian Challengers have landed, and The Akashian Challenge Phase 3 Week 1 is officially LIVE!!!\nPhase 3 is the last phase of our three phase incentivized testnet, and will take place over the next two weeks.\nWith 500,000 Akash Token (AKT) rewards at stake, you’ll get the chance to explore the world’s first decentralized cloud and help us build a strong Mainnet 2.\nStart the Week 1 challenges by clicking Get Started Now, or click on Learn More to visit The Akashian Challenge site for information on Week 1 challenges and rewards.\nLet the games begin!\nGet Started Now | [Learn More\n](https://akash.network/challenge/)\nHow to Join\n_____\nTo start, please sign up here if you have not participated in Akash’s previous testnets.\n\nKYC/AML: Complete KYC/AML. This is required to claim rewards, but not for participation. Please reach out on our Discord dev chat if you have any problems with the KYC process.\nTax Documents: W-8 BEN or W9. Once your KYC application is approved, our team will send either a W-8 BEN for international participants or a W9 via HelloSign.\n\nKey Dates\n_____\nThe Phase 3 network and challenges will be live for two weeks:\n\nWeek 1: November 30, 2020 - December 4, 2020\nWeek 2: December 7, 2020 - December 11, 2020\n\nRewards Scoring:\n\nDecember 14, 2020: Rewards earned from the first week will be posted\nDecember 21, 2020: Complete results of rewards will be posted.\nScoring Note: where submissions satisfy more than one reward, all rewards will be granted for that submission.\n\nGoals & Overview\n_____\nIntegrating performance enhancements from Cosmos SDK v0.40, The Akashian Challenge Testnet 3 will test and showcase Akash DeCloud’s deployment platform. Akashian Challengers will be incentivized to deploy applications using the Akash Network.\nEncompassing two weeks, Phase 3 will include guided challenges for deploying applications of increasing complexity — from simple single-page applications to blockchain network components, and open ended challenges where users can show off their Akash OPS skills by extending the guided examples to deploy any application they desire — from DeFi to CI.\nThere are additional rewards for participation outside of the deployment challenges, including contributions such as active validator participation, writing blog posts and how-to guides, and sharing novel uses of our platform.\nPhase 3 Goals:\n\nTest platform functionality for Mainnet 2\nDistribute tokens to potential users for Mainnet 2\nBuild a catalog of applications (SDLs) to launch Mainnet 2\n\nPhase 3 Challenges:\n\nGuided Challenges\n\nThese challenges are meant to be used as step-by-step guides to deploying applications on our network.\nEach challenge will have accompanying instructions and example deployment configurations.\n\nOpen Ended Challenges\n\nAs a generic cloud platform, Akash DeCloud has the potential to be used in a wide variety of use cases. This open-ended challenge is meant to explore what kinds of applications can be deployed on DeCloud, and how.\nYou’ll support the Akash DeCloud community by finding unique applications to deploy and sharing your deployment configuration via a pull request on Awesome Akash.\n\nNetwork Support Challenges\n\nWhile validators and other network components are not necessarily targeted in this testnet, they are of course essential to maintaining a healthy DeCloud.\nLeverage this testnet to practice your operations, or try new ones.\nTo earn rewards for this challenge, you should be actively participating — keep your component(s) up-to-date and respond to any network proposals that may come up.\n\nCommunity Content Challenges\n\nDrop your knowledge about Akash DeCloud to earn rewards. The community content challenges support community members who independently publish articles and guides related to the Akash Network.\n\nAnything Goes: An open-ended category where “Anything Goes!” with community-generated content related to Akash.\nDeCloud for DeFi: A category calling on our community to leverage Akash DeCloud as the infrastructure supporting DeFi applications.\n\nPhase 3 will accelerate our vision for a decentralized and open cloud computing marketplace and serve as the launchpad for Mainnet 2.\nRewards\n_____\nYou can check out The Akashian Challenge site for a detailed schedule of reward opportunities. A total of 500,000 AKT is allocated for Phase 3 Rewards including:\n\nGuided Challenges\nOpen Ended Challenges\nNetwork Support Challenges\nCommunity Content Challenges\nBonus Challenges\n\nDon’t Miss the Latest Phase 3 Updates\n_____\nJoin our Telegram to get the latest Akash Network and AKT news, giveaways, and special invitations to events and AMAs!\nJoin our Discord dev chat for Phase 3 and DeCloud technical support and information.\n\nReady to Get Started?\nGet Started Now | Learn More\n—\nOriginal Artwork by: Paul Muller \nFast, affordable inference for open models\n\nRun Llama, Qwen, GLM and more on Akash's open compute marketplace.\nDrop-in API compatibility means you can\n switch in minutes.\n\nTry AkashML\n(opens in a new tab) \nnote\n\ntip\n\nCaution\n\nDanger","tokens":1257,"squid":"spider-03","role":"Compute Spider","at":1791342716976,"hash":"c2c405a2d621ee49f15f6902e93b20e7643f7299"}
{"url":"https://forum.across.to/t/reduce-or-reallocate-across-acx-lp-emissions/1703/1","domain":"forum.across.to","title":"Reduce or Reallocate Across ACX LP emissions - Ideas & Feedback - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n Reduce or Reallocate Across ACX LP emissions \n\n Ideas & Feedback\n\n liquidity\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Aug 2023\n\n 1 / 3\n\n Aug 2023\n\n Sep 2023\n\n post by Kevin_UMA on Aug 22, 2023\n\n Kevin_UMA\n\n Across ACX LPs staked in reward locking currently earn 7.84% to 26.7% driven by base emissions of 20,000 ACX per day.\nThis is a significant amount given there is currently very little ACX being bridged. The emissions were initially set high to get ACX airdrop recipients to not immediately sell their tokens and to get them familiar with the reward locking mechanism. Given it’s been 9 months since the launch of the token the community should consider reducing these emissions.\nIn addition, incentives will be added to enhance liquidity on the ACX token. The community voted to end bribes on Aura and instead incentivize the Balancer pool with Reward Locking and also bribe on Velodrome. The generally idle ACX in the Across LP would be better served supporting these pools instead. In total the DAO would be spending 38k to 52k ACX per day on ACX related pools.\n20k ACX / day - Across LP\n7k -21k / day - wstETH/ACX Balancer pool (1 to 3x multiplier)\n11k/day - Velodrome pool (75k per week)\nTotal = 38k to 52k ACX / day\nThis is in comparison to the current base emissions for other assets on Across:\n~50,000 ACX per day for Across ETH LP tokens\n~50,000 ACX per day for Across USDC LP tokens\n~5,000 ACX per day for Across DAI LP tokens\n~5,000 ACX per day for Across WBTC LP tokens\nDiscussion: How much should these emissions be reduced? Should we reallocate the emissions to other pools? Some options to consider:\n\nCut emissions by 50% and don’t reallocate\nMove emissions to lower volume assets like DAI or WBTC\nMove emissions to higher volume assets like ETH or USDC\nMove some portion to temporarily create interest for smaller tokens like POOL and SNX\nAdd more incentives to ACX liquidity\n\nWhat do people think?\n\n Reduce ACX emissions for Across ACX LPs\n\n post by Clayton_UMA on Aug 22, 2023\n\n 19 days later\n\n post by Ryan_UMA on Sep 11, 2023\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Reduce ACX emissions for Across ACX LPs\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 8\n\n Nov 2023\n\n Stop ACX Emissions on ACX LP\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 4\n\n May 2025\n\n Reduce ACX emissions for ACX LPs, WBTC LPs and wstETH/ACX LPs\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 11\n\n Aug 2024\n\n Stop ACX Emissions on wstETH/ACX LP Balancer Pool\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 2\n\n May 2025\n\n ACX Emissions Committee\n\n Proposals\n\n governance-updates\n\n Proposals\n\n Dec 2023","tokens":2156,"squid":"spider-09","role":"Bridge Spider","at":1791342722008,"hash":"e9232d1fd5c32d72591577047b90101646b5799b"}
{"url":"https://forum.across.to/t/reduce-or-reallocate-across-acx-lp-emissions/1703/3","domain":"forum.across.to","title":"Reduce or Reallocate Across ACX LP emissions - Ideas & Feedback - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n Ideas & Feedback\n\n liquidity\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Aug 2023\n\n 3 / 3\n\n Sep 2023\n\n Sep 2023\n\n post by Kevin_UMA on Aug 22, 2023\n\n Kevin_UMA\n\n Across ACX LPs staked in reward locking currently earn 7.84% to 26.7% driven by base emissions of 20,000 ACX per day.\nThis is a significant amount given there is currently very little ACX being bridged. The emissions were initially set high to get ACX airdrop recipients to not immediately sell their tokens and to get them familiar with the reward locking mechanism. Given it’s been 9 months since the launch of the token the community should consider reducing these emissions.\nIn addition, incentives will be added to enhance liquidity on the ACX token. The community voted to end bribes on Aura and instead incentivize the Balancer pool with Reward Locking and also bribe on Velodrome. The generally idle ACX in the Across LP would be better served supporting these pools instead. In total the DAO would be spending 38k to 52k ACX per day on ACX related pools.\n20k ACX / day - Across LP\n7k -21k / day - wstETH/ACX Balancer pool (1 to 3x multiplier)\n11k/day - Velodrome pool (75k per week)\nTotal = 38k to 52k ACX / day\nThis is in comparison to the current base emissions for other assets on Across:\n~50,000 ACX per day for Across ETH LP tokens\n~50,000 ACX per day for Across USDC LP tokens\n~5,000 ACX per day for Across DAI LP tokens\n~5,000 ACX per day for Across WBTC LP tokens\nDiscussion: How much should these emissions be reduced? Should we reallocate the emissions to other pools? Some options to consider:\n\nCut emissions by 50% and don’t reallocate\nMove emissions to lower volume assets like DAI or WBTC\nMove emissions to higher volume assets like ETH or USDC\nMove some portion to temporarily create interest for smaller tokens like POOL and SNX\nAdd more incentives to ACX liquidity\n\nWhat do people think?\n\n Reduce ACX emissions for Across ACX LPs\n\n post by Clayton_UMA on Aug 22, 2023\n\n Clayton_UMA\n\n Thanks for compiling all the details in one location like this, it’s very helpful.\n\nMove some portion to temporarily create interest for smaller tokens like POOL and SNX\n\nI’m curious how beneficial these teams would find this? And how attractive it would be from a marketing perspective? If we can offer some amount of subsidized rate to onboard your token, perhaps as part of the deal for them to lend RL funds for a relayer or something?\n\n 19 days later\n\n post by Ryan_UMA on Sep 11, 2023\n\n Ryan_UMA\n\n Thanks for this proposal.\nI do agree the ACX pool is overweighted, and Across could benefit by attracting additional liquidity for higher volume / high utilization pools. I would be in favor of a reduction (but not elimination) of incentives for ACX pool with reallocation to USDC and WETH.\nHowever, we need to evaluate how something like this would interact with the proposal to reduce max multiplier while increasing base emissions by 50%.\nWith the ultimate goal being to get the most out of ACX incentives (in terms of user and liquidity acquisition), I think we should move forward with the proposal to reduce max multiplier while increasing base emissions by 50% first and then see the response, and then evaluate if we should move forward with this proposal in the future.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Reduce ACX emissions for Across ACX LPs\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 8\n\n Nov 2023\n\n Stop ACX Emissions on ACX LP\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 4\n\n May 2025\n\n Reduce ACX emissions for ACX LPs, WBTC LPs and wstETH/ACX LPs\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 11\n\n Aug 2024\n\n Stop ACX Emissions on wstETH/ACX LP Balancer Pool\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 2\n\n May 2025\n\n ACX Emissions Committee\n\n Proposals\n\n governance-updates\n\n Proposals\n\n Dec 2023","tokens":2456,"squid":"spider-09","role":"Bridge Spider","at":1791342732126,"hash":"60907f37c71f46e0dd4686cfeb453505da0cfc9b"}
{"url":"https://ethresear.ch/t/uncrowdable-inclusion-lists-the-tension-between-chain-neutrality-preconfirmations-and-proposer-commitments/19372","domain":"ethresear.ch","title":"Uncrowdable Inclusion Lists: The Tension between Chain Neutrality, Preconfirmations and Proposer Commitments - Economics - Ethereum Research","text":"Uncrowdable Inclusion Lists: The Tension between Chain Neutrality, Preconfirmations and Proposer Commitments \n\n Economics\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 4\n\n read \n\n 10\n min\n\n Apr 2024\n\n 1 / 7\n\n Apr 2024\n\n May 2024\n\n post by Julian on Apr 25, 2024\n\n Julian\n\n Screenshot 2024-04-25 at 10.49.521622×1606 128 KB\nBy @Julian, @barnabe and @soispoke\nValidators are the most decentralized set of participants at any level of the Ethereum protocol and infrastructure. This is a design goal of Ethereum because only then can the protocol leverage this decentralization to obtain protocol resilience:\n\nAs consensus service participants, a decentralized set of validators ensures resilience against correlated failures, either accidental (e.g., due to bugs taking offline a certain share of the validator set) or malicious (e.g., a share of the validator set producing a safety fault).\nAs block producers, a decentralized set of validators creates resilience against extractive cartels, which may be looking for undue rents, e.g., via censoring or re-ordering.\n\nThis post investigates the second role of validators and their duties as block producers. First, we explore how the protocol can leverage the decentralized validator set to uphold a concept we call chain neutrality. Then, we discuss how preconfirmations and PEPC may crowd out an in-protocol inclusion list from upholding chain neutrality, thereby introducing a property of inclusion lists that is the main topic of this post: uncrowdable inclusion lists. Finally, we compare unconditional inclusion lists with an instance of PEPC and investigate who should receive tips associated with transactions that are executed via the inclusion list.\nTowards recovering chain neutrality\nIn the past, validators (and miners before them) engaged passively both as builders, collecting transactions and sequencing them in blocks using simple heuristics, and as proposers, signing the block and gossiping it over the network.\nMaximal Extractable Value (MEV), the value which a validator may extract in their duties as block producer, changed the paradigm. Validators turned into passive proposers engaging with a distinct set of active builders. Active builders do not simply collect transactions and mindlessly pack them into blocks; instead, they actively optimize for the value they can extract from the block’s contents. Meanwhile, validators, as passive proposers, simply listen for offers from builders who wish to build on their behalf.\nUnfortunately, as a numerically much smaller set with its own profit-maximizing goals, there is no reason for builders’ objectives and preferences to be aligned with validators regarding the inclusion or censorship of certain transactions or even with the preferences of network stakeholders broadly. More generally, the following principle may be put forward:\n\nChain neutrality: Any pending, fee-paying transaction ought to be included if it is available and if there is room to include it on-chain.\n\nChain neutrality is meant to encompass principles larger than censorship resistance alone. Under censorship resistance, as we conceive of it, there is an active and targeted effort to prevent the access of some user to on-chain inclusion. However, with today’s dense supply networks of intermediated relationships, some user interactions may fall by the wayside for accidental reasons simply because their transaction does not participate in increasing the welfare of the supply network intermediaries. An example is builders excluding transactions not to censor them per se, but to decrease the amount of time it would take a block to propagate over the network. In our opinion, users must always be able to “get on-chain” as long as they satisfy the two requirements spelled out in the definition of chain neutrality.\nValidators as passive block producers would simply fill up their blocks from the mempool, ensuring allocation of blockspace to users who indeed satisfy the requirements of chain neutrality. Yet, with today’s systems, proposers have the choice of either remaining passive (”local building”) or locking themselves out entirely from participating in block production (with MEV-Boost). To preserve chain neutrality, we are then looking for ways to recover the diversity that validators embody by allowing them to provide input into block production, even when they decide to delegate building.\nInclusion lists (ILs) are a proposed method to recover validator participation in block creation. The validator produces an IL that the builder must satisfy according to the IL model’s specifications (e.g., the builder must include all transactions from the IL in their block or produce a block that cannot contain more transactions from the IL).\nThe first observation is that validators have not been forced into outsourcing their block building to active builders and have done so to maximize their own returns. It is then unclear why a validator would care to produce an IL binding the builders for their slot, forcing them to include transactions that the builders may wish to steer clear of. For this reason, the model of forward inclusion lists was proposed. Forward inclusion lists are built by the validator-proposer of slot n and constrain the block produced by the validator-proposer of slot n + 1. From the perspective of network stakeholders, constraints on validators to respect and preserve chain neutrality, even when imposed externally by distinct validators, appear to be legitimate.\nBut how can we judge the success of inclusion lists in bolstering chain neutrality beyond other potential use cases for ILs? Naively, we could consider the quantity and quality of transactions in the IL. Are the transactions reported in the IL indeed susceptible to censorship, for example, or is the IL used for other goals? This is an important question since the inclusion list is a scarce protocol product, yet other use cases lie in wait!\n\nPreconfirmations: Preconfirmations are agreements between a proposer and a user regarding the conditions for inclusion of a user’s transaction, e.g., within some time interval or acting upon some specific state. Preconfirmations offered by the validator-proposer hence require the validator to have some input into the block-building process. ILs look like a good place for the proposer to register their commitments, which may mean that the IL might be used for preconfirmations instead of for its purpose of ensuring chain neutrality.\nPartial block building: Allowing multiple builders to build different parts of the block may have value. ILs could offer a path to implementing a rough protocol for such partial building commitments, using the same pattern as mev-boost (think “IL-boost” with an IL builder feeding the data to the validator-proposer). More generally, the value proposition of PEPC is to leverage the proposer’s ability to make commitments regarding the organization of block building, including commitments about partial contents. ILs allow for a limited class of commitments on building a block, so is there again a conflict between ILs as neutral input surfacing and ILs as coordination gadgets toward partial block building.\n\nHere lies the crux of the problem. Other use cases that potentially unlock a lot of value for the IL proposer can use the commitment power that the IL proposer receives from the protocol. Preconfirmations and certain PEPC-esque proposer commitments could be realized via inclusion lists. If a proposer makes more profit by constructing their IL for these use cases than for others, they likely will. When ILs are used for cases other than chain neutrality, we say that the chain neutrality use case is crowded out. This post suggests a new design property for inclusion lists: uncrowdability. We examine how a protocol can ensure that a protocol product becomes uncrowdable, and we apply this reasoning to the currently proposed inclusion list models.\nUncrowdable Inclusion Lists\nWe informally define uncrowdable inclusion lists as inclusion lists that create more value for the inclusion list proposer when used for the purpose the protocol intended them to than when used for other purposes. Making ILs uncrowdable should be a protocol design goal. Similarly to work done on PBS, we delineate the design space of inclusion lists into the allocation rule and the market structure.\nThe market structure is the collection of rights and obligations that are assigned to the inclusion list. Who gets to make the inclusion list? To which block(s) does the inclusion list apply? How is the inclusion list enforced? We have seen a number of different proposed IL designs that each use a different market structure. Forward inclusion lists allow the beacon proposer of block n𝑛 to create the IL that applies to block n + 1𝑛 +1. Conditional ILs are enforced only if there is space for the transactions from the IL to be included in the block, whereas unconditional ILs are enforced regardless of the number of transactions in the main block body. Similarly, a cumulative, non-expiring inclusion list is also a different protocol product.\nThe allocation rule of inclusion lists refers to the space of commitments that the IL proposer may implement. The ideal allocation would be including in the list a set of transactions that are “censored.” IL proposers may implement other allocation rules, such as outsourcing IL production to third parties, e.g., via the aforementioned hypothetical IL-boost. The protocol can create a market structure such that the allocation rule that an IL proposer chooses also achieves the goal of upholding chain neutrality.\nThe protocol can use the market structure to incentivize the IL proposer to choose an allocation rule that upholds chain neutrality. Different market structures elicit different allocation rules used by IL proposers.\nArguably, conditional inclusion lists could be closer to being uncrowdable than unconditional ones because they offer fewer guarantees about the inclusion of transactions. Unconditional ILs could more easily be used for other use cases. Therefore, using the market structure of conditional ILs may incentivize the IL proposer to choose an allocation rule that upholds chain neutrality, thereby making ILs more uncrowdable.\nThe protocol could also make ILs uncrowdable by choosing a market structure that restricts the set of possible allocation rules. COMIS is such a mechanism. It roughly states that an inclusion list is constructed out of the inclusion sets that each member of a large committee makes. If a transaction is included in at least a certain fraction of the inclusion sets, it must be included in the final inclusion list. Such a mechanism clearly leads to a market structure that is more opinionated about its purpose, and it would be more costly for an IL proposer to use the IL for any other purpose than for chain neutrality.\nThere may be a more general argument to be made here. In upholding chain neutrality, the protocol makes an opinionated choice in favor of censored parties, even though this may lead to a welfare gap. A market-based solution, where the allocation rule is unconstrained, generally aims to find the welfare-maximizing solution, meaning that the MEV of one specific block is maximized. Therefore, if a protocol wants chain neutrality, maybe it must constrain the set of possible allocation rules. Potentially, this is analogous to a protocol that needs to specify an allocation rule for block construction if it wants to enforce a first-come, first-served block allocation rule.\nGiven this welfare gap, one might also wonder whether it is bad for the protocol-specified purpose to be crowded out by other use cases. However, whether this welfare gap is desirable is a governance question and not one that should be answered by markets. Moreover, other use cases, such as preconfirmations, do not require protocol products and may be satisfied by out-of-protocol proposer commitments such as PEPC-Boost or EigenLayer-based systems. Chain neutrality is hard to improve with out-of-protocol systems.\nComparison between Inclusion Lists, PEPC, and Multiple Concurrent Block Producers\nWe’ve touched upon the possibility of some use cases crowding out others, given the design of the inclusion list market structure. Use cases embody the demand for certain features or outcomes that market participants desire to achieve. If the demand cannot be satisfied directly by some product yet can be satisfied indirectly by some other product, then even if the indirect product is not ex-ante designed to accommodate this demand, some use cases will crowd out others. We must now understand where the demand for use cases such as preconfirmations or more general proposer commitments comes from and why inclusion lists allow for indirect expression of these use cases.\nBroadly, we think of inclusion lists, preconfirmations, proposer commitments, and other phenomena as instances of a larger will to participate in block co-creation. As an atomic unit, a block represents a big amount of space to allocate for the expression of user preferences, via transactions. A Hayekian argument may be advanced that no single party has the knowledge necessary to make a good block and thus must rely on decentralized knowledge of a larger number of market participants. Preventing the expression of this decentralized will to include creates pent-up demand, which will seek to realize itself in any way that it can.\nAs an example, unconditional ILs reserve a certain amount of blockspace in block n+1𝑛 +1 for the inclusion list, which is proposed and built by the proposer of block n𝑛. This setup is very similar to an instance of PEPC with two partial builders. In fact, if the protocol could take delivery of both blocks separately instead of requiring one builder to bundle the inclusion list with the regular block, we would not need the “forward” property of the IL, and we would obtain exactly two parallel builders, although some transactions in the unconditional IL may already be executed in the main block body if it were appended to the end of block n+1𝑛 +1.\nIf a single funnel, such as inclusion lists, cannot adequately realize every type of demand from the market, can we look for differentiated “pipes” adapted to each type of use case that may occur? Barnabé suggests the idea of a “mixed IL”: an IL built up from a) a spot (applying to the block of the IL proposer) unconditional IL and b) a forward conditional IL. This would allow good quality preconfirmations to be issued in the spot unconditional IL, whereas the forward conditional IL could still be used for chain neutrality.\nAlternatively, we could also design a spot IL that upholds chain neutrality. By using a spot unconditional IL with COMIS, the role of the block proposer in the construction of the IL could be removed and replaced by a committee. This is a change in market structure similar to execution tickets since we question whether the beacon proposer of a slot should receive the rights to propose the inclusion list, instead of actors directly interacting with the protocol.\nFurthermore, unconditional ILs that apply to slot n𝑛 but are made by another party than the beacon proposer of slot n𝑛 result in something that looks very similar to multiple concurrent block producers. The differences and similarities between these different forms of block co-creation are currently under-explored.\nInclusion List Tips\nThe current inclusion list spec says that the tips associated with the transactions in the IL are rewarded to the proposer of the block in which these transactions are executed, not to the proposer that included the transactions in the IL. In this part of the post, we argue that rewarding the tips to the IL proposer instead of the block proposer 1) creates a scheme in which tips can conditionally pay for censorship resistance, 2) may be inevitable, and 3) increases the cost of censorship. Note that if a credible mechanism to reward IL proposers existed, the protocol could reward IL proposers in different ways; it could use issuance, for example.\nFirst, by giving tips from transactions that are executed via the IL, we can reward the IL proposer for providing a valuable service of chain neutrality. Here, we would consider a transaction executed via the IL if the transaction is in the IL but not in the main block body of any earlier block. This is good for the proposer as it closes the welfare gap between using the IL for censorship resistance and for other purposes: the IL is more uncrowdable. Moreover, it is also good for the user because it allows them to pay for this service, conditional on the transaction not being included in any other way. This may be more difficult to do out-of-protocol.\nWhile conditional tips for censorship resistance may be more difficult out-of-protocol, it is trivial for the inclusion list proposer to demand that any transaction that wants to be included in the IL bribe the proposer and then allow these transactions to be included in the list with 0 tips.\nFinally, the cost of censorship, defined in “Censorship Resistance in On-Chain Auctions” by Elijah Fox, Mallesh Pai, and Max Resnick as the minimum cost an adversary would have to pay to censor a transaction, doubles when rewarding the IL proposer with the tip instead of the block proposer. This is because an adversary would not only need to bribe the block proposer to exclude the transaction, but it would also need to bribe the inclusion list proposer by the amount of the tip instead of by any arbitrarily small amount.\nConclusion\nTo summarize, this post argues that the forward property of inclusion lists is insufficient to guarantee that inclusion lists will be used to uphold chain neutrality. We introduce the concept of uncrowdable inclusion lists, which may explain why a certain inclusion list design will or will not achieve the protocol-specified goal of chain neutrality. Uncrowdable inclusion lists create more value for the list proposer when used for the protocol-desired goal than for any other goal. The protocol can be designed for uncrowdable inclusion lists by creating a market structure that induces a desirable allocation rule. Finally, we argue that it is beneficial for the tips associated with transactions in the inclusion list to be rewarded to the inclusion list proposer instead of to the block proposer.\n\n Embedded fee markets and ERC-4337 (part 1)\n\n Fork-Choice enforced Inclusion Lists (FOCIL): A simple committee-based inclusion list proposal\n\n Mechan-stein (alt. Franken-ism)\n\n Future-Proofing Preconfirmations\n\n LUCID: Encrypted mempool with distributed payload propagation\n\n 4\n\n read \n\n 10\n min\n\n post by Evan-Kim2028 on Apr 25, 2024\n\n Evan-Kim2028\n\nCould you expand on this point? I thought it was interesting, but not sure where you were going with this thought.\n\n post by Julian on Apr 26, 2024\n\n Julian\n\n If the transaction was included in the IL and not in any previous main block body, the tip could be given to the IL proposer. This would mean a user only pays for execution through the IL if it indeed requires the services of the IL proposer.\nNow, assuming that the tips are paid to the block proposer of the slot to which the IL applies, we can analyze what could happen out-of-protocol. In my view, there are three options:\n\nThe transaction pays its tip to the block proposer. This is the simplest way and does not reward IL proposers for their service. IL proposers may not include transactions that do not pay tips to the IL proposer.\nA separate transaction pays the IL proposer as a “tip”. This would mean the IL proposer receives the proceeds of the tips regardless of whether the transaction included in the IL is executed via the IL. It could be that the transaction is included elsewhere.\nThe transaction uses an out-of-protocol conditional tipping system, which would lead to the same outcome as the in-protocol conditional tipping system. However, it would be more costly to implement, and the IL proposer and the user must agree on the terms of the contract.\n\n post by Keccak255 on Apr 27, 2024\n\n Keccak255\n\n Great post!\nLet me clarify my understanding, am I correct in understanding that additional incentives for IL proposers to utilize ILs for protocol intended goals?\nRegarding the effectiveness of these incentives, could you elaborate more on the methods or envisions used to quantitatively measure how well the use of ILs achieve specific goals?\nAnd also, could you provide more details on how this additional incentives is envisioned? I felt like a good approach might be to increase rewards based on the extent to which the IL is used for the intended goals.\n\n post by Julian on Apr 29, 2024\n\n Julian\n\n A main idea of this post is to recognize that the specific design that is chosen for inclusion lists (unconditional, cumulative, COMIS, etc.) means that certain use cases can more easily be realized via these inclusion lists designs than via others.\nIt is important to choose a design that induces the allocation rule that the community desires. If we want to make inclusion lists that uphold chain neutrality, we must make sure that they are not used for other profit-driven purposes.\nCreating explicit additional incentives to follow the allocation rule that the protocol wishes is a related but not identical topic. In this post, we discuss a method of achieving explicit incentives for upholding chain neutrality in the following paragraph.\n\nIt is difficult for the protocol to be aware of the quality of the inclusion list as it can only ascertain which transactions are censored by observing the IL. Out-of-protocol, I imagine we can get more insights, for example with websites like https://www.censorship.pics/.\n\n post by awmacp on Apr 30, 2024\n\n awmacp\n\nIs it possible to quantify “fee-paying”? Is the idea that any transaction with a positive priority fee be included into the next block with space remaining, or should the priority fee exceed a “market price” determined according to some heuristic? If the latter, how could this market price be measured without being skewed down by hidden out-of-band MEV payoffs?\n\nDo you have in mind any further examples of chain neutrality failures other than targeted censorship or excluding transactions as a bandwidth control measure? Is any attempt to improve proposer liveness by throttling block size (measured in bytes) considered non-neutral?\n\nHow is this any different from paid preconfirmations provided by the proposer? If paid preconfirmations are not the “the purpose the protocol intended” for ILs then how does this scheme aid in creating an uncrowdable IL?\nEdit: OK, I see that it’s different because the preconfirmation is being issued by a different party than the one actually including it. Apart from meaning an earlier cutoff time for buying this type of preconfirmation, it’s unclear to me that this will affect preconf prices, or whether this matters for your notion of uncrowdability.\n\n post by Julian on May 2, 2024\n\n Julian\n\nFee-paying would mean that the transaction pays the prevailing base fee and a positive tip. Any transaction that pays at least this amount should be included on-chain if there is still space, regardless of whether the transaction carries MEV (outside of the tip) with it.\n\nI wouldn’t have any other examples at the moment, maybe they will continue to arise as the MEV ecosystem develops.\n\nThe block size should be determined via community governance to balance proposer liveness and factors such as throughput. Not all attempts to improve proposer liveness by throttling block size are non-neutral; for example, if the community decides that we should throttle block size to improve proposer liveness, then this would be considered neutral. However, if an individual proposer does not adhere to the block size determined by the community, then this would be considered non-neutral.\n\nGiving the tips of transactions that are incorporated in the IL to the IL proposer decreases the welfare gap for the IL proposer between using the IL for chain neutrality or for pursuing maximum profits through, for example, preconfirmations. This means that giving tips to the IL proposer will likely make ILs more uncrowdable.\nTransactions in ILs are indeed not very different from preconfirmations in the sense that a transaction achieves some guarantees of inclusion before being included. The goal, however, is very different. Instead of increasing UX or composability, the goal is to uphold chain neutrality.\nThis similarity is one of the reasons why we think of inclusion lists and preconfirmations as instances of a larger will to participate in block co-creation.\n\n Powered by Discourse","tokens":6192,"squid":"spider-04","role":"Research Spider","at":1791342732215,"hash":"06e8a42d650224da392803633ced8d1197cb2759"}
{"url":"https://forum.across.to/t/stop-acx-emissions-on-wsteth-acx-lp-balancer-pool/2061","domain":"forum.across.to","title":"Stop ACX Emissions on wstETH/ACX LP Balancer Pool - Proposals - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n Stop ACX Emissions on wstETH/ACX LP Balancer Pool \n\n Proposals\n\n treasury-funding\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n May 2025\n\n 1 / 4\n\n May 2025\n\n May 2025\n\n post by Kevin_UMA on May 20, 2025\n\n Kevin_UMA\n\n Title: Stop ACX Emissions on wstETH/ACX LP Balancer Pool\nAuthors: ACX Emissions Committee (Kevin Chan, David Korpi, Ryan Carman, Dylan O’Reilly, Chase Coleman)\nStatus: Proposal\nRelated Discussions: ACX Emissions Committee, ACX Emissions Committee Framework Update, Reduce ACX emissions for ACX LPs, WBTC LPs and wstETH/ACX LPs\nSummary:\nThe Across DAO should stop ACX emissions for Balancer wstETH/ACX LPs following improved liquidity of ACX on CEXes and DEXes. The aim is to optimize DAO capital efficiency by aligning rewards with actual usage and market conditions. The current emissions are disproportionately high relative to the volume this pool supports. Better liquidity solutions are already in place.\nThe ACX Emissions Committee only has permissions and a framework to control ACX emissions for ETH, USDC, USDT, and DAI. We are putting together this one-off proposal to cease Balancer wstETH/ACX LP ACX emissions.\nMotivation:\nThe wstETH/ACX LP staking pool current base emissions per second are 5,250 ACX/day. Taking into account the multiplier this means the pool currently receives approximately 11,350 ACX (~$2,600) per day in emissions while averaging just $100,000 in daily trading volume. This translates to a high cost per unit of onchain liquidity that is no longer justified. This proposal recommends reducing the emissions to 0 ACX per day.\nThere are three key reasons to support this proposal:\n\nPoor Capital Efficiency\n\nThe wstETH/ACX Balancer pool averages $100,000 in daily trading volume.\nThis comes at a cost of $2,600 per day (at $0.23 ACX price), resulting in disproportionately high incentives for relatively low return in terms of liquidity.\n\nRobust Off-Chain Liquidity\n\nSince the Binance listing and other major CEX listings in late 2024, ACX now averages over $10 million in daily trading volumes across centralized exchanges.\nThis significantly reduces our reliance on onchain liquidity for ACX.\n\nBetter Onchain Alternatives Already Exist\n\nThe DAO currently supports a Uniswap v3 vault through Arrakis, which provides onchain liquidity without direct emissions.\nThese vaults are funded via trading fees and represent a much more sustainable model for long-term liquidity provision.\n\nSpecification & Implementation:\n\nCurrent emissions: 11,350 ACX per day (5,250 ACX base emissions per day)\nProposed emissions: 0 ACX per day (0 ACX base emissions per day)\nThis change will take effect at the beginning of the next epoch following proposal approval.\nNo changes to the underlying pool structure or staking mechanism are proposed.\n\nRationale:\n\nCuts daily emissions cost by ~$2,600, saving the DAO valuable ACX.\nEncourages a shift toward sustainable, fee-based onchain liquidity strategies like the Arrakis Uni v3 vault.\nSignals to the community and stakeholders that the DAO is taking a disciplined, data-driven approach to emissions and capital deployment.\n\nDownside (Cons):\n\nLikely a reduction in TVL or liquidity depth in the wstETH/ACX Balancer pool.\nMay discourage some LPs from continuing to provide liquidity if they are highly incentive driven.\n\nVoting:\n\n Should the Across DAO end ACX base emissions for Balancer wstETH/ACX LPs? A “YES” vote means that you would like to decrease the ACX base emissions per day being paid to Balancer wstETH/ACX LPs from 5,250 ACX/day to 0 ACX/day. A “NO” vote means that you would like the ACX base emissions per day being paid to Balancer wstETH/ACX LPs to stay the same.\n\n 86%\n Yes\n\n 14%\n No\n\n 0%\n Abstain\n\n 7\n voters\n\n Closed May 2025\n\n 2\n\n post by TheRealTuna_Across on May 24, 2025\n\n post by Kevin_UMA on May 26, 2025\n\n 1 month later\n\n Closed on Jun 25, 2025\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Reduce ACX emissions for ACX LPs, WBTC LPs and wstETH/ACX LPs\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 11\n\n Aug 2024\n\n Reduce or Reallocate Across ACX LP emissions\n\n Ideas & Feedback\n\n liquidity\n\n Ideas & Feedback\n\n 2\n\n Sep 2023\n\n Stop ACX Emissions on ACX LP\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 4\n\n May 2025\n\n Reduce ACX emissions for Across ACX LPs\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 8\n\n Nov 2023\n\n Reduce ACX emissions for WBTC LPs\n\n Active Proposals\n\n Active Proposals\n\n Aug 2025","tokens":2606,"squid":"spider-09","role":"Bridge Spider","at":1791342742174,"hash":"3ac563ba53189f21e7fd968f2d782138d56e95b5"}
{"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 Who cleans up the code? SETCODEFROM’s dangling bytecode and futureproof design choices\n\n Execution Layer Research\n\n 0\n\n 33\n\n 6h\n\n Breaking the Serial Verification Loop via an Asynchronous Pipeline Consensus Architecture\n\n Consensus\n\n 0\n\n 26\n\n 12h\n\n Ethereum Cryptography and AI slop\n\n Cryptography\n\n 5\n\n 283\n\n 13h\n\n Accountability for Encrypted Mempools\n\n Cryptography\n\n mev,censorship-resistance\n\n 0\n\n 110\n\n 1d\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 554\n\n 1d\n\n Proposal for a minimal compute-anchored purchasing power signal\n\n Economics\n\n 0\n\n 58\n\n 4d\n\n Six defects in one signature verification tool, found from outside in six rounds\n\n Security\n\n 0\n\n 57\n\n 4d\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 788\n\n 5d\n\n Staking rewards as venture capital, governed by futarchy\n\n Economics\n\n dao,futarchy\n\n 2\n\n 222\n\n 5d\n\n Trust minimized transaction simulation using state proofs\n\n Security\n\n 7\n\n 635\n\n 6d\n\n PQ anonymity for Stealth Address Protocol\n\n Privacy\n\n 4\n\n 221\n\n 6d\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 149\n\n 7d\n\n Towards Encrypted Mempools from Threshold IBE without Batching\n\n Cryptography\n\n 4\n\n 240\n\n 7d\n\n Ethereum’s TCB, Part 1: The client\n\n Security\n\n security\n\n 3\n\n 364\n\n 8d\n\n PQ spending for Stealth Address Protocol\n\n 0\n\n 63\n\n 9d\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 415\n\n 9d\n\n Formal Verification of Execution and Consensus Clients\n\n Security\n\n security\n\n 12\n\n 602\n\n 12d\n\n Snappy with a memory: ~40% less gossip traffic\n\n Networking\n\n single-slot-finality\n\n 1\n\n 153\n\n 12d\n\n Capacity oracles\n\n Economics\n\n 4\n\n 415\n\n 12d\n\n Designs for EVM gas accounting in EIP-7999\n\n Execution Layer Research\n\n fee-market\n\n 6\n\n 464\n\n 12d\n\n Proprietary AMMs and Ethereum\n\n Execution Layer Research\n\n mev\n\n 13\n\n 1.3k\n\n 13d\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 109\n\n 13d\n\n Post-Poseidon: Hash Function Variants for Ethereum\n\n Cryptography\n\n 0\n\n 316\n\n 14d\n\n EIP-8411 payload segmentation under the Shadow simulator\n\n Networking\n\n p2p,scaling\n\n 0\n\n 81\n\n 14d\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 15d\n\n Etheorem update: the complete executable consensus specs written in Lean 4\n\n Consensus\n\n 0\n\n 193\n\n 16d\n\n Post-Glamsterdam One-dimensional Fee Market and Comparison with EIP-7999\n\n Economics\n\n 0\n\n 150\n\n 16d\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 18d\n\n Cryptographic canaries and backups\n\n Cryptography\n\n 8\n\n 7.6k\n\n 19d","tokens":860,"squid":"spider-04","role":"Research Spider","at":1791342743474,"hash":"0ab6f67a97fb437079a8a8ae285cd9e9a6564eea"}
{"url":"https://akash.network/architectural-overview","domain":"akash.network","title":"Architectural Overview — Akash Network","text":"Architectural Overview\n\nAkash matches infrastructure supply with developer demand via an open, programmatic request-for-quote routing engine. The protocol decouples container deployment logic from physical hardware providers, standardizing secure cloud resource access.\n Akash Deployment Simulator$ akash tx deployment create manifest.yaml # manifest.yamlversion: '2.0'services: inference: image: myorg/vllm-server:latestprofiles: compute: inference: resources: gpu: { units: 1 } memory: { size: 16Gi } → Validating SDL manifest...→ Broadcasting to on-chain ledger...✓ Manifest received by marketplace \nCore Technical Pillars\n Declarative Infrastructure (SDL) \nInstead of manually clicking through cloud consoles, configurations are defined entirely via Stack Definition Language (SDL). This YAML-based format contains the absolute, machine-readable state of your application—specifying OCI images, environment variables, network routing rules, and strict hardware constraints like isolated GPU profiles or minimum VRAM thresholds.\n Programmatic Request Routing \nThe network replaces manual human procurement with a real-time, automated matching engine. When an SDL manifest is broadcast, matching criteria are cross-referenced instantly by available providers. Compatible data centers automatically generate real-time hosting bids, establishing a highly transparent, market-driven pricing ecosystem for compute resources.\n Automated Escrow Settlements \nWorkloads are secured by automated network leases that pull from a streaming escrow account. Funded seamlessly via standard credit card billing or cloud credits, the settlement engine streams payments continuously on a per-block basis. This ensures predictability for both parties: billing stops instantly if a container is torn down, and remaining escrow funds are automatically returned to your balance.\n\nStructural Layer Breakdown\n\nThe protocol is divided into three discrete functional layers. Each layer has a defined execution boundary, a native technology stack, and a specific system responsibility within the deployment lifecycle.\n Architectural Tier Execution Component Native Technology Stack System Responsibility Control Plane Network Consensus Layer Distributed State Machine (Tendermint/Cosmos Engine) Manages secure, immutable registration of manifests, provider bids, active leases, and settlement finality. Ingestion Layer Network Gateway Module Core Orchestration APIs Executes real-time matching logic, routing inbound deployment requests directly to compatible provider nodes. Runtime Engine Provider Node Software Native Kubernetes + Open-Source Operator Pulls approved container manifests and orchestrates the complete workload lifecycle on verified physical hardware. centralized-cloud.modelSingle Vendor Control PointLegacy HyperscalerAWSAzureGCPPricing OpacityRates set by internal revenue teams. No market competition. No public bid history.Regional ConcentrationFixed datacenter footprint. Hardware availability tied to one entity's roadmap.Contractual Lock-inReserved discounts engineered to increase switching costs over time.No competitive market. No exit path. \nTraditional Hyperscale Isolation\n\nLegacy cloud platforms impose three structural constraints that have no technical justification. They exist solely because of the centralized ownership model.\n Single-vendor pricing opacity \nHyperscaler on-demand GPU prices are set by internal revenue teams, not by competitive market forces. There is no public bid history, no settlement transparency, and no mechanism for tenants to compare real costs across providers in real time. The list price is the only signal, and it includes an unspecified markup layer on top of actual hardware cost.\n Forced regional concentration \nTraditional architectures bind workloads to a small number of fixed datacenter regions owned and operated by a single entity. Hardware availability, regional outages, and capacity constraints are all determined by that entity's infrastructure roadmap rather than market supply. When a region is constrained, tenants queue or pay premium spot pricing with no alternative routing path.\n Contractual lock-in by design \nReserved instance discounts, committed use contracts, and proprietary networking primitives are designed to increase the switching cost over time instead of passing efficiency gains to customers. The longer a workload runs on a hyperscaler, the more entangled it becomes with vendor-specific APIs, private networking topologies, and billing structures that have no open-standard equivalent.\n\nThe Peer-to-Peer Coordination Gap\n\nDecentralized compute is not a new idea. What has historically blocked it is the coordination problem: how do two parties with no pre-existing trust relationship safely exchange hardware resources for payment without a centralized intermediary absorbing counterparty risk? Akash solves this at three layers.\n Manifest-level transparency \nThe deployment manifest is a public, cryptographically signed document on the blockchain. Every constraint the tenant specifies (including hardware minimums, region preferences, and maximum price) is verifiable by any party before a lease is created. Providers cannot selectively fulfill partial specs without the on-chain record reflecting the deviation.\n Automated Economic Settlement \nBilling is completely programmatic and eliminates manual, post-paid invoicing. When a workload is authorized via standard credit cards or cloud credits, an automated gateway initializes a streaming network escrow block. Behind the scenes, the protocol utilizes a Burn-Mint Equilibrium (BME) engine to programmatically convert settlement value into the network's native utility asset. Funds are drawn down continuously on a per-block basis at the exact hourly rate locked during the provider bid, providing fixed, transparent infrastructure pricing with zero trailing charges. If a container is torn down or a provider drops offline, any unspent balance is instantly released back to your account.\n Provider permissioning via on-chain audit \nHardware claims are not self-reported. Independent auditor wallets verify provider hardware inventories and write signed attestations to the chain. Tenants can filter bids exclusively to providers whose hardware has been third-party verified, eliminating the trust gap that has historically made peer-to-peer compute markets unworkable for production workloads.\n p2p-trust-architectureTrust Architecture3 layers active01Manifest TransparencyTenantNetworkSDL manifest is signed and public. Every hardware constraint and pricing cap is verifiable by any party before a lease is opened.02Automated Economic SettlementNetworkProviderEscrow initialized at the locked bid rate and drawn down per block. Stops immediately if the container is torn down. No trailing charges.03Provider PermissioningNetworkProviderIndependent auditor wallets verify hardware inventories and write signed attestations on-chain. Tenants filter to verified providers only.Network settlementTrustless · Automated","tokens":1763,"squid":"spider-03","role":"Compute Spider","at":1791342747159,"hash":"8b5c6823529e9cbca8dc44e4dc4c8feb44460b54"}
{"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 Ethereum Cryptography and AI slop\n\n Cryptography\n\n 5\n\n 283\n\n 13h\n\n Accountability for Encrypted Mempools\n\n Cryptography\n\n mev,censorship-resistance\n\n 0\n\n 110\n\n 1d\n\n Towards Encrypted Mempools from Threshold IBE without Batching\n\n Cryptography\n\n 4\n\n 240\n\n 7d\n\n Post-Poseidon: Hash Function Variants for Ethereum\n\n Cryptography\n\n 0\n\n 316\n\n 14d\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 15d\n\n Cryptographic canaries and backups\n\n Cryptography\n\n 8\n\n 7.6k\n\n 19d\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 29d\n\n Proposed PQ upgrade for ecrecover\n\n Cryptography\n\n account-abstraction,post-quantum\n\n 10\n\n 382\n\n Sep 4\n\n Poseidon2b is secure!\n\n Cryptography\n\n post-quantum\n\n 4\n\n 460\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 226\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 66\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 188\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 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 246\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":"spider-04","role":"Research Spider","at":1791342755930,"hash":"0585c1465cc6a6f7c9545239e5b5596863f99b57"}
{"url":"https://forum.across.to/t/stop-acx-emissions-on-wsteth-acx-lp-balancer-pool/2061/4","domain":"forum.across.to","title":"Stop ACX Emissions on wstETH/ACX LP Balancer Pool - Proposals - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n Proposals\n\n treasury-funding\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n May 2025\n\n 4 / 4\n\n Jun 2025\n\n May 2025\n\n post by Kevin_UMA on May 20, 2025\n\n Kevin_UMA\n\n Title: Stop ACX Emissions on wstETH/ACX LP Balancer Pool\nAuthors: ACX Emissions Committee (Kevin Chan, David Korpi, Ryan Carman, Dylan O’Reilly, Chase Coleman)\nStatus: Proposal\nRelated Discussions: ACX Emissions Committee, ACX Emissions Committee Framework Update, Reduce ACX emissions for ACX LPs, WBTC LPs and wstETH/ACX LPs\nSummary:\nThe Across DAO should stop ACX emissions for Balancer wstETH/ACX LPs following improved liquidity of ACX on CEXes and DEXes. The aim is to optimize DAO capital efficiency by aligning rewards with actual usage and market conditions. The current emissions are disproportionately high relative to the volume this pool supports. Better liquidity solutions are already in place.\nThe ACX Emissions Committee only has permissions and a framework to control ACX emissions for ETH, USDC, USDT, and DAI. We are putting together this one-off proposal to cease Balancer wstETH/ACX LP ACX emissions.\nMotivation:\nThe wstETH/ACX LP staking pool current base emissions per second are 5,250 ACX/day. Taking into account the multiplier this means the pool currently receives approximately 11,350 ACX (~$2,600) per day in emissions while averaging just $100,000 in daily trading volume. This translates to a high cost per unit of onchain liquidity that is no longer justified. This proposal recommends reducing the emissions to 0 ACX per day.\nThere are three key reasons to support this proposal:\n\nPoor Capital Efficiency\n\nThe wstETH/ACX Balancer pool averages $100,000 in daily trading volume.\nThis comes at a cost of $2,600 per day (at $0.23 ACX price), resulting in disproportionately high incentives for relatively low return in terms of liquidity.\n\nRobust Off-Chain Liquidity\n\nSince the Binance listing and other major CEX listings in late 2024, ACX now averages over $10 million in daily trading volumes across centralized exchanges.\nThis significantly reduces our reliance on onchain liquidity for ACX.\n\nBetter Onchain Alternatives Already Exist\n\nThe DAO currently supports a Uniswap v3 vault through Arrakis, which provides onchain liquidity without direct emissions.\nThese vaults are funded via trading fees and represent a much more sustainable model for long-term liquidity provision.\n\nSpecification & Implementation:\n\nCurrent emissions: 11,350 ACX per day (5,250 ACX base emissions per day)\nProposed emissions: 0 ACX per day (0 ACX base emissions per day)\nThis change will take effect at the beginning of the next epoch following proposal approval.\nNo changes to the underlying pool structure or staking mechanism are proposed.\n\nRationale:\n\nCuts daily emissions cost by ~$2,600, saving the DAO valuable ACX.\nEncourages a shift toward sustainable, fee-based onchain liquidity strategies like the Arrakis Uni v3 vault.\nSignals to the community and stakeholders that the DAO is taking a disciplined, data-driven approach to emissions and capital deployment.\n\nDownside (Cons):\n\nLikely a reduction in TVL or liquidity depth in the wstETH/ACX Balancer pool.\nMay discourage some LPs from continuing to provide liquidity if they are highly incentive driven.\n\nVoting:\n\n Should the Across DAO end ACX base emissions for Balancer wstETH/ACX LPs? A “YES” vote means that you would like to decrease the ACX base emissions per day being paid to Balancer wstETH/ACX LPs from 5,250 ACX/day to 0 ACX/day. A “NO” vote means that you would like the ACX base emissions per day being paid to Balancer wstETH/ACX LPs to stay the same.\n\n 86%\n Yes\n\n 14%\n No\n\n 0%\n Abstain\n\n 7\n voters\n\n Closed May 2025\n\n 2\n\n post by TheRealTuna_Across on May 24, 2025\n\n TheRealTuna_Across\n\n Across volume is probably strong enough now that we shouldnt need to incentivize an LP. I use Uniswap over Balancer personally.\n\n post by Kevin_UMA on May 26, 2025\n\n Kevin_UMA\n\n Thanks for the feedback. The stronger cex liquidity seems to have helped Uniswap. Also, we can consider a bigger commitment to Uniswap vaults like Arrakis.\n\n 1 month later\n\n Closed on Jun 25, 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 Reduce ACX emissions for ACX LPs, WBTC LPs and wstETH/ACX LPs\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 11\n\n Aug 2024\n\n Reduce or Reallocate Across ACX LP emissions\n\n Ideas & Feedback\n\n liquidity\n\n Ideas & Feedback\n\n 2\n\n Sep 2023\n\n Stop ACX Emissions on ACX LP\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 4\n\n May 2025\n\n Reduce ACX emissions for Across ACX LPs\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 8\n\n Nov 2023\n\n Reduce ACX emissions for WBTC LPs\n\n Active Proposals\n\n Active Proposals\n\n Aug 2025","tokens":2698,"squid":"spider-09","role":"Bridge Spider","at":1791342762422,"hash":"018de6b6d9152ccc6b7ba18ac71729020873dcb5"}
{"url":"https://ethresear.ch/t/exploring-the-design-space-for-a-post-quantum-public-key-registry-for-ethereum-validators/25040","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 29d 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":"spider-04","role":"Research Spider","at":1791342766396,"hash":"ead7313c848ec122fa9eb4f6d5f930438f9da052"}
{"url":"https://forum.across.to/t/reduce-acx-emissions-for-wbtc-lps/2082","domain":"forum.across.to","title":"Reduce ACX emissions for WBTC LPs - Proposals / Active Proposals - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n Reduce ACX emissions for WBTC LPs \n\n ProposalsActive Proposals\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Aug 2025\n\n 1 / 1\n\n Aug 2025\n\n Aug 2025\n\n post by Kevin_UMA on Aug 20, 2025\n\n Kevin_UMA\n\n Author(s): ACX Emissions Committee (Kevin Chan, David Korpi, Ryan Carman, Dylan O’Reilly, Chase Coleman)\nStatus: Proposed\nRelated Discussions: Reduce ACX emissions for ACX LPs, WBTC LPs and wstETH/ACX LPs\nSummary\nThe Across DAO should decrease ACX emissions for Across WBTC LPs by 75%—from 7,200 ACX/day to 1,800 ACX/day. WBTC liquidity is being rewarded at a level that’s out of line with its usage and volume. While the ACX Emissions Committee (AEC) currently manages emissions for ETH, USDC, USDT, and DAI via a transparent framework, this proposal brings WBTC into scope and aligns its emissions with observable demand, just as we do for the other assets.\nMotivation\nAcross should optimally manage ACX emissions across all incentivized liquidity. The AEC adjusts emissions for ETH/USDC/USDT/DAI based on utilization and comparable yield indexes; WBTC was originally excluded due to limited comps. That gap now creates clear inefficiency:\n\nOverpayment vs. heavier-usage pools: WBTC currently receives nearly 2× the daily ACX emissions of the USDC pool despite servicing only ~5–10% of USDC’s daily volume.\nimage528×260 40.2 KB\nimage525×263 44.3 KB\n704×264 11 KB\n(AEC Dune Dashboard)\n\nChronic under-utilization: WBTC utilization has rarely exceeded ~50%, indicating we’re attracting more WBTC LP than needed to support observed demand.\n1107×558 33.1 KB\n\nLower operational burden: WBTC is now an OFT on some chains, making rebalancing less costly in both time and capital, further reducing the need to “pay up” for excess idle liquidity.\n\nTaken together, we are materially overpaying for WBTC liquidity relative to its contribution to the protocol. Re-aligning incentives should improve ACX capital efficiency and free emissions for higher-impact uses (e.g., ETH/USDC, growth initiatives, or Treasury conservation).\nSpecification & Implementation\n\nNew Emission Rate: Reduce WBTC LP emissions by 75% from 7,200 ACX/day → 1,800 ACX/day which is more in line with its usage and comparable assets.\n\nScope: Authorize the AEC to bring WBTC under its existing framework (utilization- and market-yield–aware adjustments), with the same permissions and guardrails used for ETH/USDC/USDT/DAI.\n\nExecution: If approved, the AEC will update the WBTC emissions parameter and begin monitoring standard KPIs (utilization, depth, fill quality, bridging latency, and rebalancing costs).\n\nRationale\n\nPay for what we use: Emissions should scale with demand. WBTC’s low share of volume vs. USDC/ETH doesn’t justify outsized rewards.\n\nOperational improvements: With WBTC as an OFT on some chains, the platform can maintain healthy routing with less liquidity “padding.”\n\nOpportunity cost: Reducing WBTC emissions releases ACX for more productive uses or conservation, improving protocol sustainability.\n\nDownside (Cons)\n\nPotential LP outflows in WBTC: The pool size may decline; however, current under-utilization suggests we can support equal or greater volume even if WBTC LP falls by ~50%. If adverse effects appear (e.g., persistent high utilization, worse pricing/latency), the AEC is empowered to make corrective tweaks under its framework.\n\nMonitoring & Review\n\nThe AEC will review WBTC utilization, routing quality, and volumes 2–4 weeks post-change and report back to the forum with observations and any recommended follow-ups.\n\nVoting\n\n Should the Across DAO reduce the ACX base emission rate for Across WBTC LPs and bring WBTC under the AEC’s remit for ongoing adjustments?\n\n 86%\n Yes: Reduce WBTC LP emissions from 7,200 ACX/day to 1,800 ACX/day and bring WBTC under the AEC’s remit for ongoing adjustments.\n\n 14%\n No: Leave WBTC emissions unchanged at 7,200 ACX/day and keep WBTC outside the AEC’s current scope.\n\n 7\n voters\n\n Closed Aug 2025\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Reduce ACX emissions for ACX LPs, WBTC LPs and wstETH/ACX LPs\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 11\n\n Aug 2024\n\n Stop ACX Emissions on wstETH/ACX LP Balancer Pool\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 2\n\n May 2025\n\n Reduce ACX emissions for Across ACX LPs\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 8\n\n Nov 2023\n\n Stop ACX Emissions on ACX LP\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 4\n\n May 2025\n\n ACX Emissions Committee\n\n Proposals\n\n governance-updates\n\n Proposals\n\n Dec 2023","tokens":2625,"squid":"spider-09","role":"Bridge Spider","at":1791342772524,"hash":"1f662a0ab94684f6eb0e4763e0b3094f70e1a074"}
{"url":"https://eips.ethereum.org/EIPS/eip-1271","domain":"eips.ethereum.org","title":"ERC-1271: Standard Signature Validation Method for Contracts","text":"🎉 Final\n\n Standards Track: ERC\n\n ERC-1271: Standard Signature Validation Method for Contracts\n\n Standard way to verify a signature when the account is a smart contract\n\n Authors\n Francisco Giordano (@frangio), Matt Condon (@shrugs), Philippe Castonguay (@PhABC), Amir Bandeali (@abandeali1), Jorge Izquierdo (@izqui), Bertrand Masius (@catageek)\n\n Created\n 2018-07-25\n\n Abstract\n\nExternally Owned Accounts (EOA) can sign messages with their associated private keys, but currently contracts cannot. We propose a standard way for any contracts to verify whether a signature on a behalf of a given contract is valid. This is possible via the implementation of a isValidSignature(hash, signature) function on the signing contract, which can be called to validate a signature.\n\n Motivation\n\nThere are and will be many contracts that want to utilize signed messages for validation of rights-to-move assets or other purposes. In order for these contracts to be able to support non Externally Owned Accounts (i.e., contract owners), we need a standard mechanism by which a contract can indicate whether a given signature is valid or not on its behalf.\n\nOne example of an application that requires signatures to be provided would be decentralized exchanges with off-chain orderbook, where buy/sell orders are signed messages. In these applications, EOAs sign orders, signaling their desire to buy/sell a given asset and giving explicit permissions to the exchange smart contracts to conclude a trade via a signature. When it comes to contracts however, regular signatures are not possible since contracts do not possess a private key, hence this proposal.\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\npragma solidity ^0.5.0;\n\ncontract ERC1271 {\n\n // bytes4(keccak256(\"isValidSignature(bytes32,bytes)\")\n bytes4 constant internal MAGICVALUE = 0x1626ba7e;\n\n /**\n * @dev Should return whether the signature provided is valid for the provided hash\n * @param _hash Hash of the data to be signed\n * @param _signature Signature byte array associated with _hash\n *\n * MUST return the bytes4 magic value 0x1626ba7e when function passes.\n * MUST NOT modify state (using STATICCALL for solc < 0.5, view modifier for solc > 0.5)\n * MUST allow external calls\n */ \n function isValidSignature(\n bytes32 _hash, \n bytes memory _signature)\n public\n view \n returns (bytes4 magicValue);\n}\n\nisValidSignature can call arbitrary methods to validate a given signature, which could be context dependent (e.g. time based or state based), EOA dependent (e.g. signers authorization level within smart wallet), signature scheme Dependent (e.g. ECDSA, multisig, BLS), etc.\n\nThis function should be implemented by contracts which desire to sign messages (e.g. smart contract wallets, DAOs, multisignature wallets, etc.) Applications wanting to support contract signatures should call this method if the signer is a contract.\n\n Rationale\n\nWe believe the name of the proposed function to be appropriate considering that an authorized signers providing proper signatures for a given data would see their signature as “valid” by the signing contract. Hence, a signed action message is only valid when the signer is authorized to perform a given action on the behalf of a smart wallet.\n\nTwo arguments are provided for simplicity of separating the hash signed from the signature. A bytes32 hash is used instead of the unhashed message for simplicity, since contracts could expect a certain hashing function that is not standard, such as with EIP-712.\n\nisValidSignature() should not be able to modify states in order to prevent GasToken minting or similar attack vectors. Again, this is to simplify the implementation surface of the function for better standardization and to allow off-chain contract queries.\n\nThe specific return value is expected to be returned instead of a boolean in order to have stricter and simpler verification of a signature.\n\n Backwards Compatibility\n\nThis EIP is backward compatible with previous work on signature validation since this method is specific to contract based signatures and not EOA signatures.\n\n Reference Implementation\n\nExample implementation of a signing contract:\n\n /**\n * @notice Verifies that the signer is the owner of the signing contract.\n */\n function isValidSignature(\n bytes32 _hash,\n bytes calldata _signature\n ) external override view returns (bytes4) {\n // Validate signatures\n if (recoverSigner(_hash, _signature) == owner) {\n return 0x1626ba7e;\n } else {\n return 0xffffffff;\n }\n }\n\n /**\n * @notice Recover the signer of hash, assuming it's an EOA account\n * @dev Only for EthSign signatures\n * @param _hash Hash of message that was signed\n * @param _signature Signature encoded as (bytes32 r, bytes32 s, uint8 v)\n */\n function recoverSigner(\n bytes32 _hash,\n bytes memory _signature\n ) internal pure returns (address signer) {\n require(_signature.length == 65, \"SignatureValidator#recoverSigner: invalid signature length\");\n\n // Variables are not scoped in Solidity.\n uint8 v = uint8(_signature[64]);\n bytes32 r = _signature.readBytes32(0);\n bytes32 s = _signature.readBytes32(32);\n\n // EIP-2 still allows signature malleability for ecrecover(). Remove this possibility and make the signature\n // unique. Appendix F in the Ethereum Yellow paper (https://ethereum.github.io/yellowpaper/paper.pdf), defines\n // the valid range for s in (281): 0 < s < secp256k1n ÷ 2 + 1, and for v in (282): v ∈ {27, 28}. Most\n // signatures from current libraries generate a unique signature with an s-value in the lower half order.\n //\n // If your library generates malleable signatures, such as s-values in the upper range, calculate a new s-value\n // with 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141 - s1 and flip v from 27 to 28 or\n // vice versa. If your library also generates signatures with 0/1 for v instead 27/28, add 27 to v to accept\n // these malleable signatures as well.\n //\n // Source OpenZeppelin\n // https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/cryptography/ECDSA.sol\n\n if (uint256(s) > 0x7FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF5D576E7357A4501DDFE92F46681B20A0) {\n revert(\"SignatureValidator#recoverSigner: invalid signature 's' value\");\n }\n\n if (v != 27 && v != 28) {\n revert(\"SignatureValidator#recoverSigner: invalid signature 'v' value\");\n }\n\n // Recover ECDSA signer\n signer = ecrecover(_hash, v, r, s);\n\n // Prevent signer from being 0x0\n require(\n signer != address(0x0),\n \"SignatureValidator#recoverSigner: INVALID_SIGNER\"\n );\n\n return signer;\n }\n\nExample implementation of a contract calling the isValidSignature() function on an external signing contract ;\n\n function callERC1271isValidSignature(\n address _addr,\n bytes32 _hash,\n bytes calldata _signature\n ) external view {\n bytes4 result = IERC1271Wallet(_addr).isValidSignature(_hash, _signature);\n require(result == 0x1626ba7e, \"INVALID_SIGNATURE\");\n }\n\n Security Considerations\n\nSince there are no gas-limit expected for calling the isValidSignature() function, it is possible that some implementation will consume a large amount of gas. It is therefore important to not hardcode an amount of gas sent when calling this method on an external contract as it could prevent the validation of certain signatures.\n\nNote also that each contract implementing this method is responsible to ensure that the signature passed is indeed valid, otherwise catastrophic outcomes are to be expected.\n\n Copyright\n\nCopyright and related rights waived via CC0.\n\n Citation\n Please cite this document as:\n\n Francisco Giordano (@frangio), Matt Condon (@shrugs), Philippe Castonguay (@PhABC), Amir Bandeali (@abandeali1), Jorge Izquierdo (@izqui), Bertrand Masius (@catageek), \"ERC-1271: Standard Signature Validation Method for Contracts,\" Ethereum Improvement Proposals, no. 1271, July 2018. Available: https://eips.ethereum.org/EIPS/eip-1271.","tokens":2004,"squid":"spider-05","role":"Spec Spider","at":1791342798020,"hash":"297a5598adee564a528fadf0abd3285c8b103da0"}
{"url":"https://eips.ethereum.org/EIPS/eip-1328","domain":"eips.ethereum.org","title":"ERC-1328: WalletConnect URI Format","text":"🎉 Final\n\n Standards Track: ERC\n\n ERC-1328: WalletConnect URI Format\n\n Define URI format for initiating connections between applications and wallets\n\n Authors\n ligi (@ligi), Pedro Gomes (@pedrouid)\n\n Created\n 2018-08-15\n\n Abstract\n\nThis standard defines how the data to connect some application and a wallet can be encoded with a URI. This URI can then be shown either as a QR code or as a link.\n\n Specification\n\n Syntax\n\nWalletConnect request URI with the following parameters:\n\nrequest = \"wc\" \":\" topic [ \"@\" version ][ \"?\" parameters ]\ntopic = STRING\nversion = 1*DIGIT\nparameters = parameter *( \"&\" parameter )\nparameter = key \"=\" value\nkey = STRING\nvalue = STRING\n\n Semantics\n\nRequired parameters are dependent on the WalletConnect protocol version:\n\nFor WalletConnect v1.0 protocol (version=1) the parameters are:\n\n key - symmetric key used for encryption\n bridge - url of the bridge server for relaying messages\n\nFor WalletConnect v2.0 protocol (version=2) the parameters are:\n\n symKey - symmetric key used for encrypting messages over relay\n methods - jsonrpc methods supported for pairing topic\n relay-protocol - transport protocol for relaying messages\n relay-data - (optional) transport data for relaying messages\n expiryTimestamp - (optional) unix epoch in seconds when pairing expires\n\n Example\n\n# 1.0\nwc:8a5e5bdc-a0e4-4702-ba63-8f1a5655744f@1?bridge=https%3A%2F%2Fbridge.walletconnect.org&key=41791102999c339c844880b23950704cc43aa840f3739e365323cda4dfa89e7a\n\n# 2.0\nwc:7f6e504bfad60b485450578e05678ed3e8e8c4751d3c6160be17160d63ec90f9@2?relay-protocol=irn&symKey=587d5484ce2a2a6ee3ba1962fdd7e8588e06200c46823bd18fbd67def96ad303&methods=[wc_sessionPropose],[wc_authRequest,wc_authBatchRequest]\"&expiryTimestamp=1705934757\n\n Rationale\n\nThis proposal moves away from the JSON format used in the alpha version of the WalletConnect protocol because it suffered from very inefficient parsing of the intent of the QR code, thereby making it easier to create better QR code parsers APIs for wallets to implement. Also by using a URI instead of JSON inside the QR-Code the Android Intent system can be leveraged.\n\n Backwards Compatibility\n\nVersioning is required as part of the syntax for this URI specification to allow the WalletConnect protocol to evolve and allow backwards-compatibility whenever a new version is introduced.\n\n Security Considerations\n\nURIs should be shared between user devices or applications and no sensitive data is shared within the URI that could compromise the communication or would allow control of the user’s private keys.\n\n Copyright\n\nCopyright and related rights waived via CC0.\n\n Citation\n Please cite this document as:\n\n ligi (@ligi), Pedro Gomes (@pedrouid), \"ERC-1328: WalletConnect URI Format,\" Ethereum Improvement Proposals, no. 1328, August 2018. Available: https://eips.ethereum.org/EIPS/eip-1328.","tokens":710,"squid":"spider-05","role":"Spec Spider","at":1791342810788,"hash":"39e074e8048f978e932262e073060953cb85d752"}
{"url":"https://jup.ag/deposit/bridge","domain":"jup.ag","title":"Swap & Bridge Cross-Chain across multiple routes | Jupiter","text":"Sell≈ $2,614.23Buy22.1106≈ $2,614.80RouteEstimateGUM Universal BridgeBest +1.19%22.1106 SOLdeBridge21.8517 SOLMore ways to depositBuy with a cardPay with Apple Pay, Google Pay, or other supported methodsSend from an exchangeConnect to Binance, Coinbase or Uphold and bridge onchainFrequently asked questionsConnect your wallet, choose the tokens you want to send and receive, enter an amount, then review the available routes and continue with your preferred option.Bridge & Swap supports routes across Solana, Ethereum, Base, Arbitrum, Sui, BNB Chain, Robinhood, Optimism, Polygon, Avalanche, and Linea. Available tokens depend on the selected route.Available routes can include GUM Universal Bridge and deBridge. A direct deposit option may also appear when it supports the selected assets.Available routes are ranked by their estimated delivered amount. You can review the alternatives and choose another available route before continuing.New to Solana?Get Jupiter Wallet extension","tokens":246,"squid":"spider-02","role":"Liquidity Spider","at":1791342817653,"hash":"fc7d178f9e749750961637c6748c8bf81c9e083e"}
{"url":"https://eips.ethereum.org/EIPS/eip-1344","domain":"eips.ethereum.org","title":"EIP-1344: ChainID opcode","text":"🎉 Final\n\n Standards Track: Core\n\n EIP-1344: ChainID opcode\n\n Authors\n Richard Meissner (@rmeissner), Bryant Eisenbach (@fubuloubu)\n\n Created\n 2018-08-22\n\n Requires\n\n EIP-155\n\n Abstract\n\nThis EIP adds an opcode that returns the current chain’s EIP-155 unique identifier.\n\n Motivation\n\nEIP-155 proposes to use the chain ID to prevent replay attacks between different chains. It would be a great benefit to have the same possibility inside smart contracts when handling signatures, especially for Layer 2 signature schemes using EIP-712.\n\n Specification\n\nAdds a new opcode CHAINID at 0x46, which uses 0 stack arguments. It pushes the current chain ID onto the stack. Chain ID is a 256-bit value. The operation costs G_base to execute.\n\nThe value of the current chain ID is obtained from the chain ID configuration, which should match the EIP-155 unique identifier a client will accept from incoming transactions. Please note that per EIP-155, it is not required that a transaction have an EIP-155 unique identifier, but in that scenario this opcode will still return the configured chain ID and not a default.\n\n Rationale\n\nThe current approach proposed by EIP-712 is to specify the chain ID at compile time. Using this approach will result in problems after a hardfork, as well as human error that may lead to loss of funds or replay attacks on signed messages.\nBy adding the proposed opcode it will be possible to access the current chain ID and validate signatures based on that.\n\nCurrently, there is no specification for how chain ID is set for a particular network, relying on choices made manually by the client implementers and the chain community. There is a potential scenario where, during a “contentious split” over a divisive issue, a community using a particular value of chain ID will make a decision to split into two such chains. When this scenario occurs, it will be unsafe to maintain chain ID to the same value on both chains, as chain ID is used for replay protection for in-protocol transactions (per EIP-155), as well as for L2 and “meta-transaction” use cases (per EIP-712 as enabled by this proposal). There are two potential resolutions in this scenario under the current process: 1) one chain decides to modify their value of chain ID (while the other keeps it), or 2) both chains decide to modify their value of chain ID.\n\nIn order to mitigate this situation, users of the proposed CHAINID opcode must ensure that their application can handle a potential update to the value of chain ID during their usage of their application in case this does occur, if required for the continued use of the application. A Trustless Oracle that logs the timestamp when a change is made to chain ID can be implemented either as an application-level feature inside the application contract system, or referenced as a globally standard contract. Failure to provide a mitigation for this scenario could lead to a sudden loss of legitimacy of previously signed off-chain messages, which could be an issue during settlement periods and other longer-term verification events for these types of messages. Not all applications of this opcode may need mitigations to handle this scenario, but developers should provide reasoning on a case-by-case basis.\n\nOne example of a scenario where it would not make sense to leverage a global oracle is with the Plasma L2 paradigm. In the Plasma paradigm, an operator or group of operators submit blocks from the L2 network to the base chain (in this case Ethereum) summarizing transactions that have occurred on that chain. The submission of these blocks may not perfectly align with major events on the mainchain, such as a split causing an update of chain ID, which may cause a significant insecurity in the protocol if chain ID is utilized in signing messages. If the operators are not allowed to control the update of chain ID they will not be able to perfectly synchronize the update with their block submissions, and certain past transactions may be rejected because they do not align with the update. This is one example of the unintended consequences of trying to specify too much of the behavior of chain ID during a contentious split, and why having a simple opcode for access is most optimal, versus a more complicated precompile or contract.\n\nThis proposed opcode would be the simplest possible way to implement this functionality, and allows developers the flexibility to implement their own global or local handling of chain ID changes, if required.\n\n Backwards Compatibility\n\nThis EIP is fully backwards compatible with all chains which implement EIP-155 chain ID domain separator for transaction signing.\n\n References\n\nThis was previously suggested as part of EIP-901.\n\n Test Cases\n\nTest Cases added to ethereum/tests\n\n Implementation\n\nA reference implementation for the Trinity Python client is here.\n\nAn example implementation of a trustless chain ID oracle was implemented here.\n\n Copyright\n\nCopyright and related rights waived via CC0.\n\n Citation\n Please cite this document as:\n\n Richard Meissner (@rmeissner), Bryant Eisenbach (@fubuloubu), \"EIP-1344: ChainID opcode,\" Ethereum Improvement Proposals, no. 1344, August 2018. Available: https://eips.ethereum.org/EIPS/eip-1344.","tokens":1309,"squid":"spider-05","role":"Spec Spider","at":1791342822036,"hash":"710259350642e4d270d1c2c198855645593db8ec"}
{"url":"https://eips.ethereum.org/EIPS/eip-1363","domain":"eips.ethereum.org","title":"ERC-1363: Payable Token","text":"🎉 Final\n\n Standards Track: ERC\n\n ERC-1363: Payable Token\n\n Authors\n Vittorio Minacori (@vittominacori)\n\n Created\n 2018-08-30\n\n Requires\n\n EIP-20, \n\n EIP-165\n\n Simple Summary\n\nDefines a token interface for ERC-20 tokens that supports executing recipient code after transfer or transferFrom, or spender code after approve.\n\n Abstract\n\nStandard functions a token contract and contracts working with tokens can implement to make a token Payable.\n\ntransferAndCall and transferFromAndCall will call an onTransferReceived on a ERC1363Receiver contract.\n\napproveAndCall will call an onApprovalReceived on a ERC1363Spender contract.\n\n Motivation\n\nThere is no way to execute code after a ERC-20 transfer or approval (i.e. making a payment), so to make an action it is required to send another transaction and pay GAS twice.\n\nThis proposal wants to make token payments easier and working without the use of any other listener. It allows to make a callback after a transfer or approval in a single transaction.\n\nThere are many proposed uses of Ethereum smart contracts that can accept ERC-20 payments.\n\nExamples could be\n\n to create a token payable crowdsale\n selling services for tokens\n paying invoices\n making subscriptions\n\nFor these reasons it was named as “Payable Token”.\n\nAnyway you can use it for specific utilities or for any other purposes who require the execution of a callback after a transfer or approval received.\n\nThis proposal has been inspired by the ERC-721 onERC721Received and ERC721TokenReceiver behaviours.\n\n Specification\n\nImplementing contracts MUST implement the ERC-1363 interface as well as the ERC-20 and ERC-165 interfaces.\n\npragma solidity ^0.8.0;\n\ninterface ERC1363 /* is ERC20, ERC165 */ {\n /*\n * Note: the ERC-165 identifier for this interface is 0xb0202a11.\n * 0xb0202a11 ===\n * bytes4(keccak256('transferAndCall(address,uint256)')) ^\n * bytes4(keccak256('transferAndCall(address,uint256,bytes)')) ^\n * bytes4(keccak256('transferFromAndCall(address,address,uint256)')) ^\n * bytes4(keccak256('transferFromAndCall(address,address,uint256,bytes)')) ^\n * bytes4(keccak256('approveAndCall(address,uint256)')) ^\n * bytes4(keccak256('approveAndCall(address,uint256,bytes)'))\n */\n\n /**\n * @notice Transfer tokens from `msg.sender` to another address and then call `onTransferReceived` on receiver\n * @param to address The address which you want to transfer to\n * @param value uint256 The amount of tokens to be transferred\n * @return true unless throwing\n */\n function transferAndCall(address to, uint256 value) external returns (bool);\n\n /**\n * @notice Transfer tokens from `msg.sender` to another address and then call `onTransferReceived` on receiver\n * @param to address The address which you want to transfer to\n * @param value uint256 The amount of tokens to be transferred\n * @param data bytes Additional data with no specified format, sent in call to `to`\n * @return true unless throwing\n */\n function transferAndCall(address to, uint256 value, bytes memory data) external returns (bool);\n\n /**\n * @notice Transfer tokens from one address to another and then call `onTransferReceived` on receiver\n * @param from address The address which you want to send tokens from\n * @param to address The address which you want to transfer to\n * @param value uint256 The amount of tokens to be transferred\n * @return true unless throwing\n */\n function transferFromAndCall(address from, address to, uint256 value) external returns (bool);\n\n /**\n * @notice Transfer tokens from one address to another and then call `onTransferReceived` on receiver\n * @param from address The address which you want to send tokens from\n * @param to address The address which you want to transfer to\n * @param value uint256 The amount of tokens to be transferred\n * @param data bytes Additional data with no specified format, sent in call to `to`\n * @return true unless throwing\n */\n function transferFromAndCall(address from, address to, uint256 value, bytes memory data) external returns (bool);\n\n /**\n * @notice Approve the passed address to spend the specified amount of tokens on behalf of msg.sender\n * and then call `onApprovalReceived` on spender.\n * @param spender address The address which will spend the funds\n * @param value uint256 The amount of tokens to be spent\n * @return true unless throwing\n */\n function approveAndCall(address spender, uint256 value) external returns (bool);\n\n /**\n * @notice Approve the passed address to spend the specified amount of tokens on behalf of msg.sender\n * and then call `onApprovalReceived` on spender.\n * @param spender address The address which will spend the funds\n * @param value uint256 The amount of tokens to be spent\n * @param data bytes Additional data with no specified format, sent in call to `spender`\n * @return true unless throwing\n */\n function approveAndCall(address spender, uint256 value, bytes memory data) external returns (bool);\n}\n\ninterface ERC20 {\n function totalSupply() external view returns (uint256);\n function balanceOf(address account) external view returns (uint256);\n function transfer(address recipient, uint256 amount) external returns (bool);\n function transferFrom(address sender, address recipient, uint256 amount) external returns (bool);\n function allowance(address owner, address spender) external view returns (uint256);\n function approve(address spender, uint256 amount) external returns (bool);\n event Transfer(address indexed from, address indexed to, uint256 value);\n event Approval(address indexed owner, address indexed spender, uint256 value);\n}\n\ninterface ERC165 {\n function supportsInterface(bytes4 interfaceId) external view returns (bool);\n}\n\nA contract that wants to accept token payments via transferAndCall or transferFromAndCall MUST implement the following interface:\n\n/**\n * @title ERC1363Receiver interface\n * @dev Interface for any contract that wants to support `transferAndCall` or `transferFromAndCall`\n * from ERC1363 token contracts.\n */\ninterface ERC1363Receiver {\n /*\n * Note: the ERC-165 identifier for this interface is 0x88a7ca5c.\n * 0x88a7ca5c === bytes4(keccak256(\"onTransferReceived(address,address,uint256,bytes)\"))\n */\n\n /**\n * @notice Handle the receipt of ERC1363 tokens\n * @dev Any ERC1363 smart contract calls this function on the recipient\n * after a `transfer` or a `transferFrom`. 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 token contract address is always the message sender.\n * @param operator address The address which called `transferAndCall` or `transferFromAndCall` function\n * @param from address The address which are token transferred from\n * @param value uint256 The amount of tokens transferred\n * @param data bytes Additional data with no specified format\n * @return `bytes4(keccak256(\"onTransferReceived(address,address,uint256,bytes)\"))`\n * unless throwing\n */\n function onTransferReceived(address operator, address from, uint256 value, bytes memory data) external returns (bytes4);\n}\n\nA contract that wants to accept token payments via approveAndCall MUST implement the following interface:\n\n/**\n * @title ERC1363Spender interface\n * @dev Interface for any contract that wants to support `approveAndCall`\n * from ERC1363 token contracts.\n */\ninterface ERC1363Spender {\n /*\n * Note: the ERC-165 identifier for this interface is 0x7b04a2d0.\n * 0x7b04a2d0 === bytes4(keccak256(\"onApprovalReceived(address,uint256,bytes)\"))\n */\n\n /**\n * @notice Handle the approval of ERC1363 tokens\n * @dev Any ERC1363 smart contract calls this function on the recipient\n * after an `approve`. This function MAY throw to revert and reject the\n * approval. Return of other than the magic value MUST result in the\n * transaction being reverted.\n * Note: the token contract address is always the message sender.\n * @param owner address The address which called `approveAndCall` function\n * @param value uint256 The amount of tokens to be spent\n * @param data bytes Additional data with no specified format\n * @return `bytes4(keccak256(\"onApprovalReceived(address,uint256,bytes)\"))`\n * unless throwing\n */\n function onApprovalReceived(address owner, uint256 value, bytes memory data) external returns (bytes4);\n}\n\n Rationale\n\nThe choice to use transferAndCall, transferFromAndCall and approveAndCall derives from the ERC-20 naming. They want to highlight that they have the same behaviours of transfer, transferFrom and approve with the addition of a callback on receiver or spender.\n\n Backwards Compatibility\n\nThis proposal has been inspired also by ERC-223 and ERC-677 but it uses the ERC-721 approach, so it doesn’t override the ERC-20 transfer and transferFrom methods and defines the interfaces IDs to be implemented maintaining the ERC-20 backwards compatibility.\n\n Security Considerations\n\nThe approveAndCall and transferFromAndCall methods can be affected by the same issue of the standard ERC-20 approve and transferFrom method.\n\nChanging an allowance with the approveAndCall methods brings the risk that someone may use both the old and the new allowance by unfortunate transaction ordering.\n\nOne possible solution to mitigate this race condition is to first reduce the spender’s allowance to 0 and set the desired value afterwards (EIP-20#issuecomment-263524729).\n\n Copyright\n\nCopyright and related rights waived via CC0.\n\n Citation\n Please cite this document as:\n\n Vittorio Minacori (@vittominacori), \"ERC-1363: Payable Token,\" Ethereum Improvement Proposals, no. 1363, August 2018. Available: https://eips.ethereum.org/EIPS/eip-1363.","tokens":2395,"squid":"spider-05","role":"Spec Spider","at":1791342835784,"hash":"ef18ebbc7ad52cb6384fc7df9604bc1d12bc5614"}
{"url":"https://jup.ag/wallet?utm_source=jup.ag&utm_medium=deposit&utm_campaign=wallet-extension__footer","domain":"jup.ag","title":"Jupiter Wallet: The Best Solana Wallet to Trade, Earn & Manage","text":"Jupiter Wallet · Browser ExtensionThe wallet Solana runs on.Cheaper. Simpler. Safer.The official browser wallet from Jupiter. Trade cheaper, earn automatically, and manage your entire Solana life from your sidepanel.Add the extension to your browserChromeBraveEdgeNon-custodial. Your keys never leave your device.34×Better sandwich protectionwith native Ultra routingUp to42×Lower trading feeswith no additional platform fees0 SOLGasless swaps & sendsGas comes from the token you move — hold no SOL1Wallet across devicesSync mobile ↔ extension, on the goJupiter Wallet V2V1 stored your Solana. V2 runs it.V2 removes the largest pain points that users face: cost, friction, and fear. It's the easiest way for anyone to use Solana.CheaperGet more from your swaps, every time.The best price, without the markupEvery swap routes through Jupiter Ultra for the best price and lowest slippage — the same engine other wallets call, without the middleman.Trade without holding SOLNever get stuck in your wallet again. Gas is taken from any token you're already using.0% platform feeOther wallets tack on up to 85 bps plus the routing fee, for no added benefit. We just charge you for the routing.More ways to earn, in-walletToggle on Auto-Earn to generate yield from your stables, or close empty token accounts to reclaim Solana.SimplerBuilt for how you actually trade.Link your wallets across devicesScan once and your Jupiter Mobile becomes your extension, and back again. No re-keying, no new seed phrase.Auto-approve & auto-confirmEnable once for a frictionless trading experience across Jupiter and Meteora, with per-transaction limits you control.Ticker Widget everywhereBuy straight from X, Google, Yahoo Finance, ChatGPT, Claude and Gemini. The internet becomes your trading terminal.Full DeFi portfolio in-walletTrack every dollar across Solana protocols in one place, with a built-in Airdrop Checker that tells you when you’re eligible.SaferActive defense, not passive storage.Supports every major hardware walletUse the cold storage you already trust: Ledger, Keystone, or Trezor.Domain & transaction validationThe wallet reads what you're about to sign and warns you before a drainer does damage.Externally auditedContinuously audited and tested by Offside Labs.Frequently asked questionsEverything you need to know about installing, funding and using Jupiter Wallet.Install the Jupiter Wallet extension from the Chrome Web Store, then select Create new wallet and complete the setup.To add funds, select Receive to transfer Solana tokens to your address, or Buy to open Jupiter's funding options in a new tab. For more details follow the getting-started guide.Yes. Open the wallet list, then Add New Wallet → Import Existing Wallet. You can import a 12- or 24-word seed phrase or a private key. You can also add a Watch Address to track any wallet without access to its keys.Your assets stay at the same Solana address. Importing gives Jupiter Wallet access to that account; it does not move your funds onchain. For more details and troubleshooting, check out the import guide.Jupiter Wallet charges no additional fees, unlike other wallets that add up to 0.85% (85 bps) on top of the underlying routing fees. Not only is Jupiter Wallet the cheapest, it is also the quickest to use, built by the team behind Jupiter Exchange.You can swap and send tokens on Solana gaslessly, make limit orders or recurring orders, earn yield via Auto-Earn on idle tokens, view your DeFi positions, bridge from other chains and more — all in one place. Easily import from Jupiter Mobile with the scan of a QR code via Jupiter Sync, while Jupiter ID lets you sign in with email or social login instead of a seed phrase. See moving from another wallet for the full walkthrough.Jupiter ID is Jupiter's email or social sign-in, shared across Jupiter Wallet, the web app and Jupiter Mobile. It creates a wallet you reach by signing in, rather than by holding a seed phrase.You can have one active Jupiter ID account at a time. Jupiter ID wallets cannot be exported through Jupiter Sync, and are not eligible for Auto-Earn.Solana transactions require SOL to pay network costs. For eligible swaps and token sends, Jupiter Wallet covers those costs for you and deducts the equivalent from the token you receive. It activates only when needed, rather than on every transaction.Some actions are never gasless and need SOL in your wallet: NFT transfers, limit orders and recurring orders. The wallet shows a low-balance warning when your SOL is running short.When enabled, Auto-Earn checks your balances hourly and deposits the full balance of each token you've selected into Jupiter Lend's Earning Vaults once it exceeds the threshold you set (minimum 10 tokens). Eligible tokens are those with a Jupiter Lend Earn market. Yield comes from interest paid by borrowers and changes with market conditions.Auto-Earn is available for wallets created or imported via seed phrase or private key. It is not available for Jupiter ID, hardware or watch-only wallets. Turning it off stops future deposits; existing deposits stay in Lend until you withdraw. See the Auto-Earn guide.Yes. The wallet home has four tabs — Tokens, DeFi, NFTs and Activity — covering your balances, supported DeFi positions (lending, liquidity and staking), your NFTs and your transaction history.You can view and send supported NFTs from the NFTs tab; NFT transfers are not gasless and need a small amount of SOL. The DeFi tab helps you locate positions that don't appear as spendable tokens. See portfolio and holdings.Auto-Approve lets you trade on trusted first-party sites without approving every transaction. It covers Jupiter, Meteora and Orb, each toggled separately under Settings → Preferences → Auto Approve. Jupiter is enabled by default; Meteora and Orb are off until you turn them on.You can set an optional per-transaction spending limit in USD — anything above it still asks for approval. Auto-Approve makes repeated trading faster but removes the chance to review each transaction before it is signed, so review the limit and the enabled sites if you'd rather approve manually. Hardware wallets always prompt for approval, even with Auto-Approve on.Yes — Ledger, Keystone and Trezor. Open the wallet list, then Add New Wallet → Import Existing Wallet → Hardware Wallet.Hardware wallets keep their signing keys on the device, and every transaction is authorized through the device's own approval process. Hardware wallet support requires a Chromium-based browser (Chrome, Edge, Brave) — it is not available in Firefox yet.Jupiter Wallet is a self-custodial browser extension for holding assets, approving transactions and connecting to Solana apps. The Jupiter website, jup.ag, is the home for onchain finance, with Spot, Lend, Perps, Predict and more.You can use Jupiter Wallet to connect to those products directly, while swaps, limit and recurring orders, portfolio tracking and other features are also available natively inside the extension.Jupiter Wallet is the browser extension; Jupiter Mobile is the iOS and Android app. Both let you trade and manage your assets — the extension is built for your computer, Mobile for your phone.Each works independently, but Jupiter Sync lets you move a wallet between them without re-entering your recovery phrase. In the extension, open the three-dot menu and select Jupiter Sync. In Jupiter Mobile, open Settings → Jupiter Sync and scan the QR code shown by the extension.Jupiter Sync covers seed phrase and private key wallets. Jupiter ID and hardware wallets cannot be synced — sign in to Jupiter ID directly on each device, and pair hardware wallets per device. See the Jupiter Sync guide for more.Jupiter Wallet supports all Solana tokens and NFTs.You can also receive supported assets from Ethereum, Base, Arbitrum and Sui via Universal Deposit. Each network has its own accepted token, minimum deposit and fee, all shown on the Receive screen before you send. Cross-chain deposits arrive on Solana and do not create native ETH or SUI balances inside the wallet. See sending and receiving for more.The wallet Solana runs on.Cheaper. Simpler. Safer. Add Jupiter Wallet to your browser in two clicks.Add the extension to your browserChromeBraveEdge","tokens":2064,"squid":"spider-02","role":"Liquidity Spider","at":1791342845188,"hash":"ba6196bba12da205a496d68deb31a4cef6eb8dee"}
{"url":"https://eips.ethereum.org/EIPS/eip-1450","domain":"eips.ethereum.org","title":"ERC-1450: RTA-Controlled Security Token","text":"🎉 Final\n\n Standards Track: ERC\n\n ERC-1450: RTA-Controlled Security Token\n\n Security tokens where the Registered Transfer Agent has exclusive control over transfers for regulatory compliance\n\n Authors\n Howard Marks (@howardmarks) <howard@startengine.com>, Devender Gollapally (@devender-startengine) <devender@startengine.com>, Joe Mathews (@se-joe) <joe@startengine.com>, Jordan Jahja (@jordan-jahja) <jordan.jahja@startengine.com>, John Shiple (@johnshiple), David Zhang (@david-colab) <david@startengine.com>\n\n Created\n 2018-09-25\n\n Requires\n\n EIP-20, \n\n EIP-165, \n\n EIP-6093\n\n Abstract\n\nERC-1450 facilitates the recording of ownership and transfer of securities sold in compliance with Securities Act Regulations CF, D, and A. This standard is informed by practical operational experience from SEC-registered transfer agents, broker-dealers, and alternative trading systems that have collectively managed billions in compliant securities offerings. The design addresses the full lifecycle of digital securities from issuance through secondary trading.\n\nThe standard introduces a unique RTA-controlled model where the Registered Transfer Agent maintains exclusive authority over all token operations. Unlike permissionless tokens, ERC-1450 enforces strict compliance by requiring the RTA to execute all mints, burns, and transfers, while disabling direct value movement via transfer() and approve(). Holder-initiated transfer requests are permitted via requestTransferWithFee(), but no value moves unless the RTA authorizes and executes the transfer. The standard also enables compliant secondary markets through a broker registration system, where vetted brokers can request transfers with fees on behalf of holders. This design ensures regulatory compliance with SEC requirements and state blue sky laws while providing liquidity options and maintaining read-only compatibility with existing ERC-20 infrastructure.\n\nKey features include RTA-exclusive control, restricted ERC-20 interface for ecosystem integration, and built-in mechanisms for regulatory compliance including recovery procedures for lost tokens and support for court-ordered transfers. The standard MAY optionally implement EIP-3668 (CCIP-Read) for off-chain compliance pre-checks, improving user experience by allowing wallets to validate transfers before gas payment.\n\n Motivation\n\nWith the advent of the JOBS Act in 2012 and subsequent regulations (Regulation Crowdfunding in 2016, amended Reg A and Reg D), there has been significant expansion in exemptions for securities offerings. The regulated securities market has grown substantially, with billions in offerings across thousands of companies.\n\nExperience from operating SEC-registered transfer agents has revealed critical gaps in existing token standards for securities. While standards like ERC-3643 provide on-chain compliance mechanisms, they don’t address the unique regulatory requirements of U.S. securities law, particularly the role of Registered Transfer Agents.\n\nCurrent challenges that ERC-1450 addresses:\n\n Transfer Controller Authority: SEC regulations require Registered Transfer Agents to maintain exclusive control over securities transfers, similar to designated controller requirements in other jurisdictions\n Recovery Mechanisms: Legal requirements for recovering lost or stolen securities\n Court Orders: Ability to execute court-ordered transfers (divorce, estate, fraud recovery)\n Regulatory Reporting: Clear audit trails for regulatory examinations\n Cost Efficiency: Leveraging existing transfer agent infrastructure for compliance\n\nERC-20 tokens do not support the regulated roles of Funding Portal, Broker Dealer, RTA, and Investor and do not support the Bank Secrecy Act/USA Patriot Act KYC and AML requirements. Other improvements (notably Simple Restricted Token Standards) have tried to tackle KYC and AML regulatory requirements. This approach assigns exclusive control over transferFrom, mint, and burnFrom to a designated transfer agent who performs KYC and AML compliance.\n\nThis standard codifies operational requirements into a technical specification that bridges traditional securities regulation with blockchain technology.\n\n Specification\n\nERC-1450 extends ERC-20.\n\n Optional Dependencies\n\nThe following standards MAY be implemented for enhanced functionality but are NOT required for compliance:\n\n EIP-3668 (CCIP-Read): MAY be used for off-chain compliance pre-checks. Implementations choosing to support this MUST implement the preCheckCompliance and preCheckComplianceCallback functions as specified.\n ERC-1820 (Registry): MAY be used for interface registration. Implementations can optionally register their interfaces in the ERC-1820 registry for improved discoverability.\n\nIn addition to the optional standards above, the following interface components defined in this specification are OPTIONAL extensions. Implementations MAY omit them; implementations that provide them MUST follow the behavior specified for them (including emitting the specified events):\n\n Document management (setDocument, getDocument, removeDocument, getAllDocuments)\n Structured recovery workflow (initiateRecovery, cancelRecovery, executeRecovery, getRecoveryDetails, hasPendingRecovery) — the REQUIRED baseline for lost-wallet recovery and court-ordered transfers is controllerTransfer, which all implementations MUST provide\n KYC status view (isKYCVerified)\n Gasless fee approval (requestTransferWithPermit)\n Off-chain compliance pre-checks (preCheckCompliance, preCheckComplianceCallback)\n Transfer request status view (getRequestStatus) — implementations MAY instead expose equivalent request data through other read methods (e.g., a public storage mapping)\n\n ERC-1450\n\nERC-1450 is an interface standard that defines a security token where only the Registered Transfer Agent (RTA) has authority to execute transfers, mints, and burns. The token represents securities issued by an owner (the issuer) and managed exclusively by an RTA.\n\nThe standard enforces strict role separation:\n\n Owner/Issuer: The entity that creates and owns the security\n RTA: The only entity authorized to transfer, mint, or burn tokens\n Token Holders: Cannot initiate transfers directly (unlike standard ERC-20)\n\nERC-1450 explicitly disables direct value movement by requiring the transfer and approve functions to always revert. Only the RTA can execute token movements via transferFrom, mint, and burnFrom functions. Holder-initiated transfer requests are permitted via requestTransferWithFee(), but no value moves unless the RTA authorizes and executes the transfer. Registered brokers can also request transfers on behalf of holders through the same mechanism. This design ensures regulatory compliance by centralizing all token operations through the regulated RTA.\n\nCritical security feature: The changeIssuer function can only be called by the RTA, not the owner. This protects against compromised issuer keys - even if an issuer’s private key is stolen, the attacker cannot change the RTA or steal tokens.\n\n Issuers and RTAs\n\nImplementations must initialize the following parameters upon deployment:\n\n owner: The issuer’s address\n transferAgent: The RTA’s address (preferably an RTAProxy contract)\n name: The security’s name\n symbol: The security’s trading symbol\n decimals: The number of decimal places (0 for indivisible shares, up to 18 for fractional)\n\n Access Control Model\n\nThe interface defines three levels of access control:\n\nRTA-Only Functions:\n\n changeIssuer: Change the token issuer/owner (only callable by RTA, not by issuer)\n transferFrom: Transfer tokens between accounts\n mint: Create new tokens\n burnFrom: Destroy existing tokens\n All batch operations and fee collection functions\n\nOwner-Only Functions:\n\n setTransferAgent: One-time setup to RTAProxy (locked after initial setup)\n\nPublic Functions:\n\n isTransferAgent: Check if an address is the current RTA\n Standard ERC-20 view functions (balanceOf, totalSupply, etc.)\n\n Security and Compliance\n\nThe RTA maintains exclusive control over all token movements, ensuring:\n\n Complete audit trail for regulatory reporting\n Enforcement of transfer restrictions\n Recovery mechanisms for lost tokens\n Execution of court orders\n Prevention of unauthorized transfers\n\n ERC-20 Extension\n\nERC-20 tokens provide the following functionality:\n\n// SPDX-License-Identifier: MIT\npragma solidity ^0.8.20;\n\ninterface IERC20 {\n function totalSupply() external view returns (uint256);\n function balanceOf(address account) external view returns (uint256);\n function transfer(address to, uint256 amount) external returns (bool);\n function allowance(address owner, address spender) external view returns (uint256);\n function transferFrom(address from, address to, uint256 amount) external returns (bool);\n function approve(address spender, uint256 amount) external returns (bool);\n\n event Transfer(address indexed from, address indexed to, uint256 value);\n event Approval(address indexed owner, address indexed spender, uint256 value);\n}\n\nERC-165 interface for standard interface detection:\n\n// SPDX-License-Identifier: MIT\npragma solidity ^0.8.20;\n\ninterface IERC165 {\n /**\n * @notice Query if a contract implements an interface\n * @param interfaceId The interface identifier, as specified in [ERC-165](/EIPS/eip-165)\n * @return bool True if the contract implements `interfaceId`\n */\n function supportsInterface(bytes4 interfaceId) external view returns (bool);\n}\n\nERC-20 is extended as follows:\n\n// SPDX-License-Identifier: MIT\npragma solidity ^0.8.20;\n\n/**\n * @title ERC-1450: RTA-Controlled Security Token (Restricted ERC-20 Interface)\n * @notice Facilitates compliance with Securities Act Regulations CF, D, and A\n * @dev This standard extends ERC-20 with RTA-controlled transfer restrictions\n *\n * Key Features:\n * - RTA (Registered Transfer Agent) exclusive control over transfers\n * - Direct value movement disabled (transfer, approve functions always revert)\n * - Holder-initiated transfer requests permitted via requestTransferWithFee (requires RTA execution)\n * - Built-in recovery mechanisms for lost tokens\n * - Support for court-ordered transfers\n * - Restricted ERC-20 interface for read operations and ecosystem integration\n * - ERC-6093 compliant error messages for tooling interoperability\n */\ninterface IERC1450 is IERC20, IERC165 {\n // ============ ERC-6093 Standard Errors ============\n // Using standard errors from ERC-6093 for consistent tooling support\n\n // Standard ERC-20 errors (from ERC-6093)\n error ERC20InsufficientBalance(address sender, uint256 balance, uint256 needed);\n error ERC20InvalidSender(address sender);\n error ERC20InvalidReceiver(address receiver);\n error ERC20InvalidApprover(address approver);\n error ERC20InvalidSpender(address spender);\n error ERC20InsufficientAllowance(address spender, uint256 allowance, uint256 needed);\n\n // Standard Access Control errors (from ERC-6093)\n // NOTE: We retain OpenZeppelin error names for tooling compatibility, but semantics differ:\n // - \"Owner\" in ERC-1450 means \"Issuer\" (the entity that created the token)\n // - Unlike OpenZeppelin's Ownable, only the RTA can change the issuer, not the issuer themselves\n error OwnableUnauthorizedAccount(address account); // Non-issuer attempts issuer-only operation\n error OwnableInvalidOwner(address owner); // Invalid issuer address (e.g., zero address)\n\n // ============ ERC-1450 Specific Errors ============\n // Custom errors only when ERC-6093 standard errors are insufficient\n\n error ERC1450TransferDisabled(); // For disabled transfer/approve functions\n error ERC1450OnlyRTA(); // Operation restricted to RTA only\n error ERC1450TransferAgentLocked(); // RTA proxy is locked from changes\n error ERC1450ComplianceCheckFailed(address from, address to); // KYC/AML failure\n\n // Events\n event IssuerChanged(address indexed previousIssuer, address indexed newIssuer);\n event TransferAgentUpdated(address indexed previousAgent, address indexed newAgent);\n\n /**\n * @notice Emitted when tokens are minted with regulation tracking\n * @param to Recipient of the minted tokens\n * @param amount Number of tokens minted\n * @param regulationType Regulation under which tokens were issued\n * @param issuanceDate Original share issuance date\n * @param tokenizationDate When tokenized on blockchain (block.timestamp)\n * @dev MUST be emitted for every mint operation\n * Allows reconstruction of entire cap table from events\n * Critical for regulatory reporting and audit trails\n */\n event TokensMinted(\n address indexed to,\n uint256 amount,\n uint16 indexed regulationType,\n uint256 issuanceDate,\n uint256 tokenizationDate\n );\n\n /**\n * @notice Emitted when tokens are burned with regulation tracking\n * @param from Address from which tokens were burned\n * @param amount Number of tokens burned\n * @param regulationType Regulation type of burned tokens\n * @param issuanceDate Original issuance date of burned tokens\n * @dev MUST be emitted for every burn operation\n * Critical for maintaining accurate cap table and regulatory reporting\n */\n event TokensBurned(\n address indexed from,\n uint256 amount,\n uint16 indexed regulationType,\n uint256 issuanceDate\n );\n\n /**\n * @notice Emitted when tokens are transferred with specific regulation tracking\n * @param from Source address\n * @param to Destination address\n * @param amount Number of tokens transferred\n * @param regulationType Regulation type of the transferred tokens\n * @param issuanceDate Original issuance date of the transferred tokens\n * @dev Provides complete traceability of regulated token movements\n * Essential for compliance reporting and audit trails\n */\n event RegulatedTransfer(\n address indexed from,\n address indexed to,\n uint256 amount,\n uint16 indexed regulationType,\n uint256 issuanceDate\n );\n\n // Core RTA Functions\n\n /**\n * @notice Change the issuer (owner) of the token contract\n * @param newIssuer Address of the new issuer\n * @dev Only callable by the RTA. Must be restricted with onlyTransferAgent modifier.\n * Emits IssuerChanged event (not OwnershipTransferred)\n *\n * IMPORTANT: This differs from OpenZeppelin's Ownable pattern:\n * - In Ownable: owner can transfer ownership themselves\n * - In ERC-1450: ONLY the RTA can change the issuer\n * - Terminology: \"Issuer\" = the token creator/owner, not the controller\n * - This prevents compromised issuer keys from hijacking the token\n *\n * The issuer maintains rights to:\n * - Receive proceeds from offerings\n * - Update corporate documents (via ERC-1643)\n * - Make business decisions\n * But CANNOT control token transfers or change the RTA\n */\n function changeIssuer(address newIssuer) external;\n\n /**\n * @notice Update the transfer agent address (one-time use or RTA-only after initial setup)\n * @param newTransferAgent Address of the new transfer agent (should be RTAProxy contract)\n * @dev After initial setup to RTAProxy, only the RTA can rotate itself via the proxy.\n * This prevents compromised issuers from changing the RTA.\n */\n function setTransferAgent(address newTransferAgent) external;\n\n /**\n * @notice Check if an address is the current transfer agent\n * @param account Address to check\n * @return bool True if the address is the current transfer agent\n */\n function isTransferAgent(address account) external view returns (bool);\n\n // ERC-20 Overrides (Restricted Functions)\n\n /**\n * @notice Transfer tokens - DISABLED for security tokens\n * @dev Must always revert with ERC1450TransferDisabled()\n * Uses specific error for disabled functionality per [ERC-6093](/EIPS/eip-6093) guidelines\n */\n function transfer(address to, uint256 amount) external override returns (bool);\n\n /**\n * @notice Approve spending - DISABLED for security tokens\n * @dev Must always revert with ERC1450TransferDisabled()\n * Uses specific error for disabled functionality per [ERC-6093](/EIPS/eip-6093) guidelines\n */\n function approve(address spender, uint256 amount) external override returns (bool);\n\n /**\n * @notice Get spending allowance - DISABLED for security tokens\n * @dev Must always return 0\n */\n function allowance(address owner, address spender) external view override returns (uint256);\n\n /**\n * @notice Transfer tokens - DISABLED for security tokens\n * @dev Must always revert with ERC1450TransferDisabled()\n * Uses specific error for disabled functionality per [ERC-6093](/EIPS/eip-6093) guidelines\n * Use transferFromRegulated() for actual transfers with regulation tracking\n */\n function transferFrom(address from, address to, uint256 amount) external override returns (bool);\n\n // RTA-Controlled Functions\n\n /**\n * @notice Transfer tokens between accounts with regulation tracking (RTA only)\n * @param from Source address\n * @param to Destination address\n * @param amount Number of tokens to transfer\n * @param regulationType Type of regulation for the transferred tokens\n * @param issuanceDate Original issuance date of the transferred tokens\n * @dev Only callable by the registered transfer agent\n * The regulation type and issuance date specify which tokens to transfer\n * MUST revert if sender has insufficient tokens of the specified regulation/issuance\n * Callers SHOULD first check holdings via getHolderRegulations() or getDetailedBatchInfo()\n * This enables precise control over which token batches are moved\n * The RTA determines the transfer strategy (FIFO, LIFO, tax optimization, etc.)\n */\n function transferFromRegulated(address from, address to, uint256 amount, uint16 regulationType, uint256 issuanceDate) external returns (bool);\n\n /**\n * @notice Mint new tokens with regulation tracking (RTA only)\n * @param to Address to receive the minted tokens\n * @param amount Number of tokens to mint\n * @param regulationType Type of regulation under which shares were issued (uint16 for global compatibility)\n * @param issuanceDate Unix timestamp when shares were originally issued (not tokenization date)\n * @dev Only callable by the registered transfer agent\n * Every security MUST specify a regulation type - there are no \"unregulated\" securities\n * For tokenizing existing securities, issuanceDate should be when investor originally purchased\n * For new issuances, issuanceDate would typically be block.timestamp\n * RTA uses issuanceDate to calculate holding periods for regulatory compliance\n */\n function mint(address to, uint256 amount, uint16 regulationType, uint256 issuanceDate) external returns (bool);\n\n /**\n * @notice Batch mint tokens with regulation tracking (RTA only)\n * @param recipients Array of addresses to receive the minted tokens\n * @param amounts Array of token amounts to mint for each recipient\n * @param regulationTypes Array of regulation types for each mint\n * @param issuanceDates Array of issuance timestamps for each mint\n * @dev Only callable by the registered transfer agent\n * All arrays MUST be the same length\n * Each mint operation follows the same rules as individual mint()\n * Reverts if any single mint would fail\n * Emits TokensMinted event for each successful mint\n * Enables efficient bulk issuance while maintaining compliance tracking\n */\n function batchMint(\n address[] calldata recipients,\n uint256[] calldata amounts,\n uint16[] calldata regulationTypes,\n uint256[] calldata issuanceDates\n ) external returns (bool);\n\n /**\n * @notice Burn tokens from an account (RTA only) - Uses RTA's chosen strategy\n * @param from Address from which to burn tokens\n * @param amount Number of tokens to burn\n * @dev Only callable by the registered transfer agent\n * The RTA determines which tokens to burn based on their strategy (FIFO, LIFO, tax optimization, etc.)\n * Use burnFromRegulated() to burn specific regulation/issuance tokens\n */\n function burnFrom(address from, uint256 amount) external returns (bool);\n\n /**\n * @notice Burn tokens from an account with regulation tracking (RTA only)\n * @param from Address from which to burn tokens\n * @param amount Number of tokens to burn\n * @param regulationType Type of regulation for the tokens to burn\n * @param issuanceDate Original issuance date of the tokens to burn\n * @dev Only callable by the registered transfer agent\n * Burns specific tokens identified by regulation type and issuance date\n * MUST revert if holder has insufficient tokens of the specified regulation/issuance\n * Callers SHOULD first check holdings via getHolderRegulations() or getDetailedBatchInfo()\n * MUST emit TokensBurned event with the specific regulation details\n */\n function burnFromRegulated(address from, uint256 amount, uint16 regulationType, uint256 issuanceDate) external returns (bool);\n\n /**\n * @notice Burn tokens of a specific regulation type (RTA only)\n * @param from Address from which to burn tokens\n * @param amount Number of tokens to burn\n * @param regulationType Specific regulation type to burn\n * @dev Only callable by the registered transfer agent\n * Useful for partial redemptions, buybacks, or regulation-specific corporate actions\n * Reverts if holder has insufficient tokens of the specified regulation type\n * MUST emit TokensBurned event with the specific regulation details\n */\n function burnFromRegulation(address from, uint256 amount, uint16 regulationType) external returns (bool);\n\n /**\n * @notice Get token decimals (OPTIONAL per [EIP-20](/EIPS/eip-20))\n * @return uint8 The number of decimal places (0-18)\n * @dev Set at deployment based on security type:\n * - 0 for traditional indivisible shares\n * - Greater than 0 for fractional shares (mutual funds, REITs, fractional trading)\n * - Must be immutable after deployment\n *\n * NOTE: Per [EIP-20](/EIPS/eip-20), name(), symbol(), and decimals() are OPTIONAL\n * Implementations SHOULD provide these for better UX\n * Wallets MUST NOT assume these functions exist\n */\n function decimals() external view returns (uint8);\n\n // Introspection for Restricted ERC-20 Interface Detection\n\n /**\n * @notice Check if this is a security token with restricted transfers\n * @return bool Always returns true for ERC-1450 tokens\n * @dev Critical for wallets/DEXs to detect restricted tokens and handle appropriately.\n * Prevents users from attempting transfers that will always fail.\n */\n function isSecurityToken() external pure returns (bool);\n\n /**\n * @notice Returns the contract implementation version\n * @return string Semantic version string (e.g., \"1.17.0\")\n * @dev Enables upgrade detection for UUPS-upgradeable contracts.\n * Version SHOULD match the reference implementation package version.\n * Useful for:\n * - Detecting available upgrades by comparing deployed vs local version\n * - Audit trails showing which version was deployed\n * - Debugging and support by identifying exact implementation\n */\n function version() external pure returns (string memory);\n\n /**\n * @notice [EIP-165](/EIPS/eip-165) support for interface detection\n * @param interfaceId The interface identifier to check\n * @return bool True if the contract implements the interface\n * @dev MUST return true for:\n * - 0x01ffc9a7: [ERC-165](/EIPS/eip-165) interface ID\n * - 0xXXXXXXXX: IERC1450 interface ID (see Interface Detection section for calculation)\n *\n * MUST return false for:\n * - 0x36372b07: [ERC-20](/EIPS/eip-20) interface ID\n *\n * Returning false for [ERC-20](/EIPS/eip-20) prevents wallets from assuming standard transfer behavior.\n * While we are ABI-compatible with [ERC-20](/EIPS/eip-20), we are not behaviorally compatible\n * since transfer() and approve() always revert.\n */\n function supportsInterface(bytes4 interfaceId) external view returns (bool);\n\n // KYC/AML Status Check (OPTIONAL)\n\n /**\n * @notice Check if an address has been KYC verified (OPTIONAL)\n * @param account Address to check\n * @return verified Whether the address is linked to a verified person\n * @return expiryDate When the KYC verification expires (0 if not verified)\n * @dev This is a view function that queries the RTA's off-chain database\n * Never returns actual identity information, only verification status\n * Implementations MAY choose to implement this for transparency\n * Returns false for addresses that have never been verified\n */\n function isKYCVerified(address account) external view returns (bool verified, uint256 expiryDate);\n\n // Regulation Tracking Query Functions\n\n /**\n * @notice Get regulation information for tokens held by an address\n * @param holder Address to query\n * @return regulationTypes Array of regulation types for holder's tokens\n * @return amounts Array of token amounts per regulation type\n * @return issuanceDates Array of original issuance dates\n * @dev MUST return arrays of equal length representing holder's token composition\n * Implementation MUST store this data persistently on-chain\n * RTA uses this for transfer calculations and compliance checks\n */\n function getHolderRegulations(address holder) external view returns (\n uint16[] memory regulationTypes,\n uint256[] memory amounts,\n uint256[] memory issuanceDates\n );\n\n /**\n * @notice Get total tokens minted under a specific regulation\n * @param regulationType The regulation type to query\n * @return totalSupply Total tokens minted under this regulation\n * @dev Useful for regulatory reporting and tracking offering limits\n */\n function getRegulationSupply(uint16 regulationType) external view returns (uint256 totalSupply);\n\n /**\n * @notice Get detailed batch information for a holder's tokens\n * @param holder Address to query\n * @return count Number of unique batches the holder has\n * @return regulationTypes Array of regulation types for each batch\n * @return issuanceDates Array of issuance dates for each batch\n * @return amounts Array of token amounts for each batch\n * @dev Returns comprehensive batch-level details for a holder\n * Useful for detailed cap table management and regulatory reporting\n * Each index represents a unique batch of tokens with specific regulation/issuance\n */\n function getDetailedBatchInfo(address holder) external view returns (\n uint256 count,\n uint16[] memory regulationTypes,\n uint256[] memory issuanceDates,\n uint256[] memory amounts\n );\n\n // Batch Operations for Gas Efficiency\n\n /**\n * @notice Batch transfer tokens between multiple address pairs with regulation tracking (RTA only)\n * @param froms Array of source addresses\n * @param tos Array of destination addresses\n * @param amounts Array of token amounts to transfer\n * @param regulationTypes Array of regulation types for each transfer\n * @param issuanceDates Array of issuance dates for each transfer\n * @return bool True if all transfers succeed\n * @dev All arrays must have equal length. Reverts if any transfer fails.\n * Only callable by the registered transfer agent.\n * MUST revert if any sender has insufficient tokens of the specified regulation/issuance\n * The RTA determines the transfer strategy for each transfer\n * Useful for dividend distributions, corporate actions, etc.\n */\n function batchTransferFrom(\n address[] calldata froms,\n address[] calldata tos,\n uint256[] calldata amounts,\n uint16[] calldata regulationTypes,\n uint256[] calldata issuanceDates\n ) external returns (bool);\n\n /**\n * @notice Batch burn tokens from multiple addresses with regulation tracking (RTA only)\n * @param froms Array of addresses from which to burn tokens\n * @param amounts Array of token amounts to burn from each address\n * @param regulationTypes Array of regulation types for each burn\n * @param issuanceDates Array of issuance dates for each burn\n * @return bool True if all burns succeed\n * @dev All arrays must have equal length. Reverts if any burn fails.\n * Only callable by the registered transfer agent.\n * MUST revert if any holder has insufficient tokens of the specified regulation/issuance\n * Useful for redemptions, corporate buybacks, etc.\n */\n function batchBurnFrom(\n address[] calldata froms,\n uint256[] calldata amounts,\n uint16[] calldata regulationTypes,\n uint256[] calldata issuanceDates\n ) external returns (bool);\n\n // Fee Collection Mechanism\n\n /**\n * @notice Register or deregister a broker for this token (RTA only)\n * @param broker Address of the broker to register/deregister\n * @param isApproved Whether to approve or revoke broker status\n * @dev Only callable by RTA after due diligence. Brokers must:\n * 1. Apply off-chain to the RTA\n * 2. Pass KYC/AML and regulatory checks\n * 3. Sign broker agreement\n * 4. Be approved by RTA compliance team\n *\n * RECOMMENDED: Brokers SHOULD use a proxy pattern similar to RTAProxy\n * for key management and operational security. This allows:\n * - Secure key rotation without re-registration\n * - Multi-signature controls for broker operations\n * - Business continuity during personnel changes\n * - Protection against individual key compromise\n *\n * The broker address registered here MAY be:\n * - Direct broker-controlled address (simple but less secure)\n * - BrokerProxy contract address (recommended for production)\n */\n function setBrokerStatus(address broker, bool isApproved) external;\n\n /**\n * @notice Check if an address is a registered broker\n * @param broker Address to check\n * @return bool True if the address is an approved broker\n */\n function isRegisteredBroker(address broker) external view returns (bool);\n\n /**\n * @notice Request a transfer with fee payment\n * @param from Source address for the transfer\n * @param to Destination address for the transfer\n * @param amount Number of tokens to transfer\n * @param feeAmount Amount of fee being paid (in the configured fee token)\n * @return requestId Unique identifier for this request (for idempotency and tracking)\n * @dev Creates a new transfer request with initial status: RequestStatus.Requested\n *\n * Fee payment:\n * - Fee MUST be paid in the configured fee token (see getFeeToken())\n * - Caller MUST have approved the token contract to spend feeAmount\n * - Fee is transferred via safeTransferFrom from msg.sender\n *\n * Fee payment responsibility:\n * - Holder-initiated (msg.sender == from): Holder pays the fee\n * - Broker-initiated (msg.sender != from): Broker pays fee on behalf of client\n * - Settlement failures: Fees are NOT automatically refunded (RTA discretion)\n *\n * Request lifecycle:\n * 1. Request created with unique requestId (status: Requested)\n * 2. RTA reviews request (status: UnderReview - optional)\n * 3. RTA approves/rejects (status: Approved or Rejected)\n * 4. If approved, RTA executes transfer (status: Executed)\n * 5. Optional: Request expires after timeout (status: Expired)\n *\n * Idempotency guarantee:\n * - Each requestId is unique and can only be executed ONCE\n * - Duplicate execution attempts MUST revert\n * - Clients can safely retry requests with new requestId if needed\n *\n * Authorization requirements:\n * - If msg.sender == from: Token holder requesting their own transfer\n * - If msg.sender != from: Must be a registered broker (via setBrokerStatus)\n * - Reverts if neither condition is met\n *\n * Implementation MUST:\n * - Verify fee token is configured (revert if not)\n * - Generate unique requestId for each request\n * - Emit TransferRequested event\n * - Store request details for later processing\n * - Prevent double-spending by tracking request status\n */\n function requestTransferWithFee(\n address from,\n address to,\n uint256 amount,\n uint256 feeAmount\n ) external returns (uint256 requestId);\n\n /**\n * @notice Request transfer with [EIP-2612](/EIPS/eip-2612) permit for gasless fee approval (OPTIONAL)\n * @param from Source address for the transfer\n * @param to Destination address for the transfer\n * @param amount Number of tokens to transfer\n * @param feeAmount Amount of fee being paid (in the configured fee token)\n * @param deadline Permit signature deadline\n * @param v ECDSA signature v parameter\n * @param r ECDSA signature r parameter\n * @param s ECDSA signature s parameter\n * @return requestId Unique identifier for this transfer request\n * @dev OPTIONAL: Allows fee payment without prior approve() transaction\n * Uses [EIP-2612](/EIPS/eip-2612) permit for gasless approval of fee token\n * Particularly useful for first-time users who don't have fee token approvals\n * MUST revert if the configured fee token doesn't support [EIP-2612](/EIPS/eip-2612)\n * Example: USDC, DAI, and other modern stablecoins support permit\n *\n * Implementation:\n * 1. Call permit on the configured fee token with the provided signature\n * 2. Then execute the same logic as requestTransferWithFee\n * 3. This avoids users needing a separate approve transaction for fees\n */\n function requestTransferWithPermit(\n address from,\n address to,\n uint256 amount,\n uint256 feeAmount,\n uint256 deadline,\n uint8 v,\n bytes32 r,\n bytes32 s\n ) external returns (uint256 requestId);\n\n /**\n * @notice Get current fee for a transfer\n * @param from Source address\n * @param to Destination address\n * @param amount Transfer amount\n * @return feeAmount Required fee amount in the configured fee token\n * @dev Allows dynamic fee calculation based on transfer parameters\n * Fee is always denominated in the configured fee token (see getFeeToken())\n * Fee type determines calculation:\n * - Type 0 (flat): Returns feeValue directly\n * - Type 1 (percentage): Returns (amount * feeValue) / 10000\n */\n function getTransferFee(address from, address to, uint256 amount)\n external view returns (uint256 feeAmount);\n\n /**\n * @notice Get the configured fee token address\n * @return token The [ERC-20](/EIPS/eip-20) token used for fee payments\n * @dev Returns address(0) if no fee token is configured yet\n * RTA MUST configure a fee token before transfers can be requested\n * Common choices: USDC, USDT, or other stablecoins\n */\n function getFeeToken() external view returns (address token);\n\n /**\n * @notice Set the fee token (RTA only)\n * @param newFeeToken Address of the [ERC-20](/EIPS/eip-20) token to use for fees\n * @dev Only callable by RTA to configure or change the fee token\n * MUST emit FeeTokenUpdated event\n * MUST NOT accept address(0) - use a stablecoin like USDC\n * Changing fee token does not affect pending transfer requests\n */\n function setFeeToken(address newFeeToken) external;\n\n /**\n * @notice Set fee parameters (RTA only)\n * @param feeType Type of fee structure (0: flat, 1: percentage in basis points)\n * @param feeValue Fee amount or percentage basis points\n * @dev Only callable by RTA to update fee structure\n * MUST emit FeeParametersUpdated event\n * For percentage fees, feeValue is in basis points (100 = 1%)\n */\n function setFeeParameters(uint8 feeType, uint256 feeValue) external;\n\n /**\n * @notice Withdraw collected fees (RTA only)\n * @param amount Amount to withdraw (in the configured fee token)\n * @param recipient Recipient address for fees\n * @dev Only callable by RTA to collect accumulated fees\n * Withdraws from the configured fee token balance\n * MUST revert if insufficient collected fees\n */\n function withdrawFees(uint256 amount, address recipient) external;\n\n /**\n * @notice Process pending transfer request (RTA only)\n * @param requestId ID of the transfer request\n * @param approved Whether to approve or reject the transfer\n * @dev RTA reviews and processes transfer requests after compliance checks\n * MUST transition request through proper lifecycle states\n * MUST emit events for each state transition\n */\n function processTransferRequest(uint256 requestId, bool approved) external;\n\n /**\n * @notice Reject transfer request with specific reason code (RTA only)\n * @param requestId ID of the transfer request to reject\n * @param reasonCode Rejection reason code (see Reason Codes section)\n * @param refundFee Whether to refund the fee to the requester\n * @dev Convenience function for rejections with detailed reason tracking\n * MUST transition request status to Rejected\n * MUST emit TransferRejected event with reasonCode and refundFee flag\n * If refundFee is true, MUST return the fee to the original payer\n * Alternative to processTransferRequest(requestId, false) with more detail\n */\n function rejectTransferRequest(uint256 requestId, uint16 reasonCode, bool refundFee) external;\n\n // Transfer Request Lifecycle Management\n\n /**\n * @notice Request lifecycle states\n * @dev Requests MUST follow this state machine:\n * Requested → UnderReview → (Approved | Rejected) → Executed\n *\n * State transitions:\n * - Requested: Initial state when requestTransferWithFee is called\n * - UnderReview: RTA begins compliance checks (optional intermediate state)\n * - Approved: RTA approves after compliance checks pass\n * - Rejected: RTA rejects for compliance or other reasons\n * - Executed: Transfer completed and tokens moved\n * - Expired: Request timed out without processing (if timeouts implemented)\n *\n * Idempotency: Each requestId MUST be unique and can only be executed ONCE\n */\n enum RequestStatus {\n Requested, // 0: Initial state\n UnderReview, // 1: RTA is reviewing\n Approved, // 2: Approved, awaiting execution\n Rejected, // 3: Rejected, terminal state\n Executed, // 4: Successfully executed, terminal state\n Expired // 5: Timed out, terminal state\n }\n\n /**\n * @notice Get current status of a transfer request (OPTIONAL)\n * @param requestId The transfer request ID\n * @dev OPTIONAL: Implementations MAY instead expose equivalent request data\n * through other read methods (e.g., a public storage mapping).\n * @return status Current RequestStatus\n * @return from Source address\n * @return to Destination address\n * @return amount Transfer amount\n * @return requestedAt Timestamp when request was created\n * @return processedAt Timestamp when request was processed (0 if pending)\n */\n function getRequestStatus(uint256 requestId) external view returns (\n RequestStatus status,\n address from,\n address to,\n uint256 amount,\n uint256 requestedAt,\n uint256 processedAt\n );\n\n /**\n * @notice Update request status (RTA only)\n * @param requestId The transfer request ID\n * @param newStatus New status to transition to\n * @dev MUST validate state transitions according to lifecycle rules\n * MUST emit RequestStatusChanged event\n * Invalid transitions MUST revert\n */\n function updateRequestStatus(uint256 requestId, RequestStatus newStatus) external;\n\n // Events for transfer request lifecycle\n event TransferRequested(\n uint256 indexed requestId,\n address indexed from,\n address indexed to,\n uint256 amount,\n uint256 feePaid,\n address requestedBy // holder or broker\n );\n\n event RequestStatusChanged(\n uint256 indexed requestId,\n RequestStatus indexed oldStatus,\n RequestStatus indexed newStatus,\n uint256 timestamp\n );\n\n event TransferExecuted(\n uint256 indexed requestId,\n address indexed from,\n address indexed to,\n uint256 amount\n );\n\n event TransferRejected(\n uint256 indexed requestId,\n uint16 reasonCode, // Gas-efficient reason codes (see Reason Codes section)\n bool feeRefunded // Whether fee was refunded\n );\n\n event TransferExpired(\n uint256 indexed requestId,\n uint256 expiredAt\n );\n\n // Fee-related events\n event FeeParametersUpdated(uint8 feeType, uint256 feeValue);\n event FeeTokenUpdated(address indexed previousToken, address indexed newToken);\n event FeesWithdrawn(uint256 amount, address indexed recipient);\n event BrokerStatusUpdated(address indexed broker, bool isApproved, address indexed updatedBy);\n\n // Account restriction events\n event AccountFrozen(address indexed account, bool frozen, address indexed frozenBy);\n\n // Reason Codes for Transfer Rejection\n // Gas-efficient uint16 codes instead of strings\n uint16 constant REASON_COMPLIANCE_FAILED = 1; // KYC/AML check failed\n uint16 constant REASON_INSUFFICIENT_BALANCE = 2; // Sender lacks tokens\n uint16 constant REASON_RESTRICTED_ACCOUNT = 3; // Account is frozen/restricted\n uint16 constant REASON_TRANSFER_WINDOW_CLOSED = 4; // Outside allowed transfer window\n uint16 constant REASON_EXCEEDS_HOLDING_LIMIT = 5; // Would exceed max holding\n uint16 constant REASON_REGULATORY_HALT = 6; // Trading halted by regulator\n uint16 constant REASON_COURT_ORDER = 7; // Blocked by court order\n uint16 constant REASON_INVALID_RECIPIENT = 8; // Recipient not whitelisted\n uint16 constant REASON_LOCK_PERIOD = 9; // Tokens are locked\n uint16 constant REASON_RECIPIENT_NOT_VERIFIED = 10; // Recipient hasn't completed KYC/AML\n uint16 constant REASON_ADDRESS_NOT_LINKED = 11; // Address not linked to verified identity\n uint16 constant REASON_SENDER_VERIFICATION_EXPIRED = 12; // Sender's KYC expired\n uint16 constant REASON_JURISDICTION_BLOCKED = 13; // Recipient in restricted jurisdiction\n uint16 constant REASON_ACCREDITATION_REQUIRED = 14; // Recipient not accredited (Reg D)\n uint16 constant REASON_OTHER = 999; // Other/unspecified reason\n\n // Fee Refund Policy\n /**\n * @notice Fee refund policy for rejected/expired transfers\n * @dev Implementations MUST clearly document their refund policy:\n * Option 1: AUTO_REFUND - Fees automatically refunded on rejection/expiry\n * Option 2: NO_REFUND - Fees retained for processing costs\n * Option 3: CONDITIONAL_REFUND - Refund based on reason code\n *\n * The refund policy SHOULD be:\n * - Clearly documented in the contract\n * - Communicated to users before fee payment\n * - Consistently applied across all transfers\n * - Emit TransferRejected event with feeRefunded flag\n */\n\n // Optional: Off-chain Compliance Pre-check (EIP-3668 CCIP-Read)\n\n /**\n * @notice Pre-check transfer compliance off-chain (OPTIONAL)\n * @param from Source address for the transfer\n * @param to Destination address for the transfer\n * @param amount Number of tokens to transfer\n * @return bool True if transfer would likely pass compliance\n * @dev OPTIONAL: Implements EIP-3668 (CCIP-Read) for off-chain compliance checks\n *\n * This check SHOULD verify:\n * 1. Sender KYC/AML status is current (not expired)\n * 2. Recipient has passed KYC/AML verification\n * 3. Recipient address ownership is verified and linked to identity\n * 4. Transfer doesn't violate jurisdiction restrictions\n * 5. Accreditation requirements are met (if applicable for Reg D/Reg A)\n *\n * This function MAY revert with OffchainLookup error containing:\n * - URLs for off-chain compliance services\n * - Callback function to process off-chain response\n *\n * Purpose: Allow wallets to pre-screen transfers before users pay gas\n * Benefits:\n * - Show specific compliance failure reasons upfront\n * - Improve UX by preventing failed transactions\n * - Reduce wasted gas on non-compliant transfers\n *\n * IMPORTANT: This check is ADVISORY ONLY and NOT BINDING\n * - The actual transfer still requires RTA approval\n * - Compliance status may change between pre-check and execution\n * - RTA has final authority on all transfers\n *\n * Example implementation:\n * ```solidity\n * error OffchainLookup(address sender, string[] urls, bytes callData,\n * bytes4 callbackFunction, bytes extraData);\n *\n * function preCheckCompliance(address from, address to, uint256 amount)\n * external view returns (bool) {\n * revert OffchainLookup(\n * address(this),\n * urls, // RTA's compliance API endpoints\n * abi.encodeWithSignature(\"checkCompliance(address,address,uint256)\", from, to, amount),\n * this.preCheckComplianceCallback.selector,\n * \"\"\n * );\n * }\n * ```\n *\n * Wallets supporting [EIP-3668](/EIPS/eip-3668) will:\n * 1. Catch the OffchainLookup error\n * 2. Query the specified URLs with the provided callData\n * 3. Call the callback function with response and UNMODIFIED extraData\n * 4. Display compliance status to user based on callback result\n * 5. Allow/prevent transfer request submission accordingly\n */\n function preCheckCompliance(address from, address to, uint256 amount)\n external view returns (bool);\n\n /**\n * @notice Callback for processing off-chain compliance response (OPTIONAL)\n * @param response Encoded response from off-chain compliance service\n * @param extraData Additional data from original request (passed through unmodified)\n * @return bool Compliance check result\n * @dev Only called by wallets supporting EIP-3668\n * Validates and interprets off-chain compliance service response\n *\n * Per [EIP-3668](/EIPS/eip-3668) specification:\n * - Clients MUST pass extraData unmodified from the OffchainLookup error\n * - The callback signature MUST match EIP-3668's standard format\n * - This enables stateless operation and future extensibility\n *\n * Example client implementation:\n * 1. Catch OffchainLookup(sender, urls, callData, callbackFunction, extraData)\n * 2. Query off-chain service with callData\n * 3. Call callbackFunction(response, extraData) with UNMODIFIED extraData\n */\n function preCheckComplianceCallback(bytes calldata response, bytes calldata extraData)\n external pure returns (bool);\n\n // ============ ERC-1643 Document Management Interface (OPTIONAL) ============\n // Implementations MAY support on-chain anchoring of document references.\n // RTAs already maintain authoritative books and records off-chain per their\n // regulatory obligations; on-chain anchoring is an optional transparency\n // enhancement, not a compliance requirement.\n\n /**\n * @notice Set a document for the token (RTA only) (OPTIONAL)\n * @param _name Document name (unique identifier)\n * @param _uri Document location (IPFS hash or HTTPS URL)\n * @param _documentHash Hash of the document for verification\n * @dev Part of ERC-1643 standard. Only callable by RTA.\n * Used for storing references to legal documents, compliance certificates,\n * court orders, recovery evidence, physical addresses, etc.\n * Never store PII directly on-chain - use document URIs and hashes only.\n *\n * Common document names:\n * - \"PHYSICAL_ADDRESS\": Issuer's registered address\n * - \"PROSPECTUS\": Offering documents\n * - \"COURT_ORDER\": Legal judgments\n * - \"RECOVERY_EVIDENCE\": Lost wallet documentation\n *\n * Implementations providing this function MUST emit DocumentUpdated.\n */\n function setDocument(\n bytes32 _name,\n string calldata _uri,\n bytes32 _documentHash\n ) external;\n\n /**\n * @notice Get a specific document's details (OPTIONAL)\n * @param _name Document name to retrieve\n * @return documentUri Document location\n * @return documentHash Document hash for verification\n * @return timestamp When document was last updated\n * @dev Part of ERC-1643 standard. Publicly accessible.\n */\n function getDocument(bytes32 _name)\n external view\n returns (\n string memory documentUri,\n bytes32 documentHash,\n uint256 timestamp\n );\n\n /**\n * @notice Remove a document (RTA only) (OPTIONAL)\n * @param _name Document name to remove\n * @dev Part of ERC-1643 standard. Only callable by RTA.\n * Implementations providing this function MUST emit DocumentRemoved.\n */\n function removeDocument(bytes32 _name) external;\n\n /**\n * @notice Get all document names (OPTIONAL)\n * @return Array of all document names that have been set\n * @dev Part of ERC-1643 standard. Publicly accessible.\n * Allows discovery of all documents associated with the token.\n */\n function getAllDocuments() external view returns (bytes32[] memory);\n\n // ============ Recovery Workflow for Lost/Compromised Wallets (OPTIONAL) ============\n // Uses ERC-1643 for document management and aligns with ERC-1644 for controller operations.\n // OPTIONAL: This structured, time-locked workflow is an extension. The REQUIRED\n // baseline for recovery is controllerTransfer — the RTA verifies the investor's\n // identity through its existing off-chain KYC records and executes the transfer.\n // The structured workflow adds public evidence anchoring and a dispute window\n // for deployments that want on-chain transparency of recovery operations.\n\n /**\n * @notice Initiate recovery process for lost wallet (RTA only) (OPTIONAL)\n * @param lostWallet Address that has lost access\n * @param newWallet Proposed replacement address\n * @param documentName Name/type of the supporting document (ERC-1643 compatible)\n * @param uri URI pointing to the evidence document (IPFS/HTTPS)\n * @param documentHash Hash of the document for integrity verification\n * @return recoveryId Unique identifier for the recovery request\n * @dev Creates a time-locked recovery request requiring multi-step verification:\n * 1. Identity verification of the claiming party\n * 2. Proof of ownership (off-chain documentation)\n * 3. Time delay for potential disputes (e.g., 30 days)\n * 4. Final execution after time lock expires\n *\n * Following ERC-1643 document management standards:\n * - documentName: Type of evidence (e.g., \"RECOVERY_AFFIDAVIT\", \"DEATH_CERTIFICATE\")\n * - uri: Link to encrypted document storage (never store PII on-chain)\n * - documentHash: Cryptographic hash for document integrity\n *\n * Implementations providing this function MUST emit DocumentUpdated\n * per ERC-1643 when evidence is submitted\n */\n function initiateRecovery(\n address lostWallet,\n address newWallet,\n bytes32 documentName,\n string calldata uri,\n bytes32 documentHash\n ) external returns (uint256 recoveryId);\n\n /**\n * @notice Cancel a pending recovery request (RTA only) (OPTIONAL)\n * @param recoveryId The recovery request to cancel\n * @dev Can be called if:\n * - Original wallet owner proves they still have access\n * - Evidence is found to be fraudulent\n * - Court order requires cancellation\n */\n function cancelRecovery(uint256 recoveryId) external;\n\n /**\n * @notice Execute recovery after time lock expires (RTA only) (OPTIONAL)\n * @param recoveryId The recovery request to execute\n * @dev Transfers all tokens from lost wallet to new wallet\n * Can only be executed after time lock period (e.g., 30 days)\n * Implementations providing this function MUST emit ControllerTransfer\n * per ERC-1644\n */\n function executeRecovery(uint256 recoveryId) external;\n\n /**\n * @notice Controller transfer for court orders (RTA only) - ERC-1644 compatible\n * @param from Source address\n * @param to Destination address\n * @param amount Number of tokens\n * @param data Encoded data containing document references\n * @param operatorData Encoded document information per ERC-1643:\n * - documentName: Type (e.g., \"COURT_ORDER\", \"REGULATORY_ACTION\")\n * - uri: Link to encrypted document storage\n * - documentHash: Cryptographic hash for integrity\n * @dev Immediate transfer without time lock for:\n * - Court-ordered transfers (divorce, judgments)\n * - Regulatory enforcement actions\n * - Estate distributions with proper documentation\n *\n * Following ERC-1644 controller operation standards:\n * - MUST emit ControllerTransfer event\n * - Uses standard function name for tooling compatibility\n *\n * Following ERC-1643 document management:\n * - MUST emit DocumentUpdated event when court order is attached\n * - Never store PII on-chain, only document URIs and hashes\n */\n function controllerTransfer(\n address from,\n address to,\n uint256 amount,\n bytes calldata data,\n bytes calldata operatorData\n ) external;\n\n // ============ Account Freezing ============\n\n /**\n * @notice Freeze or unfreeze an account (RTA only)\n * @param account Address to freeze/unfreeze\n * @param frozen True to freeze, false to unfreeze\n * @dev Frozen accounts cannot send or receive tokens\n * Used for compliance holds, regulatory actions, or suspicious activity\n * Only RTA can freeze/unfreeze accounts\n * MUST emit AccountFrozen event\n */\n function setAccountFrozen(address account, bool frozen) external;\n\n /**\n * @notice Check if an account is frozen\n * @param account Address to check\n * @return bool True if the account is frozen\n * @dev Publicly accessible for transparency\n * Wallets and exchanges can check before attempting transfers\n */\n function isAccountFrozen(address account) external view returns (bool);\n\n // ============ Recovery System (OPTIONAL) ============\n\n /**\n * @notice Get recovery request details (OPTIONAL)\n * @param recoveryId The recovery request ID\n * @return lostWallet The wallet being recovered\n * @return newWallet The replacement wallet\n * @return documentName The type of evidence document (ERC-1643)\n * @return documentUri The URI of the evidence document\n * @return documentHash The hash of the evidence document\n * @return initiatedAt Timestamp when recovery was initiated\n * @return status Current status (pending/executed/cancelled)\n */\n function getRecoveryDetails(uint256 recoveryId)\n external view returns (\n address lostWallet,\n address newWallet,\n bytes32 documentName,\n string memory documentUri,\n bytes32 documentHash,\n uint256 initiatedAt,\n uint8 status\n );\n\n /**\n * @notice Check if a wallet has a pending recovery\n * @param wallet Address to check\n * @return bool True if wallet has pending recovery\n * @return uint256 Recovery ID if exists, 0 otherwise\n */\n function hasPendingRecovery(address wallet)\n external view returns (bool, uint256);\n\n // Standard Events from ERC-1644 (Controller Operations)\n event ControllerTransfer(\n address indexed controller,\n address indexed from,\n address indexed to,\n uint256 value,\n bytes data,\n bytes operatorData\n );\n\n event ControllerRedemption(\n address indexed controller,\n address indexed tokenHolder,\n uint256 value,\n bytes data,\n bytes operatorData\n );\n\n // ERC-1643 Standard Events (Document Management — OPTIONAL, required if\n // the document management extension is implemented)\n event DocumentUpdated(\n bytes32 indexed _name,\n string _uri,\n bytes32 _documentHash\n );\n event DocumentRemoved(\n bytes32 indexed _name,\n string _uri,\n bytes32 _documentHash\n );\n\n // Recovery-specific Events (OPTIONAL, required if the recovery workflow\n // extension is implemented)\n event RecoveryInitiated(\n uint256 indexed recoveryId,\n address indexed lostWallet,\n address indexed newWallet,\n uint256 timelock\n );\n event RecoveryCancelled(uint256 indexed recoveryId, address cancelledBy);\n // RecoveryExecuted is replaced by ControllerTransfer event per ERC-1644\n}\n\n Interface Detection\n\nThe IERC1450 interface ID is calculated by XOR’ing the function selectors of all functions unique to the IERC1450 interface (excluding inherited ERC-20 functions):\n\n// IERC1450 unique functions (not in ERC-20):\nbytes4 constant private CHANGEISSUER = bytes4(keccak256(\"changeIssuer(address)\"));\nbytes4 constant private SETTRANSFERAGENT = bytes4(keccak256(\"setTransferAgent(address)\"));\nbytes4 constant private ISTRANSFERAGENT = bytes4(keccak256(\"isTransferAgent(address)\"));\nbytes4 constant private ISSECURITYTOKEN = bytes4(keccak256(\"isSecurityToken()\"));\nbytes4 constant private MINT = bytes4(keccak256(\"mint(address,uint256,uint16,uint256)\"));\nbytes4 constant private BURNFROM = bytes4(keccak256(\"burnFrom(address,uint256)\"));\nbytes4 constant private BURNFROMREGULATION = bytes4(keccak256(\"burnFromRegulation(address,uint256,uint16)\"));\nbytes4 constant private GETHOLDERREGULATIONS = bytes4(keccak256(\"getHolderRegulations(address)\"));\nbytes4 constant private GETREGULATIONSUPPLY = bytes4(keccak256(\"getRegulationSupply(uint16)\"));\n// ... additional IERC1450-specific functions\n\n// The computed interface ID:\nbytes4 constant public IERC1450_INTERFACE_ID = CHANGEISSUER ^ SETTRANSFERAGENT ^ ISTRANSFERAGENT ^ ISSECURITYTOKEN ^ MINT ^ BURNFROM ^ BURNFROMREGULATION ^ GETHOLDERREGULATIONS ^ GETREGULATIONSUPPLY /* ^ ... */;\n// Actual value from reference implementation:\nbytes4 constant public IERC1450_INTERFACE_ID = 0xaf175dee;\n\nImportant Notes on Interface Detection:\n\n Implementations MUST return true from supportsInterface(0x01ffc9a7) for ERC-165 itself\n Implementations MUST return true from supportsInterface(0xaf175dee) for IERC1450\n Implementations SHOULD return true from supportsInterface(type(IERC20Metadata).interfaceId) for token metadata (name(), symbol(), decimals())\n Implementations MUST NOT return true from supportsInterface(0x36372b07) for ERC-20\n\nWhy NOT Support ERC-20 Interface ID:\nWhile ERC-1450 is ABI-compatible with ERC-20 (same function signatures for view functions), returning true for the ERC-20 interface ID (0x36372b07) would be misleading:\n\n Wallets would assume they can call transfer() and approve() normally\n These functions always revert in ERC-1450, breaking user expectations\n Better to force explicit detection of IERC1450 to ensure proper UI/UX\n Returning true for IERC20Metadata is acceptable since name(), symbol(), and decimals() work normally\n\n RTA Proxy Pattern (REQUIRED Security Enhancement)\n\nTo prevent security vulnerabilities where a compromised issuer could change the RTA and steal tokens, ERC-1450 implementations MUST use an RTA Proxy pattern. The reference implementation uses a generic multi-signature wallet that provides maximum flexibility while maintaining security:\n\n/**\n * @title RTAProxy\n * @notice Multi-signature proxy contract for RTA operations\n * @dev Deployed once and set as the permanent transferAgent in ERC-1450 tokens\n *\n * The RTAProxy pattern provides:\n * - Protection against single key compromise via M-of-N multi-signature\n * - Generic operation execution (can call any function on any target)\n * - Signer management through multi-sig consensus\n * - Complete audit trail of all RTA actions\n *\n * SECURITY REQUIREMENTS:\n * - MUST use multiple signers (recommended: 2-of-3 or 3-of-5)\n * - Signers SHOULD use hardware wallets or institutional custody\n * - All operations MUST emit events for audit trail\n */\ninterface IRTAProxy {\n // ============ Events ============\n\n event SignerAdded(address indexed signer);\n event SignerRemoved(address indexed signer);\n event RequiredSignaturesUpdated(uint256 oldRequired, uint256 newRequired);\n event OperationSubmitted(uint256 indexed operationId, address indexed submitter);\n event OperationConfirmed(uint256 indexed operationId, address indexed signer);\n event OperationExecuted(uint256 indexed operationId);\n event OperationRevoked(uint256 indexed operationId, address indexed signer);\n\n // ============ Errors ============\n\n error NotASigner();\n error AlreadyASigner();\n error AlreadyConfirmed();\n error NotConfirmed();\n error InsufficientConfirmations();\n error OperationAlreadyExecuted();\n error InvalidSignerCount();\n\n // ============ Multi-Sig Operations ============\n\n /**\n * @notice Submit a new operation for multi-sig approval\n * @param target The contract to call (e.g., ERC-1450 token address)\n * @param data The encoded function call (e.g., abi.encodeWithSignature(\"mint(...)\"))\n * @param value ETH value to send (usually 0)\n * @return operationId The ID of the submitted operation\n * @dev Submitter automatically confirms the operation\n * Operation auto-executes if submitter's confirmation meets threshold\n */\n function submitOperation(\n address target,\n bytes memory data,\n uint256 value\n ) external returns (uint256 operationId);\n\n /**\n * @notice Confirm a pending operation\n * @param operationId The operation to confirm\n * @dev Auto-executes when confirmation threshold is met\n */\n function confirmOperation(uint256 operationId) external;\n\n /**\n * @notice Revoke a previously given confirmation\n * @param operationId The operation to revoke confirmation from\n */\n function revokeConfirmation(uint256 operationId) external;\n\n /**\n * @notice Manually execute an operation that has enough confirmations\n * @param operationId The operation to execute\n */\n function executeOperation(uint256 operationId) external;\n\n // ============ Signer Management (via multi-sig) ============\n\n /**\n * @notice Add a new signer (requires multi-sig approval)\n * @param signer Address of the new signer\n * @dev MUST be called through submitOperation (msg.sender == address(this))\n */\n function addSigner(address signer) external;\n\n /**\n * @notice Remove a signer (requires multi-sig approval)\n * @param signer Address of the signer to remove\n * @dev MUST be called through submitOperation\n * MUST NOT reduce signers below requiredSignatures\n */\n function removeSigner(address signer) external;\n\n /**\n * @notice Update required signature threshold (requires multi-sig approval)\n * @param newRequiredSignatures New threshold\n * @dev MUST be called through submitOperation\n * MUST be > 0 and <= signers.length\n */\n function updateRequiredSignatures(uint256 newRequiredSignatures) external;\n\n // ============ View Functions ============\n\n /**\n * @notice Get the list of current signers\n * @return Array of signer addresses\n */\n function getSigners() external view returns (address[] memory);\n\n /**\n * @notice Check if an address has confirmed an operation\n * @param operationId The operation ID\n * @param signer The signer address\n * @return bool True if the signer has confirmed\n */\n function hasConfirmed(uint256 operationId, address signer) external view returns (bool);\n\n /**\n * @notice G","tokens":15000,"squid":"spider-05","role":"Spec Spider","at":1791342849515,"hash":"889a9e383d520be36835f3f6be086208d4f58236"}
{"url":"https://developers.jup.ag/docs/ai/cli","domain":"developers.jup.ag","title":"Jupiter CLI - Jupiter Developers","text":"The Jupiter CLI (jup) lets you interact with Jupiter’s products from the command line. Trade spot, open perps positions, earn yield, and more.\nThe CLI is pre-v1 (early alpha) and should be considered unstable. Breaking changes may be introduced without warning.\n​Install\nnpm i -g @jup-ag/cli\n\nFor other install methods (install script, standalone binary), see the CLI repository.\n​Usage\nThe CLI covers Jupiter products like Spot (swaps, portfolio, transfers), Perps (leveraged longs/shorts), and Lend (earn yield on deposits). For the full command reference, key management, configuration, and examples, see the full CLI documentation in the public CLI repository.\n​Ways to Use\n​Terminal\nThe most direct way. Install, add a key, and start trading:\njup keys add mykey\njup spot swap --from SOL --to USDC --amount 1\n\n​Telegram\nUse the CLI through OpenClaw, an open-source AI assistant that runs locally and connects to Telegram and other chat apps (WhatsApp, Discord, Slack, Signal).\n\nInstall OpenClaw:\ncurl -fsSL https://openclaw.ai/install.sh | bash\n\nConnect your Telegram account by following the OpenClaw setup guide\n\nInstall the Jupiter CLI:\nnpm i -g @jup-ag/cli\n\nAdd a key:\njup keys add mykey\n\nMessage your OpenClaw bot on Telegram:\n\n“Swap 1 SOL to USDC”\n\nOpenClaw executes the CLI command on your behalf and returns the result in chat.\n\nFor a more lightweight starting point, check out miniclaw, a minimal open-source personal AI assistant you can run locally with Telegram.\n​AI Agents\nThe CLI is designed to be LLM-friendly. All commands are non-interactive and support JSON output for structured, parseable responses.\njup spot swap --from SOL --to USDC --amount 1 -f json\n\nAI agents (Claude Code, Cursor, Codex, etc.) can invoke CLI commands directly through shell access. Point your agent at the CLI documentation on GitHub for complete command references and JSON response schemas.\nSet an API key from Portal for higher rate limits when running automated workflows:jup config set --api-key <your-key>\n\n​Resources\nWas this page helpful?","tokens":511,"squid":"spider-02","role":"Liquidity Spider","at":1791342856980,"hash":"bdd12b5ed2d6bc7c2c9e0a6ab7a058b103e55997"}
{"url":"https://eips.ethereum.org/EIPS/eip-6093","domain":"eips.ethereum.org","title":"ERC-6093: Custom errors for commonly-used tokens","text":"🎉 Final\n\n Standards Track: ERC\n\n ERC-6093: Custom errors for commonly-used tokens\n\n Lists custom errors for common token implementations\n\n Authors\n Ernesto García (@ernestognw), Francisco Giordano (@frangio), Hadrien Croubois (@Amxx)\n\n Created\n 2022-12-06\n\n Requires\n\n EIP-20, \n\n EIP-721, \n\n EIP-1155\n\n Abstract\n\nThis EIP defines a standard set of custom errors for commonly-used tokens, which are defined as ERC-20, ERC-721, and ERC-1155 tokens.\n\nEthereum applications and wallets have historically relied on revert reason strings to display the cause of transaction errors to users. Recent Solidity versions offer rich revert reasons with error-specific decoding (sometimes called “custom errors”). This EIP defines a standard set of errors designed to give at least the same relevant information as revert reason strings, but in a structured and expected way that clients can implement decoding for.\n\n Motivation\n\nSince the introduction of Solidity custom errors in v0.8.4, these have provided a way to show failures in a more expressive and gas efficient manner with dynamic arguments, while reducing deployment costs.\n\nHowever, ERC-20, ERC-721, ERC-1155 were already finalized when custom errors were released, so no errors are included in their specification.\n\nStandardized errors allow users to expect more consistent error messages across applications or testing environments, while exposing pertinent arguments and overall reducing the need of writing expensive revert strings in the deployment bytecode.\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\nThe following errors were designed according to the criteria described in Rationale.\n\nThis EIP defines standard errors that may be used by implementations in certain scenarios but it does not specify whether implementations should revert in those scenarios, which remains up to the implementers unless a revert is mandated by the corresponding EIPs.\n\nThe names of the error arguments are defined in the Parameter Glossary and MUST be used according to those definitions.\n\n ERC-20\n\n ERC20InsufficientBalance(address sender, uint256 balance, uint256 needed)\n\nIndicates an error related to the current balance of a sender.\nUsed in transfers.\n\nUsage guidelines:\n\n balance MUST be less than needed.\n\n ERC20InvalidSender(address sender)\n\nIndicates a failure with the token sender.\nUsed in transfers.\n\nUsage guidelines:\n\n RECOMMENDED for disallowed transfers from the zero address.\n MUST NOT be used for approval operations.\n MUST NOT be used for balance or allowance requirements.\n\n Use ERC20InsufficientBalance or ERC20InsufficientAllowance instead.\n\n ERC20InvalidReceiver(address receiver)\n\nIndicates a failure with the token receiver.\nUsed in transfers.\n\nUsage guidelines:\n\n RECOMMENDED for disallowed transfers to the zero address.\n RECOMMENDED for disallowed transfers to non-compatible addresses (eg. contract addresses).\n MUST NOT be used for approval operations.\n\n ERC20InsufficientAllowance(address spender, uint256 allowance, uint256 needed)\n\nIndicates a failure with the spender’s allowance.\nUsed in transfers.\n\nUsage guidelines:\n\n allowance MUST be less than needed.\n\n ERC20InvalidApprover(address approver)\n\nIndicates a failure with the approver of a token to be approved.\nUsed in approvals.\n\nUsage guidelines:\n\n RECOMMENDED for disallowed approvals from the zero address.\n MUST NOT be used for transfer operations.\n\n ERC20InvalidSpender(address spender)\n\nIndicates a failure with the spender to be approved.\nUsed in approvals.\n\nUsage guidelines:\n\n RECOMMENDED for disallowed approvals to the zero address.\n RECOMMENDED for disallowed approvals to the owner itself.\n MUST NOT be used for transfer operations.\n\n Use ERC20InsufficientAllowance instead.\n\n ERC-721\n\n ERC721InvalidOwner(address owner)\n\nIndicates that an address can’t be an owner.\nUsed in balance queries.\n\nUsage guidelines:\n\n RECOMMENDED for addresses whose ownership is disallowed (eg. ERC-721 explicitly disallows address(0) to be an owner).\n MUST NOT be used for transfers.\n\n Use ERC721IncorrectOwner instead.\n\n ERC721NonexistentToken(uint256 tokenId)\n\nIndicates a tokenId whose owner is the zero address.\n\nUsage guidelines:\n\n The tokenId MUST BE a non-minted or burned token.\n\n ERC721IncorrectOwner(address sender, uint256 tokenId, address owner)\n\nIndicates an error related to the ownership over a particular token.\nUsed in transfers.\n\nUsage guidelines:\n\n sender MUST NOT be owner.\n MUST NOT be used for approval operations.\n\n ERC721InvalidSender(address sender)\n\nIndicates a failure with the token sender.\nUsed in transfers.\n\nUsage guidelines:\n\n RECOMMENDED for disallowed transfers from the zero address.\n MUST NOT be used for approval operations.\n MUST NOT be used for ownership or approval requirements.\n\n Use ERC721IncorrectOwner or ERC721InsufficientApproval instead.\n\n ERC721InvalidReceiver(address receiver)\n\nIndicates a failure with the token receiver.\nUsed in transfers.\n\nUsage guidelines:\n\n RECOMMENDED for disallowed transfers to the zero address.\n RECOMMENDED for disallowed transfers to non-ERC721TokenReceiver contracts or those that reject a transfer. (eg. returning an invalid response in onERC721Received).\n MUST NOT be used for approval operations.\n\n ERC721InsufficientApproval(address operator, uint256 tokenId)\n\nIndicates a failure with the operator’s approval.\nUsed in transfers.\n\nUsage guidelines:\n\n isApprovedForAll(owner, operator) MUST be false for the tokenId’s owner and operator.\n getApproved(tokenId) MUST not be operator.\n\n ERC721InvalidApprover(address approver)\n\nIndicates a failure with the owner of a token to be approved.\nUsed in approvals.\n\nUsage guidelines:\n\n RECOMMENDED for disallowed approvals from the zero address.\n MUST NOT be used for transfer operations.\n\n ERC721InvalidOperator(address operator)\n\nIndicates a failure with the operator to be approved.\nUsed in approvals.\n\nUsage guidelines:\n\n RECOMMENDED for disallowed approvals to the zero address.\n The operator MUST NOT be the owner of the approved token.\n MUST NOT be used for transfer operations.\n\n Use ERC721InsufficientApproval instead.\n\n ERC-1155\n\n ERC1155InsufficientBalance(address sender, uint256 balance, uint256 needed, uint256 tokenId)\n\nIndicates an error related to the current balance of a sender.\nUsed in transfers.\n\nUsage guidelines:\n\n balance MUST be less than needed for a tokenId.\n\n ERC1155InvalidSender(address sender)\n\nIndicates a failure with the token sender.\nUsed in transfers.\n\nUsage guidelines:\n\n RECOMMENDED for disallowed transfers from the zero address.\n MUST NOT be used for approval operations.\n MUST NOT be used for balance or allowance requirements.\n\n Use ERC1155InsufficientBalance or ERC1155MissingApprovalForAll instead.\n\n ERC1155InvalidReceiver(address receiver)\n\nIndicates a failure with the token receiver.\nUsed in transfers.\n\nUsage guidelines:\n\n RECOMMENDED for disallowed transfers to the zero address.\n RECOMMENDED for disallowed transfers to non-ERC1155TokenReceiver contracts or those that reject a transfer. (eg. returning an invalid response in onERC1155Received).\n MUST NOT be used for approval operations.\n\n ERC1155MissingApprovalForAll(address operator, address owner)\n\nIndicates a failure with the operator’s approval in a transfer.\nUsed in transfers.\n\nUsage guidelines:\n\n isApprovedForAll(owner, operator) MUST be false for the tokenId’s owner and operator.\n\n ERC1155InvalidApprover(address approver)\n\nIndicates a failure with the approver of a token to be approved.\nUsed in approvals.\n\nUsage guidelines:\n\n RECOMMENDED for disallowed approvals from the zero address.\n MUST NOT be used for transfer operations.\n\n ERC1155InvalidOperator(address operator)\n\nIndicates a failure with the operator to be approved.\nUsed in approvals.\n\nUsage guidelines:\n\n RECOMMENDED for disallowed approvals to the zero address.\n MUST be used for disallowed approvals to the owner itself.\n MUST NOT be used for transfer operations.\n\n Use ERC1155InsufficientApproval instead.\n\n ERC1155InvalidArrayLength(uint256 idsLength, uint256 valuesLength)\n\nIndicates an array length mismatch between ids and values in a safeBatchTransferFrom operation.\nUsed in batch transfers.\n\nUsage guidelines:\n\n idsLength MUST NOT be valuesLength.\n\n Parameter Glossary\n\n Name\n Description\n\n sender\n Address whose tokens are being transferred.\n\n balance\n Current balance for the interacting account.\n\n needed\n Minimum amount required to perform an action.\n\n receiver\n Address to which tokens are being transferred.\n\n spender\n Address that may be allowed to operate on tokens without being their owner.\n\n allowance\n Amount of tokens a spender is allowed to operate with.\n\n approver\n Address initiating an approval operation.\n\n tokenId\n Identifier number of a token.\n\n owner\n Address of the current owner of a token.\n\n operator\n Same as spender.\n\n *Length\n Array length for the prefixed parameter.\n\n Error additions\n\nAny addition to this EIP or implementation-specific errors (such as extensions) SHOULD follow the guidelines presented in the rationale section to keep consistency.\n\n Rationale\n\nThe chosen objectives for a standard for token errors are to provide context about the error, and to make moderate use of meaningful arguments (to maintain the code size benefits with respect to strings).\n\nConsidering this, the error names are designed following a basic grammatical structure based on the standard actions that can be performed on each token and the subjects involved.\n\n Actions and subjects\n\nAn error is defined based on the following actions that can be performed on a token and its involved subjects:\n\n Transfer: An operation in which a sender moves to a receiver any number of tokens (fungible balance and/or non-fungible token ids).\n Approval: An operation in which an approver grants any form of approval to an operator.\n\nThese attempt to exhaustively represent what can go wrong in a token operation. Therefore, the errors can be constructed by specifying which subject failed during an action execution, and prefixing with an error prefix.\n\nNote that the action is never seen as the subject of an error.\n\nIf a subject is called different on a particular token standard, the error should be consistent with the standard’s naming convention.\n\n Error prefixes\n\nAn error prefix is added to a subject to derive a concrete error condition.\nDevelopers can think about an error prefix as the why an error happened.\n\nA prefix can be Invalid for general incorrectness, or more specific like Insufficient for amounts.\n\n Domain\n\nEach error’s arguments may vary depending on the token domain. If there are errors with the same name and different arguments, the Solidity compiler currently fails with a DeclarationError.\n\nAn example of this is:\n\nInsufficientApproval(address spender, uint256 allowance, uint256 needed);\nInsufficientApproval(address operator, uint256 tokenId);\n\nFor that reason, a domain prefix is proposed to avoid declaration clashing, which is the name of the ERC and its corresponding number appended at the beginning.\n\nExample:\n\nERC20InsufficientApproval(address spender, uint256 allowance, uint256 needed);\nERC721InsufficientApproval(address operator, uint256 tokenId);\n\n Arguments\n\nThe selection of arguments depends on the subject involved, and it should follow the order presented below:\n\n Who is involved with the error (eg. address sender)\n What failed (eg. uint256 allowance)\n Why it failed, expressed in additional arguments (eg. uint256 needed)\n\nA particular argument may fall into overlapping categories (eg. Who may also be What), so not all of these will be present but the order shouldn’t be broken.\n\nSome tokens may need a tokenId. This is suggested to include at the end as additional information instead of as a subject.\n\n Error grammar rules\n\nGiven the above, we can summarize the construction of error names with a grammar that errors will follow:\n\n<Domain><ErrorPrefix><Subject>(<Arguments>);\n\nWhere:\n\n Domain: ERC20, ERC721 or ERC1155. Although other token standards may be suggested if not considered in this EIP.\n ErrorPrefix: Invalid, Insufficient, or another if it’s more appropriate.\n Subject: Sender, Receiver, Balance, Approver, Operator, Approval or another if it’s more appropriate, and must make adjustments based on the domain’s naming convention.\n Arguments: Follow the who, what and why order.\n\n Backwards Compatibility\n\nTokens already deployed rely mostly on revert strings and make use of require instead of custom errors. Even most of the newly deployed tokens since Solidity’s v0.8.4 release inherit from implementations using revert strings.\n\nThis EIP can not be enforced on non-upgradeable already deployed tokens, however, these tokens generally use similar conventions with small variations such as:\n\n including/removing the domain.\n using different error prefixes.\n including similar subjects.\n changing the grammar order.\n\nUpgradeable contracts MAY be upgraded to implement this EIP.\n\nImplementers and DApp developers that implement special support for tokens that are compliant with this EIP, SHOULD tolerate different errors emitted by non-compliant contracts, as well as classic revert strings.\n\n Reference Implementation\n\n Solidity\n\npragma solidity ^0.8.4;\n\n/// @title Standard ERC20 Errors\n/// @dev See https://eips.ethereum.org/EIPS/eip-20\n/// https://eips.ethereum.org/EIPS/eip-6093\ninterface ERC20Errors {\n error ERC20InsufficientBalance(address sender, uint256 balance, uint256 needed);\n error ERC20InvalidSender(address sender);\n error ERC20InvalidReceiver(address receiver);\n error ERC20InsufficientAllowance(address spender, uint256 allowance, uint256 needed);\n error ERC20InvalidApprover(address approver);\n error ERC20InvalidSpender(address spender);\n}\n\n/// @title Standard ERC721 Errors\n/// @dev See https://eips.ethereum.org/EIPS/eip-721\n/// https://eips.ethereum.org/EIPS/eip-6093\ninterface ERC721Errors {\n error ERC721InvalidOwner(address owner);\n error ERC721NonexistentToken(uint256 tokenId);\n error ERC721IncorrectOwner(address sender, uint256 tokenId, address owner);\n error ERC721InvalidSender(address sender);\n error ERC721InvalidReceiver(address receiver);\n error ERC721InsufficientApproval(address operator, uint256 tokenId);\n error ERC721InvalidApprover(address approver);\n error ERC721InvalidOperator(address operator);\n}\n\n/// @title Standard ERC1155 Errors\n/// @dev See https://eips.ethereum.org/EIPS/eip-1155\n/// https://eips.ethereum.org/EIPS/eip-6093\ninterface ERC1155Errors {\n error ERC1155InsufficientBalance(address sender, uint256 balance, uint256 needed, uint256 tokenId);\n error ERC1155InvalidSender(address sender);\n error ERC1155InvalidReceiver(address receiver);\n error ERC1155MissingApprovalForAll(address operator, address owner)\n error ERC1155InvalidApprover(address approver);\n error ERC1155InvalidOperator(address operator);\n error ERC1155InvalidArrayLength(uint256 idsLength, uint256 valuesLength);\n}\n\n Security Considerations\n\nThere are no known signature hash collisions for the specified errors.\n\nTokens upgraded to implement this EIP may break assumptions in other systems relying on revert strings.\n\nOffchain applications should be cautious when dealing with untrusted contracts that may revert using these custom errors. For instance, if a user interface prompts actions based on error decoding, malicious contracts could exploit this to encourage untrusted and potentially harmful operations.\n\n Copyright\n\nCopyright and related rights waived via CC0.\n\n Citation\n Please cite this document as:\n\n Ernesto García (@ernestognw), Francisco Giordano (@frangio), Hadrien Croubois (@Amxx), \"ERC-6093: Custom errors for commonly-used tokens,\" Ethereum Improvement Proposals, no. 6093, December 2022. Available: https://eips.ethereum.org/EIPS/eip-6093.","tokens":3975,"squid":"spider-05","role":"Spec Spider","at":1791342860933,"hash":"7e04fd640f9d064deb69769b947ef23e01e08e00"}
{"url":"https://developers.metaplex.com/","domain":"developers.metaplex.com","title":"Metaplex Developer Hub","text":"TokensCreate and launch tokens on Solana. Run token generation events (TGE), fair launches, and manage fungible tokens.Launch TokenFair launch tokens on Solana with Genesis.Create A TokenCreate a fungible SPL token with metadata.Mint TokensMint fungible tokens to a wallet address.Transfer TokensTransfer tokens between wallet addresses.Update A TokenUpdate the metadata of a fungible token.Burn TokensBurn fungible tokens from circulation.AgentsCreate, register, and run agents. Use the Metaplex Agent skills and agent registry to manage your autonomous agents.Agent OnboardingOnboarding guide for AI agents integrating with Metaplex programs.SkillMetaplex knowledge base for AI agents.Mint an AgentMint an agent and register its Identity PDA.Register an AgentRegister an agent on the Metaplex registry.Read Agent DataRead and verify agent identity on Solana.Agent FinanceCapitalize and govern your AI agent through its own onchain token.Agent CommerceHow AI agents earn revenue, pay for services, and transact onchain.Create an Agent TokenLaunch a token from an agent's onchain wallet.Run an AgentDelegate execution to run an agent on Solana.NoriPay-as-you-go LLM, image, and RPC services for agents, metered in SOL.NFTsCreate, manage, and trade NFTs on Solana using Metaplex Core and other NFT standards.Create A NFTMint an NFT on Solana with Metaplex Core.Read A NFTFetch NFT metadata from Solana via the DAS API.Update A NFTUpdate NFT metadata or royalties on Solana.Burn A NFTBurn an NFT and reclaim its rent on Solana.Transfer A NFTTransfer an NFT between wallets on Solana.Smart ContractsProduction-ready on-chain programs for NFTs, tokens, and digital assets on Solana.Token MetadataSPL token creation with onchain metadata.CoreNext-gen NFT standard with a composable plugin system.Agent RegistryOnchain agent identity and execution delegation.MPL-3643Permissioned token standard for RWAs.Bubblegum v2Compressed NFTs at a fraction of regular costs.Core Candy MachineNFT launchpad for MPL Core.MPL-HybridSwap NFT traits for fungible tokens and back.MPL-DistroMerkle-based token distributions.GenesisLaunch tokens onchain.InscriptionInscribe permanent data into Solana state.Bubblegum v1Compressed NFTs on Solana. Use v2 for new projects.Deprecated: Candy Machine · Token Auth Rules · Fusion · Hydra · Auction House · Fixed Price Sale · Gumdrop · Token EntanglerDev ToolsSDKs, CLIs, and APIs to build, test, and deploy digital asset applications on Solana.DAS APIQuery Solana digital assets at scale.Metaplex APIPublic REST APIUmiJS client for Solana RPC, wallets, and signers.CLICLI to mint, transfer, and manage assets.ShankIDL generation from Rust Solana programs.AmmanLocal Solana validator and test toolkit.Deprecated: Sugar · Solita · Beet · Cusper · Rust Bin · Mobile SDKsSolanaSolanaGuides for the Solana Blockchain","tokens":708,"squid":"dotcat","role":"Tooling Spider","at":1791342942585,"hash":"95eccc84f43be6cfbbb1bdf6668629267c6e6905"}
{"url":"https://docs.switchboard.xyz/how-it-works/switchboard-protocol/re-staking/what-are-vault-receipt-tokens-vrts","domain":"docs.switchboard.xyz","title":"What are Vault Receipt Tokens (VRTs)? | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.Vault Receipt Tokens (VRTs) are synthetic tokens representing your staked assets in a network. They are akin to receipts you get when you stake your cryptocurrency that you can use elsewhere on-chain. Instead of just locking up your tokens, VRTs give you more flexibility. They allow the network to manage risks better, and some systems even let you stake different types of tokens, giving you more choices. Switchboard uses VRTs within its restaking system, which is modelled after the Jito Node Consensus Network (NCN). To better understand it, let's clarify their role in how Switchboard is set up.Switchboard and VRTs:To maximise the security of the Switchboard protocol, its staking mechanisms are built on the Jito NCN restaking system. This means Switchboard operates its own NCN to secure key actions performed by oracles within the protocol:Oracle Queues: In Switchboard, each oracle queue (a group of oracles) is linked to its own Jito NCN.Oracles as Nodes: Individual oracles within the queue act as nodes (operators) in the NCN.To ensure these oracle actions are secure the Switchboard’s NCN has associated token vaults. These token vaults are where stakers stake their tokens, for example, SWTCH. When you stake, you receive a Vault Receipt Token (VRT) representing your staked tokens in Switchboard, such as svSWTCH.The Role of svSWTCH:The svSWTCH token has two main roles within Switchboard:Governance: It's the governance token, allowing stakers to participate in decisions about the network.Economic Incentive: It ensures oracles operate reliably. Oracle operators need to have a minimum amount of svSWTCH delegated in their operating wallet to participate in the network. The prioritisation and workload distribution among oracles within the network will be determined by a combination of their performance metrics and total stake.PreviousWhat are Node Consensus Networks (NCNs)?NextThe Node Partner ProgramLast updated 1 year ago","tokens":510,"squid":"spider-08","role":"Oracle Spider","at":1791342944573,"hash":"d974b2649bbaae3a58fdaa13b20093fa8a5a1059"}
{"url":"https://www.metaplex.com/docs/api","domain":"metaplex.com","title":"Metaplex API - Public REST API Reference | Metaplex","text":"The Metaplex API is the public REST API at api.metaplex.com. It serves Genesis launch data, builds launch-creation transactions, and exposes the Metaplex Agent Registry — browsing agents, serving A2A AgentCards, and building agent wallet transactions. It is the same API that powers the metaplex.com launch platform — the endpoints documented here are what the site itself runs on. SummaryThe Metaplex API provides public HTTP access to Genesis launch data, launch creation, and the agent registry — no SDK or authentication required.Query launches by genesis address, token mint, or browse all active launchesCreate and register new Genesis launchesBrowse and search the agent registry; fetch per-agent A2A AgentCardsBuild agent mint, fund, and withdraw transactionsPublic REST API at https://api.metaplex.com/v1 — no authentication requiredPowers the metaplex.com launch platform — integrators consume the same endpoints the platform usesSupports Solana mainnet (default) and devnet via network query parameterMachine-readable OpenAPI 3.1 specification: YAML (canonical) / JSON, discoverable via the RFC 9727 API catalogBase URLhttps://api.metaplex.com/v1\nNetwork SelectionBy default, the API returns data from Solana mainnet. To query devnet launches instead, add the network query parameter:?network=solana-devnet\nExample:# Mainnet (default)\ncurl https://api.metaplex.com/v1/launches/7nE9GvcwsqzYcPUYfm5gxzCKfmPqi68FM7gPaSfG6EQN\n\n# Devnet\ncurl \"https://api.metaplex.com/v1/launches/7nE9GvcwsqzYcPUYfm5gxzCKfmPqi68FM7gPaSfG6EQN?network=solana-devnet\"\nAuthenticationNo authentication is required. The API is public with rate limits.Launch EndpointsMethodEndpointDescriptionGET/launches/{genesis_pubkey}Get launch data by genesis addressGET/tokens/{mint}Get all launches for a token mintGET/launchesList launches with optional filtersGET/launches?spotlight=trueGet featured spotlight launchesPOST/launches/createBuild on-chain transactions for a new launchPOST/launches/registerRegister a confirmed launch for listingPOST/twitter/verifyVerify Twitter account ownership for launch registrationPOST/creator-rewards/claimBuild a creator rewards claim transactionThe POST endpoints (/launches/create and /launches/register) are used together to create new token launches. For most use cases, the SDK API Client provides a simpler interface that wraps both endpoints. Real-time on-chain launch state can be read directly with the SDK chain methods fetchBucketState and fetchDepositState.Agent EndpointsMethodEndpointDescriptionGET/agentsList and search registered agents (paginated)GET/agents/{address}Get a single agent with tokens and metadataGET/agents/{address}/agent-card.jsonGet the hosted A2A AgentCardPOST/agents/mintBuild an agent mint + registration transactionPOST/agents/{address}/fundBuild a SOL transfer to the agent's walletPOST/agents/{address}/withdrawBuild a withdrawal from the agent's wallet (owner only)For minting agents with a guided walkthrough, see Mint an Agent.Transaction-Building EndpointsPOST endpoints that build transactions never hold user keys and never submit transactions. Each returns one or more base64-serialized transactions plus the blockhash they were built against; your application deserializes them, has the user's wallet sign, and submits to the network.Error CodesCodeDescription400Bad request - invalid parameters403Not authorized for the operation (e.g. withdrawing from an agent you don't own)404Launch, token, or agent not found429Rate limit exceeded500Internal server errorResponse EnvelopesTwo envelope conventions are in use, reflecting the API's evolution:Launch read endpoints (/launches*, /tokens/*, /creator-rewards/claim) wrap results in data and errors in error.message:{ \"data\": { \"…\": \"…\" } }\n{ \"error\": { \"message\": \"Launch not found\" } }\nAgent endpoints, launch write endpoints, and /twitter/verify use a success discriminator:{ \"success\": true, \"…\": \"…\" }\n{ \"success\": false, \"error\": \"Agent not found\" }\nThe exception is /agents/{address}/agent-card.json, which returns raw AgentCard JSON with no envelope so A2A clients can consume it directly. Each endpoint page documents its exact shape, as does the OpenAPI specification.Machine-Readable SpecificationThe full API contract is published as an OpenAPI 3.1 document, generated directly from the API's request validators (so it cannot drift from the implementation):FormatURLYAML (canonical)https://api.metaplex.com/v1/openapi.yamlJSONhttps://api.metaplex.com/v1/openapi.jsonCurrent-version aliaseshttps://api.metaplex.com/openapi.json / openapi.yamlRFC 9727 API cataloghttps://api.metaplex.com/.well-known/api-catalogImport the spec into Postman, Swagger UI, code generators, or agent frameworks to get typed clients and callable tools for every endpoint.NotesThe API is rate limited. If you receive a 429 response, reduce your request frequency.All date fields (startTime, endTime, graduatedAt, lastActivityAt) are returned as ISO 8601 strings. endTime is null for bonding curve launches, which have no end time.The default network is solana-mainnet. Devnet data is available via ?network=solana-devnet.For POST endpoints, the SDK API Client is recommended as it wraps both /launches/create and /launches/register.Shared TypesTypeScriptinterface Launch {\n launchPage: string;\n mechanic: string;\n genesisAddress: string;\n spotlight: boolean;\n startTime: string;\n endTime: string | null;\n status: 'upcoming' | 'live' | 'graduated' | 'ended';\n heroUrl: string | null;\n graduatedAt: string | null;\n lastActivityAt: string;\n type: 'launchpool' | 'presale' | 'bondingCurve' | 'auction' | 'custom';\n}\n\ninterface BaseToken {\n address: string;\n name: string;\n symbol: string;\n image: string;\n description: string;\n}\n\ninterface Socials {\n x?: string;\n telegram?: string;\n discord?: string;\n}\n\ninterface ErrorResponse {\n error: {\n message: string;\n };\n}\nRustuse serde::{Deserialize, Serialize};\n\n#[derive(Debug, Serialize, Deserialize)]\n#[serde(rename_all = \"camelCase\")]\npub struct Launch {\n pub launch_page: String,\n pub mechanic: String,\n pub genesis_address: String,\n pub spotlight: bool,\n pub start_time: String,\n pub end_time: Option<String>,\n pub status: String,\n pub hero_url: Option<String>,\n pub graduated_at: Option<String>,\n pub last_activity_at: String,\n #[serde(rename = \"type\")]\n pub launch_type: String,\n}\n\n#[derive(Debug, Serialize, Deserialize)]\n#[serde(rename_all = \"camelCase\")]\npub struct BaseToken {\n pub address: String,\n pub name: String,\n pub symbol: String,\n pub image: String,\n pub description: String,\n}\n\n#[derive(Debug, Serialize, Deserialize)]\npub struct Socials {\n pub x: Option<String>,\n pub telegram: Option<String>,\n pub discord: Option<String>,\n}\n\n#[derive(Debug, Serialize, Deserialize)]\npub struct ApiError {\n pub message: String,\n}\n\n#[derive(Debug, Serialize, Deserialize)]\npub struct ErrorResponse {\n pub error: ApiError,\n}\nAdd these dependencies to your Cargo.toml:[dependencies]\nreqwest = { version = \"0.12\", features = [\"json\"] }\ntokio = { version = \"1\", features = [\"full\"] }\nserde = { version = \"1\", features = [\"derive\"] }\nGlossaryTermDefinitionGenesis AddressA PDA (Program Derived Address) that uniquely identifies a specific launch campaignBase TokenThe token being launched, identified by its mint addressLaunch PageThe URL where users can participate in a launchMechanicThe allocation mechanism used for the launch (e.g., launchpoolV2, presaleV2, bondingCurveV2)Launch TypeThe underlying mechanism of the launch: launchpool, presale, or bondingCurveSpotlightA platform-curated flag indicating a featured launchStatusThe current state of a launch: upcoming, live, graduated, or endedSocialsSocial media links (X/Twitter, Telegram, Discord) associated with a tokenLaunchDataThe response wrapper containing launch, baseToken, website, and socialsTokenDataThe response wrapper for token queries, containing a launches array plus baseToken, website, and socials","tokens":1978,"squid":"dotcat","role":"Tooling Spider","at":1791342952773,"hash":"0a5d0a11dc9557c6b9e235477c0f63e3130a8314"}
{"url":"https://docs.phantom.com/phantom-deeplinks/handling-sessions","domain":"docs.phantom.com","title":"Handle sessions - Phantom developer documentation","text":"When a user connects to Phantom for the first time, Phantom will return a session param that represents the user’s connection. The app should pass this session param back to Phantom on all subsequent provider methods. It is the app’s responsibility to store this session.\nSessions do not expire. Once a user has connected with Phantom, the corresponding app can indefinitely make requests such as SignTransaction and SignMessage without prompting the user to re-connect with Phantom. Apps will still need to re-connect to Phantom after a disconnect event or an invalid session.\n​Session structure\nThe entire session param is encoded in base58. A session should contain the following data:\n\nJSON Data Signature: A base58 signature of the JSON data that is 64 bytes. Phantom will check the signature against the actual message that was signed.\nJSON Data: A JSON object with the following fields:\n\napp_url (string): A URL that was provided during the initial connection request. This URL is stored in the session for validation purposes and can be checked against the blocklist.\ntimestamp (number): The timestamp at which the user approved the connection. At the time of this writing, sessions do not expire.\nchain (string): The chain that the user connected to at the start of the session. Sessions can’t be used across two different chains with the same keypair (for example, the user can’t connect to Solana and then sign on Ethereum). At the time of this writing, Phantom only supports solana.\ncluster (string) (optional): The approved cluster that the app and user initially connected to. Solana-only. Can be either: mainnet-beta, testnet, or devnet. Defaults to mainnet-beta.\n\nAbout app_url in sessions: The app_url stored in the session token is used for validation purposes only. App metadata (such as title, icon, and favicon) is fetched from the redirect_link parameter during the initial connection request, not from the app_url stored in the session. For more information, see the Connect method documentation.\n​Decode sessions\nPhantom will decode and validate the session param on every request. To decode the session, we decode it with bs58, slice off the first 64 bytes of the signature, and then treat the rest as JSON data. We then sign the JSON data again with the same keypair and compare that signature against the signature in the session. If the signatures are the same, the session is valid. Otherwise, we conclude that the session has been faked, as the signature does not belong to the keypair it claims it does.\nCalling nacl.sign.open conveniently verifies and returns the original object. For more information, please review Encryption resources.\nAfter we determine that the session is valid, we still need to ensure that the JSON fields line up with what we expect. An app could give a session for pubkey A when the user is currently using pubkey B in Phantom. In such a scenario, that session should not allow an app to request signatures. Instead, the app must issue a new connect request or use the correct session.\n// Encoding a session\nconst privateKey = ...;\nconst sessionData = JSON.stringify({\n \"app_id\": \"APP_ID\",\n \"chain\": \"CHAIN\",\n \"cluster\": \"CLUSTER\",\n \"timestamp\": 1644954984,\n});\nconst bytes = Buffer.from(sessionData, \"utf-8\");\n\n// tweetnacl-js formats signature in format <signature><sessionData>\nconst signature = bs58.encode(nacl.sign(bytes, privateKey));\n\n// Decoding a session\nconst publicKey = ...;\nconst verifiedSessionData = nacl.sign.open(bs58.decode(signature), publicKey.toBytes());\nif (!verifiedSessionData) throw new Error(`This session was not signed by ${publicKey}`);\n\n​Invalid sessions\nWhile sessions do not expire, there are a number of reasons why a session could still be deemed invalid:\n\nIt was not signed by the current wallet keypair. This could mean that the session is entirely fake, or that it was signed by another keypair in the user’s wallet.\nIt was signed by the current wallet keypair, but the session’s JSON data does not pass muster. There are a few reasons why this might occur:\n\nThe user switched chains (or possibly networks).\nThe app_url could be blocked if malicious. For more information, see Blocklist.\n\nYou must pass the session token for all requests or Phantom will redirect the user back to your app and a new session will be created.Was this page helpful?","tokens":1085,"squid":"spider-10","role":"Tooling Spider","at":1791342954066,"hash":"a2e0ee56b7a01418c7309995004215aede9b3aca"}
{"url":"https://docs.switchboard.xyz/how-it-works/switchboard-protocol/re-staking/the-switchboard-ncn","domain":"docs.switchboard.xyz","title":"The Switchboard NCN | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.How does Switchboard use (re)Staking to secure the Switchboard network?Switchboard oracles are a scarce and valuable resource. To protect the network from abuse (e.g., spam, denial-of-service attempts), and to maximize oracle performance, the network uses a staking-based mechanism powered by the Jito NCN framework.Incentivizing Oracle Performance with StakeAlthough Switchboard oracles operate within secure Trusted Execution Environments (TEEs), they are still subject to real-world limitations like CPU load and network throughput. To incentivize optimal uptime, responsiveness, and resource management, Switchboard integrates with Jito’s staking vaults.Stakers can delegate their stake to oracles. High-performing oracles will receive more stake over time, creating a reward feedback loop. Oracles with the most stake are prioritized in routing for new price requests, ensuring that the most performant nodes serve critical traffic.Managing Usage Limits with StakeTo prevent misuse of the network (e.g., users flooding price requests), Switchboard enforces a default rate limit of 20 requests per second (RPS) per user.Users can raise this limit by staking $SWTCH tokens. When submitting a request, users can sign it with a wallet that holds stake, proving their economic commitment to the network. The more stake held, the higher the RPS limit granted to that user. This ties resource consumption directly to network value.SummaryBy integrating staking into both supply (oracles) and demand (users), Switchboard ensures a secure, performant, and economically aligned oracle network.PreviousThe Node Partner ProgramNextRunning a Switchboard OracleLast updated 1 year ago","tokens":442,"squid":"spider-08","role":"Oracle Spider","at":1791342954637,"hash":"d30cf422547a04c8a9025af6b8979e79b8ad7e8a"}
{"url":"https://www.metaplex.com/docs/api/get-launches-by-token","domain":"metaplex.com","title":"Metaplex API - Get Launches by Token | REST API | Metaplex","text":"Retrieve all launches associated with a token mint address. A token can have multiple launch campaigns, so the response returns an array of launches. SummaryFetch all launches linked to a token mint address. Returns an array of launches because a single token can have multiple launch campaigns using different genesisIndex values.Requires the token mint public key as a path parameterReturns a TokenData object containing a launches arrayIncludes base token metadata and social links alongside the launchesSupports mainnet (default) and devnet via network query parameterQuick ReferenceItemValueMethodGETPath/tokens/{token_address}AuthNoneResponseTokenData (contains launches array)PaginationNoneEndpointGET /tokens/{token_address}\nPath ParametersParameterTypeRequiredDescriptiontoken_addressstringYesThe token mint public keyQuery ParametersParameterTypeRequiredDescriptionnetworkstringNoNetwork to query. Default: solana-mainnet. Use solana-devnet for devnet.Example Requestcurl https://api.metaplex.com/v1/tokens/EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v\nResponse{\n \"data\": {\n \"launches\": [\n {\n \"launchPage\": \"https://example.com/launch/mytoken\",\n \"mechanic\": \"launchpoolV2\",\n \"genesisAddress\": \"7nE9GvcwsqzYcPUYfm5gxzCKfmPqi68FM7gPaSfG6EQN\",\n \"spotlight\": false,\n \"startTime\": \"2026-01-15T14:00:00.000Z\",\n \"endTime\": \"2026-01-15T18:00:00.000Z\",\n \"status\": \"graduated\",\n \"heroUrl\": \"launches/abc123/hero.webp\",\n \"graduatedAt\": \"2026-01-15T18:05:00.000Z\",\n \"lastActivityAt\": \"2026-01-15T17:45:00.000Z\",\n \"type\": \"launchpool\"\n }\n ],\n \"baseToken\": {\n \"address\": \"EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v\",\n \"name\": \"My Token\",\n \"symbol\": \"MTK\",\n \"image\": \"https://example.com/token-image.png\",\n \"description\": \"A community-driven token for the example ecosystem.\"\n },\n \"website\": \"https://example.com\",\n \"socials\": {\n \"x\": \"https://x.com/mytoken\",\n \"telegram\": \"https://t.me/mytoken\",\n \"discord\": \"https://discord.gg/mytoken\"\n }\n }\n}\nResponse TypeSee Shared Types for Launch, BaseToken, and Socials definitions.TypeScriptinterface TokenResponse {\n data: {\n launches: Launch[];\n baseToken: BaseToken;\n website: string;\n socials: Socials;\n };\n}\nRust#[derive(Debug, Serialize, Deserialize)]\n#[serde(rename_all = \"camelCase\")]\npub struct TokenData {\n pub launches: Vec<Launch>,\n pub base_token: BaseToken,\n pub website: String,\n pub socials: Socials,\n}\n\n#[derive(Debug, Serialize, Deserialize)]\npub struct TokenResponse {\n pub data: TokenData,\n}\nUsage ExamplesTypeScriptconst response = await fetch(\n \"https://api.metaplex.com/v1/tokens/EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v\"\n);\nconst { data }: TokenResponse = await response.json();\nconsole.log(data.launches.length); // Number of launch campaigns\nconsole.log(data.baseToken.symbol); // \"MTK\"\nRustlet response: TokenResponse = reqwest::get(\n \"https://api.metaplex.com/v1/tokens/EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v\"\n)\n.await?\n.json()\n.await?;\n\nprintln!(\"{} launches found\", response.data.launches.len());\nNotesA token can have multiple launches using different genesisIndex values. The response returns all associated launch campaigns.Returns 404 if the token mint address is not found.The mechanic field indicates the allocation mechanism (e.g., launchpoolV2, presaleV2, bondingCurveV2). The type field indicates the underlying launch mechanism (launchpool, presale, or bondingCurve).","tokens":839,"squid":"dotcat","role":"Tooling Spider","at":1791342962733,"hash":"e1e4efe74b796cde7fdcc647819fd0c8922fdcbb"}
{"url":"https://docs.phantom.com/phantom-deeplinks/provider-methods/disconnect","domain":"docs.phantom.com","title":"Disconnect - Phantom developer documentation","text":"After an initial Connect event has taken place, an app may disconnect from Phantom at anytime. Once disconnected, Phantom will reject all signature requests until another connection is established.\n​Base URL\nhttps://phantom.com/ul/v1/disconnect\n\n​Query string parameters\n\ndapp_encryption_public_key (required): The original encryption public key used from the app side for an existing Connect session.\n\nnonce (required): A nonce used for encrypting the request, encoded in base58.\n\nredirect_link (required): The URI where Phantom should redirect the user upon completion. For more details, see Specify redirects. URL-encoded.\n\npayload (required): An encrypted JSON string with the following fields:\n{\n \"session\": \"...\", // token received from the connect method\n}\n\nsession (required): The session token received from the Connect method. For more details, see Handle sessions.\n\n​Returns\n​Approve\nNo query params returned.\n​Reject\nAn errorCode and errorMessage as query parameters. For a full list of possible error codes, see Errors.\n{\n \"errorCode\": \"...\",\n \"errorMessage\": \"...\"\n}\n\n​Example\nRefer to the disconnect method implemented in our React Native demo application.Was this page helpful?","tokens":298,"squid":"spider-10","role":"Tooling Spider","at":1791342964180,"hash":"6975c6d1391ad38dd2637c9cf1ae8c2a0081adc6"}
{"url":"https://docs.switchboard.xyz/docs-by-chain/solana-svm/price-feeds/basic-price-feed","domain":"docs.switchboard.xyz","title":"Basic Price Feed Tutorial | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.Example Code: The complete working example for this tutorial is available at sb-on-demand-examples/solana/feeds/basicThis tutorial walks you through the simplest way to integrate Switchboard oracle price feeds into your Solana program. You'll learn how to read verified price data using Switchboard's managed update system.Version source of truth: SDK Version MatrixWhat You'll BuildA minimal Anchor program that reads price feed data from a Switchboard oracle account, plus a TypeScript client that fetches fresh oracle data and calls your program.PrerequisitesRust and Cargo installedSolana CLI installed and configuredNode.js 18+ and npm/pnpmBasic understanding of Anchor frameworkA Solana keypair with SOL (devnet or mainnet)Key ConceptsBefore diving into the code, let's understand how Switchboard's managed update system works.Managed UpdatesSwitchboard uses a managed update system where oracle data is stored in canonical accounts derived deterministically from feed IDs. This means:No manual account management neededSame feed IDs always produce the same oracle account addressAccounts are created automatically if they don't existThe Two-Instruction PatternEvery Switchboard oracle update requires two instructions in sequence:Ed25519 Signature Verification - Verifies the oracle operator's signatureQuote Program Storage - Stores the verified data in the canonical oracle accountYour program then reads from this oracle account as a third instruction in the same transaction.This is the current path for new Solana/SVM feed-hash integrations. The older PullFeed.fetchUpdateIx(...) path writes classic PullFeed accounts and depends on queue/gateway support for that legacy flow. Use managed quote-program updates unless you are maintaining an existing classic PullFeed integration.Feed IDsEach price feed has a unique 32-byte hex identifier. You can find feed IDs in the Switchboard Explorer.Example: BTC/USD feed ID:4cd1cad962425681af07b9254b7d804de3ca3446fbfd1371bb258d2c75059812The On-Chain ProgramHere's the complete Anchor program that reads oracle data:use anchor_lang::prelude::*;\nuse switchboard_on_demand::{\n SlotHashes, Instructions, default_queue, SwitchboardQuoteExt, SwitchboardQuote\n};\n\ndeclare_id!(\"9kVBXoCrvZgKYWTJ74w3S8wAp7daEB7zpG7kwiXxkCVN\");\n\n#[program]\npub mod basic_oracle_example {\n use super::*;\n\n /// Read and verify oracle data from the managed oracle account\n pub fn read_oracle_data(ctx: Context<ReadOracleData>) -> Result<()> {\n // Access the oracle data directly\n let feeds = &ctx.accounts.quote_account.feeds;\n\n // Calculate staleness (how old is the data?)\n let current_slot = ctx.accounts.sysvars.clock.slot;\n let quote_slot = ctx.accounts.quote_account.slot;\n let staleness = current_slot.saturating_sub(quote_slot);\n\n msg!(\"Number of feeds: {}\", feeds.len());\n msg!(\"Quote slot: {}, Current slot: {}\", quote_slot, current_slot);\n msg!(\"Staleness: {} slots\", staleness);\n\n // Process each feed\n for (i, feed) in feeds.iter().enumerate() {\n msg!(\"Feed {}: ID = {}\", i, feed.hex_id());\n msg!(\"Feed {}: Value = {}\", i, feed.value());\n\n // Your business logic here!\n // - Store the price in your program state\n // - Trigger events based on price changes\n // - Use the price for calculations\n }\n\n msg!(\"Successfully read {} oracle feeds!\", feeds.len());\n Ok(())\n }\n}\n\n/// Account context for reading oracle data\n#[derive(Accounts)]\npub struct ReadOracleData<'info> {\n /// The canonical oracle account containing verified quote data\n /// The address constraint ensures this is the correct canonical account\n #[account(address = quote_account.canonical_key(&default_queue()))]\n pub quote_account: Box<Account<'info, SwitchboardQuote>>,\n\n /// System variables required for quote verification\n pub sysvars: Sysvars<'info>,\n}\n\n/// System variables required for oracle verification\n#[derive(Accounts)]\npub struct Sysvars<'info> {\n pub clock: Sysvar<'info, Clock>,\n pub slothashes: Sysvar<'info, SlotHashes>,\n pub instructions: Sysvar<'info, Instructions>,\n}Code WalkthroughImportsuse switchboard_on_demand::{\n SlotHashes, Instructions, default_queue, SwitchboardQuoteExt, SwitchboardQuote\n};SwitchboardQuote - The account type that holds oracle dataSwitchboardQuoteExt - Extension trait for accessing feed valuesdefault_queue() - Returns the default Switchboard queue for the current networkSlotHashes, Instructions - Sysvar types needed for verificationThe InstructionThe read_oracle_data instruction:Accesses feed data from quote_account.feedsCalculates staleness by comparing the quote slot to the current slotIterates through feeds to extract values using feed.hex_id() and feed.value()Account Validation#[account(address = quote_account.canonical_key(&default_queue()))]\npub quote_account: Box<Account<'info, SwitchboardQuote>>,This constraint ensures the passed account is the legitimate canonical oracle account for the contained feeds. It prevents malicious actors from passing fake oracle data.SysvarsThe program requires three sysvars:Clock - For checking the current slotSlotHashes - For quote verificationInstructions - For verifying the Ed25519 instruction was includedThe TypeScript ClientHere's the complete client code that fetches oracle data and calls your program:import * as sb from \"@switchboard-xyz/on-demand\";\nimport { OracleQuote } from \"@switchboard-xyz/on-demand\";\n\nconst FEED_ID = \"4cd1cad962425681af07b9254b7d804de3ca3446fbfd1371bb258d2c75059812\";\n\nasync function main() {\n // Step 1: Load environment (auto-detects network)\n const { program, keypair, connection, crossbar, queue } =\n await sb.AnchorUtils.loadEnv();\n\n console.log(\"Queue:\", queue.pubkey.toBase58());\n console.log(\"Network:\", crossbar.getNetwork());\n\n // Step 2: Derive the canonical oracle account from feed ID\n const [quoteAccount] = OracleQuote.getCanonicalPubkey(\n queue.pubkey,\n [FEED_ID]\n );\n console.log(\"Quote Account:\", quoteAccount.toBase58());\n\n // Step 3: Simulate the feed to see current value\n const simResult = await crossbar.simulateFeed(FEED_ID);\n console.log(\"Simulated feed result:\", simResult);\n\n // Step 4: Create managed update instructions\n const updateInstructions = await queue.fetchManagedUpdateIxs(\n crossbar,\n [FEED_ID],\n {\n variableOverrides: {},\n payer: keypair.publicKey,\n }\n );\n\n // Step 5: Create your program's instruction\n const readOracleIx = await program.methods\n .readOracleData()\n .accounts({\n quoteAccount: quoteAccount,\n // Sysvars are added automatically by Anchor\n })\n .instruction();\n\n // Step 6: Build and send the transaction\n const tx = await sb.asV0Tx({\n connection,\n ixs: [...updateInstructions, readOracleIx],\n signers: [keypair],\n computeUnitPrice: 20_000,\n computeUnitLimitMultiple: 1.1,\n });\n\n // Step 7: Simulate and send\n const sim = await connection.simulateTransaction(tx);\n console.log(sim.value.logs?.join(\"\\n\"));\n\n if (!sim.value.err) {\n const sig = await connection.sendTransaction(tx);\n console.log(\"Transaction:\", sig);\n }\n}\n\nmain();Client Code WalkthroughStep 1: Load Environmentconst { program, keypair, connection, crossbar, queue } =\n await sb.AnchorUtils.loadEnv();This auto-detects whether you're on mainnet or devnet based on your RPC endpoint and loads the appropriate Switchboard queue.Step 2: Derive Canonical Accountconst [quoteAccount] = OracleQuote.getCanonicalPubkey(queue.pubkey, [FEED_ID]);The canonical account is a PDA derived from the queue public key and feed IDs. This ensures the same inputs always produce the same account address.Step 3: Simulate Feed (Optional)const simResult = await crossbar.simulateFeed(FEED_ID);You can simulate a feed to see what value the oracle would return before submitting a transaction.Step 4: Create Update Instructionsconst updateInstructions = await queue.fetchManagedUpdateIxs(\n crossbar,\n [FEED_ID],\n {\n variableOverrides: {},\n payer: keypair.publicKey,\n }\n);This returns an array of instructions:Ed25519 signature verification instructionQuote program verified_update instructionStep 5-7: Build and Send TransactionThe transaction includes:Ed25519 verification instructionQuote program update instructionYour program's instructionAll three must be in the same transaction for the verification to work.Running the Example1. Clone the Examples Repositorygit clone https://github.com/switchboard-xyz/sb-on-demand-examples\ncd sb-on-demand-examples/solana/feeds/basic2. Install Dependenciesnpm install3. Configure Your EnvironmentCreate or update your Solana CLI config to point to devnet:solana config set --url devnetEnsure your keypair has SOL:solana airdrop 24. Build and Deploy the ProgramThis step is optional only if you want to smoke-test the managed update flow by itself.If you want the example to invoke read_oracle_data after the quote update, you must deploy the sample Anchor program first:anchor build\nanchor deploy5. Run the Example# Using default BTC/USD feed\nnpm run update\n\n# Using a custom feed ID\nnpm run update -- --feedId YOUR_FEED_ID_HEREnpm run update always fetches a fresh managed update and submits the Switchboard transaction.If the example program is not deployed, the script logs that it skipped the consumer-program step and only updates the quote account. If the program is deployed, the same command also appends the read_oracle_data instruction.Expected OutputIf the example program is not deployed yet, you should see output like:ℹ️ Skipping crank: basic_oracle_example program not deployed\n✅ Transaction sent: 5c...\n✅ Managed update confirmed\nℹ️ The quote account was updated without the example consumer instructionWith the example program deployed, you should also see logs like:Queue: FdRnYujMnYbAJp5P2rkEYZCbF2TKs2D2yXZ7MYq89Hms\nNetwork: devnet\nQuote Account: 8Js7NsQ7sF3WLJN3JC4LJQGz8kHiEJwZ7sdGTtJC5J7d\nSimulated feed result: { value: 97234.5, ... }\nNumber of feeds: 1\nQuote slot: 123456789, Current slot: 123456790\nStaleness: 1 slots\nFeed 0: ID = 4cd1cad962425681af07b9254b7d804de3ca3446fbfd1371bb258d2c75059812\nFeed 0: Value = 97234.50\nSuccessfully read 1 oracle feeds!Adding to Your ProgramTo integrate Switchboard into your own program:1. Add DependenciesIn your Cargo.toml:[dependencies]\nswitchboard-on-demand = { version = \"0.13.0\", features = [\"anchor\", \"devnet\"] }The example program enables the devnet feature. If you are targeting a different Solana cluster, swap the cluster feature to match your deployment.2. Add the Account Structuse switchboard_on_demand::{\n SlotHashes, Instructions, default_queue, SwitchboardQuoteExt, SwitchboardQuote\n};\n\n#[derive(Accounts)]\npub struct YourInstruction<'info> {\n #[account(address = quote_account.canonical_key(&default_queue()))]\n pub quote_account: Box<Account<'info, SwitchboardQuote>>,\n\n pub clock: Sysvar<'info, Clock>,\n pub slothashes: Sysvar<'info, SlotHashes>,\n pub instructions: Sysvar<'info, Instructions>,\n\n // ... your other accounts\n}3. Read the Pricepub fn your_instruction(ctx: Context<YourInstruction>) -> Result<()> {\n let feeds = &ctx.accounts.quote_account.feeds;\n\n // Get the first feed's value\n let price = feeds[0].value();\n\n // Use the price in your logic\n // ...\n\n Ok(())\n}Quote accounts are variable-length. Do not read values by fixed byte offsets from one simulation result; parse them with SwitchboardQuote and PackedFeedInfo. See Quote Program Accounts.TroubleshootingSymptomWhat it meanspullFeedSubmitResponseConsensus or PullFeed.fetchUpdateIx(...) returns ORACLE_UNAVAILABLE, but queue.fetchManagedUpdateIxs(...) returns Ed25519 + quote-program instructionsThe integration is using the legacy PullFeed path against quote-program infrastructure. Use managed quote-program updates and read the canonical quote account.Simulation succeeds, but signed update fetching fails with oracle validation errors such as RangeExceededThis is a feed validation issue, not a PullFeed-vs-quote-program issue. Check feed parameter units, especially raw v2 maxJobRangePct; see Feed Parameter Units.Next StepsMultiple Feeds: Pass multiple feed IDs to fetchManagedUpdateIxs to update several prices in one transactionStaleness Checks: Add maximum staleness requirements for your use caseQuote Program Accounts: Read canonical quote accounts safely in the Quote Program Accounts guideAuthority-Updated Feeds: Publish quotes from your own trusted wallet or PDA in the Authority-Updated Feeds guideCustom Feeds: Learn how to create custom data feeds in the Custom Feeds sectionAdvanced Patterns: See the Advanced Price Feed tutorial for more complex integration patternsPreviousPrice FeedsNextAdvanced Price Feed TutorialLast updated 2 months ago","tokens":3147,"squid":"spider-08","role":"Oracle Spider","at":1791342964817,"hash":"ee0c7c2304e5a1df6f9bee1321a4d86b2c3d8041"}
{"url":"https://www.metaplex.com/docs/api/get-launch","domain":"metaplex.com","title":"Metaplex API - Get Launch | REST API | Metaplex","text":"Retrieve launch data for a specific genesis address. Returns launch info, token metadata, website, and social links. SummaryFetch a single launch by its genesis account public key. Returns the launch details, base token metadata, website, and social links wrapped in a LaunchData object.Requires the genesis account public key as a path parameterReturns a single LaunchData object (not an array)Includes token metadata (name, symbol, image) and social linksSupports mainnet (default) and devnet via network query parameterQuick ReferenceItemValueMethodGETPath/launches/{genesis_pubkey}AuthNoneResponseLaunchDataPaginationNoneEndpointGET /launches/{genesis_pubkey}\nPath ParametersParameterTypeRequiredDescriptiongenesis_pubkeystringYesThe genesis account public keyQuery ParametersParameterTypeRequiredDescriptionnetworkstringNoNetwork to query. Default: solana-mainnet. Use solana-devnet for devnet.Example Requestcurl https://api.metaplex.com/v1/launches/7nE9GvcwsqzYcPUYfm5gxzCKfmPqi68FM7gPaSfG6EQN\nResponse{\n \"data\": {\n \"launch\": {\n \"launchPage\": \"https://example.com/launch/mytoken\",\n \"mechanic\": \"launchpoolV2\",\n \"genesisAddress\": \"7nE9GvcwsqzYcPUYfm5gxzCKfmPqi68FM7gPaSfG6EQN\",\n \"spotlight\": false,\n \"startTime\": \"2026-01-15T14:00:00.000Z\",\n \"endTime\": \"2026-01-15T18:00:00.000Z\",\n \"status\": \"graduated\",\n \"heroUrl\": \"launches/abc123/hero.webp\",\n \"graduatedAt\": \"2026-01-15T18:05:00.000Z\",\n \"lastActivityAt\": \"2026-01-15T17:45:00.000Z\",\n \"type\": \"launchpool\"\n },\n \"baseToken\": {\n \"address\": \"EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v\",\n \"name\": \"My Token\",\n \"symbol\": \"MTK\",\n \"image\": \"https://example.com/token-image.png\",\n \"description\": \"A community-driven token for the example ecosystem.\"\n },\n \"website\": \"https://example.com\",\n \"socials\": {\n \"x\": \"https://x.com/mytoken\",\n \"telegram\": \"https://t.me/mytoken\",\n \"discord\": \"https://discord.gg/mytoken\"\n }\n }\n}\nResponse TypeSee Shared Types for Launch, BaseToken, and Socials definitions.TypeScriptinterface LaunchResponse {\n data: {\n launch: Launch;\n baseToken: BaseToken;\n website: string;\n socials: Socials;\n };\n}\nRust#[derive(Debug, Serialize, Deserialize)]\n#[serde(rename_all = \"camelCase\")]\npub struct LaunchData {\n pub launch: Launch,\n pub base_token: BaseToken,\n pub website: String,\n pub socials: Socials,\n}\n\n#[derive(Debug, Serialize, Deserialize)]\npub struct LaunchResponse {\n pub data: LaunchData,\n}\nUsage ExamplesTypeScriptconst response = await fetch(\n \"https://api.metaplex.com/v1/launches/7nE9GvcwsqzYcPUYfm5gxzCKfmPqi68FM7gPaSfG6EQN\"\n);\nconst { data }: LaunchResponse = await response.json();\nconsole.log(data.baseToken.name); // \"My Token\"\nRustlet response: LaunchResponse = reqwest::get(\n \"https://api.metaplex.com/v1/launches/7nE9GvcwsqzYcPUYfm5gxzCKfmPqi68FM7gPaSfG6EQN\"\n)\n.await?\n.json()\n.await?;\n\nprintln!(\"{}\", response.data.base_token.name); // \"My Token\"\nNotesFinding genesis pubkeys requires indexing or getProgramAccounts. If you only have a token mint, use the Get Launches by Token endpoint instead.Returns 404 if the genesis address is not found or does not have a valid launch.The mechanic field indicates the allocation mechanism (e.g., launchpoolV2, presaleV2, bondingCurveV2). The type field indicates the underlying launch mechanism (launchpool, presale, or bondingCurve).","tokens":818,"squid":"dotcat","role":"Tooling Spider","at":1791342972683,"hash":"ff3bf51cfc1896ed17096d0c3dfa37b6f85ee854"}
{"url":"https://docs.phantom.com/phantom-deeplinks/provider-methods/signmessage","domain":"docs.phantom.com","title":"SignMessage - Phantom developer documentation","text":"Once it’s connected to Phantom, an app can request that the user signs a given message. Applications are free to write their own messages which will be displayed to users from within Phantom’s signature prompt. Message signatures do not involve network fees and are a convenient way for apps to verify ownership of an address.\nIn order to send a message for the user to sign, an application must:\n\nProvide a hex or UTF-8 encoded string as a Uint8Array and then base58-encode it.\nRequest that the encoded message is signed via the user’s Phantom wallet.\n\nThe deeplinking demo app provides an example of signing a message.\nThe message to be signed must be passed as a base58-encoded string. For more information on how to verify the signature of a message, please refer to Encryption resources.\n​Base URL\nhttps://phantom.com/ul/v1/signMessage\n\n​Query string parameters\n\ndapp_encryption_public_key (required): The original encryption public key used from the app side for an existing Connect session.\n\nnonce (required): A nonce used for encrypting the request, encoded in base58.\n\nredirect_link (required): The URI where Phantom should redirect the user upon completion. For more details, see Specify redirects. URL-encoded.\n\npayload (required): An encrypted JSON string with the following fields:\n{\n \"message\": \"...\", // the message, base58 encoded\n \"session\": \"...\", // token received from connect-method\n \"display\": \"utf8\" | \"hex\", // the encoding to use when displaying the message \n}\n\nmessage (required): The message that should be signed by the user, encoded in base58. Phantom will display this message to the user when they are prompted to sign.\nsession (required): The session token received from the Connect method. For more details, see Handle sessions.\ndisplay (optional): How you want us to display the string to the user. Defaults to utf8.\n\n​Returns\n​Approve\n\nnonce: A nonce used for encrypting the response, encoded in base58.\n\ndata: An encrypted JSON string. Refer to Encryption to learn how apps can decrypt data using a shared secret. Encrypted bytes are encoded in base58.\n// content of decrypted `data`-parameter\n{\n signature: \"...\", // message-signature\n}\n\nsignature: The message signature, encoded in base58. For more information on how to verify the signature of a message, see Encryption resources.\n\n​Reject\nAn errorCode and errorMessage as query parameters. For a full list of possible error codes, see Errors.\n{\n \"errorCode\": \"...\",\n \"errorMessage\": \"...\"\n}\n\n​Example\nRefer to the signMessage method implemented in our React Native demo application.Was this page helpful?","tokens":649,"squid":"spider-10","role":"Tooling Spider","at":1791342976146,"hash":"8e2508da10f35240c586b2be023561b553062fa2"}
{"url":"https://docs.switchboard.xyz/docs-by-chain/solana-svm/price-feeds/advanced-price-feed","domain":"docs.switchboard.xyz","title":"Advanced Price Feed Tutorial | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.Example Code: The complete working example for this tutorial is available at sb-on-demand-examples/solana/feeds/advancedThis tutorial demonstrates how to build an ultra-optimized Switchboard oracle integration using the Pinocchio framework, achieving ~90% reduction in compute units compared to the basic Anchor implementation.Why Optimize Compute Units?On Solana, compute units directly impact transaction costs. Every CU saved means lower fees for your users and operators. This matters especially for:High-frequency oracle updates: If you're cranking prices every few seconds, those CUs add up fastProduction DeFi protocols: Lower costs improve margins and user experienceMEV-sensitive operations: Smaller, faster transactions have competitive advantagesMetricBasic (Anchor)Advanced (Pinocchio)SavingsCompute Units~2,000 CU~190 CU~90%Framework OverheadHighMinimal-Transaction SizeStandardOptimized with LUTs~90%What You'll BuildAn ultra-optimized oracle program with:Admin authorization for trusted crankersFour modular instructions: init_state, init_oracle, crank, readDirect oracle writes bypassing expensive verification (for authorized users)QuoteVerifier for secure reads with staleness checksPrerequisitesCompleted the Basic Price Feed tutorialRust and Cargo installedFamiliarity with Pinocchio framework conceptsSolana CLI installed and configuredA Solana keypair with SOLKey ConceptsPinocchio FrameworkPinocchio is a zero-abstraction Solana program framework that provides:Direct syscall access without runtime overheadZero-allocation account parsing#[inline(always)] instruction dispatch~100 CU framework overhead vs ~2,000 CU for AnchorAdmin Authorization PatternInstead of verifying every oracle update cryptographically (expensive), this pattern:Stores an authorized signer in a state accountOnly allows that signer to write oracle dataUses write_from_ix_unchecked for direct writesThis trades decentralization for efficiency—suitable when you control the cranker.Modular Account InitializationThe program separates account creation into dedicated instructions:init_state: Creates the authorization state accountinit_oracle: Creates the quote storage accountThis allows conditional initialization only when needed.The On-Chain ProgramProgram StructureUse the current Pinocchio and Switchboard dependencies:[dependencies]\nswitchboard-on-demand = { version = \"0.13.0\", features = [\"pinocchio\", \"devnet\"] }\npinocchio = { version = \"0.11.2\", features = [\"cpi\"] }\nsolana-msg = \"2.2.1\"use pinocchio::{entrypoint, AccountView, Address, ProgramResult};\nuse pinocchio::error::ProgramError;\nuse solana_msg::msg;\nuse switchboard_on_demand::{\n check_pubkey_eq, get_slot, Instructions, OracleQuote, QuoteVerifier\n};\n\nmod utils;\nuse utils::{init_quote_account_if_needed, init_state_account_if_needed};\n\nentrypoint!(process_instruction);\n\npub fn process_instruction(\n program_id: &Address,\n accounts: &mut [AccountView],\n instruction_data: &[u8],\n) -> ProgramResult {\n match instruction_data[0] {\n 0 => crank(program_id, accounts)?, // Write oracle data\n 1 => read(program_id, accounts)?, // Read and verify\n 2 => init_state(program_id, accounts)?, // Initialize state\n 3 => init_oracle(program_id, accounts)?, // Initialize oracle account\n _ => return Err(ProgramError::InvalidInstructionData),\n }\n Ok(())\n}The instruction discriminator is a single byte—no Anchor discriminator overhead.Instruction 0: crankThe crank instruction writes oracle data for authorized signers:pub fn crank(program_id: &Address, accounts: &mut [AccountView]) -> ProgramResult {\n let [quote, queue, state, payer, instructions_sysvar, _clock_sysvar]: &mut [AccountView; 6] =\n accounts.try_into().map_err(|_| ProgramError::NotEnoughAccountKeys)?;\n\n // Validate state account belongs to this program\n if !is_state_account(state, program_id) {\n msg!(\"Invalid state account\");\n return Err(ProgramError::Custom(2));\n }\n\n // Check payer matches authorized signer stored in state\n let state_data = state.try_borrow()?;\n if !check_pubkey_eq(&state_data[..32], payer.address()) {\n return Err(ProgramError::Custom(1)); // UnauthorizedSigner\n }\n\n // DANGER: Only use this if you trust the signer!\n // Bypasses cryptographic verification for speed\n OracleQuote::write_from_ix_unchecked(&*instructions_sysvar, quote, queue.address(), 0);\n\n Ok(())\n}Key points:Uses AccountView accessors for low-overhead account reads and writeswrite_from_ix_unchecked directly writes oracle data without Ed25519 verificationOnly ~90 CU for the entire operationInstruction 1: readThe read instruction verifies and displays oracle data:pub fn read(_program_id: &Address, accounts: &mut [AccountView]) -> ProgramResult {\n let [quote, queue, clock_sysvar, slothashes_sysvar, instructions_sysvar]: &mut [AccountView; 5] =\n accounts.try_into().map_err(|_| ProgramError::NotEnoughAccountKeys)?;\n\n let slot = get_slot(&*clock_sysvar);\n\n // Verify the oracle data with staleness check\n let quote_data = QuoteVerifier::new()\n .slothash_sysvar(&*slothashes_sysvar)\n .ix_sysvar(&*instructions_sysvar)\n .clock_slot(slot)\n .queue(&*queue)\n .max_age(30) // Reject data older than 30 slots (~12 seconds)\n .verify_account(queue.address(), quote)\n .unwrap();\n\n msg!(\"Quote slot: {}\", quote_data.slot());\n\n // Display each feed's data\n for (index, feed_info) in quote_data.feeds().iter().enumerate() {\n msg!(\"Feed #{}: {}\", index + 1, feed_info.hex_id());\n msg!(\"Value: {}\", feed_info.value());\n }\n\n Ok(())\n}Key points:Uses QuoteVerifier for secure verificationmax_age(30) ensures data freshness (30 slots ≈ 12 seconds)Iterates through all feeds in the quoteInstruction 2: init_stateInitializes the authorization state account:pub fn init_state(program_id: &Address, accounts: &mut [AccountView]) -> ProgramResult {\n let [state, payer, system_program]: &mut [AccountView; 3] =\n accounts.try_into().map_err(|_| ProgramError::NotEnoughAccountKeys)?;\n\n // Create the state account PDA\n init_state_account_if_needed(program_id, state, payer, system_program)?;\n\n // Store the authorized signer (payer becomes the admin)\n state.try_borrow_mut()?[..32].copy_from_slice(payer.address().as_ref());\n\n Ok(())\n}The state account stores a single 32-byte pubkey—the authorized cranker.Instruction 3: init_oracleInitializes the oracle quote account:pub fn init_oracle(program_id: &Address, accounts: &mut [AccountView]) -> ProgramResult {\n let [quote, queue, payer, system_program, instructions_sysvar]: &mut [AccountView; 5] =\n accounts.try_into().map_err(|_| ProgramError::NotEnoughAccountKeys)?;\n\n // Parse feed info from the Ed25519 instruction data\n let quote_data = Instructions::parse_ix_data_unverified(&*instructions_sysvar, 0)\n .map_err(|_| ProgramError::InvalidInstructionData)?;\n\n // Create the quote account as a PDA derived from queue + feed IDs\n init_quote_account_if_needed(\n program_id,\n quote,\n queue,\n payer,\n system_program,\n &quote_data,\n )?;\n\n Ok(())\n}Account Initialization HelpersThe utils.rs module handles PDA derivation and account creation:Quote Account Initializationpub const ORACLE_ACCOUNT_SIZE: usize = 8 + 32 + 1024; // discriminator + queue + data\n\npub fn init_quote_account_if_needed(\n program_id: &Address,\n oracle_account: &mut AccountView,\n queue_account: &mut AccountView,\n payer: &mut AccountView,\n system_program: &mut AccountView,\n oracle_quote: &OracleQuote,\n) -> Result<(), ProgramError> {\n // Skip if already initialized\n if oracle_account.lamports() != 0 {\n msg!(\"Oracle account already initialized\");\n return Ok(());\n }\n\n // Derive PDA from queue + feed IDs\n let feed_ids = oracle_quote.feed_ids();\n let mut seeds: Vec<&[u8]> = Vec::with_capacity(feed_ids.len() + 1);\n seeds.push(queue_account.address().as_ref());\n for feed_id in &feed_ids {\n seeds.push(feed_id.as_ref());\n }\n\n let (canonical_address, bump) = Address::find_program_address(&seeds, program_id);\n\n if canonical_address != *oracle_account.address() {\n return Err(ProgramError::InvalidArgument);\n }\n\n // Create account via CPI to system program\n // ... (invoke_signed with seeds)\n}State Account Initializationpub const STATE_ACCOUNT_SIZE: usize = 32; // Single pubkey\n\npub fn init_state_account_if_needed(\n program_id: &Address,\n state_account: &mut AccountView,\n payer: &mut AccountView,\n system_program: &mut AccountView,\n) -> Result<(), ProgramError> {\n if state_account.lamports() != 0 {\n return Ok(());\n }\n\n // Derive PDA from \"state\" seed\n let (expected_key, bump) = Address::find_program_address(&[b\"state\"], program_id);\n\n if state_account.address() != &expected_key {\n return Err(ProgramError::InvalidArgument);\n }\n\n // Create account via CPI\n // ... (invoke_signed with [\"state\", bump] seeds)\n}The TypeScript ClientThe client handles initialization, quote fetching, and transaction building:import * as sb from \"@switchboard-xyz/on-demand\";\nimport { OracleQuote } from \"@switchboard-xyz/on-demand\";\nimport { PublicKey } from \"@solana/web3.js\";\n\nconst FEED_ID = \"4cd1cad962425681af07b9254b7d804de3ca3446fbfd1371bb258d2c75059812\";\n\nasync function main() {\n // Step 1: Load environment (auto-detects network)\n const { keypair, connection, crossbar, queue } = await sb.AnchorUtils.loadEnv();\n\n // Load your deployed program ID\n const advancedProgramId = new PublicKey(\"YOUR_PROGRAM_ID\");\n\n // Step 2: Derive the canonical quote account\n // Note: includes program ID for program-owned accounts\n const [quoteAccount] = OracleQuote.getCanonicalPubkey(\n queue.pubkey,\n [FEED_ID],\n advancedProgramId // Program ID for custom derivation\n );\n\n // Step 3: Fetch the Ed25519 quote instruction\n const quoteIx = await queue.fetchQuoteIx(crossbar, [FEED_ID], {\n variableOverrides: {},\n });\n\n // Step 4: Decode and inspect the quote\n const decodedQuote = OracleQuote.decode(quoteIx.data);\n console.log(\"Quote slot:\", decodedQuote.slot.toString());\n console.log(\"Feeds:\", decodedQuote.feeds.length);\n decodedQuote.feeds.forEach((feed, idx) => {\n console.log(` Feed ${idx}: ${feed.value}`);\n });\n\n // Step 5: Check if accounts need initialization\n const [stateAccount] = PublicKey.findProgramAddressSync(\n [Buffer.from(\"state\")],\n advancedProgramId\n );\n\n const instructions = [quoteIx];\n\n // Add init_state if needed\n const stateInfo = await connection.getAccountInfo(stateAccount);\n if (!stateInfo) {\n instructions.push(createInitStateIx(advancedProgramId, keypair.publicKey));\n }\n\n // Add init_oracle if needed\n const quoteInfo = await connection.getAccountInfo(quoteAccount);\n if (!quoteInfo) {\n instructions.push(createInitOracleIx(\n advancedProgramId, quoteAccount, queue.pubkey, keypair.publicKey\n ));\n }\n\n // Step 6: Add crank and read instructions\n instructions.push(createCrankIx(\n advancedProgramId, quoteAccount, queue.pubkey, stateAccount, keypair.publicKey\n ));\n instructions.push(createReadIx(advancedProgramId, quoteAccount, queue.pubkey));\n\n // Step 7: Build V0 transaction with priority fees\n const tx = await sb.asV0Tx({\n connection,\n ixs: instructions,\n signers: [keypair],\n computeUnitPrice: 10_000,\n computeUnitLimitMultiple: 1.1,\n });\n\n // Step 8: Simulate and send\n const sim = await connection.simulateTransaction(tx);\n console.log(sim.value.logs?.join(\"\\n\"));\n\n if (!sim.value.err) {\n const sig = await connection.sendTransaction(tx);\n console.log(\"Transaction:\", sig);\n }\n}OracleQuote.decode(...) parses the Ed25519 quote instruction payload. Stored quote-program accounts are variable-length; read them with the Rust SwitchboardQuote/PackedFeedInfo account types instead of fixed offsets. See Quote Program Accounts.Running the Example1. Clone the Examples Repositorygit clone https://github.com/switchboard-xyz/sb-on-demand-examples\ncd sb-on-demand-examples/solana/feeds/advanced2. Install Dependenciesnpm install3. Build and Deploy the ProgramUnlike the basic example, the advanced program must be deployed:# Build the Pinocchio program\ncargo build-sbf --manifest-path programs/advanced-oracle-example/Cargo.toml\n\n# Deploy to devnet\nsolana program deploy target/deploy/advanced_oracle_example.so4. Run the Example# Using default BTC/USD feed\nnpm run update\n\n# Using a custom feed ID\nnpm run update -- --feedId YOUR_FEED_IDExpected OutputNetwork detected: devnet\nQueue selected: FdRnYujMnYbAJp5P2rkEYZCbF2TKs2D2yXZ7MYq89Hms\nQuote Account (derived): 8Js7NsQ7sF3WLJN3JC4LJQGz8kHiEJwZ7sdGTtJC5J7d\n\nDecoded Oracle Quote:\n Version: 1\n Slot: 298234567\n Feeds:\n Feed 0:\n Feed Hash: 4cd1cad962425681af07b9254b7d804de3ca3446fbfd1371bb258d2c75059812\n Value: 97234.5\n Min Oracle Samples: 3\n\nState account already initialized\nQuote account already initialized\nTransaction instruction count: 3\n - Ed25519 verification\n - crank\n - read\n\nPerformance Stats - Min: 45ms | Median: 52ms | Mean: 54.3ms | Count: 1\nQuote slot: 298234567\nFeed #1: 4cd1cad...\nValue: 97234.5When to Use This PatternUse the advanced pattern when:ScenarioRecommendationHigh-frequency cranking (sub-second)AdvancedCompute-sensitive DeFi protocolsAdvancedYou control the cranker infrastructureAdvancedLearning / prototypingBasicDecentralized, trustless updatesBasicSimple integrationsBasicSecurity Considerationswrite_from_ix_unchecked RisksThis function bypasses cryptographic verification. Only use it when:You control the signer: The authorized cranker is your infrastructureYou trust all transaction accounts: Malicious accounts could corrupt dataYou have external monitoring: Detect and respond to anomaliesAdmin Authorization Trade-offsAspectManaged Updates (Basic)Admin Auth (Advanced)Trust ModelTrustless (cryptographic)Trusted adminCostHigher CU~90% lower CUDecentralizationAnyone can updateOnly adminSecurityEd25519 verifiedAdmin key securityRecommendationsRotate admin keys periodicallyUse multisig for production admin accountsMonitor for anomalies in oracle valuesConsider hybrid approaches: Admin writes + periodic cryptographic verificationNext StepsAuthority-Updated Feeds: Publish quotes from your own trusted wallet or PDA in the Authority-Updated Feeds guideCustom Feeds: Learn to create custom data feeds in Custom FeedsMultiple Feeds: Batch multiple price feeds in a single transactionRandomness: Explore verifiable randomness in the Randomness TutorialPreviousBasic Price Feed TutorialNextQuote Program AccountsLast updated 2 months ago","tokens":3562,"squid":"spider-08","role":"Oracle Spider","at":1791342976202,"hash":"91751ad8dba3b3f358332e1b28f6922b4c98882d"}
{"url":"https://www.metaplex.com/docs/agents","domain":"metaplex.com","title":"Create & Run Agents on Solana | Agent Registry | Metaplex","text":"Agent KitCreate, register, and run autonomous agents on Solana. Use the Metaplex Agent skills and agent registry to manage your autonomous agents.The Metaplex Agent Kit gives autonomous AI agents a verifiable onchain identity, a wallet with no private key exposure, and the primitives to participate in the onchain economy. Agents can launch their own token to raise capital and earn revenue from productive onchain work. Agent OnboardingOnboarding guide for AI agents integrating with Metaplex programs.SkillMetaplex knowledge base for AI agents.Mint an AgentMint an agent and register its Identity PDA.Register an AgentRegister an agent on the Metaplex registry.Read Agent DataRead and verify agent identity on Solana.Agent FinanceCapitalize and govern your AI agent through its own onchain token.Agent CommerceHow AI agents earn revenue, pay for services, and transact onchain.Create an Agent TokenLaunch a token from an agent's onchain wallet.Run an AgentDelegate execution to run an agent on Solana.NoriPay-as-you-go LLM, image, and RPC services for agents, metered in SOL.","tokens":270,"squid":"dotcat","role":"Tooling Spider","at":1791342983264,"hash":"7cf08728c8a3be8336d884d1a5f4ab2565ea05aa"}
{"url":"https://docs.switchboard.xyz/docs-by-chain/solana-svm/price-feeds/authority-updated-feeds","domain":"docs.switchboard.xyz","title":"Authority-Updated Feeds | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.Authority-updated feeds let you publish Switchboard quote accounts on Solana using a trusted authority instead of Switchboard's oracle-signing flow.In this model, the authority signs the update directly and quote_program stores the result in the same quote-account format used by Surge. The authority can be:a walleta PDA signed by another Solana program with invoke_signedThroughout this page, \"authority-updated feed\" means an authority-owned quote account in quote_program.When To Use This FeatureUse authority-updated feeds when your application is the source of truth for a value and you want to publish that value through Switchboard quote-account tooling.Common examples:protocol-defined mark or fair valuesinternal pricing modelsprogram-owned data streams published from a PDAintegrations that want a stable quote-account interface without oracle signaturesUse the standard oracle-backed update path instead if you need Switchboard oracle verification and the corresponding trust model.What Gets CreatedA single authority-updated quote account can contain one or more feed IDs and their latest values.On the first successful update, quote_program:derives the quote PDAcreates the quote accountwrites the payloadThere is no separate initialize instruction. Creation happens on first write.Quote Account IdentityThe quote account PDA is derived from:quote_account = PDA(\n [\n b\"AUTH\",\n authority_pubkey,\n feed_id_1,\n feed_id_2,\n ...\n ],\n quote_program_id\n)Two consequences matter in practice:the authority is part of the quote stream identityfeed order is part of the quote stream identityThese feed bundles produce different quote accounts:[BTC, ETH]\n[ETH, BTC]Recommended practice:choose one canonical ordering and use it everywherefor human-labeled feeds, sort alphabetically by symbol or another stable label before building the payloadkeep the same ordered feed list when deriving the PDA, building the payload, and storing configuration in your appIf the order changes, the quote account address changes.High-Level FlowWallet authorityBuild an authority quote payload with the feed IDs, values, and slot.Derive the quote PDA from the authority and the ordered feed list.Send FeedAuthorityUpdate.quote_program validates the signer, derivation, and slot progression.The quote account is created on first use or updated if it already exists.PDA authorityYour program derives or receives its authority PDA.Your program builds or receives the authority quote payload.Your program CPI-calls quote_program::FeedAuthorityUpdate.Your program signs the CPI with invoke_signed.quote_program applies the same validation and writes the update.AccountsFeedAuthorityUpdate expects:quote_account - writableauthority - signerclock_sysvarpayer - signer and rent payer on first usesystem_programNotes:authority can be a wallet or PDAquote_account is always a PDA owned by quote_programpayer funds initialization, but the authority defines the stream identityPayload FormatAuthority updates use a dedicated payload format:[4 bytes] scheme tag = \"AUTH\"\n[1 byte] feed_count\n[N bytes] PackedFeedInfo[feed_count]\n[8 bytes] slot (u64 LE)\n[1 byte] version\n[4 bytes] tail discriminator = \"SBOD\"Each PackedFeedInfo is:[32 bytes] feed_id\n[16 bytes] feed_value (i128 LE)\n[1 byte] min_oracle_samplesNotes:feed_id is a 32-byte feed identifierfeed_value is stored as signed i128min_oracle_samples is retained for compatibility with shared quote tooling; SDK helpers default it to 1the payload must include at least one feedValidation Rulesquote_program::FeedAuthorityUpdate rejects the update unless all of the following are true:authority signed the transactionthe payload parses as a valid authority quote payloadthe payload contains between 1 and 13 feed IDsthe payload contains no duplicate feed IDsthe provided quote_account matches the PDA derived from AUTH + authority + ordered feed IDsif the quote account already exists, the stored authority matches the signerthe payload slot is strictly less than the current cluster slot at execution timethe payload slot is greater than or equal to the last stored slotThe current feed-ID limit is:maximum feed count: 13maximum feed-ID bytes used in PDA seeds: 416Practical slot guidance:fetch a recent slot before building the payloadtreat the slot as monotonic per quote accountdo not reuse an older slot after a newer update has already landedWhat Gets Stored On-ChainAuthority-backed quotes use the existing Switchboard quote-account layout.For authority quotes:the first 32-byte namespace field stores the authority pubkeythe quote data section stores the encoded authority payloadshared decoders reconstruct the quote as sourceScheme = \"authority\"For oracle-backed quotes, that same namespace field stores a queue pubkey instead. The layout stays compatible, but consumers must inspect the source scheme before applying trust assumptions.Reading And TrustAuthority-updated feeds are not oracle-verified quotes. Consumers should trust them only to the extent that they trust the configured authority.When reading an authority quote:decode it through the normal quote readers or SDK helperscheck that sourceScheme is authoritytreat the authority pubkey as the publisher identitydo not assume oracle signatures or QuoteVerifier-style oracle trust guaranteesThis model is a good fit when your application, service, or program is intentionally the publisher of record.TypeScript SDK HelpersThe TypeScript SDK exposes helpers in javascript/on-demand/src/classes/oracleQuote.ts:OracleQuote.buildAuthorityQuotePayload(...)OracleQuote.deriveAuthorityQuotePubkey(...)OracleQuote.buildFeedAuthorityUpdateInstruction(...)Example:import { OracleQuote } from \"@switchboard-xyz/on-demand\";\n\nconst authority = myAuthorityPubkey;\nconst payer = myWallet.publicKey;\n\nconst feeds = [\n { symbol: \"BTC\", feedHash: btcFeedId, value: 123_000000000000000000n },\n { symbol: \"ETH\", feedHash: ethFeedId, value: 456_000000000000000000n },\n].sort((a, b) => a.symbol.localeCompare(b.symbol));\n\nconst payload = OracleQuote.buildAuthorityQuotePayload(\n feeds.map(({ feedHash, value }) => ({\n feedHash,\n value,\n })),\n recentSlot\n);\n\nconst orderedFeedIds = feeds.map(({ feedHash }) => feedHash);\n\nconst [quoteAccount] = OracleQuote.deriveAuthorityQuotePubkey(\n authority,\n orderedFeedIds\n);\n\nconst ix = OracleQuote.buildFeedAuthorityUpdateInstruction({\n authority,\n payer,\n payload,\n quoteAccount,\n});If you set minOracleSamples explicitly, treat it as an unscaled oracle-sample count and use the same ordered feed list for both payload construction and PDA derivation.Rust SDK HelpersThe Rust SDK exposes the same concepts in switchboard-on-demand:build_authority_quote_payload(...)derive_authority_quote_pubkey(...)build_feed_authority_update_instruction(...)These helpers are useful for:off-chain Rust clientsintegration testsSolana programs preparing CPI inputsBest PracticesPick a canonical feed ordering before you publish the first update.Alphabetical ordering by symbol is a good default when feeds have stable human-readable names.If you only work with raw feed IDs, sort them by a stable application-level rule and never change it.Persist the authority, ordered feed list, and derived quote account together in your configuration.Keep feed bundles small and avoid duplicate feed IDs.Separate authority-backed handling from oracle-backed handling in downstream code.Only publish or consume authority quotes in places where the authority is an acceptable trust anchor.SummaryAuthority-updated feeds let a wallet or PDA publish Switchboard quote accounts directly into Solana quote_program.Key properties:the authority owns the quote stream identityfeed order mattersfirst write initializes the accountthe current limit is 13 feed IDs per quoteshared readers decode these quotes as sourceScheme = \"authority\"Use this flow when you want Switchboard-compatible quote accounts but the data should be trusted because of your authority signer, not because of Switchboard oracle signatures.PreviousQuote Program AccountsNextSurge Price FeedsLast updated 3 months ago","tokens":2039,"squid":"spider-08","role":"Oracle Spider","at":1791342986136,"hash":"a1493d0af298b17b21c47c98bba43f24caef6fdc"}
{"url":"https://www.metaplex.com/docs/agents/mint-agent","domain":"metaplex.com","title":"Mint an Agent | Metaplex","text":"Register an AI agent onchain in a single call using the Metaplex API and the mpl-agent-registry SDK. SummaryThe Metaplex API provides a hosted endpoint that stores agent metadata and returns an unsigned Solana transaction. Signing and submitting that transaction creates an MPL Core asset representing the agent and registers an Agent Identity PDA in a single atomic operation.Creates an MPL Core asset and registers the Agent Identity PDA together in one transaction — no pre-existing asset requiredHosted API at https://api.metaplex.com handles metadata storage — no separate upload step before mintingTwo SDK functions — mintAndSubmitAgent for a one-call flow, mintAgent for manual signing controlMulti-network — supports Solana mainnet and devnet, Eclipse, Sonic, and FogoRequires @metaplex-foundation/mpl-agent-registry v0.2.0+What You'll BuildA registered onchain AI agent: an MPL Core asset with a linked Agent Identity PDA, created via the Metaplex API and the mpl-agent-registry SDK.Quick StartUnderstand the flowInstall the SDKConfigure a Umi instanceMint and register in one callVerify the resultHow It WorksMinting an agent through the Metaplex API is a three-step flow orchestrated by the SDK:API call — The SDK sends your agent details to POST /v1/agents/mint on https://api.metaplex.com. The API stores the agentMetadata off-chain and constructs an unsigned Solana transaction.Unsigned transaction returned — The API returns the transaction without signing it. Your private key never leaves your environment — the API only builds the instruction set.Sign and submit — You (or mintAndSubmitAgent automatically) sign the transaction with your keypair and submit it. Onchain, this creates the Core asset and registers the Agent Identity PDA in a single atomic operation.Two fields, two destinationsWhen calling mintAndSubmitAgent or mintAgent, you provide two distinct pieces of metadata:FieldWhere it's storedPurposeuriOnchain, in the Core asset's metadataPoints to a publicly hosted JSON file — the agent's NFT metadata. Works like any standard Core asset URI.agentMetadataOff-chain, stored by the Metaplex APIDescribes the agent's capabilities, services, and trust model. Indexed by the registry for discovery.Both are set during minting and cannot be changed independently after the fact without updating the agent.This guide creates a new Core asset and registers the agent identity together in one transaction. If you already own a Core asset and only want to attach an identity to it, use registerIdentityV1 instead.PrerequisitesThe following are required before minting:Node.js 18 or laterA funded Solana wallet keypair — this wallet pays for the transaction and becomes the agent ownerA publicly accessible uri for the Core asset's NFT metadata JSONInstallationInstall the three required packages: the Agent Registry SDK, the core Umi framework, and the default Umi bundle that provides an RPC client and transaction sender.Terminalnpm install @metaplex-foundation/mpl-agent-registry @metaplex-foundation/umi @metaplex-foundation/umi-bundle-defaults\nUmi SetupUmi is the Metaplex JavaScript framework used to interact with Solana programs. Configure it with your RPC endpoint and keypair before calling any SDK function.The mplAgentIdentity() plugin registers the Agent Identity program's instruction builders and account deserializers with your Umi instance. Without it, Umi cannot construct or read Agent Identity program instructions.setup.tsimport { createUmi } from '@metaplex-foundation/umi-bundle-defaults';\nimport { keypairIdentity } from '@metaplex-foundation/umi';\nimport { mplAgentIdentity } from '@metaplex-foundation/mpl-agent-registry';\n\n// Point Umi at your preferred RPC\nconst umi = createUmi('https://api.mainnet-beta.solana.com')\n .use(mplAgentIdentity());\n\n// Load your keypair — this wallet pays for the transaction and becomes the agent owner\nconst keypair = umi.eddsa.createKeypairFromSecretKey(mySecretKeyBytes);\numi.use(keypairIdentity(keypair));\nThe example above uses keypairIdentity — loading a raw secret key directly into Umi. This is the standard approach for server-side scripts and backend integrations. Umi also supports two other identity patterns depending on your environment:ApproachHowBest forRaw keypair (this example)keypairIdentity + createKeypairFromSecretKeyServer-side scripts, backendsFilesystem walletcreateSignerFromKeypair + signerIdentity with a JSON key fileLocal development and CLI toolsBrowser wallet adapterwalletAdapterIdentity from umi-signer-wallet-adaptersWeb dApps with Phantom, Backpack, etc.See Connecting a Wallet in the Umi docs for full code examples of each approach, including how to load a filesystem keypair from a .json file and how to wire up a wallet adapter.Mint and Submit an AgentmintAndSubmitAgent calls the Metaplex API, signs the returned transaction, and submits it to the network in one step. Use this for most integrations.mintAndSubmitAgent.ts1import { mintAndSubmitAgent, mplAgentIdentity } from '@metaplex-foundation/mpl-agent-registry'\n2import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n3import { keypairIdentity } from '@metaplex-foundation/umi'\n4\n5const umi = createUmi('https://api.mainnet-beta.solana.com')\n6 .use(mplAgentIdentity())\n7\n8const keypair = umi.eddsa.createKeypairFromSecretKey(mySecretKeyBytes)\n9umi.use(keypairIdentity(keypair))\n10\n11const result = await mintAndSubmitAgent(umi, {}, {\n12 wallet: umi.identity.publicKey,\n13 name: 'My AI Agent',\n14 uri: 'https://example.com/agent-metadata.json', // Core asset NFT metadata URI\n15 agentMetadata: { // Stored off-chain by the Metaplex API\n16 type: 'agent',\n17 name: 'My AI Agent',\n18 description: 'An autonomous trading agent',\n19 services: [\n20 { name: 'trading', endpoint: 'https://myagent.ai/trade' },\n21 ],\n22 registrations: [],\n23 supportedTrust: [],\n24 },\n25})\n26\n27console.log('Asset address:', result.assetAddress)\n28console.log('Transaction signature:', result.signature)\n29\n30// Asset address: <base58 address>\n31// Transaction signature: <base58 signature>\nMint an Agent with Manual SigningmintAgent returns the unsigned transaction without submitting it. Use this when you need to add priority fees, use a hardware wallet, or integrate custom retry logic.mintAgent.ts1import {\n2 mintAgent,\n3 signAndSendAgentTransaction,\n4 mplAgentIdentity,\n5} from '@metaplex-foundation/mpl-agent-registry'\n6import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n7import { keypairIdentity } from '@metaplex-foundation/umi'\n8\n9const umi = createUmi('https://api.mainnet-beta.solana.com')\n10 .use(mplAgentIdentity())\n11\n12const keypair = umi.eddsa.createKeypairFromSecretKey(mySecretKeyBytes)\n13umi.use(keypairIdentity(keypair))\n14\n15// Step 1: Call the API — returns the unsigned transaction and the pre-computed asset address\n16const mintResult = await mintAgent(umi, {}, {\n17 wallet: umi.identity.publicKey,\n18 name: 'My AI Agent',\n19 uri: 'https://example.com/agent-metadata.json',\n20 agentMetadata: {\n21 type: 'agent',\n22 name: 'My AI Agent',\n23 description: 'An autonomous trading agent',\n24 services: [\n25 { name: 'trading', endpoint: 'https://myagent.ai/trade' },\n26 { name: 'analysis', endpoint: 'https://myagent.ai/analyze' },\n27 ],\n28 registrations: [\n29 { agentId: 'agent-123', agentRegistry: 'my-registry' },\n30 ],\n31 supportedTrust: ['tee'],\n32 },\n33})\n34\n35console.log('Asset address:', mintResult.assetAddress)\n36\n37// Step 2: Sign and send using the SDK helper\n38const signature = await signAndSendAgentTransaction(umi, mintResult)\n39console.log('Confirmed signature:', signature)\n40\n41// Asset address: <base58 address>\n42// Confirmed signature: <base58 signature>\nVerify the ResultAfter minting, confirm the agent identity was registered by fetching the Core asset and checking the AgentIdentity plugin. A successful registration attaches lifecycle hooks for Transfer, Update, and Execute — these are the signals to check.verifyRegistration.ts1import { fetchAsset } from '@metaplex-foundation/mpl-core'\n2import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n3import { publicKey } from '@metaplex-foundation/umi'\n4import { mplAgentIdentity } from '@metaplex-foundation/mpl-agent-registry'\n5\n6const umi = createUmi('https://api.mainnet-beta.solana.com')\n7 .use(mplAgentIdentity())\n8\n9// Replace with the assetAddress returned by mintAndSubmitAgent or mintAgent\n10const assetAddress = publicKey('YOUR_ASSET_ADDRESS')\n11const assetData = await fetchAsset(umi, assetAddress)\n12const agentIdentity = assetData.agentIdentities?.[0]\n13\n14console.log('Registration URI:', agentIdentity?.uri)\n15console.log('Transfer hook active:', agentIdentity?.lifecycleChecks?.transfer)\n16console.log('Update hook active:', agentIdentity?.lifecycleChecks?.update)\n17console.log('Execute hook active:', agentIdentity?.lifecycleChecks?.execute)\n18\n19// Registration URI: https://example.com/agent-metadata.json\n20// Transfer hook active: { __kind: 'Listen' }\n21// Update hook active: { __kind: 'Listen' }\n22// Execute hook active: { __kind: 'Listen' }\nIf agentIdentities is undefined or empty, the identity was not registered — the transaction may have failed silently or not confirmed. Check the transaction signature onchain before retrying.Agent Metadata FieldsThe agentMetadata object is sent to the Metaplex API and stored off-chain alongside the agent record. It is separate from the Core asset's uri (the NFT metadata file) — see How It Works for the distinction.FieldTypeRequiredDescriptiontypestringYesSchema identifier. Use 'agent'.namestringYesAgent display namedescriptionstringYesWhat the agent does and how to interact with itservicesAgentService[]NoService endpoints the agent exposesregistrationsAgentRegistration[]NoLinks to external registry entriessupportedTruststring[]NoTrust mechanisms supported — e.g. 'tee', 'reputation'Agent Service FieldsEach entry in services describes one way to interact with the agent.FieldTypeRequiredDescriptionnamestringYesService type — e.g. 'trading', 'chat', 'MCP', 'A2A'endpointstringYesURL where the service can be reachedSupported NetworksPass the network value in the input object. It defaults to 'solana-mainnet' when omitted. Make sure your Umi RPC endpoint matches the network you select.Networknetwork ValueSolana Mainnetsolana-mainnet (default)Solana Devnetsolana-devnetLocalnetlocalnetEclipse Mainneteclipse-mainnetSonic Mainnetsonic-mainnetSonic Devnetsonic-devnetFogo Mainnetfogo-mainnetFogo Testnetfogo-testnetDevnet TestingTest your integration on Solana devnet before going to mainnet. Point your Umi instance at the devnet RPC and pass network: 'solana-devnet' so the API registers the agent against the devnet cluster. Agents minted on devnet have separate asset addresses from mainnet and will not appear in mainnet explorers.devnetTest.ts1import { mintAndSubmitAgent, mplAgentIdentity } from '@metaplex-foundation/mpl-agent-registry'\n2import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n3import { keypairIdentity } from '@metaplex-foundation/umi'\n4\n5const umi = createUmi('https://api.devnet.solana.com')\n6 .use(mplAgentIdentity())\n7\n8const keypair = umi.eddsa.createKeypairFromSecretKey(mySecretKeyBytes)\n9umi.use(keypairIdentity(keypair))\n10\n11const result = await mintAndSubmitAgent(umi, {}, {\n12 wallet: umi.identity.publicKey,\n13 network: 'solana-devnet',\n14 name: 'Test Agent',\n15 uri: 'https://example.com/test-metadata.json',\n16 agentMetadata: {\n17 type: 'agent',\n18 name: 'Test Agent',\n19 description: 'A test agent on devnet',\n20 services: [],\n21 registrations: [],\n22 supportedTrust: [],\n23 },\n24})\n25\n26console.log('Asset address:', result.assetAddress)\n27console.log('Transaction signature:', result.signature)\n28\n29// Asset address: <base58 address>\n30// Transaction signature: <base58 signature>\nCustom API Base URLTarget a staging or self-hosted API by passing baseUrl in the config argument (the second parameter to mintAgent or mintAndSubmitAgent). Use this when integrating against a non-production environment.customApiUrl.ts1import { mintAgent, mplAgentIdentity } from '@metaplex-foundation/mpl-agent-registry'\n2import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n3import { keypairIdentity } from '@metaplex-foundation/umi'\n4\n5const umi = createUmi('https://api.mainnet-beta.solana.com')\n6 .use(mplAgentIdentity())\n7\n8const keypair = umi.eddsa.createKeypairFromSecretKey(mySecretKeyBytes)\n9umi.use(keypairIdentity(keypair))\n10\n11const result = await mintAgent(\n12 umi,\n13 { baseUrl: 'https://staging-api.metaplex.com' },\n14 {\n15 wallet: umi.identity.publicKey,\n16 name: 'My Agent',\n17 uri: 'https://example.com/metadata.json',\n18 agentMetadata: {\n19 type: 'agent',\n20 name: 'My Agent',\n21 description: 'Agent targeting staging API',\n22 services: [],\n23 registrations: [],\n24 supportedTrust: [],\n25 },\n26 }\n27)\n28\n29console.log('Asset address:', result.assetAddress)\n30\n31// Asset address: <base58 address>\nCustom Transaction SenderPass a txSender function as the fourth argument to mintAndSubmitAgent to use your own signing and submission infrastructure. This is the right hook for adding Jito bundle tips, priority fees, or custom confirmation polling.customSender.ts1import { mintAndSubmitAgent, mplAgentIdentity } from '@metaplex-foundation/mpl-agent-registry'\n2import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n3import { keypairIdentity } from '@metaplex-foundation/umi'\n4\n5const umi = createUmi('https://api.mainnet-beta.solana.com')\n6 .use(mplAgentIdentity())\n7\n8const keypair = umi.eddsa.createKeypairFromSecretKey(mySecretKeyBytes)\n9umi.use(keypairIdentity(keypair))\n10\n11const result = await mintAndSubmitAgent(\n12 umi,\n13 {},\n14 {\n15 wallet: umi.identity.publicKey,\n16 name: 'My Agent',\n17 uri: 'https://example.com/metadata.json',\n18 agentMetadata: {\n19 type: 'agent',\n20 name: 'My Agent',\n21 description: 'Agent with custom transaction sender',\n22 services: [],\n23 registrations: [],\n24 supportedTrust: [],\n25 },\n26 },\n27 {\n28 txSender: async (tx) => {\n29 const signed = await umi.identity.signTransaction(tx)\n30 return myCustomSend(signed)\n31 },\n32 }\n33)\n34\n35console.log('Asset address:', result.assetAddress)\n36console.log('Transaction signature:', result.signature)\n37\n38// Asset address: <base58 address>\n39// Transaction signature: <base58 signature>\nError HandlingThe SDK exports typed error guards so you can handle each failure mode explicitly rather than catching a generic error.errorHandling.ts1import {\n2 mintAgent,\n3 isAgentApiError,\n4 isAgentApiNetworkError,\n5 isAgentValidationError,\n6 mplAgentIdentity,\n7} from '@metaplex-foundation/mpl-agent-registry'\n8import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n9import { keypairIdentity } from '@metaplex-foundation/umi'\n10\n11const umi = createUmi('https://api.mainnet-beta.solana.com')\n12 .use(mplAgentIdentity())\n13\n14const keypair = umi.eddsa.createKeypairFromSecretKey(mySecretKeyBytes)\n15umi.use(keypairIdentity(keypair))\n16\n17const input = {\n18 wallet: umi.identity.publicKey,\n19 name: 'My Agent',\n20 uri: 'https://example.com/metadata.json',\n21 agentMetadata: {\n22 type: 'agent',\n23 name: 'My Agent',\n24 description: 'An autonomous agent',\n25 services: [],\n26 registrations: [],\n27 supportedTrust: [],\n28 },\n29}\n30\n31try {\n32 const result = await mintAgent(umi, {}, input)\n33} catch (err) {\n34 if (isAgentValidationError(err)) {\n35 // Client-side validation failed before the API was called\n36 console.error(`Validation error on field \"${err.field}\": ${err.message}`)\n37 } else if (isAgentApiNetworkError(err)) {\n38 // Could not reach the API endpoint\n39 console.error('Network error:', err.message, err.cause)\n40 } else if (isAgentApiError(err)) {\n41 // API responded with a non-2xx status\n42 console.error(`API error (${err.statusCode}): ${err.message}`)\n43 console.error('Response body:', err.responseBody)\n44 } else {\n45 throw err\n46 }\n47}\nCommon ErrorsThese are the most frequent failure modes and how to resolve them.ErrorCauseFixisAgentValidationErrorA required input field is missing or malformedCheck err.field and ensure all required agentMetadata fields are providedisAgentApiNetworkErrorThe API endpoint was unreachableVerify network connectivity; inspect err.cause for the underlying errorisAgentApiErrorThe API returned a non-2xx statusInspect err.statusCode and err.responseBody; verify the uri is publicly accessibleBlockhash expiredThe transaction was not submitted before the blockhash expiredCall mintAgent again to get a fresh transaction, then retry submissionagentIdentities empty after mintTransaction confirmed but identity plugin not attachedFetch the transaction receipt to confirm it succeeded; if it failed silently, retry the full mintFull ExampleA complete end-to-end snippet — setup, mint, and verify — ready to copy and run.fullExample.ts1import {\n2 mintAndSubmitAgent,\n3 mplAgentIdentity,\n4} from '@metaplex-foundation/mpl-agent-registry'\n5import { fetchAsset } from '@metaplex-foundation/mpl-core'\n6import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n7import { keypairIdentity } from '@metaplex-foundation/umi'\n8\n9const umi = createUmi('https://api.mainnet-beta.solana.com')\n10 .use(mplAgentIdentity())\n11\n12const keypair = umi.eddsa.createKeypairFromSecretKey(mySecretKeyBytes)\n13umi.use(keypairIdentity(keypair))\n14\n15// 1. Mint the agent\n16const result = await mintAndSubmitAgent(umi, {}, {\n17 wallet: umi.identity.publicKey,\n18 name: 'My AI Agent',\n19 uri: 'https://example.com/agent-metadata.json',\n20 agentMetadata: {\n21 type: 'agent',\n22 name: 'My AI Agent',\n23 description: 'An autonomous trading agent',\n24 services: [\n25 { name: 'trading', endpoint: 'https://myagent.ai/trade' },\n26 ],\n27 registrations: [],\n28 supportedTrust: [],\n29 },\n30})\n31\n32console.log('Asset address:', result.assetAddress)\n33console.log('Tx signature:', result.signature)\n34\n35// 2. Verify the agent identity was registered\n36const assetData = await fetchAsset(umi, result.assetAddress)\n37const agentIdentity = assetData.agentIdentities?.[0]\n38\n39console.log('Registered:', agentIdentity !== undefined)\n40console.log('Registration URI:', agentIdentity?.uri)\n41\n42// Asset address: <base58 address>\n43// Tx signature: <base58 signature>\n44// Registered: true\n45// Registration URI: https://example.com/agent-metadata.json\nNotesmintAndSubmitAgent creates a new Core asset on every call — there is no deduplication. Calling it twice with the same input creates two separate agents at two different asset addresses.The uri field is stored in the Core asset's onchain metadata and must point to a publicly accessible JSON document. If you do not have a hosted metadata URI yet, upload the file to Arweave or another permanent storage provider first.To attach an agent identity to an existing Core asset without creating a new one, use registerIdentityV1 instead.The Metaplex API base URL defaults to https://api.metaplex.com. No API key is required.Minting costs the standard Solana transaction fee plus rent for the Core asset account and the Agent Identity PDA.Requires @metaplex-foundation/mpl-agent-registry v0.2.0+.FAQWhat is the difference between mintAndSubmitAgent and mintAgent?mintAndSubmitAgent is a convenience wrapper that calls mintAgent then signs and submits the transaction in one step. Use mintAgent directly when you need manual signing control, a custom transaction sender, or the ability to inspect the transaction before submitting.What is the difference between minting via the Metaplex API and using registerIdentityV1 directly?The Metaplex API flow (mintAgent / mintAndSubmitAgent) creates the Core asset and registers the agent identity in a single transaction — no pre-existing Core asset is required. The registerIdentityV1 approach attaches an identity plugin to an MPL Core asset you already own.What is the difference between the uri field and agentMetadata?The uri is stored directly in the Core asset's onchain metadata — it should point to a publicly hosted JSON file, just like a standard NFT. The agentMetadata object is sent to the Metaplex API and stored off-chain alongside the agent record. Both are set during minting. See How It Works for the full breakdown.Do I need to create a Core asset before calling mintAndSubmitAgent?No. The API creates the Core asset and registers the agent identity together. You only need a wallet address, an agent name, a metadata URI, and the agentMetadata object.Can I test on devnet before going to mainnet?Yes. Pass network: 'solana-devnet' in the input and point your Umi instance at https://api.devnet.solana.com.What happens if the API returns a transaction but the submission fails onchain?A failed onchain transaction means the Core asset was not created and no identity was registered. Call mintAgent again to get a fresh transaction with a new blockhash, then retry.Which networks does the Metaplex API support?Solana Mainnet, Solana Devnet, Localnet, Eclipse Mainnet, Sonic Mainnet, Sonic Devnet, Fogo Mainnet, and Fogo Testnet. See Supported Networks for the exact values to pass.What does it cost to mint an agent?Minting costs the standard Solana transaction fee plus rent for the Core asset account and the Agent Identity PDA. There is no additional protocol fee charged by the Metaplex API for minting.","tokens":5318,"squid":"dotcat","role":"Tooling Spider","at":1791342992664,"hash":"383926c2a3175c8113cddcd2fb72dd7cecb38984"}
{"url":"https://docs.phantom.com/phantom-deeplinks/encryption","domain":"docs.phantom.com","title":"Encryption - Phantom developer documentation","text":"Deeplinks are encrypted using symmetric key encryption generated from a Diffie-Hellman key exchange. While deeplink sessions will be created in plaintext, an encrypted channel will be created to prevent session tokens from getting hijacked.\n​Encryption and decryption workflow\nPhantom deeplinks are encrypted with the following workflows:\n​Connect\n\n[dapp]: On the initial connect deeplink, dapps should include a dapp_encryption_public_key query parameter. It’s recommended to create a new x25519 keypair for every session started with connect. In all methods, the public key for this keypair is referred to as dapp_encryption_public_key.\n[phantom]: Upon handling a connect deeplink, Phantom will also generate a new x25519 keypair.\n\nPhantom will return this public key as phantom_encryption_public_key in the connect response.\nPhantom will create a secret key using Diffie-Hellman with dapp_encryption_public_key and the private key associated with phantom_encryption_public_key.\nPhantom will locally store a mapping of dapp_encryption_public_key to shared secrets for use with decryption in subsequent deeplinks.\n\n[dapp]: Upon receiving the connect response, the dapp should create a shared secret by using Diffie-Hellman with phantom_encryption_public_key and the private key associated with dapp_encryption_public_key. This shared secret should then be used to decrypt the data field in the response. If done correctly, the user’s public key will be available to share with the dapp inside the data JSON object.\n\n​Subsequent deeplinks\n\n[dapp]: For any subsequent methods (such as SignTransaction and SignMessage), dapps should send a dapp_encryption_public_key (the public key side of the shared secret) used with Phantom along with an encrypted payload object.\n[phantom]: Upon approval, Phantom will encrypt the signed response as a JSON object with the encryption sent as a data= query param.\n[dapp]: Upon receiving the deeplink response, dapps should decrypt the object in the data= query param to view the signature.\n\n​Encryption resources\nTo learn more about encryption and decryption, please refer to the following libraries:\n​JavaScript\nTweetNaCl.js\n​iOS\nTweetNaCl SwiftWrap\n​Android\n\nTink\nTweetNaCl Java\nWas this page helpful?","tokens":560,"squid":"spider-10","role":"Tooling Spider","at":1791342995410,"hash":"0d3eab3a506fb04d46e0e4fcc68e4e90bbbf0ed5"}
{"url":"https://docs.switchboard.xyz/docs-by-chain/solana-svm/price-feeds/quote-program-accounts","domain":"docs.switchboard.xyz","title":"Quote Program Accounts | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.Solana/SVM feed-hash integrations use canonical quote-program accounts. These accounts are derived from the queue public key and feed ID, then written by managed updates from queue.fetchManagedUpdateIxs(...).Use this path for new custom feeds and feed-hash integrations. The older PullFeed.fetchUpdateIx(...) path targets classic PullFeed accounts and requires compatible legacy queue/gateway support.Derive The Accountimport { OracleQuote } from \"@switchboard-xyz/on-demand\";\n\nconst [quoteAccount] = OracleQuote.getCanonicalPubkey(queue.pubkey, [feedId]);The same feed ID and queue always derive the same quote account. If your program accepts a quote account, constrain it to the canonical address for the queue and feed ID.Assemble Managed UpdatesKeep the Ed25519 and quote-program instructions returned by fetchManagedUpdateIxs(...) adjacent. asV0Tx(...) finalizes their position-dependent indices after the complete instruction order is known, so omit the legacy instructionIdx option:const updateIxs = await queue.fetchManagedUpdateIxs(crossbar, [feedId], {\n payer: keypair.publicKey,\n});\n\nconst tx = await asV0Tx({\n connection,\n ixs: [...setupIxs, ...updateIxs, consumerIx],\n signers: [keypair],\n});If you compile a transaction without asV0Tx, finalize the complete ordered array immediately before compilation:import { finalizeManagedUpdateInstructions } from \"@switchboard-xyz/on-demand\";\n\nconst finalIxs = finalizeManagedUpdateInstructions([\n ...setupIxs,\n ...updateIxs,\n consumerIx,\n]);Read Stored DataStored quote accounts are variable-length. Do not parse feed values by hard-coding byte offsets from a simulation or one account instance.In Rust, use the SDK account types:SwitchboardQuote: stored quote-program accountPackedFeedInfo: one feed result inside the quotefeeds_slice() / feeds(): access feed resultsfeed_id / feed_id(): 32-byte feed IDfeed_value / feed_value(): raw i128 value, scaled by Switchboard precisionvalue(): decimal value helpermin_oracle_samples / min_oracle_samples(): oracle-sample quorum recorded with the feeduse switchboard_on_demand::QuoteVerifier;\n\nlet quote = QuoteVerifier::new()\n .queue(&ctx.accounts.queue)\n .slothash_sysvar(&ctx.accounts.slothashes)\n .ix_sysvar(&ctx.accounts.instructions)\n .clock_slot(ctx.accounts.clock.slot)\n .max_age(50)\n .verify_account(&ctx.accounts.quote_account)?;\n\nfor feed in quote.feeds() {\n msg!(\"Feed {}: {}\", feed.hex_id(), feed.value());\n}JavaScript Decode ScopeOracleQuote.decode(...) parses the Ed25519 quote instruction payload used by managed updates. It is useful when inspecting a quote instruction before it is written on-chain.It is not a stable raw account decoder for stored quote-program account data. For stored account parsing, use the Rust/on-chain SwitchboardQuote account types until a dedicated JavaScript account decoder is available.TroubleshootingIf queue.fetchManagedUpdateIxs(...) returns Ed25519 + quote-program instructions but PullFeed.fetchUpdateIx(...) or pullFeedSubmitResponseConsensus returns ORACLE_UNAVAILABLE, the integration is using the classic PullFeed path against quote-program infrastructure. Move the integration to managed quote-program updates and canonical quote accounts.The classic PullFeed update helpers reject an unexpected median-response feed hash before constructing signature or submit instructions. Do not catch that error and substitute a different or default account.Classic PullFeed remains available for existing integrations. With on-demand 3.10.6, its update methods forward the exact on-chain scaled variance value. New feed-hash integrations should use managed quote-program updates.This is separate from feed-parameter scaling errors. If simulation succeeds but signed updates fail with oracle validation errors such as RangeExceeded, check the feed parameter units, especially raw v2 maxJobRangePct.PreviousAdvanced Price Feed TutorialNextAuthority-Updated FeedsLast updated 2 months ago","tokens":1006,"squid":"spider-08","role":"Oracle Spider","at":1791342996049,"hash":"f0bd68e6159b65852b7ae7f8dfbb0fa1f43c3fa7"}
{"url":"https://www.metaplex.com/docs/agents/skill","domain":"metaplex.com","title":"Metaplex Skill | Agents","text":"Metaplex Skill is an Agent Skill — a knowledge base that gives AI coding agents accurate, up-to-date knowledge of Metaplex programs, CLI commands, and SDK patterns. SummaryThe Metaplex Skill gives AI coding agents accurate knowledge of all Metaplex programs, CLI commands, and SDK patterns.Covers six programs: Agent Registry, Genesis, Core, Token Metadata, Bubblegum, and Candy MachineSupports CLI, Umi SDK, and Kit SDK approachesWorks with Claude Code, Cursor, Copilot, Codex, Windsurf, and other compatible agentsUses progressive disclosure to minimize token usage while providing full coverageInstead of relying on hallucinated APIs or incorrect flags, your AI agent can reference the Skill to get accurate commands and code on the first try.InstallationInstall the Skill in Claude Code, Cursor, Copilot, or any agent that supports the Agent Skills format.How It WorksLearn how progressive disclosure keeps context lightweight while providing full coverage.Programs CoveredThe Skill covers six Metaplex programs and their full operation sets:ProgramPurposeCLIUmi SDKKit SDKAgent RegistryOn-chain agent identity, wallets, and execution delegationYesYes—GenesisToken launches via launchpool or bonding curve with Raydium graduationYesYes—CoreNext-gen NFTs with plugins and royalty enforcementYesYes—Token MetadataFungible tokens, NFTs, pNFTs, editionsYesYesYesBubblegumCompressed NFTs via Merkle treesYesYes—Core Candy MachineNFT drops with configurable guardsYesYes—Operations SupportedThe Skill provides reference material for three approaches to Metaplex development:CLI (mplx) — Direct execution of Metaplex operations from the terminal. Agent registration (mplx agents), token launches and bonding curve creation (mplx genesis), asset creation, uploads, Candy Machine deployment, tree creation, transfers, and more.Umi SDK — Full programmatic access covering all programs. Agent identity and delegation, Genesis launches and bonding curve swaps, fetches by owner/collection/creator, DAS API queries, delegate management, and plugin configuration.Kit SDK — Token Metadata operations using @solana/kit with minimal dependencies.Compatible AgentsThe Skill works with any AI coding agent that supports the Agent Skills format:Claude CodeCursorGitHub CopilotCodexWindsurfNext StepsInstall the Skill to get startedHow It Works to understand the architecturePrograms & Operations for detailed coverageQuick ReferenceThe Metaplex Skill installs via a single command and provides coverage for six programs through CLI, Umi SDK, and Kit SDK.ItemValueInstall commandnpx skills add metaplexSkill formatAgent SkillsCLI package@metaplex-foundation/cli (mplx)Programs covered6 (Agent Registry, Genesis, Core, Token Metadata, Bubblegum, Candy Machine)SDK approachesUmi SDK (all programs), Kit SDK (Token Metadata only)GlossaryKey terms used throughout the Metaplex Skill documentation.TermDefinitionAgent SkillA structured knowledge base that gives AI coding agents accurate context for a specific domainProgressive disclosureArchitecture where the agent reads a lightweight router first, then loads only the reference files needed for the current taskSKILL.mdThe router file that maps tasks to specific reference filesmplxThe Metaplex CLI tool that provides direct terminal access to all supported programsUmi SDKMetaplex's primary TypeScript SDK framework for programmatic access to all programsKit SDKA lightweight alternative SDK using @solana/kit, currently supporting Token Metadata onlyNotesThe Skill requires an AI coding agent that supports the Agent Skills formatSkill files are static references bundled into your project — re-run the install command to updateThe npx skills add command requires Node.js and npm/npx","tokens":929,"squid":"dotcat","role":"Tooling Spider","at":1791343002732,"hash":"c1f07809567c79a140093eb46de711db4752483e"}
{"url":"https://alt.gov.arbitrum.foundation/security-council/contender/0x33ddb82e68940f0e4c1050885bce8faf5ddd1b93","domain":"alt.gov.arbitrum.foundation","title":"Candidate Profile | Security Council Elections | Arbitrum Governance","text":"Back to ElectionsCandidate ProfileSecurity Council election candidateEmiliano BonassiHead of Product @ConduitIndividual0x33ddb82e68940f0e4c1050885bce8faf5ddd1b93ItalyMotivationMy motivation to sign-up is to continue (I am currently part of the security council) bringing Conduit rollup expertise on the table and support the Arbitrum ecosystem.My day-to-day job is to develop the rollup platform at Conduit and assure rollups operations for 500+ networks - ~250 Orbit Chains and 60+ mainnets. Projects like Proof Of Play, AnimeChain, Gravity, Ethena and IDEX.\nI’ve been working on Arbitrum rollups and contribute to the development of Orbit chains on various fronts like addressing security issues, alt-DAs and L3s, building a deep knowledge and expertise on rollups technologies.ExperienceBuilding and maintaining rollup platform at ConduitSupport and assure rollups operations to Orbit chains like Proof of Play, AnimeChain, Gravity, IDEX, EthenaLead the major upgrades on the biggest set of mainnet rollups since 2023Active in web3 security since 2020, in many war rooms and finding security issues on projects like Curve, Yearn, SynthetixProtocol multisig Sherlock Audit and Optimism Security Council (disclosure)Advocating security practices and building security open-source tools like whitehacks-kitSkillsSolidity9/10Rust6/10Go9/10JavaScript9/10CybersecurityAdvancedCan independently verify multisig transactionsProjectsOptimism Security Council","tokens":363,"squid":"spider-07","role":"Council Spider","at":1791343005906,"hash":"29a0ad2c2efb8c22603cf8f52d98bbe22b4ba1c3"}
{"url":"https://developer.arbitrum.io/arbitrum-essentials/reference/development-frameworks","domain":"developer.arbitrum.io","title":"Development frameworks","text":"ReferenceDevelopment frameworksOverview of development frameworks compatible with Arbitrum, including Hardhat, Foundry, and other tools for building, testing, and deploying smart contracts on Arbitrum chains.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.How is this guide?Debugging toolsOverview of debugging tools for Arbitrum dApp development, including Tenderly and other platforms for transaction simulation, tracing, and smart contract debugging on Arbitrum chains.Mainnet risksUnderstand the risks of deploying on Arbitrum mainnet, including the state of progressive decentralization, smart contract upgrade mechanisms, and trust assumptions for Arbitrum One and Nova.","tokens":785,"squid":"spider-01","role":"Chain Spider","at":1791343007235,"hash":"1d864951034d088f88fa5dc36522378959b04998"}
{"url":"https://docs.arbitrum.foundation/foundational-documents/transparency-report-initial-foundation-setup","domain":"docs.arbitrum.foundation","title":"Transparency report: Initial foundation setup | Arbitrum DAO - Governance docs","text":"✏️Request an updateIntroduction​The establishment of The Arbitrum Foundation, a Cayman Islands foundation company, was a critical first step in the establishment of the DAO. The Arbitrum Foundation serves the ArbitrumDAO community and is governed by it, aiming to foster the growth and development of the Arbitrum ecosystem while remaining accountable to the community.This document acknowledges the actions that were required in advance of the DAO setup in order to legally comply with registration and operational requirements. The Arbitrum Foundation believes it is important for the community to understand all actions taken in the lead-up to DAO formation (especially for one as large as this), and therefore seeks to describe documents and activities conducted by the Foundation on the DAO's behalf.This document sets forth a transparent summary of what has occurred thus far; the structure of a decentralised autonomous organisation (the \"ArbitrumDAO\"), that is governed by holders of $ARB, responsible for fostering, developing, authorising and governing the ArbitrumDAO-governed chains (as defined in the ArbitrumDAO Constitution) and its governance powers over The Arbitrum Foundation.The ArbitrumDAO has the ability to submit Arbitrum Improvement Proposals (\"AIPs\"), vote on them and approve through on-chain execution or actions of The Arbitrum Foundation. The guiding values of The Arbitrum Foundation and ArbitrumDAO are described in Section 5 of the ArbitrumDAO Constitution.Through the submission of AIPs in line with the constitution, the ArbitrumDAO is able to collectively decide and effectuate changes ranging from core protocol technology to non-technical decisions that otherwise impact the community and $ARB tokenholders. Throughout this transparency report below, it's noted where decisions made during Foundation setup can be modified by an AIP, and the process for doing so.1. Foundation Governance: Directors​As a Cayman Islands foundation, The Arbitrum Foundation is required to have at least 1 director responsible for the management and operation of The Arbitrum Foundation, in particular approving and entering into contractual arrangements on behalf of The Arbitrum Foundation (i.e., the parties actually approving and signing agreements). These directors were required to be appointed as part of the initial set-up of the Foundation.The initial directors of The Arbitrum Foundation are the following individuals:Campbell Law is the founder of Silverside Ltd, and co-founder of Provenance Ltd. He has over 30 years' experience in the financial services industry in the Cayman Islands. He has considerable experience working within the offshore world including 11 years as a VP at Goldman Sachs and now focuses on corporate governance for Cayman Islands entities.Edward Noyons is a director of Marfire and co-founder of Autonomous and is focused on providing directorship and DAO services to web3 funds, DAOs / foundations and OpCo’s. He most recently served as an audit director at a Big-4 Audit, Tax and Advisory firm where he worked for 11 years, 8 of which were in the Cayman Islands.Ani Banerjee worked at Citigroup, Cheyne Capital and BlackRock, as an investor, for the first fourteen years of his career. Since 2017 Ani has been a private investor in various companies and advises them closely on strategy and corporate governance.As laid out in the Foundation's governing documents, the ArbitrumDAO has significant authority over the directors as it may remove or elect The Arbitrum Foundation's directors, or expand or reduce the number of directors at any time pursuant to a Non-Constitutional AIP.2. Initial Set-up Costs of The Arbitrum Foundation and ArbitrumDAO and Initial Operating Funds​The Arbitrum Foundation incurred pre-launch costs to set up the Arbitrum DAO and governance. The work included careful consideration and guidance of legal structures and technical expertise and development. This was done in the spirit of providing a safe, legal and technical framework to allow the DAO to self-govern on a trusted platform, and to allow for the safe transfer of the Arbitrum One and Arbitrum Nova networks to the DAO from both a technical and legal perspective.With the launch of the ArbitrumDAO, the responsibility for operation of the Arbitrum network was transferred to the ArbitrumDAO. As part of its responsibilities to the DAO, the Foundation has assumed the costs of paying for operations, blockchain operation, infrastructure, service contracts, and ongoing improvements to the Arbitrum ecosystem. In addition, the net on-chain fee revenue (the net difference between fees collected by on-chain operations and L1 fees paid by the Sequencer) from the Arbitrum One and Arbitrum Nova chains is now being sent to the ArbitrumDAO treasury. As such, the ArbitrumDAO will need to ensure The Arbitrum Foundation is adequately funded going forward to continue operating core infrastructure for the Arbitrum network including the Sequencer and public RPC interface.In total, 7.5% of the token supply was distributed to the Foundation when the token supply was generated. 0.5% of $ARB tokens were needed to complete initiation of the DAO. Of the 0.5%, 0.4% of $ARB tokens were provided as a loan as previously disclosed. The other 0.1% was sold to meet the obligations of initial governance setup and initial and near-term operating funds. This has been distributed to the Foundation in order to satisfy these upfront and near-term costs on behalf of the DAO.These tokens were intended to fund the following expenses:DAO administration setup and registration feesLegal costsChain service provider feesDirector feesFund near-term operating costsContracts with third partiesAside from the distribution to the Administrative Budget Wallet, 35.27% of the token supply was distributed to the on-chain DAO treasury, 11.62% to individual wallets, and 1.13% have been allocated to DAOs in the Arbitrum ecosystem.3. On-Chain DAO Governance​The Governance Structure was established in line with the The Constitution of the Arbitrum DAO.Governance powers breakdown​1. $ARB Tokenholders$ARB tokenholders, who make up the ArbitrumDAO, play the most critical role in the proper functioning of decentralised governance in the pursuit of a trustless, transparent and verifiable Arbitrum ecosystem. As Arbitrum is intended to be a public good, it is only right that governance over it should be directed by those for whom such public good is intended.$ARB token holders have the ability to directly propose, vote on and effectuate on-chain AIPs with respect to the ArbitrumDAO-governed chains.2. Security CouncilThe Security Council is a committee of 12 members of a multi-sig wallet which has the ability to perform both Emergency and delayed Non-Emergency Actions, further detailed in Section 3 of the ArbitrumDAO Constitution.The Security Council was required to be operational at the time the DAO launched, as they would be required to mobilise in cases where a critical vulnerability has been identified that could significantly compromise the integrity or availability of a chain governed by the ArbitrumDAO, or to ensure that any actions of the DAO abide by the rules of the Constitution.The initial Security Council members, split by cohort, are as follows:NOTE: The members list below represents the initial security council members, which are not necessarily the current members; for the list of current members, see Security Council Members.i. September CohortMo Dong is the Co-Founder of Celer Network. Mo received a PhD from the University of Illinois Urbana-Champaign in computer science.0x526C0DA9970E7331d171f86AeD28FAFB5D8A49EFHarry Kalodner is Co-Founder and CTO at Offchain Labs. Harry started working on building Arbitrum while studying at Princeton University.0xf8e1492255d9428c2Fc20A98A1DeB1215C8ffEfdDiane Dai is the Co-Founder of DODO, a leading decentralised trading platform. Diane has extensive marketing experience in Defi space since 2017 and was named to Forbes Asia 30 under 30 in 2022.0x0E5011001cF9c89b0259BC3B050785067495eBf5Caleb Lau has been a software engineer at Etherscan since 2019. He works closely with L2 scaling teams to bring users the Etherscan experience on the explorer front.0x8688515028955734350067695939423222009623Ed Felten is Co-Founder and Chief Scientist at Offchain Labs. Prior to this, Ed served as the Robert E. Kahn Professor of Computer Science and Public Affairs at Princeton University. Ed also served as the Deputy U.S. Chief Technology Officer from 2015-17.0x6e77068823f9D0fE98F80764c21Ec294e4d96AdBBryan Pellegrino is Co-Founder and CEO at LayerZero Labs, an omnichain interoperability protocol. Bryan is a multi-time founder/serial entrepreneur who has been active in crypto for more than 10 years.0x8e6247239CBeB3Eaf9d9a691D01A67e2A9Fea3C5ii. March CohortPatrick McNab Is a Co-founder of Mycelium which has been developing and deploying decentralised financial infrastructure since 2018. Mycelium (previously Tracer DAO) were one of the first protocols deployed on Arbitrum in 2021 and support the Arbitrum ecosystem through running validators and Chainlink nodes.0x566a07C3c932aE6AF74d77c29e5c30D8B1853710Justin Drake has been a researcher at the Ethereum Foundation since 2017. He focuses on Ethereum consensus layer upgrades.0x5280406912EB8Ec677Df66C326BE48f938DC2e44Bartek Kiepuszewski has been a blockchain architect at MakerDAO since 2017. He also co-founded l2beat.com and TokenFlow Insights. Bartek holds a PhD in computer science from Queensland University of Technology.0x0275b3D54a5dDbf8205A75984796eFE8b7357BaeRachel Bousfield has been a software engineer at Offchain Labs since 2021. She is currently leading the development of Stylus.0x5A1FD562271aAC2Dadb51BAAb7760b949D9D81dFPatricio Worthalter has been working full time in the Ethereum space since 2015. In 2018 he founded POAP, a web3 native public good that mints digital collectibles for the preservation of memories.0xf6B6F07862A02C85628B3A9688beae07fEA9C863Yoav Weiss is a security researcher at the Ethereum Foundation and has been building in the Ethereum space since 2017, working on account abstraction (ERC-4337), OpenGSN, L2 security, etc. Yoav brings over 25 years of experience and has developed security technologies used by industry leading companies.0x475816ca2a31D601B4e336f5c2418A67978aBf09Compensation:Security Council members are each paid $5,000 per month in $ARB tokens for their time, expertise, and efforts in serving the community.Security Council Elections:Section 4 of the ArbitrumDAO Constitution describes the Security Council election process.For absolute clarity, as laid out in the Constitution, the DAO may appoint and elect members of the Security Council and may even expand or reduce the powers of the Security Council through a constitutional AIP.3. Data Availability Committee (Arbitrum Nova chain only)Transactions occurring on the Arbitrum Nova chain are settled on Ethereum mainnet, but, unlike transactions occurring on the Arbitrum One chain, the underlying transaction data batches are posted and stored by the members of the Data Availability Committee on a Data Availability Server (and not on Ethereum mainnet). The Committee has already been providing this service for the Arbitrum Nova chain for the past 6 months, ensuring its speed and security.The initial members of the Data Availability Committee of the Nova chain are authorised representatives of the following parties:Reddit, Inc.ConsenSys Software Inc.QuickNode, Inc.P2P.orgGoogle CloudOffchain Labs, Inc.Opensea Innovation Labs Private LimitedData Availability Committee members can be appointed and removed at any time pursuant to a Constitutional AIP approved by the ArbitrumDAO. In the event that a Data Availability Committee member is removed (and not otherwise replaced) pursuant to a Constitutional AIP approved by the ArbitrumDAO, or in the event that a Data Availability Committee member resigns without a replacement, the Security Council may execute an emergency action (9-of-12 approval required) to appoint a replacement for such removed or resigned Data Availability Committee member.The decision was made for a distribution of 20% of the L2 base fee on the Arbitrum Nova chain with a split of 8% to the Data Availability Committee and 12% to the Arbitrum Nova Validators. These entities are critical given the security, availability, and performance that they provide to Arbitrum Nova, with this distribution enabling these groups to provide continued support. This allocation can be reduced, expanded, or eliminated pursuant to a Constitutional AIP approved by the ArbitrumDAO.The DAC and Validators are only given a share of the base fee but not congestion fees, so that no member will be incentivized to promote on-chain congestion. 100% of Nova's congestion fees and the remaining 80% of its base fee is sent to the DAO treasury.4. Arbitrum Voting Protocol ProcedureSection 2 of the ArbitrumDAO Constitution lays out the AIP process and voting procedures, as well as the various categories of AIPs and is not incorporated in this report.There are several governance avenues available, each serving its own purpose.Discourse: https://forum.arbitrum.foundation/ is a discourse forum for governance related discussions. Community members must register for an account before sharing or liking posts.Snapshot: https://snapshot.org/#/arbitrumfoundation.eth is an off-chain voting interface that allows the community to signal sentiment on the proposed AIP.Tally: Tally.xyz serves as the initial on-chain voting platform for the ArbitrumDAO to submit and vote on AIPsTally serves as a front-end user interface that allows DAO members to do several things, namely:Create AIPs;View delegates and their voting share;Re-delegate votes to a different delegate;View current and past AIPs;Vote on AIPs on-chain, interacting with the on-chain governance contracts via the Tally front-end; andView the status of AIP execution during all voting stagesThe process of voting, choice of any of the tools, and length of voting can be changed by the community through a Constitutional AIP.Introduction1. Foundation Governance: Directors2. Initial Set-up Costs of The Arbitrum Foundation and ArbitrumDAO and Initial Operating Funds3. On-Chain DAO Governance","tokens":3582,"squid":"spider-07","role":"Council Spider","at":1791343018559,"hash":"a47268e1f013de69118850120147bc0ad3aedb4e"}
{"url":"https://developer.arbitrum.io/arbitrum-essentials/how-to-estimate-gas","domain":"developer.arbitrum.io","title":"How to estimate gas in Arbitrum","text":"How to estimate gas in ArbitrumLearn 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.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 , 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 fee at the current 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 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 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 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 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 (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\");\nconst { NODE_INTERFACE_ADDRESS } = require(\"@arbitrum/sdk/dist/lib/dataEntities/constants\");\n\n...\n\n// Instantiation of the NodeInterface object\nconst nodeInterface = NodeInterface__factory.connect(\n NODE_INTERFACE_ADDRESS,\n baseL2Provider\n);\nCall gasEstimateComponents() with your transaction's destination address and data:\n// Getting the estimations from NodeInterface.gasEstimateComponents()\nconst gasEstimateComponents = await nodeInterface.callStatic.gasEstimateComponents(destinationAddress, false, txData, {\n blockTag: 'latest',\n});\nExtract the formula variables:\n// Getting useful values for calculating the formula\nconst parentChainGasEstimated = gasEstimateComponents.gasEstimateForL1;\nconst childChainGasUsed = gasEstimateComponents.gasEstimate.sub(gasEstimateComponents.gasEstimateForL1);\nconst childChainEstimatedPrice = gasEstimateComponents.baseFee;\nconst parentChainEstimatedPrice = gasEstimateComponents.l1BaseFeeEstimate.mul(16);\n\n// Calculating some extra values to be able to apply all variables of the formula\n// -------------------------------------------------------------------------------\n// NOTE: parentChainGasEstimated (B in the formula) is calculated based on the child chain's gas price\nconst parentChainCost = parentChainGasEstimated.mul(childChainEstimatedPrice);\n// Guard against zero parent-chain base-fee estimates (some AnyTrust/Orbit configs)\nconst parentChainSize = parentChainEstimatedPrice.eq(0) ? 0 : parentChainCost.div(parentChainEstimatedPrice);\n\n// Setting the basic variables of the formula\nconst P = childChainEstimatedPrice;\nconst L2G = childChainGasUsed;\nconst L1P = parentChainEstimatedPrice;\nconst L1S = parentChainSize;\nCalculate the total fee:\n// L1C (L1 Cost) = L1P * L1S\nconst L1C = L1P.mul(L1S);\n\n// B (Extra Buffer) = L1C / P\nconst B = L1C.div(P);\n\n// G (Gas Limit) = L2G + B\nconst G = L2G.add(B);\n\n// TXFEES (Transaction fees) = P * G\nconst 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';\nimport { NODE_INTERFACE_ADDRESS } from '@arbitrum/sdk/dist/lib/dataEntities/constants';\n\nconst nodeInterface = NodeInterface__factory.connect(NODE_INTERFACE_ADDRESS, childProvider);\n\n// Get parent chain confirmations for a child chain block\nconst { confirmations } = await nodeInterface.functions.getL1Confirmations(blockHash);\n\n// Find which batch contains a specific block\nconst { 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.How is this guide?Arbitrum essentialsCore, language-agnostic guidance for building on Arbitrum — bridging, precompiles, the NodeInterface, and how Arbitrum differs from Ethereum.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.","tokens":2078,"squid":"spider-01","role":"Chain Spider","at":1791343018609,"hash":"d2f5959bc6dcc5256eab16ec7f1712ad78a8e2e9"}
{"url":"https://developer.arbitrum.io/arbitrum-essentials/arbitrum-vs-ethereum","domain":"developer.arbitrum.io","title":"Arbitrum vs Ethereum","text":"Arbitrum vs EthereumWhere Arbitrum behavior differs from Ethereum — gas, block numbers, RPC methods, and Solidity support.Request an updateWhere Arbitrum's behavior differs from Ethereum's: the block gas limit, block numbers and time, RPC methods, Solidity support, and nonce management.\nOverviewWhat changes when you move an Ethereum dApp to Arbitrum.Blocks, gas, and timeHow block numbers, gas limits, and timing differ from Ethereum.RPC methodsExtra transaction types and fields returned by Arbitrum nodes.Solidity supportOpcode and global-variable differences that affect contracts.Nonce managementWhy concurrent submitters must coordinate nonce allocation.How is this guide?Custom gatewayGuide to creating and deploying a custom gateway for specialized token bridging between Ethereum and Arbitrum. For advanced use cases not covered by the standard or generic-custom gateways.Comparison overviewExplore the key differences between Arbitrum and Ethereum, including state transition functions, EVM compatibility, gas handling, and block production. Understand what changes when deploying Ethereum dApps to Arbitrum.","tokens":280,"squid":"spider-01","role":"Chain Spider","at":1791343030516,"hash":"85eb3b0f040514bde00de1341c7de65eb10ddd4b"}
{"url":"https://akash.network/case-studies/envision-labs-accelerates-generative-ai-on-akash","domain":"akash.network","title":"Envision Labs Accelerates Generative AI on Akash","text":"by Zach Horn Case Studies 5 Min. Read Mar 5, 2025 Envision Labs Accelerates Generative AI on Akash 5 Min. Read Mar 5, 2025 \nby Zach Horn \nCase Study\n\nTL;DR: Envision Labs, a DeAI generative AI platform for creators, reduced GPU spend by up to 30% by integrating Akash — training 35+ custom AI models and generating 100,000 images in the first month while maintaining decentralization across multiple providers.\n\nIn early 2024, Envision Labs, a DeAI project reimagining media distribution, faced a pivotal challenge. Envision empowers creators with generative AI tools to produce stunning visual content, but it requires significant GPU power to run AI models across its product suite. Traditional cloud providers proved too expensive to meet surging user demand. Envision’s mission to create a decentralized, creator-centric platform called the Envision DeAI Network required an equally innovative infrastructure solution.\nEnter Akash, the world’s first decentralized cloud computing marketplace. By tapping into underutilized GPUs across a global network of providers, Akash offers on-demand scalability at significantly lower costs. This case study explores how Envision Labs integrated the Akash Supercloud to fuel its generative AI platform, overcoming growth hurdles, cutting costs, and accelerating its mission to democratize creative content generation. After integrating Akash, Envision Labs reduced GPU spend by up to 30%.\nA Decentralized Solution for Growing Demand\nEnvision’s product suite spans multiple AI-driven products:\n\nEnvision generative AI suite: Tools for creating 2D/3D images, custom-trained characters, and videos.\nInteractive mascots: AI-powered avatars reflecting a project or brand’s distinct personality and knowledge base.\nOn-chain IP protection: Copyright proofs are recorded on-chain, ensuring verifiable and transparent ownership.\nIP monetization: Built-in licensing and sales options to turn creative assets into revenue streams.\n\nLaunched in late December, Envision’s first DeAI project rapidly took off: over 35 custom AI models were trained and deployed, collectively generating around 100,000 images in the first month. This surge in adoption underscored the necessity for large-scale GPU availability, but in a manner that supported the decentralization of Envision’s DeAI network.\nChoosing the Akash Supercloud\nTo support the expansion of its generative AI offerings, Envision prioritized the following requirements:\n\nDecentralization and permissionlessness: Avoiding reliance on a single provider aligns with the DeAI Network’s core principles and ensures resilience.\nScalable GPU power: Demand for AI-driven models can spike unpredictably, particularly for custom 3D video or popular character generation, so the ability to scale is crucial to supporting Envision’s operations.\nCompetitive pricing: Cost-effective GPU resources broaden the range of projects and communities Envision can serve at a fraction of the cost of traditional cloud providers.\n\nAkash fits these criteria by providing a global, open marketplace for compute. Providers worldwide bring their GPUs to the network, and projects like Envision can deploy workloads without conventional obstacles like account approvals or the need to commit to expensive reserved instances.\nIntegrating With Akash\nThe Envision Labs team experimented with Akash Console to test deployments, monitor performance, and confirm feasibility. Encouraged by the results, they shifted to a command-line interface (CLI) approach that uses a hot wallet for more direct management and integrations.\nEnvision also incorporated an autoscaling mechanism to seamlessly spin up additional Akash GPU instances when usage spikes and release them as activity tapers off. During the process, technical community members on the Akash Discord offered real-time guidance, helping Envision navigate tasks like wallet setup and transitions between different GPU types (for instance, H100 and A100) to balance availability with current usage.\nOutcomes and Impact\nScalable GPU Usage\nEnvision relies on scaling GPUs at peak times to handle surges in image or video generation requests. This previously cost tens of thousands of dollars monthly, which was reduced by up to 30% after integrating Akash GPUs.\nHigh-Volume Generations\nWith over 35 models trained and 100,000 images generated, the network’s capacity to handle diverse workloads has become a significant draw for Envision’s users.\nDecentralized Resilience\nEnvision’s DeAI Network is built to support several providers to maximize decentralization. Akash has remained the top platform in terms of usage, reflecting its reliability and permissionless structure.\nLooking Ahead\nEnvision’s roadmap includes advanced AI development, such as autonomous agents and deeper content creation explorations, which will further increase GPU needs. The DeAI Network is designed to remain flexible: different providers can join or exit, maintaining a truly decentralized environment that can absorb fluctuations in demand.\nAkash will continue to be integral to Envision’s strategy well into the future. Its open and permissionless nature aligns with Envision’s foundational philosophy: to build AI solutions without needing permission or facing unnecessary provider-imposed constraints.\nEnvision’s experience exemplifies how Akash can fuel demanding generative AI workloads as decentralized compute evolves. This will pave the way for innovation in emerging domains, from digital avatars to large-scale video generation. The work accomplished so far demonstrates that, with the proper infrastructure, the future of AI is both globally scalable and open to all.\nLearn more about Envision here, and join the Envision community on Twitter (X) and Telegram.\nFrequently Asked Questions\nWhat does Envision Labs build?\nA decentralized AI platform for creators offering generative AI tools (2D/3D images, custom characters, video), interactive mascots, on-chain IP protection, and built-in content monetization.\nHow much did Envision Labs save with Akash?\nUp to 30% reduction in GPU spend compared to traditional cloud providers — which previously cost tens of thousands of dollars monthly for their scale of AI model training and inference.\nWhat GPU types does Envision Labs use on Akash?\nH100 and A100 GPUs for their AI generation workloads — they use autoscaling to spin up additional Akash instances during usage spikes and release them as activity tapers off.\nHow does Envision Labs integrate with Akash technically?\nThey use the Akash CLI with a hot wallet for direct management, plus an autoscaling mechanism that programmatically provisions and releases GPU instances based on real-time demand.\nHow many images did Envision generate in their first month on Akash?\nAround 100,000 images from over 35 custom trained AI models — validating Akash’s capacity to handle diverse, high-volume generative AI workloads.\nWhy does decentralization matter for Envision’s platform?\nEnvision’s DeAI Network is designed to avoid single-provider dependency — Akash has been their top platform by usage, proving decentralized infrastructure can be both reliable and permissionless.\nWhat is Envision’s future roadmap on Akash?\nAdvanced AI development including autonomous agents and deeper content creation — requiring even more GPU capacity that Akash’s open marketplace can scale to meet. \nShare this Case Study\n\nSee how Akash cut costs by 60%. Start with $100 Free Credits.\n\nShare this Case Study\n\nnote\n\ntip\n\nCaution\n\nDanger","tokens":1879,"squid":"spider-03","role":"Compute Spider","at":1791343030561,"hash":"7bea6ca81056e8f240ab1376238112ef6286f547"}
{"url":"https://developer.arbitrum.io/arbitrum-essentials/arbitrum-vs-ethereum/comparison-overview","domain":"developer.arbitrum.io","title":"Differences between Arbitrum and Ethereum: Overview","text":"Arbitrum vs EthereumDifferences between Arbitrum and Ethereum: OverviewExplore the key differences between Arbitrum and Ethereum, including state transition functions, EVM compatibility, gas handling, and block production. Understand what changes when deploying Ethereum dApps to Arbitrum.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. 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 .\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 , 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.\n 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).\n (go-Ethereum) is one of the primary 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 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.How is this guide?Arbitrum vs EthereumWhere Arbitrum behavior differs from Ethereum — gas, block numbers, RPC methods, and Solidity support.Block gas limit, numbers and timeUnderstand how Arbitrum handles block gas limits, block numbers, and transaction timing differently from Ethereum. Learn about parent chain gas components and block.number behavior on Arbitrum.","tokens":1394,"squid":"spider-01","role":"Chain Spider","at":1791343052336,"hash":"d946f24ed2b82c42ca846078125925ad77601886"}
{"url":"https://forum.arbitrum.foundation/t/team-6-an-eip-4824-powered-daouri-for-the-arbitrum-dao/25371/1","domain":"forum.arbitrum.foundation","title":"Team #6: An (EIP-4824 powered) daoURI for the Arbitrum DAO - Archive / GovHack Brussels - Arbitrum","text":"The Arbitrum Foundation notified the Security Council on the need to perform a potential Emergency action. Following a review of the details and known risks, the Security Council decided to execute the upgrade and it was completed at 11:30 EST on 2nd October 2026.\nThis report provides an overview of the risks that required the Security Council Action:\n\nAdd a permissionless guard for the One-Step Proof of BoLD on Arbitrum One\n\nTemporarily pause activation of new Stylus contracts on Arbitrum One & Nova\n\nKey point: To date, known bugs for Stylus primarily impact chain liveness (e.g., denial of service attacks) and do not put any user funds at risk.\nWhy was this action taken\nLet’s take this opportunity to explain why action was taken on two separate issues concerning BoLD and Stylus.\nInstalling the guard for One-Step Proof of BoLD. Given the rise of AI-assisted attacks, we have implemented a precautionary approach that allows anyone to pause settlement of Arbitrum One on Ethereum if there are at least two conflicting answers that pass at the same level in which only one should be valid and pass. This is to halt a class of publicly verifiable and detectable attacks that exploit a bug in the one-step proof. If halted, Arbitrum One will continue to process as normal except that messages from Arbitrum One to Ethereum, such as withdrawals, that are not yet confirmed will have to wait. This provides time for the Security Council to deploy a fix for the bug and resume the rollup.\nPreventing activation of new Stylus contracts. AI-assisted tooling has led to an increasing number of sophisticated attacks on hand-crafted WASM programs that do not use the standard Stylus compiler toolchain. These programs are specifically designed to cause unexpected behaviors such as degrading the chain’s performance for all other users. To date, no attacks have been discovered that permits theft of user funds.\nNew ArbOS releases have patched several reported bugs and known attacks over the past few months, but out of an abundance of caution, we have decided to temporarily pause new activations of Stylus contracts. This was executed as an emergency action to prevent the deployment of new hand-crafted WASM programs that are not yet patched by the current version of ArbOS on the Arbitrum network.\nThe Arbitrum Foundation has informed the Security Council that they will work with the ArbitrumDAO to discuss next steps on the timeline and manner for enabling activation of new Stylus contracts. The Arbitrum community remains confident in the value of Stylus and want to preserve these use cases while taking preventative measures against Stylus-based attack vectors as AI-assisted attack tooling continues to evolve.\nImpact on builders and users\n\nNo new activations. New Stylus contracts cannot be activated during the pause including new versions of existing applications that require activation.\n\nExisting contracts are not paused. Already-active Stylus contracts continue to execute until expiration. This pause does not deactivate them.\n\nThe ArbOS 61 upgrade renewed all active contracts on Arbitrum One, so no currently active contract expires before August 20, 2027.\n\nRenewal via keepalive stays permissionless and is unaffected by the pause.\n\nReactivating an expired contract, or one that needs to be updated after a Stylus version change, is paused.\n\nUsing/calling any activated Stylus contract stays permissionless for all users and developers.\n\nNo impact on EVM. Solidity (EVM) contract deployment and execution are unaffected by this Security Council action.\n\nSecurity Council Actions\nThere are two actions bundled into a single payload:\n\nOne-Step Proof Guard. The L1UpgradeExecutor gives a new pause contract (PauseExecutor) the ability to pause and nothing else. The new pause contract grants the guard (OspSoundnessGuard) PAUSER_ROLE to use it. Anyone can show the guard two conflicting answers to the same step of an open challenge. If the one-step proof accepts both, the guard has the pause contract put Arbitrum One’s settlement to Ethereum on hold.\n\nStylus deactivation. The Security Council called ArbOwner.setWasmActivationGas(2^64 - 1) to raise the Stylus activation gas requirement on Arbitrum One and Nova. This makes activation prohibitively expensive and effectively disables new activations. This is a configuration change and does not require an ArbOS upgrade.\n\nThe Security Council signed the following transactions to update the configuration:\n\nEthereum: Ethereum Transaction Hash: 0x30732bb7d2... | Etherscan\nArbitrum One:\nArbitrum One Transaction Hash: 0x9eb3a4be3b... | Arbitrum One\nArbitrum Nova:\nArbitrum Nova transaction 0x79e0fed470dff7a22059b108e3f8f42eddd2b580a6771594060c4e7326c5f984 | Blockscout\n\nAn external audit was conducted for the OSP Guard contracts. No audit is required for the Stylus deactivation as it is only updating a single parameter in the ArbOS configuration.\n\n Team #6: An (EIP-4824 powered) daoURI for the Arbitrum DAO \n\n ArchiveGovHack Brussels\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jul 2024\n\n 1 / 54\n\n Jul 2024\n\n Oct 2024\n\n post by amanwithwings on Jul 6, 2024\n\n amanwithwings\n\nTrack: GovTech\nChallenge Statement: “Data surrounding the Arbitrum DAO is scattered all over the place. How can we increase data availability and accessibility without losing decentralisation?”\nMembers: Aman and Rashmi Abbigeri\nTeam Lead contact name or alias: Aman (Telegram: amanwithwings)\nPITCH: daoURI for Arbitrum DAO🚀 | Loom\n\nAbstract\nWe propose that the Arbitrum DAO takes control of its data by publishing a daoURI onchain. The daoURI, following EIP-4824, will create a single source of truth on the DAO, that cannot be altered by external agencies, is fully manageable via governance, bringing helpful context on the DAO onchain. This will be helpful for newcomers, tooling providers, and experienced governooors alike.\nDAOstar received a grant from the Arbitrum Foundation to improve the adoption of EIP-4824 in the Arbitrum ecosystem. We are allocating a portion of that grant to steward this proposal. Adopting EIP-4824 requires no additional spend from the DAO treasury, and it makes no change to its smart contracts or governance structure.\nMotivation\nThe Arbitrum DAO is one of the largest DAOs, and there is a lot of data surrounding it. This dataset grows with every new initiative and has multiple components that may not be very visible from the “outside”. For example, consider the following questions:\n\nWho are the current Security Council, Arbitrum Research & Development Collective, Procurement Committee members? (Answer: you can search the respective forum post to find this)\nCan you share a location that tracks all DAO-owned/managed multisig addresses? (Answer: this could be https://www.arbwallets.xyz/)\nCan you share a status update on the DAO’s grant spending? (Answer: R3gen Finance reports this on the forum)\nWhere can we see delegate performance? (Answer: KarmaGAP or Tally)\nHow much in sequencer fees is being collected? (Answer: there is a dashboard for this)\nWhat orbit chains exist? (Answer: the ecosystem page tracks this)\nWhere to find recordings and transcripts of public meetings? (Answer: I’m not sure!)\n\nFor an active participant, these answers might not be very hard. But for the majority of people who are not active participants of the DAO, and even for tooling providers, collecting this information requires a painstaking amount of manual effort. This leads to inconsistencies, errors and outdated information.\nThere are over 200 DAOs at the moment with a treasury size of over $1M, and collecting information on them manually is becoming an exponentially difficult task. EIP-4824 was authored by DAOstar with the support from the Ethereum Foundation, Gnosis, Etherscan, DeepDAO, Snapshot, and a large number of DAO tooling companies, to create a better infrastructure for DAO data.\nAdopting EIP-4824 essentially means that the DAO publishes a daoURI onchain. daoURIs have a standard JSON-LD format:\n{\n\"@context\": \"http://www.daostar.org/schemas\",\n\"type\": \"DAO\",\n\"name\": \"<name of the DAO>\",\n\"description\": \"<description>\",\n\"membersURI\": \"<URI>\",\n\"proposalsURI\": \"<URI>\",\n\"activityLogURI\": \"<URI>\",\n\"governanceURI\": \"<URI>\",\n\"contractsRegistryURI\": \"<URI>\"\n}\n\nIt contains information on governance, members, activities and contracts by default. Outside of the endpoints mentioned above, a DAO can also choose to publish information that is specifically important to it. For Arbitrum, this could be information about orbit chains, different multi-sigs and councils, spending, sequencer fees, link to its constitution, etc. Essentially, the daoURI creates an “official repository” of information on the DAO.\nHere are some examples of how the daoURI could be used:\n\nIt can be used to bring more context to contracts on block explorers. For example, we could go from this:\n\n1600×847 168 KB\nto this:\n1600×842 171 KB\n\nWe can make DAO data easily and freely available to everyone\n\nFor example, Arbitrum DAO’s current DeepDAO profile misses a ton of info - contracts, or revenue, or governance guardrails (councils and multi-sigs), etc. Messari’s Arbitrum DAO dashboard requires a paid membership to access, which could also be due to the difficulty of collecting and presenting DAO data (thus making it too valuable to give away for free). By making access to this information easy, we can greatly improve the DAO’s transparency. i.e, go from: 1600×786 291 KB\nto this:\n1600×903 249 KB\n\ndaoURI makes it much easier to structure metadata improvements.\n\nA specific example that surfaced during Arbitrum GovHack (thanks to Paulo Fonseca): onchain proposals at Arbitrum DAO (or any DAO for that matter) do not reference a forum discussion. This takes away a lot of available information. If we wanted to change this, we could achieve it easily by enforcing a discussionURI field inside the proposalURI (which is a standard component of daoURI). Tally, Aragon, Snapshot X, and most governance tooling providers are members of DAOstar. Extending the standard will create an easy upgrade pathway for them and this change would reflect the change across the ecosystem.\nTo summarize, a daoURI creates a source of truth for metadata, that can represent the present state of the DAO, and is easily accessible for onchain and offchain tools. This proposal carries no additional cost, or changes to any existing smart contract or process. It’s a step in the right direction with no downside.\nRationale\nThis proposal aligns with the Arbitrum’s mission and community values, by making the Arbitrum DAO more open, accessible, and inclusive to participants and tools alike. The initiative:\n\nsignificantly lowers the high threshold of context and background work required to start understanding and meaningfully contributing to the DAO;\nIt increases accountability over the board as more information is now freely available;\nIt decreases administrative overhead and maintenance as were converging on a single point to publish and consume data.\n\nSpecifications\nExecution is a simple contract call to the EIP-4824 Registration Factory which deploys a new registration contract that’ll store the daoURI. The registration will be on Arbitrum One network, setting the DAO’s Governor timelock as admin, and managers as the DAO decides.\nA DAO that runs the same configuration as Arbitrum DAO and has adopted EIP-4824 is Unlock Protocol. We are adding that transaction here for reference, along with successful proposals at Treasure and 1inch that were executed through their respective treasury safes.\nSteps to Implement\nCreate a daoURI for Arbitrum DAO: Based on conversations with different contributors during the Arbitrum GovHack, the daoURI can include a description on the DAO, a paginated list of all DAO voters, a list of all proposals (with title, timestamp, status and soon a discussion link), link to governance documents, list of all contracts owned or managed by the DAO, link to dashboards on protocol revenue, orbit chains and delegate performance. It will be stored on IPFS.\nNote that this is a starting point. The daoURI of Arbitrum DAO will continuously evolve and become more comprehensive over time.\nPublish the daoURI onchain: As detailed in the execution summary above, this will be a simple smart contract call to deploy a new contract on Arbitrum One.\nMaintain the daoURI: Though daoURI is fully manageable through governance, it may not be practically feasible to initiate an onchain vote for every upgrade. To solve this, the DAO can set one or many manager to manage its daoURI. The Arbitrum Foundation might be a good candidate. If needed, DAOstar can commit to maintaining Arbitrum DAO’s daoURI for a year for at additional cost. Managers can only update daoURIs. They can be added or removed easily by the DAO.\nTo keep the daoURI a community-led effort, we suggest that whoever is set as a manager maintain a forum topic to discuss updates. That way, any Arbitrum DAO member can publicly request to add a missing piece of info to the daoURI.\nTimeline\nCreation of daoURI V0.1 (includes conversations with delegates, service providers, the Arbitrum Foundation, and all other participants through the forum, led by DAOstar): 4 weeks\nTesting (ensuring that the subURIs work well & that any static data is either uploaded to IPFS or hosted by a trusted 3rd party, for example the Arbitrum Foundation): 2 weeks\nOverall: 6 weeks before the proposal is ready to be executed\nOverall Cost\nThis proposal does not require any transfer of funds from the DAO treasury.\nSpecial thanks to @Bobbay, @Matt_StableLab, @raam, @coolhorsegirl, @Srijith-Questbook, @Sinkas, Hayden (BlockworksResearch) and Nick Nahaghi (Hats) for feedback and edits; @krst, @AlexLumley, @Frisson, @dk3, and George Beall (Gauntlet) for the expert sessions, and to Klaus and the rest of the GovHack team for making an awesome event happen at Brussels!\nEIP-4824 has already been adopted by Snapshot, Aragon, Treasure, 1inch, Optimism Collective (through the Optimism Foundation), and multiple frameworks and DAOs. The effort is supported by grants from the Arbitrum Foundation, Optimism Collective, ENS, Gnosis, Solana and many other stakeholders of the web3 ecosystem. Thank you to everyone:)\n\n Arbitrum daoURI Proposal Security Review\n\n 16 Jul 2024 - Open Discussion of Proposals Governance Call\n\n 30 Jul 2024 - Open Discussion of Proposals Governance Call\n\n Curia Delegate Communication Thread\n\n An EIP-4824 powered daoURI for Arbitrum DAO\n\n 10\n\n 3\n\n 2\n\n 2\n\n 2\n\n read \n\n 11\n min\n\n post by milk-cash on Jul 6, 2024\n\n milk-cash\n\n Interesting Lowdown @amanwithwings :This proposal is all about creating a one-stop shop for all the important data related to the Arbitrum DAO.\nSo anyone can easily access and use the info they need. The idea is to make it easier for people to get involved, make informed decisions, and generally make the DAO more transparent and accessible.\nThe Good Stuff: It tackles the problem of scattered data, which can be a real pain to deal with. It’s based on a standardized format (EIP-4824), so it’s not just some custom solution that might not work with other tools. It doesn’t require any extra cash from the DAO treasury, which is always a plus. By making it easier for users to access and interact with the DAO’s data, the daoURI could lead to more on-chain activity, such as:\nMore informed decision-making Increased transparency Simplified data access Improved tooling and integrations More efficient governance Increased adoption \n\nThe Questions:\nHow are we gonna set this thing up and keep it running smoothly?\nHow do we make sure the data is accurate and complete? How do we get people to actually use this thing, and what kind of support do we need to offer?\nWhat kind of security measures do we need to put in place to protect the daoURI from potential attacks?\nNext Steps:\nLet’s keep discussing the details and figure out how to make this work in practice.\nWe should weigh the pros and cons of adopting the daoURI and think about how it’ll impact the DAO as a whole.\nWe need to make sure this proposal aligns with the Arbitrum DAO’s mission and values, and that it’ll actually make a positive difference in the ecosystem.\nThe daoURI has the potential to increase on-chain activity, drive more engagement, and make a positive impact on the Arbitrum DAO ecosystem.\n\n post by paulofonseca on Jul 6, 2024\n\n paulofonseca\n\n Love this! =)\nAdopting this standard would also help governance front-ends and aggregators gain proper data about Arbitrum DAO.\nWe will use it for proposals.app for sure!\n\n post by coolhorsegirl on Jul 7, 2024\n\n coolhorsegirl\n\n No brainer! Tally would definitely use this.\n\n post by amanwithwings on Jul 11, 2024\n\n amanwithwings\n\n milk-cash\n\n Not sure if I’m replying to an AI-agent, but everyone deserves answers.\n\nHow are we gonna set this thing up and keep it running smoothly?\nHow do we make sure the data is accurate and complete? How do we get people to actually use this thing, and what kind of support do we need to offer?\n\nIt’s not easy to get used to new systems, but what we are planning to do is:\n\nCollect extensive feedback from all stakeholders to create a good v0.1 daoURI.\nGet the right incentives in place so that we can keep making it better.\n\nSince subURIs can be dynamic, enriching most of the dynamic data points (like data on proposals, voters, and contract activity) can be automated. We’ll use trusted partners like Snapshot, Tally, and Boardroom for some of the governance data.\ndaoURI can potentially be integrated by other dashboards at Arbitrum DAO. For example, the Arbitrum DAO Dashboard (by @prometheus_PH, @Entropy, and others at GovHack), @paulofonseca’s Proposals App, Etherscan, DeepDAO, and other tools could refer to this source of truth for a copy of “official DAO data”. We are already working with some of these teams to make the integrations happen. These integrations, along with the legitimacy that anything published in the daoURI is most likely the best version of data on Arbitrum DAO, solve the incentive problem of updating daoURIs to a large extent.\n\nWhat kind of security measures do we need to put in place to protect the daoURI from potential attacks?\n\ndaoURI data can only be edited by initiating an onchain vote (to rewrite the daoURI) or through the manager (assuming the DAO sets one). Since daoURI is an important record, managers should be highly trusted 3rd parties with the right interests for Arbitrum DAO’s success. Based on the suggestions of @krst and other delagates, this could be the Arbitrum Foundation, and from my brief conversation with @stonecoldpat at ETH CC '24, the Foundation is open to taking on this responsibility.\nWe envision daoURI updates to be not-so-frequent. A structure we have in mind for ensuring community enagagement on daoURI updates is the manager maintaining a forum thread to curate daoURI update requests and doing updates every month or so. The DAO may decide to upload more data to its daoURI periodically (say a copy of forum discussions) in the future.\nBefore this proposal goes to a vote, we’ll create a minimum viable framework to handle daoURI updates and do away with false legitimacy (people/projects wanting to be in the daoURI to show that there are official parters of the DAO) and spam.\nNext steps for me: chatting with delegates, service providers and other stakeholders in the Arbitrum ecosystem to discover the possibility of what could Arbitrum DAO’s daoURI be. If you’d like to get involved, please DM!\n\n 19 days later\n\n post by amanwithwings on Jul 30, 2024\n\n amanwithwings\n\n An improved version of Arbitrum DAO’s daoURI: https://ipfs.io/ipfs/QmbAFHUiVTDpSykuHVnc8BRbMy29hSdiVzR2LiFoGdFqcT\nScreenshot 2024-07-30 at 6.29.18 PM2898×758 324 KB\n\n Security analysis of EIP-4824 adoption by Arbitrum DAO\n\n post by Pepperoni_Jo3 on Aug 1, 2024\n\n Pepperoni_Jo3\n\n We worked with @amanwithwings at Treasure DAO and found him helpful, and the overall implementation was smooth. Conscious anything with code can start to make people uncomfortable, so it may be worth speaking to the ARDC and getting them to vet the upgrade.\n\n post by amanwithwings on Aug 5, 2024\n\n amanwithwings\n\n Thanks for the support, @Pepperoni_Jo3. Will take this through the ARDC. After conversations with key delegates, I’m considering providing the DAO two options for implementation:\noption 1: as suggested above, deploy a registration contract through the timelock (which requires as onchain vote)\noption 2: use arbitrumfoundation.eth to set daoURI as a txt record. This will not require an onchain vote, or onchain actions by the timelock as they DAO will only need to signal acceptance and the signers of arbitrumfoundation.eth will be able to execute it.\n\n post by amanwithwings on Aug 13, 2024\n\n amanwithwings\n\n Hey all, attaching an improved version of daoURI here: https://ipfs.io/ipfs/QmUrBuJLBCZKnnEebwRe2Yqh3fk39H2mtqPQjMPUwVC1Ap\nChanges:\nproposalsURI structure is the following:\nProposals {\noffchain : ...\nonchain: ... }\n\nThey both are ordered from latest to oldest. We have included all the relevant data points we could from Snapshot and Tally.\nFor Members URI, member lists include:\nSnapshot : voters, space members, moderators, space admins\nTally: delegates, organizationMembers ( In Tally API, all voters are \"delegates\" )\n\nPagination: both offchain and onchain data have their own cursor;\nCaching: All results are cached and cache is invalidated on refresh param\nOnchain id: In Tally, DAO Name, for example “arbitrum” , “ens”, are then mapped with an orgnaization ID\nTo fetch onchain data, the DAO name as on Tally needs to be provided\n\n post by BlockworksResearch on Aug 15, 2024\n\n BlockworksResearch\n\n This is great work, and we find this would be extremely useful for the DAO. However, this proposal has not been given the sufficient 7-day minimum time in the forum to be pushed to Snapshot. We politely ask that this be uploaded in the proposals discussion and then this can be revisited. Additionally, was this proposal ever vetted by the security/auditing members of the ARDC?\nThat said, Blockworks Research will be voting AGAINST this proposal on Snapshot. Although we do want to see this proposed again with proper process.\n\n Blockworks Research – Delegate Communication Thread\n\n post by KlausBrave on Aug 15, 2024\n\n KlausBrave\n\n To clarify, this proposal has been in the forum since GovHack on July 7th, and there has been a back-and-forth discussion. Are you suggesting that is insufficient?\n\n post by BlockworksResearch on Aug 15, 2024\n\n BlockworksResearch\n\n Yes, as the proposal should be filed under “proposals” subcategory of the forums for proper visibility first. It is highly unlikely that the GovHack Brussels subcategory sees the same visibility as the proposals subcategory. And then there’s still the matter that this should likely go through an ARDC security provider for audits. Ideally, it should be posted on the forum in the proper category to be gestated on for a week, and then the week following it would proceed to a Snapshot vote, and then prior to a Tally vote it should receive vetting from an ARDC security member.\nAgain that said, this is extremely promising, so we make these comments not to dissuade but rather to have this pushed sooner rather than later.\n\n post by KlausBrave on Aug 15, 2024\n\n KlausBrave\n\n Fair enough, as organiser of GovHack we didn’t provide explicit guidance on how a proposal should migrate after GovHack to the proposals category.\nI think it should stay in the GovHack section as a record.\nThen people should clone their proposals and put them in the Proposals category if they plan on taking them forward. Do you think that works?\nAlso @cliffton.eth @raam as you made the Forum category and @paulofonseca @tobsch I’d appreciate you weighing in on this as you are pursuing moving your proposals forward.\nI want to establish a best practice for this going forward to avoid a repeat of this issue.\n\n post by BlockworksResearch on Aug 15, 2024\n\n BlockworksResearch\n\n Cloning the proposal and inserting it into to the subcategory sounds great to us, moving forward we could also begin to treat GovHack subcategories as canonical categories for the proposal pipeline, although this should be made explicit. Also, there could be some forum clutter if we take that approach.\n\n post by ermia on Aug 15, 2024\n\n ermia\n\n Looks like a good idea. Voting in favor, assuming our security partners take care of code audit and its impact analysis.\n\n post by amanwithwings on Aug 15, 2024\n\n amanwithwings\n\n Thank you for upholding this standard, @BlockworksResearch, and thank you for weighing in, @KlausBrave. I can repost it, no worries.\nI actually asked in the previous Governance call on 31st July if the proposal needed to be reposted for more visibility, but nobody replied yes. (It was in the chat after my presentation, so that might have also been a visibility issue.)\n\n post by EzR3aL on Aug 16, 2024\n\n EzR3aL\n\n Voting yes in a future snapshot. This benefits transparency and makes it easier to access information.\nBut today im voting against to recreate this proposal and then publish it again with sufficient time to discuss.\n\n EzR3aL Delegate Communication Thread\n\n post by amanwithwings on Aug 16, 2024\n\n amanwithwings\n\n Hey all, created a new post in the “proposals” category: An EIP-4824 powered daoURI for Arbitrum DAO \n\n post by jameskbh on Aug 16, 2024\n\n jameskbh\n\n For tracking purposes, I voted Against this proposal so we can follow the proper processes.\nThe subject itself is interesting, and I will post some questions in the other post.\n\n post by 0xDonPepe on Aug 17, 2024\n\n 0xDonPepe\n\n I voted “FOR” in Snapshot because having an on-chain daoURI is like giving Arbitrum DAO a cheat sheet for all its important info—no more digging around for answers. It’s a simple move that makes everything transparent and easy to find. Plus, it costs nothing. Think of it as giving the DAO a GPS instead of making everyone ask for directions.\n\n Load more posts below","tokens":6512,"squid":"spider-07","role":"Council Spider","at":1791343053017,"hash":"611332f728498c36b9bf9014dde061e88eb358db"}
{"url":"https://developer.arbitrum.io/arbitrum-essentials/bridging","domain":"developer.arbitrum.io","title":"Bridging","text":"BridgingMove ETH, tokens, and messages between parent and child chains.Request an updateHow assets and messages move between a parent chain and a child Arbitrum chain: deposits, withdrawals, cross-chain messaging, and token gateway configuration.\nOverviewChoose the right approach for bridging assets and messages.Deposit ETHSend ETH and messages from a parent chain to a child chain.Deposit tokensMove ERC-20 tokens from a parent chain to a child chain.Withdraw ETHSend ETH and messages from a child chain back to the parent chain.Withdraw tokensMove ERC-20 tokens back to the parent chain.Cross-chain messagingRetryable tickets, ArbSys, and the Outbox, with a worked example.Standard gatewayBridge an ERC-20 with no custom configuration.Generic-custom gatewayAdd custom child-chain token behavior on the built-in bridge.Custom gatewayBuild a gateway for cases the standard gateways don't cover.Custom gas token chainsSDK support for chains that use a gas token other than ETH.L1 to L3 teleportationBridge from Ethereum to an Arbitrum L3 in a single transaction.How is this guide?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.OverviewChoose the right approach for bridging assets and messages between Ethereum and Arbitrum.","tokens":348,"squid":"spider-01","role":"Chain Spider","at":1791343075731,"hash":"acc6e903220b56b8453f86a267f068ee927983de"}
{"url":"https://akash.network/blog/what-burn-mint-equilibrium-means-for-akash","domain":"akash.network","title":"What Burn-Mint Equilibrium Means for Akash","text":"By Michelle Javed\nTL;DR:\nThe Burn-Mint Equilibrium (BME) Incentivized Testnet wrapped up on March 4, 2026 after two weeks of intensive stress-testing. The testnet ran 52 scenarios across 11 categories, putting the new economic model through its paces with $10,000 in AKT rewards incentivizing participation.\nBME replaces traditional inflation with a burn-and-mint mechanism: users burn AKT to mint ACT (a USD-pegged pricing unit) when deploying compute, and providers receive stable payments regardless of market conditions. The dynamic Collateralization Ratio and circuit-breaker system were key focus areas during testing, ensuring the network can halt minting automatically if volatility threatens the peg.\nThe on-chain governance vote for BME launched March 7, with the mainnet upgrade scheduled for March 23 at 14:00 UTC. This is one of the most significant economic upgrades in Akash history, directly tying AKT scarcity to real network demand.\nWhy BME is Crucial for DePIN\nEvery DePIN hits the same wall. You either give users stable pricing and watch your token become irrelevant, or you force native token payments and watch enterprises walk away.\nOffering Stable payments drive adoption but weaken the token. Users pay in USDC, bypass the native asset entirely, and token holders watch revenue grow while price stagnates.\nForcing native token payments creates a different problem because volatility suppresses enterprise interest. No one deploys a 30-day AI training job when compute costs might swing 20% on a liquidation cascade. Providers face the same pressure. Electricity bills and hardware costs don’t fluctuate with token markets, so revenue stability matters just as much on the supply side.\nAEP-23 solved this by allowing tenants to pay in USDC while providers received stable USD-denominated settlements. The system worked well for driving adoption and revenue growth across the network. But the tradeoff became impossible to ignore. When tenants pay directly in USDC, demand for AKT diminishes. Staking rewards distributed from settlement fees proved insufficient to sustain strong token economics, and AKT’s role as the fundamental economic unit of the network weakened even as usage grew.\nThe introduction of Burn-Mint Equilibrium (BME) through AEP-76 resolves this tension by making AKT essential to every transaction while maintaining the stable USD experience users expect. It preserves stable pricing for all participants while creating structural demand for AKT, and it does so without imposing extractive fees.\nWe ran a dedicated incentivized testnet to validate these mechanics under real conditions. Here is what we built, what we observed, what surprised us, and what comes next.\nBME Tokenomics Overview\nAt the core of BME are two tokens working in tandem.\nAKT remains the network’s value-accruing asset, used for staking, governance, and settlement. ACT (Akash Compute Token) is a non-transferable, USD-pegged compute credit that exists solely to pay for infrastructure resources.\nWhen a tenant needs compute capacity, they burn AKT at the current oracle price to mint ACT. If AKT trades at 1.14andatenantneeds1,000 in compute credits, approximately 877 AKT gets burned to mint 1,000 ACT. The tenant now holds a dollar-denominated balance with no price volatility and no exposure to token markets, just credits they spend on compute.\nThe tenant then deploys workloads and consumes ACT over time as providers deliver compute resources. At settlement, the protocol burns the consumed ACT and mints fresh AKT to pay providers based on the current oracle price at that moment.\nThis is where the deflationary pressure comes from. If AKT moved from 1.14to1.50 during the lease, the protocol only needs to mint 667 AKT to cover the $1,000 settlement. The tenant burned 877 and the provider received 667, which means 210 AKT are permanently removed from supply.\nEvery dollar spent on Akash infrastructure creates direct AKT demand and permanent supply reduction.\n\nThe Vault and Circuit Breakers\nWhen tenants burn AKT to mint ACT, those tokens enter a module account that tracks “remint credits” for future provider payouts.\nThis creates immediate supply reduction.\nIf the network holds $10 million in outstanding ACT credits backed by 8.77 million AKT in the vault, those tokens exit circulating supply. They cannot be traded, accessed by exchanges, or influence price discovery until provider settlement occurs.\nThe vault operates as a volatility buffer. When AKT appreciates between tenant deposits and provider settlements, the vault holds more dollar-denominated value than required to fulfill obligations. This surplus materializes as net burns when providers receive payment. The collateral ratio, meaning the vault’s AKT value divided by outstanding ACT obligations, serves as the system’s primary health metric.\nThat ratio relies on oracle prices from dual feeds (Osmosis TWAP and external sources) with medianization to prevent manipulation. Time-weighted averaging over 30-minute windows smooths volatility and raises the cost of any manipulation attempt.\nWhen AKT declines, the vault absorbs the impact. Circuit breakers activate at defined thresholds. At a 0.95 collateral ratio, enhanced monitoring triggers a warning state. At 0.90, new ACT minting throttles while existing settlements continue uninterrupted. This design ensures providers always receive payment while preventing destabilizing spirals during periods of extreme volatility.\nThe system self-corrects through arbitrage. Price movements create opportunities that naturally restore equilibrium without manual intervention.\n\nBME Incentivized Testnet\nBME is elegant on paper. The math is clean and the incentive alignment makes sense in theory\nBut we have been in this space long enough to know that tokenomic mechanisms that look perfect in simulation have a long history of failing on contact with actual users, actual load, and actual adversarial behavior.\nWe designed the incentivized testnet around three questions that would determine whether BME was ready for production.\nFirst, does the AKT-to-ACT conversion hold up under heavy load? The mint and burn operations are the heartbeat of BME. If they degrade under throughput, nothing else matters.\nSecond, does the circuit breaker trigger correctly at every threshold? The circuit breaker is the system’s safety net. If it fires too early, it disrupts normal operations. If it fires too late or not at all, the vault is exposed.\nThe third was whether there are bugs that only surface under adversarial conditions. We offered bounties specifically to incentivize participants to stress-test edge cases we might not have anticipated.\nTestnet Observations\nThe conversion pipeline was rock solid. AKT-to-ACT minting and ACT-to-AKT burn were incredibly stable even in the heaviest periods of testnet use, with no unexpected circuit breaker invocations and no other stability issues. The most critical path in the system held without a single issue across the full duration of the testnet.\nThe testnet had two dedicated periods for circuit breaker testing: 24 hours of circuit breaker halt testing and 24 additional hours of circuit breaker warning testing. The circuit breaker behaved as intended through all testing periods with very granular tests leveled against it.\nCircuit breaker thresholds and expected behavior in the halt state were flawless. Minting stopped when it should have stopped, settlements continued when they should have continued, and the system resumed cleanly once conditions normalized.\nThe warning state is where things got interesting.\nThe Warning-State Bug\n\nCollateral ratio in the 90–95% range should trigger a warning state (continued minting, enhanced monitoring)\nInstead, the system was jumping straight to halt, cutting off new ACT creation prematurely\nWe identified the root cause, patched it, and rolled the fix into testnet\nAll subsequent circuit breaker testing passed without a single failure\nThis is the kind of edge case that only surfaces with real participants against real thresholds, and exactly why incentivized testnets exist\n\nWhat Held Up\n\nDespite bounties to incentivize discovery, no additional bugs were found\nBME behavior, ACT use in deployments, provider settlements, and pointed security validations all came back clean\nOracle medianization, TWAP smoothing, and vault accounting ran cleanly through conditions designed to break them\n\nWhy Now\nAI compute demand is bottlenecked by supply constraints that centralized providers cannot resolve on their own. Foundation model training, fine-tuning workloads, and inference scaling all face power limitations and GPU scarcity. Hyperscalers ration capacity through waiting lists and preferential allocation.\nAkash’s decentralized marketplace coordinates underutilized GPU capacity with compute-starved AI teams. This addresses genuine infrastructure bottlenecks rather than creating synthetic demand.\nSeveral developments converge to make this the right moment. Migration to a shared security chain reduces operational overhead for the marketplace. Upcoming VM and TEE (Trusted Execution Environment) support expands the addressable market beyond GPU workloads, increasing the range of compute tasks the network can service.\nBME ensures that as product-market fit strengthens, the economic model scales with it.\nWhat Comes Next\nBME transforms every workload on Akash into a deflationary event. Network growth and token value stop being competing priorities and become mechanically linked.\nThe mechanism achieves what decentralized infrastructure requires. It coordinates distributed resources where value flows to participants rather than intermediaries. AKT becomes essential to every transaction without imposing costs on users or providers. Tenants pay market rates for compute. Providers earn competitive revenue without take rates. Token holders benefit from structural supply reduction tied directly to usage.\nFor the Akash community, BME marks a maturation point. The network evolved from pioneering decentralized compute to establishing stable payments that drove growth. Now it synthesizes those phases into a sustainable economic model designed to scale with AI infrastructure demand.\nThe incentivized testnet confirmed the mechanism works. The mainnet implementation is next.\nProposal #318 has been approved on-chain, and is scheduled to go live on March 23rd, 2026 at approximately 14:00 UTC at block height 26063777.\nThis Akash Mainnet 17 upgrade will be the largest single upgrade in Akash’s history.\nFrequently Asked Questions\nWhat is Burn-Mint Equilibrium (BME) on Akash?\nAn economic model where users burn AKT at the current oracle price to mint ACT (a non-transferable USD-pegged compute credit) for deployments — creating direct AKT demand and deflationary supply reduction with every compute transaction.\nWhat is ACT?\nAkash Compute Token — a non-transferable, USD-pegged compute credit minted by burning AKT. Tenants use ACT to pay for compute; providers burn received ACT to receive AKT at the current market price.\nHow does BME create deflationary pressure on AKT?\nIf AKT appreciates between when a tenant burns AKT to mint ACT and when the provider collects payment, fewer AKT are minted for the provider than were burned by the tenant — the difference is permanently removed from supply.\nWhat are BME circuit breakers?\nSafety mechanisms that activate if the vault’s collateral ratio drops below thresholds: at 0.95 ratio, enhanced monitoring triggers; at 0.90, new ACT minting throttles while existing provider settlements continue uninterrupted.\nWhat did the BME incentivized testnet find?\nOne warning-state bug: the system was jumping directly to halt mode instead of the less-restrictive warning state (0.90–0.95 ratio range). The bug was identified, patched, and all subsequent testing passed cleanly.\nWhen did BME go live on Akash mainnet?\nMarch 23, 2026 at approximately 14:00 UTC at block height 26063777 — Akash Mainnet 17, approved via on-chain Proposal #318.\nWhy does BME matter for DePIN networks?\nBME solves the classic DePIN dilemma: stable pricing drives adoption but weakens the native token. BME delivers both — tenants and providers get USD-stable pricing while AKT becomes structurally essential to every transaction. \nFast, affordable inference for open models\n\nRun Llama, Qwen, GLM and more on Akash's open compute marketplace.\nDrop-in API compatibility means you can\n switch in minutes.\n\nTry AkashML\n(opens in a new tab) \nnote\n\ntip\n\nCaution\n\nDanger","tokens":3135,"squid":"spider-03","role":"Compute Spider","at":1791343075777,"hash":"7ad944d720e028e0dc6046e2cae09acdc7cf5073"}
{"url":"https://forum.arbitrum.foundation/t/team-6-an-eip-4824-powered-daouri-for-the-arbitrum-dao/25371/54","domain":"forum.arbitrum.foundation","title":"Team #6: An (EIP-4824 powered) daoURI for the Arbitrum DAO - Archive / GovHack Brussels - Arbitrum","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 10\n\n 3\n\n 2\n\n 2\n\n 2\n\n read \n\n 11\n min\n\n Jul 2024\n\n 54 / 54\n\n Oct 2024\n\n Oct 2024\n\n Load more posts above\n\n post by jwindawi on Aug 21, 2024\n\n jwindawi\n\n Directionally aligned on this but I agree with others that the path to voting hasn’t been what we need. Looking forward to having something like this in the future.\n\n post by CastleCapital on Aug 21, 2024\n\n CastleCapital\n\n We are generally very supportive of this proposal, particularly its potential to improve the user experience for both DAO operators and Arbitrum users. Enhancing the usability and accessibility of our governance processes is a step in the right direction.\nGiven that this proposal involves a technical implementation, we would like to see input from security service providers, whether they are part of the ARDC or external experts. Their assessments will be crucial in ensuring this integration is secure and aligns with the best practices for our ecosystem.\nAdditionally, while we recognize some errors in the formal process leading up to this proposal, we are willing to look past these in the interest of practicality. What matters most is the outcome and the value this initiative could bring to the Arbitrum DAO.\n\n Castle Delegate Communication Thread\n\n post by Tane on Aug 21, 2024\n\n Tane\n\n We vote AGAINST the proposal on Snapshot because of the process issue.\nThe governance process should be clearly defined in the governance document and widely known especially to proposal creators (delegate with enough VPs to create proposals) who should be guardians of enforcing the guidance defined in the governance document.\n\n Tané Delegate Communication Thread\n\n post by Frisson on Aug 21, 2024\n\n Frisson\n\n I voted ABSTAIN on this proposal due to procedural concerns. I will vote FOR it when it is created again on Snapshot.\n\n Frisson Delegate Communication Thread\n\n post by SEEDGov on Aug 21, 2024\n\n SEEDGov\n\n After consideration, the @SEEDgov delegation has decided to vote “FOR” on this proposal at the Snapshot vote.\nRationale\nWhile SEEDGov has consistently upheld the importance of respecting due process and voiced our concerns when proposers have rushed to submit votes prematurely, in this particular situation, we do not believe it justifies voting against a temperature check simply because the submission was placed in the wrong section of the forum.\nNow, the proposal in question addresses an existing problem, is pre-funded by a grant from the foundation, and incorporates highly useful tools for research and data mining.\nWe regret that this mistake occurred as we see significant value in this initiative and we hope that if it’s not approved the proposer persists with the proposal.\n\n post by krst on Aug 21, 2024\n\n krst\n\n The following reflects the views of L2BEAT’s governance team, composed of @krst and @Sinkas, and it’s based on the combined research, fact-checking, and ideation of the two.\nWe’ll be voting FOR this proposal during temp-check.\nWe see the value of incorporating the daoURI in Arbitrum’s governance to have a programmatically accessible single source of DAO information and the fact that there is no overhead for the DAO, in terms of effort or money required, makes the decision a no-brainer. Furthermore, we’re comfortable knowing that most governance tooling platforms are already members of DAOstar so adopting the daoURI will give them an easy path to metadata updates.\nWhen it comes to the two outlined approaches, we believe the path of least resistance (setting a new ‘daoURI’ txt record on arbitrumfoundation.eth) to be the most prudent one to follow at this time. This way, the implementation will be easier, and we’ll have the flexibility to make changes without needing a governance vote. At a later date, we can revisit the topic and discuss setting the DAO’s timelock as the manager.\n\n An EIP-4824 powered daoURI for Arbitrum DAO\n\n L2BEAT Delegate Communication Thread\n\n post by Griff on Aug 21, 2024\n\n Griff\n\n I’m Voting FOR this proposal.\nDespite not following the traditional forum protocol, I think its a great proposal, it costs no money directly, it just requires the foundation to add some data to their ENS handle. The DAOstar/Metagov crew work tirelessly to bring these standards to the DAO space, it is very thankless work. I am a huge fan.\nIMO, all of us voting no on this and then forcing them to repost again IMO is a waste of everyone’s time and a bad reason to vote against.\n\n post by ocandocrypto on Aug 21, 2024\n\n ocandocrypto\n\n I decided to vote “For” this proposal.\nI understand the concern that the usual process may not have been followed, and that such practices shouldn’t become common. However, recognizing that the DAO’s onboarding process and the appropriate paths to follow might not always be clear, I believe the implementation of this proposal is highly useful. The benefit-to-risk ratio doesn’t justify rejecting it.\nThis proposal serves to both enhance the ecosystem and improve our onboarding process for the development of future proposals.\n\n post by Bob-Rossi on Aug 21, 2024\n\n Bob-Rossi\n\n Voting “Against” for procedural purposes stated above, but see a lot of value in the project and will vote “Yes” when reposted.\n\n Bob-Rossi Delegate Communication Thread (No longer delegate as of 12/31/2025)\n\n An EIP-4824 powered daoURI for Arbitrum DAO\n\n post by snowdot on Aug 22, 2024\n\n snowdot\n\n The results are in for the An (EIP-4824 powered) daoURI for the Arbitrum DAO offchain proposal.\nSee how the community voted and more Arbitrum stats:\n\n post by WinVerse on Aug 23, 2024\n\n WinVerse\n\n DAOplomats voted AGAINST this proposal on Snapshot for our reasons here:\n\n DAOplomats Delegate Communication Thread\n\n post by ITUblockchain on Aug 24, 2024\n\n ITUblockchain\n\n We voted against this proposal during the temperature check process due to procedural flaws and the lack of a thorough security review. The proposal was not properly categorized in the forums, potentially limiting its visibility and feedback. Additionally, it has not been assessed by an ARDC security provider, which is crucial for its technical implementation.\nHowever, if these issues are addressed, we will support the proposal in future voting stages.\n\n post by maxlomu on Aug 25, 2024\n\n maxlomu\n\n gm, I voted ABSTAIN on this.\nThe request is fully valid and I will support it as soon as it is properly resubmitted on Snapshot.\n\n post by amanwithwings on Aug 28, 2024\n\n amanwithwings\n\n Hey all, thank you for your valuable feedback. We have created a new forum post in the correct category. I’ve also requested a security evaluation from the ARDC. We look forward to reposting the improved proposal to Snapshot after ARDC’s evaluation.\n\n post by Mehdi_eth on Aug 29, 2024\n\n Mehdi_eth\n\n I voted in favor of the proposal because I believe it will help us gather the necessary and reliable data for decision-making in the governance. I would also appreciate it if you could address some of the delegates’ concerns and resubmit the proposal on Snapshot.\n\n post by AbdullahUmar on Aug 31, 2024\n\n AbdullahUmar\n\n Below are the reflections of the UADP:\nA go-to source of truth is a great idea. We are in favor of setting up a platform like this. At Uniswap, we’ve had experience with managing a couple of ENS subdomains under Uniswap.eth. This was initially set in place in order to give additional use grants to certain deployers who would request the DAO for the ability to deploy Uniswap v3 contracts onto a new EVM. This was only required while there was a BSL in place. Since April of last year, we continued similar record management to have a source of truth regarding the “real” Uniswap v3 contracts on each of the 23 chains that we’re deployed on. This has helped from a security and standardization standpoint. Therefore, exploring record management such as this for Arbitrum is beneficial as well.\nUnfortunately, due to issues surrounding the procedure, we voted against this proposal. We will vote For a revised proposal though.\n\n An EIP-4824 powered daoURI for Arbitrum DAO\n\n post by Djinn on Sep 1, 2024\n\n Djinn\n\n This proposal came out of nowhere. The proposal seems reasonable, but would hope to discuss / hear from the proposers live on this before going forward with a more formal vote so that delegates have time to engage and learn.\nVoted AGAINST on Snapshot in the meanwhile.\n\n 23 days later\n\n post by openzeppelin on Sep 25, 2024\n\n openzeppelin\n\n OpenZeppelin reviewed the daoURI proposal for security risks. The report is available here:\n\n post by amanwithwings on Sep 26, 2024\n\n amanwithwings\n\n Thank you for the review, @openzeppelin! And thank you to @Sinkas and other members of the ARDC for cooperating here.\nWe are planning to take the proposal to Snapshot again and look forward to the community’s support!\n\n post by 0xDonPepe on Oct 1, 2024\n\n 0xDonPepe\n\n Just voted in favor of using ENS txt records on Snapshot. EIP-4824 is a solid and useful standard, and it’s great to see it getting implemented on Arbitrum. Having a reliable source for trusted info will definitely help newcomers and anyone diving deeper into Arbitrum. Plus, no additional funding needed for this proposal is a huge bonus.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n An EIP-4824 powered daoURI for Arbitrum DAO\n\n Finalized AIPs\n\n 42\n\n 834\n\n Nov 2024\n\n Arbitrum daoURI Proposal Security Review\n\n ARDC Security Member\n\n 1\n\n 140\n\n Sep 2024\n\n Arbitrum Proposals App (GovHack Brussels Winner)\n\n Archived Proposals\n\n proposal,governance,delegation,proposal-discussions\n\n 35\n\n 1.6k\n\n May 2025\n\n Proposal: AIP-1.2 - Foundation and DAO Governance\n\n Finalized AIPs\n\n tally,passed\n\n 65\n\n 19.0k\n\n Jun 2023\n\n Frisson Delegate Communication Thread\n\n Delegate Statements\n\n delegation,delegate-statements\n\n 76\n\n 1.1k\n\n Apr 2025","tokens":2466,"squid":"spider-07","role":"Council Spider","at":1791343075862,"hash":"ac5578311766c91cdcdbeee69447578409e819d1"}
{"url":"https://akash.network/current-groups/sig-analytics/","domain":"akash.network","title":"Analytics Special Interest Group - Community Groups","text":"Back\n Steering Committee Steering Committee Special Interest Groups Analytics Special Interest Group Chain Special Interest Group Clients Special Interest Group Community Special Interest Group Deployments Special Interest Group Design Special Interest Group Documentation Special Interest Group Economics Special Interest Group Education Providers Special Interest Group Support Special Interest Group Working Groups Akash Hackathon Working Group Akash Website Akash Youtube Client Libraries Working Group Content Moderation Working Group Economics 2.0 2023 Events - Working Group GPU Working Group Provider Attributes Working Group Provider Audit Working Group Testnets Working Group Zealy Analytics Special Interest Group Analytics Special Interest Group is dedicated to defining and building tools that allow data analytics for deployments, providers, chain metrics, etc. \nView on Discord\n\nView on GitHub\n\nSubscribe to Calendar\n\nAkash Network - Analytics Special Interest Group (SIG)\nAnalytics Special Interest Group is dedicated to defining and building tools that allow data analytics for deployments, providers, chain metrics, etc.\nMeetings\nEvery Two Months on the second Thursday\nFeel free to join every other month. See meeting table and calendar for specific times.\nAdd the Akash Community Group Calendar\n\nMeetingTimeNotesTranscriptRecording#1Thursday, February 9, 2023 09:00 AM PT (Pacific Time)LinkLinkLink#2Thursday, March 9, 2023 09:00 AM PT (Pacific Time)LinkLinkLink#3Thursday, April 13, 2023 09:00 AM PT (Pacific Time)LinkLinkLink#4Thursday, May 11, 2023 09:00 AM PT (Pacific Time)LinkLinkLink#5Thursday, June 08, 2023 09:00 AM PT (Pacific Time)LinkLinkLink#6Thursday, July 13, 2023 09:00 AM PT (Pacific Time)LinkLinkLink#7Thursday, August 10, 2023 09:00 AM PT (Pacific Time)LinkLinkLink#8Thursday, September 14, 2023 09:00 AM PT (Pacific Time)LinkLinkLink#9Thursday, October 12, 2023 09:00 AM PT (Pacific Time)LinkLinkLink#10Thursday, December 14, 2023 09:00 AM PT (Pacific Time)LinkLinkLink#11Thursday, February 15, 2024 09:00 AM PT (Pacific Time)LinkLinkComing Soon#12April 18, 2024 09:00 AM PT (Pacific Time)coming SoonComing SoonComing Soon#13June 20, 2024 09:00 AM PT (Pacific Time)Coming SoonComing SoonComing Soon#14August 15, 2024 09:00 AM PT (Pacific Time)LinkLinkLink#15October 17th, 2024 09:00 AM PT (Pacific Time)LinkLinkLink#16February 20, 2025 09:00 AM PT (Pacific Time)LinkLinkLink#17July 02, 2025 09:00 AM PT (Pacific Time)LinkLinkLink#18February 26th, 2026 09:00 AM PT (Pacific Time)LinkLinkLink#19July 19, 2026 09:00 AM PT (Pacific Time)LinkLinkcoming Soon#20November, 2026 09:00 AM PT (Pacific Time)\nLeadership\nAnil Murty\nContact\n\nDiscord Server\n\nSub Projects, Repositories & Relevant Work Groups\nThe following are projects and work-groups that sig-analytics participates in or contributes to (ToDo: Add links when available) Steering Committee Chain Special Interest Group","tokens":728,"squid":"spider-03","role":"Compute Spider","at":1791343097540,"hash":"bc498bc57bbd0dcccf420387558bebd035874a45"}
{"url":"https://developer.arbitrum.io/arbitrum-essentials/bridging/overview","domain":"developer.arbitrum.io","title":"Bridging overview","text":"BridgingBridging overviewChoose the right approach for bridging assets and messages between Ethereum and Arbitrum.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\nHow is this guide?BridgingMove ETH, tokens, and messages between parent and child chains.Cross-chain messagingLearn how to send cross-chain messages between Ethereum and Arbitrum using retryable tickets, the ArbSys precompile, and the Outbox contract. Includes a complete Greeter tutorial demonstrating both parent-to-child and child-to-parent messaging.","tokens":506,"squid":"spider-01","role":"Chain Spider","at":1791343097661,"hash":"9432f5bdf382ba3b9883169926aefd6d05f38695"}
{"url":"https://forum.arbitrum.foundation/t/an-eip-4824-powered-daouri-for-arbitrum-dao/26386/43","domain":"forum.arbitrum.foundation","title":"An EIP-4824 powered daoURI for Arbitrum DAO - Proposals / Finalized AIPs - Arbitrum","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 8\n\n 2\n\n read \n\n 11\n min\n\n Aug 2024\n\n 43 / 43\n\n Nov 2024\n\n Nov 2024\n\n Load more posts above\n\n post by 0xDonPepe on Oct 1, 2024\n\n 0xDonPepe\n\n Just voted in favor of using ENS txt records on Snapshot. EIP-4824 is a solid and useful standard, and it’s great to see it getting implemented on Arbitrum. Having a reliable source for trusted info will definitely help newcomers and anyone diving deeper into Arbitrum. Plus, no additional funding needed for this proposal is a huge bonus.\n\n post by Tekr0x.eth on Oct 2, 2024\n\n Tekr0x.eth\n\n Voted For - Use ENS TXT records: Picking up good practices from other DAOs makes sense. Putting as much info as possible on-chain is necessary for open and transparent governance. I support this kind of standard being adopted by all major DAOs. I agree that we should set the daoURI record on Arbitrum’s ENS. Also, it’s great that this upgrade doesn’t require any payment from the treasury.\n\n post by Curia on Oct 2, 2024\n\n Curia\n\n We are supporting the proposal with the ENS text record option as it aligns with our goal of enhancing the DAO’s accessibility. It’s a straightforward, no-cost solution to improve transparency and accessibility for ArbitrumDAO.\n\n Curia Delegate Communication Thread\n\n post by paulofonseca on Oct 2, 2024\n\n paulofonseca\n\n voting For – Use registration contract in the current offchain proposal because this information should be under the control of the DAO not the Arbitrum Foundation. the other option of using “ENS txt records” would update the ENS arbitrumfoundation.eth which is not even the name of our DAO, which is “Arbitrum DAO”. Our Arbitrum DAO is not the ENS name arbitrumfoundation.eth, it is the set of onchain governor contracts that control our protocol and network, so that’s what should be updated to hold this information. Also, my vote is conditional to the fact that we should use as few dependencies as possible for the members and proposals dynamic URIs, so that the onchain representation of the DAO is not relying on private companies APIs, especially for publicly available onchain governance data.\n\n post by mcfly on Oct 2, 2024\n\n mcfly\n\n We’re voting FOR the ENS text record option. We definitely need a single source of truth for Arbitrum DAO’s metadata to improve accessibility and tooling integration. It’s a low-risk, no-cost improvement that aligns with best practices in the DAO ecosystem.\n\n post by PennBlockchain on Oct 2, 2024\n\n PennBlockchain\n\n The FranklinDAO / Penn Blockchain Team voted for the ENS Text Record option. We chose this option because its streamlined and efficient compared to a Constitutional Proposal. This is beneficial to all delegates and we’re looking forward to the integrations with DeepDAO, ArbScan, Snapshot, etc.\n\n post by Bob-Rossi on Oct 2, 2024\n\n Bob-Rossi\n\n Voting “For”, should bring a lot of value. I indicated in the original thread that I would support this, but just voted against for procedural reasons (Team #6: An (EIP-4824 powered) daoURI for the Arbitrum DAO - #43 by Bob-Rossi)\nSimply put - this will add value to the DAO at no cost, I don’t really see a reason to vote against.\n\n Bob-Rossi Delegate Communication Thread (No longer delegate as of 12/31/2025)\n\n post by chamadao on Oct 2, 2024\n\n chamadao\n\n Just voted FOR\nIt’s a simple and effective way to improve access to Arbitrum DAO’s data without needing extra funding or major changes to the existing smart contracts. Plus, it keeps things flexible—using text records allows for easy updates without requiring an on-chain vote every time. This feels like a practical move to help streamline how we manage important DAO information while keeping it transparent and decentralized.\n\n ChamaDao Delegate Communication Thread\n\n post by Tane on Oct 2, 2024\n\n Tane\n\n We vote for Use ENS txt records on Snapshot.\nThis change leads to a better accessibility of the metadata for the toolings in the ecosystem, without additional cost. We believe it’s acceptable to utilize the ENS records for the information.\n\n Tané Delegate Communication Thread\n\n post by SEEDGov on Oct 3, 2024\n\n SEEDGov\n\n After consideration, the @SEEDgov delegation has decided to “FOR - Use ENS txt records” on this proposal at the Snapshot vote.\nRationale\nAs we expressed during the previous vote, we support this initiative as it significantly improves information accessibility, enabling external parties to learn about various DAO details in one centralized location and at no cost to the DAO.\nHowever, when selecting between the two options, we opted for the ENS txt records, prioritizing simplicity. Although we generally prefer the DAO to maintain as much autonomy as possible, keeping the information updated could prove challenging without a dedicated manager.\n\n post by EzR3aL on Oct 3, 2024\n\n EzR3aL\n\n I voted YES.\nMaking open and accessible data more transparent with no additional costs is only a a benefit to this industry.\n\n EzR3aL Delegate Communication Thread\n\n [DIP v1.0]Delegate Incentive Program Results (October 2024)\n\n post by krst on Oct 3, 2024\n\n krst\n\n The following reflects the views of L2BEAT’s governance team, composed of @krst and @Sinkas, and it’s based on the combined research, fact-checking, and ideation of the two.\nWe are voting FOR this proposal for the same reasons we supported it in the past.\nThe previous vote for this proposal was defeated simply because of a hiccup in the governance process. The proposal has now followed the proper procedure and has also received a security review from the ARDC, which raised no significant concerns. Given that, we see no reason to vote against it.\n\n post by snowdot on Oct 4, 2024\n\n snowdot\n\n The results are in for the An EIP-4824 powered daoURI for Arbitrum DAO off-chain proposal.\nSee how the community voted and more Arbitrum stats:\n\n post by maxlomu on Oct 4, 2024\n\n maxlomu\n\n gm, voted FOR this proposal.\nAdding more transparency to our processes is always useful, would be great to understand how many people will actually look into that.\nChose the ENS option as the simplest one.\n\n post by WinVerse on Oct 7, 2024\n\n WinVerse\n\n DAOplomats voted in favor of this proposal on Snapshot.\nAn official repository of information on the DAO is net-positive and would certainly provide people with a reliable location of verified onchain information. There are no additional costs to the DAO and with the ARDC seeing no issues with it, we were happy to vote in favor.\n\n DAOplomats Delegate Communication Thread\n\n 24 days later\n\n post by AbdullahUmar on Oct 31, 2024\n\n AbdullahUmar\n\n Below are the opinions of the UADP:\nWe just wanted to provide transparency regarding why we voted For this proposal. The reasoning essentially stands the same from our previous comment on this post but is updated based on proper procedure :\n\n post by olimpio on Oct 31, 2024\n\n olimpio\n\n Voted for to this proposal. From the two options, chose ENS. This is a good way to manage a single source of truth -“official repository”- for daoURI metadata, and managed by governance, at no additional cost.\n\n post by AlexLumley on Oct 31, 2024\n\n AlexLumley\n\n Vote: FOR\nType and Proposal Link: Snapshot –> An EIP-4824 powered daoURI for Arbitrum DAO\nVoting Rationale Link: Alex Lumley (Savvy DAO) Delegate Communication Thread - #29 by AlexLumley\n=== COMMENTS ON PROPOSAL: ===\nI support the proposal to implement an EIP-4824-powered daoURI for Arbitrum DAO, specifically opting for the ENS txt records approach as suggested by several delegates. This method is straightforward and effective, allowing the DAO to establish a single source of truth on-chain without any additional costs. Utilizing ENS txt records ensures the metadata remains accessible and easily updatable without needing constant governance interventions, which enhances transparency and usability for newcomers, tooling providers, and current DAO members.\nWhile this solution provides a robust foundation for maintaining important DAO information, I agree with other delegates that a clear, streamlined process for managing updates will be beneficial. As the DAO grows, an established structure for managing and updating the ENS records will be essential to maintain accuracy and utility. This setup not only offers transparency but also sets the groundwork for future improvements in data accessibility.\n\n Alex Lumley (Savvy DAO) Delegate Communication Thread\n\n post by amanwithwings on Nov 1, 2024\n\n amanwithwings\n\n Update: we are working with the Arbitrum Foundation on executing this proposal. A guide on how to create, maintain, and deploy the daoURI for Arbitrum DAO as an ENS txt record has been shared with the Foundation. They are currently evaluating it. I will provide implementation updates in this thread. Meanwhile, if you have any data you’d like to add to the daoURI, feel free to reach out!\ncc: @raam, @cliffton.eth, @stonecoldpat\n\n post by NathanVDH on Nov 1, 2024\n\n NathanVDH\n\n I have voted for this proposal on Snapshot. Making sure that newcomers can easily find a source of truth about information on the DAO is one of the best remedies against capture. Happy to see we’re leveraging ENS as well, it’s the staple for a reason and this initiative will further bring it the lindy it deserves!\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Team #6: An (EIP-4824 powered) daoURI for the Arbitrum DAO\n\n GovHack Brussels\n\n 53\n\n 1.2k\n\n Oct 2024\n\n Arbitrum daoURI Proposal Security Review\n\n ARDC Security Member\n\n 1\n\n 140\n\n Sep 2024\n\n Proposal: AIP-1.2 - Foundation and DAO Governance\n\n Finalized AIPs\n\n tally,passed\n\n 65\n\n 19.0k\n\n Jun 2023\n\n DAOplomats Delegate Communication Thread\n\n Delegate Statements\n\n delegation,delegate-statements\n\n 25\n\n 3.3k\n\n Nov 2025\n\n Arbitrum Proposals App (GovHack Brussels Winner)\n\n Archived Proposals\n\n proposal,governance,delegation,proposal-discussions\n\n 35\n\n 1.6k\n\n May 2025","tokens":2483,"squid":"spider-07","role":"Council Spider","at":1791343098035,"hash":"975094285d1544b9a949f1ae1ace6f974082ee01"}
{"url":"https://akash.network/current-groups/wg-akash-hackathon/","domain":"akash.network","title":"Akash Hackathon Working Group - Community Groups","text":"Back\n Steering Committee Steering Committee Special Interest Groups Analytics Special Interest Group Chain Special Interest Group Clients Special Interest Group Community Special Interest Group Deployments Special Interest Group Design Special Interest Group Documentation Special Interest Group Economics Special Interest Group Education Providers Special Interest Group Support Special Interest Group Working Groups Akash Hackathon Working Group Akash Website Akash Youtube Client Libraries Working Group Content Moderation Working Group Economics 2.0 2023 Events - Working Group GPU Working Group Provider Attributes Working Group Provider Audit Working Group Testnets Working Group Zealy Akash Hackathon Working Group The Akash Hackathon Working Group is responsible for creating a Akash Hackathon event, as well as finding other hackathons for an Akash focused team to attend. Hackathons are a key driver of developer growth. \nView on Discord\n\nView on GitHub\n\nSubscribe to Calendar\n Akash Network Akash Hackathon Working Group\nThe Akash Hackathon Working Group is responsible for creating a Akash Hackathon event, as well as finding other hackathons for an Akash focused team to attend. Hackathons are a key driver of developer growth.\nMeetings\n\nTo be scheduled as needed via Discord\nFull Calendar for all Akash Working Groups (wg) and Special Interest Groups(sig)\n\nMeetingTimeNotesTranscriptRecording#1Wednesday, February 15, 2023 11:30 AM PT (Pacific Time)LinkLinkcoming soon#2Friday, April 21, 2023 11:30 AM PT (Pacific Time)LinkLinkcoming soon\nLeads\nAdam Wozney (Overclock Labs)\nContacts\n\nDiscord\n\nGoals\n\nPlan a Akash Hackathon for 2023.\nFind events where an Akash team can participate in hackathons hosted by other organizations.\n\nPRDs and other documentation\n\nWorking Doc - From Adam Wozney\n\nRelated SIGs\n\nsig-community\n Support Special Interest Group Akash Website","tokens":469,"squid":"spider-03","role":"Compute Spider","at":1791343107391,"hash":"40f2f3dd60148d3b3a7cd13025e7239fe9902da9"}
{"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 29d ago\n\n post by tcoratger on Jun 1\n\n post by potuz on Jun 3\n\n post by 71104 on Jun 3\n\n post by tcoratger on Jun 3\n\n post by 71104 on Jun 3\n\n post by 0xjasonw on Jun 3\n\n post by potuz on Jun 3\n\n post by 71104 on Jun 3\n\n post by uink45 on Jun 3\n\n post by opus-lux on Jun 4\n\n post by asn on Jun 5\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":1348,"squid":"spider-04","role":"Research Spider","at":1791343112827,"hash":"374202d225a68428ef555656ef6568364931ed4e"}
{"url":"https://akash.network/current-groups/wg-akash-youtube/","domain":"akash.network","title":"Akash Youtube - Community Groups","text":"Back\n Steering Committee Steering Committee Special Interest Groups Analytics Special Interest Group Chain Special Interest Group Clients Special Interest Group Community Special Interest Group Deployments Special Interest Group Design Special Interest Group Documentation Special Interest Group Economics Special Interest Group Education Providers Special Interest Group Support Special Interest Group Working Groups Akash Hackathon Working Group Akash Website Akash Youtube Client Libraries Working Group Content Moderation Working Group Economics 2.0 2023 Events - Working Group GPU Working Group Provider Attributes Working Group Provider Audit Working Group Testnets Working Group Zealy Akash Youtube This working group is responsible for managing and improving the Akash Network Youtube Channel. Thank you for wanting to contribute. The Akash Network Youtube Channel can be found [here](https://www.youtube.com/c/AkashNetwork). \nView on Discord\n\nView on GitHub\n\nSubscribe to Calendar\n Akash Network - Akash Youtube Working Group (WG)\nThis working group is responsible for managing and improving the Akash youtube Channel. Thank you for wanting to contribute. The Akash youtube can be found here.\nMeetings\n\nTo be scheduled as needed via Discord\nFull Calendar for all Akash Working Groups (wg) and Special Interest Groups(sig)\n\nMeetingTimeNotesTranscriptRecording#1Tuesday, July 23, 2024 08:00 AM PT (Pacific Time)LinkLinkComing Soon#2Tuesday, July 30, 2024 8:00 AM PT (Pacific Time)LinkLinkcoming soon#3Tuesday, August 6, 2024 8:00 AM PT (Pacific Time)LinkLinkcoming soon#4Tuesday, August 16, 2024 8:00 AM PT (Pacific Time)LinkLinkLink#5Tuesday, August 20, 2024 8:00 AM PT (Pacific Time)LinkLinkLink#6Tuesday, September 3, 2024 8:00 AM PT (Pacific Time)LinkLinkLink#7Tuesday, September 17, 2024 8:00 AM PT (Pacific Time)LinkLinkLink#8Tuesday, October 1, 2024 8:00 AM PT (Pacific Time)LinkLinkLink#9Wednesday, November 13, 2024 8:00 AM PT (Pacific Time)LinkLinkLink\nLeads\n\nDenis Lelic\nTyler Wright\nRobert Del Rey\n\nContacts\n\nDiscord\n\nGoals\nPRDs and other documentation\n\nCode of Conduct\n\nRelated SIGs\n\nsig-community\nsig-design\n Akash Website Client Libraries Working Group","tokens":544,"squid":"spider-03","role":"Compute Spider","at":1791343118224,"hash":"a08b43f51ff4589b973d4cced6e8bae94fbec7e2"}
{"url":"https://forum.across.to/t/stop-acx-emissions-on-acx-lp/2062","domain":"forum.across.to","title":"Stop ACX Emissions on ACX LP - Proposals - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n Stop ACX Emissions on ACX LP \n\n Proposals\n\n treasury-funding\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n May 2025\n\n 1 / 6\n\n May 2025\n\n May 2025\n\n post by Kevin_UMA on May 20, 2025\n\n Kevin_UMA\n\n Title: Stop ACX Emissions on ACX LP\nAuthors: ACX Emissions Committee (Kevin Chan, David Korpi, Ryan Carman, Dylan O’Reilly, Chase Coleman)\nStatus: Proposal\nRelated Discussions: ACX Emissions Committee, ACX Emissions Committee Framework Update, Reduce ACX emissions for ACX LPs, WBTC LPs and wstETH/ACX LPs\nSummary:\nThe Across DAO should stop ACX emissions for Across ACX LPs. The ACX liquidity pools are being rewarded a high APY in comparison to the utilization of the asset or necessity of the emissions.\nThe ACX Emissions Committee only has permissions and a framework to control ACX emissions for ETH, USDC, USDT, and DAI. We are putting together this one-off proposal to decrease ACX emissions in a similar way to ETH, USDC, USDT, and DAI.\nMotivation:\nThe Across DAO should optimally manage ACX emissions for all liquidity it incentivizes. One way that we have done this previously is by creating the ACX Emissions Committee (AEC). The AEC uses a transparent and restrictive framework to adjust emissions awarded to Across ETH/USDC/USDT/DAI LPs. The framework monitors the utilization and comparable yield alternatives of each asset to make ACX emissions adjustments. Across ACX LPs were excluded from the AEC’s purview because there are more considerations than just utilization and comparable yields when we think about what the “optimal” ACX emissions to pay are.\nACX emissions for ACX LPs were initially set high to incentivize ACX airdrop recipients to not immediately sell their tokens and to get these token holders familiar with the reward locking mechanism. Base emissions currently stand at 7.5K per day. ACX utilization consistently sits close to zero given a lack of bridging needs. Yet, the emissions rate for the ACX LP is by far the highest at 11.7K ACX per day (~$2,700) taking into account the multiplier (which exceeds the sum of emissions being used for ETH, USDC, USDT, and DAI).\nThe AEC believes these emissions are unnecessary and the DAO should preserve ACX capital especially at these price levels. The Across DAO should decrease ACX LP base emissions by 100% from 7.5K ACX per day to 0 ACX per day.\nSpecification & Implementation:\nThe ACX LP base emissions are currently 7,500 ACX per day. Our proposal is to drop this to 0 ACX per day. If approved, this will be implemented by the AEC.\nRationale:\nRationale is described above.\nDownside (Cons):\nAs highlighted in previous discussions on the forum, there is the potential that some ACX LPs withdraw their funds and sell – The AEC believes that this will be a relatively muted effect as strong ACX holders will be unlikely to sell at these low prices.\nVoting:\n\n Should the Across DAO end ACX base emissions for ACX LPs? A “YES” vote means that you would like to decrease the ACX emissions being paid to ACX LPs from 7,500 ACX/day to 0 ACX/day. A “NO” vote means that you would like the ACX emissions being paid to ACX LPs to stay the same.\n\n 56%\n Yes\n\n 44%\n No\n\n 0%\n Abstain\n\n 9\n voters\n\n Closed May 2025\n\n 3\n\n post by TheRealTuna_Across on May 23, 2025\n\n TheRealTuna_Across\n\n My belief is that the most likely people to sell ACX is those farming the asset pools. Some may believe in ACX growth potential but others might not care. Would be nice if we had some data on what percentage of LP’s are moving their earned ACX into the ACX LP. Turning off emissions might stop some selling but will it find buyers? Probably not. When someone needs cash and has to sell an asset, they may sell something else instead due to fear of losing their rewards multiplier, but now there’s no reason to lock in? Why not reduce instead of remove?\nWhat about turning on the fee switch? Is there no room to charge fees that go to holders and still be competitive? Will that ever be a possibility? That’s the sort of narrative that will attract speculators and long term holders, but will it ever happen?\n\n post by arizonaice on May 26, 2025\n\n arizonaice\n\nAny LP’s that claimed their earned ACX and moved it into the ACX LP would be resetting their multipliers on the pools they claimed from. So I’m not sure people are engaging in this particular behavior.\n\n post by arizonaice on May 26, 2025\n\n arizonaice\n\nThere are a few ways of looking at this.\nThe first is that those solely farming the rewards will pull their capital and sell as they are no longer being incentivized to hold the asset. This may cause some selling pressure in the short term but are of the belief that this will not represent the majority of ACX currently staked in the pool.\nAnother way to look at this is that investors analyzing Across will see that we made a fiscally responsible decision to reduce the marginal amount of ACX hitting the market. We noted that ~25% of our emissions were being paid out to a group of LPs who were already bullish on Across and decided it would be better for the long term prospects of the protocol to converse that capital.\nWe debated whether or not we should just reduce the ACX emissions to a lower level but we all agreed that any meaningful reduction would leave the pool with a very low rate of return and would have likely the same impact as just setting the emissions to zero.\n\n post by arizonaice on May 26, 2025\n\n arizonaice\n\nI cant comment on the fee switch but what I can comment on is how incredibly competitive the market is from a pricing standpoint. We spend a large amount of time and resource analyzing how we fare on the most important routes from a pricing and speed perspective. We’re regularly making adjustments on the order of less than a basis point in order to stay ahead of the competition where it makes sense to do so.\nWith this in mind, I think increasing our pricing now would put us in a very uncompetitive position and would significantly impact our order flow.\n\n 1 month later\n\n Closed on Jun 25, 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 Reduce ACX emissions for Across ACX LPs\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 8\n\n Nov 2023\n\n Reduce or Reallocate Across ACX LP emissions\n\n Ideas & Feedback\n\n liquidity\n\n Ideas & Feedback\n\n 2\n\n Sep 2023\n\n Reduce ACX emissions for ACX LPs, WBTC LPs and wstETH/ACX LPs\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 11\n\n Aug 2024\n\n ACX Emissions Committee\n\n Proposals\n\n governance-updates\n\n Proposals\n\n Dec 2023\n\n Stop ACX Emissions on wstETH/ACX LP Balancer Pool\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 2\n\n May 2025","tokens":3174,"squid":"spider-09","role":"Bridge Spider","at":1791343121278,"hash":"464617413467eda1b8719199c94dc702fdf5036c"}
{"url":"https://www.metaplex.com/docs/agents/agent-onboarding","domain":"metaplex.com","title":"Metaplex Agent Onboarding Guide | AI Agents on Solana","text":"The Metaplex Agent Onboarding guide is the canonical starting point for any autonomous agent integrating with Metaplex programs on Solana — covering wallet setup, identity registration, delegation, and optional token launch. SummaryThe Agent Onboarding guide walks an agent through everything needed to establish a verifiable onchain identity and begin operating on Solana using the Metaplex Agent Registry.Who it's for — AI agents and developers deploying autonomous agents on SolanaWhat it covers — CLI setup, wallet creation, Core asset registration, wallet activation, delegation, and token launchFormat — command-by-command walkthrough designed to be consumed directly by an agent or its operatorPrerequisite — a funded Solana wallet with ≥0.2 SOL to cover registration and transaction feesRead the Onboarding GuideThe full agent onboarding document — open this if you are an agent or are deploying one.Register an AgentStep-by-step guide to minting a Core asset and registering it in the Metaplex Agent Registry.Metaplex SkillGive your coding agent up-to-date knowledge of Metaplex programs.What the Onboarding Guide CoversThe guide is structured as a linear sequence of CLI commands an agent runs to become operational.Installation and RPC setup — Install the Metaplex CLI and configure an RPC endpoint. Devnet has a default endpoint; mainnet requires a dedicated RPC URL.Wallet creation and funding — Generate a main wallet and fund it with at least 0.2 SOL to cover the Core asset registration and ongoing transaction fees.Agent registration — Mint a Core asset that acts as the agent's onchain identity, with metadata conforming to the EIP-8004 agent standard. This produces the agent's Core asset address — required by all downstream operations.Wallet activation — Fund and activate the Asset Signer PDA, the operational wallet the agent uses to submit transactions autonomously.Delegation (optional) — Authorise a separate executor wallet to submit transactions on the agent's behalf.Token launch (optional) — Create a token via Genesis using either a LaunchPool (48-hour deposit window, 250 SOL or 25,000 USDC minimum raise) or a Bonding Curve (immediate trading, no minimum).Who Should Read the Onboarding GuideAI agents — The guide is written to be consumed directly by an agent running the Metaplex CLI. If you are an agent, read the full document before executing any registration commands.Developers deploying agents — Use the guide as the canonical reference for bootstrapping a new agent's onchain identity before integrating with other Metaplex programs.NotesMainnet registration requires a dedicated RPC endpoint — the default devnet RPC is not available on mainnetThe Core asset address produced by registration is required by Create an Agent Token, Agentic Commerce, and other agent workflowsLaunchPool raises require a minimum of 250 SOL or 25,000 USDC and a 48-hour deposit window; Bonding Curve launches have no minimum and open for trading immediatelyAll commands route through the agent PDA — the main wallet signs and pays fees, but execution is attributed to the agent's onchain identity","tokens":780,"squid":"dotcat","role":"Tooling Spider","at":1791343128511,"hash":"76f9ba46a317fa934c5d722a768d936afcb034d7"}
{"url":"https://forum.across.to/t/stop-acx-emissions-on-acx-lp/2062/6","domain":"forum.across.to","title":"Stop ACX Emissions on ACX LP - Proposals - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n Proposals\n\n treasury-funding\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n May 2025\n\n 6 / 6\n\n Jun 2025\n\n May 2025\n\n post by Kevin_UMA on May 20, 2025\n\n Kevin_UMA\n\n Title: Stop ACX Emissions on ACX LP\nAuthors: ACX Emissions Committee (Kevin Chan, David Korpi, Ryan Carman, Dylan O’Reilly, Chase Coleman)\nStatus: Proposal\nRelated Discussions: ACX Emissions Committee, ACX Emissions Committee Framework Update, Reduce ACX emissions for ACX LPs, WBTC LPs and wstETH/ACX LPs\nSummary:\nThe Across DAO should stop ACX emissions for Across ACX LPs. The ACX liquidity pools are being rewarded a high APY in comparison to the utilization of the asset or necessity of the emissions.\nThe ACX Emissions Committee only has permissions and a framework to control ACX emissions for ETH, USDC, USDT, and DAI. We are putting together this one-off proposal to decrease ACX emissions in a similar way to ETH, USDC, USDT, and DAI.\nMotivation:\nThe Across DAO should optimally manage ACX emissions for all liquidity it incentivizes. One way that we have done this previously is by creating the ACX Emissions Committee (AEC). The AEC uses a transparent and restrictive framework to adjust emissions awarded to Across ETH/USDC/USDT/DAI LPs. The framework monitors the utilization and comparable yield alternatives of each asset to make ACX emissions adjustments. Across ACX LPs were excluded from the AEC’s purview because there are more considerations than just utilization and comparable yields when we think about what the “optimal” ACX emissions to pay are.\nACX emissions for ACX LPs were initially set high to incentivize ACX airdrop recipients to not immediately sell their tokens and to get these token holders familiar with the reward locking mechanism. Base emissions currently stand at 7.5K per day. ACX utilization consistently sits close to zero given a lack of bridging needs. Yet, the emissions rate for the ACX LP is by far the highest at 11.7K ACX per day (~$2,700) taking into account the multiplier (which exceeds the sum of emissions being used for ETH, USDC, USDT, and DAI).\nThe AEC believes these emissions are unnecessary and the DAO should preserve ACX capital especially at these price levels. The Across DAO should decrease ACX LP base emissions by 100% from 7.5K ACX per day to 0 ACX per day.\nSpecification & Implementation:\nThe ACX LP base emissions are currently 7,500 ACX per day. Our proposal is to drop this to 0 ACX per day. If approved, this will be implemented by the AEC.\nRationale:\nRationale is described above.\nDownside (Cons):\nAs highlighted in previous discussions on the forum, there is the potential that some ACX LPs withdraw their funds and sell – The AEC believes that this will be a relatively muted effect as strong ACX holders will be unlikely to sell at these low prices.\nVoting:\n\n Should the Across DAO end ACX base emissions for ACX LPs? A “YES” vote means that you would like to decrease the ACX emissions being paid to ACX LPs from 7,500 ACX/day to 0 ACX/day. A “NO” vote means that you would like the ACX emissions being paid to ACX LPs to stay the same.\n\n 56%\n Yes\n\n 44%\n No\n\n 0%\n Abstain\n\n 9\n voters\n\n Closed May 2025\n\n 3\n\n post by TheRealTuna_Across on May 23, 2025\n\n TheRealTuna_Across\n\n My belief is that the most likely people to sell ACX is those farming the asset pools. Some may believe in ACX growth potential but others might not care. Would be nice if we had some data on what percentage of LP’s are moving their earned ACX into the ACX LP. Turning off emissions might stop some selling but will it find buyers? Probably not. When someone needs cash and has to sell an asset, they may sell something else instead due to fear of losing their rewards multiplier, but now there’s no reason to lock in? Why not reduce instead of remove?\nWhat about turning on the fee switch? Is there no room to charge fees that go to holders and still be competitive? Will that ever be a possibility? That’s the sort of narrative that will attract speculators and long term holders, but will it ever happen?\n\n post by arizonaice on May 26, 2025\n\n arizonaice\n\nAny LP’s that claimed their earned ACX and moved it into the ACX LP would be resetting their multipliers on the pools they claimed from. So I’m not sure people are engaging in this particular behavior.\n\n post by arizonaice on May 26, 2025\n\n arizonaice\n\nThere are a few ways of looking at this.\nThe first is that those solely farming the rewards will pull their capital and sell as they are no longer being incentivized to hold the asset. This may cause some selling pressure in the short term but are of the belief that this will not represent the majority of ACX currently staked in the pool.\nAnother way to look at this is that investors analyzing Across will see that we made a fiscally responsible decision to reduce the marginal amount of ACX hitting the market. We noted that ~25% of our emissions were being paid out to a group of LPs who were already bullish on Across and decided it would be better for the long term prospects of the protocol to converse that capital.\nWe debated whether or not we should just reduce the ACX emissions to a lower level but we all agreed that any meaningful reduction would leave the pool with a very low rate of return and would have likely the same impact as just setting the emissions to zero.\n\n post by arizonaice on May 26, 2025\n\n arizonaice\n\nI cant comment on the fee switch but what I can comment on is how incredibly competitive the market is from a pricing standpoint. We spend a large amount of time and resource analyzing how we fare on the most important routes from a pricing and speed perspective. We’re regularly making adjustments on the order of less than a basis point in order to stay ahead of the competition where it makes sense to do so.\nWith this in mind, I think increasing our pricing now would put us in a very uncompetitive position and would significantly impact our order flow.\n\n 1 month later\n\n Closed on Jun 25, 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 Reduce ACX emissions for Across ACX LPs\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 8\n\n Nov 2023\n\n Reduce or Reallocate Across ACX LP emissions\n\n Ideas & Feedback\n\n liquidity\n\n Ideas & Feedback\n\n 2\n\n Sep 2023\n\n Reduce ACX emissions for ACX LPs, WBTC LPs and wstETH/ACX LPs\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 11\n\n Aug 2024\n\n ACX Emissions Committee\n\n Proposals\n\n governance-updates\n\n Proposals\n\n Dec 2023\n\n Stop ACX Emissions on wstETH/ACX LP Balancer Pool\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 2\n\n May 2025","tokens":3166,"squid":"spider-09","role":"Bridge Spider","at":1791343131545,"hash":"7f0e9bb7e455e839056d33ed844889467b6c9cb5"}
{"url":"https://www.metaplex.com/docs/agents/register-agent","domain":"metaplex.com","title":"Register an Agent on Solana | Metaplex 014 Agent Registry","text":"Register an agent on the Metaplex 014 agent registry by binding an identity record to an MPL Core asset. SummaryThe registerIdentityV1 instruction binds an on-chain identity record to an MPL Core asset, creating a discoverable PDA and attaching lifecycle hooks for Transfer, Update, and Execute.Creates a PDA derived from the asset's public key for on-chain discoverabilityAttaches an AgentIdentity plugin with lifecycle hooks to the Core assetLinks to an off-chain registration document following ERC-8004 for agent metadataRequires an existing MPL Core asset and the @metaplex-foundation/mpl-agent-registry SDKQuick StartPrerequisites — Get an MPL Core asset and install the SDKRegister an Agent — Call registerIdentityV1 to bind identityAgent Registration Document — Create the off-chain metadata JSONVerify Registration — Confirm the identity was attachedFull Example — End-to-end code sampleWhat You'll LearnThis guide shows you how to register an agent with:An identity record linked to an MPL Core assetA PDA (Program Derived Address) that makes the agent discoverable on-chainAn AgentIdentity plugin with lifecycle hooks for Transfer, Update, and ExecutePrerequisitesYou need an MPL Core asset before registering. If you don't have one yet, see Create an NFT. For more on the identity program itself, see the MPL Agent Registry docs.Register an AgentRegistration creates a PDA derived from the asset's public key and attaches an AgentIdentity plugin with lifecycle hooks for Transfer, Update, and Execute. The PDA makes agents discoverable — anyone can derive it from an asset address and check whether it has a registered identity.import { createUmi } from '@metaplex-foundation/umi-bundle-defaults';\nimport { mplAgentIdentity } from '@metaplex-foundation/mpl-agent-registry';\nimport { registerIdentityV1 } from '@metaplex-foundation/mpl-agent-registry';\n\nconst umi = createUmi('https://api.mainnet-beta.solana.com')\n .use(mplAgentIdentity());\n\nawait registerIdentityV1(umi, {\n asset: assetPublicKey,\n collection: collectionPublicKey,\n agentRegistrationUri: 'https://example.com/agent-registration.json',\n}).sendAndConfirm(umi);\nParametersParameterDescriptionassetThe MPL Core asset to registercollectionThe asset's collection (optional)agentRegistrationUriURI pointing to off-chain agent registration metadatapayerPays for rent and fees (defaults to umi.payer)authorityCollection authority (defaults to payer)Agent Registration DocumentThe agentRegistrationUri points to a JSON document describing the agent's identity, services, and metadata. The format follows ERC-8004 adapted for Solana. Upload the JSON (and any associated image) to a permanent storage provider like Arweave so it's publicly accessible. For programmatic uploads, see this guide.{\n \"type\": \"https://eips.ethereum.org/EIPS/eip-8004#registration-v1\",\n \"name\": \"Plexpert\",\n \"description\": \"An informational agent providing help related to Metaplex protocols and tools.\",\n \"image\": \"https://arweave.net/agent-avatar-tx-hash\",\n \"services\": [\n {\n \"name\": \"web\",\n \"endpoint\": \"https://metaplex.com/agent/<ASSET_PUBKEY>\"\n },\n {\n \"name\": \"A2A\",\n \"endpoint\": \"https://metaplex.com/agent/<ASSET_PUBKEY>/agent-card.json\",\n \"version\": \"0.3.0\"\n },\n {\n \"name\": \"MCP\",\n \"endpoint\": \"https://metaplex.com/agent/<ASSET_PUBKEY>/mcp\",\n \"version\": \"2025-06-18\"\n }\n ],\n \"active\": true,\n \"registrations\": [\n {\n \"agentId\": \"<MINT_ADDRESS>\",\n \"agentRegistry\": \"solana:101:metaplex\"\n }\n ],\n \"supportedTrust\": [\n \"reputation\",\n \"crypto-economic\"\n ]\n}\nFieldsFieldRequiredDescriptiontypeYesSchema identifier. Use https://eips.ethereum.org/EIPS/eip-8004#registration-v1.nameYesHuman-readable agent namedescriptionYesNatural language description of the agent — what it does, how it works, and how to interact with itimageYesAvatar or logo URIservicesNoArray of service endpoints the agent exposes (see below)activeNoWhether the agent is currently active (true/false)registrationsNoArray of on-chain registrations linking back to this agent's identitysupportedTrustNoTrust models the agent supports (e.g. reputation, crypto-economic, tee-attestation)ServicesEach service entry describes a way to interact with the agent:FieldRequiredDescriptionnameYesService type — e.g. web, A2A, MCP, OASF, DID, emailendpointYesURL or identifier where the service can be reachedversionNoProtocol versionskillsNoArray of skills the agent exposes through this servicedomainsNoArray of domains the agent operates inRegistrationsEach registration entry links back to an on-chain identity record:FieldRequiredDescriptionagentIdYesThe agent's mint addressagentRegistryYesConstant registry identifier — use solana:101:metaplexVerify Registrationimport { fetchAsset } from '@metaplex-foundation/mpl-core';\n\nconst assetData = await fetchAsset(umi, assetPublicKey);\n\n// Check the AgentIdentity plugin\nconst agentIdentity = assetData.agentIdentities?.[0];\nconsole.log(agentIdentity?.uri); // your registration URI\nconsole.log(agentIdentity?.lifecycleChecks?.transfer); // truthy\nconsole.log(agentIdentity?.lifecycleChecks?.update); // truthy\nconsole.log(agentIdentity?.lifecycleChecks?.execute); // truthy\nFull Exampleimport { generateSigner } from '@metaplex-foundation/umi';\nimport { create, createCollection } from '@metaplex-foundation/mpl-core';\nimport { registerIdentityV1 } from '@metaplex-foundation/mpl-agent-registry';\n\n// 1. Create a collection\nconst collection = generateSigner(umi);\nawait createCollection(umi, {\n collection,\n name: 'Agent Collection',\n uri: 'https://example.com/collection.json',\n}).sendAndConfirm(umi);\n\n// 2. Create an asset\nconst asset = generateSigner(umi);\nawait create(umi, {\n asset,\n name: 'My Agent',\n uri: 'https://example.com/agent.json',\n collection,\n}).sendAndConfirm(umi);\n\n// 3. Register identity\nawait registerIdentityV1(umi, {\n asset: asset.publicKey,\n collection: collection.publicKey,\n agentRegistrationUri: 'https://example.com/agent-registration.json',\n}).sendAndConfirm(umi);\nNotesRegistration is a one-time operation per asset. Calling registerIdentityV1 on an already-registered asset will fail.The agentRegistrationUri should point to permanently hosted JSON (e.g. Arweave). If the URI becomes unreachable, the on-chain identity still exists but clients won't be able to fetch the agent's metadata.The collection parameter is optional but recommended — it enables collection-level authority checks during registration.Lifecycle hooks for Transfer, Update, and Execute are automatically attached. These hooks allow the identity plugin to participate in approving or rejecting operations on the asset.","tokens":1644,"squid":"dotcat","role":"Tooling Spider","at":1791343138490,"hash":"f37aed5c01769cc5678041b282e41999a7213ee6"}
{"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 Who cleans up the code? SETCODEFROM’s dangling bytecode and futureproof design choices\n\n 0\n\n 33\n\n 6h\n\n Mempool Account Transaction Capacity from Historical Activity (MATCHA)\n\n account-abstraction,transaction-privacy\n\n 11\n\n 554\n\n 2d\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 788\n\n 5d\n\n Designs for EVM gas accounting in EIP-7999\n\n fee-market\n\n 6\n\n 465\n\n 12d\n\n Proprietary AMMs and Ethereum\n\n mev\n\n 13\n\n 1.3k\n\n 13d\n\n CHAMP: Hardening the Mempool with CHain-Anchored, Multi-dimensional Peer Protection\n\n p2p,networking\n\n 0\n\n 109\n\n 13d\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 19d\n\n How Hegotá can influence the state roadmap\n\n 1\n\n 220\n\n 20d\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 22d\n\n Native UTXOs on Ethereum\n\n stateless,utxo\n\n 30\n\n 4.4k\n\n 29d\n\n How Hegotá should approach gas repricing\n\n 0\n\n 186\n\n 30d\n\n Order-dependence as the classifying dimension for frame-transaction mempool admission\n\n 0\n\n 94\n\n 30d\n\n EIP-8141 and minimum required validation budget for privacy applications\n\n account-abstraction,transaction-privacy\n\n 2\n\n 250\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 107\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 215\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 84\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 124\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","tokens":784,"squid":"spider-04","role":"Research Spider","at":1791343142110,"hash":"a1e6e352f0677dd7d12f37f4a52b5a2e4c5c4530"}
{"url":"https://www.metaplex.com/docs/tokens","domain":"metaplex.com","title":"Create & Launch Tokens on Solana | Token Generation Event (TGE) | Metaplex","text":"Solana TokensCreate, launch, and manage fungible tokens on Solana. Build token generation events (TGE), fair launches, and token sales using Metaplex Genesis and SDKs.Launch TokenFair launch tokens on Solana with Genesis.Create A TokenCreate a fungible SPL token with metadata.Mint TokensMint fungible tokens to a wallet address.Transfer TokensTransfer tokens between wallet addresses.Update A TokenUpdate the metadata of a fungible token.Burn TokensBurn fungible tokens from circulation.AnchorCreate and manage tokens using Rust and the Anchor framework.Create Token with AnchorBuild an SPL token with Rust and Anchor.","tokens":155,"squid":"dotcat","role":"Tooling Spider","at":1791343148353,"hash":"23df382c056dd637764d3449b1297a8f69b319ba"}
{"url":"https://forum.across.to/t/reward-locking-parameter-changes-increase-base-emissions-decrease-max-multiplier/1704","domain":"forum.across.to","title":"Reward Locking Parameter Changes: Increase Base Emissions, Decrease Max Multiplier - Proposals - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n Reward Locking Parameter Changes: Increase Base Emissions, Decrease Max Multiplier \n\n Proposals\n\n governance-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 Aug 2023\n\n 1 / 15\n\n Aug 2023\n\n Aug 2023\n\n post by Kevin_UMA on Aug 23, 2023\n\n Kevin_UMA\n\n Title: Reward Locking Parameter Changes: Increase Base Emissions, Decrease Max Multiplier\nAuthor: Kevin Chan\nStatus: Proposal\nSubmission Date: August 23, 2023\nSummary:\nRecent data shows Across’ Reward Locking program does well in retaining loyal liquidity providers (LPs); however, the growth of new LPs has been stagnant. As Across volumes grow, the total liquidity pool size is starting to become a constraint. The Across DAO should make modifications to the Reward Locking program to increase base emissions by 50% and decrease the max reward locking multiplier to 2x (from 3x). This should help attract new LPs without negatively impacting existing LPs nor increasing total protocol emissions.\nMotivation:\nRecent data shows Across’ Reward Locking program does well in retaining loyal liquidity providers (LPs). The Risk Labs data team found that of all existing LPs, 99% of them have earned a 100 day NFT and 91% of ETH LPs, which accounts for 70% of TVL, have never unstaked and claimed their rewards (for over 250 days!). This affirms reward locking is succeeding in its objective of accumulating a set of loyal LPs. However, the flip side to this is the growth of new LPs has been stagnant. Volumes on Across continue to grow as it steadily gains market share and expands to new destinations such as zkSync and Base. This has led to more frequent bursts of high utilization of the liquidity pools which increases bridging fees and dampens volumes. In order to ensure Across has the capacity to continue growing I propose making modifications to the emissions and parameters of the Reward Locking program. There are three objectives:\n\nAttract new LPs to increase the total TVL of the liquidity pool to facilitate higher volumes\nReduce any negative impact to existing loyal LPs\nEnsure total ACX emissions do not increase\n\nI propose making the following changes:\n\nIncrease base emissions by 50%\nDecrease the max reward locking multiplier to 2x (from 3x)\n\nThe resulting higher base APY would attract new LPs and help to increase TVL. Yield hunting LPs who look at websites like DeFiLlama and Nanoly (which currently does not include Across) would notice the opportunity more easily. Some of this may be mercenary capital, but the goal is to expose Across to more people in our ecosystem and capture new sticky capital.\nExisting loyal LPs would initially see their APY unaffected (ie. 150% x 2 / 3 = 1). However, as the number of LPs and TVL increases, existing LPs could see their total APY decrease as they share emissions with new LPs. On the other hand, the higher TVL will help to increase bridging volumes and the attention from new entrants could bring more awareness to the bridge. Both would act to add more value to the protocol and ultimately help the ACX token (what LPs earn).\nThe net result could be positive for everybody involved with Across as people “share a bigger pie”.\nSpecification & Implementation:\nThe Across DAO wallet controlled by ACX holders has admin rights to change the parameters of the Accelerating Distributor contract that powers the Reward Locking program. The exact transactions to make these modifications can be put to a vote and executed on Snapshot via the oSnap module which is already implemented.\nThere is one complication regarding the decrease in multiplier. Base emissions for each LP are accumulated as each block builds; however, the multiplier for each individual LP is applied only when a LP claims rewards. This means a long time LP with a 3x multiplier who claims rewards immediately before the modification would have a much higher payout compared to the LP claiming after the modification. To work around this, I propose taking a snapshot of total accumulated rewards for all LPs before the modification and comparing it to their total rewards after the modification. The difference can be stored in a merkle root distributor for LPs to claim.\nThis makes all existing LPs “whole” and has an added perk of allowing LPs to claim some ACX rewards without having to lose their multiplier.\nThe Risk Labs foundation can help with queuing up these parameter changes for oSnap execution, creating and running scripts to figure out the impact to existing LPs, and implementing any necessary front-end changes.\nDownside (Cons):\nThere are a couple potential downsides to these parameter changes:\n\nExisting loyal LPs may feel that losing their 3x multiplier is unfair even though higher base emissions compensate for this decrease. This could lead to some existing LPs exiting the protocol all together. On the other hand, the anticipated growth of Across protocol and the ability to claim some ACX without affecting their max multiplier may appease these loyal LPs.\nThe higher APY attracts a lot of mercenary capital that could immediately dump any farmed tokens. If the community believes the protocol has a lot of value this higher APY may also attract new community members and any selling pressure will be absorbed by willing buyers.\n\nVoting:\n\n Should the Across DAO increase base emissions by 50% and decrease the max reward locking multiplier to 2x (from 3x)? This would also mean a one time distribution of ACX is needed to ensure all existing LPs are compensated for the drop in their multiplier due to the way payout calculations are implemented.\n\n 89%\n Yes\n\n 11%\n No\n\n 0%\n Abstain\n\n 18\n voters\n\n Closed Aug 2023\n\n Reduce ACX emissions for Across ACX LPs\n\n Reduce or Reallocate Across ACX LP emissions\n\n 4\n\n 3\n\n 2\n\n read \n\n 5\n min\n\n post by Mide on Aug 23, 2023\n\n Mide\n\n This strategy seems smart for attracting new liquidity providers, expanding our ecosystem, and help boost trading volumes, super cool\nWhile the changes might initially attract LPs with short-term interest , I’m optimistic that our strong community and the value Across has to offer will turn them into committed, long-term participants. This sorta reflects the dynamic nature of DeFi in general\nKudos to the team for their strategic thinking. I’m excited to see how this plays out.\n\n post by berry4144 on Aug 23, 2023\n\n berry4144\n\n Hey Kevin.\nHow has the non-ACX interest rate changed as pool usage has increased? If usage is going up a lot why arent participants being paid much more (giving incentive for more depositors)?\n\n post by berry4144 on Aug 23, 2023\n\n berry4144\n\n IE: If pool utilisation hit 100% shouldnt the APY be almost infinity and the cost to bridge incredibly expensive? Or are they not on curves that take that into consideration?\n\n post by mydefi on Aug 23, 2023\n\n mydefi\n\n I believe the pros outweigh the cons in this scenario. Yes, some LPs may exit but most might not bother because of all the steps required to unstake and exit their positions. In addition I believe that it might make it more attractive for existing LPs to claim rewards and add to their existing positions.\n\n post by Mide on Aug 24, 2023\n\n Mide\n\n berry4144\n\n Reflecting on your comments, I realize that concerns like yours might indeed arise among our community members. It’s crucial that we address these concerns comprehensively to ensure that any adjustments we make truly benefit all stakeholders.\nIn light of your insights, I’d like to suggest potential solutions that MIGHT address the balance between liquidity providers’ interests and the protocol’s objectives:\nDynamic Reward Adjustment: One way to address the concern you raised is by implementing a dynamic reward adjustment mechanism. This means that rewards would be adjusted based on the utilization of the liquidity pool. As demand and usage increase, rewards would automatically rise to attract more liquidity providers. This approach aligns rewards more closely with the value being generated by the system.\n(Also I was thinking there could actually be a potential marketing strategy here maybe With rewards increasing as more users participate, we could indeed create a small-scale marketing effect within the LP community. This could naturally attract more liquidity providers, adding value to our ecosystem, it might also attract new LP’s seeing the amount of users we have that they could indeed benefit from this)\nUtilization-Weighted Rewards: Another approach could involve distributing rewards in proportion to the utilization of the pool. When the pool is highly utilized, rewards increase, and when utilization is lower, rewards decrease. This method encourages liquidity providers to contribute more when demand is high, while still offering incentives during quieter periods, now This one’s a little tricky although frankly the same, I think it actual gives a sense of belonging and sense of growth to the community and the LPs, people’s hearts are usually where their treasure is. \nI think these solutions aim to achieve several objectives that were central to the initial proposal, I’m open to corrections and thoughts as I’m just a creative thinker with a nose for growth and marketing lol still growing and learning myself.\n\n post by caesarsherrod.eth on Aug 24, 2023\n\n caesarsherrod.eth\n\n This is a smart change even though it reduces the rates of loyal stakers. I think this plan assumes that LPs are loyal to across and not the 3x Liquidity rewards. In effect, this move would prioritize LPs that are not here over those that are.\nI agree with this motion, but I would just like to acknowledge the risk of this motion. We are reducing the rates of current LPs for new ones. Someone might get offended by that & it is worth gauging.\n\n post by nico186 on Aug 26, 2023\n\n nico186\n\n This is a very well written proposal, multipliers can be very complex. I am in favor of this proposal because it considers existing, long standing LP’s into the equation. I think it is important to maintain these long term assets, but not at the cost of stifling growth within the ACX ecosystem.\n\n post by kodada on Aug 27, 2023\n\n kodada\n\n The proposal is good. However I am not sure this is what Across liquidity providers need. There is no precise financial analysis on how exactly the current utilization stands. Is it close to full utilization all the time, or much less frequent. I don’t believe the Across capacity is fully utilized yet, especially in current market conditions. Also increasing base rate will definitely attract some fresh capital seeking higher yield, but this capital can be not so loyal and fly easily. Also it doesn’t incentivize that much new loyal capital to stick for the long run. After all the 3X multiplier is one of the unique feature which distinguish Across from other Bridges and Liquidity pools. So I really would like to see that this step is needed before saying it should be done.\n\n post by Kevin_UMA on Aug 28, 2023\n\n Kevin_UMA\n\n berry4144\n\n Yes Across uses a fee model similar to borrow and lending protocols. Calculations here: Fee Model - Across Docs\nThe “Pool” APY does go up, but majority of rewards is driven by ACX emissions. As utilization approaches 100% there is a max rate that can be charged. (in the formula it is r0+r1+r2). I don’t remember the exact numbers for each asset though.\nWhen utilization does get high bridge users will go to competitors instead. That’s why a larger TVL would be beneficial to the protocol. Across has been doing a lot of volume with relatively small pool TVL, but the bridge is growing.\n\n post by Kevin_UMA on Aug 28, 2023\n\n Kevin_UMA\n\nI think these are great ideas. I think the community wanted the reward system to be simple at first, but as we grow and develop these mechanism could be useful. We love to see some more details in this and maybe even a proposal to get further disucssion.\n\n post by Kevin_UMA on Aug 28, 2023\n\n Kevin_UMA\n\n kodada\n\n It’s definitely not close to full utilization all the time and it depends on the asset. However, at times of stress in the market we have seen Across pool assets close to being exhausted and resulting in much higher bridge fees. More TVL would ensure that we avoid these scenarios and continue to remain the fastest and cheapest bridge.\n\n post by Mide on Aug 28, 2023\n\n Mide\n\n Kevin_UMA\n\n Sure thing! I’m willing to collaborate with the community if this is something they’d be interested in along the lines of our growth, glad you like the idea!\n\n post by ayoki on Aug 29, 2023\n\n ayoki\n\n It’s great to see the positive outlook towards potential changes in the multiplier. I think this is a great proposal in that it provides a solution to a pressing liquidity issue that makes strategic use of protocol incentives, while retaining the multiplier function, which I agree is a highly praised innovation of Across.\nEspecially with our recent and upcoming deployments to new chains, I think it’s a great time to capture a new group of LP capital while we have the attention of a wider audience.\n\n 1 month later\n\n Closed on Sep 28, 2023\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 Reduce or Reallocate Across ACX LP emissions\n\n Ideas & Feedback\n\n liquidity\n\n Ideas & Feedback\n\n 2\n\n Sep 2023\n\n Reduce ACX emissions for Across ACX LPs\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 8\n\n Nov 2023\n\n Across Token Launch Proposal v2\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 47\n\n Nov 2022\n\n ACX Emissions Committee\n\n Proposals\n\n governance-updates\n\n Proposals\n\n Dec 2023\n\n Reduce ACX emissions for ACX LPs, WBTC LPs and wstETH/ACX LPs\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 11\n\n Aug 2024","tokens":4926,"squid":"spider-09","role":"Bridge Spider","at":1791343152027,"hash":"b2c619bcc654e662528c4032d88e194551023962"}
{"url":"https://ethresear.ch/t/champ-hardening-the-mempool-with-chain-anchored-multi-dimensional-peer-protection/26074","domain":"ethresear.ch","title":"CHAMP: Hardening the Mempool with CHain-Anchored, Multi-dimensional Peer Protection - Execution Layer Research - Ethereum Research","text":"CHAMP: Hardening the Mempool with CHain-Anchored, Multi-dimensional Peer Protection \n\n Execution Layer Research\n\n p2p,networking\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 23\n\n 13d ago\n\n post by cskiraly on Sep 24\n\n cskiraly\n\n Author: @cskiraly\nTL;DR\n\nClients keep their peer set fresh with random churn — periodically dropping random peers. This keeps the network open to newcomers and resistant to eclipse attacks, but it is blind to peer quality: it drops our most useful peers as readily as idle ones.\nWe add CHAMP, a set of protected peer pools: in each pool, a small set of our champion peers is shielded from random dropping, layered on top of churn. The churn rate is unchanged: drops simply land on the unprotected majority (≥70% of each pool, even with all three categories).\nPeer quality is multi-dimensional. Instead of collapsing it into a single score, we protect the top slice in each dimension independently — a peer survives if it is valuable along any one axis.\nTwo of the three categories are anchored to on-chain outcomes: they credit a peer only when transactions it delivered first get included at the head and, later, finalized. The signal is objective, and the way to earn it is to feed us transactions that land on-chain.\nThe design is on by default and extensible — new quality dimensions slot in without re-tuning a global score. Shipped in go-ethereum v1.17.5 (#34702); request-latency protection (the third dimension) is in progress in #34771.\n\nIntroduction\nEvery node in a peer-to-peer network keeps a bounded number of connections. In an open network that creates a subtle problem: once established nodes fill their slots they rarely free them, newcomers struggle to find room, and the connection graph ossifies — bad for accessibility, and bad for security, since a static, predictable graph is easier to attack. The standard fix is to keep the peer set churning: periodically drop peers at random so slots keep reopening and the graph never stays fixed.\nThat random dropping does its job, but it is blind to quality. The peer that has been reliably feeding us transactions that end up on-chain is exactly as droppable as one that has done nothing for us yet. In keeping the door open for newcomers, we keep evicting the peers we would most like to keep.\nThe transaction mempool makes this sting more, because it lives at the edge of the protocol. It is off-chain: there is no consensus on who behaved well, no ground truth about which peer is worth keeping — yet its health (how fresh it is, how fast transactions propagate) depends heavily on which peers we are connected to.\nWe want to keep the churn and the random graph, and add a quality overlay on top: protect the peers that are demonstrably useful, and let the rest churn freely. The rest of this post builds that overlay — and, crucially, does it without collapsing peer quality into a single score.\nThe idea of chain-anchored peer protection goes back to early 2025, partly implemented in #31974. Inclusion-based protection has since shipped in go-ethereum v1.17.5 (#34702), and request-latency protection is in progress in #34771.\nSaturated peer sets, and the churn that fixes them\nThis problem is not specific to Geth, or even to Ethereum: it shows up in any open peer-to-peer network where nodes have a bounded number of connection slots.\nA node accepts a bounded number of connections. On a well-established, long-running node those slots fill up — especially the inbound ones — and then stay full, because there is no reason for a healthy long-lived connection to close on its own. From the incumbent’s point of view everything is fine. From a new joiner’s point of view the network looks closed: every good node it tries to reach is already at capacity and turns it away. The network drifts toward an ossified set of old connections, and newcomers have a hard time getting in at all. Not something we can afford in a permissionless network.\nThe established remedy is induced churn: deliberately perturb each node’s connections so that slots keep opening up and no connection graph stays fixed for long. This is not a Geth invention. Induced churn was proposed as a defence against routing-table poisoning and eclipse attacks [1] in structured overlays by Condie et al. [2]. Why keeping the graph random matters is just as well studied: gossip-based peer sampling keeps an overlay close to a random graph and highly resilient to massive node failure [3], and CYCLON shows such overlays can combine low diameter with low clustering [4]. And the threat this defends against is concrete for Ethereum — eclipse attacks have been demonstrated against Bitcoin [5] and against Ethereum specifically [6], several of whose countermeasures shipped in geth 1.8.0 (February 2018). More recent work eclipses today’s execution-layer nodes by exploiting exactly the saturated, rarely-idle inbound slots described above [7].\nGeth applies induced churn with a simple mechanism: it periodically disconnects a random peer when a pool (inbound or dialed) is full, added in 2025 in #31476. (We will call this the peer dropper, or just the dropper, for the rest of the post.) That one mechanism does a surprising amount of work:\n\nIt keeps the door open. Every drop frees a slot, so there is always a steady supply of openings for nodes trying to join. Accessibility for newcomers is the original motivation.\nIt keeps the overlay fresh, and keeps us exploring. Stale or low-quality connections do not linger forever. When a dialed peer is dropped, the dial scheduler refills the slot from discovery candidates, so the node keeps sampling the network and getting chances to find better peers.\nIt keeps the overlay a random graph. Random dialing plus random dropping means each node’s neighbourhood is a fresh, unpredictable sample of the network — which buys eclipse resistance (an attacker cannot cheaply pin which peers we keep) and good propagation (random regular-ish graphs have short diameters and strong expansion).\n\nSo random dropping is not a nuisance to be minimised — it is load-bearing infrastructure for an open, healthy network. Whatever we add on top must preserve the churn and the randomness, not fight them. Protected peer pools are meant to sit inside this well-understood churn regime, not to replace it.\nThe tension: we keep evicting our best peers\nHere is the cost. “Drop a random peer” treats all peers as interchangeable, and they are not. Some peers are the reason our mempool is fresh; some are the reason our transactions propagate; some answer our requests in tens of milliseconds while others time out. Because the drop is random, a peer’s usefulness has no bearing on whether it survives the next round of churn.\nDropping one of the good ones is not fatal — we re-dial and recover — but it is wasteful, and doing it repeatedly likely hurts exactly the metrics we care about. We are paying for network openness with the currency of our best connections.\nSo the real question is: can we keep the churn and the random graph — the things that keep the network open — and still spare the peers that are demonstrably useful?\nWhy not just score peers?\nThe obvious answer is “score each peer and protect the top ones.” libp2p’s GossipSub already does something like this: it maintains a per-peer score and uses it for mesh maintenance and pruning [8], [9]. It is a well-tested design, and it is tempting to reach for the same hammer. Classic P2P reputation systems such as EigenTrust take a different route, aggregating peers’ local ratings of each other into a single global trust value [10].\nBut single-scalar scoring has a structural weakness we want to avoid: it collapses many behaviours into one number. In GossipSub, time-in-mesh, message deliveries, invalid messages, and application-specific signals are all folded together through a set of weights. That forces two uncomfortable things:\n\nYou have to pick the weights. A weighted score sets exchange rates between different kinds of service, and the right rates are hard to find across heterogeneous peers and changing conditions.\nIt can overlook peers that are excellent along one axis. Depending on normalization and weights, a peer that is superb at exactly one useful job but average elsewhere can rank below peers that are merely decent at everything — and get treated as average.\n\nPeer quality in the mempool is genuinely multi-dimensional:\n\nA peer whose transactions consistently get finalized — a strong signal, but slow.\nA peer whose transactions consistently show up at the chain head right now — faster, noisier.\nA peer that is very fast to answer requests, even when its transactions rarely appear on-chain.\n\nSquashing these into one score throws information away by construction.\nWe are not the first to protect peers along several criteria. When pruning an oversubscribed mesh, GossipSub keeps its highest-scoring peers and picks the rest at random, subject to an outbound quota [9]. Closest to what we do, Bitcoin Core’s inbound eviction has protected peers along several distinct criteria since #6374 (v0.12.0, 2016) [11], originally network group, ping, and connection age, since extended with the recency of novel transactions and blocks and with network diversity. When inbound capacity runs out, it applies these protections one after another, then evicts from what is left. So multi-criteria protection is not new. What we add is anchoring it to chain outcomes, selecting each category independently and taking the union, and running it on top of timer-driven random churn of full pools — including the peers we dialed — rather than capacity-driven eviction of inbound peers:\n\nGeth dropper + CHAMP\nBitcoin Core inbound eviction\n\nTrigger\nOne timer, every 3–7 minutes: when synced, attempt one drop among eligible peers of full pools, independently of incoming connection demand\nCapacity-driven: when an inbound connection would exceed the inbound limit, or inbound transaction-relay peers exceed theirs\n\nScope\nInbound and dynamically dialed peers; a separate dial scheduler refills outbound capacity\nInbound only (outbound peers are explored and rotated through separate mechanisms)\n\nVictim choice\nUniformly random among the remaining candidates\nRule-based: after protection (and any preferential-eviction filter), the youngest peer in the largest remaining network group\n\nProtection\nIndependent per category: up to ⌊10% of the current pool⌋ with a positive score, then unioned\nSequential: fixed counts per stage (e.g. 4 by network group, 8 by lowest ping, 4 by recent novel transactions), each taken from what the previous stages left, then half of the remainder by connection age and network diversity\n\nSignals\nEventual inclusion and finality of transactions the peer delivered first; request latency in #34771\nKeyed network group, minimum ping, recency of novel transactions and blocks, relay type, connection age, network diversity\n\nChurning dialed peers is deliberate. Induced churn is not only about making room for newcomers; it is also how a node explores the topology. When a dialed peer is dropped, the dial scheduler refills the slot from discovery candidates, so the node keeps sampling the network instead of settling on the first peers it happened to find. Bitcoin explores too, through separate outbound probing; what differs here is that established peers themselves keep rotating. Protection and churn are two halves of one loop: churn explores, and protection keeps the good peers that exploration turns up. Protecting the best peers only makes sense if we keep looking for better ones.\nProtected peer pools: a quality overlay, not a ranking\nProtected peer pools sidestep the weighting problem entirely. Instead of ranking peers on a combined score, we rank them separately in each dimension and protect the top slice of each ranking. The protected set is the union across dimensions. A peer only has to be good at one thing to be safe, and we never have to decide how many “fast responses” equal one “finalized transaction.”\nOne combined score versus a top slice per dimension2500×1240 228 KB\nFigure 1. The same 50 peers (synthetic, for illustration) and the same budget of 10 protected peers, chosen two ways. A combined score (here an equal-weight average) protects everything above a diagonal, so it keeps peers that are decent at both but best at neither, and leaves unprotected the peers that are the best along one axis. Ranking each dimension separately protects an L-shaped region, and keeps those one-axis champions.\nCrucially, this is an overlay, not a replacement. Random churn still runs; it just runs around the protected set. The random graph is preserved for the unprotected majority, and we carve out protection only for the peers that have earned it. We are hardening the mempool without giving up the properties that make the overlay robust in the first place.\nThe mechanics are intentionally boring, which is what you want in the dropper path:\n\nEach protection category produces its own ranking of peers by its own score.\nWithin each category we protect the top ~10% of each pool, computed per pool: inbound peers and dialed peers are ranked independently. Inbound and outbound connections have very different trust and attack profiles, and we do not want a flood of inbound peers to crowd out protection for the peers we chose to dial (or vice-versa).\nOnly peers with a positive score in a category can be protected by it — an idle peer with no signal is not “top 10%”, it is simply unranked.\nThe dropper computes the protected set first, then makes its random choice from whatever is left.\n\nThe protection mechanism on Geth's default pools2600×980 144 KB\nFigure 2. The mechanism on Geth’s default pools (34 inbound, 16 dialed), with the latency category of #34771; which peers are protected is made up for illustration. Each category marks its top 10% of each pool independently; peers in several categories count once. Assuming both pools are full, the node is synced, and no peer is trusted, static, or younger than 10 minutes, everything left is an ordinary random drop candidate.\nHow much churn do we give up? None, in terms of rate. Protection does not reduce the churn rate: the dropper removes protected peers from the candidates before its random pick, so it still drops one peer per period, just never a protected one. Slots open for newcomers as often as before, which matters most for the problem we started from; unprotected peers simply turn over slightly faster.\nWhat protection does change is who can be dropped, and that is easy to bound. Each category protects at most ~10% of a pool, and a peer needs only one of them, so with three categories at most ~30% of each pool is protected. With Geth’s defaults (50 peers: 16 dialed, 34 inbound) and rounding down, that is at most 3 of 16 dialed peers and 9 of 34 inbound ones. In practice it is less, since the good peers tend to overlap across categories. So at least ~70% of every pool stays a drop candidate. That bound holds for any number of attacker identities: protection itself exempts at most that many slots. It does not bound how many slots an attacker holds overall — attackers can also sit in unprotected slots, where churn keeps rotating them out like everyone else.\nProtection is not tenure. Nothing is protected for good. Every score is an exponential moving average (EMA): at each update (each block; for latency, each request), score ← (1 − α)·score + α·(new value), so older contributions fade geometrically, with a half-life of about ln 2 / α updates. Protection is recomputed from these scores each time the dropper runs. A peer that stops delivering useful transactions, or starts answering slowly, decays, and active peers soon overtake it — within minutes for the fast included EMA, within about a day for the finalized one — making it an ordinary churn candidate again. Decay is not expiry: in a quiet pool a peer with a small leftover score can still rank in the top slice, but it falls behind as soon as others contribute. That decay is what keeps the protected set from ossifying into exactly the static graph that churn was introduced to prevent.\nProtection is on by default in Geth and needs no configuration. It also degrades gracefully: only peers with a positive score can be protected, so a fresh node with no stats behaves exactly like plain random churn. The category list is a simple extensible slice, so adding a fourth dimension later is a local change.\nAnchoring protection to the chain\nHere is the part we think is the most interesting.\nThe mempool is off-chain. There is no consensus about it, no canonical record of who sent what first, no ground truth we can point to when deciding whether a peer is honest or useful. That is precisely the environment in which peer scoring tends to go wrong: the signals are local, gameable, and unverifiable.\nSo instead of scoring peers on off-chain behaviour, we bind protection to on-chain outcomes. We watch which peer first delivered each transaction, and we credit that peer only when the transaction actually lands on-chain — at the head, and later at finality. The chain is the arbiter. A peer’s protection is earned by contributing transactions that the network as a whole agreed to include.\nThis turns an off-chain popularity contest into something closer to quality assurance:\n\nThe signal is objective — inclusion and finalization are facts, not opinions.\nIt is hard to fake — a peer cannot claim inclusions it did not contribute to.\nIt rewards the behaviour we actually care about — feeding us transactions that matter, not merely being chatty.\n\nOff-chain overlay, on-chain accountability. That pairing is the core idea.\nCan protection be earned without being useful?\nA natural objection: can’t a peer simply buy protection, by sending its own transactions and paying to get them included? It can — and that is not an attack. A peer that originates real transactions, pays their fees, and delivers them to us first is doing exactly what we want to reward. Busy senders such as exchanges, rollup batchers, and bridge relayers will earn protection this way, and they should. Whether a peer is the source of a transaction or a fast relay for someone else’s, what we credit is the same: it got us transactions that the chain then accepted, before anyone else did.\nWhat would matter is a peer using a protected slot for something we do not measure. That is where the cap does its work: however protection is earned, it exempts at most 3 of 16 dialed and 9 of 34 inbound peers. Protection can help an attacker keep a foothold, but on its own it cannot give it more of our slots than that.\nWhich signals earn protection?\nRecent-included and recent-finalized (inclusion stats)\nA minimal tracker records the deliverer of each transaction; when that transaction appears at the head we credit the peer’s recent-included EMA, and when it finalizes we credit the recent-finalized EMA.\nThe two EMAs are deliberately tuned to different timescales:\n\nRecent-included is a fast EMA (α = 0.05, a half-life of ~14 blocks, under 3 minutes) — it reacts within a handful of blocks, so a peer that starts being useful is protected quickly, and one that goes quiet loses protection quickly.\nRecent-finalized is a slow EMA (roughly a day’s half-life) — it rewards sustained, long-run usefulness and is much harder to fake with a short burst.\n\nKeeping both means we protect both the peer that is hot right now and the peer that has been quietly reliable for a day.\nRequest-latency\nThe third dimension (#34771) scores peers on how quickly and reliably they answer our GetPooledTransactions requests. The tx fetcher gained an onRequestResult(peer, latency, timeout) callback that fires once per request outcome — either a delivery with the real round-trip, or a timeout with the timeout value. A delivery only counts if the pool accepted at least one of the transactions we requested: answering with duplicates, rejected transactions, or something else entirely earns nothing. Since a transaction we already have is a duplicate, a peer only earns samples by getting new transactions to us ahead of the network’s normal diffusion.\nPeers are scored by 1 / RequestLatencyEMA, so faster peers score higher:\n\nThe latency EMA is slow (α = 0.01, ~70-sample half-life). One lucky fast response does not buy protection; one unlucky slow one does not lose it.\nTimeouts count as the timeout value fed into the EMA. A peer that chronically fails to answer drags its own score down — there is no way to look fast by simply not responding.\n\nThis one is not anchored to inclusion the way the other two categories are, but it is not free-floating either: only requested transactions the pool accepts — valid against the current chain state — earn a sample, and eligibility requires such deliveries in at least ~1 block in 5. Beyond that, it has its own built-in ground truth: latency is measured, not reported, and a timeout is a timeout.\nDefending against gaming\nAny protection scheme is an incentive, and in an open, permissionless network an adversary can cheaply spin up identities to farm it — the Sybil problem [12]. So each dimension has guards against a peer cheating its way into a protected slot:\n\nInclusion credit requires an accepted, early delivery. Only transactions the pool accepted from that peer count, and only if delivered before they were included. Spraying transactions we already have, or relaying ones already on-chain, earns nothing.\nReorg-aware: finalized credit is only awarded if the inclusion block is still canonical.\nRequest-latency requires sustained activity. A peer’s latency only counts while it keeps making accepted deliveries (in ~1 block in 5). A burst cannot front-load eligibility, and a peer that goes silent soon loses it — and eventually its latency history.\nMemory is bounded: the tracker keeps at most 2^18 transaction-to-peer mappings, so it cannot be turned into a memory-exhaustion vector.\n\nHow is it implemented in Geth?\nThe work is split in three: a tracker that records which peer delivered each transaction and turns new head and finalized blocks into per-peer credits, a passive stats aggregator that keeps the EMAs and exposes a per-peer snapshot, and the dropper, which reads that snapshot through a callback and applies the per-pool selection. The dropper never touches transaction machinery, so the churn path stays as simple as it was.\nOpen questions\nThis is a first cut, and there are knobs we have not pinned down:\n\nIs 10% per pool the right slice? Too small and we barely protect anyone; too large and we starve churn and weaken the random-graph properties. We intentionally started low, but proper tuning requires further analysis.\nThe EMA constants are educated guesses. The included/finalized/latency half-lives were chosen to feel right at different timescales, not fit to data yet.\nIs reliability its own dimension? Today timeouts feed into the latency average, which is the right place for them: a peer that often times out drags its average toward the timeout, so it can only win latency protection when there is no better candidate. How often a peer answers at all, as opposed to how fast, might still deserve a category of its own.\nHow much does the overlay perturb the random graph? The churn rate is unchanged and the ~30% bound caps how many peers are exempt from it, but we have not characterised the resulting graph, nor its behaviour under adversarial inbound floods.\nThe drop rate itself is an educated guess. There is no ideal rate: no two days on a p2p network look the same. What matters is that a peer gets a fair chance to earn protection before random selection reaches it. New peers are exempt for their first 10 minutes, and with one drop every ~5 minutes over ~40 candidates an unprotected peer expects to last ~3.4 hours — long enough to earn protection in any category. Even the finalized score turns positive with a peer’s first finalized transaction, about 13 minutes after inclusion; its day-scale half-life governs how long evidence is kept, not how long it takes to earn.\n\nFuture work\nThe extensible-dimension design is the point: each new signal is a small, self-contained addition rather than a re-tuning of one global score. Candidates we are thinking about:\n\nA blob-serving dimension. With the sparse blobpool (#34047), how reliably and quickly a peer serves blob data becomes a quality of its own.\nRemembering peers across disconnects. Keeping (bounded) stats for disconnected peers, so a good peer that loses its connection for unrelated reasons does not start from zero when it reconnects.\nMeasuring it on mainnet: the protected fraction of each pool, how much the categories overlap, and the effect on mempool freshness.\n\nWhat we introduce here is a concept, not just a Geth design or an EL mechanism. The CL, whose peer management currently rests largely on GossipSub’s single-score model, is a good candidate for the same approach, with block, payload and blob propagation as its natural dimensions.\nFeedback very welcome — especially on the pool fraction, the EMA timescales, and any gaming vector we have not thought of.\nReferences\n[1] A. Singh, T.-W. Ngan, P. Druschel, D. S. Wallach. “Eclipse Attacks on Overlay Networks: Threats and Defenses.” IEEE INFOCOM, 2006. [doi]\n[2] T. Condie, V. Kacholia, S. Sankararaman, J. M. Hellerstein, P. Maniatis. “Induced Churn as Shelter from Routing-Table Poisoning.” NDSS, 2006. [pdf]\n[3] M. Jelasity, S. Voulgaris, R. Guerraoui, A.-M. Kermarrec, M. van Steen. “Gossip-based Peer Sampling.” ACM Transactions on Computer Systems, 25(3), Art. 8, 2007. [doi] [pdf]\n[4] S. Voulgaris, D. Gavidia, M. van Steen. “CYCLON: Inexpensive Membership Management for Unstructured P2P Overlays.” Journal of Network and Systems Management, 13(2), 197–217, 2005. [doi]\n[5] E. Heilman, A. Kendler, A. Zohar, S. Goldberg. “Eclipse Attacks on Bitcoin’s Peer-to-Peer Network.” USENIX Security, 129–144, 2015. [pdf]\n[6] Y. Marcus, E. Heilman, S. Goldberg. “Low-Resource Eclipse Attacks on Ethereum’s Peer-to-Peer Network.” IACR ePrint 2018/236, 2018. [eprint]\n[7] R. Shi, Y. Liang, Z. Guo, Q. Wang, L. Lan, C. Wang, Z. Zheng. “Eclipse Attacks on Ethereum’s Peer-to-Peer Network.” The ACM Web Conference (WWW), 2026. [arxiv]\n[8] D. Vyzovitis, Y. Napora, D. McCormick, D. Dias, Y. Psaras. “GossipSub: Attack-Resilient Message Propagation in the Filecoin and ETH2.0 Networks.” arXiv:2007.02754,\n2020. [arxiv]\n[9] libp2p. “gossipsub v1.1: Security extensions to improve on attacks and mitigate risks.” Specification. [github]\n[10] S. D. Kamvar, M. T. Schlosser, H. Garcia-Molina. “The EigenTrust Algorithm for Reputation Management in P2P Networks.” WWW, 640–651, 2003. [doi] [pdf]\n[11] P. Strateman. “Connection slot exhaustion DoS mitigation.” Bitcoin Core pull request #6374, released in v0.12.0, 2016. [github]; current logic in src/node/eviction.cpp\n[12] J. R. Douceur. “The Sybil Attack.” IPTPS, LNCS 2429, 251–260, 2002. [doi]\nAcknowledgments\nThanks to the Geth team for review and discussion on #34702 and #34771.\n\n read \n\n 10\n min\n\n Powered by Discourse","tokens":6786,"squid":"spider-04","role":"Research Spider","at":1791343152277,"hash":"c8605df2d82ece6f770d681dac17cdcbe175fd80"}
{"url":"https://www.metaplex.com/docs/tokens/burn-tokens","domain":"metaplex.com","title":"How to Burn Fungible Tokens on Solana | Tokens","text":"Burn fungible tokens to permanently remove them from circulation on the Solana blockchain. Burn TokensIn the following section you can find a full code example and the parameters that you might have to change. Burning tokens permanently destroys them—this action cannot be undone.1// To install all the required packages use the following command\n2// npm install @metaplex-foundation/mpl-toolbox @metaplex-foundation/umi @metaplex-foundation/umi-bundle-defaults\n3import {\n4 burnToken,\n5 findAssociatedTokenPda,\n6} from '@metaplex-foundation/mpl-toolbox';\n7import {\n8 keypairIdentity,\n9 publicKey,\n10} from '@metaplex-foundation/umi';\n11import { createUmi } from '@metaplex-foundation/umi-bundle-defaults';\n12import { readFileSync } from 'fs';\n13\n14// Initialize Umi with Devnet endpoint\n15const umi = createUmi('https://api.devnet.solana.com')\n16\n17// Load your wallet/keypair\n18const wallet = '<your wallet file path>'\n19const secretKey = JSON.parse(readFileSync(wallet, 'utf-8'))\n20const keypair = umi.eddsa.createKeypairFromSecretKey(new Uint8Array(secretKey))\n21umi.use(keypairIdentity(keypair))\n22\n23// Your token mint address\n24const mintAddress = publicKey('<your token mint address>')\n25\n26// Find the token account to burn from\n27const tokenAccount = findAssociatedTokenPda(umi, {\n28 mint: mintAddress,\n29 owner: umi.identity.publicKey,\n30})\n31\n32// Burn 100 tokens\n33await burnToken(umi, {\n34 account: tokenAccount,\n35 mint: mintAddress,\n36 amount: 100,\n37}).sendAndConfirm(umi)\n38\n39console.log('Burned 100 tokens')\n40console.log('Mint:', mintAddress)\n41console.log('Token Account:', tokenAccount)\nParametersCustomize these parameters for your burn operation:ParameterDescriptionmintAddressThe token mint addressamountNumber of tokens to burnHow It WorksThe burn process involves two steps:Find your token account - Locate your token account using findAssociatedTokenPdaBurn tokens - Execute the burn with burnTokenWhen to Burn TokensCommon use cases for burning tokens include:Reducing supply - Decrease total circulating supplyDeflationary mechanics - Implement tokenomics that reduce supply over timeError correction - Remove tokens minted by mistakeImportant NotesBurning is permanent and cannot be reversedYou can only burn tokens that you ownThe amount should account for decimals (e.g., for 9 decimals, burning 1 token requires amount: 1_000_000_000)","tokens":592,"squid":"dotcat","role":"Tooling Spider","at":1791343158196,"hash":"ab0df2360cc4208608eb39e418c2cfeac2327999"}
{"url":"https://www.metaplex.com/docs/tokens/mint-tokens","domain":"metaplex.com","title":"How to Mint Additional Fungible Tokens on Solana | Tokens","text":"Mint additional fungible tokens to increase the circulating supply of your token on Solana. Mint TokensIn the following section you can find a full code example and the parameters that you might have to change. This assumes you already have a fungible token created and want to mint more tokens.1// To install all the required packages use the following command\n2// npm install @metaplex-foundation/mpl-toolbox @metaplex-foundation/umi @metaplex-foundation/umi-bundle-defaults\n3import {\n4 createTokenIfMissing,\n5 findAssociatedTokenPda,\n6 mintTokensTo,\n7} from '@metaplex-foundation/mpl-toolbox';\n8import {\n9 keypairIdentity,\n10 publicKey,\n11 transactionBuilder,\n12} from '@metaplex-foundation/umi';\n13import { createUmi } from '@metaplex-foundation/umi-bundle-defaults';\n14import { readFileSync } from 'fs';\n15\n16// Initialize Umi with Devnet endpoint\n17const umi = createUmi('https://api.devnet.solana.com')\n18\n19// Load your wallet/keypair\n20const wallet = '<your wallet file path>'\n21const secretKey = JSON.parse(readFileSync(wallet, 'utf-8'))\n22const keypair = umi.eddsa.createKeypairFromSecretKey(new Uint8Array(secretKey))\n23umi.use(keypairIdentity(keypair))\n24\n25// Your token mint address and destination wallet\n26const mintAddress = publicKey('<your token mint address>')\n27const destinationAddress = publicKey('<destination wallet address>')\n28\n29// Find the destination token account\n30const destinationTokenAccount = findAssociatedTokenPda(umi, {\n31 mint: mintAddress,\n32 owner: destinationAddress,\n33})\n34\n35// Create the destination token account if it doesn't exist and mint tokens\n36await transactionBuilder()\n37 .add(createTokenIfMissing(umi, {\n38 mint: mintAddress,\n39 owner: destinationAddress,\n40 }))\n41 // Mint 100 tokens to the destination\n42 .add(\n43 mintTokensTo(umi, {\n44 mint: mintAddress,\n45 token: destinationTokenAccount,\n46 amount: 100,\n47 }))\n48 .sendAndConfirm(umi)\n49\n50console.log('Minted 100 tokens')\n51console.log('Mint:', mintAddress)\n52console.log('To:', destinationTokenAccount)\n1# Mint Additional Tokens using the Metaplex CLI\n2\n3# Mint tokens to your own wallet (default)\n4# Usage: mplx toolbox token mint <MINT_ADDRESS> <AMOUNT>\n5mplx toolbox token mint <MINT_ADDRESS> <AMOUNT>\n6\n7# Mint tokens to a specific recipient\n8mplx toolbox token mint <MINT_ADDRESS> <AMOUNT> --recipient <RECIPIENT_ADDRESS>\n9\n10# Example: Mint 1000 tokens (0 decimals) to your wallet\n11mplx toolbox token mint 7xKXtg2CW87d97TXJSDpbD5jBkheTqA83TZRuJosgAsU 1000\n12\n13# Example: Mint 1000 tokens (9 decimals) to your wallet\n14# Amount is in smallest units: 1000 * 10^9 = 1000000000000\n15mplx toolbox token mint 7xKXtg2CW87d97TXJSDpbD5jBkheTqA83TZRuJosgAsU 1000000000000\n16\n17# Example: Mint tokens to another wallet\n18mplx toolbox token mint 7xKXtg2CW87d97TXJSDpbD5jBkheTqA83TZRuJosgAsU 1000 \\\n19 --recipient 9WzDXwBbmkg8ZTbNMqUxvQRAyrZzDsGYdLVL9zYtAWWM\n20\n21# Note: You must be the mint authority to mint additional tokens\nParametersCustomize these parameters for your mint operation:ParameterDescriptionmintAddressThe token mint addressdestinationAddressWallet address to receive the tokensamountNumber of tokens to mintHow It WorksThe minting process involves three steps, that you may or may not have to execute manually, depending on the tool you are using. The following steps are focusing on umi:Find destination token account - Locate the recipient's token account using findAssociatedTokenPdaCreate token account if needed - Use createTokenIfMissing to ensure the recipient has a token accountMint tokens - Execute the mint with mintTokensToRequirementsTo mint additional tokens, you must be the mint authority - Only the wallet designated as the mint authority can mint new tokensImportant NotesDepending on the tool you are using, you may or may not have to account for decimals. The amount should account for decimals (e.g., for 9 decimals, minting 1 token requires amount: 1_000_000_000)You can mint to any wallet address—the token account will be created if it doesn't existOnly the mint authority can mint new tokens","tokens":1012,"squid":"dotcat","role":"Tooling Spider","at":1791343168154,"hash":"08d71463d2694286d633b5a7d64499111a3566a4"}
{"url":"https://www.metaplex.com/docs/guides","domain":"metaplex.com","title":"The leading tokenization platform on Solana. | Metaplex","text":"GTR1.23%RENDER1.85%RAY1.91%CARDS0.22%MET10.44%SPYx0.54%AUTO0.01%BOME1.43%ORE4.25%MSFTx0.87%GOOGLx0.04%STRCx0.18%GLDx0.41%xORCA37.63%GRIFFAIN26.51%CRED4.70%PUMPCADE28.95%SOLO11.00%baton49.61%PAXG0.43%PAID87.79%EMBER29.65%KNOTS47.97%DARK49.55%TWEETCRAFT12,375.33%SI2766,932.39%CLAUDIA6,416.89%LOOT5,192.94%NFLX2.38%JUICE1,602.37%GTR1.23%RENDER1.85%RAY1.91%CARDS0.22%MET10.44%SPYx0.54%AUTO0.01%BOME1.43%ORE4.25%MSFTx0.87%GOOGLx0.04%STRCx0.18%GLDx0.41%xORCA37.63%GRIFFAIN26.51%CRED4.70%PUMPCADE28.95%SOLO11.00%baton49.61%PAXG0.43%PAID87.79%EMBER29.65%KNOTS47.97%DARK49.55%TWEETCRAFT12,375.33%SI2766,932.39%CLAUDIA6,416.89%LOOT5,192.94%NFLX2.38%JUICE1,602.37%The leading tokenization platform on Solana.Launch and trade onchain assets.Launch a TokenIssue an RWA$14B+cumulative trading volume$13M+primary sale value9project token sales$470M+combined FDV1B+transactions powered$10B+transaction value$14B+cumulative trading volume$13M+primary sale value9project token sales$470M+combined FDV1B+transactions powered$10B+transaction value$14B+cumulative trading volume$13M+primary sale value9project token sales$470M+combined FDV1B+transactions powered$10B+transaction value$14B+cumulative trading volume$13M+primary sale value9project token sales$470M+combined FDV1B+transactions powered$10B+transaction valueWhy MetaplexMetaplex is where assets on Solana move from launch to active markets, with issuance and live trading all in one platform.Two sides, one market.For issuers1Run your token sale with configurable tools for a controlled, fair launch.Learn more2Create all asset types on Solana including tokens and NFTs with Metaplex protocols.Learn more3Issue tokenized securities or RWAs using Metaplex protocolsLearn moreFor Investors & TradersDiscover live token sales and trade different asset types with Metaplex.Start tradingInfrastructure the ecosystem already runs on.Access the largest network in the ecosystem, with provenance and settlement the ecosystem already trusts.Proven scale1B+Transactions poweredSolana$13B+Transaction volumeMarkets1B+Digital assets createdIssuanceDEX partnerToken sale liquidity auto-migrates from Metaplex to Raydium CPMM pools for liquidity depth and healthy trading. Spotlight customers are eligible to use CLMM pools and configure more advanced liquidity strategies.Raydium - DEX partner1B+Transactions poweredElite Partners","tokens":590,"squid":"dotcat","role":"Tooling Spider","at":1791343180722,"hash":"b4af428358b99ade131433bcfa40e0f2da147019"}
{"url":"https://developers.jup.ag/docs/ai/skills","domain":"developers.jup.ag","title":"Skills - Jupiter Developers","text":"Jupiter’s agent skills repository provides structured context that AI coding agents use when building with Jupiter APIs. Each skill is a SKILL.md file containing integration guidance, API playbooks, code examples, and best practices that your AI agent consumes as reference material.\n​Available Skills\n​integrating-jupiter\nComprehensive integration guidance for all Jupiter APIs. This is the starting point for any Jupiter integration.\nCategoryDescriptionSwapFlagship swap API with managed execution (/order + /execute), custom transactions (/build), and gasless supportLendDeposit and withdraw assets to earn yieldPerpsPerpetual futures tradingTriggerLimit orders with price conditionsRecurringDollar-cost averaging (DCA) strategiesTokenToken metadata, search, and organic scoringPriceReal-time and historical pricingPortfolioDeFi wallet positions across protocolsPrediction MarketsBinary outcome markets with JupUSDSendToken transfers via invite linksStudioToken creation with Dynamic Bonding CurvesLockToken vesting and lockRoutingDEX aggregation, RFQ integration, and market listing\nThe skill includes an intent router that maps developer goals to the right API, complete endpoint references, error handling patterns, and production hardening recommendations.\nInstall:\nnpx skills add jup-ag/agent-skills --skill \"integrating-jupiter\"\n\n​jupiter-lend\nDeep-dive integration guidance for Jupiter Lend (powered by Fluid Protocol). Use this when building lending and borrowing features.\nCategoryDescriptionKey ConceptsProtocol architecture, jlTokens, exchange prices, collateral factors, sentinel valuesLiquidityQuerying liquidity pool data, interest rates, and supply/borrow positionsLending (jlTokens)Depositing and withdrawing assets to earn yield via @jup-ag/lendVaultsCollateral deposits, borrowing, repaying, and position managementFlashloansUncollateralised loans for atomic operationsBuild KitUI components, utilities, and documentation index for frontend integration\nThe skill covers both the read SDK (@jup-ag/lend-read) for querying data and the write SDK (@jup-ag/lend) for building transactions, with complete working examples.\nInstall:\nnpx skills add jup-ag/agent-skills --skill \"jupiter-lend\"\n\n​How Skills Work\nSkills follow the Agent Skills specification. Each skill is a SKILL.md file with structured frontmatter (name, description, tags) and Markdown content that AI agents consume as context.\nWhen you install a skill, it’s added to your project so your AI coding agent (Claude Code, Cursor, Codex, etc.) can reference it when writing code. The agent uses the skill’s guidance to choose the right API, construct correct requests, handle errors, and follow best practices.\n# Install all Jupiter skills (requires Node.js)\nnpx skills add jup-ag/agent-skills\n\n# Install a specific skill\nnpx skills add jup-ag/agent-skills --skill \"integrating-jupiter\"\n\n​skill.md\nJupiter’s documentation also exposes a machine-readable skill file at developers.jup.ag/docs/skill.md. This is a high-level navigator that points AI agents to the available skills and their capabilities, following the Mintlify skill.md specification.\n​Contributing\nThe skills repository is open source. You can contribute new skills, improve existing ones, or adapt them for your use case.\nWas this page helpful?","tokens":822,"squid":"spider-02","role":"Liquidity Spider","at":1791343180803,"hash":"2b29bf17494548722a9ab934356c991c49b8c968"}
{"url":"https://eips.ethereum.org/EIPS/eip-1559","domain":"eips.ethereum.org","title":"EIP-1559: Fee market change for ETH 1.0 chain","text":"🎉 Final\n\n Standards Track: Core\n\n EIP-1559: Fee market change for ETH 1.0 chain\n\n Authors\n Vitalik Buterin (@vbuterin), Eric Conner (@econoar), Rick Dudley (@AFDudley), Matthew Slipper (@mslipper), Ian Norden (@i-norden), Abdelhamid Bakhta (@abdelhamidbakhta)\n\n Created\n 2019-04-13\n\n Requires\n\n EIP-2718, \n\n EIP-2930\n\n Simple Summary\n\nA transaction pricing mechanism that includes fixed-per-block network fee that is burned and dynamically expands/contracts block sizes to deal with transient congestion.\n\n Abstract\n\nWe introduce a new EIP-2718 transaction type, with the format 0x02 || rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, amount, data, access_list, signature_y_parity, signature_r, signature_s]).\n\nThere is a base fee per gas in protocol, which can move up or down each block according to a formula which is a function of gas used in parent block and gas target (block gas limit divided by elasticity multiplier) of parent block.\nThe algorithm results in the base fee per gas increasing when blocks are above the gas target, and decreasing when blocks are below the gas target.\nThe base fee per gas is burned.\nTransactions specify the maximum fee per gas they are willing to give to miners to incentivize them to include their transaction (aka: priority fee).\nTransactions also specify the maximum fee per gas they are willing to pay total (aka: max fee), which covers both the priority fee and the block’s network fee per gas (aka: base fee).\nSenders will always pay the base fee per gas of the block their transaction was included in, and they will pay the priority fee per gas set in the transaction, as long as the combined amount of the two fees doesn’t exceed the transaction’s maximum fee per gas.\n\n Motivation\n\nEthereum historically priced transaction fees using a simple auction mechanism, where users send transactions with bids (“gasprices”) and miners choose transactions with the highest bids, and transactions that get included pay the bid that they specify. This leads to several large sources of inefficiency:\n\n Mismatch between volatility of transaction fee levels and social cost of transactions: bids to include transactions on mature public blockchains, that have enough usage so that blocks are full, tend to be extremely volatile. It’s absurd to suggest that the cost incurred by the network from accepting one more transaction into a block actually is 10x more when the cost per gas is 10 nanoeth compared to when the cost per gas is 1 nanoeth; in both cases, it’s a difference between 8 million gas and 8.02 million gas.\n Needless delays for users: because of the hard per-block gas limit coupled with natural volatility in transaction volume, transactions often wait for several blocks before getting included, but this is socially unproductive; no one significantly gains from the fact that there is no “slack” mechanism that allows one block to be bigger and the next block to be smaller to meet block-by-block differences in demand.\n Inefficiencies of first price auctions: The current approach, where transaction senders publish a transaction with a bid a maximum fee, miners choose the highest-paying transactions, and everyone pays what they bid. This is well-known in mechanism design literature to be highly inefficient, and so complex fee estimation algorithms are required. But even these algorithms often end up not working very well, leading to frequent fee overpayment.\n Instability of blockchains with no block reward: In the long run, blockchains where there is no issuance (including Bitcoin and Zcash) at present intend to switch to rewarding miners entirely through transaction fees. However, there are known issues with this that likely leads to a lot of instability, incentivizing mining “sister blocks” that steal transaction fees, opening up much stronger selfish mining attack vectors, and more. There is at present no good mitigation for this.\n\nThe proposal in this EIP is to start with a base fee amount which is adjusted up and down by the protocol based on how congested the network is. When the network exceeds the target per-block gas usage, the base fee increases slightly and when capacity is below the target, it decreases slightly. Because these base fee changes are constrained, the maximum difference in base fee from block to block is predictable. This then allows wallets to auto-set the gas fees for users in a highly reliable fashion. It is expected that most users will not have to manually adjust gas fees, even in periods of high network activity. For most users the base fee will be estimated by their wallet and a small priority fee, which compensates miners taking on orphan risk (e.g. 1 nanoeth), will be automatically set. Users can also manually set the transaction max fee to bound their total costs.\n\nAn important aspect of this fee system is that miners only get to keep the priority fee. The base fee is always burned (i.e. it is destroyed by the protocol). This ensures that only ETH can ever be used to pay for transactions on Ethereum, cementing the economic value of ETH within the Ethereum platform and reducing risks associated with miner extractable value (MEV). Additionally, this burn counterbalances Ethereum inflation while still giving the block reward and priority fee to miners. Finally, ensuring the miner of a block does not receive the base fee is important because it removes miner incentive to manipulate the fee in order to extract more fees from users.\n\n Specification\n\nBlock validity is defined in the reference implementation below.\nThe GASPRICE (0x3a) opcode MUST return the effective_gas_price as defined in the reference implementation below.\n\nAs of FORK_BLOCK_NUMBER, a new EIP-2718 transaction is introduced with TransactionType 2.\n\nThe intrinsic cost of the new transaction is inherited from EIP-2930, specifically 21000 + 16 * non-zero calldata bytes + 4 * zero calldata bytes + 1900 * access list storage key count + 2400 * access list address count.\n\nThe EIP-2718 TransactionPayload for this transaction is rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, amount, data, access_list, signature_y_parity, signature_r, signature_s]).\n\nThe signature_y_parity, signature_r, signature_s elements of this transaction represent a secp256k1 signature over keccak256(0x02 || rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, amount, data, access_list])).\n\nThe EIP-2718 ReceiptPayload for this transaction is rlp([status, cumulative_transaction_gas_used, logs_bloom, logs]).\n\nNote: // is integer division, round down.\nfrom typing import Union, Dict, Sequence, List, Tuple, Literal\nfrom dataclasses import dataclass, field\nfrom abc import ABC, abstractmethod\n\n@dataclass\nclass TransactionLegacy:\n signer_nonce: int = 0\n gas_price: int = 0\n gas_limit: int = 0\n destination: int = 0\n amount: int = 0\n payload: bytes = bytes()\n v: int = 0\n r: int = 0\n s: int = 0\n\n@dataclass\nclass Transaction2930Payload:\n chain_id: int = 0\n signer_nonce: int = 0\n gas_price: int = 0\n gas_limit: int = 0\n destination: int = 0\n amount: int = 0\n payload: bytes = bytes()\n access_list: List[Tuple[int, List[int]]] = field(default_factory=list)\n signature_y_parity: bool = False\n signature_r: int = 0\n signature_s: int = 0\n\n@dataclass\nclass Transaction2930Envelope:\n type: Literal[1] = 1\n payload: Transaction2930Payload = Transaction2930Payload()\n\n@dataclass\nclass Transaction1559Payload:\n chain_id: int = 0\n signer_nonce: int = 0\n max_priority_fee_per_gas: int = 0\n max_fee_per_gas: int = 0\n gas_limit: int = 0\n destination: int = 0\n amount: int = 0\n payload: bytes = bytes()\n access_list: List[Tuple[int, List[int]]] = field(default_factory=list)\n signature_y_parity: bool = False\n signature_r: int = 0\n signature_s: int = 0\n\n@dataclass\nclass Transaction1559Envelope:\n type: Literal[2] = 2\n payload: Transaction1559Payload = Transaction1559Payload()\n\nTransaction2718 = Union[Transaction1559Envelope, Transaction2930Envelope]\n\nTransaction = Union[TransactionLegacy, Transaction2718]\n\n@dataclass\nclass NormalizedTransaction:\n signer_address: int = 0\n signer_nonce: int = 0\n max_priority_fee_per_gas: int = 0\n max_fee_per_gas: int = 0\n gas_limit: int = 0\n destination: int = 0\n amount: int = 0\n payload: bytes = bytes()\n access_list: List[Tuple[int, List[int]]] = field(default_factory=list)\n\n@dataclass\nclass Block:\n parent_hash: int = 0\n uncle_hashes: Sequence[int] = field(default_factory=list)\n author: int = 0\n state_root: int = 0\n transaction_root: int = 0\n transaction_receipt_root: int = 0\n logs_bloom: int = 0\n difficulty: int = 0\n number: int = 0\n gas_limit: int = 0 # note the gas_limit is the gas_target * ELASTICITY_MULTIPLIER\n gas_used: int = 0\n timestamp: int = 0\n extra_data: bytes = bytes()\n proof_of_work: int = 0\n nonce: int = 0\n base_fee_per_gas: int = 0\n\n@dataclass\nclass Account:\n address: int = 0\n nonce: int = 0\n balance: int = 0\n storage_root: int = 0\n code_hash: int = 0\n\nINITIAL_BASE_FEE = 1000000000\nINITIAL_FORK_BLOCK_NUMBER = 10 # TBD\nBASE_FEE_MAX_CHANGE_DENOMINATOR = 8\nELASTICITY_MULTIPLIER = 2\n\nclass World(ABC):\n def validate_block(self, block: Block) -> None:\n parent_gas_target = self.parent(block).gas_limit // ELASTICITY_MULTIPLIER\n parent_gas_limit = self.parent(block).gas_limit\n\n # on the fork block, don't account for the ELASTICITY_MULTIPLIER to avoid\n # unduly halving the gas target.\n if INITIAL_FORK_BLOCK_NUMBER == block.number:\n parent_gas_target = self.parent(block).gas_limit\n parent_gas_limit = self.parent(block).gas_limit * ELASTICITY_MULTIPLIER \n\n parent_base_fee_per_gas = self.parent(block).base_fee_per_gas\n parent_gas_used = self.parent(block).gas_used\n transactions = self.transactions(block)\n\n # check if the block used too much gas\n assert block.gas_used <= block.gas_limit, 'invalid block: too much gas used'\n\n # check if the block changed the gas limit too much\n assert block.gas_limit < parent_gas_limit + parent_gas_limit // 1024, 'invalid block: gas limit increased too much'\n assert block.gas_limit > parent_gas_limit - parent_gas_limit // 1024, 'invalid block: gas limit decreased too much'\n\n # check if the gas limit is at least the minimum gas limit\n assert block.gas_limit >= 5000\n\n # check if the base fee is correct\n if INITIAL_FORK_BLOCK_NUMBER == block.number:\n expected_base_fee_per_gas = INITIAL_BASE_FEE\n elif parent_gas_used == parent_gas_target:\n expected_base_fee_per_gas = parent_base_fee_per_gas\n elif parent_gas_used > parent_gas_target:\n gas_used_delta = parent_gas_used - parent_gas_target\n base_fee_per_gas_delta = max(parent_base_fee_per_gas * gas_used_delta // parent_gas_target // BASE_FEE_MAX_CHANGE_DENOMINATOR, 1)\n expected_base_fee_per_gas = parent_base_fee_per_gas + base_fee_per_gas_delta\n else:\n gas_used_delta = parent_gas_target - parent_gas_used\n base_fee_per_gas_delta = parent_base_fee_per_gas * gas_used_delta // parent_gas_target // BASE_FEE_MAX_CHANGE_DENOMINATOR\n expected_base_fee_per_gas = parent_base_fee_per_gas - base_fee_per_gas_delta\n assert expected_base_fee_per_gas == block.base_fee_per_gas, 'invalid block: base fee not correct'\n\n # execute transactions and do gas accounting\n cumulative_transaction_gas_used = 0\n for unnormalized_transaction in transactions:\n # Note: this validates transaction signature and chain ID which must happen before we normalize below since normalized transactions don't include signature or chain ID\n signer_address = self.validate_and_recover_signer_address(unnormalized_transaction)\n transaction = self.normalize_transaction(unnormalized_transaction, signer_address)\n\n signer = self.account(signer_address)\n\n signer.balance -= transaction.amount\n assert signer.balance >= 0, 'invalid transaction: signer does not have enough ETH to cover attached value'\n # the signer must be able to afford the transaction\n assert signer.balance >= transaction.gas_limit * transaction.max_fee_per_gas\n\n # ensure that the user was willing to at least pay the base fee\n assert transaction.max_fee_per_gas >= block.base_fee_per_gas\n\n # Prevent impossibly large numbers\n assert transaction.max_fee_per_gas < 2**256\n # Prevent impossibly large numbers\n assert transaction.max_priority_fee_per_gas < 2**256\n # The total must be the larger of the two\n assert transaction.max_fee_per_gas >= transaction.max_priority_fee_per_gas\n\n # priority fee is capped because the base fee is filled first\n priority_fee_per_gas = min(transaction.max_priority_fee_per_gas, transaction.max_fee_per_gas - block.base_fee_per_gas)\n # signer pays both the priority fee and the base fee\n effective_gas_price = priority_fee_per_gas + block.base_fee_per_gas\n signer.balance -= transaction.gas_limit * effective_gas_price\n assert signer.balance >= 0, 'invalid transaction: signer does not have enough ETH to cover gas'\n gas_used = self.execute_transaction(transaction, effective_gas_price)\n gas_refund = transaction.gas_limit - gas_used\n cumulative_transaction_gas_used += gas_used\n # signer gets refunded for unused gas\n signer.balance += gas_refund * effective_gas_price\n # miner only receives the priority fee; note that the base fee is not given to anyone (it is burned)\n self.account(block.author).balance += gas_used * priority_fee_per_gas\n\n # check if the block spent too much gas transactions\n assert cumulative_transaction_gas_used == block.gas_used, 'invalid block: gas_used does not equal total gas used in all transactions'\n\n # TODO: verify account balances match block's account balances (via state root comparison)\n # TODO: validate the rest of the block\n\n def normalize_transaction(self, transaction: Transaction, signer_address: int) -> NormalizedTransaction:\n # legacy transactions\n if isinstance(transaction, TransactionLegacy):\n return NormalizedTransaction(\n signer_address = signer_address,\n signer_nonce = transaction.signer_nonce,\n gas_limit = transaction.gas_limit,\n max_priority_fee_per_gas = transaction.gas_price,\n max_fee_per_gas = transaction.gas_price,\n destination = transaction.destination,\n amount = transaction.amount,\n payload = transaction.payload,\n access_list = [],\n )\n # 2930 transactions\n elif isinstance(transaction, Transaction2930Envelope):\n return NormalizedTransaction(\n signer_address = signer_address,\n signer_nonce = transaction.payload.signer_nonce,\n gas_limit = transaction.payload.gas_limit,\n max_priority_fee_per_gas = transaction.payload.gas_price,\n max_fee_per_gas = transaction.payload.gas_price,\n destination = transaction.payload.destination,\n amount = transaction.payload.amount,\n payload = transaction.payload.payload,\n access_list = transaction.payload.access_list,\n )\n # 1559 transactions\n elif isinstance(transaction, Transaction1559Envelope):\n return NormalizedTransaction(\n signer_address = signer_address,\n signer_nonce = transaction.payload.signer_nonce,\n gas_limit = transaction.payload.gas_limit,\n max_priority_fee_per_gas = transaction.payload.max_priority_fee_per_gas,\n max_fee_per_gas = transaction.payload.max_fee_per_gas,\n destination = transaction.payload.destination,\n amount = transaction.payload.amount,\n payload = transaction.payload.payload,\n access_list = transaction.payload.access_list,\n )\n else:\n raise Exception('invalid transaction: unexpected number of items')\n\n @abstractmethod\n def parent(self, block: Block) -> Block: pass\n\n @abstractmethod\n def block_hash(self, block: Block) -> int: pass\n\n @abstractmethod\n def transactions(self, block: Block) -> Sequence[Transaction]: pass\n\n # effective_gas_price is the value returned by the GASPRICE (0x3a) opcode\n @abstractmethod\n def execute_transaction(self, transaction: NormalizedTransaction, effective_gas_price: int) -> int: pass\n\n @abstractmethod\n def validate_and_recover_signer_address(self, transaction: Transaction) -> int: pass\n\n @abstractmethod\n def account(self, address: int) -> Account: pass\n\n Backwards Compatibility\n\nLegacy Ethereum transactions will still work and be included in blocks, but they will not benefit directly from the new pricing system. This is due to the fact that upgrading from legacy transactions to new transactions results in the legacy transaction’s gas_price entirely being consumed either by the base_fee_per_gas and the priority_fee_per_gas.\n\n Block Hash Changing\n\nThe datastructure that is passed into keccak256 to calculate the block hash is changing, and all applications that are validating blocks are valid or using the block hash to verify block contents will need to be adapted to support the new datastructure (one additional item). If you only take the block header bytes and hash them you should still correctly get a hash, but if you construct a block header from its constituent elements you will need to add in the new one at the end.\n\n GASPRICE\n\nPrevious to this change, GASPRICE represented both the ETH paid by the signer per gas for a transaction as well as the ETH received by the miner per gas. As of this change, GASPRICE now only represents the amount of ETH paid by the signer per gas, and the amount a miner was paid for the transaction is no longer accessible directly in the EVM.\n\n Security Considerations\n\n Increased Max Block Size/Complexity\n\nThis EIP will increase the maximum block size, which could cause problems if miners are unable to process a block fast enough as it will force them to mine an empty block. Over time, the average block size should remain about the same as without this EIP, so this is only an issue for short term size bursts. It is possible that one or more clients may handle short term size bursts poorly and error (such as out of memory or similar) and client implementations should make sure their clients can appropriately handle individual blocks up to max size.\n\n Transaction Ordering\n\nWith most people not competing on priority fees and instead using a baseline fee to get included, transaction ordering now depends on individual client internal implementation details such as how they store the transactions in memory. It is recommended that transactions with the same priority fee be sorted by time the transaction was received to protect the network from spamming attacks where the attacker throws a bunch of transactions into the pending pool in order to ensure that at least one lands in a favorable position. Miners should still prefer higher gas premium transactions over those with a lower gas premium, purely from a selfish mining perspective.\n\n Miners Mining Empty Blocks\n\nIt is possible that miners will mine empty blocks until such time as the base fee is very low and then proceed to mine half full blocks and revert to sorting transactions by the priority fee. While this attack is possible, it is not a particularly stable equilibrium as long as mining is decentralized. Any defector from this strategy will be more profitable than a miner participating in the attack for as long as the attack continues (even after the base fee reached 0). Since any miner can anonymously defect from a cartel, and there is no way to prove that a particular miner defected, the only feasible way to execute this attack would be to control 50% or more of hashing power. If an attacker had exactly 50% of hashing power, they would make no Ether from priority fee while defectors would make double the Ether from priority fees. For an attacker to turn a profit, they need to have some amount over 50% hashing power, which means they can instead execute double spend attacks or simply ignore any other miners which is a far more profitable strategy.\n\nShould a miner attempt to execute this attack, we can simply increase the elasticity multiplier (currently 2x) which requires they have even more hashing power available before the attack can even be theoretically profitable against defectors.\n\n ETH Burn Precludes Fixed Supply\n\nBy burning the base fee, we can no longer guarantee a fixed Ether supply. This could result in economic instability as the long term supply of ETH will no longer be constant over time. While a valid concern, it is difficult to quantify how much of an impact this will have. If more is burned on base fee than is generated in mining rewards then ETH will be deflationary and if more is generated in mining rewards than is burned then ETH will be inflationary. Since we cannot control user demand for block space, we cannot assert at the moment whether ETH will end up inflationary or deflationary, so this change causes the core developers to lose some control over Ether’s long term quantity.\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), Eric Conner (@econoar), Rick Dudley (@AFDudley), Matthew Slipper (@mslipper), Ian Norden (@i-norden), Abdelhamid Bakhta (@abdelhamidbakhta), \"EIP-1559: Fee market change for ETH 1.0 chain,\" Ethereum Improvement Proposals, no. 1559, April 2019. Available: https://eips.ethereum.org/EIPS/eip-1559.","tokens":5221,"squid":"spider-05","role":"Spec Spider","at":1791343183570,"hash":"a5454b61ba9ec276ff33a187a9646d7b15a6528a"}
{"url":"https://www.metaplex.com/","domain":"metaplex.com","title":"The leading tokenization platform on Solana. | Metaplex","text":"The leading tokenization platform on Solana.Launch and trade onchain assets.Launch a TokenIssue an RWA$14B+cumulative trading volume$13M+primary sale value9project token sales$470M+combined FDV1B+transactions powered$10B+transaction value$14B+cumulative trading volume$13M+primary sale value9project token sales$470M+combined FDV1B+transactions powered$10B+transaction value$14B+cumulative trading volume$13M+primary sale value9project token sales$470M+combined FDV1B+transactions powered$10B+transaction value$14B+cumulative trading volume$13M+primary sale value9project token sales$470M+combined FDV1B+transactions powered$10B+transaction valueWhy MetaplexMetaplex is where assets on Solana move from launch to active markets, with issuance and live trading all in one platform.Two sides, one market.For issuers1Run your token sale with configurable tools for a controlled, fair launch.Learn more2Create all asset types on Solana including tokens and NFTs with Metaplex protocols.Learn more3Issue tokenized securities or RWAs using Metaplex protocolsLearn moreFor Investors & TradersDiscover live token sales and trade different asset types with Metaplex.Start tradingInfrastructure the ecosystem already runs on.Access the largest network in the ecosystem, with provenance and settlement the ecosystem already trusts.Proven scale1B+Transactions poweredSolana$13B+Transaction volumeMarkets1B+Digital assets createdIssuanceDEX partnerToken sale liquidity auto-migrates from Metaplex to Raydium CPMM pools for liquidity depth and healthy trading. Spotlight customers are eligible to use CLMM pools and configure more advanced liquidity strategies.Raydium - DEX partner1B+Transactions poweredElite Partners","tokens":426,"squid":"dotcat","role":"Tooling Spider","at":1791343191099,"hash":"239f51f04a29ad88a8f81779f7687aa7fefbd0ae"}
{"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":"spider-05","role":"Spec Spider","at":1791343194749,"hash":"a1cf0eac1346c832a1e2f40ad5dbf8f36ecd3e87"}
{"url":"https://eips.ethereum.org/EIPS/eip-1679","domain":"eips.ethereum.org","title":"EIP-1679: Hardfork Meta: Istanbul","text":"🎉 Final\n\n Meta\n\n EIP-1679: Hardfork Meta: Istanbul\n\n Authors\n Alex Beregszaszi (@axic), Afri Schoedon (@5chdn)\n\n Created\n 2019-01-04\n\n Requires\n\n EIP-152, \n\n EIP-1108, \n\n EIP-1344, \n\n EIP-1716, \n\n EIP-1884, \n\n EIP-2028, \n\n EIP-2200\n\n Abstract\n\nThis meta-EIP specifies the changes included in the Ethereum hardfork named Istanbul.\n\n Specification\n\n Codename: Istanbul\n\n Activation\n\n Block >= 9,069,000 on the Ethereum Mainnet\n Block >= 6,485,846 on the Ropsten testnet\n Block >= 14,111,141 on the Kovan testnet\n Block >= 5,435,345 on the Rinkeby testnet\n Block >= 1,561,651 on the Görli testnet\n\n Included EIPs\n\n EIP-152: Add Blake2 compression function F precompile\n EIP-1108: Reduce alt_bn128 precompile gas costs\n EIP-1344: Add ChainID opcode\n EIP-1884: Repricing for trie-size-dependent opcodes\n EIP-2028: Calldata gas cost reduction\n EIP-2200: Rebalance net-metered SSTORE gas cost with consideration of SLOAD gas cost change\n\n References\n\n Included EIPs were finalized in All Core Devs Call #68\n https://medium.com/ethereum-cat-herders/istanbul-testnets-are-coming-53973bcea7df\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), Afri Schoedon (@5chdn), \"EIP-1679: Hardfork Meta: Istanbul,\" Ethereum Improvement Proposals, no. 1679, January 2019. Available: https://eips.ethereum.org/EIPS/eip-1679.","tokens":345,"squid":"spider-05","role":"Spec Spider","at":1791343216431,"hash":"b0b9fc94d9eff4f7c0c1653ccc8d56b2de267363"}
{"url":"https://developers.jup.ag/docs/ai/mcp","domain":"developers.jup.ag","title":"Documentation MCP - Jupiter Developers","text":"Jupiter supports the Model Context Protocol (MCP) through Mintlify’s native integration. This lets AI tools search and query Jupiter’s documentation and API specifications directly from your editor.\n​What is MCP?\nMCP is an open protocol that connects AI assistants to external data sources and tools. With Jupiter’s MCP server, your AI editor can:\n\nSearch documentation: find relevant API endpoints, guides, and references\nRead OpenAPI specs: access full request/response schemas\nUnderstand API contracts: look up parameters, response fields, and error codes\n\nThis is a read-only documentation server. It helps your AI assistant understand Jupiter’s APIs, but does not execute API calls. For trading via AI tools, see Jupiter CLI.\n​Mintlify Native MCP\nEvery Mintlify documentation site includes a built-in MCP server. Jupiter’s is available at:\nhttps://developers.jup.ag/docs/mcp\n\nThis server exposes all Jupiter documentation and OpenAPI specifications through the MCP protocol, with no additional setup required.\n​What You Get\nOnce connected, your AI assistant can search and read:\nResourceDescriptionDocumentation pagesAll guides, tutorials, and reference docsOpenAPI specificationsComplete API schemas for Swap, Tokens, Price, and moreError referencesCommon error codes and troubleshooting guides\nCombine MCP with llms.txt for the best results: use MCP for in-editor queries and llms.txt for batch processing or RAG pipelines.\n​Setup\n Claude Code Claude Cursor WindsurfHow to enable Jupiter MCP in Claude Code:\nOpen your terminal.\nAdd Jupiter’s MCP server by running:\nclaude mcp add --scope user --transport http jupiter https://developers.jup.ag/docs/mcp\n\nLaunch Claude Code and start chatting with Jupiter.\nOr add to your project’s .mcp.json:{\n \"mcpServers\": {\n \"jupiter\": {\n \"url\": \"https://developers.jup.ag/docs/mcp\"\n }\n }\n}\nVerify with:claude mcp list\nSetup Jupiter MCP in Claude:\nGo to Connectors in your Claude settings.\nSelect Add custom connector.\nSet the name to Jupiter and the URL to https://developers.jup.ag/docs/mcp.\nWhen chatting, click the attachments button (plus icon) and select the Jupiter connector.\nSetup Jupiter MCP in Cursor:\nOpen the command palette with Cmd + Shift + P (or Ctrl + Shift + P on Windows).\nSearch for Open MCP settings.\nAdd the following to your mcp.json file:\n{\n \"mcpServers\": {\n \"jupiter\": {\n \"url\": \"https://developers.jup.ag/docs/mcp\"\n }\n }\n}\n\nSave and reload Cursor.\nUsing Jupiter MCP in Windsurf:\nOpen the command palette with Cmd + Shift + P (or Ctrl + Shift + P on Windows).\nSearch for Windsurf: Configure MCP Servers.\nAdd the following to your mcp_config.json file:\n{\n \"mcpServers\": {\n \"jupiter\": {\n \"serverUrl\": \"https://developers.jup.ag/docs/mcp\"\n }\n }\n}\n\nSave and restart Windsurf.\n\n​Other MCP-Compatible Tools\nAny tool that supports the MCP protocol can connect to https://developers.jup.ag/docs/mcp using HTTP transport.Was this page helpful?","tokens":726,"squid":"spider-02","role":"Liquidity Spider","at":1791343217883,"hash":"7174121d8f983891cdb05c670d7e6dc8db3327ac"}
{"url":"https://eips.ethereum.org/EIPS/eip-2028","domain":"eips.ethereum.org","title":"EIP-2028: Transaction data gas cost reduction","text":"🎉 Final\n\n Standards Track: Core\n\n EIP-2028: Transaction data gas cost reduction\n\n Authors\n Alexey Akhunov (@AlexeyAkhunov), Eli Ben Sasson <eli@starkware.co>, Tom Brand <tom@starkware.co>, Louis Guthmann <louis@starkware.co>, Avihu Levy <avihu@starkware.co>\n\n Created\n 2019-05-03\n\n Simple Summary\n\nWe propose to reduce the gas cost of Calldata (GTXDATANONZERO) from its current value of 68 gas per byte to 16 gas per byte, to be backed by mathematical modeling and empirical estimates. The mathematical model is the one used in the works of Sompolinsky and Zohar [1] and Pass, Seeman and Shelat [2], which relates network security to network delay. We shall (1) evaluate the theoretical impact of lower Calldata gas cost on network delay using this model, (2) validate the model empirically, and (3) base the proposed gas cost on our findings.\n\n Motivation\n\nThere are a couple of main benefits to accepting this proposal and lowering gas cost of Calldata\nOn-Chain Scalability: Generally speaking, higher bandwidth of Calldata improves scalability, as more data can fit within a single block.\n\n Layer two scalability: Layer two scaling solutions can improve scalability by moving storage and computation off-chain, but often introduce data transmission instead.\n\n Proof systems such as STARKs and SNARKs use a single proof that attests to the computational integrity of a large computation, say, one that processes a large batch of transactions.\n Some solutions use fraud proofs which requires a transmission of merkle proofs.\n Moreover, one optional data availability solution to layer two is to place data on the main chain, via Calldata.\n\n Stateless clients: The same model will be used to determine the price of the state access for the stateless client regime, which will be proposed in the State Rent (from version 4). There, it is expected that the gas cost of state accessing operation will increase roughly proportional to the extra bandwidth required to transmit the “block proofs” as well as extra processing required to verify those block proofs.\n\n Specification\n\nThe gas per non-zero byte is reduced from 68 to 16. Gas cost of zero bytes is unchanged.\n\n Rationale\n\nRoughly speaking, reducing the gas cost of Calldata leads to potentially larger blocks, which increases the network delay associated with data transmission over the network. This is only part of the full network delay, other factors are block processing time (and storage access, as part of it). Increasing network delay affects security by lowering the cost of attacking the network, because at any given point in time fewer nodes are updated on the latest state of the blockchain.\n\nYonatan Sompolinsky and Aviv Zohar suggested in [1] an elegant model to relate network delay to network security, and this model is also used in the work of Rafael Pass, Lior Seeman and Abhi Shelat [2]. We briefly explain this model below, because we shall study it theoretically and validate it by empirical measurements to reach the suggested lower gas cost for Calldata.\n\nThe model uses the following natural parameters:\n\n lambda denotes the block creation rate [1/s]: We treat the process of finding a PoW\nsolution as a poisson process with rate lambda.\n beta - chain growth rate [1/s]: the rate at which new blocks are added to\nthe heaviest chain.\n D - block delay [s]: The time that elapses between the mining of a new block and its acceptance by all the miners (all miners switched to mining on top of that block).\n\n Beta Lower Bound\n\nNotice that lambda => beta, because not all blocks that are found will enter the main chain (as is the case with uncles). In [1] it was shown that for a blockchain using the longest chain rule, one may bound beta from below by lambda/ (1+ D * lambda). This lower bound holds in the extremal case where the topology of the network is a clique in which the delay between each pair of nodes is D, the maximal possible delay. Recording both the lower and upper bounds on beta we get\n\n_lambda_ >= _beta_ >= _lambda_ / (1 + D * _lambda_) (*)\n\nNotice, as a sanity check, that when there is no delay (D=0) then beta equals lambda, as expected.\n\n Security of the network\n\nAn attacker attempting to reorganize the main chain needs to generate blocks at a rate that is greater than beta.\nFixing the difficulty level of the PoW puzzle, the total hash rate in the system is correlated to lambda. Thus, beta / lambda is defined as the efficiency of the system, as it measures the fraction of total hash power that is used to generate the main chain of the network.\n\nRearranging (*) gives the following lower bound on efficiency in terms of delay:\n\n_beta_ / _lambda_ >= 1 / (1 + D * _lambda_) (**)\n\n The delay parameter D\n\nThe network delay depends on the location of the mining node within the network and on the current network topology (which changes dynamically), and consequently is somewhat difficult to measure directly.\nPreviously, Christian Decker and Roger Wattenhofer [3] showed that propagation time scales with blocksize, and Vitalik Buterin showed that uncle rate, which is tightly related to efficiency (**) measure, also scales with block size [4].\n\nHowever, the delay function can be decomposed into two parts D = D_t + D_p, where D_t is the delay caused by the transmission of the block and D_p is the delay caused by the processing of the block by the node. Our model and tests will examine the effect of Calldata on each of D_t and D_p, postulating that their effect is different. This may be particularly relevant for Layer 2 Scalability and for Stateless Clients (Rationales 2, 3 above) because most of the Calldata associated with these goals are Merkle authentication paths that have a large D_t component but relatively small D_p values.\n\n Test Cases\n\nTo suggest the gas cost of calldata we shall conduct two types of tests:\n\n Network tests, conducted on the Ethereum mainnet, used to estimate the effect on increasing block size on D_p and D_t, on the overall network delay D and the efficiency ratio (**), as well as delays between different mining pools. Those tests will include regression tests on existing data, and stress tests to introduce extreme scenarios.\n Local tests, conducted on a single node and measuring the processing time as a function of Calldata amount and general computation limits.\n\n Reference Implementation\n\nParity\nGeth\n\n References\n\n[1] Yonatan Sompolinsky, Aviv Zohar: Secure High-Rate Transaction Processing in Bitcoin. Financial Cryptography 2015: 507-527\n\n[2] Rafael Pass, Lior Seeman, Abhi Shelat: Analysis of the Blockchain Protocol in Asynchronous Networks, ePrint report 2016/454\n\n[3] Christian Decker, Roger Wattenhofer: Information propagation in the Bitcoin network. P2P 2013: 1-10\n\n[4] Vitalik Buterin: Uncle Rate and Transaction Fee Analysis\n\n Copyright\n\nCopyright and related rights waived via CC0.\n\n Citation\n Please cite this document as:\n\n Alexey Akhunov (@AlexeyAkhunov), Eli Ben Sasson <eli@starkware.co>, Tom Brand <tom@starkware.co>, Louis Guthmann <louis@starkware.co>, Avihu Levy <avihu@starkware.co>, \"EIP-2028: Transaction data gas cost reduction,\" Ethereum Improvement Proposals, no. 2028, May 2019. Available: https://eips.ethereum.org/EIPS/eip-2028.","tokens":1805,"squid":"spider-05","role":"Spec Spider","at":1791343226539,"hash":"52b95ed2415657cd28a343cf290cc78cf84cde55"}
{"url":"https://developers.jup.ag/docs/ai/trading-mcp","domain":"developers.jup.ag","title":"Jupiter Trading MCP - Jupiter Developers","text":"The Jupiter Trading MCP is a hosted Model Context Protocol server that lets AI agents trade and run DeFi operations on Jupiter. Connect any MCP client to https://mcp.jup.ag and your agent can swap tokens, place orders, lend, and read on-chain positions. An API key is optional and only raises your rate limit.\nThis server executes operations. For an AI assistant that searches and reads Jupiter’s documentation instead, see the read-only Documentation MCP.\n​What You Can Do\nThe server exposes 75 tools across 11 domains. Your MCP client discovers them automatically once connected.\nDomainWhat it doesSwapGet a quote and a ready-to-sign transaction, then execute the swap with managed landing.TokensSearch tokens by name, symbol, or mint, list by tag, category, or recent listings, and run token verification.PriceFetch real-time USD prices, liquidity, and 24h change for one or more tokens.TriggerCreate, update, cancel, and list limit orders that execute when a token hits a target price.RecurringSet up and manage dollar-cost averaging (DCA) orders that buy at regular intervals, built on the Trigger API’s DCA flow.LendDeposit into and withdraw from Jupiter Lend to earn yield, and read your lending positions.PredictionBrowse prediction market events, place and close bets, claim payouts, and read scores and forecasts.PortfolioRead a wallet’s positions across Solana protocols and its staked JUP.SendSend tokens via Jupiter Send invites, claw back unclaimed invites, and list invite history.StudioCreate Jupiter Studio token-launch (Dynamic Bonding Curve) pools and claim creator fees.TransactionLand any signed Solana transaction on-chain through Jupiter’s Beam landing infrastructure.\n​API Key (Optional)\nThe server works without an API key at a lower rate limit, which is enough to try it out. For higher rate limits, create a key in the Developer Platform and pass it as a Bearer token (shown in the setup below). The server forwards the key to Jupiter’s API on your behalf and never stores it, so you use your own rate limits and permissions.\n​Connect Your Client\nAdd the server to your MCP client’s configuration. To use a higher rate limit, pass your Jupiter API key as a Bearer token in the Authorization header and replace YOUR_JUPITER_API_KEY with your key. To start without a key, drop the headers block entirely.\n Claude Desktop Claude Code Cursor WindsurfClaude Desktop adds remote MCP servers as custom connectors, not through claude_desktop_config.json (the config file only supports local stdio servers and ignores remote entries).\nOpen Settings > Connectors.\nSelect Add custom connector.\nEnter a name (for example Jupiter) and the URL https://mcp.jup.ag, then confirm.\nThe connector flow does not take an Authorization header, so Claude Desktop connects keyless at the lower rate limit.Add the server from your terminal:claude mcp add --transport http jupiter https://mcp.jup.ag --header \"Authorization: Bearer YOUR_JUPITER_API_KEY\"\nOr add it manually to .mcp.json in your project root (use ~/.claude.json to make it available in every project):{\n \"mcpServers\": {\n \"jupiter\": {\n \"type\": \"http\",\n \"url\": \"https://mcp.jup.ag\",\n \"headers\": {\n \"Authorization\": \"Bearer YOUR_JUPITER_API_KEY\"\n }\n }\n }\n}\nVerify with:claude mcp list\nOpen Settings > MCP and add a new server, or edit .cursor/mcp.json:{\n \"mcpServers\": {\n \"jupiter\": {\n \"url\": \"https://mcp.jup.ag\",\n \"headers\": {\n \"Authorization\": \"Bearer YOUR_JUPITER_API_KEY\"\n }\n }\n }\n}\nSave and reload Cursor.Open Settings > MCP and add a new server, or edit ~/.codeium/windsurf/mcp_config.json:{\n \"mcpServers\": {\n \"jupiter\": {\n \"serverUrl\": \"https://mcp.jup.ag\",\n \"headers\": {\n \"Authorization\": \"Bearer YOUR_JUPITER_API_KEY\"\n }\n }\n }\n}\nSave and restart Windsurf.\n​Other MCP-Compatible Tools\nAny tool that supports the MCP protocol can connect to https://mcp.jup.ag over HTTP transport. Add a Jupiter API key in the Authorization: Bearer header for a higher rate limit, or connect without one.\n​Authentication\nAuthentication is optional and stateless. When you send a key, each request carries it as a Bearer token and the server stores nothing.\n\nNo key: requests work at a lower rate limit. Omit the Authorization header.\nWith a key: pass Authorization: Bearer YOUR_JUPITER_API_KEY for a higher rate limit.\nA 401 Unauthorized response means the key you sent is invalid, not that a key is missing.\nThe MCP endpoint is https://mcp.jup.ag. A separate GET /health endpoint needs no auth.\n\n​Example Prompts\nOnce connected, ask your AI assistant in plain language. Each prompt maps to one or more tools.\nPromptTools used”What is the current price of SOL and JUP?”price_get”Swap 10 USDC for SOL”swap_get_order, then swap_execute_order”Place a limit order to sell 50 USDC for SOL at a target price.”trigger_get_challenge → trigger_verify_challenge → trigger_build_deposit → trigger_create_order (plus trigger_register_vault the first time a wallet uses Trigger)“DCA 100 USDC into SOL daily for 10 days.”trigger_get_challenge → trigger_verify_challenge → recurring_build_order → recurring_execute (plus trigger_register_vault the first time a wallet uses Trigger)“What tokens can I lend on Jupiter and what APY do they offer?”lend_list_tokens”Are there any prediction markets about Bitcoin?”prediction_search_events\nTrading prompts that move funds return an unsigned transaction. Your client signs it with your wallet and submits it, so you stay in control of every transaction.\nIf a tool call returns 401 Unauthorized, the Jupiter API key you passed is invalid. Remove the Authorization header to run keyless at the lower rate limit, or replace it with a valid key from the Developer Platform.\n​Resources\nWas this page helpful?","tokens":1421,"squid":"spider-02","role":"Liquidity Spider","at":1791343230667,"hash":"55cd133e3376d3f38d92bd19ef7cebf884f9ba1c"}
{"url":"https://eips.ethereum.org/EIPS/eip-1716","domain":"eips.ethereum.org","title":"EIP-1716: Hardfork Meta: Petersburg","text":"🎉 Final\n\n Meta\n\n EIP-1716: Hardfork Meta: Petersburg\n\n Authors\n Afri Schoedon (@5chdn), Marius van der Wijden (@MariusVanDerWijden)\n\n Created\n 2019-01-21\n\n Requires\n\n EIP-1013, \n\n EIP-1283\n\n Abstract\n\nThis meta-EIP specifies the changes included in the Ethereum hardfork that removes EIP-1283 from Constantinople.\n\n Specification\n\n Codename: Petersburg\n Aliases: St. Petersfork, Peter’s Fork, Constantinople Fix\n Activation:\n\n Block >= 7_280_000 on the Ethereum Mainnet\n Block >= 4_939_394 on the Ropsten testnet\n Block >= 10_255_201 on the Kovan testnet\n Block >= 4_321_234 on the Rinkeby testnet\n Block >= 0 on the Görli testnet\n\n Removed EIPs:\n\n EIP-1283: Net gas metering for SSTORE without dirty maps\n\nIf Petersburg and Constantinople are applied at the same block, Petersburg takes precedence: with the net effect of EIP-1283 being disabled.\n\nIf Petersburg is defined with an earlier block number than Constantinople, then there is no immediate effect from the Petersburg fork. However, when Constantinople is later activated, EIP-1283 should be disabled.\n\n References\n\n The list above includes the EIPs that had to be removed from Constantinople due to a potential reentrancy attack vector. Removing this was agreed upon at the All-Core-Devs call #53 in January 2019.\n https://blog.ethereum.org/2019/02/22/ethereum-constantinople-st-petersburg-upgrade-announcement/\n\n Copyright\n\nCopyright and related rights waived via CC0.\n\n Citation\n Please cite this document as:\n\n Afri Schoedon (@5chdn), Marius van der Wijden (@MariusVanDerWijden), \"EIP-1716: Hardfork Meta: Petersburg,\" Ethereum Improvement Proposals, no. 1716, January 2019. Available: https://eips.ethereum.org/EIPS/eip-1716.","tokens":423,"squid":"spider-05","role":"Spec Spider","at":1791343237066,"hash":"1ec5d131a9433fc4a0ba638bb84f8bf03414a3ac"}
{"url":"https://developers.jup.ag/docs/trigger/dca","domain":"developers.jup.ag","title":"Dollar-Cost Averaging (DCA) - Jupiter Developers","text":"A DCA order splits one deposit into a series of swaps that run automatically on a fixed schedule, so you buy a little at a time instead of all at once. You deposit your full budget, choose how many rounds and how often, and Jupiter’s keeper executes each round and sends the output to your wallet.\nDCA is part of the Trigger API. It shares the same vault, authentication, and deposit flow as price orders, so if you have already integrated those, the only new endpoint is POST /trigger/v2/orders/dca. This page covers creating an order; see Track a DCA Order to monitor it and Cancel a DCA Order to withdraw the unfilled remainder.\n​How it works\nEvery wallet has one Privy-managed vault. You fund a DCA order by depositing into that vault, then the keeper draws from it each round:\n\nYou manage two moments: creating the order (deposit + schedule) and optionally cancelling it (withdraw the unfilled remainder). Everything in between, the per-round swaps, is handled by the keeper.\n​Order types\nSet orderType on create to choose how rounds execute.\nTypeBehaviourtime_based (default)Executes every round on schedule. If a round cannot execute within its retry window, it is rescheduled to the next interval. The completion time is predictable.price_conditionalExecutes a round only while the trigger mint’s USD price is inside [minPriceUsd, maxPriceUsd]. While the price is out of band, the round waits and is rescheduled to the next interval.\nBoth types retry a stuck round within a window of min(max(30, intervalSeconds / 2), 7200) seconds before rescheduling it.\nThe deposit’s orderType is dca (with no orderSubType). That is a different field from the create call’s orderType (time_based or price_conditional) above, which selects the DCA behaviour.\n​Quick start\nCreating a DCA order is four calls: authenticate, get your vault, craft and sign the deposit, then submit the order.\nPrerequisitesInstall the signing dependencies:npm install @solana/web3.js bs58 tweetnacl\nYou also need a Jupiter API key and a funded wallet. The example below loads the wallet from BS58_PRIVATE_KEY and the key from JUPITER_API_KEY in your .env. For the browser-wallet (signMessage) version of authentication, see Authentication.Never commit private keys. Use environment variables for testing and a proper key-management solution in production.\nimport { Keypair, VersionedTransaction } from \"@solana/web3.js\";\nimport bs58 from \"bs58\";\nimport nacl from \"tweetnacl\";\n\nconst BASE = \"https://api.jup.ag/trigger/v2\";\nconst API_KEY = process.env.JUPITER_API_KEY!;\nconst USDC = \"EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v\";\nconst SOL = \"So11111111111111111111111111111111111111112\";\n\nconst wallet = Keypair.fromSecretKey(bs58.decode(process.env.BS58_PRIVATE_KEY!));\nconst owner = wallet.publicKey.toBase58();\n\n// 1. Authenticate: sign the challenge to get a 24h JWT (see /trigger/authentication)\nasync function authenticate(): Promise<string> {\n const { challenge } = await fetch(`${BASE}/auth/challenge`, {\n method: \"POST\",\n headers: { \"Content-Type\": \"application/json\", \"x-api-key\": API_KEY },\n body: JSON.stringify({ walletPubkey: owner, type: \"message\" }),\n }).then((r) => r.json());\n\n const signature = nacl.sign.detached(new TextEncoder().encode(challenge), wallet.secretKey);\n const { token } = await fetch(`${BASE}/auth/verify`, {\n method: \"POST\",\n headers: { \"Content-Type\": \"application/json\", \"x-api-key\": API_KEY },\n body: JSON.stringify({ type: \"message\", walletPubkey: owner, signature: bs58.encode(signature) }),\n }).then((r) => r.json());\n return token;\n}\n\nasync function createDca() {\n const token = await authenticate();\n const headers = { \"Content-Type\": \"application/json\", \"x-api-key\": API_KEY, Authorization: `Bearer ${token}` };\n\n // 2. Get your vault, registering one on first use\n let vault = await fetch(`${BASE}/vault`, { headers });\n if (!vault.ok) vault = await fetch(`${BASE}/vault/register`, { headers });\n if (!vault.ok) throw new Error(`vault failed: ${vault.status}`);\n\n // 3. Craft the deposit (orderType: \"dca\", no orderSubType)\n const deposit = await fetch(`${BASE}/deposit/craft`, {\n method: \"POST\",\n headers,\n body: JSON.stringify({ inputMint: USDC, outputMint: SOL, userAddress: owner, amount: \"20000000\", orderType: \"dca\" }),\n }).then((r) => r.json());\n if (!deposit.requestId) throw new Error(`craft failed: ${JSON.stringify(deposit)}`);\n\n // 4. Sign the deposit and submit the order (note: no trailing slash on /orders/dca)\n const tx = VersionedTransaction.deserialize(Buffer.from(deposit.transaction, \"base64\"));\n tx.sign([wallet]);\n\n const order = await fetch(`${BASE}/orders/dca`, {\n method: \"POST\",\n headers,\n body: JSON.stringify({\n depositRequestId: deposit.requestId,\n depositSignedTx: Buffer.from(tx.serialize()).toString(\"base64\"),\n userPubkey: owner,\n inputMint: USDC,\n outputMint: SOL,\n inputAmount: \"20000000\", // 20 USDC total\n orderCount: 2, // 2 rounds of 10 USDC\n intervalSeconds: 3600, // one round per hour\n orderType: \"time_based\",\n }),\n }).then((r) => r.json());\n if (!order.id) throw new Error(`create failed: ${JSON.stringify(order)}`);\n\n console.log(`DCA order ${order.id}, deposit tx https://solscan.io/tx/${order.txSignature}`);\n return order.id as string;\n}\n\ncreateDca().catch(console.error);\n\nThe deposit lands on-chain during the create call, so a 200 means the order is live. The response is { id, txSignature }, where txSignature is the on-chain deposit signature:\n{\n \"id\": \"019f02b5-0400-72cc-8943-007c4310a3de\",\n \"txSignature\": \"4R18eTrkDvmZFPq87pznBPpVCpk1G2FQapWVks4ELLNYxAQZdwoDaxnnAHN2ZvBFrRvbnJSAPTnhutgj8ZzLFwgV\"\n}\n\nThe vault address is resolved from your JWT, so you never pass it. The deposit requestId is single-use and is consumed by the create call as depositRequestId. Once the order is live, track it.\n​Request parameters\nThe body of POST /trigger/v2/orders/dca:\nParameterTypeRequiredDescriptiondepositRequestIdstringYesThe requestId returned by /deposit/craft.depositSignedTxstringYesBase64-encoded signed deposit transaction.userPubkeystringYesYour wallet public key. Must match the JWT.inputMintstringYesMint of the token to sell. Native SOL is supported (wrapped automatically). Tokens with transfer-fee or transfer-hook extensions are rejected at the deposit step unless whitelisted.outputMintstringYesMint of the token to buy.inputAmountstringYesTotal amount to DCA, in the input token’s smallest unit. Any remainder from uneven division is added to the last round.orderCountnumberYesNumber of rounds. Minimum 2, no fixed maximum (the current per-round $10 minimum effectively caps it at your deposit in USD ÷ 10).intervalSecondsnumberYesSeconds between rounds, from 60 (1 minute) to 31,536,000 (1 year).orderTypestringNotime_based (default) or price_conditional.minPriceUsdnumberNoLower price bound. Price-conditional only.maxPriceUsdnumberNoUpper price bound. Price-conditional only.triggerMintstringCond.Mint whose USD price is checked against the band. Required for price_conditional. Must be the input or output mint, and cannot be the stablecoin leg (use the volatile leg, usually outputMint). Ignored for time_based.beginFillAtstringNoISO-8601 time to start the first round. Defaults to now, up to 30 days out.jlEnabledbooleanNoEarn While You Wait: hold idle capital as a yield-bearing Jupiter Lend token between rounds. time_based and supported-stablecoin input only. Defaults false, and requires a deposit crafted with jlMint. See Earn While You Wait.jlMintstringCond.Jupiter Lend earn token for your input stablecoin (from GET /lend/v1/earn/tokens). Required when jlEnabled is true, and must match the jlMint passed to /deposit/craft.\n​Validation\nThe API validates the request before any funds move, so a rejected order costs nothing.\nRuleError on failureEach round worth ≥ $10, currently (the minimum is per-environment; inputAmount ÷ orderCount, $0.20 tolerance)Each order must be at least 10 USD (current value: X USD)orderCount ≥ 2Too small: expected number to be >=2intervalSeconds between 60 and 31,536,000Too small/big: expected number to be >=60 / <=31536000inputMint ≠ outputMintInput mint and output mint cannot be the samebeginFillAt is in the futureBegin fill time must be in the futurebeginFillAt is ≤ 30 days outBegin fill time cannot be more than 30 days in the futureAt most 10 active orders per walletMaximum of 10 active DCA orders allowed per user\nActive orders are those in depositing, active, executing, or withdrawing. Cancel orders you no longer need to free up slots.\n​Price-conditional orders\nTo accumulate only within a target price range, set orderType: \"price_conditional\", at least one of minPriceUsd / maxPriceUsd, and a triggerMint:\n{\n // ...deposit and mints as above...\n inputAmount: \"40000000\", // 40 USDC\n orderCount: 4,\n intervalSeconds: 86400, // daily\n orderType: \"price_conditional\",\n triggerMint: SOL, // check SOL's USD price\n minPriceUsd: 120, // only buy while SOL is between\n maxPriceUsd: 180, // $120 and $180\n}\n\ntriggerMint must be the input or output mint, and cannot be the stablecoin side of the pair. In practice that is the volatile leg (here, SOL). A stablecoin trigger such as USDC is rejected with 400 \"Trigger mint is not supported\", and a pair where both legs are stable returns 400 \"Mint pair is not supported\". Omitting the bounds or the trigger returns a 400 identifying the missing field, and a time_based order that sets price bounds is rejected.\n​Earn While You Wait\nSet jlEnabled: true to earn yield on the part of your budget that has not been swapped yet. While the stablecoin sits in the vault between rounds, it is supplied to Jupiter Lend and earns yield until each round draws from it. The yield accrues to you and is returned when the order finishes or is cancelled.\nEarn While You Wait has two requirements:\n\nThe order must be time_based. A price_conditional order with jlEnabled: true returns 400 \"jlEnabled is only supported for time_based orders\".\nThe input mint must be a supported stablecoin. Any other input returns 400 \"jlEnabled is not supported for this input mint\".\n\nSupported stablecoins and their Jupiter Lend tokens:\nInput stablecoinjlMint (Jupiter Lend earn token)USDC (EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v)9BEcn9aPEmhSPbPQeFGjidRiEKki46fVQDyPpSQXPA2D (jlUSDC)USDT (Es9vMFrzaCERmJfrF4H2FYD4KCoNkY11McCe8BenwNYB)Cmn4v2wipYV41dkakDvCgFJpxhtaaKt11NyWV8pjSE8A (jlUSDT)JupUSD (JuprjznTrTSp2UFa3ZBUFgwdAmtZCq4MQCwysN55USD)7GxATsNMnaC88vdwd2t3mwrFuQwwGvmYPrUQ4D6FotXk (jlJUPUSD)\nYou can also resolve the pairing at runtime: GET https://api.jup.ag/lend/v1/earn/tokens, match assetAddress to your inputMint, and use that token’s address as jlMint.\nTo create an Earn While You Wait order:\n\nCraft the deposit with jlMint (POST /trigger/v2/deposit/craft with orderType: \"dca\" and jlMint). The response returns jlTokenAccount instead of inputTokenAccount. A jlMint that is not the Lend token for your input stablecoin returns 400 \"jlMint does not match the JL token for this input mint\".\nCreate the order with jlEnabled: true and the same jlMint on POST /trigger/v2/orders/dca.\n\nThe create response is unchanged ({ id, txSignature }). When you track the order, it carries jlEnabled: true and jlYieldUsd (yield accrued so far in USD, or null while a required price is uncached). Cancelling unwinds the Lend position and returns the remaining stablecoin, plus the accrued yield, to your wallet.\n​Errors\nBeyond the create-time validation above, these are the runtime errors you are most likely to hit across the DCA endpoints:\nWhenStatusErrorMissing or expired JWT401UnauthorizeduserPubkey does not match the authenticated wallet403Forbidden: userPubkey must match authenticated userdepositRequestId not found or already used400Deposit transaction not found in cache. Please craft a new deposit first.triggerMint is the stablecoin leg of the pair400Trigger mint is not supportedCancelling an order that is not active or withdrawing400Cannot cancel DCA order in '<state>' stateConfirm-cancel with a stale or wrong cancelRequestId400Withdrawal transaction not found in cache. Please initiate cancel again.\n​Related\nWas this page helpful?","tokens":3024,"squid":"spider-02","role":"Liquidity Spider","at":1791343240696,"hash":"b620f163547f8fac1c12ecf5ad8b4580e2cd586a"}
{"url":"https://eips.ethereum.org/EIPS/eip-1898","domain":"eips.ethereum.org","title":"EIP-1898: Add `blockHash` to defaultBlock methods","text":"🎉 Final\n\n Standards Track: Interface\n\n EIP-1898: Add `blockHash` to defaultBlock methods\n\n Add `blockHash` option to JSON-RPC methods that currently support defaultBlock parameter.\n\n Authors\n Charles Cooper (@charles-cooper)\n\n Created\n 2019-04-01\n\n Requires\n\n EIP-234\n\n Abstract\n\nFor JSON-RPC methods which currently accept a default block parameter, additionally allow the parameter to be a block hash.\n\nThis EIP can be considered a generalization of EIP-234. It would enable clients to unambiguously specify the block they want to query for certain JSON-RPC methods, even if the block is not in the canonical chain. This allows clients to maintain a coherent picture of blockchain state that they are interested in, even in the presence of reorgs, without requiring that the node maintain a persistent connection with the client or store any client-specific state.\n\n Specification\n\nThe following JSON-RPC methods are affected:\n\n eth_getBalance\n eth_getStorageAt\n eth_getTransactionCount\n eth_getCode\n eth_call\n eth_getProof\n\nThe following options, quoted from the Ethereum JSON-RPC spec, are currently possible for the defaultBlock parameter:\n\n HEX String - an integer block number\n String “earliest” for the earliest/genesis block\n String “latest” - for the latest canonical block\n String “pending” - for the pending state/transactions\n String “safe” - for the most recent safe block\n String “finalized” - for the most recent finalized block\n\nSince there is no way to clearly distinguish between a DATA parameter and a QUANTITY parameter, this EIP proposes a new scheme for the block parameter. The following option is additionally allowed:\n\n OBJECT\n\n blockNumber: QUANTITY - a block number\n blockHash: DATA - a block hash\n\nIf the block is not found, the callee SHOULD raise a JSON-RPC error (the recommended error code is -32001: Resource not found).\n\nIf the tag is blockHash, an additional boolean field may be supplied to the block parameter, requireCanonical, which defaults to false and defines whether the block must be a canonical block according to the callee. If requireCanonical is false, the callee should raise a JSON-RPC error only if the block is not found (as described above). If requireCanonical is true, the callee SHOULD additionally raise a JSON-RPC error if the block is not in the canonical chain (the recommended error code is -32000: Invalid input and in any case should be different than the error code for the block not found case so that the caller can distinguish the cases). The block-not-found check SHOULD take precedence over the block-is-canonical check, so that if the block is not found the callee raises block-not-found rather than block-not-canonical.\n\nTo maintain backwards compatibility, the block number MAY be specified either as a hex string or using the new block parameter scheme. In other words, the following are equivalent for the default block parameter:\n\n \"earliest\"\n \"0x0\"\n { \"blockNumber\": \"0x0\" }\n { \"blockHash\": \"0xd4e56740f876aef8c010b86a40d5f56745a118d0906a34e69aec8c0db1cb8fa3\" } (hash of the genesis block on the Ethereum main chain)\n { \"blockHash\": \"0xd4e56740f876aef8c010b86a40d5f56745a118d0906a34e69aec8c0db1cb8fa3\", \"requireCanonical\": true }\n { \"blockHash\": \"0xd4e56740f876aef8c010b86a40d5f56745a118d0906a34e69aec8c0db1cb8fa3\", \"requireCanonical\": false }\n\n Rationale\n\nCurrently, the state-querying JSON-RPC methods specified above have no option to unambiguously specify which block to query the state for. This can cause issues for applications which need to make multiple calls to the RPC. For instance, a wallet which just executed a transfer may want to display the balances of both the sender and recipient. If there is a re-org in between when the balance of the sender is queried via eth_getBalance and when the balance of the recipient is queried, the balances may not reconcile. As a slightly more complicated example, the UI for a decentralized exchange (which hosts orders on-chain) may walk a list of orders by calling eth_call for each of them to get the order data. Another type of use case is where an application needs to make a decision based on multiple pieces of state, e.g. a payout predicated on simultaneous ownership of two NFTs.\n\nIn order to ensure that the state is coherent (i.e., eth_call was called with exactly the same block for every call), the application may currently use one of several strategies:\n\n Decide on a block number to use (e.g., the latest block number known to the application). After each eth_call using that block number, call eth_getBlockByNumber, also with that block number. If the block hash does not match the known hash for that block number, rollback the current activity and retry from the beginning. This adds O(n) invocations as baseline overhead and another O(n) invocations for every retry needed. Moreover, there is no way to detect the (unlikely but possible) case that the relevant block was reorged out before eth_call, and then reorged back in before eth_getBlockByNumber.\n Rely on logs, which can be queried unambiguously thanks to the blockHash parameter. However, this requires semantic support from the smart contract; if the smart contract does not emit appropriate events, the client will not be able to reconstruct the specific state it is interested in.\n Rely on non-standard extensions like parity_subscribe. This requires a persistent connection between the client and node (via IPC or websockets), increases coupling between the client and the node, and cannot handle use cases where there are dependencies between invocations of eth_call, for example, walking a linked list.\n\nAllowing eth_call and friends to unambiguously specify the block to be queried give the application developer a robust and intuitive way to solve these problems. Multiple sequential queries will query the same state, enabling the application developer to not worry about inconsistencies in their view of the blockchain state.\n\n Backwards Compatibility\n\nBackwards compatible.\n\n Test Cases\n\n eth_getStorageAt [ \"0x<address>\", { \"blockNumber\": \"0x0\" } -> return storage at given address in genesis block\n eth_getStorageAt [ \"0x<address>\", { \"blockHash\": \"0xd4e56740f876aef8c010b86a40d5f56745a118d0906a34e69aec8c0db1cb8fa3\" } -> return storage at given address in genesis block\n eth_getStorageAt [ \"0x<address>\", { \"blockHash\": \"0xd4e56740f876aef8c010b86a40d5f56745a118d0906a34e69aec8c0db1cb8fa3\", \"requireCanonical\": false } -> return storage at given address in genesis block\n eth_getStorageAt [ \"0x<address>\", { \"blockHash\": \"0xd4e56740f876aef8c010b86a40d5f56745a118d0906a34e69aec8c0db1cb8fa3\", \"requireCanonical\": true } -> return storage at given address in genesis block\n eth_getStorageAt [ \"0x<address>\", { \"blockHash\": \"0x<non-existent-block-hash>\" } -> raise block-not-found error\n eth_getStorageAt [ \"0x<address>\", { \"blockHash\": \"0x<non-existent-block-hash>\", \"requireCanonical\": false } -> raise block-not-found error\n eth_getStorageAt [ \"0x<address>\", { \"blockHash\": \"0x<non-existent-block-hash>\", \"requireCanonical\": true } -> raise block-not-found error\n eth_getStorageAt [ \"0x<address>\", { \"blockHash\": \"0x<non-canonical-block-hash>\" } -> return storage at given address in specified block\n eth_getStorageAt [ \"0x<address>\", { \"blockHash\": \"0x<non-canonical-block-hash>\", \"requireCanonical\": false } -> return storage at given address in specified block\n eth_getStorageAt [ \"0x<address>\", { \"blockHash\": \"0x<non-canonical-block-hash>\", \"requireCanonical\": true } -> raise block-not-canonical error\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 Charles Cooper (@charles-cooper), \"EIP-1898: Add `blockHash` to defaultBlock methods,\" Ethereum Improvement Proposals, no. 1898, April 2019. Available: https://eips.ethereum.org/EIPS/eip-1898.","tokens":1964,"squid":"spider-05","role":"Spec Spider","at":1791343250583,"hash":"6fd4e2a23cb9523e644c2f51b29407f6e798ba67"}
{"url":"https://developers.jup.ag/docs/trigger","domain":"developers.jup.ag","title":"Trigger Order API Overview - Jupiter Developers","text":"The Jupiter Trigger Order API enables automated order types on Solana. Price orders execute a swap when a USD price condition is met (limit orders, take-profit, stop-loss). DCA orders split a deposit into recurring swaps on a schedule. Both share one vault, authentication, and deposit flow.\nOrders are stored off-chain and private by default, closing the most common MEV attack vector of visible pending orders. When an order triggers, Jupiter handles the swap: conversion, routing, and execution.\n​What’s New in V2\nTrigger V2 unifies two products that previously had separate APIs: limit orders (Trigger V1) and DCA (the Recurring V1 API). Here is what changes if you are migrating from either.\n​Limit orders: Trigger V1 vs V2\nFeatureTrigger V1Trigger V2Trigger typePool rate only (e.g. “1 Fartcoin = 0.00025 SOL”)USD priceOrder directionBuy below, sell aboveBuy above, buy below, sell above, sell belowTP/SLNot supportedTake-profit and stop-loss with OCO bundlingEdit ordersMust cancel and recreateEdit trigger price and slippage in-placePartial fillsNot supportedOrders fill partially for optimal execution pricesOutput amountGuaranteed (fixed pool rate)Not guaranteed (prioritises trigger execution, pool price may vary)AuthenticationAPI key onlyChallenge-response JWT + API keyOrder privacyPending orders visible on-chain (PDA accounts)Orders stored off-chain, private until executionDepositsProgram-derived address (PDA) order accountsVault accounts (custodial) by PrivyRoute prefix/trigger/v1/trigger/v2\nTrigger V1 is not scheduled for deprecation, but all development is focused on V2; V1 receives critical-only updates.\n​DCA: Recurring V1 vs Trigger V2\nDCA integrators are coming from the Recurring API, which is now unmaintained. What changes under Trigger V2:\nFeatureRecurring V1DCA (Trigger V2)StatusUnmaintainedActively maintainedScheduleTime-based interval, optional min/max price (price-based strategy deprecated)time_based or price_conditional (price band)Minimum size100 USD total; time-based 50 USD per order, 2+ orders10 USD per round, 2+ roundsAuthenticationAPI key onlyChallenge-response JWT + API keyDepositsOn-chain order accountsVault accounts (custodial) by Privy, shared across ordersToken-2022Not supportedSupported, except transfer-fee or transfer-hook mints (unless whitelisted)Route prefix/recurring/v1/trigger/v2\n​Order Families\nThe API has two order families that share the same vault, authentication, and deposit flow.\n​Price Orders\nExecute a swap when the USD price of a token crosses a threshold. See Create Order.\nTypeDescriptionUse caseSingleTriggers when USD price crosses above or below a threshold. Supports a trailing trigger that follows the marketStandard limit orders, stop-loss, trailing stop lossOCOTwo orders sharing one deposit: one take-profit, one stop-loss. When one fills, the other cancels automaticallyRisk management with TP/SL brackets (e.g. sell SOL at $300 TP or $200 SL while market is $250)OTOCOA parent order triggers first, then activates a TP/SL pair (OCO) on the outputConditional entry with automatic exit strategy\n​DCA (Dollar-Cost Averaging)\nSplit a single deposit into multiple swaps that execute on a fixed schedule. See DCA.\nTypeDescriptionUse caseTime-basedBuys a fixed amount every interval until the deposit is spentRecurring accumulation regardless of pricePrice-conditionalSame schedule, but each round only fills while the price is within a [min, max] bandRecurring accumulation limited to a target price range\n​How It Works\n\nEach wallet gets a single vault (a Privy-managed custodial account). When you create orders, tokens are deposited from your wallet into your vault. The vault holds funds for all your active orders.\n\nAuthenticate: Sign a challenge with your wallet to receive a JWT token\nSet up your vault and deposit: Resolve your vault (or register one on first use), then craft and sign a deposit that funds the order\nCreate an order: Submit a price order or a DCA order with the signed deposit\nMonitor: Track order state, fills, and events for price orders or DCA orders\nManage: Update or cancel price orders, or cancel DCA orders\n\nSee Integration Flow for the full call sequence and how each call’s output feeds the next.\n​Base URL\nhttps://api.jup.ag/trigger/v2\n\nAll endpoints require an API key via the x-api-key header. Authenticated endpoints additionally require a JWT token via the Authorization: Bearer <token> header.\n\n​FAQ\nHow do I get my funds back from an order?For a price order that expired or that you no longer want, funds stay in the vault; retrieve them with the two-step cancel flow (initiate, sign the withdrawal, confirm). See Expired Order Withdrawal. For a DCA order, cancelling returns the unfilled remainder to your wallet; rounds already filled are not reversed. See Cancel a DCA Order.Can I edit an order after creating it?Price orders can be updated in-place (trigger price and slippage) without cancelling and recreating. See Update an Order. DCA orders cannot be edited: to change a DCA, cancel it and create a new one.Why is the output amount not guaranteed?V2 uses USD price triggers rather than pool rate triggers. When the price condition is met, the order executes a swap at the current market rate via Jupiter routing. The actual output depends on liquidity and slippage at execution time.What is the minimum order size?Price orders: 10 USD equivalent. DCA: at least 10 USD per round, so the total minimum is 10 USD × the number of rounds (a 2-round DCA needs at least 20 USD).What happens if my JWT expires while I have open orders?Open orders continue to be monitored and will execute normally. The JWT is only required for API calls (creating, editing, cancelling orders). When your token expires, re-authenticate to manage your orders.What is an OCO order?A One-Cancels-Other order creates a take-profit and stop-loss pair that share one deposit. When one side fills, the other cancels automatically, returning unused funds to the vault.What is an OTOCO order?A One-Triggers-One-Cancels-Other order has a parent trigger that executes first. Once the parent fills, it automatically activates a TP/SL pair (OCO) on the output tokens. If the parent expires or fails, the child orders are never created.What is a DCA order?A DCA (dollar-cost averaging) order splits one deposit into multiple swaps that run on a schedule. You set the total amount, the number of rounds (2 or more), and the interval (1 minute to 1 year). Rounds can run unconditionally (time_based) or only within a price band (price_conditional). Each round must currently be worth at least 10 USD. See DCA.How do I stop a DCA order and get unspent funds back?Cancel it. Cancelling withdraws the unfilled remainder to your wallet; rounds already filled are not reversed. See Cancel a DCA Order.What is a price-conditional DCA?A DCA order type that fills a round only while the trigger mint’s USD price is inside [minPriceUsd, maxPriceUsd]. While the price is out of band, the round waits and reschedules to the next interval. See Price-conditional orders.What is the default slippage?For price orders: take-profit and buy-below orders use auto slippage via RTSE (Real-Time Slippage Estimator), and stop-loss and buy-above orders default to 20% (2000 bps) because execution certainty matters more when cutting losses. You can set a custom slippage. DCA orders have no slippage parameter: the keeper sets slippage per round from live market conditions at fill time.Can I set a trigger based on market cap?The API accepts USD price triggers only (triggerPriceUsd). Market cap targeting is a convenience feature on the jup.ag frontend — it converts the market cap to a USD price before submitting to the API. To replicate this, divide the target market cap by the token’s total supply to get the per-token USD price.Are my pending orders visible to MEV bots?No. V2 orders are stored off-chain and private by default. Order details (price, size, direction) are not revealed until the trigger condition is met and execution begins. In V1, pending orders were stored in on-chain PDA accounts, giving bots a roadmap to front-run profitable trades.Does Trigger V2 support integrator fees?Not currently, and there is no timeline for adding them. There is no atomic workaround because the keeper executes the transaction and the order is opaque to integrators. The only option is to run a separate transfer transaction outside the order flow.Was this page helpful?","tokens":2111,"squid":"spider-02","role":"Liquidity Spider","at":1791343255850,"hash":"d11e3ff48f31e2bc5fbd1c2932cb37009fb69cd0"}
{"url":"https://docs.phantom.com/phantom-deeplinks/provider-methods/connect","domain":"docs.phantom.com","title":"Connect - Phantom developer documentation","text":"In order to start interacting with Phantom, an app must first establish a connection. This connection request will prompt the user for permission to share their public key, indicating that they are willing to interact further.\nOnce a user connects to Phantom, Phantom will return a session param that should be used on all subsequent methods. For more information on sessions, see Handle sessions.\n​Base URL\nhttps://phantom.com/ul/v1/connect\n\n​Query string parameters\n\napp_url (required): A URL that is stored in the session token for validation purposes. This URL is used during session validation and can be checked against the blocklist. URL-encoded.\ndapp_encryption_public_key (required): A public key used for end-to-end encryption. This will be used to generate a shared secret. For more information on how Phantom handles shared secrets, see Encryption.\nredirect_link (required): The URI where Phantom should redirect the user upon connection. This URL is also used to fetch app metadata (such as title, icon, and favicon) for display in the connection approval dialog, using the same properties found in Display your app. The origin from this URL is also used for trusted app management. For more details, see Specify redirects. URL-encoded.\ncluster (optional): The network that should be used for subsequent interactions. Can be either: mainnet-beta, testnet, or devnet. Defaults to mainnet-beta.\n\nImportant distinction between redirect_link and app_url:\n\nredirect_link is used to fetch app metadata (title, icon, favicon) for display in the connection approval dialog and for trusted app management. This is what users see when approving the connection.\n\napp_url is stored in the session token for validation purposes and is not used for fetching metadata or display purposes.\n\nRedirect link behavior:\n\nHTTPS URLs: App metadata (logo, title, favicon) displays correctly in the connection dialog, but the redirect opens in the mobile browser instead of redirecting back to your app.\n\nCustom scheme URIs: Properly redirects back to your mobile app, but app metadata is not displayed in the connection dialog.\n\nFor more details on choosing a redirect link type, see Specify redirects.\n​Returns\n​Approve\n\nphantom_encryption_public_key: An encryption public key used by Phantom for the construction of a shared secret between the connecting app and Phantom, encoded in base58.\n\nnonce: A nonce used for encrypting the response, encoded in base58.\n\ndata: An encrypted JSON string. Refer to Encryption to learn how apps can decrypt data using a shared secret. Encrypted bytes are encoded in base58.\n// content of decrypted `data`-parameter\n{\n // base58 encoding of user public key\n \"public_key\": \"BSFtCudCd4pR4LSFqWPjbtXPKSNVbGkc35gRNdnqjMCU\",\n\n // session token for subsequent signatures and messages\n // dapps should send this with any other deeplinks after connect\n \"session\": \"...\"\n}\n\npublic_key: The public key of the user, represented as a base58-encoded string.\nsession: A string encoded in base58. This should be treated as opaque by the connecting app, as it only needs to be passed alongside other parameters. Sessions do not expire. For more details, see Handle sessions.\n\n​Reject\nAn errorCode and errorMessage as query parameters. For a full list of possible error codes, see Errors.\n{\n \"errorCode\": \"...\",\n \"errorMessage\": \"...\"\n}\n\n​Example\nRefer to the connect method implemented in our React Native demo application.Was this page helpful?","tokens":864,"squid":"spider-10","role":"Tooling Spider","at":1791343281467,"hash":"f44f66d87f02f80c3cbb7afd54b3fb95764899b2"}
{"url":"https://docs.switchboard.xyz/docs-by-chain/sui/surge","domain":"docs.switchboard.xyz","title":"Surge Price Feeds | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.Version source of truth: SDK Version MatrixThe Future of Oracle TechnologySwitchboard Surge is the industry's fastest oracle data delivery system, providing sub-100ms latency through direct WebSocket streaming. Built for the next generation of DeFi applications, trading systems, and real-time dashboards.Key InnovationTraditional oracles require multiple steps—gathering prices, writing to blockchain state, reaching consensus, and then making data available—resulting in 2-10 seconds of latency.Switchboard oracles must pass a hardware proof when joining the network, ensuring they run only verified Switchboard code. This allows oracles to stream price data directly from sources to your application via WebSocket, achieving sub-100ms latency.┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐\n│ Price Sources │────▶│ Oracle Network │────▶│ Surge Gateway │\n│ (CEX, DEX) │ │ (SAIL Verified) │ │ (WebSocket) │\n└──────────────────┘ └──────────────────┘ └────────┬─────────┘\n │\n ┌──────────▼──────────┐\n │ Your Application │\n │ • Event Listeners │\n │ • Price Handlers │\n │ • Quote Converter │\n └─────────────────────┘Key FeaturesUnmatched Performance — Sub-100ms latency with direct WebSocket streaming and event-driven updates. No polling required.Zero Setup — No data feed accounts or on-chain deployment needed. Just use your keypair and connection to start streaming.Cost Efficiency — Subscription-based pricing with no gas fees for receiving updates. Reduced on-chain costs when submitting to contracts.Seamless Integration — TypeScript/JavaScript SDK, WebSocket API for any language, and Sui quote conversion for on-chain use.Enterprise-Grade Reliability — 99.9% uptime SLA with global infrastructure, automatic failover, and professional support.User FlowSurge works the same way regardless of your target chain:Subscribe — All Surge subscriptions are managed on Solana, regardless of which chain you're building on. Connect your Solana wallet at the subscription portal.Authenticate — The SDK authenticates your session by signing with your Solana keypair. If the keypair does not have an active subscription, connectAndSubscribe will fail.Stream Prices — Once subscribed, prices stream directly to your application via WebSocket. No on-chain reads required—this is what enables sub-100ms latency.Use Prices — When you need prices on-chain, convert the Surge update to your chain's format and submit it. Switchboard provides SDKs for Solana, EVM, and Sui.Getting Started1. SubscribeConnect your wallet and subscribe at explorer.switchboardlabs.xyz/subscriptions. If you are an AI agent or wish to subscribe programmatically rather than through the UI, see the Surge Subscription Guide.2. Install the SDKnpm install @switchboard-xyz/on-demand@3.10.6 @switchboard-xyz/sui-sdk@0.1.16 @mysten/sui@1.38.0 @solana/web3.js@1.98.4\n# or\nyarn add @switchboard-xyz/on-demand@3.10.6 @switchboard-xyz/sui-sdk@0.1.16 @mysten/sui@1.38.0 @solana/web3.js@1.98.43. Connect and Streamimport * as sb from \"@switchboard-xyz/on-demand\";\nimport { convertSurgeUpdateToQuotes, MAINNET_QUEUE_ID } from \"@switchboard-xyz/sui-sdk\";\nimport { Transaction } from \"@mysten/sui/transactions\";\n\n// Initialize with keypair and connection (uses on-chain subscription)\nconst surge = new sb.Surge({ connection, keypair });\n// `connection` is a Solana RPC Connection from @solana/web3.js (used to verify the Solana subscription),\n// not your Sui client. Keep a separate Sui client for on-chain writes.\n\n// Auth note: the SDK signs with your keypair to authenticate the session.\n// If the keypair has no active Surge subscription, connectAndSubscribe will fail.\n\n// Discover available feeds\nconst availableFeeds = await surge.getSurgeFeeds();\nconsole.log(`${availableFeeds.length} feeds available`);\n\n// Subscribe to specific feeds\nawait surge.connectAndSubscribe([\n { symbol: 'BTC/USD' },\n { symbol: 'ETH/USD' },\n]);\n\n// Handle price updates\nsurge.on('signedPriceUpdate', async (response: sb.SurgeUpdate) => {\n const metrics = response.getLatencyMetrics();\n if (metrics.isHeartbeat) return;\n\n const prices = response.getFormattedPrices();\n metrics.perFeedMetrics.forEach((feed) => {\n console.log(`${feed.symbol}: ${prices[feed.feed_hash]}`);\n });\n\n // Convert to on-chain Oracle Quote for Sui contracts when needed\n const ptb = new Transaction();\n const quoteData = await convertSurgeUpdateToQuotes(ptb, response, MAINNET_QUEUE_ID);\n\n ptb.moveCall({\n target: `${PACKAGE_ID}::your_module::your_function`,\n arguments: [quoteData],\n });\n});Pricing & LimitsPlanPriceQuote IntervalMax FeedsMax ConnectionsPlugFree10s21Pro~$3,000/mo450ms10010Enterprise~$7,500/mo0ms30015Subscriptions are paid in SWTCH tokens. For custom limits or dedicated support, contact sales@switchboard.xyz.Primary Use CasesPerpetual ExchangesSurge is the perfect oracle solution for perpetual trading platforms:import * as sb from \"@switchboard-xyz/on-demand\";\nimport { convertSurgeUpdateToQuotes, MAINNET_QUEUE_ID } from \"@switchboard-xyz/sui-sdk\";\nimport { Transaction } from \"@mysten/sui/transactions\";\n\nsurge.on('signedPriceUpdate', async (response: sb.SurgeUpdate) => {\n const metrics = response.getLatencyMetrics();\n if (metrics.isHeartbeat) return;\n\n const prices = response.getFormattedPrices();\n\n for (const feed of metrics.perFeedMetrics) {\n const price = parseFloat(prices[feed.feed_hash].replace(/[$,]/g, ''));\n\n // Update mark price instantly\n await updateMarkPrice(feed.symbol, price);\n\n // Check for liquidations with latest price\n const liquidations = await checkLiquidations(feed.symbol, price);\n if (liquidations.length > 0) {\n const ptb = new Transaction();\n const quoteData = await convertSurgeUpdateToQuotes(ptb, response, MAINNET_QUEUE_ID);\n await executeLiquidations(liquidations, ptb, quoteData);\n }\n }\n});Oracle-Based AMMsBuild the next generation of AMMs that use real-time oracle prices:class OracleAMM {\n private latestUpdate: sb.SurgeUpdate;\n\n async handlePriceUpdate(response: sb.SurgeUpdate) {\n const metrics = response.getLatencyMetrics();\n if (metrics.isHeartbeat) return;\n\n this.latestUpdate = response;\n const prices = response.getFormattedPrices();\n\n for (const feed of metrics.perFeedMetrics) {\n const pair = this.pairs.get(feed.symbol);\n pair.oraclePrice = parseFloat(prices[feed.feed_hash].replace(/[$,]/g, ''));\n pair.lastUpdate = Date.now();\n }\n }\n\n async executeSwap(tokenIn: string, tokenOut: string, amountIn: number) {\n const pair = `${tokenIn}/${tokenOut}`;\n const latestPrice = this.pairs.get(pair).oraclePrice;\n const amountOut = amountIn * latestPrice * (1 - this.swapFee);\n\n const ptb = new Transaction();\n const quoteData = await convertSurgeUpdateToQuotes(ptb, this.latestUpdate, MAINNET_QUEUE_ID);\n\n ptb.moveCall({\n target: `${PACKAGE_ID}::amm::swap`,\n arguments: [amountIn, amountOut, quoteData],\n });\n\n return await this.client.signAndExecuteTransaction({ transaction: ptb });\n }\n}High-Frequency Trading & Arbitragesurge.on('signedPriceUpdate', async (response: sb.SurgeUpdate) => {\n const metrics = response.getLatencyMetrics();\n if (metrics.isHeartbeat) return;\n\n const prices = response.getFormattedPrices();\n\n for (const feed of metrics.perFeedMetrics) {\n const oraclePrice = parseFloat(prices[feed.feed_hash].replace(/[$,]/g, ''));\n const dexPrice = await getDexPrice(feed.symbol);\n\n const spread = Math.abs(dexPrice - oraclePrice) / oraclePrice;\n if (spread > MIN_PROFIT_THRESHOLD) {\n const ptb = new Transaction();\n const quoteData = await convertSurgeUpdateToQuotes(ptb, response, MAINNET_QUEUE_ID);\n await executeArbitrage(ptb, quoteData, calculateOptimalSize(spread));\n }\n }\n});Liquidation Enginessurge.on('signedPriceUpdate', async (response: sb.SurgeUpdate) => {\n const metrics = response.getLatencyMetrics();\n if (metrics.isHeartbeat) return;\n\n const prices = response.getFormattedPrices();\n\n for (const feed of metrics.perFeedMetrics) {\n const price = parseFloat(prices[feed.feed_hash].replace(/[$,]/g, ''));\n const positions = await getPositionsByCollateral(feed.symbol);\n\n for (const position of positions) {\n const ltv = calculateLTV(position, price);\n if (ltv > LIQUIDATION_THRESHOLD) {\n const ptb = new Transaction();\n const quoteData = await convertSurgeUpdateToQuotes(ptb, response, MAINNET_QUEUE_ID);\n await liquidatePosition(position, ptb, quoteData);\n }\n }\n }\n});Technical SpecificationsLatency BreakdownOracle processing: ~10msNetwork transmission: ~20-50msClient processing: ~10msTotal: <100msDiscovering Available FeedsUse the getSurgeFeeds() method to see all available trading pairs:const surge = new sb.Surge({ connection, keypair });\nconst feeds = await surge.getSurgeFeeds();\n\nfeeds.forEach(feed => {\n console.log(`${feed.symbol}`);\n});Supported AssetsAll major cryptocurrency pairsMultiple exchange sources availableNew pairs added regularlyCustom feeds available on requestNote: Surge does not support custom feeds created with the feed builder.FAQHow is Surge different from traditional oracles?Surge streams data directly to your application via WebSocket, bypassing the blockchain entirely for reads. This eliminates gas costs and reduces latency from seconds to milliseconds.Can I use Surge data on-chain?Yes! Surge updates can be converted to Sui quote format using convertSurgeUpdateToQuotes() from the @switchboard-xyz/sui-sdk and submitted to your Move contracts.What's the reliability?Surge operates with 99.9% uptime SLA, automatic failover, and global redundancy. Enterprise customers get dedicated infrastructure.How do I handle disconnections?The SDK includes automatic reconnection logic with exponential backoff. Your application will seamlessly recover from network interruptions.Next StepsSurge Tutorial - Step-by-step implementation guideCrossbar Gateway - Stream prices to your frontendSurge Gateway Protocol - Advanced HTTP + WebSocket protocolExplore code examplesJoin our DiscordPreviousPrice Feeds TutorialNextSurge TutorialLast updated 2 months ago","tokens":2500,"squid":"spider-08","role":"Oracle Spider","at":1791343284622,"hash":"b7f8ff08904b21a9d15f06dfa557603c629dbb91"}
{"url":"https://docs.switchboard.xyz/docs-by-chain/solana-svm/randomness/randomness-tutorial","domain":"docs.switchboard.xyz","title":"Randomness Tutorial | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.Example Code: The complete working example for this tutorial is available at sb-on-demand-examples/solana/randomness/coin-flipThis tutorial demonstrates how to integrate verifiable randomness into your Solana program using Switchboard's commit-reveal pattern. You'll build a provably fair coin flip game.Version source of truth: SDK Version MatrixWhy Verifiable Randomness?On-chain randomness is hard. Naive approaches fail because:Block hashes are predictable: Validators can see future block dataTimestamps are manipulable: Validators control block timestampsExternal sources are untrusted: Off-chain randomness can be fakedSwitchboard solves this with a commit-reveal pattern where neither party knows the outcome until after commitment.How It Works1. COMMIT → 2. GENERATE → 3. REVEAL\n Player Oracle Settlement\n commits to generates Player reveals\n slothash randomness and uses valueCommit: Player commits to using a specific Solana slothashGenerate: Oracle generates randomness based on the committed slotReveal: Player reveals the randomness and uses it in their programThis is secure because:The player commits before knowing the randomnessThe oracle generates randomness after commitmentNeither party can manipulate the outcomeWhat You'll BuildA coin flip game where:Player guesses heads or tailsSwitchboard generates verifiable random outcomeWinner receives double their wagerPrerequisitesRust and Cargo installedAnchor framework 0.31.1Solana CLI installed and configuredNode.js and pnpmA Solana keypair with SOLKey ConceptsRandomness AccountA dedicated Solana account that stores:The committed slothashThe seed slotThe revealed random value (after revelation)const [randomness, createIx] = await sb.Randomness.create(sbProgram, rngKp, queue);RandomnessAccountDataThe on-chain struct for parsing randomness state:use switchboard_on_demand::accounts::RandomnessAccountData;\n\nlet randomness_data = RandomnessAccountData::parse(\n ctx.accounts.randomness_account_data.data.borrow()\n).unwrap();Note: Randomness is not read from quote.feeds(). For Solana commit-reveal, call RandomnessAccountData::get_value(clock.slot), which returns a 32-byte randomness value (for example, random_bytes[0] % 2 for a coin flip).Slot-Based FreshnessRandomness must be used within a specific slot window:// Ensure randomness was committed in the previous slot\nif randomness_data.seed_slot != clock.slot - 1 {\n return Err(ErrorCode::RandomnessExpired.into());\n}Collateral on Commit (Critical!)Always take payment when committing, not when revealing.// CORRECT: Take collateral at commit time\npub fn coin_flip(ctx: Context<CoinFlip>, ...) -> Result<()> {\n // Validate randomness...\n\n // Take wager NOW, before randomness is revealed\n transfer(from_user, to_escrow, wager)?;\n\n Ok(())\n}Why? If you take payment on reveal, a malicious user could:Commit to randomnessWait for revealOnly reveal if they won (selective revelation attack)The On-Chain ProgramDependencies[dependencies]\nanchor-lang = \"0.31.1\"\nswitchboard-on-demand = { version = \"0.13.0\", features = [\"anchor\"] }Program Structureuse anchor_lang::prelude::*;\nuse switchboard_on_demand::accounts::RandomnessAccountData;\n\ndeclare_id!(\"YOUR_PROGRAM_ID\");\n\n#[program]\npub mod sb_randomness {\n use super::*;\n\n pub fn initialize(ctx: Context<Initialize>) -> Result<()> {\n let player_state = &mut ctx.accounts.player_state;\n player_state.latest_flip_result = false;\n player_state.randomness_account = Pubkey::default();\n player_state.wager = 100; // lamports\n player_state.bump = ctx.bumps.player_state;\n player_state.allowed_user = ctx.accounts.user.key();\n Ok(())\n }\n\n pub fn coin_flip(\n ctx: Context<CoinFlip>,\n randomness_account: Pubkey,\n guess: bool, // true = heads, false = tails\n ) -> Result<()> {\n let clock = Clock::get()?;\n let player_state = &mut ctx.accounts.player_state;\n\n // Record the user's guess\n player_state.current_guess = guess;\n\n // Parse the randomness account\n let randomness_data = RandomnessAccountData::parse(\n ctx.accounts.randomness_account_data.data.borrow()\n ).unwrap();\n\n // SECURITY: Verify randomness is fresh (committed in previous slot)\n if randomness_data.seed_slot != clock.slot - 1 {\n msg!(\"seed_slot: {}\", randomness_data.seed_slot);\n msg!(\"current slot: {}\", clock.slot);\n return Err(ErrorCode::RandomnessExpired.into());\n }\n\n // SECURITY: Ensure randomness hasn't been revealed yet\n if !randomness_data.get_value(clock.slot).is_err() {\n return Err(ErrorCode::RandomnessAlreadyRevealed.into());\n }\n\n // Store commit slot for later verification\n player_state.commit_slot = randomness_data.seed_slot;\n\n // CRITICAL: Take collateral NOW, not on reveal!\n transfer(\n ctx.accounts.system_program.to_account_info(),\n ctx.accounts.user.to_account_info(),\n ctx.accounts.escrow_account.to_account_info(),\n player_state.wager,\n None,\n )?;\n\n // Store randomness account reference\n player_state.randomness_account = randomness_account;\n\n msg!(\"Coin flip initiated, randomness requested.\");\n Ok(())\n }\n\n pub fn settle_flip(ctx: Context<SettleFlip>, escrow_bump: u8) -> Result<()> {\n let clock = Clock::get()?;\n let player_state = &mut ctx.accounts.player_state;\n\n // SECURITY: Verify randomness account matches stored reference\n if ctx.accounts.randomness_account_data.key() != player_state.randomness_account {\n return Err(ErrorCode::InvalidRandomnessAccount.into());\n }\n\n // Parse randomness data\n let randomness_data = RandomnessAccountData::parse(\n ctx.accounts.randomness_account_data.data.borrow()\n ).unwrap();\n\n // SECURITY: Verify seed_slot matches commit\n if randomness_data.seed_slot != player_state.commit_slot {\n return Err(ErrorCode::RandomnessExpired.into());\n }\n\n // Get the revealed random value\n let revealed_random_value = randomness_data\n .get_value(clock.slot)\n .map_err(|_| ErrorCode::RandomnessNotResolved)?;\n\n // Use randomness to determine outcome\n // Even = heads (true), Odd = tails (false)\n let randomness_result = revealed_random_value[0] % 2 == 0;\n\n player_state.latest_flip_result = randomness_result;\n\n if randomness_result {\n msg!(\"FLIP_RESULT: Heads\");\n } else {\n msg!(\"FLIP_RESULT: Tails\");\n }\n\n // Settle the wager\n if randomness_result == player_state.current_guess {\n msg!(\"You win!\");\n // Pay out double the wager\n let seeds = &[b\"stateEscrow\".as_ref(), &[escrow_bump]];\n transfer(\n ctx.accounts.system_program.to_account_info(),\n ctx.accounts.escrow_account.to_account_info(),\n ctx.accounts.user.to_account_info(),\n player_state.wager * 2,\n Some(&[seeds]),\n )?;\n } else {\n msg!(\"You lose!\");\n // Escrow keeps the wager\n }\n\n Ok(())\n }\n}Account Structures#[account]\npub struct PlayerState {\n allowed_user: Pubkey, // Who can play\n latest_flip_result: bool, // Last flip outcome\n randomness_account: Pubkey, // Reference to Switchboard randomness\n current_guess: bool, // Player's guess\n wager: u64, // Bet amount\n bump: u8, // PDA bump\n commit_slot: u64, // Slot when committed\n}\n\n#[derive(Accounts)]\npub struct Initialize<'info> {\n #[account(\n init,\n payer = user,\n seeds = [b\"playerState\", user.key().as_ref()],\n space = 8 + 100,\n bump\n )]\n pub player_state: Account<'info, PlayerState>,\n #[account(mut)]\n pub user: Signer<'info>,\n pub system_program: Program<'info, System>,\n}\n\n#[derive(Accounts)]\npub struct CoinFlip<'info> {\n #[account(\n mut,\n seeds = [b\"playerState\", user.key().as_ref()],\n bump = player_state.bump\n )]\n pub player_state: Account<'info, PlayerState>,\n pub user: Signer<'info>,\n /// CHECK: Validated manually in handler\n pub randomness_account_data: AccountInfo<'info>,\n /// CHECK: Escrow PDA\n #[account(mut, seeds = [b\"stateEscrow\"], bump)]\n pub escrow_account: AccountInfo<'info>,\n pub system_program: Program<'info, System>,\n}\n\n#[derive(Accounts)]\npub struct SettleFlip<'info> {\n #[account(\n mut,\n seeds = [b\"playerState\", user.key().as_ref()],\n bump = player_state.bump\n )]\n pub player_state: Account<'info, PlayerState>,\n /// CHECK: Validated manually in handler\n pub randomness_account_data: AccountInfo<'info>,\n /// CHECK: Escrow PDA\n #[account(mut, seeds = [b\"stateEscrow\"], bump)]\n pub escrow_account: AccountInfo<'info>,\n pub user: Signer<'info>,\n pub system_program: Program<'info, System>,\n}Error Codes#[error_code]\npub enum ErrorCode {\n #[msg(\"Unauthorized access attempt.\")]\n Unauthorized,\n #[msg(\"Game is still active.\")]\n GameStillActive,\n #[msg(\"Not enough funds to play.\")]\n NotEnoughFundsToPlay,\n #[msg(\"Randomness already revealed.\")]\n RandomnessAlreadyRevealed,\n #[msg(\"Randomness not yet resolved.\")]\n RandomnessNotResolved,\n #[msg(\"Randomness has expired.\")]\n RandomnessExpired,\n #[msg(\"Invalid randomness account.\")]\n InvalidRandomnessAccount,\n}The TypeScript ClientSetupimport * as anchor from \"@coral-xyz/anchor\";\nimport { Keypair, PublicKey, SystemProgram } from \"@solana/web3.js\";\nimport * as sb from \"@switchboard-xyz/on-demand\";\n\nasync function main() {\n // Load environment\n const { keypair, connection, program } = await sb.AnchorUtils.loadEnv();\n\n // Get the default Switchboard queue\n const queue = await sb.getDefaultQueue(connection.rpcEndpoint);\n\n // Load your program\n const myProgram = await loadMyProgram(program.provider);\n const sbProgram = await loadSbProgram(program.provider);\n}Create Randomness Account// Generate keypair for randomness account\nconst rngKp = Keypair.generate();\n\n// Create the randomness account\nconst [randomness, createIx] = await sb.Randomness.create(sbProgram, rngKp, queue);\n\n// Send creation transaction\nconst createTx = await sb.asV0Tx({\n connection,\n ixs: [createIx],\n payer: keypair.publicKey,\n signers: [keypair, rngKp],\n computeUnitPrice: 75_000,\n computeUnitLimitMultiple: 1.3,\n});\n\nawait connection.sendTransaction(createTx);Commit Phase// Get user's guess from command line\nconst userGuess = process.argv[2] === \"heads\"; // true = heads\n\n// Create commit instruction\nconst commitIx = await randomness.commitIx(queue);\n\n// Create your program's coin flip instruction\nconst coinFlipIx = await myProgram.methods\n .coinFlip(rngKp.publicKey, userGuess)\n .accounts({\n playerState: playerStateAccount,\n user: keypair.publicKey,\n randomnessAccountData: rngKp.publicKey,\n escrowAccount: escrowAccount,\n systemProgram: SystemProgram.programId,\n })\n .instruction();\n\n// Bundle commit + coin_flip in same transaction\nconst commitTx = await sb.asV0Tx({\n connection,\n ixs: [commitIx, coinFlipIx],\n payer: keypair.publicKey,\n signers: [keypair],\n computeUnitPrice: 75_000,\n computeUnitLimitMultiple: 1.3,\n});\n\nconst commitSig = await connection.sendTransaction(commitTx);\nawait connection.confirmTransaction(commitSig, \"confirmed\");\nconsole.log(\"Committed! Transaction:\", commitSig);Reveal Phase// Wait for slot to advance\nconsole.log(\"Waiting for randomness generation...\");\nawait new Promise(resolve => setTimeout(resolve, 3000));\n\n// Create reveal instruction\nconst revealIx = await randomness.revealIx();\n\n// Create your program's settle instruction\nconst settleFlipIx = await myProgram.methods\n .settleFlip(escrowBump)\n .accounts({\n playerState: playerStateAccount,\n randomnessAccountData: rngKp.publicKey,\n escrowAccount: escrowAccount,\n user: keypair.publicKey,\n systemProgram: SystemProgram.programId,\n })\n .instruction();\n\n// Bundle reveal + settle in same transaction\nconst revealTx = await sb.asV0Tx({\n connection,\n ixs: [revealIx, settleFlipIx],\n payer: keypair.publicKey,\n signers: [keypair],\n computeUnitPrice: 75_000,\n computeUnitLimitMultiple: 1.3,\n});\n\nconst revealSig = await connection.sendTransaction(revealTx);\nawait connection.confirmTransaction(revealSig, \"confirmed\");\nconsole.log(\"Revealed! Transaction:\", revealSig);\n\n// Parse result from logs\nconst tx = await connection.getParsedTransaction(revealSig, {\n maxSupportedTransactionVersion: 0,\n});\nconst resultLog = tx?.meta?.logMessages?.find(line =>\n line.includes(\"FLIP_RESULT\")\n);\nconsole.log(\"Result:\", resultLog);Retry LogicNetwork issues can cause commit/reveal to fail. Add retry logic:async function retryCommit(\n randomness: sb.Randomness,\n queue: any,\n maxRetries = 3\n): Promise<anchor.web3.TransactionInstruction> {\n for (let attempt = 1; attempt <= maxRetries; attempt++) {\n try {\n console.log(`Commit attempt ${attempt}/${maxRetries}...`);\n return await randomness.commitIx(queue);\n } catch (error) {\n if (attempt === maxRetries) throw error;\n console.log(`Failed, retrying in 2s...`);\n await new Promise(r => setTimeout(r, 2000));\n }\n }\n throw new Error(\"All commit attempts failed\");\n}\n\nasync function retryReveal(\n randomness: sb.Randomness,\n maxRetries = 5\n): Promise<anchor.web3.TransactionInstruction> {\n for (let attempt = 1; attempt <= maxRetries; attempt++) {\n try {\n console.log(`Reveal attempt ${attempt}/${maxRetries}...`);\n return await randomness.revealIx();\n } catch (error) {\n if (attempt === maxRetries) throw error;\n console.log(`Failed, retrying in 2s...`);\n await new Promise(r => setTimeout(r, 2000));\n }\n }\n throw new Error(\"All reveal attempts failed\");\n}Running the Example1. Clone the Repositorygit clone https://github.com/switchboard-xyz/sb-on-demand-examples\ncd sb-on-demand-examples/solana/randomness/coin-flip2. Install Dependenciesnpm install3. Point Solana CLI at Devnetsolana config set --url devnet\nsolana airdrop 24. Run the Example Against the Preconfigured Devnet ProgramThe checked-in Anchor.toml already includes a devnet program ID for sb_randomness, so you can run the example directly:npm run start -- heads\n# or\nnpm run start -- tails5. Deploy Your Own Program (Optional)If you want to deploy your own instance instead of using the preconfigured devnet program:anchor keys sync\nanchor build\nanchor deploy\nanchor idl init --filepath target/idl/sb_randomness.json YOUR_PROGRAM_ADDRESSThe example script resolves the example program ID from Anchor.toml. To override that at runtime, set SB_RANDOMNESS_PROGRAM_ID:SB_RANDOMNESS_PROGRAM_ID=YOUR_PROGRAM_ADDRESS npm run start -- headsExpected OutputSetup...\nProgram 93tkpep2PYDxweHHi2vQBpi7eTBF23y8LGdiLMt5R9f2\nQueue account FdRnYujMnYbAJp5P2rkEYZCbF2TKs2D2yXZ7MYq89Hms\n\nInitialize the game states...\n Transaction Signature abc123...\n\nCommit to randomness...\n Transaction Signature commitTx def456...\n\nReveal the randomness...\n Transaction Signature revealTx ghi789...\n\nYour guess is Heads\n\nAnd the random result is ... Heads!\nYou win!\n\nGame completed!Security Best Practices1. Always Take Collateral at Commit Time// CORRECT\npub fn coin_flip(...) -> Result<()> {\n // ... validate randomness ...\n transfer(user, escrow, wager)?; // Take payment HERE\n Ok(())\n}\n\n// WRONG - vulnerable to selective revelation\npub fn settle_flip(...) -> Result<()> {\n transfer(user, escrow, wager)?; // DON'T take payment here!\n // ... use randomness ...\n}2. Validate Slot Freshness// Ensure randomness was committed recently\nif randomness_data.seed_slot != clock.slot - 1 {\n return Err(ErrorCode::RandomnessExpired.into());\n}3. Verify Randomness Account Reference// Store at commit time\nplayer_state.randomness_account = randomness_account;\n\n// Verify at reveal time\nif ctx.accounts.randomness_account_data.key() != player_state.randomness_account {\n return Err(ErrorCode::InvalidRandomnessAccount.into());\n}4. Check Randomness Not Already Revealed// At commit time, ensure randomness isn't already revealed\nif !randomness_data.get_value(clock.slot).is_err() {\n return Err(ErrorCode::RandomnessAlreadyRevealed.into());\n}Use CasesGaming & GamblingCasino games (dice, slots, roulette)Provably fair bettingSkill-based games with random elementsNFT MintingRandom trait assignmentFair rarity distributionBlind box revealsLotteriesTicket drawingRaffle winnersPrize distributionFair DistributionAirdrop selectionWhitelist randomizationToken allocationAdvanced TopicsReusing Randomness AccountsSave the keypair to reuse across sessions:import * as fs from \"fs\";\n\nconst KEYPAIR_PATH = \"randomness-keypair.json\";\n\n// Load or create\nlet rngKp: Keypair;\nif (fs.existsSync(KEYPAIR_PATH)) {\n const data = JSON.parse(fs.readFileSync(KEYPAIR_PATH, \"utf8\"));\n rngKp = Keypair.fromSecretKey(new Uint8Array(data));\n} else {\n rngKp = Keypair.generate();\n fs.writeFileSync(KEYPAIR_PATH, JSON.stringify(Array.from(rngKp.secretKey)));\n}Multiple Random ValuesThe revealed value is 32 bytes. Use different bytes for different outcomes:let random_bytes = randomness_data.get_value(clock.slot)?;\n\n// Use different bytes for different purposes\nlet coin_flip = random_bytes[0] % 2 == 0;\nlet dice_roll = (random_bytes[1] % 6) + 1; // 1-6\nlet card_draw = random_bytes[2] % 52; // 0-51Next StepsPrice Feeds: Learn oracle integration in Basic Price FeedPrediction Markets: See feed verification in Prediction MarketCustom Feeds: Create your own feeds in Custom FeedsPreviousRandomnessNextX402 MicropaymentsLast updated 3 months ago","tokens":4182,"squid":"spider-08","role":"Oracle Spider","at":1791343295206,"hash":"40257fe2c4d94c7340a2e3e6db2cc2acc9d36ea5"}
{"url":"https://www.metaplex.com/docs/smart-contracts/mpl-distro/getting-started","domain":"metaplex.com","title":"Create an MPL-Distro Token Distribution on Solana","text":"This guide sends an existing token to two wallets with MPL-Distro and the Umi framework. SummaryAn MPL-Distro launch requires an existing SPL token mint, a preserved off-chain Merkle allocation, and enough tokens in the distribution vault.Build the root and proofs with prepareDistribution.Create a seven-day Wallet distribution with permissionless submission.Deposit the sum of every allocation before claims begin.Submit the exact amount, nonce, and proof committed in the tree.What You Will BuildYou will create a two-recipient distribution, deposit 350,000 token base units, and submit the first recipient's 100,000-unit claim.Create and Fund from the CLIThe Metaplex CLI can create the distribution and deposit or withdraw tokens. Generate Merkle proofs and submit claims with this SDK walkthrough.Jump to: Prerequisites · Install · Create · Fund · Claim · ErrorsQuick StartThe MPL-Distro quick start has four required phases.Install the MPL-Distro client and register mplDistro() with Umi.Generate and preserve the allocation root, proofs, amounts, and nonces.Create the distribution and deposit the complete token allocation.Submit a proof with distribute and verify its claim receipt.PrerequisitesMPL-Distro requires a funded Solana signer and an existing mint owned by the original SPL Token program.Node.js 20 or newerA Umi identity with SOL for rent, transaction fees, and the 0.002 SOL claim protocol feeAn existing SPL token mint and its authority's funded associated token accountRecipient addresses and allocation amounts expressed in token base units (the mint's smallest denomination; a 6-decimal token uses 1_000_000 units per 1.0 token)The examples do not accept Token-2022 mints. Use an original SPL Token program mint.Install the MPL-Distro SDKInstall the MPL-Distro client and its Umi peer dependencies in the application that prepares and submits transactions.Terminalnpm install @metaplex-foundation/mpl-distro@^0.4 \\\n @metaplex-foundation/umi@^1.1 \\\n @metaplex-foundation/umi-bundle-defaults \\\n @metaplex-foundation/mpl-toolbox@^0.10\nInstall @metaplex-foundation/mpl-core only when claiming into a Core asset signer.Create the Wallet DistributionCreate the distribution by committing the recipient list as a Merkle root and storing the returned proofs off-chain.createDistribution.ts1import {\n2 AllowedDistributor,\n3 createDistribution,\n4 DistributionType,\n5 findDistributionPda,\n6 mplDistro,\n7 prepareDistribution,\n8} from '@metaplex-foundation/mpl-distro'\n9import { generateSigner, publicKey } from '@metaplex-foundation/umi'\n10import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n11\n12const umi = createUmi(\n13 process.env.RPC_URL ?? 'https://api.devnet.solana.com'\n14).use(mplDistro())\n15\n16// Use umi.use(keypairIdentity(yourKeypair)) when the Umi identity\n17// should be the distribution authority.\n18\n19const mint = publicKey(process.env.TOKEN_MINT!)\n20const recipients = [\n21 { address: publicKey(process.env.RECIPIENT_1!), amount: 100_000n },\n22 { address: publicKey(process.env.RECIPIENT_2!), amount: 250_000n },\n23]\n24const { root, proofs, treeHeight } = prepareDistribution(recipients)\n25const seed = generateSigner(umi)\n26const now = BigInt(Math.floor(Date.now() / 1000))\n27\n28await createDistribution(umi, {\n29 mint,\n30 seed,\n31 merkleRoot: root,\n32 treeHeight,\n33 startTime: now,\n34 endTime: now + 7n * 24n * 60n * 60n,\n35 totalClaimants: BigInt(recipients.length),\n36 name: 'Community distribution',\n37 distributionType: DistributionType.Wallet,\n38 allowedDistributor: AllowedDistributor.Permissionless,\n39 subsidizeReceipts: false,\n40}).sendAndConfirm(umi)\n41\n42const [distribution] = findDistributionPda(umi, {\n43 mint,\n44 seed: seed.publicKey,\n45})\n46\n47// Store each recipient's amount, nonce, and proof in your claim service.\n48console.log('Distribution:', distribution)\n49console.log('Proofs:', proofs)\n50\n51// Distribution: <distribution PDA>\n52// Proofs: <one proof array per recipient>\nThe seed signer makes the distribution address unique for a mint, so the same token can have more than one distribution. The resulting PDA uses [\"distribution\", mint, seed], so the seed public key must be retained if the application needs to derive the address again.Allocation Data Is Immutable During ClaimsThe authority cannot change the Merkle root, tree height, start time, or claimant count while startTime <= now <= endTime. Validate and back up the complete allocation file before opening claims.Fund the Wallet DistributionFund the distribution by depositing at least the sum of every allocation into its program-owned associated token account. The current distribution authority must sign deposit.fundDistribution.ts1import {\n2 deposit,\n3 mplDistro,\n4} from '@metaplex-foundation/mpl-distro'\n5import { publicKey } from '@metaplex-foundation/umi'\n6import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n7\n8const umi = createUmi(\n9 process.env.RPC_URL ?? 'https://api.devnet.solana.com'\n10).use(mplDistro())\n11\n12// The Umi identity must be the current distribution authority.\n13\n14const distribution = publicKey(process.env.DISTRIBUTION_ADDRESS!)\n15const mint = publicKey(process.env.TOKEN_MINT!)\n16const totalAmount = 350_000n\n17\n18await deposit(umi, {\n19 distribution,\n20 mint,\n21 amount: totalAmount,\n22}).sendAndConfirm(umi)\n23\n24// The distribution ATA contains 350000 base units.\nThis tutorial deposits tokens only. Optional claim-receipt rent subsidies are covered in Funding and Recovery.Claim the Wallet AllocationClaim an allocation by submitting the same recipient, amount, nonce, and proof generated from the committed list.claimDistribution.ts1import {\n2 distribute,\n3 mplDistro,\n4 prepareDistribution,\n5} from '@metaplex-foundation/mpl-distro'\n6import { publicKey } from '@metaplex-foundation/umi'\n7import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n8\n9const umi = createUmi(\n10 process.env.RPC_URL ?? 'https://api.devnet.solana.com'\n11).use(mplDistro())\n12\n13// The payer may be the recipient or a third-party distributor, depending on\n14// the distribution's allowedDistributor setting.\n15\n16const distribution = publicKey(process.env.DISTRIBUTION_ADDRESS!)\n17const mint = publicKey(process.env.TOKEN_MINT!)\n18const recipients = [\n19 { address: publicKey(process.env.RECIPIENT_1!), amount: 100_000n },\n20 { address: publicKey(process.env.RECIPIENT_2!), amount: 250_000n },\n21]\n22const recipientIndex = 0\n23const { proofs } = prepareDistribution(recipients)\n24\n25await distribute(umi, {\n26 distribution,\n27 mint,\n28 recipient: recipients[recipientIndex].address,\n29 amount: recipients[recipientIndex].amount,\n30 proof: proofs[recipientIndex],\n31 nonce: 0,\n32}).sendAndConfirm(umi)\n33\n34// The recipient ATA receives 100000 base units and a claim receipt is created.\nThe program creates the recipient's canonical associated token account when needed, transfers tokens from the vault, and creates a claim receipt. A second transaction with the same allocation fails with AlreadyClaimed.Verify the MPL-Distro AccountsVerify a claim by fetching the distribution and deterministic claim receipt after confirmation.verifyClaim.ts1import {\n2 fetchClaimReceipt,\n3 fetchDistribution,\n4 findClaimReceiptPda,\n5 mplDistro,\n6} from '@metaplex-foundation/mpl-distro'\n7import { publicKey } from '@metaplex-foundation/umi'\n8import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n9\n10const umi = createUmi(\n11 process.env.RPC_URL ?? 'https://api.devnet.solana.com'\n12).use(mplDistro())\n13\n14const distribution = publicKey(process.env.DISTRIBUTION_ADDRESS!)\n15const recipients = [\n16 { address: publicKey(process.env.RECIPIENT_1!), amount: 100_000n },\n17 { address: publicKey(process.env.RECIPIENT_2!), amount: 250_000n },\n18]\n19const recipientIndex = 0\n20\n21const [receipt] = findClaimReceiptPda(umi, {\n22 distribution,\n23 recipient: recipients[recipientIndex].address,\n24 amount: recipients[recipientIndex].amount,\n25 nonce: 0,\n26})\n27\n28const [distributionAccount, receiptAccount] = await Promise.all([\n29 fetchDistribution(umi, distribution),\n30 fetchClaimReceipt(umi, receipt),\n31])\n32\n33console.log(distributionAccount.claimCount)\n34console.log(receiptAccount.amount)\n35\n36// claimCount includes this allocation and the receipt stores 100000\nCommon MPL-Distro ErrorsMPL-Distro errors identify mismatched proofs, windows, permissions, and vault balances.ErrorCauseResolutionInvalidClaimProofAddress, amount, nonce, or proof differs from the committed leafLoad every value from the same preserved allocation recordDistributionNotStartedThe cluster timestamp is before startTimeWait for the configured Unix timestampDistributionEndedThe cluster timestamp is after endTimeThe authority must create a new distributionAlreadyClaimedThe claim receipt PDA already existsTreat the allocation as completedInsufficientFundsRecorded distribution balance is below the claim amountDeposit more tokens before, during, or after the active window, or review prior withdrawalsRecipientMustSignA recipient-gated claim omitted the recipient signerSubmit with the recipient as a signerInvalidDistributorThe permissioned distributor does not matchUse the configured distributor signerTested ConfigurationThe getting-started flow is based on the current MPL-Distro client tests and generated instruction builders.ComponentVersion@metaplex-foundation/mpl-distro0.4.x@metaplex-foundation/umi1.1.x or newer@metaplex-foundation/mpl-toolbox0.10.xToken programOriginal SPL Token programNotesThe getting-started flow demonstrates a small wallet distribution. Production Delivery covers proof storage, claim pages, and recovering unclaimed tokens.Use Unix timestamps in seconds, not JavaScript milliseconds.Use bigint for token base-unit amounts and timestamps.prepareDistribution switches to a memory-optimized implementation at 1,000 allocations.Run very large allocation builds in a controlled Node.js process and test proof delivery before funding mainnet.A permissionless payer can submit a claim for another wallet, but tokens still go only to that recipient.FAQDoes MPL-Distro create the token mint?No. Create and fund an SPL token mint before creating the distribution.Where should Merkle proofs be stored?Store each address, amount, nonce, and proof in a durable database or claim file because the program stores only the root. See Production Delivery.Can one wallet receive multiple allocations?Yes. Assign a different nonce to each otherwise identical wallet and amount allocation.","tokens":2618,"squid":"dotcat","role":"Tooling Spider","at":1791343302852,"hash":"ab280a92c5ca7987cb6fecaa512b05ce169e7a69"}
{"url":"https://docs.phantom.com/phantom-deeplinks/provider-methods/signalltransactions","domain":"docs.phantom.com","title":"SignAllTransactions - Phantom developer documentation","text":"Once an app is connected, it is also possible to sign multiple transactions at once. Phantom will not submit these transactions to the network. Applications can submit signed transactions using sendRawTransaction in web3.js.\n​Base URL\nhttps://phantom.com/ul/v1/signAllTransactions\n\n​Query string parameters\n\ndapp_encryption_public_key (required): The original encryption public key used from the app side for an existing Connect session.\n\nnonce (required): A nonce used for encrypting the request, encoded in base58.\n\nredirect_link (required): The URI where Phantom should redirect the user upon completion. For more details, see Specify redirects. URL-encoded.\n\npayload (required): An encrypted JSON string with the following fields:\n{\n \"transactions\": [\n \"...\", // serialized transaction, bs58-encoded\n \"...\", // serialized transaction, bs58-encoded\n ],\n \"session\": \"...\", // token received from connect-method\n}\n\ntransactions (required): An array of transactions that Phantom will sign, serialized and encoded in base58.\nsession (required): The session token received from the Connect method. For more details, see Handle sessions.\n\n​Returns\n​Approve\n\nnonce: A nonce used for encrypting the response, encoded in base58.\n\ndata: An encrypted JSON string. Refer to Encryption to learn how apps can decrypt data using a shared secret. Encrypted bytes are encoded in base58.\n// content of decrypted `data`-parameter\n{\n transactions: [\n \"...\", // signed serialized transaction, bs58-encoded\n \"...\", // signed serialized transaction, bs58-encoded\n ] \n}\n\ntransactions: An array of signed, serialized transactions that are base58 encoded. Phantom will not submit these transactions. Applications can submit these transactions themselves using sendRawTransaction in web3.js.\n\n​Reject\nAn errorCode and errorMessage as query parameters. For a full list of possible error codes, see Errors.\n{\n \"errorCode\": \"...\",\n \"errorMessage\": \"...\"\n}\n\n​Example\nRefer to the signAllTransactions method implemented in our React Native demo application.Was this page helpful?","tokens":513,"squid":"spider-10","role":"Tooling Spider","at":1791343303117,"hash":"c0bc0b40d32ceb16aec9d38a933d78a269f519e5"}
{"url":"https://www.metaplex.com/docs/smart-contracts/mpl-distro/wallet-distribution","domain":"metaplex.com","title":"MPL-Distro Wallet Claims and Merkle Proofs","text":"Wallet distributions assign fixed token amounts to public keys and verify each allocation through distribute. SummaryA wallet distribution uses a wallet or other public key as the Merkle leaf identity and always transfers the allocation to that identity's associated token account.Use prepareDistribution to generate compatible roots and proofs.Set a nonce when duplicate recipient-and-amount allocations must remain distinct.Select a distributor mode that matches the application's signing model.Preserve every proof because proofs cannot be reconstructed from the on-chain root alone.Wallet Allocation ShapeEach wallet allocation contains an address, an amount in token base units, and an optional unsigned 64-bit nonce.walletAllocations.ts1import { mplDistro, prepareDistribution } from '@metaplex-foundation/mpl-distro'\n2import { publicKey } from '@metaplex-foundation/umi'\n3import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n4\n5const umi = createUmi(\n6 process.env.RPC_URL ?? 'https://api.devnet.solana.com'\n7).use(mplDistro())\n8\n9const contributorA = publicKey(process.env.RECIPIENT_1!)\n10const contributorB = publicKey(process.env.RECIPIENT_2!)\n11\n12const allocations = [\n13 { address: contributorA, amount: 1_000_000n, nonce: 0n },\n14 { address: contributorB, amount: 2_500_000n, nonce: 0n },\n15]\n16\n17const { root, proofs, treeHeight } = prepareDistribution(allocations)\n18console.log(root, proofs.length, treeHeight)\n19\n20// Merkle root, two proofs, and treeHeight for the wallet allocations\nAmounts must be greater than zero. A nonce defaults to zero and should change only when two leaves would otherwise contain the same address and amount.MPL-Distro Merkle FormatMPL-Distro hashes allocation data with Keccak-256 and sorted internal node pairs.ElementEncodingLeaf data`recipient_pubkey[32]Leaf hash`keccak256(\"claim\"Internal node`keccak256(0x01Odd nodePaired with itselfProof itemOne 32-byte sibling hashMaximum configured height64Use the SDK helper instead of implementing this format independently. A proof generated with SHA-256, big-endian integers, unsorted pairs, or a different domain prefix fails with InvalidClaimProof.Tree Height Is a Proof BoundThe on-chain treeHeight limits proof length; it does not independently verify totalClaimants. Pass the value returned by prepareDistribution.Wallet Claim Submission ModesThe allowedDistributor setting determines which signer may submit distribute.Permissionless Wallet ClaimsPermissionless claims let any funded payer submit a valid proof while the program sends tokens only to the committed recipient.Use this mode for a recipient-paid claim page, or a relayer that pays SOL when someone actually claims. Do not use Distro to push every allocation from a backend; that is usually more expensive than direct SPL transfers.Recipient-Signed Wallet ClaimsRecipient claims require the committed recipient to sign the transaction.Use this mode when the beneficiary must explicitly accept the allocation or when proof access alone must not authorize submission.Permissioned Wallet ClaimsPermissioned claims require the configured permissionedDistributor signer.Use this mode when one backend controls release timing within the broader on-chain claim window. The authority can change the permissioned distributor later.Set the Permissioned Distributor at CreationcreateDistribution defaults permissionedDistributor to the System Program public key. Pass the real distributor address when allowedDistributor is Permissioned, or every claim fails with InvalidDistributor.Submit a Wallet ClaimThe distribute instruction verifies the proof, creates the associated token account when necessary, transfers tokens, and records the receipt atomically.claimDistribution.ts1import {\n2 distribute,\n3 mplDistro,\n4 prepareDistribution,\n5} from '@metaplex-foundation/mpl-distro'\n6import { publicKey } from '@metaplex-foundation/umi'\n7import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n8\n9const umi = createUmi(\n10 process.env.RPC_URL ?? 'https://api.devnet.solana.com'\n11).use(mplDistro())\n12\n13// The payer may be the recipient or a third-party distributor, depending on\n14// the distribution's allowedDistributor setting.\n15\n16const distribution = publicKey(process.env.DISTRIBUTION_ADDRESS!)\n17const mint = publicKey(process.env.TOKEN_MINT!)\n18const recipients = [\n19 { address: publicKey(process.env.RECIPIENT_1!), amount: 100_000n },\n20 { address: publicKey(process.env.RECIPIENT_2!), amount: 250_000n },\n21]\n22const recipientIndex = 0\n23const { proofs } = prepareDistribution(recipients)\n24\n25await distribute(umi, {\n26 distribution,\n27 mint,\n28 recipient: recipients[recipientIndex].address,\n29 amount: recipients[recipientIndex].amount,\n30 proof: proofs[recipientIndex],\n31 nonce: 0,\n32}).sendAndConfirm(umi)\n33\n34// The recipient ATA receives 100000 base units and a claim receipt is created.\nThe payer pays transaction fees, the 0.002 SOL protocol fee, and account rent. See Funding and Recovery for optional claim-receipt rent subsidies.Wallet Claim ReceiptThe claim receipt prevents one exact allocation from being processed more than once.FieldValuePDA seeds[\"claim_receipt\", distribution, recipient, amount_le, nonce_le]Stored distributionDistribution PDAStored recipientWallet or public key from the leafStored amountClaimed token base unitsStored nonceLeaf nonceAccount size88 bytesClaim receipts are permanent in the current program and do not have a close instruction.Claim to a Core Asset SignerdistributeToAssetAndClaim claims a Wallet allocation into an MPL Core asset-signer PDA, then uses Core Execute to move the tokens to the current owner.Build the Merkle leaves from each asset's signer PDA, not from owner wallets. The helper then transfers the claimed tokens out of that PDA's associated token account.claimToCoreAsset.ts1import { findAssetSignerPda } from '@metaplex-foundation/mpl-core'\n2import {\n3 distributeToAssetAndClaim,\n4 mplDistro,\n5 prepareDistribution,\n6} from '@metaplex-foundation/mpl-distro'\n7import { publicKey } from '@metaplex-foundation/umi'\n8import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n9\n10const umi = createUmi(\n11 process.env.RPC_URL ?? 'https://api.devnet.solana.com'\n12).use(mplDistro())\n13\n14const distribution = publicKey(process.env.DISTRIBUTION_ADDRESS!)\n15const mint = publicKey(process.env.TOKEN_MINT!)\n16const asset = publicKey(process.env.CORE_ASSET!)\n17const currentOwner = publicKey(process.env.CORE_ASSET_OWNER!)\n18\n19const [assetSigner] = findAssetSignerPda(umi, { asset })\n20const allocations = [{ address: assetSigner, amount: 100_000n }]\n21const { proofs } = prepareDistribution(allocations)\n22\n23await distributeToAssetAndClaim(umi, {\n24 distribution,\n25 mint,\n26 asset,\n27 recipient: currentOwner,\n28 amount: allocations[0].amount,\n29 proof: proofs[0],\n30 nonce: 0,\n31}).sendAndConfirm(umi)\n32\n33// Tokens are claimed to the asset-signer PDA, then transferred to the current owner.\nThis helper is a Wallet distribution flow. It is not a LegacyNft claim and does not validate Core collection membership on-chain.Wallet Distribution Security ChecklistA production wallet distribution should validate allocation integrity before publishing the root.Confirm the sum of allocations does not exceed the planned deposit.Reject zero, negative, or out-of-range amounts before calling the SDK.Assign deterministic nonces and store them with proofs.Test random proofs and every edge allocation against the final root.Keep authority and permissioned-distributor keys outside browser applications.Confirm cluster timestamps and leave operational time around the start and end boundaries.NotesWallet distributions can use any public key as a leaf identity, but the default destination is its SPL token associated token account.Core asset claims use distributeToAssetAndClaim and require the asset-signer PDA in the Merkle leaf.totalClaimants is not an on-chain claim cap.A valid proof can still fail when the vault lacks tokens.Claims are accepted at both exact boundary timestamps: startTime <= now <= endTime.FAQCan a backend submit a claim without the recipient signing?Yes. A Permissionless distribution lets a relayer pay SOL and submit the proof. Tokens still go to the leaf address. Use this so recipients without SOL can claim, not to replace a bulk SPL transfer.What prevents the same wallet allocation from being claimed twice?A deterministic claim receipt PDA records each unique distribution, recipient, amount, and nonce tuple.Does totalClaimants limit successful claims?No. totalClaimants is metadata; Merkle inclusion and available vault funds determine whether an allocation can claim.What address belongs in a Core asset allocation leaf?Use the Core asset-signer PDA. distributeToAssetAndClaim then moves the tokens to the current owner.","tokens":2205,"squid":"dotcat","role":"Tooling Spider","at":1791343312752,"hash":"4bd7200f517327c070a6a9ad89a7e97afbcf52ec"}
{"url":"https://docs.switchboard.xyz/tooling/crossbar/api-endpoints","domain":"docs.switchboard.xyz","title":"Crossbar API Endpoints | Switchboard Documentation","text":"For the complete documentation index, see llms.txt. This page is also available as Markdown.This page documents the HTTP and WebSocket endpoints exposed by Crossbar.Base URL examples:Public: https://crossbar.switchboard.xyzLocal: http://localhost:8080For machine-readable schema and live testing:Swagger UI: GET /docsOpenAPI JSON: GET /api-docs/openapi.jsonCore EndpointsMethodPathPurposeGET/healthHealth checkGET/versionService version infoGET/testBasic test endpointGET/protos/job_schemas.protoOracle job protobuf schemaPOST/storeStore v1 feed definitionGET/fetch/{hash}Fetch v1 feed definitionPOST/v2/storeStore v2 feed definitionGET/v2/fetch/{feed_id}Fetch v2 feed definitionGET/v2/update/{feedHashes}Build v2 multi-feed update payloadANY/rpc/{network}RPC passthrough/proxy endpointGET/debug/cid/{hash}CID conversion/debugGET/debug/bnbBinance debug endpointParameter units are surface-specific. Raw v2 OracleFeed.maxJobRangePct and raw gateway max_variance values are percentages scaled by 1e9; 1_000_000_000 means 1%. See Feed Parameter Units.Use /v2/fetch/{feed_id} for v2 feed IDs created by Feed Builder or Crossbar v2 storage. The older /fetch/{hash} route is for v1 feed definitions and legacy compatibility.EVM Route SelectionUse different Crossbar routes depending on whether you are integrating a current Feed Builder/custom feed or an older aggregator-based EVM integration.Use caseUse these routesIdentifierNotesFeed Builder/custom feed on EVM/v2/fetch/{feed_id}, /v2/simulate/{feedHashes}, /v2/update/{feedHashes}deterministic bytes32 feed ID / feed hashRecommended flow for Monad and current custom-feed integrations. Use chain=evm, `network=mainnetLegacy aggregator-based EVM integration/simulate/evm/{network}/{aggregator_ids}, /updates/evm/{chainId}/{aggregatorIds}legacy aggregator IDCompatibility flow for older EVM integrations. Do not use this as the primary path for Feed Builder custom feeds.Solana/SVM Route SelectionFor new Solana/SVM feed-hash integrations, prefer the SDK managed update path: queue.fetchManagedUpdateIxs(...). It fetches Ed25519 oracle signatures and builds the quote-program verified_update instruction that writes the canonical OracleQuote account.The classic PullFeed.fetchUpdateIx(...) and Crossbar /updates/solana/... flows target legacy PullFeed accounts and pullFeedSubmitResponseConsensus. Use them only for existing classic PullFeed integrations where the selected queue/gateway environment supports that path.Simulation EndpointsGenericMethodPathPurposePOST/simulateSimulate jobs from request bodyPOST/simulate/jobsAlias for /simulateGET/simulate/{feedHashes}Simulate comma-separated feed hashesChain-specificMethodPathPurposePOST/simulate/solanaSimulate Solana feedsGET/simulate/solana/{network}/{feedpubkeys}Simulate Solana feed pubkeysPOST/simulate/eclipseSimulate Eclipse feedsGET/simulate/eclipse/{network}/{feedpubkeys}Simulate Eclipse feed pubkeysPOST/simulate/evmSimulate EVM aggregatorsGET/simulate/evm/{network}/{aggregator_ids}Simulate EVM aggregator IDsPOST/simulate/aptosSimulate Aptos feedsGET/simulate/aptos/{network}/{feedhashes}Simulate Aptos feed hashesPOST/simulate/suiSimulate Sui feedsPOST/simulate/sui/feedsAlias for Sui simulationGET/simulate/sui/{network}/{feedids}Simulate Sui feed IDsPOST/simulate/iotaSimulate Iota feedsGET/simulate/iota/{network}/{feedids}Simulate Iota feed IDsV2 simulationMethodPathPurposePOST/v2/simulateSimulate v2 feed input payloadGET/v2/simulate/{feedHashes}Simulate v2 feed hashesPOST/v2/simulate/protoSimulate base64-encoded OracleFeed protoBackward-compatible API prefixCrossbar also exposes simulation routes under /api/simulate for compatibility.\nExample: POST /api/simulate, GET /api/simulate/{feedHashes}.Update EndpointsMethodPathPurposeGET/updates/solana/{network}/{feedPubkeys}Solana update instructions and oracle responsesGET/updates/eclipse/{network}/{feedPubkeys}Eclipse update instructions and oracle responsesGET/updates/evm/{chainId}/{aggregatorIds}EVM encoded updatesGET/updates/evm/fetch_update_data/{chain_id}/{feed_ids}EVM update-data variantGET/updates/aptos/{network}/{aggregatorAddresses}Aptos aggregator updatesGET/updates/sui/{network}/{aggregatorAddresses}Sui aggregator updatesGET/updates/iota/{network}/{aggregatorAddresses}Iota aggregator updatesGateway EndpointsMethodPathPurposeGET`/gateways?network=mainnetdevnetPOST/gateways/fetch_signaturesFetch signatures (single feed/job request)POST/gateways/fetch_signatures_consensusFetch consensus signaturesOracle and Guardian EndpointsMethodPathPurposeGET/oraclesList Solana oraclesGET/oracles/suiList Sui oraclesGET/oracles/aptosList Aptos oraclesPOST/oracles/fetch_signaturesFetch oracle signaturesGET/guardiansList guardiansRandomness EndpointsMethodPathPurposePOST/randomness/evmFetch EVM randomness result payloadStream (Surge) EndpointsMethodPathPurposeGET/stream/wsWebSocket stream endpointGET/stream/surge_feedsList available Surge feedsPOST/stream/request_sessionCreate Surge stream session tokenGET/stream/socket_metricsStream/socket metricsGET/stream/debug_binanceBinance stream debug infoLegacy Surge endpoints are also exposed when Surge is enabled:MethodPathPurposeGET/v1/surge/streamLegacy Surge WebSocket endpointPOST/v1/surge/sessionLegacy Surge session endpointFlamegraph EndpointsMethodPathPurposeGET/flamegraphFlamegraph status/infoPOST/flamegraph/startStart profilingPOST/flamegraph/stopStop profilingGET/flamegraph/uiFlamegraph UIDetailed Request/Response ReferenceUse this section for implementation-level request and response shapes. The tables above remain the quick index.SimulationPOST /simulate/jobsPurpose: simulate raw OracleJob[] directly (without fetching feed definitions from IPFS).Request body:{\n \"jobs\": [\n {\n \"tasks\": [\n { \"valueTask\": { \"value\": 42 } }\n ]\n }\n ],\n \"includeReceipts\": true,\n \"variableOverrides\": {\n \"API_KEY\": \"...\"\n },\n \"network\": \"mainnet\"\n}Response (200):{\n \"feedHash\": \"direct\",\n \"results\": [\"42\"],\n \"receipts\": [\"...\"],\n \"error\": null\n}Notes:jobs also accepts base64-encoded protobuf entries.variableOverrides is optional.network defaults to mainnet when omitted.POST /simulate/solanaPurpose: simulate one or more Solana feed pubkeys by loading on-chain feed state, resolving feed hash, loading jobs from IPFS, and running jobs.Request body:{\n \"feeds\": [\n \"6dJY6fNn7q7eYxw8fPqfF7XULg1Wm3v3GJm6M6hQ8B9X\"\n ],\n \"network\": \"mainnet-beta\",\n \"includeReceipts\": false\n}Response (200): array of per-feed simulation results.[\n {\n \"feed\": \"6dJY6fNn7q7eYxw8fPqfF7XULg1Wm3v3GJm6M6hQ8B9X\",\n \"feedHash\": \"617c43b30c588de5e620fa4c7b932e103301b9a160e2c24be69dbe0357e45797\",\n \"results\": [\"1.2345\", \"1.2351\", \"1.2339\"],\n \"receipts\": null,\n \"result\": \"1.2345\",\n \"stdev\": \"0.00049\",\n \"variance\": \"0.00024\",\n \"error\": null\n }\n]Notes:network accepts values such as mainnet-beta, devnet, testnet.mainnet is normalized to mainnet-beta.GET /simulate/{feedHashes}Purpose: simulate one or more feed hashes directly from IPFS definitions.Path:feedHashes: comma-separated feed hashesQuery:includeReceipts (bool, optional)Response (200): array[\n {\n \"feedHash\": \"617c43b30c588de5e620fa4c7b932e103301b9a160e2c24be69dbe0357e45797\",\n \"results\": [\"1.2345\", \"1.2351\"],\n \"receipts\": null,\n \"error\": null\n }\n]POST /v2/simulatePurpose: simulate v2 feed hashes with optional network and variable overrides.Request body:{\n \"feedHashes\": [\n \"617c43b30c588de5e620fa4c7b932e103301b9a160e2c24be69dbe0357e45797\"\n ],\n \"includeReceipts\": false,\n \"variableOverrides\": {\n \"API_KEY\": \"...\"\n },\n \"network\": \"mainnet\"\n}Response (200):{\n \"feeds\": [\n {\n \"feedHash\": \"617c43b30c588de5e620fa4c7b932e103301b9a160e2c24be69dbe0357e45797\",\n \"feedName\": \"MINO/USD\",\n \"results\": [\"1.2345\"],\n \"receipts\": null,\n \"variableOverrides\": {\n \"API_KEY\": \"...\"\n },\n \"network\": \"mainnet\"\n }\n ],\n \"totalFeeds\": 1,\n \"successfulFeeds\": 1,\n \"failedFeeds\": 0\n}UpdatesGET /v2/update/{feedHashes}Purpose: build a chain-specific consensus payload for one or more v2 feed hashes.Path:feedHashes: comma-separated deterministic feed IDs / feed hashesQuery:chain (string, required for chain-specific payloads; use evm for EVM)network (string, optional; mainnet or testnet)use_timestamp (bool, optional)num_oracles (u32, optional)gateway (string, optional)Response (200): object{\n \"medianResponses\": [\n {\n \"value\": \"123450000000000000000\",\n \"feedHash\": \"0xfd2b067707a96e5b67a7500e56706a39193f956a02e9c0a744bf212b19c7246c\",\n \"numOracles\": 3\n }\n ],\n \"oracleResponses\": [],\n \"timestamp\": 1730000000,\n \"slot\": 0,\n \"recentHash\": \"0xabc123...\",\n \"encoded\": \"0x8f6f2b7c...\"\n}V2 update response schema:medianResponses: one consensus value per requested feed hashoracleResponses: per-oracle response detailtimestamp: signed consensus timestampslot: slot or sequence metadata from the gatewayrecentHash: recent hash used for the signed payloadencoded: chain-specific encoded update payloadFor EVM, wrap encoded into a one-element bytes[] when calling getFee or updateFeeds.Monad example:curl \"http://localhost:8080/v2/update/0x4cd1cad962425681af07b9254b7d804de3ca3446fbfd1371bb258d2c75059812?chain=evm&network=testnet&use_timestamp=true\"GET /updates/solana/{network}/{feedPubkeys}Purpose: generate Solana pull update instructions and oracle response metadata.Path:network: mainnet, mainnet-beta, devnet, testnetfeedPubkeys: comma-separated feed pubkeysQuery:numSignatures (u32, optional)payer (string, required)Response (200): array of update objects[\n {\n \"success\": true,\n \"pullIxns\": [\n \"0673bd46f2e47e04f12bd92fb731968ecd9d9757c274da87476f465c040c6573050000000000000089e0fecf1c1b3a11e77b9d1048192288ae1d8ada0e19ff95d737c4e5afb583f70001d284bd424eb258f1f502c95ff334245b64af7df6b14435d1ea46d10fb3ac68b6000086807068432f186a147cf0b13a30067d386204ea9d6c8b04743ac2ef010b075200007752c55e8b0a7079ad51975736764e45f56d61ebd15aa96d55f7ca86d5b5e387010100000000000000000000000000000000000000000000000000000000000000000000310000000000000001020304050607081d3c620d5670b1b26d0d3c7c27cb75a5187d99b8ccf8850d5b79d573b81bff7c030000009600000000\"\n ],\n \"responses\": [\n {\n \"oracle\": \"9pPCSotuPGUDgdYUtngMCemNi3KHdWFvwLhqx57KkbXb\",\n \"result\": 1.1067679409326794,\n \"errors\": \"\"\n }\n ],\n \"lookupTables\": [\n \"A43DyUGA7s8eXPxqEjJY6EBu1KKbNgfxF8h17VAHn13w\"\n ]\n }\n]pullIxns wire format:Each array entry is a hex-encoded bincode serialization of solana_sdk::instruction::Instruction.Raw HTTP responses return these serialized strings directly.SDK helpers such as CrossbarClient.fetchSolanaUpdates may decode them into native instruction objects before returning to your application.lookupTables are still returned separately for address lookup table usage in versioned transactions.Rust decode example:use solana_sdk::instruction::Instruction;\n\nfn decode_instruction(ix_hex: &str) -> anyhow::Result<Instruction> {\n let bytes = hex::decode(ix_hex)?;\n Ok(bincode::deserialize(&bytes)?)\n}GET /updates/eclipse/{network}/{feedPubkeys}Response schema is the same as /updates/solana/{network}/{feedPubkeys}:success: boolpullIxns: array of hex-encoded serialized Instruction valuesresponses: array of oracle responseslookupTables: array of address lookup table pubkeys (base58)GET /updates/evm/{chainId}/{aggregatorIds}Purpose: fetch EVM-compatible encoded updates and supporting oracle response data.Path:chainId: EVM chain ID (example 1, 42161, 1116)aggregatorIds: comma-separated feed IDsQuery:numSignatures (u32, optional)gateway (string, optional)Response (200): object{\n \"results\": [\n {\n \"result\": \"123450000000000000000\"\n }\n ],\n \"failures\": [],\n \"encoded\": [\n \"0x8f6f2b7c...\"\n ]\n}EVM response schema:results: array of oracle response objects (includes normalized result and additional gateway-returned fields).failures: array of errors for feeds/oracles that failed during fetch/update building.encoded: array of 0x-prefixed ABI-encoded update payloads.GET /updates/aptos/{network}/{aggregatorAddresses}Response (200):{\n \"responses\": [\n {\n \"responses\": [],\n \"failures\": [],\n \"encoded\": [\n \"0x...\"\n ]\n }\n ],\n \"failures\": [],\n \"encoded\": [\n \"0x...\"\n ]\n}Aptos response schema:responses: per-aggregator update objects returned by Aptos SDK.failures: top-level route errors.encoded: flattened list of encoded Aptos update payloads.GET /updates/sui/{network}/{aggregatorAddresses}Response (200):{\n \"responses\": [\n {\n \"results\": [],\n \"failures\": []\n }\n ],\n \"failures\": []\n}Sui response schema:responses: per-aggregator update objects returned by Sui SDK (fetchUpdateInfo output).failures: top-level route errors.GET /updates/iota/{network}/{aggregatorAddresses}Response (200) matches the Sui endpoint shape:{\n \"responses\": [\n {\n \"results\": [],\n \"failures\": []\n }\n ],\n \"failures\": []\n}GatewaysGET /gatewaysPurpose: discover active gateway URLs from cached oracle state.Query:network: mainnet (default), devnet, or testnetResponse (200):[\n \"https://gateway-1.example.com\",\n \"https://gateway-2.example.com\"\n]POST /gateways/fetch_signaturesPurpose: fetch signatures for a single feed/jobs request. Supports both legacy and new request shapes.maxVariance in these raw gateway request bodies is already scaled by 1e9; 50_000_000 means 0.05%.Legacy body (feed-hash based):{\n \"feedHash\": \"617c43b30c588de5e620fa4c7b932e103301b9a160e2c24be69dbe0357e45797\",\n \"numSignatures\": 3,\n \"maxVariance\": 50000000,\n \"minResponses\": 1,\n \"useTimestamp\": true\n}New body (jobs-based):{\n \"apiVersion\": \"1\",\n \"jobsB64Encoded\": [\"...\"],\n \"numOracles\": 3,\n \"maxVariance\": 50000000,\n \"minResponses\": 1,\n \"useTimestamp\": true\n}Response (200): gateway signature response object (signatures + timestamp + variance).POST /gateways/fetch_signatures_consensusPurpose: fetch consensus signatures using feed request objects.Request body:{\n \"apiVersion\": \"1\",\n \"feedRequests\": [],\n \"numOracles\": 3,\n \"useTimestamp\": true\n}Response (200):{\n \"signatures\": [],\n \"timestamp\": 1730000000,\n \"variance\": 0,\n \"consensusReached\": true\n}Stream (Surge)GET /stream/surge_feedsPurpose: list currently available Surge feed symbols.Query:symbol (optional)exchange (optional)Response (200): feed list object from Surge core. Response (503): no feeds available.POST /stream/request_sessionPurpose: validate API key and create session token + WebSocket URL.Auth input:Header x-api-key: <key> preferredAlso supports Authorization: Bearer <key>Also supports query param api_key=<key>Request body:{\n \"client_ip\": \"203.0.113.10\"\n}Response (200):{\n \"session_token\": \"...\",\n \"simulator_ws_url\": \"wss://.../v1/surge/stream\"\n}Error responses:400 missing API key401 invalid API keyGET /stream/wsPurpose: WebSocket stream endpoint for Surge updates.\nFor full handshake, auth headers, subscribe payload, and ping/pong flow, see Surge Gateway Protocol.Minimal curl examplesSimulate Solana feed:curl -X POST http://localhost:8080/simulate/solana \\\n -H \"Content-Type: application/json\" \\\n -d '{\n \"feeds\": [\"6dJY6fNn7q7eYxw8fPqfF7XULg1Wm3v3GJm6M6hQ8B9X\"],\n \"network\": \"mainnet-beta\",\n \"includeReceipts\": false\n }'Fetch EVM updates:curl \"http://localhost:8080/updates/evm/1116/0xfd2b067707a96e5b67a7500e56706a39193f956a02e9c0a744bf212b19c7246c\"Fetch a Monad custom-feed payload with the v2 route:curl \"http://localhost:8080/v2/update/0x4cd1cad962425681af07b9254b7d804de3ca3446fbfd1371bb258d2c75059812?chain=evm&network=testnet&use_timestamp=true\"Discover gateways:curl \"http://localhost:8080/gateways?network=mainnet\"Public Rate LimitsFor https://crossbar.switchboard.xyz, rate limiting is layered and route-dependent:SurfacePublic limit behaviorSourceNetwork-level Switchboard oracle requestsDefault 20 requests/second per user wallet; can be increased with stakeThe Switchboard NCNCrossbar public REST (/updates/*, gateway/signature routes)Additional IP-based edge throttling; 429 Too Many Requests can appear under burst trafficPublic endpoint behavior, observed on March 3, 2026Surge WebSocket accessPlan-based max connections (Plug: 1, Pro: 10, Enterprise: 15)Surge pricing and limitsOperational guidance:Keep update polling conservative on public Crossbar and avoid burst fan-out.On 429, apply exponential backoff with jitter and retry.For steady high-throughput workloads, self-host Crossbar.NotesSome stream and gateway flows require signature/auth headers. See Surge Gateway Protocol.Endpoint behavior can vary by network and environment configuration.Public Crossbar is rate limited by IP. Production systems should self-host.For complete machine schema and current field contracts, use GET /api-docs/openapi.json.PreviousRun Crossbar with Docker ComposeNextSurge Gateway ProtocolLast updated 3 months ago","tokens":4113,"squid":"spider-08","role":"Oracle Spider","at":1791343315985,"hash":"7345271b49fa4a11020a90f61290451b290757ed"}
{"url":"https://docs.phantom.com/phantom-deeplinks/provider-methods/signtransaction","domain":"docs.phantom.com","title":"SignTransaction - Phantom developer documentation","text":"Request Phantom to sign the prepared transaction and return the signature. After receiving the signature, your app can broadcast the transaction itself with sendRawTransaction in web3.js, giving you full control over timing, batching, or custom error handling.\n​Base URL\nhttps://phantom.com/ul/v1/signTransaction\n\n​Query string parameters\n\ndapp_encryption_public_key (required): The original encryption public key used from the app side for an existing Connect session.\n\nnonce (required): A nonce used for encrypting the request, encoded in base58.\n\nredirect_link (required): The URI where Phantom should redirect the user upon completion. For more details, see Specify redirects. URL-encoded.\n\npayload (required): An encrypted JSON string with the following fields:\n{\n \"transaction\": \"...\", // serialized transaction, base58 encoded\n \"session\": \"...\", // token received from connect-method\n}\n\ntransaction (required): The transaction that Phantom will sign, serialized and encoded in base58.\nsession (required): The session token received from the Connect method. For more details, see Handle sessions.\n\n​Returns\n​Approve\n\nnonce: A nonce used for encrypting the response, encoded in base58.\n\ndata: An encrypted JSON string. Refer to Encryption to learn how apps can decrypt data using a shared secret. Encrypted bytes are encoded in base58.\n// content of decrypted `data`-parameter\n{\n transaction: \"...\", // signed serialized transaction, base58 encoded\n}\n\ntransaction: The signed, serialized transaction that is base58 encoded. Phantom will not submit this transaction. An application can submit this transaction itself using sendRawTransaction in web3.js.\n\n​Reject\nAn errorCode and errorMessage as query parameters. For a full list of possible error codes, see Errors.\n{\n \"errorCode\": \"...\",\n \"errorMessage\": \"...\"\n}\n\n​Example\nRefer to the signTransaction method implemented in our React Native demo application.Was this page helpful?","tokens":484,"squid":"spider-10","role":"Tooling Spider","at":1791343325115,"hash":"e8afce9c42fcfbafa90408d982e5950997b94118"}
{"url":"https://docs.phantom.com/resources/faq","domain":"docs.phantom.com","title":"FAQ - Phantom developer documentation","text":"​Phantom Connect and SDKs\n​What is Phantom Connect?\nPhantom Connect is the recommended way to integrate Phantom into your app. It provides a unified authentication experience using social login (Google or Apple) or browser extension connection. Phantom Connect is available through our SDKs:\n\nReact SDK for React web apps\nReact Native SDK for mobile apps\nBrowser SDK for vanilla JavaScript\n\n​What’s the difference between embedded and extension wallets?\nEmbedded wallets are created through Phantom Connect using social login (Google or Apple). Users don’t need to install any browser extension—the wallet is managed by Phantom and accessible across devices.\nExtension wallets are traditional self-custody wallets where users install the Phantom browser extension or mobile app and manage their own recovery phrase.\nPhantom Connect supports both. Configure the providers array on the SDK with \"google\" and/or \"apple\" to create embedded wallets via social login, and add \"injected\" to let users connect their installed Phantom browser extension or other injected wallet.\n​Which SDK should I use?\nYour app typeRecommended SDKReact web appReact SDKNext.js appReact SDKReact Native / Expo mobile appReact Native SDKVanilla JavaScript / other frameworksBrowser SDK\n​Do I need to set up Phantom Portal?\nPhantom Portal is not accepting new applications at this time. New sign-ups for Phantom Connect SDK access and new app submissions to the Phantom app directory are paused. Existing Portal apps and App IDs are not affected.\nYes. Before using any Phantom Connect SDK, you need an existing Phantom Portal app:\n\nSign in to Phantom Portal\nOpen your app and configure your branding\nConfigure allowed origins and redirect URLs\nGet your App ID\n\nDomain verification is not required to use Phantom Connect during development. Verify your domain before going to production, allowing users outside your team to connect, or listing your app in Phantom’s Explore tab and search results.\n​Which blockchains does Phantom Connect support?\nFor new integrations, Phantom Connect supports Solana, Ethereum, Polygon, Base, and Arbitrum. You can enable multiple chains simultaneously by configuring addressTypes in your SDK setup.\nSui support has been deprecated.\n​Can users connect with both social login and extension?\nYes. Phantom Connect handles both authentication methods. When a user connects, they can choose to sign in with Google/Apple (embedded wallet) or connect their existing Phantom extension wallet.\n​Browser extension integration\n​Why can’t I access Phantom on my website?\nPhantom will only inject its provider into websites that begin with https://, or if the host is localhost or 127.0.0.1. If your website only uses http://, Phantom will not inject its provider and you will not be able to access the methods found at window.phantom. Encrypting your web traffic and upgrading to https:// will restore functionality.\nPhantom will also not inject its provider into any iframe.\nFor new integrations, we recommend using Phantom Connect SDKs instead of directly accessing the browser extension provider. The SDKs handle provider detection, connection state, and authentication automatically.\n​Does the EVM provider support Robinhood Chain?\nYes. Robinhood Chain is supported through the EIP-1193 provider at window.phantom.ethereum. Mainnet uses chain ID 4663 (0x1237), and Robinhood Chain Testnet uses chain ID 46630 (0xb626). Enable Testnet Mode before using the testnet, and see Get started with EVM networks for integration details.\n​Does the EVM provider support Arc?\nYes. Arc is supported through the EIP-1193 provider at window.phantom.ethereum. Mainnet uses chain ID 5042 (0x13b2), and Arc Testnet uses chain ID 5042002 (0x4cef52). Enable Testnet Mode before using the testnet, and see Get started with EVM networks for integration details.\n​Are hardware wallets supported?\nYes, Phantom currently supports Ledger hardware wallets and requires no special treatment on the application side.\n​Tokens and NFTs\n​Why isn’t my token displaying properly?\nPhantom supports the Token Metadata Standard established by Metaplex. When displaying tokens, Phantom will first categorize them according to their TokenStandard. If a token is considered Fungible, Phantom will display it on the Home tab. Otherwise, Phantom will display it as a Collectible. For more details, see Display tokens on Solana.\n​What types of NFTs are supported?\nPhantom supports a range of NFT media types including images, audio files, video files, and 3D models. At this time, Phantom does not support HTML files. For a full list of the types of NFTs that Phantom can display, see Supported media types.\n​Wallet behavior\n​How does Phantom import wallet addresses?\nWhen importing addresses from an existing recovery phrase (also known as a seed phrase), Phantom will scan for 20 addresses in each of our three supported derivation paths (bip44change, bip44, and a deprecated path), for a total of 60 addresses. For the convenience of the user, Phantom will filter this list of addresses down to wallets that have ever had signatures (have ever been used). Phantom will then sort this filtered list based on how many signatures each wallet has had plus the amount of lamports it currently owns.\n​Why does Phantom prepend an additional instruction on standard SPL token transfers?\nWhen transferring SPL tokens, Phantom will first double check if a token account exists for the recipient you are sending to. If one does not exist, Phantom will help you create an Associated Token Account on the recipient’s behalf. To do this check, Phantom calls a deployment of the Serum Assert Owner program. The program address of this deployment is DeJBGdMFa1uynnnKiwrVioatTuHmNLpyFKnmB5kaFdzQ and is available on Solana’s Devnet, Testnet, and Mainnet. This program has been in use since 2021. It was deployed by the Phantom team to keep this program address consistent across networks.\n​Troubleshooting\n​Why am I seeing a “new domain” warning?\nWhen your app or website is newly launched, Phantom may show users a warning that the domain is new or has not been reviewed. This warning typically disappears automatically after a few days. If the warning persists for more than a week, see Domain and transaction warnings for next steps.\n​Why is my transaction showing a security warning?\nIf Phantom can’t accurately simulate a transaction, users may see a warning message. This can happen when:\n\nThe transaction has multiple signers\nThe transaction approaches Solana’s size limit\nThe transaction would fail during simulation\n\nSee Domain and transaction warnings for detailed guidance on resolving these warnings.\n​How do I debug my app in Phantom’s mobile browser?\nYou can debug mobile web apps using your desktop browser’s developer tools. See Mobile web debugging for step-by-step instructions for iOS and Android.\n​Need more help?\nWas this page helpful?","tokens":1724,"squid":"spider-10","role":"Tooling Spider","at":1791343335216,"hash":"688a57d25d826ff1b69ad29f048e5c731b18258c"}
{"url":"https://pyth.network/","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":"spider-08","role":"Oracle Spider","at":1791343339705,"hash":"094bdbaaf7154d6cd8c641b4f392e87528ee6d59"}
{"url":"https://developer.arbitrum.io/arbitrum-essentials/bridging/withdraw/eth-and-messages","domain":"developer.arbitrum.io","title":"How to bridge from child chain to parent chain","text":"BridgingWithdraw (child → parent)How to bridge from child chain to parent chainStep-by-step guide to programmatically withdraw ETH and send messages from an Arbitrum child chain to Ethereum using ArbSys and the Outbox contract.Request an updateThis guide explains how to programmatically send messages and withdraw assets from an to a (such as Ethereum). For conceptual information about the messaging protocol, see Child-to-parent chain messaging.\nPrerequisites\n\nA child chain with funds\nAccess to parent chain infrastructure (for executing the final step)\nAwareness that child-to-parent messages require 6.4 days to finalize\n\nOverview of the process\nChild-to-parent chain messaging follows these steps:\n\nSend message on child chain: Call ArbSys.sendTxToL1 to initiate the message\nWait for finalization: The message enters a 6.4-day \nExecute on parent chain: After finalization, call Outbox.executeTransaction to complete the transfer\n\nSending a message from the child to the parent chain\nTo send a message from the child chain to the parent chain, use the ArbSys precompile's sendTxToL1 method:\nfunction sendTxToL1(\n address destination,\n bytes calldata data\n) external payable returns (uint256)\nParameters\n\ndestination: The parent chain address that will receive the message\ndata: Calldata to send to the destination address on the parent chain\n\nReturn value\nReturns a unique identifier for the message, used to track its status and construct the proof for execution.\nThe ArbSys precompile is located at address 0x0000000000000000000000000000000000000064.\nExample: Sending a simple message\nconst arbSys = new ethers.Contract('0x0000000000000000000000000000000000000064', arbSysABI, childChainSigner);\n\nconst tx = await arbSys.sendTxToL1(parentChainDestination, ethers.utils.toUtf8Bytes('Hello from L2!'));\nconst receipt = await tx.wait();\nExecuting the message on the parent chain\nAfter the 6.4-day challenge period, you can execute the message on the parent chain.\nStep 1: Retrieve proof data\nUse the NodeInterface contract to get the Merkle proof:\nfunction constructOutboxProof(\n uint64 size,\n uint64 leaf\n) external view returns (\n bytes32[] memory proof,\n uint256 path,\n address l2Sender,\n address l1Dest,\n uint256 l2Block,\n uint256 l1Block,\n uint256 timestamp,\n uint256 amount,\n bytes memory calldataForL1\n)\nParameters:\n\nsize: The number containing your message\nleaf: The index of your message within the batch (0-indexed)\n\nExample usage:\nconst nodeInterface = new ethers.Contract('0x00000000000000000000000000000000000000C8', nodeInterfaceABI, childChainProvider);\n\nconst proofData = await nodeInterface.constructOutboxProof(batchNumber, indexInBatch);\nNoteNodeInterface is a \"virtual\" contract accessible at 0x00000000000000000000000000000000000000C8. It isn't a true precompile but provides Arbitrum-specific data without requiring a custom RPC.\nStep 2: Execute on the parent chain\nCall Outbox.executeTransaction with the proof data from Step 1:\nfunction executeTransaction(\n bytes32[] calldata proof,\n uint256 path,\n address l2Sender,\n address l1Dest,\n uint256 l2Block,\n uint256 l1Block,\n uint256 timestamp,\n uint256 amount,\n bytes calldata calldataForL1\n) external\nAll parameters come from the constructOutboxProof call. The method executes the message at the l1Dest address with the provided calldata and amount.\nExample usage:\nconst outbox = new ethers.Contract(outboxAddress, outboxABI, parentChainSigner);\n\nconst tx = await outbox.executeTransaction(proofData.proof, proofData.path, proofData.l2Sender, proofData.l1Dest, proofData.l2Block, proofData.l1Block, proofData.timestamp, proofData.amount, proofData.calldataForL1);\nawait tx.wait();\nWithdrawing ETH\nTo withdraw ETH from the child chain, use the ArbSys precompile's withdrawEth method:\nfunction withdrawEth(\n address destination\n) external payable returns (uint256)\nParameters\n\ndestination: The parent chain address that will receive the ETH\nValue (msg.value): The amount of ETH to withdraw from the child chain\n\nReturn value\nReturns a unique identifier for the withdrawal message.\nHow ETH withdrawal works\n\nOn the child chain: The ETH balance is burned, and a message is created\nChallenge period: Wait 6.4 days for the to finalize\nOn the parent chain: Execute via Outbox.executeTransaction to claim your ETH\n\nArbSys.withdrawEth is equivalent to calling ArbSys.sendTxToL1 with an empty calldata argument. Like any child-to-parent message, it requires executing on the parent chain after the dispute period.\nExample: withdrawing ETH\nconst arbSys = new ethers.Contract('0x0000000000000000000000000000000000000064', arbSysABI, childChainSigner);\n\n// Withdraw 0.1 ETH\nconst tx = await arbSys.withdrawEth(parentChainAddress, {\n value: ethers.utils.parseEther('0.1'),\n});\nconst receipt = await tx.wait();\n\n// After 6.4 days, execute on parent chain using the steps above\nThe withdrawal process:\n\nWithdrawing ERC-20 tokens\nFor ERC-20 token withdrawals, see the dedicated Withdraw tokens guide, which provides detailed instructions for using Arbitrum's canonical token .\nUsing the Arbitrum SDK\nThe Arbitrum SDK simplifies child-to-parent messaging:\nimport { ChildToParentMessageStatus, ChildTransactionReceipt } from '@arbitrum/sdk';\n\n// Get the L2 transaction receipt\nconst l2Receipt = await childChainProvider.getTransactionReceipt(l2TxHash);\nconst childTxReceipt = new ChildTransactionReceipt(l2Receipt);\n\n// Get child-to-parent messages from the transaction\nconst messages = await childTxReceipt.getChildToParentMessages(parentChainSigner);\n\n// Wait for the message to be executable\nconst message = messages[0];\nawait message.waitUntilReadyToExecute(childChainProvider);\n\n// Execute the message on the parent chain\nconst executeResult = await message.execute(childChainProvider);\nawait executeResult.wait();\nWithdraw ETH using the Arbitrum SDK\nThe SDK also provides an EthBridger class that simplifies ETH withdrawals:\nimport { getArbitrumNetwork, EthBridger } from '@arbitrum/sdk';\nimport { ethers } from 'ethers';\n\nconst childNetwork = await getArbitrumNetwork(childProvider);\nconst ethBridger = new EthBridger(childNetwork);\n\n// Initiate withdrawal from child chain\nconst withdrawTx = await ethBridger.withdraw({\n amount: ethers.utils.parseEther('0.1'),\n childSigner,\n from: walletAddress,\n destinationAddress: walletAddress,\n});\nconst withdrawReceipt = await withdrawTx.wait();\n\n// Get child-to-parent events for later outbox execution\nconst withdrawEvents = withdrawReceipt.getChildToParentEvents();\nAfter the 6.4-day challenge period, use the outbox execution flow described above (or the SDK's ChildToParentMessage.execute) to claim your ETH on the parent chain.\nFor a complete example, see the eth-withdraw tutorial.\nMessage lifecycle\nChild-to-parent messages go through these stages:\nStageDescriptionPosted on child chainThe message is sent via ArbSys.sendTxToL1Waiting for finalizationThe assertion containing the message is in the challenge period (6.4 days)Confirmed and executable on parent chainThe assertion is confirmed, and the message can be executed in the outbox\nNext steps\n\nFor protocol-level details, see Child to parent chain messaging\nFor token bridging concepts, see Token bridging overview\nFor the Arbitrum SDK documentation, see Arbitrum SDK\nHow is this guide?TokensStep-by-step guide to depositing ERC-20 tokens from Ethereum (parent chain) to an Arbitrum child chain using the token bridge gateway system and Arbitrum SDK.TokensStep-by-step guide to withdrawing ERC-20 tokens from an Arbitrum child chain back to Ethereum (parent chain) using the token bridge gateway system, including the 6.4-day challenge period.","tokens":1904,"squid":"spider-01","role":"Chain Spider","at":1791343349315,"hash":"cd6b4e8e556cbaa1ded211b72f5a20094f202f44"}
{"url":"https://forum.arbitrum.foundation/t/team-6-an-eip-4824-powered-daouri-for-the-arbitrum-dao/25371","domain":"forum.arbitrum.foundation","title":"Team #6: An (EIP-4824 powered) daoURI for the Arbitrum DAO - Archive / GovHack Brussels - Arbitrum","text":"The Arbitrum Foundation notified the Security Council on the need to perform a potential Emergency action. Following a review of the details and known risks, the Security Council decided to execute the upgrade and it was completed at 11:30 EST on 2nd October 2026.\nThis report provides an overview of the risks that required the Security Council Action:\n\nAdd a permissionless guard for the One-Step Proof of BoLD on Arbitrum One\n\nTemporarily pause activation of new Stylus contracts on Arbitrum One & Nova\n\nKey point: To date, known bugs for Stylus primarily impact chain liveness (e.g., denial of service attacks) and do not put any user funds at risk.\nWhy was this action taken\nLet’s take this opportunity to explain why action was taken on two separate issues concerning BoLD and Stylus.\nInstalling the guard for One-Step Proof of BoLD. Given the rise of AI-assisted attacks, we have implemented a precautionary approach that allows anyone to pause settlement of Arbitrum One on Ethereum if there are at least two conflicting answers that pass at the same level in which only one should be valid and pass. This is to halt a class of publicly verifiable and detectable attacks that exploit a bug in the one-step proof. If halted, Arbitrum One will continue to process as normal except that messages from Arbitrum One to Ethereum, such as withdrawals, that are not yet confirmed will have to wait. This provides time for the Security Council to deploy a fix for the bug and resume the rollup.\nPreventing activation of new Stylus contracts. AI-assisted tooling has led to an increasing number of sophisticated attacks on hand-crafted WASM programs that do not use the standard Stylus compiler toolchain. These programs are specifically designed to cause unexpected behaviors such as degrading the chain’s performance for all other users. To date, no attacks have been discovered that permits theft of user funds.\nNew ArbOS releases have patched several reported bugs and known attacks over the past few months, but out of an abundance of caution, we have decided to temporarily pause new activations of Stylus contracts. This was executed as an emergency action to prevent the deployment of new hand-crafted WASM programs that are not yet patched by the current version of ArbOS on the Arbitrum network.\nThe Arbitrum Foundation has informed the Security Council that they will work with the ArbitrumDAO to discuss next steps on the timeline and manner for enabling activation of new Stylus contracts. The Arbitrum community remains confident in the value of Stylus and want to preserve these use cases while taking preventative measures against Stylus-based attack vectors as AI-assisted attack tooling continues to evolve.\nImpact on builders and users\n\nNo new activations. New Stylus contracts cannot be activated during the pause including new versions of existing applications that require activation.\n\nExisting contracts are not paused. Already-active Stylus contracts continue to execute until expiration. This pause does not deactivate them.\n\nThe ArbOS 61 upgrade renewed all active contracts on Arbitrum One, so no currently active contract expires before August 20, 2027.\n\nRenewal via keepalive stays permissionless and is unaffected by the pause.\n\nReactivating an expired contract, or one that needs to be updated after a Stylus version change, is paused.\n\nUsing/calling any activated Stylus contract stays permissionless for all users and developers.\n\nNo impact on EVM. Solidity (EVM) contract deployment and execution are unaffected by this Security Council action.\n\nSecurity Council Actions\nThere are two actions bundled into a single payload:\n\nOne-Step Proof Guard. The L1UpgradeExecutor gives a new pause contract (PauseExecutor) the ability to pause and nothing else. The new pause contract grants the guard (OspSoundnessGuard) PAUSER_ROLE to use it. Anyone can show the guard two conflicting answers to the same step of an open challenge. If the one-step proof accepts both, the guard has the pause contract put Arbitrum One’s settlement to Ethereum on hold.\n\nStylus deactivation. The Security Council called ArbOwner.setWasmActivationGas(2^64 - 1) to raise the Stylus activation gas requirement on Arbitrum One and Nova. This makes activation prohibitively expensive and effectively disables new activations. This is a configuration change and does not require an ArbOS upgrade.\n\nThe Security Council signed the following transactions to update the configuration:\n\nEthereum: Ethereum Transaction Hash: 0x30732bb7d2... | Etherscan\nArbitrum One:\nArbitrum One Transaction Hash: 0x9eb3a4be3b... | Arbitrum One\nArbitrum Nova:\nArbitrum Nova transaction 0x79e0fed470dff7a22059b108e3f8f42eddd2b580a6771594060c4e7326c5f984 | Blockscout\n\nAn external audit was conducted for the OSP Guard contracts. No audit is required for the Stylus deactivation as it is only updating a single parameter in the ArbOS configuration.\n\n Team #6: An (EIP-4824 powered) daoURI for the Arbitrum DAO \n\n ArchiveGovHack Brussels\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jul 2024\n\n 1 / 54\n\n Jul 2024\n\n Oct 2024\n\n post by amanwithwings on Jul 6, 2024\n\n amanwithwings\n\nTrack: GovTech\nChallenge Statement: “Data surrounding the Arbitrum DAO is scattered all over the place. How can we increase data availability and accessibility without losing decentralisation?”\nMembers: Aman and Rashmi Abbigeri\nTeam Lead contact name or alias: Aman (Telegram: amanwithwings)\nPITCH: daoURI for Arbitrum DAO🚀 | Loom\n\nAbstract\nWe propose that the Arbitrum DAO takes control of its data by publishing a daoURI onchain. The daoURI, following EIP-4824, will create a single source of truth on the DAO, that cannot be altered by external agencies, is fully manageable via governance, bringing helpful context on the DAO onchain. This will be helpful for newcomers, tooling providers, and experienced governooors alike.\nDAOstar received a grant from the Arbitrum Foundation to improve the adoption of EIP-4824 in the Arbitrum ecosystem. We are allocating a portion of that grant to steward this proposal. Adopting EIP-4824 requires no additional spend from the DAO treasury, and it makes no change to its smart contracts or governance structure.\nMotivation\nThe Arbitrum DAO is one of the largest DAOs, and there is a lot of data surrounding it. This dataset grows with every new initiative and has multiple components that may not be very visible from the “outside”. For example, consider the following questions:\n\nWho are the current Security Council, Arbitrum Research & Development Collective, Procurement Committee members? (Answer: you can search the respective forum post to find this)\nCan you share a location that tracks all DAO-owned/managed multisig addresses? (Answer: this could be https://www.arbwallets.xyz/)\nCan you share a status update on the DAO’s grant spending? (Answer: R3gen Finance reports this on the forum)\nWhere can we see delegate performance? (Answer: KarmaGAP or Tally)\nHow much in sequencer fees is being collected? (Answer: there is a dashboard for this)\nWhat orbit chains exist? (Answer: the ecosystem page tracks this)\nWhere to find recordings and transcripts of public meetings? (Answer: I’m not sure!)\n\nFor an active participant, these answers might not be very hard. But for the majority of people who are not active participants of the DAO, and even for tooling providers, collecting this information requires a painstaking amount of manual effort. This leads to inconsistencies, errors and outdated information.\nThere are over 200 DAOs at the moment with a treasury size of over $1M, and collecting information on them manually is becoming an exponentially difficult task. EIP-4824 was authored by DAOstar with the support from the Ethereum Foundation, Gnosis, Etherscan, DeepDAO, Snapshot, and a large number of DAO tooling companies, to create a better infrastructure for DAO data.\nAdopting EIP-4824 essentially means that the DAO publishes a daoURI onchain. daoURIs have a standard JSON-LD format:\n{\n\"@context\": \"http://www.daostar.org/schemas\",\n\"type\": \"DAO\",\n\"name\": \"<name of the DAO>\",\n\"description\": \"<description>\",\n\"membersURI\": \"<URI>\",\n\"proposalsURI\": \"<URI>\",\n\"activityLogURI\": \"<URI>\",\n\"governanceURI\": \"<URI>\",\n\"contractsRegistryURI\": \"<URI>\"\n}\n\nIt contains information on governance, members, activities and contracts by default. Outside of the endpoints mentioned above, a DAO can also choose to publish information that is specifically important to it. For Arbitrum, this could be information about orbit chains, different multi-sigs and councils, spending, sequencer fees, link to its constitution, etc. Essentially, the daoURI creates an “official repository” of information on the DAO.\nHere are some examples of how the daoURI could be used:\n\nIt can be used to bring more context to contracts on block explorers. For example, we could go from this:\n\n1600×847 168 KB\nto this:\n1600×842 171 KB\n\nWe can make DAO data easily and freely available to everyone\n\nFor example, Arbitrum DAO’s current DeepDAO profile misses a ton of info - contracts, or revenue, or governance guardrails (councils and multi-sigs), etc. Messari’s Arbitrum DAO dashboard requires a paid membership to access, which could also be due to the difficulty of collecting and presenting DAO data (thus making it too valuable to give away for free). By making access to this information easy, we can greatly improve the DAO’s transparency. i.e, go from: 1600×786 291 KB\nto this:\n1600×903 249 KB\n\ndaoURI makes it much easier to structure metadata improvements.\n\nA specific example that surfaced during Arbitrum GovHack (thanks to Paulo Fonseca): onchain proposals at Arbitrum DAO (or any DAO for that matter) do not reference a forum discussion. This takes away a lot of available information. If we wanted to change this, we could achieve it easily by enforcing a discussionURI field inside the proposalURI (which is a standard component of daoURI). Tally, Aragon, Snapshot X, and most governance tooling providers are members of DAOstar. Extending the standard will create an easy upgrade pathway for them and this change would reflect the change across the ecosystem.\nTo summarize, a daoURI creates a source of truth for metadata, that can represent the present state of the DAO, and is easily accessible for onchain and offchain tools. This proposal carries no additional cost, or changes to any existing smart contract or process. It’s a step in the right direction with no downside.\nRationale\nThis proposal aligns with the Arbitrum’s mission and community values, by making the Arbitrum DAO more open, accessible, and inclusive to participants and tools alike. The initiative:\n\nsignificantly lowers the high threshold of context and background work required to start understanding and meaningfully contributing to the DAO;\nIt increases accountability over the board as more information is now freely available;\nIt decreases administrative overhead and maintenance as were converging on a single point to publish and consume data.\n\nSpecifications\nExecution is a simple contract call to the EIP-4824 Registration Factory which deploys a new registration contract that’ll store the daoURI. The registration will be on Arbitrum One network, setting the DAO’s Governor timelock as admin, and managers as the DAO decides.\nA DAO that runs the same configuration as Arbitrum DAO and has adopted EIP-4824 is Unlock Protocol. We are adding that transaction here for reference, along with successful proposals at Treasure and 1inch that were executed through their respective treasury safes.\nSteps to Implement\nCreate a daoURI for Arbitrum DAO: Based on conversations with different contributors during the Arbitrum GovHack, the daoURI can include a description on the DAO, a paginated list of all DAO voters, a list of all proposals (with title, timestamp, status and soon a discussion link), link to governance documents, list of all contracts owned or managed by the DAO, link to dashboards on protocol revenue, orbit chains and delegate performance. It will be stored on IPFS.\nNote that this is a starting point. The daoURI of Arbitrum DAO will continuously evolve and become more comprehensive over time.\nPublish the daoURI onchain: As detailed in the execution summary above, this will be a simple smart contract call to deploy a new contract on Arbitrum One.\nMaintain the daoURI: Though daoURI is fully manageable through governance, it may not be practically feasible to initiate an onchain vote for every upgrade. To solve this, the DAO can set one or many manager to manage its daoURI. The Arbitrum Foundation might be a good candidate. If needed, DAOstar can commit to maintaining Arbitrum DAO’s daoURI for a year for at additional cost. Managers can only update daoURIs. They can be added or removed easily by the DAO.\nTo keep the daoURI a community-led effort, we suggest that whoever is set as a manager maintain a forum topic to discuss updates. That way, any Arbitrum DAO member can publicly request to add a missing piece of info to the daoURI.\nTimeline\nCreation of daoURI V0.1 (includes conversations with delegates, service providers, the Arbitrum Foundation, and all other participants through the forum, led by DAOstar): 4 weeks\nTesting (ensuring that the subURIs work well & that any static data is either uploaded to IPFS or hosted by a trusted 3rd party, for example the Arbitrum Foundation): 2 weeks\nOverall: 6 weeks before the proposal is ready to be executed\nOverall Cost\nThis proposal does not require any transfer of funds from the DAO treasury.\nSpecial thanks to @Bobbay, @Matt_StableLab, @raam, @coolhorsegirl, @Srijith-Questbook, @Sinkas, Hayden (BlockworksResearch) and Nick Nahaghi (Hats) for feedback and edits; @krst, @AlexLumley, @Frisson, @dk3, and George Beall (Gauntlet) for the expert sessions, and to Klaus and the rest of the GovHack team for making an awesome event happen at Brussels!\nEIP-4824 has already been adopted by Snapshot, Aragon, Treasure, 1inch, Optimism Collective (through the Optimism Foundation), and multiple frameworks and DAOs. The effort is supported by grants from the Arbitrum Foundation, Optimism Collective, ENS, Gnosis, Solana and many other stakeholders of the web3 ecosystem. Thank you to everyone:)\n\n Arbitrum daoURI Proposal Security Review\n\n 16 Jul 2024 - Open Discussion of Proposals Governance Call\n\n 30 Jul 2024 - Open Discussion of Proposals Governance Call\n\n Curia Delegate Communication Thread\n\n An EIP-4824 powered daoURI for Arbitrum DAO\n\n 10\n\n 3\n\n 2\n\n 2\n\n 2\n\n read \n\n 11\n min\n\n post by milk-cash on Jul 6, 2024\n\n post by paulofonseca on Jul 6, 2024\n\n post by coolhorsegirl on Jul 7, 2024\n\n post by amanwithwings on Jul 11, 2024\n\n 19 days later\n\n post by amanwithwings on Jul 30, 2024\n\n post by Pepperoni_Jo3 on Aug 1, 2024\n\n post by amanwithwings on Aug 5, 2024\n\n post by amanwithwings on Aug 13, 2024\n\n post by BlockworksResearch on Aug 15, 2024\n\n post by KlausBrave on Aug 15, 2024\n\n post by BlockworksResearch on Aug 15, 2024\n\n post by KlausBrave on Aug 15, 2024\n\n post by BlockworksResearch on Aug 15, 2024\n\n post by ermia on Aug 15, 2024\n\n post by amanwithwings on Aug 15, 2024\n\n post by EzR3aL on Aug 16, 2024\n\n post by amanwithwings on Aug 16, 2024\n\n post by jameskbh on Aug 16, 2024\n\n post by 0xDonPepe on Aug 17, 2024\n\n Load more posts below","tokens":3833,"squid":"spider-07","role":"Council Spider","at":1791343352849,"hash":"c94e1cab1188bb665d9dfa8a50460f153d8d5053"}
{"url":"https://developer.arbitrum.io/arbitrum-essentials/how-to-get-l2block-on-l1","domain":"developer.arbitrum.io","title":"How to verify child chain state on the parent chain","text":"BridgingHow to verify child chain state on the parent chainLearn how to verify child chain state on its parent chainRequest an update implements a system that ensures that the state of any given is safely maintained by its . In this system, a is responsible for periodically posting 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 ) 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 (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 {\n // Block when the first child of this assertion was created\n uint64 firstChildBlock;\n // Block when the second child was created (non-zero => assertion was challenged)\n uint64 secondChildBlock;\n // The block number when this assertion was created\n uint64 createdAtBlock;\n // True if this assertion is the first child of its prev\n bool isFirstChild;\n // Status of the assertion: NoAssertion / Pending / Confirmed\n AssertionStatus status;\n // Hash of the environment config at creation time (e.g. wasmModuleRoot)\n bytes32 configHash;\n}\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 {\n BeforeStateData beforeStateData;\n AssertionState beforeState;\n AssertionState afterState;\n}\n\nstruct AssertionState {\n GlobalState globalState;\n MachineStatus machineStatus;\n bytes32 endHistoryRoot;\n}\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(\n parentAssertionHash,\n afterState.hash(), // keccak256(abi.encode(afterState))\n inboxAcc\n))\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 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 = [\n l2blockRaw.parentHash,\n l2blockRaw.sha3Uncles,\n l2blockRaw.miner,\n l2blockRaw.stateRoot,\n l2blockRaw.transactionsRoot,\n l2blockRaw.receiptsRoot,\n l2blockRaw.logsBloom,\n BigNumber.from(l2blockRaw.difficulty).toHexString(),\n BigNumber.from(l2blockRaw.number).toHexString(),\n BigNumber.from(l2blockRaw.gasLimit).toHexString(),\n BigNumber.from(l2blockRaw.gasUsed).toHexString(),\n BigNumber.from(l2blockRaw.timestamp).toHexString(),\n l2blockRaw.extraData,\n l2blockRaw.mixHash,\n l2blockRaw.nonce,\n BigNumber.from(l2blockRaw.baseFeePerGas).toHexString(),\n];\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.\n 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 ; its correctness rests on the Rollup's fraud-proof / 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.\nHow is this guide?Cross-chain messagingLearn how to send cross-chain messages between Ethereum and Arbitrum using retryable tickets, the ArbSys precompile, and the Outbox contract. Includes a complete Greeter tutorial demonstrating both parent-to-child and child-to-parent messaging.L1-to-L3 teleportationLearn how to bridge ERC-20 tokens and ETH from Ethereum (L1) directly to an Arbitrum L3 chain using the Arbitrum SDK teleport feature, requiring only a single user transaction.","tokens":2571,"squid":"spider-01","role":"Chain Spider","at":1791343359295,"hash":"5a7e2b7a971b85cb6e99b21b1cec08b1936625f7"}
{"url":"https://www.metaplex.com/docs/smart-contracts","domain":"metaplex.com","title":"Solana Smart Contracts & Programs | NFT & Token Infrastructure | Metaplex","text":"Solana Smart ContractsProduction-ready Solana smart contracts for NFTs, tokens, and digital assets. Build with Core, Token Metadata, Candy Machine, Genesis, and more.Token MetadataSPL token creation with onchain metadata.CoreNext-gen NFT standard with a composable plugin system.Agent RegistryOnchain agent identity and execution delegation.MPL-3643Permissioned token standard for RWAs.Bubblegum v2Compressed NFTs at a fraction of regular costs.Core Candy MachineNFT launchpad for MPL Core.MPL-HybridSwap NFT traits for fungible tokens and back.MPL-DistroMerkle-based token distributions.GenesisLaunch tokens onchain.InscriptionInscribe permanent data into Solana state.Bubblegum v1Compressed NFTs on Solana. Use v2 for new projects.Deprecated: Candy Machine · Token Auth Rules · Fusion · Hydra · Auction House · Fixed Price Sale · Gumdrop · Token Entangler","tokens":214,"squid":"dotcat","role":"Tooling Spider","at":1791343364332,"hash":"3f1902c7fa37d7551517cf5c986cdafb5e8652c5"}
{"url":"https://forum.arbitrum.foundation/t/an-eip-4824-powered-daouri-for-arbitrum-dao/26386","domain":"forum.arbitrum.foundation","title":"An EIP-4824 powered daoURI for Arbitrum DAO - Proposals / Finalized AIPs - Arbitrum","text":"The Arbitrum Foundation notified the Security Council on the need to perform a potential Emergency action. Following a review of the details and known risks, the Security Council decided to execute the upgrade and it was completed at 11:30 EST on 2nd October 2026.\nThis report provides an overview of the risks that required the Security Council Action:\n\nAdd a permissionless guard for the One-Step Proof of BoLD on Arbitrum One\n\nTemporarily pause activation of new Stylus contracts on Arbitrum One & Nova\n\nKey point: To date, known bugs for Stylus primarily impact chain liveness (e.g., denial of service attacks) and do not put any user funds at risk.\nWhy was this action taken\nLet’s take this opportunity to explain why action was taken on two separate issues concerning BoLD and Stylus.\nInstalling the guard for One-Step Proof of BoLD. Given the rise of AI-assisted attacks, we have implemented a precautionary approach that allows anyone to pause settlement of Arbitrum One on Ethereum if there are at least two conflicting answers that pass at the same level in which only one should be valid and pass. This is to halt a class of publicly verifiable and detectable attacks that exploit a bug in the one-step proof. If halted, Arbitrum One will continue to process as normal except that messages from Arbitrum One to Ethereum, such as withdrawals, that are not yet confirmed will have to wait. This provides time for the Security Council to deploy a fix for the bug and resume the rollup.\nPreventing activation of new Stylus contracts. AI-assisted tooling has led to an increasing number of sophisticated attacks on hand-crafted WASM programs that do not use the standard Stylus compiler toolchain. These programs are specifically designed to cause unexpected behaviors such as degrading the chain’s performance for all other users. To date, no attacks have been discovered that permits theft of user funds.\nNew ArbOS releases have patched several reported bugs and known attacks over the past few months, but out of an abundance of caution, we have decided to temporarily pause new activations of Stylus contracts. This was executed as an emergency action to prevent the deployment of new hand-crafted WASM programs that are not yet patched by the current version of ArbOS on the Arbitrum network.\nThe Arbitrum Foundation has informed the Security Council that they will work with the ArbitrumDAO to discuss next steps on the timeline and manner for enabling activation of new Stylus contracts. The Arbitrum community remains confident in the value of Stylus and want to preserve these use cases while taking preventative measures against Stylus-based attack vectors as AI-assisted attack tooling continues to evolve.\nImpact on builders and users\n\nNo new activations. New Stylus contracts cannot be activated during the pause including new versions of existing applications that require activation.\n\nExisting contracts are not paused. Already-active Stylus contracts continue to execute until expiration. This pause does not deactivate them.\n\nThe ArbOS 61 upgrade renewed all active contracts on Arbitrum One, so no currently active contract expires before August 20, 2027.\n\nRenewal via keepalive stays permissionless and is unaffected by the pause.\n\nReactivating an expired contract, or one that needs to be updated after a Stylus version change, is paused.\n\nUsing/calling any activated Stylus contract stays permissionless for all users and developers.\n\nNo impact on EVM. Solidity (EVM) contract deployment and execution are unaffected by this Security Council action.\n\nSecurity Council Actions\nThere are two actions bundled into a single payload:\n\nOne-Step Proof Guard. The L1UpgradeExecutor gives a new pause contract (PauseExecutor) the ability to pause and nothing else. The new pause contract grants the guard (OspSoundnessGuard) PAUSER_ROLE to use it. Anyone can show the guard two conflicting answers to the same step of an open challenge. If the one-step proof accepts both, the guard has the pause contract put Arbitrum One’s settlement to Ethereum on hold.\n\nStylus deactivation. The Security Council called ArbOwner.setWasmActivationGas(2^64 - 1) to raise the Stylus activation gas requirement on Arbitrum One and Nova. This makes activation prohibitively expensive and effectively disables new activations. This is a configuration change and does not require an ArbOS upgrade.\n\nThe Security Council signed the following transactions to update the configuration:\n\nEthereum: Ethereum Transaction Hash: 0x30732bb7d2... | Etherscan\nArbitrum One:\nArbitrum One Transaction Hash: 0x9eb3a4be3b... | Arbitrum One\nArbitrum Nova:\nArbitrum Nova transaction 0x79e0fed470dff7a22059b108e3f8f42eddd2b580a6771594060c4e7326c5f984 | Blockscout\n\nAn external audit was conducted for the OSP Guard contracts. No audit is required for the Stylus deactivation as it is only updating a single parameter in the ArbOS configuration.\n\n An EIP-4824 powered daoURI for Arbitrum DAO \n\n ProposalsFinalized AIPs\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Aug 2024\n\n 1 / 43\n\n Aug 2024\n\n Nov 2024\n\n post by amanwithwings on Aug 16, 2024\n\n amanwithwings\n\n This proposal is originally a GovHack submission, posted previously in the “GovHack Brussels” category. This is a repost for more visibility.\nConstitutional / Non-Constitutional - Could be either, depending on execution (see details below)\nARDC’s review: Arbitrum daoURI Proposal Security Review\nAbstract\nWe propose that the Arbitrum DAO takes control of its metadata by publishing a daoURI onchain. The daoURI, following EIP-4824, will create a single source of truth on the DAO, that cannot be altered by external agencies, is fully manageable via governance, bringing helpful context on the DAO onchain. This will be helpful for newcomers, tooling providers, and experienced governooors alike.\nAdopting EIP-4824 requires no additional spend from the DAO treasury, and it makes no change to its smart contracts or governance structure.\nBackground\nEIP-4824 is a DAO metadata standard, akin to ERC-721 for NFTs. It has already been adopted by Snapshot, Aragon, Treasure, 1inch, Optimism Collective (through the Optimism Foundation), and multiple frameworks and DAOs. The adoption efforts are supported through grants from the Ethereum Foundation, Optimism Collective, ENS, Gnosis, Solana and many other stakeholders of the web3 ecosystem.\nDAOstar is also an Arbitrum Foundation grantee. The grant aims to improve the adoption of EIP-4824 within the Arbitrum ecosystem. We are allocating a portion of that grant to steward this proposal, and are requesting no additional funds from the DAO.\nRationale\nThe Arbitrum DAO is one of the largest DAOs. It has one of the most active governances, in terms of number participants as well as community-led initiatives. All of this activity, along with the scale and complexity of the Arbitrum DAO breeds a lot of metadata. This dataset grows with every new initiative and has multiple components that may not be very visible from the “outside”. For example, consider the following questions:\n\nWho are the current Security Council, Arbitrum Research & Development Collective, Procurement Committee members? (Answer: you can search the respective forum post to find this)\nCan you share a location that tracks all DAO-owned/managed multisig addresses? (Answer: this could be https://www.arbwallets.xyz/ )\nCan you share a status update on the DAO’s grant spending? (Answer: R3gen Finance reports this on the forum)\nWhere can we see delegate performance? (Answer: KarmaGAP or Tally)\nHow much in sequencer fees is being collected? (Answer: there is a dashboard for this)\nWhat orbit chains exist? (Answer: the ecosystem page tracks this)\nWhere to find recordings and transcripts of public meetings? (Answer: I’m not sure!)\n\nFor an active participant, these answers might not be very hard to find. But for the majority of people who are not active participants of the DAO, and even for tooling providers, collecting this information requires a painstaking amount of manual effort. This leads to inconsistencies, errors and outdated information.\nThe same concern echoes over the entire DAO ecosystem. There are over 200 DAOs at the moment with a treasury size of over $1M, and collecting information on them manually is becoming an exponentially difficult task. EIP-4824 was authored by DAOstar with the support from the Ethereum Foundation, Gnosis, Etherscan, DeepDAO, Snapshot, and a large number of DAO tooling companies, to create a better infrastructure for DAO data.\nAdopting EIP-4824 essentially means that the DAO publishes a daoURI onchain. daoURIs have a standard JSON-LD format:\n{\n\"@context\": \"http://www.daostar.org/schemas\",\n\"type\": \"DAO\",\n\"name\": \"<name of the DAO>\",\n\"description\": \"<description>\",\n\"membersURI\": \"<URI>\",\n\"proposalsURI\": \"<URI>\",\n\"activityLogURI\": \"<URI>\",\n\"governanceURI\": \"<URI>\",\n\"contractsRegistryURI\": \"<URI>\"\n}\n\nIt contains information on governance, members, activities and contracts by default. Outside of the endpoints mentioned above, a DAO can also choose to publish information that is specifically important to it. For Arbitrum, this could be information about orbit chains, different multi-sigs and councils, spending, sequencer fees, link to its constitution, etc. Essentially, the daoURI creates an “official repository” of information on the DAO.\nHere are some examples of how the daoURI could be used:\n\nIt can be used to bring more context to contracts on block explorers. For example, we could go from this:\n\n1600×847 168 KB\nto this:\n1600×842 171 KB\n\nWe can make DAO data easily and freely available to everyone\n\nFor example, Arbitrum DAO’s current DeepDAO profile misses a ton of info - contracts, or revenue, or governance guardrails (councils and multi-sigs), etc. Messari’s Arbitrum DAO dashboard requires a paid membership to access, which could also be due to the difficulty of collecting and presenting DAO data (thus making it too valuable to give away for free). By making access to this information easy, we can greatly improve the DAO’s transparency. i.e, go from:\n1600×786 291 KB\nto this:\n1600×903 249 KB\n\ndaoURI makes it much easier to structure metadata improvements.\n\nA specific example that surfaced during Arbitrum GovHack (thanks to Paulo Fonseca): onchain proposals at Arbitrum DAO (or any DAO for that matter) do not reference a forum discussion. This takes away a lot of available information. If we wanted to change this, we could achieve it easily by enforcing a discussionURI field inside the proposalURI (which is a standard component of daoURI). Tally, Aragon, Snapshot X, and most governance tooling providers are members of DAOstar. Extending the standard will create an easy upgrade pathway for them and this change would reflect the change across the ecosystem.\nTo summarize, a daoURI creates a source of truth that is easily accessible by onchain and offchain tools. This proposal carries no additional cost, or changes to any existing smart contract or process. It’s a step in the right direction with no downside.\nSpecifications\nAs mentioned above, adopting EIP-4824 essentially means that the DAO publishes a daoURI onchain. There are various ways to do this:\nScreenshot 2024-08-16 at 11.34.07 AM1550×738 103 KB\nBased on Arbitrum DAO’s characteristics, we suggest the following adoption pathways:\n\nExecuting a simple contract call to the EIP-4824 Registration Factory which’ll deploys a new registration contract to store the daoURI. The registration will be on Arbitrum One network, setting the DAO’s governor timelock as admin, and a manager as the DAO decides. This would require a constitutional proposal.\n\nSet a new ‘daoURI’ txt record on arbitrumfoundation.eth. Arbitrum Foundation will have complete edit access to this daoURI as they own arbitrumfoundation.eth. A daoURI published through this method will not be editable via an onchain vote. However, this method is in some sense easier than the previous, and it requires no onchain vote. This would be a non-constitutional proposal. When the time comes, the DAO can also adopt EIP-4824 through method 1 to have full control over its data.\n\nTransactions for reference: Unlock Protocol, Treasure and 1inch\nSteps to Implement\nCreate a daoURI for Arbitrum DAO: Based on conversations during the Arbitrum GovHack, and feedback from various delegates and contributors over the past 4 weeks, we have built this daoURI for Arbitrum:\nhttps://ipfs.io/ipfs/QmUrBuJLBCZKnnEebwRe2Yqh3fk39H2mtqPQjMPUwVC1Ap\nScreenshot 2024-08-16 at 11.50.33 AM2876×786 333 KB\nIt is presently stored on IPFS, and uses APIs from Tally, Snapshot for governance data. We recommend that if the Arbitrum Foundation ends up being the manager, the daoURI be stored in their GitHub for ease of editing, and higher transparency. DAOstar will work with the Foundation on implementation.\nNote that this is a starting point. The daoURI of Arbitrum DAO will continuously evolve and become more comprehensive over time.\nPublish the daoURI onchain: As detailed in the execution summary above, this will either be a smart contract call to deploy a new contract, or setting a new txt record on arbitrumfoundation.eth\nMaintain the daoURI: (Pathway 1) Though daoURI is fully manageable through governance, it is not practical to initiate an onchain vote for every upgrade. To solve this, the DAO can set one or many managers to manage its daoURI. The Arbitrum Foundation has agreed to take on this role if the DAO decides so. DAOstar will commit to maintaining Arbitrum DAO’s daoURI for a year for at additional cost. Note that managers can be added or removed easily by the DAO.\n(Pathway 2) The DAO will not have the capability to change the daoURI through governance. However, it can instruct the Arbitrum Foundation to do so.\nIrrespective of the adoption pathway, we would like to see the daoURI maintained through a community-led effort. We suggest that whoever is set as a manager maintain a forum discussion to discuss updates. That way, any Arbitrum DAO member can publicly request to add a missing piece of info to the daoURI.\nTimeline\nUnless the DAO has any feedback on the daoURI above, this proposal is ready for execution.\nOverall Cost\nThis proposal does not require any transfer of funds from the DAO treasury.\nSpecial thanks to @Bobbay, @Matt_StableLab, @raam, @coolhorsegirl, @Srijith-Questbook, @Sinkas, Hayden (BlockworksResearch) and Nick Nahaghi (Hats) for feedback and edits; @krst, @AlexLumley, @Frisson, @dk3, and George Beall (Gauntlet) for the expert sessions, and to Klaus and the rest of the GovHack team for making an awesome event happen at Brussels!\n\n Security analysis of EIP-4824 adoption by Arbitrum DAO\n\n GovHack ETHcc Brussels 2024 - Impact Report - Hack Humanity\n\n Team #6: An (EIP-4824 powered) daoURI for the Arbitrum DAO\n\n 8\n\n 2\n\n read \n\n 11\n min\n\n post by amanwithwings on Aug 16, 2024\n\n 1 month later\n\n post by Larva on Sep 27, 2024\n\n post by paulofonseca on Sep 27, 2024\n\n post by BlockworksResearch on Sep 27, 2024\n\n post by amanwithwings on Sep 27, 2024\n\n post by amanwithwings on Sep 27, 2024\n\n post by cp0x on Sep 27, 2024\n\n post by amanwithwings on Sep 27, 2024\n\n post by 0xTALVO.ETH_MTY on Sep 27, 2024\n\n post by JoJo on Sep 28, 2024\n\n post by PGov on Sep 28, 2024\n\n post by amanwithwings on Sep 29, 2024\n\n post by amanwithwings on Sep 29, 2024\n\n post by duokongcrypto on Sep 29, 2024\n\n post by kuiclub on Sep 29, 2024\n\n post by Bruce on Sep 29, 2024\n\n post by ggmatch on Sep 29, 2024\n\n post by Euphoria on Sep 30, 2024\n\n post by TodayInDeFi on Sep 30, 2024\n\n Load more posts below","tokens":3903,"squid":"spider-07","role":"Council Spider","at":1791343364382,"hash":"b718da52a5a3800cc33fa258a5a06c47ea346e36"}
{"url":"https://developer.arbitrum.io/oracles/overview-oracles","domain":"developer.arbitrum.io","title":"Oracles","text":"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.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.How is this guide?Nonce managementUnderstand how Arbitrum handles transaction nonces differently from Ethereum. Arbitrum's sequencer keeps only a short retry window for out-of-order nonces instead of a long-lived pending pool, so concurrent submitters must coordinate nonce allocation.PrecompilesArbitrum-specific precompiled contracts and their interfaces.","tokens":1180,"squid":"spider-01","role":"Chain Spider","at":1791343373685,"hash":"f0ddaec2dc7d88c62b3415c901a6e22fff3d2c73"}
{"url":"https://www.metaplex.com/docs/smart-contracts/mpl-agent","domain":"metaplex.com","title":"MPL Agent Registry — On-Chain Agent Identity for Solana | Metaplex","text":"The MPL Agent Registry provides on-chain programs for registering agent identity and delegating execution permissions on Solana using MPL Core assets. SummaryThe MPL Agent Registry is a pair of on-chain Solana programs that bind verifiable identity records to MPL Core assets and manage execution delegation through executive profiles.Agent Identity program — registers an identity PDA and attaches an AgentIdentity plugin with lifecycle hooks to a Core assetAgent Tools program — manages executive profiles and execution delegation recordsJavaScript/TypeScript SDK — @metaplex-foundation/mpl-agent-registry provides instruction builders and account fetchersSame addresses on Mainnet and Devnet — both programs are deployed at identical addresses across networksChoose Your PathQuick start? See Getting Started for installation and first registrationRegister an agent? Follow the Register an Agent guideRead agent data? Follow the Read Agent Data guideWhat is the Agent Registry?The Agent Registry binds a verifiable on-chain identity record to an MPL Core asset. Registration creates a PDA (Program Derived Address) that makes the agent discoverable on-chain, and attaches an AgentIdentity plugin to the Core asset with lifecycle hooks for Transfer, Update, and Execute events.Once an agent has an identity, the Agent Tools program lets asset owners delegate execution permissions to executive profiles — allowing designated authorities to execute actions on behalf of agent assets.ProgramsProgramAddressPurposeAgent Identity1DREGFgysWYxLnRnKQnwrxnJQeSMk2HmGaC6whw2B2pRegisters identity and attaches lifecycle hooks to a Core assetAgent ToolsTLREGni9ZEyGC3vnPZtqUh95xQ8oPqJSvNjvB7FGK8SExecutive profiles and execution delegationHow It WorksIdentity RegistrationYou call RegisterIdentityV1 with an MPL Core asset and an agentRegistrationUriThe program creates a PDA derived from seeds [\"agent_identity\", <asset>]The program CPIs into MPL Core to attach an AgentIdentity plugin with the URI and lifecycle checks for Transfer, Update, and ExecuteThe PDA stores the asset's public key for reverse lookupsExecution DelegationAn executive registers a profile via RegisterExecutiveV1The asset owner calls DelegateExecutionV1 to grant the executive permission to execute on behalf of the agent assetA delegation record PDA is created linking the executive profile to the assetThe asset owner calls RevokeExecutionV1 to close the delegation record when the executive should no longer operate the agentAn active execution delegate has broad operational authority over the agent's Asset Signer PDA. Revocation stops future Execute calls through the AgentIdentity path but does not unwind state created by previous executions in other programs. See the Security model on the Agent Tools reference.SDKLanguagePackageJavaScript/TypeScript@metaplex-foundation/mpl-agent-registrynpm install @metaplex-foundation/mpl-agent-registry\nNext StepsGetting Started — Installation, setup, and first registrationAgent Identity — Identity program details, accounts, and PDA derivationAgent Tools — Executive profiles and execution delegationMaintained by Metaplex · Last verified March 2026 · View source on GitHub","tokens":797,"squid":"dotcat","role":"Tooling Spider","at":1791343375800,"hash":"3fb23b107185453590c40ef1e7b8cd48f6ab39c1"}
{"url":"https://forum.arbitrum.foundation/c/proposals/finalized-aips/9","domain":"forum.arbitrum.foundation","title":"Latest Proposals/Finalized AIPs topics - Arbitrum","text":"The Arbitrum Foundation notified the Security Council on the need to perform a potential Emergency action. Following a review of the details and known risks, the Security Council decided to execute the upgrade and it was completed at 11:30 EST on 2nd October 2026.\nThis report provides an overview of the risks that required the Security Council Action:\n\nAdd a permissionless guard for the One-Step Proof of BoLD on Arbitrum One\n\nTemporarily pause activation of new Stylus contracts on Arbitrum One & Nova\n\nKey point: To date, known bugs for Stylus primarily impact chain liveness (e.g., denial of service attacks) and do not put any user funds at risk.\nWhy was this action taken\nLet’s take this opportunity to explain why action was taken on two separate issues concerning BoLD and Stylus.\nInstalling the guard for One-Step Proof of BoLD. Given the rise of AI-assisted attacks, we have implemented a precautionary approach that allows anyone to pause settlement of Arbitrum One on Ethereum if there are at least two conflicting answers that pass at the same level in which only one should be valid and pass. This is to halt a class of publicly verifiable and detectable attacks that exploit a bug in the one-step proof. If halted, Arbitrum One will continue to process as normal except that messages from Arbitrum One to Ethereum, such as withdrawals, that are not yet confirmed will have to wait. This provides time for the Security Council to deploy a fix for the bug and resume the rollup.\nPreventing activation of new Stylus contracts. AI-assisted tooling has led to an increasing number of sophisticated attacks on hand-crafted WASM programs that do not use the standard Stylus compiler toolchain. These programs are specifically designed to cause unexpected behaviors such as degrading the chain’s performance for all other users. To date, no attacks have been discovered that permits theft of user funds.\nNew ArbOS releases have patched several reported bugs and known attacks over the past few months, but out of an abundance of caution, we have decided to temporarily pause new activations of Stylus contracts. This was executed as an emergency action to prevent the deployment of new hand-crafted WASM programs that are not yet patched by the current version of ArbOS on the Arbitrum network.\nThe Arbitrum Foundation has informed the Security Council that they will work with the ArbitrumDAO to discuss next steps on the timeline and manner for enabling activation of new Stylus contracts. The Arbitrum community remains confident in the value of Stylus and want to preserve these use cases while taking preventative measures against Stylus-based attack vectors as AI-assisted attack tooling continues to evolve.\nImpact on builders and users\n\nNo new activations. New Stylus contracts cannot be activated during the pause including new versions of existing applications that require activation.\n\nExisting contracts are not paused. Already-active Stylus contracts continue to execute until expiration. This pause does not deactivate them.\n\nThe ArbOS 61 upgrade renewed all active contracts on Arbitrum One, so no currently active contract expires before August 20, 2027.\n\nRenewal via keepalive stays permissionless and is unaffected by the pause.\n\nReactivating an expired contract, or one that needs to be updated after a Stylus version change, is paused.\n\nUsing/calling any activated Stylus contract stays permissionless for all users and developers.\n\nNo impact on EVM. Solidity (EVM) contract deployment and execution are unaffected by this Security Council action.\n\nSecurity Council Actions\nThere are two actions bundled into a single payload:\n\nOne-Step Proof Guard. The L1UpgradeExecutor gives a new pause contract (PauseExecutor) the ability to pause and nothing else. The new pause contract grants the guard (OspSoundnessGuard) PAUSER_ROLE to use it. Anyone can show the guard two conflicting answers to the same step of an open challenge. If the one-step proof accepts both, the guard has the pause contract put Arbitrum One’s settlement to Ethereum on hold.\n\nStylus deactivation. The Security Council called ArbOwner.setWasmActivationGas(2^64 - 1) to raise the Stylus activation gas requirement on Arbitrum One and Nova. This makes activation prohibitively expensive and effectively disables new activations. This is a configuration change and does not require an ArbOS upgrade.\n\nThe Security Council signed the following transactions to update the configuration:\n\nEthereum: Ethereum Transaction Hash: 0x30732bb7d2... | Etherscan\nArbitrum One:\nArbitrum One Transaction Hash: 0x9eb3a4be3b... | Arbitrum One\nArbitrum Nova:\nArbitrum Nova transaction 0x79e0fed470dff7a22059b108e3f8f42eddd2b580a6771594060c4e7326c5f984 | Blockscout\n\nAn external audit was conducted for the OSP Guard contracts. No audit is required for the Stylus deactivation as it is only updating a single parameter in the ArbOS configuration.\n\n Latest topics in Finalized AIPs\n\n Proposals\n\n Finalized AIPs\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 Finalized AIPs category\n\n 0\n\n 405\n\n Jan 2023\n\n [Constitutional] AIP: Transition Arbitrum One ordering policy to Priority Gas Auctions (PGA)\n\n 30\n\n 2.2k\n\n 6d\n\n [Constitutional] AIP Fast Feed\n\n 22\n\n 1.0k\n\n 14d\n\n Banning projects identified in the high-severity Watchdog Program cases\n\n 11\n\n 396\n\n 15d\n\n Arbitrum Security Program\n\n 20\n\n 578\n\n 24d\n\n [Constitutional] AIP: Ratification of Security Council Election Process Improvements\n\n 27\n\n 645\n\n Sep 1\n\n Entropy Advisors: Exclusively Working With Arbitrum DAO\n\n proposal\n\n 86\n\n 3.9k\n\n Aug 25\n\n Transfer 6,000 ETH and Idle Stablecoins from the Treasury to the Treasury Management Portfolio\n\n 27\n\n 941\n\n Aug 12\n\n Arbitrum Audit Program\n\n 128\n\n 4.6k\n\n Aug 3\n\n [Constitutional] AIP: ArbOS 61 Elara\n\n 30\n\n 1.4k\n\n Jul 30\n\n Proposed Amendment to the Code of Conduct: AI tools and Responsible Participation Policy\n\n 4\n\n 123\n\n Jul 20\n\n Continued Funding for the Arbitrum Foundation\n\n 37\n\n 2.1k\n\n Jul 15\n\n AGV Wind-Down: Structured Transition & Return of Capital to the DAO Treasury\n\n 16\n\n 769\n\n Jul 7\n\n Extending DRIP’s Mandate\n\n 14\n\n 407\n\n Jun 26\n\n [Constitutional] AIP: Approve Release of Frozen ETH\n\n 53\n\n 7.3k\n\n Jun 15\n\n [RFC] Proposal to Adjust the Voting Power of the Arbitrum Community Pool & Ratifying the Agentic Governance Pivot\n\n proposal,delegation,proposal-discussions\n\n 65\n\n 1.7k\n\n Jun 14\n\n [Constitutional] AIP: Minimize Arbitrum Nova\n\n 21\n\n 815\n\n Jun 9\n\n Improvements to the Arbitrum Audit Program\n\n 13\n\n 514\n\n Apr 24\n\n [Constitutional] DVP Quorum for ArbitrumDAO: Implementation & Parameters\n\n 52\n\n 1.8k\n\n Apr 24\n\n Updating the Code of Conduct & DAO Procedures to Become Living Documents\n\n 12\n\n 395\n\n Apr 14\n\n Automate the Consolidation of Idle Funds into the Treasury Management Portfolio\n\n 21\n\n 727\n\n Mar 25\n\n Change to New Governance Contracts that Allow Proposal Cancellation\n\n 51\n\n 1.7k\n\n Feb 28\n\n [Constitutional] AIP: Security Council Election Process Improvements [OLD]\n\n 68\n\n 2.2k\n\n Feb 17\n\n Research on context and retention\n\n proposal\n\n 74\n\n 1.3k\n\n Feb 16\n\n Updating the Code of Conduct & DAO’s Procedures\n\n 37\n\n 1.4k\n\n Feb 9\n\n Rewarding Active Delegates (RAD) Program\n\n 46\n\n 2.3k\n\n Jan 29\n\n [Non-Constitutional] [RFC] Arbitrum D.A.O. (Domain Allocator Offerings) Grant Program - Season 3\n\n 157\n\n 4.4k\n\n Jan 13\n\n AIP: Raise the gas target, min L2 base fee, & implement improvements to the pricing algorithm\n\n 33\n\n 2.2k\n\n Dec 2025\n\n [CONSTITUTIONAL] AIP: ArbOS Version 50 Dia\n\n proposal\n\n 38\n\n 1.8k\n\n Dec 2025\n\n [Constitutional] AIP: DVP Quorum\n\n 21\n\n 897\n\n Dec 2025","tokens":1907,"squid":"spider-07","role":"Council Spider","at":1791343375849,"hash":"24ee87995fdf9e67962b5d8262a039cf8b3a38c4"}
{"url":"https://developer.arbitrum.io/arbitrum-essentials/public-chains","domain":"developer.arbitrum.io","title":"Arbitrum chains overview","text":"Arbitrum chains overviewOverview 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.Request an update chains are solutions built on top of the Ethereum , designed to increase scalability and reduce costs. In this conceptual overview, we’ll learn about the different 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 and settles to Ethereum's . 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 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.\nWarningThe old testnet RinkArby was deprecated on December 20th, 2022.\nStylus testnet (deprecated)\n 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.How is this guide?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.BridgingMove ETH, tokens, and messages between parent and child chains.","tokens":1431,"squid":"spider-01","role":"Chain Spider","at":1791343383637,"hash":"4b7ce13fb66b614fd538a2928c679169e1a64ba7"}
{"url":"https://forum.arbitrum.foundation/t/arbitrum-security-program/31207","domain":"forum.arbitrum.foundation","title":"Arbitrum Security Program - Proposals / Finalized AIPs - Arbitrum","text":"The Arbitrum Foundation notified the Security Council on the need to perform a potential Emergency action. Following a review of the details and known risks, the Security Council decided to execute the upgrade and it was completed at 11:30 EST on 2nd October 2026.\nThis report provides an overview of the risks that required the Security Council Action:\n\nAdd a permissionless guard for the One-Step Proof of BoLD on Arbitrum One\n\nTemporarily pause activation of new Stylus contracts on Arbitrum One & Nova\n\nKey point: To date, known bugs for Stylus primarily impact chain liveness (e.g., denial of service attacks) and do not put any user funds at risk.\nWhy was this action taken\nLet’s take this opportunity to explain why action was taken on two separate issues concerning BoLD and Stylus.\nInstalling the guard for One-Step Proof of BoLD. Given the rise of AI-assisted attacks, we have implemented a precautionary approach that allows anyone to pause settlement of Arbitrum One on Ethereum if there are at least two conflicting answers that pass at the same level in which only one should be valid and pass. This is to halt a class of publicly verifiable and detectable attacks that exploit a bug in the one-step proof. If halted, Arbitrum One will continue to process as normal except that messages from Arbitrum One to Ethereum, such as withdrawals, that are not yet confirmed will have to wait. This provides time for the Security Council to deploy a fix for the bug and resume the rollup.\nPreventing activation of new Stylus contracts. AI-assisted tooling has led to an increasing number of sophisticated attacks on hand-crafted WASM programs that do not use the standard Stylus compiler toolchain. These programs are specifically designed to cause unexpected behaviors such as degrading the chain’s performance for all other users. To date, no attacks have been discovered that permits theft of user funds.\nNew ArbOS releases have patched several reported bugs and known attacks over the past few months, but out of an abundance of caution, we have decided to temporarily pause new activations of Stylus contracts. This was executed as an emergency action to prevent the deployment of new hand-crafted WASM programs that are not yet patched by the current version of ArbOS on the Arbitrum network.\nThe Arbitrum Foundation has informed the Security Council that they will work with the ArbitrumDAO to discuss next steps on the timeline and manner for enabling activation of new Stylus contracts. The Arbitrum community remains confident in the value of Stylus and want to preserve these use cases while taking preventative measures against Stylus-based attack vectors as AI-assisted attack tooling continues to evolve.\nImpact on builders and users\n\nNo new activations. New Stylus contracts cannot be activated during the pause including new versions of existing applications that require activation.\n\nExisting contracts are not paused. Already-active Stylus contracts continue to execute until expiration. This pause does not deactivate them.\n\nThe ArbOS 61 upgrade renewed all active contracts on Arbitrum One, so no currently active contract expires before August 20, 2027.\n\nRenewal via keepalive stays permissionless and is unaffected by the pause.\n\nReactivating an expired contract, or one that needs to be updated after a Stylus version change, is paused.\n\nUsing/calling any activated Stylus contract stays permissionless for all users and developers.\n\nNo impact on EVM. Solidity (EVM) contract deployment and execution are unaffected by this Security Council action.\n\nSecurity Council Actions\nThere are two actions bundled into a single payload:\n\nOne-Step Proof Guard. The L1UpgradeExecutor gives a new pause contract (PauseExecutor) the ability to pause and nothing else. The new pause contract grants the guard (OspSoundnessGuard) PAUSER_ROLE to use it. Anyone can show the guard two conflicting answers to the same step of an open challenge. If the one-step proof accepts both, the guard has the pause contract put Arbitrum One’s settlement to Ethereum on hold.\n\nStylus deactivation. The Security Council called ArbOwner.setWasmActivationGas(2^64 - 1) to raise the Stylus activation gas requirement on Arbitrum One and Nova. This makes activation prohibitively expensive and effectively disables new activations. This is a configuration change and does not require an ArbOS upgrade.\n\nThe Security Council signed the following transactions to update the configuration:\n\nEthereum: Ethereum Transaction Hash: 0x30732bb7d2... | Etherscan\nArbitrum One:\nArbitrum One Transaction Hash: 0x9eb3a4be3b... | Arbitrum One\nArbitrum Nova:\nArbitrum Nova transaction 0x79e0fed470dff7a22059b108e3f8f42eddd2b580a6771594060c4e7326c5f984 | Blockscout\n\nAn external audit was conducted for the OSP Guard contracts. No audit is required for the Stylus deactivation as it is only updating a single parameter in the ArbOS configuration.\n\n Arbitrum Security Program \n\n ProposalsFinalized AIPs\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Aug 13\n\n 1 / 21\n\n Aug 13\n\n 24d ago\n\n post by Arbitrum on Aug 13\n\n Arbitrum\n\n Arbitrum Security Program\nAbstract\nThe Arbitrum Foundation proposes to continue and evolve the Arbitrum Audit Program (AAP) - launched on 1 August 2025 with a one-year mandate - into a broader Arbitrum Security Program (ASP), running for a further 12 months on a rolling-application basis.\n\nFrom “Audit” to “Security”. AAP delivered on its original purpose - real vulnerabilities surfaced and remediated before mainnet, with a high share of net-new teams brought to Arbitrum - and demonstrated where subsidised security converts into the most ecosystem value. Building on that, the mandate broadens to four pillars covering the full security lifecycle: AI-assisted screening ahead of a full audit, the human-conducted audit itself, the Arbitrum bug bounty program, and the ArbitrumDAO Security Council.\n\nNo new treasury request. ~$2M in cumulative audit commitments is expected by AAP’s close. The remaining $1.76M USDC + 25M ARB held by the Foundation becomes ASP’s operational budget, less ~$1.2M in predicted outstanding deployments.\n\nOperational refinements from a year of experience. The audit committee technical expert retainer is right-sized to $2.5k/month based on expected workload; the DAO-approved alignment framework is maintained as the program’s baseline; program changes adopt a lightweight optimistic approval process to reduce governance overhead; and idle funds are put to work in low-risk management strategies.\n\nThe program runs for one year (or until funds are exhausted), managed by the Arbitrum Foundation and supported by the audit committee as technical SME, with quarterly transparency reports and a final summary report to the DAO.\nMotivation\nThe AAP was approved by ArbitrumDAO to remove a barrier facing early-stage teams: third-party audits are the industry norm, but their cost puts them out of reach for many young projects. The program’s full design - objectives, eligibility, application process, auditor approval, and alignment commitments including Arbitrum exclusivity - is set out in the original proposal, and its performance has been reported quarterly (#1, #2, #3).\nResults\n(covering Q1-Q3 and preliminary Q4, prior to final report)\n367 applications were received through preliminary Q4, with application-to-decision time averaging 2-3 weeks. To date, 18 completed audits reviewed 71,366 lines of code and identified 385 vulnerabilities - 13 critical and 40 high - remediated before mainnet. The average audit cost was $50,706, approximately $15 per line of code, which sits below the industry average of $70,000 for mid-complexity DeFi audits as per market references provided by Sherlock and Zealynx. The total commitments are expected to reach ~$2M once in-progress and pending audits are activated.\nWhat Worked\n\nThe program delivered on its original mandate. With ~60% of funded teams net new to the ecosystem, it attracted security-first founders who might otherwise have launched elsewhere.\nIt demonstrated Arbitrum’s dedication to user security. Funding security work upfront led to tangible critical findings, remediated before mainnet.\nOperationally the program matured. A growing referral channel now drives roughly half of onboarded teams, and pricing has stayed within benchmarked ranges.\n\nLessons Learned\n\nEarly-stage teams didn’t have enough runway to benefit from audits. Some recipients were unable to move forward after receiving funding, in a few cases winding down within months. Future eligibility should require at least 1 year of runway and the capacity to cover part of the audit cost.\nValue secured has concentrated in later-stage teams that could typically fund audits themselves - a tension with the early-stage mandate, since younger projects generally need more time to grow TVL for their product.\nLead times are long. Audit contract signature to mainnet launch averages ~135 days for teams not yet live.\nImpact was real, but visibility was low. Audit subsidies set Arbitrum apart from other ecosystems, but the program received too little visibility to capitalize on that. Going forward, funded teams will be asked to publicly acknowledge the subsidy, among other improvements to program communications.\n\nThese results and lessons, among others, shape the adjustments below.\nSpecifications\nProgram Adjustments\n1. Expand Scope with AI Audits\nAAP identified five AI security agents to be trialed under this program. ASP will run the pilot: every funded team will receive an AI-assisted review ahead of its full audit, with lower-cost AI screening available to earlier-stage teams, and all five tools running in parallel for evaluation.\n2. Expand Scope with Core Protocol Security: Bug Bounty & Security Council\nAudits are point-in-time; protecting the core protocol that every funded team builds on also requires continuous review of live code and emergency response - the program’s third and fourth pillars:\n\nBug Bounty (continuous review). Arbitrum operates a bug bounty covering the Arbitrum One and Arbitrum Nova smart contracts, with rewards of up to $2,000,000 for critical findings - a maximum that has never been paid out since the Foundation began running the program. Its scope remains the Arbitrum protocol codebase; ecosystem teams’ codebases are covered through the AI-screening and audit pathway above.\nSecurity Council (emergency response). The ArbitrumDAO Security Council is the DAO-elected body empowered by the Constitution to respond to security emergencies affecting the protocol in production, and has been historically funded by the AF on behalf of the DAO.\n\nBoth are included for the reason set out in the Abstract: redirecting part of the unspent allocation toward the security layers with the highest impact on the ecosystem - every team, user, and dollar of TVL on Arbitrum ultimately depends on the integrity of the core protocol they protect - with no change to the bounty’s scope and reward terms or to the Council’s compensation, election process, and constitutional mandate. Bug and bounty reporting will be provided yearly at a high level, e.g., total payout amounts.\n3. Maintain Alignment Framework\nAfter strict exclusivity created material friction during AAP, the requirement was revised via a formal governance proposal into a DAO-approved, alignment-based framework, which ASP adopts as its baseline.\n4. Introduce a Lightweight Governance Process\nAdjusting the exclusivity framework during AAP showed that putting every program change through the full governance process adds significant overhead. ASP therefore adopts the optimistic approval framework from the recent Code of Conduct proposal: changes posted to the forum by the AF take effect after 14 days unless a combined 5% of delegated VP (measured at the time of posting) raises objections, in which case the change goes to an off-chain vote at the non-constitutional quorum. The AF is responsible for monitoring objections and tallying VP.\n5. Enable Idle Funds Deployment\nLastly, with the majority of AAP funds remaining unproductive for the duration of the program, we propose that ASP deploy idle funds into low-risk management strategies.\nBudget\nAAP was funded through a 30M ARB allocation, part of which was converted to cover audit commitments and the $60k technical expert retainer; roughly $1.23M was committed by the end of Q3, expected to reach ~$2M by program close (cumulative over the program’s duration). ASP requests no new funding: it operates from the actual remaining balance already held by the Foundation - $1.76M USDC plus 25M ARB - less ~$1.2M in predicted outstanding deployments (final amount depends on total audit commitments, some of which may not materialize). This budget covers the expanded scope:\n\nAudit, AI screening and security subsidies for ecosystem teams.\nArbitrum protocol bug bounties: operation of the bug bounty program, with contingent reward payouts for validated findings.\nSecurity Council: member compensation of $5,000 per member per month across the 12-member Council, i.e., $720,000 per year.\nTechnical expert: retainer of $2,500/month (down from $5,000/month, or $60,000/year, in AAP), reflecting updated workload.\nAll other costs (legal, program management, operations) remain covered by the Arbitrum Foundation.\n\nAs in AAP, funds committed towards audits will be disclosed in each quarterly transparency report, giving the DAO visibility into deployment pace against the remaining balance. Any balance unspent at term end returns to the ArbitrumDAO treasury unless the DAO approves a continuation\nTimeline\nWith AAP applications closed on 31 July 2026 and an approximate two-month wind-down underway, continuity of a live audit offering is an important matter for builders on Arbitrum. We propose the following governance timeline, subject to delegate feedback:\n\nAugust 13th → Proposal posted in the forum (complete)\nAugust 20th → Binding off-chain vote following non-constitutional quorum\nBy October 1st → Applications open for the program, with an official announcement declaring the start date and the one-year clock.\n\n Cp0x Delegate Communication Thread\n\n Griff Green - Delegate Communication Thread\n\n Rewarding Active Delegates - August 2026 Results\n\n DZack23.eth Delegate Communications thread\n\n 3\n\n 3\n\n 2\n\n read \n\n 12\n min\n\n post by Arbitrum on Aug 13\n\n post by MconnectDAO on Aug 13\n\n post by JulianCross on Aug 14\n\n post by GozmanGonzalez on Aug 14\n\n post by ostanescu.eth on Aug 20\n\n post by cp0x on Aug 21\n\n post by Abel189 on Aug 21\n\n post by TodayInDeFi on Aug 21\n\n post by Arbitrum on Aug 21\n\n post by Arb_Junior on Aug 21\n\n post by MconnectDAO on Aug 22\n\n post by MconnectDAO on Aug 22\n\n post by JulianCross on Aug 23\n\n post by Zeptimus on Aug 24\n\n post by Griff on Aug 24\n\n post by Reverie on Aug 25\n\n post by Manugotsuka on Aug 26\n\n post by cornellbc.eth on Aug 27\n\n post by Saurabh on Aug 27\n\n Load more posts below","tokens":3742,"squid":"spider-07","role":"Council Spider","at":1791343388881,"hash":"99975d79791aecdcf120c8772fb56e320ba05c7f"}
{"url":"https://akash.network/current-groups/wg-content-moderation/","domain":"akash.network","title":"Content Moderation Working Group - Community Groups","text":"Back\n Steering Committee Steering Committee Special Interest Groups Analytics Special Interest Group Chain Special Interest Group Clients Special Interest Group Community Special Interest Group Deployments Special Interest Group Design Special Interest Group Documentation Special Interest Group Economics Special Interest Group Education Providers Special Interest Group Support Special Interest Group Working Groups Akash Hackathon Working Group Akash Website Akash Youtube Client Libraries Working Group Content Moderation Working Group Economics 2.0 2023 Events - Working Group GPU Working Group Provider Attributes Working Group Provider Audit Working Group Testnets Working Group Zealy Content Moderation Working Group The Content Moderation working group aims to build tools and functionality that gives providers control over the applications that run on their systems. \nView on Discord\n\nView on GitHub\n\nSubscribe to Calendar\n\nAkash Network - Content Moderation Working Group\nThe Content Moderation working group aims to build tools and functionality that\ngives providers control over the applications that run on their systems.\nMeetings\nBiWeekly On Wednesdays at 9am Pacific.\n\nMeetingTimeNotesTranscriptRecording#1Thursday, Dec 22, 2022 9:00 AM PT (Pacific Time)LinkLinkLink#2Wednesday, Jan 11, 2023 9:00 AM PT (Pacific Time)LinkLinkLink#3Wednesday, Jan 25, 2023 9:00 AM PT (Pacific Time)LinkLinkLink#4Wednesday, Feb 8, 2023 9:00 AM PT (Pacific Time)LinkLinkLink#5Tuesday, Feb 28, 2023 11:00 AM PT (Pacific Time)LinkLinkLink\nLeads\n\nAdam Bozanich (adam@akash.network)\nScott Carruthers (scott@akash.network)\nDeval Patel (deval@praetorapp.com)\nJigar Patel (jigar@praetorapp.com)\nAnil Murty (anil@akash.network)\n\nContacts\n\nDiscord channel\n\nGoals\n\nAgree on problem we are trying to solve with content moderation\nBrainstorm potential solutions\nPrioritize solutions based on difficulty\nDocument High level PRD and API Spec(s)\nAllocate work to Sigs to implement code changes\n\nPRDs and other documentation\n\nPRD & Roadmap\nModeration API\nManagement API\n\nRelated SIGs\n\nsig-providers\nsig-deployments\n Client Libraries Working Group Economics 2.0","tokens":535,"squid":"spider-03","role":"Compute Spider","at":1791343388911,"hash":"8dd3f34655ad591fe0cb55fb6fd6d7a4961a06c9"}
{"url":"https://developer.arbitrum.io/how-arbitrum-works/deep-dives/anytrust-protocol","domain":"developer.arbitrum.io","title":"AnyTrust Protocol","text":"AnyTrust ProtocolLearn the fundamentals of the Arbitrum AnyTrust protocol.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 in the ’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 (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 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.How is this guide?ArbOSHow ArbOS works as the child chain hypervisor, managing resources, block production, cross-chain messaging, and EVM execution.","tokens":1680,"squid":"spider-01","role":"Chain Spider","at":1791343394801,"hash":"7089343359d2504c08f1a0a01358c8ab9b348d6c"}
{"url":"https://forum.arbitrum.foundation/t/arbitrum-security-program/31207/21","domain":"forum.arbitrum.foundation","title":"Arbitrum Security Program - Proposals / Finalized AIPs - Arbitrum","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 read \n\n 12\n min\n\n Aug 13\n\n 21 / 21\n\n Sep 12\n\n 24d ago\n\n Load more posts above\n\n post by Arbitrum on Aug 13\n\n Arbitrum\n\n We will be hosting the following open discussion governance call on this proposal:\nArbitrum Security Program: Open Discussion\nTuesday, August 18 · 4:30 – 5:30pm\nTime zone: UTC\nVideo call link: Google Meet meeting\nCall recording can be accessed here: https://drive.google.com/file/d/1wFiGzp371Urc3CtTA-WHIbyUz1mxFIzx/view?usp=sharing\n\n post by MconnectDAO on Aug 13\n\n MconnectDAO\n\n I support the Arbitrum Security Program.\nThe shift from a narrow Audit Program to a broader security program is timely and valuable. Combining AI assisted screening, human audits, the core protocol bug bounty, and Security Council support creates a more complete security lifecycle for Arbitrum builders, users, and protocol infrastructure. The previous program also showed clear impact, with critical and high severity issues identified and fixed before mainnet deployment.\nI especially support the decision to continue without requesting new treasury funds. However, to make this program stronger, more transparent, and more accountable to the DAO, I would encourage the Foundation to add the following safeguards:\n\nClear budget caps by pillar: Publish an indicative annual allocation for AI screening, audits, bug bounty payouts, Security Council compensation, and technical expert costs. This will help delegates track whether ecosystem team security is receiving sufficient funding relative to core protocol expenses.\n\nQuarterly KPI dashboard: Each quarterly report should include applications received, approvals, rejections, average decision time, audit completion rate, total subsidy deployed, vulnerabilities by severity, remediation status, time to mainnet, and projects still active after six and twelve months. The proposal already commits to quarterly reports, so these metrics would make those reports more useful.\n\nTransparent selection rubric: Publish a weighted scoring framework for selecting teams. Factors could include protocol maturity, user funds at risk, technical complexity, runway, audit co payment, Arbitrum alignment, and expected ecosystem value. This reduces discretion concerns and makes decisions easier to evaluate.\n\nMilestone based audit payments: Rather than committing the full subsidy upfront, payments should be linked to clear stages such as audit start, final report delivery, remediation confirmation, and verified deployment. This directly addresses the lesson that some early stage teams did not have enough runway to benefit from funded audits.\n\nAI pilot evaluation before scaling: Since five AI security tools will be tested in parallel, the Foundation should publish an evaluation framework before the pilot begins. It should measure false positives, meaningful findings, overlap with human audits, cost per useful finding, and time saved. AI screening should remain complementary to, not a replacement for, independent human auditing.\n\nDefined rules for idle funds: “Low risk” needs a public definition. The DAO should know permitted assets, approved protocols or custodians, maximum exposure per venue, liquidity requirements, counterparty limits, and whether principal loss is possible. A monthly disclosure of deployed amount, yield earned, and risk exposure would be appropriate.\n\nLimits on optimistic governance: The 14 day optimistic process is useful for small operational changes, but it should not apply to material changes in budget allocation, program duration, eligibility rules, Security Council compensation, bug bounty reward terms, or idle fund risk parameters. These should require a normal DAO vote. The proposed process allows Foundation posted changes to proceed unless 5 percent of delegated voting power objects, so defining these boundaries is important.\n\nPublic security impact reporting: Aggregate vulnerability data is helpful, but reports should also show how many critical and high issues were fixed, how many teams launched, how much TVL or user exposure was protected where feasible, and how many funded projects remained active. This will allow the DAO to assess security return on capital, not only audit volume.\n\nIndependent annual review: At the end of the 12 month term, an independent reviewer should assess program effectiveness, financial deployment, conflicts of interest, auditor performance, and the results of the AI tool pilot before any renewal proposal is brought to the DAO.\n\nOverall, I support the proposal. With stronger reporting, defined capital management rules, selection transparency, and limits on delegated operational changes, ASP can become a credible long term security public good for the Arbitrum ecosystem\n\n post by JulianCross on Aug 14\n\n JulianCross\n\n @MconnectDAO Your emphasis on shifting from upfront lump sums to Milestone-Based Payments and Quarterly KPI Dashboards is the exact structural upgrade the Arbitrum security framework requires.\nWhen governance funding is tied strictly to verifiable milestone completion rather than speculative projections, accountability shifts from “trust” to “math.” This is the foundational standard required for all major capital allocations moving forward.\n\n post by GozmanGonzalez on Aug 14\n\n GozmanGonzalez\n\n I’m generally in support of the Arbitrum Security Program.\nThe shift from the Audit Program to a broader security program makes sense to me. The AAP has already shown that subsidising security can create real value for the ecosystem, from getting critical vulnerabilities caught before mainnet to bringing new teams into Arbitrum.\nWhat I like about ASP is that it looks beyond the audit itself. AI-assisted screening, human audits, bug bounties, and Security Council support cover different parts of the security lifecycle, which feels much more practical than treating an audit as the finish line.\nI also like that there’s no new treasury ask. The proposal is essentially trying to get more value out of funds that have already been allocated, while keeping the DAO informed through quarterly transparency reports.\nA few things I’d still keep an eye on:\n• AI screening: Running five tools in parallel is interesting, but the program should actually measure how useful they are. I’d like to see whether they catch meaningful issues that human auditors miss, rather than just producing more findings.\n• Team eligibility: The runway requirement is a good lesson from AAP. There’s little value in funding an audit for a team that may not have the runway or resources to actually ship.\n• Idle funds: Putting unused funds to work is reasonable, but capital preservation and liquidity should come first. The DAO shouldn’t be taking unnecessary risks just to generate yield.\n• Governance: I like the 14-day optimistic approval model because not every operational adjustment needs to become a full governance event. At the same time, the objection mechanism needs to remain genuinely accessible to delegates.\n• Transparency: The quarterly reports should tell us more than just how much was spent. Metrics around vulnerabilities found, severity, remediation, AI performance, funded teams that actually launched, and remaining funds would make it much easier to judge whether ASP is delivering.\nOverall, I think ASP is a solid evolution of AAP. The biggest win here is moving from “we funded audits” to building a more complete security pipeline for the Arbitrum ecosystem.\nI’m supportive, but I’d like us to keep the focus on measurable outcomes, responsible treasury management, and transparency throughout the 12-month mandate.\n\n post by ostanescu.eth on Aug 20\n\n ostanescu.eth\n\n Hi @Arbitrum ! Great to see the continuation of this programe. More ecosystems should take this as an example for supporting early stage builders.\nI have a quick question: how were the AI security agents that will be trailed identified and can you share who built them?\nAlso, will there be possible for new Service Providers to join the list of approved ones?\nThanks!\n\n post by cp0x on Aug 21\n\n cp0x\n\n Budget questions\nThe proposal is explicit that it broadens the mandate, and that the bug bounty and the Security Council have been carried by the Foundation to date. Our questions are about what that means for the budget on both sides.\nBoth functions also sit inside the Foundation’s own 2027 funding, approved and transferred earlier this year: the technical lines are described in that proposal as covering “block explorers, bug bounties, auditing spend, cloud service providers,” and in that thread the Foundation listed the Security Council among what those lines cover. Nothing in ASP states that the corresponding amounts will be deducted from, returned from, or otherwise reconciled against that budget. The technical lines are aggregated, so this cannot be checked from outside.\nWhat amounts for these two functions are currently embedded in the 2027 Foundation budget, and how will they be reconciled if these functions are funded through ASP?\nOn the program’s own breakdown: in the deck from the 18 August call, the Security Council and the technical expert carry defined annual amounts, the bug bounty carries its maximum payout per critical finding, and “Audits and AI screening” reads “from remaining balance.” If that reflects the intended hierarchy, ecosystem audit subsidies become the residual category.\nWhat amount, or minimum floor, is reserved for the audit and AI screening pillar for the year? And is there a defined spending priority between the pillars if the balance does not cover all of them? The second was raised on the call and answered as to likelihood rather than as to rule.\nWe support @MconnectDAO on defining “low-risk” for idle fund deployment and on bounding which changes can pass through the 14-day optimistic process.\nPending answers, we are voting Against.\n\n Cp0x Delegate Communication Thread\n\n post by Abel189 on Aug 21\n\n Abel189\n\n The results from the first year provide a useful basis for refining the program rather than simply extending the previous model. In particular, the combination of AI-assisted screening with human audits could help address the cost and runway constraints identified among early-stage teams, while the inclusion of continuous bug bounty coverage and Security Council funding broadens the security benefit beyond individual projects. The proposed 14-day optimistic process is also worth watching, as its effectiveness will depend on whether the objection threshold provides sufficient protection while actually reducing governance overhead.\n\n post by TodayInDeFi on Aug 21\n\n TodayInDeFi\n\n Voting FOR.\nThe Audit Program earned its renewal on results: 18 completed audits across 71,366 lines of code surfaced 385 vulnerabilities — 13 critical, 40 high —all remediated before mainnet, at roughly $15 per line against a ~$70k industry mid-market reference. About 60% of funded teams were net new to the ecosystem. Broadening from point-in-time audits to a full security lifecycle — AI screening, human audit, bug bounty, Security Council — is the right read of where subsidised security actually converts into ecosystem value.\nTwo structural features make this a straightforward FOR for me. There is no new treasury request: ASP runs on the balance the DAO already allocated to\nAAP, and anything unspent at term end returns to the treasury. And the proposal is unusually candid about what didn’t work — the runway problem, value\nconcentrating in later-stage teams that could have self-funded, the 135-day audit-to-mainnet lead times. A program that reports its own failures is one\nworth renewing.\nA couple of things I’d like to see clarified as the program gets underway. The bug bounty and Security Council have been carried by the Foundation to date and appear inside the aggregated technical lines of the already-approved 2027 AF budget; it would help to understand how those amounts are reconciled now that both sit under ASP, since the aggregation makes that hard to see from outside.\nRelated: with the Security Council at $720k/year and roughly $1.2M of the $1.76M USDC already committed to outstanding audits, “audits and AI screening from remaining balance” leaves the program’s original purpose as the residual claimant. An indicative floor for the audit pillar, and some sense of priority between pillars if the balance doesn’t cover\neverything, would give delegates a clearer picture. @cp0x raised both points well.\nI’d also echo @MconnectDAO on defining “low-risk” for idle-fund deployment and on bounding which changes pass through the 14-day optimistic process.\nNone of this changes my support. Audit coverage lapsing would be the worse outcome — applications closed 31 July and the wind-down is already underway —\nand the structure here keeps the DAO’s exposure bounded.\n\n post by Arbitrum on Aug 21\n\n Arbitrum\n\n Thank you for your feedback and questions, @ostanescu.eth.\n\nThe five providers were identified over the course of AAP’s operations, based on the audit committee’s review of the tooling available in the market. We’re not sharing provider names at this stage, as all five will run in parallel so we can collect comparative data. We’d expect to name any providers the program converges on once the evaluation concludes.\n\nYes, depending on the volume and availability of current providers, more firms may be approved in the future. Providers interested in joining the approved list can reach out to the Foundation.\n\n post by Arb_Junior on Aug 21\n\n Arb_Junior\n\n This proposal is well-structured, low-risk from a treasury perspective, and demonstrates strong program iteration based on real data.\nKey governance strengths:\n• No new capital request: It reuses the remaining AAP allocation (~$1.76M USDC + 25M ARB, net of ~$1.2M outstanding commitments).\n• Continuity + evolution: It builds directly on a one-year pilot with clear metrics (367 applications, 18 completed audits, 385 vulnerabilities found including 13 critical/40 high, ~60% net-new teams, cost efficiency below industry benchmarks).\n• Scope expansion is logical and justified: Moving from pure audits to the full security lifecycle (AI screening → human audit → continuous bug bounty → emergency response via Security Council) addresses the reality that point-in-time audits alone are insufficient for ecosystem security.\n• Process improvements reduce overhead: The optimistic approval mechanism (14-day forum post + 5% VP objection threshold → non-constitutional vote if needed) is a sensible response to the friction experienced when adjusting the exclusivity framework.\n• Accountability mechanisms remain intact: Quarterly transparency reports, final summary, alignment framework retention, and return of unspent funds at term end preserve DAO visibility and control.\n• Risk controls: Right-sizing the technical expert retainer, eligibility tightening (runway + co-funding), public acknowledgment requirements, and idle-funds deployment into low-risk strategies all show operational maturity.\n• Bundling Security Council compensation and bug-bounty operations into the same envelope could raise questions about whether these should remain separately budgeted or more explicitly ring-fenced.\n• The optimistic process is efficient but relies on the Foundation accurately monitoring and tallying the 5% VP threshold.\n• Lead times and runway lessons indicate that pure early-stage focus had limits; the proposal acknowledges this without fully abandoning the original mandate.\nOverall, this is a responsible, data-driven continuation that prioritizes ecosystem security ROI while minimizing governance and treasury friction. It strengthens Arbitrum’s competitive positioning as a security-first L2 without requesting incremental capital.\nAppreciation:\nThank you to the Arbitrum Foundation and the audit committee for the transparent, metrics-rich proposal and for the disciplined execution of AAP over the past year.\nParticularly:\n• The clear accounting of results (vulnerabilities found and remediated pre-mainnet, cost-per-line efficiency, net-new team acquisition, and referral growth).\n• Honest lessons learned — especially around runway requirements, concentration of value in later-stage teams, long lead times, and the need for greater visibility. Acknowledging that some funded teams could not fully capitalize on the subsidy is refreshing and responsible.\n• The decision to expand the mandate to AI-assisted screening, continuous bug bounties, and Security Council support without a new treasury ask. This shows capital stewardship and a genuine focus on protecting the entire stack rather than optimizing solely for audit volume.\n• Right-sizing the technical expert retainer and introducing low-risk idle-funds strategies further demonstrate operational refinement.\n• Retaining the DAO-approved alignment framework while reducing process overhead via optimistic governance is a pragmatic balance.\nThis kind of iterative, evidence-based program design is exactly what healthy DAO governance should look like.\nOpinion:\nI am supportive of this proposal. Continuing and evolving the security program with remaining funds is a high-ROI use of capital that reinforces Arbitrum’s security posture, attracts quality builders, and protects existing users and TVL. The shift from a narrow “audit subsidy” to a broader “security lifecycle” program is a natural and welcome maturation. The operational tweaks (eligibility filters, public acknowledgment, optimistic process, idle-funds deployment) address real friction points without introducing unnecessary complexity. Barring material concerns raised in the discussion period, this should proceed.\nQuestions for Clarification: @Arbitrum\n1. Budget transparency & ring-fencing: Can you provide a clearer projected breakdown of the remaining ~$1.76M USDC + 25M ARB (net of outstanding commitments) across the four pillars (AI screening + audits, bug bounties, Security Council compensation, technical expert, and contingency)? How will contingent bug-bounty payouts be managed if a large critical payout occurs?\n2. AI pilot evaluation: How will success of the five AI security agents be measured (e.g., true-positive rate vs. human auditors, cost savings, false-positive burden on teams)? Will results of the parallel evaluation be shared in the quarterly reports?\n3. Eligibility refinements: Beyond the 1-year runway and partial self-funding requirements, will there be any scoring or prioritization criteria that balance early-stage access with likelihood of successful mainnet launch and sustained presence on Arbitrum?\n4. Optimistic process safeguards: How will the Foundation publicly track and report the 5% VP objection threshold in real time? Is there a planned notification mechanism (e.g., Snapshot or forum alerts) so delegates can easily monitor and respond within the 14-day window?\n5. Security Council & bug bounty reporting: Beyond the high-level yearly payout summary, will the quarterly ASP reports include any anonymized or aggregated insights on Security Council activity or bug-bounty submissions (without compromising operational security)?\n6. Idle funds strategy: What specific low-risk management strategies are contemplated, and what is the expected yield range and risk parameters? Will these be disclosed in the first quarterly report?\n7. Continuity & wind-down: Given the two-month wind-down of AAP and the proposed October 1 start, is there any bridge mechanism for teams currently in the pipeline that might otherwise face a gap?\nLooking forward to delegates discussion and happy to support the proposal.​​​​​​​​​​​​\n\n post by MconnectDAO on Aug 22\n\n MconnectDAO\n\n cp0x\n\n Thanks for highlighting this and for supporting the need to define low risk idle fund deployment and clear limits for the 14 day optimistic process.\nI also agree that budget reconciliation is essential. If bug bounty and Security Council costs are already covered within the Foundation budget, ASP should clearly disclose how duplicate funding will be avoided.\nA minimum allocation for audits and AI screening is equally important, otherwise the core purpose of the program may become dependent on leftover funds. Clear spending priorities, reporting, and governance limits would help delegates assess the program with confidence. @cp0x @Arb_Junior @JulianCross\n\n post by MconnectDAO on Aug 22\n\n MconnectDAO\n\n TodayInDeFi\n\n Thank you, @TodayInDeFi. I appreciate you highlighting these points.\nI agree that continuing security coverage is important, especially when the program is using already allocated funds and has shown clear results. My concern is mainly about making the expanded scope equally clear in practice.\nA public definition of “low risk” for idle fund deployment, along with clear limits on what can be changed through the 14 day optimistic process, would help delegates maintain oversight while allowing the program to operate efficiently.\nThe requested audit budget floor and clearer priority order across audits, AI screening, bug bounty, and Security Council would also improve accountability. @TodayInDeFi @cp0x\n\n post by JulianCross on Aug 23\n\n JulianCross\n\n @MconnectDAO You are correctly identifying the accounting friction.\n@cp0x @Arb_Junior To ensure the Arbitrum Security Program (ASP) does not become a convoluted residual category of the broader Foundation budget, the DAO cannot rely on retroactive, manual quarterly summaries.\nTrue budget reconciliation requires a deterministic data dashboard that automatically indexes and isolates ASP deployments (Audit payouts, Bug Bounties, AI Screening costs) from baseline Foundation spend in real-time. If delegates cannot instantly verify the on-chain execution of these specific security tranches, “spending priorities” become unenforceable.\nArchitect the tracking infrastructure first, and the governance accountability will naturally follow.\n\n post by Zeptimus on Aug 24\n\n Zeptimus\n\n Voting FOR. I love the idea of the AI screening, this will be an excellent opportunity for teams to benefit from security and focus on building. The lessons learned make sense and I’m excited to see what’s coming from builders. If the bull market really kicks in, builders should be attracted to Arbitrum.\n\n Zeptimus Delegate Communication Thread\n\n post by Griff on Aug 24\n\n Griff\n\n Voting FOR.\nThis Security program has 2 purposes: Secure Arbitrum, and also attract new projects, and overall i think it can work for achieving both those goals.\nOne of the main barriers to entry for any cool web3 innovation is getting the audits, subsidizing them for teams really can be the difference in what chain they deploy on… Personally, I can’t say i totally align with this strategy in 2026… it seems like large trusted players are safer bets for our ARB… which OCL does seem to do a good job at managing (the Robinhood deal for instance was great!) but at the the same time, i can understand this strategy… it does let us gamble on finding new teams and you never know who can be the next Polymarket, Hyperliquid or Pump.fun.\nBut I love seeing the AI screening and bug bounty uses… in general, i think we can make HUGE waves by making Arbitrum the most secure L2 in the ecosystem.\ni would love to see MORE efforts in that direction… Circuit breakers, an alternative group to the security council that can freeze funds quickly during hacks like we did with the LayerZero/rsETH/Aave incident (hopefully in conjunction with Seal 911), and other initiatives that can really move the needle to prevent thefts that seem all too common in crypto… Just think if those threats were mitigated on Arbitrum! It would be a great selling point to users and companies alike.\nThis is why I support this vote. It opens the door to support broader security initiatives… and the kicker is that it is only allocating funds that were already allocated to Audits (which i think has a smaller security ROI) to broader more impactful initiatives.\n\n Griff Green - Delegate Communication Thread\n\n post by Reverie on Aug 25\n\n Reverie\n\n Reverie is voting FOR this proposal. The original program produced tangible security outcomes, and the extension uses already-allocated funds rather than asking the DAO for more. We think extending the audit process from a snapshot review to a continuous process with AI screening, bug bounties and emergency response via the security council provides a more holistic product to teams building on the ecosystem. We also believe the optimistic approval process could be useful in reducing the friction for early stage startups.\n\n post by Manugotsuka on Aug 26\n\n Manugotsuka\n\n The following reflects the views of L2BEAT’s governance team, composed of @krst and @Manugotsuka, and is based on their combined research, fact-checking, and discussion.\nWe voted AGAINST.\nWe recognize that security is a critical priority for Arbitrum, and we are supportive of programs that help builders access high-quality audits and security support. The original Arbitrum Audit Program had a clear and useful purpose: reduce the financial burden for teams building in the ecosystem and help them reach mainnet with stronger security practices.\nOur concern is that the Arbitrum Security Program broadens that mandate too much. Some parts of the proposal, such as improving audit support for builders, make sense. However, combining builder audit support, protocol-level bug bounties, and Security Council compensation under the same remaining funding pool makes the program harder to evaluate and moves it away from its original focus.\nThis is also difficult to reconcile with the Foundation’s broader funding request, which already included security-related expenses while treating the Audit Program as a separate DAO-approved initiative. During the discussion, we asked how this proposal fits with that previously approved funding, and the response was that expenditures under this program would be reconciled against the Foundation budget to extend the Foundation’s operational runway. That makes us uncomfortable, because funds originally allocated for a builder-facing audit program should not gradually become part of the Foundation’s operating runway.\nOur understanding was that costs such as Security Council compensation and protocol-level bug bounties were already covered through the Foundation’s ordinary operating budget, especially given that the previous ask included $4.63M allocated to Security. We think the DAO should be more diligent about the use of DAO treasury funds, especially given that the treasury is not as large as it used to be.\nFurthermore, as OpCo is already operational, we think it may make sense to place this program under OpCo if it is intended to remain a DAO program. That would help avoid ambiguities around funding sources and expenses related to DAO programs.\nThe remaining audit program funds should either stay focused on ecosystem builders or return to the DAO treasury.\nFor these reasons, we voted AGAINST. This vote is not against Arbitrum security spending. It is about keeping budgets, mandates, and governance accountability clear.\n\n post by cornellbc.eth on Aug 27\n\n cornellbc.eth\n\n Cornell Blockchain supports this proposal to streamline and increase security.\n\n post by Saurabh on Aug 27\n\n Saurabh\n\n The following reflects the views of GMX’s Governance Committee and is based on the combined research, evaluation, consensus, and ideation of various committee members.\nThe GMX Governance Committees are supportive of the general direction of this proposal.\nEvolving the Arbitrum Audit Program into a broader Security Program makes sense. The first year showed that subsidised audits can surface meaningful issues before mainnet, and we agree that ecosystem security should not be treated as a one-off audit exercise.\nWe are supportive of the broader scope, including AI-assisted screening, the continued audit pathway, core protocol bug bounty coverage, and Security Council support.\nOur main request is for more clarity on two points.\nFirst, when available, we would appreciate more detail on the AI screening pilot: which tools will be used, how they will be selected, what kinds of findings they are expected to surface, and how their performance will be evaluated against human audits.\nSecond, we would like more detail on which security subsidies are available for ecosystem teams. The proposal refers to “audit, AI screening and security subsidies for ecosystem teams,” but it is not fully clear whether this is limited to audits and AI screening, or whether teams may also be eligible for other support such as bug bounty programs, AI audit competitions, monitoring, or post-deployment security coverage.\nOverall, we support the proposal’s direction and appreciate that it does not request new treasury funding. More detail on the AI tools and the scope of available ecosystem subsidies would make the program easier for teams and delegates to evaluate.\n\n 16 days later\n\n post by BenValdman on Sep 13\n\n BenValdman\n\n I think expanding the security program is a positive step for Arbitrum, especially because security is very important for blockchain projects. I also think that combining AI security tools, human audits, and a Bug Bounty program can provide better overall protection for the ecosystem.\nAt the same time, I believe it is important to maintain transparency about how the budget is being used and to provide clear results from the program.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Improvements to the Arbitrum Audit Program\n\n Finalized AIPs\n\n 13\n\n 514\n\n Apr 24\n\n Arbitrum Security Program is Live: Applications Now Open\n\n Announcements\n\n 0\n\n 77\n\n 8d\n\n Arbitrum Audit Program: Transparency Report #1\n\n Arbitrum Audit Program (AAP)\n\n 2\n\n 406\n\n Jan 15\n\n Arbitrum Audit Program: Transparency Report #3\n\n Arbitrum Audit Program (AAP)\n\n 2\n\n 239\n\n Aug 4\n\n Arbitrum Audit Program\n\n Finalized AIPs\n\n 128\n\n 4.6k\n\n Aug 3","tokens":7502,"squid":"spider-07","role":"Council Spider","at":1791343400258,"hash":"e4c8c8746f2ca6140ab4bd71770524248d143956"}
{"url":"https://developer.arbitrum.io/how-arbitrum-works/deep-dives/stf","domain":"developer.arbitrum.io","title":"State Transition Function","text":"State Transition FunctionLearn the fundamentals of the State Transition Function within Arbitrum Nitro.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 periodically posts compressed batches to the parent-chain inbox, emitting a SequencerBatchDelivered event. When the two disagree, the feed yields—the is the canonical record (Ethereum for Arbitrum), and a node will 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 mechanism behind robust parent-to-child chain messaging, and BatchPostingReport (kind 13) lets the STF charge the 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 , 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 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 .\nStylus-specific transaction processing\nA modified version of Geth that recognizes and processes transactions, ensuring proper inclusion in state transitions.\nExecution in a WASM runtime\nStylus transactions execute in ArbOS's 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 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 is this guide?Gas and feesLearn the fundamentals of how to calculate fees on Arbitrum, including parent chain pricing formulas and child chain gas mechanics.Deep divesDetailed explanations of AnyTrust, ArbOS, assertions, messaging, gas, and the transaction lifecycle.","tokens":1207,"squid":"spider-01","role":"Chain Spider","at":1791343405919,"hash":"3db409cd19fd06e40c245f79f571bb2e018c9775"}
{"url":"https://akash.network/current-groups/sig-support/","domain":"akash.network","title":"Support Special Interest Group - Community Groups","text":"Back\n Steering Committee Steering Committee Special Interest Groups Analytics Special Interest Group Chain Special Interest Group Clients Special Interest Group Community Special Interest Group Deployments Special Interest Group Design Special Interest Group Documentation Special Interest Group Economics Special Interest Group Education Providers Special Interest Group Support Special Interest Group Working Groups Akash Hackathon Working Group Akash Website Akash Youtube Client Libraries Working Group Content Moderation Working Group Economics 2.0 2023 Events - Working Group GPU Working Group Provider Attributes Working Group Provider Audit Working Group Testnets Working Group Zealy Support Special Interest Group sig-support is responsible for defining mechanics of how support works at Akash Network, as well as organizing a distributed support team across the world. The Support Special Interest group meets biweekly to discuss open issues in the Support Repo. If time permits, the group discusses issues related to the Akash Console which can be found the Console Repo. \nView on Discord\n\nView on GitHub\n\nSubscribe to Calendar\n\nAkash Network - Support Special Interest Group (SIG)\nsig-support is responsible for defining mechanics of how support works at Akash Network, as well as organizing a distributed support team across the world. The Support Special Interest group meets biweekly to discuss open issues in the Support Repo. If time permits, the group discusses issues related to the Akash Console which can be found the Console Repo.\nMeetings\nEvery other Wednesday\n\nMeetingTimeNotesTranscriptRecording#1Wed, Jan 25, 2023 09:00 AM PT (Pacific Time)LinkLinkLink#2Wed, Feb 15, 2023 10:30 AM PT (Pacific Time)LinkLinkLink#3Wed, March 1, 2023 10:30 AM PT (Pacific Time)LinkLinkLink#4Wed, March 15, 2023 09:00 AM PT (Pacific Time)LinkLinkLink#5Wed, March 29, 2023 09:00 AM PT (Pacific Time)LinkLinkLink#6Wed, April 12, 2023 09:00 AM PT (Pacific Time)LinkLinkLink#7Wed, April 26, 2023 09:00 AM PT (Pacific Time)LinkLinkLink#8Wed, May 10, 2023 09:00 AM PT (Pacific Time)LinkLinkLink#9Wed, May 24, 2023 09:00 AM PT (Pacific Time)LinkLinkLink#10Wed, June 07, 2023 09:00 AM PT (Pacific Time)LinkLinkLink#11Wed, June 21, 2023 09:00 AM PT (Pacific Time)LinkLinkLink#12Wed, July 05, 2023 09:00 AM PT (Pacific Time)LinkLinkLink#13Wed, July 19, 2023 09:00 AM PT (Pacific Time)LinkLinkLink#14Wed, August 02, 2023 09:00 AM PT (Pacific Time)LinkLinkLink#15Wed, August 16, 2023 09:00 AM PT (Pacific Time)LinkLinkLink#16Wed, August 30, 2023 07:00 AM PT (Pacific Time)LinkLinkLink#17Wed, September 13, 2023 07:00 AM PT (Pacific Time)LinkLinkLink#18Wed, September 27, 2023 07:00 AM PT (Pacific Time)LinkLinkLink#19Wed, October 11, 2023 07:00 AM PT (Pacific Time)LinkLinkLink#20Wed, October 25, 2023 07:00 AM PT (Pacific Time)LinkLinkLink#21Wed, November 08, 2023 07:00 AM PT (Pacific Time)LinkLinkLink#22Wed, November 22, 2023 07:00 AM PT (Pacific Time)LinkLinkLink#23Wed, December 06, 2023 07:00 AM PT (Pacific Time)LinkLinkLink#24Wed, December 20, 2023 07:00 AM PT (Pacific Time)LinkLinkLink#25Wed, January 10, 2024 07:00 AM PT (Pacific Time)LinkLinkLink#26Wed, January 24, 2024 07:00 AM PT (Pacific Time)LinkLinkLink#27Wed, February 21, 2024 07:00 AM PT (Pacific Time)LinkLinkLink#28Wed, March 06, 2024 07:00 AM PT (Pacific Time)LinkLinkLink#29Wed, March 20, 2024 08:00 AM PT (Pacific Time)LinkLinkComing Soon#30Wed, April 30, 2024 08:00 AM PT (Pacific Time)Coming SoonComing SoonComing Soon#31Wed, April 17, 2024 08:00 AM PT (Pacific Time)Coming SoonComing SoonComing Soon#32Wed, May 01, 2024 08:00 AM PT (Pacific Time)LinkLinkLink#33Wed, May 15, 2024 08:00 AM PT (Pacific Time)LinkLinkLink#34Wed, June 26, 2024 08:00 AM PT (Pacific Time)LinkLinkLink#35Wed, July 24, 2024 08:00 AM PT (Pacific Time)LinkLinkLink#36Wed, July 24, 2024 08:00 AM PT (Pacific Time)LinkLinkLink#37Wed, August 21, 2024 08:00 AM PT (Pacific Time)LinkLinkLink#38Wed, September 18, 2024 08:00 AM PT (Pacific Time)LinkLinkLink#39Wed, October 16, 2024 08:00 AM PT (Pacific Time)LinkLinkLink#40November 20, 2025 11:00 AM PT (Pacific Time)LinkLinkLink#41January 08, 2025 09:00 AM PT (Pacific Time)LinkLinkLink#41February 19, 2025 09:00 AM PT (Pacific Time)LinkLinkLink#42March 19, 2025 09:00 AM PT (Pacific Time)LinkLinkLink#43April 16, 2025 09:00 AM PT (Pacific Time)LinkLinkLink#44May, 2025 09:00 AM PT (Pacific Time)LinkLinkLink#45June, 2025 09:00 AM PT (Pacific Time)LinkLinkLink#46July 16, 2025 09:00 AM PT (Pacific Time)LinkLinkLink#47August 20, 2025 09:00 AM PT (Pacific Time)LinkLinkLink#48September 24, 2025 09:00 AM PT (Pacific Time)LinkLinkLink#49October 22, 2025 09:00 AM PT (Pacific Time)LinkLinkLink#50November 26, 2025 09:00 AM PT (Pacific Time)LinkLinkLink#51December 17, 2025 09:00 AM PT (Pacific Time)LinkLinkLink#52January 28, 2026 09:00 AM PT (Pacific Time)LinkLinkLink#53February 18, 2026 09:00 AM PT (Pacific Time)LinkLinkLink#54March 18, 2026 09:00 AM PT (Pacific Time)LinkLinkComing Soon#55April 22, 2026 09:00 AM PT (Pacific Time)LinkLinkLink#56May 20, 2026 09:00 AM PT (Pacific Time)LinkLinkLink#57June 24, 2026 09:00 AM PT (Pacific Time)LinkLinkLink#58July 15, 2026 09:00 AM PT (Pacific Time)LinkLinkComing Soon#59August, 2026 09:00 AM PT (Pacific Time)#60September, 2026 09:00 AM PT (Pacific Time)#61October, 2026 09:00 AM PT (Pacific Time)#62Novemebr, 2026 09:00 AM PT (Pacific Time)#63Decemebr, 2026 09:00 AM PT (Pacific Time)\nLeadership\n\nScott Carruthers, Overclock Labs\nArtur Troian, Overclock Labs\nAnil Murty, Overclock Labs\nTyler Wright, Overclock Labs\n\nContact\n\nDiscord Server\n\nSub Projects, Repositories & Relevant Work Groups\nThe following are projects and work-groups that sig-supports participates in or contributes to (ToDo: Add links when available)\n\nOpen Support Repo\nOpen Console Repo\n Providers Special Interest Group Akash Hackathon Working Group","tokens":1465,"squid":"spider-03","role":"Compute Spider","at":1791343408541,"hash":"9ed60a59be2bbf99aedc631fd94505138675aeb4"}
{"url":"https://forum.arbitrum.foundation/t/arbitrum-security-program-is-live-applications-now-open/31522","domain":"forum.arbitrum.foundation","title":"Arbitrum Security Program is Live: Applications Now Open - Announcements - Arbitrum","text":"The Arbitrum Foundation notified the Security Council on the need to perform a potential Emergency action. Following a review of the details and known risks, the Security Council decided to execute the upgrade and it was completed at 11:30 EST on 2nd October 2026.\nThis report provides an overview of the risks that required the Security Council Action:\n\nAdd a permissionless guard for the One-Step Proof of BoLD on Arbitrum One\n\nTemporarily pause activation of new Stylus contracts on Arbitrum One & Nova\n\nKey point: To date, known bugs for Stylus primarily impact chain liveness (e.g., denial of service attacks) and do not put any user funds at risk.\nWhy was this action taken\nLet’s take this opportunity to explain why action was taken on two separate issues concerning BoLD and Stylus.\nInstalling the guard for One-Step Proof of BoLD. Given the rise of AI-assisted attacks, we have implemented a precautionary approach that allows anyone to pause settlement of Arbitrum One on Ethereum if there are at least two conflicting answers that pass at the same level in which only one should be valid and pass. This is to halt a class of publicly verifiable and detectable attacks that exploit a bug in the one-step proof. If halted, Arbitrum One will continue to process as normal except that messages from Arbitrum One to Ethereum, such as withdrawals, that are not yet confirmed will have to wait. This provides time for the Security Council to deploy a fix for the bug and resume the rollup.\nPreventing activation of new Stylus contracts. AI-assisted tooling has led to an increasing number of sophisticated attacks on hand-crafted WASM programs that do not use the standard Stylus compiler toolchain. These programs are specifically designed to cause unexpected behaviors such as degrading the chain’s performance for all other users. To date, no attacks have been discovered that permits theft of user funds.\nNew ArbOS releases have patched several reported bugs and known attacks over the past few months, but out of an abundance of caution, we have decided to temporarily pause new activations of Stylus contracts. This was executed as an emergency action to prevent the deployment of new hand-crafted WASM programs that are not yet patched by the current version of ArbOS on the Arbitrum network.\nThe Arbitrum Foundation has informed the Security Council that they will work with the ArbitrumDAO to discuss next steps on the timeline and manner for enabling activation of new Stylus contracts. The Arbitrum community remains confident in the value of Stylus and want to preserve these use cases while taking preventative measures against Stylus-based attack vectors as AI-assisted attack tooling continues to evolve.\nImpact on builders and users\n\nNo new activations. New Stylus contracts cannot be activated during the pause including new versions of existing applications that require activation.\n\nExisting contracts are not paused. Already-active Stylus contracts continue to execute until expiration. This pause does not deactivate them.\n\nThe ArbOS 61 upgrade renewed all active contracts on Arbitrum One, so no currently active contract expires before August 20, 2027.\n\nRenewal via keepalive stays permissionless and is unaffected by the pause.\n\nReactivating an expired contract, or one that needs to be updated after a Stylus version change, is paused.\n\nUsing/calling any activated Stylus contract stays permissionless for all users and developers.\n\nNo impact on EVM. Solidity (EVM) contract deployment and execution are unaffected by this Security Council action.\n\nSecurity Council Actions\nThere are two actions bundled into a single payload:\n\nOne-Step Proof Guard. The L1UpgradeExecutor gives a new pause contract (PauseExecutor) the ability to pause and nothing else. The new pause contract grants the guard (OspSoundnessGuard) PAUSER_ROLE to use it. Anyone can show the guard two conflicting answers to the same step of an open challenge. If the one-step proof accepts both, the guard has the pause contract put Arbitrum One’s settlement to Ethereum on hold.\n\nStylus deactivation. The Security Council called ArbOwner.setWasmActivationGas(2^64 - 1) to raise the Stylus activation gas requirement on Arbitrum One and Nova. This makes activation prohibitively expensive and effectively disables new activations. This is a configuration change and does not require an ArbOS upgrade.\n\nThe Security Council signed the following transactions to update the configuration:\n\nEthereum: Ethereum Transaction Hash: 0x30732bb7d2... | Etherscan\nArbitrum One:\nArbitrum One Transaction Hash: 0x9eb3a4be3b... | Arbitrum One\nArbitrum Nova:\nArbitrum Nova transaction 0x79e0fed470dff7a22059b108e3f8f42eddd2b580a6771594060c4e7326c5f984 | Blockscout\n\nAn external audit was conducted for the OSP Guard contracts. No audit is required for the Stylus deactivation as it is only updating a single parameter in the ArbOS configuration.\n\n Arbitrum Security Program is Live: Applications Now Open \n\n Announcements\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Sep 29\n\n 1 / 1\n\n Sep 28\n\n 8d ago\n\n post by Arbitrum on Sep 29\n\n Arbitrum\n\n Arbitrum Security Program is Live: Applications Now Open\nunnamed1920×960 359 KB\nFollowing the ArbitrumDAO’s approval, the Arbitrum Foundation has launched the Arbitrum Security Program (ASP), a 12-month program covering the full security lifecycle for projects building on Arbitrum.\nThe ASP evolves and broadens the Arbitrum Audit Program, launched in August 2025 with a one-year mandate. It now rests on four pillars:\n\nAI-assisted screening ahead of a full audit\n\nHuman-conducted audits\n\nThe Arbitrum bug bounty program\n\nThe ArbitrumDAO Security Council\n\nThe Foundation is kicking off the ASP’s audit function today, building on learnings from the original program and introducing an updated framework to ensure projects are audit-ready before entering the program, create greater alignment between participating teams and the Arbitrum ecosystem, and make audit funding available to more projects.\nThe Foundation will subsidize a portion of selected projects’ audits, depending on the commercial agreement reached with each project.\nProgram Size\nThe Arbitrum Security Program commits ~7.8M (1.76M USDC and 25M ARB) at today’s market prices to protect the Arbitrum ecosystem. About $1.2M covers the existing Audit Program commitments, with roughly $6.6M going to new work that keeps builders and users safe. The Foundation will subsidize a portion of the selected projects’ audits depending on the commercial agreement reached with each project.\nApplication & Audit Process\nProjects can apply through an open application process. Before the Foundation begins sourcing an auditor, an approved project will need to:\n\nConfirm its codebase is audit-ready\n\nAgree to the applicable audit subsidy\n\nSign a Commitment Agreement with the Arbitrum Foundation\n\nOnce these steps are complete, the Foundation will begin matching the project with an auditor. Selected teams will also have the opportunity to strengthen their codebase with pre-audit AI security screening ahead of their full audit.\nHow to Apply\nThe standardized application form collects key details about the project, team, audit scope, and budget, ensuring a streamlined and fair review. Applications are reviewed based on technical maturity, team, likelihood of success, and alignment with the Arbitrum ecosystem.\nTimeline\nProjects should plan for approximately one month between application approval and the expected start of the audit and should factor this into their development and launch schedules. The program covers the agreed initial audit only. Teams should ensure their code and intended audit scope are ready before entering the process.\nAuditors\nProjects accepted into the program will have access to the same group of leading smart contract security firms that powered the previous audit program:\n\nack3\n\nCertora\n\nCyfrin\n\nDecurity\n\nGuardian\n\nHexens\n\nNethermind\n\nOak Security\n\nOpenZeppelin\n\nOXORIO\n\nPashov Audit Group\n\nSherlock\n\nTrail of Bits\n\nProjects will be matched with an appropriate auditor based on audit scope, technical requirements, and auditor availability.\n Application Form: Applications\n Read the approved proposal for more details: Snapshot\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Arbitrum Security Program\n\n Finalized AIPs\n\n 20\n\n 579\n\n 24d\n\n Arbitrum Audit Program Is Now Live & Accepting Applications\n\n Applications for DAO programs\n\n 0\n\n 280\n\n Aug 2025\n\n Arbitrum Audit Program - Audit Firms Application Process\n\n Applications for DAO programs\n\n 2\n\n 1.4k\n\n Jul 2025\n\n 24 August, 2026 - Roundup of Active/Upcoming Votes\n\n Weekly Voting Reminders & Updates\n\n 0\n\n 67\n\n Aug 24\n\n Improvements to the Arbitrum Audit Program\n\n Finalized AIPs\n\n 13\n\n 514\n\n Apr 24","tokens":2212,"squid":"spider-07","role":"Council Spider","at":1791343411427,"hash":"bc9ddeb5ae23270f50b7bd509748970fc7b3d505"}
{"url":"https://akash.network/current-groups/wg-akash-website/","domain":"akash.network","title":"Akash Website - Community Groups","text":"Back\n Steering Committee Steering Committee Special Interest Groups Analytics Special Interest Group Chain Special Interest Group Clients Special Interest Group Community Special Interest Group Deployments Special Interest Group Design Special Interest Group Documentation Special Interest Group Economics Special Interest Group Education Providers Special Interest Group Support Special Interest Group Working Groups Akash Hackathon Working Group Akash Website Akash Youtube Client Libraries Working Group Content Moderation Working Group Economics 2.0 2023 Events - Working Group GPU Working Group Provider Attributes Working Group Provider Audit Working Group Testnets Working Group Zealy Akash Website This working group is responsible for managing and improving the Akash Network Website. Thank you for wanting to contribute. The Akash Network Website repo can be found [here](https://github.com/akash-network/website). \nView on Discord\n\nView on GitHub\n\nSubscribe to Calendar\n\nAkash Network Website Working Group\nThis working group is responsible for managing and improving the Akash Network Website. Thank you for wanting to contribute. The Akash Network Website repo can be found here.\nMeetings\nFirst Meeting is Tuesday, February 21, 2023 08:30 AM PT (Pacific Time)\n\nMeetingTimeNotesTranscriptRecording#1Tuesday, February 21, 2023 08:30 AM PT (Pacific Time)LinkLinkLink#2Tuesday, March 7, 2023 08:30 AM PT (Pacific Time)LinkLinkLink#3Tuesday, March 22, 2023 08:30 AM PT (Pacific Time)LinkLinkLink#4April 18, 2023 08:30 AM PT (Pacific Time)LinkLinkLink#5Tuesday, May 16, 2023 08:30 AM PT (Pacific Time)LinkLinkLink#6Thursday, June 13, 2023 08:30 AM PT (Pacific Time)LinkLinkLink#7Tuesday, June 27, 2023 08:30 AM PT (Pacific Time)LinkLinkLink#8Thursday, August 10, 2023 06:30 AM PT (Pacific Time)LinkLinkLink#9Thursday, August 17, 2023 06:30 AM PT (Pacific Time)LinkLinkLink#10Thursday, August 24, 2023 07:30 AM PT (Pacific Time)LinkLinkLink#11Thursday, September 14, 2023 06:30 AM PT (Pacific Time)LinkLinkLink#12Thursday, October 12, 2023 06:30 AM PT (Pacific Time)LinkLinkLink#13Thursday, October 19, 2023 06:30 AM PT (Pacific Time)LinkLinkLink#14Thursday, October 26, 2023 06:30 AM PT (Pacific Time)LinkLinkLink#15Thursday, November 02, 2023 06:30 AM PT (Pacific Time)LinkLinkLink#16Thursday, November 09, 2023 06:30 AM PT (Pacific Time)Coming soonComing soonComing Soon#17Thursday, November 16, 2023 06:30 AM PT (Pacific Time)LinkLinkLink#18Thursday, November 27, 2023 06:30 AM PT (Pacific Time)LinkLinkLink#19Thursday, November 30, 2023 06:30 AM PT (Pacific Time)LinkLinkLink#20Thursday, December 07, 2023 06:30 AM PT (Pacific Time)LinkLinkLink#21Wednesday, January 03, 2023 06:30 AM PT (Pacific Time)Coming soonComing soonComing Soon#22Thursday, January 04, 2023 06:30 AM PT (Pacific Time)LinkLinkLink#23Friday, January 05, 2023 06:30 AM PT (Pacific Time)LinkLinkLink#29Thursday, April 04, 2024 06:30 AM PT (Pacific Time)LinkLinkLink#30Thursday, May 16, 2024 06:30 AM PT (Pacific Time)LinkLinkLink#31Thursday, June 13, 2024 06:30 AM PT (Pacific Time)LinkLinkLink#32Thursday, July 25, 2024 06:30 AM PT (Pacific Time)LinkLinkLink#33Thursday, August 8, 2024 06:30 AM PT (Pacific Time)LinkLinkLink#34Thursday, August 22, 2024 06:30 AM PT (Pacific Time)LinkLinkLink#35Thursday, September 5, 2024 06:30 AM PT (Pacific Time)LinkLinkLink#36Thursday, September 19, 2024 06:30 AM PT (Pacific Time)LinkLinkLink#37Thursday, October 24, 2024 06:30 AM PT (Pacific Time)LinkLinkLink#38Thursday, November 28, 2024 06:30 AM PT (Pacific Time)LinkLinkLink\nLeads\n\nDenis Lelic\nTyler Wright\nZach Horn\n\nContacts\n\nDiscord\n\nGoals\n\nTriage Akash Website issues\nAssign issues to working group members to improve the website on front end and back end.\nIdeate and implement new website pages and features.\n\nPRDs and other documentation\n\nCode of Conduct\nHow to contribute to the Akash Network website\n\nRelated SIGs\n\nsig-community\nsig-design\n Akash Hackathon Working Group Akash Youtube","tokens":992,"squid":"spider-03","role":"Compute Spider","at":1791343421058,"hash":"cb6a608850ea7528b231c5f0725311ced66edee5"}
{"url":"https://forum.across.to/t/reward-locking-parameter-changes-increase-base-emissions-decrease-max-multiplier/1704/15","domain":"forum.across.to","title":"Reward Locking Parameter Changes: Increase Base Emissions, Decrease Max Multiplier - Proposals - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n Proposals\n\n governance-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 Aug 2023\n\n 15 / 15\n\n Sep 2023\n\n Aug 2023\n\n post by Kevin_UMA on Aug 23, 2023\n\n post by Mide on Aug 23, 2023\n\n post by berry4144 on Aug 23, 2023\n\n post by berry4144 on Aug 23, 2023\n\n post by mydefi on Aug 23, 2023\n\n post by Mide on Aug 24, 2023\n\n post by caesarsherrod.eth on Aug 24, 2023\n\n post by nico186 on Aug 26, 2023\n\n post by kodada on Aug 27, 2023\n\n post by Kevin_UMA on Aug 28, 2023\n\n post by Kevin_UMA on Aug 28, 2023\n\n post by Kevin_UMA on Aug 28, 2023\n\n Kevin_UMA\n\n kodada\n\n It’s definitely not close to full utilization all the time and it depends on the asset. However, at times of stress in the market we have seen Across pool assets close to being exhausted and resulting in much higher bridge fees. More TVL would ensure that we avoid these scenarios and continue to remain the fastest and cheapest bridge.\n\n post by Mide on Aug 28, 2023\n\n Mide\n\n Kevin_UMA\n\n Sure thing! I’m willing to collaborate with the community if this is something they’d be interested in along the lines of our growth, glad you like the idea!\n\n post by ayoki on Aug 29, 2023\n\n ayoki\n\n It’s great to see the positive outlook towards potential changes in the multiplier. I think this is a great proposal in that it provides a solution to a pressing liquidity issue that makes strategic use of protocol incentives, while retaining the multiplier function, which I agree is a highly praised innovation of Across.\nEspecially with our recent and upcoming deployments to new chains, I think it’s a great time to capture a new group of LP capital while we have the attention of a wider audience.\n\n 1 month later\n\n Closed on Sep 28, 2023\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 Reduce or Reallocate Across ACX LP emissions\n\n Ideas & Feedback\n\n liquidity\n\n Ideas & Feedback\n\n 2\n\n Sep 2023\n\n Reduce ACX emissions for Across ACX LPs\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 8\n\n Nov 2023\n\n Across Token Launch Proposal v2\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 47\n\n Nov 2022\n\n ACX Emissions Committee\n\n Proposals\n\n governance-updates\n\n Proposals\n\n Dec 2023\n\n Reduce ACX emissions for ACX LPs, WBTC LPs and wstETH/ACX LPs\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 11\n\n Aug 2024","tokens":2099,"squid":"spider-09","role":"Bridge Spider","at":1791343421111,"hash":"2c8f0cbebfe40cf38ab76870580549e298fdb36e"}
{"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 2d 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 5 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 2 days 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 2 days 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":745,"squid":"spider-04","role":"Research Spider","at":1791343426026,"hash":"7b7a18c45dac6b4d72570589649f3dd758ff6d55"}
{"url":"https://akash.network/current-groups/sig-deployments/","domain":"akash.network","title":"Deployments Special Interest Group - Community Groups","text":"Back\n Steering Committee Steering Committee Special Interest Groups Analytics Special Interest Group Chain Special Interest Group Clients Special Interest Group Community Special Interest Group Deployments Special Interest Group Design Special Interest Group Documentation Special Interest Group Economics Special Interest Group Education Providers Special Interest Group Support Special Interest Group Working Groups Akash Hackathon Working Group Akash Website Akash Youtube Client Libraries Working Group Content Moderation Working Group Economics 2.0 2023 Events - Working Group GPU Working Group Provider Attributes Working Group Provider Audit Working Group Testnets Working Group Zealy Deployments Special Interest Group Akash Network - Deployments Special Interest Group (SIG) \nView on Discord\n\nView on GitHub\n\nSubscribe to Calendar\n Akash Network - Deployments Special Interest Group (SIG)\nMeetings\nNo future meetings scheduled (updated 2023-02-02)\n\nMeetingTimeNotesTranscriptRecording#1Wednesday, February 1, 2023 9:00 AM PT (Pacific Time)LinkLinkLink\nLeadership\nContact\n\nDiscord Server\n\nSub Projects, Repositories & Relevant Work Groups\nThe following are projects and work-groups that sig-deployments participates in or contributes to Community Special Interest Group Design Special Interest Group","tokens":327,"squid":"spider-03","role":"Compute Spider","at":1791343433126,"hash":"92ced2f58c808b71b44d0239898b5b580da95248"}
{"url":"https://forum.across.to/t/across-token-launch-proposal-v2/849","domain":"forum.across.to","title":"Across Token Launch Proposal v2 - Tokenomics (old) - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n Across Token Launch Proposal v2 \n\n Tokenomics (old)\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Apr 2022\n\n 1 / 48\n\n Apr 2022\n\n Nov 2022\n\n post by Kevin_UMA on Apr 28, 2022\n\n Kevin_UMA\n\n This is a revised proposal that builds on the initial Across token launch proposal with added community feedback and implementation details.\nThe launch of an Across token will grow and unite the Across community, incentivize liquidity providers, increase awareness of Across, and further the mission of being the fastest and cheapest L2 bridge. This proposal outlines a token launch plan and can be largely divided into two parts:\n\nInitial Distribution - a diversified airdrop and a treasury token swap\n\nReward Locking Incentive Program - a novel rewards program to incentivize actions that support the Across protocol\n\nPart 1 - Initial Distribution\n\n1,000,000,000 Across tokens ($ACX) will be minted. 700,000,000 $ACX will remain in the Across Dao Treasury and a portion will be reserved for incentive rewards. 300,000,000 $ACX will be the initial supply and distributed in the following way:\n$ACX Airdrop - 100,000,000 $ACX in total will be rewarded to the following groups:\n\n10%: Across community Discord members with “Co-founder” or “Early Recruit”\n10%: Across community Discord members with “DAO Contributor” or “Senior DAO Contributor”\n20%: Tokens will be reserved as an additional bonus for significant early contributors to the Across community which may include DAO contributors, Senior DAO contributors and the Developer Support Team. After token launch, the community will have the opportunity to submit proposals as to how this should be allocated and $ACX holders will vote via snapshot.\n10%: Early Across protocol users who bridged assets before March 11, 2022. These tokens will be allocated to wallets pro-rata by the volume of transfer completed. The numbers will be adjusted to filter out small transfers that are likely from airdrop farmers.\n50%: Liquidity providers who pool ETH, USDC, WBTC, and DAI into the Across protocol before the token launch. The amount of rewards to LPs are pro-rated by size and a fixed amount of tokens will be emitted at each block since the inception of the protocol.\n\n*Weights and exact details are all subject to change and dependent on the data collected ahead of token launch.\nToken Swap for $UMA - 100,000,000 $ACX will be swapped with the Risk Labs Treasury for $5,000,000 worth of $UMA. This achieves two goals - it gives the Across community ownership and governance power in UMA which is critical to the security of the bridge, and it also provides voting rewards as a source of income to the Across DAO treasury. Risk Labs launched Across and will continue to support the protocol and community for the foreseeable future. Providing $ACX to Risk Labs will further incentivize the Risk Labs team. Risk Labs may consider using these tokens to build and expand a dedicated development team, to help provide liquidity in $ACX, and participate in governance. Regardless of use, these tokens will only be used to the benefit of the protocol.\nStrategic Partners and Relayer Capital - 100,000,000 $ACX will be transferred to Risk Labs Treasury to raise funds and secure loans from key players in the DeFi industry. Competitors in the bridge space are partnering with large institutions and obtaining substantial resources to propel their growth. Risk Labs can use these tokens to help Across protocol do the same. A key resource constraint is the relayer network where a significant amount of capital is provided by Risk Labs’ treasury. Partnering with large and well capitalized crypto players can help alleviate this bottleneck and accelerate growth. To achieve this goal, Risk Labs may use these $ACX tokens for a success token fund raise, for collateral when borrowing via range tokens, and for rewards to facilitate the decentralization of the relayer network.\n\nPart 2 - Across Reward Locking Incentive Program\n\nA significant portion of the 700,000,000 $ACX in reserve will be emitted through this incentive program and community members can earn $ACX by doing any of the following actions:\n\nStake Across LP shares from bridge pools - WETH and USDC pools will be the first Across pools to be incentivized\nStake $ACX LP shares from a designated $ACX/ETH pool\nRefer users through the Across Referral Program\n\nLiquidity Providers - Reward locking is an enhanced version of traditional liquidity mining that discourages farm and dump activity while rewarding loyal contributors to the protocol. Liquidity providers (LPs) have an individualized rate at which they earn rewards. The longer a LP keeps accumulated rewards unclaimed (and unsold) the faster the LP earns additional rewards.\nEach incentivized liquidity pool will have a base rate of emission and each LP will have a unique multiplier for each of these pools. The LP will earn a pro-rata share of the base rate emission multiplied by the LP’s unique multiplier. A LP’s multiplier starts at 1 on day zero and can grow linearly to a maximum of 3 when rewards are left unclaimed for 100 days. The table below illustrates this simple progression. As an example, a LP that has held rewards unclaimed for 60 days will have a 2.2 multiplier. Once a LP claims ANY rewards the multiplier immediately resets to 1 and the LP would need to earn that multiplier again.\n\nDays Held\nMultiplier\n\n0\n1.0\n\n25\n1.5\n\n50\n2.0\n\n75\n2.5\n\n100\n3.0\n\nThe initial reward locking program will be expected to operate for 6 months and will be reviewed at that point in time for any changes. The program will start with the following base emission rate:\n~100,000 $ACX per day for Across ETH LP shares\n~100,000 $ACX per day for Across USDC LP shares\n~20,000 $ACX per day for designated $ACX/$ETH LP shares\nThis equates to roughly 4MM to 10MM $ACX depending on the behavior of LPs. $ACX holders can propose and vote to add new assets or change these parameters at any time.\nAcross Referral Program - The referral program will convert the Across community into a sales force. To participate in the referral program, Across supporters can enter their wallet address to generate a unique referral link. A user who clicks that link and completes a bridge transfer on Across will attribute $ACX rewards to the referrer. Supporters are encouraged to share their link with friends and promote Across on social media, such as Twitter. This can also be used in integrations with other projects. A bridge aggregator or a DEX can create a referral link to connect Across to their dApp. Once that link is clicked and a bridge transfer is completed, rewards will be allocated to that project. All future transfers completed by that wallet will continue to attribute rewards to the referrer unless the user of the wallet clicks a different referral link or the referrer claims their rewards.\nSimilar to reward locking for LPs, referrers can increase the rate they earn referral fees by keeping their rewards unclaimed and reaching a specific number of referrals or securing an amount of volume. The referral fee is a percentage of the bridge LP fee awarded to the referrers in $ACX. If rewards are not claimed and a certain number of referrals or volume is done then the referral fee goes up. There are five tiers of referrers:\n\nCopper: 40% referral fee.\nBronze: 50% referral fee. Copper referrers progress to Bronze after 3 referrals or > $50k in bridge volume\nSilver: 60% referral fee. Bronze referrers progress to Silver after 5 referrals or > $100k in bridge volume\nGold: 70% referral fee. Silver referrers progress to Gold after 10 referrals or > $250k in bridge volume.\nPlatinum: 80% referral fee. Gold referrers progress to Platinum after 20 referrals or > $500k in bridge volume.\n\nReferral rewards are attributed weekly and referrers can only increase a tier per week. Once a referrer claims rewards, the referrer’s tier immediately resets back to Copper and all referral links are broken. This means referrers will need to get users to click on their referral link again to continue earning referral fees, and the referrers will need to regain their tier which will take a minimum of 5 weeks to reach Platinum.\nReward Locking = Gamification of DeFi\nThe benefits of Reward Locking are clear. Keeping rewards locked discourages farm and dump activity, but more importantly it makes the LP and referrer more engaged with the protocol. If you are encouraged to have a stake in the protocol you will naturally want to know more about it and you are incentivized to join the community and further its mission.\nGiven the various unique multipliers you can earn for each liquidity pool and the different tiers you can acquire as a referrer, each wallet that contributes to the protocol will develop a personalized identity. Similar to a character in a role playing game, the various stats can be translated into experience points that could allow the wallet to level up and obtain status in the protocol.\nReward locking can be gamified further with a well thought out user interface and user experience to make it appear like an actual game. It can be built similar to a RPG where users can earn special NFTs or items for reaching certain milestones. Community members could build this and/or an actual game that uses these stats and do battles with one another. As well, a leader board can recognize the accomplishments of all committed Across users. This would all work to make the user very reluctant to claim their rewards and fall in status.\nStaked $ACX - As the protocol matures, the community can consider a staking mechanism for $ACX which could grant further governance rights and also share in Across protocol revenue. Governance can dictate where incentive rewards will be directed in order to determine which tokens and which L2 should get more liquidity. This vote lock like mechanism can add further value to $ACX and the Across protocol.\n\nConclusion\n\nIn addition to building community and incentivizing project goals, the Across token launch aims to create value and meaning to owning $ACX. The objective is to have $ACX token holders interact with the protocol through their token as soon as it is launched. In fact, by outlining what actions will be rewarded ahead of the airdrop, the protocol is encouraging Across LP activity now. The Across Reward Locking Incentive Program will engage community members and use $ACX as a currency to gamify and incentivize contributions to the protocol. The $ACX token will represent real ownership of the Across protocol in terms of economics and governance.\nFeedback on this proposal is very much welcome. Mechanics and numbers can and should all be discussed so that the community is comfortable ahead of this token launch.\n\n 6\n\n 3\n\n 2\n\n 2\n\n 2\n\n read \n\n 18\n min\n\n post by Tjex on Apr 29, 2022\n\n Tjex\n\n Proposal seems fair and rewarding to community builders and aims to bring more users to the protocol after the token launch. Support it.\n\n post by Ptrck on Apr 29, 2022\n\n Ptrck\n\n In general, I think the proposal is great.\nExcept the part about the airdrop.\nWhy limit it to users who bridged assets before March 11, 2022? And why do it pro-rata? (I understand: To avoid/prevent airdrop hunters. But I think this is a mistake)\nIt will cut out a quite lot of people who have smaller budgets. They would be thrilled to get an airdrop and talk positive about Across.\nOne of the main goal - if not the most important goal- of an airdrop is: Bring awareness to the protocol. We won’t get much awareness to the protocol by doing it like that.\nWe can learn something from the Optimism airdrop. Especially:\n\nPush the snapshot date to a date which is further in the future (Suggestion: Remove this part from the proposal at all where we talk about the snapshot date and take a snapshot at the end of May 2022)\nPlan in a 2nd and possibly 3rd airdrop (1st = 50,000,000 $ACX, 2nd = 25,000,000 $ACX and 3rd = 25,000,000 $ACX)\n\nI suggest we do that.\n\n post by Kastormagic on Apr 29, 2022\n\n Kastormagic\n\n Thanks for your work Kevin. I have two questions:\n\nI understand the interest of incentivizing ETH, USDC, WBTC and DAI LPs, but are there plans to do the same with other LPs? This would increase the TVL. Badger, for example, has a higher pool utilization than ETH (30% vs. 24.8%).\n\nIs there an anti-sybil mechanism to prevent playing the referral program or could someone use their referral link with multiple wallets to increase levels?\n\n post by Phuktep on Apr 29, 2022\n\n Phuktep\n\n This new proposal looks great. There had been a significant amount of thought and discussion regarding incorporating an s-curve into the distribution of the LP rewards. Is that still being considered? The quote below makes it look like we are going straight by volume. That’s fine, but it would be helpful to explicitly state that since there has been a fair amount of discussion around that.\n“The amount of rewards to LPs are pro-rated by size and a fixed amount of tokens will be emitted at each block since the inception of the protocol.”\n\n post by motif on Apr 29, 2022\n\n motif\n\nThere should be an option for users to add FURTHER non ACX tokens to their emissions and either increase their multiplier or not loose existing multiplier.\nAchieves 2 things:\n1- Incentivises deposits of additional “useful” capital\n2- Reduces ACX dumping .\n\n post by motif on Apr 29, 2022\n\n motif\n\nWould be interesting to know thoughts behind reduced incentives for the ACX/ETH pairing.\nI would have thought that might need additional incentives? Asking for learning as I know you have a large amount of experience…\n\n post by motif on Apr 29, 2022\n\n motif\n\nIs there a “self referrer” option? - A user might not feel too confident promoting across, that might not be their thing, but if they have incentive to come back and keep “levelling up” - they will want to. Kind of like a cashback credit card…\n\n post by Britt on Apr 29, 2022\n\n Britt\n\n Kastormagic\n\n My understanding is that there aren’t any mechanisms in place to prevent this type of action. However, the user would need to actually complete a transfer to gain the referral. There may be a weakness in this (hopefully Kevin can share more), but it seems like a net positive for Across to have more volume and a net negative to a user to break up their funds to transfer them.\n\n post by Britt on Apr 29, 2022\n\n Britt\n\n Phuktep\n\n @Kevin_UMA flagging you on this one\n\n post by fukuyamasato on Apr 29, 2022\n\n fukuyamasato\n\n10%: Early Across protocol users who bridged assets before March 11, 2022. These tokens will be allocated to wallets pro-rata by the volume of transfer completed. The numbers will be adjusted to filter out small transfers that are likely from airdrop farmers.\n\n10% is already a small portion of the airdrop. I don’t think it’s a good idea to distribute airdrop according to volume. It will bring too many negative comments in social media. If we want to reward whales/big investors, we should come up with a new category that seperates them small investors.\n\n post by Ptrck on Apr 29, 2022\n\n Ptrck\n\n In regards to having multiple airdrop:\n\n Optimism's Airdrop Is The Future of Governance | Weekly Roundup\n\n(timestamp 15:20)\n\n post by Ptrck on Apr 29, 2022\n\n Ptrck\n\nWhat about the LPers who provide LP with $UMA?\n\n post by Andy on Apr 29, 2022\n\n Andy\n\n Really nice looking proposal - I Lp’ed early because I believe in L2’s. I think early liquidity providers are a fundamental part of why Across is where it is, and the majority of that liquidity is not mercenary or looking to make a quick buck by dumping gov tokens.\n\n post by purgatorius91 on Apr 29, 2022\n\n purgatorius91\n\n Ptrck\n\n I agree with you. It can be given to anyone who has used the bridge to raise awareness. Other than that, the proposal is pretty fair.\n\n post by pzhome on Apr 30, 2022\n\n pzhome\n\n I agree with you.Really nice looking proposal\n\n post by carrie on Apr 30, 2022\n\n carrie\n\n In general, I think the proposal is great.\n\n post by Defgrip on Apr 30, 2022\n\n Defgrip\n\n Ptrck\n\n I agree with you on this\n\n post by Ptrck on Apr 30, 2022\n\n Ptrck\n\nAnother reason why I think we need to delay the snapshot to date in the future: The Arbitrum Odyssey is coming up. Regardless of whether we (Across) are chosen for the Odyssey or not. There will be a lot of bridging going on. I think it would be a big mistake to announce to the world “IF you wanna bridge with us. You can do it. But the snapshot has already being taken. So you won’t get an airdrop”. We need to involve those people. Otherwise Across will stand no chance against other bridges\n\n post by TheRealTuna_Across on Apr 30, 2022\n\n TheRealTuna_Across\n\n This seems to cover all the bases. Is there a way we could acquire some protocol owned liquidity or have Risk Labs provide some liquidity for ACX/ETH, ACX/USDC, and ACX/UMA pairs. Perhaps with the strategic capital raise.\n\n Load more posts below","tokens":5711,"squid":"spider-09","role":"Bridge Spider","at":1791343433210,"hash":"47058046aba6803a6dca3f0c1993a5b24d975bdf"}
{"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 2d 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 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 5 days ago\n\n post by AnkushinDaniil 2 days ago\n\n post by mmjahanara 2 days ago\n\n Powered by Discourse","tokens":3473,"squid":"spider-04","role":"Research Spider","at":1791343436159,"hash":"30eaeffa1969a955fd351c224024d2331012184c"}
{"url":"https://akash.network/current-groups/sig-documentation/","domain":"akash.network","title":"Documentation Special Interest Group - Community Groups","text":"Back\n Steering Committee Steering Committee Special Interest Groups Analytics Special Interest Group Chain Special Interest Group Clients Special Interest Group Community Special Interest Group Deployments Special Interest Group Design Special Interest Group Documentation Special Interest Group Economics Special Interest Group Education Providers Special Interest Group Support Special Interest Group Working Groups Akash Hackathon Working Group Akash Website Akash Youtube Client Libraries Working Group Content Moderation Working Group Economics 2.0 2023 Events - Working Group GPU Working Group Provider Attributes Working Group Provider Audit Working Group Testnets Working Group Zealy Documentation Special Interest Group The goal of this SIG is to foster a community around the creation and maintenance of top-tier documentation to facilitate the growth of Akash Network. \nView on Discord\n\nView on GitHub\n\nSubscribe to Calendar\n\nAkash Network - Documentation Special Interest Group (SIG)\nThe goal of this SIG is to foster a community around the creation and maintenance of top-tier documentation to facilitate the growth of Akash Network by enabling greater understanding and clarity. Effective documentation will cater to the developer and the curious, driving deployemnts on the Akash Network as a whole.\nMeetings\nThis meeting is now held every four months, on the fourth Tuesday at 7:00 AM Pacific Time.\n\nMeetingTimeNotesTranscriptRecording#1Tuesday, January 24, 2023 7:00 AM PT (Pacific Time)LinkLinkLink#2Tuesday, February 28, 2023 7:00 AM PT (Pacific Time)LinkLinkLink#3Tuesday, March 28, 2023 07:00 AM PT (Pacific Time)LinkComing SoonComing Soon#4Tuesday, April 25, 2023 07:00 AM PT (Pacific Time)LinkLinkLink#5Tuesday, May 23, 2023 07:00 AM PT (Pacific Time)LinkLinkLink#6Tuesday, June 27, 2023 07:00 AM PT (Pacific Time)LinkLinkLink#7Tuesday, July 25, 2023 07:00 AM PT (Pacific Time)LinkLinkLink#8Tuesday, August 22, 2023 07:00 AM PT (Pacific Time)LinkLinkLink#9Tuesday, September 26, 2023 07:00 AM PT (Pacific Time)LinkLinkLink#10Tuesday, October 24, 2024 07:00 AM PT (Pacific Time)LinkLinkLink#11Tuesday, November 28, 2024 07:00 AM PT (Pacific Time)LinkLinkLink#12Tuesday, December 19, 2023 07:00 AM PT (Pacific Time)LinkLinkLink#13Tuesday, January 23, 2024 07:00 AM PT (Pacific Time)LinkLinkLink#14Tuesday February 27, 2024 07:00 AM PT (Pacific Time)LinkLinkComingn Soon#15March 26, 2024 07:00 AM PT (Pacific Time)LinkLinkLink#16April 23, 2024 07:00 AM PT (Pacific Time)Coming Soon#17June 05, 2024 07:00 AM PT (Pacific Time)Coming Soon#18February 25, 2025 07:00 AM PT (Pacific Time)LinkLinkLink#19June 25, 2025 07:00 AM PT (Pacific Time)LinkLinkLink#20January, 2026 07:00 AM PT (Pacific Time)#21February 2026 07:00 AM PT (Pacific Time)#22March, 2026 07:00 AM PT (Pacific Time)#23April 2026 07:00 AM PT (Pacific Time)#24May, 2026 07:00 AM PT (Pacific Time)#25June, 2026 07:00 AM PT (Pacific Time)\nWorking Group Sessions for Docs 2.0\n\nMeetingTimeNotesTranscriptRecording#1Thursday, April 13, 2023 11:00 AM PT (Pacific Time)#2Wednesday, May 10, 2023 10:00 AM PT (Pacific Time)#3Monday, May 22, 2023 07:00 AM PT (Pacific Time)\nLeadership\n\nScott Carruthers, Overclock Labs\nTyler Wright\nJoao Luna\nZach Horn\nDenis Lilic\n\nContact\n\nDiscord Server\n\nSub Projects, Repositories & Relevant Work Groups\nThe following are projects and work-groups that sig-docs participates in or contributes to:\n\nDocs 2.0\n[Akash Website Working Group]\n Design Special Interest Group Economics Special Interest Group","tokens":876,"squid":"spider-03","role":"Compute Spider","at":1791343443292,"hash":"93c8d23e376664a93b00a354db1d20b61c6c12ce"}
{"url":"https://forum.across.to/t/across-token-launch-proposal-v2/849/50","domain":"forum.across.to","title":"Across Token Launch Proposal v2 - Tokenomics (old) - Across Protocol","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 2\n\n read \n\n 18\n min\n\n Apr 2022\n\n 48 / 48\n\n Nov 2022\n\n Nov 2022\n\n Load more posts above\n\n post by Jason666 on May 3, 2022\n\n Jason666\n\n 我觉得应该分配 dappback 参与者\n\n post by Kevinswap on May 3, 2022\n\n Kevinswap\n\n My addition is, there should be some criteria to filter out Co-founder that is not relevant anymore, can be from texts count or something like that (For example: Lyra did that).\nIt’s because the purpose of this token is for governance, member who doesn’t care about the project should not get the tokens or too much rights to vote.\nAnd what about the roles like Translatooors, Buildooors ETC.?\nMe, myself (A translatooor) already translated Across’s doc and gained knowledge about how Across works.\nWhat I gonna say is these groups of people (Who already did the works) know Across better than 90% of members and will be your die-hard fans, which mean that, when there is something to DAO or vote for, these members will know which direction should Across go.\n\n post by Polo on May 3, 2022\n\n Polo\n\n Could you include liquidity providers who pooled UMA in the airdrop as well?\nI don’t find it fair that they’re being excluded, is there a good reason for it?\n\n post by rhorse on May 3, 2022\n\n rhorse\n\n This looks great.\nAny thought to including 5% airdrop to users of competing protocols, such as HOP? (If there was discussion, sorry that I missed it)\n2022 feels like it’s shaping up to be the most competitive year yet for L2 protocols; some outreach to other communities might be strategic and helpful.\n\n post by CRYPTO_BRO_S_GGEZ on May 4, 2022\n\n CRYPTO_BRO_S_GGEZ\n\n Kevinswap\n\n totally agree, with Mr.Kevinswap\n\n post by Ptrck on May 4, 2022\n\n Ptrck\n\n rhorse\n\n Uh, a vampire attack. Dirrty (but nice) idea \n\n post by Moo.eth on May 4, 2022\n\n Moo.eth\n\n This proposal is very detailed and does not abandon everyone who contributes to the community. There is no so-called “core team” or “developers” to make this decision for the community. We are community members and everyone is a contributor. If the community wants something - each contributor should do something to make it happen. In other words, community is everyone’s responsibility, and if we fail as a community, we have no one to blame but ourselves.\n\n post by Monkey_M on May 7, 2022\n\n Monkey_M\n\n Hello team，i am a student with little capital and i only have little capital in my wallet，I transfered 0.1eth from LI to L2. the gas is not very low… Personally think. 0.1eth is already big amount for me. and i am not a airdrop farmer… i am wondering if the bridged assets could change to 0.1eth? that is fair. After all. we did it.\nand we also care about the onging- status of the project after that, why should we be flitered?\nThat would be very very sad.\n\n post by Defgrip on May 7, 2022\n\n Defgrip\n\n Ptrck\n\n this is great. im excited to see this all come together\n\n 9 days later\n\n post by DD888888 on May 16, 2022\n\n DD888888\n\nDappback makes users more aware of Across, and also allows Across to be recognized by more people. I recommend giving rewards.\n\n post by xiangguacheng on May 16, 2022\n\n xiangguacheng\n\n In general, this proposal is very good, if the weight of large funds is balanced, it may better serve the community.\n\n post by Abbeey on May 16, 2022\n\n Abbeey\n\n purgatorius91\n\n Overall I agree with this proposal👍\n\n post by 1104463457 on May 16, 2022\n\n 1104463457\n\n Users should not limit the amount of money, which will hurt the original users. Although there was no large demand before, it doesn’t mean that there will be no large demand in the future. This is not a good proposal. You should learn from the op just dropped, and 10% is already very few.\nthanks\n\n post by zsp1986 on May 16, 2022\n\n zsp1986\n\n Ptrck\n\n The percentage of co-founders is getting lower and lower\n\n post by AIlin on May 16, 2022\n\n AIlin\n\n In the contribution section, are we going to reward users of channel boosters? Of course, some measures must be taken to screen the airdrop farmers. Maybe a time-based snapshot could be made, listing booster users before the token plan was announced as one of the contributors. Farmers will only pay for rewards, and early booster users are using real money to support the channel.\n\n post by akywev on May 16, 2022\n\n akywev\n\n Kevin_UMA\n\n nice,I look forward to improving it as soon as possible, and I will always support it\n\n post by ailun.eth on May 16, 2022\n\n ailun.eth\n\n Please let the market stimulate ACX, let more users pay attention to it and understand it\n\n post by Igor55 on May 19, 2022\n\n Igor55\n\n Skip to main content\n\nAcross Token Launch Proposal v2\nTokenomics\n1\n/\n45\n\nKevin_UMA\n20d\nThis is a revised proposal that builds on the initial Across token launch proposal with added community feedback and implementation details.\nThe launch of an Across token will grow and unite the Across community, incentivize liquidity providers, increase awareness of Across, and further the mission of being the fastest and cheapest L2 bridge. This proposal outlines a token launch plan and can be largely divided into two parts:\n\nInitial Distribution - a diversified airdrop and a treasury token swap\nReward Locking Incentive Program - a novel rewards program to incentivize actions that support the Across protocol\n\nPart 1 - Initial Distribution\n\n1,000,000,000 Across tokens ($ACX) will be minted. 700,000,000 $ACX will remain in the Across Dao Treasury and a portion will be reserved for incentive rewards. 300,000,000 $ACX will be the initial supply and distributed in the following way:\n$ACX Airdrop - 100,000,000 $ACX in total will be rewarded to the following groups:\n\n10%: Across community Discord members with “Co-founder” or “Early Recruit”\n10%: Across community Discord members with “DAO Contributor” or “Senior DAO Contributor”\n20%: Tokens will be reserved as an additional bonus for significant early contributors to the Across community which may include DAO contributors, Senior DAO contributors and the Developer Support Team. After token launch, the community will have the opportunity to submit proposals as to how this should be allocated and $ACX holders will vote via snapshot.\n10%: Early Across protocol users who bridged assets before March 11, 2022. These tokens will be allocated to wallets pro-rata by the volume of transfer completed. The numbers will be adjusted to filter out small transfers that are likely from airdrop farmers.\n50%: Liquidity providers who pool ETH, USDC, WBTC, and DAI into the Across protocol before the token launch. The amount of rewards to LPs are pro-rated by size and a fixed amount of tokens will be emitted at each block since the inception of the protocol.\n\nWeights and exact details are all subject to change and dependent on the data collected ahead of token launch.\n\nToken Swap for $UMA - 100,000,000 $ACX will be swapped with the Risk Labs Treasury for $5,000,000 worth of $UMA. This achieves two goals - it gives the Across community ownership and governance power in UMA which is critical to the security of the bridge, and it also provides voting rewards as a source of income to the Across DAO treasury. Risk Labs launched Across and will continue to support the protocol and community for the foreseeable future. Providing $ACX to Risk Labs will further incentivize the Risk Labs team. Risk Labs may consider using these tokens to build and expand a dedicated development team, to help provide liquidity in $ACX, and participate in governance. Regardless of use, these tokens will only be used to the benefit of the protocol.\nStrategic Partners and Relayer Capital - 100,000,000 $ACX will be transferred to Risk Labs Treasury to raise funds and secure loans from key players in the DeFi industry. Competitors in the bridge space are partnering with large institutions and obtaining substantial resources to propel their growth. Risk Labs can use these tokens to help Across protocol do the same. A key resource constraint is the relayer network where a significant amount of capital is provided by Risk Labs’ treasury. Partnering with large and well capitalized crypto players can help alleviate this bottleneck and accelerate growth. To achieve this goal, Risk Labs may use these $ACX tokens for a success token fund raise, for collateral when borrowing via range tokens , and for rewards to facilitate the decentralization of the relayer network.\n\nPart 2 - Across Reward Locking Incentive Program\n\nA significant portion of the 700,000,000 $ACX in reserve will be emitted through this incentive program and community members can earn $ACX by doing any of the following actions:\n\nStake Across LP shares from bridge pools - WETH and USDC pools will be the first Across pools to be incentivized\nStake $ACX LP shares from a designated $ACX/ETH pool\nRefer users through the Across Referral Program\n\nLiquidity Providers - Reward locking is an enhanced version of traditional liquidity mining that discourages farm and dump activity while rewarding loyal contributors to the protocol. Liquidity providers (LPs) have an individualized rate at which they earn rewards. The longer a LP keeps accumulated rewards unclaimed (and unsold) the faster the LP earns additional rewards.\nEach incentivized liquidity pool will have a base rate of emission and each LP will have a unique multiplier for each of these pools. The LP will earn a pro-rata share of the base rate emission multiplied by the LP’s unique multiplier. A LP’s multiplier starts at 1 on day zero and can grow linearly to a maximum of 3 when rewards are left unclaimed for 100 days. The table below illustrates this simple progression. As an example, a LP that has held rewards unclaimed for 60 days will have a 2.2 multiplier. Once a LP claims ANY rewards the multiplier immediately resets to 1 and the LP would need to earn that multiplier again.\n\nDays Held\nMultiplier\n\n0\n1.0\n\n25\n1.5\n\n50\n2.0\n\n75\n2.5\n\n100\n3.0\n\nThe initial reward locking program will be expected to operate for 6 months and will be reviewed at that point in time for any changes. The program will start with the following base emission rate:\n~100,000 $ACX per day for Across ETH LP shares\n~100,000 $ACX per day for Across USDC LP shares\n~20,000 $ACX per day for designated $ACX/$ETH LP shares\nThis equates to roughly 4MM to 10MM $ACX depending on the behavior of LPs. $ACX holders can propose and vote to add new assets or change these parameters at any time.\nAcross Referral Program - The referral program will convert the Across community into a sales force. To participate in the referral program, Across supporters can enter their wallet address to generate a unique referral link. A user who clicks that link and completes a bridge transfer on Across will attribute $ACX rewards to the referrer. Supporters are encouraged to share their link with friends and promote Across on social media, such as Twitter. This can also be used in integrations with other projects. A bridge aggregator or a DEX can create a referral link to connect Across to their dApp. Once that link is clicked and a bridge transfer is completed, rewards will be allocated to that project. All future transfers completed by that wallet will continue to attribute rewards to the referrer unless the user of the wallet clicks a different referral link or the referrer claims their rewards.\nSimilar to reward locking for LPs, referrers can increase the rate they earn referral fees by keeping their rewards unclaimed and reaching a specific number of referrals or securing an amount of volume. The referral fee is a percentage of the bridge LP fee awarded to the referrers in $ACX. If rewards are not claimed and a certain number of referrals or volume is done then the referral fee goes up. There are five tiers of referrers:\n\nCopper: 40% referral fee.\nBronze: 50% referral fee. Copper referrers progress to Bronze after 3 referrals or > $50k in bridge volume\nSilver: 60% referral fee. Bronze referrers progress to Silver after 5 referrals or > $100k in bridge volume\nGold: 70% referral fee. Silver referrers progress to Gold after 10 referrals or > $250k in bridge volume.\nPlatinum: 80% referral fee. Gold referrers progress to Platinum after 20 referrals or > $500k in bridge volume.\n\nReferral rewards are attributed weekly and referrers can only increase a tier per week. Once a referrer claims rewards, the referrer’s tier immediately resets back to Copper and all referral links are broken. This means referrers will need to get users to click on their referral link again to continue earning referral fees, and the referrers will need to regain their tier which will take a minimum of 5 weeks to reach Platinum.\nReward Locking = Gamification of DeFi\nThe benefits of Reward Locking are clear. Keeping rewards locked discourages farm and dump activity, but more importantly it makes the LP and referrer more engaged with the protocol. If you are encouraged to have a stake in the protocol you will naturally want to know more about it and you are incentivized to join the community and further its mission.\nGiven the various unique multipliers you can earn for each liquidity pool and the different tiers you can acquire as a referrer, each wallet that contributes to the protocol will develop a personalized identity. Similar to a character in a role playing game, the various stats can be translated into experience points that could allow the wallet to level up and obtain status in the protocol.\nReward locking can be gamified further with a well thought out user interface and user experience to make it appear like an actual game. It can be built similar to a RPG where users can earn special NFTs or items for reaching certain milestones. Community members could build this and/or an actual game that uses these stats and do battles with one another. As well, a leader board can recognize the accomplishments of all committed Across users. This would all work to make the user very reluctant to claim their rewards and fall in status.\nStaked $ACX - As the protocol matures, the community can consider a staking mechanism for $ACX which could grant further governance rights and also share in Across protocol revenue. Governance can dictate where incentive rewards will be directed in order to determine which tokens and which L2 should get more liquidity. This vote lock like mechanism can add further value to $ACX and the Across protocol.\n\nConclusion\n\nIn addition to building community and incentivizing project goals, the Across token launch aims to create value and meaning to owning $ACX. The objective is to have $ACX token holders interact with the protocol through their token as soon as it is launched. In fact, by outlining what actions will be rewarded ahead of the airdrop, the protocol is encouraging Across LP activity now. The Across Reward Locking Incentive Program will engage community members and use $ACX as a currency to gamify and incentivize contributions to the protocol. The $ACX token will represent real ownership of the Across protocol in terms of economics and governance.\nFeedback on this proposal is very much welcome. Mechanics and numbers can and should all be discussed so that the community is comfortable ahead of this token launch.\nI completely agree with the proposal, except for dropping out users with a small deposit. 10% of tokens can be spent on guys who worked with the protocol, but for a small amount. And you can separate drophunters with the help of a transaction filter. Let’s say if there is 0 balance on the wallet now or there are no more than 10 transactions in the Ethereum network for this year. I’m sure it will be fair. The community will regard this as support for users in difficult times.\n\n 17 days later\n\n post by LL88 on Jun 5, 2022\n\n LL88\n\n I saw the proposal to add LP liquidity to allocate 50% of the tokens. This is a very exaggerated data. These airdrop hunters provide liquidity for Defi to earn airdrop tokens. They don’t care about the development of the community at all, just care about themselves For the interests of each project, the first time a project comes out is to provide LP, and then it disappears to find the next target. During the community construction period, these people are not seen at all. The smooth development of a project is inseparable from the active publicity and promotion of the community. They are the contributors to the community, such as the publicity ambassadors on dappback, and the members who promote the project. They are all early supporters, and they should maximize the benefits, not Airdrop Hunter.From the above article, I learned that giving 50% to the airdrop hunters will make too little profit for those who really contribute to the community, which is unfair. More and more people around us are becoming airdrop hunters, because that will benefit the most, and it will also be unfair. Don’t be tired, just wait for the airdrop to provide LP. After the airdrop is released, they will no longer pay attention to the community. Just imagine that they should make more contributions to the community after allocating so many benefits to them. However, this is not the case. .[quote=“Igor55, post:48, topic:849, full:true”]\nSkip to main content\n\nAcross Token Launch Proposal v2\nTokenomics\n1\n/\n45\n\nKevin_UMA\n20d\nThis is a revised proposal that builds on the initial Across token launch proposal with added community feedback and implementation details.\nThe launch of an Across token will grow and unite the Across community, incentivize liquidity providers, increase awareness of Across, and further the mission of being the fastest and cheapest L2 bridge. This proposal outlines a token launch plan and can be largely divided into two parts:\n\nInitial Distribution - a diversified airdrop and a treasury token swap\nReward Locking Incentive Program - a novel rewards program to incentivize actions that support the Across protocol\n\nPart 1 - Initial Distribution\n\n1,000,000,000 Across tokens ($ACX) will be minted. 700,000,000 $ACX will remain in the Across Dao Treasury and a portion will be reserved for incentive rewards. 300,000,000 $ACX will be the initial supply and distributed in the following way:\n$ACX Airdrop - 100,000,000 $ACX in total will be rewarded to the following groups:\n\n10%: Across community Discord members with “Co-founder” or “Early Recruit”\n10%: Across community Discord members with “DAO Contributor” or “Senior DAO Contributor”\n20%: Tokens will be reserved as an additional bonus for significant early contributors to the Across community which may include DAO contributors, Senior DAO contributors and the Developer Support Team. After token launch, the community will have the opportunity to submit proposals as to how this should be allocated and $ACX holders will vote via snapshot.\n10%: Early Across protocol users who bridged assets before March 11, 2022. These tokens will be allocated to wallets pro-rata by the volume of transfer completed. The numbers will be adjusted to filter out small transfers that are likely from airdrop farmers.\n50%: Liquidity providers who pool ETH, USDC, WBTC, and DAI into the Across protocol before the token launch. The amount of rewards to LPs are pro-rated by size and a fixed amount of tokens will be emitted at each block since the inception of the protocol.\n\nWeights and exact details are all subject to change and dependent on the data collected ahead of token launch.\n\nToken Swap for $UMA - 100,000,000 $ACX will be swapped with the Risk Labs Treasury for $5,000,000 worth of $UMA. This achieves two goals - it gives the Across community ownership and governance power in UMA which is critical to the security of the bridge, and it also provides voting rewards as a source of income to the Across DAO treasury. Risk Labs launched Across and will continue to support the protocol and community for the foreseeable future. Providing $ACX to Risk Labs will further incentivize the Risk Labs team. Risk Labs may consider using these tokens to build and expand a dedicated development team, to help provide liquidity in $ACX, and participate in governance. Regardless of use, these tokens will only be used to the benefit of the protocol.\nStrategic Partners and Relayer Capital - 100,000,000 $ACX will be transferred to Risk Labs Treasury to raise funds and secure loans from key players in the DeFi industry. Competitors in the bridge space are partnering with large institutions and obtaining substantial resources to propel their growth. Risk Labs can use these tokens to help Across protocol do the same. A key resource constraint is the relayer network where a significant amount of capital is provided by Risk Labs’ treasury. Partnering with large and well capitalized crypto players can help alleviate this bottleneck and accelerate growth. To achieve this goal, Risk Labs may use these $ACX tokens for a success token fund raise, for collateral when borrowing via range tokens , and for rewards to facilitate the decentralization of the relayer network.\n\nPart 2 - Across Reward Locking Incentive Program\n\nA significant portion of the 700,000,000 $ACX in reserve will be emitted through this incentive program and community members can earn $ACX by doing any of the following actions:\n\nStake Across LP shares from bridge pools - WETH and USDC pools will be the first Across pools to be incentivized\nStake $ACX LP shares from a designated $ACX/ETH pool\nRefer users through the Across Referral Program\n\nLiquidity Providers - Reward locking is an enhanced version of traditional liquidity mining that discourages farm and dump activity while rewarding loyal contributors to the protocol. Liquidity providers (LPs) have an individualized rate at which they earn rewards. The longer a LP keeps accumulated rewards unclaimed (and unsold) the faster the LP earns additional rewards.\nEach incentivized liquidity pool will have a base rate of emission and each LP will have a unique multiplier for each of these pools. The LP will earn a pro-rata share of the base rate emission multiplied by the LP’s unique multiplier. A LP’s multiplier starts at 1 on day zero and can grow linearly to a maximum of 3 when rewards are left unclaimed for 100 days. The table below illustrates this simple progression. As an example, a LP that has held rewards unclaimed for 60 days will have a 2.2 multiplier. Once a LP claims ANY rewards the multiplier immediately resets to 1 and the LP would need to earn that multiplier again.\n\nDays Held\nMultiplier\n\n0\n1.0\n\n25\n1.5\n\n50\n2.0\n\n75\n2.5\n\n100\n3.0\n\nThe initial reward locking program will be expected to operate for 6 months and will be reviewed at that point in time for any changes. The program will start with the following base emission rate:\n~100,000 $ACX per day for Across ETH LP shares\n~100,000 $ACX per day for Across USDC LP shares\n~20,000 $ACX per day for designated $ACX/$ETH LP shares\nThis equates to roughly 4MM to 10MM $ACX depending on the behavior of LPs. $ACX holders can propose and vote to add new assets or change these parameters at any time.\nAcross Referral Program - The referral program will convert the Across community into a sales force. To participate in the referral program, Across supporters can enter their wallet address to generate a unique referral link. A user who clicks that link and completes a bridge transfer on Across will attribute $ACX rewards to the referrer. Supporters are encouraged to share their link with friends and promote Across on social media, such as Twitter. This can also be used in integrations with other projects. A bridge aggregator or a DEX can create a referral link to connect Across to their dApp. Once that link is clicked and a bridge transfer is completed, rewards will be allocated to that project. All future transfers completed by that wallet will continue to attribute rewards to the referrer unless the user of the wallet clicks a different referral link or the referrer claims their rewards.\nSimilar to reward locking for LPs, referrers can increase the rate they earn referral fees by keeping their rewards unclaimed and reaching a specific number of referrals or securing an amount of volume. The referral fee is a percentage of the bridge LP fee awarded to the referrers in $ACX. If rewards are not claimed and a certain number of referrals or volume is done then the referral fee goes up. There are five tiers of referrers:\n\nCopper: 40% referral fee.\nBronze: 50% referral fee. Copper referrers progress to Bronze after 3 referrals or > $50k in bridge volume\nSilver: 60% referral fee. Bronze referrers progress to Silver after 5 referrals or > $100k in bridge volume\nGold: 70% referral fee. Silver referrers progress to Gold after 10 referrals or > $250k in bridge volume.\nPlatinum: 80% referral fee. Gold referrers progress to Platinum after 20 referrals or > $500k in bridge volume.\n\nReferral rewards are attributed weekly and referrers can only increase a tier per week. Once a referrer claims rewards, the referrer’s tier immediately resets back to Copper and all referral links are broken. This means referrers will need to get users to click on their referral link again to continue earning referral fees, and the referrers will need to regain their tier which will take a minimum of 5 weeks to reach Platinum.\nReward Locking = Gamification of DeFi\nThe benefits of Reward Locking are clear. Keeping rewards locked discourages farm and dump activity, but more importantly it makes the LP and referrer more engaged with the protocol. If you are encouraged to have a stake in the protocol you will naturally want to know more about it and you are incentivized to join the community and further its mission.\nGiven the various unique multipliers you can earn for each liquidity pool and the different tiers you can acquire as a referrer, each wallet that contributes to the protocol will develop a personalized identity. Similar to a character in a role playing game, the various stats can be translated into experience points that could allow the wallet to level up and obtain status in the protocol.\nReward locking can be gamified further with a well thought out user interface and user experience to make it appear like an actual game. It can be built similar to a RPG where users can earn special NFTs or items for reaching certain milestones. Community members could build this and/or an actual game that uses these stats and do battles with one another. As well, a leader board can recognize the accomplishments of all committed Across users. This would all work to make the user very reluctant to claim their rewards and fall in status.\nStaked $ACX - As the protocol matures, the community can consider a staking mechanism for $ACX which could grant further governance rights and also share in Across protocol revenue. Governance can dictate where incentive rewards will be directed in order to determine which tokens and which L2 should get more liquidity. This vote lock like mechanism can add further value to $ACX and the Across protocol.\n\nConclusion\n\nIn addition to building community and incentivizing project goals, the Across token launch aims to create value and meaning to owning $ACX. The objective is to have $ACX token holders interact with the protocol through their token as soon as it is launched. In fact, by outlining what actions will be rewarded ahead of the airdrop, the protocol is encouraging Across LP activity now. The Across Reward Locking Incentive Program will engage community members and use $ACX as a currency to gamify and incentivize contributions to the protocol. The $ACX token will represent real ownership of the Across protocol in terms of economics and governance.\nFeedback on this proposal is very much welcome. Mechanics and numbers can and should all be discussed so that the community is comfortable ahead of this token launch.\nI completely agree with the proposal, except for dropping out users with a small deposit. 10% of tokens can be spent on guys who worked with the protocol, but for a small amount. And you can separate drophunters with the help of a transaction filter. Let’s say if there is 0 balance on the wallet now or there are no more than 10 transactions in the Ethereum network for this year. I’m sure it will be fair. The community will regard this as support for users in difficult times.\n[/quote]\n\n 6 months later\n\n post by KoCoinhunter1 on Nov 17, 2022\n\n KoCoinhunter1\n\n My understanding is that there aren’t any mechanisms in place to prevent this type of action. However, the user would need to actually complete a transfer to gain the referral. There may be a weakness in this (hopefully Kevin can share more), but it seems like a net positive for Across to have more volume and a net negative to a user to break up their funds to transfer them.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Across Token Launch Proposal\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 214\n\n May 2022\n\n Across ($ACX) Community Initial Liquidity Proposal\n\n Passed Proposals\n\n Passed Proposals\n\n 49\n\n Nov 2022\n\n Second ACX Drop\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 15\n\n Feb 2024\n\n “Community Owned Liquidity” NFT Project Funding Request\n\n Active Proposals\n\n treasury-funding\n\n Active Proposals\n\n 36\n\n Jun 2023\n\n Initial thinking around token distribution\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 36\n\n Mar 2022","tokens":7332,"squid":"spider-09","role":"Bridge Spider","at":1791343443477,"hash":"715d9312d95aecdf02eddf8638f7c7099a3a0e39"}
{"url":"https://forum.across.to/t/second-acx-drop/1801","domain":"forum.across.to","title":"Second ACX Drop - Proposals - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n Second ACX Drop \n\n Proposals\n\n treasury-funding\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 5\n min\n\n Jan 2024\n\n 1 / 17\n\n Jan 2024\n\n Feb 2024\n\n post by caesarsherrod.eth on Jan 12, 2024\n\n caesarsherrod.eth\n\n Title: Second ACX Drop\nAuthor(s): 0xCaesarSeverus, Justin J\nStatus: Proposal\nRelated Discussions:\nBody\nSummary:\nThe Unclaimed Across tokens will be (have been) clawed back and should be given to the bridge users, liquidity providers and voters in a direct airdrop opportunity to reinforce their commitment to the bridge and their community.\nMotivation:\nThe people who use the Across Bridge are committed to the future of the technology and should be rewarded for it. Several Actions should be the focus of the airdrop. The first should be Liquidity Provision, which is the backbone of the bridge. The second action should be the users of the bridge and the last should be those who vote in the proposals.\nSpecification & Implementation:\n50% of the tokens should be immediately airdropped to the Liquidity providers according to the length of time they’ve staked. With special attention to those who stake ACX, and potentially to length of stake. We should also reward those who provide liquidity in ACX pools on Ethereum and Optimism.\n20% of the tokens should be focused to those who use the bridge by using 2023 Volume or total transactions.\nLastly, 30% of tokens to reward voters. Those who manage to participate in ballots are some of the most important members of our community.\nRationale:\nThose who use Across will be rewarded and have further incentive to use Across in the future. Awarding users is important. 6.7 Million tokens make up a very small percentage of the circulating 295,000,000 ACX and the sell pressure, if any would be negligible.\nDownside (Cons):\nThe downsides are that the tokens are not used to their full potential elsewhere for the DAOs interest.\nVoting:\nYes would result in the distribution of the 6.7 million ACX to users - bridge users, liquidity providers and voters.\n\n 6\n\n 2\n\n read \n\n 5\n min\n\n post by Heruvim78 on Jan 15, 2024\n\n Heruvim78\n\n Yeah, seems alright. Only that I would do 30% bridge users and 20% voters. But then, we do have some problems with the number of voters. So yeah, seems fair.\nI had one idea, but I do not know if is worthy of mention. What about some way to burn ACX in order to boost the ACX liquidity rewards? Like to buy the time needed to max up the max reward.\n\n post by PVMihalache on Jan 15, 2024\n\n PVMihalache\n\n I totally agree with the format!\n50% of the tokens should be immediately airdropped to the Liquidity providers - spot on!\n20% of the tokens should be focused to those who use the bridge by using 2023 Volume or total transactions. - top stuff again!\nLastly, 30% of tokens to reward voters. Those who manage to participate in ballots are some of the most important members of our community - yes please\n\n post by TheRealTuna_Across on Jan 15, 2024\n\n TheRealTuna_Across\n\n I don’t think a second airdrop would create value out of thin air but would instead dilute the tokens myself and others are holding and potentially dilute yield returns on LP’s in the process. Things are going well for Across and I don’t think we need to ask for more free tokens. As an ACX holder we all own a share in treasury anyways and I’d rather make sure we reward those who are in it long term then give away tokens for people to dump now.\n\n post by caesarsherrod.eth on Jan 15, 2024\n\n caesarsherrod.eth\n\n These tokens were initially intended to be airdropped to users, or intended to be apart of the circulating supply. It would not be dilution in any way to do this. We are just giving these tokens to wallets that’ll collect them.\nAdditionally, the total supply of ACX tokens is 1 Billion with a circulating supply of 315 Million. 6.7 Million Tokens would be a 2.1% expansion of the current supply. This is but a sliver of the tokens which have been vested or locked within the total supply.\nFurthermore, this proposal is about giving these tokens, which were not claimed originally, to those who use the bridge and would likely not sell the tokens. If you have better ways decide this - beyond those listed above - I would be open to suggestions.\nTo reiterate, this proposal is simply about giving unclaimed ACX tokens to the AVX community. 6.7 Million ACX is currently valued at ~ 1.19 Million USDC to likely less than 1500 wallets.\nAs an ACX Holder, I don’t think this action would prove detrimental to the value of the token, in fact I think buy rewarding holders it increases the commitment to the community.\n\n post by caesarsherrod.eth on Jan 15, 2024\n\n caesarsherrod.eth\n\n Heruvim78\n\n I am not sure if burning 6.7 Million tokens will increase the value of the 315 Million in circulation. This may hold merit, but I have not seen token burns that add value unless they are consistently being burnt.\n\n post by caesarsherrod.eth on Jan 15, 2024\n\n caesarsherrod.eth\n\n PVMihalache\n\n I think the portion to the voters and the LP is super important. I don’t see enough communities reward voters.\n\n post by PVMihalache on Jan 16, 2024\n\n PVMihalache\n\n The percentages you said are well balanced. In most cases someone who has LP will probably vote as well. Something I always pointed out during votes is that even small holders are getting involved\n\n post by gmsteele on Jan 16, 2024\n\n gmsteele\n\n I think this is a good idea. These tokens were meant to be airdropped, if everyone who could have collected them would have, they would be out there, so these are tokens the protocol expected to be circulating. And the proposed number of tokens being discussed are a small % of what’s out there.\nSecondly, I like this idea because recently we have decreased ACX emissions for liquidity providers in both the ACX pool AND the multipliers. So this would be something good to encourage continued support of the bridge.\nAnd it’s funny, TheRealTuna and I have talked about this before, and I love you man, but I’m just not on the same page with you that the circulating ACX tokens, especially at this point, have a real impact on the value. If the token goes up, it will be because of the confidence people have in Across and the value in provides, not because tokens are held close to the vest by the protocol.\nI can’t get it to make sense to me that the token volume can impact token value when there are 1 BILLION of them. If the concern of the protocol was to support token value by limiting the supply, a much smaller number would have been created. Creating so many ACX tokens just tells you that the protocol did not intend to strictly control the supply of the token to prop up value.\nBut the use of the bridge and attracting new liquidity providers is probably best accomplished by word of mouth. The word of mouth to attract new bridge users will likely be because of the speed and value of the bridge, however, incentivizing users to attract other users can’t be a bad idea. It is possible that I agree the 30% of tokens proposed to go to bridge users could be part of the referral program possibly?\nBut the only way word of mouth with attract more liquidity providers is to keep liquidity providers happy and provide a good return. And let’s face it, who should Across like to get a good ROI more than those who supported the bridge from day #1? I can’t get on board that my ROI improves if I have less ACX tokens.\n\n post by Justin_J on Jan 24, 2024\n\n Justin_J\n\n I like this but how about we set aside a small amount of tokens for a campaign to bring awareness to Across if this is air drop season 2 with multiple new chains this is the perfect opportunity to put that use\n\n post by caesarsherrod.eth on Jan 25, 2024\n\n caesarsherrod.eth\n\n how many tokens would you think to allocate to a campaign? If this happened I’d say a maximum of 1,000,000 ACX which is a modest ~150,000. I just think it should go to the active community.\nMaybe in the bridge user portion we could even include people who are using bridge aggregators.\n\n post by shola0946 on Jan 29, 2024\n\n shola0946\n\n My take, 70% or 45% should go to active bridgoors, 25% to exceptional community members (honestly not sure this is suppose to be there, since we have had one in the past) The bridgoors should take the better part of the drop, those that have done volume. If possible, a point system should be introduced, if not too late, even though it is a second drop. The only thing with this is that, there will definitely be a rise in volume we see, however, it is not sustainable, since people will only come around for the points and hence the token, but those will stay will stay. LPs/ Stakers are also loyalist of the project and so about 30% should go to them.\nI am a beneficial of the first community drop, and I actively contributed to Across. Never taken out a penny from my allocation. I am definitely routing for the bigger success of the protocol.\n\n 8 days later\n\n post by Hadari on Feb 7, 2024\n\n Hadari\n\n Pokračování diskuze z Second ACX Drop:\nHeader\nTitle: (enter proposal title)\nAuthor(s): (enter name(s) of associated authors)\nStatus: (RFC, Proposal, Vote)\nRelated Discussions: (optional - paste link here)\nSubmission Date: (Enter Date)\nBody\nSummary:\nGive us a TL;DR on your proposal; no more than 2-3 sentences.\nMotivation:\nWhat problems will this proposal address/solve? What’s the value-add?\nSpecification & Implementation:\nDescribe the proposal in as much detail as is necessary. Explain the vision for the proposal. How will this affect the protocol both technically, socially, financially (if applicable), and governance-wise? What steps need to be taken to implement this proposal?\nRationale:\nExplain any decisions above that were chosen over an alternative. Why is this the best way to do it? How will the implementation of this proposal advance the protocol?\nDownside (Cons):\nAre there any disadvantages with implementing the proposal? Are there any security considerations or potentially negative financial exposures to consider?\nVoting:\nDefine what a “yes” and “no” vote entails. Once the proposal moves to a vote, please include the link to Snapshot here.\n\n 9 days later\n\n post by ayoki on Feb 16, 2024\n\n ayoki\n\n Took a look at the post and the comments. Here are my thoughts:\nWe had originally airdropped these tokens and they were left unclaimed (idle/unused), if we use a similar criteria to airdrop (reward bridgooors), we’re going to end up with unclaimed tokens again and will have to continuously repeat this process until the airdrop gets smaller and smaller.\nWe’ve been hitting 99% utilization of USDC recently. A few months ago it was DAI. We’re paying out sky high APY to attract more liquidity and that’s not easy to sustain forever.\nThat being said, I am against this proposal. For these reasons: We already pay out Across LPs 2x, 3x more than other bridges for the same token, even 4x sometimes more than AAVE, etc. so we’re already “giving away” ACX at a rapid rate. The best use of the tokens, in my opinion, is to keep them in the treasury to pay out LP rewards because more capital is what we are in urgent need of. If people get a sudden airdrop they are more likely (maybe) to withdraw their LP because they won’t need to earn ACX anymore (worst case scenario). So, anything that encourages that behaviour, I would want to avoid.\n\n post by caesarsherrod.eth on Feb 16, 2024\n\n caesarsherrod.eth\n\n I agree with what you’re saying but even if these tokens were collected in the airdrop, ACX would still be giving away tokens, in your terms. I don’t think ACX gives away tokens. Every ACX I have I earned as an LP by pledging my own assets to the liquidity pools. The larger issue is that these LPs would likely not be there without the subsidies provided by the treasury.\nI think there is a misconception between giving away something versus what is earned. Regardless, These tokens were destined to be given away and I believe they should be given away, rather than earned.\n\n post by nuukids831228 on Feb 20, 2024\n\n nuukids831228\n\n Airdropping tokens to the same old people makes no sense. Airdrops can be a cheap and effective marketing tool to gain exposure to “NEW” communities if executed properly, but they don’t typically attract active bridge users. Across is a key infrastructure that requires more integrations and partnerships. Instead of spending these tokens on users, they should be used as incentives for people to “build/integrate” across and for CEX listings that enhance awareness, increase liquidity, and lend legitimacy to the project. Once there are more real/organic users, I wouldn’t mind airdropping some, but currently, it wouldn’t fuel any growth. In summary, I’m 100% against new airdrops, and if fair value distribution is the goal, we might as well burn them.\n\n 1 month later\n\n Closed on Mar 21, 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 Across Token Launch Proposal\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 214\n\n May 2022\n\n Across Token Launch Proposal v2\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 47\n\n Nov 2022\n\n Across ($ACX) Community Initial Liquidity Proposal\n\n Passed Proposals\n\n Passed Proposals\n\n 49\n\n Nov 2022\n\n What the token does?\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 25\n\n Apr 2022\n\n Reduce ACX emissions for Across ACX LPs\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 8\n\n Nov 2023","tokens":4862,"squid":"spider-09","role":"Bridge Spider","at":1791343453710,"hash":"ac85377b7aa1ecc1cb16095a41ca3088b8a70ef5"}
{"url":"https://ethresear.ch/c/economics/16","domain":"ethresear.ch","title":"Latest Economics topics - Ethereum Research","text":"Latest topics in Economics\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 3\n\n 4.1k\n\n Jul 2025\n\n Proposal for a minimal compute-anchored purchasing power signal\n\n 0\n\n 58\n\n 4d\n\n Staking rewards as venture capital, governed by futarchy\n\n dao,futarchy\n\n 2\n\n 222\n\n 5d\n\n Letting the base fee be a midpoint: a temporal liquidity authorization for EIP-1559\n\n mev,proposer-builder-separation,fee-market,eip-1559\n\n 1\n\n 149\n\n 7d\n\n Capacity oracles\n\n 4\n\n 415\n\n 12d\n\n Post-Glamsterdam One-dimensional Fee Market and Comparison with EIP-7999\n\n 0\n\n 150\n\n 16d\n\n Bounding Collusion in Capital Allocation DAOs via Subjective Human Oracles\n\n public-good,dao,collusion\n\n 4\n\n 158\n\n 19d\n\n When Data Binds Execution: Dynamic Simulation of EIP-7999’s Multidimensional Fee Market\n\n 0\n\n 66\n\n 21d\n\n From 60M to 200M: simulating Glamsterdam’s fee market\n\n 3\n\n 363\n\n 21d\n\n Public-mempool gas sponsorship needs escrow, a bond, or trust\n\n 0\n\n 111\n\n 22d\n\n Temporal Liquidity: heterogeneous demand and Ethereum’s single execution lane\n\n 2\n\n 153\n\n Aug 31\n\n Equilibrium in EIP-7999’s Multidimensional Fee Market: The Execution–Data Fee-Floor Frontier\n\n 2\n\n 149\n\n Aug 31\n\n Demand Model with Elasticities for Ethereum State, Data, and Execution and Glamsterdam Fee Market Analysis\n\n 2\n\n 192\n\n Aug 27\n\n AMM Yield Maximization: Convergence of the Liquidity Provider and Arbitrageur Roles\n\n mev\n\n 0\n\n 141\n\n Aug 27\n\n Manipulation-Resistant Prediction Market Derivatives with Language Models\n\n 8\n\n 9.1k\n\n Aug 25\n\n Building index-tracking assets on top of options instead of debt\n\n 31\n\n 13.5k\n\n Aug 23\n\n BTCP Zero-Bridge: cross-chain exchange where assets never leave their native chains\n\n identity,cryptoeconomic-primitives\n\n 0\n\n 236\n\n Aug 19\n\n Data Metering, BAL Decomposition, and Bundle Pricing Under EIP-7999\n\n 0\n\n 96\n\n Aug 19\n\n Futarchy is insecure without a trusted gatekeeper\n\n governance,futarchy\n\n 4\n\n 302\n\n Aug 5\n\n Prediction market design for betting on many highly improbable events\n\n 23\n\n 8.9k\n\n Aug 5\n\n Validator Redirected Revenue\n\n governance\n\n 36\n\n 2.4k\n\n Aug 4\n\n Dynamic Leverage Pricing for Non-Transferable Time Credits: Solving Skill-Mismatch in Volunteer & Public-Good Labor\n\n sybil-attack\n\n 2\n\n 75\n\n Aug 3\n\n Structural OEV Elimination through State Synchronization\n\n mev,cross-shard,chain-sync\n\n 4\n\n 278\n\n Jul 29\n\n Can a CEX microstructure signal survive Ethereum execution latency and MEV?\n\n mev,data-availability,execution,market-microstructure\n\n 0\n\n 141\n\n Jul 28\n\n 1000-Year Hyper-Reality Stress Test: Why the Current Capitalist System Programmatically Destroys the Economy, and How “SHIONO OS” Defends Against Shocks and Human Avarice\n\n 2\n\n 163\n\n Jul 24\n\n Sybil Attacks on AUCIL\n\n proposer-builder-separation,inclusion-lists\n\n 0\n\n 98\n\n Jul 11\n\n Builders’ Defection and Incentive Compatibility\n\n mev,proposer-builder-separation\n\n 0\n\n 209\n\n Jul 8\n\n ETH needs a supply cap at 128 million\n\n 8\n\n 601\n\n Jun 25\n\n Price Elasticity of Gas Demand on Ethereum and Arbitrum\n\n 0\n\n 115\n\n Jun 16\n\n The Origins of MEV: Systematic Attribution of Arbitrage Opportunity Creation at Scale\n\n mev\n\n 3\n\n 323\n\n Jun 15","tokens":793,"squid":"spider-04","role":"Research Spider","at":1791343458392,"hash":"8fbd8a5c4372ecdc212ba1ee734bef28b0d79170"}
{"url":"https://www.metaplex.com/docs/smart-contracts/mpl-agent/tools","domain":"metaplex.com","title":"Agent Tools Program | MPL Agent Registry | Metaplex","text":"The Agent Tools program manages executive delegation for agent assets, allowing asset owners to delegate execution permissions to executive profiles and revoke them. SummaryThe Agent Tools program (TLREGni9ZEyGC3vnPZtqUh95xQ8oPqJSvNjvB7FGK8S) provides three instructions for managing execution delegation: RegisterExecutiveV1 creates an executive profile, DelegateExecutionV1 grants that profile permission to execute on behalf of an agent asset, and RevokeExecutionV1 closes that delegation.Three instructions — RegisterExecutiveV1 (one-time profile setup), DelegateExecutionV1 (per-asset delegation), and RevokeExecutionV1 (per-asset revocation)ExecutiveProfileV1 — 40-byte PDA derived from [\"executive_profile\", <authority>], one per walletExecutionDelegateRecordV1 — 104-byte PDA linking an executive profile to a specific agent assetOwner-only delegation — only the asset owner can create delegation records; the program validates ownership on-chainOwner or executive revocation — either the asset owner or the executive authority on the record can sign RevokeExecutionV1; an executive can step down without owner involvementArbitrary execution authority — an active execution delegate may cause the agent's Asset Signer PDA to sign any instruction passed through Core's Execute hook; see Security modelProgram IDThe same program address is deployed on both Mainnet and Devnet.NetworkAddressMainnetTLREGni9ZEyGC3vnPZtqUh95xQ8oPqJSvNjvB7FGK8SDevnetTLREGni9ZEyGC3vnPZtqUh95xQ8oPqJSvNjvB7FGK8SOverviewThe tools program provides three instructions:RegisterExecutiveV1 — Create an executive profile that can act as an executor for agent assetsDelegateExecutionV1 — Grant an executive profile permission to execute on behalf of an agent assetRevokeExecutionV1 — Close a delegation record, ending that executive's ability to trigger future executions for the agent assetAn executive profile is registered once per authority. Delegation is per asset — an asset owner creates a delegation record linking their agent asset to a specific executive profile, and may revoke that record at any time.Instruction: RegisterExecutiveV1Creates an executive profile PDA for the given authority.AccountsFour accounts are required: the profile PDA to create, a payer, an optional authority, and the system program.AccountWritableSignerOptionalDescriptionexecutiveProfileYesNoNoPDA to be created (auto-derived from authority)payerYesYesNoPays for account rent and feesauthorityNoYesYesThe authority for this executive profile (defaults to payer)systemProgramNoNoNoSystem programWhat It DoesDerives a PDA from seeds [\"executive_profile\", <authority>]Validates the account is uninitializedCreates and initializes the ExecutiveProfileV1 account (40 bytes) storing the authorityInstruction: DelegateExecutionV1Delegates execution permission for an agent asset to an executive profile.AccountsSeven accounts are required, including the executive profile, the agent asset, its identity PDA, and the delegation record PDA to create.AccountWritableSignerOptionalDescriptionexecutiveProfileNoNoNoThe registered executive profileagentAssetNoNoNoThe MPL Core asset to delegateagentIdentityNoNoNoThe agent identity PDA for the assetexecutionDelegateRecordYesNoNoPDA to be created (auto-derived)payerYesYesNoPays for account rent and feesauthorityNoYesYesMust be the asset owner (defaults to payer)systemProgramNoNoNoSystem programWhat It DoesValidates the executive profile exists and is initializedValidates the agent asset is a valid MPL Core assetValidates the agent identity is registered for the assetValidates the signer is the asset ownerDerives a PDA from seeds [\"execution_delegate_record\", <executive_profile>, <agent_asset>]Creates and initializes the ExecutionDelegateRecordV1 account (104 bytes)Instruction: RevokeExecutionV1Closes an ExecutionDelegateRecordV1, ending the executive's ability to trigger future Execute calls for the agent asset through the AgentIdentity path. Either the asset owner or the executive authority recorded on the delegation can revoke.AccountsSix accounts are required. The delegation record PDA is closed and its rent is refunded to destination.AccountWritableSignerOptionalDescriptionexecutionDelegateRecordYesNoNoThe delegation record PDA to closeagentAssetNoNoNoThe MPL Core asset whose delegation is being closed (must match the record)destinationYesNoNoReceives reclaimed rent from the closed delegation recordpayerYesYesNoPays for transaction fees (defaults to umi.payer)authorityNoYesYesMust be the asset owner or the executive authority on the record (defaults to payer)systemProgramNoNoNoSystem programWhat It DoesValidates the delegation record is initialized and owned by the Agent Tools programReads the executive profile, executive authority, and agent asset from the recordValidates the passed agentAsset matches the record and is a valid MPL Core assetValidates the PDA derivation of the delegation recordValidates the signer is either the asset owner or the executive authority recorded on the delegationCloses the ExecutionDelegateRecordV1 account and refunds rent to destinationWhat It Does Not DoRevokeExecutionV1 only revokes future execution through the AgentIdentity path. It does not unwind downstream state created by previous valid executions. See Security model for the full lifecycle semantics.PDA DerivationBoth account types are PDAs derived from deterministic seeds. Use the SDK helpers to compute them.AccountSeedsSizeExecutiveProfileV1[\"executive_profile\", <authority>]40 bytesExecutionDelegateRecordV1[\"execution_delegate_record\", <executive_profile>, <agent_asset>]104 bytesimport {\n findExecutiveProfileV1Pda,\n findExecutionDelegateRecordV1Pda,\n} from '@metaplex-foundation/mpl-agent-registry';\n\nconst profilePda = findExecutiveProfileV1Pda(umi, {\n authority: authorityPublicKey,\n});\n\nconst delegatePda = findExecutionDelegateRecordV1Pda(umi, {\n executiveProfile: profilePda,\n agentAsset: assetPublicKey,\n});\nAccount: ExecutiveProfileV1Stores the authority that owns this executive profile. 40 bytes, 8-byte aligned.OffsetFieldTypeSizeDescription0keyu81Account discriminator (1 = ExecutiveProfileV1)1_padding[u8; 7]7Alignment padding8authorityPubkey32The authority for this executive profileAccount: ExecutionDelegateRecordV1Links an executive profile to an agent asset, recording who is authorized to execute on its behalf. 104 bytes, 8-byte aligned.OffsetFieldTypeSizeDescription0keyu81Account discriminator (2 = ExecutionDelegateRecordV1)1bumpu81PDA bump seed2_padding[u8; 6]6Alignment padding8executiveProfilePubkey32The executive profile address40authorityPubkey32The executive authority72agentAssetPubkey32The agent asset addressSecurity ModelAn active execution delegate has broad operational authority over whatever accounts the agent's Asset Signer PDA controls. Lifecycle semantics around delegation, revocation, and asset transfer are described below.Execution Authority Is ArbitraryAn authorized execution delegate may cause the agent's Asset Signer PDA to sign any instruction passed through Core's Execute hook. This includes SOL and SPL Token transfers, CPI calls, SPL Token Approve, account-authority changes, and protocol interactions.This is intentional. Execution delegation is not a narrow \"method call\" permission — it is broad operational authority over the agent's wallet and any accounts the Asset Signer controls. The Agent Tools program does not parse, introspect, gate, or restrict the instructions that an executive forwards through Execute.Revocation ScopeRevokeExecutionV1 closes the ExecutionDelegateRecordV1, preventing that executive from triggering future Execute calls through the AgentIdentity path. Either the asset owner or the executive authority on the record may sign the revocation — an executive can step down from operating an agent without owner involvement, and the owner can revoke an executive without executive cooperation.Revocation does not modify, reverse, or clean up durable downstream state created by previous valid executions.Examples of downstream state that may survive revocation:SPL Token approvals (Approve granted to a third-party delegate)Token account authority changesEscrow positions and protocol depositsOpen positions in lending, AMM, or perpetuals programsPermissions or configuration stored in other programsAny other state created by arbitrary CPICleaning up downstream state requires separate instructions to those programs — for example, calling SPL Token's Revoke on a token account whose delegate was set during a previous execution.Delegates Are Agent Runtime ConfigurationExecution delegates are part of the agent's operational state, not ephemeral approvals tied to the current owner wallet. A hosted provider, service operator, or agent container hot wallet is commonly authorized as an executive so the agent can continue operating as the asset moves between owners (for example, between wallets the same operator controls). Asset transfer does not automatically invalidate ExecutionDelegateRecordV1 accounts.Recipients of an agent assetWhen you receive an agent asset from another party, treat existing execution delegates as part of the agent's received runtime configuration. Before funding the agent's Asset Signer PDA, enumerate active delegation records and revoke any executives you do not intend to authorize.Funding the Asset Signer PDAThe agent's Asset Signer PDA is commonly used as the agent's treasury or operational account. If an active execution delegate exists, that delegate may move assets controlled by the Asset Signer PDA. Before funding the Asset Signer PDA — especially after receiving or transferring an agent asset — confirm which executives are authorized and whether they are trusted.See the Clean Up an SPL Approval example on the Run an Agent guide for a worked cleanup of downstream state.ErrorsThe program returns these errors when validation fails during registration, delegation, or revocation.CodeNameDescription0InvalidSystemProgramSystem program account is incorrect1InvalidInstructionDataInstruction data is malformed2InvalidAccountDataInvalid account data3InvalidMplCoreProgramMPL Core program account is incorrect4InvalidCoreAssetAsset is not a valid MPL Core asset5ExecutiveProfileMustBeUninitializedExecutive profile already exists6InvalidExecutionDelegateRecordDerivationDelegation record PDA derivation mismatch7ExecutionDelegateRecordMustBeUninitializedDelegation record already exists8InvalidAgentIdentityAgent identity account is invalid9AgentIdentityNotRegisteredAsset does not have a registered identity10AssetOwnerMustBeTheOneToDelegateExecutionOnly the asset owner can delegate execution11InvalidExecutiveProfileDerivationExecutive profile PDA derivation mismatch12ExecutionDelegateRecordMustBeInitializedDelegation record does not exist or has already been closed13UnauthorizedRevokeAuthority is neither the asset owner nor the executive authority on the record14ExecutiveProfileMustBeInitializedExecutive profile account is not initializedNotesRevokeExecutionV1 is an on-chain action on the Agent Tools program. It stops future Execute calls through the AgentIdentity path but does not unwind downstream state in other programs.Either the asset owner or the executive authority on the record can sign RevokeExecutionV1. DelegateExecutionV1 remains owner-only.Asset transfer does not close ExecutionDelegateRecordV1 accounts. Recipients should review and revoke executives according to their trust assumptions.Asset owners always retain the direct Core Execute path documented in Execute Asset Signing. Cleaning up downstream state (for example, an SPL Approve) can be done by the owner without an executive.The Freeze Execute plugin can freeze the Execute lifecycle event entirely as an additional safeguard; it operates at the Core layer and is independent of the Agent Tools delegation record.Maintained by Metaplex · Last verified June 2026 · View source on GitHub","tokens":2988,"squid":"dotcat","role":"Tooling Spider","at":1791343458429,"hash":"52821360ecc64562cf01c14898a7744f05927800"}
{"url":"https://forum.across.to/t/second-acx-drop/1801/17","domain":"forum.across.to","title":"Second ACX Drop - Proposals - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n Proposals\n\n treasury-funding\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 5\n min\n\n Jan 2024\n\n 17 / 17\n\n Mar 2024\n\n Feb 2024\n\n post by caesarsherrod.eth on Jan 12, 2024\n\n caesarsherrod.eth\n\n Title: Second ACX Drop\nAuthor(s): 0xCaesarSeverus, Justin J\nStatus: Proposal\nRelated Discussions:\nBody\nSummary:\nThe Unclaimed Across tokens will be (have been) clawed back and should be given to the bridge users, liquidity providers and voters in a direct airdrop opportunity to reinforce their commitment to the bridge and their community.\nMotivation:\nThe people who use the Across Bridge are committed to the future of the technology and should be rewarded for it. Several Actions should be the focus of the airdrop. The first should be Liquidity Provision, which is the backbone of the bridge. The second action should be the users of the bridge and the last should be those who vote in the proposals.\nSpecification & Implementation:\n50% of the tokens should be immediately airdropped to the Liquidity providers according to the length of time they’ve staked. With special attention to those who stake ACX, and potentially to length of stake. We should also reward those who provide liquidity in ACX pools on Ethereum and Optimism.\n20% of the tokens should be focused to those who use the bridge by using 2023 Volume or total transactions.\nLastly, 30% of tokens to reward voters. Those who manage to participate in ballots are some of the most important members of our community.\nRationale:\nThose who use Across will be rewarded and have further incentive to use Across in the future. Awarding users is important. 6.7 Million tokens make up a very small percentage of the circulating 295,000,000 ACX and the sell pressure, if any would be negligible.\nDownside (Cons):\nThe downsides are that the tokens are not used to their full potential elsewhere for the DAOs interest.\nVoting:\nYes would result in the distribution of the 6.7 million ACX to users - bridge users, liquidity providers and voters.\n\n 6\n\n 2\n\n read \n\n 5\n min\n\n post by Heruvim78 on Jan 15, 2024\n\n Heruvim78\n\n Yeah, seems alright. Only that I would do 30% bridge users and 20% voters. But then, we do have some problems with the number of voters. So yeah, seems fair.\nI had one idea, but I do not know if is worthy of mention. What about some way to burn ACX in order to boost the ACX liquidity rewards? Like to buy the time needed to max up the max reward.\n\n post by PVMihalache on Jan 15, 2024\n\n PVMihalache\n\n I totally agree with the format!\n50% of the tokens should be immediately airdropped to the Liquidity providers - spot on!\n20% of the tokens should be focused to those who use the bridge by using 2023 Volume or total transactions. - top stuff again!\nLastly, 30% of tokens to reward voters. Those who manage to participate in ballots are some of the most important members of our community - yes please\n\n post by TheRealTuna_Across on Jan 15, 2024\n\n TheRealTuna_Across\n\n I don’t think a second airdrop would create value out of thin air but would instead dilute the tokens myself and others are holding and potentially dilute yield returns on LP’s in the process. Things are going well for Across and I don’t think we need to ask for more free tokens. As an ACX holder we all own a share in treasury anyways and I’d rather make sure we reward those who are in it long term then give away tokens for people to dump now.\n\n post by caesarsherrod.eth on Jan 15, 2024\n\n caesarsherrod.eth\n\n These tokens were initially intended to be airdropped to users, or intended to be apart of the circulating supply. It would not be dilution in any way to do this. We are just giving these tokens to wallets that’ll collect them.\nAdditionally, the total supply of ACX tokens is 1 Billion with a circulating supply of 315 Million. 6.7 Million Tokens would be a 2.1% expansion of the current supply. This is but a sliver of the tokens which have been vested or locked within the total supply.\nFurthermore, this proposal is about giving these tokens, which were not claimed originally, to those who use the bridge and would likely not sell the tokens. If you have better ways decide this - beyond those listed above - I would be open to suggestions.\nTo reiterate, this proposal is simply about giving unclaimed ACX tokens to the AVX community. 6.7 Million ACX is currently valued at ~ 1.19 Million USDC to likely less than 1500 wallets.\nAs an ACX Holder, I don’t think this action would prove detrimental to the value of the token, in fact I think buy rewarding holders it increases the commitment to the community.\n\n post by caesarsherrod.eth on Jan 15, 2024\n\n caesarsherrod.eth\n\n Heruvim78\n\n I am not sure if burning 6.7 Million tokens will increase the value of the 315 Million in circulation. This may hold merit, but I have not seen token burns that add value unless they are consistently being burnt.\n\n post by caesarsherrod.eth on Jan 15, 2024\n\n caesarsherrod.eth\n\n PVMihalache\n\n I think the portion to the voters and the LP is super important. I don’t see enough communities reward voters.\n\n post by PVMihalache on Jan 16, 2024\n\n PVMihalache\n\n The percentages you said are well balanced. In most cases someone who has LP will probably vote as well. Something I always pointed out during votes is that even small holders are getting involved\n\n post by gmsteele on Jan 16, 2024\n\n gmsteele\n\n I think this is a good idea. These tokens were meant to be airdropped, if everyone who could have collected them would have, they would be out there, so these are tokens the protocol expected to be circulating. And the proposed number of tokens being discussed are a small % of what’s out there.\nSecondly, I like this idea because recently we have decreased ACX emissions for liquidity providers in both the ACX pool AND the multipliers. So this would be something good to encourage continued support of the bridge.\nAnd it’s funny, TheRealTuna and I have talked about this before, and I love you man, but I’m just not on the same page with you that the circulating ACX tokens, especially at this point, have a real impact on the value. If the token goes up, it will be because of the confidence people have in Across and the value in provides, not because tokens are held close to the vest by the protocol.\nI can’t get it to make sense to me that the token volume can impact token value when there are 1 BILLION of them. If the concern of the protocol was to support token value by limiting the supply, a much smaller number would have been created. Creating so many ACX tokens just tells you that the protocol did not intend to strictly control the supply of the token to prop up value.\nBut the use of the bridge and attracting new liquidity providers is probably best accomplished by word of mouth. The word of mouth to attract new bridge users will likely be because of the speed and value of the bridge, however, incentivizing users to attract other users can’t be a bad idea. It is possible that I agree the 30% of tokens proposed to go to bridge users could be part of the referral program possibly?\nBut the only way word of mouth with attract more liquidity providers is to keep liquidity providers happy and provide a good return. And let’s face it, who should Across like to get a good ROI more than those who supported the bridge from day #1? I can’t get on board that my ROI improves if I have less ACX tokens.\n\n post by Justin_J on Jan 24, 2024\n\n Justin_J\n\n I like this but how about we set aside a small amount of tokens for a campaign to bring awareness to Across if this is air drop season 2 with multiple new chains this is the perfect opportunity to put that use\n\n post by caesarsherrod.eth on Jan 25, 2024\n\n caesarsherrod.eth\n\n how many tokens would you think to allocate to a campaign? If this happened I’d say a maximum of 1,000,000 ACX which is a modest ~150,000. I just think it should go to the active community.\nMaybe in the bridge user portion we could even include people who are using bridge aggregators.\n\n post by shola0946 on Jan 29, 2024\n\n shola0946\n\n My take, 70% or 45% should go to active bridgoors, 25% to exceptional community members (honestly not sure this is suppose to be there, since we have had one in the past) The bridgoors should take the better part of the drop, those that have done volume. If possible, a point system should be introduced, if not too late, even though it is a second drop. The only thing with this is that, there will definitely be a rise in volume we see, however, it is not sustainable, since people will only come around for the points and hence the token, but those will stay will stay. LPs/ Stakers are also loyalist of the project and so about 30% should go to them.\nI am a beneficial of the first community drop, and I actively contributed to Across. Never taken out a penny from my allocation. I am definitely routing for the bigger success of the protocol.\n\n 8 days later\n\n post by Hadari on Feb 7, 2024\n\n Hadari\n\n Pokračování diskuze z Second ACX Drop:\nHeader\nTitle: (enter proposal title)\nAuthor(s): (enter name(s) of associated authors)\nStatus: (RFC, Proposal, Vote)\nRelated Discussions: (optional - paste link here)\nSubmission Date: (Enter Date)\nBody\nSummary:\nGive us a TL;DR on your proposal; no more than 2-3 sentences.\nMotivation:\nWhat problems will this proposal address/solve? What’s the value-add?\nSpecification & Implementation:\nDescribe the proposal in as much detail as is necessary. Explain the vision for the proposal. How will this affect the protocol both technically, socially, financially (if applicable), and governance-wise? What steps need to be taken to implement this proposal?\nRationale:\nExplain any decisions above that were chosen over an alternative. Why is this the best way to do it? How will the implementation of this proposal advance the protocol?\nDownside (Cons):\nAre there any disadvantages with implementing the proposal? Are there any security considerations or potentially negative financial exposures to consider?\nVoting:\nDefine what a “yes” and “no” vote entails. Once the proposal moves to a vote, please include the link to Snapshot here.\n\n 9 days later\n\n post by ayoki on Feb 16, 2024\n\n ayoki\n\n Took a look at the post and the comments. Here are my thoughts:\nWe had originally airdropped these tokens and they were left unclaimed (idle/unused), if we use a similar criteria to airdrop (reward bridgooors), we’re going to end up with unclaimed tokens again and will have to continuously repeat this process until the airdrop gets smaller and smaller.\nWe’ve been hitting 99% utilization of USDC recently. A few months ago it was DAI. We’re paying out sky high APY to attract more liquidity and that’s not easy to sustain forever.\nThat being said, I am against this proposal. For these reasons: We already pay out Across LPs 2x, 3x more than other bridges for the same token, even 4x sometimes more than AAVE, etc. so we’re already “giving away” ACX at a rapid rate. The best use of the tokens, in my opinion, is to keep them in the treasury to pay out LP rewards because more capital is what we are in urgent need of. If people get a sudden airdrop they are more likely (maybe) to withdraw their LP because they won’t need to earn ACX anymore (worst case scenario). So, anything that encourages that behaviour, I would want to avoid.\n\n post by caesarsherrod.eth on Feb 16, 2024\n\n caesarsherrod.eth\n\n I agree with what you’re saying but even if these tokens were collected in the airdrop, ACX would still be giving away tokens, in your terms. I don’t think ACX gives away tokens. Every ACX I have I earned as an LP by pledging my own assets to the liquidity pools. The larger issue is that these LPs would likely not be there without the subsidies provided by the treasury.\nI think there is a misconception between giving away something versus what is earned. Regardless, These tokens were destined to be given away and I believe they should be given away, rather than earned.\n\n post by nuukids831228 on Feb 20, 2024\n\n nuukids831228\n\n Airdropping tokens to the same old people makes no sense. Airdrops can be a cheap and effective marketing tool to gain exposure to “NEW” communities if executed properly, but they don’t typically attract active bridge users. Across is a key infrastructure that requires more integrations and partnerships. Instead of spending these tokens on users, they should be used as incentives for people to “build/integrate” across and for CEX listings that enhance awareness, increase liquidity, and lend legitimacy to the project. Once there are more real/organic users, I wouldn’t mind airdropping some, but currently, it wouldn’t fuel any growth. In summary, I’m 100% against new airdrops, and if fair value distribution is the goal, we might as well burn them.\n\n 1 month later\n\n Closed on Mar 21, 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 Across Token Launch Proposal\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 214\n\n May 2022\n\n Across Token Launch Proposal v2\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 47\n\n Nov 2022\n\n Across ($ACX) Community Initial Liquidity Proposal\n\n Passed Proposals\n\n Passed Proposals\n\n 49\n\n Nov 2022\n\n What the token does?\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 25\n\n Apr 2022\n\n Reduce ACX emissions for Across ACX LPs\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 8\n\n Nov 2023","tokens":4857,"squid":"spider-09","role":"Bridge Spider","at":1791343464741,"hash":"ff5d8619fcfd909f5fca8aa2d98a49b60bafbd8e"}
{"url":"https://ethresear.ch/t/from-60m-to-200m-simulating-glamsterdam-s-fee-market/25957/1","domain":"ethresear.ch","title":"From 60M to 200M: simulating Glamsterdam’s fee market - Economics - Ethereum Research","text":"From 60M to 200M: simulating Glamsterdam’s fee market \n\n Economics\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 Sep 9\n\n 1 / 4\n\n Sep 8\n\n 21d ago\n\n post by misilva73 on Sep 9\n\n misilva73\n\n What happens to the fee market when Glamsterdam changes transaction gas costs and the gas limit rises from 60M to 200M? More capacity should ease pressure on fees, but cheaper gas also attracts demand. The outcome depends on how much demand arrives and how strongly users respond to the change in price. In addition, the gas limit grows gradually, so the fee market has time to adjust.\nIn this report, we simulate the first 7,200 blocks, or roughly one day, under twelve demand scenarios. The Glamsterdam gas schedule applies from the first block. The limit takes about four hours to reach 200M, leaving roughly twenty hours to observe how fees and block utilisation settle.\nUnder the demand assumptions tested here, the day has a clear sequence: an initial fee spike, a decline as capacity expands and demand responds, and then an adjustment around the new 100M target. The size of the spike depends heavily on how the demand scenario.\nAfter this adjustment phase, nine of the twelve demand scenarios have median utilisation near the EIP-1559 target, with median base fees ranging from 0.0002 to 0.3928 gwei. The other three remain below target even with an almost negligible base fee.\nHow is the simulation set up?\nWe start with roughly 21 days of historical mainnet transactions, replayed upstream with the Glamsterdam gas schedule implemented in an instrumented reth fork. This replay records how much gas each transaction uses under the new rules. Those measurements become fixed inputs to the simulation: sampling a transaction again does not re-execute it.\nThe simulation begins immediately after the fork, with the new gas schedule already active and the gas limit still at 60M. From the next block onwards, the limit increases by approximately 1/1024 of its previous value per block, until it reaches 200M at block 1,234, about four hours later.\nAt each simulated block, we repeat three steps:\n\nSample arrivals. A demand model determines how much gas arrives: higher prices reduce demand, and lower prices increase it. We sample historical transactions to meet that quantity and add them to the mempool alongside transactions waiting from earlier blocks.\nBuild the block. We select transactions that can pay the current base fee, ordered by effective tip. Each transaction is included if it fits within the remaining capacity. If it does not fit, we skip it and continue. Transactions left out remain in the mempool.\nUpdate the fee for the next block. We apply the EIP-1559 rule using this block’s utilisation. The base fee rises when utilisation exceeds the 50% target and falls when utilisation is below it. The block’s base fee and realised tips also update the price signal that determines subsequent demand.\n\nThis creates a feedback loop: fees change arrivals, arrivals change block utilisation, and utilisation changes the next base fee. As the limit grows, the fee target rises from 30M to 100M gas per block.\nAdditionally, block capacity follows two new accounting rules:\n\nExecution gas and state-creation gas must each fit within the limit, and utilisation is the larger of the two divided by the limit. This is introduced by EIP-8037.\nBlock capacity is measured before refunds (i.e., gas refunds do not count towards the block limit, per EIP-7778).\n\nWhat demand are we assuming?\nThe historical transactions supply the mix of work. The demand model determines how much of that work arrives at each block. It measures quantity as execution gas plus state gas, rather than transaction count. This demand measure differs from block utilisation, which uses the larger dimension.\nDemand responds to a smoothed effective price (base fee plus tip). We compare that price with a fixed reference price from the historical trace. When the simulated price falls below the reference, the model samples more demand. When it rises above it, the model samples less. Including tips matters when the base fee becomes negligible, because users still pay to have transactions included. An exponential moving average with a 200-block span makes the response gradual.\nWe also vary two assumptions:\n\nDemand level: 1x, 1.5x, 2x or 2.5x. This sets the quantity arriving at the reference price. At 1x, it is one historical average block’s worth of gas per simulated block, while at 2x, it is twice that amount. Actual arrivals then rise or fall with the simulated price, so a 2x scenario does not keep arrivals fixed at twice the historical quantity.\nPrice elasticity: 0.1, 0.2 or 0.3. This sets the strength of the response. Halving the effective price increases demand by roughly 7%, 15% or 23%, respectively. A larger elasticity therefore brings more demand back when fees fall, and reduces it more when fees rise. These values follow a previous empirical analysis.\n\nThe price signal starts at the historical reference, so initial demand is exactly the chosen level. That level applies in full from the first block, while the gas limit grows gradually. This timing is important for interpreting the early fee spike.\nWe simulate 50 paths for each of the twelve combinations. The next section shows the initial 3,000 blocks, or roughly ten hours, covering the ramp and the early settling period. The section after that shows the full 7,200-block day. The lines in the charts are means across paths and shaded bands show their 10th–90th percentile. The full-day chart uses 24-block averages within each path.\nThe first several hours: fees rise before capacity catches up\nThe transition starts with demand arriving against a 60M limit. The higher-demand scenarios initially fill blocks close to that limit, while even the 1x scenario starts above the 30M gas target (due to the increase in gas costs from repricings). The following plot shows this trend. The horizontal dashed line marks the 50% utilisation target, while the vertical dashed line marks the end of the ramp at block 1,234.\nBlock utilization over the first 3,000 simulated blocks1990×507 164 KB\nWith utilisation above target, EIP-1559 raises the base fee. Demand then falls as the smoothed effective price catches up. Meanwhile, the growing gas limit creates more room in each block. Together, these effects bring utilisation below target, causing the base fee to fall again.\nHigher elasticities produce an earlier, smaller fee peak. At the lowest elasticity, demand is less sensitive to price, so the base fee rises much higher before falling again. The base-fee axis is logarithmic, so the spike spans several orders of magnitude.\nBase fee over the first 3,000 simulated blocks1957×507 160 KB\nThe spike reflects the starting assumptions: full demand from block 0, a 60M initial limit, and a price signal that adjusts gradually from the historical reference. Together, these allow demand to stay high while the base fee rises sharply.\nThe spike therefore illustrates what can happen when demand arrives faster than capacity and reacts with a delay. Its magnitude should not be read as a forecast. This sweep does not test demand arriving gradually alongside the capacity increase, or alternative response delays.\nIn all scenarios, this adjustment phase occurs in the first several hours, with weaker price responses taking longer to recover. Fees and utilisation have approximately stabilised in all scenarios by block 3,000, about ten hours into the simulation. We use blocks 3,000–7,199, the remaining fourteen hours, for all settled-period medians below.\nThe rest of the day: two outcomes emerge\nOnce the limit reaches 200M and fees stabilise, the scenarios separate into two groups: those that attract enough demand to approach the 100M fee target, and those that remain below it even as the base fee becomes negligible.\nUnder this transaction mix, reaching the 100M fee target requires roughly 2.54 times the reference demand quantity. The horizontal dashed line in the plot below marks that multiplier. The plot follows demand through the full day, from its initial fall to its recovery as prices ease.\nDemand multiplier over the full 7,200 simulated blocks1990×507 155 KB\nNine scenarios settle near the dashed line, while three level off below it. These are the two outcomes described below.\n1. Enough demand to reach the fee target\nNine of the twelve scenarios have a settled-period median utilisation of roughly 50%. The feedback explains why these scenarios look similar on the utilisation chart. If arrivals remain above target, the base fee rises and reduces demand. If arrivals fall below target, the fee falls and attracts more demand. This brings the scenarios towards the same quantity, despite starting from different demand assumptions.\n2. Too little demand, even with a negligible base fee\nThe remaining three scenarios cannot attract enough demand to reach the 100M target:\n\nDemand scenario\nSettled-period median utilisation\nGas used per block\n\n1x, elasticity 0.1\n28.3%\n56.5M\n\n1x, elasticity 0.2\n38.7%\n77.4M\n\n1.5x, elasticity 0.1\n41.4%\n82.8M\n\nHere the base fee falls to a few tens of wei and stays negligible. Further reductions barely change the effective price because tips dominate: in the 1x, elasticity 0.1 scenario, the gas-weighted average tip per block has a median of about 0.025 gwei. With a weak price response, making the base-fee component nearly free does not bring enough additional demand to reach target.\nThis is the main low-demand outcome of the simulation: some of the new capacity remains unused, and tips account for almost all of the gas price paid by users.\nSimilar utilisation can come with very different fees\nReaching the same block utilisation does not mean paying the same price. Among the nine scenarios near 50% utilisation, different demand levels and price elasticities sustain very different base fees.\nThe chart below compares median base fees over blocks 3,000–7,199, after fees and utilisation have approximately stabilised in all scenarios. The dashed line marks the starting fee of about 0.085 gwei. As we can see, a larger limit does not guarantee a lower base fee if enough demand arrives.\nSettled-period median base fee by demand level and price elasticity1053×641 60.4 KB\nThe table gives the corresponding median base fees in gwei, based on 20,000 individual blocks sampled from blocks 3,000–7,199 across the 50 paths per scenario.\n\nDemand level\nElasticity 0.1\nElasticity 0.2\nElasticity 0.3\n\n1x\n<0.0001\n<0.0001\n0.0002\n\n1.5x\n<0.0001\n0.0021\n0.0258\n\n2x\n0.0059\n0.0609\n0.1058\n\n2.5x\n0.3199\n0.3722\n0.3928\n\nAt 2x demand, for example, all three elasticities produce roughly 50% utilisation, but the median base fee ranges from about 0.006 to 0.106 gwei. When demand responds more strongly to cheaper gas, a smaller price reduction is enough to attract the quantity needed for the target. The fee therefore stays higher.\nAt 2.5x demand, the scenarios already start close to the quantity needed at 200M, so less price adjustment is required. Their settled-period median fees are closer together, around 0.32–0.39 gwei. That narrowing does not mean elasticity is unimportant: it has a large effect on the early fee spike and on the lower-demand outcomes.\nAssumptions and limitations\n\nThe transaction mix is fixed. Transactions retain their upstream gas measurements when sampled or reordered. The simulator does not re-execute them against the resulting state, enforce nonces, balances, state dependencies or bundles, or predict how applications adapt to new gas costs. The source contains included transactions, so 1x is an observed-demand reference rather than a measurement of all potential demand.\nDemand responds only to price. One aggregate elasticity covers both gas dimensions and cannot represent substitution between them. Estimates based on historical daily data and base fees are applied to block-level effective prices and much lower fees. Confirmation delays do not deter arrivals, and adapted fee caps do not model users rebidding.\nCapacity uses measured gas. The model does not reserve space using transaction gas limits. Execution gas is usually the larger dimension, but state gas is larger in about 19–21% of blocks across scenarios and sometimes nearly fills the limit during the transition. About 85% of the trace’s state gas comes from transactions that would need higher signed gas limits to succeed under the new schedule, an adaptation assumed in these inputs.\nThe transition and sampling choices are untested sensitivities. Demand applies immediately, the price signal is smoothed, and transaction mixes are drawn independently from pools of 16 neighbouring source cohorts. Historical demand persistence is not preserved. This sweep does not vary those choices, and the one-day horizon limits conclusions about later behaviour. Numerical bounds on price response and base fee are model safeguards; neither the base-fee ceiling nor the demand-response bounds are hit in this run.\n\nReproducing the analysis\nThe report uses run 20260907T122124Z, drawing on source blocks 25,168,786–25,319,985, a span of roughly 21 days. It contains twelve scenarios with 50 paths each, all simulated for 7,200 blocks. The demand reference is the trace’s gas-weighted effective price of 1.0130 gwei, paired with average demand of 61.33M gas on the execution + state basis. That sum measures demand; block utilisation uses the larger dimension, so the two quantities should not be compared directly.\nThe price-response factor is bounded between 0.05 and 20 before multiplication by the demand level. Complete configuration, accounting rules and output definitions are in the methodology, with analysis and supporting diagnostics in the notebook.\n\n 2\n\n 2\n\n read \n\n 5\n min\n\n post by egpivo on Sep 15\n\n egpivo\n\n Interesting simulation. If a 200M gas limit materially lowers L1 execution costs, do you expect some activity to reallocate from L2s rather than simply move along a fixed L1 demand curve? Could that materially change the settled fee/utilisation outcomes?\n\n post by misilva73 on Sep 15\n\n misilva73\n\n In the simulation, I tested different demand multipliers (from 1x to 2.5x). A demand multiplier >1x means that we would observe new demand arriving in the L1. So, you can see what the impact would be in those cases. In some scenarios, there is so much new demand that the base fee even increases.\n\n post by egpivo on Sep 15\n\n egpivo\n\n Thanks, that makes sense. I was thinking more about the source of that additional demand whether lower L1 costs could endogenously pull activity from L2s, rather than treating the higher L1 demand as an exogenous multiplier. That seems like a natural extension of the current setup.\n\n Powered by Discourse","tokens":3698,"squid":"spider-04","role":"Research Spider","at":1791343468631,"hash":"741921a723037f2ac4d5e4adeea6b872b35a4fbc"}
{"url":"https://forum.across.to/c/proposals/passed-proposals/20","domain":"forum.across.to","title":"Latest Proposals/Passed Proposals topics - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n Latest topics in Passed Proposals\n\n Proposals\n\n Passed 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 posted\n Mar 14\n\n by @Britt\n\n Pinned\n\n About the Passed Proposals category\n\n posted\n Feb 15\n\n by @Britt\n\n [RFC - Governance update] Proposal to adjust voting quorum and approval threshold\n\n Header\nTitle: Proposal to adjust voting quorum and approval threshold \nAuthor(s): Britt \nStatus: Draft \nRelated Discussions: ongoing discussion in discord \nSubmission Date: TBD \nBody\nSummary: \nThe goal of this proposal i…\n\n read more\n\n John_Shutt\n replied\n\n Mar 15, 2023\n\n governance-updates\n\n 11\n\n 33\n\n posted\n Feb 8\n\n by @Britt\n\n Across Community Integration Campaign\n\n Header\nTitle: Community Integration Campaign \nAuthor(s): Britt and EAsports \nStatus: Vote \nRelated Discussions: N/A \nSubmission Date: 02/08/2023 \nBody\nSummary:\nThis proposal allocates $15k (in ACX) for bounties to commun…\n\n read more\n\n 99066.bnb\n replied\n\n Feb 15, 2023\n\n treasury-funding\n\n 17\n\n 23\n\n posted\n Jan 16\n\n by @Britt\n\n [RFC - Governance Update] Committee Formation Criteria\n\n Header\nTitle: Committee Formation Criteria \nAuthor(s): Britt - Across Community Lead \nStatus: RFC \nRelated Discussions: This proposal would result in an update to the operating manual, found here, and is inspired by the …\n\n read more\n\n Saludiego201\n replied\n\n Feb 13, 2023\n\n governance-updates\n\n 13\n\n 29\n\n posted\n Nov 15\n\n by @EAsports\n\n Across ($ACX) Community Initial Liquidity Proposal\n\n *ACP1: Across ($ACX) Community Initial Liquidity Proposal \nSummary - \nWith the upcoming token launch, liquidity is an important consideration. I am proposing that Across use Balancer for their liquidity DEX and that Risk…\n\n read more\n\n Max_Poplavskii\n replied\n\n Nov 27, 2022\n\n 49\n\n 124","tokens":1936,"squid":"spider-09","role":"Bridge Spider","at":1791343475578,"hash":"82c8207a34c3663c6e0dd1646ab30fb57b58ee72"}
{"url":"https://www.metaplex.com/docs/smart-contracts/mpl-agent/identity","domain":"metaplex.com","title":"Agent Identity Program | MPL Agent Registry | Metaplex","text":"The Agent Identity program registers an on-chain identity record for an MPL Core asset. SummaryThe Agent Identity program (1DREGFgysWYxLnRnKQnwrxnJQeSMk2HmGaC6whw2B2p) creates a PDA-based identity record for an MPL Core asset and attaches an AgentIdentity plugin with lifecycle hooks for Transfer, Update, and Execute.Single instruction — RegisterIdentityV1 handles PDA creation, account initialization, and plugin attachment in one transaction40-byte account — the AgentIdentityV1 PDA stores only the discriminator, bump, and asset public keyLifecycle hooks — the plugin registers approve, listen, and reject checks on Transfer, Update, and Execute eventsDeterministic PDA — derived from seeds [\"agent_identity\", <asset_pubkey>] for easy on-chain lookupsProgram IDNetworkAddressMainnet1DREGFgysWYxLnRnKQnwrxnJQeSMk2HmGaC6whw2B2pDevnet1DREGFgysWYxLnRnKQnwrxnJQeSMk2HmGaC6whw2B2pInstruction: RegisterIdentityV1Registers an agent identity by creating a PDA, and attaching an AgentIdentity plugin to the MPL Core asset with lifecycle hooks for Transfer, Update, and Execute.AccountsAccountWritableSignerOptionalDescriptionagentIdentityYesNoNoPDA to be created (auto-derived from asset)assetYesNoNoThe MPL Core asset to registercollectionYesNoYesThe asset's collectionpayerYesYesNoPays for account rent and feesauthorityNoYesYesCollection authority (defaults to payer)mplCoreProgramNoNoNoMPL Core programsystemProgramNoNoNoSystem programArgumentsArgumentTypeDescriptionagentRegistrationUristringURI pointing to off-chain agent registration metadataWhat It DoesDerives a PDA from seeds [\"agent_identity\", <asset>]Creates and initializes the AgentIdentityV1 account (40 bytes)CPIs into MPL Core to attach an AgentIdentity plugin to the asset with the provided URIRegisters lifecycle checks for Transfer, Update, and Execute events (approve, listen, and reject)Lifecycle ChecksThe AgentIdentity plugin registers hooks on three lifecycle events:EventApproveListenRejectTransferYesYesYesUpdateYesYesYesExecuteYesYesYesThis means the identity plugin can participate in approving, observing, or rejecting transfers, updates, and executions on the asset.PDA DerivationSeeds: [\"agent_identity\", <asset_pubkey>]import { findAgentIdentityV1Pda } from '@metaplex-foundation/mpl-agent-registry';\n\nconst pda = findAgentIdentityV1Pda(umi, { asset: assetPublicKey });\n// Returns [publicKey, bump]\nAccount: AgentIdentityV140 bytes, 8-byte aligned, zero-copy via bytemuck.OffsetFieldTypeSizeDescription0keyu81Account discriminator (1 = AgentIdentityV1)1bumpu81PDA bump seed2_padding[u8; 6]6Alignment padding8assetPubkey32The MPL Core asset this identity is bound toFetching Accountsimport {\n fetchAgentIdentityV1,\n safeFetchAgentIdentityV1,\n fetchAgentIdentityV1FromSeeds,\n fetchAllAgentIdentityV1,\n getAgentIdentityV1GpaBuilder,\n} from '@metaplex-foundation/mpl-agent-registry';\n\n// By PDA address (throws if not found)\nconst identity = await fetchAgentIdentityV1(umi, pda);\n\n// Safe fetch (returns null if not found)\nconst identity = await safeFetchAgentIdentityV1(umi, pda);\n\n// By seeds (derives PDA internally)\nconst identity = await fetchAgentIdentityV1FromSeeds(umi, { asset });\n\n// Batch fetch\nconst identities = await fetchAllAgentIdentityV1(umi, [pda1, pda2]);\n\n// GPA query\nconst results = await getAgentIdentityV1GpaBuilder(umi)\n .whereField('asset', assetPublicKey)\n .get();\nErrorsCodeNameDescription0InvalidSystemProgramSystem program account is incorrect1InvalidInstructionDataInstruction data is malformed2InvalidAccountDataPDA derivation does not match the asset3InvalidMplCoreProgramMPL Core program account is incorrect4InvalidCoreAssetAsset is not a valid MPL Core assetMaintained by Metaplex · Last verified March 2026 · View source on GitHub","tokens":935,"squid":"dotcat","role":"Tooling Spider","at":1791343478373,"hash":"cf959a0f93a4f3bab674bf201f02f5d7bd9693e0"}
{"url":"https://ethresear.ch/t/from-60m-to-200m-simulating-glamsterdam-s-fee-market/25957/4","domain":"ethresear.ch","title":"From 60M to 200M: simulating Glamsterdam’s fee market - Economics - Ethereum Research","text":"Economics\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 Sep 9\n\n 4 / 4\n\n Sep 15\n\n 21d ago\n\n post by misilva73 on Sep 9\n\n misilva73\n\n What happens to the fee market when Glamsterdam changes transaction gas costs and the gas limit rises from 60M to 200M? More capacity should ease pressure on fees, but cheaper gas also attracts demand. The outcome depends on how much demand arrives and how strongly users respond to the change in price. In addition, the gas limit grows gradually, so the fee market has time to adjust.\nIn this report, we simulate the first 7,200 blocks, or roughly one day, under twelve demand scenarios. The Glamsterdam gas schedule applies from the first block. The limit takes about four hours to reach 200M, leaving roughly twenty hours to observe how fees and block utilisation settle.\nUnder the demand assumptions tested here, the day has a clear sequence: an initial fee spike, a decline as capacity expands and demand responds, and then an adjustment around the new 100M target. The size of the spike depends heavily on how the demand scenario.\nAfter this adjustment phase, nine of the twelve demand scenarios have median utilisation near the EIP-1559 target, with median base fees ranging from 0.0002 to 0.3928 gwei. The other three remain below target even with an almost negligible base fee.\nHow is the simulation set up?\nWe start with roughly 21 days of historical mainnet transactions, replayed upstream with the Glamsterdam gas schedule implemented in an instrumented reth fork. This replay records how much gas each transaction uses under the new rules. Those measurements become fixed inputs to the simulation: sampling a transaction again does not re-execute it.\nThe simulation begins immediately after the fork, with the new gas schedule already active and the gas limit still at 60M. From the next block onwards, the limit increases by approximately 1/1024 of its previous value per block, until it reaches 200M at block 1,234, about four hours later.\nAt each simulated block, we repeat three steps:\n\nSample arrivals. A demand model determines how much gas arrives: higher prices reduce demand, and lower prices increase it. We sample historical transactions to meet that quantity and add them to the mempool alongside transactions waiting from earlier blocks.\nBuild the block. We select transactions that can pay the current base fee, ordered by effective tip. Each transaction is included if it fits within the remaining capacity. If it does not fit, we skip it and continue. Transactions left out remain in the mempool.\nUpdate the fee for the next block. We apply the EIP-1559 rule using this block’s utilisation. The base fee rises when utilisation exceeds the 50% target and falls when utilisation is below it. The block’s base fee and realised tips also update the price signal that determines subsequent demand.\n\nThis creates a feedback loop: fees change arrivals, arrivals change block utilisation, and utilisation changes the next base fee. As the limit grows, the fee target rises from 30M to 100M gas per block.\nAdditionally, block capacity follows two new accounting rules:\n\nExecution gas and state-creation gas must each fit within the limit, and utilisation is the larger of the two divided by the limit. This is introduced by EIP-8037.\nBlock capacity is measured before refunds (i.e., gas refunds do not count towards the block limit, per EIP-7778).\n\nWhat demand are we assuming?\nThe historical transactions supply the mix of work. The demand model determines how much of that work arrives at each block. It measures quantity as execution gas plus state gas, rather than transaction count. This demand measure differs from block utilisation, which uses the larger dimension.\nDemand responds to a smoothed effective price (base fee plus tip). We compare that price with a fixed reference price from the historical trace. When the simulated price falls below the reference, the model samples more demand. When it rises above it, the model samples less. Including tips matters when the base fee becomes negligible, because users still pay to have transactions included. An exponential moving average with a 200-block span makes the response gradual.\nWe also vary two assumptions:\n\nDemand level: 1x, 1.5x, 2x or 2.5x. This sets the quantity arriving at the reference price. At 1x, it is one historical average block’s worth of gas per simulated block, while at 2x, it is twice that amount. Actual arrivals then rise or fall with the simulated price, so a 2x scenario does not keep arrivals fixed at twice the historical quantity.\nPrice elasticity: 0.1, 0.2 or 0.3. This sets the strength of the response. Halving the effective price increases demand by roughly 7%, 15% or 23%, respectively. A larger elasticity therefore brings more demand back when fees fall, and reduces it more when fees rise. These values follow a previous empirical analysis.\n\nThe price signal starts at the historical reference, so initial demand is exactly the chosen level. That level applies in full from the first block, while the gas limit grows gradually. This timing is important for interpreting the early fee spike.\nWe simulate 50 paths for each of the twelve combinations. The next section shows the initial 3,000 blocks, or roughly ten hours, covering the ramp and the early settling period. The section after that shows the full 7,200-block day. The lines in the charts are means across paths and shaded bands show their 10th–90th percentile. The full-day chart uses 24-block averages within each path.\nThe first several hours: fees rise before capacity catches up\nThe transition starts with demand arriving against a 60M limit. The higher-demand scenarios initially fill blocks close to that limit, while even the 1x scenario starts above the 30M gas target (due to the increase in gas costs from repricings). The following plot shows this trend. The horizontal dashed line marks the 50% utilisation target, while the vertical dashed line marks the end of the ramp at block 1,234.\nBlock utilization over the first 3,000 simulated blocks1990×507 164 KB\nWith utilisation above target, EIP-1559 raises the base fee. Demand then falls as the smoothed effective price catches up. Meanwhile, the growing gas limit creates more room in each block. Together, these effects bring utilisation below target, causing the base fee to fall again.\nHigher elasticities produce an earlier, smaller fee peak. At the lowest elasticity, demand is less sensitive to price, so the base fee rises much higher before falling again. The base-fee axis is logarithmic, so the spike spans several orders of magnitude.\nBase fee over the first 3,000 simulated blocks1957×507 160 KB\nThe spike reflects the starting assumptions: full demand from block 0, a 60M initial limit, and a price signal that adjusts gradually from the historical reference. Together, these allow demand to stay high while the base fee rises sharply.\nThe spike therefore illustrates what can happen when demand arrives faster than capacity and reacts with a delay. Its magnitude should not be read as a forecast. This sweep does not test demand arriving gradually alongside the capacity increase, or alternative response delays.\nIn all scenarios, this adjustment phase occurs in the first several hours, with weaker price responses taking longer to recover. Fees and utilisation have approximately stabilised in all scenarios by block 3,000, about ten hours into the simulation. We use blocks 3,000–7,199, the remaining fourteen hours, for all settled-period medians below.\nThe rest of the day: two outcomes emerge\nOnce the limit reaches 200M and fees stabilise, the scenarios separate into two groups: those that attract enough demand to approach the 100M fee target, and those that remain below it even as the base fee becomes negligible.\nUnder this transaction mix, reaching the 100M fee target requires roughly 2.54 times the reference demand quantity. The horizontal dashed line in the plot below marks that multiplier. The plot follows demand through the full day, from its initial fall to its recovery as prices ease.\nDemand multiplier over the full 7,200 simulated blocks1990×507 155 KB\nNine scenarios settle near the dashed line, while three level off below it. These are the two outcomes described below.\n1. Enough demand to reach the fee target\nNine of the twelve scenarios have a settled-period median utilisation of roughly 50%. The feedback explains why these scenarios look similar on the utilisation chart. If arrivals remain above target, the base fee rises and reduces demand. If arrivals fall below target, the fee falls and attracts more demand. This brings the scenarios towards the same quantity, despite starting from different demand assumptions.\n2. Too little demand, even with a negligible base fee\nThe remaining three scenarios cannot attract enough demand to reach the 100M target:\n\nDemand scenario\nSettled-period median utilisation\nGas used per block\n\n1x, elasticity 0.1\n28.3%\n56.5M\n\n1x, elasticity 0.2\n38.7%\n77.4M\n\n1.5x, elasticity 0.1\n41.4%\n82.8M\n\nHere the base fee falls to a few tens of wei and stays negligible. Further reductions barely change the effective price because tips dominate: in the 1x, elasticity 0.1 scenario, the gas-weighted average tip per block has a median of about 0.025 gwei. With a weak price response, making the base-fee component nearly free does not bring enough additional demand to reach target.\nThis is the main low-demand outcome of the simulation: some of the new capacity remains unused, and tips account for almost all of the gas price paid by users.\nSimilar utilisation can come with very different fees\nReaching the same block utilisation does not mean paying the same price. Among the nine scenarios near 50% utilisation, different demand levels and price elasticities sustain very different base fees.\nThe chart below compares median base fees over blocks 3,000–7,199, after fees and utilisation have approximately stabilised in all scenarios. The dashed line marks the starting fee of about 0.085 gwei. As we can see, a larger limit does not guarantee a lower base fee if enough demand arrives.\nSettled-period median base fee by demand level and price elasticity1053×641 60.4 KB\nThe table gives the corresponding median base fees in gwei, based on 20,000 individual blocks sampled from blocks 3,000–7,199 across the 50 paths per scenario.\n\nDemand level\nElasticity 0.1\nElasticity 0.2\nElasticity 0.3\n\n1x\n<0.0001\n<0.0001\n0.0002\n\n1.5x\n<0.0001\n0.0021\n0.0258\n\n2x\n0.0059\n0.0609\n0.1058\n\n2.5x\n0.3199\n0.3722\n0.3928\n\nAt 2x demand, for example, all three elasticities produce roughly 50% utilisation, but the median base fee ranges from about 0.006 to 0.106 gwei. When demand responds more strongly to cheaper gas, a smaller price reduction is enough to attract the quantity needed for the target. The fee therefore stays higher.\nAt 2.5x demand, the scenarios already start close to the quantity needed at 200M, so less price adjustment is required. Their settled-period median fees are closer together, around 0.32–0.39 gwei. That narrowing does not mean elasticity is unimportant: it has a large effect on the early fee spike and on the lower-demand outcomes.\nAssumptions and limitations\n\nThe transaction mix is fixed. Transactions retain their upstream gas measurements when sampled or reordered. The simulator does not re-execute them against the resulting state, enforce nonces, balances, state dependencies or bundles, or predict how applications adapt to new gas costs. The source contains included transactions, so 1x is an observed-demand reference rather than a measurement of all potential demand.\nDemand responds only to price. One aggregate elasticity covers both gas dimensions and cannot represent substitution between them. Estimates based on historical daily data and base fees are applied to block-level effective prices and much lower fees. Confirmation delays do not deter arrivals, and adapted fee caps do not model users rebidding.\nCapacity uses measured gas. The model does not reserve space using transaction gas limits. Execution gas is usually the larger dimension, but state gas is larger in about 19–21% of blocks across scenarios and sometimes nearly fills the limit during the transition. About 85% of the trace’s state gas comes from transactions that would need higher signed gas limits to succeed under the new schedule, an adaptation assumed in these inputs.\nThe transition and sampling choices are untested sensitivities. Demand applies immediately, the price signal is smoothed, and transaction mixes are drawn independently from pools of 16 neighbouring source cohorts. Historical demand persistence is not preserved. This sweep does not vary those choices, and the one-day horizon limits conclusions about later behaviour. Numerical bounds on price response and base fee are model safeguards; neither the base-fee ceiling nor the demand-response bounds are hit in this run.\n\nReproducing the analysis\nThe report uses run 20260907T122124Z, drawing on source blocks 25,168,786–25,319,985, a span of roughly 21 days. It contains twelve scenarios with 50 paths each, all simulated for 7,200 blocks. The demand reference is the trace’s gas-weighted effective price of 1.0130 gwei, paired with average demand of 61.33M gas on the execution + state basis. That sum measures demand; block utilisation uses the larger dimension, so the two quantities should not be compared directly.\nThe price-response factor is bounded between 0.05 and 20 before multiplication by the demand level. Complete configuration, accounting rules and output definitions are in the methodology, with analysis and supporting diagnostics in the notebook.\n\n 2\n\n 2\n\n read \n\n 5\n min\n\n post by egpivo on Sep 15\n\n egpivo\n\n Interesting simulation. If a 200M gas limit materially lowers L1 execution costs, do you expect some activity to reallocate from L2s rather than simply move along a fixed L1 demand curve? Could that materially change the settled fee/utilisation outcomes?\n\n post by misilva73 on Sep 15\n\n misilva73\n\n In the simulation, I tested different demand multipliers (from 1x to 2.5x). A demand multiplier >1x means that we would observe new demand arriving in the L1. So, you can see what the impact would be in those cases. In some scenarios, there is so much new demand that the base fee even increases.\n\n post by egpivo on Sep 15\n\n egpivo\n\n Thanks, that makes sense. I was thinking more about the source of that additional demand whether lower L1 costs could endogenously pull activity from L2s, rather than treating the higher L1 demand as an exogenous multiplier. That seems like a natural extension of the current setup.\n\n Powered by Discourse","tokens":3684,"squid":"spider-04","role":"Research Spider","at":1791343479792,"hash":"1d9726c138f94642cd303b5dd01e5a78b1f09a8e"}
{"url":"https://eips.ethereum.org/EIPS/eip-1967","domain":"eips.ethereum.org","title":"ERC-1967: Proxy Storage Slots","text":"🎉 Final\n\n Standards Track: ERC\n\n ERC-1967: Proxy Storage Slots\n\n A consistent location where proxies store the address of the logic contract they delegate to, as well as other proxy-specific information.\n\n Authors\n Santiago Palladino (@spalladino), Francisco Giordano (@frangio), Hadrien Croubois (@Amxx)\n\n Created\n 2019-04-24\n\n Abstract\n\nDelegating proxy contracts are widely used for both upgradeability and gas savings. These proxies rely on a logic contract (also known as implementation contract or master copy) that is called using delegatecall. This allows proxies to keep a persistent state (storage and balance) while the code is delegated to the logic contract.\n\nTo avoid clashes in storage usage between the proxy and logic contract, the address of the logic contract is typically saved in a specific storage slot (for example 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc in OpenZeppelin contracts) guaranteed to be never allocated by a compiler. This EIP proposes a set of standard slots to store proxy information. This allows clients like block explorers to properly extract and show this information to end users, and logic contracts to optionally act upon it.\n\n Motivation\n\nDelegating proxies are widely in use, as a means to both support upgrades and reduce gas costs of deployments. Examples of these proxies are found in OpenZeppelin Contracts, Gnosis, AragonOS, Melonport, Limechain, WindingTree, Decentraland, and many others.\n\nHowever, the lack of a common interface for obtaining the logic address for a proxy makes it impossible to build common tools that act upon this information.\n\nA classic example of this is a block explorer. Here, the end user wants to interact with the underlying logic contract and not the proxy itself. Having a common way to retrieve the logic contract address from a proxy allows a block explorer to show the ABI of the logic contract and not that of the proxy. The explorer checks the storage of the contract at the distinguished slots to determine if it is indeed a proxy, in which case it shows information on both the proxy and the logic contract. As an example, this is how 0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48 is shown on Etherscan:\n\nAnother example is logic contracts that explicitly act upon the fact that they are being proxied. This allows them to potentially trigger a code update as part of their logic. A common storage slot allows these use cases independently of the specific proxy implementation being used.\n\n Specification\n\nMonitoring of proxies is essential to the security of many applications. It is thus essential to have the ability to track changes to the implementation and admin slots. Unfortunately, tracking changes to storage slots is not easy. Consequently, it is recommended that any function that changes any of these slots SHOULD also emit the corresponding event. This includes initialization, from 0x0 to the first non-zero value.\n\nThe proposed storage slots for proxy-specific information are the following. More slots for additional information can be added in subsequent ERCs as needed.\n\n Logic contract address\n\nStorage slot 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc\n(obtained as bytes32(uint256(keccak256('eip1967.proxy.implementation')) - 1)).\n\nHolds the address of the logic contract that this proxy delegates to. SHOULD be empty if a beacon is used instead. Changes to this slot SHOULD be notified by the event:\n\nevent Upgraded(address indexed implementation);\n\n Beacon contract address\n\nStorage slot 0xa3f0ad74e5423aebfd80d3ef4346578335a9a72aeaee59ff6cb3582b35133d50 (obtained as bytes32(uint256(keccak256('eip1967.proxy.beacon')) - 1)).\n\nHolds the address of the beacon contract this proxy relies on (fallback). SHOULD be empty if a logic address is used directly instead, and should only be considered if the logic contract slot is empty. Changes to this slot SHOULD be notified by the event:\n\nevent BeaconUpgraded(address indexed beacon);\n\nBeacons are used for keeping the logic address for multiple proxies in a single location, allowing the upgrade of multiple proxies by modifying a single storage slot. A beacon contract MUST implement the function:\n\nfunction implementation() returns (address)\n\nBeacon based proxy contracts do not use the logic contract slot. Instead, they use the beacon contract slot to store the address of the beacon they are attached to. In order to know the logic contract used by a beacon proxy, a client SHOULD:\n\n Read the address of the beacon for the beacon logic storage slot;\n Call the implementation() function on the beacon contract.\n\nThe result of the implementation() function on the beacon contract SHOULD NOT depend on the caller (msg.sender).\n\n Admin address\n\nStorage slot 0xb53127684a568b3173ae13b9f8a6016e243e63b6e8ee1178d6a717850b5d6103\n(obtained as bytes32(uint256(keccak256('eip1967.proxy.admin')) - 1)).\n\nHolds the address that is allowed to upgrade the logic contract address for this proxy (optional). Changes to this slot SHOULD be notified by the event:\n\nevent AdminChanged(address previousAdmin, address newAdmin);\n\n Rationale\n\nThis EIP standardises the storage slot for the logic contract address, instead of a public method on the proxy contract. The rationale for this is that proxies should never expose functions to end users that could potentially clash with those of the logic contract.\n\nNote that a clash may occur even among functions with different names, since the ABI relies on just four bytes for the function selector. This can lead to unexpected errors, or even exploits, where a call to a proxied contract returns a different value than expected, since the proxy intercepts the call and answers with a value of its own.\n\nFrom Malicious backdoors in Ethereum proxies by Nomic Labs:\n\n Any function in the Proxy contract whose selector matches with one in the implementation contract will be called directly, completely skipping the implementation code.\n\n Because the function selectors use a fixed amount of bytes, there will always be the possibility of a clash. This isn’t an issue for day to day development, given that the Solidity compiler will detect a selector clash within a contract, but this becomes exploitable when selectors are used for cross-contract interaction. Clashes can be abused to create a seemingly well-behaved contract that’s actually concealing a backdoor.\n\nThe fact that proxy public functions are potentially exploitable makes it necessary to standardise the logic contract address in a different way.\n\nThe main requirement for the storage slots chosen is that they must never be picked by the compiler to store any contract state variable. Otherwise, a logic contract could inadvertently overwrite this information on the proxy when writing to a variable of its own.\n\nSolidity maps variables to storage based on the order in which they were declared, after the contract inheritance chain is linearized: the first variable is assigned the first slot, and so on. The exception is values in dynamic arrays and mappings, which are stored in the hash of the concatenation of the key and the storage slot. The Solidity development team has confirmed that the storage layout is to be preserved among new versions:\n\n The layout of state variables in storage is considered to be part of the external interface of Solidity due to the fact that storage pointers can be passed to libraries. This means that any change to the rules outlined in this section is considered a breaking change of the language and due to its critical nature should be considered very carefully before being executed. In the event of such a breaking change, we would want to release a compatibility mode in which the compiler would generate bytecode supporting the old layout.\n\nVyper seems to follow the same strategy as Solidity. Note that contracts written in other languages, or directly in assembly, may incur in clashes.\n\nThey are chosen in such a way so they are guaranteed to not clash with state variables allocated by the compiler, since they depend on the hash of a string that does not start with a storage index. Furthermore, a -1 offset is added so the preimage of the hash cannot be known, further reducing the chances of a possible attack.\n\n Reference Implementation\n\n/**\n * @dev This contract implements an upgradeable proxy. It is upgradeable because calls are delegated to an\n * implementation address that can be changed. This address is stored in storage in the location specified by\n * https://eips.ethereum.org/EIPS/eip-1967[EIP1967], so that it doesn't conflict with the storage layout of the\n * implementation behind the proxy.\n */\ncontract ERC1967Proxy is Proxy, ERC1967Upgrade {\n /**\n * @dev Initializes the upgradeable proxy with an initial implementation specified by `_logic`.\n *\n * If `_data` is nonempty, it's used as data in a delegate call to `_logic`. This will typically be an encoded\n * function call, and allows initializing the storage of the proxy like a Solidity constructor.\n */\n constructor(address _logic, bytes memory _data) payable {\n assert(_IMPLEMENTATION_SLOT == bytes32(uint256(keccak256(\"eip1967.proxy.implementation\")) - 1));\n _upgradeToAndCall(_logic, _data, false);\n }\n\n /**\n * @dev Returns the current implementation address.\n */\n function _implementation() internal view virtual override returns (address impl) {\n return ERC1967Upgrade._getImplementation();\n }\n}\n\n/**\n * @dev This abstract contract provides getters and event emitting update functions for\n * https://eips.ethereum.org/EIPS/eip-1967[EIP1967] slots.\n */\nabstract contract ERC1967Upgrade {\n // This is the keccak-256 hash of \"eip1967.proxy.rollback\" subtracted by 1\n bytes32 private constant _ROLLBACK_SLOT = 0x4910fdfa16fed3260ed0e7147f7cc6da11a60208b5b9406d12a635614ffd9143;\n\n /**\n * @dev Storage slot with the address of the current implementation.\n * This is the keccak-256 hash of \"eip1967.proxy.implementation\" subtracted by 1, and is\n * validated in the constructor.\n */\n bytes32 internal constant _IMPLEMENTATION_SLOT = 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc;\n\n /**\n * @dev Emitted when the implementation is upgraded.\n */\n event Upgraded(address indexed implementation);\n\n /**\n * @dev Returns the current implementation address.\n */\n function _getImplementation() internal view returns (address) {\n return StorageSlot.getAddressSlot(_IMPLEMENTATION_SLOT).value;\n }\n\n /**\n * @dev Stores a new address in the EIP1967 implementation slot.\n */\n function _setImplementation(address newImplementation) private {\n require(Address.isContract(newImplementation), \"ERC1967: new implementation is not a contract\");\n StorageSlot.getAddressSlot(_IMPLEMENTATION_SLOT).value = newImplementation;\n }\n\n /**\n * @dev Perform implementation upgrade\n *\n * Emits an {Upgraded} event.\n */\n function _upgradeTo(address newImplementation) internal {\n _setImplementation(newImplementation);\n emit Upgraded(newImplementation);\n }\n\n /**\n * @dev Perform implementation upgrade with additional setup call.\n *\n * Emits an {Upgraded} event.\n */\n function _upgradeToAndCall(\n address newImplementation,\n bytes memory data,\n bool forceCall\n ) internal {\n _upgradeTo(newImplementation);\n if (data.length > 0 || forceCall) {\n Address.functionDelegateCall(newImplementation, data);\n }\n }\n\n /**\n * @dev Perform implementation upgrade with security checks for UUPS proxies, and additional setup call.\n *\n * Emits an {Upgraded} event.\n */\n function _upgradeToAndCallSecure(\n address newImplementation,\n bytes memory data,\n bool forceCall\n ) internal {\n address oldImplementation = _getImplementation();\n\n // Initial upgrade and setup call\n _setImplementation(newImplementation);\n if (data.length > 0 || forceCall) {\n Address.functionDelegateCall(newImplementation, data);\n }\n\n // Perform rollback test if not already in progress\n StorageSlot.BooleanSlot storage rollbackTesting = StorageSlot.getBooleanSlot(_ROLLBACK_SLOT);\n if (!rollbackTesting.value) {\n // Trigger rollback using upgradeTo from the new implementation\n rollbackTesting.value = true;\n Address.functionDelegateCall(\n newImplementation,\n abi.encodeWithSignature(\"upgradeTo(address)\", oldImplementation)\n );\n rollbackTesting.value = false;\n // Check rollback was effective\n require(oldImplementation == _getImplementation(), \"ERC1967Upgrade: upgrade breaks further upgrades\");\n // Finally reset to the new implementation and log the upgrade\n _upgradeTo(newImplementation);\n }\n }\n\n /**\n * @dev Storage slot with the admin of the contract.\n * This is the keccak-256 hash of \"eip1967.proxy.admin\" subtracted by 1, and is\n * validated in the constructor.\n */\n bytes32 internal constant _ADMIN_SLOT = 0xb53127684a568b3173ae13b9f8a6016e243e63b6e8ee1178d6a717850b5d6103;\n\n /**\n * @dev Emitted when the admin account has changed.\n */\n event AdminChanged(address previousAdmin, address newAdmin);\n\n /**\n * @dev Returns the current admin.\n */\n function _getAdmin() internal view returns (address) {\n return StorageSlot.getAddressSlot(_ADMIN_SLOT).value;\n }\n\n /**\n * @dev Stores a new address in the EIP1967 admin slot.\n */\n function _setAdmin(address newAdmin) private {\n require(newAdmin != address(0), \"ERC1967: new admin is the zero address\");\n StorageSlot.getAddressSlot(_ADMIN_SLOT).value = newAdmin;\n }\n\n /**\n * @dev Changes the admin of the proxy.\n *\n * Emits an {AdminChanged} event.\n */\n function _changeAdmin(address newAdmin) internal {\n emit AdminChanged(_getAdmin(), newAdmin);\n _setAdmin(newAdmin);\n }\n\n /**\n * @dev The storage slot of the UpgradeableBeacon contract which defines the implementation for this proxy.\n * This is bytes32(uint256(keccak256('eip1967.proxy.beacon')) - 1)) and is validated in the constructor.\n */\n bytes32 internal constant _BEACON_SLOT = 0xa3f0ad74e5423aebfd80d3ef4346578335a9a72aeaee59ff6cb3582b35133d50;\n\n /**\n * @dev Emitted when the beacon is upgraded.\n */\n event BeaconUpgraded(address indexed beacon);\n\n /**\n * @dev Returns the current beacon.\n */\n function _getBeacon() internal view returns (address) {\n return StorageSlot.getAddressSlot(_BEACON_SLOT).value;\n }\n\n /**\n * @dev Stores a new beacon in the EIP1967 beacon slot.\n */\n function _setBeacon(address newBeacon) private {\n require(Address.isContract(newBeacon), \"ERC1967: new beacon is not a contract\");\n require(\n Address.isContract(IBeacon(newBeacon).implementation()),\n \"ERC1967: beacon implementation is not a contract\"\n );\n StorageSlot.getAddressSlot(_BEACON_SLOT).value = newBeacon;\n }\n\n /**\n * @dev Perform beacon upgrade with additional setup call. Note: This upgrades the address of the beacon, it does\n * not upgrade the implementation contained in the beacon (see {UpgradeableBeacon-_setImplementation} for that).\n *\n * Emits a {BeaconUpgraded} event.\n */\n function _upgradeBeaconToAndCall(\n address newBeacon,\n bytes memory data,\n bool forceCall\n ) internal {\n _setBeacon(newBeacon);\n emit BeaconUpgraded(newBeacon);\n if (data.length > 0 || forceCall) {\n Address.functionDelegateCall(IBeacon(newBeacon).implementation(), data);\n }\n }\n}\n\n/**\n * @dev This abstract contract provides a fallback function that delegates all calls to another contract using the EVM\n * instruction `delegatecall`. We refer to the second contract as the _implementation_ behind the proxy, and it has to\n * be specified by overriding the virtual {_implementation} function.\n *\n * Additionally, delegation to the implementation can be triggered manually through the {_fallback} function, or to a\n * different contract through the {_delegate} function.\n *\n * The success and return data of the delegated call will be returned back to the caller of the proxy.\n */\nabstract contract Proxy {\n /**\n * @dev Delegates the current call to `implementation`.\n *\n * This function does not return to its internal call site, it will return directly to the external caller.\n */\n function _delegate(address implementation) internal virtual {\n assembly {\n // Copy msg.data. We take full control of memory in this inline assembly\n // block because it will not return to Solidity code. We overwrite the\n // Solidity scratch pad at memory position 0.\n calldatacopy(0, 0, calldatasize())\n\n // Call the implementation.\n // out and outsize are 0 because we don't know the size yet.\n let result := delegatecall(gas(), implementation, 0, calldatasize(), 0, 0)\n\n // Copy the returned data.\n returndatacopy(0, 0, returndatasize())\n\n switch result\n // delegatecall returns 0 on error.\n case 0 {\n revert(0, returndatasize())\n }\n default {\n return(0, returndatasize())\n }\n }\n }\n\n /**\n * @dev This is a virtual function that should be overridden so it returns the address to which the fallback function\n * and {_fallback} should delegate.\n */\n function _implementation() internal view virtual returns (address);\n\n /**\n * @dev Delegates the current call to the address returned by `_implementation()`.\n *\n * This function does not return to its internal call site, it will return directly to the external caller.\n */\n function _fallback() internal virtual {\n _beforeFallback();\n _delegate(_implementation());\n }\n\n /**\n * @dev Fallback function that delegates calls to the address returned by `_implementation()`. Will run if no other\n * function in the contract matches the call data.\n */\n fallback() external payable virtual {\n _fallback();\n }\n\n /**\n * @dev Fallback function that delegates calls to the address returned by `_implementation()`. Will run if call data\n * is empty.\n */\n receive() external payable virtual {\n _fallback();\n }\n\n /**\n * @dev Hook that is called before falling back to the implementation. Can happen as part of a manual `_fallback`\n * call, or as part of the Solidity `fallback` or `receive` functions.\n *\n * If overridden should call `super._beforeFallback()`.\n */\n function _beforeFallback() internal virtual {}\n}\n\n/**\n * @dev Library for reading and writing primitive types to specific storage slots.\n *\n * Storage slots are often used to avoid storage conflict when dealing with upgradeable contracts.\n * This library helps with reading and writing to such slots without the need for inline assembly.\n *\n * The functions in this library return Slot structs that contain a `value` member that can be used to read or write.\n */\nlibrary StorageSlot {\n struct AddressSlot {\n address value;\n }\n\n struct BooleanSlot {\n bool value;\n }\n\n struct Bytes32Slot {\n bytes32 value;\n }\n\n struct Uint256Slot {\n uint256 value;\n }\n\n /**\n * @dev Returns an `AddressSlot` with member `value` located at `slot`.\n */\n function getAddressSlot(bytes32 slot) internal pure returns (AddressSlot storage r) {\n assembly {\n r.slot := slot\n }\n }\n\n /**\n * @dev Returns an `BooleanSlot` with member `value` located at `slot`.\n */\n function getBooleanSlot(bytes32 slot) internal pure returns (BooleanSlot storage r) {\n assembly {\n r.slot := slot\n }\n }\n\n /**\n * @dev Returns an `Bytes32Slot` with member `value` located at `slot`.\n */\n function getBytes32Slot(bytes32 slot) internal pure returns (Bytes32Slot storage r) {\n assembly {\n r.slot := slot\n }\n }\n\n /**\n * @dev Returns an `Uint256Slot` with member `value` located at `slot`.\n */\n function getUint256Slot(bytes32 slot) internal pure returns (Uint256Slot storage r) {\n assembly {\n r.slot := slot\n }\n }\n}\n\n Security Considerations\n\nThis ERC relies on the fact that the chosen storage slots are not to be allocated by the solidity compiler. This guarantees that an implementation contract will not accidentally overwrite any of the information required for the proxy to operate. As such, locations with a high slot number were chosen to avoid clashes with the slots allocated by the compiler. Also, locations with no known preimage were picked, to ensure that a write to mapping with a maliciously crafted key could not overwrite it.\n\nLogic contracts that intend to modify proxy-specific information must do so deliberately (as is the case with UUPS) by writing to the specific storage slot.\n\n Copyright\n\nCopyright and related rights waived via CC0.\n\n Citation\n Please cite this document as:\n\n Santiago Palladino (@spalladino), Francisco Giordano (@frangio), Hadrien Croubois (@Amxx), \"ERC-1967: Proxy Storage Slots,\" Ethereum Improvement Proposals, no. 1967, April 2019. Available: https://eips.ethereum.org/EIPS/eip-1967.","tokens":5055,"squid":"spider-05","role":"Spec Spider","at":1791343500405,"hash":"3589b514a2a86746db978fa1424e97f792617617"}
{"url":"https://eips.ethereum.org/EIPS/eip-2098","domain":"eips.ethereum.org","title":"ERC-2098: Compact Signature Representation","text":"🎉 Final\n\n Standards Track: ERC\n\n ERC-2098: Compact Signature Representation\n\n A compact representation of an Ethereum Signature.\n\n Authors\n Richard Moore (@ricmoo), Nick Johnson <nick@ethereum.org>\n\n Created\n 2019-03-14\n\n Requires\n\n EIP-2\n\n Abstract\n\nThe secp256k1 curve permits the computation of the public key of signed\ndigest when coupled with a signature, which is used implicitly to\nestablish the origin of a transaction from an Externally Owned Account\nas well as on-chain in EVM contracts for example, in meta-transactions and\nmulti-sig contracts.\n\nCurrently signatures require 65 bytes to represent, which when aligned\nto 256-bit words, requires 96 bytes (with 31 zero bytes injected). The\nyParity in RLP-encoded transactions also require (on average) 1.5 bytes.\nWith compact signatures, this can be reduced to 64 bytes, which remains 64\nbytes when word-aligned, and in the case of RLP-encoded transactions\nsaves the 1.5 bytes required for the yParity.\n\n Motivation\n\nThe motivations for a compact representation are to simplify handling\ntransactions in client code, reduce gas costs and reduce transaction sizes.\n\n Specification\n\nA secp256k1 signature is made up of 3 parameters, r, s and yParity.\nThe r represents the x component on the curve (from which the y can be\ncomputed), and the s represents the challenge solution for signing by a\nprivate key. Due to the symmetric nature of an elliptic curve, a yParity\nis required, which indicates which of the 2 possible solutions was intended,\nby indicating its parity (odd-ness).\n\nTwo key observations are required to create a compact representation.\n\nFirst, the yParity parameter is always either 0 or 1 (canonically the values\nused have historically been 27 and 28, as these values didn’t collide with other\nbinary prefixes used in Bitcoin).\n\nSecond, the top bit of the s parameters is always 0, due to the use of\ncanonical signatures which flip the solution parity to prevent negative values,\nwhich was introduced as a constraint in Homestead.\n\nSo, we can hijack the top bit in the s parameter to store the value of\nyParity, resulting in:\n\n[256-bit r value][1-bit yParity value][255-bit s value]\n\n Example Implementation In Python\n\n# Assume yParity is 0 or 1, normalized from the canonical 27 or 28\ndef to_compact(r, s, yParity):\n return {\n \"r\": r,\n \"yParityAndS\": (yParity << 255) | s\n }\n\ndef to_canonical(r, yParityAndS):\n return {\n \"r\": r,\n \"s\": yParityAndS & ((1 << 255) - 1),\n \"yParity\": (yParityAndS >> 255)\n }\n\n Rationale\n\nThe compact representation proposed is simple to both compose and decompose\nin clients and in Solidity, so that it can be easily (and intuitively) supported,\nwhile reducing transaction sizes and gas costs.\n\n Backwards Compatibility\n\nThe Compact Representation does not collide with canonical signature as\nit uses 2 parameters (r, yParityAndS) and is 64 bytes long while canonical\nsignatures involve 3 separate parameters (r, s, yParity) and are 65 bytes long.\n\n Test Cases\n\nPrivate Key: 0x1234567890123456789012345678901234567890123456789012345678901234\nMessage: \"Hello World\"\nSignature:\n r: 0x68a020a209d3d56c46f38cc50a33f704f4a9a10a59377f8dd762ac66910e9b90\n s: 0x7e865ad05c4035ab5792787d4a0297a43617ae897930a6fe4d822b8faea52064\n v: 27\nCompact Signature:\n r: 0x68a020a209d3d56c46f38cc50a33f704f4a9a10a59377f8dd762ac66910e9b90\n yParityAndS: 0x7e865ad05c4035ab5792787d4a0297a43617ae897930a6fe4d822b8faea52064\n\nPrivate Key: 0x1234567890123456789012345678901234567890123456789012345678901234\nMessage: \"It's a small(er) world\"\nSignature:\n r: 0x9328da16089fcba9bececa81663203989f2df5fe1faa6291a45381c81bd17f76\n s: 0x139c6d6b623b42da56557e5e734a43dc83345ddfadec52cbe24d0cc64f550793\n v: 28\nCompact Signature:\n r: 0x9328da16089fcba9bececa81663203989f2df5fe1faa6291a45381c81bd17f76\n yParityAndS: 0x939c6d6b623b42da56557e5e734a43dc83345ddfadec52cbe24d0cc64f550793 \n\n Reference Implementation\n\nThe ethers.js library supports this in v5\nas an unofficial property of split signatures (i.e. sig._vs), but should be\nconsidered an internal property that may change at discretion of the community\nand any changes to this EIP.\n\n Security Considerations\n\nThere are no additional security concerns introduced by this EIP.\n\n Copyright\n\nCopyright and related rights waived via CC0.\n\n Citation\n Please cite this document as:\n\n Richard Moore (@ricmoo), Nick Johnson <nick@ethereum.org>, \"ERC-2098: Compact Signature Representation,\" Ethereum Improvement Proposals, no. 2098, March 2019. Available: https://eips.ethereum.org/EIPS/eip-2098.","tokens":1126,"squid":"spider-05","role":"Spec Spider","at":1791343524091,"hash":"1be66e62fef083507f7573c0512c0dcb89e24c5f"}
{"url":"https://developers.jup.ag/docs/trigger/lifecycle","domain":"developers.jup.ag","title":"Integration Flow - Jupiter Developers","text":"This page maps a trigger order from start to finish: which endpoints to call, in what order, the data that flows from one call into the next, and the states an order moves through. Both order families, price (limit) orders and DCA, follow the same spine. They differ only at the create, monitor, and manage steps. Each endpoint has its own detail page, linked at every step.\n​Prerequisites\n\nAn API key from the Portal. All requests require the x-api-key header.\nA Solana wallet. Every step that moves funds (deposit, withdrawal) is signed client-side by the wallet owner.\n\n​The Flow\nAuthenticate once, set up your vault once, then repeat deposit-and-create per order. The key to integrating is the data hand-off: each call produces the value the next call needs. The shared spine:\n\nCreate and monitor are the family-specific steps (price orders vs DCA); everything else is shared.\nAll endpoints are under https://api.jup.ag/trigger/v2.\n​Limit orders vs DCA\nThe two families share authentication, the vault, and the deposit endpoint. They diverge at the calls below.\nStepLimit ordersDCADeposit orderTypeprice (with orderSubType)dcaCreatePOST /orders/pricePOST /orders/dcaOrder typessingle, oco, otocotime_based, price_conditionalTrackGET /orders/historyGET /orders/history/dcaEditPATCH /orders/price/{id}Not supportedCancelPOST /orders/price/cancel/{id} + /confirm-cancel/{id}POST /orders/dca/cancel/{id} + /confirm-cancel/{id}Detail pagesCreate, Track, ManageCreate, Track, Cancel\n​Step by Step\n​1. Authenticate\nCall POST /auth/challenge with your walletPubkey and a type of message (standard wallets) or transaction (hardware wallets). Sign the returned challenge, then submit it to POST /auth/verify to receive a JWT token. Include the token as Authorization: Bearer <token> on every subsequent call.\nThe token is valid for 24 hours. There is no refresh endpoint: when it expires, repeat the challenge-response flow.\nSee Authentication for the message and transaction flows and the full token lifecycle.\n​2. Get or register your vault\nCall GET /vault to resolve your vault, or GET /vault/register on first use. The vault is a Privy-managed custodial account that holds deposits for all your orders. The vault address is resolved from your JWT, so you do not pass it into later calls.\nSee Vault & Deposit.\n​3. Craft and sign a deposit\nCall POST /deposit/craft with the input/output mints, amount, and orderType. For a price order, also pass the orderSubType that matches the order you will create (single, oco, or otoco); for DCA, use orderType: \"dca\" with no subtype. It returns an unsigned transaction and a requestId. Sign the transaction client-side to produce depositSignedTx.\nThe API stores the deposit’s token accounts against the requestId, so you carry only the requestId and depositSignedTx into the next step.\nSee Vault & Deposit.\n​4. Create the order\nCall your family’s create endpoint with depositRequestId, depositSignedTx, and your order parameters.\n\nLimit orders: POST /orders/price. The orderType (single, oco, otoco) determines which fields are required. The response returns the order id (the ocoId, your primary identifier) and a txSignature. See Create Order.\nDCA: POST /orders/dca with orderCount, intervalSeconds, and orderType (time_based or price_conditional). The response returns { id, txSignature }. See Create a DCA Order.\n\nFor both families the deposit lands on-chain during this call, so a 200 means the order is live.\n​5. Monitor order state\nTrack an order through its lifecycle:\n\nLimit orders: GET /orders/history. Each order carries an orderState (display) and rawState (internal), plus an events array. See Order History.\nDCA: GET /orders/history/dca (or /orders/history/dca/{id} for one order). Each order reports its schedule, roundsFilled, fillPercent, state/displayState, and events. See Track a DCA Order.\n\n​6. Edit or cancel\n\nLimit orders can be updated in place while open: PATCH /orders/price/{id} to change the trigger price, slippage, or expiry. No new deposit is needed. See Manage Orders.\nDCA orders cannot be edited. To change a schedule, cancel and create a new order. See Cancel a DCA Order.\n\nTo cancel either family, call the family’s cancel endpoint, which returns a withdrawal transaction to sign (step 7).\n​7. Confirm cancellation\nSign the withdrawal transaction from step 6 and submit it to the family’s confirm-cancel endpoint (POST /orders/price/confirm-cancel/{id} or POST /orders/dca/confirm-cancel/{id}) with the cancelRequestId. This returns the unfilled funds to your wallet.\nSee Cancellation and Recovery for what happens if this step is interrupted.\n​Order State Lifecycle\nEach family has its own state machine. Both report a display state and an internal state through their history endpoint.\n​Price orders\n\nopen orders can be updated or cancelled. Updates and cancellation are only valid from this state.\nexecuting covers the swap from trigger detection to output withdrawal, including partial fills.\nexpired orders did not fill before expiresAt. The deposit is still in the vault and is retrieved with the same cancel flow (see below).\n\nOCO orders: the take-profit and stop-loss legs share one deposit. When one leg fills, the other transitions to cancelled automatically (oco_cancelled in the raw state). OTOCO orders: the child OCO pair only activates after the parent order reaches filled; if the parent expires or fails, the children are never created.\nFor the complete orderState ↔ rawState mapping and the events schema, see Order History.\n​DCA\n\nDCA states map to a display state: depositing→pending, active, executing, withdrawing→pending_withdraw, completed, cancelled, and deposit_failed→failed. There is no open or expired state; a DCA ends at completed when its budget is spent. A price_conditional round that is out of band does not fill: the order stays active with roundsFilled unchanged until the price re-enters the band. For the full mapping, see Track a DCA Order.\n​Cancellation and Recovery\nCancellation is a two-step process designed so funds are never at risk mid-flow. It works the same way for both families; the paths differ only by segment (price or dca):\n\nInitiate with POST /orders/{price|dca}/cancel/{id}. The order stops accepting fills immediately, and the call returns an unsigned withdrawal transaction and a cancelRequestId.\nConfirm by signing that transaction and submitting it to POST /orders/{price|dca}/confirm-cancel/{id}. The unfilled funds return to your wallet.\n\nBetween the two steps the order is safe: fills are stopped and the deposit remains in the vault.\nIf the second step is interrupted (the tab closes, or the transaction does not land):\nYou still have the withdrawal transaction and cancelRequestId: retry confirm-cancel with the same cancelRequestId.\nYou lost the withdrawal transaction: call cancel again. The order is already mid-cancel, so the call crafts and returns a fresh withdrawal transaction to sign (idempotent).\nThe order stays mid-cancel until a withdrawal confirms on-chain, so funds are never stranded.\nThe details differ slightly by family. A price order can be cancelled while open, and the same flow retrieves funds from one that has expired. A DCA order can be cancelled while active or withdrawing; a failed confirm-cancel leaves it in withdrawing and does not roll back to active. Cancelling a DCA returns the unfilled remainder (refundAmount, roundsRemaining); rounds already filled are not reversed. See Cancel a DCA Order.\n​Related\nWas this page helpful?","tokens":1874,"squid":"spider-02","role":"Liquidity Spider","at":1791343534560,"hash":"87b602d00c732bb6dd26e2bfdaad856cadcfb0f5"}
{"url":"https://eips.ethereum.org/EIPS/eip-2135","domain":"eips.ethereum.org","title":"ERC-2135: Consumable Interface (Tickets, etc)","text":"🎉 Final\n\n Standards Track: ERC\n\n ERC-2135: Consumable Interface (Tickets, etc)\n\n An interface extending ERC-721 and ERC-1155 for consumability, supporting use case such as an event ticket.\n\n Authors\n Zainan Victor Zhou (@xinbenlv)\n\n Created\n 2019-06-23\n\n Requires\n\n EIP-165, \n\n EIP-721, \n\n EIP-1155\n\n Abstract\n\nThis EIP defines an interface to mark a digital asset as “consumable” and to react to its “consumption.”\n\n Motivation\n\nDigital assets sometimes need to be consumed. One of the most common examples is a concert ticket.\nIt is “consumed” when the ticket-holder enters the concert hall.\n\nHaving a standard interface enables interoperability for services, clients, UI, and inter-contract functionalities on top of this use-case.\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\n Any compliant contract MUST implement the following interface:\n\npragma solidity >=0.7.0 <0.9.0;\n\n/// The ERC-165 identifier of this interface is 0xdd691946\ninterface IERC2135 {\n /// @notice The consume function consumes a token every time it succeeds.\n /// @param _consumer the address of consumer of this token. It doesn't have\n /// to be the EOA or contract Account that initiates the TX.\n /// @param _assetId the NFT asset being consumed\n /// @param _data extra data passed in for consume for extra message\n /// or future extension.\n function consume(\n address _consumer,\n uint256 _assetId,\n uint256 _amount,\n bytes calldata _data\n ) external returns (bool _success);\n\n /// @notice The interface to check whether an asset is consumable.\n /// @param _consumer the address of consumer of this token. It doesn't have\n /// to be the EOA or contract Account that initiates the TX.\n /// @param _assetId the NFT asset being consumed.\n /// @param _amount the amount of the asset being consumed.\n function isConsumableBy(\n address _consumer,\n uint256 _assetId,\n uint256 _amount\n ) external view returns (bool _consumable);\n\n /// @notice The event emitted when there is a successful consumption.\n /// @param consumer the address of consumer of this token. It doesn't have\n /// to be the EOA or contract Account that initiates the TX.\n /// @param assetId the NFT asset being consumed\n /// @param amount the amount of the asset being consumed.\n /// @param data extra data passed in for consume for extra message\n /// or future extension.\n event OnConsumption(\n address indexed consumer,\n uint256 indexed assetId,\n uint256 amount,\n bytes data\n );\n}\n\n If the compliant contract is an ERC-721 or ERC-1155 token, in addition to OnConsumption, it MUST also emit the Transfer / TransferSingle event (as applicable) as if a token has been transferred from the current holder to the zero address if the call to consume method succeeds.\n\n supportsInterface(0xdd691946) MUST return true for any compliant contract, as per ERC-165.\n\n Rationale\n\n The function consume performs the consume action. This EIP does not assume:\n\n who has the power to perform consumption\n under what condition consumption can occur\n\nIt does, however, assume the asset can be identified in a uint256 asset id as in the parameter. A design convention and compatibility consideration is put in place to follow the ERC-721 pattern.\n\n The event notifies subscribers whoever are interested to learn an asset is being consumed.\n\n To keep it simple, this standard intentionally contains no functions or events related to the creation of a consumable asset. This is because the creation of a consumable asset will need to make assumptions about the nature of an actual use-case. If there are common use-cases for creation, another follow up standard can be created.\n\n Metadata associated to the consumables is not included the standard. If necessary, related metadata can be created with a separate metadata extension interface like ERC721Metadata from ERC-721\n\n We choose to include an address consumer for consume function and isConsumableBy so that an NFT MAY be consumed for someone other than the transaction initiator.\n\n We choose to include an extra _data field for future extension, such as\nadding crypto endorsements.\n\n We explicitly stay opinion-less about whether ERC-721 or ERC-1155 shall be required because\nwhile we design this EIP with ERC-721 and ERC-1155 in mind mostly, we don’t want to rule out\nthe potential future case someone use a different token standard or use it in different use cases.\n\n The boolean view function of isConsumableBy can be used to check whether an asset is\nconsumable by the _consumer.\n\n Backwards Compatibility\n\nThis interface is designed to be compatible with ERC-721 and NFT of ERC-1155. It can be tweaked to used for ERC-20, ERC-777 and Fungible Token of ERC-1155.\n\n Test Cases\n\n describe(\"Consumption\", function () {\n it(\"Should consume when minted\", async function () {\n const fakeTokenId = \"0x1234\";\n const { contract, addr1 } = await loadFixture(deployFixture);\n await contract.safeMint(addr1.address, fakeTokenId);\n expect(await contract.balanceOf(addr1.address)).to.equal(1);\n expect(await contract.ownerOf(fakeTokenId)).to.equal(addr1.address);\n expect(await contract.isConsumableBy(addr1.address, fakeTokenId, 1)).to.be.true;\n const tx = await contract.consume(addr1.address, fakeTokenId, 1, []);\n const receipt = await tx.wait();\n const events = receipt.events.filter((x: any) => { return x.event == \"OnConsumption\" });\n expect(events.length).to.equal(1);\n expect(events[0].args.consumer).to.equal(addr1.address);\n expect(events[0].args.assetId).to.equal(fakeTokenId);\n expect(events[0].args.amount).to.equal(1);\n expect(await contract.balanceOf(addr1.address)).to.equal(0);\n await expect(contract.ownerOf(fakeTokenId))\n .to.be.rejectedWith('ERC721: invalid token ID');\n await expect(contract.isConsumableBy(addr1.address, fakeTokenId, 1))\n .to.be.rejectedWith('ERC721: invalid token ID');\n });\n });\n\n describe(\"EIP-165 Identifier\", function () {\n it(\"Should match\", async function () {\n const { contract } = await loadFixture(deployFixture);\n expect(await contract.get165()).to.equal(\"0xdd691946\");\n expect(await contract.supportsInterface(\"0xdd691946\")).to.be.true;\n });\n });\n\n Reference Implementation\n\nA deployment of version 0x1002 has been deployed onto goerli testnet at address 0x3682bcD67b8A5c0257Ab163a226fBe07BF46379B.\n\nFind the reference contract verified source code on Etherscan’s\ngoerli site for the address above.\n\n Security Considerations\n\nCompliant contracts should pay attention to the balance change when a token is consumed.\nWhen the contract is being paused, or the user is being restricted from transferring a token,\nthe consumeability should be consistent with the transferral restriction.\n\nCompliant contracts should also carefully define access control, particularly whether any EOA or contract account may or may not initiate a consume method in their own use case.\n\nSecurity audits and tests should be used to verify that the access control to the consume\nfunction behaves as expected.\n\n Copyright\n\nCopyright and related rights waived via CC0.\n\n Citation\n Please cite this document as:\n\n Zainan Victor Zhou (@xinbenlv), \"ERC-2135: Consumable Interface (Tickets, etc),\" Ethereum Improvement Proposals, no. 2135, June 2019. Available: https://eips.ethereum.org/EIPS/eip-2135.","tokens":1839,"squid":"spider-05","role":"Spec Spider","at":1791343544104,"hash":"8042ed24840a0f0a0a185a5b48395de3e97d77b5"}
{"url":"https://eips.ethereum.org/EIPS/eip-2255","domain":"eips.ethereum.org","title":"EIP-2255: Wallet Permissions System","text":"🎉 Final\n\n Standards Track: Interface\n\n EIP-2255: Wallet Permissions System\n\n An interface to restrict access to sensitive methods\n\n Authors\n Dan Finlay (@danfinlay), Erik Marks (@rekmarks), Gavin John (@Pandapip1)\n\n Created\n 2019-08-22\n\n Requires\n\n EIP-1193\n\n Abstract\n\nThis EIP adds two new wallet-namespaced RPC endpoints, wallet_getPermissions and wallet_requestPermissions, providing a standard interface for requesting and checking permissions.\n\n Motivation\n\nWallets are responsible for mediating interactions between untrusted applications and users’ keys through appropriate user consent. Today, wallets always prompt the user for every action. This provides security at the cost of substantial user friction. We believe that a single permissions request can achieve the same level of security with vastly improved UX.\n\nThe pattern of permissions requests (typically using Oauth2) is common around the web, making it a very familiar pattern:\n\nMany web3 applications today begin their sessions with a series of repetitive requests:\n\n Reveal your wallet address to this site.\n Switch to a preferred network.\n Sign a cryptographic challenge.\n Grant a token allowance to our contract.\n Send a transaction to our contract.\n\nMany of these (and possibly all), and many more (like decryption), could be generalized into a set of human-readable permissions prompts on the original sign-in screen, and additional permissions could be requested only as needed:\n\nEach of these permissions could be individually rejected, or even attenuated–adjusted to meet the user’s terms (for example, a sign-in request could have a user-added expiration date, and a token allowance could be adjusted by the user when it is requested).\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\nThis proposal adds two new methods to a wallet’s web3 provider API: wallet_getPermissions and wallet_requestPermissions.\n\n wallet_getPermissions\n\nThe wallet_getPermissions method is used for getting an array of current permissions (empty by default). It takes no parameters and returns an array of Permission objects.\n\n wallet_getPermissions Returns\n\nThe format of the returned permissions MUST be an array of Permission objects, which are defined as follows:\n\ninterface Caveat {\n type: string;\n value: any;\n}\n\ninterface Permission {\n invoker: string;\n parentCapability: string;\n caveats: Caveat[];\n}\n\nThe invoker is a URI used to identify the source of the current dapp (e.g. https://your-site.com/). The term parentCapability refers to the method that is being permitted (e.g. eth_accounts). The caveats array represents the specific restrictions applied to the permitted method. The type of a Caveat is a string, and the value is an arbitrary JSON value. The value of a Caveat is only meaningful in the context of the type of the Caveat.\n\n wallet_requestPermissions\n\nThe wallet_requestPermissions method is used for an application to request additional permissions. It MUST take a single parameter, a PermissionRequest object, and MUST return an array of RequestedPermission objects.\n\n wallet_requestPermissions Parameters\n\nThe wallet_requestPermissions method takes a single parameter, a PermissionRequest object, which is defined as follows:\n\ninterface PermissionRequest {\n [methodName: string]: {\n [caveatName: string]: any;\n };\n}\n\nThe methodName is the name of the method for which the permission is being requested (e.g. eth_accounts). The caveatName is the name of the caveat being applied to the permission (e.g. requiredMethods). The caveat value is the value of the caveat (e.g. [\"signTypedData_v3\"]).\n\nAttempted requests to a restricted method must fail with an error, until a wallet_requestPermissions request is made and accepted by the user.\n\nIf a wallet_requestPermissions request is rejected, it should throw an error with a code value equal to 4001 as per EIP-1193.\n\n wallet_requestPermissions Returns\n\nThe wallet_requestPermissions method returns an array of RequestedPermission objects, which are defined as follows:\n\ninterface RequestedPermission {\n parentCapability: string;\n date?: number;\n}\n\nThe parentCapability is the name of the method for which the permission is being requested (e.g. eth_accounts). The date is the timestamp of the request, in Unix time, and is optional.\n\n Rationale\n\nWhile the current model of getting user consent on a per-action basis has high security, there are huge usability gains to be had bo getting more general user consent which can cover broad categories of usage, which can be expressed in a more human-readable way. This pattern has a variety of benefits to offer different functions within a web3 wallet.\n\nThe requestPermissions method can be expanded to include other options related to the requested permissions, for example, sites could request accounts with specific abilities. For example, a website like an exchange that requires signTypedData_v3 (which is not supported by some hardware wallets), might want to specify that requirement. This would allow wallets to display only compatible accounts, while preserving the user’s privacy and choice regarding how they are storing their keys.\n\n Test Cases\n\n Requesting permissions\n\nThe following example should prompt the user to approve the eth_accounts permission, and return the permission object if approved.\n\nprovider.request({\n method: 'requestPermissions',\n params: [\n {\n 'eth_accounts': {\n requiredMethods: ['signTypedData_v3']\n }\n }\n ]\n});\n\n Getting permissions\n\nThe following example should return the current permissions object.\n\nprovider.request({\n method: 'getPermissions'\n});\n\n Security Considerations\n\n Server-Side Request Forgery (SSRF)\n\nThis consideration is applicable if the favicon of a website is to be displayed.\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 Copyright\n\nCopyright and related rights waived via CC0.\n\n Citation\n Please cite this document as:\n\n Dan Finlay (@danfinlay), Erik Marks (@rekmarks), Gavin John (@Pandapip1), \"EIP-2255: Wallet Permissions System,\" Ethereum Improvement Proposals, no. 2255, August 2019. Available: https://eips.ethereum.org/EIPS/eip-2255.","tokens":1620,"squid":"spider-05","role":"Spec Spider","at":1791343557539,"hash":"5b70b80db2c429c848064be3cdd5763a7270139c"}
{"url":"https://www.metaplex.com/docs/dev-tools/cli/distro","domain":"metaplex.com","title":"MPL-Distro CLI Overview | Metaplex CLI","text":"What This CoversThe complete CLI reference for MPL-Distro authority operations:Create: Initialize a wallet or legacy NFT distribution from flags, JSON, or the wizardFund and recover: Deposit tokens and withdraw leftovers outside the claim windowInspect: Fetch on-chain configuration, status, and Merkle rootSummaryThe mplx distro commands create, fund, inspect, and recover MPL-Distro distributions from the terminal.Tool: Metaplex CLI (mplx) with the distro command groupClient: Requires @metaplex-foundation/mpl-distro 0.4.x against the current programOn-chain work: Create the distribution PDA, deposit tokens, withdraw leftovers, fetch account dataOff-chain work: Merkle roots, proofs, and claims stay in the JavaScript SDKPublished CLI 0.4.3The Distro commands in this documentation require @metaplex-foundation/mpl-distro 0.4.x. The published @metaplex-foundation/cli 0.4.3 still depends on 0.3.x, so mplx distro create fails with BorshIoError. Use a CLI build that depends on @metaplex-foundation/mpl-distro@^0.4.0 (or a newer CLI release when published).Jump to: Prerequisites · General Flow · Command Reference · Merkle Root · Common Errors · FAQ · GlossaryPrerequisitesMPL-Distro CLI commands require a funded identity, an existing original SPL Token mint, and a 32-byte Merkle root.The Metaplex CLI installed and on your PATH, built against @metaplex-foundation/mpl-distro 0.4.xA Solana keypair configured with mplx config (the distribution authority)SOL for rent and transaction feesAn existing SPL token mint (not Token-2022) and a funded associated token account for depositsAn RPC endpoint via mplx config rpcs add or -rCheck the command group:Check CLImplx distro --help\nGeneral FlowAuthority setup uses the CLI. Recipients claim through an app that stores proofs.Allocate — Build the recipient list and generate the Merkle root with prepareDistribution in the JavaScript SDK. Persist every address, amount, nonce, and proof.Create — mplx distro create writes the root, claim window, mint, and access mode on-chain.Deposit — mplx distro deposit moves tokens into the distribution vault. Deposits are allowed at any time.Claim — Recipients (or a relayer) submit distribute / distributeToLegacyNft with the stored proof. The CLI has no claim command.Recover — After endTime (or before startTime), mplx distro withdraw returns unclaimed tokens.See Production Delivery for proof storage and claim pages.Create, fund, inspect, recovermplx distro create \\\n --name \"Community Airdrop\" \\\n --mint <TOKEN_MINT> \\\n --totalClaimants 2 \\\n --startTime \"2026-09-01T00:00:00Z\" \\\n --endTime \"2026-09-08T00:00:00Z\" \\\n --merkleRoot <BASE58_32_BYTE_ROOT>\n\nmplx distro deposit <DISTRIBUTION> --amount 1.0\nmplx distro fetch <DISTRIBUTION>\nmplx distro withdraw <DISTRIBUTION> --amount 0.5\nSave the Distribution Addressdistro create prints the distribution PDA as a base58 public key. Pass that address unchanged to deposit, fetch, and withdraw.Command Referencemplx distro exposes four commands. None of them generate proofs or submit claims.CommandDescriptiondistro createCreate a wallet or legacy NFT distributiondistro depositDeposit SPL tokens into the distribution vaultdistro fetchFetch on-chain distribution detailsdistro withdrawWithdraw unclaimed tokens while the window is inactiveThe CLI does not support AllowedDistributor.Permissioned, updateDistribution, withdrawSubsidy, or claim instructions.Encode the Merkle Root--merkleRoot is the 32-byte allocation root encoded as base58, not a hex string.Generate it with prepareDistribution, then encode the root bytes:Encode a Distro Merkle rootimport { prepareDistribution } from '@metaplex-foundation/mpl-distro'\nimport { publicKey } from '@metaplex-foundation/umi'\nimport { base58 } from '@metaplex-foundation/umi/serializers'\n\nconst { root, proofs, treeHeight } = prepareDistribution([\n { address: publicKey('RecipientWallet111111111111111111111111111'), amount: 100_000n },\n { address: publicKey('RecipientWallet222222222222222222222222222'), amount: 250_000n },\n])\n\nconst merkleRoot = base58.deserialize(root)[0]\nconsole.log(merkleRoot)\nSet --totalClaimants to the number of allocations in that same list. The CLI stores computeTreeHeight(totalClaimants) on-chain; proofs from prepareDistribution must not be longer than that height.Common ErrorsThese are the failures seen most often with mplx distro.ErrorCauseFixBorshIoError / Failed to serialize or deserialize account dataCLI still uses mpl-distro 0.3.x (published 0.4.3)Use a CLI build that depends on @metaplex-foundation/mpl-distro@^0.4.0InvalidPublicKeyErrorThe distribution argument is not a base58 public keyPass the PDA printed by distro createMissing required flagCreate ran without flags, JSON, or --wizardPass --name, --mint, --totalClaimants, --startTime, --endTime, and --merkleRoot, or use --distroConfig / --wizardInsufficient balanceThe identity ATA does not hold enough tokensMint or transfer tokens, then retry depositDistribution not foundWrong PDA or clusterConfirm the address with distro fetch on the same RPCNotesThe CLI is an authority tool around an SDK-built Merkle allocation.The mint must be owned by the original SPL Token program. Token-2022 mints are rejected.Amounts in --amount use the mint's decimals. --basisAmount uses token base units.Deposits are not time-gated. Withdrawals are rejected while startTime <= clusterTime <= endTime.--allowedDistributor accepts permissionless or recipient only.The CLI generates a random seed signer and does not print it. Save the distribution PDA from create output.FAQWhat does mplx distro do?The mplx distro command group creates an MPL-Distro account, deposits and withdraws SPL tokens, and fetches on-chain distribution details. It does not generate Merkle proofs or submit claims.Which CLI version works with the current MPL-Distro program?The on-chain program requires the @metaplex-foundation/mpl-distro 0.4.x client. Published @metaplex-foundation/cli 0.4.3 still depends on 0.3.x and fails distro create with BorshIoError. Use a CLI build that depends on mpl-distro 0.4.0 or newer.Does the CLI submit recipient claims?No. Generate proofs with prepareDistribution and submit distribute or distributeToLegacyNft through the JavaScript SDK or a claim page.When can the authority withdraw tokens?Before the start timestamp or after the end timestamp. Withdrawals are rejected while the claim window is active.GlossaryTermDefinitionDistribution PDAOn-chain account derived from [\"distribution\", mint, seed]. The CLI generates the seed internally.Merkle root32-byte hash of the allocation tree, passed to create as base58.Basis amountToken smallest units (10 ^ decimals per 1.0 token).Claim windowInclusive period from startTime to endTime when claims succeed and withdrawals fail.Allowed distributorWho may submit a valid proof: permissionless or recipient in the CLI.","tokens":1713,"squid":"dotcat","role":"Tooling Spider","at":1791343559627,"hash":"613aea5bfe43ff3910d01cdf89b8d960066e95a7"}
{"url":"https://developers.jup.ag/docs/trigger/deposit","domain":"developers.jup.ag","title":"Vault & Deposit - Jupiter Developers","text":"Every order, limit or DCA, is funded from a single per-wallet vault. Before creating any order you resolve your vault, then craft and sign a deposit transaction. This is the shared setup for both price orders and DCA: the only thing that differs is one field on the deposit. Every request needs the JWT from authentication and the x-api-key header.\n​The vault\nEach wallet has one vault, a Privy-managed custodial account that holds deposits for all your orders. The vault address is resolved from your JWT, so you never pass it into later calls.\n\nThe examples below assume a headers object carrying your API key and the JWT from authentication:\nconst BASE = \"https://api.jup.ag/trigger/v2\";\nconst headers = {\n \"Content-Type\": \"application/json\",\n \"x-api-key\": \"your-api-key\",\n Authorization: `Bearer ${token}`, // token from /trigger/authentication\n};\n\n​Get your vault\nRetrieve your vault, or register one on first use:\nlet vault = await fetch(`${BASE}/vault`, { headers });\nif (!vault.ok) vault = await fetch(`${BASE}/vault/register`, { headers });\nconst { vaultPubkey } = await vault.json();\n// { userPubkey, vaultPubkey, privyVaultId }\n\nThe code above calls GET /vault first and falls back to GET /vault/register on first use. GET /vault/register returns 409 if a vault already exists, so calling GET /vault first avoids that error.\n​Craft a deposit\nPOST /deposit/craft builds an unsigned transaction that moves tokens from your wallet into your vault. Set orderType (and orderSubType for price orders) to match the order you are about to create.\nconst deposit = await fetch(`${BASE}/deposit/craft`, {\n method: \"POST\",\n headers,\n body: JSON.stringify({\n inputMint: \"So11111111111111111111111111111111111111112\", // SOL\n outputMint: \"EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v\", // USDC\n userAddress: walletAddress,\n amount: \"1000000000\", // 1 SOL, in the input token's smallest unit\n orderType: \"price\", // \"price\" or \"dca\"\n orderSubType: \"single\", // price orders only\n }),\n}).then((r) => r.json());\n\n​Deposit parameters\nParameterTypeRequiredDescriptioninputMintstringYesMint of the token to deposit and sell. Native SOL is wrapped automatically. Tokens with transfer-fee or transfer-hook extensions are rejected unless whitelisted.outputMintstringYesMint of the token to buy.userAddressstringYesYour wallet public key. Must match the JWT.amountstringYesTotal amount to deposit, in the input token’s smallest unit (lamports for SOL).orderTypestringYesprice or dca.orderSubTypestringCond.Price orders only: single, oco, or otoco. Omit for dca.\nMatch the deposit to the order you will create:\nDepositCreate it fororderType: \"price\", orderSubType: \"single\"A standalone limit orderorderType: \"price\", orderSubType: \"oco\"A one-cancels-other (TP/SL) pair sharing one depositorderType: \"price\", orderSubType: \"otoco\"A parent trigger that activates an OCO pair. This also provisions an output token accountorderType: \"dca\"A DCA order, time-based or price-conditional. No orderSubType\nFor a price order, both orderType: \"price\" and orderSubType are required; omitting either returns a 4xx.\nThe deposit amount must be worth at least 10 USD. A smaller amount is rejected at this step with 400 \"Order must be at least 10 USD (current value: X USD)\". For DCA, each round must also be worth at least 10 USD, checked when you create the order.\n​Response\n{\n \"transaction\": \"Base64EncodedUnsignedTransaction...\",\n \"requestId\": \"01234567-89ab-cdef-0123-456789abcdef\",\n \"receiverAddress\": \"VaultPublicKey...\",\n \"mint\": \"So11111111111111111111111111111111111111112\",\n \"amount\": \"1000000000\",\n \"tokenDecimals\": 9,\n \"inputTokenAccount\": \"InputTokenAccountPubkey...\"\n}\n\nFor orderSubType: \"otoco\", the response also includes outputTokenAccount for the account used by the conditional OCO pair.\nThe vault address is resolved from your JWT, so you never pass it. You also do not pass inputTokenAccount or outputTokenAccount into the create call; the API stores them against the deposit requestId. The requestId is single-use and is consumed by the create call as depositRequestId.\n​Sign the deposit\nSign the returned transaction client-side. There is no separate submit step: you hand the signed transaction to the create call, which lands the deposit on-chain.\nimport { VersionedTransaction } from \"@solana/web3.js\";\n\nconst tx = VersionedTransaction.deserialize(Buffer.from(deposit.transaction, \"base64\"));\n\n// Browser wallet:\nconst signed = await wallet.signTransaction(tx);\nconst depositSignedTx = Buffer.from(signed.serialize()).toString(\"base64\");\n\n// Or a keypair:\n// tx.sign([keypair]);\n// const depositSignedTx = Buffer.from(tx.serialize()).toString(\"base64\");\n\nCarry two values into the create call:\n\ndeposit.requestId → depositRequestId\ndepositSignedTx → depositSignedTx\n\nThen create the order for your family:\n\nPrice orders: Create Order\nDCA: Create a DCA Order\n\n​Related\nWas this page helpful?","tokens":1221,"squid":"spider-02","role":"Liquidity Spider","at":1791343559674,"hash":"0bb7340a34d088ef10b239923376f8c939b89eae"}
{"url":"https://eips.ethereum.org/EIPS/eip-2309","domain":"eips.ethereum.org","title":"ERC-2309: ERC-721 Consecutive Transfer Extension","text":"🎉 Final\n\n Standards Track: ERC\n\n ERC-2309: ERC-721 Consecutive Transfer Extension\n\n Authors\n Sean Papanikolas (@pizzarob)\n\n Created\n 2019-10-08\n\n Requires\n\n EIP-721\n\n Simple Summary\n\nA standardized event emitted when creating/transferring one, or many non-fungible tokens using consecutive token identifiers.\n\n Abstract\n\nThe optional ERC-721 Consecutive Transfer Extension provides a standardized event which could be emitted during the creation/transfer of one, or many non-fungible tokens. This standard does not set the expectation of how you might create/transfer many tokens it is only concerned with the event emitted after the creation, or transfer of ownership of these tokens. This extension assumes that token identifiers are in consecutive order.\n\n Motivation\n\nThis extension provides even more scalibility of the ERC-721 specification. It is possible to create, transfer, and burn 2^256 non-fungible tokens in one transaction. However, it is not possible to emit that many Transfer events in one transaction. The Transfer event is part of the original specification which states:\n\n This emits when ownership of any NFT changes by any mechanism.\nThis event emits when NFTs are created (from == 0) and destroyed\n(to == 0). Exception: during contract creation, any number of NFTs\nmay be created and assigned without emitting Transfer. At the time of\nany transfer, the approved address for that NFT (if any) is reset to none.\n\nThis allows for the original Transfer event to be emitted for one token at a time, which in turn gives us O(n) time complexity. Minting one billion NFTs can be done in one transaction using efficient data structures, but in order to emit the Transfer event - according to the original spec - one would need a loop with one billion iterations which is bound to run out of gas, or exceed transaction timeout limits. This cannot be accomplished with the current spec. This extension solves that problem.\n\nMany decentralized marketplaces and block explorers utilize the Transfer event as a way to determine which NFTs an address owns. The Consecutive Transfer Extension provides a standard mechanism for these platforms to use to determine ownership of many tokens.\n\n Specification\n\nThe key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL\nNOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and\n“OPTIONAL” in this document are to be interpreted as described in\nRFC 2119.\n\nERC-721 compliant contracts MAY implement this Consecutive Transfer Extension to provide a standard event to be emitted at the time of creation, burn, or transfer of one or many consecutive tokens\n\nThe address executing the transaction MUST own all the tokens within the range of fromTokenId and toTokenId, or MUST be an approved operator to act on the owners behalf.\n\nThe fromTokenId and toTokenId MUST be a consecutive range of tokens IDs.\n\nThe fromTokenId, fromAddress, and toAddress MUST be indexed parameters\n\nThe toTokenId MUST NOT be an indexed parameter\n\nWhen minting/creating tokens, the fromAddress argument MUST be set to 0x0 (i.e. zero address).\n\nWhen burning/destroying tokens, the toAddress argument MUST be set to 0x0 (i.e. zero address).\n\nWhen emitting the ConsecutiveTransfer event the Transfer event MUST NOT be emitted\n\nContracts that implement the ConsecutiveTransfer event MAY still use the original Transfer event, however when emitting the ConsecutiveTransfer event the Transfer event MUST NOT be emitted.\n\n event ConsecutiveTransfer(uint256 indexed fromTokenId, uint256 toTokenId, address indexed fromAddress, address indexed toAddress);\n\n Examples\n\nThe ConsecutiveTransfer event can be used for a single token as well as many tokens:\n\nSingle token creation\n\nemit ConsecutiveTransfer(1, 1, address(0), toAddress);\n\nBatch token creation\n\nemit ConsecutiveTransfer(1, 100000, address(0), toAddress);\n\nBatch token transfer\n\nemit ConsecutiveTransfer(1, 100000, fromAddress, toAddress);\n\nBurn\n\nemit ConsecutiveTransfer(1, 100000, from, address(0));\n\n Rationale\n\nStandardizing the ConsecutiveTransfer event gives decentralized platforms a standard way of determining ownership of large quantities of non-fungible tokens without the need to support a new token standard. There are many ways in which the batch creation and transfer of NFTs can be implemented. The Consecutive Transfer Extension allows contract creators to implement batch creation, transfer, and burn methods however they see fit, but provides a standardized event in which all implementations can use. By specifying a range of consecutive token identifiers we can easily cover the transfer, or creation of 2^(256) tokens and decentralized platforms can react accordingly.\n\nTake this example. I sell magical fruit and have a farm with 10,000 magical fruit trees each with different fruit and 1,000 new trees every few years. I want to turn each tree into a non-fungible token that people can own. Each person that owns one of my non-fungible tree tokens will receive a quarterly percentage of each harvest from that tree. The problem is that I would need to create and transfer each of these tokens individually - which will cost me a lot of time and money and frankly would keep me from doing this.\n\nWith this extension I would be able to mint my initial 10,000 tree tokens in one transaction. I would be able to quickly and cheaply mint my additional 1,000 tree tokens when a new batch is planted. I would then be able to transfer all of the 10,000+ tree tokens to a special smart contract that keeps track of the selling and distribution of funds in one transaction all while adhering to a specified standard.\n\nRationale to have a single event that covers minting, burning, and transferring\n\nThe ConsecutiveTransfer event can be used to cover minting, burning, and transferring events. While there may have been confusion in the beginning adhering to transfer to/from “0” pattern this is mitigated by checking for the ConsecutiveTransfer topic and verifying the emitting contract supports the ERC-721 interface by using the ERC-165 standard.\n\nIndexed event parameters\n\nEvents in Solidity can have up to three indexed parameters which will make it possible to filter for specific values of indexed arguments. This standard sets the fromAddress, toAddress, and fromTokenId as the indexed parameters. The toTokenId can be retrieved from the data part of the log. The reason for this is that more often than not one may be searching for events to learn about the history of ownership for a given address. The fromTokenId can then be retrieved along with the other two indexed parameters for simplicity. Then one only needs to decode the log data which is ensured to be the toTokenId.\n\nRationale to not emit Transfer when ConsecutiveTransfer is also emitted\n\nThis can lead to bugs and unnecessary complex logic for platforms using these events to track token ownership. When transferring a single token it is acceptable to emit the original Transfer event, but the ConsecutiveTransfer event should not be emitted during the same transaction and vice-versa.\n\nComparing 2309 and 1155\n\nAs the NFT market continues to grow so does the need for the ability to scale the smart contracts. Users need to be able to do things like mint a massive amount of tokens at one time, transfer a massive amount of tokens, and be able to track ownership of all these assets. We need to do this in a way that is cost effective and doesn’t fail under the confines of the Ethereum blockchain. As millions of tokens are minted we need contracts with the ability to scale.\n\nERC-1155 was created and added as a standard in 2019 to try to solve these problems, but it falls short when it comes to minting massive amounts of unique tokens in a cost-effective way. With ERC-1155 it’s either going to cost hundreds (or thousands) of dollars or it’s going to run out of gas. ERC-1155 works well when minting many semi-fungible tokens but falls short when minting many unique tokens. Using the 2309 standard you could mint millions of blank NFTs upfront and update the metadata for each one in a cost effective way.\n\n Backwards Compatibility\n\nThis extension was written to allow for the smallest change possible to the original ERC-721 spec while still providing a mechanism to track the creation, transfer, and deletion of a massive amount of tokens. While it is a minimal change the effects on platforms that only use the original Transfer event to index token ownership would be severe. They would not be properly recording token ownership information that could be known by listening for the ConsecutiveTransfer event. For platforms that wish to support the ConsecutiveTransfer event it would be best to support both the original Transfer event and the ConsecutiveTransfer event to track token ownership.\n\n Security Considerations\n\nThere are no security considerations related directly to the implementation of this standard.\n\n Copyright\n\nCopyright and related rights waived via CC0.\n\n Citation\n Please cite this document as:\n\n Sean Papanikolas (@pizzarob), \"ERC-2309: ERC-721 Consecutive Transfer Extension,\" Ethereum Improvement Proposals, no. 2309, October 2019. Available: https://eips.ethereum.org/EIPS/eip-2309.","tokens":2295,"squid":"spider-05","role":"Spec Spider","at":1791343570936,"hash":"ad2ab855d1f9368581e80f75422eff637e79eaa5"}
{"url":"https://www.metaplex.com/docs/dev-tools/cli/genesis","domain":"metaplex.com","title":"Genesis Overview | Metaplex CLI","text":"What This CoversThe complete CLI reference for Genesis token launches:API flow: Create and register launches with a single command via the Genesis APIManual flow: Creating Genesis accounts, configuring buckets, depositing, claiming, and revokingSummaryThe mplx genesis commands let you run a full Genesis token launch from your terminal — creating accounts, configuring buckets, depositing, claiming, and revoking authorities.Tool: Metaplex CLI (mplx) with the genesis command groupBucket types: Launch pool (proportional), presale (fixed-price), unlocked (treasury), bonding curve (constant-product AMM)Quote token (manual flow): Wrapped SOL by default, any SPL token mint address supportedQuote token (API flow): Currently supports SOL or USDC onlyIrreversible actions: finalize and revoke cannot be undoneJump to: Prerequisites · General Flow · Command Reference · Common Errors · FAQ · GlossaryPrerequisitesThe Metaplex CLI installed and on your PATHA Solana keypair file (e.g., ~/.config/solana/id.json)SOL for transaction feesAn RPC endpoint configured via mplx config rpc add or passed with -rCheck your setup:Check CLImplx genesis --help\nGeneral FlowThere are two ways to launch a token with the Genesis CLI:API Flow (Recommended)Use genesis launch create for an all-in-one flow that calls the Genesis API, builds and signs transactions, and registers your launch on the Metaplex platform — all in a single command. Two launch types are available: launchpool (default, 48h deposit window) and bonding-curve (instant trading). Launches created through the API are compatible with metaplex.com and will appear on the platform with a public launch page.Launchpool (default)mplx genesis launch create \\\n --name \"My Token\" --symbol \"MTK\" \\\n --image \"https://gateway.irys.xyz/abc123\" \\\n --tokenAllocation 500000000 \\\n --depositStartTime 2025-03-01T00:00:00Z \\\n --raiseGoal 250 --raydiumLiquidityBps 5000 \\\n --fundsRecipient <WALLET_ADDRESS>\nBonding curve (instant)mplx genesis launch create --launchType bonding-curve \\\n --name \"My Token\" --symbol \"MTK\" \\\n --image \"https://gateway.irys.xyz/abc123\"\nBoth launch types support linking to a registered agent with --agentAsset and --agentSetToken.See Launch (API) for full details.Manual FlowFor full control over every step:Create — genesis create sets up the Genesis account and token mint.Add Buckets — Add one or more buckets to define how tokens are distributed. Use bucket add-launch-pool for proportional distribution, bucket add-presale for fixed-price sales, or bucket add-unlocked for team/treasury allocations.Finalize — genesis finalize locks the configuration. No more buckets can be added after this step.Deposit — Users deposit quote tokens (e.g. wrapped SOL) into buckets during the deposit window using genesis deposit or genesis presale deposit.Withdraw (optional) — Users can withdraw from launch pools during the deposit period with genesis withdraw.Transition (optional) — If a launch pool has end behaviors, call genesis transition after deposits close to forward collected tokens to destination buckets.Claim — After the claim period opens, users claim their base tokens with genesis claim or genesis presale claim. Treasury wallets use genesis claim-unlocked.Revoke (optional) — genesis revoke permanently revokes mint and/or freeze authority on the token.If you used the manual flow and want a public launch page, use genesis launch register to register your genesis account on the Metaplex platform.You can check the state of your launch at any point with genesis fetch and genesis bucket fetch.Command ReferenceCommandDescriptiongenesis launch createCreate and register a launch via the Genesis API (all-in-one)genesis launch registerRegister an existing genesis account on the Metaplex platformgenesis createCreate a new Genesis account and tokengenesis finalizeLock configuration and activate the launchgenesis fetchFetch Genesis account detailsgenesis revokeRevoke mint/freeze authoritygenesis bucket add-launch-poolAdd a launch pool bucketgenesis bucket add-presaleAdd a presale bucketgenesis bucket add-unlockedAdd an unlocked (treasury) bucketgenesis bucket fetchFetch bucket details by typegenesis bucket indexList and index buckets for a Genesis accountgenesis swapBuy or sell tokens on a bonding curvegenesis depositDeposit into a launch poolgenesis withdrawWithdraw from a launch poolgenesis transitionExecute end behaviors after deposit periodgenesis claimClaim tokens from a launch poolgenesis claim-unlockedClaim from an unlocked bucketgenesis presale depositDeposit into a presale bucketgenesis presale claimClaim tokens from a presale bucketNotestotalSupply and allocation are in base units — with 9 decimals, 1000000000000000 = 1,000,000 tokensDeposit and withdraw amounts are in quote token base units (lamports for SOL, where 1 SOL = 1,000,000,000 lamports)If using SOL as the quote token, wrap it first with mplx toolbox sol wrap <amount>Finalization is irreversible — double-check all bucket configurations before running genesis finalizeRun mplx genesis <command> --help for full flag documentation on any commandSee the Genesis documentation for concepts, lifecycle details, and SDK guidesCommon ErrorsErrorCauseFixAccount not foundWrong Genesis address or wrong networkVerify the address and check your RPC endpoint with mplx config rpc listGenesis already finalizedTrying to add buckets after finalizeFinalization is irreversible — create a new Genesis account if the configuration is wrongAllocation exceeds total supplySum of bucket allocations exceeds totalSupplyReduce allocations so they sum to at most totalSupplyDeposit period not activeDepositing outside the deposit windowCheck timestamps with genesis bucket fetch — deposits only work between depositStart and depositEndClaim period not activeClaiming before the claim window opensWait until after claimStart timestampInsufficient fundsNot enough SOL or quote tokens in walletFund your wallet and wrap SOL if needed with mplx toolbox sol wrapNo wrapped SOLDepositing unwrapped SOLWrap SOL first: mplx toolbox sol wrap <amount>FAQWhat is the mplx genesis command? The mplx genesis command group lets you run a full Genesis token launch from your terminal — creating accounts, configuring buckets, depositing, claiming, and revoking authorities.What are the different bucket types in Genesis? Genesis has four bucket types: launch pool (proportional distribution based on deposits), presale (fixed-price token sale), unlocked (team/treasury allocations that can claim directly), and bonding curve (constant-product AMM with instant trading).Do I need to wrap SOL before depositing? Yes. If using SOL as the quote token, wrap it first with mplx toolbox sol wrap <amount> before depositing into any bucket.Can I undo finalization? No. Finalization is irreversible. Once finalized, no more buckets can be added and the configuration is locked. Double-check everything before running genesis finalize.How are token amounts specified? All amounts are in base units. With 9 decimals, 1,000,000 tokens = 1000000000000000 base units. Deposit amounts use quote token base units (lamports for SOL, where 1 SOL = 1,000,000,000 lamports).Can I have multiple buckets of the same type? Yes. Use the --bucketIndex flag to specify different indices for each bucket of the same type.GlossaryTermDefinitionGenesis AccountThe PDA that manages an entire token launch — holds configuration, bucket references, and mint authorityBucketA distribution channel within a Genesis launch that defines how a portion of tokens is allocated and distributedLaunch PoolBucket type that collects deposits during a window and distributes tokens proportionally to depositorsPresaleBucket type that sells tokens at a fixed price determined by quoteCap / allocationUnlocked BucketBucket type for team/treasury — the designated recipient can claim tokens or forwarded quote tokens directlyQuote TokenThe token deposited by users (usually wrapped SOL) in exchange for base tokensBase TokenThe token being launched and distributed to depositorsBase UnitsThe smallest denomination of a token — with 9 decimals, 1 token = 1,000,000,000 base unitsEnd BehaviorRules that forward collected quote tokens from a launch pool to destination buckets after the deposit periodFinalizeIrreversible action that locks the Genesis configuration and activates the launchClaim ScheduleVesting rules that control how tokens are released over time after the claim period opensAllocationThe amount of base tokens assigned to a specific bucket, specified in base units","tokens":2141,"squid":"dotcat","role":"Tooling Spider","at":1791343581576,"hash":"9fd00eb27bc254168cd60b24042382f2e62726a9"}
{"url":"https://developers.jup.ag/docs/trigger/dca-history","domain":"developers.jup.ag","title":"Track a DCA Order - Jupiter Developers","text":"Track a DCA order’s schedule, progress, and fill history through the order-history endpoints. Every request needs the JWT from authentication.\n​Tracking an order\nList your DCA orders, or fetch one by ID. Both require the JWT.\nconst list = await fetch(`${BASE}/orders/history/dca?state=active&limit=20`, { headers }).then((r) => r.json());\nconst detail = await fetch(`${BASE}/orders/history/dca/${orderId}`, { headers }).then((r) => r.json());\n\nThe per-order detail path requires the dca segment: GET /trigger/v2/orders/history/dca/{id}.\nList query parameters: state (active or past), mint (matches input or output), limit (1–100, default 20), offset, sort (updated_at, created_at, next_fill_at), and dir (asc / desc).\nEach order reports its schedule, progress, and event history:\nFieldDescriptioninputAmountInitial / inputAmountRemainingTotal deposited, and amount still in the vault.amountPerRoundInput swapped each round (the last round absorbs any dust).outputAmountTotal / inputAmountUsedOutput received and input consumed across filled rounds.numberOfRounds / roundsFilled / fillPercentTotal rounds, rounds completed, and progress from 0 to 1.nextFillAt / lastFillAtNext scheduled round, and the most recent fill.state / displayStateRaw and human-friendly status (see below).jlEnabled / jlYieldUsdWhether Earn While You Wait is on, and the yield accrued so far in USD (null when not JL-enabled or a required price is uncached).eventsOrdered history of deposit, fill, withdrawal, and cancelled events.\nFull order response{\n \"id\": \"019f02b5-0400-72cc-8943-007c4310a3de\",\n \"requestId\": \"2ea435dc-1068-466c-8fff-c9ad74d076e8\",\n \"userPubkey\": \"8gs8rXavMQRqoAoMhCfo79r2wndgSn93FLSWErdHp82n\",\n \"vaultPubkey\": \"66xK9AE6oFpGAyn9eCWE3LtYwUZKkeUxbfjFSNmFnkBo\",\n \"inputMint\": \"EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v\",\n \"outputMint\": \"So11111111111111111111111111111111111111112\",\n \"inputAmountInitial\": \"20000000\",\n \"inputAmountRemaining\": \"20000000\",\n \"amountPerRound\": \"10000000\",\n \"outputAmountTotal\": \"0\",\n \"inputAmountUsed\": \"0\",\n \"orderType\": \"time_based\",\n \"minPriceUsd\": null,\n \"maxPriceUsd\": null,\n \"triggerMint\": null,\n \"retryWindowSeconds\": 30,\n \"jlEnabled\": false,\n \"jlYieldUsd\": null,\n \"numberOfRounds\": 2,\n \"intervalSeconds\": 60,\n \"beginFillAt\": \"2026-06-26T07:53:57.767Z\",\n \"nextFillAt\": \"2026-06-26T07:53:57.767Z\",\n \"lastFillAt\": null,\n \"roundsFilled\": 0,\n \"fillPercent\": 0,\n \"state\": \"active\",\n \"displayState\": \"active\",\n \"createdAt\": \"2026-06-26T06:54:05.327Z\",\n \"updatedAt\": \"2026-06-26T06:54:05.924Z\",\n \"events\": [\n {\n \"type\": \"deposit\",\n \"timestamp\": \"2026-06-26T06:54:05.924Z\",\n \"txSignature\": \"4R18eTrkDvmZFPq87pznBPpVCpk1G2FQapWVks4ELLNYxAQZdwoDaxnnAHN2ZvBFrRvbnJSAPTnhutgj8ZzLFwgV\",\n \"inputAmount\": \"20000000\",\n \"state\": \"success\"\n }\n ]\n}\nReconcile against state and events, not inputAmountRemaining, which is not zeroed after a cancellation.\n​Order states\nThe response carries two status fields: state is the raw internal status, and displayState is the human-friendly version most integrations show.\nstatedisplayStateMeaningdepositingpendingDeposit in progress.activeactiveScheduled and waiting for the next round.executingexecutingA round is currently filling.withdrawingpending_withdrawA cancellation is in progress.completedcompletedAll rounds filled.cancelledcancelledCancelled by you.deposit_failedfailedThe deposit failed on-chain.\nFor how these states fit the end-to-end flow, see the Integration Flow.\n​How rounds fill\nWhen a round comes due, the keeper swaps amountPerRound and delivers the output straight to your wallet, and pays the swap’s transaction fee itself. You never withdraw filled output manually; only the unfilled remainder is returned, and only when you cancel. A round that is due now typically fills within a few seconds.\nEach fill appends an event and advances roundsFilled, outputAmountTotal, inputAmountUsed, and nextFillAt:\n{\n \"type\": \"fill\",\n \"timestamp\": \"2026-06-26T18:42:11.469Z\",\n \"txSignature\": \"HuNMpjFkTjVrCYMN6gTPWV9ay3GSxTxM7sZj4WNzjvzQoe4J5CR71MnTpuMKH9rtkDoDCTWu6rYRM12oR9cpbb4\",\n \"roundNumber\": 1,\n \"inputAmount\": \"10000000\",\n \"outputAmount\": \"137589159\",\n \"state\": \"success\"\n}\n\nA price_conditional round that is out of band does not fill: the order stays active with roundsFilled unchanged until the price re-enters the range, then resumes on the next interval.\nIf a round cannot execute (for example, not enough liquidity within slippage), the keeper retries it within a window of min(max(30, intervalSeconds / 2), 7200) seconds, then reschedules it to the next interval. roundsFilled stays the same and nextFillAt advances. A round’s fill event carries a state of success, failed, rescheduled, or pending.\n​Fees and slippage\nEach round executes as a standard Jupiter swap, run by the keeper. Two things follow from that:\n\nSlippage is automatic and not configurable. DCA orders have no slippage parameter. The keeper sets slippage per round from live market conditions at fill time; you cannot set or cap it.\nThe swap fee is included in the output. Any swap fee is already reflected in the outputAmount you receive each round. Trigger V2 does not support integrator fees.\n\nThe keeper pays the network and priority fees for each fill, and the output settles directly to your wallet.\n​Related\nWas this page helpful?","tokens":1321,"squid":"spider-02","role":"Liquidity Spider","at":1791343581605,"hash":"2231ed9947fd1b358895072aafae089162a4b076"}
{"url":"https://eips.ethereum.org/EIPS/eip-2384","domain":"eips.ethereum.org","title":"EIP-2384: Muir Glacier Difficulty Bomb Delay","text":"🎉 Final\n\n Standards Track: Core\n\n EIP-2384: Muir Glacier Difficulty Bomb Delay\n\n Authors\n Eric Conner (@econoar)\n\n Created\n 2019-11-20\n\n Simple Summary\n\nThe average block times are increasing due to the difficulty bomb (also known as the “ice age”) and slowly accelerating. This EIP proposes to delay the difficulty bomb for another 4,000,000 blocks (~611 days).\n\n Abstract\n\nStarting with MUIR_GLACIER_FORK_BLKNUM the client will calculate the difficulty based on a fake block number suggesting to the client that the difficulty bomb is adjusting 9 million blocks later than the Homestead fork, which is also 7 million blocks later than the Byzantium fork and 4 million blocks later than the Constantinople fork.\n\n Motivation\n\nThe difficulty bomb started to become noticeable again on October 5th 2019 at block 8,600,000. Block times have been around 13.1s on average and now as of block 8,900,000 are around 14.3s. This will start to accelerate exponentially every 100,000 blocks. Estimating the added impact from the difficulty bomb on block times shows that we will see 20s block times near the end of December 2019 and 30s+ block times starting February 2020. This will start making the chain bloated and more costly to use. It’s best to delay the difficulty bomb again to around the time of expected launch of the Eth2 finality gadget.\n\n Specification\n\n Relax Difficulty with Fake Block Number\n\nFor the purposes of calc_difficulty, simply replace the use of block.number, as used in the exponential ice age component, with the formula:\n\nfake_block_number = max(0, block.number - 9_000_000) if block.number >= MUIR_GLACIER_FORK_BLKNUM else block.number\n\n Rationale\n\nThis will delay the ice age by 52 million seconds (approximately 611 days), so the chain would be back at 20 second block times around July 2021. It’s important to note this pushes the ice age 4,000,000 blocks from ~block 8,800,000 NOT from when this EIP is activated in a fork.\n\n Backwards Compatibility\n\nThis EIP is not forward compatible and introduces backwards incompatibilities in the difficulty calculation. Therefore, it should be included in a scheduled hardfork at a certain block number. It’s suggested to include this EIP shortly after the Istanbul fork.\n\n Test Cases\n\nTest cases shall be created once the specification is to be accepted by the developers or implemented by the clients.\n\n Implementation\n\nThe implementation in it’s logic does not differ from EIP-649 or EIP-1234; an implementation for Parity-Ethereum is available in parity-ethereum#9187.\n\n Copyright\n\nCopyright and related rights waived via CC0.\n\n Citation\n Please cite this document as:\n\n Eric Conner (@econoar), \"EIP-2384: Muir Glacier Difficulty Bomb Delay,\" Ethereum Improvement Proposals, no. 2384, November 2019. Available: https://eips.ethereum.org/EIPS/eip-2384.","tokens":705,"squid":"spider-05","role":"Spec Spider","at":1791343593071,"hash":"8cfab29a1f63cf61179a2da0c38891b1276953cc"}
{"url":"https://developers.jup.ag/docs/trigger/create-order","domain":"developers.jup.ag","title":"Create Order (Trigger) - Jupiter Developers","text":"Price orders execute a swap when a token’s USD price crosses a threshold: limit orders, take-profit, and stop-loss. This page covers the create call and its order types. The vault and deposit setup is shared with DCA: the example below includes it inline, and Vault & Deposit is the full reference.\nFor a working reference of the full order creation flow, see how jup.ag handles it. The frontend implements the same API with validation, error handling, and UX patterns you can use as a guide.\n​Order types\nSet orderType on the create call to choose the variant.\nTypeBehavioursingleTriggers a swap when triggerMint’s USD price crosses above or below a target. Standard limit order, stop-loss, or trailing stop loss.ocoA take-profit and stop-loss pair sharing one deposit. When one side fills, the other cancels automatically.otocoA parent trigger that executes first, then activates a TP/SL (OCO) pair on the output.\nOn the create call, orderType is the variant (single, oco, otoco). That is different from the deposit’s orderType (price or dca). Craft the deposit with orderType: \"price\" and an orderSubType that matches the create orderType.\n​Quick start\nCreating a price order is four calls: authenticate, get your vault, craft and sign the deposit, then submit the order.\nPrerequisitesInstall the signing dependencies:npm install @solana/web3.js bs58 tweetnacl\nYou also need a Jupiter API key and a funded wallet. The example below loads the wallet from BS58_PRIVATE_KEY and the key from JUPITER_API_KEY in your .env. For the browser-wallet (signMessage / signTransaction) version of authentication and signing, see Authentication and Vault & Deposit.Never commit private keys. Use environment variables for testing and a proper key-management solution in production.\nimport { Keypair, VersionedTransaction } from \"@solana/web3.js\";\nimport bs58 from \"bs58\";\nimport nacl from \"tweetnacl\";\n\nconst BASE = \"https://api.jup.ag/trigger/v2\";\nconst API_KEY = process.env.JUPITER_API_KEY!;\nconst SOL = \"So11111111111111111111111111111111111111112\";\nconst USDC = \"EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v\";\n\nconst wallet = Keypair.fromSecretKey(bs58.decode(process.env.BS58_PRIVATE_KEY!));\nconst owner = wallet.publicKey.toBase58();\n\n// 1. Authenticate: sign the challenge to get a 24h JWT (see /trigger/authentication)\nasync function authenticate(): Promise<string> {\n const { challenge } = await fetch(`${BASE}/auth/challenge`, {\n method: \"POST\",\n headers: { \"Content-Type\": \"application/json\", \"x-api-key\": API_KEY },\n body: JSON.stringify({ walletPubkey: owner, type: \"message\" }),\n }).then((r) => r.json());\n\n const signature = nacl.sign.detached(new TextEncoder().encode(challenge), wallet.secretKey);\n const { token } = await fetch(`${BASE}/auth/verify`, {\n method: \"POST\",\n headers: { \"Content-Type\": \"application/json\", \"x-api-key\": API_KEY },\n body: JSON.stringify({ type: \"message\", walletPubkey: owner, signature: bs58.encode(signature) }),\n }).then((r) => r.json());\n return token;\n}\n\nasync function createLimitOrder() {\n const token = await authenticate();\n const headers = { \"Content-Type\": \"application/json\", \"x-api-key\": API_KEY, Authorization: `Bearer ${token}` };\n\n // 2. Get your vault, registering one on first use\n let vault = await fetch(`${BASE}/vault`, { headers });\n if (!vault.ok) vault = await fetch(`${BASE}/vault/register`, { headers });\n if (!vault.ok) throw new Error(`vault failed: ${vault.status}`);\n\n // 3. Craft the deposit (orderType: \"price\", orderSubType matches the create orderType below)\n const deposit = await fetch(`${BASE}/deposit/craft`, {\n method: \"POST\",\n headers,\n body: JSON.stringify({\n inputMint: SOL,\n outputMint: USDC,\n userAddress: owner,\n amount: \"1000000000\", // 1 SOL\n orderType: \"price\",\n orderSubType: \"single\",\n }),\n }).then((r) => r.json());\n if (!deposit.requestId) throw new Error(`craft failed: ${JSON.stringify(deposit)}`);\n\n // 4. Sign the deposit and submit the order\n const tx = VersionedTransaction.deserialize(Buffer.from(deposit.transaction, \"base64\"));\n tx.sign([wallet]);\n const depositSignedTx = Buffer.from(tx.serialize()).toString(\"base64\");\n\n const order = await fetch(`${BASE}/orders/price`, {\n method: \"POST\",\n headers,\n body: JSON.stringify({\n orderType: \"single\",\n depositRequestId: deposit.requestId,\n depositSignedTx,\n userPubkey: owner,\n inputMint: SOL,\n outputMint: USDC,\n inputAmount: \"1000000000\",\n triggerMint: SOL,\n triggerCondition: \"above\", // fill when SOL climbs above the target\n triggerPriceUsd: 200,\n slippageBps: 100, // 1%\n expiresAt: Date.now() + 7 * 24 * 60 * 60 * 1000, // 7 days\n }),\n }).then((r) => r.json());\n if (!order.id) throw new Error(`create failed: ${JSON.stringify(order)}`);\n\n console.log(`Order ${order.id}, deposit tx https://solscan.io/tx/${order.txSignature}`);\n return order.id as string;\n}\n\ncreateLimitOrder().catch(console.error);\n\nThe deposit lands on-chain during the create call. The response is { id, txSignature, depositConfirmed }: id is the order identifier you use to track, update, or cancel it, txSignature is the on-chain deposit signature, and depositConfirmed is true once the deposit has landed and the order is active:\n{\n \"id\": \"order-uuid\",\n \"txSignature\": \"5eykt4UsFv8P8NJdTREpY1vzqKqZKvdpKuc147dw2N9d...\",\n \"depositConfirmed\": true\n}\n\nThe vault address is resolved from your JWT, so you never pass it. The deposit requestId is single-use and is consumed by the create call as depositRequestId.\n​Other order types\nThe OCO and OTOCO bodies replace step 4’s create call. Each needs its deposit crafted with the matching orderSubType.\n​OCO (One-Cancels-Other)\nAn OCO order creates a take-profit and stop-loss pair sharing one deposit. When one side fills, the other cancels automatically.\n// deposit crafted with orderSubType: \"oco\"\nconst order = await fetch(`${BASE}/orders/price`, {\n method: \"POST\",\n headers,\n body: JSON.stringify({\n orderType: \"oco\",\n depositRequestId: deposit.requestId,\n depositSignedTx,\n userPubkey: owner,\n inputMint: SOL,\n outputMint: USDC,\n inputAmount: \"1000000000\",\n triggerMint: SOL,\n tpPriceUsd: 250, // take profit\n slPriceUsd: 150, // stop loss\n tpSlippageBps: 100,\n slSlippageBps: 100,\n expiresAt: Date.now() + 7 * 24 * 60 * 60 * 1000,\n }),\n}).then((r) => r.json());\n\nThe take-profit price must be greater than the stop-loss price.\n​OTOCO (One-Triggers-One-Cancels-Other)\nAn OTOCO order has a parent trigger that executes first. Once filled, it automatically activates a TP/SL pair (OCO) on the output tokens.\n// deposit crafted with orderSubType: \"otoco\"\nconst order = await fetch(`${BASE}/orders/price`, {\n method: \"POST\",\n headers,\n body: JSON.stringify({\n orderType: \"otoco\",\n depositRequestId: deposit.requestId,\n depositSignedTx,\n userPubkey: owner,\n inputMint: USDC,\n outputMint: SOL,\n inputAmount: \"200000000\", // 200 USDC\n triggerMint: SOL,\n triggerCondition: \"below\",\n triggerPriceUsd: 180, // entry: buy SOL when it drops to \\$180\n tpPriceUsd: 220, // take profit at \\$220\n slPriceUsd: 160, // stop loss at \\$160\n slippageBps: 100, // parent order slippage\n tpSlippageBps: 100,\n slSlippageBps: 100,\n expiresAt: Date.now() + 30 * 24 * 60 * 60 * 1000, // 30 days\n }),\n}).then((r) => r.json());\n\n​Trailing stop loss\nA trailing stop loss is a single order that tracks the market instead of using a fixed price. Set trailingBps instead of triggerPriceUsd: the trigger follows the price in your favour and holds when the price reverses. Provide exactly one of triggerPriceUsd (static) or trailingBps (trailing).\ntrailingBps is the trail distance in basis points, from 50 to 9000 (0.5% to 90%). triggerCondition sets the direction:\ntriggerConditionUsetriggerMintTrigger pricebelowSell-below (stop loss): protect a position, sell if the price fallsinputMinthighWatermark × (1 − trailingBps/10000)aboveBuy-above: enter as the price rises off a lowoutputMintlowWatermark × (1 + trailingBps/10000)\nAt create, the API seeds the trigger from the current market price. The keeper then tracks a running watermark (the high for below, the low for above) and rewrites the trigger as the watermark moves in your favour. The trigger never moves against you. Watermark updates are batched, not per price tick.\nCraft the deposit with orderSubType: \"single\", then submit a single order with trailingBps and no triggerPriceUsd:\n// deposit crafted with orderSubType: \"single\"; hold SOL, sell if it falls 10% from its peak\nconst order = await fetch(`${BASE}/orders/price`, {\n method: \"POST\",\n headers,\n body: JSON.stringify({\n orderType: \"single\",\n depositRequestId: deposit.requestId,\n depositSignedTx,\n userPubkey: owner,\n inputMint: SOL, // selling the asset you hold\n outputMint: USDC,\n inputAmount: \"200000000\", // 0.2 SOL\n triggerMint: SOL, // \"below\" requires triggerMint === inputMint\n triggerCondition: \"below\",\n trailingBps: 1000, // trail 10% below the peak; no triggerPriceUsd\n slippageBps: 100,\n expiresAt: Date.now() + 30 * 24 * 60 * 60 * 1000,\n }),\n}).then((r) => r.json());\n\nslippageBps is the execution buffer beneath the trigger, the same as a static order. Track the live trigger and watermark with Order History (triggerPriceUsd, trailingBps, highWatermark/lowWatermark), and change the trail distance later by updating trailingBps.\nTrailing rules: provide exactly one of triggerPriceUsd or trailingBps (else 400 \"exactly one of triggerPriceUsd or trailingBps must be set\"); trailingBps must be 50–9000; and triggerMint must be the inputMint for below or the outputMint for above.\n​Order parameters reference\n​Common fields (all order types)\nParameterTypeRequiredDescriptionorderTypestringYessingle, oco, or otocodepositRequestIdstringYesThe requestId from the deposit craft responsedepositSignedTxstringYesBase64-encoded signed deposit transactionuserPubkeystringYesYour wallet public key. Must match the JWTinputMintstringYesMint address of the token to sellinputAmountstringYesAmount in smallest unit (lamports, etc.)outputMintstringYesMint address of the token to buytriggerMintstringYesMint address to monitor for the price triggerexpiresAtnumberYesExpiration timestamp in milliseconds\n​Single order fields\nParameterTypeRequiredDescriptiontriggerConditionstringYesabove or belowtriggerPriceUsdnumberCond.USD price that triggers execution. Required unless trailingBps is set.trailingBpsnumberCond.Trail distance in basis points (50–9000) for a trailing stop loss. Set instead of triggerPriceUsd.slippageBpsnumberNoSlippage tolerance in basis points (0-10000)\n​OCO order fields\nParameterTypeRequiredDescriptiontpPriceUsdnumberYesTake-profit trigger price (USD)slPriceUsdnumberYesStop-loss trigger price (USD)tpSlippageBpsnumberNoTake-profit slippage (basis points)slSlippageBpsnumberNoStop-loss slippage (basis points)\n​OTOCO order fields\nParameterTypeRequiredDescriptiontriggerConditionstringYesParent trigger: above or belowtriggerPriceUsdnumberYesParent trigger price (USD)tpPriceUsdnumberYesTake-profit price after parent fillsslPriceUsdnumberYesStop-loss price after parent fillsslippageBpsnumberNoParent order slippagetpSlippageBpsnumberNoTake-profit slippageslSlippageBpsnumberNoStop-loss slippage\n​Default slippage\nIf slippage is not specified, defaults vary by order type and trigger condition:\nOrder sideDefault slippageTake-profit / buy below (buying into strength)Auto slippage via RTSE (Real-Time Slippage Estimator)Stop-loss / buy above (selling into weakness)20% (2000 bps)\nStop-loss orders use a higher default because execution certainty is more important than price precision when cutting losses.\n​Validation rules\n\nMinimum order size: 10 USD\nInput and output mints must be different\nSlippage: 0-10000 basis points\nexpiresAt is required and must be a future timestamp (milliseconds)\nOCO/OTOCO: take-profit price must be greater than stop-loss price\nTrailing: set exactly one of triggerPriceUsd or trailingBps; trailingBps must be 50–9000; triggerMint must be inputMint for below or outputMint for above\n\nUnlike V1 where orders could exist indefinitely, V2 requires an expiration on every order. Adding a TTL allows the system to prune orders that are unlikely to fill, improving execution quality for active orders. For long-lived orders, use a far-future timestamp (e.g. 30 days).\n​Related\nWas this page helpful?","tokens":3052,"squid":"spider-02","role":"Liquidity Spider","at":1791343607937,"hash":"836dc2c788e0159eedcdc9250fa1bbeed25e2c82"}
{"url":"https://developers.jup.ag/docs/trigger/order-history","domain":"developers.jup.ag","title":"Order History (Trigger) - Jupiter Developers","text":"​Get Order History\nRetrieve your orders with optional filters for state, mint, and pagination.\nconst historyResponse = await fetch(\n 'https://api.jup.ag/trigger/v2/orders/history?state=active&limit=20&offset=0',\n {\n headers: {\n 'x-api-key': 'your-api-key',\n 'Authorization': `Bearer ${token}`,\n },\n }\n);\n\nconst history = await historyResponse.json();\n\n​Query Parameters\nParameterTypeDefaultDescriptionstatestring—active (open orders) or past (filled/cancelled/expired)mintstring—Filter by token mint address (input or output)limitnumber20Results per page (1-100)offsetnumber0Number of results to skipsortstringupdated_atSort field: updated_at, created_at, expires_atdirstringdescSort direction: asc or desc\n​Response\n{\n \"orders\": [\n {\n \"id\": \"order-uuid\",\n \"orderType\": \"single\",\n \"orderState\": \"open\",\n \"rawState\": \"open\",\n \"userPubkey\": \"YourWalletPublicKey...\",\n \"privyWalletPubkey\": \"VaultPublicKey...\",\n \"inputMint\": \"So11111111111111111111111111111111111111112\",\n \"initialInputAmount\": \"1000000000\",\n \"remainingInputAmount\": \"1000000000\",\n \"outputMint\": \"EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v\",\n \"triggerMint\": \"So11111111111111111111111111111111111111112\",\n \"triggerCondition\": \"above\",\n \"triggerPriceUsd\": 200.00,\n \"slippageBps\": 100,\n \"expiresAt\": 1704067200000,\n \"createdAt\": 1704000000000,\n \"updatedAt\": 1704000000000,\n \"events\": [\n {\n \"type\": \"deposit\",\n \"timestamp\": 1704000000000,\n \"txSignature\": \"5eykt4UsFv8P8NJdTREpY1vzqKqZKvdpKuc147dw2N9d...\",\n \"mint\": \"So11111111111111111111111111111111111111112\",\n \"amount\": \"1000000000\",\n \"state\": \"success\"\n }\n ]\n }\n ],\n \"pagination\": {\n \"total\": 50,\n \"limit\": 20,\n \"offset\": 0\n }\n}\n\ninitialInputAmount is the inputAmount you submitted on create; remainingInputAmount is the amount not yet filled.\n​Additional Fields for Filled Orders\nOrders that have been fully or partially filled include extra fields:\nFieldDescriptiontriggeredAtTimestamp when the price condition was metoutputAmountTotal output tokens receivedinputUsedTotal input tokens consumedfillPercentFill ratio (1.0 = fully filled)\n​Trailing Stop Loss Fields\nSingle orders created with trailingBps (a trailing stop loss) report these extra fields. triggerPriceUsd holds the current trailing trigger, which the keeper rewrites as the watermark moves.\nFieldDescriptiontrailingBpsTrail distance in basis points. null for non-trailing orders.highWatermarkHighest observed trigger-mint price (sell-below trailing). null otherwise.lowWatermarkLowest observed trigger-mint price (buy-above trailing). null otherwise.\n​Execution Attempts\nOrder history includes execution attempts for each order. When an order fails to execute (due to slippage, quote generation failure, or other reasons), the attempt is recorded in the history. The reason for failure is not included in the response.\nUsers can adjust slippage settings via the update endpoint if execution keeps failing due to slippage.\n​Event Types\nEach order includes an events array tracking its lifecycle:\nEvent TypeDescriptiondepositTokens deposited into vaultfillOrder executed (full or partial)withdrawalTokens withdrawn back to walletcancelledOrder cancelled by userexpiredOrder expired\nEach event includes type, timestamp, and state. Events that involve token movement (deposit, fill, withdrawal) also include:\nFieldDescriptiontxSignatureOn-chain transaction signaturemintToken mint addressamountToken amount (in smallest unit)\nFill events include additional fields:\nFieldDescriptionoutputMintOutput token mint addressoutputAmountOutput amount receivedorderContextSemantic order type: take_profit, stop_loss, buy_above, or buy_below\n​Order States\nOrders follow a state machine from creation to completion. The orderState field provides a human-friendly state, while rawState shows the exact internal state. For a high-level view of how an order moves through these states, including OCO and OTOCO branching, see the Integration Flow page.\n​Display States\nStateDescriptionpendingDeposit is being processedopenActive and waiting for price triggerexecutingPrice condition met, swap in progressfilledOrder completed successfullypending_withdrawCancellation initiated, awaiting signed withdrawalcancelledUser cancelled the orderexpiredOrder expired before executionfailedExecution failed\n​Raw States\nThe rawState field exposes the internal processing state. Multiple raw states map to each display state:\norderStaterawStateMeaningpendingpending_depositDeposit transaction not yet submittedpendingdepositingDeposit transaction submitted, awaiting confirmationopenopenActive and monitoring priceexecutingready_executePrice condition met, preparing swapexecutingready_expireOrder expiry detected, processingexecutingexecutingSwap transaction in flightexecutingexecute_successSwap landed, validating outputexecutingexecute_failedSwap attempt failed, may retryexecutingready_withdraw_outputOutput ready to withdraw to walletexecutingwithdrawingWithdrawal transaction in flightfilledfill_successOrder fully filled and output withdrawnexecutingpartial_fill_successOrder partially filled, may continue fillingpending_withdrawready_to_cancelCancellation initiated, awaiting signed withdrawalcancelledcancelledUser cancelled the ordercancelledoco_cancelledAutomatically cancelled because the other side of an OCO pair filledexpiredexpiredOrder expired before executionfaileddeposit_failedDeposit transaction failed on-chain (e.g. insufficient balance)failedwithdraw_failedOutput withdrawal failed after executionfailedfill_failedFill validation failed after execution\n​State Flow\n\nFor OCO orders, when one side fills, the other transitions to cancelled automatically (displayed as oco_cancelled in the raw state).\nFor OTOCO orders, the child OCO pair only activates after the parent order reaches filled. If the parent expires or fails, the children are never created.Was this page helpful?","tokens":1463,"squid":"spider-02","role":"Liquidity Spider","at":1791343619803,"hash":"4e0c0d8c520704d3bf76ed92a92ab488f09c3db1"}
{"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":"spider-08","role":"Oracle Spider","at":1791343645187,"hash":"9f33e6e11d7737651ddb50525eab096ad32ea2e4"}
{"url":"https://docs.phantom.com/phantom-cli/commands","domain":"docs.phantom.com","title":"Commands - Phantom developer documentation","text":"Run phantom --help or phantom <command> --help for inline documentation.\n​Authentication\nphantom login\n\nAuthenticate with Phantom via browser (Google, Apple, or Phantom extension). Use this to log in for the first time, switch accounts, or refresh an expired session.\n\n​Wallet\nphantom wallet status # Check session status (no API call)\nphantom wallet addresses # Get all wallet addresses (Solana, EVM, Bitcoin, Sui)\nphantom wallet balances # Get token balances with USD prices across all chains\nphantom wallet rebalance # Rebalance portfolio to a target allocation\n\nSui support has been deprecated.\n\n​Tokens & Swaps\nphantom buy # Swap tokens on Solana, EVM, or cross-chain\nphantom transfer # Transfer native tokens or SPL/ERC-20 tokens\nphantom simulate # Simulate a transaction and preview asset changes\nphantom pay # Pay for API access using tokens\n\n​phantom buy\nSwap tokens on Solana, across EVM chains, or between chains (including Hyperliquid):\n# Swap SOL to USDC on Solana\nphantom buy --sellTokenIsNative --buyTokenMint EPjFWdd5... --amount 0.1 --amountUnit ui --execute\n\n# Bridge USDC from Solana to Base\nphantom buy --sellTokenMint EPjFWdd5... --buyChainId eip155:8453 --buyTokenIsNative \\\n --amount 10 --amountUnit ui --execute\n\n# Deposit to Hyperliquid (bridge SOL into HL spot)\nphantom buy --sellTokenIsNative --buyChainId hypercore:mainnet \\\n --buyTokenMint 0x00000000000000000000000000000000 --amount 0.05 --amountUnit ui --execute\n\nOmit --execute to get a quote preview only.\n\n​Solana\nphantom solana send # Sign and broadcast a base64-encoded Solana transaction\nphantom solana sign # Sign a UTF-8 message (returns base58 signature)\n\n​EVM\nphantom evm send # Sign and broadcast an EVM transaction\nphantom evm sign # Sign an EVM personal message (EIP-191)\nphantom evm sign-typed # Sign EVM typed data (EIP-712)\nphantom evm allowance # Get ERC-20 token allowance for a spender address\n\n​Perpetuals (Hyperliquid)\nFull perpetuals documentation: PERPS guide.\nphantom perps markets # List available perpetual markets with prices\nphantom perps account # Get account balance, available margin, and withdrawable amount\nphantom perps positions # Get all open positions\nphantom perps orders # Get all open orders\nphantom perps history # Get recent trade history\n\nphantom perps open # Open a long or short position (market or limit)\nphantom perps close # Close an open position\nphantom perps cancel # Cancel an open order\nphantom perps leverage # Update leverage for a market\n\nphantom perps deposit # Bridge tokens from external chain into Hyperliquid spot\nphantom perps transfer # Move USDC from Hyperliquid spot into perps account\nphantom perps withdraw # Bridge USDC from perps account to an external chain\nphantom perps withdraw-hl-spot # Bridge USDC from Hyperliquid spot to an external chain\n\n​Perps workflow\nFund and trade:\n# 1. Bridge SOL into Hyperliquid spot\nphantom perps deposit --sourceChainId solana:mainnet --amount 0.1 --sellTokenIsNative --execute\n\n# 2. Move USDC from spot into perps account\nphantom perps transfer --amountUsdc 8\n\n# 3. Open a leveraged long position\nphantom perps open --market BTC --direction long --sizeUsd 50 --leverage 5 --orderType market\n\nExit and withdraw:\n# 1. Close the position\nphantom perps close --market BTC\n\n# 2. Bridge USDC from perps back to Solana\nphantom perps withdraw --amountUsdc 8 --destinationChainId solana:mainnet\n\n# Or bridge USDC from Hyperliquid spot to Solana (if funds are already in spot)\nphantom perps withdraw-hl-spot --amountUsdc 8 --destinationChainId solana:mainnet\n\n​Global flags\nFlagDescription--walletIdOverride the wallet ID (defaults to authenticated wallet)--derivationIndexAccount derivation index (default: 0)--helpShow help for the current command--versionShow CLI version--mcpStart the CLI as an MCP stdio serverWas this page helpful?","tokens":954,"squid":"spider-10","role":"Tooling Spider","at":1791343651883,"hash":"35f2623be6bc503bce52faf86f6e6f947ad4e27c"}
{"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":"spider-08","role":"Oracle Spider","at":1791343678602,"hash":"02f487482326cc35088bdc92997ba2d67b80b296"}
{"url":"https://docs.phantom.com/phantom-mcp-server/account-types","domain":"docs.phantom.com","title":"Agent wallets and your existing accounts - Phantom developer documentation","text":"When you set up the Phantom MCP server and sign in (even with the same Google or Apple account you use for Phantom), your agent receives a new dedicated wallet, not your existing personal wallet. This is by design.\n​Why your agent has a different wallet\nAgent wallets are isolated from your personal Phantom wallet for security. An AI agent acting on your behalf should only have access to the funds you explicitly send it, not everything in your main wallet.\nWhen you authenticate with @phantom/mcp-server, Phantom creates a fresh wallet for that agent. This wallet has its own addresses across Solana, Ethereum, Bitcoin, and Sui. Sui address support has been deprecated.\nThe agent wallet starts with a zero balance. You must fund it before the agent can transfer tokens, swap, or trade. Use get_wallet_addresses to find the agent’s addresses after setup.\n​Where are my existing accounts?\nYour existing Phantom accounts are still there. They haven’t been deleted or rotated.\n\nPersonal wallet: Accessible in the Phantom browser extension or mobile app as normal.\nEmbedded wallets (created via Phantom Connect SDK apps): Scoped to the app where they were created. Each app integration maintains its own wallet, separate from your personal wallet and your agent wallet.\n\nComing soon: Agent wallets will appear directly in the Phantom app, making it easy to view balances and manage funds alongside your other accounts.\n​How to fund your agent wallet\n\nAfter setup, ask your agent: “What are my wallet addresses?” or call get_wallet_addresses.\nCopy the address for the chain you want to use (e.g. Solana or Ethereum).\nSend funds from your personal wallet or an exchange to that address.\n\nThe agent can only spend what you send to its wallet.\n​Summary\nAccountWhere to accessShares funds with agent?Personal walletPhantom extension / mobile appNoEmbedded wallet (app logins)App where it was createdNoAgent walletMCP server (get_wallet_addresses)No\nEach wallet is separate. Signing in with the same email does not give your agent access to your personal wallet or embedded wallets.Was this page helpful?","tokens":524,"squid":"spider-10","role":"Tooling Spider","at":1791343688151,"hash":"74f32ce798b96eaafe3b965aa4d296b4d3c23dba"}
{"url":"https://squidfunk.github.io/mkdocs-material/insiders/changelog/","domain":"squidfunk.github.io","title":"Changelog - Material for MkDocs","text":"Changelog¶ Material for MkDocs Insiders¶ 4.53.17 August 22, 2025¶ Fixed #8408: Code annotations bug with custom selectors 4.53.16 March 13, 2025¶ Fixed #8019: Tooltips have precedence over instant previews 4.53.15 January 15, 2025¶ Fixed #7896: Scoped tags listings not rendering in subsections 4.53.14 September 29, 2024¶ Fixed #7567: Empty headlines when using typeset plugin with anchorlinks 4.53.13 September 14, 2024¶ Fixed #7520: Social plugin errors for generated files (MkDocs 1.6+) 4.53.12 August 2, 2024¶ Fixed #7410: Instant previews jump on content tabs with anchor links Fixed #7408: Instant previews jump on content tabs 4.53.11 May 27, 2024¶ Fixed projects plugin crashing when serving before building subprojects 4.53.10 May 20, 2024¶ Fixed projects plugin crashing in serve mode when disabled Fixed projects plugin crashing when building nested projects 4.53.9 May 20, 2024¶ Fixed #7191: Tags listings not rendering when toc_depth is changed 4.53.8 April 26, 2024¶ Fixed #7052: Preview extension automatically including all pages Fixed #7051: Instant previews mounting on footnote references Fixed #5165: Improved tooltips not mounting in sidebar for typeset plugin 4.53.7 April 25, 2024¶ Fixed #7060: Incorrect resolution of translation when using static-i18n 4.53.6 April 5, 2024¶ Ensure working directory is set for projects when using projects plugin Fixed #6970: Incorrect relative paths in git submodules with projects plugin 4.53.5 April 2, 2024¶ Fixed social plugin crashing when no colors are specified in palettes 4.53.4 March 31, 2024¶ Fixed #6973: Escaping issue in tags extra files deprecation helper 4.53.3 March 23, 2024¶ Added support for font variants in social plugin Improved resilience of font resolution in social plugin Fixed tag listing sometimes not being auto-populated Fixed tag listing scope not being correctly resolved Fixed #6941: Meta plugin adding duplicate entries Fixed #6928: Social plugin crashes for some fonts 4.53.2 March 18, 2024¶ Fixed abort on first non-matching configuration in preview extension Fixed #6914: Meta files take precedence over front matter 4.53.1 March 6, 2024¶ Fixed #6877: Projects plugin computes incorrect path to assets Fixed #6869: Blog plugin should emit warning on invalid related link 4.53.0 February 24, 2024¶ Added support for automatic instant previews Added support for pinned blog posts 4.52.3 February 21, 2024¶ Fixed resolution of URLs in instant previews Fixed instant previews not mounting for same-page links 4.52.2 February 7, 2024¶ Fixed #6735: Instant previews misplaced when below tabs 4.52.1 January 30, 2024¶ Fixed #6705: Navigation path not being hidden when specified Fixed #6703: New tags plugin crashes on Windows (2nd attempt) 4.52.0 January 28, 2024¶ Added support for instant previews Fixed footnote tooltips positioning edge cases Fixed #6703: New tags plugin crashes on Windows 4.51.0 January 24, 2024¶ Added support for footnote tooltips 4.50.0 January 19, 2024¶ Added configurable logging capabilities to privacy plugin 4.49.2 January 9, 2024¶ Fixed missing attribute lists extension for tags plugin Fixed #6627: New tags plugin crashes on Python 3.8 4.49.1 January 7, 2024¶ Improved interop of new tags plugin with other plugins Fixed #6594: Tags plugin doesn't work with mkdocs-macros plugin Fixed #6569: Social plugin crashes if in different file system location 4.49.0 December 29, 2023¶ Added support for exporting tags and mappings Added support for disabling tags and/or listings or both Fixed tag links from pages to listings on homepage 4.48.0 December 23, 2023¶ Rewrite of tags plugin, now much more powerful Added support for nested tags (tag hierarchies, e.g. foo/bar) Added support for shadow tags (by list, prefix or suffix) Added support for custom tag layouts and templates Added support for hiding tags in table of contents Added support for configurable inline tag listings Added support for automatically linking to closest tag listing Added support for scoped listings (limit to subsection of site) Added support for multiple instances of tags plugin Added support for changing front matter property and template variable Added support for tag slugification format strings Fixed #6510: Projects plugin out of memory on Linux (4.47.1 regression) Fixed projects plugin not notifying plugins about serve mode Fixed projects plugin skipping projects on prefix match Deprecated tags_file and tags_extra_files settings Modernized tags plugin code base 4.47.1 December 11, 2023¶ Improved editing experience for projects plugin Improved resilience of optimize and social plugin Fixed race condition when writing manifest in optimize and social plugin Fixed #6475: Logo not taking precedence over icon in social card Fixed #6399: Projects plugin doesn't pick up added/removed projects Fixed #6306: Projects plugin cache not correctly updated 4.47.0 December 8, 2023¶ Added support for staying on page when switching languages Added configurable logging capabilities to projects plugin Removed temporary warning on blog plugin authors file format change Fixed projects plugin logging messages twice on Linux systems Fixed projects plugin trying to hoist theme assets of divergent themes Fixed compatibility of optimize plugin and projects plugin Fixed compatibility of social plugin and projects plugin Fixed #6448: Code line selection broken for code blocks with custom ids Fixed #6437: Projects plugin crashing for certain site URL configurations Fixed #6414: Projects plugin doesn't prefix messages coming from projects 4.46.0 November 26, 2023¶ Added support for author profiles in blog plugin Fixed custom index pages yielding two navigation items (4.45.0 regression) 4.45.0 November 24, 2023¶ Added support for sorting blog categories by post count or custom function Improved tags plugin to generate Unicode-aware slugs by default Fixed non-deterministic order of multiple authors in blog plugin 4.44.0 November 23, 2023¶ Added pagination settings for archive pages in blog plugin Added pagination settings for category pages in blog plugin 4.43.1 November 19, 2023¶ Added third-party theme support in projects plugin, improving editing Fixed #6360: Projects plugin crashes when theme is not Material for MkDocs Fixed #6306: Projects plugin not reloading nested project configuration 4.43.0 November 5, 2023¶ Added support for GitLab committers (document contributors) Fixed #6264: Fixed compatibility with Python < 3.10 Fixed #6254: Meta plugin not applying meta files to blog posts 4.42.3 October 27, 2023¶ Fixed #6251: Cards in grids cut off on very small screens Fixed #6241: Using social plugin + static-i18n plugin errors 4.42.2 October 14, 2023¶ Fixed #6186: Privacy plugin ignores hash fragments on images Fixed #6180: Projects plugin crashing when adding or removing files 4.42.1 October 5, 2023¶ Fixed spacing of related links in blog posts on small screens 4.42.0 September 19, 2023¶ Added support for using git submodules in projects plugin Added support for transforming project configurations Improved resilience of optimize and blog plugin Fixed optimize plugin crashing on .jpeg extension Fixed project URLs not using site URLs in projects plugin 4.41.0 September 11, 2023¶ Improved multi-instance support for optimize plugin Added inclusion and exclusion patterns for optimize plugin Added transparent keyword for color handling in social plugin Changed default quality of PNGs to 3 in optimize plugin Fixed #5979: meta file not detected in root of docs directory 4.40.4 September 4, 2023¶ Fixed privacy plugin choking on boolean HTML5 attributes Fixed wrapping of inline code blocks in typeset table of contents Fixed blog plugin error when running under dirty reload 4.40.3 September 2, 2023¶ Fixed #5946: Docker image missing pngquant for optimize plugin 4.40.2 August 31, 2023¶ Added configurable error handling capabilities for social plugin Fixed #5922: Blog plugin shows no posts when building a standalone blog Fixed #5914: Tags plugin tags_extra_files errors (4.39.3 regression) Fixed #5904: Blog plugin sometimes excludes files (4.40.1 regression) 4.40.1 August 27, 2023¶ Fixed #5902: ResizeObserver polyfill not detected by privacy plugin Fixed empty category pages in blog plugin (4.40.0 regression) 4.40.0 August 26, 2023¶ Added logo, title and description options to social plugin default layouts Fixed privacy plugin compatibility issue with Python < 3.10 Fixed #5896: Blog plugin errors when using custom index pages 4.39.3 August 24, 2023¶ Fixed lxml dependency missing in Docker container (4.39.2 regression) 4.39.2 August 23, 2023¶ Fixed color palette toggle being reversed (9.2.0 regression) 4.39.1 August 21, 2023¶ Fixed git diff in tags plugin after merging back 9.2.0 changes 4.39.0 August 3, 2023¶ Added support for hoisting theme media files when building projects Added support for sorting pages on tags index for tags plugin Added support for adding date of last update to blog posts Fixed #5797: Parse error in typeset plugin (4.38.1 regression) 4.38.1 August 1, 2023¶ Improved nested serve mode for projects plugin Improved compat in privacy plugin with third-party plugins Fixed #5790: Typeset plugin ignores data-toc-label attribute Fixed #5778: Interplay of privacy plugin with git-revision-date-localized Fixed #5773: Info plugin erroring when community edition is in beta 4.38.0 July 29, 2023¶ Added projects plugin for building nested projects Updated privacy plugin to new MkDocs API 4.37.1 July 28, 2023¶ Updated MkDocs to 1.5.1 Fixed deprecation warning in social plugin due to MkDocs upgrade Fixed #5772: Privacy plugin fails due to API change in MkDocs 4.37.0 July 7, 2023¶ Added support for overriding social cards settings per page Added new social card default/only/image layout Improved resilience of optimize and social plugin Fixed rendering bugs for pruned navigation items Fixed jumping of content tabs anchor links when instant loading is enabled Fixed #5676: Optimize plugin doesn't check for pngquant 4.36.1 June 23, 2023¶ Fixed #5618: Date comparison breaking for drafts in blog plugin 4.36.0 June 15, 2023¶ Added support for instant prefetching to speed up slow connections Improved stability of anchor link removal in built-in typeset plugin Improved performance of regular expressions in typeset plugin Removed unnecessary import test for cairosvg in optimize plugin Fixed #5590: Regular expression for anchor link removal too greedy 4.35.3 June 1, 2023¶ Fixed #5579: Abbreviations in headlines filtered by typeset plugin 4.35.2 May 29, 2023¶ Fixed #5555: Blog plugin crashes when computing readtime for emojis 4.35.1 May 20, 2023¶ Fixed internal handling of errors in social plugin 4.35.0 May 20, 2023¶ Improve editing experience and stability of social plugin Added support for custom layout syntax validation in social plugin Added support for layer origin for easier placement in social plugin Added support for in- and exclusion patterns in social plugin Catch and print syntax errors in custom layouts 4.34.1 May 16, 2023¶ Disable social plugin debug mode by default on mkdocs build Added warning in social plugin debug mode when font style couldn't be found Set default concurrency of built-in multi-threaded plugins to CPUs - 1 Fixed #5521: Social plugin triggers race condition when downloading fonts Fixed #5515: Social plugin crashes when concurrency is set to 1 4.34.0 May 14, 2023¶ Added support for new overflow mode to auto-fit text in social plugin Reduced subtle rendering bugs in (code) annotations due to subpixel rounding Improved print styles for (code) annotation lists Improved performance of social plugin, now 3x as fast Improved interop of typeset plugin with MkDocstrings Fixed logo location for variants of default template in social plugin Fixed #5446: Built-in typeset plugin picks up headings in code blocks 4.33.2 May 12, 2023¶ Fixed #5508: Social plugin crashes trying to copy cards on Docker/Windows Fixed #5507: Social plugin crashes on serve when layouts folder doesn't exist Fixed #5505: Social plugin trying to resolve logo in wrong location Fixed #5496: Annotations with nested lists incorrectly mounted Fixed #5493: Social plugin crashes on Python 3.8 4.33.1 May 9, 2023¶ Added support for SVG background images in social plugin 4.33.0 May 8, 2023¶ Added support for custom layouts for social plugin Added support for background images for social cards 4.32.6 April 22, 2023¶ Fixed #5336: Interplay of blog plugin with git-revision-date-localized 4.32.5 April 7, 2023¶ Fixed #5322: Navigation tabs hoist nested page icons 4.32.4 March 24, 2023¶ Fixed #5241: Built-in typeset plugin jams navigation for anchors in headings 4.32.3 March 9, 2023¶ Fixed Docker image release workflow (9.1.0 regression) Fixed #5159: Missing underline for abbreviations (9.1.0 regression) 4.32.2 February 23, 2023¶ Fixed #5127: Privacy plugin not handling large number of occurrences Fixed #5126: Privacy plugin breaks when replacing specific emojis 4.32.1 February 23, 2023¶ Fixed code block spans interfering with copying Fixed #5077: Privacy plugin breaks image alt text encoding Fixed #5079: Privacy plugin removing rel=me on external links 4.32.0 February 19, 2023¶ Added support for custom selectors for code annotations Added support for code line range selection for better sharing 4.31.0 February 18, 2023¶ Added support for table of contents on blog index and archive pages Fixed #4512: Allow custom search field boosts (experimental) 4.30.2 February 13, 2023¶ Fixed privacy plugin excludes not working (4.30.0 regression) 4.30.1 February 12, 2023¶ Fixed privacy plugin not handling static templates (e.g. 404.html) 4.30.0 February 6, 2023¶ Rewrite of privacy plugin for concurrency, now twice as fast Added support for explicit inclusion for privacy plugin Added optimization support for privacy plugin (+ optimize plugin) 4.29.0 January 21, 2023¶ Added built-in optimize plugin for automatically compressing images Switched reporting in built-in privacy plugin to info level 4.28.1 January 17, 2023¶ Fixed built-in info plugin erroring for Insiders on version check Fixed #4865: Navigation paths render bug when there's no top-level section Fixed #4875: Added support for hiding navigation paths Improved navigation path to not render for a single item 4.28.0 January 14, 2023¶ Added support for navigation path (breadcrumbs) 4.27.1 December 20, 2022¶ Fixed rendering of succeeding navigation items in typeset plugin Fixed #4795: Built-in typeset plugin changes MkDocs' title precedence Fixed #4724: Blog plugin not rendering integrate table of contents 4.27.0 December 20, 2022¶ Added built-in typeset plugin to preserve formatting in sidebars Added URL and table of contents support for blog categories 4.26.6 November 28, 2022¶ Fixed #4683: Tags plugin crashes when a tag is empty 4.26.5 November 27, 2022¶ Fixed #4632: Post excerpt title link doesn't point to top of the page 4.26.4 November 27, 2022¶ Fixed redundant file extension when using privacy plugin 4.26.3 November 15, 2022¶ Fixed #4637: Attachments w/o titles in related links error in blog plugin Fixed #4631: Remote favicons not downloaded and inlined by privacy plugin 4.26.2 November 3, 2022¶ Updated MkDocs to 1.4.2 Added support for tag compare functions when sorting on index pages Fixed footnotes being rendered in post excerpts without separators Fixed error in blog plugin when toc extension is not enabled Fixed issues with invalid asset paths and linked post titles Fixed #4572: Privacy plugin fails when symlinks cannot be created Fixed #4545: Blog plugin doesn't automatically link headline to post Fixed #4542: Blog plugin doesn't allow for multiple instances Fixed #4532: Blog plugin doesn't allow for mixed use of date and datetime 4.26.1 October 22, 2022¶ Improved reporting of configuration errors in tags plugin Fixed #4515: Privacy plugin fails when site URL is not defined Fixed #4514: Privacy plugin doesn't fetch Google fonts (4.26.0 regression) 4.26.0 October 18, 2022¶ Refactored privacy plugin to prepare for new features Added support for rel=noopener links in privacy plugin Resolve encoding issues with blog and privacy plugin 4.25.5 October 16, 2022¶ Updated MkDocs to 1.4.1 Added namespace prefix to built-in plugins Updated content and header partial 4.25.4 October 9, 2022¶ Fixed other path issues for standalone blogs (4.24.2 regression) 4.25.3 October 9, 2022¶ Fixed #4457: Posts not collected for standalone blog (4.24.2 regression) 4.25.2 October 4, 2022¶ Fixed #4452: Blog and tags plugin crash when specifying slugify function 4.25.1 October 3, 2022¶ Updated mkdocs-rss-plugin in Dockerfile to fix MkDocs compat errors 4.25.0 October 2, 2022¶ Added support for navigation subtitles Added support for defining an allow list for built-in tags plugin Added support for custom slugify functions for built-in tags plugin Improved stability of search plugin when using --dirtyreload 4.24.2 October 1, 2022¶ Updated MkDocs to 1.4 Fixed compatibility issues with MkDocs 1.4 Fixed incorrectly generated paths in privacy plugin Fixed blog index page not showing navigation when using meta plugin 4.24.1 September 30, 2022¶ Fixed #4430: build error when enabling consent without repository URL 4.24.0 September 27, 2022¶ Added support for custom content on index pages (blog) Added support for keeping content on paginated index pages (blog) Added support for limiting categories in post excerpts (blog) Added support for simple override of templates via front matter (blog) Added icon in navigation for pages with encrypted content Fixed #4396: Front matter of index pages not inherited by pagination (blog) Improved performance by building post excerpts once (blog) 4.23.6 September 22, 2022¶ Fixed #4389: Blog posts in first week of year in wrong archive Fixed (= switched) footer previous and next links for blog posts 4.23.5 September 18, 2022¶ Fixed #4367: Improved blog plugin date handling for MultiMarkdown syntax Fixed #4374: Fixed invalid URLs of related links to other blog posts 4.23.4 September 14, 2022¶ Fixed #4365: Recursion error in blog plugin due to deepcopy Fixed path errors for blog plugin on Windows Fixed publishing workflow in forked repositories 4.23.3 September 13, 2022¶ Fixed previous and next page links for drafts of blog posts 4.23.2 September 13, 2022¶ Fixed #4348: Blog plugin crashes on custom nav title Fixed blog plugin crashing when category contained only drafts Fixed rendering of content from blog index file 4.23.1 September 12, 2022¶ Fixed #4345: Blog plugin errors with default settings 4.23.0 September 12, 2022¶ Added blogging support via built-in blog plugin 4.22.1 September 7, 2022¶ Fixed #4217: Tooltips in data tables render in wrong position 4.22.0 August 21, 2022¶ Added support for navigation status 4.21.1 August 13, 2022¶ Fixed #4176: Broken image when avatar is served by Gravatar Fixed #4212: Deferred search initialization for file:// locations 4.21.0 July 17, 2022¶ Added meta plugin: set front matter for all pages in a folder Fixed #4114: Tags plugin fails if only tags_extra_files is set 4.20.1 July 11, 2022¶ Fixed #4105: Tags plugin fails if tags_file is not set (4.20.0 regression) 4.20.0 July 7, 2022¶ Added support for additional tags indexes Fixed #4100: Tag icons not shown in tags index 4.19.2 July 4, 2022¶ Fixed #4051: Privacy plugin fails if symlinking isn't allowed on Windows 4.19.1 June 25, 2022¶ Added mkdocs-git-committers-plugin to Dockerfile Added mkdocs-git-revision-date-localized-plugin to Dockerfile 4.19.0 June 24, 2022¶ Added support for document contributors Updated French translations for cookie consent 4.18.2 June 16, 2022¶ Fixed #4026: Fixed tooltips not mounted for nested navigation links 4.18.1 June 14, 2022¶ Fixed #3990: Chinese search highlighting not working on non-boundaries 4.18.0 June 11, 2022¶ Added support for automatic dark/light mode Fixed #4009: Privacy plugin uses invalid paths for file cache on Windows 4.17.2 June 5, 2022¶ Added support for custom jieba dictionaries (Chinese search) 4.17.1 June 5, 2022¶ Added support for cookie consent reject button Added support for cookie consent custom button ordering Fixed #3988: Content tab not focused after alternating anchor links 4.17.0 June 4, 2022¶ Added support for content tabs anchor links (deep linking) Fixed #3975: Detect composition events in search interface (Chinese) Fixed #3980: Search plugin doesn't use title set via front matter 4.16.2 May 29, 2022¶ Fixed #3961: Nested sections triggered build error for navigation tabs 4.16.1 May 28, 2022¶ Switched feedback widget rating titles to tooltips Improved contrast of link colors for light/dark color schemes Fixed #3950: Sticky navigation tabs rendering broken (4.15.2 regression) Fixed #3958: Links invisible when using white primary color 4.16.0 May 25, 2022¶ Added support for navigation pruning Fixed search results for non-segmented characters (4.15.2 regression) 4.15.2 May 22, 2022¶ Removed workaround for abbr on touch devices (superseded by tooltips) Fixed #3915: Improved Chinese search query segmentation Fixed #3938: Fixed tooltips position for navigation titles with ellipsis 4.15.1 May 14, 2022¶ Improved performance of element focus observables Fixed #3531: Added prev/next buttons to content tabs Fixed tooltip positioning when host element is hidden 4.15.0 May 8, 2022¶ Added support for improved tooltips Fixed #3785: Show tooltip on hover for overflowing navigation link 4.14.0 May 5, 2022¶ Added Chinese language support to built-in search plugin Fixed all-numeric page titles raising error in social plugin 4.13.2 April 30, 2022¶ Improved caching of downloaded resources in privacy plugin Fixed #3851: External images not downloaded by privacy plugin 4.13.1 April 25, 2022¶ Fixed #3839: Tags plugin breaks without icons (4.13.0 regression) 4.13.0 April 24, 2022¶ Added support for tag icons 4.12.0 March 27, 2022¶ Added support for card grids and grid layouts Fixed #3685: Annotations sometimes broken when using instant loading Fixed #3742: Automatically add Mermaid.js when building for offline usage 4.11.0 March 6, 2022¶ Added support for excluding external assets from privacy plugin 4.10.1 March 2, 2022¶ Added missing build dependencies to Dockerfile Fixed encoding issues in privacy plugin, now forcing UTF-8 encoding Fixed #3624: Scroll to active navigation item unreliable in Firefox Fixed #3642: Privacy plugin errors when font setting was omitted 4.10.0 February 27, 2022¶ Added support for offline plugin (supersedes offline search support) Improved built-in privacy plugin to download nested JavaScript assets Refactored configuration of built-in privacy plugin 4.9.1 February 21, 2022¶ Fixed #3610: missing lxml dependency for privacy plugin Fixed error when charset is missing in content-type header 4.9.0 February 20, 2022¶ Added privacy plugin: automatic downloading of external assets 4.8.3 February 13, 2022¶ Fixed #3560: Mermaid diagrams don't render for file:// locations 4.8.2 February 10, 2022¶ Fixed #3559: Mermaid diagrams don't render inside closed details 4.8.1 February 6, 2022¶ Fixed jump back to top on mobile when using anchor following 4.8.0 February 6, 2022¶ Added support for anchor following table of contents (= auto scroll) 4.7.2 February 2, 2022¶ Fixed #3526: Transparent sidebar title due to Safari bug Fixed #3528: Firefox sometimes clips text in flow chart diagrams 4.7.1 January 30, 2022¶ Fixed #3506: Tags index not respecting title set via front matter 4.7.0 January 25, 2022¶ Added native support for offline search 4.6.1 January 16, 2022¶ Fixed #3459: Section index pages picking up wrong title 4.6.0 January 11, 2022¶ Added support for annotations (outside of code blocks) 4.5.2 January 8, 2022¶ Fixed #3440: Content tab indicator not moving when using linking Fixed #3445: Content tab switch flickers/jitters when using linking 4.5.1 January 2, 2022¶ Added support for setting initial state of cookie consent Fixed #3396: Disappearing link in navigation due to Safari bug 4.5.0 December 16, 2021¶ Added support for navigation icons 4.4.0 December 10, 2021¶ Added support for code annotation anchor links (deep linking) Added new code annotation syntax modifier to strip comment Updated German translations for cookie consent 4.3.0 December 5, 2021¶ Added support for custom fonts in social cards Fixed #3300: Announcement bar reappearing when using instant loading 4.2.0 December 2, 2021¶ Added support for dismissible announcement bar Added support for named placeholders in feedback widget 4.1.0 November 30, 2021¶ Added support for passing page title to feedback forms 4.0.0 November 28, 2021¶ Removed deprecated content tabs legacy implementation Removed deprecated seealso admonition type Removed deprecated site_keywords setting (unsupported by MkDocs) Removed deprecated prebuilt search index support Removed deprecated web app manifest – use customization Removed extracopyright variable – use new copyright partial Removed Disqus integration – use customization Switched to :is() selectors for simple selector lists Switched autoprefixer from last 4 years to last 2 years Improved CSS overall to match modern standards Improved CSS variable semantics for fonts Improved extensibility by restructuring partials Improved handling of details when printing Improved keyboard navigation for footnotes Fixed #3214: Search highlighting breaks site when empty 3.2.3 November 20, 2021¶ Updated Swedish and French translations Removed support for .mermaid-experimental class (now .mermaid) Fixed #3202: Cookie consent not dismissable on file:// locations Fixed #3216: Cookie consent not dismissed when invoked via anchor Fixed #3232: Mermaid.js sometimes runs twice (race condition) 3.2.2 November 6, 2021¶ Fixed always last feedback rating being sent Fixed #3145: Code annotations eat whole comment lines Fixed #3170: Feedback widget doesn't send data to GA4 3.2.1 November 4, 2021¶ Added support for custom Mermaid.js version via additional JavaScript Fixed some configuration edge cases for tags plugin (3.1.5 regression) Fixed feedback widget title not being centered in Firefox Fixed #3179: Safari doesn't send request for feedback widget 3.2.0 October 31, 2021¶ Added support for feedback widget (Was this page helpful?) 3.1.5 October 28, 2021¶ Fixed #3144: Rogue link when using tags with auto-populated navigation Fixed #3147: Code block line numbers appear in search results Fixed #3158: Social cards do not strip HTML tags from title 3.1.4 October 17, 2021¶ Fixed #2974: Text cropped with other fonts than Roboto in social plugin Fixed #3099: Encoding problems with non-latin character in social plugin Fixed #3112: Japanese segmenter not executed as part of new tokenizer Fixed tags (front matter) appearing in search with disabled tags plugin 3.1.3 October 12, 2021¶ Added warnings to search plugin for unsupported options and syntax Fixed #3503: Search sometimes returns entire page Fixed #3089: Single-line code annotations disappear when printing 3.1.2 October 6, 2021¶ Fixed incorrect path separators for social cards on Windows 3.1.1 September 26, 2021¶ Fixed ordering bug in search exclusion logic 3.1.0 September 26, 2021¶ Added support for excluding pages, sections, and elements from search Fixed #2803: Code block annotations not visible when printing 3.0.1 September 19, 2021¶ Added support for using literal h1-6 tags for search plugin Fixed search plugin breaking on void elements without slashes Fixed search plugin filtering link contents from headlines Fixed search plugin handling of multiple h1 headlines Fixed search plugin handling of missing h1 headlines 3.0.0 September 13, 2021¶ Rewrite of MkDocs' search plugin Added support for rich search previews Added support for tokenizer with lookahead Improved search indexing performance (twice as fast) Improved search highlighting 2.13.3 September 1, 2021¶ Added support for disabling social card generation 2.13.2 August 25, 2021¶ Fixed #2965: Social plugin error when primary color is not defined 2.13.1 August 21, 2021¶ Fixed #2948: Social cards are not cached Fixed #2953: Mermaid.js diagrams can't be centered anymore 2.13.0 August 7, 2021¶ Added support for custom colors in social cards 2.12.2 August 4, 2021¶ Fixed #2891: Division by zero error in social plugin 2.12.1 July 26, 2021¶ Fixed error in social plugin when site_description was not set Fixed error in social plugin for non-ASCII characters 2.12.0 July 25, 2021¶ Added support for social cards 2.11.1 July 20, 2021¶ Fixed order of tags index, now sorted alphabetically 2.11.0 July 18, 2021¶ Improved Mermaid.js integration, now stable Added support for sequence diagrams Added support for entity relationship diagrams Added support for cookie consent configuration Added feature flag to always enable annotations 2.10.0 July 10, 2021¶ Added support for cookie consent Fixed #2807: Back-to-top button not hidden when using sticky tabs 2.9.2 May 30, 2021¶ Moved tags to partial for easier customization Added support for hiding tags on any page 2.9.1 May 24, 2021¶ Added missing guard for linking of content tabs 2.9.0 May 23, 2021¶ Added support for linking of content tabs 2.8.0 May 12, 2021¶ Added support for boosting pages in search 2.7.2 May 8, 2021¶ Fixed #2638: Warnings shown when using tags plugin without directory URLs 2.7.1 May 3, 2021¶ Fixed git-revision-date-localized plugin integration (2.7.0 regression) 2.7.0 May 1, 2021¶ Added support for tags (with search integration) 2.6.0 April 11, 2021¶ Stay on page when switching versions 2.5.0 March 28, 2021¶ Added support for version warning 2.4.0 March 20, 2021¶ Added support for custom admonition icons Fixed #2444: Code block annotations with extra comments have wrong index 2.3.1 March 14, 2021¶ Fixed anchor offset for permalinks when using sticky navigation tabs 2.3.0 March 13, 2021¶ Added support for back-to-top button 2.2.1 March 4, 2021¶ Fixed #2382: Repository stats failing when no release tag is present 2.2.0 February 28, 2021¶ Added support for code block annotations 2.1.0 February 26, 2021¶ Added support for anchor tracking 2.0.0 February 24, 2021¶ Migrated Insiders to the new architecture Swapped color palette toggle configuration 1.17.0 January 31, 2021¶ Added support for section index pages 1.16.1 January 26, 2021¶ Fixed #2249: Instant loading + sticky tabs result in invalid links Fixed #2248: Search highlighting URL parameter always added Fixed #2235: Version selector doesn't select current version for aliases 1.16.0 January 7, 2021¶ Added latest release to repository info (GitHub) Slight facelift of repository info (lighter fonts, spacing and icons) 1.15.0 January 2, 2021¶ Added support for native Mermaid.js integration 1.14.0 December 30, 2020¶ Added support for sharing searches 1.13.2 December 22, 2020¶ Fixed version selector + sticky tabs navigation rendering issues Fixed version selector wrapping 1.13.1 December 20, 2020¶ Removed horizontal scrollbars on language and version selector Fixed type conversion in JavaScript config 1.13.0 December 13, 2020¶ Refactored navigation tabs to simplify grouping behavior Added support for sticky navigation tabs Added support for arbitrary links in navigation tabs Fixed #2098: Subsequent active subsection not highlighted correctly 1.12.1 December 8, 2020¶ Fixed empty language selector being shown 1.12.0 December 6, 2020¶ Added support for adding a language selector 1.11.2 November 29, 2020¶ Fixed #2068: Search highlight interprets code blocks as JavaScript 1.11.1 November 29, 2020¶ Refactored styling to be more stable and easier to adjust Fixed some styling regressions from latest features 1.11.0 November 22, 2020¶ Added support for rendering admonitions as inline blocks 1.10.0 November 15, 2020¶ Added support for integrating table of contents into navigation 1.9.0 November 7, 2020¶ Added support for hiding navigation and table of contents on any page Removed autohiding table of contents when empty 1.8.0 November 1, 2020¶ Added support for navigation sections Fixed appearance of inactive search suggestions 1.7.0 October 25, 2020¶ Added support for deploying multiple versions Fixed alignment of sidebar when content area is too small 1.6.0 October 11, 2020¶ Added support for search suggestions to save keystrokes Added support for removing Made with Material for MkDocs from footer Fixed #1915: search should go to first result by pressing Enter 1.5.1 September 21, 2020¶ Fixed content area stretching to whole width for long code blocks 1.5.0 September 19, 2020¶ Added support for autohiding table of contents when empty 1.4.1 September 6, 2020¶ Improved typeahead and search result relevance and scoring 1.4.0 August 30, 2020¶ Added support for autohiding header on scroll 1.3.0 August 26, 2020¶ Added support for user-selectable color palettes 1.2.0 August 11, 2020¶ Added feature to expand navigation by default 1.1.0 August 3, 2020¶ Added highlighting of search results 1.0.0 July 14, 2020¶ Added grouping of search results Added missing query terms to search result Improved search result relevance and scoring","tokens":8262,"squid":"spider-06","role":"Security Spider","at":1791343692715,"hash":"62045f42c2da8f5ac6fcbd8c7d7159211bc404d6"}
{"url":"https://pyth.network/developers/price-feed-ids","domain":"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":"spider-08","role":"Oracle Spider","at":1791343692749,"hash":"e2b31e27cc5e49f6d20416bf0b41c9d9e9bcdb51"}
{"url":"https://docs.phantom.com/phantom-mcp-server/openclaw-plugin","domain":"docs.phantom.com","title":"OpenClaw Plugin - Phantom developer documentation","text":"The Phantom OpenClaw plugin (@phantom/phantom-openclaw-plugin) gives OpenClaw agents direct access to a Phantom wallet. Once installed, agents can check balances, fetch addresses, transfer tokens, sign messages, swap assets, and use the rest of the Phantom MCP tool surface from inside OpenClaw.\n​Install\nInstall the plugin:\nopenclaw plugins install @phantom/phantom-openclaw-plugin\n\nIf you are testing a local checkout instead of the published package:\nopenclaw plugins install -l /absolute/path/to/packages/phantom-openclaw-plugin\n\n​Enable the plugin\nAdd the plugin to your OpenClaw config at ~/.openclaw/openclaw.json:\n{\n \"plugins\": {\n \"allow\": [\n \"phantom-openclaw-plugin\"\n ],\n \"entries\": {\n \"phantom-openclaw-plugin\": {\n \"enabled\": true\n }\n }\n }\n}\n\nIf you already have other plugins configured, add phantom-openclaw-plugin to your existing allow array and entries object.\n​Optional: associate tool calls with your app\nIf you registered your app in Phantom Portal, you can add your App ID to the plugin entry so tool calls made through the plugin are attributed to your application:\n{\n \"plugins\": {\n \"entries\": {\n \"phantom-openclaw-plugin\": {\n \"enabled\": true,\n \"PHANTOM_APP_ID\": \"your-app-id\",\n \"PHANTOM_CLIENT_ID\": \"your-client-id\"\n }\n }\n }\n}\n\nBoth keys are optional. PHANTOM_CLIENT_ID is only needed if your app uses a Phantom Connect Client ID. Without either value, the plugin authenticates with the default device-code flow and tool calls are not attributed to a specific app.\n​Authenticate on first use\nAfter installing and enabling the plugin:\n\nRestart OpenClaw.\nAsk the agent to perform a wallet action such as What are my Phantom wallet addresses?\nOpenClaw will trigger Phantom’s browser-based authentication flow.\nSign in, approve the wallet session, and return to OpenClaw.\n\nThe session is stored locally and reused across restarts until it is deleted or expires.\n​What the plugin exposes\nThe plugin wraps the Phantom MCP server and exposes the same wallet tool surface inside OpenClaw, including:\n\nget_connection_status\nget_wallet_addresses\nget_token_balances\nsend_solana_transaction\nsend_evm_transaction\nsign_solana_message\nsign_evm_personal_message\nsign_evm_typed_data\nsimulate_transaction\nget_token_allowance\ntransfer_tokens\nbuy_token\nportfolio_rebalance\nphantom_login\npay_api_access\nThe Phantom perp tools for Hyperliquid-backed trading flows (deposit_to_hyperliquid, open_perp_position, close_perp_position, cancel_perp_order, update_perp_leverage, transfer_spot_to_perps, withdraw_from_perps)\n\nSee the tool reference for the current tool behavior and parameters.\n​Notes\n\nNo manual MCP server wiring is required inside OpenClaw.\nThe plugin uses Phantom’s authentication flow automatically.\nTransaction sends and transfers use simulation-first flows where supported. Review the preview before approving execution.\n\n​Troubleshooting\nPlugin loads but Phantom tools do not appear\nConfirm the plugin is present in both plugins.allow and plugins.entries.\nVerify the entry is enabled: \"enabled\": true.\nRestart OpenClaw after config changes.\nAuthentication does not start\nTrigger a wallet action such as get_wallet_addresses.\nEnsure the machine can open a browser window.\nCheck that OpenClaw is using the expected installed plugin copy if you are testing a local path install.\nConfig invalid for phantom-openclaw-plugin\nMake sure the installed plugin copy matches the version of the manifest you expect.\nIf you are testing a local path install, reinstall or resync the plugin so OpenClaw validates against the current manifest.\n\n​Related\nWas this page helpful?","tokens":894,"squid":"spider-10","role":"Tooling Spider","at":1791343704180,"hash":"3ed5b28d098eb84f34d578b6188449640d20b4df"}
{"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":"spider-08","role":"Oracle Spider","at":1791343704254,"hash":"6b1a106fc0a6d3e4d164025ea6bf7d4dead50b24"}
{"url":"https://developer.arbitrum.io/how-arbitrum-works/deep-dives/arbos","domain":"developer.arbitrum.io","title":"ArbOS","text":"ArbOSHow ArbOS works as the child chain hypervisor, managing resources, block production, cross-chain messaging, and EVM execution.Request an updateArbOS is the child-EVM virtual machine monitor (VMM) for . 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 ) can replay it deterministically.\nCore responsibilities\n\nNetwork resource management: Allocating and tracking the required resources to execute 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 and child chains for deposits, withdrawals, and .\nEnhanced EVM execution: Running instrumented to execute with child-chain specific logic.\n support: Managing , memory, and execution context for -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 , and finalizes the block.\n\nMessages and blocks\n 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 . Two components deserve special mention because they back headline features:\n\nsendMerkle is the accumulator that records every → L1 message; its root is what the parent-chain verifies against when a withdrawal is finalized. See child-to-parent messaging for how a withdrawal proves against that root.\nprograms hold Stylus 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\nAn Arbitrum transaction has a cost structure on L1: the chain must pay Ethereum to store its data and spend compute to execute it. ArbOS meters both, so every transaction pays two parties:\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 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 —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 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 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).\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 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 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 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.How is this guide?AnyTrustLearn the fundamentals of the Arbitrum AnyTrust protocol.AssertionsDeep dive information on assertions and how to make an assertion.","tokens":1963,"squid":"spider-01","role":"Chain Spider","at":1791343707206,"hash":"d79830f4379982e2351c84432c0a53609fb9435f"}
{"url":"https://developer.arbitrum.io/how-arbitrum-works/deep-dives/batchposter","domain":"developer.arbitrum.io","title":"The batch poster","text":"The batch posterLearn the fundamentals of the Arbitrum batch poster.Request an updateBatch posting is a fundamental process for the operation in Arbitrum. It involves collecting multiple , organizing them into , compressing the data to reduce size, and sending these batches to the contract on the . 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 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 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 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 / committee or a custom backend—via the small Writer.Store interface, with a fallback to putting data directly on Ethereum (calldata or ). What comes back is either a (offchain) or the raw data (EthDA). The committee aggregation, , 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 is this guide?FinalityLearn the fundamentals of finality on Arbitrum.Parent to Child chain MessagingLearn the fundamentals of parent to child chain messaging on Arbitrum.","tokens":1053,"squid":"spider-01","role":"Chain Spider","at":1791343717084,"hash":"42189b8a74ffacba969671a5034af0d6d692774a"}
{"url":"https://developer.arbitrum.io/how-arbitrum-works/deep-dives/token-bridging","domain":"developer.arbitrum.io","title":"Token bridging","text":"Token bridgingDescribes how token bridging works on Arbitrum and the architecture of the token bridgeRequest 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 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.\nNotearbSomeERC20Token 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.\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.How is this guide?Sequencer transaction flowA deep dive into how the Sequencer processes transactions end-to-end: the transaction queue, ordering, block creation timing, and the sequencer feed.Gas and feesLearn the fundamentals of how to calculate fees on Arbitrum, including parent chain pricing formulas and child chain gas mechanics.","tokens":3187,"squid":"spider-01","role":"Chain Spider","at":1791343727055,"hash":"b7980964aecdbcd088c0507cc5266744a9865830"}
{"url":"https://forum.arbitrum.foundation/c/announcements/24","domain":"forum.arbitrum.foundation","title":"Latest Announcements topics - Arbitrum","text":"The Arbitrum Foundation notified the Security Council on the need to perform a potential Emergency action. Following a review of the details and known risks, the Security Council decided to execute the upgrade and it was completed at 11:30 EST on 2nd October 2026.\nThis report provides an overview of the risks that required the Security Council Action:\n\nAdd a permissionless guard for the One-Step Proof of BoLD on Arbitrum One\n\nTemporarily pause activation of new Stylus contracts on Arbitrum One & Nova\n\nKey point: To date, known bugs for Stylus primarily impact chain liveness (e.g., denial of service attacks) and do not put any user funds at risk.\nWhy was this action taken\nLet’s take this opportunity to explain why action was taken on two separate issues concerning BoLD and Stylus.\nInstalling the guard for One-Step Proof of BoLD. Given the rise of AI-assisted attacks, we have implemented a precautionary approach that allows anyone to pause settlement of Arbitrum One on Ethereum if there are at least two conflicting answers that pass at the same level in which only one should be valid and pass. This is to halt a class of publicly verifiable and detectable attacks that exploit a bug in the one-step proof. If halted, Arbitrum One will continue to process as normal except that messages from Arbitrum One to Ethereum, such as withdrawals, that are not yet confirmed will have to wait. This provides time for the Security Council to deploy a fix for the bug and resume the rollup.\nPreventing activation of new Stylus contracts. AI-assisted tooling has led to an increasing number of sophisticated attacks on hand-crafted WASM programs that do not use the standard Stylus compiler toolchain. These programs are specifically designed to cause unexpected behaviors such as degrading the chain’s performance for all other users. To date, no attacks have been discovered that permits theft of user funds.\nNew ArbOS releases have patched several reported bugs and known attacks over the past few months, but out of an abundance of caution, we have decided to temporarily pause new activations of Stylus contracts. This was executed as an emergency action to prevent the deployment of new hand-crafted WASM programs that are not yet patched by the current version of ArbOS on the Arbitrum network.\nThe Arbitrum Foundation has informed the Security Council that they will work with the ArbitrumDAO to discuss next steps on the timeline and manner for enabling activation of new Stylus contracts. The Arbitrum community remains confident in the value of Stylus and want to preserve these use cases while taking preventative measures against Stylus-based attack vectors as AI-assisted attack tooling continues to evolve.\nImpact on builders and users\n\nNo new activations. New Stylus contracts cannot be activated during the pause including new versions of existing applications that require activation.\n\nExisting contracts are not paused. Already-active Stylus contracts continue to execute until expiration. This pause does not deactivate them.\n\nThe ArbOS 61 upgrade renewed all active contracts on Arbitrum One, so no currently active contract expires before August 20, 2027.\n\nRenewal via keepalive stays permissionless and is unaffected by the pause.\n\nReactivating an expired contract, or one that needs to be updated after a Stylus version change, is paused.\n\nUsing/calling any activated Stylus contract stays permissionless for all users and developers.\n\nNo impact on EVM. Solidity (EVM) contract deployment and execution are unaffected by this Security Council action.\n\nSecurity Council Actions\nThere are two actions bundled into a single payload:\n\nOne-Step Proof Guard. The L1UpgradeExecutor gives a new pause contract (PauseExecutor) the ability to pause and nothing else. The new pause contract grants the guard (OspSoundnessGuard) PAUSER_ROLE to use it. Anyone can show the guard two conflicting answers to the same step of an open challenge. If the one-step proof accepts both, the guard has the pause contract put Arbitrum One’s settlement to Ethereum on hold.\n\nStylus deactivation. The Security Council called ArbOwner.setWasmActivationGas(2^64 - 1) to raise the Stylus activation gas requirement on Arbitrum One and Nova. This makes activation prohibitively expensive and effectively disables new activations. This is a configuration change and does not require an ArbOS upgrade.\n\nThe Security Council signed the following transactions to update the configuration:\n\nEthereum: Ethereum Transaction Hash: 0x30732bb7d2... | Etherscan\nArbitrum One:\nArbitrum One Transaction Hash: 0x9eb3a4be3b... | Arbitrum One\nArbitrum Nova:\nArbitrum Nova transaction 0x79e0fed470dff7a22059b108e3f8f42eddd2b580a6771594060c4e7326c5f984 | Blockscout\n\nAn external audit was conducted for the OSP Guard contracts. No audit is required for the Stylus deactivation as it is only updating a single parameter in the ArbOS configuration.\n\n Latest topics in Announcements\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 The ArbitrumDAO’s Procedures\n\n Below you’ll find the ArbitrumDAO’s Procedures, as approved by a governance process on April 2, 2026. For more historical context, scroll to the bottom. \nPredictable Voting Schedule\nTo improve predictability in the Arbit…\n\n read more\n\n 0\n\n 302\n\n Apr 16\n\n The ArbitrumDAO Code of Conduct\n\n Below you’ll find ArbitrumDAO’s Code of Conduct, approved through the governance process on April 2, 2026. For more historical context, scroll to the bottom. \nValues Alignment\nArbitrum contributors should always strive t…\n\n read more\n\n 0\n\n 192\n\n Apr 16\n\n About the Announcements category\n\n Announcements for important items, events and initiatives in the ArbitrumDAO.\n\n 0\n\n 2.8k\n\n Feb 2024\n\n Arbitrum Security Program is Live: Applications Now Open\n\n 0\n\n 78\n\n 8d\n\n ArbitrumDAO Factsheet: Robinhood Chain Mainnet Launch\n\n 5\n\n 971\n\n 10d\n\n The Arbitrum Foundation H1 2026 Progress Update\n\n 0\n\n 245\n\n Sep 2\n\n ArbitrumDAO Factsheet: LG Electronics Pilots Onchain Advertising on Arbitrum\n\n 1\n\n 141\n\n Jun 14\n\n Arbitrum Open House London 2026\n\n 1\n\n 141\n\n Jun 10\n\n The Arbitrum Foundation 2025 Transparency Report: The Year of Institutional Adoption\n\n 0\n\n 259\n\n Mar 17\n\n ArbitrumDAO Factsheet: Robinhood Chain Testnet Launches on Arbitrum\n\n 0\n\n 216\n\n Feb 11\n\n A Vision for the Future of Arbitrum\n\n 56\n\n 7.0k\n\n Feb 5\n\n The Arbitrum Foundation Bi-annual Progress Update (H1’2025)\n\n 10\n\n 1.3k\n\n Nov 2025\n\n The Watchdog Program: Get Rewarded for Reporting Suspected Grant Misuse\n\n 3\n\n 874\n\n Sep 2025\n\n The Arbitrum Foundation 2024 Transparency Report: A Year of Key Milestones and Progress\n\n 2\n\n 986\n\n Sep 2025\n\n The Arbitrum Foundation Bi-annual Progress Update (H1’2024)\n\n 8\n\n 1.5k\n\n Mar 2025\n\n List of projects banned from the DAO\n\n 0\n\n 543\n\n Dec 2024\n\n Improving Predictability in Arbitrum DAO’s Operations - Ratification\n\n 0\n\n 171\n\n Dec 2024\n\n The Constitution of the Arbitrum DAO\n\n 0\n\n 1.8k\n\n Jul 2024\n\n Arbitrum ArbOS upgrades\n\n 0\n\n 2.7k\n\n Jul 2024\n\n Arbitrum Foundation Transparency Report 2023\n\n 7\n\n 12.9k\n\n May 2024\n\n Community Guidelines\n\n 0\n\n 2.5k\n\n Apr 2023","tokens":1787,"squid":"spider-07","role":"Council Spider","at":1791343728514,"hash":"2c439352e323b37abdee88bff182b7702e82b054"}
{"url":"https://developer.arbitrum.io/how-arbitrum-works/deep-dives/l2-to-l1-messaging","domain":"developer.arbitrum.io","title":"Child to parent chain messaging","text":"Child to parent chain messagingLearn the fundamentals of child to parent chain messaging on Arbitrum.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.\n's 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 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 :\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 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.How is this guide?Parent to Child chain MessagingLearn the fundamentals of parent to child chain messaging on Arbitrum.Transaction lifecycleLearn how transactions are submitted and processed on Arbitrum, including sequencer and non-sequencer pathways.","tokens":1276,"squid":"spider-01","role":"Chain Spider","at":1791343737024,"hash":"5cde560b50ba6452ecfbc3152b660db89ce32ebb"}
{"url":"https://forum.arbitrum.foundation/t/arbitrumdao-factsheet-robinhood-chain-mainnet-launch/31041/6","domain":"forum.arbitrum.foundation","title":"ArbitrumDAO Factsheet: Robinhood Chain Mainnet Launch - Announcements - Arbitrum","text":"The Arbitrum Foundation notified the Security Council on the need to perform a potential Emergency action. Following a review of the details and known risks, the Security Council decided to execute the upgrade and it was completed at 11:30 EST on 2nd October 2026.\nThis report provides an overview of the risks that required the Security Council Action:\n\nAdd a permissionless guard for the One-Step Proof of BoLD on Arbitrum One\n\nTemporarily pause activation of new Stylus contracts on Arbitrum One & Nova\n\nKey point: To date, known bugs for Stylus primarily impact chain liveness (e.g., denial of service attacks) and do not put any user funds at risk.\nWhy was this action taken\nLet’s take this opportunity to explain why action was taken on two separate issues concerning BoLD and Stylus.\nInstalling the guard for One-Step Proof of BoLD. Given the rise of AI-assisted attacks, we have implemented a precautionary approach that allows anyone to pause settlement of Arbitrum One on Ethereum if there are at least two conflicting answers that pass at the same level in which only one should be valid and pass. This is to halt a class of publicly verifiable and detectable attacks that exploit a bug in the one-step proof. If halted, Arbitrum One will continue to process as normal except that messages from Arbitrum One to Ethereum, such as withdrawals, that are not yet confirmed will have to wait. This provides time for the Security Council to deploy a fix for the bug and resume the rollup.\nPreventing activation of new Stylus contracts. AI-assisted tooling has led to an increasing number of sophisticated attacks on hand-crafted WASM programs that do not use the standard Stylus compiler toolchain. These programs are specifically designed to cause unexpected behaviors such as degrading the chain’s performance for all other users. To date, no attacks have been discovered that permits theft of user funds.\nNew ArbOS releases have patched several reported bugs and known attacks over the past few months, but out of an abundance of caution, we have decided to temporarily pause new activations of Stylus contracts. This was executed as an emergency action to prevent the deployment of new hand-crafted WASM programs that are not yet patched by the current version of ArbOS on the Arbitrum network.\nThe Arbitrum Foundation has informed the Security Council that they will work with the ArbitrumDAO to discuss next steps on the timeline and manner for enabling activation of new Stylus contracts. The Arbitrum community remains confident in the value of Stylus and want to preserve these use cases while taking preventative measures against Stylus-based attack vectors as AI-assisted attack tooling continues to evolve.\nImpact on builders and users\n\nNo new activations. New Stylus contracts cannot be activated during the pause including new versions of existing applications that require activation.\n\nExisting contracts are not paused. Already-active Stylus contracts continue to execute until expiration. This pause does not deactivate them.\n\nThe ArbOS 61 upgrade renewed all active contracts on Arbitrum One, so no currently active contract expires before August 20, 2027.\n\nRenewal via keepalive stays permissionless and is unaffected by the pause.\n\nReactivating an expired contract, or one that needs to be updated after a Stylus version change, is paused.\n\nUsing/calling any activated Stylus contract stays permissionless for all users and developers.\n\nNo impact on EVM. Solidity (EVM) contract deployment and execution are unaffected by this Security Council action.\n\nSecurity Council Actions\nThere are two actions bundled into a single payload:\n\nOne-Step Proof Guard. The L1UpgradeExecutor gives a new pause contract (PauseExecutor) the ability to pause and nothing else. The new pause contract grants the guard (OspSoundnessGuard) PAUSER_ROLE to use it. Anyone can show the guard two conflicting answers to the same step of an open challenge. If the one-step proof accepts both, the guard has the pause contract put Arbitrum One’s settlement to Ethereum on hold.\n\nStylus deactivation. The Security Council called ArbOwner.setWasmActivationGas(2^64 - 1) to raise the Stylus activation gas requirement on Arbitrum One and Nova. This makes activation prohibitively expensive and effectively disables new activations. This is a configuration change and does not require an ArbOS upgrade.\n\nThe Security Council signed the following transactions to update the configuration:\n\nEthereum: Ethereum Transaction Hash: 0x30732bb7d2... | Etherscan\nArbitrum One:\nArbitrum One Transaction Hash: 0x9eb3a4be3b... | Arbitrum One\nArbitrum Nova:\nArbitrum Nova transaction 0x79e0fed470dff7a22059b108e3f8f42eddd2b580a6771594060c4e7326c5f984 | Blockscout\n\nAn external audit was conducted for the OSP Guard contracts. No audit is required for the Stylus deactivation as it is only updating a single parameter in the ArbOS configuration.\n\n Announcements\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n Jul 6\n\n 6 / 6\n\n Sep 26\n\n 10d ago\n\n post by Arbitrum on Jul 6\n\n post by MconnectDAO on Jul 7\n\n 3 months later\n\n post by nate6711 on Sep 26\n\n post by Arb_Junior on Sep 26\n\n Arb_Junior\n\n Thank you for raising this excellent question @nate6711 , It’s a great one for anyone learning about Arbitrum governance and the practical implications of the Arbitrum Expansion Program (AEP).\n1. Tracking the 8% revenue share\nYes, the payments are trackable both on-chain and through official reporting:\n• On-chain: The 8% share of Robinhood Chain’s net protocol revenue is routed through the standardized AEP fee routercontracts (RewardDistributor + ChildToParentRouter system). These contracts automatically split the fees (90% retained by the chain operator, 10% to the Arbitrum ecosystem) and ultimately deliver the DAO’s portion to the Arbitrum Foundation-controlled address on Ethereum, which then flows to the DAO treasury.\n• Official reporting: As noted in the ArbitrumDAO Factsheet on the Robinhood Chain mainnet launch, these funds “reach the treasury through the AEP fee router and appear in the DAO’s regular financial reporting.” You can follow them in the Arbitrum Foundation’s bi-annual progress updates (and any interim treasury or financial dashboards), where AEP / Expansion Program licence fees are broken out as a distinct income line. Third-party dashboards such as DefiLlama have also been tracking the contributions from Robinhood Chain.\n2. Does the DAO have any operational say over Robinhood Chain?\nNo — beyond the revenue-share obligation, the ArbitrumDAO does not have formal governance or operational control over how Robinhood Chain is run.\nUnder the AEP terms, chains that settle outside Arbitrum One and Arbitrum Nova retain full control of their own governance, sequencer policy, fee parameters, upgrades, and day-to-day operations. There is explicitly no requirement to submit to shared governance with the DAO. The relationship is a licensing / revenue-share arrangement: the chain uses the Arbitrum technology stack and, in return, contributes 10% of net protocol revenue (8% to the DAO treasury, 2% to the Developer Guild).\nIn short, ARB tokenholders benefit economically from the success of chains like Robinhood Chain through the treasury, but they do not hold operational or constitutional authority over those chains.\nThis design prioritizes scalable economic alignment and growth while keeping the DAO focused on Arbitrum One, Nova, the core protocol, and treasury stewardship. Whether additional transparency measures (e.g., standardized public dashboards of AEP inflows by chain) would be valuable as this revenue line grows is an open and worthwhile discussion for the community.\n\n post by Arbit1 on Sep 27\n\n Arbit1\n\nOne small correction, ARB tokenholders DO NOT directly benefit economically from the success of chains as there isn’t any value accrual mechanism providing direct value to the token or tokenholders. With the SEC releasing guidance on Friday regarding staking and buybacks not making tokens a security, it is really up to the Arbitrum Aligned Entities (Offchain, Entropy, Foundation, etc.) to put forward a proposal to implement a value accrual mechanism.\nThe regulatory concerns there once was has been lifted now or reduced by the SECs announcement.\n\n post by Arb_Junior on Sep 27\n\n Arb_Junior\n\n Thank you for the correction — this is an important and accurate distinction.\nYou’re right: there is currently no direct value-accrual mechanism (such as buybacks, burns, staking rewards, or distributions) that automatically channels treasury revenue to ARB tokenholders or the token itself. The 8% AEP share (along with other protocol revenue) flows into the ArbitrumDAO treasury, which is governed by ARB holders. Any economic benefit to tokenholders is therefore indirect and depends on how the DAO chooses to deploy those funds through governance.\nI should have been more precise in my earlier wording. The more accurate framing is that ARB tokenholders benefit through governance control over a growing treasury rather than through any automatic or direct economic claim on the revenue.\nOn the regulatory point you raised: the recent SEC staff FAQs (issued September 25) do appear to reduce prior uncertainty around buybacks and certain staking structures on functional networks. As you noted, this potentially opens the door for Arbitrum Aligned Entities or community members to put forward proposals exploring formal value-accrual mechanisms, should the DAO wish to pursue them.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n ArbitrumDAO Factsheet: Robinhood Chain Testnet Launches on Arbitrum\n\n Announcements\n\n 0\n\n 216\n\n Feb 11\n\n The Arbitrum Foundation H1 2026 Progress Update\n\n Announcements\n\n 0\n\n 245\n\n Sep 2\n\n Proposal: Distribution of DAO Revenue to ARB Token Holders\n\n Archived Proposals\n\n 100\n\n 15.0k\n\n Apr 2024\n\n Follow Up – DAO Income Sources and The Path to Staking\n\n ARDC Research Member\n\n 8\n\n 1.1k\n\n Sep 2024\n\n Arbitrum Treasury and Sustainability Research\n\n General\n\n 14\n\n 4.3k\n\n Jan 2024","tokens":2531,"squid":"spider-07","role":"Council Spider","at":1791343738597,"hash":"85a29cc17f02362422214510d76a56fad8ca1b2f"}
{"url":"https://akash.network/current-groups/wg-provider-attributes/","domain":"akash.network","title":"Provider Attributes Working Group - Community Groups","text":"Back\n Steering Committee Steering Committee Special Interest Groups Analytics Special Interest Group Chain Special Interest Group Clients Special Interest Group Community Special Interest Group Deployments Special Interest Group Design Special Interest Group Documentation Special Interest Group Economics Special Interest Group Education Providers Special Interest Group Support Special Interest Group Working Groups Akash Hackathon Working Group Akash Website Akash Youtube Client Libraries Working Group Content Moderation Working Group Economics 2.0 2023 Events - Working Group GPU Working Group Provider Attributes Working Group Provider Audit Working Group Testnets Working Group Zealy Provider Attributes Working Group This working group is for figuring out the schema for how providers specify attributes and for maintaining a list of required and optional provider attributes that can be referenced by Akash Network providers. \nView on Discord\n\nView on GitHub\n\nSubscribe to Calendar\n Akash Network Provider Attributes Working Group\nThis working group is for figuring out the schema for how providers specify attributes and for maintaining a list of required and optional provider attributes that can be referenced by Akash Network providers.\nMeetings\nJoining the mailing list for the group will typically add invites for the following meetings to your calendar.\n\nMeeting 1 (e.g bug Scrub): <weekday> at <time> PT (Pacific Time) (every <n> weeks). Convert to your timezone (add link to https://dateful.com/time-zone-converter?t=09:00&tz=PT%20%28Pacific%20Time%29).\n\nMeeting notes and Agenda.\nMeeting recordings.\n\nMeeting 2: <weekday> at <time> PT (Pacific Time) (every <n> weeks). Convert to your timezone (add link to https://dateful.com/time-zone-converter?t=09:00&tz=PT%20%28Pacific%20Time%29).\n\nMeeting notes and Agenda.\nMeeting recordings.\n\nRegular WG Meeting: <weekday> at <time> PT (Pacific Time) (biweekly). Convert to your timezone (add link to https://dateful.com/time-zone-converter?t=09:00&tz=PT%20%28Pacific%20Time%29).\n\nMeeting notes and Agenda.\nMeeting recordings.\n\nLeads\n\nMaxime Beauchamp (@baktun14)\n\nContacts\n\n@baktun14\n\nGoals\n\nDecide on provider attribute schema\nDocument key attibutes including features, capabilities, hostname and location\nFigure out communication and roll out strategy to update existing providers\nMake code changes to provider code, clients and deployment code to enforce and use the attribute schema\n\nPRDs and other documentation\nThe implementation of the provider attribute schema currently resides here:\n\nhttps://github.com/ovrclk/cloudmos-config/blob/main/provider-attributes.md\nhttps://github.com/ovrclk/cloudmos-config/blob/main/provider-attributes.json\n\nA form to use this schema has been implemented on Cloudmos in the providers section: https://deploy.cloudmos.io/providers\nRelated SIGs\n\nsig-provider\nsig-clients\nsig-deployments\n GPU Working Group Provider Audit Working Group","tokens":733,"squid":"spider-03","role":"Compute Spider","at":1791343745047,"hash":"467d8b2fa33ba359dd19ac0c1e2e794fad69d856"}
{"url":"https://developer.arbitrum.io/how-arbitrum-works/deep-dives/transaction-lifecycle","domain":"developer.arbitrum.io","title":"Transaction lifecycle on Arbitrum","text":"Transaction lifecycle on ArbitrumLearn how transactions are submitted and processed on Arbitrum, including sequencer and non-sequencer pathways.Request an updateYou can submit transactions to 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 decides that. On , Priority Gas Auctions (PGA) order transactions by the each one pays, so the fee you attach matters more than the route you choose. Other chains may run 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, , 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 signingHow is this guide?Child to Parent chain MessagingLearn the fundamentals of child to parent chain messaging on Arbitrum.Sequencer transaction flowA deep dive into how the Sequencer processes transactions end-to-end: the transaction queue, ordering, block creation timing, and the sequencer feed.","tokens":1325,"squid":"spider-01","role":"Chain Spider","at":1791343748035,"hash":"f0f91799878ab274eafafd18ccd7895dd4bf34ae"}
{"url":"https://forum.arbitrum.foundation/t/arbitrumdao-factsheet-robinhood-chain-testnet-launches-on-arbitrum/30551/1","domain":"forum.arbitrum.foundation","title":"ArbitrumDAO Factsheet: Robinhood Chain Testnet Launches on Arbitrum - Announcements - Arbitrum","text":"The Arbitrum Foundation notified the Security Council on the need to perform a potential Emergency action. Following a review of the details and known risks, the Security Council decided to execute the upgrade and it was completed at 11:30 EST on 2nd October 2026.\nThis report provides an overview of the risks that required the Security Council Action:\n\nAdd a permissionless guard for the One-Step Proof of BoLD on Arbitrum One\n\nTemporarily pause activation of new Stylus contracts on Arbitrum One & Nova\n\nKey point: To date, known bugs for Stylus primarily impact chain liveness (e.g., denial of service attacks) and do not put any user funds at risk.\nWhy was this action taken\nLet’s take this opportunity to explain why action was taken on two separate issues concerning BoLD and Stylus.\nInstalling the guard for One-Step Proof of BoLD. Given the rise of AI-assisted attacks, we have implemented a precautionary approach that allows anyone to pause settlement of Arbitrum One on Ethereum if there are at least two conflicting answers that pass at the same level in which only one should be valid and pass. This is to halt a class of publicly verifiable and detectable attacks that exploit a bug in the one-step proof. If halted, Arbitrum One will continue to process as normal except that messages from Arbitrum One to Ethereum, such as withdrawals, that are not yet confirmed will have to wait. This provides time for the Security Council to deploy a fix for the bug and resume the rollup.\nPreventing activation of new Stylus contracts. AI-assisted tooling has led to an increasing number of sophisticated attacks on hand-crafted WASM programs that do not use the standard Stylus compiler toolchain. These programs are specifically designed to cause unexpected behaviors such as degrading the chain’s performance for all other users. To date, no attacks have been discovered that permits theft of user funds.\nNew ArbOS releases have patched several reported bugs and known attacks over the past few months, but out of an abundance of caution, we have decided to temporarily pause new activations of Stylus contracts. This was executed as an emergency action to prevent the deployment of new hand-crafted WASM programs that are not yet patched by the current version of ArbOS on the Arbitrum network.\nThe Arbitrum Foundation has informed the Security Council that they will work with the ArbitrumDAO to discuss next steps on the timeline and manner for enabling activation of new Stylus contracts. The Arbitrum community remains confident in the value of Stylus and want to preserve these use cases while taking preventative measures against Stylus-based attack vectors as AI-assisted attack tooling continues to evolve.\nImpact on builders and users\n\nNo new activations. New Stylus contracts cannot be activated during the pause including new versions of existing applications that require activation.\n\nExisting contracts are not paused. Already-active Stylus contracts continue to execute until expiration. This pause does not deactivate them.\n\nThe ArbOS 61 upgrade renewed all active contracts on Arbitrum One, so no currently active contract expires before August 20, 2027.\n\nRenewal via keepalive stays permissionless and is unaffected by the pause.\n\nReactivating an expired contract, or one that needs to be updated after a Stylus version change, is paused.\n\nUsing/calling any activated Stylus contract stays permissionless for all users and developers.\n\nNo impact on EVM. Solidity (EVM) contract deployment and execution are unaffected by this Security Council action.\n\nSecurity Council Actions\nThere are two actions bundled into a single payload:\n\nOne-Step Proof Guard. The L1UpgradeExecutor gives a new pause contract (PauseExecutor) the ability to pause and nothing else. The new pause contract grants the guard (OspSoundnessGuard) PAUSER_ROLE to use it. Anyone can show the guard two conflicting answers to the same step of an open challenge. If the one-step proof accepts both, the guard has the pause contract put Arbitrum One’s settlement to Ethereum on hold.\n\nStylus deactivation. The Security Council called ArbOwner.setWasmActivationGas(2^64 - 1) to raise the Stylus activation gas requirement on Arbitrum One and Nova. This makes activation prohibitively expensive and effectively disables new activations. This is a configuration change and does not require an ArbOS upgrade.\n\nThe Security Council signed the following transactions to update the configuration:\n\nEthereum: Ethereum Transaction Hash: 0x30732bb7d2... | Etherscan\nArbitrum One:\nArbitrum One Transaction Hash: 0x9eb3a4be3b... | Arbitrum One\nArbitrum Nova:\nArbitrum Nova transaction 0x79e0fed470dff7a22059b108e3f8f42eddd2b580a6771594060c4e7326c5f984 | Blockscout\n\nAn external audit was conducted for the OSP Guard contracts. No audit is required for the Stylus deactivation as it is only updating a single parameter in the ArbOS configuration.\n\n ArbitrumDAO Factsheet: Robinhood Chain Testnet Launches on Arbitrum \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 10\n\n Feb 11\n\n post by Arbitrum on Feb 11\n\n Arbitrum\n\n ArbitrumDAO Factsheet: Robinhood Chain Testnet Launches on Arbitrum\n\nRobinhood Chain public testnet is live on the Arbitrum platform - a dedicated Ethereum Layer 2 ahead of mainnet later in 2026\nRobinhood Chain testnet validates Arbitrum’s phased infrastructure model: launch on shared rails, validate demand, then deploy a dedicated chain\nRobinhood is also committing $1m to the 2026 Arbitrum Open House programme: four global buildathons and two in-person Founder Houses.\n\nWhat happened\nRobinhood Chain testnet is live.\nThe launch follows Robinhood’s deployment of Stock Tokens on Arbitrum One - over 2,000 tokens linked to US stocks and ETPs, available to EU customers, including exposure to private companies like OpenAI and SpaceX. The testnet marks the next phase in a deliberate infrastructure progression: validate product-market fit on shared production rails, then deploy a purpose-built chain.\nDevelopers can now connect wallets, request testnet ETH and simulated Stock Tokens (including Tesla, Amazon, Palantir, Netflix and AMD), deploy Solidity contracts and bridge test assets into the Robinhood Chain environment.\nWhy this matters\nAnother institutional deployment on Arbitrum rails.\nRobinhood joins BlackRock (BUIDL), Franklin Templeton (BENJI) and Ethena (USDe) in selecting the Arbitrum platform for production financial infrastructure. Each deployment strengthens network effects that competitors cannot replicate - deep liquidity, institutional-grade tooling and a proven migration pathway from shared to sovereign infrastructure.\nPartner-funded builder investment.\nRobinhood’s $1M Open House commitment helps to fund four online buildathons (New York, Dubai, London, Singapore) and two in-person Founder Houses (New York, London). Capital from institutional partners flowing directly into developer acquisition accelerates ecosystem growth beyond Foundation resources alone.\nThe Arbitrum app-to-chain model in action.\nRobinhood started on Arbitrum One with immediate access to deep liquidity and production-grade infrastructure. Now they are deploying a dedicated chain with blockspace designed specifically for tokenised financial assets. That progression - shared infrastructure to sovereign chain - is native to Arbitrum’s architecture. When Robinhood migrates, the ArbitrumDAO receives a 10% protocol revenue share of onchain transaction fees. Every dedicated chain deployment compounds the economic engine.\nGet involved\nBuild on Robinhood Chain testnet at robinhood.com/chain - read the developer docs, connect a wallet, request testnet ETH and start deploying contracts.\nApply (or refer builders) for the Open House programme at openhouse.arbitrum.io for buildathon access and mentorship.\nResources\n\nArbitrum X Post: https://x.com/arbitrum/status/2021404363340775474\nRobinhood X Post: https://x.com/RobinhoodApp/status/2021399303722258575\nRobinhood Chain Portal: robinhood.com/chain\nOpen House Programme: openhouse.arbitrum.io\nArbitrum Announcement Blog: Robinhood Chain Launches Testnet on Arbitrum, Commits $1M to Jumpstart Developer Ecosystem\nRobinhood Announcement Blog: Robinhood Chain Launches Public Testnet\nDeveloper Docs: https://docs.robinhood.com/chain/\nTestnet Faucet: https://faucet.testnet.chain.robinhood.com/\n\n 34th GRC Call - Recording & Transcript\n\n 35th GRC Call - Recording & Transcript\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n ArbitrumDAO Factsheet: Robinhood Chain Mainnet Launch\n\n Announcements\n\n 5\n\n 972\n\n 10d\n\n The Arbitrum Foundation H1 2026 Progress Update\n\n Announcements\n\n 0\n\n 245\n\n Sep 2\n\n The Arbitrum Foundation 2025 Transparency Report: The Year of Institutional Adoption\n\n Announcements\n\n 0\n\n 259\n\n Mar 17\n\n Arbitrum Institutional Strategy Program - Capitalizing on Ethereum Institutional Launch & OpCo Advancements\n\n Early Idea Discussion\n\n 4\n\n 113\n\n Jul 5\n\n Temperature Check: Change Arbitrum Expansion Program to allow deployments of new Orbit chains on any blockchain\n\n Finalized AIPs\n\n 45\n\n 3.0k\n\n Aug 2024","tokens":2298,"squid":"spider-07","role":"Council Spider","at":1791343748664,"hash":"8c5db9a8287ab3a27a447da73c4136ff30fbce2a"}
{"url":"https://akash.network/current-groups/sig-education/","domain":"akash.network","title":"Education - Community Groups","text":"Back\n Steering Committee Steering Committee Special Interest Groups Analytics Special Interest Group Chain Special Interest Group Clients Special Interest Group Community Special Interest Group Deployments Special Interest Group Design Special Interest Group Documentation Special Interest Group Economics Special Interest Group Education Providers Special Interest Group Support Special Interest Group Working Groups Akash Hackathon Working Group Akash Website Akash Youtube Client Libraries Working Group Content Moderation Working Group Economics 2.0 2023 Events - Working Group GPU Working Group Provider Attributes Working Group Provider Audit Working Group Testnets Working Group Zealy Education This SIG (Special Interest Group) is focused on all efforts related to educating users about all things Akash. Sig-education is tasked with finding subjects for educational content, as well as creating a wide range of content to be distributed to the Akash community. \nView on Discord\n\nView on GitHub\n\nSubscribe to Calendar\n Akash Network - Education Special Interest Group (SIG)\nThis SIG (Special Interest Group) is focused on all efforts related to educating users about all things Akash. Sig-education is tasked with finding subjects for educational content, as well as creating a wide range of content to be distributed to the Akash community.\nMeetings\nSecond Tuesday of the month at 10:00 AM PT (Pacific Time)\n\nMeetingTimeNotesTranscriptRecording#1Tuesday, February 14, 2023 10:00 AM PT (Pacific Time)LinkLinkComing soon#2Tuesday, March 14, 2023 10:00 AM PT (Pacific Time)LinkLinkComing soon#3Tuesday, April 11, 2023 10:00 AM PT (Pacific Time)LinkLinkComing soon\nLeadership\n\nAdam Wozney, Overclock Labs\n\nContact\n\nDiscord Server\n\nSub Projects, Repositories & Relevant Work Groups\nThe following are projects and work-groups that sig-education participates in or contributes to: Economics Special Interest Group Providers Special Interest Group","tokens":487,"squid":"spider-03","role":"Compute Spider","at":1791343754812,"hash":"12cb6a4c006b8ed8577937946b4839ce3ef793ca"}
{"url":"https://developer.arbitrum.io/how-arbitrum-works/timeboost/gentle-introduction","domain":"developer.arbitrum.io","title":"How Timeboost works","text":"How Timeboost worksLearn how Timeboost works and how it can benefit your Arbitrum-based project.Request an update is a novel for Arbitrum chains that enables chain owners to capture the Maximal Extractable Value (MEV) on their chain, reduce spam, and preserve fast block times, all while protecting users from harmful types of MEV, such as sandwich attacks and front-running.\nTimeboost is the culmination of over a year of research and development by the team at Offchain Labs. It is currently live on Arbitrum One and Arbitrum Nova, and is available for Arbitrum chains, whose owners can adopt and customize it as they choose.\nWhy do Arbitrum chains need Timeboost?\nIn the past, Arbitrum chains ordered incoming transactions on a basis. This ordering policy is simple to understand and implement, enabling fast block times (starting at 250ms and down to 100ms if desired), and protecting users from harmful types of MEV, such as front-running & sandwich attacks.\nHowever, there are a few downsides to an FCFS ordering policy. Under FCFS, searchers have incentives to participate in and attempt to win latency races by investing in offchain hardware. This \"race\" means that for searchers on Arbitrum chains, generating a profit from arbitrage and liquidation opportunities involves a lot of spam, placing stress on the chain infrastructure and contributing to congestion. Additionally, all captured MEV on an Arbitrum chain under FCFS is allocated to searchers, returning none of the available MEV to the chain owner or the applications on the chain.\nWhat is Timeboost\nTimeboost retains most FCFS benefits while addressing FCFS limitations.\nTimeboost is a transaction ordering policy. It's a set of rules that the sequencer of an Arbitrum chain is trusted to follow when ordering transactions submitted by users. In the near future, multiple sequencers will be able to enforce those rules with decentralized Timeboost.\nFor Arbitrum chains, the sequencer’s sole job is to take arriving, valid transactions from users, place them into an order dictated by the transaction ordering policy, and then publish the final sequence to a real-time feed and in compressed batches to the chain’s data availability layer. Before Timeboost, the transaction ordering policy was FCFS, and Timeboost is a modified FCFS ordering policy.\nTimeboost preserves the great UX that Arbitrum chains are known for\n\nThe default block time for Arbitrum chains continues to be industry-leading at 250ms, even with Timeboost. With Timeboost, some transactions not in the express lane may experience a delay to the next block.\n\nWith Timeboost, Arbitrum chains will continue to protect users from harmful types of MEV\n\nTimeboost only grants the auction winner a temporary time advantage—not the power to view or reorder incoming transactions or to be the first in every block. Furthermore, the transactions' mempool will continue to be private, which means users with Timeboost enabled will remain protected from harmful MEV-like front-running and sandwich attacks.\n\nTimeboost unlocks a new value accrual path for chain owners\n\nChain owners may use Timeboost to capture a portion of the available MEV on their chain that would have otherwise gone entirely to searchers. There are many flavors of this, too—including custom gas tokens and/or redistribution of these proceeds back to the applications and users on the chain.\n\nTimeboost may help reduce spam and congestion on a network\n\nBy introducing the ability to “purchase a time advantage” through the Timeboost auction, it is expected that rational, profit-seeking actors will spend on auctions instead of investing in hardware or infrastructure to win latency races. We expect that this diversion of resources will reduce FCFS MEV-driven spam on the network.\n\nHow does it work?\nTimeboost uses three separate components that work together:\n\nA special “express lane” which allows valid transactions to be sequenced as soon as the sequencer receives them for a given round.\nAn offchain auction to determine the controller of the express lane for a given round. This auction gets managed by an .\nAn deployed on the target chain to serve as the canonical source of truth for the auction results and handling of auction proceeds.\n\nTo start, the default duration of a round is 60 seconds. Transactions not in the express lane will be subject to a default 200-millisecond artificial delay in their arrival timestamp before being sequenced, which means that some non-express lane transactions may be delayed to the next block. It’s important to note that the default Arbitrum block time will remain at 250 milliseconds (which can be adjusted to 100 milliseconds if desired). Let’s dive into how each of these components works.\nThe express lane\n\nThe express lane implementation uses a special endpoint on the sequencer, formally titled timeboost_sendExpressLaneTransaction. This endpoint is special because transactions submitted to it will be sequenced immediately by the sequencer, hence the name \"express lane.\" The sequencer will only accept valid transaction payloads to this endpoint if they are signed correctly by the current round’s .\nTransactions submitted to the sequencer normally will be considered non-express lane transactions and will, therefore, have their arrival timestamp delayed by 200 milliseconds. It is important to note that transactions from both the express and non-express lanes will eventually get sequenced into a single, ordered stream of transactions for the sequencer to post to a data availability layer (and for node operations to construct the chain's state then). The express lane controller does not:\n\nHave the right to reorder transactions.\nHave a guarantee that their transactions will always be first at the “top-of-the-block.”\nGuarantee a profit at all.\n\nThe value of the express lane will be the sum of how much MEV the express lane controller predicts they can extract during the upcoming round (i.e., MEV opportunity estimates made before the auction closes) plus the amount of MEV extracted by the express lane controller while they are in control (that they otherwise did not predict). Understanding how the value of the express lane is determined can be useful for chain owners when adjusting to the artificial delay and the time before the auction closes.\nThe Timeboost auction\nDetermining control of the express lane in each round (default: 60 seconds) happens by a per-round auction, which is a sealed-bid, second-price auction. This auction occurs to determine the express lane controller for the next round. In other words, determining the express lane controller can happen at any point in time in the previous auction round. Bids for the auction can be made with any ERC-20 token, in any amount, and can be collected by any address—at the full discretion of the chain owner.\n\nThe auction for a round has a closing time that is auctionClosingSeconds (default: 15) seconds before the beginning of the round. This closing time means that, in the default parameters, parties have 45 seconds to submit bids before the auction will no longer accept bids. In the 15 seconds between when bidding is over and when the new round begins, the autonomous auctioneer will verify all bids, determine the winner, and make a call to the onchain auction contract to formally resolve the auction.\nBid behaviorThe autonomous auctioneer will consider only an address’s most recent bid, meaning that if you have placed a bid and wish to change it, you may resubmit a bid to “update it.” To cancel a bid, place a new bid that is significantly lower than your original bid or bid below the minimum reserve price. Remember that there is a maximum of five bids per round per address to mitigate DDoS risks.\nAuction contract\nBefore placing a bid in the auction, a party must deposit funds into the Auction Contract. At any time, you can make a deposit or add additional funds to an existing deposit. These deposits are fully withdrawable, with a nominal delay (two rounds or two minutes by default), to prevent impacting the outcome of an existing round. There is no minimum deposit amount, but a starting minimum bid of 0.001 WETH (the default amount and token) is required, known as the \"minimum reserve price\".\nThe chain owner sets the minimum reserve price, which can be updated at any time up to 30 seconds (default) before the start of the next round, ensuring that auction participants always know the reserve price at least 30 seconds before they must submit their bids. A reserve price can also be set by the chain owner (or by an address designated by the chain owner) as a way to raise the minimum bid, as the Auction Contract enforces that the reserve price is never less than the minimum reserve price.\nOnce the autonomous auctioneer determines an auction winner, the Auction contract will deduct the second-highest bid amount from the account of the highest bidder and transfer those funds to a beneficiary account designated by the chain owner by default. The expressLaneControllerAddress specified in the highest bid will become the express lane controller for the round.\nAdditional FAQsFor frequently asked questions refer to the Timeboost FAQ.How is this guide?Use TimeboostLearn how to use timeboost","tokens":2314,"squid":"spider-01","role":"Chain Spider","at":1791343757956,"hash":"2cace150574ca73c13ddf49194eb62ccf6cc9c91"}
{"url":"https://akash.network/current-groups/wg-testnet-sandbox/","domain":"akash.network","title":"Testnets Working Group - Community Groups","text":"Back\n Steering Committee Steering Committee Special Interest Groups Analytics Special Interest Group Chain Special Interest Group Clients Special Interest Group Community Special Interest Group Deployments Special Interest Group Design Special Interest Group Documentation Special Interest Group Economics Special Interest Group Education Providers Special Interest Group Support Special Interest Group Working Groups Akash Hackathon Working Group Akash Website Akash Youtube Client Libraries Working Group Content Moderation Working Group Economics 2.0 2023 Events - Working Group GPU Working Group Provider Attributes Working Group Provider Audit Working Group Testnets Working Group Zealy Testnets Working Group This working group is dedicated to figuring out Akash Network's strategy with testnets and sandbox environments as well as defining the work necessary to create and maintain them \nView on Discord\n\nView on GitHub\n\nSubscribe to Calendar\n Akash Network - Testnets & Sandbox Environments Working Group\nThis working group is dedicated to figuring out Akash Network’s strategy with testnets and sandbox environments as well as defining the work necessary to create and maintain them\nMeetings\nJoining the mailing list for the group will typically add invites for the following meetings to your calendar.\n\nMeeting 1 (e.g bug Scrub): <weekday> at <time> PT (Pacific Time) (every <n> weeks). Convert to your timezone (add link to https://dateful.com/time-zone-converter?t=09:00&tz=PT%20%28Pacific%20Time%29).\n\nMeeting notes and Agenda.\nMeeting recordings.\n\nMeeting 2: <weekday> at <time> PT (Pacific Time) (every <n> weeks). Convert to your timezone (add link to https://dateful.com/time-zone-converter?t=09:00&tz=PT%20%28Pacific%20Time%29).\n\nMeeting notes and Agenda.\nMeeting recordings.\n\nRegular WG Meeting: <weekday> at <time> PT (Pacific Time) (biweekly). Convert to your timezone (add link to https://dateful.com/time-zone-converter?t=09:00&tz=PT%20%28Pacific%20Time%29).\n\nMeeting notes and Agenda.\nMeeting recordings.\n\nLeads\n\nName (GH Handle)\nName (GH Handle)\n\nContacts\n\nDiscord (add link)\nMail list (add link)\n\nGoals\n\nbulletted list\nof goals for this WG\n\nPRDs and other documentation\n\nPRD\n\nRelated SIGs\n\nsig-provider\nsig-clients\nsig-deployments\n Provider Audit Working Group Zealy","tokens":573,"squid":"spider-03","role":"Compute Spider","at":1791343776547,"hash":"14204e3b7491bba5354607839b64ef18be829aa3"}
{"url":"https://forum.arbitrum.foundation/t/the-arbitrumdao-code-of-conduct/30792/1","domain":"forum.arbitrum.foundation","title":"The ArbitrumDAO Code of Conduct - Announcements - Arbitrum","text":"The Arbitrum Foundation notified the Security Council on the need to perform a potential Emergency action. Following a review of the details and known risks, the Security Council decided to execute the upgrade and it was completed at 11:30 EST on 2nd October 2026.\nThis report provides an overview of the risks that required the Security Council Action:\n\nAdd a permissionless guard for the One-Step Proof of BoLD on Arbitrum One\n\nTemporarily pause activation of new Stylus contracts on Arbitrum One & Nova\n\nKey point: To date, known bugs for Stylus primarily impact chain liveness (e.g., denial of service attacks) and do not put any user funds at risk.\nWhy was this action taken\nLet’s take this opportunity to explain why action was taken on two separate issues concerning BoLD and Stylus.\nInstalling the guard for One-Step Proof of BoLD. Given the rise of AI-assisted attacks, we have implemented a precautionary approach that allows anyone to pause settlement of Arbitrum One on Ethereum if there are at least two conflicting answers that pass at the same level in which only one should be valid and pass. This is to halt a class of publicly verifiable and detectable attacks that exploit a bug in the one-step proof. If halted, Arbitrum One will continue to process as normal except that messages from Arbitrum One to Ethereum, such as withdrawals, that are not yet confirmed will have to wait. This provides time for the Security Council to deploy a fix for the bug and resume the rollup.\nPreventing activation of new Stylus contracts. AI-assisted tooling has led to an increasing number of sophisticated attacks on hand-crafted WASM programs that do not use the standard Stylus compiler toolchain. These programs are specifically designed to cause unexpected behaviors such as degrading the chain’s performance for all other users. To date, no attacks have been discovered that permits theft of user funds.\nNew ArbOS releases have patched several reported bugs and known attacks over the past few months, but out of an abundance of caution, we have decided to temporarily pause new activations of Stylus contracts. This was executed as an emergency action to prevent the deployment of new hand-crafted WASM programs that are not yet patched by the current version of ArbOS on the Arbitrum network.\nThe Arbitrum Foundation has informed the Security Council that they will work with the ArbitrumDAO to discuss next steps on the timeline and manner for enabling activation of new Stylus contracts. The Arbitrum community remains confident in the value of Stylus and want to preserve these use cases while taking preventative measures against Stylus-based attack vectors as AI-assisted attack tooling continues to evolve.\nImpact on builders and users\n\nNo new activations. New Stylus contracts cannot be activated during the pause including new versions of existing applications that require activation.\n\nExisting contracts are not paused. Already-active Stylus contracts continue to execute until expiration. This pause does not deactivate them.\n\nThe ArbOS 61 upgrade renewed all active contracts on Arbitrum One, so no currently active contract expires before August 20, 2027.\n\nRenewal via keepalive stays permissionless and is unaffected by the pause.\n\nReactivating an expired contract, or one that needs to be updated after a Stylus version change, is paused.\n\nUsing/calling any activated Stylus contract stays permissionless for all users and developers.\n\nNo impact on EVM. Solidity (EVM) contract deployment and execution are unaffected by this Security Council action.\n\nSecurity Council Actions\nThere are two actions bundled into a single payload:\n\nOne-Step Proof Guard. The L1UpgradeExecutor gives a new pause contract (PauseExecutor) the ability to pause and nothing else. The new pause contract grants the guard (OspSoundnessGuard) PAUSER_ROLE to use it. Anyone can show the guard two conflicting answers to the same step of an open challenge. If the one-step proof accepts both, the guard has the pause contract put Arbitrum One’s settlement to Ethereum on hold.\n\nStylus deactivation. The Security Council called ArbOwner.setWasmActivationGas(2^64 - 1) to raise the Stylus activation gas requirement on Arbitrum One and Nova. This makes activation prohibitively expensive and effectively disables new activations. This is a configuration change and does not require an ArbOS upgrade.\n\nThe Security Council signed the following transactions to update the configuration:\n\nEthereum: Ethereum Transaction Hash: 0x30732bb7d2... | Etherscan\nArbitrum One:\nArbitrum One Transaction Hash: 0x9eb3a4be3b... | Arbitrum One\nArbitrum Nova:\nArbitrum Nova transaction 0x79e0fed470dff7a22059b108e3f8f42eddd2b580a6771594060c4e7326c5f984 | Blockscout\n\nAn external audit was conducted for the OSP Guard contracts. No audit is required for the Stylus deactivation as it is only updating a single parameter in the ArbOS configuration.\n\n The ArbitrumDAO Code of Conduct \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 16\n\n post by OpCo on Apr 16\n\n OpCo\n\n Below you’ll find ArbitrumDAO’s Code of Conduct, approved through the governance process on April 2, 2026. For more historical context, scroll to the bottom.\nValues Alignment\nArbitrum contributors should always strive to uphold the seven community values stated in Section 6:\n\nEthereum-aligned: Arbitrum is part of the Ethereum ecosystem and community\n\nSustainable: Focus on long-term health of the protocol over short-term gains\n\nSecure: Arbitrum is security-minded\n\nSocially inclusive: Open and welcoming to all constructive participants\n\nTechnically inclusive: Accessible for ordinary people with ordinary technology\n\nUser-focused: Managed for the benefit of all users\n\nNeutral and open: Foster open innovation, interoperability, user choice, and healthy competition\n\nGood Faith and Best Interest\n\nContributors should conduct themselves with honesty, integrity, and transparency, fostering trust and confidence among community members.\n\nContributors should act and vote in accordance with what they see is in the best interests of Arbitrum, which encompasses but is not limited to all of the following: Arbitrum One, Arbitrum Nova, the Orbit Ecosystem, and any future Arbitrum DAO-governed chains as outlined in Section 1 of the Arbitrum Constitution.\n\nDue Care and Attention\n\nContributors should remain knowledgeable of developments in regard to Arbitrum DAO’s initiatives and the broader Arbitrum ecosystem.\n\nContributors should strive to make a professional and unbiased review of each proposal before submitting their vote.\n\nContributors are advised to vote abstain when unable to conduct the necessary diligence to understand the proposals.\n\nCivility and Professionalism\n\nWhile separate from the Code of Conduct, contributors are expected to uphold the community guidelines for activity on the Arbitrum DAO forum and de facto understood gathering places for the Arbitrum DAO, whether online or in-person.\n\nContributors should seek to create a respectful and inclusive environment for all community members, free from harassment and discrimination.\n\nUnacceptable behavior includes, but is not limited to:\n\nPublicly or privately harassing or intimidating others\n\nSharing someone’s private information without their consent\n\nUsing sexualized language or imagery, or making unwanted advances\n\nMaking insulting or derogatory comments about others\n\nContributors should strive to provide constructive feedback that is well-researched and respectful, focusing on the proposal’s merits. Personal attacks are never acceptable.\n\nContributors should be open-minded and respectful of differing viewpoints, even if they disagree with them. Disagreements are an inevitable part of healthy debate, but they often yield positive results when approached in a civil manner.\n\nContributors should make a best effort to provide constructive feedback through appropriate channels and avoid taking discussions to social media in a manner that could tarnish Arbitrum DAO’s brand and reputation.\n\nContributors should avoid making unsubstantiated accusations that imply malice without proper evidence. They should conduct proper due diligence before making any public accusations via social media, public forums, or any other recognized communication channels. This includes exhausting all available avenues, such as seeking clarification privately, before issuing any public statement that contains an unsubstantiated accusation about another DAO contributor.\n\nResponsibility\n\nMaintaining a culture of productive debate, integrity, and transparency requires a sense of collective responsibility. As entrusted leaders of the Arbitrum community, contributors should take responsibility in fostering and maintaining a culture that promotes the principles outlined herein.\n\nBest practices of responsible contributors:\n\nParticipation: Contributors should make an effort to vote (even if they vote abstain) on all proposals.\n\nCommunication: Contributors should clearly communicate their rationale behind votes and discussions to the Arbitrum community.\n\nAccountability: Contributors should maintain knowledge of all DAO initiatives and hold managing parties or elected representatives accountable.\n\nResponsiveness: Contributors should use their best efforts to connect with the Arbitrum community and be accessible to answer questions or concerns.\n\nConflicts of Interest\nDisclosure and Transparency Policy: If a conflict of interest exists, it is expected that the contributor discloses the nature and extent of the conflict in writing on the forum before voting. Proposal authors should disclose potential conflicts in the COI section of the recommended proposal template as outlined in the “How to Submit a DAO Proposal” by the Arbitrum Foundation. While it may not always be clear if an individual/entity stands to gain “directly” or “indirectly”, contributors and proposal authors are recommended to lean on the side of over-communication in the name of transparency.\nContributors who disclose a conflict of interest are not expected to alter their voting in any way. Self-voting is not currently banned outright for the reasons stated in previous DAO-wide discussions and based on sentiment gathered from a subsequent temperature check. However, a contributor who repeatedly fails to disclose a conflict of interest before voting risks being removed from their compensated governance role.\nAI tools and responsible participation in the ArbitrumDAO\nThe use of AI tools to automate administrative tasks, overcome language barriers, or process and summarize large blocks of information is expected. That said, the ArbitrumDAO discourages the irresponsible use of AI agents that may lead to the forum being littered with comments that do little to add value to the conversation.\nGoing forward, moderators of the forum (currently the Arbitrum Foundation and OpCo) will proactively monitor for comments that are off-topic or irrelevant to the main discussion, with the aim of mitigating the irresponsible use of AI agents. Moderators may use a variety of tools to assist their review, but moderation decisions will be based on the quality, relevance and intention of the contribution rather than solely on whether it appears to have been AI-generated. Repeat infractions will lead to suspension or, in severe cases, user deletion.\nModerators retain discretion to remove content that undermines productive governance discussions. Where appropriate, moderators may redirect off-topic discussions to a more suitable venue rather than removing them or message the author with similar suggestions. Enforcement will generally follow a graduated process:\n\nRemoval or redirection of the relevant content, with an explanation where practical.\nA formal warning for repeated low-quality or disruptive contributions.\nTemporary suspension for continued violations following a warning.\nLonger suspensions or permanent removal from the forum in cases of persistent abuse, automated spam campaigns, or other serious or repeated violations.\n\nCommunity members are encouraged to flag content they believe is off-topic, repetitive or otherwise inconsistent with these guidelines. Moderators will review flagged content on a case-by-case basis.\nEnforcement & Appeal Process\nAll contributors are expected to abide by the Code of Conduct. Enforcement will take place through any program that financially compensates performing governance activities, such as rewards for voting/forum activity, or participation in DAO-approved programs where contributors are directly elected to facilitate the programs.\nThe program manager, council, or comparable facilitator in charge of the program is the one responsible for determining violations of the Code of Conduct and reserves the right to take what it deems as appropriate action, which may include but is not limited to, issuing a warning, suspension, or removal from the program. Any community member can raise a concern to the party responsible for managing the program with respect to a contributor failing to uphold the Code of Conduct. While the responsible party is required to acknowledge receipt of the concern and investigate the matter, the final determination and resulting course of action, which may include dismissing the concern, will depend on the underlying program’s structure.\nIf there are contradictions between the Code of Conduct and the specific program that is compensating a contributor, then the policies of the program shall take precedence. It is assumed that a program will define its own appeal process, but if it does not, then the conflict resolution section (next) will be the default appeal approach.\nConflict Resolution\nResolution of conflicts between contributors (and between contributors and programs) will be entrusted to the OpCo, which will act as a neutral mediator. It is recommended that contributors first seek to resolve conflict issues in good faith and privately. If the matter is unable to be resolved for any reason, or if the behavior is threatening or harassing, the matter can be raised to the OpCo. The OpCo will have the final say on the issue and reserves the right to determine if the issue should be brought to the attention of the community as a whole.\n\n If you want to submit a request for support in resolving a conflict, please do so through this form.\n\nImportant Terms\nContributor: An individual or entity who willingly engages in Arbitrum governance and/or is compensated via a DAO-approved program.\nDAO-approved program: A structured initiative that is funded and/or authorized by the Arbitrum DAO through a formal governance vote (Tally or Snapshot) and designed to achieve defined objectives. Examples include the Arbitrum Audit Program, the Arbitrum D.A.O. Grant Program, and other comparable initiatives that receive DAO treasury funding or delegated authority.\nCommunity Guidelines: The rules of engagement for the Arbitrum DAO forum as outlined and enforced by the Arbitrum Foundation.\nConflict of Interest (COI): A situation where a contributor, or any entity with which a contributor has a direct professional or financial relationship, stands to directly benefit from the outcome of a proposal or election.\n\nHistorical Context\nThe previous version of the Code of Conduct was voted for a trial period that was set to expire on January 31st, 2026. There was a stipulation that enabled the Arbitrum Foundation to extend the trial period by an additional 2 months. During that extension, the Arbitrum Foundation, Entropy Advisors and OpCo worked on gathering feedback from delegates, considered and made some amendments, and put a new version of the Code of Conduct forward through the governance process. The vote passed successfully and as of April 2026, the OpCo has assumed the responsibility for stewarding the Code of Conduct of the ArbitrumDAO.\nOn July 6th, 2026, the OpCo proposed an amendment to the Code of Conduct, adding language around the responsible use of AI tools in the participation of delegates and contributors in the ArbitrumDAO.\nThe amendment was optimistically approved 14 days later, in accordance with the ‘Feedback and Review Process’ outlined in the Code of Conduct itself.\nPast Versions\nThe above is the third amendment of the Code of Conduct and is now under the stewardship of the OpCo. You can find previous, now deprecated, versions in the links below.\n1st Code of Conduct\n2nd Code of Conduct\n\nFeedback and Review Process\nWith the Code of Conduct existing as living documents, the OpCo will serve as the steward of the documents and is responsible for maintaining them over time. Changes can be proposed and adopted through the following process:\nFeedback and Observation. Any contributor may propose amendments by submitting feedback through a dedicated channel maintained by OpCo (for example a forum thread or dedicated google form). OpCo may also identify necessary changes based on its own observations of governance activity, enforcement gaps, or evolving DAO needs.\nDrafting and Posting. When OpCo determines that a change is warranted, it will draft the proposed amendment and post it to the governance forum with a clear description of what is being changed and why.\nOptimistic Approval. Proposed changes take effect automatically 14 days after being posted to the forum unless a combined 5% of DVP, calculated at the time of the forum post, raises objections through the appropriate governance forum amendment thread. This threshold, currently ~16.75M VP, is high enough to prevent trivial escalations from slowing down maintenance-type updates, but low enough that a coalition of small-medium sized delegates can trigger a vote on changes they consider substantive. The 14-day window is intended to give delegates sufficient time to review the proposed changes and OpCo will be responsible for monitoring objections and tallying the VP delegates.\n\nEscalation to an Offchain Vote. If sufficient VP raises an objection to the changes, the OpCo must then put the change to an offchain vote with a quorum set at the active non-constitutional quorum level.\n\nAnnual Review. In addition to the ongoing amendment process, OpCo will conduct a review of the Code of Conduct and DAO Procedures each January, soliciting community feedback and proposing any updates deemed necessary. This review serves as a regular checkpoint but does not preclude amendments at other times of the year.\n\n Proposed Amendment to the Code of Conduct: AI tools and Responsible Participation Policy\n\n Oversight and Transparency Committee (OAT) - June 2026 Elections Overview\n\n read \n\n 5\n min\n\n Pinned on Apr 16\n\n Closed 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 The Arbitrum DAO Code of Conduct\n\n Archived Announcements\n\n 0\n\n 272\n\n Jul 2025\n\n [Deprecated] The Arbitrum DAO Delegate Code of Conduct\n\n Archive\n\n 1\n\n 428\n\n May 2025\n\n Terms and Conditions of RAD\n\n Rewarding Active Delegates Program (RAD)\n\n 0\n\n 156\n\n Dec 2025\n\n [Non-Constitutional] Arbitrum DAO Delegate Code of Conduct + Formalizing the DAO’s Operations\n\n Finalized AIPs\n\n 85\n\n 2.4k\n\n Jun 2025\n\n Proposed Amendment to the Code of Conduct: AI tools and Responsible Participation Policy\n\n Finalized AIPs\n\n 4\n\n 123\n\n Jul 20","tokens":4838,"squid":"spider-07","role":"Council Spider","at":1791343780963,"hash":"a8fb147d1dfa74ff05b7a9971649edc2c3abd54f"}
{"url":"https://www.metaplex.com/docs/dev-tools/cli/config/rpcs","domain":"metaplex.com","title":"RPCs | Metaplex CLI","text":"Manage RPC endpoints in your configuration. You can add, list, remove, and set active RPCs for different networks.Basic Usage# Add a new RPC endpoint\nmplx config rpcs add <name> <endpoint>\n\n# List all RPC endpoints\nmplx config rpcs list\n\n# Remove an RPC endpoint\nmplx config rpcs remove <name>\n\n# Set active RPC endpoint\nmplx config rpcs set <name>\nCommandsAdd RPCAdd a new RPC endpoint to your configuration.mplx config rpcs add <name> <endpoint>\nArgumentsArgumentDescriptionnameA unique name for the RPC endpoint (e.g., 'mainnet', 'devnet')endpointThe RPC endpoint URLExamplemplx config rpcs add mainnet https://api.mainnet-beta.solana.com\nList RPCsDisplay all configured RPC endpoints.mplx config rpcs list\nOutput--------------------------------\nRPC Endpoints\n--------------------------------\nName: mainnet\nEndpoint: https://api.mainnet-beta.solana.com\nActive: true\n\nName: devnet\nEndpoint: https://api.devnet.solana.com\nActive: false\n--------------------------------\nRemove RPCRemove an RPC endpoint from your configuration.mplx config rpcs remove <name>\nArgumentsArgumentDescriptionnameThe name of the RPC endpoint to removeExamplemplx config rpcs remove devnet\nSet Active RPCSet the active RPC endpoint for your configuration.mplx config rpcs set <name>\nArgumentsArgumentDescriptionnameThe name of the RPC endpoint to set as activeExamplemplx config rpcs set mainnet\nConfiguration FileRPCs are stored in your configuration file at ~/.mplx/config.json:{\n \"rpcs\": {\n \"mainnet\": {\n \"endpoint\": \"https://api.mainnet-beta.solana.com\",\n \"active\": true\n },\n \"devnet\": {\n \"endpoint\": \"https://api.devnet.solana.com\",\n \"active\": false\n }\n }\n}\nNotesRPC names are case-sensitiveOnly one RPC can be active at a timeThe active RPC is used for all network operationsYou can add multiple RPCs for different networksRemoving the active RPC will automatically set another RPC as active if availableRelated CommandsWallets - Manage wallet configurationsExplorer - Set preferred blockchain explorer","tokens":496,"squid":"dotcat","role":"Tooling Spider","at":1791343781009,"hash":"99592eb2bf2e643c72accb3220cc8b97b2b338e6"}
{"url":"https://akash.network/current-groups/wg-zealy/","domain":"akash.network","title":"Zealy - Community Groups","text":"Back\n Steering Committee Steering Committee Special Interest Groups Analytics Special Interest Group Chain Special Interest Group Clients Special Interest Group Community Special Interest Group Deployments Special Interest Group Design Special Interest Group Documentation Special Interest Group Economics Special Interest Group Education Providers Special Interest Group Support Special Interest Group Working Groups Akash Hackathon Working Group Akash Website Akash Youtube Client Libraries Working Group Content Moderation Working Group Economics 2.0 2023 Events - Working Group GPU Working Group Provider Attributes Working Group Provider Audit Working Group Testnets Working Group Zealy Zealy This working group is to launch an Akash account on Zealy (formerly Crew3.xyz), a community builder platform. The aim of this group is to increase awareness about Akash in gamify form, and create tasks for the community based on their skill level. e.g influencer, developer, provider, content creator etc.The working group is created to work on the proposal to see what support is needed, outline the goals and forecast outcome, decide on the user rewards, points, ladder system and time. Based on this metrics, we will be able to see the full picture and the success of the program. \nView on Discord\n\nView on GitHub\n\nSubscribe to Calendar\n Akash Network Zealy Working Group\nThis working group is to launch an Akash account on Zealy (formerly Crew3.xyz), a community builder platform. The aim of this group is to increase awareness about Akash in gamify form, and create tasks for the community based on their skill level. e.g influencer, developer, provider, content creator etc.\nThe working group is created to work on the proposal to see what support is needed, outline the goals and forecast outcome, decide on the user rewards, points, ladder system and time. Based on this metrics, we will be able to see the full picture and the success of the program.\nMeetings\n\nMeetingTimeNotesTranscriptRecording#1Friday, February 17, 2023 08:30 AM PT (Pacific Time)LinkLinkcoming soon#2Monday, November 20, 2023 08:30 AM PT (Pacific Time)LinkLinkLink#3Monday, November 27, 2023 08:30 AM PT (Pacific Time)LinkLinkLink#4Monday, December 04, 2023 06:30 AM PT (Pacific Time)LinkLinkLink#5Monday, December 11, 2023 06:30 AM PT (Pacific Time)LinkLinkLink#6Monday, December 18, 2023 06:30 AM PT (Pacific Time)LinkLinkLink#7Monday, January 15, 2024 06:30 AM PT (Pacific Time)coming sooncoming soonComing soon#8Monday, January 22, 2024 06:30 AM PT (Pacific Time)LinkLinkLink#9Monday, February 12, 2024 06:30 AM PT (Pacific Time)LinkLinkComing Soon#10Monday, March 18, 2024 06:30 AM PT (Pacific Time)LinkLinkComing Soon#11Monday, April 15, 2024 06:30 AM PT (Pacific Time)LinkLinkLink#12Monday, April 29, 2024 06:30 AM PT (Pacific Time)LinkLinkLink#13Monday, August 12, 2024 06:30 AM PT (Pacific Time)LinkLinkLink#14Monday, August 19, 2024 06:30 AM PT (Pacific Time)LinkLinkLink#15Monday, August 26, 2024 06:30 AM PT (Pacific Time)LinkLinkLink#16Monday, September 09, 2024 06:30 AM PT (Pacific Time)LinkLinkLink#17Monday, September 30, 2024 06:30 AM PT (Pacific Time)LinkLinkLink#18Monday, October 07, 2024 06:30 AM PT (Pacific Time)LinkLinkLink\nLeads\n\nPiber Dev\nRobert Del Rey\n\nContacts\n\nDiscord\n\nPRDs and other documentation\n\nPRD\n\nRelated SIGs\n\ncommunity/sig-community\n Testnets Working Group","tokens":844,"squid":"spider-03","role":"Compute Spider","at":1791343788166,"hash":"034f37deb2cd3d880b0295371000b35e02e53476"}
{"url":"https://www.metaplex.com/docs/dev-tools/cli/installation","domain":"metaplex.com","title":"Installation | Metaplex CLI","text":"This guide will help you install and set up the Metaplex CLI on your system.PrerequisitesBefore installing the CLI, ensure you have:Node.js 16.x or laternpm 7.x or laterA Solana wallet (optional, but recommended)Git (optional, for development)Installation MethodsUsing npm (Recommended)npm install -g @metaplex-foundation/cli\nUsing yarnyarn global add @metaplex-foundation/cli\nUsing pnpmpnpm add -g @metaplex-foundation/cli\nVerify InstallationAfter installation, verify that the CLI is properly installed:mplx --version\nYou should see the current version of the CLI displayed.Initial Setup1. Create Configuration DirectoryThe CLI will automatically create a configuration file at ~/.config/mplx when first setting config settings. This config stores:Wallet configurationsRPC endpoint settingsExplorer preferencesOther CLI settings2. Configure Your EnvironmentSet up a Wallet# Create a new wallet\nmplx config wallets new --name dev1\n\n# Or add an existing wallet\nmplx config wallets add <name> <path>\nmplx config wallets add dev1 /path/to/keypair.json\n\n# After adding a wallet you'll need to set it\nmplx config wallets set\nFurther reading seeConfigure RPC Endpointmplx config set rpcUrl https://api.mainnet-beta.solana.com\nSet Preferred Explorermplx config explorer set\nDevelopment InstallationIf you want to contribute to the CLI or run it from source:Clone the repository:git clone https://github.com/metaplex-foundation/cli.git\ncd cli\nInstall dependencies:npm install\nBuild the project:npm run build\nLink the CLI:npm link\nTroubleshootingCommon IssuesCommand Not FoundEnsure the global npm bin directory is in your PATHTry reinstalling the packagePermission ErrorsUse sudo for global installation on Unix-based systemsOr configure npm to install global packages without sudoNode Version IssuesUse nvm to manage Node.js versionsEnsure you're using a compatible Node.js versionGetting HelpIf you encounter any issues:Check the documentationSearch GitHub issuesJoin the Discord communityNext StepsNow that you have the CLI installed, you can:Learn about the core commandsExplore the toolbox utilitiesConfigure your environmentUpdatingTo update the CLI to the latest version:npm update -g @metaplex-foundation/cli\nOr if you installed via yarn:yarn global upgrade @metaplex-foundation/cli\nUninstallationTo remove the CLI:npm uninstall -g @metaplex-foundation/cli\nOr if you installed via yarn:yarn global remove @metaplex-foundation/cli","tokens":608,"squid":"dotcat","role":"Tooling Spider","at":1791343790960,"hash":"b36709a542fe436596f6223838660506bcab9327"}
{"url":"https://forum.across.to/t/across-community-integration-campaign/1516","domain":"forum.across.to","title":"Across Community Integration Campaign - Proposals / Passed Proposals - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n Across Community Integration Campaign \n\n ProposalsPassed Proposals\n\n treasury-funding\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 5\n min\n\n Feb 2023\n\n 1 / 18\n\n Feb 2023\n\n Feb 2023\n\n post by Britt on Feb 8, 2023\n\n Britt\n\n Header\nTitle: Community Integration Campaign\nAuthor(s): Britt and EAsports\nStatus: Vote\nRelated Discussions: N/A\nSubmission Date: 02/08/2023\nBody\nSummary:\nThis proposal allocates $15k (in ACX) for bounties to community members who can bring value to Across by facilitating integrations between Across and the ecosystem we belong to.\nMotivation:\nAcross is the most capital-efficient bridge, which we believe will help us win and gain further adoption in the long term. However, in the short term, we are experiencing a brand awareness deficit compared to our competitors in the space. By utilizing the expertise, bandwidth, and networks of the community to seek out partnerships and integrations in the L2 ecosystem, we aim to accomplish more connections, awareness, and integrations to tackle this opportunity more aggressively.\nSpecification & Implementation:\nWe are recommending a bounty program to reward community contributors who successfully establish an integration for Across. The value of the bounty will be based on both the type of integration and the amount of visibility it will bring to the protocol.\nIntegration types (and multipliers):\n\nTechnical: Across is integrated into another protocol’s UI as a bridging option for that protocol’s users. (3x)\nListing: Across is listed as a preferred bridging option on a resource page. (1x)\nMarketing/social: Across partners with a protocol to put out partnership content such as a podcast, video, article, Twitter space, etc. (1.5x)\nCampaigns: Across co-sponsors a campaign or quest that results in users trying the product and exposes other communities to Across. (2x)\n\nVisibility:\nFor the purposes of this bounty, visibility will be defined as the number of Twitter Followers another protocol has.\nBounty Calculation:\nThe value of each successful bounty will be calculated by this formula:\nReward = 0.5 ACX * multiplier * Visibility\nEligible Protocols:\nAny protocol that operates on Arbitrum, Optimism, Polygon, or zkSync is eligible, but we’d like to really see an emphasis on protocols that either tap into new demographics for awareness or that could help drive direct volume through Across. We’ll maintain a list that includes preferred partnerships that we’d like to see, as well as partnerships that are already in progress. It’s encouraged, but not required, for you to double-check with us in Discord before setting off to tackle an integration in order to avoid spamming potential partners with integration requests. We want to see folks working together rather than competing for these bounties, so please be respectful if it appears that someone is already in active discussions with a potential partner.\nEvaluation:\nAnyone may submit a complete bounty for evaluation in the comment section of this proposal on Forum or in the growth forum in discord (which will be set up after passing this approval). When you do so, you’ll need to demonstrate that the integration was the consequence of your actions (documented conversations, links to proposals, etc.). Submissions will be reviewed on a community call (scheduled as needed), where anyone can object to their validity. If a consensus isn’t reached on the call, Risk Labs will be the decider.\nDistribution:\nThe Treasury will distribute the ACX tokens to recipients as bounties are validated. This will continue until $15k in ACX has been reached, at which point the program will be evaluated to determine if continuing with subsequent rounds is valuable.\nRationale:\nThis is an experiment in lightweight bounty programs to see if this is a good model for mobilizing the community without too many barriers to entry. Capping the program at $15k to start is an easy way to minimize the downside of this program while also giving it a chance to succeed. The bounty calculation is a way to standardize the value of each integration according to the potential amount of exposure it will give the protocol and the amount of work required for each integration type. Having submissions be reviewed optimistically on a community call is meant to give the community the opportunity to be responsible for accepting these bounties.\nDownside (Cons):\nUsing Twitter followers is not a perfect proxy for visibility, and it’s possible that a contributor may be over or under-compensated for their efforts. The qualification criteria are also a bit subjective, meaning it’s not a perfect system.\nVoting:\nA “yes” vote will earmark 250,000 ACX to be used for this bounty program. It will be distributed as bounties are validated. A “no” vote will reject the use of these funds for this bounty program. You can vote on this now on snapshot.\n\n 5\n\n 2\n\n 2\n\n read \n\n 5\n min\n\n post by TheRealTuna_Across on Feb 8, 2023\n\n post by PVMihalache on Feb 8, 2023\n\n post by Sabotage on Feb 8, 2023\n\n post by Sabotage on Feb 9, 2023\n\n post by Clayton_UMA on Feb 9, 2023\n\n post by caesarsherrod.eth on Feb 9, 2023\n\n post by Britt on Feb 9, 2023\n\n post by Britt on Feb 9, 2023\n\n post by Britt on Feb 9, 2023\n\n post by BecauseofAlice on Feb 9, 2023\n\n post by caesarsherrod.eth on Feb 9, 2023\n\n post by neondaemon on Feb 11, 2023\n\n post by nithin_shylendra on Feb 13, 2023\n\n post by Britt on Feb 13, 2023\n\n post by mydefi on Feb 13, 2023\n\n post by Saludiego201 on Feb 13, 2023\n\n post by 99066.bnb on Feb 15, 2023\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Community Integration Campaign 2.0\n\n Active Proposals\n\n Active Proposals\n\n 5\n\n Nov 2023\n\n Across Token Launch Proposal v2\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 47\n\n Nov 2022\n\n Across Token Launch Proposal\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 214\n\n May 2022\n\n Integration and Utilization Campaign for Across with Latin America’s Largest X-to-Earn Community\n\n Ideas & Feedback\n\n volume,awareness\n\n Ideas & Feedback\n\n Jul 2024\n\n # Across Community Essentials Committee Renewal Proposal for Q2-Q3 2025\n\n Committees\n\n Committees\n\n 4\n\n Mar 2025","tokens":3037,"squid":"spider-09","role":"Bridge Spider","at":1791343793032,"hash":"302b0f9edc828445be08faafb09bbdcbd5453e0d"}
{"url":"https://akash.network/current-groups/wg-client-libraries/","domain":"akash.network","title":"Client Libraries Working Group - Community Groups","text":"Back\n Steering Committee Steering Committee Special Interest Groups Analytics Special Interest Group Chain Special Interest Group Clients Special Interest Group Community Special Interest Group Deployments Special Interest Group Design Special Interest Group Documentation Special Interest Group Economics Special Interest Group Education Providers Special Interest Group Support Special Interest Group Working Groups Akash Hackathon Working Group Akash Website Akash Youtube Client Libraries Working Group Content Moderation Working Group Economics 2.0 2023 Events - Working Group GPU Working Group Provider Attributes Working Group Provider Audit Working Group Testnets Working Group Zealy Client Libraries Working Group This working group is responsible for the design, implementation, testing and documentation of the client libraries to interact with the Akash Network. \nView on Discord\n\nView on GitHub\n\nSubscribe to Calendar\n Akash Network Client Libraries Working Group\nThis working group is responsible for the design, implementation, testing and documentation of the client libraries to interact with the Akash Network.\nMeetings\nTuesday February 7, 2023 01:00 PM PT (Pacific Time)\n\nMeetingTimeNotesTranscriptRecording#1Tuesday, February 7, 2023 1:00 PM PT (Pacific Time)LinkLinkLink\nLeads\n\nJoão Luna (@cloud-j-luna)\nAnil Murty, Overclock Labs\n\nContacts\n\nDiscord\n\nGoals\n\nDefine the common interface across the different implementations\nImplement the clients in the following popular technologies: Java, Go, Python, C#, Javascript\nIdentify limitations on the Cosmos SDK and design solutions to achieve performant clients\nCreate documentation on the libraries’ APIs\n\nPRDs and other documentation\n\nClient Libraries Spec\n\nRelated SIGs\n\nsig-clients\nsig-deployments\n Akash Youtube Content Moderation Working Group","tokens":454,"squid":"spider-03","role":"Compute Spider","at":1791343798095,"hash":"4cc79ce1334bcd48608c73d1c48bcd5892c69cde"}
{"url":"https://www.metaplex.com/docs/dev-tools/cli","domain":"metaplex.com","title":"Introduction | Metaplex CLI","text":"Metaplex CLIThe Metaplex CLI is a powerful command-line tool that provides a comprehensive suite of utilities for interacting with the Metaplex protocol on Solana. Whether you're a developer building NFT applications or a creator managing digital assets, the CLI offers a robust set of features to streamline your workflow.Key FeaturesCore FunctionalityCreate and manage MPL Core Assets and CollectionsUpload and update asset metadataFetch asset and collection informationManage asset properties and attributesCandy Machine SupportCreate MPL Core Candy Machines with step-by-step guidanceUpload, validate, and insert assets with intelligent cachingSet up complex minting rules and guard groupsReal-time indicators for uploads, creation, and deploymentToolbox UtilitiesCreate and manage fungible tokensTransfer SOL between addressesCheck SOL balancesAirdrop SOL for testing purposesConfiguration ManagementManage multiple walletsConfigure RPC endpointsSet preferred blockchain explorerCustomize CLI behaviorWhy Use the CLI?Developer-Friendly: Built with developers in mind, offering both simple commands and advanced optionsInteractive Mode: User-friendly wizards for complex operationsFlexible Configuration: Customize your environment with multiple wallets and RPC endpointsComprehensive Tools: Everything you need for NFT and token management in one placeCross-Platform: Works on Windows, macOS, and LinuxGetting StartedInstall the CLIConfigure your environment:Set up your walletConfigure RPC endpointsChoose your preferred explorerStart using the commands:Create assetsCreate collectionsCommand StructureThe CLI follows a hierarchical command structure:mplx <category> <command> [options]\nCategories include:core: MPL Core asset managementcm: Candy Machine operationsdistro: MPL-Distro create, deposit, fetch, and withdrawtoolbox: Utility commandsconfig: Configuration managementBest PracticesUse Configuration: Set up your wallets and RPC endpoints for a smoother experienceInteractive Mode: Use the --wizard flag for guided operationsCheck Balances: Always verify your SOL balance before transactionsTest First: Use devnet for testing before mainnet deploymentBackup: Keep your wallet files and configuration secureSupport and ResourcesGitHub RepositoryDocumentationDiscord CommunityQuick Start ExamplesCreate Your First Candy MachineGet started with the interactive wizard:# Install and configure the CLI\nmplx config set keypair /path/to/my-wallet.json\nmplx config set rpcUrl https://api.mainnet-beta.solana.com\n\n# Create a candy machine with guided setup\nmplx cm create --wizard\nCreate Individual AssetsFor single assets or custom collections:# Create a collection\nmplx core create-collection\n\n# Create an asset in the collection\nmplx core create-asset\nNext StepsReady to get started? Choose your path:For Setup: Visit the installation guideFor NFT Collections: Start with the candy machine wizardFor Individual Assets: Begin with asset creation","tokens":738,"squid":"dotcat","role":"Tooling Spider","at":1791343800980,"hash":"63c497939a7349f8298856072b27e5641e1443bc"}
{"url":"https://akash.network/current-groups/wg-provider-audit/","domain":"akash.network","title":"Provider Audit Working Group - Community Groups","text":"Back\n Steering Committee Steering Committee Special Interest Groups Analytics Special Interest Group Chain Special Interest Group Clients Special Interest Group Community Special Interest Group Deployments Special Interest Group Design Special Interest Group Documentation Special Interest Group Economics Special Interest Group Education Providers Special Interest Group Support Special Interest Group Working Groups Akash Hackathon Working Group Akash Website Akash Youtube Client Libraries Working Group Content Moderation Working Group Economics 2.0 2023 Events - Working Group GPU Working Group Provider Attributes Working Group Provider Audit Working Group Testnets Working Group Zealy Provider Audit Working Group This working group is for defining any specifications and scope of code changes for making it easy to monitor providers. Note that this working group does not deal with provider analytics but is considered with pure monitoring of the infrastructure (for improved uptime, SLA and such) \nView on Discord\n\nView on GitHub\n\nSubscribe to Calendar\n Akash Network Provider Audit Working Group\nThis working group is for developing an open source auditor tool for providers. The Pi3 team requested funds for building this open source tool, which passed on chain\nMeetings\n3rd Wednesday of Every Month\n\nMeetingTimeNotesTranscriptRecording#1Wed, Feb 21, 2024 10:00 AM PT (Pacific Time)LinkLinkComing Soon#2Wed, May 1st, 2024 09:00 AM PT (Pacific Time)No meetingNo meetingNo Meeting#3Thursday, June 13, 2024 10:00 AM PT (Pacific Time)LinkLinkLink#4Wed, July 17, 2024 10:00 AM PT (Pacific Time)\nContacts\n\nDiscord\n\nGoals\n\nPi3 is looking to contribute to the Cloudmos indexer to expand their tasks to include examples such as: benchmarking, testing RPC nodes, tracking the lease uptime of providers, and other trackable metrics to include in their API. We would also want snapshots of this database to be made semi-regularly, if there is demand for this.\n\nPi3 Team is looking to create our own open source services:\n\nStat-based, tier-based auditing service, where filtering API can be used on Cloudmos & signing can happen for CLI users. Example on the filtering this would allow.\nGeneral auditing, where we can have a general audit similar to how Overclock Labs sign their providers, and how Moultrie Audits signed providers. We create a set of criteria that we think are “good enough,” and sign generally from this.\nKYC-based auditing on providers and tenants. Details for this are TBD and to do the KYC, we would be working with companies that do this as a service.\nYet another Akash Stats Page, if there is demand for one. In the past weeks, some questions have not been able to be responded to due to data not being formatted in such a way.\nTo our knowledge, this relates to: rich lists as a pie graph, the community pool growth over time, and provider filtering shown as a demo here.\n\nPRDs and other documentation\n\nProposal 242\n\nRelated SIGs\n\nsig-provider\n Provider Attributes Working Group Testnets Working Group","tokens":756,"squid":"spider-03","role":"Compute Spider","at":1791343808114,"hash":"cadbdfe9b951048e2d4de73e5e3575359e1bdf94"}
{"url":"https://forum.across.to/t/across-community-integration-campaign/1516/18","domain":"forum.across.to","title":"Across Community Integration Campaign - Proposals / Passed Proposals - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n ProposalsPassed Proposals\n\n treasury-funding\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 5\n min\n\n Feb 2023\n\n 18 / 18\n\n Feb 2023\n\n Feb 2023\n\n post by Britt on Feb 8, 2023\n\n post by TheRealTuna_Across on Feb 8, 2023\n\n post by PVMihalache on Feb 8, 2023\n\n post by Sabotage on Feb 8, 2023\n\n post by Sabotage on Feb 9, 2023\n\n post by Clayton_UMA on Feb 9, 2023\n\n post by caesarsherrod.eth on Feb 9, 2023\n\n post by Britt on Feb 9, 2023\n\n post by Britt on Feb 9, 2023\n\n post by Britt on Feb 9, 2023\n\n post by BecauseofAlice on Feb 9, 2023\n\n post by caesarsherrod.eth on Feb 9, 2023\n\n post by neondaemon on Feb 11, 2023\n\n post by nithin_shylendra on Feb 13, 2023\n\n nithin_shylendra\n\n I think this would be a good starting point to get the community work going especially with the much needed growth and marketing side of things, would quests like Crew3 be considered for this campaign? @Britt @EAsports\n\n post by Britt on Feb 13, 2023\n\n Britt\n\n imo yes, it should be. I think navigating those integrations is an interesting example of where this will be a learning experience because it’s not clear to me what resources will be required to get it off the ground and to maintain it. It will probably be a case-by-case basis on whether these ones work out or not. But I think it’s very much worth trying, and I’m hopeful that we’ll see some good traction here.\n\n post by mydefi on Feb 13, 2023\n\n mydefi\n\n Not much to say here other than that I support this proposal and think it would be a good incentive to encourage more integration.\n\n post by Saludiego201 on Feb 13, 2023\n\n Saludiego201\n\n nithin_shylendra\n\n Hey honestly I think it’s a great idea quest for creew3 or layer3 could really reach a lot of people that across.to has not reached.\nMy question is, is this closed to protocols only? or can apps also enter, say apps with access to and interactions in WEB3?\n\n post by 99066.bnb on Feb 15, 2023\n\n 99066.bnb\n\n Yes. I have done all works on across. I’ll stick around. I wish the project to be better. So that I can keep it going.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Community Integration Campaign 2.0\n\n Active Proposals\n\n Active Proposals\n\n 5\n\n Nov 2023\n\n Across Token Launch Proposal v2\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 47\n\n Nov 2022\n\n Across Token Launch Proposal\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 214\n\n May 2022\n\n Integration and Utilization Campaign for Across with Latin America’s Largest X-to-Earn Community\n\n Ideas & Feedback\n\n volume,awareness\n\n Ideas & Feedback\n\n Jul 2024\n\n # Across Community Essentials Committee Renewal Proposal for Q2-Q3 2025\n\n Committees\n\n Committees\n\n 4\n\n Mar 2025","tokens":2165,"squid":"spider-09","role":"Bridge Spider","at":1791343813493,"hash":"0915797e6ea46591c1681669f9511be9bd205e90"}
{"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 post by abcoathup on Jan 4\n\n post by captnbli on Jan 5\n\n post by abcoathup on Jan 5\n\n 27 days later\n\n post by ngrawlings on Feb 2\n\n post by abcoathup on Feb 2\n\n post by brighammurdoch-byte on Feb 3\n\n post by umamimi on Feb 4\n\n 2 months later\n\n post by MicahZoltu on Apr 19\n\n 3 months later\n\n post by frostybucks on Jul 8\n\n 13 days later\n\n post by YulinLiu20 on Jul 21\n\n 28 days later\n\n post by captnbli on Aug 19\n\n post by virgil on Aug 19\n\n Powered by Discourse","tokens":829,"squid":"spider-04","role":"Research Spider","at":1791343819776,"hash":"d6bbc1ee2a94aec335bd696eeca08aa533a485d1"}
{"url":"https://www.metaplex.com/docs/dev-tools/cli/agents","domain":"metaplex.com","title":"Agent Commands Overview | Metaplex CLI","text":"What This CoversThe complete CLI reference for agent identity management:Registration: Create and register agent identities on MPL Core assetsToken linking: Associate Genesis token launches with agent identitiesExecutive delegation: Authorize wallets to act on behalf of registered agentsSummaryThe mplx agents commands let you register agent identities on MPL Core assets, link Genesis tokens, and manage executive delegation — all from your terminal.Tool: Metaplex CLI (mplx) with the agents command groupIdentity: Each agent identity is stored as a PDA derived from an MPL Core assetDelegation: Executives can be authorized to sign transactions on behalf of agentsToken linking: A Genesis token can be permanently linked to an agent identityJump to: Prerequisites · General Flow · Command Reference · Common Errors · FAQ · GlossaryPrerequisitesThe Metaplex CLI installed and on your PATHA Solana keypair file (e.g., ~/.config/solana/id.json)SOL for transaction feesAn RPC endpoint configured via mplx config rpcs add or passed with -rCheck your setup:Check CLImplx agents --help\nGeneral FlowRegister an Agent IdentityUse agents register to create an MPL Core asset and register an agent identity in a single command. By default this uses the Metaplex Agent API — no Irys upload needed.Register an agent (API mode)mplx agents register \\\n --name \"My Agent\" \\\n --description \"An autonomous trading agent\" \\\n --image \"./avatar.png\"\nFor advanced workflows (existing assets, custom documents, interactive wizard), use the --use-ix flag to send the registerIdentityV1 instruction directly. See Register Agent for full details.Link a Genesis TokenAfter registering an agent and creating a Genesis token launch, link them with set-agent-token. This permanently associates the token with the agent identity.Link Genesis token to agentmplx agents set-agent-token <AGENT_ASSET> <GENESIS_ACCOUNT>\nIrreversibleEach agent identity can only ever have one token, and the agent token can only be set once. This action cannot be undone.Set Up Executive DelegationExecutive delegation allows a wallet to sign transactions on behalf of a registered agent:Register an executive profile (one-time per wallet):Register executive profilemplx agents executive register\nDelegate an agent to the executive (run by the asset owner):Delegate executionmplx agents executive delegate <AGENT_ASSET> --executive <EXECUTIVE_WALLET>\nRevoke a delegation (run by either the owner or executive):Revoke delegationmplx agents executive revoke <AGENT_ASSET>\nSee Executive Delegation for full details.Command ReferenceCommandDescriptionagents registerRegister an agent identity on an MPL Core assetagents fetchFetch and display agent identity dataagents set-agent-tokenLink a Genesis token to a registered agentagents executive registerCreate an executive profile for the current walletagents executive delegateAuthorize an executive to act on behalf of an agentagents executive revokeRemove an execution delegationNotesAgent identities are stored as PDAs derived from MPL Core assets via the Agent Registry programThe default registration flow uses the Metaplex Agent API — use --use-ix for direct on-chain registrationset-agent-token requires the wallet to be in asset-signer mode — see Asset-Signer WalletsRun mplx agents <command> --help for full flag documentation on any commandSee the Agent Kit documentation for concepts, architecture, and SDK guidesCommon ErrorsErrorCauseFixNo agent identity foundAsset is not registered as an agentRegister the asset first with agents registerAgent token already setTrying to set the token a second timeAgent token can only be set once per identity — this is irreversibleExecutive profile already existsCalling executive register twice from the same walletEach wallet can only have one executive profile — it's already set upNot the asset ownerTrying to delegate from a non-owner walletOnly the asset owner can delegate executionDelegation not foundRevoking a delegation that doesn't existCheck the agent and executive addresses are correctFAQWhat is the mplx agents command? The mplx agents command group lets you register agent identities on MPL Core assets, link Genesis tokens to agents, and manage executive delegation — all from your terminal.What is an executive profile? An executive profile is a one-time on-chain PDA that allows a wallet to receive execution delegations from registered agents. Once registered, the executive can sign transactions on behalf of delegated agents.Can I register an agent without uploading to Irys? Yes. By default, the register command uses the Metaplex Agent API which handles storage automatically. You only need Irys when using the --use-ix flag for direct on-chain registration.Can an agent token be changed after it is set? No. The agent token can only be set once per identity using the set-agent-token command. This is irreversible.What is the difference between the API and direct IX registration paths? The API path (default) creates a Core asset and registers the identity in a single API call with no Irys upload needed. The direct IX path (--use-ix) sends the registerIdentityV1 instruction directly, which is needed for existing assets, custom document workflows, or the interactive wizard.GlossaryTermDefinitionAgent IdentityAn on-chain PDA derived from an MPL Core asset that stores the agent's registration data, lifecycle hooks, and token associationExecutive ProfileA one-time on-chain PDA for a wallet, required before that wallet can receive execution delegationsExecution DelegationA per-asset link between a registered agent and an executive profile, allowing the executive to sign transactions on behalf of the agentAsset Signer PDAA PDA derived from the Core asset that acts as the agent's built-in wallet — used for set-agent-tokenRegistration DocumentA JSON document containing the agent's name, description, image, services, and trust models — uploaded and stored as the identity URI","tokens":1489,"squid":"dotcat","role":"Tooling Spider","at":1791343821160,"hash":"5d464fc7651fb43b7e887a6ada7c0bceeeed2cbd"}
{"url":"https://forum.across.to/t/community-integration-campaign-2-0/1765","domain":"forum.across.to","title":"Community Integration Campaign 2.0 - Proposals / Active Proposals - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n Community Integration Campaign 2.0 \n\n ProposalsActive Proposals\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n Nov 2023\n\n 1 / 6\n\n Nov 2023\n\n Nov 2023\n\n post by TheRealTuna_Across on Nov 17, 2023\n\n TheRealTuna_Across\n\n Summary:\nThis proposal allocates 150,000 ACX as bounties, to community members who can bring value to Across by facilitating integrations between Across and crypto projects that share a similar vision.\nMotivation:\nAcross is the most capital-efficient bridge, which we believe will help us win and gain further adoption in the long term. However, in the short term, we are experiencing a brand awareness deficit compared to our competitors in the space.\nBy utilizing the expertise, bandwidth, and networks of the community to seek out partnerships and integrations in the L2 ecosystem, we aim to accomplish more connections, awareness, and integrations to tackle this opportunity more aggressively.\nSpecification & Implementation:\nWe are recommending a bounty program to reward community contributors who successfully establish an integration for Across. The value of the bounty will be based on both the type of integration and the amount of visibility it will bring to the protocol.\nBased on the feedback from the previous Community Integration Campaign, the Visibility defined by the raw number of Twitter followers did not reflect a clear benefit for Across.\nIntegration types (and multipliers):\nTechnical: Across is integrated into another protocol’s UI as a bridging option for that protocol’s users. (2x)\nListing: Across is listed as a preferred bridging option on a resource page. (1x)\nMedia Impact (and multipliers):\nFor the purposes of this bounty, Media Impact will still be defined by the number of Twitter Followers another protocol has. The difference from the previous campaign is that the visibility will give a second multiplier.\nUp to 99k followers: 1x\nMore than 100k followers: 1.5x\nACX Loyalty: ACX Holder role on Discord receives 1.1 multiplier on top of Integration Type and Visibility\nBounty Calculation:\nThe value of each successful bounty will be calculated by this formula:\nReward = 10,000 ACX * Integration multiplier * Media Impact multiplier * ACX Loyalty\nThe new budget can cover more integrations, from 4 top ranked integrations to 15 standard integrations\nMin. bounty 10,000 x 1 x 1 x 1 = 10,000 ACX\nMax. bounty 10,000 x 2 x 1.5 x 1.1 = 33,000 ACX\nEligible Protocols:\nAny protocol that operates on Ethereum, Arbitrum, Optimism, Polygon, zkSync, or Base is eligible, but we’d like to really see an emphasis on protocols that either tap into new demographics for awareness or that could help drive direct volume through Across.\nWe’ll maintain a list that includes preferred partnerships that we’d like to see, as well as partnerships that are already in progress.\nIt’s encouraged, but not mandatory, for the community member to double-check with the Across team in Discord before setting off to tackle an integration, in order to avoid spamming potential partners with integration requests.\nWe want to see the community working together rather than competing for these bounties, so please be respectful if it appears that someone is already in active discussions with a potential partner.\nEvaluation:\nAnyone may submit a completed bounty for evaluation in the Discord governance chat. The claim must demonstrate that the integration was the consequence of your actions (documented conversations, links to proposals, emails, etc.).\nSubmissions will be reviewed on a community call (scheduled as needed), where anyone can object to their validity. If a consensus isn’t reached on the call, Risk Labs will be the decider.\nDistribution:\nThe Treasury will distribute the ACX tokens to recipients as bounties are validated. This will continue until the allocated 150,000 ACX has been claimed, at which point the program will be evaluated to determine if continuing with subsequent rounds is valuable. If the funds have not been awarded by 05/01/2024, they will be returned to the DAO by the committee.\nRationale:\nThe initial bounty program was created to mobilize the community without too many barriers to entry. Capping the program at 150,000 ACX was the method used to minimize the downside of this program, while also giving it a chance to succeed.\nThe follow-up integration campaign was modified based on the community feedback, and a new bounty calculation formula was proposed.\nThe bounty calculation is a way to standardize the value of each integration, according to the potential amount of exposure it will give the protocol and the amount of work required for each integration type. The review of submissions on a community call will give the community the opportunity to discuss, show approval or dispute the claim.\nDownside (Cons):\nUsing Twitter followers was not the perfect proxy for visibility, and a multiplier added for the updated proposal may still over or under-compensate. The qualification criteria are also subjective, as a perfect reward system cannot be created.\nVoting:\nThis poll is a temperature check and once we receive feedback from the community we will move to an official snapshot vote.\n\n The “Yes” vote will earmark 150,000 ACX to be used for the bounty program, which will be distributed as bounties are validated. The “No” vote will reject the use of these funds for the bounty program.\n\n 12\n voters\n\n Votes are public.\n\n 2\n\n post by berry4144 on Nov 17, 2023\n\n berry4144\n\n Sounds good to me. One small point is whether we can provide agents with a tool kit to assist their efforts.\n\n post by PVMihalache on Nov 17, 2023\n\n PVMihalache\n\n Me and Tuna will be around to help, and for UI integrations we will need the devs to get involved at one point. The role of the community is to liease and lead to the integration\n\n post by mydefi on Nov 17, 2023\n\n mydefi\n\n berry4144\n\n I agree - I think if we can provide some sort of initial guidance for anyone who requests it, or an example case study, that would be a good start to any person/group looking to participate.\n\n post by Heruvim78 on Nov 20, 2023\n\n Heruvim78\n\n Seems the right thing to do. I support this.\nOh, it seems that we need to write 100 characters now, was this before? He he.\n\n post by PVMihalache on Nov 21, 2023\n\n PVMihalache\n\n Yes! The character requirement was always there. Maybe the previous times you wrote more and you didn’t noticed\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Across Community Integration Campaign\n\n Passed Proposals\n\n treasury-funding\n\n Passed Proposals\n\n 17\n\n Feb 2023\n\n Across Token Launch Proposal v2\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 47\n\n Nov 2022\n\n Integration and Utilization Campaign for Across with Latin America’s Largest X-to-Earn Community\n\n Ideas & Feedback\n\n volume,awareness\n\n Ideas & Feedback\n\n Jul 2024\n\n Across Token Launch Proposal\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 214\n\n May 2022\n\n AcrossAlert Proposal: Amplifying Across’s Excellence on Twitter\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 5\n\n May 2024","tokens":3256,"squid":"spider-09","role":"Bridge Spider","at":1791343823662,"hash":"84279dc2cdce04c3f30f3d437b0628b6129d0fb2"}
{"url":"https://www.metaplex.com/docs/dev-tools/cli/agents/executive","domain":"metaplex.com","title":"Executive Delegation | Metaplex CLI","text":"What You'll DoManage execution delegation for registered agents:Register executive profiles (one-time per wallet)Delegate agent execution to an executive walletRevoke delegations when no longer neededSummaryThe mplx agents executive commands manage execution delegation — authorizing wallets to sign transactions on behalf of registered agents. An executive must register a profile once, then the MPL Core asset owner can delegate execution to them.Register: One-time executive profile creation per walletDelegate: Link a registered agent to an executive (owner only)Revoke: Remove a delegation (owner or executive can revoke)Jump to: Register Executive Profile · Delegate Execution · Revoke Delegation · Common Errors · FAQRegister Executive ProfileThe agents executive register command creates a one-time on-chain executive profile PDA for the current wallet. This profile is required before any agent can be delegated to this wallet.Register executive profilemplx agents executive register\nNo flags or arguments required — the profile is derived from the current signer's wallet.OutputExpected output--------------------------------\n Executive Profile: <profile_pda_address>\n Authority: <wallet_address>\n Signature: <transaction_signature>\n Explorer: <explorer_url>\n--------------------------------\nDelegate ExecutionThe agents executive delegate command links a registered agent to an executive profile, allowing the executive to sign transactions on behalf of the agent. Only the asset owner can delegate execution.Delegate executionmplx agents executive delegate <AGENT_ASSET> --executive <EXECUTIVE_WALLET>\nOptionsFlagDescriptionRequired--executive <string>The executive's wallet address (profile PDA is derived automatically)YesThe executive must have already registered their profile with mplx agents executive register before delegation.OutputExpected output--------------------------------\n Agent Asset: <agent_asset_address>\n Executive Profile: <profile_pda_address>\n Signature: <transaction_signature>\n Explorer: <explorer_url>\n--------------------------------\nRevoke DelegationThe agents executive revoke command removes an execution delegation, closing the delegation record and refunding rent. Either the asset owner or the executive authority can revoke.Revoke delegation (as owner)mplx agents executive revoke <AGENT_ASSET> --executive <EXECUTIVE_WALLET>\nRevoke own delegation (as executive)mplx agents executive revoke <AGENT_ASSET>\nOptionsFlagDescriptionRequiredDefault--executive <string>The executive's wallet addressNoCurrent signer--destination <string>Wallet to receive refunded rentNoCurrent signerOutputExpected output--------------------------------\n Agent Asset: <agent_asset_address>\n Executive Wallet: <executive_wallet_address>\n Signature: <transaction_signature>\n Explorer: <explorer_url>\n--------------------------------\nCommon ErrorsErrorCauseFixExecutive profile already existsCalling register a second timeEach wallet can only have one profile — it's already registeredNot the asset ownerTrying to delegate from a non-owner walletOnly the asset owner can delegate executionExecutive profile not foundDelegating to a wallet that hasn't registeredThe executive must run agents executive register firstDelegation not foundRevoking a delegation that doesn't existVerify the agent asset and executive addressesNotesExecutive profiles are one-time per wallet — registering again will failEach delegation is per-asset: an executive can be delegated multiple agents, but each requires a separate delegate callWhen revoking without --executive, the command defaults to the current signer (for executives revoking their own delegation)Rent from closed delegation records is refunded to the --destination wallet (defaults to the signer)FAQWhat is an executive profile? A one-time on-chain PDA for a wallet that enables it to receive execution delegations from registered agents.Can a wallet have multiple executive profiles? No. Each wallet can only have one executive profile. Registration is a one-time operation.Who can revoke a delegation? Either the asset owner or the executive authority can revoke a delegation. When the executive revokes, --executive can be omitted (defaults to current signer).","tokens":1057,"squid":"dotcat","role":"Tooling Spider","at":1791343831149,"hash":"5b0454715ad58d36d101d20bb6f810ac27c92665"}
{"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 8 years later\n\n post by captnbli on Jan 4\n\n post by abcoathup on Jan 4\n\n post by captnbli on Jan 5\n\n post by abcoathup on Jan 5\n\n 27 days later\n\n post by ngrawlings on Feb 2\n\n post by abcoathup on Feb 2\n\n post by brighammurdoch-byte on Feb 3\n\n post by umamimi on Feb 4\n\n 2 months later\n\n post by MicahZoltu on Apr 19\n\n 3 months later\n\n post by frostybucks on Jul 8\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":559,"squid":"spider-04","role":"Research Spider","at":1791343839957,"hash":"30d104907c979cd885f7c3fa2d5143f4c58b7f7c"}
{"url":"https://forum.across.to/t/community-integration-campaign-2-0/1765/6","domain":"forum.across.to","title":"Community Integration Campaign 2.0 - Proposals / Active Proposals - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n ProposalsActive Proposals\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n Nov 2023\n\n 6 / 6\n\n Nov 2023\n\n Nov 2023\n\n post by TheRealTuna_Across on Nov 17, 2023\n\n TheRealTuna_Across\n\n Summary:\nThis proposal allocates 150,000 ACX as bounties, to community members who can bring value to Across by facilitating integrations between Across and crypto projects that share a similar vision.\nMotivation:\nAcross is the most capital-efficient bridge, which we believe will help us win and gain further adoption in the long term. However, in the short term, we are experiencing a brand awareness deficit compared to our competitors in the space.\nBy utilizing the expertise, bandwidth, and networks of the community to seek out partnerships and integrations in the L2 ecosystem, we aim to accomplish more connections, awareness, and integrations to tackle this opportunity more aggressively.\nSpecification & Implementation:\nWe are recommending a bounty program to reward community contributors who successfully establish an integration for Across. The value of the bounty will be based on both the type of integration and the amount of visibility it will bring to the protocol.\nBased on the feedback from the previous Community Integration Campaign, the Visibility defined by the raw number of Twitter followers did not reflect a clear benefit for Across.\nIntegration types (and multipliers):\nTechnical: Across is integrated into another protocol’s UI as a bridging option for that protocol’s users. (2x)\nListing: Across is listed as a preferred bridging option on a resource page. (1x)\nMedia Impact (and multipliers):\nFor the purposes of this bounty, Media Impact will still be defined by the number of Twitter Followers another protocol has. The difference from the previous campaign is that the visibility will give a second multiplier.\nUp to 99k followers: 1x\nMore than 100k followers: 1.5x\nACX Loyalty: ACX Holder role on Discord receives 1.1 multiplier on top of Integration Type and Visibility\nBounty Calculation:\nThe value of each successful bounty will be calculated by this formula:\nReward = 10,000 ACX * Integration multiplier * Media Impact multiplier * ACX Loyalty\nThe new budget can cover more integrations, from 4 top ranked integrations to 15 standard integrations\nMin. bounty 10,000 x 1 x 1 x 1 = 10,000 ACX\nMax. bounty 10,000 x 2 x 1.5 x 1.1 = 33,000 ACX\nEligible Protocols:\nAny protocol that operates on Ethereum, Arbitrum, Optimism, Polygon, zkSync, or Base is eligible, but we’d like to really see an emphasis on protocols that either tap into new demographics for awareness or that could help drive direct volume through Across.\nWe’ll maintain a list that includes preferred partnerships that we’d like to see, as well as partnerships that are already in progress.\nIt’s encouraged, but not mandatory, for the community member to double-check with the Across team in Discord before setting off to tackle an integration, in order to avoid spamming potential partners with integration requests.\nWe want to see the community working together rather than competing for these bounties, so please be respectful if it appears that someone is already in active discussions with a potential partner.\nEvaluation:\nAnyone may submit a completed bounty for evaluation in the Discord governance chat. The claim must demonstrate that the integration was the consequence of your actions (documented conversations, links to proposals, emails, etc.).\nSubmissions will be reviewed on a community call (scheduled as needed), where anyone can object to their validity. If a consensus isn’t reached on the call, Risk Labs will be the decider.\nDistribution:\nThe Treasury will distribute the ACX tokens to recipients as bounties are validated. This will continue until the allocated 150,000 ACX has been claimed, at which point the program will be evaluated to determine if continuing with subsequent rounds is valuable. If the funds have not been awarded by 05/01/2024, they will be returned to the DAO by the committee.\nRationale:\nThe initial bounty program was created to mobilize the community without too many barriers to entry. Capping the program at 150,000 ACX was the method used to minimize the downside of this program, while also giving it a chance to succeed.\nThe follow-up integration campaign was modified based on the community feedback, and a new bounty calculation formula was proposed.\nThe bounty calculation is a way to standardize the value of each integration, according to the potential amount of exposure it will give the protocol and the amount of work required for each integration type. The review of submissions on a community call will give the community the opportunity to discuss, show approval or dispute the claim.\nDownside (Cons):\nUsing Twitter followers was not the perfect proxy for visibility, and a multiplier added for the updated proposal may still over or under-compensate. The qualification criteria are also subjective, as a perfect reward system cannot be created.\nVoting:\nThis poll is a temperature check and once we receive feedback from the community we will move to an official snapshot vote.\n\n The “Yes” vote will earmark 150,000 ACX to be used for the bounty program, which will be distributed as bounties are validated. The “No” vote will reject the use of these funds for the bounty program.\n\n 12\n voters\n\n Votes are public.\n\n 2\n\n post by berry4144 on Nov 17, 2023\n\n berry4144\n\n Sounds good to me. One small point is whether we can provide agents with a tool kit to assist their efforts.\n\n post by PVMihalache on Nov 17, 2023\n\n PVMihalache\n\n Me and Tuna will be around to help, and for UI integrations we will need the devs to get involved at one point. The role of the community is to liease and lead to the integration\n\n post by mydefi on Nov 17, 2023\n\n mydefi\n\n berry4144\n\n I agree - I think if we can provide some sort of initial guidance for anyone who requests it, or an example case study, that would be a good start to any person/group looking to participate.\n\n post by Heruvim78 on Nov 20, 2023\n\n Heruvim78\n\n Seems the right thing to do. I support this.\nOh, it seems that we need to write 100 characters now, was this before? He he.\n\n post by PVMihalache on Nov 21, 2023\n\n PVMihalache\n\n Yes! The character requirement was always there. Maybe the previous times you wrote more and you didn’t noticed\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Across Community Integration Campaign\n\n Passed Proposals\n\n treasury-funding\n\n Passed Proposals\n\n 17\n\n Feb 2023\n\n Across Token Launch Proposal v2\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 47\n\n Nov 2022\n\n Integration and Utilization Campaign for Across with Latin America’s Largest X-to-Earn Community\n\n Ideas & Feedback\n\n volume,awareness\n\n Ideas & Feedback\n\n Jul 2024\n\n Across Token Launch Proposal\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 214\n\n May 2022\n\n AcrossAlert Proposal: Amplifying Across’s Excellence on Twitter\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 5\n\n May 2024","tokens":3247,"squid":"spider-09","role":"Bridge Spider","at":1791343844096,"hash":"b2240dd2b3c8cffc220ba9086787776f88e49aca"}
{"url":"https://www.metaplex.com/docs/dev-tools/cli/config/asset-signer-wallets","domain":"metaplex.com","title":"Asset-Signer Wallets | Metaplex CLI","text":"SummaryAsset-signer wallets let you use an MPL Core Asset's signer PDA as your active CLI wallet. When active, every CLI command automatically wraps its instructions in the on-chain execute instruction — no custom scripting required.Register any Core Asset as a wallet with mplx config wallets add <name> --asset <assetId>All CLI commands transparently operate through the PDA when the asset-signer wallet is activeThe asset owner signs the execute instruction; a separate fee payer can be specified with -pSome operations are restricted by Solana CPI constraints (large account creation, native SOL wrapping)Quick StartAsset-signer wallet setup# 1. Create an asset (or use an existing one you own)\nmplx core asset create --name \"My Vault\" --uri \"https://example.com/vault\"\n\n# 2. Register it as a wallet (auto-detects the owner from on-chain data)\nmplx config wallets add vault --asset <assetId>\n\n# 3. Check the PDA info\nmplx core asset execute info <assetId>\n\n# 4. Fund the PDA (use the Signer PDA address from step 3, never the asset address)\nmplx toolbox sol transfer 0.1 <signerPdaAddress>\n\n# 5. Switch to the asset-signer wallet\nmplx config wallets set vault\n\n# 6. Use any command as the PDA\nmplx toolbox sol balance\nmplx toolbox sol transfer 0.01 <destination>\nmplx core asset create --name \"PDA Created NFT\" --uri \"https://example.com/nft\"\nHow Asset-Signer Wallets WorkThe CLI uses a noop-signer pattern to make PDA operations transparent. When an asset-signer wallet is active:umi.identity is set to a noop signer with the PDA's public key — commands build instructions with the PDA as authority naturallyumi.payer is also set to the PDA noop signer — so derived addresses (ATAs, token accounts) resolve correctlyAt send time, the transaction is wrapped in MPL Core's execute instruction, which signs on behalf of the PDA on-chainThe real wallet (asset owner) signs the outer transaction and pays fees via setFeePayerRegistering an Asset-Signer WalletAdd asset-signer walletmplx config wallets add <name> --asset <assetId>\nThe --asset flag is what distinguishes this from a normal wallet. The CLI fetches the asset on-chain, determines the owner, and matches it against your saved wallets. If the owner is not in your wallet list, you must add the owner wallet first.Once registered, use the standard wallet commands (list, set, remove) to manage it like any other wallet. Asset-signer wallets display as asset-signer type in the wallet list.The -k flag bypasses the active wallet for a single command, including asset-signer wallets.Separate Fee PayerThe on-chain execute instruction supports separate authority and fee payer accounts. Use -p to have a different wallet pay transaction fees while the asset owner signs the execute:Separate fee payermplx toolbox sol transfer 0.01 <destination> -p /path/to/fee-payer.json\nThe asset owner still signs the execute instruction. The -p wallet only pays the Solana transaction fee.Supported CommandsAll CLI commands work with asset-signer wallets. The transaction wrapping happens transparently in the send layer.CategoryCommandsCoreasset create, asset transfer, asset burn, asset update, collection createToolbox SOLbalance, transfer, wrap, unwrapToolbox Tokentransfer, create, mintToolbox Rawraw --instruction <base64>Token Metadatatransfer, create, updateBubblegumnft create, nft transfer, nft burn, collection createGenesiscreate, bucket add-*, deposit, withdraw, claim, finalize, revokeDistributioncreate, deposit, withdrawCandy Machineinsert, withdrawCPI LimitationsSome operations cannot be wrapped in execute() due to Solana CPI constraints:Large account creation — Merkle trees and candy machines exceed CPI account allocation limitsNative SOL wrapping — transferSol to a token account fails in CPI contextFor these operations, use a normal wallet or create the infrastructure first, then switch to the asset-signer wallet for subsequent operations.Raw Instructions with Toolbox RawThe mplx toolbox raw command executes arbitrary base64-encoded instructions. When an asset-signer wallet is active, these are automatically wrapped in execute().Execute raw instructions# Single instruction\nmplx toolbox raw --instruction <base64>\n\n# Multiple instructions\nmplx toolbox raw --instruction <ix1> --instruction <ix2>\n\n# Read from stdin\necho \"<base64>\" | mplx toolbox raw --stdin\nBuilding Raw InstructionsThe CLI includes serialization helpers for building base64-encoded instructions:build-raw-instruction.tsimport { publicKey } from '@metaplex-foundation/umi'\nimport { serializeInstruction } from '@metaplex-foundation/cli/lib/execute/deserializeInstruction'\n\nconst signerPda = '<PDA address from execute info>'\nconst destination = '<destination address>'\n\n// System Program SOL transfer\nconst data = new Uint8Array(12)\nconst view = new DataView(data.buffer)\nview.setUint32(0, 2, true) // Transfer discriminator\nview.setBigUint64(4, 1_000_000n, true) // 0.001 SOL\n\nconst ix = {\n programId: publicKey('11111111111111111111111111111111'),\n keys: [\n { pubkey: publicKey(signerPda), isSigner: true, isWritable: true },\n { pubkey: publicKey(destination), isSigner: false, isWritable: true },\n ],\n data,\n}\n\nconsole.log(serializeInstruction(ix))\n// Pass the output to: mplx toolbox raw --instruction <base64>\nInstruction Binary FormatBytesField32Program ID2Number of accounts (u16 little-endian)33 per account32 bytes pubkey + 1 byte flags (bit 0 = isSigner, bit 1 = isWritable)remainingInstruction dataQuick ReferenceItemValueAdd walletmplx config wallets add <name> --asset <assetId>Switch walletmplx config wallets set <name>Inspect PDAmplx core asset execute info <assetId>Override-k /path/to/keypair.json on any commandFee payer-p /path/to/payer.json on any commandPDA derivationfindAssetSignerPda(umi, { asset: assetPubkey })Config file~/.config/mplx/config.jsonSourceGitHub — metaplex-foundation/cliGlossaryTermDefinitionSigner PDAA program-derived address derived from an MPL Core Asset that can hold SOL, tokens, and own other assetsExecute instructionThe MPL Core on-chain instruction that allows a PDA to sign instructions on behalf of the assetNoop signerA placeholder signer that provides a public key but produces no signature — used so commands build instructions targeting the PDACPICross-Program Invocation — when one Solana program calls another; some operations have size limits in CPI contextFAQDo I need a separate execute command for each operation?No. When an asset-signer wallet is active, every CLI command is automatically wrapped in the execute instruction at send time. Use standard commands like mplx toolbox sol transfer or mplx core asset create — no separate execute subcommands exist for these operations.What happens if the asset owner is not in my saved wallets?The CLI returns an error asking you to add the owner wallet first. Run mplx config wallets add <name> <keypair-path> with the asset owner's keypair before registering the asset-signer wallet.Can a different wallet pay transaction fees while the PDA signs?Yes. Pass -p /path/to/fee-payer.json to any command. The asset owner still signs the execute instruction, but the -p wallet pays the Solana transaction fee.Which operations cannot be wrapped in execute?Large account creation (Merkle trees, candy machines) and native SOL wrapping fail due to Solana CPI size limits. Create this infrastructure with a normal wallet first, then switch to the asset-signer wallet for subsequent operations.How do I check what address the PDA resolves to?Run mplx core asset execute info <assetId>. This shows the deterministic signer PDA address and its current SOL balance.What happens if I burn the Asset while the PDA still holds funds?execute fails after the Asset is burned, so SOL, tokens, and nested assets in the PDA are stranded. Transfer them out first.NotesAsset-signer wallets require the asset owner's wallet to be saved in your wallet configuration — add the owner wallet firstThe asset-signer wallet stores the PDA address, the linked asset ID, and a reference to the owner wallet in your config fileWhen you switch away from an asset-signer wallet, commands revert to normal keypair signingThe -k flag always takes precedence over the active wallet, including asset-signer walletsRaw instructions via mplx toolbox raw are wrapped in execute() like any other command when an asset-signer wallet is activeBurning the Asset permanently disables execute. Empty the signer PDA first or remaining SOL, tokens, and nested assets are stranded","tokens":2120,"squid":"dotcat","role":"Tooling Spider","at":1791343851463,"hash":"64442815b3be058df4ccdbdf9d742a7f452b01ea"}
{"url":"https://eips.ethereum.org/EIPS/eip-2387","domain":"eips.ethereum.org","title":"EIP-2387: Hardfork Meta: Muir Glacier","text":"🎉 Final\n\n Meta\n\n EIP-2387: Hardfork Meta: Muir Glacier\n\n Authors\n James Hancock (@madeoftin)\n\n Created\n 2019-11-22\n\n Requires\n\n EIP-1679, \n\n EIP-2384\n\n Abstract\n\nThis meta-EIP specifies the changes included in the Ethereum hard fork named Muir Glacier. This hard fork addresses the impending Ice Age on Ethereum Mainnet and includes a commitment to solving the problems with the ice age more permanently.\n\n Motivation\n\nEthereum achieves a consistent block time due to its’ difficulty retargeting algorithm. If a block-time is higher than 20 seconds, it reduces the difficulty, and if a block time is lower than 10 seconds, it increases the difficulty. This mechanism reaches typically an equilibrium of around 13-14 seconds. Included within this mechanism is something we refer to as the Difficulty Bomb or the Ice Age. It artificially adds to the difficulty in such a way that the retargeting mechanism, at some point, can not adapt to the increase, and we see increased block times throughout the network. The ice age increments every 100,000 blocks. It at first is barely noticeable, but once it is visible, there is a drastic effect on block-times in the network.\n\nThe primary problem with the Ice Age is that it is included in the complex mechanism that targets block times, which is an entirely separate in purpose. What is worse is due to being intwined with that algorithm, it is very difficult to simulate or predict its effect on the network. To predict the impact of the ice age, you must both make assumptions about the difficulty of main-net in the future, and predict the effect of changes in difficulty to the impact on the ice age and thus block-times.\n\nThis fork will push back the Iceage as far as far as is reasonable and will give us time to update the Iceage to no longer have these design problems. There are two solutions to consider within that time frame.\n\n Update the mechanism so that behavior is predictable.\n Remove the Iceage entirely\n\n Specification\n\n Codename: Muir Glacier\n\n Activation\n\n Block >= 9,200,000 on the Ethereum mainnet\n Block >= 7,117,117 on the Ropsten testnet\n Block >= N/A on the Kovan testnet\n Block >= N/A on the Rinkeby testnet\n Block >= N/A on the Görli testnet\n\n Included EIPs\n\n EIP-2384: Istanbul/Berlin Difficulty Bomb Delay\n\n Rationale\n\nI want to address the rationale for the intention of the Iceage and the implementation of the Iceage separately.\n\nThe original intentions of the ice age include:\n\n At the time of upgrades, inhibit unintentional growth of the resulting branching forks leading up to Eth 2.0. *\n Encourage a prompt upgrade schedule for the path to Eth 2.0. *\n Forces the community to come back into agreement repeatedly…and it gives whatever portion of the community that wants to a chance to fork off\n Is a check for the Core Devs in the case that a decision is made to freeze the code base of clients without the blessing of the community.\n\n*Note: None of these effects the Freedom to Fork. They are meant to encourage core-devs and the community to upgrade along with the network and prevent the case where sleeper forks remain dormant only later to be resurrected. The requirement for an active fork is to change a client in a way to respond to the ice age. This is in fact what Ethereum Classic has done.\n\nThis is not meant to be exhaustive, but the ideas above capture much of what has been written on the original intentions and process of creating the fork. Any additions to this list that need to be made, I am happy to include. Regardless, to effectively implement an updated design for the ice age, all of the intentions need to be revisited and clarified as part of any updates. This clarification will give a clear expectation for the community and core developers moving forward.\n\nThe implementation\n\nThe existing implementation of the ice age, while it does work in practice, is unnecessarily complex to model and confusing to communicate to the community. Any updates to the design should be:\n\n Easy to model the effect on the network\n Easy to predict when it occurs\n\nThis fork would give us time to address the community to understand their priorities better as far as the intentions of the Ice Age, and give time for proposals for better mechanisms to achieve those goals.\n\n POA Testnets\n\nMuir Glacier never activates on PoA chains – thus will have zero impact on forkid.\n\n Note on Issuance Reduction\n\nPrevious Hardforks to address the Ice Age have also included reductions in the block reward from 5 Eth to 3 Eth to 2 Eth, respectively. In this case, there is no change in issuance, and the block reward remains 2 Eth per block.\n\n Copyright\n\nCopyright and related rights waived via CC0.\n\n Citation\n Please cite this document as:\n\n James Hancock (@madeoftin), \"EIP-2387: Hardfork Meta: Muir Glacier,\" Ethereum Improvement Proposals, no. 2387, November 2019. Available: https://eips.ethereum.org/EIPS/eip-2387.","tokens":1226,"squid":"spider-05","role":"Spec Spider","at":1791343855525,"hash":"cc1964ea08b72db1b0ac58f2ede7a342a54d37dc"}
{"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":"spider-04","role":"Research Spider","at":1791343862660,"hash":"40423dcc60831f129143556d72dd4f2297db1a03"}
{"url":"https://developers.jup.ag/docs/trigger/authentication","domain":"developers.jup.ag","title":"Authentication - Jupiter Developers","text":"The Trigger Order API V2 uses a challenge-response flow to authenticate users. Your wallet signs a challenge, and the server issues a JWT. There are two auth modes:\n\naccess_refresh (recommended): a 15-minute access token plus a rotating refresh token. Extend the session by calling /refresh, and revoke it with /logout or /logout-all.\naccess_only (deprecated): a single JWT valid for 24 hours with no refresh or revocation. This is still the default when authMode is omitted.\n\naccess_only is deprecated (2026-07-21) and will be removed. If your client omits authMode, the server still responds as access_only and sets a Deprecation response header. Nothing breaks today, but authMode: \"access_only\" will stop being accepted at removal. Send authMode: \"access_refresh\" on /verify to migrate. See Migrate from access_only.\n​Auth modes at a glance\nTopicaccess_only (deprecated)access_refresh (recommended)Access token lifetime24 hours15 minutesVerify response token fieldtokenaccessTokenExtend a sessionRe-authenticate (new challenge)POST /trigger/v2/auth/refreshRevoke a sessionNot possible before expiry/logout (one session), /logout-all (all sessions), reuse detectionResponse headersDeprecation, Linknone\n​Prerequisites\nSigning challenges and transactions requires @solana/web3.js and bs58:\nnpm install @solana/web3.js bs58\n\n​Step 1: Request a challenge\nRequest a challenge for your wallet. The type field selects how your wallet will sign, and accepts exactly two values:\ntypeUse it forYou sign withmessageStandard wallets (Phantom, Solflare, and most others)signMessage on the returned challenge stringtransactionHardware wallets (Ledger, etc.) that only support transaction signingsignTransaction on the returned transaction (it is never submitted on-chain)\nBoth prove wallet ownership and return the same tokens. Any other value returns a 400. Challenges expire after 5 minutes; request a new one if yours expires.\nconst challengeResponse = await fetch('https://api.jup.ag/trigger/v2/auth/challenge', {\n method: 'POST',\n headers: {\n 'Content-Type': 'application/json',\n 'x-api-key': 'your-api-key',\n },\n body: JSON.stringify({\n walletPubkey: walletAddress,\n type: 'message', // or 'transaction' for hardware wallets\n }),\n});\n\nconst challenge = await challengeResponse.json();\n\nMessage challenge response:\n{\n \"type\": \"message\",\n \"challenge\": \"Sign this message to authenticate with Jupiter that you are the owner of <walletPubkey>.\\n\\nThis challenge expires at 2026-09-16T14:02:39.204Z with the nonce of 01a0aa82-4504-76ed-8c94-4fb787c6a2a9.\"\n}\n\nTransaction challenge response:\n{\n \"type\": \"transaction\",\n \"transaction\": \"Base64EncodedTransactionWithMemoInstruction...\"\n}\n\n​Step 2: Verify and get tokens\nSign the challenge with your wallet, then submit the signature to /verify. Add authMode: \"access_refresh\" to the request body to receive refresh tokens. The challenge step is identical for both auth modes.\nFor message signing:\nimport bs58 from 'bs58';\n\n// Sign the challenge message with your wallet\nconst encodedMessage = new TextEncoder().encode(challenge.challenge);\nconst signature = await wallet.signMessage(encodedMessage);\n\nconst verifyResponse = await fetch('https://api.jup.ag/trigger/v2/auth/verify', {\n method: 'POST',\n headers: {\n 'Content-Type': 'application/json',\n 'x-api-key': 'your-api-key',\n },\n body: JSON.stringify({\n type: 'message',\n walletPubkey: walletAddress,\n signature: bs58.encode(signature),\n authMode: 'access_refresh',\n }),\n});\n\nconst { accessToken, refreshToken, expiresAt } = await verifyResponse.json();\n// Store all three. Use accessToken in Authorization: Bearer <accessToken>.\n\nFor transaction signing (hardware wallets):\nimport { VersionedTransaction } from '@solana/web3.js';\n\nconst signedTx = await wallet.signTransaction(\n VersionedTransaction.deserialize(Buffer.from(challenge.transaction, 'base64'))\n);\n\nconst verifyResponse = await fetch('https://api.jup.ag/trigger/v2/auth/verify', {\n method: 'POST',\n headers: {\n 'Content-Type': 'application/json',\n 'x-api-key': 'your-api-key',\n },\n body: JSON.stringify({\n type: 'transaction',\n walletPubkey: walletAddress,\n signedTransaction: Buffer.from(signedTx.serialize()).toString('base64'),\n authMode: 'access_refresh',\n }),\n});\n\nconst { accessToken, refreshToken, expiresAt } = await verifyResponse.json();\n\naccess_refresh response:\n{\n \"authMode\": \"access_refresh\",\n \"accessToken\": \"<jwt, expires in 15 minutes>\",\n \"refreshToken\": \"<opaque>\",\n \"expiresAt\": \"2026-09-16T14:12:43.000Z\",\n \"tokenType\": \"Bearer\"\n}\n\nFieldTypeDescriptionauthModestringaccess_refreshaccessTokenstringJWT to send in the Authorization: Bearer header. Expires 15 minutes after issue.refreshTokenstringOpaque token used to obtain a new access token. Rotates on every /refresh call.expiresAtstringISO 8601 timestamp when accessToken expires.tokenTypestringAlways Bearer.\nIf you omit authMode, you get the deprecated access_only response instead: a single 24-hour token (read accessToken, not token, once you migrate), returned with Deprecation and Link headers.\n{\n \"authMode\": \"access_only\",\n \"token\": \"<jwt, expires in 24 hours>\"\n}\n\n​Using the access token\nInclude the access token in all authenticated requests:\nconst response = await fetch('https://api.jup.ag/trigger/v2/vault', {\n headers: {\n 'x-api-key': 'your-api-key',\n 'Authorization': `Bearer ${accessToken}`,\n },\n});\n\n​Refresh the access token\nBefore expiresAt, call /refresh with the current refresh token to get a new access token and refresh token. Every call rotates the refresh token: replace both stored tokens with the response. Do not send authMode here.\nconst refreshResponse = await fetch('https://api.jup.ag/trigger/v2/auth/refresh', {\n method: 'POST',\n headers: {\n 'Content-Type': 'application/json',\n 'x-api-key': 'your-api-key',\n },\n body: JSON.stringify({ refreshToken }),\n});\n\nif (refreshResponse.status === 401) {\n // Refresh token expired, revoked, or reused: start a new challenge.\n return reauthenticate();\n}\n\nconst { accessToken, refreshToken: newRefreshToken, expiresAt } = await refreshResponse.json();\n// Persist the new pair; discard the old refresh token.\n\nThe response has the same fields as the access_refresh verify response:\n{\n \"authMode\": \"access_refresh\",\n \"accessToken\": \"<jwt, expires in 15 minutes>\",\n \"refreshToken\": \"<opaque, rotated>\",\n \"expiresAt\": \"2026-09-16T14:12:47.000Z\",\n \"tokenType\": \"Bearer\"\n}\n\nRotation rules:\n\nRotate and replace. Each successful /refresh invalidates the refresh token you sent and returns a new one. Always store the newest pair.\nRetry grace. Repeating the same /refresh request within a short grace window (a network retry) is tolerated and returns a valid pair, so a dropped response does not lock you out.\nReuse is rejected. Presenting an old refresh token outside that grace window returns 401, and the session is revoked. Send the user back through the challenge flow.\n\n​Handle 401 on protected routes\nA 15-minute access token expires mid-session more often than a 24-hour one did. On a 401 from any protected route, refresh once and retry the request. If /refresh itself returns 401, start a new challenge.\nasync function callWithAuth(input: RequestInfo, init: RequestInit = {}) {\n let res = await fetch(input, withBearer(init, accessToken));\n if (res.status === 401) {\n await refreshTokens(); // updates accessToken/refreshToken, or re-authenticates on 401\n res = await fetch(input, withBearer(init, accessToken));\n }\n return res;\n}\n\n​Log out\nRevoke refresh tokens when the user signs out. Access tokens already issued remain valid until they expire (up to 15 minutes); logout stops new access tokens from being minted.\nOne session (the device holding this refresh token). No authentication required, always returns 200:\nawait fetch('https://api.jup.ag/trigger/v2/auth/logout', {\n method: 'POST',\n headers: {\n 'Content-Type': 'application/json',\n 'x-api-key': 'your-api-key',\n },\n body: JSON.stringify({ refreshToken }),\n});\n// { \"success\": true }\n\nEvery session for the wallet. Requires the access token as a Bearer credential:\nawait fetch('https://api.jup.ag/trigger/v2/auth/logout-all', {\n method: 'POST',\n headers: {\n 'Content-Type': 'application/json',\n 'x-api-key': 'your-api-key',\n 'Authorization': `Bearer ${accessToken}`,\n },\n body: '{}',\n});\n// { \"success\": true }\n\n/logout revokes the single refresh token you pass. /logout-all invalidates every refresh token issued for the wallet, so all devices must re-authenticate.\n​Migrate from access_only\n\nSend authMode: \"access_refresh\" on /verify for both type: \"message\" and type: \"transaction\". The challenge step is unchanged.\nRead accessToken, not token. Store accessToken, refreshToken, and expiresAt. Keep the refresh token out of logs and analytics.\nRefresh before expiresAt. Call /refresh with the current refresh token and replace both tokens with the response.\nHandle 401 by refreshing once, then re-login. On a 401 from a protected route, refresh and retry once; if the refresh returns 401, start a new challenge.\nWire logout. Call /logout on sign-out, and /logout-all to revoke every session for the wallet.\n\n​Sequence after migration\n\n​Token lifecycle\nPropertyValueChallenge TTL5 minutesAccess token TTL (access_refresh)15 minutesToken TTL (access_only, deprecated)24 hoursRefresh tokenRotates on every /refresh; revoked by /logout, /logout-all, or reuse\n​Security notes\nFor integrators building user-facing applications:\nTreat the refresh token as the sensitive credential. Never store tokens in local storage; use secure, httpOnly cookies or in-memory storage, and keep the refresh token out of logs and analytics.\nAlways verify the challenge content before signing. Do not blindly sign arbitrary messages.\nOn 401, refresh once and retry; if the refresh fails, re-authenticate. Do not retry a refresh token that already returned 401 (it counts as reuse and revokes the session).\nTokens are tied to the wallet public key. Do not reuse them across wallets.\nCall /logout-all if you suspect a refresh token has leaked.\n\n​What happens if a token is leaked\nThe tokens grant limited access. An attacker with a leaked access or refresh token can:\n\nCancel orders: This stops an order from filling, but does not withdraw funds. Withdrawal requires signing a transaction with the wallet private key.\nEdit price-order parameters: Updating a price order’s trigger price or slippage does not require transaction signing. DCA orders cannot be edited.\n\nAn attacker cannot:\n\nWithdraw funds: All withdrawal operations require the wallet owner to sign a transaction. The vault’s funds remain secure.\nCreate new orders: Depositing tokens requires signing a deposit transaction with the wallet.\n\nAll operations involving funds (deposits, withdrawals) require the wallet owner to sign a transaction, so a leaked token alone cannot result in loss of funds. A leaked access token expires within 15 minutes; a leaked refresh token stays usable until it is rotated or revoked, so call /logout-all to cut off every session. If the wallet private key is also compromised, an attacker could sign transactions and withdraw funds from the vault.Was this page helpful?","tokens":2776,"squid":"spider-02","role":"Liquidity Spider","at":1791343862693,"hash":"8d1eb0efad22a81844f6001d0c6115764058ead5"}
{"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":"spider-05","role":"Spec Spider","at":1791343866293,"hash":"e77499b0a6e8af33389fd8b52adb9fc6f83acff9"}
{"url":"https://developers.jup.ag/docs/trigger/manage-orders","domain":"developers.jup.ag","title":"Manage Orders - Jupiter Developers","text":"Update an order in place, or cancel it with a two-step withdrawal. Every request needs the JWT token from authentication and the orderId returned when you created the order (the same value as id in order history).\n​Prerequisites\nSigning withdrawal transactions requires @solana/web3.js:\nnpm install @solana/web3.js\n\n​Update an Order\nModify the trigger price or slippage of an existing order without cancelling and recreating it.\nconst updateResponse = await fetch(`https://api.jup.ag/trigger/v2/orders/price/${orderId}`, {\n method: 'PATCH',\n headers: {\n 'Content-Type': 'application/json',\n 'x-api-key': 'your-api-key',\n 'Authorization': `Bearer ${token}`,\n },\n body: JSON.stringify({\n orderType: 'single',\n triggerPriceUsd: 210.00,\n slippageBps: 150,\n }),\n});\n\nconst result = await updateResponse.json();\n// { id: \"order-uuid\" }\n\n​Update Fields by Order Type\nSingle:\n{\n \"orderType\": \"single\",\n \"triggerPriceUsd\": 210.00,\n \"slippageBps\": 150\n}\n\nOCO:\n{\n \"orderType\": \"oco\",\n \"tpPriceUsd\": 260.00,\n \"slPriceUsd\": 145.00\n}\n\nOTOCO:\n{\n \"orderType\": \"otoco\",\n \"triggerPriceUsd\": 185.00,\n \"tpPriceUsd\": 230.00,\n \"slPriceUsd\": 155.00\n}\n\nTrailing stop loss:\n{\n \"orderType\": \"single\",\n \"trailingBps\": 800,\n \"slippageBps\": 150\n}\n\nOn a trailing stop loss, update trailingBps (50–9000) to change the trail distance. You cannot set triggerPriceUsd on a trailing order (400 \"Cannot set trigger price on trailing stop loss order\"), convert a static order to trailing or back (400 \"Cannot convert to trailing stop loss order\"), or set a trailingBps whose new band would fire immediately (400 \"Trailing order would immediately trigger\").\n​Cancel an Order\nCancellation is a two-step process. The first step returns a withdrawal transaction that moves funds from the vault back to your wallet. You sign and submit it in the second step.\n​Step 1: Initiate Cancellation\nThis immediately moves the order from open to ready_to_cancel. The order will no longer be filled, even if step 2 has not yet completed. This prevents a race condition where the order could still execute while you are signing the withdrawal transaction.\nconst cancelResponse = await fetch(\n `https://api.jup.ag/trigger/v2/orders/price/cancel/${orderId}`,\n {\n method: 'POST',\n headers: {\n 'x-api-key': 'your-api-key',\n 'Authorization': `Bearer ${token}`,\n },\n }\n);\n\nconst cancelData = await cancelResponse.json();\n\nResponse:\n{\n \"id\": \"order-uuid\",\n \"transaction\": \"Base64EncodedUnsignedWithdrawalTransaction...\",\n \"requestId\": \"cancel-request-uuid\"\n}\n\n​Step 2: Sign and Confirm\nSign the withdrawal transaction and submit it to complete the cancellation.\nimport { VersionedTransaction } from '@solana/web3.js';\n\nconst transaction = VersionedTransaction.deserialize(\n Buffer.from(cancelData.transaction, 'base64')\n);\nconst signedTransaction = await wallet.signTransaction(transaction);\n\nconst confirmResponse = await fetch(\n `https://api.jup.ag/trigger/v2/orders/price/confirm-cancel/${orderId}`,\n {\n method: 'POST',\n headers: {\n 'Content-Type': 'application/json',\n 'x-api-key': 'your-api-key',\n 'Authorization': `Bearer ${token}`,\n },\n body: JSON.stringify({\n signedTransaction: Buffer.from(signedTransaction.serialize()).toString('base64'),\n cancelRequestId: cancelData.requestId,\n }),\n }\n);\n\nconst result = await confirmResponse.json();\n// { id: \"order-uuid\", txSignature: \"...\" }\n\nIf step 2 fails (the transaction doesn’t land), you can retry by calling the confirm endpoint again with the same cancelRequestId. The order remains in ready_to_cancel state until the withdrawal confirms.\n​Expired Order Withdrawal\nIf an order expires before execution, the funds remain in the vault. To retrieve them, use the same two-step cancel flow: initiate cancellation on the expired order, sign the withdrawal transaction, and confirm. The order transitions through ready_to_cancel and then to cancelled once the withdrawal confirms on-chain.\n​Error Handling\nStatusMeaning400Invalid order ID, order not in a cancellable state, or validation error401Invalid API key, or JWT expired/invalid403Order belongs to a different wallet404Order not foundWas this page helpful?","tokens":1026,"squid":"spider-02","role":"Liquidity Spider","at":1791343884608,"hash":"d7040160eaf6a9f9cf4f47e3ad3a155f06949264"}
{"url":"https://ethresear.ch/t/somewhat-time-critical-how-do-i-set-a-password/11074","domain":"ethresear.ch","title":"Somewhat time critical — How do I set a password? - Administrivia - Ethereum Research","text":"Somewhat time critical — How do I set a password? \n\n Administrivia\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 5\n\n 2\n\n Oct 2021\n\n 1 / 9\n\n Oct 2021\n\n Nov 2021\n\n post by x on Oct 22, 2021\n\n x\n\n This site required me to do OAuth to register. For privacy / data hygiene reasons I then removed my GitHub from this profile and de-authenticated the site in GitHub.\nNext I changed my GitHub email address and deleted the previous address. Finally I also generated a new email address for this site to then remove the final remaining link to GitHub.\nQuestion: How can I set a password on this site, such that I will be allowed to log in once my cookie expires? Can I just log in with the email that’s now in my profile, without a password?\n\n Ethresear.ch: email login will be disabled in 7 days\n\n 5\n\n 2\n\n post by hwwhww on Oct 22, 2021\n\n hwwhww\n\n Well, the main reason why we disallow email login is for mitigating spamming. GitHub account association also provides some reputation reference in R&D community. (And considering dogfooding Ethereum account login in the future)\nI don’t think you can set password now. If you want to hide your main email/GitHub info, you could register a new GitHub account for ethresear.ch.\nSorry it’s not perfect, but IMO it’s not good to enable email login in ethresear.ch.\n\n post by x on Oct 22, 2021\n\n x\n\n K … well the guys over at ethereum-magicians allow it. They also have 2FA \n\n post by pavloMandryk on Oct 22, 2021\n\n pavloMandryk\n\n Hi, this is my first reply, hope it can be helpful.\nAs @hwwhww mentioned, there is no way you can set a password; but you still can recover access to the profile after cookie expiration.\nThe way to proceed would be creating a new GitHub account for the newly set “primary email” in your forum profile. You can access your profile using those GitHub credentials. This way you didn’t need to create an extra profile and still succeed to remove any trace of your main GitHub account.\nTo achieve privacy when creating a ethresear.ch profile just use a fresh email with a fresh GitHub account.\n\n post by x on Oct 22, 2021\n\n x\n\n My session is still alive! Woohoo, clearly living on the edge here. Tbh, as some might have guessed, I didn’t really expect to receive a solution here. I just wanted to highlight that the current system seems inefficient.\nGiven how easy it is to create a separate GitHub account for registration here, what is the purpose of enforcing GitHub in the first place? If it’s for reputation purposes, then you shouldn’t be allowed to disassociate your GitHub again, and you should enforce a certain minimum GitHub account age or a certain minimum number of GitHub contributions.\nThe current system doesn’t protect us from anything. Instead, I only see negative outcomes:\n\nPeople who don’t want all their profiles across the Internet correlated are forced to go through the extra step of setting up a throwaway GitHub account (it takes time to set up and secure) — there is a reason why people set their GitHub email to private\nPeople who don’t have time to do that may need to unnecessarily sacrifice OpSec against their will\nPeople who don’t know yet what they want are by default directed into a non-privacy maximizing choice and the use of single-sign on is wrongly presented to them as a best practice (by a reputable community)\n\nGiven the increasing scrutiny from all sides, we should all try to become less traceable, not more traceable. At least, you should allow the people who care to minimize their attack surface.\n\n post by MicahZoltu on Oct 22, 2021\n\n MicahZoltu\n\n hwwhww\n\n Is the theory here to try to leverage GitHub’s spam protections? What is GitHub’s spam protection and can we just do that directly instead?\n\n post by pavloMandryk on Oct 22, 2021\n\n pavloMandryk\n\n These topics were discussed here alongside with the EAuth implementation.\n\n@hwwhww Are spamming and impersonator attacks the only reasons for disallowing email login? Did we have bad experiences with this before? How is ethereum-magicians managing these issues while allowing email login?\nI agree on maximizing non-traceability and would like to point out two more implications of the GitHub login only: UX and security.\nI believe that it is fair to say that a significant amount of potential users fall under a) don’t have an GitHub account or b) have a completely inactive GitHub account. For these users the lack of 2FA results on poor UX, of course, but also they are more likely to give up on security as they are probably less willing to set up and secure a GitHub account they don’t use.\nOn the other hand, in my personal experience as a GitHub user, the UX of the current system feels super smooth.\nThe advantages of having email login and GitHub auth would be:\n\nPrivacy for those who don’t want their profile to be associated with their GitHub.\nMore balanced UX.\n\nFor the current GitHub only system we have the following:\n\nLess privacy.\nA worst UX and security for non-GitHub-users.\nA better UX for GitHub users.\nProtection against spam and impersonator attacks.\n\nIs there a way to point to the GitHub account without using email as primary key? If this is non-trivial to make, we can’t enforce users to stick with one GitHub account since GitHub email can be changed.\n\nWhen it comes to EAuth implementation we are still facing the same privacy issues, as the idea would be enabling to sign up with ENS but requiring to associate a GitHub account with it. (Still excited about EAuth though!)\n\n post by x on Oct 22, 2021\n\n x\n\n If this is about impersonators, then the solution are cryptographic signatures, not some OAuth using some random website that some people don’t even feel comfortable using.\nYou could sign a message in your profile with GPG or you could even use an ETH key to sign it.\n\n 10 days later\n\n post by x on Nov 1, 2021\n\n x\n\n Hey friends — I can’t believe it, but I just came back after 10 days and my session is still live … ! Long live the cookies.\nSo, what did we end up with? Can this discussion be summarized as (not everyone thinks this! thank you for the constructive discussion so far):\n\nThe reason for GitHub auth is to avoid impersonation\nCryptographic signatures (OpenPGP, Minisign, ETH keys, …) would be a better solution than GitHub to verify identities/pseudonyms\nHowever, the target users of this forum don’t like using cryptographic signatures for this use case\nThus the people in this forum want to keep using GitHub to avoid impersonation\n(They don’t care that others may not like that; either because it links their accounts unnecessarily, or because they just don’t want to use GitHub)\n\n(There was more nuance, but I tried to dumb it down.)\nEDIT: By the way … thank you all for voting me “User of the Month” … I feel very honored.\nimage1038×272 29 KB\n\n Powered by Discourse","tokens":1700,"squid":"spider-04","role":"Research Spider","at":1791343884745,"hash":"4edb82ca695313cbc3c361fc901a02756f8bc6ed"}
{"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":"spider-05","role":"Spec Spider","at":1791343888227,"hash":"ac5b304844b6cd203ec60df1393a6af817c787d5"}
{"url":"https://developers.jup.ag/docs/trigger/best-practices","domain":"developers.jup.ag","title":"Trigger Best Practices - Jupiter Developers","text":"The Trigger Order V2 API is in beta and under active development. Behaviour, endpoints, and response formats may change as we iterate based on integrator feedback. Pin to specific response schemas and handle unknown fields gracefully.\n​Reference Implementation\nThe jup.ag frontend is the canonical reference for how to interact with the V2 API. When in doubt about edge cases, validation logic, or UX patterns, refer to how jup.ag handles it. This includes:\n\nOrder creation flows and parameter validation\nPrice and slippage presentation\nError handling and retry logic\nOrder state management and polling\n\n​Order Expiry (Price Orders)\nEvery price order requires an expiresAt timestamp. Unlike V1 where orders could exist indefinitely, V2 enforces expiry on all price orders. This allows the system to prune stale orders, improving execution quality for active orders.\nUse caseRecommended expiryShort-term trades1-7 daysSwing trades7-30 daysLong-duration positions30 days, with periodic renewal\nFor long-lived orders, set a 30-day expiry and renew by updating the order before it expires via the update endpoint. There is no “no expiry” option by design.\nDCA orders have no expiresAt. A DCA runs until its budget is spent: its duration is orderCount × intervalSeconds, and an optional beginFillAt (default now, at most 30 days out) sets when the first round starts.\n​Slippage (Price Orders)\nSlippage settings apply to price orders. DCA orders have no slippage parameter: the keeper sets slippage per round from live market conditions at fill time.\nOrder typeDefaultRecommendationTake-profit / buy belowAuto (RTSE)Use the default unless you have specific requirementsStop-loss / buy above20% (2000 bps)Keep high for execution certainty; tighten only if you accept missed fillsParent (OTOCO)Auto (RTSE)Use the default\nStop-loss orders use a higher default because execution certainty matters more than price precision when cutting losses. If you lower stop-loss slippage, the order may not fill during volatile conditions.\n​Error Handling\n\nValidation errors (400) include a details object with per-field messages. Parse these to surface specific issues to users.\nAuthentication errors (401) mean the JWT has expired. Re-authenticate with a new challenge-response flow rather than retrying the same token.\nMinimum order size is 10 USD: per price order, or per DCA round (inputAmount / orderCount). Enforce this client-side to avoid unnecessary API calls.\nHandle unknown fields in responses gracefully. As the API evolves during beta, new fields may be added to response objects.\n\n​Order Summary\nThe API does not validate whether your trigger price makes economic sense. If a user sets a buy order above market price or a sell order below market price, the keeper will execute as instructed and the difference is lost.\nDisplay a human-readable summary of what the order will do before the user confirms. On jup.ag, the confirmation shows a plain-language description like:\n\nBuy SOL with 15 USDC when price goes below 76.37(−1076.37 (-10% from market). If triggered, automatically set TP for SOL at 84.01.\n\nThis helps users catch mistakes before submitting. For OCO and OTOCO orders, include both the trigger conditions and the child order parameters in the summary.\nFor DCA, summarise the schedule (number of rounds × interval), the per-round amount (inputAmount / orderCount, with the last round absorbing any remainder), and for price_conditional orders the [minPriceUsd, maxPriceUsd] band and which mint is the trigger.\n​Token Compatibility\n\nTokens with transfer-fee or transfer-hook extensions are rejected at deposit unless whitelisted\nInput and output mints must be different\n\n​Order Lifecycle\nPoll the history endpoint to track order state; the states differ by family.\nPrice orders (GET /orders/history):\nStateMeaningActionopenActive, waiting for triggerNo action neededfilledFully executedShow completion to usercancelledCancelled by userConfirm funds returned to vaultexpiredPast expiresAtPrompt user to withdraw funds or recreatefailedExecution failedShow error, suggest retry with adjusted parameters\nDCA (GET /orders/history/dca) uses a different set: pending, active, executing, completed (all rounds filled), pending_withdraw, cancelled, and failed. There is no open or expired state; a DCA ends at completed when its budget is spent.Was this page helpful?","tokens":1091,"squid":"spider-02","role":"Liquidity Spider","at":1791343895860,"hash":"977ffbce277c3c7a6eb926c6028524cf9f29cb7c"}
{"url":"https://eips.ethereum.org/EIPS/eip-2535","domain":"eips.ethereum.org","title":"ERC-2535: Diamonds, Multi-Facet Proxy","text":"🎉 Final\n\n Standards Track: ERC\n\n ERC-2535: Diamonds, Multi-Facet Proxy\n\n Create modular smart contract systems that can be extended after deployment.\n\n Authors\n Nick Mudge (@mudgen)\n\n Created\n 2020-02-22\n\n Abstract\n\nThis proposal standardizes diamonds, which are modular smart contract systems that can be upgraded/extended after deployment, and have virtually no size limit. More technically, a diamond is a contract with external functions that are supplied by contracts called facets. Facets are separate, independent contracts that can share internal functions, libraries, and state variables.\n\n Motivation\n\nThere are a number of different reasons to use diamonds. Here are some of them:\n\n A single address for unlimited contract functionality. Using a single address for contract functionality makes deployment, testing and integration with other smart contracts, software and user interfaces easier.\n Your contract exceeds the 24KB maximum contract size. You may have related functionality that it makes sense to keep in a single contract, or at a single contract address. A diamond does not have a max contract size.\n A diamond provides a way to organize contract code and data. You may want to build a contract system with a lot of functionality. A diamond provides a systematic way to isolate different functionality and connect them together and share data between them as needed in a gas-efficient way.\n A diamond provides a way to upgrade functionality. Upgradeable diamonds can be upgraded to add/replace/remove functionality. Because diamonds have no max contract size, there is no limit to the amount of functionality that can be added to diamonds over time. Diamonds can be upgraded without having to redeploy existing functionality. Parts of a diamond can be added/replaced/removed while leaving other parts alone.\n A diamond can be immutable. It is possible to deploy an immutable diamond or make an upgradeable diamond immutable at a later time.\n A diamond can reuse deployed contracts. Instead of deploying contracts to a blockchain, existing already deployed, onchain contracts can be used to create diamonds. Custom diamonds can be created from existing deployed contracts. This enables the creation of on-chain smart contract platforms and libraries.\n\nThis standard is an improvement of EIP-1538. The same motivations of that standard apply to this standard.\n\nA deployed facet can be used by any number of diamonds.\n\nThe diagram below shows two diamonds using the same two facets.\n\n FacetA is used by Diamond1\n FacetA is used by Diamond2\n FacetB is used by Diamond1\n FacetB is used by Diamond2\n\n Upgradeable Diamond vs. Centralized Private Database\n\nWhy have an upgradeable diamond instead of a centralized, private, mutable database?\n\n Decentralized Autonomous Organizations (DAOs) and other governance systems can be used to upgrade diamonds.\n Wide interaction and integration with the Ethereum ecosystem.\n With open storage data and verified source code it is possible to show a provable history of trustworthiness.\n With openness bad behavior can be spotted and reported when it happens.\n Independent security and domain experts can review the change history of contracts and vouch for their history of trustworthiness.\n It is possible for an upgradeable diamond to become immutable and trustless.\n\n Some Diamond Benefits\n\n A stable contract address that provides needed functionality.\n A single address with the functionality of multiple contracts (facets) that are independent from each other but can share internal functions, libraries and state variables.\n Emitting events from a single address can simplify event handling.\n A way to add, replace and remove multiple external functions atomically (in the same transaction).\n Fine-grained upgrades, so you can change just the parts of a diamond that need to be changed.\n Have greater control over when and what functions exist.\n Decentralized Autonomous Organizations (DAOs), multisig contracts and other governance systems can be used to upgrade diamonds.\n An event that shows what functions are added, replaced and removed.\n The ability to show all changes made to a diamond.\n Increase trust over time by showing all changes made to a diamond.\n A way to look at a diamond to see its current facets and functions.\n Have an immutable, trustless diamond.\n Solves the 24KB maximum contract size limitation. Diamonds can be any size.\n Separate functionality can be implemented in separate facets and used together in a diamond.\n Diamonds can be created from already deployed, existing onchain contracts.\n Larger contracts have to reduce their size by removing error messages and other things. You can keep your full functionality that you need by implementing a diamond.\n Enables zero, partial or full diamond immutability as desired, and when desired.\n The ability to develop and improve an application over time with an upgradeable diamond and then make it immutable and trustless if desired.\n Develop incrementally and let your diamond grow with your application.\n Upgrade diamonds to fix bugs, add functionality and implement new standards.\n Organize your code with a diamond and facets.\n Diamonds can be large (have many functions) but still be modular because they are compartmented with facets.\n Contract architectures that call multiple contracts in a single transaction can save gas by condensing those contracts into a single diamond and accessing state variables directly.\n Save gas by converting external functions to internal functions. This done by sharing internal functions between facets.\n Save gas by creating external functions for gas-optimized specific use cases, such as bulk transfers.\n Diamonds are designed for tooling and user-interface software.\n\n Specification\n\n Terms\n\n A diamond is a facade smart contract that delegatecalls into its facets to execute function calls. A diamond is stateful. Data is stored in the contract storage of a diamond.\n A facet is a stateless smart contract or Solidity library with external functions. A facet is deployed and one or more of its functions are added to one or more diamonds. A facet does not store data within its own contract storage but it can define state and read and write to the storage of one or more diamonds. The term facet comes from the diamond industry. It is a side, or flat surface of a diamond.\n A loupe facet is a facet that provides introspection functions. In the diamond industry, a loupe is a magnifying glass that is used to look at diamonds.\n An immutable function is an external function that cannot be replaced or removed (because it is defined directly in the diamond, or because the diamond’s logic does not allow it to be modified).\n A mapping for the purposes of this EIP is an association between two things and does not refer to a specific implementation.\n\nThe term contract is used loosely to mean a smart contract or deployed Solidity library.\n\nWhen this EIP uses function without specifying internal or external, it means external function.\n\nIn this EIP the information that applies to external functions also applies to public functions.\n\n Overview\n\nA diamond calls functions from its facets using delegatecall.\n\nIn the diamond industry diamonds are created and shaped by being cut, creating facets. In this standard diamonds are cut by adding, replacing or removing functions from facets.\n\n A Note on Implementing Interfaces\n\nBecause of the nature of diamonds, a diamond can implement an interface in one of two ways: directly (contract Contract is Interface), or by adding functions to it from one or more facets. For the purposes of this proposal, when a diamond is said to implement an interface, either method of implementation is permitted.\n\n Fallback Function\n\nWhen an external function is called on a diamond its fallback function is executed. The fallback function determines which facet to call based on the first four bytes of the call data (known as the function selector) and executes that function from the facet using delegatecall.\n\nA diamond’s fallback function and delegatecall enable a diamond to execute a facet’s function as if it was implemented by the diamond itself. The msg.sender and msg.value values do not change and only the diamond’s storage is read and written to.\n\nHere is an illustrative example of how a diamond’s fallback function might be implemented:\n\n// Find facet for function that is called and execute the\n// function if a facet is found and return any value.\nfallback() external payable {\n // get facet from function selector\n address facet = selectorTofacet[msg.sig];\n require(facet != address(0));\n // Execute external function from facet using delegatecall and return any value.\n assembly {\n // copy function selector and any arguments\n calldatacopy(0, 0, calldatasize())\n // execute function call using the facet\n let result := delegatecall(gas(), facet, 0, calldatasize(), 0, 0)\n // get any return value\n returndatacopy(0, 0, returndatasize())\n // return any return value or error back to the caller\n switch result\n case 0 {revert(0, returndatasize())}\n default {return (0, returndatasize())}\n }\n}\n\nThis diagram shows the structure of a diamond:\n\n Storage\n\nA state variable or storage layout organizational pattern is needed because Solidity’s builtin storage layout system doesn’t support proxy contracts or diamonds. The particular layout of storage is not defined in this EIP, but may be defined by later proposals. Examples of storage layout patterns that work with diamonds are Diamond Storage and AppStorage.\n\nFacets can share state variables by using the same structs at the same storage positions. Facets can share internal functions and libraries by inheriting the same contracts or using the same libraries. In these ways facets are separate, independent units but can share state and functionality.\n\nThe diagram below shows facets with their own data and data shared between them.\n\nNotice that all data is stored in the diamond’s storage, but different facets have different access to data.\n\nIn this diagram\n\n Only FacetA can access DataA\n Only FacetB can access DataB\n Only the diamond’s own code can access DataD.\n FacetA and FacetB share access to DataAB.\n The diamond’s own code, FacetA and FacetB share access to DataABD.\n\n Solidity Libraries as Facets\n\nSmart contracts or deployed Solidity libraries can be facets of diamonds.\n\nOnly Solidity libraries that have one or more external functions can be deployed to a blockchain and be a facet.\n\nSolidity libraries that contain internal functions only cannot be deployed and cannot be a facet. Internal functions from Solidity libraries are included in the bytecode of facets and contracts that use them. Solidity libraries with internal functions only are useful for sharing internal functions between facets.\n\nSolidity library facets have a few properties that match their use as facets:\n\n They cannot be deleted.\n They are stateless. They do not have contract storage.\n Their syntax prevents declaring state variables outside Diamond Storage.\n\n Adding/Replacing/Removing Functions\n\n IDiamond Interface\n\nAll diamonds must implement the IDiamond interface.\n\nDuring the deployment of a diamond any immutable functions and any external functions added to the diamond must be emitted in the DiamondCut event.\n\nA DiamondCut event must be emitted any time external functions are added, replaced, or removed. This applies to all upgrades, all functions changes, at any time, whether through diamondCut or not.\n\ninterface IDiamond {\n enum FacetCutAction {Add, Replace, Remove}\n // Add=0, Replace=1, Remove=2\n\n struct FacetCut {\n address facetAddress;\n FacetCutAction action;\n bytes4[] functionSelectors;\n }\n\n event DiamondCut(FacetCut[] _diamondCut, address _init, bytes _calldata);\n}\n\nThe DiamondCut event records all function changes to a diamond.\n\n IDiamondCut Interface\n\nA diamond contains within it a mapping of function selectors to facet addresses. Functions are added/replaced/removed by modifying this mapping.\n\nDiamonds should implement the IDiamondCut interface if after their deployment they allow modifications to their function selector mapping.\n\nThe diamondCut function updates any number of functions from any number of facets in a single transaction. Executing all changes within a single transaction prevents data corruption which could occur in upgrades done over multiple transactions.\n\ndiamondCut is specified for the purpose of interoperability. Diamond tools, software and user-interfaces should expect and use the standard diamondCut function.\n\ninterface IDiamondCut is IDiamond {\n /// @notice Add/replace/remove any number of functions and optionally execute\n /// a function with delegatecall\n /// @param _diamondCut Contains the facet addresses and function selectors\n /// @param _init The address of the contract or facet to execute _calldata\n /// @param _calldata A function call, including function selector and arguments\n /// _calldata is executed with delegatecall on _init\n function diamondCut(\n FacetCut[] calldata _diamondCut,\n address _init,\n bytes calldata _calldata\n ) external;\n}\n\nThe _diamondCut argument is an array of FacetCut structs.\n\nEach FacetCut struct contains a facet address and array of function selectors that are updated in a diamond.\n\nFor each FacetCut struct:\n\n If the action is Add, update the function selector mapping for each functionSelectors item to the facetAddress. If any of the functionSelectors had a mapped facet, revert instead.\n If the action is Replace, update the function selector mapping for each functionSelectors item to the facetAddress. If any of the functionSelectors had a value equal to facetAddress or the selector was unset, revert instead.\n If the action is Remove, remove the function selector mapping for each functionSelectors item. If any of the functionSelectors were previously unset, revert instead.\n\nAny attempt to replace or remove an immutable function must revert.\n\nBeing intentional and explicit about adding/replacing/removing functions helps catch and prevent upgrade mistakes.\n\n Executing _calldata\n\nAfter adding/replacing/removing functions the _calldata argument is executed with delegatecall on _init. This execution is done to initialize data or setup or remove anything needed or no longer needed after adding, replacing and/or removing functions.\n\nIf the _init value is address(0) then _calldata execution is skipped. In this case _calldata can contain 0 bytes or custom information.\n\n Inspecting Facets & Functions\n\n A loupe is a small magnifying glass used to look at diamonds.\n\nDiamonds must support inspecting facets and functions by implementing the IDiamondLoupe interface.\n\n IDiamondLoupe Interface\n\n// A loupe is a small magnifying glass used to look at diamonds.\n// These functions look at diamonds\ninterface IDiamondLoupe {\n struct Facet {\n address facetAddress;\n bytes4[] functionSelectors;\n }\n\n /// @notice Gets all facet addresses and their four byte function selectors.\n /// @return facets_ Facet\n function facets() external view returns (Facet[] memory facets_);\n\n /// @notice Gets all the function selectors supported by a specific facet.\n /// @param _facet The facet address.\n /// @return facetFunctionSelectors_\n function facetFunctionSelectors(address _facet) external view returns (bytes4[] memory facetFunctionSelectors_);\n\n /// @notice Get all the facet addresses used by a diamond.\n /// @return facetAddresses_\n function facetAddresses() external view returns (address[] memory facetAddresses_);\n\n /// @notice Gets the facet that supports the given selector.\n /// @dev If facet is not found return address(0).\n /// @param _functionSelector The function selector.\n /// @return facetAddress_ The facet address.\n function facetAddress(bytes4 _functionSelector) external view returns (address facetAddress_);\n}\n\nSee a reference implementation to see how this can be implemented.\n\nThe loupe functions can be used in user-interface software. A user interface calls these functions to provide information about and visualize diamonds.\n\nThe loupe functions can be used in deployment functionality, upgrade functionality, testing and other software.\n\n Implementation Points\n\nA diamond must implement the following:\n\n A diamond contains a fallback function and zero or more immutable functions that are defined within it.\n A diamond associates function selectors with facets.\n When a function is called on a diamond it executes immediately if it is an “immutable function” defined directly in the diamond. Otherwise the diamond’s fallback function is executed. The fallback function finds the facet associated with the function and executes the function using delegatecall. If there is no facet for the function then optionally a default function may be executed. If there is no facet for the function and no default function and no other mechanism to handle it then execution reverts.\n Each time functions are added, replaced or removed a DiamondCut event is emitted to record it.\n A diamond implements the DiamondLoupe interface.\n All immutable functions must be emitted in the DiamondCut event as new functions added. And the loupe functions must return information about immutable functions if they exist. The facet address for an immutable function is the diamond’s address. Any attempt to delete or replace an immutable function must revert.\n\nA diamond may implement the following:\n\n EIP-165’s supportsInterface. If a diamond has the diamondCut function then the interface ID used for it is IDiamondCut.diamondCut.selector. The interface ID used for the diamond loupe interface is IDiamondLoupe.facets.selector ^ IDiamondLoupe.facetFunctionSelectors.selector ^ IDiamondLoupe.facetAddresses.selector ^ IDiamondLoupe.facetAddress.selector.\n\nThe diamond address is the address that users interact with. The diamond address does not change. Only facet addresses can change by using the diamondCut function, or other function.\n\n Rationale\n\n Using Function Selectors\n\nUser interface software can be used to retrieve function selectors and facet addresses from a diamond in order show what functions a diamond has.\n\nThis standard is designed to make diamonds work well with user-interface software. Function selectors with the ABI of a contract provide enough information about functions to be useful for user-interface software.\n\n Gas Considerations\n\nDelegating function calls does have some gas overhead. This is mitigated in several ways:\n\n Because diamonds do not have a max size limitation it is possible to add gas optimizing functions for use cases. For example someone could use a diamond to implement the EIP-721 standard and implement batch transfer functions to reduce gas (and make batch transfers more convenient).\n Some contract architectures require calling multiple contracts in one transaction. Gas savings can be realized by condensing those contracts into a single diamond and accessing contract storage directly.\n Facets can contain few external functions, reducing gas costs. Because it costs more gas to call a function in a contract with many functions than a contract with few functions.\n The Solidity optimizer can be set to a high setting causing more bytecode to be generated but the facets will use less gas when executed.\n\n Versions of Functions\n\nSoftware or a user can verify what version of a function is called by getting the facet address of the function. This can be done by calling the facetAddress function from the IDiamondLoupe interface. This function takes a function selector as an argument and returns the facet address where it is implemented.\n\n Default Function\n\nSolidity provides the fallback function so that specific functionality can be executed when a function is called on a contract that does not exist in the contract. This same behavior can optionally be implemented in a diamond by implementing and using a default function, which is a function that is executed when a function is called on a diamond that does not exist in the diamond.\n\nA default function can be implemented a number of ways and this standard does not specify how it must be implemented.\n\n Loupe Functions & DiamondCut Event\n\nTo find out what functions a regular contract has it is only necessary to look at its verified source code.\n\nThe verified source code of a diamond does not include what functions it has so a different mechanism is needed.\n\nA diamond has four standard functions called the loupe functions that are used to show what functions a diamond has.\n\nThe loupe functions can be used for many things including:\n\n To show all functions used by a diamond.\n To query services like Etherscan or files to retrieve and show all source code used by a diamond.\n To query services like Etherscan or files to retrieve ABI information for a diamond.\n To test or verify that a transaction that adds/replaces/removes functions on a diamond succeeded.\n To find out what functions a diamond has before calling functions on it.\n To be used by tools and programming libraries to deploy and upgrade diamonds.\n To be used by user interfaces to show information about diamonds.\n To be used by user interfaces to enable users to call functions on diamonds.\n\nDiamonds support another form of transparency which is a historical record of all upgrades on a diamond. This is done with the DiamondCut event which is used to record all functions that are added, replaced or removed on a diamond.\n\n Sharing Functions Between Facets\n\nIn some cases it might be necessary to call a function defined in a different facet. Here are ways to do this:\n\n Copy internal function code in one facet to the other facet.\n Put common internal functions in a contract that is inherited by multiple facets.\n Put common internal functions in a Solidity library and use the library in facets.\n A type safe way to call an external function defined in another facet is to do this: MyOtherFacet(address(this)).myFunction(arg1, arg2)\n A more gas-efficient way to call an external function defined in another facet is to use delegatecall. Here is an example of doing that:\n DiamondStorage storage ds = diamondStorage();\nbytes4 functionSelector = bytes4(keccak256(\"myFunction(uint256)\"));\n// get facet address of function\naddress facet = ds.selectorToFacet[functionSelector];\nbytes memory myFunctionCall = abi.encodeWithSelector(functionSelector, 4);\n(bool success, bytes memory result) = address(facet).delegatecall(myFunctionCall);\n\n Instead of calling an external function defined in another facet you can instead create an internal function version of the external function. Add the internal version of the function to the facet that needs to use it.\n\n Facets can be Reusable and Composable\n\nA deployed facet can be used by any number of diamonds.\n\nDifferent combinations of facets can be used with different diamonds.\n\nIt is possible to create and deploy a set of facets that are reused by different diamonds over time.\n\nThe ability to use the same deployed facets for many diamonds reduces deployment costs.\n\nIt is possible to implement facets in a way that makes them usable/composable/compatible with other facets. It is also possible to implement facets in a way that makes them not usable/composable/compatible with other facets.\n\nA function signature is the name of a function and its parameter types. Example function signature: myfunction(uint256). A limitation is that two external functions with the same function signature can’t be added to the same diamond at the same time because a diamond, or any contract, cannot have two external functions with the same function signature.\n\nAll the functions of a facet do not have to be added to a diamond. Some functions in a facet can be added to a diamond while other functions in the facet are not added to the diamond.\n\n Backwards Compatibility\n\nThis standard makes upgradeable diamonds compatible with future standards and functionality because new functions can be added and existing functions can be replaced or removed.\n\n Reference Implementation\n\nAll the Solidity code for a complete reference implementation has been put in a single file here: Diamond.sol\n\nThe same reference implementation has been organized into multiple files and directories and also includes a deployment script and tests. Download it as a zip file: EIP2535-Diamonds-Reference-Implementation.zip\n\n Security Considerations\n\n Ownership and Authentication\n\n Note: The design and implementation of diamond ownership/authentication is not part of this standard. The examples given in this standard and in the reference implementation are just examples of how it could be done.\n\nIt is possible to create many different authentication or ownership schemes with this proposal. Authentication schemes can be very simple or complex, fine grained or coarse. This proposal does not limit it in any way. For example ownership/authentication could be as simple as a single account address having the authority to add/replace/remove functions. Or a decentralized autonomous organization could have the authority to only add/replace/remove certain functions.\n\nConsensus functionality could be implemented such as an approval function that multiple different people call to approve changes before they are executed with the diamondCut function. These are just examples.\n\nThe development of standards and implementations of ownership, control and authentication of diamonds is encouraged.\n\n Arbitrary Execution with diamondCut\n\nThe diamondCut function allows arbitrary execution with access to the diamond’s storage (through delegatecall). Access to this function must be restricted carefully.\n\n Do Not Self Destruct\n\nUse of selfdestruct in a facet is heavily discouraged. Misuse of it can delete a diamond or a facet.\n\n Function Selector Clash\n\nA function selector clash occurs when two different function signatures hash to the same four-byte hash. This has the unintended consequence of replacing an existing function in a diamond when the intention was to add a new function. This scenario is not possible with a properly implemented diamondCut function because it prevents adding function selectors that already exist.\n\n Transparency\n\nDiamonds emit an event every time one or more functions are added, replaced or removed. All source code can be verified. This enables people and software to monitor changes to a contract. If any bad acting function is added to a diamond then it can be seen.\n\nSecurity and domain experts can review the history of change of a diamond to detect any history of foul play.\n\n Copyright\n\nCopyright and related rights waived via CC0.\n\n Citation\n Please cite this document as:\n\n Nick Mudge (@mudgen), \"ERC-2535: Diamonds, Multi-Facet Proxy,\" Ethereum Improvement Proposals, no. 2535, February 2020. Available: https://eips.ethereum.org/EIPS/eip-2535.","tokens":6697,"squid":"spider-05","role":"Spec Spider","at":1791343902291,"hash":"e6c48ba0ed96f11bfe31d17369481c2cf0916ea2"}
{"url":"https://developers.jup.ag/docs/trigger/errors","domain":"developers.jup.ag","title":"Error Reference - Jupiter Developers","text":"Most error responses are JSON with an error message:\n{ \"error\": \"Order not found\" }\n\nValidation failures add a details object with per-field messages, so parse details when you get a 400:\n{ \"error\": \"Request validation failed\", \"details\": { \"orderSubType\": \"Invalid input\" } }\n\nGET /vault/register also returns the existing vault in details on a 409. Access errors from the API gateway (for example, an API key without Trigger access) use a different shape: { \"code\": 403, \"message\": \"...\" }.\nThis page covers the price-order and shared (auth, vault, deposit) endpoints. For DCA endpoint errors (/orders/dca, /orders/history/dca, /orders/dca/cancel, /confirm-cancel), see DCA errors.\n​Authentication errors apply everywhere\nEvery endpoint except POST /auth/challenge and POST /auth/verify requires a JWT in the Authorization: Bearer <token> header. A missing, malformed, or expired token returns:\n{ \"error\": \"Unauthorized\" }\n\nwith status 401. When you see a 401 on an authenticated call, re-run the challenge-response flow to get a fresh token. The tables below list the errors specific to each endpoint on top of this shared 401. The DCA endpoints share this 401 rule; their endpoint-specific errors are on the DCA pages.\n​Authentication\n​POST /auth/challenge\nStatusMeaning400Invalid request body (bad walletPubkey, or type is not message or transaction)500Failed to generate the challenge\n​POST /auth/verify\nStatusMeaning400Challenge not found, expired, or invalid request body401Invalid signature, or the challenge has expired500Internal server error\n​Vault\n​GET /vault\nStatusMeaning404Vault not found. Call GET /vault/register to create one500Failed to get vault info\n​GET /vault/register\nStatusMeaning409Vault already registered. The existing vault is returned in details500Failed to generate or store the vault\n​Deposit\n​POST /deposit/craft\nStatusMeaning400Validation error, or userAddress equals the vault address403userAddress does not match the authenticated wallet, or no vault is registered for this user500Failed to fetch vault info or craft the deposit transaction\n​Orders\n​POST /orders/price\nStatusMeaning400Validation error (price relationships, slippage range, expiry), no vault registered, userPubkey equals the vault address, an invalid signed deposit transaction, or a duplicate deposit403userPubkey does not match the authenticated wallet500Failed to fetch the trigger mint price or create the order\n​PATCH /orders/price/\nStatusMeaning400Validation error, or the order is not in the open state (only open orders can be updated)404Order not found500Failed to fetch or update the order\n​POST /orders/price/cancel/\nStatusMeaning400The order is not yet marked ready to cancel. Retry shortly403The order belongs to a different wallet404Order not found500Failed to initiate the cancellation or craft the withdrawal transaction\n​POST /orders/price/confirm-cancel/\nStatusMeaning400Invalid transaction format, an invalid or mismatched withdrawal transaction, or a withdrawal validation error404Order not found500Failed to prepare or confirm the withdrawal\n​History\n​GET /orders/history\nStatusMeaning403You do not have permission to view these orders404Order not found (when requesting a single order by id)\n​Related\nWas this page helpful?","tokens":812,"squid":"spider-02","role":"Liquidity Spider","at":1791343905790,"hash":"5942098d2b09a3acd5df31104947d27221233f8f"}
{"url":"https://squidfunk.github.io/mkdocs-material/blog/2025/11/05/zensical/","domain":"squidfunk.github.io","title":"Zensical - A modern static site generator - Material for MkDocs","text":"Zensical – A modern static site generator built by the Material for MkDocs team¶ We are thrilled to announce Zensical, our next-gen static site generator designed to simplify the process of building documentation sites. Distilled from a decade of experience, Zensical is our effort to overcome the technical limitations of MkDocs, reaching far beyond its capabilities. Zensical is the result of thousands of hours of work – built from the ground up for a modern and comfortable authoring experience, while making it easy for developers to extend and customize Zensical through its upcoming module system. Our goal is to support docs-as-code workflows with tens of thousands of pages, without compromising performance or usability. To make the transition seamless, compatibility comes first. We're putting significant effort into ensuring a smooth migration from Material for MkDocs for all users. Zensical can natively read mkdocs.yml, allowing you to build your existing project with minimal changes. As of now, a subset of plugins is supported, and we're working on feature parity in the coming months. Zensical is fully Open Source, licensed under MIT, and can be used for any purpose, including for commercial use. We're also saying goodbye to our sponsorware model, replacing it with our new offering for professional users: Zensical Spark. This allows us to stay independent, maximizing user value, as we shape the future of Zensical together with you. You can subscribe to our newsletter to stay in the loop. This is the second article in a series: Transforming Material for MkDocs Zensical – A modern static site generator built by the creators of Material for MkDocs Material for MkDocs Insiders – Now free for everyone Goodbye, GitHub Discussions What MkDocs 2.0 means for your documentation projects Why Zensical?¶ Since its initial release in 2016, Material for MkDocs has helped tens of thousands of teams to publish and maintain reliable documentation. However, in recent years, it has become apparent that we were running up against limitations of our core dependency, MkDocs. These limitations proved impossible to overcome as they are deeply rooted in its architecture. We also mentioned in our update on our foundational work that MkDocs must be considered a supply chain risk, since it's unmaintained since August 2024. It has seen no releases in over a year and is accumulating unresolved issues and pull requests. These developments have forced us to cut our ties to MkDocs as a dependency. In order to map out a path forward, we went back to the drawing board, talked to dozens of our professional users and thoroughly analyzed the MkDocs ecosystem. We didn't just want to create a fork or port of MkDocs, but decided to rethink static site generation from first principles. With Zensical, we are creating a modern static site generator, which is compatible with your content and customizations, and addresses MkDocs' limitations. While Material for MkDocs is built on top of MkDocs, Zensical consolidates both projects into one coherent stack, covering static site generation, theming, and customization. What you can expect today: 5x faster rebuilds Modern design Blazing-fast search Although we haven't reached full feature parity yet, you can already use Zensical to build your existing Material for MkDocs projects with minimal changes. You can jump to the compatibility section to learn what is already supported. What you can expect¶ Solid foundation¶ Our goal with Zensical is to create a coherent and modern stack, vertically integrating all parts of the authoring experience (AX), developer experience (DX), and user experience (UX). This gives us a significant competitive advantage over solutions that overly rely on third-party frameworks and dependencies, helping us to create much more robust Open Source software. ZRX, our new differential build engine, creates a solid foundation for Zensical, and is an Open Source project of its own. It's a fresh take on making differential data flows easy to build and a joy to work with. Most engineering effort has gone into ZRX, as it forms the backbone of Zensical, and will allow us to ship features faster. Following the principle of architectural hoisting, we moved essential, reusable functionality into ZRX, which allows us to keep Zensical's core simple and focused on static site generation. ZRX handles the heavy lifting – differential builds, caching, and data flow orchestration. With the upcoming module system and component system, both of which are on our public roadmap, Zensical will gain more degrees of freedom in the coming months, allowing you to extend and customize Zensical in ways that were previously impossible with MkDocs. Modern design¶ Zensical brings a fresh, modern design that breaks out of the Materal Design aesthetic, creating a visual foundation that is more easily brandable and adaptable to different use cases. The new design prioritizes clarity, simplicity, and usability, while having a more professional finish: Our public roadmap, built with Zensical Right now, the layout and site structure of Zensical match Material for MkDocs closely, as we're focusing on ensuring maximum compatibility. Once we finish work on our upcoming component system, we'll provide an alternative that is much more flexible and adaptable, and can be tailored to different use cases and branding requirements more easily. You can also keep the Material for MkDocs look and feel with a single line of configuration. Blazing-fast search¶ Client-side search isn't a compromise – for the vast majority of static sites, it's the best solution, since it's faster, involves zero maintenance, and doesn't require you to pay for a service. As covered in depth in the first part of this series, the current search implementation in Material for MkDocs has severe limitations, and is based on a now unmaintained library, which is why we decided to build a new search engine from scratch. It's based on the same goals as Zensical itself: performance, flexibility, and extensibility. Disco, our modular and blazing-fast client-side search engine, is exclusively available in Zensical. When you build your site with Zensical, your users will immediately benefit from Disco's improved ranking algorithm, as well as its filtering and aggregation capabilities: Disco on zensical.org We'll release Disco as an MIT-licensed standalone Open Source project soon. With the feedback of our professional users in Zensical Spark, we're going to evolve the search experience, turning Disco into a highly configurable and customizable search engine that adapts to your needs. You can subscribe to our newsletter to receive news about Disco. Authoring experience¶ Slow feedback loops can be a major pain point when writing documentation. Almost all of us know the feeling of waiting for the static site generator to finish building the site, just to see a small change reflected in the output. With Zensical, we're finally addressing this issue. It's important to understand that we're not yet utilizing the differential capabilities of ZRX to the fullest extent, as we're forced to make several compromises to ensure maximum compatibility with Material for MkDocs at the moment. Markdown rendering needs to go through Python Markdown, which forces us to pay for extra marshalling costs. While the initial build can sometimes be slower than with MkDocs, repeated builds – especially when serving the site – are already 4 to 5x faster, as only changed files need to be rebuilt. We're also working on a new Markdown toolchain based on a CommonMark-compliant parser written in Rust, which will make Markdown processing significantly faster. We'll be tackling this as part of the upcoming component system, which we'll start working on in early 2026. Once our new Markdown toolchain is ready, we'll provide automated tools to translate between Python Markdown and CommonMark, so you don't need to manually migrate your content. Maximum compatibility¶ Compatibility with Material for MkDocs is our top priority. We understand that switching to a new static site generator can be challenging, especially for large projects with many customizations. Therefore, we've put significant effort into ensuring that Zensical understands mkdocs.yml configuration files, so that you can build your projects with minimal changes. This means your existing Markdown files, template overrides, CSS and JavaScript extensions don't need to be touched, primarily because we did not change the generated HTML, and rely on Python Markdown for processing your content. However, plugins are a different story. In MkDocs, practically all plugins have side effects, making it impossible to parallelize builds. We started from first principles and asked: what should extensibility look like in a modern static site generator? Our answer is the upcoming module system, which takes a fundamentally different approach based on four core principles: Modules can inject, extend, and re-define functionality Modules are deterministic through topological ordering Modules foster reusability, with the possibility to remix them Modules can cooperate through well-defined contracts We're working on shipping essential functionality as provided by MkDocs plugins as built-in modules. In early 2026, we will open the module system to third-party developers, so they can start building their own modules, as we see Zensical as the heart of a thriving ecosystem. Zensical Spark¶ Material for MkDocs was originally built for individual developers and small teams, but over the years it found its way into the workflows of large organizations and professional documentation teams – far beyond what we ever anticipated. With that came a new set of requirements: scalability, dedicated support, and a direct line to the team behind the project. Zensical Spark is our answer to that. Rather than building software that organizations need to adapt to, we built Zensical from the ground up around the needs of professional teams – handling documentation of any size, seamlessly, out of the box. As a Spark member, you get early access to new features, hands-on migration support, and direct access to the Zensical team. Your participation in Zensical Spark directly shapes the direction of the project, and your financial contribution ensures that we can continue to develop and maintain Zensical as a set of OSI-compliant Open Source projects. Learn more about Zensical Spark or reach out to us at members@zensical.org. Zensical is built for everyone – individual developers, small teams, and large organizations alike. Zensical Spark provides you with dedicated support from the team that built Material for MkDocs for the last decade, ensuring Zensical adapts to your organization as you grow. We're growing our team¶ We're also excited to announce that we're growing our team: Timothée Mazzucotelli, also known as @pawamoy, is joining Zensical! At Zensical, Tim is focusing on providing the same seamless experience for generating API reference documentation from source code (via docstrings) as he has done with mkdocstrings, the second biggest project in the MkDocs ecosystem. With his expertise, and Zensical's new stack, we'll be pushing the boundaries of what's possible with API reference documentation. Goodbye, GitHub Sponsors¶ Thank you! To all of you who have supported us over the years through GitHub Sponsors – we are incredibly grateful for your support. It has been invaluable in helping us to build, maintain and evolve Material for MkDocs, and we couldn't have done it without you. Seriously, thank you! Material for MkDocs gave us something invaluable: experience building for tens of thousands of users, and the opportunity to build a team around Open Source software. It showed us that making a living from Open Source isn't just possible – we grew it into one of the largest sponsorware projects on GitHub and inspired others to pursue similar paths. Now we're breaking new ground. Zensical is our next chapter, and we're professionalizing how we approach Open Source development. Our vision is to make Zensical free for everyone to use while building a sustainable business around it through [our new approach]. This transition means saying goodbye to GitHub Sponsors. It has served us exceptionally well, but as we professionalize and scale, we're making the leap from personal project to company – building a business and team that can meet the growing demands of professional users while staying true to our values. We're doubling down on Open Source, developing software for everyone. If you want to continue supporting our work, please subscribe to our newsletter. We'll be providing new methods to support us in the coming months, with the possibility of getting exclusive goodies. Looking Ahead¶ Material for MkDocs grew organically like a plant in a pot that eventually became too small. With Zensical, we're building on solid foundations designed to grow with us – and with you. Material for MkDocs is in maintenance mode We want to be transparent about the risks of staying on Material for MkDocs or on forks of both Material for MkDocs and MkDocs. With MkDocs 1.x unmaintained and facing fundamental supply chain concerns, its future is uncertain and we cannot guarantee Material for MkDocs will continue working reliably. MkDocs 2.0 will introduce breaking changes – something we analyzed thoroughly in our MkDocs 2.0 article. We're aware that transitioning takes time, which is why we commit to supporting Material for MkDocs for at least the next 12 months, fixing critical bugs and security vulnerabilities as needed. If you have questions about your specific situation or need help planning a migration, don't hesitate to reach out at hello@zensical.org. Where we'll be in 12 months¶ Over the next 12 months, following our phased transition strategy, we'll reach Phase 2 and 3 – introducing our module system and component system, as well as CommonMark support. By replacing Python Markdown with a Rust-based Markdown parser, we'll unlock performance improvements and the modularity needed for flexible templating. This is where Zensical truly starts to unfold its capabilities. Zensical is already powering real projects due to extensive compatibility with Material for MkDocs. We're actively working on closing the gap to reach full feature parity. You can install Zensical now, and build your existing Material for MkDocs projects with it. If you run into a bug, please don't hesitate to open an issue – we're here to help. Connect with us¶ If you have questions we haven't addressed, please reach out to us at hello@zensical.org. We're currently collecting questions from the community about Zensical, and will address them in an FAQ section as part of our documentation in the coming weeks. We're incredibly thankful that you have been part of our journey so far. With Zensical, we're embarking on a new chapter, and we couldn't be more excited to have you with us. You can subscribe to our newsletter to stay in the loop.","tokens":3773,"squid":"spider-06","role":"Security Spider","at":1791343909878,"hash":"3f2e1113f366f16f3c9e24b2810d2e81045a6088"}
{"url":"https://eips.ethereum.org/EIPS/eip-101","domain":"eips.ethereum.org","title":"EIP-101: Serenity Currency and Crypto Abstraction","text":"🚧 Stagnant\n\n Standards Track: Core\n\n EIP-101: Serenity Currency and Crypto Abstraction\n\n Authors\n Vitalik Buterin (@vbuterin)\n\n Created\n 2015-11-15\n\n Specification\n\n Accounts now have only two fields in their RLP encoding: code and storage.\n Ether is no longer stored in account objects directly; instead, at address 0, we premine a contract which contains all ether holdings. The eth.getBalance command in web3 is remapped appropriately.\n msg.value no longer exists as an opcode.\n A transaction now only has four fields: to, startgas, data and code.\n Aside from an RLP validity check, and checking that the to field is twenty bytes long, the startgas is an integer, and code is either empty or hashes to the to address, there are no other validity constraints; anything goes. However, the block gas limit remains, so miners are disincentivized from including junk.\n Gas is charged for bytes in code at the same rate as data.\n When a transaction is sent, if the receiving account does not yet exist, the account is created, and its code is set to the code provided in the transaction; otherwise the code is ignored.\n A tx.gas opcode is added alongside the existing msg.gas at index 0x5c; this new opcode allows the transaction to access the original amount of gas allotted for the transaction\n\nNote that ECRECOVER, sequence number/nonce incrementing and ether are now nowhere in the bottom-level spec (NOTE: ether is going to continue to have a privileged role in Casper PoS). To replicate existing functionality under the new model, we do the following.\n\nSimple user accounts can have the following default standardized code:\n\n# We assume that data takes the following schema:\n# bytes 0-31: v (ECDSA sig)\n# bytes 32-63: r (ECDSA sig)\n# bytes 64-95: s (ECDSA sig)\n# bytes 96-127: sequence number (formerly called \"nonce\")\n# bytes 128-159: gasprice\n# bytes 172-191: to\n# bytes 192+: data\n\n# Get the hash for transaction signing\n~mstore(0, msg.gas)\n~calldatacopy(32, 96, ~calldatasize() - 96)\nh = sha3(96, ~calldatasize() - 96)\n# Call ECRECOVER contract to get the sender\n~call(5000, 3, [h, ~calldataload(0), ~calldataload(32), ~calldataload(64)], 128, ref(addr), 32)\n# Check sender correctness\nassert addr == 0x82a978b3f5962a5b0957d9ee9eef472ee55b42f1\n# Check sequence number correctness\nassert ~calldataload(96) == self.storage[-1]\n# Increment sequence number\nself.storage[-1] += 1\n# Make the sub-call and discard output\n~call(msg.gas - 50000, ~calldataload(160), 192, ~calldatasize() - 192, 0, 0)\n# Pay for gas\n~call(40000, 0, [SEND, block.coinbase, ~calldataload(128) * (tx.gas - msg.gas + 50000)], 96, 0, 0)\n\nThis essentially implements signature and nonce checking, and if both checks pass then it uses all remaining gas minus 50000 to send the actual desired call, and then finally pays for gas.\n\nMiners can follow the following algorithm upon receiving transactions:\n\n Run the code for a maximum of 50000 gas, stopping if they see an operation or call that threatens to go over this limit\n Upon seeing that operation, make sure that it leaves at least 50000 gas to spare (either by checking that the static gas consumption is small enough or by checking that it is a call with msg.gas - 50000 as its gas limit parameter)\n Pattern-match to make sure that gas payment code at the end is exactly the same as in the code above.\n\nThis process ensures that miners waste at most 50000 gas before knowing whether or not it will be worth their while to include the transaction, and is also highly general so users can experiment with new cryptography (eg. ed25519, Lamport), ring signatures, quasi-native multisig, etc. Theoretically, one can even create an account for which the valid signature type is a valid Merkle branch of a receipt, creating a quasi-native alarm clock.\n\nIf someone wants to send a transaction with nonzero value, instead of the current msg.sender approach, we compile into a three step process:\n\n In the outer scope just before calling, call the ether contract to create a cheque for the desired amount\n In the inner scope, if a contract uses the msg.value opcode anywhere in the function that is being called, then we have the contract cash out the cheque at the start of the function call and store the amount cashed out in a standardized address in memory\n In the outer scope just after calling, send a message to the ether contract to disable the cheque if it has not yet been cashed\n\n Rationale\n\nThis allows for a large increase in generality, particularly in a few\nareas:\n\n Cryptographic algorithms used to secure accounts (we could reasonably say that Ethereum is quantum-safe, as one is perfectly free to secure one’s account with Lamport signatures). The nonce-incrementing approach is now also open to revision on the part of account holders, allowing for experimentation in k-parallelizable nonce techniques, UTXO schemes, etc.\n Moving ether up a level of abstraction, with the particular benefit of allowing ether and sub-tokens to be treated similarly by contracts\n Reducing the level of indirection required for custom-policy accounts such as multisigs\n\nIt also substantially simplifies and purifies the underlying Ethereum protocol, reducing the minimal consensus implementation complexity.\n\n Implementation\n\nComing soon.\n\n Citation\n Please cite this document as:\n\n Vitalik Buterin (@vbuterin), \"EIP-101: Serenity Currency and Crypto Abstraction [STAGNANT],\" Ethereum Improvement Proposals, no. 101, November 2015. Available: https://eips.ethereum.org/EIPS/eip-101.","tokens":1376,"squid":"spider-05","role":"Spec Spider","at":1791343915764,"hash":"4cf230f5d61a8c765eba24e867b911eceeba68ca"}
{"url":"https://developers.jup.ag/docs/tool-kits/plugin","domain":"developers.jup.ag","title":"Integrate Jupiter Plugin - Jupiter Developers","text":"Jupiter Plugin is an open-source, lightweight, plug-and-play version of Jupiter Ultra Swap, allowing you to bring the exact jup.ag swap experience to any application.\nTry out the Plugin Playground to experience the entire suite of customizations.\nTo view the open-source code, visit the GitHub repository.\n\nQUICK STARTTo quick start your integration, check out the Next.js, React or HTML app examples.Refer to Customization and FAQ for more information.\n​Key Features\n\nSeamless Integration: Embed Jupiter’s swap functionality directly into your application without redirects.\nMultiple Display Options: Choose between integrated, widget, or modal display modes.\nCustomizable Options: Configure the swap form to match your application’s needs.\nRPC-less: Integrate Plugin without any RPCs, Ultra handles transaction sending, wallet balances and token information.\nUltra Mode: Access to all features of Ultra Mode, read more about it in the Ultra Swap API docs.\n\n​Getting Started\nWhen integrating Plugin, there are a few integration methods to think about, and choose the one that best fits your application’s architecture and requirements.\n​Integration Methods\n\nUsing Window Object - Simplest way to add and initialize Plugin.\nUsing NPM Package - Install via npm install @jup-ag/plugin and initialize as a module (will require you to maintain its dependencies).\n\n​Wallet Integration\n\nWallet Standard Support: For applications without existing wallet provider, Plugin will provide a wallet adapter and connection - powered by Unified Wallet Kit.\nPassthrough Wallet: For applications with existing wallet provider(s), set enableWalletPassthrough=true with context, and Plugin will allow the application to pass through the existing wallet provider’s connection to Plugin.\n\n​Adding Fees to plugin\n\nReferral Account: You can create a referral account via scripts or Referral Dashboard.\nReferral Fee: You can set the referral fee and account in the formProps interface when you initialize the Plugin.\n\n​Quick Start Guides\nIn the next sections, we’ll walk you through the steps to integrate Jupiter Plugin into different types of web applications from scratch.\n\nBy integrating Jupiter Plugin into your application, you can seamlessly integrate a fully functional swap interface into your application with minimal effort, while staying at the forefront of Solana DeFi innovation.Was this page helpful?","tokens":598,"squid":"spider-02","role":"Liquidity Spider","at":1791343921357,"hash":"757269edafaec64b3fb87b5867f5112e44fcf392"}
{"url":"https://eips.ethereum.org/EIPS/eip-86","domain":"eips.ethereum.org","title":"EIP-86: Abstraction of transaction origin and signature","text":"🚧 Stagnant\n\n Standards Track: Core\n\n EIP-86: Abstraction of transaction origin and signature\n\n Authors\n Vitalik Buterin (@vbuterin)\n\n Created\n 2017-02-10\n\n Summary\n\nImplements a set of changes that serve the combined purpose of “abstracting out” signature verification and nonce checking, allowing users to create “account contracts” that perform any desired signature/nonce checks instead of using the mechanism that is currently hard-coded into transaction processing.\n\n Parameters\n\n METROPOLIS_FORK_BLKNUM: TBD\n CHAIN_ID: same as used for EIP 155 (ie. 1 for mainnet, 3 for testnet)\n NULL_SENDER: 2**160 - 1\n\n Specification\n\nIf block.number >= METROPOLIS_FORK_BLKNUM, then:\n\n If the signature of a transaction is (CHAIN_ID, 0, 0) (ie. r = s = 0, v = CHAIN_ID), then treat it as valid and set the sender address to NULL_SENDER\n Transactions of this form MUST have gasprice = 0, nonce = 0, value = 0, and do NOT increment the nonce of account NULL_SENDER.\n Create a new opcode at 0xfb, CREATE2, with 4 stack arguments (value, salt, mem_start, mem_size) which sets the creation address to sha3(sender + salt + sha3(init code)) % 2**160, where salt is always represented as a 32-byte value.\n Add to all contract creation operations, including transactions and opcodes, the rule that if a contract at that address already exists and has non-empty code OR non-empty nonce, the operation fails and returns 0 as if the init code had run out of gas. If an account has empty code and nonce but nonempty balance, the creation operation may still succeed.\n\n Rationale\n\nThe goal of these changes is to set the stage for abstraction of account security. Instead of having an in-protocol mechanism where ECDSA and the default nonce scheme are enshrined as the only “standard” way to secure an account, we take initial steps toward a model where in the long term all accounts are contracts, contracts can pay for gas, and users are free to define their own security model.\n\nUnder EIP 86, we can expect users to store their ether in contracts, whose code might look like the following (example in Serpent):\n\n# Get signature from tx data\nsig_v = ~calldataload(0)\nsig_r = ~calldataload(32)\nsig_s = ~calldataload(64)\n# Get tx arguments\ntx_nonce = ~calldataload(96)\ntx_to = ~calldataload(128)\ntx_value = ~calldataload(160)\ntx_gasprice = ~calldataload(192)\ntx_data = string(~calldatasize() - 224)\n~calldataload(tx_data, 224, ~calldatasize())\n# Get signing hash\nsigning_data = string(~calldatasize() - 64)\n~mstore(signing_data, tx.startgas)\n~calldataload(signing_data + 32, 96, ~calldatasize() - 96)\nsigning_hash = sha3(signing_data:str)\n# Perform usual checks\nprev_nonce = ~sload(-1)\nassert tx_nonce == prev_nonce + 1\nassert self.balance >= tx_value + tx_gasprice * tx.startgas\nassert ~ecrecover(signing_hash, sig_v, sig_r, sig_s) == <pubkey hash here>\n# Update nonce\n~sstore(-1, prev_nonce + 1)\n# Pay for gas\n~send(MINER_CONTRACT, tx_gasprice * tx.startgas)\n# Make the main call\n~call(msg.gas - 50000, tx_to, tx_value, tx_data, len(tx_data), 0, 0)\n# Get remaining gas payments back\n~call(20000, MINER_CONTRACT, 0, [msg.gas], 32, 0, 0)\n\nThis can be thought of as a “forwarding contract”. It accepts data from the “entry point” address 2**160 - 1 (an account that anyone can send transactions from), expecting that data to be in the format [sig, nonce, to, value, gasprice, data]. The forwarding contract verifies the signature, and if the signature is correct it sets up a payment to the miner and then sends a call to the desired address with the provided value and data.\n\nThe benefits that this provides lie in the most interesting cases:\n\n Multisig wallets: currently, sending from a multisig wallet requires each operation to be ratified by the participants, and each ratification is a transaction. This could be simplified by having one ratification transaction include signatures from the other participants, but even still it introduces complexity because the participants’ accounts all need to be stocked up with ETH. With this EIP, it will be possible to just have the contract store the ETH, send a transaction containing all signatures to the contract directly, and the contract can pay the fees.\n Ring signature mixers: the way that ring signature mixers work is that N individuals send 1 coin into a contract, and then use a linkable ring signature to withdraw 1 coin later on. The linkable ring signature ensures that the withdrawal transaction cannot be linked to the deposit, but if someone attempts to withdraw twice then those two signatures can be linked and the second one prevented. However, currently there is a privacy risk: to withdraw, you need to have coins to pay for gas, and if these coins are not properly mixed then you risk compromising your privacy. With this EIP, you can pay for gas straight our of your withdrawn coins.\n Custom cryptography: users can upgrade to ed25519 signatures, Lamport hash ladder signatures or whatever other scheme they want on their own terms; they do not need to stick with ECDSA.\n Non-cryptographic modifications: users can require transactions to have expiry times (this being standard would allow old empty/dust accounts to be flushed from the state securely), use k-parallelizable nonces (a scheme that allows transactions to be confirmed slightly out-of-order, reducing inter-transaction dependence), or make other modifications.\n\n(2) and (3) introduce a feature similar to bitcoin’s P2SH, allowing users to send funds to addresses that provably map to only one particular piece of code. Something like this is crucial in the long term because, in a world where all accounts are contracts, we need to preserve the ability to send to an account before that account exists on-chain, as that’s a basic functionality that exists in all blockchain protocols today.\n\n Miner and transaction replaying strategy\n\nNote that miners would need to have a strategy for accepting these transactions. This strategy would need to be very discriminating, because otherwise they run the risk of accepting transactions that do not pay them any fees, and possibly even transactions that have no effect (eg. because the transaction was already included and so the nonce is no longer current).\n\nOne simple strategy is to have a set of regexps that the to address of an account would be checked against, each regexp corresponding to a “standard account type” which is known to be “safe” (in the sense that if an account has that code, and a particular check involving the account balances, account storage and transaction data passes, then if the transaction is included in a block the miner will get paid), and mine and relay transactions that pass these checks.\n\nOne example would be to check as follows:\n\n Check that the to address has code which is the compiled version of the Serpent code above, with <pubkey hash here> replaced with any public key hash.\n Check that the signature in the transaction data verifies with that key hash.\n Check that the gasprice in the transaction data is sufficiently high\n Check that the nonce in the state matches the nonce in the transaction data\n Check that there is enough ether in the account to pay for the fee\n\nIf all five checks pass, relay and/or mine the transaction.\n\nA looser but still effective strategy would be to accept any code that fits the same general format as the above, consuming only a limited amount of gas to perform nonce and signature checks and having a guarantee that transaction fees will be paid to the miner. Another strategy is to, alongside other approaches, try to process any transaction that asks for less than 250,000 gas, and include it only if the miner’s balance is appropriately higher after executing the transaction than before it.\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), \"EIP-86: Abstraction of transaction origin and signature [STAGNANT],\" Ethereum Improvement Proposals, no. 86, February 2017. Available: https://eips.ethereum.org/EIPS/eip-86.","tokens":2011,"squid":"spider-05","role":"Spec Spider","at":1791343937922,"hash":"bbd0bdd9248d7c18fd4ed5bd0775ea27d2b854c3"}
{"url":"https://phantom.com/developer-portal-terms","domain":"phantom.com","title":"Phantom Developer Portal Terms of Service","text":"Phantom Developer Portal Terms of ServicePHANTOM TECHNOLOGIES, INC. • Effective Date: Feb 10, 2026Agreement to Portal Terms.By using the Phantom Developer Portal (the “Portal” or the “Platform”) you are agreeing to these Phantom Developer Portal Terms of Service (these “Portal Terms”). These Portal Terms set forth the terms and conditions that govern your access and use of the Portal and Services (as defined below) and constitute a legally binding agreement between Phantom Technologies, Inc. (“Phantom” or “we”) and you and/or the entity you represent (“you”, “your” or “user”). References to Phantom or we contained herein include Phantom’s affiliates and subsidiaries. By entering into these Portal Terms on behalf of a company, legal entity or other organization, you represent that you have the authority to bind the entity to these Portal Terms. If there is a conflict between these Portal Terms and any separate signed written agreement or Order Form between Phantom and you then the terms of that separate agreement or Order Form will control.These Portal Terms are effective as of the first day that you use any of the APIs, SDKs or other tools and functionality provided to via the Portal (collectively, the “Services”) either at the time of first use or which may be added to the Portal thereafter.ARBITRATION NOTICE: THESE PORTAL TERMS CONTAIN AN ARBITRATION CLAUSE FOR USERS IN THE UNITED STATES AND CANADA, WHICH PROVISION IS CONTAINED BELOW UNDER THE HEADING “DISPUTE RESOLUTION”. IF YOU ARE LOCATED IN THE UNITED STATES OR CANADA, YOU AGREE THAT DISPUTES BETWEEN YOU AND PHANTOM WILL BE RESOLVED BY BINDING ARBITRATION, AND YOU WAIVE YOUR RIGHT TO A TRIAL BY JURY OR TO PARTICIPATE AS A PLAINTIFF OR CLASS MEMBER IN ANY PURPORTED CLASS ACTION OR OTHER REPRESENTATIVE PROCEEDING.Privacy Policy.By agreeing to these Portal Terms and using the Services you also consent to the collection, use, disclosure and other handling of information as described in our Privacy Policy. The Privacy Policy is incorporated by reference to these Portal Terms in its entirety and all references to these Portal Terms include a reference to the Privacy Policy.The Children’s Online Privacy Protection Act (“COPPA”) requires that online service providers obtain parental consent before they knowingly collect personally identifiable information online from children who are under 13 years of age. We do not knowingly collect or solicit personally identifiable information from children under 16 years of age; if you are a child under 16 years of age, please do not attempt to register for or otherwise use the Services or send us any personal information. If we learn we have collected personal information from a child under 16 years of age, we will delete that information as quickly as possible. If you believe that a child under 16 years of age may have provided us personal information, please contact us at privacy@phantom.app.Copyright Dispute Policy.We respect others’ intellectual property rights, and we reserve the right to delete or disable User Content (as defined below) alleged to be infringing, and to terminate the accounts of repeat alleged infringers; to review our complete Copyright Dispute Policy and learn how to report potentially infringing content, click here.Updates to these Portal Terms or Services.We may modify these Portal Terms at any time at any time by posting revised Portal Terms on the Phantom website or by providing you with a copy. These Portal Terms will be effective as of the date posted and by continuing use of the Services after these Portal Terms have been modified you agree to be bound by the modified Portal Terms. If you do not agree to be bound by the modified Portal Terms, then you must refrain from using the Services. Unless expressly stated otherwise, any modifications to these Portal Terms shall apply to all claims, actions, and disputes arising at any time, including those that accrued prior to the effective date of such modifications.We may also update, suspend or discontinue the Services at any time without notice to you. You are responsible for reviewing API and SDK documentation regularly and ensuring that your systems are properly configured to be compatible with the Services. You acknowledge that updates to the Services may adversely impact how your application interacts with the Services and that you alone are responsible for ensuring that the Services are properly integrated with your products and services.Phantom Portal Access and Account.Contingent upon your compliance with these Portal Terms, Phantom grants you a non-exclusive, limited, personal, non-sublicensable, non-transferable right and license to access the Portal and any Services contained therein during the Term.In order to access and use the Services you will be required to create a Phantom Portal Account using your email address. You may be subject to additional registration requirements in order to access certain Services or to be eligible for revenue partnerships, and revenue partnerships may be subject to additional terms. We reserve the right to suspend or terminate your Account if you provide inaccurate, untrue, or incomplete information; if you fail to comply with the Account registration requirements; or pending an investigation into possible violations of the Terms.You are responsible for maintaining the confidentiality of the login or authentication credentials associated with your Account. We may provide the ability for you to grant additional users access to your Account under separate usernames or credentials (“Authorized Users”). Authorized Users will also be required to agree to and comply with these Portal Terms. You agree that you are responsible for all activities that occur under your Account if your login credentials were used to access the Account, even if such access was not authorized by you. You are also responsible for any activities of Authorized Users if their login credentials were used to access the Account, even if such access was not authorized by the applicable Authorized User. If you or any Authorized User’s login credentials are compromised you agree to notify Phantom immediately so that steps can be taken to secure your Account.In connection with your use of the Services you may be provided with a Client ID, which is a unique identifier for your application and must be used in connection with certain APIs and SDKs available via the Portal. You, along with any Authorized Users are responsible for maintaining the confidentiality of your Client ID. You may not sell, sublicense, transfer or otherwise disclose your Client ID to any third party.Embedded Wallets; Relationship with End Users.The Services include, among other things, access to the Phantom embedded wallet SDK (the “Embedded Wallets” product). Embedded Wallets provides users of your application (“End Users”) the ability to create a digital asset wallet directly on your application’s website or via your mobile application without having to navigate to a separate site in order to create a wallet or download a wallet extension. If you integrate Embedded Wallets via the Services you may be provided with a unique API key which is used to connect your application with Embedded Wallets created by End Users on your site and you will also be able to customize your End Users’ Embedded Wallet experience.You understand that while the End Users’ interactions with and any transactions made via your application will be subject to your application’s terms and conditions and privacy policy, their use of the Embedded Wallet will be subject to the Phantom Wallet Terms of Use and Privacy Policy.All wallets provided by Phantom, including Embedded Wallets, are self-custodial, meaning that the user maintains control over the private keys, transactions, and assets within their wallet. Phantom is not a custodian of assets held within Embedded Wallets and does not have the ability to initiate or authorize any transactions on behalf of End Users.User Content; Acceptable Use.You may be able to make available content or information to Phantom users via the Services (“User Content”). Phantom has the absolute discretion to remove User Content at any time and for any reason without notice to you. User Content must adhere to the acceptable use restrictions outlined in this section. Any violation of the acceptable use restrictions may result in the suspension or termination of your access to the Portal or certain Services. You agree to abide by the restrictions outlined here and will not encourage, enable or otherwise facilitate others to violate these restrictions.By making User Content available through the Services, you hereby do and shall grant Phantom a worldwide, non-exclusive, perpetual, royalty-free, fully paid, sublicensable and transferable license to use, edit, modify, truncate, aggregate, reproduce, distribute, prepare derivative works of, display, perform, and otherwise fully exploit the User Content in connection with Phantom’s website, the Services, the Portal and our (and our successors’ and assigns’) businesses, including without limitation for promoting and redistributing part or all of this website or the Services (and derivative works thereof) in any media formats and through any media channels (including, without limitation, third party websites and feeds), and including after your termination of your account or your use of the Portal and the Services. For clarity, the foregoing license grant to us does not affect your other ownership or license rights in your User Content, including the right to grant additional licenses to your User Content, unless otherwise agreed in writing. You represent and warrant that you have all rights to grant such licenses to us without infringement or violation of any third party rights, including without limitation, any privacy rights, publicity rights, copyrights, trademarks, contract rights, or any other intellectual property or proprietary rights.As a condition of using the Portal and the Services, you represent, warrant and agree that you will not submit User Content or otherwise use the Portal and the Services in ways that:Use the Portal or the Services in a manner not expressly authorized by these Portal Terms;Violate, misappropriate, or infringe the rights of Phantom, its licensors, or others, including privacy, publicity, intellectual property or other rights;Are illegal, obscene, defamatory, threatening, intimidating, harassing, hateful or racially or ethnically offensive, or that instigate or encourage conduct that would be illegal or otherwise inappropriate or objectionable;Involve falsehoods, misrepresentations, or misleading statements, including statements that could constitute market manipulation or any other activities in efforts to defraud Phantom or End Users;Violate any applicable law or regulation, including, without limitation any applicable anti-money laundering, anti-proliferation and anti-terrorism financing laws and sanctions programs, including but not limited to, the U.S. Bank Secrecy Act, those enforced by the U.S. Department of Treasury’s Office of Foreign Assets Controls, or the U.S. federal securities laws, including the Securities Act of 1933, the Securities Exchange Act of 1934 or any applicable rules promulgated thereunder;Use the Portal or Services in a manner that could cause Phantom to violate any applicable law or regulation;Avoid, bypass, remove, deactivate, impair, descramble or otherwise circumvent any technological measure implemented by us or any of our service providers or any other third party to protect the Portal or the Services;Interfere with, or attempt to interfere with, the access to the Portal or Services for other Portal users or with End User’s access to the Phantom wallet, including, without limitation, transmitting a virus or other malware, overloading, flooding, spamming, or making any attempts to do the same;Decompile, reverse engineer, or otherwise attempt to obtain the source code or underlying ideas or information of or relating to the Portal or the Services;Jeopardize the security of your or your Authorized Users’ respective login credentials and Client IDs, or any other user’s account (such as allowing someone else to access the Portal as you);Fail to maintain security best-practices with an appropriate threat/risk model, such as promptly updating vulnerable dependencies and enforcing security controls;Attempt, in any manner, to obtain the Client ID, login credentials, password, or other security information from any other user;Configure Embedded Wallets in a manner that is misleading or is intended to divert, misappropriate or otherwise obtain unauthorized access to assets stored within Embedded Wallets or any other Phantom wallet product;May be connected to businesses that pose elevated financial, legal, or regulatory risk, including but not limited to adult content and services, drugs and drug paraphernalia or substances designed to mimic illegal drugs, regulated products or services (e.g., marijuana dispensaries, weapons, controlled substances, pharmaceuticals, or gambling products), and any other business that we believe poses elevated regulatory or legal risk.Could cause Phantom or any of its affiliates to violate any applicable law, regulation, rule, or contractual term, representation, or warranty.You understand that any unauthorized access to an Embedded Wallet could result in the loss or theft of any asset held in the Embedded Wallet. If you notice any unauthorized or suspicious activity in Embedded Wallets or accounts that are related or linked to the Services or Portal, you agree to notify Phantom immediately through your account or by visiting help.phantom.com. You will, at all times, be responsible for the acts or omissions of any person who accesses an account or Embedded Wallet provided through the Services.From time to time, we may request you provide additional information, certifications, or attestations regarding your use of the Services. You agree to provide the requested information in the requested timeframe and form. Such certifications and attestations must be provided by an authorized representative of yours.Phantom may take action against you, including suspending or ending your access to the Services, with or without notice to you, if we believe, in our sole discretion that:You have violated or may have violated these Terms or any other applicable terms or policies, or You or your use of the Services, including your User Content, is negatively impacting Phantom or people who use Phantom products;It is needed to comply with applicable laws or regulations or otherwise required or requested by a court order or governmental authority; orIt is needed to protect Phantom from legal or regulatory liability.Rights & Content Ownership.You retain your ownership rights in your application. We reserve and retain all right, title and interest, including all intellectual property rights in the content, features, and functionality made available on or through the Portal or the Services, including but not limited to the APIs, SDKs or other software made available through the Portal, all information, documentation, services and branding an all improvements, enhancements, modifications and derivative works thereto, unless they are expressly granted to you in these Portal Terms. All rights not expressly granted by these Portal Terms are retained by us.If you use the Embedded Wallet Service, you represent and warrant that your application, including its name and all of its content, does not infringe upon our intellectual property rights or the rights of any third party. Should you discover, determine or believe that your application infringes any intellectual property rights you agree to notify us immediately.Representations and Warranties.You represent and warrant that:If you are an individual, you are of legal age to enter into a binding contract. If you are agreeing to these Portal Terms on behalf of a legal entity, you represent and warrant that you are authorized to agree to these Portal Terms on that entity’s behalf and bind them to these Portal Terms.If you are entering into these Portal Terms on behalf of a legal entity you further represent that (a) it is a duly organized, validly existing, and in good standing under the laws of the jurisdiction in which it is organized; (b) it has full power and authority, and has obtained all approvals, permissions and consents necessary, to enter into these Portal Terms and to perform its obligations hereunder; (c) these Portal Terms are legally binding upon it and enforceable in accordance with its terms; and (d) the execution, delivery and performance of these Portal Terms do not and will not conflict with any agreement, instrument, judgment or understanding, oral or written, to which it is a party or by which it may be bound.You agree to comply with all applicable U.S. and non-U.S. export control and trade sanctions laws (“Export Laws”). Without limiting the foregoing, you may not use the Portal or the Services if (i) you are in, under the control of, or a national or resident of Cuba, Iran, North Korea, or Russian-occupied regions of Donetsk, Luhansk or Crimea, or any other country subject to United States embargo, UN Security Council resolutions, HM Treasury’s financial or other sanctions regime, or if you are on the U.S. Treasury Department’s Specially Designated Nationals List or the U.S. Commerce Department's Denied Persons List, Unverified List, Entity List HM Treasury’s financial or other sanctions regime; or (ii) you intend to provide any of your products or services to Cuba, Iran, North Korea, or Russian-occupied regions of Donetsk, Luhansk or Crimea, or any other country subject to United States embargo or HM Treasury’s financial or other sanctions regime (or a national or resident of one of these countries), or to a person on the Specially Designated Nationals List, Denied Persons List, Unverified List, Entity List, or HM Treasury’s financial or other sanctions regime.Subject to any exemptions or licenses, neither you, nor anyone controlling or acting on behalf of a legal entity you represent, including any subsidiaries, affiliates, officers, directors, employees, agents, contractors, consultants or beneficial owners, are the subject to any Export Laws or are located or headquartered in a comprehensively sanctioned country or jurisdiction, including Iran, Cuba, North Korea, or Russian-occupied regions of Donetsk, Luhansk or Crimea, or in a country or jurisdiction has been designated by the U.S. Government as a “terrorist supporting” country, and you represent that you are not listed on any U.S. Government list of prohibited or restricted parties.You will not use the Services to conduct any criminal, fraudulent or deceptive activity.Should we request, you agree to provide us with information and documentation necessary to substantiate these representations and warranties and your use of the Services.Disclaimer.EXCEPT AS EXPRESSLY SET FORTH IN THESE PORTAL TERMS, PHANTOM AND ITS LICENSORS, SUPPLIERS, PARTNERS, PARENT, SUBSIDIARIES OR AFFILIATED ENTITIES, AND EACH OF THEIR RESPECTIVE OFFICERS, DIRECTORS, MEMBERS, EMPLOYEES, CONSULTANTS, CONTRACT EMPLOYEES, REPRESENTATIVES AND AGENTS, AND EACH OF THEIR RESPECTIVE SUCCESSORS AND ASSIGNS (PHANTOM AND ALL SUCH PARTIES TOGETHER, THE “PHANTOM PARTIES”) HEREBY MAKE NO REPRESENTATIONS AND WARRANTIES CONCERNING THE SERVICES, INCLUDING WITHOUT LIMITATION REGARDING ANY USER CONTENT CONTAINED IN OR ACCESS THROUGH THE SERVICES, AND THE PHANTOM PARTIES WILL NOT BE RESPONSIBLE OR LIABLE FOR THE ACCURACY, COPYRIGHT COMPLIANCE, LEGALITY OR DECENCY OF MATERIAL CONTAINED IN OR ACCESSED THROUGH THE SERVICES OR ANY CLAIMS, ACTIONS, SUITS PROCEDURES, COSTS, EXPENSES, DAMAGES OR LIABILITIES ARISING OUT OF USE OF, OR IN ANY WAY RELATED TO YOUR PARTICIPATION IN, THE SERVICES. THE PHANTOM PARTIES MAKE NO REPRESENTATIONS OR WARRANTIES REGARDING SUGGESTIONS OR RECOMMENDATIONS OF SERVICES OR PRODUCTS OFFERED OR PURCHASED THROUGH OR IN CONNECTION WITH THE SERVICES. THE PHANTOM PARTIES DISCLAIM ALL OTHER WARRANTIES, WHETHER EXPRESS OR IMPLIED, ORAL OR WRITTEN, WITH RESPECT TO THE SERVICES INCLUDING, WITHOUT LIMITATION, ALL IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE AND ALL WARRANTIES ARISING FROM ANY COURSE OF DEALING, COURSE OF PERFORMANCE OR USAGE OF TRADE. THE PORTAL AND THE SERVICES ARE PROVIDED ON AN “AS IS” AND “AS AVAILABLE BASIS. PHANTOM DOES NOT WARRANT THAT (A) THE USE OF THE SERVICES WILL BE UNINTERRUPTED OR ERROR-FREE, OR (B) THE SERVICES WILL MEET CUSTOMER’S OR ANY AUTHORIZED USERS’ REQUIREMENTS OR EXPECTATIONS. SOME STATES DO NOT ALLOW LIMITATIONS ON HOW LONG AN IMPLIED WARRANTY LASTS, SO THE ABOVE LIMITATIONS MAY NOT APPLY TO YOU.Termination.We may terminate or suspend these Portal Terms, or terminate or suspend your access to the Portal or to one or more of the Services, in whole or in part at our sole discretion. While we will attempt to provide notice of such termination or suspension where possible, we reserve the right to do so without prior notice. Upon termination or suspension of these Portal Terms, your right to use the Portal and/or any suspended or terminated Services will cease immediately.You may terminate these Portal Terms by discontinuing use of the Portal and the Services at any time. Please consult the Privacy Policy to understand how we will treat the information you provide to us once you have stopped using the Services.Fees.Unless otherwise stated on an Order Form, access to the Portal and the Services are free of charge.Limitation of Liability and Indemnification.You agree to release, indemnify, defend and hold harmless the Phantom Parties from and against any and all claims, disputes, demands, liabilities, damages (actual and consequential), losses, and costs and expenses, including reasonable legal and accounting fees arising from or in any way connected to:Your access to the Portal or use of the Services (including the acts of third parties using or with access to your Account, whether or not that use or access is authorized by you);Any claims related to your violation of any law, rule or regulation;Your User Content; andYour violation of these Portal Terms.In the event of such a claim, suit, or action (“Claim”), we will attempt to provide notice of the Claim to the contact information we have for your account (provided that failure to deliver such notice shall not eliminate or reduce your indemnification obligations hereunder).TO THE FULLEST EXTENT ALLOWED BY LAW, IN NO EVENT SHALL THE PHANTOM PARTIES BE LIABLE FOR MATTERS ARISING OUT OF OR IN CONNECTION WITH THESE PORTAL TERMS, REGARDLESS OF THE FORM OF ANY CLAIM OR ACTION (WHETHER IN CONTRACT, NEGLIGENCE, STRICT LIABILITY OR OTHERWISE), OR FOR ANY (A) INDIRECT, PUNITIVE, INCIDENTAL, RELIANCE, SPECIAL, EXEMPLARY OR CONSEQUENTIAL DAMAGES OF ANY KIND, INCLUDING DAMAGES FOR LOST PROFITS, BUSINESS INTERRUPTION, LOSS OF DATA, LOSS OF GOODWILL, WORK STOPPAGE, ACCURACY OF RESULTS, OR COMPUTER FAILURE OR MALFUNCTION, (B) ANY SUBSTITUTE GOODS, SERVICES OR TECHNOLOGY, (C) DAMAGES, IN THE AGGREGATE, IN EXCESS OF THE AMOUNTS PAID OR PAYABLE HEREUNDER DURING THE PREVIOUS 6 MONTHS, EVEN IF IT HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES OR (D) ANY MATTER BEYOND OUR REASONABLE CONTROL. FURTHER, THE PHANTOM PARTIES SHALL NOT BE LIABLE FOR OR COMPENSATE YOU (1) IN CONNECTION WITH YOUR INABILITY TO USE THE PORTAL OR ACCESS THE SERVICES OR THE DISCONTINUATION OF THE SERVICES FOR ANY REASON, (2) FOR CLAIMS ARISING FROM USER ERROR, OR (3) FOR UNAUTHORIZED ACCESS TO THE PORTAL OR THE SERVICES OR THE ACTIVITIES OF UNAUTHORIZED THIRD PARTIES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF INCIDENTAL OR CONSEQUENTIAL OR CERTAIN OTHER DAMAGES, SO THE ABOVE LIMITATION AND EXCLUSIONS MAY NOT APPLY TO YOU.Confidentiality.For purposes of these Portal Terms, “Confidential Information” means any and all technical and non-technical information disclosed by the parties, either directly or indirectly, in any form (whether in oral, written, graphic, electronic or machine-readable form), which may include without limitation: (a) patent applications, (b) trade secrets, and (c) other proprietary or confidential information, including, without limitation, ideas, technology, works of authorship, models, inventions, know-how, processes, algorithms, software programs, software source documents, information related to current, future, and proposed products and services, information concerning research, experimental work, development, design details or specifications, engineering, financial information, procurement requirements, purchasing, customer lists, investors, employees, business and contractual relationships, business forecasts, sales and merchandising, and marketing plans and information. Confidential Information does not include any information the receiving party can prove: (i) was in, or comes into the public domain through no fault of the receiving party, (ii) rightfully was in or comes into the receiving party’s possession free of any obligation of confidence. The parties agree that at all times and notwithstanding any termination or expiration of these Portal Terms they will hold in strict confidence and not disclose to any third party any Confidential Information of the other party, except as approved in writing by the disclosing party, and will use the Confidential Information for no purpose except as permitted under these Portal Terms. The receiving party shall protect the Confidential Information from inadvertent or unauthorized disclosure, access, or use in the same manner as it protects its own Confidential Information of a similar nature, but in no event less than reasonable care. The receiving party shall immediately notify the disclosing party upon discovery of any loss or unauthorized disclosure of the Confidential Information. Upon termination or expiration of these Portal Terms, or upon written request of the disclosing party, the receiving party shall promptly return to the disclosing party or destroy its Confidential Information. The receiving party may disclose Confidential Information as required by law or court order provided that the receiving party provides the disclosing party with reasonable prior written notice of the disclosure and reasonable assistance in the disclosing party’s efforts to prevent or limit the disclosure.Assignment.You may not assign, delegate or transfer these Portal Terms or your rights or obligations hereunder, or your Services account, in any way (by operation of law or otherwise) without Phantom’s prior written consent. We may transfer, assign, or delegate these Portal Terms and our rights and obligations without consent.Dispute ResolutionThese Terms shall apply to all disputes, claims, or causes of action arising at any time, including those that accrued prior to the effective date of the Terms.Governing LawThese Terms shall be construed and enforced in accordance with the laws of the state of California applicable to contracts entered into and performed in California by residents thereof; provided that all provisions hereof related to arbitration shall be governed by and construed in accordance with the Federal Arbitration Act (U.S. Code Title 9).Mandatory ArbitrationPLEASE READ THIS “MANDATORY ARBITRATION” PROVISION VERY CAREFULLY. IT LIMITS YOUR RIGHTS IN THE EVENT OF A DISPUTE BETWEEN YOU AND PHANTOM, SUBJECT TO THE TERMS AND OPT-OUT OPTION SET FORTH BELOW.You and Phantom agree that any and all past, present and future disputes, claims, or causes of action arising out of or relating to your use of any of the Site or the Functionality, this Agreement, or any other controversies or disputes between you and Phantom (including, without limitation, disputes regarding the effectiveness, scope, validity or enforceability of this agreement to arbitrate) (collectively, “Dispute(s)”), shall be determined by arbitration, unless (A) your Country of Residence does not allow this arbitration agreement; (B) you opt out as provided below; or (C) your Dispute is subject to an exception to this agreement to arbitrate set forth below. You and Phantom further agree that any arbitration pursuant to this Section shall not proceed as a class, group or representative action.“Country of Residence” for purposes of this agreement to arbitrate means the country in which you hold citizenship or legal permanent residence, as well as any country from which you regularly access and use the Phantom Functionality. If more than one country meets that definition for you, then your country of citizenship or legal permanent residence shall be your Country of Residence, and if you have more than one country of citizenship or legal permanent residence, it shall be the country with which you most closely are associated by permanent or most frequent residence.Phantom wants to address your concerns without the need for a formal legal dispute. Before filing a claim against Phantom, you agree to try to resolve the Dispute informally by contacting Phantom at legal@phantom.com to notify Phantom of the actual or potential Dispute. Similarly, Phantom will undertake reasonable efforts to contact you to notify you of any actual or potential dispute to resolve any claim we may possess informally before taking any formal action. The party that provides the notice of the actual or potential Dispute (the “Notifying Party”) will include in that notice (a “Notice of Dispute”) the name of User, the Notifying Party’s contact information for any communications relating to such Dispute (including for the Notifying Party’s legal counsel if it is represented by counsel in connection with such Dispute), and a detailed factual statement setting forth the basis of such Dispute, including specific dates, times, and circumstances to enable the other party (the “Notified Party”) to understand the basis of and evaluate the concerns raised.If the Notified Party responds within fifteen (15) business days after receiving the Notice of Dispute that it is ready and willing to engage in good faith discussions in an effort to resolve the Dispute informally, then each party shall promptly participate in such discussions in good faith.If, notwithstanding the Notifying Party’s compliance with all of its obligations under the preceding paragraph, a Dispute is not resolved within 60 days after the Notice of Dispute is sent (or if the Notified Party fails to respond to the Notice of Dispute within fifteen (15) business days), the Notifying Party may initiate an arbitration proceeding as described below. If either party purports to initiate arbitration without first providing a Notice of Dispute and otherwise complying with all of its obligations under the preceding paragraph, then, notwithstanding any other provision of this Agreement, the arbitrator(s) will promptly dismiss the claim with prejudice.We both agree to arbitrate (unless you opt out as described below). You and Phantom each agree to resolve any Disputes that are not resolved informally as described above through final and binding arbitration as discussed herein, except as set forth below.If you do not wish to be subject to this agreement to arbitrate, you may opt out of this arbitration provision by sending a written notice to Phantom at legal@phantom.com within thirty (30) days of first accepting this Agreement. You must date the written notice, and include your first and last name, address, and a clear statement that you do not wish to resolve disputes with Phantom through arbitration. If no written notice is submitted by the 30-day deadline, you will be deemed to have knowingly and intentionally waived your right to litigate any Dispute except with regard to the exceptions set forth below. By opting out of the agreement to arbitrate, you will not be precluded from using the Phantom functionalities, but you and Phantom will not be permitted to invoke the mutual agreement to arbitrate to resolve Disputes under the terms otherwise provided herein.You and Phantom agree JAMS will administer the arbitration under its Comprehensive Arbitration Rules and Procedures (“JAMS Rules”). The JAMS Rules are available at https://www.jamsadr.com/adr-rules-procedures/. Arbitration will proceed on an individual basis and will be handled by a sole arbitrator. The single arbitrator will be either a retired judge or an attorney licensed to practice law and will be selected by the parties from the JAMS’s roster of arbitrators. Judgment on the Award may be entered in any court having jurisdiction. You and Phantom agree that if JAMS is unable or unwilling to administer the arbitration, then National Arbitration and Mediation (“NAM”) will administer the arbitration under NAM’s Comprehensive Dispute Resolution Rules and Procedures (“NAM Rules”). The NAM Rules are available at https://www.namadr.com/resources/rules-fees-forms/. You and Phantom agree that if JAMS and NAM are both unable or unwilling to administer the arbitration, and You and Phantom are unable to agree on an alternative provider, then either You or Phantom may apply to a court of competent jurisdiction in California to appoint an alternative arbitration provider to administer the arbitration.The arbitrator shall be authorized to award any remedies, including injunctive relief, that would be available to you hereunder in an individual lawsuit. Notwithstanding any language to the contrary in this paragraph or the preceding paragraph, if a party seeks injunctive relief that would significantly impact other Phantom users as reasonably determined by either party, the parties agree that such arbitration will proceed on an individual basis but will be handled by a panel of three (3) arbitrators. Each party shall select one arbitrator, and the two party-selected arbitrators shall select the third, who shall serve as chair of the arbitral panel. That chairperson shall be a retired judge or an attorney licensed to practice law and with experience arbitrating or mediating disputes. In the event of disagreement as to whether the threshold for a three-arbitrator panel has been met, the sole arbitrator appointed in accordance with this Section shall make that determination. If the arbitrator determines a three- person panel is appropriate, the arbitrator may – if selected by either party or as the chair by the two party-selected arbitrators – participate in the arbitral panel. Except as and to the extent otherwise may be required by law, the arbitration proceeding and any award shall be confidential.You and Phantom further agree that the arbitration hearing will be held in the English language via videoconference, telephonically or via other remote electronic means, unless You and Phantom agree otherwise. In the event that neither you nor Phantom seek more than three hundred and fifty thousand dollars ($350,000) in damages (or an equivalent amount in cryptocurrency, as measured on CoinMarketCap.com on the date that the alleged damages occurred), you and Phantom agree to waive the arbitration hearing and submit the dispute to the arbitrator for an award based on written submissions and other evidence as you and Phantom may agree. If Phantom elects arbitration, Phantom shall pay all of the JAMS filing costs and administrative fees (other than hearing fees). If you elect arbitration, filing costs and administrative fees (other than hearing fees) shall be paid in accordance with the JAMS Rules, or in accordance with countervailing law if contrary to the JAMS Rules. In such circumstances, fees will be determined in accordance with the JAMS Rules. Each party shall bear the expense of its own attorneys’ fees, except as otherwise provided herein or required by law.You and Phantom agree that the arbitration of any Dispute shall proceed on an individual basis, and neither you nor Phantom may bring a claim as a part of a class, group, collective, coordinated, or consolidated arbitration (each, a “Collective Arbitration”). Without limiting the generality of the foregoing, a claim to resolve any Dispute against Phantom will be deemed a Collective Arbitration if (i) two (2) or more similar claims for arbitration are filed concurrently by or on behalf of one or more claimants; and (ii) claimants or their counsel share fees or coordinate across the arbitrations. “Concurrently” for purposes of this provision means that both arbitrations are pending (filed but not yet resolved) at the same time.TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, NEITHER YOU NOR PHANTOM SHALL BE ENTITLED TO CONSOLIDATE, JOIN OR COORDINATE DISPUTES BY OR AGAINST OTHER INDIVIDUALS OR ENTITIES, OR ARBITRATE OR LITIGATE ANY DISPUTE IN A REPRESENTATIVE CAPACITY, INCLUDING AS A REPRESENTATIVE MEMBER OF A CLASS OR IN A PRIVATE ATTORNEY GENERAL CAPACITY. IN CONNECTION WITH ANY DISPUTE (AS DEFINED ABOVE), ANY AND ALL SUCH RIGHTS ARE HEREBY EXPRESSLY AND UNCONDITIONALLY WAIVED. Without limiting the foregoing, any challenge to the validity of this paragraph shall be determined exclusively by the arbitrator.You and Phantom elect the JAMS Mass Arbitration Procedures and Guidelines (“JAMS Mass Rules”), available at https://www.jamsadr.com/mass-arbitration-procedures, for twenty-five (25) or more similar Demands for Arbitration filed against Phantom by individual claimants represented by either the same law firm or law firms acting in coordination. In the event that the JAMS Mass Rules apply, then JAMS shall administer the Demands for Arbitration in batches, with a single, different arbitrator for each batch. Each batch shall be resolved as a single consolidated arbitration with one set of filing and administrative fees due per side per batch, with one schedule and one hearing. If there are twenty-five (25) or more but fewer than one hundred (100) arbitrations, then there will be twenty-five (25) arbitrations per batch. If there are one hundred (100) or more arbitrations, then there will be one hundred (100) arbitrations per batch. JAMS shall designate a Process Administrator to administer the batches, including the composition thereof.Notwithstanding your and Phantom’s agreement to arbitrate Disputes, either you or Phantom retain the right (A) to adjudicate the Dispute pursuant to the California Small Claims Act if the Dispute may be adjudicated pursuant to such act; and (B) to seek provisional relief in aid of arbitration in a court of competent jurisdiction to prevent the actual or threatened infringement, misappropriation or violation of a party’s copyrights, trademarks, trade secrets, patents or other intellectual property rights. Further, this agreement to arbitrate does not deprive you of the protection of the mandatory provisions of the consumer protection laws in your Country of Residence; you shall retain any such rights and this agreement to arbitrate shall be construed accordingly.Except as otherwise required by applicable law or provided in this Agreement, in the event that the agreement to arbitrate is found not to apply to you or your Dispute, you and Phantom agree that any judicial proceeding may only be brought in a court of competent jurisdiction in California, United States. Both you and Phantom consent to venue and personal jurisdiction there; provided that either party may seek provisional relief in aid of arbitration to enforce its intellectual property rights as provided above or bring an action to confirm an arbitral award in any court having jurisdiction.This agreement to arbitrate shall survive the termination or expiration of this Agreement. With the exception of the provisions of this agreement to arbitrate that prohibit Collective Arbitration, if a court decides that any part of this agreement to arbitrate is invalid or unenforceable, then the remaining portions of this agreement to arbitrate shall nevertheless remain valid and in force. In the event that a court finds the prohibition of Collective Arbitration to be invalid or unenforceable, then the entirety of this agreement to arbitrate shall be deemed void (but no provisions of this Agreement unrelated to arbitration shall be void), and any remaining Dispute must be litigated in court pursuant to the preceding paragraph.General Provisions.Each party is an independent contractor. All suggestions, enhancement requests, recommendations or other feedback provided by you relating to the Services or Platform (collectively, “Feedback”), will be the sole and exclusive property of Phantom and Customer shall and hereby does assign any rights in such Feedback to Phantom. Customer grants Phantom a non-exclusive, limited, non-transferable license, and royalty-free license to use its trademarks, service marks, trade names and logos for promotional and marketing purposes in order to identify Customer as a customer of Phantom. These Portal Terms supersede all prior written or oral understandings between the parties regarding the subject matter of these Portal Terms and it may be waived only in writing. These Portal Terms shall be governed by the laws of California, without regard to its conflict of law rules, and any legal action must be brought exclusively within San Francisco, California. If any provision of these Portal Terms is determined to be illegal or unenforceable, that provision will be limited or eliminated to the minimum extent necessary so that these Portal Terms will otherwise remain in full force and effect. These Portal Terms may change from time to time and we will provide a notice on our Platform or notify you by some other means if so. Additionally, since we are always trying to improve our Platform and Services, we may, in our sole discretion, make changes to, suspend or discontinue certain parts of the Platform of Services. We will try to give you notice on our Platform or through some other means when we make material changes to the Platform or Services. Any new or modified terms will be immediately effective and will apply for the duration of the subscriptions(s) that you have selected. Except for changes by us as described here, no other amendment or modification of these Portal Terms will be effective unless in writing and signed by both you and us. You will be responsible for paying, withholding, filing, and reporting all taxes, duties, and other governmental assessments associated with your activity in connection with the Services, provided that Phantom may, in its sole discretion, do any of the foregoing on your behalf or for itself as it sees fit. The failure of either you or us to exercise, in any way, any right herein shall not be deemed a waiver of any further rights hereunder. You hereby acknowledge and agree that you are not an employee, agent, partner, or joint venture of Phantom, and you do not have any authority of any kind to bind Phantom in any respect whatsoever. Except as expressly set forth in the agreement to arbitrate, you and Phantom agree there are no third-party beneficiaries intended under these Portal Terms.Contact and Notices.If you have feedback, suggestions or questions regarding the Platform please visit help.phantom.com. Any required notices under these Portal Terms should be sent to legal@phantom.app.","tokens":10853,"squid":"spider-10","role":"Tooling Spider","at":1791343988323,"hash":"18fd6dc3f7402e1fae6f026cf15a6729a8f88c40"}
{"url":"https://www.metaplex.com/docs/dev-tools/cli/config/wallets","domain":"metaplex.com","title":"Wallets | Metaplex CLI","text":"Manage wallet configurations in your CLI. You can add, list, remove, and set active wallets for different purposes.You can also use an MPL Core Asset's PDA as a wallet. Register one with mplx config wallets add <name> --asset <assetId> and all commands will automatically operate through the PDA.Basic Usage# Create a new wallet\nmplx config wallets new --name <name>\n\n# Add an existing wallet\nmplx config wallets add <name> <keypairPath>\n\n# List all wallets\nmplx config wallets list\n\n# Remove a wallet\nmplx config wallets remove <name>\n\n# Set active wallet\nmplx config wallets set <name>\nCommandsNew WalletCreate a new wallet and add it to your configuration.mplx config wallets new --name <name>\nArgumentsArgumentDescription--nameA unique name for the walletExamplemplx config wallets new --name dev1\nAdd WalletAdd an existing wallet to your configuration.mplx config wallets add <name> <keypairPath>\nArgumentsArgumentDescriptionnameA unique name for the walletkeypairPathPath to the keypair fileExamplemplx config wallets add dev1 ~/.config/solana/devnet/dev1.json\nList WalletsDisplay all configured wallets.mplx config wallets list\nOutput--------------------------------\nWallets\n--------------------------------\nName: dev1\nPublic Key: 7xKXtg2CW87d97TXJSDpbD5jBkheTqA83TZRuJosgAsU\nActive: true\n\nName: dev2\nPublic Key: 9WzDXwBbmkg8ZTbNMqUxvQRAyrZzDsGYdLVL9zYtAWWM\nActive: false\n--------------------------------\nRemove WalletRemove a wallet from your configuration.mplx config wallets remove <name>\nArgumentsArgumentDescriptionnameThe name of the wallet to removeExamplemplx config wallets remove dev2\nSet Active WalletSet the active wallet for your configuration.mplx config wallets set <name>\nArgumentsArgumentDescriptionnameThe name of the wallet to set as activeExamplemplx config wallets set dev1\nConfiguration FileWallets are stored in your configuration file at ~/.mplx/config.json:{\n \"wallets\": {\n \"dev1\": {\n \"publicKey\": \"7xKXtg2CW87d97TXJSDpbD5jBkheTqA83TZRuJosgAsU\",\n \"keypairPath\": \"~/.config/solana/devnet/dev1.json\",\n \"active\": true\n },\n \"dev2\": {\n \"publicKey\": \"9WzDXwBbmkg8ZTbNMqUxvQRAyrZzDsGYdLVL9zYtAWWM\",\n \"keypairPath\": \"~/.config/solana/devnet/dev2.json\",\n \"active\": false\n }\n }\n}\nNotesWallet names are case-sensitiveOnly one wallet can be active at a timeThe active wallet is used for all transactionsYou can add multiple wallets for different purposesRemoving the active wallet will automatically set another wallet as active if availableKeep your keypair files secure and never share themRelated CommandsAsset-Signer Wallets - Use an MPL Core Asset's PDA as your active walletRPCs - Manage RPC endpointsExplorer - Set preferred blockchain explorer","tokens":668,"squid":"dotcat","role":"Tooling Spider","at":1791343990439,"hash":"3f21d102f7d92d070fd9dc459b2be9cfbd612584"}
{"url":"https://docs.phantom.com/recipes/signatures/sign-message","domain":"docs.phantom.com","title":"Sign a message - Phantom developer documentation","text":"Ask the user to sign a message. Useful for authentication, proving ownership, or agreeing to terms.\n React Browser SDK React Nativeimport { useSolana } from \"@phantom/react-sdk\";\n\nfunction SignMessage() {\n const { solana } = useSolana();\n\n const sign = async () => {\n const message = \"Hello, please sign this message to verify your identity.\";\n const { signature, publicKey } = await solana.signMessage(message);\n\n console.log(\"Signature:\", signature);\n console.log(\"Public key:\", publicKey);\n\n return signature;\n };\n\n return <button onClick={sign}>Sign Message</button>;\n}\nimport { BrowserSDK, AddressType } from \"@phantom/browser-sdk\";\n\nconst sdk = new BrowserSDK({\n providers: [\"google\", \"apple\", \"injected\"],\n appId: \"your-app-id\",\n addressTypes: [AddressType.solana],\n});\n\nconst { signature, publicKey } = await sdk.solana.signMessage(\"Sign to verify\");\nconsole.log(\"Signature:\", signature);\nconsole.log(\"Public key:\", publicKey);\nimport { useSolana } from \"@phantom/react-native-sdk\";\nimport { View, Button, Alert, StyleSheet } from \"react-native\";\n\nfunction SignMessage() {\n const { solana } = useSolana();\n\n const sign = async () => {\n try {\n const message = \"Hello, please sign this message to verify your identity.\";\n const { signature, publicKey } = await solana.signMessage(message);\n\n Alert.alert(\"Signed!\", `Public key: ${publicKey}`);\n return signature;\n } catch (error) {\n Alert.alert(\"Error\", error instanceof Error ? error.message : \"Signing failed\");\n throw error;\n }\n };\n\n return (\n <View style={styles.container}>\n <Button title=\"Sign Message\" onPress={sign} />\n </View>\n );\n}\n\nconst styles = StyleSheet.create({\n container: {\n padding: 20,\n gap: 10,\n },\n});\nWas this page helpful?","tokens":426,"squid":"spider-10","role":"Tooling Spider","at":1791343999854,"hash":"1dd43e4bb55fc737d5e506c8e70a992b5a13fdb4"}
{"url":"https://docs.phantom.com/recipes/transactions/sponsored-transaction","domain":"docs.phantom.com","title":"Sponsored transactions - Phantom developer documentation","text":"A sponsored transaction is one where your server pays the network fee instead of the user. This removes the SOL requirement for new users and enables gasless UX patterns like free mints, claim flows, and onboarding actions.\n​How it works\nThis recipe covers the embedded wallet flow (Google/Apple sign-in via Phantom Connect). For injected/extension wallets, direct pre-signing works — you can build and sign the transaction server-side before passing it to the extension.\nFor embedded wallets:\n\nYour client builds a transaction with the sponsor’s public key as payerKey\nThe client calls signAndSendTransaction with a presignTransaction callback\nPhantom validates the transaction, then invokes the callback with the transaction bytes (base64url)\nThe callback sends those bytes to your server, which signs as fee payer and returns the partially-signed transaction (base64url)\nPhantom adds the user’s signature and submits — no SOL required from the user\n\nPhantom embedded wallets do not accept pre-signed transactions passed directly. The presignTransaction callback is the only supported way to add a second signer (such as a fee payer) for embedded wallets. This restriction does not apply to injected providers (the Phantom browser extension), which support direct pre-signing.\n​Server: sign as fee payer\nYour API endpoint receives a base64url-encoded transaction from the presignTransaction callback, signs it with the sponsor keypair, and returns the partially-signed bytes.\n// app/api/sponsor/route.ts (Next.js App Router)\nimport { NextRequest, NextResponse } from \"next/server\";\nimport { Keypair, VersionedTransaction } from \"@solana/web3.js\";\nimport bs58 from \"bs58\";\n\nexport async function POST(req: NextRequest) {\n try {\n const { transaction } = await req.json();\n if (!transaction) {\n return NextResponse.json({ error: \"transaction is required\" }, { status: 400 });\n }\n\n const sponsor = Keypair.fromSecretKey(\n bs58.decode(process.env.SPONSOR_PRIVATE_KEY!)\n );\n\n // Decode the base64url transaction sent by Phantom's presignTransaction callback\n const txBytes = Buffer.from(transaction, \"base64url\");\n const tx = VersionedTransaction.deserialize(txBytes);\n\n // Sign as fee payer — Phantom will add the user's signature next\n tx.sign([sponsor]);\n\n // signatures[0] is the fee payer's signature = the Solana transaction ID.\n // Return it here because the client only gets Phantom's signature from\n // signAndSendTransaction, which is the second signer — not the tx ID.\n const txId = bs58.encode(tx.signatures[0]);\n\n return NextResponse.json({\n transaction: Buffer.from(tx.serialize()).toString(\"base64url\"),\n txId,\n });\n } catch (error) {\n return NextResponse.json(\n { error: error instanceof Error ? error.message : \"Unknown error\" },\n { status: 500 }\n );\n }\n}\n\nKeep SPONSOR_PRIVATE_KEY server-side only. Never expose it to the client or include it in NEXT_PUBLIC_* variables.\n​Client: build and send the sponsored transaction\n React Browser SDK React Nativeimport { useSolana } from \"@phantom/react-sdk\";\nimport {\n Connection,\n PublicKey,\n TransactionInstruction,\n TransactionMessage,\n VersionedTransaction,\n} from \"@solana/web3.js\";\n\nconst MEMO_PROGRAM_ID = new PublicKey(\n \"MemoSq4gqABAXKb96qnH8TysNcWxMyWCqXgDLGmfcHr\"\n);\n// Expose only the public key to the client — never the private key\nconst SPONSOR_PUBLIC_KEY = new PublicKey(\n process.env.NEXT_PUBLIC_SPONSOR_PUBLIC_KEY!\n);\n\nfunction SponsoredAction() {\n const { solana } = useSolana();\n\n const handleSponsoredTransaction = async () => {\n const publicKey = solana.publicKey;\n if (!publicKey) return;\n\n const connection = new Connection(\"https://api.mainnet-beta.solana.com\");\n const { blockhash } = await connection.getLatestBlockhash();\n const userPubkey = new PublicKey(publicKey);\n\n // Any instruction that requires the user's signature\n // Here: a Memo instruction — user signs, sponsor pays fees\n const instruction = new TransactionInstruction({\n keys: [{ pubkey: userPubkey, isSigner: true, isWritable: false }],\n programId: MEMO_PROGRAM_ID,\n data: new TextEncoder().encode(\"Sponsored by dApp\"),\n });\n\n // Build the transaction with the sponsor as fee payer\n const transaction = new VersionedTransaction(\n new TransactionMessage({\n payerKey: SPONSOR_PUBLIC_KEY,\n recentBlockhash: blockhash,\n instructions: [instruction],\n }).compileToV0Message()\n );\n\n // presignTransaction fires after Phantom validates the transaction.\n // The server signs as fee payer and returns the partially-signed tx.\n // Phantom then adds the user's signature and submits.\n //\n // We capture txId from the API because the Solana transaction ID is always\n // the fee payer's (sponsor's) signature — not Phantom's signature returned\n // by signAndSendTransaction.\n let txId: string | undefined;\n\n await solana.signAndSendTransaction(transaction, {\n presignTransaction: async (tx) => {\n const res = await fetch(\"/api/sponsor\", {\n method: \"POST\",\n headers: { \"Content-Type\": \"application/json\" },\n body: JSON.stringify({ transaction: tx }),\n });\n if (!res.ok) throw new Error(\"Failed to presign transaction\");\n const { transaction: signed, txId: sponsorTxId } = await res.json();\n txId = sponsorTxId;\n return signed;\n },\n });\n\n console.log(\"Transaction confirmed:\", txId);\n };\n\n return (\n <button onClick={handleSponsoredTransaction}>\n Claim (free for you)\n </button>\n );\n}\nimport { BrowserSDK, AddressType } from \"@phantom/browser-sdk\";\nimport {\n Connection,\n PublicKey,\n TransactionInstruction,\n TransactionMessage,\n VersionedTransaction,\n} from \"@solana/web3.js\";\n\nconst MEMO_PROGRAM_ID = new PublicKey(\n \"MemoSq4gqABAXKb96qnH8TysNcWxMyWCqXgDLGmfcHr\"\n);\nconst SPONSOR_PUBLIC_KEY = new PublicKey(\"YOUR_SPONSOR_PUBLIC_KEY\");\n\nconst sdk = new BrowserSDK({\n providers: [\"google\", \"apple\", \"injected\"],\n appId: \"your-app-id\",\n addressTypes: [AddressType.solana],\n});\n\n// Connect with your preferred auth provider before accessing sdk.solana\nawait sdk.connect({ provider: \"google\" }); // or \"apple\" / \"injected\"\n\nasync function handleSponsoredTransaction() {\n const publicKey = sdk.solana.publicKey;\n if (!publicKey) return;\n\n const connection = new Connection(\"https://api.mainnet-beta.solana.com\");\n const { blockhash } = await connection.getLatestBlockhash();\n const userPubkey = new PublicKey(publicKey);\n\n const instruction = new TransactionInstruction({\n keys: [{ pubkey: userPubkey, isSigner: true, isWritable: false }],\n programId: MEMO_PROGRAM_ID,\n data: new TextEncoder().encode(\"Sponsored by dApp\"),\n });\n\n const transaction = new VersionedTransaction(\n new TransactionMessage({\n payerKey: SPONSOR_PUBLIC_KEY,\n recentBlockhash: blockhash,\n instructions: [instruction],\n }).compileToV0Message()\n );\n\n let txId: string | undefined;\n\n await sdk.solana.signAndSendTransaction(transaction, {\n presignTransaction: async (tx) => {\n const res = await fetch(\"/api/sponsor\", {\n method: \"POST\",\n headers: { \"Content-Type\": \"application/json\" },\n body: JSON.stringify({ transaction: tx }),\n });\n if (!res.ok) throw new Error(\"Failed to presign transaction\");\n const { transaction: signed, txId: sponsorTxId } = await res.json();\n txId = sponsorTxId;\n return signed;\n },\n });\n\n console.log(\"Transaction confirmed:\", txId);\n}\nimport { useSolana } from \"@phantom/react-native-sdk\";\nimport {\n Connection,\n PublicKey,\n TransactionInstruction,\n TransactionMessage,\n VersionedTransaction,\n} from \"@solana/web3.js\";\nimport { Button, Alert } from \"react-native\";\n\nconst MEMO_PROGRAM_ID = new PublicKey(\n \"MemoSq4gqABAXKb96qnH8TysNcWxMyWCqXgDLGmfcHr\"\n);\nconst SPONSOR_PUBLIC_KEY = new PublicKey(\"YOUR_SPONSOR_PUBLIC_KEY\");\n\nfunction SponsoredAction() {\n const { solana } = useSolana();\n\n const handleSponsoredTransaction = async () => {\n try {\n const publicKey = solana.publicKey;\n if (!publicKey) return;\n\n const connection = new Connection(\"https://api.mainnet-beta.solana.com\");\n const { blockhash } = await connection.getLatestBlockhash();\n const userPubkey = new PublicKey(publicKey);\n\n const instruction = new TransactionInstruction({\n keys: [{ pubkey: userPubkey, isSigner: true, isWritable: false }],\n programId: MEMO_PROGRAM_ID,\n data: new TextEncoder().encode(\"Sponsored by dApp\"),\n });\n\n const transaction = new VersionedTransaction(\n new TransactionMessage({\n payerKey: SPONSOR_PUBLIC_KEY,\n recentBlockhash: blockhash,\n instructions: [instruction],\n }).compileToV0Message()\n );\n\n let txId: string | undefined;\n\n await solana.signAndSendTransaction(transaction, {\n presignTransaction: async (tx) => {\n const res = await fetch(\"https://your-api.com/api/sponsor\", {\n method: \"POST\",\n headers: { \"Content-Type\": \"application/json\" },\n body: JSON.stringify({ transaction: tx }),\n });\n if (!res.ok) throw new Error(\"Failed to presign transaction\");\n const { transaction: signed, txId: sponsorTxId } = await res.json();\n txId = sponsorTxId;\n return signed;\n },\n });\n\n Alert.alert(\"Success\", `Transaction confirmed: ${txId}`);\n } catch (error) {\n Alert.alert(\"Error\", error instanceof Error ? error.message : \"Failed\");\n }\n };\n\n return <Button title=\"Claim (free for you)\" onPress={handleSponsoredTransaction} />;\n}\n\n​Environment setup\n​1. Phantom Portal setup\nPhantom Portal is not accepting new applications at this time. New sign-ups for Phantom Connect SDK access and new app submissions to the Phantom app directory are paused. Existing Portal apps and App IDs are not affected.\nBefore you can use the Phantom Connect SDK, open your existing app at Phantom Portal:\n\nCopy your App ID\nAllowlist your domain (e.g. localhost:3000 for development, your production domain for prod)\nFor mobile integrations, configure your redirect URL\n\n# .env.local\nNEXT_PUBLIC_PHANTOM_APP_ID=your_app_id_from_phantom_portal\n\n​2. Sponsor keypair\n# .env.local — SPONSOR_PRIVATE_KEY is server-side only, never prefix with NEXT_PUBLIC_\nSPONSOR_PRIVATE_KEY=your_base58_encoded_private_key\nNEXT_PUBLIC_SPONSOR_PUBLIC_KEY=your_sponsor_public_key\nSOLANA_RPC_URL=https://api.mainnet-beta.solana.com\n\nGenerate a sponsor keypair with the Solana CLI:\nsolana-keygen new --outfile sponsor-keypair.json\n# Fund it on devnet for testing\nsolana airdrop 1 $(solana-keygen pubkey sponsor-keypair.json) --url devnet\n\nOr with web3.js:\nimport { Keypair } from \"@solana/web3.js\";\nimport bs58 from \"bs58\";\n\nconst keypair = Keypair.generate();\nconsole.log(\"Public key:\", keypair.publicKey.toString());\nconsole.log(\"Private key:\", bs58.encode(keypair.secretKey));\n\n​When to use this pattern\n\nFree mints — users claim NFTs or tokens without needing SOL\nOnboarding actions — first transaction is free to reduce friction\nProtocol interactions — dApp covers fees for protocol-specific instructions\nGasless vouchers — sponsor a fixed number of transactions per user\n\n​Security considerations\n\nRate-limit sponsorship per wallet address to prevent abuse\nKeep the scope narrow — only sign transactions your dApp explicitly builds, not arbitrary user-provided transactions\nMonitor your sponsor wallet balance and set up alerts when it runs low\nFor injected/extension wallets, the presignTransaction callback is not invoked — direct pre-signing works, but the embedded wallet restriction above still applies to embedded provider users\nWas this page helpful?","tokens":2784,"squid":"spider-10","role":"Tooling Spider","at":1791344009836,"hash":"7174a42ed3e42b39ef1c82a53ab5d84f0c1acedd"}
{"url":"https://www.metaplex.com/docs/dev-tools/cli/config/explorer","domain":"metaplex.com","title":"Explorer Configuration | Metaplex CLI","text":"The mplx config explorer command allows you to set your preferred blockchain explorer for viewing transactions and accounts.Basic UsageSet Explorermplx config explorer set\nCommandsSet ExplorerSets your preferred blockchain explorer from a list of available options.Examplesmplx config explorer set\nNotesOpens an interactive prompt to select from available explorersUpdates the active explorer in your configurationThe selected explorer will be used for viewing transactions and accountsAvailable explorers include:Solana Explorer (https://explorer.solana.com)Solscan (https://solscan.io)Solana FM (https://solana.fm)Configuration FileThe explorer configuration is stored in your config file (default: ~/.mplx/config.json). The structure looks like this:{\n \"explorer\": \"https://explorer.solana.com\"\n}\nNotesThe explorer setting is used when displaying links to transactions and accountsThe configuration file is automatically created if it doesn't existYou can change your preferred explorer at any timeThe selected explorer will be used for all explorer links in command outputsEach explorer provides different features and interfaces for viewing blockchain data","tokens":290,"squid":"dotcat","role":"Tooling Spider","at":1791344010422,"hash":"1660186ee07c8ba034adb8dcb270b9bd9389786c"}
{"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":"spider-08","role":"Oracle Spider","at":1791344013022,"hash":"235fe0aa50bab8cc1268211f39bc35550824695f"}
{"url":"https://www.metaplex.com/docs/cli/cm","domain":"metaplex.com","title":"MPLX CLI - Candy Machine Commands","text":"The MPLX CLI provides comprehensive support for creating and managing MPL Core Candy Machines on Solana. These commands allow you to create NFT collections with configurable minting rules, upload assets, and manage the entire candy machine lifecycle through an intuitive command-line interface.Quick StartGet started quickly with the interactive wizard:mplx cm create --wizard\nThis single command handles everything to create a candy machine: asset validation, upload, candy machine creation including guard configuration, item insertion with progress tracking.Command OverviewCommandPurposeKey FeaturescreateCreate a new candy machineInteractive wizard, template generation, manual configuploadUpload assets to storageIntelligent caching, progress tracking, validationinsertInsert items into candy machineSmart loading detection, batch processingvalidateValidate asset cacheComprehensive validation, error reportingfetchFetch candy machine infoDisplay configuration, guard settings, statuswithdrawWithdraw and deleteClean withdrawal, balance recoveryKey FeaturesInteractive WizardGuided Setup: Step-by-step candy machine creationAsset Validation: Comprehensive file and metadata validationProgress Tracking: Real-time indicators for all operationsError Recovery: Detailed error messages with actionable guidanceIntelligent Asset ManagementSmart Caching: Reuses existing uploads when possibleBatch Processing: Efficient asset upload and insertionFile Validation: Ensures proper naming and metadata formatCollection Support: Automatic collection creationFlexible ConfigurationGuard Support: All Core Candy Machine guards supportedGuard Groups: Create different minting phases with distinct rulesTemplate Generation: Quick directory structure setupManual Configuration: Advanced users can create custom configsDirectory StructureAll candy machine commands work from a candy machine asset directory with this structure:my-candy-machine/\n├── assets/\n│ ├── 0.png # Image files (PNG, JPG)\n│ ├── 0.json # Metadata files\n│ ├── 1.png\n│ ├── 1.json\n│ ├── ...\n│ ├── collection.png # Collection image\n│ └── collection.json # Collection metadata\n├── asset-cache.json # Asset upload cache (generated)\n└── cm-config.json # Candy machine configuration (generated when using the wizard)\nWorkflow OptionsOption 1: Wizard Mode (Recommended)Perfect for beginners and most use cases:mplx cm create --wizard\nWhat it does:Validates assets and configurationUploads all assets with progress trackingCreates the candy machine on-chainInserts all items with transaction progressProvides comprehensive completion summaryOption 2: Manual Mode (Advanced)For advanced users who want full control:# 1. Set up directory and config manually\nmkdir my-candy-machine && cd my-candy-machine\n# (create assets/ directory and add your assets)\n\n# 2. Upload assets\nmplx cm upload\n\n# 3. Create candy machine\nmplx cm create\n\n# 4. Insert items\nmplx cm insert\n\n# 5. Validate (optional)\nmplx cm validate\nGuard ConfigurationThe CLI supports all Core Candy Machine guards and guard groups:Global Guards{\n \"guardConfig\": {\n \"solPayment\": {\n \"lamports\": 1000000000,\n \"destination\": \"111111111111111111111111111111111\"\n },\n \"mintLimit\": {\n \"id\": 1,\n \"limit\": 1\n }\n }\n}\nGuard Groups (Minting Phases){\n \"groups\": [\n {\n \"label\": \"wl\",\n \"guards\": {\n \"allowList\": {\n \"merkleRoot\": \"MerkleRootHash...\"\n },\n \"solPayment\": {\n \"lamports\": 500000000,\n \"destination\": \"111111111111111111111111111111111\"\n }\n }\n },\n {\n \"label\": \"public\",\n \"guards\": {\n \"solPayment\": {\n \"lamports\": 1000000000,\n \"destination\": \"111111111111111111111111111111111\"\n }\n }\n }\n ]\n}\nAvailable GuardsThe CLI supports all Core Candy Machine guards:Payment Guards: solPayment, solFixedFee, tokenPayment, token2022Payment, nftPayment, assetPayment, assetPaymentMultiAccess Control: addressGate, allowList, nftGate, tokenGate, assetGate, programGate, thirdPartySignerTime-Based: startDate, endDateLimits: mintLimit, allocation, nftMintLimit, assetMintLimit, redeemedAmountBurn Guards: nftBurn, tokenBurn, assetBurn, assetBurnMultiSpecial: botTax, edition, vanityMintFreeze Guards: freezeSolPayment, freezeTokenPaymentFor detailed guard documentation, see the Core Candy Machine Guards reference.Best Practices🎯 Directory OrganizationKeep each candy machine in its own directoryUse descriptive directory namesMaintain consistent asset naming (0.png, 1.png, etc.)Back up your candy machine directories📁 Asset PreparationUse consistent naming (0.png, 1.png, etc.)Ensure metadata JSON files match image filesValidate image formats (PNG, JPG supported)Keep file sizes reasonable (< 10MB recommended)Include collection.json with a valid \"name\" field⚙️ ConfigurationTest on devnet before mainnetUse the wizard for guided configurationBack up configuration filesDocument guard settingsConsider adding at least one guard or guard group🚀 DeploymentVerify candy machine creationTest minting functionalityMonitor transaction statusKeep explorer links for verificationRelated DocumentationCore Candy Machine Overview - Understanding MPL Core Candy MachinesCore Candy Machine Guards - Complete guard referenceCLI Installation - Setting up the MPLX CLICLI Configuration - Wallet and RPC setupNext StepsInstall the CLI if you haven't alreadyCreate your first candy machine using the wizardExplore guard configuration for advanced minting rulesLearn about guard groups for phased launches","tokens":1345,"squid":"dotcat","role":"Tooling Spider","at":1791344024224,"hash":"eac18206dab78122c81508c7e1adb4b8e808c76f"}
{"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":"spider-08","role":"Oracle Spider","at":1791344033504,"hash":"248974368117ff3f16af56e9b79132e3f2aece0f"}
{"url":"https://docs.phantom.com/recipes/transactions/check-transaction-status","domain":"docs.phantom.com","title":"Check transaction status - Phantom developer documentation","text":"Check the status of a transaction after sending it to the network. Useful for showing users when their transaction is confirmed.\n React Browser SDK React Nativeimport { Connection } from \"@solana/web3.js\";\nimport { useEffect, useState } from \"react\";\n\ntype TransactionStatus = \"pending\" | \"confirmed\" | \"finalized\" | \"failed\";\n\nfunction TransactionStatus({ signature }: { signature: string }) {\n const [status, setStatus] = useState<TransactionStatus>(\"pending\");\n const [transaction, setTransaction] = useState<any>(null);\n const [error, setError] = useState<string | null>(null);\n\n useEffect(() => {\n const connection = new Connection(\"https://api.mainnet-beta.solana.com\");\n\n const checkStatus = async () => {\n try {\n // Get transaction status\n const txStatus = await connection.getSignatureStatus(signature);\n\n if (txStatus.value?.err) {\n setStatus(\"failed\");\n setError(JSON.stringify(txStatus.value.err));\n return;\n }\n\n if (txStatus.value?.confirmationStatus === \"finalized\") {\n setStatus(\"finalized\");\n } else if (txStatus.value?.confirmationStatus === \"confirmed\") {\n setStatus(\"confirmed\");\n } else {\n setStatus(\"pending\");\n }\n\n // Get full transaction details\n const txDetails = await connection.getTransaction(signature, {\n maxSupportedTransactionVersion: 0,\n });\n\n setTransaction(txDetails);\n } catch (err) {\n setError(err instanceof Error ? err.message : \"Unknown error\");\n }\n };\n\n // Check immediately\n checkStatus();\n\n // Poll every 2 seconds until finalized\n const interval = setInterval(() => {\n if (status !== \"finalized\" && status !== \"failed\") {\n checkStatus();\n } else {\n clearInterval(interval);\n }\n }, 2000);\n\n return () => clearInterval(interval);\n }, [signature, status]);\n\n return (\n <div>\n <h3>Transaction Status</h3>\n <p>\n <strong>Signature:</strong> {signature}\n </p>\n <p>\n <strong>Status:</strong> {status}\n </p>\n {error && <p style={{ color: \"red\" }}>Error: {error}</p>}\n {transaction && (\n <div>\n <p>\n <strong>Slot:</strong> {transaction.slot}\n </p>\n <p>\n <strong>Block Time:</strong>{\" \"}\n {transaction.blockTime\n ? new Date(transaction.blockTime * 1000).toLocaleString()\n : \"N/A\"}\n </p>\n <a\n href={`https://explorer.solana.com/tx/${signature}`}\n target=\"_blank\"\n rel=\"noopener noreferrer\"\n >\n View on Explorer\n </a>\n </div>\n )}\n </div>\n );\n}\n\n// Usage\nfunction SendTransaction() {\n const [txSignature, setTxSignature] = useState<string | null>(null);\n\n const sendTx = async () => {\n // ... send transaction logic\n // const { hash } = await solana.signAndSendTransaction(transaction);\n // setTxSignature(hash);\n };\n\n return (\n <div>\n <button onClick={sendTx}>Send Transaction</button>\n {txSignature && <TransactionStatus signature={txSignature} />}\n </div>\n );\n}\nimport { Connection } from \"@solana/web3.js\";\n\ntype TransactionStatus = \"pending\" | \"confirmed\" | \"finalized\" | \"failed\";\n\nasync function checkTransactionStatus(\n signature: string,\n connection: Connection\n): Promise<{ status: TransactionStatus; transaction: any; error?: string }> {\n try {\n const txStatus = await connection.getSignatureStatus(signature);\n\n if (txStatus.value?.err) {\n return {\n status: \"failed\",\n transaction: null,\n error: JSON.stringify(txStatus.value.err),\n };\n }\n\n let status: TransactionStatus = \"pending\";\n if (txStatus.value?.confirmationStatus === \"finalized\") {\n status = \"finalized\";\n } else if (txStatus.value?.confirmationStatus === \"confirmed\") {\n status = \"confirmed\";\n }\n\n const txDetails = await connection.getTransaction(signature, {\n maxSupportedTransactionVersion: 0,\n });\n\n return { status, transaction: txDetails };\n } catch (error) {\n return {\n status: \"failed\",\n transaction: null,\n error: error instanceof Error ? error.message : \"Unknown error\",\n };\n }\n}\n\n// Poll until finalized\nasync function waitForConfirmation(\n signature: string,\n connection: Connection,\n maxAttempts: number = 30\n): Promise<TransactionStatus> {\n for (let i = 0; i < maxAttempts; i++) {\n const { status } = await checkTransactionStatus(signature, connection);\n\n if (status === \"finalized\" || status === \"failed\") {\n return status;\n }\n\n // Wait 2 seconds before next check\n await new Promise((resolve) => setTimeout(resolve, 2000));\n }\n\n return \"pending\"; // Timeout\n}\n\n// Usage\nconst connection = new Connection(\"https://api.mainnet-beta.solana.com\");\nconst signature = \"your-transaction-signature\";\n\nconst finalStatus = await waitForConfirmation(signature, connection);\nconsole.log(`Transaction ${finalStatus}`);\nimport { Connection } from \"@solana/web3.js\";\nimport { View, Text, StyleSheet, Linking, ActivityIndicator } from \"react-native\";\nimport { useEffect, useState } from \"react\";\n\ntype TransactionStatus = \"pending\" | \"confirmed\" | \"finalized\" | \"failed\";\n\nfunction TransactionStatus({ signature }: { signature: string }) {\n const [status, setStatus] = useState<TransactionStatus>(\"pending\");\n const [transaction, setTransaction] = useState<any>(null);\n const [error, setError] = useState<string | null>(null);\n\n useEffect(() => {\n const connection = new Connection(\"https://api.mainnet-beta.solana.com\");\n\n const checkStatus = async () => {\n try {\n const txStatus = await connection.getSignatureStatus(signature);\n\n if (txStatus.value?.err) {\n setStatus(\"failed\");\n setError(JSON.stringify(txStatus.value.err));\n return;\n }\n\n if (txStatus.value?.confirmationStatus === \"finalized\") {\n setStatus(\"finalized\");\n } else if (txStatus.value?.confirmationStatus === \"confirmed\") {\n setStatus(\"confirmed\");\n } else {\n setStatus(\"pending\");\n }\n\n const txDetails = await connection.getTransaction(signature, {\n maxSupportedTransactionVersion: 0,\n });\n\n setTransaction(txDetails);\n } catch (err) {\n setError(err instanceof Error ? err.message : \"Unknown error\");\n }\n };\n\n checkStatus();\n\n const interval = setInterval(() => {\n if (status !== \"finalized\" && status !== \"failed\") {\n checkStatus();\n } else {\n clearInterval(interval);\n }\n }, 2000);\n\n return () => clearInterval(interval);\n }, [signature, status]);\n\n return (\n <View style={styles.container}>\n <Text style={styles.title}>Transaction Status</Text>\n <Text style={styles.signature}>{signature}</Text>\n <Text style={styles.status}>Status: {status}</Text>\n {error && <Text style={styles.error}>Error: {error}</Text>}\n {status === \"pending\" && <ActivityIndicator size=\"small\" />}\n {transaction && (\n <View style={styles.details}>\n <Text>Slot: {transaction.slot}</Text>\n <Text>\n Block Time:{\" \"}\n {transaction.blockTime\n ? new Date(transaction.blockTime * 1000).toLocaleString()\n : \"N/A\"}\n </Text>\n <Text\n style={styles.link}\n onPress={() =>\n Linking.openURL(`https://explorer.solana.com/tx/${signature}`)\n }\n >\n View on Explorer\n </Text>\n </View>\n )}\n </View>\n );\n}\n\nconst styles = StyleSheet.create({\n container: {\n padding: 20,\n },\n title: {\n fontSize: 20,\n fontWeight: \"bold\",\n marginBottom: 10,\n },\n signature: {\n fontSize: 12,\n color: \"#666\",\n marginBottom: 10,\n },\n status: {\n fontSize: 16,\n fontWeight: \"600\",\n marginBottom: 10,\n },\n error: {\n color: \"red\",\n marginTop: 10,\n },\n details: {\n marginTop: 20,\n padding: 15,\n backgroundColor: \"#f5f5f5\",\n borderRadius: 8,\n },\n link: {\n color: \"#0ea5e9\",\n marginTop: 10,\n textDecorationLine: \"underline\",\n },\n});\n\n​Confirmation statuses\nSolana transactions have three confirmation statuses:\n\nPending: Transaction has been submitted but not yet confirmed\nConfirmed: Transaction has been confirmed by the cluster (not yet finalized)\nFinalized: Transaction has been finalized and cannot be rolled back\n\nTransactions are typically confirmed within 1-2 seconds and finalized within ~30 seconds on mainnet. Use “confirmed” status for most UI updates, and “finalized” for critical operations.Was this page helpful?","tokens":1907,"squid":"spider-10","role":"Tooling Spider","at":1791344036719,"hash":"bb49335170b7b0c4f8e0e389620d9acebef0177b"}
{"url":"https://www.metaplex.com/docs/dev-tools/cli/cm/insert","domain":"metaplex.com","title":"MPLX CLI - Insert Items Command","text":"The mplx cm insert command inserts uploaded assets from your cache file into the on-chain candy machine, making them available for minting. It features smart loading detection, efficient batch processing, and detailed transaction tracking.Usage# Insert items from current candy machine directory\nmplx cm insert\n\n# Insert items from specific candy machine directory\nmplx cm insert <directory>\nRequirementsBefore running the insert command, ensure you have:Asset Cache: Valid asset-cache.json with uploaded URIsCandy Machine: Created candy machine with ID in cacheWallet Balance: Sufficient SOL for transaction feesNetwork Access: Stable connection to Solana networkPrerequisites# 1. Candy machine must be created\nmplx cm create\n\n# 2. Upload the assets\nmplx cm upload\n\n# 3. Then insert items\nmplx cm insert\nRelated Commandsmplx cm upload - Upload assets (required before insert)mplx cm create - Create candy machine (required before insert)mplx cm validate - Validate cache and uploadsmplx cm fetch - Verify insertion statusNext StepsVerify insertion to confirm all items are loadedTest minting to ensure candy machine worksMonitor performance to check for issuesPlan your launch with appropriate guards","tokens":300,"squid":"dotcat","role":"Tooling Spider","at":1791344037118,"hash":"f18333a30b1c883a2e89751df426c8c236f1d577"}
{"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":"spider-08","role":"Oracle Spider","at":1791344043205,"hash":"db4649c905a5d911c2527478785c44cd7fa9197e"}
{"url":"https://developer.arbitrum.io/how-arbitrum-works/timeboost/how-to-use-timeboost","domain":"developer.arbitrum.io","title":"How to use Timeboost","text":"How to use TimeboostLearn how to use timeboostRequest an updateTimeboost is a transaction ordering policy for Arbitrum chains. With Timeboost, anyone can bid for the right to access an express lane on the Sequencer for faster transaction inclusion.\nIn this how-to, you'll learn how to bid for the right to use the express lane and submit transactions through the express lane. To learn more about Timeboost and the key terms used on this page, refer to the gentle introduction.\nThis how-to assumes that you're familiar with How Timeboost works\nNote about transferring express lane rightsA round's express lane controller, at their choice, can send transactions signed by others on a per-transaction basis, as explained later in this guide.\nHow to submit bids for the right to be the express lane controller\nTo use the express lane for faster transaction inclusion, you must win an auction for the right to be the express lane controller for a specific round.\nNoteRemember that, by default, each round lasts 60 seconds, and the auction for a specific round closes 15 seconds before the start of the round. These default values can be configured on a chain using the roundDurationSeconds and auctionClosingSeconds parameters.\nAn auction contract facilitates auctions, and bids get submitted to an autonomous auctioneer that interacts with the contract. Let's examine the process of submitting bids and determining the winner of an auction.\nPrerequisites: Gather the required information\nBefore we begin, make sure you have:\n\nAddress of the auction contract\nEndpoint of the autonomous auctioneer\n\nThe following table shows this information for the Arbitrum DAO-owned chains:\nTimeboost reference URLs and addresses\nNetworkAuction contractAutonomous auctioneer endpointArbitrum Sepolia0x991DbEDf388CB5925318f06362D4fCa7b040527Dhttps://arbsepolia-auctioneer.arbitrum.io/Arbitrum One0x5fcb496a31b7AE91e7c9078Ec662bd7A55cd3079https://arb1-auctioneer.arbitrum.io/Arbitrum Nova0xa5aBADAF73DFcf5261C7f55420418736707Dc0dbhttps://nova-auctioneer.arbitrum.io/\nStep 1: Deposit funds into the auction contract\nBefore bidding on an auction, we need to deposit funds in the auction contract. These funds are in the form of the ERC-20 tokens used to bid, also known as the bidding token. We will be able to bid for an amount that is equal to or less than the tokens we have deposited in the auction contract.\nTo see the amount of tokens we have deposited in the auction contract, we can call the function balanceOf in the Auction contract:\n// Code example uses viem\n\nconst depositedBalance = await publicClient.readContract({\n address: auctionContractAddress,\n abi: auctionContractAbi,\n functionName: 'balanceOf',\n args: [userAddress],\n});\nconsole.log(`Current balance of ${userAddress} in auction contract: ${depositedBalance}`);\nIf we want to deposit more funds to the Auction contract, we first need to know what the bidding token is. To obtain the address of the bidding token, we can call the function biddingToken in the Auction contract:\n// Code example uses viem\n\nconst biddingTokenContractAddress = await publicClient.readContract({\n address: auctionContractAddress,\n abi: auctionContractAbi,\n functionName: 'biddingToken',\n});\nconsole.log(`biddingToken: ${biddingTokenContractAddress}`);\nBidding token in Arbitrum chainsOn Arbitrum One and Arbitrum Nova, the default bidding token is WETH.\nOnce we know what the bidding token is, we can deposit funds to the auction contract by calling the function deposit of the contract after having it approved as spender of the amount we want to deposit:\n// Code example uses viem\n\n// Approving spending tokens\nconst approveHash = await walletClient.writeContract({\n account,\n address: biddingTokenContractAddress,\n abi: parseAbi(['function approve(address,uint256)']),\n functionName: 'approve',\n args: [auctionContract, amountToDeposit],\n});\nconsole.log(`Approve transaction sent: ${approveHash}`);\n\n// Making the deposit\nconst depositHash = await walletClient.writeContract({\n account,\n address: auctionContractAddress,\n abi: auctionContractAbi,\n functionName: 'deposit',\n args: [amountToDeposit],\n});\nconsole.log(`Deposit transaction sent: ${depositHash}`);\nStep 2: Query the reserve pricer API\nAny auction participant submitting a valid bid must first know the minimum acceptable bid amount for the round being bid on. The Timeboost Reserve Pricer API exposes this data publicly over HTTP, returning the current reserve price and the round it applies to. Query this API before submitting any bid.\nThe reserve price is updated at the 31st second of every minute.\nEndpoints\nThe API exposes two endpoints over HTTPS:\n\n/api/latest returns the newest reserve price and round.\n/api/recent returns the reserve price and rounds for the last two hours.\n\nThe base URL differs per network:\nNetworkBase URLArbitrum Sepoliahttps://arbsepolia-reserve-pricer.arbitrum.ioArbitrum Onehttps://arb1-reserve-pricer.arbitrum.io\nFor example, to fetch the latest reserve price and round:\n# Arbitrum One\ncurl https://arb1-reserve-pricer.arbitrum.io/api/latest\n\n# Arbitrum Sepolia\ncurl https://arbsepolia-reserve-pricer.arbitrum.io/api/latest\nStep 3: submit bids\nOnce we have deposited funds into the auction contract, we can submit bids for the current auction round.\nWe can obtain the current round by calling the function currentRound in the Auction contract:\n// Code example uses viem\n\nconst currentRound = await publicClient.readContract({\n address: auctionContractAddress,\n abi: auctionContractAbi,\n functionName: 'currentRound',\n});\nconsole.log(`Current round: ${currentRound}`);\nThe above shows the current round that's running. At the same time, the auction for the next round might be open. For example, if the currentRound is 10, the auction for round 11 is currently happening. To check whether or not that auction is open, we can call the function isAuctionRoundClosed of the Auction contract:\n// Code example uses viem\n\nlet currentAuctionRoundIsClosed = await publicClient.readContract({\n address: auctionContractAddress,\n abi: auctionContractAbi,\n functionName: 'isAuctionRoundClosed',\n});\nNoteRemember that, by default, auctions for a given round open 60 seconds before that round starts and close 15 seconds before the round starts, so there might be no auctions opened at certain times.\nOnce we know the current round, we can bid for (currentRound + 1) and verify that the auction is still open (!currentAuctionRoundIsClosed), then we can submit a bid.\nFetching the minimum bid amountBefore submitting a bid, query the reserve pricer API to retrieve the minimum acceptable bid amount for the round you're bidding on.\nWhen bids get submitted to the autonomous auctioneer endpoint, we need to send an auctioneer_submitBid request with the following information:\n\nchain id\naddress of the express lane controller candidate (for example, our address if we want to be the express lane controller)\naddress of the auction contract\nround we are bidding for (in our example, currentRound + 1)\nthe amount in wei of the deposit ERC-20 token to bid\nsignature (explained below)\n\nLet's see an example of a call to this RPC method:\n// Code example uses viem\n\nconst currentAuctionRound = currentRound + 1;\nconst hexChainId: `0x${string}` = `0x${Number(publicClient.chain.id).toString(16)}`;\n\nconst res = await fetch(<AUTONOMOUS_AUCTIONEER_ENDPOINT>, {\n method: 'POST',\n headers: { 'content-type': 'application/json' },\n body: JSON.stringify({\n jsonrpc: '2.0',\n id: 'submit-bid',\n method: 'auctioneer_submitBid',\n params: [\n {\n chainId: hexChainId,\n expressLaneController: userAddress,\n auctionContractAddress: auctionContractAddress,\n round: `0x${currentAuctionRound.toString(16)}`,\n amount: `0x${Number(amountToBid).toString(16)}`,\n signature: signature,\n },\n ],\n }),\n});\nThe signature that needs to be sent is an EIP-712 signature over the following typed structure data:\n\nDomain: Bid(uint64 round,address expressLaneController,uint256 amount)\nround: auction round number\nexpressLaneController: address of the express lane controller candidate\namount: amount to bid\n\nHere's an example to produce that signature with viem:\n// Code example uses viem\n\nconst currentAuctionRound = currentRound + 1;\n\nconst signatureData = hashTypedData({\n domain: {\n name: 'ExpressLaneAuction',\n version: '1',\n chainId: Number(publicClient.chain.id),\n verifyingContract: auctionContractAddress,\n },\n types: {\n Bid: [\n { name: 'round', type: 'uint64' },\n { name: 'expressLaneController', type: 'address' },\n { name: 'amount', type: 'uint256' },\n ],\n },\n primaryType: 'Bid',\n message: {\n round: currentAuctionRound,\n expressLaneController: userAddress,\n amount: amountToBid,\n },\n});\nconst signature = await account.sign({\n hash: signatureData,\n});\nNoteYou can also call the function getBidHash in the auction contract to obtain the signatureData, specifying the round, userAddress, and amountToBid.\nWhen sending the request, the autonomous auctioneer will return an empty result with an HTTP status 200 if received correctly. If the result returned contains an error message, something went wrong. Following are some of the error messages that can help us understand what's happening:\nErrors relating to bid submission\nErrorDescriptionMALFORMED_DATAWrong input data, failed to deserialize, missing certain fields, etc.NOT_DEPOSITORThe address is not an active depositor in the auction contractWRONG_CHAIN_IDWrong chain id for the target chainWRONG_SIGNATURESignature failed to verifyBAD_ROUND_NUMBERIncorrect round, such as one from the pastRESERVE_PRICE_NOT_METBid amount does not meet the minimum required reserve price onchainINSUFFICIENT_BALANCEThe bid amount specified in the request is higher than the deposit balance of the depositor in the contract\nStep 4: find out the winner of the auction\nAfter the auction closes and before the round starts, the autonomous auctioneer will call the auction contract with the two highest bids received, allowing the contract to declare the winner and deduct the second-highest bid from the winner's deposited funds. After this, the contract will emit an event with the new Express Lane Controller address.\nWe can use this event to determine whether or not we've won the auction. The event signature is:\nevent SetExpressLaneController(\n uint64 round,\n address indexed previousExpressLaneController,\n address indexed newExpressLaneController,\n address indexed transferor,\n uint64 startTimestamp,\n uint64 endTimestamp\n);\nHere's an example to get the log from the auction contract to determine the new express lane controller:\n// Code example uses viem\n\nconst fromBlock = <any recent block, for example during the auction>\nconst logs = await publicClient.getLogs({\n address: auctionContractAddress,\n event: auctionContractAbi.filter((abiEntry) => abiEntry.name === 'SetExpressLaneController')[0],\n fromBlock,\n});\n\nconst newExpressLaneController = logs[0].args.newExpressLaneController;\nconsole.log(`New express lane controller: ${newExpressLaneController}`);\nIf you won the auction, congratulations! You are the express lane controller for the next round, which, by default, will start 15 seconds after the auction closes. The following section explains how we can submit a transaction to the express lane.\nHow to submit transactions to the express lane\nThe sequencer immediately sequences transactions sent to the express lane, while regular transactions are delayed 200ms by default. However, only the express lane controller can send transactions to the express lane. The previous section explained how to participate in the auction as the express lane controller for a given round. For background on default sequencer ordering and the feed, see Sequencing and broadcasting.\nThe sequencer handles the express lane. When sending transactions to the Sequencer endpoint, we need to send a timeboost_sendExpressLaneTransaction request with the following information:\n\nchain id\ncurrent round (following the example above, currentRound)\naddress of the auction contract\nsequence number: a per-round nonce of express lane submissions, which resets to 0 at the beginning of each round. You can also use the special \"dontcare\" sequence number (2^64 - 1) to indicate that you don't care about ordering relative to other ExpressLaneSubmissions (normal nonce ordering within transactions for an account is still respected)\nRLP-encoded transaction payload\nconditional options for Arbitrum transactions (more information)\nsignature (explained below)\n\nTimeboost-ing third party transactionsNotice that while the express lane controller must sign the timeboost_sendExpressLaneTransaction request, any party can sign the transaction for execution. In other words, the express lane controller can receive transactions signed by other parties and sign them to apply the time advantage offered by the express lane to those transactions.\nSupport for eth_sendRawTransactionConditionalTimeboost doesn't currently support the eth_sendRawTransactionConditional method.\nLet's see an example of a call to this RPC method:\n// Code example uses viem\n\nconst hexChainId: `0x${string}` = `0x${Number(publicClient.chain.id).toString(16)}`;\n\nconst transaction = await walletClient.prepareTransactionRequest(...);\nconst serializedTransaction = await walletClient.signTransaction(transaction);\n\nconst res = await fetch(<SEQUENCER_ENDPOINT>, {\n method: 'POST',\n headers: { 'content-type': 'application/json' },\n body: JSON.stringify({\n jsonrpc: '2.0',\n id: 'express-lane-tx',\n method: 'timeboost_sendExpressLaneTransaction',\n params: [\n {\n chainId: hexChainId,\n round: `0x${currentRound.toString(16)}`,\n auctionContractAddress: auctionContractAddress,\n sequenceNumber: `0x${sequenceNumber.toString(16)}`,\n transaction: serializedTransaction,\n options: {},\n signature: signature,\n },\n ],\n }),\n});\nThe required signature is an Ethereum signature that needs to be sent with the following information:\n\nHash of keccak256(\"TIMEBOOST_BID\")\nChain id in hexadecimal, padded to 32 bytes\nAuction contract address\nRound number in hexadecimal, padded to 8 bytes\nSequence number in hexadecimal, padded to 8 bytes\nSerialized transaction\n\nHere's an example to produce that signature:\n// Code example uses viem\n\nconst hexChainId: `0x${string}` = `0x${Number(publicClient.chain.id).toString(16)}`;\n\nconst transaction = await walletClient.prepareTransactionRequest(...);\nconst serializedTransaction = await walletClient.signTransaction(transaction);\n\nconst signatureData = concat([\n keccak256(toHex('TIMEBOOST_BID')),\n pad(hexChainId),\n auctionContract,\n toHex(numberToBytes(currentRound, { size: 8 })),\n toHex(numberToBytes(sequenceNumber, { size: 8 })),\n serializedTransaction,\n]);\nconst signature = await account.signMessage({\n message: { raw: signatureData },\n});\nWhen sending the request, the sequencer will return an empty result with an HTTP status 200 if it received it correctly. If the result returned contains an error message, something went wrong. Following are some of the error messages that can help us understand what's happening:\nErrors relating to express lane transaction submission\nNote that if you get any of the errors below, then the sequence number used in your express lane transaction was not consumed.\nErrorDescriptionMALFORMED_DATAwrong input data, failed to deserialize, missing certain fields, etc.WRONG_CHAIN_IDwrong chain id for the target chainWRONG_SIGNATUREsignature failed to verifyBAD_ROUND_NUMBERincorrect round, such as one from the pastNOT_EXPRESS_LANE_CONTROLLERthe sender is not the express lane controllerNO_ONCHAIN_CONTROLLERthere is no defined, onchain express lane controller for the roundSEQUENCE_NUMBER_ALREADY_SEENthe sequence number used for the given transaction was already consumed, try resubmitting with a new sequence numberSEQUENCE_NUMBER_TOO_LOWthe sequencer number used for the given transaction is numerically lower than the expeected sequence number, try resubmitting with the expected sequence numbersequence number has reached max allowed limitthe limit on the number of buffered express lane transactions was reached. Read more about this on our Troubleshoot Timeboost page\nWhat happens if you're not the express lane controller?If you are not the express lane controller and you try to submit a transaction to the express lane, the sequencer will respond with the error NOT_EXPRESS_LANE_CONTROLLER or NO_ONCHAIN_CONTROLLER.\nHow to withdraw funds deposited in the auction contract\nFunds are deposited in the auction contract to have the right to bid in auctions. Withdrawing funds is possible through a two-step process: initiate the withdrawal, wait for two rounds, and then finalize the withdrawal.\nTo initiate a withdrawal, we can call the function initiateWithdrawal in the Auction contract:\n// Code example uses viem\n\nconst initWithdrawalTransaction = await walletClient.writeContract({\n account,\n address: auctionContractAddress,\n abi: auctionContractAbi,\n functionName: 'initiateWithdrawal',\n});\nconsole.log(`Initiate withdrawal transaction sent: ${initWithdrawalTransaction}`);\nThis transaction will initiate a withdrawal of all funds deposited by the sender's account. When executing it, the contract will emit a WithdrawalInitiated event with the following structure:\nevent WithdrawalInitiated(\n address indexed account,\n uint256 withdrawalAmount,\n uint256 roundWithdrawable\n);\nIn this event, the account is the address from which we will withdraw funds, withdrawalAmount specifies the amount we will take from the contract, and roundWithdrawable indicates the specific round during which we can finalize the withdrawal.\nAfter two rounds have passed, we can call the method finalizeWithdrawal in the Auction contract to finalize the withdrawal:\n// Code example uses viem\n\nconst finalizeWithdrawalTransaction = await walletClient.writeContract({\n account,\n address: auctionContractAddress,\n abi: auctionContractAbi,\n functionName: 'finalizeWithdrawal',\n});\nconsole.log(`Finalize withdrawal transaction sent: ${finalizeWithdrawalTransaction}`);\nHow to identify timeboosted transactions\nTransactions sent to the express lane by the express lane controller and that have been executed (regardless of whether they were successful or reverted) can be identified by examining their receipts or the message broadcast by the Sequencer feed.\nTransaction receipts now include a new field, timeboosted, which will be true for timeboosted transactions and false for regular non-timeboosted transactions. For example:\nblockHash 0x56325449149b362d4ace3267681c3c90823f1e5c26ccc4df4386be023f563eb6\nblockNumber 105169374\ncontractAddress\ncumulativeGasUsed 58213\neffectiveGasPrice 100000000\nfrom 0x193cA786e7C7CC67B6227391d739E41C43AF285f\ngasUsed 58213\nlogs []\nlogsBloom 0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000\nroot\nstatus 1 (success)\ntransactionHash 0x62ea458ad2bb408fab57d1a31aa282fe3324b2711e0d73f4777db6e34bc1bef5\ntransactionIndex 1\ntype 2\nblobGasPrice\nblobGasUsed\nto 0x0000000000000000000000000000000000000001\ngasUsedForL1 \"0x85a5\"\nl1BlockNumber \"0x6e8b49\"\ntimeboosted true\nIn the sequencer feed, the BroadcastFeedMessage struct now contains a blockMetadata field that represents whether a particular transaction in the block was timeboosted or not. The field block metadata is an array of bytes, and it starts with a byte representing the version (0), followed by ceil(N/8) bytes, where N is the number of transactions in the block. If a particular transaction were time-boosted, the bit representing its position in the block would be set to 1, while the rest would reset to 0. For example, if the blockmetadata of a particular message, viewed as bits, is 00000000 01100000, then the 2nd and 3rd transactions in that block were time boosted.\nHow to view historical bid data\nIn the current implementation, information about the winning bid for a resolved auction emits via the AuctionResolved event (sample interface). Historical bid information, including the round number and bid amounts, are published to a public S3 bucket at a regular cadence. The domain for the S3 bucket where historical bids get saved is:\nS3 URLs for historical bid data\nURL updates for historical bid dataOn June 9 2025, at around 17:27 ET (UTC−05:00), the region in which the Amazon S3 bucket for historical bid data on Arbitrum One was changed from s3://timeboost-auctioneer-arb1/uw2/validated-timeboost-bids/ to s3://timeboost-auctioneer-arb1/ue2/validated-timeboost-bids/. The below table has been updated for the new, correct URL to access bid data after June 9, 2025 17:27 ET, but if you require data from before June 9, 2025 17:27 ET, then please use s3://timeboost-auctioneer-arb1/uw2/validated-timeboost-bids/.\nChainS3 bucket URLArbitrum Sepolias3://timeboost-auctioneer-sepolia/ue2/validated-timeboost-bids/Arbitrum Ones3://timeboost-auctioneer-arb1/ue2/validated-timeboost-bids/Arbitrum Novas3://timeboost-auctioneer-nova/ue2/validated-timeboost-bids/\nNoteMake sure you use --no-sign-request with the AWS S3 CLI.\nHere is an example query on how to look up and download historical bid data:\n➜ ~ aws s3 ls s3://timeboost-auctioneer-arb1/ue2/validated-timeboost-bids/2025/06/10/ --no-sign-request --recursive\n\n2025-06-09 18:21:47 12553 ue2/validated-timeboost-bids/2025/06/09/0130304-0130343.csv.gzip\n2025-06-09 18:36:46 4725 ue2/validated-timeboost-bids/2025/06/09/0130344-0130358.csv.gzip\n...\n2025-06-09 17:23:28 3407 uw2/validated-timeboost-bids/2025/06/09/0130264-0130284.csv.gzip\n2025-06-09 17:27:32 1228 uw2/validated-timeboost-bids/2025/06/09/0130285-0130288.csv.gzip\n\n➜ ~ aws s3 cp s3://timeboost-auctioneer-arb1/ue2/validated-timeboost-bids/2025/06/09/0130304-0130343.csv.gzip local.csv.gzip --no-sign-request\ndownload: s3://timeboost-auctioneer-arb1/ue2/validated-timeboost-bids/2025/06/09/0130304-0130343.csv.gzip to ./local.csv.gzip\nDefault parameters\nBelow are a few of the default Timeboost parameters mentioned earlier. All these parameters and more are configurable by the chain owner.\nParameter nameDescriptionRecommended default valueroundDurationSecondsDuration of time that the sequencer will honor the express lane privileges for transactions signed by the current round’s express lane controller.60 secondsauctionClosingSecondsTime before the start of the next round. The autonomous auctioneer will not accept bids during this time interval.15 secondsbeneficiaryAddress where proceeds from the Timeboost auction are sent to when flushBeneficiaryBalance() gets called on the auction contract.An address controlled by the chain's owner_biddingTokenAddress of the token used to make bids in the Timeboost auction. It can be any ERC-20 token (assuming the token chosen does not have fee-on-transfer, rebasing, transfer hooks, or otherwise non-standard ERC-20 logic).WETHnonExpressDelayMsecThe artificial delay applied to the arrival timestamp of non-express lane transactions before the non-express lane transactions are sequenced.0.2 seconds, or 200 millisecondsreservePriceThe minimum bid amount accepted by the auction contract for the current Timeboost auction, denominated in _biddingToken.None_minReservePriceA value that must be equal to or below the reservePrice to act as a \"floor minimum\" for Timeboost bids. Enforced by the auction contract.0.001 WETH\nTroubleshooting and best practices\nOur guide on Troubleshooting Timeboost provides more information on how response times work and how express lane transactions are sequenced, along with common errors and best practices for using Timeboost.How is this guide?How Timeboost worksLearn how Timeboost works and how it can benefit your Arbitrum-based project.Troubleshoot TimeboostA guide on common errors & best practices when using Timeboost","tokens":6028,"squid":"spider-01","role":"Chain Spider","at":1791344049778,"hash":"f4a806cd1de365b55386d2688561371ccf29aaa8"}
{"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 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":4002,"squid":"spider-08","role":"Oracle Spider","at":1791344053181,"hash":"adc4987649d3fc9fd23f713239626416fe278199"}
{"url":"https://forum.arbitrum.foundation/t/the-arbitrumdao-code-of-conduct/30792/3","domain":"forum.arbitrum.foundation","title":"The ArbitrumDAO Code of Conduct - Announcements - Arbitrum","text":"The Arbitrum Foundation notified the Security Council on the need to perform a potential Emergency action. Following a review of the details and known risks, the Security Council decided to execute the upgrade and it was completed at 11:30 EST on 2nd October 2026.\nThis report provides an overview of the risks that required the Security Council Action:\n\nAdd a permissionless guard for the One-Step Proof of BoLD on Arbitrum One\n\nTemporarily pause activation of new Stylus contracts on Arbitrum One & Nova\n\nKey point: To date, known bugs for Stylus primarily impact chain liveness (e.g., denial of service attacks) and do not put any user funds at risk.\nWhy was this action taken\nLet’s take this opportunity to explain why action was taken on two separate issues concerning BoLD and Stylus.\nInstalling the guard for One-Step Proof of BoLD. Given the rise of AI-assisted attacks, we have implemented a precautionary approach that allows anyone to pause settlement of Arbitrum One on Ethereum if there are at least two conflicting answers that pass at the same level in which only one should be valid and pass. This is to halt a class of publicly verifiable and detectable attacks that exploit a bug in the one-step proof. If halted, Arbitrum One will continue to process as normal except that messages from Arbitrum One to Ethereum, such as withdrawals, that are not yet confirmed will have to wait. This provides time for the Security Council to deploy a fix for the bug and resume the rollup.\nPreventing activation of new Stylus contracts. AI-assisted tooling has led to an increasing number of sophisticated attacks on hand-crafted WASM programs that do not use the standard Stylus compiler toolchain. These programs are specifically designed to cause unexpected behaviors such as degrading the chain’s performance for all other users. To date, no attacks have been discovered that permits theft of user funds.\nNew ArbOS releases have patched several reported bugs and known attacks over the past few months, but out of an abundance of caution, we have decided to temporarily pause new activations of Stylus contracts. This was executed as an emergency action to prevent the deployment of new hand-crafted WASM programs that are not yet patched by the current version of ArbOS on the Arbitrum network.\nThe Arbitrum Foundation has informed the Security Council that they will work with the ArbitrumDAO to discuss next steps on the timeline and manner for enabling activation of new Stylus contracts. The Arbitrum community remains confident in the value of Stylus and want to preserve these use cases while taking preventative measures against Stylus-based attack vectors as AI-assisted attack tooling continues to evolve.\nImpact on builders and users\n\nNo new activations. New Stylus contracts cannot be activated during the pause including new versions of existing applications that require activation.\n\nExisting contracts are not paused. Already-active Stylus contracts continue to execute until expiration. This pause does not deactivate them.\n\nThe ArbOS 61 upgrade renewed all active contracts on Arbitrum One, so no currently active contract expires before August 20, 2027.\n\nRenewal via keepalive stays permissionless and is unaffected by the pause.\n\nReactivating an expired contract, or one that needs to be updated after a Stylus version change, is paused.\n\nUsing/calling any activated Stylus contract stays permissionless for all users and developers.\n\nNo impact on EVM. Solidity (EVM) contract deployment and execution are unaffected by this Security Council action.\n\nSecurity Council Actions\nThere are two actions bundled into a single payload:\n\nOne-Step Proof Guard. The L1UpgradeExecutor gives a new pause contract (PauseExecutor) the ability to pause and nothing else. The new pause contract grants the guard (OspSoundnessGuard) PAUSER_ROLE to use it. Anyone can show the guard two conflicting answers to the same step of an open challenge. If the one-step proof accepts both, the guard has the pause contract put Arbitrum One’s settlement to Ethereum on hold.\n\nStylus deactivation. The Security Council called ArbOwner.setWasmActivationGas(2^64 - 1) to raise the Stylus activation gas requirement on Arbitrum One and Nova. This makes activation prohibitively expensive and effectively disables new activations. This is a configuration change and does not require an ArbOS upgrade.\n\nThe Security Council signed the following transactions to update the configuration:\n\nEthereum: Ethereum Transaction Hash: 0x30732bb7d2... | Etherscan\nArbitrum One:\nArbitrum One Transaction Hash: 0x9eb3a4be3b... | Arbitrum One\nArbitrum Nova:\nArbitrum Nova transaction 0x79e0fed470dff7a22059b108e3f8f42eddd2b580a6771594060c4e7326c5f984 | Blockscout\n\nAn external audit was conducted for the OSP Guard contracts. No audit is required for the Stylus deactivation as it is only updating a single parameter in the ArbOS configuration.\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 16\n\n Apr 16\n\n post by OpCo on Apr 16\n\n OpCo\n\n Below you’ll find ArbitrumDAO’s Code of Conduct, approved through the governance process on April 2, 2026. For more historical context, scroll to the bottom.\nValues Alignment\nArbitrum contributors should always strive to uphold the seven community values stated in Section 6:\n\nEthereum-aligned: Arbitrum is part of the Ethereum ecosystem and community\n\nSustainable: Focus on long-term health of the protocol over short-term gains\n\nSecure: Arbitrum is security-minded\n\nSocially inclusive: Open and welcoming to all constructive participants\n\nTechnically inclusive: Accessible for ordinary people with ordinary technology\n\nUser-focused: Managed for the benefit of all users\n\nNeutral and open: Foster open innovation, interoperability, user choice, and healthy competition\n\nGood Faith and Best Interest\n\nContributors should conduct themselves with honesty, integrity, and transparency, fostering trust and confidence among community members.\n\nContributors should act and vote in accordance with what they see is in the best interests of Arbitrum, which encompasses but is not limited to all of the following: Arbitrum One, Arbitrum Nova, the Orbit Ecosystem, and any future Arbitrum DAO-governed chains as outlined in Section 1 of the Arbitrum Constitution.\n\nDue Care and Attention\n\nContributors should remain knowledgeable of developments in regard to Arbitrum DAO’s initiatives and the broader Arbitrum ecosystem.\n\nContributors should strive to make a professional and unbiased review of each proposal before submitting their vote.\n\nContributors are advised to vote abstain when unable to conduct the necessary diligence to understand the proposals.\n\nCivility and Professionalism\n\nWhile separate from the Code of Conduct, contributors are expected to uphold the community guidelines for activity on the Arbitrum DAO forum and de facto understood gathering places for the Arbitrum DAO, whether online or in-person.\n\nContributors should seek to create a respectful and inclusive environment for all community members, free from harassment and discrimination.\n\nUnacceptable behavior includes, but is not limited to:\n\nPublicly or privately harassing or intimidating others\n\nSharing someone’s private information without their consent\n\nUsing sexualized language or imagery, or making unwanted advances\n\nMaking insulting or derogatory comments about others\n\nContributors should strive to provide constructive feedback that is well-researched and respectful, focusing on the proposal’s merits. Personal attacks are never acceptable.\n\nContributors should be open-minded and respectful of differing viewpoints, even if they disagree with them. Disagreements are an inevitable part of healthy debate, but they often yield positive results when approached in a civil manner.\n\nContributors should make a best effort to provide constructive feedback through appropriate channels and avoid taking discussions to social media in a manner that could tarnish Arbitrum DAO’s brand and reputation.\n\nContributors should avoid making unsubstantiated accusations that imply malice without proper evidence. They should conduct proper due diligence before making any public accusations via social media, public forums, or any other recognized communication channels. This includes exhausting all available avenues, such as seeking clarification privately, before issuing any public statement that contains an unsubstantiated accusation about another DAO contributor.\n\nResponsibility\n\nMaintaining a culture of productive debate, integrity, and transparency requires a sense of collective responsibility. As entrusted leaders of the Arbitrum community, contributors should take responsibility in fostering and maintaining a culture that promotes the principles outlined herein.\n\nBest practices of responsible contributors:\n\nParticipation: Contributors should make an effort to vote (even if they vote abstain) on all proposals.\n\nCommunication: Contributors should clearly communicate their rationale behind votes and discussions to the Arbitrum community.\n\nAccountability: Contributors should maintain knowledge of all DAO initiatives and hold managing parties or elected representatives accountable.\n\nResponsiveness: Contributors should use their best efforts to connect with the Arbitrum community and be accessible to answer questions or concerns.\n\nConflicts of Interest\nDisclosure and Transparency Policy: If a conflict of interest exists, it is expected that the contributor discloses the nature and extent of the conflict in writing on the forum before voting. Proposal authors should disclose potential conflicts in the COI section of the recommended proposal template as outlined in the “How to Submit a DAO Proposal” by the Arbitrum Foundation. While it may not always be clear if an individual/entity stands to gain “directly” or “indirectly”, contributors and proposal authors are recommended to lean on the side of over-communication in the name of transparency.\nContributors who disclose a conflict of interest are not expected to alter their voting in any way. Self-voting is not currently banned outright for the reasons stated in previous DAO-wide discussions and based on sentiment gathered from a subsequent temperature check. However, a contributor who repeatedly fails to disclose a conflict of interest before voting risks being removed from their compensated governance role.\nAI tools and responsible participation in the ArbitrumDAO\nThe use of AI tools to automate administrative tasks, overcome language barriers, or process and summarize large blocks of information is expected. That said, the ArbitrumDAO discourages the irresponsible use of AI agents that may lead to the forum being littered with comments that do little to add value to the conversation.\nGoing forward, moderators of the forum (currently the Arbitrum Foundation and OpCo) will proactively monitor for comments that are off-topic or irrelevant to the main discussion, with the aim of mitigating the irresponsible use of AI agents. Moderators may use a variety of tools to assist their review, but moderation decisions will be based on the quality, relevance and intention of the contribution rather than solely on whether it appears to have been AI-generated. Repeat infractions will lead to suspension or, in severe cases, user deletion.\nModerators retain discretion to remove content that undermines productive governance discussions. Where appropriate, moderators may redirect off-topic discussions to a more suitable venue rather than removing them or message the author with similar suggestions. Enforcement will generally follow a graduated process:\n\nRemoval or redirection of the relevant content, with an explanation where practical.\nA formal warning for repeated low-quality or disruptive contributions.\nTemporary suspension for continued violations following a warning.\nLonger suspensions or permanent removal from the forum in cases of persistent abuse, automated spam campaigns, or other serious or repeated violations.\n\nCommunity members are encouraged to flag content they believe is off-topic, repetitive or otherwise inconsistent with these guidelines. Moderators will review flagged content on a case-by-case basis.\nEnforcement & Appeal Process\nAll contributors are expected to abide by the Code of Conduct. Enforcement will take place through any program that financially compensates performing governance activities, such as rewards for voting/forum activity, or participation in DAO-approved programs where contributors are directly elected to facilitate the programs.\nThe program manager, council, or comparable facilitator in charge of the program is the one responsible for determining violations of the Code of Conduct and reserves the right to take what it deems as appropriate action, which may include but is not limited to, issuing a warning, suspension, or removal from the program. Any community member can raise a concern to the party responsible for managing the program with respect to a contributor failing to uphold the Code of Conduct. While the responsible party is required to acknowledge receipt of the concern and investigate the matter, the final determination and resulting course of action, which may include dismissing the concern, will depend on the underlying program’s structure.\nIf there are contradictions between the Code of Conduct and the specific program that is compensating a contributor, then the policies of the program shall take precedence. It is assumed that a program will define its own appeal process, but if it does not, then the conflict resolution section (next) will be the default appeal approach.\nConflict Resolution\nResolution of conflicts between contributors (and between contributors and programs) will be entrusted to the OpCo, which will act as a neutral mediator. It is recommended that contributors first seek to resolve conflict issues in good faith and privately. If the matter is unable to be resolved for any reason, or if the behavior is threatening or harassing, the matter can be raised to the OpCo. The OpCo will have the final say on the issue and reserves the right to determine if the issue should be brought to the attention of the community as a whole.\n\n If you want to submit a request for support in resolving a conflict, please do so through this form.\n\nImportant Terms\nContributor: An individual or entity who willingly engages in Arbitrum governance and/or is compensated via a DAO-approved program.\nDAO-approved program: A structured initiative that is funded and/or authorized by the Arbitrum DAO through a formal governance vote (Tally or Snapshot) and designed to achieve defined objectives. Examples include the Arbitrum Audit Program, the Arbitrum D.A.O. Grant Program, and other comparable initiatives that receive DAO treasury funding or delegated authority.\nCommunity Guidelines: The rules of engagement for the Arbitrum DAO forum as outlined and enforced by the Arbitrum Foundation.\nConflict of Interest (COI): A situation where a contributor, or any entity with which a contributor has a direct professional or financial relationship, stands to directly benefit from the outcome of a proposal or election.\n\nHistorical Context\nThe previous version of the Code of Conduct was voted for a trial period that was set to expire on January 31st, 2026. There was a stipulation that enabled the Arbitrum Foundation to extend the trial period by an additional 2 months. During that extension, the Arbitrum Foundation, Entropy Advisors and OpCo worked on gathering feedback from delegates, considered and made some amendments, and put a new version of the Code of Conduct forward through the governance process. The vote passed successfully and as of April 2026, the OpCo has assumed the responsibility for stewarding the Code of Conduct of the ArbitrumDAO.\nOn July 6th, 2026, the OpCo proposed an amendment to the Code of Conduct, adding language around the responsible use of AI tools in the participation of delegates and contributors in the ArbitrumDAO.\nThe amendment was optimistically approved 14 days later, in accordance with the ‘Feedback and Review Process’ outlined in the Code of Conduct itself.\nPast Versions\nThe above is the third amendment of the Code of Conduct and is now under the stewardship of the OpCo. You can find previous, now deprecated, versions in the links below.\n1st Code of Conduct\n2nd Code of Conduct\n\nFeedback and Review Process\nWith the Code of Conduct existing as living documents, the OpCo will serve as the steward of the documents and is responsible for maintaining them over time. Changes can be proposed and adopted through the following process:\nFeedback and Observation. Any contributor may propose amendments by submitting feedback through a dedicated channel maintained by OpCo (for example a forum thread or dedicated google form). OpCo may also identify necessary changes based on its own observations of governance activity, enforcement gaps, or evolving DAO needs.\nDrafting and Posting. When OpCo determines that a change is warranted, it will draft the proposed amendment and post it to the governance forum with a clear description of what is being changed and why.\nOptimistic Approval. Proposed changes take effect automatically 14 days after being posted to the forum unless a combined 5% of DVP, calculated at the time of the forum post, raises objections through the appropriate governance forum amendment thread. This threshold, currently ~16.75M VP, is high enough to prevent trivial escalations from slowing down maintenance-type updates, but low enough that a coalition of small-medium sized delegates can trigger a vote on changes they consider substantive. The 14-day window is intended to give delegates sufficient time to review the proposed changes and OpCo will be responsible for monitoring objections and tallying the VP delegates.\n\nEscalation to an Offchain Vote. If sufficient VP raises an objection to the changes, the OpCo must then put the change to an offchain vote with a quorum set at the active non-constitutional quorum level.\n\nAnnual Review. In addition to the ongoing amendment process, OpCo will conduct a review of the Code of Conduct and DAO Procedures each January, soliciting community feedback and proposing any updates deemed necessary. This review serves as a regular checkpoint but does not preclude amendments at other times of the year.\n\n Proposed Amendment to the Code of Conduct: AI tools and Responsible Participation Policy\n\n Oversight and Transparency Committee (OAT) - June 2026 Elections Overview\n\n read \n\n 5\n min\n\n Pinned on Apr 16\n\n Closed 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 The Arbitrum DAO Code of Conduct\n\n Archived Announcements\n\n 0\n\n 272\n\n Jul 2025\n\n [Deprecated] The Arbitrum DAO Delegate Code of Conduct\n\n Archive\n\n 1\n\n 428\n\n May 2025\n\n Terms and Conditions of RAD\n\n Rewarding Active Delegates Program (RAD)\n\n 0\n\n 156\n\n Dec 2025\n\n [Non-Constitutional] Arbitrum DAO Delegate Code of Conduct + Formalizing the DAO’s Operations\n\n Finalized AIPs\n\n 85\n\n 2.4k\n\n Jun 2025\n\n Proposed Amendment to the Code of Conduct: AI tools and Responsible Participation Policy\n\n Finalized AIPs\n\n 4\n\n 123\n\n Jul 20","tokens":4829,"squid":"spider-07","role":"Council Spider","at":1791344069301,"hash":"f05a8667949eaf574ffe46fcb93b8b6b20e9b45c"}
{"url":"https://akash.network/current-groups/sig-economics/","domain":"akash.network","title":"Economics Special Interest Group - Community Groups","text":"Back\n Steering Committee Steering Committee Special Interest Groups Analytics Special Interest Group Chain Special Interest Group Clients Special Interest Group Community Special Interest Group Deployments Special Interest Group Design Special Interest Group Documentation Special Interest Group Economics Special Interest Group Education Providers Special Interest Group Support Special Interest Group Working Groups Akash Hackathon Working Group Akash Website Akash Youtube Client Libraries Working Group Content Moderation Working Group Economics 2.0 2023 Events - Working Group GPU Working Group Provider Attributes Working Group Provider Audit Working Group Testnets Working Group Zealy Economics Special Interest Group The goal of this SIG is to ensure that AKT, the utility token of Akash Network, is used in ways to incentivize long-term, sustainable growth of the network. This can include but is not limited to incentivizing engineering development, provider onboarding, community efforts, and security budget. \nView on Discord\n\nView on GitHub\n\nSubscribe to Calendar\n Akash Network - Economics Special Interest Group (SIG)\nThe goal of this SIG is to ensure that AKT, the utility token of Akash Network, is used in ways to incentivize long-term, sustainable growth of the network. This can include but is not limited to incentivizing engineering development, provider onboarding, community efforts, and security budget.\nMeetings\nMeetings usually happens every First Wednesday of the Month\n\nMeetingTimeNotesTranscriptRecording#1Wednesday, February 1, 2023 10:00 AM PT (Pacific Time)LinkLinkLink#2Wednesday, March 1, 2023 10:00 AM PT (Pacific Time)LinkLinkLink#3Wednesday, April 5, 2023 10:00 AM PT (Pacific Time)LinkLinkLink#4Wednesday, May 3, 2023 10:00 AM PT (Pacific Time)LinkLinkLink#5Wednesday, June 7, 2023 10:00 AM PT (Pacific Time)LinkLinkLink#6Wednesday, July 5, 2023 10:00 AM PT (Pacific Time)LinkLinkLink#7Wednesday, August 2, 2023 10:00 AM PT (Pacific Time)LinkLinkLink#8Wednesday, September 6, 2023 10:00 AM PT (Pacific Time)LinkLinkLink#9Wednesday, October 4, 2023 10:00 AM PT (Pacific Time)LinkLinkLink#10Wednesday, November 1, 2023 10:00 AM PT (Pacific Time)LinkLinkLink#11Wednesday, December 06, 2023 10:00 AM PT (Pacific Time)LinkLinkLink#12Wednesday, January 10, 2024 10:00 AM PT (Pacific Time)LinkLinkLink#13Wednesday, February 07, 2024 10:00 AM PT (Pacific Time)LinkLinkLink#14Wednesday, March 06, 2024 10:00 AM PT (Pacific Time)LinkLinkLink#15April 3rd, 2024 10:00 AM PT (Pacific Time)LinkLinkLink#16May 1st, 2024 10:00 AM PT (Pacific Time)LinkLinkLink#17June 18th, 2024 10:00 AM PT (Pacific Time)LinkLinkLink#18July 3rd, 2024 10:00 AM PT (Pacific Time)LinkLinkLink#19August 07, 2024 10:00 AM PT (Pacific Time)LinkLinkLink#20October 09, 2024 10:00 AM PT (Pacific Time)LinkLinkLink#21November 6th, 2024 10:00 AM PT (Pacific Time)LinkLinkLink#22December 4th, 2024 10:00 AM PT (Pacific Time)LinkLinkLink#23January 8th, 2025 10:00 AM PT (Pacific Time)LinkLinkLink#24February 5th, 2025 09:00 AM PT (Pacific Time)LinkLinkLink#25March 19th, 2025 09:00 AM PT (Pacific Time)LinkLinkLink#26April, 2025 09:00 AM PT (Pacific Time)LinkLinkLink#27May, 2025 09:00 AM PT (Pacific Time)LinkLinkLink#28June 11 , 2025 09:00 AM PT (Pacific Time)LinkLinkLink#29July 09, 2025 09:00 AM PT (Pacific Time)LinkLinkLink#30August 06, 2025 09:00 AM PT (Pacific Time)LinkLinkLink#31September, 2025 09:00 AM PT (Pacific Time)LinkLinkLink#32October 22, 2025 09:00 AM PT (Pacific Time)LinkLinkLink#33December 10, 2025 09:00 AM PT (Pacific Time)LinkLinkLink#34February 4, 2026 09:00 AM PT (Pacific Time)LinkLinkLink#35March 11, 2026 09:00 AM PT (Pacific Time)LinkLinkComing Soon#36April 28, 2026 09:00 AM PT (Pacific Time)LinkLinkLink#37May, 2026 09:00 AM PT (Pacific Time)LinkLinkLink#38June 17, 2026 09:00 AM PT (Pacific Time)LinkLinkLink#39July, 2026 09:00 AM PT (Pacific Time)LinkLinkLink#40August 26th, 2026 09:00 AM PT (Pacific Time)#41September, 2026 09:00 AM PT (Pacific Time)#42October, 2026 09:00 AM PT (Pacific Time)#43Novemeber, 2026 09:00 AM PT (Pacific Time)#44December, 2026 09:00 AM PT (Pacific Time)\nLeadership\nSpecial Interest Group Meeting Leads:\n\nCheng Wang, CFO Overclock Labs\n\nContact\n\nDiscord Server\n\nSub Projects, Repositories & Relevant Work Groups\nThe following are projects and work-groups that sig-economics participates in or contributes to:\n\nwg-economics-2.0\n Documentation Special Interest Group Education","tokens":1108,"squid":"spider-03","role":"Compute Spider","at":1791344069333,"hash":"8fd35f2670fba1141bf819189ad87c5c0479757c"}
{"url":"https://developer.arbitrum.io/how-arbitrum-works/timeboost/timeboost-faq","domain":"developer.arbitrum.io","title":"Frequently Asked Questions (FAQs) about Timeboost","text":"Frequently Asked Questions (FAQs) about TimeboostTimeboost FAQRequest an updateBelow are some common and frequently asked questions about Timeboost. This list of questions is in no particular order and will be updated periodically as new questions arise.\nWho is Timeboost for, and how do I use it?\nTimeboost is an optional addition to an Arbitrum chain’s infrastructure, meaning that enabling Timeboost is at the discretion of the chain owner and that an Arbitrum chain can fully function normally without Timeboost.\nWhen enabled, Timeboost serves different groups of parties with varying degrees of impact and benefits. Let’s go through them below:\nFor regular users:\nThe only difference users should experience is a small delay when submitting their transactions. The default configuration for this delay is 200ms, and a chain's owner can adjust it.\nThe delay intends to give the express lane controller an advantage, allowing them to include transactions slightly quicker than others. Importantly, user transactions will remain private until after they are sequenced, meaning that the express lane controller cannot frontrun or sandwich other users.\nFor chain owners:\nTimeboost represents a unique way to accrue value for its token and generate revenue for the chain. Explicitly, chain owners can set up their Timeboost auction to collect bid proceeds in the same token used for gas on their network and then choose what to do with these proceeds afterward.\nFor searchers/arbitrageurs:\nTimeboost adds a unique twist to your existing or prospective MEV strategies that may become more profitable than before. For instance, purchasing the time advantage offered by Timeboost’s auction may end up costing less than the costs of investing in hardware and winning latency races. Another example is the potential new business model of reselling express lane rights to other parties on a time slot or per-transaction basis.\nSpecial note on Timeboost for chain owners\nAs with many new features and upgrades to Arbitrum Nitro, Timeboost is an optional feature that chain owners may choose to deploy and customize however they see fit. Deploying and enabling/disabling Timeboost on a live Arbitrum chain will not halt or impact the chain but will instead influence the chain's transaction ordering policy. An Arbitrum chain will, by default, fall back to FCFS in scenarios where Timeboost is deployed but disabled, or if there is no express lane controller for a given round.\nWe recommend that Arbitrum chains holistically assess the applicability and use cases of Timeboost for their chain before deploying and enabling Timeboost. This assessment is necessary because some Arbitrum chains may not have that much MEV (e.g., arbitrage) to begin with. Furthermore, we recommend that Arbitrum chains start with the default parameters recommended by Offchain Labs and closely monitor the results and impacts on their chain’s ecosystem over time before considering any adjustments to the parameters.\nUsing Timeboost\nHow can I participate in Timeboost directly?\nInterested parties can participate in the Timeboost auctions by depositing funds in the auction contract and sending bids to the autonomous auctioneer. Feel free to refer to this guide for more information.\nThe Timeboost auction is open to everyone; however, since auctions require a non-zero bid to win, only parties that can generate a return from capturing arbitrage opportunities, backrunning opportunities, or reselling the express lane rights will benefit from participating.\nThe Timeboost protocol operates behind the scenes with minimal impact on normal users, generating revenue for the chain owners and opening up an additional revenue stream for sophisticated searchers.\nWhat is the goal of Timeboost?\nThe goal of Timeboost is to provide chain owners with a way to capture available MEV on their chain and reduce spam from FCFS arbitrage while preserving a best-in-class user experience with both fast block times and protecting users from harmful MEV (e.g., frontrunning, sandwich attacks).\nDoes it work with Arbitrum chains?\nArbitrum chains can adopt Timeboost, and Arbitrum chain owners can also choose to use any ERC-20 token for making bids. For example, a chain could decide to accept its (or any other) token for the auction.\nHow do I change or cancel my bid after I have submitted it?\nThe autonomous auctioneer will consider only an address’s most recent bid, meaning that if you have placed a bid and wish to change it, you may re-submit a bid to “update it.” To cancel a bid, place a new bid that is significantly lower than your original bid or bid below the minimum reserve price. Remember that there is a maximum of five bids per round per address to mitigate DDoS risks.\nSecurity questions\nDoes Timeboost create new types of MEV extraction vectors?\nTimeboost does not create new types of Maximum Extractable Value (MEV). Instead, it introduces slight adjustments to when and how existing forms of MEV operate. Timeboost's design strikes a balance between capturing MEV value for the chain without introducing additional externalities.\nFor example, Timeboost does not enable transaction reordering in a way that facilitates sandwich attacks. The protocol does allow users to attempt to process their transactions earlier by gaining control of the express lane. Still, it doesn't permit them to manipulate the order in which trades occur relative to others in the same block. This ordering means the fast lane controller [at any given time] cannot be certain of how their transactions will get ordered relative to others' transactions.\nDoes Timeboost give the auction winner an unfair advantage or power around transaction ordering?\nWinning a Timeboost auction gives you a time advantage — specifically, a proposed 200ms “head start” — but it does not ensure your transaction will always be the first in every block. The perceived value of the express lane is determined by its holder and the amount they choose to bid to win control of it; it’s a use-it-or-lose-it privilege. Let’s be clear on what Timeboost does not do:\n\nIt does not give anyone the right to reorder transactions. It does not allow you to view others’ transactions until they are sequenced (because the mempool remains private).\nIt does not ensure your transaction will always be the first in every block.\nIt does not mean your transaction will have absolutely zero total time delay. Winning the bid means you won’t experience the 200ms artificial delay others face, but natural delays — such as processing time or network distance — still apply.\n\nIs it expected for powerful, centralized entities to monopolize the Timeboost express lane? Could this lead to harmful outcomes?\nTimeboost's design is an auction-based system that encourages open competition. Although the idea of a monopoly can be intimidating, the auction process remains competitive. If one player dominates, they will be required to outbid other users, which prevents them from maintaining complete static control continuously. Additionally, the express lane only gives a 200ms time advantage. The system is designed to incentivize rational actors to participate when they believe there is an advantage to controlling the express lane and only bid up to the value they are willing to pay for that advantage (since it is a sealed-bid auction).\nFinally, Timeboost is entirely optional, meaning that Arbitrum chains can still function normally without it. Should Timeboost need to be disabled, the network would smoothly revert to FCFS transaction ordering, maintaining its current security and efficiency. Every chain can make its own decision about whether to enable Timeboost–your chain, your rules.\nTechnical questions\nDoes Timeboost mean an expectation for searchers to bid continuously in advance, expecting opportunities to happen one minute later, rather than “in real time” opportunities (I see something → I submit an arbitrage tx with priority)?\nBefore answering this question, it is worth clarifying that the participant will likely attempt to predict the amount of MEV generated between 15 seconds and 1 minute 15 seconds in the future, not 1 minute later. This assumption is because the auction is closed and resolved within a maximum of 15 seconds before the start of the next round (as proposed in the current proposal).\nThe expectation is willing participants will bid continuously for the right to use the express lane in advance so that they (the participant) can profit from both (1) MEV opportunities they predict between 15s and 1min 15s in the future and (2) MEV opportunities in real-time during the period that the participant is in control of the express lane that they didn’t otherwise predict in advance (proposed duration: 1 minute). Suppose the participant does not win control of the express lane. In that case, opportunities that they see in real-time are still exploitable, but with a 200ms delay, similar to all other transactions (since only the express lane controller’s transactions get sequenced with no delay).\nWhat are the different variations of Timeboost?\nTimeboost is implemented by modifying the sequencer to add an express lane and deploying an autonomous auctioneer service to facilitate the auction (sealed-bid, second-price) for temporary rights to control the express lane. Timeboost was designed and developed with decentralization in mind, including one that is compatible with decentralized sequencers (full specification here).\nWill Timeboost work with future decentralized Arbitrum sequencers?\nYes. Timeboost is compatible with both the current centralized sequencer and a future design that allows Arbitrum chains to benefit from a decentralized group of sequencers. The current approach allowed us to deliver Timeboost sooner rather than waiting until the decentralized sequencer design and implementation are complete. A full specification of Timeboost with decentralized sequencers can be found here).\nWill there be plans for a clean user interface that allows users to understand the logic of how their transactions get sorted, as well as an optional setting to adjust the sensitivity to the time factor?\nFor the first point about a more straightforward user interface, users can subscribe to the sequencer feed to view, in real time, the final order of transactions. Using the sequencer feed is a sufficient solution for helping users understand the logic behind how their transactions get sorted. Additional documentation and diagrams will be forthcoming to help illustrate this workflow.\nTo the second point, chain owners can adjust the amount of time that non-express lane transactions get delayed. This parameter, defined as NonExpressDelayMsec, is denominated in milliseconds and is proposed to be 200ms initially.\nHow will Timeboost affect block time finality on Arbitrum chains? Does this mean that an Arbitrum chain's new block time will be 450ms?\nRecall that Arbitrum chains have two types of finality: (1) a trusted or and (2) Ethereum-equivalent finality. A trusted or soft confirmation for a user’s transaction relies on the user trusting the sequencer and the near-instant transaction receipt issued by the sequencer, which takes approximately 250ms. For (2), the user can use the Ethereum-equivalent finality heuristic once their child chain transaction becomes finalized on the parent chain as part of a batch of transactions posted to Ethereum, which can take two epochs, or roughly 13 minutes, in today’s Proof-of-Stake Ethereum. Read more about these two types of finality in Finality.\nWith Timeboost, both finality timelines for non-express lane transactions (250ms for soft finality and ~13 minutes for Ethereum-equivalent finality) will extend by the default 200ms delay proposed in Timeboost, which will be roughly ~450ms and ~13 minutes & 0.2 seconds for soft finality and Ethereum-equivalent finality, respectively.\nFor express lane transactions, there will be no impact on transaction finality, meaning that finality will remain at 250ms and ~13 minutes for soft finality and Etheruem-equivalent finality, respectively.\nIs there a way to track the time (milliseconds, etc.) it takes for a transaction to be sent and received by the sequencer?\nYes! Measure the time between when you send your transaction and when you see it in the sequencer feed. Here, we assume that “accepted” refers to the point at which the sequencer has seen your transaction and gets processed into a block. This number is not uniformly consistent because different teams will have access to different hardware and setups, which may affect how quickly they can send messages over the public internet to the sequencer and also how quickly they can read the sequencer’s feed for state updates and transaction receipts.\nDoes gas have any effect on the transaction ordering in the sequencer?\nYes, because if your transaction did not provide enough gas, it might get rejected outright. If you specify insufficient gas, your transaction may be excluded from an upcoming block because it does not meet the network's requirements for processing, which include child chain execution and parent chain data posting costs. For details on how those two cost components are calculated, see Gas and fees.\nDoes Arbitrum support non-JSON formats for submitting transactions?\nNo.\nHow does the sequencer handle raw transaction requests that contain incorrect data, like an inconsistent nonce? For example, multiple transactions by same wallet with same nonce are submitted to the sequencer. Would there be any penalty for that wallet/IP address?\nYou should expect to get a nonce error. This behavior will work today, but this is considered abuse and we provide no guarantees on how this behavior will be treated in the future.\nDoes the sequencer have any rate limit? If it has, what is the limit, and is it per IP address or wallet?\nYes, but these limits are not published, and we don’t expect anyone to reach them. The limits are per IP address.\nIs it recommended to send requests directly to the sequencer IP address(es) instead of the sequencer domain if we want the lowest latency?\nNo, it is not recommended.\nIs there a more efficient way to track if our transaction has been accepted or rejected by the sequencer than listening to smart contract events or transaction counts?\nYes. We recommend that teams monitor and verify transaction receipts to obtain formal confirmation that their transaction gets included in a block.\nFor Timeboost, is there a limit on the number of transactions that can receive a boost from the winner in a round?\nThere is no transaction limit, but there is a block-based limit: if your Timeboosted transactions do not get sequenced within five Arbitrum blocks (1250ms) from the time that the sequencer received them, then they will get dropped. The 200ms Timeboost time advantage only lasts for 1000ms anyway, so this is a safe limit that people will not hit. Note that the block gas limit may be a reason why your transaction(s) doesn't get included in an Arbitrum block. More details on this limit can be found in the Timeboost troubleshooting guide.\nIf a transaction is Timeboosted and we assume it arrived in the current block creation period, which includes other non-express lane transactions, would that Timeboosted transaction queue in front of those other non-express lane transactions that have already arrived but not included yet?\nIt depends on the arrival timestamp of all the transactions. \"Regular\" transactions will receive a 200ms delay before being sequenced, while Timeboosted transactions will receive zero delay before being sequenced. In this scenario, if the \"regular\" transactions had arrived 200 milliseconds earlier than the Timeboosted transaction, they would get sequenced alongside the Timeboosted transaction based on their arrival timestamps. In this case, for that block, some \"regular\" transactions may indeed be ahead of Timeboosted transactions due to the timestamps. For additional information, read this document that explains how Timeboost works.\nApart from Timeboost, are there any other mechanisms or factors that can affect transaction priority or latency?\nThere are many factors, including how your infrastructure is set up and built, as well as where you are sending transactions from. Latency is something that top teams will optimize for, so spend time focusing on this to ensure you can maximize the benefits of Timeboost. The 200ms time advantage you receive from using Timeboost is likely more than enough to exploit the arbitrage opportunities onchain (ahead of competitors who are not using Timeboost).\nAre there any recommendations for submitting transactions to Arbitrum with lower latency in addition to Timeboost?\nYeah! We recommend:\n\nDoing adequate testing of your infrastructure to optimize for the geographical latency considerations,\nA solid setup for bid submission if using Timeboost,\nRunning your transaction pre-checker, Arbitrum full node, and a client to subscribe to the sequencer feed for the fastest onchain updates, the ability to send transactions fast, robust nonce management, and\nBuild a good observability and monitoring stack to watch and take action on events from the auction and also to review and process transaction receipts quickly to confirm behavior\nHow is this guide?Troubleshoot TimeboostA guide on common errors & best practices when using TimeboostTimeboostTransaction ordering and the Timeboost auction on Arbitrum chains.","tokens":4371,"squid":"spider-01","role":"Chain Spider","at":1791344069412,"hash":"9dc7aba779371609af34c6291abeb7c1ea484b56"}
{"url":"https://developer.arbitrum.io/how-arbitrum-works/timeboost/troubleshoot-timeboost","domain":"developer.arbitrum.io","title":"Troubleshoot Timeboost","text":"Troubleshoot TimeboostA guide on common errors & best practices when using TimeboostRequest an updateThis is a short guide on how response times work and how are sequenced, alongside common errors and best practices for using . This guide assumes you have reviewed our guide on How to use Timeboost.\nHow express lane transactions are ordered into blocks\nThe express lane time advantage is currently set to 200ms, while the current block creation time is 250ms. Both express lane transactions and regular transactions are processed together in a single queue after taking into account the timeboost time advantage and artificial delay. This means that if an express lane transaction and a normal transaction both arrive at the sequencer at the same time, but before 50ms have passed since the last block was produced, then both transactions may appear in the same block, though the express lane transaction would be sequenced ahead of the normal transaction (assuming that the block's gas limit has not yet been reached).\nExpress lane transactions are processed in the order of their sequenceNumber, which is a field in every express lane transaction. The sequenceNumber field is important because transactions with sequenceNumber = n can only be sequenced after all the transactions from sequenceNumber = 0 to sequenceNumber = n-1 have been sequenced. The first expected sequence number for a new round is zero and increments for each accepted transaction.\nThere is a special \"dontcare\" sequence number (2^64 - 1) that can be used to indicate that you don't care about ordering of this express lane submission relative to others. Transactions with the \"dontcare\" sequence number will be sequenced right away without waiting for any other transactions. Note that normal nonce ordering within transactions for an account is still respected, so transactions from the same account will still be ordered by their nonce regardless of sequence number. The express lane controller can send ExpressLaneSubmissions with both \"dontcare\" and normal sequence numbers within the same round.\nHow response times work\nThe response for a transaction submission to the express lane is returned immediately once received by the sequencer. For example, if an express lane transaction is sent to the sequencer at t=0ms and it took 50ms to arrive at the sequencer (defined as time_to_arrive), then the expected response time is at t=50ms. Note that an accepted transaction is defined as an express lane transaction submission where the sequencer returns an empty result with an HTTP status of 200 and will always have their sequenceNumber consumed. You can read more about how to submit express lane transactions in: How to submit transactions to the express lane.\nErrors relating to the sequenceNumber\nWhen it comes to submitting express lane transactions, there are a few scenarios to consider. Note that if your use case doesn't require an ordering between ExpressLaneSubmissions beyond the usual per account nonce ordering, then you can use the \"dontcare\" sequence number described above.\nScenario 1: You get an error response immediately\nIn this scenario, an error response is immediately returned after you send an express lane transaction. In most cases the transaction's sequenceNumber will not be consumed if the error is Timeboost-related or if the transaction was invalid (e.g., nonce too low, malformed transaction). If the error contains \"Error queuing expressLane transaction\" you need to re-submit your transaction with the same sequence number after rectifying any errors, or submit a different transaction with that sequence number. See Common Timeboost error responses below for a full list of Timeboost-related error responses and how to interpret them.\nScenario 2: Your transaction got an empty response with an HTTP status of 200\nIn this scenario, a null response is immediately returned after you send an express lane transaction. This means that your transaction's sequenceNumber was consumed and your transaction was accepted. However, this does not mean that your transaction was sequenced into a block due to a block-based timeout explained below. We recommend checking transaction receipts for confirmation on whether your transactions were sequenced into a block or not.\nThe block-based timeout for express lane transactions\nIf the express lane controller decides to send a burst of transactions to the express lane with ascending values for the sequenceNumber, then the sequencer will attempt to process them in the order defined by the sequenceNumber (as explained above). However, if the transactions arrive out-of-order at the sequencer, then the transactions that do not have the expected sequenceNumber will be buffered (up to a limit) to be processed until the sequencer receives the transaction with the expected sequenceNumber. Once the sequencer receives the transaction with the expected sequenceNumber, then the sequencer will begin processing the buffered transaction with the next sequenceNumber. In other words, a transaction will only be sequenced into a block once transactions with the other, missing sequence numbers arrive to fill in the “gap” between the expected sequencerNumber and a given transaction’s sequenceNumber. For background on the sequencer's default (non-express-lane) ordering and feed, see Sequencing and broadcasting.\nA block-based timeout is applied to all express lane transactions, even those in the buffer, such that any transactions accepted (meaning sequenceNumber is consumed) by the sequencer will be dropped if they are not sequenced into a block within five blocks. This timeout can occur if the cumulative gas usage of transactions (express lane or otherwise) fill up 5 blocks worth of transactions before all of the buffered express lane transactions are sequenced. No timeout error will be returned in this case and we recommend checking transaction receipts for confirmation on whether your transactions were sequenced into a block or not. Note that each Arbitrum block has a gas limit of 32 million gas and 1 Arbitrum block is produced every 250ms. This block-based timeout is likely to be reached before the limit on buffered transactions is hit in almost all cases.\nCommon error responses\nThe below two tables can also be found on our guide on How to use Timeboost.\nTable 1: Errors relating to bid submission\nErrorDescriptionMALFORMED_DATAwrong input data, failed to deserialize, missing certain fields, etc.NOT_DEPOSITORthe address is not an active depositor in the auction contractWRONG_CHAIN_IDwrong chain id for the target chainWRONG_SIGNATUREsignature failed to verifyBAD_ROUND_NUMBERincorrect round, such as one from the pastRESERVE_PRICE_NOT_METbid amount does not meet the minimum required reserve price onchainINSUFFICIENT_BALANCEthe bid amount specified in the request is higher than the deposit balance of the depositor in the contract\nTable 2: Errors relating to express lane transaction submission\nNote that if you get any of the errors below or errors related to invalidity of the transaction (e.g., nonce too low, malformed transaction), then the sequence number used in your express lane transaction was not consumed.\nErrorDescriptionMALFORMED_DATAwrong input data, failed to deserialize, missing certain fields, etc.WRONG_CHAIN_IDwrong chain id for the target chainWRONG_SIGNATUREsignature failed to verifyBAD_ROUND_NUMBERincorrect round, such as one from the pastNOT_EXPRESS_LANE_CONTROLLERthe sender is not the express lane controllerNO_ONCHAIN_CONTROLLERthere is no defined, onchain express lane controller for the roundSEQUENCE_NUMBER_ALREADY_SEENthe sequence number used for the given transaction was already consumed, try resubmitting with a new sequence numberSEQUENCE_NUMBER_TOO_LOWthe sequencer number used for the given transaction is numerically lower than the expeected sequence number, try resubmitting with the expected sequence numbersequence number has reached max allowed limitthe limit on the number of buffered express lane transactions was reached\nNotes on Timeboost's implementation for Arbitrum One & Arbitrum Nova\nAlthough the auctioneer will function autonomously, please note that the ArbitrumDAO (formal owners of Arbitrum One and Arbitrum Nova) has granted the sequencer operator with:\n\nThe right to pause the acceptance and verification of bids. This is to allow the current sequencer operator to provide reliable, consistent UX and maximize infrastructure stability, and\nThe right to disable Timeboost entirely in the event of a security risk or otherwise malicious attempt to harm Arbitrum One and Arbitrum Nova node operators, existing deployed applications, and/or end users. The Arbitrum Foundation and Offchain Labs commits to sharing publicly post-mortems and analyses should this scenario arise.\n\nThese rights, among a few others as described in the original AIP, are expected to only be exercised in circumstances where doing so would enhance Timeboost’s long-term stability, preserve or improve the user experience for those using Timeboost-enabled Arbitrum chains, increase the security posture, resiliency, or stability of the chain, and/or otherwise help increase revenue for the ArbitrumDAO.\nIt is important to emphasize that for Arbitrum One and Arbitrum Nova, the DAO-elected Arbitrum Security Council can, at any time, perform either Emergency Actions or Non-Emergency Actions to execute software upgrades, perform routine maintenance, and other parameter adjustments to Timeboost, in each case in accordance with its existing powers. These actions can include, but are not limited solely to, exercising the rights proposed above for the current sequencer operator. More information about the Arbitrum Security Council and their scope of powers can be found in the ArbitrumDAO Constitution.How is this guide?Use TimeboostLearn how to use timeboostTimeboost FAQTimeboost FAQ","tokens":2474,"squid":"spider-01","role":"Chain Spider","at":1791344091309,"hash":"b88328281bfe327ed27f786f65212d7811065ec4"}
{"url":"https://forum.arbitrum.foundation/t/the-arbitrum-dao-code-of-conduct/29713/1","domain":"forum.arbitrum.foundation","title":"The Arbitrum DAO Code of Conduct - Archive / Archived Announcements - Arbitrum","text":"The Arbitrum Foundation notified the Security Council on the need to perform a potential Emergency action. Following a review of the details and known risks, the Security Council decided to execute the upgrade and it was completed at 11:30 EST on 2nd October 2026.\nThis report provides an overview of the risks that required the Security Council Action:\n\nAdd a permissionless guard for the One-Step Proof of BoLD on Arbitrum One\n\nTemporarily pause activation of new Stylus contracts on Arbitrum One & Nova\n\nKey point: To date, known bugs for Stylus primarily impact chain liveness (e.g., denial of service attacks) and do not put any user funds at risk.\nWhy was this action taken\nLet’s take this opportunity to explain why action was taken on two separate issues concerning BoLD and Stylus.\nInstalling the guard for One-Step Proof of BoLD. Given the rise of AI-assisted attacks, we have implemented a precautionary approach that allows anyone to pause settlement of Arbitrum One on Ethereum if there are at least two conflicting answers that pass at the same level in which only one should be valid and pass. This is to halt a class of publicly verifiable and detectable attacks that exploit a bug in the one-step proof. If halted, Arbitrum One will continue to process as normal except that messages from Arbitrum One to Ethereum, such as withdrawals, that are not yet confirmed will have to wait. This provides time for the Security Council to deploy a fix for the bug and resume the rollup.\nPreventing activation of new Stylus contracts. AI-assisted tooling has led to an increasing number of sophisticated attacks on hand-crafted WASM programs that do not use the standard Stylus compiler toolchain. These programs are specifically designed to cause unexpected behaviors such as degrading the chain’s performance for all other users. To date, no attacks have been discovered that permits theft of user funds.\nNew ArbOS releases have patched several reported bugs and known attacks over the past few months, but out of an abundance of caution, we have decided to temporarily pause new activations of Stylus contracts. This was executed as an emergency action to prevent the deployment of new hand-crafted WASM programs that are not yet patched by the current version of ArbOS on the Arbitrum network.\nThe Arbitrum Foundation has informed the Security Council that they will work with the ArbitrumDAO to discuss next steps on the timeline and manner for enabling activation of new Stylus contracts. The Arbitrum community remains confident in the value of Stylus and want to preserve these use cases while taking preventative measures against Stylus-based attack vectors as AI-assisted attack tooling continues to evolve.\nImpact on builders and users\n\nNo new activations. New Stylus contracts cannot be activated during the pause including new versions of existing applications that require activation.\n\nExisting contracts are not paused. Already-active Stylus contracts continue to execute until expiration. This pause does not deactivate them.\n\nThe ArbOS 61 upgrade renewed all active contracts on Arbitrum One, so no currently active contract expires before August 20, 2027.\n\nRenewal via keepalive stays permissionless and is unaffected by the pause.\n\nReactivating an expired contract, or one that needs to be updated after a Stylus version change, is paused.\n\nUsing/calling any activated Stylus contract stays permissionless for all users and developers.\n\nNo impact on EVM. Solidity (EVM) contract deployment and execution are unaffected by this Security Council action.\n\nSecurity Council Actions\nThere are two actions bundled into a single payload:\n\nOne-Step Proof Guard. The L1UpgradeExecutor gives a new pause contract (PauseExecutor) the ability to pause and nothing else. The new pause contract grants the guard (OspSoundnessGuard) PAUSER_ROLE to use it. Anyone can show the guard two conflicting answers to the same step of an open challenge. If the one-step proof accepts both, the guard has the pause contract put Arbitrum One’s settlement to Ethereum on hold.\n\nStylus deactivation. The Security Council called ArbOwner.setWasmActivationGas(2^64 - 1) to raise the Stylus activation gas requirement on Arbitrum One and Nova. This makes activation prohibitively expensive and effectively disables new activations. This is a configuration change and does not require an ArbOS upgrade.\n\nThe Security Council signed the following transactions to update the configuration:\n\nEthereum: Ethereum Transaction Hash: 0x30732bb7d2... | Etherscan\nArbitrum One:\nArbitrum One Transaction Hash: 0x9eb3a4be3b... | Arbitrum One\nArbitrum Nova:\nArbitrum Nova transaction 0x79e0fed470dff7a22059b108e3f8f42eddd2b580a6771594060c4e7326c5f984 | Blockscout\n\nAn external audit was conducted for the OSP Guard contracts. No audit is required for the Stylus deactivation as it is only updating a single parameter in the ArbOS configuration.\n\n The Arbitrum DAO Code of Conduct \n\n ArchiveArchived Announcements\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jul 2025\n\n 1 / 5\n\n Jul 2025\n\n Jul 2025\n\n post by Entropy on Jul 30, 2025\n\n Entropy\n\n April 2026 Update: This version of the Delegate Code of Conduct is now deprecated following the ratification of the living permanent version managed by OpCo.\nContributors looking for the first iteration of the Code of Conduct from November 2024, can find deprecated document in the forum’s archive.\n\nThe Arbitrum Code of Conduct is a set of guiding principles to help establish explicit expectations and responsibilities for contributors, while also ensuring that Arbitrum DAO’s culture is transparent, professional, and civil.\nThe Code of Conduct applies for interactions between contributors, whether online or offline. This includes the governance forum, Telegram and Discord chats, governance community or working group calls, and any other virtual or physical space that is de-facto understood to be a gathering place for the Arbitrum DAO. Contributors should use their best discretion and act in a way that aligns with the Code’s spirit, rather than seeking to exploit loopholes or ambiguities.\nFollowing discussions and ratification via Snapshot vote, this version of the Code of Conduct is in effect until January 31st, 2026. To ensure that the DAO has ample time to discuss future revisions or inclusion into the Arbitrum Constitution without the Code of Conduct losing its validity, the Arbitrum Foundation reserves the right to extend their effectiveness by up to two months through March 31st, 2026 as long as a new version has not yet been officially ratified.\nImportant Terms\nContributor: An individual or entity who willingly engages in Arbitrum governance and/or is compensated via a DAO-approved program.\nDAO-approved program: A structured initiative that is funded and/or authorized by the Arbitrum DAO through a formal governance vote (Tally or Snapshot) and designed to achieve defined objectives. Examples include the Arbitrum Audit Program, the Arbitrum D.A.O. Grant Program, and other comparable initiatives that receive DAO treasury funding or delegated authority.\nCommunity Guidelines: The rules of engagement for the Arbitrum DAO forum as outlined and enforced by the Arbitrum Foundation.\nConflict of Interest (COI): A situation where a contributor, or any entity with which a contributor has a direct professional or financial relationship, stands to directly benefit from the outcome of a proposal or election.\nArbitrum DAO Code of Conduct\nAt the conclusion of the trial period, the DAO if it is time to formalize the language into the Arbitrum Constitution. Based on conversations thus far, it is envisioned as a new Section 7 with the following quoted block containing the 5 sub-sections to be included:\n\n7.1 Values Alignment\nArbitrum contributors should always strive to uphold the seven community values stated above in Section 6:\n\nEthereum-aligned: Arbitrum is part of the Ethereum ecosystem and community\nSustainable: Focus on long-term health of the protocol over short-term gains\nSecure: Arbitrum is security minded\nSocially inclusive: Open and welcoming to all constructive participants\nTechnically inclusive: Accessible for ordinary people with ordinary technology\nUser-focused: Managed for the benefit of all users\nNeutral and open: Foster open innovation, interoperation, user choice, and healthy competition\n\n7.2 Good Faith and Best Interest\n\nContributors should conduct themselves with honesty, integrity, and transparency, fostering trust and confidence among community members.\nContributors should act and vote in accordance with what they see is in the best interests of Arbitrum, which encompasses but is not limited to all of the following: Arbitrum One, Arbitrum Nova, the Orbit Ecosystem, and any future Arbitrum DAO-governed chains as outlined above in Section 1.\n\n7.3 Due Care and Attention\n\nContributors should remain knowledgeable of developments in regard to Arbitrum DAO’s initiatives and the broader Arbitrum ecosystem.\nContributors should strive to make a professional and unbiased review of each proposal before submitting their vote.\nContributors are advised to vote abstain when unable to conduct the necessary diligence to understand the proposals.\n\n7.4 Civility and Professionalism\n\nWhile separate from the Code of Conduct, contributors are expected to uphold the community guidelines for activity on the Arbitrum DAO forum and de facto understood gathering places for the Arbitrum DAO, whether online or in-person.\nContributors should seek to create a respectful and inclusive environment for all community members, free from harassment and discrimination.\n\nUnacceptable behavior includes, but is not limited to:\n\nPublicly or privately harassing or intimidating others\nSharing someone’s private information without their consent\nUsing sexualized language or imagery, or making unwanted advances\nMaking insulting or derogatory comments about others\n\nContributors should strive to provide constructive feedback that is well-researched and respectful, focusing on the proposal’s merits. Personal attacks are never acceptable.\nContributors should be open-minded and respectful of differing viewpoints, even if they disagree with them. Disagreements are an inevitable part of healthy debate, but they often yield positive results when approached in a civil manner.\nContributors should make a best effort to provide constructive feedback through appropriate channels and avoid taking discussions to social media in a manner that could tarnish Arbitrum DAO’s brand and reputation.\nContributors should avoid making unsubstantiated accusations that imply malice without proper evidence. They should conduct proper due diligence before making any public accusations via social media, public forums, or any other recognized communication channels. This includes exhausting all available avenues, such as seeking clarification privately, before issuing any public statement that contains an unsubstantiated accusation about another DAO contributor.\n\n7.5 Responsibility\n\nMaintaining a culture of productive debate, integrity, and transparency requires a sense of collective responsibility. As entrusted leaders of the Arbitrum community, contributors should take responsibility in fostering and maintaining a culture that promotes the principles outlined herein.\nBest practices of responsible contributors:\n\nParticipation: Contributors should make an effort to vote (even if they vote abstain) on all proposals.\nCommunication: Contributors should clearly communicate their rationale behind votes and discussions to the Arbitrum community.\nAccountability: Contributors should maintain knowledge of all DAO initiatives and hold managing parties or elected representatives accountable.\nResponsiveness: Contributors should use their best efforts to connect with the Arbitrum community and be accessible to answer questions or concerns.\n\nSub-sections 7.1 through 7.5 outline enduring values and expectations appropriate for constitutional inclusion, while the following clauses regarding Conflicts of Interest, Enforcement & Appeal Process, and Conflict Resolution are more operational in nature. They are envisioned to remain outside the Arbitrum Constitution so that they may more easily adapt over time based on active programs, contributor behavior, and evolving community standards.\nConflicts of Interest\nDisclosure and Transparency Policy: If a conflict of interest exists, it is expected that the contributor discloses the nature and extent of the conflict in writing on the forum before voting. Proposal authors should disclose potential conflicts in the COI section of the recommended proposal template as outlined in the “How to Submit a DAO Proposal” by the Arbitrum Foundation. While it may not always be clear if an individual/entity stands to gain “directly” or “indirectly”, contributors and proposal authors are recommended to lean on the side of over-communication in the name of transparency.\nContributors who disclose a conflict of interest are not expected to alter their voting in any way. Self-voting is not currently banned outright for the reasons stated in previous DAO-wide discussions and based on sentiment gathered from a subsequent temperature check. However, a contributor who repeatedly fails to disclose a conflict of interest before voting risks being removed from their compensated governance role.\nEnforcement & Appeal Process\nAll contributors are expected to abide by the Code of Conduct. Enforcement will take place through any program that financially compensates performing governance activities, such as rewards for voting/forum activity, or participation in DAO-approved programs where contributors are directly elected to facilitate the programs.\nThe program manager, council, or comparable facilitator in charge of the program is the one responsible for determining violations of the Code of Conduct and reserves the right to take what it deems as appropriate action, which may include but is not limited to, issuing a warning, suspension, or removal from the program. Any community member can raise a concern to the party responsible for managing the program with respect to a contributor failing to uphold the Code of Conduct. While the responsible party is required to acknowledge receipt of the concern and investigate the matter, the final determination and resulting course of action, which may include dismissing the concern, will depend on the underlying program’s structure.\nIf there are contradictions between the Code of Conduct and the specific program that is compensating a contributor, then the policies of the program shall take precedence. It is assumed that a program will define its own appeal process, but if it does not, then the conflict resolution section (next) will be the default appeal approach.\nConflict Resolution\nResolution of conflicts between contributors (and between contributors and programs) will be entrusted to the Arbitrum Foundation, which will act as a neutral mediator. It is recommended that contributors first seek to resolve conflict issues in good faith and privately. If the matter is unable to be resolved for any reason, or if the behavior is threatening or harassing, the matter can be raised to the Arbitrum Foundation using this form. The Arbitrum Foundation will have the final say on the issue and reserves the right to determine if the issue should be brought to the attention of the community as a whole.\nIn the future and once OpCo is fully operational, responsibility for the resolution of conflicts can be transferred to the OpCo at the Arbitrum Foundation’s discretion. The Arbitrum Foundation will acknowledge when this transfer can take place and make it public on the governance forum when it goes into effect.\n\n The ArbitrumDAO Code of Conduct\n\n Updating the Code of Conduct & DAO's Procedures\n\n Arbitrum Triple Dip (Delegate Incentive Program)\n\n AGV - 2026 Council Elections\n\n [Deprecated] The Arbitrum DAO Delegate Code of Conduct\n\n read \n\n 4\n min\n\n Closed on Jul 31, 2025\n\n 4 months later\n\n Pinned on Nov 28, 2025\n\n 5 months later\n\n Unpinned on Apr 16\n\n Unarchived 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 The ArbitrumDAO Code of Conduct\n\n Announcements\n\n 0\n\n 193\n\n Apr 16\n\n [Deprecated] The Arbitrum DAO Delegate Code of Conduct\n\n Archive\n\n 1\n\n 428\n\n May 2025\n\n Terms and Conditions of RAD\n\n Rewarding Active Delegates Program (RAD)\n\n 0\n\n 156\n\n Dec 2025\n\n [Non-Constitutional] Arbitrum DAO Delegate Code of Conduct + Formalizing the DAO’s Operations\n\n Finalized AIPs\n\n 85\n\n 2.4k\n\n Jun 2025\n\n Proposed Amendment to the Code of Conduct: AI tools and Responsible Participation Policy\n\n Finalized AIPs\n\n 4\n\n 123\n\n Jul 20","tokens":4199,"squid":"spider-07","role":"Council Spider","at":1791344091471,"hash":"a1ee5f89e085a4c5f314ddf8ac8f184ad631fe0f"}
{"url":"https://akash.network/current-groups/wg-gpu/","domain":"akash.network","title":"GPU Working Group - Community Groups","text":"Back\n Steering Committee Steering Committee Special Interest Groups Analytics Special Interest Group Chain Special Interest Group Clients Special Interest Group Community Special Interest Group Deployments Special Interest Group Design Special Interest Group Documentation Special Interest Group Economics Special Interest Group Education Providers Special Interest Group Support Special Interest Group Working Groups Akash Hackathon Working Group Akash Website Akash Youtube Client Libraries Working Group Content Moderation Working Group Economics 2.0 2023 Events - Working Group GPU Working Group Provider Attributes Working Group Provider Audit Working Group Testnets Working Group Zealy GPU Working Group This working group is dedicated to figuring out everything that needs to happen for Akash to offer GPUs on its provider network. This includes coming up with specifications for provider, deployments, clients, inventory sourcing, understanding application needs, integrations with partners etc. \nView on Discord\n\nView on GitHub\n\nSubscribe to Calendar\n Akash Network GPU Working Group\nThis working group is dedicated to figuring out everything that needs to happen for Akash to offer GPUs on its provider network. This includes coming up with specifications for provider, deployments, clients, inventory sourcing, understanding application needs, integrations with partners etc.\nMeetings\n\nMeetingTimeNotesTranscriptRecording#1Tuesday, February 7, 2023 11:00 AM PT (Pacific Time)LinkLinkLink\nLeads\n\nAnil Murty (@anilmurty)\nArtur Troian (@troian)\nAdam Bozanich (@boz)\nGreg Osuri (@gosuri)\n\nContacts\n\nDiscord\n\nGoals\n\nDecide on tradeoffs w.r.to cross vendor vs just Nvidia, need for private containers, bandwidth pricing.\nDefine requirements for provider setup & Attiributes\nDefine requirements for deployment (SDL)\nCommunicate required changes to various client teams\nForm partnerships with data center providers, mining OSes and others to build inventory\nConduct user research with ML & AI App developers as well as middleware platforms (that offer models as a service) to understand end-to-end user experience\nRun Alpha/ Beta programs\nFigure out events to pitch Akash GPU support at\n\nPRDs and other documentation\n\nPRD\nProgress\n\nRelated SIGs\n\nsig-providers\nsig-clients\nsig-deployments\n 2023 Events - Working Group Provider Attributes Working Group","tokens":588,"squid":"spider-03","role":"Compute Spider","at":1791344100815,"hash":"d3950df412d432b86d9b4f0e8e5abc1937d73790"}
{"url":"https://developer.arbitrum.io/how-arbitrum-works/deep-dives/sequencer","domain":"developer.arbitrum.io","title":"The Sequencer and censorship resistance","text":"The Sequencer and censorship resistanceLearn the fundamentals of the Arbitrum Sequencer.Request an updateThe job is to receive, admit, and order and then publish and post the resulting blocks. The moment ordered transactions are handed to the execution engine, responsibility shifts to the and , 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 fee-surplus thresholds can reject it; and internal Arbitrum transaction types and 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 . Under , 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 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 . This is the moment users get soft finality: a sub-second provisional confirmation that depends on the Sequencer behaving honestly.\nOn , 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 reads sequenced messages from the TransactionStreamer, Brotli-compresses them with adaptive compression levels, and posts them to the 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. clears any 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 enter through the parent chain’s . The DelayedSequencer watches for these messages to finalize on the parent chain, then sequences them into the 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 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 One auctioned a 60-second to one 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 ’s parent chain Sequencer (the Sequencer) is censoring or offline. In such a case, every and/or sub- move would need to wait 24 hours before bypassing the L2 Sequencer (using the Sequencer Inbox’s 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 ) 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.How is this guide?GethLearn the fundamentals of Nitro, Arbitrum stack.","tokens":3012,"squid":"spider-01","role":"Chain Spider","at":1791344102188,"hash":"3a2956df5d276481915115edde1cfe6dccf9a2d1"}
{"url":"https://forum.arbitrum.foundation/t/the-arbitrum-dao-code-of-conduct/29713/6","domain":"forum.arbitrum.foundation","title":"The Arbitrum DAO Code of Conduct - Archive / Archived Announcements - Arbitrum","text":"The Arbitrum Foundation notified the Security Council on the need to perform a potential Emergency action. Following a review of the details and known risks, the Security Council decided to execute the upgrade and it was completed at 11:30 EST on 2nd October 2026.\nThis report provides an overview of the risks that required the Security Council Action:\n\nAdd a permissionless guard for the One-Step Proof of BoLD on Arbitrum One\n\nTemporarily pause activation of new Stylus contracts on Arbitrum One & Nova\n\nKey point: To date, known bugs for Stylus primarily impact chain liveness (e.g., denial of service attacks) and do not put any user funds at risk.\nWhy was this action taken\nLet’s take this opportunity to explain why action was taken on two separate issues concerning BoLD and Stylus.\nInstalling the guard for One-Step Proof of BoLD. Given the rise of AI-assisted attacks, we have implemented a precautionary approach that allows anyone to pause settlement of Arbitrum One on Ethereum if there are at least two conflicting answers that pass at the same level in which only one should be valid and pass. This is to halt a class of publicly verifiable and detectable attacks that exploit a bug in the one-step proof. If halted, Arbitrum One will continue to process as normal except that messages from Arbitrum One to Ethereum, such as withdrawals, that are not yet confirmed will have to wait. This provides time for the Security Council to deploy a fix for the bug and resume the rollup.\nPreventing activation of new Stylus contracts. AI-assisted tooling has led to an increasing number of sophisticated attacks on hand-crafted WASM programs that do not use the standard Stylus compiler toolchain. These programs are specifically designed to cause unexpected behaviors such as degrading the chain’s performance for all other users. To date, no attacks have been discovered that permits theft of user funds.\nNew ArbOS releases have patched several reported bugs and known attacks over the past few months, but out of an abundance of caution, we have decided to temporarily pause new activations of Stylus contracts. This was executed as an emergency action to prevent the deployment of new hand-crafted WASM programs that are not yet patched by the current version of ArbOS on the Arbitrum network.\nThe Arbitrum Foundation has informed the Security Council that they will work with the ArbitrumDAO to discuss next steps on the timeline and manner for enabling activation of new Stylus contracts. The Arbitrum community remains confident in the value of Stylus and want to preserve these use cases while taking preventative measures against Stylus-based attack vectors as AI-assisted attack tooling continues to evolve.\nImpact on builders and users\n\nNo new activations. New Stylus contracts cannot be activated during the pause including new versions of existing applications that require activation.\n\nExisting contracts are not paused. Already-active Stylus contracts continue to execute until expiration. This pause does not deactivate them.\n\nThe ArbOS 61 upgrade renewed all active contracts on Arbitrum One, so no currently active contract expires before August 20, 2027.\n\nRenewal via keepalive stays permissionless and is unaffected by the pause.\n\nReactivating an expired contract, or one that needs to be updated after a Stylus version change, is paused.\n\nUsing/calling any activated Stylus contract stays permissionless for all users and developers.\n\nNo impact on EVM. Solidity (EVM) contract deployment and execution are unaffected by this Security Council action.\n\nSecurity Council Actions\nThere are two actions bundled into a single payload:\n\nOne-Step Proof Guard. The L1UpgradeExecutor gives a new pause contract (PauseExecutor) the ability to pause and nothing else. The new pause contract grants the guard (OspSoundnessGuard) PAUSER_ROLE to use it. Anyone can show the guard two conflicting answers to the same step of an open challenge. If the one-step proof accepts both, the guard has the pause contract put Arbitrum One’s settlement to Ethereum on hold.\n\nStylus deactivation. The Security Council called ArbOwner.setWasmActivationGas(2^64 - 1) to raise the Stylus activation gas requirement on Arbitrum One and Nova. This makes activation prohibitively expensive and effectively disables new activations. This is a configuration change and does not require an ArbOS upgrade.\n\nThe Security Council signed the following transactions to update the configuration:\n\nEthereum: Ethereum Transaction Hash: 0x30732bb7d2... | Etherscan\nArbitrum One:\nArbitrum One Transaction Hash: 0x9eb3a4be3b... | Arbitrum One\nArbitrum Nova:\nArbitrum Nova transaction 0x79e0fed470dff7a22059b108e3f8f42eddd2b580a6771594060c4e7326c5f984 | Blockscout\n\nAn external audit was conducted for the OSP Guard contracts. No audit is required for the Stylus deactivation as it is only updating a single parameter in the ArbOS configuration.\n\n ArchiveArchived Announcements\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jul 2025\n\n 5 / 5\n\n Apr 16\n\n Jul 2025\n\n post by Entropy on Jul 30, 2025\n\n Entropy\n\n April 2026 Update: This version of the Delegate Code of Conduct is now deprecated following the ratification of the living permanent version managed by OpCo.\nContributors looking for the first iteration of the Code of Conduct from November 2024, can find deprecated document in the forum’s archive.\n\nThe Arbitrum Code of Conduct is a set of guiding principles to help establish explicit expectations and responsibilities for contributors, while also ensuring that Arbitrum DAO’s culture is transparent, professional, and civil.\nThe Code of Conduct applies for interactions between contributors, whether online or offline. This includes the governance forum, Telegram and Discord chats, governance community or working group calls, and any other virtual or physical space that is de-facto understood to be a gathering place for the Arbitrum DAO. Contributors should use their best discretion and act in a way that aligns with the Code’s spirit, rather than seeking to exploit loopholes or ambiguities.\nFollowing discussions and ratification via Snapshot vote, this version of the Code of Conduct is in effect until January 31st, 2026. To ensure that the DAO has ample time to discuss future revisions or inclusion into the Arbitrum Constitution without the Code of Conduct losing its validity, the Arbitrum Foundation reserves the right to extend their effectiveness by up to two months through March 31st, 2026 as long as a new version has not yet been officially ratified.\nImportant Terms\nContributor: An individual or entity who willingly engages in Arbitrum governance and/or is compensated via a DAO-approved program.\nDAO-approved program: A structured initiative that is funded and/or authorized by the Arbitrum DAO through a formal governance vote (Tally or Snapshot) and designed to achieve defined objectives. Examples include the Arbitrum Audit Program, the Arbitrum D.A.O. Grant Program, and other comparable initiatives that receive DAO treasury funding or delegated authority.\nCommunity Guidelines: The rules of engagement for the Arbitrum DAO forum as outlined and enforced by the Arbitrum Foundation.\nConflict of Interest (COI): A situation where a contributor, or any entity with which a contributor has a direct professional or financial relationship, stands to directly benefit from the outcome of a proposal or election.\nArbitrum DAO Code of Conduct\nAt the conclusion of the trial period, the DAO if it is time to formalize the language into the Arbitrum Constitution. Based on conversations thus far, it is envisioned as a new Section 7 with the following quoted block containing the 5 sub-sections to be included:\n\n7.1 Values Alignment\nArbitrum contributors should always strive to uphold the seven community values stated above in Section 6:\n\nEthereum-aligned: Arbitrum is part of the Ethereum ecosystem and community\nSustainable: Focus on long-term health of the protocol over short-term gains\nSecure: Arbitrum is security minded\nSocially inclusive: Open and welcoming to all constructive participants\nTechnically inclusive: Accessible for ordinary people with ordinary technology\nUser-focused: Managed for the benefit of all users\nNeutral and open: Foster open innovation, interoperation, user choice, and healthy competition\n\n7.2 Good Faith and Best Interest\n\nContributors should conduct themselves with honesty, integrity, and transparency, fostering trust and confidence among community members.\nContributors should act and vote in accordance with what they see is in the best interests of Arbitrum, which encompasses but is not limited to all of the following: Arbitrum One, Arbitrum Nova, the Orbit Ecosystem, and any future Arbitrum DAO-governed chains as outlined above in Section 1.\n\n7.3 Due Care and Attention\n\nContributors should remain knowledgeable of developments in regard to Arbitrum DAO’s initiatives and the broader Arbitrum ecosystem.\nContributors should strive to make a professional and unbiased review of each proposal before submitting their vote.\nContributors are advised to vote abstain when unable to conduct the necessary diligence to understand the proposals.\n\n7.4 Civility and Professionalism\n\nWhile separate from the Code of Conduct, contributors are expected to uphold the community guidelines for activity on the Arbitrum DAO forum and de facto understood gathering places for the Arbitrum DAO, whether online or in-person.\nContributors should seek to create a respectful and inclusive environment for all community members, free from harassment and discrimination.\n\nUnacceptable behavior includes, but is not limited to:\n\nPublicly or privately harassing or intimidating others\nSharing someone’s private information without their consent\nUsing sexualized language or imagery, or making unwanted advances\nMaking insulting or derogatory comments about others\n\nContributors should strive to provide constructive feedback that is well-researched and respectful, focusing on the proposal’s merits. Personal attacks are never acceptable.\nContributors should be open-minded and respectful of differing viewpoints, even if they disagree with them. Disagreements are an inevitable part of healthy debate, but they often yield positive results when approached in a civil manner.\nContributors should make a best effort to provide constructive feedback through appropriate channels and avoid taking discussions to social media in a manner that could tarnish Arbitrum DAO’s brand and reputation.\nContributors should avoid making unsubstantiated accusations that imply malice without proper evidence. They should conduct proper due diligence before making any public accusations via social media, public forums, or any other recognized communication channels. This includes exhausting all available avenues, such as seeking clarification privately, before issuing any public statement that contains an unsubstantiated accusation about another DAO contributor.\n\n7.5 Responsibility\n\nMaintaining a culture of productive debate, integrity, and transparency requires a sense of collective responsibility. As entrusted leaders of the Arbitrum community, contributors should take responsibility in fostering and maintaining a culture that promotes the principles outlined herein.\nBest practices of responsible contributors:\n\nParticipation: Contributors should make an effort to vote (even if they vote abstain) on all proposals.\nCommunication: Contributors should clearly communicate their rationale behind votes and discussions to the Arbitrum community.\nAccountability: Contributors should maintain knowledge of all DAO initiatives and hold managing parties or elected representatives accountable.\nResponsiveness: Contributors should use their best efforts to connect with the Arbitrum community and be accessible to answer questions or concerns.\n\nSub-sections 7.1 through 7.5 outline enduring values and expectations appropriate for constitutional inclusion, while the following clauses regarding Conflicts of Interest, Enforcement & Appeal Process, and Conflict Resolution are more operational in nature. They are envisioned to remain outside the Arbitrum Constitution so that they may more easily adapt over time based on active programs, contributor behavior, and evolving community standards.\nConflicts of Interest\nDisclosure and Transparency Policy: If a conflict of interest exists, it is expected that the contributor discloses the nature and extent of the conflict in writing on the forum before voting. Proposal authors should disclose potential conflicts in the COI section of the recommended proposal template as outlined in the “How to Submit a DAO Proposal” by the Arbitrum Foundation. While it may not always be clear if an individual/entity stands to gain “directly” or “indirectly”, contributors and proposal authors are recommended to lean on the side of over-communication in the name of transparency.\nContributors who disclose a conflict of interest are not expected to alter their voting in any way. Self-voting is not currently banned outright for the reasons stated in previous DAO-wide discussions and based on sentiment gathered from a subsequent temperature check. However, a contributor who repeatedly fails to disclose a conflict of interest before voting risks being removed from their compensated governance role.\nEnforcement & Appeal Process\nAll contributors are expected to abide by the Code of Conduct. Enforcement will take place through any program that financially compensates performing governance activities, such as rewards for voting/forum activity, or participation in DAO-approved programs where contributors are directly elected to facilitate the programs.\nThe program manager, council, or comparable facilitator in charge of the program is the one responsible for determining violations of the Code of Conduct and reserves the right to take what it deems as appropriate action, which may include but is not limited to, issuing a warning, suspension, or removal from the program. Any community member can raise a concern to the party responsible for managing the program with respect to a contributor failing to uphold the Code of Conduct. While the responsible party is required to acknowledge receipt of the concern and investigate the matter, the final determination and resulting course of action, which may include dismissing the concern, will depend on the underlying program’s structure.\nIf there are contradictions between the Code of Conduct and the specific program that is compensating a contributor, then the policies of the program shall take precedence. It is assumed that a program will define its own appeal process, but if it does not, then the conflict resolution section (next) will be the default appeal approach.\nConflict Resolution\nResolution of conflicts between contributors (and between contributors and programs) will be entrusted to the Arbitrum Foundation, which will act as a neutral mediator. It is recommended that contributors first seek to resolve conflict issues in good faith and privately. If the matter is unable to be resolved for any reason, or if the behavior is threatening or harassing, the matter can be raised to the Arbitrum Foundation using this form. The Arbitrum Foundation will have the final say on the issue and reserves the right to determine if the issue should be brought to the attention of the community as a whole.\nIn the future and once OpCo is fully operational, responsibility for the resolution of conflicts can be transferred to the OpCo at the Arbitrum Foundation’s discretion. The Arbitrum Foundation will acknowledge when this transfer can take place and make it public on the governance forum when it goes into effect.\n\n The ArbitrumDAO Code of Conduct\n\n Updating the Code of Conduct & DAO's Procedures\n\n Arbitrum Triple Dip (Delegate Incentive Program)\n\n AGV - 2026 Council Elections\n\n [Deprecated] The Arbitrum DAO Delegate Code of Conduct\n\n read \n\n 4\n min\n\n Closed on Jul 31, 2025\n\n 4 months later\n\n Pinned on Nov 28, 2025\n\n 5 months later\n\n Unpinned on Apr 16\n\n Unarchived 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 The ArbitrumDAO Code of Conduct\n\n Announcements\n\n 0\n\n 193\n\n Apr 16\n\n [Deprecated] The Arbitrum DAO Delegate Code of Conduct\n\n Archive\n\n 1\n\n 428\n\n May 2025\n\n Terms and Conditions of RAD\n\n Rewarding Active Delegates Program (RAD)\n\n 0\n\n 156\n\n Dec 2025\n\n [Non-Constitutional] Arbitrum DAO Delegate Code of Conduct + Formalizing the DAO’s Operations\n\n Finalized AIPs\n\n 85\n\n 2.4k\n\n Jun 2025\n\n Proposed Amendment to the Code of Conduct: AI tools and Responsible Participation Policy\n\n Finalized AIPs\n\n 4\n\n 123\n\n Jul 20","tokens":4189,"squid":"spider-07","role":"Council Spider","at":1791344104432,"hash":"a8bd60af703debdd8cf41917b02fb6189a8af34a"}
{"url":"https://akash.network/current-groups/wg-economics-20/","domain":"akash.network","title":"Economics 2.0 - Community Groups","text":"Back\n Steering Committee Steering Committee Special Interest Groups Analytics Special Interest Group Chain Special Interest Group Clients Special Interest Group Community Special Interest Group Deployments Special Interest Group Design Special Interest Group Documentation Special Interest Group Economics Special Interest Group Education Providers Special Interest Group Support Special Interest Group Working Groups Akash Hackathon Working Group Akash Website Akash Youtube Client Libraries Working Group Content Moderation Working Group Economics 2.0 2023 Events - Working Group GPU Working Group Provider Attributes Working Group Provider Audit Working Group Testnets Working Group Zealy Economics 2.0 This working group is for the development of Akash Economics 2.0 which aims to provide more budget towards network development activies while trading off security budget among other variables. \nView on Discord\n\nView on GitHub\n\nSubscribe to Calendar\n Akash Network Economics 2.0 Working Group\nThis working group is for the development of Akash Economics 2.0 which aims to provide more budget towards network development activies while trading off security budget among other variables.\nMeetings\nTBD\n\nMeetingTimeNotesTranscriptRecording#1\nLeads\n\nGreg Osuri, CEO Overclock Labs\nAdam Bozanich, CTO Overclock Labs\nCheng Wang, CFO Overclock Labs\nScott Hewitson, Finance Associate Overclock Labs\n\nContacts\n\nDiscord Server\n\nGoals\n\nCreate sustainable way to incentivize development activites on Akash Network\nInvestigate opportunities to reduce security budget\nProduce governance proposal to implement changes\n\nPRDs and other documentation\n\nTBD\n\nRelated SIGs\n\nsig-economics\n Content Moderation Working Group 2023 Events - Working Group","tokens":433,"squid":"spider-03","role":"Compute Spider","at":1791344110614,"hash":"017e6345451b968af82ce28f189844393ddd3a4f"}
{"url":"https://developer.arbitrum.io/how-arbitrum-works/reference/geth","domain":"developer.arbitrum.io","title":"Geth at the core: modified Geth on Arbitrum Nitro","text":"Geth at the core: modified Geth on Arbitrum NitroLearn the fundamentals of Nitro, Arbitrum stack.Request an updateArbitrum Nitro makes minimal modifications to 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 direct state changes to ArbOS would get discarded upon a revert.\n0xA4B05FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF is a fictional account representing ArbOS.\nNoteAny 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\n 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 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\nSource: nitro/arbstate/geth-hook.go#L47\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\nSource: nitro/arbos/tx_processor.go#L100\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 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\nSource: nitro/arbos/tx_processor.go#L354\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\nSource: nitro/arbos/tx_processor.go#L76\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\nSource: nitro/arbos/tx_processor.go#L617\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\nSource: nitro/arbos/tx_processor.go#L425\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\nSource: nitro/arbos/tx_processor.go#L418\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\nSource: nitro/arbos/tx_processor.go#L429\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\nSource: nitro/arbos/tx_processor.go#L960\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\nSource: go-ethereum/arbitrum/apibackend.go#L34\nAPIBackend implements the ethapi.Backend interface, which allows a simple integration of the to the existing Geth API. The Backend member answers most calls.\nBackend\nSource: go-ethereum/arbitrum/backend.go#L15\nThis struct is an Arbitrum equivalent to the Ethereum struct. It is mostly glue logic, including a pointer to the ArbInterface interface.\nArbInterface\nSource: go-ethereum/arbitrum/arbos_interface.go#L10\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\nSource: go-ethereum/arbitrum/recordingdb.go#L22\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\nSource: go-ethereum/core/types/arb_types.go#L43\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\nSource: go-ethereum/core/types/arb_types.go#L104\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 .\nArbitrumDepositTx\nSource: go-ethereum/core/types/arb_types.go#L338\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\nSource: go-ethereum/core/types/arb_types.go#L232\nIt represents a retryable submission and may schedule an ArbitrumRetryTx if enough gas is available. For more info, see the retryables documentation.\nArbitrumRetryTx\nSource: go-ethereum/core/types/arb_types.go#L161\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\nSource: nitro/arbos/internal_tx.go\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\nSource: nitro/arbos/internal_tx.go#L22\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 . 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 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.How is this guide?SequencerLearn the fundamentals of the Arbitrum Sequencer.Finality and reorgsHow finality works on Arbitrum chains, how and why a child chain can reorganize, how deep a reorg can go, and the confirmation levels an indexer should wait for before treating data as irreversible.","tokens":3825,"squid":"spider-01","role":"Chain Spider","at":1791344112124,"hash":"da6d520ee8fda8b94382db97cb509ad3eb50e15d"}
{"url":"https://forum.arbitrum.foundation/c/archive/archived-announcements/76","domain":"forum.arbitrum.foundation","title":"Latest Archive/Archived Announcements topics - Arbitrum","text":"The Arbitrum Foundation notified the Security Council on the need to perform a potential Emergency action. Following a review of the details and known risks, the Security Council decided to execute the upgrade and it was completed at 11:30 EST on 2nd October 2026.\nThis report provides an overview of the risks that required the Security Council Action:\n\nAdd a permissionless guard for the One-Step Proof of BoLD on Arbitrum One\n\nTemporarily pause activation of new Stylus contracts on Arbitrum One & Nova\n\nKey point: To date, known bugs for Stylus primarily impact chain liveness (e.g., denial of service attacks) and do not put any user funds at risk.\nWhy was this action taken\nLet’s take this opportunity to explain why action was taken on two separate issues concerning BoLD and Stylus.\nInstalling the guard for One-Step Proof of BoLD. Given the rise of AI-assisted attacks, we have implemented a precautionary approach that allows anyone to pause settlement of Arbitrum One on Ethereum if there are at least two conflicting answers that pass at the same level in which only one should be valid and pass. This is to halt a class of publicly verifiable and detectable attacks that exploit a bug in the one-step proof. If halted, Arbitrum One will continue to process as normal except that messages from Arbitrum One to Ethereum, such as withdrawals, that are not yet confirmed will have to wait. This provides time for the Security Council to deploy a fix for the bug and resume the rollup.\nPreventing activation of new Stylus contracts. AI-assisted tooling has led to an increasing number of sophisticated attacks on hand-crafted WASM programs that do not use the standard Stylus compiler toolchain. These programs are specifically designed to cause unexpected behaviors such as degrading the chain’s performance for all other users. To date, no attacks have been discovered that permits theft of user funds.\nNew ArbOS releases have patched several reported bugs and known attacks over the past few months, but out of an abundance of caution, we have decided to temporarily pause new activations of Stylus contracts. This was executed as an emergency action to prevent the deployment of new hand-crafted WASM programs that are not yet patched by the current version of ArbOS on the Arbitrum network.\nThe Arbitrum Foundation has informed the Security Council that they will work with the ArbitrumDAO to discuss next steps on the timeline and manner for enabling activation of new Stylus contracts. The Arbitrum community remains confident in the value of Stylus and want to preserve these use cases while taking preventative measures against Stylus-based attack vectors as AI-assisted attack tooling continues to evolve.\nImpact on builders and users\n\nNo new activations. New Stylus contracts cannot be activated during the pause including new versions of existing applications that require activation.\n\nExisting contracts are not paused. Already-active Stylus contracts continue to execute until expiration. This pause does not deactivate them.\n\nThe ArbOS 61 upgrade renewed all active contracts on Arbitrum One, so no currently active contract expires before August 20, 2027.\n\nRenewal via keepalive stays permissionless and is unaffected by the pause.\n\nReactivating an expired contract, or one that needs to be updated after a Stylus version change, is paused.\n\nUsing/calling any activated Stylus contract stays permissionless for all users and developers.\n\nNo impact on EVM. Solidity (EVM) contract deployment and execution are unaffected by this Security Council action.\n\nSecurity Council Actions\nThere are two actions bundled into a single payload:\n\nOne-Step Proof Guard. The L1UpgradeExecutor gives a new pause contract (PauseExecutor) the ability to pause and nothing else. The new pause contract grants the guard (OspSoundnessGuard) PAUSER_ROLE to use it. Anyone can show the guard two conflicting answers to the same step of an open challenge. If the one-step proof accepts both, the guard has the pause contract put Arbitrum One’s settlement to Ethereum on hold.\n\nStylus deactivation. The Security Council called ArbOwner.setWasmActivationGas(2^64 - 1) to raise the Stylus activation gas requirement on Arbitrum One and Nova. This makes activation prohibitively expensive and effectively disables new activations. This is a configuration change and does not require an ArbOS upgrade.\n\nThe Security Council signed the following transactions to update the configuration:\n\nEthereum: Ethereum Transaction Hash: 0x30732bb7d2... | Etherscan\nArbitrum One:\nArbitrum One Transaction Hash: 0x9eb3a4be3b... | Arbitrum One\nArbitrum Nova:\nArbitrum Nova transaction 0x79e0fed470dff7a22059b108e3f8f42eddd2b580a6771594060c4e7326c5f984 | Blockscout\n\nAn external audit was conducted for the OSP Guard contracts. No audit is required for the Stylus deactivation as it is only updating a single parameter in the ArbOS configuration.\n\n Latest topics in Archived Announcements\n\n Archive\n\n Archived 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 The Arbitrum DAO Code of Conduct\n\n 0\n\n 273\n\n Jul 2025\n\n The Arbitrum DAO’s Procedures\n\n 0\n\n 306\n\n Jul 2025","tokens":1302,"squid":"spider-07","role":"Council Spider","at":1791344114451,"hash":"74f3b52f948046adb6beed8b661d68ea585bf04c"}
{"url":"https://akash.network/current-groups/wg-events/","domain":"akash.network","title":"2023 Events - Working Group - Community Groups","text":"Back\n Steering Committee Steering Committee Special Interest Groups Analytics Special Interest Group Chain Special Interest Group Clients Special Interest Group Community Special Interest Group Deployments Special Interest Group Design Special Interest Group Documentation Special Interest Group Economics Special Interest Group Education Providers Special Interest Group Support Special Interest Group Working Groups Akash Hackathon Working Group Akash Website Akash Youtube Client Libraries Working Group Content Moderation Working Group Economics 2.0 2023 Events - Working Group GPU Working Group Provider Attributes Working Group Provider Audit Working Group Testnets Working Group Zealy 2023 Events - Working Group This working group is to discuss events to attend, year by year, and ways to encourage community attendance. \nView on Discord\n\nView on GitHub\n\nSubscribe to Calendar\n Akash Network - Events - WG\nThis working group is to discuss events to attend, year by year, and ways to encourage community attendance.\nwg-events 2023 Meetings\n\nMeetingTimeNotesTranscriptRecording#1Friday, February 17, 2023 10:30 AM PT (Pacific Time)LinkLinkComing Soon#2Wednesday April 19, 2023 10:00 AM PT (Pacific Time)LinkLinkComing Soon\nwg-events 2024 Meetings\n\nMeetingTimeNotesTranscriptRecording#1Wednesday October 25, 2023 10:00 AM PT (Pacific Time)LinkLinkLink#2Friday November 03, 2023 10:00 AM PT (Pacific Time)Coming SoonComing SoonComing Soon\nwg-events 2025 Meetings\n\nMeetingTimeNotesTranscriptRecording#1Wednesday November 20, 2024 10:00 AM PT (Pacific Time)LinkLinkLink#2Wednesday January 29, 2025 10:00 AM PT (Pacific Time)LinkLinkLink#3Wednesday March 27, 2025 10:00 AM PT (Pacific Time)LinkLinkLink#4Wednesday APril 27, 2025 10:00 AM PT (Pacific Time)Coming SoonComing Soon#5Wednesday May 28, 2025 10:00 AM PT (Pacific Time)LinkLinkLink#6Wednesday October 10, 2025 10:00 AM PT (Pacific Time)LinkLinkLink\nLead\nAdam Wozney (Overclock Labs)\nContacts\n\nDiscord\n\nRelated SIGs\n\nsig-community\n Economics 2.0 GPU Working Group","tokens":506,"squid":"spider-03","role":"Compute Spider","at":1791344120381,"hash":"0dcb9f55a24f3da676973e58948d4c4d7cd15759"}
{"url":"https://forum.across.to/c/tokenomics/6","domain":"forum.across.to","title":"Latest Tokenomics (old) topics - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n Latest topics in Tokenomics (old)\n\n Tokenomics (old)\n\n tags\n\n Latest\n\n Top\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n posted\n Apr 28\n\n by @Kevin_UMA\n\n Across Token Launch Proposal v2\n\n This is a revised proposal that builds on the initial Across token launch proposal with added community feedback and implementation details. \nThe launch of an Across token will grow and unite the Across community, incent…\n\n read more\n\n KoCoinhunter1\n replied\n\n Nov 17, 2022\n\n 47\n\n 154\n\n posted\n Mar 18\n\n by @Kevin_UMA\n\n Across Token Launch Proposal\n\n The launch of an Across token will grow and unite the Across community, incentivize liquidity providers, increase awareness of Across, and further the mission of being the fastest and cheapest L2 bridge. This proposal ou…\n\n read more\n\n bciase\n replied\n\n May 9, 2022\n\n 214\n\n 325\n\n posted\n Mar 25\n\n by @10086\n\n 这个提议很好，希望社区也做越好\n\n Continuing the discussion from Across Token Launch Proposal:\n\n Monkey_M\n replied\n\n Apr 23, 2022\n\n 1\n\n posted\n Nov 12\n\n by @Kastormagic\n\n What the token does?\n\n As we discusse about airdrops and « who gets what », I think we should talk about what the token does. That’s why I launch this conversation. \nAn example : Across token gives you a fees reduction when you use the bridge,…\n\n read more\n\n Ray_V\n replied\n\n Apr 21, 2022\n\n 25\n\n 40\n\n posted\n Nov 9\n\n by @FortunateSon\n\n Initial thinking around token distribution\n\n Hi, I’m FS. Happy to break the ice on this category topic. I read the announcement post and listened to a little bit of the launch party. \nI read the conversation in Discord about tokenomics. Seems people are already thi…\n\n read more\n\n hakan5353\n replied\n\n Mar 21, 2022\n\n 36\n\n 74\n\n posted\n Nov 3\n\n by @Britt\n\n About the Tokenomics (old) category\n\n This category was used to discuss the tokenomics of the ACX token ahead of the token launch. It will remain open for reference until after the token has launched and will then be archived. \nAny future proposals around th…\n\n read more\n\n Monkey_M\n replied\n\n Mar 19, 2022\n\n 1\n\n 1","tokens":1999,"squid":"spider-09","role":"Bridge Spider","at":1791344126714,"hash":"3c574c51b240c3aa647863a374b5da94320165c7"}
{"url":"https://akash.network/current-groups/sig-clients/","domain":"akash.network","title":"Clients Special Interest Group - Community Groups","text":"Back\n Steering Committee Steering Committee Special Interest Groups Analytics Special Interest Group Chain Special Interest Group Clients Special Interest Group Community Special Interest Group Deployments Special Interest Group Design Special Interest Group Documentation Special Interest Group Economics Special Interest Group Education Providers Special Interest Group Support Special Interest Group Working Groups Akash Hackathon Working Group Akash Website Akash Youtube Client Libraries Working Group Content Moderation Working Group Economics 2.0 2023 Events - Working Group GPU Working Group Provider Attributes Working Group Provider Audit Working Group Testnets Working Group Zealy Clients Special Interest Group Akash Network Clients are software and services that make it easier for tenants of all types to deploy on to Akash Providers as well as for new provider onboarding. The Akash Network community has built and supports the following deployment & provider onboarding clients at this time \nView on Discord\n\nView on GitHub\n\nSubscribe to Calendar\n\nAkash Network - Clients Special Interest Group (SIG)\nAkash Network Clients are software and services that make it easier for tenants of all types to deploy on to Akash Providers as well as for new provider onboarding. The Akash Network community has built and supports the following deployment & provider onboarding clients at this time:\nDeployment Clients\n\nAkash Console\nAKash Command Line Interface\nClient Libraries (for various programming languages)\nCloudmos Deploy\nFleek\nTerraform Provider\n\nProvider Onboarding Clients\n\nAkash Command Line, with Helm Charts\nPraetor App\n\nThe goal of this SIG is to foster a community around each of these clients that is focused on building a roadmap for each client, capturing feedback from users, resolving issues and driving adoption of the clients. Each of these clients cater to specific Akash Network user segments and as such, drive the north star metric of driving deployemtns on Akash Network as a whole.\nMeetings\nMeetings happen every Third Wednesday of every other Month\n\nMeetingTimeNotesTranscriptRecording#1Wednesday, January 18, 2023 10:30 AM PT (Pacific Time)LinkLinkLink#2Wednesday, February 15, 2023 10:30 AM PT (Pacific Time)LinkLinkLink#3Wednesday, March 15, 2023 10:30 AM PT (Pacific Time)LinkLinkLink#4Wednesday, April 19, 2023 10:30 AM PT (Pacific Time)LinkLinkLink#5Wednesday, May 17, 2023 10:30 AM PT (Pacific Time)LinkLinkLink#6Wednesday, June 21, 2023 10:30 AM PT (Pacific Time)LinkLinkLink#7Wednesday, July 19, 2023 10:30 AM PT (Pacific Time)LinkLinkLink#8Wednesday, August 16, 2023 10:30 AM PT (Pacific Time)LinkLinkLink#9Wednesday, September 20, 2023 10:30 AM PT (Pacific Time)LinkLinkLink#10Wednesday, October 18, 2023 10:30 AM PT (Pacific Time)LinkLinkLink#11Monday, December 18th, 2023 08:30 AM PT (Pacific Time)LinkLinkLink#12Wednesday, January 17, 2024 10:30 AM PT (Pacific Time)LinkLinkLink#13Thursday, February 22nd, 2024 09:30 AM PT (Pacific Time)LinkLinkLink#14March 27th, 2024 09:00 AM PT (Pacific Time)LinkLinkComing Soon#15April 24th, 2024 09:00 AM PT (Pacific Time)LinkLinkLink#16June 25th, 2024 10:00 AM PT (Pacific Time)LinkLinkLink#17August 20th, 2024 10:30 AM PT (Pacific Time)LinkLinkLink#18November 13th, 2024 10:30 AM PT (Pacific Time)LinkLinkLink#19February 18, 2025 09:00 AM PT (Pacific Time)LinkLinkLink#20April 15, 2025 09:00 AM PT (Pacific Time)LinkLinkLink#21July 01, 2025 09:00 AM PT (Pacific Time)LinkLinkLink#22August 19, 2025 09:00 AM PT (Pacific Time)LinkLinkLink#23November 05, 2025 09:00 AM PT (Pacific Time)LinkLinkLink#24December 16, 2025 09:00 AM PT (Pacific Time)LinkLinkLink#25February 24, 2026 09:00 AM PT (Pacific Time)LinkLinkLink#26April 21, 2026 09:00 AM PT (Pacific Time)LinkLinkLink#27May, 2026 09:00 AM PT (Pacific Time)#28June, 2026 09:00 AM PT (Pacific Time)#29July, 2026 09:00 AM PT (Pacific Time)\nLeadership\nProduct Lead(s)\n\nAnil Murty, Overclock Labs (@anilmurty) - Akash Console\nGreg Osuri, Overclock Labs (@gosuri) - Akash CLI\nJoao Luna, Quasarch (@cloud-j-luna) - Terraform Provider, Client Libraries\nMaxime Beauchamp, Cloudmos (baktun14) - Akash Console\nJigar Patel, Praetor (jigar-arc10) - Akash Console\nDeval Patel, Praetor - Akash Console\n\nTech Lead(s)\n\nAdam Bozanich, Overclock Labs (@boz)\nJoao Luna, Quasarch (@cloud-j-luna)\nJoseph Tary, Overclock Labs (@jtary)\nMaxime Beauchamp, Cloudmos (baktun14)\nDeval Patel, Praetor (@deval_vora)\n\nProgram Manager(s)\n\nTyler Wright (@brewsterdrinkwater)\n\nContact\n\nDiscord Server\n\nSub Projects, Repositories & Relevant Work Groups\nThe following are projects and work-groups that sig-clients participates in or contributes to\n\nClient Libraries\n Chain Special Interest Group Community Special Interest Group","tokens":1183,"squid":"spider-03","role":"Compute Spider","at":1791344133756,"hash":"e0bfe04c3117a48e0fe6fc008b1f483eda49af75"}
{"url":"https://forum.arbitrum.foundation/t/community-guidelines/12807","domain":"forum.arbitrum.foundation","title":"Community Guidelines - Announcements - Arbitrum","text":"The Arbitrum Foundation notified the Security Council on the need to perform a potential Emergency action. Following a review of the details and known risks, the Security Council decided to execute the upgrade and it was completed at 11:30 EST on 2nd October 2026.\nThis report provides an overview of the risks that required the Security Council Action:\n\nAdd a permissionless guard for the One-Step Proof of BoLD on Arbitrum One\n\nTemporarily pause activation of new Stylus contracts on Arbitrum One & Nova\n\nKey point: To date, known bugs for Stylus primarily impact chain liveness (e.g., denial of service attacks) and do not put any user funds at risk.\nWhy was this action taken\nLet’s take this opportunity to explain why action was taken on two separate issues concerning BoLD and Stylus.\nInstalling the guard for One-Step Proof of BoLD. Given the rise of AI-assisted attacks, we have implemented a precautionary approach that allows anyone to pause settlement of Arbitrum One on Ethereum if there are at least two conflicting answers that pass at the same level in which only one should be valid and pass. This is to halt a class of publicly verifiable and detectable attacks that exploit a bug in the one-step proof. If halted, Arbitrum One will continue to process as normal except that messages from Arbitrum One to Ethereum, such as withdrawals, that are not yet confirmed will have to wait. This provides time for the Security Council to deploy a fix for the bug and resume the rollup.\nPreventing activation of new Stylus contracts. AI-assisted tooling has led to an increasing number of sophisticated attacks on hand-crafted WASM programs that do not use the standard Stylus compiler toolchain. These programs are specifically designed to cause unexpected behaviors such as degrading the chain’s performance for all other users. To date, no attacks have been discovered that permits theft of user funds.\nNew ArbOS releases have patched several reported bugs and known attacks over the past few months, but out of an abundance of caution, we have decided to temporarily pause new activations of Stylus contracts. This was executed as an emergency action to prevent the deployment of new hand-crafted WASM programs that are not yet patched by the current version of ArbOS on the Arbitrum network.\nThe Arbitrum Foundation has informed the Security Council that they will work with the ArbitrumDAO to discuss next steps on the timeline and manner for enabling activation of new Stylus contracts. The Arbitrum community remains confident in the value of Stylus and want to preserve these use cases while taking preventative measures against Stylus-based attack vectors as AI-assisted attack tooling continues to evolve.\nImpact on builders and users\n\nNo new activations. New Stylus contracts cannot be activated during the pause including new versions of existing applications that require activation.\n\nExisting contracts are not paused. Already-active Stylus contracts continue to execute until expiration. This pause does not deactivate them.\n\nThe ArbOS 61 upgrade renewed all active contracts on Arbitrum One, so no currently active contract expires before August 20, 2027.\n\nRenewal via keepalive stays permissionless and is unaffected by the pause.\n\nReactivating an expired contract, or one that needs to be updated after a Stylus version change, is paused.\n\nUsing/calling any activated Stylus contract stays permissionless for all users and developers.\n\nNo impact on EVM. Solidity (EVM) contract deployment and execution are unaffected by this Security Council action.\n\nSecurity Council Actions\nThere are two actions bundled into a single payload:\n\nOne-Step Proof Guard. The L1UpgradeExecutor gives a new pause contract (PauseExecutor) the ability to pause and nothing else. The new pause contract grants the guard (OspSoundnessGuard) PAUSER_ROLE to use it. Anyone can show the guard two conflicting answers to the same step of an open challenge. If the one-step proof accepts both, the guard has the pause contract put Arbitrum One’s settlement to Ethereum on hold.\n\nStylus deactivation. The Security Council called ArbOwner.setWasmActivationGas(2^64 - 1) to raise the Stylus activation gas requirement on Arbitrum One and Nova. This makes activation prohibitively expensive and effectively disables new activations. This is a configuration change and does not require an ArbOS upgrade.\n\nThe Security Council signed the following transactions to update the configuration:\n\nEthereum: Ethereum Transaction Hash: 0x30732bb7d2... | Etherscan\nArbitrum One:\nArbitrum One Transaction Hash: 0x9eb3a4be3b... | Arbitrum One\nArbitrum Nova:\nArbitrum Nova transaction 0x79e0fed470dff7a22059b108e3f8f42eddd2b580a6771594060c4e7326c5f984 | Blockscout\n\nAn external audit was conducted for the OSP Guard contracts. No audit is required for the Stylus deactivation as it is only updating a single parameter in the ArbOS configuration.\n\n Community Guidelines \n\n Announcements\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Apr 2023\n\n 1 / 4\n\n Apr 2023\n\n Apr 2023\n\n post by Arbitrum on Apr 1, 2023\n\n Arbitrum\n\n Welcome to the Forum!\nThis forum is dedicated to discussions and exchange of ideas related to governance.\nPlease read the following guidelines carefully to ensure a productive and respectful community.\nStay on topic: This forum is dedicated to discussions related to governance only. Please refrain from discussing unrelated topics. Off-topic or irrelevant posts may be removed by the moderators.\nBe respectful: Respect other forum members, their opinions, and their rights to express themselves. Do not use offensive or derogatory language, personal attacks, or hate speech.\nKeep it constructive: We encourage healthy and constructive debates that lead to learning and growth. However, we do not tolerate unproductive or malicious behavior.\nProvide evidence: Back up your claims and arguments with reliable sources and evidence. Unsupported opinions or rumors are not allowed.\nStay legal: Do not engage in activities that are illegal or violate the rights of others, including intellectual property rights.\nProtect your privacy: Do not share personal information about yourself or others, including email addresses, phone numbers, or social media handles.\nFollow the rules: Abide by the rules and guidelines set forth by the forum moderators. Failure to do so may result in disciplinary action, including temporary or permanent suspension from the forum.\nModeration: The forum moderators reserve the right to remove any posts or comments that violate these guidelines or are deemed inappropriate. Repeat offenders may be banned from the forum.\nRemember, the purpose of this forum is to foster productive and respectful discussions related to governance. We encourage everyone to contribute their ideas and perspectives, and to learn from each other.\n\n The ArbitrumDAO's Procedures\n\n Arbitrum Now: a pragmatic approach for the Moment\n\n Proposal to Backfund Successful STIP Proposals (Savvy DAO) [FINAL]\n\n Proposal: Experimental Incentive System for Active ArbitrumDAO Delegates\n\n Arbitrum Triple Dip (Delegate Incentive Program)\n\n Made this a banner on Apr 1, 2023. It will appear at the top of every page until it is dismissed by the user.\n\n Removed this banner on Apr 1, 2023. It will no longer appear at the top of every page.\n\n Pinned on Apr 1, 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 Welcome to Discourse\n\n General\n\n 41\n\n 21.7k\n\n Mar 22\n\n Create a Discord Category Channel for Governance\n\n Voting Rationale & Governance Calls\n\n community-engagement\n\n 13\n\n 1.8k\n\n Aug 2024\n\n Proposed Amendment to the Code of Conduct: AI tools and Responsible Participation Policy\n\n Finalized AIPs\n\n 4\n\n 123\n\n Jul 20\n\n 12 Mar 2024 - Open Discussion of Proposals Governance Call\n\n Biweekly Proposals Discussions Call\n\n governance,proposal-discussions\n\n 1\n\n 629\n\n Mar 2024\n\n Interest in a monthly governance call?\n\n Voting Rationale & Governance Calls\n\n community-engagement\n\n 34\n\n 3.4k\n\n Jul 2023","tokens":2018,"squid":"spider-07","role":"Council Spider","at":1791344136782,"hash":"49f07c00275e60aa08e6af3ad20f5e392d28a130"}
{"url":"https://forum.across.to/t/what-the-token-does/52","domain":"forum.across.to","title":"What the token does? - Tokenomics (old) - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n What the token does? \n\n Tokenomics (old)\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Nov 2021\n\n 1 / 26\n\n Nov 2021\n\n Apr 2022\n\n post by Kastormagic on Nov 12, 2021\n\n Kastormagic\n\n As we discusse about airdrops and « who gets what », I think we should talk about what the token does. That’s why I launch this conversation.\nAn example : Across token gives you a fees reduction when you use the bridge, xAcross (think xSushi) gives you voting power and a share of the fees.\nLet’s talk about it ! We want to hear you !\n\n 3\n\n 3\n\n 2\n\n 2\n\n read \n\n 4\n min\n\n post by heropunk.eth on Nov 17, 2021\n\n heropunk.eth\n\n AcrossIt is to build a DAO and become a community governance token, not to use it as gas, so I don’t agree with you, on the contrary AcrosdDAO, it will have more uses\n\n post by goldsnitch.eth on Nov 17, 2021\n\n goldsnitch.eth\n\n Need tokens to attract users\n\n post by fojo on Nov 17, 2021\n\n fojo\n\n Thanks for starting this discussion. To me this is the most important discussion to have with regards to tokenomics. There is no point in airdropping a token that does nothing. So first and foremost we should think about and decide on what the token will do.\nHere’s my 2 cents:\nGovernance: Establish a governance framework by granting discission making to across token holders (i.e. voting power)\nFees: Establish utility to the token (rather than it being just a governance token) by either giving fee reductions when using the bridge or a share of the fees generated by the bridge.\nSafety module: Staked across tokens will act as a collateral of last resort, to provide insurance against shortfall events. Stakers will get staking rewards. (see AAVE and DYDX for examples).\n\n post by DHACK on Nov 17, 2021\n\n post by Robot on Nov 17, 2021\n\n post by fommes.eth on Nov 17, 2021\n\n post by fommes.eth on Nov 17, 2021\n\n post by Robot on Nov 17, 2021\n\n post by Sanguine on Nov 17, 2021\n\n post by jotatotal on Nov 17, 2021\n\n post by fommes.eth on Nov 17, 2021\n\n post by Robot on Nov 17, 2021\n\n post by Solace on Nov 17, 2021\n\n post by Sanguine on Nov 17, 2021\n\n post by eqing.eth on Nov 21, 2021\n\n post by Alisa on Nov 22, 2021\n\n 9 days later\n\n post by MrHeviDi on Dec 1, 2021\n\n 2 months later\n\n post by jotatotal on Jan 26, 2022\n\n post by lawpanda.eth on Jan 26, 2022\n\n Load more posts below","tokens":2067,"squid":"spider-09","role":"Bridge Spider","at":1791344136830,"hash":"5a3c14f75672fc4cf8190472e9530c44e80672e1"}
{"url":"https://forum.across.to/t/what-the-token-does/52/3","domain":"forum.across.to","title":"What the token does? - Tokenomics (old) - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n Tokenomics (old)\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Nov 2021\n\n 3 / 26\n\n Nov 2021\n\n Apr 2022\n\n post by Kastormagic on Nov 12, 2021\n\n Kastormagic\n\n As we discusse about airdrops and « who gets what », I think we should talk about what the token does. That’s why I launch this conversation.\nAn example : Across token gives you a fees reduction when you use the bridge, xAcross (think xSushi) gives you voting power and a share of the fees.\nLet’s talk about it ! We want to hear you !\n\n 3\n\n 3\n\n 2\n\n 2\n\n read \n\n 4\n min\n\n post by heropunk.eth on Nov 17, 2021\n\n heropunk.eth\n\n AcrossIt is to build a DAO and become a community governance token, not to use it as gas, so I don’t agree with you, on the contrary AcrosdDAO, it will have more uses\n\n post by goldsnitch.eth on Nov 17, 2021\n\n goldsnitch.eth\n\n Need tokens to attract users\n\n post by fojo on Nov 17, 2021\n\n fojo\n\n Thanks for starting this discussion. To me this is the most important discussion to have with regards to tokenomics. There is no point in airdropping a token that does nothing. So first and foremost we should think about and decide on what the token will do.\nHere’s my 2 cents:\nGovernance: Establish a governance framework by granting discission making to across token holders (i.e. voting power)\nFees: Establish utility to the token (rather than it being just a governance token) by either giving fee reductions when using the bridge or a share of the fees generated by the bridge.\nSafety module: Staked across tokens will act as a collateral of last resort, to provide insurance against shortfall events. Stakers will get staking rewards. (see AAVE and DYDX for examples).\n\n post by DHACK on Nov 17, 2021\n\n DHACK\n\n Need tokens to attract users . I agree with it\n\n post by Robot on Nov 17, 2021\n\n Robot\n\n I think we should bump up the fees for using the bridge by a small % but if you stake X amount of the token then fees come back down to the original %, and if you stake even more you become eligible for profit share and all the usual stuff that comes with a govenunce token.\n\n post by fommes.eth on Nov 17, 2021\n\n fommes.eth\n\n Imho there is no point in holding the Across token for fees reduction. I imagine a tipical Across user will not bridge all the time, just looking at the general roadmap/POV that Eth mainnet is becoming solely/mostly just the settlement layer, already in the coming months ppl will use more frequent L2s and withdraw back sometimes.\n\n post by fommes.eth on Nov 17, 2021\n\n fommes.eth\n\n I propose the Across token to accrue fees for holders instead.\n\n post by Robot on Nov 17, 2021\n\n Robot\n\n fommes.eth\n\n Surely the more utility the better and i’m sure Across will have to go L2 to L2 in the end\n\n post by Sanguine on Nov 17, 2021\n\n Sanguine\n\n Kastormagic\n\n I think that token is needed for the DAO in the first place. It is not even necessary that it have economic value in the form of receiving % from commissions for the interaction of other users with the protocol. First of all, a token is a symbol. The more successful the project is, the more people want to be involved in it through the token.\n\n post by jotatotal on Nov 17, 2021\n\n jotatotal\n\n I would suggest that a part of the fees goes to the DAO treasury, and so increment value of DAO token. On the other hand I also consider that if the token is used to pay fees those fees get burned after that.\n\n post by fommes.eth on Nov 17, 2021\n\n fommes.eth\n\n Robot\n\n There are lots of L2 to L2 bridges already. Imho Across is unique in that sense and should aim to be the Go-To for fast+secure L1 withdrawals. There will always be a need for L1 withdrawals, even if Ethereum becomes mostly just an execution layer.\n\n post by Robot on Nov 17, 2021\n\n Robot\n\n Sanguine\n\n That’s not true go look at Ribbon finance and their token launch people bought and it non-stop gets called a useless govenunce token, Ribbon is very successful with about $200m TVL but the token price don’t reflect that\n\n post by Solace on Nov 17, 2021\n\n Solace\n\n Completely agree with /u/fojo’s post above - this is an important discussion regarding the token launch.\nWould the token be used strictly for governance, to pay out fees, or as a safety module? These do not necessarily have to mutually exclusive, and it’s possible that the token could incorporate all three - but as far as emission and distribution goes, it’s pretty important to make at least one a priority.\nIf choosing a governance route, liquidity incentives and a safety module could also be implemented at a later stage via a proposal. But this would remain subject to a vote, which could take some time to pass.\nOn the topic of liquidity incentives, these will likely remain temporary in order to bootstrap liquidity though there are plenty of examples of where artificially incentivizing usage has led to users with short-term outlooks farming these pools and draining the liquidity afterwards.\nAs far as using the token to incentivize usage goes, one approach could be to provide a gas fee rebate to users that bridge from L1 → L2 using the Arbitrum/optimism native bridge and bridge back to L1 using Across. This could be implemented similarly to Balancer’s gas fee rebate: [Proposal] Balancer Exchange Gas Reimbursement - Proposals - Balancer\nWe could get creative with some ways in order to incentivize usage rather than only incentivizing the LPs (as they will receive a fee of the transaction either way).\n\n post by Sanguine on Nov 17, 2021\n\n Sanguine\n\n Robot\n\n Maybe so. Indeed, in our time, the success of the project for the crowd is the endless rise in the price of the token. And if the price of a token does not grow infinitely, then they begin to call it “useless governance token”. But if the project starts to hype and the price rises, then it abruptly turns into an “incredibly useful governance token”.\n\n post by eqing.eth on Nov 21, 2021\n\n eqing.eth\n\n Kastormagic\n\n Tokens will attract some early users, which is necessary!At the initial stage of the project, it is necessary to attract users by token airdrop and distinguish real users.\n\n post by Alisa on Nov 22, 2021\n\n Alisa\n\n Acrosit is to establish a Dao and become a token of community governance. However, empowering and offsetting gas is a good suggestion, which can prevent members from throwing it out too early. However, it also has some disadvantages., if it is a gas, will it affect the development of community autonomy? But if it is only from the perspective of token, the more successful across is, the better the development of Dao will be, Of course, it will attract more people to participate\n\n 9 days later\n\n post by MrHeviDi on Dec 1, 2021\n\n MrHeviDi\n\n fommes.eth\n\n But there will be other protocals/bridges to move funds from L2 to L1, so Across needs to atract users to use Across and maybe to hold Across token. Maybe, like someone before montioned, having Across token will give you some fee reduction or something like that.\n\n 2 months later\n\n post by jotatotal on Jan 26, 2022\n\n jotatotal\n\n Solace\n\n What about giving the holders of the token , despite a fee reduction , a share of the fee according to their holdings?\n\n post by lawpanda.eth on Jan 26, 2022\n\n lawpanda.eth\n\n That would functionally be an ‘x’ token, like xSushi, dQuick, etc. On the legal end it creates regulatory questions because it resembles a security. But it is a more functional mechanism for facilitating adoption/use.\n\n Load more posts below","tokens":3349,"squid":"spider-09","role":"Bridge Spider","at":1791344158971,"hash":"2187d89f6e3150eefa46819860df963bcae10df4"}
{"url":"https://www.metaplex.com/docs/smart-contracts/core/json-schema","domain":"metaplex.com","title":"JSON Schema | Core","text":"The off-chain JSON metadata for Metaplex Core assets is similar to the Metaplex Token Metadata standard. However, since more data can be stored on-chain in the asset itself using plugins, some of the data like attributes can in addition be stored on chain.Schema ExamplesBelow are examples for the different known types of NFTs. It's important to note that all of these different types can also be part of a single Asset using the image, animation_url, and properties fields. All the different fields are further described in the JSON Schema Fields section.JSON Schema FieldsBelow explanations for the different fields can be found. If you miss some fields that you knew from Metaplex Token Metadata those are probably deprecated. The creators for example are part of the Royalties Plugin now.Required Fieldsname: The name of your NFT assetExample: \"Solana Monkey #123\", \"Degen Ape #45\"description: A detailed description of your NFTExample: \"A rare cosmic monkey floating through the Solana blockchain\"image: URI pointing to the primary image of your NFTExample: https://arweave.net/123abc...?ext=pngSupports: PNG, GIF, JPG/JPEGcategory: Type of NFT contentExamples: image, video, audio, vr, htmlOptional Fieldsanimation_url: URI for multimedia attachmentsExample: https://arweave.net/xyz789...?ext=mp4Supports: MP4, GIF, GLB, HTMLexternal_url: Link to an external website for the NFTExample: https://www.myproject.io/nft/123attributes: Array of traits and their values. These can alternatively be stored onchain using the Attributes PluginExample:{\n \"trait_type\": \"Background\",\n \"value\": \"Galaxy\"\n}\nproperties: Additional metadata including files and categoriesfiles: Array of all assets associated with the NFT. the type is the MIME type of the file.{\n \"uri\": \"https://arweave.net/abc123...?ext=png\",\n \"type\": \"image/png\"\n}","tokens":457,"squid":"dotcat","role":"Tooling Spider","at":1791344159498,"hash":"ed9be69ed17a80f9fd48c24c3548e4d1051106c8"}
{"url":"https://ethresear.ch/t/somewhat-time-critical-how-do-i-set-a-password/11074/7","domain":"ethresear.ch","title":"Somewhat time critical — How do I set a password? - Administrivia - Ethereum Research","text":"Administrivia\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 5\n\n 2\n\n Oct 2021\n\n 6 / 9\n\n Oct 2021\n\n Nov 2021\n\n post by x on Oct 22, 2021\n\n x\n\n This site required me to do OAuth to register. For privacy / data hygiene reasons I then removed my GitHub from this profile and de-authenticated the site in GitHub.\nNext I changed my GitHub email address and deleted the previous address. Finally I also generated a new email address for this site to then remove the final remaining link to GitHub.\nQuestion: How can I set a password on this site, such that I will be allowed to log in once my cookie expires? Can I just log in with the email that’s now in my profile, without a password?\n\n Ethresear.ch: email login will be disabled in 7 days\n\n 5\n\n 2\n\n post by hwwhww on Oct 22, 2021\n\n hwwhww\n\n Well, the main reason why we disallow email login is for mitigating spamming. GitHub account association also provides some reputation reference in R&D community. (And considering dogfooding Ethereum account login in the future)\nI don’t think you can set password now. If you want to hide your main email/GitHub info, you could register a new GitHub account for ethresear.ch.\nSorry it’s not perfect, but IMO it’s not good to enable email login in ethresear.ch.\n\n post by x on Oct 22, 2021\n\n x\n\n K … well the guys over at ethereum-magicians allow it. They also have 2FA \n\n post by pavloMandryk on Oct 22, 2021\n\n pavloMandryk\n\n Hi, this is my first reply, hope it can be helpful.\nAs @hwwhww mentioned, there is no way you can set a password; but you still can recover access to the profile after cookie expiration.\nThe way to proceed would be creating a new GitHub account for the newly set “primary email” in your forum profile. You can access your profile using those GitHub credentials. This way you didn’t need to create an extra profile and still succeed to remove any trace of your main GitHub account.\nTo achieve privacy when creating a ethresear.ch profile just use a fresh email with a fresh GitHub account.\n\n post by x on Oct 22, 2021\n\n x\n\n My session is still alive! Woohoo, clearly living on the edge here. Tbh, as some might have guessed, I didn’t really expect to receive a solution here. I just wanted to highlight that the current system seems inefficient.\nGiven how easy it is to create a separate GitHub account for registration here, what is the purpose of enforcing GitHub in the first place? If it’s for reputation purposes, then you shouldn’t be allowed to disassociate your GitHub again, and you should enforce a certain minimum GitHub account age or a certain minimum number of GitHub contributions.\nThe current system doesn’t protect us from anything. Instead, I only see negative outcomes:\n\nPeople who don’t want all their profiles across the Internet correlated are forced to go through the extra step of setting up a throwaway GitHub account (it takes time to set up and secure) — there is a reason why people set their GitHub email to private\nPeople who don’t have time to do that may need to unnecessarily sacrifice OpSec against their will\nPeople who don’t know yet what they want are by default directed into a non-privacy maximizing choice and the use of single-sign on is wrongly presented to them as a best practice (by a reputable community)\n\nGiven the increasing scrutiny from all sides, we should all try to become less traceable, not more traceable. At least, you should allow the people who care to minimize their attack surface.\n\n post by MicahZoltu on Oct 22, 2021\n\n MicahZoltu\n\n hwwhww\n\n Is the theory here to try to leverage GitHub’s spam protections? What is GitHub’s spam protection and can we just do that directly instead?\n\n post by pavloMandryk on Oct 22, 2021\n\n pavloMandryk\n\n These topics were discussed here alongside with the EAuth implementation.\n\n@hwwhww Are spamming and impersonator attacks the only reasons for disallowing email login? Did we have bad experiences with this before? How is ethereum-magicians managing these issues while allowing email login?\nI agree on maximizing non-traceability and would like to point out two more implications of the GitHub login only: UX and security.\nI believe that it is fair to say that a significant amount of potential users fall under a) don’t have an GitHub account or b) have a completely inactive GitHub account. For these users the lack of 2FA results on poor UX, of course, but also they are more likely to give up on security as they are probably less willing to set up and secure a GitHub account they don’t use.\nOn the other hand, in my personal experience as a GitHub user, the UX of the current system feels super smooth.\nThe advantages of having email login and GitHub auth would be:\n\nPrivacy for those who don’t want their profile to be associated with their GitHub.\nMore balanced UX.\n\nFor the current GitHub only system we have the following:\n\nLess privacy.\nA worst UX and security for non-GitHub-users.\nA better UX for GitHub users.\nProtection against spam and impersonator attacks.\n\nIs there a way to point to the GitHub account without using email as primary key? If this is non-trivial to make, we can’t enforce users to stick with one GitHub account since GitHub email can be changed.\n\nWhen it comes to EAuth implementation we are still facing the same privacy issues, as the idea would be enabling to sign up with ENS but requiring to associate a GitHub account with it. (Still excited about EAuth though!)\n\n post by x on Oct 22, 2021\n\n x\n\n If this is about impersonators, then the solution are cryptographic signatures, not some OAuth using some random website that some people don’t even feel comfortable using.\nYou could sign a message in your profile with GPG or you could even use an ETH key to sign it.\n\n 10 days later\n\n post by x on Nov 1, 2021\n\n x\n\n Hey friends — I can’t believe it, but I just came back after 10 days and my session is still live … ! Long live the cookies.\nSo, what did we end up with? Can this discussion be summarized as (not everyone thinks this! thank you for the constructive discussion so far):\n\nThe reason for GitHub auth is to avoid impersonation\nCryptographic signatures (OpenPGP, Minisign, ETH keys, …) would be a better solution than GitHub to verify identities/pseudonyms\nHowever, the target users of this forum don’t like using cryptographic signatures for this use case\nThus the people in this forum want to keep using GitHub to avoid impersonation\n(They don’t care that others may not like that; either because it links their accounts unnecessarily, or because they just don’t want to use GitHub)\n\n(There was more nuance, but I tried to dumb it down.)\nEDIT: By the way … thank you all for voting me “User of the Month” … I feel very honored.\nimage1038×272 29 KB\n\n Powered by Discourse","tokens":1687,"squid":"spider-04","role":"Research Spider","at":1791344168835,"hash":"f7d76ae74ec4b9ab7e91cf47266131f78480f01f"}
{"url":"https://forum.across.to/t/what-the-token-does/52/26","domain":"forum.across.to","title":"What the token does? - Tokenomics (old) - Across Protocol","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 read \n\n 4\n min\n\n Nov 2021\n\n 26 / 26\n\n Apr 2022\n\n Apr 2022\n\n Load more posts above\n\n post by fommes.eth on Nov 17, 2021\n\n fommes.eth\n\n Imho there is no point in holding the Across token for fees reduction. I imagine a tipical Across user will not bridge all the time, just looking at the general roadmap/POV that Eth mainnet is becoming solely/mostly just the settlement layer, already in the coming months ppl will use more frequent L2s and withdraw back sometimes.\n\n post by fommes.eth on Nov 17, 2021\n\n fommes.eth\n\n I propose the Across token to accrue fees for holders instead.\n\n post by Robot on Nov 17, 2021\n\n Robot\n\n fommes.eth\n\n Surely the more utility the better and i’m sure Across will have to go L2 to L2 in the end\n\n post by Sanguine on Nov 17, 2021\n\n Sanguine\n\n Kastormagic\n\n I think that token is needed for the DAO in the first place. It is not even necessary that it have economic value in the form of receiving % from commissions for the interaction of other users with the protocol. First of all, a token is a symbol. The more successful the project is, the more people want to be involved in it through the token.\n\n post by jotatotal on Nov 17, 2021\n\n jotatotal\n\n I would suggest that a part of the fees goes to the DAO treasury, and so increment value of DAO token. On the other hand I also consider that if the token is used to pay fees those fees get burned after that.\n\n post by fommes.eth on Nov 17, 2021\n\n fommes.eth\n\n Robot\n\n There are lots of L2 to L2 bridges already. Imho Across is unique in that sense and should aim to be the Go-To for fast+secure L1 withdrawals. There will always be a need for L1 withdrawals, even if Ethereum becomes mostly just an execution layer.\n\n post by Robot on Nov 17, 2021\n\n Robot\n\n Sanguine\n\n That’s not true go look at Ribbon finance and their token launch people bought and it non-stop gets called a useless govenunce token, Ribbon is very successful with about $200m TVL but the token price don’t reflect that\n\n post by Solace on Nov 17, 2021\n\n Solace\n\n Completely agree with /u/fojo’s post above - this is an important discussion regarding the token launch.\nWould the token be used strictly for governance, to pay out fees, or as a safety module? These do not necessarily have to mutually exclusive, and it’s possible that the token could incorporate all three - but as far as emission and distribution goes, it’s pretty important to make at least one a priority.\nIf choosing a governance route, liquidity incentives and a safety module could also be implemented at a later stage via a proposal. But this would remain subject to a vote, which could take some time to pass.\nOn the topic of liquidity incentives, these will likely remain temporary in order to bootstrap liquidity though there are plenty of examples of where artificially incentivizing usage has led to users with short-term outlooks farming these pools and draining the liquidity afterwards.\nAs far as using the token to incentivize usage goes, one approach could be to provide a gas fee rebate to users that bridge from L1 → L2 using the Arbitrum/optimism native bridge and bridge back to L1 using Across. This could be implemented similarly to Balancer’s gas fee rebate: [Proposal] Balancer Exchange Gas Reimbursement - Proposals - Balancer\nWe could get creative with some ways in order to incentivize usage rather than only incentivizing the LPs (as they will receive a fee of the transaction either way).\n\n post by Sanguine on Nov 17, 2021\n\n Sanguine\n\n Robot\n\n Maybe so. Indeed, in our time, the success of the project for the crowd is the endless rise in the price of the token. And if the price of a token does not grow infinitely, then they begin to call it “useless governance token”. But if the project starts to hype and the price rises, then it abruptly turns into an “incredibly useful governance token”.\n\n post by eqing.eth on Nov 21, 2021\n\n eqing.eth\n\n Kastormagic\n\n Tokens will attract some early users, which is necessary!At the initial stage of the project, it is necessary to attract users by token airdrop and distinguish real users.\n\n post by Alisa on Nov 22, 2021\n\n Alisa\n\n Acrosit is to establish a Dao and become a token of community governance. However, empowering and offsetting gas is a good suggestion, which can prevent members from throwing it out too early. However, it also has some disadvantages., if it is a gas, will it affect the development of community autonomy? But if it is only from the perspective of token, the more successful across is, the better the development of Dao will be, Of course, it will attract more people to participate\n\n 9 days later\n\n post by MrHeviDi on Dec 1, 2021\n\n MrHeviDi\n\n fommes.eth\n\n But there will be other protocals/bridges to move funds from L2 to L1, so Across needs to atract users to use Across and maybe to hold Across token. Maybe, like someone before montioned, having Across token will give you some fee reduction or something like that.\n\n 2 months later\n\n post by jotatotal on Jan 26, 2022\n\n jotatotal\n\n Solace\n\n What about giving the holders of the token , despite a fee reduction , a share of the fee according to their holdings?\n\n post by lawpanda.eth on Jan 26, 2022\n\n lawpanda.eth\n\n That would functionally be an ‘x’ token, like xSushi, dQuick, etc. On the legal end it creates regulatory questions because it resembles a security. But it is a more functional mechanism for facilitating adoption/use.\n\n 2 months later\n\n post by J.Berg on Mar 18, 2022\n\n J.Berg\n\n Creating a token enables the DAO to have an asset (without investing) that can be used to fund projects/guilds for effort the DAO needs (both maintenance and major initiatives), as well as contribute to internal DAO economics.\n–Paying core team members for their efforts\n–Paying for work done by Guilds and their squads\n–Internal DAO markets and trade\n–Bounties\nWill the Across token be used strictly for governance? or will it be used as money? or both?\nWould it be a monetary asset and a governance token to be used to fund and vote? Some DAO’s treat their governance token as ONLY that, and it actively drives down it’s valuation.\nIf its money then the DAO as an organization has the challenges of both a startup and an emerging digital nationstate in that we have to find and create revenue streams and manage costs, as well as drive the use and acceptance of our denomination both internally and externally.\nI think long term will be based on the size of the treasury it controls and the useful things you can do with it. As a result, I think the focus should be on activities that generate on-chain revenue for the DAO and ways to make the token useful stake it, collateral, ect.\nHow to pay contributors is definitely an important factor to consider. Without contributors, we won’t be able to do any of the above. Part of me feels that if your contributing, it should be because you believe in the DAO long term and shouldn’t expect an immediate monetary reward. The other part of me thinks that contributor renumeration is something that needs to be painstakingly thought out to retain talent and pay our people\n\n post by heybeo on Mar 22, 2022\n\n heybeo\n\n It would be nice to use bridges on the same platform as well as to create a nice dex.\nTrading pairs, for example acx-uma, are used as fees and distributed to token holders.\nacx-x\nacx-y\nacx-z\nJust a simple idea as liquidity addition commissions are burned\n\n post by altsilversurfer.nft on Mar 26, 2022\n\n altsilversurfer.nft\n\n Tokenomics can be viewed as a function of 3 main parameters, token launch (model, vesting scheme, market cap), utility, and inflation. Utility is one of the major drivers of adoption and appreciation of value. Thus, the more utilities, the best. Governance will be the first and more obvious utility of $ACX, but we must think beyond this to achieve sustainnability. This is the ultimate goal. And this is also the common interest of all involved. People that are waiting for profits will be maximally rewarded if they be patient and contribute to protocol sustainnability. Across will be really BIG and this is not a fanboy statement. The major crosschain pipes will see in the future typical value movements that will far exceed those of the biggest centralized exchanges today.\n\n post by jeffrey on Mar 29, 2022\n\n jeffrey\n\n Token is share, it means users own the project\n\n 12 days later\n\n post by hescollazo on Apr 11, 2022\n\n hescollazo\n\n I agree with the use of the token as a payment mechanism for the protocol. The low fees will bring new users and money into the ecosystem. That it can be used in governance will incentivize use of the application and hodling of the asset. Ultimately the goal should be to give users the tools to discover new ways in which to generate positive cash flow and build wealth.\n\n 10 days later\n\n post by Ray_V on Apr 21, 2022\n\n Ray_V\n\n Would we introduce a single staking mechanism? In which we would offer our tokens as liquidity to the across protocol and earn APR either through the fees accrued by the protocol - or another more effective system? Would that be something considered?\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Initial thinking around token distribution\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 36\n\n Mar 2022\n\n Across Token Launch Proposal\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 214\n\n May 2022\n\n Across Token Launch Proposal v2\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 47\n\n Nov 2022\n\n Second ACX Drop\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 15\n\n Feb 2024\n\n Welcome to Across\n\n WELCOME 👋\n\n WELCOME 👋\n\n Nov 2022","tokens":2413,"squid":"spider-09","role":"Bridge Spider","at":1791344169285,"hash":"e224083b7becf8de1126d9a2747b437871c85cd2"}
{"url":"https://www.metaplex.com/docs/smart-contracts/core","domain":"metaplex.com","title":"Metaplex Core | Next-Gen NFT Standard for Solana","text":"Metaplex Core (\"Core\") is the next-generation NFT standard on Solana. It uses a single-account design that reduces minting costs by 80%+ compared to alternatives, while providing enforced royalties, collection-level operations, and a flexible plugin system for custom behaviors. What You'll LearnThis overview covers:What Metaplex Core is and why it existsKey advantages over Token Metadata and other standardsCore concepts: Assets, Collections, and PluginsHow to get started building with CoreSummaryMetaplex Core is a Solana NFT standard that replaces Token Metadata for most new projects. It offers the lowest minting costs, enforced royalties, and a plugin architecture for custom functionality.Single-account design: ~0.003 SOL per mint (vs 0.022 SOL for Token Metadata)Enforced royalties by default with allowlist/denylist controlsPlugin system for staking, attributes, delegates, and custom behaviorsCollection-level operations: freeze, update royalties, or modify all assets at onceOut of ScopeThis overview does not cover: fungible tokens (use SPL Token), Token Metadata migration paths, or detailed plugin implementation. See specific pages for those topics.Quick StartJump to: Getting Started · Key Advantages · FAQ · GlossaryInstall the SDK: npm install @metaplex-foundation/mpl-coreCreate an Asset: Creating Assets guideAdd plugins: Plugins overviewQuery with DAS: Fetching AssetsGetting StartedFind the language or library of your choice and get started with digital assets on Solana.API ReferenceLooking for something specific? Check our API References.Differences from Token MetadataComing from Token Metadata? See what's changed and what's new.Try Core in a UIMint a Core Asset yourself using our web interface.IntroductionMetaplex Core is the recommended NFT standard for new projects on Solana. Compared to Token Metadata and other standards, Core provides:Cost EfficiencyStandardMint CostCompute UnitsMetaplex Core~0.003 SOL~17,000 CUToken Metadata~0.022 SOL~205,000 CUToken Extensions~0.0046 SOL~85,000 CUKey AdvantagesSingle Account Design: Core uses one account per asset instead of multiple (mint + metadata + token account). This reduces costs and simplifies development.Enforced Royalties: The Royalties plugin enforces creator royalties by default with allowlist/denylist controls.Collection-Level Operations: Update royalties, freeze assets, or modify metadata for an entire collection in a single transaction.Plugin Architecture: Add custom behaviors to assets via plugins:Freeze Delegate - Allow others to freeze/unfreezeBurn Delegate - Allow others to burnAttributes - On-chain key/value data (auto-indexed by DAS)Transfer Delegate - Allow others to transferAnd many more in the Plugins sectionDAS Indexing: All major RPC providers supporting DAS already index Core assets.Core ConceptsAssetsAn Asset is a single on-chain account representing an NFT. Unlike Token Metadata (which uses 3+ accounts), Core Assets contain ownership, metadata URI, and plugin data in one account. See: What is an Asset?CollectionsA Collection is a Core account that groups related Assets. Collections can have their own plugins that apply to all member Assets. Collection-level royalties, for example, apply to every Asset in the collection unless overridden.Groups (GroupV1) are a separate taxonomy layer that can organize collections, standalone assets, and nested groups. See Core Groups for when to use groups vs collections. See: CollectionsPluginsPlugins are modular extensions that add behavior to Assets or Collections. They hook into lifecycle events (create, transfer, burn) to enforce rules or store data. See: Plugins OverviewQuick ReferenceProgram IDsProgramAddressMPL CoreCoREENxT6tW1HoK8ypY1SxRMZTcVPm7R94rH4PZNhX7dMPL Core (Devnet)CoREENxT6tW1HoK8ypY1SxRMZTcVPm7R94rH4PZNhX7dSDK PackagesLanguagePackageJavaScript/TypeScript@metaplex-foundation/mpl-coreRustmpl-coreNext StepsChoose your SDK: Visit Getting Started to install the JavaScript or Rust SDKCreate your first Asset: Follow the Creating Assets guideExplore plugins: See available behaviors in PluginsMigrate from Token Metadata: Review Differences from Token MetadataPlease note that certain Core instructions require protocol fees. Review the Protocol Fees page for current information.FAQWhat is Metaplex Core?Metaplex Core is a next-generation NFT standard on Solana that uses a single-account design for lower costs, enforced royalties, and a flexible plugin system. It's the recommended standard for new NFT projects.How is Core different from Token Metadata?Core uses one account per asset (vs 3+ for Token Metadata), costs ~80% less to mint, has lower compute usage, and includes built-in royalty enforcement. Token Metadata is considered legacy for new projects. See Differences from Token Metadata for a detailed comparison.Can I migrate from Token Metadata to Core?Core Assets and Token Metadata NFTs are separate standards. There's no automatic migration. New projects should use Core; existing Token Metadata collections continue to work.Does Core support royalties?Yes. Core has a Royalties plugin that enforces royalties by default. You can set basis points, creator splits, and allowlist/denylist rules for marketplaces.What are plugins?Plugins are modular extensions that add behavior to Core Assets or Collections. Examples include Freeze Delegate (allow freezing), Attributes (on-chain data), and Royalties (creator payments).How much does it cost to mint a Core Asset?Approximately 0.003 SOL per base asset, compared to ~0.022 SOL for Token Metadata. This makes Core ~80% cheaper for minting. See Differences from Token Metadata for more details.Which RPC providers support Core?All major RPC providers supporting DAS (Digital Asset Standard) index Core assets. See RPC Providers for a current list.Can I use Core for gaming assets?Yes. Core's plugin system makes it ideal for gaming: use Attributes for on-chain stats, Freeze Delegate for locking items, and Transfer Delegate for marketplace integration.GlossaryTermDefinitionAssetA single Core on-chain account representing an NFT with ownership, metadata, and pluginsCollectionA Core account that groups related Assets and can apply collection-wide pluginsPluginA modular extension that adds behavior to Assets or Collections (royalties, freeze, attributes)DASDigital Asset Standard - the API specification for querying indexed NFT dataBasis PointsRoyalty percentage in hundredths of a percent (500 = 5%)DelegateAn account authorized to perform specific actions on an Asset without owning itCPICross-Program Invocation - calling the Core program from another Solana programURIThe off-chain metadata URL pointing to a JSON file with name, image, and attributesAsset Signer PDAA separate address derived from an Asset that acts as the Asset's wallet","tokens":1701,"squid":"dotcat","role":"Tooling Spider","at":1791344169381,"hash":"96b18052885f6a4e473ee64c54cac715ba52f3b2"}
{"url":"https://ethresear.ch/t/somewhat-time-critical-how-do-i-set-a-password/11074/10","domain":"ethresear.ch","title":"Somewhat time critical — How do I set a password? - Administrivia - Ethereum Research","text":"Administrivia\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 5\n\n 2\n\n Oct 2021\n\n 9 / 9\n\n Nov 2021\n\n Nov 2021\n\n post by x on Oct 22, 2021\n\n x\n\n This site required me to do OAuth to register. For privacy / data hygiene reasons I then removed my GitHub from this profile and de-authenticated the site in GitHub.\nNext I changed my GitHub email address and deleted the previous address. Finally I also generated a new email address for this site to then remove the final remaining link to GitHub.\nQuestion: How can I set a password on this site, such that I will be allowed to log in once my cookie expires? Can I just log in with the email that’s now in my profile, without a password?\n\n Ethresear.ch: email login will be disabled in 7 days\n\n 5\n\n 2\n\n post by hwwhww on Oct 22, 2021\n\n hwwhww\n\n Well, the main reason why we disallow email login is for mitigating spamming. GitHub account association also provides some reputation reference in R&D community. (And considering dogfooding Ethereum account login in the future)\nI don’t think you can set password now. If you want to hide your main email/GitHub info, you could register a new GitHub account for ethresear.ch.\nSorry it’s not perfect, but IMO it’s not good to enable email login in ethresear.ch.\n\n post by x on Oct 22, 2021\n\n x\n\n K … well the guys over at ethereum-magicians allow it. They also have 2FA \n\n post by pavloMandryk on Oct 22, 2021\n\n pavloMandryk\n\n Hi, this is my first reply, hope it can be helpful.\nAs @hwwhww mentioned, there is no way you can set a password; but you still can recover access to the profile after cookie expiration.\nThe way to proceed would be creating a new GitHub account for the newly set “primary email” in your forum profile. You can access your profile using those GitHub credentials. This way you didn’t need to create an extra profile and still succeed to remove any trace of your main GitHub account.\nTo achieve privacy when creating a ethresear.ch profile just use a fresh email with a fresh GitHub account.\n\n post by x on Oct 22, 2021\n\n x\n\n My session is still alive! Woohoo, clearly living on the edge here. Tbh, as some might have guessed, I didn’t really expect to receive a solution here. I just wanted to highlight that the current system seems inefficient.\nGiven how easy it is to create a separate GitHub account for registration here, what is the purpose of enforcing GitHub in the first place? If it’s for reputation purposes, then you shouldn’t be allowed to disassociate your GitHub again, and you should enforce a certain minimum GitHub account age or a certain minimum number of GitHub contributions.\nThe current system doesn’t protect us from anything. Instead, I only see negative outcomes:\n\nPeople who don’t want all their profiles across the Internet correlated are forced to go through the extra step of setting up a throwaway GitHub account (it takes time to set up and secure) — there is a reason why people set their GitHub email to private\nPeople who don’t have time to do that may need to unnecessarily sacrifice OpSec against their will\nPeople who don’t know yet what they want are by default directed into a non-privacy maximizing choice and the use of single-sign on is wrongly presented to them as a best practice (by a reputable community)\n\nGiven the increasing scrutiny from all sides, we should all try to become less traceable, not more traceable. At least, you should allow the people who care to minimize their attack surface.\n\n post by MicahZoltu on Oct 22, 2021\n\n MicahZoltu\n\n hwwhww\n\n Is the theory here to try to leverage GitHub’s spam protections? What is GitHub’s spam protection and can we just do that directly instead?\n\n post by pavloMandryk on Oct 22, 2021\n\n pavloMandryk\n\n These topics were discussed here alongside with the EAuth implementation.\n\n@hwwhww Are spamming and impersonator attacks the only reasons for disallowing email login? Did we have bad experiences with this before? How is ethereum-magicians managing these issues while allowing email login?\nI agree on maximizing non-traceability and would like to point out two more implications of the GitHub login only: UX and security.\nI believe that it is fair to say that a significant amount of potential users fall under a) don’t have an GitHub account or b) have a completely inactive GitHub account. For these users the lack of 2FA results on poor UX, of course, but also they are more likely to give up on security as they are probably less willing to set up and secure a GitHub account they don’t use.\nOn the other hand, in my personal experience as a GitHub user, the UX of the current system feels super smooth.\nThe advantages of having email login and GitHub auth would be:\n\nPrivacy for those who don’t want their profile to be associated with their GitHub.\nMore balanced UX.\n\nFor the current GitHub only system we have the following:\n\nLess privacy.\nA worst UX and security for non-GitHub-users.\nA better UX for GitHub users.\nProtection against spam and impersonator attacks.\n\nIs there a way to point to the GitHub account without using email as primary key? If this is non-trivial to make, we can’t enforce users to stick with one GitHub account since GitHub email can be changed.\n\nWhen it comes to EAuth implementation we are still facing the same privacy issues, as the idea would be enabling to sign up with ENS but requiring to associate a GitHub account with it. (Still excited about EAuth though!)\n\n post by x on Oct 22, 2021\n\n x\n\n If this is about impersonators, then the solution are cryptographic signatures, not some OAuth using some random website that some people don’t even feel comfortable using.\nYou could sign a message in your profile with GPG or you could even use an ETH key to sign it.\n\n 10 days later\n\n post by x on Nov 1, 2021\n\n x\n\n Hey friends — I can’t believe it, but I just came back after 10 days and my session is still live … ! Long live the cookies.\nSo, what did we end up with? Can this discussion be summarized as (not everyone thinks this! thank you for the constructive discussion so far):\n\nThe reason for GitHub auth is to avoid impersonation\nCryptographic signatures (OpenPGP, Minisign, ETH keys, …) would be a better solution than GitHub to verify identities/pseudonyms\nHowever, the target users of this forum don’t like using cryptographic signatures for this use case\nThus the people in this forum want to keep using GitHub to avoid impersonation\n(They don’t care that others may not like that; either because it links their accounts unnecessarily, or because they just don’t want to use GitHub)\n\n(There was more nuance, but I tried to dumb it down.)\nEDIT: By the way … thank you all for voting me “User of the Month” … I feel very honored.\nimage1038×272 29 KB\n\n Powered by Discourse","tokens":1687,"squid":"spider-04","role":"Research Spider","at":1791344178994,"hash":"1769204c8d6776dfeec2b8f8143b3be7261a027e"}
{"url":"https://www.metaplex.com/docs/smart-contracts/core/using-core-in-anchor","domain":"metaplex.com","title":"Using Metaplex Core in Anchor | Metaplex Core","text":"Build on-chain programs that interact with Core Assets using Anchor. This guide covers installation, account deserialization, plugin access, and CPI patterns. What You'll LearnInstall and configure mpl-core in Anchor projectsDeserialize Core Assets and Collections in your programsAccess plugin data (Attributes, Freeze, etc.)Make CPI calls to create, transfer, and manage AssetsSummaryThe mpl-core Rust crate provides everything needed to interact with Core from Anchor programs. Enable the anchor feature flag for native Anchor account deserialization.Add mpl-core with default-features = false and the appropriate Anchor featuresUse features = [\"anchor\", \"anchor-0-32\"] with anchor-lang 0.32.xUse features = [\"anchor\"] with anchor-lang 0.31.xDeserialize Assets/Collections in Accounts structsUse fetch_plugin() to read plugin dataCPI builders simplify instruction callsOut of ScopeClient-side JavaScript SDK (see JavaScript SDK), standalone Rust clients (see Rust SDK), and creating Core Assets from clients.Quick StartJump to: Installation · Account Deserialization · Plugin Access · CPI ExamplesAdd mpl-core with default-features = false and Anchor features to Cargo.tomlPin Rust 1.89.0 or newer in rust-toolchain.tomlDeserialize Assets with Account<'info, BaseAssetV1>Access plugins with fetch_plugin::<BaseAssetV1, PluginType>()Make CPI calls with CreateV2CpiBuilder, TransferV1CpiBuilder, etc.InstallationAdd mpl-core to your Anchor program's Cargo.toml. The default borsh-v1 feature is incompatible with Anchor integration, so always disable default features when enabling anchor.Feature FlagsFeatureDescriptionanchorEnables Anchor account deserialization using anchor-lang 0.31.1 and Solana 2.x typesanchor-0-32Opt-in support for anchor-lang 0.32.x; requires anchorserdeOptional serde support for off-chain toolingAnchor 0.32.x (recommended)Use this when your program depends on anchor-lang 0.32.x:[dependencies]\nanchor-lang = \"0.32.1\"\nmpl-core = { version = \"x.x.x\", default-features = false, features = [\"anchor\", \"anchor-0-32\"] }\nAnchor 0.31.x (legacy)Use this when your program depends on anchor-lang 0.31.x:[dependencies]\nanchor-lang = \"0.31.1\"\nmpl-core = { version = \"x.x.x\", default-features = false, features = [\"anchor\"] }\nImportantanchor-0-32 alone is not enough — it must be combined with anchor.default-features = false is required. Without it, the default borsh-v1 feature conflicts with Anchor integration.The Anchor path uses Solana 2.x types for Pubkey, AccountInfo, and related Anchor traits.Rust Toolchainmpl-core requires Rust 1.89.0 or newer. Add a rust-toolchain.toml file to your Anchor workspace:[toolchain]\nchannel = \"1.89.0\"\nIf your build fails with an edition2024 error from transitive dependencies such as base64ct, upgrade to Rust 1.89.0 or newer.Core Rust SDK ModulesThe Core Rust SDK is organized into several modules:accounts: represents the program's accounts.errors: enumerates the program's errors.instructions: facilitates the creation of instructions, instruction arguments, and CPI instructions.types: represents types used by the program. For more detailed information on how different instructions are called and used, refer to the mpl-core docs.rs website or you can use cmd + left click (mac) or ctrl + left click (windows) on the instruction to expand it.Accounts DeserializationDeserializable AccountsThe following account structs are available for deserialization within the mpl-core crate:- BaseAssetV1\n- BaseCollectionV1\n- HashedAssetV1\n- PluginHeaderV1\n- PluginRegistryV1\nThere are two ways to deserialize Core accounts within Anchor.Using Anchors Account list struct (recommended in most cases),Directly in the instruction functions body using <Account>::from_bytes().Anchor Accounts List MethodBy activating the anchor flag you'll be able to deserialize both the BaseAssetV1 and BaseCollectionV1 accounts directly in the Anchor Accounts list struct:Accounts Deserialization#[derive(Accounts)]\npub struct ExampleAccountStruct<'info> {\n ...\n pub asset: Account<'info, BaseAssetV1>,\n}\nAccount from_bytes() MethodBorrow the data inside the asset/collection account using the try_borrow_data() function and create the asset/collection struct from those bytes:Accounts Deserializationlet data = ctx.accounts.asset.try_borrow_data()?;\nlet base_asset: BaseAssetV1 = BaseAssetV1::from_bytes(&data.as_ref())?;\nDeserializing PluginsTo access individual plugins within an Asset or Collection account, use the fetch_plugin() function. This function will either return the plugin data or a null response without throwing an hard error, allowing you to check if a plugin exists without having to access its data. The fetch_plugin() function is used for both Assets and Collections accounts and can handle every plugin type by specifying the appropriate typing. If you want to access the data inside a plugin, use the middle value returned by this function.Plugins Deserializationlet (_, attribute_list, _) = fetch_plugin::<BaseAssetV1, Attributes>(&ctx.accounts.asset.to_account_info(), mpl_core::types::PluginType::Attributes)?;\nNote: The fetch_plugin() function is only used for non-external plugins. To read external plugins, use the fetch_external_plugin() function, which operates in the same way as fetch_plugin().The CPI Instruction BuildersEach instruction from the Core crate comes with a CpiBuilder version. The CpiBuilder version is created using name of the instruction + CpiBuilder and simplifies the code significantly abstracting a lot of boilerplate code away! If you want to learn more about all the possible instruction available in Core, you can find them on the mpl-core docs.rs websiteCPI ExampleLet's take the CreateCollectionV2CpiBuilder instruction as an example Initialize the builder by calling new on the CpiBuilder and passing in the core program as AccountInfo:CreateCollectionV2CpiBuilder::new(ctx.accounts.mpl_core_program.to_account_info);\nUse then Cmd + left click (Ctrl + left click for Windows users) to view all the CPI arguments required for this CPI call:CreateCollectionV2CpiBuilder::new(&ctx.accounts.core_program)\n .collection(&ctx.accounts.collection)\n .payer(&ctx.accounts.payer)\n .system_program(&ctx.accounts.system_program)\n .name(\"Test Collection\".to_string())\n .uri(\"https://test.com\".to_string())\n .invoke()?;\nCommon ErrorsAccountNotInitializedThe Asset or Collection account doesn't exist or hasn't been created yet.PluginNotFoundThe plugin you're trying to fetch doesn't exist on the Asset. Check with fetch_plugin() which returns None safely.InvalidAuthorityThe signer doesn't have permission for this operation. Verify the correct authority is signing.NotesAlways set default-features = false when enabling Anchor featuresUse features = [\"anchor\", \"anchor-0-32\"] with anchor-lang 0.32.xUse features = [\"anchor\"] with anchor-lang 0.31.xPin Rust 1.89.0 or newer in rust-toolchain.tomlUse fetch_plugin() for built-in plugins, fetch_external_plugin() for externalCPI builders abstract away account ordering complexityCheck docs.rs/mpl-core for complete API referenceQuick ReferenceCommon CPI BuildersOperationCPI BuilderCreate AssetCreateV2CpiBuilderCreate CollectionCreateCollectionV2CpiBuilderTransfer AssetTransferV1CpiBuilderBurn AssetBurnV1CpiBuilderUpdate AssetUpdateV1CpiBuilderAdd PluginAddPluginV1CpiBuilderUpdate PluginUpdatePluginV1CpiBuilderAccount TypesAccountStructAssetBaseAssetV1CollectionBaseCollectionV1Hashed AssetHashedAssetV1Plugin HeaderPluginHeaderV1Plugin RegistryPluginRegistryV1FAQDo I need the anchor feature flag?Yes, for direct deserialization in Accounts structs. Without it, use from_bytes() manually. Always set default-features = false when enabling anchor.Which Anchor version should I use?For anchor-lang 0.32.x, use default-features = false with features = [\"anchor\", \"anchor-0-32\"]. For anchor-lang 0.31.x, use features = [\"anchor\"] only.What Rust version is required?mpl-core requires Rust 1.89.0 or newer. Pin it in rust-toolchain.toml in your Anchor project.How do I check if a plugin exists?Use fetch_plugin() which returns Option - it won't throw an error if the plugin doesn't exist.Can I access external plugins (Oracle, AppData)?Yes. Use fetch_external_plugin() instead of fetch_plugin() with the appropriate key.Where can I find all available instructions?See the mpl-core docs.rs instructions module.GlossaryTermDefinitionCPICross-Program Invocation - calling one program from anotherCpiBuilderHelper struct for constructing CPI callsBaseAssetV1Core Asset account struct for deserializationfetch_plugin()Function to read plugin data from accountsanchor featureCargo feature enabling Anchor-native deserializationanchor-0-32 featureOpt-in Cargo feature for anchor-lang 0.32.x supportRelated PagesAnchor Staking Example - Complete staking programCreate Asset with Anchor - Step-by-step guideRust SDK - Standalone Rust client usagempl-core docs.rs - Complete API reference","tokens":2227,"squid":"dotcat","role":"Tooling Spider","at":1791344179251,"hash":"c798e9a68697c0827377e66c85a08c49644d0602"}
{"url":"https://forum.across.to/t/initial-thinking-around-token-distribution/38","domain":"forum.across.to","title":"Initial thinking around token distribution - Tokenomics (old) - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n Initial thinking around token distribution \n\n Tokenomics (old)\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Nov 2021\n\n 1 / 37\n\n Nov 2021\n\n Mar 2022\n\n post by FortunateSon on Nov 9, 2021\n\n FortunateSon\n\n Hi, I’m FS. Happy to break the ice on this category topic. I read the announcement post and listened to a little bit of the launch party.\nI read the conversation in Discord about tokenomics. Seems people are already thinking through how a token might function for Across, how a distribution could work, and so forth. I’m finding it hard to follow or feel organized so I wanted to start out over here.\nI wanted to raise some very preliminary points around what purpose a token can serve in the future of Across. The way I’d like to start is by asking what things we think Across needs to succeed, and which of those a token can help with. I’m sure this isn’t the only starting point, but I’d personally find it useful.\nI googled “main parts of a company” to find this short list:\nstrategy,\nmarketing,\nfinance,\nhuman resources,\ntechnology and equipment,\nand operations.\nSeems a token would be needed for almost all of these because there’s no other coordination tool. This would make it a DAO, which seems like the obvious way forward.\nSo we could progress by looking at those six categories above and asking how a token needs to be distributed to help achieve each. I think the biggest concern is making sure there are engineers.\nI also wonder about something else, which is co-founders. Startsups typically have cofounders, but DAOs don’t - do we expect to have dedicated leaders with big shares of tokens?\n\n 3\n\n 2\n\n read \n\n 4\n min\n\n post by 7revenant on Nov 11, 2021\n\n 7revenant\n\n I think you have to give a large number of tokens to “leaders” otherwise how will they be alligned with long term growth (vested ofcourse)\n\n post by motif on Nov 12, 2021\n\n motif\n\n Do we have any existing token models in other ecosystems that we like?\nI quite like Sushi’s system.\n\n post by Kastormagic on Nov 12, 2021\n\n Kastormagic\n\n I agree with you. Sushi is a nice model.\n\n post by Mohammedt75 on Nov 16, 2021\n\n Mohammedt75\n\n I cannot agree more. Sushi has a great model\n\n post by Trophycase on Nov 16, 2021\n\n Trophycase\n\n motif\n\n What aspects of sushi’s system? The way it was initially distributed with vesting? The non-linear distribution schedule? xSUSHI?\n\n post by Willis on Nov 16, 2021\n\n Willis\n\n That’s a great idea. I agree with you\n\n post by dillon on Nov 16, 2021\n\n dillon\n\n can’t agree more. maybe curve way, the longer you lock, the more bonus rewards you will get. in addition, the weighted voting power depends on the time you choose to lock. It seems a sustainable way\n\n post by TheRealTuna_Across on Nov 16, 2021\n\n TheRealTuna_Across\n\n Hopefully we can find ways to reward those who are in it for the longterm and not going to dump tokens as soon as they get their hands on them. It would be cool to have an initial drop followed by a few rounds of KPI options to reward the most loyal.\n\n post by Theshyless on Nov 16, 2021\n\n Theshyless\n\n I think it’s great to introduce this topic like that\n\n post by birchskin on Nov 17, 2021\n\n birchskin\n\n Sushi and Curve are mentioned above as models to go by - I was not super familiar and came across this article which is helpful:\n\nNote: I think “deep dive” is misleading and it is more “a short summary of how 10 of the top DAOs work” - but very informative nonetheless\nThere are a few characteristics between SUSHI, CRV and UMA that stand\n\nSushi uses Snapshot for voting — a decentralized and gasless voting dashboard.\nCRV has voting weight issued to each user depends on the timelock implemented for the locked governance token\nCRV has a lower limit on token holdings for proposal submission (2500 CRV)\nUMA has a template for new proposals (UMIP) UMIPs/umip-template.md at master · UMAprotocol/UMIPs · GitHub\n\nA few thoughts:\nFor sushi using Snapshot is really all that stands out as positive to me, but I’d love to see more information and have a broader discussion of which aspects people like. It just seems very “loose” to me from the summary I found above.\nThe concept of locking tokens for voting weight is really appealing - it mimics RSUs in a ways. Having the tokens locked for a period of time implies a commitment beyond short-term price action, and gives some kind of reassurance that you plan on staying involved for a period of time.\nIn terms of UMA/UMIPs - I love the structure here, having some templated way to submit proposals makes the proposals require a little more thought and coverage. As an engineer having scope that is very clearly defined is crucial for executing on that scope. A template won’t solve 100% of cases, but it will make the process a lot more clear.\n\n post by heropunk.eth on Nov 17, 2021\n\n heropunk.eth\n\n I agree with you and express my support\n\n post by Rush on Nov 17, 2021\n\n Rush\n\n I’ve been reading the discord and one main point the team has expressed to be of major importance is obtaining and keeping customers early on, to generate revenue for the treasury. I’m not familiar with $sushi tokenomics, but does what $sushi do meet these objectives at the start?\nIf not, i would like to propose tokenomics that would fall under the strategy, marketing and operations parts of the DAO.\nLets say there IS an airdrop, how would you keep customers after? We could perhaps do the DYDX model where first attention is garnered with a small airdrop, and then they’re incentivized to try the bridge themselves whilst being paid to do so, just like in DYDX where they pay traders who trade on their platforms with the $DYDX token. Doesn’t have to be a large amount and can be just for a short amount of time, 1 month or so when most potential customers are now aware of it. “Paying you to bridge” is also great headlines for free publicity, I can envision bridgooors reading crypto newsletters to be attracted to such a heading. The cost of such marketing would be the cost of the airdrop, and the fees generated for the protocol at the start too. Basically similar to a startup where you spend first to earn later.\nThe product then markets itself, who would want to try another bridge whilst having one that tick all their boxes? And a lifetime customer is born. But of course to remain above the rest Across Protocol cannot fall behind, all we need to do is to ensure that the basics are first class.\n\n post by fommes.eth on Nov 17, 2021\n\n fommes.eth\n\n I completely agree here, imho the DYDX model fits perfectly for the Across token release. But I would make the initial (retro) airdrop quite substancial (just like DYDX), this creates a lot of publicity on CT. Also the approach of DYDX that you had to reach certain milestones imo is the way to go for the Across token release. For example users of other popular EVM bridges could get the airdrop if they would in a certain time span use the Across bridge with at least once, no min amount required, since Across has already a min because of Gas fees.\n\n post by mrbluesg on Nov 17, 2021\n\n mrbluesg\n\n Yeah, am a big fan of DYDX L2. Been using their platform since the early days… Was airdropped some tokens and as part of the requisite, had to trade on their L2… Grew to love it and today, it is my main Go-To perpetual trading platform. (ps. have not sold a single token as well as i see much growth potential being a user myself)\nIn summary, airdrop is like a marketing budget where you bring in targeted users. Have a good product that they can use and grow to love… So that the project can gain not only marketshare, but also mindshare.\n\n post by Heruvim78 on Nov 17, 2021\n\n Heruvim78\n\n I found interesting the 03 model on BSC, where your funds needed to be unlocked, and the unlocked funds where faster the more liquidity provided. but this is not entirely applicable here. i still find their system lacking somehow.\n\n post by Kevinswap on Nov 17, 2021\n\n Kevinswap\n\n This is quite good and I’m ok with it\n\n post by Momo95 on Nov 17, 2021\n\n Momo95\n\n Rush\n\n you have my full support \n\n post by Raypok on Nov 17, 2021\n\n Raypok\n\n You want to drop to actual users of bridge protocols, thats the real userbase and probably more dedicated to hold on and be active in a DAO structure imo, so you could look for Arbitrum/Optimism/Hop/x-pollinate/Across bridge users for instance and the discord community that is actively helping to construct the DAO transition. You could setup a point system, if you use more protocols you get a bigger piece of the pie or some sort. Then for the technical part i back the above ideas to look into the Sushi/Curve/Uma method, they are proven succesfull.\n\n post by jeffrey on Nov 17, 2021\n\n jeffrey\n\n Agreed!That`s a classic model.\n\n Load more posts below","tokens":3677,"squid":"spider-09","role":"Bridge Spider","at":1791344180669,"hash":"99ded9d0043941f75269e6e08e0a2b46dfd9a6ae"}
{"url":"https://www.metaplex.com/docs/smart-contracts/core/tm-differences","domain":"metaplex.com","title":"Core vs Token Metadata | Metaplex Core","text":"Coming from Token Metadata? This guide explains what's different in Core, why it's better, and how to translate your TM knowledge to Core concepts. Key DifferencesSingle account vs 3+ accounts (mint, metadata, token account)Over 80% lower costs: ~0.003 SOL vs 0.022 SOL per mintPlugins instead of delegates and freeze authoritiesCollections are first-class with collection-level operationsNo Associated Token Accounts neededSummaryCore replaces Token Metadata's multi-account model with a single-account design. Everything is simpler: creating, freezing, delegating, and managing collections. The plugin system replaces TM's scattered delegate types with a unified, extensible architecture.FeatureToken MetadataCoreAccounts per NFT3+ (mint, metadata, ATA)1Mint cost~0.022 SOL~0.003 SOLFreeze mechanismDelegate + freeze authorityFreeze Delegate pluginRoyaltiesPer-asset updatesFlexible: collection or asset levelOn-chain attributes❌✅ Attributes pluginOut of ScopepNFT-specific features and fungible token handling (use SPL Token).Quick StartJump to: Cost Comparison · Collections · Freeze/Lock · Lifecycle Events If you're starting fresh, use Core. If migrating, the key mental shifts are:One account, not threePlugins, not delegatesCollection-level operations are nativeDifference OverviewUnprecedented Cost Efficiency: Metaplex Core offers the lowest minting costs compared to available alternatives. For instance, an NFT that would cost .022 SOL with Token Metadata can be minted with Core for ~0.003 SOL.Improved Developer Experience: While most digital assets inherit the data needed to maintain an entire fungible token program, Core is optimized for NFTs, allowing all key data to be stored in a single Solana account. This dramatically reduces complexity for developers, while also helping improve network performance for Solana more broadly.Enhanced Collection Management: With first-class support for collections, developers and creators can easily manage collection-level configurations such as royalties and plugins, which can be uniquely overridden for individual NFTs. This can be done in a single transaction, reducing collection management costs and Solana transaction fees.Advanced Plugin Support: From built-in staking to asset-based point systems, the plugin architecture of Metaplex Core opens a vast landscape of utility and customization. Plugins allow developers to hook into any asset life cycle event like create, transfer and burn to add custom behaviors.Compatibility and Support: Fully supported by the Metaplex Developer Platform, Core is set to integrate seamlessly with a suite of SDKs and upcoming programs, enriching the Metaplex ecosystem.Out of the Box Indexing: Expanding on the Metaplex Digital Asset Standard API (DAS API), Core assets will be automatically indexed and available for application developers through a common interface that is used for all Solana NFTs. However, a unique improvement is that with the Core attribute plugin, developers will be able to add on chain data that is now also automatically indexed.Technical overviewCreateTo create a Core Asset, only a single create instruction is required. There is no need to mint and attach metadata later as was required by Token Metadata. This reduces the complexity and transaction size.CollectionsCore Collections include multiple new features. Collections are now their own account type and differentiate themselves from regular Assets. This is a welcome addition from Token Metadatas approach of using the same accounts and state to represent both NFT's and Collections making the two difficult to tell apart. With Core, Collections are first class assets that allow additional functionalities. For example, Core provides for collection-level royalty adjustments by adding the Royalties Plugin to the collection. Developers and creators can now update all assets in a collection at once rather than being forced to update each asset individually. But what if some assets in the collection should have different royalty settings? No problem – just add the same plugin to the asset and the collection-level royalty plugin will be overwritten Collection features that were not possible with TM are for example collection level royalties - no more having updating each asset when changing the royalties or creators but define it in the collection. This can be done by adding the Royalties Plugin to your collection. Some assets should have different royalty settings? Just add the same plugin to the asset and the collection level royalty plugin would be overwritten. Freezing is also possible on the collection level. You can find more information on handling collections, like creating or updating them on the Managing Collections page.Lifecycle events and PluginsDuring an Asset's lifecycle multiple events can be triggered, such as:CreatingTransferringUpdatingBurningAdd PluginApprove Authority PluginRemove Authority Plugin In TM these lifecyle events are either executed by the owner or a delegate. All TM Assets (nfts/pNfts) include functions for every lifecycle event. In Core these events are handled by Plugins at either a Asset or Collection wide level. Plugins attached on both an Asset level or a Collection level will run through a validation process during these lifecycle events to either approve, reject, or force approve the event from execution.Freeze / LockTo freeze an asset with TM you typically first delegate the freeze authority to a different wallet, which then freezes the NFT. In Core you must use one of two plugins: Freeze Delegate or Permanent Freeze Delegate. The latter can only be added during Asset creation, while the Freeze Delegate plugin can be added at any time providing the current owner signs the transaction. Delegation is also easier with Core as we do away with Delegete Record accounts and store delegate authorities directly on the plugin itself while also being assignable at the point of adding a plugin to an Asset either during Asset creation or via addPluginV1 function. To have the owner assign the freeze authority to a different Account, when the asset does not have a freeze plugin yet they would need to add the plugin with that authority and freeze it. Here's a quick example of adding the Freeze Delegate plugin to an Asset while also assigning it to a delegated authority.Additionally in Core freezing can be done on the collection level. A complete collection can be frozen or thawed in just one transaction.Asset statusIn TM you often have to check multiple Accounts to find the current status of an Asset and if it has been frozen, locked, or even in a transferable state. With Core this status is stored in the Asset account but can be also be affected by the Collection account. To make things easier we have introduced lifecycle helpers such as canBurn, canTransfer, canUpdate which come included in the @metaplex-foundation/mpl-core package. These helpers return a boolean value letting you know if the passed in address has permission to execute these lifecycle events.const burningAllowed = canBurn(authority, asset, collection)\nQuick ReferenceTM Concept → Core EquivalentToken MetadataCore EquivalentMint accountAsset accountMetadata accountAsset account (combined)Associated Token AccountNot neededFreeze authorityFreeze Delegate pluginUpdate authorityUpdate authority (same)DelegateTransfer/Burn/Update Delegate pluginsCollection verifiedCollection membership (automatic)Creators arrayVerified Creators pluginUses/utilityPlugins (custom logic)Common OperationsOperationToken MetadataCoreCreate NFTcreateV1() (multiple accounts)create() (single account)FreezeDelegate then freezeAdd Freeze Delegate pluginUpdate metadataupdateV1()update()TransferSPL Token transfertransfer()BurnburnV1()burn()FAQShould I use Core or Token Metadata for new projects?Use Core for all new projects. It's cheaper, simpler, and has better features. Token Metadata for NFTs is legacy.Can I migrate existing TM NFTs to Core?Not automatically. Core Assets are different on-chain accounts. Migration would require burning TM NFTs and minting new Core Assets.What happened to pNFTs?Core's royalty enforcement is built-in via the Royalties plugin with allowlist/denylist support. No separate \"programmable\" variant needed.Do I still need Associated Token Accounts?No. Core Assets don't use ATAs. Ownership is stored directly in the Asset account.How do I verify creators in Core?Use the Verified Creators plugin. It works similarly to TM's creator array but is opt-in.Further ReadingThe features described above are just the tip of the iceberg. Additional interesting topics include:Collection ManagementPlugin OverviewAdding on-chain data using the Attributes PluginCreating AssetsGlossaryTermDefinitionToken Metadata (TM)Legacy Metaplex NFT standard using multiple accountsCoreNew Metaplex NFT standard with single-account designPluginModular functionality added to Core AssetsATAAssociated Token Account (not needed in Core)pNFTProgrammable NFT in TM (royalty enforcement built into Core)","tokens":2259,"squid":"dotcat","role":"Tooling Spider","at":1791344189148,"hash":"33c823b8ca043fd091af39768ba5cba32bffed12"}
{"url":"https://ethresear.ch/t/somewhat-time-critical-how-do-i-set-a-password/11074/5","domain":"ethresear.ch","title":"Somewhat time critical — How do I set a password? - Administrivia - Ethereum Research","text":"Administrivia\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 5\n\n 2\n\n Oct 2021\n\n 4 / 9\n\n Oct 2021\n\n Nov 2021\n\n post by x on Oct 22, 2021\n\n x\n\n This site required me to do OAuth to register. For privacy / data hygiene reasons I then removed my GitHub from this profile and de-authenticated the site in GitHub.\nNext I changed my GitHub email address and deleted the previous address. Finally I also generated a new email address for this site to then remove the final remaining link to GitHub.\nQuestion: How can I set a password on this site, such that I will be allowed to log in once my cookie expires? Can I just log in with the email that’s now in my profile, without a password?\n\n Ethresear.ch: email login will be disabled in 7 days\n\n 5\n\n 2\n\n post by hwwhww on Oct 22, 2021\n\n hwwhww\n\n Well, the main reason why we disallow email login is for mitigating spamming. GitHub account association also provides some reputation reference in R&D community. (And considering dogfooding Ethereum account login in the future)\nI don’t think you can set password now. If you want to hide your main email/GitHub info, you could register a new GitHub account for ethresear.ch.\nSorry it’s not perfect, but IMO it’s not good to enable email login in ethresear.ch.\n\n post by x on Oct 22, 2021\n\n x\n\n K … well the guys over at ethereum-magicians allow it. They also have 2FA \n\n post by pavloMandryk on Oct 22, 2021\n\n pavloMandryk\n\n Hi, this is my first reply, hope it can be helpful.\nAs @hwwhww mentioned, there is no way you can set a password; but you still can recover access to the profile after cookie expiration.\nThe way to proceed would be creating a new GitHub account for the newly set “primary email” in your forum profile. You can access your profile using those GitHub credentials. This way you didn’t need to create an extra profile and still succeed to remove any trace of your main GitHub account.\nTo achieve privacy when creating a ethresear.ch profile just use a fresh email with a fresh GitHub account.\n\n post by x on Oct 22, 2021\n\n x\n\n My session is still alive! Woohoo, clearly living on the edge here. Tbh, as some might have guessed, I didn’t really expect to receive a solution here. I just wanted to highlight that the current system seems inefficient.\nGiven how easy it is to create a separate GitHub account for registration here, what is the purpose of enforcing GitHub in the first place? If it’s for reputation purposes, then you shouldn’t be allowed to disassociate your GitHub again, and you should enforce a certain minimum GitHub account age or a certain minimum number of GitHub contributions.\nThe current system doesn’t protect us from anything. Instead, I only see negative outcomes:\n\nPeople who don’t want all their profiles across the Internet correlated are forced to go through the extra step of setting up a throwaway GitHub account (it takes time to set up and secure) — there is a reason why people set their GitHub email to private\nPeople who don’t have time to do that may need to unnecessarily sacrifice OpSec against their will\nPeople who don’t know yet what they want are by default directed into a non-privacy maximizing choice and the use of single-sign on is wrongly presented to them as a best practice (by a reputable community)\n\nGiven the increasing scrutiny from all sides, we should all try to become less traceable, not more traceable. At least, you should allow the people who care to minimize their attack surface.\n\n post by MicahZoltu on Oct 22, 2021\n\n MicahZoltu\n\n hwwhww\n\n Is the theory here to try to leverage GitHub’s spam protections? What is GitHub’s spam protection and can we just do that directly instead?\n\n post by pavloMandryk on Oct 22, 2021\n\n pavloMandryk\n\n These topics were discussed here alongside with the EAuth implementation.\n\n@hwwhww Are spamming and impersonator attacks the only reasons for disallowing email login? Did we have bad experiences with this before? How is ethereum-magicians managing these issues while allowing email login?\nI agree on maximizing non-traceability and would like to point out two more implications of the GitHub login only: UX and security.\nI believe that it is fair to say that a significant amount of potential users fall under a) don’t have an GitHub account or b) have a completely inactive GitHub account. For these users the lack of 2FA results on poor UX, of course, but also they are more likely to give up on security as they are probably less willing to set up and secure a GitHub account they don’t use.\nOn the other hand, in my personal experience as a GitHub user, the UX of the current system feels super smooth.\nThe advantages of having email login and GitHub auth would be:\n\nPrivacy for those who don’t want their profile to be associated with their GitHub.\nMore balanced UX.\n\nFor the current GitHub only system we have the following:\n\nLess privacy.\nA worst UX and security for non-GitHub-users.\nA better UX for GitHub users.\nProtection against spam and impersonator attacks.\n\nIs there a way to point to the GitHub account without using email as primary key? If this is non-trivial to make, we can’t enforce users to stick with one GitHub account since GitHub email can be changed.\n\nWhen it comes to EAuth implementation we are still facing the same privacy issues, as the idea would be enabling to sign up with ENS but requiring to associate a GitHub account with it. (Still excited about EAuth though!)\n\n post by x on Oct 22, 2021\n\n x\n\n If this is about impersonators, then the solution are cryptographic signatures, not some OAuth using some random website that some people don’t even feel comfortable using.\nYou could sign a message in your profile with GPG or you could even use an ETH key to sign it.\n\n 10 days later\n\n post by x on Nov 1, 2021\n\n x\n\n Hey friends — I can’t believe it, but I just came back after 10 days and my session is still live … ! Long live the cookies.\nSo, what did we end up with? Can this discussion be summarized as (not everyone thinks this! thank you for the constructive discussion so far):\n\nThe reason for GitHub auth is to avoid impersonation\nCryptographic signatures (OpenPGP, Minisign, ETH keys, …) would be a better solution than GitHub to verify identities/pseudonyms\nHowever, the target users of this forum don’t like using cryptographic signatures for this use case\nThus the people in this forum want to keep using GitHub to avoid impersonation\n(They don’t care that others may not like that; either because it links their accounts unnecessarily, or because they just don’t want to use GitHub)\n\n(There was more nuance, but I tried to dumb it down.)\nEDIT: By the way … thank you all for voting me “User of the Month” … I feel very honored.\nimage1038×272 29 KB\n\n Powered by Discourse","tokens":1687,"squid":"spider-04","role":"Research Spider","at":1791344199481,"hash":"a7c318497a3e56857690bd150c77549500afe3ff"}
{"url":"https://ethereum.org/en/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":"spider-05","role":"Spec Spider","at":1791344204615,"hash":"62f2cb7a1d2c096a23add991bfa58dcd2aa5365f"}
{"url":"https://www.metaplex.com/docs/smart-contracts/core/guides","domain":"metaplex.com","title":"Guides | Core","text":"The following Guides for MPL Core are currently available:Soulbound NFTDifferent options for Soulbound NFT including code examplesPrint EditionsLearn how to combine plugins to create Editions with MPL CoreImmutabilityLearn how Immutability works in MPL CoreOracle Plugin ExampleLearn how you can create a collection that can be traded only during US market hoursAppdata Plugin ExampleLearn how you can create a ticketing platform leveraging the Appdata pluginTypescript Staking ExampleLearn how you can create a staking program for your collection using only TypescriptAnchor Staking ExampleLearn how you can create a staking smart contract for your collection","tokens":165,"squid":"dotcat","role":"Tooling Spider","at":1791344211732,"hash":"ce62bb969bb118909e29df9bee6ceaae938b0d29"}
{"url":"https://ethresear.ch/t/somewhat-time-critical-how-do-i-set-a-password/11074/8","domain":"ethresear.ch","title":"Somewhat time critical — How do I set a password? - Administrivia - Ethereum Research","text":"Administrivia\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 5\n\n 2\n\n Oct 2021\n\n 7 / 9\n\n Oct 2021\n\n Nov 2021\n\n post by x on Oct 22, 2021\n\n x\n\n This site required me to do OAuth to register. For privacy / data hygiene reasons I then removed my GitHub from this profile and de-authenticated the site in GitHub.\nNext I changed my GitHub email address and deleted the previous address. Finally I also generated a new email address for this site to then remove the final remaining link to GitHub.\nQuestion: How can I set a password on this site, such that I will be allowed to log in once my cookie expires? Can I just log in with the email that’s now in my profile, without a password?\n\n Ethresear.ch: email login will be disabled in 7 days\n\n 5\n\n 2\n\n post by hwwhww on Oct 22, 2021\n\n hwwhww\n\n Well, the main reason why we disallow email login is for mitigating spamming. GitHub account association also provides some reputation reference in R&D community. (And considering dogfooding Ethereum account login in the future)\nI don’t think you can set password now. If you want to hide your main email/GitHub info, you could register a new GitHub account for ethresear.ch.\nSorry it’s not perfect, but IMO it’s not good to enable email login in ethresear.ch.\n\n post by x on Oct 22, 2021\n\n x\n\n K … well the guys over at ethereum-magicians allow it. They also have 2FA \n\n post by pavloMandryk on Oct 22, 2021\n\n pavloMandryk\n\n Hi, this is my first reply, hope it can be helpful.\nAs @hwwhww mentioned, there is no way you can set a password; but you still can recover access to the profile after cookie expiration.\nThe way to proceed would be creating a new GitHub account for the newly set “primary email” in your forum profile. You can access your profile using those GitHub credentials. This way you didn’t need to create an extra profile and still succeed to remove any trace of your main GitHub account.\nTo achieve privacy when creating a ethresear.ch profile just use a fresh email with a fresh GitHub account.\n\n post by x on Oct 22, 2021\n\n x\n\n My session is still alive! Woohoo, clearly living on the edge here. Tbh, as some might have guessed, I didn’t really expect to receive a solution here. I just wanted to highlight that the current system seems inefficient.\nGiven how easy it is to create a separate GitHub account for registration here, what is the purpose of enforcing GitHub in the first place? If it’s for reputation purposes, then you shouldn’t be allowed to disassociate your GitHub again, and you should enforce a certain minimum GitHub account age or a certain minimum number of GitHub contributions.\nThe current system doesn’t protect us from anything. Instead, I only see negative outcomes:\n\nPeople who don’t want all their profiles across the Internet correlated are forced to go through the extra step of setting up a throwaway GitHub account (it takes time to set up and secure) — there is a reason why people set their GitHub email to private\nPeople who don’t have time to do that may need to unnecessarily sacrifice OpSec against their will\nPeople who don’t know yet what they want are by default directed into a non-privacy maximizing choice and the use of single-sign on is wrongly presented to them as a best practice (by a reputable community)\n\nGiven the increasing scrutiny from all sides, we should all try to become less traceable, not more traceable. At least, you should allow the people who care to minimize their attack surface.\n\n post by MicahZoltu on Oct 22, 2021\n\n MicahZoltu\n\n hwwhww\n\n Is the theory here to try to leverage GitHub’s spam protections? What is GitHub’s spam protection and can we just do that directly instead?\n\n post by pavloMandryk on Oct 22, 2021\n\n pavloMandryk\n\n These topics were discussed here alongside with the EAuth implementation.\n\n@hwwhww Are spamming and impersonator attacks the only reasons for disallowing email login? Did we have bad experiences with this before? How is ethereum-magicians managing these issues while allowing email login?\nI agree on maximizing non-traceability and would like to point out two more implications of the GitHub login only: UX and security.\nI believe that it is fair to say that a significant amount of potential users fall under a) don’t have an GitHub account or b) have a completely inactive GitHub account. For these users the lack of 2FA results on poor UX, of course, but also they are more likely to give up on security as they are probably less willing to set up and secure a GitHub account they don’t use.\nOn the other hand, in my personal experience as a GitHub user, the UX of the current system feels super smooth.\nThe advantages of having email login and GitHub auth would be:\n\nPrivacy for those who don’t want their profile to be associated with their GitHub.\nMore balanced UX.\n\nFor the current GitHub only system we have the following:\n\nLess privacy.\nA worst UX and security for non-GitHub-users.\nA better UX for GitHub users.\nProtection against spam and impersonator attacks.\n\nIs there a way to point to the GitHub account without using email as primary key? If this is non-trivial to make, we can’t enforce users to stick with one GitHub account since GitHub email can be changed.\n\nWhen it comes to EAuth implementation we are still facing the same privacy issues, as the idea would be enabling to sign up with ENS but requiring to associate a GitHub account with it. (Still excited about EAuth though!)\n\n post by x on Oct 22, 2021\n\n x\n\n If this is about impersonators, then the solution are cryptographic signatures, not some OAuth using some random website that some people don’t even feel comfortable using.\nYou could sign a message in your profile with GPG or you could even use an ETH key to sign it.\n\n 10 days later\n\n post by x on Nov 1, 2021\n\n x\n\n Hey friends — I can’t believe it, but I just came back after 10 days and my session is still live … ! Long live the cookies.\nSo, what did we end up with? Can this discussion be summarized as (not everyone thinks this! thank you for the constructive discussion so far):\n\nThe reason for GitHub auth is to avoid impersonation\nCryptographic signatures (OpenPGP, Minisign, ETH keys, …) would be a better solution than GitHub to verify identities/pseudonyms\nHowever, the target users of this forum don’t like using cryptographic signatures for this use case\nThus the people in this forum want to keep using GitHub to avoid impersonation\n(They don’t care that others may not like that; either because it links their accounts unnecessarily, or because they just don’t want to use GitHub)\n\n(There was more nuance, but I tried to dumb it down.)\nEDIT: By the way … thank you all for voting me “User of the Month” … I feel very honored.\nimage1038×272 29 KB\n\n Powered by Discourse","tokens":1687,"squid":"spider-04","role":"Research Spider","at":1791344211798,"hash":"9e64978db48f689765efa3eabf1366927ef3066e"}
{"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)AvadoFrom 10.4 ETHBrowserGUIOpen sourceAuditedBug bountyBattle testedTrustlessPermissionlessMulti-clientSelf custodyEconomicalVisit on (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)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)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)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:What uptime is required for a validator to be profitable?","tokens":5883,"squid":"spider-05","role":"Spec Spider","at":1791344214847,"hash":"12cc63cf6c2d1532f4569a62d31128bf5dc6af60"}
{"url":"https://www.metaplex.com/docs/smart-contracts/core/guides/oracle-plugin-example","domain":"metaplex.com","title":"Create a US Market Trading Experience Using the Oracle External Plugin | Core Guides","text":"This developer guide leverages the new Oracle Plugin to create an NFT collection that can only be traded during US market hours.IntroductionExternal PluginAn External Plugin is a plugin whose behavior is controlled by an external source. The core program will provide an adapter for these plugins, but developers decide the behavior by pointing this adapter to an external data source. Each External Adapter has the ability to assign lifecycle checks to Lifecycle Events, influencing the behavior of the lifecycle event taking place. This means we can assign the following checks to lifecycle events like create, transfer, update, and burn:Listen: A “web3” webhook that alerts the plugin when a lifecycle event occurs. This is particularly useful for tracking data or performing actions.Reject: The plugin can reject a lifecycle event.Approve: The plugin can approve a lifecycle event. If you want to learn more about External Plugins, read more about them on the External Plugins overview.Oracle PluginThe Oracle Plugin leverages the capability of external plugins to save data that an external authority can update by accessing onchain data accounts external to the Core asset, allowing assets to dynamically reject lifecycle events set by the asset authority. The external Oracle account can also be updated at any time to change the authorization behavior of the lifecycle events, providing a flexible and dynamic experience. If you want to learn more about the Oracle Plugin, read more about it on the Oracle Plugin page.Starting off: Understanding the Protocol behind the IdeaTo create an NFT collection that can only be traded during US market hours, we need a reliable way of updating onchain data based on the time of day. This is how the protocol design will look like:Program OverviewThe program will have two main instructions (one to create the Oracle and the other to update its value) and two helper functions to facilitate implementation. Main InstructionsInitialize Oracle Instruction: This instruction creates the oracle account so any user wanting to employ this time-gated feature for their collection will redirect the NFT Oracle Plugin to this onchain account address.Crank Oracle Instruction: This instruction updates the oracle state data to ensure it always has the right and most up-to-date data. Helper functionsisUsMarketOpen: Checks if the US market is open.isWithin15mOfMarketOpenOrClose: Checks if the current time is within 15 minutes of market opening or closing. Note: The crank_oracle_instruction ensure that the protocol is updated with accurate data providing incentives to those maintaining up-to-date information. But we'll talk about this in the next section.The Incentives mechanismEvery collection using this oracle as a source of trust should run its own crank to ensure that the oracle is always up-to-date. However, to enhance resilience, protocol developers should consider creating incentives for multiple people to crank the protocol, ensuring a safety net that keeps the oracle data accurate if the in-house crank fails to update the data. The current program design rewards crankers for maintaining the oracle with 0.001 SOL. This amount is manageable while still providing a sufficient incentive for crankers to keep the oracle state account up-to-date. Note: These incetives are paid out only if the crank is executed the first 15 minute of market opening or closing and are funded from a vault present in the smart contract. The vault needs to be refilled by sending SOL to the oracle vault address.Let's Get Our Hands Dirty: Building out the ProgramNow that the logic behind our protocol is clear, it’s time to dive into the code and bring it all together!Anchor OverviewIn this guide, we'll use the Anchor framework, but you can also implement it using a native program. Learn more about the Anchor framework on the Anchor website. For simplicity, we'll use a mono-file approach, with helpers, state, accounts, and instructions all in lib.rs instead of the usual separation. Note: You can follow along and open the example on the Metaplex Foundation Github: Oracle Trading ExampleHelpers & ConstantsInstead of declaring some inputs repeatedly, it’s a good idea to create constants that we can easily reference in our instructions/functions. Here are the constants used in this oracle protocol:// Constants\nconst SECONDS_IN_AN_HOUR: i64 = 3600;\nconst SECONDS_IN_A_MINUTE: i64 = 60;\nconst SECONDS_IN_A_DAY: i64 = 86400;\nconst MARKET_OPEN_TIME: i64 = 14 * SECONDS_IN_AN_HOUR + 30 * SECONDS_IN_A_MINUTE; // 14:30 UTC == 9:30 EST\nconst MARKET_CLOSE_TIME: i64 = 21 * SECONDS_IN_AN_HOUR; // 21:00 UTC == 16:00 EST\nconst MARKET_OPEN_CLOSE_MARGIN: i64 = 15 * SECONDS_IN_A_MINUTE; // 15 minutes in seconds\nconst REWARD_IN_LAMPORTS: u64 = 10000000; // 0.001 SOL\nCreating helpers to check some of the logic of our smart contract makes sense, such as checking if the US market is open and if it’s within 15 minutes of opening or closing. is_us_market_open helper:fn is_us_market_open(unix_timestamp: i64) -> bool {\n let seconds_since_midnight = unix_timestamp % SECONDS_IN_A_DAY;\n let weekday = (unix_timestamp / SECONDS_IN_A_DAY + 4) % 7;\n // Check if it's a weekday (Monday = 0, ..., Friday = 4)\n if weekday >= 5 {\n return false;\n }\n // Check if current time is within market hours\n seconds_since_midnight >= MARKET_OPEN_TIME && seconds_since_midnight < MARKET_CLOSE_TIME\n}\nThis helper checks if the US market is open based on the given Unix timestamp by calculating the seconds since midnight and the day of the week. If the current time is a weekday and is within market hours, it returns true. Note: This is just an example, particular occasion (like banking holiday) will not be taken in consideration. is_within_15_minutes_of_market_open_or_close helper:fn is_within_15_minutes_of_market_open_or_close(unix_timestamp: i64) -> bool {\n let seconds_since_midnight = unix_timestamp % SECONDS_IN_A_DAY;\n // Check if current time is within 15 minutes after market open or within 15 minutes after market close\n (seconds_since_midnight >= MARKET_OPEN_TIME && seconds_since_midnight < MARKET_OPEN_TIME + MARKET_OPEN_CLOSE_MARGIN) ||\n (seconds_since_midnight >= MARKET_CLOSE_TIME && seconds_since_midnight < MARKET_CLOSE_TIME + MARKET_OPEN_CLOSE_MARGIN)\n}\nThis helper checks if the current time is within 15 minutes of the market opening or closing by calculating the seconds since midnight and comparing it with the market open and close times, adding a 15-minute margin.StateOn Solana, to store data on the chain, we need to create a struct that will represent this data once deserialized. So here's the struct we're going to use for our Oracle Account.#[account]\npub struct Oracle {\n pub validation: OracleValidation,\n pub bump: u8,\n pub vault_bump: u8,\n}\nimpl Space for Oracle {\n const INIT_SPACE: usize = 8 + 5 + 1 + 1;\n}\nLet's discuss some of the choices made in creating this struct:There is no admin field because once initialized, it’s going to be permissionless, allowing anyone to interact with it.The validation field is positioned first to leverage the native way of setting up the offset to search for on the NFT with just the discriminator size (8 bytes), avoiding the need for a custom offset on the Oracle Plugin config.We save the bump for both the Oracle PDA and the Oracle Vault PDA to avoid deriving bumps every time we include this accounts in the instruction. This is a standard in Solana Development and it helps saving Compute Usage. Read more about it on Solana StackExchange Regarding space calculation, we use the Space implementation for Anchor directly, creating a constant called INIT_SPACE to reference when creating the PDA and storing enough SOL for rent exemption.The only unusual aspect is that the OracleValidation struct from mpl-core needs to have a size of 5 bytes. The rest of the space calculation is standard. Learn more about calculating space in the Anchor Book.AccountsAccounts on anchor are a structure of validated accounts that can be deserialized from the input to a Solana program. For our program, the account structure used for both instructions is very similar. However, in one we initialize the Oracle account, and in the other, we just reference it. Let's explore the CreateOracle Account:#[derive(Accounts)]\npub struct CreateOracle<'info> {\n pub signer: Signer<'info>,\n #[account(mut)]\n pub payer: Signer<'info>,\n #[account(\n init,\n payer = payer,\n space = Oracle::INIT_SPACE,\n seeds = [b\"oracle\"],\n bump\n )]\n pub oracle: Account<'info, Oracle>,\n #[account(\n seeds = [b\"reward_vault\", oracle.key().as_ref()],\n bump,\n )]\n pub reward_vault: SystemAccount<'info>,\n pub system_program: Program<'info, System>,\n}\nThe struct presents two separate accounts for the signer and the payer of this instruction. This is standard for most instructions, even if not strictly necessary here, as it ensures that if a PDA signs the transaction, we still have an account to pay the fees. Both need to be signers of the transaction. Other details:The Oracle account is initialized and has [b\"oracle\"] as seeds to ensure there is no possibility of creating more than one oracle account. The space allocated is defined by the INIT_SPACE constant.The reward_vault account is included in this instruction to save the bumps for use in the next instruction.The System program is necessary for creating new accounts on Solana since the init macro will use the create_account instruction from the system program. Now let's see the CrankOracle Account:#[derive(Accounts)]\npub struct CrankOracle<'info> {\n pub signer: Signer<'info>,\n #[account(mut)]\n pub payer: Signer<'info>,\n #[account(\n mut,\n seeds = [b\"oracle\"],\n bump = oracle.bump,\n )]\n pub oracle: Account<'info, Oracle>,\n #[account(\n mut, \n seeds = [b\"reward_vault\", oracle.key().as_ref()],\n bump = oracle.vault_bump,\n )]\n pub reward_vault: SystemAccount<'info>,\n pub system_program: Program<'info, System>,\n}\nThis structure is similar to the CreateOracle account but with oracle and reward_vault set as mutable. This is because the oracle will need to update its validation input, and the reward_vault will need to adjust the lamports to pay the cranker. The bump fields are explicitly defined from the oracle account to avoid recalculating them everytime.InstructionsFinally, we are at the most important part: the instructions, where the magic happens! Create Oracle Instruction:pub fn create_oracle(ctx: Context<CreateOracle>) -> Result<()> {\n // Set the Oracle validation based on the time and if the US market is open\n match is_us_market_open(Clock::get()?.unix_timestamp) {\n true => {\n ctx.accounts.oracle.set_inner(\n Oracle {\n validation: OracleValidation::V1 {\n transfer: ExternalValidationResult::Approved,\n create: ExternalValidationResult::Pass,\n update: ExternalValidationResult::Pass,\n burn: ExternalValidationResult::Pass,\n },\n bump: ctx.bumps.oracle,\n vault_bump: ctx.bumps.reward_vault,\n }\n );\n }\n false => {\n ctx.accounts.oracle.set_inner(\n Oracle {\n validation: OracleValidation::V1 {\n transfer: ExternalValidationResult::Rejected,\n create: ExternalValidationResult::Pass,\n update: ExternalValidationResult::Pass,\n burn: ExternalValidationResult::Pass,\n },\n bump: ctx.bumps.oracle,\n vault_bump: ctx.bumps.reward_vault,\n }\n );\n }\n }\n Ok(())\n}\nThis instruction initializes the oracle account using set_inner to populate the Oracle State Struct correctly. Based on the result of the is_us_market_open function, it will either approve or reject the transfer for NFTs pointing to that account. Additionally, it saves the bumps using ctx.bumps. Crank Oracle Instruction:pub fn crank_oracle(ctx: Context<CrankOracle>) -> Result<()> {\n match is_us_market_open(Clock::get()?.unix_timestamp) {\n true => {\n require!(\n ctx.accounts.oracle.validation == OracleValidation::V1 {\n transfer: ExternalValidationResult::Rejected,\n create: ExternalValidationResult::Pass,\n burn: ExternalValidationResult::Pass,\n update: ExternalValidationResult::Pass\n },\n Errors::AlreadyUpdated\n );\n ctx.accounts.oracle.validation = OracleValidation::V1 {\n transfer: ExternalValidationResult::Approved,\n create: ExternalValidationResult::Pass,\n burn: ExternalValidationResult::Pass,\n update: ExternalValidationResult::Pass,\n };\n }\n false => {\n require!(\n ctx.accounts.oracle.validation == OracleValidation::V1 {\n transfer: ExternalValidationResult::Approved,\n create: ExternalValidationResult::Pass,\n burn: ExternalValidationResult::Pass,\n update: ExternalValidationResult::Pass\n },\n Errors::AlreadyUpdated\n );\n ctx.accounts.oracle.validation = OracleValidation::V1 {\n transfer: ExternalValidationResult::Rejected,\n create: ExternalValidationResult::Pass,\n burn: ExternalValidationResult::Pass,\n update: ExternalValidationResult::Pass,\n };\n }\n }\n let reward_vault_lamports = ctx.accounts.reward_vault.lamports();\n let oracle_key = ctx.accounts.oracle.key().clone();\n let signer_seeds = &[b\"reward_vault\", oracle_key.as_ref(), &[ctx.accounts.oracle.bump]];\n\n if is_within_15_minutes_of_market_open_or_close(Clock::get()?.unix_timestamp) && reward_vault_lamports > REWARD_IN_LAMPORTS {\n // Reward cranker for updating Oracle within 15 minutes of market open or close\n transfer(\n CpiContext::new_with_signer(\n ctx.accounts.system_program.to_account_info(), \n Transfer {\n from: ctx.accounts.reward_vault.to_account_info(),\n to: ctx.accounts.signer.to_account_info(),\n }, \n &[signer_seeds]\n ),\n REWARD_IN_LAMPORTS\n )?\n }\n Ok(())\n}\nThis instruction functions similarly to the create_oracle instruction but with added checks. Based on the response from the is_us_market_open function, it verifies if the state was already updated. If not, it updates the state. The second part of the instruction checks if is_within_15_minutes_of_market_open_or_close is true and if there are enough lamports in the reward vault to pay the cranker. If both conditions are met, it transfers the reward to the cranker; otherwise, it does nothing.Create the NFTLast part of this journey will be to create a collection and point it to the Oracle account so every asset we include in that collection will follow the custom Oracle rule!Let's start by setting up your environment to use Umi. (Umi is a modular framework for building and using JavaScript clients for Solana programs. Learn more in the Umi Getting Started guide)import { createSignerFromKeypair, signerIdentity } from '@metaplex-foundation/umi'\nimport { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n// SecretKey for the wallet you're going to use \nimport wallet from \"../wallet.json\";\nconst umi = createUmi(\"https://api.devnet.solana.com\", \"finalized\")\nlet keyair = umi.eddsa.createKeypairFromSecretKey(new Uint8Array(wallet));\nconst myKeypairSigner = createSignerFromKeypair(umi, keyair);\numi.use(signerIdentity(myKeypairSigner));\nNext, we create the collection including the Oracle Plugin using the CreateCollection instruction:// Generate the Collection PublicKey\nconst collection = generateSigner(umi)\nconsole.log(\"Collection Address: \\n\", collection.publicKey.toString())\nconst oracleAccount = publicKey(\"...\")\n// Generate the collection\nconst collectionTx = await createCollection(umi, { \n collection: collection,\n name: 'My Collection',\n uri: 'https://example.com/my-collection.json',\n plugins: [\n {\n type: \"Oracle\",\n resultsOffset: {\n type: 'Anchor',\n },\n baseAddress: oracleAccount,\n authority: {\n type: 'UpdateAuthority',\n },\n lifecycleChecks: {\n transfer: [CheckResult.CAN_REJECT],\n },\n baseAddressConfig: undefined,\n }\n ]\n}).sendAndConfirm(umi)\n// Deserialize the Signature from the Transaction\nlet signature = base58.deserialize(collectinTx.signature)[0]; \nconsole.log(signature);\nConclusionCongratulations! You are now equipped to create an NFT collection that trades only during US market hours using the Oracle Plugin. If you want to learn more about Core and Metaplex, check out the developer hub.","tokens":3968,"squid":"dotcat","role":"Tooling Spider","at":1791344221980,"hash":"f93240f41af9d47301781737bcf76f81e218333b"}
{"url":"https://developers.jup.ag/docs/tool-kits/plugin/faq","domain":"developers.jup.ag","title":"Jupiter Plugin FAQ - Jupiter Developers","text":"Common questions and answers about Jupiter Plugin, including how to request features, add referral fees, fix integrated mode layout issues, and follow best practices for responsive design, user experience, and security.\nHow do I feature request or get support?\nFor feature requests, please open an issue on the GitHub repository and tag us on Discord.\nFor support, please join the Discord server and get help in the developer channels.\nHow do I add fees to Plugin?\nCreating Referral Account and Token Accounts: You can create via scripts or Referral Dashboard.\nAdding to FormProps: You can set the referral account and fee in the formProps interface when you initialize the Plugin.\nIntegrated Mode: Token Search Modal Collapses Plugin\nEnsure you establish a fixed height for the swap form container under containerStyles\n{\n displayMode: \"integrated\",\n integratedTargetId: \"jupiter-plugin\",\n containerStyles: {\n height: \"500px\",\n },\n}\n\n​Best Practices for Customization\nResponsive Design\nUse percentage-based widths for container styles\nTest on different screen sizes\nConsider mobile-first design\nUser Experience\nPosition widgets in easily accessible locations\nConsider fixed token pairs for specific use cases\nImplement proper error handling and prompts\nSecurity\nUse environment variables for sensitive data\nImplement proper error boundaries\nValidate user inputs\nWas this page helpful?","tokens":346,"squid":"spider-02","role":"Liquidity Spider","at":1791344225863,"hash":"05499017c3b3d5fe3840c4f6d138dc22d26dffc9"}
{"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 275 217Transactions 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 updatesEEZ Executes First Mainnet L1-to-L2 TransactionETH DailyEthereum’s first EEZ atomic cross-chain transaction links L1 and an L2 on mainnet. The briefing also covers proposed transaction safeguards in EIP-7906 and dGEN1’s on-device wallet protections.NewslettersOct 5, 2026 link-external-assistive-textHow native transaction assertions could enforce a transaction's final outcomeEthereum FoundationThe 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…FoundationOct 5, 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-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":1181,"squid":"spider-05","role":"Spec Spider","at":1791344226471,"hash":"5667dd05463bd491f2f717842185ea96eceb3de1"}
{"url":"https://www.metaplex.com/docs/smart-contracts/core/guides/javascript/how-to-create-a-core-collection-with-javascript","domain":"metaplex.com","title":"How to Create a Core Collection with Javascript | Core Guides","text":"This guide will demonstrate the use of the @metaplex-foundation/mpl-core Javascript sdk package to create a Core Collection using the Metaplex Core onchain program.What is Core?Core uses a single account design, reducing minting costs and improving Solana network load compared to alternatives. It also has a flexible plugin system that allows for developers to modify the behavior and functionality of assets.But before starting, let's talk about Collections:What are Collections?Collections are a group of Assets that belong together, part of the same series, or group. In order to group Assets together, we must first create a Collection Asset whose purpose is to store any metadata related to that collection such as collection name and collection image. The Collection Asset acts as a front cover to your collection and can also store collection wide plugins.PrerequisiteCode Editor of your choice (recommended Visual Studio Code)Node 18.x.x or above.Initial SetupThis guide will teach you how to create a Core Collection using Javascript based on a single file script. You may need to modify and move functions around to suit your needs.Initializing the ProjectStart by initializing a new project (optional) with the package manager of your choice (npm, yarn, pnpm, bun) and fill in required details when prompted.npm init\nRequired PackagesInstall the required packages for this guide.@metaplex-foundation/umi@metaplex-foundation/umi-bundle-defaults@metaplex-foundation/mpl-core@metaplex-foundation/umi-uploader-irysnpm i @metaplex-foundation/umi\nnpm i @metaplex-foundation/umi-bundle-defaults\nnpm i @metaplex-foundation/mpl-core\nnpm i @metaplex-foundation/umi-uploader-irys;\nImports and Wrapper FunctionHere we will define all needed imports for this particular guide and create a wrapper function where all our code will execute.import { \n createCollection, \n mplCore \n} from '@metaplex-foundation/mpl-core'\nimport {\n createGenericFile,\n generateSigner,\n signerIdentity,\n sol,\n} from '@metaplex-foundation/umi'\nimport { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\nimport { irysUploader } from '@metaplex-foundation/umi-uploader-irys'\nimport { base58 } from '@metaplex-foundation/umi/serializers'\nimport fs from 'fs'\nimport path from 'path'\n// Create the wrapper function\nconst createCollection = async () => {\n ///\n ///\n /// all our code will go in here\n ///\n ///\n}\n// run the wrapper function\ncreateCollection()\nSetting up UmiWhile setting up Umi you can use or generate keypairs/wallets from different sources. You create a new wallet for testing, import an existing wallet from the filesystem, or use walletAdapter if you are creating a website/dApp.Note: For this example we're going to set up Umi with a generatedSigner() but you can find all the possible setup down below!Note: The walletAdapter section provides only the code needed to connect it to Umi, assuming you've already installed and set up the walletAdapter. For a comprehensive guide, refer to the Wallet Adapter guideCreating the Metadata for the CollectionTo display a recognisable image for your Collection in the Wallets or on the Explorer, we need to create the URI where we can store the Metadata!Uploading the ImageUmi comes with downloadable storage plugins that allow you to upload to storage solutions such Arweave, NftStorage, AWS, and ShdwDrive. For this guide we're going to use the irysUploader() plugin which stores content on Arweave. In this example we're going to use a local approach using Irys to upload to Arweave; if you wish to upload files to a different storage provider or from the browser you will need to take a different approach. Importing and using fs won't work in a browser scenario.import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\nimport { irysUploader } from '@metaplex-foundation/umi-uploader-irys'\nimport fs from 'fs'\nimport path from 'path'\n// Create Umi and tell it to use Irys\nconst umi = createUmi('https://api.devnet.solana.com')\n .use(irysUploader())\n// use `fs` to read file via a string path.\n// You will need to understand the concept of pathing from a computing perspective.\nconst imageFile = fs.readFileSync(\n path.join(__dirname, '..', '/assets/my-image.jpg')\n)\n// Use `createGenericFile` to transform the file into a `GenericFile` type\n// that umi can understand. Make sure you set the mimi tag type correctly\n// otherwise Arweave will not know how to display your image.\nconst umiImageFile = createGenericFile(imageFile, 'my-image.jpeg', {\n tags: [{ name: 'Content-Type', value: 'image/jpeg' }],\n})\n// Here we upload the image to Arweave via Irys and we get returned a uri\n// address where the file is located. You can log this out but as the\n// uploader can takes an array of files it also returns an array of uris.\n// To get the uri we want we can call index [0] in the array.\nconst imageUri = await umi.uploader.upload([umiImageFile]).catch((err) => {\n throw new Error(err)\n})\nconsole.log(imageUri[0])\nUploading the MetadataOnce we have a valid and working image URI we can start working on the metadata for our collection. The standard for offchain metadata for a fungible token is as follows. This should be filled out and writen to either an object {} without Javascript or saved to a metadata.json file. We are going to look at the JavaScript object approach.const metadata = {\n name: 'My Collection',\n description: 'This is a Collection on Solana',\n image: imageUri[0],\n external_url: 'https://example.com',\n properties: {\n files: [\n {\n uri: imageUri[0],\n type: 'image/jpeg',\n },\n ],\n category: 'image',\n },\n}\nThe fields here include:fielddescriptionnameThe name of your Collection.descriptionThe description of your Collection.imageThis will be set to the imageUri (or any online location of the image) that we uploaded previously.animation_urlThis will be set to the animation_ulr (or any online location of the video/glb) that you've uploaded.external_urlThis would link to an external address of your choice. This is normally the projects website.imageThis will be set to the imageUri (or any online location of the image) that we uploaded previously.propertiesContains the files field that takes an [] array of {uri: string, type: mimeType}. Also contains the category field which can be set to image, audio, video, vfx, and htmlAfter creating the metadata, we need to upload it as a JSON file, so we can get a URI to attach to our Collection. To do this, we'll use Umi's uploadJson() function:// Call upon Umi's `uploadJson()` function to upload our metadata to Arweave via Irys.\nconst metadataUri = await umi.uploader.uploadJson(metadata).catch((err) => {\n throw new Error(err)\n})\nThis function automatically converts our JavaScript object to JSON before uploading. Now we should finally have the URI of JSON file stored in the metadataUri providing it did not throw any errors.Minting the Core CollectionFrom here we can use the createCollection function from the @metaplex-foundation/mpl-core package to create our Core NFT Asset.const collection = generateSigner(umi)\nconst tx = await createCollection(umi, {\n collection,\n name: 'My Collection',\n uri: metadataUri,\n}).sendAndConfirm(umi)\nconst signature = base58.deserialize(tx.signature)[0]\nAnd log out the detail as follow:// Log out the signature and the links to the transaction and the NFT.\nconsole.log('\\nCollection Created')\nconsole.log('View Transaction on Solana Explorer')\nconsole.log(`https://explorer.solana.com/tx/${signature}?cluster=devnet`)\nconsole.log('\\n')\nconsole.log('View Collection on Metaplex Explorer')\nconsole.log(`https://core.metaplex.com/explorer/${collection.publicKey}?env=devnet`)\nAdditional ActionsBefore moving on, what if we want to create a collection with plugins and/or external plugins, such as the FreezeDelegate plugin or the AppData external plugin, already included? Here's how we can do it. The createCollection() instruction supports adding both normal and external plugin through the plugins field. So we can just easily add all the required field for the specific plugins, and everything it will be handled by the instruction. Here's an example on how to do it:const collection = generateSigner(umi)\nconst tx = await createCollection(umi, {\n collection: collection,\n name: 'My Collection',\n uri: 'https://example.com/my-collection.json',\n plugins: [\n {\n type: \"PermanentFreezeDelegate\",\n frozen: true,\n authority: { type: \"UpdateAuthority\"}\n },\n {\n type: \"AppData\",\n dataAuthority: { type: \"UpdateAuthority\"},\n schema: ExternalPluginAdapterSchema.Binary,\n } \n ]\n}).sendAndConfirm(umi)\nconst signature = base58.deserialize(tx.signature)[0]\nNote: Refer to the documentation if you're not sure on what fields and plugin to use!Full Code Exampleimport { \n createCollection,\n mplCore,\n} from '@metaplex-foundation/mpl-core'\nimport {\n createGenericFile,\n generateSigner,\n signerIdentity,\n sol,\n} from '@metaplex-foundation/umi'\nimport { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\nimport { base58 } from '@metaplex-foundation/umi/serializers'\nimport fs from 'fs'\nimport path from 'path'\nconst createCollection = async () => {\n //\n // ** Setting Up Umi **\n //\n const umi = createUmi('https://api.devnet.solana.com')\n .use(mplCore())\n .use(irysUploader({address: 'https://devnet.irys.xyz'}))\n const signer = generateSigner(umi)\n umi.use(signerIdentity(signer))\n\n console.log('Airdropping 1 SOL to identity')\n await umi.rpc.airdrop(umi.identity.publicKey, sol(1))\n //\n // ** Upload an image to Arweave **\n //\n const imageFile = fs.readFileSync(\n path.join(__dirname, '..', '/assets/my-image.jpg')\n )\n const umiImageFile = createGenericFile(imageFile, 'my-image.jpeg', {\n tags: [{ name: 'Content-Type', value: 'image/jpeg' }],\n })\n const imageUri = await umi.uploader.upload([umiImageFile]).catch((err) => {\n throw new Error(err)\n })\n console.log('imageUri: ' + imageUri[0])\n //\n // ** Upload Metadata to Arweave **\n //\n const metadata = {\n name: 'My Collection',\n description: 'This is a Collection on Solana',\n image: imageUri[0],\n external_url: 'https://example.com',\n properties: {\n files: [\n {\n uri: imageUri[0],\n type: 'image/jpeg',\n },\n ],\n category: 'image',\n },\n }\n console.log('Uploading Metadata...')\n const metadataUri = await umi.uploader.uploadJson(metadata).catch((err) => {\n throw new Error(err)\n })\n //\n // ** Creating the Collection **\n //\n const collection = generateSigner(umi)\n console.log('Creating Collection...')\n const tx = await createCollection(umi, {\n collection,\n name: 'My Collection',\n uri: metadataUri,\n }).sendAndConfirm(umi)\n const signature = base58.deserialize(tx.signature)[0]\n console.log('\\Collection Created')\n console.log('View Transaction on Solana Explorer')\n console.log(`https://explorer.solana.com/tx/${signature}?cluster=devnet`)\n console.log('\\n')\n console.log('View NFT on Metaplex Explorer')\n console.log(`https://core.metaplex.com/explorer/${nftSigner.publicKey}?env=devnet`)\n}\ncreateCollection()","tokens":2733,"squid":"dotcat","role":"Tooling Spider","at":1791344233166,"hash":"8b59a2db26e4748c05bb2a978b7031637a027f22"}
{"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:Which risk comes from a bridge being trusted rather than trustless?","tokens":2204,"squid":"spider-05","role":"Spec Spider","at":1791344239747,"hash":"48527efd56bc35aa13fa8d83d83df7ebfb4ac8aa"}
{"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.055Market share$332B$0.055$332BBaseAvg. transaction fee$0.002Market share$16.4B$0.002$16.4BArbitrum OneAvg. transaction fee$0.004Market share$11.6B$0.004$11.6BOptimismAvg. transaction fee$0.00Market share$2.03B$0.00$2.03BStarknetAvg. transaction fee$0.008Market share$509M$0.008$509MInkAvg. transaction fee$0.00Market share$421M$0.00$421MUnichainAvg. transaction fee$0.00Market share$93.9M$0.00$93.9MZKSync EraAvg. transaction fee-Market share$278M-$278MScrollAvg. transaction fee$0.003Market share$48.9M$0.003$48.9MLineaAvg. transaction fee$0.019Market share$381M$0.019$381MZircuitAvg. transaction fee-Market share$12.6M-$12.6MLooking 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":"spider-05","role":"Spec Spider","at":1791344253311,"hash":"50d57e6d3dac9e6d2ed1564c5bb39882ed2d4ba2"}
{"url":"https://ethereum.org/developers/tools/categories/education-standards/","domain":"ethereum.org","title":"Education & standards | Developer builder resources | ⁦ethereum.org⁩","text":"Resources 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.","tokens":747,"squid":"spider-05","role":"Spec Spider","at":1791344263395,"hash":"4dff9fe79cbf751f85a9ec012114d12f9fa76d33"}
{"url":"https://developers.jup.ag/docs/ultra/add-fees-to-ultra","domain":"developers.jup.ag","title":"Add Integrator Fees - Jupiter Developers","text":"Ultra Swap API is no longer actively maintained and has been superseded by Swap V2.\nIf you are unfamiliar with Ultra Swap Fees, please refer to the doc.\n​Key Points\nThe Jupiter Ultra Swap API allows you to add integrator fees to the orders.\nKey points summary: Fees require Referral Program accounts, Jupiter takes 20% of your integrator fees, Ultra decides which mint to take fees in (based on a priority list), you must create referralTokenAccount for each expected feeMint, and fees enforce routing to Metis only.\nRequires specific Referral Program AccountsThe Ultra Swap Integrator Fees are governed by the Referral Program.It is required to create a valid referral account and it’s referral token accounts for the specific token mints to collect fees in. These accounts are initalized under the Jupiter Ultra Referral Project.Refer to the rest of the guide for more details on the set up.Fee split when adding feesIf you plan to take 100bps, Jupiter will take 20bps for the fee split (there will be no Ultra base fee).TypeFeeUltra default fees5 to 10 bpsAdded integrator feesUltra takes 20% of your integrator feesUltra decides which mint to take fees inIn the /order response, you will see the feeMint field which is the token mint we will collect the fees in for that particular order.Since Jupiter will always dictate which token mint to collect the fees in, you must ensure that you have the valid referral token account created for the specific fee mint.The feeMint is based on a priority list, you can refer to the Ultra Fees doc for more details.inputMintoutputMintfeeMintReasonSOLUSDCSOLSOL is of highest priorityUSDCSOLSOLSOL is of highest priority, regardless of sideMEMEUSDCUSDCStablecoin (USDC) has higher priorityIf the referralTokenAccount for the feeMint is not initialized, the order will still return and can be executed without your fees. This is to ensure your user still receives a quote to proceed with the swap.For example, if the feeMint is SOL, but the referralTokenAccount for SOL is not initialized, the order will still return but will be executed without your fees.You can refer to if feeBps tallies with what you specified in referralFee, in this case, the feeBps will default to Jupiter Ultra’s default fees.Check the feeBps fieldYou can configure referralFee to be between 50bps to 255bps. The /order response will show the total fee in feeBps field which should be exactly what you specified in referralFee.If the referralTokenAccount for the feeMint is not initialized, the order will still return and can be executed without your fees. This is to ensure your user still receives a quote to proceed with the swap.For example, if the feeMint is SOL, but the referralTokenAccount for SOL is not initialized, the order will still return but will be executed without your fees.You can refer to if feeBps tallies with what you specified in referralFee, in this case, the feeBps will default to Jupiter Ultra’s default fees.Token supportYou can now take fees in SPL or Token2022 tokens. As long as you have the referral token account initialized before calling /order, and the feeMint is one of the token mints you have initialized for, your fees will apply.Only initialized for this token mintfeeMintAre your fees applied?SOLSOLYesUSDCJupSOLNoXYZUSDCNoEnforces routing to Metis and other DEX aggregator routesWhen integrator fees are being added, it defaults routing to Metis and other DEX aggregator routes.JupiterZ does not support integrator fees currently.\n​Step-by-step\n1Install additional dependencies or if you prefer, you can use the Referral Dashboard, a simple interface to create referral accounts.2Create referralAccount.3Create referralTokenAccount for each token mint.4Add referralAccount and referralFee to Ultra Swap /order endpoint.5Sign and send the transaction via Ultra Swap /execute endpoint.6Verify transaction and fees.\nFull Code Exampleimport { ReferralProvider } from \"@jup-ag/referral-sdk\";\nimport { Connection, Keypair, PublicKey, sendAndConfirmTransaction, sendAndConfirmRawTransaction } from \"@solana/web3.js\";\nimport fs from 'fs';\n\nconst connection = new Connection(\"https://api.mainnet-beta.solana.com\");\nconst privateKeyArray = JSON.parse(fs.readFileSync('/Path/to/.config/solana/id.json', 'utf8').trim());\nconst wallet = Keypair.fromSecretKey(new Uint8Array(privateKeyArray));\n\nconst provider = new ReferralProvider(connection);\nconst projectPubKey = new PublicKey('DkiqsTrw1u1bYFumumC7sCG2S8K25qc2vemJFHyW2wJc');\n\nasync function initReferralAccount() {\n const transaction = await provider.initializeReferralAccountWithName({\n payerPubKey: wallet.publicKey,\n partnerPubKey: wallet.publicKey,\n projectPubKey: projectPubKey,\n name: \"insert-name-here\",\n });\n\n const referralAccount = await connection.getAccountInfo(\n transaction.referralAccountPubKey,\n );\n\n if (!referralAccount) {\n const signature = await sendAndConfirmTransaction(connection, transaction.tx, [wallet]);\n console.log('signature:', `https://solscan.io/tx/${signature}`);\n console.log('created referralAccountPubkey:', transaction.referralAccountPubKey.toBase58());\n } else {\n console.log(\n `referralAccount ${transaction.referralAccountPubKey.toBase58()} already exists`,\n );\n }\n}\n\nasync function initReferralTokenAccount() {\n const mint = new PublicKey(\"So11111111111111111111111111111111111111112\"); // the token mint you want to collect fees in\n\n const transaction = await provider.initializeReferralTokenAccountV2({\n payerPubKey: wallet.publicKey,\n referralAccountPubKey: new PublicKey(\"insert-referral-account-pubkey-here\"), // you get this from the initReferralAccount function\n mint,\n });\n\n const referralTokenAccount = await connection.getAccountInfo(\n transaction.tokenAccount,\n );\n\n if (!referralTokenAccount) {\n const signature = await sendAndConfirmTransaction(connection, transaction.tx, [wallet]);\n console.log('signature:', `https://solscan.io/tx/${signature}`);\n console.log('created referralTokenAccountPubKey:', transaction.tokenAccount.toBase58());\n console.log('mint:', mint.toBase58());\n } else {\n console.log(\n `referralTokenAccount ${transaction.tokenAccount.toBase58()} for mint ${mint.toBase58()} already exists`,\n );\n }\n}\n\nasync function claimAllTokens() {\n const transactions = await provider.claimAllV2({\n payerPubKey: wallet.publicKey,\n referralAccountPubKey: new PublicKey(\"insert-referral-account-pubkey-here\"),\n })\n\n // Send each claim transaction one by one.\n for (const transaction of transactions) {\n transaction.sign([wallet]);\n\n const signature = await sendAndConfirmRawTransaction(connection, transaction.serialize(), [wallet]);\n console.log('signature:', `https://solscan.io/tx/${signature}`);\n }\n}\n\n// initReferralAccount(); // you should only run this once\n// initReferralTokenAccount();\n// claimAllTokens();\n\n​Dependencies\nnpm install @jup-ag/referral-sdk\nnpm install @solana/web3.js@1 # Using v1 of web3.js instead of v2\n\nRPC Connection and Wallet SetupSet up RPC ConnectionSolana provides a default RPC endpoint. However, as your application grows, we recommend you to always use your own or provision a 3rd party provider’s RPC endpoint such as Helius or Triton.const connection = new Connection('https://api.mainnet-beta.solana.com');\nSet up Development WalletYou can paste in your private key for testing but this is not recommended for production.\nEither use your private key in the project directly, you can do it via a .env file.\nOr set up your private key in the Solana CLI.\n// In your .env file\nPRIVATE_KEY=\"\"\n\n// In your index.js (or any file that needs the private key)\nimport { Keypair } from '@solana/web3.js';\nimport dotenv from 'dotenv';\nrequire('dotenv').config();\n\nconst wallet = Keypair.fromSecretKey(bs58.decode(process.env.PRIVATE_KEY || '')));\nimport { Keypair } from '@solana/web3.js';\nimport fs from 'fs';\n\nconst privateKeyArray = JSON.parse(fs.readFileSync('/Path/to/.config/solana/id.json', 'utf8').trim());\nconst wallet = Keypair.fromSecretKey(new Uint8Array(privateKeyArray));\n\n​Create referralAccount\n\nYou should only need to create the referral account once.\nAfter this step, you need to create the referral token accounts for each token mint.\n\nimport { ReferralProvider } from \"@jup-ag/referral-sdk\";\nimport { Connection, Keypair, PublicKey, sendAndConfirmTransaction } from \"@solana/web3.js\";\n\nconst connection = new Connection(\"https://api.mainnet-beta.solana.com\");\nconst privateKeyArray = JSON.parse(fs.readFileSync('/Path/to/.config/solana/id.json', 'utf8').trim());\nconst wallet = Keypair.fromSecretKey(new Uint8Array(privateKeyArray));\nconst provider = new ReferralProvider(connection);\nconst projectPubKey = new PublicKey('DkiqsTrw1u1bYFumumC7sCG2S8K25qc2vemJFHyW2wJc'); // Jupiter Ultra Referral Project\n\nasync function initReferralAccount() {\n const transaction = await provider.initializeReferralAccountWithName({\n payerPubKey: wallet.publicKey,\n partnerPubKey: wallet.publicKey,\n projectPubKey: projectPubKey,\n name: \"insert-name-here\",\n });\n\n const referralAccount = await connection.getAccountInfo(\n transaction.referralAccountPubKey,\n );\n\n if (!referralAccount) {\n const signature = await sendAndConfirmTransaction(connection, transaction.tx, [wallet]);\n console.log('signature:', `https://solscan.io/tx/${signature}`);\n console.log('created referralAccountPubkey:', transaction.referralAccountPubKey.toBase58());\n } else {\n console.log(\n `referralAccount ${transaction.referralAccountPubKey.toBase58()} already exists`,\n );\n }\n}\n\n​Create referralTokenAccount\n\nYou need to create the referralAccount first.\nYou need to create a referralTokenAccount for each token mint you want to collect fees in.\nWe don’t recommend creating a token account for every token mint, as it costs rent and most tokens might not be valuable, instead created token accounts for top mints to begin with (you can always add more later).\n\nimport { ReferralProvider } from \"@jup-ag/referral-sdk\";\nimport { Connection, Keypair, PublicKey, sendAndConfirmTransaction } from \"@solana/web3.js\";\n\nconst connection = new Connection(\"https://api.mainnet-beta.solana.com\");\nconst privateKeyArray = JSON.parse(fs.readFileSync('/Path/to/.config/solana/id.json', 'utf8').trim());\nconst wallet = Keypair.fromSecretKey(new Uint8Array(privateKeyArray));\nconst provider = new ReferralProvider(connection);\n\nasync function initReferralTokenAccount() {\n const mint = new PublicKey(\"So11111111111111111111111111111111111111112\"); // the token mint you want to collect fees in\n\n const transaction = await provider.initializeReferralTokenAccountV2({\n payerPubKey: wallet.publicKey,\n referralAccountPubKey: new PublicKey(\"insert-referral-account-pubkey-here\"),\n mint,\n });\n\n const referralTokenAccount = await connection.getAccountInfo(\n transaction.tokenAccount,\n );\n\n if (!referralTokenAccount) {\n const signature = await sendAndConfirmTransaction(connection, transaction.tx, [wallet]);\n console.log('signature:', `https://solscan.io/tx/${signature}`);\n console.log('created referralTokenAccountPubKey:', transaction.tokenAccount.toBase58());\n console.log('mint:', mint.toBase58());\n } else {\n console.log(\n `referralTokenAccount ${transaction.tokenAccount.toBase58()} for mint ${mint.toBase58()} already exists`,\n );\n }\n}\n\n​Usage in Ultra Swap\n\nAfter creating the necessary accounts, you can now add the referralAccount and referralFee to the Ultra Swap /order endpoint.\nFrom the order response, you should see the feeMint field, which is the token mint we will collect the fees in for that particular order.\nFrom the order response, you should see the feeBps field, which is the total fee in bps, which should be exactly what you specified in referralFee.\nThen, you can sign and send the transaction via the Ultra Swap /execute endpoint.\n\nIf the referralTokenAccount for the feeMint is not initialized, the order will still return and can be executed without your fees. This is to ensure your user still receives a quote to proceed with the swap.For example, if the feeMint is SOL, but the referralTokenAccount for SOL is not initialized, the order will still return but will be executed without your fees.You can refer to if feeBps tallies with what you specified in referralFee, in this case, the feeBps will default to Jupiter Ultra’s default fees.\nimport { Keypair, VersionedTransaction } from \"@solana/web3.js\";\nimport fs from 'fs';\n\nconst privateKeyArray = JSON.parse(fs.readFileSync('/Path/to/.config/solana/id.json', 'utf8').trim());\nconst wallet = Keypair.fromSecretKey(new Uint8Array(privateKeyArray));\n\nconst orderResponse = await (\n await fetch(\n 'https://api.jup.ag/ultra/v1/order?' +\n 'inputMint=So11111111111111111111111111111111111111112&' +\n 'outputMint=EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v&' +\n 'amount=100000000&' +\n 'taker=jdocuPgEAjMfihABsPgKEvYtsmMzjUHeq9LX4Hvs7f3&' +\n 'referralAccount=&' + // insert referral account public key here\n 'referralFee=50', // insert referral fee in basis points (bps)\n {\n headers: {\n 'x-api-key': 'your-api-key',\n },\n }\n )\n).json();\n\nconsole.log(JSON.stringify(orderResponse, null, 2));\n\nconst transactionBase64 = orderResponse.transaction // Extract the transaction from the order response\nconst transaction = VersionedTransaction.deserialize(Buffer.from(transactionBase64, 'base64')); // Deserialize the transaction\ntransaction.sign([wallet]); // Sign the transaction\nconst signedTransaction = Buffer.from(transaction.serialize()).toString('base64'); // Serialize the transaction to base64 format\n\nconst executeResponse = await (\n await fetch('https://api.jup.ag/ultra/v1/execute', {\n method: 'POST',\n headers: {\n 'Content-Type': 'application/json',\n 'x-api-key': 'your-api-key',\n },\n body: JSON.stringify({\n signedTransaction: signedTransaction,\n requestId: orderResponse.requestId,\n }),\n })\n).json();\n\nif (executeResponse.status === \"Success\") {\n console.log('Swap successful:', JSON.stringify(executeResponse, null, 2));\n console.log(`https://solscan.io/tx/${executeResponse.signature}`);\n} else {\n console.error('Swap failed:', JSON.stringify(executeResponse, null, 2));\n console.log(`https://solscan.io/tx/${executeResponse.signature}`);\n}\n\n​Claim All Fees\n\nThe claimAllV2 method will return a list of transactions to claim all fees and are batched by 5 claims for each transaction.\nThe code signs and sends the transactions one by one - you can also Jito Bundle to send multiple at once, if preferred.\nWhen claiming fees, the transaction will include the transfer of the fees to both your referral account and Jupiter’s (20% of your integrator fees).\n\nimport { ReferralProvider } from \"@jup-ag/referral-sdk\";\nimport { Connection, Keypair, PublicKey, sendAndConfirmRawTransaction } from \"@solana/web3.js\";\n\nconst connection = new Connection(\"https://api.mainnet-beta.solana.com\");\nconst privateKeyArray = JSON.parse(fs.readFileSync('/Path/to/.config/solana/id.json', 'utf8').trim());\nconst wallet = Keypair.fromSecretKey(new Uint8Array(privateKeyArray));\nconst provider = new ReferralProvider(connection);\n\nasync function claimAllTokens() {\n const transactions = await provider.claimAllV2({\n payerPubKey: wallet.publicKey,\n referralAccountPubKey: new PublicKey(\"insert-referral-account-pubkey-here\"),\n })\n\n // Send each claim transaction one by one.\n for (const transaction of transactions) {\n transaction.sign([wallet]);\n\n const signature = await sendAndConfirmRawTransaction(connection, transaction.serialize(), [wallet]);\n console.log('signature:', `https://solscan.io/tx/${signature}`);\n }\n}\nWas this page helpful?","tokens":3865,"squid":"spider-02","role":"Liquidity Spider","at":1791344267191,"hash":"4ff01017b54951dc8a937140b06d5789a5ca749f"}
{"url":"https://docs.phantom.com/recipes/quickstarts/react-native","domain":"docs.phantom.com","title":"React Native - Phantom developer documentation","text":"Complete guide to integrating Phantom Connect in a React Native app.\n​1. Install dependencies\nnpm install @phantom/react-native-sdk @solana/web3.js\n\n# Required polyfill for cryptographic operations\nnpm install react-native-get-random-values\n\n# Install peer dependencies\nnpx expo install expo-secure-store expo-web-browser expo-auth-session react-native-svg\n\nIf you’re using Expo, use npx expo install to ensure compatibility. For bare React Native projects, you can install the packages directly with npm.\n​2. Configure app scheme\nAdd your custom scheme to app.json:\n{\n \"expo\": {\n \"name\": \"My App\",\n \"slug\": \"my-app\",\n \"scheme\": \"myapp\",\n \"plugins\": [\n \"expo-router\",\n \"expo-secure-store\",\n \"expo-web-browser\",\n \"expo-auth-session\"\n ]\n }\n}\n\nFor bare React Native projects, configure deep linking in your native project files. See React Native deep linking documentation for details.\n​3. Create the app entry point\nThe polyfill must be the first import:\nThe react-native-get-random-values import must be the very first import in your app’s entry point, before any other imports.\n​With Expo Router\n// app/_layout.tsx\nimport \"react-native-get-random-values\"; // Must be first!\n\nimport { Stack } from \"expo-router\";\nimport { PhantomProvider, AddressType, darkTheme } from \"@phantom/react-native-sdk\";\n\nexport default function Layout() {\n return (\n <PhantomProvider\n config={{\n providers: [\"google\", \"apple\"],\n appId: \"your-app-id\", // Get from phantom.com/portal\n scheme: \"myapp\",\n addressTypes: [AddressType.solana],\n authOptions: {\n redirectUrl: \"myapp://phantom-auth-callback\",\n },\n }}\n theme={darkTheme}\n appName=\"My App\"\n >\n <Stack />\n </PhantomProvider>\n );\n}\n\n​Without Expo Router\n// App.tsx or index.js\nimport \"react-native-get-random-values\"; // Must be first!\n\nimport React from \"react\";\nimport { PhantomProvider, AddressType, darkTheme } from \"@phantom/react-native-sdk\";\nimport { WalletScreen } from \"./WalletScreen\";\n\nexport default function App() {\n return (\n <PhantomProvider\n config={{\n providers: [\"google\", \"apple\"],\n appId: \"your-app-id\", // Get from phantom.com/portal\n scheme: \"myapp\",\n addressTypes: [AddressType.solana],\n authOptions: {\n redirectUrl: \"myapp://phantom-auth-callback\",\n },\n }}\n theme={darkTheme}\n appName=\"My App\"\n >\n <WalletScreen />\n </PhantomProvider>\n );\n}\n\n​4. Create the wallet screen\n// WalletScreen.tsx\nimport React from \"react\";\nimport { View, Text, Button, StyleSheet, Alert } from \"react-native\";\nimport {\n useModal,\n usePhantom,\n useAccounts,\n useDisconnect,\n useSolana,\n} from \"@phantom/react-native-sdk\";\n\nexport function WalletScreen() {\n const { open } = useModal();\n const { isConnected } = usePhantom();\n const addresses = useAccounts();\n const { disconnect } = useDisconnect();\n const { solana } = useSolana();\n\n if (isConnected && addresses) {\n return (\n <View style={styles.container}>\n <Text style={styles.title}>Wallet Connected</Text>\n <Text style={styles.address}>{addresses[0]?.address}</Text>\n <Button\n title=\"Sign Message\"\n onPress={async () => {\n try {\n const { signature } = await solana.signMessage(\"Hello!\");\n Alert.alert(\"Success\", `Signature: ${signature.slice(0, 10)}...`);\n } catch (error) {\n Alert.alert(\"Error\", error instanceof Error ? error.message : \"Failed to sign\");\n }\n }}\n />\n <Button\n title=\"Disconnect\"\n onPress={() => disconnect()}\n />\n </View>\n );\n }\n\n return (\n <View style={styles.container}>\n <Text style={styles.title}>Welcome</Text>\n <Button title=\"Connect Wallet\" onPress={open} />\n </View>\n );\n}\n\nconst styles = StyleSheet.create({\n container: {\n flex: 1,\n justifyContent: \"center\",\n alignItems: \"center\",\n padding: 20,\n },\n title: {\n fontSize: 24,\n marginBottom: 20,\n fontWeight: \"bold\",\n },\n address: {\n fontSize: 14,\n marginBottom: 20,\n color: \"#666\",\n },\n});\n\n​5. Configure Phantom Portal\nPhantom Portal is not accepting new applications at this time. New sign-ups for Phantom Connect SDK access and new app submissions to the Phantom app directory are paused. Existing Portal apps and App IDs are not affected.\n\nGo to phantom.com/portal\nSelect an existing app\nAdd your redirect URL (e.g., myapp://phantom-auth-callback) to redirect URLs\nCopy your App ID\nWas this page helpful?","tokens":1043,"squid":"spider-10","role":"Tooling Spider","at":1791344273789,"hash":"a39dad264897fcba0d0acef1af445415531627b8"}
{"url":"https://developers.jup.ag/docs/get-started/environment-setup","domain":"developers.jup.ag","title":"Environment Setup - Jupiter Developers","text":"​Libraries\nInstall @solana/web3.js (v1) for transaction handling and @solana/spl-token for SPL token operations:\nnpm install @solana/web3.js@1 @solana/spl-token bs58\n\nThis documentation uses @solana/web3.js v1. Version 2 has a different API for transaction handling.\n​RPC Connection\nimport { Connection } from '@solana/web3.js';\n\nconst connection = new Connection('https://api.mainnet-beta.solana.com');\n\nSolana provides a default RPC endpoint, but as your application grows, use a dedicated provider like Helius or Triton.\n​Development Wallet\nNever hardcode private keys in source code. Use environment variables or the Solana CLI keyfile.\nimport { Keypair } from '@solana/web3.js';\nimport bs58 from 'bs58';\nimport 'dotenv/config';\n\nconst wallet = Keypair.fromSecretKey(bs58.decode(process.env.PRIVATE_KEY));\nimport { Keypair } from '@solana/web3.js';\nimport fs from 'fs';\n\nconst privateKeyArray = JSON.parse(\n fs.readFileSync('/Path/to/.config/solana/id.json', 'utf8').trim()\n);\nconst wallet = Keypair.fromSecretKey(new Uint8Array(privateKeyArray));\nWas this page helpful?","tokens":269,"squid":"spider-02","role":"Liquidity Spider","at":1791344277275,"hash":"bec638ef5636ac990e06b624d10b9dc93266ea82"}
{"url":"https://consensysdiligence.github.io/smart-contract-best-practices/development-recommendations/solidity-specific/assert-require-revert/","domain":"consensysdiligence.github.io","title":"Assert, Require, Revert - Ethereum Smart Contract Best Practices","text":"Assert, Require, Revert\n\nTip\nFor comprehensive insights into secure development practices, consider visiting the Development Recommendations section of the Smart Contract Security Field Guide. This resource provides in-depth articles to guide you in developing robust and secure smart contracts.\n\nEnforce invariants with assert()¶\nAn assert guard triggers when an assertion fails - such as an invariant property changing. For\nexample, the token to ether issuance ratio, in a token issuance contract, may be fixed. You can\nverify that this is the case at all times with an assert(). Assert guards should often be\ncombined with other techniques, such as pausing the contract and allowing upgrades. (Otherwise, you\nmay end up stuck, with an assertion that is always failing.)\nExample:\ncontract Token {\n mapping(address => uint) public balanceOf;\n uint public totalSupply;\n\n function deposit() public payable {\n balanceOf[msg.sender] += msg.value;\n totalSupply += msg.value;\n assert(address(this).balance >= totalSupply);\n }\n}\n\nNote that the assertion is not a strict equality of the balance because the contract can be\nforcibly sent ether without going\nthrough the deposit() function!\nUse assert(), require(), revert() properly¶\n\nInfo\nThe convenience functions assert and require can be used to check for conditions and throw an exception if the condition is not met.\n\nThe assert function should only be used to test for internal errors, and to check invariants.\nThe require function should be used to ensure valid conditions, such as inputs, or contract state variables are met, or to validate return values from calls to external contracts.\nFollowing this paradigm allows formal analysis tools to verify that the invalid opcode can never be\nreached: meaning no invariants in the code are violated and that the code is formally verified.\npragma solidity ^0.5.0;\n\ncontract Sharer {\n function sendHalf(address payable addr) public payable returns (uint balance) {\n require(msg.value % 2 == 0, \"Even value required.\"); //Require() can have an optional message string\n uint balanceBeforeTransfer = address(this).balance;\n (bool success, ) = addr.call.value(msg.value / 2)(\"\");\n require(success);\n // Since we reverted if the transfer failed, there should be\n // no way for us to still have half of the money.\n assert(address(this).balance == balanceBeforeTransfer - msg.value / 2); // used for internal error checking\n return address(this).balance;\n }\n}\n\nSee SWC-110 & SWC-123","tokens":618,"squid":"spider-06","role":"Security Spider","at":1791344280861,"hash":"26967a465c7b570b876d21f51c6aec1f28e085a6"}
{"url":"https://docs.phantom.com/recipes/transactions/add-priority-fees","domain":"docs.phantom.com","title":"Add priority fees - Phantom developer documentation","text":"Add priority fees to your transactions to ensure faster confirmation during network congestion. Phantom automatically applies priority fees, but you can also set them manually.\n React Browser SDK React Nativeimport { useSolana } from \"@phantom/react-sdk\";\nimport {\n Connection,\n PublicKey,\n VersionedTransaction,\n TransactionMessage,\n SystemProgram,\n LAMPORTS_PER_SOL,\n ComputeBudgetProgram,\n} from \"@solana/web3.js\";\n\nfunction SendWithPriorityFees() {\n const { solana } = useSolana();\n\n const sendWithPriorityFees = async (\n to: string,\n amount: number,\n priorityFee: number = 1000 // micro-lamports per compute unit\n ) => {\n const connection = new Connection(\"https://api.mainnet-beta.solana.com\");\n const { blockhash } = await connection.getLatestBlockhash();\n const from = new PublicKey(await solana.getPublicKey());\n const recipient = new PublicKey(to);\n\n // Create transfer instruction\n const transferInstruction = SystemProgram.transfer({\n fromPubkey: from,\n toPubkey: recipient,\n lamports: amount * LAMPORTS_PER_SOL,\n });\n\n // Add priority fee instructions\n const instructions = [\n // Set compute unit limit (optional, defaults to 200,000)\n ComputeBudgetProgram.setComputeUnitLimit({ units: 200_000 }),\n // Set compute unit price (priority fee)\n ComputeBudgetProgram.setComputeUnitPrice({ microLamports: priorityFee }),\n transferInstruction,\n ];\n\n const transaction = new VersionedTransaction(\n new TransactionMessage({\n payerKey: from,\n recentBlockhash: blockhash,\n instructions,\n }).compileToV0Message()\n );\n\n const { signature } = await solana.signAndSendTransaction(transaction);\n return signature;\n };\n\n return (\n <button onClick={() => sendWithPriorityFees(\"RECIPIENT_ADDRESS\", 0.1, 5000)}>\n Send with Priority Fee\n </button>\n );\n}\nimport { BrowserSDK, AddressType } from \"@phantom/browser-sdk\";\nimport {\n Connection,\n PublicKey,\n VersionedTransaction,\n TransactionMessage,\n SystemProgram,\n LAMPORTS_PER_SOL,\n ComputeBudgetProgram,\n} from \"@solana/web3.js\";\n\nconst sdk = new BrowserSDK({\n providers: [\"google\", \"apple\", \"injected\"],\n appId: \"your-app-id\",\n addressTypes: [AddressType.solana],\n});\n\nasync function sendWithPriorityFees(\n to: string,\n amount: number,\n priorityFee: number = 1000\n) {\n const connection = new Connection(\"https://api.mainnet-beta.solana.com\");\n const { blockhash } = await connection.getLatestBlockhash();\n const from = new PublicKey(await sdk.solana.getPublicKey());\n const recipient = new PublicKey(to);\n\n const transferInstruction = SystemProgram.transfer({\n fromPubkey: from,\n toPubkey: recipient,\n lamports: amount * LAMPORTS_PER_SOL,\n });\n\n const instructions = [\n ComputeBudgetProgram.setComputeUnitLimit({ units: 200_000 }),\n ComputeBudgetProgram.setComputeUnitPrice({ microLamports: priorityFee }),\n transferInstruction,\n ];\n\n const transaction = new VersionedTransaction(\n new TransactionMessage({\n payerKey: from,\n recentBlockhash: blockhash,\n instructions,\n }).compileToV0Message()\n );\n\n const { signature } = await sdk.solana.signAndSendTransaction(transaction);\n return signature;\n}\nimport { useSolana } from \"@phantom/react-native-sdk\";\nimport {\n Connection,\n PublicKey,\n VersionedTransaction,\n TransactionMessage,\n SystemProgram,\n LAMPORTS_PER_SOL,\n ComputeBudgetProgram,\n} from \"@solana/web3.js\";\nimport { View, Button, Alert, StyleSheet } from \"react-native\";\n\nfunction SendWithPriorityFees() {\n const { solana } = useSolana();\n\n const sendWithPriorityFees = async (\n to: string,\n amount: number,\n priorityFee: number = 1000\n ) => {\n try {\n const connection = new Connection(\"https://api.mainnet-beta.solana.com\");\n const { blockhash } = await connection.getLatestBlockhash();\n const from = new PublicKey(await solana.getPublicKey());\n const recipient = new PublicKey(to);\n\n const transferInstruction = SystemProgram.transfer({\n fromPubkey: from,\n toPubkey: recipient,\n lamports: amount * LAMPORTS_PER_SOL,\n });\n\n const instructions = [\n ComputeBudgetProgram.setComputeUnitLimit({ units: 200_000 }),\n ComputeBudgetProgram.setComputeUnitPrice({ microLamports: priorityFee }),\n transferInstruction,\n ];\n\n const transaction = new VersionedTransaction(\n new TransactionMessage({\n payerKey: from,\n recentBlockhash: blockhash,\n instructions,\n }).compileToV0Message()\n );\n\n const { signature } = await solana.signAndSendTransaction(transaction);\n Alert.alert(\"Success\", `Transaction sent: ${signature}`);\n return signature;\n } catch (error) {\n Alert.alert(\"Error\", error instanceof Error ? error.message : \"Transaction failed\");\n throw error;\n }\n };\n\n return (\n <View style={styles.container}>\n <Button\n title=\"Send with Priority Fee\"\n onPress={() => sendWithPriorityFees(\"RECIPIENT_ADDRESS\", 0.1, 5000)}\n />\n </View>\n );\n}\n\nconst styles = StyleSheet.create({\n container: {\n padding: 20,\n },\n});\n\n​Priority fee recommendations\nPriority fees are measured in micro-lamports per compute unit. Common values:\n\nLow priority: 1,000 - 5,000 micro-lamports (for non-urgent transactions)\nMedium priority: 5,000 - 25,000 micro-lamports (standard transactions)\nHigh priority: 25,000+ micro-lamports (urgent transactions during congestion)\n\nAutomatic priority fees: If you don’t add priority fee instructions, Phantom will automatically calculate and apply appropriate priority fees to your transaction, provided it meets certain requirements.\n​Dynamic priority fee calculation\nCalculate priority fees based on recent network activity:\nimport { Connection } from \"@solana/web3.js\";\n\nasync function getRecommendedPriorityFee(connection: Connection): Promise<number> {\n // Get recent priority fee samples\n const feeSample = await connection.getRecentPrioritizationFees();\n\n if (feeSample.length === 0) {\n return 1000; // Default fallback\n }\n\n // Calculate median priority fee\n const fees = feeSample.map((sample) => sample.prioritizationFee);\n fees.sort((a, b) => a - b);\n const median = fees[Math.floor(fees.length / 2)];\n\n // Add 20% buffer for safety\n return Math.ceil(median * 1.2);\n}\nWas this page helpful?","tokens":1488,"squid":"spider-10","role":"Tooling Spider","at":1791344283708,"hash":"954adb9ed02bc3dde07718901727e23b6c55f4d2"}
{"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":"spider-08","role":"Oracle Spider","at":1791344290143,"hash":"65307ec8b80799f8cf69fa03e644664eac0ef251"}
{"url":"https://consensysdiligence.github.io/smart-contract-best-practices/development-recommendations/general/negative-int/","domain":"consensysdiligence.github.io","title":"Negation of Signed Integers - Ethereum Smart Contract Best Practices","text":"Negation of Signed Integers\n\nTip\nFor comprehensive insights into secure development practices, consider visiting the Development Recommendations section of the Smart Contract Security Field Guide. This resource provides in-depth articles to guide you in developing robust and secure smart contracts.\n\nSolidity provides several types to work with signed integers. Like in most programming languages,\nin Solidity a signed integer with N bits can represent values from -2^(N-1) to 2^(N-1)-1.\nThis means that there is no positive equivalent for the MIN_INT. Negation is implemented as\nfinding the two's complement of a number, so the negation of the most negative number\nwill result in the same number.\nThis is true for all signed integer types in Solidity (int8, int16, ..., int256).\ncontract Negation {\n function negate8(int8 _i) public pure returns(int8) {\n return -_i;\n }\n\n function negate16(int16 _i) public pure returns(int16) {\n return -_i;\n }\n\n int8 public a = negate8(-128); // -128\n int16 public b = negate16(-128); // 128\n int16 public c = negate16(-32768); // -32768\n}\n\nOne way to handle this is to check the value of a variable before negation and throw if it's equal\nto the MIN_INT. Another option is to make sure that the most negative number will never be\nachieved by using a type with a higher capacity (e.g. int32 instead of int16).\nA similar issue with int types occurs when MIN_INT is multiplied or divided by -1.","tokens":357,"squid":"spider-06","role":"Security Spider","at":1791344290829,"hash":"abbb2ad8a2f4a903045ba897059d82042e8d7c85"}
{"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":"spider-08","role":"Oracle Spider","at":1791344301324,"hash":"b21103b10bab2db373df72997ebb32065ad93826"}
{"url":"https://consensysdiligence.github.io/smart-contract-best-practices/development-recommendations/solidity-specific/integer-division/","domain":"consensysdiligence.github.io","title":"Integer Division - Ethereum Smart Contract Best Practices","text":"Integer Division\n\nTip\nFor comprehensive insights into secure development practices, consider visiting the Development Recommendations section of the Smart Contract Security Field Guide. This resource provides in-depth articles to guide you in developing robust and secure smart contracts.\n\nAll integer division rounds down to the nearest integer. If you need more precision, consider using\na multiplier, or store both the numerator and denominator.\n(In the future, Solidity will have a\nfixed-point type,\nwhich will make this easier.)\n// bad\nuint x = 5 / 2; // Result is 2, all integer division rounds DOWN to the nearest integer\n\nUsing a multiplier prevents rounding down, this multiplier needs to be accounted for when working\nwith x in the future:\n// good\nuint multiplier = 10;\nuint x = (5 * multiplier) / 2;\n\nStoring the numerator and denominator means you can calculate the result of numerator/denominator\noff-chain:\n// good\nuint numerator = 5;\nuint denominator = 2;","tokens":243,"squid":"spider-06","role":"Security Spider","at":1791344304264,"hash":"491eb64328c7b6adff65b9615d77c549e75f7428"}
{"url":"https://docs.phantom.com/recipes/quickstarts/vanilla-js","domain":"docs.phantom.com","title":"Vanilla JavaScript - Phantom developer documentation","text":"Complete guide to integrating Phantom Connect using plain JavaScript.\n​1. Install the Browser SDK\nnpm install @phantom/browser-sdk @solana/web3.js\n\n​2. Initialize the SDK\n// wallet.ts\nimport { BrowserSDK, AddressType } from \"@phantom/browser-sdk\";\n\n// These functions are defined in main.ts\ndeclare function updateUI(address: string): void;\ndeclare function showConnectButton(): void;\n\nexport const sdk = new BrowserSDK({\n providers: [\"google\", \"apple\", \"injected\"],\n appId: \"your-app-id\", // Get from phantom.com/portal\n addressTypes: [AddressType.solana],\n authOptions: {\n redirectUrl: \"https://yourapp.com/callback.html\",\n },\n});\n\n// Set up event listeners\nsdk.on(\"connect\", (data) => {\n console.log(\"Connected:\", data.addresses);\n updateUI(data.addresses[0].address);\n});\n\nsdk.on(\"disconnect\", () => {\n console.log(\"Disconnected\");\n showConnectButton();\n});\n\n// Try to restore existing session\nsdk.autoConnect();\n\n​3. Create the HTML\n<!-- index.html -->\n<!DOCTYPE html>\n<html>\n <head>\n <title>My App</title>\n </head>\n <body>\n <div id=\"app\">\n <div id=\"disconnected\">\n <h1>Welcome</h1>\n <button id=\"connect-google\">Continue with Google</button>\n <button id=\"connect-apple\">Continue with Apple</button>\n <button id=\"connect-extension\">Connect Phantom</button>\n </div>\n\n <div id=\"connected\" style=\"display: none;\">\n <p>Connected: <span id=\"address\"></span></p>\n <button id=\"sign\">Sign Message</button>\n <button id=\"disconnect\">Disconnect</button>\n </div>\n </div>\n\n <script type=\"module\" src=\"./main.ts\"></script>\n </body>\n</html>\n\n​4. Add the JavaScript\n// main.ts\nimport { sdk } from \"./wallet\";\n\n// Connect buttons\ndocument.getElementById(\"connect-google\")!.onclick = () => {\n sdk.connect({ provider: \"google\" });\n};\n\ndocument.getElementById(\"connect-apple\")!.onclick = () => {\n sdk.connect({ provider: \"apple\" });\n};\n\ndocument.getElementById(\"connect-extension\")!.onclick = () => {\n sdk.connect({ provider: \"injected\" });\n};\n\n// Sign message\ndocument.getElementById(\"sign\")!.onclick = async () => {\n const { signature } = await sdk.solana.signMessage(\"Hello!\");\n alert(\"Signature: \" + signature);\n};\n\n// Disconnect\ndocument.getElementById(\"disconnect\")!.onclick = () => {\n sdk.disconnect();\n};\n\n// UI helpers\nfunction updateUI(address: string) {\n document.getElementById(\"disconnected\")!.style.display = \"none\";\n document.getElementById(\"connected\")!.style.display = \"block\";\n document.getElementById(\"address\")!.textContent = address;\n}\n\nfunction showConnectButton() {\n document.getElementById(\"disconnected\")!.style.display = \"block\";\n document.getElementById(\"connected\")!.style.display = \"none\";\n}\n\n​5. Create the callback page\n<!-- callback.html -->\n<!DOCTYPE html>\n<html>\n <head>\n <title>Connecting...</title>\n </head>\n <body>\n <p>Connecting to Phantom...</p>\n <script type=\"module\">\n import { sdk } from \"./wallet\";\n // SDK handles the callback automatically\n // Redirect back to main page after connection\n sdk.on(\"connect\", () => {\n window.location.href = \"/\";\n });\n </script>\n </body>\n</html>\n\n​6. Configure Phantom Portal\nPhantom Portal is not accepting new applications at this time. New sign-ups for Phantom Connect SDK access and new app submissions to the Phantom app directory are paused. Existing Portal apps and App IDs are not affected.\n\nGo to phantom.com/portal\nSelect an existing app\nAdd your domain to allowed URLs\nAdd your callback URL to redirect URLs\nCopy your App ID\nWas this page helpful?","tokens":855,"squid":"spider-10","role":"Tooling Spider","at":1791344307059,"hash":"ff9f918813d7e4c6ac26ddb85991d27bed7eed6d"}
{"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":"spider-08","role":"Oracle Spider","at":1791344310530,"hash":"26f4fc755be35228c8519eb0c7d49657202d7c14"}
{"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":"spider-08","role":"Oracle Spider","at":1791344320547,"hash":"b88c983a45a74aa771a4fe99bce362f61dc9bb02"}
{"url":"https://www.metaplex.com/docs/smart-contracts/core/guides/javascript/how-to-create-a-core-nft-asset-with-javascript","domain":"metaplex.com","title":"How to Create a Core NFT Asset with Javascript | Core Guides","text":"This guide will demonstrate the use of the @metaplex-foundation/mpl-core Javascript SDK package to create a Core NFT Asset using the Metaplex Core onchain program.What is Core?Core uses a single account design, reducing minting costs and improving Solana network load compared to alternatives. It also has a flexible plugin system that allows for developers to modify the behavior and functionality of assets.But before starting, let's talk about Assets:What is an Asset?Setting itself apart from existing Asset programs, like Solana’s Token program, Metaplex Core and Core NFT Assets (sometimes referred to as Core NFT Assets) do not rely on multiple accounts, like Associated Token Accounts. Instead, Core NFT Assets store the relationship between a wallet and the \"mint\" account within the asset itself.PrerequisiteCode Editor of your choice (recommended Visual Studio Code)Node 18.x.x or above.Initial SetupThis guide will teach you how to create an NFT Core Asset with Javascript based on a single file script. You may need to modify and move functions around to suit your needs.InitializingStart by initializing a new project (optional) with the package manager of your choice (npm, yarn, pnpm, bun) and fill in required details when prompted.npm init\nRequired PackagesInstall the required packages for this guide.@metaplex-foundation/umi@metaplex-foundation/umi-bundle-defaults@metaplex-foundation/mpl-core@metaplex-foundation/umi-uploader-irysnpm i @metaplex-foundation/umi\nnpm i @metaplex-foundation/umi-bundle-defaults\nnpm i @metaplex-foundation/mpl-core\nnpm i @metaplex-foundation/umi-uploader-irys;\nImports and Wrapper FunctionHere we will define all needed imports for this particular guide and create a wrapper function where all our code will execute.import { create, mplCore } from '@metaplex-foundation/mpl-core'\nimport {\n createGenericFile,\n generateSigner,\n signerIdentity,\n sol,\n} from '@metaplex-foundation/umi'\nimport { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\nimport { irysUploader } from '@metaplex-foundation/umi-uploader-irys'\nimport { base58 } from '@metaplex-foundation/umi/serializers'\nimport fs from 'fs'\nimport path from 'path'\n// Create the wrapper function\nconst createNft = async () => {\n ///\n ///\n /// all our code will go in here\n ///\n ///\n}\n// run the wrapper function\ncreateNft()\nSetting up UmiWhile setting up Umi you can use or generate keypairs/wallets from different sources. You create a new wallet for testing, import an existing wallet from the filesystem, or use walletAdapter if you are creating a website/dApp.Note: For this example we're going to set up Umi with a generatedSigner() but you can find all the possible setup down below!Note: The walletAdapter section provides only the code needed to connect it to Umi, assuming you've already installed and set up the walletAdapter. For a comprehensive guide, refer to the Wallet Adapter guideCreating the Metadata for the AssetTo display a recognisable image for your Asset in the Wallets or on the Explorer, we need to create the URI where we can store the Metadata!Uploading the ImageUmi comes with downloadable storage plugins that allow you to upload to storage solutions such Arweave, NftStorage, AWS, and ShdwDrive. For this guide we're going to use the irysUploader() plugin which stores content on Arweave. In this example we're going to use a local approach using Irys to upload to Arweave; if you wish to upload files to a different storage provider or from the browser you will need to take a different approach. Importing and using fs won't work in a browser scenario.import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\nimport { irysUploader } from '@metaplex-foundation/umi-uploader-irys'\nimport fs from 'fs'\nimport path from 'path'\n// Create Umi and tell it to use Irys\nconst umi = createUmi('https://api.devnet.solana.com')\n .use(irysUploader())\n// use `fs` to read file via a string path.\n// You will need to understand the concept of pathing from a computing perspective.\nconst imageFile = fs.readFileSync(\n path.join(__dirname, '..', '/assets/my-image.jpg')\n)\n// Use `createGenericFile` to transform the file into a `GenericFile` type\n// that umi can understand. Make sure you set the mimi tag type correctly\n// otherwise Arweave will not know how to display your image.\nconst umiImageFile = createGenericFile(imageFile, 'my-image.jpeg', {\n tags: [{ name: 'Content-Type', value: 'image/jpeg' }],\n})\n// Here we upload the image to Arweave via Irys and we get returned a uri\n// address where the file is located. You can log this out but as the\n// uploader can takes an array of files it also returns an array of uris.\n// To get the uri we want we can call index [0] in the array.\nconst imageUri = await umi.uploader.upload([umiImageFile]).catch((err) => {\n throw new Error(err)\n})\nconsole.log(imageUri[0])\nUploading the MetadataOnce we have a valid and working image URI we can start working on the metadata for our asset. The standard for offchain metadata for a fungible token is as follows. This should be filled out and writen to either an object {} without Javascript or saved to a metadata.json file. We are going to look at the JavaScript object approach.const metadata = {\n name: 'My NFT',\n description: 'This is an NFT on Solana',\n image: imageUri[0],\n external_url: 'https://example.com',\n attributes: [\n {\n trait_type: 'trait1',\n value: 'value1',\n },\n {\n trait_type: 'trait2',\n value: 'value2',\n },\n ],\n properties: {\n files: [\n {\n uri: imageUri[0],\n type: 'image/jpeg',\n },\n ],\n category: 'image',\n },\n}\nThe fields here include:fielddescriptionnameThe name of your NFT.descriptionThe description of your NFT.imageThis will be set to the imageUri (or any online location of the image) that we uploaded previously.animation_urlThis will be set to the animation_ulr (or any online location of the video/glb) that you've uploaded.external_urlThis would link to an external address of your choice. This is normally the projects website.attributesUsing an object og {trait_type: vlue, \"value\": \"value1\"}imageThis will be set to the imageUri (or any online location of the image) that we uploaded previously.propertiesContains the files field that takes an [] array of {uri: string, type: mimeType}. Also contains the category field which can be set to image, audio, video, vfx, and htmlAfter creating the metadata, we need to upload it as a JSON file, so we can get a URI to attach to our Collection. To do this, we'll use Umi's uploadJson() function:// Call upon Umi's `uploadJson()` function to upload our metadata to Arweave via Irys.\nconst metadataUri = await umi.uploader.uploadJson(metadata).catch((err) => {\n throw new Error(err)\n})\nThis function automatically converts our JavaScript object to JSON before uploading. Now we should finally have the URI of JSON file stored in the metadataUri providing it did not throw any errors.Minting the NFT Core AssetFrom here we can use the create function from the @metaplex-foundation/mpl-core package to create our Core NFT Asset.const asset = generateSigner(umi)\nconst tx = await create(umi, {\n asset,\n name: 'My NFT',\n uri: metadataUri,\n}).sendAndConfirm(umi)\nconst signature = base58.deserialize(tx.signature)[0]\nAnd log out the detail as follow: // Log out the signature and the links to the transaction and the NFT.\n console.log('\\nNFT Created')\n console.log('View Transaction on Solana Explorer')\n console.log(`https://explorer.solana.com/tx/${signature}?cluster=devnet`)\n console.log('\\n')\n console.log('View NFT on Metaplex Explorer')\n console.log(`https://core.metaplex.com/explorer/${nftSigner.publicKey}?env=devnet`)\nAdditional ActionsBefore moving on, what if we want to create an asset with plugins and/or external plugins, such as the FreezeDelegate plugin or the AppData external plugin, already included? Here's how we can do it. The create() instruction supports adding both normal and external plugin through the plugins field. So we can just easily add all the required field for the specific plugins, and everything it will be handled by the instruction. Here's an example on how to do it:const asset = generateSigner(umi)\nconst tx = await create(umi, {\n asset,\n name: 'My NFT',\n uri: metadataUri,\n plugins: [\n {\n type: \"PermanentFreezeDelegate\",\n frozen: true,\n authority: { type: \"UpdateAuthority\"}\n },\n {\n type: \"AppData\",\n dataAuthority: { type: \"UpdateAuthority\"},\n schema: ExternalPluginAdapterSchema.Binary,\n } \n ]\n}).sendAndConfirm(umi)\nconst signature = base58.deserialize(tx.signature)[0]\nNote: Refer to the documentation if you're not sure on what fields and plugin to use!Full Code Exampleimport { create } from '@metaplex-foundation/mpl-core'\nimport {\n createGenericFile,\n generateSigner,\n signerIdentity,\n sol,\n} from '@metaplex-foundation/umi'\nimport { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\nimport { base58 } from '@metaplex-foundation/umi/serializers'\nimport fs from 'fs'\nimport path from 'path'\nconst createNft = async () => {\n //\n // ** Setting Up Umi **\n //\n const umi = createUmi('https://api.devnet.solana.com')\n .use(mplCore())\n .use(\n irysUploader({\n // mainnet address: \"https://node1.irys.xyz\"\n // devnet address: \"https://devnet.irys.xyz\"\n address: 'https://devnet.irys.xyz',\n })\n )\n const signer = generateSigner(umi)\n umi.use(signerIdentity(signer))\n // Airdrop 1 SOL to the identity\n // if you end up with a 429 too many requests error, you may have to use\n // the filesystem wallet method or change rpcs.\n console.log('Airdropping 1 SOL to identity')\n await umi.rpc.airdrop(umi.identity.publicKey, sol(1))\n //\n // ** Upload an image to Arweave **\n //\n // use `fs` to read file via a string path.\n // You will need to understand the concept of pathing from a computing perspective.\n const imageFile = fs.readFileSync(\n path.join('./image.png')\n )\n // Use `createGenericFile` to transform the file into a `GenericFile` type\n // that umi can understand. Make sure you set the mimi tag type correctly\n // otherwise Arweave will not know how to display your image.\n const umiImageFile = createGenericFile(imageFile, 'image.png', {\n tags: [{ name: 'Content-Type', value: 'image/png' }],\n })\n // Here we upload the image to Arweave via Irys and we get returned a uri\n // address where the file is located. You can log this out but as the\n // uploader can takes an array of files it also returns an array of uris.\n // To get the uri we want we can call index [0] in the array.\n console.log('Uploading Image...')\n const imageUri = await umi.uploader.upload([umiImageFile]).catch((err) => {\n throw new Error(err)\n })\n console.log('imageUri: ' + imageUri[0])\n //\n // ** Upload Metadata to Arweave **\n //\n const metadata = {\n name: 'My NFT',\n description: 'This is an NFT on Solana',\n image: imageUri[0],\n external_url: 'https://example.com',\n attributes: [\n {\n trait_type: 'trait1',\n value: 'value1',\n },\n {\n trait_type: 'trait2',\n value: 'value2',\n },\n ],\n properties: {\n files: [\n {\n uri: imageUri[0],\n type: 'image/jpeg',\n },\n ],\n category: 'image',\n },\n }\n // Call upon umi's `uploadJson` function to upload our metadata to Arweave via Irys.\n console.log('Uploading Metadata...')\n const metadataUri = await umi.uploader.uploadJson(metadata).catch((err) => {\n throw new Error(err)\n })\n //\n // ** Creating the NFT **\n //\n // We generate a signer for the NFT\n const asset = generateSigner(umi)\n console.log('Creating NFT...')\n const tx = await create(umi, {\n asset,\n name: 'My NFT',\n uri: metadataUri,\n }).sendAndConfirm(umi)\n // Finally we can deserialize the signature that we can check on chain.\n const signature = base58.deserialize(tx.signature)[0]\n // Log out the signature and the links to the transaction and the NFT.\n console.log('\\nNFT Created')\n console.log('View Transaction on Solana Explorer')\n console.log(`https://explorer.solana.com/tx/${signature}?cluster=devnet`)\n console.log('\\n')\n console.log('View NFT on Metaplex Explorer')\n console.log(`https://core.metaplex.com/explorer/${nftSigner.publicKey}?env=devnet`)\n}\ncreateNft()","tokens":3004,"squid":"dotcat","role":"Tooling Spider","at":1791344326837,"hash":"c424b0cbdde21de2cbf2b72e9c8bf7e65aff246e"}
{"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":"spider-08","role":"Oracle Spider","at":1791344330463,"hash":"3c12dd5f28ea85bcba651dabf950571c77021ed1"}
{"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":"spider-08","role":"Oracle Spider","at":1791344340443,"hash":"6b6258d1dec344f8b433ba0de62b1bdd610101a7"}
{"url":"https://developer.arbitrum.io/how-arbitrum-works/reference/finality-and-reorgs","domain":"developer.arbitrum.io","title":"Finality and chain reorganizations","text":"Finality and chain reorganizationsHow finality works on Arbitrum chains, how and why a child chain can reorganize, how deep a reorg can go, and the confirmation levels an indexer should wait for before treating data as irreversible.Request an updateThis reference explains how finality works on chains, why and when a chain can reorganize (), 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 , , and Dedicated Blockchains (Arbitrum chains)—including 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?latestThe has ordered and executed the transaction and emitted it on the .Yes—this is a promise from the Sequencer, not yet backed by the parent chain.Parent-chain safesafeThe containing the block has been posted to the 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. is fast (sub-second) but reversible. —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 signs the block's data. That describes soft confirmation and data availability, not :\n\nThe Sequencer executes and broadcasts the queued transactions immediately—this is your sub-second soft confirmation.\nThe DAC signing a 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 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 '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 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 asks the DAC to sign a DACert over the batch data. If enough committee members sign against the current , 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.\n\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.\n\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 . and dispute resolution never cause a reorg—a rejected 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 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 .\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 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 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 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 — , 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.\nHow is this guide?GethLearn the fundamentals of Nitro, Arbitrum stack.STF inputsReference for the message types and input channels that feed the Arbitrum State Transition Function.","tokens":4705,"squid":"spider-01","role":"Chain Spider","at":1791344343316,"hash":"6f879e56fdafe0e775ab842bab9a274d96fa4b97"}
{"url":"https://developer.arbitrum.io/how-arbitrum-works/reference/stf-inputs","domain":"developer.arbitrum.io","title":"Inputs to the State Transition Function","text":"Inputs to the State Transition FunctionReference for the message types and input channels that feed the Arbitrum State Transition Function.Request an update nodes receive transaction inputs through two channels:\n\nNodes subscribe to the feed and receive upcoming ordered published in real time. To learn more, refer to the real-time sequencer feed documentation.\nNodes also subscribe to the SequencerBatchDelivered event on the . This event occurs whenever a 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 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 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;\nuint8 constant L1MessageType_L2FundedByL1 = 7;\nuint8 constant L1MessageType_submitRetryableTx = 9;\nuint8 constant L1MessageType_ethDeposit = 12;\nuint8 constant L1MessageType_batchPostingReport = 13;\nuint8 constant L2MessageType_unsignedEOATx = 0;\nuint8 constant L2MessageType_unsignedContractTx = 1;\n\nuint8 constant ROLLUP_PROTOCOL_EVENT_TYPE = 8;\nuint8 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_TYPE8 used it for messages sent to ; 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.How is this guide?Finality and reorgsHow finality works on Arbitrum chains, how and why a child chain can reorganize, how deep a reorg can go, and the confirmation levels an indexer should wait for before treating data as irreversible.ArbOS technical referenceTechnical reference for ArbOS internals: precompile architecture, state storage, child chain pricing state, and Stylus execution details.","tokens":907,"squid":"spider-01","role":"Chain Spider","at":1791344365109,"hash":"f88a2795b9b6890a176ab162303b14be57e1c310"}
{"url":"https://developer.arbitrum.io/how-arbitrum-works/priority-gas-auction/fast-feed","domain":"developer.arbitrum.io","title":"Introduction to the Fast Feed","text":"Introduction to the Fast FeedLearn what the Fast Feed publishes, who it serves, and how paid subscription access works.Request an updateThe Fast Feed is a paid, authenticated WebSocket stream that publishes each transaction as soon as the has ordered and executed it, before the block that contains it reaches the standard .\nOn , 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\n react to ordered transactions sooner, whether they run arbitrage between a centralized and a decentralized exchange, liquidations, or back-running strategies.\n 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 . 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.\nNoteThe 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.\nNoteThe 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.How is this guide?Introduction to PGALearn how PGA works and how it can benefit your Arbitrum-based project.PGA and Fast feedDetailed explanations of Priority Gas Auction (PGA) and Fast Feed.","tokens":1956,"squid":"spider-01","role":"Chain Spider","at":1791344386913,"hash":"92dfe259992e7ae8a769425e6622543c3b727768"}
{"url":"https://akash.network/docs/developers/guides/","domain":"akash.network","title":"Developer Guides | Akash Network - Your Guide to Decentralized Cloud","text":"Developer Guides Hands-on tutorials and guides for building applications on Akash Network.\nThis section contains practical, step-by-step guides that walk you through building real-world applications using Akash infrastructure.\n\nWhat You’ll Learn\nOur guides cover:\n\nAkashML Integration - Using Akash’s AI inference APIs\nFull-Stack Development - Building complete applications\nDeployment Best Practices - Deploying to Akash Network\nReal-World Examples - Practical, production-ready code\n\nPrerequisites\nMost guides assume you have:\n\nBasic programming knowledge (JavaScript/TypeScript, Python, or Go)\nFamiliarity with web development concepts\nAn Akash wallet with some AKT for deployments\n\nSpecific prerequisites are listed in each guide.\n\nContributing\nHave a guide you’d like to share? We welcome community contributions!\n\nContributing Guide\nDocumentation Writing Guide\n\nQuestions? Join Discord #developers channel! \nEdit page on github\n AuthZ & Fee Grants Getting Started","tokens":242,"squid":"spider-03","role":"Compute Spider","at":1791344392371,"hash":"a4ee0a29b3789bbcee76d40dd46884be9bf5b03f"}
{"url":"https://developer.arbitrum.io/how-arbitrum-works/priority-gas-auction/use-fast-feed","domain":"developer.arbitrum.io","title":"How to use the Fast Feed","text":"How to use the Fast FeedGenerate an API key, deposit USDG, buy a ticket each round from the Tickets contract, open an authenticated WebSocket to the Fast Feed on Arbitrum One, automate renewals with the reference bot, and troubleshoot reverts and rejected connections.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 on , 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 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/\nexport TICKETS=0x451DD62C26b753d07d6104aaC6865AaE73a6A598\nexport 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)\"\ncast call $TICKETS \"currentPrice()(uint256)\"\ncast call $TICKETS \"roundEnd()(uint256)\"\ncast call $TICKETS \"grandfatherPeriodEnd()(uint256)\"\ncast 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 . 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 \\\n \"purchaseTickets(uint256,uint256,uint256,bytes32)\" \\\n <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.\nwscat -c \"$FEED_URL\" -H \"Authorization: Bearer $API_KEY\"import WebSocket from 'ws';\n\nconst ws = new WebSocket(process.env.FEED_URL, {\n headers: { Authorization: `Bearer ${process.env.API_KEY}` },\n});\n\nws.on('unexpected-response', (req, res) => {\n // 401: unknown key or no active ticket. 429: every ticket already has a connection.\n console.error(`Rejected: HTTP ${res.statusCode}`);\n req.destroy(); // with a listener attached, ws leaves the request open\n});\n\nws.on('message', (data) => {\n const msg = JSON.parse(data.toString());\n // msg.pga_round, msg.transaction.tx_hash, msg.transaction.receipt, ...\n});\n\nws.on('close', (code, reason) => {\n console.log('closed', code, reason.toString());\n});import asyncio\nimport json\nimport os\n\nimport websockets\n\nasync def main():\n headers = {\"Authorization\": f\"Bearer {os.environ['API_KEY']}\"}\n try:\n async with websockets.connect(os.environ[\"FEED_URL\"], additional_headers=headers) as ws:\n async for frame in ws:\n msg = json.loads(frame)\n # msg[\"pga_round\"], msg[\"transaction\"][\"tx_hash\"], msg[\"transaction\"][\"receipt\"], ...\n except websockets.InvalidStatus as e:\n # 401: unknown key or no active ticket. 429: every ticket already has a connection.\n print(f\"Rejected: HTTP {e.response.status_code}\")\n except websockets.ConnectionClosed as e:\n print(f\"closed {e.rcvd.code} {e.rcvd.reason}\")\n\nasyncio.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_GASNo 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.git\ncd feed-ticket-contracts/bot\ndocker build -t purchase-bot .\ndocker run --rm \\\n -e RPC_URL=$RPC_URL \\\n -e PRIVATE_KEY=$PRIVATE_KEY \\\n -e TICKETS_ADDRESS=$TICKETS \\\n -e TICKETS_PER_ROUND=1 \\\n -e MAX_PRICE_PER_TICKET=<amount> \\\n -e MAX_TRANSACTION_FEE=<wei> \\\n -e API_KEY_HASH=<apiKeyHash> \\\n 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.How is this guide?PGA and Fast feedDetailed explanations of Priority Gas Auction (PGA) and Fast Feed.","tokens":3579,"squid":"spider-01","role":"Chain Spider","at":1791344397851,"hash":"9012ba157e5bdcd1ac5a8a9edf30cd786671b680"}
{"url":"https://akash.network/docs/api-documentation/console-api/","domain":"akash.network","title":"Managed Wallet API | Akash Network - Your Guide to Decentralized Cloud","text":"Managed Wallet API Deploy on Akash programmatically using the Console API. It lets you create and manage deployments with Console-managed wallets, so you do not have to manage private keys.\nBase URL: https://console-api.akash.network\nAuthentication: pass your API key in every request with x-api-key: YOUR_API_KEY.\n\nFeatures\n\nCreate and manage deployments via plain HTTP with no blockchain client or SDK required.\nReceive bids from providers and accept them by creating a lease in a single API call.\nFund deployments with a credit card; no AKT wallet or crypto exchange needed.\nAuthenticate with a single API key scoped to your Console account.\nMonitor deployments with list, get, and settings endpoints.\n\nHow it works\n\nCreate a deployment: POST your SDL (deployment manifest) to /v1/deployments.\nAccept a bid: wait around 30 seconds, GET bids from /v1/bids?dseq=..., then POST to /v1/leases to accept one.\nManage: update the SDL, or DELETE to close the deployment. Funding is automatic. Console keeps the deployment running from your account credits and returns whatever it did not spend when you close it.\n\nDocumentation\n\nGetting Started - Complete guide with examples and best practices\nAPI Reference - Endpoint documentation with schemas\nQuickstart - End-to-end deployment in five API calls\n\nChangelog\nSee the full GitHub releases for the authoritative version history.\n\nNeed Help?\n\nDiscord: discord.akash.network\nGitHub Issues: https://github.com/akash-network/console/issues\n\nEdit page on github\n Getting Started Getting Started","tokens":384,"squid":"spider-03","role":"Compute Spider","at":1791344403104,"hash":"0417d15de5d2afe11b5df6c2388ffe47269485b4"}
{"url":"https://developer.arbitrum.io/how-arbitrum-works/priority-gas-auction/pga","domain":"developer.arbitrum.io","title":"Introduction to PGA (Priority Gas Auctions)","text":"Introduction to PGA (Priority Gas Auctions)Learn how PGA works and how it can benefit your Arbitrum-based project.Request an updatePGA is an ordering policy in which users bid for ordering by attaching a priority fee to each . Ordering becomes a continuous, permissionless, per-transaction competition.\nPGA is available for activation on supported Arbitrum chains with priority fee collection and a PGA-capable Sequencer build.\nWhy sunset Timeboost?\n has used Timeboost since April 2025. Timeboost auctions off a 60-second \"\" 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\n.\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 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 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\n 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 : a set of rules the Sequencer is trusted to follow when ordering transactions submitted by users.\nAs with FCFS and Timeboost, the '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 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(\n transaction.max_priority_fee_per_gas,\n transaction.max_fee_per_gas - block.base_fee_per_gas\n)\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 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 held the round.\nYou can withdraw funds you still have locked in the Timeboost 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.How is this guide?Introduction to the Fast FeedLearn what the Fast Feed publishes, who it serves, and how paid subscription access works.","tokens":2308,"squid":"spider-01","role":"Chain Spider","at":1791344408810,"hash":"7fe19ad473a215687584632c84c84ce2f1df035b"}
{"url":"https://mpl-core.typedoc.metaplex.com/types/_internal_.Program.html","domain":"mpl-core.typedoc.metaplex.com","title":"Program | @metaplex-foundation/mpl-core - v1.9.0","text":"@metaplex-foundation/mpl-core - v1.9.0\n<internal>\nProgram\nType alias Program\nProgram: {     getErrorFromCode: ((code: number, cause?: Error) => ProgramError | null);     getErrorFromName: ((name: string, cause?: Error) => ProgramError | null);     isOnCluster: ((cluster: Cluster) => boolean);     name: string;     publicKey: PublicKey; }\nDefines a Solana Program that can be\nregistered in Umi's program repository.\n\nType declaration\n\ngetErrorFromCode: ((code: number, cause?: Error) => ProgramError | null)\n\n(code: number, cause?: Error): ProgramError | null\n\nRetrieves a ProgramError from a given error code\nor null if the error code is not recognized.\n\nParameters\n\ncode: number\n\nOptional cause: Error\nReturns ProgramError | null\n\ngetErrorFromName: ((name: string, cause?: Error) => ProgramError | null)\n\n(name: string, cause?: Error): ProgramError | null\n\nRetrieves a ProgramError from a given error name\nor null if the error name is not recognized.\n\nParameters\n\nname: string\n\nOptional cause: Error\nReturns ProgramError | null\n\nisOnCluster: ((cluster: Cluster) => boolean)\n\n(cluster: Cluster): boolean\n\nA method that returns true if the program is available on the given cluster.\nIf the same program is available on multiple clusters but using different public keys,\nmultiple Program instances must be registered such that the isOnCluster method\nreturns true for the appropriate cluster.\n\nParameters\n\ncluster: Cluster\nReturns boolean\n\nname: string\nA unique name for the Program in camelCase.\nTo avoid conflict with other organizations, it is recommended\nto prefix the program name with a namespace that is unique to\nyour organization. For instance, Metaplex programs are prefixed\nwith mpl like so: mplTokenMetadata or mplCandyMachine.\n\npublicKey: PublicKey\nThe public key of the program.\n\n Settings\n\nMember Visibility\n\nThemeOSLightDark\n\nGenerated using TypeDoc","tokens":466,"squid":"dotcat","role":"Tooling Spider","at":1791344410204,"hash":"2a9b5b5443d5e1c2c7fae4d758d5d9b8b8d5edac"}
{"url":"https://akash.network/docs/getting-started/ai-agents/","domain":"akash.network","title":"Akash for AI Agents | Akash Network - Your Guide to Decentralized Cloud","text":"Akash for AI Agents Install the Akash skill in your AI coding agent and deploy to Akash from natural-language prompts.\nThe Akash skill is an open-source skill bundle for AI coding agents such as Claude Code, Codex, and OpenCode. It teaches your agent how to write Akash SDL and deploy, inspect, and manage workloads on Akash Network — so you can ship to decentralized compute just by describing what you want.\nInstalling it adds three skills: akash-network:akash (deploying workloads), akash-network:akash-provider (running a provider), and akash-network:akash-node (running a node or validator). This page focuses on the deployer skill.\nFor an agent operating the akt binary, use the focused akt CLI agent skill. That page hosts the skill and its supporting files from the akt repository, with a ZIP download and installation instructions.\n\nPrerequisites\nBefore you start, make sure you have:\n\nA supported coding agent — Claude Code, Codex, or OpenCode.\nAn Akash API key (recommended) — create one in Akash Console. The skill uses it to deploy through the Console API with a managed wallet. You can instead use a funded self-custody wallet if you deploy through the CLI or an SDK.\nA container image for the workload you want to deploy, with an explicit version tag.\n\nSet Up the Skill\nInstall the skill once, then your agent can deploy to Akash on demand.\nClaude Code (recommended)\nAdd the marketplace and install the plugin from inside a Claude Code session:\n/plugin marketplace add akash-network/akash-skill/plugin install akash-network@akash-network\nTo pin a specific release, add a version tag:\n/plugin marketplace add akash-network/akash-skill@v3.2.0\nUpdate later with:\n/plugin marketplace update akash-network\nNote: To try the skill in a single session without installing it, clone the repository and launch Claude Code with it as a local plugin:\nTerminal windowgit clone https://github.com/akash-network/akash-skillcd akash-skillclaude --plugin-dir \"$(pwd)\"\nCodex\nCodex discovers the skills from the repository’s .codex-plugin/plugin.json manifest and loads them from skills/. Add the akash-skill repository as a local or marketplace Codex plugin, and the Akash skills become available.\nOpenCode & Other Agents\nLink the skills into your agent’s global skills directory:\nTerminal windowmkdir -p ~/.agents/skillsln -s /path/to/akash-skill/skills/akash ~/.agents/skills/akashln -s /path/to/akash-skill/skills/akash-provider ~/.agents/skills/akash-providerln -s /path/to/akash-skill/skills/akash-node ~/.agents/skills/akash-node\nReplace /path/to/akash-skill with the location where you cloned the repository.\nTip: In Claude Code, run /plugin to confirm akash-network is installed. If the skill does not trigger automatically, restart your agent and mention Akash explicitly in your prompt.\n\nDeploy on Akash with the Skill\nOnce the skill is installed, you don’t call it directly — just describe what you want to deploy. The skill auto-triggers on Akash-related prompts and walks through the whole flow: writing the SDL, choosing a deployment method, submitting the deployment, accepting a provider bid, and fetching logs.\nFor example, tell your agent:\n\n“Deploy a simple Node.js web app to Akash using my API key.”\n\nThe skill writes a valid SDL for the app, deploys it through the Console API, waits for a provider bid, and returns the lease details and the public URL where your app is running.\nExample Prompts\n\n“Write an SDL for a Next.js app with 1 CPU and 1 GB of RAM and deploy it to Akash with my API key.”\n“Deploy this SDL to Akash and show me the lease status.”\n“Check the logs and events for my Akash deployment.”\n“Call DeepSeek on Akash with the OpenAI SDK.” (uses AkashML managed inference)\n\nExplicit Invocation\nIn Claude Code you can also invoke the deployer skill directly:\n/akash-network:akash <task description>\nWhat the Skill Handles\n\nWriting and validating Akash SDL.\nChoosing a deployment method — Console API, CLI, or the TypeScript/Go SDK.\nCreating the deployment, accepting a bid, and sending the manifest.\nFetching deployment logs and events through the provider proxy.\nCalling hosted open-source models with AkashML managed inference.\n\nRelated Resources\n\nQuick Start - Deploy your first app on Akash\nCore Concepts - How deployments, leases, and bids work\nSDL Reference - Deployment configuration syntax\nakt CLI - Command-line deployment\nakt CLI Agent Skill - Skill download, setup, deployment recipes, and troubleshooting\nConsole API - Managed-wallet HTTP API and API keys\nAkash Skill on GitHub - Source, issues, and releases\n\nQuestions? Join Discord #developers channel! \nEdit page on github\n How Funding Works Getting Started","tokens":1163,"squid":"spider-03","role":"Compute Spider","at":1791344412890,"hash":"da2fc586c393a9c517f4c057bcaa6767faf49806"}
{"url":"https://forum.arbitrum.foundation/t/proposal-to-backfund-successful-stip-proposals-savvy-dao-draft/19046/101","domain":"forum.arbitrum.foundation","title":"Proposal to Backfund Successful STIP Proposals (Savvy DAO) [FINAL] - Proposals / Finalized AIPs - Arbitrum","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Oct 2023\n\n 91 / 120\n\n Nov 2023\n\n Feb 2024\n\n Load more posts above\n\n post by litocoen on Nov 13, 2023\n\n post by Bob-Rossi on Nov 13, 2023\n\n post by Camelot on Nov 13, 2023\n\n post by tnorm on Nov 13, 2023\n\n tnorm\n\n tsundoku\n\n To be candid, I feel neither shame nor the need to defend myself against the finer points of message here.\nI hope Alex and the team behind this backfund prop would state that I’ve been nothing but supportive of their intent to create this proposal including helping them use the working group as a platform in its early weeks, providing feedback, and not gatekeeping or pushing the political games that you seem to think occur.\nMy comments clearly addressed a specific tactic that I do not support, which is the (sometimes sublte, sometimes blatant) perpetuation of narratives that are manipulative and often take statements out of context. These narratives are being used to inflame divisions in the community and target some of the most important stakeholders and contributors at Arbitrum.\nAs to @Djinn’s points, the point is that to spin the WG as being designed by big protocols for big protocols is simply not reflective of the spirit of the proposal, which was literally borne to ensure that both large proposals and smaller proposals, could be passed simultaneously so that not just massive protocols got incentives for the fall/winter. Many of the protocols who knew they would likely ask for large grants actually lobbied quite hard for a 75M ARB cap for the very reason of including more smaller protocols, which you can also track in the original proposal thread.\nThe fact that ~90 protocols only engaged with the DAO once the grants program had launched was unfortunate and unexpected. I simply can’t stand by quietly and watch those who were not present (and apparently do not care to read) to claim any original contributor’s intent, especially for the sake of trying to pass a proposal.\nAs for alleging that gaming was not considered, that’s simply false and was addressed throughout the original STIP comments, as we purposefully made the tier recommendations “guidelines” rather than “rules” to allow them to participate:\n\nThe WG calls actively tried to address gaming both pre-STIP and post, but there has been little to none engagement from any gaming representatives thus far.\n\n post by blazedbison on Nov 13, 2023\n\n blazedbison\n\nJust want to point out that this has/should have been done during the actual STIP Rd 1. These are all projects that received a majority FOR vote AND met quorum.\nAlso, a Round 2 working group is/has been formed, and this proposal in no way impacts that. Why should those who were ready and did put the time in for round 1, and as previously mentioned DID obtain the required votes to pass - a taxing task in itself for smaller projects who could better spend their time building their products rather than lobbying delegates - be punished by having to apply again and go through this whole process…\nBut, I appreciate the response/reasoning. Just think there’s been a lot of confusion about this proposal and who it’s rewarding.\n\n post by cliffton.eth on Nov 13, 2023\n\n cliffton.eth\n\n Hey everyone, a reminder to please keep comments and replies respectful, professional, and constructive to this proposal. I had to delete some comments which undermined the integrity and/or character of individuals and/or teams.\nName-calling, personal attacks, and comments which challenged the integrity of individuals and/or teams will not be tolerated as per the community guidelines.\nRemember, the purpose of this forum is to foster productive and respectful discussions related to governance. We encourage everyone to contribute their ideas and perspectives in a respectful and constructive way, and to learn from each other.\n\n post by realdumbird on Nov 13, 2023\n\n realdumbird\n\n First of all, MUX delegates sincerely appreciate all the DAO members who pushed for the productive yet intense STIP program, and we also respect all the efforts that went into this backfund proposal. After internal debates and long discussions, we have decided to vote “Abstain” for this proposal.\nAlthough MUX delegates totally support the idea of having more protocols and builders to be supported, backfunding doesn’t seem to be the most reasonable approach:\n\nThe 25+ proposals in this backfund bundle have mixed quality; some are worthy of support, while some are questionable, considering the protocol fundamentals, incentives execution strategies, and actual grant requested.\nIt would be more reasonable to have the proposals being voted on individually in a round 2 type of event instead of binding all the proposals together.\nThe term “inclusion” was used frequently in this conversation to back up the intention. However, it seems the phrase has been used to dodge the fact that the original grant size was set according to supply & demand + DAO treasury fund management concerns instead of being “exclusive”.\nRound 1 was made possible by DAO members advocating for a framework so more protocols and builders who are building projects with solid fundamentals and clear benefits to the ecosystem can be supported. Some of the claims that tried to twist the original intention in this forum thread are a bit sickening to see.\nPassing the quorum wasn’t a solid reason to back up the claim for a “guaranteed” grant; Passing the quorum + making it to the cutoff line was, given the fact that the VOTED size for the first STIP was 50M.\nWe hope the backfund attempt won’t become a recurring behavior that will always happen after all STIP types of events \n\nTo conclude, although MUX delegates would love to support many individual proposals included in this bundle, the delegates can’t seem to all align with the backfund approach and reasonings behind this proposal. Therefore, MUX delegates will vote “Abstain.”\nAdditional Disclaimer:\nPreviously MUX delegates didn’t have a chance to participate in the backfund proposal AMA hosted by @SavvyDeFi due to time conflicts, but we listened to the full recording.\n\n post by krst on Nov 14, 2023\n\n krst\n\n The below response reflects the views of L2BEAT’s governance team, composed of @krst and @Sinkas, and it’s based on the combined research, fact-checking and ideation of the two.\nL2BEAT is voting FOR STIP backfunding proposal in the temperature check vote.\nAt first we were hesitant regarding this proposal, for the reasons already mentioned by other delegates:\n\nInitially, the spending limit for the STIP program has been set at 50M ARB through a DAO vote. Even though the original proposal did mention a possibility of extending this amount, it’s not a good precedent to immediately ignore this self-imposed limit with a follow-up proposal.\nThere are concerns regarding the impact that the deployment of 20M additional ARB to the market through direct incentives will have on the short- and mid-term price of the ARB token.\nThere was also a concern about the potential delay of STIP Round 2 and the long-term program development. That concern was raised especially by projects that did not make it to the list in this proposal or that did not apply for the STIP during round 1 at all.\nLastly, there was a concern related to the fact that in our opinion the results of STIP Round 1 were far from perfect. As we have previously mentioned, we were not satisfied with the end results of the STIP voting as there was not enough time to review the applications and provide proper feedback. That includes the applications included in the back-funding list.\n\nGiven the concerns mentioned above, we engaged in a discussion with the team behind the backfund proposal. We held discussions both during our Office Hours calls as well as during public Twitter spaces and in Telegram group chats. The team addressed most of our concerns and while they were not completely dispelled, we got convinced that this proposal is safe to pass and will not be a blocker for future rounds.\nIt is worth noting that the team behind this proposal was very active in assembling a dedicated team to work on Round 2 and pushing the needle forward with the work in that front. In addition, the team showed dedication and perseverance in pushing this proposal through the temperature check, making themselves available for any questions we had and willing to find ways to address concerns raised by us or other parties. This was, and still is, a very promising signal for the actual execution of the proposal.\nIn addition, since STIP was designed to be a short-term experiment, doubling the number of projects in the program, and ensuring the inclusion of smaller projects, will provide us with more data on how this program is performing and allow us to draw better conclusions and lessons for the long-term program.\nConsidering all this, but especially considering the dedication and openness of the team, we have decided to support this proposal for the temp check, and we will continue to support the team in the execution and validation of the results.\n\n L2BEAT Delegate Communication Thread\n\n post by DoomedCapital on Nov 14, 2023\n\n post by Ram_Ranchero on Nov 14, 2023\n\n post by hsuanting on Nov 14, 2023\n\n post by SeriousTaylor on Nov 14, 2023\n\n post by Michigan_Blockchain on Nov 14, 2023\n\n post by dk3 on Nov 15, 2023\n\n post by dansco8 on Nov 15, 2023\n\n post by Shoos on Nov 15, 2023\n\n post by SavvyDAO on Nov 19, 2023\n\n post by BlockworksResearch on Nov 21, 2023\n\n post by Djinn on Nov 21, 2023\n\n post by Pioneer on Nov 21, 2023\n\n Load more posts below","tokens":2397,"squid":"spider-07","role":"Council Spider","at":1791344421955,"hash":"258f101d1c857836c520df5ccfced0ed2538962c"}
{"url":"https://akash.network/docs/getting-started/core-concepts/","domain":"akash.network","title":"Core Concepts | Akash Network - Your Guide to Decentralized Cloud","text":"Core Concepts Learn the basics of how Akash Network works in 5 minutes.\n\nHow Akash Works\nAkash is a decentralized marketplace connecting people who need compute resources with data centers that provide them.\n\nKey Terms\nDeployment\nA request for compute resources. You describe what you need (CPU, memory, storage) using SDL (Stack Definition Language).\nProvider\nA data center offering compute resources on Akash. Providers bid competitively to host your deployment.\nLease\nAn agreement between you and a provider. Locks in pricing and resources for your deployment.\nSDL\nStack Definition Language - a YAML file that describes your deployment:\n\nWhat container image to run\nHow much CPU, memory, and storage you need\nWhat ports to expose\nHow much you’re willing to pay\n\nEscrow\nFunds held to pay for your deployment, in ACT (a USD-pegged compute credit). The provider is paid automatically per block from that escrow.\nWho fills it depends on how you deploy. With your own wallet, through Console Air or the CLI, you fund escrow yourself and top it up with ACT (or AKT when the circuit breaker is in effect). On the managed Akash Console you never touch it: you add credits to your account and Console funds each deployment for you. See How Funding Works.\n\nBasic Workflow\n1. Create Deployment\nWrite an SDL file describing your app and resources needed.\n2. Review Bids\nProviders submit bids with their pricing. Choose the one you prefer.\n3. Accept Bid\nCreate a lease with the selected provider.\n4. App Runs\nProvider pulls your container image and starts your app.\n5. Automatic Payment\nYour escrow pays the provider per block (~6 seconds) in ACT.\n\nDeployment Options\nAkash Console (Easiest)\n\nVisual web interface\n$1 free trial (no wallet needed)\nPerfect for beginners\n\nCLI (Most Control)\n\nCommand-line interface\nUse your own wallet\nBest for automation\n\nSDK (Programmatic)\n\nJavaScript/TypeScript or Go\nIntegrate into your apps\nBuild custom tools\n\nResource Units\n\nCPU: Measured in units (1 unit = 1 thread)\nMemory: Measured in Mi (Mebibytes) or Gi (Gibibytes)\nStorage: Measured in Mi or Gi\nGPU: Measured in units with specific model requirements\n\nExample: 0.5 CPU, 512Mi memory, 1Gi storage\n\nPricing\nAkash is significantly cheaper than traditional cloud providers:\n\nBasic web app: ~$1-3/month\nSmall API: ~$5-10/month\nGPU workload (RTX 4090): ~$50-150/month\n\nPrices vary by provider and demand.\n\nWhat You Can Update\nContainer image version\nEnvironment variables\nContainer commands\nCannot update: CPU, Memory, Storage amounts - Must create new deployment\n\nLearn More\nWant to understand Akash in depth?\n→ Detailed Core Concepts - Deep dive into deployments, providers, SDL, private containers, persistent storage, IP leases, and more.\n\nNext Steps\n\nQuick Start → - Deploy your first app\nSDL Reference → - Learn SDL syntax\nDiscord → - Get help from the community\n\nEdit page on github\n Quick Start How Funding Works","tokens":725,"squid":"spider-03","role":"Compute Spider","at":1791344423473,"hash":"e3383f631fb7b27d73a14f72c4e5d90b3cc3ae69"}
{"url":"https://forum.arbitrum.foundation/t/proposal-to-backfund-successful-stip-proposals-savvy-dao-final/19046/1","domain":"forum.arbitrum.foundation","title":"Proposal to Backfund Successful STIP Proposals (Savvy DAO) [FINAL] - Proposals / Finalized AIPs - Arbitrum","text":"The Arbitrum Foundation notified the Security Council on the need to perform a potential Emergency action. Following a review of the details and known risks, the Security Council decided to execute the upgrade and it was completed at 11:30 EST on 2nd October 2026.\nThis report provides an overview of the risks that required the Security Council Action:\n\nAdd a permissionless guard for the One-Step Proof of BoLD on Arbitrum One\n\nTemporarily pause activation of new Stylus contracts on Arbitrum One & Nova\n\nKey point: To date, known bugs for Stylus primarily impact chain liveness (e.g., denial of service attacks) and do not put any user funds at risk.\nWhy was this action taken\nLet’s take this opportunity to explain why action was taken on two separate issues concerning BoLD and Stylus.\nInstalling the guard for One-Step Proof of BoLD. Given the rise of AI-assisted attacks, we have implemented a precautionary approach that allows anyone to pause settlement of Arbitrum One on Ethereum if there are at least two conflicting answers that pass at the same level in which only one should be valid and pass. This is to halt a class of publicly verifiable and detectable attacks that exploit a bug in the one-step proof. If halted, Arbitrum One will continue to process as normal except that messages from Arbitrum One to Ethereum, such as withdrawals, that are not yet confirmed will have to wait. This provides time for the Security Council to deploy a fix for the bug and resume the rollup.\nPreventing activation of new Stylus contracts. AI-assisted tooling has led to an increasing number of sophisticated attacks on hand-crafted WASM programs that do not use the standard Stylus compiler toolchain. These programs are specifically designed to cause unexpected behaviors such as degrading the chain’s performance for all other users. To date, no attacks have been discovered that permits theft of user funds.\nNew ArbOS releases have patched several reported bugs and known attacks over the past few months, but out of an abundance of caution, we have decided to temporarily pause new activations of Stylus contracts. This was executed as an emergency action to prevent the deployment of new hand-crafted WASM programs that are not yet patched by the current version of ArbOS on the Arbitrum network.\nThe Arbitrum Foundation has informed the Security Council that they will work with the ArbitrumDAO to discuss next steps on the timeline and manner for enabling activation of new Stylus contracts. The Arbitrum community remains confident in the value of Stylus and want to preserve these use cases while taking preventative measures against Stylus-based attack vectors as AI-assisted attack tooling continues to evolve.\nImpact on builders and users\n\nNo new activations. New Stylus contracts cannot be activated during the pause including new versions of existing applications that require activation.\n\nExisting contracts are not paused. Already-active Stylus contracts continue to execute until expiration. This pause does not deactivate them.\n\nThe ArbOS 61 upgrade renewed all active contracts on Arbitrum One, so no currently active contract expires before August 20, 2027.\n\nRenewal via keepalive stays permissionless and is unaffected by the pause.\n\nReactivating an expired contract, or one that needs to be updated after a Stylus version change, is paused.\n\nUsing/calling any activated Stylus contract stays permissionless for all users and developers.\n\nNo impact on EVM. Solidity (EVM) contract deployment and execution are unaffected by this Security Council action.\n\nSecurity Council Actions\nThere are two actions bundled into a single payload:\n\nOne-Step Proof Guard. The L1UpgradeExecutor gives a new pause contract (PauseExecutor) the ability to pause and nothing else. The new pause contract grants the guard (OspSoundnessGuard) PAUSER_ROLE to use it. Anyone can show the guard two conflicting answers to the same step of an open challenge. If the one-step proof accepts both, the guard has the pause contract put Arbitrum One’s settlement to Ethereum on hold.\n\nStylus deactivation. The Security Council called ArbOwner.setWasmActivationGas(2^64 - 1) to raise the Stylus activation gas requirement on Arbitrum One and Nova. This makes activation prohibitively expensive and effectively disables new activations. This is a configuration change and does not require an ArbOS upgrade.\n\nThe Security Council signed the following transactions to update the configuration:\n\nEthereum: Ethereum Transaction Hash: 0x30732bb7d2... | Etherscan\nArbitrum One:\nArbitrum One Transaction Hash: 0x9eb3a4be3b... | Arbitrum One\nArbitrum Nova:\nArbitrum Nova transaction 0x79e0fed470dff7a22059b108e3f8f42eddd2b580a6771594060c4e7326c5f984 | Blockscout\n\nAn external audit was conducted for the OSP Guard contracts. No audit is required for the Stylus deactivation as it is only updating a single parameter in the ArbOS configuration.\n\n Proposal to Backfund Successful STIP Proposals (Savvy DAO) [FINAL] \n\n ProposalsFinalized AIPs\n\n proposal\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Oct 2023\n\n 1 / 120\n\n Oct 2023\n\n Feb 2024\n\n post by SavvyDAO on Oct 19, 2023\n\n SavvyDAO\n\n Empowering STIP to measure the impact of incentives for new builders\nUPDATE - we want to draw attention to a budget clarification that the total listed for Data and Monitoring for Plurality Labs (performed by OpenBlock Labs) is not 100K ARB but 149,500 ARB. The total ask of 21.52M remains unchanged.\nSTIP_Backfund_Opportunity3374×3374 884 KB\nCall to Action for Arbitrum ecosystem\nThis proposal represents a critical opportunity for our community to:\n\nSupport diverse, emerging builders and make Arbitrum a welcoming environment for new projects\nDouble the sample size and diversity of stages and categories in the STIP data set\nUphold constitutional values of Inclusion vs Exclusion\nAvoid potentially irreversible harm of crushing small, high potential builders\n\nNotes:\n\nThis proposal draft has been prepared by the Arbitrum STIP Inclusion Working Group following a series of community calls and workshops involving various stakeholders. As a preliminary document, it seeks input from both the Arbitrum DAO and the Liquidity Working Group.\nThis proposal frequently cites AIP-9.\nFor all of our resources see here: svy.gg/stip-backfund (DocSend)\n\nAbstract\nThis proposal outlines a one-time backfund to all \"approved but not funded proposals’’ from Arbitrum STIP. The proposed AIP increases the total budget by 21.4M to 71.4M while increasing the total participating protocols by 26, for a total of 56 funded projects. The program plans to allocate DAO-owned ARB towards incentives while leveraging distribution systems, consensus, and delegate diligence already created from STIP 1.\nThis program is designed to backfund approved protocols while maintaining the timelines and systems of STIP 1:\n\nTimeline: The program is scheduled to commence and conclude concurrently with STIP 1, or within a similar timeframe, starting from the first week of November and running through January 31, 2024.\nKYC: The program will utilize the same KYC system as STIP 1.\nReporting: Participating grantees are required to self-report data, maintain dashboards, and regularly summarize grant performance\n\nConsiderations\nBefore this proposal was drafted, a working group was formed to gauge sentiment, gather key data points, and outline the proposal’s structure. The working group collaborated with delegates and projects affected by the STIP, engaging in multiple calls—including sessions with the creators of the STIP and the Incentive Working Group—to solicit feedback and refine the proposal accordingly.\nKey concerns discussed include:\nWhy not just push towards a round 2 and go through voting for all proposals again?\nFirst and foremost, we believe that the successful execution of this Backfund proposal will, in time, serve as a crucial catalyst for future grant structures, including a successful STIP round 2. Why? This opportunity will unify the Arbitrum ecosystem by addressing key weaknesses in the original STIP 1 structure by quickly providing approved projects and other stakeholders with the resources/data needed to design and support future programs.\nKey issues associated with delaying an immediate backfund and moving towards a round 2 include:\n\nProper design and execution add considerable time delay to a highly competitive environment within Arbitrum and other L2s\nRequires teams with limited resources approved already for STIP 1 to spend significant time lobbying delegates\nRemoves attention away from new Round 2 proposals\nAdds additional burden to delegates that should be focused on long-term design improvements and new STIP grants not yet approved\nRemoves key data for STIP experiment analysis by skewing learnings towards larger, well-established projects\nDelays the alignment of the STIP with the Arbitrum constitution values of inclusivity and diversity\nNegatively impacts new builder sentiment towards Arbitrum at a critical time in the L2 Wars\n\nThe budget set aside was 50M, and the DAO decided that was the acceptable spend for a short-term incentive.\nWhile the budget was set at 50M, the original working group proposed 75M so that:\n\n“The budget was raised to 75M ARB to accommodate larger protocols (Pinnacle Grants) without compromising smaller applications.” tnorm, September 3rd 2023.\n\nExcess demand was a significant possibility due to the high interest in STIP and the absence of a cap for Pinnacle grants. Voters lacked the data to ascertain whether the initial 50M would be adequate to achieve the objectives of STIP.\nNoteworthy is that, in the event of excess demand, measures including backfunding were already outlined as potential options.\nProper design and fulfillment of a Round 2 or similar future funding programs may take time to develop. Meanwhile, projects that received approval but no funding have immediate initiatives requiring support. Our opportunity is to fund these initiatives, level the competitive playing field, and enhance the data available for the STIP process.\n1600×733 150 KB\n1458×832 92.8 KB\nVoting behaviors for a 50M proposal shouldn’t carry over to a proposal that includes the additional backfunded amounts.\nDuring our consultation process, we engaged in numerous discussions that brought forth questions about backfunding. Despite the criticisms, backfunding remains the most straightforward method to address the current STIP’s skewed sample size. We advocate that backfunding is the optimal approach to achieve the STIP’s intended outcomes—specifically, to examine the impact that incentives have on the growth of the Arbitrum ecosystem.\nFurthermore, if the STIP continues without rectifying the issues with its sample, the analysis will be compromised by a significant methodological flaw. Backfunding is not just the “best” option; it is essential for preserving the integrity of the STIP overall.\nVoting behavior might have differed if the budget cap were set at 75M or 100M. The only way to determine this would be to repeat the experiment with a raised cap (an option that is unfeasible as time travel has not yet been realized).\nIt’s helpful for us to remember the original objectives of the STIP:\n\nTo provide incentives to a diverse and inclusive group of Arbitrum projects.\nTo quickly establish an incentives program that is in harmony with Arbitrum’s values and constitution.\nTo generate robust, meaningful data to shape the future design of Arbitrum grants for projects of all types and sizes.\n\nMotivation\n\nMotivation - A statement on why the Arbitrum community should implement the AIP.\n\nHow can Arbitrum create an incentives structure to grow the ecosystem? STIP started when the community began investigating creative uses for incentives. A short-term program was devised to act quickly, collect data about how incentives are used by Arbitrum protocols, and learn from the results to design new programs and grow the Arbitrum Ecosystem.\nAn unexpected budget problem caused many successful STIP applications to receive no funding. The real-world consequence of this mistake caused the STIP sample to be cut in half - but not at random. To determine the final STIP cohort, the applications were sorted by approval, which inadvertently skewed the sample towards incumbent protocols. This sampling bias is most egregious for collecting data about the smallest protocols; over 70% of Beacon grants were rejected due to the sorting algorithm that was used. Consequently, STIP may not be collecting sufficient data about new builders on Arbitrum.\nThis AIP seeks to achieve STIP’s original motivations by:\n\nnearly doubling the sample size;\nadding protocols across a broad array of industry categories; and\nincluding protocols at different stages of development.\n\nThis AIP will ensure an important builder population is included in the study, while increasing the validity of the STIP results.\nOne of the most important questions facing Arbitrum today is how to grow the ecosystem and win the L2 Wars. STIP is a novel study on the impact of incentives for growing the Arbitrum ecosystem. In practice, the STIP excluded most new builders from the study, severely limiting the data that will be collected about the early stages of the builder pipeline. This AIP includes a broader range of protocols in the STIP study, ensuring that Arbitrum gets the data it needs about how incentives impact new builders in the Arbitrum ecosystem. It stands to reason that extending incentives to smaller projects could serve to incubate projects that grow into the high-usage dApps of tomorrow. Extending the STIP may not only increase the inclusivity of the program but also incentivize significant growth for the broader Arbitrum ecosystem at a lower cost per project, and this possibility is worth exploring.\nRationale\nRationale - An explanation of how the AIP aligns with the Arbitrum community's mission and guiding values\nArbitrum’s community values highlight the importance of diversity, which increases the fitness of the entire Arbitrum ecosystem by representing the needs of many kinds of participants. The original work to design STIP was careful to consider how both large and small protocols would fare under the framework. However, the unexpected budget cutoff caused the sample to skew towards large protocols, which is at odds with the values of the Arbitrum community. The cost of falling short of this ideal is that STIP systematically overlooks the possibility that incentives might be uniquely interesting to small and new protocols. By failing to incorporate protocols at the first stages of the builders onboarding pipeline, Arbitrum will be unsure about how incentives operate among this crucial group of protocols.\nThe Arbitrum community also values neutrality, which received careful consideration during the STIP design stages. It was well-understood that incumbent protocols were likely to prevail with their STIP applications - but it was hoped this would not preclude smaller participants from also being funded. Unfortunately, this wish for inclusion was not fulfilled and - unintentional though it may have been - funding was nevertheless distributed according to a ranking that was likely to favor incumbents. Again, despite the best efforts of the DAO and the STIP designers, the result was at odds with the values of the Arbitrum community.\nAbove all, Arbitrum seeks to create and nurture a thriving ecosystem - and the DAO’s values are designed to provide guiding values that will always trend towards the health of the ecosystem. When the values aren’t met - even unintentionally - it is possible the best interests of the ecosystem aren’t met, either. In the case of STIP, accidentally excluding Beacon grants falls short of the community values - which, in all likelihood, is a critical oversight that Arbitrum would benefit from fixing.\nKey Terms:\n\nApproved but not funded STIP proposals\nAIP-9\nBackfund\nExtension\nSTIP\nSTIP Round 1\nSTIP Backfunded\n\nSpecifications:\nSpecifications - A detailed breakdown of the platforms and technologies that will be used.\nWill approve funding of an additional 21.4M ARB through the end of January 31, 2024.\nPlease note the STIP Backfund will leverage the multiple sections of AIP-9 such as Specification section and Outstanding Questions and Concerns and specifically:\n\nFinancial Proposal\nMultisig Setup\nEligibility Requirements and Eligibility and Evaluation Guidelines.\nKPIs\n\nSteps to Implement -\nThe steps to implement the AIP, including associated costs, manpower, and other resources for each step where applicable. For the avoidance of doubt, any AIPs involving transactions with third parties (such as grants) will need to ensure that applicable legal documentation and procedures are also included.`\nSpecific Recipients and Amounts for Backfund Proposal\nWe used data provided by ARB STIP — raho.me to determine which successful STIP proposals did not receive funding. This list is also available via google docs.\nWhich protocols are included in this AIP?\nWe used data provided by https://www.raho.me/stip to determine which successful STIP proposals did not receive funding. This list is also available via google docs.\nThe 26 Backfunded Builders1920×1497 356 KB\nTotal ARB for backfund\n\n21.4M ARB\n26 protocols\n\nProject\nARB Amount\n\nWOOFi\n1,000,000\n\nGains Network [1]\n4,500,000\n\nDefiEdge\n200,000\n\nSynapse\n2,000,000\n\nPancakeSwap [2]\n2,000,000\n\nRabbitHole [3]\n1,000,000\n\nNotional\n500,000\n\nRodeo Finance\n250,000\n\nMagpie\n1,250,000\n\nStargate Finance\n2,000,000\n\nSavvy\n200,000\n\nTales of Elleria\n50,000\n\nThales\n500,000\n\nTIDE\n80,000\n\nSolv Protocol\n150,000\n\nFurucombo\n59,500\n\ndForce\n1,000,000\n\nSanko GameCorp\n500,000\n\nRamses\n1,248,000\n\nVela\n1,000,000\n\nThetanuts Finance\n200,000\n\nJoJo\n200,000\n\nWormhole\n1,800,000\n\nShell Protocol\n750,000\n\nRealm\n300,000\n\nunshETH\n375,000\n\nStakeDAO\n200,000\n\nWINR [4]\n38,000\n\n[1] Gains Network originally asked for 7M ARB, but reduced their ask to 4.5M ARB. See announcement.\n[2] PancakeSwap has removed their proposal from consideration because of KYC requirements.\n[3] RabbitHole’s inclusion in backfunding would replace their proposal titled: “Proposal: Grow Arbitrum & STIP Teams by leveraging Quest Protocol built by RabbitHole”\n[4] Currently, WINR will receive 462,000 of their ask - with backfunding WINR would receive 500,000.\nOverall Cost\nOverall Cost - The total cost to implement the AIP.\nOverall Cost - 71.4M ARB\nProjected Timeline\nTimeline - Relevant timing details, including but not limited to start date, milestones, and completion dates.\n*Note: Timeline may change based on option selected or amount of work needed to update and develop. For DAO proposals and voting procedures please see Section 2 in the constitution.\n\nPhase\nDate / Duration\nTitle\nDescription\n\nPhase 1: Temp check (1 week)\nTh, Nov 2nd\nDraft posted to forum\nDiscussion hosted on forum, revisions to draft, broader working group call and revisions to AIP.\n\nMon, Nov 6th\nTemp check posted to snapshot by sponsor delegate\nReconvene in forum to post results and conclude temperature check.\n\nPhase 2: Formal AIP and call for voting (3 days):\nTues, Nov 8th\n\nPhase 3: DAO votes on AIP, on Arbitrum One (14-16 days):\nThurs, Nov 10th\nSnapshot vote begins(submit to Tally)\nDuring this Phase 3, the ArbitrumDAO will be able to vote directly on-chain on a submitted AIP. Vote to approve AIP for non-constitutional funding. Tally voting: Quorum ~71.4M ARB; greater than 50% voting in favor.\n\nThurs, Nov 24th\nDAO vote ends, results are final\n\nPhase 4: L2 Waiting Period (3 days)\nWait\nWaiting period of 3 days; then schedule on-chain txs to disburse ARB\n\n SEED Latam Delegate Communication Thread\n\n Arbitrum Treasury and Sustainability - Working Group\n\n [RFC] Incentives Detox Proposal\n\n Incentive Program Assessments & Recommendations\n\n 9\n\n 6\n\n 4\n\n 4\n\n 4\n\n read \n\n 42\n min\n\n post by stonecoldpat on Oct 19, 2023\n\n post by Englandzz_Curia on Oct 19, 2023\n\n post by Viperr on Oct 19, 2023\n\n post by dk3 on Oct 19, 2023\n\n post by JoePadawan1 on Oct 19, 2023\n\n post by Dog on Oct 19, 2023\n\n post by Dog on Oct 19, 2023\n\n post by Englandzz_Curia on Oct 19, 2023\n\n post by sahijeevan on Oct 19, 2023\n\n post by JoePadawan1 on Oct 20, 2023\n\n post by Manualtesar on Oct 20, 2023\n\n post by DanThales on Oct 23, 2023\n\n post by bflynn on Oct 23, 2023\n\n post by SavvyDAO on Oct 23, 2023\n\n post by padzank on Oct 24, 2023\n\n post by Djinn on Oct 24, 2023\n\n post by omw2kokomo on Oct 26, 2023\n\n post by SavvyDAO on Oct 27, 2023\n\n post by sahijeevan on Oct 31, 2023\n\n Load more posts below","tokens":5143,"squid":"spider-07","role":"Council Spider","at":1791344435053,"hash":"88619b9ab9093f1445a4db7ac33465081117bd04"}
{"url":"https://akash.network/docs/api-documentation/getting-started/","domain":"akash.network","title":"API Documentation | Akash Network Documentation","text":"API Documentation Integrate Akash Network into your applications with SDKs and APIs \nIntegration Options\n Console API \nRecommended\n Deploy via REST API with managed wallets and credit-card billing — no crypto, no blockchain node, no key management for your end users. Also serves public indexed network data. Managed Deployments API key required • Building SaaS platforms• Offering deployments to non-crypto users• User-friendly deployment interfaces• No wallet management overhead Deployment API → Network Data Public — no auth • Querying provider availability and specs• Finding GPU resources on the network• Building dashboards and analytics• Network monitoring tools Network Data API → Akash Blockchain SDK Full blockchain integration with your own wallet Best for: • Building deployment automation tools• Creating custom deployment workflows• Provider management dashboards• Monitoring and analytics tools Payment: AKT or USDC cryptocurrency Explore Blockchain SDK → Blockchain REST/RPC Query the chain directly via an Akash node (gRPC, REST, RPC). For chain state and transactions. Best for: • Querying chain state (balances, deployments, validators)• Submitting transactions to the blockchain• Tooling that talks to an Akash node Note: Use a node endpoint; Console API is indexed data, not a node. Node API Layer → \nBlockchain SDK Documentation\n SDK Overview Official Go and JavaScript/TypeScript SDKs Quick Start Deploy your first application programmatically API Reference Complete SDK documentation and methods Examples Code examples for common tasks AuthZ & Fee Grants Manage permissions and sponsored transactions \nDeployment REST API Documentation\n API Overview REST API for credit card deployments via Console Getting Started Set up authentication and make your first API call API Reference Complete endpoint documentation \nConsole API — Network Data (indexed)\n Console API — Network Data Indexed data: providers, GPU, stats. Not a node. Providers API Query provider details, specs, and availability GPU Availability Guide Find and filter GPU resources across providers \nNeed Help?\n Discord - #developers channel GitHub - Contribute to Akash","tokens":539,"squid":"spider-03","role":"Compute Spider","at":1791344445363,"hash":"b74e87c7831f6881eb4e8dfefaf51ece77e1688e"}
{"url":"https://forum.across.to/t/initial-thinking-around-token-distribution/38/37","domain":"forum.across.to","title":"Initial thinking around token distribution - Tokenomics (old) - Across Protocol","text":"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 Nov 2021\n\n 37 / 37\n\n Mar 2022\n\n Mar 2022\n\n Load more posts above\n\n post by Momo95 on Nov 17, 2021\n\n post by Raypok on Nov 17, 2021\n\n post by jeffrey on Nov 17, 2021\n\n post by Apokalypse on Nov 18, 2021\n\n post by Alisa on Nov 21, 2021\n\n post by long9332 on Nov 21, 2021\n\n post by kawa on Nov 21, 2021\n\n post by AmyUFO on Nov 21, 2021\n\n post by eqing.eth on Nov 21, 2021\n\n post by heropunk.eth on Nov 25, 2021\n\n post by Banditx0x on Nov 27, 2021\n\n post by Psalm6figs on Dec 1, 2021\n\n post by MrHeviDi on Dec 1, 2021\n\n post by MrHeviDi on Dec 1, 2021\n\n post by CarlosJuanCarlos on Dec 1, 2021\n\n post by MrHeviDi on Dec 2, 2021\n\n MrHeviDi\n\n Remember - there are POAPS to \n\n 15 days later\n\n post by Werlda_Hert on Dec 17, 2021\n\n Werlda_Hert\n\n I’m not sure if this is a premature question, but, do we know which DAOs have a similar enough structure to what Across DAO might become, that we could interview or use their token structure as a reference?\n\n 3 months later\n\n post by NFb on Mar 18, 2022\n\n NFb\n\n motif\n\n How was the sushi system? Can you give details\n\n post by maoge.eth on Mar 21, 2022\n\n maoge.eth\n\nThat’s a great idea. I agree with you\n\n post by hakan5353 on Mar 21, 2022\n\n hakan5353\n\n Interesting ideas I like it\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Across Token Launch Proposal\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 214\n\n May 2022\n\n What the token does?\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 25\n\n Apr 2022\n\n Across Token Launch Proposal v2\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 47\n\n Nov 2022\n\n Second ACX Drop\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 15\n\n Feb 2024\n\n Welcome to Across\n\n WELCOME 👋\n\n WELCOME 👋\n\n Nov 2022","tokens":443,"squid":"spider-09","role":"Bridge Spider","at":1791344445517,"hash":"29bcea76c991a148ba13b311dadab8745b8db988"}
{"url":"https://forum.arbitrum.foundation/t/proposal-to-backfund-successful-stip-proposals-savvy-dao-final/19046/135","domain":"forum.arbitrum.foundation","title":"Proposal to Backfund Successful STIP Proposals (Savvy DAO) [FINAL] - Proposals / Finalized AIPs - Arbitrum","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 4\n\n 4\n\n read \n\n 42\n min\n\n Oct 2023\n\n 120 / 120\n\n Feb 2024\n\n Feb 2024\n\n Load more posts above\n\n post by Shoos on Nov 15, 2023\n\n Shoos\n\n dk3\n\nFoundation grants have been in the talks for many projects since beginning of the year and have no bearing on the STIP. If you have a project that is of interest to the Foundation, nothing is stopping anyone at any point from putting in a proposal to them.\nDelegate votes should have taken into account potential for back funding as back funding is clearly declared and stated in the STIP documentation\nimage936×534 105 KB\nAppetite for grants will always be there regardless of how the distribution is done\nGroups that did not make it into round 1 cut off also made adjustments in order to try to make the cut off as well. It was not just adjustments being made at the top of the stack, the majority of projects made changes in order to try to be accommodated.\nWhat?\n\n post by SavvyDAO on Nov 19, 2023\n\n SavvyDAO\n\n UPDATE - we want to draw attention to a budget clarification that the total listed for Data and Monitoring for Plurality Labs (performed by OpenBlock Labs) is not 100K ARB but 149,500 ARB. The total ask of 21.52M remains unchanged. (also pinning this post)\n\n post by BlockworksResearch on Nov 21, 2023\n\n BlockworksResearch\n\n We are voting no to the STIP backfund. We would like the DAO to revisit the idea of another short term incentives program once the first round of applicants have spent the ARB already allocated. This way analysts can look at the data and evaluate how beneficial the STIPs actually were. In order to efficiently/effectively allocate ARB in the future, delegates need to if/know how much ARB incentives hurt the underlying price, how much TVL and fee revenue changes, whether or not new users are onboarded to Arbitrum, and other important metrics. We would also suggest capping the amount of ARB available to projects to ensure more protocols are included in the allocation next time. January 31st is only 2 months away and we do not believe the benefit of getting this done quickly outweighs the advantage of using data from STIP round 1 for future incentive endeavors.\n\n post by Djinn on Nov 21, 2023\n\n Djinn\n\n Is there a reason why Blockworks did not vote in the temp check or engage in any of the conversations here on the forums or the myriad of other comms channels?\nPretty disappointing to see, but at least the community gets to see some rationale of your decision after your decision.\n\n post by Pioneer on Nov 21, 2023\n\n Pioneer\n\n After the original STIP allocation was distributed (mostly uncapped and favoring already massively established projects ahem), there have been plenty of opportunities to contribute to the discussion of this backfund. The results?\nOverwhelmingly positive by all those who actually participated in the discussion. I urge the community and our delegates- please don’t let this blunder of over expenditure towards a handful of projects be what drives small startups and innovation away. What we see here are the few gate keeping the many.\nGood job, decentralization.\n\n post by Blazar on Nov 22, 2023\n\n Blazar\n\n Question, so for those who are stuck in this voting process, if this vote fails to pass, then we will not get an opportunity to apply for STIP round 2. How do we consider those protocols that might have wanted to make a submission, but are waiting for the results of this vote?\n\n post by Dog on Nov 22, 2023\n\n Dog\n\nCurious why an AGAINST vote was submitted now? Did anything materially change since this post? Would appreciate some transparency and what swayed your thoughts.\nEdit: I see the comment on Tally now, still would like clarity on what changed.\n\n post by peter on Nov 22, 2023\n\n peter\n\n I believe they want to include Round 2 too and the backfund will likely deteriorate the previous vote for STIP integrity.\n\n post by Midgetwhale on Nov 22, 2023\n\n Midgetwhale\n\n Dog\n\n It’s important to remember that when MUX first put up their draft for a grant they asked for 9 Million ARB.\n9M ARB for a GMX v1 clone that integrated Gains and GMX as an aggregator on top.\nThen they abstained for every vote during the STIP.\nBut now they really want to express themselves and deny 21.4M ARB to a group of 26 Protocols.\n\n post by realdumbird on Nov 22, 2023\n\n realdumbird\n\n Dog\n\nMostly because of these reasons that were indicated in the original comment:\n\nThe 25+ proposals in this backfund bundle have mixed quality; some are worthy of support, while some are questionable, considering the protocol fundamentals, incentives execution strategies, and actual grant requested.\n\nIt would be more reasonable to have the proposals being voted on individually in a round 2 type of event instead of binding all the proposals together.\n\nThe term “inclusion” was used frequently in this conversation to back up the intention. However, it seems the phrase has been used to dodge the fact that the original grant size was set according to supply & demand + DAO treasury fund management concerns instead of being “exclusive”.\n\nRound 1 was made possible by DAO members advocating for a framework so more protocols and builders who are building projects with solid fundamentals and clear benefits to the ecosystem can be supported. Some of the claims that tried to twist the original intention in this forum thread are a bit sickening to see.\n\nPassing the quorum wasn’t a solid reason to back up the claim for a “guaranteed” grant; Passing the quorum + making it to the cutoff line was, given the fact that the VOTED size for the first STIP was 50M.\n\nWe hope the backfund attempt won’t become a recurring behavior that will always happen after all STIP types of events\n\nAlthough MUX delegates would love to support many individual proposals included in this bundle, the delegates can’t seem to align with the bundle backfund approach. Several proposals involve strategies that can simply initiate sybil-attack type of transactions that will likely boost transactions when the incentives are live, and then the majority of the “ingenuine” addresses will leave after the incentives run out. We simply won’t want to see that happen cuz that will waste DAO funds for nothing. Again, we would love to support many individual proposals included in the backfund proposal, and would have been ideal if it were individual voting.\n\n post by Lothaen on Nov 22, 2023\n\n Lothaen\n\n You could have supported many of the protocols with the round 1 stip and voting for those you deemed suitable rather than abstaining.\nNow your team deems it necessary to block instead of abstain.\nTo me this feels like another maneuver to give certain projects a longer runway against their competition.\n\n post by realdumbird on Nov 22, 2023\n\n realdumbird\n\n Midgetwhale\n\n As an aggregator, MUX’s proposal has always been using the grant toward 4 perps protocols with a combined liquidity depth of $550M+, with the goal of using the grant to cross the fee barrier and onboard more real traders for the ecosystem and multiple protocols. The increased volume will also mean higher income for GLP, GM, gDAI, MUXLP, and all of the protocols and pools built on top of them. Based on this context, the original 9M size was proposed. It would’ve been more reasonable to include the context than using numbers only to point fingers.\nIn addition, after realizing the total grant size from all proposals was very high during the review period, MUX was one of the first protocols to voluntarily lower the size to 6M with a 30% drop (one of the highest drop, plus this happened during the review period, not one day before voting period ended ), while still keeping the original execution strategy even when that means the campaign will end earlier than expected.\n\n post by realdumbird on Nov 22, 2023\n\n realdumbird\n\n Lothaen\n\n MUX voted “For” for many of the proposals included in the backfund proposal during round 1 if you checked the record. Voting “Agansit” doesn’t mean we are not supporting some of these proposals, since I have indicated in every comment so far that MUX delegates would love to support many individual proposals included in this bundle, but the delegates can’t seem to all align with the bundle backfund approach.\n\n post by Djinn on Nov 22, 2023\n\n Djinn\n\n realdumbird\n\n I don’t understand what changed between temp check and snapshot.\nYour proposal combined with your main integration partner’s ask amounted to almost 50% of the total STIP ask.\nNow we are hearing about issues with ‘budget’ when the majority of the STIP rd 1 budget was taken by 3-4 protocols.\n\n post by Smith on Nov 22, 2023\n\n Smith\n\n realdumbird\n\n Which projects do you expect to initiate “sybil-attacks”?\n\n Redistribute Savvy's STIP Allocation to Other Approved Projects until It Conducts Ethical Practices\n\n post by cheekybastard on Nov 27, 2023\n\n cheekybastard\n\nIf Sybil attacks gaming transactions with STIP incentives are a plausible concern, then Sybil attacks on individual protocol proposal voting should also be considered a concern. The potential for profit is greater with griefing individual protocol proposal voting, as it’s not capped by grant size.\nIf a protocol token can be short margin traded, there is an opportunity for significantly more profit using the ancient Italian gambit (gambetto, before chess), the act of tripping someone with the leg to make them fall. For example, voting Against & Abstain can be used maliciously against an individual competitor protocol, enabling predictable profitable short margin trades or price drops for profitable spot trades.\nThe DAO does not conduct Sybil checks. This absence of systems to monitor for Sybil and self-dealing necessitates proposal bundling. When proposals are voted on individually, it creates an opportunity for profitable Sybil attacks and facilitates self-dealing. On the other hand, bundling aligns interests; it becomes highly implausible for many attacks to affect the entire bundle without being obvious and unprofitable.\nPreliminary network analysis of STIP round one, shows self-dealing happens. A delegate, not MUX, who openly opposed and voted against a particular protocol, has profited from trading(last day of STIP voting) the token of the protocol they both, openly advocated against & voted against. Individual proposals cater to self-interest when there are no systems to conduct Sybil & self-dealing checks.\nFinally, I agree that certain projects ought to be excluded, but on verifiable, testable, objective values regarding security and trust. For instance, hypothetically, if they deploy into production unaudited contracts, omit critical information from incentives proposals or finger prints link to a sybil attack.\n\n post by Plutus on Nov 30, 2023\n\n Plutus\n\n Plutus has decided to vote against the proposed backfunding approach. We acknowledge the good intentions behind this proposal but believe there are more effective strategies to consider.\nTo begin with, the initial voting decisions in Round 1 were based on specific rules that included the possibility of a Round 2 extension. Incorporating a backfunding approach at this stage might have influenced these decisions differently, potentially altering the outcomes significantly. Furthermore, numerous protocols tailored their proposals in response to the initial rules. Changing the approach now could render these adjustments ineffective.\nAdditionally, we prefer to review a detailed proposal and subsequent discussion for Round 2 and its interplay with the backfunding approach before making any commitments with DAO funds. The backfunding proposal involves a substantial sum, over 20 million ARB, and there’s a concern that these proposals might compete for the same resources.\nLastly, the backfunding approach aggregates incentives for several protocols, which might inadvertently exclude those anticipating a second round. We advocate for a system that emphasizes merit and inclusivity. This can be achieved through a distinct second STIP round, with its own set of transparent rules and individual voting for each proposal.\n\n post by krst on Dec 1, 2023\n\n krst\n\n The below response reflects the views of L2BEAT’s governance team, composed of @krst and @Sinkas, and it’s based on the combined research, fact-checking and ideation of the two.\nAs we explained during temp-check, we were originally hesitant with the proposal, but most of our concerns have been addressed since. Given that nothing changed to the extent that it would cause us to have new concerns, and since the team behind the proposal has been very actively working on pushing forward a STIP Round 2, we’ll be voting in favour of the proposal in the on-chain vote as well.\n\n L2BEAT Delegate Communication Thread\n\n post by Arbitrum on Dec 3, 2023\n\n Arbitrum\n\n The on-chain AIP to backfund successful STIP proposals has passed!\nCongratulations to the 26 projects that are eligible for the backfunding. The Arbitrum Foundation, with the STIP multi-sig’s buy-in, is tasked by the STIP proposal to handle all KYC/KYB checks on teams who are eligible to receive the funds and for arranging the Grant Agreements to be signed prior to the ARB disbursement.\nAs next steps, please follow the instructions in this post to kickstart the compliance process.\n\nUpon receipt of the email, the Foundation will start the compliance process with a third party service provider.\nAll formal communication will be conducted over email with compliance@arbitrum.foundation. Please double-check all email addresses and, if in doubt you may contact @stonecoldpat or @cliffton.eth on the forum.\n\n 2 months later\n\n post by KarlaGod on Feb 6, 2024\n\n KarlaGod\n\n Love the fact that successful projects that meet the criteria will have their proposals in, looking forward to Bitsave’s Success in Q4 on Arbitrum.\nWill keep updated on 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 Extension of Arbitrum’s Short-Term Incentive Program\n\n Grants Discussions\n\n 99\n\n 12.9k\n\n Nov 2023\n\n Double-Down on STIP Successes (STIP-Bridge)\n\n Finalized AIPs\n\n proposal\n\n 96\n\n 9.0k\n\n Aug 2024\n\n Arbitrum’s Short-Term Incentive Program (Arbitrum Improvement Proposal)\n\n Finalized AIPs\n\n aip\n\n 135\n\n 37.0k\n\n Aug 2024\n\n GFX Labs Delegate Communication Thread\n\n Delegate Statements\n\n delegation,delegate-statements\n\n 105\n\n 7.2k\n\n Jun 17\n\n Uniswap-Arbitrum Delegate Program (UADP) Communication Thread\n\n Delegate Statements\n\n delegation,delegate-statements\n\n 99\n\n 5.2k\n\n 22d","tokens":3636,"squid":"spider-07","role":"Council Spider","at":1791344455281,"hash":"4fbec528b8e949a193910525c49045940aba334c"}
{"url":"https://forum.across.to/c/8-category/8","domain":"forum.across.to","title":"Latest WELCOME 👋 topics - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n Latest topics in WELCOME 👋\n\n WELCOME 👋\n\n tags\n\n Latest\n\n Top\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n posted\n Nov 27\n\n by @Britt\n\n Across Governance Operating Manual\n\n Overview\nThe Across governance process will evolve to meet the needs of Across DAO as it grows, and this is a living document. Anyone can participate in the Across Governance process, and anyone with ACX voting power can…\n\n read more\n\n 3\n\n posted\n Nov 27\n\n by @Britt\n\n Proposal Template\n\n Use the template below when creating your proposal. A passing proposal must include these components, and authors are encouraged to add any additional context that provides value. \n\nTitle: (enter proposal title) \nAuthor(…\n\n read more\n\n 2\n\n posted\n Nov 10\n\n by @Britt\n\n Welcome to Across\n\n Welcome to the Across Forum. This space has previously been used to share ideas and iterate on early attempts at governance. As we lead up to the token launch, this space may evolve a bit to make room for official Across…\n\n read more\n\n 11","tokens":1744,"squid":"spider-09","role":"Bridge Spider","at":1791344458006,"hash":"46b774accacb14a7ee7090aee453828d2c4a8f5e"}
{"url":"https://ethresear.ch/t/ethresear-ch-email-login-will-be-disabled-in-7-days/7369/11","domain":"ethresear.ch","title":"Ethresear.ch: email login will be disabled in 7 days - 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 3\n\n 3\n\n 2\n\n May 2020\n\n 10 / 16\n\n May 2020\n\n Oct 2021\n\n post by hwwhww on May 8, 2020\n\n Pinned globally on May 8, 2020\n\n post by vbuterin on May 8, 2020\n\n post by hwwhww on May 8, 2020\n\n post by axic on May 8, 2020\n\n post by hwwhww on May 8, 2020\n\n post by axic on May 8, 2020\n\n axic\n\nI see. But wouldn’t it be possible to add a field for “ENS name” in discourse (like now there’s the email field + github link) so the linking happens?\nAlternatively (though I am not a big fan due to the privacy aspect) EIP-634 could be used to link an ENS record to an email.\n\n post by kmichel on May 9, 2020\n\n kmichel\n\n Successfully logged in with it.\n\n post by vbuterin on May 9, 2020\n\n vbuterin\n\n axic\n\nBy ENS transfer you mean what happens if an ENS name is transferred to another account? Wouldn’t the natural answer be “well, for future logins start verifying signatures against that new account instead of the current one”? What’s the problem?\n\n post by hwwhww on May 9, 2020\n\n hwwhww\n\nI believe we can add ENS name (or, ETH account) field in discourse. And then, we need to ask the GitHub login user to manually update that field to claim that “the one who has this ENS name / ETH account is me”. So when the user uses Eauth login later, it will be able to bind to the existing account.\n\nRight, adding the email field in ENS can also solve the password recovery issue on discourse! I understand why we may be against it, we are trying to dogfood with a decentralized solution, but we still want the email system to prevent a user from losing their properties forever. \n\nYes.\n\nI think the authentication follows the authorized controller of the ENS name, and use ENS name as the default handle name? It doesn’t take ENS as the first-class when searching for an associated account (ping @Ping to verify it).\n\n Somewhat time critical — How do I set a password?\n\n post by Ping on May 9, 2020\n\n Ping\n\n @virgil suggests that we can use ethmail.cc by default, but at present ethmail seems not so well functioned and decentralized. \nIn Eauth scenario, account address is the primary key. And for ENS you need to not only own an ENS but also set it as your address’s reverse lookup name, then it would be displayed as your nickname.\nBTW, Eauth supports contract address login with EIP1271. I highly recommend this one. You can have multiple authenticate keys, timelock, social recovery, and lots of good stuff, without overhead to the platform. \nLogin with: Gnosis safe / Argent / Authereum / Dapper / etc\ncode: GitHub - pelith/node-eauth-server: An OAuth-compatiable service based on Ethereum credentials to authenticate users on a website. See live version at https://eauth.pelith.com/ https://forum.hakka.finance\ndemo: https://eauth.pelith.com/\nDiscourse + Eauth prototype: https://discourse-ens.pelith.com/\n\n post by vbuterin on May 10, 2020\n\n vbuterin\n\n I definitely like eauth!\n\n post by gkapkowski on May 13, 2020\n\n post by gkapkowski on May 13, 2020\n\n post by gkapkowski on May 13, 2020\n\n 1 year later\n\n post by x on Oct 22, 2021\n\n Powered by Discourse","tokens":781,"squid":"spider-04","role":"Research Spider","at":1791344460501,"hash":"b1fa250705b358210a098005a992ba81a0fa7fe4"}
{"url":"https://forum.arbitrum.foundation/t/extension-of-arbitrum-s-short-term-incentive-program/18800/1","domain":"forum.arbitrum.foundation","title":"Extension of Arbitrum’s Short-Term Incentive Program - Archive / Grants Discussions - Arbitrum","text":"The Arbitrum Foundation notified the Security Council on the need to perform a potential Emergency action. Following a review of the details and known risks, the Security Council decided to execute the upgrade and it was completed at 11:30 EST on 2nd October 2026.\nThis report provides an overview of the risks that required the Security Council Action:\n\nAdd a permissionless guard for the One-Step Proof of BoLD on Arbitrum One\n\nTemporarily pause activation of new Stylus contracts on Arbitrum One & Nova\n\nKey point: To date, known bugs for Stylus primarily impact chain liveness (e.g., denial of service attacks) and do not put any user funds at risk.\nWhy was this action taken\nLet’s take this opportunity to explain why action was taken on two separate issues concerning BoLD and Stylus.\nInstalling the guard for One-Step Proof of BoLD. Given the rise of AI-assisted attacks, we have implemented a precautionary approach that allows anyone to pause settlement of Arbitrum One on Ethereum if there are at least two conflicting answers that pass at the same level in which only one should be valid and pass. This is to halt a class of publicly verifiable and detectable attacks that exploit a bug in the one-step proof. If halted, Arbitrum One will continue to process as normal except that messages from Arbitrum One to Ethereum, such as withdrawals, that are not yet confirmed will have to wait. This provides time for the Security Council to deploy a fix for the bug and resume the rollup.\nPreventing activation of new Stylus contracts. AI-assisted tooling has led to an increasing number of sophisticated attacks on hand-crafted WASM programs that do not use the standard Stylus compiler toolchain. These programs are specifically designed to cause unexpected behaviors such as degrading the chain’s performance for all other users. To date, no attacks have been discovered that permits theft of user funds.\nNew ArbOS releases have patched several reported bugs and known attacks over the past few months, but out of an abundance of caution, we have decided to temporarily pause new activations of Stylus contracts. This was executed as an emergency action to prevent the deployment of new hand-crafted WASM programs that are not yet patched by the current version of ArbOS on the Arbitrum network.\nThe Arbitrum Foundation has informed the Security Council that they will work with the ArbitrumDAO to discuss next steps on the timeline and manner for enabling activation of new Stylus contracts. The Arbitrum community remains confident in the value of Stylus and want to preserve these use cases while taking preventative measures against Stylus-based attack vectors as AI-assisted attack tooling continues to evolve.\nImpact on builders and users\n\nNo new activations. New Stylus contracts cannot be activated during the pause including new versions of existing applications that require activation.\n\nExisting contracts are not paused. Already-active Stylus contracts continue to execute until expiration. This pause does not deactivate them.\n\nThe ArbOS 61 upgrade renewed all active contracts on Arbitrum One, so no currently active contract expires before August 20, 2027.\n\nRenewal via keepalive stays permissionless and is unaffected by the pause.\n\nReactivating an expired contract, or one that needs to be updated after a Stylus version change, is paused.\n\nUsing/calling any activated Stylus contract stays permissionless for all users and developers.\n\nNo impact on EVM. Solidity (EVM) contract deployment and execution are unaffected by this Security Council action.\n\nSecurity Council Actions\nThere are two actions bundled into a single payload:\n\nOne-Step Proof Guard. The L1UpgradeExecutor gives a new pause contract (PauseExecutor) the ability to pause and nothing else. The new pause contract grants the guard (OspSoundnessGuard) PAUSER_ROLE to use it. Anyone can show the guard two conflicting answers to the same step of an open challenge. If the one-step proof accepts both, the guard has the pause contract put Arbitrum One’s settlement to Ethereum on hold.\n\nStylus deactivation. The Security Council called ArbOwner.setWasmActivationGas(2^64 - 1) to raise the Stylus activation gas requirement on Arbitrum One and Nova. This makes activation prohibitively expensive and effectively disables new activations. This is a configuration change and does not require an ArbOS upgrade.\n\nThe Security Council signed the following transactions to update the configuration:\n\nEthereum: Ethereum Transaction Hash: 0x30732bb7d2... | Etherscan\nArbitrum One:\nArbitrum One Transaction Hash: 0x9eb3a4be3b... | Arbitrum One\nArbitrum Nova:\nArbitrum Nova transaction 0x79e0fed470dff7a22059b108e3f8f42eddd2b580a6771594060c4e7326c5f984 | Blockscout\n\nAn external audit was conducted for the OSP Guard contracts. No audit is required for the Stylus deactivation as it is only updating a single parameter in the ArbOS configuration.\n\n Extension of Arbitrum’s Short-Term Incentive Program \n\n ArchiveGrants Discussions\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Oct 2023\n\n 1 / 100\n\n Oct 2023\n\n Nov 2023\n\n post by 0xRamen on Oct 12, 2023\n\n 0xRamen\n\n Hey all, I am 0xRamen from Ouroboros Research, the research arm of Ouroboros Capital.\nWe’ve been watching the voting progress closely using this live dashboard we built.\n\nArbitrum Short-Term Incentive Program (STIP) Oversubscription\nAt present (T-10 hours to vote end), ~29 projects fit into the 50m ARB budget.\nIn addition, there is currently a list of 26 projects with 1) 71.51m ARB quorum and 2) >50% in favor votes, which have collectively asked for 24.4m ARB worth of grants.\nimage939×593 25.7 KB\nimage941×656 31.3 KB\nGiven that >50m ARB request fulfill the quorum and voting criteria, a round 2 will no longer be held if there are no further votes to extend the framework.\n\nIt is apparent that there is significantly more appetite to approve grants than had expected, with 74m worth of grants or 1.5 times the amount of initially approved budget currently tracking for approval, implying 74% of total requested ARB grants being approved.\n\nExtension of STIP Grants\nWe believe that an extension of the grant program is warranted.\nOur reasoning is as follows:\n\nFairness: Exceeding 50m ARB was a somewhat unexpected outcome. Unfortunately, there were projects that were 1) waiting to apply in round 2 or 2) missed the deadline in round 1. Now with no round 2 happening, these projects will be denied of the opportunity to apply for the grant, which we think is somewhat arbitrary. The list of projects that have kickstarted round 2 applications is here.\n\nGrant diversity: For an ecosystem to thrive, we believe it is not only important to have large hallmark projects but also a diversity of smaller projects that have the potential to grow into ecosystem stalwarts. The top 5 requesters which are currently eligible collectively have 27m ARB requested. Extending the grant program will allow the DAO to honor its initially promised rules while letting in more smaller projects the opportunity to help grow the ecosystem.\n\nWe do understand that the initial consensus was leaning towards a 25/50m ARB grant program size rather than 75m. However, we do think that after going through the first round of pitches, opinions might have changed and from the voting results, we see that voting participants do think more projects should receive the grant than previously thought.\nThere have already been lively debates in the initial STIP thread. In our view, the quantum of extension should be chosen by the DAO, which we think could be:\n\nDo not extend\nExtend STIP by 10m ARB\nExtend STIP by 20m ARB\nExtend STIP by 30m ARB\n\n [STIP Monitoring - Objective 1&2] - Ouroboros Research - [FINAL]\n\n Proposal to Backfund Successful STIP Proposals (Savvy DAO) [FINAL]\n\n 5\n\n 4\n\n 4\n\n 4\n\n 4\n\n read \n\n 24\n min\n\n post by 0xRamen on Oct 12, 2023\n\n 0xRamen\n\n We’ve come to the end of round 1.\nAdding the list of confirmed recipients:\nimage852×787 62.1 KB\nand the list projects achieving quorum & >50% in favor votes but did not make the cut off:\nimage849×572 27.8 KB\n\n post by Synth on Oct 13, 2023\n\n Synth\n\n Its only fair for the protocols which have reached quaroum but did not make it, to also have a share of another batch of 50mil ARB\n\n post by Dog on Oct 13, 2023\n\n Dog\n\n 0xRamen\n\n As one of the projects on the list I am obviously coming from a stance of bias, but even with that aside— I think this list of protocols shown, that did not get an allocation but passed quorum in favor, include many high quality builders and contributors to the Arbitrum ecosystem.\nWith the recent clawback of the unclaimed airdropped ARB, there exists enough to cover the remaining 24m, and then some. I think there’s a compelling case to be made here since ~74m passed and one of the original ask options was 75m.\nThe main thing I believe in extending the rest of the budget to the rest of the protocols is to ensure increased opportunities on Arbitrum during the following months, plus to prevent stifling projects who can’t compete with those who passed.\nHappy to hear the opinion of others but I think the overall benefits outweigh any downsides.\n\n post by ZIsBraindead on Oct 13, 2023\n\n ZIsBraindead\n\n Even just 20M more ARB, less than half of the original STIP, would give so many more protocols that were voted in favour of an allocation.\nThe purpose of grants is not to benefit the largest players with even more backing, but to allow the smaller guys a chance to prove themselves (especially in this STIP), so I believe it would be beneficial to extend the STIP amount to somewhere between 70M-75M. There is really not much downside.\n\n post by Mantis on Oct 13, 2023\n\n Mantis\n\n Its self-evident the current STIP framework lacked nuance having well-established non-native projects pooled with Arbitrum native projects (90% probably launching amidst this bear market).\nPersonally, if we want to stay true to the standard logic behind grant initiatives and how they typically function, the allocation should be extended to projects that made quorum but missed out on an allocation.\nThis will help enable long term blockchain usage, supporting native projects to continue to apply maximum bandwidth on the Arbitrum blockchain.\nAdditionally, it shows future innovators and builders that they can recieve support if decided to build on Arbitrum, despite competing against large, chain agnostic projects.\nThanks for your time.\n\n post by Trantor on Oct 13, 2023\n\n Trantor\n\n 0xRamen\n\n It is great news that we are able to have this discussion as it demonstrated the passion and commitment that protocols and the community have for our ecosystem. The other side of the coin could have been almost nobody voting!\nSo to my mind, this proposal is an easy win for the entire ecosystem!\nExtending the grant by the additional 25M (or 20M or 30M) will see many of the projects who did very well get their allocation and thus avoid having the biggest protocols simply get the biggest grants because they are already the biggest. ie, just cementing their positions.\nThe wider these grants are spread to quality projects, who have support (ie over 70M votes and more than 50% in favor), the better. Increased capital flows are a benefit to all and the more it is spread amongst builders the better!\n\n post by Jonezee on Oct 13, 2023\n\n Jonezee\n\n Concur with the sentiment that an extension would be just, considering a number of good projects didn’t make the cut because of a budget limitation rather than a lack of support.\n\n post by Shoos on Oct 13, 2023\n\n Shoos\n\n The DAO’s treasury allocation should be able to accommodate this requested increase as it was an option on the initial proposal when determining grant amount. By implementing this adjustment, the projects achieving quorum will all have the opportunity these incentives provide. This not only upholds the principles of fairness but also acts as a catalyst for innovation and diversity within our ecosystem.\nIt’s also worth noting that a significant number of projects that secured allocations from the initial 50 million grant have received funding in the past, which could solidify their dominant position. Without providing incentives to the rest, there’s the potential that established projects become complacent, with no real motivation to compete and innovate, propping up their platforms using grants alone. All the while, the upcoming projects struggle against the grant ARB being distributed, regardless of the tech the top projects are using.\n\n post by relied on Oct 13, 2023\n\n relied\n\n While I do understand that there is disappointment from some participants / protocols, this is the natural outcome of the 2 step vote we had. First the maximum program size is approved, then protocols apply with the reasonable asks and it is voted on the total of those applications. If the overall size of the grant program would´ve been bigger to begin with it surely would have led to bigger asks and eventually to a similar outcome with disappointment, same for a smaller overall program size.\nWhile I am not against a second round / additional funding I do think the focus now should be on the execution of the first stage and to follow the spending of the approved funds and the contribution to growth of the arbitrum ecosystem. Starting an extension of the program right away undermines and devalues the steps that have been taken by the DAO to get this program started and should be postponed to a later stage, in my opinion.\n\n post by kiryu_0x on Oct 13, 2023\n\n kiryu_0x\n\n In favor of 20m ARB to 30m ARB here. I think one thing that is obvious if you look at the chart is that projects that were larger were more likely to get voted in at a higher position. They have larger communities. So smaller projects asking for smaller amounts were largely the ones who made quorum and had enough yes votes, yet were not able to get enough votes.\nThe outcome of “Do you get a grant or not” should be decided by the result of the vote on a case by case basis. The way this proposal was setup, it put larger protocols in the front of the line.\n\n post by Chuba on Oct 13, 2023\n\n Chuba\n\n Agreed for an extension here as well, for projects which made the quorum, which was the main target to receive the grant. The 1st come 1st served basis was there in case too many projects were successful, but it shouldn’t limit Arbitrum expansion. Enough people voted FOR for each of them.\nOnce this final process is ended, we could start thinking about giving the funds to all projects. Let’s remain focus and logic.\nHave a great day, my fellow arbinauts !\n\n post by zdeadex on Oct 13, 2023\n\n zdeadex\n\n In terms of diversity, i’m still wondering why it’s allowed to ask for more than 20% of the total grant for only project.\nThe cap should have been below 10%, which is still too much (probably 2% so 2M cap per project - looking at data it makes sense).\nI do believe than 10 projects requesting less than 1M $ARB is worth than 1 requesting 10M $ARB, even if it’s a big protocol.\nSaying this, I think extending to a round 2 make sense with determined cap per project.\n\n post by Lunaman on Oct 13, 2023\n\n Lunaman\n\n There are two main issues we have detected with the way the STIP process has been designed.\n1.) Teams shouldn’t be spending time and resources lobbying to delegates. Of course the time that was given to review all proposals was minimal taking into account all projects that applied for the program so teams had to resort to private communications with delegates instead of having public discussions that would benefit all projects.\n2.) The design of the program forced projects into competition instead of promoting collaboration between all of arbitrum’s builders. We should have done a budget per category where all the protocols per category would collaborate and come up with a unified budget that would need to get approved by the DAO. I think we are promoting the wrong values with this STIP design and should be corrected immediately to, again, foster innovation AND collaboration instead of competition.\n\n post by 0xAlpha on Oct 13, 2023\n\n 0xAlpha\n\n The primary objective of STIP is to enhance Arbitrum’s ecosystem by drawing in more developers and community engagement. As the first round stands, the top five eligible requesters have collectively sought 27m ARB. Extending the grant program adheres to the DAO’s initial commitments, also opening doors for more projects to contribute to the ecosystem’s growth.\n0xRamen’s post concerning the STIP extension aligns with this aim. We ardently support this initiative and are optimistic that the Arbitrum DAO will provide solutions fostering a robust growth within the Arbitrum community.\n\n post by Nailax1 on Oct 13, 2023\n\n Nailax1\n\n I support your suggestion\nI think DAO needs to consider extending the time, some projects are very good but I see they do not receive grants from Arbitrum\n\n post by bflynn on Oct 13, 2023\n\n bflynn\n\n I’m for extending this by 20M.\nIf the grant is extended by 20M, then according to the stack ranking from Round 1, an additional 20 projects will receive grants, which is a clean number. It’s worth noting that 29 projects received grants with the current 50M budget, so this will be a substantial increase and lead to a more diverse Arbitrum ecosystem.\nIt’s important that the Arbitrum DAO supports new projects in the ecosystem and rewards projects that have ambitious plans to expand the ecosystem with good proposals. This will result in not just more competition, but more innovation in the Arbitrum ecosystem which is a net positive for ARB holders.\nIt’s also worth noting that we should avoid these types of proposals in the future. This was a huge burden to ARB delegates, who felt pressured to sift through the 100 applications in just a week. I don’t think any delegate enjoyed this process, and we should work on creating proper accountability & transparency systems to grant recipients so we can iterate on results.\n\n post by Achi on Oct 13, 2023\n\n Achi\n\n Advocating for an extension by 20m or 30m here. Given the unforeseen explosion in popularity of this grant program, it is highly advisable to broaden its scope and include other projects that have successfully met the quorum requirements. This initiative has absolutely no downside; quite the opposite, it stands to significantly benefit our ecosystem.\nThis extension not only ensures that more deserving projects receive crucial support, but it also serves as a substantial boost to the overall health of the ecosystem. By nurturing native projects and expanding their horizons, we are actively contributing to the growth and development of our ecosystem as a whole. So, let’s proceed this expansion in mind, knowing that it’s a win-win scenario for all involved.\n\n post by 0xMasterCrypto on Oct 13, 2023\n\n 0xMasterCrypto\n\n I am in favor of the 30M ARB add. The top 5 projects got the majority of the allocation with 27M ARB. Some of those projects, with larger TVL indeed, are less efficient than other smaller native projects.\nIts evident that the way this grant approval process was set up was unfair. There should have been a grant cap per project and ARB allocation should have been awarded by other metrics like efficiency instead of just TVL/MC/FDV.\n\n post by Mummy on Oct 13, 2023\n\n Mummy\n\n Extending the amount of Arb is def something that should be done to integrate a greater part of the network since the top 5 projects took half the grant for all the projects in the network.\n\n Load more posts below","tokens":4886,"squid":"spider-07","role":"Council Spider","at":1791344466493,"hash":"97934048ac8e231e9fc72232e83ec3f96bdb5723"}
{"url":"https://ethresear.ch/t/ethresear-ch-email-login-will-be-disabled-in-7-days/7369/10","domain":"ethresear.ch","title":"Ethresear.ch: email login will be disabled in 7 days - 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 3\n\n 3\n\n 2\n\n May 2020\n\n 9 / 16\n\n May 2020\n\n Oct 2021\n\n post by hwwhww on May 8, 2020\n\n Pinned globally on May 8, 2020\n\n post by vbuterin on May 8, 2020\n\n post by hwwhww on May 8, 2020\n\n post by axic on May 8, 2020\n\n post by hwwhww on May 8, 2020\n\n hwwhww\n\n We can have multiple authorization options at the same time.\nIf we have both email login and GitHub oauth (as status-quo), and they can be merged together automatically well since the GitHub account identifier is the email you used to register GitHub account.\nBut for Eauth case, since you don’t register your Ethereum address / ENS with an email address, it will create a new discourse account when you use Eauth login. (@Ping please correct me if I’m wrong!)\n\n post by axic on May 8, 2020\n\n axic\n\nI see. But wouldn’t it be possible to add a field for “ENS name” in discourse (like now there’s the email field + github link) so the linking happens?\nAlternatively (though I am not a big fan due to the privacy aspect) EIP-634 could be used to link an ENS record to an email.\n\n post by kmichel on May 9, 2020\n\n kmichel\n\n Successfully logged in with it.\n\n post by vbuterin on May 9, 2020\n\n vbuterin\n\n axic\n\nBy ENS transfer you mean what happens if an ENS name is transferred to another account? Wouldn’t the natural answer be “well, for future logins start verifying signatures against that new account instead of the current one”? What’s the problem?\n\n post by hwwhww on May 9, 2020\n\n hwwhww\n\nI believe we can add ENS name (or, ETH account) field in discourse. And then, we need to ask the GitHub login user to manually update that field to claim that “the one who has this ENS name / ETH account is me”. So when the user uses Eauth login later, it will be able to bind to the existing account.\n\nRight, adding the email field in ENS can also solve the password recovery issue on discourse! I understand why we may be against it, we are trying to dogfood with a decentralized solution, but we still want the email system to prevent a user from losing their properties forever. \n\nYes.\n\nI think the authentication follows the authorized controller of the ENS name, and use ENS name as the default handle name? It doesn’t take ENS as the first-class when searching for an associated account (ping @Ping to verify it).\n\n Somewhat time critical — How do I set a password?\n\n post by Ping on May 9, 2020\n\n Ping\n\n @virgil suggests that we can use ethmail.cc by default, but at present ethmail seems not so well functioned and decentralized. \nIn Eauth scenario, account address is the primary key. And for ENS you need to not only own an ENS but also set it as your address’s reverse lookup name, then it would be displayed as your nickname.\nBTW, Eauth supports contract address login with EIP1271. I highly recommend this one. You can have multiple authenticate keys, timelock, social recovery, and lots of good stuff, without overhead to the platform. \nLogin with: Gnosis safe / Argent / Authereum / Dapper / etc\ncode: GitHub - pelith/node-eauth-server: An OAuth-compatiable service based on Ethereum credentials to authenticate users on a website. See live version at https://eauth.pelith.com/ https://forum.hakka.finance\ndemo: https://eauth.pelith.com/\nDiscourse + Eauth prototype: https://discourse-ens.pelith.com/\n\n post by vbuterin on May 10, 2020\n\n post by gkapkowski on May 13, 2020\n\n post by gkapkowski on May 13, 2020\n\n post by gkapkowski on May 13, 2020\n\n 1 year later\n\n post by x on Oct 22, 2021\n\n Powered by Discourse","tokens":889,"squid":"spider-04","role":"Research Spider","at":1791344472051,"hash":"004eac733be7951d586d26f93a037a22ee380223"}
{"url":"https://forum.arbitrum.foundation/t/extension-of-arbitrum-s-short-term-incentive-program/18800/110","domain":"forum.arbitrum.foundation","title":"Extension of Arbitrum’s Short-Term Incentive Program - Archive / Grants Discussions - Arbitrum","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 5\n\n 4\n\n 4\n\n 4\n\n 4\n\n read \n\n 24\n min\n\n Oct 2023\n\n 100 / 100\n\n Nov 2023\n\n Nov 2023\n\n Load more posts above\n\n post by Hubirb on Oct 26, 2023\n\n Hubirb\n\n maxlomu\n\n Agreed rules were not very clear, they kept changing.\nInitially, it was supposed to be first come first serve. That’s what was voted on Snapshot. Then it changed to this random number of yes vote which makes no rational sense.\nAlso, it was also voted as part of the STIP the possibility of an extension in case of the progrom being oversubscribed.\nFinally, delegates voted on a proposal by proposal basis which is what they were missioned to. The PVP part was not part of the exercise. I don’t think any delegate withdrew their vote on one side to favor one project over the other, seeing the project being oversubscribed.\n\n post by blue on Oct 26, 2023\n\n blue\n\n Same protocols, same people. Where are the new projects? Where are the new excited devs willing to build on Arbitrum? Prioritizing Round 1 is giving priority to large groups and stifling good intentions that require way less funding. Many have prepared for Round 2 and it is quite disappointing wait for a final decision. There aren’t dev-rel projects, how do we expect to create solutions directly in code, culture etc? I hope for a Round 2 and concrete solutions instead of same liquidity and rewards programs.\n\n post by MattOnChain on Oct 26, 2023\n\n MattOnChain\n\n I am a strong believer that it makes sense to wait until after round 1 has concluded and proper analysis (multiple!) have been done before funding another round, given that 3 months is an extremely short period of time. This way, we can take into account lessons learned from round 1 surrounding what types of incentives work best in order to maximize the value of treasury funds toward future expenditure. Additionally, the voting process in round 1 had many inefficiencies that need to be addressed in any further STIPs.\n\n post by blazedbison on Oct 26, 2023\n\n blazedbison\n\n maxlomu\n\n Max the original STIP post (that eventually passed) states that it would be an option for the DAO to choose to backfund successful incentive proposals … if budget is exceeded, no?\nThis proposal is well within the original rules/guidelines?\n\n post by maxlomu on Oct 27, 2023\n\n maxlomu\n\n image1127×233 25.9 KB\nRules highlighted above.\nI don’t think an extension of the STIP round 1 is fair - While I support the idea of creating a round 2, or a new independent proposal.\n\n post by bflynn on Oct 27, 2023\n\n bflynn\n\nRules highlighted above.\n\nThe next sentence after your highlight is part of the rules as well, is it not @Max?\n\n post by maxlomu on Oct 27, 2023\n\n maxlomu\n\n Not a rule, but an option for the DAO.\nOne that I support as a separate round, as I have expressed before.\n\n post by blazedbison on Oct 27, 2023\n\n blazedbison\n\n Respectfully, why should projects that went to so much effort to be included in round 1, and that campaigned hard to meet quorum AND received over 50% For votes, have to go through the process a 2nd time? Why would we not just reward those projects and extend the grant to them when\ni. The demand was totally unprecedented (a good thing)\nii. The vast majority are smaller, new, and different (read: not defi) projects that could contribute massively to the ecosystem\niii. The unclaimed airdrop amount was more than expected and would easily cover the ~ 22m additional being requested?\nAnyway, I look forward to the AIP for the extension going live and hope you and other delegates can see that this is a net positive for the Arb ecosystem\n\n post by Lunaman on Oct 29, 2023\n\n Lunaman\n\n To be honest, I still fail to understand the arguments against backfilling the projects that met the criteria and didn’t get funded.\nIf these projects met the requirements it is because the great majority of the DAO’s voting power assessed the proposals and deemed them valid of getting the grant. The reason that these projects did not get filled comes from the fact that we pulled the figures of 25M, 50M and 75M $ARB out of a hat without first probing around to figure out if this even sufficient to satisfy demand. The total demand was for around 120M $ARB and the DAO decided that projects’ requests amounting to around 74M $ARB should pass and get the funding, that’s the only valid piece of data we have. Everything else are just conjectures and what ifs.\n\n post by ArbOG on Oct 29, 2023\n\n ArbOG\n\n MattOnChain\n\n Very bad take, we’ve dropped the ball on not forecasting properly demand for STIP in terms of total ARB required. We’ve allowed for backroom deals and most delegates-connected protocols to meet the threshold and get funded. Arbitrum is not 29 projects. If swift extension with round 2 doesn’t get voted in, it will be catastrophic to rest of the ecosystem projects that can’t compete with others due to zero sum game. You should know better Matt, you guys specialize in research right? How about some research piece on the impact of 100s of Arbitrum projects that will suffer major decline in activity and potentially be forced to seek activity outside of Arbitrum ecosystem because they can’t compete without incentivization. 3 months of time is enough to create permanent damage to ecosystem with negative long term impact. Who knows but this type of unbiased research could actually score you some points for your coalition proposal ( feedback coming soon )\nThe STIP voting results made it clear, the process favors protocols selected by essentially the top 3 delegators to be winners. This punishes those who are not among the chosen (and those who didn’t submit their STIP proposal in time), with little regard to the value they provide to the ecosystem. As a result, they are destined to be short term losers and might even end up turning lights off for good.\nFor example, in coming months Uniswap and Sushi will lose volume to Camelot, TraderJoe and Balancer due to incentivization. Premia, Dopex, Rysk and Good Entry will dominate over Hegic, Lyra and other A+ option protocols, yet without incentives Hegic currently organically dominates options category in terms of fees ( top 8 in fees from all protocols on arbitrum in last 30 days per defilama ) . Where is the logic in punishing indirectly Hegic here for example? Why aren’t “research” firms asking those questions? Unless protocols come up with their own incentivizes to compete, they will underperform.\nI’ve listened to your spaces on Friday and it seems like you, @maxlomu, Gauntlet and few other large delegates internally agreed to go against any extension plans. To me it looks more like a coup against Arbitrum ecosystem. Please provide some stats on potential positive / negative impact that no additional funding + round 2 will have on rest of the ecosystem. We can’t drop another ball here on all the legit projects that are building in the space and simply want to fairly compete with those that got grants approved and soon to be funded.\nTo summarize - Arbitrum risks losing builders and legit projects because of zero sum game. You can’t compete organically with incentivized projects hence 29 projects will succumb most of activity in their respected categories, where the rest will suffer drop in activity.\nWe need to act NOW, without unnecessary delays and support plans for extension and round 2. I’m completely outraged that some of the large delegates don’t see this or choose to turn the blind eye on destructive impact this decision might have on entire ecosystem.\n\n Proposal to Backfund Successful STIP Proposals (Savvy DAO) [FINAL]\n\n post by dennison on Oct 30, 2023\n\n dennison\n\n Hey folks!\nDennison from @tally.xyz here!\nThe STIP proposal has been incredible to see, so much activity! I’ve been thinking about this problem a bit: allocating incentive funding across a diverse ecosystem of builders.\nI was curious as I go through the problem maze- would it make sense to set a budget that is distributed to teams based on the percentage of votes they win, potentially with a cap? (So that there is an upper ceiling to the grant with the expectation that more teams could be funded?)\nAnother way of doing it might be to set a budget, and then allocate some number of spots to fund, with each spot receive a decreasing portion of funds? So Top spot gets 10% of the budget, second spot gets 7%, and so on and so on?\nWhile I’m not addressing the current discussion about a round two, I am thinking about how at Tally we could help make this process more scalable and inclusive for everyone.\n\n post by Djinn on Oct 30, 2023\n\n Djinn\n\n Hey Dennison, I think certain grant structures could definitely have some sort of weighted distribution of funds in an overflow scenario.\nFor this specific STIP framework, the data to back budgeting wasn’t there - and it was very difficult to project with unlimited proposal limits for the largest projects, BUT the creators knew this and had backup options just incase the exact overfunding scenarios were met, which is great.\nAn extension reduces workload on everyone, and adjusts a weakness of the STIP process into a strength that supports all projects across verticals and project size.\nMy concern around having a scaling funding model like you mentioned is that it hurts the smallest projects with the least political pull even more than the STIP process currently does, and it just means that their already smaller asks would be trimmed down even more.\nAnother option would be a way to just proportionally allocate funds based on the amount proposed, as long as the proposal passed quorum and other requirements.\n\n post by dennison on Oct 30, 2023\n\n dennison\n\n Hmm yeah thats a great point, what if there was a maximum cap as well as a minimum cap? You of course will still need the political strength to be included at all, but at least a minimum cap would mean folks don’t get percentage wise pennies.\n\n post by Djinn on Oct 30, 2023\n\n Djinn\n\n That could make sense, I think the challenge is creating a framework that sits as the foundation of future grants but offering levers like caps, max allocations, overflow mechanics that can adjust per each grant type.\nKeep up the good feedback.\n\n post by dennison on Oct 30, 2023\n\n dennison\n\n Thanks! I’ll keep thinking about this, there is probably some MVP version of this which could streamline the process more so that we could do it more often and for more types of things. I’m excited to think about it!\n\n 8 days later\n\n post by mint_cloud on Nov 7, 2023\n\n mint_cloud\n\n 0xRamen\n\n ICYMI there’s a new vote ending on 11/14 pushing for option 2.\nI will vote against it as I believe we should\nOption 1: Continue with round 2. Continue with the existing program structure where we hold a round 2, everyone from round 1 who had not qualified can retry in round 2. Supporters - @limes @DanThales @mint_cloud @deBridge\nselfishly we from matcha.xyz were awaiting round 2 to apply and find it not unfair to not been given the opportunity to participate\nhttps://snapshot.org/#/arbitrumfoundation.eth/proposal/0xc040de9c6a85dee5ca15de10691165bf5595245ffac922cbef61e45199522345\n\n post by SavvyDAO on Nov 7, 2023\n\n SavvyDAO\n\n dennison\n\n Dennison. Thanks so much for the awesome feedback!\nAs I mentioned to @mint_cloud in the STIP Backfund Proposal post, we have put together an STIP Inclusion Working Group that is thinking about Backfund AND round 2 - would love to add you. We believe they work better TOGETHER.\nWe are having an AMA tomorrow to discuss the STIP Backfund and Frisson is joining us. Would love if you also attended!\nPlease reach out - tg: AlexLumley\n\n post by dennison on Nov 7, 2023\n\n dennison\n\n Thanks! I’ll see if I can attend! (Not sure, but yeah excited to see this come together)\n\n post by mint_cloud on Nov 9, 2023\n\n mint_cloud\n\n SavvyDAO\n\n thanks @SavvyDAO , it’s great to hear a round 2 is in motion too. It looks like I defaulted to quickly on the hypothesis that backfunding round 1 implied a less likely round 2. I will hit you up on tg, talk to you soon \n\n post by SavvyDAO on Nov 9, 2023\n\n SavvyDAO\n\n Appreciate the support ser!\nPlease let us know when you have reached out - haven’t seen your message come through yet. =)\n\n Related topics\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 Backfund Successful STIP Proposals (Savvy DAO) [FINAL]\n\n Finalized AIPs\n\n proposal\n\n 119\n\n 18.2k\n\n Feb 2024\n\n STIP - Round 1: Voting Period Update\n\n Short Term Incentives Program (STIP) Round 1\n\n 8\n\n 2.4k\n\n Oct 2023\n\n Arbitrum’s Short-Term Incentive Program (Arbitrum Improvement Proposal)\n\n Finalized AIPs\n\n aip\n\n 135\n\n 37.0k\n\n Aug 2024\n\n How to Apply - Arbitrum Short Term Incentives Program\n\n Short Term Incentives Program (STIP) Round 1\n\n 41\n\n 7.8k\n\n Nov 2023\n\n Double-Down on STIP Successes (STIP-Bridge)\n\n Finalized AIPs\n\n proposal\n\n 96\n\n 9.0k\n\n Aug 2024","tokens":3218,"squid":"spider-07","role":"Council Spider","at":1791344478069,"hash":"1de16e58cd6a3163d74ecd3138c9adbb17540fab"}
{"url":"https://forum.across.to/c/8-category/8/l/top","domain":"forum.across.to","title":"Top WELCOME 👋 topics - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n Top topics in WELCOME 👋\n\n WELCOME 👋\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 posted\n Nov 10\n\n by @Britt\n\n Welcome to Across\n\n Welcome to the Across Forum. This space has previously been used to share ideas and iterate on early attempts at governance. As we lead up to the token launch, this space may evolve a bit to make room for official Across…\n\n read more\n\n 11\n\n posted\n Nov 27\n\n by @Britt\n\n Across Governance Operating Manual\n\n Overview\nThe Across governance process will evolve to meet the needs of Across DAO as it grows, and this is a living document. Anyone can participate in the Across Governance process, and anyone with ACX voting power can…\n\n read more\n\n 3\n\n posted\n Nov 27\n\n by @Britt\n\n Proposal Template\n\n Use the template below when creating your proposal. A passing proposal must include these components, and authors are encouraged to add any additional context that provides value. \n\nTitle: (enter proposal title) \nAuthor(…\n\n read more\n\n 2","tokens":1746,"squid":"spider-09","role":"Bridge Spider","at":1791344483552,"hash":"713354e07e68e74f4b0b360b0897316e599d4406"}
{"url":"https://forum.arbitrum.foundation/t/stip-round-1-voting-period-update/18725","domain":"forum.arbitrum.foundation","title":"STIP - Round 1: Voting Period Update - Archive / Short Term Incentives Program (STIP) Round 1 - Arbitrum","text":"The Arbitrum Foundation notified the Security Council on the need to perform a potential Emergency action. Following a review of the details and known risks, the Security Council decided to execute the upgrade and it was completed at 11:30 EST on 2nd October 2026.\nThis report provides an overview of the risks that required the Security Council Action:\n\nAdd a permissionless guard for the One-Step Proof of BoLD on Arbitrum One\n\nTemporarily pause activation of new Stylus contracts on Arbitrum One & Nova\n\nKey point: To date, known bugs for Stylus primarily impact chain liveness (e.g., denial of service attacks) and do not put any user funds at risk.\nWhy was this action taken\nLet’s take this opportunity to explain why action was taken on two separate issues concerning BoLD and Stylus.\nInstalling the guard for One-Step Proof of BoLD. Given the rise of AI-assisted attacks, we have implemented a precautionary approach that allows anyone to pause settlement of Arbitrum One on Ethereum if there are at least two conflicting answers that pass at the same level in which only one should be valid and pass. This is to halt a class of publicly verifiable and detectable attacks that exploit a bug in the one-step proof. If halted, Arbitrum One will continue to process as normal except that messages from Arbitrum One to Ethereum, such as withdrawals, that are not yet confirmed will have to wait. This provides time for the Security Council to deploy a fix for the bug and resume the rollup.\nPreventing activation of new Stylus contracts. AI-assisted tooling has led to an increasing number of sophisticated attacks on hand-crafted WASM programs that do not use the standard Stylus compiler toolchain. These programs are specifically designed to cause unexpected behaviors such as degrading the chain’s performance for all other users. To date, no attacks have been discovered that permits theft of user funds.\nNew ArbOS releases have patched several reported bugs and known attacks over the past few months, but out of an abundance of caution, we have decided to temporarily pause new activations of Stylus contracts. This was executed as an emergency action to prevent the deployment of new hand-crafted WASM programs that are not yet patched by the current version of ArbOS on the Arbitrum network.\nThe Arbitrum Foundation has informed the Security Council that they will work with the ArbitrumDAO to discuss next steps on the timeline and manner for enabling activation of new Stylus contracts. The Arbitrum community remains confident in the value of Stylus and want to preserve these use cases while taking preventative measures against Stylus-based attack vectors as AI-assisted attack tooling continues to evolve.\nImpact on builders and users\n\nNo new activations. New Stylus contracts cannot be activated during the pause including new versions of existing applications that require activation.\n\nExisting contracts are not paused. Already-active Stylus contracts continue to execute until expiration. This pause does not deactivate them.\n\nThe ArbOS 61 upgrade renewed all active contracts on Arbitrum One, so no currently active contract expires before August 20, 2027.\n\nRenewal via keepalive stays permissionless and is unaffected by the pause.\n\nReactivating an expired contract, or one that needs to be updated after a Stylus version change, is paused.\n\nUsing/calling any activated Stylus contract stays permissionless for all users and developers.\n\nNo impact on EVM. Solidity (EVM) contract deployment and execution are unaffected by this Security Council action.\n\nSecurity Council Actions\nThere are two actions bundled into a single payload:\n\nOne-Step Proof Guard. The L1UpgradeExecutor gives a new pause contract (PauseExecutor) the ability to pause and nothing else. The new pause contract grants the guard (OspSoundnessGuard) PAUSER_ROLE to use it. Anyone can show the guard two conflicting answers to the same step of an open challenge. If the one-step proof accepts both, the guard has the pause contract put Arbitrum One’s settlement to Ethereum on hold.\n\nStylus deactivation. The Security Council called ArbOwner.setWasmActivationGas(2^64 - 1) to raise the Stylus activation gas requirement on Arbitrum One and Nova. This makes activation prohibitively expensive and effectively disables new activations. This is a configuration change and does not require an ArbOS upgrade.\n\nThe Security Council signed the following transactions to update the configuration:\n\nEthereum: Ethereum Transaction Hash: 0x30732bb7d2... | Etherscan\nArbitrum One:\nArbitrum One Transaction Hash: 0x9eb3a4be3b... | Arbitrum One\nArbitrum Nova:\nArbitrum Nova transaction 0x79e0fed470dff7a22059b108e3f8f42eddd2b580a6771594060c4e7326c5f984 | Blockscout\n\nAn external audit was conducted for the OSP Guard contracts. No audit is required for the Stylus deactivation as it is only updating a single parameter in the ArbOS configuration.\n\n STIP - Round 1: Voting Period Update \n\n ArchiveShort Term Incentives Program (STIP) Round 1\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n Oct 2023\n\n 1 / 10\n\n Oct 2023\n\n Oct 2023\n\n post by Matt_StableLab on Oct 11, 2023\n\n Matt_StableLab\n\n Hello Arbitrum DAO,\nAt the current pace of the Short-Term Incentives Program, it appears the 50 Million ARB budget will be exceeded. I will continue to monitor this as the voting period continues but wanted to outline the different possible scenarios.\nIf the 50 Million ARB budget is reached:\nSTIP only includes 50M in funding. If this limit is reached in Round 1 there will be no Round 2 of the program.\nShould the DAO wish to extend this framework, it may create a second proposal to either extend the budget for STIP to fund a Round 2 program OR create a proposal for an additional program to help meet the community’s extended demand for grants.\nIf the 50 Million ARB budget is NOT reached:\nThe remaining funds will be used for Round 2.\nRound 2 submissions may begin October 13, 2023 12:00 AM EST and are due by October 20, 2023 11:59 PM EST.\nIn the event that only a small amount of funding is left, it may not make sense to have a second round for only a tiny amount of funding. In this case, the DAO may vote to end the program early, extend this program with an added budget, or implement a new program.\n\n Arbitrum's Short-Term Incentive Program (Arbitrum Improvement Proposal)\n\n How to Apply - Arbitrum Short Term Incentives Program\n\n 2\n\n Pinned on Oct 11, 2023\n\n post by Matt_StableLab on Oct 11, 2023\n\n Matt_StableLab\n\n UPDATE: 50M ARB Budget Reached:\nAs of now the 50M ARB budget for STIP has been exceeded. This means there will be no Round 2 as there is no budget remaining.\nShould the DAO wish to extend this framework, it may create a second proposal to either extend the budget for STIP to fund a Round 2 program OR create a proposal for an additional program to help meet the community’s extended demand for grants\nI will continue to provide updates on the status of the funding as the voting period comes to an end.\n\n Extension of Arbitrum’s Short-Term Incentive Program\n\n post by DanThales on Oct 11, 2023\n\n DanThales\n\n Can the exact methodology of how the 50m will be allocated, in the case that the total voted in sum is larger, be expanded upon?\nNamely, it says that the sorting will be done by votes in favor and there will be a hard cut off at 50m. Are “votes in favor” only the FOR votes, or the difference between FOR and AGAINST?\nDo abstain votes count towards quorum?\nLastly, not a question per se, but it definitely seems fairer to try to come up with a pro rata distribution across all STIPs that were voted in, then have a hard binary cut-off. Like in case the total sum is 55m, all STIPs could be paid out with a 10% reduction.\n\n post by ArbDefender on Oct 11, 2023\n\n ArbDefender\n\n Abstain votes always count towards quorum.\nNow having more than 50mm allocated, we need to see those with less FOR votes, those will be left out.\nOn a first stance for example that Lido ends up with 40mm FOR and 39mm Negative and XX Abstain, then they will be left out (im putting Lido as example as they are the ones with most negative votes or less FOR votes).\nFor extending the 50MM ARB distribution, i think to better wait to see how this plays out and maybe end of November see if we extend the program or not. Maybe just better to wait for next year.\n\n post by Kapyrus on Oct 12, 2023\n\n Kapyrus\n\n Going down the road by choosing only on “for” votes, we have 27 Projects included right now.\nSorting out by ratio for/against includes 35 Projects.\nsomething like top ratio projects with for-votes equal to at least quorum requirement? around 72 Million votes, right?\n\n post by Grandma on Oct 13, 2023\n\n Grandma\n\n Given the cut-off today breached the 50m mark… and the previous statement was that all 50m would be awarded as the cut-off… WINR Protocol, for instance, which was right at the cut off, on paper earned a sizable portion of its 500k request… we are assuming that partial amount will be granted, yes?\nThanks for the clarity.\n\n post by Tenzent on Oct 13, 2023\n\n Tenzent\n\n Would also love some clarity on this for the protocols right at the cutoff. Perhaps a list with numbers would be good.\nI think the biggest learning and take away for next vote/program/extension/whatever is decided should be to move the system to Ranked Choice Voting.\nThis way projects can express votes in a much more sophisticated manner and no delegate is encouraged to not vote on a proposal. I also thought @cattin and the SEED LATAM community did an amazing job doing exactly this but manually, only voting for 50M of ARB worth grants. RCV would be a huge improvement to the way things are currently being done but Romang explained some of the other benefits better than I below:\n\n post by mint_cloud on Oct 16, 2023\n\n mint_cloud\n\n Matt_StableLab\n\n hi @Matt_StableLab , Theo from Matcha (matcha.xyz) / 0x (0x.org) here. We were preparing a proposal from our side and just discovered this.\nWould you recommend posting the proposal on the main Incentive Framework (Round 1) queue or use the Round 2 tag instead?\nThanks in advance\n\n post by chiragmahapatra on Oct 18, 2023\n\n chiragmahapatra\n\n Is there an update on if Round 2 will be happening?\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Extension of Arbitrum’s Short-Term Incentive Program\n\n Grants Discussions\n\n 99\n\n 12.9k\n\n Nov 2023\n\n How to Apply - Arbitrum Short Term Incentives Program\n\n Short Term Incentives Program (STIP) Round 1\n\n 41\n\n 7.8k\n\n Nov 2023\n\n STIP Grant Recipients Update\n\n Short Term Incentives Program (STIP) Round 1\n\n 0\n\n 3.8k\n\n Dec 2024\n\n Proposal to Backfund Successful STIP Proposals (Savvy DAO) [FINAL]\n\n Finalized AIPs\n\n proposal\n\n 119\n\n 18.2k\n\n Feb 2024\n\n Should large players side step the STIP program?\n\n Grants Discussions\n\n 10\n\n 890\n\n Oct 2023","tokens":2721,"squid":"spider-07","role":"Council Spider","at":1791344501628,"hash":"8bde8eb0c6a5f8ac0660e2e49e4a0a61fcd4dcab"}
{"url":"https://forum.across.to/t/proposal-template/1446","domain":"forum.across.to","title":"Proposal Template - WELCOME 👋 - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n Proposal Template \n\n WELCOME 👋\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Nov 2022\n\n 1 / 1\n\n Nov 2022\n\n Nov 2022\n\n post by Britt on Nov 27, 2022\n\n Britt\n\n Use the template below when creating your proposal. A passing proposal must include these components, and authors are encouraged to add any additional context that provides value.\n\nTitle: (enter proposal title)\nAuthor(s): (enter name(s) of associated authors)\nStatus: (RFC, Proposal)\nRelated Discussions: (optional - paste link here)\n\nSummary:\nGive us a TL;DR on your proposal; no more than 2-3 sentences.\nMotivation:\nWhat problems will this proposal address/solve? What’s the value-add?\nSpecification & Implementation:\nDescribe the proposal in as much detail as necessary. Explain the vision for the proposal. How will this affect the protocol both technically, socially, financially (if applicable), and governance-wise? What steps need to be taken to implement this proposal?\nRationale:\nExplain any decisions above that were chosen over an alternative. Why is this the best way to do it? How will the implementation of this proposal advance the protocol?\nDownside (Cons):\nAre there any disadvantages to implementing the proposal? Are there any security considerations or potentially negative financial exposures to consider?\nVoting:\nDefine what a “yes” and “no” vote entails. Once Snapshot vote is live, please add link here.\n\n [RFC - Governance Update] Committee Formation Criteria\n\n Across Governance Operating Manual\n\n About the Proposals category\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n 这个提议很好，希望社区也做越好\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 1\n\n Apr 2022\n\n About the Proposals category\n\n Proposals\n\n Proposals\n\n Mar 2023\n\n Across Governance Operating Manual\n\n WELCOME 👋\n\n WELCOME 👋\n\n Jun 2025\n\n Cryptohadari NFT Proposal\n\n Active Proposals\n\n Active Proposals\n\n May 2024\n\n [RFC - Governance update] Proposal to adjust voting quorum and approval threshold\n\n Passed Proposals\n\n governance-updates\n\n Passed Proposals\n\n 11\n\n Mar 2023","tokens":2006,"squid":"spider-09","role":"Bridge Spider","at":1791344507116,"hash":"b7a7b1a4a254ad3785bfcbbd0e37fafe84e91480"}
{"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.055Average 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 networksUnichainUnichain is a DeFi-native Ethereum L2, built to be the home for liquidity across chainsGo (opens in a new tab)OptimismOP Mainnet is an EVM-equivalent Optimistic Rollup. It aims to be fast, simple, and secure.Go (opens in a new tab)InkInk 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)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":918,"squid":"spider-05","role":"Spec Spider","at":1791344516246,"hash":"46c6c1c954d44962735cf6b7e6965b644f3899ab"}
{"url":"https://ethresear.ch/t/ethresear-ch-email-login-will-be-disabled-in-7-days/7369/6","domain":"ethresear.ch","title":"Ethresear.ch: email login will be disabled in 7 days - 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 3\n\n 3\n\n 2\n\n May 2020\n\n 5 / 16\n\n May 2020\n\n Oct 2021\n\n post by hwwhww on May 8, 2020\n\n hwwhww\n\n Thank you for using etheresear.ch forum!\nEmail login was enabled during the last time we restored the system. To mitigate spam and impersonator attacks, we decide to disable email login again and you can only log in with GitHub account.\nIf you were using email login, don’t worry! Please register a GitHub account with the same email to log in ethresear.ch, your previous posts and account content would remain unchanged.\nThanks.\n\n Somewhat time critical — How do I set a password?\n\n 4\n\n 3\n\n 3\n\n 2\n\n Pinned globally on May 8, 2020\n\n post by vbuterin on May 8, 2020\n\n vbuterin\n\n Should we just dogfood and enable logging in with an ethereum account? I remember @virgil or @Ping had a prototype for log-in-with-ETH on discourse?\n\n post by hwwhww on May 8, 2020\n\n hwwhww\n\n It’s still on our radar! I think one of pending issues that @virgil wanted to solve with ENS team is how to handle ENS transfer for authorization on discourse side, or even on ENS side.\nA future issue is how the merge people’s current discourse account and new Eauth login account gracefully.\nInteresting issues, we can introduce Eauth now if we sacrifice some (?) UX though.\n\n post by axic on May 8, 2020\n\n axic\n\n Just as discourse supports linking and login via Github, cannot the eauth login be added optionally, so that both github and eauth work at the same time?\n\n post by hwwhww on May 8, 2020\n\n hwwhww\n\n We can have multiple authorization options at the same time.\nIf we have both email login and GitHub oauth (as status-quo), and they can be merged together automatically well since the GitHub account identifier is the email you used to register GitHub account.\nBut for Eauth case, since you don’t register your Ethereum address / ENS with an email address, it will create a new discourse account when you use Eauth login. (@Ping please correct me if I’m wrong!)\n\n post by axic on May 8, 2020\n\n axic\n\nI see. But wouldn’t it be possible to add a field for “ENS name” in discourse (like now there’s the email field + github link) so the linking happens?\nAlternatively (though I am not a big fan due to the privacy aspect) EIP-634 could be used to link an ENS record to an email.\n\n post by kmichel on May 9, 2020\n\n kmichel\n\n Successfully logged in with it.\n\n post by vbuterin on May 9, 2020\n\n vbuterin\n\n axic\n\nBy ENS transfer you mean what happens if an ENS name is transferred to another account? Wouldn’t the natural answer be “well, for future logins start verifying signatures against that new account instead of the current one”? What’s the problem?\n\n post by hwwhww on May 9, 2020\n\n hwwhww\n\nI believe we can add ENS name (or, ETH account) field in discourse. And then, we need to ask the GitHub login user to manually update that field to claim that “the one who has this ENS name / ETH account is me”. So when the user uses Eauth login later, it will be able to bind to the existing account.\n\nRight, adding the email field in ENS can also solve the password recovery issue on discourse! I understand why we may be against it, we are trying to dogfood with a decentralized solution, but we still want the email system to prevent a user from losing their properties forever. \n\nYes.\n\nI think the authentication follows the authorized controller of the ENS name, and use ENS name as the default handle name? It doesn’t take ENS as the first-class when searching for an associated account (ping @Ping to verify it).\n\n Somewhat time critical — How do I set a password?\n\n post by Ping on May 9, 2020\n\n Ping\n\n @virgil suggests that we can use ethmail.cc by default, but at present ethmail seems not so well functioned and decentralized. \nIn Eauth scenario, account address is the primary key. And for ENS you need to not only own an ENS but also set it as your address’s reverse lookup name, then it would be displayed as your nickname.\nBTW, Eauth supports contract address login with EIP1271. I highly recommend this one. You can have multiple authenticate keys, timelock, social recovery, and lots of good stuff, without overhead to the platform. \nLogin with: Gnosis safe / Argent / Authereum / Dapper / etc\ncode: GitHub - pelith/node-eauth-server: An OAuth-compatiable service based on Ethereum credentials to authenticate users on a website. See live version at https://eauth.pelith.com/ https://forum.hakka.finance\ndemo: https://eauth.pelith.com/\nDiscourse + Eauth prototype: https://discourse-ens.pelith.com/\n\n post by vbuterin on May 10, 2020\n\n vbuterin\n\n I definitely like eauth!\n\n post by gkapkowski on May 13, 2020\n\n gkapkowski\n\n Hi, I’ve build Cryptoauth and I have working plugin for discord that enabled authentication with Ethereum address. Let me know if you would be interested in experimenting with it.\nWorking example: https://community.cryptoverse.cc/\nIt also has ability to limit logins to only those addresses that hold certain tokens. Example: https://marketpunks.cryptoverse.cc/\n\n post by gkapkowski on May 13, 2020\n\n gkapkowski\n\n @Ping nice work with Eauth! I would love Cryptoauth to look like this \nI’m also the person behind ETHMail so if you need something done with it let me know \n\n post by gkapkowski on May 13, 2020\n\n gkapkowski\n\n You can find cryptoauth.io discord plugin at https://github.com/CryptoverseCC/discourse-openid-connect It’s a fork that creates users in the background instead of asking people to confirm creating users.\n\n 1 year later\n\n post by x on Oct 22, 2021\n\n x\n\n Just found this discussion and realized that it’s related to my thread here: Somewhat time critical — How do I set a password?\nIn my opinion, it’s not a good idea to restrict people to GitHub OAuth, and I explain in detail why that is in the thread above.\nBesides, some people just don’t feel comfortable using GitHub and instead use self-hosted repositories or codeberg.org. We shouldn’t force those people to sign up for a website that they don’t feel comfortable using.\n\n Powered by Discourse","tokens":1516,"squid":"spider-04","role":"Research Spider","at":1791344517798,"hash":"885d2994b7c69a84215c8c46ccfb304fa41fc5f0"}
{"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)Encode London Hackathon and ConferenceOct 23 – 25, 2026London, United Kingdom (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":1884,"squid":"spider-05","role":"Spec Spider","at":1791344526340,"hash":"c553f0f17bea9ffc37623dfd5e87f7207d2e4458"}
{"url":"https://ethresear.ch/t/ethresear-ch-email-login-will-be-disabled-in-7-days/7369","domain":"ethresear.ch","title":"Ethresear.ch: email login will be disabled in 7 days - Administrivia - Ethereum Research","text":"Ethresear.ch: email login will be disabled in 7 days \n\n Administrivia\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 May 2020\n\n 1 / 16\n\n May 2020\n\n Oct 2021\n\n post by hwwhww on May 8, 2020\n\n hwwhww\n\n Thank you for using etheresear.ch forum!\nEmail login was enabled during the last time we restored the system. To mitigate spam and impersonator attacks, we decide to disable email login again and you can only log in with GitHub account.\nIf you were using email login, don’t worry! Please register a GitHub account with the same email to log in ethresear.ch, your previous posts and account content would remain unchanged.\nThanks.\n\n Somewhat time critical — How do I set a password?\n\n 4\n\n 3\n\n 3\n\n 2\n\n Pinned globally on May 8, 2020\n\n post by vbuterin on May 8, 2020\n\n vbuterin\n\n Should we just dogfood and enable logging in with an ethereum account? I remember @virgil or @Ping had a prototype for log-in-with-ETH on discourse?\n\n post by hwwhww on May 8, 2020\n\n hwwhww\n\n It’s still on our radar! I think one of pending issues that @virgil wanted to solve with ENS team is how to handle ENS transfer for authorization on discourse side, or even on ENS side.\nA future issue is how the merge people’s current discourse account and new Eauth login account gracefully.\nInteresting issues, we can introduce Eauth now if we sacrifice some (?) UX though.\n\n post by axic on May 8, 2020\n\n axic\n\n Just as discourse supports linking and login via Github, cannot the eauth login be added optionally, so that both github and eauth work at the same time?\n\n post by hwwhww on May 8, 2020\n\n hwwhww\n\n We can have multiple authorization options at the same time.\nIf we have both email login and GitHub oauth (as status-quo), and they can be merged together automatically well since the GitHub account identifier is the email you used to register GitHub account.\nBut for Eauth case, since you don’t register your Ethereum address / ENS with an email address, it will create a new discourse account when you use Eauth login. (@Ping please correct me if I’m wrong!)\n\n post by axic on May 8, 2020\n\n axic\n\nI see. But wouldn’t it be possible to add a field for “ENS name” in discourse (like now there’s the email field + github link) so the linking happens?\nAlternatively (though I am not a big fan due to the privacy aspect) EIP-634 could be used to link an ENS record to an email.\n\n post by kmichel on May 9, 2020\n\n kmichel\n\n Successfully logged in with it.\n\n post by vbuterin on May 9, 2020\n\n vbuterin\n\n axic\n\nBy ENS transfer you mean what happens if an ENS name is transferred to another account? Wouldn’t the natural answer be “well, for future logins start verifying signatures against that new account instead of the current one”? What’s the problem?\n\n post by hwwhww on May 9, 2020\n\n hwwhww\n\nI believe we can add ENS name (or, ETH account) field in discourse. And then, we need to ask the GitHub login user to manually update that field to claim that “the one who has this ENS name / ETH account is me”. So when the user uses Eauth login later, it will be able to bind to the existing account.\n\nRight, adding the email field in ENS can also solve the password recovery issue on discourse! I understand why we may be against it, we are trying to dogfood with a decentralized solution, but we still want the email system to prevent a user from losing their properties forever. \n\nYes.\n\nI think the authentication follows the authorized controller of the ENS name, and use ENS name as the default handle name? It doesn’t take ENS as the first-class when searching for an associated account (ping @Ping to verify it).\n\n Somewhat time critical — How do I set a password?\n\n post by Ping on May 9, 2020\n\n Ping\n\n @virgil suggests that we can use ethmail.cc by default, but at present ethmail seems not so well functioned and decentralized. \nIn Eauth scenario, account address is the primary key. And for ENS you need to not only own an ENS but also set it as your address’s reverse lookup name, then it would be displayed as your nickname.\nBTW, Eauth supports contract address login with EIP1271. I highly recommend this one. You can have multiple authenticate keys, timelock, social recovery, and lots of good stuff, without overhead to the platform. \nLogin with: Gnosis safe / Argent / Authereum / Dapper / etc\ncode: GitHub - pelith/node-eauth-server: An OAuth-compatiable service based on Ethereum credentials to authenticate users on a website. See live version at https://eauth.pelith.com/ https://forum.hakka.finance\ndemo: https://eauth.pelith.com/\nDiscourse + Eauth prototype: https://discourse-ens.pelith.com/\n\n post by vbuterin on May 10, 2020\n\n vbuterin\n\n I definitely like eauth!\n\n post by gkapkowski on May 13, 2020\n\n gkapkowski\n\n Hi, I’ve build Cryptoauth and I have working plugin for discord that enabled authentication with Ethereum address. Let me know if you would be interested in experimenting with it.\nWorking example: https://community.cryptoverse.cc/\nIt also has ability to limit logins to only those addresses that hold certain tokens. Example: https://marketpunks.cryptoverse.cc/\n\n post by gkapkowski on May 13, 2020\n\n gkapkowski\n\n @Ping nice work with Eauth! I would love Cryptoauth to look like this \nI’m also the person behind ETHMail so if you need something done with it let me know \n\n post by gkapkowski on May 13, 2020\n\n gkapkowski\n\n You can find cryptoauth.io discord plugin at https://github.com/CryptoverseCC/discourse-openid-connect It’s a fork that creates users in the background instead of asking people to confirm creating users.\n\n 1 year later\n\n post by x on Oct 22, 2021\n\n x\n\n Just found this discussion and realized that it’s related to my thread here: Somewhat time critical — How do I set a password?\nIn my opinion, it’s not a good idea to restrict people to GitHub OAuth, and I explain in detail why that is in the thread above.\nBesides, some people just don’t feel comfortable using GitHub and instead use self-hosted repositories or codeberg.org. We shouldn’t force those people to sign up for a website that they don’t feel comfortable using.\n\n Powered by Discourse","tokens":1530,"squid":"spider-04","role":"Research Spider","at":1791344528035,"hash":"37619c87f3dcee6a7380c58fdd6207d83bcf7c51"}
{"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)KilnFrom 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)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)Consensys StakingFrom 32 ETHmacOSWindowsGUIAPIOpen sourceAuditedBug bountyBattle testedPermissionlessExecution diversityConsensus diversitySelf custodyGet 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)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)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)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)Abyss FinanceFrom 32 ETHBrowserGUIOpen sourceAuditedBug bountyBattle testedPermissionlessExecution diversityConsensus diversitySelf custodyVisit on (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)Sensei NodeFrom 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\nWagyu Key GenLinuxmacOSWindowsGUIOpen sourceAuditedBug bountyBattle testedPermissionlessSelf custodyVisit on (opens in a new tab) (opens in a new tab)Get started (opens in a new tab)ethdoLinuxWindowsCLIOpen sourceAuditedBug bountyBattle testedPermissionlessSelf custodyGet 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":"spider-05","role":"Spec Spider","at":1791344536496,"hash":"67840e153da02d1678a7d3945d0945fde92c2687"}
{"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":"spider-05","role":"Spec Spider","at":1791344548633,"hash":"e50a68f20c7b85ad93896a4b60955758bef1b2c2"}
{"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":"spider-05","role":"Spec Spider","at":1791344560465,"hash":"1ac1781ca24c6889401e446b6d8c2229a1bad5a6"}
{"url":"https://developers.jup.ag/docs/portal/analytics","domain":"developers.jup.ag","title":"Analytics - Jupiter Developers","text":"Analytics show your traffic, performance, cost, and origin for a team and per API.\n​Period and granularity\nA timezone-aware period picker controls the range, and your choice persists as you move between pages. The time bucket scales with the range:\nRangeBucketUp to 1 hour1 minuteUp to 1 day15 minutesUp to 7 days6 hoursUp to 30 days12 hoursOver 30 days1 day\nAnalytics cover the last 6 months.\n​Overview\nThe overview shows headline KPIs, each with a period-over-period trend:\nKPIWhat it showsTotal requestsRequests in the period.Errors and error rateResponses with a 4xx or 5xx status, and that count as a percentage of total requests.Latency (p50 / p95 / p99)Median, 95th, and 99th percentile response time.Credits consumedCredits used in the period.\nCharts on the overview cover requests, latency, credits over time, status-code distribution, geographic distribution, and top paths.\n\n​Per-API breakdown\nFor each API, see latency (p50 / p90 / p99) and request and error counts. Use it to find which API drives your traffic, errors, or latency.\n\n​API-specific analytics\nSome APIs have deeper analytics beyond the overview. Common metrics include volume, success rate, latency by phase, top token pairs, and fees collected.\n\nIf there are specific metrics you need for your integration, reach out to us and we can help.\n​Firewall analytics\nFirewall analytics show rule outcomes over time and how often each rule matched. See Firewall for the rules behind them.\n​Related\nWas this page helpful?","tokens":373,"squid":"spider-02","role":"Liquidity Spider","at":1791344578202,"hash":"72cc88b52b1981489dd961dcdfd8ef232e4f1331"}
{"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":"spider-05","role":"Spec Spider","at":1791344583885,"hash":"faa4e5229af4bd48e795632e1dc3b59a7662b5ac"}
{"url":"https://developers.jup.ag/docs/guides","domain":"developers.jup.ag","title":"Developer Guides - Jupiter Developers","text":"​What are these guides?\nThese guides answer the question: “How do I do X on Solana?”\nEach guide walks through a real problem you’ll hit while building, which API to use, and how to implement it.\nBefore you start: Get an API key at Portal\n\n​Available Guides\n\n​Quick reference\n​Tokens and prices\nI want to…Use this guideSwap tokens on Solana via APISwap API V2Build a trading bot with swapsSwap API V2Search for tokens by name or symbolGet Token InformationGet token logos and metadataGet Token InformationCheck if a token is verifiedGet Token InformationFind trending or new tokensGet Token InformationGet current token prices in USDGet Token PricesCalculate portfolio valueGet Token Prices\n​Swapping\nI want to…Use this guideEmbed a swap widget in my appEmbed Swap WidgetAdd token swap to my websiteEmbed Swap WidgetLet users buy my token on my siteEmbed Swap WidgetBuild a swap with custom logicSwap V2 /buildCall Jupiter swap from my program (CPI)Swap V2 /buildAdd custom instructions to a swapSwap V2 /build\n​Trading\nI want to…Use this guideLet users bet on event outcomesPrediction MarketsBuild a prediction market appPrediction Markets\n\n​Demo apps\nSource code for the demo apps built in these guides is available in the api-examples repo:\n\nPlugin community site\nPrediction API\nTokens API\nPrice API\n\n​Stay updated\n\nPortal: API keys and usage dashboard\nJupiter Dev Notifications: API updates and announcements\nWas this page helpful?","tokens":359,"squid":"spider-02","role":"Liquidity Spider","at":1791344590378,"hash":"1c4e336fd8df76b8984ec29529ccba1e35d3296b"}
{"url":"https://consensysdiligence.github.io/smart-contract-best-practices/development-recommendations/solidity-specific/visibility/","domain":"consensysdiligence.github.io","title":"Visibility - Ethereum Smart Contract Best Practices","text":"Visibility\n\nTip\nFor comprehensive insights into secure development practices, consider visiting the Development Recommendations section of the Smart Contract Security Field Guide. This resource provides in-depth articles to guide you in developing robust and secure smart contracts.\n\nExplicitly label the visibility of functions and state variables. Functions can be specified as\nbeing external, public, internal or private. Please understand the differences between\nthem, for example, external may be sufficient instead of public. For state variables,\nexternal is not possible. Labeling the visibility explicitly will make it easier to catch\nincorrect assumptions about who can call the function or access the variable.\n\nExternal functions are part of the contract interface. An external function f cannot be\n called internally (i.e. f() does not work, but this.f() works). External functions are\n sometimes more efficient when they receive large arrays of data.\nPublic functions are part of the contract interface and can be either called internally or via\n messages. For public state variables, an automatic getter function (see below) is generated.\nInternal functions and state variables can only be accessed internally, without using this.\nPrivate functions and state variables are only visible for the contract they\n are defined in and not in derived contracts. Note: Everything inside a\n contract is visible to all observers external to the\n blockchain,\n even Private variables.\n\n// bad\nuint x; // the default is internal for state variables, but it should be made explicit\nfunction buy() { // the default is public\n // public code\n}\n\n// good\nuint private y;\nfunction buy() external {\n // only callable externally or using this.buy()\n}\n\nfunction utility() public {\n // callable externally, as well as internally: changing this code requires thinking about both cases.\n}\n\nfunction internalAction() internal {\n // internal code\n}\n\nSee SWC-100 and\nSWC-108","tokens":490,"squid":"spider-06","role":"Security Spider","at":1791344602601,"hash":"20d967ba82723e93050ee864d37d7642a561b3dd"}
{"url":"https://developers.jup.ag/docs/get-started/development-basics","domain":"developers.jup.ag","title":"Development Basics - Jupiter Developers","text":"Solana uses an account-based architecture where data is stored in accounts and mutated by programs (smart contracts).\nJupiter is deployed on Solana mainnet only.\n​Core Concepts\n\nPrograms - Executable code deployed on-chain. They define instructions, process transactions, and interact with accounts.\nAccounts - Store data on-chain. Mutable by their owning program.\nInstructions - Defined by programs, similar to API endpoints.\nTransactions - Bundles of one or more instructions sent to the network.\n\nSee the official Solana docs for Web3.js and Rust client libraries.\n​Interacting with Jupiter\nMethodDescriptionSwap APIGet an order, sign, and submit.Cross Program Invocation (CPI)Call Jupiter Swap from your on-chain program. Recommended since the Loosen CPI restriction feature.Flash FillAlternative to CPI using Versioned Transactions and Address Lookup Tables to reduce account size.\nThe Swap API’s order and execute path handles transaction building, sending, priority fees, and compute optimisation for you. No RPC required.\n​Transaction Fundamentals\n​Priority Fees\nAn optional fee to improve transaction landing speed. Higher priority fee = higher position in the execution queue.\nPriority Fee = Compute Budget x Compute Unit Price (excluding the 5,000 lamport base fee).\nTermDescriptionGlobal Priority FeeFee estimation across the entire networkLocal Fee MarketFee estimation for a specific writable account (hot account)Compute BudgetHow much compute the transaction is expected to consumeCompute Unit PriceMicro-lamports per compute unit\nOverpaying priority fees drives up costs across the network over time. Estimate appropriately rather than always bidding high.\n​Compute Units\nCompute Units (CU) measure the resources a transaction needs. The Solana runtime caps transactions at 1.4M CU, with a default of 200K CU per instruction. You can set a custom limit with SetComputeUnitLimit.\n​Slippage\nA threshold (percentage or bps) that causes the transaction to fail if the actual output falls below the quoted amount by that margin. Tighter slippage protects against price movement but makes landing harder.\n​Transaction Broadcasting\nTransactions reach the network via:\n\nStandard RPCs\nRPCs with Stake-Weighted Quality of Service (SWQoS)\nJito RPC\nWas this page helpful?","tokens":569,"squid":"spider-02","role":"Liquidity Spider","at":1791344606227,"hash":"9dd23f1ee2feb0aeaf205510a437c37baecb5122"}
{"url":"https://www.metaplex.com/docs/smart-contracts/core/guides/onchain-ticketing-with-appdata","domain":"metaplex.com","title":"Core - Appdata Plugin Example","text":"This developer guide leverages the new Appdata Plugin to create a ticketing solution that could be used to generate tickets as digital assets and verified by an external source of trust other than the issuer, like for example a venue manager.IntroductionExternal PluginAn External Plugin is a plugin whose behavior is controlled by an external source. The core program will provide an adapter for these plugins, but developers decide the behavior by pointing this adapter to an external data source. Each External Adapter has the ability to assign lifecycle checks to Lifecycle Events, influencing the behavior of the lifecycle event taking place. This means we can assign the following checks to lifecycle events like create, transfer, update, and burn:Listen: A “web3” webhook that alerts the plugin when a lifecycle event occurs. This is particularly useful for tracking data or performing actions.Reject: The plugin can reject a lifecycle event.Approve: The plugin can approve a lifecycle event. If you want to learn more about External Plugins, read more about them on the External Plugins overview.Appdata PluginThe AppData Plugin allows asset/collection authorities to save arbitrary data that can be written and changed by the data_authority, an external source of trust and can be assigned to anyone the asset/collection authority decides to. With the AppData Plugin, collection/asset authorities can delegate the task of adding data to their assets to trusted third parties. If you’re not familiar with the new Appdata Plugin, read more about it on the AppData Plugin page.General Overview: Program DesignIn this example, we will develop a ticketing solution that comes with four basic operations:Setting up the Manager: Establish the authority responsible for the creation and issuance of tickets.Creating an Event: Generate an event as a collection asset.Creating Individual Tickets: Produce individual tickets that are part of the event collection.Handling Venue Operations: Manage operations for the venue operator, such as scanning tickets when they are used. Note: While these operations provide a foundational start for a ticketing solution, a full-scale implementation would require additional features like an external database for indexing the event collection. However, this example serves as a good starting point for those interested in developing a ticketing solution.The importance of having an external source of trust to handle scanning ticketsUntil the introduction of the AppData plugin and the Core standard, managing attribute changes for assets was limited due to off-chain storage constraints. It was also impossible to delegate authority over specific parts of an asset. This advancement is a game changer for regulated use cases, such as ticketing systems since it allows venue authorities to add data to the asset without granting them complete control over attribute changes and other data aspects. This setup reduces the risk of fraudulent activities and shifts the responsibility for errors away from the venue so the issuing company retains immutable records of the assets, while specific data updates, like marking tickets as used, are securely managed through the AppData plugin.Using Digital Assets to store data instead of PDAsInstead of relying on generic external Program Derived Addresses (PDAs) for event-related data, you can create the event itself as a collection asset. This approach allow all tickets for the event to be included in the \"event\" collection, making general event data easily accessible and easily link event details with the ticket assets itself. You can then apply the same method for individual ticket-related data, including ticket number, hall, section, row, seat, and price directly on the Asset. Using Core accounts like Collection or Asset accounts to save relevant data when dealing with digital assets, rather than relying on external PDAs, let ticket purchasers view all relevant event information directly from their wallet without needing to deserialize data. In addition, storing data directly on the asset itself allows you to leverage the Digital Asset Standard (DAS) to fetch and display it on your website with a single instruction, as shown below:const ticketData = await fetchAsset(umi, ticket);\nconsole.log(\"\\nThis are all the ticket-related data: \", ticketData.attributes);\nGetting our hands dirty: The programPrerequisite and SetupFor simplicity, we’ll use Anchor, leveraging a mono-file approach where all the necessary macros can be found in the lib.rs file:declare_id: Specifies the program's on-chain address.#[program]: Specifies the module containing the program’s instruction logic.#[derive(Accounts)]: Applied to structs to indicate a list of accounts required for an instruction.#[account]: Applied to structs to create custom account types specific to the program. Note: You can follow along and open the following example in Solana Playground, an online tool to build and deploy Solana programs: Solana Playground. As a stylistic choice, in the account struct of all instructions, we will separate the Signer and the Payer. Quite often the same account is used for both but this is a standard procedure in case the Signer is a PDAs since it cannot pay for account creation, therefore, there need to be two different fields for it. While this separation isn't strictly necessary for our instructions, it's considered good practice. Note: Both the Signer and the Payer must still be signers of the transaction.Dependencies and ImportsIn this example, we primarily use the mpl_core crate with the anchor feature enabled:anchor-lang = \"0.32.1\"\nmpl-core = { version = \"x.x.x\", default-features = false, features = [\"anchor\", \"anchor-0-32\"] }\nSee Using Core in Anchor for feature flag details and Rust toolchain requirements. The dependencies used are as follows:use anchor_lang::prelude::*;\nuse mpl_core::{\n ID as MPL_CORE_ID,\n fetch_external_plugin_adapter_data_info, \n fetch_plugin, \n instructions::{\n CreateCollectionV2CpiBuilder, \n CreateV2CpiBuilder, \n WriteExternalPluginAdapterDataV1CpiBuilder, \n UpdatePluginV1CpiBuilder\n }, \n accounts::{BaseAssetV1, BaseCollectionV1}, \n types::{\n AppDataInitInfo, Attribute, Attributes, \n ExternalPluginAdapterInitInfo, ExternalPluginAdapterKey, \n ExternalPluginAdapterSchema, PermanentBurnDelegate, UpdateAuthority,\n PermanentFreezeDelegate, PermanentTransferDelegate, Plugin, \n PluginAuthority, PluginAuthorityPair, PluginType\n }, \n};\nThe Setup Manager InstructionThe setup manager instruction is a one-off process needed to initialize the manager PDA and save the bumps inside the manager account. Most of the action happens in the Account struct:#[derive(Accounts)]\npub struct SetupManager<'info> {\n pub signer: Signer<'info>,\n #[account(mut)]\n pub payer: Signer<'info>,\n #[account(\n init,\n payer = payer,\n space = Manager::INIT_SPACE,\n seeds = [MANAGER_SEEDS.as_bytes()],\n bump,\n )]\n pub manager: Account<'info, Manager>,\n pub system_program: Program<'info, System>,\n}\nHere, we initialize the Manager account using the init macro, with the payer transferring enough lamports for rent and the INIT_SPACE variable to reserve the appropriate number of bytes.#[account]\npub struct Manager {\n pub bump: u8,\n}\nimpl Space for Manager {\n const INIT_SPACE: usize = 8 + 1;\n}\nIn the instruction itself, we just declare and save the bumps for future reference when using signer seeds. This avoids wasting compute units on refinding them everytime we use the manager account.pub fn setup_manager(ctx: Context<SetupManager>) -> Result<()> {\n ctx.accounts.manager.bump = ctx.bumps.manager;\n Ok(())\n}\nThe Create Event InstructionThe Create Event Instruction sets up an event as a digital asset in the form of a collection asset, allowing you to include all related tickets and event data in a seamless and organized manner. The account struct for this instruction, closely resembles the Setup Manager instruction:#[derive(Accounts)]\npub struct CreateEvent<'info> {\n pub signer: Signer<'info>,\n #[account(mut)]\n pub payer: Signer<'info>,\n #[account(\n seeds = [MANAGER_SEEDS.as_bytes()],\n bump = manager.bump\n )]\n pub manager: Account<'info, Manager>,\n #[account(mut)]\n pub event: Signer<'info>,\n pub system_program: Program<'info, System>,\n #[account(address = MPL_CORE_ID)]\n /// CHECK: This is checked by the address constraint\n pub mpl_core_program: UncheckedAccount<'info>\n}\nThe main differences areThe Manager account is already initialized and will be used as the update authority for the event account.The event account, set as mutable and a signer, will be transformed into a Core Collection Account during this instruction. Since we need to save a lot of data within the collection account, we pass all the inputs via a structured format to avoid cluttering the function with numerous parameters.#[derive(AnchorDeserialize, AnchorSerialize)]\npub struct CreateEventArgs {\n pub name: String,\n pub uri: String,\n pub city: String,\n pub venue: String,\n pub artist: String,\n pub date: String,\n pub time: String,\n pub capacity: u64,\n}\nThe main function, create_event, just then utilizes the above inputs to create the event collection and add attributes containing all event details.pub fn create_event(ctx: Context<CreateEvent>, args: CreateEventArgs) -> Result<()> {\n // Add an Attribute Plugin that will hold the event details\n let mut collection_plugin: Vec<PluginAuthorityPair> = vec![];\n let attribute_list: Vec<Attribute> = vec![\n Attribute { \n key: \"City\".to_string(), \n value: args.city \n },\n Attribute { \n key: \"Venue\".to_string(), \n value: args.venue \n },\n Attribute { \n key: \"Artist\".to_string(), \n value: args.artist \n },\n Attribute { \n key: \"Date\".to_string(), \n value: args.date \n },\n Attribute { \n key: \"Time\".to_string(), \n value: args.time \n },\n Attribute { \n key: \"Capacity\".to_string(), \n value: args.capacity.to_string() \n }\n ];\n\n collection_plugin.push(\n PluginAuthorityPair { \n plugin: Plugin::Attributes(Attributes { attribute_list }), \n authority: Some(PluginAuthority::UpdateAuthority) \n }\n );\n\n // Create the Collection that will hold the tickets\n CreateCollectionV2CpiBuilder::new(&ctx.accounts.mpl_core_program.to_account_info())\n .collection(&ctx.accounts.event.to_account_info())\n .update_authority(Some(&ctx.accounts.manager.to_account_info()))\n .payer(&ctx.accounts.payer.to_account_info())\n .system_program(&ctx.accounts.system_program.to_account_info())\n .name(args.name)\n .uri(args.uri)\n .plugins(collection_plugin)\n .invoke()?;\n Ok(())\n}\nThe Create Ticket InstructionThe Create Event Instruction sets up an event as a digital asset in the form of a collection asset, allowing you to include all related tickets and event data in a seamless and organized manner. The whole instruction closely resemble the create_event one since the goal are very similar, but this time instead of creating the event asset, we’re going to create the ticket asset that will be contained inside of the event collection#[derive(Accounts)]\npub struct CreateTicket<'info> {\n pub signer: Signer<'info>,\n #[account(mut)]\n pub payer: Signer<'info>,\n #[account(\n seeds = [MANAGER_SEEDS.as_bytes()],\n bump = manager.bump\n )]\n pub manager: Account<'info, Manager>,\n #[account(\n mut,\n constraint = event.update_authority == manager.key(),\n )]\n pub event: Account<'info, BaseCollectionV1>,\n #[account(mut)]\n pub ticket: Signer<'info>,\n pub system_program: Program<'info, System>,\n #[account(address = MPL_CORE_ID)]\n /// CHECK: This is checked by the address constraint\n pub mpl_core_program: UncheckedAccount<'info>\n}\nThe main differences in the account struct are:The event account is already initialized so we can deserialize it as a BaseCollectionV1 asset where we can check that the update_authority is the manager PDA.The ticket account, set as mutable and a signer, will be transformed into a Core Collection Account during this instruction. Since we need to save extensive data in this function too, we pass these inputs via a structured format as done already in the create_event instruction.#[derive(AnchorDeserialize, AnchorSerialize)]\npub struct CreateTicketArgs {\n pub name: String,\n pub uri: String,\n pub hall: String,\n pub section: String,\n pub row: String,\n pub seat: String,\n pub price: u64,\n pub venue_authority: Pubkey,\n}\nWhen we talk about the instruction, the main differences are:Incorporates additional plugins like the PermanentFreeze, PermanentBurn, and PermanentTransferin order to add a security layer in case something goes wrong.Use the new AppData external plugin to store binary data inside of it managed by the venue_authority that we pass in as input in the instruction.It has a sanity check at the start to see if the total number of ticket issued doesn’t go beyond capacity limitpub fn create_ticket(ctx: Context<CreateTicket>, args: CreateTicketArgs) -> Result<()> {\n // Check that the maximum number of tickets has not been reached yet\n let (_, collection_attribute_list, _) = fetch_plugin::<BaseCollectionV1, Attributes>(\n &ctx.accounts.event.to_account_info(), \n PluginType::Attributes\n )?;\n // Search for the Capacity attribute\n let capacity_attribute = collection_attribute_list\n .attribute_list\n .iter()\n .find(|attr| attr.key == \"Capacity\")\n .ok_or(TicketError::MissingAttribute)?;\n // Unwrap the Capacity attribute value\n let capacity = capacity_attribute\n .value\n .parse::<u32>()\n .map_err(|_| TicketError::NumericalOverflow)?;\n require!(\n ctx.accounts.event.num_minted < capacity, \n TicketError::MaximumTicketsReached\n );\n // Add an Attribute Plugin that will hold the ticket details\n let mut ticket_plugin: Vec<PluginAuthorityPair> = vec![];\n\n let attribute_list: Vec<Attribute> = vec![\n Attribute { \n key: \"Ticket Number\".to_string(), \n value: ctx.accounts.event.num_minted.checked_add(1).ok_or(TicketError::NumericalOverflow)?.to_string()\n },\n Attribute { \n key: \"Hall\".to_string(), \n value: args.hall \n },\n Attribute { \n key: \"Section\".to_string(), \n value: args.section \n },\n Attribute { \n key: \"Row\".to_string(), \n value: args.row \n },\n Attribute { \n key: \"Seat\".to_string(), \n value: args.seat \n },\n Attribute { \n key: \"Price\".to_string(), \n value: args.price.to_string() \n }\n ];\n\n ticket_plugin.push(\n PluginAuthorityPair { \n plugin: Plugin::Attributes(Attributes { attribute_list }), \n authority: Some(PluginAuthority::UpdateAuthority) \n }\n );\n\n ticket_plugin.push(\n PluginAuthorityPair { \n plugin: Plugin::PermanentFreezeDelegate(PermanentFreezeDelegate { frozen: false }), \n authority: Some(PluginAuthority::UpdateAuthority) \n }\n );\n\n ticket_plugin.push(\n PluginAuthorityPair { \n plugin: Plugin::PermanentBurnDelegate(PermanentBurnDelegate {}), \n authority: Some(PluginAuthority::UpdateAuthority) \n }\n );\n\n ticket_plugin.push(\n PluginAuthorityPair { \n plugin: Plugin::PermanentTransferDelegate(PermanentTransferDelegate {}), \n authority: Some(PluginAuthority::UpdateAuthority) \n }\n );\n let mut ticket_external_plugin: Vec<ExternalPluginAdapterInitInfo> = vec![];\n\n ticket_external_plugin.push(ExternalPluginAdapterInitInfo::AppData(\n AppDataInitInfo {\n init_plugin_authority: Some(PluginAuthority::UpdateAuthority),\n data_authority: PluginAuthority::Address{ address: args.venue_authority },\n schema: Some(ExternalPluginAdapterSchema::Binary),\n }\n ));\n let signer_seeds = &[b\"manager\".as_ref(), &[ctx.accounts.manager.bump]];\n // Create the Ticket\n CreateV2CpiBuilder::new(&ctx.accounts.mpl_core_program.to_account_info())\n .asset(&ctx.accounts.ticket.to_account_info())\n .collection(Some(&ctx.accounts.event.to_account_info()))\n .payer(&ctx.accounts.payer.to_account_info())\n .authority(Some(&ctx.accounts.manager.to_account_info()))\n .owner(Some(&ctx.accounts.signer.to_account_info()))\n .system_program(&ctx.accounts.system_program.to_account_info())\n .name(args.name)\n .uri(args.uri)\n .plugins(ticket_plugin)\n .external_plugin_adapters(ticket_external_plugin)\n .invoke_signed(&[signer_seeds])?;\n Ok(())\n}\nNote: To use external plugins, we need to use the V2 of the create function, which allows setting the .external_plugin_adapter input.The Scan Ticket InstructionThe Scan Ticket Instruction finalizes the process by verifying and updating the status of the ticket when scanned.#[derive(Accounts)]\npub struct ScanTicket<'info> {\n pub owner: Signer<'info>,\n pub signer: Signer<'info>,\n #[account(mut)]\n pub payer: Signer<'info>,\n #[account(\n seeds = [MANAGER_SEEDS.as_bytes()],\n bump = manager.bump\n )]\n pub manager: Account<'info, Manager>,\n #[account(\n mut,\n constraint = ticket.owner == owner.key(),\n constraint = ticket.update_authority == UpdateAuthority::Collection(event.key()),\n )]\n pub ticket: Account<'info, BaseAssetV1>,\n #[account(\n mut,\n constraint = event.update_authority == manager.key(),\n )]\n pub event: Account<'info, BaseCollectionV1>,\n pub system_program: Program<'info, System>,\n #[account(address = MPL_CORE_ID)]\n /// CHECK: This is checked by the address constraint\n pub mpl_core_program: UncheckedAccount<'info>,\n}\nThe main differences in the account struct are:The ticket account is already initialized so we can deserialize it as a BaseAssetV1 asset where we can check that the update_authority is the event collection and that the owner of the asset is the owner account.We require for both the owner and the venue_authority to be signer to ensure the scan is authenticated by both party and error-free. The application will create a transaction, partially signed by the venue_authority and broadcast it so the owner of the ticket can sign it and send it In the instruction we start with a sanity check to see if there is any data inside of the Appdata plugin because if there is, the ticket would’ve been already scanned. After that, we create a data variable that consist of a vector of u8 that says “Scanned” that we’ll later write inside the Appdata plugin We finish the instruction by making the digital asset soulbounded so it can’t be traded or transferred after validation. Making it just a memorabilia of the event.pub fn scan_ticket(ctx: Context<ScanTicket>) -> Result<()> {\n let (_, app_data_length) = fetch_external_plugin_adapter_data_info::<BaseAssetV1>(\n &ctx.accounts.ticket.to_account_info(), \n None, \n &ExternalPluginAdapterKey::AppData(\n PluginAuthority::Address { address: ctx.accounts.signer.key() }\n )\n )?;\n require!(app_data_length == 0, TicketError::AlreadyScanned);\n let data: Vec<u8> = \"Scanned\".as_bytes().to_vec();\n WriteExternalPluginAdapterDataV1CpiBuilder::new(&ctx.accounts.mpl_core_program.to_account_info())\n .asset(&ctx.accounts.ticket.to_account_info())\n .collection(Some(&ctx.accounts.event.to_account_info()))\n .payer(&ctx.accounts.payer.to_account_info())\n .system_program(&ctx.accounts.system_program.to_account_info())\n .key(ExternalPluginAdapterKey::AppData(PluginAuthority::Address { address: ctx.accounts.signer.key() }))\n .data(data)\n .invoke()?;\n let signer_seeds = &[b\"manager\".as_ref(), &[ctx.accounts.manager.bump]];\n UpdatePluginV1CpiBuilder::new(&ctx.accounts.mpl_core_program.to_account_info())\n .asset(&ctx.accounts.ticket.to_account_info())\n .collection(Some(&ctx.accounts.event.to_account_info()))\n .payer(&ctx.accounts.payer.to_account_info())\n .authority(Some(&ctx.accounts.manager.to_account_info()))\n .system_program(&ctx.accounts.system_program.to_account_info())\n .plugin(Plugin::PermanentFreezeDelegate(PermanentFreezeDelegate { frozen: true }))\n .invoke_signed(&[signer_seeds])?;\n Ok(())\n}\nConclusionCongratulations! You are now equipped to create a Ticketing Solution using the Appdata Plugin. If you want to learn more about Core and Metaplex, check out the developer hub.","tokens":4890,"squid":"dotcat","role":"Tooling Spider","at":1791344624106,"hash":"a08d086b84dbb379b5f8d608ef20d2577b864316"}
{"url":"https://consensysdiligence.github.io/smart-contract-best-practices/development-recommendations/solidity-specific/modifiers-as-guards/","domain":"consensysdiligence.github.io","title":"Modifiers as Guards - Ethereum Smart Contract Best Practices","text":"Modifiers as Guards\n\nTip\nFor comprehensive insights into secure development practices, consider visiting the Development Recommendations section of the Smart Contract Security Field Guide. This resource provides in-depth articles to guide you in developing robust and secure smart contracts.\n\nThe code inside a modifier is usually executed before the function body, so any state changes or\nexternal calls will violate the\nChecks-Effects-Interactions\npattern. Moreover, these statements may also remain unnoticed by the developer, as the code for\nmodifier may be far from the function declaration. For example, an external call in modifier can\nlead to the reentrancy attack:\ncontract Registry {\n address owner;\n\n function isVoter(address _addr) external returns(bool) {\n // Code\n }\n}\n\ncontract Election {\n Registry registry;\n\n modifier isEligible(address _addr) {\n require(registry.isVoter(_addr));\n _;\n }\n\n function vote() isEligible(msg.sender) public {\n // Code\n }\n}\n\nIn this case, the Registry contract can make a reentrancy attack by calling Election.vote()\ninside isVoter().\n\nNote\nUse modifiers to\nreplace duplicate condition checks in multiple functions, such as isOwner(), otherwise use\nrequire or revert inside the function. This makes your smart contract code more readable and\neasier to audit.","tokens":326,"squid":"spider-06","role":"Security Spider","at":1791344624363,"hash":"2230e4343e58a5d5d12611431e63c3335c8c86e8"}
{"url":"https://consensysdiligence.github.io/smart-contract-best-practices/development-recommendations/precautions/safe-haven/","domain":"consensysdiligence.github.io","title":"Safe Haven - Ethereum Smart Contract Best Practices","text":"Safe Haven\n\nTip\nFor comprehensive insights into secure development practices, consider visiting the Development Recommendations section of the Smart Contract Security Field Guide. This resource provides in-depth articles to guide you in developing robust and secure smart contracts.\n\nSome tips for running bounty programs:\n\nDecide which currency bounties will be distributed in (BTC and/or ETH)\nDecide on an estimated total budget for bounty rewards\nFrom the budget, determine three tiers of rewards:\nsmallest reward you are willing to give out\nhighest reward that's usually awardable\nan extra range to be awarded in case of very severe vulnerabilities\nDetermine who the bounty judges are (3 may be ideal typically)\nLead developer should probably be one of the bounty judges\nWhen a bug report is received, the lead developer, with advice from judges, should evaluate the\n severity of the bug\nWork at this stage should be in a private repo, and the issue filed on Github\nIf it's a bug that should be fixed, in the private repo, a developer should write a test case,\n which should fail and thus confirm the bug\nDeveloper should implement the fix and ensure the test now passes; writing additional tests as\n needed\nShow the bounty hunter the fix; merge the fix back to the public repo is one way\nDetermine if bounty hunter has any other feedback about the fix\nBounty judges determine the size of the reward, based on their evaluation of both the\n likelihood and impact of the bug.\nKeep bounty participants informed throughout the process, and then strive to avoid delays in\n sending them their reward\n\nFor an example of the three tiers of rewards, see\nEthereum's Bounty Program:\n\nThe value of rewards paid out will vary depending on severity of impact. Rewards for minor\n'harmless' bugs start at 0.05 BTC. Major bugs, for example leading to consensus issues, will be\nrewarded up to 5 BTC. Much higher rewards are possible (up to 25 BTC) in case of very severe\nvulnerabilities.","tokens":493,"squid":"spider-06","role":"Security Spider","at":1791344633896,"hash":"184c61453cdbd004d0b40a4a74aba999f6ed57c2"}
{"url":"https://docs.phantom.com/best-practices/tokens/token-display","domain":"docs.phantom.com","title":"Display tokens on Solana - Phantom developer documentation","text":"If you’ve created a token on Solana using the SPL Token Program or Token-2022 Program (“Token Extensions”), then your token is compatible with Phantom. If Phantom users own a certain balance of a token made with these programs, that balance will always appear in their wallet. However, if Phantom cannot find more metadata about that token, it will display the token as “Unknown.”\n​Search for metadata\nWhen searching for metadata, Phantom will first look to the Token Metadata Program established by Metaplex. This program enhances ordinary SPL token mints with a Metadata Account that describes additional fields such as the token’s symbol, image, and description. Some of these fields exist on-chain in the Metadata Account itself, while others exist off-chain in a JSON file that follows a standard format. The link to this off-chain JSON file is found at the Metadata Account’s uri field.\nIf a Metadata Account is found, Phantom will prioritize on-chain fields (such as name, symbol) before off-chain fields described in the uri JSON file.\n​Categorize tokens\nPhantom will categorize and display tokens based on their Token Standard. The tokenStandard field can be found in the token’s on-chain Metadata Account and is used to describe a token’s fungibility. The tokenStandard field has four options:\n\nFungible: A token with simple metadata that can be freely mixed with others of the same mint. Common examples include USDC and SRM.\nFungibleAsset: A token with metadata that can also have NFT-like attributes. Commonly referred to as Semi-Fungible, these tokens are often used in gaming contexts to support stackable items like a piece of wood.\nNonFungible: A non-fungible token with a Master Edition account. This is the most popular type of NFT, encompassing well known collections like Solana Monkey Business and DeGods.\nNonFungibleEdition: A non-fungible token with an Edition account (printed from a Master Edition). This is a helpful feature for creators who want to offer multiple copies of their 1/1 NFTs.\nProgrammableNonFungible: A new non-fungible asset class that allows for flexible configuration of various lifecycle rules triggered by specific actions. For more information about Programmable NFTs or pNFTs, visit Programmable NFTs.\n\nIf no tokenStandard is set, Phantom will fallback to categorizing tokens based on the following logic:\n\nIf the total mint supply is 1, Phantom will consider the token to be NonFungible.\nIf the total mint supply is greater than 1 and the mint has 0 decimals, Phantom will consider the token to be a FungibleAsset.\nPhantom will consider all other tokens to be Fungible.\n\n​Display tokens\nPhantom will display all Fungible tokens in the Home tab. For more details on Fungible token best practices, refer to our Fungibles documentation.\nAll other token standards (FungibleAsset, NonFungible, NonFungibleEdition, and ProgrammableNonFungible) will be displayed in the Collectibles tab. For more information on collectible best practices, see Collectibles.\n​Token visibility\nBeyond metadata and display rules, Phantom applies trust and safety signals to determine whether a token is surfaced to users. Tokens that do not meet certain signals may be hidden or shown with a warning indicator. These signals are evaluated automatically across all tokens using multiple internal systems and third-party security providers, including Blockaid.\nPhantom does not publish specific visibility or spam classification criteria, raw detection reasons, or detailed provider signals. This helps protect users by preventing bad actors from using the criteria to bypass spam and scam detection.\nIf your token is not displaying as expected or is shown with a spam warning, ensure your token metadata is complete and accurate (see guidance above), and that your token is recognized by established token registries such as CoinGecko and Jupiter. If your token has been marked as spam, the best first step is to contact Blockaid through their Appeal Submission Portal. For current support guidance, see Token flagged as spam in Phantom.\nIf you have follow-up questions or need help from our Trust & Safety team, submit a ticket at help.phantom.com.Was this page helpful?","tokens":1049,"squid":"spider-10","role":"Tooling Spider","at":1791344634011,"hash":"0f733cd71befffa68eba9565f07383528e71bc85"}
{"url":"https://consensysdiligence.github.io/smart-contract-best-practices/development-recommendations/precautions/deployment/","domain":"consensysdiligence.github.io","title":"Deployment - Ethereum Smart Contract Best Practices","text":"Deployment\n\nTip\nFor comprehensive insights into secure development practices, consider visiting the Development Recommendations section of the Smart Contract Security Field Guide. This resource provides in-depth articles to guide you in developing robust and secure smart contracts.\n\nContracts should have a substantial and prolonged testing period - before substantial money is put\nat risk.\nAt minimum, you should:\n\nHave a full test suite with 100% test coverage (or close to it)\nDeploy on your own testnet\nDeploy on the public testnet with substantial testing and bug bounties\nExhaustive testing should allow various players to interact with the contract at volume\nDeploy on the mainnet in beta, with limits to the amount at risk\n\nAutomatic Deprecation¶\nDuring testing, you can force an automatic deprecation by preventing any actions, after a certain\ntime period. For example, an alpha contract may work for several weeks and then automatically shut\ndown all actions, except for the final withdrawal.\nmodifier isActive() {\n require(block.number <= SOME_BLOCK_NUMBER);\n _;\n}\n\nfunction deposit() public isActive {\n // some code\n}\n\nfunction withdraw() public {\n // some code\n}\n\nRestrict amount of Ether per user/contract¶\nIn the early stages, you can restrict the amount of Ether for any user (or for the entire contract)\n- reducing the risk.","tokens":336,"squid":"spider-06","role":"Security Spider","at":1791344645230,"hash":"2ab23f5d4e20682fb41e31b4540480b768b39e9d"}
{"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":"spider-08","role":"Oracle Spider","at":1791344648830,"hash":"49b035475e68d5322a784c661b28ab918e9d14a8"}
{"url":"https://consensysdiligence.github.io/smart-contract-best-practices/development-recommendations/precautions/circuit-breakers/","domain":"consensysdiligence.github.io","title":"Circuit Breakers - Ethereum Smart Contract Best Practices","text":"Circuit Breakers\n\nTip\nFor comprehensive insights into secure development practices, consider visiting the Development Recommendations section of the Smart Contract Security Field Guide. This resource provides in-depth articles to guide you in developing robust and secure smart contracts.\n\nCircuit breakers stop execution if certain conditions are met, and can be useful when new errors\nare discovered. For example, most actions may be suspended in a contract if a bug is discovered,\nand the only action now active is a withdrawal. You can either give certain trusted parties the\nability to trigger the circuit breaker or else have programmatic rules that automatically trigger\nthe certain breaker when certain conditions are met.\nExample:\nbool private stopped = false;\naddress private owner;\n\nmodifier isAdmin() {\n require(msg.sender == owner);\n _;\n}\n\nfunction toggleContractActive() isAdmin public {\n // You can add an additional modifier that restricts stopping a contract to be based on another action, such as a vote of users\n stopped = !stopped;\n}\n\nmodifier stopInEmergency { if (!stopped) _; }\nmodifier onlyInEmergency { if (stopped) _; }\n\nfunction deposit() stopInEmergency public {\n // some code\n}\n\nfunction withdraw() onlyInEmergency public {\n // some code\n}","tokens":317,"squid":"spider-06","role":"Security Spider","at":1791344655930,"hash":"eae562a158f629dade7aa9431778dc07d86ac391"}
{"url":"https://docs.phantom.com/best-practices/tokens/collectibles-nfts-and-semi-fungibles","domain":"docs.phantom.com","title":"NFTs and semi-fungibles - Phantom developer documentation","text":"On Solana, NFTs are often thought of as SPL Tokens with 0 decimals and a supply of 1. According to the Token Metadata Standard, however, it is possible for a range of different tokens to have NFT-like characteristics. Phantom refers to all NFT-like tokens as collectibles and will display them separately from Fungible tokens that appear on the Home tab. Specifically, Phantom will display all FungibleAsset, NonFungible, NonFungibleEdition and ProgrammableNonFungible tokens on their own Collectibles tab.\n​Group collectibles\nPhantom groups collectibles by their Certified Collections introduced in v1.1.0 of the Token Metadata Standard. In order to be grouped together, individual NFTs should all reference the same verified collection mint address. This mint address is itself home to an NFT with metadata that describes the collection as in the example. Creators must ensure that this collection is verified on-chain (that is, that verified is set to true).\nIf no verified collection is found, Phantom will fallback to grouping NFTs by the first verified creator’s address in the on-chain creators field. If two unverified items share the same creator address at the 0 index of their creators array, they will be grouped into the same collection.\n​Name grouped collectibles\nWhen a group is created, a best-effort process is used to determine that group’s name. Phantom will look to these fields in the following order of preference:\n\nname of the verified on-chain collection NFT\ncollection.name\ncollection.family\nexternal_url (parsed to remove url parts)\nname (of a single collectible)\nsymbol\naddress of the first verified creator in the creators array (also used to group the collection)\n\n​Display an individual collectible\nWhen displaying the detail view of an individual collectible, Phantom will prioritize on-chain data in the Metadata Account over off-chain JSON linked via the uri field. This impacts both the name and symbol field which appears in both locations.\n​Render collectible media\n​Supported media types\nPhantom supports a wide-range of media types. For a full list, refer to Supported media types.\n​Select media\nWhen determining what media to display for a given collectible, Phantom will search the off-chain JSON for data in the following order:\n\nanimation_url: Phantom will select the media source at the collectible’s animation_url field.\nproperties.files: If no animation_url is found, Phantom will choose the first file where the cdn property is set to true. Otherwise, a file will be chosen based on the media type in the following order of preference:\n\nimage\naudio\nvideo\nvr or model\n\nimage: Finally, if Phantom still cannot find media to display, it will fallback to the media source at the collectible’s image field.\n\n​Determine media type\nIf a media source is found in properties.files, and that source is defined as an object, Phantom will determine the media type based on that file’s type property. Under the Token Metadata Standard, file objects are defined with the following structure:\nFieldTypeDescriptiontypestringThe media type of the file. If selected, Phantom will use this to determine the media type. For example, “image/png.”uristringThe URI source of the file. For example, https://asfh3uxyeoyvtkfqc7jagy3mhtsszhyubnc3wfss5ismdgtw.arweave.net/BIp90vgjs_VmosBfSA2NsPOUsnxQLRbsWUuo-kwZp2o?ext=pngcdnboolean (optional)An optional flag that dictates if the file is hosted on a cdn. If true, Phantom will select this file as the primary source file.\nIn cases where Phantom cannot find a source from properties.files, it may fallback to a media source that is defined as a string (such as animation_url or image). In these cases, Phantom will look for data in the following order of preference:\n\nThe media source URI’s ?ext= query string parameter (https://example.com/foo?ext=png).\nThe media source URI’s pathname extension (https://example.com/foo.png).\nIf the media source URI comes from the animation_url, Phantom will infer the media type based on the collectible’s properties.category field.\nIf the media source URI comes from the image field, Phantom will default to assume it is a PNG.\n\nIf no supported media type can be determined, no media will be selected, and users may see a placeholder image instead.\n​Resize images\nPhantom will resize all collectible images to 256x256 pixels. For best results, we recommend images with a square aspect ratio and a power-of-2 dimension (for example, 256x256, 512x512, or 1024x1024).Was this page helpful?","tokens":1123,"squid":"spider-10","role":"Tooling Spider","at":1791344655979,"hash":"4da0d78bfb7fa4c4834587886eff9944c2e12a3e"}
{"url":"https://consensysdiligence.github.io/smart-contract-best-practices/development-recommendations/precautions/general/","domain":"consensysdiligence.github.io","title":"General - Ethereum Smart Contract Best Practices","text":"General\n\nTip\nFor comprehensive insights into secure development practices, consider visiting the Development Recommendations section of the Smart Contract Security Field Guide. This resource provides in-depth articles to guide you in developing robust and secure smart contracts.\n\nAs we discussed in the General Philosophy section, it is not enough to\nprotect yourself against the known attacks. Since the cost of failure on a blockchain can be very\nhigh, you must also adapt the way you write software, to account for that risk.\nThe approach we advocate is to \"prepare for failure\". It is impossible to know in advance whether\nyour code is secure. However, you can architect your contracts in a way that allows them to fail\ngracefully, and with minimal damage. This section presents a variety of techniques that will help\nyou prepare for failure.\nNote: There's always a risk when you add a new component to your system. A badly designed fail-safe\ncould itself become a vulnerability, as can the interaction between a number of well-designed\nfail-safes. Be thoughtful about each technique you use in your contracts, and consider carefully\nhow they work together to create a robust system.","tokens":297,"squid":"spider-06","role":"Security Spider","at":1791344665200,"hash":"0cda7c2fab7ac89a8da29c70ddd85cedfbd5667f"}
{"url":"https://docs.pyth.network/price-feeds/core/create-your-first-pyth-app/evm/part-1","domain":"docs.pyth.network","title":"Create your first Pyth app on EVM | Pyth Developer Hub","text":"Pyth CoreCreate Your First Pyth Appon EVMCreate your first Pyth app on EVMBuild and test an EVM app using Pyth price feedsIn this tutorial, we will use real-time Pyth price data to mint an NFT in exchange for $1 of ETH.\nOur solidity contract will read the price of ETH/USD from Pyth and use it to calculate the amount of ETH required to mint the NFT.\nThis tutorial will cover the following topics:\n\nCreate a contract that reads the ETH/USD price from Pyth using pyth-sdk-solidity\nLearn how to update Pyth prices to avoid Stale data.\nDeploy the contract to OP-sepolia testnet.\nUpdate and Fetch price using hermes-client.\n\nThis tutorial is divided into two parts:\n\nPart 1: Create a contract and fetch prices from Pyth oracles. \\\nPart 2: Deploy Your Pyth App\n\nCreate a contract and fetch prices from Pyth oracles\nIn this part of the tutorial, we will create a contract that reads the price from Pyth and uses it to calculate the amount of ETH required to mint an NFT.\nAfter that, we will write tests to ensure that the contract works as expected.\nPreliminaries\nThis tutorial uses Foundry to perform the contract development tasks.\nPlease make sure these are installed on your system before continuing.\n\nfoundry\nnode\ncurl\njq\n\nCreate a Foundry projectCreate a new directory to hold your app and a contracts directory within.\nHere forge init command will initialize an empty foundry project creating several subdirectories within contracts.mkdir my_first_pyth_app\nmkdir my_first_pyth_app/contracts && cd my_first_pyth_app/contracts\nforge initThe src directory will hold your contract code, and the test directory will hold unit tests.\nBoth directories are initialized with some sample contract code and tests.Try it out by running forge test.\nThis command should print out something like this:[⠢] Compiling...\nNo files changed, compilation skipped\n\nRunning 2 tests for test/Counter.t.sol:CounterTest\n[PASS] testFuzz_SetNumber(uint256) (runs: 256, μ: 27864, ~: 28409)\n[PASS] test_Increment() (gas: 28379)\nTest result: ok. 2 passed; 0 failed; 0 skipped; finished in 12.30ms\n\nRan 1 test suites: 2 tests passed, 0 failed, 0 skipped (2 total tests)The Foundry project has been successfully initialized!\nAt this point, delete the sample code from src and the test file from test -- we won't need them anymore.rm -r src/* test/* scripts/*Install the Pyth SDKPyth provides a Solidity SDK that can be used to interact with one-chain Pyth Price Feed contracts.\nIt exposes multiple methods to read and interact with the contracts.Use npm to add the Pyth SDK:npm init -y\nnpm install @pythnetwork/pyth-sdk-solidityNext, run the following command to create a text file contracts/remappings.txt:echo '@pythnetwork/pyth-sdk-solidity/=node_modules/@pythnetwork/pyth-sdk-solidity' > remappings.txtThis line tells Foundry where to find the Pyth SDK so that you can import it from Solidity contracts.Create a contractNext, open src/MyFirstPythContract.sol in your favorite editor and add the following code:// SPDX-License-Identifier: UNLICENSED\npragma solidity ^0.8.13;\n\nimport { console2 } from \"forge-std/Test.sol\";\nimport \"@pythnetwork/pyth-sdk-solidity/IPyth.sol\";\n\ncontract MyFirstPythContract {\n IPyth pyth;\n bytes32 ethUsdPriceId;\n\n constructor(address _pyth, bytes32 _ethUsdPriceId) {\n pyth = IPyth(_pyth);\n ethUsdPriceId = _ethUsdPriceId;\n }\n}\nNotice that this code block imports the IPyth interface from the SDK you installed earlier.\nThis interface is the primary way to interact with the Pyth price feeds contract.\nThe constructor instantiates this interface with the address of the Pyth contract.\nIt also takes an _ethUsdPriceId.\nWe will see how to populate both parameters later on.Next, add a mint function to your contract:contract MyFirstPythContract {\n // ... other functions omitted\n\n function mint() public payable {\n PythStructs.Price memory price = pyth.getPriceNoOlderThan(\n ethUsdPriceId,\n 60\n );\n\n uint ethPrice18Decimals = (uint(uint64(price.price)) * (10 ** 18)) /\n (10 ** uint8(uint32(-1 * price.expo)));\n uint oneDollarInWei = ((10 ** 18) * (10 ** 18)) / ethPrice18Decimals;\n\n console2.log(\"required payment in wei\");\n console2.log(oneDollarInWei);\n\n if (msg.value >= oneDollarInWei) {\n // User paid enough money.\n // TODO: mint the NFT here\n } else {\n revert InsufficientFee();\n }\n }\n\n // Error raised if the payment is not sufficient\n error InsufficientFee();\n}\nThis function first reads a Price from the pyth contract if it is updated within the last 60 seconds.\nIt then performs some arithmetic on the price in order to calculate how much the caller needs to pay. This conversion\nassumes that 10^18 wei is equal to the native token (ETH in this example); in some networks (like Hedera) the decimal\nplaces are different and you need to change the math.\nIf the caller has not paid enough, the function reverts.Try out your changes by running forge build:[⠒] Compiling...\n[⠘] Compiling 28 files with 0.8.23\n[⠊] Solc 0.8.23 finished in 2.71s\nCompiler run successful!The contract compiles!Create a testBefore deploying the contract, let's write a test to make sure it works.\nOpen test/MyFirstPythContract.t.sol in your favorite editor and add the following code:// SPDX-License-Identifier: UNLICENSED\npragma solidity ^0.8.13;\n\nimport { Test, console2 } from \"forge-std/Test.sol\";\nimport { MyFirstPythContract } from \"../src/MyFirstPythContract.sol\";\nimport { MockPyth } from \"@pythnetwork/pyth-sdk-solidity/MockPyth.sol\";\n\ncontract MyFirstPythContractTest is Test {\n MockPyth public pyth;\n bytes32 ETH_PRICE_FEED_ID = bytes32(uint256(0x1));\n MyFirstPythContract public app;\n\n uint256 ETH_TO_WEI = 10 ** 18;\n\n function setUp() public {\n pyth = new MockPyth(60, 1);\n app = new MyFirstPythContract(address(pyth), ETH_PRICE_FEED_ID);\n }\n\n function createEthUpdate(\n int64 ethPrice\n ) private view returns (bytes[] memory) {\n bytes[] memory updateData = new bytes[](1);\n updateData[0] = pyth.createPriceFeedUpdateData(\n ETH_PRICE_FEED_ID,\n ethPrice * 100000, // price\n 10 * 100000, // confidence\n -5, // exponent\n ethPrice * 100000, // emaPrice\n 10 * 100000, // emaConfidence\n uint64(block.timestamp), // publishTime\n uint64(block.timestamp) // prevPublishTime\n );\n\n return updateData;\n }\n\n function setEthPrice(int64 ethPrice) private {\n bytes[] memory updateData = createEthUpdate(ethPrice);\n uint value = pyth.getUpdateFee(updateData);\n vm.deal(address(this), value);\n pyth.updatePriceFeeds{ value: value }(updateData);\n }\n\n function testMint() public {\n setEthPrice(100);\n\n vm.deal(address(this), ETH_TO_WEI);\n app.mint{ value: ETH_TO_WEI / 100 }();\n }\n\n function testMintRevert() public {\n setEthPrice(99);\n\n vm.deal(address(this), ETH_TO_WEI);\n vm.expectRevert();\n app.mint{ value: ETH_TO_WEI / 100 }();\n }\n}\nTake a look at the two test functions at the end of this file.\nThese tests set the price of Ether to a specific value, then call mint.\nThe tests use a mock implementation of Pyth and some helper methods defined above to set the price of Ether.Try your tests by running forge test -vvv[⠢] Compiling...\n[⠔] Compiling 1 files with 0.8.23\n[⠒] Solc 0.8.23 finished in 1.23s\nCompiler run successful!\n\nRunning 2 tests for test/MyFirstPythContract.t.sol:MyFirstPythContractTest\n[PASS] testMint() (gas: 197064)\nLogs:\n required payment in wei\n 10000000000000000\n\n[PASS] testMintRevert() (gas: 197468)\nLogs:\n required payment in wei\n 10101010101010101\n\nTest result: ok. 2 passed; 0 failed; 0 skipped; finished in 702.58µs\n\nRan 1 test suites: 2 tests passed, 0 failed, 0 skipped (2 total tests)The tests pass!\nThe tests also print out the required payment to successfully mint the NFT -- these originate from the console2.log statements in MyFirstPythContract.\nNotice that the payment is higher in the second test: when the price of ETH is $99 (instead of $100), more ETH is required to reach $1.\nThis difference demonstrates that your contract is successfully reading the price of ETH/USD from Pyth.Update Pyth pricesWhile our code above seems to work properly, it has a problem.\nTo see this problem, let's add another test to the test suite:contract MyFirstPythContractTest is Test {\n // ... prior tests omitted ...\n\n function testMintStalePrice() public {\n setEthPrice(100);\n\n skip(120);\n\n vm.deal(address(this), ETH_TO_WEI);\n app.mint{ value: ETH_TO_WEI / 100 }();\n }\n}\nNotice that this test is the same as the first test, except it adds a call to skip in the middle.Now run forge test -vvv[FAIL. Reason: StalePrice()] testMintStalePrice() (gas: 192722)Oh no, the test fails with a StalePrice error!\nWhen our contract calls getPriceNoOlderThan(.., 60), it checks the timestamp on the blockchain and compares it to the timestamp for the Pyth price.\nIf the Pyth price's timestamp is more than 60 seconds in the past, then a StalePrice error occurs.\nskip moves the timestamp on the blockchain forward, which triggers the error.We can fix this problem, but first, let's fix the test case.\nAdd a call to vm.expectRevert() as shown below:contract MyFirstPythContractTest is Test {\n // ... prior tests omitted ...\n function testMintStalePrice() public {\n setEthPrice(100);\n\n skip(120);\n\n vm.deal(address(this), ETH_TO_WEI);\n // Add this line\n vm.expectRevert();\n app.mint{ value: ETH_TO_WEI / 100 }();\n }\n}\nTo fix the StalePrice error, add a new function to MyFirstPythContract:contract MyFirstPythContract {\n // ... prior code omitted\n\n function updateAndMint(bytes[] calldata pythPriceUpdate) external payable {\n uint updateFee = pyth.getUpdateFee(pythPriceUpdate);\n pyth.updatePriceFeeds{ value: updateFee }(pythPriceUpdate);\n\n mint();\n }\n}\nThe end of this function calls the mint function we defined before.\nBefore that, however, the function calls updatePriceFeeds on the Pyth contract.\nThis function takes a payload of bytes[] that is passed into the function itself.\nThe Pyth contract requires a fee to perform this update; the code snippet above calculates the needed fee using getUpdateFee.\nThe caller of this function can pass in a recent Pyth price update as this payload, guaranteeing that the StalePrice error won't occur.We can test this function by adding the following snippet to the test file:contract MyFirstPythContractTest is Test {\n // ... prior tests omitted ...\n function testUpdateAndMint() public {\n bytes[] memory updateData = createEthUpdate(100);\n\n vm.deal(address(this), ETH_TO_WEI);\n app.updateAndMint{ value: ETH_TO_WEI / 100 }(updateData);\n }\n}\nNote that this test creates and passes a price update directly to updateAndMint instead of calling setEthPrice like\nthe previous tests. For this test, we created a mock price update using the testing library.\nWhen the contract is deployed, we will retrieve the price update from a web service.Run this new test with forge test -vvv[⠢] Compiling...\n[⠰] Compiling 1 files with 0.8.23\n[⠔] Solc 0.8.23 finished in 1.19s\nCompiler run successful!\n\nRunning 4 tests for test/MyFirstPythContract.t.sol:MyFirstPythContractTest\n[PASS] testMint() (gas: 197148)\nLogs:\n required payment in wei\n 10000000000000000\n\n[PASS] testMintRevert() (gas: 197575)\nLogs:\n required payment in wei\n 10101010101010101\n\n[PASS] testMintStalePrice() (gas: 193074)\n[PASS] testUpdateAndMint() (gas: 197067)\nLogs:\n required payment in wei\n 10000000000000000\n\nTest result: ok. 4 passed; 0 failed; 0 skipped; finished in 1.54ms\n\nRan 1 test suites: 4 tests passed, 0 failed, 0 skipped (4 total tests)The test passes!Congratulations! We have successfully created a contract that reads the price of ETH/USD from Pyth and uses it to calculate the amount of ETH required to mint an NFT.In this part of the tutorial, we learned how to create a contract that reads the price from Pyth oracle and how to update the price to avoid stale data.\nWe also wrote tests to ensure that the contract works as expected.Our final contract code should look like this:// SPDX-License-Identifier: UNLICENSED\npragma solidity ^0.8.13;\n\nimport { console2 } from \"forge-std/Test.sol\";\nimport \"@pythnetwork/pyth-sdk-solidity/IPyth.sol\";\n\ncontract MyFirstPythContract {\n IPyth pyth;\n bytes32 ethUsdPriceId;\n\n constructor(address _pyth, bytes32 _ethUsdPriceId) {\n pyth = IPyth(_pyth);\n ethUsdPriceId = _ethUsdPriceId;\n }\n\n function mint() public payable {\n PythStructs.Price memory price = pyth.getPriceNoOlderThan(\n ethUsdPriceId,\n 60\n );\n console2.log(\"price of ETH in USD\");\n console2.log(price.price);\n\n uint ethPrice18Decimals = (uint(uint64(price.price)) * (10 ** 18)) /\n (10 ** uint8(uint32(-1 * price.expo)));\n uint oneDollarInWei = ((10 ** 18) * (10 ** 18)) / ethPrice18Decimals;\n\n console2.log(\"required payment in wei\");\n console2.log(oneDollarInWei);\n\n if (msg.value >= oneDollarInWei) {\n // User paid enough money.\n // TODO: mint the NFT here\n } else {\n revert InsufficientFee();\n }\n }\n\n function updateAndMint(bytes[] calldata pythPriceUpdate) external payable {\n uint updateFee = pyth.getUpdateFee(pythPriceUpdate);\n pyth.updatePriceFeeds{ value: updateFee }(pythPriceUpdate);\n\n mint();\n }\n\n // Error raised if the payment is not sufficient\n error InsufficientFee();\n}\nAnd our test file should look like this:// SPDX-License-Identifier: UNLICENSED\npragma solidity ^0.8.13;\n\nimport { Test, console2 } from \"forge-std/Test.sol\";\nimport { MyFirstPythContract } from \"../src/MyFirstPythContract.sol\";\nimport { MockPyth } from \"@pythnetwork/pyth-sdk-solidity/MockPyth.sol\";\n\ncontract MyFirstPythContractTest is Test {\n MockPyth public pyth;\n bytes32 ETH_PRICE_FEED_ID = bytes32(uint256(0x1));\n MyFirstPythContract public app;\n\n uint256 ETH_TO_WEI = 10 ** 18;\n\n function setUp() public {\n pyth = new MockPyth(60, 1);\n app = new MyFirstPythContract(address(pyth), ETH_PRICE_FEED_ID);\n }\n\n function createEthUpdate(\n int64 ethPrice\n ) private view returns (bytes[] memory) {\n bytes[] memory updateData = new bytes[](1);\n updateData[0] = pyth.createPriceFeedUpdateData(\n ETH_PRICE_FEED_ID,\n ethPrice * 100000,\n 10 * 100000,\n -5,\n ethPrice * 100000,\n 10 * 100000,\n uint64(block.timestamp),\n uint64(block.timestamp)\n );\n\n return updateData;\n }\n\n function setEthPrice(int64 ethPrice) private {\n bytes[] memory updateData = createEthUpdate(ethPrice);\n uint value = pyth.getUpdateFee(updateData);\n console2.log(\"value: \", value);\n vm.deal(address(this), value);\n pyth.updatePriceFeeds{ value: value }(updateData);\n }\n\n function testMint() public {\n setEthPrice(100);\n\n vm.deal(address(this), ETH_TO_WEI);\n app.mint{ value: ETH_TO_WEI / 100 }();\n }\n\n function testMintRevert() public {\n setEthPrice(99);\n\n vm.deal(address(this), ETH_TO_WEI);\n vm.expectRevert();\n app.mint{ value: ETH_TO_WEI / 100 }();\n }\n\n function testMintStalePrice() public {\n setEthPrice(100);\n\n skip(120);\n\n vm.deal(address(this), ETH_TO_WEI);\n\n vm.expectRevert();\n app.mint{ value: ETH_TO_WEI / 100 }();\n }\n\n function testUpdateAndMint() public {\n bytes[] memory updateData = createEthUpdate(100);\n\n vm.deal(address(this), ETH_TO_WEI);\n app.updateAndMint{ value: ETH_TO_WEI / 100 }(updateData);\n }\n}\n\nCheck out Part 2 to learn how to deploy our contract to OP-sepolia testnet and fetch prices using hermes-client.Create your first Pyth appBuild your first application that consumes Pyth price feedsPart 2: Deploy Pyth AppNext Page","tokens":3778,"squid":"spider-08","role":"Oracle Spider","at":1791344667861,"hash":"212d5fe0c829009e6658a7c6644b33a6886be365"}
{"url":"https://docs.phantom.com/best-practices/tokens/home-tab-fungibles","domain":"docs.phantom.com","title":"Fungibles - Phantom developer documentation","text":"​Display fungible tokens\nPhantom prioritizes on-chain metadata that follows the Token Metadata Standard. For fungible tokens specifically, Phantom will show the following fields:\nFieldDescriptionnameThe name of the token, such as “USD Coin.”symbolThe symbol of the token, such as ”USDC.”imageA URI pointing to the token’s logo.\nIf a Fungible token has name and symbol fields present on both its on-chain Metadata Account and off-chain JSON file (linked via the on-chain uri field), Phantom will prioritize the on-chain fields.\nIf a Fungible token does not have an on-chain Metadata Account, Phantom will fallback to displaying data from the Solana Labs Token List. This list is considered deprecated and should not be used to host new tokens. When reading from the token list, Phantom will display the following fields:\nFieldDescriptionnameThe name of the token, such as “USD Coin.”symbolThe symbol of the token, such as ”USDC.”logoURIA URI pointing to the token’s logo.extensions.coingeckoIDThe token ID as defined by the Coingecko API. Phantom uses this to fetch the price of the token.\n​Display prices\nPhantom will display prices for any token that is verified on Coingecko. When verifying with Coingecko, be sure to include the token’s contract. For Solana tokens, this should be the mint address. For example, Bonk is verified with the contract DezXAZ8z7PnrnRJjz3wXBoRgixCa6xjnB7YaB1pPB263. Once a token has verified its contract address with Coingecko, Phantom will automatically begin displaying its price.\nIf Coingecko is unable to return a price for a given token, Phantom will fallback to using Birdeye for token prices.Was this page helpful?","tokens":413,"squid":"spider-10","role":"Tooling Spider","at":1791344668277,"hash":"9cf697287059253305b882460a767fbc459dc222"}
{"url":"https://developer.arbitrum.io/launch-arbitrum-chain/integrations/exchange-integration-checklist","domain":"developer.arbitrum.io","title":"Exchange integration checklist: deposit and withdrawal verification","text":"Ecosystem supportExchange integration checklist: deposit and withdrawal verificationA version-pinned checklist that helps centralized exchanges reliably detect deposits, process withdrawals, and re-verify their indexing logic across Nitro and ArbOS upgrades on Dedicated Blockchains.Request an updateThis checklist helps centralized exchanges (and other custodial integrators) detect deposits and process withdrawals reliably on and Dedicated Blockchains. It also provides a repeatable procedure for re-verifying your indexing logic whenever a new Nitro release or an upgrade reaches your chain.\nThe two failure modes every exchange must avoid are the same:\n\nFalse credits: crediting a user for a transaction that did not actually transfer value to a platform-controlled address (a reverted transaction, a spoofed event, the wrong token, or an internal call that did not succeed).\nMissed deposits: failing to credit a real transfer because it arrived through a path your indexer does not scan (ETH moved by an internal call, a token moved without a top-level transfer(), or value delivered by an Arbitrum-specific transaction type).\n\nThe detection flow below is designed to make both failure modes structurally impossible: you examine every transaction in every block, validate each one against its receipt and traces rather than its calldata, and credit only after the block is final on the parent chain.\nRe-verify on every upgradeArbOS upgrades are Arbitrum's equivalent of a hard fork and can change trace output, gas accounting, and transaction-type handling. Treat the Re-verification procedure as mandatory before each upgrade activates on your chain, not as optional cleanup afterward.\nBefore you start\nRequirementWhy it mattersA full node with the debug API enabled (--http.api=eth,debug,net,web3), or an RPC provider that exposes debug_traceBlockByHash.Catching ETH delivered through internal calls requires call traces. The eth namespace alone is not sufficient.A Nitro version greater than or equal to the release that ships the latest ArbOS used by your chain.Nitro is backward compatible, but trace output and gas accounting are tied to the active ArbOS version.The exact set of platform-controlled deposit addresses, plus supported token contract addresses with their decimals.Every detection rule below keys off these two sets.Confirmation of whether your chain supports the finalized and safe block tags.These tags are available on Arbitrum One. On a Dedicated Blockchain, support depends on your parent-chain configuration.\nRun an archive or debug-capable nodedebug_traceBlockByHash may not return traces beyond a pruned node's retention window. Index in near real time, or run an archive node when you need to backfill historical blocks.\nHow deposit detection works\nPoll the chain roughly once per second and process every block exactly once, in order, with no gaps:\neth_blockNumber → latest sequenced height\n └─ for each unprocessed height:\n eth_getBlockByNumber → block, including the ordered \"transactions\" array\n debug_traceBlockByHash → per-transaction call traces (tracer: callTracer)\n └─ for each transaction:\n eth_getTransactionByHash → transaction detail (to, value, input, type)\n eth_getTransactionReceipt → status, logs, gasUsed\n classify → ETH | ERC-20 | internal → add to the READY list\n └─ eth_getBlockByNumber(\"finalized\") → credit READY deposits at or under the finalized height\nThree properties make this correct. You examine every transaction in every block, plus internal calls through traces, so no value-bearing path is skipped. You credit only transactions whose receipt status is 0x1 and whose movement is confirmed by an event log or a trace, not solely by calldata. And you credit only after a block is finalized on the parent chain, so a parent-chain reorganization cannot reverse a credited deposit.\nCalldata here means transaction input, not batch data availabilityThroughout this guide, \"calldata\" means a transaction's input field, the per-transaction data you read over RPC and deliberately validate against receipts and traces. It is unrelated to how your chain posts batches to its parent chain, whether as EIP-4844 blobs or parent-chain calldata. That data-availability choice does not affect deposit detection: you always index transactions through the RPC methods below.\nStep 1: Stay in sync with the chain head\n\nCall eth_blockNumber to get the latest sequenced height.\nCompare it against your last scanned height.\nFor each missing height, call eth_getBlockByNumber(height, true) to retrieve full transaction objects. The returned transactions array is ordered; use that ordering as the index for the trace output in the next step.\nHandle reorganizations by rewinding, not patching. Store each scanned block's hash, keyed by height. On each poll, confirm that every new block's parentHash matches the hash you stored for the height below it. A mismatch means the chain reorganized — and because a reorg can both remove a deposit and introduce a new one, re-checking only the records already in READY is not enough. Walk back to the most recent height whose stored hash still matches the canonical chain (the common ancestor), discard every READY entry and stored hash above it, move your scan cursor back to that height, and re-scan forward from there. You never need to rewind below the finalized height, because finalized blocks cannot reorganize.\n\nArbitrum block timingArbitrum produces blocks far more frequently than Ethereum, and the Sequencer assigns their ordering. The latest tag is the Sequencer tip and is not yet final. Never credit a deposit based on latest. See Step 4.\nStep 2: Pull call traces for the block\nCall debug_traceBlockByHash(blockHash, {\"tracer\": \"callTracer\"}).\nThe result is an array whose entries correspond one-to-one, by index, with the block's transactions array: trace[i] is the trace for transactions[i]. Each entry's result contains the top-level call plus a nested calls array describing internal calls. Only CALL frames carry ETH value; STATICCALL and DELEGATECALL frames never do. This is how you detect ETH that moved through an internal call rather than a top-level transfer.\nAttach each trace to its transaction by index before classifying, then confirm against the transaction hash.\nStep 3: Classify and validate every transaction\nFor each transaction, first fetch its details and receipt:\n\neth_getTransactionByHash(txHash) returns from, to, value, input, and type.\neth_getTransactionReceipt(txHash) returns status, logs, and gas or gasUsed.\n\nGate first. If status is not 0x1, skip the transaction entirely. A reverted transaction never moves value, regardless of what its calldata claims. This single check is your primary defense against false credits.\nThen apply the checks below in order, A through C.\nA. Native ETH deposit\nThis applies when to is one of your platform deposit addresses.\nRead value, convert it from hexadecimal to decimal, and divide by 10^18. Record {from, to, amount, coin: \"ETH\", blockNumber, blockHash, txHash} in the READY list.\nB. Standard ERC-20 token deposit\nThis applies when to is one of your supported token contract addresses, input begins with 0xa9059cbb (the transfer(address,uint256) selector), and input is 138 hexadecimal characters long (0x plus 8 selector characters, 64 address characters, and 64 amount characters).\nDo not trust calldata alone. Confirm the transfer against the receipt:\n\ngas is greater than or equal to gasUsed.\nlogs has at least one entry.\nA log exists where all of the following hold:\n\nlog.address equals receipt.to (the token contract).\ntopics[0] equals 0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef, the Transfer(address,address,uint256) event signature.\n0x followed by topics[1][26:66] (the sender) equals the transaction from.\n0x followed by topics[2][26:66] (the recipient) equals 0x followed by input[34:74], and is a platform user's address.\ndata[2:66] (the transferred amount) equals input[74:138].\n\nCredit data[2:66] as decimal, divided by 10^decimals for that token. Record {from, toAddress, amount, coin, blockNumber, blockHash, txHash}.\nC. Internal token or ETH deposit\nThis is the catch-all reached when neither A nor B matched. Value can still have reached a platform address through an internal call. Require gas >= gasUsed, and, for the token sub-case, require more than one log entry.\nFor an internal token transfer, scan every entry in the receipt logs. Credit the transfer when log.address is one of your supported token contracts (this identifies the coin), topics[0] is the Transfer signature above, and 0x followed by topics[2][26:66] is a platform user's address. Credit data[2:66] divided by 10^decimals.\nFor an internal ETH transfer, recursively scan the callTracer frames for the transaction — the top-level call and every entry in its nested calls arrays. Credit a frame when to is a platform user's address, value is not 0x0, the frame's type is CALL (only CALL frames carry ETH value), the frame has no error, and the frame's gasUsed is less than or equal to its gas. Credit value divided by 10^18.\nArbitrum-specific deposits to watchBesides ordinary externally owned account transactions, value can arrive through Arbitrum-native transaction types. When a user bridges directly to an exchange-controlled address, the credit appears as an ArbitrumDepositTx (type 0x64), where ArbOS adds balance to the destination after the parent-chain bridge locks the same funds. Retryable-ticket execution (ArbitrumRetryTx, 0x68, and ArbitrumSubmitRetryableTx, 0x69) can also deliver value. System transactions of type ArbitrumInternalTx (0x6A) are ArbOS-generated bookkeeping and must never be credited. Classify by observed value movement, as in A through C, rather than assuming every credit is a standard transfer. See Geth at the core for the full list of transaction types.\nStep 4: Confirm finality before crediting\nRun an asynchronous loop that calls eth_getBlockByNumber(\"finalized\", false) and reads result.number as the finalized height. For each READY entry whose block height is at or below the finalized height, credit the mapped user the recorded amount and coin. Because Step 1 rewinds and re-scans whenever a block's hash stops matching the canonical chain, every READY entry at or below the finalized height already reflects the canonical chain, and finalized blocks can no longer reorganize — so a match on height is sufficient to credit.\nThe block tags carry different finality guarantees:\n\nlatest is the Sequencer tip and is not yet posted to the parent chain. Never credit on latest.\nsafe means the batch containing this block has been posted and reached finality on the parent chain. It is resistant to reorganizations but can still be reverted by a deep parent-chain reorganization.\nfinalized means the batch is finalized on the parent chain, and reversal is highly improbable. Credit occurs here.\n\nFinality on Dedicated BlockchainsThe safe and finalized tags are available on Arbitrum One. On a self-managed Dedicated Blockchain, support for these tags depends on your parent-chain configuration and on how your node tracks parent-chain finality. Confirm the behavior on your chain before relying on finalized, and document the expected confirmation latency for your integrators.\nWithdrawal flow\nDistinguish two operations that are both casually called \"withdrawals.\"\nExchange to the user on the same Dedicated Blockchain\nThis is the common case: an ordinary transaction from your hot wallet to the user's address, either a native ETH transfer or a token transfer(). Submit the transaction and track it by hash. Mark the withdrawal complete only when eth_getTransactionReceipt returns a status of 0x1, and apply the same finality discipline you use for deposits before treating it as irreversible. Use EIP-1559-style fee fields, and account for the parent-chain data-posting fee, which is reflected in the effective gas cost rather than in the gas units.\nBridging value to the parent chain\nIf the user withdraws to the parent chain (for example, from Arbitrum One to Ethereum), the funds move through the bridge and outbox and are subject to the dispute window before they can be claimed. Do not treat the parent-chain side as settled until the message is confirmed and executed through the outbox. Direct integrators to the bridge documentation for the current dispute-period mechanics rather than hard-coding a duration.\nTest vectors\nMaintain at least one fixture per detection path so you can assert that your indexer credits the right amount and rejects everything else. Capture each fixture from a live node (Arbitrum Sepolia is preferred because it receives ArbOS upgrades first) and pin it to the stated Nitro and ArbOS versions.\nTV #ScenarioExpected result1Native ETH transfer to a platform deposit address, status 0x1Credit ETH equal to value / 10^182ERC-20 transfer() to a supported token with a valid Transfer logCredit token equal to amount / 10^decimals3ERC-20 transfer() that reverts (status 0x0)No credit4Token moved through an internal call (no top-level transfer())Credit through the log scan in C5ETH moved to a user through an internal call frameCredit through the trace scan in C6ArbitrumDepositTx (0x64) to a platform addressCredit ETH from the bridge deposit7ArbitrumInternalTx (0x6A) system transactionNo credit8Transfer event emitted by an unsupported or spoofed contractNo credit (address not in the set)\nEach fixture should record the block hash, the transaction hash, the raw eth_getTransactionByHash and eth_getTransactionReceipt responses, the relevant slice of debug_traceBlockByHash, and the expected credit or rejection.\nVersion compatibility\nArbOS upgrades can change the details this logic depends on, so confirm versions against the ArbOS releases overview and the Nitro releases page before each integration cycle. Three things can change across an upgrade and affect your indexer:\n\nTracer output — the structure or completeness of debug_traceBlockByHash call frames.\nGas accounting — how gasUsed is computed and how the parent-chain data fee is represented.\nTransaction-type handling — the addition of, or changes to, Arbitrum-native transaction types.\n\nNone of the historical upgrades that prompted partner questions changed the core detection contract (poll, fetch the block, trace, validate logs and traces, then gate on finality). Each one still has to be re-verified, because an upgrade could change the byte-level details above.\nRe-verification procedure\nRun this whenever a new Nitro release or ArbOS upgrade targets your chain, before activation on your production chain rather than after.\n\nWatch the upgrade channels. Subscribe to the Arbitrum Node Upgrade Announcement channel on Telegram and read the relevant upgrade notice.\nTest on Sepolia first. Arbitrum Sepolia receives ArbOS upgrades ahead of Arbitrum One. Point a staging indexer at a Sepolia node running the new Nitro version.\nReplay your test vectors. Run TV-1 through TV-8 against the upgraded node and assert identical credit and rejection outcomes.\nDiff the raw responses. Compare debug_traceBlockByHash, eth_getTransactionReceipt, and eth_getBlockByNumber payloads before and after the upgrade for the same fixtures, and investigate any structural change.\nVerify the two invariants explicitly. Confirm that no invalid or reverted transaction produces a credit, and that no valid deposit on any path is missed.\nConfirm the finality tags. Check that the finalized height advances and that you are not crediting on latest.\nUpgrade your own node to the required Nitro version per the Nitro support policy, then re-run Steps 3 through 6 on your production chain shortly after activation.\nRecord the result — node version, ArbOS version, date, and pass or fail, so the next upgrade has a baseline to diff against.\n\nFor Dedicated Blockchain ownersWe recommend waiting at least four weeks after an ArbOS release is live on Arbitrum One before upgrading a self-managed chain, so that any stability issues surface first.\nRelated resources\n\nArbOS software releases: overview\nGeth at the core\nRPC methods: Arbitrum compared with Ethereum\nNitro support policy\nHow is this guide?How to adopt the bridged USDC standard on your Arbitrum chainHow to implement Circle bridged USDC standard on Arbitrum chainThird-party Arbitrum chain infrastructure providersA high-level overview of third-party Arbitrum chain infrastructure providers for production-grade chains.","tokens":4119,"squid":"spider-01","role":"Chain Spider","at":1791344675203,"hash":"d6cb010f215a733d6762ca43ff9a0580852e8327"}
{"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":"spider-08","role":"Oracle Spider","at":1791344677698,"hash":"7cad0275203794047bfcf07a55659d94959c6f1d"}
{"url":"https://developer.arbitrum.io/launch-arbitrum-chain/quickstart","domain":"developer.arbitrum.io","title":"Quickstart","text":"QuickstartCreate an L3 chain with default settings and custom infrastructure.Request an updateRun an L3 rollup from scratchA simple A-Z guide to deploy and run a default-configured L3 rollup chain on Arbitrum Sepolia.Run testnet infrastructure on your first rollup (product-level testnet)Step-by-step guide to run your Arbitrum chain infrastructure as a production-level testnet with high availability.Deploy a production chain: an overviewLearn how to deploy and manage your Arbitrum chain with the Arbitrum chain SDK.How is this guide?Run an L3 rollup from scratchA simple A-Z guide to deploy and run a default-configured L3 rollup chain on Arbitrum Sepolia.","tokens":165,"squid":"spider-01","role":"Chain Spider","at":1791344685062,"hash":"e3aa91863e8ca679a3e503a71220798023ba0525"}
{"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":"spider-08","role":"Oracle Spider","at":1791344687949,"hash":"dab71b6e8f6870de2c70fe08aa852b29f0039873"}
{"url":"https://developers.metaplex.com/token-metadata/token-standard","domain":"developers.metaplex.com","title":"Token Standard | Token Metadata","text":"Token Metadata is a legacy program. It remains supported, but is not recommended for new projects. Use Core instead.As token usage has evolved on Solana, it has become clear that there are more types of tokens than simply \"fungible\" and \"non-fungible\" tokens.An example is something the community is calling a \"semi-fungible token\", an SPL token with a supply greater than 1 but which has typical NFT attributes such as an image and an attributes array in the JSON metadata.The consensus seems to be that these should be stored in wallets in the same view as standard NFTs, or in their own view but separate from \"standard\" fungible SPL tokens. These tokens are becoming popular in gaming contexts to support fungible items such as a kind of sword or a piece of wood, etc. but which are in a different league from typical fungible SPL tokens such as USDC.The Token Standard fieldIn order to support this particular use-case but also to make the standard broad enough to allow expansion to other token types in the future, we keep track of the token's fungibility using the Token Standard enum on the Metadata account. This field maps to a particular JSON standard and is used to objectively differentiate token types.This solves a pain point for third parties such as wallets which, before this field, had to apply inconsistent heuristics to determine what is and is not an \"NFT\".The Token Standard field can have the following values:0 / NonFungible: A non-fungible token with a Master Edition.1 / FungibleAsset (1): A token with metadata that can also have attributes, sometimes called Semi-Fungible.2 / Fungible (2): A token with simple metadata.3 / NonFungibleEdition (3): A non-fungible token with an Edition account (printed from a Master edition).4 / ProgrammableNonFungible (4): A special NonFungible token that is frozen at all times to enforce custom authorization rules.It is important to note that the Token Standard is set automatically by the Token Metadata program and cannot be manually updated. It uses the following logic to apply the correct standard:If the token has a Master Edition account, it is either a NonFungible or a ProgrammableNonFungible.If the token has an Edition account, it is a NonFungibleEdition.If the token has no (Master) Edition account (ensuring its supply can be > 1) and uses zero decimals places, it is a FungibleAsset.If the token has no (Master) Edition account (ensuring its supply can be > 1) and uses at least one decimal place, it is a Fungible.Each Token Standard type has its own JSON schema which is defined below.The Fungible StandardThese are simple SPL tokens with limited metadata and supply >= 0. Examples are USDC, GBTC and RAY.FieldTypeDescriptionnamestringName of the asset.symbolstringSymbol of the asset.descriptionstringDescription of the asset.imagestringURI pointing to the asset's logo.The Fungible Asset StandardThese are fungible tokens with more extensive metadata and supply >= 0. An example of this kind of token is something the community has been calling \"semi-fungible tokens\" often used to represent a fungible but attribute-heavy in-game item such as a sword or a piece of wood.FieldTypeDescriptionnamestringName of the asset.descriptionstringDescription of the asset.imagestringURI pointing to the asset's logo.animation_urlstringURI pointing to the asset's animation.external_urlstringURI pointing to an external URL defining the asset — e.g. the game's main site.attributesarrayArray of attributes defining the characteristics of the asset.trait_type (string): The type of attribute.value (string): The value for that attribute.propertiesobjectAdditional properties that define the asset.files (array): Additional files to include with the asset.uri (string): The file's URI.type (string): The file's type. E.g. image/png, video/mp4, etc.cdn (boolean, optional): Whether the file is served from a CDN.category (string): A media category for the asset. E.g. video, image, etc.The Non-Fungible StandardThese are the \"standard\" non-fungible tokens the community is already familiar with and have both a Metadata PDA and a Master Edition (or Edition) PDA. Examples of these are Solana Monkey Business, Stylish Studs and Thugbirdz.FieldTypeDescriptionnamestringName of the asset.descriptionstringDescription of the asset.imagestringURI pointing to the asset's logo.animation_urlstringURI pointing to the asset's animation.external_urlstringURI pointing to an external URL defining the asset — e.g. the game's main site.attributesarrayArray of attributes defining the characteristics of the asset.trait_type (string): The type of attribute.value (string): The value for that attribute.propertiesobjectAdditional properties that define the asset.files (array): Additional files to include with the asset.uri (string): The file's URI.type (string): The file's type. E.g. image/png, video/mp4, etc.cdn (boolean, optional): Whether the file is served from a CDN.category (string): A media category for the asset. E.g. video, image, etc.The Programmable Non-Fungible StandardThis standard is similar to the Non-Fungible standard above, except that the underlying token account is kept frozen at all times to ensure nobody can transfer, lock or burn Programmable NFTs without going through the Token Metadata program. This enables creators to define custom authorization rules for their NFTs such as enforcing secondary sales royalties.You can read more about Programmable NFTs here.FieldTypeDescriptionnamestringName of the asset.descriptionstringDescription of the asset.imagestringURI pointing to the asset's logo.animation_urlstringURI pointing to the asset's animation.external_urlstringURI pointing to an external URL defining the asset — e.g. the game's main site.attributesarrayArray of attributes defining the characteristics of the asset.trait_type (string): The type of attribute.value (string): The value for that attribute.propertiesobjectAdditional properties that define the asset.files (array): Additional files to include with the asset.uri (string): The file's URI.type (string): The file's type. E.g. image/png, video/mp4, etc.cdn (boolean, optional): Whether the file is served from a CDN.category (string): A media category for the asset. E.g. video, image, etc.","tokens":1563,"squid":"spider-10","role":"Tooling Spider","at":1791344691613,"hash":"da1daae1856202c620b7e4c13708bd52c85a79c1"}
{"url":"https://developer.arbitrum.io/launch-arbitrum-chain/operate","domain":"developer.arbitrum.io","title":"Operate your chain","text":"Operate your chainOperate your chain documentationRequest an updateCustomizable challenge periodLearn how to customize your Arbitrum chain's challenge periodBond and validator configurationsLearn how to configure your Arbitrum chain with a custom bond and validator configurationsBatch PosterLearn how to configure the batch poster.Configure assertion controlLearn how to configure assertion control.How to upgrade ArbOS on your Arbitrum chainLearn how to upgrade ArbOS on your Arbitrum chain.Enabling blob transactions for Arbitrum batch posterHow to configure your Arbitrum node to post EIP-4844 blob transactions to the parent chainHow to configure Delayed Inbox finalityLearn how to configure Delayed Inbox finality on your Arbitrum chain.Batch poster fee tuningLearn how to configure and tune fee-related parameters for batch posting, including blob transaction fees and gas price spike handling.BoLD for Arbitrum chainsLearn how to integrate BoLD with your Arbitrum chainConfigure smart contract size limitLearn how to configure the smart contract size limits on your Arbitrum chainHow is this guide?Migrate from another stackMigrate to Arbitrum chain from another stackArbOS upgradeLearn how to upgrade ArbOS on your Arbitrum chain.","tokens":310,"squid":"spider-01","role":"Chain Spider","at":1791344694367,"hash":"34ed9d18a746ca35cf44ecbe663c7bb8184ec99a"}
{"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":"spider-08","role":"Oracle Spider","at":1791344697747,"hash":"c01918a2d805bde2da5a7b8d765a4c5ab2b2f7c0"}
{"url":"https://akash.network/docs/api-documentation/sdk/","domain":"akash.network","title":"Akash SDK | Akash Network - Your Guide to Decentralized Cloud","text":"Akash SDK Deploy and manage Akash applications programmatically using our official SDKs in Go or JavaScript/TypeScript.\nBoth SDKs are generated from the same chain-sdk protobuf definitions and provide identical core functionality.\n\nAvailable SDKs\nGo SDK\nThe official Go SDK for Akash Network, generated from chain-sdk protobuf definitions.\n\nRepository: github.com/akash-network/chain-sdk\nPackage: pkg.akt.dev/go\nInstallation: See the installation guide\n\nJavaScript/TypeScript SDK\nThe official JavaScript/TypeScript SDK for Akash Network, generated from chain-sdk protobuf definitions.\n\nRepository: github.com/akash-network/chain-sdk\nPackage: @akashnetwork/chain-sdk\nInstallation: See the installation guide\n\nQuick Start\nGet started quickly with either SDK:\n\nInstallation - Install the SDK in Go or JavaScript/TypeScript\nQuick Start - Get started with your first deployment\nAuthZ & Fee Grants - Programmatic permission management\nAPI Reference - Complete API documentation\n\nCore Features\nBoth SDKs support:\n\nDeployment Management - Create, update, close deployments\nMarket Operations - View bids, create leases\nProvider Queries - Find and evaluate providers\nQuery Operations - Query deployments, leases, balances\nWallet Management - Sign transactions securely\nSDL Parsing - Parse and validate SDL files\nCertificate Management - Generate and manage certificates\nJWT Authentication - Authenticate with providers (TypeScript)\n\nChoose Your Language\nGo SDK\nPerfect for Go developers and high-performance applications.\nBest for:\n\nGo-based projects\nHigh-performance applications\nSystem-level integrations\nCLI tools and automation\n\nJavaScript/TypeScript SDK\nIdeal for web applications and Node.js projects.\nBest for:\n\nWeb applications\nNode.js projects\nTypeScript projects\nBrowser-based applications\nReact/Vue/Angular apps\n\nSDK Comparison\n\nFeatureGo SDKTypeScript SDKDeployment OperationsSupportedSupportedQuery OperationsSupportedSupportedTransaction SigningSupportedSupportedSDL ParsingSupportedSupportedCertificate ManagementSupportedSupportedJWT AuthenticationSupportedSupportedBrowser SupportNot applicableSupported (via Web SDK)Node.js SupportNot applicableSupportedProvider API ClientSupportedSupported\n\nNext Steps\n\nInstallation - Install the SDK\nQuick Start - Your first deployment\nAuthZ & Fee Grants - Programmatic permission management\nExamples - Real-world code examples\nAPI Reference - Complete API documentation\nSDL Reference - Stack Definition Language docs\n\nNeed Help?\n\nSDK Issues: GitHub Issues\nDiscord: discord.akash.network\nDocumentation: Browse the full docs\n\nEdit page on github\n Quickstart Installation","tokens":653,"squid":"spider-03","role":"Compute Spider","at":1791344701747,"hash":"23d787839549b41dcbc6cecce5a7ea51ffa9b845"}
{"url":"https://developer.arbitrum.io/launch-arbitrum-chain/operate/error-index","domain":"developer.arbitrum.io","title":"Common error messages","text":"Operate your chainCommon error messagesAn index of error and log messages emitted by Arbitrum chain infrastructure, mapping each message to the guide that explains its cause and resolution.Request an updateThis page indexes error and log messages emitted by Arbitrum chain infrastructure. Find your message below and follow the link for the cause and resolution.\nMessages are grouped by the component that emits them. If you do not know which component produced a message, use your browser's find-in-page to search for a distinctive fragment of it.\nThis page is an index, not a guideEach entry links to the guide that explains the message in full. This page deliberately carries no resolution steps of its own, so that it cannot fall out of step with those guides.\nLog levels in the linked guides are worth reading closely. Many messages are logged quietly at first. If they persist, they escalate to WARN or ERROR. A single WARN is usually noise. A sustained one that reaches ERROR is the real signal. To learn how that escalation works, see The escalation rule to remember.\nBatch poster\nMempool and balance\nMessageLikely causeWhere to lookPosting this transaction will exceed max mempool sizeNitro's own in-flight window (max-mempool-transactions) is full, usually because the parent chain is confirming slowlyMempool errorsErrExceedsMaxMempoolSize / error posting batchIn-flight transaction window full; parent chain confirming slowlyMempool errorslack of L1 balance prevents posting transaction with desired fee capParent chain wallet cannot cover the target max costMempool errorsa large batch posting backlog existsPosting is not keeping up with sequencingBacklog diagnosiserror fetching batch poster wallet balanceParent chain RPC hiccup; monitoring gap onlyMempool errors\nRetries, nonces, and sync\nMessageLikely causeWhere to lookFailed to re-send transactionNonce already consumed, stale storage, or underpriced replacementRetry errorsfailed to update nonce with queue empty; falling back to using a recent blockFinality data unavailable; safe because the queue is emptyNonce and syncFailed to get current nonceParent chain RPC; non-fatal, a previous nonce existsNonce and syncFailed to get latest nonceTransient RPC; the iteration backs offNonce and syncfailed to update tx poster balance / failed to update tx poster noncePeriodic state refresh failed; loop backs offNonce and syncDataPoster failed to send transactionMempool rejection or RPC issue; transaction stays queuedNonce and syncfailed to replace-by-fee transactionPer-nonce RBF error that escalates if it persistsNonce and syncDataPoster is avoiding creating a mempool nonce gapDeliberate safety; transaction is retriedParent chain bounds\nReverts and halting\nMessageLikely causeWhere to lookTransaction from batch poster revertedContract rejected the batch; halts posting on persistent storageReverts and haltingLarge gap between last seen and current block number, skipping check for revertsNode lag; reverts in the skipped window go undetectedReverts and haltingError checking batch revertsRevert check failed; benign when it contains not foundReverts and halting\nFees and pricing\nMessageLikely causeWhere to lookcan't meet data poster fee cap obligations with current target max costParent chain fees spiked above the escalation targetFees and pricingsubmitting transaction with GasFeeCap less than latest basefeePosting with a cap below current fees, expecting fees to fallFees and pricingunable to fetch suggestedTipCap from l1 clientMetric gap only, not a posting failureFees and pricing\nParent chain bounds and reorg\nMessageLikely causeWhere to lookDisabling batch posting due to batch being within reorg resistance marginExpected safety guard near the lower parent chain boundParent chain boundsdisabling L1 bound as batch posting message is close to the maximum delayBound overridden to avoid stalling near max-delayParent chain boundsnot posting more messages because block number or timestamp exceed L1 boundsNormal bounding behaviorParent chain boundserror getting max time variation on L1 bound block; falling back on latest blockParent chain node could not serve state at the bound blockParent chain boundsunknown L1 block bound config value; falling back on using finalizedInvalid l1-block-bound config valueParent chain bounds\nData availability\nMessageLikely causeWhere to lookDA writer failed, operator action requiredNon-fallback DA writer error; posting stopsData availability fallbackDA writer explicitly requested fallbackDA backend requested fallback; check provider healthData availability fallback\nCoordination, gas estimation, and startup\nMessageLikely causeWhere to lookError checking if we could acquire redis lockRedis connectivity; the poster tries anywayLock and coordinationNot posting batches right now because another batch poster has the lock or this node is behindNormal on backup postersLock and coordinationFailed to estimate gas for EIP-7623 checkThe probe Nitro uses to auto-detect EIP-7623 support failed; can occur on any parent chainLock and coordinationerror estimating gas for batchParent chain state lag or inbox not caught upLock and coordinationmax-size is deprecated; use max-calldata-batch-sizeDeprecated flag in useConfig and startupDisabling data poster storage, as parent chain appears to be an Arbitrum chain without a mempoolExpected when your parent chain is an Arbitrum chainConfig and startupmessagesPerBatch is somehow zeroDefensive guard; benign unless recurringConfig and startup\nValidator\nMessageLikely causeWhere to lookerror initializing staker: could not create assertion chain: no contract code at given addressReading at finalized before the Rollup deployment is finalized, or a stale rollup.rollupParent chain read consistencyASSERTION_NOT_EXISTUnsynced node, inconsistent parent chain RPC, or reorg exposureAssertion errorsfound incorrect assertion in watchtower mode (legacy staker)Local state disagrees with an onchain Assertion errorsDetected invalid assertion, but not configured to post a rival stake (BoLD staker)Local state disagrees with an onchain assertionAssertion errors\nMessages not listed here\nThis index covers Arbitrum chain infrastructure that you operate. For errors from other areas, start with the guide for that area:\n\nStylus contracts — build, deployment, activation, and runtime errors are covered in Common Stylus issues.\nRunning a node — sync and startup questions are covered in Node troubleshooting.\nBridging — deposit and withdrawal issues are covered in Bridge troubleshooting.\nHow is this guide?Batch poster recoveryLearn how the batch poster recovers state and the mechanisms that make recovery possible.Node Key Rotation GuideLearn how to rotate keys for the different roles in your Arbitrum chain.","tokens":1692,"squid":"spider-01","role":"Chain Spider","at":1791344704247,"hash":"f5bd064390c2d51d44895f6c40251ae2c2c6cd82"}
{"url":"https://forum.arbitrum.foundation/t/stip-round-1-voting-period-update/18725/10","domain":"forum.arbitrum.foundation","title":"STIP - Round 1: Voting Period Update - Archive / Short Term Incentives Program (STIP) Round 1 - Arbitrum","text":"The Arbitrum Foundation notified the Security Council on the need to perform a potential Emergency action. Following a review of the details and known risks, the Security Council decided to execute the upgrade and it was completed at 11:30 EST on 2nd October 2026.\nThis report provides an overview of the risks that required the Security Council Action:\n\nAdd a permissionless guard for the One-Step Proof of BoLD on Arbitrum One\n\nTemporarily pause activation of new Stylus contracts on Arbitrum One & Nova\n\nKey point: To date, known bugs for Stylus primarily impact chain liveness (e.g., denial of service attacks) and do not put any user funds at risk.\nWhy was this action taken\nLet’s take this opportunity to explain why action was taken on two separate issues concerning BoLD and Stylus.\nInstalling the guard for One-Step Proof of BoLD. Given the rise of AI-assisted attacks, we have implemented a precautionary approach that allows anyone to pause settlement of Arbitrum One on Ethereum if there are at least two conflicting answers that pass at the same level in which only one should be valid and pass. This is to halt a class of publicly verifiable and detectable attacks that exploit a bug in the one-step proof. If halted, Arbitrum One will continue to process as normal except that messages from Arbitrum One to Ethereum, such as withdrawals, that are not yet confirmed will have to wait. This provides time for the Security Council to deploy a fix for the bug and resume the rollup.\nPreventing activation of new Stylus contracts. AI-assisted tooling has led to an increasing number of sophisticated attacks on hand-crafted WASM programs that do not use the standard Stylus compiler toolchain. These programs are specifically designed to cause unexpected behaviors such as degrading the chain’s performance for all other users. To date, no attacks have been discovered that permits theft of user funds.\nNew ArbOS releases have patched several reported bugs and known attacks over the past few months, but out of an abundance of caution, we have decided to temporarily pause new activations of Stylus contracts. This was executed as an emergency action to prevent the deployment of new hand-crafted WASM programs that are not yet patched by the current version of ArbOS on the Arbitrum network.\nThe Arbitrum Foundation has informed the Security Council that they will work with the ArbitrumDAO to discuss next steps on the timeline and manner for enabling activation of new Stylus contracts. The Arbitrum community remains confident in the value of Stylus and want to preserve these use cases while taking preventative measures against Stylus-based attack vectors as AI-assisted attack tooling continues to evolve.\nImpact on builders and users\n\nNo new activations. New Stylus contracts cannot be activated during the pause including new versions of existing applications that require activation.\n\nExisting contracts are not paused. Already-active Stylus contracts continue to execute until expiration. This pause does not deactivate them.\n\nThe ArbOS 61 upgrade renewed all active contracts on Arbitrum One, so no currently active contract expires before August 20, 2027.\n\nRenewal via keepalive stays permissionless and is unaffected by the pause.\n\nReactivating an expired contract, or one that needs to be updated after a Stylus version change, is paused.\n\nUsing/calling any activated Stylus contract stays permissionless for all users and developers.\n\nNo impact on EVM. Solidity (EVM) contract deployment and execution are unaffected by this Security Council action.\n\nSecurity Council Actions\nThere are two actions bundled into a single payload:\n\nOne-Step Proof Guard. The L1UpgradeExecutor gives a new pause contract (PauseExecutor) the ability to pause and nothing else. The new pause contract grants the guard (OspSoundnessGuard) PAUSER_ROLE to use it. Anyone can show the guard two conflicting answers to the same step of an open challenge. If the one-step proof accepts both, the guard has the pause contract put Arbitrum One’s settlement to Ethereum on hold.\n\nStylus deactivation. The Security Council called ArbOwner.setWasmActivationGas(2^64 - 1) to raise the Stylus activation gas requirement on Arbitrum One and Nova. This makes activation prohibitively expensive and effectively disables new activations. This is a configuration change and does not require an ArbOS upgrade.\n\nThe Security Council signed the following transactions to update the configuration:\n\nEthereum: Ethereum Transaction Hash: 0x30732bb7d2... | Etherscan\nArbitrum One:\nArbitrum One Transaction Hash: 0x9eb3a4be3b... | Arbitrum One\nArbitrum Nova:\nArbitrum Nova transaction 0x79e0fed470dff7a22059b108e3f8f42eddd2b580a6771594060c4e7326c5f984 | Blockscout\n\nAn external audit was conducted for the OSP Guard contracts. No audit is required for the Stylus deactivation as it is only updating a single parameter in the ArbOS configuration.\n\n ArchiveShort Term Incentives Program (STIP) Round 1\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n Oct 2023\n\n 10 / 10\n\n Oct 2023\n\n Oct 2023\n\n post by Matt_StableLab on Oct 11, 2023\n\n Pinned on Oct 11, 2023\n\n post by Matt_StableLab on Oct 11, 2023\n\n post by DanThales on Oct 11, 2023\n\n post by ArbDefender on Oct 11, 2023\n\n post by Kapyrus on Oct 12, 2023\n\n post by Grandma on Oct 13, 2023\n\n post by Tenzent on Oct 13, 2023\n\n Tenzent\n\n Would also love some clarity on this for the protocols right at the cutoff. Perhaps a list with numbers would be good.\nI think the biggest learning and take away for next vote/program/extension/whatever is decided should be to move the system to Ranked Choice Voting.\nThis way projects can express votes in a much more sophisticated manner and no delegate is encouraged to not vote on a proposal. I also thought @cattin and the SEED LATAM community did an amazing job doing exactly this but manually, only voting for 50M of ARB worth grants. RCV would be a huge improvement to the way things are currently being done but Romang explained some of the other benefits better than I below:\n\n post by mint_cloud on Oct 16, 2023\n\n mint_cloud\n\n Matt_StableLab\n\n hi @Matt_StableLab , Theo from Matcha (matcha.xyz) / 0x (0x.org) here. We were preparing a proposal from our side and just discovered this.\nWould you recommend posting the proposal on the main Incentive Framework (Round 1) queue or use the Round 2 tag instead?\nThanks in advance\n\n post by chiragmahapatra on Oct 18, 2023\n\n chiragmahapatra\n\n Is there an update on if Round 2 will be happening?\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Extension of Arbitrum’s Short-Term Incentive Program\n\n Grants Discussions\n\n 99\n\n 12.9k\n\n Nov 2023\n\n How to Apply - Arbitrum Short Term Incentives Program\n\n Short Term Incentives Program (STIP) Round 1\n\n 41\n\n 7.8k\n\n Nov 2023\n\n STIP Grant Recipients Update\n\n Short Term Incentives Program (STIP) Round 1\n\n 0\n\n 3.8k\n\n Dec 2024\n\n Proposal to Backfund Successful STIP Proposals (Savvy DAO) [FINAL]\n\n Finalized AIPs\n\n proposal\n\n 119\n\n 18.2k\n\n Feb 2024\n\n Should large players side step the STIP program?\n\n Grants Discussions\n\n 10\n\n 890\n\n Oct 2023","tokens":1795,"squid":"spider-07","role":"Council Spider","at":1791344709040,"hash":"40024312a4854c375a9e1ceca359069599270443"}
{"url":"https://developer.arbitrum.io/launch-arbitrum-chain/operate/arbos-upgrade","domain":"developer.arbitrum.io","title":"How to upgrade ArbOS on your Arbitrum chain","text":"Operate your chainHow to upgrade ArbOS on your Arbitrum chainLearn how to upgrade ArbOS on your Arbitrum chain.Request an updateThis how-to provides step-by-step instructions for operators who want to upgrade ArbOS on their Arbitrum chain(s). Familiarity with ArbOS, Arbitrum chains, and chain ownership is expected. Note that Arbitrum chain owners have full discretion over when and whether to upgrade their ArbOS version.\nThe specific upgrade requirements for each ArbOS release are located under each reference page for that specific ArbOS release.\nStep 1: Update Nitro on nodes and validators\nRefer to the requirements for the targeted ArbOS release to identify the specific Nitro release that supports the ArbOS version you're upgrading to. For example, if your upgrade targets ArbOS 61, you'd use Nitro v3.11.3 (Docker image: offchainlabs/nitro-node:v3.11.3-beb2108) or higher. This is the Nitro stack version that must run on each of your Arbitrum chain’s nodes. A list of all Nitro releases can be found on Github.\nBegin by upgrading your node(s) to the specified Nitro version, then update each remaining Arbitrum chain node to match this version.\nNote that upgrading your node version must occur before the deadline established for the target ArbOS upgrade. Refer to the timestamp in the ArbOS upgrade schedule for a precise deadline.\nStep 2: Upgrade the WASM module root & your chain's Nitro contracts\nWhile every ArbOS upgrade will require an update to the , not every ArbOS upgrade will require an upgrade to the chain's nitro-contracts version.\nIf necessary, as defined in the release notes for each ArbOS release (example of ArbOS 61), you may need to deploy new versions of some (or all) of the Nitro contracts to the of your Arbitrum chain. These contracts include the rollup logic, bridging logic, fraud-proof contracts, and interfaces for interacting with Nitro precompiles. To verify the current version of your Nitro contracts, follow these instructions, replacing the inbox contract address and network name with those of your Arbitrum chain. This information will allow you to find the correct upgrade path for your Nitro contracts.\nTo update the WASM module root and deploy your chain's Nitro contracts to the parent chain for the most recent ArbOS release, you will need the following inputs (obtained from the requirements for the targeted ArbOS release):\n\nThe WASM module root, and if necessary,\nThe required nitro-contracts version\n\nOnce you have the WASM module root and have identified the required nitro-contracts version for the target ArbOS release, if any, please follow the instructions in this guide for specific actions based on the nitro-contracts version you are deploying. Note that each ArbOS release will require performing this step with a different WASM module root and may require a different version of nitro-contracts. The guide linked above will be kept updated with the instructions for each specific ArbOS release.\nThe WASM module root is a 32-byte hash created from the Merkelized Go replay binary and its dependencies. When ArbOS is upgraded, a new WASM module root because of changes to the (STF). Set the new WASM module root in the rollup contract on the parent chain. For example, the WASM module root for ArbOS 61 Elara is 0xc10cd7ec6acaf1c441a3f6bd0900ad20f15855ba775a96f1939118cbc629dc97 (consensus-v61).\nTo set the WASM module root manually (i.e., not using the above guide), use the Rollup proxy contract's setWasmModuleRoot method. Note that the upgrade executor contract on the parent chain is the designated owner of the Rollup contract, so the account needs to initiate a call to the upgrade executor contract in order to perform the upgrade. This call should include the correct calldata for setting the new WASM module root.\nBackward compatibilityWASM module roots are backward compatible, so upgrading them before an ArbOS version upgrade will not disrupt your chain's functionality.\nStep 3: Schedule the ArbOS version upgrade\nTo schedule an ArbOS version upgrade for your Arbitrum chain, follow this guide. In addition to the upgrade action contract address and the account address for the chain owner account, you will need the following inputs:\n\nnewVersion: Specify the ArbOS version you wish to upgrade to (e.g., 61).\ntimestamp: Set the exact UNIX timestamp at which you want your Arbitrum chain (Orbit) to transition to the new ArbOS version.\n\nIf you would prefer to do this manually, simply call the scheduleArbOSUpgrade function on the ArbOwner precompile of the Arbitrum chain(s) you're upgrading. Because this is an administrative action (similar to upgrading your Wasm module root), the chain owner account must call the target chain's upgrade executor contract with the appropriate calldata in order to invoke the scheduleArbOSUpgrade function of the ArbOwner precompile. This will schedule the ArbOS upgrade using the specified version and timestamp.\nImmediate upgradesTo upgrade immediately (without scheduling), set the timestamp to 0.\nObtaining the current ArbOS versionYou can obtain the current ArbOS version of your chain by calling ArbSys.ArbOSVersion(). Keep in mind that this function adds 55 to the current ArbOS version. For example, if your chain is running on ArbOS 10, calling this function will return 65.When scheduling the ArbOS upgrade through ArbOwner.scheduleArbOSUpgrade you must use the actual ArbOS version you're upgrading to. For example, if you're upgrading to ArbOS 61, you will pass 61 when calling this function.\nStep 4: Enable ArbOS specific configurations or feature flags (not always required)\nFor some ArbOS upgrades, such as ArbOS 61 Elara, there may be additional requirements or steps that need to be satisfied to ensure your Arbitrum chain can use all of the new features and improvements made available in that particular ArbOS release.\nIf the targeted ArbOS release has additional requirements, they will be listed on the reference pages for that the targeted ArbOS release. For example, you can find the additional requirements for upgrading to ArbOS 61 in the ArbOS 61 docs.\nCongratulations! You've upgraded your Arbitrum chain(s) to the specified ArbOS version.How is this guide?Operate your chainOperate your chain documentationBatch poster troubleshootingDiagnose and resolve common batch poster operational issues including mempool errors, balance management, backlog conditions, and retry failures.","tokens":1606,"squid":"spider-01","role":"Chain Spider","at":1791344714737,"hash":"49c320b18e71d695a73d9127ac4fbe6aa61c959c"}
{"url":"https://forum.arbitrum.foundation/t/how-to-apply-arbitrum-short-term-incentives-program/16545","domain":"forum.arbitrum.foundation","title":"How to Apply - Arbitrum Short Term Incentives Program - Archive / Short Term Incentives Program (STIP) Round 1 - Arbitrum","text":"The Arbitrum Foundation notified the Security Council on the need to perform a potential Emergency action. Following a review of the details and known risks, the Security Council decided to execute the upgrade and it was completed at 11:30 EST on 2nd October 2026.\nThis report provides an overview of the risks that required the Security Council Action:\n\nAdd a permissionless guard for the One-Step Proof of BoLD on Arbitrum One\n\nTemporarily pause activation of new Stylus contracts on Arbitrum One & Nova\n\nKey point: To date, known bugs for Stylus primarily impact chain liveness (e.g., denial of service attacks) and do not put any user funds at risk.\nWhy was this action taken\nLet’s take this opportunity to explain why action was taken on two separate issues concerning BoLD and Stylus.\nInstalling the guard for One-Step Proof of BoLD. Given the rise of AI-assisted attacks, we have implemented a precautionary approach that allows anyone to pause settlement of Arbitrum One on Ethereum if there are at least two conflicting answers that pass at the same level in which only one should be valid and pass. This is to halt a class of publicly verifiable and detectable attacks that exploit a bug in the one-step proof. If halted, Arbitrum One will continue to process as normal except that messages from Arbitrum One to Ethereum, such as withdrawals, that are not yet confirmed will have to wait. This provides time for the Security Council to deploy a fix for the bug and resume the rollup.\nPreventing activation of new Stylus contracts. AI-assisted tooling has led to an increasing number of sophisticated attacks on hand-crafted WASM programs that do not use the standard Stylus compiler toolchain. These programs are specifically designed to cause unexpected behaviors such as degrading the chain’s performance for all other users. To date, no attacks have been discovered that permits theft of user funds.\nNew ArbOS releases have patched several reported bugs and known attacks over the past few months, but out of an abundance of caution, we have decided to temporarily pause new activations of Stylus contracts. This was executed as an emergency action to prevent the deployment of new hand-crafted WASM programs that are not yet patched by the current version of ArbOS on the Arbitrum network.\nThe Arbitrum Foundation has informed the Security Council that they will work with the ArbitrumDAO to discuss next steps on the timeline and manner for enabling activation of new Stylus contracts. The Arbitrum community remains confident in the value of Stylus and want to preserve these use cases while taking preventative measures against Stylus-based attack vectors as AI-assisted attack tooling continues to evolve.\nImpact on builders and users\n\nNo new activations. New Stylus contracts cannot be activated during the pause including new versions of existing applications that require activation.\n\nExisting contracts are not paused. Already-active Stylus contracts continue to execute until expiration. This pause does not deactivate them.\n\nThe ArbOS 61 upgrade renewed all active contracts on Arbitrum One, so no currently active contract expires before August 20, 2027.\n\nRenewal via keepalive stays permissionless and is unaffected by the pause.\n\nReactivating an expired contract, or one that needs to be updated after a Stylus version change, is paused.\n\nUsing/calling any activated Stylus contract stays permissionless for all users and developers.\n\nNo impact on EVM. Solidity (EVM) contract deployment and execution are unaffected by this Security Council action.\n\nSecurity Council Actions\nThere are two actions bundled into a single payload:\n\nOne-Step Proof Guard. The L1UpgradeExecutor gives a new pause contract (PauseExecutor) the ability to pause and nothing else. The new pause contract grants the guard (OspSoundnessGuard) PAUSER_ROLE to use it. Anyone can show the guard two conflicting answers to the same step of an open challenge. If the one-step proof accepts both, the guard has the pause contract put Arbitrum One’s settlement to Ethereum on hold.\n\nStylus deactivation. The Security Council called ArbOwner.setWasmActivationGas(2^64 - 1) to raise the Stylus activation gas requirement on Arbitrum One and Nova. This makes activation prohibitively expensive and effectively disables new activations. This is a configuration change and does not require an ArbOS upgrade.\n\nThe Security Council signed the following transactions to update the configuration:\n\nEthereum: Ethereum Transaction Hash: 0x30732bb7d2... | Etherscan\nArbitrum One:\nArbitrum One Transaction Hash: 0x9eb3a4be3b... | Arbitrum One\nArbitrum Nova:\nArbitrum Nova transaction 0x79e0fed470dff7a22059b108e3f8f42eddd2b580a6771594060c4e7326c5f984 | Blockscout\n\nAn external audit was conducted for the OSP Guard contracts. No audit is required for the Stylus deactivation as it is only updating a single parameter in the ArbOS configuration.\n\n How to Apply - Arbitrum Short Term Incentives Program \n\n ArchiveShort Term Incentives Program (STIP) Round 1\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Sep 2023\n\n 1 / 43\n\n Sep 2023\n\n Nov 2023\n\n post by tnorm on Sep 20, 2023\n\n tnorm\n\n *Note: This program follows two tracks as outlined in the Incentive Framework Category post. The continuation of this program and any grants approved by the Arbitrum DAO are dependent upon the successful passage of AIP 9.\nWhat is the Arbitrum Short Term Incentives Program?\nThe Arbitrum Short-Term Incentive Program is a one-time, community-created initiative to distribute up to 50 million ARB from the DAO treasury to active protocols on Arbitrum. The goals are to accelerate ecosystem growth, experiment with grant distribution models, generate data to inform future programs, and uncover new strategies to drive activity on the network. It spans two voting rounds and provides incentives to eligible programs designed to fund incentives through January 31, 2024.\nIt is expected that all funds distributed by this program will be used by the end of January 31, 2024. Participating grantees will be expected to self report data, dashboards, and summarize grant performance on an ongoing basis. Successful applicants will receive funding distributions biweekly via Hedgey streams.\nGrantees must comply with spending guidelines, data reporting, and community standards or risk having their stream halted by the multisig.\nHow to Apply For Funding?\nThe Arbitrum Short-Term Incentive Program will accept applications over 2 consecutive proposal Application Rounds.\nTo apply, projects can follow the following steps:\n\nReview the Official Short Term Incentives Program proposal here.\n\nDraft a proposal for your project using the Application Template.\n\nPublish your proposal in the Incentive Framework category for feedback from delegates with your title formatted as: [Project Name] [DRAFT] [STIP - Round 1].\n\nFollowing the application, delegates will have one week to review applications. During this week, applicants may digest critiques and adjust their proposals accordingly.\n\nOnce feedback has been incorporated, projects will need to change their title from [DRAFT] to [FINAL] by the deadline: October 4, 2023 11:59 PM EST. At that time, all proposals with the following formatted titles will be migrated to Snapshot to vote. The correct format for a proposal ready to move to vote looks like this: [Project Name] [FINAL] [STIP - Round 1].\n\nVoting will occur on Arbitrum Snapshot. Once voting commences, the Arbitrum Foundation will reach out with steps to KYC.\n\nOnce successful votes have been confirmed, the STIP-ARB Multisig will begin the distribution of funds.\n\nWhat is the Application Timeline?\nThis program is designed to fund incentive programs running from October 2023 through the end of January 31, 2024. While there is no hard deadline on the end of incentive programs, funds are expected to be distributed as they are received, and programs should aim to end before the end of the incentivization period on Jan. 31, 2024.\nThe program will comprise two application rounds. With the first application round commencing September 20, 2023.\nRound 1:\n\nApplication Date Starts: September 20, 2023 12:00 AM EST\n\nApplication Deadline: September 27, 2023 11:59 PM EST\n\nReview Period Starts: September 28, 2023 12:00 AM EST\n\nReview Period Deadline: October 4, 2023 11:59 PM EST\n\nVoting Period Starts: October 5, 2023\n\nVoting Period Deadline: October 12, 2023\n\nTowards the end of the review period, a community call will be organized to help facilitate discussion between grantees and delegates, giving each grantee a short time to respond and field questions from the community.\nRound 2\nRound 2 will begin directly after the end of the final voting period of Round 1. Further details will be provided in the coming weeks.\nWhat are the Application Requirements?\nOnce program’s are live, protocols are responsible for upholding their end of the grant program agreement by distributing the funds as described in their approved strategy and providing dashboards for their programs based on the descriptions below.\nEligibility Requirements:\n\nGrantees are required to keep distributions in ARB without converting to other assets.\n\nGrantees must not farm their own incentive programs.\n\nGrantees must outline a spending plan, provide a pro forma, and state the grant’s objective.\n\nGrantees must commit to providing data on distributions, all ARB spending transactions, and key metrics like daily TVL, transactions, volumes, unique addresses, and transaction fees. This data should cover 30 days before, during, and after the Incentivization period, and be presented preferably in a Dune Spell/dashboard. Grantees must agree to share all contract addresses being used to distribute incentive rewards.\n\nGrantees must disclose the contracts being incentivized and denote any external contracts being incentivized as part of the program.\n\nGrantees can only incentivize contracts on the Arbitrum Network.\n\nGrants are not to be used in DAO governance (Ie, self-delegating funds or holding funds in a wallet delegated).\n\nGrantees are expected to not encourage or partake in disruptive behaviors that may delay the funding process such as intentionally directing individuals to or directly spamming the forum to obfuscate true community sentiment’\n\nGrantees must agree to completing KYC verification the Arbitrum Foundation in order to receive funds.\n\nGrantees must apply using the approved program application template 39.\n\nExceptions may be made only at delegate discretion for non-applicable points (For example, if TVL is irrelevant for a protocol’s dashboard, etc.). Any exceptions must be explicitly demonstrable to the DAO in the protocol’s application.\nWhat Are the Additional Program Deliverables?\nIn addition to upholding accordance with the aforementioned requirements, protocols are required to uphold their commitment to dashboards and reporting. The expectation of participating grantees is two-fold:\n\nTo create a dashboard by December 15, 2023 showing daily TVL, transactions, volume, addresses, and network fees covering 30 days before/during/after incentivization. Grantees are encouraged to expand upon these basic requirements, and the commitment to data availability and transparency shown in this program should play a key role in the application process of future programs. We recommend that prospective applicants create the infrastructure/data in place so dashboards are available throughout the incentive program.\n\nProvide bi-weekly status updates on the program posted onto the Arbitrum Forum on the application thread. These updates should report on distributions made in the preceding two week period as well as articulate any relevant refinement or adjustment to the program’s strategy.\n\nFrequently Asked Questions\nWhat happens if the budget is exceeded?\nWe do not expect applications to exceed the funding budget of 50M ARB. However, if requested grants do exceed the allocated budget, funding will be allocated based on the amount of votes in favor of a proposal, and secondly (if there are any exact ties) on a first-come, first-serve basis dependent upon the time the proposal was submitted to the Arbitrum Forum.\nIn the event that the budget is exceeded, the DAO may choose to unlock further funds for a third round, or backfund successful incentive proposals.\nI noticed the grant categories listed in the original proposal, are projects that aren’t DeFi allowed to apply?\nThe grant categories listed in the program overview are meant only as guidelines for delegates and applications to use as reference points when applying. Any protocol that meets the eligibility requirements described above may apply for a grant at the discretion of the community and delegate review.\nCan I Edit my Application Once it is Posted?\nYes. All grant applications may be adjusted throughout the review period, up until the review period deadline. Once a proposal is ready to be finalized, please format your post to the correct format explained in step 5.\nHow does the program determine whether to halt funding streams?\nFunds can be stopped by the STIP-ARB Multisig with a 5/9 consensus. Funds will be stopped in the event of negligent actions in violation of the previously defined grant requirements. If halted, the multisig must publish the justification of its decision on the Arbitrum Forum. The stream can restart either through a Snapshot Veto or if the multisig decides the grantee has corrected their actions and it’s appropriate to continue.\nCan I use grant funding for operational costs?\nFunds are to be kept in ARB and used to incentive Arbitrum contracts. This funding is not meant support development or operational costs.\n\n Arbitrum's Short-Term Incentive Program (Arbitrum Improvement Proposal)\n\n [Prime Protocol] [FINAL] [STIP - Round 1]\n\n [Quadrat] [FINAL] [STIP - Round 1]\n\n #6 Arbitrum Open Governance Call (20.09.2023)\n\n RFP - Abitrum Short-Term Incentive Program (STIP) Data Monitoring and Reporting\n\n 7\n\n 4\n\n 3\n\n 3\n\n 3\n\n read \n\n 6\n min\n\n post by JoJo on Sep 20, 2023\n\n post by tnorm on Sep 20, 2023\n\n post by frondoto on Sep 20, 2023\n\n post by stonecoldpat on Sep 21, 2023\n\n Pinned on Sep 21, 2023\n\n post by strategicreserve on Sep 22, 2023\n\n post by medocons on Sep 23, 2023\n\n post by jerame20 on Sep 24, 2023\n\n post by medocons on Sep 24, 2023\n\n post by CokeRat on Sep 25, 2023\n\n post by PedroNegron on Sep 27, 2023\n\n post by moon on Sep 28, 2023\n\n post by AlexLumley on Sep 28, 2023\n\n post by jerame20 on Sep 28, 2023\n\n post by AlexLumley on Sep 28, 2023\n\n post by jerame20 on Sep 28, 2023\n\n post by AlexLumley on Sep 28, 2023\n\n post by ALAYA on Sep 29, 2023\n\n post by matt_kepler on Sep 30, 2023\n\n Load more posts below","tokens":3683,"squid":"spider-07","role":"Council Spider","at":1791344719179,"hash":"e3fa8906517e4ffb6c22057ccb9d046d0bd1de80"}
{"url":"https://akash.network/docs/api-documentation/sdk/installation/","domain":"akash.network","title":"SDK Installation | Akash Network - Your Guide to Decentralized Cloud","text":"SDK Installation Install the Akash SDK in your preferred language.\nBoth SDKs are generated from the chain-sdk repository and provide the same core functionality.\n\nPrerequisites\nGo SDK\n\nGo 1.25.0 or higher\nBasic Go module knowledge\n\nTypeScript SDK\n\nNode.js 22.14.0 or higher\nnpm, yarn, or pnpm\n\nInstallation\n# Install the Go SDK from chain-sdk\n# Using Go modules (recommended)\ngo get pkg.akt.dev/go\n\n# The SDK includes multiple packages:\n# - pkg.akt.dev/go # Core types and clients\n# - pkg.akt.dev/go/sdl # SDL parsing and validation\n# - pkg.akt.dev/go/cli # CLI utilities\n\nSDK Details\nGo SDK\nThe official Go SDK for Akash Network, generated from chain-sdk protobuf definitions.\n\nRepository: github.com/akash-network/chain-sdk\nPackage: pkg.akt.dev/go\nSource: chain-sdk/go directory\nGo Version: 1.25.0+\nIncludes:\n\nCore blockchain types and clients (pkg.akt.dev/go)\nSDL parsing and validation (pkg.akt.dev/go/sdl)\nCLI utilities (pkg.akt.dev/go/cli)\n\nJavaScript/TypeScript SDK\nThe official JavaScript/TypeScript SDK for Akash Network, generated from chain-sdk protobuf definitions.\n\nRepository: github.com/akash-network/chain-sdk\nPackage: @akashnetwork/chain-sdk\nSource: chain-sdk/ts directory\nNode Version: 22.14.0+\nSupports: Node.js and browser environments\nDependencies: Uses CosmJS for wallet and signing operations\n\nRelated Resources\n\nQuick Start - Get started with your first deployment\nExamples - Real-world code examples\nAPI Reference - Complete API documentation\n\nEdit page on github\n Quickstart Quick Start","tokens":378,"squid":"spider-03","role":"Compute Spider","at":1791344722110,"hash":"86d4ac6019c2f73d41b06c7664945fa78c580e19"}
{"url":"https://developer.arbitrum.io/launch-arbitrum-chain/operate/bold-upgrade-playbook","domain":"developer.arbitrum.io","title":"BoLD upgrade playbook for multisig and security council chains","text":"Operate your chainBoLD upgrade playbook for multisig and security council chainsSequence a BoLD upgrade when execution requires multisig or security council signatures that take days to collect, without freezing your validators for the entire window.Request an updateThis guide covers the operational sequencing of a upgrade for chains where the execute call is performed by a multisig or a security council rather than a single key. It continues from the step-by-step upgrade in BoLD for Arbitrum chains and assumes you have read it. Concepts, the full parameter table, and the base upgrade steps are not repeated here.\nIf your chain owner is a single key that can send the upgrade immediately, you do not need this guide—follow the base guide instead.\nThe problem this guide solves\nThe base guide sequence contains two steps that appear to conflict when a security council is involved:\n\nStep 4 runs bold-populate-lookup, which reads the last confirmed so the new Rollup contract can be initialized from it.\nStep 5 executes the upgrade, and reverts if a new has been confirmed since Step 4.\n\nThe base guide therefore recommends stopping all at Step 4 to prevent a new from blocking Step 5.\nFor a production chain, Step 5 is not a you can send on demand. Signers must review a simulation before signing, and collecting a security council's signatures can take days. Read literally, the base sequence implies you must keep every validator stopped for that entire period—a multi-day halt to assertion posting and confirmation on a production chain, which is unacceptable and carries its own risks.\nYou do not have to do this. The following sections explain why.\nWhy the signed payload is independent of the assertion\nThe upgrade action's entry point takes no assertion data:\nfunction perform(address[] memory validators) external\nThe genesis state for the new Rollup contract is not passed in as an argument. Instead, perform reads it at execution time from a separate helper contract, StateHashPreImageLookup:\nbytes32 latestConfirmedStateHash =\n OLD_ROLLUP.getNode(OLD_ROLLUP.latestConfirmed()).stateHash;\n(ExecutionState memory genesisExecState, uint256 inboxMaxCount) =\n PREIMAGE_LOOKUP.get(latestConfirmedStateHash);\nThat helper stores its entries in a mapping keyed by state hash, and its setter is permissionless with no access control beyond a hash-consistency check:\nmapping(bytes32 => bytes) internal preImages;\n\nfunction set(bytes32 h, ExecutionState calldata executionState, uint256 inboxMaxCount) public {\n require(h == stateHash(executionState, inboxMaxCount), \"Invalid hash\");\n preImages[h] = abi.encode(executionState, inboxMaxCount);\n emit HashSet(h, executionState, inboxMaxCount);\n}\nSee BOLDUpgradeAction.sol for both contracts.\nThree consequences follow, and together they resolve the conflict:\n\nThe calldata your signers approve never changes. What the council signs is an execute call wrapping perform(validators). Because no assertion data appears in that calldata, running bold-populate-lookup again does not alter the payload, and therefore does not invalidate signatures already collected.\nPopulating the lookup is additive, not destructive. set writes to a new mapping key per state hash. Repeated runs accumulate entries; they do not overwrite or clear earlier ones. A lookup entry for an assertion that has since been superseded is harmless.\nAnyone can populate the lookup at any time. set is public and requires no privileged key, so refreshing the lookup is not itself a governance action and needs no signatures.\n\nWhat perform actually requires is narrower than the base guide implies. Confirming another assertion after Step 4 is fine—what matters is that the lookup must contain an entry for whichever assertion is latest-confirmed at the moment of execution.\nWarningConfirm this sequence with the Offchain Labs team before executing it on a production chain. The reasoning above is drawn from the contract source, but a mainnet BoLD upgrade is a high-consequence, one-way operation, and your chain may use customized contracts for which it does not hold.\nRecommended sequence\nThis sequence keeps validators running throughout signature collection.\nStep 1: Prepare and deploy the upgrade action\nFollow Steps 0 through 3 of the base upgrade guide without changes. Validators keep running. This deploys the action contract with your chain's configuration and fixes the address that the execute payload will target.\nStep 2: Populate the lookup once, to produce the payload and simulation\nRun bold-populate-lookup and then bold-local-execute with a non-owner key, which prints the payload rather than sending it:\n$ L1_PRIV_KEY=xxx yarn script:bold-populate-lookup --network {mainnet|arb1|nova|base|sepolia|arbSepolia}\n$ L1_PRIV_KEY=xxx yarn script:bold-local-execute --network {mainnet|arb1|nova|base|sepolia|arbSepolia}\nUse the printed execute(...) calldata as the payload for your multisig transaction. Use the populated state to produce the simulation your signers will review.\nStep 3: Collect signatures with validators running\nCirculate the payload and simulation. Validators continue posting and confirming assertions normally during this period. Assertions confirmed now will not match the lookup entry from Step 2, which is expected and is corrected in the next step.\nNoteDistinguish two things that behave differently as the chain advances. A signature covers the transaction calldata, which is fixed, so it stays valid. A simulation reflects onchain state at the time it was produced, so it goes stale as new assertions confirm. If your signing process requires signers to review a fresh simulation, re-run the simulation against current state and re-populate the lookup beforehand—but you do not need to re-collect signatures that were already given for the same calldata.\nStep 4: Re-populate the lookup immediately before execution\nOnce you have the signatures and are ready to execute, run bold-populate-lookup again:\n$ L1_PRIV_KEY=xxx yarn script:bold-populate-lookup --network {mainnet|arb1|nova|base|sepolia|arbSepolia}\nThis writes an entry for the assertion that is latest-confirmed right now. Any key can send it.\nNoteThe script finds the last confirmed assertion by searching for its NodeCreated event in the most recent 100,000 parent-chain blocks. If your chain confirms assertions infrequently enough that the event falls outside that window, the script cannot find it. Take this into account before pausing assertion creation for any length of time.\nStep 5: Execute the upgrade\nSubmit the signed multisig transaction. Then continue with Steps 6 and 7 of the base guide to update node configuration, restart nodes, and monitor the new Rollup contract.\nClosing the residual race\nOne narrow race remains: an assertion could be confirmed in the interval between your final bold-populate-lookup in Step 4 and your execute transaction landing. If that happens, perform looks up a state hash that has no entry and the transaction reverts with:\nHash not yet set\nThis is a benign, recoverable failure. The upgrade did not partially apply—it reverted. Choose whichever mitigation fits your operations, in rough order of preference:\n\nSubmit both in one bundle or block. If your tooling can batch, sending set and execute together removes the gap entirely. This is the cleanest option and requires no validator downtime at all.\nRetry. Because set is permissionless and inexpensive, re-running Step 4 and resubmitting is often the pragmatic answer, particularly on chains that confirm assertions hours apart.\nFreeze validators briefly, at execution time only. Stop assertion-confirming validators shortly before you submit, rather than for the whole signature window. This is the base guide's recommendation, narrowed from days to minutes. If you choose this, read the following section first, because a freeze has a side effect on the validator allowlist.\n\nKeeping validation permissioned across the upgrade\nTwo configuration parameters govern whether your chain stays permissioned. They are often assumed to compete; they do not, and setting only the first is not sufficient.\nParameterRoledisableValidatorWhitelistWhen false (the recommended value), only addresses in the validators[] array may post assertions.validatorAfkBlocksA liveness escape hatch. If assertions stop being confirmed for this many parent-chain blocks, anyone can permissionlessly disable the allowlist, regardless of disableValidatorWhitelist.\nvalidatorAfkBlocks is not overridden by disableValidatorWhitelist. It is the mechanism that removes the allowlist, and it applies precisely when the allowlist is in force. The parameter table's note that validatorAfkBlocks is ignored when disableValidatorWhitelist is true is a statement that the escape hatch is redundant on a chain that is already permissionless—not that setting disableValidatorWhitelist to false protects you from it.\nThis matters directly to the upgrade, because any validator freeze is a period of assertion inactivity and counts toward the window. It is the main reason not to hold a multi-day freeze while collecting signatures.\nTo keep validation permissioned:\n\nSet disableValidatorWhitelist to false and populate validators[].\nSet validatorAfkBlocks to 0, which disables the escape hatch entirely. This is preferable to setting an artificially large value, which achieves the same intent less clearly and still leaves a finite window.\nIf you keep the escape hatch enabled, alert on assertion inactivity well before the window elapses. See the validator section of Monitoring tools and considerations for the metrics to watch.\n\nWarningDisabling the escape hatch with validatorAfkBlocks: 0 is a deliberate trade-off. It removes the protection that lets a chain recover permissionlessly if every allowlisted validator becomes unavailable. Make this choice knowingly, and pair it with monitoring and an on-call rotation for your validator set.\nTo weigh permissioned against , see BoLD for Arbitrum chains. It covers bond sizing and resource exhaustion risk.\nPreparing the bond token\nBoLD changes what validators bond with. The new bond token must be in place before the upgrade, not after.\nBoLD requires an ERC-20 bond token. In the BoLD Rollup contract, bonding runs entirely through ERC-20 transfers:\nfunction newStake(uint256 tokenAmount, address _withdrawalAddress) external whenNotPaused\n\nfunction receiveTokens(uint256 tokenAmount) private {\n IERC20(stakeToken).safeTransferFrom(msg.sender, address(this), tokenAmount);\n}\nNo bonding function in the BoLD RollupUserLogic is payable, so there is no native-currency path.\nWhether this is a migration for your chain depends on which pre-BoLD variant you are upgrading from. Legacy nitro-contracts shipped two Rollup user logic contracts, and your chain uses exactly one of them:\nPre-BoLD contractBondingEffect of the upgradeRollupUserLogicNative currency, via payable functions calling _newStake(msg.value)The bond asset changes. By default the node handles this automatically: it wraps native currency into WETH (--node.bold.auto-deposit) and approves it for bonding (--node.bold.auto-increase-allowance), so validator wallets only need sufficient native currency. Manual acquisition and approval are only needed if these flags are set to false, or if the stakeToken is not WETH-compatible (auto-deposit cannot acquire other tokens).ERC20RollupUserLogicAn ERC-20 token alreadyThe bond asset does not necessarily change. Confirm whether your configured stakeToken is staying the same.\nDetermine which one your chain runs before you prepare validators. Do not assume the native-currency case, even though it is the more common one.\nWhy operators think BoLD chains bond in ETHOn Arbitrum One and Arbitrum Nova the stakeToken is WETH, the ERC-20 wrapper around ETH. Explorers and dashboards often display this as ETH, which makes it look as though BoLD supports native bonding. It does not—the contract holds WETH. If you are checking your own chain's configuration, read stakeToken from the Rollup contract rather than relying on a display label.\nBefore you execute the upgrade:\n\nConfirm the stakeToken address in your upgrade configuration is a compliant ERC-20 on the parent chain. WETH is the recommended choice, and Offchain Labs does not recommend custom tokens as the bond asset.\nEnsure each validator wallet holds enough of that token to meet stakeAmt, in addition to parent-chain native currency for gas. With the default auto-deposit flags and a WETH-compatible stakeToken, native currency alone is enough — the node wraps and approves it automatically.\nPlan for first-time bonding on the new contract. Validators bond only once, but existing bonds do not carry over from the old Rollup contract, so every validator must bond again after the upgrade.\n\nFor guidance on choosing stakeToken and stakeAmt values, see Bond and validator configurations and Economics of disputes.\nAfter the upgrade\nOnce the upgrade executes, watch for AssertionCreated and AssertionConfirmed events on the new Rollup contract, as described in the base guide. If assertions do not appear, or validators fail to start or bond, see Validator troubleshooting.How is this guide?Batch poster troubleshootingDiagnose and resolve common batch poster operational issues including mempool errors, balance management, backlog conditions, and retry failures.Batch poster recoveryLearn how the batch poster recovers state and the mechanisms that make recovery possible.","tokens":3368,"squid":"spider-01","role":"Chain Spider","at":1791344724787,"hash":"607ccdb4c74e15b34310e6333b54e97177713442"}
{"url":"https://akash.network/docs/getting-started/choosing-your-console/","domain":"akash.network","title":"Choosing Your Console | Akash Network - Your Guide to Decentralized Cloud","text":"Choosing Your Console Akash ships two web apps for deploying. Pick the one whose key-custody model matches what you want.\n\nAkash Console (managed) ↗Console Air (self-custody) ↗WalletNot requiredBring your own (Keplr-compatible)BillingCredit cardPay directly in AKT/ACTHostingHosted at console.akash.networkSelf-hostable; you run itBest forBeginners, SaaS users, anyone who wants AWS-style deploys without cryptoCrypto-native users who want to own their keys end-to-endOpenconsole.akash.network ↗github.com/akash-network/console-air ↗\nPick by audience\nDo you want to hold your own keys?\n\nNo → Akash Console. Sign up with your email and start deploying; add a card when you want to go past the trial. Begin with the Quick Start.\nYes → Console Air. Clone the repo, run it locally, connect your wallet. New here? Walk through your first deploy in Deploy with Console Air. Already have deployments on console.akash.network? Follow the migration guide.\n\nFor programmatic access — CLI, SDK, REST API — see the API Documentation.\nWhat Console Air looks like\nA wallet-connected deploy in three frames — same UI as the legacy self-custody flow, now living in Console Air:\n\nConnected — your Akash address and balances show in the top right.\n\nMint ACT from AKT — Console Air’s escrow currency for deployments.\n\nPick a provider bid and sign the lease in your wallet.\nFor the full step-by-step, see Deploy with Console Air.\nBackground\nThe split is explained in the Console Air announcement and the design rationale in AEP-84. \nEdit page on github\n What is Akash? Console Onboarding","tokens":392,"squid":"spider-03","role":"Compute Spider","at":1791344731974,"hash":"11d29db6bfbd81b874836dfda2bd6e21c5e28905"}
{"url":"https://forum.arbitrum.foundation/t/how-to-apply-arbitrum-short-term-incentives-program/16545/47","domain":"forum.arbitrum.foundation","title":"How to Apply - Arbitrum Short Term Incentives Program - Archive / Short Term Incentives Program (STIP) Round 1 - Arbitrum","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 7\n\n 4\n\n 3\n\n 3\n\n 3\n\n read \n\n 6\n min\n\n Sep 2023\n\n 43 / 43\n\n Nov 2023\n\n Nov 2023\n\n Load more posts above\n\n post by ALAYA on Oct 2, 2023\n\n ALAYA\n\n tnorm\n\n I can’t edit the topic as well. So it means that just waiting for the system allows for uniform modifications？\n\n post by cliffton.eth on Oct 2, 2023\n\n cliffton.eth\n\n tnorm\n\n Hey @tnorm , @Matt_StableLab , everyone, you should be able to edit the topics now.\n\n post by ALAYA on Oct 2, 2023\n\n ALAYA\n\n I still can’t edit the title. Have you edit it successful?\n\n post by sahijeevan on Oct 3, 2023\n\n sahijeevan\n\n in full motion \n\n post by ALAYA on Oct 4, 2023\n\n ALAYA\n\n @Matt_StableLab\nHi, I just wanna make sure of the steps and rules about voting.\n\nWill the final submission be migrated to Snapshot to vote by the moderator or by myself?\nAre there any other details about voting? like what conditions users need to meet to vote, etc.\nThank you!\n\n post by GUMbo.Slice on Oct 5, 2023\n\n GUMbo.Slice\n\n jerame20\n\n @jerame20 thank u sir\na true legendary hero\n\n post by ArbDefender on Oct 5, 2023\n\n ArbDefender\n\n ALAYA\n\n Everyone can vote on Snapshot!!\nAnd there are no conditions on voting, you just for yes or no for that project or abstain.\n\n post by GUMbo.Slice on Oct 5, 2023\n\n GUMbo.Slice\n\n AlexLumley\n\n That right , imo in web9.9 for the patch update.\nwith nerf and new perk.\n\n post by ALAYA on Oct 5, 2023\n\n ALAYA\n\n ArbDefender\n\n I can’t find any voting proposal in Snapshot so far and if I am in the wrong address for voting could share it with me? Thank you!\n\n post by GUMbo.Slice on Oct 5, 2023\n\n GUMbo.Slice\n\n sahijeevan\n\n Preciate tought , thank you\n\n post by medocons on Oct 5, 2023\n\n medocons\n\n ALAYA\n\n Voting haven’t started, yet.\n\n post by ALAYA on Oct 5, 2023\n\n ALAYA\n\n Thank you so much, sir \n\n post by InspexCo on Oct 6, 2023\n\n InspexCo\n\n We have created a dashboard to track live voting of STIP proposals on Arbitrum Foundation\nhere: https://link.inspex.co/arbitrum-grants-voting-dashboard \nWe are also planning to create a comprehensive dashboard to track and monitor all the grant distributions for all successful applicants. So stay tuned for that! If there is any specific data you would like to see please let us know and we will incorporate them.\n\n post by Diamond_Protocol on Oct 9, 2023\n\n Diamond_Protocol\n\n Hi, when will round 2 start?\n\n 11 days later\n\n post by supercoolkay on Oct 20, 2023\n\n supercoolkay\n\n Very explanatory. Thanks!\n\n 12 days later\n\n post by kblockchainbabe on Nov 2, 2023\n\n kblockchainbabe\n\n Hi there! Just curious as to when Round 2 will be announced?\nThanks and happy to be here!\n\n post by KromatikaDAO on Nov 4, 2023\n\n KromatikaDAO\n\n @tnorm : Is STIP Round-2 open? Can you direct me to more info on Round 2 please?\n\n post by tnorm on Nov 4, 2023\n\n tnorm\n\n Because the budget was exceeded in Round 1 no Round 2 will take place.\n\n post by KromatikaDAO on Nov 5, 2023\n\n KromatikaDAO\n\n Got it. Thank you.\nWill there be a Round 2 in the near future? Any tentative time frame?\n\n post by kblockchainbabe on Nov 7, 2023\n\n kblockchainbabe\n\n tnorm\n\n also interested in knowing if and how to apply for round 2.\nthank you. there is another user here @jamieeto who tried to give me advice for how to connect my wallet and submit an application, but not sure if he is legitimate or not.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n STIP - Round 1: Application Period Update\n\n Short Term Incentives Program (STIP) Round 1\n\n 21\n\n 4.8k\n\n Oct 2023\n\n Arbitrum’s Short-Term Incentive Program (Arbitrum Improvement Proposal)\n\n Finalized AIPs\n\n aip\n\n 135\n\n 37.0k\n\n Aug 2024\n\n Extension of Arbitrum’s Short-Term Incentive Program\n\n Grants Discussions\n\n 99\n\n 12.9k\n\n Nov 2023\n\n Arbitrum Incentives Program - Working Group\n\n DAO Programs & Initiatives\n\n 27\n\n 5.5k\n\n Jan 2024\n\n LTI Pilot Program Position Application Thread\n\n Long Term Incentives Pilot Program (LTIPP)\n\n 67\n\n 11.1k\n\n Jan 2024","tokens":997,"squid":"spider-07","role":"Council Spider","at":1791344740058,"hash":"59b28d24d125c83cc547ba07e94a8b4c79a2a324"}
{"url":"https://forum.across.to/t/welcome-to-across/1123","domain":"forum.across.to","title":"Welcome to Across - WELCOME 👋 - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n Welcome to Across \n\n WELCOME 👋\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n post by Britt on Nov 10, 2022\n\n Britt\n\n Welcome to the Across Forum. This space has previously been used to share ideas and iterate on early attempts at governance. As we lead up to the token launch, this space may evolve a bit to make room for official Across DAO governance. Our governance process will use a combination of Forum and Snapshot, so you can expect to see this forum act as the starting point for all Across proposals.\nThe welcome category will be used to host all of the official governance docs for Across DAO.\nHappy bridging!\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Across Governance Operating Manual\n\n WELCOME 👋\n\n WELCOME 👋\n\n Jun 2025\n\n Across Token Launch Proposal\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 214\n\n May 2022\n\n Welcome to Discourse\n\n Nov 2021\n\n Initial thinking around token distribution\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 36\n\n Mar 2022\n\n What the token does?\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 25\n\n Apr 2022","tokens":1764,"squid":"spider-09","role":"Bridge Spider","at":1791344740357,"hash":"a0c419ab914a383ee5cb6c90264c563a11e9da9a"}
{"url":"https://forum.arbitrum.foundation/t/stip-round-1-application-period-update/17523","domain":"forum.arbitrum.foundation","title":"STIP - Round 1: Application Period Update - Archive / Short Term Incentives Program (STIP) Round 1 - Arbitrum","text":"The Arbitrum Foundation notified the Security Council on the need to perform a potential Emergency action. Following a review of the details and known risks, the Security Council decided to execute the upgrade and it was completed at 11:30 EST on 2nd October 2026.\nThis report provides an overview of the risks that required the Security Council Action:\n\nAdd a permissionless guard for the One-Step Proof of BoLD on Arbitrum One\n\nTemporarily pause activation of new Stylus contracts on Arbitrum One & Nova\n\nKey point: To date, known bugs for Stylus primarily impact chain liveness (e.g., denial of service attacks) and do not put any user funds at risk.\nWhy was this action taken\nLet’s take this opportunity to explain why action was taken on two separate issues concerning BoLD and Stylus.\nInstalling the guard for One-Step Proof of BoLD. Given the rise of AI-assisted attacks, we have implemented a precautionary approach that allows anyone to pause settlement of Arbitrum One on Ethereum if there are at least two conflicting answers that pass at the same level in which only one should be valid and pass. This is to halt a class of publicly verifiable and detectable attacks that exploit a bug in the one-step proof. If halted, Arbitrum One will continue to process as normal except that messages from Arbitrum One to Ethereum, such as withdrawals, that are not yet confirmed will have to wait. This provides time for the Security Council to deploy a fix for the bug and resume the rollup.\nPreventing activation of new Stylus contracts. AI-assisted tooling has led to an increasing number of sophisticated attacks on hand-crafted WASM programs that do not use the standard Stylus compiler toolchain. These programs are specifically designed to cause unexpected behaviors such as degrading the chain’s performance for all other users. To date, no attacks have been discovered that permits theft of user funds.\nNew ArbOS releases have patched several reported bugs and known attacks over the past few months, but out of an abundance of caution, we have decided to temporarily pause new activations of Stylus contracts. This was executed as an emergency action to prevent the deployment of new hand-crafted WASM programs that are not yet patched by the current version of ArbOS on the Arbitrum network.\nThe Arbitrum Foundation has informed the Security Council that they will work with the ArbitrumDAO to discuss next steps on the timeline and manner for enabling activation of new Stylus contracts. The Arbitrum community remains confident in the value of Stylus and want to preserve these use cases while taking preventative measures against Stylus-based attack vectors as AI-assisted attack tooling continues to evolve.\nImpact on builders and users\n\nNo new activations. New Stylus contracts cannot be activated during the pause including new versions of existing applications that require activation.\n\nExisting contracts are not paused. Already-active Stylus contracts continue to execute until expiration. This pause does not deactivate them.\n\nThe ArbOS 61 upgrade renewed all active contracts on Arbitrum One, so no currently active contract expires before August 20, 2027.\n\nRenewal via keepalive stays permissionless and is unaffected by the pause.\n\nReactivating an expired contract, or one that needs to be updated after a Stylus version change, is paused.\n\nUsing/calling any activated Stylus contract stays permissionless for all users and developers.\n\nNo impact on EVM. Solidity (EVM) contract deployment and execution are unaffected by this Security Council action.\n\nSecurity Council Actions\nThere are two actions bundled into a single payload:\n\nOne-Step Proof Guard. The L1UpgradeExecutor gives a new pause contract (PauseExecutor) the ability to pause and nothing else. The new pause contract grants the guard (OspSoundnessGuard) PAUSER_ROLE to use it. Anyone can show the guard two conflicting answers to the same step of an open challenge. If the one-step proof accepts both, the guard has the pause contract put Arbitrum One’s settlement to Ethereum on hold.\n\nStylus deactivation. The Security Council called ArbOwner.setWasmActivationGas(2^64 - 1) to raise the Stylus activation gas requirement on Arbitrum One and Nova. This makes activation prohibitively expensive and effectively disables new activations. This is a configuration change and does not require an ArbOS upgrade.\n\nThe Security Council signed the following transactions to update the configuration:\n\nEthereum: Ethereum Transaction Hash: 0x30732bb7d2... | Etherscan\nArbitrum One:\nArbitrum One Transaction Hash: 0x9eb3a4be3b... | Arbitrum One\nArbitrum Nova:\nArbitrum Nova transaction 0x79e0fed470dff7a22059b108e3f8f42eddd2b580a6771594060c4e7326c5f984 | Blockscout\n\nAn external audit was conducted for the OSP Guard contracts. No audit is required for the Stylus deactivation as it is only updating a single parameter in the ArbOS configuration.\n\n STIP - Round 1: Application Period Update \n\n ArchiveShort Term Incentives Program (STIP) Round 1\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Sep 2023\n\n 1 / 23\n\n Sep 2023\n\n Oct 2023\n\n post by Matt_StableLab on Sep 27, 2023\n\n Matt_StableLab\n\n Hi Everyone,\nThis is a formal announcement that the Application Period will end tonight, on September 27, 2023 11:59 PM EST.\nOnce the application period has concluded, any new applications will be withheld from the forum and will be placed in the forum queue until Round 2 of the program.\nRound 1 of the program will proceed with the following timeline:\n\nReview Period Begins: September 28, 2023 12:00 AM EST\n\nReview Period Deadline: October 4, 2023 11:59 PM EST\n\nVoting Period Begins: October 5, 2023\n\nVoting Period Deadline: October 12, 2023\n\nTo clarify the process ahead…\nDuring the Voting Period, eligible applications will be put to vote on Arbitrum Snapshot. StableLab will mark applications as ready for vote depending upon each application’s eligibility. To be eligible for Snapshot, programs must follow the following steps:\n\nApplications must integrate feedback to meet all of the aforementioned Application Requirements for the STIP program:\n\nApplications must format their post correctly.\nOnce feedback is collected, applicants will need to change their application title from [DRAFT] to [FINAL] by the Review Period deadline: October 4, 2023 11:59 PM EST. At that time, all eligible proposals with the following formatted titles will be migrated to Arbitrum Snapshot to vote. The correct format for a proposal ready to move to vote looks like this: [Project Name] [FINAL] [STIP - Round 1].\n\nIf your proposal has NOT been formatted as such it will NOT proceed to Snapshot.\nThe voting period will allow delegates to vote to determine each application’s success. To succeed, eligible applications must receive a greater than 50% majority in favor of the proposal and exceed the 71.51 million ARB vote quorum outlined in the STIP proposal.\nNext Steps\nTo kickoff the Review Period, StableLab is ingesting the rush of last minute proposals with plans to publish two posts tomorrow:\n\nA summary and review guide of existing applications for Delegates.\nA Community Call Schedule for both Applicants and Delegates.\n\nLastly, as we approach the voting period, StableLab and the STIP-ARB Multisig will publish additional information regarding the KYC process and the fund disbursement schedule and cadence for successful STIP Round 1 grantees.\nWe look forward to proceeding into the Review period tomorrow and we thank the DAO again for its support.\n\n [Shell Protocol] [FINAL] [STIP - Round 1]\n\n [Wormhole][FINAL][STIP - Round 1]\n\n [CRYPTEX FINANCE] [FINAL] [STIP - Round 1]\n\n [REALM] [FINAL] [STIP - Round 1]\n\n [PancakeSwap] [FINAL] [STIP - Round 1]\n\n 3\n\n 2\n\n 2\n\n 2\n\n post by HMX on Sep 27, 2023\n\n HMX\n\n @Matt_StableLab HMX team posted the grant application earlier today but somehow it was flagged by a bot for review and the post is now hidden.\nBeing cognizant of the submission deadline, should we try to repost with a different account or the original post will still be considered as being submitted within the deadline.\nThank you!\n\n post by Matt_StableLab on Sep 27, 2023\n\n Matt_StableLab\n\n @HMX The foundation must approve posts for new users. Sometimes this takes time but as your post was submitted before September 27, 2023 11:59 PM EST it should be approved and will be checked for eligibility once it makes it to the forum.\n@cliffton.eth could you help HMX out with this?\n\n post by HMX on Sep 27, 2023\n\n HMX\n\n @Matt_StableLab Thank you for the clarification\n@cliffton.eth here is the link to the post: https://forum.arbitrum.foundation/t/hmx-draft-stip-round1/17518/1\nThanks for your help.\n\n post by cliffton.eth on Sep 27, 2023\n\n cliffton.eth\n\n Hey @HMX , this post is now live! [HMX][DRAFT][STIP-Round1]\n\n post by HMX on Sep 27, 2023\n\n HMX\n\n @cliffton.eth Many thanks for the help! \n\n Pinned on Sep 27, 2023\n\n post by archipelabro on Sep 27, 2023\n\n archipelabro\n\n Made a dashboard summarising all 92 applications!\nNot yet accounting for more recent updates to the breakdown/sizes though, just their original asks.\n\n post by tnorm on Sep 28, 2023\n\n tnorm\n\n A few helpful dashes floating around:\nBlockworks: Blockworks Research | Arbitrum Incentive Proposals - Google Sheets\nArbitrum STIP tracking - Google Sheets\n@jerame20 Arbitrum STIP tracking - Google Sheets\n@archipelabro: Arbitrum_STIP by archipelabro - Google Sheets\n@CastleCapital Has one too?\n\n post by AlexLumley on Sep 28, 2023\n\n AlexLumley\n\n Appreciate you bringing all of the different sheets in to one place. \n\n post by KeepBuildong on Sep 28, 2023\n\n KeepBuildong\n\n Thanks @tnorm @Matt_StableLab @jerame20 @archipelabro , is gone be a great vote for buildooor , and a great exchange of skills to buildong in it.\n\n post by CastleCapital on Oct 1, 2023\n\n CastleCapital\n\n tnorm\n\n These sheets are a great resource!\nWe will publish something in due course, but it is currently a WIP\n\n post by North on Oct 2, 2023\n\n North\n\n tnorm\n\n @tnorm\nEach of these has incorrect and varying information for the Ramses proposal\nConsidering the volume of applications the delegates have to cover, I’m concerned that we get the correct information to them in these (helpful) aggregated tracking sheets.\nAnything I can do to help update this information so it matches the proposal?\nThanks\n\n post by ALAYA on Oct 2, 2023\n\n ALAYA\n\n A question here. I can’t edit the title right now and should I wait for the system to uniformly open the permissions to allow modification？\n\n post by chefmaroon on Oct 4, 2023\n\n chefmaroon\n\n A big thank you to Blockworks, @jerame20, @archipelabro, and @CastleCapital for helping to compile the proposals!\nJust a note that PancakeSwap has revised our grant request amount to 200k ARB tokens - we’d greatly appreciate if you could help reflect that in your respective sheets \n\n post by TheTrueLeonidas on Oct 4, 2023\n\n TheTrueLeonidas\n\n tnorm\n\n SpartaDEX has reduced the grant request amount from 650,000 $ARB to 500,000 $ARB, therefore incorporating the valuable feedback provided by @CastleCapital. Thank you guys for helping in improving the proposal so it can serve the Arbitrum Ecosystem better.\n@jerame20, @archipelabro, we would be grateful if you could include this change in your sheets. Thanks in advance!\n\n post by 543 on Oct 4, 2023\n\n 543\n\n ALAYA\n\n hey alaya, you need to tag @ cliff or eli (admins of this forum) on your propoal and announce that your proposal is Final. and then they will edit the title for you : )\n\n post by archipelabro on Oct 5, 2023\n\n archipelabro\n\n archipelabro\n\n Updated everything to reflect the final applications!\n\n post by InspexCo on Oct 6, 2023\n\n InspexCo\n\n We have created a dashboard to track live voting of STIP proposals on Arbitrum Foundation\nhere: https://link.inspex.co/arbitrum-grants-voting-dashboard\nWe are also planning to create a comprehensive dashboard to track and monitor all the grant distributions for all successful applicants. So stay tuned for that! If there is any specific data you would like to see please let us know and we will incorporate them.\n\n post by mhiztasolid on Oct 7, 2023\n\n mhiztasolid\n\n archipelabro\n\n 50million $ARB in @arbitrum ecosystem incentives is coming! \n\n Load more posts below","tokens":3060,"squid":"spider-07","role":"Council Spider","at":1791344751159,"hash":"a8f26c4ff3d3761511d1fff649b68cc0eb4a85c1"}
{"url":"https://forum.across.to/t/welcome-to-discourse/7","domain":"forum.across.to","title":"Welcome to Discourse - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n Welcome to Discourse \n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Nov 2021\n\n 1 / 2\n\n Nov 2021\n\n Nov 2021\n\n post by system on Nov 1, 2021\n\n system\n\n This Forum serves as the starting consensus mechanism for The Across Protocol Fair Fair Launch. It is an offer to the world to take freely an audited, fully-functional protocol and see how a crypto-native community will choose to allocate ownership.\n\n 4 years later\n\n Unpinned on Mar 12\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Welcome to Across\n\n WELCOME 👋\n\n WELCOME 👋\n\n Nov 2022\n\n Across Token Launch Proposal\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 214\n\n May 2022\n\n Across Governance Operating Manual\n\n WELCOME 👋\n\n WELCOME 👋\n\n Jun 2025\n\n Across Token Launch Proposal v2\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 47\n\n Nov 2022\n\n “Community Owned Liquidity” NFT Project Funding Request\n\n Active Proposals\n\n treasury-funding\n\n Active Proposals\n\n 36\n\n Jun 2023","tokens":1734,"squid":"spider-09","role":"Bridge Spider","at":1791344751224,"hash":"27dfe5910c79477c2bbc6ccdecd03b3425924de9"}
{"url":"https://akash.network/docs/getting-started/how-funding-works/","domain":"akash.network","title":"How Funding Works | Akash Network - Your Guide to Decentralized Cloud","text":"How Funding Works You add credits to your Akash Console account, and Console keeps your deployments funded from that balance. There is no deposit to choose and no per-deployment balance to watch.\nThis page covers the managed Console at console.akash.network, including the Console API. If you deploy with your own wallet through Console Air or the CLI, you fund each deployment yourself. See Choosing Your Console.\nAdding credits\nCredits are denominated in US dollars. You get them three ways:\n\nFree trial credits when you first sign up, with no card required\nA card payment from Settings, under Payment Methods\nA coupon code, redeemed on the same page\n\nCredits are spent as your deployments run. Console converts them to the network’s ACT token behind the scenes, so nothing you do involves buying or holding crypto.\nAvailable and escrow\nYour billing page splits the account balance in two.\nEscrow is what your running deployments hold to stay online. Each deployment has its own escrow account on-chain, and Console keeps roughly two days of that deployment’s cost in it. A deployment costing 1/dayholdsabout2. Escrowed credits are held, not spent, and whatever a deployment does not use returns to available when it closes.\nAvailable is everything else: what you can spend on a new deployment right now.\nThe billing page also shows how long your whole balance will last at your current spend rate, and which deployments the escrow is split across.\nYou do not manage any of this yourself. You never choose a deposit or top a deployment up, because Console does both. If you deploy with your own wallet instead, you fund each escrow account directly. See Deployments and Escrow for the chain-level mechanics.\nAutomatic funding\nConsole funds every deployment for you. A new deployment is funded the moment it is created, so it can take a lease immediately rather than waiting for a background job. From then on, Console tops it up to keep it ahead of its own burn rate for as long as your account has credits. You do not enable this, and there is no per-deployment setting to get wrong.\nAutomatic funding also leaves some of your available balance untouched, so topping up a running deployment’s escrow can never eat the headroom you need to start a new one.\nNote: The exact figures (the runway Console targets, the headroom it leaves, and the amount a deployment starts with) are platform constants. API callers can read the current values from GET /v1/deployment-funding-config.\nAuto Top-Up\nAutomatic funding moves credits from your available balance into your deployments’ escrow. Auto Top-Up is the layer above it: charging your card so that balance never hits zero. It is off until you turn it on from the billing page, and it needs a default payment method.\nThere are two modes:\n\nFixed threshold charges a set amount as soon as your available balance drops to a limit you pick. This is the recommended mode.\nPredicted spend charges whatever it takes to cover the next week of your current deployments, checked once a day.\n\nRuntime limits\nBy default a deployment runs until you close it or your credits run out. You can instead give it a runtime limit when you create it, and Console will close it once it reaches that limit and return the unused credits to your balance.\nYou can extend a limit, or remove it and go back to always-on funding, from the deployment’s settings. Console emails you before a runtime-limited deployment reaches its limit.\nWhen credits run low\nConsole emails you before your credits run out, so you have time to add more. If you have Auto Top-Up on, your card is charged instead and you get no warning email, because there is nothing to act on.\nIf the balance does reach zero, automatic funding has nothing left to top up with. Your running deployments spend down the escrow they already hold and then close. Adding credits before that point keeps them alive with no further action from you: funding picks them up on its next pass.\nClosing a deployment\nClosing a deployment stops its services and returns whatever is left in its escrow to your available balance. Settlement happens on-chain, so the credited amount can take a short while to appear.\nRelated Resources\n\nConsole Onboarding Guide - Deploy your first app\nQuick Start - Deploy with free trial credits\nManaged Wallet API - The same funding model, from the API\nChoosing Your Console - Managed Console vs. self-custody Console Air\nDeployments and Escrow - How funding works at the blockchain level\n\nEdit page on github\n Core Concepts AI Agents","tokens":1133,"squid":"spider-03","role":"Compute Spider","at":1791344754847,"hash":"39a5b6eced4ec0ca594eecab49031170d4e45c83"}
{"url":"https://forum.across.to/t/across-token-launch-proposal/195","domain":"forum.across.to","title":"Across Token Launch Proposal - Tokenomics (old) - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n Across Token Launch Proposal \n\n Tokenomics (old)\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Mar 2022\n\n 1 / 215\n\n Mar 2022\n\n May 2022\n\n post by Kevin_UMA on Mar 18, 2022\n\n Kevin_UMA\n\n The launch of an Across token will grow and unite the Across community, incentivize liquidity providers, increase awareness of Across, and further the mission of being the fastest and cheapest L2 bridge. This proposal outlines a token launch plan and can be largely divided into three parts:\n\nInitial Distribution - a diversified airdrop and a treasury token swap.\n\nReward Locking Mechanism - a novel rewards program to incentivize all actions that support the Across protocol\n\nFuture Actions - a fundraising plan using success tokens and a staking mechanism\n\nPart 1 - Initial Distribution\n100,000,000 Across tokens ($ACX) will be minted. 85,000,000 $ACX will remain in the Across Dao Treasury and be reserved for incentive rewards and a future success token sale. 15,000,000 $ACX will be the initial supply and distributed in the following way:\n$ACX Airdrop - 10,000,000 $ACX in total will be rewarded to the following groups:\n\n20%: Across community Discord members with “co-founder status” who joined before March 18, 2022\n50%: LPs who pool assets and community members who refer users to the Across protocol before the token launch. The amount of rewards to LPs are pro-rated by size and a fixed amount of tokens will be emitted at each time since the inception of the protocol.\n10%: Early Across protocol users who bridged assets before March 11, 2022\n20%: Significant early contributors to the Across community which will later be determined by the new $ACX holders\n\n*Weights and exact details are all subject to change and dependent on the data collected ahead of token launch.\nThese groups will not be rewarded $ACX directly, but will instead claim a special “Co-Founder” NFT that can be burned in return for the corresponding $ACX. The “Co-Founder” NFT will be the first NFT that interacts with the Reward Locking Mechanism which will be further explained below. Recipients who keep this NFT will be granted status to earn additional rewards from protocol actions at a higher rate. Individuals given this “Co-Founder” status are therefore heavily incentivized to keep these NFTs.\nToken Swap for $UMA - 5,000,000 $ACX will be swapped with the Risk Labs Treasury for $2,500,000 worth of $UMA. This achieves two goals - it gives the Across community ownership and governance power in UMA which is critical to the security of the bridge, and it also provides voting rewards as a source of income to the Across DAO treasury. Risk Labs launched Across and will continue to support the protocol and community for the foreseeable future. Providing $ACX to Risk Labs will further incentivize the Risk Labs team. Risk Labs will have no plans to sell these tokens, but may use the tokens to help provide liquidity in $ACX and participate in governance.\nPart 2 - Across Reward Locking Mechanism\nUMA’s Optimistic Rewarder (OR) contract is a new DAO primitive that enables the creation of a customized rewards program that can direct token rewards to a wallet for any verifiable action that supports the protocol. This contract will be used to build the Across Reward Locking Mechanism to determine the rate at which rewards will be paid to a specific wallet. The longer a wallet keeps accumulated rewards unclaimed the faster the wallet earns additional rewards.\nA significant portion of the 85,000,000 $ACX in reserve will be emitted through this incentive program and community members can earn $ACX by doing any of the following actions:\n\nRefer new users through the Across Referral Program\nStake Across LP shares from bridge pools - WETH and USDC pools will be the first Across pools to be incentivized\nStake $ACX LP shares from a designated $ACX/ETH pool\n\nAcross Referral Program - The referral program will convert the Across community into a sales force. To participate in the referral program, Across supporters can enter their wallet address to generate a unique referral link. A user who clicks that link and completes a bridge transfer on Across will attribute $ACX rewards to the referrer. Supporters are encouraged to share their link with friends and promote Across on social media, such as Twitter. This can also be used in integrations with other projects. A bridge aggregator or a DEX can create a referral link to connect Across to their dApp. Once that link is clicked and a bridge transfer is completed, rewards will be allocated to that project. The Across referral program will begin before the $ACX token is launched and a deserving wallet will earn the accumulated awards at token launch.\nReward Locked NFT and the Reward Locked Multiplier\nEach community member who has taken one of the three actions to earn $ACX will be allowed to mint a Reward Locked NFT (reNFT). Each wallet will only have one reNFT even if multiple actions are performed. The single reNFT will represent the details of the actions performed and the accumulated $ACX rewards. In order to claim these rewards, the community member must burn their reNFT. If instead the community member decides to leave these rewards locked in the reNFT, the reNFT will accrue status and increase the rate at which additional rewards can be earned. The longer the rewards remain unclaimed the higher the rewards multiplier. However, once the reNFT is burned to claim rewards any multiplier and status obtained is immediately erased.\nReward Locked Multiplier for holding $ACX\nEach unique reNFT will have a reward locked multiplier determined by how long a wallet has held their unclaimed $ACX rewards. Similar to existing liquidity mining programs, a set amount of $ACX is emitted at each block for the bridge pools and the $ACX/ETH liquidity pool. However, an LP’s share of token rewards is determined not only by the amount of assets the LP has relative to the entire pool, but also by the LP’s unique multiplier. The multiplier chart could look like the one illustrated below and it is further gamified with the reNFT receiving a level and title. The community is encouraged to discuss these parameters, titles, and other possible privileges. In addition, the community should consider ways to make the process sybil resistant so that it only encourages behavior that supports Across.\n\nLevel\nTitle\nDays Held\nMultiplier\n\n1\nTroll\n30\n0.5\n\n2\nPeon\n60\n0.75\n\n3\nGrunt\n90\n1\n\n4\nTollKeeper\n120\n1.1\n\n5\nMason\n150\n1.2\n\n6\nWelder\n180\n1.3\n\n7\nForeman\n210\n1.4\n\n8\nArchitect\n240\n1.5\n\n9\nEngineer\n270\n1.75\n\n10\nMaster Builder\n300\n2\n\n*A troll cannot claim rewards\nReward Locking Mechanism = Gamification of DeFi\nThe benefits of the Reward Locking Mechanism are clear. Keeping rewards locked in a reNFT discourages farm and dump activity, but more importantly it makes the LP and referrer more engaged with the protocol. If you are encouraged to have a stake in the protocol you will naturally want to know more about it and you are incentivized to join the community and further its mission.\nThe reward locking mechanism can also be gamified further with a well thought out user interface and user experience to make it appear like an actual game. It can be built similar to a RPG where users can earn special NFTs or items for reaching certain milestones. Community members could build this and/or an actual game that uses these stats and do battles with one another. As well, a leader board can recognize the accomplishments of all committed Across users. This would all work to make the user very reluctant to claim their rewards and burn their precious reNFT. (The below graphic is my poor attempt at using Microsoft Paint and Word to show a mock UI.)\n\n1022×556 447 KB\n\nPart 3 - Future Actions\nSuccess Token Sale - As the Across protocol grows and matures it will move further towards decentralization and will operate independent of Risk Labs. At that point the Across DAO should raise operating funds through an $ACX success token sale. Success tokens incentivize investors to engage with the protocol by rewarding them more tokens when a goal is achieved.\nStaked $ACX - As the protocol matures, staked $ACX will grant governance rights and also share in Across protocol revenue. Governance can dictate where incentive rewards will be directed in order to determine which tokens and which L2 should get more liquidity. This vote lock like mechanism can add further value to $ACX and the Across protocol.\nConclusion\nIn addition to building community and incentivizing project goals, the Across token launch aims to create value and meaning to owning $ACX. The objective is to have $ACX token holders interact with the protocol through their token as soon as it is launched. In fact, by outlining what actions will be rewarded ahead of the airdrop, the protocol is encouraging Across LP activity and referrals even before the launch. The Across Reward Locking Mechanism will engage community members and use $ACX as a currency to gamify and incentivize contributions to the protocol. The $ACX token will represent real ownership of the Across protocol in terms of economics and governance.\nFeedback on this proposal is very much welcome. Mechanics and numbers can and should all be discussed so that the community is comfortable ahead of this token launch.\n\n 这个提议很好，希望社区也做越好\n\n Across Token Launch Proposal v2\n\n 8\n\n 4\n\n 3\n\n 3\n\n 3\n\n read \n\n 18\n min\n\n post by Werlda_Hert on Mar 18, 2022\n\n post by Pusat on Mar 18, 2022\n\n post by Pusat on Mar 18, 2022\n\n post by dadababa on Mar 18, 2022\n\n post by blank1u on Mar 18, 2022\n\n post by TheRealTuna_Across on Mar 18, 2022\n\n post by Srtemis on Mar 18, 2022\n\n post by AlfaAlerts on Mar 18, 2022\n\n post by zakk on Mar 18, 2022\n\n post by wenqi on Mar 18, 2022\n\n post by Micle on Mar 18, 2022\n\n post by BingBing on Mar 18, 2022\n\n post by MRcooljin on Mar 18, 2022\n\n post by Maple on Mar 18, 2022\n\n post by Momo95 on Mar 18, 2022\n\n post by BlastPit on Mar 18, 2022\n\n post by Btc.eth on Mar 18, 2022\n\n post by noun211 on Mar 18, 2022\n\n post by zws970906 on Mar 18, 2022\n\n Load more posts below","tokens":4012,"squid":"spider-09","role":"Bridge Spider","at":1791344761328,"hash":"57fc91c2cc6eacb7298422d666830df026ca4419"}
{"url":"https://forum.arbitrum.foundation/t/stip-round-1-application-period-update/17523/23","domain":"forum.arbitrum.foundation","title":"STIP - Round 1: Application Period Update - Archive / Short Term Incentives Program (STIP) Round 1 - Arbitrum","text":"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 Sep 2023\n\n 23 / 23\n\n Oct 2023\n\n Oct 2023\n\n Load more posts above\n\n post by HMX on Sep 27, 2023\n\n HMX\n\n Matt_StableLab\n\n @Matt_StableLab Thank you for the clarification\n@cliffton.eth here is the link to the post: https://forum.arbitrum.foundation/t/hmx-draft-stip-round1/17518/1\nThanks for your help.\n\n post by cliffton.eth on Sep 27, 2023\n\n cliffton.eth\n\n Hey @HMX , this post is now live! [HMX][DRAFT][STIP-Round1]\n\n post by HMX on Sep 27, 2023\n\n HMX\n\n @cliffton.eth Many thanks for the help! \n\n Pinned on Sep 27, 2023\n\n post by archipelabro on Sep 27, 2023\n\n archipelabro\n\n Made a dashboard summarising all 92 applications!\nNot yet accounting for more recent updates to the breakdown/sizes though, just their original asks.\n\n post by tnorm on Sep 28, 2023\n\n tnorm\n\n A few helpful dashes floating around:\nBlockworks: Blockworks Research | Arbitrum Incentive Proposals - Google Sheets\nArbitrum STIP tracking - Google Sheets\n@jerame20 Arbitrum STIP tracking - Google Sheets\n@archipelabro: Arbitrum_STIP by archipelabro - Google Sheets\n@CastleCapital Has one too?\n\n post by AlexLumley on Sep 28, 2023\n\n AlexLumley\n\n Appreciate you bringing all of the different sheets in to one place. \n\n post by KeepBuildong on Sep 28, 2023\n\n KeepBuildong\n\n Thanks @tnorm @Matt_StableLab @jerame20 @archipelabro , is gone be a great vote for buildooor , and a great exchange of skills to buildong in it.\n\n post by CastleCapital on Oct 1, 2023\n\n CastleCapital\n\n tnorm\n\n These sheets are a great resource!\nWe will publish something in due course, but it is currently a WIP\n\n post by North on Oct 2, 2023\n\n North\n\n tnorm\n\n @tnorm\nEach of these has incorrect and varying information for the Ramses proposal\nConsidering the volume of applications the delegates have to cover, I’m concerned that we get the correct information to them in these (helpful) aggregated tracking sheets.\nAnything I can do to help update this information so it matches the proposal?\nThanks\n\n post by ALAYA on Oct 2, 2023\n\n ALAYA\n\n A question here. I can’t edit the title right now and should I wait for the system to uniformly open the permissions to allow modification？\n\n post by chefmaroon on Oct 4, 2023\n\n chefmaroon\n\n A big thank you to Blockworks, @jerame20, @archipelabro, and @CastleCapital for helping to compile the proposals!\nJust a note that PancakeSwap has revised our grant request amount to 200k ARB tokens - we’d greatly appreciate if you could help reflect that in your respective sheets \n\n post by TheTrueLeonidas on Oct 4, 2023\n\n TheTrueLeonidas\n\n tnorm\n\n SpartaDEX has reduced the grant request amount from 650,000 $ARB to 500,000 $ARB, therefore incorporating the valuable feedback provided by @CastleCapital. Thank you guys for helping in improving the proposal so it can serve the Arbitrum Ecosystem better.\n@jerame20, @archipelabro, we would be grateful if you could include this change in your sheets. Thanks in advance!\n\n post by 543 on Oct 4, 2023\n\n 543\n\n ALAYA\n\n hey alaya, you need to tag @ cliff or eli (admins of this forum) on your propoal and announce that your proposal is Final. and then they will edit the title for you : )\n\n post by archipelabro on Oct 5, 2023\n\n archipelabro\n\n archipelabro\n\n Updated everything to reflect the final applications!\n\n post by InspexCo on Oct 6, 2023\n\n InspexCo\n\n We have created a dashboard to track live voting of STIP proposals on Arbitrum Foundation\nhere: https://link.inspex.co/arbitrum-grants-voting-dashboard\nWe are also planning to create a comprehensive dashboard to track and monitor all the grant distributions for all successful applicants. So stay tuned for that! If there is any specific data you would like to see please let us know and we will incorporate them.\n\n post by mhiztasolid on Oct 7, 2023\n\n mhiztasolid\n\n archipelabro\n\n 50million $ARB in @arbitrum ecosystem incentives is coming! \n\n post by sharp on Oct 11, 2023\n\n sharp\n\n archipelabro\n\n this data is soo cool, thanks for getting it all in one place @archipelabro @tnorm \n\n post by aleezagroks on Oct 11, 2023\n\n aleezagroks\n\n Heads up @BlockworksResearch your description of Shell Protocol’s proposal in this sheet is inaccurate–the final proposal is 100% fee rebates with 50:50 matching.\n\n post by sharp on Oct 12, 2023\n\n sharp\n\n archipelabro\n\n Hey folks, we loved the data but wanted to make a more inteactive interface for users to easily filter the STIP applicants data, so we created an upgraded version on the STIP dashboard, check it out here\n\nimage1436×690 73.9 KB\nimage1653×782 59.6 KB\n\n Related topics\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 Apply - Arbitrum Short Term Incentives Program\n\n Short Term Incentives Program (STIP) Round 1\n\n 41\n\n 7.8k\n\n Nov 2023\n\n Reflections on the Short-Term Incentive Program\n\n Short Term Incentives Program (STIP) Round 1\n\n 3\n\n 1.4k\n\n Oct 2023\n\n Short-Term Incentive Grants Pitching Sessions\n\n Short Term Incentives Program (STIP) Round 1\n\n 53\n\n 6.8k\n\n Oct 2023\n\n STIP Application Template\n\n Short Term Incentives Program (STIP) Round 1\n\n 5\n\n 3.9k\n\n Oct 2023\n\n Arbitrum’s Short-Term Incentive Program (Arbitrum Improvement Proposal)\n\n Finalized AIPs\n\n aip\n\n 135\n\n 37.0k\n\n Aug 2024","tokens":1315,"squid":"spider-07","role":"Council Spider","at":1791344761462,"hash":"f7a8df2dec7d3e177cda32fc2685d6e81e9b1ec7"}
{"url":"https://www.metaplex.com/docs/smart-contracts/core/external-plugins/app-data","domain":"metaplex.com","title":"AppData Plugin | Metaplex Core","text":"The AppData Plugin provides secure, partitioned data storage on Core Assets. Third-party applications can store and read arbitrary data (JSON, MsgPack, or binary) with exclusive write access controlled by a Data Authority. What You'll LearnAdd AppData to Assets and CollectionsConfigure Data Authorities for secure writesChoose data schemas (JSON, MsgPack, Binary)Read and write data from on-chain and off-chainSummaryThe AppData plugin stores arbitrary data on Assets with controlled write access. Only the Data Authority can write to the plugin's data section, enabling secure third-party integrations.Store JSON, MsgPack, or Binary dataData Authority has exclusive write permissionAutomatically indexed by DAS (JSON/MsgPack)LinkedAppData variant for collection-wide writesOut of ScopeOracle validation (see Oracle Plugin), on-chain attributes (see Attributes Plugin), and off-chain metadata storage.Quick StartJump to: Add to Asset · Write Data · Read DataAdd AppData plugin with a Data Authority addressChoose schema: JSON, MsgPack, or BinaryWrite data using writeData() (must sign as Data Authority)Read data via DAS or direct account fetchWhat is an AppData Plugin?The AppData external plugin stores and contains arbitrary data that can be written to by the dataAuthority. Note this is different then the overall plugin authority stored in the ExternalRegistryRecord as it cannot update/revoke authority or change other metadata for the plugin. Think of AppData as like a partition data area of an Asset that only a certain authority can change and write to. This is useful for 3rd party sites/apps to store data needed to execute certain functionality within their product/app.Works WithMPL Core Asset✅MPL Core Collection*✅* MPL Core Collections can also work with the LinkedAppData Plugin.What is a LinkedAppData Plugin?The LinkedAppData plugin is built for Collections. It allows you to add a single plugin adapter on the collection which will allow you to write to any Asset in the collection.ArgumentsArgValuedataAuthorityPluginAuthorityschemaExternalPluginAdapterSchemadataAuthorityAttributeListconst dataAuthority = {\n type: 'Address',\n address: publicKey('11111111111111111111111111111111'),\n}\nschemaThe schema determines the type of data that is being stored within the AppData plugin. All schemas will be indexed by DAS.ArgDAS SupportedStored asBinary (Raw Data)✅base64Json✅jsonMsgPack✅jsonWhen indexing the data if there was an error reading the JSON or MsgPack schema then it will be saved as binary.Writing data to the `AppData` pluginimport { ExternalPluginAdapterSchema } from '@metaplex-foundation/mpl-core'\n// Chose from Binary, Json or MsgPack\nconst schema = ExternalPluginAdapterSchema.Json\nAdding the AppData Plugin to an AssetAdding a Attribute Plugin to an MPL Core Assetimport { publicKey } from '@metaplex-foundation/umi'\nimport { addPlugin, ExternalPluginAdapterSchema } from '@metaplex-foundation/mpl-core'\nconst assetSigner = generateSigner(umi);\nconst dataAuthority = publicKey('11111111111111111111111111111111')\nawait create(umi, {\n asset: asset.publicKey,\n name: \"My Asset\",\n uri: \"https://example.com/my-assets.json\"\n plugins: [\n {\n type: 'AppData',\n dataAuthority,\n schema: ExternalPluginAdapterSchema.Json,\n },\n ],\n}).sendAndConfirm(umi)\n// Alternatively you could add the plugin to an existing Asset\nawait addPlugin(umi, {\n asset,\n plugin: {\n type: 'AppData',\n dataAuthority,\n schema: ExternalPluginAdapterSchema.Json,\n },\n})\nWriting Data to the AppData PluginOnly the dataAuthority address can write data to the AppData plugin. To write data to the AppData plugin we will use a writeData() helper which takes the following args.ArgValuekey{ type: string, dataAuthority: publicKey}authoritysignerdatadata in the format you wish to storeassetpublicKeySerializing JSONSerializing JSONconst json = {\n timeStamp: Date.now(),\n message: 'Hello, World!',\n}\nconst data = new TextEncoder().encode(JSON.stringify(json))\nSerializing MsgPackSerializing MsgPack// This implementation uses `msgpack-lite` for serialization\nconst json = {\n timeStamp: Date.now(),\n message: 'Hello, World!',\n}\nconst data = msgpack.encode(json)\nSerializing BinaryAs binary can store arbitrary data it's up to you to decide on how you are going to serialize and deserialize the data.Serializing Binary// The below example is just creating bytes that are considered `true` or `false`.\nconst data = new Uint8Array([1, 0, 0, 1, 0])\nWriting DataAdding a Attribute Plugin to an MPL Core Assetawait writeData(umi, {\n key: {\n type: 'AppData',\n dataAuthority,\n },\n authority: dataAuthoritySigner,\n data: data,\n asset: asset.publicKey,\n}).sendAndConfirm(umi)\nReading Data from the AppData PluginData can be both read on chain programs and external sources pulling account data.Fetch the Raw DataThe first step to deserializing the data stored in an AppData plugin is to fetch the raw data and check the schema field which dictates the format in which the data is stored before serialization.Fetching `AppData` Raw Dataconst assetId = publicKey('11111111111111111111111111111111')\nconst dataAuthority = publicKey('33333333333333333333333333333333')\nconst asset = await fetchAsset(umi, assetId)\nlet appDataPlugin = asset.appDatas?.filter(\n (appData) => (appData.authority.address = dataAuthority)\n)\nlet data\nlet schema\n// Check if `AppData` plugin with the given authority exists\nif (appDataPlugin && appDataPlugin.length > 0) {\n // Save plugin data to `data`\n data = appDataPlugin[0].data\n // Save plugin schema to `schema`\n schema = appDataPlugin[0].schema\n}\nDeserializationNow that you have the data you'll need to deserialize the data depending on the schema you chose to write the data with to the AppData plugins.Deserialize JSON SchemaDeserializing JSON// Due to the JS SDK, the deserialization for the MsgPack schema is automatic and deserialized\n// data can be accessed at the RAW location example above.\nDeserialize MsgPack SchemaDeserializing MsgPack// Due to the JS SDK, the deserialization for the MsgPack schema is automatic and deserialized\n// data can be accessed at the RAW location example above.\nDeserialize Binary SchemaBecause the Binary schema is arbitrary data then deserialization will be dependent on the serialization you used.Deserializing Binary// As the binary data is arbitrary you will need to include your own deserializer to\n// parse the data into a usable format your app/website will understand.\nCommon ErrorsAuthority mismatchOnly the Data Authority can write data. Verify you're signing with the correct keypair.Data too largeThe data exceeds account size limits. Consider compressing or splitting data across multiple plugins.Invalid schemaThe data doesn't match the declared schema. Ensure JSON is valid or MsgPack is properly encoded.NotesData Authority is separate from plugin authorityChoose JSON or MsgPack for DAS indexingBinary schema for custom serialization formatsLinkedAppData allows writing to any Asset in a CollectionQuick ReferenceSchema ComparisonSchemaDAS IndexedBest ForJSON✅ As JSONHuman-readable, web appsMsgPack✅ As JSONCompact, typed dataBinary✅ As base64Custom formats, max efficiencyAppData vs Attributes PluginFeatureAppDataAttributesWrite permissionData Authority onlyUpdate AuthorityData formatAny (JSON, MsgPack, Binary)Key-value stringsThird-party friendly✅ Yes❌ Requires update authorityDAS indexing✅ Yes✅ YesFAQWhat's the difference between AppData and the Attributes plugin?Attributes stores key-value strings controlled by the update authority. AppData stores arbitrary data controlled by a separate Data Authority, making it ideal for third-party applications.Can I have multiple AppData plugins on one Asset?Yes. Each AppData plugin can have a different Data Authority, allowing multiple third-party apps to store data on the same Asset.How do I update existing AppData?Call writeData() with the new data. This replaces the existing data entirely—there's no partial update.Is AppData indexed by DAS?Yes. JSON and MsgPack schemas are automatically deserialized and indexed. Binary is stored as base64.What is LinkedAppData?LinkedAppData is added to a Collection and allows the Data Authority to write to any Asset in that Collection without adding AppData to each Asset individually.GlossaryTermDefinitionAppDataExternal plugin for storing arbitrary data on AssetsData AuthorityAddress with exclusive write permissionLinkedAppDataCollection-level variant for writing to any AssetSchemaData format: JSON, MsgPack, or BinarywriteData()Function to write data to AppData pluginRelated PagesExternal Plugins Overview - Understanding external pluginsOracle Plugin - Validation instead of data storageAttributes Plugin - Built-in key-value storageOn-chain Ticketing Guide - AppData example","tokens":2187,"squid":"dotcat","role":"Tooling Spider","at":1791344766688,"hash":"96b5c7b579867d92bbcc7bee65dc97b7778d067f"}
{"url":"https://forum.across.to/t/across-token-launch-proposal/195/1","domain":"forum.across.to","title":"Across Token Launch Proposal - Tokenomics (old) - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n Across Token Launch Proposal \n\n Tokenomics (old)\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Mar 2022\n\n 1 / 215\n\n Mar 2022\n\n May 2022\n\n post by Kevin_UMA on Mar 18, 2022\n\n Kevin_UMA\n\n The launch of an Across token will grow and unite the Across community, incentivize liquidity providers, increase awareness of Across, and further the mission of being the fastest and cheapest L2 bridge. This proposal outlines a token launch plan and can be largely divided into three parts:\n\nInitial Distribution - a diversified airdrop and a treasury token swap.\n\nReward Locking Mechanism - a novel rewards program to incentivize all actions that support the Across protocol\n\nFuture Actions - a fundraising plan using success tokens and a staking mechanism\n\nPart 1 - Initial Distribution\n100,000,000 Across tokens ($ACX) will be minted. 85,000,000 $ACX will remain in the Across Dao Treasury and be reserved for incentive rewards and a future success token sale. 15,000,000 $ACX will be the initial supply and distributed in the following way:\n$ACX Airdrop - 10,000,000 $ACX in total will be rewarded to the following groups:\n\n20%: Across community Discord members with “co-founder status” who joined before March 18, 2022\n50%: LPs who pool assets and community members who refer users to the Across protocol before the token launch. The amount of rewards to LPs are pro-rated by size and a fixed amount of tokens will be emitted at each time since the inception of the protocol.\n10%: Early Across protocol users who bridged assets before March 11, 2022\n20%: Significant early contributors to the Across community which will later be determined by the new $ACX holders\n\n*Weights and exact details are all subject to change and dependent on the data collected ahead of token launch.\nThese groups will not be rewarded $ACX directly, but will instead claim a special “Co-Founder” NFT that can be burned in return for the corresponding $ACX. The “Co-Founder” NFT will be the first NFT that interacts with the Reward Locking Mechanism which will be further explained below. Recipients who keep this NFT will be granted status to earn additional rewards from protocol actions at a higher rate. Individuals given this “Co-Founder” status are therefore heavily incentivized to keep these NFTs.\nToken Swap for $UMA - 5,000,000 $ACX will be swapped with the Risk Labs Treasury for $2,500,000 worth of $UMA. This achieves two goals - it gives the Across community ownership and governance power in UMA which is critical to the security of the bridge, and it also provides voting rewards as a source of income to the Across DAO treasury. Risk Labs launched Across and will continue to support the protocol and community for the foreseeable future. Providing $ACX to Risk Labs will further incentivize the Risk Labs team. Risk Labs will have no plans to sell these tokens, but may use the tokens to help provide liquidity in $ACX and participate in governance.\nPart 2 - Across Reward Locking Mechanism\nUMA’s Optimistic Rewarder (OR) contract is a new DAO primitive that enables the creation of a customized rewards program that can direct token rewards to a wallet for any verifiable action that supports the protocol. This contract will be used to build the Across Reward Locking Mechanism to determine the rate at which rewards will be paid to a specific wallet. The longer a wallet keeps accumulated rewards unclaimed the faster the wallet earns additional rewards.\nA significant portion of the 85,000,000 $ACX in reserve will be emitted through this incentive program and community members can earn $ACX by doing any of the following actions:\n\nRefer new users through the Across Referral Program\nStake Across LP shares from bridge pools - WETH and USDC pools will be the first Across pools to be incentivized\nStake $ACX LP shares from a designated $ACX/ETH pool\n\nAcross Referral Program - The referral program will convert the Across community into a sales force. To participate in the referral program, Across supporters can enter their wallet address to generate a unique referral link. A user who clicks that link and completes a bridge transfer on Across will attribute $ACX rewards to the referrer. Supporters are encouraged to share their link with friends and promote Across on social media, such as Twitter. This can also be used in integrations with other projects. A bridge aggregator or a DEX can create a referral link to connect Across to their dApp. Once that link is clicked and a bridge transfer is completed, rewards will be allocated to that project. The Across referral program will begin before the $ACX token is launched and a deserving wallet will earn the accumulated awards at token launch.\nReward Locked NFT and the Reward Locked Multiplier\nEach community member who has taken one of the three actions to earn $ACX will be allowed to mint a Reward Locked NFT (reNFT). Each wallet will only have one reNFT even if multiple actions are performed. The single reNFT will represent the details of the actions performed and the accumulated $ACX rewards. In order to claim these rewards, the community member must burn their reNFT. If instead the community member decides to leave these rewards locked in the reNFT, the reNFT will accrue status and increase the rate at which additional rewards can be earned. The longer the rewards remain unclaimed the higher the rewards multiplier. However, once the reNFT is burned to claim rewards any multiplier and status obtained is immediately erased.\nReward Locked Multiplier for holding $ACX\nEach unique reNFT will have a reward locked multiplier determined by how long a wallet has held their unclaimed $ACX rewards. Similar to existing liquidity mining programs, a set amount of $ACX is emitted at each block for the bridge pools and the $ACX/ETH liquidity pool. However, an LP’s share of token rewards is determined not only by the amount of assets the LP has relative to the entire pool, but also by the LP’s unique multiplier. The multiplier chart could look like the one illustrated below and it is further gamified with the reNFT receiving a level and title. The community is encouraged to discuss these parameters, titles, and other possible privileges. In addition, the community should consider ways to make the process sybil resistant so that it only encourages behavior that supports Across.\n\nLevel\nTitle\nDays Held\nMultiplier\n\n1\nTroll\n30\n0.5\n\n2\nPeon\n60\n0.75\n\n3\nGrunt\n90\n1\n\n4\nTollKeeper\n120\n1.1\n\n5\nMason\n150\n1.2\n\n6\nWelder\n180\n1.3\n\n7\nForeman\n210\n1.4\n\n8\nArchitect\n240\n1.5\n\n9\nEngineer\n270\n1.75\n\n10\nMaster Builder\n300\n2\n\n*A troll cannot claim rewards\nReward Locking Mechanism = Gamification of DeFi\nThe benefits of the Reward Locking Mechanism are clear. Keeping rewards locked in a reNFT discourages farm and dump activity, but more importantly it makes the LP and referrer more engaged with the protocol. If you are encouraged to have a stake in the protocol you will naturally want to know more about it and you are incentivized to join the community and further its mission.\nThe reward locking mechanism can also be gamified further with a well thought out user interface and user experience to make it appear like an actual game. It can be built similar to a RPG where users can earn special NFTs or items for reaching certain milestones. Community members could build this and/or an actual game that uses these stats and do battles with one another. As well, a leader board can recognize the accomplishments of all committed Across users. This would all work to make the user very reluctant to claim their rewards and burn their precious reNFT. (The below graphic is my poor attempt at using Microsoft Paint and Word to show a mock UI.)\n\n1022×556 447 KB\n\nPart 3 - Future Actions\nSuccess Token Sale - As the Across protocol grows and matures it will move further towards decentralization and will operate independent of Risk Labs. At that point the Across DAO should raise operating funds through an $ACX success token sale. Success tokens incentivize investors to engage with the protocol by rewarding them more tokens when a goal is achieved.\nStaked $ACX - As the protocol matures, staked $ACX will grant governance rights and also share in Across protocol revenue. Governance can dictate where incentive rewards will be directed in order to determine which tokens and which L2 should get more liquidity. This vote lock like mechanism can add further value to $ACX and the Across protocol.\nConclusion\nIn addition to building community and incentivizing project goals, the Across token launch aims to create value and meaning to owning $ACX. The objective is to have $ACX token holders interact with the protocol through their token as soon as it is launched. In fact, by outlining what actions will be rewarded ahead of the airdrop, the protocol is encouraging Across LP activity and referrals even before the launch. The Across Reward Locking Mechanism will engage community members and use $ACX as a currency to gamify and incentivize contributions to the protocol. The $ACX token will represent real ownership of the Across protocol in terms of economics and governance.\nFeedback on this proposal is very much welcome. Mechanics and numbers can and should all be discussed so that the community is comfortable ahead of this token launch.\n\n 这个提议很好，希望社区也做越好\n\n Across Token Launch Proposal v2\n\n 8\n\n 4\n\n 3\n\n 3\n\n 3\n\n read \n\n 18\n min\n\n post by Werlda_Hert on Mar 18, 2022\n\n Werlda_Hert\n\n(WΞRLDA HΞRT) Plans change. These words could inspire more confidence if they read “…will not sell these tokens, but will…”\n\n post by Pusat on Mar 18, 2022\n\n Pusat\n\n Looks like good but ı wısh ıt will not like Olympus.Project managements are important how they will manage period.And must of us,we dont have any experiment.İ wish it will be good\n\n post by Pusat on Mar 18, 2022\n\n Pusat\n\n Because ı like across\n\n post by dadababa on Mar 18, 2022\n\n dadababa\n\n Co-founder NFT sounds good\n\n post by blank1u on Mar 18, 2022\n\n blank1u\n\n Hope the community is getting better and better\n\n post by TheRealTuna_Across on Mar 18, 2022\n\n TheRealTuna_Across\n\n This is a very well thought out proposal and the token swap with UMA and NFT idea are a nice added bonus. Curious how the referal part of the 50% distribution works, having referred many people here but not documented it any of it. I support this proposal as is but also wonder if we can allocate some portion of the airdrop to target some communities outside our own. One idea I have is airdropping to some coordinape circles of some select communities to attract active participants. Thinking like 5% to a very small group.\n\n post by Srtemis on Mar 18, 2022\n\n Srtemis\n\n nice hope to across token\n\n post by AlfaAlerts on Mar 18, 2022\n\n AlfaAlerts\n\n I like this proposal and also the incentive to hold on to the tokens.\n\n post by zakk on Mar 18, 2022\n\n zakk\n\n Overall a good suggestion.\nI have a question about “community members who refer users to the Across protocol before the token launch.”\nWhat does this mean?\n① Invitation to Discord\n② People who spread Acoross on articles (Mirror etc.) and Twitter\n③ Other than that\nI think ② is better.\nFor example, how about targeting people who have completed tasks according to DappBack\npeople who wrote Mirror articles, people who feedback, people who got NFT, etc.\n\n post by wenqi on Mar 18, 2022\n\n wenqi\n\n This proposal is good!\n\n post by Micle on Mar 18, 2022\n\n Micle\n\n dear team, builder nft holder made more contribution than co-founder and they should be reward as well.\n\n post by BingBing on Mar 18, 2022\n\n BingBing\n\n dear team, builders who hold the builder nft should be considered to be rewarded too.\n\n post by MRcooljin on Mar 18, 2022\n\n MRcooljin\n\n DEAR SIR!\nThe nft of builder made more contribution than co-founder and they should be reward as well. OR it will get co-founder role, too! They build the peoject hardly!\n\n post by Maple on Mar 18, 2022\n\n Maple\n\n can’t wait to see acx token.\n\n post by Momo95 on Mar 18, 2022\n\n Momo95\n\n The proposal is good overall. One thing I would add is to include the successful dappback participants in the « referral » pot. The effect of their actions was seen across Across (hehe) social media channels through their tweets, reviews & other tasks. They did more in a day that some who have joined as co-founders before march 18th but did not contribute and might not even have used Across. It will add a couple more holders but it’s better than allocating a big pot to referral links imo.\n\n post by BlastPit on Mar 18, 2022\n\n BlastPit\n\n This proposal will be a milestone of our community, can’t wait to see it!\n\n post by Btc.eth on Mar 18, 2022\n\n Btc.eth\n\n 这个提议很好，很人性化，希望可以得到关注。。。。。。\n\n post by noun211 on Mar 18, 2022\n\n noun211\n\n Great proposal a few thoughts/questions:\n\nIt’s likely any future community remember referrals will be heavily sybiled. IMO just give 5% to retroactively to LPs based by size.\n10% to early across protocol users will also probably have been gamed. What measures will be taken against this?\nWhat vesting is being considered for the $ACX airdrop?\n\n post by zws970906 on Mar 18, 2022\n\n zws970906\n\n 很棒的提议 我希望我能获得 或者有机会获得它 谢谢\n\n Load more posts below","tokens":4785,"squid":"spider-09","role":"Bridge Spider","at":1791344771541,"hash":"ac0ee2e3f0a820f5e2129d7c01bc9e481a9b8ee2"}
{"url":"https://ethresear.ch/t/ethresear-ch-email-login-will-be-disabled-in-7-days/7369/5","domain":"ethresear.ch","title":"Ethresear.ch: email login will be disabled in 7 days - 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 3\n\n 3\n\n 2\n\n May 2020\n\n 4 / 16\n\n May 2020\n\n Oct 2021\n\n post by hwwhww on May 8, 2020\n\n hwwhww\n\n Thank you for using etheresear.ch forum!\nEmail login was enabled during the last time we restored the system. To mitigate spam and impersonator attacks, we decide to disable email login again and you can only log in with GitHub account.\nIf you were using email login, don’t worry! Please register a GitHub account with the same email to log in ethresear.ch, your previous posts and account content would remain unchanged.\nThanks.\n\n Somewhat time critical — How do I set a password?\n\n 4\n\n 3\n\n 3\n\n 2\n\n Pinned globally on May 8, 2020\n\n post by vbuterin on May 8, 2020\n\n vbuterin\n\n Should we just dogfood and enable logging in with an ethereum account? I remember @virgil or @Ping had a prototype for log-in-with-ETH on discourse?\n\n post by hwwhww on May 8, 2020\n\n hwwhww\n\n It’s still on our radar! I think one of pending issues that @virgil wanted to solve with ENS team is how to handle ENS transfer for authorization on discourse side, or even on ENS side.\nA future issue is how the merge people’s current discourse account and new Eauth login account gracefully.\nInteresting issues, we can introduce Eauth now if we sacrifice some (?) UX though.\n\n post by axic on May 8, 2020\n\n axic\n\n Just as discourse supports linking and login via Github, cannot the eauth login be added optionally, so that both github and eauth work at the same time?\n\n post by hwwhww on May 8, 2020\n\n hwwhww\n\n We can have multiple authorization options at the same time.\nIf we have both email login and GitHub oauth (as status-quo), and they can be merged together automatically well since the GitHub account identifier is the email you used to register GitHub account.\nBut for Eauth case, since you don’t register your Ethereum address / ENS with an email address, it will create a new discourse account when you use Eauth login. (@Ping please correct me if I’m wrong!)\n\n post by axic on May 8, 2020\n\n axic\n\nI see. But wouldn’t it be possible to add a field for “ENS name” in discourse (like now there’s the email field + github link) so the linking happens?\nAlternatively (though I am not a big fan due to the privacy aspect) EIP-634 could be used to link an ENS record to an email.\n\n post by kmichel on May 9, 2020\n\n kmichel\n\n Successfully logged in with it.\n\n post by vbuterin on May 9, 2020\n\n vbuterin\n\n axic\n\nBy ENS transfer you mean what happens if an ENS name is transferred to another account? Wouldn’t the natural answer be “well, for future logins start verifying signatures against that new account instead of the current one”? What’s the problem?\n\n post by hwwhww on May 9, 2020\n\n post by Ping on May 9, 2020\n\n post by vbuterin on May 10, 2020\n\n post by gkapkowski on May 13, 2020\n\n post by gkapkowski on May 13, 2020\n\n post by gkapkowski on May 13, 2020\n\n 1 year later\n\n post by x on Oct 22, 2021\n\n Powered by Discourse","tokens":745,"squid":"spider-04","role":"Research Spider","at":1791344773572,"hash":"70aaa45cc302140ffec5a8dcde75f41e4571ec47"}
{"url":"https://forum.across.to/t/across-token-launch-proposal/195/219","domain":"forum.across.to","title":"Across Token Launch Proposal - Tokenomics (old) - Across Protocol","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 8\n\n 4\n\n 3\n\n 3\n\n 3\n\n read \n\n 18\n min\n\n Mar 2022\n\n 215 / 215\n\n May 2022\n\n May 2022\n\n Load more posts above\n\n post by 0xhhyangly on Apr 21, 2022\n\n 0xhhyangly\n\n The proposal is very constructible. I would like to contribute more.\n\n post by 91chiao on Apr 21, 2022\n\n 91chiao\n\n Cant wait to see the power of Across proposal.\n\n post by luckyrubyus on Apr 21, 2022\n\n luckyrubyus\n\n luckyrubyus\n\n To add to it:\nIt’s time to vote, if we already have a few basic plans, voting is fair. We cannot make everyone happy, but at least majority can vote to express their preference.\n\n post by LL05999 on Apr 21, 2022\n\n LL05999\n\n It’s time to vote, if we already have a few basic plans, voting is fair. We cannot make everyone happy, but at least majority can vote to express their preference.\n\nAgreed, and I can’t wait for the vote anymore. This proposal is good, so for me, a early user, I really look forward to taking vote.\n\n post by Frost.East on Apr 21, 2022\n\n Frost.East\n\n Man0w\n\n To consider the involution(内卷） of NFT。\n\n post by bciase on Apr 22, 2022\n\n bciase\n\n Kevin_UMA\n\n 我很赞同你得观点，我认为这样做，我们得社区和生态都会得到提升\n\n post by leaf on Apr 22, 2022\n\n leaf\n\n Cool, can protocol users get some more shares?\n\n post by Arvex28 on Apr 22, 2022\n\n Arvex28\n\nI think the airdrop reward for the builder should be there, because they are already doing the task via 3rd party dapps and while working on the task from Across\n\nI think lp and bridgooor users should get rewarded according to their volume for using across\n\nRole discord across co founder before Mar 18th , it shouldn’t take much up to 10% of the airdrop supply, just 5% and 5% of it is put into the NFT holder of The Builder\n\nMy advice, do a filter on wallets that you feel are just looking for airdrops in the Across ecosystem and blacklist wallets for airdrops\n\nThat’s all my advice, thank you regards\n\n post by fukuyamasato on Apr 23, 2022\n\n fukuyamasato\n\nFirstly, I think early protocol users should get more since they’re the reason we are organizing this DAO.\nSecondly, $ACX should have more utility rather than governance. Some portion of bridge fees can be used for buyback. Governance tokens showed poor performance in price if their only utility is governance.\nhttps://static1.squarespace.com/static/5966eb2ff7e0ab3d29b6b55d/t/5f989987fc086a1d8482ae70/1603837124500/defi_governance_paper.pdf\n\n post by motif on Apr 24, 2022\n\n motif\n\n Very nicely put together proposal and sure looks to tick most aspects.\nAs I was reading, I was thinking we should be incentivising people to show up to important things, and reward those that carry multiple facets.\nSo a couple of suggestions:\n\nA multiplier for people who complete “ALL” listed (and deemed important) actions by across?\nA multiplier (some incentive mechanism) for those that turn up to participate on governance?\n\nAre the NFTs transferable? - could someone pass on their NFT instead of minting it?\nIf non transferrable - have to consider special cases where a wallets security might be compromised and you need an emergency workaround.\nOtherwise an excellent proposal imho and great way to bring align incentives.\nAlso second Tunas comment, where have brought many people over to across that I know first hand have bridged/provided liq. Some way to account for that?\n\n post by vicky77 on Apr 29, 2022\n\n vicky77\n\n I wonder if the snapshot time for the LP has been decided?\n\n post by zziaweiwei.eth on Apr 29, 2022\n\n zziaweiwei.eth\n\n I just came to the forum today. The project team respects the voice of the community and tries its best to meet the demands of real community members. I hope that across will get better and better.\n\n post by DSCVR-nbmrjun on Apr 29, 2022\n\n DSCVR-nbmrjun\n\n Good projects Good projects Good projects\n\n post by carrie on Apr 29, 2022\n\n carrie\n\n good project,hope to get better and more successful\n\n post by pzhome on Apr 29, 2022\n\n pzhome\n\n Hope the community is getting better and better\n\n post by xDans on Apr 29, 2022\n\n xDans\n\n This proposal is good!\n\n post by Defgrip on May 3, 2022\n\n Defgrip\n\n im on board! exciting to see this all come together\n\n post by LL88 on May 6, 2022\n\n LL88\n\n Project team teams: The builder’s NFT holder is not less contributed than the co -founder. It is not easy to get this NFT, and they should also get rewards. As far as my personal experience is concerned, I spent 2 days to fill in the form, learn, understand the project, and write the original article to get this NFT.\n\n post by AE2760 on May 9, 2022\n\n AE2760\n\n This proposal is very good, and the airdrop has also made innovations in the form of NFT, but it is necessary to clarify the corresponding number of airdrop tokens in the marketing activities such as the promotion bridge that is invited to be used, or whether to distribute it in the form of NFT, these need to be clearer\n\n post by bciase on May 9, 2022\n\n bciase\n\n I agree with it !this proposal is so cool!\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Across Token Launch Proposal v2\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 47\n\n Nov 2022\n\n Initial thinking around token distribution\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 36\n\n Mar 2022\n\n Second ACX Drop\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 15\n\n Feb 2024\n\n Across ($ACX) Community Initial Liquidity Proposal\n\n Passed Proposals\n\n Passed Proposals\n\n 49\n\n Nov 2022\n\n “Community Owned Liquidity” NFT Project Funding Request\n\n Active Proposals\n\n treasury-funding\n\n Active Proposals\n\n 36\n\n Jun 2023","tokens":1380,"squid":"spider-09","role":"Bridge Spider","at":1791344781728,"hash":"39053e882d7f5a8f96c9af2339ca4bff7e53767d"}
{"url":"https://ethresear.ch/t/ethresear-ch-email-login-will-be-disabled-in-7-days/7369/8","domain":"ethresear.ch","title":"Ethresear.ch: email login will be disabled in 7 days - 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 3\n\n 3\n\n 2\n\n May 2020\n\n 7 / 16\n\n May 2020\n\n Oct 2021\n\n post by hwwhww on May 8, 2020\n\n Pinned globally on May 8, 2020\n\n post by vbuterin on May 8, 2020\n\n post by hwwhww on May 8, 2020\n\n hwwhww\n\n It’s still on our radar! I think one of pending issues that @virgil wanted to solve with ENS team is how to handle ENS transfer for authorization on discourse side, or even on ENS side.\nA future issue is how the merge people’s current discourse account and new Eauth login account gracefully.\nInteresting issues, we can introduce Eauth now if we sacrifice some (?) UX though.\n\n post by axic on May 8, 2020\n\n axic\n\n Just as discourse supports linking and login via Github, cannot the eauth login be added optionally, so that both github and eauth work at the same time?\n\n post by hwwhww on May 8, 2020\n\n hwwhww\n\n We can have multiple authorization options at the same time.\nIf we have both email login and GitHub oauth (as status-quo), and they can be merged together automatically well since the GitHub account identifier is the email you used to register GitHub account.\nBut for Eauth case, since you don’t register your Ethereum address / ENS with an email address, it will create a new discourse account when you use Eauth login. (@Ping please correct me if I’m wrong!)\n\n post by axic on May 8, 2020\n\n axic\n\nI see. But wouldn’t it be possible to add a field for “ENS name” in discourse (like now there’s the email field + github link) so the linking happens?\nAlternatively (though I am not a big fan due to the privacy aspect) EIP-634 could be used to link an ENS record to an email.\n\n post by kmichel on May 9, 2020\n\n kmichel\n\n Successfully logged in with it.\n\n post by vbuterin on May 9, 2020\n\n vbuterin\n\n axic\n\nBy ENS transfer you mean what happens if an ENS name is transferred to another account? Wouldn’t the natural answer be “well, for future logins start verifying signatures against that new account instead of the current one”? What’s the problem?\n\n post by hwwhww on May 9, 2020\n\n hwwhww\n\nI believe we can add ENS name (or, ETH account) field in discourse. And then, we need to ask the GitHub login user to manually update that field to claim that “the one who has this ENS name / ETH account is me”. So when the user uses Eauth login later, it will be able to bind to the existing account.\n\nRight, adding the email field in ENS can also solve the password recovery issue on discourse! I understand why we may be against it, we are trying to dogfood with a decentralized solution, but we still want the email system to prevent a user from losing their properties forever. \n\nYes.\n\nI think the authentication follows the authorized controller of the ENS name, and use ENS name as the default handle name? It doesn’t take ENS as the first-class when searching for an associated account (ping @Ping to verify it).\n\n Somewhat time critical — How do I set a password?\n\n post by Ping on May 9, 2020\n\n post by vbuterin on May 10, 2020\n\n post by gkapkowski on May 13, 2020\n\n post by gkapkowski on May 13, 2020\n\n post by gkapkowski on May 13, 2020\n\n 1 year later\n\n post by x on Oct 22, 2021\n\n Powered by Discourse","tokens":798,"squid":"spider-04","role":"Research Spider","at":1791344783741,"hash":"8b1ccb457e8d17c8faefd87c1cb1358d23f35e37"}
{"url":"https://www.metaplex.com/docs/smart-contracts/core/plugins/attribute","domain":"metaplex.com","title":"Attribute Plugin | Metaplex Core","text":"The Attributes Plugin stores key-value pairs directly on-chain within Core Assets or Collections. Perfect for game stats, traits, and any data that on-chain programs need to read. What You'll LearnAdd on-chain attributes to Assets and CollectionsStore and update key-value pairsRead attributes from on-chain programsUse cases: game stats, traits, access levelsSummaryThe Attributes Plugin is an Authority Managed plugin that stores key-value string pairs on-chain. Unlike off-chain metadata, these attributes are readable by Solana programs and indexed by DAS.Store any string key-value pairs on-chainReadable by on-chain programs via CPIAutomatically indexed by DAS for fast queriesMutable by the update authorityOut of ScopeOff-chain metadata attributes (stored in JSON at URI), complex data types (only strings supported), and immutable attributes (all attributes are mutable).Quick StartJump to: Add to Asset · Update AttributesAdd the Attributes plugin: addPlugin(umi, { asset, plugin: { type: 'Attributes', attributeList: [...] } })Each attribute is a { key: string, value: string } pairUpdate anytime with updatePlugin()Query via DAS or fetch on-chainOn-Chain vs Off-Chain AttributesFeatureOn-Chain (this plugin)Off-Chain (JSON metadata)Storage locationSolana accountArweave/IPFSReadable by programs✅ Yes (CPI)❌ NoIndexed by DAS✅ Yes✅ YesMutable✅ YesDepends on storageCostRent (recoverable)Upload cost (one-time)Best forDynamic data, game statsStatic traits, imagesUse on-chain attributes when programs need to read the data or it changes frequently.Use off-chain metadata for static traits and image references.Common Use CasesGame character stats: Health, XP, level, class - data that changes during gameplayAccess control: Tier, role, permissions - data programs check for authorizationDynamic traits: Evolving NFTs where traits change based on actionsStaking state: Track staking status, rewards earned, time stakedAchievement tracking: Badges, milestones, completion statusRental/lending: Track rental periods, borrower info, return datesWorks WithMPL Core Asset✅MPL Core Collection✅ArgumentsArgValueattributeListArray<{key: string, value: string}>AttributeListThe attribute list consists of an Array[] then an object of key-value pairs {key: \"value\"} string value pairs.AttributeListconst attributeList = [\n { key: 'key0', value: 'value0' },\n { key: 'key1', value: 'value1' },\n]\nAdding the Attributes Plugin to an AssetAdding a Attribute Plugin to an MPL Core Assetimport { publicKey } from '@metaplex-foundation/umi'\nimport { addPlugin } from '@metaplex-foundation/mpl-core'\nconst asset = publicKey('11111111111111111111111111111111')\nawait addPlugin(umi, {\n asset: asset.publicKey,\n plugin: {\n type: 'Attributes',\n attributeList: [\n { key: 'key0', value: 'value0' },\n { key: 'key1', value: 'value1' },\n ],\n },\n}).sendAndConfirm(umi)\nUpdating the Attributes Plugin on an AssetUpdating the Attributes Plugin on an Assetimport { publicKey } from '@metaplex-foundation/umi'\nimport { updatePlugin } from '@metaplex-foundation/mpl-core'\nconst assetAddress = publicKey('11111111111111111111111111111111')\nawait updatePlugin(umi, {\n asset: assetAddress,\n plugin: {\n type: 'Attributes',\n attributeList: [\n { key: 'key0', value: 'value0' },\n { key: 'key1', value: 'value1' },\n ],\n },\n}).sendAndConfirm(umi)\nCommon ErrorsAuthority mismatchOnly the plugin authority (usually update authority) can add or update attributes. Verify you're signing with the correct keypair.String too longAttribute keys and values are limited in size. Keep them concise.NotesAuthority Managed: update authority can add/update without owner signatureAll values are strings - convert numbers/booleans as neededUpdating replaces the entire attribute list (no partial updates)Attributes increase account size and rent costDAS indexes attributes for fast queriesQuick ReferenceMinimum Codeminimal-attributes.tsimport { addPlugin } from '@metaplex-foundation/mpl-core'\nawait addPlugin(umi, {\n asset: assetAddress,\n plugin: {\n type: 'Attributes',\n attributeList: [\n { key: 'level', value: '5' },\n { key: 'class', value: 'warrior' },\n ],\n },\n}).sendAndConfirm(umi)\nCommon Attribute PatternsUse CaseExample KeysGame characterlevel, health, xp, classAccess controltier, access_level, roleTraitsbackground, eyes, rarityStatestaked, listed, lockedFAQWhat's the difference between on-chain attributes and off-chain metadata attributes?On-chain attributes (this plugin) are stored on Solana and readable by programs. Off-chain attributes (in JSON at URI) are stored on Arweave/IPFS and only readable by clients.Can on-chain programs read these attributes?Yes. Use CPI to fetch the Asset account and deserialize the Attributes plugin data.Are attributes indexed by DAS?Yes. DAS automatically indexes attribute key-value pairs for fast queries.Can I store numbers or booleans?Values are strings only. Convert as needed: { key: 'level', value: '5' }, { key: 'active', value: 'true' }.How do I update a single attribute?You can't update individual attributes. Fetch the current list, modify it, and update with the full new list.What's the size limit for attributes?There's no hard limit, but larger attribute lists increase rent cost. Keep data concise.Can the owner update attributes?No. The Attributes plugin is Authority Managed, so only the update authority can modify it (not the owner).Related PluginsUpdate Delegate - Grant others permission to update attributesImmutableMetadata - Lock name/URI (attributes remain mutable)AddBlocker - Prevent adding new pluginsGlossaryTermDefinitionAttributes PluginAuthority Managed plugin storing on-chain key-value pairsattributeListArray of { key, value } objectsAuthority ManagedPlugin type controlled by update authorityOn-chain DataData stored directly in Solana account (readable by programs)DASDigital Asset Standard API that indexes attributes","tokens":1465,"squid":"dotcat","role":"Tooling Spider","at":1791344787345,"hash":"1775c69abd6898fe51d9dcf6de20126506a45152"}
{"url":"https://forum.across.to/t/across-acx-community-initial-liquidity-proposal/1129","domain":"forum.across.to","title":"Across ($ACX) Community Initial Liquidity Proposal - Proposals / Passed Proposals - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n Across ($ACX) Community Initial Liquidity Proposal \n\n ProposalsPassed Proposals\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Nov 2022\n\n 1 / 50\n\n Nov 2022\n\n Nov 2022\n\n post by EAsports on Nov 15, 2022\n\n EAsports\n\n *ACP1: Across ($ACX) Community Initial Liquidity Proposal\nSummary -\nWith the upcoming token launch, liquidity is an important consideration. I am proposing that Across use Balancer for their liquidity DEX and that Risk Labs provides some initial $ACX incentives from the Across treasury for LPs to help establish deep liquidity that will minimize long term cost.\nBackground:\nOver the past few weeks $ACX liquidity has been a hot topic as we await the token launch. The community has held multiple AMAs on potential liquidity solutions, conversations in discord, questions, and ideas about the best options for liquidity. This proposal summarizes much of the discussion and aims to lay a foundation for $ACX liquidity alongside the upcoming token launch.\nProposed DEX/Platform:\nGiven multiple options reviewed and considering cost efficiency, ease of maintaining deep liquidity, opportunities for additional yield for LPs, and strategic partnership in the ecosystem, I am recommending we align as a community alongside the Across/RL team to use Balancer for the main liquidity pool for ACX with a 50/50 ACX/wstETH pool at token launch. This will provide one pool to focus on establishing deep liquidity, minimize cost & effort to maintain said liquidity long term.\nThis provides a simple approach as a foundation and benefits include:\n\nUsing a trusted platform in Balancer\nKeeping a simple 50/50 pool to minimize complexity or potential IL\nUsing wstETH as the pair provides deep liquidity and also additional yield opportunities other than trading fees for LPs through the Balancer/Aura framework that allow for cost efficient provision of liquidity instead of having to constantly incentivize long term.\nIn addition, aggregators can route swaps from eth to ACX even when the pool is wstETH/ACX. Balancer’s UI uses cowswap for trading and they are very well integrated so from a buyer/seller’s perspective it is no different than having ETH as the pair to ACX\n\nInitial Incentives:\nIt’s important to solidify this pool as the primary venue for trading ACX immediately so when the launch happens we don’t see fragmented liquidity across DEXs. I propose that the protocol treasury allocate some ACX towards direct incentives on the pool (LP’s would earn ACX).\nFor the first two weeks, I am proposing we allocate 60k ACX per week to encourage deep liquidity and establish this as the main pool for ACX trading. The Balancer team confirmed they can directly distribute these rewards to LPs through their gauge framework which means no additional effort for calculations or distribution. I would also recommend as part of this proposal that the Risk Labs team monitor the pool during these two weeks to watch depth of liquidity and LP participation and have the ability to adjust the reward rate to change behavior as they see fit.\nIf you would like to look at detailed calculations for what potential APR and estimated ACX counts, reference this spreadsheet from @hasherror here: ACX Swap Liquidity Scenarios\nIn addition, by using Balancer, we will work through their governance process to enable a gauge proposal to receive veBAL and Aura rewards emissions for LPs. Typically takes a couple weeks. We can monitor liquidity levels throughout the timeframe and adjust as needed, but the first two weeks of $ACX LM rewards are intended to start off strong and enable us to transition to a sustainable scale of APR through bribes that more closely align to the reward locking staking rewards.\nRelative Timeline:\nThere may be more nuance or additional details, but given the various moving pieces, I wanted to show key milestones and timeline relative to the Airdrop and token unlock announcement to set expectations on liquidity and LM incentives.\n1.) Risk Labs to formally announce timing of token launch/unlock\n2.) Some community members adds liquidity to Balancer pool to get it started as $ACX is available to claim\n4.) Pending agreement/approval of this proposal Across treasury send needed ACX to Balancer for 2 weeks of LM rewards\n5.) Liquidity incentives start\n6.) Post gauge governance proposal on Balancer once pool is up to tap into LP incentives through Balancer/Aura. Pending approval, those will begin in 1-2 weeks\nVote\nPlease vote on this proposal as a way to enact this streamlined governance process with a 3 day forum poll. Majority vote should carry the proposal.\nVoting “Yes” supports the proposal to have Across use Balancer for their liquidity DEX & that Risk Labs provides some initial $ACX incentives from the Across treasury for LPs to help establish liquidity\nVoting “No” is not supporting this proposal and don’t agree with this as a solution.\n\n Do you support this proposal?\n\n 97%\n Yes\n\n 3%\n No\n\n 74\n voters\n\n Closed Nov 2022\n\n $ACX Liquidity - Update and Feedback Wanted\n\n read \n\n 6\n min\n\n post by nithin_shylendra on Nov 15, 2022\n\n nithin_shylendra\n\n It’s a well thought out proposal that EA has put forward for the community and should be moved forward as it helps $ACX to setup and be traded for people who see value in it and would like to be part of the Across community.\n\n post by Rasbom on Nov 16, 2022\n\n Rasbom\n\n This is a well thought out proposal.\nKudos to you EA for taking your time to put this together. I must say you’ve make a reasonable and fair proposal.\n\n post by Marhkson_AptosLaunch on Nov 16, 2022\n\n Marhkson_AptosLaunch\n\n Nice Active proposal\nA very reasonable proposal , it will greatly benefits the whole ecosystem and also induced more trust to the community\n\n post by DonEchez on Nov 16, 2022\n\n DonEchez\n\n Sustainable development plan and not just this equal fork would not just equate but attracts more investors, which is the sol-aim of DAO. ($ACX)\n\n post by FruityCup on Nov 16, 2022\n\n FruityCup\n\n Wen token bby! Great job ea and hash! Time for the official across launch to begin! Take off imminent. Moon incoming.\n\n post by poopster on Nov 16, 2022\n\n poopster\n\n I shared my thoughts in discord but will share here as well, i think this is a well thought out proposal and only have one point of contention. I would recommend considering extending LM rewards to a month long instead of two weeks. Thanks for putting this together ser, well done\n\n post by hash_error on Nov 17, 2022\n\n hash_error\n\n I agree with your take poopster.\nMy view is after the first couple of weeks Across should be transitioning from direct incentives to the Aura hidden hands birb markets. The direct incentives for the first 2 weeks has 2 purposes imo. First, the gauges for Balancer veBAL and AURA vlAURA programs won’t be able to provide incentives on day 1 (length of time for first rounds of birbing, voting, etc) so Across needs a “bridge” of incentives for the first couple weeks. Also, the direct incentives are intended to aid in bootstrapping the LP with community participation with the goal of getting ACX the depth of liquidity sufficient to support reasonably low friction swapping quickly.\nMy 2 cents, a good Across birbing strategy that aligns to end of first 2 weeks of direct bootstrapping emissions and settles into a longer term plan is great next step for discussion.\n\n post by Everythingblockchain on Nov 17, 2022\n\n Everythingblockchain\n\n Thank you @EAsports for this proposal.\nGiven that the launch is planned in the next few weeks, it is important to have a mechanism in place for attracting liquidity. This could be a good starting point that can be further refined based on the results and the community feedback.\n\n post by Izkillaz on Nov 17, 2022\n\n Izkillaz\n\n This is awesome!!! This will boost up ACX to the moon! With this proposal, this will further cement ACX’s stability and provide firm hold on DEX markets. Balancer is a good platform with established market and support. Definitely worth the wait! Lezgaw ACROSS !\n\n post by breezy008 on Nov 17, 2022\n\n breezy008\n\n This is Nice EA … keep up the good work , I want to see $ACX at 5$.\nLet’s end 2022 on a good note​:hibiscus:.\nYeah… …\n\n post by Phuktep on Nov 17, 2022\n\n Phuktep\n\n Why not Uniswap instead of Balancer? Uniswap will almost surely become the eventual marketshare leader for ACX volume.\n\n post by a.mashura on Nov 17, 2022\n\n a.mashura\n\n Nice decision, hope the project has a great future \nIs the token going to be released before the new year?\n\n post by Dagnarus on Nov 17, 2022\n\n Dagnarus\n\n Right thing to do! Balancer good platform for liquidity! Community must support this! Let’s the launch begin!\n\n post by Britt on Nov 17, 2022\n\n Britt\n\n Thank you @EAsports for putting this together. I think this plan accomplishes a few key things.\n\nRecognizing the importance of establishing a trading liquidity pool and centering the community around one single pool.\nGiving the flexibility to adjust the incentives in order to achieve a sufficiently liquid token launch.\nAcknowledges that this is a stepping stone towards a more long-term incentives program for this pool.\n\nI personally support this proposal.\nThe sentiment around risk labs is supportive of this and it seems to me we will be happy to execute the wishes of this proposal.\n\n post by Valerii on Nov 17, 2022\n\n Valerii\n\n Community Initial Liquidity Proposal HM interesting suggestion. Need to try. agree with this as a solution.\n\n post by Vladyslav on Nov 17, 2022\n\n Vladyslav\n\n Good idea! Both hands for. During your work, you have come a long way and developed dramatically, I have been watching your project from the very beginning!\n\n post by chtotodrygoe on Nov 17, 2022\n\n chtotodrygoe\n\n It’s a good idea. A necessary and very necessary update for the project. I’m sure the project has a great future together with a great ecosystem and a cool community\n\n post by NotSatoshi on Nov 17, 2022\n\n NotSatoshi\n\n Very interesting activity, we look forward to more!)Your product is very good, and important in our time, the main thing is safety in translation)\n\n post by Ptrck on Nov 17, 2022\n\n Ptrck\n\nYeah, I like it. Balancer has quite a lot of lindy. I think we should pick the protocol which has the highest likelihood of surviving a potential 3 year long bear market\n\n Load more posts below","tokens":4067,"squid":"spider-09","role":"Bridge Spider","at":1791344792923,"hash":"635037449a03a142281cd1a704b27512673a933c"}
{"url":"https://ethresear.ch/t/ethresear-ch-email-login-will-be-disabled-in-7-days/7369/7","domain":"ethresear.ch","title":"Ethresear.ch: email login will be disabled in 7 days - 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 3\n\n 3\n\n 2\n\n May 2020\n\n 6 / 16\n\n May 2020\n\n Oct 2021\n\n post by hwwhww on May 8, 2020\n\n hwwhww\n\n Thank you for using etheresear.ch forum!\nEmail login was enabled during the last time we restored the system. To mitigate spam and impersonator attacks, we decide to disable email login again and you can only log in with GitHub account.\nIf you were using email login, don’t worry! Please register a GitHub account with the same email to log in ethresear.ch, your previous posts and account content would remain unchanged.\nThanks.\n\n Somewhat time critical — How do I set a password?\n\n 4\n\n 3\n\n 3\n\n 2\n\n Pinned globally on May 8, 2020\n\n post by vbuterin on May 8, 2020\n\n vbuterin\n\n Should we just dogfood and enable logging in with an ethereum account? I remember @virgil or @Ping had a prototype for log-in-with-ETH on discourse?\n\n post by hwwhww on May 8, 2020\n\n hwwhww\n\n It’s still on our radar! I think one of pending issues that @virgil wanted to solve with ENS team is how to handle ENS transfer for authorization on discourse side, or even on ENS side.\nA future issue is how the merge people’s current discourse account and new Eauth login account gracefully.\nInteresting issues, we can introduce Eauth now if we sacrifice some (?) UX though.\n\n post by axic on May 8, 2020\n\n axic\n\n Just as discourse supports linking and login via Github, cannot the eauth login be added optionally, so that both github and eauth work at the same time?\n\n post by hwwhww on May 8, 2020\n\n hwwhww\n\n We can have multiple authorization options at the same time.\nIf we have both email login and GitHub oauth (as status-quo), and they can be merged together automatically well since the GitHub account identifier is the email you used to register GitHub account.\nBut for Eauth case, since you don’t register your Ethereum address / ENS with an email address, it will create a new discourse account when you use Eauth login. (@Ping please correct me if I’m wrong!)\n\n post by axic on May 8, 2020\n\n axic\n\nI see. But wouldn’t it be possible to add a field for “ENS name” in discourse (like now there’s the email field + github link) so the linking happens?\nAlternatively (though I am not a big fan due to the privacy aspect) EIP-634 could be used to link an ENS record to an email.\n\n post by kmichel on May 9, 2020\n\n kmichel\n\n Successfully logged in with it.\n\n post by vbuterin on May 9, 2020\n\n vbuterin\n\n axic\n\nBy ENS transfer you mean what happens if an ENS name is transferred to another account? Wouldn’t the natural answer be “well, for future logins start verifying signatures against that new account instead of the current one”? What’s the problem?\n\n post by hwwhww on May 9, 2020\n\n hwwhww\n\nI believe we can add ENS name (or, ETH account) field in discourse. And then, we need to ask the GitHub login user to manually update that field to claim that “the one who has this ENS name / ETH account is me”. So when the user uses Eauth login later, it will be able to bind to the existing account.\n\nRight, adding the email field in ENS can also solve the password recovery issue on discourse! I understand why we may be against it, we are trying to dogfood with a decentralized solution, but we still want the email system to prevent a user from losing their properties forever. \n\nYes.\n\nI think the authentication follows the authorized controller of the ENS name, and use ENS name as the default handle name? It doesn’t take ENS as the first-class when searching for an associated account (ping @Ping to verify it).\n\n Somewhat time critical — How do I set a password?\n\n post by Ping on May 9, 2020\n\n post by vbuterin on May 10, 2020\n\n post by gkapkowski on May 13, 2020\n\n post by gkapkowski on May 13, 2020\n\n post by gkapkowski on May 13, 2020\n\n 1 year later\n\n post by x on Oct 22, 2021\n\n Powered by Discourse","tokens":966,"squid":"spider-04","role":"Research Spider","at":1791344793804,"hash":"096dd2e552e06269775e89245ade18611328ae99"}
{"url":"https://ethresear.ch/t/ethresear-ch-email-login-will-be-disabled-in-7-days/7369/9","domain":"ethresear.ch","title":"Ethresear.ch: email login will be disabled in 7 days - 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 3\n\n 3\n\n 2\n\n May 2020\n\n 8 / 16\n\n May 2020\n\n Oct 2021\n\n post by hwwhww on May 8, 2020\n\n hwwhww\n\n Thank you for using etheresear.ch forum!\nEmail login was enabled during the last time we restored the system. To mitigate spam and impersonator attacks, we decide to disable email login again and you can only log in with GitHub account.\nIf you were using email login, don’t worry! Please register a GitHub account with the same email to log in ethresear.ch, your previous posts and account content would remain unchanged.\nThanks.\n\n Somewhat time critical — How do I set a password?\n\n 4\n\n 3\n\n 3\n\n 2\n\n Pinned globally on May 8, 2020\n\n post by vbuterin on May 8, 2020\n\n vbuterin\n\n Should we just dogfood and enable logging in with an ethereum account? I remember @virgil or @Ping had a prototype for log-in-with-ETH on discourse?\n\n post by hwwhww on May 8, 2020\n\n hwwhww\n\n It’s still on our radar! I think one of pending issues that @virgil wanted to solve with ENS team is how to handle ENS transfer for authorization on discourse side, or even on ENS side.\nA future issue is how the merge people’s current discourse account and new Eauth login account gracefully.\nInteresting issues, we can introduce Eauth now if we sacrifice some (?) UX though.\n\n post by axic on May 8, 2020\n\n axic\n\n Just as discourse supports linking and login via Github, cannot the eauth login be added optionally, so that both github and eauth work at the same time?\n\n post by hwwhww on May 8, 2020\n\n hwwhww\n\n We can have multiple authorization options at the same time.\nIf we have both email login and GitHub oauth (as status-quo), and they can be merged together automatically well since the GitHub account identifier is the email you used to register GitHub account.\nBut for Eauth case, since you don’t register your Ethereum address / ENS with an email address, it will create a new discourse account when you use Eauth login. (@Ping please correct me if I’m wrong!)\n\n post by axic on May 8, 2020\n\n axic\n\nI see. But wouldn’t it be possible to add a field for “ENS name” in discourse (like now there’s the email field + github link) so the linking happens?\nAlternatively (though I am not a big fan due to the privacy aspect) EIP-634 could be used to link an ENS record to an email.\n\n post by kmichel on May 9, 2020\n\n kmichel\n\n Successfully logged in with it.\n\n post by vbuterin on May 9, 2020\n\n vbuterin\n\n axic\n\nBy ENS transfer you mean what happens if an ENS name is transferred to another account? Wouldn’t the natural answer be “well, for future logins start verifying signatures against that new account instead of the current one”? What’s the problem?\n\n post by hwwhww on May 9, 2020\n\n hwwhww\n\nI believe we can add ENS name (or, ETH account) field in discourse. And then, we need to ask the GitHub login user to manually update that field to claim that “the one who has this ENS name / ETH account is me”. So when the user uses Eauth login later, it will be able to bind to the existing account.\n\nRight, adding the email field in ENS can also solve the password recovery issue on discourse! I understand why we may be against it, we are trying to dogfood with a decentralized solution, but we still want the email system to prevent a user from losing their properties forever. \n\nYes.\n\nI think the authentication follows the authorized controller of the ENS name, and use ENS name as the default handle name? It doesn’t take ENS as the first-class when searching for an associated account (ping @Ping to verify it).\n\n Somewhat time critical — How do I set a password?\n\n post by Ping on May 9, 2020\n\n Ping\n\n @virgil suggests that we can use ethmail.cc by default, but at present ethmail seems not so well functioned and decentralized. \nIn Eauth scenario, account address is the primary key. And for ENS you need to not only own an ENS but also set it as your address’s reverse lookup name, then it would be displayed as your nickname.\nBTW, Eauth supports contract address login with EIP1271. I highly recommend this one. You can have multiple authenticate keys, timelock, social recovery, and lots of good stuff, without overhead to the platform. \nLogin with: Gnosis safe / Argent / Authereum / Dapper / etc\ncode: GitHub - pelith/node-eauth-server: An OAuth-compatiable service based on Ethereum credentials to authenticate users on a website. See live version at https://eauth.pelith.com/ https://forum.hakka.finance\ndemo: https://eauth.pelith.com/\nDiscourse + Eauth prototype: https://discourse-ens.pelith.com/\n\n post by vbuterin on May 10, 2020\n\n vbuterin\n\n I definitely like eauth!\n\n post by gkapkowski on May 13, 2020\n\n gkapkowski\n\n Hi, I’ve build Cryptoauth and I have working plugin for discord that enabled authentication with Ethereum address. Let me know if you would be interested in experimenting with it.\nWorking example: https://community.cryptoverse.cc/\nIt also has ability to limit logins to only those addresses that hold certain tokens. Example: https://marketpunks.cryptoverse.cc/\n\n post by gkapkowski on May 13, 2020\n\n gkapkowski\n\n @Ping nice work with Eauth! I would love Cryptoauth to look like this \nI’m also the person behind ETHMail so if you need something done with it let me know \n\n post by gkapkowski on May 13, 2020\n\n gkapkowski\n\n You can find cryptoauth.io discord plugin at https://github.com/CryptoverseCC/discourse-openid-connect It’s a fork that creates users in the background instead of asking people to confirm creating users.\n\n 1 year later\n\n post by x on Oct 22, 2021\n\n x\n\n Just found this discussion and realized that it’s related to my thread here: Somewhat time critical — How do I set a password?\nIn my opinion, it’s not a good idea to restrict people to GitHub OAuth, and I explain in detail why that is in the thread above.\nBesides, some people just don’t feel comfortable using GitHub and instead use self-hosted repositories or codeberg.org. We shouldn’t force those people to sign up for a website that they don’t feel comfortable using.\n\n Powered by Discourse","tokens":1516,"squid":"spider-04","role":"Research Spider","at":1791344804590,"hash":"535412632da3f82eff5a450ed7ac65c227547165"}
{"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:What hard drive storage is required for an Ethereum node?","tokens":1990,"squid":"spider-05","role":"Spec Spider","at":1791344804638,"hash":"2a8f3427c0e75e484dae4f6b5e377172a13eeb5e"}
{"url":"https://www.metaplex.com/docs/smart-contracts/core/what-is-an-asset","domain":"metaplex.com","title":"What is a Core Asset | Metaplex Core","text":"This page explains what a Core Asset is and how it differs from traditional Solana NFTs. Understand the account structure, collection relationships, and metadata storage. Key ConceptsSingle-account model: Core Assets store ownership within the Asset account itselfNo token accounts: Unlike SPL tokens, Core doesn't require Associated Token AccountsCollection membership: Assets can belong to Collections via the updateAuthority fieldOff-chain metadata: A URI points to JSON metadata (permanent storage like Arweave/IPFS is recommended)SummaryA Core Asset is a single Solana account that represents an NFT. Unlike Token Metadata (which requires 3+ accounts), Core stores all essential data in one account: owner, name, URI, and update authority. This makes Core Assets ~80% cheaper and simpler to work with.OverviewSetting itself apart from existing Asset programs, like Solana’s Token program, Metaplex Core and Core Assets (sometimes referred to as Core NFT Assets) do not rely on multiple accounts, like Associated Token Accounts. Instead, Core Assets store the relationship between a wallet and the \"mint\" account within the asset itself.Wallet AccountOwner: System ProgramSomeone's wallet.Asset AccountOwner: Core ProgramStores information about the asset, including the ownerReact FlowPress enter or space to select a node.You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel. Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.The Core Asset AccountThe Core Asset account represents the bare minimum data for a digital asset. This structure provides an unopinionated blockchain primitive for onchain ownership.Wallet AccountOwner: System ProgramAsset AccountOwner: Core ProgramKey = AssetOwnerUpdate AuthorityNameURIReact FlowPress enter or space to select a node.You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel. Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.Is my Asset in a Collection?MPL Core Assets can belong to collections. The updateAuthority field in the MPL Core Asset data provides two duties, either to report the update authority of the Asset, or to provide the publicKey of the MPL Core Collection to which it belongs. When accessing the updateAuthority field either directly via the asset, or via the collectionAddress helper of the MPL Core Asset, the returning result will be one of the following outcomes: Collection The asset belongs to the collection at the given address.Create Asset{\n __kind: 'Collection'\n fields: [PublicKey]\n}\nimport { fetchAssetV1 } from '@metaplex-foundation/mpl-core'\nconst asset = await fetchAssetV1(umi, assetAddress.publicKey)\nconst collectionId = collectionAddress(asset)\nconsole.log({collectionId})\nconsole.log({asset})\n// log\ncollection: '2222222222222222222222222222222'\nasset: {\n key: AssetV1,\n owner: \"11111111111111111111111111111111\",\n updateAuthority: {\n type: 'Collection',\n address: '2222222222222222222222222222222'\n },\n name: \"My Core Asset\",\n uri: \"https://example.com/metadata.json\",\n ...\n}\nAddress The asset has an update authority set and does not belong to a collection.Create Assetimport { fetchAssetV1 } from '@metaplex-foundation/mpl-core'\nconst asset = await fetchAssetV1(umi, assetAddress.publicKey)\nconst collectionId = collectionAddress(asset)\nconsole.log({collectionId})\nconsole.log({asset})\n// log\ncollectionId: undefined\nasset: {\n key: AssetV1,\n owner: \"11111111111111111111111111111111\",\n updateAuthority: {\n type: 'Address',\n address: '2222222222222222222222222222222'\n }\n name: \"My Core Asset\",\n uri: \"https://example.com/metadata.json\",\n ...\n}\nNone The asset has no update authority set.Create Assetimport { fetchAssetV1 } from '@metaplex-foundation/mpl-core'\nconst asset = await fetchAssetV1(umi, assetAddress.publicKey)\nconst collectionId = collectionAddress(asset)\nconsole.log({collectionId})\nconsole.log({asset})\n// log\ncollectionId: undefined\nasset: {\n key: AssetV1,\n owner: \"11111111111111111111111111111111\",\n updateAuthority: {\n type: 'None',\n },\n name: \"My Core Asset\",\n uri: \"https://example.com/metadata.json\",\n}\nOff Chain MetadataOne important attribute of the Asset Account is the URI attribute that points to a JSON file off-chain. This is used to safely provide additional data whilst not being constrained by the fees involved in storing onchain data. That JSON file follows a certain standard that anyone can use to find useful information on tokens. Off Chain Metadata can be stored at any publicly accessible location. Popular places to host your json files include;ArweaveNFT.Storage/IPFSAmazon AWS S3/Google CloudWallet AccountOwner: System ProgramAsset AccountOwner: Core ProgramKey = AssetOwnerUpdate AuthorityNameURIOff-chain JSON MetadataNameDescriptionImageAnimated URLAttributes...React FlowPress enter or space to select a node.You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel. Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.FieldTypeDescriptionnamestringName of the asset.descriptionstringDescription of the asset.imagestringURI pointing to the asset's logo.animation_urlstringURI pointing to the asset's animation.external_urlstringURI pointing to an external URL defining the asset — e.g. the game's main site.attributesarrayArray of attributes defining the characteristics of the asset.trait_type (string): The type of attribute.value (string): The value for that attribute.propertiesobjectAdditional properties that define the asset.files (array): Additional files to include with the asset.uri (string): The file's URI.type (string): The file's type. E.g. image/png, video/mp4, etc.cdn (boolean, optional): Whether the file is served from a CDN.category (string): A media category for the asset. E.g. video, image, etc.Note that, this JSON file can be stored using a permanent storage solution such as Arweave to ensure it cannot be updated. Additionally, one can set the Update Authority field to None to make it immutable and, therefore, forbid the URI and Name attributes to ever be changed. Using this combination, we can guarantee the immutability of the off-chain JSON file.FAQHow is Core different from Token Metadata NFTs?Token Metadata requires 3+ accounts (mint, metadata, token account). Core uses a single account that stores owner and metadata together. This makes Core ~80% cheaper and faster to create.What data is stored on-chain vs off-chain?On-chain: owner, name, URI, update authority, plugins. Off-chain (at the URI): description, image, attributes, animation URL, and other extended metadata.Can I convert a Token Metadata NFT to Core?Not directly. Core and Token Metadata are separate standards. You would need to burn the old NFT and mint a new Core Asset. Some migration tools exist to help with this process.Is Core compatible with existing NFT marketplaces?Most major Solana marketplaces support Core Assets. Check Ecosystem Support for the current list of compatible platforms.What happens if the off-chain metadata goes offline?The Asset still exists on-chain with its name and URI, but the image and off-chain attributes won't be accessible. On-chain attributes (via the Attributes plugin) remain accessible. Use permanent storage (Arweave, IPFS with pinning) to prevent this.GlossaryTermDefinitionAssetA single Core account representing an NFTOwnerThe wallet that currently owns the AssetUpdate AuthorityThe account authorized to modify Asset metadataURIURL pointing to off-chain JSON metadataCollectionA Core account that groups related AssetsKeyAccount discriminator identifying the account typeseqSequence number used for compression indexingAsset Signer PDAA separate address derived from an Asset that acts as the Asset's wallet for SOL and tokens","tokens":1979,"squid":"dotcat","role":"Tooling Spider","at":1791344808255,"hash":"80c48c51ddc75caed9df56ea1c45bd625b7904fe"}
{"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":"spider-05","role":"Spec Spider","at":1791344814741,"hash":"831253e961fe854145f08c0ebac3975aea03ecad"}
{"url":"https://ethresear.ch/t/ethresear-ch-email-login-will-be-disabled-in-7-days/7369/3","domain":"ethresear.ch","title":"Ethresear.ch: email login will be disabled in 7 days - 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 3\n\n 3\n\n 2\n\n May 2020\n\n 3 / 16\n\n May 2020\n\n Oct 2021\n\n post by hwwhww on May 8, 2020\n\n hwwhww\n\n Thank you for using etheresear.ch forum!\nEmail login was enabled during the last time we restored the system. To mitigate spam and impersonator attacks, we decide to disable email login again and you can only log in with GitHub account.\nIf you were using email login, don’t worry! Please register a GitHub account with the same email to log in ethresear.ch, your previous posts and account content would remain unchanged.\nThanks.\n\n Somewhat time critical — How do I set a password?\n\n 4\n\n 3\n\n 3\n\n 2\n\n Pinned globally on May 8, 2020\n\n post by vbuterin on May 8, 2020\n\n vbuterin\n\n Should we just dogfood and enable logging in with an ethereum account? I remember @virgil or @Ping had a prototype for log-in-with-ETH on discourse?\n\n post by hwwhww on May 8, 2020\n\n hwwhww\n\n It’s still on our radar! I think one of pending issues that @virgil wanted to solve with ENS team is how to handle ENS transfer for authorization on discourse side, or even on ENS side.\nA future issue is how the merge people’s current discourse account and new Eauth login account gracefully.\nInteresting issues, we can introduce Eauth now if we sacrifice some (?) UX though.\n\n post by axic on May 8, 2020\n\n axic\n\n Just as discourse supports linking and login via Github, cannot the eauth login be added optionally, so that both github and eauth work at the same time?\n\n post by hwwhww on May 8, 2020\n\n hwwhww\n\n We can have multiple authorization options at the same time.\nIf we have both email login and GitHub oauth (as status-quo), and they can be merged together automatically well since the GitHub account identifier is the email you used to register GitHub account.\nBut for Eauth case, since you don’t register your Ethereum address / ENS with an email address, it will create a new discourse account when you use Eauth login. (@Ping please correct me if I’m wrong!)\n\n post by axic on May 8, 2020\n\n axic\n\nI see. But wouldn’t it be possible to add a field for “ENS name” in discourse (like now there’s the email field + github link) so the linking happens?\nAlternatively (though I am not a big fan due to the privacy aspect) EIP-634 could be used to link an ENS record to an email.\n\n post by kmichel on May 9, 2020\n\n kmichel\n\n Successfully logged in with it.\n\n post by vbuterin on May 9, 2020\n\n vbuterin\n\n axic\n\nBy ENS transfer you mean what happens if an ENS name is transferred to another account? Wouldn’t the natural answer be “well, for future logins start verifying signatures against that new account instead of the current one”? What’s the problem?\n\n post by hwwhww on May 9, 2020\n\n hwwhww\n\nI believe we can add ENS name (or, ETH account) field in discourse. And then, we need to ask the GitHub login user to manually update that field to claim that “the one who has this ENS name / ETH account is me”. So when the user uses Eauth login later, it will be able to bind to the existing account.\n\nRight, adding the email field in ENS can also solve the password recovery issue on discourse! I understand why we may be against it, we are trying to dogfood with a decentralized solution, but we still want the email system to prevent a user from losing their properties forever. \n\nYes.\n\nI think the authentication follows the authorized controller of the ENS name, and use ENS name as the default handle name? It doesn’t take ENS as the first-class when searching for an associated account (ping @Ping to verify it).\n\n Somewhat time critical — How do I set a password?\n\n post by Ping on May 9, 2020\n\n Ping\n\n @virgil suggests that we can use ethmail.cc by default, but at present ethmail seems not so well functioned and decentralized. \nIn Eauth scenario, account address is the primary key. And for ENS you need to not only own an ENS but also set it as your address’s reverse lookup name, then it would be displayed as your nickname.\nBTW, Eauth supports contract address login with EIP1271. I highly recommend this one. You can have multiple authenticate keys, timelock, social recovery, and lots of good stuff, without overhead to the platform. \nLogin with: Gnosis safe / Argent / Authereum / Dapper / etc\ncode: GitHub - pelith/node-eauth-server: An OAuth-compatiable service based on Ethereum credentials to authenticate users on a website. See live version at https://eauth.pelith.com/ https://forum.hakka.finance\ndemo: https://eauth.pelith.com/\nDiscourse + Eauth prototype: https://discourse-ens.pelith.com/\n\n post by vbuterin on May 10, 2020\n\n vbuterin\n\n I definitely like eauth!\n\n post by gkapkowski on May 13, 2020\n\n gkapkowski\n\n Hi, I’ve build Cryptoauth and I have working plugin for discord that enabled authentication with Ethereum address. Let me know if you would be interested in experimenting with it.\nWorking example: https://community.cryptoverse.cc/\nIt also has ability to limit logins to only those addresses that hold certain tokens. Example: https://marketpunks.cryptoverse.cc/\n\n post by gkapkowski on May 13, 2020\n\n gkapkowski\n\n @Ping nice work with Eauth! I would love Cryptoauth to look like this \nI’m also the person behind ETHMail so if you need something done with it let me know \n\n post by gkapkowski on May 13, 2020\n\n gkapkowski\n\n You can find cryptoauth.io discord plugin at https://github.com/CryptoverseCC/discourse-openid-connect It’s a fork that creates users in the background instead of asking people to confirm creating users.\n\n 1 year later\n\n post by x on Oct 22, 2021\n\n x\n\n Just found this discussion and realized that it’s related to my thread here: Somewhat time critical — How do I set a password?\nIn my opinion, it’s not a good idea to restrict people to GitHub OAuth, and I explain in detail why that is in the thread above.\nBesides, some people just don’t feel comfortable using GitHub and instead use self-hosted repositories or codeberg.org. We shouldn’t force those people to sign up for a website that they don’t feel comfortable using.\n\n Powered by Discourse","tokens":1516,"squid":"spider-04","role":"Research Spider","at":1791344814871,"hash":"fe9fc4d26a035c8cfb933f5dd6acd220564fab49"}
{"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":"spider-05","role":"Spec Spider","at":1791344824675,"hash":"54b1a84e8fca56debcfaa4f1d626a84c40f9131c"}
{"url":"https://ethresear.ch/t/somewhat-time-critical-how-do-i-set-a-password/11074/6","domain":"ethresear.ch","title":"Somewhat time critical — How do I set a password? - Administrivia - Ethereum Research","text":"Administrivia\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 5\n\n 2\n\n Oct 2021\n\n 5 / 9\n\n Oct 2021\n\n Nov 2021\n\n post by x on Oct 22, 2021\n\n x\n\n This site required me to do OAuth to register. For privacy / data hygiene reasons I then removed my GitHub from this profile and de-authenticated the site in GitHub.\nNext I changed my GitHub email address and deleted the previous address. Finally I also generated a new email address for this site to then remove the final remaining link to GitHub.\nQuestion: How can I set a password on this site, such that I will be allowed to log in once my cookie expires? Can I just log in with the email that’s now in my profile, without a password?\n\n Ethresear.ch: email login will be disabled in 7 days\n\n 5\n\n 2\n\n post by hwwhww on Oct 22, 2021\n\n hwwhww\n\n Well, the main reason why we disallow email login is for mitigating spamming. GitHub account association also provides some reputation reference in R&D community. (And considering dogfooding Ethereum account login in the future)\nI don’t think you can set password now. If you want to hide your main email/GitHub info, you could register a new GitHub account for ethresear.ch.\nSorry it’s not perfect, but IMO it’s not good to enable email login in ethresear.ch.\n\n post by x on Oct 22, 2021\n\n x\n\n K … well the guys over at ethereum-magicians allow it. They also have 2FA \n\n post by pavloMandryk on Oct 22, 2021\n\n pavloMandryk\n\n Hi, this is my first reply, hope it can be helpful.\nAs @hwwhww mentioned, there is no way you can set a password; but you still can recover access to the profile after cookie expiration.\nThe way to proceed would be creating a new GitHub account for the newly set “primary email” in your forum profile. You can access your profile using those GitHub credentials. This way you didn’t need to create an extra profile and still succeed to remove any trace of your main GitHub account.\nTo achieve privacy when creating a ethresear.ch profile just use a fresh email with a fresh GitHub account.\n\n post by x on Oct 22, 2021\n\n x\n\n My session is still alive! Woohoo, clearly living on the edge here. Tbh, as some might have guessed, I didn’t really expect to receive a solution here. I just wanted to highlight that the current system seems inefficient.\nGiven how easy it is to create a separate GitHub account for registration here, what is the purpose of enforcing GitHub in the first place? If it’s for reputation purposes, then you shouldn’t be allowed to disassociate your GitHub again, and you should enforce a certain minimum GitHub account age or a certain minimum number of GitHub contributions.\nThe current system doesn’t protect us from anything. Instead, I only see negative outcomes:\n\nPeople who don’t want all their profiles across the Internet correlated are forced to go through the extra step of setting up a throwaway GitHub account (it takes time to set up and secure) — there is a reason why people set their GitHub email to private\nPeople who don’t have time to do that may need to unnecessarily sacrifice OpSec against their will\nPeople who don’t know yet what they want are by default directed into a non-privacy maximizing choice and the use of single-sign on is wrongly presented to them as a best practice (by a reputable community)\n\nGiven the increasing scrutiny from all sides, we should all try to become less traceable, not more traceable. At least, you should allow the people who care to minimize their attack surface.\n\n post by MicahZoltu on Oct 22, 2021\n\n MicahZoltu\n\n hwwhww\n\n Is the theory here to try to leverage GitHub’s spam protections? What is GitHub’s spam protection and can we just do that directly instead?\n\n post by pavloMandryk on Oct 22, 2021\n\n pavloMandryk\n\n These topics were discussed here alongside with the EAuth implementation.\n\n@hwwhww Are spamming and impersonator attacks the only reasons for disallowing email login? Did we have bad experiences with this before? How is ethereum-magicians managing these issues while allowing email login?\nI agree on maximizing non-traceability and would like to point out two more implications of the GitHub login only: UX and security.\nI believe that it is fair to say that a significant amount of potential users fall under a) don’t have an GitHub account or b) have a completely inactive GitHub account. For these users the lack of 2FA results on poor UX, of course, but also they are more likely to give up on security as they are probably less willing to set up and secure a GitHub account they don’t use.\nOn the other hand, in my personal experience as a GitHub user, the UX of the current system feels super smooth.\nThe advantages of having email login and GitHub auth would be:\n\nPrivacy for those who don’t want their profile to be associated with their GitHub.\nMore balanced UX.\n\nFor the current GitHub only system we have the following:\n\nLess privacy.\nA worst UX and security for non-GitHub-users.\nA better UX for GitHub users.\nProtection against spam and impersonator attacks.\n\nIs there a way to point to the GitHub account without using email as primary key? If this is non-trivial to make, we can’t enforce users to stick with one GitHub account since GitHub email can be changed.\n\nWhen it comes to EAuth implementation we are still facing the same privacy issues, as the idea would be enabling to sign up with ENS but requiring to associate a GitHub account with it. (Still excited about EAuth though!)\n\n post by x on Oct 22, 2021\n\n x\n\n If this is about impersonators, then the solution are cryptographic signatures, not some OAuth using some random website that some people don’t even feel comfortable using.\nYou could sign a message in your profile with GPG or you could even use an ETH key to sign it.\n\n 10 days later\n\n post by x on Nov 1, 2021\n\n x\n\n Hey friends — I can’t believe it, but I just came back after 10 days and my session is still live … ! Long live the cookies.\nSo, what did we end up with? Can this discussion be summarized as (not everyone thinks this! thank you for the constructive discussion so far):\n\nThe reason for GitHub auth is to avoid impersonation\nCryptographic signatures (OpenPGP, Minisign, ETH keys, …) would be a better solution than GitHub to verify identities/pseudonyms\nHowever, the target users of this forum don’t like using cryptographic signatures for this use case\nThus the people in this forum want to keep using GitHub to avoid impersonation\n(They don’t care that others may not like that; either because it links their accounts unnecessarily, or because they just don’t want to use GitHub)\n\n(There was more nuance, but I tried to dumb it down.)\nEDIT: By the way … thank you all for voting me “User of the Month” … I feel very honored.\nimage1038×272 29 KB\n\n Powered by Discourse","tokens":1687,"squid":"spider-04","role":"Research Spider","at":1791344825092,"hash":"119c4114402b359e3b3e940158ac2794d1a2dbd7"}
{"url":"https://www.metaplex.com/docs/smart-contracts/core/sdk/javascript","domain":"metaplex.com","title":"JavaScript SDK | Metaplex Core","text":"The Metaplex Core JavaScript SDK (@metaplex-foundation/mpl-core) provides a complete TypeScript/JavaScript interface for interacting with Core Assets and Collections on Solana. Built on the Umi framework, it offers type-safe methods for all Core operations. What You'll LearnThis SDK reference covers:Setting up Umi with the Core pluginCreating, transferring, burning, and updating AssetsManaging Collections and collection-level operationsAdding, updating, and removing PluginsFetching Assets and Collections with DASError handling and common patternsSummaryThe Core JavaScript SDK is the recommended way to interact with Metaplex Core from JavaScript/TypeScript applications. It wraps the Core program instructions in a type-safe API.Install: npm install @metaplex-foundation/mpl-core @metaplex-foundation/umiRequires Umi framework for wallet/RPC managementAll functions return transaction builders for flexible executionSupports both browser and Node.js environmentsOut of ScopeRust SDK usage (see Rust SDK), Token Metadata operations, Candy Machine integration, and low-level Solana transaction construction.Quick StartJump to: Setup · Create · Transfer · Burn · Update · Collections · Plugins · Fetch · Errors · FAQInstall dependencies: npm install @metaplex-foundation/mpl-core @metaplex-foundation/umi-bundle-defaultsCreate Umi instance with mplCore() pluginGenerate or load a signer for transactionsCall SDK functions and confirm transactionsPrerequisitesNode.js 18+ or modern browser with ES modulesUmi framework configured with RPC and signerSOL for rent and fees (~0.003 SOL per base asset; rent varies with asset size)API ReferenceFull TypeDoc API documentation for the SDK.NPM PackagePackage on npmjs.com with version history.InstallationInstall the Core SDK and Umi framework:Terminalnpm install @metaplex-foundation/mpl-core @metaplex-foundation/umi-bundle-defaults\nFor metadata uploads, add an uploader plugin:Terminalnpm install @metaplex-foundation/umi-uploader-irys\nUmi SetupCreate and configure an Umi instance with the Core plugin:setup-umi.tsimport { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\nimport { mplCore } from '@metaplex-foundation/mpl-core'\nimport { keypairIdentity } from '@metaplex-foundation/umi'\nimport { irysUploader } from '@metaplex-foundation/umi-uploader-irys'\n// Create Umi with RPC endpoint\nconst umi = createUmi('https://api.devnet.solana.com')\n .use(mplCore())\n .use(keypairIdentity(yourKeypair))\n .use(irysUploader()) // Optional: for metadata uploads\nAssetsCreate an AssetUse create() to mint a new Core Asset:1import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n2import { create } from '@metaplex-foundation/mpl-core'\n3import { mplCore } from '@metaplex-foundation/mpl-core'\n4\n5// Initialize UMI\n6const umi = createUmi('https://api.devnet.solana.com')\n7 .use(mplCore())\n8\n9// Create a new NFT asset\n10const asset = await create(umi, {\n11 name: 'My NFT',\n12 uri: 'https://example.com/metadata.json'\n13}).sendAndConfirm(umi)\n14\n15console.log('Asset created:', asset.publicKey)\nTransfer an AssetUse transfer() to send an Asset to another wallet:1import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n2import { transfer } from '@metaplex-foundation/mpl-core'\n3import { mplCore } from '@metaplex-foundation/mpl-core'\n4import { publicKey } from '@metaplex-foundation/umi'\n5\n6// Initialize UMI\n7const umi = createUmi('https://api.devnet.solana.com')\n8 .use(mplCore())\n9\n10// Transfer an existing NFT asset to a new owner\n11const result = await transfer(umi, {\n12 asset: publicKey('AssetAddressHere...'),\n13 newOwner: publicKey('RecipientAddressHere...'),\n14}).sendAndConfirm(umi)\n15\n16console.log('Asset transferred:', result.signature)\nBurn an AssetUse burn() to permanently destroy an Asset and reclaim rent:1import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n2import { burn } from '@metaplex-foundation/mpl-core'\n3import { mplCore } from '@metaplex-foundation/mpl-core'\n4import { publicKey } from '@metaplex-foundation/umi'\n5\n6const umi = createUmi('https://api.devnet.solana.com').use(mplCore())\n7const assetAddress = publicKey('AssetAddressHere...')\n8\n9// Permanently destroy/burn an NFT asset\n10const result = await burn(umi, {\n11 asset: assetAddress,\n12}).sendAndConfirm(umi)\n13\n14console.log('Asset burned successfully')\nWithdraw Asset Signer balances firstBurning the Asset makes execute fail. SOL, tokens, or other assets still held by the Asset Signer PDA become stranded.Update an AssetUse update() to modify Asset metadata:1import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n2import { update } from '@metaplex-foundation/mpl-core'\n3import { mplCore } from '@metaplex-foundation/mpl-core'\n4import { publicKey } from '@metaplex-foundation/umi'\n5\n6const umi = createUmi('https://api.devnet.solana.com').use(mplCore())\n7const assetAddress = publicKey('AssetAddressHere...')\n8\n9// Update an existing NFT asset's metadata\n10const result = await update(umi, {\n11 asset: assetAddress,\n12 name: 'Updated NFT Name',\n13 uri: 'https://updated-example.com/metadata.json',\n14}).sendAndConfirm(umi)\n15\n16console.log('Asset updated successfully')\nCollectionsCreate a CollectionUse createCollection() to create a Collection account:1import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n2import { createCollection } from '@metaplex-foundation/mpl-core'\n3import { mplCore } from '@metaplex-foundation/mpl-core'\n4import { generateSigner } from '@metaplex-foundation/umi'\n5\n6// Initialize UMI\n7const umi = createUmi('https://api.devnet.solana.com')\n8 .use(mplCore())\n9\n10// Generate a new keypair for the collection\n11const collectionSigner = generateSigner(umi)\n12\n13// Create a new Collection\n14await createCollection(umi, {\n15 collection: collectionSigner,\n16 name: 'My Collection',\n17 uri: 'https://example.com/collection.json',\n18}).sendAndConfirm(umi)\n19\n20console.log('Collection created:', collectionSigner.publicKey)\nCreate Asset in CollectionPass the collection parameter to create():1import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n2import { create, fetchCollection } from '@metaplex-foundation/mpl-core'\n3import { mplCore } from '@metaplex-foundation/mpl-core'\n4import { generateSigner, publicKey } from '@metaplex-foundation/umi'\n5\n6// Initialize UMI\n7const umi = createUmi('https://api.devnet.solana.com')\n8 .use(mplCore())\n9\n10const collectionAddress = publicKey('YOUR_COLLECTION_ADDRESS')\n11\n12// Fetch the existing collection\n13const collection = await fetchCollection(umi, collectionAddress)\n14\n15// Generate a new keypair for the asset\n16const assetSigner = generateSigner(umi)\n17\n18// Create asset in the collection\n19await create(umi, {\n20 asset: assetSigner,\n21 collection,\n22 name: 'Collection Item #1',\n23 uri: 'https://example.com/item1.json',\n24}).sendAndConfirm(umi)\n25\n26console.log('Asset created in collection:', assetSigner.publicKey)\nPluginsPlugins add behavior to Assets and Collections. They can be added at creation time or afterwards.Add Plugin at Creation1import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n2import { create, ruleSet } from '@metaplex-foundation/mpl-core'\n3import { mplCore } from '@metaplex-foundation/mpl-core'\n4import { generateSigner, publicKey } from '@metaplex-foundation/umi'\n5\n6// Initialize UMI\n7const umi = createUmi('https://api.devnet.solana.com')\n8 .use(mplCore())\n9\n10const creator = publicKey('YOUR_CREATOR_ADDRESS')\n11\n12// Generate a new keypair for the asset\n13const assetSigner = generateSigner(umi)\n14\n15// Create asset with Royalties plugin\n16await create(umi, {\n17 asset: assetSigner,\n18 name: 'NFT with Royalties',\n19 uri: 'https://example.com/metadata.json',\n20 plugins: [\n21 {\n22 type: 'Royalties',\n23 basisPoints: 500, // 5%\n24 creators: [\n25 { address: creator, percentage: 100 },\n26 ],\n27 ruleSet: ruleSet('None'),\n28 },\n29 ],\n30}).sendAndConfirm(umi)\n31\n32console.log('Asset created with plugins:', assetSigner.publicKey)\nAdd Plugin to Existing Asset1import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n2import { addPlugin, fetchAsset, ruleSet } from '@metaplex-foundation/mpl-core'\n3import { mplCore } from '@metaplex-foundation/mpl-core'\n4import { publicKey } from '@metaplex-foundation/umi'\n5\n6// Initialize UMI\n7const umi = createUmi('https://api.devnet.solana.com')\n8 .use(mplCore())\n9\n10const assetAddress = publicKey('YOUR_ASSET_ADDRESS')\n11\n12// Fetch the existing asset\n13const asset = await fetchAsset(umi, assetAddress)\n14\n15// Add a Royalties plugin to the asset\n16await addPlugin(umi, {\n17 asset,\n18 plugin: {\n19 type: 'Royalties',\n20 basisPoints: 500, // 5%\n21 creators: [\n22 { address: umi.identity.publicKey, percentage: 100 },\n23 ],\n24 ruleSet: ruleSet('None'),\n25 },\n26}).sendAndConfirm(umi)\n27\n28console.log('Plugin added to asset:', assetAddress)\nCommon Plugin TypesPluginType StringPurposeRoyalties'Royalties'Creator royalty enforcementFreeze Delegate'FreezeDelegate'Allow freezing/unfreezingBurn Delegate'BurnDelegate'Allow burning by delegateTransfer Delegate'TransferDelegate'Allow transfers by delegateUpdate Delegate'UpdateDelegate'Allow metadata updatesAttributes'Attributes'On-chain key/value dataPermanent Freeze'PermanentFreezeDelegate'Permanent freeze statePermanent Transfer'PermanentTransferDelegate'Permanent transfer delegatePermanent Burn'PermanentBurnDelegate'Permanent burn delegateSee Plugins Overview for detailed plugin documentation.Fetching AssetsFetch Single Asset1import { fetchAsset, fetchCollection, mplCore } from '@metaplex-foundation/mpl-core';\n2import { publicKey } from '@metaplex-foundation/umi';\n3import { createUmi } from '@metaplex-foundation/umi-bundle-defaults';\n4\n5// Initialize UMI\n6const umi = createUmi('https://api.devnet.solana.com')\n7 .use(mplCore())\n8\n9// Fetch a Core Asset\n10const assetAddress = publicKey('AssetAddressHere...')\n11const asset = await fetchAsset(umi, assetAddress)\n12\n13// Fetch a Core Collection\n14const collectionAddress = publicKey('CollectionAddressHere...')\n15const collection = await fetchCollection(umi, collectionAddress)\n16\n17console.log('Asset fetched:', asset)\n18console.log('Name:', asset.name)\n19console.log('Owner:', asset.owner)\n20console.log('URI:', asset.uri)\n21\n22console.log('\\nCollection fetched:', collection)\n23console.log('Name:', collection.name)\n24console.log('URI:', collection.uri)\nFetch Assets by Owner (DAS)Use the DAS API to query indexed assets:fetch-by-owner.tsimport { publicKey } from '@metaplex-foundation/umi'\nimport { dasApi } from '@metaplex-foundation/digital-asset-standard-api'\n// Add DAS plugin to Umi\nconst umi = createUmi('https://api.devnet.solana.com')\n .use(mplCore())\n .use(dasApi())\nconst owner = publicKey('OwnerAddressHere...')\nconst assets = await umi.rpc.getAssetsByOwner({\n owner,\n limit: 100,\n})\nconsole.log('Assets owned:', assets.items.length)\nFetch Assets by Collection (DAS)fetch-by-collection.tsimport { publicKey } from '@metaplex-foundation/umi'\nconst collectionAddress = publicKey('CollectionAddressHere...')\nconst assets = await umi.rpc.getAssetsByGroup({\n groupKey: 'collection',\n groupValue: collectionAddress,\n limit: 100,\n})\nconsole.log('Collection assets:', assets.items.length)\nUploading MetadataUse Umi's uploader plugins to store metadata JSON:upload-metadata.tsimport { irysUploader } from '@metaplex-foundation/umi-uploader-irys'\nconst umi = createUmi('https://api.devnet.solana.com')\n .use(mplCore())\n .use(keypairIdentity(yourKeypair))\n .use(irysUploader())\n// Upload image first\nconst imageFile = await fs.promises.readFile('image.png')\nconst [imageUri] = await umi.uploader.upload([imageFile])\n// Upload metadata JSON\nconst uri = await umi.uploader.uploadJson({\n name: 'My NFT',\n description: 'An awesome NFT',\n image: imageUri,\n attributes: [\n { trait_type: 'Background', value: 'Blue' },\n { trait_type: 'Rarity', value: 'Rare' },\n ],\n})\nconsole.log('Metadata URI:', uri)\nTransaction PatternsSend and ConfirmThe standard pattern waits for confirmation:send-confirm.tsconst result = await create(umi, { asset, name, uri }).sendAndConfirm(umi)\nconsole.log('Signature:', result.signature)\nCustom Confirmation Optionscustom-confirm.tsconst result = await create(umi, { asset, name, uri }).sendAndConfirm(umi, {\n confirm: { commitment: 'finalized' },\n})\nBuild Transaction Without Sendingbuild-only.tsconst tx = create(umi, { asset, name, uri })\nconst builtTx = await tx.buildAndSign(umi)\n// Send later with: await umi.rpc.sendTransaction(builtTx)\nCombine Multiple Instructionscombine-instructions.tsimport { transactionBuilder } from '@metaplex-foundation/umi'\nconst tx = transactionBuilder()\n .add(create(umi, { asset: asset1, name: 'NFT 1', uri: uri1 }))\n .add(create(umi, { asset: asset2, name: 'NFT 2', uri: uri2 }))\nawait tx.sendAndConfirm(umi)\nCommon ErrorsAccount does not existThe asset or collection address doesn't exist. Verify the address is correct:const asset = await fetchAsset(umi, assetAddress).catch(() => null)\nif (!asset) {\n console.log('Asset not found')\n}\nInvalid authorityYou're not authorized to perform this action. Check that:You own the asset (for transfers, burns)You're the update authority (for updates)You have the required delegate permissionInsufficient fundsYour wallet needs more SOL. Fund it with:solana airdrop 1 <WALLET_ADDRESS> --url devnet\nAsset already existsThe asset keypair was already used. Generate a new signer:const assetSigner = generateSigner(umi) // Must be unique\nPlugin not foundThe plugin doesn't exist on this asset. Check installed plugins:const asset = await fetchAsset(umi, assetAddress)\nconsole.log('Plugins:', Object.keys(asset))\nNotesAlways use a new keypair for new assets - never reuse keypairsThe asset parameter in create() must be a signer, not just a public keyCollection-level plugins override asset-level plugins of the same typeUse commitment: 'finalized' when creating assets that you immediately fetchTransaction builders are immutable - each method returns a new builderEmpty the Asset Signer PDA before burn() — remaining balances cannot be moved afterwardQuick ReferenceMinimum Dependenciespackage.json{\n \"dependencies\": {\n \"@metaplex-foundation/mpl-core\": \"^1.0.0\",\n \"@metaplex-foundation/umi\": \"^0.9.0\",\n \"@metaplex-foundation/umi-bundle-defaults\": \"^0.9.0\"\n }\n}\nCore FunctionsFunctionPurposecreate()Create a new AssetcreateCollection()Create a new Collectiontransfer()Transfer Asset ownershipburn()Destroy an Assetupdate()Update Asset metadataupdateCollection()Update Collection metadataaddPlugin()Add plugin to AssetaddCollectionPlugin()Add plugin to CollectionupdatePlugin()Update existing pluginremovePlugin()Remove plugin from AssetfetchAsset()Fetch Asset by addressfetchCollection()Fetch Collection by addressProgram IDNetworkAddressMainnetCoREENxT6tW1HoK8ypY1SxRMZTcVPm7R94rH4PZNhX7dDevnetCoREENxT6tW1HoK8ypY1SxRMZTcVPm7R94rH4PZNhX7dFAQWhat is the Core JavaScript SDK?The Core JavaScript SDK (@metaplex-foundation/mpl-core) is a TypeScript library for interacting with Metaplex Core NFTs on Solana. It provides type-safe functions for creating, transferring, burning, and managing Assets and Collections.Do I need Umi to use this SDK?Yes. The Core SDK is built on the Umi framework, which handles wallet connections, RPC communication, and transaction building. Install both @metaplex-foundation/mpl-core and @metaplex-foundation/umi-bundle-defaults.How do I connect a browser wallet?Use the @metaplex-foundation/umi-signer-wallet-adapters package with your wallet adapter:import { walletAdapterIdentity } from '@metaplex-foundation/umi-signer-wallet-adapters'\numi.use(walletAdapterIdentity(wallet))\nWhat's the difference between sendAndConfirm and send?sendAndConfirm() waits for transaction confirmation before returning. send() returns immediately after broadcasting. Use sendAndConfirm() for most cases to ensure your transaction succeeded.How do I batch multiple operations?Use transactionBuilder() to combine instructions, but be aware of Solana's transaction size limits (~1232 bytes). For large batches, send multiple transactions.Can I use this SDK in React/Next.js?Yes. The SDK works in both browser and Node.js environments. For React, use wallet adapters from @solana/wallet-adapter-react with Umi's wallet adapter identity.How do I handle errors?Wrap SDK calls in try/catch blocks. The SDK throws typed errors that include program error codes:try {\n await transfer(umi, { asset, newOwner }).sendAndConfirm(umi)\n} catch (error) {\n console.error('Transfer failed:', error.message)\n}\nWhere can I find the full API documentation?See the TypeDoc API Reference for complete function signatures and types.GlossaryTermDefinitionUmiMetaplex's framework for building Solana applications with wallet and RPC managementAssetA Core on-chain account representing an NFT with ownership, metadata, and pluginsCollectionA Core account that groups related Assets and can apply collection-wide pluginsSignerA keypair that can sign transactions (required for creating new accounts)PluginA modular extension that adds behavior to Assets or CollectionsURIThe off-chain metadata URL pointing to a JSON file with name, image, and attributesDASDigital Asset Standard - API for querying indexed NFT data from RPC providersTransaction BuilderAn immutable object that constructs transactions before sendingIdentityThe wallet/keypair configured as the transaction signer in UmiCommitmentSolana confirmation level (processed, confirmed, finalized)","tokens":4361,"squid":"dotcat","role":"Tooling Spider","at":1791344840287,"hash":"cc44cbddab1c107517f841604dde068231a43934"}
{"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":"spider-05","role":"Spec Spider","at":1791344846768,"hash":"58e8887d56300d423360204e16b15207d3d03deb"}
{"url":"https://www.metaplex.com/docs/smart-contracts/core/faq","domain":"metaplex.com","title":"FAQ | Core","text":"Why does the Core Asset and Collection accounts have both onchain and off-chain data?The Core Asset and Collection accounts both contain onchain data, yet both also include a URI attribute that points to an off-chain JSON file which provides additional data. Why is that? Can't we just store everything onchain? Well, there are several issues with storing data onchain:Storing data onchain requires paying rent. If we had to store everything within the Asset or Collection account, which may include long texts such as the description of an asset, it would require a lot more bytes and creating an Asset would suddenly be a lot more expensive, since storing more bytes means more rent has to be paidonchain data is less flexible. Once an account state is created using a certain byte structure it cannot easily be changed without potentially causing deserialization issues. Therefore, if we had to store everything onchain, the standard would be a lot harder to evolve with the demands of the ecosystem. Therefore, splitting the data into onchain and off-chain data allows users to get the best of both worlds where onchain data can be used by the program to create guarantees and expectations for its users and off-chain data can be used to provide standardized yet flexible information. But don't worry, if you want data entirely on chain Metaplex also offers Inscriptions for this purpose.Are there any costs to using Core?Core currently charges a very small fee of 0.0015 SOL per Asset mint to the caller, plus a small fee on each execute call paid by the Asset owner. More details can be found on the Protocol Fees page.Can I store SOL on a Core Asset account?No. The Core program treats every lamport above the rent-exempt minimum on an Asset account as a protocol fee, and the Metaplex fee collector sweeps only the amount above that minimum, leaving the rent-exempt balance in the account. SOL sent to an Asset address will be collected and cannot be recovered. To give an Asset a wallet, send funds to its Asset Signer PDA, which is a separate address derived from the Asset and controlled through the execute instruction.How to create a Soulbound Asset?The Core Standard allows you to create Soulbound Assets. To achieve this either the Permanent Freeze Delegate plugin or the Oracle Plugin can be used. To learn more check out the Soulbound Assets Guide!How to set an Asset to be Immutable?There are multiple levels of \"immutability\" in Core. You can find more information and how to implement it in this guide.What are the differences between Metaplex Token Metadata and Core?Core is an entirely new standard designed specifically for NFTs, hence there are several notable differences. For example Core is cheaper, requires less Compute Units and should be easier to work with from a developer perspective. Have a look at the differences page for details.Does Core Support Editions?Yes! Using the Edition and Master Edition Plugins. You can find more information in the \"How to print Editions\" Guide.What happens to funds in the Asset Signer PDA if I burn the Asset?execute fails after burn, so SOL, tokens, and nested assets left in the Asset Signer PDA are stranded. Withdraw them first.","tokens":800,"squid":"dotcat","role":"Tooling Spider","at":1791344852691,"hash":"f4c3f9ae7b5eac4833055f88973ceccf43991a03"}
{"url":"https://developers.jup.ag/docs/swap/order-and-execute","domain":"developers.jup.ag","title":"Order & Execute - Jupiter Developers","text":"The Meta-Aggregator is the recommended way to swap on Jupiter. All routing engines compete for the best price (Metis, JupiterZ RFQ, Dflow, OKX), and Jupiter handles transaction landing for you via /order + /execute.\n​Quick start\nThree steps: get an order, sign it, execute it.\n​Prerequisites\nLoading a wallet for testingThere are several ways to load a wallet for testing. All examples on this page use BS58_PRIVATE_KEY from your .env file.// .env: BS58_PRIVATE_KEY=your_base58_secret_key\n\n// @solana/kit\nimport { createKeyPairSignerFromBytes, getBase58Encoder } from \"@solana/kit\";\nconst signer = await createKeyPairSignerFromBytes(\n getBase58Encoder().encode(process.env.BS58_PRIVATE_KEY!),\n);\n\n// @solana/web3.js\nimport { Keypair } from \"@solana/web3.js\";\nimport bs58 from \"bs58\";\nconst signer = Keypair.fromSecretKey(bs58.decode(process.env.BS58_PRIVATE_KEY!));\nimport fs from \"fs\";\n\n// @solana/kit\nimport { createKeyPairSignerFromBytes } from \"@solana/kit\";\nconst keyfileBytes = JSON.parse(\n fs.readFileSync(\"/path/to/.config/solana/id.json\", \"utf8\"),\n);\nconst signer = await createKeyPairSignerFromBytes(\n new Uint8Array(keyfileBytes),\n);\n\n// @solana/web3.js\nimport { Keypair } from \"@solana/web3.js\";\nconst keyfileBytes = JSON.parse(\n fs.readFileSync(\"/path/to/.config/solana/id.json\", \"utf8\"),\n);\nconst signer = Keypair.fromSecretKey(new Uint8Array(keyfileBytes));\n// @solana/kit\nimport { createKeyPairSignerFromBytes } from \"@solana/kit\";\nconst signer = await createKeyPairSignerFromBytes(\n new Uint8Array([/* 64 bytes */]),\n);\n\n// @solana/web3.js\nimport { Keypair } from \"@solana/web3.js\";\nconst signer = Keypair.fromSecretKey(new Uint8Array([/* 64 bytes */]));\nNever commit private keys to source control. Use environment variables or the Solana CLI keyfile for testing. In production, use a proper key management solution.\nImports, types, and constantsimport {\n createKeyPairSignerFromBytes,\n getBase58Encoder,\n getTransactionDecoder,\n getTransactionEncoder,\n partiallySignTransaction,\n} from \"@solana/kit\";\n\ntype OrderResponse = {\n transaction: string | null; // base64-encoded transaction, null if no taker, \"\" if quote-only\n requestId: string;\n outAmount: string;\n router: string; // \"metis\" | \"jupiterz\" | \"dflow\" | \"okx\"\n mode: string; // \"ultra\" | \"manual\"\n feeBps: number;\n feeMint: string;\n errorCode?: number; // present when transaction is \"\"\n errorMessage?: string; // present when transaction is \"\"\n};\n\ntype ExecuteResponse = {\n status: \"Success\" | \"Failed\";\n signature: string;\n code: number;\n totalInputAmount: string;\n totalOutputAmount: string;\n inputAmountResult: string;\n outputAmountResult: string;\n error?: string;\n};\n\nconst API_KEY = process.env.JUPITER_API_KEY;\nif (!API_KEY) throw new Error(\"Missing JUPITER_API_KEY\");\nconst BASE_URL = \"https://api.jup.ag/swap/v2\";\n\n// Load wallet from base58 secret key in .env\nconst signer = await createKeyPairSignerFromBytes(\n getBase58Encoder().encode(process.env.BS58_PRIVATE_KEY!),\n);\nimport { Keypair, VersionedTransaction } from \"@solana/web3.js\";\nimport bs58 from \"bs58\";\n\ntype OrderResponse = {\n transaction: string | null; // base64-encoded transaction, null if no taker, \"\" if quote-only\n requestId: string;\n outAmount: string;\n router: string; // \"metis\" | \"jupiterz\" | \"dflow\" | \"okx\"\n mode: string; // \"ultra\" | \"manual\"\n feeBps: number;\n feeMint: string;\n errorCode?: number; // present when transaction is \"\"\n errorMessage?: string; // present when transaction is \"\"\n};\n\ntype ExecuteResponse = {\n status: \"Success\" | \"Failed\";\n signature: string;\n code: number;\n totalInputAmount: string;\n totalOutputAmount: string;\n inputAmountResult: string;\n outputAmountResult: string;\n error?: string;\n};\n\nconst API_KEY = process.env.JUPITER_API_KEY;\nif (!API_KEY) throw new Error(\"Missing JUPITER_API_KEY\");\nconst BASE_URL = \"https://api.jup.ag/swap/v2\";\n\n// Load wallet from base58 secret key in .env\nconst signer = Keypair.fromSecretKey(\n bs58.decode(process.env.BS58_PRIVATE_KEY!),\n);\n\n​Code example\n// Step 1: Get an order\nconst orderResponse = await fetch(\n `${BASE_URL}/order?` +\n new URLSearchParams({\n inputMint: \"So11111111111111111111111111111111111111112\", // SOL\n outputMint: \"EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v\", // USDC\n amount: \"100000000\",\n taker: signer.address,\n }),\n { headers: { \"x-api-key\": API_KEY } },\n);\nif (!orderResponse.ok) {\n console.error(`/order failed: ${orderResponse.status}`, await orderResponse.text());\n process.exit(1);\n}\nconst order: OrderResponse = await orderResponse.json();\n\nif (!order.transaction) {\n console.error(\"No transaction in response:\", JSON.stringify(order, null, 2));\n process.exit(1);\n}\n\n// Step 2: Sign the transaction\n// Use partiallySignTransaction because JupiterZ quotes require an additional\n// market maker signature, which is added during /execute\nconst transactionBytes = Buffer.from(order.transaction, \"base64\");\nconst transaction = getTransactionDecoder().decode(transactionBytes);\nconst signedTransaction = await partiallySignTransaction(\n [signer.keyPair],\n transaction,\n);\n\n// Step 3: Execute\nconst signedTxBytes = getTransactionEncoder().encode(signedTransaction);\nconst signedTxBase64 = Buffer.from(signedTxBytes).toString(\"base64\");\n\nconst executeResponse = await fetch(`${BASE_URL}/execute`, {\n method: \"POST\",\n headers: {\n \"Content-Type\": \"application/json\",\n \"x-api-key\": API_KEY,\n },\n body: JSON.stringify({\n signedTransaction: signedTxBase64,\n requestId: order.requestId,\n }),\n});\nif (!executeResponse.ok) {\n console.error(`/execute failed: ${executeResponse.status}`, await executeResponse.text());\n process.exit(1);\n}\nconst result: ExecuteResponse = await executeResponse.json();\n\nconsole.log(`https://solscan.io/tx/${result.signature}`);\nif (result.status === \"Success\") {\n console.log(\"Swap successful:\", JSON.stringify(result, null, 2));\n} else {\n console.error(\"Swap failed:\", JSON.stringify(result, null, 2));\n}\n// Step 1: Get an order\nconst orderResponse = await fetch(\n `${BASE_URL}/order?` +\n new URLSearchParams({\n inputMint: \"So11111111111111111111111111111111111111112\", // SOL\n outputMint: \"EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v\", // USDC\n amount: \"100000000\",\n taker: signer.publicKey.toString(),\n }),\n { headers: { \"x-api-key\": API_KEY } },\n);\nif (!orderResponse.ok) {\n console.error(`/order failed: ${orderResponse.status}`, await orderResponse.text());\n process.exit(1);\n}\nconst order: OrderResponse = await orderResponse.json();\n\nif (!order.transaction) {\n console.error(\"No transaction in response:\", JSON.stringify(order, null, 2));\n process.exit(1);\n}\n\n// Step 2: Sign the transaction\nconst transaction = VersionedTransaction.deserialize(\n Buffer.from(order.transaction, \"base64\"),\n);\ntransaction.sign([signer]);\n\n// Step 3: Execute\nconst signedTransaction = Buffer.from(transaction.serialize()).toString(\"base64\");\n\nconst executeResponse = await fetch(`${BASE_URL}/execute`, {\n method: \"POST\",\n headers: {\n \"Content-Type\": \"application/json\",\n \"x-api-key\": API_KEY,\n },\n body: JSON.stringify({\n signedTransaction,\n requestId: order.requestId,\n }),\n});\nif (!executeResponse.ok) {\n console.error(`/execute failed: ${executeResponse.status}`, await executeResponse.text());\n process.exit(1);\n}\nconst result: ExecuteResponse = await executeResponse.json();\n\nconsole.log(`https://solscan.io/tx/${result.signature}`);\nif (result.status === \"Success\") {\n console.log(\"Swap successful:\", JSON.stringify(result, null, 2));\n} else {\n console.error(\"Swap failed:\", JSON.stringify(result, null, 2));\n}\n\n​How it works\n​1. Get an order\nGET /order returns a quote and an assembled transaction in a single call. All routers compete for the best price: Metis, JupiterZ, Dflow, and OKX.\nAdding optional parameters to /order (such as fee or slippage overrides) may restrict routing. See the routing impact matrix below for details.\nRequired parameters:\nParameterDescriptioninputMintMint address of the token you are sellingoutputMintMint address of the token you are buyingamountAmount in the smallest unit of the input tokentakerYour wallet address. Required to receive an assembled transaction.Without taker, you get a quote but no transaction. This is useful for price checks.\nTo accept a Solana v1 transaction, pass maxSupportedTransactionVersion=1 (\"0\" or \"1\", default \"0\"). This is a ceiling, not a force: you get v1 only when Metis wins the route and the order is not gasless. Other routers and gasless orders (including automatic sponsorship for low-SOL takers) return v0, and wider v1 support is in progress. Read the response transactionVersion to see what you got, and deserialize accordingly. /execute lands either version.\nKey response fields:\nFieldDescriptiontransactionBase64-encoded transaction to sign. Null if taker is not set. Empty string (\"\") if the router could quote a price but could not build a transaction (check errorCode).requestIdPass this to /execute.outAmountExpected output amount before slippage.routerWhich router won the quote (metis, jupiterz, dflow, okx).transactionVersionThe message version of transaction, 0 or 1. With maxSupportedTransactionVersion=1 this is 1 only when Metis wins and the order is not gasless, and 0 otherwise.mode”ultra” (no optional params) or “manual” (optional params used).errorCodePresent when transaction is \"\". Match on router + errorCode. See /order error codes.errorMessagePresent when transaction is \"\". Human-readable description. Do not match on this string, it may be parameterised.\nWhen transaction is an empty string, the response still contains valid pricing (inAmount, outAmount) but the swap cannot proceed. Handle this in your integration:\nif (!order.transaction) {\n // Match on router + errorCode to identify the specific error\n console.error(`[${order.router}] Error ${order.errorCode}: ${order.errorMessage}`);\n // Show the quoted price to the user, but do not attempt to sign or execute\n}\n\nFor the full parameter reference, see the API reference. For how each parameter affects routing, see the routing impact matrix below.\n​Transaction validity\nSign and submit the transaction as soon as you receive it. The longer you wait, the more the quote goes stale as onchain prices move.\n\nAggregator routes (Metis, Dflow, OKX): lastValidBlockHeight in the response is the hard expiry. The transaction becomes invalid after this block height.\nRFQ routes (JupiterZ): expireAt is the quote expiry timestamp from the market maker. RFQ quotes are typically shorter-lived than aggregator quotes.\n\nThese are guidelines, not guarantees of execution. Prices can move against you even within the validity window, causing the transaction to fail due to slippage. Sign and submit immediately after receiving the order.\n​2. Sign the transaction\n\nThe transaction returned by /order is unsigned. Sign it with your wallet’s private key. The example above uses @solana/kit. The transaction is a versioned transaction, v0 by default or v1 when you request it with maxSupportedTransactionVersion=1 (check the response transactionVersion). Build and sign v1 with @solana/kit v8 or later (@solana/web3.js v1 cannot sign v1). Not all wallet extensions can sign v1 yet, so request maxSupportedTransactionVersion=1 only for wallets you have confirmed support it, otherwise signing fails. See Transaction Versions.\nNote: we use the partiallySignTransaction for partial signing because when JupiterZ routing is provided, there is an additional signer which is the MM that will be required after sending the transaction to /execute request.\n\n​3. Execute the transaction\nPOST /execute takes the signed transaction and the requestId from the order response.\n/execute has its own dedicated rate limit bucket (Keyless 20, Free 50, Paid 100 RPS), separate from your general API limit. See Rate Limits.\nJupiter handles:\n\nOptimised slippage via RTSE (Real-Time Slippage Estimator), applied at order time to balance trade success and price protection\nOptimised priority fee strategy for current network conditions\nJupiter Beam (our own proprietary transaction execution pipeline) for accelerated transaction sending and landing across multiple RPC providers\nConfirmation polling\nParses both successful and failed transactions\n\nRequest body:\nFieldRequiredDescriptionsignedTransactionYesBase64-encoded signed transactionrequestIdYesThe requestId from the /order responselastValidBlockHeightNoBlock height for nonce validation\nResponse:\nFieldDescriptionstatus”Success” or “Failed”signatureTransaction signature (present on both success and some failures)codeError code. 0 = success. See /execute error codes.totalInputAmountTotal input token amount deducted from the user’s wallet, including the fee if feeMint is the input mintinputAmountResultInput amount that went into the swap route, after any fee collected in the input mintoutputAmountResultOutput amount produced by the swap route, before any fee collected in the output minttotalOutputAmountFinal output token amount reflected in the user’s wallet, after any fee collected in the output mint\nUse totalInputAmount and totalOutputAmount for the swap token amounts reflected in the user’s wallet. Use inputAmountResult and outputAmountResult for swap-route accounting.\nThe swap fee is collected in one token, shown by feeMint in the /order response. If feeMint matches inputMint, compare totalInputAmount and inputAmountResult:\nfee collected in the input mint = totalInputAmount - inputAmountResult\n\nIf feeMint matches outputMint, compare outputAmountResult and totalOutputAmount:\nfee collected in the output mint = outputAmountResult - totalOutputAmount\n\nFor example, if /execute returns:\n{\n \"outputAmountResult\": \"2103\",\n \"totalOutputAmount\": \"2101\"\n}\n\nThe swap route produced 2103 output units, and 2101 output units were reflected in the user’s wallet. The difference is the fee collected in the output mint.\n​Error codes\n​/order error codes\nWhen /order returns transaction: \"\" (empty string), the response still contains valid pricing but the swap cannot proceed. The errorCode and errorMessage fields explain why.\nThe same errorCode number has different meanings depending on the router. Match on both fields:\nAggregator routers (metis, dflow, okx):\nerrorCodeMeaning1Insufficient funds (taker lacks input token balance)2Insufficient SOL for gas3Swap below minimum for gasless\nJupiterZ router (jupiterz):\nerrorCodeMeaning1Insufficient balance to fund the swap2Missing associated token account3Quote could not be built into a transaction\n​/execute error codes\nThe code field in the /execute response indicates the result. 0 is success, negative values are errors grouped by router type:\nCodeCategoryMeaning0SuccessTransaction confirmed-1ExecuteMissing cached order (requestId not found or expired)-2ExecuteInvalid signed transaction-3ExecuteInvalid message bytes-1000AggregatorFailed to land-1001AggregatorUnknown error-1002AggregatorInvalid transaction-1003AggregatorTransaction not fully signed-1004AggregatorInvalid block height-2000RFQFailed to land-2001RFQUnknown error-2002RFQInvalid payload-2003RFQQuote expired-2004RFQSwap rejected\n​Routing impact matrix\nAdding optional parameters to /order can restrict which routers are eligible:\nParameterMetisJupiterZ (RFQ)DflowOKX(no optional params)YesYesYesYesreceiverYesYesYesYesreferralAccount & referralFeeYesYesYesYespayer (integrator gasless)YesNoNoNoexcludeRouters: jupiterzYesNoYesYes\nKey takeaway: setting payer to a wallet different from taker disables JupiterZ (RFQ) and restricts routing to Metis, which may result in worse pricing on major pairs where market makers often beat onchain routing by 5-20bps.\nFor the full parameter reference, see the API reference.\n​Order mode\nThe /order response includes a mode field that indicates whether optional parameters were applied that may affect routing or swap behaviour:\nModeMeaningultraNo optional params used. Default behaviour with all routers eligible.manualOptional params detected (e.g. slippageBps, referralAccount, payer). These modifications may restrict routing or change swap behaviour.\nmode does not indicate which router was used for the swap. It signals whether you adjusted parameters that could affect price or swap success. This is useful for debugging: if a swap fails in manual mode, the parameter modifications you applied may be the cause.\nThis is similar to how the jup.ag frontend behaves: when you use custom settings like slippage, priority fee strategy, or dex/router exclusions, the swap is handled differently. Since you opted into custom parameters, you take responsibility for the impact on swap outcomes.\n​Fees\n​Jupiter platform fee\nJupiter charges a platform fee on /order swaps. This fee is included in the quote and deducted automatically. The platformFee field in the response shows the fee amount and rate:\n{\n \"platformFee\": {\n \"amount\": \"8529\",\n \"feeBps\": 5,\n \"feeMint\": \"EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v\"\n }\n}\n\n​Total fee vs platform fee\nThe top-level feeBps field is the total fee rate charged for the swap. The platformFee.feeBps field is the Jupiter platform fee rate, which is the fee Jupiter intends to make from the swap.\nThese values can differ when the swap includes additional charges, such as gasless support cost recoup. For example, if the platform fee for a swap pair is 5 bps and gasless support adds 7 bps, the response can show feeBps: 12 and platformFee.feeBps: 5.\n​Fee breakdown\nThe platform fee varies by token pair:\nToken PairFee (bps)Buying Jupiter tokens (SOL/Stable to JUP/JLP/jupSOL)0Pegged assets (LST-LST, Stable-Stable)0SOL-Stable2LST-Stable5Everything else10New tokens (within 24 hours of token age)50\n​Fee mint priority\nJupiter determines which token to collect fees in based on a priority list:\n\nSOL\nStablecoins (USDC, USDT, etc.)\nLiquid staked tokens (jupSOL, etc.)\nBluechips (large market cap tokens)\nOthers\n\nCheck the feeBps, platformFee.feeBps, and feeMint fields in the /order response to see the total fee rate, Jupiter platform fee rate, and fee token for your swap.\n​Referral fees\nUse the Jupiter Referral Program to earn fees on /order swaps. This requires setting up referral accounts before you can collect fees.\n​How it works\n\nJupiter takes 20% of your integrator fee (no separate platform fee when referral is active)\nJupiter decides which token mint to collect fees in based on the fee mint priority list\nYou must create a referralTokenAccount for each mint you expect to receive fees in\nIf the referralTokenAccount for the feeMint is not initialised, the order still returns but executes without your fees (the user still gets their swap)\nFee range: 50 to 255 bps\nSupports SPL and Token2022 tokens\n\n​Setup\nThree one-time steps before you can collect fees:\n\nInstall the Referral SDK\n\nnpm install @jup-ag/referral-sdk\n\nCreate a referralAccount (once)\n\nimport { ReferralProvider } from \"@jup-ag/referral-sdk\";\nimport { Connection, Keypair, PublicKey, sendAndConfirmTransaction } from \"@solana/web3.js\";\nimport bs58 from \"bs58\";\n\nconst connection = new Connection(\"https://api.mainnet-beta.solana.com\");\nconst wallet = Keypair.fromSecretKey(bs58.decode(process.env.BS58_PRIVATE_KEY!));\nconst provider = new ReferralProvider(connection);\n\n// Jupiter Ultra Referral Project\nconst projectPubKey = new PublicKey(\"DkiqsTrw1u1bYFumumC7sCG2S8K25qc2vemJFHyW2wJc\");\n\nconst transaction = await provider.initializeReferralAccountWithName({\n payerPubKey: wallet.publicKey,\n partnerPubKey: wallet.publicKey,\n projectPubKey: projectPubKey,\n name: \"your-app-name\",\n});\n\nconst signature = await sendAndConfirmTransaction(connection, transaction.tx, [wallet]);\nconsole.log(\"referralAccount:\", transaction.referralAccountPubKey.toBase58());\n\nCreate referralTokenAccount for each fee mint\n\nCreate a token account for each mint you expect to collect fees in. Start with SOL and USDC. You can add more later.\nconst mint = new PublicKey(\"So11111111111111111111111111111111111111112\"); // SOL\n\nconst transaction = await provider.initializeReferralTokenAccountV2({\n payerPubKey: wallet.publicKey,\n referralAccountPubKey: new PublicKey(\"YOUR_REFERRAL_ACCOUNT\"),\n mint,\n});\n\nconst signature = await sendAndConfirmTransaction(connection, transaction.tx, [wallet]);\nconsole.log(\"referralTokenAccount:\", transaction.tokenAccount.toBase58());\n\nYou can also use the Referral Dashboard to create accounts via a web interface.\n​Usage\nPass referralAccount and referralFee to /order:\nconst params = new URLSearchParams({\n inputMint: \"So11111111111111111111111111111111111111112\",\n outputMint: \"EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v\",\n amount: \"1000000000\",\n taker: walletAddress,\n referralAccount: \"YOUR_REFERRAL_ACCOUNT\",\n referralFee: \"50\", // 50 bps = 0.5%\n});\n\nconst response = await fetch(\n `https://api.jup.ag/swap/v2/order?${params}`,\n { headers: { \"x-api-key\": API_KEY } }\n);\n\nVerify your fees are applied by checking the response fee fields. Top-level feeBps is the total fee rate charged for the swap, while platformFee.feeBps is the Jupiter platform fee rate. If the response falls back to the default platform fee, the referralTokenAccount for that feeMint is likely not initialised.\n​Fee response fields\nThe /order response includes these fee-related fields:\nFieldDescriptionfeeBpsTotal fee rate charged for the swap, including platform fee and additional charges such as gasless support cost recoupfeeMintToken fees are collected inplatformFee.amountJupiter platform fee amountplatformFee.feeBpsJupiter platform fee rate, excluding gasless support cost recoupreferralAccountReferral account used (if set)\n​Related\n\nJupiter Referral Program for the full referral program documentation\nAdvanced Techniques for gasless swaps, priority fees, and CU optimisation\nAPI Reference: GET /order for the full OpenAPI specification\nAPI Reference: POST /execute for the full OpenAPI specification\nWas this page helpful?","tokens":5440,"squid":"spider-02","role":"Liquidity Spider","at":1791344863120,"hash":"1463c1c023bdf112152cbb7929fb9661e01b958c"}
{"url":"https://consensysdiligence.github.io/smart-contract-best-practices/development-recommendations/solidity-specific/payability/","domain":"consensysdiligence.github.io","title":"Payability - Ethereum Smart Contract Best Practices","text":"Payability\n\nTip\nFor comprehensive insights into secure development practices, consider visiting the Development Recommendations section of the Smart Contract Security Field Guide. This resource provides in-depth articles to guide you in developing robust and secure smart contracts.\n\nStarting from Solidity 0.4.0, every function that is receiving ether must use payable modifier,\notherwise if the transaction has msg.value > 0 will revert\n(except when forced).\n\nNote\nSomething that might not be obvious: The payable modifier only applies to calls from external contracts. If I call a non-payable function in the payable function in the same contract, the non-payable function won't fail, though msg.value is still set.","tokens":180,"squid":"spider-06","role":"Security Spider","at":1791344872394,"hash":"2a5caf82a262b3b4aee750b318837b302d0b550e"}
{"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":"spider-05","role":"Spec Spider","at":1791344879906,"hash":"763199222b4e2f752bef0429a0ed53e058e306d9"}
{"url":"https://consensysdiligence.github.io/smart-contract-best-practices/development-recommendations/solidity-specific/event-monitoring/","domain":"consensysdiligence.github.io","title":"Event Monitoring - Ethereum Smart Contract Best Practices","text":"Event Monitoring\n\nTip\nFor comprehensive insights into secure development practices, consider visiting the Development Recommendations section of the Smart Contract Security Field Guide. This resource provides in-depth articles to guide you in developing robust and secure smart contracts.\n\nIt can be useful to have a way to monitor the contract's activity after it was deployed. One way to\naccomplish this is to look at all transactions of the contract, however that may be insufficient,\nas message calls between contracts are not recorded in the blockchain. Moreover, it shows only the\ninput parameters, not the actual changes being made to the state. Also, events could be used to\ntrigger functions in the user interface.\ncontract Charity {\n mapping(address => uint) balances;\n\n function donate() payable public {\n balances[msg.sender] += msg.value;\n }\n}\n\ncontract Game {\n function buyCoins() payable public {\n // 5% goes to charity\n charity.donate.value(msg.value / 20)();\n }\n}\n\nHere, Game contract will make an internal call to Charity.donate(). This transaction won't\nappear in the external transaction list of Charity, but only visible in the internal\ntransactions.\nAn event is a convenient way to log something that happened in the contract. Events that were\nemitted stay in the blockchain along with the other contract data and they are available for future\naudit. Here is an improvement to the example above, using events to provide a history of the\nCharity's donations.\ncontract Charity {\n // define event\n event LogDonate(uint _amount);\n\n mapping(address => uint) balances;\n\n function donate() payable public {\n balances[msg.sender] += msg.value;\n // emit event\n emit LogDonate(msg.value);\n }\n}\n\ncontract Game {\n function buyCoins() payable public {\n // 5% goes to charity\n charity.donate.value(msg.value / 20)();\n }\n}\n\nHere, all transactions that go through the Charity contract, either directly or not, will show up\nin the event list of that contract along with the amount of donated money.\n\nPrefer newer Solidity constructs\nPrefer constructs/aliases such as selfdestruct (over suicide) and keccak256 (over sha3). Patterns like require(msg.sender.send(1 ether)) can also be simplified to using transfer(), as in msg.sender.transfer(1 ether). Check out Solidity Change log for more similar changes.","tokens":578,"squid":"spider-06","role":"Security Spider","at":1791344883071,"hash":"d8fad215c3e21adddf40d2a207ae95c59af103ed"}
{"url":"https://developers.jup.ag/docs/swap/advanced/gasless","domain":"developers.jup.ag","title":"Gasless Swaps - Jupiter Developers","text":"Gasless swaps let users trade without holding SOL for transaction fees. On /order, the gasless: true response field can be set by three independent paths:\n\nAutomatic Jupiter sponsorship: Jupiter covers gas and token account rent when the taker has low SOL.\nJupiterZ market maker: an RFQ market maker pays signature and priority fees directly.\nIntegrator payer: your wallet covers gas via the payer parameter.\n\nTo identify which path fired on any quote, compare signatureFeePayer to the taker:\nsignatureFeePayer valueSourceEqual to takerNot gasless, taker paysgasTzr94Pmp4Gf8vknQnqxeYxdgwFjbgdJa4msYRpnBAutomatic Jupiter sponsorshipEqual to your payer parameterIntegrator-sponsored gasAny other addressJupiterZ market maker (varies per quote)\n​Types of gas costs\nSolana transactions can incur four types of gas costs:\n\nBase network transaction fee (signature fee)\nAssociated token account (ATA) rent for new token accounts\nPriority fee (or tips for Jito, etc.)\nOther account rent (some DEXes require additional accounts of the taker, e.g. Pump.fun)\n\n​How to opt out of gasless\nThe most reliable check is signatureFeePayer == taker on every /order response. Drop any quote where they differ. This catches all three gasless paths and survives future changes to routing.\nYou can also reduce gasless quotes upstream by passing excludeRouters=jupiterz. This blocks the JupiterZ RFQ path, which is the most common source of gasless quotes. It is not a complete opt-out on its own: if the taker has less than 0.01 SOL on a trade of about $10 or more, automatic Jupiter sponsorship still fires through Metis with signatureFeePayer = gasTzr94Pmp4Gf8vknQnqxeYxdgwFjbgdJa4msYRpnB. The signatureFeePayer check catches both cases.\n​Automatic gasless (/order)\nJupiter automatically covers gas costs when the taker lacks SOL.\nWhen it applies:\n\nTaker has less than 0.01 SOL\nMinimum trade size of ~$10 (dynamic, varies with current priority fee market)\nA JupiterZ market maker is not winning the quote, and integrator payer is not set\n\nWhat it covers: all four gas types (signature fee, priority fee, ATA rent, other account rent).\nHow it works:\n\nJupiter calculates the required SOL to cover gas and increases the swap fee. The taker receives less output tokens. The top-level feeBps field reflects this increased total fee, while platformFee.feeBps only reflects the Jupiter platform fee.\nThe sponsor wallet gasTzr94Pmp4Gf8vknQnqxeYxdgwFjbgdJa4msYRpnB is added as a secondary signer and is returned as the signatureFeePayer, prioritizationFeePayer, and rentFeePayer in the response.\n\nLimitations:\n\nDoes not fire when payer is set to a wallet other than the taker (integrator payer takes over instead)\nDoes not fire when referralAccount and referralFee are set\n\n​JupiterZ gasless (/order)\nWhen a JupiterZ (RFQ) market maker wins the quote on /order, the market maker pays network and priority fees directly. Output token account rent is separate: when referral fees are not set, Jupiter’s gas wallet (gasTzr94Pmp4Gf8vknQnqxeYxdgwFjbgdJa4msYRpnB) can pay the rent to create the taker’s output token account. With referral fees, the taker pays output token account rent.\nWhen it applies:\n\nTaker trades a pair the market makers are willing to quote\npayer is not set\n\nWhat it covers: signature fee and priority fee. Output token account rent can be covered by Jupiter’s gas wallet when referral fees are not set.\nHow it works:\n\nThe order transaction includes a secondary signer for the market maker\nJupiter sets the gas payer to the MM signer and on /execute, your partially signed transaction is sent to the MM for them to co-sign and execute\nIf the taker’s output token account is not yet initialised and referral fees are not set, Jupiter’s gas wallet (gasTzr94Pmp4Gf8vknQnqxeYxdgwFjbgdJa4msYRpnB) can pay the rent to create it\nThe signatureFeePayer is the MM’s address. MM addresses vary per quote, so do not hardcode against a single address. Use the signatureFeePayer != taker check instead.\n\nLimitations:\n\nDoes not fire when payer is set\nWith referralAccount and referralFee, JupiterZ can still quote and execute, but the taker must have enough SOL for any required output token account rent\n\n​Integrator payer\nIntegrators can cover all gas costs on behalf of their users by passing the payer parameter. This works on both /order and /build.\npayer only activates when set to a wallet different from taker. Setting payer=taker has no effect. The request behaves as if no payer was provided.\n​On /order\nPass payer to cover all gas-related fees. The transaction requires both taker and payer signatures.\nThis needs to be used together with referral parameters (referralAccount and referralFee) because it is assumed that you will be taking fees to recoup the costs spent on gas.\nconst params = new URLSearchParams({\n inputMint: \"EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v\", // USDC\n outputMint: \"So11111111111111111111111111111111111111112\", // SOL\n amount: \"1000000\",\n taker: userWallet,\n payer: integratorPayerWallet,\n});\n\nconst response = await fetch(\n `https://api.jup.ag/swap/v2/order?${params}`,\n { headers: { \"x-api-key\": API_KEY } }\n);\n\nThe returned transaction needs two signatures (taker + payer) before sending to /execute.\nWhat it covers: all four gas types.\nHow it works:\n\nRegardless of how much SOL the taker has, the payer covers all fees\nTemporary wSOL ATA rent is covered by the payer and returned in the same transaction\nOther ATAs are covered by the payer but not returned (they hold tokens post-swap)\nRoutes through Metis only\n\n​On /build\nPass payer to change the fee payer on all returned instructions. The payer address replaces the default taker as the fee payer for the transaction.\nconst params = new URLSearchParams({\n inputMint: \"EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v\",\n outputMint: \"So11111111111111111111111111111111111111112\",\n amount: \"1000000\",\n taker: userWallet,\n payer: integratorPayerWallet,\n});\n\nconst response = await fetch(\n `https://api.jup.ag/swap/v2/build?${params}`,\n { headers: { \"x-api-key\": API_KEY } }\n);\n\nThe returned instructions will have fee payer accounts set to the payer address. You are responsible for building the transaction, collecting both signatures (taker + payer), and sending via your own RPC.\n\nWhen using payer on /build, do note that your gas payer is not only paying for gas, it is paying for transaction fee, priority fee/tip, token accounts, or any other AMM related accounts that might be required.\n\nThe token accounts or AMM related accounts can be closed by the user. If you do not find ways to recoup the fees you spent for the user, it may be gameable where they always close their accounts and you have to fund them again.\n\nHence, when you are the gas payer, ensure that you account for these and find ways to recoup the cost spent to ensure your gas payer is not drained.\n​Related\n\nOrder & Execute for the default swap flow\nBuild for full transaction control\nRouting impact matrix for how payer affects routing\nFees for how gasless affects the fee calculation\nWas this page helpful?","tokens":1762,"squid":"spider-02","role":"Liquidity Spider","at":1791344888850,"hash":"3eba372c69dd7d771e5fae90c2374ca3957785eb"}
{"url":"https://consensysdiligence.github.io/smart-contract-best-practices/development-recommendations/solidity-specific/complex-inheritance/","domain":"consensysdiligence.github.io","title":"Complex Inheritance - Ethereum Smart Contract Best Practices","text":"Complex Inheritance\n\nTip\nFor comprehensive insights into secure development practices, consider visiting the Development Recommendations section of the Smart Contract Security Field Guide. This resource provides in-depth articles to guide you in developing robust and secure smart contracts.\n\nWhen utilizing multiple inheritance in Solidity, it is important to understand how the compiler\ncomposes the inheritance graph.\ncontract Final {\n uint public a;\n function Final(uint f) public {\n a = f;\n }\n}\n\ncontract B is Final {\n int public fee;\n\n function B(uint f) Final(f) public {\n }\n function setFee() public {\n fee = 3;\n }\n}\n\ncontract C is Final {\n int public fee;\n\n function C(uint f) Final(f) public {\n }\n function setFee() public {\n fee = 5;\n }\n}\n\ncontract A is B, C {\n function A() public B(3) C(5) {\n setFee();\n }\n}\n\nWhen a contract is deployed, the compiler will linearize the inheritance from right to left\n(after the keyword is the parents are listed from the most base-like to the most derived). Here\nis contract A's linearization:\nFinal \\<- B \\<- C \\<- A\nThe consequence of the linearization will yield a fee value of 5, since C is the most derived\ncontract. This may seem obvious, but imagine scenarios where C is able to shadow crucial functions,\nreorder boolean clauses, and cause the developer to write exploitable contracts. Static analysis\ncurrently does not raise issue with overshadowed functions, so it must be manually inspected.\nFor more on security and inheritance, check out this\narticle\nTo help contribute, Solidity's Github has a\nproject with all\ninheritance-related issues.\nSee SWC-125","tokens":403,"squid":"spider-06","role":"Security Spider","at":1791344895570,"hash":"94d149c63b7d24ee977de20577cdf07d3e0f5cec"}
{"url":"https://www.metaplex.com/docs/smart-contracts/token-metadata","domain":"metaplex.com","title":"Overview | Token Metadata","text":"Token Metadata is a legacy program. It remains supported, but is not recommended for new projects. Use Core instead.The Token Metadata program is a fundamental program when dealing NFTs and Fungible assets on the Solana blockchain. In this overview, we explain what this program does and how we can leverage its various features at a high level. Please note that certain Token Metadata instructions will require protocol fees. Please review the Protocol Fees page for up-to-date information.Getting StartedFind the language or library of your choice and get started with digital assets on Solana.API referenceLooking for something specific? Have a peak at our API References and find your answer.IntroductionThe Token Metadata program is one of the most important programs when dealing with NFTs on the Solana blockchain. Its main goal is to attach additional data to Fungible or Non-Fungible Tokens on Solana.It achieves this using Program Derived Addresses (PDAs) that are derived from the address of Mint Accounts. If you’re not familiar with Solana’s Token program, Mint Accounts are responsible for storing the global information of a Token and Token Accounts store the relationship between a wallet and a Mint Account.Wallet AccountOwner: System ProgramSomeone's wallet.Token AccountOwner: Token ProgramStores the number of tokens owned by the wallet, among other things.Mint AccountOwner: Token ProgramStores information about the token itself. E.g. its current supply and its authorities.React FlowPress enter or space to select a node.You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel. Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.Whilst Mint Accounts contain a few data attributes such as its current supply, it doesn't offer the ability to inject standardized data that can be understood by apps and marketplaces.This is why the Token Metadata program offers a Metadata Account that attaches itself to a Mint Account via a PDA.Wallet AccountOwner: System ProgramToken AccountOwner: Token ProgramMint AccountOwner: Token ProgramPDAMetadata AccountOwner: Token Metadata ProgramKey = MetadataV1Update AuthorityMintNameSymbolURISeller Fee Basis PointsCreatorsPrimary Sale HappenedIs MutableEdition NonceToken StandardCollectionUsesCollection DetailsProgrammable ConfigsReact FlowPress enter or space to select a node.You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel. Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.That Metadata Account holds a lot of valuable information that can be used throughout the ecosystem. For instance, it maintains a list of creators for the token. Each creator has a Verified attribute that, when True, guarantees the token was signed by that creator. Each creator also has a Share attribute that can be used by marketplaces to distribute royalties.By attaching more data to the Mint Account, the Token Metadata program is able to make Digital Assets of regular onchain Tokens.A JSON standardOne important attribute of the Metadata Account is the URI attribute that points to a JSON file off-chain. This is used to safely provide additional data whilst not being constrained by the fees involved in storing onchain data. That JSON file follows a certain standard that anyone can use to find useful information on tokens.Wallet AccountOwner: System ProgramToken AccountOwner: Token ProgramMint AccountOwner: Token ProgramPDAMetadata AccountOwner: Token Metadata ProgramKey = MetadataV1Update AuthorityMintNameSymbolURISeller Fee Basis PointsCreatorsPrimary Sale HappenedIs MutableEdition NonceToken StandardCollectionUsesCollection DetailsProgrammable ConfigsOff-chain JSON MetadataNameDescriptionImageAnimated URLAttributes...React FlowPress enter or space to select a node.You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel. Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.Note that, this JSON file can be stored using a permanent storage solution such as Arweave to ensure it cannot be updated. Additionally, one can use the Is Mutable attribute of the Metadata Account to make it immutable and, therefore, forbid the URI attribute — and other attributes such as Name and Creators — to ever be changed. Using this combination, we can guarantee the immutability of the off-chain JSON file.NFTsYou might be wondering: what has this got to do with NFTs? Well, NFTs are special tokens that are Non-Fungible.More precisely, NFTs in Solana are Mint Accounts with the following characteristics:It has a supply of 1, meaning only one token is in circulation.It has zero decimals, meaning there cannot be such a thing as 0.5 tokens.It has no mint authority, meaning no one can ever mint additional tokens.What we end up with is a token that cannot be traded with something of the same kind, which is the definition of a Non-Fungible Token (NFT).Wallet AccountOwner: System ProgramToken AccountOwner: Token ProgramAmount = 1Mint AccountOwner: Token ProgramMint Authority = NoneSupply = 1Decimals = 0PDAMetadata AccountOwner: Token Metadata ProgramReact FlowPress enter or space to select a node.You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel. Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.In this particular yet popular case, the goal of the Metadata Account is to provide the actual data of that NFT to make it a useful Digital Asset.Additionally, the Token Metadata program offers another account specifically for NFTs called the Master Edition Account. This account is also a PDA derived from the Mint Account.Before creating this account, the Token Metadata program will ensure the special characteristics of Non-Fungible Tokens listed above are met. However, it is worth noting that, instead of voiding the Mint Authority, it will transfer both the Mint Authority and the Freeze Authority to the Master Edition PDA to ensure no one can mint or freeze tokens without going through the Token Metadata program. You can read more about why this decision was made in the FAQ.Thus, the existence of the Master Edition account acts as proof of Non-Fungibility for that Mint Account.Wallet AccountOwner: System ProgramToken AccountOwner: Token ProgramAmount = 1Mint AccountOwner: Token ProgramMint Authority = EditionSupply = 1Decimals = 0Freeze Authority = EditionPDAMetadata AccountOwner: Token Metadata ProgramPDAMaster Edition AccountOwner: Token Metadata ProgramKey = MasterEditionV2SupplyMax SupplyReact FlowPress enter or space to select a node.You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel. Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.Printing EditionsIn addition to being Non-Fungibility evidence, the Master Edition account also allows users to print one or multiple copies of an NFT.This feature is particularly helpful to creators that want to offer multiple copies of their 1/1 NFTs to their audience.The Master Edition account contains an optional Max Supply attribute that dictates the maximum amount of NFTs that can be printed that way. If set to 0, printing is disabled. If set to None an unlimited amount of copies can be printed.The Master Edition NFT, a.k.a. Original NFT, acts as the master record that one can use to print copies, a.k.a. Print NFTs.Each Print NFT is made of its own Mint Account and its own Metadata Account whose data is copied from the Original NFT. However, instead of having a Master Edition account attached to their Mint Account, Print NFTs use yet another PDA account called an Edition Account. This account keeps track of the edition number and the parent Master Edition it originated from.Note that the Master Edition account and the Edition account share the same seeds for their PDA. That means an NFT can be one or the other but not both.ORWallet AccountOwner: System ProgramToken AccountOwner: Token ProgramAmount = 1Mint AccountOwner: Token ProgramMint Authority = EditionSupply = 1Decimals = 0Freeze Authority = EditionPDAMetadata AccountOwner: Token Metadata ProgramPDAMaster Edition AccountOwner: Token edition ProgramEdition AccountOwner: Token edition ProgramKey = EditionV1ParentEditionReact FlowPress enter or space to select a node.You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel. Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.Semi-Fungible TokensWhilst NFTs are the biggest use case of the Token Metadata program, it’s important to notice that the program also works with Fungible Token and, what we call, Semi-Fungible Tokens or Fungible Assets.At the end of the day, the Metadata account helps attach data to tokens regardless of their fungibility. However, the standard of the off-chain JSON file will vary slightly to accommodate their needs.To safely identify the fungibility of a token — and, thus, the standard that we should use — the Metadata account keeps track of that information in its Token Standard attribute. This attribute is automatically computed by the program and cannot be manually updated. It can take the following values.NonFungible: The Mint account is associated with a Master Edition account and, therefore, is Non-Fungible. This is your typical NFT standard.NonFungibleEdition: This is the same as NonFungible but the NFT was printed from an Original NFT and, thus, is associated with an Edition account instead of a Master Edition account.FungibleAsset: The Mint account is Fungible but has zero decimal places. Having zero decimals means we can treat the token as an asset whose supply is not limited to one. For instance, Fungible Assets can be used in the gaming industry to store resources such as “Wood” or “Iron”.Fungible: The Mint account is Fungible and has more than one decimal place. This is more likely going to be a token used as a decentralised currency.ProgrammableNonFungible: A special NonFungible token that is frozen at all times to enforce custom authorization rules. See the next section for more information.You can read more about these standards here.ORMint AccountOwner: Token ProgramMint Authority = EditionSupply = 1Decimals = 0Freeze Authority = EditionNonFungiblePDAMetadata AccountOwner: Token Metadata ProgramToken Standard = NonFungiblePDAMaster Edition AccountOwner: Token Metadata ProgramEdition AccountOwner: Token Metadata ProgramMint AccountOwner: Token ProgramDecimals = 0FungibleAssetPDAMetadata AccountOwner: Token Metadata ProgramToken Standard = FungibleAssetMint AccountOwner: Token ProgramDecimals > 0FungiblePDAMetadata AccountOwner: Token Metadata ProgramToken Standard = FungibleReact FlowPress enter or space to select a node.You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel. Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.Programmable NFTs Because the Token Metadata program is building on top of the Solana Token program, anyone can transfer tokens (fungible or not) without going through the Token Metadata program. Whilst this is great for program composibility, it also means that the Token Metadata program cannot enforce any rules on the tokens it is attached to.A good example of why this can be problematic is that Token Metadata cannot enforce secondary sales royalties. Whilst there is Seller Fee Basis Points attribute on the Metadata account, it is purely indicative and anyone could create a marketplace that does not honor royalties — which is exactly what happened.Programmable NFTs were introduced to solve this problem. They are a new opt-in Token Standard that keeps the underlying token accounts frozen at all times. That way, nobody can transfer, lock or burn Programmable NFTs without going through the Token Metadata program.It is then up to the creators to define custom operation-specific authorization rules that will be enforced by the Token Metadata program. These are defined in a special RuleSet account which is attached to the Metadata account. An example of such RuleSet could be an allowlist of program addresses that honor royalties. RuleSets are part of a new Metaplex program called Token Auth Rules.You can read more about Programmable NFTs here.Wallet AccountOwner: System ProgramToken AccountOwner: Token ProgramState = FrozenMint AccountOwner: Token ProgramPDAMetadata AccountOwner: Token Metadata Program...Programmable ConfigsRuleSet AccountOwner: Token Auth Rules ProgramReact FlowPress enter or space to select a node.You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel. Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.And a lot moreWhilst this provides a good overview of the Token Metadata program and what it has to offer, there’s still a lot more that can be done with it.The other pages of this documentation aim to document it further and explain significant features in their own individual pages.Token Standards (Assets)Minting AssetsUpdating AssetsTransferring AssetsBurning AssetsPrinted EditionsVerified CollectionsVerified CreatorsDelegated AuthoritiesLocking AssetsProgrammable NFTsNFT Escrow","tokens":3394,"squid":"spider-10","role":"Tooling Spider","at":1791344906092,"hash":"b06fcaf81f5a19feb215f7995c00c508e1941606"}
{"url":"https://developers.jup.ag/docs/api-reference/swap/build","domain":"developers.jup.ag","title":"Build Transaction - Jupiter Developers","text":"Build Transactioncurl --request GET \\\n --url 'https://api.jup.ag/swap/v2/build?transactionVersion=0' \\\n --header 'x-api-key: <api-key>'import requests\n\nurl = \"https://api.jup.ag/swap/v2/build?transactionVersion=0\"\n\nheaders = {\"x-api-key\": \"<api-key>\"}\n\nresponse = requests.get(url, headers=headers)\n\nprint(response.text)const options = {method: 'GET', headers: {'x-api-key': '<api-key>'}};\n\nfetch('https://api.jup.ag/swap/v2/build?transactionVersion=0', options)\n .then(res => res.json())\n .then(res => console.log(res))\n .catch(err => console.error(err));<?php\n\n$curl = curl_init();\n\ncurl_setopt_array($curl, [\n CURLOPT_URL => \"https://api.jup.ag/swap/v2/build?transactionVersion=0\",\n CURLOPT_RETURNTRANSFER => true,\n CURLOPT_ENCODING => \"\",\n CURLOPT_MAXREDIRS => 10,\n CURLOPT_TIMEOUT => 30,\n CURLOPT_HTTP_VERSION => CURL_HTTP_VERSION_1_1,\n CURLOPT_CUSTOMREQUEST => \"GET\",\n CURLOPT_HTTPHEADER => [\n \"x-api-key: <api-key>\"\n ],\n]);\n\n$response = curl_exec($curl);\n$err = curl_error($curl);\n\ncurl_close($curl);\n\nif ($err) {\n echo \"cURL Error #:\" . $err;\n} else {\n echo $response;\n}package main\n\nimport (\n \"fmt\"\n \"net/http\"\n \"io\"\n)\n\nfunc main() {\n\n url := \"https://api.jup.ag/swap/v2/build?transactionVersion=0\"\n\n req, _ := http.NewRequest(\"GET\", url, nil)\n\n req.Header.Add(\"x-api-key\", \"<api-key>\")\n\n res, _ := http.DefaultClient.Do(req)\n\n defer res.Body.Close()\n body, _ := io.ReadAll(res.Body)\n\n fmt.Println(string(body))\n\n}HttpResponse<String> response = Unirest.get(\"https://api.jup.ag/swap/v2/build?transactionVersion=0\")\n .header(\"x-api-key\", \"<api-key>\")\n .asString();require 'uri'\nrequire 'net/http'\n\nurl = URI(\"https://api.jup.ag/swap/v2/build?transactionVersion=0\")\n\nhttp = Net::HTTP.new(url.host, url.port)\nhttp.use_ssl = true\n\nrequest = Net::HTTP::Get.new(url)\nrequest[\"x-api-key\"] = '<api-key>'\n\nresponse = http.request(request)\nputs response.read_body{\n \"inputMint\": \"<string>\",\n \"outputMint\": \"<string>\",\n \"inAmount\": \"<string>\",\n \"outAmount\": \"<string>\",\n \"otherAmountThreshold\": \"<string>\",\n \"swapMode\": \"<string>\",\n \"slippageBps\": 123,\n \"priceImpactPct\": \"<string>\",\n \"routePlan\": [\n {\n \"swapInfo\": {\n \"ammKey\": \"<string>\",\n \"label\": \"<string>\",\n \"inputMint\": \"<string>\",\n \"outputMint\": \"<string>\",\n \"inAmount\": \"<string>\",\n \"outAmount\": \"<string>\"\n },\n \"percent\": 123,\n \"bps\": 123,\n \"usdValue\": 123\n }\n ],\n \"computeBudgetInstructions\": [\n {\n \"programId\": \"<string>\",\n \"accounts\": [\n {\n \"pubkey\": \"<string>\",\n \"isWritable\": true,\n \"isSigner\": true\n }\n ],\n \"data\": \"<string>\"\n }\n ],\n \"setupInstructions\": [\n {\n \"programId\": \"<string>\",\n \"accounts\": [\n {\n \"pubkey\": \"<string>\",\n \"isWritable\": true,\n \"isSigner\": true\n }\n ],\n \"data\": \"<string>\"\n }\n ],\n \"swapInstruction\": {\n \"programId\": \"<string>\",\n \"accounts\": [\n {\n \"pubkey\": \"<string>\",\n \"isWritable\": true,\n \"isSigner\": true\n }\n ],\n \"data\": \"<string>\"\n },\n \"cleanupInstruction\": {\n \"programId\": \"<string>\",\n \"accounts\": [\n {\n \"pubkey\": \"<string>\",\n \"isWritable\": true,\n \"isSigner\": true\n }\n ],\n \"data\": \"<string>\"\n },\n \"otherInstructions\": [\n {\n \"programId\": \"<string>\",\n \"accounts\": [\n {\n \"pubkey\": \"<string>\",\n \"isWritable\": true,\n \"isSigner\": true\n }\n ],\n \"data\": \"<string>\"\n }\n ],\n \"tipInstruction\": {\n \"programId\": \"<string>\",\n \"accounts\": [\n {\n \"pubkey\": \"<string>\",\n \"isWritable\": true,\n \"isSigner\": true\n }\n ],\n \"data\": \"<string>\"\n },\n \"addressesByLookupTableAddress\": {},\n \"transactionVersion\": 0,\n \"computeUnitPrice\": \"<string>\",\n \"blockhashWithMetadata\": {\n \"blockhash\": [\n 123\n ],\n \"lastValidBlockHeight\": 123,\n \"fetchedAt\": {\n \"secs_since_epoch\": 123,\n \"nanos_since_epoch\": 123\n }\n }\n}{\n \"error\": \"<string>\"\n}GET/buildBuild Transactioncurl --request GET \\\n --url 'https://api.jup.ag/swap/v2/build?transactionVersion=0' \\\n --header 'x-api-key: <api-key>'import requests\n\nurl = \"https://api.jup.ag/swap/v2/build?transactionVersion=0\"\n\nheaders = {\"x-api-key\": \"<api-key>\"}\n\nresponse = requests.get(url, headers=headers)\n\nprint(response.text)const options = {method: 'GET', headers: {'x-api-key': '<api-key>'}};\n\nfetch('https://api.jup.ag/swap/v2/build?transactionVersion=0', options)\n .then(res => res.json())\n .then(res => console.log(res))\n .catch(err => console.error(err));<?php\n\n$curl = curl_init();\n\ncurl_setopt_array($curl, [\n CURLOPT_URL => \"https://api.jup.ag/swap/v2/build?transactionVersion=0\",\n CURLOPT_RETURNTRANSFER => true,\n CURLOPT_ENCODING => \"\",\n CURLOPT_MAXREDIRS => 10,\n CURLOPT_TIMEOUT => 30,\n CURLOPT_HTTP_VERSION => CURL_HTTP_VERSION_1_1,\n CURLOPT_CUSTOMREQUEST => \"GET\",\n CURLOPT_HTTPHEADER => [\n \"x-api-key: <api-key>\"\n ],\n]);\n\n$response = curl_exec($curl);\n$err = curl_error($curl);\n\ncurl_close($curl);\n\nif ($err) {\n echo \"cURL Error #:\" . $err;\n} else {\n echo $response;\n}package main\n\nimport (\n \"fmt\"\n \"net/http\"\n \"io\"\n)\n\nfunc main() {\n\n url := \"https://api.jup.ag/swap/v2/build?transactionVersion=0\"\n\n req, _ := http.NewRequest(\"GET\", url, nil)\n\n req.Header.Add(\"x-api-key\", \"<api-key>\")\n\n res, _ := http.DefaultClient.Do(req)\n\n defer res.Body.Close()\n body, _ := io.ReadAll(res.Body)\n\n fmt.Println(string(body))\n\n}HttpResponse<String> response = Unirest.get(\"https://api.jup.ag/swap/v2/build?transactionVersion=0\")\n .header(\"x-api-key\", \"<api-key>\")\n .asString();require 'uri'\nrequire 'net/http'\n\nurl = URI(\"https://api.jup.ag/swap/v2/build?transactionVersion=0\")\n\nhttp = Net::HTTP.new(url.host, url.port)\nhttp.use_ssl = true\n\nrequest = Net::HTTP::Get.new(url)\nrequest[\"x-api-key\"] = '<api-key>'\n\nresponse = http.request(request)\nputs response.read_body{\n \"inputMint\": \"<string>\",\n \"outputMint\": \"<string>\",\n \"inAmount\": \"<string>\",\n \"outAmount\": \"<string>\",\n \"otherAmountThreshold\": \"<string>\",\n \"swapMode\": \"<string>\",\n \"slippageBps\": 123,\n \"priceImpactPct\": \"<string>\",\n \"routePlan\": [\n {\n \"swapInfo\": {\n \"ammKey\": \"<string>\",\n \"label\": \"<string>\",\n \"inputMint\": \"<string>\",\n \"outputMint\": \"<string>\",\n \"inAmount\": \"<string>\",\n \"outAmount\": \"<string>\"\n },\n \"percent\": 123,\n \"bps\": 123,\n \"usdValue\": 123\n }\n ],\n \"computeBudgetInstructions\": [\n {\n \"programId\": \"<string>\",\n \"accounts\": [\n {\n \"pubkey\": \"<string>\",\n \"isWritable\": true,\n \"isSigner\": true\n }\n ],\n \"data\": \"<string>\"\n }\n ],\n \"setupInstructions\": [\n {\n \"programId\": \"<string>\",\n \"accounts\": [\n {\n \"pubkey\": \"<string>\",\n \"isWritable\": true,\n \"isSigner\": true\n }\n ],\n \"data\": \"<string>\"\n }\n ],\n \"swapInstruction\": {\n \"programId\": \"<string>\",\n \"accounts\": [\n {\n \"pubkey\": \"<string>\",\n \"isWritable\": true,\n \"isSigner\": true\n }\n ],\n \"data\": \"<string>\"\n },\n \"cleanupInstruction\": {\n \"programId\": \"<string>\",\n \"accounts\": [\n {\n \"pubkey\": \"<string>\",\n \"isWritable\": true,\n \"isSigner\": true\n }\n ],\n \"data\": \"<string>\"\n },\n \"otherInstructions\": [\n {\n \"programId\": \"<string>\",\n \"accounts\": [\n {\n \"pubkey\": \"<string>\",\n \"isWritable\": true,\n \"isSigner\": true\n }\n ],\n \"data\": \"<string>\"\n }\n ],\n \"tipInstruction\": {\n \"programId\": \"<string>\",\n \"accounts\": [\n {\n \"pubkey\": \"<string>\",\n \"isWritable\": true,\n \"isSigner\": true\n }\n ],\n \"data\": \"<string>\"\n },\n \"addressesByLookupTableAddress\": {},\n \"transactionVersion\": 0,\n \"computeUnitPrice\": \"<string>\",\n \"blockhashWithMetadata\": {\n \"blockhash\": [\n 123\n ],\n \"lastValidBlockHeight\": 123,\n \"fetchedAt\": {\n \"secs_since_epoch\": 123,\n \"nanos_since_epoch\": 123\n }\n }\n}{\n \"error\": \"<string>\"\n}Authorizations​x-api-keystringheaderrequiredGet API key via https://developers.jup.ag/portalQuery Parameters​inputMintstringrequiredThe mint address of the input token​outputMintstringrequiredThe mint address of the output token​amountstringrequiredThe amount to swap in the smallest unit of the input token​takerstringrequiredPublic key of the user initiating the swap.​slippageBpsenum<string>numberdefault:50Slippage tolerance in basis points. Defaults to 50.Available options: rtse ​modeenum<string>Quoting mode. \"fast\" trades quote optimality for reduced latency.Available options: fast ​dexesstring\nComma-separated list of DEXes to restrict routing to.\nLabels are case sensitive (SolFi, not solfi). An unrecognised label is not a validation error: it returns 400 {\"error\": \"No routes found\"}, indistinguishable from a pair with no liquidity.\nMutually exclusive with excludeDexes. Passing both returns 400 {\"error\": \"dexes and excludeDexes are mutually exclusive\"}.\nFull list of DEXes here using the /program-id-to-label endpoint.\n​excludeDexesstring\nComma-separated list of DEXes to exclude.\nLabels are case sensitive (SolFi, not solfi).\nMutually exclusive with dexes.\nFull list of DEXes here using the /program-id-to-label endpoint.\n​platformFeeBpsintegerPlatform fee in basis points. If positive, feeAccount is required.Required range: 0 <= x <= 10000​feeAccountstringToken account to collect platform fees. Required if platformFeeBps is positive.​maxAccountsintegerMaximum number of accounts for the swap route. Defaults to 64.Required range: 1 <= x <= 64​payerstringAccount that pays transaction fees and rent. Defaults to taker when not passed in.​wrapAndUnwrapSolbooleanWhether to wrap/unwrap SOL. Defaults to true.​destinationTokenAccountstring\nSPL token account to receive output tokens.\nMutually exclusive with nativeDestinationAccount.\n​nativeDestinationAccountstring\nNative SOL account to receive output.\nMutually exclusive with destinationTokenAccount.\n​blockhashSlotsToExpiryintegerNumber of slots until the blockhash expires. Defaults to 150.Required range: 1 <= x <= 300​tipAmountstringSOL tip amount in lamports. Adds a tip instruction for use with /submit. The tip payer is the taker (or payer if specified).​computeUnitPricePercentileenum<string>integerPercentile of compute unit price to use. Named levels: \"medium\" (25th), \"high\" (50th), \"veryHigh\" (75th), or a number 0-10000 in basis points.Available options: medium, high, veryHigh ​forJitoBundlebooleandefault:falseSet to true if the transaction will be submitted as part of a Jito bundle.\nThis excludes DEXes that are incompatible with Jito bundles.​transactionVersionenum<string>default:0The Solana transaction version to build for, \"0\" or \"1\". Defaults to \"0\".\n\"1\" returns v1 instructions: computeBudgetInstructions is empty and addressesByLookupTableAddress is {} (v1 inlines accounts, no lookup tables). Set the compute budget, including the returned computeUnitPrice, on the message config. Build with a v1-capable SDK (@solana/kit v8 or later).Available options: 0, 1 ResponseQuote with raw swap instructions​inputMintstring​outputMintstring​inAmountstring​outAmountstring​otherAmountThresholdstringMinimum output amount after slippage​swapModestring​slippageBpsnumber​priceImpactPctstringPrice impact of the swap as a decimal ratio (e.g. \"0.001\" = 0.1%)​routePlanobject[]Show child attributes​computeBudgetInstructionsobject[]Compute unit price instruction (does not include compute unit limit). Empty when transactionVersion is \"1\"; use computeUnitPrice on the message config instead.Show child attributes​setupInstructionsobject[]Pre-swap setup instructions (e.g. create ATAs)Show child attributes​swapInstructionobjectShow child attributes​cleanupInstructionobject | nullPost-swap cleanup instructionShow child attributes​otherInstructionsobject[]Show child attributes​tipInstructionobject | nullShow child attributes​addressesByLookupTableAddressobject | nullAddress lookup table mappings for v0 transactions. Empty object ({}) when transactionVersion is \"1\" (v1 inlines accounts, no lookup tables).Show child attributes​transactionVersionenum<number>The Solana transaction version these instructions are for, 0 or 1, matching the transactionVersion request parameter.Available options: 0, 1 ​computeUnitPricestringPresent when transactionVersion is \"1\". Compute unit price in micro-lamports, to set on the message config.​blockhashWithMetadataobjectShow child attributesWas this page helpful?","tokens":2918,"squid":"spider-02","role":"Liquidity Spider","at":1791344911003,"hash":"b47e449d4abc72f3d296ca961a0d01f3a87b93e4"}
{"url":"https://consensysdiligence.github.io/smart-contract-best-practices/development-recommendations/solidity-specific/shadowing/","domain":"consensysdiligence.github.io","title":"Shadowing - Ethereum Smart Contract Best Practices","text":"Shadowing\n\nTip\nFor comprehensive insights into secure development practices, consider visiting the Development Recommendations section of the Smart Contract Security Field Guide. This resource provides in-depth articles to guide you in developing robust and secure smart contracts.\n\nIt is currently possible to shadow built-in\nglobals in Solidity. This allows contracts to override the functionality of built-ins such as msg\nand revert(). Although this is intended, it\ncan mislead users of a contract as to the contract's true behavior.\ncontract PretendingToRevert {\n function revert() internal constant {}\n}\n\ncontract ExampleContract is PretendingToRevert {\n function somethingBad() public {\n revert();\n }\n}\n\nContract users (and auditors) should be aware of the full smart contract source code of any\napplication they intend to use.","tokens":208,"squid":"spider-06","role":"Security Spider","at":1791344913686,"hash":"0bc40b7490d138c90edde49b13de08f0856d8358"}
{"url":"https://www.metaplex.com/docs/smart-contracts/token-metadata/mint","domain":"metaplex.com","title":"Minting Assets | Token Metadata","text":"Token Metadata is a legacy program. It remains supported, but is not recommended for new projects. Use Core instead.As we discussed in the Token Metadata overview, digital assets on Solana are composed of several onchain accounts and off-chain data describing the token. On this page, we'll go over the process of minting these assets. The minting processWhether we want to mint a Fungible, Semi-Fungible or Non-Fungible asset, the overall process is the same:Upload off-chain data. First, we must ensure our off-chain data is ready. This means we must have a JSON file stored somewhere that describes our asset. It doesn't matter how or where that JSON file is stored, as long as it's accessible via a URI.Create onchain accounts. Then, we must create the onchain accounts that will hold our asset's data. Which exact accounts will be created depends on the Token Standard of our asset, but in all cases, a Metadata account will be created and will store the URI of our off-chain data.Mint tokens. Finally, we must mint the tokens associated with all these accounts. For Non-Fungible assets, that simply means minting from 0 to 1, since Non-Fungibility forbids us to have a supply greater than 1. For Fungible or Semi-Fungible assets, we may mint however many tokens we want.Let's dig into these steps in more detail, whilst providing concrete code examples.Uploading off-chain dataYou may use any service to upload your off-chain data or simply store it on your own server but it is worth noting that the Umi SDK can help with that. It uses a plugin system that allows you to select the uploader of your choice and offers a unified interface for you to upload your data.Upload assets and JSON dataconst [imageUri] = await umi.uploader.upload([imageFile])\nconst uri = await umi.uploader.uploadJson({\n name: 'My NFT',\n description: 'This is my NFT',\n image: imageUri,\n // ...\n})\nNow that we have our URI, we can move on to the next step.The next steps show how to create accounts and mint the tokens in two steps. At the bottom of the page there are code examples for helpers that combine those steps and make creating different token types easier.Creating Mint and Metadata accountsTo create all the onchain accounts required by the Token Standard of your choice, you may simply use the Create V1 instruction. It will adapt to the requested Token Standard and create the right accounts accordingly.For instance, NonFungible assets will have a Metadata account and a MasterEdition account created, whereas Fungible assets will only have a Metadata account created.ORMint AccountOwner: Token ProgramMint Authority = EditionSupply = 1Decimals = 0Freeze Authority = EditionNonFungible (incl. editions and pNFTs)PDAMetadata AccountOwner: Token Metadata ProgramToken Standard = NonFungiblePDAMaster Edition AccountOwner: Token Metadata ProgramEdition AccountOwner: Token Metadata ProgramMint AccountOwner: Token ProgramDecimals = 0FungibleAssetPDAMetadata AccountOwner: Token Metadata ProgramToken Standard = FungibleAssetMint AccountOwner: Token ProgramDecimals > 0FungiblePDAMetadata AccountOwner: Token Metadata ProgramToken Standard = FungibleReact FlowPress enter or space to select a node.You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel. Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.Additionally, if the provided Mint account does not exist, it will be created for us. That way, we don't even need to call the underlying Token program to prepare our token before adding metadata to it.This instruction accepts a variety of parameters and our SDKs do their best to provide default values to them so you don't need to fill all of them every single time. That being said, here is a list of parameters that you may be interested in:Mint: The Mint account of the asset. If it doesn't exist, it must be provided as a Signer as it will be initialized. Typically, we generate a new keypair for this purpose.Authority: The authority of the Mint account. This is the account that is or will be allowed to mint tokens from the Mint account. This will default to the \"Identity\" wallet — i.e. the connected wallet — if supported by the SDK.Name, URI, Seller Fee Basis Points, Creators, etc.: The data of the asset to store on the Metadata account.Token Standard: The Token Standard of the asset.createV1 is a helper function that can initialize the Mint Account and create the Metadata Account. If the mint exists already it will only create the metadata Account. If you are looking for how to use createMetadataAccountV3 you should be using this function instead.1import { generateSigner, percentAmount } from '@metaplex-foundation/umi';\n2import {\n3 createV1,\n4 TokenStandard,\n5} from '@metaplex-foundation/mpl-token-metadata';\n6\n7// Assuming umi is set up with mplTokenMetadata plugin\n8// See getting-started for full setup\n9\n10const mint = generateSigner(umi);\n11\n12// Create the onchain accounts (Mint + Metadata + MasterEdition for NFTs)\n13await createV1(umi, {\n14 mint,\n15 authority: umi.identity,\n16 name: 'My NFT',\n17 uri: 'https://example.com/my-nft.json',\n18 sellerFeeBasisPoints: percentAmount(5.5),\n19 tokenStandard: TokenStandard.NonFungible,\n20}).sendAndConfirm(umi);\n21\n22console.log('Created NFT accounts');\n23console.log('Mint:', mint.publicKey);\n1import { generateKeyPairSigner } from '@solana/kit';\n2import {\n3 getCreateV1InstructionAsync,\n4 TokenStandard,\n5} from '@metaplex-foundation/mpl-token-metadata-kit';\n6\n7// Assuming rpc, rpcSubscriptions, and sendAndConfirm are set up\n8// See getting-started for full setup\n9\n10const mint = await generateKeyPairSigner();\n11const authority = await generateKeyPairSigner(); // Your wallet\n12\n13// Create the onchain accounts (Mint + Metadata + MasterEdition for NFTs)\n14const createIx = await getCreateV1InstructionAsync({\n15 mint,\n16 authority,\n17 payer: authority,\n18 name: 'My NFT',\n19 uri: 'https://example.com/my-nft.json',\n20 sellerFeeBasisPoints: 550, // 5.5%\n21 tokenStandard: TokenStandard.NonFungible,\n22});\n23\n24// Send the transaction\n25await sendAndConfirm({\n26 instructions: [createIx],\n27 payer: authority,\n28});\n29\n30console.log('Created NFT accounts');\n31console.log('Mint:', mint.address);\n1use mpl_token_metadata::{\n2 accounts::Metadata,\n3 instructions::CreateV1CpiBuilder,\n4 types::{PrintSupply, TokenStandard},\n5};\n6\n7// 1. every account is specified by a reference to their AccountInfo\n8\n9let create_cpi = CreateV1CpiBuilder::new(token_metadata_program_info)\n10 .metadata(metadata_info)\n11 .mint(mint_info, true)\n12 .authority(payer_info)\n13 .payer(payer_info)\n14 .update_authority(update_authority_info, false)\n15 .master_edition(Some(master_edition_info))\n16 .system_program(system_program_info)\n17 .sysvar_instructions(sysvar_instructions_info)\n18 .spl_token_program(spl_token_program_info)\n19 .token_standard(TokenStandard::NonFungible)\n20 .name(String::from(\"My NFT\"))\n21 .uri(uri)\n22 .seller_fee_basis_points(550)\n23 .token_standard(TokenStandard::NonFungible)\n24 .print_supply(PrintSupply::Zero);\n25\n26create_cpi.invoke();\nNote that when setting the mint account in Rust, it is required to specify a bool flag to indicate whether the account will be a signer or not – it needs to be a signer if the mint account does not exist.Minting TokensOnce all onchain accounts are created for our asset, we can mint tokens for it. If the asset is Non-Fungible we will simply mint its one and only token, otherwise we can mint as many tokens as we want. Note that a Non-Fungible asset is only valid once its unique token has been minted so it is a mandatory step for that Token Standard.We can use the Mint V1 instruction of the Token Metadata program to achieve this. It requires the following parameters:Mint: The address of the asset's Mint account.Authority: The authority that can authorize this instruction. For Non-Fungible assets, this is the update authority of the Metadata account, otherwise, this refers to the Mint Authority of the Mint account.Token Owner: The address of the wallet to receive the token(s).Amount: The number of tokens to mint. For Non-Fungible assets, this may only be 1.Token Standard: The Token Standard of the asset (required for our JavaScript SDK). The program does not require this argument but our SDK do so they can provide adequate default values for most of the other parameters.1import { mintV1, TokenStandard } from '@metaplex-foundation/mpl-token-metadata';\n2\n3// Assuming umi is set up with mplTokenMetadata plugin\n4// mint from createV1\n5\n6const mintPublicKey = mint.publicKey; // From the created mint\n7const tokenOwner = umi.identity.publicKey; // Wallet to receive the token\n8\n9// Mint the NFT token\n10await mintV1(umi, {\n11 mint: mintPublicKey,\n12 authority: umi.identity,\n13 amount: 1,\n14 tokenOwner,\n15 tokenStandard: TokenStandard.NonFungible,\n16}).sendAndConfirm(umi);\n17\n18console.log('Minted NFT to:', tokenOwner);\n1import {\n2 getMintV1InstructionAsync,\n3 TokenStandard,\n4} from '@metaplex-foundation/mpl-token-metadata-kit';\n5\n6// Assuming rpc, rpcSubscriptions, and sendAndConfirm are set up\n7// mint and authority from createV1\n8\n9const mintAddress = mint.address; // From the created mint\n10const tokenOwner = authority.address; // Wallet to receive the token\n11\n12// Mint the NFT token\n13const mintIx = await getMintV1InstructionAsync({\n14 mint: mintAddress,\n15 authority,\n16 payer: authority,\n17 amount: 1,\n18 tokenOwner,\n19 tokenStandard: TokenStandard.NonFungible,\n20});\n21\n22await sendAndConfirm({\n23 instructions: [mintIx],\n24 payer: authority,\n25});\n26\n27console.log('Minted NFT to:', tokenOwner);\n1use mpl_token_metadata::instructions::MintV1CpiBuilder;\n2\n3// 1. every account is specified by a reference to their AccountInfo\n4\n5let mint_cpi = MintV1CpiBuilder::new(token_metadata_program_info)\n6 .token(token_info)\n7 .token_owner(Some(token_owner_info))\n8 .metadata(metadata_info)\n9 .master_edition(Some(master_edition_info))\n10 .mint(mint_info)\n11 .payer(payer_info)\n12 .authority(update_authority_info)\n13 .system_program(system_program_info)\n14 .sysvar_instructions(sysvar_instructions_info)\n15 .spl_token_program(spl_token_program_info)\n16 .spl_ata_program(spl_ata_program_info)\n17 .amount(1);\n18\n19mint_cpi.invoke();\nWe are setting the master_edition since it is required to mint a NonFungible; the token_owner is required if the token account does not exist and one will be initialized.Create HelpersSince creating digital assets is such an important part of Token Metadata, our SDKs provide helper methods to make the process easier. Namely, these helper methods combine the Create V1 and Mint V1 instructions together in different ways, depending on the Token Standard we want to create.Create helpers","tokens":2690,"squid":"spider-10","role":"Tooling Spider","at":1791344917450,"hash":"4ae9ca76d61190d1790135e7a2202dfe03f3575d"}
{"url":"https://developers.jup.ag/docs/swap/build/common-instructions","domain":"developers.jup.ag","title":"Common Instructions - Jupiter Developers","text":"When using /build, you can add your own instructions alongside the swap. This page covers common instructions and how to compose them.\n​Instruction ordering\nWhen building your transaction, follow this order:\n\nCompute budget instructions (from /build response)\nSetup instructions (from /build response)\nYour pre-swap instructions (e.g. create token accounts)\nSwap instruction (from /build response)\nYour post-swap instructions (e.g. transfer, memo, close accounts)\nCleanup instruction (from /build response, if present)\n\n​Create associated token account\nIf the recipient does not have a token account for the output mint, create one before the swap. Use createAssociatedTokenAccountIdempotent to safely handle the case where the account already exists.\nimport { getCreateAssociatedTokenIdempotentInstruction } from \"@solana-program/associated-token\";\nimport { TOKEN_PROGRAM_ADDRESS } from \"@solana-program/token\";\n\nconst createAtaIx = getCreateAssociatedTokenIdempotentInstruction({\n payer: signer,\n owner: address(recipientAddress),\n mint: address(outputMint),\n tokenProgram: TOKEN_PROGRAM_ADDRESS,\n});\n\n// Add before the swap instruction\n\n​Close token account\nAfter a swap, you may want to close a token account to reclaim its rent. This is common when swapping to native SOL (the wrapped SOL account can be closed after unwrapping).\nimport { getCloseAccountInstruction } from \"@solana-program/token\";\n\nconst closeIx = getCloseAccountInstruction({\n account: address(tokenAccountToClose),\n destination: signer.address, // Rent refund destination\n owner: signer,\n});\n\n// Add after the swap instruction\n\n​SOL transfer\nAdd a SOL transfer to tip a validator, pay a fee, or send funds alongside the swap.\nimport { getTransferSolInstruction } from \"@solana-program/system\";\n\nconst transferIx = getTransferSolInstruction({\n source: signer,\n destination: address(recipientAddress),\n amount: 1_000_000n, // 0.001 SOL in lamports\n});\n\n// Add before or after the swap instruction\n\n​Memo instruction\nAttach a memo to the transaction for tracking, tagging, or compliance purposes.\nimport { getAddMemoInstruction } from \"@solana-program/memo\";\n\nconst memoIx = getAddMemoInstruction({\n memo: \"swap-order-12345\",\n});\n\n// Add anywhere in the transaction\n\n​CPI (Cross-Program Invocation)\nFor protocols that need to invoke the Jupiter swap from within their own onchain program, use the swap instruction from /build as the inner instruction in a CPI call.\n\nHow CPI works\nCPI considerations\n\nCPI cannot use Address Lookup Tables (ALTs), which limits the number of accounts in the transaction. Jupiter’s complex routing often requires many accounts.\nUse maxAccounts on /build to control route complexity and keep the transaction within size limits.\nSet your own compute budget, as CPI adds overhead.\n\nFlash Fill (alternative to CPI): allows the use of Versioned Transactions and ALTs, avoiding the account limit constraints of CPI. The flow:\nReferences\n\nCPI swap example\nSOL swap CPI\nFlash Fill example\n\n​Related\n\nBuild for the full /build workflow\nTransaction Submission to submit via Jupiter’s transaction landing infrastructure with SOL tips for priority processing\nAdvanced Techniques for compute unit simulation and priority fee strategies\nWas this page helpful?","tokens":812,"squid":"spider-02","role":"Liquidity Spider","at":1791344924682,"hash":"08ea24fca40e3ec28a908bb9f33aa5937b1aeeb9"}
{"url":"https://consensysdiligence.github.io/smart-contract-best-practices/development-recommendations/precautions/speed-bumps/","domain":"consensysdiligence.github.io","title":"Speed Bumps - Ethereum Smart Contract Best Practices","text":"Speed Bumps\n\nTip\nFor comprehensive insights into secure development practices, consider visiting the Development Recommendations section of the Smart Contract Security Field Guide. This resource provides in-depth articles to guide you in developing robust and secure smart contracts.\n\nSpeed bumps slow down actions, so that if malicious actions occur, there is time to recover. For\nexample, The DAO required 27 days between a successful request\nto split the DAO and the ability to do so. This ensured the funds were kept within the contract,\nincreasing the likelihood of recovery. In the case of the DAO, there was no effective action that\ncould be taken during the time given by the speed bump, but in combination with our other\ntechniques, they can be quite effective.\nExample:\nstruct RequestedWithdrawal {\n uint amount;\n uint time;\n}\n\nmapping (address => uint) private balances;\nmapping (address => RequestedWithdrawal) private requestedWithdrawals;\nuint constant withdrawalWaitPeriod = 28 days; // 4 weeks\n\nfunction requestWithdrawal() public {\n if (balances[msg.sender] > 0) {\n uint amountToWithdraw = balances[msg.sender];\n balances[msg.sender] = 0; // for simplicity, we withdraw everything;\n // presumably, the deposit function prevents new deposits when withdrawals are in progress\n\n requestedWithdrawals[msg.sender] = RequestedWithdrawal({\n amount: amountToWithdraw,\n time: block.timestamp\n });\n }\n}\n\nfunction withdraw() public {\n if(requestedWithdrawals[msg.sender].amount > 0 && block.timestamp > requestedWithdrawals[msg.sender].time + withdrawalWaitPeriod) {\n uint amountToWithdraw = requestedWithdrawals[msg.sender].amount;\n requestedWithdrawals[msg.sender].amount = 0;\n\n require(msg.sender.send(amountToWithdraw));\n }\n}","tokens":434,"squid":"spider-06","role":"Security Spider","at":1791344934589,"hash":"3c374e6e2eb9f709e15bdb2a36918399d926d011"}
{"url":"https://developers.jup.ag/docs/api-reference/swap/order","domain":"developers.jup.ag","title":"Get Order (Swap API) - Jupiter Developers","text":"Get Ordercurl --request GET \\\n --url 'https://api.jup.ag/swap/v2/order?maxSupportedTransactionVersion=0' \\\n --header 'x-api-key: <api-key>'import requests\n\nurl = \"https://api.jup.ag/swap/v2/order?maxSupportedTransactionVersion=0\"\n\nheaders = {\"x-api-key\": \"<api-key>\"}\n\nresponse = requests.get(url, headers=headers)\n\nprint(response.text)const options = {method: 'GET', headers: {'x-api-key': '<api-key>'}};\n\nfetch('https://api.jup.ag/swap/v2/order?maxSupportedTransactionVersion=0', options)\n .then(res => res.json())\n .then(res => console.log(res))\n .catch(err => console.error(err));<?php\n\n$curl = curl_init();\n\ncurl_setopt_array($curl, [\n CURLOPT_URL => \"https://api.jup.ag/swap/v2/order?maxSupportedTransactionVersion=0\",\n CURLOPT_RETURNTRANSFER => true,\n CURLOPT_ENCODING => \"\",\n CURLOPT_MAXREDIRS => 10,\n CURLOPT_TIMEOUT => 30,\n CURLOPT_HTTP_VERSION => CURL_HTTP_VERSION_1_1,\n CURLOPT_CUSTOMREQUEST => \"GET\",\n CURLOPT_HTTPHEADER => [\n \"x-api-key: <api-key>\"\n ],\n]);\n\n$response = curl_exec($curl);\n$err = curl_error($curl);\n\ncurl_close($curl);\n\nif ($err) {\n echo \"cURL Error #:\" . $err;\n} else {\n echo $response;\n}package main\n\nimport (\n \"fmt\"\n \"net/http\"\n \"io\"\n)\n\nfunc main() {\n\n url := \"https://api.jup.ag/swap/v2/order?maxSupportedTransactionVersion=0\"\n\n req, _ := http.NewRequest(\"GET\", url, nil)\n\n req.Header.Add(\"x-api-key\", \"<api-key>\")\n\n res, _ := http.DefaultClient.Do(req)\n\n defer res.Body.Close()\n body, _ := io.ReadAll(res.Body)\n\n fmt.Println(string(body))\n\n}HttpResponse<String> response = Unirest.get(\"https://api.jup.ag/swap/v2/order?maxSupportedTransactionVersion=0\")\n .header(\"x-api-key\", \"<api-key>\")\n .asString();require 'uri'\nrequire 'net/http'\n\nurl = URI(\"https://api.jup.ag/swap/v2/order?maxSupportedTransactionVersion=0\")\n\nhttp = Net::HTTP.new(url.host, url.port)\nhttp.use_ssl = true\n\nrequest = Net::HTTP::Get.new(url)\nrequest[\"x-api-key\"] = '<api-key>'\n\nresponse = http.request(request)\nputs response.read_body{\n \"mode\": \"<string>\",\n \"inputMint\": \"<string>\",\n \"outputMint\": \"<string>\",\n \"inAmount\": \"<string>\",\n \"outAmount\": \"<string>\",\n \"inUsdValue\": 123,\n \"outUsdValue\": 123,\n \"priceImpact\": 123,\n \"swapUsdValue\": 123,\n \"otherAmountThreshold\": \"<string>\",\n \"swapMode\": \"<string>\",\n \"slippageBps\": 123,\n \"priceImpactPct\": \"<string>\",\n \"routePlan\": [\n {\n \"swapInfo\": {\n \"ammKey\": \"<string>\",\n \"label\": \"<string>\",\n \"inputMint\": \"<string>\",\n \"outputMint\": \"<string>\",\n \"inAmount\": \"<string>\",\n \"outAmount\": \"<string>\"\n },\n \"percent\": 123,\n \"bps\": 123,\n \"usdValue\": 123\n }\n ],\n \"referralAccount\": \"<string>\",\n \"feeMint\": \"<string>\",\n \"feeBps\": 123,\n \"platformFee\": {\n \"amount\": \"<string>\",\n \"feeBps\": 123,\n \"feeMint\": \"<string>\"\n },\n \"signatureFeeLamports\": 123,\n \"signatureFeePayer\": \"<string>\",\n \"prioritizationFeeLamports\": 123,\n \"prioritizationFeePayer\": \"<string>\",\n \"rentFeeLamports\": 123,\n \"rentFeePayer\": \"<string>\",\n \"swapType\": \"aggregator\",\n \"router\": \"metis\",\n \"transactionVersion\": 0,\n \"transaction\": \"<string>\",\n \"lastValidBlockHeight\": \"<string>\",\n \"gasless\": true,\n \"requestId\": \"<string>\",\n \"totalTime\": 123,\n \"taker\": \"<string>\",\n \"quoteId\": \"<string>\",\n \"maker\": \"<string>\",\n \"expireAt\": \"<string>\",\n \"errorCode\": 123,\n \"errorMessage\": \"<string>\",\n \"error\": \"<string>\"\n}{\n \"requestId\": \"<string>\",\n \"error\": \"<string>\"\n}GET/orderGet Ordercurl --request GET \\\n --url 'https://api.jup.ag/swap/v2/order?maxSupportedTransactionVersion=0' \\\n --header 'x-api-key: <api-key>'import requests\n\nurl = \"https://api.jup.ag/swap/v2/order?maxSupportedTransactionVersion=0\"\n\nheaders = {\"x-api-key\": \"<api-key>\"}\n\nresponse = requests.get(url, headers=headers)\n\nprint(response.text)const options = {method: 'GET', headers: {'x-api-key': '<api-key>'}};\n\nfetch('https://api.jup.ag/swap/v2/order?maxSupportedTransactionVersion=0', options)\n .then(res => res.json())\n .then(res => console.log(res))\n .catch(err => console.error(err));<?php\n\n$curl = curl_init();\n\ncurl_setopt_array($curl, [\n CURLOPT_URL => \"https://api.jup.ag/swap/v2/order?maxSupportedTransactionVersion=0\",\n CURLOPT_RETURNTRANSFER => true,\n CURLOPT_ENCODING => \"\",\n CURLOPT_MAXREDIRS => 10,\n CURLOPT_TIMEOUT => 30,\n CURLOPT_HTTP_VERSION => CURL_HTTP_VERSION_1_1,\n CURLOPT_CUSTOMREQUEST => \"GET\",\n CURLOPT_HTTPHEADER => [\n \"x-api-key: <api-key>\"\n ],\n]);\n\n$response = curl_exec($curl);\n$err = curl_error($curl);\n\ncurl_close($curl);\n\nif ($err) {\n echo \"cURL Error #:\" . $err;\n} else {\n echo $response;\n}package main\n\nimport (\n \"fmt\"\n \"net/http\"\n \"io\"\n)\n\nfunc main() {\n\n url := \"https://api.jup.ag/swap/v2/order?maxSupportedTransactionVersion=0\"\n\n req, _ := http.NewRequest(\"GET\", url, nil)\n\n req.Header.Add(\"x-api-key\", \"<api-key>\")\n\n res, _ := http.DefaultClient.Do(req)\n\n defer res.Body.Close()\n body, _ := io.ReadAll(res.Body)\n\n fmt.Println(string(body))\n\n}HttpResponse<String> response = Unirest.get(\"https://api.jup.ag/swap/v2/order?maxSupportedTransactionVersion=0\")\n .header(\"x-api-key\", \"<api-key>\")\n .asString();require 'uri'\nrequire 'net/http'\n\nurl = URI(\"https://api.jup.ag/swap/v2/order?maxSupportedTransactionVersion=0\")\n\nhttp = Net::HTTP.new(url.host, url.port)\nhttp.use_ssl = true\n\nrequest = Net::HTTP::Get.new(url)\nrequest[\"x-api-key\"] = '<api-key>'\n\nresponse = http.request(request)\nputs response.read_body{\n \"mode\": \"<string>\",\n \"inputMint\": \"<string>\",\n \"outputMint\": \"<string>\",\n \"inAmount\": \"<string>\",\n \"outAmount\": \"<string>\",\n \"inUsdValue\": 123,\n \"outUsdValue\": 123,\n \"priceImpact\": 123,\n \"swapUsdValue\": 123,\n \"otherAmountThreshold\": \"<string>\",\n \"swapMode\": \"<string>\",\n \"slippageBps\": 123,\n \"priceImpactPct\": \"<string>\",\n \"routePlan\": [\n {\n \"swapInfo\": {\n \"ammKey\": \"<string>\",\n \"label\": \"<string>\",\n \"inputMint\": \"<string>\",\n \"outputMint\": \"<string>\",\n \"inAmount\": \"<string>\",\n \"outAmount\": \"<string>\"\n },\n \"percent\": 123,\n \"bps\": 123,\n \"usdValue\": 123\n }\n ],\n \"referralAccount\": \"<string>\",\n \"feeMint\": \"<string>\",\n \"feeBps\": 123,\n \"platformFee\": {\n \"amount\": \"<string>\",\n \"feeBps\": 123,\n \"feeMint\": \"<string>\"\n },\n \"signatureFeeLamports\": 123,\n \"signatureFeePayer\": \"<string>\",\n \"prioritizationFeeLamports\": 123,\n \"prioritizationFeePayer\": \"<string>\",\n \"rentFeeLamports\": 123,\n \"rentFeePayer\": \"<string>\",\n \"swapType\": \"aggregator\",\n \"router\": \"metis\",\n \"transactionVersion\": 0,\n \"transaction\": \"<string>\",\n \"lastValidBlockHeight\": \"<string>\",\n \"gasless\": true,\n \"requestId\": \"<string>\",\n \"totalTime\": 123,\n \"taker\": \"<string>\",\n \"quoteId\": \"<string>\",\n \"maker\": \"<string>\",\n \"expireAt\": \"<string>\",\n \"errorCode\": 123,\n \"errorMessage\": \"<string>\",\n \"error\": \"<string>\"\n}{\n \"requestId\": \"<string>\",\n \"error\": \"<string>\"\n}Authorizations​x-api-keystringheaderrequiredGet API key via https://developers.jup.ag/portalQuery Parameters​inputMintstringrequiredThe mint address of the input token​outputMintstringrequiredThe mint address of the output token​amountstringrequiredThe amount to swap in the smallest unit of the input token​takerstring\nThe public key of the wallet that will sign the transaction\nIf not provided, the response will contain a quote but no transaction\nMust be present if you intend to sign and execute the transaction via /execute\n​receiverstring\nThe public key of the account that will receive the output tokens\nMust differ from taker\nExpects a wallet address, not a token account\nFor non-SOL output: tokens are sent to the receiver's associated token account (ATA). If the ATA is not initialised, a create ATA instruction is added to the transaction\nFor SOL output: native SOL is transferred directly to the receiver\nDoes not support destination wSOL token accounts\n​swapModeenum<string>\nSwap mode. Currently only ExactIn is supported.\nAvailable options: ExactIn ​slippageBpsinteger\nSlippage tolerance in basis points (0-10000)\nIf not set, Jupiter automatically determines an appropriate slippage\nRequired range: 0 <= x <= 10000​referralAccountstring\nAddress of your referral account for the Jupiter referral project\nMust be used together with referralFee\nSee the Referral Program for setup\n​referralFeenumber\nReferral fee in basis points (50-255)\nMust be used together with referralAccount\nRequired range: 50 <= x <= 255​payerstring\nThe public key of an account that will cover gas-related fees (signature fees, priority fees, and rent) on behalf of the taker\nHas no effect when set equal to taker. Must be a different wallet to activate integrator-sponsored gas\nEnabling this restricts routing to Metis (JupiterZ is disabled when an integrator payer is set)\n​priorityFeeLamportsnumber\nPriority fee in lamports\nIf not set, Jupiter automatically determines an appropriate priority fee\nSetting this overrides the automatic optimisation\n​jitoTipLamportsnumber\nJito MEV tip in lamports for faster block inclusion\n​broadcastFeeTypeenum<string>\nFee cap strategy: maxCap treats the fee as a maximum, exactFee uses the exact amount\nIgnored if neither priorityFeeLamports nor jitoTipLamports are set\nAvailable options: maxCap, exactFee ​excludeRoutersstring\nComma-separated list of routers to exclude\nAvailable routers: metis, jupiterz, dflow, okx\n​excludeDexesstring\nComma-separated list of DEXes to exclude from the Metis router\nImportant: This only affects the Metis router, not other routers\nFor example: excludeDexes=Raydium,Orca+V2,Meteora+DLMM\nLabels are case sensitive (SolFi, not solfi). Full list of DEXes here using the /program-id-to-label endpoint.\nOn /order only excludeDexes is honoured, not dexes. Use /build to restrict routing to specific DEXes.\n​maxSupportedTransactionVersionenum<string>default:0\nThe highest Solana transaction version your client can accept, \"0\" or \"1\". Defaults to \"0\".\nThis is a ceiling, not a force. You get v1 only when Metis wins the route and the order is not gasless; other routers and gasless orders (including automatic sponsorship for low-SOL takers) return v0. Wider v1 support is in progress.\nRead the response transactionVersion to see the version you got. v1 transactions must be deserialized and signed with a v1-capable SDK (@solana/kit v8 or later).\nAvailable options: 0, 1 ResponseQuote with optional assembled transaction​modestring\"ultra\" or \"manual\" based on parameters used​inputMintstring​outputMintstring​inAmountstring​outAmountstring​inUsdValuenumber​outUsdValuenumber​priceImpactnumberPrice impact in percentage points (e.g. -0.1 = -0.1%). Divide by 100 to convert to a decimal fraction.​swapUsdValuenumber​otherAmountThresholdstringMinimum output amount after slippage​swapModestring​slippageBpsnumber​priceImpactPctstringdeprecatedDeprecated: decimal price impact ratio. Use priceImpact divided by 100 instead.​routePlanobject[]Show child attributes​referralAccountstring​feeMintstring​feeBpsnumberTotal fee rate charged for the swap in basis points. This includes the Jupiter platform fee plus any additional charges, such as gasless support cost recoup.​platformFeeobjectShow child attributes​signatureFeeLamportsnumber​signatureFeePayerstring | null​prioritizationFeeLamportsnumberIncludes priority fees and tips (Jito, Nozomi)​prioritizationFeePayerstring | null​rentFeeLamportsnumberEstimated rent fee​rentFeePayerstring | null​swapTypeenum<string>deprecatedDeprecated: use router insteadAvailable options: aggregator, rfq, aggregator+rfq, dflow, okx ​routerenum<string>Which router won the quoteAvailable options: metis, jupiterz, dflow, okx ​transactionVersionenum<number>The Solana message version of transaction, 0 or 1. With maxSupportedTransactionVersion=1 this is 1 only when Metis wins the route and the order is not gasless, and 0 otherwise (other routers, and gasless orders including automatic sponsorship).Available options: 0, 1 ​transactionstring | null\nBase64-encoded transaction. Null if taker is not provided.\nEmpty string if taker is provided but transaction could not be built (check errorCode).\n​lastValidBlockHeightstring​gaslessbooleanTrue when signature and priority fees are paid by a wallet other than the taker. Set by three independent paths:\n\nAutomatic Jupiter sponsorship: signatureFeePayer = gasTzr94Pmp4Gf8vknQnqxeYxdgwFjbgdJa4msYRpnB\nJupiterZ market maker: signatureFeePayer is the MM address (varies per quote); Jupiter's gas wallet can pay the rent to create the taker's output token account when referral fees are not set\nIntegrator payer: signatureFeePayer is your payer parameter\nFor a deterministic opt-out, check signatureFeePayer == taker on every response.\n​requestIdstringUnique request ID. Pass this to /execute.​totalTimenumberResponse time in milliseconds​takerstring | null​quoteIdstringQuote ID for RFQ swaps​makerstringMarket maker address for RFQ swaps​expireAtstringQuote expiration timestamp for RFQ swaps​errorCodenumberPresent when taker is defined and transaction is the empty string. The router quoted a price but could not build a transaction. Match on router + errorCode to identify the error.\nAggregator routers (router is metis, dflow, okx):\n\n1: Insufficient funds\n2: Insufficient SOL for gas\n3: Swap below minimum for gasless\n\nJupiterZ router (router is jupiterz):\n\n1: Insufficient balance to fund the swap\n2: Missing associated token account\n3: Quote could not be built into a transaction\n​errorMessagestringHuman-readable error description. Present when taker is defined and transaction is the empty string.\nMatch on router + errorCode instead of this string, as the message text may be parameterised.​errorstringDuplicate of errorMessage for backwards compatibilityWas this page helpful?","tokens":3338,"squid":"spider-02","role":"Liquidity Spider","at":1791344934797,"hash":"8b463b547d65f4d3637565901a5418a7e28f58cd"}
{"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":"spider-08","role":"Oracle Spider","at":1791344948669,"hash":"1ddb6357c70c98614f7677912f028544041b2309"}
{"url":"https://www.metaplex.com/docs/smart-contracts/token-metadata/fetch","domain":"metaplex.com","title":"Fetching Assets | Token Metadata","text":"Token Metadata is a legacy program. It remains supported, but is not recommended for new projects. Use Core instead.Now that we know how to create and mint the various onchain accounts of our assets, let's learn how to fetch them. Digital AssetsAs mentioned in the previous page, an asset — fungible or not — requires multiple onchain accounts to be created. Depending on the Token Standard of the asset, some accounts may not be required. Here's a quick overview of these accounts:Mint account (from the SPL Token program): It defines the core properties of the underlying SPL token. This is the entry point to any asset as all other accounts derive from it.Metadata account: It provides additional data and features to the underlying SPL token.Master Edition or Edition account (only for Non-Fungibles): It enables printing multiple copies of an original NFT. Even when an NFT does not allow printing editions, the Master Edition account is still created as it is used as the Mint authority and Freeze authority of the Mint account to ensure its non-fungibility.In order to make fetching assets easier, our SDKs offer a set of helper methods that allow us to fetch all the relevant accounts of an asset in one go. We call the data type that stores all these accounts a Digital Asset. In the next sub-sections, we will go through the various ways to fetch Digital Assets.Digital Asset definitionimport { PublicKey } from '@metaplex-foundation/umi'\nimport { Mint } from '@metaplex-foundation/mpl-toolbox'\nimport {\n Metadata,\n MasterEdition,\n Edition,\n} from '@metaplex-foundation/mpl-token-metadata'\n\nexport type DigitalAsset = {\n publicKey: PublicKey\n mint: Mint\n metadata: Metadata\n edition?:\n | ({ isOriginal: true } & MasterEdition)\n | ({ isOriginal: false } & Edition)\n}\nFetch By MintThis helper fetches a single Digital Asset from the public key of its Mint account.1import { publicKey } from '@metaplex-foundation/umi';\n2import { fetchDigitalAsset } from '@metaplex-foundation/mpl-token-metadata';\n3\n4// Assuming umi is set up with mplTokenMetadata plugin\n5// See getting-started for full setup\n6\n7const mintAddress = publicKey('Ay1U9DWphDgc7hq58Yj1yHabt91zTzvV2YJbAWkPNbaK');\n8\n9// Fetch a digital asset by its mint address\n10const asset = await fetchDigitalAsset(umi, mintAddress);\n11\n12console.log('Asset:', asset.publicKey);\n13console.log('Metadata:', asset.metadata.publicKey);\n14console.log('Name:', asset.metadata.name);\n15console.log('URI:', asset.metadata.uri);\n16console.log('Seller Fee:', asset.metadata.sellerFeeBasisPoints);\n1import { address } from '@solana/addresses';\n2import { fetchDigitalAsset } from '@metaplex-foundation/mpl-token-metadata-kit';\n3\n4// Assuming rpc is set up\n5// See getting-started for full setup\n6\n7const mintAddress = address('Ay1U9DWphDgc7hq58Yj1yHabt91zTzvV2YJbAWkPNbaK');\n8\n9// Fetch a digital asset by its mint address\n10const asset = await fetchDigitalAsset(rpc, mintAddress);\n11\n12console.log('Asset:', asset.address);\n13console.log('Name:', asset.metadata.name);\n14console.log('URI:', asset.metadata.uri);\n15console.log('Seller Fee:', asset.metadata.sellerFeeBasisPoints);\n16if (asset.edition) {\n17 console.log('Is Original:', asset.edition.isOriginal);\n18}\nFetch By MetadataThis helper fetches a single Digital Asset from the public key of its Metadata account. This is slightly less efficient than the previous helper as we first need to fetch the content of the Metadata account to find the Mint address but if you only have access to the Metadata public key, this can be helpful.1import { publicKey } from '@metaplex-foundation/umi';\n2import { fetchDigitalAssetByMetadata } from '@metaplex-foundation/mpl-token-metadata';\n3\n4// Assuming umi is set up with mplTokenMetadata plugin\n5// See getting-started for full setup\n6\n7const metadataAddress = publicKey('Gz3vYbpsB2agTsAwedtvtTkQ1CG9Cpo6eTq59rrEGCKF');\n8\n9// Fetch a digital asset by its metadata address\n10const asset = await fetchDigitalAssetByMetadata(umi, metadataAddress);\n11\n12console.log('Asset:', asset.publicKey);\n13console.log('Metadata:', asset.metadata.publicKey);\n14console.log('Name:', asset.metadata.name);\n15console.log('URI:', asset.metadata.uri);\n1import { address } from '@solana/addresses';\n2import { fetchDigitalAssetByMetadata } from '@metaplex-foundation/mpl-token-metadata-kit';\n3\n4// Assuming rpc is set up\n5// See getting-started for full setup\n6\n7const metadataAddress = address('Gz3vYbpsB2agTsAwedtvtTkQ1CG9Cpo6eTq59rrEGCKF');\n8\n9// Fetch a digital asset by its metadata address\n10const asset = await fetchDigitalAssetByMetadata(rpc, metadataAddress);\n11\n12console.log('Asset:', asset.address);\n13console.log('Name:', asset.metadata.name);\n14console.log('URI:', asset.metadata.uri);\nFetch All By Mint ListThis helper fetches as many Digital Assets as there are Mint public keys in the provided list.1import { publicKey } from '@metaplex-foundation/umi';\n2import { fetchAllDigitalAsset } from '@metaplex-foundation/mpl-token-metadata';\n3\n4// Assuming umi is set up with mplTokenMetadata plugin\n5// See getting-started for full setup\n6\n7const mints = [\n8 publicKey('Ay1U9DWphDgc7hq58Yj1yHabt91zTzvV2YJbAWkPNbaK'),\n9 publicKey('8TQdiAzdZZEaKtHGjvnLMXhVGjfNsqMgPGBQPPsWYgo8'),\n10];\n11\n12// Fetch multiple digital assets by their mint addresses\n13const assets = await fetchAllDigitalAsset(umi, mints);\n14\n15assets.forEach((asset) => {\n16 console.log('Asset:', asset.publicKey);\n17 console.log('Name:', asset.metadata.name);\n18});\n1import { address } from '@solana/addresses';\n2import { fetchAllDigitalAsset } from '@metaplex-foundation/mpl-token-metadata-kit';\n3\n4// Assuming rpc is set up\n5// See getting-started for full setup\n6\n7const mints = [\n8 address('Ay1U9DWphDgc7hq58Yj1yHabt91zTzvV2YJbAWkPNbaK'),\n9 address('8TQdiAzdZZEaKtHGjvnLMXhVGjfNsqMgPGBQPPsWYgo8'),\n10];\n11\n12// Fetch multiple digital assets by their mint addresses\n13const assets = await fetchAllDigitalAsset(rpc, mints);\n14\n15assets.forEach((asset) => {\n16 console.log('Asset:', asset.address);\n17 console.log('Name:', asset.metadata.name);\n18});\nFetch All By CreatorThis helper fetches all Digital Assets by creator. Since creators can be located in five different positions in the Metadata account, we must also provide the creator position we are interested in. For instance, if we know that for a set of NFTs, the first creator is creator A and the second creator B, we will want to search for creator A in position 1 and creator B in position 2.This helper requires RPC calls to filter accounts and is available in the Umi SDK. For the Kit SDK, consider using a DAS (Digital Asset Standard) API provider for efficient queries.1import { publicKey } from '@metaplex-foundation/umi';\n2import { fetchAllDigitalAssetByCreator } from '@metaplex-foundation/mpl-token-metadata';\n3\n4// Assuming umi is set up with mplTokenMetadata plugin\n5// See getting-started for full setup\n6\n7const creator = publicKey('creatorAddress...');\n8\n9// Assets where the creator is first in the Creator array\n10const assetsA = await fetchAllDigitalAssetByCreator(umi, creator);\n11\n12// Assets where the creator is second in the Creator array\n13const assetsB = await fetchAllDigitalAssetByCreator(umi, creator, {\n14 position: 2,\n15});\n16\n17console.log('Assets with creator at position 1:', assetsA.length);\n18assetsA.forEach((asset) => {\n19 console.log('Name:', asset.metadata.name);\n20});\nFetch All By OwnerThis helper fetches all Digital Assets by owner.This helper requires RPC calls to filter accounts and is available in the Umi SDK. For the Kit SDK, consider using a DAS (Digital Asset Standard) API provider for efficient queries.1import { publicKey } from '@metaplex-foundation/umi';\n2import { fetchAllDigitalAssetByOwner } from '@metaplex-foundation/mpl-token-metadata';\n3\n4// Assuming umi is set up with mplTokenMetadata plugin\n5// See getting-started for full setup\n6\n7const owner = publicKey('ownerAddress...');\n8\n9// Fetch all digital assets owned by a wallet\n10const assets = await fetchAllDigitalAssetByOwner(umi, owner);\n11\n12assets.forEach((asset) => {\n13 console.log('Name:', asset.metadata.name);\n14 console.log('URI:', asset.metadata.uri);\n15});\nFetch All By Update AuthorityThis helper fetches all Digital Assets from the public key of their update authority.This helper requires RPC calls to filter accounts and is available in the Umi SDK. For the Kit SDK, consider using a DAS (Digital Asset Standard) API provider for efficient queries.1import { publicKey } from '@metaplex-foundation/umi';\n2import { fetchAllDigitalAssetByUpdateAuthority } from '@metaplex-foundation/mpl-token-metadata';\n3\n4// Assuming umi is set up with mplTokenMetadata plugin\n5// See getting-started for full setup\n6\n7const updateAuthority = publicKey('updateAuthorityAddress...');\n8\n9// Fetch all digital assets by update authority\n10const assets = await fetchAllDigitalAssetByUpdateAuthority(umi, updateAuthority);\n11\n12console.log('Found', assets.length, 'assets');\n13assets.forEach((asset) => {\n14 console.log('Name:', asset.metadata.name);\n15 console.log('Mint:', asset.publicKey);\n16});\nDigital Assets With TokenNote that the Digital Asset data structure mentioned above does not provide any information about the owner of the asset. This first definition only focuses on the onchain accounts that are required regardless of their owners. However, in order to provide a more complete picture of an asset, we may also need to know who owns it. This is where the Digital Asset With Token data structure comes in. It is an extension of the Digital Asset data structure that also includes the following accounts:Token account (from the SPL Token program): It defines the relationship between a Mint account and its owner. It stores important data such as the amount of tokens owned by the owner. In the case of NFTs, the amount is always 1.Token Record account (for PNFTs only): It defines additional token-related information for Programmable Non-Fungibles such as its current Token Delegate and its role.Note that, for fungible assets, the same Digital Asset will likely be associated with multiple owners via multiple Token accounts. Therefore, there can be multiple Digital Asset With Token for the same Digital Asset.Here as well, we offer a set of helpers to fetch Digital Assets With Token.Digital Asset With Token definitionimport { Token } from '@metaplex-foundation/mpl-toolbox'\nimport {\n DigitalAsset,\n TokenRecord,\n} from '@metaplex-foundation/mpl-token-metadata'\n\nexport type DigitalAssetWithToken = DigitalAsset & {\n token: Token\n tokenRecord?: TokenRecord\n}\nFetch By MintThis helper fetches a single Digital Asset With Token from the public key of its Mint account. This is mostly relevant for Non-Fungible assets since it will only return one Digital Asset With Token, regardless of how many exist for a Fungible asset.The Kit SDK requires knowing either the token address or the owner. Use the \"Fetch By Mint and Owner\" helper below if you know the owner.1import { publicKey } from '@metaplex-foundation/umi';\n2import { fetchDigitalAssetWithTokenByMint } from '@metaplex-foundation/mpl-token-metadata';\n3\n4// Assuming umi is set up with mplTokenMetadata plugin\n5// See getting-started for full setup\n6\n7const mint = publicKey('Ay1U9DWphDgc7hq58Yj1yHabt91zTzvV2YJbAWkPNbaK');\n8\n9// Fetch a digital asset with its token account by mint address\n10const asset = await fetchDigitalAssetWithTokenByMint(umi, mint);\n11\n12console.log('Asset:', asset.publicKey);\n13console.log('Name:', asset.metadata.name);\n14console.log('Token Owner:', asset.token.owner);\n15console.log('Token Amount:', asset.token.amount);\nFetch By Mint and OwnerThis helper is more performant than the previous helper but requires that we know the owner of the asset.1import { publicKey } from '@metaplex-foundation/umi';\n2import { fetchDigitalAssetWithAssociatedToken } from '@metaplex-foundation/mpl-token-metadata';\n3\n4// Assuming umi is set up with mplTokenMetadata plugin\n5// See getting-started for full setup\n6\n7const mint = publicKey('Ay1U9DWphDgc7hq58Yj1yHabt91zTzvV2YJbAWkPNbaK');\n8const owner = publicKey('ownerAddress...');\n9\n10// Fetch a digital asset with its associated token account\n11const asset = await fetchDigitalAssetWithAssociatedToken(umi, mint, owner);\n12\n13console.log('Asset:', asset.publicKey);\n14console.log('Name:', asset.metadata.name);\n15console.log('Token Owner:', asset.token.owner);\n16console.log('Token Amount:', asset.token.amount);\n1import { address } from '@solana/addresses';\n2import { fetchDigitalAssetWithAssociatedToken } from '@metaplex-foundation/mpl-token-metadata-kit';\n3\n4// Assuming rpc is set up\n5// See getting-started for full setup\n6\n7const mintAddress = address('Ay1U9DWphDgc7hq58Yj1yHabt91zTzvV2YJbAWkPNbaK');\n8const ownerAddress = address('ownerAddress...');\n9\n10// Fetch a digital asset with its associated token account\n11const asset = await fetchDigitalAssetWithAssociatedToken(rpc, mintAddress, ownerAddress);\n12\n13console.log('Asset:', asset.address);\n14console.log('Name:', asset.metadata.name);\n15console.log('Token Owner:', asset.token.owner);\n16console.log('Token Amount:', asset.token.amount);\nFetch All By OwnerThis helper fetches all Digital Assets With Token from a given owner.This helper requires RPC calls to filter accounts and is available in the Umi SDK. For the Kit SDK, consider using a DAS (Digital Asset Standard) API provider for efficient queries.1import { publicKey } from '@metaplex-foundation/umi';\n2import { fetchAllDigitalAssetWithTokenByOwner } from '@metaplex-foundation/mpl-token-metadata';\n3\n4// Assuming umi is set up with mplTokenMetadata plugin\n5// See getting-started for full setup\n6\n7const owner = publicKey('ownerAddress...');\n8\n9// Fetch all digital assets with their token accounts by owner\n10const assets = await fetchAllDigitalAssetWithTokenByOwner(umi, owner);\n11\n12console.log('Found', assets.length, 'assets');\n13assets.forEach((asset) => {\n14 console.log('Name:', asset.metadata.name);\n15 console.log('Token Amount:', asset.token.amount);\n16});\nFetch All By MintThis helper fetches all Digital Assets With Token from the public key of a Mint account. This is particularly relevant for Fungible assets since it fetches all Token accounts.This helper requires RPC calls to filter accounts and is available in the Umi SDK. For the Kit SDK, consider using a DAS (Digital Asset Standard) API provider for efficient queries.1import { publicKey } from '@metaplex-foundation/umi';\n2import { fetchAllDigitalAssetWithTokenByMint } from '@metaplex-foundation/mpl-token-metadata';\n3\n4// Assuming umi is set up with mplTokenMetadata plugin\n5// See getting-started for full setup\n6\n7const mint = publicKey('Ay1U9DWphDgc7hq58Yj1yHabt91zTzvV2YJbAWkPNbaK');\n8\n9// Fetch all token accounts for a given mint\n10const assets = await fetchAllDigitalAssetWithTokenByMint(umi, mint);\n11\n12console.log('Found', assets.length, 'token accounts');\n13assets.forEach((asset) => {\n14 console.log('Owner:', asset.token.owner);\n15 console.log('Amount:', asset.token.amount);\n16});\nFetch All By Owner and MintThis helper fetches all Digital Assets With Token from both an owner and a Mint account. This can be useful for Fungible assets that have more than one Token account for a given owner.This helper requires RPC calls to filter accounts and is available in the Umi SDK. For the Kit SDK, consider using a DAS (Digital Asset Standard) API provider for efficient queries.1import { publicKey } from '@metaplex-foundation/umi';\n2import { fetchAllDigitalAssetWithTokenByOwnerAndMint } from '@metaplex-foundation/mpl-token-metadata';\n3\n4// Assuming umi is set up with mplTokenMetadata plugin\n5// See getting-started for full setup\n6\n7const owner = publicKey('ownerAddress...');\n8const mint = publicKey('Ay1U9DWphDgc7hq58Yj1yHabt91zTzvV2YJbAWkPNbaK');\n9\n10// Fetch all token accounts for a given owner and mint\n11const assets = await fetchAllDigitalAssetWithTokenByOwnerAndMint(umi, owner, mint);\n12\n13console.log('Found', assets.length, 'token accounts');\n14assets.forEach((asset) => {\n15 console.log('Token Address:', asset.token.publicKey);\n16 console.log('Amount:', asset.token.amount);\n17});","tokens":4029,"squid":"spider-10","role":"Tooling Spider","at":1791344955249,"hash":"4f36e683ed7b8688ff793390ab2abc5a9c0d6be2"}
{"url":"https://developer.arbitrum.io/launch-arbitrum-chain/operate/state-growth","domain":"developer.arbitrum.io","title":"Managing state growth and corresponding issues","text":"Operate your chainManaging state growth and corresponding issuesLearn about state growth and corresponding issuesRequest an updateAs the Arbitrum ecosystem grows, more and more teams are choosing to build on the Arbitrum tech stack. Arbitrum chains offer a feature-rich and scalable Rollup stack that allows teams to focus on their ecosystem growth and build great products. As a result, many Arbitrum chains are seeing usage and throughput increase rapidly, often with sustained transaction load at the chain’s throughput limit for months on end.\nThis page aims to educate Arbitrum chain operators and owners on safely operating a high throughput chain. Amongst all the factors, the primary consideration is state growth rate and state size. We’ll discuss how increased state size affects the performance of different components in the Arbitrum chain stack and how certain metrics can be used to indicate a need to upgrade various infrastructure components.\nUnderstanding state size and state growth rate\nWhen we say ‘state size’, we mean the total amount of data recorded on the blockchain; state size is a critical metric for node performance as a larger state creates higher infrastructure requirements on nodes for storage and searching through existing states.\nThe state growth rate is simply the rate at which state size increases. A high state growth rate creates higher requirements for nodes to process state transitions and perform operations needed to keep up with the tip of the chain.\nThe critical Nitro stack parameter affecting state growth and state growth rate is the gas target. Offchain Labs has built an algorithm to ensuring a safe, sustained operating limit for Arbitrum chains. You can read more about the nuances of the gas target here.\nThe default gas target is designed to ensure Arbitrum chains operate performantly and sustainably.\nBehaviour at ultra-high throughput\nAt high state growth rates, especially in cases where a chain is pushing past prescribed limits, an Arbitrum chain may display certain behaviors that either indicate or result from the chain load being higher than its infrastructure can support. The following is a list of such behaviors.\n1. Read Operation Bottleneck at High Disk Latency\nAs the number of read requests on a chain grows, the impact of disk latency on performance becomes more pronounced. The performance impact can be considered the total amount of read requests made as a multiple of the disk latency. High read request volumes may necessitate switching to using low-latency local NVMe drives.\n2. Increased single-core CPU and RAM Utilization\nObserving high utilization on single-core CPU and RAM indicates that you may require more performant hardware. As this trend continues, hardware investments become prohibitively expensive for the ecosystem or require increasingly custom solutions, which decreases accessibility for node runners.\n3. Increased Total State Database Size\nThe accelerated state database growth rate, on the order of multiple terabytes of data per month, indicates that your chain may require increasing drive sizes. Played out over time, this may force node runners on the chain to adopt prohibitively expensive or hard-to-procure drives (e.g., those notes available on major cloud providers).\n4. Increased Disk Write Operations per Second\nThe number of write operations per second directly correlates to state size growth. As the state growth rate increases, ecosystem nodes that aren’t properly resourced may fall out of sync with the chain.\n5. Sync from Genesis Time\nAs state size increases, the time a new node needs to catch up to the chain also increases. A large state size and state growth rate can result in new nodes catching up to the chain in the worst case.\nSummary of symptoms, mitigations, risks\nThe general trend with any issue in the table below is as follows:\n\nThe simple resolutions involve moving to more expensive infrastructure.\nWhen simple resolutions are exhausted, infrastructure becomes both expensive and bespoke (options that available cloud providers do not support)\nThe long-term risk (and point of no return) is when infrastructure requirements are too expensive or too inaccessible for node runners.\n\nBehaviourRiskMitigations & ConsiderationsPerformance degradation due to storage reads at high disk latencyAn increase in read operations causes nodes to spend more accessing disk state. As the number of read operations increases, these delays can degrade chain performance.Upgrade drives to local NVMe (PCIe Gen4/Gen5, not configured with RAID) with higher speeds. In the short term, NVMe usage will greatly increase the cost of node runners. In the extreme, you may run out of usable drive specifications on available infrastructure vendors.Growing or constant sequencer backlog (using arb_sequencer_backlog) over a sustained period.Seeing a growing or persistent backlog implies that nodes cannot keep up with the transaction load accepted by the sequencer.Large state database size and high growth rate of the state databaseA large state database size will require that nodes run more expensive disks. This reduces the economic feasibility for node runners. In extreme cases, the required disk size may be unsupported by accessible cloud service providers.The primary resolution is to upgrade the disk size requirement for nodes on your chain.High utilization of single-core CPU and RAMAs with the cases above, this symptom implies a need to upgrade hardware. The main risk is the economic feasibility and long-term accessibility of new hardware options.The only resolution is to upgrade your node’s CPU and RAM.How is this guide?Sequencer troubleshootingDiagnose and resolve sequencer feed problems, broadcast backlog errors, feed stalls, and the conditions that stop block production.Upgrade runbookAn end-to-end operational checklist for upgrading an Arbitrum chain, covering pre-upgrade validation, execution order, post-upgrade verification, WASM module root troubleshooting, and rollback options.","tokens":1506,"squid":"spider-01","role":"Chain Spider","at":1791344958021,"hash":"c93f49410d461355eaf912b90b3c4d35e483db54"}
{"url":"https://developer.arbitrum.io/launch-arbitrum-chain/operate/validator-troubleshooting","domain":"developer.arbitrum.io","title":"Validator troubleshooting","text":"Operate your chainValidator troubleshootingDiagnose and resolve common validator operational issues, including assertion timing flags, parent-chain read consistency, assertion errors, stuck transactions, and manual assertion confirmation.Request an updateThis guide covers operational issues that operators encounter after setup, with guidance on diagnosing root causes and resolving them. For initial setup, see How to run a validator. For the metrics and alerts to watch, see the validator section of Monitoring tools and considerations. For sequencing a upgrade, see the BoLD upgrade playbook.\nMost of this guide applies to both the legacy staker and the staker. Where behavior differs, this guide calls it out.\nValidation strategies in operation\nThe validator setup guide describes what each strategy does. This section covers the operational consequences that are easy to get wrong.\nStrategyOperational notesWatchtowerDefault. Takes no onchain action and needs no or bond. Logs: found incorrect assertion in watchtower mode (legacy) or Detected invalid assertion, but not configured to post a rival stake (BoLD) on disagreement.DefensiveActs only when it finds a bad : it bonds and posts the correct rival assertion. On a BoLD chain it does not open the itself — that requires ResolveNodes or MakeNodes. Idle in normal operation, so an absence of onchain activity is not a fault signal.StakeLatestPre-BoLD chains only. Not available on BoLD chains.ResolveNodesResolves assertions that already exist — on legacy chains it bonds on them; on BoLD chains it confirms them and can open challenges. It does not create routine successor assertions (it still posts the correct rival when it detects a bad one), so a chain whose validators are all ResolveNodes will stop advancing. At least one MakeNodes validator is required to post new assertions.MakeNodesCreates assertions, resolves unconfirmed ones, and challenges bad ones.\nSwitching strategy does not re-bondA validator bonds once. Changing strategy—for example from MakeNodes to Defensive—does not place a new bond, and does not require one. If you are troubleshooting a validator that will not act after a strategy change, the bond is not the thing to check; look at wallet gas balance, allowlist membership, and parent-chain connectivity instead.\nMultiple MakeNodes validators produce expected revertsIf more than one MakeNodes validator runs on the same chain, they may attempt to create the same assertion simultaneously. Only one succeeds; the others revert. These reverts are normal contention, not a malfunction. Do not alert on them individually—alert on assertions failing to appear at all. See arb/validator/poster/error_posting_assertion for the counter to watch, and expect a nonzero baseline when you run redundant .\nAssertion timing flags\nFour flags control assertion timing, and they are frequently confused with one another. None of them takes a -duration suffix, despite that form circulating in support threads.\nFlagDefaultApplies toWhat it controls--node.bold.assertion-posting-interval15m0sBoLD stakerHow often this validator posts a new assertion.--node.staker.make-assertion-interval1h0m0sLegacy stakerHow often a MakeNodes validator creates assertions. Bypassed during a dispute. Has no effect on BoLD chains.--node.bold.minimum-gap-to-parent-assertion1m0sBoLD stakerMinimum time to wait after the parent assertion was created before posting a child. A floor between consecutive assertions, distinct from the posting cadence above.--node.bold.assertion-confirming-interval1m0sBoLD stakerHow often the validator checks whether a pending assertion can be confirmed. This is a polling interval, not a delay before confirmation is permitted.\nTwo rules to check when tuning these:\n\nThe posting interval must exceed the Rollup contract's minimumAssertionPeriod. That is an onchain constraint measured in blocks (block.number units — on an Arbitrum parent these track the underlying L1 block number, not the Arbitrum block height). The validator checks it before posting and waits until enough blocks have passed, so a shorter posting interval silently caps you at the onchain floor rather than causing reverted transactions. Read minimumAssertionPeriod from your Rollup contract rather than assuming the default.\nDo not tune the confirming interval to make confirmations happen sooner. Confirmation timing is governed onchain by confirmPeriodBlocks and, where a challenge occurred, challengeGracePeriodBlocks. Lowering --node.bold.assertion-confirming-interval only increases how often the validator checks, which adds parent-chain RPC load without advancing anything.\n\nFor the full flag list, see the Nitro CLI flags reference. For the onchain parameters, see the parameter table in BoLD for Arbitrum chains.\nParent-chain read consistency\n--node.bold.rpc-block-number determines which block the BoLD staker reads onchain data from. It accepts finalized (the default), safe, or latest.\nValueTrade-offfinalizedDefault and safest. The validator only acts on data that cannot be reorganized, at the cost of lagging roughly two epochs behind on an Ethereum parent chain.safeShorter lag, small exposure.latestNo lag, full exposure. The validator may act on data that later disappears.\nerror initializing staker: could not create assertion chain: no contract code at given address\nThis is the most common symptom of the default finalized setting, and it usually appears immediately after a BoLD upgrade.\nCause: the validator is reading at the finalized block, and the block containing the new Rollup contract deployment has not finalized yet. From the validator's point of view, no contract exists at the configured address.\nResolution: wait for the upgrade transactions to finalize, then start the node again. This is expected behavior and not a misconfiguration. Do not switch to latest to work around it. That permanently exposes the validator to acting on data that a reorg can undo, to solve a problem that resolves itself in minutes.\nCheck as well that rollup.rollup in --chain.info-json points at the new Rollup address, and that rollup.stake-token is set. A stale rollup.rollup produces the same error and does not resolve on its own.\nAssertion errors\nASSERTION_NOT_EXIST\nA revert from the Rollup contract. It originates in requireExists, which rejects any assertion whose status is NoAssertion:\nrequire(self.status != AssertionStatus.NoAssertion, \"ASSERTION_NOT_EXIST\");\nIn other words, the validator referenced an assertion hash that the Rollup contract has no record of.\nThis is almost never a protocol fault. The usual causes are environmental:\n\nUnsynced node. The validator computed state from a chain it has not fully caught up on, and referenced an assertion that does not exist onchain.\nRPC inconsistency. A parent-chain endpoint behind a load balancer can serve reads from nodes at different heights, so the validator sees an assertion in one request and not in the next. Point the validator at a single consistent endpoint.\nReorg exposure. With --node.bold.rpc-block-number=latest, an assertion the validator observed may have been reorganized away.\n\nResolution: confirm the node is fully synced, verify the parent-chain endpoint returns consistent results, and confirm the Rollup address in --chain.info-json is correct. Move to finalized if you are running latest.\nfound incorrect assertion in watchtower mode\nThe node's locally computed state disagrees with an assertion posted onchain. The legacy staker logs found incorrect assertion in watchtower mode; on a BoLD chain the same condition is logged as Detected invalid assertion, but not configured to post a rival stake. On a healthy chain this warrants immediate investigation—it is the signal watchtower mode exists to produce.\nBefore escalating, rule out local causes: an unsynced or partially synced node, a mismatched Nitro version, or a wrong --chain.info-json will all produce local state that legitimately disagrees with a correct onchain assertion. Confirm the disagreement against a second, independently operated node before treating it as a real dispute.\nStuck validator transactions\nIf a validator transaction has been pending for more than roughly 10 minutes, it is stuck rather than slow.\nThe staker queues only one transaction by default--node.staker.data-poster.max-mempool-transactions defaults to 1, compared to 18 for the . A single stuck transaction therefore blocks every subsequent validator action until it clears. This is the first thing to check, and the difference from batch poster behavior surprises most operators.\nWork through these in order:\n\nRaise the queue depth. Increase --node.staker.data-poster.max-mempool-transactions so that one pending transaction does not stall the whole validator. Increase it deliberately rather than setting 0 (unlimited), which removes the backpressure that prevents runaway submission.\nCheck the fee cap against current parent-chain gas prices. If parent-chain gas has risen above what the data poster will bid, the network will not include the transaction. Raise the relevant fee cap.\nAccelerate the transaction manually. Resubmit at a higher gas price from the same account and nonce to replace it. Keep the nonce identical—submitting a new nonce leaves the original stuck and creates a gap.\nConfirm the wallet is funded. The validator needs parent-chain native currency for gas, separately from its ERC-20 bond token. Watch arb/staker/balance.\n\nConfirming an assertion manually\nIf assertions are pending well past the confirmation period and no validator is confirming them, a validator can call confirmAssertion on the Rollup contract directly:\nfunction confirmAssertion(\n bytes32 assertionHash,\n bytes32 prevAssertionHash,\n AssertionState calldata confirmState,\n bytes32 winningEdgeId,\n ConfigData calldata prevConfig,\n bytes32 inboxAcc\n) external onlyValidator(msg.sender) whenNotPaused\nTreat this as a recovery tool, not a routine operation. A healthy validator confirms assertions on its own, so needing this manually points at an underlying problem—usually a stopped validator, an unfunded wallet, or a strategy set that contains no validator willing to resolve.\nBefore attempting it, note the constraints:\n\nIt is not permissionless. onlyValidator restricts the caller to the allowlist on a permissioned chain. If you misconfigured the allowlist, fix it first.\nprevAssertionHash must be the current latest confirmed assertion. Assertions confirm in order; you cannot skip ahead.\nconfirmPeriodBlocks must have elapsed since the assertion was created.\nIf the parent assertion has more than one child, a occurred. The winning must be confirmed, and challengeGracePeriodBlocks must have elapsed since that edge was confirmed. The grace period exists to give the or security council a window to intervene—do not attempt to route around it.\n\nRelated monitoring\nAssertion-progress and failure signals, including which metrics apply to the legacy staker versus the BoLD staker and the validatorAfkBlocks allowlist caution, are documented in the validator section of Monitoring tools and considerations.How is this guide?Upgrade runbookAn end-to-end operational checklist for upgrading an Arbitrum chain, covering pre-upgrade validation, execution order, post-upgrade verification, WASM module root troubleshooting, and rollback options.ConceptsConcepts documentation","tokens":2843,"squid":"spider-01","role":"Chain Spider","at":1791344967935,"hash":"fa917608bc8aedbc850aed4a7a57af9010000e76"}
{"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":"spider-08","role":"Oracle Spider","at":1791344971020,"hash":"0bf6264d5d99820ebaa327768ebeaa6ffebb7a0b"}
{"url":"https://developer.arbitrum.io/launch-arbitrum-chain/operate/upgrade-runbook","domain":"developer.arbitrum.io","title":"Arbitrum chain upgrade runbook","text":"Operate your chainArbitrum chain upgrade runbookAn end-to-end operational checklist for upgrading an Arbitrum chain, covering pre-upgrade validation, execution order, post-upgrade verification, WASM module root troubleshooting, and rollback options.Request an updateThis runbook is the operational wrapper around an upgrade: what to validate before you start, what order to execute in, how to confirm the upgrade succeeded, and what you can undo if it doesn't.\nIt complements ArbOS upgrade, which remains the canonical reference for how each individual step works. This page does not restate those mechanics—it links to them at each step and focuses on the coordination, verification, and failure-recovery work around them.\nAn upgrade touches five things that must stay mutually compatible:\n\nThe version running on every node and .\nThe nitro-contracts deployed on the .\nThe set in the Rollup contract.\nThe machines on each validator's disk—one per root the validator must validate (current and pending). A new Nitro version alone doesn't guarantee they are present.\nThe version active on the .\n\nMost failed upgrades are a mismatch between two of these five, and the majority are mismatches between the onchain root (3) and the machines on validators (4). Troubleshoot WASM module root failures covers those in detail.\nArbOS upgrades are one-wayOnce an ArbOS upgrade activates, you cannot downgrade the ArbOS version. Plan on rolling forward, not back. Read Rollback options before you schedule an upgrade, so you know which parts of the process are reversible and which aren't.The Nitro version and the ArbOS version are independent: Nitro is per-node software you can deploy and roll back; the ArbOS version is chain-wide state, moved only by scheduleArbOSUpgrade. Upgrading Nitro does not change the chain's ArbOS version.\nRecord your target versions\nEvery version-specific value comes from the reference page for the ArbOS release you're targeting. Record all five before you begin, because later steps consume them as inputs:\nInputWhere to get itTarget ArbOS versionThe list of available ArbOS releasesMinimum Nitro versionThe requirements section of the targeted ArbOS release pagenitro-contracts versionThe targeted ArbOS release page. Not every ArbOS upgrade requires a contracts upgradeWASM module rootThe targeted ArbOS release pageConsensus tagThe consensus version paired with that WASM module root (for example, consensus-v51). Cross-check the pairing against the Dockerfile in the Nitro repository\nWhy the consensus tag mattersThe consensus tag and the WASM module root are two names for the same artifact, and scripts/download-machine.sh requires both as arguments. Release pages sometimes reference point releases (for example, consensus-v51.1) that carry a different module root than the base tag. Record the exact pair you intend to run, and confirm it against the Dockerfile in the Nitro repository, which is the source of truth for which tag maps to which root.\nPre-upgrade validation\nComplete every check in this section before scheduling anything onchain.\nConfirm your current ArbOS version\nCall ArbSys.ArbOSVersion() on your chain. This function returns the ArbOS version plus 55—a chain running ArbOS 40 returns 95. When you later schedule the upgrade, you pass the real version number, not the offset one. See Obtaining the current ArbOS version for details.\nConfirm your current contracts version and upgrade path\nDetermine which nitro-contracts version your chain currently runs and whether a direct upgrade path to the target exists. Follow Check version and upgrade path in the chain-actions repository, substituting your chain's inbox address and network name.\nContract upgrades are not always a single hop. Confirm the full path now rather than discovering a required intermediate version mid-upgrade.\nConfirm chain owner access\nEvery administrative action in this runbook is executed by the contract, not directly by your account. Before you begin, verify that:\n\nYou control an account with the executor role on the parent chain upgrade executor.\nThat account is funded on the parent chain.\nYou can reach the child chain upgrade executor, which owns the ArbOwner actions.\n\nSee Ownership and access to confirm which account holds which role.\nConfirm the target machine is present on every validator\nThis is the check that most often gets skipped, and it's the one that causes the failures in Troubleshoot WASM module root failures. Verify that each validator has the machine for the target WASM module root on disk before you set that root onchain—not after the upgrade activates.\nMachines are discovered by directory layout, so inspect the directory directly:\nls -l /home/user/.arbitrum/machines/\ncat /home/user/.arbitrum/machines/latest/module-root.txt\nA correctly populated machines directory looks like this:\nmachines/\n├── latest -> 0x8a7513bf... # symlink to the newest machine directory\n└── 0x8a7513bf.../ # directory name must equal the module root\n ├── module-root.txt # contains 0x8a7513bf...\n ├── machine.v2.wavm.br\n └── replay.wasm # only present if the release publishes it\nStaging the machine is only half the check. The block validator reads its machine list and resolves its pending root once, at startup, so restart each validator after staging and confirm the startup log before you set the root onchain:\nINFO BlockValidator initialized current=0x8a7513bf... pending=0xc2c02df5...\npending must equal your target root. If it doesn't, the validator will refuse the onchain root change in step 3. Don't defer this to post-upgrade verification—by then the root is already set.\nWASM module roots are backward compatibleYou can stage the machines on your validators and set the new WASM module root well before the ArbOS upgrade activates. Doing so does not disrupt the chain, so there's no reason to leave it until the last moment.Order matters within that window, though: stage the machine on each validator and restart it first, then set the root onchain. A running validator only follows an onchain root change if its pending root already resolves to the new root, and it resolves that root at startup.\nDetermine whether you need download-machine.sh\nscripts/download-machine.sh in the Nitro repository fetches a prebuilt WAVM machine for a given consensus tag. Whether you need to run it depends entirely on how you obtain your node binary:\nYour setupDo you need download-machine.sh?Official Docker image, no customizationNo. Machines are already baked into the imageBuilding the Docker image from sourceUsually yes. The Dockerfile only downloads the machines on its uncommented RUN ./download-machine.sh linesCustom STF buildYes, and you must also rebuild the replay binary so the resulting module root matches what you set onchain\nThe Dockerfile only downloads recent machinesIn the Nitro repository's Dockerfile, the RUN ./download-machine.sh lines for older consensus versions are commented out—only the most recent few are active. If your chain's Rollup contract still points at an older module root, a from-source build produces an image with no machine for that root, and your validator fails to start.This is the single most common cause of the startup failures described below. Check the Dockerfile for a line matching your consensus version before assuming the image contains it.\nTo fetch a machine manually, run the script from your machines directory with both the consensus tag and its module root:\ncd /home/user/.arbitrum/machines\n./download-machine.sh consensus-v51.1 0xc2c02df561d4afaf9a1d6785f70098ec3874765c638e3cb6dbe8d3c83333e14c\nThe script creates a directory named after the module root, writes module-root.txt inside it, repoints the latest symlink at it, and downloads machine.v2.wavm.br (plus replay.wasm, if that release published one).\nIf you maintain a custom STF, downloading a published machine is not sufficient—see Customize your chain's behavior to learn how to build and register your own.\nExecution order\nOrder matters. Each step assumes the previous one completed successfully.\nStepActionNotes1Update Nitro on nodes and validatorsValidators first, then remaining nodes. Must complete before the ArbOS upgrade deadline2Stage the target WAVM machine on every validator, then restart the validatorMust precede step 3. The block validator resolves its pending root at startup, so stage the machine before the step 1 restart and one restart covers both3Set the new WASM module rootSafe to do early, as long as every validator has been restarted with the target machine and its startup log shows pending=<target root>4Upgrade nitro-contracts, if the release requires itFollow Nitro contracts upgrades5Schedule the ArbOS version upgradePass the real version number and a UNIX timestamp. A timestamp of 0 upgrades immediately6Enable release-specific configuration or feature flagsNot always required; check the release page\nStage machines and restart before you set the root onchainA running validator adopts a new onchain root only if that root equals its pending root; anything else is refused with unexpected wasmModuleRoot! cannot validate!. The legacy staker then stops acting entirely, while only warns. Both the pending root and the machine list are read once, at startup, so staging a machine under a running validator does nothing—the validator must be restarted before step 3. See Understand which roots your validator is required to have.\nUpgrade nodes before the activation timestampA node that is too old to process the newly active ArbOS version stops with a fatal please upgrade to the latest version of the node software error. Because the ArbOS upgrade activates in consensus at the scheduled timestamp, every node must already be running a compatible Nitro version when that timestamp passes. Leave yourself margin.\nPost-upgrade verification\nWork through all four checks. A chain can look healthy on the surface while its validator is quietly unable to bond.\nVerify the active ArbOS version\nCall ArbSys.ArbOSVersion() again and confirm it advanced to your target, remembering the +55 offset. If the scheduled timestamp has passed and the version has not changed, the upgrade did not activate—check that you scheduled the correct version and that nodes are actually producing blocks past the timestamp.\nVerify the WASM module root matches everywhere\nCompare the root set in the Rollup contract against the root your validator resolved. Read the onchain value from the parent chain:\ncast call <rollup-address> \"wasmModuleRoot()(bytes32)\" --rpc-url <parent-chain-rpc>\nThen confirm your validator agrees. On startup, the block validator logs both roots it will validate against:\nINFO BlockValidator initialized current=0x8a7513bf... pending=0x8a7513bf...\nINFO validator chosen WasmModuleRoot=0x8a7513bf... chosen=jit maxWorkers=8\nThe current value should match the onchain wasmModuleRoot(). A validator chosen line appears for every root listed in BlockValidator initialized; if a machine for any root is missing, startup fails with cannot validate WasmModuleRoot.\nVerify the validator is bonding\nConfirm the validator is still advancing and posting bonds after the upgrade. A validator that started cleanly can still be unable to act if the Rollup contract's root doesn't match what the validator actually validated with—that produces the runtime mismatch described in The validator starts but can't advance its bond.\nIf your chain has enabled, re-check them specifically after the upgrade—see Fast withdrawals.\nVerify the batch poster is still posting\nConfirm the is submitting to the at its usual cadence, and that no backlog is accumulating. See Monitoring tools and considerations for what to watch.\nBatch poster log noise after an upgradeNew Nitro versions probe for contract features that older nitro-contracts deployments don't implement, so a version-skewed window between steps 1 and 4 can produce eth_call errors in the log that are benign. Confirm batches are still landing onchain before treating any of them as an incident. To diagnose messages that persist after the upgrade completes, see Batch poster troubleshooting and Batch poster recovery.\nTroubleshoot WASM module root failures\nThese failures share a single root cause—the validator does not have, or hasn't loaded, the machine for a module root it's required to handle—but they surface at three different severities: fatal at startup, non-fatal at startup, and at runtime. Identify which one you have before changing any configuration.\nError messageNode starts?What it meanslatestWasmModuleRoot not setNoNo machine directory was found at allcannot validate WasmModuleRoot <root>NoMachines were found, but none provides this specific required rootunable to find validator machine directory for the on-chain WASM module rootYesStartup compatibility pre-check failed. Logged at ERROR, but does not stop the nodeon-chain WASM module root did not match with any of the allowed WASM module rootsYesSame pre-check, when --validation.wasm.allowed-wasm-module-roots is set and nothing matchedwasmroot doesn't match rollup : <root>, valid: [<roots>]YesRuntime mismatch. The validator runs but cannot advance its bondunexpected wasmModuleRoot! cannot validate! found <onchain>, current <x>, pending <y>YesThe onchain root changed to a root that is neither the validator's current nor its pending root, so the validator refuses to adopt it. The legacy staker then stops acting entirely; logs a warning and continues\nOperators upgrading Nitro have reported the two fatal cases wrapped in a failed to create node startup error (failed to create consensus node on newer versions); the specific message quoted in that error tells you which one you're looking at.\nThe node won't start\nFor either fatal case, work through these in order:\n\nCheck the Dockerfile for your consensus version. If you built the image from source, confirm there's an uncommented RUN ./download-machine.sh line for the consensus tag your chain needs. This is the most common cause.\nRun download-machine.sh with the correct version. Fetch the machine for the exact consensus tag and module root pair you recorded earlier.\nRebuild the replay binary. Required if you maintain a custom STF, where no published machine will ever match your root.\n\nThen confirm the machines directory is actually discoverable, because two layout rules are enforced silently:\n\nA directory is ignored unless its name is either latest or exactly its own module root. The comparison is against the lowercase, 0x-prefixed form. A directory named with a truncated, uppercase, or otherwise reformatted root is skipped without an error, even though module-root.txt inside it is correct.\nDiscovery stops at the first search path that yields any machine. One stale directory in an earlier path masks a correct one later in the search order. If --validation.wasm.root-path is set, it is the only path searched.\n\nWhen --validation.wasm.root-path is unset, the search order is:\n\n<project>/target/machines (source builds)\n./machines, relative to the working directory\n./target/machines\nmachines/ in the grandparent directory of the binary—for example, /usr/local/machines for a binary at /usr/local/bin/nitro\n\nSetting --validation.wasm.root-path explicitly is the reliable fix when discovery picks the wrong directory.\nUnderstand which roots your validator is required to have\nA validator must have machines for both roots the block validator resolves, not just the current one:\n\n--node.block-validator.current-module-root (default current, read from the chain)\n--node.block-validator.pending-upgrade-module-root (default latest)\n\nWhen these differ, both are required, and a missing machine for either produces cannot validate WasmModuleRoot. This is why a validator that ran fine yesterday can fail to start today: the chain's root changed, and the current root—read from the chain—now names a root with no machine in the image. Pending, by contrast, is resolved from what's on disk (via the machines/latest symlink), so it can't point at a machine you don't have; a pinned pending root that's missing fails startup with the same cannot validate WasmModuleRoot error.\nBy default, pending resolves through the machines/latest symlink, which download-machine.sh repoints to whatever it fetched last. If you'd rather not depend on that, pin it: --node.block-validator.pending-upgrade-module-root=<target root>. Either way the machine must be on disk, or startup fails with cannot validate WasmModuleRoot—pinning changes which root is required, not whether one is.\nClearing pending-upgrade-module-root is not a fix for a Rollup mismatchSetting --node.block-validator.pending-upgrade-module-root= to an empty value only shrinks the set of roots required at startup. It has no effect on the runtime wasmroot doesn't match rollup error, which compares against the Rollup contract rather than against this flag.So if your node starts but can't advance its bond, clearing this flag won't help—you need the correct machine on disk. Conversely, if you cleared it to work around a startup failure, you've disabled validation against the pending upgrade root, which means you won't discover a missing machine until the upgrade activates. Clearing it also means the validator has no pending root to match against, so it can't adopt a new onchain root at runtime either. Restore it once the correct machine is staged.\nThe validator starts but can't advance its bond\nThis error only occurs on chains still running the legacy staker—the BoLD staker doesn't perform this check. It means the node is running, but the root in the Rollup contract isn't among the roots the block validator actually validated with:\nerror advancing stake from node 18 (hash 0x4d42...): error generating node action:\nwasmroot doesn't match rollup : 0x260f5fa5..., valid: [0x8b104a2e...]\nRead it as: the Rollup contract expects the first root; your validator only has the second. Both roots map to consensus versions you can look up in the Nitro repository's Dockerfile—which usually reveals that the expected root corresponds to a consensus version your image never downloaded.\nThe fix is to stage the machine for the root the Rollup contract expects, then restart the validator. Confirm success by checking that a validator chosen line appears for that root.\nA related message, block validation is still pending, is not a mismatch—it means the block validator hasn't validated anything yet and has no roots to compare. Wait for validation to progress.\nDon't suppress the mismatch check--node.staker.dangerous.ignore-rollup-wasm-module-root downgrades this error to a warning and lets the validator make anyway. Its own help text describes it as dangerous, and for good reason: asserting against a module root the Rollup contract doesn't recognize risks producing assertions that can be challenged. Fix the machine, don't silence the check.Likewise, --validation.wasm.enable-wasmroots-check=false disables only the non-fatal startup pre-check. It hides an early warning without addressing the cause.\nRollback options\nHow much you can undo depends entirely on whether the ArbOS upgrade has activated. The ArbOS upgrade applies in consensus once the chain's block timestamp reaches the scheduled timestamp, and the upgrade logic only ever moves the version upward.\nWhat you changedReversible?Scheduled ArbOS upgrade, before the timestampYes. Call scheduleArbOSUpgrade again to push the timestamp out or to set a version at or below the current oneWASM module rootYes. Call setWasmModuleRoot with the previous root. Roots are backward compatibleNitro node versionPartially. You can downgrade, but not below a version that supports the chain's active ArbOS versionnitro-contractsDifficult. Technically possible by re-pointing implementations through the upgrade executor, but treat it as a last resortActivated ArbOS versionNo. There is no downgrade path\nBefore the activation timestamp\nA scheduled upgrade is just two stored values—a target version and a timestamp—and the upgrade only fires when the chain's timestamp reaches the target timestamp and the target version is higher than the current one. Until then, you can freely cancel or reschedule by calling scheduleArbOSUpgrade again through the upgrade executor. This is the safe window; if you have any doubt about validator readiness, postpone from here rather than pushing forward.\nAfter the activation timestamp\nThe ArbOS version cannot be lowered. Recovery means rolling forward:\n\nRestore node availability first. If nodes are failing to start, resolve that with the WASM root troubleshooting above. Getting nodes running on the new ArbOS version is almost always faster than any attempt to unwind.\nDon't downgrade Nitro below the active ArbOS version. A node too old for the active ArbOS version stops with a fatal out-of-date error, so downgrading to \"get back to a working state\" makes the outage worse.\nEscalate rather than improvise. If the chain is producing blocks but validation is broken, the chain is still live and withdrawals are the pressure point. Contact Offchain Labs support before attempting contract-level changes.\n\nReverting contracts after assertions existRolling nitro-contracts back is only remotely viable if no assertions have been posted that depend on the new contracts' behavior. Once they have, a revert can invalidate chain history or strand in-flight withdrawals. Treat a contracts rollback as an incident requiring support involvement, not a routine operation.\nRelated documents\n\nArbOS upgrade—step-by-step mechanics for each upgrade action\nArbOS releases—per-release requirements, WASM module roots, and Nitro versions\nOwnership and access—which account holds which administrative role\nMonitoring tools and considerations—what to watch during and after an upgrade\nBatch poster troubleshooting—diagnosing batch poster errors\nCustomize your chain's behavior—building a custom STF and its replay binary\nNitro CLI flags reference—reference for the Nitro configuration flags named here (dangerous flags are not listed)\nHow is this guide?Manage state growthLearn about state growth and corresponding issuesValidator troubleshootingDiagnose and resolve common validator operational issues, including assertion timing flags, parent-chain read consistency, assertion errors, stuck transactions, and manual assertion confirmation.","tokens":5588,"squid":"spider-01","role":"Chain Spider","at":1791344978206,"hash":"346ab896e88ef8c03207ebd1759ba17ffb25a4a8"}
{"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":"spider-08","role":"Oracle Spider","at":1791344980852,"hash":"18b15e8b853e95c274c93ed199cfa3273b8f9911"}
{"url":"https://developer.arbitrum.io/launch-arbitrum-chain/operate/batch-poster-troubleshooting","domain":"developer.arbitrum.io","title":"Batch poster troubleshooting","text":"Operate your chainBatch poster troubleshootingDiagnose and resolve common batch poster operational issues including mempool errors, balance management, backlog conditions, and retry failures.Request an updateThis guide covers common operational issues that batch poster operators encounter, with guidance on diagnosing root causes and resolving them. For initial setup, see Run a batch poster. For fee-related tuning, see Batch poster fee tuning.\nBatch poster balance management\nThe batch poster account is an Externally Owned Account (EOA) that pays gas fees on the parent chain to submit batch transactions. There is no automatic mechanism to keep this account funded—operators must monitor the balance and replenish it manually or through external automation.\nSymptoms of low balance\n\nBatch posting transactions fail on the parent chain due to insufficient funds\nThe batch poster logs show transaction submission errors\nUnposted batches accumulate, causing a growing backlog (see Batch posting backlog diagnosis)\n\nMonitoring guidance\nThe Monitoring tools and considerations guide recommends monitoring the batch poster balance. In practice, this means:\n\nQuery the balance directly: Use the parent chain RPC to check the batch poster EOA balance at regular intervals.\nSet up alerting: Configure external monitoring (e.g., a balance-checking script, onchain monitoring service, or infrastructure alerting tool) to notify you when the balance drops below a threshold.\n\nBalance threshold guidanceThere is no universally recommended balance threshold—the appropriate level depends on your parent chain's gas prices, your chain's batch posting frequency, and batch sizes. As a general approach, estimate your daily batch posting cost (number of batches per day multiplied by average gas cost per batch) and maintain a buffer of several days' worth of posting costs. Monitor actual spending over time and adjust accordingly.\nFunding strategy\n\nKeep the account overfunded: The recommendation is to keep the batch poster account overfunded rather than maintaining a tight balance. This provides a buffer against gas price spikes.\nAutomate top-ups if possible: Consider scripting periodic balance checks and transfers from a treasury account to the batch poster EOA.\nMonitor alongside gas prices: A balance that seems adequate during low gas prices may drain quickly during sustained gas spikes. Factor in parent chain gas price volatility when developing your funding strategy.\n\nMempool errors\n\"Posting this transaction will exceed max mempool size\"\nThis error indicates that the parent chain node's mempool has rejected a transaction from the batch poster because it was at capacity.\nWhat causes this error\n\nToo many pending transactions: The batch poster has submitted multiple transactions that haven't yet been included in a block, and the parent chain node's mempool has reached its limit for pending transactions from a single account or overall.\nGas price too low for inclusion: If gas prices have risen since the transactions were submitted, older transactions may remain in the mempool and not be included. New submissions then push against the mempool's size limits.\nRBF not escalating fast enough: When using DB or Redis storage (which support RBF), the replacement fee schedule may not be aggressive enough to get transactions included during congestion, causing the mempool to fill with stale transactions.\n\nResolution\n\nCheck the parent chain's current gas prices and compare them to your data poster's fee cap configuration. If gas prices are above your --node.batch-poster.data-poster.target-price-gwei, the data poster can't bid high enough to cover the fee. See Batch poster fee tuning for guidance on adjustments.\nReview your queued transaction storage configuration: If you're using DB or Redis storage, pending transactions accumulate and rely on RBF for inclusion. Consider whether your RBF schedule (--node.batch-poster.data-poster.replacement-times for non-blob batch poster, --node.batch-poster.data-poster.blob-tx-replacement-times for blob batch poster) is escalating fees quickly enough. See Queued transaction database selection for storage option details.\nConsider Noop storage for parent chains without mempools: If your parent chain is an Arbitrum chain or another chain without a traditional mempool, Noop storage avoids this issue entirely by waiting for each transaction receipt before submitting the next one.\n\nMempool size limitsThe exact mempool weight limits depend on the parent chain node's configuration, not the batch poster itself. The batch poster does not control the parent chain node's mempool size. If you are running your own parent chain node, consult its documentation for mempool configuration. If using a third-party RPC provider, the mempool limits are determined by the provider's infrastructure.\nErrExceedsMaxMempoolSize → \"error posting batch\"\n\n[DEBUG→WARN→ERROR over 5 min]—The next batch's nonce would exceed unconfirmed nonce + max-mempool-transactions, so it's held back.\n[CAUSE]— is confirming the poster's transactions slowly, and the in-flight window (default: 18) is filled.\n[MEANING]—Normal back-pressure short-term; sustained means posts are stuck.\n[ACTION]—If persistent, check L1 confirmation/fees, consider raising max-mempool-transactions.\n\nlack of L1 balance prevents posting transaction with desired fee cap\n\n[WARN]—The poster's wallet can't cover the target max cost, so the bid is capped at the available balance.\n[CAUSE]—Low parent-chain balance and/or high L1 fees.\n[ACTION]—Fund the L1 wallet (send-l1); watch arb/batchposter/wallet/eth.\n\na large batch posting backlog exists\n\n[INFO/WARN/ERROR]—Unposted messages are piling up; INFO if it recently hit L1 bounds, WARN at backlog > 10, ERROR at > 30.\n[CAUSE]—Posts not keeping up (fees, mempool cap, L1 congestion, or the poster is behind).\n[ACTION]—Investigate why posting is throttled; ERROR is an alerting threshold.\n\nerror fetching batch poster wallet balance / ...gas refunder balance\n\n[WARN]—Balance gauge update failed.\n[CAUSE]—L1 RPC hiccup.\n[MEANING]—Monitoring gap only, not a posting failure.\n[ACTION]—Ignore if transient.\n\nBatch posting backlog diagnosis\nA batch posting backlog occurs when the sequencer continues ordering transactions, but the batch poster can't submit them to the parent chain at the same rate. This results in an accumulation of unposted messages.\nCommon causes\nCauseDescriptionInsufficient batch poster balanceThe EOA does not have enough funds to pay parent chain gas feesGas prices exceeding fee capParent chain gas prices are above --node.batch-poster.data-poster.target-price-gwei, causing the data poster to pause submissionsParent chain congestionEven with adequate fees, high parent chain congestion can delay transaction inclusionNode sync issuesThe batch poster node may have fallen behind in syncing with the parent chain, preventing accurate fee estimation or transaction submissionReverted transactions (DB/Redis)When using DB or Redis storage, a reverted batch posting transaction causes the batch poster to halt. Noop storage tolerates reverts and retries automatically\nHow to identify a backlog\n\nMonitor the SequencerInbox contract: Track the frequency of batch submissions to the parent chain. A sudden drop or stop in batch submissions indicates an issue.\nCheck the sequencer's transaction backlog size: As noted in the Monitoring tools and considerations guide, a large and growing backlog can be a sign of network health issues.\nReview batch poster logs: Look for error messages related to transaction submission failures, fee estimation errors, or the data poster pausing.\n\nBacklog metricsThe specific log messages and metrics that indicate a backlog depend on the Nitro node version and configuration. Operators should familiarize themselves with their node's log output during normal operation so that deviations are easier to spot. Key log prefixes to watch for include BatchPoster: and DataPoster: entries.\nResolution approaches\n\nCheck the batch poster balance: ensures the EOA has sufficient funds on the parent chain.\nCheck the parent chain gas prices: If prices exceed your fee cap, either wait for prices to drop or increase --node.batch-poster.data-poster.target-price-gwei (see Batch poster fee tuning).\nVerify parent chain connectivity: Ensure the batch poster node can reach the parent chain RPC endpoint and that the parent chain node is fully synced.\nCheck for reverted transactions: If using DB or Redis storage, a reverted transaction halts the batch poster. Check the batch poster logs for revert errors. Restarting the batch poster or clearing the queued transaction storage (with caution) may be necessary.\nReview node sync status: Confirm the batch poster node is synced with both the Arbitrum chain and the parent chain.\n\nRetry errors\n\"Failed to re-send transaction\"\nThis error appears when the data poster attempts to resubmit a batch posting transaction (typically as part of RBF), and the resubmission fails.\nWhat causes this error\n\nNonce conflicts: The original transaction may have already been included onchain, making the replacement attempt invalid because the nonce has already been consumed.\nStorage inconsistencies: When using DB or Redis for queued transaction tracking, mismatches between the stored transaction state and the onchain state can cause resubmission failures. This can happen after a node restart if the storage wasn't cleanly synced.\nParent chain rejection: The parent chain node may reject the replacement transaction for various reasons—the replacement fee isn't high enough (must be at least 10% higher for standard RBF), the transaction format is invalid, or the parent chain node is experiencing issues.\n\nError contextThe exact phrasing and context of retry errors can vary across Nitro versions. The \"failed to re-send transaction\" message generally indicates an RBF attempt that didn't succeed. Check the surrounding log lines for more specific error details (for example, \"nonce too low\", \"replacement transaction underpriced\", or connection errors).\nResolution\n\nCheck if the original transaction was included: Query the parent chain for the batch poster's latest nonce and compare it to what the data poster expects. If the original transaction was already included, the retry error is benign—the data poster should recover automatically on the next cycle.\nReview the queued transaction storage: If using DB or Redis, the stored transaction state may be stale. A node restart typically resolves transient storage inconsistencies.\nCheck parent chain connectivity: Ensure the batch poster can reliably reach the parent chain RPC. Intermittent connectivity causes retry failures.\nInspect RBF fee escalation: If the error mentions \"replacement transaction underpriced\", the fee increase between attempts may be insufficient. The parent chain typically requires at least a 10% fee increase for RBF. Review the blob-tx-replacement-times schedule—shorter intervals may not allow enough price movement between attempts.\n\nReverts and halting\nLarge gap between last seen and current block number, skipping check for reverts\n\n[WARN]—pollForReverts fell > 100 blocks behind the chain, so it skipped scanning the intervening blocks for reverted poster transactions and fast-forwarded.\n[CAUSE]—Node lag, a long pause, or a header-subscription stall.\n[MEANING]—Reverts in that skipped window won't be detected.\n[ACTION]—Usually transient; if frequent, investigate node sync/L1 RPC health.\n\nTransaction from batch poster reverted\n\n[WARN→ERROR]—A batch posting transaction got a failed receipt on L1.\n[ERROR (not WARN)]—When using persistent storage, it sets batchReverted and halts all further posting.\n[CAUSE]—Contract rejected the batch (e.g., message-count mismatch, bad sequence number, gas/blob issue).\n[ACTION]—Investigate txErr; restart clears the halt flag; a count mismatch after may need allow-posting-first-batch-when-sequencer-message-count-mismatch.\n\nError checking batch reverts\n\n[DEBUG/WARN]—Revert check failed.\n[DEBUG]—If the error contains \"not found\" (a benign parent-node inconsistency where one node served a header, another lacks it), else WARN.\n[ACTION]—Ignore the DEBUG case; investigate persistent WARNs.\n\nNonce/sync\nfailed to update nonce with queue empty; falling back to using a recent block\n\n[WARN]—Couldn't get the finalized nonce, so it used a recent block instead. Safe because the queue is empty.\n[CAUSE]—Finality data unavailable/RPC issue.\n[ACTION]—Benign one-off; investigate if constant.\n\nFailed to get current nonce\n\n[WARN]—Nonce refresh failed, but a previous nonce exists, so it's non-fatal.\n[CAUSE]—L1 RPC.\n[ACTION]—Ignore if transient.\n\nFailed to get latest nonce\n\n[WARN]—Couldn't fetch the unconfirmed nonce this loop; the iteration backs off 10s (minWait).\n[ACTION]—Transient RPC.\n\nfailed to update tx poster balance / failed to update tx poster nonce\n\n[WARN]—Periodic state refresh in the data-poster loop failed; on balance failure, the loop backs off 10s.\n[ACTION]—Transient RPC.\n\nDataPoster failed to send transaction\n\n[WARN]—The RPC SendTransaction call errored.\n[CAUSE]—Mempool rejection, underpriced, RPC issue.\n[MEANING]—The transaction stays queued and is retried.\n[ACTION]—Watch for repetition.\n\nmaybeLogError family—failed to replace-by-fee transaction / failed to re-send transaction\n\n[DEBUG/INFO → WARN/ERROR after 20 consecutive]—Per-nonce send/RBF errors that escalate if they persist. storage.ErrStorageRace starts DEBUG; ErrFutureReplacePending/ErrNonceTooHigh start INFO; anything else is immediate ERROR.\n[ACTION]—The escalated WARN/ERROR is the real signal—investigate then.\n\nFee/pricing\ncan't meet data poster fee cap obligations with current target max cost / can't meet current parent chain fees with current target max cost\n\n[INFO]—The computed fee cap can't cover the current L1 base fee/required cost.\n[CAUSE]—L1 fees spiked above the poster's escalation target, or balanced-capped.\n[ACTION]—If posts stall, tune the fee formula (target-price-gwei, urgency-gwei, max-fee-bid-multiple-bips) or fund the wallet.\n\nsubmitting transaction with GasFeeCap less than latest basefee / ...BlobGasFeeCap less than latest blobfee\n\n[INFO]—Posting anyway with a cap below the current fee, expecting it to confirm as fees drop.\n[ACTION]—Normal during fee volatility; concerning only if posts never confirm.\n\nunable to fetch suggestedTipCap from l1 client to update arb/batchposter/suggestedtipcap metric\n\n[WARN]—Couldn't get a tip suggestion for the metric.\n[MEANING]—Metric gap only.\n[ACTION]—Ignore if transient.\n\nL1 bounds/reorg\nDisabling batch posting due to batch being within reorg resistance margin from layer 1 minimum block or timestamp bounds\n\n[ERROR]—The batch's first message is within reorg-resistance-margin of the L1 minimum bound, so posting is refused this round.\n[CAUSE]—The margin guard (default 10m) protects against near the lower bound.\n[ACTION]—Expected safety behavior; set margin to 0 only if you accept the risk.\n\ndisabling L1 bound as batch posting message is close to the maximum delay\n\n[ERROR]—Overriding the L1 block bound because messages are near max-delay; the l1-block-bound-bypass margin kicked in to avoid stalling.\n[ACTION]—Informational; means it chose to post over respecting the bounds.\n\nnot posting more messages because block number or timestamp exceed L1 bounds\n\n[INFO]—Stopped adding messages that fall outside the current L1 bound window.\n[ACTION]—Normal bounding behavior.\n\nerror getting max time variation on L1 bound block; falling back on latest block\nThe L1 node couldn't give state at the finalized bound block, so it falls back to the latest block—usually transient.\nunknown L1 block bound config value; falling back on using finalized\n\n[ERROR]—Bound resolution issues; the latter means a bad l1-block-bound config value.\n[ACTION]—Fix the config value for the ERROR.\n\nDataPoster is avoiding creating a mempool nonce gap\n\n[INFO]—Held a transaction back rather than create a nonce gap that a reorg could expose (predecessor not yet reorg-resistant).\n[ACTION]—Normal reorg-safety; the transaction is retried.\n\nDA/fallback (AnyTrust/AltDA)\nDA writer failed, operator action required\n\n[ERROR]—A non-fallback DA writer error; posting stops.\n[ACTION]—Investigate immediately—this is an explicit operator-action alert.\n\nDA writer explicitly requested fallback\n\n[WARN]—A DA backend requested a fallback; the poster moves to the next writer/EthDA.\n[ACTION]—Check DA provider health; sustained fallback means degraded DA.\n\nRelated info\nDA writer reports message too large, will rebuild batch\nDA writers exhausted, will rebuild for EthDA\nEthDA fallback period complete, will retry AltDA\nThese pair with the da_success/da_failure/da_last_success metrics.\nLock/coordination and gas estimation\nError checking if we could acquire redis lock\n\n[WARN]—Redis lock check failed; it optimistically tries anyway.\n[CAUSE]—Redis connectivity.\n[ACTION]—Check Redis if high availability matters.\n\nNot posting batches right now because another batch poster has the lock or this node is behind\n\n[DEBUG]—Normal on backup posters/when behind.\n[ACTION]—Expected; not an error.\n\nFailed to estimate gas for EIP-7623 check 1/2\n\n[WARN]—An EIP-7623 calldata-cost estimation probe failed.\n[ACTION]—Usually transient; relevant only on EIP-7623 parent chains.\n\nerror estimating gas for batch\n\n[escalates via ephemeral handler]—Gas estimation failed (ErrNormalGasEstimationFailed); DEBUG→WARN→ERROR over 5 min.\n[CAUSE]—L1 state lag, reverting estimation, inbox not caught up.\n[ACTION]—Investigate if it reaches ERROR.\n\nConfig/startup\nmax-size is deprecated; use max-calldata-batch-size...\n\n[ERROR]—Deprecated flag in use.\n[ACTION]—Migrate to max-calldata-batch-size.\n\nDisabling data poster storage, as parent chain appears to be an Arbitrum chain without a mempool\n\n[INFO]—Auto-switched to no-op storage on an Arbitrum parent.\n[ACTION]—Expected for L3s.\n\nmessagesPerBatch is somehow zero\n\n[WARN]—Defensive guard against a should-be-impossible state; defaults to 1.\n[ACTION]—Benign unless recurring.\n\nThe escalation rule to remember\nMany of these (mempool size, storage race, gas estimation, nonce-too-high,\naccumulator-not-found) are logged quietly at first and only escalate to WARN/ERROR if they persist past ~1–5 minutes, and batchPosterFailureCounter increments only at ERROR level. So a single WARN is usually noise; a sustained one that reaches ERROR is the real signal. Pair these with the metrics: estimated_batch_backlog, wallet/eth, the dataposter/nonce/* gap, and da_failure.\nQuick reference\nSymptomLikely causeResolutionBatch posting stopped, no error in logsBatch poster balance depletedFund the batch poster EOA on the parent chain\"Mempool weight limit exceeded\"Too many pending transactions in parent chain mempoolReview fee cap settings; check RBF escalation scheduleBatches not posting during gas spikeGas prices exceed --node.batch-poster.data-poster.target-price-gweiIncrease fee cap or wait for prices to normalize\"Failed to re-send transaction\"Nonce conflict or RBF underpricedCheck if original transaction was included; review fee escalationGrowing sequencer backlogMultiple possible causesCheck balance, gas prices, parent chain connectivity, and node syncBatch poster halted after revertUsing DB/Redis storage with a reverted transactionReview revert cause; restart batch poster or clear storageBlob transactions pending for hoursBlob tip cap too lowIncrease max-blob-tx-tip-cap-gwei; review replacement scheduleHow is this guide?ArbOS upgradeLearn how to upgrade ArbOS on your Arbitrum chain.BoLD upgrade playbookSequence a BoLD upgrade when execution requires multisig or security council signatures that take days to collect, without freezing your validators for the entire window.","tokens":4948,"squid":"spider-01","role":"Chain Spider","at":1791344988492,"hash":"fea575da07f22f0f2d6b3152b25b05d4601d86c6"}
{"url":"https://www.metaplex.com/docs/smart-contracts/core/execute-asset-signing","domain":"metaplex.com","title":"Execute and Asset Signer | Core","text":"The MPL Core Execute instruction introduces the concept of Asset Signers to MPL Core Assets. These Asset Signers act as Signers on behalf of the Asset itself which unlocks the ability for MPL Core Assetsto transfer out Solana and SPL Tokens.to become the authority of other accounts.to perform other actions and validations that have been assigned to the assetSignerPda that require transaction/instruction/CPI signing. MPL Core Assets have the ability to sign and submit transactions/CPIs to the blockchain. This effectively gives the Core Asset it's own wallet in the form of an assetSigner.Withdraw Asset Signer balances before burningBurning a Core Asset makes the execute instruction fail. The program can no longer load the Asset, so it cannot sign as the assetSignerPda. Any SOL, tokens, or other assets still held by that PDA become stranded with no recovery path.Asset Signer PDAAssets are now able to access the assetSignerPda account/address which allows the execute instruction on the MPL Core program to pass through additional instructions sent to it to sign the CPI instructions with the assetSignerPda. This allows the assetSignerPda account to effectively own and execute account instructions on behalf of the current asset owner. You can think of the assetSignerPda as a wallet attached to a Core Asset.Fund the Asset Signer PDA, not the Asset addressThe assetSignerPda is a different address from the Asset account. Only the assetSignerPda can hold SOL and tokens on behalf of the Asset. The Asset account itself must never be used as a wallet.findAssetSignerPda()const assetId = publickey('11111111111111111111111111111111')\nconst assetSignerPda = findAssetSignerPda(umi, { asset: assetId })\nExecute InstructionOverviewThe execute instruction allows users to pass in the Core Asset and also some pass through instructions that will get signed by the AssetSigner when it hits the MPL Core programs execute instruction on chain. An overview of the execute instruction and it's args.const executeIx = await execute(umi, {\n {\n // The asset via `fetchAsset()` that is signing the transaction.\n asset: AssetV1,\n // The collection via `fetchCollection()`\n collection?: CollectionV1,\n // Either a TransactionBuilder | Instruction[]\n instructions: ExecuteInput,\n // Additional Signers that will be required for the transaction/instructions.\n signers?: Signer[]\n }\n})\nValidationassetSignerPda ValidationThe MPL Core Execute instruction will validate that the current Asset owner has also signed the transaction. This insures only the current Asset Owner can execute transactions while using the assetSignerPda with the execute instruction.Controlling Execute OperationsThe execute functionality can be controlled using the Freeze Execute Plugin. This plugin allows you to freeze the execute operations on an asset, preventing any execute instructions from being processed until unfrozen. The Freeze Execute Plugin is particularly useful for:Backed NFTs: Prevent withdrawal of underlying assets when neededEscrowless protocols: Temporarily lock execute functionality during protocol operationsSecurity measures: Add an additional layer of protection for assets that can execute complex operations When the Freeze Execute Plugin is active and set to frozen: true, any attempts to use the execute instruction will be blocked until the plugin is updated to frozen: false.Burning an Asset with Asset Signer balancesBurning a Core Asset permanently disables execute, so any SOL, tokens, or nested Core Assets left in the assetSignerPda cannot be moved.The execute instruction requires a live Core Asset account owned by the MPL Core program. After you burn the Asset, that account is no longer a valid Asset. The assetSignerPda address still exists and can still hold funds — there is just no remaining instruction that can spend them.Move everything out of the PDA with execute before burning:Derive the PDA with findAssetSignerPda or mplx core asset execute infoTransfer SOL, SPL tokens, and any Core Assets the PDA ownsConfirm the PDA is emptyBurn the AssetExamplesTransferring SOL From the Asset SignerIn the following example we transfer SOL that had been sent to the assetSignerPda to a destination of our choice.import {\n execute,\n findAssetSignerPda,\n fetchAsset,\n fetchCollection,\n} from '@metaplex-foundation/mpl-core'\nimport { transferSol } from '@metaplex-foundation/mpl-toolbox'\nimport { publickey, createNoopSigner, sol } from '@metaplex-foundation/umi'\nconst assetId = publickey('11111111111111111111111111111111')\nconst asset = await fetchAsset(umi, assetId)\n// Optional - If Asset is part of collection fetch the collection object\nconst collection =\n asset.updateAuthority.type == 'Collection' && asset.updateAuthority.address\n ? await fetchCollection(umi, asset.updateAuthority.address)\n : undefined\n// Asset signer has a balance of 1 SOL in the account.\nconst assetSignerPda = findAssetSignerPda(umi, { asset: assetId })\n// Destination account we wish to transfer the SOL to.\nconst destination = publickey('2222222222222222222222222222222222')\n// A standard `transferSol()` transactionBuilder.\nconst transferSolIx = transferSol(umi, {\n // Create a noopSigner as the assetSigner will sign later during CPI\n source: createNoopSigner(publicKey(assetSigner)),\n // Destination address\n destination,\n // Amount you wish to transfer\n amount: sol(0.5),\n})\n// Call the `execute` instruction and send to the chain.\nconst res = await execute(umi, {\n // Execute instruction(s) with this asset\n asset,\n // If Asset is part of collection pass in collection object via `fetchCollection()`\n collection,\n // The transactionBuilder/instruction[] to execute\n instructions: transferSolIx,\n}).sendAndConfirm(umi)\nconsole.log({ res })\nTransferring SPL Tokens From the Asset SignerIn the following example we transfer some of our SPL Token balance from the assetSignerPda account to a destination. This example is based on the best practices in regards to derived tokens accounts for a base wallet address. If tokens are not in their correctly derived token account based on the assetSignerPda address then this example will need adjusting.import {\n execute,\n findAssetSignerPda,\n fetchAsset,\n fetchCollection,\n} from '@metaplex-foundation/mpl-core'\nimport {\n transferTokens,\n findAssociatedTokenPda,\n} from '@metaplex-foundation/mpl-toolbox'\nimport { publickey } from '@metaplex-foundation/umi'\nconst assetId = publickey('11111111111111111111111111111111')\nconst asset = await fetchAsset(umi, assetId)\n// Optional - If Asset is part of collection fetch the collection object\nconst collection =\n asset.updateAuthority.type == 'Collection' && asset.updateAuthority.address\n ? await fetchCollection(umi, asset.updateAuthority.address)\n : undefined\nconst splTokenMint = publickey('2222222222222222222222222222222222')\n// Asset signer has a balance of tokens.\nconst assetSignerPda = findAssetSignerPda(umi, { asset: assetId })\n// Destination wallet we wish to transfer the SOL to.\nconst destinationWallet = publickey('3333333333333333333333333333333')\n// A standard `transferTokens()` transactionBuilder.\nconst transferTokensIx = transferTokens(umi, {\n // Source is the `assetSignerPda` derived Token Account\n source: findAssociatedTokenPda(umi, {\n mint: splTokenMint,\n owner: assetSignerPda,\n }),\n // Destination is the `destinationWallet` derived Token Account\n destination: findAssociatedTokenPda(umi, {\n mint: splTokenMint,\n owner: destinationWallet,\n }),\n // Amount to send in lamports.\n amount: 5000,\n})\n// Call the `execute` instruction and send to the chain.\nconst res = await execute(umi, {\n // Execute instruction(s) with this asset\n asset,\n // If Asset is part of collection pass in collection object via `fetchCollection()`\n collection,\n // The transactionBuilder/instruction[] to execute\n instructions: transferTokensIx,\n}).sendAndConfirm(umi)\nconsole.log({ res })\nTransferring Ownership of an Asset to Another AssetIn the following example we transfer a Core Asset that is owned by another Core Asset, to another.import {\n execute,\n fetchAsset,\n fetchCollection,\n findAssetSignerPda,\n transfer,\n} from '@metaplex-foundation/mpl-core'\nimport { publickey } from '@metaplex-foundation/umi'\n// Asset we wish to transfer.\nconst assetId = publickey('11111111111111111111111111111111')\nconst asset = await fetchAsset(assetId)\n// Optional - If Asset is part of collection fetch the collection object\nconst collection =\n asset.updateAuthority.type == 'Collection' && asset.updateAuthority.address\n ? await fetchCollection(umi, asset.updateAuthority.address)\n : undefined\n// Asset ID that owns the Asset we wish to transfer.\nconst sourceAssetId = publickey('2222222222222222222222222222222222')\n// The source Asset object.\nconst sourceAsset = fetchAsset(umi, sourceAssetId)\n// Asset signer has a balance of 1 SOL in the account.\nconst sourceAssetSignerPda = findAssetSignerPda(umi, { asset: assetId })\n// Destination account we wish to transfer the SOL to.\nconst destinationAssetId = publickey('33333333333333333333333333333333')\n// Destination Asset signer we wish to transfer the Asset to.\nconst destinationAssetSignerPda = findAssetSignerPda(umi, {\n asset: destinationAssetId,\n})\nconst transferAssetIx = transfer(umi, {\n // Asset object via `fetchAsset()`.\n asset,\n // Optional - Collection object via `fetchCollection()`\n collection,\n // New Owner of the Asset.\n newOwner: destinationAssetSignerPda,\n}).sendAndConfirm(umi)\nconst res = await execute(umi, {\n // Execute instruction(s) with this asset\n asset,\n // If Asset is part of collection pass in collection object via `fetchCollection()`\n collection,\n // The transactionBuilder/instruction[] to execute\n instructions: transferAssetIx,\n}).sendAndConfirm(umi)\nconsole.log({ res })\nNotesOnly the current Asset owner can invoke execute (the owner must sign the outer transaction)The Freeze Execute Plugin can block execute until it is unfrozenBurning the Asset is irreversible for Asset Signer funds: empty the PDA firstThe assetSignerPda is deterministic from the Asset address and does not change if the Asset is transferredThe execute instruction charges a protocol fee paid by the payer account passed to the instruction, which is normally the Asset owner but can also be the assetSignerPda itself. This is separate from the Solana transaction fee, which the PDA cannot pay. See the Protocol Fees page for the current amount. The fee is transferred into the Asset account and later swept by the Metaplex fee collector.Every lamport above the rent-exempt minimum on the Asset account is treated as a protocol fee and will be collected. Hold SOL and tokens in the assetSignerPda, never in the Asset account.The assetSignerPda is a system-owned account. The Solana runtime rejects any transaction that leaves it with a non-zero balance below the rent-exempt minimum for a zero-byte account, so a transfer out must either empty the account or leave at least that minimum behind. If the PDA is also the payer for execute, the protocol fee is deducted from it in the same instruction, so include the fee when working out what remains. Query getMinimumBalanceForRentExemption(0) on the target cluster for the current minimum instead of hard-coding a value.FAQWhat happens to funds in the Asset Signer PDA if I burn the Asset?They are stranded. execute requires a live Core Asset, so after burn the PDA can still hold SOL, tokens, and nested Assets but nothing can sign to move them.Can I recover stranded Asset Signer funds after a burn?No. There is no instruction that can sign as the assetSignerPda without the original Asset account.Does transferring the Asset strand the Asset Signer wallet?No. Transfer changes which owner can call execute. The PDA stays attached to the Asset address. Burning, not transferring, is what disables execute.","tokens":2949,"squid":"dotcat","role":"Tooling Spider","at":1791344988865,"hash":"d97e429fd97549fb981d815b33b1ebb3582f7a56"}
{"url":"https://developer.arbitrum.io/launch-arbitrum-chain/operate/sequencer-troubleshooting","domain":"developer.arbitrum.io","title":"Sequencer troubleshooting","text":"Operate your chainSequencer troubleshootingDiagnose and resolve sequencer feed problems, broadcast backlog errors, feed stalls, and the conditions that stop block production.Request an updateThis guide covers sequencer feed and block production problems. For setup, see How to set up a high-availability sequencer. For metric names and alert thresholds, see Monitoring tools and considerations. For batch posting problems, see Batch poster troubleshooting.\nDefaults in this guideEvery default value and log string on this page comes from the Nitro source. Defaults change between releases. Confirm them against the version you run with --help.\nFeed relay architecture\nThe is a WebSocket stream of transactions in the order the chose. It gives you data before batches land on the , which is why nodes use it to stay current instead of waiting for batches.\nWhat produces the feed\nAny node with feed output enabled runs a broadcast server on port 9642 and serves the /feed endpoint. Two roles enable it:\nRoleWhat it doesConfigurationSequencerBroadcasts messages it sequences itselfnode.feed.output.enable=trueRelaySubscribes to an upstream feed and rebroadcasts it unchangednode.feed.input.url plus feed output\nA relay does not sequence, validate, or execute anything. It reads an upstream feed and distributes it to more subscribers. The message content is identical either way, so a cannot tell from the payload whether it is connected to a sequencer or a relay.\nSequencer feed compared to relay feed\nThe difference is operational, not structural:\n\nLoad isolation. Every subscriber on a sequencer is a connection the sequencer maintains instead of ordering transactions. Relays absorb that load.\nCompression. Public feed endpoints may serve compressed messages using a custom dictionary. A local relay serves an uncompressed feed by default, so if you consume the feed with anything other than a standard Nitro node, run one.\nBlast radius. A relay that fails takes its subscribers offline. A sequencer that fails stops the chain.\n\nIn a high-availability deployment, feeds flow in one direction through two relay tiers:\nsequencers → sequencer relays → external relays → public subscribers\nSequencer relays subscribe to every sequencer replica, not just the active one. Non-chosen sequencers still broadcast, so aggregating all of them means no messages are lost when the chosen sequencer changes. This is why the Helm setup needs per-replica headless services—a single load-balanced address would connect to only one replica. See How to set up a high-availability sequencer.\nFor installation steps, see How to run a feed relay. For the message format, see How to read the sequencer feed.\nTimeouts that govern a feed connection\nClient and server apply separate timeouts. Because the server gives up before the client does, a healthy connection that goes quiet is usually dropped by the server first.\nSettingSideDefaultWhat it controlsnode.feed.output.pingServer5sHow often the server pings each clientnode.feed.output.client-timeoutServer15sHow long the server waits before dropping a silent clientnode.feed.output.read-timeoutServer1sHow long the server waits to read data (including pings)node.feed.input.timeoutClient20sHow long the client waits for data before treating it as deadnode.feed.input.reconnect-initial-backoffClient1sFirst reconnect delaynode.feed.input.reconnect-maximum-backoffClient64sReconnect delay ceiling; the delay doubles each attempt\nBroadcast backlog errors\nThe broadcast server keeps recent messages in a backlog so a reconnecting client can catch up without a full resync. The backlog is split into segments holding node.feed.output.backlog.segment-limit messages each (default 240).\nerror in backlogSegment type assertion: clearing backlog\nNitro logs this at ERROR. Despite the wording, it is a broadcaster-side memory structure problem, not chain data loss or corruption. Blocks the sequencer already produced are unaffected.\nWhat happens. The backlog empties itself. Connected clients can no longer catch up from memory, so they resync from their configured source. Feed consumers see a gap and reconnect.\nWhere it comes from. The message appears at five places in broadcaster/backlog/backlog.go, and they do not all behave the same way:\n\nFour sites inside delete(confirmed) call reset() and genuinely clear the backlog. This runs when the broadcaster prunes messages it has seen confirmed on the parent chain.\nOne site inside IsBacklogSegmentNil logs the identical text but clears nothing—it only reports a failed type check and returns. If you see this message and the backlog is still populated, you hit this path.\n\nBecause the text is the same in both cases, do not infer a backlog reset from the log line alone. Confirm it with arb/feed/backlog/messages, which drops to zero on a real reset.\nOne related message comes from the same code path.\nconfirmed sequence number is past the end of stored messages\n\n[WARN]—The confirmed message number is ahead of everything the backlog holds, so it resets.\n[CAUSE]—The broadcaster fell far behind, or it restarted and received confirmations for messages it never buffered.\n[MEANING]—Expected shortly after a restart. A recurring pattern in steady state is not.\n\nWhat to do\n\nConfirm the scope. Check whether the chain is still producing blocks. If it is, the problem is limited to the feed and no chain data is at risk.\nCheck arb/feed/backlog/messages. A drop to zero confirms a real reset. Sustained growth is a different problem—see Feed stall diagnosis.\nTreat repeats as a bug report. A single occurrence after a restart is tolerable. A repeating pattern in steady state is worth reporting to the Nitro repository with the surrounding log lines, because every code path that produces this message is an internal invariant failure rather than a configuration problem.\nDo not tune segment-limit in response. The error is not caused by the segment size.\n\nFeed stall diagnosis\nA \"stalled feed\" describes three different failures. They need different fixes, so identify which one you have before acting.\nWhat you observeWhat it meansWhere to lookNo new messages arrive at your nodeConnection is dead or upstream stoppedYour node and the relay chainarb/feed/backlog/messages grows steadilyBatches are not landing on the parent chainYour node lags but the feed is liveYour node cannot keep up executingYour node's resources\nA growing feed backlog is not a lagging followerarb/feed/backlog/messages counts messages the broadcast server retains until it sees them covered by batches on the parent chain. Growth means batches are not landing. It does not mean a subscriber is behind. See Monitoring tools and considerations for the full metric list.\nDetecting a stall\nThe feed carries no heartbeat at the application level, so silence is ambiguous—a chain with no traffic produces no messages. Use these signals instead:\n\nCompare block height to feed activity. If the chain advances but you receive nothing, your connection is the problem. If neither advances, see Block production halt conditions.\nWatch for reconnect loops. The client gives up after node.feed.input.timeout (default 20s) and reconnects with backoff that doubles from 1s to 64s. Repeated reconnects in the logs mean the connection is unstable, not idle.\nCheck each relay tier separately. With sequencer relays and external relays chained, a stall at one tier looks identical from the bottom. Connect directly to each tier to find where messages stop.\n\nRecovering from a stall\n\nRestart the relay. A relay holds no state that needs preserving. Restarting reconnects it upstream and repopulates its backlog.\nVerify the upstream URL list. A relay configured against a single sequencer replica goes silent whenever that replica is not chosen. Point sequencer relays at every replica.\nCheck for rate limiting. Public feed endpoints may throttle excessive connections. If you added redundant connections, remove them and reconnect.\nFall back to the parent chain. A node with a working parent chain connection still syncs from batches without any feed. Sync is slower but correct, so a feed outage degrades latency rather than halting your node.\n\nRedundant feed connectionsYou can point a relay at the same endpoint twice to survive a reset without waiting for a reconnect. This doubles bandwidth and risks rate limiting. Configure it at the relay, never at individual nodes, and never use more than one redundant connection. See How to run a feed relay.\nBlock production halt conditions\nBlock production stops for one of four reasons: no sequencer holds the lockout, the sequencer refuses to build a block, the sequencer accepts no transactions, or execution fails. The checks below run in that order inside Nitro's block creation loop.\n1. No sequencer is chosen\nWith the coordinator enabled, exactly one sequencer holds the lockout in Redis. When none does, every node forwards transactions to a target that is not sequencing, and the chain stops.\nsequencer priorities unset\n\n[ERROR]—The coordinator.priorities key does not exist in Redis.\n[CAUSE]—A new or wiped Redis instance, or one that was never populated.\n[ACTION]—Register your sequencers. See Redis priority registration.\n\nno sequencer appears to want the lockout on redis\n\n[DEBUG→WARN→ERROR]—The priority list exists, but no sequencer on it has set its wants-lockout key. Nitro logs this at DEBUG at first, escalates to WARN after 10 seconds and ERROR after 20, and throttles it to once every 5 seconds.\n[CAUSE]—Every listed sequencer is unsynced, down, or unreachable—or the URLs in the list do not match any running sequencer's my-url.\n[ACTION]—Compare the priorities value printed in the log against each sequencer's configured my-url. They must match exactly.\n\nsequencer is not synced\n\n[WARN]—The sequencer does not ask for the lockout because it has not caught up. Nitro attaches sync details to the log entry.\n[CAUSE]—The node is still replaying messages, or it cannot reach the feed or parent chain.\n[MEANING]—Expected during startup. Sustained means the node cannot catch up.\n\nmyurl main sequencer, but no sequencer exists\n\n[ERROR]—The node is top of the priority list, but it has no sequencer configured.\n[CAUSE]—A node registered in coordinator.priorities without node.sequencer=true. Registering a batch poster causes exactly this.\n[ACTION]—Remove the node from the priority list, or enable sequencing on it.\n\n2. The sequencer refuses to build a block\ncannot sequence: unknown L1 block or L1 timestamp too far from local clock time\n\n[ERROR]—The single most common cause of a silent halt on an otherwise healthy sequencer. Queued transactions are pushed back to the retry queue and the sequencer waits before trying again.\n[CAUSE]—Either the sequencer has not learned any parent chain block yet, or the newest parent chain block's timestamp differs from the local clock by more than execution.sequencer.max-acceptable-timestamp-delta (default 1h).\n[MEANING]—Two very different faults share this message: a parent chain connection that is down or lagging, and a local clock that has drifted.\n[ACTION]—Check parent chain RPC reachability and freshness first, then verify NTP on the sequencer host. Raising the delta hides the symptom without fixing either cause.\n\nThis check only runs with a parent chain readerThe timestamp check applies only when the sequencer has a parent chain reader configured. A sequencer without one never halts for this reason, which is why local dev nodes do not reproduce it.\nsequencer block creation panicked\n\n[ERROR]—Block creation panicked. Nitro recovers, returns an internal error to every queued transaction, and waits max-block-speed before retrying.\n[MEANING]—The sequencer survives, so this appears as a stall rather than a crash. A repeating panic halts the chain in practice.\n[ACTION]—Capture the attached backtrace and report it.\n\n3. The sequencer accepts no transactions\nThe sequencer keeps running here, but the block it builds is empty because the sequencer rejects everything before queuing it.\nRejection messageTriggercurrently not accepting transactions due to expected surplus being below thresholdExpected surplus fell below expected-surplus-hard-thresholdtransaction sender is not on the whitelistsender-whitelist is set and the sender is absentsequencer temporarily not availableThis node is forwarding rather than sequencing, and its is disabled\nFor the surplus flags, see Sequencer configuration reference.\nsequencer temporarily not available comes from the forwarder, not the sequencer. A node returns it when it is not the chosen sequencer and has no enabled target to forward to. Brief occurrences during a lockout handoff are normal. Sustained occurrences across every node mean no sequencer is chosen—see No sequencer is chosen.\n4. Execution problems\ntook over 5 seconds to sequence a block\n\n[WARN]—Fixed 5-second threshold, not configurable.\n[CAUSE]—Slow disk, an oversized block, or resource contention.\n[MEANING]—An early warning, not a halt. Sustained occurrences precede a growing backlog.\n[ACTION]—Check disk I/O and CPU. See Managing state growth.\n\nWhat does not halt block production\nRuling these out saves time:\n\nA batch posting backlog. The sequencer keeps producing blocks while unposted batches accumulate. See Batch poster troubleshooting.\nA feed outage. The feed is an output. Losing it affects subscribers, not block production.\nA or failure. Validation runs behind block production and does not gate it.\nAn unfunded batch poster. Posting stops; sequencing does not.\n\nDiagnostic order\n\nIs the chain producing blocks? Compare block height across two samples.\nDoes a sequencer hold the lockout? Read coordinator.chosen in Redis, or use the Sequencer Coordination Manager (SQM).\nDoes the chosen sequencer log cannot sequence? Check the parent chain connection and clock.\nAre transactions being rejected on arrival? Check surplus thresholds and the sender allowlist.\nIs block creation slow rather than stopped? Check took over 5 seconds to sequence a block and host resources.\nHow is this guide?Post-launch deploymentsLearn about deploying contracts like Multicall3 to an Arbitrum chain after launch using sendL2Message, without needing a chain upgrade or predeploy.Manage state growthLearn about state growth and corresponding issues","tokens":3574,"squid":"spider-01","role":"Chain Spider","at":1791344998412,"hash":"77ce64dd73216177cbbb1c9db171b6eaf19da336"}
{"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":"spider-08","role":"Oracle Spider","at":1791345001329,"hash":"7016ce6b6f3daa380000a6ae73df3f2ee7ff21c3"}
{"url":"https://www.metaplex.com/docs/smart-contracts/core/burn","domain":"metaplex.com","title":"Burning Assets | Metaplex Core","text":"This guide shows how to burn Core Assets on Solana using the Metaplex Core SDK. Permanently destroy Assets and recover most of the rent deposit. What You'll LearnBurn an Asset and recover rentHandle burning for Assets in CollectionsUnderstand Burn Delegate permissionsKnow what happens to the account after burningEmpty the Asset Signer PDA before burningWithdraw Asset Signer balances before burningBurning a Core Asset makes execute fail. SOL, tokens, or other assets still held by the Asset Signer PDA become stranded with no recovery path. Transfer them out first.SummaryBurn a Core Asset to permanently destroy it and recover rent. Only the owner (or Burn Delegate) can burn an Asset.Call burn(umi, { asset }) to destroy the AssetThe account's rent is returned to the burn transaction's payerA small amount (~0.0009 SOL) remains to prevent account reuseBurning is permanent and irreversibleEmpty the Asset Signer PDA first — execute cannot move those funds after burnOut of ScopeToken Metadata burning (use mpl-token-metadata), compressed NFT burning (use Bubblegum), and Collection burning (Collections have their own burn process).Quick StartJump to: Burn Asset · Burn in CollectionInstall: npm install @metaplex-foundation/mpl-core @metaplex-foundation/umiFetch the Asset to verify ownershipIf the Asset Signer PDA holds funds, transfer them out with executeCall burn(umi, { asset }) as the ownerRent is automatically returned to your walletPrerequisitesUmi configured with a signer that owns the Asset (or is its Burn Delegate)Asset address of the Asset to burnCollection address (if the Asset is in a Collection) Assets can be burnt using the burn instruction. This refunds the Asset account's rent deposit to the transaction payer. Only the one-byte rent-exempt minimum (0.00089784 SOL) stays in the account to prevent it from being reopened; any lamports above that remain there too.Only rent is refundedburn refunds the rent-exempt balance for the account's data size minus the 1-byte floor to the payer. The account is resized to a 1-byte uninitialized account rather than deleted, to prevent address reopen attacks. Any lamports above rent, such as not-yet-collected protocol fees, stay in that 1-byte uninitialized account until swept by the Metaplex fee collector.Code ExampleHere is how you can use our SDKs to burn a Core asset. The snippet assumes that you are the owner of the asset.1import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n2import { burn } from '@metaplex-foundation/mpl-core'\n3import { mplCore } from '@metaplex-foundation/mpl-core'\n4import { publicKey } from '@metaplex-foundation/umi'\n5\n6const umi = createUmi('https://api.devnet.solana.com').use(mplCore())\n7const assetAddress = publicKey('AssetAddressHere...')\n8\n9// Permanently destroy/burn an NFT asset\n10const result = await burn(umi, {\n11 asset: assetAddress,\n12}).sendAndConfirm(umi)\n13\n14console.log('Asset burned successfully')\nBurning an Asset that is part of a CollectionHere is how you can use our SDKs to burn a Core asset that is part of a collection. The snippet assumes that you are the owner of the asset.Burning an Asset that is part of a collectionimport { publicKey } from '@metaplex-foundation/umi'\nimport {\n burn,\n fetchAsset,\n collectionAddress,\n fetchCollection,\n} from '@metaplex-foundation/mpl-core'\n\nconst assetId = publicKey('11111111111111111111111111111111')\nconst asset = await fetchAsset(umi, assetId)\nconst collectionId = collectionAddress(asset)\n\nlet collection = undefined\nif (collectionId) {\n collection = await fetchCollection(umi, collectionId)\n}\n\nawait burn(umi, {\n asset,\n collection,\n}).sendAndConfirm(umi)\nCommon ErrorsAuthority mismatchYou're not the owner or Burn Delegate of the Asset. Check ownership:const asset = await fetchAsset(umi, assetAddress)\nconsole.log(asset.owner) // Must match your signer\nAsset is frozenThe Asset has a Freeze Delegate plugin and is currently frozen. The freeze authority must unfreeze it before burning.Missing collection parameterFor Assets in a Collection, you must pass the collection address. Fetch the Asset first to get the collection:const asset = await fetchAsset(umi, assetAddress)\nconst collectionId = collectionAddress(asset)\nNotesBurning is permanent and irreversible - the Asset cannot be recoveredRent is returned to the payer (amount varies based on asset size and plugins)Only rent is refunded. Any lamports above the rent-exempt minimum are not returned to the ownerThe remaining SOL prevents the account address from being reusedBurn Delegates can burn on behalf of owners (via the Burn Delegate plugin)Frozen Assets must be unfrozen before burningEmpty the Asset Signer PDA before burning — execute fails afterward and remaining balances are strandedQuick ReferenceBurn ParametersParameterRequiredDescriptionassetYesAsset address or fetched objectcollectionIf in collectionCollection addressauthorityNoDefaults to signer (use for delegates)Who Can Burn?AuthorityCan Burn?Asset OwnerYesBurn DelegateYesTransfer DelegateNoUpdate AuthorityNoRent RecoveryItemAmountReturned to payerBase + plugin storage rentRemaining in account~0.0009 SOLLamports above rentNot refundedFAQCan I recover the ~0.0009 SOL left in the account?No. This small amount is intentionally left to mark the account as \"burned\" and prevent its address from being reused for a new Asset.What happens to the Asset's metadata after burning?The on-chain account is cleared (zeroed out). The off-chain metadata remains accessible via the original URI, but there's no on-chain record linking to it.Can a Burn Delegate burn without the owner's approval?Yes. Once an owner assigns a Burn Delegate via the plugin, the delegate can burn the Asset at any time. Owners should only assign trusted addresses as Burn Delegates.Does burning affect the Collection's count?Yes. The Collection's currentSize is decremented when an Asset is burned. The numMinted counter remains unchanged (it tracks total ever minted).Can I burn multiple Assets at once?Not in a single instruction. You can batch multiple burn instructions in one transaction (up to transaction size limits).What happens to SOL and tokens in the Asset Signer PDA when I burn?Burning disables execute. Empty the Asset Signer PDA first or those balances are stranded with no recovery path.GlossaryTermDefinitionBurnPermanently destroy an Asset and recover rentBurn DelegateAn account authorized to burn on behalf of the ownerRentSOL deposited to keep an account alive on SolanaFrozenAn Asset state where burns and transfers are blockedCollectionA group account that the Asset may belong toAsset Signer PDAA wallet attached to the Asset that signs via execute. Burning strands any remaining balances.","tokens":1678,"squid":"dotcat","role":"Tooling Spider","at":1791345011596,"hash":"8686eb0a786cb7248344e23205dd94e6d90f2bc7"}
{"url":"https://akash.network/docs/developers/contributing/","domain":"akash.network","title":"Contributing to Akash Network | Akash Network - Your Guide to Decentralized Cloud","text":"Contributing to Akash Network Thank you for your interest in contributing to Akash Network! This guide will help you get started with contributing to the codebase, documentation, and community.\n\nWays to Contribute\nCode Contributions\nContribute to Akash’s open-source projects:\n\nnode - Akash blockchain node\nprovider - Provider services\nconsole - Akash Console (web UI)\nwebsite - Documentation (this site!)\nawesome-akash - Community deployment examples\n\nDocumentation Contributions\nImprove documentation for all users:\n\nFix typos and errors\nAdd missing information\nUpdate outdated content\nWrite new guides\nAdd code examples\nImprove clarity\n\nSee: Documentation Writing Guide\nCommunity Contributions\nHelp others in the community:\n\nAnswer questions in Discord\nShare your deployment examples\nWrite blog posts or tutorials\nHelp test new features\nReport bugs and issues\n\nGetting Started\n1. Choose Your Contribution Type\nCode:\n\nConsole & Website Setup - Web development (recommended for beginners)\nNode & Provider Setup - Blockchain development (advanced)\nCode Conventions\nPull Request Process\n\nDocumentation:\n\nDocumentation Writing Guide\nConsole & Website Setup\nPull Request Process\n\nCommunity:\n\nJoin Discord\nExplore Awesome Akash\nRead the Blog\n\n2. Set Up Your Environment\nFor code contributions:\n\nClone the relevant repository\nSet up your development environment\nRun tests to verify setup\n\nFor documentation contributions:\n\nClone the website repository\nFollow Console & Website Setup\nRun npm install and npm run dev to preview locally\n\n3. Find Something to Work On\nBrowse open issues:\n\nNode & Provider Issues - All node and provider issues\nConsole Issues - Web UI issues\nDocumentation Issues - Docs issues\nAwesome Akash - Add deployment examples\n\nGood first issues:\n\nLook for issues labeled good first issue or ready-for-community-dev\nDocumentation improvements (typos, missing info, unclear sections)\nSimple bug fixes\nAdding SDL examples to Awesome Akash\n\nAsk for guidance:\n\nDiscord: #developers channel\nGitHub: Comment on issues you’re interested in\nDon’t hesitate to ask questions!\n\nContribution Guidelines\nBefore You Start\n\nCheck existing issues - Someone might already be working on it\nDiscuss major changes - Open an issue or ask in Discord first\nRead the guidelines - Follow code conventions and documentation style\nTest your changes - Ensure everything works before submitting\n\nMaking Changes\n\nFork the repository (for external contributors)\nCreate a branch - Use descriptive names: fix/typo-in-provider-docs\nMake your changes - Follow conventions for the project\nTest thoroughly - Run tests, verify builds pass\nCommit with clear messages - Follow conventional commit format\n\nSubmitting Changes\n\nOpen a pull request - Describe what you changed and why\nLink related issues - Use keywords: Fixes #123\nRespond to feedback - Address reviewer comments\nBe patient - Reviews may take time\n\nCommit Message Format\nUse conventional commit format:\n<type>: <summary>\n<body (optional)>\nTypes:\n\nfeat: - New features\nfix: - Bug fixes\ndocs: - Documentation changes\nchore: - Maintenance tasks\ntest: - Test updates\nrefactor: - Code refactoring\n\nExamples:\nfeat: add GPU support to provider\nfix: correct gas price in validator guide\ndocs: update hardware requirements for providers\nchore: bump dependency versions\n\nCode of Conduct\nBe Respectful\n\nTreat everyone with respect\nWelcome newcomers\nBe patient with questions\nProvide constructive feedback\n\nBe Collaborative\n\nShare knowledge freely\nHelp others succeed\nWork together on solutions\nCelebrate contributions\n\nBe Professional\n\nFocus on the work, not the person\nAccept constructive criticism\nLearn from mistakes\nImprove continuously\n\nGetting Help\nWhere to Ask\nFor code questions:\n\nDiscord: #developers channel\nGitHub: Open an issue or discussion\n\nFor documentation questions:\n\nDiscord: #docs channel (if exists) or #developers\nGitHub: website issues\n\nFor general questions:\n\nDiscord: #general or #support\nCommunity Resources\n\nSupport Workflow\n\nAsk in Discord first - Fastest response\nSearch existing issues - Your question might be answered\nOpen a GitHub issue - If unresolved and needs tracking\nBe specific - Provide context, logs, and steps to reproduce\n\nRecognition\nContributors Are Valued\nYour contributions are appreciated:\n\nAll contributors are acknowledged in release notes\nSignificant contributions are highlighted in blog posts\nActive contributors become trusted community members\nOutstanding contributors may join core teams\n\nBuilding Your Portfolio\nContributing to Akash:\n\nDemonstrates blockchain development skills\nShows open-source collaboration experience\nBuilds your GitHub profile\nConnects you with the Akash community\nMay lead to career opportunities\n\nNext Steps\nReady to contribute?\n\nPick a section:\n\nGetting Started\nConsole & Website Setup - For web development\nNode & Provider Setup - For blockchain development\nDocumentation Guide\nCode Conventions\nPull Request Process\n\nJoin the community:\n\nDiscord\nGitHub\nBlog\n\nStart contributing:\n\nFind a good first issue\nAsk questions in Discord\nSubmit your first PR!\n\nRelated Resources\n\nCommunity Resources\nDeveloper Documentation\nGitHub Organization\n\nQuestions? Join us on Discord - the community is here to help! \nEdit page on github\n Guides Getting Started","tokens":1313,"squid":"spider-03","role":"Compute Spider","at":1791345011666,"hash":"c76be554d7673d662e3864f450eb705e46ab7e81"}
{"url":"https://forum.arbitrum.foundation/t/stip-round-1-application-period-update/17523/1","domain":"forum.arbitrum.foundation","title":"STIP - Round 1: Application Period Update - Archive / Short Term Incentives Program (STIP) Round 1 - Arbitrum","text":"The Arbitrum Foundation notified the Security Council on the need to perform a potential Emergency action. Following a review of the details and known risks, the Security Council decided to execute the upgrade and it was completed at 11:30 EST on 2nd October 2026.\nThis report provides an overview of the risks that required the Security Council Action:\n\nAdd a permissionless guard for the One-Step Proof of BoLD on Arbitrum One\n\nTemporarily pause activation of new Stylus contracts on Arbitrum One & Nova\n\nKey point: To date, known bugs for Stylus primarily impact chain liveness (e.g., denial of service attacks) and do not put any user funds at risk.\nWhy was this action taken\nLet’s take this opportunity to explain why action was taken on two separate issues concerning BoLD and Stylus.\nInstalling the guard for One-Step Proof of BoLD. Given the rise of AI-assisted attacks, we have implemented a precautionary approach that allows anyone to pause settlement of Arbitrum One on Ethereum if there are at least two conflicting answers that pass at the same level in which only one should be valid and pass. This is to halt a class of publicly verifiable and detectable attacks that exploit a bug in the one-step proof. If halted, Arbitrum One will continue to process as normal except that messages from Arbitrum One to Ethereum, such as withdrawals, that are not yet confirmed will have to wait. This provides time for the Security Council to deploy a fix for the bug and resume the rollup.\nPreventing activation of new Stylus contracts. AI-assisted tooling has led to an increasing number of sophisticated attacks on hand-crafted WASM programs that do not use the standard Stylus compiler toolchain. These programs are specifically designed to cause unexpected behaviors such as degrading the chain’s performance for all other users. To date, no attacks have been discovered that permits theft of user funds.\nNew ArbOS releases have patched several reported bugs and known attacks over the past few months, but out of an abundance of caution, we have decided to temporarily pause new activations of Stylus contracts. This was executed as an emergency action to prevent the deployment of new hand-crafted WASM programs that are not yet patched by the current version of ArbOS on the Arbitrum network.\nThe Arbitrum Foundation has informed the Security Council that they will work with the ArbitrumDAO to discuss next steps on the timeline and manner for enabling activation of new Stylus contracts. The Arbitrum community remains confident in the value of Stylus and want to preserve these use cases while taking preventative measures against Stylus-based attack vectors as AI-assisted attack tooling continues to evolve.\nImpact on builders and users\n\nNo new activations. New Stylus contracts cannot be activated during the pause including new versions of existing applications that require activation.\n\nExisting contracts are not paused. Already-active Stylus contracts continue to execute until expiration. This pause does not deactivate them.\n\nThe ArbOS 61 upgrade renewed all active contracts on Arbitrum One, so no currently active contract expires before August 20, 2027.\n\nRenewal via keepalive stays permissionless and is unaffected by the pause.\n\nReactivating an expired contract, or one that needs to be updated after a Stylus version change, is paused.\n\nUsing/calling any activated Stylus contract stays permissionless for all users and developers.\n\nNo impact on EVM. Solidity (EVM) contract deployment and execution are unaffected by this Security Council action.\n\nSecurity Council Actions\nThere are two actions bundled into a single payload:\n\nOne-Step Proof Guard. The L1UpgradeExecutor gives a new pause contract (PauseExecutor) the ability to pause and nothing else. The new pause contract grants the guard (OspSoundnessGuard) PAUSER_ROLE to use it. Anyone can show the guard two conflicting answers to the same step of an open challenge. If the one-step proof accepts both, the guard has the pause contract put Arbitrum One’s settlement to Ethereum on hold.\n\nStylus deactivation. The Security Council called ArbOwner.setWasmActivationGas(2^64 - 1) to raise the Stylus activation gas requirement on Arbitrum One and Nova. This makes activation prohibitively expensive and effectively disables new activations. This is a configuration change and does not require an ArbOS upgrade.\n\nThe Security Council signed the following transactions to update the configuration:\n\nEthereum: Ethereum Transaction Hash: 0x30732bb7d2... | Etherscan\nArbitrum One:\nArbitrum One Transaction Hash: 0x9eb3a4be3b... | Arbitrum One\nArbitrum Nova:\nArbitrum Nova transaction 0x79e0fed470dff7a22059b108e3f8f42eddd2b580a6771594060c4e7326c5f984 | Blockscout\n\nAn external audit was conducted for the OSP Guard contracts. No audit is required for the Stylus deactivation as it is only updating a single parameter in the ArbOS configuration.\n\n STIP - Round 1: Application Period Update \n\n ArchiveShort Term Incentives Program (STIP) Round 1\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Sep 2023\n\n 1 / 23\n\n Sep 2023\n\n Oct 2023\n\n post by Matt_StableLab on Sep 27, 2023\n\n Matt_StableLab\n\n Hi Everyone,\nThis is a formal announcement that the Application Period will end tonight, on September 27, 2023 11:59 PM EST.\nOnce the application period has concluded, any new applications will be withheld from the forum and will be placed in the forum queue until Round 2 of the program.\nRound 1 of the program will proceed with the following timeline:\n\nReview Period Begins: September 28, 2023 12:00 AM EST\n\nReview Period Deadline: October 4, 2023 11:59 PM EST\n\nVoting Period Begins: October 5, 2023\n\nVoting Period Deadline: October 12, 2023\n\nTo clarify the process ahead…\nDuring the Voting Period, eligible applications will be put to vote on Arbitrum Snapshot. StableLab will mark applications as ready for vote depending upon each application’s eligibility. To be eligible for Snapshot, programs must follow the following steps:\n\nApplications must integrate feedback to meet all of the aforementioned Application Requirements for the STIP program:\n\nApplications must format their post correctly.\nOnce feedback is collected, applicants will need to change their application title from [DRAFT] to [FINAL] by the Review Period deadline: October 4, 2023 11:59 PM EST. At that time, all eligible proposals with the following formatted titles will be migrated to Arbitrum Snapshot to vote. The correct format for a proposal ready to move to vote looks like this: [Project Name] [FINAL] [STIP - Round 1].\n\nIf your proposal has NOT been formatted as such it will NOT proceed to Snapshot.\nThe voting period will allow delegates to vote to determine each application’s success. To succeed, eligible applications must receive a greater than 50% majority in favor of the proposal and exceed the 71.51 million ARB vote quorum outlined in the STIP proposal.\nNext Steps\nTo kickoff the Review Period, StableLab is ingesting the rush of last minute proposals with plans to publish two posts tomorrow:\n\nA summary and review guide of existing applications for Delegates.\nA Community Call Schedule for both Applicants and Delegates.\n\nLastly, as we approach the voting period, StableLab and the STIP-ARB Multisig will publish additional information regarding the KYC process and the fund disbursement schedule and cadence for successful STIP Round 1 grantees.\nWe look forward to proceeding into the Review period tomorrow and we thank the DAO again for its support.\n\n [Shell Protocol] [FINAL] [STIP - Round 1]\n\n [Wormhole][FINAL][STIP - Round 1]\n\n [CRYPTEX FINANCE] [FINAL] [STIP - Round 1]\n\n [REALM] [FINAL] [STIP - Round 1]\n\n [PancakeSwap] [FINAL] [STIP - Round 1]\n\n 3\n\n 2\n\n 2\n\n 2\n\n post by HMX on Sep 27, 2023\n\n post by Matt_StableLab on Sep 27, 2023\n\n post by HMX on Sep 27, 2023\n\n post by cliffton.eth on Sep 27, 2023\n\n post by HMX on Sep 27, 2023\n\n Pinned on Sep 27, 2023\n\n post by archipelabro on Sep 27, 2023\n\n post by tnorm on Sep 28, 2023\n\n post by AlexLumley on Sep 28, 2023\n\n post by KeepBuildong on Sep 28, 2023\n\n post by CastleCapital on Oct 1, 2023\n\n post by North on Oct 2, 2023\n\n post by ALAYA on Oct 2, 2023\n\n post by chefmaroon on Oct 4, 2023\n\n post by TheTrueLeonidas on Oct 4, 2023\n\n post by 543 on Oct 4, 2023\n\n post by archipelabro on Oct 5, 2023\n\n post by InspexCo on Oct 6, 2023\n\n post by mhiztasolid on Oct 7, 2023\n\n Load more posts below","tokens":2109,"squid":"spider-07","role":"Council Spider","at":1791345017246,"hash":"e1aa1f5c2ae4aabaae6a5cafcb291c6ba0be7fdb"}
{"url":"https://akash.network/docs/developers/contributing/console-website-setup/","domain":"akash.network","title":"Console & Website Development Setup | Akash Network - Your Guide to Decentralized Cloud","text":"Console & Website Development Setup Get started with Console and website development—much simpler than node/provider setup!\nThis guide covers setting up development environments for:\n\nAkash Console - Web UI (React/Next.js)\nAkash Website - Documentation site (Astro)\n\nPerfect for first-time contributors! These projects are easier to set up than node/provider development.\n\nPrerequisites\nRequired Software\n\nNode.js - 22.14.0 or later (download)\nnpm - Comes with Node.js (or use pnpm/yarn)\nGit - Version control\nCode Editor - VS Code recommended\n\nVerify Installation\nTerminal windownode --version # Should be v22.14.0 or highernpm --version # Should be 10.x or highergit --version\n\nConsole Development Setup\nRepository: github.com/akash-network/console\nTech Stack: React, Next.js, TypeScript, TailwindCSS\nStep 1: Fork and Clone\nTerminal window# 1. Fork the repository on GitHub (click \"Fork\" button)\n# 2. Clone your forkgit clone https://github.com/YOUR-USERNAME/console.gitcd console\n# 3. Add upstream remotegit remote add upstream https://github.com/akash-network/console.git\n# 4. Verify remotesgit remote -v\nStep 2: Install Dependencies\nTerminal window# Install all packagesnpm install\n# Or use pnpm (faster alternative)npm install -g pnpmpnpm install\nStep 3: Set Up Environment\nTerminal window# Copy example environment filecp .env.example .env.local\n# Edit .env.local with your configurationvim .env.local # or code .env.local\nTypical .env.local contents:\nTerminal window# API ConfigurationNEXT_PUBLIC_API_BASE_URL=https://console-api.akash.network\n# Network ConfigurationNEXT_PUBLIC_MAINNET_RPC=https://rpc.akashnet.net:443NEXT_PUBLIC_TESTNET_RPC=https://rpc.sandbox-2.aksh.pw:443\n# Feature Flags (optional)NEXT_PUBLIC_ENABLE_BETA_FEATURES=false\nStep 4: Run Development Server\nTerminal windownpm run dev\nExpected output:\n> console@x.x.x dev> next dev\n- ready started server on 0.0.0.0:3000- Local: http://localhost:3000- Network: http://192.168.x.x:3000\nOpen browser: Visit http://localhost:3000 to see the Console.\nStep 5: Verify Setup\nTerminal window# Run testsnpm test\n# Run linternpm run lint\n# Auto-fix linting issuesnpm run lint:fix\n# Type checknpm run type-check\n# Build production versionnpm run build\nAll checks should pass before submitting a PR.\n\nConsole Project Structure\nconsole/├── src/│ ├── app/ # Next.js app router pages│ ├── components/ # React components│ ├── hooks/ # Custom React hooks│ ├── lib/ # Utility libraries│ ├── services/ # API services│ ├── stores/ # State management│ ├── types/ # TypeScript types│ └── styles/ # Global styles├── public/ # Static assets├── .env.example # Environment variables template└── package.json\n\nConsole Development Workflow\n1. Create a Feature Branch\nTerminal windowgit checkout -b feature/add-deployment-filter\n2. Make Your Changes\nEdit files in src/:\nsrc/components/DeploymentCard.tsxexport const DeploymentCard: React.FC<Props> = ({ deployment }) => { return ( <div className=\"rounded-lg border p-4\"> <h3>{deployment.dseq}</h3> <p>Status: {deployment.state}</p> </div> )}\n3. Test Your Changes\nTerminal window# Development server (hot reload)npm run dev\n# Run testsnpm test\n# Check typesnpm run type-check\n# Lint codenpm run lint\n4. Build and Verify\nTerminal window# Build productionnpm run build\n# Test production build locallynpm run start\n5. Commit and Push\nTerminal windowgit add .git commit -s -m \"feat: add deployment filter component\"git push origin feature/add-deployment-filter\n6. Open Pull Request\nGo to GitHub and create a PR from your fork to akash-network/console.\n\nConsole Common Tasks\nUpdate dependencies:\nTerminal windownpm updatenpm audit fix\nClear cache and reinstall:\nTerminal windowrm -rf node_modules .nextnpm install\nRun specific test:\nTerminal windownpm test -- DeploymentCard.test.tsx\nFormat code:\nTerminal windownpm run format\n\nWebsite Development Setup\nRepository: github.com/akash-network/website\nTech Stack: Astro, React, TypeScript, TailwindCSS, MDX\nStep 1: Fork and Clone\nTerminal window# 1. Fork the repository on GitHub\n# 2. Clone your forkgit clone https://github.com/YOUR-USERNAME/website.gitcd website\n# 3. Add upstream remotegit remote add upstream https://github.com/akash-network/website.git\n# 4. Verify remotesgit remote -v\nStep 2: Install Dependencies\nTerminal windownpm install\nStep 3: Run Development Server\nTerminal windownpm run dev\nExpected output:\n astro v4.x.x started in Xms\n ┃ Local http://localhost:4321/ ┃ Network use --host to expose\n ┃ watching for file changes...\nOpen browser: Visit http://localhost:4321 to preview the docs.\nStep 4: Verify Setup\nTerminal window# Build sitenpm run build\n# Preview production buildnpm run preview\n# Run Astro checksnpm run astro -- check\n# Format codenpm run format\n\nWebsite Project Structure\nwebsite/├── src/│ ├── content/│ │ └── Docs/ # All documentation (Markdown/MDX)│ │ ├── getting-started/│ │ ├── for-developers/│ │ ├── for-providers/│ │ └── learn/│ ├── components/ # React/Astro components│ ├── layouts/ # Page layouts│ ├── pages/ # Route pages│ └── styles/ # Global styles├── public/ # Static assets (images, fonts)└── astro.config.mjs # Astro configuration\n\nWebsite Development Workflow\n1. Create a Feature Branch\nTerminal windowgit checkout -b docs/improve-cli-guide\n2. Make Your Changes\nEdit documentation:\nTerminal window# Documentation is in src/content/Docs/vim src/content/Docs/for-developers/deployment/cli/index.md\nExample edit:\n---categories: [\"Developers\", \"Deployment\"]tags: [\"CLI\", \"Command Line\"]weight: 1title: \"Akash CLI Guide\"linkTitle: \"CLI\"description: \"Deploy using the Akash command-line interface\"---\n# Akash CLI Guide\nDeploy applications on Akash using the command-line interface...\n## Installation\n```bash# Install provider-services CLIcurl -sSfL https://raw.githubusercontent.com/akash-network/provider/main/install.sh | sh\nYour First Deployment\n\nCreate SDL file…\n\n#### 3. Preview Your Changes\n```bash# Development server with hot reloadnpm run dev\n# Visit http://localhost:4321 and navigate to your page\n4. Build and Verify\nTerminal window# Build production sitenpm run build\n# Check for errorsnpm run astro -- check\n# Preview production buildnpm run preview\n5. Commit and Push\nTerminal windowgit add .git commit -s -m \"docs: improve CLI installation instructions\"git push origin docs/improve-cli-guide\n6. Open Pull Request\nCreate a PR from your fork to akash-network/website.\n\nWebsite Common Tasks\nAdd new documentation page:\n\nCreate new .md or .mdx file in src/content/Docs/\nAdd frontmatter\nWrite content\nPreview with npm run dev\n\nUpdate navigation:\nNavigation is auto-generated from:\n\nFolder structure in src/content/Docs/\nweight in frontmatter (lower = higher in sidebar)\ncategories in frontmatter (for breadcrumbs)\n\nAdd images:\n<!-- Place images in public/images/ -->![Alt text](/images/my-screenshot.png)\nTest links:\nTerminal window# Build and check for broken linksnpm run build\n# Any broken links will show errors during build\nFormat all files:\nTerminal windownpm run format\n\nEditor Setup\nVS Code (Recommended)\nInstall extensions:\nTerminal windowcode --install-extension astro-build.astro-vscodecode --install-extension dbaeumer.vscode-eslintcode --install-extension esbenp.prettier-vscodecode --install-extension bradlc.vscode-tailwindcss\nWorkspace settings (.vscode/settings.json):\n{ \"editor.formatOnSave\": true, \"editor.defaultFormatter\": \"esbenp.prettier-vscode\", \"editor.codeActionsOnSave\": { \"source.fixAll.eslint\": true }, \"[astro]\": { \"editor.defaultFormatter\": \"astro-build.astro-vscode\" }, \"[markdown]\": { \"editor.wordWrap\": \"on\" }}\n\nTroubleshooting\nConsole Issues\nPort 3000 already in use:\nTerminal window# Kill process on port 3000lsof -i :3000kill -9 <PID>\n# Or use different portnpm run dev -- -p 3001\nModule not found errors:\nTerminal window# Clear cache and reinstallrm -rf node_modules .nextnpm install\nEnvironment variables not loading:\nTerminal window# Ensure .env.local existsls -la .env.local\n# Verify environment variables start with NEXT_PUBLIC_grep NEXT_PUBLIC_ .env.local\nBuild fails:\nTerminal window# Check for TypeScript errorsnpm run type-check\n# Check for linting errorsnpm run lint\n# Clear Next.js cacherm -rf .nextnpm run build\n\nWebsite Issues\nPort 4321 already in use:\nTerminal window# Kill process on port 4321lsof -i :4321kill -9 <PID>\nBuild fails:\nTerminal window# Check Astro configurationnpm run astro -- check\n# Clear cacherm -rf .astro distnpm run build\nImages not showing:\nTerminal window# Ensure images are in public/ directoryls -la public/images/\n# Use absolute paths in markdown# Correct: ![Alt](/images/pic.png)# Incorrect: ![Alt](./images/pic.png)\nMDX parsing errors:\nTerminal window# Check frontmatter format# Ensure YAML is valid# Check for unclosed code blocks\n\nCommon Development Commands\nConsole\n\nCommandPurposenpm run devStart development servernpm testRun testsnpm run lintCheck code qualitynpm run lint:fixAuto-fix linting issuesnpm run type-checkCheck TypeScript typesnpm run buildBuild production bundlenpm run startServe production buildnpm run formatFormat code with Prettier\nWebsite\n\nCommandPurposenpm run devStart development servernpm run buildBuild production sitenpm run previewPreview production buildnpm run astro -- checkCheck for errorsnpm run formatFormat code with Prettier\n\nKeep Your Fork Updated\nSync with Upstream\nTerminal window# Fetch upstream changesgit fetch upstream\n# Switch to main branchgit checkout main\n# Merge upstream changesgit merge upstream/main\n# Push to your forkgit push origin main\nUpdate Your Feature Branch\nTerminal window# Switch to your feature branchgit checkout feature/your-feature\n# Rebase on latest maingit rebase main\n# If conflicts, resolve them and continuegit add .git rebase --continue\n# Force push to update PRgit push --force-with-lease origin feature/your-feature\n\nBest Practices\nFor Console Development\n\nTest in multiple browsers - Chrome, Firefox, Safari\nCheck mobile responsiveness - Use browser dev tools\nFollow accessibility guidelines - Use semantic HTML, ARIA labels\nKeep components small - Single responsibility principle\nWrite tests - For new components and functions\nUse TypeScript - Don’t use any type\n\nFor Documentation\n\nTest all commands - Every command must work\nAdd code examples - Show, don’t just tell\nUse proper formatting - Code blocks, headings, lists\nKeep it concise - Remove unnecessary words\nLink related content - Help users navigate\nCheck spelling - Use a spell checker\n\nGetting Help\nConsole Help\n\nDiscord: discord.akash.network - #developers channel\nGitHub Issues: console/issues\nDocumentation: Check the Console README\n\nWebsite Help\n\nDiscord: discord.akash.network - #developers channel\nGitHub Issues: website/issues\nAstro Docs: docs.astro.build\n\nNext Steps\nReady to contribute?\n\nGetting Started Guide - Make your first contribution\nCode Conventions - Learn coding standards\nDocumentation Guide - Write great docs\nPull Request Process - Submit your changes\n\nQuestions? Ask in Discord #developers! \nEdit page on github\n Node & Provider Setup Code Conventions","tokens":2746,"squid":"spider-03","role":"Compute Spider","at":1791345024435,"hash":"59083f66c85e3c503760b769f2de84f8c77ec077"}
{"url":"https://forum.arbitrum.foundation/c/archive/incentive-framework/14","domain":"forum.arbitrum.foundation","title":"Latest Archive/Short Term Incentives Program (STIP) Round 1 topics - Arbitrum","text":"The Arbitrum Foundation notified the Security Council on the need to perform a potential Emergency action. Following a review of the details and known risks, the Security Council decided to execute the upgrade and it was completed at 11:30 EST on 2nd October 2026.\nThis report provides an overview of the risks that required the Security Council Action:\n\nAdd a permissionless guard for the One-Step Proof of BoLD on Arbitrum One\n\nTemporarily pause activation of new Stylus contracts on Arbitrum One & Nova\n\nKey point: To date, known bugs for Stylus primarily impact chain liveness (e.g., denial of service attacks) and do not put any user funds at risk.\nWhy was this action taken\nLet’s take this opportunity to explain why action was taken on two separate issues concerning BoLD and Stylus.\nInstalling the guard for One-Step Proof of BoLD. Given the rise of AI-assisted attacks, we have implemented a precautionary approach that allows anyone to pause settlement of Arbitrum One on Ethereum if there are at least two conflicting answers that pass at the same level in which only one should be valid and pass. This is to halt a class of publicly verifiable and detectable attacks that exploit a bug in the one-step proof. If halted, Arbitrum One will continue to process as normal except that messages from Arbitrum One to Ethereum, such as withdrawals, that are not yet confirmed will have to wait. This provides time for the Security Council to deploy a fix for the bug and resume the rollup.\nPreventing activation of new Stylus contracts. AI-assisted tooling has led to an increasing number of sophisticated attacks on hand-crafted WASM programs that do not use the standard Stylus compiler toolchain. These programs are specifically designed to cause unexpected behaviors such as degrading the chain’s performance for all other users. To date, no attacks have been discovered that permits theft of user funds.\nNew ArbOS releases have patched several reported bugs and known attacks over the past few months, but out of an abundance of caution, we have decided to temporarily pause new activations of Stylus contracts. This was executed as an emergency action to prevent the deployment of new hand-crafted WASM programs that are not yet patched by the current version of ArbOS on the Arbitrum network.\nThe Arbitrum Foundation has informed the Security Council that they will work with the ArbitrumDAO to discuss next steps on the timeline and manner for enabling activation of new Stylus contracts. The Arbitrum community remains confident in the value of Stylus and want to preserve these use cases while taking preventative measures against Stylus-based attack vectors as AI-assisted attack tooling continues to evolve.\nImpact on builders and users\n\nNo new activations. New Stylus contracts cannot be activated during the pause including new versions of existing applications that require activation.\n\nExisting contracts are not paused. Already-active Stylus contracts continue to execute until expiration. This pause does not deactivate them.\n\nThe ArbOS 61 upgrade renewed all active contracts on Arbitrum One, so no currently active contract expires before August 20, 2027.\n\nRenewal via keepalive stays permissionless and is unaffected by the pause.\n\nReactivating an expired contract, or one that needs to be updated after a Stylus version change, is paused.\n\nUsing/calling any activated Stylus contract stays permissionless for all users and developers.\n\nNo impact on EVM. Solidity (EVM) contract deployment and execution are unaffected by this Security Council action.\n\nSecurity Council Actions\nThere are two actions bundled into a single payload:\n\nOne-Step Proof Guard. The L1UpgradeExecutor gives a new pause contract (PauseExecutor) the ability to pause and nothing else. The new pause contract grants the guard (OspSoundnessGuard) PAUSER_ROLE to use it. Anyone can show the guard two conflicting answers to the same step of an open challenge. If the one-step proof accepts both, the guard has the pause contract put Arbitrum One’s settlement to Ethereum on hold.\n\nStylus deactivation. The Security Council called ArbOwner.setWasmActivationGas(2^64 - 1) to raise the Stylus activation gas requirement on Arbitrum One and Nova. This makes activation prohibitively expensive and effectively disables new activations. This is a configuration change and does not require an ArbOS upgrade.\n\nThe Security Council signed the following transactions to update the configuration:\n\nEthereum: Ethereum Transaction Hash: 0x30732bb7d2... | Etherscan\nArbitrum One:\nArbitrum One Transaction Hash: 0x9eb3a4be3b... | Arbitrum One\nArbitrum Nova:\nArbitrum Nova transaction 0x79e0fed470dff7a22059b108e3f8f42eddd2b580a6771594060c4e7326c5f984 | Blockscout\n\nAn external audit was conducted for the OSP Guard contracts. No audit is required for the Stylus deactivation as it is only updating a single parameter in the ArbOS configuration.\n\n Latest topics in Short Term Incentives Program (STIP) Round 1\n\n Archive\n\n Short Term Incentives Program (STIP) Round 1\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 STIP Application Template\n\n SECTION 1: APPLICANT INFORMATION\nProvide personal or organizational details, including applicant name, contact information, and any associated organization. This information ensures proper identification and communicatio…\n\n read more\n\n 5\n\n 3.9k\n\n Oct 2023\n\n How to Apply - Arbitrum Short Term Incentives Program\n\n *Note: This program follows two tracks as outlined in the Incentive Framework Category post. The continuation of this program and any grants approved by the Arbitrum DAO are dependent upon the successful passage of AIP 9.…\n\n read more\n\n 41\n\n 7.8k\n\n Nov 2023\n\n About the Incentive Framework category\n\n Arbitrum’s Short-Term Incentive Program has passed a temperature check on Snapshot. \nAs part of the proposal, there are two tracks for the incentive program: \n\nThe Arbitrum DAO will vote on the final proposal via on-chai…\n\n read more\n\n 0\n\n 1.2k\n\n Sep 2023\n\n OpenBlock’s STIP Incentive Efficacy Analysis\n\n 0\n\n 1.0k\n\n Dec 2024\n\n [Synapse Protocol][STIP - Round 1] [ Update]\n\n 0\n\n 878\n\n Dec 2024\n\n STIP Winning Proposals - Next Steps\n\n 0\n\n 1.6k\n\n Dec 2024\n\n STIP Grant Recipients Update\n\n 0\n\n 3.8k\n\n Dec 2024\n\n Clarification - Assignment rules for STIP due requests exceeding budget\n\n 0\n\n 669\n\n Dec 2024\n\n STIP Backfund Stream Updates\n\n 4\n\n 1.4k\n\n Feb 2024\n\n [Wormhole][FINAL][STIP - Round 1]\n\n 25\n\n 14.0k\n\n Feb 2024\n\n [Rodeo Finance] [FINAL] [STIP - Round 1]\n\n 29\n\n 3.5k\n\n Feb 2024\n\n [Savvy] [FINAL] [STIP - Round 1]\n\n proposal\n\n 31\n\n 4.3k\n\n Jan 2024\n\n [StakeDAO] [FINAL] [STIP - Round 1]\n\n 28\n\n 4.1k\n\n Jan 2024\n\n [GMX] [FINAL] [STIP - Round 1]\n\n 173\n\n 22.3k\n\n Jan 2024\n\n [REALM] [FINAL] [STIP - Round 1]\n\n 23\n\n 4.4k\n\n Jan 2024\n\n [Gamma] [FINAL] [STIP - Round 1]\n\n proposal\n\n 32\n\n 5.2k\n\n Jan 2024\n\n [Umami Finance] [FINAL] [STIP - Round 1]\n\n 35\n\n 4.7k\n\n Jan 2024\n\n [ANGLE PROTOCOL] [FINAL] [STIP - Round 1]\n\n 25\n\n 4.0k\n\n Jan 2024\n\n [Galxe] [FINAL] [STIP - Round 1]\n\n 24\n\n 4.3k\n\n Jan 2024\n\n [Furucombo] [FINAL] [STIP - Round 1]\n\n 14\n\n 2.7k\n\n Jan 2024\n\n [Balancer] [FINAL] [STIP - Round 1]\n\n 56\n\n 6.4k\n\n Dec 2023\n\n [Synapse Protocol] [FINAL][STIP - Round 1]\n\n proposal\n\n 26\n\n 4.5k\n\n Dec 2023\n\n [Sanko GameCorp] [FINAL] [STIP - Round 1]\n\n 36\n\n 6.4k\n\n Dec 2023\n\n [TIDE][FINAL][STIP - Round 1]\n\n 16\n\n 2.8k\n\n Dec 2023\n\n [Gains Network][FINAL][STIP - Round 1]\n\n proposal\n\n 86\n\n 7.7k\n\n Dec 2023\n\n [RAMSES] [FINAL] [STIP - Round 1]\n\n 250\n\n 14.3k\n\n Dec 2023\n\n [Thales] [FINAL] [STIP - Round 1]\n\n proposal\n\n 19\n\n 3.7k\n\n Dec 2023\n\n [Florence Finance] [FINAL] [STIP - Round 1]\n\n proposal\n\n 9\n\n 2.6k\n\n Nov 2023\n\n STIP Funding Stream Updates\n\n 14\n\n 2.9k\n\n Nov 2023\n\n [KyberSwap] [FINAL] [STIP - Round 1]\n\n 33\n\n 5.3k\n\n Nov 2023","tokens":1949,"squid":"spider-07","role":"Council Spider","at":1791345027335,"hash":"5ec3915a04cc5cda1ec897204cb53ba548e1c2fc"}
{"url":"https://www.metaplex.com/docs/smart-contracts/core/guides/create-soulbound-nft-asset","domain":"metaplex.com","title":"Soulbound Assets in MPL Core | Core Guides","text":"Soulbound NFTs are non-fungible tokens that are permanently bound to a specific wallet address and cannot be transferred to another owner. They are useful for representing achievements, credentials, or memberships that should remain tied to a specific identity. OverviewIn this guide, we'll explore how to create soulbound assets using MPL Core and the Umi Framework. Whether you're a developer looking to implement soulbound NFTs in TypeScript or just want to understand how they work, we'll cover everything from basic concepts to practical implementation. We'll examine different approaches for making assets soulbound and walk through creating your first soulbound NFT within a collection. In MPL Core, there are two main approaches to create soulbound NFTs:1. Permanent Freeze Delegate PluginMakes assets completely non-transferrable and non-burnableCan be applied at either:Individual asset levelCollection level (more rent efficient)Collection-level implementation allows thawing all assets in a single transaction2. Oracle PluginMakes assets non-transferrable but still burnableCan also be applied at:Individual asset levelCollection level (more rent efficient)Collection-level implementation allows thawing all assets in a single transactionCreating Soulbound NFTs with the Permanent Freeze Delegate PluginThe Permanent Freeze Delegate Plugin provides functionality to make assets non-transferrable by freezing them. When creating a soulbound asset, you would:Include the Permanent Freeze plugin during asset creationSet the initial state to frozenSet the authority to None, making the frozen state permanent and immutable This effectively creates a permanently soulbound asset that cannot be transferred or thawed. In the following code snippet it is shown where to add those three options: await create(umi, {\n asset: assetSigner,\n collection: collection,\n name: \"My Frozen Asset\",\n uri: \"https://example.com/my-asset.json\",\n plugins: [\n {\n type: 'PermanentFreezeDelegate', // Include the Permanent Freeze plugin\n frozen: true, // Set the initial state to frozen\n authority: { type: \"None\" }, // Set the authority to None\n },\n ],\n })\nAsset-Level ImplementationThe Permanent Freeze Delegate Plugin can be attached to individual assets to make them soulbound. This provides more granular control but requires more rent and separate thaw transactions per asset in case it ever should not be soulbound anymore.Collection-Level ImplementationFor collections where all assets should be soulbound, applying the plugin at the collection level is more efficient. This requires less rent and enables thawing the entire collection in one transaction.Creating Soulbound NFTs with the Oracle PluginThe Oracle Plugin provides a way to approve or reject different lifecycle events for an asset. To create soulbound NFTs, we can use a special Oracle deployed by Metaplex that always rejects transfer events while still allowing other operations like burning. This differs from the Permanent Freeze Delegate Plugin approach since assets remain burnable even though they cannot be transferred. When creating a soulbound asset using the Oracle Plugin, one would attach the plugin to the asset. This can be done on creation or afterwards. In this example we are using a default Oracle that will always reject and has been deployed by Metaplex. This effectively creates a permanently soulbound asset that cannot be transferred but burned. In the following code snippet it is shown how:const ORACLE_ACCOUNT = publicKey(\n \"GxaWxaQVeaNeFHehFQEDeKR65MnT6Nup81AGwh2EEnuq\"\n);\nawait create(umi, {\n asset: assetSigner,\n collection: collection,\n name: \"My Soulbound Asset\",\n uri: \"https://example.com/my-asset.json\",\n plugins: [\n {\n // The Oracle plugin allows us to control transfer permissions\n type: \"Oracle\",\n resultsOffset: {\n type: \"Anchor\",\n },\n baseAddress: ORACLE_ACCOUNT,\n lifecycleChecks: {\n // Configure the Oracle to reject all transfer attempts\n transfer: [CheckResult.CAN_REJECT],\n },\n baseAddressConfig: undefined,\n },\n ],\n})\nAsset-Level ImplementationThe Oracle Plugin can make individual assets non-transferrable while preserving the ability to burn them. This provides flexibility for cases where assets may need to be destroyed.Collection-Level ImplementationApplying the Oracle Plugin at the collection level makes all assets in the collection non-transferrable but burnable. This is more rent efficient and allows managing permissions for the entire collection at once.","tokens":1118,"squid":"dotcat","role":"Tooling Spider","at":1791345034431,"hash":"a8dc527b5e091ee7555f714b6637139d6ffafd0c"}
{"url":"https://akash.network/docs/developers/contributing/code-conventions/","domain":"akash.network","title":"Code Conventions & Standards | Akash Network - Your Guide to Decentralized Cloud","text":"Code Conventions & Standards Write consistent, maintainable code that follows Akash Network standards.\nThis guide covers coding conventions for Go (node, provider) and JavaScript/TypeScript (console, docs) projects.\n\nGeneral Principles\nCode Quality\n\nReadability first - Code is read more than written\nSimple over clever - Prefer clarity over cleverness\nConsistent style - Follow existing patterns\nTest your code - Write tests for new functionality\nDocument complexity - Add comments for non-obvious logic\n\nYAGNI Principle\n“You Aren’t Gonna Need It” - Don’t add functionality until it’s needed.\n\nBuild what’s required now\nAvoid over-engineering\nJustify features with real use cases\nDefend proposals with data, not hypotheses\n\nGo Conventions\nCode Style\nFollow the official Go Code Review Comments.\nFormatting\nTerminal window# Use gofmt (required)gofmt -w .\n# Or goimports (preferred - also manages imports)goimports -w .\n# Project lintingmake lint\nProject Structure\ncmd/ # Main applicationspkg/ # Library codeinternal/ # Private application codeapi/ # API definitionstestutil/ # Test utilitiesintegration/ # Integration tests\nNaming Conventions\nPackage Names\n// Good: Short, lowercase, no underscorespackage bidenginepackage deploymentpackage manifest\n// Bad: Mixed case, underscorespackage bidEnginepackage bid_engine\nVariables\n// Good: CamelCase for exported, camelCase for unexportedtype DeploymentManager struct { MaxBids int bidders []Bidder}\n// Bad: Inconsistent casingtype deploymentManager struct { max_bids int}\nFunctions\n// Good: Descriptive, action-orientedfunc CreateDeployment(ctx context.Context, sdl []byte) (*Deployment, error)func ValidateManifest(m *Manifest) errorfunc (d *Deployment) Close() error\n// Bad: Vague or inconsistentfunc DoStuff() errorfunc deployment_create() error\nError Handling\n// Good: Return errors, don't panicfunc ProcessBid(bid *Bid) (*Lease, error) { if bid == nil { return nil, errors.New(\"bid cannot be nil\") }\n lease, err := createLease(bid) if err != nil { return nil, fmt.Errorf(\"failed to create lease: %w\", err) }\n return lease, nil}\n// Good: Wrap errors with contextif err != nil { return fmt.Errorf(\"processing bid %s: %w\", bid.ID, err)}\n// Bad: Ignoring errorslease, _ := createLease(bid)\n// Bad: Panicking in library codeif err != nil { panic(err)}\nInterfaces\n// Good: Small, focused interfacestype Bidder interface { PlaceBid(ctx context.Context, order Order) (*Bid, error)}\ntype LeaseManager interface { CreateLease(ctx context.Context, bid *Bid) (*Lease, error) CloseLease(ctx context.Context, leaseID LeaseID) error}\n// Good: Accept interfaces, return structsfunc ProcessBids(ctx context.Context, bidder Bidder, orders []Order) ([]*Bid, error)\n// Bad: Large interfaces with many methodstype Everything interface { DoBid() DoLease() DoManifest() DoEverything()}\nTesting\n// Good: Table-driven testsfunc TestCreateDeployment(t *testing.T) { tests := []struct { name string sdl []byte want *Deployment wantErr bool }{ { name: \"valid SDL\", sdl: []byte(\"version: '2.0'...\"), want: &Deployment{...}, wantErr: false, }, { name: \"invalid SDL\", sdl: []byte(\"invalid\"), want: nil, wantErr: true, }, }\n for _, tt := range tests { t.Run(tt.name, func(t *testing.T) { got, err := CreateDeployment(context.Background(), tt.sdl) if (err != nil) != tt.wantErr { t.Errorf(\"CreateDeployment() error = %v, wantErr %v\", err, tt.wantErr) return } if !reflect.DeepEqual(got, tt.want) { t.Errorf(\"CreateDeployment() = %v, want %v\", got, tt.want) } }) }}\nGoroutine Leak Detection\n// Good: Use goleak to detect goroutine leaksimport \"go.uber.org/goleak\"\nfunc TestMyFunction(t *testing.T) { defer goleak.VerifyNone(t)\n // Your test code that uses goroutines}\nComments\n// Good: Package documentation// Package bidengine provides bid placement and management for Akash providers.// It handles bid evaluation, placement, and lease creation.package bidengine\n// Good: Exported function documentation// CreateDeployment creates a new deployment from the provided SDL.// It validates the SDL, creates the deployment transaction, and returns// the deployment ID.//// Returns an error if the SDL is invalid or the transaction fails.func CreateDeployment(ctx context.Context, sdl []byte) (*Deployment, error)\n// Good: Explain complex logic// Calculate bid price using the formula:// price = (cpu * cpuPrice) + (memory * memPrice) + (storage * storagePrice)// Prices are in uact per unit per block (ACT is the deployment/payment denom).price := calculateBidPrice(resources)\n// Bad: Obvious comments// Increment counter by 1counter++\nContext Usage\n// Good: Pass context as first parameterfunc CreateDeployment(ctx context.Context, sdl []byte) (*Deployment, error)\n// Good: Check context cancellationselect {case <-ctx.Done(): return ctx.Err()case result := <-ch: return result, nil}\n// Bad: Store context in structtype Manager struct { ctx context.Context // Don't do this}\n\nJavaScript/TypeScript Conventions\nCode Style\nFollow Airbnb JavaScript Style Guide and TypeScript best practices.\nFormatting\nTerminal window# Use Prettier (required)npm run format\n# Or Prettier with eslintnpm run lint:fix\nNaming Conventions\n// Good: PascalCase for components and classesexport const DeploymentCard: React.FC<Props> = ({ deployment }) => { }export class DeploymentManager { }\n// Good: camelCase for variables and functionsconst deploymentId = \"123\"function createDeployment(sdl: string) { }\n// Good: UPPER_SNAKE_CASE for constantsconst MAX_BID_AMOUNT = 1000const API_BASE_URL = \"https://api.akash.network\"\n// Bad: Inconsistent casingconst DeploymentId = \"123\" // Should be camelCasefunction CreateDeployment() { } // Should be camelCase\nTypeScript Best Practices\n// Good: Explicit types for function parameters and returnsfunction createDeployment(sdl: string, deposit: number): Promise<Deployment> { return api.post<Deployment>(\"/deployments\", { sdl, deposit })}\n// Good: Use interfaces for object shapesinterface Deployment { dseq: string owner: string state: DeploymentState createdAt: Date}\n// Good: Use enums for fixed valuesenum DeploymentState { Active = \"active\", Closed = \"closed\", Paused = \"paused\"}\n// Bad: Using `any`function processDeployment(data: any) { // Avoid `any` return data.something}\n// Better: Use proper types or `unknown`function processDeployment(data: unknown) { if (isDeployment(data)) { return data.dseq }}\nReact Component Conventions\n// Good: Functional components with TypeScriptinterface DeploymentCardProps { deployment: Deployment onClose: (id: string) => void}\nexport const DeploymentCard: React.FC<DeploymentCardProps> = ({ deployment, onClose}) => { const handleClose = () => { onClose(deployment.dseq) }\n return ( <div className=\"deployment-card\"> <h3>{deployment.dseq}</h3> <button onClick={handleClose}>Close</button> </div> )}\n// Good: Custom hooks for reusable logicfunction useDeployments() { const [deployments, setDeployments] = useState<Deployment[]>([]) const [loading, setLoading] = useState(true)\n useEffect(() => { fetchDeployments().then(setDeployments).finally(() => setLoading(false)) }, [])\n return { deployments, loading }}\n// Bad: Prop drilling (use Context or state management)<ComponentA deployment={deployment}> <ComponentB deployment={deployment}> <ComponentC deployment={deployment} /> </ComponentB></ComponentA>\nError Handling\n// Good: Try-catch with proper error handlingasync function createDeployment(sdl: string): Promise<Deployment> { try { const response = await api.post<Deployment>(\"/deployments\", { sdl }) return response.data } catch (error) { if (axios.isAxiosError(error)) { throw new Error(`Failed to create deployment: ${error.message}`) } throw error }}\n// Good: Error boundaries for Reactclass ErrorBoundary extends React.Component<Props, State> { static getDerivedStateFromError(error: Error) { return { hasError: true, error } }\n componentDidCatch(error: Error, errorInfo: React.ErrorInfo) { console.error(\"Error caught by boundary:\", error, errorInfo) }\n render() { if (this.state.hasError) { return <ErrorDisplay error={this.state.error} /> } return this.props.children }}\nAsync/Await\n// Good: Use async/awaitasync function fetchDeployments(): Promise<Deployment[]> { const response = await api.get<Deployment[]>(\"/deployments\") return response.data}\n// Good: Handle errorsasync function fetchDeployments(): Promise<Deployment[]> { try { const response = await api.get<Deployment[]>(\"/deployments\") return response.data } catch (error) { console.error(\"Failed to fetch deployments:\", error) return [] }}\n// Bad: Unhandled promise rejectionsfunction fetchDeployments() { return api.get(\"/deployments\") // What if this fails?}\n\nDocumentation Conventions\nMarkdown Style\n<!-- Good: Clear headings --># Main Title## Section### Subsection\n<!-- Good: Code blocks with language -->```typescriptconst deployment = await createDeployment(sdl)\n\nUse the provider-services CLI to create a deployment.\n\ncode here\n### Writing Style\n- **Use active voice** - \"The provider accepts the bid\" not \"The bid is accepted\"- **Be concise** - Remove unnecessary words- **Use examples** - Show, don't just tell- **Link related content** - Help users navigate- **Update screenshots** - Keep visuals current\n---\n## Git Conventions\n### Commit Messages\nFollow [Conventional Commits](https://www.conventionalcommits.org/):\n```bash# Format<type>: <subject>\n<body>\n<footer>\nTypes:\n\nfeat: - New feature\nfix: - Bug fix\ndocs: - Documentation\nchore: - Maintenance\ntest: - Tests\nrefactor: - Code refactoring\nstyle: - Formatting\nperf: - Performance\n\nExamples:\nTerminal window# Simple fixfix: resolve escrow calculation error\n# Feature with descriptionfeat: add GPU resource filtering\nProviders can now filter available GPUs by model and memory.This improves bid accuracy for GPU deployments.\nFixes #123\n# Breaking changefeat!: change deployment state enum values\nBREAKING CHANGE: Deployment states are now lowercase stringsinstead of integers. Update client code accordingly.\nBranch Names\nTerminal window# Good: Descriptive branch namesfeature/gpu-bid-filteringfix/escrow-calculation-errordocs/update-cli-guidechore/bump-dependencies\n# Bad: Vague namesmy-changesfix-stuffupdate\n\nCode Review Checklist\nBefore Submitting PR\n\n Code follows project conventions\n All tests pass (make test or npm test)\n Linter passes (make lint or npm run lint)\n Added tests for new functionality\n Updated documentation if needed\n Commit messages follow convention\n Commits are signed-off (git commit -s)\n\nDuring Code Review\nAs Author:\n\nRespond to all comments\nAsk for clarification if needed\nMake requested changes promptly\nLearn from feedback\n\nAs Reviewer:\n\nBe constructive and respectful\nExplain the “why” behind suggestions\nPraise good code\nFocus on the code, not the person\n\nAdditional Resources\nGo\n\nEffective Go\nGo Code Review Comments\nUber Go Style Guide\n\nJavaScript/TypeScript\n\nAirbnb JavaScript Style Guide\nTypeScript Do’s and Don’ts\nReact TypeScript Cheatsheet\n\nGeneral\n\nConventional Commits\nSemantic Versioning\n\nNext Steps\n\nPull Request Process - Submit your changes\nGetting Started - Make your first contribution\n\nQuestions? Ask in Discord #developers! \nEdit page on github\n Console & Website Setup Pull Request Process","tokens":2790,"squid":"spider-03","role":"Compute Spider","at":1791345034482,"hash":"c6898283a5ca6c07c1c8768efe34ecd85fc24e85"}
{"url":"https://forum.arbitrum.foundation/t/synapse-protocol-stip-round-1-update/20192","domain":"forum.arbitrum.foundation","title":"[Synapse Protocol][STIP - Round 1] [ Update] - Archive / Short Term Incentives Program (STIP) Round 1 - Arbitrum","text":"The Arbitrum Foundation notified the Security Council on the need to perform a potential Emergency action. Following a review of the details and known risks, the Security Council decided to execute the upgrade and it was completed at 11:30 EST on 2nd October 2026.\nThis report provides an overview of the risks that required the Security Council Action:\n\nAdd a permissionless guard for the One-Step Proof of BoLD on Arbitrum One\n\nTemporarily pause activation of new Stylus contracts on Arbitrum One & Nova\n\nKey point: To date, known bugs for Stylus primarily impact chain liveness (e.g., denial of service attacks) and do not put any user funds at risk.\nWhy was this action taken\nLet’s take this opportunity to explain why action was taken on two separate issues concerning BoLD and Stylus.\nInstalling the guard for One-Step Proof of BoLD. Given the rise of AI-assisted attacks, we have implemented a precautionary approach that allows anyone to pause settlement of Arbitrum One on Ethereum if there are at least two conflicting answers that pass at the same level in which only one should be valid and pass. This is to halt a class of publicly verifiable and detectable attacks that exploit a bug in the one-step proof. If halted, Arbitrum One will continue to process as normal except that messages from Arbitrum One to Ethereum, such as withdrawals, that are not yet confirmed will have to wait. This provides time for the Security Council to deploy a fix for the bug and resume the rollup.\nPreventing activation of new Stylus contracts. AI-assisted tooling has led to an increasing number of sophisticated attacks on hand-crafted WASM programs that do not use the standard Stylus compiler toolchain. These programs are specifically designed to cause unexpected behaviors such as degrading the chain’s performance for all other users. To date, no attacks have been discovered that permits theft of user funds.\nNew ArbOS releases have patched several reported bugs and known attacks over the past few months, but out of an abundance of caution, we have decided to temporarily pause new activations of Stylus contracts. This was executed as an emergency action to prevent the deployment of new hand-crafted WASM programs that are not yet patched by the current version of ArbOS on the Arbitrum network.\nThe Arbitrum Foundation has informed the Security Council that they will work with the ArbitrumDAO to discuss next steps on the timeline and manner for enabling activation of new Stylus contracts. The Arbitrum community remains confident in the value of Stylus and want to preserve these use cases while taking preventative measures against Stylus-based attack vectors as AI-assisted attack tooling continues to evolve.\nImpact on builders and users\n\nNo new activations. New Stylus contracts cannot be activated during the pause including new versions of existing applications that require activation.\n\nExisting contracts are not paused. Already-active Stylus contracts continue to execute until expiration. This pause does not deactivate them.\n\nThe ArbOS 61 upgrade renewed all active contracts on Arbitrum One, so no currently active contract expires before August 20, 2027.\n\nRenewal via keepalive stays permissionless and is unaffected by the pause.\n\nReactivating an expired contract, or one that needs to be updated after a Stylus version change, is paused.\n\nUsing/calling any activated Stylus contract stays permissionless for all users and developers.\n\nNo impact on EVM. Solidity (EVM) contract deployment and execution are unaffected by this Security Council action.\n\nSecurity Council Actions\nThere are two actions bundled into a single payload:\n\nOne-Step Proof Guard. The L1UpgradeExecutor gives a new pause contract (PauseExecutor) the ability to pause and nothing else. The new pause contract grants the guard (OspSoundnessGuard) PAUSER_ROLE to use it. Anyone can show the guard two conflicting answers to the same step of an open challenge. If the one-step proof accepts both, the guard has the pause contract put Arbitrum One’s settlement to Ethereum on hold.\n\nStylus deactivation. The Security Council called ArbOwner.setWasmActivationGas(2^64 - 1) to raise the Stylus activation gas requirement on Arbitrum One and Nova. This makes activation prohibitively expensive and effectively disables new activations. This is a configuration change and does not require an ArbOS upgrade.\n\nThe Security Council signed the following transactions to update the configuration:\n\nEthereum: Ethereum Transaction Hash: 0x30732bb7d2... | Etherscan\nArbitrum One:\nArbitrum One Transaction Hash: 0x9eb3a4be3b... | Arbitrum One\nArbitrum Nova:\nArbitrum Nova transaction 0x79e0fed470dff7a22059b108e3f8f42eddd2b580a6771594060c4e7326c5f984 | Blockscout\n\nAn external audit was conducted for the OSP Guard contracts. No audit is required for the Stylus deactivation as it is only updating a single parameter in the ArbOS configuration.\n\n [Synapse Protocol][STIP - Round 1] [ Update] \n\n ArchiveShort Term Incentives Program (STIP) Round 1\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n post by moses on Dec 20, 2023\n\n moses\n\n This is an update to the Synapse STIP Round 1 proposal, that was created in October 2023, and approved as part of the STIP Backfund.\nThe Funding Address used to receive the STIP funds is:\n0xD31d3A2C19123b8FF48560c20a08fFB16aD62dFe\nThe address above is a 2/3 multi-sig controlled by the Synapse DAO.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Synapse STIP Addendum\n\n STIP Bridge Addendum\n\n 6\n\n 1.2k\n\n May 2024\n\n Notice: New Multisig Wallet for STIP fund management (Magpie Ecosystem)\n\n Report Misuse of Funds\n\n 0\n\n 899\n\n Dec 2023\n\n Notice: New multisig wallet for STIP fund management (Shell Protocol)\n\n Report Misuse of Funds\n\n 0\n\n 577\n\n Mar 2024\n\n STIP Funding Stream Updates\n\n Short Term Incentives Program (STIP) Round 1\n\n 14\n\n 2.9k\n\n Nov 2023\n\n Synapse Protocol Bi-Weekly STIP Backfund Updates\n\n Biweekly Updates (STIP)\n\n 3\n\n 955\n\n Mar 2024","tokens":1511,"squid":"spider-07","role":"Council Spider","at":1791345037363,"hash":"80817cdc3603e014073b266226d78e428847df69"}
{"url":"https://akash.network/docs/developers/contributing/getting-started/","domain":"akash.network","title":"Getting Started with Contributing | Akash Network - Your Guide to Decentralized Cloud","text":"Getting Started with Contributing Ready to contribute? Here’s how to get started!\nThis guide walks you through making your first contribution to Akash Network, from finding an issue to submitting your pull request.\n\nStep 1: Choose What to Work On\nFind an Issue\nCore Repositories:\n\nSupport Repository - All node and provider issues\nConsole Repository - Web UI issues\nWebsite Repository - Documentation issues\n\nLook for:\n\nIssues labeled good first issue - Beginner-friendly tasks\nIssues labeled ready-for-community-dev - Ready for community contributions\nIssues labeled help wanted - Core team welcomes help\nIssues labeled documentation - Doc improvements\n\nTypes of Contributions\n1. Documentation Improvements\nPerfect for first contributions!\n\nFix typos and broken links\nClarify confusing sections\nAdd missing information\nImprove code examples\nUpdate outdated content\n\nWhere to contribute:\n\nWebsite Issues\nBrowse existing docs and spot improvements\n\n2. Code Contributions\nNode & Provider:\n\nBug fixes\nNew features\nPerformance improvements\nTest coverage\n\nConsole:\n\nUI improvements\nNew features\nBug fixes\nAccessibility improvements\n\n3. Deployment Examples\nAwesome Akash:\n\nAdd new SDL examples\nImprove existing examples\nTest and verify examples\nDocument deployment steps\n\nBrowse Awesome Akash →\n\nStep 2: Set Up Your Environment\nFor Documentation Contributions\nDocumentation contributions are perfect for first-timers!\n\nSet up the website repository:\n\nFollow the Console & Website Setup Guide\nQuick version:\n\nTerminal windowgit clone https://github.com/YOUR-USERNAME/website.gitcd websitenpm installnpm run dev\n\nCreate a branch:\nTerminal windowgit checkout -b docs/your-improvement-name\n\nFor Code Contributions (Node/Provider)\nNode and provider development requires a complete Kubernetes environment. Follow these steps:\n\nFork the repositories:\n\nakash-network/node\nakash-network/provider\n\nClone both repositories:\nTerminal windowmkdir -p ~/go/src/github.com/akash-networkcd ~/go/src/github.com/akash-network\ngit clone https://github.com/YOUR-USERNAME/node.gitgit clone https://github.com/YOUR-USERNAME/provider.git\n\nInstall all development dependencies:\nTerminal window# Automated installer for all required tools./provider/script/install_dev_dependencies.sh\n\nSet up local Kubernetes cluster:\nTerminal windowcd provider/_run/kube\n# Create and provision cluster (may take several minutes)make kube-cluster-setup\n# If timeout occurs, use extended timeout:KUBE_ROLLOUT_TIMEOUT=300 make kube-cluster-setup\n\nCreate a branch:\nTerminal windowcd ~/go/src/github.com/akash-network/node # or providergit checkout -b feature/your-feature-name\n\nImportant: Node and provider development requires a complete Kubernetes environment and is significantly more complex than other contributions. New contributors should start with documentation or Console contributions first. See the complete Development Environment Guide for detailed setup instructions.\nFor Console Contributions\nConsole is a great place to start with React/TypeScript contributions!\n\nSet up the console repository:\n\nFollow the Console & Website Setup Guide\nQuick version:\n\nTerminal windowgit clone https://github.com/YOUR-USERNAME/console.gitcd consolenpm installnpm run dev\n\nCreate a branch:\nTerminal windowgit checkout -b feature/your-feature-name\n\nStep 3: Make Your Changes\nBest Practices\n\nStart small - Your first PR doesn’t need to be big\nFollow existing patterns - Look at how similar code is written\nTest your changes - Verify everything works\nKeep it focused - One issue per PR\nDocument your changes - Add comments for complex logic\n\nFor Documentation Changes\n\nEdit the relevant .md or .mdx file in src/content/Docs/\nPreview your changes with npm run dev\nCheck formatting with npm run build\n\nTips:\n\nUse clear, concise language\nAdd code examples where helpful\nInclude links to related docs\nTest all code examples\n\nFor Code Changes\n\nWrite code following project conventions\n\nRun tests:\nTerminal windowmake test\n\nRun linter:\nTerminal windowmake lint\n\nVerify build:\nTerminal windowmake build\n\nSee: Code Conventions\n\nStep 4: Commit Your Changes\nCommit Message Format\nUse conventional commits:\n<type>: <short summary>\n<optional body>\nTypes:\n\nfeat: - New feature\nfix: - Bug fix\ndocs: - Documentation changes\nchore: - Maintenance tasks\ntest: - Test updates\nrefactor: - Code refactoring\nstyle: - Formatting changes\n\nExamples:\nTerminal window# Documentation fixgit commit -m \"docs: fix typo in CLI installation guide\"\n# Feature additiongit commit -m \"feat: add GPU filtering to provider bidengine\"\n# Bug fix with descriptiongit commit -m \"fix: resolve escrow balance calculation error\nThe escrow balance was not accounting for fees correctly,causing incorrect balance displays in the console.\"\nSign Your Commits\nAll commits must be signed-off:\nTerminal windowgit commit -s -m \"docs: update provider setup guide\"\nThis adds a Signed-off-by: line to your commit, certifying you have the right to submit the contribution under the project’s license.\nConfigure your git identity:\nTerminal windowgit config --global user.name \"Your Name\"git config --global user.email \"your.email@example.com\"\n\nStep 5: Push and Create a Pull Request\nPush Your Changes\nTerminal windowgit push origin your-branch-name\nCreate the Pull Request\n\nGo to your fork on GitHub\n\nClick “Compare & pull request”\n\nFill out the PR template:\nTitle: Use conventional commit format\ndocs: improve CLI installation guide\nDescription: Explain what and why\n## Changes- Added troubleshooting section for macOS- Fixed broken links to provider docs- Clarified version requirements\n## WhyUsers were getting stuck on installation due to missing macOS instructions.\nFixes #123\n\nLink related issues:\n\nFixes #123 - Closes issue #123\nRelates to #456 - References issue #456\n\nClick “Create pull request”\n\nStep 6: Respond to Feedback\nReview Process\n\nAutomated checks run - CI, linting, tests\nMaintainers review - May take a few days\nChanges requested - Address feedback\nApproval - PR gets merged!\n\nAddressing Feedback\nTerminal window# Make requested changes# ... edit files ...\n# Commit changesgit add .git commit -s -m \"fix: address review feedback\"\n# Push to update PRgit push origin your-branch-name\nBe Patient and Professional\n\nReviews may take time - maintainers are volunteers\nRespond to all comments\nAsk for clarification if needed\nDon’t take criticism personally\nLearn from the feedback\n\nCommon First Contribution Ideas\nDocumentation\n\nFix typos in any documentation page\nAdd missing links between related docs\nImprove clarity in confusing sections\nAdd code examples to API references\nUpdate screenshots or outdated information\n\nCode\n\nFix a good first issue bug\nAdd test coverage to existing code\nImprove error messages\nAdd logging for debugging\nUpdate dependencies\n\nDeployment Examples\n\nAdd your SDL to Awesome Akash\nTest and verify existing examples\nAdd README documentation\nCreate category-specific examples\n\nGetting Help\nBefore Asking\n\nSearch existing issues - Your question might be answered\nCheck documentation - Read relevant guides\nReview closed PRs - See how similar changes were done\n\nWhere to Ask\nDiscord:\n\n#developers - Code and technical questions\n#general - General questions\n#providers - Provider-specific questions\n\nGitHub:\n\nComment on the issue you’re working on\nOpen a Discussion for ideas\nAsk in your PR if you need guidance\n\nBest Practices:\n\nBe specific - Provide context, logs, errors\nShow what you’ve tried\nBe respectful of people’s time\nFollow up if you solve it yourself\n\nAfter Your First Contribution\nKeep Contributing!\n\nLook for more issues to work on\nHelp review others’ PRs - Learn from their code\nShare your experience - Write about your contribution\nJoin community calls - Get to know the team\n\nLevel Up\nAs you gain experience:\n\nTackle more complex issues\nPropose new features\nBecome a regular reviewer\nHelp onboard new contributors\nJoin a Special Interest Group (SIG)\n\nNext Steps\nReady for more?\n\nCode Conventions - Learn coding standards\nDevelopment Environment - Deep dive into setup\nPull Request Process - Detailed PR guide\n\nRecognition\nYour contributions matter:\n\nAll contributors acknowledged in release notes\nActive contributors join the community leaders\nOutstanding contributors may join core teams\nBuild your portfolio and reputation\n\nThank you for contributing to Akash Network!\n\nQuestions? Join Discord and ask in #developers! \nEdit page on github\n Guides Node & Provider Setup","tokens":2103,"squid":"spider-03","role":"Compute Spider","at":1791345044464,"hash":"8ec82c75ade71ef78e05ed73b034759003752aa8"}
{"url":"https://forum.arbitrum.foundation/t/synapse-stip-addendum/23353/7","domain":"forum.arbitrum.foundation","title":"Synapse STIP Addendum - Archive / STIP Bridge Addendum - Arbitrum","text":"The Arbitrum Foundation notified the Security Council on the need to perform a potential Emergency action. Following a review of the details and known risks, the Security Council decided to execute the upgrade and it was completed at 11:30 EST on 2nd October 2026.\nThis report provides an overview of the risks that required the Security Council Action:\n\nAdd a permissionless guard for the One-Step Proof of BoLD on Arbitrum One\n\nTemporarily pause activation of new Stylus contracts on Arbitrum One & Nova\n\nKey point: To date, known bugs for Stylus primarily impact chain liveness (e.g., denial of service attacks) and do not put any user funds at risk.\nWhy was this action taken\nLet’s take this opportunity to explain why action was taken on two separate issues concerning BoLD and Stylus.\nInstalling the guard for One-Step Proof of BoLD. Given the rise of AI-assisted attacks, we have implemented a precautionary approach that allows anyone to pause settlement of Arbitrum One on Ethereum if there are at least two conflicting answers that pass at the same level in which only one should be valid and pass. This is to halt a class of publicly verifiable and detectable attacks that exploit a bug in the one-step proof. If halted, Arbitrum One will continue to process as normal except that messages from Arbitrum One to Ethereum, such as withdrawals, that are not yet confirmed will have to wait. This provides time for the Security Council to deploy a fix for the bug and resume the rollup.\nPreventing activation of new Stylus contracts. AI-assisted tooling has led to an increasing number of sophisticated attacks on hand-crafted WASM programs that do not use the standard Stylus compiler toolchain. These programs are specifically designed to cause unexpected behaviors such as degrading the chain’s performance for all other users. To date, no attacks have been discovered that permits theft of user funds.\nNew ArbOS releases have patched several reported bugs and known attacks over the past few months, but out of an abundance of caution, we have decided to temporarily pause new activations of Stylus contracts. This was executed as an emergency action to prevent the deployment of new hand-crafted WASM programs that are not yet patched by the current version of ArbOS on the Arbitrum network.\nThe Arbitrum Foundation has informed the Security Council that they will work with the ArbitrumDAO to discuss next steps on the timeline and manner for enabling activation of new Stylus contracts. The Arbitrum community remains confident in the value of Stylus and want to preserve these use cases while taking preventative measures against Stylus-based attack vectors as AI-assisted attack tooling continues to evolve.\nImpact on builders and users\n\nNo new activations. New Stylus contracts cannot be activated during the pause including new versions of existing applications that require activation.\n\nExisting contracts are not paused. Already-active Stylus contracts continue to execute until expiration. This pause does not deactivate them.\n\nThe ArbOS 61 upgrade renewed all active contracts on Arbitrum One, so no currently active contract expires before August 20, 2027.\n\nRenewal via keepalive stays permissionless and is unaffected by the pause.\n\nReactivating an expired contract, or one that needs to be updated after a Stylus version change, is paused.\n\nUsing/calling any activated Stylus contract stays permissionless for all users and developers.\n\nNo impact on EVM. Solidity (EVM) contract deployment and execution are unaffected by this Security Council action.\n\nSecurity Council Actions\nThere are two actions bundled into a single payload:\n\nOne-Step Proof Guard. The L1UpgradeExecutor gives a new pause contract (PauseExecutor) the ability to pause and nothing else. The new pause contract grants the guard (OspSoundnessGuard) PAUSER_ROLE to use it. Anyone can show the guard two conflicting answers to the same step of an open challenge. If the one-step proof accepts both, the guard has the pause contract put Arbitrum One’s settlement to Ethereum on hold.\n\nStylus deactivation. The Security Council called ArbOwner.setWasmActivationGas(2^64 - 1) to raise the Stylus activation gas requirement on Arbitrum One and Nova. This makes activation prohibitively expensive and effectively disables new activations. This is a configuration change and does not require an ArbOS upgrade.\n\nThe Security Council signed the following transactions to update the configuration:\n\nEthereum: Ethereum Transaction Hash: 0x30732bb7d2... | Etherscan\nArbitrum One:\nArbitrum One Transaction Hash: 0x9eb3a4be3b... | Arbitrum One\nArbitrum Nova:\nArbitrum Nova transaction 0x79e0fed470dff7a22059b108e3f8f42eddd2b580a6771594060c4e7326c5f984 | Blockscout\n\nAn external audit was conducted for the OSP Guard contracts. No audit is required for the Stylus deactivation as it is only updating a single parameter in the ArbOS configuration.\n\n ArchiveSTIP Bridge Addendum\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 Apr 2024\n\n 7 / 7\n\n May 2024\n\n May 2024\n\n post by moses on Apr 21, 2024\n\n post by Matt_StableLab on Apr 22, 2024\n\n post by SEEDGov on Apr 23, 2024\n\n 10 days later\n\n post by moses on May 3, 2024\n\n 11 days later\n\n post by SEEDGov on May 15, 2024\n\n post by moses on May 15, 2024\n\n moses\n\n Thank you for your review here. To clarify on some of the points raised here:\n1. Data Reporting\nThroughout the program we published Bi-Weekly updates here: Synapse Protocol Bi-Weekly STIP Backfund Updates - #4 by moses. This data can be used as the source of truth, was audited and is being implemented by Openblocks now to share. The reasons for data discrepancies were all outlined here: Synapse STIP Addendum - #4 by moses\n2. Metrics\nSynapse delivered on the first and most important goal of the program, Encouraging new $$ into the Arbitrum ecosystem. (More than $3b in bridge volume). These dollars flowed into partner protocols like GMX and Uniswap through modules like SynapseX and xAsset token bridging. In regards to the last goal of increasing TVL → The development of SynapseRFQ accomplished the first two items in a capital efficient way, such that idle liquidity (TVL) is replaced with just-in-time liquidity providers (relayers). So while TVL on Arbitrum did not increase by an order of magnitude, bridging and volume overall increased more capital efficiently than any liquidity based bridging,\n3. The allocation of 750k ARB was not only allocated in the original proposal under “Slippage-free bridging” (which was accomplished), but also was earned delegated by individual relayers (and since @socrates has requested that they undelegate). I further elaborate on this here: Concerns Regarding Possible Misconduct by Synapse with Respect to the Usage of ARB Incentives Allocated Through the STIP - #4 by moses\n@socrates elaborates on the delegation of the 750k ARB by the relayers\n\n750k ARB was distributed to bridgers as fee rebates, and 750k was distributed to RFQ relayers. I asked those relayers if they’d consider delegating their Arb to me which they did. As mentioned in @moses’s reply, I can see how this could be viewed as some sort of “quid-pro-quo” and have since asked them to undelegate or vote themselves. That said, I don’t think it’s against STIP rules; my understanding is the ARB shouldn’t be used by the DAO for governance, but after it’s distributed to relayers, users, LPs, etc, they can use it for governance.\n\nfuthermore:\n\nIn regards to the use of Arb in governance, a clarification of the rules here would be helpful. The original STIP proposal says, \" Grants are not to be used in DAO governance\". Our understanding of this was that Arb tokens given to the respective STIP DAOs shouldn’t be used in governance but once they’ve been distributed, it could be used. Similar to how LPs & traders that received Arb from GMX’s STIP program could use the Arb in governance.\n\nThe full response to these concerns can be found here: Concerns Regarding Possible Misconduct by Synapse with Respect to the Usage of ARB Incentives Allocated Through the STIP - #5 by Socrates\n\n post by Socrates on May 20, 2024\n\n Socrates\n\n Synapse will be withdrawing from STIP-Bridge. Please consider our application withdrawn. We will be responding further with a detailed post but just posting this now in the interest of time since the challenge period is coming to an end.\n\n Concerns Regarding Possible Misconduct by Synapse with Respect to the Usage of ARB Incentives Allocated Through the STIP\n\n ARDC Research Deliverables\n\n [RFC] Incentives Detox Proposal\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Concerns Regarding Possible Misconduct by Synapse with Respect to the Usage of ARB Incentives Allocated Through the STIP\n\n ARDC Research Member\n\n 17\n\n 3.2k\n\n Jul 2024\n\n Synapse Protocol Bi-Weekly STIP Backfund Updates\n\n Biweekly Updates (STIP)\n\n 3\n\n 955\n\n Mar 2024\n\n [Synapse Protocol] [FINAL][STIP - Round 1]\n\n Short Term Incentives Program (STIP) Round 1\n\n proposal\n\n 26\n\n 4.5k\n\n Dec 2023\n\n Savvy DAO STIP Addendum\n\n STIP Bridge Addendum\n\n 18\n\n 1.2k\n\n May 2024\n\n Stake DAO STIP Addendum\n\n STIP Bridge Addendum\n\n 20\n\n 1.2k\n\n May 2024","tokens":2312,"squid":"spider-07","role":"Council Spider","at":1791345047447,"hash":"287f6780bafd7337d23a90d2c48012e57dd95387"}
{"url":"https://akash.network/docs/developers/contributing/documentation-guide/","domain":"akash.network","title":"Documentation Writing Guide | Akash Network - Your Guide to Decentralized Cloud","text":"Documentation Writing Guide Write clear, helpful documentation that serves all Akash users.\nThis guide covers how to contribute to Akash documentation, including style guidelines, structure, and best practices.\n\nWhy Documentation Matters\nGood documentation:\n\nReduces support burden - Fewer questions in Discord\nImproves onboarding - New users get started faster\nBuilds trust - Professional docs signal project quality\nEnables growth - Users can self-serve and scale\n\nDocumentation is code - Treat it with the same care and rigor.\n\nGetting Started\nDocumentation Repository\nAll documentation lives at github.com/akash-network/website\nStructure:\nsrc/content/Docs/├── getting-started/ # New user guides├── for-developers/ # Developer documentation│ ├── deployment/ # Deployment methods│ ├── contributing/ # Contributing guides│ └── ...├── for-providers/ # Provider documentation├── for-node-operators/ # Validator/node docs└── learn/ # Educational content\nSetup\nTerminal window# Fork and clonegit clone https://github.com/YOUR-USERNAME/website.gitcd website\n# Install dependenciesnpm install\n# Run dev servernpm run dev\n# Visit http://localhost:4321\n\nFinding Documentation to Improve\nWhere to Start\n\nBrowse GitHub Issues\n\nLook for documentation label\nCheck good first issue for beginners\n\nRead the docs as a new user\n\nFollow tutorials\nTry examples\nNote what’s confusing\n\nListen to community questions\n\nCheck Discord #general and #support\nFrequent questions = missing docs\n\nReview existing content\n\nFix typos\nUpdate outdated information\nImprove clarity\n\nDocumentation Types\n1. Tutorials\nPurpose: Teach a specific task step-by-step\nStructure:\n# Task Title\nBrief introduction to what they'll learn.\n## Prerequisites- List what they need before starting\n## Step 1: First ActionClear instructions with commands\n## Step 2: Next ActionContinue with next logical step\n## VerifyHow to confirm it worked\n## Next StepsWhere to go from here\nExample: CLI Installation Guide\n2. How-To Guides\nPurpose: Solve a specific problem\nStructure:\n# How to [Do Something]\nProblem statement and use case.\n## Quick SolutionTL;DR for experienced users\n## Detailed Steps1. Step one2. Step two3. Step three\n## TroubleshootingCommon issues and solutions\n## RelatedLinks to related guides\nExample: Update a Deployment\n3. Reference Documentation\nPurpose: Comprehensive technical details\nStructure:\n# [Component] Reference\nOverview and purpose.\n## API / CommandsComplete list with syntax\n## ParametersAll options explained\n## ExamplesCode samples\n## Error HandlingCommon errors and solutions\nExample: CLI Commands Reference\n4. Explanations\nPurpose: Explain concepts and architecture\nStructure:\n# Understanding [Concept]\nWhat is it and why it matters.\n## How It WorksTechnical explanation\n## Use CasesWhen to use it\n## Best PracticesRecommended approaches\n## Learn MoreFurther reading\nExample: Core Concepts\n\nWriting Style\nVoice and Tone\nUse:\n\nActive voice - “The provider accepts bids” not “Bids are accepted”\nSecond person - “You deploy” not “Users deploy” or “One deploys”\nPresent tense - “The CLI creates” not “The CLI will create”\nDirect language - “Run this command” not “You might want to consider running”\n\nExamples:\n**Good:** \"Deploy your application using the CLI\"**Bad:** \"Applications can be deployed by users via the CLI\"\n**Good:** \"Create a deployment with this command\"**Bad:** \"A deployment may be created using the following command\"\nClarity\nBe specific:\n**Vague:** \"Install the required dependencies\"**Specific:** \"Install Go 1.25.0 or later\"\n**Vague:** \"Configure your environment\"**Specific:** \"Set the AKASH_NODE environment variable\"\nRemove unnecessary words:\n**Wordy:** \"In order to create a deployment, you will need to...\"**Concise:** \"To create a deployment...\"\n**Wordy:** \"There are three different methods available for...\"**Concise:** \"Three methods for...\"\nTechnical Accuracy\n\nTest all commands - Every command must work\nVerify code examples - All code must compile/run\nKeep versions current - Update version numbers\nLink to source - Reference actual code when possible\n\nFormatting\nHeadings\n# H1: Page Title (only one per page)## H2: Main Sections### H3: Subsections#### H4: Minor Sections (use sparingly)\nGood heading structure:\n# Deploy with CLI\n## Prerequisites\n## Installation\n### macOS\n### Linux\n### Windows\n## Your First Deployment\n### Create SDL File\n### Deploy\n## Next Steps\nCode Blocks\nAlways specify language:\n```bashprovider-services tx deployment create deploy.yaml```\n```typescriptconst sdk = createChainNodeSDK({ rpcEndpoint: \"https://rpc.akashnet.net:443\"})```\n```yamlversion: \"2.0\"services: web: image: nginx:1.25.3```\nInline Code\nUse backticks for:\n\nCommands: provider-services\nFile names: deploy.yaml\nVariable names: AKASH_NODE\nPackage names: @akashnetwork/chain-sdk\n\nRun `provider-services version` to check your installation.\nLists\nOrdered lists for sequences:\n1. Install the CLI2. Configure your wallet3. Create deployment\nUnordered lists for non-sequential items:\n- CPU: 0.5 cores- Memory: 512Mi- Storage: 1Gi\nLinks\nInternal links:\nSee the [CLI Guide](/docs/developers/deployment/cli).\nExternal links:\nInstall [Node.js](https://nodejs.org/) version 22 or later.\nAnchor links:\nJump to [Installation](#installation).\nTables\n| Feature | CLI | Console | SDK ||---------|-----|---------|-----|| Easy to use | Moderate | High | Moderate || Automation | High | Low | High || GUI | No | Yes | No |\nAdmonitions\nUse for important information:\n**Note:** This feature requires provider-services v0.10.0 or later.\n**Warning:** This command will close your deployment and refund remaining escrow (ACT).\n**Tip:** Use `--dry-run` to preview changes without applying them.\n **Important:** Back up your wallet before proceeding.\n\nCode Examples\nRequirements\nAll code examples must:\n\nWork - Actually run without errors\nBe complete - Include all necessary imports/setup\nBe realistic - Show real-world usage\nBe tested - Verify before submitting\n\nGood Example Structure\nHere's how to query deployments:\n```typescriptimport { createChainNodeSDK } from \"@akashnetwork/chain-sdk\"\nasync function queryDeployments(owner: string) { const sdk = createChainNodeSDK({ rpcEndpoint: \"https://rpc.akashnet.net:443\" })\n const deployments = await sdk.query.deployment.deployments({ filters: { owner } })\n return deployments}\n// Usageconst myDeployments = await queryDeployments(\"akash1...\")console.log(`Found ${myDeployments.length} deployments`)```\nThis returns all deployments for the specified owner address.\nMulti-Language Examples\nUse tabs for multiple languages:\n```go// Go exampleclient, err := discovery.DiscoverClient(ctx)if err != nil { return err}```\n```typescript// TypeScript exampleconst sdk = createChainNodeSDK({ rpcEndpoint: \"https://rpc.akashnet.net:443\"})```\n\nStructure Guidelines\nPage Frontmatter\n---categories: [\"Developers\", \"Deployment\"]tags: [\"CLI\", \"Installation\", \"Setup\"]weight: 1title: \"Installing the Akash CLI\"linkTitle: \"Installation\"description: \"Install and configure the Akash CLI for deployments\"---\n\ncategories: Breadcrumb path (max 3 levels)\ntags: Search keywords\nweight: Sidebar ordering (lower = higher)\ntitle: Full page title\nlinkTitle: Shorter sidebar title\ndescription: SEO and preview text\n\nPage Structure\n---frontmatter...---\n# Page Title\n**Bold lead paragraph** - Brief overview of what this page covers.\n---\n## First Major Section\nContent...\n### Subsection\nMore specific content...\n---\n## Second Major Section\nContent...\n---\n## Next Steps\n- [Related Page 1](/link1)- [Related Page 2](/link2)\n---\n**Questions?** Join [Discord](https://discord.akash.network)!\nNavigation\nEvery page should:\n\nStart with context - What will they learn?\nEnd with next steps - Where to go from here?\nLink related content - Connect the docs\n\nGood navigation example:\n## Next Steps\n- **[SDL Reference](/docs/developers/deployment/akash-sdl)** - Learn SDL syntax- **[Examples Library](/docs/developers/deployment/akash-sdl/examples-library)** - 290+ deployment examples- **[Best Practices](/docs/developers/deployment/akash-sdl/best-practices)** - Production deployment tips\n\nCommon Documentation Issues\nIssue: Outdated Information\nProblem: Commands or APIs have changed\nSolution:\n\nCheck current source code\nTest all commands\nUpdate version numbers\nAdd “Last Updated” dates if needed\n\nIssue: Missing Prerequisites\nProblem: Users can’t follow the guide\nSolution:\n## Prerequisites\nBefore you begin, ensure you have:- Go 1.25.0 or later installed- An Akash wallet with ACT for deployment (and AKT for gas); e.g. at least 5 ACT + some AKT- Basic command-line knowledge\n**Not set up yet?** See [Development Environment](/docs/developers/contributing/development-environment)\nIssue: Wall of Text\nProblem: Dense paragraphs are hard to read\nSolution:\n\nBreak into smaller paragraphs (3-4 lines max)\nUse headings to chunk content\nAdd lists and code blocks\nInclude visual breaks (horizontal rules)\n\nIssue: No Examples\nProblem: Conceptual explanation without practical application\nSolution:\nAlways include working examples:\n## TheoryDeployments are created from SDL files...\n## ExampleHere's a simple deployment:```yamlversion: \"2.0\"...```\nUse it like this:```bashprovider-services tx deployment create deploy.yaml```\n\nChecklist for Documentation PRs\nBefore submitting:\n\n Tested all commands - Every command works\n Verified code examples - All code runs\n Checked links - No broken links\n Proper formatting - Code blocks have languages\n Clear writing - Active voice, concise\n Logical structure - Good headings and flow\n Next steps included - Users know where to go\n Spell-checked - No typos\n Frontmatter correct - Categories, tags, weight set\n\nResources\nStyle Guides\n\nGoogle Developer Documentation Style Guide - Industry standard\nWrite the Docs - Community resources\nStripe Documentation - Excellence example\n\nTools\n\nGrammarly - Grammar and clarity\nHemingway Editor - Readability\nmarkdownlint - Markdown linting\n\nGetting Help\nBefore writing:\n\nCheck existing docs for similar content\nAsk in Discord #developers if unsure\nReview recent documentation PRs\n\nDuring writing:\n\nAsk for feedback early (draft PRs welcome)\nTest with someone unfamiliar with the topic\nIterate based on feedback\n\nAfter submission:\n\nRespond to review feedback\nBe open to suggestions\nLearn from the review process\n\nRecognition\nDocumentation contributors are valued:\n\nAcknowledged in release notes\nFeatured in blog posts for major contributions\nBuild portfolio with technical writing samples\nHelp thousands of users succeed\n\nThank you for improving Akash documentation!\n\nQuestions? Ask in Discord #developers! \nEdit page on github\n Pull Request Process Getting Started","tokens":2655,"squid":"spider-03","role":"Compute Spider","at":1791345054569,"hash":"fc668a1130aa7227ed5c916126aa13c1106de797"}
{"url":"https://forum.arbitrum.foundation/t/concerns-regarding-possible-misconduct-by-synapse-with-respect-to-the-usage-of-arb-incentives-allocated-through-the-stip/23775/18","domain":"forum.arbitrum.foundation","title":"Concerns Regarding Possible Misconduct by Synapse with Respect to the Usage of ARB Incentives Allocated Through the STIP - Archive / ARDC Research Member - Arbitrum","text":"The Arbitrum Foundation notified the Security Council on the need to perform a potential Emergency action. Following a review of the details and known risks, the Security Council decided to execute the upgrade and it was completed at 11:30 EST on 2nd October 2026.\nThis report provides an overview of the risks that required the Security Council Action:\n\nAdd a permissionless guard for the One-Step Proof of BoLD on Arbitrum One\n\nTemporarily pause activation of new Stylus contracts on Arbitrum One & Nova\n\nKey point: To date, known bugs for Stylus primarily impact chain liveness (e.g., denial of service attacks) and do not put any user funds at risk.\nWhy was this action taken\nLet’s take this opportunity to explain why action was taken on two separate issues concerning BoLD and Stylus.\nInstalling the guard for One-Step Proof of BoLD. Given the rise of AI-assisted attacks, we have implemented a precautionary approach that allows anyone to pause settlement of Arbitrum One on Ethereum if there are at least two conflicting answers that pass at the same level in which only one should be valid and pass. This is to halt a class of publicly verifiable and detectable attacks that exploit a bug in the one-step proof. If halted, Arbitrum One will continue to process as normal except that messages from Arbitrum One to Ethereum, such as withdrawals, that are not yet confirmed will have to wait. This provides time for the Security Council to deploy a fix for the bug and resume the rollup.\nPreventing activation of new Stylus contracts. AI-assisted tooling has led to an increasing number of sophisticated attacks on hand-crafted WASM programs that do not use the standard Stylus compiler toolchain. These programs are specifically designed to cause unexpected behaviors such as degrading the chain’s performance for all other users. To date, no attacks have been discovered that permits theft of user funds.\nNew ArbOS releases have patched several reported bugs and known attacks over the past few months, but out of an abundance of caution, we have decided to temporarily pause new activations of Stylus contracts. This was executed as an emergency action to prevent the deployment of new hand-crafted WASM programs that are not yet patched by the current version of ArbOS on the Arbitrum network.\nThe Arbitrum Foundation has informed the Security Council that they will work with the ArbitrumDAO to discuss next steps on the timeline and manner for enabling activation of new Stylus contracts. The Arbitrum community remains confident in the value of Stylus and want to preserve these use cases while taking preventative measures against Stylus-based attack vectors as AI-assisted attack tooling continues to evolve.\nImpact on builders and users\n\nNo new activations. New Stylus contracts cannot be activated during the pause including new versions of existing applications that require activation.\n\nExisting contracts are not paused. Already-active Stylus contracts continue to execute until expiration. This pause does not deactivate them.\n\nThe ArbOS 61 upgrade renewed all active contracts on Arbitrum One, so no currently active contract expires before August 20, 2027.\n\nRenewal via keepalive stays permissionless and is unaffected by the pause.\n\nReactivating an expired contract, or one that needs to be updated after a Stylus version change, is paused.\n\nUsing/calling any activated Stylus contract stays permissionless for all users and developers.\n\nNo impact on EVM. Solidity (EVM) contract deployment and execution are unaffected by this Security Council action.\n\nSecurity Council Actions\nThere are two actions bundled into a single payload:\n\nOne-Step Proof Guard. The L1UpgradeExecutor gives a new pause contract (PauseExecutor) the ability to pause and nothing else. The new pause contract grants the guard (OspSoundnessGuard) PAUSER_ROLE to use it. Anyone can show the guard two conflicting answers to the same step of an open challenge. If the one-step proof accepts both, the guard has the pause contract put Arbitrum One’s settlement to Ethereum on hold.\n\nStylus deactivation. The Security Council called ArbOwner.setWasmActivationGas(2^64 - 1) to raise the Stylus activation gas requirement on Arbitrum One and Nova. This makes activation prohibitively expensive and effectively disables new activations. This is a configuration change and does not require an ArbOS upgrade.\n\nThe Security Council signed the following transactions to update the configuration:\n\nEthereum: Ethereum Transaction Hash: 0x30732bb7d2... | Etherscan\nArbitrum One:\nArbitrum One Transaction Hash: 0x9eb3a4be3b... | Arbitrum One\nArbitrum Nova:\nArbitrum Nova transaction 0x79e0fed470dff7a22059b108e3f8f42eddd2b580a6771594060c4e7326c5f984 | Blockscout\n\nAn external audit was conducted for the OSP Guard contracts. No audit is required for the Stylus deactivation as it is only updating a single parameter in the ArbOS configuration.\n\n ArchiveARDC Research Member\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 2\n\n read \n\n 12\n min\n\n May 2024\n\n 18 / 18\n\n Jul 2024\n\n Jul 2024\n\n post by BlockworksResearch on May 13, 2024\n\n post by MattOnChain on May 13, 2024\n\n post by axlvaz_SEEDLATAM.eth on May 13, 2024\n\n post by moses on May 13, 2024\n\n post by Socrates on May 15, 2024\n\n post by JoJo on May 15, 2024\n\n post by coinflip on May 15, 2024\n\n post by krst on May 16, 2024\n\n post by BlockworksResearch on May 17, 2024\n\n post by Socrates on May 20, 2024\n\n 15 days later\n\n post by BlockworksResearch on Jun 4, 2024\n\n post by stonecoldpat on Jun 7, 2024\n\n post by aureliusbtc on Jun 11, 2024\n\n post by stonecoldpat on Jun 11, 2024\n\n post by SEEDGov on Jun 12, 2024\n\n post by krst on Jun 19, 2024\n\n krst\n\n The following reflects the views of L2BEAT’s governance team, composed of @krst and @Sinkas, and it’s based on the combined research, fact-checking, and ideation of the two.\nThe below response is made in our capacity as delegates and not in our capacity as the DAO Advocate for the ARDC. As already suggested by @stonecoldpat and @SEEDGov, we agree that the 750,000 ARB that Synapse Labs accrued by operating two relayers during STIP should be returned to the DAO’s treasury.\nWe appreciate Synapse’s addressing of the concerns, responsiveness to delegates’ inquiries, and willingness to return the ARB to the treasury.\nAdditionally, we must use this situation as an opportunity to establish a precedent for resolving similar issues in the future. We understand the nuances of navigating delicate circumstances in the context of a DAO. As such, we believe it’s important to have some guidelines to refer to in case something similar occurs in the future.\n\n post by moses on Jun 24, 2024\n\n moses\n\n Synapse Labs and the external LP returned funds to the Arbitrum DAO last week in the following transactions:\n\n 17 days later\n\n post by Deepali on Jul 12, 2024\n\n Deepali\n\n krst\n\n Code of Conduct and its implementation is a very thin line to walk. I have been luring through the forum for a while now to go through the post and delegate responses. Arbitrum DAO should start conversation on how code of conduct issues will be handled with respect, neutrality and transparently.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Synapse STIP Addendum\n\n STIP Bridge Addendum\n\n 6\n\n 1.2k\n\n May 2024\n\n Synapse Protocol Bi-Weekly STIP Backfund Updates\n\n Biweekly Updates (STIP)\n\n 3\n\n 955\n\n Mar 2024\n\n [Synapse Protocol] [FINAL][STIP - Round 1]\n\n Short Term Incentives Program (STIP) Round 1\n\n proposal\n\n 26\n\n 4.5k\n\n Dec 2023\n\n Double-Down on STIP Successes (STIP-Bridge)\n\n Finalized AIPs\n\n proposal\n\n 96\n\n 9.0k\n\n Aug 2024\n\n [FINAL] Stargate Finance STIP Addendum\n\n STIP Bridge Addendum\n\n 15\n\n 1.1k\n\n May 2024","tokens":1944,"squid":"spider-07","role":"Council Spider","at":1791345057681,"hash":"8913d7300d22b3fac368b46bec682b204d5853ce"}
{"url":"https://akash.network/docs/developers/contributing/pull-request-process/","domain":"akash.network","title":"Pull Request Process | Akash Network - Your Guide to Decentralized Cloud","text":"Pull Request Process Submit high-quality pull requests that get merged quickly.\nThis guide walks you through the entire pull request process, from preparation to merge.\n\nBefore Creating a PR\n1. Discuss Major Changes\nFor significant features or changes:\n\nOpen an issue first - Describe what you want to build\nGet feedback - Ensure it aligns with project goals\nWait for approval - Look for design/approved label\nThen start coding - Build what was agreed upon\n\nWhy? Prevents wasted effort on changes that won’t be merged.\n\n“Please do not raise a proposal after doing the work - this is counter to the spirit of the project.” - Akash Contributing Guidelines\n\n2. Verify Your Changes\nRun all checks locally:\nTerminal window# Go projectsmake testmake lintmake build\n# JavaScript projectsnpm testnpm run lintnpm run build\nEnsure:\n\nAll tests pass\nNo linter errors\nCode builds successfully\nNo new warnings\n\n3. Update Documentation\nIf your changes affect:\n\nUser behavior - Update relevant docs\nAPI - Update API documentation\nConfiguration - Update config docs\nCLI commands - Update CLI reference\n\nCreating the Pull Request\nStep 1: Prepare Your Branch\nTerminal window# Ensure you're on your feature branchgit checkout feature/your-feature\n# Rebase on latest main (if needed)git fetch upstreamgit rebase upstream/main\n# Push to your forkgit push origin feature/your-feature\nStep 2: Open the PR\n\nGo to GitHub - Navigate to your fork\nClick “Compare & pull request”\nSelect base and compare branches:\n\nBase: akash-network/repo → main\nCompare: your-fork/repo → feature/your-feature\n\nStep 3: Fill Out PR Template\nTitle\nUse conventional commit format:\nfeat: add GPU model filtering to bidenginefix: resolve escrow balance calculation errordocs: update CLI installation guidechore: bump Go version to 1.25\nDescription\nProvide a clear, complete description:\n## What\nBrief summary of what this PR does.\n## Why\nExplain the problem this solves or feature this adds.\n## Changes\n- List specific changes made- Include technical details- Mention any breaking changes\n## Testing\nHow did you test this?- [ ] Unit tests added- [ ] Integration tests passed- [ ] Manual testing performed\n## Screenshots (if applicable)\nInclude before/after screenshots for UI changes.\n## Related Issues\nFixes #123Relates to #456\nExample:\n## What\nAdds GPU model filtering to the bidengine, allowing providers to filterbids based on specific GPU models and memory requirements.\n## Why\nProviders were receiving bids for GPU models they don't have, causingbid failures and wasted resources. This change allows providers to onlybid on deployments they can actually fulfill.\n## Changes\n- Add `GPUFilter` struct to bidengine- Implement GPU model matching logic- Add configuration options for GPU filtering- Update provider config schema\n## Testing\n- [x] Unit tests added for GPU filtering logic- [x] Integration tests pass- [x] Manually tested with RTX 3090 and A100 GPUs\n## Related Issues\nFixes #789\nStep 4: Link Issues\nUse keywords to auto-close issues:\n\nFixes #123 - Closes issue when PR merges\nCloses #123 - Same as Fixes\nResolves #123 - Same as Fixes\nRelates to #123 - References without closing\n\nAfter Submitting\nAutomated Checks\nYour PR will trigger:\nGo Projects:\n\nTests (make test)\nLinting (make lint)\nBuild verification\nCoverage report\n\nJavaScript Projects:\n\nTests (npm test)\nLinting (npm run lint)\nType checking\nBuild verification\n\nAll checks must pass before merge.\nCode Review Process\nTimeline\n\nInitial review: 2-7 days typically\nFollow-up reviews: 1-3 days\nMerge: After all feedback addressed\n\nNote: Reviews are done by volunteers. Be patient and follow up politely if needed.\n\nResponding to Feedback\nGood responses:\n- \"Great catch! Fixed in latest commit.\"- \"I considered that approach but chose X because Y. Thoughts?\"- \"Good point. Changed to use interface instead.\"- \"Can you clarify what you mean by...?\"\nAvoid:\n- \"This is fine as-is.\"- No response (ignoring feedback)- \"You're wrong.\"- Defensive or argumentative responses\nMaking Changes\nTerminal window# Make requested changes# ... edit files ...\n# Commit changes (signed-off)git add .git commit -s -m \"fix: address review feedback\"\n# Push to update PRgit push origin feature/your-feature\nTips:\n\nAddress all comments\nMark conversations as resolved when fixed\nAsk for clarification if unclear\nBe open to suggestions\n\nCommon PR Issues\nIssue: Tests Failing\nProblem: CI tests fail\nSolution:\nTerminal window# Run tests locallymake test # or npm test\n# Fix failing tests# ... make changes ...\n# Verify fixmake test\n# Commit and pushgit commit -s -m \"test: fix failing tests\"git push origin feature/your-feature\nIssue: Merge Conflicts\nProblem: Your branch conflicts with main\nSolution:\nTerminal window# Fetch latest maingit fetch upstream\n# Rebase on maingit rebase upstream/main\n# Resolve conflicts# ... edit conflicting files ...\n# Continue rebasegit add .git rebase --continue\n# Force push (rebase rewrites history)git push --force-with-lease origin feature/your-feature\nIssue: Linter Errors\nProblem: Linter finds issues\nSolution:\nTerminal window# Run lintermake lint # or npm run lint\n# Auto-fix what's possiblemake lint-fix # or npm run lint:fix\n# Manually fix remaining issues# ... edit files ...\n# Verifymake lint\n# Commitgit commit -s -m \"style: fix linter errors\"git push origin feature/your-feature\nIssue: Missing Sign-off\nProblem: Commits not signed-off\nSolution:\nTerminal window# Sign off last commitgit commit --amend --signoff\n# Sign off multiple commits (interactive rebase)git rebase -i HEAD~3 # for last 3 commits# In editor, change 'pick' to 'edit' for commits to sign# For each commit:git commit --amend --signoffgit rebase --continue\n# Push (force required after rebase)git push --force-with-lease origin feature/your-feature\nIssue: Too Many Commits\nProblem: PR has many small commits\nSolution:\nTerminal window# Squash commitsgit rebase -i HEAD~5 # for last 5 commits\n# In editor, keep first 'pick', change rest to 'squash'# Save and edit commit message\n# Pushgit push --force-with-lease origin feature/your-feature\n\nPR Requirements Checklist\nBefore Requesting Review\n\n Tests pass - All automated tests green\n Linter passes - No linting errors\n Commits signed - All commits have sign-off\n Clear description - Explains what, why, and how\n Documentation updated - If applicable\n No merge conflicts - Rebased on latest main\n Reviewable size - Not too large (< 500 lines ideal)\n\nDuring Review\n\n Respond to comments - Address all feedback\n Be professional - Stay respectful and collaborative\n Ask questions - If anything is unclear\n Update commits - Fix issues found in review\n Mark resolved - Mark conversations as resolved\n\nBefore Merge\n\n All checks pass - Green checkmarks on all CI\n Review approved - At least one approval\n Feedback addressed - All comments resolved\n Up to date - No conflicts with main\n\nPR Size Guidelines\nIdeal PR Size\n\nSmall: < 200 lines changed\nMedium: 200-500 lines\nLarge: 500+ lines (try to avoid)\n\nBreaking Up Large Changes\nTerminal window# Instead of one large PR:feat: complete provider bidengine rewrite (2000 lines)\n# Create multiple smaller PRs:1. refactor: extract bid validation to separate package2. feat: add GPU filtering to bid validation3. feat: implement new bid pricing algorithm4. feat: add bid priority system5. docs: update bidengine documentation\nBenefits:\n\nEasier to review\nFaster to merge\nEasier to revert if needed\nBetter git history\n\nPR Review Etiquette\nAs a PR Author\nDo:\n\nBe responsive to feedback\nAccept constructive criticism\nLearn from suggestions\nThank reviewers\nBe patient\n\nDon’t:\n\nTake feedback personally\nArgue with reviewers\nRush reviewers\nIgnore comments\nGet defensive\n\nAs a Reviewer\nDo:\n\nBe constructive and kind\nExplain why changes are needed\nSuggest alternatives\nPraise good code\nBe thorough but timely\n\nDon’t:\n\nBe condescending\nNitpick excessively\nRequest perfect code\nBlock without explanation\nGhost the author\n\nAfter Merge\nCelebrate!\nYour contribution is now part of Akash Network!\nNext Steps\n\nDelete your branch:\nTerminal windowgit branch -d feature/your-featuregit push origin --delete feature/your-feature\n\nUpdate your fork:\nTerminal windowgit checkout maingit pull upstream maingit push origin main\n\nFind another issue:\n\nBrowse open issues\nLook for good first issue labels\nHelp review others’ PRs\n\nShare your contribution:\n\nTweet about it\nBlog about your experience\nHelp others contribute\n\nCommon Questions\n”How long until my PR is reviewed?”\nAnswer: Typically 2-7 days for initial review. Maintainers are volunteers with varying availability.\nWhat you can do:\n\nEnsure all CI checks pass\nProvide a clear description\nJoin Discord and mention your PR (politely)\nBe patient\n\n”Can I work on multiple PRs at once?”\nAnswer: Yes! Just keep them in separate branches:\nTerminal windowgit checkout -b feature/gpu-filtering# Work on GPU filtering PR\ngit checkout maingit checkout -b fix/escrow-bug# Work on escrow bug fix PR\n“My PR was closed without merging”\nPossible reasons:\n\nDidn’t follow contributing guidelines\nDuplicate of another PR\nDoesn’t align with project goals\nNo response to review feedback for 30+ days\n\nWhat to do:\n\nRead the closing comment\nAddress the concerns\nReopen if appropriate\nAsk in Discord for guidance\n\n”Do I need approval before starting?”\nFor small changes: No\n\nBug fixes\nDocumentation improvements\nTypo fixes\n\nFor large changes: Yes\n\nNew features\nAPI changes\nArchitecture changes\n\nOpen an issue first and wait for design/approved label.\n\nResources\n\nCode Conventions - Coding standards\nGetting Started - First contribution guide\nGitHub PR Documentation - GitHub’s official guide\n\nReady to submit? Make sure your PR follows this process and get ready to contribute!\nQuestions? Ask in Discord #developers! \nEdit page on github\n Code Conventions Documentation Guide","tokens":2443,"squid":"spider-03","role":"Compute Spider","at":1791345064813,"hash":"f73cd53651a61857dec933e58ff6b8875b8d6106"}
{"url":"https://forum.arbitrum.foundation/t/synapse-stip-addendum/23353/1","domain":"forum.arbitrum.foundation","title":"Synapse STIP Addendum - Archive / STIP Bridge Addendum - Arbitrum","text":"The Arbitrum Foundation notified the Security Council on the need to perform a potential Emergency action. Following a review of the details and known risks, the Security Council decided to execute the upgrade and it was completed at 11:30 EST on 2nd October 2026.\nThis report provides an overview of the risks that required the Security Council Action:\n\nAdd a permissionless guard for the One-Step Proof of BoLD on Arbitrum One\n\nTemporarily pause activation of new Stylus contracts on Arbitrum One & Nova\n\nKey point: To date, known bugs for Stylus primarily impact chain liveness (e.g., denial of service attacks) and do not put any user funds at risk.\nWhy was this action taken\nLet’s take this opportunity to explain why action was taken on two separate issues concerning BoLD and Stylus.\nInstalling the guard for One-Step Proof of BoLD. Given the rise of AI-assisted attacks, we have implemented a precautionary approach that allows anyone to pause settlement of Arbitrum One on Ethereum if there are at least two conflicting answers that pass at the same level in which only one should be valid and pass. This is to halt a class of publicly verifiable and detectable attacks that exploit a bug in the one-step proof. If halted, Arbitrum One will continue to process as normal except that messages from Arbitrum One to Ethereum, such as withdrawals, that are not yet confirmed will have to wait. This provides time for the Security Council to deploy a fix for the bug and resume the rollup.\nPreventing activation of new Stylus contracts. AI-assisted tooling has led to an increasing number of sophisticated attacks on hand-crafted WASM programs that do not use the standard Stylus compiler toolchain. These programs are specifically designed to cause unexpected behaviors such as degrading the chain’s performance for all other users. To date, no attacks have been discovered that permits theft of user funds.\nNew ArbOS releases have patched several reported bugs and known attacks over the past few months, but out of an abundance of caution, we have decided to temporarily pause new activations of Stylus contracts. This was executed as an emergency action to prevent the deployment of new hand-crafted WASM programs that are not yet patched by the current version of ArbOS on the Arbitrum network.\nThe Arbitrum Foundation has informed the Security Council that they will work with the ArbitrumDAO to discuss next steps on the timeline and manner for enabling activation of new Stylus contracts. The Arbitrum community remains confident in the value of Stylus and want to preserve these use cases while taking preventative measures against Stylus-based attack vectors as AI-assisted attack tooling continues to evolve.\nImpact on builders and users\n\nNo new activations. New Stylus contracts cannot be activated during the pause including new versions of existing applications that require activation.\n\nExisting contracts are not paused. Already-active Stylus contracts continue to execute until expiration. This pause does not deactivate them.\n\nThe ArbOS 61 upgrade renewed all active contracts on Arbitrum One, so no currently active contract expires before August 20, 2027.\n\nRenewal via keepalive stays permissionless and is unaffected by the pause.\n\nReactivating an expired contract, or one that needs to be updated after a Stylus version change, is paused.\n\nUsing/calling any activated Stylus contract stays permissionless for all users and developers.\n\nNo impact on EVM. Solidity (EVM) contract deployment and execution are unaffected by this Security Council action.\n\nSecurity Council Actions\nThere are two actions bundled into a single payload:\n\nOne-Step Proof Guard. The L1UpgradeExecutor gives a new pause contract (PauseExecutor) the ability to pause and nothing else. The new pause contract grants the guard (OspSoundnessGuard) PAUSER_ROLE to use it. Anyone can show the guard two conflicting answers to the same step of an open challenge. If the one-step proof accepts both, the guard has the pause contract put Arbitrum One’s settlement to Ethereum on hold.\n\nStylus deactivation. The Security Council called ArbOwner.setWasmActivationGas(2^64 - 1) to raise the Stylus activation gas requirement on Arbitrum One and Nova. This makes activation prohibitively expensive and effectively disables new activations. This is a configuration change and does not require an ArbOS upgrade.\n\nThe Security Council signed the following transactions to update the configuration:\n\nEthereum: Ethereum Transaction Hash: 0x30732bb7d2... | Etherscan\nArbitrum One:\nArbitrum One Transaction Hash: 0x9eb3a4be3b... | Arbitrum One\nArbitrum Nova:\nArbitrum Nova transaction 0x79e0fed470dff7a22059b108e3f8f42eddd2b580a6771594060c4e7326c5f984 | Blockscout\n\nAn external audit was conducted for the OSP Guard contracts. No audit is required for the Stylus deactivation as it is only updating a single parameter in the ArbOS configuration.\n\n Synapse STIP Addendum \n\n ArchiveSTIP Bridge Addendum\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 Apr 2024\n\n 1 / 7\n\n Apr 2024\n\n May 2024\n\n post by moses on Apr 21, 2024\n\n moses\n\n Banner copy1920×1080 83.3 KB\nSynapse Protocol STIP ADDENDUM\nSynapse Protocol was granted 2M DAO in the STIP Backfund proposal to increase bridge volume in the Arbitrum Ecosystem and launch Intent-based, slippage free bridging.\nWe delivered on both, bridging ~$3.8b (10x) during the program, and bootstrapping SynapseRFQ which provides slippage free bridging on up to $5m in under 15 seconds.\n\nCan you provide a link to your previous STIP proposal (round 1 or backfund)?\n\nHow much, in the previous STIP proposal, did you request in ARB?\n\nAmount requested: 2,000,000 ARB\n\nIn which date did you start the incentive program for your users and in which date did it end?\n\nSTIP Back Fund distributions for Synapse started 26th of January 2024, and ended 29th of March 2023\n\nCould you provide the links to the bi-weekly STIP performance reports and Openblocks Dashboard?\n\nBi-Weekly Reports\nOpenblocks Dashboard\n\nCould you provide the KPI(s) that you deem relevant for your protocol, both in absolute terms and relative change, for the first of each month starting from October 2023 until April 2024, including the extremes? If you don’t know what KPI might be relevant for you or how to properly define them, please refer to the following document:\n\nAttached is a Dune Dashboard that looks at bridging during the STIP program\nOutside of KPIs\nBridge Volume\n\nDATE\n01/10/23\n01/11/23\n01/12/23\n01/01/24\n01/02/24\n01/03/24\n\nVolume ($M)\n95.6M\n113.4M\n233.1M\n210.5M\n914.9M\n2.88B\n\nTVL %\n+18.5%\n+31%\n+56%\n-9%\n+334%\n+215%\n\nMAU\n\nDATE\n01/10/23\n01/11/23\n01/12/23\n01/01/24\n01/02/24\n01/03/24\n\nMAU (K)\n31k\n42k\n76k\n50k\n95k\n112k\n\nMAU %\n-25.6%\n+34%\n+80%\n-33%\n+89%\n+17%\n\n[From the dune dashboard above]\nSTIP also helped to launch and scale RFQ, which brought bridge fees near zero and transactions that complete in < 30 seconds.\n1322×694 29.8 KB\nThe program also helped to incentivize > $3B in total volume.\n1600×359 56.3 KB\n\n[Optional] Any lessons learned from the previous STIP round?\n\nA general lesson we learned was that incentives need to be updated quite frequently, and that incentive design can be carefully crafted to create organic volume and find more sticky users. Specifically, incentivizing certain routes and adjusting the size of those incentives helped to grow RFQ, and find users that converted from other bridging alternatives.\nNew Plans for STIP Bridge\n\nHow much are you requesting for this STIP Bridge proposal?\n950,000 ARB (47.5%) of the original grant amount.\n\nThis is what Synapse thinks is necessary to achieve similar results and scale the intent base RFQ system.\n\nDo you plan to use the incentives in the same way* as highlighted in Section 3 of the STIP proposal?\n\nYes, incentives will be allocated as following:\n62.5% to Bridge fee and gas rebates\n37.5% to Relayer incentives\n37.5% is being allocated to relayers to specifically encourage onboarding of new relayers that will make quotes even more competitive, and broaden the set of assets and chains supported. In the last round, incentives were distributed proportionately to the ($) amount each relayer bridged. This incentive structure rewards relayers with the best pricing, and best routes, and will be used again.\nAlso important to note that incentives are not used for any liquidity mining.\n\n[Only if answered “no” to the previous question] How will the incentive distribution change in term of mechanisms and products?\nN/A\n\nCould you provide the addresses involved in the STIP Bridge initiative (multisig to receive funds, contracts for distribution, and any other relevant contract involved), and highlight if they changed compared to the previous STIP proposal?\nThe address will be:\n\nMultisig to receive the incentives:Address: 0xD31d3A2C...16aD62dFe | Arbitrum One\nContracts that will distribute the incentives: Address: 0x48fa1ebd...15e125ead | Arbitrum One\n\nBoth Contracts remain the same\n\nCould you share any feedback or suggestion on what could be improved in future incentive programs, what were the pain points and what was your general evaluation of the experience?\nWhile the overall program experience was positive, I think a better way to streamline community feedback around incentives would help to create a positive flywheel around effective incentive spend. There was not as much forum activity around weekly updates as there could have been. In general I thought most of the process would’ve worked out quite well. I would have liked for OpenBlocks to be better incentivized so they could carry a heavier load on reporting and centralizing that info.\n\n 3\n\n 2\n\n read \n\n 6\n min\n\n post by Matt_StableLab on Apr 22, 2024\n\n Matt_StableLab\n\n Hello @moses ,\nThank you for your application! Your advisor will be SeedLatam Gov @SEEDGov\nPlease join the LTIPP discord and ping your advisor in the general chat so they can create a new channel and start communicating with you.\n\n post by SEEDGov on Apr 23, 2024\n\n SEEDGov\n\n Hi @moses we are waiting for you in the discord!\n\n 10 days later\n\n post by moses on May 3, 2024\n\n moses\n\n Wanted to add some clarity on some of the items our advisor pointed out.\nData Reporting:\nIn the initial STIP Backfund program, Synapse Labs created a bespoke data stream on Dune to track solely the incentivized routes and RFQ. While we relied on this as the source of truth internally, other data tools did not support this level of granularity at the time. Thus OpenBlocks and the Synapse Explorer only offered a small peak into the efficacy of the program. An example of this is the API exposed only returns volume “from” Arbitrum, when a majority of the incentivized routes were “to” Arbitrum. To solve this Labs is working with OBL to upgrade the data streams so they have sufficient tooling to do their job, and also go a step deeper.\nAnother goal for the program would be to get more granular with data reporting and track where dollars are going/what users are doing once they enter the ecosystem. Research for Synapse on Optimism shows that Synapse drove 25% of all high-value users to the chain. Tracking this activity on chain helps to make the impact from grants like this more obvious, and more data on user behavior, organic activity, and alignment with general Arbitrum ecosystem goals for growth help everyone to make more informed decisions.\nIncentive Structure:\nIn the addendum we specifically outlined what relayer incentives look like. The initial relayer incentives were a success: in the last month, 90% of intra L2 volume has gone through SynapseRFQ. Relayers offer quotes that are more competitive than fee-less CCTP, and most aggregators, and have finality times < 20 seconds. The new incentives should drive more competition and diversity amongst relayers, as well as offer new routes and assets.\nThe majority of rebates are allocated towards fee and gas rebates. In LTIPP there were several concerns with direct fee rebates. In this scenario, fee-rebates look more like liquidity incentives for just-in-time liquidity. A large portion of fees go directly to relayers in return for assets on the desired chain. This is infinitely cheaper than incentivizing the existing Uni v2/v3 pools on synapse that over pay for liquidity and offer worse pricing. This subsidy for liquidity provision also encourages the proliferation of relayers, and competition that drives down price and speeds. Relayers already offer slippage-free, near instant bridging, and this direct subsidy for liquidity provision encourages more relayers to onboard.\n** Synapse DAO employed several measures to prevent sybiling, these methods were not publicized to prevent abuse of these rules.\nSummary of KPIs:\nExpand SynapseRFQ specifically by encouraging relayer onboarding and increasing competition. This includes the nominal amount of relayers in the ecosystem, the routes, chains, and assets supported, and the resulting decrease in quote prices and bridge speeds.\nEncourage new $$ into the Arbitrum ecosystem. With SynapseRFQ, bridging to Arbitrum will be slippage free from any chain. This should also be directed in a way that encourages participation in the larger arbitrum defi ecosystem (ie users should bridge to use partner protocols like GMX to truly onboard onto the chain).\nOne note is that Synapse did not and will not incentivize traditional liquidity pools using the grant. The goal of the initial stip program was to provide slippage free bridging, and this is most efficiently done through SynapseRFQ\n\n 11 days later\n\n post by SEEDGov on May 15, 2024\n\n SEEDGov\n\n Following feedback on the proposal to establish the STIP Bridge, it was agreed to involve the LTIPP Advisors in this process with the mission to “help applicants gain insights into their proposals. This not only guides applicants through the process but also ensures that the DAO will review better proposals.”\nDespite the inclusion of Advisors, this process does not involve the Council, leading us to believe that this addendum places a significant burden on the delegates who must review all the proposals. One of the reasons for the LTIPP was precisely to avoid this excessive burden. Moreover, the optimistic model adopted in this phase could raise concerns about the real control the DAO will have over these proposals, as reviewing six months of data for each applicant is time-consuming.\nFor this reason, we decided to accompany each application we reviewed with a brief report. We ask the delegates not to take this as an in-depth or definitive basis for deciding your vote, but rather as a guide that can potentially raise questions for your own analysis.\nRegarding Synapse, with STIP incentives their objectives were:\n\nRegarding objective 1, we think it was met positively. The trading volume has been very good. What we noticed is that there’s a difference between what is reported in the OBL dashboards, defillama, the synapse explorer, and their own Dune, regarding the volume metrics they report in the addendum:\n755×168 10 KB\nAlso, we are concerned about the significant drop of that volume after incentives have ended:\n756×450 60.7 KB\nWe recommended the applicant to clarify in the addendum the difference between the dashboards and the reasons for these differences. In Discord, they explained that the difference was because the first three dashboards didn’t track the RFQ volume.\nRegarding the support & grow of Arbitrum projects, it is a hard objective to measure. Synapse hasn’t provided specific data regarding the outcome of that objective.\nPoint 3 was not only unmet, but the TVL from Ethereum today accounts for more than 70% of Synapse, while that of Arbitrum is around 25%. For Synapse, as well as for other bridges running incentive programs, the volume coming into Arbitrum and the amount of Tx and unique users should be measured.\nSomething we noticed and was then brought up to the forum by Blockworks, is that they sent 750K ARB to 3 wallets without much explanation of the reason. In Discord they explained to us that The Synapse DAO voted to spend that specific allocation half on bridger rebates and half on relayer incentives, which is why those wallets received ARB. They also gave the same explanation on the forum.\nAlso, they used that ARB to delegate to Socrates0x, a team member of Synapse.\nBoth things were against the STIP rules: Altering the use of the funds and using them to delegate to one of the team members.\nAbout incentivizing relayers, on this opportunity they are including it in the addendum:\n\nConclusions\nThis applicant has had some positive results and others not as much. They have not been thorough in the execution of the incentive distribution and have failed to comply with the STIP rules.\nAdditionally, we believe that the addendum still needs to justify the amount allocated to fee rebates with more data and establish objective, measurable KPIs to make the proposal’s success quantifiable for the DAO.\n\n post by moses on May 15, 2024\n\n moses\n\n Thank you for your review here. To clarify on some of the points raised here:\n1. Data Reporting\nThroughout the program we published Bi-Weekly updates here: Synapse Protocol Bi-Weekly STIP Backfund Updates - #4 by moses. This data can be used as the source of truth, was audited and is being implemented by Openblocks now to share. The reasons for data discrepancies were all outlined here: Synapse STIP Addendum - #4 by moses\n2. Metrics\nSynapse delivered on the first and most important goal of the program, Encouraging new $$ into the Arbitrum ecosystem. (More than $3b in bridge volume). These dollars flowed into partner protocols like GMX and Uniswap through modules like SynapseX and xAsset token bridging. In regards to the last goal of increasing TVL → The development of SynapseRFQ accomplished the first two items in a capital efficient way, such that idle liquidity (TVL) is replaced with just-in-time liquidity providers (relayers). So while TVL on Arbitrum did not increase by an order of magnitude, bridging and volume overall increased more capital efficiently than any liquidity based bridging,\n3. The allocation of 750k ARB was not only allocated in the original proposal under “Slippage-free bridging” (which was accomplished), but also was earned delegated by individual relayers (and since @socrates has requested that they undelegate). I further elaborate on this here: Concerns Regarding Possible Misconduct by Synapse with Respect to the Usage of ARB Incentives Allocated Through the STIP - #4 by moses\n@socrates elaborates on the delegation of the 750k ARB by the relayers\n\n750k ARB was distributed to bridgers as fee rebates, and 750k was distributed to RFQ relayers. I asked those relayers if they’d consider delegating their Arb to me which they did. As mentioned in @moses’s reply, I can see how this could be viewed as some sort of “quid-pro-quo” and have since asked them to undelegate or vote themselves. That said, I don’t think it’s against STIP rules; my understanding is the ARB shouldn’t be used by the DAO for governance, but after it’s distributed to relayers, users, LPs, etc, they can use it for governance.\n\nfuthermore:\n\nIn regards to the use of Arb in governance, a clarification of the rules here would be helpful. The original STIP proposal says, \" Grants are not to be used in DAO governance\". Our understanding of this was that Arb tokens given to the respective STIP DAOs shouldn’t be used in governance but once they’ve been distributed, it could be used. Similar to how LPs & traders that received Arb from GMX’s STIP program could use the Arb in governance.\n\nThe full response to these concerns can be found here: Concerns Regarding Possible Misconduct by Synapse with Respect to the Usage of ARB Incentives Allocated Through the STIP - #5 by Socrates\n\n post by Socrates on May 20, 2024\n\n Socrates\n\n Synapse will be withdrawing from STIP-Bridge. Please consider our application withdrawn. We will be responding further with a detailed post but just posting this now in the interest of time since the challenge period is coming to an end.\n\n Concerns Regarding Possible Misconduct by Synapse with Respect to the Usage of ARB Incentives Allocated Through the STIP\n\n ARDC Research Deliverables\n\n [RFC] Incentives Detox Proposal\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Concerns Regarding Possible Misconduct by Synapse with Respect to the Usage of ARB Incentives Allocated Through the STIP\n\n ARDC Research Member\n\n 17\n\n 3.2k\n\n Jul 2024\n\n Synapse Protocol Bi-Weekly STIP Backfund Updates\n\n Biweekly Updates (STIP)\n\n 3\n\n 955\n\n Mar 2024\n\n [Synapse Protocol] [FINAL][STIP - Round 1]\n\n Short Term Incentives Program (STIP) Round 1\n\n proposal\n\n 26\n\n 4.5k\n\n Dec 2023\n\n Savvy DAO STIP Addendum\n\n STIP Bridge Addendum\n\n 18\n\n 1.2k\n\n May 2024\n\n Stake DAO STIP Addendum\n\n STIP Bridge Addendum\n\n 20\n\n 1.2k\n\n May 2024","tokens":5237,"squid":"spider-07","role":"Council Spider","at":1791345070513,"hash":"836e4e2c6a8435643f69c7a0d8945c6780f322ae"}
{"url":"https://forum.across.to/t/across-acx-community-initial-liquidity-proposal/1129/1","domain":"forum.across.to","title":"Across ($ACX) Community Initial Liquidity Proposal - Proposals / Passed Proposals - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n Across ($ACX) Community Initial Liquidity Proposal \n\n ProposalsPassed Proposals\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Nov 2022\n\n 1 / 50\n\n Nov 2022\n\n Nov 2022\n\n post by EAsports on Nov 15, 2022\n\n EAsports\n\n *ACP1: Across ($ACX) Community Initial Liquidity Proposal\nSummary -\nWith the upcoming token launch, liquidity is an important consideration. I am proposing that Across use Balancer for their liquidity DEX and that Risk Labs provides some initial $ACX incentives from the Across treasury for LPs to help establish deep liquidity that will minimize long term cost.\nBackground:\nOver the past few weeks $ACX liquidity has been a hot topic as we await the token launch. The community has held multiple AMAs on potential liquidity solutions, conversations in discord, questions, and ideas about the best options for liquidity. This proposal summarizes much of the discussion and aims to lay a foundation for $ACX liquidity alongside the upcoming token launch.\nProposed DEX/Platform:\nGiven multiple options reviewed and considering cost efficiency, ease of maintaining deep liquidity, opportunities for additional yield for LPs, and strategic partnership in the ecosystem, I am recommending we align as a community alongside the Across/RL team to use Balancer for the main liquidity pool for ACX with a 50/50 ACX/wstETH pool at token launch. This will provide one pool to focus on establishing deep liquidity, minimize cost & effort to maintain said liquidity long term.\nThis provides a simple approach as a foundation and benefits include:\n\nUsing a trusted platform in Balancer\nKeeping a simple 50/50 pool to minimize complexity or potential IL\nUsing wstETH as the pair provides deep liquidity and also additional yield opportunities other than trading fees for LPs through the Balancer/Aura framework that allow for cost efficient provision of liquidity instead of having to constantly incentivize long term.\nIn addition, aggregators can route swaps from eth to ACX even when the pool is wstETH/ACX. Balancer’s UI uses cowswap for trading and they are very well integrated so from a buyer/seller’s perspective it is no different than having ETH as the pair to ACX\n\nInitial Incentives:\nIt’s important to solidify this pool as the primary venue for trading ACX immediately so when the launch happens we don’t see fragmented liquidity across DEXs. I propose that the protocol treasury allocate some ACX towards direct incentives on the pool (LP’s would earn ACX).\nFor the first two weeks, I am proposing we allocate 60k ACX per week to encourage deep liquidity and establish this as the main pool for ACX trading. The Balancer team confirmed they can directly distribute these rewards to LPs through their gauge framework which means no additional effort for calculations or distribution. I would also recommend as part of this proposal that the Risk Labs team monitor the pool during these two weeks to watch depth of liquidity and LP participation and have the ability to adjust the reward rate to change behavior as they see fit.\nIf you would like to look at detailed calculations for what potential APR and estimated ACX counts, reference this spreadsheet from @hasherror here: ACX Swap Liquidity Scenarios\nIn addition, by using Balancer, we will work through their governance process to enable a gauge proposal to receive veBAL and Aura rewards emissions for LPs. Typically takes a couple weeks. We can monitor liquidity levels throughout the timeframe and adjust as needed, but the first two weeks of $ACX LM rewards are intended to start off strong and enable us to transition to a sustainable scale of APR through bribes that more closely align to the reward locking staking rewards.\nRelative Timeline:\nThere may be more nuance or additional details, but given the various moving pieces, I wanted to show key milestones and timeline relative to the Airdrop and token unlock announcement to set expectations on liquidity and LM incentives.\n1.) Risk Labs to formally announce timing of token launch/unlock\n2.) Some community members adds liquidity to Balancer pool to get it started as $ACX is available to claim\n4.) Pending agreement/approval of this proposal Across treasury send needed ACX to Balancer for 2 weeks of LM rewards\n5.) Liquidity incentives start\n6.) Post gauge governance proposal on Balancer once pool is up to tap into LP incentives through Balancer/Aura. Pending approval, those will begin in 1-2 weeks\nVote\nPlease vote on this proposal as a way to enact this streamlined governance process with a 3 day forum poll. Majority vote should carry the proposal.\nVoting “Yes” supports the proposal to have Across use Balancer for their liquidity DEX & that Risk Labs provides some initial $ACX incentives from the Across treasury for LPs to help establish liquidity\nVoting “No” is not supporting this proposal and don’t agree with this as a solution.\n\n Do you support this proposal?\n\n 97%\n Yes\n\n 3%\n No\n\n 74\n voters\n\n Closed Nov 2022\n\n $ACX Liquidity - Update and Feedback Wanted\n\n read \n\n 6\n min\n\n post by nithin_shylendra on Nov 15, 2022\n\n post by Rasbom on Nov 16, 2022\n\n post by Marhkson_AptosLaunch on Nov 16, 2022\n\n post by DonEchez on Nov 16, 2022\n\n post by FruityCup on Nov 16, 2022\n\n post by poopster on Nov 16, 2022\n\n post by hash_error on Nov 17, 2022\n\n post by Everythingblockchain on Nov 17, 2022\n\n post by Izkillaz on Nov 17, 2022\n\n post by breezy008 on Nov 17, 2022\n\n post by Phuktep on Nov 17, 2022\n\n post by a.mashura on Nov 17, 2022\n\n post by Dagnarus on Nov 17, 2022\n\n post by Britt on Nov 17, 2022\n\n post by Valerii on Nov 17, 2022\n\n post by Vladyslav on Nov 17, 2022\n\n post by chtotodrygoe on Nov 17, 2022\n\n post by NotSatoshi on Nov 17, 2022\n\n post by Ptrck on Nov 17, 2022\n\n Load more posts below","tokens":2932,"squid":"spider-09","role":"Bridge Spider","at":1791345070693,"hash":"0a0ed44f80682bc3efd090caf09dc35ec7eb5f98"}
{"url":"https://forum.across.to/t/across-acx-community-initial-liquidity-proposal/1129/50","domain":"forum.across.to","title":"Across ($ACX) Community Initial Liquidity Proposal - Proposals / Passed Proposals - Across Protocol","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n read \n\n 6\n min\n\n Nov 2022\n\n 50 / 50\n\n Nov 2022\n\n Nov 2022\n\n Load more posts above\n\n post by Bernade on Nov 18, 2022\n\n Bernade\n\n I think 60000 acx\\week not enoth at now. I believe more tokens need to be allocated for price stability.\n\n post by DieWithHonor on Nov 18, 2022\n\n DieWithHonor\n\n Totally agree! Balancer is my favourite defi platform. They were never hacked, their liquidity are safu \n\n post by charis on Nov 18, 2022\n\n charis\n\n so nice is fast and good ^^ but interface is so black, i think white is good how about you?? brighten is so good more\n\n post by AndrewG on Nov 18, 2022\n\n AndrewG\n\n This is a very good idea! Support it by two hands! Good luck and waiting forward for the launch!!!\n\n post by user6 on Nov 18, 2022\n\n user6\n\n Very nice proposal i think!\nHope the project has a great future! WAGMI\nIs there any plan to launch token before next year?\n\n post by MiLLiE on Nov 18, 2022\n\n MiLLiE\n\n Solid proposal. I have two minor suggestions;\n\nAiming for a 1month LM program makes sense as @poopster mentioned, since 2weeks will go by in a flash\n\nI think it might be better to pair it ACX with ETH. Don’t get me wrong wstETH obviously has better intrinsic yield but there are far fewer wstETH holders than there are ETH holders and I would think that the vast majority of wstETH holders have their wstETH already deployed in some way, eg)\n\nIn a vault on Maker\nLending on Aave/Euler\nin a Curve pool\nSo it may be more difficult to compete with attracting those types of LPs to LP on Across versus a raw ETH holder - of which there are many - who may be attracted to these long tail opportunities\n\nEither way I don’t feel too strongly about my position on the points mentioned above and would support the proposal the way it is as well.\n\n post by TheRealTuna_Across on Nov 18, 2022\n\n TheRealTuna_Across\n\n Great proposal @EAsports!\nI agree with the comments on extending the LM program to a longer time frame than 2 weeks.\nAlso curious to hear the reasoning behind pairing it with wstETH, I understand users would get extra staking rewards while LP’ing but it also adds an extra step to setting up an LP and in a way targets a smaller market. At the end of the day whether it’s wstETH or ETH, I support this proposal.\n\n post by holly on Nov 18, 2022\n\n holly\n\n EAsports\n\n I support the proposal to have Across use Balancer for their liquidity DEX & that Risk Labs provides some initial $ACX incentives from the Across treasury for LPs to help establish liquidity\nSo i voted yes . Can’t wait for it to list\n\n post by RoninImperial.eth on Nov 19, 2022\n\n RoninImperial.eth\n\n Missed the vote window, but the proposal sounds good to me and Balancer is a great platform to launch this through \n\n post by eren.eth on Nov 24, 2022\n\n eren.eth\n\n It’s a great proposal, almost like excellent example of proposals @EAsports ! Rather than presenting my own opinion (voting is already closed :D), I would like to make a point. From Across Protocol’s many Medium articles and a quote in Across Docs that says “Designed by the engineers who built UMA, Across was the result of approaching bridging not only as a technical concern but as a financial engineering concern.” we can understand the team seems to support Financial Engineering rather than AMMs (Balancer is an AMM, as everyone knows). But it looks like the DAO has made its side clear!\n\n post by jotatotal on Nov 25, 2022\n\n jotatotal\n\n [quote=“EAsports, post:1, topic:1129”]\nIt’s important to solidify this pool as the primary venue for trading ACX immediately so when the launch happens we don’t see fragmented liquidity across DEXs.\n[/quote] I missed the proposal window but want to insist on something. This is for me the main point of this discussion. Don´t split the liquidity.\n\n post by user9 on Nov 27, 2022\n\n user9\n\n Nice Active proposal\nA very reasonable proposal , it will greatly benefits the whole ecosystem and also induced more trust to the community\n\n post by jyh66 on Nov 27, 2022\n\n jyh66\n\n A reasonable proposal that will help increase trust in the community and the development of the ecology, I support this proposal\n\n post by CyA on Nov 27, 2022\n\n CyA\n\n this is awesome, i support this, i think it will be good for the community and the project \n\n post by Parim_Param on Nov 27, 2022\n\n Parim_Param\n\n Great proposal But it seems to me that 60k tokens does not sufficiently account for the attention to the project in the community. And this attention is actually huge\n\n post by zfm on Nov 27, 2022\n\n zfm\n\n nice!!! This is awesome!!! This will boost up ACX to the moon! With this proposal, this will further cement ACX’s stability and provide firm hold on DEX markets. Balancer is a good platform with established market and support. Definitely worth the wait! Lezgaw ACROSS\n\n post by pnynto on Nov 27, 2022\n\n pnynto\n\n Nice Active proposal\nA very reasonable proposal , it will greatly benefits the whole ecosystem and also induced more trust to the community\n\n post by Cevik11 on Nov 27, 2022\n\n Cevik11\n\n Will those who are in dao get airdrops? I just joined, can adding lp to the pool be a criterion? What can we do to support the community\n\n post by crismin7777 on Nov 27, 2022\n\n crismin7777\n\n It’s so good I absolutely agree. I think the project is going in a good direction. Let’s keep developing like this.\n\n post by Max_Poplavskii on Nov 27, 2022\n\n Max_Poplavskii\n\n Very interesting acitivity, I think it is a Cool and Good NEWS! and i respect your choice\nThank you @EAsports for this proposal.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Across Token Launch Proposal v2\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 47\n\n Nov 2022\n\n $ACX Liquidity - Update and Feedback Wanted\n\n Ideas & Feedback\n\n Ideas & Feedback\n\n 7\n\n Jun 2023\n\n Velodrome Liquidity Program Extension\n\n Active Proposals\n\n Active Proposals\n\n 19\n\n Jan 2024\n\n Across Token Launch Proposal\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 214\n\n May 2022\n\n “Community Owned Liquidity” NFT Project Funding Request\n\n Active Proposals\n\n treasury-funding\n\n Active Proposals\n\n 36\n\n Jun 2023","tokens":1528,"squid":"spider-09","role":"Bridge Spider","at":1791345083093,"hash":"a49aba398e4adcef088bdb7f2d5592199a0cb75c"}
{"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 SingaporeOctober 7Singapore (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)Encode London Hackathon and ConferenceOct 22 – 24London, United Kingdom (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.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.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.ThiagoBrazilIn 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.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.0x3liza.ethArgentina (opens in a new tab)Growing up in Argentina, I experienced how economic instability, inflation, and a lack of trust in institutions can deeply affect daily life. These challenges pushed me to explore alternative systems that don’t rely on centralized authorities or intermediaries. That’s how I found Ethereum, and it’s made a profound difference in how I view the future.\n\nEthereum offered me and my community a new way to think about trust, identity, and value. It’s not just a technology; it’s a tool for empowerment. With this public good, financial inclusion becomes real. People who were previously shut out of traditional systems now have access to decentralized finance, secure transactions, and even new forms of income and expression through NFTs, DAOs, and other innovations.CharlesNigeriaI started as a local group in my city Warri south of Nigeria, two years ago, has metamorphosed into a vibrant community of over 400 people with some already developing smart contracts and getting immersed in Ethereum. One of the most significant differences Ethereum made in my community - the web3 Warri - was bringing together individuals with no background in blockchain and transforming them into smart contracts developers. Ethereum has helped my community - the web3 Warri - overcome some of these challenges 1. Centralization: Members of my community now understand that they have control over how they use the internet and their data 2. Seamless and cross-border payments: Most members of my community work as freelancers and remote workers. And receiving their payments have already been a challenger but with Ethereum, they have been able to receive their payments via stable coins and in almost an instance. 3. They also don't need to provide numerous documents to support their identity in making and receiving payments.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.InhwanSouth KoreaI had a transaction with a friend who was overseas, and I was surprised that sending and receiving money through Ethereum was much faster and easier than I thought. It's much more transparent than the existing banking system, and there are no complicated procedures in the middle.TranslationThomasKenyaEthereum has empowered Kenyan communities by improving financial inclusion, supporting agriculture, fostering education, and enabling cost-effective remittances. big up to ETHOpen-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":2031,"squid":"spider-05","role":"Spec Spider","at":1791345083132,"hash":"be67e3e74878b2e850cc115eb0b07cd66e4d9f69"}
{"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":"spider-05","role":"Spec Spider","at":1791345093341,"hash":"1b21ba7bda3360c0790f936c89615950f3feeab8"}
{"url":"https://forum.across.to/t/acx-liquidity-update-and-feedback-wanted/1639","domain":"forum.across.to","title":"$ACX Liquidity - Update and Feedback Wanted - Ideas & Feedback - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n $ACX Liquidity - Update and Feedback Wanted \n\n Ideas & Feedback\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n read \n\n 4\n min\n\n May 2023\n\n 1 / 8\n\n May 2023\n\n Jun 2023\n\n post by Kevin_UMA on May 19, 2023\n\n Kevin_UMA\n\n ACX liquidity is an ongoing topic in the community. I want to use this forum to share some observations and gather feedback and views to help guide any potential actions we should consider taking.\nOpen questions to discuss:\n\nShould we increase or decrease incentives on platforms such Aura?\nACX liquidity is primarily on Balancer, should we consider other decentralized exchanges such as Uniswap v3 with the help of projects like Arrakis?\nShould we consider other ways to increase liquidity in ACX? For example, there was a discussion about community owned liquidity (COL).\nShould we explore a way to create protocol owned liquidity (POL) or other ways to accrue value to the Across Dao treasury?\n\nCurrent ACX Liquidity\nWe have received mixed feedback about ACX liquidity. Some people believe liquidity is appropriate for the market capitalization of the token whereas others believe the liquidity is poor.\nAt the moment, ACX liquidity is primarily on a Balancer pool that is incentivized through bribes on Aura. The initial proposal that describes the construction of this is here. Risk Labs is consistently incentivizing this pool and the process should migrate to the DAO to manage in the near future - read about this here.\nFor token holders who believe they experience poor liquidity we notice two consistent themes:\n\nThe user does not see the Balancer pool where the bulk of ACX liquidity is located and incentivized. Uniswap has very little liquidity and platforms such as DEX screener do not show the Balancer pool. The use of aggregators such as CoW Swap solves this problem. Should we do a better job of telling users where to trade ACX? Or is there something else we can do?\nWe have noticed that the “slippage” value shown on aggregators is incorrect. For example, when we compare the ACX / USD price from execution to the price on Coingecko or Coin Marketcap it ties out; however, depending on the day a large positive or negative slippage number can appear. We are uncertain as to why this is and could spend some time on understanding this.\n\nWe try to measure liquidity in a different way by measuring the depth of the market relative to comparable tokens. We used CoW Swap to figure out the price for transacting 0.1% to 1% market cap of $ACX, $HOP and $STG. From the table below you can see that we have much better liquidity than $HOP, but liquidity is not as great when compared to $STG. Stargate has a much larger market cap and spends a lot on incentives to create deeper liquidity pools. In addition, they are also listed on centralized exchanges.\n\nACX on a L2\nThere have been some discussion about this and there seems to be a general debate that involves the following:\n\nIs there actually any use at the moment for having $ACX on a L2? What would the purpose be?\nAre there benefits to having $ACX liquidity on a L2 such as supporting the L2 ecosystem and building stronger relationships with those projects.\nDoes this fragment our liquidity given we would have $ACX on mainnet and a L2?\n\nVelodrome provides some information and arguments for pursuing L2 liquidity. The team lays out a plan and how the economics of it would work in this discussion.\nPlease share any feedback you have on ACX liquidity and also take a few seconds to respond to the questions below.\nThanks\n\n Should we take action to improve $ACX liquidity on main net?\n\n 7\n voters\n\n Should we support $ACX liquidity on a L2?\n\n 9\n voters\n\n Build liquidity for $ACX on Velodrome\n\n 3\n\n read \n\n 4\n min\n\n post by eth-wei-trader on May 20, 2023\n\n eth-wei-trader\n\n The current Balancer pool pairs ACX with wstETH, but we should only incentivize ACX pairs that are also providing liquidity to the Across bridge. We can use a Balancer Boosted Pool with Across LP tokens to incentivize both ACX trading liquidity and underlying bridge liquidity at the same time.\n\n post by Saludiego201 on May 20, 2023\n\n Saludiego201\n\n Incentivizing the opening on L2 makes more sense on mainnet, think about the smaller size holders, it is not the same to try to open a position on Arbitrum than on Mainnet.\nAlso thinking about Optimism, Velodrome and their bribes, plus leveraging it with BeefyFinance or PickleFinance strategies and looking for the opportunity to create DCA in MeanFinance could help incentivize this in L2.\n\n post by Clayton_UMA on May 21, 2023\n\n Clayton_UMA\n\nI think Balancer’s UI/UX is rough, and combined with L1 gas fees, makes trading ACX a pain in the butt.\nI think Risk Labs over-indexes on product-only focus. A healthy, easy to trade token is good for the product and awareness.\n\nTherefore, I think reasonable liquidity on an L2 is a great idea. This is combined w/ the fact that we can get support from Velodrome for rewards (Right?) – I’m a big fan of velodrome. I also think doing something with Optimism is a good call right now–The pendulum of attention will inevitably swing from Arbitrum to someone else, and I think if Across invests in our relationship with Optimism now, it’ll pay off when things pick up over there.\n\n post by Kevin_UMA on May 22, 2023\n\n Kevin_UMA\n\n eth-wei-trader\n\n This sounds interesting, but does that mean there needs to be an Across LP / ETH pool to make this work? Just not sure how liquidity will be like if a pool is created this way.\nAlso, the Across LP would not earn Across reward locking emissions.\nAnd another question for this and in general - should we just move away from bribing all together. the emissions / ACX bribed started around $2.50 and it’s creeped down to $1, so economics aren’t as great.\nWe could even consider incentivizing using our own reward locking system\n\n post by Bananachain on May 22, 2023\n\n Bananachain\n\n What would the cons be, regulation apart, of listing on a centralised exchange, as well?\nHaving ACX on an L2 would increase incentive to hold, utilise and trade ACX, given its easier to generate a profit by traders and coming up with more use cases, DeFi or other, such as gaming.\n\n post by Kevin_UMA on May 23, 2023\n\n Kevin_UMA\n\n cons of L2 liquidity are the cost of promoting and maintaining it. the DAO treasury would need to pay ACX to incentivize it - LPs naturally won’t be providing that liquidity.\nAs for centralized liquidity - it’s been brought up to exchanges or they have inquired, but there’s no set time line as to when that happens. so not fully in our control.\n\n 11 days later\n\n post by Dakotah on Jun 3, 2023\n\n Dakotah\n\n Hey yall this just came across my desk a few days ago. I have been thinking and I wanna make sure you are aware of what we do at Bunni.pro. We should be able to help in a few different ways.\nWe are a liquidity engine built on top of Uni v3. In its own rights, Uni v3 is very powerful, but the reward is limited for LPing without incentives. We solved this with our liquidity engine. Think Curve but for Uni.\nBefore incentives we start saving LPs right away by allowing LPs on Bunni to mint ERC20s instead of the gas inefficient Uni v3 NFTs. Providing valuing from day 1! Next we offer LPs on bunni incentives on top of Uni trading fees! Incentives are paid in oLIT which is an option to buy LIT at a discount. Rn its a 50% discount this can be changed by the community. The other 50% comes from WETH. These are transferable & do not expire. We also have an interesting feature where holders of our gov token get up to 10x boost on those incentives. This is Curve math but with a 10x boost instead of a 2.5x. (TLDR is if your % of the total supply of veLIT matches your % of the LP pool you get max boost). This is subject to change and certain folks would like to see it lowered to increase the non boosted APY (onboarding more TVL). Holders of our gov token direct these incentives via our gauges.\nProtocols can bribe voters on Hiddenhand & Warden this is extremely efficient for the protocols participating! As of last epoch it was $1 in bribes = $3 in emissions!\nveLIT holders also get 50% rev share including oLIT redemptions which has been pretty profitable\nWe have a Dune page that you can also see a lot related to us competing with Curve even with much less TVL due to Uni v3 concentrated liquidity.\nSo imo we help to get you on Uni which should help solve common complaint 1 and 2 while also creating deeper liquidity at a more efficient price!\nWe are also in the process of moving to L2 so work done with us on L1 could also lead to an improved situation on L2. We could grow together for a long time…\nI am here if yall wanna do a community call or just talk shop! Hmu!\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Build liquidity for $ACX on Velodrome\n\n Active Proposals\n\n treasury-funding\n\n Active Proposals\n\n 8\n\n Jul 2023\n\n Across ($ACX) Community Initial Liquidity Proposal\n\n Passed Proposals\n\n Passed Proposals\n\n 49\n\n Nov 2022\n\n Tokenomics & Liquidity Incentives: Pair ACX w Across LP Tokens\n\n Ideas & Feedback\n\n liquidity\n\n Ideas & Feedback\n\n 2\n\n Aug 2023\n\n Discontinue ACX Bribes on Aura and Replace with Reward Locking in the Near Term\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 5\n\n Jul 2023\n\n Reduce or Reallocate Across ACX LP emissions\n\n Ideas & Feedback\n\n liquidity\n\n Ideas & Feedback\n\n 2\n\n Sep 2023","tokens":3841,"squid":"spider-09","role":"Bridge Spider","at":1791345093472,"hash":"a8a7d84803c485988b01e7354c502fd1fe7469cc"}
{"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.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.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.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.snekmateState-of-the-art, highly opinionated, hyper-optimised, and secureVyper smart contract building blocks.SolarBlazingly fast, modular Solidity compiler written in Rust by Paradigm. Designed as a contributor-friendly compiler stack for faster builds and better diagnostics.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.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.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.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.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.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.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.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.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.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.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.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.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.ZabiZabi is a Zig library for interacting with Ethereum and other EVM chains, providing JSON-RPC clients, ABI utilities, signers, and wallet primitives.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.Cryptography & key management(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.Kernel (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.ethereum-multicallAbility to call many ethereum constant function calls in 1 JSONRPC requestSafe 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 infrastructure with global request ro","tokens":15000,"squid":"spider-05","role":"Spec Spider","at":1791345113391,"hash":"760764a342623786fe958b1a7524cf8be7cbbf57"}
{"url":"https://forum.across.to/t/community-owned-liquidity-nft-project-funding-request/1555/23","domain":"forum.across.to","title":"“Community Owned Liquidity” NFT Project Funding Request - Proposals / Active Proposals - Across Protocol","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 12\n\n 3\n\n 3\n\n 3\n\n 2\n\n read \n\n 15\n min\n\n Mar 2023\n\n 23 / 37\n\n Mar 2023\n\n Jun 2023\n\n Load more posts above\n\n post by TheRealTuna_Across on Mar 9, 2023\n\n TheRealTuna_Across\n\n Justin_J\n\n Plan is still currently to have everything happen on L1 but I’m not totally opposed to the idea of NFT being elsewhere if that’s what the majority wanted. Since we are a bridge I don’t think we should fear bridging funds, that being said we want to make sure the NFT is accessible to everyone and it is safe to say that everyone uses Ethereum.\n\n post by mhairi on Mar 9, 2023\n\n mhairi\n\n I’m going to abstain on this proposal for now. I love the idea of build ACX liquidity using NFTs, but I think it needs a few tweaks as others have suggested.\nIn particular\n\nI’d like to see something that showcased L2s, given that Across is a bridge. Creating the NFTs on an L2 would offer Across a good opportunity to develop its relationship with one (or more?) of the chains that we bridge to.\n\nAllowing redemption for underlying liquidity is important for sustainability and keeping the NFT tokens value anchored.\n\nThis could be combined with some kind of “vesting” - such as it cant be redeemed until x time after minting/transfer in order to protect against people either immediately liquidating to take advantage of the ACX treasury “bonus”, or a sweep at a time of price volatility, where people can purchase the NFT at less than “face value” then immediately liquidate; drying up ACX liquidity when it is most needed.\n\nI’m a big cheerleader for oSnap. I think this is the way that protocol decisions should be executed, without needing individuals to take on personal risk or responsibility, and ensuring that parameter changes are fully decentralised. Its very easy to set up, like Across itself, its secured by UMA’s Oracle and built by UMA engineers and this seems a perfect fit.\n\nI understand the concern that someone could buy up 1/2 the NFTs to send a malicious proposal, (although it would be difficult in practice) but if that were to happen oSnap would stop the transaction if it was disputed (regardless of outcome) and there are other potential guardrails that can also be implemented.\n\nLPing to UniV3 tends to result in impermanent loss. I’m not really an expert on dexes but I wonder if we could delegate the liquidity management to bots and manage the bot parameters through oSnap, hmm actually on a further read thats using flashloans, like I said no expert, but UniV3 feels risky.\n\n post by Britt on Mar 9, 2023\n\n Britt\n\n@Kevin_UMA this resonates a lot with me. Maybe you could help suggest a couple of options that you might consider more ideal?\nI think that the redemption details are going to be the most technically difficult part to sort out in this implementation. So I’d like to call on anyone reading this to make recommendations of protocols who might do something like this that we could work with.\n\n post by caesarsherrod.eth on Mar 9, 2023\n\n caesarsherrod.eth\n\n I think that there is another point to be made. This Community Owned Liquidity NFT is not necessarily for the community but specifically for the liquidity provider. I think it should be called an Across Liquidity Provider NFT.\nI say this because the Blueberry project on GMX is a Community Project and each NFT is a PFP and has different levels of swag. Furthermore, this project is limited to 2,000 NFTs rather than the whopping 10,000 of the other project.\nIf this is just a way to raise 500k I understand that, but I think there is merit to the production of a second Across NFT project with PFP’s on a Layer Two, priced in ETH or ACX. That would be a community project, but this proposes an NFT to pass value to LPs. I am a proponent of both of these projects.\nI think it is important for a bridge protocol NFT project to encourage the use of a bridge protocol, and minting on mainnet only offers utility to LPs, while minting on layer 2 may favor community.\n\n post by Deadcoin on Mar 10, 2023\n\n Deadcoin\n\n Well put together proposal.\nI do agree with Kevin. I just feel there needs to be a more solid detailed process when it comes to fund management. If the snapshot element is just a gauge or temp check why go through the hassle of snapshot. That can be done here .\nA few things that I wanted to comment on, ask about and toss in some thought on :\n\nSecondary sales (royalties) are baked in the contract usually set around 3% - 10% .\nThat fee follows the NFT not the platform .\n\nAre the plans to build a website for promotional purposes and to mint only?\nA marketplace where users can mint their tokens (assuming this is not a drop but a lazy mint) and trade/auction their NFTs might be something to look at.\nThere could be a small platform fee set up in the initial contract as well .\nThe accepted tokens for payment can also be set to almost whatever the DAO wants, which could be used as a strategy.\n\n100 - 150 unique traits for a 2,000 mint could be too many or not enough, how many layers?\na good formula to figure out the layers/traits\nNumber of NFTs = Number of traits ^ Number of layers\nYou dont want to dilute the rarity formula .\nWill a number of rare NFTs be saved for the artist , devs, etc.?\n\nThe way it’s worded “Community Owned Liquidity” It implies a DAO Haus type of ownership where everyone owns a chunk of the entire treasury.\nWith the ability to “rage quit” at any point in time, pulling their share of the treasury out and walking. If everyone redeemed at once, the treasury would 0 out. Or is it more of a community managed treasury, and even if everyone cashed out the treasury would still have enough runway to sustain itself?\n\nIncreasing value by $75.00 is inviting to day one dumpers and opens up opportunities for arbitrage. 30% for every NFT I can mint , and in one day.\nI think the contract should include a claim restriction when created to avoid someone from minting large amounts to only extract as much value as possible.\nIt is possible to create a dNFT , open the NFTs up to trade in X amount of time. Switch from Non-transferable to transferable. But will it be more economically feasible to take your share and burn your NFT or to sell your NFT…have to wait for the market to decide that I suppose\n\n25% of LP rewards raffled off weekly .\nACX is doing $119,672.00 / 24hrs (coinmarketcap)\nThat could reach around $700 , thats a nice incentive to hodl your ACX !\n\nLast but not least.\nAny consideration for keeping a honest, decentralized and transparent whitelist ?\nI know a guy . \n\"Whitelist powered by decentraList \"! \n\nAgain, great proposal, I can appreciate the time you put into this.\n\n post by TheRealTuna_Across on Mar 10, 2023\n\n TheRealTuna_Across\n\n Thanks for your feedback Deadcoin, it is valued and thoughtful as always! Will try to answer your questions as best I can.\n\nThis website is intended to be a place to check whitelist eligibility, mint your NFT, view your NFT, and possibly see raffle results and have a raffle countdown. We will have to see how it all falls into place once we get to work but I hope it can check all these boxes.\n\nGood things to think about in regards to the NFT’s trait’s and layers, we have some flexibility here and could probably increase if needed.\nIn regards to NFT’s being saved for the artists and devs, I do intend to include a purchased NFT to the primary contributors as part of the compensation package. These NFT’s would be paid for from the budget and have no impact to the treasury we will build from the mints (All NFT’s must contribute funds to the liquidity, no freebies that will dilute other members shares).\n\nThe way I see it your NFT represents your share in the treasury and if we bake in a redemption where people can burn their NFT to pull out their share then there will be a time period before redemption opens up. Redemption is still an open discussion so I will save the final details for our final proposal. Initially I intended to have no redemption option and the funds would remained locked until further down the road once exponential growth has been achieved, but after feedback I do think some redemption option should be built up front but with protection of the incentives for at least 1 year.\n\nThe raffle is a fun element that I wanted to include so that we could have some fun while we hold. Really excited about this element being included.\n\nWould love to chat openly about whitelist ideas, we want to attract lots of great new people and OG’s to our new Across sub-community.\n\n $ACX Liquidity - Update and Feedback Wanted\n\n post by TheRealTuna_Across on Mar 10, 2023\n\n TheRealTuna_Across\n\n Some final comments to the community as a whole. We are very happy with the positive response to our proposal and will take into account all of the feedback we’ve received here and come back with our final version soon “TM”.\nMost important details we’ve taken from the feedback:\nGovernance:\nWe need to decide how governance will look. It sounds like osnap is something we can use and I’m excited at the idea of supporting this great new tool that UMA has made possible.\nLiquidity Management\nWe need to draft up a plan for how our liquidity will be managed.\nActive management vs Passive management.\nWe will weigh the pro’s and con’s of having our own liquidity management strategy vs using a service like Arrakis. I am a firm believer that this liquidity should be tied to Uniswap as it is the most trusted and widely used dex. (Dexs - DefiLlama)\nRedemption:\nWe will discuss what redemption can look like. In this proposal Across treasury is putting up $150,000 in incentives and we need to protect those funds and be sure long term sustained liquidity is provided. We also need to be sure that the NFT is appealing enough for the community to raise $500,000 towards liquidity. If we put a 1 year lockup in place I hope we can do so in a way that makes people want to continue to hold this NFT beyond 1 year. It would also be nice to handle this in a way that encourages a trade market for the NFT on NFT marketplaces.\nWe will come up with a plan that tackles these 3 pieces and come back with an improved proposal.\n\n post by Bananachain on Mar 11, 2023\n\n Bananachain\n\n Bananachain\n\n I am wondering what the incentive is for someone to buy such an NFT on a secondary market as long as the release of its value remains uncertain. Will there be a way to track the development of its value for the respective holder?\n\n post by TheRealTuna_Across on Mar 11, 2023\n\n TheRealTuna_Across\n\n I think a good comparison would be trading KPI options based on speculation that goals will be met and the KPI options value will increase. Somebody may decide they need funds now and sell the NFT close to the purchase price which will be someone else’s opportunity to unlock the incentives at the end of the term. I also think that if we do offer some kind of redemption after a certain term, then not everybody will want to burn their NFT for the underlying collateral which will further reduce the incentives cost to our treasury.\n\n post by Bananachain on Mar 12, 2023\n\n Bananachain\n\n As far as I understand, there is currently no such “end of term” maturity/redemption envisaged or specified which would make this open ended (“for years to come”) and the assets potentially unretrievable. The suggestion of burning (but only after a certain periode of “vesting” e.g. on year) is essentially a reaction to this and meant to add a further option, a kind of “locking as emergency exit”, though at the price of the holder not realising the possible full NFT value upon maturity. Am wondering whether that could mean that the remaining NFTs’ returns could even increase in the process.\n\n post by eth-wei-trader on Mar 14, 2023\n\n eth-wei-trader\n\n My initial reaction is that we should spend more time on the financial engineering and not spend ACX on NFT art.\nThe Across protocol has great financial engineering at it’s core and we should embrace that by creating a community-owned liquidity proposal that focuses on mechanism design and doesn’t spend money on art or NFT graphic design. By being a bit stingy with spending we emphasize how much we value ACX as a community.\n\n post by TheRealTuna_Across on Mar 15, 2023\n\n TheRealTuna_Across\n\n Since we have our own team putting this together it will not take time away from the devs building Across. Also, this NFT has a clear utility in that it represents your share in the LP so I don’t think it’s fair to say that we are spending on art. This results in $650,000 in liquidity being raised at a cost of $190,000 (assuming all NFT’s are redeemed for the underlying capital). Deep liquidity of ACX comes at a cost and I believe this method is a big improvement and cheaper option than liquidity mining or protocol owned liquidity.\n\n post by eth-wei-trader on Mar 15, 2023\n\n eth-wei-trader\n\n The cost here of $190,000 is assuming a certain price for ACX which I think is below fair value so to me that’s not the actual cost. This is the point I’m trying to make - we should be stingy when spending ACX unless we think it is overvalued.\n\n post by TheRealTuna_Across on Mar 15, 2023\n\n TheRealTuna_Across\n\n The goal of this proposal is to help solve liquidity of ACX. Protocol owned liquidity would require selling ACX in order to acquire stables or ETH for a liquidity pair and liquidity mining would require giving ACX tokens to liquidity providers who could dump the tokens and also may exit their position once the rewards end.\nGetting ACX liquidity is going to cost regardless and I believe this is the lowest cost option from ACX treasury and guarantees that the principal deposit is locked in for a full year. I agree with you that we should be stingy when spending ACX but if we do not maintain deep liquidity for prospective buyers then we will remain undervalued.\n\n post by eth-wei-trader on Mar 15, 2023\n\n eth-wei-trader\n\n Before continuing on this I just want to say thank you for not taking my feedback personal and I’m glad we can have this discussion about the proposal.\nCouple follow-on questions / comments from me:\n\nIsn’t this essentially selling ACX treasury for ETH? Why is this functionally different than selling ACX for ETH and LPing it?\n\nI think over time as the Across community grows market makers will become more interested and the ability to buy and sell tokens will grow.\n\nIf the community really wants to deeper AMM liquidity, then we should remove reward locking for the ACX pool - which is probably never used to facilitate actual bridging - and use that to facilitate ACX/ETH or ACX/USDC liquidity somehow\n\n post by TheRealTuna_Across on Mar 15, 2023\n\n TheRealTuna_Across\n\nI would say it’s more of the opposite as some of the ETH raised would potentially be used to buy ACX in order to balance the ACX/ETH LP (Pending our liquidity management plan to be outlined on the final proposal). If ACX pumps against ETH then yes the LP is essentially selling ACX for ETH but it is generating fee revenue and deepening liquidity at the same time. Ideally ACX and ETH grow together and the liquidity becomes much deeper in the process.\n\nI agree with this but believe that some actions now can help accelerate growth.\n\n post by haifeng on Mar 21, 2023\n\n haifeng\n\n Lovely idea! Will read it in details in the morning but everything looks spot on while I skimmed through the text.\nYou have my full support.\n\n 2 months later\n\n post by Methodic on May 19, 2023\n\n Methodic\n\n Sounds like a great idea! Will this proposal be progressing? Curious to know what next steps will be.\n\n 24 days later\n\n post by barbarossa_Arrakis on Jun 13, 2023\n\n barbarossa_Arrakis\n\n Appreciate the initiative!\nThough the conversation around this proposal seems to have faded, we @Arrakis are making an alternative proposal for Across community.\n\n post by caesarsherrod.eth on Jun 20, 2023\n\n caesarsherrod.eth\n\n Much needed! I would love to see the ACX NFT come to life soon!!! Cannot wait to see what the proposal looks like! I hope it offers minting on Layer 2 simply for a Community NFT & a Liquidity NFT Main net\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Across ($ACX) Community Initial Liquidity Proposal\n\n Passed Proposals\n\n Passed Proposals\n\n 49\n\n Nov 2022\n\n Across Token Launch Proposal v2\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 47\n\n Nov 2022\n\n Across Token Launch Proposal\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 214\n\n May 2022\n\n Across Treasury Committee Formation Proposal\n\n Proposals\n\n governance-updates\n\n Proposals\n\n 13\n\n Nov 2023\n\n Reduce ACX emissions for ACX LPs, WBTC LPs and wstETH/ACX LPs\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 11\n\n Aug 2024","tokens":4167,"squid":"spider-09","role":"Bridge Spider","at":1791345117234,"hash":"b0c73ea7ad51014da9f46d8a83dfc003021c35ca"}
{"url":"https://ethereum.org/developers/tools/huff/","domain":"ethereum.org","title":"Huff | ⁦ethereum.org⁩","text":"Contract toolingHuffContract frameworksCompiler · Gas optimizationhuff-language/huff-rs(595 ☆) (opens in a new tab)huff-language/huff2(159 ☆) (opens in a new tab)Huff 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.Related resourcesApe 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.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.","tokens":335,"squid":"spider-05","role":"Spec Spider","at":1791345123307,"hash":"8a32d0ad4922eca7c74ea086b611aba3c3955c89"}
{"url":"https://forum.across.to/t/community-owned-liquidity-nft-project-funding-request/1555/22","domain":"forum.across.to","title":"“Community Owned Liquidity” NFT Project Funding Request - Proposals / Active Proposals - Across Protocol","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Mar 2023\n\n 22 / 37\n\n Mar 2023\n\n Jun 2023\n\n Load more posts above\n\n post by Justin_J on Mar 9, 2023\n\n Justin_J\n\n TheRealTuna_Across\n\n If minted on layer 2 wouldn’t that force more liquidity to said l2, I’m not against it but it seems counter productive to have to move liquidity from l2 back to mainet after mint most acx liquidity is on l1\n\n post by TheRealTuna_Across on Mar 9, 2023\n\n TheRealTuna_Across\n\n Plan is still currently to have everything happen on L1 but I’m not totally opposed to the idea of NFT being elsewhere if that’s what the majority wanted. Since we are a bridge I don’t think we should fear bridging funds, that being said we want to make sure the NFT is accessible to everyone and it is safe to say that everyone uses Ethereum.\n\n post by mhairi on Mar 9, 2023\n\n mhairi\n\n I’m going to abstain on this proposal for now. I love the idea of build ACX liquidity using NFTs, but I think it needs a few tweaks as others have suggested.\nIn particular\n\nI’d like to see something that showcased L2s, given that Across is a bridge. Creating the NFTs on an L2 would offer Across a good opportunity to develop its relationship with one (or more?) of the chains that we bridge to.\n\nAllowing redemption for underlying liquidity is important for sustainability and keeping the NFT tokens value anchored.\n\nThis could be combined with some kind of “vesting” - such as it cant be redeemed until x time after minting/transfer in order to protect against people either immediately liquidating to take advantage of the ACX treasury “bonus”, or a sweep at a time of price volatility, where people can purchase the NFT at less than “face value” then immediately liquidate; drying up ACX liquidity when it is most needed.\n\nI’m a big cheerleader for oSnap. I think this is the way that protocol decisions should be executed, without needing individuals to take on personal risk or responsibility, and ensuring that parameter changes are fully decentralised. Its very easy to set up, like Across itself, its secured by UMA’s Oracle and built by UMA engineers and this seems a perfect fit.\n\nI understand the concern that someone could buy up 1/2 the NFTs to send a malicious proposal, (although it would be difficult in practice) but if that were to happen oSnap would stop the transaction if it was disputed (regardless of outcome) and there are other potential guardrails that can also be implemented.\n\nLPing to UniV3 tends to result in impermanent loss. I’m not really an expert on dexes but I wonder if we could delegate the liquidity management to bots and manage the bot parameters through oSnap, hmm actually on a further read thats using flashloans, like I said no expert, but UniV3 feels risky.\n\n post by Britt on Mar 9, 2023\n\n Britt\n\n@Kevin_UMA this resonates a lot with me. Maybe you could help suggest a couple of options that you might consider more ideal?\nI think that the redemption details are going to be the most technically difficult part to sort out in this implementation. So I’d like to call on anyone reading this to make recommendations of protocols who might do something like this that we could work with.\n\n post by caesarsherrod.eth on Mar 9, 2023\n\n caesarsherrod.eth\n\n I think that there is another point to be made. This Community Owned Liquidity NFT is not necessarily for the community but specifically for the liquidity provider. I think it should be called an Across Liquidity Provider NFT.\nI say this because the Blueberry project on GMX is a Community Project and each NFT is a PFP and has different levels of swag. Furthermore, this project is limited to 2,000 NFTs rather than the whopping 10,000 of the other project.\nIf this is just a way to raise 500k I understand that, but I think there is merit to the production of a second Across NFT project with PFP’s on a Layer Two, priced in ETH or ACX. That would be a community project, but this proposes an NFT to pass value to LPs. I am a proponent of both of these projects.\nI think it is important for a bridge protocol NFT project to encourage the use of a bridge protocol, and minting on mainnet only offers utility to LPs, while minting on layer 2 may favor community.\n\n post by Deadcoin on Mar 10, 2023\n\n Deadcoin\n\n Well put together proposal.\nI do agree with Kevin. I just feel there needs to be a more solid detailed process when it comes to fund management. If the snapshot element is just a gauge or temp check why go through the hassle of snapshot. That can be done here .\nA few things that I wanted to comment on, ask about and toss in some thought on :\n\nSecondary sales (royalties) are baked in the contract usually set around 3% - 10% .\nThat fee follows the NFT not the platform .\n\nAre the plans to build a website for promotional purposes and to mint only?\nA marketplace where users can mint their tokens (assuming this is not a drop but a lazy mint) and trade/auction their NFTs might be something to look at.\nThere could be a small platform fee set up in the initial contract as well .\nThe accepted tokens for payment can also be set to almost whatever the DAO wants, which could be used as a strategy.\n\n100 - 150 unique traits for a 2,000 mint could be too many or not enough, how many layers?\na good formula to figure out the layers/traits\nNumber of NFTs = Number of traits ^ Number of layers\nYou dont want to dilute the rarity formula .\nWill a number of rare NFTs be saved for the artist , devs, etc.?\n\nThe way it’s worded “Community Owned Liquidity” It implies a DAO Haus type of ownership where everyone owns a chunk of the entire treasury.\nWith the ability to “rage quit” at any point in time, pulling their share of the treasury out and walking. If everyone redeemed at once, the treasury would 0 out. Or is it more of a community managed treasury, and even if everyone cashed out the treasury would still have enough runway to sustain itself?\n\nIncreasing value by $75.00 is inviting to day one dumpers and opens up opportunities for arbitrage. 30% for every NFT I can mint , and in one day.\nI think the contract should include a claim restriction when created to avoid someone from minting large amounts to only extract as much value as possible.\nIt is possible to create a dNFT , open the NFTs up to trade in X amount of time. Switch from Non-transferable to transferable. But will it be more economically feasible to take your share and burn your NFT or to sell your NFT…have to wait for the market to decide that I suppose\n\n25% of LP rewards raffled off weekly .\nACX is doing $119,672.00 / 24hrs (coinmarketcap)\nThat could reach around $700 , thats a nice incentive to hodl your ACX !\n\nLast but not least.\nAny consideration for keeping a honest, decentralized and transparent whitelist ?\nI know a guy . \n\"Whitelist powered by decentraList \"! \n\nAgain, great proposal, I can appreciate the time you put into this.\n\n post by TheRealTuna_Across on Mar 10, 2023\n\n TheRealTuna_Across\n\n Thanks for your feedback Deadcoin, it is valued and thoughtful as always! Will try to answer your questions as best I can.\n\nThis website is intended to be a place to check whitelist eligibility, mint your NFT, view your NFT, and possibly see raffle results and have a raffle countdown. We will have to see how it all falls into place once we get to work but I hope it can check all these boxes.\n\nGood things to think about in regards to the NFT’s trait’s and layers, we have some flexibility here and could probably increase if needed.\nIn regards to NFT’s being saved for the artists and devs, I do intend to include a purchased NFT to the primary contributors as part of the compensation package. These NFT’s would be paid for from the budget and have no impact to the treasury we will build from the mints (All NFT’s must contribute funds to the liquidity, no freebies that will dilute other members shares).\n\nThe way I see it your NFT represents your share in the treasury and if we bake in a redemption where people can burn their NFT to pull out their share then there will be a time period before redemption opens up. Redemption is still an open discussion so I will save the final details for our final proposal. Initially I intended to have no redemption option and the funds would remained locked until further down the road once exponential growth has been achieved, but after feedback I do think some redemption option should be built up front but with protection of the incentives for at least 1 year.\n\nThe raffle is a fun element that I wanted to include so that we could have some fun while we hold. Really excited about this element being included.\n\nWould love to chat openly about whitelist ideas, we want to attract lots of great new people and OG’s to our new Across sub-community.\n\n $ACX Liquidity - Update and Feedback Wanted\n\n post by TheRealTuna_Across on Mar 10, 2023\n\n TheRealTuna_Across\n\n Some final comments to the community as a whole. We are very happy with the positive response to our proposal and will take into account all of the feedback we’ve received here and come back with our final version soon “TM”.\nMost important details we’ve taken from the feedback:\nGovernance:\nWe need to decide how governance will look. It sounds like osnap is something we can use and I’m excited at the idea of supporting this great new tool that UMA has made possible.\nLiquidity Management\nWe need to draft up a plan for how our liquidity will be managed.\nActive management vs Passive management.\nWe will weigh the pro’s and con’s of having our own liquidity management strategy vs using a service like Arrakis. I am a firm believer that this liquidity should be tied to Uniswap as it is the most trusted and widely used dex. (Dexs - DefiLlama)\nRedemption:\nWe will discuss what redemption can look like. In this proposal Across treasury is putting up $150,000 in incentives and we need to protect those funds and be sure long term sustained liquidity is provided. We also need to be sure that the NFT is appealing enough for the community to raise $500,000 towards liquidity. If we put a 1 year lockup in place I hope we can do so in a way that makes people want to continue to hold this NFT beyond 1 year. It would also be nice to handle this in a way that encourages a trade market for the NFT on NFT marketplaces.\nWe will come up with a plan that tackles these 3 pieces and come back with an improved proposal.\n\n post by Bananachain on Mar 11, 2023\n\n Bananachain\n\n Bananachain\n\n I am wondering what the incentive is for someone to buy such an NFT on a secondary market as long as the release of its value remains uncertain. Will there be a way to track the development of its value for the respective holder?\n\n post by TheRealTuna_Across on Mar 11, 2023\n\n TheRealTuna_Across\n\n I think a good comparison would be trading KPI options based on speculation that goals will be met and the KPI options value will increase. Somebody may decide they need funds now and sell the NFT close to the purchase price which will be someone else’s opportunity to unlock the incentives at the end of the term. I also think that if we do offer some kind of redemption after a certain term, then not everybody will want to burn their NFT for the underlying collateral which will further reduce the incentives cost to our treasury.\n\n post by Bananachain on Mar 12, 2023\n\n Bananachain\n\n As far as I understand, there is currently no such “end of term” maturity/redemption envisaged or specified which would make this open ended (“for years to come”) and the assets potentially unretrievable. The suggestion of burning (but only after a certain periode of “vesting” e.g. on year) is essentially a reaction to this and meant to add a further option, a kind of “locking as emergency exit”, though at the price of the holder not realising the possible full NFT value upon maturity. Am wondering whether that could mean that the remaining NFTs’ returns could even increase in the process.\n\n post by eth-wei-trader on Mar 14, 2023\n\n eth-wei-trader\n\n My initial reaction is that we should spend more time on the financial engineering and not spend ACX on NFT art.\nThe Across protocol has great financial engineering at it’s core and we should embrace that by creating a community-owned liquidity proposal that focuses on mechanism design and doesn’t spend money on art or NFT graphic design. By being a bit stingy with spending we emphasize how much we value ACX as a community.\n\n post by TheRealTuna_Across on Mar 15, 2023\n\n TheRealTuna_Across\n\n Since we have our own team putting this together it will not take time away from the devs building Across. Also, this NFT has a clear utility in that it represents your share in the LP so I don’t think it’s fair to say that we are spending on art. This results in $650,000 in liquidity being raised at a cost of $190,000 (assuming all NFT’s are redeemed for the underlying capital). Deep liquidity of ACX comes at a cost and I believe this method is a big improvement and cheaper option than liquidity mining or protocol owned liquidity.\n\n post by eth-wei-trader on Mar 15, 2023\n\n eth-wei-trader\n\n The cost here of $190,000 is assuming a certain price for ACX which I think is below fair value so to me that’s not the actual cost. This is the point I’m trying to make - we should be stingy when spending ACX unless we think it is overvalued.\n\n post by TheRealTuna_Across on Mar 15, 2023\n\n TheRealTuna_Across\n\n The goal of this proposal is to help solve liquidity of ACX. Protocol owned liquidity would require selling ACX in order to acquire stables or ETH for a liquidity pair and liquidity mining would require giving ACX tokens to liquidity providers who could dump the tokens and also may exit their position once the rewards end.\nGetting ACX liquidity is going to cost regardless and I believe this is the lowest cost option from ACX treasury and guarantees that the principal deposit is locked in for a full year. I agree with you that we should be stingy when spending ACX but if we do not maintain deep liquidity for prospective buyers then we will remain undervalued.\n\n post by eth-wei-trader on Mar 15, 2023\n\n eth-wei-trader\n\n Before continuing on this I just want to say thank you for not taking my feedback personal and I’m glad we can have this discussion about the proposal.\nCouple follow-on questions / comments from me:\n\nIsn’t this essentially selling ACX treasury for ETH? Why is this functionally different than selling ACX for ETH and LPing it?\n\nI think over time as the Across community grows market makers will become more interested and the ability to buy and sell tokens will grow.\n\nIf the community really wants to deeper AMM liquidity, then we should remove reward locking for the ACX pool - which is probably never used to facilitate actual bridging - and use that to facilitate ACX/ETH or ACX/USDC liquidity somehow\n\n post by TheRealTuna_Across on Mar 15, 2023\n\n TheRealTuna_Across\n\nI would say it’s more of the opposite as some of the ETH raised would potentially be used to buy ACX in order to balance the ACX/ETH LP (Pending our liquidity management plan to be outlined on the final proposal). If ACX pumps against ETH then yes the LP is essentially selling ACX for ETH but it is generating fee revenue and deepening liquidity at the same time. Ideally ACX and ETH grow together and the liquidity becomes much deeper in the process.\n\nI agree with this but believe that some actions now can help accelerate growth.\n\n post by haifeng on Mar 21, 2023\n\n haifeng\n\n Lovely idea! Will read it in details in the morning but everything looks spot on while I skimmed through the text.\nYou have my full support.\n\n 2 months later\n\n post by Methodic on May 19, 2023\n\n Methodic\n\n Sounds like a great idea! Will this proposal be progressing? Curious to know what next steps will be.\n\n 24 days later\n\n post by barbarossa_Arrakis on Jun 13, 2023\n\n barbarossa_Arrakis\n\n Appreciate the initiative!\nThough the conversation around this proposal seems to have faded, we @Arrakis are making an alternative proposal for Across community.\n\n Load more posts below","tokens":4013,"squid":"spider-09","role":"Bridge Spider","at":1791345127447,"hash":"a2053a13367c57b7a5e236e450717d25c65e45a1"}
{"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)Ankr StakingAny amountBrowserWalletGUIOpen sourceAuditedBug bountyBattle testedTrustlessPermissionless nodesExecution diversityConsensus diversityLiquidity tokenVisit on (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)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":"spider-05","role":"Spec Spider","at":1791345133415,"hash":"cb8c231e5b41c92d06019cda013890b63d0f38ab"}
{"url":"https://ethresear.ch/c/evm/26","domain":"ethresear.ch","title":"Latest EVM topics - Ethereum Research","text":"Latest topics in EVM\n\n EVM\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 EVM category\n\n 1\n\n 1.6k\n\n Sep 2018\n\n New Opcode Proposal 2: `L / R` Structured Skip Region\n\n 0\n\n 105\n\n Feb 2\n\n New Opcode Proposal 1: `PACK` Structured Data Construction\n\n 0\n\n 102\n\n Feb 2\n\n Gas Fee Schedule update proposal\n\n 2\n\n 374\n\n May 2025\n\n EVM in Motoko for Trustless Execution Environments\n\n 3\n\n 2.2k\n\n Apr 2025\n\n Parallelizing Ethereum: A Novel Approach Using Historical Data and Transactional Data\n\n layer-2\n\n 2\n\n 474\n\n Dec 2024\n\n Building an EVM for Bitcoin\n\n 23\n\n 4.6k\n\n Nov 2024\n\n Introducing Accrual-Based Recurring Payments for Decentralized Platforms\n\n 2\n\n 1.7k\n\n Apr 2024\n\n Onchain computation proofs for EVM\n\n 0\n\n 1.2k\n\n Dec 2023\n\n Introducing Poseidon VM: A zkApp-friendly blockchain virtual machine with EVM Compatibility\n\n layer-2,zkop-rollup\n\n 2\n\n 2.9k\n\n Nov 2023\n\n Better history access by contracts\n\n 16\n\n 4.0k\n\n Aug 2023\n\n An EVM Execution Layer for Bitcoin\n\n 1\n\n 1.6k\n\n Jul 2023\n\n Gas Estimation problem with internal transactions\n\n 1\n\n 1.4k\n\n Jun 2023\n\n Probably outdated, but: EIP-170 24KB max. leading to Expensive On-Chain Data Blobs masqueraded as compiled EVM bytecode\n\n 1\n\n 1.1k\n\n Feb 2023\n\n EIP-3541 locks my ETH in contract forever. What should I do?\n\n 6\n\n 5.3k\n\n Nov 2022\n\n EIP-5875 Opcode for TXNUM\n\n 0\n\n 1.3k\n\n Nov 2022\n\n Parallel txs processing with chunked Merkle Patricia Trie(s)\n\n 2\n\n 2.4k\n\n Oct 2022\n\n Smart contract languages for Ethereum 2.0/Serenity use?\n\n 3\n\n 3.1k\n\n Jun 2022\n\n Access to CALLDATA of non-current call frames and alternative methods of token-use authorization\n\n 4\n\n 3.2k\n\n Jun 2022\n\n `EEICALL`: Opcode to execute bytecode over given EEI\n\n 1\n\n 1.7k\n\n Jul 2021\n\n Cannot distinguish right indexed parameters from contract bytecode\n\n 5\n\n 2.3k\n\n Jun 2021\n\n Tool for Solidity bytecode decompile and dataflow analysis\n\n 1\n\n 2.0k\n\n May 2021\n\n Improving the EVM’s memory model with paginated RAM and FP-relative access\n\n 0\n\n 938\n\n Mar 2021\n\n Is it possible to implement self-recharging wallets in EVM?\n\n 0\n\n 1.1k\n\n Jan 2021\n\n Fast Tx Execution Without State Trie\n\n 2\n\n 2.9k\n\n Oct 2020\n\n IMPERSONATECALL Opcode\n\n 4\n\n 2.3k\n\n Oct 2020\n\n Introducing the Flint Programming Language for ewasm\n\n 0\n\n 1.4k\n\n Sep 2020\n\n Optimizing Trusted Code Base for Verified Precompiles\n\n 0\n\n 1.9k\n\n Apr 2020\n\n Verifiable Precompiled Contracts\n\n 0\n\n 3.0k\n\n Apr 2020\n\n Fixed-point arithmetics for bonding curve contracts\n\n cryptoeconomic-primitives\n\n 0\n\n 1.3k\n\n Jan 2020","tokens":634,"squid":"spider-04","role":"Research Spider","at":1791345139342,"hash":"86f2095b122a9d8fbfbe378b3c92085d7a7b997b"}
{"url":"https://consensysdiligence.github.io/smart-contract-best-practices/development-recommendations/solidity-specific/timestamp-dependence/","domain":"consensysdiligence.github.io","title":"Timestamp Dependence - Ethereum Smart Contract Best Practices","text":"Timestamp Dependence\n\nTip\nFor comprehensive insights into secure development practices, consider visiting the Development Recommendations section of the Smart Contract Security Field Guide. This resource provides in-depth articles to guide you in developing robust and secure smart contracts.\n\nThere are three main considerations when using a timestamp to execute a critical function in a\ncontract, especially when actions involve fund transfer.\nTimestamp Manipulation¶\nBe aware that the timestamp of the block can be manipulated by a miner. Consider this\ncontract:\nuint256 constant private salt = block.timestamp;\n\nfunction random(uint Max) constant private returns (uint256 result){\n //get the best seed for randomness\n uint256 x = salt * 100/Max;\n uint256 y = salt * block.number/(salt % 5) ;\n uint256 seed = block.number/3 + (salt % 300) + Last_Payout + y;\n uint256 h = uint256(block.blockhash(seed));\n\n return uint256((h / x)) % Max + 1; //random number between 1 and Max\n}\n\nWhen the contract uses the timestamp to seed a random number, the miner can actually post a\ntimestamp within 15 seconds of the block being validated, effectively allowing the miner to\nprecompute an option more favorable to their chances in the lottery. Timestamps are not random and\nshould not be used in that context.\nThe 15-second Rule¶\nThe Yellow Paper (Ethereum's reference\nspecification) does not specify a constraint on how much blocks can drift in time, but\nit does specify that each timestamp should be\nbigger than the timestamp of its parent. Popular Ethereum protocol implementations\nGeth\nand\nParity\nboth reject blocks with timestamp more than 15 seconds in future. Therefore, a good rule of thumb\nin evaluating timestamp usage is:\n\nNote\nIf the scale of your time-dependent event can vary by 15 seconds and maintain integrity,\nit is safe to use a block.timestamp.\n\nAvoid using block.number as a timestamp¶\nIt is possible to estimate a time delta using the block.number property and\naverage block time, however this is not future proof as\nblock times may change (such as\nfork reorganisations\nand the difficulty bomb). In a sale spanning days,\nthe 15-second rule allows one to achieve a more reliable estimate of time.\nSee SWC-116","tokens":555,"squid":"spider-06","role":"Security Spider","at":1791345149796,"hash":"845f8d075dcc1e3b65602b819a717c29af9f564c"}
{"url":"https://www.metaplex.com/docs/smart-contracts/core/plugins","domain":"metaplex.com","title":"Core Plugins Overview | Metaplex Core","text":"This page explains the Core Plugin system - modular extensions that add behaviors and data storage to Core Assets and Collections. Plugins hook into lifecycle events to enforce rules or store on-chain data. What You'll LearnWhat plugins are and how they workTypes of plugins: Owner Managed, Authority Managed, PermanentHow plugins affect lifecycle events (create, transfer, burn)Plugin priority between Assets and CollectionsSummaryPlugins are on-chain extensions that add functionality to Core Assets or Collections. They can store data (like attributes), enforce rules (like royalties), or delegate permissions (like freeze/transfer authority).Owner Managed: Require owner signature to add (Transfer, Freeze, Burn Delegate)Authority Managed: Can be added by update authority (Royalties, Attributes, Update Delegate)Permanent: Can only be added at creation time (Permanent Transfer/Freeze/Burn Delegate)Out of ScopeCreating custom plugins (only built-in plugins are supported), Token Metadata plugins (different system), and off-chain plugin data storage.Quick StartJump to: Plugin Types · Plugin Table · Lifecycle Events · Adding PluginsChoose a plugin based on your use case (royalties, freezing, attributes, etc.)Add the plugin using addPlugin() or at Asset/Collection creationPlugins automatically hook into lifecycle eventsQuery plugin data via DAS or on-chain fetchLifecyclesDuring a Core Assets lifecycle, multiple events can be triggered such as:CreatingTransferringUpdatingBurningAdd PluginApprove Authority PluginRemove Authority Plugin Lifecycle events impact the Asset in various ways from creating, to transfers between wallets, all the way through to the Assets destruction. Plugins attached an Asset level or a Collection level will run through a validation process during these lifecycle events to either approve, reject, or force approve the event from execution.What are Plugins?A plugin is like an onchain app for your NFT that can either store data or provide additional functionality to the asset.Types of PluginsOwner Managed PluginsOwner managed plugins are plugins that can only be added to an Core Asset if the Asset owner's signature is present in the transaction. Owner Managed Plugins include but are not limited to:Transfer Delegate (market places, games)Freeze Delegate (market places, staking, games)Burn Delegate (games) If an Owner Managed plugin is added to an Asset/Collection without an authority set it will default the authority type to the type of owner. The authority of owner managed plugins is automatically revoked when they are transferred.Authority Managed PluginsAuthority managed plugins are plugins that the authority of the MPL Core Asset or Core Collection can add and update at any time. Authority manages plugins include but are not limited to:RoyaltiesUpdate DelegateAttribute If an Authority Managed plugin is added to an Asset/Collection without an authority argument present then the plugin will default to the authority type of update authority.Permanent PluginsPermanent plugins are plugins that may only be added to a Core Asset at the time of creation. If an Asset already exists then Permanent Plugins cannot be added. Permanent Plugins include but are not limited to:Permanent Transfer DelegatePermanent Freeze DelegatePermanent Burn Delegate If an Permanent Plugin is added to an Asset/Collection without an authority set it will default the authority type to the type of update authority.Collection PluginsCollection Plugins are plugins that are added at the collection level can have a collection-wide effect. This is particularly useful for royalties because you can assign the royalties plugin to the Collection Asset and all Assets in that collection will now reference that plugin. Collections only have access to Permanent Plugins and Authority Managed Plugins.Plugin PriorityIf an MPL Core Asset and MPL Core Collection Asset both share the same plugin type then the Asset level plugin and its data will take precedence over the Collection level plugin. This can be used in creative ways like setting royalties at different levels for a collection of assets.Collection Asset has a Royalties Plugin assigned at 2%A Super Rare MPL Core Asset within the collection has a Royalty Plugin assigned at 5% In the above case, regular MPL Core Asset sales from the collection will retain a 2% royalty while the Super Rare MPL Core Asset will retain a 5% royalty at sale because it has it's own Royalties Plugin that takes precedence over the Collection Asset Royalties Plugin.Plugin TablePluginOwner ManagedAuthority ManagedPermanentTransfer Delegate✅Freeze Delegate✅Burn Delegate✅Royalties✅Update Delegate✅Attribute✅Permanent Transfer Delegate✅Permanent Freeze Delegate✅Permanent Burn Delegate✅Plugins and Lifecycle EventsPlugins in MPL Core have the ability to affect the outcome of certain lifecycle actions such as Create, Transfer, Burn, and Update. Each plugin has the ability to to reject, approve, or force approve an action to a desired outcome. During lifecycle events the action will work its way down a list of predefined plugins checking and validating against them. If the plugins conditions are validated the lifecycle passes and continues its action. If a plugin validation fails then the lifecycle will be halted and rejected. The rules for plugin validation are as follows in this hierarchy of conditions;If there is force approve, always approveElse if there is any reject, rejectElse if there is any approve, approveElse reject The force approve validation is only available on 1st party plugins and on Permanent Delegate plugins.Force ApproveForce approve is the first check made when checking a plugins validations. The plugins which will force approve validations currently are:Permanent TransferPernament BurnPermanent Freeze These plugins will take precedence with their actions over their non permanent counterparts and other plugins.ExampleIf you have an Asset frozen at Asset level with a Freeze Plugin while simultaneously have a Permanent Burn plugin on the Asset, even if the Asset is frozen the burn procedure called via the Pernament Burn plugin with still execute due to the forceApprove nature of permanent plugins.CreatePluginActionConditionsRoyaltiesCan RejectRulesetUpdateUpdate currently has no plugin conditions or validations.TransferPluginActionConditionsRoyaltiesCan RejectRulesetFreeze DelegateCan RejectisFrozenTransfer DelegateCan ApproveisAuthorityPermanent Freeze DelegateCan RejectisFrozenPermanent Transfer DelegateCan ApproveisAuthorityBurnPluginActionConditionsFreeze DelegateCan RejectisFrozenBurn DelegateCan RejectisAuthorityPermanent Freeze DelegateCan RejectisFrozenPermanent Burn DelegateCan ApproveisAuthorityAdd PluginPluginActionConditionsRoyaltiesCan RejectRulesetUpdate DelegateCan ApproveisAuthorityRemove PluginPluginActionConditionsRoyaltiesCan RejectRulesetUpdate DelegateCan ApproveisAuthorityApprove Plugin AuthorityApprove currently has no plugin conditions or validations.Revoke Authority PluginRevoke currently has no plugin conditions or validations.Common Use CasesUse CaseRecommended PluginEnforce creator royaltiesRoyaltiesEscrowless stakingFreeze DelegateMarketplace listingsFreeze Delegate + Transfer DelegateOn-chain game statsAttributesAllow third-party burnsBurn DelegatePermanent staking programPermanent Freeze DelegateFAQCan I add plugins after an Asset is created?Yes, except for Permanent plugins. Owner Managed plugins require owner signature; Authority Managed plugins require update authority signature.What happens to plugins when an Asset is transferred?Owner Managed plugins (Transfer, Freeze, Burn Delegate) have their authority automatically revoked on transfer. Authority Managed and Permanent plugins persist.Can an Asset have the same plugin as its Collection?Yes. When both have the same plugin type, the Asset-level plugin takes precedence over the Collection-level plugin.How do I remove a plugin?Use the removePlugin instruction. Only the plugin authority can remove it. See Removing Plugins.Can I create custom plugins?No. Only built-in plugins are supported. The plugin system is not extensible by third parties.Do plugins cost extra SOL?Adding plugins increases account size, which increases rent. Most plugins cost ~0.001 SOL, but data-storage plugins (like AppData or Attributes) can cost more depending on how much data is stored.GlossaryTermDefinitionPluginA modular extension adding behavior or data to an Asset/CollectionOwner ManagedPlugin type requiring owner signature to addAuthority ManagedPlugin type that update authority can addPermanentPlugin type that can only be added at creationLifecycle EventAn action (create, transfer, burn) that plugins can validateForce ApprovePermanent plugin validation that overrides other rejectionsPlugin AuthorityThe account authorized to update or remove a plugin","tokens":2219,"squid":"dotcat","role":"Tooling Spider","at":1791345162595,"hash":"a154de336246c83b537c9b4f8e13583bcbae6260"}
{"url":"https://consensysdiligence.github.io/smart-contract-best-practices/development-recommendations/token-specific/contract-address/","domain":"consensysdiligence.github.io","title":"Contract Address - Ethereum Smart Contract Best Practices","text":"Contract Address\n\nTip\nFor comprehensive insights into secure development practices, consider visiting the Development Recommendations section of the Smart Contract Security Field Guide. This resource provides in-depth articles to guide you in developing robust and secure smart contracts.\n\nConsider also preventing the transfer of tokens to the same address of the smart contract.\nAn example of the potential for loss by leaving this open is the\nEOS token smart contract\nwhere more than 90,000 tokens are stuck at the contract address.\nExample¶\nAn example of implementing both the above recommendations would be to create the following\nmodifier; validating that the \"to\" address is neither 0x0 nor the smart contract's own address:\n modifier validDestination( address to ) {\n require(to != address(0x0));\n require(to != address(this) );\n _;\n }\n\nThe modifier should then be applied to the \"transfer\" and \"transferFrom\" methods:\n function transfer(address _to, uint _value)\n validDestination(_to)\n returns (bool) \n {\n (... your logic ...)\n }\n\n function transferFrom(address _from, address _to, uint _value)\n validDestination(_to)\n returns (bool) \n {\n (... your logic ...)\n }","tokens":293,"squid":"spider-06","role":"Security Spider","at":1791345171497,"hash":"47cc3f8632fcd899b3f1d75873e9e1420b60d140"}
{"url":"https://developers.jup.ag/docs/swap","domain":"developers.jup.ag","title":"Solana Swap API - Jupiter Developers","text":"The Swap API unifies Jupiter’s swap capabilities into a single entry point at https://api.jup.ag/swap/v2. Two paths cover every use case:\n\nMeta-Aggregator: all routing engines compete for the best price. You get a fully assembled transaction, sign it, and Jupiter handles landing.\nRouter: Metis onchain routing only. You get raw swap instructions with full transaction control for custom builds, CPI, and composability.\n\n​Choosing a path\nMeta-AggregatorRouterEndpoints/order + /execute/build + /submitReturnsAssembled transactionRaw swap instructionsRoutersAll (Metis, JupiterZ, Dflow, OKX)Metis onlyBest forMost integrations. Best price, simplest flow.Custom transactions, CPI, composability.Transaction landingManaged via /execute (optimised slippage, priority fees, proprietary landing pipeline)Self-managed via your own RPC, or via /submit with SOL tips for Jupiter’s proprietary landing pipelineSwap feesYes (Jupiter platform fee)NoIntegrator feesReferral fees (referralAccount + referralFee)Platform fee only (platformFeeBps) or DIYGaslessAutomatic gasless, or your own payerUse your own payerTransaction modificationNoFull control\nStart with the Meta-Aggregator. It gives you the best price because all routers compete, including RFQ market makers who often beat onchain routing by 5-20bps on major pairs. Only use the Router if you need to modify the transaction.\n​Routing engines\nJupiter’s routing combines multiple engines and selects the best execution price across all of them, with a self-learning mechanism that automatically sidelines underperforming sources.\nEngineRoleAvailabilityMetisJupiter’s onchain routing engine. Multi-hop, multi-split swaps across Solana DEXes. Also available as an independent public good.Meta-Aggregator + RouterJupiterZRFQ (Request for Quote) system where market makers compete to provide off-chain liquidity. Often beats onchain by 5-20bps on major pairs.Meta-Aggregator onlyDflowThird-party on-chain router.Meta-Aggregator onlyOKXThird-party OKX liquidity.Meta-Aggregator only\nJupiterZ (RFQ) is not available on the Router path. It is available through the Meta-Aggregator, where it competes with the other engines.\nJupiter runs safety and validation mechanisms between integrators and market makers, and market makers have last-look execution rights, which requires controlled transaction handling to ensure validity and prevent spam.\nTransactions routed through JupiterZ cannot be modified after they are returned, so use cases that require CPI, custom instructions, or any transaction modification must use the Router path.\n\n​Endpoints\nAll endpoints require an API key via the x-api-key header. Get one at Portal.\nMeta-Aggregator\nMethodEndpointDescriptionGET/swap/v2/orderGet a quote and assembled transactionPOST/swap/v2/executeExecute a signed /order transaction with managed landing\nRouter\nMethodEndpointDescriptionGET/swap/v2/buildGet a quote and raw swap instructionsPOSTtx.jup.agLand any signed transaction through Jupiter’s infrastructure via Solana sendTransaction with SOL tips\n​Learn More\n\n​Integrate into routing\nIf you want your liquidity routed through Jupiter:\n\nAMM operators: Integrate AMM into Metis to get your markets included in Jupiter’s onchain routing.\nMarket makers: integrate into JupiterZ to provide off-chain liquidity via the RFQ system, over a webhook (V1) or gRPC streams (V2).\nWas this page helpful?","tokens":845,"squid":"spider-02","role":"Liquidity Spider","at":1791345173060,"hash":"74aea2a92647cb5658b48b618799669cee886147"}
{"url":"https://www.metaplex.com/docs/smart-contracts/core/plugins/adding-plugins","domain":"metaplex.com","title":"Adding Plugins to Core Assets | Metaplex Core","text":"This guide shows how to add plugins to Core Assets and Collections. Plugins add functionality like royalties, freezing, attributes, and delegate permissions. What You'll LearnAdd plugins to existing Assets and CollectionsSet default vs custom plugin authoritiesConfigure plugin data during additionUnderstand authority type differencesSummaryAdd plugins to Assets using addPlugin() or to Collections using addCollectionPlugin(). Each plugin has a default authority type, but you can override it.Owner Managed plugins default to Owner authorityAuthority Managed plugins default to UpdateAuthorityPermanent plugins can only be added at creation timeCustom authority can be set with the authority parameterOut of ScopePermanent plugins (must be added at creation), plugin removal (see Removing Plugins), and plugin updates (see Updating Plugins).Quick StartJump to: Add to Asset · Add to Collection · Custom AuthorityChoose a plugin from the Plugins OverviewCall addPlugin() with the Asset address and plugin configSend the transactionPlugin is active after transaction confirms Plugins can be assigned to both the MPL Core Asset and also the MPL Core Collection. MPL Core Asset and MPL Core Collection both share a similar list of available plugins. To find out which plugins can be used on each visit the Plugins Overview area.Adding a Plugin to a Core AssetPlugins support the ability to assign an authority over the plugin. If an initAuthority argument is supplied this will set the authority to the desired plugin authority type. If left unassigned the plugins default authority type will be assigned (next section). Create Plugin Helper The createPlugin() helper gives you a typed method that allows you to assign plugins during the addPlugin() process. For a full list of plugins and their arguments see the plugins overview page.Adding a Plugin with the default authorityIf you add a plugin to an Asset or Collection without specifying the authority of the plugin the authority will be set to that plugins default authority type.Owner Managed Plugins will default to the plugin authority type of Owner.Authority Managed Plugins will default to the plugin authority type of UpdateAuthority.Permanent Plugins will default to the plugin authority type of UpdateAuthorityAdding a Plugin with the default authorityimport { publicKey } from '@metaplex-foundation/umi'\nimport { addPlugin } from '@metaplex-foundation/mpl-core'\nconst assetId = publicKey('11111111111111111111111111111111')\nawait addPlugin(umi, {\n asset: assetId,\n plugin: {\n type: 'Attributes',\n attributeList: [{ key: 'key', value: 'value' }],\n },\n}).sendAndConfirm(umi)\nAdding a Plugin with an assigned authorityThere are a few authority helpers to aid you in setting the authorities of plugins. Addressawait addPlugin(umi, {\n ...\n plugin: {\n ...\n authority: {\n type: 'Address',\n address: publicKey('22222222222222222222222222222222'),\n },\n },\n }).sendAndConfirm(umi);\nThis sets the plugin's authority to a specific address. Ownerawait addPlugin(umi, {\n ...\n plugin: {\n ...\n authority: {\n type: 'Owner'\n },\n },\n }).sendAndConfirm(umi);\nThis sets the plugin's authority to the type of Owner. The current owner of the Asset will have access to this plugin. UpdateAuthorityawait addPlugin(umi, {\n ...\n plugin: {\n ...\n authority: {\n type: \"UpdateAuthority\",\n },\n },\n }).sendAndConfirm(umi);\nThis sets the plugin's authority to the type of UpdateAuthority. The current update authority of the Asset will have access to this plugin. Noneawait addPlugin(umi, {\n ...\n plugin: {\n ...\n authority: {\n type: \"None\",\n },\n },\n }).sendAndConfirm(umi);\nThis sets the plugin's authority to the type of None. The plugin's data if it has any becomes immutable at this point.Adding a Plugin with an assigned authorityuse mpl_core::{\n instructions::AddPluginV1Builder,\n types::{FreezeDelegate, Plugin, PluginAuthority},\n};\nuse solana_client::nonblocking::rpc_client;\nuse solana_sdk::{pubkey::Pubkey, signature::Keypair, signer::Signer, transaction::Transaction};\nuse std::str::FromStr;\npub async fn add_plugin_with_authority() {\n let rpc_client = rpc_client::RpcClient::new(\"https://api.devnet.solana.com\".to_string());\n let authority = Keypair::new();\n let asset = Pubkey::from_str(\"11111111111111111111111111111111\").unwrap();\n let plugin_authority = Pubkey::from_str(\"22222222222222222222222222222222\").unwrap();\n let add_plugin_with_authority_ix = AddPluginV1Builder::new()\n .asset(asset)\n .payer(authority.pubkey())\n .plugin(Plugin::FreezeDelegate(FreezeDelegate { frozen: false }))\n .init_authority(PluginAuthority::Address {\n address: plugin_authority,\n })\n .instruction();\n let signers = vec![&authority];\n let last_blockhash = rpc_client.get_latest_blockhash().await.unwrap();\n let add_plugin_with_authority_tx = Transaction::new_signed_with_payer(\n &[add_plugin_with_authority_ix],\n Some(&authority.pubkey()),\n &signers,\n last_blockhash,\n );\n let res = rpc_client\n .send_and_confirm_transaction(&add_plugin_with_authority_tx)\n .await\n .unwrap();\n println!(\"Signature: {:?}\", res)\n}\nAdding a Plugin to a CollectionAdding a Plugin to a Core Collection is similar to that of adding to a Core Asset. You can add plugins during creation and also using the addCollectionV1 instruction. Collections only have access to Authority Plugins and Permanent Plugins.Adding a Collection Plugin with the default authorityAdding a Collection Plugin with the default authorityimport { publicKey } from '@metaplex-foundation/umi'\nimport { addCollectionPlugin, ruleSet } from '@metaplex-foundation/mpl-core'\nconst collection = publicKey('11111111111111111111111111111111')\nconst creator = publicKey('22222222222222222222222222222222')\nawait addCollectionPlugin(umi, {\n collection: collection,\n plugin: {\n type: 'Royalties',\n data: {\n basisPoints: 5000,\n creators: [\n {\n address: creator,\n percentage: 100,\n },\n ],\n ruleSet: ruleSet('None'),\n },\n },\n}).sendAndConfirm(umi)\nAdding a Collection Plugin with an assigned authorityBurning an Assetsimport { publicKey } from '@metaplex-foundation/umi'\nimport {\n addCollectionPlugin,\n ruleSet,\n} from '@metaplex-foundation/mpl-core'\nconst collection = publicKey('11111111111111111111111111111111')\nconst delegate = publicKey('22222222222222222222222222222222')\nawait addCollectionPlugin(umi, {\n collection: collection.publicKey,\n plugin: {\n type: 'Attributes',\n attributeList: [{ key: 'key', value: 'value' }],\n authority: {\n type: 'Address',\n address: delegate,\n },\n },\n}).sendAndConfirm(umi)\nCommon ErrorsAuthority mismatchYou don't have permission to add this plugin. Owner Managed plugins require owner signature; Authority Managed plugins require update authority.Plugin already existsThe Asset/Collection already has this plugin type. Use updatePlugin to modify it instead.Cannot add permanent pluginPermanent plugins can only be added at creation time. They cannot be added to existing Assets/Collections.NotesOwner Managed plugins require owner signature to addAuthority Managed plugins require update authority signaturePermanent plugins can only be added at creation timeAdding plugins increases account size and rentQuick ReferenceDefault Authority TypesPlugin TypeDefault AuthorityOwner ManagedOwnerAuthority ManagedUpdateAuthorityPermanentUpdateAuthorityAuthority OptionsAuthority TypeDescriptionOwnerCurrent Asset ownerUpdateAuthorityCurrent update authorityAddressSpecific public keyNoneImmutable (no one can update)FAQCan I add multiple plugins in one transaction?Yes, when creating an Asset. For existing Assets, each addPlugin call is a separate instruction. Multiple instructions can be combined into one transaction.What happens if I set authority to None?The plugin becomes immutable. No one can update or remove it.Can I add Owner Managed plugins as the update authority?No. Owner Managed plugins always require the owner's signature to add, regardless of who signs.Why can't I add a Permanent plugin?Permanent plugins can only be added during Asset/Collection creation. They cannot be added to existing accounts.Related OperationsRemoving Plugins - Delete plugins from Assets/CollectionsDelegating Plugins - Change plugin authoritiesUpdating Plugins - Modify plugin dataPlugins Overview - Full list of available pluginsGlossaryTermDefinitionOwner ManagedPlugin requiring owner signature to addAuthority ManagedPlugin that update authority can addPermanentPlugin only addable at creation timeinitAuthorityParameter to set custom plugin authority","tokens":2111,"squid":"dotcat","role":"Tooling Spider","at":1791345195691,"hash":"83a38920ed6c2bfc7a4dc6f4d506fa8e019fc30e"}
{"url":"https://developers.jup.ag/docs/swap/build","domain":"developers.jup.ag","title":"Build - Jupiter Developers","text":"The Router path uses the /build endpoint to return raw swap instructions instead of an assembled transaction. Routing is handled by Metis, Jupiter’s onchain routing engine, which finds the best path across Solana DEXes.\nYou build the transaction yourself, giving you full control to add custom instructions, CPI, or modify any part of the transaction. Once built and signed, submit via your own RPC or use /submit to land through Jupiter’s transaction infrastructure with SOL tips.\n​Quick start\n​Prerequisites\nImports, types, and helpersimport {\n AccountRole,\n Address,\n address,\n AddressesByLookupTableAddress,\n appendTransactionMessageInstructions,\n Base64EncodedBytes,\n Blockhash,\n compileTransaction,\n compressTransactionMessageUsingAddressLookupTables,\n createKeyPairSignerFromBytes,\n createSolanaRpc,\n createTransactionMessage,\n getBase58Decoder,\n getBase58Encoder,\n getBase64Codec,\n getBase64EncodedWireTransaction,\n AccountMeta,\n Instruction,\n pipe,\n setTransactionMessageFeePayer,\n setTransactionMessageLifetimeUsingBlockhash,\n signTransaction,\n} from \"@solana/kit\";\nimport { getTransferSolInstruction } from \"@solana-program/system\"; // For adding custom instructions\n\n// ── Config ──────────────────────────────────────────────────────────────────\nconst COMPUTE_BUDGET_PROGRAM: Address = address(\n \"ComputeBudget111111111111111111111111111111\",\n);\nconst COMPUTE_UNIT_LIMIT_MAX = 1_400_000;\n\n// ── Instruction types ───────────────────────────────────────────────────────\n\ntype Account = {\n pubkey: Address;\n isSigner: boolean;\n isWritable: boolean;\n};\n\ntype ApiInstruction = {\n programId: Address;\n accounts: Account[];\n data: Base64EncodedBytes;\n};\n\nfunction createInstruction(ix: ApiInstruction): Instruction {\n return {\n programAddress: ix.programId,\n accounts: ix.accounts.map((acc) => ({\n address: acc.pubkey,\n role: acc.isSigner && acc.isWritable\n ? AccountRole.WRITABLE_SIGNER\n : acc.isSigner\n ? AccountRole.READONLY_SIGNER\n : acc.isWritable\n ? AccountRole.WRITABLE\n : AccountRole.READONLY,\n })),\n data: Uint8Array.from(getBase64Codec().encode(ix.data)),\n };\n}\n\n// ── Build response type ─────────────────────────────────────────────────────\n\ntype BuildResponse = {\n inputMint: string;\n outputMint: string;\n inAmount: string;\n outAmount: string;\n otherAmountThreshold: string;\n swapMode: string;\n slippageBps: number;\n routePlan: {\n percent: number;\n bps: number;\n swapInfo: {\n ammKey: string;\n label: string;\n inputMint: string;\n outputMint: string;\n inAmount: string;\n outAmount: string;\n };\n }[];\n computeBudgetInstructions: ApiInstruction[];\n setupInstructions: ApiInstruction[];\n swapInstruction: ApiInstruction;\n cleanupInstruction: ApiInstruction | null;\n otherInstructions: ApiInstruction[];\n tipInstruction: ApiInstruction | null;\n addressesByLookupTableAddress: Record<string, string[]> | null;\n blockhashWithMetadata: {\n blockhash: number[];\n lastValidBlockHeight: number;\n };\n};\n\n// ── Helpers ──────────────────────────────────────────────────────────────────\n\nfunction makeSetComputeUnitLimitIx(units: number): ApiInstruction {\n const data = Buffer.alloc(5);\n data.writeUInt8(0x02, 0);\n data.writeUInt32LE(units, 1);\n return {\n programId: COMPUTE_BUDGET_PROGRAM,\n accounts: [],\n data: data.toString(\"base64\") as ApiInstruction[\"data\"],\n };\n}\n\nfunction transformBlockhash(meta: BuildResponse[\"blockhashWithMetadata\"]): {\n blockhash: Blockhash;\n lastValidBlockHeight: bigint;\n} {\n return {\n blockhash: getBase58Decoder().decode(\n Uint8Array.from(meta.blockhash),\n ) as Blockhash,\n lastValidBlockHeight: BigInt(meta.lastValidBlockHeight),\n };\n}\n\nfunction transformALTs(\n raw: Record<string, string[]> | null,\n): AddressesByLookupTableAddress {\n if (!raw) return {};\n return Object.fromEntries(\n Object.entries(raw).map(([key, addrs]) => [\n address(key),\n addrs.map((a) => address(a)),\n ]),\n );\n}\n\nfunction buildTransaction(\n ixs: Instruction[],\n blockhash: { blockhash: Blockhash; lastValidBlockHeight: bigint },\n alts: AddressesByLookupTableAddress,\n feePayer: Address,\n) {\n return pipe(\n createTransactionMessage({ version: 0 }),\n (msg) => appendTransactionMessageInstructions(ixs, msg),\n (msg) => compressTransactionMessageUsingAddressLookupTables(msg, alts),\n (msg) => setTransactionMessageFeePayer(feePayer, msg),\n (msg) => setTransactionMessageLifetimeUsingBlockhash(blockhash, msg),\n (msg) => compileTransaction(msg),\n );\n}\nimport {\n ComputeBudgetProgram,\n Connection,\n Keypair,\n PublicKey,\n SystemProgram,\n TransactionInstruction,\n TransactionMessage,\n VersionedTransaction,\n AddressLookupTableAccount,\n} from \"@solana/web3.js\";\nimport bs58 from \"bs58\";\n\nconst COMPUTE_UNIT_LIMIT_MAX = 1_400_000;\n\n// ── API response types ──────────────────────────────────────────────────────\n\ntype ApiAccount = {\n pubkey: string;\n isSigner: boolean;\n isWritable: boolean;\n};\n\ntype ApiInstruction = {\n programId: string;\n accounts: ApiAccount[];\n data: string; // base64\n};\n\ntype BuildResponse = {\n inputMint: string;\n outputMint: string;\n inAmount: string;\n outAmount: string;\n otherAmountThreshold: string;\n swapMode: string;\n slippageBps: number;\n routePlan: {\n percent: number;\n bps: number;\n swapInfo: {\n ammKey: string;\n label: string;\n inputMint: string;\n outputMint: string;\n inAmount: string;\n outAmount: string;\n };\n }[];\n computeBudgetInstructions: ApiInstruction[];\n setupInstructions: ApiInstruction[];\n swapInstruction: ApiInstruction;\n cleanupInstruction: ApiInstruction | null;\n otherInstructions: ApiInstruction[];\n tipInstruction: ApiInstruction | null;\n addressesByLookupTableAddress: Record<string, string[]> | null;\n blockhashWithMetadata: {\n blockhash: number[];\n lastValidBlockHeight: number;\n };\n};\n\n// ── Helpers ──────────────────────────────────────────────────────────────────\n\nfunction toInstruction(ix: ApiInstruction): TransactionInstruction {\n return new TransactionInstruction({\n programId: new PublicKey(ix.programId),\n keys: ix.accounts.map((acc) => ({\n pubkey: new PublicKey(acc.pubkey),\n isSigner: acc.isSigner,\n isWritable: acc.isWritable,\n })),\n data: Buffer.from(ix.data, \"base64\"),\n });\n}\n\nfunction transformALTs(\n raw: Record<string, string[]> | null,\n): AddressLookupTableAccount[] {\n if (!raw) return [];\n return Object.entries(raw).map(\n ([key, addresses]) =>\n new AddressLookupTableAccount({\n key: new PublicKey(key),\n state: {\n deactivationSlot: BigInt(\"18446744073709551615\"),\n lastExtendedSlot: 0,\n lastExtendedSlotStartIndex: 0,\n addresses: addresses.map((a) => new PublicKey(a)),\n },\n }),\n );\n}\n\n​Code example\nconst API_KEY = process.env.JUPITER_API_KEY;\nconst RPC_URL = process.env.RPC_URL;\nif (!API_KEY) throw new Error(\"Missing JUPITER_API_KEY\");\nif (!RPC_URL) throw new Error(\"Missing RPC_URL\");\n\nconst signer = await createKeyPairSignerFromBytes(\n getBase58Encoder().encode(process.env.BS58_PRIVATE_KEY!),\n);\nconst rpc = createSolanaRpc(RPC_URL);\n\n// Step 1: Get swap instructions from /build\nconst buildRes = await fetch(\n \"https://api.jup.ag/swap/v2/build?\" +\n new URLSearchParams({\n inputMint: \"So11111111111111111111111111111111111111112\",\n outputMint: \"EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v\",\n amount: \"100000000\",\n taker: signer.address,\n slippageBps: \"100\",\n tipAmount: \"1000000\", // 0.001 SOL tip for /submit (omit if using your own RPC)\n }),\n { headers: { \"x-api-key\": API_KEY } },\n);\nif (!buildRes.ok) {\n console.error(`/build failed: ${buildRes.status}`, await buildRes.text());\n process.exit(1);\n}\nconst build: BuildResponse = await buildRes.json();\n\n// Step 2: Collect instructions (no compute unit limit yet, we simulate first)\n// Example: add a SOL transfer after the swap\nconst RECIPIENT = address(\"YOUR_RECIPIENT_ADDRESS\");\nconst transferIx = getTransferSolInstruction({\n source: signer,\n destination: RECIPIENT,\n amount: 1_000_000n, // 0.001 SOL\n});\n\nconst instructions = [\n ...build.setupInstructions.map(createInstruction),\n createInstruction(build.swapInstruction),\n transferIx, // Your custom instruction, added after the swap\n ...(build.cleanupInstruction\n ? [createInstruction(build.cleanupInstruction)]\n : []),\n ...build.otherInstructions.map(createInstruction),\n ...(build.tipInstruction\n ? [createInstruction(build.tipInstruction)]\n : []),\n];\n\n// Step 3: Prepare blockhash and address lookup tables\nconst blockhash = transformBlockhash(build.blockhashWithMetadata);\nconst alts = transformALTs(build.addressesByLookupTableAddress);\n\n// Step 4: Simulate with max CU limit to estimate actual usage\nconst simulationTx = buildTransaction(\n [\n createInstruction(makeSetComputeUnitLimitIx(COMPUTE_UNIT_LIMIT_MAX)),\n ...instructions,\n ],\n blockhash,\n alts,\n signer.address,\n);\n\nconst simulationResult = await rpc\n .simulateTransaction(getBase64EncodedWireTransaction(simulationTx), {\n encoding: \"base64\",\n commitment: \"confirmed\",\n replaceRecentBlockhash: true,\n })\n .send();\n\nif (simulationResult.value.err) {\n console.error(\"Simulation failed:\", simulationResult.value.err);\n}\n\n// Set 1.2x buffer on simulated CU, capped at max\nconst estimatedCUL = simulationResult.value.unitsConsumed\n ? Math.min(\n Math.ceil(Number(simulationResult.value.unitsConsumed) * 1.2),\n COMPUTE_UNIT_LIMIT_MAX,\n )\n : COMPUTE_UNIT_LIMIT_MAX;\n\n// Step 5: Build final transaction with estimated CU limit + CU price from response\nconst compiledTx = buildTransaction(\n [\n createInstruction(makeSetComputeUnitLimitIx(estimatedCUL)),\n ...build.computeBudgetInstructions.map(createInstruction),\n ...instructions,\n ],\n blockhash,\n alts,\n signer.address,\n);\n\n// Step 6: Sign and submit via /submit (or use your own RPC / transaction pipeline)\nconst signedTransaction = await signTransaction([signer.keyPair], compiledTx);\n\nconst submitRes = await fetch(\"https://api.jup.ag/tx/v1/submit\", {\n method: \"POST\",\n headers: {\n \"Content-Type\": \"application/json\",\n \"x-api-key\": API_KEY,\n },\n body: JSON.stringify({\n signedTransaction: getBase64EncodedWireTransaction(signedTransaction),\n }),\n});\n\nconst { signature } = await submitRes.json();\nconsole.log(\"Submitted:\", `https://solscan.io/tx/${signature}`);\n\n// Step 7: Confirm the transaction landed\nconst confirmation = await rpc\n .confirmTransaction(signature, {\n strategy: { type: \"blockhash\", ...blockhash },\n commitment: \"confirmed\",\n })\n .send();\n\nif (confirmation.value.err) {\n console.error(\"Transaction failed:\", confirmation.value.err);\n process.exit(1);\n}\n\nconsole.log(\"Confirmed:\", signature);\nconst API_KEY = process.env.JUPITER_API_KEY;\nconst RPC_URL = process.env.RPC_URL;\nif (!API_KEY) throw new Error(\"Missing JUPITER_API_KEY\");\nif (!RPC_URL) throw new Error(\"Missing RPC_URL\");\n\nconst connection = new Connection(RPC_URL);\nconst signer = Keypair.fromSecretKey(\n bs58.decode(process.env.BS58_PRIVATE_KEY!),\n);\n\n// Step 1: Get swap instructions from /build\nconst buildRes = await fetch(\n \"https://api.jup.ag/swap/v2/build?\" +\n new URLSearchParams({\n inputMint: \"So11111111111111111111111111111111111111112\",\n outputMint: \"EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v\",\n amount: \"100000000\",\n taker: signer.publicKey.toString(),\n slippageBps: \"100\",\n tipAmount: \"1000000\", // 0.001 SOL tip for /submit (omit if using your own RPC)\n }),\n { headers: { \"x-api-key\": API_KEY } },\n);\nif (!buildRes.ok) {\n console.error(`/build failed: ${buildRes.status}`, await buildRes.text());\n process.exit(1);\n}\nconst build: BuildResponse = await buildRes.json();\n\n// Step 2: Collect instructions (no compute unit limit yet, we simulate first)\n// Example: add a SOL transfer after the swap\nconst RECIPIENT = new PublicKey(\"YOUR_RECIPIENT_ADDRESS\");\nconst transferIx = SystemProgram.transfer({\n fromPubkey: signer.publicKey,\n toPubkey: RECIPIENT,\n lamports: 1_000_000, // 0.001 SOL\n});\n\nconst instructions = [\n ...build.setupInstructions.map(toInstruction),\n toInstruction(build.swapInstruction),\n transferIx, // Your custom instruction, added after the swap\n ...(build.cleanupInstruction\n ? [toInstruction(build.cleanupInstruction)]\n : []),\n ...build.otherInstructions.map(toInstruction),\n ...(build.tipInstruction\n ? [toInstruction(build.tipInstruction)]\n : []),\n];\n\n// Step 3: Resolve address lookup tables (from /build response, no RPC needed)\nconst addressLookupTableAccounts = transformALTs(\n build.addressesByLookupTableAddress,\n);\n\nconst { blockhash, lastValidBlockHeight } = build.blockhashWithMetadata;\nconst recentBlockhash = bs58.encode(Buffer.from(blockhash));\n\n// Step 4: Simulate with max CU limit to estimate actual usage\nconst simulationMessage = new TransactionMessage({\n payerKey: signer.publicKey,\n recentBlockhash,\n instructions: [\n ComputeBudgetProgram.setComputeUnitLimit({ units: COMPUTE_UNIT_LIMIT_MAX }),\n ...instructions,\n ],\n}).compileToV0Message(addressLookupTableAccounts);\n\nconst simulationTx = new VersionedTransaction(simulationMessage);\nconst simulationResult = await connection.simulateTransaction(simulationTx, {\n replaceRecentBlockhash: true,\n});\n\nif (simulationResult.value.err) {\n console.error(\"Simulation failed:\", simulationResult.value.err);\n}\n\n// Set 1.2x buffer on simulated CU, capped at max\nconst estimatedCUL = simulationResult.value.unitsConsumed\n ? Math.min(\n Math.ceil(simulationResult.value.unitsConsumed * 1.2),\n COMPUTE_UNIT_LIMIT_MAX,\n )\n : COMPUTE_UNIT_LIMIT_MAX;\n\n// Step 5: Build final transaction with estimated CU limit + CU price from response\nconst finalMessage = new TransactionMessage({\n payerKey: signer.publicKey,\n recentBlockhash,\n instructions: [\n ComputeBudgetProgram.setComputeUnitLimit({ units: estimatedCUL }),\n ...build.computeBudgetInstructions.map(toInstruction), // CU price from response\n ...instructions,\n ],\n}).compileToV0Message(addressLookupTableAccounts);\n\n// Step 6: Sign and submit via /submit (or use your own RPC / transaction pipeline)\nconst transaction = new VersionedTransaction(finalMessage);\ntransaction.sign([signer]);\n\nconst submitRes = await fetch(\"https://api.jup.ag/tx/v1/submit\", {\n method: \"POST\",\n headers: {\n \"Content-Type\": \"application/json\",\n \"x-api-key\": API_KEY,\n },\n body: JSON.stringify({\n signedTransaction: Buffer.from(transaction.serialize()).toString(\"base64\"),\n }),\n});\n\nconst { signature } = await submitRes.json();\nconsole.log(\"Submitted:\", `https://solscan.io/tx/${signature}`);\n\n// Step 7: Confirm the transaction landed\nconst confirmation = await connection.confirmTransaction(\n { signature, blockhash: recentBlockhash, lastValidBlockHeight },\n \"confirmed\",\n);\n\nif (confirmation.value.err) {\n console.error(\"Transaction failed:\", confirmation.value.err);\n process.exit(1);\n}\n\nconsole.log(\"Confirmed:\", signature);\n\n​How it works\n​1. Call /build\nGET /build returns a quote and all the instructions you need to build a swap transaction.\nRequired parameters:\nParameterDescriptioninputMintMint address of the token you are sellingoutputMintMint address of the token you are buyingamountAmount in the smallest unit of the input tokentakerYour wallet address\nKey response fields:\nFieldDescriptioncomputeBudgetInstructionsCompute unit price instruction (does not include compute unit limit). Empty when transactionVersion is \"1\": use computeUnitPrice on the message config insteadsetupInstructionsPre-swap setup (e.g. ATA creation)swapInstructionThe main swap instructioncleanupInstructionPost-swap cleanup (may be null)otherInstructionsAdditional instructionstipInstructionSOL tip transfer instruction (present when tipAmount is provided)addressesByLookupTableAddressAddress lookup tables for v0 transactions. {} when transactionVersion is \"1\" (v1 inlines accounts, no lookup tables)transactionVersionThe version these instructions are for, 0 or 1computeUnitPricePresent when transactionVersion is \"1\". Compute unit price in micro-lamports, to set on the message configblockhashWithMetadataRecent blockhash and expiry height\nEach instruction follows this structure:\n{\n programId: string, // Program address\n accounts: [\n {\n pubkey: string, // Account address\n isWritable: boolean,\n isSigner: boolean\n }\n ],\n data: string // Base64-encoded instruction data\n}\n\n​2. Add your own instructions\nInsert custom instructions alongside the swap instructions. Common examples:\n\nSOL transfer (tip or payment)\nMemo instruction\nCreate or close token accounts\nCustom program CPI\n\nSee Common Instructions for a reference of common instructions.\n​3. Simulate compute unit limit\nThe /build response includes computeBudgetInstructions with the compute unit price but not the compute unit limit. You need to simulate the transaction to determine the correct limit.\nWhy: integrators using /build typically add their own instructions, so the CU usage will differ from the base swap. The simulation gives you the actual CU consumed, and you set the limit to 1.2x that value (capped at 1,400,000).\nBoth code examples above demonstrate this: simulate with max CU limit, then rebuild with 1.2x the simulated value plus the CU price from the response. See Solana fee structure for more on compute units and Estimate Compute Units for a standalone guide.\nValidate the compute unit price from the response before signing. The estimate tracks recent network priority fees and can spike when recent blocks contain transactions bidding extreme values. See Cap the compute unit price for a decode-and-clamp snippet.\n​4. Build the transaction\nBy default /build returns v0 instructions. The response includes address lookup tables in addressesByLookupTableAddress; use these to compile a v0 (versioned) transaction, which supports more accounts than legacy transactions.\nPass transactionVersion=1 to build a Solana v1 transaction instead. v1 raises the size limit to 4096 bytes and inlines accounts without lookup tables, so addressesByLookupTableAddress is {} and computeBudgetInstructions is empty. Set the compute budget (including the returned computeUnitPrice) on the message config, and build with a v1-capable SDK (@solana/kit v8 or later). If an end-user wallet signs the transaction, confirm it supports v1 first: not all wallet extensions do, and signing fails otherwise. See Transaction Versions for a full v1 example.\n​5. Sign and send\nSign the transaction with your wallet and send via your own RPC, or use /submit to land them through Jupiter’s transaction infrastructure with SOL tips.\n/build transactions cannot use /execute.\n/build does not have the required requestId\n/build is intended for customisations, and /execute validates the transaction to prevent any changes\n\n​Router vs Meta-Aggregator\nMeta-Aggregator (/order)Router (/build)RoutingAll engines (Metis, JupiterZ, Dflow, OKX)Metis onlySwap feesJupiter platform feeNoneTransaction landingManaged via /executeSelf-managed or use Jupiter’s proprietary transaction landing pipeline via /submitTransaction controlNoneFullCompute budgetIncluded in transactionIncluded as instructions (you can override)\n​Optional parameters\nParameterDefaultDescriptionslippageBps50Slippage tolerance in basis points, or \"rtse\" for RTSEtipAmount-SOL tip amount in lamports. Adds a tip instruction for use with /submitcomputeUnitPricePercentile-Priority fee percentile for the CU price instruction. Named levels: \"medium\" (25th), \"high\" (50th), \"veryHigh\" (75th), or an integer 0-10000 in bps. See Compute Unitsmode(default)“fast” for reduced latency routing (BETA)maxAccounts64Maximum accounts for the swap route (1-64)platformFeeBps0Integrator platform fee in bps (requires feeAccount)feeAccount-Token account to collect platform feespayerpublic keyAccount that pays transaction fees and rentwrapAndUnwrapSoltrueWhether to wrap/unwrap SOL automaticallydexes(all)Restrict routing to specific DEXes. Labels are case sensitive. See the full DEX label listexcludeDexes(none)Exclude specific DEXes from routing. Labels are case sensitive. See the full DEX label listdestinationTokenAccount-SPL token account for outputnativeDestinationAccount-Native SOL account for outputblockhashSlotsToExpiry150Slots until blockhash expires (1-300)forJitoBundlefalseExclude DEXes incompatible with Jito bundlestransactionVersion\"0\"Solana transaction version to build for, \"0\" or \"1\". \"1\" returns v1 instructions: no lookup tables, and the compute budget as response fields instead of instructions. See Transaction Versions\nFor the full parameter reference, see the API reference.\n​Fees\nJupiter does not charge swap fees on /build. The only fee mechanism is integrator platform fees via platformFeeBps and feeAccount:\nconst params = new URLSearchParams({\n inputMint: \"So11111111111111111111111111111111111111112\",\n outputMint: \"EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v\",\n amount: \"1000000000\",\n taker: walletAddress,\n platformFeeBps: \"50\", // 0.5%\n feeAccount: \"YOUR_FEE_TOKEN_ACCOUNT\",\n});\n\nconst response = await fetch(\n `https://api.jup.ag/swap/v2/build?${params}`,\n { headers: { \"x-api-key\": API_KEY } }\n);\n\nYour fee is added as part of the swap instruction. The feeAccount can be any SPL token account you control (it does not need to be a referral program account). You are responsible for creating and managing this account.\n​Related\n\nTransaction Submission to submit via Jupiter’s transaction landing infrastructure with SOL tips for priority processing\nCommon Instructions for common instructions to compose with your swap\nAdvanced Techniques for CU simulation, mode: \"fast\", and maxAccounts\nAPI Reference: GET /build for the full OpenAPI specification\nWas this page helpful?","tokens":5303,"squid":"spider-02","role":"Liquidity Spider","at":1791345195738,"hash":"c9ecb3fa30a330dfb613ddf1a81315514318c9f1"}
{"url":"https://consensysdiligence.github.io/smart-contract-best-practices/development-recommendations/solidity-specific/tx-origin/","domain":"consensysdiligence.github.io","title":"tx.origin - Ethereum Smart Contract Best Practices","text":"tx.origin\n\nTip\nFor comprehensive insights into secure development practices, consider visiting the Development Recommendations section of the Smart Contract Security Field Guide. This resource provides in-depth articles to guide you in developing robust and secure smart contracts.\n\nNever use tx.origin for authorization, another contract can have a method which will call your\ncontract (where the user has some funds for instance) and your contract will authorize that\ntransaction as your address is in tx.origin.\ncontract MyContract {\n\n address owner;\n\n function MyContract() public {\n owner = msg.sender;\n }\n\n function sendTo(address receiver, uint amount) public {\n require(tx.origin == owner);\n (bool success, ) = receiver.call.value(amount)(\"\");\n require(success);\n }\n\n}\n\ncontract AttackingContract {\n\n MyContract myContract;\n address attacker;\n\n function AttackingContract(address myContractAddress) public {\n myContract = MyContract(myContractAddress);\n attacker = msg.sender;\n }\n\n function() public {\n myContract.sendTo(attacker, msg.sender.balance);\n }\n\n}\n\nYou should use msg.sender for authorization (if another contract calls your contract msg.sender\nwill be the address of the contract and not the address of the user who called the contract).\nYou can read more about it here:\nSolidity docs\n\nWarning\nBesides the issue with authorization, there is a chance that tx.origin will be\nremoved from the Ethereum protocol in the future, so code that uses tx.origin won't be compatible\nwith future releases\nVitalik: 'Do NOT assume that tx.origin will continue to be usable or meaningful.'\nIt's also worth mentioning that by using tx.origin you're limiting interoperability between\ncontracts because the contract that uses tx.origin cannot be used by another contract as a contract\ncan't be the tx.origin.\nSee SWC-115","tokens":455,"squid":"spider-06","role":"Security Spider","at":1791345202843,"hash":"8913d63673c392aaf95db2f6090281a6f0d85165"}
{"url":"https://developers.jup.ag/docs/transaction/submit","domain":"developers.jup.ag","title":"Transaction Submission - Jupiter Developers","text":"tx.jup.ag is a Solana RPC-compatible endpoint that forwards your signed transactions to the Solana cluster through Jupiter’s proprietary landing infrastructure, the same stack that powers Jupiter’s own swap products. Point any Solana client at it, authenticate with your Jupiter API key, and call sendTransaction as you would against any RPC node. It accepts any valid signed Solana transaction with a SOL tip.\n​How it works\ntx.jup.ag is Solana RPC-compatible where possible: it implements the standard sendTransaction method, so any Solana client library can talk to it with only an endpoint change. It is send-only, so it does not serve getLatestBlockhash, simulateTransaction, or confirmation queries; keep your usual RPC for those.\n\nBuild your transaction (using /build, or assemble your own)\nInclude a SOL tip transfer instruction (minimum 0.001 SOL) to one of 16 tip receiver accounts\nSign the transaction\nSend it with sendTransaction to https://tx.jup.ag, passing your API key in the x-api-key header\n\nFor /build transactions, use the tipAmount parameter to have the tip instruction included automatically. For non-Jupiter transactions, add a standard SOL transfer instruction to one of the tip receiver accounts.\nThe request is a standard JSON-RPC call, so any language works:\ncurl https://tx.jup.ag \\\n -H \"Content-Type: application/json\" \\\n -H \"x-api-key: $JUPITER_API_KEY\" \\\n -d '{\n \"jsonrpc\": \"2.0\",\n \"id\": 1,\n \"method\": \"sendTransaction\",\n \"params\": [\"<base64-signed-transaction>\", { \"encoding\": \"base64\" }]\n }'\n\nA successful response returns the signature in result. This means the transaction was accepted and forwarded, not that it landed, so confirm on your own RPC. A transaction without a valid tip is rejected with Transaction must include a Jupiter tip instruction.\n​Requirements\nRequirementDetailsEndpointPOST https://tx.jup.ag, JSON-RPC method sendTransactionValid signed transactionMust be a valid Solana transaction with all required signaturesSOL tipMinimum 1,000,000 lamports (0.001 SOL) transferred to one of the 16 tip receiver accountsTransaction sizeMust not exceed the Solana transaction size limit (1232 bytes)API accessRequires a Jupiter API key in the x-api-key header\nThe sendTransaction config (the second param) takes:\nFieldValueencodingDefaults to base64 (the only supported value)skipPreflightPreflight is not supported; defaults to true. An explicit false is rejected with -1015maxRetriesDefaults to 0. A non-zero value is rejected with -1015swqosOnlyOptional. false (default) uses SWQoS + Jito; true uses SWQoS only. See Tips and fees\n​Tips and fees\nEvery transaction must include the Jupiter tip instruction (minimum 0.001 SOL) or it is rejected. The Jupiter tip is flat: tipping more does not improve landing. Add priority fees when the network is congested.\nWhether to add a Jito tip depends on swqosOnly:\nswqosOnlyRoutingJito tipfalse (default)SWQoS + JitoNot needed, Beam adds a small one. Optionally add your own to boost Jito landing.trueSWQoS onlyDo not add, it will not help.\n​Code example\n​Using /build\nUse /build with the tipAmount parameter to automatically include a tip instruction in the response.\nimport {\n AddressLookupTableAccount,\n ComputeBudgetProgram,\n Connection,\n Keypair,\n PublicKey,\n TransactionInstruction,\n TransactionMessage,\n VersionedTransaction,\n} from \"@solana/web3.js\";\nimport bs58 from \"bs58\";\n\n// ── Types matching the /build response ───────────────────────────────────────\n\ntype ApiAccount = { pubkey: string; isSigner: boolean; isWritable: boolean };\n\ntype ApiInstruction = {\n programId: string;\n accounts: ApiAccount[];\n data: string; // base64\n};\n\ntype BuildResponse = {\n computeBudgetInstructions: ApiInstruction[];\n setupInstructions: ApiInstruction[];\n swapInstruction: ApiInstruction;\n cleanupInstruction: ApiInstruction | null;\n otherInstructions: ApiInstruction[];\n tipInstruction: ApiInstruction;\n addressesByLookupTableAddress: Record<string, string[]> | null;\n blockhashWithMetadata: {\n blockhash: number[];\n lastValidBlockHeight: number;\n };\n};\n\n// ── Helpers ──────────────────────────────────────────────────────────────────\n\nconst CU_LIMIT_MAX = 1_400_000;\n\nfunction toInstruction(ix: ApiInstruction): TransactionInstruction {\n return new TransactionInstruction({\n programId: new PublicKey(ix.programId),\n keys: ix.accounts.map((acc) => ({\n pubkey: new PublicKey(acc.pubkey),\n isSigner: acc.isSigner,\n isWritable: acc.isWritable,\n })),\n data: Buffer.from(ix.data, \"base64\"),\n });\n}\n\n// ── Main ─────────────────────────────────────────────────────────────────────\n\nconst API_KEY = process.env.JUPITER_API_KEY!;\nconst connection = new Connection(process.env.RPC_URL!);\n// Send-only endpoint; blockhash and confirmation stay on your own RPC.\nconst txConnection = new Connection(\"https://tx.jup.ag\", {\n httpHeaders: { \"x-api-key\": API_KEY },\n});\nconst signer = Keypair.fromSecretKey(\n bs58.decode(process.env.BS58_PRIVATE_KEY!),\n);\n\n// 1. Call /build with your swap parameters\nconst buildRes = await fetch(\n \"https://api.jup.ag/swap/v2/build?\" +\n new URLSearchParams({\n inputMint: \"So11111111111111111111111111111111111111112\",\n outputMint: \"EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v\",\n amount: \"100000000\",\n taker: signer.publicKey.toString(),\n tipAmount: \"1000000\",\n }),\n { headers: { \"x-api-key\": API_KEY } },\n);\nconst build: BuildResponse = await buildRes.json();\n\n// 2. Collect instructions (excluding compute budget — we handle CU limit ourselves)\nconst instructions = [\n ...build.setupInstructions.map(toInstruction),\n toInstruction(build.swapInstruction),\n ...(build.cleanupInstruction\n ? [toInstruction(build.cleanupInstruction)]\n : []),\n ...build.otherInstructions.map(toInstruction),\n toInstruction(build.tipInstruction),\n];\n\n// 3. Prepare blockhash and address lookup tables\nconst addressLookupTableAccounts: AddressLookupTableAccount[] = [];\nfor (const addr of Object.keys(build.addressesByLookupTableAddress ?? {})) {\n const result = await connection.getAddressLookupTable(new PublicKey(addr));\n if (result.value) addressLookupTableAccounts.push(result.value);\n}\n\nconst recentBlockhash = bs58.encode(\n Buffer.from(build.blockhashWithMetadata.blockhash),\n);\nconst { lastValidBlockHeight } = build.blockhashWithMetadata;\n\n// 4. Simulate to estimate CU usage, then apply 1.2x buffer\nconst simMessage = new TransactionMessage({\n payerKey: signer.publicKey,\n recentBlockhash,\n instructions: [\n ComputeBudgetProgram.setComputeUnitLimit({ units: CU_LIMIT_MAX }),\n ...instructions,\n ],\n}).compileToV0Message(addressLookupTableAccounts);\n\nconst sim = await connection.simulateTransaction(\n new VersionedTransaction(simMessage),\n { sigVerify: false, replaceRecentBlockhash: true },\n);\n\nif (sim.value.err) {\n console.error(\"Simulation failed:\", sim.value.err);\n process.exit(1);\n}\n\nconst estimatedCUL = sim.value.unitsConsumed\n ? Math.min(Math.ceil(sim.value.unitsConsumed * 1.2), CU_LIMIT_MAX)\n : CU_LIMIT_MAX;\n\n// 5. Build final transaction with estimated CU limit + CU price from response\nconst messageV0 = new TransactionMessage({\n payerKey: signer.publicKey,\n recentBlockhash,\n instructions: [\n ComputeBudgetProgram.setComputeUnitLimit({ units: estimatedCUL }),\n ...build.computeBudgetInstructions.map(toInstruction),\n ...instructions,\n ],\n}).compileToV0Message(addressLookupTableAccounts);\n\nconst transaction = new VersionedTransaction(messageV0);\ntransaction.sign([signer]);\n\n// 6. Submit the signed transaction through tx.jup.ag (or use your own RPC / transaction pipeline)\nconst signature = await txConnection.sendRawTransaction(\n transaction.serialize(),\n { skipPreflight: true, maxRetries: 0 },\n);\nconsole.log(\"Submitted:\", `https://solscan.io/tx/${signature}`);\n\n// 7. Confirm the transaction landed\nconst confirmation = await connection.confirmTransaction(\n { signature, blockhash: recentBlockhash, lastValidBlockHeight },\n \"confirmed\",\n);\n\nif (confirmation.value.err) {\n console.error(\"Transaction failed:\", confirmation.value.err);\n process.exit(1);\n}\n\nconsole.log(\"Confirmed:\", signature);\nimport {\n AccountRole,\n Address,\n address,\n AddressesByLookupTableAddress,\n appendTransactionMessageInstructions,\n Base64EncodedBytes,\n Blockhash,\n compileTransaction,\n compressTransactionMessageUsingAddressLookupTables,\n createDefaultRpcTransport,\n createKeyPairSignerFromBytes,\n createSolanaRpc,\n createSolanaRpcFromTransport,\n createTransactionMessage,\n getBase58Decoder,\n getBase58Encoder,\n getBase64Codec,\n getBase64EncodedWireTransaction,\n AccountMeta,\n Instruction,\n pipe,\n setTransactionMessageFeePayer,\n setTransactionMessageLifetimeUsingBlockhash,\n signTransaction,\n} from \"@solana/kit\";\n\n// ── Types matching the /build response ───────────────────────────────────────\n\ntype Account = { pubkey: Address; isSigner: boolean; isWritable: boolean };\n\ntype ApiInstruction = {\n programId: Address;\n accounts: Account[];\n data: Base64EncodedBytes;\n};\n\ntype BuildResponse = {\n computeBudgetInstructions: ApiInstruction[];\n setupInstructions: ApiInstruction[];\n swapInstruction: ApiInstruction;\n cleanupInstruction: ApiInstruction | null;\n otherInstructions: ApiInstruction[];\n tipInstruction: ApiInstruction;\n addressesByLookupTableAddress: Record<string, string[]> | null;\n blockhashWithMetadata: {\n blockhash: number[];\n lastValidBlockHeight: number;\n };\n};\n\n// ── Helpers ──────────────────────────────────────────────────────────────────\n\nconst COMPUTE_BUDGET_PROGRAM = address(\n \"ComputeBudget111111111111111111111111111111\",\n);\nconst CU_LIMIT_MAX = 1_400_000;\n\nfunction createInstruction(ix: ApiInstruction): Instruction {\n return {\n programAddress: ix.programId,\n accounts: ix.accounts.map((acc) => ({\n address: acc.pubkey,\n role: acc.isSigner && acc.isWritable\n ? AccountRole.WRITABLE_SIGNER\n : acc.isSigner\n ? AccountRole.READONLY_SIGNER\n : acc.isWritable\n ? AccountRole.WRITABLE\n : AccountRole.READONLY,\n })),\n data: Uint8Array.from(getBase64Codec().encode(ix.data)),\n };\n}\n\nfunction makeSetComputeUnitLimitIx(units: number): ApiInstruction {\n const data = Buffer.alloc(5);\n data.writeUInt8(0x02, 0);\n data.writeUInt32LE(units, 1);\n return {\n programId: COMPUTE_BUDGET_PROGRAM,\n accounts: [],\n data: data.toString(\"base64\") as ApiInstruction[\"data\"],\n };\n}\n\nfunction transformBlockhash(meta: BuildResponse[\"blockhashWithMetadata\"]) {\n return {\n blockhash: getBase58Decoder().decode(\n Uint8Array.from(meta.blockhash),\n ) as Blockhash,\n lastValidBlockHeight: BigInt(meta.lastValidBlockHeight),\n };\n}\n\nfunction transformALTs(\n raw: Record<string, string[]> | null,\n): AddressesByLookupTableAddress {\n if (!raw) return {};\n return Object.fromEntries(\n Object.entries(raw).map(([key, addrs]) => [\n address(key),\n addrs.map((a) => address(a)),\n ]),\n );\n}\n\nfunction buildTransaction(\n ixs: Instruction[],\n blockhash: { blockhash: Blockhash; lastValidBlockHeight: bigint },\n alts: AddressesByLookupTableAddress,\n feePayer: Address,\n) {\n return pipe(\n createTransactionMessage({ version: 0 }),\n (msg) => appendTransactionMessageInstructions(ixs, msg),\n (msg) => compressTransactionMessageUsingAddressLookupTables(msg, alts),\n (msg) => setTransactionMessageFeePayer(feePayer, msg),\n (msg) => setTransactionMessageLifetimeUsingBlockhash(blockhash, msg),\n (msg) => compileTransaction(msg),\n );\n}\n\n// ── Main ─────────────────────────────────────────────────────────────────────\n\nconst API_KEY = process.env.JUPITER_API_KEY!;\nconst rpc = createSolanaRpc(process.env.RPC_URL!);\n// Send-only endpoint; blockhash and confirmation stay on your own RPC.\nconst txRpc = createSolanaRpcFromTransport(\n createDefaultRpcTransport({\n url: \"https://tx.jup.ag\",\n headers: { \"x-api-key\": API_KEY },\n }),\n);\nconst signer = await createKeyPairSignerFromBytes(\n getBase58Encoder().encode(process.env.BS58_PRIVATE_KEY!),\n);\n\n// 1. Call /build with your swap parameters\nconst buildRes = await fetch(\n \"https://api.jup.ag/swap/v2/build?\" +\n new URLSearchParams({\n inputMint: \"So11111111111111111111111111111111111111112\",\n outputMint: \"EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v\",\n amount: \"100000000\",\n taker: signer.address,\n tipAmount: \"1000000\",\n }),\n { headers: { \"x-api-key\": API_KEY } },\n);\nconst build: BuildResponse = await buildRes.json();\n\n// 2. Collect instructions (excluding compute budget — we handle CU limit ourselves)\nconst instructions = [\n ...build.setupInstructions.map(createInstruction),\n createInstruction(build.swapInstruction),\n ...(build.cleanupInstruction\n ? [createInstruction(build.cleanupInstruction)]\n : []),\n ...build.otherInstructions.map(createInstruction),\n createInstruction(build.tipInstruction),\n];\n\n// 3. Prepare blockhash and address lookup tables\nconst blockhash = transformBlockhash(build.blockhashWithMetadata);\nconst alts = transformALTs(build.addressesByLookupTableAddress);\n\n// 4. Simulate to estimate CU usage, then apply 1.2x buffer\nconst simTx = buildTransaction(\n [createInstruction(makeSetComputeUnitLimitIx(CU_LIMIT_MAX)), ...instructions],\n blockhash,\n alts,\n signer.address,\n);\nconst sim = await rpc\n .simulateTransaction(getBase64EncodedWireTransaction(simTx), {\n encoding: \"base64\",\n commitment: \"confirmed\",\n replaceRecentBlockhash: true,\n })\n .send();\n\nif (sim.value.err) {\n console.error(\"Simulation failed:\", sim.value.err);\n process.exit(1);\n}\n\nconst estimatedCUL = sim.value.unitsConsumed\n ? Math.min(\n Math.ceil(Number(sim.value.unitsConsumed) * 1.2),\n CU_LIMIT_MAX,\n )\n : CU_LIMIT_MAX;\n\n// 5. Build final transaction with estimated CU limit + CU price from response\nconst compiledTx = buildTransaction(\n [\n createInstruction(makeSetComputeUnitLimitIx(estimatedCUL)),\n ...build.computeBudgetInstructions.map(createInstruction),\n ...instructions,\n ],\n blockhash,\n alts,\n signer.address,\n);\n\n// 6. Sign and submit through tx.jup.ag (or use your own RPC / transaction pipeline)\nconst signedTx = await signTransaction([signer.keyPair], compiledTx);\n\nconst signature = await txRpc\n .sendTransaction(getBase64EncodedWireTransaction(signedTx), {\n encoding: \"base64\",\n skipPreflight: true,\n maxRetries: 0,\n })\n .send();\nconsole.log(\"Submitted:\", `https://solscan.io/tx/${signature}`);\n\n// 7. Confirm the transaction landed\nconst confirmation = await rpc\n .confirmTransaction(signature, {\n strategy: { type: \"blockhash\", ...blockhash },\n commitment: \"confirmed\",\n })\n .send();\n\nif (confirmation.value.err) {\n console.error(\"Transaction failed:\", confirmation.value.err);\n process.exit(1);\n}\n\nconsole.log(\"Confirmed:\", signature);\n\n​Adding tip instruction manually\nFor non-Jupiter transactions (another swap protocol, a program call, a transfer), add a standard SOL transfer to one of the 16 tip receiver accounts. Randomise which account you send to on each transaction to reduce write-lock contention.\nimport { SystemProgram, PublicKey } from \"@solana/web3.js\";\n\nconst TIP_ACCOUNTS = [\n \"GGztQqQ6pCPaJQnNpXBgELr5cs3WwDakRbh1iEMzjgSJ\",\n \"2MFoS3MPtvyQ4Wh4M9pdfPjz6UhVoNbFbGJAskCPCj3h\",\n \"BQ72nSv9f3PRyRKCBnHLVrerrv37CYTHm5h3s9VSGQDV\",\n \"6U91aKa8pmMxkJwBCfPTmUEfZi6dHe7DcFq2ALvB2tbB\",\n \"4xDsmeTWPNjgSVSS1VTfzFq3iHZhp77ffPkAmkZkdu71\",\n \"CapuXNQoDviLvU1PxFiizLgPNQCxrsag1uMeyk6zLVps\",\n \"9nnLbotNTcUhvbrsA6Mdkx45Sm82G35zo28AqUvjExn8\",\n \"6LXutJvKUw8Q5ue2gCgKHQdAN4suWW8awzFVC6XCguFx\",\n \"HFqp6ErWHY6Uzhj8rFyjYuDya2mXUpYEk8VW75K9PSiY\",\n \"DSN3j1ykL3obAVNv7ZX49VsFCPe4LqzxHnmtLiPwY6xg\",\n \"69yhtoJR4JYPPABZcSNkzuqbaFbwHsCkja1sP1Q2aVT5\",\n \"HU23r7UoZbqTUuh3vA7emAGztFtqwTeVips789vqxxBw\",\n \"3LoAYHuSd7Gh8d7RTFnhvYtiTiefdZ5ByamU42vkzd76\",\n \"3CgvbiM3op4vjrrjH2zcrQUwsqh5veNVRjFCB9N6sRoD\",\n \"GP8StUXNYSZjPikyRsvkTbvRV1GBxMErb59cpeCJnDf1\",\n \"7iWnBRRhBCiNXXPhqiGzvvBkKrvFSWqqmxRyu9VyYBxE\",\n];\n\nconst tipIx = SystemProgram.transfer({\n fromPubkey: signer.publicKey,\n toPubkey: new PublicKey(\n TIP_ACCOUNTS[Math.floor(Math.random() * TIP_ACCOUNTS.length)]\n ),\n lamports: 1_000_000, // 0.001 SOL minimum\n});\n\n// Add tipIx to your transaction, sign, then send via tx.jup.ag\nimport { getTransferSolInstruction } from \"@solana-program/system\";\n\nconst TIP_ACCOUNTS = [\n \"GGztQqQ6pCPaJQnNpXBgELr5cs3WwDakRbh1iEMzjgSJ\",\n \"2MFoS3MPtvyQ4Wh4M9pdfPjz6UhVoNbFbGJAskCPCj3h\",\n \"BQ72nSv9f3PRyRKCBnHLVrerrv37CYTHm5h3s9VSGQDV\",\n \"6U91aKa8pmMxkJwBCfPTmUEfZi6dHe7DcFq2ALvB2tbB\",\n \"4xDsmeTWPNjgSVSS1VTfzFq3iHZhp77ffPkAmkZkdu71\",\n \"CapuXNQoDviLvU1PxFiizLgPNQCxrsag1uMeyk6zLVps\",\n \"9nnLbotNTcUhvbrsA6Mdkx45Sm82G35zo28AqUvjExn8\",\n \"6LXutJvKUw8Q5ue2gCgKHQdAN4suWW8awzFVC6XCguFx\",\n \"HFqp6ErWHY6Uzhj8rFyjYuDya2mXUpYEk8VW75K9PSiY\",\n \"DSN3j1ykL3obAVNv7ZX49VsFCPe4LqzxHnmtLiPwY6xg\",\n \"69yhtoJR4JYPPABZcSNkzuqbaFbwHsCkja1sP1Q2aVT5\",\n \"HU23r7UoZbqTUuh3vA7emAGztFtqwTeVips789vqxxBw\",\n \"3LoAYHuSd7Gh8d7RTFnhvYtiTiefdZ5ByamU42vkzd76\",\n \"3CgvbiM3op4vjrrjH2zcrQUwsqh5veNVRjFCB9N6sRoD\",\n \"GP8StUXNYSZjPikyRsvkTbvRV1GBxMErb59cpeCJnDf1\",\n \"7iWnBRRhBCiNXXPhqiGzvvBkKrvFSWqqmxRyu9VyYBxE\",\n];\n\nconst tipIx = getTransferSolInstruction({\n source: signer,\n destination: address(\n TIP_ACCOUNTS[Math.floor(Math.random() * TIP_ACCOUNTS.length)]\n ),\n amount: 1_000_000n, // 0.001 SOL minimum\n});\n\n// Add tipIx to your transaction, sign, then send via tx.jup.ag\n\n​Best practices\n\nRandomise tip accounts: there are 16 tip receiver accounts. Randomise which one you send to on each transaction to reduce write-lock contention across concurrent submissions.\nRun in parallel with your own RPC: submitting the same signed transaction through both tx.jup.ag and your existing RPC is a zero-risk way to compare landing. Whichever confirms first wins; the duplicate is dropped by the network.\nPoll for confirmation on your own RPC: tx.jup.ag is send-only. Confirm with the blockhash and lastValidBlockHeight from your transaction. If the blockhash expires without confirmation, rebuild with a fresh blockhash and resubmit.\nSimulate on your own RPC first: tx.jup.ag does not simulate, so run any preflight simulation against your own RPC before submitting.\nColocate for lowest latency: Jupiter’s API gateway runs in six AWS regions. Deploy your servers in the nearest region to minimise round-trip time.\n\n​Why it lands fast\nJupiter’s transaction landing stack is purpose-built for high throughput and low latency:\n\nDirect to Beam. tx.jup.ag routes straight to the landing infrastructure. The legacy api.jup.ag/tx/v1/submit proxies through the API gateway first, so tx.jup.ag removes that hop.\nSWQoS via high-stake validator. Jupiter operates one of the highest-staked validators on Solana. Solana’s Stake-Weighted Quality of Service (SWQoS) reserves ~80% of a leader’s TPU capacity for staked validators proportional to their stake. Higher stake means more reserved bandwidth when forwarding transactions to the current leader.\nBeam (custom TPU forwarder). Jupiter’s own TPU client bypasses standard RPC nodes and sends transactions directly to leaders via staked QUIC connections. This removes intermediaries that could be malicious actors and eliminates RPC processing overhead.\nDoubleZero. Dedicated fiber network for validator communication, with FPGA-based spam filtering and transaction deduplication at the network edge. Cleaner transaction set, faster propagation between validators.\nUltra-low-latency fiber. Private fiber links from Tokyo to Frankfurt reduce physical propagation time between Jupiter’s infrastructure and leader validators globally.\n\n​How this differs from /execute\n/executetx.jup.agPaired with/order (meta-aggregator flow)/build or any signed transactionInterfaceREST POST /swap/v2/executeSolana JSON-RPC sendTransactionFee modelJupiter swap fees (included in the order)SOL tips (minimum 0.001 SOL)Transaction sourceMust match the exact transaction from /orderAny valid signed Solana transactionUse caseManaged swap execution for /order transactionsAny transaction: /build swaps, non-Jupiter transactions\n​API reference\nEndpoint: POST https://tx.jup.ag, JSON-RPC method sendTransaction.\nSee the transaction submission API reference for the request and response shape.\nThe legacy REST endpoint POST https://api.jup.ag/tx/v1/submit still accepts the same signed transactions, but tx.jup.ag is the recommended path going forward.\n​Related\n\nBuild: build custom transactions with /build (use tipAmount for automatic tip inclusion)\nOrder & Execute: the standard swap flow using /order + /execute\nReduce Latency: use mode=fast on /build for faster routing\nLatency and Server Locations: API gateway regions and colocation guidance\nWas this page helpful?","tokens":5058,"squid":"spider-02","role":"Liquidity Spider","at":1791345207088,"hash":"f2a0dc9d38c8aa6b431d61e9e425d7b228428f0e"}
{"url":"https://consensysdiligence.github.io/smart-contract-best-practices/development-recommendations/solidity-specific/interface-types/","domain":"consensysdiligence.github.io","title":"Interface Types - Ethereum Smart Contract Best Practices","text":"Interface Types\n\nTip\nFor comprehensive insights into secure development practices, consider visiting the Development Recommendations section of the Smart Contract Security Field Guide. This resource provides in-depth articles to guide you in developing robust and secure smart contracts.\n\nWhen a function takes a contract address as an argument, it is better to pass an interface or\ncontract type rather than a raw address. If the function is called elsewhere within the source\ncode, the compiler will provide additional type safety guarantees.\nHere we see two alternatives:\ncontract Validator {\n function validate(uint) external returns(bool);\n}\n\ncontract TypeSafeAuction {\n // good\n function validateBet(Validator _validator, uint _value) internal returns(bool) {\n bool valid = _validator.validate(_value);\n return valid;\n }\n}\n\ncontract TypeUnsafeAuction {\n // bad\n function validateBet(address _addr, uint _value) internal returns(bool) {\n Validator validator = Validator(_addr);\n bool valid = validator.validate(_value);\n return valid;\n }\n}\n\nThe benefits of using the TypeSafeAuction contract above can then be seen from the following\nexample. If validateBet() is called with an address argument, or a contract type other than\nValidator, the compiler will throw this error:\ncontract NonValidator{}\n\ncontract Auction is TypeSafeAuction {\n NonValidator nonValidator;\n\n function bet(uint _value) {\n bool valid = validateBet(nonValidator, _value); // TypeError: Invalid type for argument in function call.\n // Invalid implicit conversion from contract NonValidator\n // to contract Validator requested.\n }\n}","tokens":402,"squid":"spider-06","role":"Security Spider","at":1791345214193,"hash":"45e810e8262224403c42686c8f6414e78a6f13f9"}
{"url":"https://www.metaplex.com/docs/smart-contracts/token-metadata/guides/account-size-reduction","domain":"metaplex.com","title":"Token Metadata Account Size Reduction | Token Metadata Guides","text":"Token Metadata is a legacy program. It remains supported, but is not recommended for new projects. Use Core instead.On 10th of October 2024, a Metaplex Token Metadata (TM) program change was deployed to mainnet that reduces the size of all new metadata accounts created. Subsequently on October 25th, Metaplex introduced a new Resize instruction that enables existing metadata accounts to be resized. If your product fetches any metadata from TM, this change might affect you.What does it mean to \"resize\" an asset?Resizing an NFT enables the release of excess SOL not previously accessible without fully closing (aka burning) the Token Metadata (TM) accounts.Resize does not impact your NFT's functionality, they are simply optimized to free up space on the Solana network.However, as stated in the Developer FAQ, programs using SDK versions dating back to August and October 2023 will need to update to handle the smaller Token Metadata accounts.How many NFT accounts have been resized and how much SOL can I claim?As of August 15, 2025, all TM NFT metadata accounts have been resized.Holders of TM NFTs that had not already been resized at the time of the final optimization can claim 100% of the excess SOL attributed to their NFTs’ storage accounts at resize.metaplex.com. The claimable amounts include: 0.0023 excess SOL per Master Edition and 0.0019 excess SOL per Edition.What are the benefits of Resizing?The update reduces metadata account sizes, lowering the data storage cost, while making Solana lighter & more cost-efficient.The optimization saved a total of 7,380 MB of Solana network space, resulting in more efficient validator performance that benefits all Solana users and stakers.It was an important step in benefitting every Solana user and the validator infrastructure the network depends on.Where can I claim excess SOL with my NFTs?You can use our free UI at resize.metaplex.com to claim excess SOL attributed to your NFTs’ storage accounts. Per the Metaplex DAO’s approved MTP-004, the deadline to claim excess SOL is extended until at least Feb. 13th, 2027. This extends the total amount of time for NFT holders to claim excess SOL from the optimization to at least 28 months.Developer FAQWho is affected by the change?Every Program and Tool that is based on our Rust SDK and deserializes Data from the TM Accounts and is using very old SDK Versions might be affected. The specific versions can be found below.How much is the Size reduced?The Account sizes are reduced as you can see in the table below.AccountSize (bytes)New Size (bytes)Metadata679607Master Edition v128220Master Edition v228220Edition24142Which SDK Versions are affected?Javascript: The JS SDKs (both @metaplex-foundation/js and Umi-based SDKs) are not affectedRust: The Rust SDK became compatible over a Year ago starting with v2.0.0 (Available since August 2023)Anchor: Anchor 0.29 and above is compatible to the new sizes (Available since October 2023)How to make your Program compatible?If you are using an older SDK Version than listed above and deserializing Token Metadata Data it is recommended to update the used Packages to ensure compatibility.Where can I find Help and more Information?In case something is unclear after reading this FAQ please feel free to join our Discord and drop your questions!","tokens":827,"squid":"spider-10","role":"Tooling Spider","at":1791345229003,"hash":"cc50746bea3849c99870df6c6f7b7bff077d2632"}
{"url":"https://www.metaplex.com/docs/smart-contracts/token-metadata/guides/get-by-collection","domain":"metaplex.com","title":"Get Mints in a Collection | Token Metadata Guides","text":"Token Metadata is a legacy program. It remains supported, but is not recommended for new projects. Use Core instead.Metaplex Token Metadata has onchain collections to allow objective identifying of NFT collections instead of various subjective and potentially conflicting heuristics employed by the community in absence of an onchain standard.The specification design makes it very easy to look up any given NFT and determine if it is in a collection and if so, which collection, by simply reading the Collection fields from the metadata account. The onchain Metadata struct contains an option Collection struct which has a key field which is the Pubkey of the SPL token mint of the collection it belongs to.pub struct Metadata {\n pub key: Key,\n pub update_authority: Pubkey,\n pub mint: Pubkey,\n pub data: Data,\n // Immutable, once flipped, all sales of this metadata are considered secondary.\n pub primary_sale_happened: bool,\n // Whether or not the data struct is mutable, default is not\n pub is_mutable: bool,\n /// nonce for easy calculation of editions, if present\n pub edition_nonce: Option<u8>,\n /// Token Standard is deterministic and will change from SemiFungible to NonFungible if\n /// you call the create master edition call and it succeeds.\n pub token_standard: Option<TokenStandard>,\n /// Since we cannot easily change Metadata, we add the new DataV2 fields here at the end.\n /// Collection\n pub collection: Option<Collection>,\n...\n}\n\n#[derive(BorshSerialize, BorshDeserialize, PartialEq, Debug, Clone)]\npub struct Collection {\n pub verified: bool, // Whether or not the collection is verified\n pub key: Pubkey, // The SPL token mint account of the collection NFT\n}\nHowever, given a collection mint address, finding all NFTs that belong to that particular collection is significantly more difficult when reading directly from chain. There is one superior method using DAS and two basic approaches to get the data from chain directly.DAS APIFetching the mints using DAS is the superior method when using a RPC Provider that supports it.getAssetByGroup ExampleReplace the endpoint with your RPC URL and collection with the collection address you are looking for.import { publicKey } from '@metaplex-foundation/umi';\nimport { createUmi } from '@metaplex-foundation/umi-bundle-defaults';\nimport { dasApi } from '@metaplex-foundation/digital-asset-standard-api';\n\nconst endpoint = '<ENDPOINT>';\nconst collection = 'J2ZfLdQsaZ3GCmbucJef3cPnPwGcgjDW1SSYtMdq3L9p'\n\nconst umi = createUmi(endpoint).use(dasApi());\n\nconst assets = await umi.rpc.getAssetsByGroup({\n groupKey: 'collection',\n groupValue: collection,\n});\nconsole.log(assets.items.length > 0);\nYou can find more methods on DAS and additional Methods that allows fetching and filtering data in our DAS DocumentationGetProgramAccounts with PreCalculated OffsetsIt’s tempting to think we can simply use a getProgramAccounts call with an offset into the Collection struct to match the collection id against the key field. This is the same way that most client programs find, e.g. a snapshot of NFT mint accounts belonging to a specific candy machine or creator ID. However, due to the fact that edition_nonce, token_standard, and collection are all Rust Options, this gets significantly more complicated.Rust Options are represented in Borsh encoding with a 0 for the None variant and a 1 for the Some variant along with the normal encoding for whatever the contained value of the Some variant is. (One byte for a u8, for example.) This means that we can’t calculate an offset into the Collection struct without knowing what variant type is in each two of the two Options prior to the Collection field.There are two ways to do this: brute force and gathering a priori knowledge of the variants.Brute force requires computing all the possible variants and running multiple getProgramAccount calls in parallel. Given up to five creators in the creators array and two possible options for each of the two Option fields prior to Collection, that leads to a total number of 20 possible combinations, meaning that you would have to make 20 getProgramAccount calls with various offsets to take this approach. This is obviously not a feasible nor scalable approach. If some a priori information is known about a collection though, this can be reduced to a smaller number of calls. Knowing how many creators there are is the biggest gain, reducing the number of getProgramAccount calls down to only four which can be reasonably run in parallel.This approach is not the recommended one due to the high number of edge cases it involves and the fact that it can only be pragmatically used on collections where there is only one creator or the number of variations of how many creators there are is known ahead of time.Instead, we recommend using the transaction crawling approach.Transaction CrawlingTransaction crawling involves getting all the transactions associated with the collection mint address and then parsing them to find the specific instructions that create collections. From there we can determine which mint accounts are part of the collection.The algorithm for doing this is shown below:Call [getSignaturesForAddress](https://docs.solana.com/developing/clients/jsonrpc-api#getsignaturesforaddress) for the collection mint address to get all transaction signatures that in anyway involved the collection mint address.For each signature, call [getTransaction](https://docs.solana.com/developing/clients/jsonrpc-api#gettransaction) to get the actual transaction data for each signature.Parse the transactions to find the program ids and filter out any that do not involve the token-metadata program which has an address of metaqbxxUerdq28cj1RbAWkYQm3ybzjb6a8bt518x1s.We only want to retrieve collection members that are verified, and the only two handlers in the token-metadata that verify collection members are verify_collection and set_and_verify which have the respective positions in the MetadataInstruction enum of 18 and 25, which are base58 values of K and S.Filter the instructions to only have ones with a data value of K or S to insure we only get those specific token-metadata handlers.The metadata address being verified will be the first account passed into either of these handlers.Add the metadata address to a Set to ensure no duplicates.Once all metadata address are found, loop over them and call getAccountInfo to find the account data.Deserialize the account data into a Metadata struct/object, and find the mint address from the mint field. Add the mint address to a Set.This final Set is your list of mint addresses for all items in the collection.Example Rust and TypeScript code for transaction crawling to get collection members can be found in the get-collection repository.","tokens":1690,"squid":"spider-10","role":"Tooling Spider","at":1791345239790,"hash":"da57e7d7c7e94c25beabd73b67b03aa61f716ec6"}
{"url":"https://developer.arbitrum.io/launch-arbitrum-chain/operate/key-rotation","domain":"developer.arbitrum.io","title":"Arbitrum Node Key Rotation Guide","text":"Operate your chainArbitrum Node Key Rotation GuideLearn how to rotate keys for the different roles in your Arbitrum chain.Request an updateThis guide covers how to rotate keys for different roles in your Arbitrum Orbit chain: batch poster, validator/bonder, and Data Availability Servers (DAS).\nImportant Prerequisites\nBackup: Always back up your current configuration and private keys before starting\nTesting: Test key rotation on a testnet environment first, if possible\nDowntime: Plan for potential brief service interruptions during the rotation process\nPermissions: Ensure you have the necessary permissions to call the required smart contract functions\n\n1. Batch poster key rotation\nCritical warningFor sequencer nodes running both the sequencer and batch poster on the same server, you must first split them and then configure Redis for message synchronization. Failure to do so may cause chain reorganizations. Refer to the High Availability Sequencer documentation for setup instructions.\nPrerequisites\n\nA new batch poster account funded with sufficient ETH for gas fees\nAccess to call functions on the SequencerInbox contract\nGracefully stop the current batch poster\n\nGenerate new batch poster keys\n1. Enable the new batch poster\nCall the following function on the SequencerInbox contract. The caller must be the rollup owner or the batch poster manager.\nsetIsBatchPoster(<new_address>, true)\nIf you also want to transfer the batch poster manager role to a new address, the rollup owner must call:\nsetBatchPosterManager(<new_address>)\n2. Update the node configuration\n\nUpdate your node configuration to use the new private key\nRestart the batch poster service with the new configuration\n\n3. Verify operation\n\nMonitor logs to confirm the new batch poster is successfully submitting batches\nCheck that transactions are processing normally\n\n4. Disable the old batch poster\nsetIsBatchPoster(<old_address>, false)\n2. Validator/bonder key rotation\nPrerequisites\n\nA new validator account funded with sufficient ETH\nThe required bond amount available for the new validator\nAccess to call functions on the Rollup contract\n\nActivate new keys\n1. Enable new validator\nCall the following function on the RollupAdminLogic contract. The caller must be the rollup owner.\nNote that setValidator accepts arrays, allowing you to enable or disable multiple validators in a single call.\nsetValidator([<new_validator_address>], [true])\n2. Update the node configuration\n\nUpdate your validator node configuration to use the new private key\nRestart the validator service\n\n3. Verify the new validator operation\n\nMonitor that the new validator successfully posts bond transactions\nConfirm that assertion and confirmation transactions are submitted successfully\n\n4. Disable the old validator\nsetValidator([<old_validator_address>], [false])\n6. Recover old validator bond (if applicable)\n\nWait for your old validator's latest bond assertion to be confirmed\nCall reduceDeposit(0) on the RollupUserLogic contract to reduce the bond to zero\nCall withdrawStakerFunds() on the RollupUserLogic contract to withdraw the released funds\n\n3. AnyTrust Data Availability Committee (DAC) rotation\nPrerequisites\n\nA new DAC keyset generated\nAccess to call functions on the SequencerInbox contract\n\nGenerate, deploy, and verify new DAC keys\n1. Generate a new keyset\n\nFollow the Generate Keyset documentation with your new group of DAS servers\nEnsure that all new DASs are properly configured and accessible\n\n2. Register the new keyset onchain\nCall the following function on the SequencerInbox contract. The caller must be the rollup owner.\nsetValidKeyset(<new_keyset_bytes>)\nNoteThe setValidKeyset function takes the raw keyset bytes as its only parameter. The assumed-honest count is encoded within the keyset bytes themselves during keyset generation — it is not a separate contract parameter.\n3. Deploy new DAS servers\n\nStart the new DAS with the updated configuration\nVerify they are accessible and responding to health checks\n\n4. Verify integration\n\nMonitor that the batch poster can successfully write batches to the new DAS servers\nCheck DAS server logs for successful data storage operations\nConfirm data availability requests are getting handled successfully\n\n5. Invalidate the old keyset (optional)\nOnce the new DAS servers and keyset are fully verified, you can optionally invalidate the old keyset to prevent it from being used. Call the following function on the SequencerInbox contract. The caller must be the rollup owner.\ninvalidateKeysetHash(<old_keyset_hash>)\nNoteAfter invalidating the old keyset, you must stop and restart the batch poster so it picks up the new keyset. If you skip this step, the batch poster will continue attempting to use the old (now invalid) keyset and fail to submit batches.\nWarning\nYou can obtain the old keyset hash from the SetValidKeyset event that was emitted when the old keyset was originally registered\nDo not invalidate the old keyset until the new keyset is fully verified and the batch poster is successfully posting with the new DAS servers — invalidating prematurely can disrupt data availability for your chain\nAfter invalidation, the old keyset can no longer be used to certify data availability certificates\nHow is this guide?Error indexAn index of error and log messages emitted by Arbitrum chain infrastructure, mapping each message to the guide that explains its cause and resolution.Monitoring tools and considerationsTools available to monitor an Arbitrum chain, and a component-by-component reference of the metrics, signals, and thresholds to watch for the sequencer, batch poster, validator, and chain fees.","tokens":1410,"squid":"spider-01","role":"Chain Spider","at":1791345239845,"hash":"168efe9cc172872f0bd0bcfa534686d6940f19da"}
{"url":"https://www.metaplex.com/docs/smart-contracts/token-metadata/guides","domain":"metaplex.com","title":"Guides | Token Metadata","text":"Token Metadata is a legacy program. It remains supported, but is not recommended for new projects. Use Core instead.The following guides for MPL Token Metadata are currently available:Get Mints by CollectionSnippets to fetch NFTs by CollectionCreate an NFTCreate your very own NFT using JavascriptAccount Size ReductionLearn more about the TM Account Size ReductionCreate a claim based airdrop using MPL-DistroPersist Merkle proofs, run a claim page or API, and recover unclaimed tokens with MPL-Distro.Token Claimer Smart ContractLearn how to create a Token Claimer Smart Contract on Solana leveraging Merkle Trees and using Anchor!","tokens":158,"squid":"spider-10","role":"Tooling Spider","at":1791345250627,"hash":"b265894f6f0c976941f4cae783bc6ef35c9b4a66"}
{"url":"https://developer.arbitrum.io/launch-arbitrum-chain/operate/monitoring","domain":"developer.arbitrum.io","title":"Monitoring tools and considerations","text":"Operate your chainMonitoring tools and considerationsTools available to monitor an Arbitrum chain, and a component-by-component reference of the metrics, signals, and thresholds to watch for the sequencer, batch poster, validator, and chain fees.Request an updateWhen deploying and maintaining an Arbitrum chain, there are several key elements that need to be monitored. This page has two parts:\n\nMonitoring tools — scripts and services available to chain maintainers.\nWhat to monitor, by component — a reference of the specific metrics, onchain signals, and thresholds to watch for each part of the stack (, , , and chain fees), plus deployment and hardware guidance.\n\nThe metric names in this page are the internal Nitro metric paths (for example, arb/sequencer/backlog). On the Prometheus scrape endpoint, each / is replaced with _ (so arb/sequencer/backlog is scraped as arb_sequencer_backlog). See Enabling Nitro metrics for how to expose them.\nArbitrum chain verification script\nThe Arbitrum chain verification script retrieves information from an Arbitrum chain and its to verify that all parameters are configured correctly. After gathering the data, it generates a comprehensive report and issues warnings for any discrepancies detected. This tool is particularly useful after deploying and configuring an Arbitrum chain, to make sure that the onchain information has been correctly set.\nNoteThe Arbitrum chain verification script is currently under active development and is considered a work-in-progress (WIP). Consequently, its findings should be approached with caution, as there is a potential for false positives.\nThe arbitrum-monitoring alerting suite\nThe arbitrum-monitoring repository provides five ready-to-run monitoring scripts that watch the critical liveness signals of an Arbitrum chain and can send alerts to Slack, with more monitors under active development. All monitors read your chain's parameters (RPC endpoints and core contract addresses) from a shared config.json file, and can be run once (for example, on a schedule) or continuously.\nRetryable monitor\nRetryable tickets are messages sent from a parent chain and executed on the Arbitrum chain. Due to their asynchronous nature (they are executed several minutes after being created), if insufficient funds are provided at the time of creation, they might not automatically redeem (execute) upon arrival at the Arbitrum chain. When this occurs, a manual redemption of the ticket is required.\nThe retryable monitor tracks these tickets from creation through execution: it watches for ticket creation events on the parent chain, then checks each ticket's status on the Arbitrum chain — automatically redeemed, manually redeemed, still pending, or failed. It alerts on tickets that failed to redeem automatically and on tickets approaching their seven-day expiration window, so that no cross-chain message expires unexecuted.\nBatch poster monitor\nThe batch poster monitor tracks batch posting activity and data availability. It alerts when no batches have been posted within the chain's expected time bounds while user transactions are pending, when the batch poster account balance falls below an estimate of about three days of posting costs, and when a backlog of unposted blocks accumulates. For AnyTrust chains, it also detects when the chain has fallen back to posting full calldata on the parent chain instead of , which indicates a problem with the .\nAssertion monitor\nThe assertion monitor tracks the creation and confirmation of on the chain's Rollup contract, supporting both BoLD and legacy (pre-BoLD) chains. It alerts when no assertions are being created despite chain activity, when assertions remain unconfirmed after the challenge period has elapsed, and on validator-related risks such as low validator participation, a base stake below the expected threshold on BoLD chains, or a disabled validator allowlist on legacy chains.\nArbOS version monitor\nThe ArbOS version monitor checks that every monitored chain is running at least a minimum version, by querying the ArbSys on each chain. It alerts when a chain reports a version below the configured minimum, and when the chain's RPC endpoint is unavailable or returns an invalid value, since such a chain cannot be monitored.\nNode sync monitor\nThe node sync monitor checks the health of your operator-run nodes by comparing each node against a trusted reference RPC endpoint for the same chain, such as the chain's public gateway. A node is considered healthy when it reports fully synced and its head is within a configurable number of blocks of the reference. Comparing against an independent reference correctly handles chains that produce blocks on demand: a stuck node shows growing lag against the reference, while an idle chain stays equal. Note that the comparison is only as reliable as the reference: if the reference RPC itself fails or falls behind, the monitor's results may be inaccurate, so point it at infrastructure independent of the monitored nodes.\nData Availability Server (DAS) health checks\nIf you've deployed an AnyTrust chain with a Data Availability Committee, it is recommended to actively monitor the endpoints of the different configured DA servers. The How to deploy a DAS guide contains a section for testing both the RPC and REST endpoints of any given DAS, by using the anytrusttool available in .\nEnabling Nitro metrics\nMost of the signals below are exposed as Prometheus-compatible metrics by the Nitro node. Start the node with the --metrics flag to enable the metrics server, then scrape the endpoint at http://<metrics-server.addr>:<metrics-server.port>/debug/metrics/prometheus (default port 6070):\nnitro --metrics \\\n --metrics-server.addr 0.0.0.0 \\\n --metrics-server.port 6070\nFor metrics-server flags, memory-related metrics, health-check patterns, and Kubernetes ServiceMonitor examples, see Node tuning and monitoring.\nThe signals that are not Nitro metrics — onchain events and account balances on the parent chain — are called out explicitly in each table below.\nWhat to monitor, by component\nThe sections below group the elements to monitor by the component they belong to. Each table lists the signal, where it comes from, what it means, and a suggested condition to alert on. Suggested alert thresholds are starting points; tune them to your chain's activity and settlement layer.\nSequencer\nThe sequencer accepts , orders them, and produces blocks. Two different \"backlogs\" are often confused: the sequencer's transaction backlog (transactions received but not yet sequenced into blocks) and the batcher backlog (sequenced messages not yet posted to the parent chain). They are separate metrics and live in separate components — the batcher backlog is covered under Batch poster.\nSignalSourceWhat it meansSuggested alertarb/sequencer/backlogNitro metric (sequencer)The sequencer's transaction backlog: transactions accepted but not yet included in a block. A sign of network health.Sustained growth over several minutesarb/sequencer/activeNitro metric (sequencer)Whether this node is currently the active sequencer. Useful when running a sequencer coordinator with failover.Value flaps, or no node reports activearb/feed/backlog/messagesNitro metric (nodes with feed output enabled — the sequencer or a relay)Messages retained by the broadcast server until it sees them covered by batches on the parent chain. Growth means batches aren't landing — not that a follower is lagging.Sustained growtheth_syncing fieldsRPC (any node)While a node is syncing, eth_syncing returns fields such as batchSeen, batchProcessed, msgCount, and blockNum. See caveats below.batchSeen − batchProcessed keeps growing\nWarningeth_syncing returns false once a node is fully synced, so it is useful for tracking a node that is catching up, not for steady-state health. Its out-of-sync output is not a stable API and can change between Nitro versions, so do not build production alerting on the exact field shape. For a fully synced node, use the metrics above and an RPC liveness check (an eth_chainId call returning HTTP 200) instead. See eth_syncing for the full field reference.\nBatch poster\nThe batch poster (the \"batcher\") posts sequenced transactions to the contract on the parent chain as batches. It needs a funded account and must keep landing batches, or the chain's data stops being published to the parent chain.\nSignalSourceWhat it meansSuggested alertarb/batchposter/estimated_batch_backlogNitro metric (batch poster)The batcher backlog: sequenced batches waiting to be posted to the parent chain.Sustained growth over several minutesarb/batchposter/wallet/ethNitro metric (batch poster)The batch poster account balance, in ether. Monitor fund usage directly from this metric.Below your funding thresholdarb/inbox/latest/batchNitro metric (any node)The latest batch number the node has seen in the SequencerInbox. Stalls if batches stop landing.No increase while the chain has activitySequencerBatchDelivered eventParent chain (SequencerInbox)Emitted each time a batch is delivered onchain. The onchain that batches are landing.No event within your expected posting interval\nTipMonitor the batch poster account balance directly through arb/batchposter/wallet/eth (and the validator balance through arb/staker/balance, below) rather than estimating monthly spend from configs and gas multipliers. Direct balance monitoring reflects real usage; config-based estimation drifts from reality as parent-chain fees move. There is no automatic mechanism to refund these accounts, so keep them overfunded and alert well before they run dry.\nIf batches stop being posted, see Batch poster troubleshooting for common causes and tuning flags.\nValidator\nValidators post and confirm (historically called \"RBlocks\" or \"nodes\") of the chain's state to the Rollup contract on the parent chain. The metrics differ depending on whether your chain runs the legacy staker or the BoLD staker.\nNoteIf you are relying on arb/staker/action/last_success and seeing it go stale for long periods even while assertions are being created, this is expected on two counts. First, that gauge updates each time the staker successfully acts — during periods when the staker has no action to take, it stays flat even though the validator is healthy and polling. Second, it is a legacy-staker metric; on BoLD chains, assertion activity is tracked by the arb/validator/poster/* and arb/validator/scanner/* metrics instead. Prefer the assertion-progress and failure signals below over last_success as your primary health check, and corroborate with the onchain assertion events.\nSignalSourceWhat it meansSuggested alertarb/staker/staked_nodeNitro metric (legacy staker)The latest assertion this validator has staked on. Should advance as the chain progresses.No advance while the chain has activityarb/staker/confirmed_nodeNitro metric (legacy staker)The latest confirmed assertion this validator sees.Stalls unexpectedlyarb/staker/action/failureNitro metric (legacy staker)Counter of failed staker actions. A better failure signal than a stale last_success gauge.Any sustained increasearb/staker/balanceNitro metric (staker)The validator account balance, in ether. Monitor fund usage directly.Below your funding thresholdarb/validator/poster/assertion_postedNitro metric (BoLD staker)Counter of assertions posted by this validator. The primary \"assertions are being made\" signal on BoLD chains.No increase while the chain has activityarb/validator/poster/error_posting_assertionNitro metric (BoLD staker)Counter of errors while posting assertions.Any sustained increasearb/validator/scanner/latest_confirmed_assertion_block_numberNitro metric (BoLD staker)Parent-chain block number of the latest confirmed assertion.No advance over an extended periodarb/validator/validations/failedNitro metric (any validator)Counter of failed block validations.Any sustained increaseNodeCreated or AssertionCreated eventsParent chain (Rollup contract)The onchain confirmation that assertions are being created. Watch alongside the metrics above.No event over an extended period\nWarningLong periods of inactivity can disable the validator allowlist. If the latest confirmed assertion (or its first child, once one exists) is older than validatorAfkBlocks parent-chain blocks, the Rollup contract's validator allowlist can be permissionlessly disabled. validatorAfkBlocks is configured per chain — read it from your Rollup contract; a value of 0 disables this mechanism entirely. Alert on assertion inactivity well before this window elapses. For example, on Arbitrum One validatorAfkBlocks is set to 201600 (~28 days of parent-chain blocks).This applies regardless of disableValidatorWhitelist. Setting disableValidatorWhitelist to false keeps your chain permissioned in normal operation but does not protect the allowlist from this escape hatch. To learn how the two parameters interact, and why any deliberate validator pause counts toward this window, see Keeping validation permissioned across the upgrade.\nIf assertions stop being posted or confirmed, see Validator troubleshooting for common causes and tuning flags.\nChain fees and load\nThe chain's base fee is a useful signal of sustained demand. An Arbitrum chain has a (also called the speed limit), measured in gas per second, that acts as a threshold for pricing. When cumulative usage exceeds it, a backlog of excess gas accumulates and the L2 base fee rises using an approach similar to Ethereum's EIP-1559 pricing algorithm. The default gas target is 7,000,000 gas per second as of ArbOS 6 (it was 1,000,000 in ArbOS 0). A sustained base-fee spike therefore indicates demand is exceeding the speed limit — as a rough guide, 7M gas per second is on the order of 330 simple transfers per second, though the exact transactions-per-second figure depends on the gas cost of the transactions being run.\nSignalSourceWhat it meansSuggested alertarb/block/basefeeNitro metric (any node)The current base fee. Spikes above the minimum indicate the chain is congested.Sustained elevation above baselineArbGasInfo.getGasBacklog() (RPC)The backlogged amount of gas burnt in excess of the speed limit. Drives the base fee up.Sustained growthArbGasInfo.getGasAccountingParams()Precompile (RPC)Returns the chain's speed limit, pool size, and block gas limit. Use to confirm configuration.Values differ from expected configurationArbGasInfo.getGasPricingConstraints()Precompile (RPC)Returns the configured gas pricing constraints. An empty array means the chain uses a single gas target.Values differ from expected configuration\nFor guidance on choosing a gas target, see Manage gas target. If a sustained spike means your chain has outgrown its current target, follow how to set the gas target.\nDeployment guidance\nDo not run the sequencer and a validator on the same node. They have different resource profiles and different failure modes, and co-locating them means a single machine failure takes down both liveness (sequencing) and safety (validation) at once. Running them separately also keeps their funding and monitoring independent:\n\nThe batch poster account (arb/batchposter/wallet/eth) pays to post batches to the parent chain.\nEach validator account (arb/staker/balance) pays to post and confirm assertions.\n\nFund and alert on each account separately, and keep each overfunded — there is no automatic top-up mechanism for either.\nAppendix: reference hardware specifications\nThe following are the canonical hardware specifications used by Offchain Labs for Arbitrum One nodes. Treat them as a reference point for sizing your own chain; requirements scale with your chain's activity and history.\nRolevCPU / coresRAMStorageReference instanceSequencer10 cores90 GB6.6 TB NVMei7ie.3xlargeArchive2 cores40 GB16 TB—Validator3 cores32 GB4 TB—RPC4 cores32 GB——\nFast, locally attached NVMe SSD storage is strongly recommended, especially for the sequencer and archive nodes, because disk latency directly affects performance as read volume grows. See State growth for more on storage sizing over time.How is this guide?Node Key Rotation GuideLearn how to rotate keys for the different roles in your Arbitrum chain.Ownership structure and access controlOverview of the technical architecture of chain ownership affordances on Arbitrum chains.","tokens":4081,"squid":"spider-01","role":"Chain Spider","at":1791345250676,"hash":"b142514a58c3bef2a4603c9e520f833afaf227e7"}
{"url":"https://www.metaplex.com/docs/smart-contracts/core/external-plugins/oracle","domain":"metaplex.com","title":"Oracle Plugin | Metaplex Core","text":"The Oracle Plugin connects Core Assets to external Oracle accounts for custom validation logic. Reject transfers, burns, or updates based on time, price, ownership, or any custom rule you implement. What You'll LearnCreate Oracle accounts for validationConfigure lifecycle checks (reject transfers, updates, burns)Use PDA-based Oracle addressingDeploy time-based and condition-based restrictionsSummaryThe Oracle Plugin validates lifecycle events against external Oracle accounts. The Oracle account stores validation results that the Core program reads to approve or reject operations.Can reject create, transfer, burn, and update eventsOracle account is external to the Asset (you control it)Dynamic: update the Oracle account to change behaviorSupports PDA derivation for per-asset or per-owner oraclesOut of ScopeAppData storage (see AppData Plugin), built-in freeze behavior (see Freeze Delegate), and off-chain oracles.Quick StartJump to: Oracle Account Structure · Create with Oracle · Add to Asset · Default OraclesDeploy an Oracle account with validation rulesAdd Oracle plugin adapter to Asset/CollectionConfigure lifecycle checks (which events to validate)Update Oracle account to change validation behavior dynamicallyWhat is an Oracle Plugin?An Oracle Plugin is an onchain account that is created by the authority externally from the MPL Core Asset or Collection. If an Asset or Collection has an Oracle Adapter enabled and an Oracle Account assigned to it the Oracle Account will be loaded by the MPL Core program for validations against lifecycle events. The Oracle Plugin stores data relating to 4 lifecycle events of create, transfer, burn, and update and can be configured to perform a Reject validation. The ability to update and change the Oracle Account provides a powerful and interactive lifecycle experience.Works WithMPL Core Asset✅MPL Core Collection✅Allowed ValidationsThe following validation results can be returned from the Oracle Account to the Oracle Plugin.Can Approve❌Can Reject✅Can Pass❌On Chain Oracle Account StructureThe Oracle Account should have the following onchain account structure.On Chain Account Struct of Oracle Account#[account]\npub struct Validation {\n pub validation: OracleValidation,\n}\nimpl Validation {\n pub fn size() -> usize {\n 8 // anchor discriminator\n + 5 // validation\n }\n}\npub enum OracleValidation {\n Uninitialized,\n V1 {\n create: ExternalValidationResult,\n transfer: ExternalValidationResult,\n burn: ExternalValidationResult,\n update: ExternalValidationResult,\n },\n}\npub enum ExternalValidationResult {\n Approved,\n Rejected,\n Pass,\n}\nOracle Account OffsetThe account structure will differ slightly between account frameworks (Anchor, Shank, etc.) due to the discriminator sizes needed for accounts:If the OracleValidation struct is located at the beginning of the data section for the Oracle account, then choose NoOffset for the ValidationResultsOffset.If the Oracle account only contains the OracleValidation struct but is managed by an Anchor program, select Anchor for ValidationResultsOffset so that the struct can be located after the Anchor account discriminator.If the OracleValidation struct is located at some other offset in the Oracle account, use the Custom offset.resultsOffset / result_offsetconst resultsOffset: ValidationResultsOffset =\n | { type: 'NoOffset' }\n | { type: 'Anchor' }\n | { type: 'Custom'; offset: bigint };\nUpdating the Oracle AccountBecause the Oracle Account is created and maintained by the creator/developer the OracleValidation struct can be updated at anytime allowing lifecycles to be dynamic.The Oracle AdapterThe Oracle Adapter accepts the following arguments and data.On Chain Structpub struct Oracle {\n /// The address of the oracle, or if using the `pda` option,\n /// a program ID from which to derive a PDA.\n pub base_address: Pubkey,\n /// Optional account specification (PDA derived from `base_address` or other\n /// available account specifications). Note that even when this\n /// configuration is used there is still only one\n /// Oracle account specified by the adapter.\n pub base_address_config: Option<ExtraAccount>,\n /// Validation results offset in the Oracle account.\n /// Default is `ValidationResultsOffset::NoOffset`\n pub results_offset: ValidationResultsOffset,\n}\nDeclaring the PDA of an Oracle PluginThe default behavior of the Oracle Plugin Adapter is to supply the adapter with a static base_address which the adapter can then read from and provide the resulting validation results. If you wish to get more dynamic with the Oracle Plugin Adapter you can pass in your program_id as the base_address and then an ExtraAccount, which can be used to derive one or more PDAs pointing to Oracle Account addresses. This allows the Oracle Adapter to access data from multiple derived Oracle Accounts. Note that there are other advanced non-PDA specifications also available when using ExtraAccount.List of ExtraAccounts OptionsAn example of an extra account that is the same for all assets in a collection is the PreconfiguredCollection PDA, which uses the collection's Pubkey to derive the Oracle account. An example of more dynamic extra account is the PreconfiguredOwner PDA, which uses the owner pubkey to derive the Oracle account.pub enum ExtraAccount {\n /// Program-based PDA with seeds \\[\"mpl-core\"\\]\n PreconfiguredProgram {\n /// Account is a signer\n is_signer: bool,\n /// Account is writable.\n is_writable: bool,\n },\n /// Collection-based PDA with seeds \\[\"mpl-core\", collection_pubkey\\]\n PreconfiguredCollection {\n /// Account is a signer\n is_signer: bool,\n /// Account is writable.\n is_writable: bool,\n },\n /// Owner-based PDA with seeds \\[\"mpl-core\", owner_pubkey\\]\n PreconfiguredOwner {\n /// Account is a signer\n is_signer: bool,\n /// Account is writable.\n is_writable: bool,\n },\n /// Recipient-based PDA with seeds \\[\"mpl-core\", recipient_pubkey\\]\n /// If the lifecycle event has no recipient the derivation will fail.\n PreconfiguredRecipient {\n /// Account is a signer\n is_signer: bool,\n /// Account is writable.\n is_writable: bool,\n },\n /// Asset-based PDA with seeds \\[\"mpl-core\", asset_pubkey\\]\n PreconfiguredAsset {\n /// Account is a signer\n is_signer: bool,\n /// Account is writable.\n is_writable: bool,\n },\n /// PDA based on user-specified seeds.\n CustomPda {\n /// Seeds used to derive the PDA.\n seeds: Vec<Seed>,\n /// Program ID if not the base address/program ID for the external plugin.\n custom_program_id: Option<Pubkey>,\n /// Account is a signer\n is_signer: bool,\n /// Account is writable.\n is_writable: bool,\n },\n /// Directly-specified address.\n Address {\n /// Address.\n address: Pubkey,\n /// Account is a signer\n is_signer: bool,\n /// Account is writable.\n is_writable: bool,\n },\n}\nCreating and Adding Oracle PluginsCreating an Asset with the Oracle PluginCreate a MPL Core Asset with an Oracle Pluginimport { generateSigner, publicKey } from '@metaplex-foundation/umi'\nimport {\n create,\n CheckResult\n} from '@metaplex-foundation/mpl-core'\nconst collectionSigner = generateSigner(umi)\nconst oracleAccount = publicKey('11111111111111111111111111111111')\nconst asset = await create(umi, {\n ... CreateAssetArgs,\n plugins: [\n {\n type: 'Oracle',\n resultsOffset: {\n type: 'Anchor',\n },\n baseAddress: oracleAccount,\n lifecycleChecks: {\n update: [CheckResult.CAN_REJECT],\n },\n baseAddressConfig: undefined,\n },\n ],\n });.sendAndConfirm(umi)\nAdding an Oracle Plugin to An AssetAdding an Oracle Plugin to a Collectionimport { publicKey } from '@metaplex-foundation/umi'\nimport { addPlugin, CheckResult } from '@metaplex-foundation/mpl-core'\nconst asset = publicKey('11111111111111111111111111111111')\nconst oracleAccount = publicKey('22222222222222222222222222222222')\naddPlugin(umi, {\n asset,\n plugin: {\n type: 'Oracle',\n resultsOffset: {\n type: 'Anchor',\n },\n lifecycleChecks: {\n create: [CheckResult.CAN_REJECT],\n },\n baseAddress: oracleAccount,\n },\n})\nCreating a Collection with an Oracle PluginCreating a Collection with an Oracle Pluginimport { generateSigner, publicKey } from '@metaplex-foundation/umi'\nimport {\n create,\n CheckResult\n } from '@metaplex-foundation/mpl-core'\nconst collectionSigner = generateSigner(umi)\nconst oracleAccount = publicKey('11111111111111111111111111111111')\nconst collection = await createCollection(umi, {\n ... CreateCollectionArgs,\n plugins: [\n {\n type: 'Oracle',\n resultsOffset: {\n type: 'Anchor',\n },\n baseAddress: oracleAccount,\n lifecycleChecks: {\n update: [CheckResult.CAN_REJECT],\n },\n baseAddressConfig: undefined,\n },\n ],\n });.sendAndConfirm(umi)\nAdding an Oracle Plugin to a CollectionAdding an Oracle Plugin to a Collectionimport { publicKey } from '@metaplex-foundation/umi'\nimport { addCollectionPlugin, CheckResult } from '@metaplex-foundation/mpl-core'\nconst collection = publicKey('11111111111111111111111111111111')\nconst oracleAccount = publicKey('22222222222222222222222222222222')\nawait addCollectionPlugin(umi, {\n collection: collection,\n plugin: {\n type: 'Oracle',\n resultsOffset: {\n type: 'Anchor',\n },\n lifecycleChecks: {\n update: [CheckResult.CAN_REJECT],\n },\n baseAddress: oracleAccount,\n },\n}).sendAndConfirm(umi)\nDefault Oracles deployed by MetaplexIn some rare cases like Soulbound NFT it might be useful to have Oracles that always Deny or Approve a lifecycle event. For those the following Oracles have been deployed and can be used by anyone:Transfer Oracle: Always denies transferring. AwPRxL5f6GDVajyE1bBcfSWdQT58nWMoS36A1uFtpCZYUpdate Oracle: Always denies updating. 6cKyMV4toCVCEtvh6Sh5RQ1fevynvBDByaQP4ufz1Zj6Create Oracle: Always denies creating. 2GhRFi9RhqmtEFWCwrAHC61Lti3jEKuCKPcZTfuujaGrExample Usage/IdeasExample 1Assets to be not transferable during the hours of noon-midnight UTC.Create onchain Oracle Plugin in a program of your choice.Add the Oracle Plugin Adapter to an Asset or Collection specifying the lifecycle events you wish to have rejection validation over.You write a cron that writes and updates to your Oracle Plugin at noon and midnight flipping a bit validation from true/false/true.Example 2Assets can only be updated if the floor price is above $10 and the asset has attribute “red hat”.Create onchain Oracle Plugin in a program of your choice.Add the Oracle Plugin Adapter to Asset specifying the lifecycle events you wish to have rejection validation over.Dev writes Anchor program that can write to the Oracle Account that derive the same PRECONFIGURED_ASSET accountsDev writes web2 script that watches prices on a marketplace, AND with known hashlist of Assets with the 'Red Hat' trait red updates and writes to the relevant Oracle Accounts.Common ErrorsOracle validation failedThe Oracle account returned a rejection. Check your Oracle account state and validation logic.Oracle account not foundThe Oracle account address is invalid or doesn't exist. Verify the base address and any PDA derivation.Invalid results offsetThe ValidationResultsOffset doesn't match your Oracle account structure. Use Anchor for Anchor programs, NoOffset for raw accounts.NotesOracle accounts are external. You deploy and maintain themValidation is read-only: Core reads the Oracle, doesn't write to itUse cron jobs or event listeners to update Oracle state dynamicallyPDA derivation allows per-asset, per-owner, or per-collection oraclesFAQCan Oracle plugins approve transfers, or only reject?Oracle plugins can only reject or pass. They cannot force-approve transfers that other plugins reject.How do I create time-based transfer restrictions?Deploy an Oracle account and use a cron job to update the validation result at specific times. See Example 1 above.Can I use one Oracle for multiple Assets?Yes. Use a static base address for a single Oracle, or use PDA derivation with PreconfiguredCollection for collection-wide validation.What's the difference between Oracle and Freeze Delegate?Freeze Delegate is built-in and binary (frozen/unfrozen). Oracle allows custom logic—time-based, price-based, or any condition you implement.Do I need to write a Solana program for Oracle?Yes. The Oracle account must be a Solana account with the correct structure. You can use Anchor or native Rust. See the Oracle Plugin Example guide.GlossaryTermDefinitionOracle AccountExternal Solana account storing validation resultsOracle AdapterPlugin component attached to Asset referencing the OracleValidationResultsOffsetByte offset to locate validation data in Oracle accountExtraAccountPDA derivation configuration for dynamic Oracle addressingLifecycle CheckConfiguration specifying which events the Oracle validatesRelated PagesExternal Plugins Overview - Understanding external pluginsAppData Plugin - Data storage instead of validationOracle Plugin Example - Complete implementation guideFreeze Delegate - Built-in freeze alternative","tokens":3186,"squid":"dotcat","role":"Tooling Spider","at":1791345254288,"hash":"98a9ec110ca6e23612facc830d2407f065b486f3"}
{"url":"https://developer.arbitrum.io/launch-arbitrum-chain/operate/post-launch-deployments","domain":"developer.arbitrum.io","title":"Post-launch deployment of deterministic contracts","text":"Operate your chainPost-launch deployment of deterministic contractsLearn about deploying contracts like Multicall3 to an Arbitrum chain after launch using sendL2Message, without needing a chain upgrade or predeploy.Request an updateSome forms of contract deployment rely on pre-made transactions with hardcoded gas limits designed for non-Arbitrum chains that only cover execution gas. Since Arbitrum also charges for data posting, these limits may be too low, causing transactions to fail. This page describes a safe, permissionless post-launch deployment method for such cases.\nUsing this approach, you can deploy contracts like Multicall3, the EntryPoint contract, or a create2 factory to a live Arbitrum chain without needing to modify chain configuration. It leverages Arbitrum's cross-chain messaging infrastructure via the Inbox.sendL2Message function, which submits a pre-signed child chain transaction from the parent chain. Unlike retryable tickets, these messages incur parent chain data fees only at submission and aren’t subject to the 100,000 gas cap imposed on deterministic deployment flows.\nWhen to use this method\nThis approach is useful when:\n\nYour Arbitrum chain is already live.\nYou want to deploy a contract at a specific address (e.g., using create2).\nThe chain's genesis configuration did not include the contract.\n\nCommon examples include deployments of contracts like Multicall3, the ERC-4337 EntryPoint contract, or a create2 factory/deterministic deployment proxy.\nNote that if deployFactoriesToL2 is set to true when calling createRollup(), the following contracts are deployed to the Arbitrum chain by default:\n\nMulticall3\nDeterministicDeploymentProxy\nERC-4337 EntryPoint\nCREATE3Deployer\n\nOverview\nTo deploy a contract post-launch:\n1. Fund the deployer address on the child chain:\nSend ETH to the child chain address that will send the deployment transaction. Funding is possible using a retryable ticket or Parent-to-Child chain deposit.\n2. Create the signed child chain transaction:\nConstruct and sign a raw child chain transaction that performs the contract deployment (e.g., using create2). DeployHelper.sol can be used as a reference for formatting the transaction.\n3. Send the message from the parent chain:\nCall Inbox.sendL2Message(bytes calldata message) on the Arbitrum chain’s inbox contract. Provide the signed transaction as the input.\n4. Wait for the transaction to be executed on the child chain:\nThe child chain will process and execute the message as a regular transaction. This flow does not use retryables, so if the transaction fails, it is not auto-retried and the nonce is consumed. This means the same transaction cannot be replayed, and a new transaction with a higher nonce must be created and submitted.\nWarningMake sure that the deployer address is sufficiently funded on the child chain before sending the transaction. If the transaction runs out of gas or fails for any reason, the associated nonce will be burned. This means that the contract cannot be deployed at the predetermined deterministic address, potentially breaking tooling and integrations that rely on that specific address.\nAdvantages and considerations\nThis approach avoids parent chain data fees and bypasses the 100,000 gas limit associated with retryable tickets. It also requires no chain upgrade or restart and works on any standard Arbitrum or Arbitrum chain setup. However, failed transactions are not automatically retried since the flow bypasses retryable safety mechanisms. The sender must have enough ETH on child chain to cover gas costs, and the signed transaction must be valid and use the correct nonce.How is this guide?Ownership structure and access controlOverview of the technical architecture of chain ownership affordances on Arbitrum chains.Sequencer troubleshootingDiagnose and resolve sequencer feed problems, broadcast backlog errors, feed stalls, and the conditions that stop block production.","tokens":986,"squid":"spider-01","role":"Chain Spider","at":1791345260577,"hash":"87297e5e492fb17344fe023b0054911612573abf"}
{"url":"https://www.metaplex.com/terms-of-use","domain":"metaplex.com","title":"Terms of Use | Metaplex","text":"← Back to homeWelcome to metaplex.com!I. INTRODUCTIONThese Terms of Use (\"Terms of Use\") provide the terms and conditions under which you, whether personally or on behalf of an entity (\"you\" or \"your\"), are permitted to use, interact with or otherwise access the Interfaces or Products provided by Metaplex Global Ltd. (\"Metaplex Global\", \"we,\" \"us,\" or \"our\"). These Terms of Use, together with any documents and additional terms or policies incorporated herein by reference, as well as our Privacy Policy (collectively, the \"Terms\"), constitute a binding agreement between you and us. Please refer to our Privacy Policy for information about how we collect, use, share and otherwise process information about you.These Terms are applicable to:(a) all content, functionality and features available on metaplex.com or any graphical user interface that link to this Terms of Use (each, as applicable, an \"Interface\");(b) software that we operate or host, or make available via an Interface (the \"Technology Features\" and together with the Interfaces, the \"Products\")Third-Party Authentication and Wallet Services. Certain features of the Products, including authentication, account creation, wallet provisioning, wallet recovery, transaction signing and transaction submission, may be provided or facilitated using services supplied by third parties. These third parties may include Horkos, Inc. d/b/a Privy (\"Privy\") and providers of externally connected self-hosted cryptocurrency wallets such as Phantom and Solflare.Your use of a third-party service may be subject to the applicable provider's terms, privacy policy and other disclosures presented to you in connection with that service. Those terms govern your relationship with the applicable provider and are separate from these Terms unless expressly stated otherwise. Metaplex Global does not own or control third-party authentication services or external wallet services and is not responsible for their continued availability, security or operation.Acceptance of these Terms does not, by itself, constitute acceptance of any separate agreement between you and Privy, an external wallet provider or another third party. Where acceptance of separate third-party terms is required, those terms will be presented to you through the applicable onboarding, authentication or wallet-creation flow.Certain User-Authorised Transaction Instructions may be implemented using functionality that Privy refers to as \"Delegated Actions.\" Your use of that functionality is also subject to the applicable Privy terms. As between you and Metaplex Global, these Terms, the applicable feature disclosures and the parameters you approve govern the scope of each instruction and the related technical permissions made available through the Products.NOTICE: YOU MUST READ THE TERMS CAREFULLY BEFORE ACCESSING OR USING THE PRODUCTS. BY ACCESSING, BROWSING OR OTHERWISE USING THE PRODUCTS, OR BY ACKNOWLEDGING AGREEMENT TO THE TERMS ON THE PRODUCTS, YOU AGREE THAT YOU HAVE READ, UNDERSTOOD AND ACCEPTED ALL OF THE TERMS, INCLUDING OUR PRIVACY POLICY, WHICH IS INCORPORATED BY REFERENCE INTO THE TERMS, INCLUDING THE BINDING ARBITRATION AGREEMENT AND CLASS ACTION WAIVER BELOW. IF YOU DO NOT AGREE TO ALL OF THE TERMS, THEN YOU ARE NOT AUTHORISED TO INTERACT WITH, ACCESS, OR USE ANY OF THE PRODUCTS.II. THE PRODUCTSA. Overview of the ProductsThe main purpose of the Products is to provide you with access to functionalities in the DeFi space powered by the Metaplex protocol, a decentralised suite of programs and tools designed to facilitate the creation, distribution, and management of digital assets using distributed ledger technology (\"Metaplex Protocol\"). We provide the Interfaces and Technology Features. We do not own or control the Blockchain Networks or Protocols with which the Products interact, act as principal or counterparty to your transactions, or exercise investment, trading, asset-management or other discretionary authority for you. Transactions are validated, ordered, confirmed and settled through Blockchain Networks, Protocols and other third parties that we do not own or control. We reserve the right to make changes to the Products, including adding, modifying, or discontinuing products or features.The Products integrate decentralised protocols (each, a \"Protocol\"), including the Metaplex Protocol. We do not own or control any Protocol, including the Metaplex Protocol. The Products offer you access to onchain programs that you can use to create, buy, sell, and/or distribute digital assets. You are solely responsible for deciding whether to enter into any blockchain transaction and for reviewing the material terms of each transaction before approving it. Metaplex Global does not make investment, trading, asset-management or other discretionary decisions for you.The Products may include other products and/or features added for the purposes of user experience development and improvement, including those for the informational, security, and entertainment purposes, which are not intended to affect the main purpose of the Products described above.Certain features may allow you to create and approve a User-Authorised Transaction Instruction that may be implemented through the Products using Privy or other Third-Party Services. The Products provide technical and ministerial functionality to process the instruction within the parameters you approved. Metaplex Global does not recommend the transaction, negotiate its terms or exercise discretion as to whether you should enter into it.Metaplex Global does not determine whether you should initiate or approve transactions using your blockchain wallet (\"Wallet\"), control your Wallet, or take possession or custody of your digital assets. A User-Authorised Transaction Instruction may permit technical functionality to process a transaction based solely on parameters you previously approved, as described in these Terms. As used herein, a \"Wallet\" means, as applicable, an \"Embedded Wallet\" or an \"External Wallet\". An \"Embedded Wallet\" is a blockchain wallet provisioned for you through the Products using technology supplied by Privy. An \"External Wallet\" is a blockchain wallet obtained from and operated through a third-party wallet provider that you connect to the Products, such as Phantom or Solflare.You are responsible for familiarising yourself with the security, authentication, recovery and transaction-approval features applicable to your Account and Wallet. Depending on the type of Wallet you use, these may include private keys, recovery phrases, passwords, email accounts, social-login accounts, authentication factors, access credentials and trusted devices.Metaplex Global does not see, possess or have access to the complete private key, whether encrypted or decrypted, for a user-controlled Embedded Wallet and cannot independently reconstruct that key. Privy supplies the relevant wallet infrastructure under its own terms. Metaplex Global also cannot access or recover the private key or recovery phrase for an External Wallet.You should also familiarise yourself with the risks associated with transacting on Blockchain Networks, including but not limited to smart contract vulnerabilities, front end vulnerabilities, hacks, phishing attacks, social engineering attacks, digital asset volatility and transaction irreversibility.B. Blockchain Networks TransactionsIn order to be completed, all transactions with cryptocurrency, digital tokens or virtual currencies (\"digital assets\") must be confirmed and recorded in the associated public blockchain. Such networks are decentralised, peer-to-peer networks supported by independent third parties, which we do not own, control, or operate. We have no control over the Blockchain Networks and, therefore, cannot and do not ensure that any transaction details that you submit via the Products will be confirmed and processed. By using the Products, you acknowledge and agree that the transaction details you submit may not be completed, or may be substantially delayed, by the Blockchain Networks.Metaplex Global does not take possession or custody of your digital assets, acquire legal or beneficial ownership of your Wallet or assets, or act as principal or counterparty to your transactions. Depending on the feature, the Products may provide limited technical functionality pursuant to a User-Authorised Transaction Instruction, including converting parameters you approve into transaction data and, through Privy or other Third-Party Services, facilitating policy-bound signing and transmission of the resulting transaction. Metaplex Global does not negotiate transaction terms or exercise discretion over whether or when you should transact. The validation, ordering, execution, confirmation and settlement of blockchain transactions are performed through Blockchain Networks, validators, Protocols, liquidity providers and other independent third parties that Metaplex Global does not control. Metaplex Global does not guarantee that a transaction will be transmitted, executed, confirmed or settled, or that title or rights in any digital asset will be transferred.You accept and acknowledge that we are not responsible for errors or omissions that you make in connection with any digital asset transaction initiated through the Products. You are responsible for reviewing the transaction details and for errors in an instruction that you approve, including an incorrect Wallet address, recipient, asset, amount, Protocol, program or transaction parameter. The Products are designed to act only within the material parameters of the instruction presented to and approved by you, but Metaplex Global does not warrant that the Products or any Third-Party Service will be error-free, uninterrupted or immune from compromise, subject to the disclaimers and limitations in these Terms.Completion of transactions that you instruct for through the Products also depends on the availability and operation of the Blockchain Networks. Errors or forks in the Blockchain Networks may cause transactions that you initiate through the Products to fail. This may mean that the transaction you were originally intending to perform will no longer be available. Unfortunately, due to the decentralised nature of the Blockchain Networks, there is no one single point of failure, and so neither we nor any particular party will be responsible to you for errors or any losses that you suffer as a result.C. Token Launch FeaturesThe Products facilitate your access to third party Protocols you can use to create tokens and conduct token distribution events or other similar offerings events directly with other users of the Protocols (\"Token Launches\"). The Products also facilitate your access to other users' Token Launches.Any tokens made available through a Token Launch are offered and sold, if at all, directly by the token creator to other users, and any transfer of tokens are conducted by the applicable third-party Protocol. For the avoidance of doubt, Metaplex Global does not offer, sell, issue, distribute, transfer, exchange, or otherwise dispose of any tokens or digital assets, does not act as a principal, agent, broker, dealer, intermediary, placement agent, or counterparty in any token transaction, and does not participate in the negotiation or execution of any token purchase or sale.Unless explicitly stated otherwise, Metaplex Global does not charge users any fees for participating in Token Launches. Participation in Token Launches may result in Network Fees to the relevant Blockchain Network or relevant Protocol.Metaplex Global does not provide investment advice, investment recommendations, or investment research, and does not provide legal, tax, accounting, or other professional advice. Metaplex Global does not determine, opine on, or represent whether any token is a security or otherwise subject to any regulatory regime, and makes no representation or warranty regarding the legal or regulatory status of any token, token creator, or Token Launch.Any information you publish to the Interfaces related to a Token Launch you conduct must be complete and accurate. You acknowledge and agree that you do not rely on Metaplex Global, the Token Launch Features, or any information made available by Metaplex Global in deciding whether to participate in any Token Launch or to acquire any token. You further acknowledge that Metaplex Global does not solicit, recommend, or advise you with respect to any Token Launch or token, and that you conduct your own independent investigation, analysis, and evaluation of each Token Launch and token creator.D. Network FeesWhen you use or interact with the Products, you may be required to pay transaction fees and/or Protocol fees (\"Network Fees\") to the relevant blockchain network or relevant Protocol in order to process and validate your transaction. These fees are set entirely by the network or third parties and are not determined, collected, or controlled by us in any way. You are solely responsible for ensuring that you have a sufficient balance of the applicable network token to cover any Network Fees. Failure to do so may result in unsuccessful or failed transaction attempts. Network Fees are non-refundable and may vary significantly depending on network congestion and protocol-level conditions, which are outside of our control.When you initiate or approve a transaction using the Products, estimated Network Fees and other material transaction charges may be displayed through the Interface, an Embedded Wallet approval screen, an External Wallet approval screen, or the screen through which you approve a conditional instruction.Fee estimates are not guaranteed and may differ from the fees ultimately charged because of changes in Blockchain Network, Protocol or market conditions.After you approve a User-Authorised Transaction Instruction, technical functionality may request policy-bound signing and transmit the resulting signed transaction without an additional fee-confirmation prompt at that time, provided that the transaction and applicable fees remain within the parameters you approved. By approving the instruction, you authorise payment of Network Fees and third-party fees within those parameters.You are responsible for Network Fees and third-party fees associated with an instruction you approve. Fees may be incurred even when a transaction fails, is reverted, is delayed or does not produce the result you anticipated.Unless expressly disclosed through the applicable feature, Metaplex Global does not charge you a transaction-based fee. Metaplex Global does not receive payment for order flow or compensation that varies based on the selection of a particular Protocol, liquidity source, execution route or counterparty. Any fee charged by Metaplex Global in connection with a feature will be disclosed before you approve the applicable User-Authorised Transaction Instruction.E. Third-Party Services and LinksTo operate the Products and facilitate your access to the Technology Features, we may engage third-party providers, protocols infrastructure and APIs, which Metaplex Global has no direct or indirect control over. We also provide access to independent third-party products the offerings of which may be presented on the Interfaces; all previously named, referred to as \"Third-Party Services\". Where applicable, such Third-Party Services are governed by their respective terms and conditions, which may include separate fees and charges, as well as disclaimers and/or risk warnings on the accuracy of the information or the services of such a provider. These terms may also include a privacy policy that differs from our Privacy Policy that is incorporated by reference herein. It is your sole responsibility to read carefully and make sure that you understand those Third-Party Services terms and conditions, including how those service providers may use your information according to their respective privacy policies.Third-Party Services may include Privy's authentication, embedded-wallet, key-management, wallet-recovery, Delegated Action, signing and transaction-broadcast services; External Wallet services; Blockchain Networks; Protocols; APIs; RPC providers; transaction relayers; market-data services; price feeds; liquidity providers; resolvers; fillers; and compliance or security vendors.The Blockchain Networks, Protocols and Third-Party Services with which the Products interact perform the underlying validation, ordering, confirmation, settlement, liquidity, market-data and other third-party functions. Metaplex Global may provide the Interface and perform the limited technical actions described in these Terms, but does not control and is not responsible for the availability, accuracy, security, operation or performance of any Third-Party Service. We may change, suspend, remove, disable or impose access restrictions or limits on any Third-Party Service at any time without notice. Where applicable, Third-Party Services may operate according to technical or programmatic parameters.Use of Third-Party Services may result in Network Fees or other third-party fees. Applicable information, including indicative fees or disclosures, may be made available through the Products, the applicable Third-Party Service terms, or informational notices accompanying the relevant feature.In certain cases, Third-Party Service add-ons to the native Products may impose or lead to the imposition of additional Network Fees on otherwise standard functionalities of the Products. This includes, without limitation, connectivity services (for example, \"connect\" buttons provided by independent third parties), which may result in additional charges. Where applicable, such services will be clearly identified and any associated fees separately disclosed.You hereby acknowledge that the functionalities accessible via the Third-Party Services are the sole responsibility of such Third-Party Services providers. You hereby expressly release Metaplex Global from any liability arising from use of any Third-Party Services, third-party website, service, or content and any resulting harm, loss, or damage. The availability of an Account, Embedded Wallet, authentication method or transaction feature may depend on the continued availability and operation of one or more Third-Party Services. Metaplex Global does not guarantee that any particular authentication provider, wallet provider or wallet feature will remain available.Integration or availability of any Third-Party Service through our Products does not imply endorsement or guarantee by us. We provide these integrations for your convenience, \"as is.\"Any information, statements, or content accessible through Third-Party Services belong to the respective third parties. We make no representations or warranties regarding the accuracy or appropriateness of third-party content.F. Changes to Products and these TermsWe reserve the right in our sole and absolute discretion to change how we operate the Products, including by adding or modifying features or temporarily or permanently suspending, discontinuing or terminating access to any portion of the Products, with or without notice, subject to applicable law. A change, suspension or discontinuation may prevent access to functionality used to create, modify or implement a User-Authorised Transaction Instruction. We may disable that functionality or stop further technical processing of an outstanding instruction, but cannot guarantee that a transaction already signed, transmitted, submitted to or accepted by a Third-Party Service or Blockchain Network, queued or included in a block can be stopped or reversed. These changes will not transfer legal or beneficial ownership of your Wallet or assets to Metaplex Global. We may update these Terms from time to time at our sole discretion. If we do, we will post the updated Terms on www.metaplex.com and wherever else they are posted, and will provide notice the next time you sign in to access or use your Account or the Products. You should review the Terms whenever we update them or you use the Products. Continued use after the updated Terms are posted and notice is provided constitutes acceptance of the changes. If you do not agree to the changes, you may not continue to use the Products.G. Additional TermsCertain Technology Features accessible through, demonstrated on or otherwise mentioned on the Interfaces, including related applications, may be subject to additional terms, transaction disclosures or feature-specific parameters presented through the Products. By approving a User-Authorised Transaction Instruction after those disclosures or parameters are presented, you agree to them. If a feature-specific disclosure or approved parameter conflicts with these Terms, it controls solely with respect to the applicable instruction or feature and only to the extent of the conflict.III. ELIGIBILITYA. OverviewYou may not use the Products if you are barred from using the Products under applicable law in any way whatsoever. You must be at least 18 years old or the minimum age required to consent to use the Products in your location, whichever is higher.Our Products are NOT offered to persons or entities who reside in, are citizens of, are incorporated in, or have a registered office in any Prohibited Localities, namely Restricted Persons, as defined below. We do not make exceptions. If you are a Restricted Person, then do not attempt to access or use the Products. Use of a virtual private network (e.g., a VPN) or other means by Restricted Persons to access or use the Products is prohibited.B. LegalityYou are solely responsible for adhering to all laws and regulations applicable to you and your use of or access to the Products. Your use of the Products is prohibited to the extent it would violate or facilitate the violation of any applicable laws or regulations, or contribute to or facilitate any illegal activity.We make no representations or warranties that the information, products, or services provided through our Interface, are appropriate for access or use in other jurisdictions. You are not permitted to access or use our Products in any jurisdiction or country if it would be contrary to the law or regulation of that jurisdiction or if it would subject us to the laws of, or any registration requirement with respect to, such jurisdiction. We reserve the right to limit the availability of our Products to any person, geographic area, or jurisdiction, at any time and at our sole and absolute discretion.C. SanctionsBy using or accessing the Products, you represent to us that you are not subject to the Sanction Lists and you are not a Restricted Person, as defined below. \"Sanction Lists\" means any sanctions designations listed on economic, trade, embargo lists and/or specially designated persons, blocked persons lists published by international organisations, as well as any state and governmental authorities of any jurisdiction, including, but not limited to the lists of comprehensive trade or economic sanctions, embargoes, or similar restrictive measures administered or enforced by the United Nations, the United States (including, without limitation, the Office of Foreign Assets Control of the U.S. Department of the Treasury (OFAC), the European Union (or any of its Member States), the United Kingdom (including as extended to the British Virgin Islands), or any other authority with relevant jurisdiction.D. Prohibited LocalitiesThe Products are not made available to persons, entities, Accounts, or Wallets located in, established in, or belonging to a resident of any state, country or region that is subject or target of comprehensive trade or economic sanctions, embargoes, or similar restrictive measures, or included in the Sanction Lists.E. Restricted PersonsThe Products are not made available to Wallets, which have been previously classified or otherwise identified by international organisations or any state and governmental authorities of any jurisdiction, as belonging or affiliated with the persons specially designated or otherwise included in the Sanction Lists (\"Restricted Persons\"). The Products are not available to Restricted Persons or to Accounts, Wallets or wallet addresses owned, controlled or used by Restricted Persons. For the purposes of these Terms, Restricted Persons shall also include all persons or entities who reside in, are citizens of, are incorporated in, or have a registered office in the Prohibited Localities.F. Third-Party RestrictionsAs mentioned above, our Products may include the Third-Party Services. Your interaction with and use of the Third-Party Services, including Privy or an External Wallet, is governed by the respective terms and conditions of the third-party providers, including but not limited to their eligibility requirements, restrictions on certain localities, restricted persons or any other eligibility-related terms. As a result, based on those terms set by the third-party providers, your access to certain products and/or features of the Products may be restricted by those providers. Please note that we only facilitate your interaction with these Third-Party Services and we bear no liability for any such restrictions thereof. It is your own responsibility to review those terms and conditions, and ensure that you meet the requirements set forth therein.G. Non-CircumventionYou agree not to access the Products using any technology for the purposes of circumventing these Terms, including any software or networking techniques, such as Virtual Private Networks (VPNs) to modify your internet protocol address or otherwise circumvent or attempt to circumvent these Terms.IV. YOUR ACCESS TO THE PRODUCTSA. Conditions for Access to the ProductsAs a condition to accessing or using the Products, you will:ensure that all information that you share via the Products or to us otherwise is current, complete, and accurate;only use the Products for lawful purposes and in accordance with these Terms;maintain the security and confidentiality of your Account, email account, social-login account, authentication factors, devices, Wallets, wallet credentials, recovery methods and other means of accessing the Products or approving transactions; andagree that: (a) no Metaplex Party (as defined in Section IX) will be responsible for any loss or damage incurred as a result of interactions you have with other users of the Products; and (b) if there is a dispute between you and another user of the Products, no Metaplex Party will be under any obligation to become involved.You must promptly notify Metaplex Global if you know or reasonably suspect that: (i) your Account or Embedded Wallet has been accessed without authorisation; (ii) an authentication method or device associated with your Account has been compromised; (iii) a transaction instruction or Delegated Authorization was created or approved without your authorisation; (iv) a signer, wallet policy or other permission associated with a Delegated Authorization has been compromised or misconfigured; or (v) an active instruction or authorisation no longer reflects your intentions.As a condition to accessing or using the Products, you will not:violate any applicable law, including, without limitation, any relevant and applicable privacy and data collection laws including the British Virgin Islands Data Protection Act, the European Union General Data Protection Regulation, any relevant and applicable gambling, illicit contracting, misrepresentation, or fraud laws, and any relevant and applicable anti-money laundering and anti-terrorist financing laws, in each case as may be amended from time to time;export, re-export, or transfer, directly or indirectly, any Metaplex Global technology or data or data accessed through any of the Products in violation of applicable export laws or regulations or the legal owners and controllers of such data;infringe any intellectual property or other third-party right, or commit a tort or violation of criminal or contract law while using or involving any Product;misrepresent the reliability or veracity of any content on the Products or through the Products;use the Products in any manner that could interfere with, disrupt, negatively affect, or inhibit other users from their quiet enjoyment of the Products, or that could impair, disable, overwhelm, or otherwise alter the functioning of the Products in any manner;attempt to circumvent any content filtering techniques or security or compliance measures that the Metaplex Global employs on the Interfaces or in the Technological Features, or attempt to access any part of the Product that you are not authorised to access;use any scraper or other automated means or interface not provided by us to access the Products or to extract data;introduce any virus, malware, Trojan horse, worm, backdoor, exploit, or other harmful software into the Products;post content or communications on the Interfaces or in the Products that are, in our sole discretion, fraudulent, deceptive, libelous, defamatory, profane, obscene, pornographic, sexually explicit, lewd, vulgar, suggestive, harassing, hateful, threatening, offensive, discriminatory, bigoted, abusive, inflammatory, or otherwise objectionablecircumvent, interfere with or misrepresent any transaction-approval, authentication, wallet-policy, signer-policy, revocation, security or authorisation control made available through the Products;post content or communications on the Interfaces containing unsolicited promotions, campaigns, or commercial messages or any user content designed to deceive the user of the Product; orinduce any other user or third party to engage in any of the activities prohibited under these Terms or otherwise violate these Terms.You represent and warrant that you know, understand, and accept the risks associated with your use of the Products, using onchain programs (smart contracts) and other blockchain and distributed ledger technologies, APIs, and public/private key technologies in general, your Wallet address and the Blockchain Network, including the risks identified elsewhere in these Terms.B. Right to Suspend AccessWe reserve the right, at our sole discretion, to suspend, restrict, or disable access to any of the Products, or to any part, feature, or functionality thereof, at any time, for any reason or no reason, with or without prior notice, and without any obligation to provide an explanation. You acknowledge and agree that we shall not be liable to you for any losses or damages you may suffer as a result of, or in connection with, your inability to access or use the Products at any time.Suspension or restriction of your Account may prevent you from accessing an Embedded Wallet through the Products but does not transfer ownership of the Embedded Wallet or its assets to Metaplex Global. Metaplex Global may disable access to relevant functionality or prevent further technical processing or transmission of an outstanding User-Authorised Transaction Instruction, or further use of a Delegated Authorization, where reasonably necessary for security, legal, sanctions, compliance, fraud-prevention or technical reasons. A cancellation or revocation request may require processing and is not effective until the Products indicate that it has taken effect. Metaplex Global cannot guarantee that cancellation, revocation or suspension will stop or reverse a transaction that has already been signed, transmitted, submitted to or accepted by a Third-Party Service or Blockchain Network, queued or included in a block.C. Account Creation and AuthenticationTo access certain features of the Products, you may be required to create an account (\"Account\"). You may be permitted to create or access an Account using:an email address;a supported third-party authentication provider, such as Google;a supported External Wallet, such as Phantom or Solflare; oranother authentication method made available through the Products.Your Account is distinct from any particular Wallet or wallet address. An Account may be associated with one or more authentication methods, Embedded Wallets, External Wallets or wallet addresses. You must provide accurate and current Account information. You may not create or use an Account on behalf of another person without authorisation, impersonate another person, or use another person's authentication method or Wallet without authorisation.You are responsible for all activity conducted through your Account using a valid authentication method, except to the extent such activity results from a breach of Metaplex Global's obligations that cannot lawfully be disclaimed. You must maintain the security of your Account and all linked authentication methods. You should use any additional authentication or security functionality made available through the Products.Your ability to access your Account may depend on the continued availability of your email account, device, third-party authentication provider or External Wallet. Metaplex Global cannot guarantee that a third-party authentication method will remain available or that a third-party provider will restore your access. You may be able to link or unlink authentication methods or Wallets through the Products. Metaplex Global may require additional verification before linking, unlinking or changing an authentication method or Wallet.Creating multiple Accounts or using different authentication methods may result in separate Accounts or Wallets unless the authentication methods are properly linked. Metaplex Global does not guarantee that separate Accounts or Wallets can be merged.D. WalletsEmbedded Wallets. An Embedded Wallet is provisioned for your benefit using technology supplied by Privy. You retain legal and beneficial ownership of the Embedded Wallet and the digital assets associated with it. Metaplex Global does not see, possess or have access to your complete private key and does not acquire ownership of your Wallet or assets. Certain optional features may allow you to approve limited, policy-bound wallet permissions through a Delegated Authorization, as described below.The Products do not make transaction decisions for you, and Metaplex Global does not execute or settle transactions. When you approve a User-Authorised Transaction Instruction, the Products may provide technical functionality to implement that instruction within the parameters you approved. The availability and operation of authentication, recovery, export, additional-security and wallet-management functionality depend on the applicable Privy configuration and may change over time. You are responsible for understanding and using the security and recovery functionality made available to you.External Wallets. An External Wallet is provided and controlled by a third-party wallet provider. Metaplex Global does not possess or control the private keys, recovery phrase or credentials for your External Wallet. You are responsible for securing your External Wallet and for reviewing and approving transactions through the wallet interface supplied by its provider. Metaplex Global cannot restore access to an External Wallet, recover its private keys or recovery phrase, or reverse a transaction approved through it.E. User-Authorised Transaction InstructionsCertain features of the Products may allow you to create and approve a User-Authorised Transaction Instruction for a blockchain transaction using your Embedded Wallet. Depending on the feature, the instruction may later be implemented automatically upon satisfaction of conditions you approved, without an additional approval at the time technical functionality requests signing or transmits the transaction. This functionality may use policy-bound signing and transmission services supplied by Privy or other Third-Party Services. Metaplex Global does not execute or settle the transaction.\"Delegated Authorization\" means any limited, policy-bound wallet permission that you expressly approve in connection with one or more User-Authorised Transaction Instructions. A Delegated Authorization is limited to the scope, duration and other restrictions disclosed when you approve it. It does not give Metaplex Global access to your complete private key or discretion to decide whether you should transact or to alter the material parameters of an instruction. Depending on the feature and the disclosures presented to you, a Delegated Authorization may remain effective after an individual instruction is completed, cancelled or expires.A \"User-Authorised Transaction Instruction\" is an instruction that:is initiated, configured or requested by you;is presented to you through the Products in a manner reasonably designed to clearly describe the action you are requesting;identifies the material parameters of the action, which may include, as applicable, the asset, transaction type or direction, maximum quantity or value, price or price range, triggering condition, expiration, permitted Protocol or destination, and fee or slippage limitations; andis affirmatively approved by you through the approval mechanism presented by the Products.By approving a User-Authorised Transaction Instruction, you direct the Products to apply technical and ministerial functionality to that instruction within the parameters you approved. Technical processing occurs according to pre-disclosed, objective functionality and does not involve Metaplex Global making an individualised judgment about whether or when you should transact. The Products may not materially modify, expand or substitute a User-Authorised Transaction Instruction without obtaining your additional affirmative approval. Your approval of one instruction does not authorise Metaplex Global to enter into unrelated transactions or create new instructions for you.A User-Authorised Transaction Instruction remains outstanding until it is completed, cancelled, expires or otherwise terminates in accordance with the parameters presented to you. A Delegated Authorization may have a different duration and may remain effective until revoked, expired or otherwise terminated as disclosed to you. Cancellation of one instruction does not necessarily revoke a separate Delegated Authorization. Cancellation and revocation are prospective, may require processing and are not effective until the Products indicate that they have taken effect. They cannot prevent or reverse a transaction that has already been signed, transmitted, submitted to or accepted by a Blockchain Network, Protocol or Third-Party Service, queued, included in a block or otherwise entered an irreversible stage of execution. You are responsible for monitoring and managing your settings, authorisations and open instructions.Conditional Transaction Risks. Approval of a User-Authorised Transaction Instruction does not guarantee continuous availability of market data or technical functionality, transmission at the exact moment a triggering condition occurs, confirmation or completion at any particular time or price, completion in full, or any particular economic result. An instruction may fail to result in a transaction, or a transaction may be delayed, partially completed, fail or expire even if a condition displayed through the Products appears to have occurred. Whether a transaction is signed, transmitted, executed, confirmed or settled may depend on Blockchain Networks, Protocols, liquidity providers, market-data services, price feeds, RPC providers, transaction relayers, Privy and other Third-Party Services that Metaplex Global does not control. Prices, liquidity, balances, fees, routes and market conditions may change between approval and completion. You are responsible for maintaining sufficient assets and network tokens in your Wallet and assume the risks of slippage, transaction ordering, MEV, unavailable liquidity, insufficient balances, stale or inaccurate data, network congestion, smart-contract failures and third-party outages.F. Records of Instructions and ApprovalsMetaplex Global may create and retain electronic records relating to a User-Authorised Transaction Instruction or Delegated Authorization, including:the information presented to you;the material parameters of the instruction;the date and time of approval;the Account and Embedded Wallet associated with the instruction;the approval method used;the version of the relevant Interface and disclosures;the scope and duration of any Delegated Authorization and applicable signer or wallet-policy restrictions;any modification, cancellation, expiration or revocation;the requested and effective times of any cancellation or revocation;actions taken pursuant to the instruction; andrelevant technical processing, transmission, error and status records; andassociated blockchain transaction identifiers, signatures, statuses and results.You agree that these electronic records, together with applicable blockchain records, may be used to evidence the instructions and approvals you provided through the Products.G. Account ClosureBefore closing your Account, you should:cancel outstanding User-Authorised Transaction Instructions and separately revoke any Delegated Authorizations that you no longer wish to remain effective;review the Embedded Wallet's balance and transaction activity;use any available wallet export, recovery or alternative-access functionality that you wish to retain; andpreserve any records you may need.Closing or suspending an Account does not delete, reverse or remove a Wallet, digital asset, wallet address or transaction recorded on a Blockchain Network.Closing or suspending an Account may prevent you from accessing an Embedded Wallet through the Products. The availability of continued or alternative wallet access depends on the applicable technical configuration and recovery or export functionality.Closing or suspending an Account does not necessarily cancel an outstanding User-Authorised Transaction Instruction or revoke a separate Delegated Authorization unless the Products confirm that the cancellation or revocation has taken effect. Before voluntarily closing your Account, you are responsible for completing each available cancellation and revocation step.V. YOUR USE OF THE PRODUCTSA. OverviewYou acknowledge and agree that the Products facilitate your interaction with decentralised Blockchain Networks, Protocols and other technology. We do not control any Blockchain Network, Protocol or digital asset and cannot ensure that an interaction will be confirmed. Except through cancellation or revocation functionality expressly made available through the Products, we generally cannot effectuate a cancellation or modification request; even when such functionality is available, a request may be ineffective once a transaction has been signed or transmitted and can no longer be modified or reversed. You make each decision to create or approve a transaction instruction. The availability of an interface, feature, suggested action, template, default parameter or transaction route does not constitute a recommendation that you enter into a transaction.Without limiting the foregoing, you specifically understand and hereby represent your acknowledgement of the following:The information provided through the Products does not represent an offer, a solicitation of an offer, or any advice regarding, or recommendation to enter into, a transaction with the Products;Nothing in these Terms appoints Metaplex Global as your agent to negotiate a transaction, exercise investment discretion or bind you beyond the specific technical and ministerial actions expressly authorised by a User-Authorised Transaction Instruction;The Products do not own, control, or operate any Blockchain Networks, Protocols, smart contracts, liquidity sources, or other third-party infrastructure that you may interact with, and therefore are not responsible for their availability, security, or operation;You are solely responsible for reporting and paying any taxes applicable to your use of the Products;Although it is intended to provide accurate and timely information on the Products, the Products or relevant tools may not always be entirely accurate, complete or current and may also include technical inaccuracies or typographical errors. Accordingly, you should verify all information before relying on it, and all decisions based on information contained on the Products or relevant tools are your sole responsibility.The Products are provided for direct, human use only. You may not access or use the Products programmatically or in a way that creates undue burden on our infrastructure, bypasses restrictions, or manipulates outcomes. You agree not to use, access, or interact with the Products through the use of any automated software, including but not limited to bots, such as automated trading bots, sniper or arbitrage bots, scripts, front-running tools, crawlers, scrapers, other similar tools or technologies that are designed to automate access, interactions, or trading activity or any other any software that circumvents or interferes with the intended functionality of the Products.B. Information Provided is for Informational Purposes OnlyAll information provided in connection with your access and use of the Products 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 Products or any other information that we make available at any time, including, without limitation, blog posts, articles, links to third-party content, news feeds, tutorials, tweets and videos. Before you make any financial, legal, or other decisions involving the Products, you should seek independent professional advice from an individual who is licensed and qualified in the area for which such advice would be appropriate.C. No Fiduciary DutiesThese 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 eliminated. You further agree that the only duties and obligations that we owe you are those set forth expressly in the Terms.For the avoidance of doubt, in providing the Products, Metaplex Global does not take possession or custody of digital assets, acquire legal or beneficial ownership of a Wallet or its assets, act as principal or counterparty, or exercise discretionary authority to decide whether or when you should transact. Performing limited technical and ministerial actions pursuant to a User-Authorised Transaction Instruction does not create a fiduciary, advisory, brokerage, dealer, custodial or asset-management relationship.D. The Products May Not Be Used to Violate Securities LawsYOU ARE SOLELY RESPONSIBLE FOR ENSURING THAT YOUR USE OF THE PRODUCTS AS CONTEMPLATED BY THESE TERMS OF USE, DOES NOT AND WILL NOT VIOLATE ANY U.S. SECURITIES LAW OR REGULATION OR ANY OTHER APPLICABLE SECURITIES LAW OR REGULATION. WE DO NOT ASSUME ANY LIABILITY THAT MAY ARISE BASED ON ANY SUCH VIOLATIONS.Without limiting the foregoing, you agree not to create any digital assets which would be deemed unlawful securities and acknowledge that the Products may not be used for creating digital assets that may be deemed a security or a derivative.You agree to use the Products only for lawful purposes and in compliance with these Terms, the Acceptable Use Policy, and all applicable laws and regulations.We reserve the right to monitor usage, investigate any suspected violation of these Terms, and to take appropriate action, including suspension or termination of access, against any user who engages in prohibited activities. If you are unsure whether your intended use of the Products is allowed, you should cease such use or seek clarification from us.VI. COMPLIANCEA. Your Compliance ObligationsThe Products may not be available or appropriate for use in all jurisdictions. By accessing or using the Products, you agree that you are solely and entirely responsible for compliance with all laws and regulations that may apply to you. You further agree that we have no obligation to inform you of any potential liabilities or violations of law or regulation that may arise in connection with your access and use of the Products and that we are not liable in any respect for any failure by you to comply with any applicable laws or regulations.B. Compliance ChecksAs we aim to provide a safe and compliant environment within the Products, some of the Interfaces or Technological Features accessible through the Products may be available to you only upon the completion of a verification process. The verification may involve completing a due diligence and verification questionnaire (\"Due Diligence Checks\") as required by applicable law, including anti-money laundering and fraud prevention, sanctions laws and regulations.The Due Diligence Checks may be designated to a third-party provider upon our discretion. In order to complete the Due Diligence Checks, you undertake to promptly provide all required information, including supporting documentation and other evidence, as may be reasonably requested, to such third-party provider elected by us. You are solely responsible for the accuracy and completeness of the data provided.You acknowledge and understand that the outcome of the Due Diligence Checks lies in the sole discretion of the third-party provider. After having successfully passed the Due Diligence Checks you will be granted access to the relevant products and/or features in the Products. In the event you refuse or deny information requested by the third-party provider, your access to the respective products and/or features of the Products may be restricted.You understand that the amount of information requested as part of the Due Diligence Checks may be subject to change over time and that you may at a later point in time be required to provide additional documents and/or information.The data collected in accordance with the Due Diligence Checks is to comply with applicable legal and regulatory obligations to verify your identity and determine your legal eligibility. This data is securely maintained and disclosed only when permitted by law. For more information on how your personal data is processed please refer to our Privacy Policy.C. Risk AssessmentYou acknowledge and agree that a risk assessment may be conducted using Third-Party Services to review Accounts, Wallets, wallet addresses, transactions, proposed transactions and other activity for suspected fraud, sanctions exposure, illicit activity or other non-compliant behavior. We may block or restrict an Account, Wallet address, feature or User-authorised Transaction Instruction based on such an assessment, subject to applicable law. We reserve the right to block or restrict access of any Wallet addresses associated with such illicit activity and file a report with relevant competent authorities if required by applicable law. You acknowledge that we hold no liability for such assessment, restriction, results, or accuracy of the Third-Party Services.If you believe you or your Account or Wallet has been blocked or restricted from using the Products by mistake, please contact us at: compliance@metaplex.xyzD. Regulatory ComplianceYou acknowledge and understand that, as at the date of this version of the Terms, Metaplex Global is not registered as a virtual asset service provider under the British Virgin Islands Virtual Assets Service Providers Act, 2022, or under any equivalent legislation of any other financial regulatory regime.The Products do not involve us in custody of digital assets, the operation of a virtual assets exchange, transfer of virtual assets, or any other regulated virtual assets activity. We provide a software service only, and no aspect of the Products constitute issuing, offering, or facilitating transactions in virtual assets or other regulated financial instruments. You must not use the Products to create tokens or engage in activities that would violate securities laws or require registration or licensing where you do not hold such registration or license. Any such use is strictly prohibited, and you will be solely responsible for compliance with all applicable laws.If it is determined that your use of the Products is in violation of any financial regulations or these Terms, we may immediately suspend your access and report such activity to relevant authorities if required by law.VII. CONTENT MODERATIONWe do not control and do not have any obligation to monitor the content published by users on the Interfaces (\"User Content\"). We are under no obligation to host or serve User Content. If you see any User Content you believe does not comply with these Terms, including by violating applicable law or regulations, you can report it to us.If we become aware that any User Content made available via the Products (1) infringes another's copyright or any other intellectual property or related or neighboring right, (2) is in breach of these Terms, or (3) may cause harm to us, our users, or third parties, we reserve the right to remove or take down some or all of such User Content using, where appropriate, algorithmic and/or human review.Written reports concerning copyright infringement must include:The signature of the person authorised to act on behalf of the copyright owner.A description of the copyright work you allege has been infringed.A description of where the material you alleged is infringing is located on the platform.Your address, phone number, email.Statement by you that you have good faith belief that the disputed use is not authorised by the owner.Statement by you under penalty of perjury, that the above information is correct and that you are authorised to act on behalf of the copyright owner.VIII. OWNERSHIP OF THE PRODUCTSThe Products are owned, operated, and provided by us and our affiliates, licensors, distributors, and service providers (collectively \"Providers\"). We and our Providers retain all of our respective rights, title, and interest, including intellectual property rights, in and to the Products.Subject to your compliance with these Terms, we grant you a limited, royalty-free, non-exclusive, non-transferable, non-sublicensable, revocable license to access and use the Products. This license is provided solely for you to utilise and enjoy the benefit of the Products as permitted herein. You shall not use the Products in any manner or for any purpose other than as expressly permitted by these Terms.Other than the rights of access and use expressly granted in these Terms, we do not grant you any right, title, or interest in or to our Products. You will not remove, alter, or obscure any copyright, trademark, service mark, or other proprietary rights notices on the Products or any content obtained via the Products.IX. DISCLAIMER OF WARRANTIES, LIMITATIONS OF LIABILITY, AND INDEMNITYYOUR USE OF THE PRODUCTS IS SOLELY AT YOUR OWN RISK. THE PRODUCTS ARE PROVIDED ON AN \"AS IS\" AND \"AS AVAILABLE\" BASIS AND, TO THE FULLEST EXTENT PERMISSIBLE UNDER APPLICABLE LAW, ARE PROVIDED WITHOUT WARRANTIES OF ANY KIND, WHETHER EXPRESS, IMPLIED, OR STATUTORY. WE AND OUR PROVIDERS EXPRESSLY DISCLAIM ANY AND ALL WARRANTIES OF FITNESS FOR A PARTICULAR PURPOSE, TITLE, MERCHANTABILITY, ACCURACY, AVAILABILITY, RELIABILITY, SECURITY, PRIVACY, COMPATIBILITY, NON-INFRINGEMENT, AND ANY WARRANTY IMPLIED BY COURSE OF DEALING, COURSE OF PERFORMANCE, OR TRADE USAGE.TO THE FULLEST EXTENT PERMISSIBLE UNDER APPLICABLE LAW, IN NO EVENT WILL WE, OUR PROVIDERS, OR OUR OR THEIR RESPECTIVE AFFILIATES, DIRECTORS, OFFICERS, EMPLOYEES, AGENTS, SUCCESSORS OR ASSIGNS (COLLECTIVELY, THE \"METAPLEX PARTIES\"), BE LIABLE FOR ANY DIRECT, INDIRECT, PUNITIVE, INCIDENTAL, SPECIAL, CONSEQUENTIAL, EXEMPLARY, OR OTHER DAMAGES ARISING OUT OF OR IN ANY WAY RELATED TO THE SERVICES, THE MATERIALS, THE ACTIONS, OR THESE TERMS, WHETHER BASED IN CONTRACT, TORT (INCLUDING NEGLIGENCE), STRICT LIABILITY, OR OTHER THEORY, EVEN IF ANY METAPLEX PARTIES HAVE BEEN ADVISED OF THE POSSIBILITY OF DAMAGES, AND EVEN IF THE DAMAGES ARE FORESEEABLE.TO THE FULLEST EXTENT PERMISSIBLE UNDER APPLICABLE LAW, THE METAPLEX PARTIES' TOTAL AGGREGATE LIABILITY TO YOU FOR ALL DAMAGES, LOSSES AND CAUSES OF ACTION ARISING OUT OF OR IN ANY WAY RELATED TO THE SERVICES, THE MATERIALS, THE ACTIONS, OR THESE TERMS, WHETHER IN CONTRACT, TORT (INCLUDING NEGLIGENCE) OR OTHERWISE, WILL NOT EXCEED THE GREATER OF (i) THE AMOUNT YOU PAID TO US IN EXCHANGE FOR ACCESS TO AND USE OF THE PRODUCTS, OR (ii) $1,000. THE FOREGOING LIMITATIONS ARE ESSENTIAL TO THESE TERMS, AND WE WOULD NOT OFFER THE PRODUCTS TO YOU UNDER THESE TERMS WITHOUT THESE LIMITATIONS.YOU AGREE TO INDEMNIFY AND HOLD HARMLESS THE METAPLEX PARTIES FROM AND AGAINST ANY AND ALL LIABILITIES, CLAIMS, DAMAGES, EXPENSES (INCLUDING REASONABLE ATTORNEYS' FEES AND COSTS), AND OTHER LOSSES ARISING OUT OF OR RELATED TO YOUR BREACH OR ALLEGED BREACH OF THESE TERMS OF USE; YOUR ACCESS TO, USE OF, OR ALLEGED USE OF THE PRODUCTS, THE MATERIALS, OR THE ACTIONS; ANY PRODUCTS OR SERVICES THAT YOU DEVELOP, OFFER, OR OTHERWISE MAKE AVAILABLE USING OR OTHERWISE IN CONNECTION WITH THE PRODUCTS; YOUR VIOLATION OF APPLICABLE LAW OR ANY THIRD-PARTY RIGHT; AND ANY ACTUAL OR ALLEGED FRAUD, INTENTIONAL MISCONDUCT, OR CRIMINAL ACTS COMMITTED BY YOU OR YOUR EMPLOYEES OR AGENTS. WE RESERVE THE RIGHT TO ENGAGE SEPARATE COUNSEL AND PARTICIPATE IN OR ASSUME THE EXCLUSIVE DEFENSE AND CONTROL OF ANY MATTER OTHERWISE SUBJECT TO INDEMNIFICATION BY YOU HEREUNDER, IN WHICH CASE YOU AGREE TO COOPERATE WITH US AND SUCH SEPARATE COUNSEL AS WE REASONABLY REQUEST.THE LAWS OF SOME JURISDICTIONS DO NOT ALLOW THE DISCLAIMER OF IMPLIED WARRANTIES OR CERTAIN TYPES OF DAMAGES, SO SOME OR ALL OF THE DISCLAIMERS AND LIMITATIONS OF LIABILITY IN THESE TERMS MAY NOT APPLY TO YOU.OUR PROVIDERS ARE INTENDED THIRD PARTY BENEFICIARIES OF THE WARRANTY DISCLAIMERS AND LIMITATIONS OF LIABILITY CONTAINED IN THIS SECTION.X. DISPUTE RESOLUTION AND ARBITRATIONThese Terms require you to arbitrate certain disputes and claims with us and limit the manner in which you can seek relief from us, 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. You and Metaplex Global agree that any dispute arising out of or related to these Terms or our Products is personal to you and Metaplex Global and that any dispute will be resolved solely through individual action, and will not be brought as a class arbitration, class action or any other type of representative proceeding.A. Notice of DisputeFor any dispute or claim that you may have against Metaplex Global, you agree to first contact Metaplex Global and attempt to resolve the claim informally by sending a written notice of your claim (\"Notice\") to Metaplex Global by email at contact@metaplex.xyz. Metaplex Global will similarly contact you in the event that we have any dispute or claim against you.The Notice must include your name, email address, and telephone number, describe the nature and basis of the claim and set forth the specific relief sought. Our notice to you will be similar in form to that described above.B. Arbitration RulesIf you and Metaplex Global cannot reach an agreement to resolve the claim within thirty (30) days after such Notice is received, then either party may submit the dispute to binding arbitration administered by binding arbitration administered by the London Court of International Arbitration (LCIA). The","tokens":15000,"squid":"spider-10","role":"Tooling Spider","at":1791345261065,"hash":"aa2a275a63c4faac801e64d981a4670f547bd1d3"}
{"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":"spider-08","role":"Oracle Spider","at":1791345265821,"hash":"6c96834b3abd6610fe19f45bfa21993992cdf70f"}
{"url":"https://www.metaplex.com/docs/smart-contracts/token-metadata/guides/javascript/create-an-nft","domain":"metaplex.com","title":"How to Create a NFT On Solana | Token Metadata Guides","text":"Token Metadata is a legacy program. It remains supported, but is not recommended for new projects. Use Core instead.This is an intial guide on how to create an NFT on the Solana blockchain with the Metaplex Token Metadata protocol.PrerequisiteCode Editor of your choice (recommended Visual Studio Code)Node 18.x.x or above.Initial SetupThis guide will run through creation of an NFT with Javascript based on a single file script. You may need to modify and move functions around to suit your needs.InitializingStart by initializing a new project (optional) with the package manager of your choice (npm, yarn, pnpm, bun) and fill in required details when prompted.npm init\nRequired PackagesInstall the required packages for this guide.1import { createUmi } from '@metaplex-foundation/umi-bundle-defaults';\n2import { generateSigner, percentAmount } from '@metaplex-foundation/umi';\n3import {\n4 mplTokenMetadata,\n5 createNft,\n6 fetchDigitalAsset,\n7} from '@metaplex-foundation/mpl-token-metadata';\n8\n9// Create Umi instance with the Token Metadata plugin\n10const umi = createUmi('https://api.devnet.solana.com')\n11 .use(mplTokenMetadata());\n12\n13// Connect your wallet (keypair or wallet adapter)\n14// For keypair: umi.use(keypairIdentity(keypair))\n15// For wallet adapter: umi.use(walletAdapterIdentity(wallet))\n16\n17// Generate a new mint keypair\n18const mint = generateSigner(umi);\n19\n20// Create an NFT\n21await createNft(umi, {\n22 mint,\n23 name: 'My NFT',\n24 uri: 'https://example.com/my-nft.json',\n25 sellerFeeBasisPoints: percentAmount(5.5),\n26}).sendAndConfirm(umi);\n27\n28// Fetch the NFT data\n29const asset = await fetchDigitalAsset(umi, mint.publicKey);\n30\n31console.log('NFT created successfully!');\n32console.log('Mint address:', mint.publicKey);\n33console.log('Name:', asset.metadata.name);\n34console.log('URI:', asset.metadata.uri);\n1import {\n2 appendTransactionMessageInstructions,\n3 createSolanaRpc,\n4 createSolanaRpcSubscriptions,\n5 createTransactionMessage,\n6 generateKeyPairSigner,\n7 getSignatureFromTransaction,\n8 pipe,\n9 sendAndConfirmTransactionFactory,\n10 setTransactionMessageFeePayer,\n11 setTransactionMessageLifetimeUsingBlockhash,\n12 signTransactionMessageWithSigners,\n13} from '@solana/kit';\n14import {\n15 createNft,\n16 fetchDigitalAsset,\n17} from '@metaplex-foundation/mpl-token-metadata-kit';\n18\n19// Create RPC connection\n20const rpc = createSolanaRpc('https://api.devnet.solana.com');\n21const rpcSubscriptions = createSolanaRpcSubscriptions('wss://api.devnet.solana.com');\n22\n23// Generate keypairs (or load from wallet)\n24const authority = await generateKeyPairSigner();\n25const mint = await generateKeyPairSigner();\n26\n27// Helper function to send and confirm transactions\n28// Works with any signer type - signers are automatically extracted from instruction accounts\n29async function sendAndConfirm(options) {\n30 const { instructions, payer } = options;\n31 const { value: latestBlockhash } = await rpc.getLatestBlockhash().send();\n32\n33 const transactionMessage = pipe(\n34 createTransactionMessage({ version: 0 }),\n35 (tx) => setTransactionMessageFeePayer(payer.address, tx),\n36 (tx) => setTransactionMessageLifetimeUsingBlockhash(latestBlockhash, tx),\n37 (tx) => appendTransactionMessageInstructions(instructions, tx),\n38 );\n39\n40 // Sign with all signers attached to instruction accounts\n41 const signedTransaction = await signTransactionMessageWithSigners(transactionMessage);\n42\n43 const sendAndConfirmTx = sendAndConfirmTransactionFactory({ rpc, rpcSubscriptions });\n44 await sendAndConfirmTx(signedTransaction, { commitment: 'confirmed' });\n45\n46 return getSignatureFromTransaction(signedTransaction);\n47}\n48\n49// Create and mint an NFT using the helper function\n50const [createIx, mintIx] = await createNft({\n51 mint,\n52 authority,\n53 payer: authority,\n54 name: 'My NFT',\n55 uri: 'https://example.com/my-nft.json',\n56 sellerFeeBasisPoints: 550, // 5.5%\n57 tokenOwner: authority.address,\n58});\n59\n60// Send transaction\n61const sx = await sendAndConfirm({\n62 instructions: [createIx, mintIx],\n63 payer: authority,\n64});\n65\n66// Fetch the NFT data\n67const asset = await fetchDigitalAsset(rpc, mint.address);\n68\n69console.log('NFT created successfully!');\n70console.log('Mint address:', mint.address);\n71console.log('Signature:', sx);\n72console.log('Name:', asset.metadata.name);\n73console.log('URI:', asset.metadata.uri);\nSetting up the SDK1import { createUmi } from '@metaplex-foundation/umi-bundle-defaults';\n2import { generateSigner, percentAmount } from '@metaplex-foundation/umi';\n3import {\n4 mplTokenMetadata,\n5 createNft,\n6 fetchDigitalAsset,\n7} from '@metaplex-foundation/mpl-token-metadata';\n8\n9// Create Umi instance with the Token Metadata plugin\n10const umi = createUmi('https://api.devnet.solana.com')\n11 .use(mplTokenMetadata());\n12\n13// Connect your wallet (keypair or wallet adapter)\n14// For keypair: umi.use(keypairIdentity(keypair))\n15// For wallet adapter: umi.use(walletAdapterIdentity(wallet))\n16\n17// Generate a new mint keypair\n18const mint = generateSigner(umi);\n19\n20// Create an NFT\n21await createNft(umi, {\n22 mint,\n23 name: 'My NFT',\n24 uri: 'https://example.com/my-nft.json',\n25 sellerFeeBasisPoints: percentAmount(5.5),\n26}).sendAndConfirm(umi);\n27\n28// Fetch the NFT data\n29const asset = await fetchDigitalAsset(umi, mint.publicKey);\n30\n31console.log('NFT created successfully!');\n32console.log('Mint address:', mint.publicKey);\n33console.log('Name:', asset.metadata.name);\n34console.log('URI:', asset.metadata.uri);\n1import {\n2 appendTransactionMessageInstructions,\n3 createSolanaRpc,\n4 createSolanaRpcSubscriptions,\n5 createTransactionMessage,\n6 generateKeyPairSigner,\n7 getSignatureFromTransaction,\n8 pipe,\n9 sendAndConfirmTransactionFactory,\n10 setTransactionMessageFeePayer,\n11 setTransactionMessageLifetimeUsingBlockhash,\n12 signTransactionMessageWithSigners,\n13} from '@solana/kit';\n14import {\n15 createNft,\n16 fetchDigitalAsset,\n17} from '@metaplex-foundation/mpl-token-metadata-kit';\n18\n19// Create RPC connection\n20const rpc = createSolanaRpc('https://api.devnet.solana.com');\n21const rpcSubscriptions = createSolanaRpcSubscriptions('wss://api.devnet.solana.com');\n22\n23// Generate keypairs (or load from wallet)\n24const authority = await generateKeyPairSigner();\n25const mint = await generateKeyPairSigner();\n26\n27// Helper function to send and confirm transactions\n28// Works with any signer type - signers are automatically extracted from instruction accounts\n29async function sendAndConfirm(options) {\n30 const { instructions, payer } = options;\n31 const { value: latestBlockhash } = await rpc.getLatestBlockhash().send();\n32\n33 const transactionMessage = pipe(\n34 createTransactionMessage({ version: 0 }),\n35 (tx) => setTransactionMessageFeePayer(payer.address, tx),\n36 (tx) => setTransactionMessageLifetimeUsingBlockhash(latestBlockhash, tx),\n37 (tx) => appendTransactionMessageInstructions(instructions, tx),\n38 );\n39\n40 // Sign with all signers attached to instruction accounts\n41 const signedTransaction = await signTransactionMessageWithSigners(transactionMessage);\n42\n43 const sendAndConfirmTx = sendAndConfirmTransactionFactory({ rpc, rpcSubscriptions });\n44 await sendAndConfirmTx(signedTransaction, { commitment: 'confirmed' });\n45\n46 return getSignatureFromTransaction(signedTransaction);\n47}\n48\n49// Create and mint an NFT using the helper function\n50const [createIx, mintIx] = await createNft({\n51 mint,\n52 authority,\n53 payer: authority,\n54 name: 'My NFT',\n55 uri: 'https://example.com/my-nft.json',\n56 sellerFeeBasisPoints: 550, // 5.5%\n57 tokenOwner: authority.address,\n58});\n59\n60// Send transaction\n61const sx = await sendAndConfirm({\n62 instructions: [createIx, mintIx],\n63 payer: authority,\n64});\n65\n66// Fetch the NFT data\n67const asset = await fetchDigitalAsset(rpc, mint.address);\n68\n69console.log('NFT created successfully!');\n70console.log('Mint address:', mint.address);\n71console.log('Signature:', sx);\n72console.log('Name:', asset.metadata.name);\n73console.log('URI:', asset.metadata.uri);\nCreating the NFTUploading the ImageThe first thing we need to do is to an image that represents the NFT and makes it recognisable. This can be in the form of jpeg, png or gif.Umi comes with downloadable storage plugins that allow you to upload to storage solutions such Arweave, NftStorage, AWS, and ShdwDrive. At start of this guide we had installed the irsyUploader() plugin which stores content on the Arweave blockchain so we'll stick with using that.Local script/Node.jsThis example is using a localscript/node.js approach using Irys to upload to Arweave. If you wish to upload files to a different storage provider or from the browser you will need to take a different approach. Importing and using fs won't work in a browser scenario.1import { createGenericFile } from '@metaplex-foundation/umi';\n2import { readFile } from 'fs/promises';\n3\n4// Assuming umi is set up with irysUploader plugin\n5// See getting-started for full setup\n6\n7// Read image from local filesystem\n8const imageFile = await readFile('./my-nft-image.png');\n9const umiImageFile = createGenericFile(imageFile, 'my-nft-image.png', {\n10 contentType: 'image/png',\n11});\n12\n13// Upload image to Arweave via Irys\n14const [imageUri] = await umi.uploader.upload([umiImageFile]);\n15\n16console.log('Image URI:', imageUri);\nUploading the MetadataOnce we have a valid and working image URI we can start working on the metadata for our NFT.The standard for offchain metadata for a fungilbe token is as follows;{\n \"name\": \"My NFT\",\n \"description\": \"This is an NFT on Solana\",\n \"image\": \"https://arweave.net/my-image\",\n \"external_url\": \"https://example.com/my-nft.json\",\n \"attributes\": [\n {\n \"trait_type\": \"trait1\",\n \"value\": \"value1\"\n },\n {\n \"trait_type\": \"trait2\",\n \"value\": \"value2\"\n }\n ],\n \"properties\": {\n \"files\": [\n {\n \"uri\": \"https://arweave.net/my-image\",\n \"type\": \"image/png\"\n }\n ],\n \"category\": \"image\"\n }\n}\nThe fields here includenameThe name of your token.symbolThe short hand of your token. Where Solana's shorthand would be SOL.descriptionThe description of your token.imageThis will be set to the imageUri (or any online location of the image) that we uploaded previously.NFT vs pNFTThe Token Metadata program can mint 2 kinds of NFTs, a normal NFT, and a pNFT (programmable Non-Fungible Asset). The main difference between the two types of NFTs here are one is royalty enforced (pNFT) and the other is not (NFT).NFTNo royatly enforcementSimpler in initial setup and to work with in future.pNFTMore accounts to deal with when it comes to future development.Royalty enforcementProgramable in which we have rulesets which can block programs from making a transfer.Minting the NftFrom here you can pick the type of NFT mint instruction you wish to use, either NFT or pNFT.NFT1import { percentAmount, generateSigner } from '@metaplex-foundation/umi';\n2import { createNft } from '@metaplex-foundation/mpl-token-metadata';\n3\n4// Assuming umi is set up with mplTokenMetadata plugin\n5// See getting-started for full setup\n6\n7const mint = generateSigner(umi);\n8\n9// Create and mint an NFT in one step\n10await createNft(umi, {\n11 mint,\n12 name: 'My NFT',\n13 uri: 'https://example.com/my-nft.json',\n14 sellerFeeBasisPoints: percentAmount(5.5),\n15 // Optional: add to collection (must verify separately)\n16 // collection: some({ key: collectionMint.publicKey, verified: false }),\n17}).sendAndConfirm(umi);\n18\n19console.log('NFT created:', mint.publicKey);\n1import { generateKeyPairSigner } from '@solana/kit';\n2import { createNft } from '@metaplex-foundation/mpl-token-metadata-kit';\n3\n4// Assuming rpc, rpcSubscriptions, and sendAndConfirmInstructions are set up\n5// See getting-started for full setup\n6\n7const mint = await generateKeyPairSigner();\n8const authority = await generateKeyPairSigner(); // Your wallet\n9\n10// Create and mint an NFT in one step\n11const [createIx, mintIx] = await createNft({\n12 mint,\n13 authority,\n14 payer: authority,\n15 name: 'My NFT',\n16 uri: 'https://example.com/my-nft.json',\n17 sellerFeeBasisPoints: 550, // 5.5%\n18 tokenOwner: authority.address,\n19 // Optional: add to collection (must verify separately)\n20 // collection: { key: collectionMint.address, verified: false },\n21});\n22\n23// Send both instructions in one transaction\n24await sendAndConfirm({\n25 instructions: [createIx, mintIx],\n26 payer: authority,\n27});\n28\n29console.log('NFT created:', mint.address);\npNFT1import { percentAmount, generateSigner } from '@metaplex-foundation/umi';\n2import { createProgrammableNft } from '@metaplex-foundation/mpl-token-metadata';\n3\n4// Assuming umi is set up with mplTokenMetadata plugin\n5\n6const mint = generateSigner(umi);\n7\n8// Create and mint a Programmable NFT in one step\n9await createProgrammableNft(umi, {\n10 mint,\n11 name: 'My Programmable NFT',\n12 uri: 'https://example.com/my-programmable-nft.json',\n13 sellerFeeBasisPoints: percentAmount(5.5),\n14 // Optional: add to collection (must verify separately)\n15 // collection: some({ key: collectionMint.publicKey, verified: false }),\n16}).sendAndConfirm(umi);\n17\n18console.log('Programmable NFT created:', mint.publicKey);\n1import { generateKeyPairSigner } from '@solana/kit';\n2import { createProgrammableNft } from '@metaplex-foundation/mpl-token-metadata-kit';\n3\n4// Assuming rpc, rpcSubscriptions, and sendAndConfirmInstructions are set up\n5\n6const mint = await generateKeyPairSigner();\n7const authority = await generateKeyPairSigner(); // Your wallet\n8\n9// Create and mint a Programmable NFT in one step\n10const [createIx, mintIx] = await createProgrammableNft({\n11 mint,\n12 authority,\n13 payer: authority,\n14 name: 'My Programmable NFT',\n15 uri: 'https://example.com/my-programmable-nft.json',\n16 sellerFeeBasisPoints: 550, // 5.5%\n17 tokenOwner: authority.address,\n18 // Optional: add to collection (must verify separately)\n19 // collection: { key: collectionMint.address, verified: false },\n20});\n21\n22// Send both instructions in one transaction\n23await sendAndConfirm({\n24 instructions: [createIx, mintIx],\n25 payer: authority,\n26});\n27\n28console.log('Programmable NFT created:', mint.address);\nWhat's Next?This guide helped you to create a basic NFT, from here you can head over to the Token Metadata Program and check out things like creating a collection and adding your new NFT into a collection and the various other interactions you can perform with your NFT.","tokens":3582,"squid":"spider-10","role":"Tooling Spider","at":1791345272374,"hash":"f1c9d1dec202827301b8f08be7241866b0e4be81"}
{"url":"https://developer.arbitrum.io/launch-arbitrum-chain/operate/bp-recovery","domain":"developer.arbitrum.io","title":"Batch poster recovery","text":"Operate your chainBatch poster recoveryLearn how the batch poster recovers state and the mechanisms that make recovery possible.Request an updateThis section covers how the batch poster recovers state after a crash, restart, or bad start—including DB restore from a batch-poster checkpoint, storage backends, revert and halt recovery, Redis failover, nonce sync, and reorg handling.\nThe batch poster is mostly stateless—its checkpoint lives on L1\nThe batch poster does not primarily checkpoint its position in its own database. On every posting attempt it reconstructs where to resume from authoritative sources: the SequencerInbox contract on plus the local inbox tracker DB. Its own data-poster DB holds only the in-flight transaction queue (transactions sent but not yet confirmed), for replace-by-fee (RBF). This is why recovery is robust: lose the data-poster DB and the poster still knows exactly where to resume.\nRecovery state machine flow\nRecovery state machine flow\nThe position \"checkpoint\"\nThis is wired as the data poster's MetadataRetriever. So the \"checkpoint\" (batchPosterPosition: message count, delayed count, next sequence number) is RLP-encoded into each transaction's metadata, but the source of truth is L1 + the inbox tracker, not a snapshot.\nfunc (b *BatchPoster) getBatchPosterPosition(ctx context.Context, blockNum *big.Int) ([]byte, error) {\n bigInboxBatchCount, err := b.seqInbox.BatchCount(...) // <-- read from L1 contract\n ...\n prevBatchMeta, err = b.batchMetaFetcher.GetBatchMetadata(inboxBatchCount - 1) // <-- inbox tracker DB\n return rlp.EncodeToBytes(batchPosterPosition{\n MessageCount: prevBatchMeta.MessageCount,\n DelayedMessageCount: prevBatchMeta.DelayedMessageCount,\n NextSeqNum: inboxBatchCount,\n })\n}\nHow resume actually works on restart\n\nFetchLast() the data-poster queue. If non-empty (transactions survived restart), resume from lastQueueItem.Nonce()+1 with its stored metadata—continues exactly where it left off, RBF-ing pending transactions.\nIf empty, call updateNonce to sync the nonce from L1, then fetch position metadata via getBatchPosterPosition. If updateNonce fails, a non-persistent queue that's still waiting for L1 finality returns an error and retries next round; otherwise the poster reads the nonce from a recent block (the \"failed to update nonce with queue empty; falling back to using a recent block\" warning).\n\nIn short: queue intact → resume in-flight; queue gone → rebuild cleanly from L1.\nStorage backends and what survives a restart\nBackendPersists?Recovery behaviordbstorageYes (consensus DB, BatchPosterPrefix table)Queue rehydrated from keyed entries; FetchContents/FetchLast reload on startupredisstorageYes (shared)Sorted-set keyed by nonce; HMAC-signed entries; enables failovernoopNoStores nothing; post-and-forget; used when parent chain is Arbitrum (no mempool)\nNotably, when the parent chain itself is an Arbitrum chain, the data poster forces no-op storage—there's no L1 mempool to RBF into, so there's nothing to persist or recover.\nRecovery mechanism 1: dangerous.clear-dbstorage\nWhen the persisted queue gets into a bad state, set --node.batch-poster.data-poster.dangerous.clear-dbstorage. At construction, with DB storage active, it calls PruneAll before starting:\nfunc (s *Storage) PruneAll(ctx context.Context) error {\n idx, err := s.lastItemIdx(ctx) // dbstorage/storage.go:94\n ...\n return s.Prune(ctx, until+1) // delete every entry through the last\n}\nPrune iterates and batch-deletes all keys below the bound and rewrites the count. After clearing, the empty-queue path above rebuilds nonce and position from L1. Use once, then unset—it discards in-flight transaction tracking, so clearing while transactions are genuinely pending risks nonce conflicts or double-posting. It's a no-op unless use-db-storage is the active backend.\nRecovery mechanism 2: revert → halt, and force-inclusion recovery\nHalt on revert.\npollForReverts watches L1; checkReverts finds a failed receipt from the poster's sender and returns shouldHalt := !UsingNoOpStorage(). On a confirmed revert it sets b.batchReverted.Store(true); MaybePostSequencerBatch then refuses to post: \"batch was reverted, not posting any more batches\". This is deliberate—a revert means something is wrong; the poster stops rather than burn funds. Recovery requires operator investigation and a restart (which clears the in-memory batchReverted flag).\n mismatch\ndangerous.allow-posting-first-batch-when-sequencer-message-count-mismatch handles the case\nwhere the poster's DB message count drifts from the chain's sequencerReportedSubMessageCount. The scenario: poster down >24h, someone force-includes a delayed message via the parent contract (which doesn't bump sequencerReportedSubMessageCount), so on restart the inbox reader's count diverges. The fix:\nprevMessageCount := batchPosition.MessageCount\nif b.config().Dangerous.AllowPostingFirstBatchWhenSequencerMessageCountMismatch && !b.postedFirstBatch {\n ...\n prevMessageCount = 0 // contract skips the prevMessageCount equality check when it's 0\n}\nSetting prevMessageCount = 0 tells the SequencerInbox to skip the equality check, so the\nfirst post goes through and re-aligns the onchain count. It applies only to the first\nbatch after startup (!b.postedFirstBatch) — once posted, the mismatch resolves itself.\nRecovery mechanism 3: Redis failover (high availability)\nMultiple posters coordinate via redislock, default Enable: true, LockoutDuration: 1m, RefreshDuration: 10s:\n\nPrimary holds the lock: the loop checks CouldAcquireLock and logs \"Not posting batches right now because another batch poster has the lock or this node is behind\" on backups.\nIf the primary crashes, the lock expires after LockoutDuration; a backup with background-lock acquires it.\nThe backup recovers shared state from Redis queue storage, which is HMAC-signed so a tampered queue is rejected. Nonce continuity comes from updateNonce against L1.\n\nSo failover state-sharing rides on persistent, signed Redis storage plus L1-derived nonce and position.\nRecovery mechanism 4: nonce/sync on restart\nupdateNonce queries the finalized (or latest) L1 nonce; when it advances past s.Nonce it logs \"Data poster transactions confirmed\" and prunes confirmed txs from the queue (Prune(ctx, nonce-1)). On a failed fetch with a prior nonce it's non-fatal (\"Failed to get current nonce\" warning). wait-for-l1-finality (default true) governs whether it tracks finalized vs latest — trading confirmation latency for reorg safety.\nReorg handling\n\nParent-chain reorg, revert polling: if the chain went backward (nextRevertCheckBlock > blockNum) it resets to re-check; the >100-block gap warning fast-forwards and skips.\nMempool nonce-gap avoidance: before sending a transaction of a different type than its predecessor (or whose predecessor isn't yet reorg-resistant), it checks the sender nonce one block back (latest − 1) and, if the nonce exceeds the reorg-resistant count, leaves the transaction queued—\"DataPoster is avoiding creating a mempool nonce gap\"—rather than risk a gap a reorg would expose.\nl1-block-bound (safe/finalized/latest/ignore) and reorg-resistance-margin (default 10m) keep batches from referencing L1 blocks that could reorg out (see also Batch poster troubleshooting).\n\nWhere state physically lives\nThe data-poster DB is a table within the consensus DB: rawdb.NewTable(consensusDB, storage.BatchPosterPrefix). The inbox tracker independently persists SequencerBatchCountKey/DelayedMessageCountKey (initialized to 0 if absent). A full DB restore therefore restores both the in-flight queue and the inbox-tracker counts—but even a wiped data-poster table self-heals from L1.\nOperator recovery cheat-sheet\n\nCorrupt or stuck queue → restart with data-poster.dangerous.clear-dbstorage (once), then\nremove it.\nBatch reverted or poster halted → investigate the revert, then restart to clear\nbatchReverted.\nMessage-count mismatch after force-inclusion or long downtime → restart with\ndangerous.allow-posting-first-batch-when-sequencer-message-count-mismatch (first batch\nonly).\nPrimary died, HA configured → automatic failover after lockout-duration; backup\nresumes from signed Redis state + L1 nonce.\nLost data-poster DB entirely → no manual action needed (just make sure there is no pending parent chain batch posting transaction); position rebuilds from L1 +\ninbox tracker, queue starts empty.\nHow is this guide?BoLD upgrade playbookSequence a BoLD upgrade when execution requires multisig or security council signatures that take days to collect, without freezing your validators for the entire window.Error indexAn index of error and log messages emitted by Arbitrum chain infrastructure, mapping each message to the guide that explains its cause and resolution.","tokens":2186,"squid":"spider-01","role":"Chain Spider","at":1791345272520,"hash":"bbe1426696c33819271ebb02f564fa1966d53a62"}
{"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":"spider-08","role":"Oracle Spider","at":1791345275075,"hash":"425f58b9240ecb8cf6164da6dfeedeb20ff0fa0f"}
{"url":"https://developer.arbitrum.io/launch-arbitrum-chain/deploy","domain":"developer.arbitrum.io","title":"Deploy an arbitrum chain","text":"Deploy an arbitrum chainDeploy an arbitrum chain documentationRequest an updateHow to deploy an Arbitrum chain using the Chain SDKHow to deploy an Arbitrum chain using the Chain SDK Deploy a token bridge using the Chain SDKHow to deploy a token bridge using the Chain SDK Canonical factory contractsLearn how to use the canonical factory contracts for deploying your Arbitrum chainRun an L3 rollup from scratchA simple A-Z guide to deploy and run a default-configured L3 rollup chain on Arbitrum Sepolia.Run testnet infrastructure on your first rollup (product-level testnet)Step-by-step guide to run your Arbitrum chain infrastructure as a production-level testnet with high availability.How is this guide?chainConfig referenceReference list of chainConfig JSON parameters available when deploying or managing your Arbitrum chain.Canonical factory contractsLearn how to use the canonical factory contracts for deploying your Arbitrum chain","tokens":235,"squid":"spider-01","role":"Chain Spider","at":1791345286236,"hash":"6542580a6891dd89107145e696837bd0b4811529"}
{"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":"spider-08","role":"Oracle Spider","at":1791345286284,"hash":"3b71d1a560853efb92622e4965d3e8dc5e1254f9"}
{"url":"https://developer.arbitrum.io/launch-arbitrum-chain/deploy/token-bridge","domain":"developer.arbitrum.io","title":"Deploy a token bridge using the Chain SDK","text":"Deploy an arbitrum chainDeploy a token bridge using the Chain SDKHow to deploy a token bridge using the Chain SDKRequest an updateRaaS providersIt is highly recommended that you work with a Rollup-as-a-Service (RaaS) provider to deploy a production chain. You can find a list of RaaS providers in our integrations directory.\nThe Arbitrum stack doesn't natively support specific token bridging standards at the protocol level. Instead, Offchain Labs designed a \"canonical token bridge\" that ensures ERC-20 token transfers between the parent and child chains.\nThe token bridge architecture includes contracts deployed on the parent and child chains. These entities communicate via the protocol, ensuring efficient and secure interactions.\nOnce you have deployed your Arbitrum chain and have a node running, you can deploy a token bridge for your chain. See the Overview for an introduction to creating and configuring an Arbitrum chain.\nBefore reading this guide, we recommend:\n\nBecoming familiar with the general process of creating new chains explained in How to deploy an Arbitrum chain\nLearning about the canonical token bridge in the Token bridging section\n\nIf you hit a problem while deploying, verifying, or registering token bridge contracts, see Token bridge troubleshooting.\nParameters used when deploying a token bridge\nBefore we describe the process of deploying a token bridge using the Chain SDK, let's look at the parameters we need to pass to the token bridge creator contract.\nDeploying a new token bridge for an Arbitrum chain is done through a TokenBridgeCreator contract that processes the creation of the needed contracts and sends the appropriate ParentToChild messages from the parent chain to the child chain so the counterpart contracts of the token bridge are created in the Arbitrum chain.\nTokenBridgeCreator has a createTokenBridge function that creates the parent chain contracts of the token bridge and sends the creation message to the Arbitrum chain via retryable tickets. createTokenBridge takes four parameters as input:\naddress inbox,\naddress rollupOwner,\nuint256 maxGasForContracts,\nuint256 gasPriceBid\nThe following table describes these parameters:\nParameterTypeDescriptioninboxaddressAddress of the Inbox contract of the chain. This is used to uniquely identify the chain.rollupOwneraddressAccount address responsible for deploying, owning, and managing your Arbitrum chain's base contracts on its parent chain.maxGasForContractsuint256Gas limit used for executing the retryable ticket on the child chain.gasPriceBiduint256Max gas price used for executing the retryable ticket on the child chain.\nWhen creating the token bridge through the Chain SDK, the parameters maxGasForContracts and gasPriceBid don't need to be configured, since the SDK will calculate the right values.\nHow to deploy a token bridge using the Arbitrum Chain SDK\nLet's look at the methods to create a token bridge using the Chain SDK.\nExample scriptThe Arbitrum Chain SDK includes an example script for deploying a token bridge. We recommend that you first understand the process described in this section and then check the create-token-bridge-eth and create-token-bridge-custom-fee-token scripts.\nDeploying a token bridge for a chain involves the following steps:\n\nApprove the custom gas token (if configured)\nDeploy the token bridge\nWait for retryable tickets to execute\nObtain the token bridge contracts (optional)\nSet up the WETH gateway\n\n1. Approve the custom gas token (if configured)\nNoteThis step is only a requirement for Arbitrum chains configured to use a custom gas token.\nBecause the token bridge creation involves sending a retryable ticket to the Arbitrum chain, the TokenBridgeCreator needs to be able to send the appropriate custom gas token amount for its execution on the child chain. That means that before calling the TokenBridgeCreator, we need to grant allowance to the contract to move our custom gas token. To facilitate this process, the Chain SDK provides two functions:\n\ncreateTokenBridgeEnoughCustomFeeTokenAllowance: This method verifies that the TokenBridgeCreator contract has enough allowance to pay for the fees associated with the token bridge deployment.\ncreateTokenBridgePrepareCustomFeeTokenApprovalTransactionRequest: This function assists in generating the raw transaction required to approve the custom gas token for the TokenBridgeCreator contract.\n\nBoth functions take the following parameters:\n\nnativeToken: the address of the custom gas token contract in the parent chain\nowner: the address of the chain owner\npublicClient: a viem's public client for the parent chain\n\nThe following example shows how to use these functions:\nimport { createPublicClient, http } from 'viem';\nimport { createTokenBridgeEnoughCustomFeeTokenAllowance, createTokenBridgePrepareCustomFeeTokenApprovalTransactionRequest } from '@arbitrum/chain-sdk';\n\nconst parentChainPublicClient = createPublicClient({\n chain: parentChain,\n transport: http(),\n});\n\nconst allowanceParams = {\n nativeToken,\n owner: rollupOwner.address,\n publicClient: parentChainPublicClient,\n};\n\nif (!(await createTokenBridgeEnoughCustomFeeTokenAllowance(allowanceParams))) {\n const approvalTxRequest = await createTokenBridgePrepareCustomFeeTokenApprovalTransactionRequest(allowanceParams);\n\n // sign and send the transaction\n const approvalTxHash = await parentChainPublicClient.sendRawTransaction({\n serializedTransaction: await rollupOwner.signTransaction(approvalTxRequest),\n });\n\n // get the transaction receipt after waiting for the transaction to complete\n const approvalTxReceipt = await parentChainPublicClient.waitForTransactionReceipt({\n hash: approvalTxHash,\n });\n}\n2. Deploy the token bridge\nTo initiate the token bridge deployment process, we can call the createTokenBridgePrepareTransactionRequest function, which will craft a transaction request to be signed by the chain owner and sent to the TokenBridgeCreator contract.\nAfter that, we wait for the transaction to be executed and retrieve its receipt with createTokenBridgePrepareTransactionReceipt.\nYou'll notice that in this case we use the rollup contract instead of the inbox contract as input for the createTokenBridgePrepareTransactionRequest function. Both contracts can uniquely identify a chain, so either can be used to find the right Inbox contract, but only the latter can be sent to the TokenBridgeCreator contract.\nBelow is an example of how to use these functions:\nimport { createPublicClient, http } from 'viem';\nimport { createTokenBridgePrepareTransactionRequest, createTokenBridgePrepareTransactionReceipt } from '@arbitrum/chain-sdk';\n\nconst parentChainPublicClient = createPublicClient({\n chain: parentChain,\n transport: http(),\n});\nconst orbitChainPublicClient = createPublicClient({\n chain: orbitChain,\n transport: http(),\n});\n\nconst txRequest = await createTokenBridgePrepareTransactionRequest({\n params: {\n rollup: coreContracts.rollup,\n rollupOwner: rollupOwner.address,\n },\n parentChainPublicClient,\n account: rollupOwner.address,\n});\n\n// sign and send the transaction\nconst txHash = await parentChainPublicClient.sendRawTransaction({\n serializedTransaction: await rollupOwner.signTransaction(txRequest),\n});\n\n// get the transaction receipt after waiting for the transaction to complete\nconst txReceipt = createTokenBridgePrepareTransactionReceipt(await parentChainPublicClient.waitForTransactionReceipt({ hash: txHash }));\n3. Wait for retryable tickets to execute\nAfter the transaction executes on the parent chain, we wait for the generated retryable tickets to execute on the child chain. To do this, we use a waitForRetryable method available in the txReceipt object returned by createTokenBridgePrepareTransactionReceipt.\nRemember that these retryable tickets intend to create the counterpart contracts of the token bridge in the child chain so that they can communicate. The first retryable ticket creates a creator contract on the child chain configured with the templates of all the token bridge contracts. The second retryable creates the actual counterpart contracts of the token bridge.\nExample:\n// wait for retryables to execute\nconsole.log(`Waiting for retryable tickets to execute on the Orbit chain...`);\nconst orbitChainRetryableReceipts = await txReceipt.waitForRetryables({\n orbitPublicClient: orbitChainPublicClient,\n});\nconsole.log(`Retryables executed`);\nconsole.log(`Transaction hash for first retryable is ${orbitChainRetryableReceipts[0].transactionHash}`);\nconsole.log(`Transaction hash for second retryable is ${orbitChainRetryableReceipts[1].transactionHash}`);\nif (orbitChainRetryableReceipts[0].status !== 'success') {\n throw new Error(`First retryable status is not success: ${orbitChainRetryableReceipts[0].status}. Aborting...`);\n}\nif (orbitChainRetryableReceipts[1].status !== 'success') {\n throw new Error(`Second retryable status is not success: ${orbitChainRetryableReceipts[1].status}. Aborting...`);\n}\n4. Obtain the token bridge contracts (optional)\nOnce the token bridge deployment is successful, you can use the getTokenBridgeContracts method to retrieve all the token bridge contracts' addresses:\nconst tokenBridgeContracts = await txReceipt.getTokenBridgeContracts({\n parentChainPublicClient,\n});\n5. Set up the WETH gateway\nNoteThat step only applies to ETH-based Arbitrum chains (i.e., not custom gas token chains). The canonical bridge design has a separate custom gateway for WETH to bridge it in and out of the Arbitrum chain.You can find more info about WETH gateways in our \"other gateways flavors\" documentation.\nOnce the token bridge deploys, if the chain uses ETH as the gas token, you must set a special gateway to bridge WETH. This gateway unwraps WETH to bridge it as ETH and wraps it back to WETH on the destination chain.\nYou can use the methods createTokenBridgePrepareSetWethGatewayTransactionRequest and createTokenBridgePrepareSetWethGatewayTransactionReceipt to set this gateway, in a similar way to what we used to send the createTokenBridge request earlier.\nThis action also sends a retryable ticket to the child chain to create and configure the WETH gateway, so you should wait to verify that the ticket executes successfully.\nBelow is an example of how to use these functions:\nimport { createPublicClient, http } from 'viem';\nimport { createTokenBridgePrepareSetWethGatewayTransactionRequest, createTokenBridgePrepareSetWethGatewayTransactionReceipt } from '@arbitrum/chain-sdk';\n\nconst parentChainPublicClient = createPublicClient({\n chain: parentChain,\n transport: http(),\n});\nconst orbitChainPublicClient = createPublicClient({\n chain: orbitChain,\n transport: http(),\n});\n\nconst setWethGatewayTxRequest = await createTokenBridgePrepareSetWethGatewayTransactionRequest({\n rollup: coreContracts.rollup,\n parentChainPublicClient,\n account: rollupOwner.address,\n});\n\n// sign and send the transaction\nconst setWethGatewayTxHash = await parentChainPublicClient.sendRawTransaction({\n serializedTransaction: await rollupOwner.signTransaction(setWethGatewayTxRequest),\n});\n\n// get the transaction receipt after waiting for the transaction to complete\nconst setWethGatewayTxReceipt = createTokenBridgePrepareSetWethGatewayTransactionReceipt(await parentChainPublicClient.waitForTransactionReceipt({ hash: setWethGatewayTxHash }));\n\n// Wait for retryables to execute\nconst orbitChainSetWethGatewayRetryableReceipt = await setWethGatewayTxReceipt.waitForRetryables({\n orbitPublicClient: orbitChainPublicClient,\n});\nconsole.log(`Retryables executed`);\nconsole.log(`Transaction hash for retryable is ${orbitChainSetWethGatewayRetryableReceipt[0].transactionHash}`);\nif (orbitChainSetWethGatewayRetryableReceipt[0].status !== 'success') {\n throw new Error(`Retryable status is not success: ${orbitChainSetWethGatewayRetryableReceipt[0].status}. Aborting...`);\n}\nYou must verify Arbitrum chain contracts' source codeWe have provided a script that will perform the source code verification of all the contracts deployed by the L1AtomicTokenBridgeCreator to the specific Arbitrum chain. The script is available in the Token Bridge Contracts repo.How is this guide?Token bridge troubleshootingDiagnose and resolve common token bridge problems including ENS errors on non-Ethereum parent chains, unverified WETH contracts, bridged USDC routing to the wrong gateway, custom gateway registration failures, and outboundTransfer reverts.Extend the protocolAdvanced configurations for your chain.","tokens":3109,"squid":"spider-01","role":"Chain Spider","at":1791345308198,"hash":"19b66edf5ac488691db190b65450a561cfb73a86"}
{"url":"https://akash.network/docs/developers/contributing/development-environment/","domain":"akash.network","title":"Node & Provider Development Environment | Akash Network - Your Guide to Decentralized Cloud","text":"Node & Provider Development Environment Set up a complete Kubernetes development environment for node and provider development.\nThis guide covers the complex setup required for contributing to Akash node and provider repositories, including local Kind clusters and remote SSH clusters.\nFor Console and website development, see Console & Website Setup - much simpler!\n\nPrerequisites\nRequired for Node & Provider Development\n\nGit - Version control\nGitHub Account - For forking and PRs\nCode Editor - VS Code, GoLand, or your preference\nGo - 1.25.0 or later (latest version)\nDocker Engine/Desktop - For Kind clusters\nGNU Make - 4.0 or later\nBash - 4.0 or later\nDirenv - 2.32.x or later\n\nSystem-Specific Setup\nmacOS\nInstall Homebrew\nTerminal window/bin/bash -c \"$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)\"\nInstall Development Tools\nTerminal window# Core toolsbrew install go node git make\n# Additional utilitiesbrew install wget jq curl gnu-getopt direnv\n# GNU Make (macOS default is outdated)brew install makeexport PATH=\"/usr/local/opt/make/libexec/gnubin:$PATH\"\nAdd to your ~/.zshrc or ~/.bashrc:\nTerminal windowexport PATH=\"/usr/local/opt/make/libexec/gnubin:$PATH\"\nSetup Direnv\nDirenv manages environment variables per project:\nTerminal window# Installbrew install direnv\n# Add to ~/.zshrcecho 'eval \"$(direnv hook zsh)\"' >> ~/.zshrc\n# Or add to ~/.bashrcecho 'eval \"$(direnv hook bash)\"' >> ~/.bashrc\n# Reload shellsource ~/.zshrc # or source ~/.bashrc\n\nLinux (Ubuntu/Debian)\nInstall Development Tools\nTerminal window# Update package listsudo apt-get update\n# Install Gocd /tmpwget https://go.dev/dl/go1.25.0.linux-amd64.tar.gzsudo rm -rf /usr/local/gosudo tar -C /usr/local -xzf go1.25.0.linux-amd64.tar.gz\n# Add Go to PATHecho 'export PATH=$PATH:/usr/local/go/bin' >> ~/.bashrcsource ~/.bashrc\n# Verifygo version\n# Install Node.js (via nvm recommended)curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.0/install.sh | bashsource ~/.bashrcnvm install 22nvm use 22\n# Install other toolssudo apt-get install -y make git wget curl jq build-essential direnv\n# Setup direnvecho 'eval \"$(direnv hook bash)\"' >> ~/.bashrcsource ~/.bashrc\n\nWindows (WSL2 Recommended)\nUse Windows Subsystem for Linux 2:\nTerminal window# In PowerShell (Admin)wsl --install -d Ubuntu\n# Restart, then follow Linux instructions above\n\nNode & Provider Development Environment\nThe node and provider repositories require a complete Kubernetes development environment. This guide covers both local and remote cluster setups.\nOverview\nThis page covers setting up a development environment for both node and provider repositories. The provider repository contains all setup scripts as it depends on the node repository.\nDevelopment approaches:\n\nLocal Kind Cluster (kube) - Most common, runs locally with Docker\nSingle Node Cluster (single) - All services run as Kubernetes deployments\nRemote SSH Cluster (ssh) - For testing GPU workloads and IP leases\nMinikube - Alternative local cluster (not commonly used)\n\nRequirements\nSoftware Requirements\nCore:\n\nGo - 1.25.0 or later (latest version required)\nDocker Engine/Desktop - For containerization\nGNU Make - 4.0 or later\nBash - 4.0 or later\nDirenv - 2.32.x or later\nwget - For downloads\nrealpath - Path utilities\n\nAdditional:\n\nunzip\ncurl\nnpm\njq\nreadlink\ngit\n\nmacOS Specific:\n\nHomebrew\ngnu-getopt (brew install gnu-getopt)\n\nVerify versions:\nTerminal windowgo versionmake --versionbash --versiondirenv version\nInstall All Dependencies (Automated)\nTerminal window# Clone repositories firstmkdir -p ~/go/src/github.com/akash-networkcd ~/go/src/github.com/akash-networkgit clone https://github.com/akash-network/node.gitgit clone https://github.com/akash-network/provider.git\n# Run automated installer (macOS and Debian-based Linux)./provider/script/install_dev_dependencies.sh\nSupported platforms:\n\nmacOS\nDebian-based Linux\nWindows (not supported - use WSL2)\n\nRunbook Structure\nAll development configurations are in the provider/_run directory:\nprovider/_run/├── kube/ # Local Kind cluster (most common)├── single/ # All services in Kubernetes├── ssh/ # Remote cluster via SSH└── minikube/ # Minikube setup\nCommands are implemented as make targets. All runbooks share the same commands once set up.\n\nEnvironment Parameters\nCommon parameters available across all runbooks:\n\nParameterDefaultApplies ToDescriptionSKIP_BUILDfalseAllSkip binary rebuildsDSEQ1deployment-, lease-, bid-*, send-manifestDeployment sequenceOSEQ1deployment-, lease-, bid-*, send-manifestOrder sequenceGSEQ1deployment-, lease-, bid-*, send-manifestGroup sequenceKUSTOMIZE_INSTALLSVarieskustomize-*Components to installKUBE_ROLLOUT_TIMEOUT120AllKubernetes rollout timeout (seconds)\nUsage:\nTerminal windowKUBE_ROLLOUT_TIMEOUT=300 make kube-cluster-setupDSEQ=5 GSEQ=2 make query-deployments\n\nLocal Kind Cluster Setup (Recommended)\nPurpose: Complete local development environment using Kubernetes in Docker.\nOverview\nThe Kind (Kubernetes in Docker) runbook creates a local cluster where:\n\nNode and provider run as host services\nOperators run as Kubernetes deployments\nComplete end-to-end testing capability\n\nThis is the most widely used development setup.\nPrerequisites\n\nDocker Desktop/Engine running\nDirenv configured\nAll dependencies installed\n\nSetup Steps\n\nNote: This requires three simultaneous terminals. We’ll call them terminal1, terminal2, and terminal3.\n\nSTEP 1 - Navigate to Kube Directory\nRun on all three terminals:\nTerminal windowcd ~/go/src/github.com/akash-network/provider/_run/kube\nSTEP 2 - Create and Provision Local Cluster\nRun on terminal1 only:\nTerminal window# This may take several minutesmake kube-cluster-setup\nWhat this does:\n\nCreates a local Kind cluster\nSets up ingress controller\nConfigures networking\nInstalls required components\n\nIf timeout occurs:\nThe ingress controller may take longer to initialize. If you see:\nerror: timed out waiting for the conditionmake: *** [kube-setup-ingress-default] Error 1\nRun with extended timeout:\nTerminal windowcd ~/go/src/github.com/akash-network/provider/_run/kubemake kube-cluster-deletemake cleanmake initKUBE_ROLLOUT_TIMEOUT=300 make kube-cluster-setup\nGoreleaser version issue:\nIf you see Unable to find image 'ghcr.io/goreleaser/goreleaser-cross:v':\nTerminal windowexport GOVERSION_SEMVER=v1.24.2KUBE_ROLLOUT_TIMEOUT=300 make kube-cluster-setup\nSTEP 3 - Start Akash Node\nRun on terminal2:\nTerminal windowmake node-run\nExpected output:\n\nNode starts and begins syncing\nBlockchain state initializes\nRPC and API servers start\n\nKeep this terminal running - you’ll see node logs here.\nSTEP 4 - Create Provider\nRun on terminal1:\nTerminal windowmake provider-create\nWhat this does:\n\nRegisters provider on the blockchain\nCreates provider account\nSets provider attributes\n\nSTEP 5 - Start Provider\nRun on terminal3:\nTerminal windowmake provider-run\nExpected output:\n\nProvider connects to node\nBidding engine starts\nCluster monitoring begins\n\nKeep this terminal running - you’ll see provider logs here.\nSTEP 6 - Test Deployment Workflow\nRun on terminal1:\nTerminal window# Create a test deploymentmake deployment-create\n# Query the deploymentmake query-deployments\n# Check for ordersmake query-orders\n# View provider bidsmake query-bids\n# Create a leasemake lease-create\n# Verify leasemake query-leases\n# Send deployment manifestmake send-manifest\n# Check lease statusmake provider-lease-status\n# Test connectivitymake provider-lease-ping\n# View deployment logsmake provider-lease-logs\nCleanup and Reset\nFull cleanup:\nTerminal windowcd ~/go/src/github.com/akash-network/provider/_run/kubemake kube-cluster-deletemake cleanmake init\nRestart services only:\nTerminal window# Stop servicesmake provider-stopmake node-stop\n# Restartmake node-run # in terminal2make provider-run # in terminal3\n\nRemote SSH Cluster Setup (Advanced)\nPurpose: Test GPU workloads, IP leases, or production-like deployments.\nOverview\nThe SSH runbook connects to a remote Kubernetes cluster for:\n\nGPU provider testing\nIP lease functionality\nProduction environment simulation\nComplex networking scenarios\n\nPrerequisites\nRemote Cluster:\n\nKubernetes cluster with external API access\nSSH access to cluster nodes\nkubectl configured\nGPU drivers (for GPU testing)\n\nLocal Machine:\n\nSSH key configured\nkubectl installed\nDirenv configured\n\nRemote Cluster Preparation\nOn Remote Cluster\nTerminal window# Install containerd (if not already installed)apt-get update && apt-get install -y containerd\n# Install nerdctl for image managementwget https://github.com/containerd/nerdctl/releases/download/v1.7.0/nerdctl-1.7.0-linux-amd64.tar.gztar Cxzvvf /usr/local/bin nerdctl-1.7.0-linux-amd64.tar.gzrm nerdctl-1.7.0-linux-amd64.tar.gz\n# Verify installationnerdctl --version\nGenerate Kubeconfig for External Access\nTerminal window# On remote cluster, create external kubeconfigkubectl config view --raw > /tmp/external-kubeconfig.yaml\n# Get cluster's external IPEXTERNAL_IP=$(curl -s ifconfig.me)echo \"Cluster external IP: $EXTERNAL_IP\"\n# Replace localhost with external IPsed -i \"s|https://127.0.0.1:6443|https://$EXTERNAL_IP:6443|\" /tmp/external-kubeconfig.yaml\n# Skip TLS verification (development only!)kubectl config set-cluster cluster.local \\ --insecure-skip-tls-verify=true \\ --kubeconfig /tmp/external-kubeconfig.yaml\n# Test from remote hostKUBECONFIG=/tmp/external-kubeconfig.yaml kubectl get nodes\nCopy Kubeconfig to Local Machine\nTerminal window# From your local machinescp -i ~/.ssh/your-key root@<CLUSTER_IP>:/tmp/external-kubeconfig.yaml ~/.kube/remote-cluster-config\n# Set KUBECONFIGexport KUBECONFIG=~/.kube/remote-cluster-config\n# Test connectionkubectl get nodes\nLocal Setup\nSTEP 1 - Navigate to SSH Directory\nTerminal windowcd ~/go/src/github.com/akash-network/provider/_run/ssh\nSTEP 2 - Configure Environment\nEdit .envrc:\nTerminal windowvim .envrc\nAdd/verify these settings:\nTerminal windowsource_up .envrcdotenv_if_exists dev.env\nAP_RUN_NAME=$(basename \"$(pwd)\")AP_RUN_DIR=\"${DEVCACHE_RUN}/${AP_RUN_NAME}\"\nexport AKASH_HOME=\"${AP_RUN_DIR}/.akash\"export AKASH_KUBECONFIG=$KUBECONFIGexport AP_KUBECONFIG=$KUBECONFIGexport AP_RUN_NAMEexport AP_RUN_DIRexport KUBE_SSH_NODES=\"root@<YOUR_CLUSTER_IP>\"\nReload environment:\nTerminal windowdirenv allow\n# Verifyecho \"KUBE_SSH_NODES: $KUBE_SSH_NODES\"echo \"KUBECONFIG: $KUBECONFIG\"\nSTEP 3 - Initialize Environment\nTerminal windowmake init\nSTEP 4 - Set Up Remote Cluster\nFor standard workloads:\nTerminal windowKUBE_ROLLOUT_TIMEOUT=300 make kube-cluster-setup\nFor GPU workloads:\nTerminal windowKUBE_ROLLOUT_TIMEOUT=300 make kube-cluster-setup-gpu\nWhat this does:\n\nCreates namespaces\nSets up ingress controller\nInstalls Helm charts\nConfigures GPU support (if GPU target)\n\nSTEP 5 - Start Services\nRun these in separate terminals:\nTerminal 1 - Start Node:\nTerminal windowcd ~/go/src/github.com/akash-network/provider/_run/sshexport KUBECONFIG=~/.kube/remote-cluster-configdirenv reload\nmake node-run\nTerminal 2 - Create Provider:\nTerminal windowcd ~/go/src/github.com/akash-network/provider/_run/sshexport KUBECONFIG=~/.kube/remote-cluster-configdirenv reload\nmake provider-create\nTerminal 3 - Run Provider:\nTerminal windowcd ~/go/src/github.com/akash-network/provider/_run/sshexport KUBECONFIG=~/.kube/remote-cluster-configdirenv reload\nmake provider-run\nSTEP 6 - Test Deployment\nSame commands as local Kind cluster:\nTerminal windowmake deployment-createmake query-deploymentsmake lease-createmake send-manifestmake provider-lease-status\nSSH Cluster Troubleshooting\nSSH Permission Denied:\n\nVerify SSH key is loaded: ssh-add -l\nTest SSH access: ssh root@<CLUSTER_IP>\n\nKubeconfig Access Issues:\n\nVerify external IP is reachable\nCheck firewall rules for port 6443\nEnsure TLS verification is skipped\n\nImage Upload Failures:\n\nVerify nerdctl is installed on nodes\nCheck containerd is running\nTest: ssh root@<CLUSTER_IP> nerdctl version\n\nTimeout Errors:\n\nIncrease timeout: KUBE_ROLLOUT_TIMEOUT=600\nCheck network latency\nVerify cluster resources\n\nReset SSH Environment\nTerminal windowcd ~/go/src/github.com/akash-network/provider/_run/sshmake init\n\nCommon Make Targets\nOnce any runbook is set up, these commands work across all environments:\nDeployment Commands:\nTerminal windowmake deployment-create # Create test deploymentmake deployment-update # Update deploymentmake deployment-close # Close deployment\nQuery Commands:\nTerminal windowmake query-deployments # List all deploymentsmake query-orders # List ordersmake query-bids # List bidsmake query-leases # List leasesmake query-providers # List providers\nLease Commands:\nTerminal windowmake lease-create # Create lease from bidmake send-manifest # Send manifest to providermake provider-lease-status # Check lease statusmake provider-lease-logs # View deployment logsmake provider-lease-ping # Test connectivity\nProvider Commands:\nTerminal windowmake provider-create # Register providermake provider-run # Start provider servicemake provider-stop # Stop provider\nNode Commands:\nTerminal windowmake node-run # Start local nodemake node-stop # Stop node\n\nTroubleshooting\nCommon Issues\nDocker not running:\nTerminal window# macOSopen -a Docker\n# Linuxsudo systemctl start docker\nDirenv not loading:\nTerminal window# Check hook is configuredgrep direnv ~/.zshrc\n# If missingecho 'eval \"$(direnv hook zsh)\"' >> ~/.zshrcsource ~/.zshrc\n# Allow in projectdirenv allow\nPort already in use:\nTerminal window# Find process using portlsof -i :8080 # or other port\n# Kill processkill -9 <PID>\nKind cluster won’t start:\nTerminal window# List existing clusterskind get clusters\n# Delete old clusterkind delete cluster --name akash\n# Retry setupmake kube-cluster-setup\nBuild fails with Go version error:\nTerminal window# Set Go versionexport GOVERSION_SEMVER=v1.24.2\n# Verifyecho $GOVERSION_SEMVER\n# Retry buildmake kube-cluster-setup\nProvider won’t connect to node:\n\nVerify node is running in terminal2\nCheck node logs for errors\nEnsure provider was created: make query-providers\n\nNo bids on deployment:\n\nCheck provider is running in terminal3\nVerify provider attributes match deployment requirements\nCheck provider logs for errors\n\nDebug Commands\nTerminal window# Check cluster statuskubectl get nodeskubectl get pods --all-namespaces\n# Check kind clusterkind get clustersdocker ps\n# View provider logsmake provider-logs\n# View node logsmake node-logs\n# Check blockchain statusmake query-block-results\n\nAdvanced Topics\nCustom SDL Files\nPlace custom SDL files in _run/kube/deployment.yaml (or ssh/single):\nversion: \"2.0\"services: web: image: nginx:latest expose: - port: 80 to: - global: trueprofiles: compute: web: resources: cpu: units: 0.5 memory: size: 512Mi storage: size: 512Mi placement: akash: pricing: web: denom: uact amount: 1000deployment: web: akash: profile: web count: 1\nThen deploy:\nTerminal windowmake deployment-create\nTesting Different Scenarios\nTest bid rejection:\nTerminal window# Set very low pricingDSEQ=1 make deployment-create# Provider should reject bid\nTest multiple deployments:\nTerminal windowDSEQ=1 make deployment-createDSEQ=2 make deployment-createDSEQ=3 make deployment-createmake query-deployments\nTest deployment updates:\nTerminal windowmake deployment-create# Modify deployment.yamlmake deployment-update\n\nNext Steps\nAfter setup:\n\nExplore _run/kube/Makefile to see all available targets\nRead provider logs to understand bidding logic\nExperiment with different SDL configurations\nTest various deployment scenarios\n\nOther Development Guides:\n\nConsole & Website Setup - Web development (easier)\nGetting Started - Make your first contribution\nCode Conventions - Coding standards\n\nResources:\n\nNode Repository - Blockchain node source\nProvider Repository - Provider services source\n\nEditor Setup\nVS Code (Recommended)\nInstall Go extension:\nTerminal windowcode --install-extension golang.go\nWorkspace settings (.vscode/settings.json):\n{ \"go.formatTool\": \"goimports\", \"go.lintTool\": \"golangci-lint\", \"go.useLanguageServer\": true, \"editor.formatOnSave\": true, \"[go]\": { \"editor.formatOnSave\": true, \"editor.codeActionsOnSave\": { \"source.organizeImports\": true } }, \"go.testFlags\": [\"-v\"], \"go.testTimeout\": \"10s\"}\nGoLand (Recommended for Go Development)\n\nOpen provider or node directory\nConfigure Go SDK - Point to your Go 1.25+ installation\nEnable gofmt on save - Settings → Tools → File Watchers\nSet up golangci-lint - Settings → Tools → golangci-lint\nConfigure Kubernetes - Settings → Languages & Frameworks → Kubernetes\nEnable Direnv - Settings → Plugins → Install Direnv plugin\n\nCommon Development Tools\nMake Commands\nAll Akash Go projects use Makefiles:\nTerminal window# View all available commandsmake help\n# Run testsmake test\n# Run lintermake lint\n# Build binariesmake build\n# Clean build artifactsmake clean\n# Install dependenciesmake cache\nGit Workflow\nTerminal window# Keep your fork updatedgit fetch upstreamgit checkout maingit merge upstream/main\n# Create feature branchgit checkout -b feature/your-feature\n# Make changes, commit, pushgit add .git commit -s -m \"feat: your change\"git push origin feature/your-feature\nTesting\nRun all tests:\nTerminal windowmake test\nRun specific package tests:\nTerminal windowgo test ./pkg/specific-packagego test ./bidengine/...\nRun with coverage:\nTerminal windowmake test-coverage\nIntegration tests:\nTerminal windowmake test-integration\nVerbose output:\nTerminal windowgo test -v ./...\n\nTroubleshooting\n”Command not found” Errors\nProblem: go, make, or node not in PATH\nSolution:\nTerminal window# macOS - Add to ~/.zshrcexport PATH=$PATH:/usr/local/go/bin:$HOME/go/bin\n# Linux - Add to ~/.bashrcexport PATH=$PATH:/usr/local/go/bin:$HOME/go/bin\n# Reloadsource ~/.zshrc # or ~/.bashrc\nMake Version Too Old (macOS)\nProblem: make: unrecognized option '--version'\nSolution:\nTerminal windowbrew install makeexport PATH=\"/usr/local/opt/make/libexec/gnubin:$PATH\"\nGo Module Issues\nProblem: go: module not found\nSolution:\nTerminal window# Clear module cachego clean -modcache\n# Re-download dependenciesgo mod download\n# Verify go.modgo mod verify\nDirenv Not Working\nProblem: Environment variables not loading\nSolution:\nTerminal window# Re-allow direnvdirenv allow\n# Check hook is installedgrep direnv ~/.zshrc # or ~/.bashrc\n# If missing, add:eval \"$(direnv hook zsh)\" # or bash\nPort Already in Use\nProblem: Dev server won’t start (port 3000 or 4321)\nSolution:\nTerminal window# Find process using portlsof -i :3000 # or :4321\n# Kill processkill -9 <PID>\n# Or use different portnpm run dev -- --port 3001\nPermission Denied\nProblem: Can’t write to directories\nSolution:\nTerminal window# Fix ownership (macOS/Linux)sudo chown -R $USER:$USER ~/path/to/repo\n# Or use sudo for npm (not recommended)# Instead, fix npm permissions:mkdir ~/.npm-globalnpm config set prefix '~/.npm-global'export PATH=~/.npm-global/bin:$PATH\n\nIDE Debugging\nVS Code - Go Debugging\nCreate .vscode/launch.json:\n{ \"version\": \"0.2.0\", \"configurations\": [ { \"name\": \"Launch Package\", \"type\": \"go\", \"request\": \"launch\", \"mode\": \"auto\", \"program\": \"${fileDirname}\" }, { \"name\": \"Attach to Process\", \"type\": \"go\", \"request\": \"attach\", \"mode\": \"local\", \"processId\": \"${command:pickProcess}\" } ]}\nVS Code - Node.js Debugging\nCreate .vscode/launch.json:\n{ \"version\": \"0.2.0\", \"configurations\": [ { \"type\": \"node\", \"request\": \"launch\", \"name\": \"Next.js: debug server-side\", \"runtimeExecutable\": \"npm\", \"runtimeArgs\": [\"run\", \"dev\"], \"port\": 9229 } ]}\n\nPerformance Tips\nSpeed Up Go Builds\nTerminal window# Use build cacheexport GOCACHE=$HOME/.cache/go-build\n# Parallel buildsmake -j8 build\nSpeed Up npm installs\nTerminal window# Use pnpm (faster alternative)npm install -g pnpmpnpm install\n# Or use npm ci for clean installsnpm ci\n\nNext Steps\nEnvironment set up? Great!\n\nGetting Started - Make your first contribution\nCode Conventions - Learn coding standards\nPull Request Process - Submit your changes\n\nNeed help? Ask in Discord #developers! \nEdit page on github\n Getting Started Console & Website Setup","tokens":4963,"squid":"spider-03","role":"Compute Spider","at":1791345308370,"hash":"56f848e94fc6e9b53e81c660549c7a236fdbc4b4"}
{"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":"spider-08","role":"Oracle Spider","at":1791345317316,"hash":"161d5f9b5a0a41465a69e3d959845481edead08d"}
{"url":"https://akash.network/docs/getting-started/console-air-onboarding/","domain":"akash.network","title":"Console Air Onboarding Guide | Akash Network - Your Guide to Decentralized Cloud","text":"Console Air Onboarding Guide Console Air is the self-custody deployment interface for Akash Network. Unlike the standard Console (which uses email/OAuth and custodial trial credits), Console Air connects directly to your Web3 wallet, giving you full control over your AKT and ACT tokens at every step.\n\nConsole (managed)Console Air (self-custody)LoginEmail / Google / GitHubWeb3 wallet (Keplr, Cosmostation, MetaMask)Credits$1 trial credits, no AKT neededRequires AKT tokens in walletCustodyCustodial — Akash manages escrowSelf-custody — you sign every transactionBest forNew usersExperienced Web3 users\nNot sure which to use? See Choosing your Console.\nStep 1 — Open Console Air & Connect Your Wallet\nNavigate to Console Air. The home screen shows the sidebar navigation and a welcome panel with three quick-start links:\n\nGetting started with Console Air — deploy your first Docker container\nExplore the marketplace — pre-made solutions: AI, blogs, blockchain nodes and more\nLearn more about Akash — decentralized cloud compute background\n\nThe sidebar gives you access to:\n\nDeploy — launch the deployment wizard\nDeployments — manage existing deployments\nTemplates — browse pre-built app templates\nSDL Builder — write/edit Akash Stack Definition Language configs\nProviders — browse the live compute provider network\n\n💡 No wallet connected yet = read-only mode. You can browse templates and providers but cannot deploy until a wallet is connected.\n\nStep 2 — Select Your Wallet\nClick “Connect Wallet” in the top-right corner. A modal appears with the following options:\nBrowser Extensions\n\nKeplr — the most widely used Cosmos wallet. Recommended for most users.\nCosmostation — alternative Cosmos ecosystem wallet with browser extension.\nCosmos MetaMask Extension — connects your existing MetaMask via the Cosmos snap.\n\nMobile\n\nKeplr Mobile — connect via WalletConnect QR code from the Keplr iOS/Android app.\n\n⚠️ You need AKT tokens in your wallet before you can deploy. AKT is the native token of Akash Network. You can acquire it on major exchanges including Osmosis, Crypto.com, Kraken, and Coinbase.\n\nStep 3 — Fund Your Deployment with ACT\nOnce your wallet is connected, your Akash address and AKT/ACT balances appear in the top-right corner.\nConsole Air uses ACT (Akash Credits Token) as the escrow currency for deployments — not AKT directly. You need to mint ACT from your AKT before deploying:\n\nGo to your wallet balance in the top-right\nSelect “Mint ACT from AKT”\nChoose the amount to convert and confirm the transaction in your wallet\n\n💡 ACT is burned as your deployment runs. Any unused ACT can be reclaimed when you close a deployment. Think of it as a prepaid compute credit.\n\nStep 4 — Deploy\nClick “Deploy” in the sidebar or use a Template. The deployment flow mirrors the standard Console:\n\nChoose a template or provide your own Docker image / SDL config\nConfigure compute resources (CPU, RAM, storage, optional GPU)\nClick “Request quotes” to fetch live bids from providers\nReview provider bids — compare region, uptime, and price\nSelect a provider → your wallet prompts you to sign the lease transaction\nDeployment starts after the on-chain lease is confirmed\n\n💡 The provider bid list and marketplace are identical to the standard Console. See the Console Onboarding Guide for a full breakdown of the 3-column configurator and provider bid table.\n\nBackground & Further Reading\n\nConsole Air announcement — explains the Console vs Console Air split and the rationale for the self-custody flow.\nAEP-84 — the design spec behind Console Air.\nDeploy with Console Air — detailed deployment walkthrough in the official docs.\nChoosing your Console — decision guide: Console vs Console Air.\n\nEdit page on github\n Console Onboarding Quick Start","tokens":937,"squid":"spider-03","role":"Compute Spider","at":1791345320353,"hash":"342a1010b19497a227951dc0031056e0b50567e1"}
{"url":"https://forum.arbitrum.foundation/t/synapse-protocol-final-stip-round-1/17550","domain":"forum.arbitrum.foundation","title":"[Synapse Protocol] [FINAL][STIP - Round 1] - Archive / Short Term Incentives Program (STIP) Round 1 - Arbitrum","text":"The Arbitrum Foundation notified the Security Council on the need to perform a potential Emergency action. Following a review of the details and known risks, the Security Council decided to execute the upgrade and it was completed at 11:30 EST on 2nd October 2026.\nThis report provides an overview of the risks that required the Security Council Action:\n\nAdd a permissionless guard for the One-Step Proof of BoLD on Arbitrum One\n\nTemporarily pause activation of new Stylus contracts on Arbitrum One & Nova\n\nKey point: To date, known bugs for Stylus primarily impact chain liveness (e.g., denial of service attacks) and do not put any user funds at risk.\nWhy was this action taken\nLet’s take this opportunity to explain why action was taken on two separate issues concerning BoLD and Stylus.\nInstalling the guard for One-Step Proof of BoLD. Given the rise of AI-assisted attacks, we have implemented a precautionary approach that allows anyone to pause settlement of Arbitrum One on Ethereum if there are at least two conflicting answers that pass at the same level in which only one should be valid and pass. This is to halt a class of publicly verifiable and detectable attacks that exploit a bug in the one-step proof. If halted, Arbitrum One will continue to process as normal except that messages from Arbitrum One to Ethereum, such as withdrawals, that are not yet confirmed will have to wait. This provides time for the Security Council to deploy a fix for the bug and resume the rollup.\nPreventing activation of new Stylus contracts. AI-assisted tooling has led to an increasing number of sophisticated attacks on hand-crafted WASM programs that do not use the standard Stylus compiler toolchain. These programs are specifically designed to cause unexpected behaviors such as degrading the chain’s performance for all other users. To date, no attacks have been discovered that permits theft of user funds.\nNew ArbOS releases have patched several reported bugs and known attacks over the past few months, but out of an abundance of caution, we have decided to temporarily pause new activations of Stylus contracts. This was executed as an emergency action to prevent the deployment of new hand-crafted WASM programs that are not yet patched by the current version of ArbOS on the Arbitrum network.\nThe Arbitrum Foundation has informed the Security Council that they will work with the ArbitrumDAO to discuss next steps on the timeline and manner for enabling activation of new Stylus contracts. The Arbitrum community remains confident in the value of Stylus and want to preserve these use cases while taking preventative measures against Stylus-based attack vectors as AI-assisted attack tooling continues to evolve.\nImpact on builders and users\n\nNo new activations. New Stylus contracts cannot be activated during the pause including new versions of existing applications that require activation.\n\nExisting contracts are not paused. Already-active Stylus contracts continue to execute until expiration. This pause does not deactivate them.\n\nThe ArbOS 61 upgrade renewed all active contracts on Arbitrum One, so no currently active contract expires before August 20, 2027.\n\nRenewal via keepalive stays permissionless and is unaffected by the pause.\n\nReactivating an expired contract, or one that needs to be updated after a Stylus version change, is paused.\n\nUsing/calling any activated Stylus contract stays permissionless for all users and developers.\n\nNo impact on EVM. Solidity (EVM) contract deployment and execution are unaffected by this Security Council action.\n\nSecurity Council Actions\nThere are two actions bundled into a single payload:\n\nOne-Step Proof Guard. The L1UpgradeExecutor gives a new pause contract (PauseExecutor) the ability to pause and nothing else. The new pause contract grants the guard (OspSoundnessGuard) PAUSER_ROLE to use it. Anyone can show the guard two conflicting answers to the same step of an open challenge. If the one-step proof accepts both, the guard has the pause contract put Arbitrum One’s settlement to Ethereum on hold.\n\nStylus deactivation. The Security Council called ArbOwner.setWasmActivationGas(2^64 - 1) to raise the Stylus activation gas requirement on Arbitrum One and Nova. This makes activation prohibitively expensive and effectively disables new activations. This is a configuration change and does not require an ArbOS upgrade.\n\nThe Security Council signed the following transactions to update the configuration:\n\nEthereum: Ethereum Transaction Hash: 0x30732bb7d2... | Etherscan\nArbitrum One:\nArbitrum One Transaction Hash: 0x9eb3a4be3b... | Arbitrum One\nArbitrum Nova:\nArbitrum Nova transaction 0x79e0fed470dff7a22059b108e3f8f42eddd2b580a6771594060c4e7326c5f984 | Blockscout\n\nAn external audit was conducted for the OSP Guard contracts. No audit is required for the Stylus deactivation as it is only updating a single parameter in the ArbOS configuration.\n\n [Synapse Protocol] [FINAL][STIP - Round 1] \n\n ArchiveShort Term Incentives Program (STIP) Round 1\n\n proposal\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Sep 2023\n\n 1 / 27\n\n Sep 2023\n\n Dec 2023\n\n post by moses on Sep 27, 2023\n\n moses\n\n SECTION 1: APPLICANT INFORMATION\nProvide personal or organizational details, including applicant name, contact information, and any associated organization. This information ensures proper identification and communication throughout the grant process.\nApplicant Name: Moses\nProject Name: Synapse Protocol\nProject Description: Synapse is the most widely used, extensible, secure cross-chain platform.\nTeam Members and Qualifications:\nAurelius - Core Team Member\nSocrates - Core Team Member\nMoses - Core Team Member\nThe team members above are a fraction of the contributors to the protocol but contribute to development, maintenance and growth of Synapse Protocol.\nProject Links:\nhttps://twitter.com/SynapseProtocol\nGitHub\n\nContact Information:\nTG: @defi_moses\nTwitter: @defi_moses\nEmail: moses@synapseprotocol.com\nDo You Acknowledge That Your Team WIll Be Subject to a KYC Requirement?: Yes\nSECTION 2: GRANT INFORMATION\nDetail the requested grant size, provide an overview of the budget breakdown, specify the funding and contract addresses, and describe any matching funds if relevant.\nRequested Grant Size:\n2,000,000 ARB\nGrant Matching:\nSynapse will match the grant fully as well as continue to provide liquidity mining rewards on Arbitrum. In the past year, Synapse has supported the Arbitrum ecosystem with 4M+ SYN($3M+).\nGrant Breakdown: [Please provide a high-level overview of the budget breakdown and planned use of funds]\nThis grant’s aim is to achieve two primary objectives:\n\nSlippage-free bridging - 1.5M ARB will be used to support faster and cheaper bridging. Using Synapse’s concentrated liquidity pools and traditional stableswap pools, Synapse’s aim is for any Arbitrum user to bridge up to $5M slippage-free. Concentrated liquidity bridging is similar to going from Uni V2 to Uni V3, allowing slippage-free bridging. This will massively improve Arbitrum’s UX, lowering costs for users and incentivizing users to bring their assets in from other chains.\n\nSupport Arbitrum partners - Synapse is the native bridge partner for many Arbitrum tokens including GMX, FRAX, OHM, VSTA, SDT etc. 500k ARB will be used to support these projects and their users bridging to Arbitrum. Users bridging partner tokens to Arbitrum as well as new tokens launching on Arbitrum will receive gas & fee rebates.\n\nTo date, Synapse has facilitated $8B in volume across 700k transactions and 200k wallets on Arbitrum, bringing billions of dollars of stablecoins and other assets to Arbitrum. Additionally, Synapse is the native bridge for over a dozen projects including GMX, FRAX, etc to allow their users to bridge their tokens to Arbitrum.\nFunding Address: GnosisSafeProxy | Address 0x1d9Bfc24d9e7EeDa4119Ceca11EaF4c24E622E62 | Arbiscan 3\nFunding Address Characteristics:\nFunds will be deposited to the Synapse Treasury wallet on Arbitrum.\nContract Address: N/A\nSECTION 3: GRANT OBJECTIVES AND EXECUTION\nClearly outline the primary objectives of the project and the Key Performance Indicators (KPIs) used to measure success. This helps reviewers understand what the project aims to achieve and how progress will be assessed.\nObjectives: [Clearly state the primary objectives of the grant and what you intend to achieve]\n\nEncourage new $$ into the Arbitrum ecosystem. With concentrated liquidity, Arbitrum will be the only L2 to have slippage-free bridging from any chain. We expect this grant to bring $3B net new dollars into the ecosystem.\nSupport & grow existing Arbitrum projects. Today, Synapse is the native bridge for GMX and dozens of other Arbitrum native projects. By subsidizing gas & fee costs associated with bridging these tokens, more users and developers will be encouraged to join the ecosystem.\nAccording to DefiLama, 45% of Synapse TVL is on Ethereum and 40% is on Arbitrum today. We anticipate Arbitrum to dominate Synapse TVL and reach 70%.\n\nBetween a large cross-chain user base and innovative cross-chain technology, the goal is to bring new users, assets, and dollars into the Arbitrum ecosystem. This is accomplished through Fast bridging for users up to $5m, Supporting existing Arbitrum Protocols, and Encouraging new users and developers.\nFast bridging through Concentrated Liquidity is a new paradigm that will expedite the bridging process and make bridging more affordable. Success in this initiative includes attracting liquidity, shorter bridge times, and volume through the new pools.\nSupport for existing Arbitrum protocols is focused around initiatives that encourage users to cross-pollinate protocols on the chain. Gas rebates & fee rebates will support projects and their users.\nThe objectives here follow the tailwinds of current Synapse efforts in the Arbitrum ecosystem Synapse has already facilitated nearly $8bn of volume, ~200k users and 700k transactions on the L2 and is uniquely positioned to bring new dollars into the Arbitrum ecosystem and direct them to key protocols.\nScreenshot 2023-09-27 at 8.15.38 PM690×371 33.1 KB\nScreenshot 2023-09-27 at 8.15.38 PM1920×1035 89.8 KB\nKey Performance Indicators (KPIs): [Specify the KPIs that will be used to measure success in achieving the grant objectives]\nSome milestones are:\n\nImprove Bridge Quotes: Slippage free, instant bridging on up to $5m through Concentrated Liquidity\nDeeper Liquidity Pools: $60m in TVL on synapse stableswap pools\nIncrease assets on Arbitrum, we anticipate this grant will drive $3B of net new volume(based on existing incentives) on Arbitrum\n\nHow will receiving a grant enable you to foster growth or innovation within the Arbitrum ecosystem?: [Provide details]\nSynapse Protocol expects to foster growth and innovation from the grant through two key mechanisms: Making it easier to get assets onto the chain, and improving the cross-chain experience through partnerships in the ecosystem.\nThe first goal is to make it easier to bridge assets into the ecosystem, this means cheaper, faster, safer, and more user friendly bridging. Concentrated Liquidity is a novel way to enable slippage-free, fast bridging for anything under $5m. Cheap and fast bridging is crucial for increasing the amount of dollars that enter the ecosystem. Beyond new bridging models and subsidizing liquidity, creative ways to encourage old and new users are from gas airdrops to subsidized fees, which will help to funnel liquidity and users into the Arbitrum Ecosystem.\nThe second goal is to build deeper integrations and tooling with existing Arbitrum projects. Synapse already has key strategic integrations within the ecosystem: the native bridge for GMX, core integrations with Uniswap, Balancer, Olympus DAO, and Frax. Further tying cross-chain support into decentralized applications, in a way that is intuitive, encourages the use of new applications in the ecosystem.\nJustification for the size of the grant: [Enter explanation]\nSynapse is eligible for the Pinnacle grant:\n\nHas been live on Arbitrum for 22 months\nHas $40M in TVL on Arbitrum\n\nDeploying shortly after mainnet launched, Synapse was one of the first protocols to arrive on the chain, and to date has facilitated $8bn of volume, ~200k users and 700k transactions.\nSynapse also has made a strong effort to create deep integrations with top tier Arbitrum projects, serving as the native bridge partner for GMX, and bespoke integrations with 4 more of the top 10 TVL projects on the chain.\nExecution Strategy: [Describe the plan for executing including resources, products, use of funds, and risk management. This includes allocations for specific pools, eligible assets, products, etc.]\nThe execution plan is to deploy liquidity emissions and gas/fee rebates as the streamed ARB comes in.\nSmart contracts to stream these funds will be developed by contributors to the Synapse DAO and the contracts will be managed by the Synapse DAO.\nGrant Timeline: [Describe the timeline for the grant]\nThe timeline for the grant is Q4 2023. Deployment of funds into initiatives would begin soon after the grant.\nSECTION 5: PROTOCOL DETAILS\nProvide details about the Arbitrum protocol requirements relevant to the grant. This information ensures that the applicant is aligned with the technical specifications and commitments of the grant.\nIs the Protocol Native to Arbitrum?:\nSynapse is deployed to 19 other chains but Arbitrum is where 40% of all Synapse TVL lives(only Ethereum mainnet is bigger).\nOn what other networks is the protocol deployed?:\nSynapse is deployed to 19 chains, the entire list can be found at docs.synapseprotocol.com\nWhat date did you deploy on Arbitrum?: 11/6/2021\nProtocol Performance:\nSynapse protocol was the first bridge deployed to Arbitrum Mainnet in the fall of 2021.\nTo date, Synapse Protocol has facilitated over $2.5bn of bridge volume, $8bn of total volume and 170,000 wallets have interacted with the protocol just on Arbitrum. Synapse has also built strong relationships and integrations with top protocols on Arbitrum like GMX, Balancer, and Sushiswap.\nSynapse protocol remains the only way to bridge native GMX, and has also made meaningful contributions to the developer ecosystem of Arbitrum by building integrations on top of existing Arb protocols and open source development.\nCheck out the data here: Synapse Arbitrum Stats - Protochain Research\nProtocol Roadmap:\nSynapse Labs just announced the Synapse Interchain Network, a new primitive in enabling a cross-chain future. Synapse sees Arbitrum as leading the way for L2’s and the home of many important decentralized applications core to the multi-chain thesis.\nAudit History: N/A\nSECTION 6: Data and Reporting\nProvide details on how your team is equipped to provide data and reporting on grant distribution.\nIs your team prepared to create Dune Spells and/or Dashboards for your incentive program?: Yes\nIf not, how does your team plan to report grant data?:\nSynapse has robust analytics and can create on demand reports.\nDoes your team agree to provide bi-weekly program updates on the Arbitrum Forum thread?: Yes, see above\nDoes your team acknowledge that failure to comply with any of the above requests can result in the halting of the programs funding stream?:\nYes\n\n [Synapse Protocol][STIP - Round 1] [ Update]\n\n Synapse STIP Addendum\n\n Concerns Regarding Possible Misconduct by Synapse with Respect to the Usage of ARB Incentives Allocated Through the STIP\n\n 7\n\n 5\n\n 2\n\n 2\n\n read \n\n 9\n min\n\n post by Konyalu42 on Sep 28, 2023\n\n post by MattOnChain on Sep 28, 2023\n\n post by Matt_StableLab on Sep 28, 2023\n\n post by meyaf320219 on Sep 28, 2023\n\n post by Socrates on Sep 29, 2023\n\n post by Socrates on Sep 29, 2023\n\n post by Matt_StableLab on Sep 29, 2023\n\n post by flindy on Sep 29, 2023\n\n post by Db_DefiEdge on Sep 29, 2023\n\n post by sahijeevan on Sep 29, 2023\n\n post by axlvaz_SEEDLATAM.eth on Oct 1, 2023\n\n post by axlvaz_SEEDLATAM.eth on Oct 1, 2023\n\n post by Bobbay on Oct 2, 2023\n\n post by moses on Oct 2, 2023\n\n post by moses on Oct 2, 2023\n\n post by moses on Oct 2, 2023\n\n post by moses on Oct 2, 2023\n\n post by Matt_StableLab on Oct 3, 2023\n\n post by Matt_StableLab on Oct 3, 2023\n\n Load more posts below","tokens":4061,"squid":"spider-07","role":"Council Spider","at":1791345324222,"hash":"4479ade2846f718c7e4b663aabdce78c808840a8"}
{"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":"spider-08","role":"Oracle Spider","at":1791345326523,"hash":"324bcbc6843f63ba91092db203365ded1238fcfc"}
{"url":"https://forum.arbitrum.foundation/t/synapse-protocol-final-stip-round-1/17550/27","domain":"forum.arbitrum.foundation","title":"[Synapse Protocol] [FINAL][STIP - Round 1] - Archive / Short Term Incentives Program (STIP) Round 1 - Arbitrum","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 7\n\n 5\n\n 2\n\n 2\n\n read \n\n 9\n min\n\n Sep 2023\n\n 27 / 27\n\n Dec 2023\n\n Dec 2023\n\n Load more posts above\n\n post by Matt_StableLab on Sep 29, 2023\n\n post by flindy on Sep 29, 2023\n\n post by Db_DefiEdge on Sep 29, 2023\n\n post by sahijeevan on Sep 29, 2023\n\n post by axlvaz_SEEDLATAM.eth on Oct 1, 2023\n\n post by axlvaz_SEEDLATAM.eth on Oct 1, 2023\n\n post by Bobbay on Oct 2, 2023\n\n post by moses on Oct 2, 2023\n\n post by moses on Oct 2, 2023\n\n post by moses on Oct 2, 2023\n\n post by moses on Oct 2, 2023\n\n post by Matt_StableLab on Oct 3, 2023\n\n post by Matt_StableLab on Oct 3, 2023\n\n post by CastleCapital on Oct 3, 2023\n\n post by Matt_StableLab on Oct 4, 2023\n\n post by moses on Oct 4, 2023\n\n post by cliffton.eth on Oct 4, 2023\n\n cliffton.eth\n\n Post has been marked FINAL and locked.\n\n post by iZUMi_Finance on Oct 9, 2023\n\n iZUMi_Finance\n\n We would like to support this proposal, which is meticulously designed to inject vibrancy and liquidity into the Arbitrum ecosystem.\nSynapse, already a key player in the ecosystem with significant volume and user base, is uniquely positioned to achieve these objectives.\nBR,\nIZUMI TEAM\n\n post by ITUblockchain on Oct 12, 2023\n\n ITUblockchain\n\n Synapse, proving to be one of the biggest contributors for the ecosystem continuing to provide mining rewards on Arbitrum and supporting the ecosystem with 4M+SYN in the past year, requests the proposal focusing on mainly 2 objectives: supporting faster and cheaper bridging, and supporting Arbitrum partners. Even though the requested budget amount is remarkably big, considering the sustainable outcomes and the possible future contribution for the ecosystem makes it reasonable.\nBased on these reasons, ITU Blockchain voted in favor of this proposal.\n\n 2 months later\n\n post by moses on Dec 19, 2023\n\n moses\n\n Quick update to the Synapse STIP Round 1 proposal, that was created in October 2023, and approved as part of the STIP Backfund.\nThe Funding Address used to receive the STIP funds is:\n0xD31d3A2C19123b8FF48560c20a08fFB16aD62dFe\nThe address above is a 2/3 multi-sig controlled by the Synapse DAO.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Synapse STIP Addendum\n\n STIP Bridge Addendum\n\n 6\n\n 1.2k\n\n May 2024\n\n [Socket] [FINAL] [STIP - Round 1]\n\n Short Term Incentives Program (STIP) Round 1\n\n 26\n\n 5.0k\n\n Nov 2023\n\n [Stargate Finance] [FINAL] [STIP - Round 1]\n\n Short Term Incentives Program (STIP) Round 1\n\n 15\n\n 3.4k\n\n Oct 2023\n\n Concerns Regarding Possible Misconduct by Synapse with Respect to the Usage of ARB Incentives Allocated Through the STIP\n\n ARDC Research Member\n\n 17\n\n 3.2k\n\n Jul 2024\n\n [Synthetix] LTIPP Application - FINAL\n\n Long Term Incentives Pilot Program (LTIPP)\n\n 17\n\n 2.8k\n\n Aug 2024","tokens":706,"squid":"spider-07","role":"Council Spider","at":1791345334465,"hash":"163729174fbb7f9afad35df23cdff163c5a8f17d"}
{"url":"https://forum.across.to/t/across-acx-community-initial-liquidity-proposal/1129/49","domain":"forum.across.to","title":"Across ($ACX) Community Initial Liquidity Proposal - Proposals / Passed Proposals - Across Protocol","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n read \n\n 6\n min\n\n Nov 2022\n\n 49 / 50\n\n Nov 2022\n\n Nov 2022\n\n Load more posts above\n\n post by Bernade on Nov 18, 2022\n\n post by DieWithHonor on Nov 18, 2022\n\n post by charis on Nov 18, 2022\n\n post by AndrewG on Nov 18, 2022\n\n post by user6 on Nov 18, 2022\n\n post by MiLLiE on Nov 18, 2022\n\n post by TheRealTuna_Across on Nov 18, 2022\n\n post by holly on Nov 18, 2022\n\n post by RoninImperial.eth on Nov 19, 2022\n\n post by eren.eth on Nov 24, 2022\n\n post by jotatotal on Nov 25, 2022\n\n post by user9 on Nov 27, 2022\n\n post by jyh66 on Nov 27, 2022\n\n post by CyA on Nov 27, 2022\n\n post by Parim_Param on Nov 27, 2022\n\n Parim_Param\n\n Great proposal But it seems to me that 60k tokens does not sufficiently account for the attention to the project in the community. And this attention is actually huge\n\n post by zfm on Nov 27, 2022\n\n zfm\n\n nice!!! This is awesome!!! This will boost up ACX to the moon! With this proposal, this will further cement ACX’s stability and provide firm hold on DEX markets. Balancer is a good platform with established market and support. Definitely worth the wait! Lezgaw ACROSS\n\n post by pnynto on Nov 27, 2022\n\n pnynto\n\n Nice Active proposal\nA very reasonable proposal , it will greatly benefits the whole ecosystem and also induced more trust to the community\n\n post by Cevik11 on Nov 27, 2022\n\n Cevik11\n\n Will those who are in dao get airdrops? I just joined, can adding lp to the pool be a criterion? What can we do to support the community\n\n post by crismin7777 on Nov 27, 2022\n\n crismin7777\n\n It’s so good I absolutely agree. I think the project is going in a good direction. Let’s keep developing like this.\n\n post by Max_Poplavskii on Nov 27, 2022\n\n Max_Poplavskii\n\n Very interesting acitivity, I think it is a Cool and Good NEWS! and i respect your choice\nThank you @EAsports for this proposal.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Across Token Launch Proposal v2\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 47\n\n Nov 2022\n\n $ACX Liquidity - Update and Feedback Wanted\n\n Ideas & Feedback\n\n Ideas & Feedback\n\n 7\n\n Jun 2023\n\n Velodrome Liquidity Program Extension\n\n Active Proposals\n\n Active Proposals\n\n 19\n\n Jan 2024\n\n Across Token Launch Proposal\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 214\n\n May 2022\n\n “Community Owned Liquidity” NFT Project Funding Request\n\n Active Proposals\n\n treasury-funding\n\n Active Proposals\n\n 36\n\n Jun 2023","tokens":616,"squid":"spider-09","role":"Bridge Spider","at":1791345340649,"hash":"545c814952496859cdefaefe540329cea7cebb5f"}
{"url":"https://akash.network/docs/api-documentation/sdk/quick-start","domain":"akash.network","title":"SDK Quick Start | Akash Network - Your Guide to Decentralized Cloud","text":"SDK Quick Start Deploy and manage Akash applications using our official SDKs in Go or JavaScript/TypeScript.\nBoth SDKs are generated from the chain-sdk repository and provide the same core functionality.\n\nPrerequisites\nBefore you begin, ensure you have:\n\nFor TypeScript: Node.js 22.14.0+ and npm/yarn/pnpm\nFor Go: Go 1.25.0+\nAn Akash wallet with AKT tokens (get sandbox tokens from the faucet)\nBasic understanding of blockchain concepts\n\nInstallation\nnpm install @akashnetwork/chain-sdk@alpha @cosmjs/proto-signing @cosmjs/amino\n\nQuick Start: Complete Deployment Workflow\nStep 1: Initialize SDK and Wallet\nimport { DirectSecp256k1HdWallet } from \"@cosmjs/proto-signing\";\nimport { createChainNodeSDK, generateManifest, yaml, type SDLInput } from \"@akashnetwork/chain-sdk\";\n\n// Initialize wallet from mnemonic\nconst mnemonic = \"your mnemonic phrase here\";\nconst wallet = await DirectSecp256k1HdWallet.fromMnemonic(mnemonic, { \nprefix: \"akash\" \n});\nconst accounts = await wallet.getAccounts();\n\nconsole.log(\"Wallet address:\", accounts[0].address);\n\n// Initialize SDK\nconst sdk = createChainNodeSDK({\nquery: {\n baseUrl: \"https://grpc.sandbox-2.aksh.pw:443\", // Sandbox gRPC\n},\ntx: {\n baseUrl: \"https://rpc.sandbox-2.aksh.pw:443\", // Sandbox RPC\n signer: wallet,\n gasPrice: \"0.025uakt\"\n}\n});\n\nconsole.log(\"SDK initialized\");\n\nStep 2: Define Your SDL\nversion: \"2.0\"\n\nservices:\nweb:\n image: nginx:1.25.3\n expose:\n - port: 80\n as: 80\n to:\n - global: true\n\nprofiles:\ncompute:\n web:\n resources:\n cpu:\n units: 0.5\n memory:\n size: 512Mi\n storage:\n size: 512Mi\nplacement:\n dcloud:\n pricing:\n web:\n denom: uakt\n amount: 1000\n\ndeployment:\nweb:\n dcloud:\n profile: web\n count: 1\n\nStep 3: Parse SDL and Create Deployment\nimport { generateManifest, yaml, type SDLInput } from \"@akashnetwork/chain-sdk\";\n\n// Define SDL using the yaml template tag\nconst sdl: SDLInput = yaml`\nversion: \"2.0\"\nservices:\nweb:\n image: nginx:1.25.3\n expose:\n - port: 80\n as: 80\n to:\n - global: true\nprofiles:\ncompute:\n web:\n resources:\n cpu:\n units: 0.5\n memory:\n size: 512Mi\n storage:\n size: 512Mi\nplacement:\n dcloud:\n pricing:\n web:\n denom: uakt\n amount: 1000\ndeployment:\nweb:\n dcloud:\n profile: web\n count: 1\n`;\n\n// Generate manifest and deployment groups\nconst result = generateManifest(sdl, \"sandbox\");\n\nif (!result.ok) {\nthrow new Error(\"SDL validation failed: \" + JSON.stringify(result.value));\n}\n\nconst { groups, groupSpecs } = result.value;\n\nconsole.log(\"SDL parsed successfully\");\n\n// Get current block height for dseq\nconst status = await sdk.cosmos.base.tendermint.v1beta1.getLatestBlock({});\nconst dseq = status.block.header.height;\n\nconsole.log(\"Creating deployment with dseq:\", dseq);\n\n// Create deployment\nconst deployment = await sdk.akash.deployment.v1beta4.createDeployment({\nid: {\n owner: accounts[0].address,\n dseq: dseq\n},\ngroups: groupSpecs,\ndeposit: {\n denom: \"uakt\",\n amount: \"5000000\" // 5 AKT deposit\n},\ndepositor: accounts[0].address\n});\n\nconsole.log(\"Deployment created with dseq:\", dseq);\n\nStep 4: Wait for Bids\nAfter creating a deployment, providers will submit bids. Wait 30-60 seconds for bids to arrive.\n// Wait for bids (in production, use events or polling)\nconsole.log(\"Waiting for bids...\");\nawait new Promise(resolve => setTimeout(resolve, 30000)); // Wait 30s\n\n// Query bids\nconst bidsResult = await sdk.akash.market.v1beta5.getBids({\nfilters: {\n owner: accounts[0].address,\n dseq: dseq,\n state: \"open\"\n}\n});\n\nconsole.log(`Received ${bidsResult.bids.length} bids`);\n\n// Display bid details\nbidsResult.bids.forEach((bidInfo, index) => {\nconst bid = bidInfo.bid;\nconsole.log(`Bid ${index + 1}:`);\nconsole.log(` Provider: ${bid.bidId.provider}`);\nconsole.log(` Price: ${bid.price.amount} ${bid.price.denom}`);\n});\n\nStep 5: Accept a Bid (Create Lease)\nif (bidsResult.bids.length === 0) {\nconsole.error(\"No bids received. Check your SDL and try again.\");\nprocess.exit(1);\n}\n\n// Select the first bid (or implement your own selection logic)\nconst selectedBid = bidsResult.bids[0].bid;\n\nconsole.log(`Accepting bid from provider: ${selectedBid.bidId.provider}`);\n\n// Create lease (accept the bid)\nconst lease = await sdk.akash.market.v1beta5.createLease({\nbidId: selectedBid.bidId\n});\n\nconsole.log(\"Lease created!\");\nconsole.log(`Provider: ${selectedBid.bidId.provider}`);\n\nStep 6: Send Manifest to Provider\nAfter creating a lease, you need to send the manifest to the provider using the Provider API.\nimport { JwtTokenManager } from \"@akashnetwork/chain-sdk\";\nimport { Secp256k1HdWallet } from \"@cosmjs/amino\";\n\n// Initialize JWT token manager for provider authentication\nconst aminoWallet = await Secp256k1HdWallet.fromMnemonic(mnemonic, { \nprefix: \"akash\" \n});\nconst tokenManager = new JwtTokenManager(aminoWallet);\n\n// Generate JWT token\nconst token = await tokenManager.generateToken({\niss: accounts[0].address,\nexp: Math.floor(Date.now() / 1000) + 3600, // 1 hour\niat: Math.floor(Date.now() / 1000),\nversion: \"v1\",\nleases: { access: \"full\" }\n});\n\n// Use manifest from earlier generateManifest result (groups = manifest)\nconst manifest = groups;\n\n// Send manifest to provider\nconst providerUrl = selectedBid.bidId.provider; // Get provider URL from chain\nconst response = await fetch(\n`https://provider.example.com:8443/deployment/${dseq}/manifest`,\n{\n method: \"PUT\",\n headers: {\n \"Content-Type\": \"application/json\",\n \"Authorization\": `Bearer ${token}`\n },\n body: JSON.stringify(manifest)\n}\n);\n\nif (response.ok) {\nconsole.log(\"Manifest sent successfully!\");\nconsole.log(\"Your deployment is now starting...\");\n} else {\nconsole.error(\"Failed to send manifest:\", await response.text());\n}\n\nVerify Deployment Status\n// Query lease status from provider\nconst statusResponse = await fetch(\n`https://provider.example.com:8443/lease/${dseq}/1/1/status`,\n{\n headers: {\n \"Authorization\": `Bearer ${token}`\n }\n}\n);\n\nconst status = await statusResponse.json();\n\nconsole.log(\"Deployment Status:\");\nconsole.log(\" Services:\", status.services);\nconsole.log(\" URIs:\", status.forwarded_ports);\n\nComplete Example Script\nFor a complete, runnable example that ties all these steps together, see the Examples page.\n\nCore Features\nAll SDKs support:\n\nDeployment Management - Create, update, close deployments\nMarket Operations - View bids, create leases\nProvider Queries - Find and evaluate providers\nQuery Operations - Query deployments, leases, balances\nWallet Management - Sign transactions securely\nSDL Parsing - Parse and validate SDL files\nCertificate Management - Generate and manage certificates\nJWT Authentication - Authenticate with providers\n\nNext Steps\n\nExamples - Real-world code examples for common tasks\nAPI Reference - Complete API documentation\nSDL Reference - Stack Definition Language documentation\n\nTroubleshooting\nCommon Issues\n“Insufficient funds” error:\n\nEnsure your wallet has enough AKT tokens\nSandbox tokens: Get from faucet\n\nNo bids received:\n\nCheck your SDL syntax is valid\nEnsure resource requirements are reasonable\nWait longer (up to 2 minutes)\n\nProvider connection failed:\n\nVerify provider URL is correct\nCheck JWT token is valid and not expired\nEnsure provider is online and accepting deployments\n\nSupport\n\nDiscord: Akash Network Discord\nGitHub: chain-sdk repository\nDocumentation: Akash Docs\n\nEdit page on github\n Installation AuthZ & Fee Grants","tokens":1812,"squid":"spider-03","role":"Compute Spider","at":1791345341621,"hash":"d6891e8dd6b9730d109fa8ea260953f3426bfd81"}
{"url":"https://forum.arbitrum.foundation/c/archive/stip-bridge-addendum/29","domain":"forum.arbitrum.foundation","title":"Latest Archive/STIP Bridge Addendum topics - Arbitrum","text":"The Arbitrum Foundation notified the Security Council on the need to perform a potential Emergency action. Following a review of the details and known risks, the Security Council decided to execute the upgrade and it was completed at 11:30 EST on 2nd October 2026.\nThis report provides an overview of the risks that required the Security Council Action:\n\nAdd a permissionless guard for the One-Step Proof of BoLD on Arbitrum One\n\nTemporarily pause activation of new Stylus contracts on Arbitrum One & Nova\n\nKey point: To date, known bugs for Stylus primarily impact chain liveness (e.g., denial of service attacks) and do not put any user funds at risk.\nWhy was this action taken\nLet’s take this opportunity to explain why action was taken on two separate issues concerning BoLD and Stylus.\nInstalling the guard for One-Step Proof of BoLD. Given the rise of AI-assisted attacks, we have implemented a precautionary approach that allows anyone to pause settlement of Arbitrum One on Ethereum if there are at least two conflicting answers that pass at the same level in which only one should be valid and pass. This is to halt a class of publicly verifiable and detectable attacks that exploit a bug in the one-step proof. If halted, Arbitrum One will continue to process as normal except that messages from Arbitrum One to Ethereum, such as withdrawals, that are not yet confirmed will have to wait. This provides time for the Security Council to deploy a fix for the bug and resume the rollup.\nPreventing activation of new Stylus contracts. AI-assisted tooling has led to an increasing number of sophisticated attacks on hand-crafted WASM programs that do not use the standard Stylus compiler toolchain. These programs are specifically designed to cause unexpected behaviors such as degrading the chain’s performance for all other users. To date, no attacks have been discovered that permits theft of user funds.\nNew ArbOS releases have patched several reported bugs and known attacks over the past few months, but out of an abundance of caution, we have decided to temporarily pause new activations of Stylus contracts. This was executed as an emergency action to prevent the deployment of new hand-crafted WASM programs that are not yet patched by the current version of ArbOS on the Arbitrum network.\nThe Arbitrum Foundation has informed the Security Council that they will work with the ArbitrumDAO to discuss next steps on the timeline and manner for enabling activation of new Stylus contracts. The Arbitrum community remains confident in the value of Stylus and want to preserve these use cases while taking preventative measures against Stylus-based attack vectors as AI-assisted attack tooling continues to evolve.\nImpact on builders and users\n\nNo new activations. New Stylus contracts cannot be activated during the pause including new versions of existing applications that require activation.\n\nExisting contracts are not paused. Already-active Stylus contracts continue to execute until expiration. This pause does not deactivate them.\n\nThe ArbOS 61 upgrade renewed all active contracts on Arbitrum One, so no currently active contract expires before August 20, 2027.\n\nRenewal via keepalive stays permissionless and is unaffected by the pause.\n\nReactivating an expired contract, or one that needs to be updated after a Stylus version change, is paused.\n\nUsing/calling any activated Stylus contract stays permissionless for all users and developers.\n\nNo impact on EVM. Solidity (EVM) contract deployment and execution are unaffected by this Security Council action.\n\nSecurity Council Actions\nThere are two actions bundled into a single payload:\n\nOne-Step Proof Guard. The L1UpgradeExecutor gives a new pause contract (PauseExecutor) the ability to pause and nothing else. The new pause contract grants the guard (OspSoundnessGuard) PAUSER_ROLE to use it. Anyone can show the guard two conflicting answers to the same step of an open challenge. If the one-step proof accepts both, the guard has the pause contract put Arbitrum One’s settlement to Ethereum on hold.\n\nStylus deactivation. The Security Council called ArbOwner.setWasmActivationGas(2^64 - 1) to raise the Stylus activation gas requirement on Arbitrum One and Nova. This makes activation prohibitively expensive and effectively disables new activations. This is a configuration change and does not require an ArbOS upgrade.\n\nThe Security Council signed the following transactions to update the configuration:\n\nEthereum: Ethereum Transaction Hash: 0x30732bb7d2... | Etherscan\nArbitrum One:\nArbitrum One Transaction Hash: 0x9eb3a4be3b... | Arbitrum One\nArbitrum Nova:\nArbitrum Nova transaction 0x79e0fed470dff7a22059b108e3f8f42eddd2b580a6771594060c4e7326c5f984 | Blockscout\n\nAn external audit was conducted for the OSP Guard contracts. No audit is required for the Stylus deactivation as it is only updating a single parameter in the ArbOS configuration.\n\n Latest topics in STIP Bridge Addendum\n\n Archive\n\n STIP Bridge Addendum\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 [FINAL] Jones STIP Addendum\n\n 8\n\n 1.1k\n\n Aug 2024\n\n [FINAL] WINR Protocol STIP Addendum\n\n 4\n\n 752\n\n Aug 2024\n\n [Premia] STIP Addendum\n\n 2\n\n 715\n\n Jul 2024\n\n Tide Protocol STIP Addendum\n\n 15\n\n 687\n\n Jul 2024\n\n [FINAL] WOOFi STIP Addendum\n\n 2\n\n 576\n\n Jul 2024\n\n [ FINAL] ANGLE STIP Bridge Addendum\n\n 16\n\n 1.0k\n\n Jun 2024\n\n Start of STIP.B Streams and Timeline of Incentives\n\n 1\n\n 758\n\n Jun 2024\n\n [FINAL] Abracadabra DAO STIP Addendum\n\n 3\n\n 712\n\n Jun 2024\n\n [FINAL] Trader Joe STIP Addendum\n\n 7\n\n 1.0k\n\n Jun 2024\n\n STIP Bridge Funded Protocols Results\n\n 5\n\n 10.9k\n\n Jun 2024\n\n [FINAL] Gains Network STIP Addendum\n\n 19\n\n 2.1k\n\n Jun 2024\n\n [FINAL] MUX Protocol STIP Addendum\n\n 15\n\n 1.1k\n\n Jun 2024\n\n [FINAL] Stargate Finance STIP Addendum\n\n 15\n\n 1.1k\n\n May 2024\n\n [FINAL] Solv Protocol STIP Addendum\n\n 15\n\n 949\n\n May 2024\n\n Sanko GameCorp STIP Addendum\n\n 13\n\n 925\n\n May 2024\n\n [FINAL] KyberSwap STIP Addendum\n\n 15\n\n 1.0k\n\n May 2024\n\n Boost (Prev. RabbitHole) STIP Addendum\n\n 17\n\n 1.1k\n\n May 2024\n\n THALES PROTOCOL STIP Addendum\n\n 14\n\n 972\n\n May 2024\n\n Savvy DAO STIP Addendum\n\n 18\n\n 1.2k\n\n May 2024\n\n Stake DAO STIP Addendum\n\n 20\n\n 1.2k\n\n May 2024\n\n [FINAL] Furucombo STIP Addendum\n\n 16\n\n 1.1k\n\n May 2024\n\n [FINAL] Socket Bridge Addendum\n\n 15\n\n 1.0k\n\n May 2024\n\n OpenOcean STIP Addendum\n\n 16\n\n 1.0k\n\n May 2024\n\n Thetanuts Finance STIP Addendum\n\n 18\n\n 1.2k\n\n May 2024\n\n Dolomite STIP Addendum\n\n 15\n\n 1.1k\n\n May 2024\n\n [FINAL] Umami Finance STIP Addendum\n\n 14\n\n 1.1k\n\n May 2024\n\n STIP-Bridge Live Voting Dashboard created by Lampros Labs DAO\n\n 0\n\n 262\n\n May 2024\n\n Updates to the STIP Bridge Timeline\n\n 1\n\n 797\n\n May 2024\n\n STIP Bridge FAQ\n\n 1\n\n 1.1k\n\n May 2024\n\n Synapse STIP Addendum\n\n 6\n\n 1.2k\n\n May 2024","tokens":1699,"squid":"spider-07","role":"Council Spider","at":1791345344817,"hash":"11b35a7ae213ec783c9a818b79198388efdc6f70"}
{"url":"https://forum.across.to/t/velodrome-liquidity-program-extension/1752","domain":"forum.across.to","title":"Velodrome Liquidity Program Extension - Proposals / Active Proposals - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n Velodrome Liquidity Program Extension \n\n ProposalsActive Proposals\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 6\n\n 4\n\n 3\n\n 2\n\n read \n\n 6\n min\n\n Oct 2023\n\n 1 / 20\n\n Oct 2023\n\n Jan 2024\n\n post by Methodic on Oct 31, 2023\n\n Methodic\n\n Summary:\nAcross Protocol’s pilot program on Velodrome ended in October. This proposal aims to extend its initial program for 16 weeks in order to ensure sufficient liquidity for ACX on L2s.\nThe Velodrome team presented this strategy to the Across community on the 29th of November. A summary of the pilot program as well as this proposed extension can be viewed here.\nAfter discussing with the community, this proposal will reduce the amount of ACX incentives required by 70% (from $5K to $1.5K per week) and have Across deploy $200K worth of POL in order to sustain about $400K+ worth of TVL for effectively zero net cost.\nMotivation:\nL2 adoption continues to gain significant momentum with Across Protocol taking a leadership position in supporting cross-chain activity. Building ACX liquidity on Optimism will further strengthen Across’s presence in the growing ecosystem and allow L2 users to trade and hold ACX at a low cost.\nOn Velodrome’s pilot program, Across protocol attracted nearly $600K in liquidity by directing ~2X in VELO emissions per ACX incentive to ACX/WETH, following an uptick in incentive efficiency.\nBy extending the program, Across can leverage the increase in incentive efficiency which, complemented by Velodrome’s renewed OP grant program, will provide significant support for ACX/WETH.\n1600×884 115 KB\nSpecification:\nOn Velodrome, $VELO emissions are directed to liquidity pools based on votes by veVELO (vote-escrow VELO) holders. Protocols such as Across can use veVELO or voter incentives (bribes) to attract votes and emissions for their liquidity pairs.\nProtocols bribing on Velodrome tend to receive $2-$3 in $VELO for every $1 they deposit. Major DeFi protocols such as Yearn, Lido, Synthetix and Stargate leverage Velodrome’s mechanics to maintain deep liquidity on Optimism in a capital-efficient way.\nAcross will extend its initial program for another 16 weeks while strategically reducing incentives from $5K worth of ACX tokens to $1.5K. These will be deposited weekly to attract votes for ACX/WETH. After each epoch is completed on Wednesday at 23:59 UTC, the resulting $VELO emissions from votes will flow to ACX/WETH LPs.\nAcross may also be eligible for a share of 4000 OP every week whilst it remains in the Top 15 ecosystem pools by voter incentives as part of the current “Tour de OP” incentive program. This amount will be proportional to all other pools in this category and will be deposited as an extra bribe to boost votes further. Details about the current Tour de OP program below.\n1600×1000 205 KB\nProtocol Owned Liquidity (POL)\nAcross Protocol will also create a $200K ACX/WETH POL position and deploy it on Velodrome. This POL will allow Across able to capture a significant portion of the $VELO rewards that will be streamed to the ACX/WETH pool. To build the POL position, Across will convert up to $100K ACX into WETH as needed.\nAcross will lock farmed $VELO as veVELO in order to build a voting position - Protocol Owned Votepower (POV) - that will direct additional emissions in perpetuity, while earning rewards in fees and incentives. Protocols pursuing a similar strategy are able to reduce reliance on voter incentives over time. They include Stargate, Yearn, Inverse, QiDAO, Thales among others.\nRationale:\nVelodrome is the single largest protocol on Optimism and the largest DEX on Layer 2 Ethereum with ~150M TVL. Velodrome’s governance community is one of the most active and diverse in crypto, with ~15K veVELO holders participating in Velodrome’s weekly voting epochs.\nIncentivizing liquidity on Velodrome will naturally boost exposure for Across Protocol, as veVELO voters and Liquidity Providers will find ACX near the top of the voting and LP pages respectively.\nCosts:\nAcross Protocol will deploy $1.5K weekly incentives for 16 weeks which totals USD $24K. This is is $11K less than its pilot program which cost $35K. Assuming incentive efficiency remains constant at 2X, Across would capture $1.5K in VELO emissions per week at a 40% APR. In other words, Across can receive 100% of the value of its weekly incentives in VELO, allowing the protocol to sustain $390K worth of TVL for effectively zero net cost.\nAs Across locks its farmed VELO into veVELO throughout the 16 weeks, it will also end up with a veVELO position which will enable the DAO to claim weekly rewards made up of fees generated by the pool as well as claim back a portion of the weekly incentives deposited.\nAt the end of the 16 week period, the DAO can assess results and decide on whether to continue or suspend its program. The Velodrome team will also conduct a review at the end of the program and provide recommended optimizations to its strategy\nImplementation:\n\nRisk Labs to swap $100K worth of ACX to WETH\nDeposit $200K ACX/WETH LP position and stake this on Velodrome\n$24K worth of ACX tokens to be sent to Risk Labs multisig (0x8180D59b7175d4064bDFA8138A58e9baBFFdA44a)\nRisk Labs to deposit $1.5K worth of ACX incentives every week for a period of 16 weeks\nLock farmed VELO emissions into veVELO to build Protocol Owned Votepower and vote for the ACX/WETH pair\n\nVoting:\nYes - move forward with program extension\nNo - do not move forward with program extension\nAbstain - no vote\nDo you support this proposal?\n\n 67%\n Yes\n\n 33%\n No\n\n 0%\n Abstain\n\n 9\n voters\n\n Closed Jan 2024\n\n 6\n\n 4\n\n 3\n\n 2\n\n read \n\n 6\n min\n\n post by Methodic on Oct 31, 2023\n\n post by TheRealTuna_Across on Nov 2, 2023\n\n post by neondaemon on Nov 3, 2023\n\n post by btctdm on Nov 7, 2023\n\n post by PVMihalache on Nov 7, 2023\n\n post by Kevin_UMA on Nov 7, 2023\n\n post by DerivativeKid on Nov 8, 2023\n\n post by Methodic on Nov 9, 2023\n\n post by Methodic on Nov 9, 2023\n\n post by Methodic on Nov 9, 2023\n\n post by Kevin_UMA on Nov 9, 2023\n\n post by Kevin_UMA on Nov 9, 2023\n\n 20 days later\n\n post by caesarsherrod.eth on Nov 30, 2023\n\n post by Methodic on Dec 5, 2023\n\n 1 month later\n\n post by PVMihalache on Jan 6, 2024\n\n post by PVMihalache on Jan 6, 2024\n\n post by alexander on Jan 8, 2024\n\n post by PVMihalache on Jan 8, 2024\n\n post by alexander on Jan 8, 2024\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Build liquidity for $ACX on Velodrome\n\n Active Proposals\n\n treasury-funding\n\n Active Proposals\n\n 8\n\n Jul 2023\n\n Across ($ACX) Community Initial Liquidity Proposal\n\n Passed Proposals\n\n Passed Proposals\n\n 49\n\n Nov 2022\n\n Across Token Launch Proposal v2\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 47\n\n Nov 2022\n\n $ACX Liquidity - Update and Feedback Wanted\n\n Ideas & Feedback\n\n Ideas & Feedback\n\n 7\n\n Jun 2023\n\n Reduce ACX emissions for ACX LPs, WBTC LPs and wstETH/ACX LPs\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 11\n\n Aug 2024","tokens":3228,"squid":"spider-09","role":"Bridge Spider","at":1791345350852,"hash":"f697ebd2ee9e02ae98975d4410b7647d45a74f2c"}
{"url":"https://forum.arbitrum.foundation/t/final-angle-stip-bridge-addendum/23627","domain":"forum.arbitrum.foundation","title":"[ FINAL] ANGLE STIP Bridge Addendum - Archive / STIP Bridge Addendum - Arbitrum","text":"The Arbitrum Foundation notified the Security Council on the need to perform a potential Emergency action. Following a review of the details and known risks, the Security Council decided to execute the upgrade and it was completed at 11:30 EST on 2nd October 2026.\nThis report provides an overview of the risks that required the Security Council Action:\n\nAdd a permissionless guard for the One-Step Proof of BoLD on Arbitrum One\n\nTemporarily pause activation of new Stylus contracts on Arbitrum One & Nova\n\nKey point: To date, known bugs for Stylus primarily impact chain liveness (e.g., denial of service attacks) and do not put any user funds at risk.\nWhy was this action taken\nLet’s take this opportunity to explain why action was taken on two separate issues concerning BoLD and Stylus.\nInstalling the guard for One-Step Proof of BoLD. Given the rise of AI-assisted attacks, we have implemented a precautionary approach that allows anyone to pause settlement of Arbitrum One on Ethereum if there are at least two conflicting answers that pass at the same level in which only one should be valid and pass. This is to halt a class of publicly verifiable and detectable attacks that exploit a bug in the one-step proof. If halted, Arbitrum One will continue to process as normal except that messages from Arbitrum One to Ethereum, such as withdrawals, that are not yet confirmed will have to wait. This provides time for the Security Council to deploy a fix for the bug and resume the rollup.\nPreventing activation of new Stylus contracts. AI-assisted tooling has led to an increasing number of sophisticated attacks on hand-crafted WASM programs that do not use the standard Stylus compiler toolchain. These programs are specifically designed to cause unexpected behaviors such as degrading the chain’s performance for all other users. To date, no attacks have been discovered that permits theft of user funds.\nNew ArbOS releases have patched several reported bugs and known attacks over the past few months, but out of an abundance of caution, we have decided to temporarily pause new activations of Stylus contracts. This was executed as an emergency action to prevent the deployment of new hand-crafted WASM programs that are not yet patched by the current version of ArbOS on the Arbitrum network.\nThe Arbitrum Foundation has informed the Security Council that they will work with the ArbitrumDAO to discuss next steps on the timeline and manner for enabling activation of new Stylus contracts. The Arbitrum community remains confident in the value of Stylus and want to preserve these use cases while taking preventative measures against Stylus-based attack vectors as AI-assisted attack tooling continues to evolve.\nImpact on builders and users\n\nNo new activations. New Stylus contracts cannot be activated during the pause including new versions of existing applications that require activation.\n\nExisting contracts are not paused. Already-active Stylus contracts continue to execute until expiration. This pause does not deactivate them.\n\nThe ArbOS 61 upgrade renewed all active contracts on Arbitrum One, so no currently active contract expires before August 20, 2027.\n\nRenewal via keepalive stays permissionless and is unaffected by the pause.\n\nReactivating an expired contract, or one that needs to be updated after a Stylus version change, is paused.\n\nUsing/calling any activated Stylus contract stays permissionless for all users and developers.\n\nNo impact on EVM. Solidity (EVM) contract deployment and execution are unaffected by this Security Council action.\n\nSecurity Council Actions\nThere are two actions bundled into a single payload:\n\nOne-Step Proof Guard. The L1UpgradeExecutor gives a new pause contract (PauseExecutor) the ability to pause and nothing else. The new pause contract grants the guard (OspSoundnessGuard) PAUSER_ROLE to use it. Anyone can show the guard two conflicting answers to the same step of an open challenge. If the one-step proof accepts both, the guard has the pause contract put Arbitrum One’s settlement to Ethereum on hold.\n\nStylus deactivation. The Security Council called ArbOwner.setWasmActivationGas(2^64 - 1) to raise the Stylus activation gas requirement on Arbitrum One and Nova. This makes activation prohibitively expensive and effectively disables new activations. This is a configuration change and does not require an ArbOS upgrade.\n\nThe Security Council signed the following transactions to update the configuration:\n\nEthereum: Ethereum Transaction Hash: 0x30732bb7d2... | Etherscan\nArbitrum One:\nArbitrum One Transaction Hash: 0x9eb3a4be3b... | Arbitrum One\nArbitrum Nova:\nArbitrum Nova transaction 0x79e0fed470dff7a22059b108e3f8f42eddd2b580a6771594060c4e7326c5f984 | Blockscout\n\nAn external audit was conducted for the OSP Guard contracts. No audit is required for the Stylus deactivation as it is only updating a single parameter in the ArbOS configuration.\n\n [ FINAL] ANGLE STIP Bridge Addendum \n\n ArchiveSTIP Bridge Addendum\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n read \n\n 8\n min\n\n May 2024\n\n 1 / 17\n\n May 2024\n\n Jun 2024\n\n post by Mariam on May 2, 2024\n\n Mariam\n\n Information about STIP/STIP Backfund\n1. Can you provide a link to your previous STIP proposal (round 1 or backfund)?\n\n2. How much, in the previous STIP proposal, did you request in ARB?\n700,000 ARB\n3. What date did you start the incentive program and what date did it end?\n7 November 2023 - 31 March 2024\n4. Could you provide the links to the bi-weekly STIP performance reports and Openblocks Dashboard?\n\nBi-weekly updates\nMerkl incentives report on the Camelot stEUR-ARB pool\nMerkl incentives report on the Camelot stEUR-USDC pool\nMerkl incentives report on the Camelot stEUR-wstETH pool\nOpenBlock Dashboard (Please note that the OpenBlock Dashboard shows a TVL of $683k which does not match the size of EURA supply that can be check on Arbiscan and the TVL available in the Angle Analytics. The Angle team s in touch with the OpenBlock team to help update the data)\n\nPlease note that the number of adresses effectively rewarded as shown in the bi-weekly reports and in the Merkl reports pages include Asset Liquidity Managers addresses such as Gamma that manage position on behalf on multiple individual LPs.\n5. Could you provide the KPI(s) that you deem relevant for your protocol, both in absolute terms and percentage change, month over month, for the first of each month starting from October 2023 until April 2024, including the extremes? If you don’t know what KPI might be relevant for you or how to properly define them, please refer to the following document:[Arbitrum DAO] OpenBlock Labs Incentive Onboarding Spec\n\nKPI 1 - User Count on Arbitrum: The program has helped onboard 5016 new EURA holders. At the beginning of the Angle STIP program early November, EURA (ex agEUR) has 63,063 holders on Arbitrum. This number has steadily increased during the program and continued to increase after. The count of EURA holders on Arbitrum is now 68,142.\n\nThe Angle analytics, when filters on the holders count on the Arbitrum chain, allows to se the progression (see screenshot below).\n\nDATE\n01/10/23\n01/11/23\n01/12/23\n01/01/24\n01/02/24\n01/03/24\n01/04/24\n\nDAU (K)\n62087\n63063\n63488\n64754\n65311\n65997\n67068\n\nDAU %\n0%\n+1.57%\n0.68%\n1.99%\n0.86%\n1.05%\n1.63%\n\nimage1387×530 45.8 KB\n\nKPI 2 - Volume: From the start of the STIP campaign, EURA’s trading volume on Arbitrum increased from **281M in early November to 601M of volume as at today **, resulting in an increase of 115% in volume over time from early November to now.\n\nThe Angle analytics, when filters on the holders count on the Arbitrum chain, allows to se the progression (see screenshot below).\n\nDATE\n01/10/23\n01/11/23\n01/12/23\n01/01/24\n01/02/24\n01/03/24\n01/04/24\n\nVolume (M)\n266.6\n281.1\n366.3\n423.9\n462.2\n509.7\n562.7\n\nVolume %\n0%\n+5.45%\n+30.24%\n+15.71%\n+9.05%\n+10.30%\n+10.41%\n\nimage1393×519 44.9 KB\n\nKPI 3 - TVL: The TVL relating to the EURA stablecoin amounted $361k on Arbitrum at the start of the STIP in early November. It peaked at $6.7M and is now stabilized around $2.3M. The maximum growth of TVL during the program represented a 1753% increase. At the current stabilized TVL of $2.3M, the program allowed to create and retain a TVL increase of 538% between the beginning and te end of the program.\n\nDATE\n01/10/23\n01/11/23\n01/12/23\n01/01/24\n01/02/24\n01/03/24\n01/04/24\n\nTVL ($M)\n0.664\n0.361\n4.43\n3.73\n3.66\n5.2\n6.7\n\nTVL %\n0%\n-45.75%\n1130.47%\n-15.8%\n-1.87%\n42.62%\n28.85%\n\nimage1411×530 50.1 KB\n6. [Optional] Any lessons learned from the previous STIP round?\nEven if the program allowed us to grow (1) the Angle TVL on Arbitrum with peak 1753% increase now stabilizing at a 538% increased compared to the begining of the program, and (2) DEX liquidity, the remaining stEUR holders after the program did not necessarily leave their liquidity in the pools created, they keep holding the EURA and stEUR stablecoins but out the pools. In summary, new holders of the EURA stablecoin remained after the end of the program and a considerable part of them (approx. 50%) kept staking their EURA stablecoin into stEUR to gain the RWA yield associated with it. Indeed Around 1m of EURA are currently staked in the stEUR savings product. However, most of these people pulled their liquidity out the Camelot pools that were set up.\nThe integration of stEUR with Silo allowed the onboarding of new EURA and stEUR holders. Integrations and sigle-sided liquidity incentivization on Silo appears to be a good continuation path for this STIP Bridge.\nNew Plans for STIP Bridge\n7. How much are you requesting for this STIP Bridge proposal? 350,000\n8. Do you plan to use the incentives in the same ways as highlighted in Section 3 of the STIP proposal? [Y/N]*\nNo\n9. [Only if answered “no” to the previous question] How will the incentive distribution change in terms of mechanisms and products?\nAngle has launched a new USD stablecoin, USDA. USDA has a yield-bearing product associated called stUSD.\nThe reserves backing USDA and stUSD are as follows:\n\nPrice Stability Module:\n\nSteakUSDC: the USDC deposits in the Steakhouse Financial curated Morpho vault, yielding the current DeFi money markets yield (64.70%)\nIB01: Blackrock ETF of short term US treasury bonds tokenized by Backed Finance (18%)\nUSDC: the Circle USD stablecoin (17.30%)\nUSDA also has a safety surplus of $3M+ to further buffer overcollateralization, and this surplus is called to grow as the protocol grows. This surplus buffer is made up of the profits the protocol has built since its launch in November 2021.\n\nBorrowing Facility on Morpho: For USDA, Angle delegated its borrowing facility to a Metamorpho vault curated by Gauntlet by pre-minting USDA in it. This is functionally equivalent to having a borrowing system on its own. The choice to delegate the borrowing infrastructure of USDA to the Morpho system holds benefits in terms of distribution, helps to benefit from the expertise of a reputed third party as Gauntlet and still allows the protocol to manage its risk on Morpho by proposing to adjust debt ceilings. To this date, the protocol has minted $3M USDA in the form of Automatic Market Operations (AMO) for seeding purposes in the Morpho vault curated by Gauntlet. This is always trackable in the real-time analytics and balance sheet provided by Angle. Please also see the Angle governance proposal detailing the borrowing facility set-up and the Angle documentation explaining protocol AMOs.\n\nAMO (Automatic Market Operations): To this date, the protocol has also minted USDA for seeding purposes on Uniswap ($5M USDA) in a EURA/USDA Uniswap v3 pool. This is also always trackable in the real-time analytics and balance sheet provided by Angle. Please also see the governance proposal relating to the seeding of that pool and and how this reflects within the balance sheet and the Angle documentation explaining protocol AMOs.\n\nFor stUSD, the yield comes from:\n\nAssets held in the backing (price stability module)\n\nsteakUSDC currently yielding 7% depending on DeFi rates\nbIB01: Blackrock ETF of short term US treasury bonds tokenized by Backed Finance yielding approximately 5% over the past year\n\nBorrowing interest earned by the protocol from people borrowing USDA on Angle Morpho Blue markets\n\nCurrently stUSD yields 20%. Why is it the the yield so high? The current yield is at 20% for stUSD thanks to the multiplier effect that Angle’s savings solution benefits from. The yield that the protocol distributes to stUSD holders comes from the backing of USDA. Currently, only 27% of the USDA is staked into stUSD, this means that the savings contract utilization rate is low and it allows stUSD holders to earn more. Why is the utilization rate low? The current utilization rates on the stUSD and stEUR are low due to competing DeFi integrations that incentivize USDA and EURA holders to deposit their stablecoins in pools rather than staking them with Angle. For example, USDA supply is largely used on Aerodrome (Base Chain DEX) and Morpho rather than being staked.\nA larger target and user base that the Euro stablecoin: USDA has been launched two weeks ago and currently has a 10m TVL. More generally, USD stablecoins have larger use cases and adoption in Defi, hence the plan to direct the potential STIP bridge funds to the development of use cases around USDA and stUSD.\nAfter the initial STIP program, an event if Angle registered solid growth numbers in user count, volume, and TVL, it appears that favoring lending and/or perpetual DEX inregrations may be better long term spending for networks effects within the Arbitrum ecosystem.\nThe new plan would be to allocate the funds as follow:\n\nStep 1 - 250,000 ARB dedicated to single sided USDA liquidity providers on lending markets including at least Silo,\nStep 2 - 100,000 ARB dedicated to (1) bringing stUSD liquidity on a native perpetual DEX on Arbitrum (Vela Exchange or else) to facilitate more trades, or (2) bringing furthermore USDA liquidity a money market on results observed in Step 1\n\nIncentives distributions on Silo\nAngle will gradually distribute incentives on Silo starting with a lower amount of incentives during the first weeks to avoid incentives collection by a minority of lenders. Incentives will be streamed on a weekly basis in order to monitor and maintain a constant APR.\nIncentives distributions on a perpetual DEX\nThe goal would be to facilitate more trades by bringing further liquidity on a native decentralized Arbitrum perpetual DEX. The incentives would be distributed to reward the liquidity deposited. If implemented, this distribution of ARB will be rolled out progressively to ensure a constant and controlled APR benefiting to a maximum of LPs.\n10. Could you provide the addresses involved in the STIP Bridge initiative (multisig to receive funds, contracts for distribution, and any other relevant contract involved), and highlight if they changed compared to the previous STIP proposal?\n\nMultisig receiving payment: 0x55F01DDaE74b60e3c255BD2f619FEbdFce560a9C\n\nCould you share any feedback or suggestions on what could be improved in future incentive programs, what were the pain points and what was your general evaluation of the experience?\n\nN/A. The STIP experience has been very productive (cf. numbers provided above) overall and well managed by the team in charge.\n\n Curia Delegate Communication Thread\n\n Savvy DAO - Delegate Communication Thread\n\n 3\n\n read \n\n 8\n min\n\n post by Matt_StableLab on May 3, 2024\n\n Matt_StableLab\n\n Hello @Mariam ,\nThank you for your application! Your advisor will be @JoJo.\nPlease join the LTIPP discord and ping your advisor in the general chat so they can create a new channel and start communicating with you.\n\n 17 days later\n\n post by cattin on May 20, 2024\n\n cattin\n\n Following the ARDC recommendation, we believe that this proposed addendum requires further review by the DAO. Therefore, we challenge its optimistic approval so that the delegates can form an opinion on the merit of renewing the incentives received during the STIP.\nWe are publishing the review conducted by Blockworks for greater visibility and advice to the applicant to provide an explanation for the concerns raised.\n“Is applying to the STEP as well (although doesn’t seem to be prohibited in STIP/STEP rules). Currently, TVL of Camelot pools incentivised during the program at ~$650K (~600K ARB spent in incentives). Deposited stEUR on Silo at ~$45K, with utilization at 1% (~100K ARB spent in incentives). However, circulating supply of EURA on Arbitrum increased from ~500K to ~1.6M (beginning of May). Extremely poor reporting during original STIP. New program would focus on USDA instead of EURA, but usage of incentives is quite similar to the original STIP, where results were lackluster (although, Bridge structure quite loosely defined). Hard market to penetrate, especially on the liquidity side. If accepted to STEP, would likely have a notably larger positive impact on the project relative to STIP allocation.”\n\n post by Mariam on May 21, 2024\n\n Mariam\n\n Thank you @cattin and all involved delegates for your review and feedback.\nPlease see below additional information to address the concern raised re: the Angle STIP Bridge application. Please let us know if there are any concerns or questions you have regarding the below or our application in general in order to help us bring a better value to the ecosystem.\n\nKPIs - Initial STIP results re: TVL, volume and holders on Arbitrum: Angle’s EURA’s key KPIs on Arbitrum all grew and did not go back to level lower than before the STIP as it has ben observed in other cases upon reading the ARDC report. Please see the addendum above for main KPI and results.\n\nLiquidity on Camelot - Solution for the STIP Bridge to deploy the Angle Price Stability module on Arbitrum, deepen liquidity and create native USDA and stUSD on Arbitrum: Part of Angle STIP incentives were distributed on Camelot. As noted on the ARDC report, liquidity decreased after the end of the program. Please note that Angle however retained new EURA and stEUR holders that pulled their liquidity from camlot but kept their EURA and staked EURA (stEUR). In summary, new holders of the EURA stablecoin remained after the end of the program and a considerable part of them (approx. 50%) kept staking their EURA stablecoin into stEUR to gain the RWA yield associated with it (see addendum above). In order to make a better use of the STIP Bridge incentives and deepen Angle’s presence on Arbitrum, Angle contributors decided to submit the deployment of the Angle PSM on Arbitrum to a vote by Angle DAO (currently it is only deployed on Ethereum mainnet) to solve liquidity issued and make an even more efficient use of the STIP Bridge. The core contributors are working on the technical implementation and it will be submitted to vote at the end of June maximum (probably before but stating end of June as a precaution).\n\nChange use of incentives from EURA to USDA, and from liquidity incentivization to perpetuals DEXes and money market use cases: As noted in the ARDC report liquidity is hard to acquire and lack of liquidity hinders development potential. For that reason the deployment of the Angle PSM on Arbitrum will be submitted to Angle DAO (see above). The STIP bridge incentives that were almost entirely dedicated to deepening liquidity will thus be used differently. They will be used to keep supporting a protocol that was included initially (i.e. Silo) and Vela Exchange. The goal is to dedicate the use of these incentives to two distinct but complementary use cases of both USDA and stUSD as loan currency then margin collateral. Please also note that in general, USD stablecoins have a larger addressable market and integration possibilities in the current Defi landscape than the EURO stablecoins, that remain niche in DefFi ans are largely used for Forex trades and payments via cards (Gnosis Pay, Holyheld etc.) even though the report indeed rightfully mentions that the EURA supply grew on Arbitrum post STIP and did not go back down to the original supply, in addition to Arbitrum holder growth and volume growth that we have noted in the addendum above.\n\nTracking and reporting: Angle will set up a Dune dashboard in addition to the team-built analytics and Merkl statistics that were initally used in order to allow a real-time and trackable reporting for the STIP Bridge (with the help of OpenBlock if applicable). Improvements on the tracking/reporting side will me implemented.\n\nReward program by Angle and upcoming integrations of USDA and stUSD for increased network effects: Angle has set up a reward program geared towards protocols that will be announced this week and will be applicable to all protocols creating network effect and utility for users of USDA, including on Arbitrum, irrespective of whether they or Angle participate to the STIP Bridge program. Also as mentioned, the integration possibilities being higher for USD than Euro, USDA already has integrations planned in various few Arbitrum protocols that will be made possible thanks to the upcoming deployment of the Angle PSM on Arbitrum. These integrations along with the reward program in place will complement and multiply the effects created by the STIP Bridge if the opportunity to participate to the program is granted.\n\nI hope the above provides more context as to Angle’s short term plans for Arbitrum, USDA and the usage of the STIP Bridge allocation.\n\n post by Frisson on May 23, 2024\n\n Frisson\n\n I voted to approve funding from this STIP bridge addendum because I am satisfied with the team’s plans to improve reporting and improve performance by shifting incentives from liquidity incentivization to specific collateral use cases.\n\n post by Mariam on May 24, 2024\n\n Mariam\n\n Thank you for your feedback and vote @Frisson!\n\n post by mcfly on May 26, 2024\n\n mcfly\n\n On behalf of the Arbitrum community members who delegated their voting power to us, we’re voting Against this proposal.\nWhile Angle achieved respectable growth in some key metrics during the initial 700K ARB STIP, with EURA holders increasing 8%, trading volume rising 114%, and peak TVL jumping 1753%, the sustainability and cost-efficiency of these gains is questionable.\nThe fact that TVL stabilized at a much lower $2.3M (+538%) after the program ended, with many new EURA/stEUR holders removing their liquidity from pools, suggests the incentives did not create lasting, organic protocol adoption. An 8% increase in EURA holders for 700K ARB also seems like a relatively expensive acquisition cost.\nWe do see promise in the learnings around single-sided liquidity provision with lending platforms like Silo. Focusing the bridge round on this mechanism for the new USDA stablecoin makes strategic sense given the larger addressable market for USD-based assets.\nAllocating 250K ARB to USDA liquidity on Silo and other lending markets, with 100K reserved for stUSD liquidity on Arbitrum perp DEXes like Vela or further USDA incentives based on initial results, is a sound plan. The emphasis on progressive reward distribution to maintain a stable APR and wide participation is also encouraging.\nHowever, absent clearer projections on the expected impact of this 350K ARB investment and a more definitive assessment on the ROI of the first 700K, we are hesitant to extend the program at this juncture.\nWith USDA at $10M TVL just two weeks post-launch, it seems prudent to allow more time for natural growth trajectories to emerge before deploying additional liquidity incentives. We would recommend first gathering data on the stickiness of this initial traction and the marginal returns on incremental rewards.\nTherefore, while we commend Angle on their overall STIP execution and the thoughtful iterations in their bridge proposal, we believe pausing rewards to assess the sustainability of USDA’s early momentum is the responsible path forward.\nShould Angle demonstrate evidence of continued organic growth and the potential for targeted incentives to efficiently accelerate it, we would eagerly reevaluate a revised proposal. But at this stage, we feel the community’s funds are best reserved until a clearer case for the ROI on liquidity mining can be made.\nWe appreciate Angle’s commitment to supporting the Arbitrum ecosystem and look forward to future opportunities to collaborate on sustainably growing the DeFi community.\n\n post by Tane on May 27, 2024\n\n Tane\n\n We vote to reject funding the protocol.\nReasoning: While we understand the team promised to improve the method and reporting process, we don’t consider a complete shift to the red-ocean USD stablecoin market is qualified for a bridge funding.\n\n post by maxlomu on May 27, 2024\n\n maxlomu\n\n gm, I am voting FOR.\n\nThe team successfully increased the TVL of a new EURO stablecoin on Arbitrum. While this operation was costly in terms of ARB, I believe a stablecoin differentiation (different currencies) is beneficial for our L2.\n\nI echo this, the distribution plan seems solid to me, and I hope the Angle team will do a better job at reporting.\n\n post by PrincetonBlockchain on May 27, 2024\n\n PrincetonBlockchain\n\n PBC voted to abstain from the Angle STIP Bridge grant.\nOur team was out of office this week and was unable to do a complete review of the request/challenge in time for voting.\n\n post by PGov on May 28, 2024\n\n PGov\n\n We support Angle’s STIP Bridge addendum for its introduction of the USDA and stUSD stablecoins, which promise high yields and robust backing. Additionally, the strategic allocation of incentives towards single-sided USDA liquidity on lending markets and stUSD liquidity on perpetual DEXs ensures sustainable growth and increased activity on Arbitrum. This targeted approach will drive user engagement and enhance liquidity in the ecosystem, we are in favor.\n\n post by WinVerse on May 28, 2024\n\n WinVerse\n\n DAOplomats voted to Approve funding.\nWe were happy to support this project based on the milestones met and plans for this addendum. With plans to set up a Dune dashboard, we are confident reporting will be properly done this time.\n\n DAOplomats Delegate Communication Thread\n\n post by ITUblockchain on May 28, 2024\n\n ITUblockchain\n\n ANGLE, with its offered features and the new niches it has introduced for DeFi, is a value-added product, as evidenced by the KPIs presented in previous STIPs (which are clearly significant for the Arbitrum ecosystem). We believe that presenting the proposal with an Addendum and new approaches is optimistic for the sake of the Arbitrum ecosystem.\n\n post by cp0x on May 28, 2024\n\n cp0x\n\n The project increases its TVL from the beginning of the grant to now from 300k to 2 million.\nI like that they plan to spend the grant on the USDA launched and profitable stUSD with 20% APY\n\n post by AbdullahUmar on May 28, 2024\n\n AbdullahUmar\n\n Below are the opinions of the UADP:\nWe voted FOR this proposal. The increase in TVL for EURA during the incentive period was impressive, even though it dropped from its peak of nearly a 19x increase–the stability of the TVL is what we find more impressive, increasing from $361k to $2.3M. We hope that a similar result can be achieved for USDA. Our team is glad to see diversified products being launched in the stablecoin space.\n\n post by jameskbh on May 31, 2024\n\n jameskbh\n\n For tracking purposes, I’m copying the reasoning given on my snapshot vote:\nReason: The changes are welcomed, and the protocol seems to use the lessons learned to make a strong proposal.\n\n 27 days later\n\n post by sogipec on Jun 28, 2024\n\n sogipec\n\n Update:\nTurns out that we hadn’t used the full budget that the Arbitrum DAO had allocated to us for the STIP. We’ve returned the leftover amount to the STIP Multisig: Arbitrum One Transaction Hash (Txhash) Details | Arbitrum One\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [ANGLE PROTOCOL] [FINAL] [STIP - Round 1]\n\n Short Term Incentives Program (STIP) Round 1\n\n 25\n\n 4.0k\n\n Jan 2024\n\n Stake DAO STIP Addendum\n\n STIP Bridge Addendum\n\n 20\n\n 1.2k\n\n May 2024\n\n [FINAL] Umami Finance STIP Addendum\n\n STIP Bridge Addendum\n\n 14\n\n 1.1k\n\n May 2024\n\n Angle Protocol Bi-Weekly Updates\n\n Biweekly Updates (STIP)\n\n 10\n\n 1.3k\n\n May 2024\n\n Angle Protocol (stUSD & stEUR) STEP Application - STEP Application\n\n STEP Applications & Updates\n\n 0\n\n 746\n\n Apr 2024","tokens":7107,"squid":"spider-07","role":"Council Spider","at":1791345355004,"hash":"47c2c2e2bcac8b82d6098d6c0cfb636b3e8f27c5"}
{"url":"https://forum.across.to/t/velodrome-liquidity-program-extension/1752/21","domain":"forum.across.to","title":"Velodrome Liquidity Program Extension - Proposals / Active Proposals - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n ProposalsActive Proposals\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 6\n\n 4\n\n 3\n\n 2\n\n read \n\n 6\n min\n\n Oct 2023\n\n 20 / 20\n\n Jan 2024\n\n Jan 2024\n\n post by Methodic on Oct 31, 2023\n\n post by Methodic on Oct 31, 2023\n\n post by TheRealTuna_Across on Nov 2, 2023\n\n post by neondaemon on Nov 3, 2023\n\n post by btctdm on Nov 7, 2023\n\n post by PVMihalache on Nov 7, 2023\n\n post by Kevin_UMA on Nov 7, 2023\n\n post by DerivativeKid on Nov 8, 2023\n\n post by Methodic on Nov 9, 2023\n\n post by Methodic on Nov 9, 2023\n\n post by Methodic on Nov 9, 2023\n\n post by Kevin_UMA on Nov 9, 2023\n\n post by Kevin_UMA on Nov 9, 2023\n\n 20 days later\n\n post by caesarsherrod.eth on Nov 30, 2023\n\n post by Methodic on Dec 5, 2023\n\n 1 month later\n\n post by PVMihalache on Jan 6, 2024\n\n post by PVMihalache on Jan 6, 2024\n\n PVMihalache\n\n But that’s not all. In January I used Velodrome again and got drained again. All the $POOL I had was gone, along the USDC! Lost another $22k and again no reaction. Was asked if I was using the correct link and was recommended to change the wallet. That’s my tl;dr on why I don’t trust Velodrome and I don’t want for this be renewed. Raising awareness and trying to keep everyone’s safe \n\n post by alexander on Jan 8, 2024\n\n alexander\n\n We have repeatedly demonstrated to you that your wallet was in someway compromised and it has nothing to do with Velodrome – you continuing to both use that wallet and blaming Velodrome for the continued loss of funds is absurd.\nHere is the attacker’s address who drained your funds on 12/20. You can see they are exploiting a number of wallets, none of which have any history of interacting with Velodrome at all.\n0x447edbf56d58468b621867cf6dc455d7e31e6c36\nVelodrome has thousands of transactions every day and no one has reported any issues outside of the context of the attack on our DNS provider. I would highly recommend you review your own personal OPSec and if you want to know the true cause, investigate any similarities between your wallet’s approvals and those of the other victims of the attacker.\n\n post by PVMihalache on Jan 8, 2024\n\n PVMihalache\n\n Nothing was demonstrated, my ticket was answered after 14 days, and was told its “unlikely” it was caused by my interaction with Velo. Poor support and lack of empathy as well!\n\n post by alexander on Jan 8, 2024\n\n alexander\n\n If you have any evidence that Velodrome played any role in that exploit, then you are welcome to present it, until then you are just posting what is essentially slander rather than seeking to understand the actual attack vector or taking steps to insulate yourself from further attacks.\nAnyone who reviews your exploiter’s transactions can see clearly that there is no demonstrable link to Velodrome. If someone tried to blame Across in a similar manner, I’m sure their team would pushback as well.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Build liquidity for $ACX on Velodrome\n\n Active Proposals\n\n treasury-funding\n\n Active Proposals\n\n 8\n\n Jul 2023\n\n Across ($ACX) Community Initial Liquidity Proposal\n\n Passed Proposals\n\n Passed Proposals\n\n 49\n\n Nov 2022\n\n Across Token Launch Proposal v2\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 47\n\n Nov 2022\n\n $ACX Liquidity - Update and Feedback Wanted\n\n Ideas & Feedback\n\n Ideas & Feedback\n\n 7\n\n Jun 2023\n\n Reduce ACX emissions for ACX LPs, WBTC LPs and wstETH/ACX LPs\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 11\n\n Aug 2024","tokens":2357,"squid":"spider-09","role":"Bridge Spider","at":1791345361034,"hash":"6070f4d216b0638a6b7644c434ccf5787ce06df5"}
{"url":"https://forum.arbitrum.foundation/t/angle-protocol-draft-stip-round-1/17104/2","domain":"forum.arbitrum.foundation","title":"[ANGLE PROTOCOL] [FINAL] [STIP - Round 1] - Archive / Short Term Incentives Program (STIP) Round 1 - Arbitrum","text":"The Arbitrum Foundation notified the Security Council on the need to perform a potential Emergency action. Following a review of the details and known risks, the Security Council decided to execute the upgrade and it was completed at 11:30 EST on 2nd October 2026.\nThis report provides an overview of the risks that required the Security Council Action:\n\nAdd a permissionless guard for the One-Step Proof of BoLD on Arbitrum One\n\nTemporarily pause activation of new Stylus contracts on Arbitrum One & Nova\n\nKey point: To date, known bugs for Stylus primarily impact chain liveness (e.g., denial of service attacks) and do not put any user funds at risk.\nWhy was this action taken\nLet’s take this opportunity to explain why action was taken on two separate issues concerning BoLD and Stylus.\nInstalling the guard for One-Step Proof of BoLD. Given the rise of AI-assisted attacks, we have implemented a precautionary approach that allows anyone to pause settlement of Arbitrum One on Ethereum if there are at least two conflicting answers that pass at the same level in which only one should be valid and pass. This is to halt a class of publicly verifiable and detectable attacks that exploit a bug in the one-step proof. If halted, Arbitrum One will continue to process as normal except that messages from Arbitrum One to Ethereum, such as withdrawals, that are not yet confirmed will have to wait. This provides time for the Security Council to deploy a fix for the bug and resume the rollup.\nPreventing activation of new Stylus contracts. AI-assisted tooling has led to an increasing number of sophisticated attacks on hand-crafted WASM programs that do not use the standard Stylus compiler toolchain. These programs are specifically designed to cause unexpected behaviors such as degrading the chain’s performance for all other users. To date, no attacks have been discovered that permits theft of user funds.\nNew ArbOS releases have patched several reported bugs and known attacks over the past few months, but out of an abundance of caution, we have decided to temporarily pause new activations of Stylus contracts. This was executed as an emergency action to prevent the deployment of new hand-crafted WASM programs that are not yet patched by the current version of ArbOS on the Arbitrum network.\nThe Arbitrum Foundation has informed the Security Council that they will work with the ArbitrumDAO to discuss next steps on the timeline and manner for enabling activation of new Stylus contracts. The Arbitrum community remains confident in the value of Stylus and want to preserve these use cases while taking preventative measures against Stylus-based attack vectors as AI-assisted attack tooling continues to evolve.\nImpact on builders and users\n\nNo new activations. New Stylus contracts cannot be activated during the pause including new versions of existing applications that require activation.\n\nExisting contracts are not paused. Already-active Stylus contracts continue to execute until expiration. This pause does not deactivate them.\n\nThe ArbOS 61 upgrade renewed all active contracts on Arbitrum One, so no currently active contract expires before August 20, 2027.\n\nRenewal via keepalive stays permissionless and is unaffected by the pause.\n\nReactivating an expired contract, or one that needs to be updated after a Stylus version change, is paused.\n\nUsing/calling any activated Stylus contract stays permissionless for all users and developers.\n\nNo impact on EVM. Solidity (EVM) contract deployment and execution are unaffected by this Security Council action.\n\nSecurity Council Actions\nThere are two actions bundled into a single payload:\n\nOne-Step Proof Guard. The L1UpgradeExecutor gives a new pause contract (PauseExecutor) the ability to pause and nothing else. The new pause contract grants the guard (OspSoundnessGuard) PAUSER_ROLE to use it. Anyone can show the guard two conflicting answers to the same step of an open challenge. If the one-step proof accepts both, the guard has the pause contract put Arbitrum One’s settlement to Ethereum on hold.\n\nStylus deactivation. The Security Council called ArbOwner.setWasmActivationGas(2^64 - 1) to raise the Stylus activation gas requirement on Arbitrum One and Nova. This makes activation prohibitively expensive and effectively disables new activations. This is a configuration change and does not require an ArbOS upgrade.\n\nThe Security Council signed the following transactions to update the configuration:\n\nEthereum: Ethereum Transaction Hash: 0x30732bb7d2... | Etherscan\nArbitrum One:\nArbitrum One Transaction Hash: 0x9eb3a4be3b... | Arbitrum One\nArbitrum Nova:\nArbitrum Nova transaction 0x79e0fed470dff7a22059b108e3f8f42eddd2b580a6771594060c4e7326c5f984 | Blockscout\n\nAn external audit was conducted for the OSP Guard contracts. No audit is required for the Stylus deactivation as it is only updating a single parameter in the ArbOS configuration.\n\n ArchiveShort Term Incentives Program (STIP) Round 1\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Sep 2023\n\n 2 / 26\n\n Sep 2023\n\n Jan 2024\n\n post by Mariam on Sep 26, 2023\n\n Mariam\n\n This is an updated proposal following comments received below in respect of the initial draft.\nApplicant Name: Mariam Kouanda\nProject Name: Angle Protocol\nProject Description: Angle Protocol is a Defi protocol that launched:\n\nagEUR, the most liquid Euro stablecoin;\nstEUR, a staked agEUR paying a yield coming from RWAs held in Angle’s reserves and protocol fees (newly launched on 25 September 2023); and\nMerkl, a smart incentivization system for concentrated liquidity used by major Arbitrum DEXes.\n\nTeam Members and Qualifications:\nPablo Veyrat - Cofounder of Angle\nGuillaume Nervo - Cofounder of Angle\nPicodes - Cofounder of Angle\nMariam Kouanda - Head of growth at Angle\nProject Links:\n\nWebsite - https://www.angle.money/\nDocumentation Portal - Angle Documentation Portal | Angle Docs\nGithub - Angle · GitHub\nAudits - Audits | Angle Docs\nTwitter - https://twitter.com/AngleProtocol\nAnalytics and Balance Sheet - Angle Analytics\n\nContact Information\nTG: @MariamKd\nTwitter: https://twitter.com/TheBlockAdopter\nEmail: mariam.k@angle.money\nDo You Acknowledge That Your Team Will Be Subject to a KYC Requirement?: Yes\nSECTION 2: GRANT INFORMATION\nRequested Grant Size: Between 200,000 $ARB and 700,000 $ARB, to be released according to milestones (see grant timeline below with milestones included).\nGrant Matching: Yes. Native yield in agEUR will distributed from Angle Protocol’s profits and reserves, currently 4% APY on stEUR.\nGrant Breakdown:\nAs a reminder, stEUR is a staked agEUR paying a fixed 4% APY coming from RWAs held in Angle’s reserves and protocol fees.\nThe grant will be distributed to (see grant timeline below for milestones):\n\nincentivize a stEUR/USDC Camelot v3 pool from 1 November 2023 to 31 January 2024 with up to 250,000 $ARB;\nincentivize a stEUR/ARB Camelot v3 pool from 1 November 2023 to 31 January 2024 with up to 250,000 $ARB;\nincentivize a stEUR/wstETH Camelot v3 pool from 1 November 2023 to 31 January 2024 with up to 100,000 $ARB;\nincentivize the use of stEUR as collateral to borrow USDC on a native lending protocol (Radiant) with 100,000 $ARB (to be unlocked only if the integration is secured prior to December 15, 2023);\n\nIf this grant request is approved, Angle will immediately:\n(1) deploy stEUR and native agEUR staking on Arbitrum in order to create the first RWAs and Euro based savings rate on Arbitrum;\n(2) add $ARB as a token to mint agEUR natively on Arbitrum;\n(3) work on use cases and integration for stEUR in order to push this program beyond liquidity incentivization (e.g. lending, yield tokenization etc.).\nThe grant will not be used for development costs, only for supporting the development of stEUR on Arbitrum, promoting RWAs in the ecosytem, enabling integrations across the ecosystem and its pairing with $ARB and $wstETH.\nFunding Address: 0xAA2DaCCAb539649D1839772C625108674154df0B\nFunding Address Characteristics: 4/6 Safe multisig composed on Angle core team members and ecosystem participants. More details on the multisig composition here.\nContract Address: Incentivization will go through Merkl, the incentivization tool built by Angle Labs, that enabled concentrated liquidity incentivization. Merkl related contract addresses can be found here.\nSECTION 3: GRANT OBJECTIVES AND EXECUTION\nObjectives: The objectives are:\n\nLaunch the first RWA and Euro-based yield source on any L2 with stEUR and bring the first savings rate to Arbitrum\nCreate deep Euro liquidity on Arbitrum with stEUR and so indirectly with agEUR\nUse the development of stEUR on Arbitrum to support $ARB volume and liquidity with a stEUR/ARB pool\nFurther support the use of $ARB by enabling agEUR minting with $ARB\nUse the development of stEUR on Arbitrum to support $ETH volume and liquidity with a stEUR/wstETH pool\nFurther the use of RWAs-related assets on Arbitrum and taking this program beyond liquidity incentivization by supporting the use of stEUR as collateral on a lending protocol and promoting other use cases\n\nKey Performance Indicators (KPIs):\n\nAngle TVL on Arbitrum\nNumber of circulating stEUR on Arbitrum\nPercentage of stEUR natively staked on Arbitrum and portion of Angle revenue distributed on Arbitrum (breakdown between Ethereum and Arbitrum)\n$ARB volume and liquidity relating to the stEUR/ARB pool to be set up\n$wstETH volume and liquidity relating to the stEUR/wstETH pool to be set up\n\nHow will receiving a grant enable you to foster growth or innovation within the Arbitrum ecosystem?:\nThis is an opportunity to provide all Defi users on Arbitrum (and not only Euro inclined ones) with:\n\na simple and real yield coming from RWAs;\na state of the art application of RWAs in the space;\ncomposability opportunities with enabling borrowing with stEUR and other use cases.\n\nThis grant would make Arbitrum the home of the first Euro and RWA based yield source and the most cost effective option to benefit from that opportunity. Arbitrum would be the first L2 to provide and support such an opportunity with stEUR (staked agEUR).\nAs mentioned, this will incidentally grow Euro liquidity on Arbitrum giving it a and boost in terms of stablecoins’ and currency’s diversity in the Defi ecosystem.\nJustification for the size of the grant:\nagEUR and the Angle Borrowing module have been deployed on Arbitrum since July 2022 to allow native minting of agEUR on the chain.\nAll these products have undergone audits and development work. This includes significant developement work made by Angle to allow a 1-click leverage from on Curve pools on Arbitrum in the Angle borrowing module.\nAngle has been active in the Arbitrum ecosystem, in particular through its Merkl product, the smart incentivization tool that is today used by Uniswap to distribute close to 2M ARB to increase volume and liquidity in several pools but also by DEXes such as Sushiswap and Camelot. Working with these partners have required bespoke integrations and smart contract work to cater to the development of liquidity and volume on Arbitrum for these DEXes.\nstEUR is a new product that enables value-sharing by streaming protocol revenue to agEUR stakers.\nThis grant will:\n\nsupport the further adoption on Arbitrum of all the above mentioned products (agEUR, agEUR borrowing using $ARB, stEUR and Merkl);\nthe sizing and duration will allow a compelling support RWAs-related opportunities on Arbitrum;\nthe sizing and duration will allow the development of a stEUR liquidity to develop use cases for it apart from LPeing in pools (use stEUR as collateral, integration in yield-related products like Pendle etc.);\nsupport both $ARB and $ETH liquidity and volume.\n\nThe grant is requested to migrate stEUR stakers to Arbitrum and incidentally support $ARB and $ETH in order to unlock a total TVL in the above-mentioned pools of $14+ millions in total, including, approximately €7m worth of stEUR on Arbitrum (see the grant timeline with milestones below).\nExecution Strategy:\nUse of Merkl to incentivize on Camelot v3\nThe pools to be set up are concentrated liquidity pools on Camelot.\nIncentivizing concentrated liquidity is initially difficult to implement. To do so, Angle will use Merkl, the tool developed by Angle Labs.\nThis tool is already in use since 2022 and trusted by several concentrated liquidity DEXes and projects to incentivize concentrated liquidity including Uniswap, Camelot, Sushiswap, Retro and others.\nFees do not apply when Merkl is used to incentivize agEUR and stEUR pools. This means the the use of Merkl will not incur any fees charged to the benefit of Angle Labs.\nIncentivization of the pools for a maximum total of 600,000 $ARB (see grant timeline for milestones)\nIf found are allocated to Angle to develop the stEUR while boosting the use of ARB and ETH on Arbitrum, we will immeditaly set up the three following pools:\n\nCamelot v3 stEUR/ARB\nCamelot v3 stEUR/wstETH\nCamelot v3 stEUR/USDC\n\nIncentivization for the use of stEUR as collateral on Radiant for a total of 100,000 $ARB (see grant timeline for milestones)\nUpon incentivization of the above-mentioned pools and development deep liquidity for stEUR on Arbitrum, the Angle team shall seek the listing of stEUR as collateral on Radiant as a native Arbitrum lending protocol and incentivize this use case.\nThis integration shall be worked on by the Angle team and the selected lending protocol prior to December 15, 2023 to unlock this portion of the grant.\nGrant Timeline:\n\nThe grant shall be awarded in three monthly tranches according to milestone as mentioned in the tables below.\nIf after the first month less than 75% of the global stEUR targets is reached, the program shall be stopped. Above 75%, the program shall continue over the second month.\nIf after the second month, less that 75% of the second month stEUR global target is reached, the program shall be stopped. Above 75%, the program shall continue over the third month.\n\nFirst month - 1 November 2023 to 30 November 2023\n\nDeployment of stEUR on Arbitrum\nEnabling of native staking of agEUR on Arbitrum\nEnabling agEUR borrowing with $ARB\nIncentivization on stEUR pools as follow\n\nPools\nDistributed $ARB\nMilestone Goal in TVL in the pool\n\nCamelot v3 stEUR/ARB\n83,333\n$1.4m\n\nCamelot v3 stEUR/wstETH\n33,334\n$1.3m\n\nCamelot v3 stEUR/USDC\n83,333\n$4m\n\nGlobal\n200,000\n$6.7m\n\nSecond month - 1 December 2023 to 31 December 2023\n\nAssessment of the first month stEUR global target and continuation if >75%\n\nPools\nDistributed $ARB\nMilestone Goal in TVL in the pool\n\nCamelot v3 stEUR/ARB\n83,333\n$1.5m\n\nCamelot v3 stEUR/wstETH\n33,334\n$1.4m\n\nCamelot v3 stEUR/USDC\n83,333\n$4.25m\n\nGlobal\n200,000\n$7.15m\n\nThird month - 1 January 2024 to 31 January 2024\n\nAssessment of the second month stEUR global target and continuation if >75%\n\nPools/Lending\nDistributed $ARB\nMilestone Goal in TVL in the pool\n\nCamelot v3 stEUR/ARB\n83,333\n$1.7m\n\nCamelot v3 stEUR/wstETH\n33,334\n$1.5m\n\nCamelot v3 stEUR/USDC\n83,333\n$5m\n\nRadiant (native lending protocol)\n100,000\n$8m\n\nGlobal\n300,000\n$16.2m\n\nDo you accept the funding of your grant streamed linearly for the duration of your grant proposal, and that the multisig holds the power to halt your stream? Yes\nSECTION 4: PROTOCOL DETAILS\nIs the Protocol Native to Arbitrum?: Yes. Angle protocol was initilly deployed on Ethereum but deployed it borrowing module natively on Arbitrum. This allows the native minting of agEUR on the chain.\nOn what other networks is the protocol deployed?: agEUR is deployed on at least 12 chains. However the protocol in itself is deployed only on Ethereum, Arbitrum, Optimism, and Polygon.\nWhat date did you deploy on Arbitrum?: agEUR and Angle Borrowing module were deployed on Arbitrum in July 2022.\nProtocol Performance:\nAs at 27 September 2023, Angle Protocol has a global TVL of $27m and agEUR has 581.k holders.\nAngle has newly launched the stEUR on 25 September 2023 at 5pm CET. Currently, 48 hours hours after launch, $3m worth of agEUR have been staked for stEUR.\nScreenshot 2023-09-27 at 15.49.402148×460 46.3 KB\nAs at 27 September 2023, Angle has $1m TVL on Arbitrum.\nThe potential deployement of stEUR on Arbitrum is a first of a kind, simple and useful usage on which the Angle can rely on to grow further on Arbitrum while supporting RWAs use cases and ARB on the chain.\nScreenshot 2023-09-27 at 15.51.502106×822 104 KB\nWith its tool Merkl, Angle Labs helps to power more liquidity and volume on concentrated liquidity pools across DEXes such as Uniswap, Camelot, Sushiswap etc.\nScreenshot 2023-09-25 at 18.57.342822×1406 411 KB\nThe protocol is also focused on providing transparency and making protocols’ reserves and financials accessible and readable by all.\nAngle has built and maintains an analytics showing the protocol balance-sheet, reserves and TVL progression in real time. The goal is to add more details useful to all participants including a soon to come event page that will detail all events by chain. This will also allow tracking of performance on Arbitrum.\nProtocol Roadmap:\nAngle newly deployed stEUR on 25 September 2023 (i.e. just 1 day prior to the posting of this proposal). The protocol future roadmap consists in:\n\nre-enforcing the diversification and resilience of the protocol’s reserves by exploring additional collaterals, including yield-producing collaterals;\nimplementing a fully on-chain governance, it being noted that the on-chain governance will allow voting on both Ethereum and Arbitrum;\nFurthering the integrations for the newly launched stEUR;\nDelivering more details in the analytics of the protocol that provide all details to stakeholders on the financial state of the protocol.\n\nAudit History:\nThe protocol has been audited:\n\n1 time by Code4rena\n3 times by ChainSecurity\n1 time by Sigma Prime\n\nNo critical findings remained unresolved. Audits are available here.\nSECTION 5: Data and Reporting\nIs your team prepared to create Dune Dashboards for your incentive program?: Yes or another dashboard providing a similar level of information.\nDoes your team agree to provide bi-weekly program updates on the Arbitrum Forum thread?\nAngle analytics is publicly available.\nIt will allow anyone at all times to see agEUR minted on Arbitrum but also agEUR staked on Arbitrum (stEUR). In addition, I (Mariam) or Pablo (Angle’s Cofounder) will be able to provide bi-weekly program updates.\nDoes your team acknowledge that failure to comply with any of the above requests can result in the halting of the program’s funding stream?: Yes\n\n Short-Term Incentive Grants Pitching Sessions\n\n 5\n\n 2\n\n 2\n\n 2\n\n 2\n\n read \n\n 10\n min\n\n post by meyaf320219 on Sep 26, 2023\n\n meyaf320219\n\n Up to 1.1m ARB to incentivise the liquidity of a single token is really quite hard to compherend.\nWhilst I appreciate the work you are doing with stEUR/agEUR, it really is hard to justify such a large amount for a non-native protocol and on just one single token.\nWhy does the proposal not take into account any other Arbitrum protocols? Uniswap and a “lending protocol” is disappointing when the entire purpose of this framework is to incentivise Arbitrum builders.\nThis proposal is a large cost to the DAO that almost entirely generates value just for Angle.\nPlease could you also detail the incentives and liquidity you have achieved so far for this token? Thanks\n\n post by Mariam on Sep 26, 2023\n\n Mariam\n\n Hi meyaf320219,\nThanks a lot for your feedback.\nPlease see answers below. Going from there we’re happy to incorporate feedbacks to improve the proposal.\nScope and value of the program for Arbitrum\n\nSupporting the adoption of the first savings rate on Arbitrum and any L2\nGiving access to a fixed 4% Euro-based real yield to Arbitrum users\nincentivizing ARB, USDC, wstETH along with stEUR\nCreating the base for composability opportunities with a RWA-related asset (i.e. stEUR liquidity)\n\nAmount requested\nThe initial amount requested is 333,334 ARB with potential extensions.\nThe proposal suggest the release of a second tranche of the grant only if a $9m TVL (75% of the target) is achieved across the 3 pools incentivized after 1 month.\nThe same logic applies for any extension of the grant from the 2nd month to the 3rd.\nHappy to hear improvements suggestion on that part.\nInclusion of other Arbitrum builders\n\nThis proposal include further building on Arbitrum on Angle’s part including adding $ARB as collateral to mint agEUR\nThe initial proposal is to use of the most popular DEX on Arbitrum by TVL and volume (i.e. Uniswap v3) to host the incentivized pools → we are very happy to hear any suggestion from you or any other stakeholders on the alternative they would like to see\nComposability of a RWA-based asset in Defi starting with using stEUR as collateral in lending → this bit and many other uses of this opportunity by Arbitrum builders is conditional to the presence of enough stEUR liquidity on the chain. And the portion of the grant relating to integrating stEUR as a lending collateral would not be used if there is no integration to incentivize.\n\nAdding here again that we’re open to suggestions to improve the proposal, if any.\nMore information on the savings rate and stEUR\nagEUR staking and stEUR have been deployed 24 hours ago on Ethereum Mainnet.\nIt has never been incentivized and there are currently 2.4m stEUR from users who started using the contract to benefit from the savings rate.\nPlease let us know your thoughts on the above as well as your suggestions if any!\n\n Treasure Delegate Communication Thread\n\n [ FINAL] ANGLE STIP Bridge Addendum\n\n post by Matt_StableLab on Sep 26, 2023\n\n Matt_StableLab\n\n Hello @Mariam thank you for your application! Your submission meets all requirements to be considered for a snapshot vote.\n\n post by peter on Sep 26, 2023\n\n peter\n\n Hi Mariam,\nThanks for the proposal.\nThe Arbitrum Incentive exists primarily to nurture the Arbitrum ecosystem, including builders and users. It’s a win-win cooperation program, as evidenced by the sentiment across the forum.\nI agree with @meyaf320219 mentioning that this proposal only focuses on stEUR liquidity on Uniswap, which is not Arbitrum native and leverages stEUR through minting and lending. Although stEUR is a protocol great forward as the first Euro RWAs yield-bearing asset, it’s a still new product that just has launched and has not been proven its liveness on mainnet, where the protocol focuses on and starts with.\nHowever, Angle Protocol and Merkl are both good products. Angle Lab is a great team with their commitment, talent, and transparency. They are real builders in this space and deserve an Arbitrum grant to grow the first Euro RWAs native yield-bearing assets, which will bring many benefits when it can interact with many users with cheap transactions as Arbitrum offers.\nI suggest that Angle Lab adjust the requested amount to be more reasonable and use native Arbitrum DEXs and money markets as their liquidity and leverage solutions for stEUR.\nI hope this feedback is helpful.\n\n post by Perl on Sep 26, 2023\n\n Perl\n\n I wouldn’t change a word of this post. I’m sure this proposal could, and imho should, pass with the suggested improvements.\n\n post by Mariam on Sep 27, 2023\n\n Mariam\n\n peter\n\n @peter @Perl @meyaf320219 @Matt_StableLab and all reading this post - Please see above a revised version of the draft proposal to (1) include native Arbitrum protocols to the execution and (2) revise the size of the request.\nAlso updated the protocol figures as the number of staked agEUR grew!\nThanks a lot for chiming in, i’ll be reading further comments!\n\n post by meyaf320219 on Sep 28, 2023\n\n meyaf320219\n\n this is great, the amount seems much more reasonable\n\n post by thecryptostakr on Sep 28, 2023\n\n thecryptostakr\n\n Hello @Mariam, thank you for choosing Arbitrum to implement this project.\nThese are my reasons for supporting the Angle Protocol proposal:\n\nGreat team, pragmatic with good vision about the fusion between DeFi and RWA assets;\nAngle Protocol is a completely transparent protocol (something unique in DeFi), providing a platform (https://facts.angle.money/) for consulting transactions, treasury, liquidity composition, etc.;\nLaunched the most liquid euro stablecoin on the market: agEUR;\nagEUR is the only yield bearing euro stablecoin;\nThe project states “native minting” of stEUR, therefore it means that this project implies native involvement in Arbitrum DeFi;\nArbitrum’s investment in this project and others like it contributes to the consolidation of Arbitrum as the Ethereum L2 DeFi hub, and the competition to be this DeFi hub is becoming very strong and aggressive. The first movers, with quality investments, are those who will be able to gain market share;\nThis project presented by Angle Protocol is a great opportunity for small crypto investors (European or non-European) to access a fantastic DeFi product (euro yield stablecoin), contributing to the expansion of the Arbitrum platform’s user base, as well as to the increased liquidity on this platform;\nI can say that, as a small investor in DeFi (and a European one), I am looking forward to this product being made available on a Layer 2 so that it is viable for me to make an investment. And I sincerely hope that this layer 2 is Arbitrum, the Ethereum L2 DeFi hub;\nTo conclude, investing in this project means much more than supporting a product (stEUR), it means bringing greater liquidity and the integration of RWA assets into DeFi across Arbitrum DeFi.\n\nPS:\n\nThrough the amended proposal, the amount of support requested has already been adjusted and a change in the implementation of the liquidity pools to a native protocol (Camelot) has been proposed;\nAs a holder of $ARB tokens, this amended proposal has my full support.\n\n post by abeltherebel on Sep 28, 2023\n\n abeltherebel\n\n Really respect the flexibility here, turning community feedback into action like this is a great sign of accountability. 100% in favor of the proposal.\n\n post by strategicreserve on Oct 1, 2023\n\n strategicreserve\n\n As a long-term partner of Angle, Gamma knows how intelligent and professional the Angle team is. We have enjoyed working with the team on their EUR products and with Angle Merkl. Angle is a team you want to have a presence on Arbitrum. We hope the delegates approve this proposal.\n\n post by Matt_StableLab on Oct 3, 2023\n\n Matt_StableLab\n\n Hello @Mariam ,\nNow that your application has been marked eligible, please be advised of the remaining steps in the application process to be completed prior to the Review Period Deadline:\n\nPlease complete the following steps required for your application to proceed to Snapshot:\n\nTo change your proposal to final, please tag an Arbitrum Foundation Forum Moderator (@ stonecoldpat @ cliffton.eth @ eli_defi) by the Review Period deadline to notify them of your proposal’s readiness to proceed from [Draft] to [Final] status.\nOnce notified, the Arbitrum Foundation Forum Moderator will adjust your title from [Draft] to [Final] status. Once marked as [FInal], your application post will be locked by moderators and you will no longer be able to edit your proposal.\n\n post by Mariam on Oct 4, 2023\n\n Mariam\n\n Hi @Matt_StableLab @stonecoldpat, @cliffton.eth and @eli_defi,\nWe would like to confirm that our application is ready be marked as [FINAL]. Please kindly change the title accordingly.\nThank you!\n\n post by cliffton.eth on Oct 4, 2023\n\n cliffton.eth\n\n Post has been marked FINAL and locked.\n\n post by litocoen on Oct 5, 2023\n\n litocoen\n\n The Angle team has really impressed me throughout this bear market continuously continuing to build new products as well as many public goods used in the Arbitrum ecosystem such as Merkl.\nI also think that building liquidity for a Euro stablecoin is beneficial to Arbitrum - as well as experimenting with RWA’s and the yield it will produce for stEUR holders.\nYou have my support!\n\n post by EynSoph on Oct 7, 2023\n\n EynSoph\n\n RWAs are big narrative in the space and I love how Angle is also helping drive that. If you’d like to do more with EUR, this is it. Happy to support their proposal and their endeavours on Arbitrum.\n\n post by WintermuteGovernance on Oct 9, 2023\n\n WintermuteGovernance\n\n Angle Protocol has contributed to the diversity of the DeFi ecosystem with the EUR based stablecoin and advanced liquidity mining efforts through Merkl. The outlined grant objectives align with the goals of the STIP and target collaboration between Arbitrum-native protocols. Furthermore, Angles focus on driving adoption of stEUR will provide important data and insights into the demand for RWAs on Arbitrum.\nWe look forward to supporting Angle Protocol’s grant application!\nAngle Protocol Summary Stats:\n\nLargest EUR stablecoin by DEX trading volume market share since May 2022 - 64.4% in September\n4th largest EUR stablecoin by Market Cap & largest decentralized stablecoin - $20M\n\nimage2409×750 136 KB\nSource: Dune, DefiLlama.\nDisclaimer: Wintermute is an investor in Angle Protocol\n\n post by SEEDGov on Oct 10, 2023\n\n SEEDGov\n\n Angle Protocol: @Mariam\nFrom @Seedgov led by the @cattin delegation, we want to convey our support to this proposal. The reasons why we agree are as follows:\n\nApplication size tied to milestones. Being the largest decentralized Euro Stablecoin in the ecosystem, they have described a number of interesting actions for the Arbitrum ecosystem; the implementation of STEUR, and the subsequent liquidity incentive in Camelot, may bring new interest to Arbitrum; the listing of ARB as asset collateral, will give it an interesting use that avoids the sell\n\nWe want to clarify that this is not the final vote, since as we clarify in this release, the final vote is defined by our community. We also want to invite you to attend our Governance Call that will be held tomorrow in our discord .\n\n SEED Latam Delegate Communication Thread\n\n post by Mariam on Oct 10, 2023\n\n Mariam\n\n Thank you to everyone here that has commented this proposal for improvements and support.\nIt’s particularly great to see Angle community members, users and delegates spontaneously providing feedback and the thoughts behind their support for this proposal. Thank you for your work, time and commitment to governance and new Defi development.\n@SEEDGov I would be glad to attend your governance call on behalf of Angle. Reaching out to arrange details!\n\n post by SEEDGov on Oct 10, 2023\n\n SEEDGov\n\n For more details you can see this post we made\n\n Load more posts below","tokens":7611,"squid":"spider-07","role":"Council Spider","at":1791345365369,"hash":"5cae229bb87f57c92e418b6789214bd1f212021e"}
{"url":"https://forum.across.to/t/build-liquidity-for-acx-on-velodrome/1643","domain":"forum.across.to","title":"Build liquidity for $ACX on Velodrome - Proposals / Active Proposals - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n Build liquidity for $ACX on Velodrome \n\n ProposalsActive Proposals\n\n treasury-funding\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n May 2023\n\n 1 / 9\n\n May 2023\n\n Jul 2023\n\n post by Methodic on May 21, 2023\n\n Methodic\n\n Related Discussions:\n\nSummary:\nCurrently, Across Protocol’s $ACX has little liquidity on Layer 2s, limiting the ability for users to acquire $ACX with low slippage and provide liquidity on L2s. This proposal aims to bootstrap $ACX liquidity on Velodrome and establish a meaningful presence for Across Protocol in the Optimism ecosystem.\nMotivation:\nL2 adoption has gained significant momentum over the past 12 months and is expected to continue as more users flock to ecosystems that inherit Ethereum’s security, while offering significantly cheaper fees and faster transaction times.\n\nL2 majors (Optimism & Arbitrum) alone have seen a net inflow of ~$4.3B by over 983,000 wallets and L2 users represent ~30% of all Ethereum users (compared to ~4.5% in July 2022).\nUsers also benefit from a better experience on L2s, saving about 95% in transaction fees compared to Ethereum mainnet with the average number of daily transactions on L2 majors having increased by about 7x since July 2022.\n\nAs a core cross-chain bridge, Across Protocol stands to grow alongside Layer 2s. Building a strong presence for $ACX on Optimism will give Across Protocol further exposure to the ecosystem and improve the user experience for those looking to buy or provide liquidity for $ACX.\nUpon successful completion of the pilot, Across will also benefit from receiving a veAERO airdrop to direct $AERO emissions and incentivize liquidity on Coinbase’s upcoming L2 chain, Base 2.\nSpecification & Implementation:\nOn Velodrome, $VELO emissions are directed to liquidity pools based on votes by veVELO (vote-escrow VELO) holders. Protocols such as Across can use veVELO or voter incentives (bribes) to attract votes and emissions for their liquidity pairs.\nProtocols bribing on Velodrome often receive $2-$3 in $VELO for every $1 they deposit. Major DeFi protocols such as Lido, Synthetix and Stargate leverage Velodrome’s mechanics to maintain deep liquidity on Optimism in a capital-efficient way.\nAcross will implement a 10 week pilot program using 750k $ACX tokens. The protocol will bribe the ACX/WETH liquidity pool on Velodrome at a rate of 75k $ACX per week. Velodrome also offers to match at least 5% of Across Protocol’s bribes each week with $OP tokens. Once an epoch is completed on Wednesday at 23:59 UTC, VELO emissions will begin to flow to Across Protocols’ LP.\nSimilar protocols typically attract 2-3x the value of their bribes in $VELO emissions. 75k $ACX tokens at current prices are worth about $3.5K; which Velodrome would complement with a minimum 5% bribe match, resulting in ~$9K of $VELO emissions going to the ACX pool at current rates. Using Aura’s $ACX/wstETH pool as reference which has an APR of 36% and ~820k in TVL, Velodrome could attract upwards of $1.3M TVL ($9K * 52 weeks / 36%). In other words, Across could achieve a ~50% growth in TVL on Velodrome for the same cost, while getting exposure to the Optimism community and a potentially new holder base.\nProtocol Owned Liquidity (POL)\nIf available, Across Protocol can also deposit Protocol Owned Liquidity (POL) to capture and farm a portion of $VELO rewards that are streamed to its pool. Across can lock all $VELO farmed as veVELO, allowing it to build a voting position that will direct additional emissions in perpetuity, while generating fee rewards, bribe rebates, and bonuses for locking. Any rewards generated by these locks can be compounded further into veVELO to grow protocol owned votepower and reduce reliance on voter incentives over time.\nLocking veVELO is an attractive strategy for protocols as it reduces net cost of incentive programs through a Lock Bonus airdrop, typically worth 10% of the $VELO locked, paid in OP. In addition, protocols with veVELO votepower will be eligible for the upcoming Aerodrome veAERO airdrop, which will enable protocols to bootstrap TVL for their tokens on Coinbase’s L2, Base and gain exposure to Coinbase’s 110m+ users and 80bn+ TVL.\nRationale:\nVelodrome is the single largest protocol on Optimism and the largest DEX on Layer 2 Ethereum with ~250M TVL. Velodrome’s governance community is one of the most active and diverse in crypto, with 14,300 veVELO holders participating in Velodrome’s weekly voting epochs.\nIncentivizing liquidity on Velodrome will naturally boost exposure for Across Protocol, as veVELO voters and Liquidity Providers will find $ACX near the top of the voting and LP pages respectively.\nVelodrome will also actively support Across Protocol’s marketing initiatives during the pilot program which means the community will not only benefit from having the option to provide liquidity and trade $ACX but also generate demand towards Across Protocol’s bridge services.\nDownsides:\nLiquidity incentives on Optimism can represent an additional expense for Across Protocol. However, this expense can be significantly reduced through Velodrome’s bribe-emissions multiplier and any potential VELO rewards and the other incentives described above.\nFurthermore, given this pilot program will run for 10 weeks, the DAO may use this time to assess results and decide on whether to continue or suspend its program on Velodrome after this period. At current prices, the total cost of the strategy to bootstrap liquidity via voter incentives without farming and locking $VELO emissions is about USD $35k (750k $ACX).\nVoting:\nYes - move forward with pilot program\nNo - do not move forward with program\nAbstain - no vote\n\n Discontinue ACX Bribes on Aura and Replace with Reward Locking in the Near Term\n\n post by eth-wei-trader on May 21, 2023\n\n post by Everythingblockchain on May 24, 2023\n\n post by Saludiego201 on May 26, 2023\n\n post by caesarsherrod.eth on Jun 1, 2023\n\n post by roundmound on Jun 2, 2023\n\n post by PVMihalache on Jun 8, 2023\n\n post by Alex_Goh on Jun 9, 2023\n\n 1 month later\n\n post by alexander on Jul 22, 2023\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n $ACX Liquidity - Update and Feedback Wanted\n\n Ideas & Feedback\n\n Ideas & Feedback\n\n 7\n\n Jun 2023\n\n Velodrome Liquidity Program Extension\n\n Active Proposals\n\n Active Proposals\n\n 19\n\n Jan 2024\n\n Across ($ACX) Community Initial Liquidity Proposal\n\n Passed Proposals\n\n Passed Proposals\n\n 49\n\n Nov 2022\n\n Tokenomics & Liquidity Incentives: Pair ACX w Across LP Tokens\n\n Ideas & Feedback\n\n liquidity\n\n Ideas & Feedback\n\n 2\n\n Aug 2023\n\n Reduce or Reallocate Across ACX LP emissions\n\n Ideas & Feedback\n\n liquidity\n\n Ideas & Feedback\n\n 2\n\n Sep 2023","tokens":3169,"squid":"spider-09","role":"Bridge Spider","at":1791345371286,"hash":"f3dd39f39efa5dce590aa07b57e9217f6135eb47"}
{"url":"https://forum.arbitrum.foundation/t/angle-protocol-final-stip-round-1/17104","domain":"forum.arbitrum.foundation","title":"[ANGLE PROTOCOL] [FINAL] [STIP - Round 1] - Archive / Short Term Incentives Program (STIP) Round 1 - Arbitrum","text":"The Arbitrum Foundation notified the Security Council on the need to perform a potential Emergency action. Following a review of the details and known risks, the Security Council decided to execute the upgrade and it was completed at 11:30 EST on 2nd October 2026.\nThis report provides an overview of the risks that required the Security Council Action:\n\nAdd a permissionless guard for the One-Step Proof of BoLD on Arbitrum One\n\nTemporarily pause activation of new Stylus contracts on Arbitrum One & Nova\n\nKey point: To date, known bugs for Stylus primarily impact chain liveness (e.g., denial of service attacks) and do not put any user funds at risk.\nWhy was this action taken\nLet’s take this opportunity to explain why action was taken on two separate issues concerning BoLD and Stylus.\nInstalling the guard for One-Step Proof of BoLD. Given the rise of AI-assisted attacks, we have implemented a precautionary approach that allows anyone to pause settlement of Arbitrum One on Ethereum if there are at least two conflicting answers that pass at the same level in which only one should be valid and pass. This is to halt a class of publicly verifiable and detectable attacks that exploit a bug in the one-step proof. If halted, Arbitrum One will continue to process as normal except that messages from Arbitrum One to Ethereum, such as withdrawals, that are not yet confirmed will have to wait. This provides time for the Security Council to deploy a fix for the bug and resume the rollup.\nPreventing activation of new Stylus contracts. AI-assisted tooling has led to an increasing number of sophisticated attacks on hand-crafted WASM programs that do not use the standard Stylus compiler toolchain. These programs are specifically designed to cause unexpected behaviors such as degrading the chain’s performance for all other users. To date, no attacks have been discovered that permits theft of user funds.\nNew ArbOS releases have patched several reported bugs and known attacks over the past few months, but out of an abundance of caution, we have decided to temporarily pause new activations of Stylus contracts. This was executed as an emergency action to prevent the deployment of new hand-crafted WASM programs that are not yet patched by the current version of ArbOS on the Arbitrum network.\nThe Arbitrum Foundation has informed the Security Council that they will work with the ArbitrumDAO to discuss next steps on the timeline and manner for enabling activation of new Stylus contracts. The Arbitrum community remains confident in the value of Stylus and want to preserve these use cases while taking preventative measures against Stylus-based attack vectors as AI-assisted attack tooling continues to evolve.\nImpact on builders and users\n\nNo new activations. New Stylus contracts cannot be activated during the pause including new versions of existing applications that require activation.\n\nExisting contracts are not paused. Already-active Stylus contracts continue to execute until expiration. This pause does not deactivate them.\n\nThe ArbOS 61 upgrade renewed all active contracts on Arbitrum One, so no currently active contract expires before August 20, 2027.\n\nRenewal via keepalive stays permissionless and is unaffected by the pause.\n\nReactivating an expired contract, or one that needs to be updated after a Stylus version change, is paused.\n\nUsing/calling any activated Stylus contract stays permissionless for all users and developers.\n\nNo impact on EVM. Solidity (EVM) contract deployment and execution are unaffected by this Security Council action.\n\nSecurity Council Actions\nThere are two actions bundled into a single payload:\n\nOne-Step Proof Guard. The L1UpgradeExecutor gives a new pause contract (PauseExecutor) the ability to pause and nothing else. The new pause contract grants the guard (OspSoundnessGuard) PAUSER_ROLE to use it. Anyone can show the guard two conflicting answers to the same step of an open challenge. If the one-step proof accepts both, the guard has the pause contract put Arbitrum One’s settlement to Ethereum on hold.\n\nStylus deactivation. The Security Council called ArbOwner.setWasmActivationGas(2^64 - 1) to raise the Stylus activation gas requirement on Arbitrum One and Nova. This makes activation prohibitively expensive and effectively disables new activations. This is a configuration change and does not require an ArbOS upgrade.\n\nThe Security Council signed the following transactions to update the configuration:\n\nEthereum: Ethereum Transaction Hash: 0x30732bb7d2... | Etherscan\nArbitrum One:\nArbitrum One Transaction Hash: 0x9eb3a4be3b... | Arbitrum One\nArbitrum Nova:\nArbitrum Nova transaction 0x79e0fed470dff7a22059b108e3f8f42eddd2b580a6771594060c4e7326c5f984 | Blockscout\n\nAn external audit was conducted for the OSP Guard contracts. No audit is required for the Stylus deactivation as it is only updating a single parameter in the ArbOS configuration.\n\n [ANGLE PROTOCOL] [FINAL] [STIP - Round 1] \n\n ArchiveShort Term Incentives Program (STIP) Round 1\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Sep 2023\n\n 1 / 26\n\n Sep 2023\n\n Jan 2024\n\n post by Mariam on Sep 26, 2023\n\n Mariam\n\n This is an updated proposal following comments received below in respect of the initial draft.\nApplicant Name: Mariam Kouanda\nProject Name: Angle Protocol\nProject Description: Angle Protocol is a Defi protocol that launched:\n\nagEUR, the most liquid Euro stablecoin;\nstEUR, a staked agEUR paying a yield coming from RWAs held in Angle’s reserves and protocol fees (newly launched on 25 September 2023); and\nMerkl, a smart incentivization system for concentrated liquidity used by major Arbitrum DEXes.\n\nTeam Members and Qualifications:\nPablo Veyrat - Cofounder of Angle\nGuillaume Nervo - Cofounder of Angle\nPicodes - Cofounder of Angle\nMariam Kouanda - Head of growth at Angle\nProject Links:\n\nWebsite - https://www.angle.money/\nDocumentation Portal - Angle Documentation Portal | Angle Docs\nGithub - Angle · GitHub\nAudits - Audits | Angle Docs\nTwitter - https://twitter.com/AngleProtocol\nAnalytics and Balance Sheet - Angle Analytics\n\nContact Information\nTG: @MariamKd\nTwitter: https://twitter.com/TheBlockAdopter\nEmail: mariam.k@angle.money\nDo You Acknowledge That Your Team Will Be Subject to a KYC Requirement?: Yes\nSECTION 2: GRANT INFORMATION\nRequested Grant Size: Between 200,000 $ARB and 700,000 $ARB, to be released according to milestones (see grant timeline below with milestones included).\nGrant Matching: Yes. Native yield in agEUR will distributed from Angle Protocol’s profits and reserves, currently 4% APY on stEUR.\nGrant Breakdown:\nAs a reminder, stEUR is a staked agEUR paying a fixed 4% APY coming from RWAs held in Angle’s reserves and protocol fees.\nThe grant will be distributed to (see grant timeline below for milestones):\n\nincentivize a stEUR/USDC Camelot v3 pool from 1 November 2023 to 31 January 2024 with up to 250,000 $ARB;\nincentivize a stEUR/ARB Camelot v3 pool from 1 November 2023 to 31 January 2024 with up to 250,000 $ARB;\nincentivize a stEUR/wstETH Camelot v3 pool from 1 November 2023 to 31 January 2024 with up to 100,000 $ARB;\nincentivize the use of stEUR as collateral to borrow USDC on a native lending protocol (Radiant) with 100,000 $ARB (to be unlocked only if the integration is secured prior to December 15, 2023);\n\nIf this grant request is approved, Angle will immediately:\n(1) deploy stEUR and native agEUR staking on Arbitrum in order to create the first RWAs and Euro based savings rate on Arbitrum;\n(2) add $ARB as a token to mint agEUR natively on Arbitrum;\n(3) work on use cases and integration for stEUR in order to push this program beyond liquidity incentivization (e.g. lending, yield tokenization etc.).\nThe grant will not be used for development costs, only for supporting the development of stEUR on Arbitrum, promoting RWAs in the ecosytem, enabling integrations across the ecosystem and its pairing with $ARB and $wstETH.\nFunding Address: 0xAA2DaCCAb539649D1839772C625108674154df0B\nFunding Address Characteristics: 4/6 Safe multisig composed on Angle core team members and ecosystem participants. More details on the multisig composition here.\nContract Address: Incentivization will go through Merkl, the incentivization tool built by Angle Labs, that enabled concentrated liquidity incentivization. Merkl related contract addresses can be found here.\nSECTION 3: GRANT OBJECTIVES AND EXECUTION\nObjectives: The objectives are:\n\nLaunch the first RWA and Euro-based yield source on any L2 with stEUR and bring the first savings rate to Arbitrum\nCreate deep Euro liquidity on Arbitrum with stEUR and so indirectly with agEUR\nUse the development of stEUR on Arbitrum to support $ARB volume and liquidity with a stEUR/ARB pool\nFurther support the use of $ARB by enabling agEUR minting with $ARB\nUse the development of stEUR on Arbitrum to support $ETH volume and liquidity with a stEUR/wstETH pool\nFurther the use of RWAs-related assets on Arbitrum and taking this program beyond liquidity incentivization by supporting the use of stEUR as collateral on a lending protocol and promoting other use cases\n\nKey Performance Indicators (KPIs):\n\nAngle TVL on Arbitrum\nNumber of circulating stEUR on Arbitrum\nPercentage of stEUR natively staked on Arbitrum and portion of Angle revenue distributed on Arbitrum (breakdown between Ethereum and Arbitrum)\n$ARB volume and liquidity relating to the stEUR/ARB pool to be set up\n$wstETH volume and liquidity relating to the stEUR/wstETH pool to be set up\n\nHow will receiving a grant enable you to foster growth or innovation within the Arbitrum ecosystem?:\nThis is an opportunity to provide all Defi users on Arbitrum (and not only Euro inclined ones) with:\n\na simple and real yield coming from RWAs;\na state of the art application of RWAs in the space;\ncomposability opportunities with enabling borrowing with stEUR and other use cases.\n\nThis grant would make Arbitrum the home of the first Euro and RWA based yield source and the most cost effective option to benefit from that opportunity. Arbitrum would be the first L2 to provide and support such an opportunity with stEUR (staked agEUR).\nAs mentioned, this will incidentally grow Euro liquidity on Arbitrum giving it a and boost in terms of stablecoins’ and currency’s diversity in the Defi ecosystem.\nJustification for the size of the grant:\nagEUR and the Angle Borrowing module have been deployed on Arbitrum since July 2022 to allow native minting of agEUR on the chain.\nAll these products have undergone audits and development work. This includes significant developement work made by Angle to allow a 1-click leverage from on Curve pools on Arbitrum in the Angle borrowing module.\nAngle has been active in the Arbitrum ecosystem, in particular through its Merkl product, the smart incentivization tool that is today used by Uniswap to distribute close to 2M ARB to increase volume and liquidity in several pools but also by DEXes such as Sushiswap and Camelot. Working with these partners have required bespoke integrations and smart contract work to cater to the development of liquidity and volume on Arbitrum for these DEXes.\nstEUR is a new product that enables value-sharing by streaming protocol revenue to agEUR stakers.\nThis grant will:\n\nsupport the further adoption on Arbitrum of all the above mentioned products (agEUR, agEUR borrowing using $ARB, stEUR and Merkl);\nthe sizing and duration will allow a compelling support RWAs-related opportunities on Arbitrum;\nthe sizing and duration will allow the development of a stEUR liquidity to develop use cases for it apart from LPeing in pools (use stEUR as collateral, integration in yield-related products like Pendle etc.);\nsupport both $ARB and $ETH liquidity and volume.\n\nThe grant is requested to migrate stEUR stakers to Arbitrum and incidentally support $ARB and $ETH in order to unlock a total TVL in the above-mentioned pools of $14+ millions in total, including, approximately €7m worth of stEUR on Arbitrum (see the grant timeline with milestones below).\nExecution Strategy:\nUse of Merkl to incentivize on Camelot v3\nThe pools to be set up are concentrated liquidity pools on Camelot.\nIncentivizing concentrated liquidity is initially difficult to implement. To do so, Angle will use Merkl, the tool developed by Angle Labs.\nThis tool is already in use since 2022 and trusted by several concentrated liquidity DEXes and projects to incentivize concentrated liquidity including Uniswap, Camelot, Sushiswap, Retro and others.\nFees do not apply when Merkl is used to incentivize agEUR and stEUR pools. This means the the use of Merkl will not incur any fees charged to the benefit of Angle Labs.\nIncentivization of the pools for a maximum total of 600,000 $ARB (see grant timeline for milestones)\nIf found are allocated to Angle to develop the stEUR while boosting the use of ARB and ETH on Arbitrum, we will immeditaly set up the three following pools:\n\nCamelot v3 stEUR/ARB\nCamelot v3 stEUR/wstETH\nCamelot v3 stEUR/USDC\n\nIncentivization for the use of stEUR as collateral on Radiant for a total of 100,000 $ARB (see grant timeline for milestones)\nUpon incentivization of the above-mentioned pools and development deep liquidity for stEUR on Arbitrum, the Angle team shall seek the listing of stEUR as collateral on Radiant as a native Arbitrum lending protocol and incentivize this use case.\nThis integration shall be worked on by the Angle team and the selected lending protocol prior to December 15, 2023 to unlock this portion of the grant.\nGrant Timeline:\n\nThe grant shall be awarded in three monthly tranches according to milestone as mentioned in the tables below.\nIf after the first month less than 75% of the global stEUR targets is reached, the program shall be stopped. Above 75%, the program shall continue over the second month.\nIf after the second month, less that 75% of the second month stEUR global target is reached, the program shall be stopped. Above 75%, the program shall continue over the third month.\n\nFirst month - 1 November 2023 to 30 November 2023\n\nDeployment of stEUR on Arbitrum\nEnabling of native staking of agEUR on Arbitrum\nEnabling agEUR borrowing with $ARB\nIncentivization on stEUR pools as follow\n\nPools\nDistributed $ARB\nMilestone Goal in TVL in the pool\n\nCamelot v3 stEUR/ARB\n83,333\n$1.4m\n\nCamelot v3 stEUR/wstETH\n33,334\n$1.3m\n\nCamelot v3 stEUR/USDC\n83,333\n$4m\n\nGlobal\n200,000\n$6.7m\n\nSecond month - 1 December 2023 to 31 December 2023\n\nAssessment of the first month stEUR global target and continuation if >75%\n\nPools\nDistributed $ARB\nMilestone Goal in TVL in the pool\n\nCamelot v3 stEUR/ARB\n83,333\n$1.5m\n\nCamelot v3 stEUR/wstETH\n33,334\n$1.4m\n\nCamelot v3 stEUR/USDC\n83,333\n$4.25m\n\nGlobal\n200,000\n$7.15m\n\nThird month - 1 January 2024 to 31 January 2024\n\nAssessment of the second month stEUR global target and continuation if >75%\n\nPools/Lending\nDistributed $ARB\nMilestone Goal in TVL in the pool\n\nCamelot v3 stEUR/ARB\n83,333\n$1.7m\n\nCamelot v3 stEUR/wstETH\n33,334\n$1.5m\n\nCamelot v3 stEUR/USDC\n83,333\n$5m\n\nRadiant (native lending protocol)\n100,000\n$8m\n\nGlobal\n300,000\n$16.2m\n\nDo you accept the funding of your grant streamed linearly for the duration of your grant proposal, and that the multisig holds the power to halt your stream? Yes\nSECTION 4: PROTOCOL DETAILS\nIs the Protocol Native to Arbitrum?: Yes. Angle protocol was initilly deployed on Ethereum but deployed it borrowing module natively on Arbitrum. This allows the native minting of agEUR on the chain.\nOn what other networks is the protocol deployed?: agEUR is deployed on at least 12 chains. However the protocol in itself is deployed only on Ethereum, Arbitrum, Optimism, and Polygon.\nWhat date did you deploy on Arbitrum?: agEUR and Angle Borrowing module were deployed on Arbitrum in July 2022.\nProtocol Performance:\nAs at 27 September 2023, Angle Protocol has a global TVL of $27m and agEUR has 581.k holders.\nAngle has newly launched the stEUR on 25 September 2023 at 5pm CET. Currently, 48 hours hours after launch, $3m worth of agEUR have been staked for stEUR.\nScreenshot 2023-09-27 at 15.49.402148×460 46.3 KB\nAs at 27 September 2023, Angle has $1m TVL on Arbitrum.\nThe potential deployement of stEUR on Arbitrum is a first of a kind, simple and useful usage on which the Angle can rely on to grow further on Arbitrum while supporting RWAs use cases and ARB on the chain.\nScreenshot 2023-09-27 at 15.51.502106×822 104 KB\nWith its tool Merkl, Angle Labs helps to power more liquidity and volume on concentrated liquidity pools across DEXes such as Uniswap, Camelot, Sushiswap etc.\nScreenshot 2023-09-25 at 18.57.342822×1406 411 KB\nThe protocol is also focused on providing transparency and making protocols’ reserves and financials accessible and readable by all.\nAngle has built and maintains an analytics showing the protocol balance-sheet, reserves and TVL progression in real time. The goal is to add more details useful to all participants including a soon to come event page that will detail all events by chain. This will also allow tracking of performance on Arbitrum.\nProtocol Roadmap:\nAngle newly deployed stEUR on 25 September 2023 (i.e. just 1 day prior to the posting of this proposal). The protocol future roadmap consists in:\n\nre-enforcing the diversification and resilience of the protocol’s reserves by exploring additional collaterals, including yield-producing collaterals;\nimplementing a fully on-chain governance, it being noted that the on-chain governance will allow voting on both Ethereum and Arbitrum;\nFurthering the integrations for the newly launched stEUR;\nDelivering more details in the analytics of the protocol that provide all details to stakeholders on the financial state of the protocol.\n\nAudit History:\nThe protocol has been audited:\n\n1 time by Code4rena\n3 times by ChainSecurity\n1 time by Sigma Prime\n\nNo critical findings remained unresolved. Audits are available here.\nSECTION 5: Data and Reporting\nIs your team prepared to create Dune Dashboards for your incentive program?: Yes or another dashboard providing a similar level of information.\nDoes your team agree to provide bi-weekly program updates on the Arbitrum Forum thread?\nAngle analytics is publicly available.\nIt will allow anyone at all times to see agEUR minted on Arbitrum but also agEUR staked on Arbitrum (stEUR). In addition, I (Mariam) or Pablo (Angle’s Cofounder) will be able to provide bi-weekly program updates.\nDoes your team acknowledge that failure to comply with any of the above requests can result in the halting of the program’s funding stream?: Yes\n\n Short-Term Incentive Grants Pitching Sessions\n\n 5\n\n 2\n\n 2\n\n 2\n\n 2\n\n read \n\n 10\n min\n\n post by meyaf320219 on Sep 26, 2023\n\n meyaf320219\n\n Up to 1.1m ARB to incentivise the liquidity of a single token is really quite hard to compherend.\nWhilst I appreciate the work you are doing with stEUR/agEUR, it really is hard to justify such a large amount for a non-native protocol and on just one single token.\nWhy does the proposal not take into account any other Arbitrum protocols? Uniswap and a “lending protocol” is disappointing when the entire purpose of this framework is to incentivise Arbitrum builders.\nThis proposal is a large cost to the DAO that almost entirely generates value just for Angle.\nPlease could you also detail the incentives and liquidity you have achieved so far for this token? Thanks\n\n post by Mariam on Sep 26, 2023\n\n Mariam\n\n Hi meyaf320219,\nThanks a lot for your feedback.\nPlease see answers below. Going from there we’re happy to incorporate feedbacks to improve the proposal.\nScope and value of the program for Arbitrum\n\nSupporting the adoption of the first savings rate on Arbitrum and any L2\nGiving access to a fixed 4% Euro-based real yield to Arbitrum users\nincentivizing ARB, USDC, wstETH along with stEUR\nCreating the base for composability opportunities with a RWA-related asset (i.e. stEUR liquidity)\n\nAmount requested\nThe initial amount requested is 333,334 ARB with potential extensions.\nThe proposal suggest the release of a second tranche of the grant only if a $9m TVL (75% of the target) is achieved across the 3 pools incentivized after 1 month.\nThe same logic applies for any extension of the grant from the 2nd month to the 3rd.\nHappy to hear improvements suggestion on that part.\nInclusion of other Arbitrum builders\n\nThis proposal include further building on Arbitrum on Angle’s part including adding $ARB as collateral to mint agEUR\nThe initial proposal is to use of the most popular DEX on Arbitrum by TVL and volume (i.e. Uniswap v3) to host the incentivized pools → we are very happy to hear any suggestion from you or any other stakeholders on the alternative they would like to see\nComposability of a RWA-based asset in Defi starting with using stEUR as collateral in lending → this bit and many other uses of this opportunity by Arbitrum builders is conditional to the presence of enough stEUR liquidity on the chain. And the portion of the grant relating to integrating stEUR as a lending collateral would not be used if there is no integration to incentivize.\n\nAdding here again that we’re open to suggestions to improve the proposal, if any.\nMore information on the savings rate and stEUR\nagEUR staking and stEUR have been deployed 24 hours ago on Ethereum Mainnet.\nIt has never been incentivized and there are currently 2.4m stEUR from users who started using the contract to benefit from the savings rate.\nPlease let us know your thoughts on the above as well as your suggestions if any!\n\n Treasure Delegate Communication Thread\n\n [ FINAL] ANGLE STIP Bridge Addendum\n\n post by Matt_StableLab on Sep 26, 2023\n\n Matt_StableLab\n\n Hello @Mariam thank you for your application! Your submission meets all requirements to be considered for a snapshot vote.\n\n post by peter on Sep 26, 2023\n\n peter\n\n Hi Mariam,\nThanks for the proposal.\nThe Arbitrum Incentive exists primarily to nurture the Arbitrum ecosystem, including builders and users. It’s a win-win cooperation program, as evidenced by the sentiment across the forum.\nI agree with @meyaf320219 mentioning that this proposal only focuses on stEUR liquidity on Uniswap, which is not Arbitrum native and leverages stEUR through minting and lending. Although stEUR is a protocol great forward as the first Euro RWAs yield-bearing asset, it’s a still new product that just has launched and has not been proven its liveness on mainnet, where the protocol focuses on and starts with.\nHowever, Angle Protocol and Merkl are both good products. Angle Lab is a great team with their commitment, talent, and transparency. They are real builders in this space and deserve an Arbitrum grant to grow the first Euro RWAs native yield-bearing assets, which will bring many benefits when it can interact with many users with cheap transactions as Arbitrum offers.\nI suggest that Angle Lab adjust the requested amount to be more reasonable and use native Arbitrum DEXs and money markets as their liquidity and leverage solutions for stEUR.\nI hope this feedback is helpful.\n\n post by Perl on Sep 26, 2023\n\n Perl\n\n I wouldn’t change a word of this post. I’m sure this proposal could, and imho should, pass with the suggested improvements.\n\n post by Mariam on Sep 27, 2023\n\n Mariam\n\n peter\n\n @peter @Perl @meyaf320219 @Matt_StableLab and all reading this post - Please see above a revised version of the draft proposal to (1) include native Arbitrum protocols to the execution and (2) revise the size of the request.\nAlso updated the protocol figures as the number of staked agEUR grew!\nThanks a lot for chiming in, i’ll be reading further comments!\n\n post by meyaf320219 on Sep 28, 2023\n\n meyaf320219\n\n this is great, the amount seems much more reasonable\n\n post by thecryptostakr on Sep 28, 2023\n\n thecryptostakr\n\n Hello @Mariam, thank you for choosing Arbitrum to implement this project.\nThese are my reasons for supporting the Angle Protocol proposal:\n\nGreat team, pragmatic with good vision about the fusion between DeFi and RWA assets;\nAngle Protocol is a completely transparent protocol (something unique in DeFi), providing a platform (https://facts.angle.money/) for consulting transactions, treasury, liquidity composition, etc.;\nLaunched the most liquid euro stablecoin on the market: agEUR;\nagEUR is the only yield bearing euro stablecoin;\nThe project states “native minting” of stEUR, therefore it means that this project implies native involvement in Arbitrum DeFi;\nArbitrum’s investment in this project and others like it contributes to the consolidation of Arbitrum as the Ethereum L2 DeFi hub, and the competition to be this DeFi hub is becoming very strong and aggressive. The first movers, with quality investments, are those who will be able to gain market share;\nThis project presented by Angle Protocol is a great opportunity for small crypto investors (European or non-European) to access a fantastic DeFi product (euro yield stablecoin), contributing to the expansion of the Arbitrum platform’s user base, as well as to the increased liquidity on this platform;\nI can say that, as a small investor in DeFi (and a European one), I am looking forward to this product being made available on a Layer 2 so that it is viable for me to make an investment. And I sincerely hope that this layer 2 is Arbitrum, the Ethereum L2 DeFi hub;\nTo conclude, investing in this project means much more than supporting a product (stEUR), it means bringing greater liquidity and the integration of RWA assets into DeFi across Arbitrum DeFi.\n\nPS:\n\nThrough the amended proposal, the amount of support requested has already been adjusted and a change in the implementation of the liquidity pools to a native protocol (Camelot) has been proposed;\nAs a holder of $ARB tokens, this amended proposal has my full support.\n\n post by abeltherebel on Sep 28, 2023\n\n abeltherebel\n\n Really respect the flexibility here, turning community feedback into action like this is a great sign of accountability. 100% in favor of the proposal.\n\n post by strategicreserve on Oct 1, 2023\n\n strategicreserve\n\n As a long-term partner of Angle, Gamma knows how intelligent and professional the Angle team is. We have enjoyed working with the team on their EUR products and with Angle Merkl. Angle is a team you want to have a presence on Arbitrum. We hope the delegates approve this proposal.\n\n post by Matt_StableLab on Oct 3, 2023\n\n Matt_StableLab\n\n Hello @Mariam ,\nNow that your application has been marked eligible, please be advised of the remaining steps in the application process to be completed prior to the Review Period Deadline:\n\nPlease complete the following steps required for your application to proceed to Snapshot:\n\nTo change your proposal to final, please tag an Arbitrum Foundation Forum Moderator (@ stonecoldpat @ cliffton.eth @ eli_defi) by the Review Period deadline to notify them of your proposal’s readiness to proceed from [Draft] to [Final] status.\nOnce notified, the Arbitrum Foundation Forum Moderator will adjust your title from [Draft] to [Final] status. Once marked as [FInal], your application post will be locked by moderators and you will no longer be able to edit your proposal.\n\n post by Mariam on Oct 4, 2023\n\n Mariam\n\n Hi @Matt_StableLab @stonecoldpat, @cliffton.eth and @eli_defi,\nWe would like to confirm that our application is ready be marked as [FINAL]. Please kindly change the title accordingly.\nThank you!\n\n post by cliffton.eth on Oct 4, 2023\n\n cliffton.eth\n\n Post has been marked FINAL and locked.\n\n post by litocoen on Oct 5, 2023\n\n litocoen\n\n The Angle team has really impressed me throughout this bear market continuously continuing to build new products as well as many public goods used in the Arbitrum ecosystem such as Merkl.\nI also think that building liquidity for a Euro stablecoin is beneficial to Arbitrum - as well as experimenting with RWA’s and the yield it will produce for stEUR holders.\nYou have my support!\n\n post by EynSoph on Oct 7, 2023\n\n EynSoph\n\n RWAs are big narrative in the space and I love how Angle is also helping drive that. If you’d like to do more with EUR, this is it. Happy to support their proposal and their endeavours on Arbitrum.\n\n post by WintermuteGovernance on Oct 9, 2023\n\n WintermuteGovernance\n\n Angle Protocol has contributed to the diversity of the DeFi ecosystem with the EUR based stablecoin and advanced liquidity mining efforts through Merkl. The outlined grant objectives align with the goals of the STIP and target collaboration between Arbitrum-native protocols. Furthermore, Angles focus on driving adoption of stEUR will provide important data and insights into the demand for RWAs on Arbitrum.\nWe look forward to supporting Angle Protocol’s grant application!\nAngle Protocol Summary Stats:\n\nLargest EUR stablecoin by DEX trading volume market share since May 2022 - 64.4% in September\n4th largest EUR stablecoin by Market Cap & largest decentralized stablecoin - $20M\n\nimage2409×750 136 KB\nSource: Dune, DefiLlama.\nDisclaimer: Wintermute is an investor in Angle Protocol\n\n post by SEEDGov on Oct 10, 2023\n\n SEEDGov\n\n Angle Protocol: @Mariam\nFrom @Seedgov led by the @cattin delegation, we want to convey our support to this proposal. The reasons why we agree are as follows:\n\nApplication size tied to milestones. Being the largest decentralized Euro Stablecoin in the ecosystem, they have described a number of interesting actions for the Arbitrum ecosystem; the implementation of STEUR, and the subsequent liquidity incentive in Camelot, may bring new interest to Arbitrum; the listing of ARB as asset collateral, will give it an interesting use that avoids the sell\n\nWe want to clarify that this is not the final vote, since as we clarify in this release, the final vote is defined by our community. We also want to invite you to attend our Governance Call that will be held tomorrow in our discord .\n\n SEED Latam Delegate Communication Thread\n\n post by Mariam on Oct 10, 2023\n\n Mariam\n\n Thank you to everyone here that has commented this proposal for improvements and support.\nIt’s particularly great to see Angle community members, users and delegates spontaneously providing feedback and the thoughts behind their support for this proposal. Thank you for your work, time and commitment to governance and new Defi development.\n@SEEDGov I would be glad to attend your governance call on behalf of Angle. Reaching out to arrange details!\n\n post by SEEDGov on Oct 10, 2023\n\n SEEDGov\n\n For more details you can see this post we made\n\n Load more posts below","tokens":7622,"squid":"spider-07","role":"Council Spider","at":1791345378333,"hash":"440ead47b1a1514c230b6aa7d7a9e4b32df319a7"}
{"url":"https://forum.across.to/t/build-liquidity-for-acx-on-velodrome/1643/1","domain":"forum.across.to","title":"Build liquidity for $ACX on Velodrome - Proposals / Active Proposals - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n Build liquidity for $ACX on Velodrome \n\n ProposalsActive Proposals\n\n treasury-funding\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n May 2023\n\n 1 / 9\n\n May 2023\n\n Jul 2023\n\n post by Methodic on May 21, 2023\n\n Methodic\n\n Related Discussions:\n\nSummary:\nCurrently, Across Protocol’s $ACX has little liquidity on Layer 2s, limiting the ability for users to acquire $ACX with low slippage and provide liquidity on L2s. This proposal aims to bootstrap $ACX liquidity on Velodrome and establish a meaningful presence for Across Protocol in the Optimism ecosystem.\nMotivation:\nL2 adoption has gained significant momentum over the past 12 months and is expected to continue as more users flock to ecosystems that inherit Ethereum’s security, while offering significantly cheaper fees and faster transaction times.\n\nL2 majors (Optimism & Arbitrum) alone have seen a net inflow of ~$4.3B by over 983,000 wallets and L2 users represent ~30% of all Ethereum users (compared to ~4.5% in July 2022).\nUsers also benefit from a better experience on L2s, saving about 95% in transaction fees compared to Ethereum mainnet with the average number of daily transactions on L2 majors having increased by about 7x since July 2022.\n\nAs a core cross-chain bridge, Across Protocol stands to grow alongside Layer 2s. Building a strong presence for $ACX on Optimism will give Across Protocol further exposure to the ecosystem and improve the user experience for those looking to buy or provide liquidity for $ACX.\nUpon successful completion of the pilot, Across will also benefit from receiving a veAERO airdrop to direct $AERO emissions and incentivize liquidity on Coinbase’s upcoming L2 chain, Base 2.\nSpecification & Implementation:\nOn Velodrome, $VELO emissions are directed to liquidity pools based on votes by veVELO (vote-escrow VELO) holders. Protocols such as Across can use veVELO or voter incentives (bribes) to attract votes and emissions for their liquidity pairs.\nProtocols bribing on Velodrome often receive $2-$3 in $VELO for every $1 they deposit. Major DeFi protocols such as Lido, Synthetix and Stargate leverage Velodrome’s mechanics to maintain deep liquidity on Optimism in a capital-efficient way.\nAcross will implement a 10 week pilot program using 750k $ACX tokens. The protocol will bribe the ACX/WETH liquidity pool on Velodrome at a rate of 75k $ACX per week. Velodrome also offers to match at least 5% of Across Protocol’s bribes each week with $OP tokens. Once an epoch is completed on Wednesday at 23:59 UTC, VELO emissions will begin to flow to Across Protocols’ LP.\nSimilar protocols typically attract 2-3x the value of their bribes in $VELO emissions. 75k $ACX tokens at current prices are worth about $3.5K; which Velodrome would complement with a minimum 5% bribe match, resulting in ~$9K of $VELO emissions going to the ACX pool at current rates. Using Aura’s $ACX/wstETH pool as reference which has an APR of 36% and ~820k in TVL, Velodrome could attract upwards of $1.3M TVL ($9K * 52 weeks / 36%). In other words, Across could achieve a ~50% growth in TVL on Velodrome for the same cost, while getting exposure to the Optimism community and a potentially new holder base.\nProtocol Owned Liquidity (POL)\nIf available, Across Protocol can also deposit Protocol Owned Liquidity (POL) to capture and farm a portion of $VELO rewards that are streamed to its pool. Across can lock all $VELO farmed as veVELO, allowing it to build a voting position that will direct additional emissions in perpetuity, while generating fee rewards, bribe rebates, and bonuses for locking. Any rewards generated by these locks can be compounded further into veVELO to grow protocol owned votepower and reduce reliance on voter incentives over time.\nLocking veVELO is an attractive strategy for protocols as it reduces net cost of incentive programs through a Lock Bonus airdrop, typically worth 10% of the $VELO locked, paid in OP. In addition, protocols with veVELO votepower will be eligible for the upcoming Aerodrome veAERO airdrop, which will enable protocols to bootstrap TVL for their tokens on Coinbase’s L2, Base and gain exposure to Coinbase’s 110m+ users and 80bn+ TVL.\nRationale:\nVelodrome is the single largest protocol on Optimism and the largest DEX on Layer 2 Ethereum with ~250M TVL. Velodrome’s governance community is one of the most active and diverse in crypto, with 14,300 veVELO holders participating in Velodrome’s weekly voting epochs.\nIncentivizing liquidity on Velodrome will naturally boost exposure for Across Protocol, as veVELO voters and Liquidity Providers will find $ACX near the top of the voting and LP pages respectively.\nVelodrome will also actively support Across Protocol’s marketing initiatives during the pilot program which means the community will not only benefit from having the option to provide liquidity and trade $ACX but also generate demand towards Across Protocol’s bridge services.\nDownsides:\nLiquidity incentives on Optimism can represent an additional expense for Across Protocol. However, this expense can be significantly reduced through Velodrome’s bribe-emissions multiplier and any potential VELO rewards and the other incentives described above.\nFurthermore, given this pilot program will run for 10 weeks, the DAO may use this time to assess results and decide on whether to continue or suspend its program on Velodrome after this period. At current prices, the total cost of the strategy to bootstrap liquidity via voter incentives without farming and locking $VELO emissions is about USD $35k (750k $ACX).\nVoting:\nYes - move forward with pilot program\nNo - do not move forward with program\nAbstain - no vote\n\n Discontinue ACX Bribes on Aura and Replace with Reward Locking in the Near Term\n\n post by eth-wei-trader on May 21, 2023\n\n eth-wei-trader\n\n Spending additional tokens with the ACX price so low and without clear KPIs is not advisable, IMO.\nIf we were to decide that we need more liquidity on L2 then we should move incentives from the L1 ACX bridge pool to L2, not increase inflation when the price is low.\n\n post by Everythingblockchain on May 24, 2023\n\n Everythingblockchain\n\n I believe the suggestion of moving to L2s is a valid one. However, it is important to take into account the potential impact on inflation and the current price of ACX, as previously highlighted. Perhaps it would be more suitable to revisit this proposal once market conditions have improved and the price has recovered.\n\n post by Saludiego201 on May 26, 2023\n\n Saludiego201\n\n Personally I would like to see this proposal in action, bedrock is just around the corner and it would be interesting to see this in action, facilitating interest for smaller investors like me.\n\n post by caesarsherrod.eth on Jun 1, 2023\n\n caesarsherrod.eth\n\n It is a great time to move into the layer 2 ecosystem in general. Personally, I am always biased to the Layer 2 Space. I would love to buy $ACX with low fees, which is only agreeable on L2.\nI just would like to know what the utility of having the token on the L2 would be? We would not be able to vote with these tokens. Adding them to the Velo Pools would likely have Velodrome being the only use case for $ACX on Optimism.\nI own several Governance Tokens on L2 for simply price exposure, rather than voting. If voting could be multi chain, I’d be bullish on this off the rip but I would like to know the pool would be used if we put it on L2.\nDefinitely need some $ACX on Optimism, Arbitrum & Polygon.\n\n post by roundmound on Jun 2, 2023\n\n roundmound\n\n There is already substantial sell pressure on $ACX, making it challenging to increase circulation further without a better understanding of whether the incremental liquidity will improve the supply/demand dynamic. Fostering L2 liquidity may very well expand the pool of buyers as a result of reduced gas costs, offsetting the 75k/week increase in supply, but it honestly just feels a bit like tail wagging the dog until there is actual utility for $ACX on the L2.\n\n post by PVMihalache on Jun 8, 2023\n\n PVMihalache\n\n It looks like a good proposal, that can bring growth to both projects. Yes… I want to see ACX on layer2!\n\n post by Alex_Goh on Jun 9, 2023\n\n Alex_Goh\n\n Great idea actually. Across already integrates well in Arbitrum but we need to gain presence in other layer 2s. Optimism will be a great next step.\n\n 1 month later\n\n post by alexander on Jul 22, 2023\n\n alexander\n\n eth-wei-trader\n\n The fact that ACX voting incentives would be earning the LPs 2x - 3x the rewards would mean any inflation would likely be offset by attracting additional LPs.\nLikewise, if those with ACX use an autocompunder you could potentially be creating multiples more in buying pressure.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n $ACX Liquidity - Update and Feedback Wanted\n\n Ideas & Feedback\n\n Ideas & Feedback\n\n 7\n\n Jun 2023\n\n Velodrome Liquidity Program Extension\n\n Active Proposals\n\n Active Proposals\n\n 19\n\n Jan 2024\n\n Across ($ACX) Community Initial Liquidity Proposal\n\n Passed Proposals\n\n Passed Proposals\n\n 49\n\n Nov 2022\n\n Tokenomics & Liquidity Incentives: Pair ACX w Across LP Tokens\n\n Ideas & Feedback\n\n liquidity\n\n Ideas & Feedback\n\n 2\n\n Aug 2023\n\n Reduce or Reallocate Across ACX LP emissions\n\n Ideas & Feedback\n\n liquidity\n\n Ideas & Feedback\n\n 2\n\n Sep 2023","tokens":3828,"squid":"spider-09","role":"Bridge Spider","at":1791345382003,"hash":"e28e73018833d03eb3a18a655c1575f5a806f0ba"}
{"url":"https://www.metaplex.com/docs/smart-contracts/core/plugins/freeze-delegate","domain":"metaplex.com","title":"Freeze Delegate Plugin | Metaplex Core","text":"The Freeze Delegate Plugin allows you to freeze Core Assets, blocking transfers and burns while the asset remains in the owner's wallet. Perfect for escrowless staking, marketplace listings, and game mechanics. What You'll LearnAdd the Freeze Delegate plugin to an AssetFreeze and thaw AssetsDelegate freeze authority to another addressUse cases: staking, listings, game lockingSummaryThe Freeze Delegate is an Owner Managed plugin that freezes Assets in place. When frozen, the Asset cannot be transferred or burned until thawed by the freeze authority.Freeze Assets without transferring to escrowDelegate freeze authority to a program or other walletAuthority is revoked on transfer (for non-permanent version)Use Permanent Freeze Delegate for irrevocable freezingOut of ScopeCollection-level freezing (use Asset-level only), permanent freezing (see Permanent Freeze Delegate), and Token Metadata freeze authority (different system).Quick StartJump to: Add Plugin · Delegate Authority · Freeze · ThawAdd the Freeze Delegate plugin: addPlugin(umi, { asset, plugin: { type: 'FreezeDelegate', data: { frozen: true } } })The Asset is now frozen and cannot be transferredThaw when ready: update the plugin with frozen: falseAuthority is revoked on transferWhen to Use Freeze vs Permanent FreezeUse CaseFreeze DelegatePermanent Freeze DelegateMarketplace listings✅ Best choice❌ OverkillEscrowless staking✅ Best choice✅ Also worksSoulbound tokens❌ Revokes on transfer✅ Best choiceCollection-wide freeze❌ Assets only✅ Supports CollectionsRental protocols✅ Best choice✅ Also worksChoose Freeze Delegate when authority should reset on ownership change.Choose Permanent Freeze Delegate when authority must persist forever.Common Use CasesEscrowless staking: Freeze NFTs while staked without transferring to escrowMarketplace listings: Lock NFTs for sale without escrow accountsGame item locking: Temporarily lock items during gameplayRental protocols: Lock NFTs while rented outGovernance: Lock tokens during voting periodsCollateral: Lock NFTs used as lending collateralTournaments: Lock NFTs during competition participationWorks WithMPL Core Asset✅MPL Core Collection❌For collection-level freezing, use Permanent Freeze Delegate instead.ArgumentsArgValuefrozenboolFunctionsAdd Freeze Delegate Plugin to an AssetThe addPlugin command adds the Freeze Delegate Plugin to an Asset. This plugin allows the Asset to be frozen, preventing transfers and burns.Adding a Freeze Plugin to an MPL Core Assetimport { publicKey } from '@metaplex-foundation/umi'\nimport { addPlugin } from '@metaplex-foundation/mpl-core'\nconst assetAddress = publicKey('11111111111111111111111111111111')\nawait addPlugin(umi, {\n asset: assetAddress,\n plugin: { type: 'FreezeDelegate', data: { frozen: true } },\n}).sendAndConfirm(umi)\nDelegate the Freeze AuthorityThe approvePluginAuthority command delegates the freeze authority to a different address. This allows another address to freeze and thaw the Asset while maintaining ownership.Delegate the Freeze Authorityimport { publicKey } from '@metaplex-foundation/umi'\nimport { approvePluginAuthority } from '@metaplex-foundation/mpl-core'\nconst asset = publicKey('11111111111111111111111111111111')\nconst delegateAddress = publicKey('22222222222222222222222222222222')\nawait approvePluginAuthority(umi, {\n asset: asset.publicKey,\n plugin: { type: 'FreezeDelegate' },\n newAuthority: { type: 'Address', address: delegateAddress },\n}).sendAndConfirm(umi)\nUpdating the Freeze Delegate PluginThe Freeze Delegate Plugin can be updated to change the frozen state of the asset. This is the same as using the Freezing an Asset and Thawing a Frozen Asset functions shown below.Freezing an AssetThe freezeAsset command freezes an Asset, preventing it from being transferred or burned. This is useful for escrowless staking or marketplace listings.Freeze an MPL Core Assetimport { publicKey } from '@metaplex-foundation/umi'\nimport { freezeAsset, fetchAsset } from '@metaplex-foundation/mpl-core'\nconst assetAddress = publicKey('11111111111111111111111111111111')\nconst assetAccount = await fetchAsset(umi, assetAddress)\nconst delegateSigner = generateSigner(umi)\nawait freezeAsset(umi, {\n asset: assetAccount,\n delegate: delegateSigner.publicKey,\n authority: delegateSigner,\n }).sendAndConfirm(umi)\nThawing a Frozen AssetThe thawAsset command unfreezes a frozen Asset, restoring its ability to be transferred and burned.Thaw an MPL Core Assetimport { publicKey } from '@metaplex-foundation/umi'\nimport { thawAsset, fetchAsset } from '@metaplex-foundation/mpl-core'\nconst assetAddress = publicKey('11111111111111111111111111111111')\nconst assetAccount = await fetchAsset(umi, assetAddress)\nconst delegateSigner = generateSigner(umi)\nawait thawAsset(umi, {\n asset: assetAccount,\n delegate: delegateSigner,\n}).sendAndConfirm(umi)\nCommon ErrorsAsset is frozenYou tried to transfer or burn a frozen Asset. The freeze authority must thaw it first.Authority mismatchOnly the freeze delegate authority can freeze/thaw the Asset. Check who has the plugin authority.Plugin not foundThe Asset doesn't have a Freeze Delegate plugin. Add it first with addPlugin.NotesOwner Managed: requires owner signature to addAuthority is automatically revoked when the Asset transfersFrozen Assets can still be updated (metadata changes allowed)Use Permanent Freeze Delegate if you need the authority to persist after transferFreezing is immediate - no confirmation periodQuick ReferenceFreeze StatesStateCan TransferCan BurnCan UpdateUnfrozenYesYesYesFrozenNoNoYesAuthority BehaviorEventAuthority ResultAsset transfersAuthority revokedPlugin removedAuthority goneThawAuthority retainedFAQCan I freeze an Asset I don't own?No. The Freeze Delegate is Owner Managed, so only the owner can add it. After adding, you can delegate authority to another address.What's the difference between Freeze Delegate and Permanent Freeze Delegate?Freeze Delegate authority is revoked on transfer. Permanent Freeze Delegate authority persists forever and can only be added at creation time.Can a frozen Asset be burned?No. Frozen Assets block both transfers and burns. Thaw the Asset first if you want to burn it.Can I freeze an entire Collection at once?Not with the regular Freeze Delegate (Assets only). Use Permanent Freeze Delegate on the Collection instead - it supports collection-level freezing and will freeze all Assets in that Collection at once. Note that Permanent Freeze Delegate can only be added at Collection creation time.Does freezing affect metadata updates?No. The Asset owner or update authority can still update metadata (name, URI) while frozen. Only transfers and burns are blocked.How do I implement escrowless staking?Add Freeze Delegate plugin with your staking program as authorityWhen user stakes: freeze the AssetWhen user unstakes: thaw the AssetThe NFT never leaves the user's walletRelated PluginsPermanent Freeze Delegate - Irrevocable freeze authority, supports CollectionsTransfer Delegate - Allow delegate to transfer AssetsBurn Delegate - Allow delegate to burn AssetsGlossaryTermDefinitionFreeze DelegateOwner Managed plugin that blocks transfers and burnsFrozenAsset state where transfers and burns are blockedThawUnfreezing an Asset to allow transfers againDelegate AuthorityThe account authorized to freeze/thaw the AssetEscrowlessStaking/listing without transferring to a holding accountOwner ManagedPlugin type requiring owner signature to add","tokens":1862,"squid":"dotcat","role":"Tooling Spider","at":1791345388365,"hash":"c3c7a78629f1549e53ee719ada68cef3b13e85a3"}
{"url":"https://forum.across.to/t/build-liquidity-for-acx-on-velodrome/1643/9","domain":"forum.across.to","title":"Build liquidity for $ACX on Velodrome - Proposals / Active Proposals - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n ProposalsActive Proposals\n\n treasury-funding\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n May 2023\n\n 9 / 9\n\n Jul 2023\n\n Jul 2023\n\n post by Methodic on May 21, 2023\n\n Methodic\n\n Related Discussions:\n\nSummary:\nCurrently, Across Protocol’s $ACX has little liquidity on Layer 2s, limiting the ability for users to acquire $ACX with low slippage and provide liquidity on L2s. This proposal aims to bootstrap $ACX liquidity on Velodrome and establish a meaningful presence for Across Protocol in the Optimism ecosystem.\nMotivation:\nL2 adoption has gained significant momentum over the past 12 months and is expected to continue as more users flock to ecosystems that inherit Ethereum’s security, while offering significantly cheaper fees and faster transaction times.\n\nL2 majors (Optimism & Arbitrum) alone have seen a net inflow of ~$4.3B by over 983,000 wallets and L2 users represent ~30% of all Ethereum users (compared to ~4.5% in July 2022).\nUsers also benefit from a better experience on L2s, saving about 95% in transaction fees compared to Ethereum mainnet with the average number of daily transactions on L2 majors having increased by about 7x since July 2022.\n\nAs a core cross-chain bridge, Across Protocol stands to grow alongside Layer 2s. Building a strong presence for $ACX on Optimism will give Across Protocol further exposure to the ecosystem and improve the user experience for those looking to buy or provide liquidity for $ACX.\nUpon successful completion of the pilot, Across will also benefit from receiving a veAERO airdrop to direct $AERO emissions and incentivize liquidity on Coinbase’s upcoming L2 chain, Base 2.\nSpecification & Implementation:\nOn Velodrome, $VELO emissions are directed to liquidity pools based on votes by veVELO (vote-escrow VELO) holders. Protocols such as Across can use veVELO or voter incentives (bribes) to attract votes and emissions for their liquidity pairs.\nProtocols bribing on Velodrome often receive $2-$3 in $VELO for every $1 they deposit. Major DeFi protocols such as Lido, Synthetix and Stargate leverage Velodrome’s mechanics to maintain deep liquidity on Optimism in a capital-efficient way.\nAcross will implement a 10 week pilot program using 750k $ACX tokens. The protocol will bribe the ACX/WETH liquidity pool on Velodrome at a rate of 75k $ACX per week. Velodrome also offers to match at least 5% of Across Protocol’s bribes each week with $OP tokens. Once an epoch is completed on Wednesday at 23:59 UTC, VELO emissions will begin to flow to Across Protocols’ LP.\nSimilar protocols typically attract 2-3x the value of their bribes in $VELO emissions. 75k $ACX tokens at current prices are worth about $3.5K; which Velodrome would complement with a minimum 5% bribe match, resulting in ~$9K of $VELO emissions going to the ACX pool at current rates. Using Aura’s $ACX/wstETH pool as reference which has an APR of 36% and ~820k in TVL, Velodrome could attract upwards of $1.3M TVL ($9K * 52 weeks / 36%). In other words, Across could achieve a ~50% growth in TVL on Velodrome for the same cost, while getting exposure to the Optimism community and a potentially new holder base.\nProtocol Owned Liquidity (POL)\nIf available, Across Protocol can also deposit Protocol Owned Liquidity (POL) to capture and farm a portion of $VELO rewards that are streamed to its pool. Across can lock all $VELO farmed as veVELO, allowing it to build a voting position that will direct additional emissions in perpetuity, while generating fee rewards, bribe rebates, and bonuses for locking. Any rewards generated by these locks can be compounded further into veVELO to grow protocol owned votepower and reduce reliance on voter incentives over time.\nLocking veVELO is an attractive strategy for protocols as it reduces net cost of incentive programs through a Lock Bonus airdrop, typically worth 10% of the $VELO locked, paid in OP. In addition, protocols with veVELO votepower will be eligible for the upcoming Aerodrome veAERO airdrop, which will enable protocols to bootstrap TVL for their tokens on Coinbase’s L2, Base and gain exposure to Coinbase’s 110m+ users and 80bn+ TVL.\nRationale:\nVelodrome is the single largest protocol on Optimism and the largest DEX on Layer 2 Ethereum with ~250M TVL. Velodrome’s governance community is one of the most active and diverse in crypto, with 14,300 veVELO holders participating in Velodrome’s weekly voting epochs.\nIncentivizing liquidity on Velodrome will naturally boost exposure for Across Protocol, as veVELO voters and Liquidity Providers will find $ACX near the top of the voting and LP pages respectively.\nVelodrome will also actively support Across Protocol’s marketing initiatives during the pilot program which means the community will not only benefit from having the option to provide liquidity and trade $ACX but also generate demand towards Across Protocol’s bridge services.\nDownsides:\nLiquidity incentives on Optimism can represent an additional expense for Across Protocol. However, this expense can be significantly reduced through Velodrome’s bribe-emissions multiplier and any potential VELO rewards and the other incentives described above.\nFurthermore, given this pilot program will run for 10 weeks, the DAO may use this time to assess results and decide on whether to continue or suspend its program on Velodrome after this period. At current prices, the total cost of the strategy to bootstrap liquidity via voter incentives without farming and locking $VELO emissions is about USD $35k (750k $ACX).\nVoting:\nYes - move forward with pilot program\nNo - do not move forward with program\nAbstain - no vote\n\n Discontinue ACX Bribes on Aura and Replace with Reward Locking in the Near Term\n\n post by eth-wei-trader on May 21, 2023\n\n eth-wei-trader\n\n Spending additional tokens with the ACX price so low and without clear KPIs is not advisable, IMO.\nIf we were to decide that we need more liquidity on L2 then we should move incentives from the L1 ACX bridge pool to L2, not increase inflation when the price is low.\n\n post by Everythingblockchain on May 24, 2023\n\n Everythingblockchain\n\n I believe the suggestion of moving to L2s is a valid one. However, it is important to take into account the potential impact on inflation and the current price of ACX, as previously highlighted. Perhaps it would be more suitable to revisit this proposal once market conditions have improved and the price has recovered.\n\n post by Saludiego201 on May 26, 2023\n\n Saludiego201\n\n Personally I would like to see this proposal in action, bedrock is just around the corner and it would be interesting to see this in action, facilitating interest for smaller investors like me.\n\n post by caesarsherrod.eth on Jun 1, 2023\n\n caesarsherrod.eth\n\n It is a great time to move into the layer 2 ecosystem in general. Personally, I am always biased to the Layer 2 Space. I would love to buy $ACX with low fees, which is only agreeable on L2.\nI just would like to know what the utility of having the token on the L2 would be? We would not be able to vote with these tokens. Adding them to the Velo Pools would likely have Velodrome being the only use case for $ACX on Optimism.\nI own several Governance Tokens on L2 for simply price exposure, rather than voting. If voting could be multi chain, I’d be bullish on this off the rip but I would like to know the pool would be used if we put it on L2.\nDefinitely need some $ACX on Optimism, Arbitrum & Polygon.\n\n post by roundmound on Jun 2, 2023\n\n roundmound\n\n There is already substantial sell pressure on $ACX, making it challenging to increase circulation further without a better understanding of whether the incremental liquidity will improve the supply/demand dynamic. Fostering L2 liquidity may very well expand the pool of buyers as a result of reduced gas costs, offsetting the 75k/week increase in supply, but it honestly just feels a bit like tail wagging the dog until there is actual utility for $ACX on the L2.\n\n post by PVMihalache on Jun 8, 2023\n\n PVMihalache\n\n It looks like a good proposal, that can bring growth to both projects. Yes… I want to see ACX on layer2!\n\n post by Alex_Goh on Jun 9, 2023\n\n Alex_Goh\n\n Great idea actually. Across already integrates well in Arbitrum but we need to gain presence in other layer 2s. Optimism will be a great next step.\n\n 1 month later\n\n post by alexander on Jul 22, 2023\n\n alexander\n\n eth-wei-trader\n\n The fact that ACX voting incentives would be earning the LPs 2x - 3x the rewards would mean any inflation would likely be offset by attracting additional LPs.\nLikewise, if those with ACX use an autocompunder you could potentially be creating multiples more in buying pressure.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n $ACX Liquidity - Update and Feedback Wanted\n\n Ideas & Feedback\n\n Ideas & Feedback\n\n 7\n\n Jun 2023\n\n Velodrome Liquidity Program Extension\n\n Active Proposals\n\n Active Proposals\n\n 19\n\n Jan 2024\n\n Across ($ACX) Community Initial Liquidity Proposal\n\n Passed Proposals\n\n Passed Proposals\n\n 49\n\n Nov 2022\n\n Tokenomics & Liquidity Incentives: Pair ACX w Across LP Tokens\n\n Ideas & Feedback\n\n liquidity\n\n Ideas & Feedback\n\n 2\n\n Aug 2023\n\n Reduce or Reallocate Across ACX LP emissions\n\n Ideas & Feedback\n\n liquidity\n\n Ideas & Feedback\n\n 2\n\n Sep 2023","tokens":3818,"squid":"spider-09","role":"Bridge Spider","at":1791345392348,"hash":"b020e9934399cbb93ef8ce0a7bc9bfa1c14e1815"}
{"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 →11.1 YrsUninterrupted uptime and liveness$115BTotal 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$115B+ in economic security distributed across geographies and client implementations makes Ethereum the most expensive smart contract platform to attack.Deep Liquidity$1.64B+ 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.5B 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":1087,"squid":"spider-05","role":"Spec Spider","at":1791345395199,"hash":"7b0f561564dea28b12728df1b0dcc5ae6dff5699"}
{"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":"spider-05","role":"Spec Spider","at":1791345406560,"hash":"69f1f913897f0cbb6c4d71f033530c180d60a3bd"}
{"url":"https://ethresear.ch/t/onchain-computation-proofs-for-evm/17804/1","domain":"ethresear.ch","title":"Onchain computation proofs for EVM - EVM - Ethereum Research","text":"Onchain computation proofs for EVM \n\n EVM\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Dec 2023\n\n 1 / 1\n\n Dec 2023\n\n Dec 2023\n\n post by alexeuler on Dec 13, 2023\n\n alexeuler\n\n Ethereum provides two main data/call types for external RPC users: current data from regular nodes and historical data from archival nodes. However, within a smart contract or the Ethereum Virtual Machine, access is restricted to only current data.\nThis post presents an algorithm that allows for the validation of historical call results for any smart contract on the Ethereum Virtual Machine. The algorithm enables smart contracts to retrospectively evaluate past execution outcomes, facilitating actions such as penalizing previous actions or inactions and reacting to events that happened but weren’t logged on the blockchain.\nContents\n\n1 Introduction\n\n2 Zero knowledge proofs for storage slots values\n\n2.1 Components of the Proof System\n\n2.2 Proof of Blockhash\n\n2.3 Proof of Storage\n\n2.4 Effectiveness for Proof of computation\n\n3 Onchain Computation Proofs\n\n3.1 Onchain EVM\n\n4 zkEVM Computation Proofs\n\n5 Use cases\n\n5.1 Decentralized Onchain Dutch Auctions\n\n5.2 Keeper Network\n\n6 Conclusion\n\n1 Introduction\nThe growth of Ethereum’s smart contract ecosystem has been impressive, driven by the idea of smart contracts working together. This allowed them to share data and make updates easily. This feature, called composability, helped decentralized applications on Ethereum expand quickly.\nBut there was a limitation. Smart contracts were capable of accessing only the most recent data on the blockchain, lacking the ability to retrieve historical information. To illustrate, if a contract needed the latest price information, it could make a call like this: Oracle.getPrice(\"USDC\", \"ETH\"), which would provide the current ETH/USDC price to the contract. Yet, it was impossible to specify a past block to obtain the price at that particular point in time. To fix this, Ethereum introduced the BLOCKHASH opcode, which in theory, let developers access past block data:\nScreenshot 2023-12-13 at 11.15.33946×262 13.1 KB\nBlockhash is a cryptographic hash of the entire Ethereum state at this block (see Table 1). This means you can prove the historical value for any storage slot in block number BN in two steps:\n\nProve that the blockhash of block BN equals the value BH.\n\nUsing BH, prove the value V for a storage slot SS.\n\nThe proof consists of two parts:\n\nThe block headers from the current block going back 256 blocks, up to block BN (or it may be empty if BN is in the most recent 256 blocks).\n\nThe Merkle-Patricia proof of the storage slot value with the State Root of block BN and the blockhash BH.\n\nSee Figure 1 for details. The proof verifier (a smart contract) will perform the following steps:\n\nRetrieve the blockhash of the block closest to block BN using the BLOCKHASH opcode.\n\nIf block BN is not among the recent 256 blocks, use the last available onchain blockhash (current - 256).\n\nFrom this block header, obtain the blockhash of the previous block.\n\nRepeat this process until the blockhash BH of block BN is proven.\n\nVerify the Merkle proof of the storage slot SS using blockhash BH.\n\nScreenshot 2023-12-13 at 11.16.531072×1334 118 KB\nThis is the most straightforward approach, enabling the proof of historical storage slot values. Utilizing solely this method, it is possible to implement historical oracles within smart contracts (as specified in this article). The only drawback of this approach is the gas costs. The proof of each storage slot results in approximately 400k gas consumption, which increases the further we look back into the past. While this works well on Layer 2 solutions where gas costs are low, it’s often prohibitive on the Ethereum mainnet.\nAxiom and Herodotus take this approach a step further by using zero knowledge proofs (ZKP) to prove storage slots and arbitrary computations over storage slots. The core advantage of this approach is that ZKP proofs can be aggregated. With a fixed gas cost of around 300-500k, you can obtain proofs for many storage slots and even computations over these slots.\n2 Zero knowledge proofs for storage slots values\nThe concept of aggregating storage proofs into a single zero-knowledge proof (ZKP) is fundamental in reducing gas costs for verification. This approach is extensively documented in the Axiom Documentation and the Herodotus Documentation. In this section, we provide a brief summary to ensure the completeness of our discussion. If you’re already familiar with these solution, feel free to skip to section 3.\n2.1 Components of the Proof System\nThe proof system under consideration has several components:\n\nProof of Blockhash: This involves having an onchain Merkle proof for all block number-to-blockhash pairs\n\nProof of Storage: This part focuses on generating proofs for storage slots corresponding to a specific blockhash\n\n2.2 Proof of Blockhash\nScreenshot 2023-12-13 at 11.19.301020×500 44.8 KB\nThe process of storing proofs of blockhash utilizes a cryptographic structure known as the Merkle Mountain Range (MMR). MMR is a specialized data structure that combines the concepts of a Merkle tree and a mountain range. Its primary purpose is to efficiently store and verify large sets of data, particularly in append-only contexts like blockchain. Unlike traditional Merkle trees, which are binary and balanced, MMRs consist of several smaller, individual Merkle trees, often referred to as ”peaks,” arranged to form a range or sequence. (see Figure 2)\nEach peak in a Merkle Mountain Range is itself a perfect Merkle tree, and these peaks vary in size. This variation allows for efficient append operations, as new data can be added without needing to restructure the entire tree. The root of an MMR is the combination of the roots of these individual peaks, and it provides a cryptographic proof of the entire dataset.\nEach leaf in MMR is a blockhash of a specific block. A dedicated smart contract is deployed to verify the correctness of MMR roots using ZKPs. The verification of a blockhash can be conducted in two distinct ways:\n\nOnchain Comparison: The blockhash is compared directly to the output of the BLOCKHASH opcode on the blockchain\n\nHash Chain Validation: In cases where the onchain comparison is not\n\nfeasible, the validity of the blockhash is ascertained by verifying its hashchain linkage to known blocks. This method is visualized in Figure 1, which illustrates the chain of hashes leading back to a known block.\nThe process of bringing the MMR roots onchain is executed in two primary stages:\n\nInitial Setup Phase: This stage involves the generation of the MMR root for all blocks up to a recent block. It establishes a foundational state from which subsequent verifications can proceed.\n\nMMR Root Updates: Following the initial setup, the MMR root is regularly updated to bring all blocks up to the current point in the blockchain.\n\nThis continuous update ensures that the proof system remains current and reliable.\n2.3 Proof of Storage\nWith the accessibility of onchain proofs for blockhashes now established, the next crucial step involves generating ZKPs for a specific set of storage slots. The process is based on converting the standard Ethereum Merkle-Patricia proofs into a format compatible with ZKPs. This conversion process involves encoding the traditional proofs into a structure that can be efficiently processed and\nverified through ZKP algorithms. Once the proofs are translated into the ZKP format, the final step is to submit these proofs to Ethereum. ZKPs are more gas-efficient compared to the conventional onchain verification methods with Merkle trees.\n2.4 Effectiveness for Proof of computation\nAxiom implements a ZKP system that uses storage slots and other blockchain data. The system is designed to prove arbitrary statements about the historical state of Ethereum. Theoretically, this ZKP system has the capacity to perform arbitrary computations. However, in practice, these computations must be implemented in specialized languages tailored for zero-knowledge applications, such as Halo2, Circom, or Cairo. This requirement presents a practical limitation, particularly when verifying the historical execution of contract calls on the blockchain.\nFor effective verification, one would need to translate or port the smart contracts, along with any dependent contracts, from Solidity (the native language of Ethereum smart contracts) to one of these ZKP-compatible languages. This translation process is not only technically demanding but also makes the task of verifying historical contract executions somewhat impractical.\n3 Onchain Computation Proofs\nIn addressing the challenge of verifying historical onchain calls, we propose a comprehensive multi-step process that integrates both offchain and onchain components, as illustrated in Figure 3.\nScreenshot 2023-12-13 at 11.23.54980×842 46.2 KB\nThe suggested process is broken down into a few steps:\n\nUse the offchain RPC API (specifically the debug_traceCall method) to retrieve storage slots and their corresponding values for a particular onchain call at a given block.\n\nUse the acquired data to interact with a storage prover, subsequently obtaining a proof.\n\nAdditionally, get a proof of the contract’s hashcode at the time of execution. The storage provers we mentioned earlier are capable of generating this proof as well.\n\nForward the storage data and hashcode to a verifier smart contract.\n\nThe verifier, in turn, confirms this data onchain through the use of Storage Verifier smart contracts.\n\nThe verifier then submits the storage slot values and hash code to an onchain EVM implementation (as discussed below).\n\nThe onchain EVM retrieves the current contract code, matches it with the provided hashcode, and executes the code. However, rather than reading actual values from the storage, it uses the supplied storage values.\n\nFinally, the result of the call is returned to the verifier for final analysis.\n\nThis approach makes the computation proof viable for any smart contract execution. All that is required are storage proofs and a single onchain EVM implementation applicable to all contracts that have ever existed on the Ethereum blockchain.\n3.1 Onchain EVM\nAn EVM is a state transition function that alters the state in response to an\nEthereum transaction. The function can be represented as:\n\nwhere St+1 is the state after the transaction,St is the state before the transaction, and Tx is the transaction.\nThe EVM has a finite set of opcodes, each altering the Ethereum state in its own specific way. It incorporates four types of memory:\n\nStack\n\nCalldata\n\nDynamic\n\nStorage\n\nThus, we can model the execution context of the onchain EVM as shown in Table 2.\nScreenshot 2023-12-13 at 11.26.441038×600 59.3 KB\nThen for every EVM instruction we’ll make a state transition. For all opcodes it’ll behave exactly the same as EVM except we’ll implement a custom\nSLOAD code to use our slot values from the proof rather than reading them onchain. Additionally we can disable mutating opcodes like SSTORE and CALL (i.e. have only view call semantics).\nBelow is the reference implementation of the ‘SLOAD‘ opcode:\nScreenshot 2023-12-13 at 11.27.10978×642 66.1 KB\nThis approach works effectively, allowing us to create onchain proof of any historical call result. However, a primary concern now is the gas cost on the mainnet:\n\nStorage Proofs:The storage proofs will burn a significant amount of gas.\n\nOnchain EVM Execution: Additional gas costs will arise from onchain\n\nEVM execution. However, this increase is not too substantial since no actual storage is read; the operations are limited to memory and stack. Nevertheless, there is potential to further reduce the gas cost.\n4 zkEVM Computation Proofs\nThe final twist in our approach involves the use of zkEVM (Zero-Knowledge\nEthereum Virtual Machine) to create a ZKP of an onchain EVM execution. In\nthis scenario, the onchain verifier would only need to verify a single ZKP and\nthus save the gas costs.\nThe concept appears straightforward, yet there are only a few zkEVM implementations available in the market. Prominent zkEVM providers include:\n\nzkSync\n\nPolygon\n\nScrolls\n\nWhile some of these platforms are already operational, they are relatively new and still evolving.\nAnother critical aspect to consider is the categorization of zkEVMs into three distinct levels:\n\nConsensus Compatible: Ideal for our scenario, but these types of zkEVMs are currently under development and not yet released.\n\nEVM Compatible: Theoretically usable, but additional steps are necessary for full compatibility with onchain EVM.\n\nSolidity Compatible: Doesn’t work for our scenario.\n\nLastly, it’s important to consider that generating a zkEVM proof might require significant offchain resources. This factor should be carefully factored into any planning or implementation.\n5 Use cases\n5.1 Decentralized Onchain Dutch Auctions\nA Dutch auction, also known as a descending price auction, is a type of auction where the auctioneer begins with a high asking price which is progressively lowered until a participant accepts the price.\nExamples of Dutch auctions implemented onchain include:\n\nVRGDA (Variable Rate Gradual Dutch Auction)\nDLM (Declarative Liquidity Manager)\n\nTo commence a Dutch auction onchain, an initial call must be made, marking\nthe start of the auction. However, this approach presents certain challenges:\n\nCentralization Issue: It requires a kind of trusted Auction Manager to initiate the auction, potentially compromising decentralization.\n\nMaintenance Cost: There are ongoing costs associated with managing and executing the necessary actions.\n\nBy leveraging onchain call proofs, the responsibility of initiating the auction can be transferred to the participants (auction bidders). Here’s how it works:\n\nAs an auction participant submits their bid, they simultaneously provide a proof that the auction should have started at a specific block in the past (a result of a previous onchain call).\n\nThis process validates the bid and effectively initiates the auction at the same time.\n\nThis model effectively eliminates the need for an Auction Manager, leading to a more decentralized and autonomous auction process, aligning with the principles of blockchain and decentralized systems.\n5.2 Keeper Network\nA keeper network is a system where specialized nodes, known as keepers, are responsible for performing certain network functions. These functions can include executing transactions, managing smart contracts, or performing maintenance tasks. The key feature of a keeper network is its ability to automate these processes, which are crucial for the efficiency and reliability of blockchain operations.\nOne significant issue within keeper networks is the lack of a hard guarantee that a keeper will not miss a task execution. This uncertainty can compromise the reliability of the network. To mitigate this risk, some systems implement staking mechanisms for keepers, where they must stake a certain amount of cryptocurrency as a form of collateral.\nHowever, introducing staking necessitates a mechanism to penalize (or slash) keepers for any misbehavior or failure to execute tasks. This is where the challenge lies: designing a system that can fairly and accurately identify and penalize such failures.\nA potential solution to this challenge is Eigenlayer. Eigenlayer is a protocol that allows for the creation of decentralized, trust-minimized networks over existing blockchains. It works by enabling users to stake their tokens on specific network functions or validators, effectively creating a layer of accountability and security.\nTo leverage Eigenlayer in a keeper network, the following approach can be adopted:\n\nOnchain proof is submitted to demonstrate that in block X, a call was supposed to be executed by keeper Y but was not.\n\nUpon verification of this failure, Eigenlayer’s staking and slashing mechanisms can be used to penalize the keeper, ensuring accountability and reliability.\n\n6 Conclusion\nThis article has explored the domain of onchain computation proofs, particularly focusing on the ability to create and verify proofs of historical smart contract calls within the Ethereum ecosystem.\nThe approach outlined here leverages the power of onchain data and zero-knowledge proofs to retrospectively validate smart contract executions. This method makes decentralized apps more transparent and trustworthy, and also creates new ways for smart contracts to interact with and check past states.\n\n read \n\n 6\n min\n\n Powered by Discourse","tokens":4150,"squid":"spider-04","role":"Research Spider","at":1791345406597,"hash":"a28c01729418c8a941e3caefe239d3df12946d41"}
{"url":"https://www.metaplex.com/docs/smart-contracts/core/plugins/permanent-freeze-delegate","domain":"metaplex.com","title":"Permanent Freeze Delegate | Metaplex Core","text":"The Permanent Freeze Delegate Plugin provides irrevocable freeze authority that persists across transfers. Use it for soulbound tokens, collection-wide freezing, and permanent lock mechanisms. What You'll LearnCreate Assets with permanent freeze capabilityFreeze entire Collections at onceImplement soulbound (non-transferable) tokensUnderstand permanent vs regular freeze delegateSummaryThe Permanent Freeze Delegate is a permanent plugin that can only be added at creation time. Unlike the regular Freeze Delegate, this authority persists forever and can freeze/thaw even after transfers.Can only be added at Asset/Collection creationAuthority persists across transfers (never revoked)Uses forceApprove - can freeze even with other blocking pluginsCollection-level freezing affects all Assets in the CollectionOut of ScopeRegular freeze delegate (see Freeze Delegate), temporary freezing, and Token Metadata freeze authority.Quick StartJump to: Create Asset · Create Collection · Update (Thaw)Add PermanentFreezeDelegate plugin at Asset/Collection creationSet frozen: true for immediate freeze, or false to freeze laterThe delegate can freeze/thaw at any time, even after transfersPermanent vs Regular Freeze DelegateFeatureFreeze DelegatePermanent Freeze DelegateAdd after creation✅ Yes❌ Creation onlyAuthority persists on transfer❌ Revokes✅ PersistsWorks with Collections❌ No✅ YesforceApprove❌ No✅ YesSoulbound tokens❌ Limited✅ Best choiceChoose Freeze Delegate for temporary, revocable freezing.Choose Permanent Freeze Delegate for permanent authority or collection-wide freezing.Common Use CasesSoulbound tokens: Create non-transferable credentials, achievements, or membershipsCollection-wide freeze: Freeze all Assets in a Collection with one pluginPermanent collateral: Lock Assets as collateral that survives ownership changesGame item permanence: Items that stay locked regardless of tradesCompliance requirements: Assets that must remain frozen for regulatory reasonsWorks WithMPL Core Asset✅MPL Core Collection✅BehavioursAsset: Allows the delegated address to freeze and thaw the NFT at any time.Collection: Allows the collection authority to freeze and thaw the whole collection at once. It does not allow to freeze a single asset in the collection using this delegate.ArgumentsArgValuefrozenboolCreating an Asset with a Permanent Freeze pluginThe following example shows how to create an Asset with a Permanent Freeze plugin.Creating an Asset with a Permanent Freeze pluginimport { publicKey } from '@metaplex-foundation/umi'\nimport { create } from '@metaplex-foundation/mpl-core'\nconst assetSigner = generateSigner(umi)\nconst delegate = publicKey('33333333333333333333333333333')\nawait create(umi, {\n asset: assetSigner,\n name: 'My NFT',\n uri: 'https://example.com/my-asset.json',\n plugins: [\n {\n type: 'PermanentFreezeDelegate',\n frozen: true,\n authority: { type: 'Address', address: delegate },\n },\n ],\n}).sendAndConfirm(umi)\nUpdating the Permanent Freeze Delegate plugin on an AssetThe following example shows how to update the Permanent Freeze Delegate plugin on an Asset. Freeze or unfreeze it by setting the frozen argument to true or false respectively. It assumes that the signing wallet is the plugin authority.Updating the Permanent Freeze Delegate plugin on an Assetimport { updatePlugin } from '@metaplex-foundation/mpl-core'\nconst updateAssetResponse = await updatePlugin(umi, {\n asset: asset.publicKey,\n plugin: {\n type: \"PermanentFreezeDelegate\",\n frozen: false,\n },\n}).sendAndConfirm(umi);\nCreating a Collection with a Permanent Freeze pluginThe following example shows how to create a collection with a Permanent Freeze plugin.Creating a Collection with a Permanent Freeze pluginimport { generateSigner } from '@metaplex-foundation/umi'\nimport { createCollection } from '@metaplex-foundation/mpl-core'\nconst collectionSigner = generateSigner(umi)\nawait createCollection(umi, {\n collection: collectionSigner,\n name: \"Frozen Collection\",\n uri: \"https://example.com/my-collection.json\",\n plugins: [\n {\n type: 'PermanentFreezeDelegate',\n frozen: true,\n authority: { type: \"UpdateAuthority\"}, // The update authority can unfreeze it\n },\n ],\n }).sendAndConfirm(umi);\nUpdating a Collection with a Permanent Freeze pluginThe following example shows how to update the Permanent Freeze Delegate plugin on a Collection. Freeze or unfreeze it by setting the frozen argument to true or false respectively. It assumes that the signing wallet is the plugin authority.Updating a Collection with a Permanent Freeze pluginimport { updateCollectionPlugin } from '@metaplex-foundation/mpl-core'\nconst updateCollectionResponse = await updateCollectionPlugin(umi, {\n collection: collectionSigner.publicKey,\n plugin: {\n type: \"PermanentFreezeDelegate\",\n frozen: false,\n },\n }).sendAndConfirm(umi);\nCommon ErrorsCannot add permanent plugin after creationPermanent plugins can only be added at Asset/Collection creation. You cannot add a Permanent Freeze Delegate to an existing Asset.Authority mismatchOnly the plugin authority can freeze/thaw. Verify you're signing with the correct keypair.NotesOn creation only: Cannot be added after Asset/Collection existsForce approve: Can freeze even with conflicting pluginsCollection behavior: Freezes all Assets at once, not individuallyPersists forever: Authority is never revoked, even after transfersUse for soulbound tokens by setting frozen: true with authority NoneFAQHow do I create a soulbound (non-transferable) token?Create the Asset with PermanentFreezeDelegate, set frozen: true, and set authority to None. The Asset can never be unfrozen or transferred.What's the difference between Freeze Delegate and Permanent Freeze Delegate?Regular Freeze Delegate authority is revoked on transfer and only works on Assets. Permanent Freeze Delegate persists forever, works on Collections, and uses forceApprove.Can I freeze individual Assets in a Collection?No. When Permanent Freeze Delegate is on a Collection, freezing affects all Assets at once. Use Asset-level Permanent Freeze Delegate for individual control.Can a permanently frozen Asset be burned?Only if there's also a Permanent Burn Delegate. Regular Burn Delegate cannot burn frozen Assets, but Permanent Burn Delegate uses forceApprove.Related PluginsFreeze Delegate - Revocable freeze for temporary lockingPermanent Transfer Delegate - Permanent transfer authorityPermanent Burn Delegate - Burn even frozen AssetsGlossaryTermDefinitionPermanent PluginPlugin that can only be added at creation and persists foreverforceApproveValidation that overrides other plugin rejectionsSoulboundNon-transferable token permanently frozen to a walletCollection FreezeFreezing all Assets in a Collection at once","tokens":1679,"squid":"dotcat","role":"Tooling Spider","at":1791345410229,"hash":"6e1ae113cbb9e3f3309cc032f4e19b4676f6f9b7"}
{"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":"spider-05","role":"Spec Spider","at":1791345416699,"hash":"675ad28d156f1c465db752f8479c857a1b75b482"}
{"url":"https://ethresear.ch/t/about-the-economics-category/1080/5","domain":"ethresear.ch","title":"About the Economics category - Economics - Ethereum Research","text":"Economics\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n Feb 2018\n\n 4 / 4\n\n Jul 2025\n\n Jul 2025\n\n post by vbuterin on Feb 14, 2018\n\n vbuterin\n\n (Replace this first paragraph with a brief description of your new category. This guidance will appear in the category selection area, so try to keep it below 200 characters. Until you edit this description or create topics, this category won’t appear on the categories page.)\nUse the following paragraphs for a longer description, or to establish category guidelines or rules:\n\nWhy should people use this category? What is it for?\n\nHow exactly is this different than the other categories we already have?\n\nWhat should topics in this category generally contain?\n\nDo we need this category? Can we merge with another category, or subcategory?\n\n 2\n\n 4 years later\n\n post by STZeed on Jan 3, 2022\n\n STZeed\n\n This is for developing. To help grow. This has community before profit with improvement. Communities online and of line.\n\n 3 months later\n\n post by STZeed on Mar 28, 2022\n\n STZeed\n\n Creptocerncy Research By “Zachary Anello”. Problem… Confusion amount average workforce. “Concept” Dow NFTID union. Companies offer benefits by investing in union tokens. To pool in industry or give out their own coin registered on the market. Creating Industry Pool governed by companies DoW or IDNFT personal Wp 401k DoW, Wp insurance Dow, and Wp dental Dow. Coin pooling for companies to offer Tokenes Baked by the IDnft number of activities in an industry coin and one’s own time spent in the industry for personal retirement control plus benefits. A Global workforce union governed by legal geographical Industry DOW. With 3 or more company participation. Proof of study or work a GID, “global industry DoW” governed by IDnft union holders will have a lifelong ability to utilize the dow union for retirement or change of industry time is ongoing for all holding Gi union IDnft time + level = Benefits from the Global DoW union funds. A regional workforce of individuals in a proven industry adding to a verifiable IDnft sincerity, 10 year states With a confirmed yearly NFT update ID.AI.AS\n\n 3 years later\n\n post by jonhubby on Jul 8, 2025\n\n jonhubby\n\n “Wow, that’s quite an interesting concept, STZeed. Mixing blockchain and workforce benefits is ambitious. Do you have any examples of companies already trying something similar?”\n\n Powered by Discourse","tokens":602,"squid":"spider-04","role":"Research Spider","at":1791345426915,"hash":"f4ebbddb68f4fff89355ff59cc964eef7a5bf44d"}
{"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":"spider-05","role":"Spec Spider","at":1791345428308,"hash":"d4854d3682d5f79200412adb5badabe371058768"}
{"url":"https://ethresear.ch/t/about-the-economics-category/1080","domain":"ethresear.ch","title":"About the Economics category - Economics - Ethereum Research","text":"About the Economics category \n\n Economics\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n Feb 2018\n\n 1 / 4\n\n Feb 2018\n\n Jul 2025\n\n post by vbuterin on Feb 14, 2018\n\n vbuterin\n\n (Replace this first paragraph with a brief description of your new category. This guidance will appear in the category selection area, so try to keep it below 200 characters. Until you edit this description or create topics, this category won’t appear on the categories page.)\nUse the following paragraphs for a longer description, or to establish category guidelines or rules:\n\nWhy should people use this category? What is it for?\n\nHow exactly is this different than the other categories we already have?\n\nWhat should topics in this category generally contain?\n\nDo we need this category? Can we merge with another category, or subcategory?\n\n 2\n\n 4 years later\n\n post by STZeed on Jan 3, 2022\n\n STZeed\n\n This is for developing. To help grow. This has community before profit with improvement. Communities online and of line.\n\n 3 months later\n\n post by STZeed on Mar 28, 2022\n\n STZeed\n\n Creptocerncy Research By “Zachary Anello”. Problem… Confusion amount average workforce. “Concept” Dow NFTID union. Companies offer benefits by investing in union tokens. To pool in industry or give out their own coin registered on the market. Creating Industry Pool governed by companies DoW or IDNFT personal Wp 401k DoW, Wp insurance Dow, and Wp dental Dow. Coin pooling for companies to offer Tokenes Baked by the IDnft number of activities in an industry coin and one’s own time spent in the industry for personal retirement control plus benefits. A Global workforce union governed by legal geographical Industry DOW. With 3 or more company participation. Proof of study or work a GID, “global industry DoW” governed by IDnft union holders will have a lifelong ability to utilize the dow union for retirement or change of industry time is ongoing for all holding Gi union IDnft time + level = Benefits from the Global DoW union funds. A regional workforce of individuals in a proven industry adding to a verifiable IDnft sincerity, 10 year states With a confirmed yearly NFT update ID.AI.AS\n\n 3 years later\n\n post by jonhubby on Jul 8, 2025\n\n jonhubby\n\n “Wow, that’s quite an interesting concept, STZeed. Mixing blockchain and workforce benefits is ambitious. Do you have any examples of companies already trying something similar?”\n\n Powered by Discourse","tokens":610,"squid":"spider-04","role":"Research Spider","at":1791345448929,"hash":"0fa942f49428eadc1b85889c90defa029f71ca31"}
{"url":"https://ethereum.org/apps/","domain":"ethereum.org","title":"Top crypto apps on Ethereum | ⁦ethereum.org⁩","text":"HighlightsUniswap is an automated liquidity protocol powered by a constant product formula and implemented in a system of non-upgradeable smart contracts on the Ethereum blockchain. It obviates the need for trusted intermediaries, prioritizing decentralization, censorship resistance, and security.DeFiUniswapDEXA fully decentralized mixing protocol for private transactions on Ethereum.PrivacyTornado CashPoolsFocus Tree is an web3 app that helps you manage your screentime better. Grow your garden with friends and collect items on Starknet blockchain.ProductivityFocus TreeMemberships · LifestyleUniswap is an automated liquidity protocol powered by a constant product formula and implemented in a system of non-upgradeable smart contracts on the Ethereum blockchain. It obviates the need for trusted intermediaries, prioritizing decentralization, censorship resistance, and security.DeFiUniswapDEXA fully decentralized mixing protocol for private transactions on Ethereum.PrivacyTornado CashPoolsFocus Tree is an web3 app that helps you manage your screentime better. Grow your garden with friends and collect items on Starknet blockchain.ProductivityFocus TreeMemberships · LifestyleDiscoverDeFi1inch1inch is an exchange aggregator that scans decentralized exchanges to find the lowest cryptocurrency prices for traders.DEXProductivityFileverse - ddocsddocs.new is a privacy-first alternative to Google docs. dDocs is end-to-end encrypted, open-source, and onchain. By design, not by promise. You can use it both for real-time and async collaboration! Moisturised features include: Markdown and LaTeX support; Darkmode; local LLM plugin; Offline mode; Collaborate with your ENS vs email; Accountless version where all your docs are stored locally. What we stand for: Self-sovereignty, Privacy, Open standards.Privacy · Communication · StorageDAOSplitsSplits is a platform offering financial infrastructure for onchain teams, specializing in managing onchain payments using audited, open-source smart contracts.Treasury managementPrivacyFluidkeyFluidkey is a wallet to receive and manage funds onchain without publicly linking them together via stealth addresses. Fluidkey allows users to seamlessly manage, receive, and send onchain assets while protecting their privacy.Stealth address · Payments · IdentityCollectiblesBasepaintBasePaint.xyz is a collaborative, onchain pixel art application where artists create daily, shared canvases that are then minted as NFTs.IP · ArtSocialParagraphParagraph is a Web3 publishing platform that lets writers create token-gated newsletters and mint content as NFTs on Ethereum and Base.PublishingApplicationsDeFiAaveLending 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":1377,"squid":"spider-05","role":"Spec Spider","at":1791345450330,"hash":"af9d1619f3d79e2b6770548999bcd09454e37d33"}
{"url":"https://core.metaplex.com/","domain":"core.metaplex.com","title":"Metaplex Core UI","text":"Check out the new Oracle external plugin here!Start building with CoreCore is a next generation Solana NFT standard and asset programDocumentation - hereMPL Repository - hereJavascript SDK - hereRust SDK - hereA standard purpose-built for Digital AssetsDesigned from the ground-up, Core is the culmination of learnings since introducing the first Solana NFT standard in early 2021. Core rethinks the concept of digital assets on Solana, optimizing for cost, extensibility and performance.Lowest costWith creation costs as low as ◎0.0029, Core is the cheapest NFT standard on Solana.Extreme performanceOptimize your dApps through Core's single account model and 90% reduction in Compute Units for lifecycle actions like mint and transfer.Maximum versatilityAdd custom functionlity to your Core assets with 1st and 3rd party plugins that hook into lifecycle events.Single account, single programNo more dealing with ATA's, metadata acounts, edition accounts or delegate accounts.const asset = generateSigner(umi);\nawait create(umi, {\n asset: asset,\n name: 'My digital asset #1',\n uri: 'https://example.com/metadata.json',\n}).sendAndConfirm(umi);\n\nconst recipient = generateSigner(umi);\nawait transfer(umi, {\n asset: asset.publicKey,\n newOwner: recipient.publicKey,\n}).sendAndConfirm(umi);First class collectionsApply collection-wide configurations to collections in a single transaction, automatic collection size tracking and more.Indexing includedChoose your favorite Digital Asset Standard API provider (DAS API) to query Core assets and collections.Configurable on-chain stateAttach custom on-chain data to your assets via the attributes plugin which will automatically get indexed by the DAS API.Developer friendlyComes with all the developer tooling and documentation you've come to expect from a Metaplex product as well as compatibility with top MPL projects such as Candy Machine, DAS API, Umi, Amman and more.Ecosystem readyJoin top Solana collections Claynosaurz and Aurory in creating the next generation of Solana NFTs. Supported by top Solana wallets and marketplaces.Secure by defaultCore has been audited by one of Solana's most trusted security firms, Mad Shield.","tokens":545,"squid":"dotcat","role":"Tooling Spider","at":1791345453050,"hash":"58124e9921b7e3c2f84a18cc81d23857e7e8c8db"}
{"url":"https://ethresear.ch/t/about-the-economics-category/1080/4","domain":"ethresear.ch","title":"About the Economics category - Economics - Ethereum Research","text":"Economics\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n Feb 2018\n\n 3 / 4\n\n Mar 2022\n\n Jul 2025\n\n post by vbuterin on Feb 14, 2018\n\n vbuterin\n\n (Replace this first paragraph with a brief description of your new category. This guidance will appear in the category selection area, so try to keep it below 200 characters. Until you edit this description or create topics, this category won’t appear on the categories page.)\nUse the following paragraphs for a longer description, or to establish category guidelines or rules:\n\nWhy should people use this category? What is it for?\n\nHow exactly is this different than the other categories we already have?\n\nWhat should topics in this category generally contain?\n\nDo we need this category? Can we merge with another category, or subcategory?\n\n 2\n\n 4 years later\n\n post by STZeed on Jan 3, 2022\n\n STZeed\n\n This is for developing. To help grow. This has community before profit with improvement. Communities online and of line.\n\n 3 months later\n\n post by STZeed on Mar 28, 2022\n\n STZeed\n\n Creptocerncy Research By “Zachary Anello”. Problem… Confusion amount average workforce. “Concept” Dow NFTID union. Companies offer benefits by investing in union tokens. To pool in industry or give out their own coin registered on the market. Creating Industry Pool governed by companies DoW or IDNFT personal Wp 401k DoW, Wp insurance Dow, and Wp dental Dow. Coin pooling for companies to offer Tokenes Baked by the IDnft number of activities in an industry coin and one’s own time spent in the industry for personal retirement control plus benefits. A Global workforce union governed by legal geographical Industry DOW. With 3 or more company participation. Proof of study or work a GID, “global industry DoW” governed by IDnft union holders will have a lifelong ability to utilize the dow union for retirement or change of industry time is ongoing for all holding Gi union IDnft time + level = Benefits from the Global DoW union funds. A regional workforce of individuals in a proven industry adding to a verifiable IDnft sincerity, 10 year states With a confirmed yearly NFT update ID.AI.AS\n\n 3 years later\n\n post by jonhubby on Jul 8, 2025\n\n jonhubby\n\n “Wow, that’s quite an interesting concept, STZeed. Mixing blockchain and workforce benefits is ambitious. Do you have any examples of companies already trying something similar?”\n\n Powered by Discourse","tokens":602,"squid":"spider-04","role":"Research Spider","at":1791345459066,"hash":"aac3fbbebc13cf450c49901a02e10702159c392c"}
{"url":"https://ethereum.org/apps/uniswap/","domain":"ethereum.org","title":"Ethereum Apps - Uniswap | ⁦ethereum.org⁩","text":"DeFiUniswapby Uniswap LabsEnglish, Chinese, Japanese, French, Portuguese Visit Uniswap (opens in a new tab) (opens in a new tab) (opens in a new tab) (opens in a new tab)See nextPendleSee nextPendleUniswap is an automated liquidity protocol powered by a constant product formula and implemented in a system of non-upgradeable smart contracts on the Ethereum blockchain. It obviates the need for trusted intermediaries, prioritizing decentralization, censorship resistance, and security.InfoFounded2018CreatorUniswap LabsLast updated457 days agoGalleryMore apps like thisDeFiCurveCurve.fi is a non-custodial decentralized exchange that revolutionized stablecoin trading. It began by offering superior exchange rates for stablecoin swaps (like DAI to USDC) through liquidity pools, where users earn yield by depositing their assets.DEXDeFiBalancerBalancer is a decentralized automated market maker (AMM) protocol built on Ethereum with a clear focus on fungible and yield-bearing liquidity. Balancer's success is intrinsically linked to the success of protocols and products built on the platform.DEXDeFiFluidFluid is a DeFi protocol combining a liquidity layer, automated limits, lending and vault protocols, robust oracle system, and DEX protocol,Lending and borrowing · DEX","tokens":319,"squid":"spider-05","role":"Spec Spider","at":1791345461929,"hash":"05af25705e5ae6e430a744679214cb2bc0e18246"}
{"url":"https://developers.jup.ag/docs/swap/advanced/transaction-versions","domain":"developers.jup.ag","title":"Transaction Versions (v0 and v1) - Jupiter Developers","text":"Solana transaction v1 (the “larger transaction sizes” upgrade, SIMD-0385) is live on mainnet. The Swap API builds it on request. v1 is opt-in and the forward path for new integrations.\nv1 gives you:\n\nBigger transactions: 4096 bytes, up from 1232.\nNo lookup tables: up to 64 accounts inline, so there is nothing to resolve or compile against.\nRoom for your own instructions: CPI, memos, or transfers alongside the swap.\n\n​v0 vs v1\nv0v1Max transaction size1232 bytes4096 bytesAccountsUp to 64, referenced via Address Lookup Tables (ALTs)Up to 64, all inline (no ALTs)Compute budgetComputeBudgetProgram instructionsOn the message configSDK to build and sign@solana/kit or @solana/web3.js@solana/kit v8 or later only\nBoth cap at 64 accounts. v0 reaches that by referencing ALT addresses at 1 byte each; v1 inlines full addresses, which now fit in the larger envelope.\n​Requesting v1\nThe parameter differs by endpoint:\n\nRouter (/build): pass transactionVersion=1 (\"0\" or \"1\", default \"0\"). This forces v1, and you assemble the transaction yourself.\nGET https://api.jup.ag/swap/v2/build?...&transactionVersion=1\n\nMeta-Aggregator (/order): pass maxSupportedTransactionVersion=1 (\"0\" or \"1\", default \"0\"). This is a ceiling, not a force. You get v1 only when Metis wins the route and the order is not gasless; otherwise /order returns v0. Read the response transactionVersion for what you got, and /execute lands either.\nGET https://api.jup.ag/swap/v2/order?...&maxSupportedTransactionVersion=1\n\nToday v1 on /order is supported only on Metis. Other routers return v0 for now, and we are working toward v1 across them, including JupiterZ. Two cases to plan for:\n\nGasless orders are always v0. This includes automatic sponsorship, which can fire for low-SOL takers without you asking, and the integrator payer. An integrator testing with a funded wallet may see v1 while their low-SOL users get v0.\nA non-Metis win is v0. If another router gives the best price, you get a v0 transaction.\n\ntransactionVersion and maxSupportedTransactionVersion are not interchangeable. /order ignores transactionVersion and /build ignores maxSupportedTransactionVersion; the wrong name is silently ignored, with no error.\n​Response differences\nWhen /build builds v1, the response changes shape:\nFieldv0v1transactionVersion01computeBudgetInstructionsCU price instructionempty (budget goes on the config)addressesByLookupTableAddresslookup tables to compile against{} (no ALTs)computeUnitPricenot present (inside the instruction)present, micro-lamports per CU, as a string\nYou set the compute unit limit and loaded accounts data size limit yourself. On the Meta-Aggregator, /order returns a built transaction and transactionVersion; sign it and hand it to /execute.\n​Building a v1 transaction\n\nBuild, deserialize, and sign v1 transactions with @solana/kit v8 or later (it exposes setTransactionMessageConfig). @solana/web3.js v1 cannot sign v1 transactions.\n\nSet the compute budget on the message config, not as instructions: computeUnitLimit, loadedAccountsDataSizeLimit (v1 defaults both to zero, so a transaction without them fails), and the priority fee. As on v0 /build, simulate the transaction to size the compute unit limit rather than hardcoding the maximum.\n\nThe API returns computeUnitPrice in micro-lamports per CU. v1’s priorityFeeLamports is an absolute lamport total, so convert it:\npriorityFeeLamports = ceil(computeUnitPrice × computeUnitLimit ÷ 1_000_000)\n\nNot all wallet extensions can sign v1 transactions yet. Requesting v1 for a wallet that does not support it fails at signing. Know which wallets support v1 upfront and request it only for those. This matters most on the Meta-Aggregator path, where the end user’s wallet signs the transaction /order returns.\nThe compute unit price clamp reads computeBudgetInstructions, which is empty on v1, so it does nothing there. Validate computeUnitPrice against your own ceiling before converting it to priorityFeeLamports.\nThe example requests v1 from /build, simulates to size the compute unit limit, sets the budget on the config, signs, sends, and confirms.\n@solana/kit (v8 or later)import {\n AccountRole,\n Address,\n appendTransactionMessageInstructions,\n Blockhash,\n compileTransaction,\n createKeyPairSignerFromBytes,\n createSolanaRpc,\n createTransactionMessage,\n getBase58Decoder,\n getBase58Encoder,\n getBase64Codec,\n getBase64EncodedWireTransaction,\n pipe,\n setTransactionMessageConfig,\n setTransactionMessageFeePayerSigner,\n setTransactionMessageLifetimeUsingBlockhash,\n signTransactionMessageWithSigners,\n} from \"@solana/kit\";\n\nconst API_KEY = process.env.JUPITER_API_KEY;\nconst RPC_URL = process.env.RPC_URL;\nif (!API_KEY) throw new Error(\"Missing JUPITER_API_KEY\");\nif (!RPC_URL) throw new Error(\"Missing RPC_URL\");\n\nconst COMPUTE_UNIT_LIMIT_MAX = 1_400_000;\n// v1 has no default loaded-accounts-data-size limit (unset budgets zero bytes).\n// 64 MiB matches the implicit v0 default.\nconst LOADED_ACCOUNTS_DATA_SIZE_LIMIT = 64 * 1024 * 1024;\n\nconst signer = await createKeyPairSignerFromBytes(\n getBase58Encoder().encode(process.env.BS58_PRIVATE_KEY!),\n);\nconst rpc = createSolanaRpc(RPC_URL);\n\ntype ApiInstruction = {\n programId: Address;\n accounts: { pubkey: Address; isSigner: boolean; isWritable: boolean }[];\n data: string;\n};\n\ntype BuildResponse = {\n computeUnitPrice: string;\n setupInstructions: ApiInstruction[];\n swapInstruction: ApiInstruction;\n cleanupInstruction: ApiInstruction | null;\n otherInstructions: ApiInstruction[];\n tipInstruction: ApiInstruction | null;\n blockhashWithMetadata: { blockhash: number[]; lastValidBlockHeight: number };\n};\n\nfunction toInstruction(ix: ApiInstruction) {\n return {\n programAddress: ix.programId,\n accounts: ix.accounts.map((a) => ({\n address: a.pubkey,\n role:\n a.isSigner && a.isWritable\n ? AccountRole.WRITABLE_SIGNER\n : a.isSigner\n ? AccountRole.READONLY_SIGNER\n : a.isWritable\n ? AccountRole.WRITABLE\n : AccountRole.READONLY,\n })),\n data: Uint8Array.from(getBase64Codec().encode(ix.data)),\n };\n}\n\n// 1. Request v1 instructions from /build\nconst res = await fetch(\n \"https://api.jup.ag/swap/v2/build?\" +\n new URLSearchParams({\n inputMint: \"So11111111111111111111111111111111111111112\",\n outputMint: \"EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v\",\n amount: \"100000000\",\n taker: signer.address,\n slippageBps: \"100\",\n transactionVersion: \"1\",\n }),\n { headers: { \"x-api-key\": API_KEY } },\n);\nif (!res.ok) throw new Error(`/build failed: ${await res.text()}`);\nconst build = (await res.json()) as BuildResponse;\n// For v1: build.computeBudgetInstructions is [] and\n// build.addressesByLookupTableAddress is {}. The compute unit price is a field.\n\n// 2. Collect the swap instructions (no compute-budget instructions, no ALTs)\nconst instructions = [\n ...build.setupInstructions.map(toInstruction),\n toInstruction(build.swapInstruction),\n ...(build.cleanupInstruction ? [toInstruction(build.cleanupInstruction)] : []),\n ...build.otherInstructions.map(toInstruction),\n ...(build.tipInstruction ? [toInstruction(build.tipInstruction)] : []),\n];\n\nconst blockhash = {\n blockhash: getBase58Decoder().decode(\n Uint8Array.from(build.blockhashWithMetadata.blockhash),\n ) as Blockhash,\n lastValidBlockHeight: BigInt(build.blockhashWithMetadata.lastValidBlockHeight),\n};\n\n// Build a v1 message at a given compute unit limit. priorityFeeLamports is an\n// absolute lamport total (a bigint): compute unit price x limit, rounded up.\nfunction buildV1Message(computeUnitLimit: number) {\n const priorityFeeLamports = BigInt(\n Math.ceil((Number(build.computeUnitPrice) * computeUnitLimit) / 1_000_000),\n );\n return pipe(\n createTransactionMessage({ version: 1 }),\n (m) => setTransactionMessageFeePayerSigner(signer, m),\n (m) => setTransactionMessageLifetimeUsingBlockhash(blockhash, m),\n (m) => appendTransactionMessageInstructions(instructions, m),\n (m) =>\n setTransactionMessageConfig(\n {\n computeUnitLimit,\n priorityFeeLamports,\n loadedAccountsDataSizeLimit: LOADED_ACCOUNTS_DATA_SIZE_LIMIT,\n },\n m,\n ),\n );\n}\n\n// 3. Simulate at the max limit to measure compute units used, then size with a 1.2x buffer\nconst simulation = await rpc\n .simulateTransaction(\n getBase64EncodedWireTransaction(compileTransaction(buildV1Message(COMPUTE_UNIT_LIMIT_MAX))),\n { encoding: \"base64\", commitment: \"confirmed\", replaceRecentBlockhash: true },\n )\n .send();\nif (simulation.value.err) console.error(\"Simulation failed:\", simulation.value.err);\n\nconst computeUnitLimit = simulation.value.unitsConsumed\n ? Math.min(Math.ceil(Number(simulation.value.unitsConsumed) * 1.2), COMPUTE_UNIT_LIMIT_MAX)\n : COMPUTE_UNIT_LIMIT_MAX;\n\n// 4. Rebuild at the measured limit, sign, and send\nconst signed = await signTransactionMessageWithSigners(buildV1Message(computeUnitLimit));\nconst signature = await rpc\n .sendTransaction(getBase64EncodedWireTransaction(signed), {\n encoding: \"base64\",\n skipPreflight: true,\n })\n .send();\nconsole.log(\"Submitted:\", `https://solscan.io/tx/${signature}`);\n\n// 5. Confirm the transaction landed, and surface an on-chain failure\nfor (let i = 0; i < 40; i++) {\n await new Promise((r) => setTimeout(r, 1500));\n const { value } = await rpc.getSignatureStatuses([signature]).send();\n const status = value[0];\n if (status?.confirmationStatus === \"confirmed\" || status?.confirmationStatus === \"finalized\") {\n if (status.err) throw new Error(`Transaction failed: ${JSON.stringify(status.err)}`);\n console.log(\"Confirmed:\", signature);\n break;\n }\n}\n\nReading v1 transactions back needs maxSupportedTransactionVersion: 1 on getTransaction and similar RPC calls, or you get an “unsupported version” error. This applies to your confirmation and indexing code too.\n​When to use v1\nUse v1 when you:\n\nHit the 1232-byte size limit, with or without custom instructions.\nWant to avoid resolving and compiling against Address Lookup Tables.\nAre building a new integration, since new features target v1.\n\nFirst confirm your whole signing path supports it:\n\nA v1-capable SDK (@solana/kit v8 or later).\nA wallet that can sign v1 transactions.\nAn RPC that accepts v1 (maxSupportedTransactionVersion: 1 on reads).\n\n​Learn more\n\nVersioned transactions\nLarger transaction sizes (v1)\nSolana fee structure\n\n​Related\n\nBuild: request transactionVersion and assemble instructions yourself\nOrder & Execute: maxSupportedTransactionVersion on the managed path\nReduce Transaction Size: techniques when you still hit limits\nWas this page helpful?","tokens":2596,"squid":"spider-02","role":"Liquidity Spider","at":1791345479794,"hash":"520864e777eeed871d4014b29f5423cdd47644ea"}
{"url":"https://www.metaplex.com/docs/smart-contracts/mpl-distro/production-delivery","domain":"metaplex.com","title":"Deliver MPL-Distro Claims in Production","text":"MPL-Distro stores only the Merkle root on-chain. A production airdrop persists each allocation's proof off-chain and gives recipients a way to submit it. SummaryProduction delivery is the off-chain work around an MPL-Distro distribution: store claim records, serve them to the right claimant, and recover leftovers when the window ends.Create and fund the distribution with the Getting Started flow or the Metaplex CLI.Persist address, amount, nonce, and proof for every allocation before claims open.Choose Permissionless, Recipient, or Permissioned submission to match who should sign.Recover unclaimed tokens with Funding and Recovery after the window ends.No Hosted Claim InterfaceMPL-Distro does not ship a claim website or email, SMS, or Discord identity. The Metaplex CLI can create, fund, inspect, and recover a distribution; it does not generate Merkle proofs or submit claims. Notify users through any channel you already use; the on-chain leaf is still a wallet or legacy NFT mint.Jump to: Prerequisites · Submission Mode · Persist Records · Deliver Proofs · Recover TokensQuick StartA production MPL-Distro airdrop has five delivery steps around the on-chain program.Build a complete allocation list and generate the root with prepareDistribution.Persist one claim record per allocation, then create and fund the distribution.Serve each record from a claim page or lookup API keyed by wallet or NFT mint.Submit distribute or distributeToLegacyNft with the stored amount, nonce, and proof.After endTime, withdraw unclaimed tokens and unused receipt-rent subsidy.PrerequisitesProduction delivery starts from an existing SPL token mint and a finished allocation list.A Getting Started distribution (or the same create and deposit steps in your backend)Durable storage for claim records (database, object store, or downloadable file)A claim transaction payer funded for rent, network fees, and the 0.002 SOL protocol feeA distribution type: wallet or legacy NFTAllocation amounts are token base units. For a 6-decimal mint, 1.0 token is 1_000_000.Choose a Claim Submission ModeallowedDistributor decides who may submit a valid proof; it does not change where the tokens go.ModeWho signs the claimTypical production shapePermissionlessAny funded payerA claim page where the user or a relayer pays; tokens still go to the leafRecipientThe leaf wallet or current NFT ownerA claim page where the beneficiary must approve the transactionPermissionedThe configured permissionedDistributorOne backend is the only signer allowed to submit proofsTokens always arrive at the leaf's canonical associated token account (or the current NFT owner's ATA for LegacyNft). Permissionless submission cannot redirect funds to the payer.Keep the distribution authority and any permissioned-distributor key outside browser applications.Persist Allocation RecordsEach claim needs the same address, amount, nonce, and proof that prepareDistribution used for that leaf. The on-chain account cannot reconstruct those values from the root.Start from a complete list, then store the proof at the same index:allocations.json[\n {\n \"address\": \"8SoWVrwJ6vPa3rcdNBkhznR54yJ6iQqPSmgcXVGnwtEu\",\n \"amount\": \"10000000\",\n \"nonce\": \"0\"\n },\n {\n \"address\": \"GjwcWFQYzemBtpUoN5fMAP2FZviTtMRWCmrppGuTthJS\",\n \"amount\": \"5000000\",\n \"nonce\": \"0\"\n }\n]\npersistClaimRecords.ts1import { mplDistro, prepareDistribution } from '@metaplex-foundation/mpl-distro'\n2import { publicKey } from '@metaplex-foundation/umi'\n3import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n4\n5const umi = createUmi(\n6 process.env.RPC_URL ?? 'https://api.devnet.solana.com'\n7).use(mplDistro())\n8\n9const allocations = [\n10 { address: publicKey(process.env.RECIPIENT_1!), amount: 100_000n, nonce: 0n },\n11 { address: publicKey(process.env.RECIPIENT_2!), amount: 250_000n, nonce: 0n },\n12]\n13\n14const { root, proofs, treeHeight } = prepareDistribution(allocations)\n15\n16const claimRecords = allocations.map((allocation, index) => ({\n17 address: allocation.address,\n18 amount: allocation.amount.toString(),\n19 nonce: (allocation.nonce ?? 0n).toString(),\n20 proof: proofs[index],\n21}))\n22\n23// Persist claimRecords with the distribution PDA after createDistribution.\n24console.log(root, treeHeight, claimRecords.length)\n25\n26// One durable record per allocation: address, amount, nonce, and proof.\nAfter createDistribution, store the distribution PDA on every record. The claim transaction needs that address plus mint, amount, nonce, and proof.FieldRequired forNotesaddressLeaf identityWallet public key or legacy NFT mintamountLeaf dataToken base units as a string or bigintnonceLeaf dataDefaults to 0; required when the same address and amount appear twiceproofdistributeOne 32-byte sibling hash per tree level, in SDK orderdistributiondistributePDA from findDistributionPda after createStore Proofs Before Opening ClaimsThe authority cannot change the Merkle root, tree height, start time, or claimant count while startTime <= now <= endTime. Back up the full allocation file before the window starts.Deliver Merkle ProofsThe application looks up one stored record and passes it to distribute or distributeToLegacyNft. MPL-Distro does not index recipients.Common delivery shapes:Claim page. The user connects a wallet, pays network fees, and submits their stored proof.Lookup API. A service maps address → { amount, nonce, proof, distribution } for your frontend or relayer.Sponsored claim. The recipient (or an eligibility check) still triggers the claim. A relayer pays SOL so the user does not need a funded wallet. Tokens still go to the leaf ATA.Sponsored claims are not a substitute for sending every allocation in one backend loop. Each Distro claim still pays the 0.002 SOL protocol fee. If every recipient will receive tokens immediately with no claim step, use direct SPL token transfers.Use Distro when some allocations may go unclaimed, when you need a public Merkle commitment and time window, or when a relayer should pay only for people who actually claim.For LegacyNft, key the lookup by NFT mint. Resolve the current owner at claim time; do not freeze a snapshot owner into the leaf unless you intended a wallet distribution instead.Do not rebuild proofs from the on-chain root. A proof generated with a different hash, byte order, or leaf set fails with InvalidClaimProof.Open the Claim WindowClaims succeed only when the cluster time is inside the inclusive startTime–endTime window and the vault holds enough tokens.Create, deposit, and submit the first test claim with the Getting Started flow before opening the list to every recipient. Confirm:A sample proof from the persisted file matches distribute.The protocol fee payer has SOL for the 0.002 SOL fee plus receipt rent, or receipt subsidies are funded.Authority keys are not exposed to the claim frontend.Monitor ClaimsA successful claim creates a permanent claim-receipt PDA. Fetch that account, or compare claimCount / claimAmount on the distribution, to know which allocations are done.Treat AlreadyClaimed as success for that exact (distribution, recipient, amount, nonce) tuple. Ownership transfer of a LegacyNft mint does not reset the receipt.Recover Unclaimed TokensThe distribution authority withdraws leftover tokens and unused subsidy SOL only when the distribution is inactive: before startTime or after endTime.See Funding and Recovery for withdraw and withdrawSubsidy. Leave operational margin around the end timestamp so the last claims are not racing a recovery transaction.Production Delivery ChecklistValidate the off-chain file against the on-chain root before users rely on it.Sum of amount values is covered by the vault deposit.Every persisted proof is the prepareDistribution output for that same list, in the same order.Recipient mode is used when a leaked proof must not be enough to submit.Claim frontends never hold the distribution authority.Unclaimed tokens have an owner who can call withdraw after endTime.NotesMPL-Distro does not replace your allocation database, notification channel, or claim UI.totalClaimants is metadata and does not cap successful proofs.Claim receipts are not closed, so receipt rent stays allocated.Large lists should be built in a controlled Node.js process; prepareDistribution switches implementation at 1,000 leaves.FAQDoes MPL-Distro host a claim website?No. The program stores only the Merkle root. The application must persist proofs and provide a claim page or API.Can an email or Discord handle be the Merkle leaf?No. Leaves are wallet public keys or legacy NFT mints. Off-chain channels can notify users, but they are not on-chain identities.Is it safe to make Merkle proofs public?In Permissionless mode, anyone with a valid proof can submit the claim; tokens still go to the leaf address. Use Recipient mode when proof access alone must not authorize submission.Should a backend submit every Merkle proof itself?No. Submitting every proof from a backend is usually more expensive than SPL token transfers because each Distro claim pays the protocol fee. Use a relayer so users without SOL can still claim, or use Distro when some allocations may go unclaimed and you need the Merkle window.When can unclaimed tokens be recovered?The authority can withdraw tokens before the start timestamp or after the end timestamp. Withdrawals are rejected while startTime <= clusterTime <= endTime.","tokens":2345,"squid":"spider-10","role":"Tooling Spider","at":1791345485925,"hash":"940dc80ea879e93951fe18da62786a9e080c8a7e"}
{"url":"https://consensysdiligence.github.io/smart-contract-best-practices/development-recommendations/solidity-specific/locking-pragmas/","domain":"consensysdiligence.github.io","title":"Locking Pragmas - Ethereum Smart Contract Best Practices","text":"Locking Pragmas\n\nTip\nFor comprehensive insights into secure development practices, consider visiting the Development Recommendations section of the Smart Contract Security Field Guide. This resource provides in-depth articles to guide you in developing robust and secure smart contracts.\n\nContracts should be deployed with the same compiler version and flags that they have been tested\nthe most with. Locking the pragma helps ensure that contracts do not accidentally get deployed\nusing, for example, the latest compiler which may have higher risks of undiscovered bugs. Contracts\nmay also be deployed by others and the pragma indicates the compiler version intended by the\noriginal authors.\n// bad\npragma solidity ^0.4.4;\n\n// good\npragma solidity 0.4.4;\n\nNote: a floating pragma version (ie. ^0.4.25) will compile fine with 0.4.26-nightly.2018.9.25,\nhowever nightly builds should never be used to compile code for production.\n\nWarning\nPragma statements can be allowed to float when a contract is intended for consumption\nby other developers, as in the case with contracts in a library or EthPM package. Otherwise, the\ndeveloper would need to manually update the pragma in order to compile locally.\nSee SWC-103","tokens":303,"squid":"spider-06","role":"Security Spider","at":1791345489041,"hash":"fca70045659515a76e7e31daf0e64ee8d98e5d15"}
{"url":"https://developers.jup.ag/docs/guides/how-to-embed-a-swap-widget","domain":"developers.jup.ag","title":"How to Embed a Swap Widget in Your App - Jupiter Developers","text":"​TL;DR\nJupiter Plugin gives you the same swap experience as jup.ag, embedded directly in your app. One script tag, one function call. No RPC node, no wallet adapter code, no UI to build. Powered by Ultra, which handles routing, slippage, MEV protection, and transaction sending.\nVideo walkthrough + source code: Watch the video walkthrough and grab the demo app source code on GitHub.\n\n​Prerequisites\nNo API key or RPC node required. Jupiter Plugin handles all infrastructure.\nFor framework-based apps, you need Node.js and npm installed from nodejs.org. For plain HTML, you just need a browser.\n\n​Quick start\nThe simplest way to add a swap widget: a single HTML file:\n<!DOCTYPE html>\n<html>\n<head>\n <script src=\"https://plugin.jup.ag/plugin-v1.js\" data-preload defer></script>\n</head>\n<body>\n <h1>My App</h1>\n <div id=\"jupiter-plugin\"></div>\n <script>\n window.onload = function() {\n window.Jupiter.init({\n displayMode: \"integrated\",\n integratedTargetId: \"jupiter-plugin\",\n });\n };\n </script>\n</body>\n</html>\n\nSave this as swap.html, serve it locally, and open it in your browser:\nnpx http-server -o /swap.html\n\n​Try it yourself\nNot ready to write code? The Plugin Playground lets you experience the full swap widget live in your browser. Switch display modes, set token defaults, tweak colours, and copy the generated code when you’re ready to integrate.\n\n​When you need this\nYou want to add swap functionality to your app or website without building any of it yourself:\n\nApp with swap: Your app needs token swaps but you don’t want to build the UI, handle transactions, or run an RPC node.\nCommunity token site: Let your community buy your token directly on your website by locking the output mint with fixedMint.\nQuick swap access: Add a floating widget to any page for convenient swapping.\n\nCommon searches that lead here:\n\n“embed swap widget solana”\n“add token swap to my website”\n“jupiter plugin integration”\n“buy token widget solana”\n“solana swap widget no backend”\n“drop-in swap component solana”\n“add jupiter swap to react app”\n“token swap widget html”\n\n​Why Jupiter Plugin\nBuilding a swap interface from scratch means:\n\nRunning an RPC node\nIntegrating a wallet adapter\nBuilding the swap UI\nHandling quoting, routing, slippage, and MEV protection\nManaging transaction errors and retries\n\nJupiter Plugin handles all of this. You get the full jup.ag swap experience as a drop-in component:\n\nNo RPC: Powered by Ultra, which handles all transaction sending.\nNo wallet code: Plugin provides wallet connection out of the box (users connect their existing browser wallet like Phantom or Backpack).\nNo UI to build: Complete swap interface with token search, price display, and transaction status.\nNo error handling: Plugin manages slippage, retries, and transaction failures.\n\n​Code examples\nAdd the plugin script to your page, then call window.Jupiter.init(). Here’s a complete working example for each framework:\n<!DOCTYPE html>\n<html lang=\"en\">\n<head>\n <meta charset=\"UTF-8\">\n <meta name=\"viewport\" content=\"width=device-width, initial-scale=1.0\">\n <title>Jupiter Plugin Demo</title>\n <script src=\"https://plugin.jup.ag/plugin-v1.js\" data-preload defer></script>\n</head>\n<body>\n <h1>Jupiter Plugin Demo</h1>\n <div id=\"jupiter-plugin\"></div>\n\n <script>\n window.onload = function() {\n window.Jupiter.init({\n displayMode: \"integrated\",\n integratedTargetId: \"jupiter-plugin\",\n });\n };\n </script>\n</body>\n</html>\nimport { useEffect } from \"react\";\n\n// Add to public/index.html <head>:\n// <script src=\"https://plugin.jup.ag/plugin-v1.js\" data-preload defer></script>\n\nexport default function App() {\n useEffect(() => {\n window.Jupiter.init({\n displayMode: \"integrated\",\n integratedTargetId: \"jupiter-plugin\",\n });\n }, []);\n\n return (\n <div>\n <h1>Jupiter Plugin Demo</h1>\n <div id=\"jupiter-plugin\" />\n </div>\n );\n}\n\"use client\";\nimport { useEffect } from \"react\";\nimport Script from \"next/script\";\n\nexport default function SwapPage() {\n return (\n <>\n <Script\n src=\"https://plugin.jup.ag/plugin-v1.js\"\n data-preload\n strategy=\"afterInteractive\"\n onReady={() => {\n window.Jupiter.init({\n displayMode: \"integrated\",\n integratedTargetId: \"jupiter-plugin\",\n });\n }}\n />\n <h1>Jupiter Plugin Demo</h1>\n <div id=\"jupiter-plugin\" />\n </>\n );\n}\n\nFor a full step-by-step walkthrough with TypeScript support and project setup:\n\n​Configuration\n​Display modes\nJupiter Plugin offers three display modes:\nModeDescriptionUse caseintegratedEmbeds directly in your page layoutDedicated swap page or sectionwidgetFloating button that expands to a swap formQuick access on any pagemodalPopup overlay triggered by your appOn-demand swap without layout changes\n// Integrated: renders inside a target element\nwindow.Jupiter.init({\n displayMode: \"integrated\",\n integratedTargetId: \"jupiter-plugin\", // ID of your container div\n});\n\n// Widget: floating in a corner\nwindow.Jupiter.init({\n displayMode: \"widget\",\n widgetStyle: {\n position: \"bottom-right\", // bottom-left, bottom-right, top-left, top-right\n size: \"default\", // sm, default\n },\n});\n\n// Modal: popup overlay\nwindow.Jupiter.init({\n displayMode: \"modal\",\n});\n\n​Form props\nPre-configure the swap form with formProps:\nwindow.Jupiter.init({\n displayMode: \"integrated\",\n integratedTargetId: \"jupiter-plugin\",\n formProps: {\n initialInputMint: \"So11111111111111111111111111111111111111112\", // SOL\n initialOutputMint: \"JUPyiwrYJFskUPiHa7hkeR8VUtAeFoSYbKedZNsDvCN\", // JUP\n initialAmount: \"1\",\n fixedMint: \"JUPyiwrYJFskUPiHa7hkeR8VUtAeFoSYbKedZNsDvCN\", // Lock output to JUP\n fixedAmount: false,\n },\n});\n\nPropTypeDescriptioninitialInputMintstringPre-select the input token (mint address)initialOutputMintstringPre-select the output token (mint address)initialAmountstringPre-fill the swap amountfixedMintstringLock one side of the swap to a specific tokenfixedAmountbooleanPrevent users from changing the amountswapModestring\"ExactIn\", \"ExactOut\", or \"ExactInOrOut\" (default)\nCommunity token site example: Let your community buy your token directly:\nwindow.Jupiter.init({\n displayMode: \"integrated\",\n integratedTargetId: \"jupiter-plugin\",\n formProps: {\n initialOutputMint: \"YOUR_TOKEN_MINT_ADDRESS\",\n fixedMint: \"YOUR_TOKEN_MINT_ADDRESS\",\n },\n});\n\n​Wallet passthrough\nIf your app already has a wallet provider (e.g. via @solana/wallet-adapter), you can pass the wallet state through to Plugin instead of having users connect twice:\nwindow.Jupiter.init({\n displayMode: \"integrated\",\n integratedTargetId: \"jupiter-plugin\",\n enableWalletPassthrough: true,\n});\n\n// Sync wallet state when it changes\nwindow.Jupiter.syncProps({\n passthroughWalletContextState: walletContextState,\n});\n\nIf you don’t enable passthrough, Plugin provides its own wallet connection. Users connect their browser wallet (Phantom, Backpack, etc.) directly through the widget.\n​Referral fees\nEarn fees on swaps through the Jupiter Referral Program:\nwindow.Jupiter.init({\n displayMode: \"widget\",\n formProps: {\n referralAccount: \"YOUR_REFERRAL_ACCOUNT\",\n referralFee: 50, // Basis points (50 = 0.5%)\n },\n});\n\n​Branding\nAdd your logo and name to the Plugin:\nwindow.Jupiter.init({\n displayMode: \"widget\",\n branding: {\n logoUri: \"https://your-app.com/logo.png\",\n name: \"Your App\",\n },\n});\n\n​Colour theme\nCustomise colours via CSS variables in your global stylesheet:\n:root {\n --jupiter-plugin-primary: 199, 242, 132;\n --jupiter-plugin-background: 0, 0, 0;\n --jupiter-plugin-primaryText: 232, 249, 255;\n --jupiter-plugin-warning: 251, 191, 36;\n --jupiter-plugin-interactive: 33, 42, 54;\n --jupiter-plugin-module: 16, 23, 31;\n}\n\n​Event handling\nTrack swap results in your app:\nwindow.Jupiter.init({\n displayMode: \"widget\",\n onSuccess: ({ txid, swapResult, quoteResponseMeta }) => {\n console.log(\"Swap successful:\", txid);\n },\n onSwapError: ({ error, quoteResponseMeta }) => {\n console.error(\"Swap failed:\", error);\n },\n});\n\n​Common questions\nDo I need an API key or RPC node?No. Jupiter Plugin handles all infrastructure through Ultra. No API key, no RPC node, no backend required.Can I lock the swap to a specific token?Yes. Use formProps.fixedMint to lock one side of the swap to a specific token mint address. Combine with fixedAmount to also lock the amount (useful for payment flows).How do users connect their wallet?Plugin provides wallet connection out of the box. Users click the connect button in the widget and select their browser wallet (Phantom, Backpack, etc.). If your app already has a wallet provider, use enableWalletPassthrough to avoid a double connection.How do I test before deploying?Use the Plugin Playground to experiment with display modes, form props, and colour themes. It generates the configuration code for you.Why does integrated mode have no height?The integrated mode container needs a fixed height. Set it on your target div:<div id=\"jupiter-plugin\" style=\"height: 600px;\"></div>\n\n​Next steps\n\nPlugin Playground: Experiment with configuration and get code snippets.\nCustomisation Reference: Full configuration options and TypeScript types.\nFramework Walkthroughs: Step-by-step guides for Next.js, React, and HTML.\nReferral Program: Earn fees on swaps through your integration.\nJupiter Dev Notifications: Plugin updates and announcements.\nWas this page helpful?","tokens":2295,"squid":"spider-02","role":"Liquidity Spider","at":1791345491851,"hash":"d94b2ae0298081b62133f024426e11a774810922"}
{"url":"https://developers.jup.ag/docs/swap/advanced/compute-units","domain":"developers.jup.ag","title":"Compute Units & Priority Fees - Jupiter Developers","text":"The /build response includes computeBudgetInstructions with the compute unit price but not the compute unit limit. You need to simulate to determine the correct limit.\nWhy: since you are building your own transaction with custom instructions, the CU usage will differ from a base swap. The simulation gives you the actual number, and you set the limit with a safety buffer.\n​Why this matters\nPriority fee cost is calculated as:\npriority fee = compute unit price × compute unit limit\n\nA tighter CU limit directly reduces the priority fee you pay. Setting it to the maximum (1,400,000) when you only use 200,000 means you pay 7x more than necessary. See Solana fee structure for details.\n​Customise compute unit price\nThe /build response bakes a compute unit price into computeBudgetInstructions based on recent network priority fees. Use computeUnitPricePercentile to control how aggressively you bid:\nValuePercentileUse case\"medium\"25thLower fees, may land slower during congestion\"high\"50thBalanced (default)\"veryHigh\"75thHigher fees, better chance of landing quicklyInteger 0-10000Custom (in bps)Fine-grained control\nWhen mode=fast is set and no computeUnitPricePercentile is provided, the default is the 90th percentile instead of the 50th.\nYou can also override entirely by replacing the computeBudgetInstructions from the response with your own setComputeUnitPrice instruction.\n​Cap the compute unit price\nThe estimated compute unit price tracks recent network priority fees. When recent blocks contain transactions bidding extreme values, the estimate can spike far above what is needed to land. Validate the compute unit price before signing.\nDecode the compute unit price from the setComputeUnitPrice instruction in computeBudgetInstructions and clamp it to your own maximum. The instruction data is base64: a 1-byte discriminator (3 for setComputeUnitPrice) followed by the price as a little-endian u64 in micro-lamports.\nOn transaction v1, computeBudgetInstructions is empty, so this loop is a no-op. The price comes back in the computeUnitPrice field instead: clamp that value before converting it to priorityFeeLamports.\nconst COMPUTE_BUDGET_PROGRAM = 'ComputeBudget111111111111111111111111111111';\nconst MAX_CUP_MICRO_LAMPORTS = 10_000_000n; // set your own maximum\n\nfor (const ix of build.computeBudgetInstructions) {\n if (ix.programId !== COMPUTE_BUDGET_PROGRAM) continue;\n const data = Buffer.from(ix.data, 'base64');\n if (data[0] !== 3) continue; // 3 = setComputeUnitPrice\n const cup = data.readBigUInt64LE(1);\n if (cup > MAX_CUP_MICRO_LAMPORTS) {\n data.writeBigUInt64LE(MAX_CUP_MICRO_LAMPORTS, 1);\n ix.data = data.toString('base64');\n }\n}\n\nRun this on the raw /build response before converting the instructions for your SDK, so the same check works with both @solana/kit and @solana/web3.js. With the clamp in place, your worst-case priority fee is bounded: CUP cap × CU limit. A lower cap can slow landing during congestion, so pick a maximum that matches the fees you are willing to pay.\nIf you already maintain your own priority fee estimate, you can skip the decode: drop the returned computeBudgetInstructions and set your own setComputeUnitPrice with the lower of your estimate and your cap. A low computeUnitPricePercentile is not a substitute for a cap, because a percentile of an inflated fee distribution can still be extreme.\n​Estimate compute unit limit\n\nBuild the transaction with all your instructions + max CU limit (1,400,000)\nSimulate with replaceRecentBlockhash: true to get actual CU consumed\nRebuild with 1.2x the simulated value (capped at 1,400,000) as the CU limit\nAdd the CU price instruction from the /build response\n\nThe Build code example demonstrates this in steps 4-5 (kit) with full working code.\nSetting the CU limit too tight causes transaction failures. Always use at least a 1.2x buffer over the simulated value.\n​Related\n\nBuild for the full code example with CU simulation\nTransaction Submission to submit via Jupiter’s transaction landing infrastructure with SOL tips for priority processing\nReduce Transaction Size for other optimisations\nWas this page helpful?","tokens":1029,"squid":"spider-02","role":"Liquidity Spider","at":1791345503193,"hash":"f5c7535a234873000507acb5e0fb65da77edc25c"}
{"url":"https://www.metaplex.com/docs/smart-contracts/mpl-distro/updates","domain":"metaplex.com","title":"Update an MPL-Distro Distribution","text":"The current MPL-Distro authority can change selected distribution fields without creating a new PDA or invalidating existing claim receipts. SummaryupdateDistribution applies authority-approved configuration changes to an existing distribution.Change the full allocation configuration only outside the active claim window.Change operational fields such as authority and permissioned distributor during claims.Treat an authority change as immediate and security-sensitive.Publish replacement Merkle proofs atomically with any root update.Quick StartUpdating an MPL-Distro distribution is a signed configuration change on the existing account.Confirm whether the cluster time is inside the inclusive startTime–endTime window.Pass only the fields that should change to updateDistribution.If the Merkle root changes, replace every off-chain proof at the same time.Verify the stored authority and permissioned distributor after confirmation.MPL-Distro Update PermissionsThe current authority must sign every distribution update.FieldBefore startDuring active windowAfter endmerkleRootYesNoYestreeHeightYesNoYesstartTimeYesNoYesendTimeYesYesYestotalClaimantsYesNoYesnewAuthorityYesYesYesnameYesYesYesnewPermissionedDistributorYesYesYesThe active window includes both boundary timestamps. The protected allocation fields are locked when startTime <= clusterTime <= endTime.Root Updates Require Matching ProofsChanging the Merkle root invalidates every proof generated for the previous root. Publish and preserve the replacement allocation file atomically with the on-chain update.Update MPL-Distro ConfigurationPass only the fields that should change to updateDistribution.updateDistribution.ts1import { mplDistro, updateDistribution } from '@metaplex-foundation/mpl-distro'\n2import { publicKey } from '@metaplex-foundation/umi'\n3import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n4\n5const umi = createUmi(\n6 process.env.RPC_URL ?? 'https://api.devnet.solana.com'\n7).use(mplDistro())\n8\n9const distributionAddress = process.env.DISTRIBUTION_ADDRESS!\n10const newEndTimestamp = Math.floor(Date.now() / 1000) + 14 * 24 * 60 * 60\n11const newDistributorAddress = process.env.PERMISSIONED_DISTRIBUTOR!\n12\n13await updateDistribution(umi, {\n14 distribution: publicKey(distributionAddress),\n15 endTime: BigInt(newEndTimestamp),\n16 name: 'Extended community distribution',\n17 newPermissionedDistributor: publicKey(newDistributorAddress),\n18}).sendAndConfirm(umi)\n19\n20// The distribution end time, name, and permissioned distributor are updated.\nWhen totalClaimants changes without an explicit treeHeight, the program infers a minimum height. Passing the treeHeight returned by the newly prepared tree is clearer and avoids coupling the update to claimant-count inference.Change the Distribution AuthorityupdateDistribution replaces the signer that can update, deposit, withdraw tokens, and withdraw subsidy.changeDistributionAuthority.ts1import { mplDistro, updateDistribution } from '@metaplex-foundation/mpl-distro'\n2import { publicKey } from '@metaplex-foundation/umi'\n3import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n4\n5const umi = createUmi(\n6 process.env.RPC_URL ?? 'https://api.devnet.solana.com'\n7).use(mplDistro())\n8\n9const distribution = publicKey(process.env.DISTRIBUTION_ADDRESS!)\n10const currentAuthority = umi.identity\n11const nextAuthority = publicKey(process.env.NEXT_AUTHORITY!)\n12\n13await updateDistribution(umi, {\n14 distribution,\n15 authority: currentAuthority,\n16 newAuthority: nextAuthority,\n17}).sendAndConfirm(umi)\n18\n19// Subsequent deposits, withdrawals, and updates require the new authority.\nThe new authority does not need to sign the update. Verify the destination public key and make sure its signing infrastructure is operational before submitting the change.Change the Permissioned DistributorupdateDistribution changes the signer accepted for distributions configured with AllowedDistributor.Permissioned. Pass newPermissionedDistributor on updateDistribution.The change does not alter the Merkle tree or existing receipts. In-flight transactions signed by the previous distributor fail after the update lands.Update ErrorsUpdate errors protect authority and timing constraints.ErrorMeaningResolutionDistributionStartedA protected allocation field was changed during the active windowWait until the distribution ends or leave the field unchangedInvalidDistributionAuthorityThe supplied signer is not the stored authorityUse the current authorityInvalidTreeHeightTree height exceeds the maximumUse a value at or below 64NameTooLongUTF-8 name exceeds 32 bytesShorten the distribution nameNotesConfiguration changes affect proof validity and operational authority immediately after confirmation.Changing endTime during an active window can extend or shorten the claim period.A post-window root update does not remove existing claim receipts.Existing receipts remain keyed to the distribution PDA after an update.FAQCan the authority change the Merkle root during the active window?No. The root, tree height, start time, and claimant count are locked throughout the active window but can be changed before it starts or after it ends.Can the claim end time be extended during an active distribution?Yes. The authority may update endTime while the distribution is active.Does the new authority need to sign an authority change?No. Only the current authority signs updateDistribution. Verify the destination key before submitting.","tokens":1370,"squid":"spider-10","role":"Tooling Spider","at":1791345505911,"hash":"3af24bfb6535b693e6a2170c0416734594957e84"}
{"url":"https://consensysdiligence.github.io/smart-contract-best-practices/development-recommendations/solidity-specific/fallback-functions/","domain":"consensysdiligence.github.io","title":"Fallback Functions - Ethereum Smart Contract Best Practices","text":"Fallback Functions\n\nTip\nFor comprehensive insights into secure development practices, consider visiting the Development Recommendations section of the Smart Contract Security Field Guide. This resource provides in-depth articles to guide you in developing robust and secure smart contracts.\n\nKeep fallback functions simple¶\nFallback functions are\ncalled when a contract is sent a message with no arguments (or when no function matches), and only\nhas access to 2,300 gas when called from a .send() or .transfer(). If you wish to be able to\nreceive Ether from a .send() or .transfer(), the most you can do in a fallback function is log\nan event. Use a proper function if a computation of more gas is required.\n// bad\nfunction() payable { balances[msg.sender] += msg.value; }\n\n// good\nfunction deposit() payable external { balances[msg.sender] += msg.value; }\n\nfunction() payable { require(msg.data.length == 0); emit LogDepositReceived(msg.sender); }\n\nCheck data length in fallback functions¶\nSince the\nfallback functions is\nnot only called for plain ether transfers (without data) but also when no other function matches,\nyou should check that the data is empty if the fallback function is intended to be used only for\nthe purpose of logging received Ether. Otherwise, callers will not notice if your contract is used\nincorrectly and functions that do not exist are called.\n// bad\nfunction() payable { emit LogDepositReceived(msg.sender); }\n\n// good\nfunction() payable { require(msg.data.length == 0); emit LogDepositReceived(msg.sender); }","tokens":385,"squid":"spider-06","role":"Security Spider","at":1791345509580,"hash":"28c400cc21ccb65cd6fd4be85875865548484622"}
{"url":"https://developers.jup.ag/docs/swap/advanced/reduce-latency","domain":"developers.jup.ag","title":"Reduce Latency - Jupiter Developers","text":"Set mode=fast on /build to reduce routing latency at the cost of quote optimality.\nGET /build?inputMint=...&outputMint=...&amount=...&taker=...&mode=fast\n\nThe feature mode=fast on /build is new and in BETA. Note that there may be changes to the implementation as we continue to improve and evaluate.\n​How it works\nFast mode optimises for speed in two ways:\n\nBellman-Ford with no splitting: the routing algorithm uses Bellman-Ford without splitting the route across multiple pools. This reduces computation time significantly, at the cost of potentially missing better multi-pool routes.\nParallel priority fee lookup: the getRecentPriorityFee RPC call runs in parallel with the call to Metis routing engine to get the swap instructions, instead of sequentially. This eliminates the RPC round-trip from the critical path.\n\nWhen the getRecentPriorityFee is done in parallel and not sequentially, this can impact the final priority fee estimation.When done sequentially, the Metis routing result provides the writable accounts (hot accounts/local fee market) that we will use in getRecentPriorityFee to further estimate accurately.When done parallelly, those accounts are not yet known, hence getRecentPriorityFee will estimate globally based on global fees.\n​When to use\n\nYou are swapping high-frequency and need low latency\nThe pair is well-known (e.g. SOL/USDC) and doesn’t benefit from complex routing\nYou are building a trading bot where speed matters more than optimising the last basis point\n\n​Trade-offs\nFast mode may return suboptimal pricing compared to the default mode because:\n\nLess accurate priority fee estimation as mentioned above\nNo route splitting means the entire amount goes through a single pool path\nFewer route combinations are explored\n\nFor most major pairs and typical sizes, the pricing difference is negligible. For large swaps or illiquid pairs, the default mode will find better routes.\n​Related\n\nReduce Transaction Size for controlling account count\nBuild for the full /build workflow\nTransaction Submission to submit via Jupiter’s transaction landing infrastructure with SOL tips for priority processing\nWas this page helpful?","tokens":539,"squid":"spider-02","role":"Liquidity Spider","at":1791345515275,"hash":"ec937c15eca174fd2cb13d98b39da0b582275ecd"}
{"url":"https://www.metaplex.com/docs/smart-contracts/mpl-distro","domain":"metaplex.com","title":"MPL-Distro - Merkle Token Claims and Airdrops on Solana","text":"MPL-Distro is a Solana program that distributes an existing SPL token to a list of wallets or legacy NFT holders. It stores a compact Merkle root on-chain instead of the full recipient list. SummaryMPL-Distro commits a recipient list as one on-chain Merkle root, holds the tokens in a vault, and records each successful claim so it cannot be reused.Distribute an existing SPL token mint without storing the full recipient list on-chain.Target wallet addresses or current holders of specific legacy NFT mints.Choose permissionless, recipient-only, or permissioned claim submission.Recover unclaimed tokens and unused receipt-rent subsidies after the claim window.Build a DistributionCreate, fund, and claim from a wallet distribution.Deliver Claims in ProductionStore proofs, run a claim page or API, and recover unclaimed tokens.Choose a Distribution TypeCompare wallet and legacy NFT allocation models.CLICreate, fund, inspect, and recover distributions from the terminal.MPL-Distro Distribution ModelA Merkle tree turns the recipient list into one 32-byte hash (the root). Each recipient later proves they are on that list with a short proof, so the full list never has to live on-chain.The distribution authority builds an off-chain list containing each recipient, amount, and optional nonce.prepareDistribution creates the Merkle root and one proof per allocation.createDistribution stores the root, claim window, mint, and access rules.deposit transfers the full token allocation to the distribution's associated token account.distribute or distributeToLegacyNft verifies a proof and creates a permanent claim receipt.withdraw returns unclaimed tokens after the distribution is inactive.Store the Claim DataThe program stores only the Merkle root, not the recipient list or proofs. Preserve each allocation's address, amount, nonce, and proof in a database or downloadable claim file.MPL-Distro Distribution TypesMPL-Distro supports wallet-address allocations and legacy NFT-mint allocations through separate claim instructions.Distribution typeMerkle leaf identityClaim instructionBest forWalletWallet or other public keydistributeAllowances, contributor rewards, and direct token airdropsLegacyNftLegacy NFT mintdistributeToLegacyNftRewards claimed by the NFT's current token-account ownerThe LegacyNft type pays the wallet that currently owns a listed NFT mint. See Legacy NFT Distribution for which NFTs qualify and how ownership is checked.MPL-Distro Allowed Distributor ModesThe allowed distributor mode controls who may submit a valid Merkle claim transaction.ModeRequired signerBehaviorPermissionlessAny payerA service or third party can submit claims on behalf of recipientsRecipientRecipient wallet or legacy NFT ownerThe beneficiary must approve the claimPermissionedConfigured distributorOnly one designated distributor may submit claimsPermissionless submission does not redirect tokens: the program always sends the allocation to the recipient's canonical associated token account.MPL-Distro Protocol FeesA successful Merkle claim charges a protocol fee, paid by the claim transaction payer.InstructionSolanadistribute / distributeToLegacyNft0.002 SOL** Receipt subsidies do not cover this fee.See Protocol Fees for the current amounts across Metaplex programs.NotesMPL-Distro's on-chain checks protect claims but do not replace off-chain allocation validation.totalClaimants is metadata and does not cap the number of valid proofs.Deposits are not checked against the sum of all Merkle allocations; fund the vault with enough tokens before claims begin.Claim receipts are not closed, so their rent remains allocated.The program targets the original SPL Token program rather than Token-2022.MPL-Distro does not provide vesting, streaming, partial claims, or structured program events.FAQWhat is MPL-Distro used for?MPL-Distro distributes an existing SPL token allocation to a fixed list of wallet addresses or legacy NFT mints through Merkle proofs.Is MPL-Distro a token launchpad?No. MPL-Distro distributes an existing mint; use Genesis when you need a token generation event, sale, launch pool, or bonding curve.Can someone pay transaction fees for recipients?Yes. Permissionless distributions let any payer submit a valid claim for a recipient, while Recipient and Permissioned modes restrict who may submit it.Does MPL-Distro support vesting?No. MPL-Distro releases each Merkle allocation in one claim; use Genesis project vesting for schedule-based project allocations.GlossaryMPL-Distro uses Merkle proofs and deterministic accounts to verify and record token allocations.TermDefinitionDistributionProgram account containing the token mint, Merkle root, time window, authority, and claim totalsDistribution authorityThe wallet that can update configuration, deposit tokens, and recover unclaimed fundsMerkle treeOff-chain structure that produces the on-chain root and one proof per allocationMerkle rootA 32-byte commitment to the complete off-chain allocation listMerkle proofSibling hashes that prove one allocation belongs to the committed treeClaim receiptPDA proving one (distribution, recipient, amount, nonce) allocation was claimedNonceA number that distinguishes otherwise identical recipient and amount leavesToken base unitsSmallest mint denomination; a 6-decimal token uses 1_000_000 units per 1.0 tokenReceipt subsidyOptional SOL held by the distribution PDA to reimburse claim-receipt rent","tokens":1357,"squid":"spider-10","role":"Tooling Spider","at":1791345515860,"hash":"506788fb6acb11d682773884acd0b11bdf2ce480"}
{"url":"https://consensysdiligence.github.io/smart-contract-best-practices/development-recommendations/solidity-specific/extcodesize-checks/","domain":"consensysdiligence.github.io","title":"EXTCODESIZE Checks - Ethereum Smart Contract Best Practices","text":"EXTCODESIZE Checks\n\nTip\nFor comprehensive insights into secure development practices, consider visiting the Development Recommendations section of the Smart Contract Security Field Guide. This resource provides in-depth articles to guide you in developing robust and secure smart contracts.\n\nAvoid using extcodesize to check for Externally Owned Accounts.\nThe following modifier (or a similar check) is often used to verify whether a call was made from an\nexternally owned account (EOA) or a contract account:\n// bad\nmodifier isNotContract(address _a) {\n uint size;\n assembly {\n size := extcodesize(_a)\n }\n require(size == 0);\n _;\n}\n\nThe idea is straightforward: if an address contains code, it's not an EOA but a contract account.\nHowever, a contract does not have source code available during construction. This means that\nwhile the constructor is running, it can make calls to other contracts, but extcodesize for its\naddress returns zero. Below is a minimal example that shows how this check can be circumvented:\ncontract OnlyForEOA { \n uint public flag;\n\n // bad\n modifier isNotContract(address _a){\n uint len;\n assembly { len := extcodesize(_a) }\n require(len == 0);\n _;\n }\n\n function setFlag(uint i) public isNotContract(msg.sender){\n flag = i;\n }\n}\n\ncontract FakeEOA {\n constructor(address _a) public {\n OnlyForEOA c = OnlyForEOA(_a);\n c.setFlag(1);\n }\n}\n\nBecause contract addresses can be pre-computed, this check could also fail if it checks an address\nwhich is empty at block n, but which has a contract deployed to it at some block greater than\nn.\n\nThis issue is nuanced.\nIf your goal is to prevent other contracts from being able to call your contract, the extcodesize check is probably sufficient. An alternative approach is to check the value of (tx.origin == msg.sender), though this also has drawbacks.\nThere may be other situations in which the extcodesize check serves your purpose. Describing all of them here is out of scope. Understand the underlying behaviors of the EVM and use your judgement.","tokens":504,"squid":"spider-06","role":"Security Spider","at":1791345519482,"hash":"cb76314637282f5a0ae4ca700dd92708f1b7082b"}
{"url":"https://developers.jup.ag/docs/swap/advanced/reduce-transaction-size","domain":"developers.jup.ag","title":"Reduce Transaction Size - Jupiter Developers","text":"When building custom transactions with /build, you may hit the 1232-byte transaction size limit, especially when adding custom instructions alongside the swap. Two techniques help.\nRequesting a Solana v1 transaction (transactionVersion=1) raises the size limit to 4096 bytes and inlines up to 64 accounts without Address Lookup Tables. If your constraint is size, v1 is often the simpler fix than the techniques below.\n​Limit accounts with maxAccounts\nSet maxAccounts (1-64, default 64) to limit the number of accounts in the swap route. Lower values produce simpler routes with fewer accounts.\nGET /build?...&maxAccounts=20\n\nUse this when:\n\nYour transaction already has many accounts from custom instructions\nYou are hitting the transaction size limit\nYou need room for CPI accounts\n\nSetting maxAccounts too low will severely degrade routing quality. Very low values (e.g below 50) can result in no route found or significantly worse pricing, because the router cannot access enough DEXes or split the route across multiple pools. Start with a moderate reduction (e.g. reducing 2 and retry) and test pricing impact before going lower.\n​Remove no-op setup instructions\nThe /build response always includes createAssociatedTokenAccountIdempotent instructions in setupInstructions, even when the token accounts already exist. These are no-ops on existing accounts but still consume transaction space.\nTo reclaim that space:\n\nCheck onchain if the associated token accounts already exist\nIf they exist, omit those setup instructions from your transaction\nIf they don’t exist, keep the instructions\n\nThis technique requires an additional RPC call (getAccountInfo) per ATA you check. Depending on your RPC latency and how many ATAs the swap involves, this can add measurable overhead to your overall swap flow. Consider whether the space savings are worth the added latency for your use case, or batch the account checks in parallel or pre-swap.\nimport { findAssociatedTokenPda } from \"@solana-program/associated-token\";\nimport { TOKEN_PROGRAM_ADDRESS } from \"@solana-program/token\";\n\n// Assumes @solana/kit imports and rpc from build/index.mdx example\n\n// For each setup instruction, check if the target ATA already exists\n// If it does, the createIdempotent instruction is a no-op and can be removed\nconst outputAta = await findAssociatedTokenPda({\n mint: address(outputMint),\n owner: address(taker),\n tokenProgram: TOKEN_PROGRAM_ADDRESS,\n});\n\nconst accountInfo = await rpc.getAccountInfo(outputAta[0]).send();\nconst ataExists = accountInfo.value !== null;\n\n// If ATA exists, filter out the createIdempotent instruction for it\nconst filteredSetupInstructions = ataExists\n ? build.setupInstructions.filter((ix) => {\n // Skip instructions targeting the existing ATA\n // Match by checking if any account in the instruction is the ATA address\n return !ix.accounts.some(\n (acc) => acc.pubkey === outputAta[0] && acc.isWritable\n );\n })\n : build.setupInstructions;\n\n​Related\n\nBuild for the full /build workflow\nReduce Latency for faster routing\nRouting impact matrix for how parameters affect routing\nWas this page helpful?","tokens":778,"squid":"spider-02","role":"Liquidity Spider","at":1791345525375,"hash":"797068642c4353fcf5ab5d32eb5be1aa043bd269"}
{"url":"https://developers.jup.ag/docs/swap/advanced/slippage","domain":"developers.jup.ag","title":"Slippage Estimation - Jupiter Developers","text":"Slippage is the difference between the quoted output amount and what you actually receive. It depends on token pair volatility, trade size relative to pool liquidity, and time between quoting and execution.\nJupiter’s Real-Time Slippage Estimator (RTSE) estimates the optimal slippage tolerance for each swap, balancing trade success against price protection.\n​How RTSE works\nRTSE estimates slippage at order time (when you call /order or /build), not at execution time. The estimated slippage is baked into the transaction.\nRTSE uses a variety of heuristics, algorithms, and monitoring to estimate the best possible slippage:\n\nHeuristics: token categories, historical and real-time slippage data. Uses token categories to intelligently estimate slippage for different token types, with increased sensitivity for tokens with high historical volatility patterns.\nAlgorithms: Exponential Moving Average (EMA) on slippage data to smooth out noise and follow trends.\nMonitoring: real-time monitoring of failure rates to reactively increase slippage when necessary.\n\n​RTSE on Meta-Aggregator vs Router\nMeta-Aggregator (/order)Router (/build)RTSEAutomatic. Applied at order time.Opt-in. Pass slippageBps=rtse.DefaultRTSE (no param needed)slippageBps=50 (fixed 0.5%)OverridePass slippageBps for a fixed valuePass a number for fixed, or \"rtse\" for RTSE\n​Meta-Aggregator (automatic)\nOn the Meta-Aggregator path (/order), RTSE is applied automatically when the order is created. You do not need to set any slippage parameter. The estimated slippage is embedded in the transaction returned by /order.\nIf you pass slippageBps to /order, it overrides RTSE with a fixed value. Fixed slippageBps does not restrict /order to Metis-only routing by itself.\n​Router (opt-in)\nOn the Router path (/build), slippage defaults to 50 bps (0.5%). To enable RTSE, pass the literal string \"rtse\":\nGET https://api.jup.ag/swap/v2/build?inputMint=...&outputMint=...&amount=...&taker=...&slippageBps=rtse\n\nThe estimated slippage is reflected in otherAmountThreshold in the response.\n​When to use RTSE\nUse RTSE (recommended for most cases):\n\nYou want Jupiter to handle slippage optimisation for you\nYou are swapping tokens where the right slippage is hard to predict\nYou want to minimise failed transactions without overpaying on slippage\n\nUse a fixed slippageBps value when:\n\nYou want to accept more slippage to improve success rate, e.g. trading memecoins or exiting a position as quickly as possible\nYou are building a UI that lets users set their own slippage\nYou need deterministic behaviour for testing or simulation\n\n​Related\n\nRouting impact matrix: how optional parameters affect which routers are available\nOrder & Execute: the default swap flow where RTSE is automatic\nBuild: full transaction control, RTSE is opt-in via slippageBps=rtse\nWas this page helpful?","tokens":709,"squid":"spider-02","role":"Liquidity Spider","at":1791345537163,"hash":"48306aa4b1e196c389cbfefa8c33677e0dae8e93"}
{"url":"https://www.metaplex.com/docs/smart-contracts/mpl-distro/legacy-nft-distribution","domain":"metaplex.com","title":"Distribute Tokens to Legacy NFT Holders with MPL-Distro","text":"Legacy NFT distributions assign token allocations to NFT mint addresses and pay the wallet that owns each NFT when the claim executes. SummaryA LegacyNft distribution uses the legacy NFT mint as the Merkle leaf and verifies its current SPL token-account owner during distributeToLegacyNft.Build the allocation tree from NFT mint addresses rather than owner wallets.Create the distribution with DistributionType.LegacyNft.Send distributed tokens to the current owner's token account.Record the receipt against the NFT mint so an ownership transfer cannot enable a second claim.Legacy NFTs OnlyThis flow validates an original SPL Token account with balance one. Token Metadata NFTs and pNFTs on that token program qualify. It is not compatible with MPL Core assets or Token-2022 NFTs.Legacy NFT Allocation ModelEach allocation commits a legacy NFT mint address, token amount, and optional nonce.legacyNftAllocations.ts1import {\n2 DistributionType,\n3 mplDistro,\n4 prepareDistribution,\n5} from '@metaplex-foundation/mpl-distro'\n6import { publicKey } from '@metaplex-foundation/umi'\n7import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n8\n9const umi = createUmi(\n10 process.env.RPC_URL ?? 'https://api.devnet.solana.com'\n11).use(mplDistro())\n12\n13const nftMintA = publicKey(process.env.LEGACY_NFT_MINT_A!)\n14const nftMintB = publicKey(process.env.LEGACY_NFT_MINT_B!)\n15\n16const allocations = [\n17 { address: nftMintA, amount: 100_000n },\n18 { address: nftMintB, amount: 100_000n },\n19]\n20\n21const { root, proofs, treeHeight } = prepareDistribution(allocations)\n22\n23const distributionFields = {\n24 merkleRoot: root,\n25 treeHeight,\n26 totalClaimants: BigInt(allocations.length),\n27 distributionType: DistributionType.LegacyNft,\n28}\n29\n30console.log(distributionFields, proofs.length)\n31\n32// Root, treeHeight, and LegacyNft fields for createDistribution\nDo not build the leaves from snapshot owner wallets. The NFT mint is the stable identity that lets ownership transfer before a claim.Legacy NFT Ownership VerificationThe program verifies current ownership from the NFT's SPL token account at claim time.The supplied NFT token account must:Be owned by the original SPL Token program.Use the NFT mint committed in the Merkle leaf.Hold exactly one token.Be owned by the supplied nftOwner.The program does not call Token Metadata, Token Record, or Authorization Rules. It only checks the SPL token account listed above.Submit a Legacy NFT ClaimThe distributeToLegacyNft instruction verifies the mint proof and sends tokens to the current NFT owner's associated token account.claimLegacyNft.ts1import {\n2 distributeToLegacyNft,\n3 mplDistro,\n4 prepareDistribution,\n5} from '@metaplex-foundation/mpl-distro'\n6import { publicKey } from '@metaplex-foundation/umi'\n7import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n8\n9const umi = createUmi(\n10 process.env.RPC_URL ?? 'https://api.devnet.solana.com'\n11).use(mplDistro())\n12\n13// Default nftOwner to the Umi identity, or pass nftOwner explicitly\n14// for a sponsored claim.\n15\n16const distribution = publicKey(process.env.DISTRIBUTION_ADDRESS!)\n17const mint = publicKey(process.env.TOKEN_MINT!)\n18const nftMint = publicKey(process.env.LEGACY_NFT_MINT!)\n19const allocations = [{ address: nftMint, amount: 100_000n }]\n20const { proofs } = prepareDistribution(allocations)\n21\n22await distributeToLegacyNft(umi, {\n23 distribution,\n24 mint,\n25 nftMint,\n26 amount: allocations[0].amount,\n27 proof: proofs[0],\n28 nonce: 0,\n29}).sendAndConfirm(umi)\n30\n31// The current NFT owner's ATA receives 100000 base units.\n32// The receipt is keyed by the NFT mint, so the allocation cannot be claimed twice.\nWhen nftOwner is omitted, the SDK defaults it to the transaction payer and derives that payer's NFT token account. Supply nftOwner explicitly when a permissionless service pays on behalf of another owner.sponsoredLegacyNftClaim.ts1import {\n2 distributeToLegacyNft,\n3 mplDistro,\n4} from '@metaplex-foundation/mpl-distro'\n5import { publicKey } from '@metaplex-foundation/umi'\n6import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n7\n8const umi = createUmi(\n9 process.env.RPC_URL ?? 'https://api.devnet.solana.com'\n10).use(mplDistro())\n11\n12const airdropService = umi.payer\n13const distribution = publicKey(process.env.DISTRIBUTION_ADDRESS!)\n14const rewardMint = publicKey(process.env.TOKEN_MINT!)\n15const nftMint = publicKey(process.env.LEGACY_NFT_MINT!)\n16const currentOwner = publicKey(process.env.NFT_OWNER!)\n17const amount = 100_000n\n18const proof = []\n19const nonce = 0\n20\n21await distributeToLegacyNft(umi, {\n22 payer: airdropService,\n23 distribution,\n24 mint: rewardMint,\n25 nftMint,\n26 nftOwner: currentOwner,\n27 amount,\n28 proof,\n29 nonce,\n30}).sendAndConfirm(umi)\n31\n32// The current NFT owner's ATA receives the allocation.\nLegacy NFT Claim ReceiptThe legacy NFT receipt stores the NFT mint as its recipient identity.Receipt componentValueRecipient seedNFT mint, not owner walletDestinationCurrent owner's associated token account for the distributed mintOwnership transfer effectChanges who may receive an unclaimed allocationRepeat claim after transferRejected because the receipt remains tied to the NFT mintLegacy NFT Distribution Access ModesThe allowed distributor mode applies to the NFT owner rather than the NFT mint.ModeClaim signer requirementPermissionlessAny payer may submit for the verified current ownerRecipientThe current nftOwner must signPermissionedThe configured permissioned distributor must signUse Recipient when the current holder must opt in. Use Permissionless when a relayer can pay the claim for the verified current owner without that owner signing.Legacy NFT Snapshot ConsiderationsThe Merkle tree fixes eligible NFT mints while ownership remains dynamic until each mint claims.This distinction creates two common models:Mint eligibility model: Eligible NFT mints can claim regardless of later transfer, and the owner at claim time receives the reward.Owner snapshot model: Snapshot owner wallets instead and use a Wallet distribution when transfer after the snapshot must not move eligibility.Prevent Marketplace SurprisesPublish whether eligibility follows the NFT mint or the snapshot owner. A buyer can receive an unclaimed mint-based allocation, but cannot determine claim status from ownership alone; the application should check the claim receipt.NotesLegacy NFT distributions verify fungible token-account facts rather than complete NFT metadata semantics.Collection verification and NFT eligibility must happen before root generation.Frozen or delegated NFT token accounts still need application-level review.The reward token goes to the NFT owner's canonical associated token account.The current program does not close claim receipts after redemption.FAQWho receives an allocation after the NFT is transferred?The wallet that owns the NFT token account when the claim executes receives the allocation.Can a later NFT owner claim again?No. The claim receipt is keyed by the NFT mint, amount, and nonce, so ownership transfer does not reset it.Can this flow distribute tokens to MPL Core asset holders?No. LegacyNft validates SPL token-account ownership; Core assets require the Wallet distribution asset-signer pattern.Does LegacyNft work for pNFTs?Yes, when the pNFT token account is owned by the original SPL Token program and holds a balance of one. The program does not call Token Metadata, Token Record, or Authorization Rules. Token-2022 pNFTs are not supported.","tokens":1874,"squid":"spider-10","role":"Tooling Spider","at":1791345537210,"hash":"bb3f90bf661de124e3ae760b68a92758660ba201"}
{"url":"https://developer.arbitrum.io/launch-arbitrum-chain/chain-config","domain":"developer.arbitrum.io","title":"Configure your chain","text":"Configure your chainConfiguration options.Request an updateBatch posterConfiguration options for the batch poster.CostsCosts configuration options for your chain.Data availabilityData availability configuration options.ExecutionExecution options: smart contract size limit.SequencerSequencer configuration options for your chain.ValidationHow to configure validation for your chain.Configuration parametersA list of configuration parameters for your chain.chainConfig referenceReference list of chainConfig JSON parameters available when deploying or managing your Arbitrum chain.How is this guide?Deploy a production chain: an overviewLearn how to deploy and manage your Arbitrum chain with the Arbitrum chain SDK.Batch posterConfiguration options for the batch poster.","tokens":193,"squid":"spider-01","role":"Chain Spider","at":1791345540842,"hash":"e527b9aff6ab3e8af09350e0718bbdf738acddca"}
{"url":"https://developer.arbitrum.io/launch-arbitrum-chain/chain-config/sequencer","domain":"developer.arbitrum.io","title":"Sequencer","text":"Configure your chainSequencerSequencer configuration options for your chain.Request an updateChain finalityConfigure Delayed Inbox finality on your chain.Compliance filteringConfigure protocol-level transaction filtering to restrict sanctioned addresses on your chain.Sequencer configuration referenceSequencer flags, surplus thresholds, block production timing, and sequencer coordinator tuning.Sequencer timing adjustmentsConfigure sequencer timing adjustments for your chain.TimeboostGuidance and best practices for using Timeboost on your chain.PGAGuidance and best practices for using PGA on your chain.How is this guide?Configure smart contract size limitLearn how to configure the smart contract size limits on your Arbitrum chainHow to configure Delayed Inbox finalityLearn how to configure Delayed Inbox finality on your Arbitrum chain.","tokens":211,"squid":"spider-01","role":"Chain Spider","at":1791345553910,"hash":"829e8abda74926bf1b94247b0b1aebaf9c8289c5"}
{"url":"https://developer.arbitrum.io/launch-arbitrum-chain/chain-config/sequencer/sequencer-timing-adjustments","domain":"developer.arbitrum.io","title":"Configure Sequencer timing adjustments","text":"Configure your chainSequencerConfigure Sequencer timing adjustmentsLearn how to configure timing adjustments to the Sequencer for your Arbitrum chainRequest 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 , 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 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 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 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. 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 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';\n\nconst nodeConfig = await prepareNodeConfig({\n // Your deployment tx receipt or params\n // Override defaults here, e.g.:\n});\n// 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 \\\n offchainlabs/nitro-node:v3.12.1-70fa99a \\\n --conf.file=/config/nodeConfig.json \\\n --node.sequencer=true \\\n --execution.sequencer.enable=true \\\n # 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 or advanced features, additional setup (e.g., ) is needed.\nUnderstanding maxTimeVariation\nmaxTimeVariation is a four-field setting on the contract on the . 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 carrying that message is actually posted.\nstruct MaxTimeVariation {\n uint256 delayBlocks; // max parent-chain blocks in the past a message may be received\n uint256 futureBlocks; // max parent-chain blocks in the future a message may be received\n uint256 delaySeconds; // max parent-chain seconds in the past a message may be received\n uint256 futureSeconds; // max parent-chain seconds in the future a message may be received\n}\nThe four fields define a two-sided window around the current parent-chain block and time:\n\ndelayBlocks and delaySeconds bound the past —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 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 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 must wait before it can be , 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 , 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.How is this guide?Configuration referenceOperational guidance for sequencer flags, including expected surplus thresholds, block production timing, and sequencer coordinator tuning.Timeboost for Arbitrum chainsGuidance & best practices for using Timeboost on Arbitrum chains","tokens":3470,"squid":"spider-01","role":"Chain Spider","at":1791345563936,"hash":"fff02f30698cd5e4f7299423e813aaafdba5733f"}
{"url":"https://developer.arbitrum.io/launch-arbitrum-chain/chain-config/sequencer/timeboost","domain":"developer.arbitrum.io","title":"Timeboost for Arbitrum chains","text":"Configure your chainSequencerTimeboost for Arbitrum chainsGuidance & best practices for using Timeboost on Arbitrum chainsRequest an updatePUBLIC PREVIEW DOCUMENTThis document is currently in public preview and may change significantly as feedback is captured from readers like you. Click the Request an update button at the top of this document or join the Arbitrum Discord to share your feedback.\nNoteAEP fees will apply here in the future.\nLaunch status and key dates\n\nStatus: Alpha—not formally supported yet for deployments on \nArbitrum Sepolia: Feb 12, 2025\n: April 17, 2025\n: April 17, 2025\n\ntldr;\n is a novel ordering policy that can be optionally deployed and enabled for any Arbitrum chain. Timeboost allows a to capture some of the available Maximum Extractable Value (MEV) on their and reduces latency-related spamming, in exchange for a small impact on user response times (despite block times not changing). It is therefore recommended that chains only consider deploying and enabling Timeboost if there is substantial DeFi and related MEV activity (e.g., liquidations, arbitrage, backrunning) on the chain. Please read the gentle introduction to Timeboost to learn more about how Timeboost works.\nAs with all features on the Arbitrum stack, Arbitrum chains can adopt Timeboost at their own discretion and on their own timeline. To deploy and enable Arbitrum Timeboost on your chain, please refer to this guide on how to deploy and configure Timeboost.\nRecommended adoption path\nIt is recommended that most Arbitrum chains do not deploy Arbitrum Timeboost, as the benefits do not outweigh the trade-offs in most cases. The primary reason behind this recommendation is based on cost and user experience considerations. The only instances in which Timeboost might make sense are for chains with significant DeFi and related MEV activity, as the potential revenue from bids may outweigh the costs and possible impact on user experience.\nAgain, Arbitrum chains can adopt Timeboost at their discretion and on their timeline, so this is only a recommendation.\nBenefits of adopting Timeboost\nTimeboost enables a chain owner to capture a portion of the available MEV on their blockchain, reducing latency-related spam while preserving the built-in protections and UX benefits that Arbitrum users have come to know and enjoy. A more in-depth overview of the benefits of Timeboost is explored in the gentle introduction to Timeboost, and also a paper on how Timeboost is more profitable for arbitrageurs compared to other forms of MEV capture, like Priority Gas Auctions (PGA) here.\nFair(er) MEV capture\nTimeboost provides sophisticated actors (e.g., searchers) with the ability to purchase a fixed time advantage over a specified number of blocks to perform various MEV activities, such as backrunning, liquidations, or arbitrage. This design preserves the use of a private mempool that all Arbitrum chains have by default, and it does not impact block times. This approach protects users from harmful types of MEV (e.g., frontrunning) while maintaining the same block times.\nPotential revenue capture for chain owners\nThe auction, run at a fixed cadence, is held offchain. Bids can be made in any asset the chain owner designates, including custom ERC-20 tokens. Furthermore, the chain owner has full discretion over how to use the bid proceeds. For example, chain owners may decide to burn the bid proceeds or use the bid proceeds to support the chain in other ways.\nIt stands to reason that sophisticated actors (e.g., searchers) will bid up to the amount they believe they can profit or realize from the time advantage. Therefore, at equilibrium, one could reasonably expect that the bid proceeds will approach or equal the amount of available MEV on a Timeboost-enabled chain.\nPotential reduction in latency-based spam\nAs explained earlier, searchers will be incentivized to bid onchain for the time advantage, rather than spending money on offchain hardware to win latency races. Therefore, at equilibrium, one could reasonably expect that the amount of latency-based spam should reduce on a Timeboost-enabled chain. To learn more about this phenomenon, please check out this analysis on how the Timeboost ordering policy impacts backrunning strategies: TimeBoost and Backrunning: Probabilistic Strategies.\nTrade offs with adopting Timeboost\nAs mentioned earlier, chain owners should consider several trade-offs when deciding whether to adopt Timeboost. We will cover two of them below.\nCost\nAs explained in the guide on how to deploy and configure Timeboost, there are are three core components to Timeboost:\n\nAn offchain auctioneer (responsible for receiving and validating bids, and resolving auctions),\nAn onchain (to manage the Express Lane auction), and\nA new configuration on the Sequencer is implemented to take advantage of the Express Lane time.\n\nOften times, the cost required to set up, configure, and maintain the infrastructure above (especially the auctioneer) will exceed that of the potential revenue that Timeboost brings in. Most importantly, the revenue that Timeboost can generate for the chain is not guaranteed either.\nUser experience\nAs explained in the gentle introduction to Timeboost, the Timeboost Express Lane time advantage is implemented by imposing an artificial delay (default: 200ms) on all non-express lane transactions whenever there is an for a round (default: 1 minute). While Timeboost does not change the default Arbitrum blocktimes (default: 250ms), this artificial delay does mean that the average response time for a user in the non-express lane is the sum of the artificial delay and the block time of the chain. Note that this artificial delay is only applied when there is an express lane controller for a round, meaning there is no change in user experience if nobody is using Timeboost, even though it is enabled (for the duration of that round).\nEnabling Timeboost for your Arbitrum chain\nThis guide walks you through the process of enabling Timeboost for your Arbitrum chain. For a conceptual introduction to Timeboost, see the Timeboost Introduction.\nPrerequisites\nBefore starting, ensure you have:\n\nAn ERC-20 token address to use as the bid token\nA Redis server for auctioneer coordination\nA server to run the auctioneer service\nA proxy admin contract address\n\nOverview\nEnabling Timeboost requires completing these three steps:\n\nDeploy the ExpressLaneAuction contract\nRun Auctioneer Services (bid and auction server)\nConfigure your sequencer node to support Timeboost\n\nStep 1: Deploy the ExpressLaneAuction contract\nFirst, clone the chain-actions repository:\ngit clone https://github.com/OffchainLabs/chain-actions.git\ncd chain-actions/scripts/foundry/timeboost\nCreate and edit the environment configuration file:\ncp .env.sample .env\nConfigure the following parameters in your .env file:\n## Configuration for DeployExpressLaneAuction.s.sol\nPROXY_ADMIN_ADDRESS= # Your proxy admin contract address\nAUCTIONEER_ADDRESS= # Address that will send resolve auction requests\nBIDDING_TOKEN_ADDRESS= # Your ERC20 bid token address\nBENEFICIARY_ADDRESS= # Address to receive bid proceeds\nAUCTIONEER_ADMIN_ADDRESS= # Admin address for the auctioneer\nMIN_RESERVE_PRICE_SETTER_ADDRESS= # Address allowed to set minimum reserve price\nRESERVE_PRICE_SETTER_ADDRESS= # Address allowed to set reserve price\nRESERVE_PRICE_SETTER_ADMIN_ADDRESS= # Admin for reserve price setter\nBENEFICIARY_SETTER_ADDRESS= # Address allowed to change beneficiary\nROUND_TIMING_SETTER_ADDRESS= # Address allowed to adjust round timing\nMASTER_ADMIN_ADDRESS= # Master admin address\n\nMIN_RESERVE_PRICE=0 # Minimum price for bids (0 recommended for testing)\n\n# Round timing configuration (in seconds)\nROUND_DURATION_SECONDS=60 # Total duration of each round\nAUCTION_CLOSING_SECONDS=15 # Time before round end when new bids are closed\nRESERVE_SUBMISSION_SECONDS=15 # Time allocated for reserve price submission\nDeploy the contract:\nforge script --sender $DEPLOYER --rpc-url $CHILD_CHAIN_RPC --slow ./DeployExpressLaneAuction.s.sol -vvv --verify --broadcast\n# Use --account XXX / --private-key XXX / --interactive / --ledger to specify the transaction signer\nVerify successful deployment by checking that the contract returns your configured bid token:\ncast call --rpc-url=<Your-chain's-endpoint> <Your-ExpressLaneAuction-address> \"biddingToken()(address)\"\nExample output:\n0xYourBidTokenAddress\nStep 2: Run auctioneer services\nThere are two distinct services to run: the bid validator and the auction server. The bid validator verifies submitted bids, while the auction server sends the winning bid onchain.\nPrerequisites\nThe services require the autonomous-auctioneer binary, which is included in the Nitro Docker image. Alternatively, you can build it locally by following the Build Nitro Locally guide.\nTo build only the autonomous-auctioneer component during the local build process:\nmake target/bin/autonomous-auctioneer\nRunning bid validator service\nStart the bid validator with:\n./autonomous-auctioneer \\\n--bid-validator.auction-contract-address=<Your ExpressLaneAuction address> \\\n--bid-validator.rpc-endpoint=<Your chain's rpc URL> \\\n--auctioneer-server.enable=false \\\n--bid-validator.redis-url=<Your Redis URL> \\\n--http.addr=0.0.0.0 \\\n--http.port=<port>\nRunning auction server service\nStart the auction server with:\n./autonomous-auctioneer \\\n--auctioneer-server.auction-contract-address=<Your ExpressLaneAuction address> \\\n--auctioneer-server.db-directory=<Your_auctioneer_server_db_directory> \\\n--auctioneer-server.redis-url=<Your Redis URL> \\\n--auctioneer-server.use-redis-coordinator=false \\\n--auctioneer-server.sequencer-endpoint=<Your sequencer URL> \\\n--auctioneer-server.wallet.private-key=<Your auctioneer private key> \\\n--bid-validator.enable=false\nStep 3: Configure your sequencer node for Timeboost\nUpdate your sequencer node configuration to enable Timeboost functionality. Add the following new config to your sequencer's node configuration file:\n{\n \"http\": {\n \"api\": [\n // existing APIs\n \"auctioneer\",\n \"timeboost\"\n ]\n },\n \"ws\": {\n \"api\": [\n // existing APIs\n \"auctioneer\",\n \"timeboost\"\n ]\n },\n \"execution\": {\n \"sequencer\": {\n \"timeboost\": {\n \"enable\": true,\n \"auction-contract-address\": \"<Your-ExpressLaneAuction-address>\",\n \"auctioneer-address\": \"<Your-auctioneer-address>\",\n \"redis-url\": \"<Your-Redis-URL>\"\n }\n }\n }\n}\nVerifying your Timeboost setup\nThere are multiple ways to confirm that Timeboost is correctly enabled on your chain:\nPeriodic startup logs\nWhen you start your sequencer with Timeboost enabled, you'll see periodic logs indicating the start of new express lane auction rounds:\nNew express lane auction round\nThis log indicates that the Timeboost mechanism is active and running normally.\nTransaction processing confirmation\nAfter finishing a bid request, look for messages in your sequencer logs such as:\nAuctionResolved: New express lane controller assigned round\nThis message confirms that your sequencer is processing express queue transactions from the express lane controller, and that Timeboost is functioning correctly.\nUser interaction verification\nUsers can interact with Timeboost by submitting bids through the auctioneer_submitBid endpoint of your auctioneer service.\nFor detailed instructions on how users can interact with Timeboost, see How to Use Timeboost.\nA successful bid submission will trigger the auction resolution process and generate the corresponding logs mentioned above.\nConfiguring Timeboost's Parameters\nBelow is a table of the configurable parameters and how to think about adjusting their values, should you choose to deploy and enable Timeboost for your chain.\nParameter nameDescriptionConsiderationsroundDurationSecondsTime during which the sequencer will honor the express lane privileges for transactions signed by the current round’s express lane controller. Default: 60 secondsThe larger this value, the more powerful and valuable controlling the express lane will be. Higher values may incentivize more participation and demand for the express lane time advantage.auctionClosingSecondsTime before the start of the next round. The will not accept bids during this time interval. Default: 15 secondsThe larger the value, the more difficult it is for participants to predict the value of the future express lane round, and therefore, their ability and confidence in being able to place an accurate/fair bid for the time advantage. However, a value that is too small may not allow the auctioneer sufficient time to resolve the auction on time during periods of high activity.beneficiaryAn address where proceeds from the Timeboost auction are sent to when flushBeneficiaryBalance() gets called on the . Default: An address controlled by the chain's ownerCan be any address, including the burn address, that the chain owner designates or controls._biddingTokenAddress of the token used to make bids in the Timeboost auction. It can be any ERC-20 token, including the gas token of the network, provided the chosen token address does not have fee-on-transfer, rebasing, transfer hooks, or otherwise non-standard ERC-20 logic. Default: WETHThis asset should ideally be liquid and easily obtainable for your auction participants. Furthermore, the less volatile this asset is, the more consistent your auction will be.nonExpressDelayMsecThe artificial delay applied, by the sequencer, to the arrival timestamp on non-express lane transactions before the non-express lane transactions eventually get sequenced. Default: 0.2 seconds, or 200 millisecondsThe larger this value, the greater the time advantage will be for the express lane controller, making it easier for the express lane controller to capture MEV opportunities (e.g., backrunning, liquidations, or arbitrage) and therefore the more valuable. However, increasing this value comes at the expense of slower response times for user transactions in the non-express lane.reservePriceThe minimum bid amount accepted by the auction contract for Timeboost auctions, denominated in _biddingToken. Default: NoneThis value should be left empty and only be changed to raise the minimum bid post-deployment of the auction contract (see below)._minReservePriceA value that must be equal to or below the reservePrice to act as a \"floor price\" for Timeboost bids. Enforced by the auction contract. Default: 0.001 WETHA value that is low enough to make the auction worth while participating in, but not high enough to pose a significant barrier to entry (i.e., ideally, chain owners will want a fair, competitive market for the timeboost time advantage). This value can also be set high such that if someone does bid, the bid proceeds could offset some of the costs spent on running the autonomous auctioneer.How is this guide?Sequencer timing adjustmentsLearn how to configure timing adjustments to the Sequencer for your Arbitrum chainPGA for Arbitrum chainsGuidance and best practices for using PGA on Arbitrum chains","tokens":3738,"squid":"spider-01","role":"Chain Spider","at":1791345575651,"hash":"fef3a8599829979eb6a9a612e0db712b102932da"}
{"url":"https://www.metaplex.com/docs/smart-contracts/core/sdk/rust","domain":"metaplex.com","title":"Rust SDK | MPL-Core","text":"Metaplex provides a Rust library that can be used to interact with the MPL-Core program. The Rust library can be used in rust scripts/builds as well as onchain programs via CPI instructions. For Anchor program integration, see Using Core in Anchor for anchor, anchor-0-32, and Rust toolchain requirements.InstallationThe MPL-Core Rust SDK can be used in both scripts/desktop/mobile applications as well as with Solana onchain programs.cargo add mpl-core\ncrates.ioGet started with our JavaScript library based on the Umi framework.docs.rsThe Rust SDK typedoc platform.Local ScriptsFor local scripts is recommended to use the Builder versions of all the instructions listed. These builders abstract a lot of the work for you and return a instruction that can be added to a transaction. A list of all Core instructions can be found here: Metaplex Core - Rust Instructions For a more comprehensive guide on using Rust check out the Metaplex Rust SDKs Guide page.CreateV1Builder - Exampleuse mpl_core::instructions::CreateV1Builder;\nuse solana_client::rpc_client;\nuse solana_sdk::{signature::Keypair, signer::Signer, transaction::Transaction};\npub fn create_asset() {\nlet rpc_client = rpc_client::RpcClient::new(\"https://api.devnet.solana.com\".to_string());\nlet keypair_path = \".../my-key.json\"\n let keypair = solana_sdk::signature::read_keypair_file(keypair_path).unwrap();\n let asset = Keypair::new();\n let create_asset_ix = CreateV1Builder::new()\n .asset(asset.pubkey())\n .payer(keypair.pubkey())\n .name(\"My Asset\".into())\n .uri(\"https://example.com/my-asset.json\".into())\n .instruction();\n let signers = vec![&asset, &keypair];\n let last_blockhash = rpc_client.get_latest_blockhash().await.unwrap();\n let create_asset_tx = Transaction::new_signed_with_payer(\n &[create_asset_ix],\n Some(&keypair.pubkey()),\n &signers,\n last_blockhash,\n );\n let res = rpc_client.send_and_confirm_transaction(&create_asset_tx).await.unwrap();\n println!(\"Signature: {:?}\", res)\n}\nCPI (Cross Program Invocation)Performing CPI instructions from your own programs can be achieved easily by using the CpiBuilder version of an instruction function that can be found for all instructions in the mpl-core Rust crate. A list of all Core instructions can be found here: Metaplex Core - Rust Instructions For a more comprehensive guide using Metaplex crates to create CPI instructions check out the How to CPI into a Metaplex Program guide page.CreateV1CpiBuilder - ExampleCreateV1CpiBuilder::new()\n .asset(context.accounts.asset)\n .collection(context.accounts.collection)\n .authority(context.accounts.authority)\n .payer(context.accounts.payer)\n .owner(context.accounts.owner)\n .update_authority(context.accounts.update_authority)\n .system_program(context.acccounts.system_program)\n .data_state(input.data_state.unwrap_or(DataState::AccountState))\n .name(args.asset_name)\n .uri(args.asset_uri)\n .plugins(args.plugins)\n .invoke()","tokens":724,"squid":"dotcat","role":"Tooling Spider","at":1791345576106,"hash":"689085f862f2b5d7f839ea9802917fc930cb1cad"}
{"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":"spider-08","role":"Oracle Spider","at":1791345582800,"hash":"48a7ba6681acdaf8d336e880bac5c926f99694cf"}
{"url":"https://www.metaplex.com/docs/solana/rust/metaplex-rust-sdks","domain":"metaplex.com","title":"Metaplex Rust SDKs | Guides","text":"IntroductionMetaplex provides Rust SDKs for most of our programs which have consistent and predictable outputs and functionality leading to improved integration times for developers working with our products.ModulesThe Core Rust SDKs are organized into several modules:accounts: represents the program's accounts.instructions: facilitates the creation of instructions, instruction arguments, and CPI instructions.errors: enumerates the program's errors.types: represents types used by the program.AccountsThe accounts module is generated based on on-chain account structures. These can be deserialized using a number of different methods based on if you are using RAW program generation or using a framework such as Anchor.These can be accessed from <crate_name>::accounts. In the case of mpl-core you could access the accounts as follows;mpl_core::accounts\nInstructionsEach SDK comes with an instructions module that comes with multiple versions of the supplied instructions from the given program that strips away a lot of the boiler plate depending on your needs.An example below shows all the CreateV1 instructions coming from the mpl-core crate.CreateV1\nCreateV1Builder\nCreateV1Cpi\nCreateV1CpiAccounts\nCreateV1CpiBuilder\nCreateV1InstructionArgs\nCreateV1InstructionData\nThese can be accessed from <crate_name>::instructions. In the case of mpl-core you could access the accounts as follows;mpl_core::instructions\nTypesEach of the Metaplex Rust SDKs comes with a types module that supplies all the necessary extra types that may not be in the initial accounts module structs.These can be accessed from <crate_name>::types. In the case of mpl-core you could access the accounts as follows;mpl_core::types\nErrorsWhile an errors module is generated for every SDK this just holds the error list for that specific program and users do not need to interact with this module.Instruction BuildersMetaplex Rust SDKs will also currently come with two Builder versions of each instruction which you can import. This abstracts a massive amount code for you and will return you an instruction that's ready to send.These include:BuilderCpiBuilderIn the case of CreateV1 from the mpl-Core crate docs these instructions are currently available to us.CreateV1\nCreateV1Builder\nCreateV1Cpi\nCreateV1CpiAccounts\nCreateV1CpiBuilder\nCreateV1InstructionArgs\nCreateV1InstructionData\nBuilderBuilder instructions are designed to be used when you need to create instructions for client-side transactions.The one we are interested in here is the CreateV1Builder.To initialize the builder we can call new.CreateV1Builder::new();\nFrom this point we can ctrl + click (pc) or cmd + click (mac) into the new function generated from the Builder:: which positions us at the pub fn new() for the builder. If you scroll up slightly you'll then see the pub struct for the CreateV1Builder as outlined below.pub struct CreateV1Builder {\n asset: Option<solana_program::pubkey::Pubkey>,\n collection: Option<solana_program::pubkey::Pubkey>,\n authority: Option<solana_program::pubkey::Pubkey>,\n payer: Option<solana_program::pubkey::Pubkey>,\n owner: Option<solana_program::pubkey::Pubkey>,\n update_authority: Option<solana_program::pubkey::Pubkey>,\n system_program: Option<solana_program::pubkey::Pubkey>,\n log_wrapper: Option<solana_program::pubkey::Pubkey>,\n data_state: Option<DataState>,\n name: Option<String>,\n uri: Option<String>,\n plugins: Option<Vec<PluginAuthorityPair>>,\n __remaining_accounts: Vec<solana_program::instruction::AccountMeta>,\n}\nThese are your arguments of publickeys and data that will need to be passed into the builder. Some accounts may also be optional. These optional accounts may not be required at all by the program or could possibly default to another address if left out. This behaviour can vary from instruction to instruction.If you click through to the new() function again and scroll down this time you'll see the individual functions with additional comments. In the below case you can see that the owner will default to payer, so we don't need to pass in owner if in this case if the payer is also going to be the owner of the Asset./// `[optional account]`\n /// The owner of the new asset. Defaults to the authority if not present.\n #[inline(always)]\n pub fn owner(&mut self, owner: Option<solana_program::pubkey::Pubkey>) -> &mut Self {\n self.owner = owner;\n self\n }\nHere is an example using the CreateV1Builder that returns an instruction using .instruction() to close out the Builder.let create_asset_ix = CreateV1Builder::new()\n .asset(asset.pubkey())\n .collection(collection.pubkey())\n .payer(payer.pubkey())\n .name(\"My Nft\".into())\n .uri(\"https://example.com/my-nft.json\".into())\n .instruction();\nNow that we have our instruction ready we need to create a normal Solana transaction to send to our RPC. This includes a blockhash and signers.Full Builder ExampleThis is a full example of creating a instruction using a Metaplex Builder function and sending that transaction off to the chain.use mpl_core::instructions::CreateV1Builder;\nuse solana_client::nonblocking::rpc_client;\nuse solana_sdk::{signature::Keypair, signer::Signer, transaction::Transaction};\n\nlet rpc_client = rpc_client::RpcClient::new(\"https://api.devnet.solana.com\".to_string());\n\n let payer = Keypair::new();\n let asset = Keypair::new();\n\n let create_asset_ix = CreateV1Builder::new()\n .asset(asset.pubkey())\n .payer(payer.pubkey())\n .name(\"My Nft\".into())\n .uri(\"https://example.com/my-nft.json\".into())\n .instruction();\n\n let signers = vec![&asset, &payer];\n\n let last_blockhash = rpc_client.get_latest_blockhash().await.unwrap();\n\n let create_asset_tx = Transaction::new_signed_with_payer(\n &[create_asset_ix],\n Some(&payer.pubkey()),\n &signers,\n last_blockhash,\n );\n\n let res = rpc_client.send_and_confirm_transaction(&create_asset_tx).await.unwrap();\n\n println!(\"Signature: {:?}\", res)\nCpiBuilderThe CpiBuilder instructions are designed to be used when you wish to call and execute instructions from a Metaplex program from your own program.We have a full separate guide discussing CpiBuilders which can be viewed here;CPI Into a Metaplex Program","tokens":1532,"squid":"dotcat","role":"Tooling Spider","at":1791345587440,"hash":"8b7fc0c273bde72de51eb17ae64902b36e1ab7c1"}
{"url":"https://docs.pyth.network/price-feeds/pro/integrate-as-consumer/sui","domain":"docs.pyth.network","title":"Consume Data on Sui | Pyth Developer Hub","text":"Pyth ProIntegrate as a ConsumerConsume Data on SuiConsume and verify Pyth Pro price updates in Sui Move smart contractsThis guide is intended to serve users who want to consume prices from Pyth Pro on Sui.\nIntegrating with Pyth Pro in smart contracts as a consumer is a three-step process:\n\nSubscribe to Pyth Pro websocket to receive price updates on backend or frontend.\nVerify price updates in a Programmable Transaction Block (PTB) using the Pyth Lazer Sui SDK.\nConsume the verified Update in your smart contract.\n\nSubscribe to Pyth Pro to receive Price UpdatesPyth Pro provides a websocket endpoint to receive price updates. Pyth Pro also provides a TypeScript SDK to subscribe to the websocket endpoint.Consult How to subscribe to prices for a complete step-by-step guide.When subscribing, request the leEcdsa format which is compatible with Sui's secp256k1 signature verification:client.subscribe({\n type: \"subscribe\",\n subscriptionId: 1,\n priceFeedIds: [1, 2], // BTC/USD, ETH/USD\n properties: [\"price\", \"bestBidPrice\", \"bestAskPrice\", \"exponent\"],\n formats: [\"leEcdsa\"], // Required for Sui\n channel: \"fixed_rate@200ms\",\n jsonBinaryEncoding: \"hex\",\n});Verify price updates in a PTBPyth Pro provides a Sui TypeScript SDK that handles the verification call for you.Always call parse_and_verify_le_ecdsa_update_v2 in a Programmable Transaction Block (PTB), not inside your smart contract.\nThis allows your contract to work with any newer version of the Pyth Lazer contract, since the Update type remains stable.Install the Sui SDK:npm install @pythnetwork/pyth-lazer-sui-jsUse the SDK to build your transaction:import { SuiGrpcClient } from \"@mysten/sui/grpc\";\nimport { Ed25519Keypair } from \"@mysten/sui/keypairs/ed25519\";\nimport { Transaction } from \"@mysten/sui/transactions\";\nimport { PythLazerClient } from \"@pythnetwork/pyth-lazer-sdk\";\nimport { addParseAndVerifyLeEcdsaUpdateCall } from \"@pythnetwork/pyth-lazer-sui-js\";\n\n// 1. Fetch the price update from Pyth Lazer in \"leEcdsa\" format:\nconst lazer = await PythLazerClient.create({ token: LAZER_TOKEN });\nconst latestPrice = await lazer.getLatestPrice({\n channel: \"fixed_rate@200ms\",\n formats: [\"leEcdsa\"],\n jsonBinaryEncoding: \"hex\",\n priceFeedIds: [1],\n properties: [\"price\", \"bestBidPrice\", \"bestAskPrice\", \"exponent\"],\n});\nconst update = Buffer.from(latestPrice.leEcdsa?.data ?? \"\", \"hex\");\n\n// 2. Create a new Sui transaction:\nconst signer = Ed25519Keypair.fromSecretKey(SUI_KEY);\nconst client = new SuiGrpcClient({ baseUrl, network });\nconst tx = new Transaction();\n\n// 3. Add the parse and verify call:\nconst verifiedUpdate = await addParseAndVerifyLeEcdsaUpdateCall({\n client: client.core,\n stateObjectId: STATE_ID,\n tx,\n update,\n});\n\n// 4. Consume `verifiedUpdate` in your own contract with additional calls...\ntx.moveCall({\n target: `${YOUR_PACKAGE_ID}::your_module::consume_price`,\n arguments: [verifiedUpdate],\n});\n\n// 5. Sign and execute the transaction:\nconst result = await client.signAndExecuteTransaction({\n signer,\n transaction: tx,\n});The stateObjectId is the Pyth Lazer State object on Sui. See the Contract Addresses page for the current mainnet and testnet state object IDs.Consume the verified Update in your smart contractYour contract receives a verified Update object and can extract the price data it needs. Add the Pyth Lazer package as a dependency in your Move.toml file:[dependencies]\npyth_lazer = { git = \"https://github.com/pyth-network/pyth-crosschain.git\", subdir = \"lazer/contracts/sui\", rev = \"main\" }To use testnet version of Pyth Lazer contract, use rev = \"sui-testnet\" instead. We use custom deployment of the Wormhole contract on testnet for maintenance purposes.Import the necessary modules and write a function that accepts the Update:use pyth_lazer::update_v2::Update;\nuse pyth_lazer::feed::Feed;\n\npublic fun consume_price(update: Update) {\n // Access update metadata\n let timestamp = update.timestamp();\n let channel = update.channel();\n\n // Get the feeds vector\n let feeds = update.feeds_ref();\n\n // Access the first feed\n let feed = &feeds[0];\n\n // Extract price data\n let feed_id = feed.feed_id();\n let price = feed.price();\n let exponent = feed.exponent();\n\n // Process the price data according to your application logic\n // ...\n}See pyth_lazer::feed module for additional fields and their types.Many feed properties return Option<Option<T>>. The outer Option indicates whether the property was requested in the subscription.\nThe inner Option indicates whether a value is available (e.g., price may be None if there aren't enough publishers).\nAlways check both levels when accessing values.Working with Signed IntegersPyth prices can be negative (e.g., for certain derivative products). The SDK provides I64 and I16 types for signed integers:use pyth_lazer::i64::{Self, I64};\n\n// Check if a price exists and extract it\nlet price_opt = feed.price();\nif (price_opt.is_some()) {\n let inner_opt = price_opt.borrow();\n if (inner_opt.is_some()) {\n let price_i64 = inner_opt.borrow();\n\n // Check if negative\n let is_negative = price_i64.get_is_negative();\n\n // Get the magnitude\n let magnitude = if (is_negative) {\n price_i64.get_magnitude_if_negative()\n } else {\n price_i64.get_magnitude_if_positive()\n };\n }\n}\nAdditional Resources\nYou may find these additional resources helpful for consuming prices from Pyth Pro in your Sui smart contracts.\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\nLazer Sui SDK contains a complete example of building a transaction using Lazer Sui contract.\npyth-lazer-example-js is a simple example for subscribing to the Pyth Pro websocket.in EVM contractsPrevious Pagein IOTA contractsNext Page","tokens":1433,"squid":"spider-08","role":"Oracle Spider","at":1791345592061,"hash":"dd638027b6b193a9c3af5a26a35465e0e87fa6c3"}
{"url":"https://www.metaplex.com/docs/solana/solana-keypairs-and-wallets","domain":"metaplex.com","title":"Solana Keypairs and Wallets | Wallet Security Guide","text":"A comprehensive guide to creating, managing, and securing Solana keypairs for development and production environments. What You'll LearnWhat keypairs are and how they work on SolanaHow to generate and manage keypairsSecurity best practices for different environmentsHow to use keypairs with the Solana CLI and MPLX CLIPrerequisitesSolana CLI installedUnderstanding KeypairsA keypair on Solana consists of:Public Key - Your wallet address, safe to shareSecret Key - Secret key that controls the wallet, never share thisCritical Security RuleYour private key gives complete control over your wallet. Anyone with access to it can transfer all your assets. Never commit keypair files to git, share them online, or store them unencrypted on cloud services.Creating KeypairsGenerate a New Keypair# Create a new keypair (prompts for BIP39 passphrase)\nsolana-keygen new\n\n# Create with a specific output file\nsolana-keygen new --outfile ~/my-wallet.json\n\n# Create without passphrase prompt (for scripts/testing)\nsolana-keygen new --no-bip39-passphrase --outfile ~/my-devnet-wallet.json\nThe command outputs:The public key (your wallet address)A seed phrase (12-24 words) for recoverySave Your Seed PhraseWrite down your seed phrase and store it securely offline. This is the only way to recover your wallet if you lose the keypair file.Recover from Seed Phrase# Recover a keypair from seed phrase\nsolana-keygen recover --outfile ~/recovered-wallet.json\nYou'll be prompted to enter your seed phrase.Generate from Existing SeedIf you have a seed phrase and want to derive the keypair:solana-keygen recover 'prompt://?full-path=m/44'/501'/0'/0'' --outfile ~/derived-wallet.json\nManaging Keypairs with MPLX CLIThe MPLX CLI provides convenient wallet management with named wallets:# Create a new wallet in MPLX config\nmplx config wallets new my-dev-wallet\n\n# Add an existing keypair file\nmplx config wallets add my-wallet ~/path/to/keypair.json\n\n# List all configured wallets\nmplx config wallets list\n\n# Set the active wallet\nmplx config wallets set my-dev-wallet\n\n# Remove a wallet from config\nmplx config wallets remove old-wallet\nBenefits of MPLX wallet management:Named wallets instead of file pathsEasy switching between walletsCentralized configuration at ~/.mplx/config.jsonViewing Keypair InformationGet Public Key from Keypair Filesolana-keygen pubkey ~/my-wallet.json\nVerify a Keypair Filesolana-keygen verify <PUBKEY> ~/my-wallet.json\nSetting Your Default KeypairSolana CLI# Set default keypair for all commands\nsolana config set --keypair ~/my-wallet.json\n\n# Verify the setting\nsolana config get\nPer-Command Override# Use a specific keypair for one command\nsolana balance --keypair ~/other-wallet.json\nsolana transfer <ADDRESS> 1 --keypair ~/funding-wallet.json\nSecurity Best PracticesDevelopment vs ProductionEnvironmentRecommendationLocal testingFile system wallet, no passphrase neededDevnet/TestnetFile system wallet, backed up seed phraseMainnet (small amounts)File system wallet with passphrase, encrypted diskMainnet (significant value)Hardware wallet or multisigsFile System WalletsFor development and moderate amounts:# Create with restrictive permissions\nsolana-keygen new --outfile ~/.config/solana/mainnet-wallet.json\nchmod 600 ~/.config/solana/mainnet-wallet.json\nEnvironment VariablesFor automated scripts, avoid hardcoding keypair paths:# In your shell profile (~/.bashrc or ~/.zshrc)\nexport SOLANA_KEYPAIR_PATH=\"$HOME/.config/solana/devnet-wallet.json\"\n\n# In scripts\nsolana config set --keypair \"$SOLANA_KEYPAIR_PATH\"\nMultiple Wallets StrategyRecommended setup for active developers:~/.config/solana/\n├── devnet-wallet.json # Main devnet testing\n├── testnet-wallet.json # Testnet when needed\n├── mainnet-wallet.json # Small mainnet operations\n└── burner-wallet.json # Temporary/throwaway\nConfigure with MPLX CLI for easy switching:mplx config wallets add devnet ~/.config/solana/devnet-wallet.json\nmplx config wallets add mainnet ~/.config/solana/mainnet-wallet.json\nmplx config wallets set devnet\nWhat NOT to DoNever commit keypair files to git (add *.json to .gitignore)Never share your seed phrase or private key in Discord, Telegram, or support ticketsNever paste your private key into websitesNever store unencrypted keypairs in cloud storage (Dropbox, Google Drive)Never use the same keypair for mainnet testing and productionHardware WalletsFor significant mainnet holdings, use a Ledger hardware wallet:# Check if Ledger is connected\nsolana-keygen pubkey usb://ledger\n\n# Use Ledger for transactions\nsolana config set --keypair usb://ledger\nsolana transfer <ADDRESS> 1\nRequirements:Ledger device with Solana app installedUSB connection to your computerPractical ExamplesDevelopment Wallet Setup# 1. Create a devnet wallet (no passphrase for convenience)\nsolana-keygen new --no-bip39-passphrase --outfile ~/.config/solana/devnet.json\n\n# 2. Set it as default\nsolana config set --keypair ~/.config/solana/devnet.json\n\n# 3. Switch to devnet\nsolana config set --url devnet\n\n# 4. Get some devnet SOL\nsolana airdrop 2\n\n# 5. Verify\nsolana balance\nTeam Development SetupFor teams, each developer should have their own keypairs:# Developer creates their own wallet\nsolana-keygen new --outfile ~/my-project-wallet.json\n\n# Share only the PUBLIC key with the team\nsolana-keygen pubkey ~/my-project-wallet.json\n# Output: 7nE9GvcwYDhwWdFfGjVZQ8dR6bYYvqPJktNpyxQYb1xm\nProgrammatic Keypair Generation (JavaScript)For applications that need to generate keypairs using UMI:import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\nimport { generateSigner, signerIdentity } from '@metaplex-foundation/umi'\n\nconst umi = createUmi('https://api.devnet.solana.com')\n\n// Generate a new random keypair signer\nconst signer = generateSigner(umi)\nconsole.log('Public Key:', signer.publicKey)\n\n// Use it as the identity (payer + signer)\numi.use(signerIdentity(signer))\n\n// Load an existing keypair from a file\nimport { createSignerFromKeypair } from '@metaplex-foundation/umi'\nimport fs from 'fs'\n\nconst secretKey = new Uint8Array(JSON.parse(fs.readFileSync('wallet.json')))\nconst keypair = umi.eddsa.createKeypairFromSecretKey(secretKey)\nconst loadedSigner = createSignerFromKeypair(umi, keypair)\nTroubleshooting\"Keypair file not found\"# Check if file exists\nls -la ~/.config/solana/id.json\n\n# If not, create one\nsolana-keygen new --outfile ~/.config/solana/id.json\n\n# Or check your config\nsolana config get\n\"Invalid keypair\"The keypair file must be a JSON array of 64 numbers. Verify format:# Should output an array like [123, 45, 67, ...]\ncat ~/my-wallet.json | head -c 100\nLost Seed PhraseIf you lost your seed phrase but still have the keypair file:Your funds are safe as long as you have the fileTransfer funds to a new wallet with a backed-up seed phraseTreat the old keypair as compromised for future useNext StepsGrind a vanity public key - Create branded addressesGet SOL for development - Fund your new walletSolana CLI essentials - Use your wallet effectivelyFAQCan I use the same keypair on devnet and mainnet?Technically yes, but it's not recommended. Use separate keypairs to avoid accidentally sending real SOL in test scripts.What's the difference between a keypair and a wallet?A keypair is the cryptographic key pair (public + private). A wallet is software that manages keypairs and helps you interact with the blockchain. File system wallets store the raw keypair; browser wallets like Phantom manage it with additional UX.How do I use my Phantom wallet with the CLI?Export your private key from Phantom (Settings > Security > Export Private Key), then import it:# The exported key is base58 encoded, convert it:\necho \"[your-exported-key]\" | base58 -d > phantom-wallet.json\nsolana config set --keypair phantom-wallet.json\nNote: For security, consider creating a separate CLI keypair instead of exporting from Phantom.","tokens":1960,"squid":"dotcat","role":"Tooling Spider","at":1791345598857,"hash":"9a765ee98372fb51e2ec337897ef898a46184208"}
{"url":"https://docs.pyth.network/price-feeds/pro/integrate-as-consumer/cardano","domain":"docs.pyth.network","title":"Consume Data on Cardano | Pyth Developer Hub","text":"Pyth ProIntegrate as a ConsumerConsume Data on CardanoConsume and verify Pyth Pro price updates in Cardano smart contractsThis guide is intended to serve users who want to consume prices from Pyth Pro on Cardano.\nIntegrating with Pyth Pro in Cardano smart contracts as a consumer is a three-step process:\n\nUse the pyth-lazer-cardano Aiken library in your on-chain code.\nSubscribe to Pyth Pro websocket to receive signed price updates.\nInclude those updates in a Cardano transaction by doing a zero withdrawal from the Pyth withdraw script.\n\nPurpose of the Pyth withdraw script is to verify signature validity of a provided price update payload. It does not enforce freshness of the update, nor does it disallow verifying the same update multiple times. If your contract puts constraints on a validity window of an update, make sure to enforce this directly in your contract implementation, e.g. by checking timestamp_us field.\nUse the Aiken library in your on-chain codeAdd the Pyth Lazer Cardano library to your aiken.toml file:[[dependencies]]\nname = \"pyth-network/pyth-lazer-cardano\"\nversion = \"main\"\nsource = \"github\"Your contract should read verified updates from the transaction, not verify the signatures itself. The Aiken library exposes pyth.get_updates, which reads:\nthe Pyth state from the transaction's reference_inputs\nthe verified update bytes from the redeemer of the Pyth withdraw script\nHere is a minimal example that searches for the ADA/USD feed (Pyth Pro feed\nID 16) and converts the result into Aiken's Rational type:use aiken/collection/list\nuse aiken/math/rational.{Rational}\nuse cardano/assets.{PolicyId}\nuse cardano/transaction.{Transaction}\nuse pyth\nuse types/u32\n\nfn read_ada_usd_price(pyth_id: PolicyId, self: Transaction) -> Rational {\n expect [update] = pyth.get_updates(pyth_id, self)\n expect Some(feed) = list.find(update.feeds, fn(feed) {\n u32.as_int(feed.feed_id) == 16\n })\n expect Some(Some(price)) = feed.price\n expect Some(exponent) = feed.exponent\n expect Some(multiplier) = rational.from_int(10) |> rational.pow(exponent)\n\n rational.from_int(price) |> rational.mul(multiplier)\n}The returned PriceUpdate values include:\ntimestamp_us\nchannel_id\nfeeds\nEach Feed includes fields such as feed_id, price, best_bid_price, best_ask_price, exponent, confidence, ema_price, and feed_update_timestamp.pyth.get_updates requires the Pyth state UTxO to be present as a reference\ninput. If you omit that reference input, your validator will fail when it\ntries to locate the Pyth State NFT and withdraw-script hash.Fetch a signed price update off-chainPyth Pro provides a TypeScript SDK for fetching signed updates. Request the solana format for the binary update - this is a little-endian format signed by an Ed25519 key, which we use for both Cardano and Solana integrations.The example below follows fetch-and-verify.ts and fetches one signed update that can be passed into the verification script redeemer:import { PythLazerClient } from \"@pythnetwork/pyth-lazer-sdk\";\n\nconst lazer = await PythLazerClient.create({ token: LAZER_TOKEN });\nconst latestPrice = await lazer.getLatestPrice({\n channel: \"fixed_rate@200ms\",\n formats: [\"solana\"],\n jsonBinaryEncoding: \"hex\",\n priceFeedIds: [16],\n properties: [\"price\", \"exponent\"],\n});\n\nif (!latestPrice.solana?.data) {\n throw new Error(\"Missing update payload\");\n}\n\nconst update = Buffer.from(latestPrice.solana.data, \"hex\");If you need a streaming integration instead of a one-shot fetch, consult How to subscribe to prices. Regardless of transport, the transaction must receive the signed update as raw bytes.Include the updates into the Cardano transactionPyth's own Cardano integration builds a transaction with the following shape:\nSet a short validity window.\nAdd the Pyth state UTxO as a reference input.\nWithdraw 0 lovelace from the Pyth withdraw script, with the list of signed updates as the redeemer.\nInclude your own script in the same transaction so that your validator can call pyth.get_updates(pyth_id, self).\nThe pyth_id below is the Pyth deployment policy ID for your network. The Pyth state UTxO is the UTxO holding the Pyth State NFT under that policy ID.import { Client, preprod, ScriptHash } from \"@evolution-sdk/evolution\";\nimport {\n getPythScriptHash,\n getPythState,\n} from \"@pythnetwork/pyth-lazer-cardano-js\";\n\nconst client = Client.make(preprod).withKoios({\n baseUrl: \"https://preprod.koios.rest/api/v1\",\n});\n\nconst pythState = await getPythState(POLICY_ID, client);\nconst pythScript = getPythScriptHash(pythState);\n\n// In your own transaction, include Pyth State UTxO as a reference input, and\n// trigger 0-withdrawal on the verification script, together with the price\n// update as a redeemer, to perform price verification on-chain.\n\nconst wallet = client.withSeed({\n mnemonic: CARDANO_MNEMONIC,\n});\n\nconst now = BigInt(Date.now());\nconst tx = wallet\n .newTx()\n .setValidity({ from: now - 60_000n, to: now + 60_000n })\n .readFrom({ referenceInputs: [pythState] })\n .withdraw({\n amount: 0n,\n redeemer: [update],\n stakeCredential: ScriptHash.fromHex(pythScript),\n });\n\n// Add your own scripts and transaction data...\n\n// Sign and execute the transaction:\nconst builtTx = await tx.build();\nconst digest = await builtTx.signAndSubmit();The zero-withdrawal and your consuming validator must be in the same\ntransaction. pyth.get_updates reads the withdrawal redeemer directly from\nthe transaction that is currently being validated.\nAdditional Resources\nYou may find these additional resources helpful for consuming prices from Pyth Pro in Cardano smart contracts.\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.\nContract Sources\nThe Cardano contract implementation lives in lazer/contracts/cardano.\nThe off-chain flow shown above comes from fetch-and-verify.ts.in IOTA contractsPrevious Pagein Stellar contractsNext Page","tokens":1476,"squid":"spider-08","role":"Oracle Spider","at":1791345601959,"hash":"5f45b3b04c581b32e43ba2eddeca7abd71818965"}
{"url":"https://www.metaplex.com/docs/solana/understanding-programs","domain":"metaplex.com","title":"Understanding Programs | Developer Hub","text":"This page aims to provide a quick overview of how programs work in Solana and offer additional reading material for those who are interested in learning more about a particular subject. IntroductionUnlike most blockchains, Solana separates logic and data into two separate components. These are, respectively, Programs and Accounts. What that means is that instead of storing data inside variables internally, Programs interact with external data stored in Accounts with the ability to mutate them.This architecture is great for making Programs more modular since the data they interact with is not bound by the Program itself and can scale to new orders of magnitude. It is also great for making Programs more performant since it allows the blockchain to run the same Program in parallel with different Accounts.To interact with a Program, we must use the Instructions defined by that Program. You can think of Instructions as API endpoints exposed by the Program. Each Instruction contains a set of parameters and constraints that must be fulfilled to execute it.To recap: In Solana, Programs define Instructions that can be used to interact with external data stores called Accounts.Note that, technically, Programs are special kinds of Accounts marked as executable whose entire purpose is to store the compiled code of the Program. However, for the sake of simplicity, we will distinguish these definitions and use the term \"Account\" to refer to non-executable Accounts.In the rest of this guide, we will talk about Accounts and Instructions in more detail before explaining the visual representation that we will be using in diagrams throughout the documentation.📚 Additional reading:Solana Documentation — On-chain ProgramsSolana Cookbook — ProgramsThe Anchor Book — Intro to Programming on SolanaAccountsIn Solana, Accounts are used to store data. In essence, they are simple arrays of bytes stored at a particular address. The address of an Account is the public key of a cryptographic key pair.Anyone that has access to the private key of that key pair, can sign on behalf of that Account which, depending on the program, may give them the ability to mutate the data stored in that Account.Once an Account is created, it is usually immediately initialized by a Program which will be marked as its Owner and will define the data structure of the allocated array of bytes. The Program that owns the Account is then responsible for providing Instructions that can be used to interact with it.📚 Additional reading:Solana Documentation — AccountsSolana Cookbook — AccountsProgram Derived Addresses (PDA)There exist another type of Account, called Program Derived Account, whose address is not the public key of a cryptographic key pair but instead is algorithmically derived from the public key of the Program that owns the Account. We call that address a Program Derived Address or PDA for short.Since the address is always derived from the public key of the Program, no other Program can algorithmically derive the same address. On top of that, additional Seeds can be provided to the algorithm to add more context to the address.This has a variety of use cases such as enabling programs to sign Cross-Program Invocations or enabling the creation of accounts within an address that can be derived deterministically.Note that, by design, Program Derived Addresses will never conflict with cryptographically generated public keys. All cryptographic public keys are part of what we call an Elliptic-curve. If, when generating a PDA, the algorithm generated a key that falls on that curve, a Bump is added to the address and is incremented by one until the generated address no longer falls on the curve.📚 Additional reading:Solana Documentation — PDAsSolana Cookbook — PDAsAccount dataWhether we are dealing with a regular Account or a Program Derived Account, Accounts store data as a serialized array of bytes. Therefore, it is the responsibility of the Program to define a data structure for each of the Accounts it manages as well as provide a way of differentiating these Accounts, so we know which data structure to apply to them.DiscriminatorsDiscriminators are used to differentiate between different types of Accounts within a Program. They can be implemented in many ways but here are the three most common ones:Use a shared Enum as the first byte of every account. By prefixing every Account with a shared Enum, we can use the first byte of the serialized data to identify the Account. This is a simple and efficient way to implement discriminators. Most of the programs maintained by Metaplex use this approach.Use a deterministic hash as the first byte of every account. This is very similar to the previous point, but it uses a hash instead of an Enum. Programs created using the Anchor framework end up using this approach implicitly because Anchor will automatically generate that hash based on the Account's name.No discriminator, use the size of the Account. If all the accounts managed by a Program have different sizes, then we can examine the length of that array of bytes to determine which Account we are dealing with. This is a performant approach since we don't need to add extra bytes to the data, but it limits how flexible a Program can be with its Accounts. The SPL Token Program by Solana uses this approach since it only maintains two accounts of different fixed sizes.Field types, sizes and offsetsEach Account defines its own data structure by using fields of different types. These types will affect the number of bytes required to store the field. For instance, an i8 is an 8-bit integer that will require 1 byte to store whereas an i64 is a 64-bit integer which will require 8 bytes to store.Since, in the blockchain, Accounts are just arrays of bytes, it is important to understand the size of each field and where they start in this array, i.e. their offset. This can be useful when fetching multiple accounts from a given program using a memcmp filter.Note that not all fields have a fixed size. For instance, a Vec<i8> is a vector of 8-bit integers that may contain none, one or many items. As such, it becomes a lot more complicated to filter accounts based on fields that are located after the first field of variable size.Optional fieldsA field can also be defined as optional, meaning there exists a scenario where that field can be empty.This field will use an additional byte as a prefix to indicate whether the field is empty or not.Concretely, the value None will be assigned and the program will act accordingly when using that field.Indicative fieldsWhilst this is not something that is explicitly defined in the data structure, the documentation will mark certain fields as indicative.An indicative field means that the information provided by the field is not used by the program itself. Instead, it indicates a piece of information to third parties. The program will still enforce the integrity of the data, but it will simply not use that information internally.Let’s take the Metadata Account as an example.The Share property of each creator in the Creators array is indicative. The Token Metadata program will ensure that the Share values of all creators add up to 100%, but it will not do anything with that information. Instead, it expects NFT marketplaces to use this information when distributing royalties.On the other hand, the Is Mutable property is not indicative because the Token Metadata program will use that information internally to prevent immutable Metadata Accounts to be updated.InstructionsOne can interact with a Program using the Instructions it provides. Multiple Instructions can be packed into a single Transaction that will be sent to the blockchain. Each Transaction is atomic meaning if any of its instructions fails, the whole Transaction will be reverted.Similarly to Accounts, Instructions must be serialized into an array of bytes before they can be sent to the network. The data to be serialized must contain the following information for the Program to execute it.Discriminator: Similarly to Accounts, Instructions are usually prefixed with a discriminator so the Program can identify which Instruction is being executed.Accounts: An array of Account addresses that are affected by this instruction. This can either be because the Account will be read, mutated or both. Note that the order of this array is important since Programs will identify the type of Account provided based on its position.Arguments: An array of data fields required by the instruction. It is not uncommon for this array to be empty since Instructions can get most of their information directly from the Accounts. Note that these arguments are comparable to the fields of an Account and, therefore, they can have the same properties mentioned above such as \"optional\" and \"indicative\".Signers: An array of signatures for a sub-set of the Accounts provided. This is only needed for Accounts that are required to sign the Instruction. The next section explains this in a bit more detail.📚 Additional reading:Solana Documentation — TransactionsSolana Documentation — InstructionsSolana Cookbook — TransactionsSigner and/or Writable AccountsA Program may require that the Accounts provided within an Instruction are Signers and/or Writable.Signers: A Signer Account is required to sign the Transaction for the Instruction to be successful. By attaching a signature, users can prove that they are the owner of the Account.Writable: A Writable Account will be mutated by the Instruction. This information is important for the blockchain to know which Transactions can be run in parallel and which ones can't.Therefore, with these two booleans, we end up with the following four possible scenarios:Non-Signer and Non-Writable: This Account is only used to read data. We cannot mutate it and we cannot make any assumption about its ownership.Signer and Non-Writable: This Account can also not be mutated, but we know that the user who sent the Transaction owns its private key. This enables Programs to grant or deny access to certain actions.Signer and Writable: This Account has both signed the Transaction and it can be mutated by the Instruction. This combination is pretty common since Programs will usually require the owner of an Account to prove who they are before mutating that account. Otherwise, anyone could mutate any Account they don't own.Non-Signer and Writable: This Account can be mutated, but we can't make any assumption about its ownership. That usually means that the Program is using other Signer Accounts to prove they can mutate that one. This is also the case for PDA Accounts since they are owned by the Program and, as such, they require the Program to keep track of Authorities that can mutate them. Also, note that certain actions like crediting lamports to an Account do not require the Account to sign the Transaction.Cross-Program Invocations (CPI)Cross-Program Invocations allow Programs to execute nested Instructions within their Instructions. They can use Instructions from their own Program and/or from other Programs.📚 Additional reading:Solana Documentation — CPIUsing CPIs with Anchor Programs","tokens":2800,"squid":"dotcat","role":"Tooling Spider","at":1791345608742,"hash":"36c2479030c3c33c507b0584b326838e34f16444"}
{"url":"https://akash.network/docs/api-documentation/sdk/authz-feegrant/","domain":"akash.network","title":"AuthZ & Fee Grants SDK | Akash Network - Your Guide to Decentralized Cloud","text":"AuthZ & Fee Grants SDK Programmatically grant permissions and manage fee allowances using the Akash SDK.\nThis guide covers how to use the Akash SDK (Go and JavaScript/TypeScript) to implement AuthZ and Fee Grants in your applications.\n\nOverview\nThe Akash SDK provides full support for:\n\nAuthZ (Authorization) - Grant deployment permissions programmatically\nFee Grants - Pay transaction fees for other accounts via code\n\nFor CLI usage and concepts, see: AuthZ & Fee Grants Guide\n\nInstallation\nBefore using AuthZ and Fee Grants, install the Akash SDK:\n→ SDK Installation Guide\n\nAuthZ SDK Integration\nGranting Permissions\nGrant deployment permissions to another account:\nimport (\n \"pkg.akt.dev/go/node/authz/v1beta1\"\n \"time\"\n)\n\n// Grant permission to create deployments\ngrantMsg := &authz.MsgGrant{\n Granter: granterAddress,\n Grantee: granteeAddress,\n Grant: authz.Grant{\n Authorization: &authz.GenericAuthorization{\n Msg: \"/akash.deployment.v1beta3.MsgCreateDeployment\",\n },\n Expiration: &time.Time{}, // Optional expiration\n },\n}\n\n// Broadcast the grant transaction\nresp, err := client.BroadcastTx(ctx, grantMsg)\nif err != nil {\n log.Fatal(err)\n}\n\nGrant with Expiration and Limits\nimport (\n \"pkg.akt.dev/go/node/authz/v1beta1\"\n sdk \"github.com/cosmos/cosmos-sdk/types\"\n \"time\"\n)\n\n// Set expiration to 30 days from now\nexpiration := time.Now().Add(30 * 24 * time.Hour)\n\n// Grant with spending limit\ngrantMsg := &authz.MsgGrant{\n Granter: granterAddress,\n Grantee: granteeAddress,\n Grant: authz.Grant{\n Authorization: &authz.GenericAuthorization{\n Msg: \"/akash.deployment.v1beta3.MsgCreateDeployment\",\n },\n Expiration: &expiration,\n },\n}\n\n// Note: Spending limits are set via fee grants (see below)\nresp, err := client.BroadcastTx(ctx, grantMsg)\n\nExecute with Granted Permission\nUse granted permissions to deploy on behalf of another account:\nimport (\n \"pkg.akt.dev/go/node/authz/v1beta1\"\n \"pkg.akt.dev/go/node/deployment/v1beta3\"\n \"github.com/cosmos/cosmos-sdk/codec/types\"\n)\n\n// Create the deployment message\ndeploymentMsg := &deployment.MsgCreateDeployment{\n ID: deployment.DeploymentID{\n Owner: granterAddress, // Important: use granter's address\n DSeq: dseq,\n },\n Groups: groups,\n Version: version,\n Deposit: deposit,\n}\n\n// Wrap in authz exec message\nexecMsg := &authz.MsgExec{\n Grantee: granteeAddress, // Your address\n Msgs: []*types.Any{\n types.MustPackAny(deploymentMsg),\n },\n}\n\n// Broadcast from grantee account\nresp, err := client.BroadcastTx(ctx, execMsg)\nif err != nil {\n log.Fatal(err)\n}\n\nfmt.Printf(\"Deployment created: %d\\n\", dseq)\n\nQuery Grants\nCheck existing grants between accounts:\nimport (\n \"pkg.akt.dev/go/node/authz/v1beta1\"\n)\n\n// Query grants by granter and grantee\ngrantsResp, err := client.AuthzClient.Grants(ctx, &authz.QueryGrantsRequest{\n Granter: granterAddress,\n Grantee: granteeAddress,\n MsgTypeUrl: \"/akash.deployment.v1beta3.MsgCreateDeployment\",\n})\nif err != nil {\n log.Fatal(err)\n}\n\nfor _, grant := range grantsResp.Grants {\n fmt.Printf(\"Grant: %+v\\n\", grant)\n fmt.Printf(\"Expiration: %s\\n\", grant.Expiration)\n}\n\n// Query all grants by granter\nallGrantsResp, err := client.AuthzClient.GranterGrants(ctx, &authz.QueryGranterGrantsRequest{\n Granter: granterAddress,\n})\n\nRevoke Permissions\nRemove granted permissions:\nimport (\n \"pkg.akt.dev/go/node/authz/v1beta1\"\n)\n\n// Revoke permission\nrevokeMsg := &authz.MsgRevoke{\n Granter: granterAddress,\n Grantee: granteeAddress,\n MsgTypeUrl: \"/akash.deployment.v1beta3.MsgCreateDeployment\",\n}\n\n// Broadcast the revoke transaction\nresp, err := client.BroadcastTx(ctx, revokeMsg)\nif err != nil {\n log.Fatal(err)\n}\n\nfmt.Println(\"Permission revoked successfully\")\n\nFee Grant SDK Integration\nGrant Basic Fee Allowance\nAllow another account to use your AKT for transaction fees:\nimport (\n \"pkg.akt.dev/go/node/feegrant/v1beta1\"\n sdk \"github.com/cosmos/cosmos-sdk/types\"\n \"github.com/cosmos/cosmos-sdk/codec/types\"\n)\n\n// Grant basic fee allowance (unlimited)\nbasicAllowance := &feegrant.BasicAllowance{}\n\nallowanceAny, err := types.NewAnyWithValue(basicAllowance)\nif err != nil {\n log.Fatal(err)\n}\n\ngrantMsg := &feegrant.MsgGrantAllowance{\n Granter: granterAddress,\n Grantee: granteeAddress,\n Allowance: allowanceAny,\n}\n\n// Broadcast the grant\nresp, err := client.BroadcastTx(ctx, grantMsg)\n\nGrant Fee Allowance with Spending Limit\nimport (\n \"pkg.akt.dev/go/node/feegrant/v1beta1\"\n sdk \"github.com/cosmos/cosmos-sdk/types\"\n \"github.com/cosmos/cosmos-sdk/codec/types\"\n)\n\n// Grant with spending limit (1 AKT = 1,000,000 uAKT)\nlimitAllowance := &feegrant.BasicAllowance{\n SpendLimit: sdk.NewCoins(sdk.NewCoin(\"uakt\", sdk.NewInt(1000000))),\n}\n\nallowanceAny, err := types.NewAnyWithValue(limitAllowance)\nif err != nil {\n log.Fatal(err)\n}\n\ngrantMsg := &feegrant.MsgGrantAllowance{\n Granter: granterAddress,\n Grantee: granteeAddress,\n Allowance: allowanceAny,\n}\n\nresp, err := client.BroadcastTx(ctx, grantMsg)\n\nGrant Periodic Fee Allowance\nAllow a specific amount per time period (e.g., daily limit):\nimport (\n \"pkg.akt.dev/go/node/feegrant/v1beta1\"\n sdk \"github.com/cosmos/cosmos-sdk/types\"\n \"github.com/cosmos/cosmos-sdk/codec/types\"\n \"time\"\n)\n\n// Grant 0.1 AKT per day\nperiod := time.Hour * 24\nperiodLimit := sdk.NewCoins(sdk.NewCoin(\"uakt\", sdk.NewInt(100000)))\n\nperiodicAllowance := &feegrant.PeriodicAllowance{\n Basic: feegrant.BasicAllowance{\n SpendLimit: sdk.NewCoins(sdk.NewCoin(\"uakt\", sdk.NewInt(10000000))), // Total limit\n },\n Period: period,\n PeriodLimit: periodLimit,\n}\n\nallowanceAny, err := types.NewAnyWithValue(periodicAllowance)\ngrantMsg := &feegrant.MsgGrantAllowance{\n Granter: granterAddress,\n Grantee: granteeAddress,\n Allowance: allowanceAny,\n}\n\nresp, err := client.BroadcastTx(ctx, grantMsg)\n\nQuery Fee Grants\nimport (\n \"pkg.akt.dev/go/node/feegrant/v1beta1\"\n)\n\n// Query specific fee grant\ngrantResp, err := client.FeegrantClient.Allowance(ctx, &feegrant.QueryAllowanceRequest{\n Granter: granterAddress,\n Grantee: granteeAddress,\n})\nif err != nil {\n log.Fatal(err)\n}\n\nfmt.Printf(\"Allowance: %+v\\n\", grantResp.Allowance)\n\n// Query all fee grants by granter\ngranterResp, err := client.FeegrantClient.AllowancesByGranter(ctx, &feegrant.QueryAllowancesByGranterRequest{\n Granter: granterAddress,\n})\n\nfor _, allowance := range granterResp.Allowances {\n fmt.Printf(\"Grantee: %s\\n\", allowance.Grantee)\n}\n\nRevoke Fee Grant\nimport (\n \"pkg.akt.dev/go/node/feegrant/v1beta1\"\n)\n\n// Revoke fee grant\nrevokeMsg := &feegrant.MsgRevokeAllowance{\n Granter: granterAddress,\n Grantee: granteeAddress,\n}\n\nresp, err := client.BroadcastTx(ctx, revokeMsg)\nif err != nil {\n log.Fatal(err)\n}\n\nfmt.Println(\"Fee grant revoked\")\n\nCombined AuthZ + Fee Grant\nThe most powerful pattern: grant both permissions AND fee allowance so the grantee can deploy without any AKT:\nimport (\n \"pkg.akt.dev/go/node/authz/v1beta1\"\n \"pkg.akt.dev/go/node/feegrant/v1beta1\"\n sdk \"github.com/cosmos/cosmos-sdk/types\"\n \"github.com/cosmos/cosmos-sdk/codec/types\"\n \"time\"\n)\n\n// Step 1: Grant fee allowance\nlimitAllowance := &feegrant.BasicAllowance{\n SpendLimit: sdk.NewCoins(sdk.NewCoin(\"uakt\", sdk.NewInt(10000000))), // 10 AKT for fees\n}\nallowanceAny, _ := types.NewAnyWithValue(limitAllowance)\nfeeGrantMsg := &feegrant.MsgGrantAllowance{\n Granter: granterAddress,\n Grantee: granteeAddress,\n Allowance: allowanceAny,\n}\n\n// Step 2: Grant deployment permission\nexpiration := time.Now().Add(30 * 24 * time.Hour)\nauthzGrantMsg := &authz.MsgGrant{\n Granter: granterAddress,\n Grantee: granteeAddress,\n Grant: authz.Grant{\n Authorization: &authz.GenericAuthorization{\n Msg: \"/akash.deployment.v1beta3.MsgCreateDeployment\",\n },\n Expiration: &expiration,\n },\n}\n\n// Broadcast both in a single transaction\nresp, err := client.BroadcastTx(ctx, feeGrantMsg, authzGrantMsg)\nif err != nil {\n log.Fatal(err)\n}\n\nfmt.Println(\"Grantee can now deploy on your behalf with no AKT needed!\")\n\nUse Cases\nCI/CD Pipeline Automation\nGrant your CI/CD bot permissions and fees for automated deployments:\n// Setup CI/CD bot with daily fee limit and deployment permissions\nfunc setupCICDBot(client *AkashClient, botAddress string) error {\n // Daily fee limit: 0.5 AKT per day\n period := time.Hour * 24\n periodicAllowance := &feegrant.PeriodicAllowance{\n Basic: feegrant.BasicAllowance{\n SpendLimit: sdk.NewCoins(sdk.NewCoin(\"uakt\", sdk.NewInt(50000000))),\n },\n Period: period,\n PeriodLimit: sdk.NewCoins(sdk.NewCoin(\"uakt\", sdk.NewInt(500000))),\n }\n\n // Grant full deployment permissions\n authzGrant := &authz.MsgGrant{\n Granter: myAddress,\n Grantee: botAddress,\n Grant: authz.Grant{\n Authorization: &authz.GenericAuthorization{\n Msg: \"/akash.deployment.v1beta3.MsgCreateDeployment\",\n },\n },\n }\n\n // Broadcast both\n return client.BroadcastTx(ctx, periodicAllowance, authzGrant)\n}\n\nBest Practices\nSecurity\n\nAlways set spending limits - Never grant unlimited fee allowances\nUse expiration dates - Time-limit permissions when possible\nMonitor grants - Regularly query and audit active grants\nRevoke promptly - Remove grants when no longer needed\nSeparate accounts - Use dedicated accounts for different purposes\n\nError Handling\n// Check if grant exists before executing\nfunc checkAndExecute(client *AkashClient, granterAddr, granteeAddr string) error {\n // Query grant\n grantResp, err := client.AuthzClient.Grants(ctx, &authz.QueryGrantsRequest{\n Granter: granterAddr,\n Grantee: granteeAddr,\n MsgTypeUrl: \"/akash.deployment.v1beta3.MsgCreateDeployment\",\n })\n\n if err != nil {\n return fmt.Errorf(\"failed to query grant: %w\", err)\n }\n\n if len(grantResp.Grants) == 0 {\n return fmt.Errorf(\"no grant found\")\n }\n\n // Check expiration\n grant := grantResp.Grants[0]\n if grant.Expiration != nil && grant.Expiration.Before(time.Now()) {\n return fmt.Errorf(\"grant has expired\")\n }\n\n // Execute deployment\n return executeDeployment(client, granterAddr)\n}\n\nRelated Resources\n\nAuthZ & Fee Grants Guide - CLI usage and concepts\nSDK Installation - Get started with the SDK\nSDK Quick Start - Deploy your first app programmatically\nSDK Examples - More SDK code examples\n\nAdditional Resources\n\nCosmos SDK AuthZ: docs.cosmos.network/sdk/v0.53/build/modules/authz\nCosmos SDK FeeGrant: docs.cosmos.network/sdk/v0.53/build/modules/feegrant\nDiscord: discord.akash.network - #developers channel\n\nQuestions? Join Discord #developers channel! \nEdit page on github\n Quick Start Examples","tokens":2564,"squid":"spider-03","role":"Compute Spider","at":1791345610642,"hash":"733c09ebe65d434fffba1667ac6c4a7a370247f1"}
{"url":"https://forum.arbitrum.foundation/t/angle-protocol-final-stip-round-1/17104/1","domain":"forum.arbitrum.foundation","title":"[ANGLE PROTOCOL] [FINAL] [STIP - Round 1] - Archive / Short Term Incentives Program (STIP) Round 1 - Arbitrum","text":"The Arbitrum Foundation notified the Security Council on the need to perform a potential Emergency action. Following a review of the details and known risks, the Security Council decided to execute the upgrade and it was completed at 11:30 EST on 2nd October 2026.\nThis report provides an overview of the risks that required the Security Council Action:\n\nAdd a permissionless guard for the One-Step Proof of BoLD on Arbitrum One\n\nTemporarily pause activation of new Stylus contracts on Arbitrum One & Nova\n\nKey point: To date, known bugs for Stylus primarily impact chain liveness (e.g., denial of service attacks) and do not put any user funds at risk.\nWhy was this action taken\nLet’s take this opportunity to explain why action was taken on two separate issues concerning BoLD and Stylus.\nInstalling the guard for One-Step Proof of BoLD. Given the rise of AI-assisted attacks, we have implemented a precautionary approach that allows anyone to pause settlement of Arbitrum One on Ethereum if there are at least two conflicting answers that pass at the same level in which only one should be valid and pass. This is to halt a class of publicly verifiable and detectable attacks that exploit a bug in the one-step proof. If halted, Arbitrum One will continue to process as normal except that messages from Arbitrum One to Ethereum, such as withdrawals, that are not yet confirmed will have to wait. This provides time for the Security Council to deploy a fix for the bug and resume the rollup.\nPreventing activation of new Stylus contracts. AI-assisted tooling has led to an increasing number of sophisticated attacks on hand-crafted WASM programs that do not use the standard Stylus compiler toolchain. These programs are specifically designed to cause unexpected behaviors such as degrading the chain’s performance for all other users. To date, no attacks have been discovered that permits theft of user funds.\nNew ArbOS releases have patched several reported bugs and known attacks over the past few months, but out of an abundance of caution, we have decided to temporarily pause new activations of Stylus contracts. This was executed as an emergency action to prevent the deployment of new hand-crafted WASM programs that are not yet patched by the current version of ArbOS on the Arbitrum network.\nThe Arbitrum Foundation has informed the Security Council that they will work with the ArbitrumDAO to discuss next steps on the timeline and manner for enabling activation of new Stylus contracts. The Arbitrum community remains confident in the value of Stylus and want to preserve these use cases while taking preventative measures against Stylus-based attack vectors as AI-assisted attack tooling continues to evolve.\nImpact on builders and users\n\nNo new activations. New Stylus contracts cannot be activated during the pause including new versions of existing applications that require activation.\n\nExisting contracts are not paused. Already-active Stylus contracts continue to execute until expiration. This pause does not deactivate them.\n\nThe ArbOS 61 upgrade renewed all active contracts on Arbitrum One, so no currently active contract expires before August 20, 2027.\n\nRenewal via keepalive stays permissionless and is unaffected by the pause.\n\nReactivating an expired contract, or one that needs to be updated after a Stylus version change, is paused.\n\nUsing/calling any activated Stylus contract stays permissionless for all users and developers.\n\nNo impact on EVM. Solidity (EVM) contract deployment and execution are unaffected by this Security Council action.\n\nSecurity Council Actions\nThere are two actions bundled into a single payload:\n\nOne-Step Proof Guard. The L1UpgradeExecutor gives a new pause contract (PauseExecutor) the ability to pause and nothing else. The new pause contract grants the guard (OspSoundnessGuard) PAUSER_ROLE to use it. Anyone can show the guard two conflicting answers to the same step of an open challenge. If the one-step proof accepts both, the guard has the pause contract put Arbitrum One’s settlement to Ethereum on hold.\n\nStylus deactivation. The Security Council called ArbOwner.setWasmActivationGas(2^64 - 1) to raise the Stylus activation gas requirement on Arbitrum One and Nova. This makes activation prohibitively expensive and effectively disables new activations. This is a configuration change and does not require an ArbOS upgrade.\n\nThe Security Council signed the following transactions to update the configuration:\n\nEthereum: Ethereum Transaction Hash: 0x30732bb7d2... | Etherscan\nArbitrum One:\nArbitrum One Transaction Hash: 0x9eb3a4be3b... | Arbitrum One\nArbitrum Nova:\nArbitrum Nova transaction 0x79e0fed470dff7a22059b108e3f8f42eddd2b580a6771594060c4e7326c5f984 | Blockscout\n\nAn external audit was conducted for the OSP Guard contracts. No audit is required for the Stylus deactivation as it is only updating a single parameter in the ArbOS configuration.\n\n [ANGLE PROTOCOL] [FINAL] [STIP - Round 1] \n\n ArchiveShort Term Incentives Program (STIP) Round 1\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Sep 2023\n\n 1 / 26\n\n Sep 2023\n\n Jan 2024\n\n post by Mariam on Sep 26, 2023\n\n Mariam\n\n This is an updated proposal following comments received below in respect of the initial draft.\nApplicant Name: Mariam Kouanda\nProject Name: Angle Protocol\nProject Description: Angle Protocol is a Defi protocol that launched:\n\nagEUR, the most liquid Euro stablecoin;\nstEUR, a staked agEUR paying a yield coming from RWAs held in Angle’s reserves and protocol fees (newly launched on 25 September 2023); and\nMerkl, a smart incentivization system for concentrated liquidity used by major Arbitrum DEXes.\n\nTeam Members and Qualifications:\nPablo Veyrat - Cofounder of Angle\nGuillaume Nervo - Cofounder of Angle\nPicodes - Cofounder of Angle\nMariam Kouanda - Head of growth at Angle\nProject Links:\n\nWebsite - https://www.angle.money/\nDocumentation Portal - Angle Documentation Portal | Angle Docs\nGithub - Angle · GitHub\nAudits - Audits | Angle Docs\nTwitter - https://twitter.com/AngleProtocol\nAnalytics and Balance Sheet - Angle Analytics\n\nContact Information\nTG: @MariamKd\nTwitter: https://twitter.com/TheBlockAdopter\nEmail: mariam.k@angle.money\nDo You Acknowledge That Your Team Will Be Subject to a KYC Requirement?: Yes\nSECTION 2: GRANT INFORMATION\nRequested Grant Size: Between 200,000 $ARB and 700,000 $ARB, to be released according to milestones (see grant timeline below with milestones included).\nGrant Matching: Yes. Native yield in agEUR will distributed from Angle Protocol’s profits and reserves, currently 4% APY on stEUR.\nGrant Breakdown:\nAs a reminder, stEUR is a staked agEUR paying a fixed 4% APY coming from RWAs held in Angle’s reserves and protocol fees.\nThe grant will be distributed to (see grant timeline below for milestones):\n\nincentivize a stEUR/USDC Camelot v3 pool from 1 November 2023 to 31 January 2024 with up to 250,000 $ARB;\nincentivize a stEUR/ARB Camelot v3 pool from 1 November 2023 to 31 January 2024 with up to 250,000 $ARB;\nincentivize a stEUR/wstETH Camelot v3 pool from 1 November 2023 to 31 January 2024 with up to 100,000 $ARB;\nincentivize the use of stEUR as collateral to borrow USDC on a native lending protocol (Radiant) with 100,000 $ARB (to be unlocked only if the integration is secured prior to December 15, 2023);\n\nIf this grant request is approved, Angle will immediately:\n(1) deploy stEUR and native agEUR staking on Arbitrum in order to create the first RWAs and Euro based savings rate on Arbitrum;\n(2) add $ARB as a token to mint agEUR natively on Arbitrum;\n(3) work on use cases and integration for stEUR in order to push this program beyond liquidity incentivization (e.g. lending, yield tokenization etc.).\nThe grant will not be used for development costs, only for supporting the development of stEUR on Arbitrum, promoting RWAs in the ecosytem, enabling integrations across the ecosystem and its pairing with $ARB and $wstETH.\nFunding Address: 0xAA2DaCCAb539649D1839772C625108674154df0B\nFunding Address Characteristics: 4/6 Safe multisig composed on Angle core team members and ecosystem participants. More details on the multisig composition here.\nContract Address: Incentivization will go through Merkl, the incentivization tool built by Angle Labs, that enabled concentrated liquidity incentivization. Merkl related contract addresses can be found here.\nSECTION 3: GRANT OBJECTIVES AND EXECUTION\nObjectives: The objectives are:\n\nLaunch the first RWA and Euro-based yield source on any L2 with stEUR and bring the first savings rate to Arbitrum\nCreate deep Euro liquidity on Arbitrum with stEUR and so indirectly with agEUR\nUse the development of stEUR on Arbitrum to support $ARB volume and liquidity with a stEUR/ARB pool\nFurther support the use of $ARB by enabling agEUR minting with $ARB\nUse the development of stEUR on Arbitrum to support $ETH volume and liquidity with a stEUR/wstETH pool\nFurther the use of RWAs-related assets on Arbitrum and taking this program beyond liquidity incentivization by supporting the use of stEUR as collateral on a lending protocol and promoting other use cases\n\nKey Performance Indicators (KPIs):\n\nAngle TVL on Arbitrum\nNumber of circulating stEUR on Arbitrum\nPercentage of stEUR natively staked on Arbitrum and portion of Angle revenue distributed on Arbitrum (breakdown between Ethereum and Arbitrum)\n$ARB volume and liquidity relating to the stEUR/ARB pool to be set up\n$wstETH volume and liquidity relating to the stEUR/wstETH pool to be set up\n\nHow will receiving a grant enable you to foster growth or innovation within the Arbitrum ecosystem?:\nThis is an opportunity to provide all Defi users on Arbitrum (and not only Euro inclined ones) with:\n\na simple and real yield coming from RWAs;\na state of the art application of RWAs in the space;\ncomposability opportunities with enabling borrowing with stEUR and other use cases.\n\nThis grant would make Arbitrum the home of the first Euro and RWA based yield source and the most cost effective option to benefit from that opportunity. Arbitrum would be the first L2 to provide and support such an opportunity with stEUR (staked agEUR).\nAs mentioned, this will incidentally grow Euro liquidity on Arbitrum giving it a and boost in terms of stablecoins’ and currency’s diversity in the Defi ecosystem.\nJustification for the size of the grant:\nagEUR and the Angle Borrowing module have been deployed on Arbitrum since July 2022 to allow native minting of agEUR on the chain.\nAll these products have undergone audits and development work. This includes significant developement work made by Angle to allow a 1-click leverage from on Curve pools on Arbitrum in the Angle borrowing module.\nAngle has been active in the Arbitrum ecosystem, in particular through its Merkl product, the smart incentivization tool that is today used by Uniswap to distribute close to 2M ARB to increase volume and liquidity in several pools but also by DEXes such as Sushiswap and Camelot. Working with these partners have required bespoke integrations and smart contract work to cater to the development of liquidity and volume on Arbitrum for these DEXes.\nstEUR is a new product that enables value-sharing by streaming protocol revenue to agEUR stakers.\nThis grant will:\n\nsupport the further adoption on Arbitrum of all the above mentioned products (agEUR, agEUR borrowing using $ARB, stEUR and Merkl);\nthe sizing and duration will allow a compelling support RWAs-related opportunities on Arbitrum;\nthe sizing and duration will allow the development of a stEUR liquidity to develop use cases for it apart from LPeing in pools (use stEUR as collateral, integration in yield-related products like Pendle etc.);\nsupport both $ARB and $ETH liquidity and volume.\n\nThe grant is requested to migrate stEUR stakers to Arbitrum and incidentally support $ARB and $ETH in order to unlock a total TVL in the above-mentioned pools of $14+ millions in total, including, approximately €7m worth of stEUR on Arbitrum (see the grant timeline with milestones below).\nExecution Strategy:\nUse of Merkl to incentivize on Camelot v3\nThe pools to be set up are concentrated liquidity pools on Camelot.\nIncentivizing concentrated liquidity is initially difficult to implement. To do so, Angle will use Merkl, the tool developed by Angle Labs.\nThis tool is already in use since 2022 and trusted by several concentrated liquidity DEXes and projects to incentivize concentrated liquidity including Uniswap, Camelot, Sushiswap, Retro and others.\nFees do not apply when Merkl is used to incentivize agEUR and stEUR pools. This means the the use of Merkl will not incur any fees charged to the benefit of Angle Labs.\nIncentivization of the pools for a maximum total of 600,000 $ARB (see grant timeline for milestones)\nIf found are allocated to Angle to develop the stEUR while boosting the use of ARB and ETH on Arbitrum, we will immeditaly set up the three following pools:\n\nCamelot v3 stEUR/ARB\nCamelot v3 stEUR/wstETH\nCamelot v3 stEUR/USDC\n\nIncentivization for the use of stEUR as collateral on Radiant for a total of 100,000 $ARB (see grant timeline for milestones)\nUpon incentivization of the above-mentioned pools and development deep liquidity for stEUR on Arbitrum, the Angle team shall seek the listing of stEUR as collateral on Radiant as a native Arbitrum lending protocol and incentivize this use case.\nThis integration shall be worked on by the Angle team and the selected lending protocol prior to December 15, 2023 to unlock this portion of the grant.\nGrant Timeline:\n\nThe grant shall be awarded in three monthly tranches according to milestone as mentioned in the tables below.\nIf after the first month less than 75% of the global stEUR targets is reached, the program shall be stopped. Above 75%, the program shall continue over the second month.\nIf after the second month, less that 75% of the second month stEUR global target is reached, the program shall be stopped. Above 75%, the program shall continue over the third month.\n\nFirst month - 1 November 2023 to 30 November 2023\n\nDeployment of stEUR on Arbitrum\nEnabling of native staking of agEUR on Arbitrum\nEnabling agEUR borrowing with $ARB\nIncentivization on stEUR pools as follow\n\nPools\nDistributed $ARB\nMilestone Goal in TVL in the pool\n\nCamelot v3 stEUR/ARB\n83,333\n$1.4m\n\nCamelot v3 stEUR/wstETH\n33,334\n$1.3m\n\nCamelot v3 stEUR/USDC\n83,333\n$4m\n\nGlobal\n200,000\n$6.7m\n\nSecond month - 1 December 2023 to 31 December 2023\n\nAssessment of the first month stEUR global target and continuation if >75%\n\nPools\nDistributed $ARB\nMilestone Goal in TVL in the pool\n\nCamelot v3 stEUR/ARB\n83,333\n$1.5m\n\nCamelot v3 stEUR/wstETH\n33,334\n$1.4m\n\nCamelot v3 stEUR/USDC\n83,333\n$4.25m\n\nGlobal\n200,000\n$7.15m\n\nThird month - 1 January 2024 to 31 January 2024\n\nAssessment of the second month stEUR global target and continuation if >75%\n\nPools/Lending\nDistributed $ARB\nMilestone Goal in TVL in the pool\n\nCamelot v3 stEUR/ARB\n83,333\n$1.7m\n\nCamelot v3 stEUR/wstETH\n33,334\n$1.5m\n\nCamelot v3 stEUR/USDC\n83,333\n$5m\n\nRadiant (native lending protocol)\n100,000\n$8m\n\nGlobal\n300,000\n$16.2m\n\nDo you accept the funding of your grant streamed linearly for the duration of your grant proposal, and that the multisig holds the power to halt your stream? Yes\nSECTION 4: PROTOCOL DETAILS\nIs the Protocol Native to Arbitrum?: Yes. Angle protocol was initilly deployed on Ethereum but deployed it borrowing module natively on Arbitrum. This allows the native minting of agEUR on the chain.\nOn what other networks is the protocol deployed?: agEUR is deployed on at least 12 chains. However the protocol in itself is deployed only on Ethereum, Arbitrum, Optimism, and Polygon.\nWhat date did you deploy on Arbitrum?: agEUR and Angle Borrowing module were deployed on Arbitrum in July 2022.\nProtocol Performance:\nAs at 27 September 2023, Angle Protocol has a global TVL of $27m and agEUR has 581.k holders.\nAngle has newly launched the stEUR on 25 September 2023 at 5pm CET. Currently, 48 hours hours after launch, $3m worth of agEUR have been staked for stEUR.\nScreenshot 2023-09-27 at 15.49.402148×460 46.3 KB\nAs at 27 September 2023, Angle has $1m TVL on Arbitrum.\nThe potential deployement of stEUR on Arbitrum is a first of a kind, simple and useful usage on which the Angle can rely on to grow further on Arbitrum while supporting RWAs use cases and ARB on the chain.\nScreenshot 2023-09-27 at 15.51.502106×822 104 KB\nWith its tool Merkl, Angle Labs helps to power more liquidity and volume on concentrated liquidity pools across DEXes such as Uniswap, Camelot, Sushiswap etc.\nScreenshot 2023-09-25 at 18.57.342822×1406 411 KB\nThe protocol is also focused on providing transparency and making protocols’ reserves and financials accessible and readable by all.\nAngle has built and maintains an analytics showing the protocol balance-sheet, reserves and TVL progression in real time. The goal is to add more details useful to all participants including a soon to come event page that will detail all events by chain. This will also allow tracking of performance on Arbitrum.\nProtocol Roadmap:\nAngle newly deployed stEUR on 25 September 2023 (i.e. just 1 day prior to the posting of this proposal). The protocol future roadmap consists in:\n\nre-enforcing the diversification and resilience of the protocol’s reserves by exploring additional collaterals, including yield-producing collaterals;\nimplementing a fully on-chain governance, it being noted that the on-chain governance will allow voting on both Ethereum and Arbitrum;\nFurthering the integrations for the newly launched stEUR;\nDelivering more details in the analytics of the protocol that provide all details to stakeholders on the financial state of the protocol.\n\nAudit History:\nThe protocol has been audited:\n\n1 time by Code4rena\n3 times by ChainSecurity\n1 time by Sigma Prime\n\nNo critical findings remained unresolved. Audits are available here.\nSECTION 5: Data and Reporting\nIs your team prepared to create Dune Dashboards for your incentive program?: Yes or another dashboard providing a similar level of information.\nDoes your team agree to provide bi-weekly program updates on the Arbitrum Forum thread?\nAngle analytics is publicly available.\nIt will allow anyone at all times to see agEUR minted on Arbitrum but also agEUR staked on Arbitrum (stEUR). In addition, I (Mariam) or Pablo (Angle’s Cofounder) will be able to provide bi-weekly program updates.\nDoes your team acknowledge that failure to comply with any of the above requests can result in the halting of the program’s funding stream?: Yes\n\n Short-Term Incentive Grants Pitching Sessions\n\n 5\n\n 2\n\n 2\n\n 2\n\n 2\n\n read \n\n 10\n min\n\n post by meyaf320219 on Sep 26, 2023\n\n post by Mariam on Sep 26, 2023\n\n post by Matt_StableLab on Sep 26, 2023\n\n post by peter on Sep 26, 2023\n\n post by Perl on Sep 26, 2023\n\n post by Mariam on Sep 27, 2023\n\n post by meyaf320219 on Sep 28, 2023\n\n post by thecryptostakr on Sep 28, 2023\n\n post by abeltherebel on Sep 28, 2023\n\n post by strategicreserve on Oct 1, 2023\n\n post by Matt_StableLab on Oct 3, 2023\n\n post by Mariam on Oct 4, 2023\n\n post by cliffton.eth on Oct 4, 2023\n\n post by litocoen on Oct 5, 2023\n\n post by EynSoph on Oct 7, 2023\n\n post by WintermuteGovernance on Oct 9, 2023\n\n post by SEEDGov on Oct 10, 2023\n\n post by Mariam on Oct 10, 2023\n\n post by SEEDGov on Oct 10, 2023\n\n Load more posts below","tokens":4841,"squid":"spider-07","role":"Council Spider","at":1791345612522,"hash":"80b7000855cebb2c96dc2a3d736d2c142b028c31"}
{"url":"https://www.metaplex.com/docs/solana/spl-tokens-and-token-programs","domain":"metaplex.com","title":"SPL Tokens and Token Programs | Understanding Solana Tokens","text":"Understand how tokens work on Solana—from the SPL Token Program to Metaplex Core—and how Metaplex extends tokens with metadata, royalties, and more. What You'll LearnHow SPL tokens work on SolanaThe role of mint accounts, token accounts, and ATAsHow to choose between Token Program, Token Metadata, and Metaplex CoreHow Metaplex builds on top of the token standardPrerequisitesUnderstanding Solana accountsSolana CLI installedWhat Are SPL Tokens?SPL tokens (Solana Program Library tokens) are the standard for fungible and non-fungible tokens on Solana. Every token you interact with—USDC, BONK, NFTs, compressed NFTs—is built on the SPL token standard.Unlike Ethereum where each token deploys its own smart contract (ERC-20), Solana uses a single shared program that manages all tokens:Ethereum: Solana:\n┌──────────────┐ ┌──────────────────────┐\n│ USDC Contract│ │ Token Program │\n├──────────────┤ │ (single program) │\n│ BONK Contract│ │ │\n├──────────────┤ vs │ manages ALL tokens: │\n│ DAI Contract │ │ - USDC mint │\n├──────────────┤ │ - BONK mint │\n│ ... each │ │ - Your NFT mint │\n│ separate │ │ - Every SPL token │\n└──────────────┘ └──────────────────────┘\nThe Three Account TypesEvery SPL token involves three types of accounts:1. Mint AccountThe mint account defines the token itself. There's exactly one per token type.┌─────────────────────────────────────────────┐\n│ Mint Account (82 bytes) │\n├─────────────────────────────────────────────┤\n│ mint_authority: <pubkey or null> │ ← Who can create more supply\n│ supply: 1,000,000,000 │ ← Total tokens in existence\n│ decimals: 6 │ ← Decimal precision\n│ is_initialized: true │\n│ freeze_authority: <pubkey or null> │ ← Who can freeze accounts\n└─────────────────────────────────────────────┘\nKey properties:Decimals define precision (USDC uses 6, SOL-like tokens use 9, NFTs use 0)Supply tracks total minted tokensMint authority can create new tokens (set to null to make supply fixed)Freeze authority can freeze individual token accounts2. Token AccountA token account holds a specific user's balance of a specific token. Each wallet needs a separate token account for each token they hold.┌─────────────────────────────────────────────┐\n│ Token Account (165 bytes) │\n├─────────────────────────────────────────────┤\n│ mint: <which token> │\n│ owner: <which wallet controls this> │\n│ amount: 500,000,000 │ ← Balance (raw, before decimals)\n│ delegate: <optional delegated authority> │\n│ state: Initialized │\n│ is_native: false │\n│ delegated_amount: 0 │\n│ close_authority: <optional> │\n└─────────────────────────────────────────────┘\n3. Associated Token Account (ATA)An Associated Token Account is a token account with a deterministic address derived from the wallet and mint:ATA address = findProgramAddress(\n [wallet_address, TOKEN_PROGRAM_ID, mint_address],\n ASSOCIATED_TOKEN_PROGRAM_ID\n)\nThis means:Given a wallet and a token mint, you can always find the ATA addressNo need to track token account addresses separatelyWallets and explorers automatically know where to look# Find the ATA for a wallet and mint\nspl-token address --owner <WALLET> --token <MINT>\nATAs Are the StandardAlways use Associated Token Accounts. Metaplex tools (MPLX CLI and SDKs) create ATAs automatically when needed. You rarely need to create token accounts manually.The Token ProgramsSolana has two token programs:Token Program (Original)Program ID: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DAThe original SPL Token Program handles:Creating mints and token accountsMinting, transferring, and burning tokensApproving delegatesFreezing/thawing accountsMost existing tokens (USDC, BONK, and most NFTs) use this program.Token-2022 (Token Extensions)Solana also has a newer Token-2022 program (TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb) that adds extensions like transfer fees and confidential transfers. However, ecosystem support for Token-2022 is still maturing—most wallets, marketplaces, and DeFi protocols are optimized for the original Token Program.What Should I Use?ScenarioRecommendedWhyFungible tokensToken Program + Token MetadataMaximum compatibility with wallets, exchanges, and DeFiNFTs and digital assetsMetaplex CorePurpose-built for NFTs, lower cost, better performanceNFT collections with mintingCore Candy MachineAutomated minting with guards and phasesMassive NFT collections (100k+)BubblegumCompressed NFTs at a fraction of the costExisting Token Metadata NFTsToken MetadataContinue with the legacy standardMetaplex Core for NFTsMetaplex Core is the recommended standard for NFTs and digital assets. It doesn't rely on SPL tokens—instead it uses a purpose-built account model that is more efficient, cheaper, and easier to work with. Always choose Core for new NFT projects.How Metaplex Extends TokensThe SPL Token Program stores only basic information (supply, decimals, authority). It has no concept of names, images, or royalties. Metaplex fills this gap:┌─────────────────────────────────────────────────────────────┐\n│ SPL Token Program Metaplex Token Metadata │\n│ (token mechanics) (rich metadata) │\n│ │\n│ Mint Account ◄────────────► Metadata Account │\n│ ├── supply ├── name: \"Cool Token\" │\n│ ├── decimals ├── symbol: \"COOL\" │\n│ └── authority ├── uri: \"https://...\" │\n│ ├── creators: [...] │\n│ Token Account ├── royalties: 5% │\n│ ├── owner └── collection: <pubkey> │\n│ └── amount │\n│ Master Edition Account │\n│ ├── max_supply: 1 │\n│ └── (makes it an NFT) │\n└─────────────────────────────────────────────────────────────┘\nThe Metaplex EcosystemProductPurposeToken MetadataAdds metadata (name, image, royalties) to any SPL tokenCoreModern NFT standard (recommended for new projects)BubblegumCompressed NFTs for massive collectionsCandy MachineAutomated NFT mintingCore Candy MachineCandy Machine for Core NFTsCommon OperationsCreating a Token with MetadataUsing the MPLX CLI (handles all accounts automatically):# Create a fungible token with metadata\nmplx toolbox token-create --name \"My Token\" --symbol \"MTK\" --decimals 9\nThis creates:A Mint Account (Token Program)A Metadata Account (Token Metadata Program)Your wallet's ATA for the new tokenChecking Token Information# View mint details\nspl-token display <MINT_ADDRESS>\n\n# View your token accounts\nspl-token accounts\n\n# View a specific token balance\nspl-token balance --address <TOKEN_ACCOUNT_ADDRESS>\nMinting Tokens# Mint tokens (you must be the mint authority)\nspl-token mint <MINT_ADDRESS> <AMOUNT>\n\n# Mint to a specific wallet\nspl-token mint <MINT_ADDRESS> <AMOUNT> -- <RECIPIENT_TOKEN_ACCOUNT>\nNFTs Are TokensOn Solana, an NFT is simply an SPL token with:0 decimals (no fractional amounts)Supply of 1 (exactly one token exists)Mint authority set to null (no more can be minted)This is how the original Token Metadata standard works. Metaplex Core takes a different approach with dedicated NFT accounts that are more efficient.ApproachHow It WorksBest ForToken Metadata (legacy)SPL token + metadata accountExisting projects, fungible tokensCore (recommended)Dedicated asset accountNew NFT projects, collectionsBubblegumCompressed on-chain dataMassive collections (100k+)Rent CostsCreating token-related accounts requires rent-exempt deposits:# Check rent costs\nsolana rent 82 # Mint Account: ~0.002 SOL\nsolana rent 165 # Token Account: ~0.0025 SOL\nWhen you close token accounts or burn NFTs, you recover these deposits.Troubleshooting\"Account does not exist\"The recipient doesn't have a token account for this mint. Create one:# Create an ATA for a recipient\nspl-token create-account <MINT_ADDRESS> --owner <RECIPIENT_WALLET>\nMost Metaplex tools create ATAs automatically.\"Insufficient funds\"You need SOL for:Transaction fees (~0.000005 SOL)Rent for new accounts (~0.002 SOL per account)solana airdrop 2 # On devnet\n\"Owner does not match\"You're trying to operate on a token account you don't own, or using the wrong token program. Check the account's owner field matches the expected program.Next StepsCreate a Solana token - Hands-on token creationAdd metadata to tokens - Enrich tokens with Metaplex metadataMetaplex Core overview - The modern NFT standardUnderstanding Solana accounts - Deeper account model understandingFAQDo I need to understand SPL tokens to use Metaplex Core?Not necessarily. Metaplex Core has its own account model that doesn't use SPL tokens. However, understanding SPL tokens helps you work with Token Metadata NFTs and fungible tokens.Should I use Token-2022?For most use cases, the original Token Program with Metaplex Token Metadata is the best choice for fungible tokens. It has the widest ecosystem support across wallets, exchanges, and DeFi protocols.Why are there separate token accounts for each token?This is a key Solana design choice. Separate accounts enable parallel processing—transfers of different tokens can happen simultaneously without conflicts, which is how Solana achieves high throughput.What's the difference between \"owner\" and \"authority\"?Account owner (on-chain field): The program that controls the account (Token Program)Token account owner (in account data): The wallet that controls the tokensMint authority (in mint data): The wallet that can mint new supplyFreeze authority (in mint data): The wallet that can freeze accounts","tokens":2299,"squid":"dotcat","role":"Tooling Spider","at":1791345619639,"hash":"c0ecea11a4953bb06014fb4e3b048c0192184607"}
{"url":"https://forum.arbitrum.foundation/t/angle-protocol-final-stip-round-1/17104/26","domain":"forum.arbitrum.foundation","title":"[ANGLE PROTOCOL] [FINAL] [STIP - Round 1] - Archive / Short Term Incentives Program (STIP) Round 1 - Arbitrum","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 10\n min\n\n Sep 2023\n\n 26 / 26\n\n Jan 2024\n\n Jan 2024\n\n Load more posts above\n\n post by Mariam on Sep 27, 2023\n\n post by meyaf320219 on Sep 28, 2023\n\n post by thecryptostakr on Sep 28, 2023\n\n post by abeltherebel on Sep 28, 2023\n\n post by strategicreserve on Oct 1, 2023\n\n post by Matt_StableLab on Oct 3, 2023\n\n post by Mariam on Oct 4, 2023\n\n post by cliffton.eth on Oct 4, 2023\n\n post by litocoen on Oct 5, 2023\n\n post by EynSoph on Oct 7, 2023\n\n post by WintermuteGovernance on Oct 9, 2023\n\n post by SEEDGov on Oct 10, 2023\n\n post by Mariam on Oct 10, 2023\n\n post by SEEDGov on Oct 10, 2023\n\n post by iZUMi_Finance on Oct 10, 2023\n\n post by Michigan_Blockchain on Oct 11, 2023\n\n Michigan_Blockchain\n\n Michigan Blockchain supports this proposal with the requested amount being justified given the sustainable benefits to the Arbitrum ecosystem and having conducted an in-depth reviewal process of all submitted STIP proposals. We appreciate Angle Protocol’s effort in delivering a promising proposal and working with the community throughout the process.\n\n post by ITUblockchain on Oct 12, 2023\n\n ITUblockchain\n\n Firstly, we want to thank the team for considering the feedback of community and taking action towards it. We think this proposal fits with the aim of the grant as it supports the adoption of RWA and Euro stablecoins on Arbitrum. The grant will be used to incentivize stEUR pools, which will lead to stEUR stakers’ migration to Arbitrum. Considering this, we are giving our vote in favor of this proposal.\n\n post by ITUblockchain on Oct 12, 2023\n\n ITUblockchain\n\n First of all, thank you for the detailed proposal. We want RWAs to have a more active market on Arbitrum. We believe this could create TVL for Arbitrum. The incentives provided are sufficient to move both users and assets from other networks.\nWe support the proposal and are voting “For” in the poll.\n\n 3 months later\n\n post by pan on Jan 16, 2024\n\n pan\n\n I am very happy to see that the project team has made good progress. Please continue to work hard and contribute to ecological prosperity.\n\n post by pzi on Jan 17, 2024\n\n pzi\n\n Great progress has been made again, congratulations\n\n Related topics\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] ANGLE STIP Bridge Addendum\n\n STIP Bridge Addendum\n\n 16\n\n 1.0k\n\n Jun 2024\n\n Angle Protocol (stUSD & stEUR) STEP Application - STEP Application\n\n STEP Applications & Updates\n\n 0\n\n 746\n\n Apr 2024\n\n [Curve] [FINAL] [STIP - Round 1]\n\n Short Term Incentives Program (STIP) Round 1\n\n proposal\n\n 23\n\n 4.6k\n\n Oct 2023\n\n Angle Protocol Bi-Weekly Updates\n\n Biweekly Updates (STIP)\n\n 10\n\n 1.3k\n\n May 2024\n\n [Range Protocol] [FINAL] [STIP - Round 1]\n\n Short Term Incentives Program (STIP) Round 1\n\n proposal\n\n 9\n\n 2.0k\n\n Oct 2023","tokens":722,"squid":"spider-07","role":"Council Spider","at":1791345623236,"hash":"799bd094f0262d9c660a5eadfea87b5af7ae1b51"}
{"url":"https://www.metaplex.com/docs/solana/solana-transaction-fundamentals","domain":"metaplex.com","title":"Solana Transaction Fundamentals | How Transactions Work","text":"A comprehensive guide to understanding how Solana transactions work from structure to confirmation. What You'll LearnThe anatomy of a Solana transactionHow to sign and send transactionsTransaction confirmation and finalityVersioned transactions vs legacyCommon transaction errors and their meaningsPrerequisitesSolana CLI installedUnderstanding Solana accountsTransaction AnatomyA Solana transaction consists of several components:┌─────────────────────────────────────────────────────────────┐\n│ Transaction │\n├─────────────────────────────────────────────────────────────┤\n│ Signatures: [sig1, sig2, ...] │\n│ │\n│ Message: │\n│ ├── Header │\n│ │ ├── num_required_signatures │\n│ │ ├── num_readonly_signed_accounts │\n│ │ └── num_readonly_unsigned_accounts │\n│ │ │\n│ ├── Account Keys: [pubkey1, pubkey2, ...] │\n│ │ │\n│ ├── Recent Blockhash │\n│ │ │\n│ └── Instructions: [ │\n│ { program_id_index, accounts, data }, │\n│ { program_id_index, accounts, data }, │\n│ ] │\n└─────────────────────────────────────────────────────────────┘\nKey ComponentsComponentDescriptionSignaturesEd25519 signatures from required signersRecent BlockhashA recent block hash (valid for ~60-90 seconds)InstructionsThe operations to performAccount KeysAll accounts involved in the transactionInstructionsInstructions are the actual operations in a transaction. Each instruction specifies:Program ID - Which program to executeAccounts - Which accounts the program needsData - Serialized arguments for the programInstruction:\n ├── program_id: 11111111111111111111111111111111 (System Program)\n ├── accounts:\n │ ├── sender (signer, writable)\n │ └── recipient (not signer, writable)\n └── data: [encoded transfer amount]\nMultiple InstructionsTransactions can contain multiple instructions that execute atomically:import { transactionBuilder } from '@metaplex-foundation/umi'\n\n// All instructions succeed or all fail (atomic)\nconst builder = transactionBuilder()\n .add(createAccountInstruction)\n .add(initializeMintInstruction)\n .add(mintTokensInstruction)\n\nawait builder.sendAndConfirm(umi)\nThis atomicity is powerful. If any instruction fails, the entire transaction is reverted.Recent BlockhashEvery transaction requires a recent blockhash that:Proves the transaction was created recentlyPrevents replay attacksExpires after ~60-90 seconds (~150 slots)// UMI handles blockhash automatically when sending transactions.\n// To fetch it manually:\nconst { blockhash, lastValidBlockHeight } = await umi.rpc.getLatestBlockhash()\nBlockhash ExpirationIf your transaction isn't confirmed before the blockhash expires, it will be dropped. For long-running operations, fetch a fresh blockhash before sending.Signing TransactionsTransactions must be signed by all accounts marked as isSigner:// UMI signs automatically with the identity signer when sending.\n// For additional signers, pass them during the build:\nconst tx = await myBuilder\n .setBlockhash(await umi.rpc.getLatestBlockhash())\n .buildAndSign(umi)\n\n// For partial signing (multi-sig workflows), you can sign\n// and serialize the transaction, then pass it to another party:\nimport { base64 } from '@metaplex-foundation/umi/serializers'\n\nconst serialized = umi.transactions.serialize(tx)\nconst encoded = base64.deserialize(serialized)[0]\n// ... send encoded string to another party for additional signing ...\nSending TransactionsBasic Send// Send and wait for confirmation (recommended)\nconst result = await myBuilder.sendAndConfirm(umi)\n\n// Or just send without waiting\nconst signature = await myBuilder.send(umi)\nSend with Optionsconst result = await myBuilder.sendAndConfirm(umi, {\n send: { skipPreflight: false },\n confirm: { commitment: 'confirmed' },\n})\nTransaction ConfirmationSolana has multiple commitment levels indicating transaction finality:CommitmentDescriptionUse CaseprocessedTransaction received by leaderReal-time updatesconfirmedVoted on by supermajorityMost applicationsfinalized31+ blocks deep, irreversibleFinancial operationsChecking Confirmation// sendAndConfirm waits for confirmation automatically.\n// To check a signature status manually:\nconst result = await umi.rpc.getSignatureStatuses([signature])\nCommitment in Practice// For most operations, 'confirmed' is the right default\nconst result = await myBuilder.sendAndConfirm(umi, {\n confirm: { commitment: 'confirmed' },\n})\n\n// For financial operations where you need full finality\nconst result = await myBuilder.sendAndConfirm(umi, {\n confirm: { commitment: 'finalized' },\n})\nVersioned TransactionsSolana supports three transaction formats:Legacy TransactionsLegacy transactions use Solana's original transaction format without Address Lookup Tables.Original formatLimited to 35 accountsSimpler structureV0 TransactionsV0 transactions add Address Lookup Table support for transactions that need more accounts.Support Address Lookup Tables (ALTs)Can reference up to 256 accountsRequired for complex DeFi operationsV1 TransactionsV1 transactions increase the transaction size limit and store compute configuration in the message.Support transactions up to 4,096 bytesStore compute budget configuration in the transaction messageDo not support Address Lookup Tables// Umi uses V0 transactions by default. Opt in to V1 explicitly.\nconst result = await myBuilder\n .useV1()\n .sendAndConfirm(umi)\n\n// To use legacy transactions instead\nconst result = await myBuilder\n .useLegacyVersion()\n .sendAndConfirm(umi)\n\n// With Address Lookup Tables\nimport { createLut } from '@metaplex-foundation/mpl-toolbox'\n\nconst [lutBuilder, lut] = createLut(umi, {\n recentSlot: await umi.rpc.getSlot({ commitment: 'finalized' }),\n addresses: [addressA, addressB, addressC],\n})\nawait lutBuilder.sendAndConfirm(umi)\n\n// Address Lookup Tables require V0.\nawait myBuilder\n .useV0()\n .setAddressLookupTables([lut])\n .sendAndConfirm(umi)\nChoosing a Transaction VersionUse V1 for transactions larger than 1,232 bytes when the wallet supports transaction version 1.Use V0 when the transaction requires an Address Lookup Table.Use legacy transactions only when compatibility requires the original format.Umi defaults to V0 for backward compatibility. See Migrating from V0 to V1 Transactions before changing the application-wide default.Transaction Size LimitsSolana transactions have strict size limits:LimitValueLegacy and V0 transaction size1,232 bytesV1 transaction size4,096 bytesAddress Lookup TablesV0 onlyMaximum instructionsLimited by sizeDealing with Size LimitsIf your transaction is too large:Use V1 - Increase the size limit to 4,096 bytes when no Address Lookup Table is requiredUse Address Lookup Tables with V0 - Compress account referencesSplit into multiple transactions - Execute sequentiallyOptimize instruction data - Minimize serialized dataSimulationBefore sending, simulate transactions to catch errors:// Build the transaction without sending\nconst tx = await myBuilder\n .setBlockhash(await umi.rpc.getLatestBlockhash())\n .buildAndSign(umi)\n\n// Simulate it\nconst simulation = await umi.rpc.simulateTransaction(tx, {\n commitment: 'confirmed',\n})\nconsole.log('Simulation result:', simulation)\nSimulation helps you:Catch errors before paying feesEstimate compute unitsDebug program logicCommon Transaction Errors\"Blockhash not found\"Cause: The blockhash expired before confirmation.Solutions:Retry with a fresh blockhash (UMI fetches a new blockhash automatically on each send)Use 'finalized' commitment for blockhash when network is congestedImplement retry logic in your application\"Insufficient funds\"Cause: Account doesn't have enough SOL for transaction fees + rent.Solution: Ensure the fee payer has sufficient balance:solana balance\nsolana airdrop 1 # On devnet\n\"Transaction simulation failed\"Cause: Program logic error.Solution: Check simulation logs on an explorer (see Using Solana Explorers), or simulate the transaction before sending to inspect the error output.\"Account not found\"Cause: An account in the transaction doesn't exist.Solution: Create the account first or check addresses.\"Invalid account owner\"Cause: Account is owned by a different program than expected.Solution: Verify account ownership matches the program you're calling.Practical Example: Complete Flowimport { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\nimport { transferSol } from '@metaplex-foundation/mpl-toolbox'\nimport { signerIdentity, generateSigner, sol, publicKey } from '@metaplex-foundation/umi'\nimport { base58 } from '@metaplex-foundation/umi/serializers'\n\n// 1. Create UMI instance\nconst umi = createUmi('https://api.devnet.solana.com')\n\n// 2. Set up signer (your wallet)\nconst signer = generateSigner(umi)\numi.use(signerIdentity(signer))\n\n// 3. Build and send the transaction\nconst result = await transferSol(umi, {\n source: umi.identity,\n destination: publicKey('RecipientAddressHere...'),\n amount: sol(1),\n}).sendAndConfirm(umi)\n\n// 4. Get the transaction signature\nconst signature = base58.deserialize(result.signature)[0]\nconsole.log('Transaction confirmed:', signature)\nconsole.log(`Explorer: https://explorer.solana.com/tx/${signature}?cluster=devnet`)\nNext StepsCompute units and priority fees - Optimize transaction landingWorking with devnet and testnet - Test your transactionsDiagnose transaction errors - Debug failed transactionsFAQHow long do I have to confirm a transaction?A transaction's blockhash is valid for approximately 60-90 seconds (~150 slots). After that, the transaction will be dropped if not confirmed.Can I cancel a transaction?No, once submitted, you cannot cancel a transaction. However, if it hasn't been confirmed, you can submit a new transaction with the same nonce (using durable nonces) to effectively \"replace\" it.What's the difference between \"processed\" and \"confirmed\"?\"Processed\" means a validator received it. \"Confirmed\" means a supermajority (66%+) of validators voted on the block containing it. Always use \"confirmed\" or \"finalized\" for important operations.Why did my transaction fail after simulation succeeded?State can change between simulation and execution. Another transaction may have modified the accounts. This is common in competitive scenarios like NFT mints.","tokens":2528,"squid":"dotcat","role":"Tooling Spider","at":1791345629755,"hash":"5dbff026f39d4d7a9f4c678fd36d31f81ce36887"}
{"url":"https://akash.network/docs/api-documentation/rest-api/","domain":"akash.network","title":"Console API — Network Data | Akash Network - Your Guide to Decentralized Cloud","text":"Console API — Network Data Public, read-only Console API for indexed network data. No authentication required.\nThis API serves indexed data (providers, GPU availability, network stats). It is not an Akash node — do not use it to query chain state or broadcast transactions. For querying the blockchain directly, use Node API Layer (gRPC, REST, RPC).\nBase URL: https://console-api.akash.network\n\nAvailable Endpoints\nProviders\nQuery provider details, hardware specs, GPU models, and availability:\n\nProviders API Reference — GET /v1/providers and GET /v1/providers/{address}\nGPU Availability Guide — Find and filter GPU resources across the network\n\nQuick Example\nList all providers on the network:\nTerminal windowcurl https://console-api.akash.network/v1/providers\nGet details for a specific provider:\nTerminal windowcurl https://console-api.akash.network/v1/providers/akash1u5cdg7k3gl43mukca4aeultuz8x2j68mgwn28e\n\nKey Features\n\nIndexed data, not a node — Aggregated network data from Console; for raw chain queries use Node API Layer\nNo authentication — All endpoints are public and read-only\nJSON responses — Standard REST API returning JSON\nProvider data — Hardware specs, GPU models, uptime, location, and real-time capacity (indexed)\nNetwork statistics — Active/available/pending resources across the network\n\nQuestions? Join Discord #developers channel! \nEdit page on github\n API Reference Providers API","tokens":352,"squid":"spider-03","role":"Compute Spider","at":1791345634674,"hash":"2219f7fdc85c439b7356f986619b052cdd3ed381"}
{"url":"https://forum.arbitrum.foundation/t/curve-final-stip-round-1/17198","domain":"forum.arbitrum.foundation","title":"[Curve] [FINAL] [STIP - Round 1] - Archive / Short Term Incentives Program (STIP) Round 1 - Arbitrum","text":"The Arbitrum Foundation notified the Security Council on the need to perform a potential Emergency action. Following a review of the details and known risks, the Security Council decided to execute the upgrade and it was completed at 11:30 EST on 2nd October 2026.\nThis report provides an overview of the risks that required the Security Council Action:\n\nAdd a permissionless guard for the One-Step Proof of BoLD on Arbitrum One\n\nTemporarily pause activation of new Stylus contracts on Arbitrum One & Nova\n\nKey point: To date, known bugs for Stylus primarily impact chain liveness (e.g., denial of service attacks) and do not put any user funds at risk.\nWhy was this action taken\nLet’s take this opportunity to explain why action was taken on two separate issues concerning BoLD and Stylus.\nInstalling the guard for One-Step Proof of BoLD. Given the rise of AI-assisted attacks, we have implemented a precautionary approach that allows anyone to pause settlement of Arbitrum One on Ethereum if there are at least two conflicting answers that pass at the same level in which only one should be valid and pass. This is to halt a class of publicly verifiable and detectable attacks that exploit a bug in the one-step proof. If halted, Arbitrum One will continue to process as normal except that messages from Arbitrum One to Ethereum, such as withdrawals, that are not yet confirmed will have to wait. This provides time for the Security Council to deploy a fix for the bug and resume the rollup.\nPreventing activation of new Stylus contracts. AI-assisted tooling has led to an increasing number of sophisticated attacks on hand-crafted WASM programs that do not use the standard Stylus compiler toolchain. These programs are specifically designed to cause unexpected behaviors such as degrading the chain’s performance for all other users. To date, no attacks have been discovered that permits theft of user funds.\nNew ArbOS releases have patched several reported bugs and known attacks over the past few months, but out of an abundance of caution, we have decided to temporarily pause new activations of Stylus contracts. This was executed as an emergency action to prevent the deployment of new hand-crafted WASM programs that are not yet patched by the current version of ArbOS on the Arbitrum network.\nThe Arbitrum Foundation has informed the Security Council that they will work with the ArbitrumDAO to discuss next steps on the timeline and manner for enabling activation of new Stylus contracts. The Arbitrum community remains confident in the value of Stylus and want to preserve these use cases while taking preventative measures against Stylus-based attack vectors as AI-assisted attack tooling continues to evolve.\nImpact on builders and users\n\nNo new activations. New Stylus contracts cannot be activated during the pause including new versions of existing applications that require activation.\n\nExisting contracts are not paused. Already-active Stylus contracts continue to execute until expiration. This pause does not deactivate them.\n\nThe ArbOS 61 upgrade renewed all active contracts on Arbitrum One, so no currently active contract expires before August 20, 2027.\n\nRenewal via keepalive stays permissionless and is unaffected by the pause.\n\nReactivating an expired contract, or one that needs to be updated after a Stylus version change, is paused.\n\nUsing/calling any activated Stylus contract stays permissionless for all users and developers.\n\nNo impact on EVM. Solidity (EVM) contract deployment and execution are unaffected by this Security Council action.\n\nSecurity Council Actions\nThere are two actions bundled into a single payload:\n\nOne-Step Proof Guard. The L1UpgradeExecutor gives a new pause contract (PauseExecutor) the ability to pause and nothing else. The new pause contract grants the guard (OspSoundnessGuard) PAUSER_ROLE to use it. Anyone can show the guard two conflicting answers to the same step of an open challenge. If the one-step proof accepts both, the guard has the pause contract put Arbitrum One’s settlement to Ethereum on hold.\n\nStylus deactivation. The Security Council called ArbOwner.setWasmActivationGas(2^64 - 1) to raise the Stylus activation gas requirement on Arbitrum One and Nova. This makes activation prohibitively expensive and effectively disables new activations. This is a configuration change and does not require an ArbOS upgrade.\n\nThe Security Council signed the following transactions to update the configuration:\n\nEthereum: Ethereum Transaction Hash: 0x30732bb7d2... | Etherscan\nArbitrum One:\nArbitrum One Transaction Hash: 0x9eb3a4be3b... | Arbitrum One\nArbitrum Nova:\nArbitrum Nova transaction 0x79e0fed470dff7a22059b108e3f8f42eddd2b580a6771594060c4e7326c5f984 | Blockscout\n\nAn external audit was conducted for the OSP Guard contracts. No audit is required for the Stylus deactivation as it is only updating a single parameter in the ArbOS configuration.\n\n [Curve] [FINAL] [STIP - Round 1] \n\n ArchiveShort Term Incentives Program (STIP) Round 1\n\n proposal\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Sep 2023\n\n 1 / 25\n\n Sep 2023\n\n Oct 2023\n\n post by WormholeOracle on Sep 26, 2023\n\n WormholeOracle\n\n SECTION 1: APPLICANT INFORMATION\nProvide personal or organizational details, including applicant name, contact information, and any associated organization. This information ensures proper identification and communication throughout the grant process.\nApplicant Name:\nLlama Consulting Ltd.\nProject Name:\nCurve Finance\nProject Description:\nCurve is a multichain AMM exchange that specializes in low slippage stablecoin swaps and concentrated liquidity provision. Curve distinguishes itself as the primary liquidity hub for some of the most exciting DeFi innovations, including stablecoins, Liquid Staking Tokens, and Real World Assets. More recently, it has launched its own stablecoin, crvUSD, creating new opportunities for DeFi integrations.\nProject Links:\n\nWebsite - https://www.curve.fi/\nTwitter - https://twitter.com/CurveFinance\nTelegram - http://t.me/curvefi\nGithub - Curve · GitHub\nDocumentation - Procotol Overview — Curve 1.0.0 documentation\n\nTeam Members and Qualifications:\nWormholeOracle and Svetlin Konsulov\nLlama Consulting Ltd. is the legal entity governing Llama Risk, an independent risk consulting non-profit organization funded by the Curve DAO. It has been operating since 2021 with management by its founding member and Director of Llama Consulting Ltd., WormholeOracle. Svetlin is the legal counsel for Llama Risk and the sole shareholder of Llama Consulting Ltd. Although an independent org, the group, and its members have a history of working closely with the Curve team and community and have represented the DAO in the past to pursue grants for Curve (see our approved proposal for an Optimism Grant)\nContact Information:\n\nTG: @WormholeOracle\nTwitter: https://twitter.com/LlamaRisk\nEmail: wormhole@llamarisk.com\n\nDo You Acknowledge That Your Team Will Be Subject to a KYC Requirement?:\nYes\nSECTION 2: GRANT INFORMATION\nDetail the requested grant size, provide an overview of the budget breakdown, specify the funding and contract addresses, and describe any matching funds if relevant.\nRequested Grant Size:\n1.6M ARB = 100,000 ARB per week for 16 weeks\nGrant Breakdown:\nCurve has been deployed on Arbitrum since September 2021 and has been incentivizing certain pools with its own CRV emissions since inception. A quick breakdown of Arbitrum Curve pools that have undergone DAO votes to receive CRV emissions and are currently active:\n\nPool\nGauge Active Since\n\nUSDC.e-USDT (2pool)\nApril 15th, 2022\n\nFRAX/USDC.e (FraxBP)\nAugust 15th, 2022\n\nVST/FRAX\nFebruary 28th, 2022\n\nWBTC/tBTC\nJune 2nd, 2023\n\nEURS/2pool metapool\nNovember 10th, 2021\n\naxlUSDC/FraxBP metapool\nMarch 28th, 2023\n\nUSD+/FraxBP\nJuly 31st 2023\n\nCurve is eager to begin allocating incentives toward a new strategy that will promote crvUSD migration to Arbitrum and will strengthen liquidity depth and trade volumes for both stablecoins and blue-chip crypto (BTC and ETH) on Arbitrum. The strategy involves the deployment of extremely low-fee stableswap pools paired with crvUSD (.01% swap fee) and a crvUSD-paired tricrypto pool (crvUSD/ETH/tBTC).\ncrvUSD is an overcollaterized stablecoin backed by a diverse set of collateral, including sfrxETH, wstETH, WBTC, WETH, and tBTC. The stablecoin was deployed in March 2023 and has reached a market cap of >$100m since inception. Its primary innovations are the LLAMMA AMM which gradually liquidates positions, and a dynamic monetary policy that adjusts interest rates based on market dynamics. Supporting the growth of crvUSD on Arbitrum will help Arbitrum become a hub for the adoption of decentralized stablecoins and enable the creation of new DeFi markets as deep crvUSD liquidity becomes available through Curve.\nThis grant will be used exclusively to incentivize liquidity in Arbitrum Curve pools. We intend to handle the distro with the following strategy:\n\nAllocate 100k ARB per week for 16 weeks as liquidity incentives\n\n20k ARB each to 3 stableswap pools paired with crvUSD (e.g. crvUSD/USDT, crvUSD/USDC, crvUSD/FRAX)\n40k ARB to the tricrypto pool paired with crvUSD (e.g. crvUSD/ETH/tBTC)\n\nPending the availability of a vote incentives market, the ARB may be either deployed as vote incentives to veCRV voters that allocate CRV gauge emissions to the target pools or, in the absence of an acceptable vote market, the ARB will be deployed to the pool rewards as a direct LP incentive.\nAs we are submitting this proposal on behalf of Curve DAO, we request that the grant funds be sent to the Curve DAO-controlled Treasury on Arbitrum. The custody of funds is entirely decentralized, governed by veCRV voters and on-chain votes initiated on Ethereum mainnet. There is a relayer that executes commands on Arbitrum, which you can see was tested successfully on May 4th with a transfer of 1 ARB out of the treasury address.\nOnce funds have been received, we will work with the Curve core team to deploy the grant. This will involve creating a contract to handle the distro logic and initiating an on-chain vote to approve the distro strategy as it has been outlined above.\nDistribution will begin shortly after the necessary pools and distro contract have been deployed. On-chain votes take 7 days to execute, after which the incentives can begin. The program will allocate ARB every week until all ARB is distributed after 16 weeks.\nFunding Address:\nThe Curve DAO-controlled Treasury on Arbitrum: Curve: X-Gov L2 Vault | Address: 0x25877b94...3935feF82 | Arbitrum One\nFunding Address Characteristics:\nCurve x-gov is Curve’s system for cross-chain governance involving its implementation of Aragon on-chain DAO on Ethereum mainnet, an L1 broadcaster/L2 relayer, the Arbitrum bridge, and the Arbitrum vault. This allows fully decentralized DAO control of funds held on Arbitrum.\nSECTION 3: GRANT OBJECTIVES AND EXECUTION\nClearly outline the primary objectives of the project and the Key Performance Indicators (KPIs) used to measure success. This helps reviewers understand what the project aims to achieve and how progress will be assessed.\nObjectives\nStrengthening DeFi Bonds\nCurve prides itself in its role as a liquidity hub for a multitude of protocols. Curve is not just a DEX; it is an extended network of DeFi protocols that have integrations and governance stakes in the protocol. Just about any DeFi protocol that issues a stablecoin, RWA, or LST has a significant presence on Curve as its core liquidity hub. This positions Curve as an essential component of a robust ecosystem that can withstand any and all market conditions.\nBoosting Core Liquidity on Arbitrum\nCurve’s stableswap AMM excels for pools involving like-kind assets. LPs are attracted to these pools as a way to earn real yield from swap fees while mitigating the risk of impermanent loss (as assets supplied to Curve pools are expected to be mean reverting). There is an expectation of increased stablecoin assets bridged to Arbitrum as LPs seek superior yield opportunities on Curve.\nStreamlining Liquidity Costs for Ecosystem Projects\nDeep liquidity is essential for the vitality and success of the overall DeFi ecosystem, particularly for applications like money markets, to facilitate protocol liquidations. We intend for this grant to contribute to readily accessible liquidity within the thriving Arbitrum DeFi ecosystem, encompassing major stablecoins and blue-chip crypto assets. By enhancing Curve pools on Arbitrum, we aim to reduce the liquidity cost for all projects on Arbitrum seeking a reliable liquidity solution.\nSustaining Incentives with CRV Emissions\nA short-term incentive program runs the risk of seeing mass liquidity outflows after incentives end. Our goal is to jumpstart demand to Arbitrum that veCRV stakeholders will be motivated to continue allocating CRV emissions toward these pools even after the ARB incentives end. CRV’s emission schedule lasts hundreds of years, giving Curve the means to incentivize liquidity on Arbitrum for years to come.\nKey Performance Indicators (KPIs):\nTo measure the success of this grant, we will use the following key performance indicators:\n\ncrvUSD migration: The total value of crvUSD that migrates to Arbitrum.\nCurve pool TVL: The total value of Curve pool liquidity\nLiquidity utilization: Both overall pool volume and liquidity utilization in the incentivized pools.\n\nHow will receiving a grant enable you to foster growth or innovation within the Arbitrum ecosystem?\nCurve is the backbone of the burgeoning DeFi industry. It touches every piece of the stack and strengthens every integrated protocol. There is an opportunity for Arbitrum to leverage Curve’s foundational role to further support its vibrant ecosystem. Examples of how Curve spurs DeFi integration include:\n\nThe stableswap algorithm, well known for enabling deep liquidity and low slippage swaps, has built a reputation for stabilizing pegs and enhancing stablecoin utility. (e.g. FRAX, 3CRV)\nCurve has a number of integrations with lending markets, yield-bearing derivatives, and real-world assets. Swap fees compound the interest generated from these activities. (e.g. Aave, stETH, STBT)\nHighly configurable V2 pools are unlocking new potential for FX markets and volatile crypto pairs. The concentrated liquidity algorithm offers advantages to LPs and traders, combining a composable AMM design with low-slippage swaps. (e.g. Tricrypto, eursusd)\n\nJustification for the size of the grant:\nReferencing the StakeDAO votemarket, tricrypto pools are being incentivized with around $32k worth of tokens per week. crvUSD pools are being incentivized around $21k worth of tokens per week. This proposal is targeting a comparable value for the Arbitrum incentivized pools. Given an ARB price ~$0.82, the proposed weekly incentives amount to around $32,800/week to the Arbitrum tricrypto pool and $16,400/week to each crvUSD stableswap pool.\nThe incentives will result in a significant influx of crvUSD to Arbitrum, enabling new markets for other applications to integrate. The grant will pay dividends in terms of future potential integrations and does not contribute to any direct selling pressure of the ARB token.\nExecution Strategy:\nOur execution plan includes the following steps:\n\nPool Deployment: The stableswap-ng pool implementation will be used to deploy the stableswap pools. A crvUSD tricrypto pool will also be deployed\nARB Distro Handle Contract: A distribution contract will be deployed for the non-custodial distribution of the ARB tokens.\nIncentive Campaign: Run incentives to the specified Cuve pools for 16 weeks\n\nGrant Timeline:\nThe projected timeline is as follows:\n\nDevelopment: 3 weeks. This is for necessary pool and distro contract deployments. While a relatively simple undertaking, there is some uncertainty about when the stablecoin-ng implementation will be in production. It is currently undergoing an audit.\nOn-chain vote: 1 week. A vote to allocate ARB to the distro contract\nIncentives: Incentives will run for 16 weeks.\n\nSECTION 4: PROTOCOL DETAILS\nProvide details about the Arbitrum protocol requirements relevant to the grant. This information ensures that the applicant is aligned with the technical specifications and commitments of the grant.\nIs the Protocol Native to Arbitrum?:\nNo, Curve is native to Ethereum and has deployed on 12 other chains and L2s. As described above, it has a cross-chain governance system for handling funds on Arbitrum.\nOn what other networks is the protocol deployed?:\nAs per DefiLlama on September 25th, 2023:\n\nEthereum\n$1.808b\n\nArbitrum\n$31.5m\n\nPolygon\n$26.74m\n\nBase\n$23.33m\n\nCelo\n$20.74m\n\nOptimism\n$14.61m\n\nKava\n$12.73m\n\nAvalanche\n$12.55m\n\nGnosis\n$10.38m\n\nFantom\n$2.92m\n\nMoonbeam\n$419,503\n\nAurora\n$17,068\n\nHarmony\n$0\n\nWhat date did you deploy on Arbitrum?:\nSeptember 12th, 2021\nProtocol Performance:\nAs per DefiLlama on September 25th, 2023:\nTVL: $1.963B\nCumulative Revenue: $126.53M\nCumulative Admin Fees Paid to LPs: $126.53M\nCumulative Annual Volume: $90.977B (average $249M/day)\nPast Performance:\nA report by Delphi Digital released in July 2022 pulled data from every trade on the ETH/USDT pair on both Curve Tricrypto and Uniswap and simulated every trade on the opposite venue. It found that price quotes were better on Curve 65% of the time, although it only captured 35% of the volume. This was attributable to the higher gas cost of the more complex Curve pool.\nimage1148×610 11.8 KB\nWhen running the same test on Arbitrum, the “ideal” volume matched the actual volume much more closely, suggesting that Curve performs much better on a cheap gas platform like Arbitrum.\nimage1148×610 11.8 KB\nNot only does Curve have the capacity to offer superior trade execution on L2s like Arbitrum, it offers a superior experience for LPs. Curve uses an internal price oracle and dynamic fees, only updating the price scale if losses from re-pegging are made up for by at least half of the pool profits from fees. While the complex logic makes Curve V2 pools less competitive on mainnet, it is a truly automated market maker designed to protect LPs from erosion of their supplied value through impermanent loss.\nProtocol Roadmap:\nCurve is making strides with the adoption of crvUSD. New pool implementations (tagged -ng) have an EMA oracle used with the Curve LLAMMA algorithm. The roadmap includes plans to make use of Curve LP positions as markets for crvUSD, enabling leveraged liquidity. There are also plans for money markets around crvUSD. Pegkeepers currently support the stablecoin peg and improvements are being made to the PK algorithm.\nCurve is also working to integrate RWAs such as offerings by Matrixdock, Ondo, and others that are tokenized t-bills and overnight reverse repos. These assets have unique challenges to comply with regulations and Curve is working with them to find compliant solutions that unlock reliable yield for DeFi.\nAudit History:\nCurve has been heavily audited. The crvUSD protocol underwent a comprehensive audit by 3 separate audit firms before launch. Every upgrade to the Curve protocol involves audits as part of standard security practice.\nA list of Curve audit reports can be found here. Also, see a crvUSD specific audit by Mixbytes.\nSECTION 5: Data and Reporting\nProvide details on how your team is equipped to provide data and reporting on grant distribution.\nIs your team prepared to create Dune Dashboards according to program requirements for your incentive program?:\nYes, we can provide a dune dashboard that covers the following metrics:\n\ncrvUSD supply on Arbitrum over time\nTVL of incentivized pools over time\nVolume of incentivized pools over time\nLiquidity utilization of incentivized pools over time\n\n 5\n\n 2\n\n read \n\n 9\n min\n\n post by ArbUSER on Sep 27, 2023\n\n post by peter on Sep 27, 2023\n\n post by WormholeOracle on Sep 27, 2023\n\n post by Hubirb on Sep 27, 2023\n\n post by Matt_StableLab on Sep 27, 2023\n\n post by martinkrung on Sep 28, 2023\n\n post by whereismymind on Sep 28, 2023\n\n post by meyaf320219 on Sep 28, 2023\n\n post by Jadmat on Oct 1, 2023\n\n post by WormholeOracle on Oct 2, 2023\n\n post by Tenzent on Oct 2, 2023\n\n post by Matt_StableLab on Oct 3, 2023\n\n post by WormholeOracle on Oct 3, 2023\n\n Closed on Oct 3, 2023\n\n post by cliffton.eth on Oct 3, 2023\n\n post by CastleCapital on Oct 4, 2023\n\n post by BlockworksResearch on Oct 4, 2023\n\n post by iZUMi_Finance on Oct 9, 2023\n\n post by SEEDGov on Oct 10, 2023\n\n Load more posts below","tokens":5126,"squid":"spider-07","role":"Council Spider","at":1791345634721,"hash":"69210732fe3a38925baf2cd3e96e8961ffd0ebd0"}
{"url":"https://forum.across.to/t/tokenomics-liquidity-incentives-pair-acx-w-across-lp-tokens/1681","domain":"forum.across.to","title":"Tokenomics & Liquidity Incentives: Pair ACX w Across LP Tokens - Ideas & Feedback - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n Tokenomics & Liquidity Incentives: Pair ACX w Across LP Tokens \n\n Ideas & Feedback\n\n liquidity\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jul 2023\n\n 1 / 3\n\n Jul 2023\n\n Aug 2023\n\n post by eth-wei-trader on Jul 19, 2023\n\n eth-wei-trader\n\n I believe we can improve ACX liquidity while also paying for bridge liquidity - killing two birds with one stone.\nWe should pair ACX with Across LP tokens such as USDC, USDT, DAI, ETH, and WBTC on Balancer and incentivize that under a single reward locking mechanism that distributes ACX incentives. This will mean we’re paying for bridge liquidity and ACX liquidity in a single swoop. This will also be an example to the broader ecosystem that Across LP tokens can be used as superfluid collateral to earn yield.\nI’ll consider the exact incentive amount and distribution between the Across LP tokens as follow-on considerations, but I believe this idea is significantly better than incentivizing ACX liquidity and bridging LP tokens separately which significantly hurts ACX’s tokenomics.\n\n 2\n\n 1 month later\n\n post by Kevin_UMA on Aug 22, 2023\n\n Kevin_UMA\n\n I forgot to reply to this idea. Wouldn’t we need pools for Across LP tokens against WETH or USDC? In order for there to be liquidity to trade ACX vs ETH or USDC we would need to make Across LP tokens liquid as well. This seems very tricky. I think trying to figure out how to use Across LP tokens as collateral to borrow could be a starting point, but that I already see has some issues/concerns.\nIt’s an interesting idea though.\n\n post by eth-wei-trader on Aug 22, 2023\n\n eth-wei-trader\n\n CoW searchers or aggregators can simply add the functionality to withdraw from the Across LP tokens as needed within the swap transaction. For example, if ACX is paired with the Across USDC Bridge LP, then unwrapping is done as needed at the time of the swap so that the user always gets USDC or ACX, not the intermediate bridge LP.\nMain downside is that it adds gas to swaps, but I think the pro of matching bridge liquidity with ACX liquidity outweighs that con.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n $ACX Liquidity - Update and Feedback Wanted\n\n Ideas & Feedback\n\n Ideas & Feedback\n\n 7\n\n Jun 2023\n\n Reduce or Reallocate Across ACX LP emissions\n\n Ideas & Feedback\n\n liquidity\n\n Ideas & Feedback\n\n 2\n\n Sep 2023\n\n Across ($ACX) Community Initial Liquidity Proposal\n\n Passed Proposals\n\n Passed Proposals\n\n 49\n\n Nov 2022\n\n Build liquidity for $ACX on Velodrome\n\n Active Proposals\n\n treasury-funding\n\n Active Proposals\n\n 8\n\n Jul 2023\n\n Discontinue ACX Bribes on Aura and Replace with Reward Locking in the Near Term\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 5\n\n Jul 2023","tokens":2172,"squid":"spider-09","role":"Bridge Spider","at":1791345644157,"hash":"51bacbd24a30487f8e236c5e831ab3abfe904400"}
{"url":"https://gov.optimism.io/t/draft-gf-phase-1-proposal-curve/3089","domain":"gov.optimism.io","title":"[DRAFT] [GF: Phase 1 Proposal] Curve - ARCHIVED & OLD Missions / Governance Fund: Phase 1 - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n [DRAFT] [GF: Phase 1 Proposal] Curve \n\n ARCHIVED & OLD MissionsGovernance Fund: Phase 1\n\n cycle-8,season-2\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jul 2022\n\n 1 / 117\n\n Jul 2022\n\n Jul 2023\n\n post by WormholeOracle on Jul 24, 2022\n\n WormholeOracle\n\n Project Name: Curve\nAuthor Name: WormholeOracle (Discord: WormholeOracle#6470, TG: @WormholeOracle)\nI understand that I will be required to provide additional KYC information to the Optimism Foundation to receive this grant: Yes\nL2 Recipient Address: 0xD166EEdf272B860E991d331B71041799379185D5\nWhich Voting Cycle are you applying for?: Cycle #8\nGrant category: DeFi\nIs this proposal applicable to a specific committee? DeFi committee\nProject description: Curve is a multichain AMM exchange specializing in concentrated liquidity. Curve is designed for extremely efficient stablecoin trading and low risk, supplemental fee income for liquidity providers.\nProject links:\nWebsite: https://curve.fi\nTwitter: @CurveFinance\nDiscord/Discourse/Community: Discord: Curve Finance, Telegram: Contact @curvefi\nPlease include all other relevant links below: Curve on Optimism- https://optimism.curve.fi/\nAdditional team member info: Curve Founder TG handle- @michwill\nPlease link to any previous projects the team has meaningfully contributed to: Michael was a founder and CTO of NuCypher, now known as Threshold Network.\nRelevant Usage Metrics:\n\nTVL on Optimism: $31.73m\n\nTVL across all chains: $5.67B\n\nWeekly volume on Optimism: $7,142,872\n\nA fantastic Dune Analytics dashboard for Curve metrics\n\nData sourced on August 28, 2022\nCompetitors, peers, or similar projects: Uniswap\nIs/will this project be open sourced? Yes\nOptimism native?: No\nDate of deployment/expected deployment on Optimism: Currently Deployed\nEcosystem Value Proposition:\nCurve is the backbone of the burgeoning DeFi industry. It touches every piece of the stack and strengthens every integrated protocol. There is opportunity for Optimism to leverage Curve’s foundational role to further support its vibrant ecosystem.\nApplications integrated into Curve have realized novel use cases. Synthetix heavily utilizes Curve for synth liquidity. Their atomic swap functionality recently integrated with Curve has produced staggering revenues for Synthetix stakers.\nThe stableswap algorithm, well known for enabling deep liquidity and low slippage swaps, has built a reputation for stabilizing pegs and enhancing stablecoin utility. See: FRAX, 3CRV\nCurve has a number of integrations with lending markets and yield bearing derivatives. Swap fees compound the interest generated from these activities. See: Aave, stETH\nHighly configurable V2 pools are unlocking new potential for FX markets and volatile crypto pairs. The concentrated liquidity algorithm offers advantages to LPs and traders, combining a composable AMM design with low slippage swaps. See: Tricrypto, eursusd\nCurve also needs Optimism. A recent Delphi article demonstrated that although Curve regularly quotes better pricing than competitors, it underperforms on volume due to mainnet gas costs. Curve requires a scalable L2 where it can absorb liquidity and realize its potential. Optimism is the ideal partner in this regard.\nHas your project previously applied for an OP grant? No\nNumber of OP tokens requested: 504,828\nDid the project apply for or receive OP tokens through the Foundation Partner Fund?: In Process\nIf OP tokens were requested from the Foundation Partner Fund, what was the amount?: Undetermined, in process\nHow much will your project match in co-incentives?\nThe distribution method will ensure that Curve matches incentives with its own emissions. As will be explained in the token distribution section, OP will be used as vote incentives to pay veCRV voters who gauge weight Optimism pools. While not possible to predict the dollar value of emissions from this strategy, historically >$1 of emissions are produced from $1 of reward deposits. It is commonly considered a capital efficient way to attract TVL, and would create a market dynamic that guarantees Curve will be offering co-incentives.\nAdditionally, a virtuous cycle is created from the bootstrapping phase. Increased incentives attract LPs → Influx of liquidity stimulates utility of Optimism pools → Utility incentivizes veCRV to more heavily weight those pools → Incentives attract more LPs to Optimism.\nCurve’s inflation schedule takes place over the course of ~250 years, so Optimism can be confident that there are many years of incentives ahead.\nProposal for token distribution:\nHow will the OP tokens be distributed?\n100% of OP will be distributed as vote incentives for veCRV voters who direct CRV emissions toward Optimism pools.\nCurve Gauge\n\nveTokenomics, first implemented by Curve, give vote locked tokenholders control over directing inflationary token emissions. A popular strategy used by many protocols is to exchange their native token for Curve emissions to their pools. The OP will be distributed in much the same way, offered as incentives for “gauge weighting”.\nCurve uses a gauge weight mechanism, the process which directs CRV emissions. Pools receive a gauge by passing an on-chain DAO vote. veCRV owning governance participants vote weekly on where to allocate inflation, which may be pools on any network, including Optimism.\nEach week, the RootChainGauge on Ethereum mints all CRV emissions of the previous week and transfers them over the Optimism bridge where they are received to a ChildChainGauge contract deployed to the same address. After checkpointing, they are transferred to the ChildGaugeFactory, the contract which handles distribution to all gauges on Optimism.\n\nContract Name\nContract Address\n\nChildGaugeFactory\n0xabC000d88f23Bb45525E447528DBF656A9D55bf5\n\nThis decentralized mechanism for rewards distribution distributes CRV to LPs. There are currently five pools with gauge on Optimism (sUSD, sETH, sBTC, 3pool, and FraxBP), although the number of pools and opportunities for LPs will be increasing over time.\nCurrent Optimism Gauges Eligible for Incentives:\n\nPool Name\nGauge Contract\n\nsUSD\n0xc5aE4B5F86332e70f3205a8151Ee9eD9F71e0797\n\nsETH\n0xCB8883D1D8c560003489Df43B30612AAbB8013bb\n\nsBTC\n0x172a5AF37f69C69CC59E748D090a70615830A5Dd\n\n3pool\n0x15F52286C0FF1d7A7dDbC9E300dd66628D46D4e6\n\nFRAXBP\n0x4B960396011A914B4ccCC3b33DFEE83A97A9D766\n\nVotium\n\nVotium is the most widely used service for participating in Curve vote incentives. Depositers can deposit a reward token and specify a specific gauge. Then, during each gauge weight round, CVX and veCRV tokenholders who voted for that gauge can claim their portion of the reward.\nAlthough this process has always taken place on mainnet, the Votium team has agreed to deploy their contracts to Optimism so that OP can be distributed on its native network. They generate a merkle proof from votes cast, so can easily determine the correct value each voter is entitled to, and therefore voters simply claim rewards from their Optimism address.\nVotium contracts deployed to Optimism:\n\nPool Name\nGauge Contract\n\nGnosis Safe\n0x3A84A0517F3175c0F84ac98DDF5045418D751fdd\n\nDeposit address\n0x3299Ef424fd225f07eF614B4C9E8a591490Fb564\n\nFee address\n0x5F9f852d3B04c22a43B44EaC364c91252882C7e8\n\nMerkle Distributor\n0xA4cdaCBf6cD74eaFBB785064B03B9eD11ec377ff\n\nMerkle Controller\n0x25E39DE2678C59983738134d8DA1953D0191e53F\n\nDistribution Plan\n\nWe plan to deposit OP each week as vote incentives to veCRV voters on Votium Optimism. The weekly allotment will be 42,069 OP/week for 12 weeks.\nThe recipient address is a L2 vault smart contract deployed as part of Curve’s cross-chain governance system. Tokens sent to this vault are controlled by veCRV voters on mainnet via on-chain governance, making use of Optimism’s own messaging bridge to relay the data. Funds sent to the contract are only accessible by Curve DAO.\nA distribution contract will be deployed that trustlessly carries out the following strategy. This strategy will be initiated using the cross-chain governance system.\nThe OP rewards will be evenly divided between all existing gauges and deposited each week as vote incentives to Votium Optimism. If a new gauge is added to the gauge controller, it will be added to the distribution in the following weekly cycle.\nThere are currently 5 gauges on Optimism, so each would receive 8,413.8 OP/week of incentives. If a new gauge is voted in, making a total of 6 gauges, each would receive 7,011.5 OP in the next cycle. The median Votium incentives toward CVX in the last 5 bribe rounds has been ~$50k-90k/week by protocol. At current valuation (October 13,2022), the proposed incentive amounts to ~$33k/week, putting it slightly below the median. We expect to see an influx of LPs from mainnet to Optimism as gauge weighting shifts toward Optimism pools as a result of these incentives.\nNote that the proposed strategy for receiving and distributing OP never involves custody of funds by Curve team, some other admin, or any multisig. Management is handled entirely by Curve DAO and the use of trustless smart contracts.\nHow will this distribution incentivize usage and liquidity on Optimism?\nCurve’s stableswap AMM excels for pools involving like-kind assets. LP’s are attracted to these pools as a way to earn real yield from swap fees, while mitigating the risk of impermanent loss (as assets supplied to Curve pools are expected to be mean reverting). This is an expectation of increased assets bridged to Optimism, largely stablecoins, as LPs seek superior yield opportunities on Curve.\nUsers trust the design, implementation, and security of Curve’s contracts. Curve has been live on mainnet since early 2020, and has subsequently expanded to a number of side-chains and L2’s. Its system is robust and battletested. Thanks to the integrity of its team and its brand, Optimism will surely see LP’s onboard en masse to its incentivized pools.\nOnce onboarded, the goal is to retain LPs on Optimism. Early converts incentivized with a stake in the network are more likely to express long term loyalty toward Optimism. Curve LPs are power users, some of the most capable at traversing the DeFi landscape. Whereas most protocols regard liquidity as mercenary, Curve has found an enduring alignment with its LPs, largely thanks to veTokenomics. Optimism has this opportunity to make allies of the best DeFi has to offer.\nWhy will the incentivized users and liquidity remain after incentives dry up?\nCurve’s value proposition has not only attracted individual depositors, but has spawned new categories of DeFi application as protocols build their services around Curve. When these applications establish themselves, liquidity becomes anchored on Curve.\n\nUse case 1: Synthetix and Curve have a deeply intertwined history that began with the need for Synthetix to offer low-slippage exposure to their sTokens. The partnership eventually expanded with the ability to accomplish cross-asset swaps using a combination of Curve and Synthetix. Now atomic swaps are fully realizing this functionality. For example, a user might swap USDC → sUSD on Curve, sUSD → sETH on Synthetix, and sETH → ETH on Curve, all in a single transaction. This is a powerful tool for LPs, who can provide liquidity in a single token without exposure to impermanent loss. Both Curve and Synthetix are seeing a surge in volumes thanks to this functionality.\n\nUse case 2: Yearn was one of the first protocols built on Curve with their Y pool. They essentially invented the yield aggregator that kicked off the farming craze of 2020. Their service involves accepting user stablecoin deposits and optimizing yield on those assets across several lending applications (later expanding to a variety of other strategies). Its viability depends on Curve’s deep liquidity and the assurance that their users can withdraw their stables without suffering impermanent loss. This use case was simply not possible before Curve.\n\nUse case 3: Lido has chosen Curve as the source of liquidity for their liquid staked ETH derivative, stETH. Their service involves accepting user deposits of ETH and staking them on the ETH2 beacon chain. While deposits are temporarily locked before the merge, the stETH pool allows depositors to exit their position back to ETH. The deep liquidity and composability offered by Curve’s stableswap AMM made it an excellent choice for Lido’s integration.\n\nFrom these examples, it is evident that Curve is foundational to the DeFi ecosystem. It does not exist in isolation, but rather as a building block for novel use cases. Once those applications establish themselves, liquidity becomes firmly cemented within Curve, ultimately becoming the fuel that powers the Optimism flywheel.\nOver what period of time will the tokens be distributed?\nThe distribution will take place over 12 weeks (42,069 OP will be distributed weekly for the total of 504,828 OP).\n Feedback Summary from Discussion (Oct. 13, 2022) \nfeedback in bold, followed by author’s response\nThe proposed 5 month distribution is too short, should increase duration.\nThe proposed 1,000,000 OP is too much, should decrease requested amount.\nThe proposal has been revised to be a shorter duration, requesting less funds. The intention is to show positive results for Optimism that will support a case for a second round of incentives in the future.\nNumber of incentivized pools seems limited and mainly Synthetix pools. Core pools should have gauges, such as Tricrypto [ETH, BTC, USDT] and 3pool [USDT, USDC, DAI].\nWhen the proposal was first written, only Synthetix pools had gauges on Optimism. Since then, 3pool and FraxBP have received gauges on Optimism. These are basepools and set a foundation for liquidity on Curve Optimism.\nCurve is not an Optimism native platform, so governance involving addition of gauges and gauge weighting (a requirement for pools to begin receiving OP) would require activity on main net Ethereum. Additionally, the admin fee returns 50% of swap fees to token holders on main net.\nThis line of reasoning takes the position that Ethereum mainnet and Optimism are somehow in competition. While the argument involves ideology, ultimately it is the ambition for Optimism to absorb liquidity most effectively. It is clear that the liquidity Curve draws to Optimism through incentivized pools far outweighs any fees sent to mainnet. Votium will launch contracts for vote incentives on Optimism, so the incentive program will take place directly on Optimism.\nGauge weighting is a decentralized mechanism collectively controlled by all veCRV. This makes a commitment of co-incentives from Curve side an uncertain proposition.\nThe first draft of this proposal planned to distribute OP to Curve LPs, and had no way to predict co-incentives because the gauge weight system is decentralized. The updated proposal instead plans to distribute OP as vote incentives for gauge weighting so there will be an economic motive for voters to direct co-incentives toward Optimism pools. This process historically results in >$1 emissions per $1 of reward deposit (over 100% incentive matching).\nBribes are a more cost effective way to increase TVL\nThis proposal was updated from distribution to LPs to distribution as vote incentives. The Balancer proposal was used as a model for this updated proposal.\nOP reward should be proportional to the amount of CRV allocated to pools each week, as opposed to the fixed rate of distribution laid out in the proposal.\nThis suggestion was made to ensure that CRV is adequately co-incentivizing the pools. The updated proposal addresses the request to guarantee co-incentives from Curve.\nveFunder multisig as recipient address is misleading. Members are not part of Curve core team and therefore possibly a higher risk recipient\nAlthough the official Curve Twitter voiced support of the proposal and veFunder as a recipient, we have opted to create a trustless solution whereby the recipient is a smart contract governed by Curve DAO. Distribution is also handled by a contract. There is no longer any question of recipient trust involved with this proposal.\nDistribution plan is clear and straightforward. OP is not retained by the team/protocol, but instead is distributed entirely to LPs who are Optimism’s user base.\nThis praise was given to the first proposal, which planned to distribute OP to LPs. Now OP is planned to distribute to veCRV voters as gauge weighting rewards, and will be available for claim on Optimism. It remains true that no OP is retained by the team or protocol.\nIncreased incentives on Curve could attract prominent partners such as Lido to make their products the primary venue on Optimism.\nCompetition is not a zero sum game. Increasing TVL on Curve will benefit all trading venues on Optimism.\n\n [Recording & Recap] 22nd OP Community Governance Call\n\n [DRAFT] [GF: Phase 1 Proposal] Abracadabra Money - Cycle #8\n\n Optimism Community Call Recaps & Recordings Thread\n\n ScaleWeb3 - Delegate Communication Thread\n\n DeFi Committee C: Season 2 Recommendations\n\n 17\n\n 11\n\n 10\n\n 7\n\n 6\n\n read \n\n 28\n min\n\n post by mlich on Jul 24, 2022\n\n mlich\n\n Good proporsal curve & optimism\n\n post by diligit on Jul 24, 2022\n\n diligit\n\n I like the proposal. The information is complete. I especially appreciate the detailed information on how the OP tokens are distributed and the distribution period. I would have liked the OP tokens to be distributed over a longer period than 6 months, but 5 months, according to TVL, is acceptable. And I have more confidence that you didn’t rush to apply for governance funding in the first few voting cycles, this is an advantage that the Optimism community knows the project and have time to use the Curve Protocol.\n\n post by frankrx15 on Jul 24, 2022\n\n frankrx15\n\n Good proporsal and good team, I trust you\n\n post by OPUser on Jul 25, 2022\n\n OPUser\n\n Hey @WormholeOracle , Adding all the link here referred in the proposal.\n3 Synthetix (SNX) | Dashboard | Token Terminal\n4 https://curve.fi/files/stableswap-paper.pdf\n5 Curve.fi\n6 Curve.fi\n7 Curve.fi\n8 Curve.fi\n9 Deep Dive: Curve v2 Parameters - nagaking\n10 Curve.fi\n11 Curve.fi\n12 https://members.delphidigital.io/reports/uniswap-vs-curve-which-is-the-best-dex\n13 Gauge Weights - Curve Finance\n14 Contract Address 0xabc000d88f23bb45525e447528dbf656a9d55bf5 | Optimism\n15 Curve.fi\n16 Curve.fi\n17 Curve.fi\n18 Contract Address 0xc5ae4b5f86332e70f3205a8151ee9ed9f71e0797 | Optimism\n19 Contract Address 0xcb8883d1d8c560003489df43b30612aabb8013bb | Optimism\n20 Contract Address 0x172a5af37f69c69cc59e748d090a70615830a5dd | Optimism\n21 Curve.fi\n22 Curve.fi\n23 https://dao.curve.fi/inflation\n\n post by alexcutlerdoteth on Jul 25, 2022\n\n alexcutlerdoteth\n\n Heya - Alex from the Velodrome Team here. Even though I’m Velodrome founder, I’m a big Curve and Convex fan. Got my start following and writing about them! I’ve got a few thoughts and questions.\n\n@WormholeOracle are you a member of the Curve Team? How did this proposal come to be?\n\nAm I correct in understanding all of the economic activity around staking veCRV, bribing for votes, and actual voting for Curve emissions would remain on main-net? So any projects looking to actually engage with the Curve ecosystem (outside of swapping or LPing) will need to do so off of Optimism?\n\nI understand 50% of trading fees on Curve go to LPs and 50% go to veCRV holders, does this mean that 50% of the fees generated by this subsidized liquidity would be routinely transferred off Optimism?\n\nWhen you say that “Curve is currently incentivizing liquidity on Optimism in the form of CRV emissions” you mean that there are veCRV lockers voting for pools such as sUSD-3CRV, right? The Curve Team itself isn’t currently voting for OP pools or offering any matching incentives.\n\nWhy would Curve be asking for 1M in $OP from governance solely to offer pool 2 rewards on Synthetix pools? Didn’t the Synthetix Team already received 7M OP to do just that?\n\nWould be good to understand this before weighing in. \n\n post by millie on Jul 25, 2022\n\n millie\n\n The proposal didn’t say anything about SNX pool 2s to my knowledge…\nThey seem to be directing all the rewards to their highest volume pools (the same L1 synth pools) which are pegged ETH, BTC and USD pools. Those pools generally have 2-3 assets other than synths in them as well.\n\n post by alexcutlerdoteth on Jul 25, 2022\n\n alexcutlerdoteth\n\n Yeah, apologies my note was unclear. I was more looking to understand why (as a Curve proposal) the focus is entirely on incentivizing s asset pools versus the 3pool or CRV or any of the other top main-net pools, especially given the 3M already granted by governance to Synthetix to do that (at least for sUSD). Is intended to be more of a joint Curve/Synthetix proposal?\n\nimage1457×1441 219 KB\n\n post by fiddy on Jul 25, 2022\n\n fiddy\n\n alexcutlerdoteth\n\n From Curve core. I’ll answer here:\n\n@WormholeOracle are you a member of the Curve Team? How did this proposal come to be?\n\nWormhole is a distinguished community member, and a member of the Curve Grants council. He is not a curve core dev.\n\nAm I correct in understanding all of the economic activity around staking veCRV, bribing for votes, and actual voting for Curve emissions would remain on main-net? So any projects looking to actually engage with the Curve ecosystem (outside of swapping or LPing) will need to do so off of Optimism?\n\nYes. Because no such service exists on Optimism (yet) due to technical reasons explained in the next question.\n\nI understand 50% of trading fees on Curve go to LPs and 50% go to veCRV holders, does this mean that 50% of the fees generated by this subsidized liquidity would be routinely transferred off Optimism?\n\nYes this is by design, since there is a technical challenge that has a dependency on Ethereum EIP: Verkle tree integration - HackMD, and could be updated once Ethereum core devs sunset Merkle Patricia Proofs and onboard Verkle Trees.\n\nWhen you say that “Curve is currently incentivizing liquidity on Optimism in the form of CRV emissions” you mean that there are veCRV lockers voting for pools such as sUSD-3CRV, right? The Curve Team itself isn’t currently voting for OP pools or offering any matching incentives.\n\nCurve Stakeholders and veCRV holders vote for sUSD-3CRV.\n\nWhy would Curve be asking for 1M in $OP from governance solely to offer pool 2 rewards on Synthetix pools? Didn’t the Synthetix Team already received 7M OP to do just that?\n\nThis is not a join Synthetix/Curve proposal: this should be clear.\n\n post by chanho on Jul 25, 2022\n\n chanho\n\n alexcutlerdoteth\n\n The proposal is NOT focusing on incentivizing synth pools only. This misunderstanding seems to arise from unfamiliarity with how CRV emissions work.\nCurrently only the synth pools on Optimism are getting CRV emissions (see here). This is why they were used for the example.\nThe way emissions work is they are determined completely by voting from the DAO. Once gauges are voted for inclusion in the periodic gauge weight votes, they will get CRV emissions based on the proportion of voting power they receive.\nNote however that the DAO voting power is comprised of large entities such as Convex, Yearn, etc., in addition to many smaller longtime holders. While unanimous decisions can occur, results often are the result of much compromise and discussion amongst community members.\n\n post by alexcutlerdoteth on Jul 25, 2022\n\n alexcutlerdoteth\n\n I understand, but I think this is a distinction without a difference at the moment.\nYou are saying that until or unless the DAO votes for the inclusion of other non s asset pairs in the gauge weight votes (a process that takes time and buy-in), the requested incentives will only benefit the outlined s asset pools.\nAnd if any other ecosystem projects were to want to try to participate this process by getting their own gauges approved, participate in the gauge weight votes, or bribe for votes for that their only option to do this would be on mainnet.\nThis essentially makes the program inaccessible to Optimism native protocols or new entrants that don’t have existing presences on mainnet or in Curve goveranance.\nThis is all absolutely fine by the way, but at least in my opinion is not the kind of thing that governance should be directly incentivizing. At least until participation in Curve governance is actually possible on Optimism and there is no longer a need for 50% protocol revenue to be shipped off the chain.\nPerhaps Curve could apply for a grant through the partner fund to help to accelerate these kinds of efforts and revisit LP incentive boosts from goverance once they’re further along?\n\n post by alexcutlerdoteth on Jul 25, 2022\n\n alexcutlerdoteth\n\n fiddy\n\n This was very clear! Thank you.\n\n post by fiddy on Jul 25, 2022\n\n fiddy\n\nThis is factually incorrect, since protocols that build on Optimism are not forbidden to use Ethereum (the protocol that secures Optimism). So new protocols can just as easily participate in one of the most decentralised protocol governance processes on Ethereum mainnet to determine how its protocol on Optimism evolves.\nSo I don’t see how it becomes suddenly ‘inaccessible’.\n\n post by tao on Jul 25, 2022\n\n tao\n\n Right, so all an Optimism protocol would need to do is lobby veCRV holders to get gauges approved for their token pairs, then lobby to get a share of the OP rewards.\nOnce the OP incentives run out, they’d have to consistently bridge funds from Optimism to mainnet to build a veCRV position or bribe veCRV holders to continue incentivizing their liquidity.\nBest case for Curve, the CRV wars heat up among Optimism protocols and they all bridge funds to mainnet to compete. Eventually Curve attracts the majority of liquidity and trades on Optimism, and they all automatically route 50% of fees back to mainnet.\nAs a Velodrome team member, I’m biased, but this is not what I’d like for the ecosystem.\n\n post by FantomFunhouse on Jul 25, 2022\n\n FantomFunhouse\n\n The proposal does not seem to have any incentive matching for protocols whose tokens are not already on gauges approved by the Curve DAO for CRV emissions. I don’t think CRV that may be approved in the future by the Curve DAO should be referenced as co-incentives supplied by the protocol in this proposal. The duration of the emission incentive program is also too short.\n\n post by alexcutlerdoteth on Jul 25, 2022\n\n alexcutlerdoteth\n\n fiddy\n\n Fair enough.\nIt is not inaccessible, it’s significantly less accessible. 1M in OP incentives that you can only access if you leave the chain and do some combination of purchasing and staking CRV, persuading mainnet voters to approve your gauge, vote or bribe voters to direct emissions to your pool, etc etc.\nAgain, this is a fine behavior to ask for participation in Curve. But, not if Optimism is the one providing the incentives. There are plenty of existing native options that don’t have these limitations.\nI think any grant would be better served helping the Curve Team remove these barriers first. Then consider juicing the incentives to participation.\n\n post by chanho on Jul 25, 2022\n\n chanho\n\n tao\n\nRight, so all an Optimism protocol would need to do is lobby veCRV holders to get gauges approved for their token pairs, then lobby to get a share of the OP rewards.\n\nThere are other options than lobbying veCRV holders directly, but ultimately garnering support is necessary, as is the case for receiving any emissions from Curve.\n\nAs a Velodrome team member, I’m biased, but this is not what I’d like for the ecosystem.\n\nYou guys have already stated you understand the importance of working with Curve (and Convex) when you airdropped $VELO to veCRV and vlCVX holders:\n\n“$VELO tokens will be distributed to the people who have played the biggest role in incubating Velodrome and those likeliest to contribute to its long-term success”\n\nI assume you were aware all along this is how the protocol works when you airdropped to veCRV holders. I would like to understand where this objection is coming from. Are you are looking out for other protocols on Optimism? They may not be able to marshall the efforts you guys were able to? I would say let’s not underestimate others, including your potential competition.\n\nBest case for Curve, the CRV wars heat up among Optimism protocols and they all bridge funds to mainnet to compete.\n\nBest case perhaps in a static world.\n\n post by OPUser on Jul 25, 2022\n\n OPUser\n\n I would love to take a moment to appreciate how beautifully written this proposal is . Distribution plan is clear with contact address and pool name along with number of token to be distributed in each pool.\nAuthor has left nothing to the readers imagination by providing 25 citation. Thank you @WormholeOracle, this was a good read. To be frank, I still find math behind curve mind boggling but worth a read nonetheless.\nNow coming back to proposal.\nOn co-incentives, from what I understood, curve emission is part of the curve protocol, right ? Its not something special that you are doing only on OP chain ?\nDo you have project or DAO budget in form of CRV ? Will you be able to provide any form of co-incentives ?\n\n post by tao on Jul 25, 2022\n\n tao\n\n chanho\n\n Curve is one of the best protocols in DeFi, and Velodrome exists thanks to it. That’s why we airdropped tokens to veCRV holders.\nThe point though was to attract said veCRV holders into Optimism to participate in the ecosystem.\nAs explained above, without being fully deployed on Optimism, Curve’s success would lead to a direct flow of capital AWAY from Optimism and into Mainnet in the form of fees, bribes, and veCRV acquisitions.\nThis is not in the best interest of Optimism as it tries to grow while competing for resources with other L2s.\n\n post by chanho on Jul 25, 2022\n\n chanho\n\nCurve’s success would lead to a direct flow of capital AWAY from Optimism and into Mainnet in the form of fees, bribes, and veCRV acquisitions.\n\nAs any accountant will tell you, what’s important is net flow. If you are saying this is the net result, that’s a (suspect) claim to know the future. If you claim this is one flow of many, then ok.\nBut keep in mind: the most important flow is from Mainnet to Optimism. Curve will be a strong ally for that.\n\n Load more posts below","tokens":7579,"squid":"spider-07","role":"Council Spider","at":1791345646903,"hash":"a9466f7bd2d7e18a1b07d28b38234b98b88cb26f"}
{"url":"https://forum.across.to/t/tokenomics-liquidity-incentives-pair-acx-w-across-lp-tokens/1681/2","domain":"forum.across.to","title":"Tokenomics & Liquidity Incentives: Pair ACX w Across LP Tokens - Ideas & Feedback - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n Ideas & Feedback\n\n liquidity\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jul 2023\n\n 2 / 3\n\n Aug 2023\n\n Aug 2023\n\n post by eth-wei-trader on Jul 19, 2023\n\n eth-wei-trader\n\n I believe we can improve ACX liquidity while also paying for bridge liquidity - killing two birds with one stone.\nWe should pair ACX with Across LP tokens such as USDC, USDT, DAI, ETH, and WBTC on Balancer and incentivize that under a single reward locking mechanism that distributes ACX incentives. This will mean we’re paying for bridge liquidity and ACX liquidity in a single swoop. This will also be an example to the broader ecosystem that Across LP tokens can be used as superfluid collateral to earn yield.\nI’ll consider the exact incentive amount and distribution between the Across LP tokens as follow-on considerations, but I believe this idea is significantly better than incentivizing ACX liquidity and bridging LP tokens separately which significantly hurts ACX’s tokenomics.\n\n 2\n\n 1 month later\n\n post by Kevin_UMA on Aug 22, 2023\n\n Kevin_UMA\n\n I forgot to reply to this idea. Wouldn’t we need pools for Across LP tokens against WETH or USDC? In order for there to be liquidity to trade ACX vs ETH or USDC we would need to make Across LP tokens liquid as well. This seems very tricky. I think trying to figure out how to use Across LP tokens as collateral to borrow could be a starting point, but that I already see has some issues/concerns.\nIt’s an interesting idea though.\n\n post by eth-wei-trader on Aug 22, 2023\n\n eth-wei-trader\n\n CoW searchers or aggregators can simply add the functionality to withdraw from the Across LP tokens as needed within the swap transaction. For example, if ACX is paired with the Across USDC Bridge LP, then unwrapping is done as needed at the time of the swap so that the user always gets USDC or ACX, not the intermediate bridge LP.\nMain downside is that it adds gas to swaps, but I think the pro of matching bridge liquidity with ACX liquidity outweighs that con.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n $ACX Liquidity - Update and Feedback Wanted\n\n Ideas & Feedback\n\n Ideas & Feedback\n\n 7\n\n Jun 2023\n\n Reduce or Reallocate Across ACX LP emissions\n\n Ideas & Feedback\n\n liquidity\n\n Ideas & Feedback\n\n 2\n\n Sep 2023\n\n Across ($ACX) Community Initial Liquidity Proposal\n\n Passed Proposals\n\n Passed Proposals\n\n 49\n\n Nov 2022\n\n Build liquidity for $ACX on Velodrome\n\n Active Proposals\n\n treasury-funding\n\n Active Proposals\n\n 8\n\n Jul 2023\n\n Discontinue ACX Bribes on Aura and Replace with Reward Locking in the Near Term\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 5\n\n Jul 2023","tokens":2155,"squid":"spider-09","role":"Bridge Spider","at":1791345654327,"hash":"9d82dc4d59f2746b23d3c0c735611cffb17824b8"}
{"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.5k\n\n 29d\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 33\n\n 710\n\n 11h\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 6\n\n 76\n\n 23h\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 3d\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 65\n\n 3d\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 345\n\n 3d\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 3d\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 10d\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 12d\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 468\n\n 14d\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 172\n\n 14d\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 282\n\n 21d\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 129\n\n 28d\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 Sep 6\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 107\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 55\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 85\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 872\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 98\n\n Jul 22","tokens":2610,"squid":"spider-07","role":"Council Spider","at":1791345657946,"hash":"8d879b8c8e2bf9b84a653256b02b3514137f28e0"}
{"url":"https://forum.across.to/t/discontinue-acx-bribes-on-aura-and-replace-with-reward-locking-in-the-near-term/1682","domain":"forum.across.to","title":"Discontinue ACX Bribes on Aura and Replace with Reward Locking in the Near Term - Proposals - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n Discontinue ACX Bribes on Aura and Replace with Reward Locking in the Near Term \n\n Proposals\n\n treasury-funding\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n read \n\n 4\n min\n\n Jul 2023\n\n 1 / 7\n\n Jul 2023\n\n Jul 2023\n\n post by Kevin_UMA on Jul 19, 2023\n\n Kevin_UMA\n\n Title: Discontinue ACX Bribes on Aura and Replace with Reward Locking in the Near Term\nAuthor(s): Kevin Chan\nStatus: Proposal\nRelated Discussions: ACX Bribes on Aura - Reimburse Risk Labs and Plan Forward\nSubmission Date: July 19, 2023\nSummary:\nThe Across DAO has spent 2.9MM ACX (~$136k at current $ACX price of $0.047) on bribes to Aura Finance with the final proposed bribe deposited on July 6, 2023. These bribes helped jumpstart liquidity for the ACX token and created a wstETH / ACX pool on Balancer that is over $1MM in value. We now need to decide whether or not to continue with these bribes. There are a few things to consider since Across first started using Aura. 1) The efficiency of Aura has decreased. When Across first bribed on Aura, each dollar of ACX bribed returned as much as $2.50 in emissions. Now that metric is below $1.20 in emissions per dollar bribed. 2) The Across community has received competing proposals from Velodrome, which would add ACX liquidity on Optimism and claims to provide 2 to 3x efficiency, and Arrakis, which would enhance ACX liquidity on Uniswap v3 and start to build protocol owned liquidity. The Across community will need to weigh these factors to consider whether or not continuing Aura bribes makes sense. If the community decides to discontinue bribes, Across’ reward locking program can be used instead of Aura in the meantime as we work on a resolution to the Velodrome and Arrakis proposals.\nMotivation:\nACX bribes on Aura Finance have helped incentivize liquidity in ACX over the last 7 months. However, the current economics of bribing have changed and alternatives have emerged. Here we summarize some thoughts from community members on each incentive mechanism.\nAura Finance\nAura provides some efficiency gains by providing currently $1 to $1.20 in emissions per dollar bribed. This has come down from as high as $2.50 per dollar bribed. Continuing to use Aura would allow Across to capture some small efficiency and also not disrupt capital already provided on Balancer by LPs. However, the downside to bribes is ACX tokens are given to bribe takers who likely sell these tokens when they receive them as they have no association with Across.\nAcross Reward Locking\nUsing Across reward locking has the benefit of keeping all Across supporters on one UI. Across bridge LPs and LPs who provide liquidity in wstETH/ACX can stake their LPs tokens and monitor their rewards in one place. More importantly, ACX incentives would now go direct to LPs instead of bribe takers. These LPs are less likely to sell ACX tokens given they are holders of ACX already. In addition, using reward locking would provide some continuity. ACX LPs would continue providing liquidity in the wstETH / ACX pool on Balancer and just need to unstake their BPT from Aura and stake in Across instead.\nVelodrome\nACX liquidity on an L2 was not initially considered given a focus on having healthy liquidity on mainnet. Across bridge LP assets are primarily in the hub pool on mainnet and earn rewards from there; therefore, it made sense to initially build ACX liquidity on mainnet. The community has expressed an interest in ACX having a presence on a L2 like Optimism to support the L2 ecosystem. It also provides other benefits such as co-marketing and awareness. Velodrome claims to provide higher efficiency gains and a small bribe there could potentially help to start a decent liquidity pool. The downside of L2 liquidity is fragmentation. Across would be spending ACX for incentives to maintain liquidity on both mainnet and L2 which do not natively connect.\nArrakis\nUniswap v3, through the use of concentrated liquidity, can be much more capital efficient in providing liquidity. However, using Uniswap v3 requires active management of liquidity ranges. Arrakis provides a solution with its vault strategies and more specifically Protocol Automated Liquidity Management (PALM). This would involve the Across DAO building protocol owned liquidity. The risk to this proposal is the dependency on Arrakis to manage this strategy well. PALM is still relatively new and the Across DAO would be putting treasury assets at risk. In addition, there is a 1% management fee and a 50% split in any profits.\nAfter considering the current landscape and the proposals presented to the Across DAO, I propose to end Aura bribes and use Across reward locking in the near term. The efficiency gains of Aura have diminished and there are benefits to paying ACX direct to LPs instead of bribe takers. This will also provide time for the Across community to assess and potentially implement new incentives such as Velodrome and Arrakis.\nSpecification & Implementation:\nIf the community decides to discontinue Aura bribes I propose the following to ensure a smooth transition:\n\nRisk Labs will continue to bribe 150,000 ACX for each of the next two epochs - specifically depositing a bribe on July 20, 2023 and August 3, 2023. This will provide AURA and BAL emissions for the next four weeks to ACX LPs. Risk Labs can later provide a proposal to ask for reimbursement.\nDuring this 4 week period, the Risk Labs team will add wstETH / ACX BPT as a token eligible for reward locking. This will involve updating the Accelerating Distributor contract and the Across Rewards UI. The initial base emission will be set to ~7,000 ACX per day which is equivalent to ~98,000 ACX every two weeks (compared with current Aura bribes of 150,000 ACX). As per the rules of reward locking, LPs who stake and do not claim ACX rewards can earn up to a 3x multiplier after 100 days. The accelerating distributor contract would need additional ACX tokens to fund this incentive. To be conservative, if we assume all existing LPs stake and hold for the next three months then these token holders would earn a 2.8 multiplier (1+2*(90/100)) and average a 1.9 multiplier over the period. This would mean 1,197,000 ACX (7000 * 90 *1.9) would be required for the next three months. Three months is chosen to attempt to match the timing of the Reward Locking renewal proposal that just passed. This assumes reward locking for wstETH/ACX LPs start in a month and the next reward locking renewal proposal is also for two months.\nThe two Aura bribes and 3 months of reward locking incentives should provide ample time for the Across community to decide on the Velodrome and Arrakis proposals and also implement them if they pass. There may be some overlap of incentives for LPs, but it will ensure there is a smooth transition.\n\nVoting:\n\n Should the Across DAO discontinue Aura bribes? This would involve the following: a) Risk Labs will provide two more bribes of 150,000 ACX each on July 20, 2023 and August 3, 2023 b) Make the wstETH / ACX BPT eligible for reward locking on Across and c) send 1,197,000 ACX to the Accelerating Distributor contract to fund the reward locking incentives for the next 3 months\n\n 90%\n Yes\n\n 10%\n No\n\n 0%\n Abstain\n\n 10\n voters\n\n Closed Jul 2023\n\n Updated - [ACX] Market Making Proposal - Arrakis PALM\n\n 3\n\n read \n\n 4\n min\n\n post by Clayton_UMA on Jul 19, 2023\n\n post by hash_error on Jul 20, 2023\n\n post by zkPantani on Jul 21, 2023\n\n post by Kevin_UMA on Jul 23, 2023\n\n post by Kevin_UMA on Jul 23, 2023\n\n 1 month later\n\n Closed on Aug 22, 2023\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n ACX Bribes on Aura - Reimburse Risk Labs and Plan Forward\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 3\n\n May 2023\n\n $ACX Liquidity - Update and Feedback Wanted\n\n Ideas & Feedback\n\n Ideas & Feedback\n\n 7\n\n Jun 2023\n\n Across Token Launch Proposal v2\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 47\n\n Nov 2022\n\n Across ($ACX) Community Initial Liquidity Proposal\n\n Passed Proposals\n\n Passed Proposals\n\n 49\n\n Nov 2022\n\n Reduce or Reallocate Across ACX LP emissions\n\n Ideas & Feedback\n\n liquidity\n\n Ideas & Feedback\n\n 2\n\n Sep 2023","tokens":3530,"squid":"spider-09","role":"Bridge Spider","at":1791345664438,"hash":"023fdb656416fe825b0865e3c9cf9632df6ab281"}
{"url":"https://gov.optimism.io/t/eden-fractal-epoch-2-implementing-fractal-decision-making-on-the-superchain/9976/1","domain":"gov.optimism.io","title":"Eden Fractal Epoch 2: Implementing Fractal Decision-Making on the Superchain - Updates and Announcements 📢 / Community Calls - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n Eden Fractal Epoch 2: Implementing Fractal Decision-Making on the Superchain \n\n Updates and Announcements 📢Community Calls\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jun 2025\n\n 1 / 34\n\n Jun 2025\n\n 11h ago\n\n post by Optimystics on Jun 5, 2025\n\n Optimystics\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 implementation, from vision to reality. What started as weekly experiments in collaborative decision-making has grown into a dedicated community working to transform how people make decisions together.\nimage1280×720 142 KB\nEden Fractal is a community dedicated to optimizing collective decision-making with fractal consensus processes and prosocial games. Since May 2022, we’ve pioneered ways for communities to make decisions that are fast, fair, and fun, helping organizations implement better coordination systems across various ecosystems. Our bi-weekly events bring together governance leaders, builders, and innovators to develop better coordination systems. Through interactive workshops and educational deep dives, we explore everything from theoretical frameworks to practical implementation strategies for scaling governance and improving coordination throughout society.\nWith our deployment on Base and integration with the Superchain ecosystem, we’re positioned to introduce these innovations to the broader blockchain ecosystem and beyond. We invite you to join this thriving ecosystem as we work toward our mission of implementing fractal decision-making processes throughout society.\nBi-Weekly Events\nJoin us every other Thursday at 17:00 UTC to play the Respect Game where you can:\n\nNetwork with governance innovators and builders across the Superchain\nEarn respect by contributing to the fractal ecosystem—whether building tools, spreading awareness, hosting events, or supporting fractal communities\nPresent your projects and contributions in supportive breakout rooms\nParticipate in peer evaluation and consensus-building\nLearn about state-of-the-art governance processes\n\nFollowing each Eden Fractal event, we meet for Eden Town Hall — a dedicated forum for deeper discussions about governance, strategy, and community coordination. Soon, participants will use their earned Respect to vote on discussion topics through the Cagendas system. You’re welcome to explore the website to learn more about this event.\nWhether you’re actively building governance tools or just beginning your journey, our events provide valuable opportunities for learning, networking, and contributing to better coordination systems. We welcome builders of all experience levels and encourage you to invite friends who could benefit from our supportive community.\nRSVP here to join our next events!\nSupporting the Optimism Ecosystem\nEden Fractal plays a unique role in advancing governance innovation for the Superchain ecosystem. While Eden Fractal plays a supporting role in the Optimism Fractal’ community, Eden Fractal is an independent community with our own vision and mission. This vision drives Eden Fractal’s community to actively support the Optimism Collective in creating better coordination systems.\nOur recent deployment on Base (part of the Superchain) positions us to test and refine governance mechanisms that can benefit the entire Ethereum ecosystem. The democratic fund distribution system we’re implementing builds upon @DanSingjoy’s research document conducted for Optimism Fractal, demonstrating how innovations can flow between communities to create collective benefit. In the upcoming season, we’re planning to run the fund distribution pilot that could be adapted for other communities on the Superchain.\nOver the past year and a half, Eden Fractal has provided a consistent space where many people from across the Superchain come together who are interested in improving governance. Now that we’re building on Base, we can help much more by contributing to open source and public goods, like governance tools and fund allocation tools, which can eventually be integrated more deeply into the Optimism Collective to improve Citizens House and Token House, retro funding, missions, and much more.\nEpoch 1 Achievements\nLooking back at our journey through Epoch 1:\n\n120 Events Completed: Over nearly three years, we’ve hosted consistent weekly (now bi-weekly) events, creating a substantial library of educational content documenting governance innovations and community development.\nFoundational Innovations: Eden Fractal became the birthplace of numerous innovations that now define the fractal governance landscape. This is where the Respect Game was named and refined, transforming from an experimental process into a proven tool for democratic coordination.\nTechnical Infrastructure: Our community fostered the development of essential infrastructure like Fractalgram and nurtured relationships that sparked new communities including Optimism Fractal.\nVision and Mission Crystallization: We collectively developed our vision—that all communities and organizations should have the tools and methods for the best decision-making possible. We crystallized our mission to implement fractal decision-making processes throughout society via collaborative research, development, education, gamification, and community engagement.\nEcosystem Growth: Eden Fractal has inspired and supported the creation of multiple fractal communities, including Optimism Fractal, ZAO Fractal, and others, demonstrating the adaptability of these governance principles.\n\nFor a comprehensive overview of our origins, development, and the many contributors who shaped our journey, we invite you to explore the Eden Fractal Epoch 1 article.\nLooking Ahead to Epoch 2\nEpoch 2 marks a fundamental shift in our approach and capabilities:\n\nBuilding on Base: Our deployment on Base connects us to the Ethereum ecosystem, enabling seamless integration with modern Web3 infrastructure while maintaining the principles that make fractal governance unique.\nORDAO Implementation: With the ORDAO and other advanced tools built by @Tadas, we’re implementing genuine democratic processes where decision-making power stems from peer-recognized contributions rather than financial stakes.\nDemocratic Fund Distribution Research: Building on the research conducted for Optimism Fractal, Eden Fractal will test capital allocation processes that could benefit the entire Superchain ecosystem.\nRespect Token Migration: Eden Fractal Epoch 1 participants can now claim their Respect tokens on Base, enabling participation in ORDAO governance and unlocking new capabilities for our community.\nEnhanced Collaboration Tools: With improved versions of Fractalgram and new applications being developed, participation in fractal governance is becoming more accessible and intuitive for communities across the Superchain.\n\nYou can learn more about Epoch 2 in this article.\nRelated Initiatives\nOptimism Fractal hosts weekly events every other Thursday at 17:00 UTC, alternating with Eden Fractal. This companion community focuses specifically on fostering collaboration and awarding public goods creators on the Superchain. Optimism Fractal was launched by community members from Eden Fractal in October 2023 and has successfully hosted over 60 events. You can follow progress in this newly created thread.\nOptimism Town Hall follows immediately after Optimism Fractal events at 18:00 UTC, providing a forum for broader governance discussions within the Optimism ecosystem. You can explore the Season 3 thread for detailed discussions and insights from previous events, as well as dive into this current season’s thread.\nORDAO Fractal is a newly launched community supporting ORDAO development and implementation, creating specialized infrastructure for fractal governance across multiple blockchain networks. The ORDAO Fractal playlist features recorded sessions where community members can learn about the technical infrastructure powering our governance systems.\nEveryone is welcome to join all of these events to contribute to the broader ecosystem and pioneer new forms of governance on the Superchain. Subscribe to the Optimystics Events Calendar to stay informed about all activities across the fractal ecosystem.\nGetting Involved & Resources\nEden Fractal continues as a pioneering community doing crucial work to help communities achieve better coordination—from attracting builders and fostering collaboration to pioneering democratic decision-making at scale. We welcome engagement in various forms:\n\nExplore our community: EdenFractal.com\nWatch past events: Videos and Show Notes\nLearn about Epoch 2: Welcome to Epoch 2\nExplore Epoch 2 Implementation Plan\nReview our journey: Epoch 1 Retrospective\nUnderstand our mission: Mission Statement\nLearn the Respect Game: Introductory article\nJoin discussions: Telegram Group\nSubscribe for updates: Eden Creators Youtube channel\nExplore coordination tools: Optimystics Toolkit\nUnderstand fractal democracy: Article\n\nJoin Us in Shaping the Future of Coordination\nThis thread will serve as a central place for event announcements, video recordings, and key updates throughout Epoch 2. As we embark on this new chapter, we’re not just continuing our work—we’re elevating it to meet the moment. With mature tools, clear vision, and a proven community, we’re ready to bring fractal decision-making processes to communities worldwide.\nWhether you’re a developer building on the Superchain, a community leader seeking democratic coordination methods, an educator spreading knowledge about better governance, or someone passionate about improving how communities make decisions together—there’s a place for you in Eden Fractal.\nFeel free to share any questions or thoughts below. We look forward to seeing you at our events as we work together to transform governance from a burden into a joy, from exclusion into participation, from conflict into collaboration. Together, we’re building the future of human coordination — fair, fast, and fun! \nimage1280×720 157 KB\n\n Optimism Fractal Season 6: Expanding Democratic Coordination Across the Superchain\n\n 24\n\n 5\n\n 3\n\n 2\n\n read \n\n 28\n min\n\n post by DanSingjoy on Jun 5, 2025\n\n DanSingjoy\n\n Hello everyone!\nI’m thrilled to announce that today marks the official launch of Eden Fractal Epoch 2! After months of preparation and strategic development, we’re finally ready to take this transformative step together.\nWe’ll be hosting our Epoch 2 launch event today at 17 UTC, where we’ll restart the Respect Game on Base and welcome everyone to this new chapter. To help everyone understand this transition, I’ve just published two comprehensive articles:\nEden Fractal Epoch 2: A New Era of Collaborative Decision-Making - Everything you need to know about Epoch 2, including key features, benefits, and how to get started\nEden Fractal Epoch 1: A Retrospective on Our First Three Years - A deep dive into our history, achievements, and the journey that brought us here\nAfter three incredible years, we’re positioned to truly actualize our vision of implementing fractal decision-making processes throughout society. Today’s event includes both the Respect Game at 17 UTC and the return of Eden Town Hall at 18 UTC, where we’ll discuss our plans and prepare for our three-year anniversary celebration on June 19th.\nSpecial thanks to everyone who made Epoch 1 so remarkable over the past three years. Your contributions, dedication, and collaborative spirit have built the foundation that makes this evolution possible. I’m especially grateful to @rosmari for her wonderful promotions and to @tadas for building the new Eden Fractal ORDAO app, which now enables our community to vote and execute on-chain decisions while claiming Respect tokens earned during Epoch 1 on Ethereum.\nI invite everyone to join us as we collaborate, earn Respect, and shape the future of governance together. You can RSVP at the Optimystics Events Calendar. Let’s make Epoch 2 extraordinary! \n1280×720 141 KB\n\n 12 days later\n\n post by DanSingjoy on Jun 17, 2025\n\n DanSingjoy\n\n Members of the Optimism Collective,\nI warmly invite you to join us this Thursday, June 19th, as we celebrate three years of Eden Fractal’s epic journey in fractal governance. We’ve planned two special events that bring together the fractal ecosystem to honor our progress and accelerate toward the future on the Superchain.\nAt 17 UTC, we’ll gather for the Respect Game where you can collaborate with fellow governance innovators and earn Respect by contributing to the fractal ecosystem. This is part of Eden Fractal’s historic Epoch 2, which launched two weeks ago and marked our transition to building on Base and Ethereum – creating exciting opportunities to expand our impact. It was amazing playing the Respect Game at our last event, and I’m thrilled to return to this core practice of fractal democracy. This shared ritual forms the foundation of our progress and provides the perfect way to recognize contributions while strengthening our ecosystem together.\nFollowing at 18 UTC, our anniversary Eden Town Hall welcomes everyone to share their thoughts and stories about fractal governance, and hear from others in our community. After successfully relaunching Eden Town Hall at our past event, this three-year anniversary offers a special moment to harness our collective wisdom and experience. We’ll reflect on our journey, exchange ideas, and envision increasing success for the coming year. These two events provide an opportunity to participate in a unique moment of fractal history as we shape the future of governance together.\nThe collaboration and dedication of participants throughout the fractal ecosystem has built a strong foundation, yet we stand at just the beginning of our potential impact. As we enter year four, I’m energized by the opportunity to transform how communities and organizations make decisions. With foundations now in place – technical infrastructure, educational resources, and a thriving culture – we’re ready to enter a new era. This year, we’ll expand our reach dramatically while empowering each participant to advance fractal governance in their own communities and projects.\nEveryone is welcome to join, whether you’re discovering fractals for the first time or you’ve been part of this journey from day one. Register for both events on the Optimystics Event Calendar. As always, recordings will be available at EdenFractal.com/videos for those unable to join live. I look forward to celebrating with you as we honor our journey and accelerate toward a future where fractal coordination benefits communities everywhere.\nWith gratitude and anticipation,\nDan Singjoy\neden fractal 3 year event 51280×720 154 KB\n\n 14 days later\n\n post by Optimystics on Jul 2, 2025\n\n Optimystics\n\n Experience the Magic: Respect Game Revival on Base\nHey all,\nJoin us for Eden Fractal’s next gathering this Thursday at 17 UTC as we continue our historic Respect Game revival on Base! \nExperience collaborative governance innovation as we shape the future of fractal decision-making processes throughout society.\nWhy play the Respect Game? It’s great for networking, collaboration, education, career development, making positive impact, and much more! Earn Respect by contributing to the fractal ecosystem through building tools that help communities with decision-making, spreading awareness, hosting events, supporting fractal communities & more.\nEveryone’s welcome to join even if you’re not familiar with fractals. You can help pioneer the best possible decision-making for all!\nimage1280×720 147 KB\nEden Town Hall\nAfter playing the Respect Game at 17 UTC, join Eden Town Hall at 18 UTC \nWe’ll have both discussion about the future of Eden Town Hall and an open discussion about our next steps for Epoch 2. We’ll discuss the Cagendas rules, cadence, format, and structure of Eden Town Hall going forward - including implementing a minimum threshold of Respect required to trigger an event, similar to what was recently approved at Optimism Town Hall.\nEden Town Hall events provide the deliberative foundation for governance, creating space for democratic topic selection through Cagendas, structured deliberation on proposals, community dialogue about strategic direction, and integration with legislative consensus processes. You’re welcome to explore more at Eden Town Hall’s website.\nRecent Episodes & Ecosystem Highlights\nIn our latest Eden Fractal episode, we celebrated Eden Fractal’s Respect Game revival on Base featuring Tadas on ORDAO metadata migration, Cardano fractal democracy implementation, thezaodao Fractal’s Discord bot, and Dan Singjoy on Superchain ORDAO capabilities.\n\n EF 122: Eden Fractal Respect Game on Base\n\nYou’re also welcome to watch Eden Fractal’s 3-year anniversary celebration video where Dan Singjoy facilitates reflections on innovative progress, Cardano guests explore cross-chain governance, Jorge shares UBI vision, Tadas explains Bell Labs model, and the group discusses funding fractal communities.\n\n ETH 58: Eden Fractal 3-Year Anniversary Celebration\n\nRecent ecosystem highlights include Superchain ORDAO’s cross-chain deployment capabilities, ORDAO Fractal app launches by Tadas, Fractalgram ongoing configuration for smooth gameplay, and Respect Game mission research milestone by Dan Singjoy. The fractal ecosystem continues to thrive! \nGet Involved\nEpoch 1 Participants: As Tadas mentioned in his recent post, you can now claim your Respect tokens on Base from Epoch 1 and participate in Eden Fractal’s governance with more capabilities than ever before - to mint Respect, or execute any other onchain action.\nEden Fractal is pioneering profoundly helpful coordination tools through collaborative research, development, education, gamification, and community engagement Have a topic you’d like to discuss about the fractal ecosystem at the event? Let us know!\nTogether we can make 2025 transformative for collective decision-making. Join builders and governance pioneers this Thursday at 17 UTC for an awesome Respect Game at Eden Fractal, and then join us at Eden Town Hall at 18 UTC. You’re welcome to RSVP on the events calendar where you can find a link to the zoom room.\nLooking forward to seeing you this Thursday \n\n 14 days later\n\n post by Optimystics on Jul 17, 2025\n\n Optimystics\n\n Island of Ideas: Eden Fractal Grows Again!\nExperience the future of collaborative governance at Eden Fractal this Thursday at 17 UTC & Eden Town Hall at 18 UTC \nEden Fractal continues pioneering democratic coordination tools on Base, where builders showcase contributions and earn Respect through peer evaluation. Ready to experience the magic?\nEF 124 promotional thumbnail1280×720 154 KB\nThe Respect Game transforms governance into an engaging experience where your impact matters! Build coordination tools, spread awareness, support communities & earn recognition for creating public goods\nEveryone’s welcome to join even if you’re not familiar with fractals. You can help pioneer the best possible decision-making for all!\nEden Town Hall\nAfter playing the Respect Game at 17 UTC, join Eden Town Hall at 18 UTC where we’ll discuss event scheduling & cadence for the fractal ecosystem, Cagendas implementation & minimum respect thresholds, and next steps for Epoch 2’s legislative consensus process \nEden Town Hall provides the deliberative foundation for governance, designing space for democratic topic selection through Cagendas, structured deliberation on proposals, community dialogue about strategic direction, and integration with legislative consensus processes. You’re welcome to explore more at Eden Town Hall’s website.\nRecent Episodes & Ecosystem Highlights\nExplore exciting developments at Eden Fractal’s latest episode featuring Will on standardized impact measurement & Common Approach, Tadas’s infrastructure work on ORDAO for immutable respect distribution, and Tevo’s cross-chain tools & Swarm treasury work.\n\n EF 123: Impact Measurement\n\nYou’re also welcome to watch the latest Eden Town Hall episode for more enthusiastic community discussions! Flavia shares AI-powered task recommendation systems, Sebastian explores Epoch 2 potential, plus discussions on dispute resolution & much more \n\n ETH 59: Community Governance & Fractal Expansion\n\nRecent ecosystem highlights include Tevo’s Swarm treasury work for onchain value recognition, Will’s standardized impact measurement insights, Tadas’s ORDAO deployment for immutable respect distribution, and celebrating Eden Fractal’s 3 years of magical innovation! \nJoin Us Today\nEden Fractal is pioneering profoundly helpful coordination tools through collaborative research, development, education, gamification, and community engagement. Have a topic you’d like to discuss about the fractal ecosystem at the event? Let us know - we’d love to discuss it together \nTogether we can make 2025 transformative for collective decision-making. Join builders and governance pioneers this Thursday at 17 UTC for an awesome Respect Game at Eden Fractal, and then join us at Eden Town Hall at 18 UTC. You’re welcome to RSVP on the events calendar where you can find a link to the zoom room.\nLooking forward to seeing you in 15 mins \n\n 14 days later\n\n post by Optimystics on Jul 31, 2025\n\n Optimystics\n\n What’s next?\nEden Fractal is wrapping up now—Eden Town Hall begins shortly \nAfter the upcoming mid-season break, Eden Fractal returns on August 28th—continuing its mission to advance collaborative governance innovation on Base!\nJoin us for Eden Town Hall at 18 UTC where we’ll explore legislative consensus processes & more! Find out topics for today below \nLatest Videos & Updates\nYou’re welcome to watch Eden Fractal’s latest episode where we browse through ORDAO for immutable respect distribution, community repositories document fractal specs & AI-powered bots gamify consensus!\n\n EF 124: Democratic Innovation\n\nExplore summer event scheduling, Epoch 2 implementation progress & legislative consensus options (Eden Plus Fractal, ORPolls) in our latest Town Hall episode.\n\n ETH 60: Event Scheduling, Epoch 2 Progress & Consensus Process Discussion\n\nEden Town Hall\nWe’ll discuss:\n\nLegislative consensus process options for Epoch 2\nZAO’s “Fractal of Fractals” - enabling community-hosted Respect Games\nImpact Concert collaboration planning\nEden Fractal Mid-season break: We’ll skip Aug 14, returning Aug 28\n\nEcosystem Highlights and Initiatives\nExciting updates from the fractal ecosystem:\n\nBase has rebranded - A new day one that we keep building on!\nORDAO deployment advancing for onchain respect distribution\n3+ years of democratic innovation continues\nGrowing network of fractal communities worldwide\n\nGet Involved\nJoin the discussion about our future governance structure!\nWe’re exploring Eden + Fractal delegate elections & ORPolls two-stage voting. Your input shapes how we make collective decisions. Have topics for Cagendas or ideas about consensus mechanisms? Share them with us!\nYou’re welcome to RSVP on the events calendar where you can find a link to the zoom room. Explore more at edenfractal.com/videos and edentownhall.com.\nLooking forward to seeing you soon! \nimage1280×572 119 KB\n\n 27 days later\n\n post by Optimystics on Aug 27, 2025\n\n Optimystics\n\n Hey all,\nhope you’re all doing well!\nIt’s been a long time since we played the Respect Game and did a community catch-up! We missed you, but hope you had a lovely time and are curious to learn what you’ve been up to \nLatest Episodes Before the Break\nBefore we reunite this Thursday, catch up on our latest episodes from before the mid-season break.\nYou’re welcome to watch Eden Fractal’s episode, featuring wonderful contributions from community members.\n\n EF 125: Building Abundance\n\nEnjoy Eden Town Hall’s episode, where we planned for the exciting Fractal Impact Concert and reviewed legislative consensus process options for Epoch 2 \n\n ETH 61: Planning Fractal Impact Concert & Legislative Process\n\nFractal Impact Concert Success\nDuring our break, the fractal ecosystem celebrated with an amazing event - the Fractal Impact Concert!\nHuge thanks to EZ for organizing and Jose for co-hosting this incredible gathering that beautifully merged art, music, and governance innovation. The concert featured amazing performances by talented musicians, inspiring talks from speakers across ZAO Fractal, Eden Fractal, and Optimism Fractal, and brought many new people into the fractal ecosystem for the first time.\nYou can watch the recordings now: the Eden Creators version has better visuals while the Token Smart YouTube version has complete audio. This event really demonstrated how culture and coordination can work together in powerful ways!\nJoin Us\nAfter our refreshing break, we’re back for our sixth event of the season!\nThis Thursday, we’ll gather for the Respect Game at 17 UTC, followed by Eden Town Hall at 18 UTC.\nCurious what’s happening? This week marks the beginning of the second half of our season, and we’re focusing on implementing the Eden+Fractal consensus process - the legislative branch of our governance system. We’ve been discussing this throughout the first half of the season, and now it’s time to put it into action!\nThe Eden+Fractal process enables democratic decision-making through elected delegates and rolling councils, completing our tripartite governance structure alongside ORDAO and the Respect Game. Your participation shapes this historic moment in the evolution of fractal democracy. For a preview of what we’ll discuss in more detail with all the relevant links, check out this week’s Eden Town Hall agenda.\nFor those wanting to understand the process better, we’ve prepared a comprehensive implementation plan and you can learn more at our introductory guide. We’ll discuss the key points during Thursday’s event, including how we’ll handle the technical implementation on Base and what opportunities exist for community members to become delegates and help lead Eden Fractal forward.\nYou’re welcome to RSVP on the events calendar where you can find a link to the zoom room. Explore more at edenfractal.com/videos and edentownhall.com.\nLooking forward to seeing you this Thursday! \neden fractal welcome back smaller11280×614 131 KB\n\n post by DanSingjoy on Aug 28, 2025\n\n DanSingjoy\n\n Hello everyone!\nAfter a refreshing mid-season break, I’m excited to welcome you back for our sixth event of the season and make the next great strides in our second epoch. Today at 17:00 UTC, we’ll gather for Eden Fractal Event #126, followed by our 62nd Eden Town Hall event from 18:00-19:00 UTC.\nDuring the Eden Fractal event, we’ll play the beloved Respect Game to measure contributions to Eden Fractal’s mission and further the growth of the fractal ecosystem. As always, this will be a great place to network, earn respect on Base for your contributions to collective decision-making, see what people are building in the fractal ecosystem, and foster new collaborations.\nFollowing the Respect Game, Eden Town Hall will feature three main discussion topics:\n1. Updates Over the Break\nA major highlight from our break was the Fractal Impact Concert organized by EZ! This organic community initiative brought together awesome music from talented artists and speakers from ZAO Fractal, Eden Fractal, and Optimism Fractal, introducing many new people to fractal governance. Videos are available on Eden Creators and Token Smart youtube channels.\nWe also released new episodes before the break that you might have missed: Eden Fractal Episode 125, Eden Town Hall Episode 60, and Optimism Fractal Episode 66. You can find links to watch the full videos from each of these events in the agenda below and we’ll share quick highlights from these during our discussion.\n2. Eden+Fractal Consensus Process\nThe main focus will be discussing the re-implementation of the Eden+Fractal consensus process for the second half of our season. This legislative branch of our governance system enables democratic decision-making through elected delegates and rolling councils. For those wanting to understand the details, check out the new Eden+Fractal introductory guide and implementation plan. Stay tuned for more details about delegate opportunities in this week’s event and coming weeks.\n3. Open Discussion\nAs always, everyone’s welcome to share thoughts and questions about the fractal ecosystem, next steps for Eden Fractal, and our Epoch 2 implementation plans. This is a great space for community-driven conversations about our collective future. For a preview of what we’ll discuss in more detail with all the relevant links, check out this week’s Eden Town Hall agenda.\nYou’re invited to join us today at 17:00 UTC for the Respect Game, followed by Eden Town Hall at 18:00 UTC. RSVP for the events here and find more details on our websites. Everyone is welcome to join, whether you’re experienced with Fractals and contributing regularly or learning about fractal governance for the first time.\nLooking forward to seeing everyone as we begin this exciting second half of our season!\n\n 13 days later\n\n post by DanSingjoy on Sep 11, 2025\n\n DanSingjoy\n\n eden fractal epoch 2 - world and wave1280×720 128 KB\nHey optimists! You’re welcome to join us for the 127th Eden Fractal event and 62nd Eden Town Hall today, starting at 17 UTC!\nWe’ll take the next steps into Eden Fractal’s second epoch by playing the Respect Game to measure contributions to the fractal ecosystem and advancing our mission of integrating fractal decision-making processes throughout society. This is an excellent opportunity to network, collaborate, and earn Respect by sharing contributions and ranking contributions to optimize collective decision-making. After reaching consensus on contribution rankings, each breakout room will elect a delegate to help lead the world to fractal democracy!\nAt Eden Fractal’s prior event, we successfully revived the Eden+Fractal consensus process, implementing a streamlined democratic process that enables community members to play a more direct role in fractal governance and our legislative process. We then elected a delegate for the first time in nearly two years, marking an important milestone in our community’s development. Each Eden Fractal event now provides a unique opportunity to become a delegate or vote for delegates who will help lead the fractal ecosystem and work towards achieving our mission.\nFollowing the Respect Game, we’ll gather for the Eden Town Hall to discuss recent developments across the fractal ecosystem and dive deeper into refining the Eden+Fractal consensus process. We’ll cover new videos and progress from over the break, as well as working to improve the functionality of the Eden+Fractal consensus process while reviewing the implementation plan. As always, the Eden Town Hall provides an open forum where anyone in the Fractal ecosystem can share thoughts about fractals, ask questions, and contribute to our collective direction. Check out the town hall agenda for more details.\nI’m looking forward to another amazing pair of events and taking the next step in Eden Fractal’s journey together. Everyone is welcome regardless of experience level, and joining itself is a valuable contribution to the common good. As always you can RSVP on the Optimystics event calendar, catch any events you’ve missed on the Eden Creators youtube channel, and feel free to share your thoughts in the Eden Fractal Telegram group. Hope to see you there!\n\n 14 days later\n\n post by Optimystics on Sep 25, 2025\n\n Optimystics\n\n Hey all,\nJoin us today at 17 UTC to play a fantastic Respect Game at Eden Fractal \nEF image21280×720 150 KB\nThese events are open for everyone and have a friendly environment where you can connect with fellow governance enthusiasts and earn Respect by helping to optimize collective decision-making. Experience the art of community building through the beloved Respect Game!\nAs a quick reminder, Eden Fractal has successfully revived the Eden+Fractal consensus process, implementing a streamlined democratic process that enables community members to play a more direct role in fractal governance and our legislative process. Each Eden Fractal event provides a unique opportunity to become a delegate or vote for delegates who will help lead the fractal ecosystem and work towards achieving our mission.\nAt 18 UTC, we’ll continue with the Eden Town Hall, where we’ll have an open discussion, while exploring various topics important to our evolving community. It’s a great place for community members to share ideas, ask questions, and contribute to our collective growth and decision-making processes.\nYou’re welcome to RSVP on the event page where you can find a link to the zoom room.\nLooking forward to seeing you all soon \n\n 14 days later\n\n post by Optimystics on Oct 9, 2025\n\n Optimystics\n\n Join Us in the Garden \nHey all, hope you’re all doing well!\nWe’re so excited for today’s Respect Game! It’s always inspiring to come together, share what we’ve been creating, and celebrate the amazing work happening across the community \nLatest Episodes\nYou’re welcome to watch Eden Fractal’s episode, featuring consensus cultivation through gamification and collaboration, with Eric launching doctoral research on appreciation-driven motivation, Zaal successfully deploying ORDAO for Zao Fractal, and Tadas fixing vote weight bugs while creating new proposal types.\nEnjoy Eden Town Hall’s episode, where we explored adjusting meeting times and demonstrated the ORDAO proposal system while enhancing the Eden + Fractal consensus process.\n\n EF 128: Consensus Cultivation\n\nEden Town Hall Highlights\nIn our latest Eden Town Hall episode, we made significant progress on governance optimization!\nThe community elected Zaal as delegate through the onchain ORDAO system, with Dan providing a detailed walkthrough of the proposal submission process for Eden + Fractal. Leo shared valuable insights about event scheduling across Web3 communities, noting that Mondays and Fridays offer the least conflicts. Tadas proposed an innovative solution to split the Town Hall and Respect Game timing, sparking important discussions about creating tighter feedback loops in our governance process & much more!\n\n ETH 63: Meeting Time & ORDAO Discussion\n\nGet Involved\nThis Thursday, we’ll gather for the Eden Fractal event at 17 UTC, followed by Eden Town Hall at 18 UTC.\nCurious what’s on the agenda? This week we’re considering an important draft proposal to move Eden Town Hall to Thursday 16 UTC (before Eden Fractal), so we have Eden+Fractal councils pass proposals during this hour. This would create tighter feedback loops between delegate decisions and Respect Game outcomes.\nThe Eden+Fractal process enables democratic decision-making through elected delegates and rolling councils, completing our tripartite governance structure alongside ORDAO and the Respect Game. Your participation shapes this historic moment in the evolution of fractal democracy across society.\nYou’re welcome to RSVP on the events calendar where you can find a link to the zoom room.\nLooking forward to seeing you shortly \n\n 13 days later\n\n post by Optimystics on Oct 23, 2025\n\n Optimystics\n\n Thriving Together in the Fractal Community\nHi everyone,\nA quick reminder that the Eden Town Hall starts at 16:00 UTC, followed by Eden Fractal at 17:00 UTC, where we’ll be playing the Respect Game!\nEF image1280×720 1.26 MB\nThe updated Town Hall time was discussed and approved during our last event, which will be published shortly. You can read more about the reasoning for the time change in Tadas’ proposal. We also encourage you to check out the exciting Town Hall agenda for today in Dan’s recent post.\nSomething else to look forward to: Dan will also demo Vlad’s new Respect Game app at the Town Hall! Join us in our zoom room shortly to take part in the growth and development of the fractal community!\nLooking forward to seeing you all soon \n\n 13 days later\n\n post by Optimystics on Nov 5, 2025\n\n Optimystics\n\n Join us this Thursday for our second-to-last Eden Fractal event of the season!\nWe’ve got two joyful gatherings lined up with exciting new ways to collaborate, vote, and build together. Find out more about the upcoming events below \nEF 131 thumbnail image1792×1024 740 KB\nEden Fractal\nWe’ll play the beloved Respect Game at 17 UTC, where community members share their contributions, connect with one another, and earn non-transferable Respect — the foundation of our reputation and coordination. It’s a great chance to reflect on recent progress and help our fractal community grow stronger together.\nEden Town Hall\nStarting one hour before Eden Fractal at 16 UTC, we’ll host a Town Hall, where the community will have its first playing of the Synchronous Respect Trees game, a new coordination method created by Tadas. Over the past week, the community has been collaborating in this four-stage method to choose and refine topics for discussion — using Respect earned during Epoch 2 to guide collective priorities.\nSo far, the top topic is Fractal Tokenomics, and the subtopics now open for voting include:\n• Experimentation with Fractal Nouns\n• History of Fractal Tokenomics\n• Service for Respect\nYou’re welcome to follow updates and participate in the Synchronous Respect Trees channel within the Eden Fractal Telegram group, as well as learn more on this page.\nGet Involved\nRSVP and join the events via the calendar, and please note that daylight savings time has ended, so the events will start one hour earlier for some time zones.\nWhether you’re new to fractals or have been part of the long journey, everyone’s welcome to give their opinion, experience and support to help shape the growth of the fractal ecosystem!\nLooking forward to seeing you there,\n\n 14 days later\n\n post by Optimystics on Nov 19, 2025\n\n Optimystics\n\n Be part of the final Eden Fractal event this season!\nWe have two wonderful gatherings lined up for tomorrow, and we would be delighted if you could join us! First we’ll meet at Eden Town Hall at 16 UTC to discuss exciting topics, then play the final Eden Fractal Respect Game of the year with our amazing community. Find out more about the upcoming events below \nimage1280×720 475 KB\nEden Fractal\nWe’ll play the beloved Respect Game at 17 UTC, where you can share your work, make connections, and earn Respect — the foundation of our reputation and coordination systems. This is a great opportunity to hear from everyone, reflect on the season, and strengthen the fractal ecosystem.\nEden Town Hall\nStarting one hour before Eden Fractal, we’ll host a Town Hall at 16 UTC, where the community will be playing the Synchronous Respect Trees game - a new coordination game created to choose topics for discussion and guide priorities with Respect earned during Epoch 2.\nSo far, the top topic is the Eden Fractal Season 12 finale, and the subtopics now open for voting include:\n• More discussion time next season?\n• Pause Optimism Fractal?\n• Fractal Nouns & Experimentation on Nouns.Build\n• Schedule more time for Fractal Nouns?\n• Schedule more time for Agency project?\n• Season 12 retrospective\nYou can participate in the Synchronous Respect Trees channel to see updates, vote on the above topics on Snapshot, and learn more about the game on this page.\nJoin us for the season finale!\nWe’re so grateful for everyone’s participation and contributions this season. You have made the first season of Epoch 2 truly special. We are really excited to close out the season with this event, our last gathering of 2025, and can’t wait to hear everyone’s thoughts as we discuss these topics and play the Respect Game together.\nYou’re welcome to RSVP and join via the Optimystics events calendar. Whether you’re new to fractals or a longtime participant, everyone is welcome to share their thoughts and help shape the fractal ecosystem. Looking forward to seeing you there \n\n 2 months later\n\n post by Optimystics on Jan 13\n\n Optimystics\n\n New Year, New Season: Join Us for Town Hall + Respect Game\nHey friends, happy new year! \nWelcome back to Eden Fractal! We’re excited to return from our holiday break and kick off Season 12 with the first events of 2026. We hope you all had a wonderful holiday season and are ready to reconnect with the community!\nEF 133 Promotion1280×720 407 KB\nEvents\nThis Thursday, January 15th, we’re launching Eden Fractal’s new season with two back-to-back events. First, at 16 UTC, we’ll host Eden Town Hall where we’ll have open community discussions and play the Respect Trees game - a new way for our community to build consensus on topics to discuss by proposing and voting on priorities. If you’d like to propose a topic, you can share it in the Synchronous Respect Trees chat by 16 UTC today, and then voting will open for Respect holders to rank the topics before the Town Hall begins.\nThen at 17 UTC, we’ll play the beloved Respect Game - the core ritual at the heart of our community. This is a great opportunity to connect with governance innovators, contribute to the fractal ecosystem, and earn Respect for supporting Eden Fractal’s mission of helping organizations make better collective decisions. It’s the perfect way to showcase what you’ve been up to over the winter break and gain influence in our governance systems.\nGratitude & Scaling Success\nThe Eden Fractal community and the fractal ecosystem made wonderful progress in 2025, and we’re now well-positioned to make great strides in our fourth year. Together we continue implementing fractal decision-making processes throughout society and collaborating to increase our impact in Eden Fractal’s second epoch. Whether you’re new to fractal governance or a longtime participant, we’re grateful for your participation and you’re warmly welcome to join us!\nYou’re invited to RSVP for both the Eden Town Hall and Eden Fractal Respect Game on the events calendar, where you’ll find a link to the zoom room. You can stay up to date on the latest community developments in our group chat (linked above) and explore more at EdenFractal.com.\nLooking forward to seeing you this Thursday \n\n 8 days later\n\n post by DanSingjoy on Jan 22\n\n DanSingjoy\n\n Hey all! I have an important announcement to share, along with an invitation to today’s event.\nOptimism Fractal Is Pausing\nIn case you haven’t heard yet, Optimism Fractal is entering an indefinite hiatus. The proposal was approved by the Optimism Fractal Council, using Optimism Fractal’s existing consensus processes to indefinitely pause events. The main goal is to consolidate our focus on the fractal ecosystem with Eden Fractal — supporting the mission to implement fractal decision-making processes throughout society and better serving the growing ecosystem of fractal communities.\nAs I wrote in the proposal, I’m deeply grateful for everyone who participated and contributed to Optimism Fractal over the past two years. It’s been truly special, and we’ve achieved a great deal together. I’m also really excited about this consolidated focus on Eden Fractal, where there’s been a lot of momentum lately. In the new year, we have plans to make significant strides toward help all communities and organizations optimize collective decision-making, and I believe this focus will help us get there.\nYou can learn more about the rationale and what this means for the fractal ecosystem in the approved proposal (linked above) or the post below. The proposal also includes a link to the Eden Town Hall 67 video where we discussed this decision in full. Stay tuned for additional updates in the coming weeks. In coordination with this decision, the Optimystics events calendar has been rebranded to the Eden Creators events calendar, reflecting this shift in focus toward the Eden community.\n\nYou’re Invited: Eden Town Hall Today at 16 UTC\nSecondly, I’d like to invite you all to the Eden Town Hall event today at 16 UTC, which starts in about 15 minutes!\nThe topics from last week’s event (January 15th) are rolling over since we only had time to discuss one of the seven proposed topics. These topics have already been pre-voted through the Synchronous Respect Trees game (as you can see in this Snapshot poll), so we’ll dive straight into discussion.\nThe top-voted topic is about setting Eden Fractal’s schedule going forward—whether to continue with bi-weekly events, shift to weekly Town Halls, weekly Respect Games, or some other arrangement. We’ll also aim to cover the second most voted topic about ORDAO documentation and the other five community topic proposals as time allows. We will not play a Respect Game after today’s town hall, so we may extend the town hall to last for two hours to provide sufficient space for all discussions.\nSince this event falls on the date that Optimism Fractal Season 7 was originally planned to begin, we’re also welcoming anyone who has questions about the hiatus or other thoughts related to Optimism Fractal. This is a good opportunity for open discussion about the strategic direction and how fractal communities will continue to work together across the Superchain through Eden Fractal.\nI’m excited to collaborate with you all and chart our next steps together. You can RSVP on the Eden Creators Events Calendar and, as always, join the conversation in the Eden Fractal telegram group. Hope to see you there!\n\n post by Optimystics on Jan 28\n\n Optimystics\n\n Hey everyone!\nYou’re invited to join two Eden Fractal community events this Thursday, January 30th. It’s always a joyful time to gather, collaborate, and experience democratic governance together. Please see details about the events shared below:\nimage1280×720 479 KB\nAt 16:00 UTC, we’ll gather for the Eden Town Hall, where we’re trying a new community-driven game for selecting discussion topics. Community members have proposed and can now vote on topics throughout the week, and whichever topics receive the most votes will guide our discussions. Six topics have been proposed:\n\nUpdate Eden Fractal’s ORDAO configuration\n\nFractalgram development priorities\n\nEden Fractal 2026 resolutions\n\nIntroduction to Fractal Circles with a demo from Mikael\n\nOptimism Fractal hiatus reflections\n\nContinuing discussions from recent events\n\nTo learn more about how this new game works, check out Tadas’s post. To see all topics in detail and vote, visit the Topics snapshot poll. There’s also a new contribution requests feature as part of this game where community members are requesting specific contributions—you can learn more about that in Tadas’s post as well.\nAt 17:00 UTC, we’ll play the Eden Fractal Respect Game, the heart of our community where we measure and recognize contributions to Eden Fractal’s mission of implementing fractal decision-making throughout society.\nThis special game provides a space to share your progress updates, build your reputation, earn Respect tokens, and connect with fellow governance enthusiasts. Since we’re now doing contribution requests, contributions that address what the community has requested will be especially valued.\nYou’re welcome to register on the Eden Creators Events calendar. Join the Eden Fractal Telegram group to participate in choosing and discussing topic proposals shared in this group. See you this Thursday!\n\n post by Optimystics on Feb 2\n\n Optimystics\n\n Hey everyone! You’re invited to join the Eden Town Hall this Thursday at 16:00 UTC.\nThis week is an Eden Town Hall only week, so we won’t play a Respect Game afterward. This gives us space for deeper, more flexible discussions, and we may extend the Town Hall to two hours to cover more ground.\nimage1280×720 536 KB\nDiscussion Topics\nThe topics from last week’s Synchronous Respect Trees V1 game (a community-driven game for selecting discussion topics) are rolling over to guide our discussions. The six pre-voted topics include:\n\nUpdate ORDAO configuration\n\nIntroduction to Fractal Circles\n\nEden Fractal 2026 resolutions\n\nOptimism Fractal hiatus\n\nFractalgram\n\nContinuing discussions\n\nTo see all topics in detail, visit the Topics snapshot poll. There’s also a Contribution Requests poll showing areas where the community is seeking contributions.\nThe next Synchronous Respect Trees game will start on Friday, so stay tuned in the Eden Fractal Telegram group if you’d like to propose topics for the following week.\nVideos\nHere’s a quick update about some videos that have been recently uploaded to the Youtube channel:\nEden Town Hall 68 is now available \nThis session kicks off Eden Fractal Season 12 with a deep dive into a proposed bi-weekly structure that alternates between legislative governance weeks and independent contribution weeks.\n\n ETH 68: Eden Fractal Event Structure & Visions\n\nEden Fractal 133 episode shows the first Respect Game of 2026, marking the start of Season 12 after an eight-week break. These events took place on January 15th. As always, you can find more of the latest Eden Fractal and Eden Town Hall videos on the Eden Creators youtube channel.\n\n EF 133: Eden Fractal Looking Ahead in 2026\n\nGet Involved\nYou’re welcome to register on the Eden Creators Events calendar. Whether you’re new to fractals or a longtime participant, everyone’s welcome to share their thoughts and help shape the fractal ecosystem.\nWe hope to see you there \n\n 8 days later\n\n post by Optimystics on Feb 11\n\n Optimystics\n\n Join Us This Thursday: Eden Fractal Community Events \nHi all,\nYou’re invited to join two Eden Fractal community events this Thursday! It’s a wonderful opportunity to meet up friends, collaborate, and experiment with new governance methods for communities. Please see details about these exciting events below:\nimage1280×720 480 KB\nEden Town Hall\nAt 16:00 UTC, we’ll gather for the Eden Town Hall to play a community-driven game for selecting discussion topics. Community members who’ve earned Respect have proposed and now can vote on topics throughout the week, and whichever topics receive the most votes will guide our discussions. Six topics have been proposed:\n\nUpdate Eden Fractal’s ORDAO configuration\n\nMore Equal Animals 5-Year Anniversary\n\nFractalgram development discussions\n\nEden Fractal 2026 resolutions\n\nSRT V1 and other improvements\n\nTo learn more about how this game works, check out Tadas’s post. To see all topics and vote, visit the Topics snapshot poll. There’s also a contribution requests feature where community members are requesting specific contributions, which you can find out more about in the Synchronous Respect Trees sub-channel within the Eden Fractal Telegram group.\nEden Fractal\nAt 17:00 UTC, we’ll play the Eden Fractal Respect Game, glowing at the heart of our community where we measure and recognize contributions to Eden Fractal’s mission of implementing fractal decision-making throughout society.\nThis special game provides a space to share your progress updates, build your reputation, earn Respect tokens, and connect with fellow governance enthusiasts. Since we’re now doing contribution requests, contributions that address what the community has requested will be especially valued.\nRecent Discussions\nCurious what exciting ideas and innovative designs are in progress? Catch up on recent discussions by watching the 69th episode of Eden Town Hall! This event took place on January 22nd. As always, you can find more of the latest Eden Fractal and Eden Town Hall videos on the Eden Creators youtube channel.\n\n ETH 69: New Respect Trees Game & Spec-Driven Development\n\nYou’re welcome to register on the Eden Creators Events calendar, as well as participate in choosing and discussing topic proposals shared in this group.\nSee you this Thursday \n\n 1 month later\n\n post by Optimystics on Mar 17\n\n Optimystics\n\n Eden Town Hall Event Coming Up This Thursday\nHey all! You’re invited to join the Eden Town Hall event this Thursday at 16:00 UTC. It’s a wonderful opportunity to come together, discuss community proposed topics, and help drive the growth to the fractal ecosystem! \nThis week is an Eden Town Hall only week, so we won’t play a Respect Game afterward. This gives us space for deeper, more flexible discussions, and we may extend the Town Hall to two hours to cover more ground.\nimage1280×720 637 KB\nDiscussion Topics\nThe topics from last week’s Synchronous Respect Trees V1 game (a community-driven game for selecting discussion topics) are rolling over to guide our discussions. The topics that receive the most votes out of the below six will guide our discussions:\n\nEden Fractal Spring Break\n\nEden Fractal Community Agreement\n\nEden Fractal Intent Document\n\nEden+Fractal Improvements\n\nExploring Matrix.org\n\nRecognizing Prior Contributions\n\nTo view all topics, visit the Topics snapshot poll. Community members can also request specific contributions through the contribution requests feature—learn more in this Snapshot poll. For the full rules of the game, check out the article linked in the polls.\nWhether you’re new to fractals or a longtime participant, everyone’s welcome to share their thoughts and help shape the fractal ecosystem. You’re welcome to register on the Eden Creators Events calendar.\nCatch up on recent discussions\nThe Eden Town Hall event video from March 5th is now available to watch here \n\n ETH 75: Envisioning Firmament & SRT Coordination\n\nAs always, you can find more of the latest Eden Fractal and Eden Town Hall videos on the Eden Creators youtube channel. We hope to see you at an upcoming event and/or join the conversation on social media channels. Enjoy!\n\n Load more posts below","tokens":13423,"squid":"spider-07","role":"Council Spider","at":1791345668179,"hash":"b6a29b2ea5872e1f99bdfff6831d448b887b902f"}
{"url":"https://forum.across.to/t/discontinue-acx-bribes-on-aura-and-replace-with-reward-locking-in-the-near-term/1682/7","domain":"forum.across.to","title":"Discontinue ACX Bribes on Aura and Replace with Reward Locking in the Near Term - Proposals - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n Proposals\n\n treasury-funding\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n read \n\n 4\n min\n\n Jul 2023\n\n 7 / 7\n\n Aug 2023\n\n Jul 2023\n\n post by Kevin_UMA on Jul 19, 2023\n\n post by Clayton_UMA on Jul 19, 2023\n\n post by hash_error on Jul 20, 2023\n\n post by zkPantani on Jul 21, 2023\n\n zkPantani\n\n I’m in favor of this proposal as well. Has there been any discussion about redirecting a part from the ACX bridging pool rewards towards the wstETH / ACX pool?\nThe ACX bridging pool as it currently stands is pretty much useless from my pov since there isn’t anything to do with ACX outside of Eth mainnet. Contrary to this, the liquidity pool (a classic pool2) has a big utility factor for the protocol. Pointing incentives towards that is favorable imho.\n\n post by Kevin_UMA on Jul 23, 2023\n\n Kevin_UMA\n\n hash_error\n\n Arrakis PALM does that management through their vaults. But yes I do think we should have a committee that helps look after POL and helps directs funds to these initiatives and set risk parameters etc\n\n post by Kevin_UMA on Jul 23, 2023\n\n Kevin_UMA\n\n zkPantani\n\n Yes agree with this and we have had discussions about this but no formal proposal yet. I think reducing emissions from acx stakers and moving to wstETH / ACX pool and also incentivizing capital into new assets on Across also makes sense. For example we could temporarily have acx rewards for POOL to get that community familiar with providing bridging liquidity on Across. And as new assets get added we move those rewards elsewhere and some of the incentivized capital should remain sticky\n\n 1 month later\n\n Closed on Aug 22, 2023\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 ACX Bribes on Aura - Reimburse Risk Labs and Plan Forward\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 3\n\n May 2023\n\n $ACX Liquidity - Update and Feedback Wanted\n\n Ideas & Feedback\n\n Ideas & Feedback\n\n 7\n\n Jun 2023\n\n Across Token Launch Proposal v2\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 47\n\n Nov 2022\n\n Across ($ACX) Community Initial Liquidity Proposal\n\n Passed Proposals\n\n Passed Proposals\n\n 49\n\n Nov 2022\n\n Reduce or Reallocate Across ACX LP emissions\n\n Ideas & Feedback\n\n liquidity\n\n Ideas & Feedback\n\n 2\n\n Sep 2023","tokens":2075,"squid":"spider-09","role":"Bridge Spider","at":1791345674603,"hash":"1891bb511954d87f319c4c1dace824f488d187ad"}
{"url":"https://ethereum.org/apps/balancer/","domain":"ethereum.org","title":"Ethereum Apps - Balancer | ⁦ethereum.org⁩","text":"DeFiBalancerby Balancer LabsEnglish Visit Balancer (opens in a new tab) (opens in a new tab) (opens in a new tab) (opens in a new tab)See nextUsual See nextUsual Balancer is a decentralized automated market maker (AMM) protocol built on Ethereum with a clear focus on fungible and yield-bearing liquidity. Balancer's success is intrinsically linked to the success of protocols and products built on the platform.InfoFounded2020CreatorBalancer LabsLast updated457 days agoGalleryMore apps like thisDeFiUniswapUniswap is an automated liquidity protocol powered by a constant product formula and implemented in a system of non-upgradeable smart contracts on the Ethereum blockchain. It obviates the need for trusted intermediaries, prioritizing decentralization, censorship resistance, and security.DEXDeFiCurveCurve.fi is a non-custodial decentralized exchange that revolutionized stablecoin trading. It began by offering superior exchange rates for stablecoin swaps (like DAI to USDC) through liquidity pools, where users earn yield by depositing their assets.DEXDeFiFluidFluid is a DeFi protocol combining a liquidity layer, automated limits, lending and vault protocols, robust oracle system, and DEX protocol,Lending and borrowing · DEX","tokens":310,"squid":"spider-05","role":"Spec Spider","at":1791345680421,"hash":"5a327e9de61bea467cb9113a654460dda4dd83f7"}
{"url":"https://ethresear.ch/t/about-the-economics-category/1080/3","domain":"ethresear.ch","title":"About the Economics category - Economics - Ethereum Research","text":"Economics\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n Feb 2018\n\n 2 / 4\n\n Jan 2022\n\n Jul 2025\n\n post by vbuterin on Feb 14, 2018\n\n vbuterin\n\n (Replace this first paragraph with a brief description of your new category. This guidance will appear in the category selection area, so try to keep it below 200 characters. Until you edit this description or create topics, this category won’t appear on the categories page.)\nUse the following paragraphs for a longer description, or to establish category guidelines or rules:\n\nWhy should people use this category? What is it for?\n\nHow exactly is this different than the other categories we already have?\n\nWhat should topics in this category generally contain?\n\nDo we need this category? Can we merge with another category, or subcategory?\n\n 2\n\n 4 years later\n\n post by STZeed on Jan 3, 2022\n\n STZeed\n\n This is for developing. To help grow. This has community before profit with improvement. Communities online and of line.\n\n 3 months later\n\n post by STZeed on Mar 28, 2022\n\n STZeed\n\n Creptocerncy Research By “Zachary Anello”. Problem… Confusion amount average workforce. “Concept” Dow NFTID union. Companies offer benefits by investing in union tokens. To pool in industry or give out their own coin registered on the market. Creating Industry Pool governed by companies DoW or IDNFT personal Wp 401k DoW, Wp insurance Dow, and Wp dental Dow. Coin pooling for companies to offer Tokenes Baked by the IDnft number of activities in an industry coin and one’s own time spent in the industry for personal retirement control plus benefits. A Global workforce union governed by legal geographical Industry DOW. With 3 or more company participation. Proof of study or work a GID, “global industry DoW” governed by IDnft union holders will have a lifelong ability to utilize the dow union for retirement or change of industry time is ongoing for all holding Gi union IDnft time + level = Benefits from the Global DoW union funds. A regional workforce of individuals in a proven industry adding to a verifiable IDnft sincerity, 10 year states With a confirmed yearly NFT update ID.AI.AS\n\n 3 years later\n\n post by jonhubby on Jul 8, 2025\n\n jonhubby\n\n “Wow, that’s quite an interesting concept, STZeed. Mixing blockchain and workforce benefits is ambitious. Do you have any examples of companies already trying something similar?”\n\n Powered by Discourse","tokens":602,"squid":"spider-04","role":"Research Spider","at":1791345682409,"hash":"f7f791e6525e671a2cffa22d422b8326c6017a70"}
{"url":"https://forum.across.to/t/acx-bribes-on-aura-reimburse-risk-labs-and-plan-forward/1626","domain":"forum.across.to","title":"ACX Bribes on Aura - Reimburse Risk Labs and Plan Forward - Proposals - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n ACX Bribes on Aura - Reimburse Risk Labs and Plan Forward \n\n Proposals\n\n treasury-funding\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n May 2023\n\n 1 / 5\n\n May 2023\n\n May 2023\n\n post by Kevin_UMA on May 11, 2023\n\n Kevin_UMA\n\n Title: ACX Bribes on Aura - Reimburse Risk Labs and Plan Forward\nAuthor(s): Kevin Chan\nStatus: Proposal\nSubmission Date: May 11, 2023\nSummary:\nOver the last 5 months, Risk Labs deposited 2.3MM ACX of its own holdings as bribes to Aura Finance to drive emissions to the wstETH / ACX pool on Balancer. This has helped jumpstart liquidity in the ACX token and created a pool that is over $1MM in value. Risk Labs took this action for the benefit of ACX token holders and should now be reimbursed. In addition, the Across DAO should work to implement a process to vote on and execute this bribe itself given a robust governance system is now in place with the deployment of oSnap.\nMotivation/Rationale:\nWhen the ACX token first launched, the infrastructure for Across protocol governance was just forming and not ready for the community; however, there was an immediate need for better liquidity in the token. Instead of using its multisig signing rights on the Across DAO treasury and enforcing a decision to use DAO assets, Risk Labs decided to front its own ACX tokens to incentivize liquidity with the hope that it would be reimbursed in the future.\nStarting on December 8, 2022, Risk Labs deposited a bribe to Aura Finance via Hidden Hand of 150,000 to 300,000 ACX each epoch (every 2 weeks) to drive emissions to the wstETH / ACX pool on Balancer. A total of 2.3MM ACX was deposited for this purpose. The ACX was transferred from the Risk Labs multisig to an EOA that executed the transactions. All bribe transactions are summarized and can be verified in this table. In addition, Risk Labs locked its own holdings of BAL and ETH to receive veBAL and has been using that to further boost emissions in the wstETH / ACX pool via gauge voting. The combination of the two have helped to create a liquidity pool that is over $1MM in value and has greatly benefited ACX token holders.\nNow that Across protocol has deployed oSnap and optimistic governance is in place, the Across DAO treasury should reimburse Risk Labs for this 2.3MM ACX. The Across DAO has the ability to take ownership of this process to control and execute these bribes as a community. Risk Labs will continue to support the Across DAO to ensure ACX liquidity remains healthy and will assist the DAO in setting up this process.\nThe current set up of oSnap is not ideal for directly depositing bribes into Aura for the following reasons:\n\nThe Across DAO treasury would need to interact with an external smart contract which has a tail risk of exposing the protocol and its assets.\nThe current oSnap parameters are purposely set to be conservative in the initial stages with a 7 day Snapshot voting period and a 3 day dispute window to validate transactions using the UMA optimistic oracle. This is a long time frame given the 2 week epoch for bribes. The intention is to reduce these windows as ACX token holders become more familiar with oSnap.\nWith the current rules set in the module, ACX token holders would need to vote every 2 weeks to approve a bribe. The ideal set up would be one vote to designate an entity like Risk Labs to spend a certain amount to directly execute bribes on Hidden Hand. This would require some design work and a change in the rule set.\n\nOver the next few weeks, Risk Labs will work with the Across community to design a process that efficiently implements the desired outcome without putting the DAO treasury at risk and burdening ACX token holders.\nIn the meantime, Risk Labs can continue executing bribes on behalf of the Across DAO to maintain the emissions for the wstETH / ACX Balancer pool. I propose sending an additional 600,000 ACX to Risk Labs which is equivalent to 4 bribes or 8 weeks of incentives. The bribes of 150,000 ACX each would be deposited on May 25, June 8, June 22, and July 6, 2023. This will ensure there is healthy liquidity in the ACX token over this period. In addition, a vote for this course of action would signify an approval that the community would like to continue using bribes on Aura as a way to incentive liquidity in the ACX token.\nSpecification & Implementation:\nThe oSnap module on Snapshot will be used to approve and execute two separate transactions:\n\nA vote to reimburse Risk Labs for the 2.3MM ACX. This vote will be proposed on Snapshot where ACX token holders can vote to approve a transaction to send 2,300,000 ACX from the Across DAO treasury to the Risk Labs multisig. Once approved, anybody can propose this transaction and then execute it after it passes a liveness period where the UMA optimistic oracle verifies it is legitimate.\nA vote to transfer an additional 600k ACX for Risk Labs to continue depositing bribes on Aura - 4 bribes of 150k ACX each starting on May 25th, 2023. This vote will be proposed on Snapshot where ACX token holders can vote to approve a transaction to send 600,000 ACX from the Across DAO treasury to the Risk Labs multisig. Once approved, anybody can propose this transaction and then execute it after it passes a liveness period where the UMA optimistic oracle verifies it is legitimate.\n\nVoting:\n\n Should the Across DAO reimburse Risk Labs for the 2,300,000 ACX tokens it had deposited over the last 5 months as bribes on Aura to drive emissions into the wstETH / ACX Balancer pool?\n\n 100%\n Yes\n\n 0%\n Abstain\n\n 0%\n No\n\n 7\n voters\n\n Closed May 2023\n\n Should the Across DAO transfer an additional 600,000 ACX tokens to Risk Labs. Risk Labs will act on behalf of Across DAO to deposit 4 bribes of 150k ACX each on Aura on May 25, June 8, June 22, and July 6, 2023 to continue incentivizing ACX liquidity by driving emissions into the wstETH / ACX Balancer pool?\n\n 100%\n Yes\n\n 0%\n Abstain\n\n 0%\n No\n\n 6\n voters\n\n Closed May 2023\n\n ACX Market Making Proposal - Arrakis PALM\n\n Updated - [ACX] Market Making Proposal - Arrakis PALM\n\n Discontinue ACX Bribes on Aura and Replace with Reward Locking in the Near Term\n\n $ACX Liquidity - Update and Feedback Wanted\n\n 2\n\n post by Clayton_UMA on May 11, 2023\n\n Clayton_UMA\n\n So just to understand, we’re paying back previous incentives, and pre-paying a window of future incentives, to Risk Labs.\nDuring that window of future incentives, we’ll set up the system where the DAO no longer needs Risk Labs to manage this and can do it autonomously. Yeh?\n\n post by Kevin_UMA on May 12, 2023\n\n Kevin_UMA\n\n Yes that is right @Clayton_UMA. But just to be clear - Risk Labs is not earning anything. It’s directly passing the ACX tokens as bribes on behalf of Across DAO. (I just notice you typed “pre-paying a window of future incentives, to Risk Labs.”)\n\n post by eth-wei-trader on May 18, 2023\n\n eth-wei-trader\n\n I’d like to propose a new Balancer / liquidity mining set-up before we continue to bribe the current ACX Balancer pool.\nI think the Balancer pool that ACX incentivizes should contain Across LP shares, similar to how Balancer integrates with Aave. This way we can bolster the Across’s bridge liquidity while also deepening ACX’s liquidity for trading. I can do a more comprehensive write up in a day or two.\n\n 1 month later\n\n Closed on Jun 17, 2023\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 Discontinue ACX Bribes on Aura and Replace with Reward Locking in the Near Term\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 5\n\n Jul 2023\n\n Across ($ACX) Community Initial Liquidity Proposal\n\n Passed Proposals\n\n Passed Proposals\n\n 49\n\n Nov 2022\n\n $ACX Liquidity - Update and Feedback Wanted\n\n Ideas & Feedback\n\n Ideas & Feedback\n\n 7\n\n Jun 2023\n\n Across Token Launch Proposal v2\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 47\n\n Nov 2022\n\n Risk Labs Retroactive Funding and Future Development\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 5\n\n Sep 2024","tokens":3504,"squid":"spider-09","role":"Bridge Spider","at":1791345686570,"hash":"c8445e12da69cc3d49b080f0477316acb5c34375"}
{"url":"https://ethereum.org/apps/fluid/","domain":"ethereum.org","title":"Ethereum Apps - Fluid | ⁦ethereum.org⁩","text":"DeFiFluidby InstadappEnglish Visit Fluid (opens in a new tab) (opens in a new tab) (opens in a new tab) (opens in a new tab)See nextFraxSee nextFraxFluid is a DeFi protocol combining a liquidity layer, automated limits, lending and vault protocols, robust oracle system, and DEX protocol,InfoFounded2024CreatorInstadappLast 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 borrowingDeFiUniswapUniswap is an automated liquidity protocol powered by a constant product formula and implemented in a system of non-upgradeable smart contracts on the Ethereum blockchain. It obviates the need for trusted intermediaries, prioritizing decentralization, censorship resistance, and security.DEX","tokens":288,"squid":"spider-05","role":"Spec Spider","at":1791345691883,"hash":"f598221bb2a778fa0c0689ac29e9a3358cba9e7d"}
{"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 874\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 123\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 676\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 421\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 784\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 292\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":"spider-04","role":"Research Spider","at":1791345692735,"hash":"5cdeb6c02d6e3ac5ed45d4f270fcbe88097b5026"}
{"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":"spider-05","role":"Spec Spider","at":1791345702189,"hash":"0c1b4026d3acaf30735b79fa4be7dd8da7c26b9d"}
{"url":"https://ethresear.ch/t/native-ethereum-delegation-ned-protocol-routed-delegation-with-split-neutral-allocation-and-coverage-bounded-consensus-amplification/25699/1","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 12\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":"spider-04","role":"Research Spider","at":1791345705404,"hash":"398c162a87ba4ccb153d46048572e6f53e4bccec"}
{"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":"spider-05","role":"Spec Spider","at":1791345712550,"hash":"7b2c478e0a79609da26e118a32b055946dba2acd"}
{"url":"https://www.metaplex.com/docs/solana/understanding-pdas","domain":"metaplex.com","title":"Understanding Solana Program Derived Addresses | Guides","text":"OverviewProgram Derived Addresses (PDAs) are special types of account used on Solana that are deterministically derived and look like standard public keys, but have no associated private keys.Only the program that derived the PDA can sign transactions involving the address/account. This is due to the fact that PDAs do not occur on the Ed25519 curve (elliptic-curve cryptography). Only addresses that appear on the curve can have a matching private key making PDAs a secure way of signing transactions from within a program. This means that no external user can generate a valid signature for the PDA address and sign on behalf of a pda/program.Role of PDAsPDAs are primarily used to:Manage State: PDAs allow programs to create accounts and store data to a deterministic PDA address which allows read and write access for the program.Authorize Transactions: Only the program that owns the PDA can authorize transactions involving it, ensuring secure controlled access. For example this allows programs and PDA accounts to store tokens/own NFTs that would require the current owner of the tokens/NFT to sign a transaction to transfer the items to another account.How PDAs are DerivedPDAs are derived using a combination of a program ID and a set of seed values. The derivation process involves hashing these values together and ensuring the resulting address is valid.Derivation ProcessSelect Program ID: The public key of the program for which the PDA is being derived.Choose Seeds: One or more seed values that, together with the program ID, will deterministically generate the PDA algorithmically based on the combined values.Compute PDA: Use the Pubkey::find_program_address function to derive the PDA. This function ensures the derived address is valid and cannot collide with any regular (non-PDA) address.Example in RustHere's an example of deriving a PDA in a Solana program written in Rust:use solana_program::{\n pubkey::Pubkey,\n system_instruction,\n system_program,\n sysvar::rent::Rent,\n program::invoke_signed,\n};\n\n// Function to derive a PDA\nfn derive_pda(program_id: &Pubkey, seeds: &[&[u8]]) -> (Pubkey, u8) {\n Pubkey::find_program_address(seeds, program_id)\n}\n\n// Example usage\nfn example_usage(program_id: &Pubkey) {\n // Define seeds\n let seed1 = b\"seed1\";\n let seed2 = b\"seed2\";\n\n // Derive PDA\n let (pda, bump_seed) = derive_pda(program_id, &[seed1, seed2]);\n\n // Print PDA\n println!(\"Derived PDA: {}\", pda);\n}\nPractical Use Case: Account Creation Programs often use PDAs to create and manage program-specific accounts. Here's an example of how a PDA can be used to create an account:\nuse solana_program::{\n pubkey::Pubkey,\n system_instruction,\n system_program,\n sysvar::rent::Rent,\n program::invoke_signed,\n};\n\nfn create_account_with_pda(\n program_id: &Pubkey,\n payer: &Pubkey,\n seeds: &[&[u8]],\n lamports: u64,\n space: u64,\n) -> Result<(), ProgramError> {\n let (pda, bump_seed) = Pubkey::find_program_address(seeds, program_id);\n\n let create_account_ix = system_instruction::create_account(\n payer,\n &pda,\n lamports,\n space,\n program_id,\n );\n\n // Sign the instruction with the PDA\n let signers_seeds = &[&seeds[..], &[bump_seed]];\n\n invoke_signed(\n &create_account_ix,\n &[payer_account_info, pda_account_info],\n signers_seeds,\n )?;\n\n Ok(())\n}","tokens":816,"squid":"dotcat","role":"Tooling Spider","at":1791345713288,"hash":"bc9274ee301711892f6bb2d302fc92382f087029"}
{"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":"spider-05","role":"Spec Spider","at":1791345722735,"hash":"3df28452b7375818de94b581efb72b676456c91b"}
{"url":"https://www.metaplex.com/docs/solana","domain":"metaplex.com","title":"Metaplex Solana Guides | Guides","text":"The guides in this section are designed to help new Solana developers start their journey by providing step-by-step instructions and practical examples they can execute. These guides focus on teaching key concepts with a structured learning path that gradually introduces developers to the Solana ecosystem. They cover everything from the basics of blockchain and Solana's unique features to advanced topics such as program development and optimization techniques.By incorporating a variety of learning resources, including tutorials and code samples, the guides are designed to be accessible to new and experienced developers in the space. The guides are regularly updated to reflect the latest developments in the Solana ecosystem.The guides are shared for educational and informational purposes only and are not to be relied upon as professional advice. All content included in these learning resources are not guaranteed to be current or error-free.Program Guides IndexairdropanchorjavascriptnftsrusttokensBubblegum V1How to create 1000000 NFTs on SolanaHow to interact with CNFTs on other SVMSCandy MachineAirdrop Mint to Another WalletCreate an NFT Collection on Solana with Candy MachineCore Candy MachineCreate a Core Candy Machine UICreate a Core Candy Machine with Hidden SettingsCoreImmutable NFTsCreate Soulbound NFT AssetPrint EditionsOracle Plugin ExampleOnchain Ticketing with AppDataHow to create a Core NFT Asset with JavaScriptHow to create a Core Collection with JavascriptWeb2 Typescript Staking ExampleLoyalty Card Concept GuideHow to create a Core NFT Asset with AnchorHow to create a Core Collection with AnchorAnchor Staking ExampleToken MetadataGet NFTs By CollectionAccount Size ReductionCreate a Claimable Token Airdrop with MPL-DistroToken Claimer Smart ContractCreate an NFTUmiOptimal Transactions with Compute Units and Priority FeesSerializing and Deserializing Transactions","tokens":476,"squid":"dotcat","role":"Tooling Spider","at":1791345723152,"hash":"983465817384969771d00729e65b862e0d8c0dc4"}
{"url":"https://ethresear.ch/t/timing-the-head-in-ethereum-pos/25766","domain":"ethresear.ch","title":"Timing the Head in Ethereum PoS - Proof-of-Stake / Economics - Ethereum Research","text":"Timing the Head in Ethereum PoS \n\n Proof-of-StakeEconomics\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Aug 19\n\n 1 / 3\n\n Aug 19\n\n Sep 1\n\n post by Yolodannn on Aug 19\n\n Yolodannn\n\n Description\nIn Ethereum PoS, many reorganization attacks manipulate validators’ views of the head, causing their attestation weight to be distributed across different branches and potentially triggering a reorganization. This shows that the head plays a critical role in consensus security. Meanwhile, head votes also account for a significant part of attestation rewards and must satisfy a strict timing condition to be rewarded, making them particularly vulnerable to loss. However, the role of the head in consensus security and validator incentives has not been studied in a unified way.\nBackground\nHead Vote.\nValidators attest to the block they consider the head according to LMD-GHOST. Unlike source and target votes, the head reward depends strongly on whether the validator observes the correct block in time.\nAttestation Timing.\nIn each 12-second slot, validators normally attest before 4 seconds after the beginning of the slot. Therefore, a proposer that controls when its block is released can influence the local view used by honest attesters.\nProposer Boost.\nEthereum gives the current-slot block additional temporary fork-choice weight for 40%. This mechanism is intended to minimize an ex ante reorg attack and balancing attack, but it also affects the outcome when competing branches are deliberately created.\nAttack Scenario\nWe consider two timing-based attack scenarios that exploit the role of the head vote in Ethereum PoS.\n\nHead-vote timing game . An adversarial proposer delays the broadcast of its block within a plausible network-delay range and releases it close to the attestation deadline. Honest validators that have not received the block and continue to regard its parent as the head and therefore vote for the parent, causing them to lose the head component of their attestation reward once the delayed block becomes canonical. Importantly, such delayed delivery cannot be reliably identified by the protocol as malicious behavior, since a late block may also result from ordinary network propagation delay.\nTiming Game-p3991×1121 90.8 KB\n\nK-block attack. We further generalize the attack to consecutive adversarial proposer slots. When the attacker controls k consecutive proposers, it can privately extend a competing branch while withholding these blocks from honest validators. The private branch can isolate subsequent honest blocks and, once released, become the canonical chain and trigger a reorganization. As a result, honest validators may cast head votes for blocks that are later removed from the canonical chain, again causing the loss of their head-vote rewards.\nk-block-p2000×1172 81.6 KB\n\nImpact\nOur Prysm experiments show that this timing manipulation produces a persistent reward asymmetry.\nthe head-vote timing game produces a 15.06% average total reward loss for honest validators. The same block-visibility asymmetry can also affect HLMD-GHOST directly: under k-block withholding, coordinated adversarial proposers and attesters can accumulate enough private fork-choice weight to realize reorganization\nTo reduce the incentive loss caused by these stale local views, we explore a distance-weighted head reward that gives partial rewards to eligible attestations pointing to recent canonical ancestors, while retaining the highest reward for voting for the freshest canonical head. The mechanism changes only the reward calculation and leaves HLMD-GHOST and proposer boost unchanged. In our experiments, it reduces the timing-game loss from 15.06% to 4.71%, and consistently reduces honest reward losses under the K-block attack. It does not eliminate losses caused by orphaned branches or all reorganization effects, but substantially reduces the reward disadvantage experienced by honest validators.\n\n 2\n\n post by yzcrypto on Aug 23\n\n yzcrypto\n\n These two discussed attack scenarios are reasonable and also intuitive for LMD-GHOST, but the mainnet proposers simply won’t do so.\nCurrent mainnet block proposers are already enforcing the first strategy, which is to delay the block broadcast time. But their purpose is to maximize their revenue from PBS by extending the auction window, from 0s of the current slot to a time before 4s, and they make sure their proposed block will be included in the canonical chain.\nTechnically, no block proposers will do such attacks. For the head-vote timing game, making validators lose their rewards also means a high probability of that block being reorged, and the block proposer will not receive his reward from the protocol or from PBS.\nFor the k-block attack, I think a block proposer will not do it either because his revenue comes largely from the block auction, and it is not guaranteed that the withheld blocks will ultimately beat the branch from k+1 to 2k-1, so for revenue maximization the proposer will simply reveal his blocks rather than withholding them.\nHow is the value 15.06% derived? Is there a technical report or a paper, as you seem to have completed this research?\n\n 8 days later\n\n post by Yolodannn on Sep 1\n\n Yolodannn\n\n Thank you for the thoughtful comment. We agree with part of your economic interpretation, but would like to clarify the objective and threat model of our work.\nFor the head-vote timing scenario, we agree that the usual motivation is to extend the PBS auction window and obtain a higher builder bid. Our point is that this common, economically motivated behavior creates a negative externality at the head-vote layer: as the broadcast time approaches the 4-second attestation deadline, some honest attesters may not receive the new block in time, follow the protocol by voting for its parent, and nevertheless lose their head-vote reward if the delayed block becomes canonical. The attesters behave honestly throughout the process, yet still suffer a reward loss. This is the incentive fragility we intend to highlight.\nWe also do not think that missed head votes necessarily imply a high probability that the delayed block will be reorged. In the current proposer-reorg logic, a head is considered weak only when its weight is below REORG_HEAD_WEIGHT_THRESHOLD, currently 20% of one slot committee’s weight. If the delayed block obtains at least this amount of weight, an honest next proposer following this single-slot reorg heuristic will not reorg it through that mechanism.\nThe purpose of a reorg attack is not to maximize ordinary block-auction revenue, but to obtain additional economic benefits—such as double-spending, transaction reordering, front-running, or censorship.\nIf the attack succeeds, the Byzantine blocks become canonical, so their proposers retain the ordinary consensus-layer rewards while also capturing these additional reorg-related gains. In contrast, honest proposers whose blocks are orphaned lose their block rewards, and honest attesters voting for the displaced blocks lose their head-vote rewards. The attack therefore creates a reward asymmetry: the Byzantine group gains additional economic value while the honest validator group suffers reward losses.\nFinally, the 15.06% value is an empirical result from our Prysm experiments, not a value derived analytically from the protocol’s head-reward weight. It represents the measured average total reward loss of honest validators under our experimental timing-game configuration relative to the baseline.\n\n Powered by Discourse","tokens":1887,"squid":"spider-04","role":"Research Spider","at":1791345725839,"hash":"64dde7911373d2daaf0f318b3923698dca4a4263"}
{"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":"spider-05","role":"Spec Spider","at":1791345732703,"hash":"dd8c536b2c50f7e46126fcfa26d34c5b926681a5"}
{"url":"https://www.metaplex.com/docs/smart-contracts/bubblegum/guides/javascript/how-to-interact-with-cnfts-on-other-svms","domain":"metaplex.com","title":"How to Interact with cNFTs on Other SVMs | Bubblegum","text":"Bubblegum v1 is a legacy program. It remains supported, but is not recommended for new projects. Use Bubblegum V2 instead.OverviewThis guide details the specific requirements for interacting with compressed NFT (cNFT) assets using JavaScript on Solana Virtual Machine (SVM) environments other than Solana's devnet and mainnet-beta. For a more comprehensive overview of creating cNFTs, see the Create 1,000,000 NFTs on Solana with Bubblegum guide.Required PackageThis guide makes use of a specific beta npm package for @metaplex-foundation/mpl-bubblegum. Install using:npm -i @metaplex-foundation/mpl-bubblegum@4.3.1-beta.0\nConnecting to the SVMNote you will need to create your umi instance using the endpoint for the SVM.import { createUmi } from \"@metaplex-foundation/umi-bundle-defaults\";\n\nconst umi = createUmi('<RPC endpoint for the SVM>')\n .use(mplBubblegum())\n .use(mplTokenMetadata())\n ...\nCreating a TreeTree CostWe are creating a Merkle Tree that with a real up-front SOL cost that will vary depending on the tree size and the specific SVM you are using. Until you are ready, please try this example on devnet only, as Merkle Trees can not be closed or refunded.Creating a tree can be done using the same createTree function that is used on Solana devnet/mainnet-beta. However, we must override the default logWrapper and compressionProgram values. This could be accomplished as simply as:import {\n createTree,\n MPL_ACCOUNT_COMPRESSION_PROGRAM_ID,\n MPL_NOOP_PROGRAM_ID,\n} from '@metaplex-foundation/mpl-bubblegum'\nimport {\n generateSigner,\n publicKey,\n} from '@metaplex-foundation/umi';\n\n// Create a Merkle tree specifying the correct `logWrapper` and\n// `compressionProgram` for the SVM.\nconst merkleTree = generateSigner(umi);\nconst createTreeTx = await createTree(umi, {\n merkleTree,\n maxDepth: 3,\n maxBufferSize: 8,\n canopyDepth: 0,\n logWrapper: MPL_NOOP_PROGRAM_ID,\n compressionProgram: MPL_ACCOUNT_COMPRESSION_PROGRAM_ID,\n});\n\nawait createTreeTx.sendAndConfirm(umi);\nHowever, a helper function has been provided to automatically resolve these program IDs, and this is the recommended approach as it will work on Solana devnet/mainnet-beta as well as other SVMs to which Bubblegum has been deployed:import {\n getCompressionPrograms,\n createTree,\n} from '@metaplex-foundation/mpl-bubblegum'\nimport {\n generateSigner,\n publicKey,\n} from '@metaplex-foundation/umi';\n\n// Create a Merkle tree using the `getCompressionPrograms` helper function.\nconst merkleTree = generateSigner(umi);\nconst createTreeTx = await createTree(umi, {\n merkleTree,\n maxDepth: 3,\n maxBufferSize: 8,\n canopyDepth: 0,\n ...(await getCompressionPrograms(umi)),\n});\n\nawait createTreeTx.sendAndConfirm(umi);\nMint and Transfer a cNFTSimilarly to creating the Merkle tree on another SVM, other SDK functions such as mintV1 and transfer will also require specifying the compression programs. Again we use the getCompressionPrograms helper.import {\n fetchMerkleTree,\n getCurrentRoot,\n hashMetadataCreators,\n hashMetadataData,\n transfer,\n getCompressionPrograms,\n createTree,\n MetadataArgsArgs,\n mintV1,\n} from '@metaplex-foundation/mpl-bubblegum'\nimport {\n generateSigner,\n none,\n} from '@metaplex-foundation/umi';\n\n// Get leaf index before minting.\nconst leafIndex = Number(\n (await fetchMerkleTree(umi, merkleTree.publicKey)).tree.activeIndex\n);\n\n// Define Metadata.\nconst metadata: MetadataArgsArgs = {\n name: 'My NFT',\n uri: 'https://example.com/my-nft.json',\n sellerFeeBasisPoints: 500, // 5%\n collection: none(),\n creators: [],\n};\n\n// Mint a cNFT.\nconst originalOwner = generateSigner(umi);\nconst mintTxn = await mintV1(umi, {\n leafOwner: originalOwner.publicKey,\n merkleTree: merkleTree.publicKey,\n metadata,\n ...(await getCompressionPrograms(umi)),\n}).sendAndConfirm(umi);\n\n// Transfer the cNFT to a new owner.\nconst newOwner = generateSigner(umi);\nconst merkleTreeAccount = await fetchMerkleTree(umi, merkleTree.publicKey);\nconst transferTxn = await transfer(umi, {\n leafOwner: originalOwner,\n newLeafOwner: newOwner.publicKey,\n merkleTree: merkleTree.publicKey,\n root: getCurrentRoot(merkleTreeAccount.tree),\n dataHash: hashMetadataData(metadata),\n creatorHash: hashMetadataCreators(metadata.creators),\n nonce: leafIndex,\n index: leafIndex,\n proof: [],\n ...(await getCompressionPrograms(umi)),\n}).sendAndConfirm(umi);","tokens":1076,"squid":"dotcat","role":"Tooling Spider","at":1791345733136,"hash":"9198b9c2b9d50eefe8622a5485666ef2176d5a5b"}
{"url":"https://ethresear.ch/t/timing-the-head-in-ethereum-pos/25766/3","domain":"ethresear.ch","title":"Timing the Head in Ethereum PoS - 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 Aug 19\n\n 3 / 3\n\n Aug 31\n\n Sep 1\n\n post by Yolodannn on Aug 19\n\n Yolodannn\n\n Description\nIn Ethereum PoS, many reorganization attacks manipulate validators’ views of the head, causing their attestation weight to be distributed across different branches and potentially triggering a reorganization. This shows that the head plays a critical role in consensus security. Meanwhile, head votes also account for a significant part of attestation rewards and must satisfy a strict timing condition to be rewarded, making them particularly vulnerable to loss. However, the role of the head in consensus security and validator incentives has not been studied in a unified way.\nBackground\nHead Vote.\nValidators attest to the block they consider the head according to LMD-GHOST. Unlike source and target votes, the head reward depends strongly on whether the validator observes the correct block in time.\nAttestation Timing.\nIn each 12-second slot, validators normally attest before 4 seconds after the beginning of the slot. Therefore, a proposer that controls when its block is released can influence the local view used by honest attesters.\nProposer Boost.\nEthereum gives the current-slot block additional temporary fork-choice weight for 40%. This mechanism is intended to minimize an ex ante reorg attack and balancing attack, but it also affects the outcome when competing branches are deliberately created.\nAttack Scenario\nWe consider two timing-based attack scenarios that exploit the role of the head vote in Ethereum PoS.\n\nHead-vote timing game . An adversarial proposer delays the broadcast of its block within a plausible network-delay range and releases it close to the attestation deadline. Honest validators that have not received the block and continue to regard its parent as the head and therefore vote for the parent, causing them to lose the head component of their attestation reward once the delayed block becomes canonical. Importantly, such delayed delivery cannot be reliably identified by the protocol as malicious behavior, since a late block may also result from ordinary network propagation delay.\nTiming Game-p3991×1121 90.8 KB\n\nK-block attack. We further generalize the attack to consecutive adversarial proposer slots. When the attacker controls k consecutive proposers, it can privately extend a competing branch while withholding these blocks from honest validators. The private branch can isolate subsequent honest blocks and, once released, become the canonical chain and trigger a reorganization. As a result, honest validators may cast head votes for blocks that are later removed from the canonical chain, again causing the loss of their head-vote rewards.\nk-block-p2000×1172 81.6 KB\n\nImpact\nOur Prysm experiments show that this timing manipulation produces a persistent reward asymmetry.\nthe head-vote timing game produces a 15.06% average total reward loss for honest validators. The same block-visibility asymmetry can also affect HLMD-GHOST directly: under k-block withholding, coordinated adversarial proposers and attesters can accumulate enough private fork-choice weight to realize reorganization\nTo reduce the incentive loss caused by these stale local views, we explore a distance-weighted head reward that gives partial rewards to eligible attestations pointing to recent canonical ancestors, while retaining the highest reward for voting for the freshest canonical head. The mechanism changes only the reward calculation and leaves HLMD-GHOST and proposer boost unchanged. In our experiments, it reduces the timing-game loss from 15.06% to 4.71%, and consistently reduces honest reward losses under the K-block attack. It does not eliminate losses caused by orphaned branches or all reorganization effects, but substantially reduces the reward disadvantage experienced by honest validators.\n\n 2\n\n post by yzcrypto on Aug 23\n\n yzcrypto\n\n These two discussed attack scenarios are reasonable and also intuitive for LMD-GHOST, but the mainnet proposers simply won’t do so.\nCurrent mainnet block proposers are already enforcing the first strategy, which is to delay the block broadcast time. But their purpose is to maximize their revenue from PBS by extending the auction window, from 0s of the current slot to a time before 4s, and they make sure their proposed block will be included in the canonical chain.\nTechnically, no block proposers will do such attacks. For the head-vote timing game, making validators lose their rewards also means a high probability of that block being reorged, and the block proposer will not receive his reward from the protocol or from PBS.\nFor the k-block attack, I think a block proposer will not do it either because his revenue comes largely from the block auction, and it is not guaranteed that the withheld blocks will ultimately beat the branch from k+1 to 2k-1, so for revenue maximization the proposer will simply reveal his blocks rather than withholding them.\nHow is the value 15.06% derived? Is there a technical report or a paper, as you seem to have completed this research?\n\n 8 days later\n\n post by Yolodannn on Sep 1\n\n Yolodannn\n\n Thank you for the thoughtful comment. We agree with part of your economic interpretation, but would like to clarify the objective and threat model of our work.\nFor the head-vote timing scenario, we agree that the usual motivation is to extend the PBS auction window and obtain a higher builder bid. Our point is that this common, economically motivated behavior creates a negative externality at the head-vote layer: as the broadcast time approaches the 4-second attestation deadline, some honest attesters may not receive the new block in time, follow the protocol by voting for its parent, and nevertheless lose their head-vote reward if the delayed block becomes canonical. The attesters behave honestly throughout the process, yet still suffer a reward loss. This is the incentive fragility we intend to highlight.\nWe also do not think that missed head votes necessarily imply a high probability that the delayed block will be reorged. In the current proposer-reorg logic, a head is considered weak only when its weight is below REORG_HEAD_WEIGHT_THRESHOLD, currently 20% of one slot committee’s weight. If the delayed block obtains at least this amount of weight, an honest next proposer following this single-slot reorg heuristic will not reorg it through that mechanism.\nThe purpose of a reorg attack is not to maximize ordinary block-auction revenue, but to obtain additional economic benefits—such as double-spending, transaction reordering, front-running, or censorship.\nIf the attack succeeds, the Byzantine blocks become canonical, so their proposers retain the ordinary consensus-layer rewards while also capturing these additional reorg-related gains. In contrast, honest proposers whose blocks are orphaned lose their block rewards, and honest attesters voting for the displaced blocks lose their head-vote rewards. The attack therefore creates a reward asymmetry: the Byzantine group gains additional economic value while the honest validator group suffers reward losses.\nFinally, the 15.06% value is an empirical result from our Prysm experiments, not a value derived analytically from the protocol’s head-reward weight. It represents the measured average total reward loss of honest validators under our experimental timing-game configuration relative to the baseline.\n\n Powered by Discourse","tokens":1878,"squid":"spider-04","role":"Research Spider","at":1791345736770,"hash":"46cac30826165e1f32f8ff4cbebbb1ca1aab7257"}
{"url":"https://www.metaplex.com/docs/smart-contracts/bubblegum/guides/javascript/how-to-create-1000000-nfts-on-solana","domain":"metaplex.com","title":"Create 1 Million NFTs on Solana | Bubblegum","text":"Bubblegum v1 is a legacy program. It remains supported, but is not recommended for new projects. Use Bubblegum V2 instead.PrerequisiteCode Editor of your choice (recommended Visual Studio Code).Node 18.x.x or above.Basic knowledge of Javascript and running scripts.Initial SetupThis guide will run through creation of a compressed NFT (cNFT) Asset with Javascript based on a single file script. You may need to modify and move functions around to suit your needs.InitializingStart by initializing a new project (optional) with the package manager of your choice (npm, yarn, pnpm, bun) and fill in required details when prompted.npm init\nRequired PackagesInstall the required packages for this guide.@metaplex-foundation/umi@metaplex-foundation/umi-bundle-defaults@metaplex-foundation/mpl-bubblegum@metaplex-foundation/mpl-token-metadata@metaplex-foundation/umi-uploader-irysnpm i @metaplex-foundation/umi\nnpm i @metaplex-foundation/umi-bundle-defaults\nnpm i @metaplex-foundation/mpl-bubblegum\nnpm i @metaplex-foundation/mpl-token-metadata\nnpm i @metaplex-foundation/umi-uploader-irys\nImports and Wrapper FunctionHere we will define all needed imports for this particular guide and create a wrapper function where all our code will execute.import {\n createTree,\n findLeafAssetIdPda,\n getAssetWithProof,\n mintV1,\n mplBubblegum,\n parseLeafFromMintV1Transaction,\n} from '@metaplex-foundation/mpl-bubblegum'\nimport {\n createNft,\n mplTokenMetadata,\n} from '@metaplex-foundation/mpl-token-metadata'\nimport {\n createGenericFile,\n generateSigner,\n percentAmount,\n publicKey,\n sol,\n} from '@metaplex-foundation/umi'\nimport { Network, Wallet, umiInstance } from '../scripts/umi'\n\nimport fs from 'fs'\nimport { irysUploader } from '@metaplex-foundation/umi-uploader-irys'\n\n// Create the wrapper function\nconst createCnft = async () => {\n ///\n ///\n /// all our code will go in here\n ///\n ///\n}\n\n// run the wrapper function\ncreateCnft()\nSetting up UmiThis example sets up Umi with generateSigner(umi). If you wish to try this example with React, you'll need to set up Umi via the React - Umi w/ Wallet Adapter guide. Apart from the wallet setup, this guide will use fileStorage keys and a wallet adapter.Generating a New Walletconst umi = createUmi('https://api.devnet.solana.com')\n .use(mplBubblegum())\n .use(mplTokenMetadata())\n .use(\n irysUploader({\n // mainnet address: \"https://node1.irys.xyz\"\n // devnet address: \"https://devnet.irys.xyz\"\n address: 'https://devnet.irys.xyz',\n })\n )\n\nconst signer = generateSigner(umi)\n\numi.use(signerIdentity(signer))\n\n// This will airdrop SOL on devnet only for testing.\nconsole.log('Airdropping 1 SOL to identity')\nawait umi.rpc.airdrop(umi.identity.publickey, sol(5))\nUse an Existing Wallet Locallyconst umi = createUmi('https://api.devnet.solana.com')\n .use(mplBubblegum())\n .use(mplTokenMetadata())\n .use(\n irysUploader({\n // mainnet address: \"https://node1.irys.xyz\"\n // devnet address: \"https://devnet.irys.xyz\"\n address: 'https://devnet.irys.xyz',\n })\n )\n\n// Generate a new keypair signer.\nconst signer = generateSigner(umi)\n\n// You will need to us fs and navigate the filesystem to\n// load the wallet you wish to use via relative pathing.\nconst walletFile = fs.readFileSync('./keypair.json')\n\n// Convert your walletFile onto a keypair.\nlet keypair = umi.eddsa.createKeypairFromSecretKey(new Uint8Array(walletFile))\n\n// Load the keypair into umi.\numi.use(keypairIdentity(keypair))\nCreating an cNFTCreating a cNFT on Solana is fairly simple and requires a few items to get ready before we can actually perform the minting and reading operations.A Merkle tree to store our cNFT data to.A DAS ready RPC to be able to read the data from an indexer that is storing our data during creation.Merkle TreeA Merkle Tree for the most park can be thought of as a \"database\" of cNFT data. A Merkle Tree is created and cNFTs can be added to it until it's full.DAS RPCsDue to the nature of a Merkle Tree cNFT data isn't stored in Solana accounts and instead is stored in the ledger state. To be able to read the data back effectively we need to use an indexer which indexes all the cNFT data as its created/mutated. DAS enabled RPCs are RPCs that are running the DAS indexer service and allow us to query the RPC provider for this data on demand.For a full list of RPC provides that support DAS you can visit the RPC Providers PageYou can pick up a free account for running this guide from any of these providers. Once signed up you will want to replace your RPC instance during the previous umi creation.// Replace address located below.\nconst umi = createUmi('https://rpcAddress.com')\nCreating a TreeTree CostWe are creating a Merkle Tree that holds 1,000,000 cNFTs in this guide which requires the cost of roughly 7.7 SOL. Until you are ready, please try this example on devnet only, as Merkle Trees can not be closed or refunded. You will need at least 7.7 devnet SOL in order to run this code. This may require multiple airdrops.To store Compressed NFTs (cNFTs) on the Solana blockchain you need to create a Merkle Tree in which to store the data. The size and cost of the merkle tree is determined by the merkle tree creator and all cNFTs storage on chain is paid for in advanced which differs from Token Metadata's approach of lazy minting where normally the payer would pay for the necessary storage space and account creation on the solana blockchain at the time of minting the NFT itself, with bubblegum all data space needed is determined and paid for at tree creation by the tree creator.There are some unique features regarding a merkle tree compared to Token Metadata that people can take advantage of:You can mint cNFTs to multiple collections within a Merkle Tree.A Merkle Tree isn't a collection!The Merkle Tree can house cNFTs from many collections making it incredibly powerful for projects that know they will have expanded growth in the future. If your Merkle Tree holds 1,000,000 cNFTs and you decide to release and mint a 10k project to said Merkle Tree you will still have 990,000 spaces in the tree to write and release additional cNFTs in the future.//\n// ** Create a Merkle Tree **\n//\n\nconst merkleTree = generateSigner(umi)\n\nconsole.log(\n 'Merkle Tree Public Key:',\n merkleTree.publicKey,\n '\\nStore this address as you will need it later.'\n)\n\n// Create a tree with the following parameters.\n// This tree will cost approximately 7.7 SOL to create with a maximum\n// capacity of 1,000,000 leaves/nfts. You may have to airdrop some SOL\n// to the umi identity account before running this script.\n\nconst createTreeTx = await createTree(umi, {\n merkleTree,\n maxDepth: 20,\n maxBufferSize: 64,\n canopyDepth: 14,\n})\n\nawait createTreeTx.sendAndConfirm(umi)\nCreate a Collection NFTCollections for cNFTs are still maintained and manged by Token Metadata and the original Collection NFTs minted from Token Metadata. If you wish to create a collection for your cNFTs and mint them to it you will need to create a Token Metadata Collection NFT.//\n// ** Create Token Metadata Collection NFT **\n//\n\n//\n// If you wish to mint a NFT to a collection you must first create a collection NFT.\n// This step is optional and you can skip it if you do not wish to mint a NFT to a collection\n// or have previously created a collection NFT.\n//\n\nconst collectionSigner = generateSigner(umi)\n\n// Path to image file\nconst collectionImageFile = fs.readFileSync('./collection.png')\n\nconst genericCollectionImageFile = createGenericFile(\n collectionImageFile,\n 'collection.png'\n)\n\nconst collectionImageUri = await umi.uploader.upload([\n genericCollectionImageFile,\n])\n\nconst collectionMetadata = {\n name: 'My cNFT Collection',\n image: collectionImageUri[0],\n externalUrl: 'https://www.example.com',\n properties: {\n files: [\n {\n uri: collectionImageUri[0],\n type: 'image/png',\n },\n ],\n },\n}\n\nconst collectionMetadataUri = await umi.uploader.uploadJson(collectionMetadata)\n\nawait createNft(umi, {\n mint: collectionSigner.publicKey,\n name: 'My cNFT Collection',\n uri: 'https://www.example.com/collection.json',\n isCollection: true,\n sellerFeeBasisPoints: percentAmount(0),\n}).sendAndConfirm(umi)\nUpload Image and Metadata for cNFT (Optional)Our cNFT needs data and an image. This code block shows us how to upload both an image and then add that image to a metadata object and final upload that object as a json file to Arweave via Irys for use to use with our cNFT.//\n// ** Upload Image and Metadata used for the NFT (Optional) **\n//\n\n// If you already have an image and metadata file uploaded, you can skip this step\n// and use the uri of the uploaded files in the mintV1 call.\n\n// Path to image file\nconst nftImageFile = fs.readFileSync('./nft.png')\n\nconst genericNftImageFile = createGenericFile(nftImageFile, 'nft.png')\n\nconst nftImageUri = await umi.uploader.upload([genericNftImageFile])\n\nconst nftMetadata = {\n name: 'My cNFT',\n image: nftImageUri[0],\n externalUrl: 'https://www.example.com',\n attributes: [\n {\n trait_type: 'trait1',\n value: 'value1',\n },\n {\n trait_type: 'trait2',\n value: 'value2',\n },\n ],\n properties: {\n files: [\n {\n uri: nftImageUri[0],\n type: 'image/png',\n },\n ],\n },\n}\n\nconst nftMetadataUri = await umi.uploader.uploadJson(nftMetadata)\nMint cNFT to the Merkle TreeMinting a cNFT to a tree does not cost any additional account/storage costs on the Solana blockchain as the tree has already been created with enough room for all our cNFT data to be stored (1,000,000 cNFTs in fact). The only additional cost here is just the basic Solana transaction fee making cNFTs incredibly efficient to mint en masse.//\n// ** Mint a Compressed NFT to the Merkle Tree **\n//\n\n//\n// If you do not wish to mint a NFT to a collection you can set the collection\n// field to `none()`.\n//\n\n// The owner of the cNFT being minted.\nconst newOwner = publicKey('111111111111111111111111111111')\n\nconsole.log('Minting Compressed NFT to Merkle Tree...')\n\nconst { signature } = await mintToCollectionV1(umi, {\n leafOwner: newOwner,\n merkleTree: merkleTree.publicKey,\n collectionMint: collectionSigner.publicKey,\n metadata: {\n name: 'My cNFT',\n uri: nftMetadataUri, // Either use `nftMetadataUri` or a previously uploaded uri.\n sellerFeeBasisPoints: 500, // 5%\n collection: { key: collectionSigner.publicKey, verified: false },\n creators: [\n {\n address: umi.identity.publicKey,\n verified: true,\n share: 100,\n },\n ],\n },\n}).sendAndConfirm(umi, { send: { commitment: 'finalized' } })\nFetch the Newly Minted cNFT//\n// ** Fetching Asset **\n//\n\n//\n// Here we find the asset ID of the compressed NFT using the leaf index of the mint transaction\n// and then log the asset information.\n//\n\nconsole.log('Finding Asset ID...')\nconst leaf = await parseLeafFromMintV1Transaction(umi, signature)\nconst assetId = findLeafAssetIdPda(umi, {\n merkleTree: merkleTree.publicKey,\n leafIndex: leaf.nonce,\n})\n\nconsole.log('Compressed NFT Asset ID:', assetId.toString())\n\n// Fetch the asset using umi rpc with DAS.\nconst asset = await umi.rpc.getAsset(assetId[0])\n\nconsole.log({ asset })\nMinting 1,000,000 cNFTsNow that we understand how to make a Merkle Tree that holds 1,000,000 cNFTs and can mint an NFT to that tree you can now take all the previous steps and start adjusting the code to make some loops to upload the needed data to Arweave and then mint the cNFT to a tree.As the Merkle Tree has space for 1,000,000 cNFts you can freely loop and fill up the tree as desired for your projects needs.Below is an example of minting cNFTs to an array of addresses that increment the data stored on the cNFT based on the loop index. This is a rough simple example/concept and would be need to be modified for production use. const addresses = [\n \"11111111111111111111111111111111\",\n \"22222222222222222222222222222222\",\n \"33333333333333333333333333333333\",\n ...\n ];\n\n let index = 0;\n\n for await (const address in addresses) {\n const newOwner = publicKey(address);\n\n console.log(\"Minting Compressed NFT to Merkle Tree...\");\n\n const { signature } = await mintV1(umi, {\n leafOwner: newOwner,\n merkleTree: merkleTree.publicKey,\n metadata: {\n name: `My Compressed NFT #${index}`,\n uri: `https://example.com/${index}.json`, //either use metadataUri or the uri of the uploaded metadata file\n sellerFeeBasisPoints: 500, // 5%\n collection: { key: collectionSigner.publicKey, verified: false },\n creators: [\n { address: umi.identity.publicKey, verified: true, share: 100 },\n ],\n },\n }).sendAndConfirm(umi, { send: { commitment: \"finalized\" } });\n\n index++;\n }\nFull Code Exampleimport {\n createTree,\n findLeafAssetIdPda,\n mintToCollectionV1,\n mplBubblegum,\n parseLeafFromMintV1Transaction\n} from '@metaplex-foundation/mpl-bubblegum'\nimport {\n createNft,\n mplTokenMetadata,\n} from '@metaplex-foundation/mpl-token-metadata'\nimport {\n createGenericFile,\n generateSigner,\n keypairIdentity,\n percentAmount,\n publicKey\n} from '@metaplex-foundation/umi'\nimport { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\nimport { irysUploader } from '@metaplex-foundation/umi-uploader-irys'\nimport fs from 'fs'\n\n// Create the wrapper function\nconst createCnft = async () => {\n //\n // ** Set Up Umi **\n //\n\n // In this instance we are using a locally stored wallet. This can be replaced\n // with the code from 'generating a new wallet' if need be but make sure you\n // airdrop/send at least 7.7 SOL to the new wallet.\n\n const umi = createUmi('https://api.devnet.solana.com')\n .use(mplBubblegum())\n .use(mplTokenMetadata())\n .use(\n irysUploader({\n // mainnet address: \"https://node1.irys.xyz\"\n // devnet address: \"https://devnet.irys.xyz\"\n address: 'https://devnet.irys.xyz',\n })\n )\n\n // Generate a new keypair signer.\n const signer = generateSigner(umi)\n\n // You will need to us fs and navigate the filesystem to\n // load the wallet you wish to use via relative pathing.\n const walletFile = fs.readFileSync('./keypair.json')\n\n // Convert your walletFile onto a keypair.\n let keypair = umi.eddsa.createKeypairFromSecretKey(new Uint8Array(walletFile))\n\n // Load the keypair into umi.\n umi.use(keypairIdentity(keypair))\n\n //\n // ** Create a Merkle Tree **\n //\n\n const merkleTree = generateSigner(umi)\n\n console.log(\n 'Merkle Tree Public Key:',\n merkleTree.publicKey,\n '\\nStore this address as you will need it later.'\n )\n\n // Create a tree with the following parameters.\n // This tree will cost approximately 7.7 SOL to create with a maximum\n // capacity of 1,000,000 leaves/nfts. You may have to airdrop some SOL\n // to the umi identity account before running this script.\n\n console.log('Creating Merkle Tree...')\n const createTreeTx = await createTree(umi, {\n merkleTree,\n maxDepth: 20,\n maxBufferSize: 64,\n canopyDepth: 14,\n })\n\n await createTreeTx.sendAndConfirm(umi)\n\n //\n // ** Create Token Metadata Collection NFT (Optional) **\n //\n\n //\n // If you wish to mint a NFT to a collection you must first create a collection NFT.\n // This step is optional and you can skip it if you do not wish to mint a NFT to a collection\n // or have previously created a collection NFT.\n //\n\n const collectionSigner = generateSigner(umi)\n\n // Path to image file\n const collectionImageFile = fs.readFileSync('./collection.png')\n\n const genericCollectionImageFile = createGenericFile(\n collectionImageFile,\n 'collection.png'\n )\n\n const collectionImageUri = await umi.uploader.upload([\n genericCollectionImageFile,\n ])\n\n const collectionMetadata = {\n name: 'My cNFT Collection',\n image: collectionImageUri[0],\n externalUrl: 'https://www.example.com',\n properties: {\n files: [\n {\n uri: collectionImageUri[0],\n type: 'image/png',\n },\n ],\n },\n }\n\n console.log('Uploading Collection Metadata...')\n const collectionMetadataUri = await umi.uploader.uploadJson(\n collectionMetadata\n )\n\n console.log('Creating Collection NFT...')\n await createNft(umi, {\n mint: collectionSigner,\n name: 'My cNFT Collection',\n uri: 'https://www.example.com/collection.json',\n isCollection: true,\n sellerFeeBasisPoints: percentAmount(0),\n }).sendAndConfirm(umi)\n\n //\n // ** Upload Image and Metadata used for the NFT (Optional) **\n //\n\n // If you already have an image and metadata file uploaded, you can skip this step\n // and use the uri of the uploaded files in the mintV1 call.\n\n // Path to image file\n const nftImageFile = fs.readFileSync('./nft.png')\n\n const genericNftImageFile = createGenericFile(nftImageFile, 'nft.png')\n\n const nftImageUri = await umi.uploader.upload([genericNftImageFile])\n\n const nftMetadata = {\n name: 'My cNFT',\n image: nftImageUri[0],\n externalUrl: 'https://www.example.com',\n attributes: [\n {\n trait_type: 'trait1',\n value: 'value1',\n },\n {\n trait_type: 'trait2',\n value: 'value2',\n },\n ],\n properties: {\n files: [\n {\n uri: nftImageUri[0],\n type: 'image/png',\n },\n ],\n },\n }\n\n console.log('Uploading cNFT metadata...')\n const nftMetadataUri = await umi.uploader.uploadJson(nftMetadata)\n\n //\n // ** Mint a Compressed NFT to the Merkle Tree **\n //\n\n //\n // If you do not wish to mint a NFT to a collection you can set the collection\n // field to `none()`.\n //\n\n // The owner of the cNFT being minted.\n const newOwner = publicKey('111111111111111111111111111111')\n\n console.log('Minting Compressed NFT to Merkle Tree...')\n\nconst { signature } = await mintToCollectionV1(umi, {\n leafOwner: newOwner,\n merkleTree: merkleTree.publicKey,\n collectionMint: collectionSigner.publicKey,\n metadata: {\n name: 'My cNFT',\n uri: nftMetadataUri, // Either use `nftMetadataUri` or a previously uploaded uri.\n sellerFeeBasisPoints: 500, // 5%\n collection: { key: collectionSigner.publicKey, verified: false },\n creators: [\n {\n address: umi.identity.publicKey,\n verified: true,\n share: 100,\n },\n ],\n },\n}).sendAndConfirm(umi, { send: { commitment: 'finalized' } })\n\n //\n // ** Fetching Asset **\n //\n\n //\n // Here we find the asset ID of the compressed NFT using the leaf index of the mint transaction\n // and then log the asset information.\n //\n\n console.log('Finding Asset ID...')\n const leaf = await parseLeafFromMintV1Transaction(umi, signature)\n const assetId = findLeafAssetIdPda(umi, {\n merkleTree: merkleTree.publicKey,\n leafIndex: leaf.nonce,\n })\n\n console.log('Compressed NFT Asset ID:', assetId.toString())\n\n // Fetch the asset using umi rpc with DAS.\n const asset = await umi.rpc.getAsset(assetId[0])\n\n console.log({ asset })\n};\n\n// run the wrapper function\ncreateCnft();","tokens":4554,"squid":"dotcat","role":"Tooling Spider","at":1791345746279,"hash":"a36d38b7b3d8c3d5acfef0aa7b1faa9c3ff66e44"}
{"url":"https://developers.jup.ag/docs/ultra/index","domain":"developers.jup.ag","title":"Ultra Swap API Overview - Jupiter Developers","text":"Ultra Swap API is no longer actively maintained and has been superseded by Swap V2.\nUltra Swap is the most advanced yet developer-friendly solution for building trading applications on Solana. Ultra Swap is designed to be the only solution you’ll ever need for creating exceptional trading experiences.\n​Quick Launch\nQuick launch options: Ultra Swap API guide | Plugin (drop-in UI)\n\n​Features\nRead our latest blog on Ultra V3.\nKey features at a glance: Juno liquidity engine (multi-source aggregation with self-learning), best executed price (predictive execution + slippage-aware routing), sub-second transaction landing via Jupiter Beam, Real-Time Slippage Estimator (RTSE), automatic gasless support, and sub-2s API latency.\nJuno Liquidity EngineUltra Swap utilizes the latest Juno Liquidity Engine which aggregates across multiple liquidity sources, including Jupiter’s proprietary routing engines: improved versions of Metis and JupiterZ, and third-party liquidity sources, for the best possible price.It also includes self-learning capabilities (to detect and sideline low-quality liquidity sources) which creates a competitive environment for all liquidity sources to continously optimize their performance and price.Best Executed PriceUltra Swap guarantees the best executed price through several key innovations:\nPredictive Execution: Ultra simulates and compares executed prices (not just quoted prices) before actually sending a transaction, dynamically selecting the route with the least slippage for real user outcomes.\nUltra Signaling: Ultra provides signaling to Proprietary AMMs to help them distinguish Ultra user flow, incentivizing them to quote tighter spreads and better prices.\nSlippage-Aware Routing: Automatically prioritizes and selects routes that minimize realized slippage, protecting users from misleading “best quotes” that deliver poor executed results.\nFor detailed examples and results, see our Ultra V3 blog post.Sub-second Transaction Landing & MEV ProtectionUltra is now using our new in-house transaction-landing engine, Jupiter Beam, which allows us to send transactions via our own infrastructure: designed to make every trade faster, more private, and more precise.\nLeverage our own validator stake and dedicated R&D efforts.\nComplete transaction privacy until on-chain execution.\nEliminate the risk of artificial delays and front-running, ensuring faster and more secure execution for our users.\nResults:\nLanding Latency: Improved by 50-66% compared to our previous approach that relied on multiple providers\n\nLands in 0–1 block (~50–400ms)\nCompared to the 1–3 blocks (~400ms–1.2s) previously.\n\nMEV Protection: Routing transactions through our own infrastructure provides:\n\nComplete transaction privacy until on-chain execution.\nReduce frontrunning exposure - transactions are invisible to public mempool scanners.\nReduce risk of sandwich attack vectors - see our blog post on Ultra’s swap volume to value extracted ratio.\n\nReal Time Slippage EstimatorBuilding on top of our previous versions of slippage estimation/optimization engines, we have developed a new Real Time Slippage Estimator (RTSE), that is able to intelligently estimate the best possible slippage to use at the time of execution, balancing between trade success and price protection.RTSE uses a variety of heuristics, algorithms and monitoring to ensure the best user experience:\nHeuristics: Token categories, historical and real-time slippage data, and more.\n\nUses token categories to intelligently estimate slippage for different token types.\nAutomatic prioritization of slippage-protected routes over purely price-optimized routes.\nIncreased volatility sensitivity for tokens with high historical volatility patterns.\n\nAlgorithms: Exponential Moving Average (EMA) on slippage data, and more.\nMonitoring: Real-time monitoring of failure rates to ensure reactiveness to increase slippage when necessary.\nGaslessUltra Swap provides different gasless mechanisms for different scenarios.\nGasless via Jupiter Z (RFQ): All swaps routed via Jupiter Z are gasless, as the market maker is the fee payer for the transaction.\nGasless via Gasless Support: Depending on the tokens and trade sizes of your swap, Ultra Swap will automatically determine if it can provide gasless support to your swap by helping you pay for the transaction fee of your swap - you can identify this via the secondary signer in the transaction.\nAPI Latency95% of all swaps are executed under 2 seconds via our proprietary transaction sending engine.EndpointDescriptionLatency (P50 Average)/orderAggregating across multiple liquidity sources and selecting the best price.300ms/executeBroadcasting the transaction to the network and polling for the status and result of the transaction.RoundtripMetis: 700ms; JupiterZ: 2s/holdingsRetrieving the user’s balances.70ms/shieldEnhanced token security feature to provide critical token information.150ms/searchSearching for a token by its symbol, name or mint address.15ms\nThe following table summarizes Ultra’s core capabilities:\nFeatureDescriptionBest Trading ExperienceUltra Swap is the best trading experience in crypto, it handles all the complexities and headaches such as slippage protection, transaction landing and more.RPC-lessYou do not need to maintain your own RPC for blockchain actions such as send transactions, get token information, or get user balances - we handle everything for you.API CoverageUltra Swap covers all the necessary features for you to build your application, including the features mentioned below and useful information such as user wallet balances, token information, and more.Integrator FeeUltra Swap allows you to add custom integrator fees to your transactions, on top of Jupiter’s fees. Refer to the Add Fees To Ultra Swap guide for more information.Developer SupportGet help from our developer support in Discord.World Class SupportIf you ever face any issues or need help when using Ultra Swap, our support team is here to assist you 24/7. Read more about Ultra Swap Customer Support.\nUse Ultra if you want managed execution without infrastructure overhead. Use Metis if you need CPI, custom instructions, or full transaction control.\n​Ultra vs Metis Matrix\nQuestionUltraMetisCan I use this for standard swap UX?✅ Yes—recommended✅ Yes—requires infrastructureCan I use this for CPI?❌ No✅ YesCan I add custom instructions?❌ No✅ YesDo I need my own RPC?❌ No✅ Yes—requiredIs gasless supported?✅ Yes—automatic⚠️ Build yourselfWho handles user support?JupiterYouDo I get automatic optimizations?✅ Yes—continuous❌ No—build yourselfWhat’s the integration timeline?HoursMonthsInfrastructure maintenance?❌ None—managed✅ Full—self-managed\nChoose Ultra API if you:\n\nWant to focus on product differentiation rather than infrastructure\nValue battle-tested execution quality out of the box\nNeed gasless swaps without building infrastructure\nPrefer operational/technical and customer support\nWant to iterate quickly on user experience\nDon’t need CPI or custom transaction composition\n\nChoose Metis API if you:\n\nNeed CPI (Cross Program Invocation) capabilities\nRequire custom instructions in transactions\nWant full control over fee monetization\nHave existing RPC/execution infrastructure to leverage\nAre building execution infrastructure as competitive advantage\nNeed transaction-level flexibility an opinionated engine can’t provide\n\nThe following table provides a comprehensive comparison between Ultra Swap API and Metis Swap API to help you choose the right solution for your needs:\nCategoryAspectUltra APIMetis APIArchitectureDesign PhilosophyEnd-to-end execution engine with integrated componentsRouting primitive requiring custom execution infrastructureConfiguration PhilosophyOptimized defaults refined by millions of swapsComplete flexibility to build your own strategiesPrimary Use CaseTeams wanting immediate, optimized swap executionTeams needing CPI, custom instructions, or infrastructure controlComplexityOpinionated, streamlined integrationFlexible, requires extensive custom developmentRoutingRouting EngineMeta-aggregator combining:• Metis (onchain routing with self-learning)• DFlow• OKX• JupiterZ (RFQ with 20+ market makers)Single, proven routing engine for on-chain liquidityRFQ AccessBuilt-in JupiterZ RFQ with 20+ market makersNot supportedLiquidity SourcesAggregates across multiple DEXes, PropAMMs, RFQ’s MMsDirect access to Solana’s on-chain liquidityMetis Features• Ultra Signaling for tighter PropAMM quotes• Predictive Execution• Just-In-Time Market Revival• Self-learning route optimization• And moreNot applicableContinuous ImprovementAutomatic improvements deployed from millions of swapsStable routing engine, you build improvementsExecutionTransaction FlowGet order → Sign → Submit to execute endpointGet quote → Build transaction → Send via your infrastructureTransaction SendingJupiter Beam proprietary engine with network of transaction sendersYou build and maintain your own RPC pipelineLanding Performance50-400ms average via Jupiter BeamVaries based on your priority fee optimizationTransaction PollingBuilt-in status polling with intelligent error handlingYou implement polling logic and parse on-chain errorsEnd-to-End Execution LatencyP95 < 1000ms (400-600ms average), includes pollingEntirely dependent on your infrastructure qualityQuote LatencyP95 < 900ms (100-200ms average)Higher due to simulations and optimizationsP95 < 500ms (100-200ms average)Raw routing dataRPC RequirementsNone—Jupiter provisions all infrastructureYou provision and pay for RPC accessMEV ProtectionIndustry-lowest MEV attack rate (sandwiched.me)Dependent on your infrastructure choicesConfigurationSlippage OptimizationRTSE (Real-Time Slippage Estimator) applying heuristics and real-time adjustments using token categories, historical and real-time dataManual configuration based on your strategyPriority Fee ManagementAutomatic estimation and optimization using quality RPC and network dataYou build custom fee estimation logicManual ModeAvailable for user-facing trading experiencesNot recommended as default integrationFull manual control alwaysGaslessUltra Gasless Support (Metis)Automatic when user has trade value but insufficient SOLJupiter pays: tx fee, priority fee, token account rentNot supportedJupiterZ GaslessMarket makers cover tx and priority feesJupiter’s gas wallet pays the rent to create the taker’s output token account if neededNot applicableIntegrator as PayerSupported (Metis quotes only, all gas covered)Supported with full control over implementationCustomizationTransaction CustomizationOpinionated—no custom instructions, no CPI, no instruction modificationFull flexibility—add instructions, use for CPI, compose as neededOperationsCustomer SupportJupiter provides direct support to your users via official channelsMinimal technical support—you handle user-facing supportRate LimitsDynamic based on executed volumeBase quota can be increased on requestFixed tiers via Portal, no overagesIncident ResponseP0 direct contact available, monitored business chatsstatus.jup.ag updates, monitored chats by severityMonitoring & ObservabilitySame infrastructure as jup.ag—24/7 monitoring, end-to-end loggingSelf-service status page—you log and monitor your own infrastructureInfrastructure MaintenanceFully managed by JupiterYou build and maintain all infrastructureFeesFees Involved5-10 bps swap feePortal fees to increase rate limitsBest ForIdeal Use Cases• Standard swap UX• Quick time to market• Product differentiation focus• Inherited optimization• Operational support needs• CPI integration• Custom instructions• Novel transaction compositions• Infrastructure as competitive advantage• Full execution controlTeam ProfileTeams focusing on product, not infrastructureTeams with infrastructure expertise and resourcesStrategic Trade-offCustomization flexibility → Immediate performance + reduced overheadImmediate optimization → Freedom to build proprietary infrastructureTechnicalShared InfrastructureSame infrastructure powering jup.ag core productIndependent integrationAutomatic ImprovementsContinuous optimizations deployed automaticallyStable API, you build improvementsData SourcesLearns from millions of swaps across jup.ag and API integrationsYou collect and analyze your own dataIntegration ComplexityGet order → Sign → Execute (3 steps)Get quote → Build → Send → Poll (multiple steps + infrastructure)Infrastructure InvestmentZero—fully managed3-6 months development + ongoing DevOpsWas this page helpful?","tokens":3127,"squid":"spider-02","role":"Liquidity Spider","at":1791345751583,"hash":"ce0215053e454117f7ad5b1044d464c871923952"}
{"url":"https://consensysdiligence.github.io/smart-contract-best-practices/development-recommendations/general/force-feeding/","domain":"consensysdiligence.github.io","title":"Force-feeding Ether - Ethereum Smart Contract Best Practices","text":"Force-feeding Ether\n\nTip\nFor comprehensive insights into secure development practices, consider visiting the Development Recommendations section of the Smart Contract Security Field Guide. This resource provides in-depth articles to guide you in developing robust and secure smart contracts.\n\nBeware of coding an invariant that strictly checks the balance of a contract.\nAn attacker can forcibly send ether to any account and this cannot be prevented (not even with a\nfallback function that does a revert()).\nThe attacker can do this by creating a contract, funding it with 1 wei, and invoking\nselfdestruct(victimAddress). No code is invoked in victimAddress, so it cannot be prevented.\nThis is also true for block reward which is sent to the address of the miner, which can be any\narbitrary address.\nAlso, since contract addresses can be precomputed, ether can be sent to an address before the\ncontract is deployed.\nSee SWC-132","tokens":232,"squid":"spider-06","role":"Security Spider","at":1791345767539,"hash":"a9c6ea5ab223707e039d6fb2a631fc11a0207990"}
{"url":"https://developers.jup.ag/docs/ultra/get-started","domain":"developers.jup.ag","title":"Ultra Swap API Quick Start - Jupiter Developers","text":"Ultra Swap API is no longer actively maintained and has been superseded by Swap V2.\nUltra Swap uses a two-step flow: first call GET /ultra/v1/order to receive a base64-encoded unsigned transaction, then sign it and submit via POST /ultra/v1/execute. This page lists all Ultra endpoints and guides.\n​Overview\nStepEndpointDescription1Get OrderRequest for a quote and swap transaction.2Execute OrderSign and execute the swap transaction.-Search TokenSearch for a token by its symbol, name or mint address.-Get HoldingsRequest for token balances of an account.-Get ShieldEnhanced security feature to provide critical token information contributing to better informed trading decisions.-API ReferenceReference for the Ultra Swap API endpoints.\n​Guides\nGuideDescriptionGasless SupportImportant notes of gasless mechanisms.FeesBreakdown of fees involved.Manual ModeControl Ultra Swap API parameters like slippage or priority fee settings.Add Fees to Ultra SwapAdd custom integrator fees to your Ultra Swap transaction.Add Integrator PayerAdd integrator payer to pay for networks fees and rent on behalf of your users.Plugin IntegrationWalkthrough on how to integrate Ultra Swap API with Jupiter Plugin.\n​FAQ\nFrequently asked questions: Integrator fees are 5–10 bps (you keep 80%), Ultra transactions cannot be modified, and rate limits scale dynamically with swap volume.\nCan I add custom integrator fees to Ultra Swap API?\nIntegrator without custom fees: Do note that when your users swap using Ultra Swap, we take 5 to 10 bps of the swap amount as a fee.\nIntegrator with custom fees: If you are an integrator, you can add custom integrator fees via Ultra Swap API and Jupiter will take 20% of the integrator fees. Please refer to the Add Fees To Ultra Swap guide for more information.\nCan I modify Ultra Swap transactions?\nNo, you cannot modify Ultra Swap transactions.\nUltra Swap is intended to use as is, without any modifications.\nWhat is the rate limit for Ultra Swap API?Dynamic rate limits have been replaced by fixed rate limits under the new Developer Platform. See Rate Limits and the Migration Guide for details.\nGenerate an API key via Developer Platform\nRate limits are fixed per tier (Free: 1 RPS, Developer: 10 RPS, Launch: 50 RPS, Pro: 150 RPS)\nSee Plans and Pricing for full details\nWas this page helpful?","tokens":579,"squid":"spider-02","role":"Liquidity Spider","at":1791345773617,"hash":"cc3b1b751ed2d80da6154227dd9c2408ae130d2e"}
{"url":"https://consensysdiligence.github.io/smart-contract-best-practices/development-recommendations/solidity-specific/abstract-vs-interfaces/","domain":"consensysdiligence.github.io","title":"Abstract vs Interfaces - Ethereum Smart Contract Best Practices","text":"Abstract vs Interfaces\n\nTip\nFor comprehensive insights into secure development practices, consider visiting the Development Recommendations section of the Smart Contract Security Field Guide. This resource provides in-depth articles to guide you in developing robust and secure smart contracts.\n\nBe aware of the tradeoffs between abstract contracts and interfaces.\nBoth interfaces and abstract contracts provide one with a customizable and re-usable approach for\nsmart contracts. Interfaces, which were introduced in Solidity 0.4.11, are similar to abstract\ncontracts but cannot have any functions implemented. Interfaces also have limitations such as not\nbeing able to access storage or inherit from other interfaces which generally makes abstract\ncontracts more practical. Although, interfaces are certainly useful for designing contracts prior\nto implementation. Additionally, it is important to keep in mind that if a contract inherits from\nan abstract contract it must implement all non-implemented functions via overriding or it will be\nabstract as well.","tokens":265,"squid":"spider-06","role":"Security Spider","at":1791345776775,"hash":"785b6d926a4bf1a5faea68452544f86a77ca1cb3"}
{"url":"https://developers.jup.ag/docs/ultra/get-shield","domain":"developers.jup.ag","title":"Get Shield (Ultra) - Jupiter Developers","text":"Ultra Swap API is no longer actively maintained and has been superseded by Swap V2.\nThe /ultra/v1/shield endpoint returns security warnings for one or more token mint addresses. Warnings include freeze authority, mint authority, unverified status, low organic activity, and new listing alerts. Use this to inform users before they trade.\nThis is useful when integrating with Jupiter Ultra Swap or any other APIs, allowing you or your user to be informed of any potential malicious mints before conducting your transaction.\nCheck shield warnings for multiple mints:\nconst shieldResponse = await (\n await fetch(`https://api.jup.ag/ultra/v1/shield?mints=So11111111111111111111111111111111111111112,EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v,someTokenAddressForEducationalPurposes`,\n {\n headers: {\n 'x-api-key': 'your-api-key',\n },\n }\n )\n).json();\n\n​Shield Response\nThe shield response will return a list of objects, containing the token information and warnings of the mints passed in.\nDo note that this is subject to changes, and we will be adding more warnings and improving the accuracy of the warnings over time.\nFor the full list of potential warnings, refer to the Shield API Reference.\nSuccessful example response:\n{\n \"warnings\": {\n \"someTokenAddressForEducationalPurposes\": [\n {\n \"type\": \"NOT_VERIFIED\",\n \"message\": \"This token is not verified, make sure the mint address is correct before trading\",\n \"severity\": \"info\"\n },\n {\n \"type\": \"LOW_ORGANIC_ACTIVITY\",\n \"message\": \"This token has low organic activity\",\n \"severity\": \"info\"\n },\n {\n \"type\": \"NEW_LISTING\",\n \"message\": \"This token is newly listed\",\n \"severity\": \"info\"\n }\n ],\n \"EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v\": [\n {\n \"type\": \"HAS_FREEZE_AUTHORITY\",\n \"message\": \"The authority's owner has the ability to freeze your token account, preventing you from further trading\",\n \"severity\": \"warning\"\n },\n {\n \"type\": \"HAS_MINT_AUTHORITY\",\n \"message\": \"The authority's owner has the ability to mint more tokens\",\n \"severity\": \"info\"\n }\n ],\n \"So11111111111111111111111111111111111111112\": []\n }\n}\nWas this page helpful?","tokens":521,"squid":"spider-02","role":"Liquidity Spider","at":1791345783518,"hash":"ca5202668a5ab7f8257846acfaa80ab6695e690b"}
{"url":"https://www.metaplex.com/docs/smart-contracts/bubblegum","domain":"metaplex.com","title":"Overview | Bubblegum","text":"Bubblegum v1 is a legacy program. It remains supported, but is not recommended for new projects. Use Bubblegum V2 instead.New Bubblegum versionWe recommend using Bubblegum v2 to allow more flexibility and features.Please note that certain Bubblegum instructions will require protocol fees. Please review the Protocol Fees page for up-to-date information.Bubblegum is the Metaplex Protocol program for creating and interacting with compressed NFTs (cNFTs) on Solana. Compressed NFTs make it possible to scale the creation of NFTs to new orders of magnitude by rethinking the way we store data onchain. Getting StartedFind the language or library of your choice and get started with compressed NFTs.API referenceLooking for something specific? Have a peak at our API References and find your answer.IntroductionAs NFTs have flourished on the Solana blockchain, there's been an increasing need for NFTs to be as ubiquitous as any digital asset on the Internet: every single item in your game's inventory, proof-of-engagement in your favorite consumer app, or even a profile for every human on the planet.So far, though, these types of products have been held back by the cost of rent for NFTs on Solana, which is relatively cheap but scales linearly. Compression for NFTs drastically reduces the cost of onchain storage of NFTs to enable creators to be as expressive with the technology as they wish.Launching a cNFT project on Solana using Merkle trees can be incredibly cost-effective, with costs starting as low as:Number of cNFTsStorage CostTransaction CostTotal CostCost per cNFT10,0000.22220.050.27220.000027222100,0000.26560.50.76560.0000076561,000,0000.312255.31220.00000531210,000,0000.42365050.42360.000005042100,000,0007.2205500507.22050.0000050721,000,000,0007.22055,0005007.22050.000005007These compressed NFTs can be transferred, delegated, and even decompressed into regular NFTs for interoperability with existing smart contracts.Merkle Trees, leaves and proofsCompressed NFTs only exist in the context of a Merkle Tree. We explain in a dedicated advanced guide what Merkle Trees are but, for the sake of this overview, you can think of a Merkle Tree as a collection of hashes that we call Leaves. Each Leaf is obtained by hashing the data of the compressed NFT.For each Leaf in the Merkle Tree, one can provide a list of hashes — called a Proof — that enables anyone to verify that the given Leaf is part of that tree. Whenever a compressed NFT is updated or transferred, its associated Leaf will change and so will its Proof.Root NodeHashNode 1HashNode 2Node 3Node 4HashNode 5Node 6Leaf 1Leaf 2Leaf 3Leaf 4Leaf 5Leaf 6Leaf 7Leaf 8NFT DataLeaf 4Node 3Node 2ProofReact FlowPress enter or space to select a node.You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel. Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.As such, Merkle Trees act as an onchain structure that allows anyone to verify a given compressed NFT exist. They do this without storing any NFT data which makes them so scalable.Which brings us to an important question: where is the NFT data stored?Metaplex DAS APIWhen we mint a new compressed NFT, its data is hashed and added as a new Leaf in a Merkle Tree. But there's more. Additionally, the entire NFT data is stored in the transaction that created the compressed NFT. Similarly, when a compressed NFT is updated, its updated data is, once again, saved on the transaction as a changelog. So, whilst there aren't any accounts keeping track of that data, one can look at all previous transactions in the ledger and find that information.Transaction 1Transaction 2Transaction 3Transaction 4Transaction 5...Initial NFT DataNFT Data ChangelogNFT Data ChangelogReact FlowPress enter or space to select a node.You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel. Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.Crawling through millions of transactions every time just to fetch the data of one NFT is admittedly not the best user experience. Therefore, compressed NFTs rely on some RPCs to index that information in real time to abstract this away from the end-user. We call the resulting RPC API, which enables fetching compressed NFTs, the Metaplex DAS API.Note that not all RPCs support the DAS API. As such, you may be interested in the \"Metaplex DAS API RPCs\" page to select an appropriate RPC when using compressed NFTs in your application.We talk about this in more detail in our advanced \"Storing and indexing NFT data\" guide.FeaturesEven though NFT data does not live inside accounts, it is still possible to execute a variety of operations on compressed NFTs. This is possible by requesting the current NFT data and ensuring its hashed Leaf is valid on the Merkle Tree. As such, the following operations can be performed on compressed NFTs:Mint a cNFT with or without an associated collection.Transfer a cNFT.Update the data of a cNFT.Burn a cNFT.Decompress a cNFT into a regular NFT. Note that this enables interoperability with existing smart contracts but creates onchain accounts with rent fees.Delegate a cNFT.Verify and unverify a cNFT collection.Verify and unverify the creators of a cNFT.Next stepsNow that we know how compressed NFTs work at a high level, we recommend checking out our Getting Started page which enumerates the various languages/frameworks that one can use to interact with compressed NFTs. Afterward, the various feature pages can be used to learn more about the specific operations that can be performed on cNFTs. Finally, advanced guides are also available to deepen your knowledge of cNFTs and Merkle Trees.","tokens":1445,"squid":"dotcat","role":"Tooling Spider","at":1791345790632,"hash":"6b2a36b40b5d65691b1e88a3dd9478e515ef67d2"}
{"url":"https://developers.jup.ag/docs/tool-kits/referral-program","domain":"developers.jup.ag","title":"Referral Program - Jupiter Developers","text":"The Referral Program is an open-source on-chain program that lets developers earn fees through Jupiter API integrations. It supports Swap API, Trigger API, and Plugin. Any Solana program can also integrate the Referral Program to share revenue with its own integrators.\nREFERRAL PROGRAM SOURCE CODEOpen Source Repository: To understand and make use of the referral program better.\n​Jupiter API Integrators\nThe Jupiter Programs use the Referral Program to allow developers to earn fees when integrating with Jupiter. Below are some resources to help you quickly get started. There are a different ways to setup such as via the Jupiter Referral Dashboard or using the provided scripts.\n\nJupiter Referral Dashboard: To view and manage your referral accounts used with Jupiter APIs.\nAdd Fees to Swap API: To add fees to your Swap API integration.\nAdd Fees to Jupiter Plugin: To add fees to your Plugin integration.\n\n​Other Program Integrators\n​Project Usage\nIf you have a project/product that runs a program on the Solana blockchain, you can integrate the Referral Program to allow/share revenue with the integrators of your program.\nSimilar to how Jupiter Programs uses the Referral Program to help developers earn fees and/or share the revenue with Jupiter. For example, Jupiter Ultra uses the Jupiter Swap program which relies on the Referral Program.\n\nCreate a Project by calling initialize_project with your chosen base key and a project name (base key refers to a key identifier of your project).\nSet a default_share_bps to share the fees with your referrers (or integrators).\nAn example of a Project account: Jupiter Ultra Project\n\n​Referrer Usage\nIf you are a referrer such as a developer or integrator of a project that runs a program on the Solana blockchain, you can create the necessary accounts via the Referral Program to earn fees.\n\nThe program must be integrated with the Referral Program.\nCreate a Referral account by calling initialize_referral_account with the correct Project account, the Referral account, and your own Partner account (Partner account is the admin of this referral account).\nCreate the necessary Referral token accounts for the Referral account to receive fees in.\nWas this page helpful?","tokens":555,"squid":"spider-02","role":"Liquidity Spider","at":1791345803334,"hash":"84a08c7cd689b1ee452cf033e846383241e401c7"}
{"url":"https://developers.jup.ag/docs/tool-kits/wallet-kit","domain":"developers.jup.ag","title":"Integrate Wallet Kit - Jupiter Developers","text":"The Jupiter Wallet Kit is an open-source, Swiss Army Knife wallet adapter designed to streamline your development on Solana by eliminating redundancies and providing wallet adapter building blocks in a simple, plug-and-play package. This allows developers to focus on what matters most: building innovative features for your users.\n​Overview\nJupiter Wallet Kit Features\nCreating a wallet notification system.\nManaging wallet states (connected, disconnected, etc).\nImplementing a mobile-friendly wallet connector.\nSupport for 20+ wallet adapters via a unified interface.\nSupport for all wallets built with Solana’s Wallet Standard.\nSupport for Jupiter Wallet Extension.\nSupport for Jupiter Mobile Adapter QR code login.\n\n​Technical Features\nFeatureDescriptionCompact BundleMain ESM bundle is a lightweight 94KB (20KB gzipped).Built-in SupportComes with Wallet Standard and Mobile Wallet Adapter support.Abstracted Wallet AdapterUse the Bring Your Own Wallet (BYOW) approach to select custom and legacy wallets.Mobile ResponsiveDesigned to be mobile-first.Smart Notification SystemIntegrates seamlessly with your existing notification system or can be used independently.InternationalizationSupports multiple languages including English, Chinese, Vietnamese, French, Japanese, Bahasa Indonesia, and Russian.Theming OptionsChoose from light, dark, and Jupiter modes, with more customization options coming soon.New User OnboardingSimplifies the onboarding process for new users.Was this page helpful?","tokens":374,"squid":"spider-02","role":"Liquidity Spider","at":1791345814533,"hash":"b733b9e2d613a12a9a2828dd58f55ee635eef92d"}
{"url":"https://developer.arbitrum.io/launch-arbitrum-chain/integrations/bridge-ui","domain":"developer.arbitrum.io","title":"How to add your Arbitrum chain to Arbitrum's bridge.","text":"Ecosystem supportHow to add your Arbitrum chain to Arbitrum's bridge.Learn how to add your Arbitrum chain to Arbitrum's bridge.Request an updateThis how-to will walk you through the process of adding your Arbitrum chain to the Arbitrum bridge. There's one section for mainnet Arbitrum chains, and another for local testnet Arbitrum chains. You can access either section using the links on the right column.\nRequest adding a mainnet Arbitrum chain to the Arbitrum bridge\nMainnet Arbitrum chains can be added to the Arbitrum Bridge by filling out this form.\nOnce receiving your request, our team will review and apply internal criteria to include your chain in the bridge. Here are some of the criteria that a chain must follow to be added to the bridge:\n\nThe use case must fall within existing legal and marketing guidelines\nThe core Rollup / token bridge contracts must not have been modified, except the cases where modifications have been done with a certified partnership and communicated to Offchain Labs\nThe infrastructure and core contracts are hosted by one of our partnered RaaS teams\n\nAdd a local testnet Arbitrum chain to the Arbitrum bridge\nTo add a testnet Arbitrum chain to the Arbitrum bridge you can submit a request at the same GitHub link and indicate that it is a testnet (https://github.com/OffchainLabs/arbitrum-token-bridge/issues/new/choose).\nCongratulations! Your chain should now appear in both the network dropdown in the top navigation pane, and as an option in the bridging UI directly.How is this guide?KMS and signing servicesLearn how to integrate external signing—including AWS KMS—for your chain's batch poster.How to adopt the bridged USDC standard on your Arbitrum chainHow to implement Circle bridged USDC standard on Arbitrum chain","tokens":442,"squid":"spider-01","role":"Chain Spider","at":1791345820235,"hash":"beb7498801b795c266347047c10bce714448ea81"}
{"url":"https://www.metaplex.com/docs/smart-contracts/mpl-distro/sdk/javascript","domain":"metaplex.com","title":"MPL-Distro JavaScript SDK Reference","text":"The @metaplex-foundation/mpl-distro package provides Umi instruction builders, account serializers, PDA helpers, and compatible Merkle tree utilities. SummaryThe MPL-Distro JavaScript SDK is the supported TypeScript interface for creating, funding, claiming, updating, and inspecting distributions.Register mplDistro() on a Umi client before building instructions.Generate roots and proofs with prepareDistribution.Use generated builders for the operational program instructions.Fetch deterministic distribution and claim-receipt accounts through exported helpers.Install the MPL-Distro JavaScript SDKInstall MPL-Distro 0.4.x with its Umi and Toolbox peer dependencies.Terminalnpm install @metaplex-foundation/mpl-distro@^0.4 \\\n @metaplex-foundation/mpl-core@^1.3 \\\n @metaplex-foundation/umi@^1.1 \\\n @metaplex-foundation/umi-bundle-defaults \\\n @metaplex-foundation/mpl-toolbox@^0.10\n@metaplex-foundation/mpl-core is a declared peer dependency and supports the Core asset-signer helper flow.Register the MPL-Distro Umi PluginRegister mplDistro() once on the application's Umi instance.setupUmi.ts1import { mplDistro } from '@metaplex-foundation/mpl-distro'\n2import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n3\n4const rpcUrl = process.env.RPC_URL ?? 'https://api.devnet.solana.com'\n5\n6export const umi = createUmi(rpcUrl).use(mplDistro())\n7\n8// Umi is registered with the mplDistro plugin.\nThe plugin registers program name mplDistro at D1STRoZTUiEa6r8TLg2aAbG4nSRT5cDBmgG7jDqCZvU8.MPL-Distro Instruction BuildersThe SDK exposes a transaction builder for each operational program instruction.BuilderPurposePrimary argumentscreateDistributionCreate a distribution PDARoot, height, time window, claimant count, name, type, access modeupdateDistributionChange optional configuration fieldsDistribution plus fields to replacedepositFund the distribution token vaultDistribution, mint, amountwithdrawRecover tokens while inactiveDistribution, mint, amountdistributeClaim a wallet allocationDistribution, mint, recipient, amount, proof, noncedistributeToLegacyNftClaim an NFT-mint allocationDistribution, reward mint, NFT mint, owner, amount, proof, noncewithdrawSubsidyRecover unused receipt subsidyDistribution, recipient, amount in lamportsEvery builder returns a Umi TransactionBuilder and can be composed or submitted with .sendAndConfirm(umi).MPL-Distro Merkle HelpersThe SDK generates allocation-compatible roots and proofs from recipient records.ExportPurposeprepareDistribution(recipients)Return root, proofs, and treeHeighthashDistroLeaf(recipient)Serialize one address, amount, and nonce for hashingcomputeTreeHeight(leavesCount)Return the minimum internal height for a leaf countdistributeToAssetAndClaimClaim to a Core asset signer and transfer the tokens through Core ExecuteRecipientType containing address, amount, and optional nonceLegacyNftAlias of Recipient used when addresses are NFT mintsprepareDistribution.ts1import { mplDistro, prepareDistribution } from '@metaplex-foundation/mpl-distro'\n2import { publicKey } from '@metaplex-foundation/umi'\n3import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n4\n5const umi = createUmi(\n6 process.env.RPC_URL ?? 'https://api.devnet.solana.com'\n7).use(mplDistro())\n8\n9const allocations = [\n10 { address: publicKey(process.env.RECIPIENT_1!), amount: 100n, nonce: 0n },\n11 { address: publicKey(process.env.RECIPIENT_2!), amount: 200n, nonce: 0n },\n12]\n13\n14const { root, proofs, treeHeight } = prepareDistribution(allocations)\n15console.log(root, proofs, treeHeight)\n16\n17// root, one proof array per allocation, and treeHeight\nUse the proof at the same array index as its allocation. Preserve the amount and nonce with that proof.MPL-Distro Account FetchersAccount helpers deserialize distribution state and individual claim receipts.ExportResultfetchDistribution(umi, address)One decoded distributionsafeFetchDistribution(umi, address)Distribution or nullfetchAllDistribution(umi, addresses)Multiple decoded distributionsfetchClaimReceipt(umi, address)One decoded receiptsafeFetchClaimReceipt(umi, address)Receipt or nullfetchAllClaimReceipt(umi, addresses)Multiple decoded receiptsgetDistributionSize()Current distribution account sizegetClaimReceiptSize()Claim receipt account sizeThe SDK does not provide an indexer query for every distribution by authority or mint. Applications need known PDA inputs, indexed transaction data, or an external account index.MPL-Distro Distribution AccountThe distribution account stores configuration and aggregate bookkeeping for one mint and Merkle root.FieldTypeMeaningdistributionTypeDistributionTypeWallet or LegacyNftsubsidizeReceiptsbooleanWhether claims require receipt-rent reimbursementallowedDistributorAllowedDistributorSubmission authorization modetreeHeightnumberMaximum accepted proof lengthauthoritypublic keyAdministrative signermintpublic keyDistributed SPL token mintmerkleRoot32 bytesAllocation commitmentstartTime, endTimebigintInclusive Unix claim windowtotalClaimantsbigintDeclared allocation count metadatatotalAmountbigintDeposits minus withdrawals; claims do not decrement this fieldclaimCountbigintNumber of recorded claimsclaimAmountbigintSum of claimed token base unitsseedpublic keySeed signer used by the distribution PDAname32 bytesPadded UTF-8 distribution namepermissionedDistributorpublic keyRequired signer for permissioned modeMPL-Distro Enum ValuesDistribution and authorization enums select the claim identity and signer rules.EnumValueMeaningDistributionType.Wallet0Allocation identity is a wallet or public keyDistributionType.LegacyNft1Allocation identity is a legacy NFT mintAllowedDistributor.Permissionless0Any payer can submitAllowedDistributor.Recipient1Recipient or NFT owner must signAllowedDistributor.Permissioned2Configured distributor must signMPL-Distro PDA HelpersPDA helpers derive the program's deterministic distribution and receipt addresses.deriveDistroPdas.ts1import {\n2 findClaimReceiptPda,\n3 findDistributionPda,\n4 mplDistro,\n5} from '@metaplex-foundation/mpl-distro'\n6import { publicKey } from '@metaplex-foundation/umi'\n7import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n8\n9const umi = createUmi(\n10 process.env.RPC_URL ?? 'https://api.devnet.solana.com'\n11).use(mplDistro())\n12\n13const mint = publicKey(process.env.TOKEN_MINT!)\n14const seedPublicKey = publicKey(process.env.DISTRIBUTION_SEED!)\n15const recipient = publicKey(process.env.RECIPIENT_1!)\n16const amount = 100_000n\n17const nonce = 0n\n18\n19const [distribution] = findDistributionPda(umi, {\n20 mint,\n21 seed: seedPublicKey,\n22})\n23\n24const [receipt] = findClaimReceiptPda(umi, {\n25 distribution,\n26 recipient,\n27 amount,\n28 nonce,\n29})\n30\n31console.log(distribution, receipt)\n32\n33// Distribution PDA and claim-receipt PDA\nPDASeedsDistribution[\"distribution\", mint, seed]Claim receipt[\"claim_receipt\", distribution, recipient, amount_le, nonce_le]For LegacyNft, pass the NFT mint as recipient when deriving the receipt.MPL-Distro Error HelpersThe registered Umi program maps custom error codes to generated JavaScript error classes.ErrorTypical causeDistributionNotStartedClaim submitted before the start timestampDistributionEndedClaim submitted after the end timestampInvalidClaimProofAllocation fields or proof do not match the rootAlreadyClaimedReceipt already existsCannotWithdrawDuringActiveDistributionToken recovery attempted while activeCannotWithdrawWhileActiveReceipt-subsidy recovery attempted while activeInsufficientFundsRecorded token balance is below the claimInsufficientFundsToSubsidizeReceiptsDistribution SOL cannot reimburse receipt rentRecipientMustSignRecipient mode omitted the recipient signerInvalidDistributionTypeClaim builder does not match the configured typeInvalidDistributorPermissioned claim used the wrong signerUse getMplDistroErrorFromCode or the registered program's error mapping when decoding simulation and confirmation failures.MPL-Distro JavaScript Quick ReferenceThe JavaScript client and deployed program use the following stable identifiers.ItemValuePackage@metaplex-foundation/mpl-distroTested package range0.4.xUmi peer dependency1.1.1 or newerProgram IDD1STRoZTUiEa6r8TLg2aAbG4nSRT5cDBmgG7jDqCZvU8Fee wallet9kFjQsxtpBsaw8s7aUyiY3wazYDNgFP4Lj5rsBVVF8tbSourcemetaplex-foundation/mpl-distroNotesThe generated client exposes low-level instruction builders and does not manage off-chain proof delivery.prepareDistribution uses a memory-optimized implementation for 1,000 or more leaves.nonce defaults to zero in both claim builders.Optional account defaults depend on the Umi payer and should be supplied explicitly in sponsored flows.SDK package version, Rust crate version, and internal program crate version are released independently.Authority create, deposit, fetch, and withdraw can also run from the Metaplex CLI. Claims stay in the SDK.","tokens":2214,"squid":"spider-10","role":"Tooling Spider","at":1791345823854,"hash":"9c8d89d023027221517a26fc25a3aa82bc1cc8a6"}
{"url":"https://developer.arbitrum.io/launch-arbitrum-chain/integrations/infrastructure-providers","domain":"developer.arbitrum.io","title":"Third-party Arbitrum chain infrastructure providers","text":"Ecosystem supportThird-party Arbitrum chain infrastructure providersA high-level overview of third-party Arbitrum chain infrastructure providers for production-grade chains.Request an updateThis document provides an overview of third-party Arbitrum chain infrastructure providers that support production-grade Arbitrum chain deployments.\nNoteThis list is not exhaustive, and will be continuously updated as the Arbitrum ecosystem evolves.\nRollup-as-a-Service (RaaS) providers\nFor most production use-cases, we encourage Arbitrum chain operators to work with one of the following RaaS (Rollup as a Service) providers. These providers manage the infrastructure required to maintain high-performance, secure Arbitrum chain deployments:\n\nQuickNode\nCaldera\nConduit\nAltLayer\nGelato\nAsphere\nAlchemy\nZeeve\n\nChain explorers\nChain explorers let you view transactions, blocks, addresses, and network activity associated with your Arbitrum chain. The following explorers support Arbitrum chains, and can be used to monitor and analyze your chain's activity:\n\nBlockscout\nSocialscan\nLore\nRoutescan\n\nAdditionally, Arbitrum chains leveraging blobs for data availability may use tools like Blobscan to see which blob/block includes a given transaction.\nBridges\nYou can easily launch an Arbitrum chain with a canonical token bridge, which allows transfers to and from the chain via , , or the parent chain to which your Arbitrum chain settles transactions.\nFor applications that require the ability to transfer assets to chains outside of the Arbitrum ecosystem or in an expedited manner (without waiting for complete finality), the following third-party bridging providers can be used:\n\nLayerZero\nConnext\nHyperlane\nAxelar\nAcross\nDecent\n\nData availability providers for AnyTrust Chains\nAnyTrust protocol offers native support data availability. If you are turning on Fast Withdrawals, we recommend having at least three members as part of your Data Availability Committee. Here are some providers we recommend:\n\nChainbase\nAnkr\nKiln\nChainstack\nNansen\nUnifra\nBCW Group\nCaldera\n\nIndexers\nIndexers provide a convenient way to retrieve historic or application-specific data without having to interface with your chain through an RPC endpoint. The following third-party providers offer indexing services that can be used with Arbitrum chains:\n\nAlchemy\nChainstack\nEnvio\nGoldsky\nOrmi\nThe Graph\nTraceye\nQuickNode\nSequence\n\nOracles\nThe following Oracle providers can be used to integrate offchain data with your Arbitrum chain's smart contracts:\n\nChainlink\nChronicle\nPyth\nRedstone\nRandomizer (VRF only)\nSupra\nRedStone\n\nRPC endpoints\nRPC endpoints are the primary interface through which users and developers interact with any chain, whether it be for transaction submission, reading state, or indexing historical data. The following third-party providers offer RPC endpoint services compatible with Arbitrum chains:\n\nAlchemy\nAnkr\nChainstack\nGrove\nGetBlock\nQuickNode\nSequence\n\nAlternative data availability\nOne way to reduce transaction fees for Arbitrum chains is to configure a Data Availability (DA) solution that stores chain data offchain. Although the AnyTrust protocol offers native support for this functionality (and is configurable by default on Arbitrum AnyTrust chains), the following third-party providers give you another way to store data offchain. Note that using these services will limit your chain's ability to leverage AnyTrust protocol improvements as they relate to transaction fee and DA configurability:\n\nCelestia\nEigenDA\nAvailDA\nEspressoDA\nNear\nHow is this guide?Exchange integration checklistA version-pinned checklist that helps centralized exchanges reliably detect deposits, process withdrawals, and re-verify their indexing logic across Nitro and ArbOS upgrades on Dedicated Blockchains.MigrateMove to the Arbitrum stack from another stack or RaaS","tokens":962,"squid":"spider-01","role":"Chain Spider","at":1791345831001,"hash":"4f752201af737bf1210a82609e57676ceea21dfd"}
{"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":"spider-08","role":"Oracle Spider","at":1791345831049,"hash":"27ef3e5a52173066bee7ea8aeaca2176a64d6c43"}
{"url":"https://developer.arbitrum.io/launch-arbitrum-chain/integrations/bridged-usdc","domain":"developer.arbitrum.io","title":"How to adopt the bridged USDC standard on your Arbitrum chain","text":"Ecosystem supportHow to adopt the bridged USDC standard on your Arbitrum chainHow to implement Circle bridged USDC standard on Arbitrum chainRequest an updateCircle’s Bridged USDC Standard is a specification and process for deploying a bridged form of USDC on EVM blockchains with optionality for Circle to upgrade to native issuance in the future.\nWhy adopt the bridged USDC standard?\nWhen USDC is bridged into an Arbitrum chain, the default path is to use the chain’s canonical gateway contracts for ERC-20's. By way of example, when a user bridges USDC from Arbitrum One to an Arbitrum chain, their Arbitrum One USDC tokens are locked into the Arbitrum chain’s parent side bridge, and a representative USDC token is minted to the user’s address on the Arbitrum chain, via the child side bridge.\nThe challenge with this user flow is two-fold:\n\nNative vs. non-Native USDC: The USDC tokens issued by Circle (’native USDC’) are locked in the parent side bridge contract. Conversely, the USDC tokens on the Arbitrum chain aren’t native USDC but are collateralized by the locked tokens in the bridge. As such, Circle will not recognize these tokens across their product suite.\nFragmented UX: If Circle were to provide native support for USDC by deploying a USDC contract on the Arbitrum chain, there would be two forms of USDC on the chain (native and non-native USDC). This leads to a fragmented user experience, and users with non-native USDC would have to withdraw to the parent chain to be able to turn their tokens into native USDC.\n\nBy deploying the bridged USDC standard from the start, all USDC tokens that are bridged are locked in a gateway contract that can be adopted by Circle should a chain upgrade its USDC into native USDC. This allows USDC adoption on Arbitrum chains today without encountering either of the two problems above.\nHow to implement the bridged USDC Standard\nWe provide a custom USDC gateway implementation (for parent and child chains) that follows the Bridged USDC Standard. These contracts can be used by new Arbitrum chains. This solution will not be used in existing Arbitrum chains that are governed by the DAO.\n\nOn a parent chain the contract L1USDCGateway is used in case the child chain uses ETH as native currency, or L1OrbitUSDCGateway in case the child chain uses a custom fee token.\nOn a child chain, L2USDCGateway is used.\nFor the USDC token contracts, Circle's reference implementation is used.\n\nThis page describes how to deploy a USDC bridge compatible with both the Arbitrum chain token bridge and Circle’s Bridged USDC Standard.\nSteps for a transition to native USDC issuance are also provided. Note that both Circle and the Arbitrum chain owner must agree to transition to native USDC issuance.\nRequirements\n\nRecommended token bridge version 1.2.0\nNo additional dependencies with Nitro or Nitro contract version\n\nOther requirements:\n\nIt is assumed there is already a USDC token deployed and used on the parent chain.\nAlso, it is assumed that the standard Arbitrum chain ownership system is used, i.e., UpgradeExecutor is the owner of the ownable contracts, and there is an EOA or multi-sig that has the executor role on the UpgradeExecutor.\nRefer to the token bridge overview page for more information about the token bridge design and operational dynamics. You can learn more in our overview of gateway operating models.\n\nDeployment steps\n\nCheckout target code, install dependencies, and build\ncd token-bridge-contracts\nyarn install\nyarn build\nPopulate your .env file based on env.example in the project's root directory\nPARENT_RPC=\nPARENT_DEPLOYER_KEY=\nCHILD_RPC=\nCHILD_DEPLOYER_KEY=\nL1_ROUTER=\nL2_ROUTER=\nINBOX=\nL1_USDC=\n## OPTIONAL arg. If set, the script will register the gateway. Otherwise, it will store the transaction's payload in a file\nROLLUP_OWNER_KEY=\nRun the script:\nyarn deploy:usdc-token-bridge\nThe script will do the following:\n\nLoad deployer wallets for L1 and L2\nRegister L1 and L2 networks in SDK\nDeploy new L1 and L2 proxy admins\nDeploy bridged (L2) USDC using the Circle's implementation\nInit L2 USDC\nDeploy L1 USDC gateway\nDeploy L2 USDC gateway\nInit both gateways\nIf ROLLUP_OWNER_KEY is provided, register the gateway in the router through the UpgradeExecutor\nIf ROLLUP_OWNER_KEY is not provided, prepare calldata and store it in the registerUsdcGatewayTx.json file\nSet minter role to L2 USDC gateway with max allowance\n\nNow, new USDC gateways can be used to deposit/withdraw USDC. Everything is now in place to support transition to native USDC issuance if Circle and the Arbitrum chain owner agree to it.\nIf your deposits still route through the standard ERC-20 gateway after the script finishes, the gateway registration never landed. See Bridged USDC routes to the standard gateway in the token bridge troubleshooting guide.\nTransitioning to native USDC\nOnce a transition to native USDC is agreed upon, the following steps are required:\n\nL1 gateway owner pauses deposits on the parent chain by calling pauseDeposits()\nL2 gateway owner pauses withdrawals on the child chain by calling pauseWithdrawals()\nmaster minter removes the minter role from the child chain gateway\n\nNoteThere should be no in-flight deposits when the minter role is revoked. If there are any, they should be finalized first. Anyone can do that by claiming the failed retryable tickets that execute a USDC deposit\n\nL1 gateway owner sets Circle's account as burner on the parent chain gateway using setBurner(address)\nL1 gateway owner reads the total supply of USDC on the child chain and then invokes setBurnAmount(uint256) on the parent/child gateway where the amount matches the total supply\nUSDC masterMinter gives the minter role with 0 allowance to the L1 gateway so that the burn can be executed\non the child chain, the L2 gateway owner calls the setUsdcOwnershipTransferrer(address) to set the account (provided and controlled by Circle), which will be able to transfer the bridged USDC ownership and proxy admin\nif not already owned by the gateway, the L2 USDC owner transfers ownership to the gateway, and proxy admin transfers admin rights to the gateway\nCircle uses the usdcOwnershipTransferrer account to trigger transferUSDCRoles(address), which will set the caller as USDC proxy admin and will transfer USDC ownership to the provided address\nCircle calls burnLockedUSDC() on the L1 gateway using the burner account to burn the burnAmount of USDC\n\nremaining USDC will be cleared off when remaining in-flight USDC withdrawals are executed, if any\nThe L1 gateway owner is trusted to not front-run this transaction to modify the burning amount\n\nHow is this guide?How to add your Arbitrum chain to Arbitrum's bridge.Learn how to add your Arbitrum chain to Arbitrum's bridge.Exchange integration checklistA version-pinned checklist that helps centralized exchanges reliably detect deposits, process withdrawals, and re-verify their indexing logic across Nitro and ArbOS upgrades on Dedicated Blockchains.","tokens":1740,"squid":"spider-01","role":"Chain Spider","at":1791345841000,"hash":"c126da9b329feaa1edae915480f110006eb23172"}
{"url":"https://www.metaplex.com/docs/smart-contracts/mpl-distro/funding-and-recovery","domain":"metaplex.com","title":"Fund and Recover an MPL-Distro Token Distribution","text":"MPL-Distro separates token funding in the distribution vault from optional SOL funding for claim-receipt rent. SummaryThe authority deposits SPL tokens into the distribution's associated token account and may fund the distribution PDA with SOL when receipt subsidies are enabled.Deposit enough token base units to cover every Merkle allocation.Budget one claim-receipt rent payment per expected successful claim.Monitor both the recorded totalAmount and the actual vault token balance.Withdraw unclaimed tokens and unused subsidy SOL only when the distribution is inactive.Quick StartMPL-Distro funding and recovery follows four operational steps.Sum all allocation amounts and deposit that many token base units.When receipt subsidies are enabled, transfer the expected receipt-rent budget to the distribution PDA.Monitor the actual vault balance, distribution SOL, and claim totals.After the window ends, withdraw unclaimed tokens and unused subsidy SOL.Deposit Distribution TokensThe deposit instruction transfers tokens from the depositor's account to the distribution PDA's canonical associated token account. The current distribution authority must sign every deposit, even when a different wallet supplies the tokens.fundDistribution.ts1import {\n2 deposit,\n3 mplDistro,\n4} from '@metaplex-foundation/mpl-distro'\n5import { publicKey } from '@metaplex-foundation/umi'\n6import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n7\n8const umi = createUmi(\n9 process.env.RPC_URL ?? 'https://api.devnet.solana.com'\n10).use(mplDistro())\n11\n12// The Umi identity must be the current distribution authority.\n13\n14const distribution = publicKey(process.env.DISTRIBUTION_ADDRESS!)\n15const mint = publicKey(process.env.TOKEN_MINT!)\n16const totalAmount = 350_000n\n17\n18await deposit(umi, {\n19 distribution,\n20 mint,\n21 amount: totalAmount,\n22}).sendAndConfirm(umi)\n23\n24// The distribution ATA contains 350000 base units.\nThe SDK defaults depositor, payer, and authority to the Umi payer and derives both associated token accounts. Supply a separate depositor signer when another wallet owns the source tokens, and still pass the current distribution authority.depositFromSeparateWallet.ts1import { deposit, mplDistro } from '@metaplex-foundation/mpl-distro'\n2import { publicKey } from '@metaplex-foundation/umi'\n3import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n4\n5const umi = createUmi(\n6 process.env.RPC_URL ?? 'https://api.devnet.solana.com'\n7).use(mplDistro())\n8\n9const distribution = publicKey(process.env.DISTRIBUTION_ADDRESS!)\n10const mint = publicKey(process.env.TOKEN_MINT!)\n11const amount = 350_000n\n12const treasurySigner = umi.identity\n13const feePayer = umi.payer\n14const distributionAuthority = umi.identity\n15\n16await deposit(umi, {\n17 distribution,\n18 mint,\n19 depositor: treasurySigner,\n20 payer: feePayer,\n21 authority: distributionAuthority,\n22 amount,\n23}).sendAndConfirm(umi)\n24\n25// Tokens move from the treasury ATA to the distribution vault.\nThe program increments totalAmount after each deposit. It does not compare that value with the sum of allocations committed by the Merkle root.Calculate the Token DepositThe required token deposit is the sum of all allocation amounts expressed in the mint's base units.calculateDeposit.ts1import { publicKey } from '@metaplex-foundation/umi'\n2\n3const allocations = [\n4 { address: publicKey(process.env.RECIPIENT_1!), amount: 100_000n },\n5 { address: publicKey(process.env.RECIPIENT_2!), amount: 250_000n },\n6]\n7\n8const totalAmount = allocations.reduce(\n9 (total, allocation) => total + BigInt(allocation.amount),\n10 0n\n11)\n12console.log(totalAmount)\n13\n14// 350000\nDeposit a deliberate buffer only when the authority accepts that it must recover the excess later. A valid proof fails with InsufficientFunds when the recorded balance is below its allocation, and the SPL transfer can also fail if the actual vault balance is lower.Fund Claim Receipt SubsidiesReceipt subsidies let the distribution PDA reimburse the transaction payer for the rent used to create each claim receipt.Enable subsidizeReceipts during createDistribution, calculate rent through the RPC, and transfer SOL directly to the distribution PDA:fundReceiptSubsidy.ts1import { getClaimReceiptSize, mplDistro } from '@metaplex-foundation/mpl-distro'\n2import { transferSol } from '@metaplex-foundation/mpl-toolbox'\n3import { multiplyAmount, publicKey } from '@metaplex-foundation/umi'\n4import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n5\n6const umi = createUmi(\n7 process.env.RPC_URL ?? 'https://api.devnet.solana.com'\n8).use(mplDistro())\n9\n10const distribution = publicKey(process.env.DISTRIBUTION_ADDRESS!)\n11const expectedClaimCount = 2\n12\n13const receiptRent = await umi.rpc.getRent(getClaimReceiptSize())\n14const budget = multiplyAmount(receiptRent, expectedClaimCount)\n15\n16await transferSol(umi, {\n17 destination: distribution,\n18 amount: budget,\n19}).sendAndConfirm(umi)\n20\n21// The distribution PDA holds extra SOL for claim-receipt rent.\nSubsidy Budget BoundaryThe distribution must retain its own rent-exempt minimum. A claim fails with InsufficientFundsToSubsidizeReceipts when the remaining SOL cannot cover both the distribution rent and one receipt reimbursement.MPL-Distro Funding Quick ReferenceClaim costs are split among a fixed protocol fee, Solana transaction costs, and account rent.CostDefault payerReceipt subsidy covers itProtocol fee (0.002 SOL)Claim transaction payerNoTransaction feeClaim transaction payerNoClaim receipt rentClaim transaction payerYes, when enabled and fundedRecipient ATA rentClaim transaction payerNoRecover Unclaimed TokensThe distribution authority recovers unclaimed or excess tokens with withdraw before the start time or after the end time.recoverFunds.ts1import {\n2 DISTRIBUTION_SIZE,\n3 fetchDistribution,\n4 mplDistro,\n5 withdraw,\n6 withdrawSubsidy,\n7} from '@metaplex-foundation/mpl-distro'\n8import { publicKey } from '@metaplex-foundation/umi'\n9import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n10\n11const umi = createUmi(\n12 process.env.RPC_URL ?? 'https://api.devnet.solana.com'\n13).use(mplDistro())\n14\n15// The Umi identity must be the current distribution authority.\n16\n17const distribution = publicKey(process.env.DISTRIBUTION_ADDRESS!)\n18const mint = publicKey(process.env.TOKEN_MINT!)\n19\n20// Token and subsidy withdrawals succeed only outside the active window.\n21await withdraw(umi, {\n22 distribution,\n23 mint,\n24 amount: 50_000n,\n25}).sendAndConfirm(umi)\n26\n27const distributionAccount = await fetchDistribution(umi, distribution)\n28if (distributionAccount.subsidizeReceipts) {\n29 const balance = await umi.rpc.getBalance(distribution)\n30 const rent = await umi.rpc.getRent(DISTRIBUTION_SIZE)\n31 const unusedSubsidy = balance.basisPoints - rent.basisPoints\n32\n33 if (unusedSubsidy > 0n) {\n34 await withdrawSubsidy(umi, {\n35 distribution,\n36 recipient: umi.identity.publicKey,\n37 amount: unusedSubsidy,\n38 }).sendAndConfirm(umi)\n39 }\n40}\n41\n42// 50000 token base units and any unused receipt subsidy are returned.\nThe active interval is inclusive. A withdrawal is rejected when startTime <= clusterTime <= endTime.Recover Unused Subsidy SOLThe authority recovers unused receipt subsidy with withdrawSubsidy only when subsidies are enabled and the distribution is inactive.withdrawSubsidy transfers a requested lamport amount while preserving the distribution account's rent-exempt minimum. Determine the safe amount from the current account balance instead of assuming every expected claim occurred.Monitor Distribution BalancesProduction systems should compare program bookkeeping with the actual SPL and SOL account balances.ValueSourceMeaningdistribution.totalAmountDistribution accountDeposits minus withdrawals recorded by the program; claims do not decrement itVault token amountDistribution associated token accountTokens actually available for transferDistribution lamportsDistribution PDA accountRent reserve plus optional unused receipt subsidyclaimCountDistribution accountNumber of recorded successful claimsclaimAmountDistribution accountSum of recorded claimed token base unitsThe token withdrawal bookkeeping uses saturating subtraction, so integrations should not assume totalAmount can never diverge from the SPL vault balance.NotesFunding operations require authority controls and explicit balance monitoring.Only the current distribution authority can authorize a deposit.Deposits are allowed before, during, and after the claim window.Token and subsidy withdrawals are blocked throughout the active window.Anyone can transfer SOL directly to the distribution PDA, but only the authority can withdraw subsidy through the program.Receipt rent remains allocated because claim receipts cannot currently be closed.FAQCan the authority withdraw tokens while claims are active?No. Token withdrawals are rejected from the start timestamp through the end timestamp, inclusive.What costs does subsidizeReceipts reimburse?It reimburses claim-receipt rent only, not the protocol fee, transaction fee, or recipient token-account rent.Can more tokens be deposited after claims start?Yes. Deposits are not time-gated, so the authority can replenish an underfunded vault.Can a treasury wallet deposit without the distribution authority?No. The current authority must sign deposit, even when a separate depositor supplies the tokens.","tokens":2349,"squid":"spider-10","role":"Tooling Spider","at":1791345856603,"hash":"796b9b625c8431253cf7e8bf9305cf2a4c2f6e25"}
{"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":"spider-08","role":"Oracle Spider","at":1791345862582,"hash":"d7ac3d58b6d16a404f8a7923662d05c5486ede83"}
{"url":"https://developer.arbitrum.io/launch-arbitrum-chain/integrations/bp-kms-signing-services","domain":"developer.arbitrum.io","title":"Batch poster: External signing (KMS)","text":"Ecosystem supportBatch poster: External signing (KMS)Learn how to integrate external signing—including AWS KMS—for your chain's batch poster.Request an updateNitro's batch poster (and staker) sign their parent chain transactions through the DataPoster component. By default, it signs locally with a private key, but it also supports generic RPC-based external signing: instead of holding the key, Nitro sends an unsigned transaction to a remote signer over (m)TLS, gets back a signed transaction, and independently verifies it.\nNoteThere is no native AWS KMS integration in the Nitro codebase. KMS support is achieved by running a separate signer service that talks to KMS and exposes an Ethereum-style eth_signTransaction RPC endpoint. Nitro connects to that endpoint. In other words: \"KMS support\" = external signer pointed at a KMS-backed signing service.\nHow it works internally\n\nConnect—rpcClient() dials the signer URL with a TLS config: optional client cert/key for mTLS (ClientCert/ClientPrivateKey), optional RootCA (lets you use self-signed certs), and InsecureSkipVerify.\nSign—externalSigner() returns a signer callback that:\n\nConverts the transaction to apitypes.SendTxArgs via TxToSignTxArgs.\n\nIt fully supports EIP-4844 blob transactions (blobs, commitments, proofs), which the batch poster needs.\n\nCalls the configured RPC method: client.CallContext(ctx, &data, opts.Method, args), expecting an RLP-encoded signed transaction back.\nVerifies the returned transaction: the hash must match the request and the recovered sender must equal the configured Address. This means TLS is not relied on for authentication—the signature itself is checked at the application layer.\n\nConfiguration\nThe config struct is ExternalSignerCfg:\nFieldkoanf keyPurposeURLurlRPC endpoint of the signer. Setting this enables external signing (overrides local key).AddressaddressHex Ethereum address the signer controls; used to verify returned signatures.MethodmethodRPC method name, e.g., eth_signTransaction.RootCAroot-ca(Optional) CA cert to trust — enables self-signed server certs.ClientCertclient-cert(Optional) client cert for mTLS.ClientPrivateKeyclient-private-key(Optional) client key for mTLS (required if client-cert set).InsecureSkipVerifyinsecure-skip-verifySkip server TLS verification (not recommended).\nThis config is nested under both the batch poster and the staker, so the full CLI flag paths are:\nBatch poster:\n--node.batch-poster.data-poster.external-signer.url\n--node.batch-poster.data-poster.external-signer.address\n--node.batch-poster.data-poster.external-signer.method\n--node.batch-poster.data-poster.external-signer.root-ca\n--node.batch-poster.data-poster.external-signer.client-cert\n--node.batch-poster.data-poster.external-signer.client-private-key\n--node.batch-poster.data-poster.external-signer.insecure-skip-verify\nStaker uses the same fields under --node.staker.data-poster.external-signer.*.\nWhen external-signer.url is empty, the batch poster requires a local key. AnyTrust chains need a local key even when external signing is enabled: the external signer covers the batch transactions posted to the parent chain, but the requests sent to the are still signed with a local key. See External signer support for how to configure the separate key.\nWhat the signer service must implement\nYour signer (whether KMS-backed or otherwise) must expose an HTTPS RPC server with a method matching Method that:\n\nAccepts an Ethereum transaction object (apitypes.SendTxArgs—the standard eth_signTransaction shape, including blob fields for EIP-4844),\nReturns the RLP-encoded signed transaction as a hex string,\nSigns with the key for the address you configured as address.\n\nIf you use mTLS, the server must require and verify the client cert that matches client-cert/client-private-key.\nReference implementations\nNitro ships two working examples you can model a KMS service on:\n\ncmd/mockexternalsigner/mockexternalsigner.go—a standalone signer binary. It\nbuilds an rpc.Server, registers a signing method, serves over HTTPS with\ntls.RequireAndVerifyClientCert. Swap the\nlocal-key txOpts.Signer for a KMS-backed signer, and you have a KMS integration.\narbnode/dataposter/externalsignertest/externalsignertest.go—the test harness,\nshowing the server side (SignerAPI, method registration, cert setup with\nRequireAndVerifyClientCert). The RPC method (externalsignertest.go:185) takes\n*apitypes.SendTxArgs and returns the RLP-encoded signed transaction as hexutil.Bytes.\nHow is this guide?Ecosystem supportEcosystem support documentationHow to add your Arbitrum chain to Arbitrum's bridge.Learn how to add your Arbitrum chain to Arbitrum's bridge.","tokens":1163,"squid":"spider-01","role":"Chain Spider","at":1791345862867,"hash":"7e5d6658f6dfb078d80dd7b62c12111551205dfd"}
{"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":"spider-08","role":"Oracle Spider","at":1791345884264,"hash":"39ed4f298b8c3f42ed66a542c63cbd5f08342b28"}
{"url":"https://www.metaplex.com/docs/smart-contracts/token-metadata/guides/anchor/token-claimer-smart-contract","domain":"metaplex.com","title":"How to Create a Token Claimer Smart Contract | Token Metadata Guides","text":"Token Metadata is a legacy program. It remains supported, but is not recommended for new projects. Use Core instead.This guide leverages the use of Merkle Trees and Compression to create a low-cost Token Claimer for Token Metadata Tokens using Anchor.PrerequisiteBefore starting to learn more about how the Token Claimer works, we should look into how Compression and Merkle Trees work to really understand what is going on inside of the smart contract.Merkle TreesA Merkle tree is a binary tree used to efficiently represent a set of data. Each leaf node in the tree is a hash of individual data (e.g., an address and token amount). Parent nodes are created by hashing pairs of child nodes, continuing up the tree until reaching the root, which serves as a compact and tamper-proof representation of the entire dataset.Example: Suppose we have four data entries: A, B, C, and D. The Merkle tree structure is built as follows:Leaf Nodes: Each entry is hashed:Hash(A), Hash(B), Hash(C), Hash(D)\nParent Nodes: Pairs of leaf nodes are combined and hashed:Parent1 = Hash(Hash(A) + Hash(B))\nParent2 = Hash(Hash(C) + Hash(D))\nRoot Node: The final hash is computed from the parent nodes:Root = Hash(Parent1 + Parent2)\nRoot NodeHashNode 1HashNode 2Node 3Node 4HashNode 5Node 6Leaf 1Leaf 2Leaf 3Leaf 4Leaf 5Leaf 6Leaf 7Leaf 8NFT DataLeaf 4Node 3Node 2ProofReact FlowPress enter or space to select a node.You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel. Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.Merkle trees are a cornerstone of on-chain compression, enabling efficient and secure data verification. By design, altering any part of the dataset invalidates the root, which means the integrity of a specific entry can be verified by storing only the Merkle root on-chain and providing a Merkle Proof—a minimal set of sibling hashes needed to reconstruct the root.Key Advantages: Cost-Efficient Storage: Only the Merkle root (32 bytes) is stored on-chain, significantly reducing storage costs. Verification is achieved by passing Merkle proofs as inputs.Scalability: Proof sizes grow logarithmically with the number of entries, making this method ideal for managing large datasets.Privacy and Efficiency: Entire Merkle trees can be generated and managed off-chain, keeping the full dataset private. Programs like Compressed NFTs use this approach with Solana’s noop program, optimizing performance while maintaining privacy.Concurrent Merkle TreeSolana's state compression employs a unique type of Merkle tree that enables multiple changes to a tree while preserving its integrity and validity.This specialized tree, called a concurrent Merkle tree, maintains an on-chain changelog, allowing multiple rapid updates to the same tree (e.g., all within the same block) without invalidating proofs.This functionality is essential on Solana where only one writer per block is allowed per account. This limites updates to a single change per block, so the runtime can ensure the account's security and prevents corruption. Since every action requires writing, concurrent Merkle tree offers an efficient solution for managing multiple updates within the same block seamlessly.SetupCode Editor of your choice (recommended Visual Studio Code with the Rust Analyzer Plugin)Anchor 0.30.1 or above.Additionally, in this guide we’re going to leverage a mono-file approach to Anchor where all the necessary macros can be found in the lib.rs file:declare_id: Specifies the program's on-chain address.#[program]: Specifies the module containing the program’s instruction logic.#[derive(Accounts)]: Applied to structs to indicate a list of accounts required for an instruction.#[account]: Applied to structs to create custom account types specific to the program.Note: You may need to modify and move functions around to suit your needs.Initializing the ProgramStart by initializing a new project (optional) using avm (Anchor Version Manager). To initialize it, run the following command in your terminalanchor init token-claimer-example\nRequired CratesIn this guide, we'll use the svm_merkle_tree crate an optimized version for creating and managing merkle trees for the SVM. To install it, first navigate to the token-claimer-example directory:cd token-claimer-example\nThen run the following command to install the merkle tree crate:cargo add svm-merkle-tree --git https://github.com/deanmlittle/svm-merkle-tree\nAnd then we run the following command to install the anchor-spl to interact with the Token Program:cargo add anchor-spl\nThe programThis example is not a full-fledged implementation suitable for production. To make it production-ready, several additional components and considerations are necessary:Event Emission: Use the event!() macro to emit events for important actions, such as successful claims or updates to the Merkle root. Alternatively, you can integrate with Solana's noop program to log updates and facilitate data indexing for off-chain applications.Database Hosting: You'll need to store and host the complete Merkle tree dataset off-chain and derive hashes for leaves and internal nodes other than generate and serve Merkle proofs dynamically and validate input consistency for claims.Imports and TemplatesHere we're going to define all the imports for this particular guide and create the template for the Account struct and instruction in our lib.rs file.use anchor_lang::prelude::*;\n\nuse anchor_spl::associated_token::AssociatedToken;\nuse anchor_spl::token::{mint_to, set_authority, transfer, Mint, MintTo, SetAuthority, Token, TokenAccount, Transfer, spl_token::instruction::AuthorityType}\n\nuse svm_merkle_tree::{HashingAlgorithm, MerkleProof};\n\ndeclare_id!(\"C9PLf3qMCVqtUCJtEBy8NCcseNp3KTZwFJxAtDdN1bto\");\n\n/// Instructions and Logic behind the program\n#[program]\npub mod merkle_tree_token_claimer {\n use super::*;\n\n pub fn initialize_airdrop_data(\n ctx: Context<Initialize>, \n merkle_root: [u8; 32],\n amount: u64,\n ) -> Result<()> {\n\n Ok(())\n }\n\n pub fn update_tree(\n ctx: Context<Update>, \n new_root: [u8; 32]\n ) -> Result<()> {\n\n Ok(())\n }\n\n pub fn claim_airdrop(\n ctx: Context<Claim>,\n amount: u64,\n hashes: Vec<u8>,\n index: u64,\n ) -> Result<()> { \n\n Ok(())\n }\n\n}\n\n/// Account Struct for the different Instructions\n#[derive(Accounts)]\npub struct Initialize<'info> {\n\n}\n\n#[derive(Accounts)]\npub struct Update<'info> {\n\n}\n\n#[derive(Accounts)]\npub struct Claim<'info> {\n\n}\n\n/// State account holding the merkle tree and airdrop information\n#[account]\npub struct AirdropState {\n\n}\n\n/// Error for the Program\n#[error_code]\npub enum AirdropError {\n\n}\nThis serves as the template for the on-chain program, however, there is also significant frontend overhead to consider which we’ll address in detail in this writeup.Initializing the Merkle TreeWe begin by initializing a Merkle tree with user data, including their claimable amounts. This process is performed off-chain, where we calculate the tree's root and later upload it on-chain, reducing computational costs while maintaining integrity.In this example, we generate 100 random addresses and 100 random amounts, and initialize an isClaimed flag for each entry, setting it to false. These details are serialized into binary format to efficiently populate the Merkle tree and we then merklize the data we just created to create the root.import * as anchor from \"@coral-xyz/anchor\";\nimport { Keypair, PublicKey, SystemProgram, LAMPORTS_PER_SOL, Transaction } from \"@solana/web3.js\";\nimport { HashingAlgorithm, MerkleTree } from \"svm-merkle-tree\";\n\n// Generate 100 random addresses and amount\nlet merkleTreeData = Array.from({ length: 100 }, () => ({\n address: Keypair.generate().publicKey, // Example random address\n amount: Math.floor(Math.random() * 1000), // Example random amount\n isClaimed: false, // Default value for isClaimed\n}));\n\n// Create Merkle Tree\nlet merkleTree = new MerkleTree(HashingAlgorithm.Keccak, 32);\n\nmerkleTreeData.forEach((entry) => {\n // Serialize address, amount, and isClaimed in binary format\n const entryBytes = Buffer.concat([\n entry.address.toBuffer(),\n Buffer.from(new Uint8Array(new anchor.BN(entry.amount).toArray('le', 8))),\n Buffer.from([entry.isClaimed ? 1 : 0]),\n ]);\n merkleTree.add_leaf(entryBytes);\n});\n\nmerkleTree.merklize();\n\nconst merkleRoot = Array.from(merkleTree.get_merkle_root());\nOn-chain, we define an AirdropState account to manage and track the state of the airdrop. This account holds key information needed to securely distribute tokens based on the Merkle tree mechanism. Below is the breakdown of each field:#[account]\npub struct AirdropState {\n /// The current merkle root\n pub merkle_root: [u8; 32],\n /// The authority who can update the merkle root\n pub authority: Pubkey,\n /// The mint address of the token being airdropped\n pub mint: Pubkey,\n /// Total amount allocated for the airdrop\n pub airdrop_amount: u64,\n /// Total amount claimed so far\n pub amount_claimed: u64,\n /// PDA bump seed\n pub bump: u8,\n}\nThe initialize_airdrop_data instruction will just populate the AirdropState and, before revoking the mint_authority, mint enough tokens in the vaultpub fn initialize_airdrop_data(\n ctx: Context<Initialize>, \n merkle_root: [u8; 32],\n amount: u64,\n) -> Result<()> {\n\n ctx.accounts.airdrop_state.set_inner(\n AirdropState {\n merkle_root,\n authority: ctx.accounts.authority.key(),\n mint: ctx.accounts.mint.key(),\n airdrop_amount: amount,\n amount_claimed: 0,\n bump: ctx.bumps.airdrop_state,\n }\n );\n\n mint_to(\n CpiContext::new(\n ctx.accounts.token_program.to_account_info(), \n MintTo {\n mint: ctx.accounts.mint.to_account_info(),\n to: ctx.accounts.vault.to_account_info(),\n authority: ctx.accounts.authority.to_account_info(),\n }\n ),\n amount\n )?;\n\n set_authority(\n CpiContext::new(\n ctx.accounts.token_program.to_account_info(), \n SetAuthority {\n current_authority: ctx.accounts.authority.to_account_info(),\n account_or_mint: ctx.accounts.mint.to_account_info(),\n }\n ), \n AuthorityType::MintTokens,\n None\n )?;\n\n Ok(())\n}\n\n#[derive(Accounts)]\npub struct Initialize<'info> {\n #[account(\n init, \n seeds = [b\"merkle_tree\".as_ref(), mint.key().to_bytes().as_ref()],\n bump,\n payer = authority, \n space = 8 + 32 + 32 + 32 + 8 + 8 + 1\n )]\n pub airdrop_state: Account<'info, AirdropState>,\n #[account(mut)]\n pub mint: Account<'info, Mint>,\n #[account(\n init_if_needed,\n payer = authority,\n associated_token::mint = mint,\n associated_token::authority = airdrop_state,\n )]\n pub vault: Account<'info, TokenAccount>,\n #[account(mut)]\n pub authority: Signer<'info>,\n pub system_program: Program<'info, System>,\n pub token_program: Program<'info, Token>,\n pub associated_token_program: Program<'info, AssociatedToken>,\n}\nUpdate the Merkle Root onchain if neededWe're going to create the update_tree instruction that will let the authority of the AirdropState change the root onchain. This can be used to add a new user or to revoke allocation.For this example we're going to create a new random allocation for a random address and push this entry in the Merkle Tree we created in the last instruction, like this:const newData = {\n address: Keypair.generate().publicKey,\n amount: Math.floor(Math.random() * 1000), // Example random amount\n isClaimed: false, // Default value for isClaimed\n};\n\nmerkleTreeData.push(newData); \n\nconst entryBytes = Buffer.concat([\n newData.address.toBuffer(), // PublicKey as bytes\n Buffer.from(new Uint8Array(new anchor.BN(newData.amount).toArray('le', 8))), // Amount as little-endian\n Buffer.from([newData.isClaimed ? 1 : 0]), // isClaimed as 1 byte\n]);\n\nmerkleTree.add_leaf(entryBytes);\n\nmerkleTree.merklize();\n\nconst newMerkleRoot = Array.from(merkleTree.get_merkle_root());\nWe can easily update the root this way then:pub fn update_tree(\n ctx: Context<Update>, \n new_root: [u8; 32]\n) -> Result<()> {\n\n ctx.accounts.airdrop_state.merkle_root = new_root;\n\n Ok(())\n}\n\n#[derive(Accounts)]\npub struct Update<'info> {\n #[account(\n mut, \n has_one = authority,\n seeds = [b\"merkle_tree\".as_ref(), airdrop_state.mint.key().to_bytes().as_ref()],\n bump = airdrop_state.bump\n )]\n pub airdrop_state: Account<'info, AirdropState>,\n pub authority: Signer<'info>,\n}\nWe verify that this change is \"safe\" because we check the authority provided against the authority saved in the AirdropState using the has_one constrain.Claiming instruction for the UserWhen a user claims tokens, their eligibility is verified using the Merkle Tree Root stored on-chain.Step 1: Generate Merkle Proof:The system locates the user’s data in the external Merkle Tree database, generated from the previous examples, and generates the Merkle Proof. This proof includes the hashes of sibling nodes along the path to the user’s leaf and the index, enabling the verification process, like this:const index = merkleTreeData.findIndex(data => data.address.equals(newAddress.publicKey));\n\nif (index === -1) {\n throw new Error(\"Address not found in Merkle tree data\");\n}\n\nconst proof = merkleTree.merkle_proof_index(index);\nconst proofArray = Buffer.from(proof.get_pairing_hashes());\nStep 2: On-Chain VerificationUsing the user’s submitted data, the generated Merkle Proof, and the data’s index, the system reconstructs the Merkle Root on-chain. The reconstructed root is then compared to the stored root to ensure the claim is valid and the Merkle Tree's integrity is preserved.pub fn claim_airdrop(\n ctx: Context<Claim>,\n amount: u64,\n hashes: Vec<u8>,\n index: u64,\n) -> Result<()> { \n let airdrop_state = &mut ctx.accounts.airdrop_state;\n\n // Step 1: Verify that the Signer and Amount are right by computing the original leaf\n let mut original_leaf = Vec::new();\n original_leaf.extend_from_slice(&ctx.accounts.signer.key().to_bytes());\n original_leaf.extend_from_slice(&amount.to_le_bytes());\n original_leaf.push(0u8); // isClaimed = false\n\n // Step 2: Verify the Merkle proof against the on-chain root\n let merkle_proof = MerkleProof::new(\n HashingAlgorithm::Keccak,\n 32,\n index as u32,\n hashes.clone(),\n );\n\n let computed_root = merkle_proof\n .merklize(&original_leaf)\n .map_err(|_| AirdropError::InvalidProof)?;\n\n require!(\n computed_root.eq(&airdrop_state.merkle_root),\n AirdropError::InvalidProof\n );\n\n // Step 3: Execute the transfer\n let mint_key = ctx.accounts.mint.key().to_bytes();\n\n let signer_seeds = &[\n b\"merkle_tree\".as_ref(),\n mint_key.as_ref(),\n &[airdrop_state.bump],\n ];\n\n transfer(\n CpiContext::new_with_signer(\n ctx.accounts.token_program.to_account_info(),\n Transfer {\n from: ctx.accounts.vault.to_account_info(),\n to: ctx.accounts.signer_ata.to_account_info(),\n authority: airdrop_state.to_account_info(),\n },\n &[signer_seeds],\n ),\n amount,\n )?;\n\n Ok(())\n}\n\n#[derive(Accounts)]\npub struct Claim<'info> {\n #[account(\n mut,\n has_one = mint,\n seeds = [b\"merkle_tree\".as_ref(), mint.key().to_bytes().as_ref()],\n bump = airdrop_state.bump\n )]\n pub airdrop_state: Account<'info, AirdropState>,\n pub mint: Account<'info, Mint>,\n #[account(\n mut,\n associated_token::mint = mint,\n associated_token::authority = airdrop_state,\n )]\n pub vault: Account<'info, TokenAccount>,\n #[account(\n init_if_needed,\n payer = signer,\n associated_token::mint = mint,\n associated_token::authority = signer,\n )]\n pub signer_ata: Account<'info, TokenAccount>,\n #[account(mut)]\n pub signer: Signer<'info>,\n pub system_program: Program<'info, System>,\n pub token_program: Program<'info, Token>,\n pub associated_token_program: Program<'info, AssociatedToken>,\n}\nTo ensure accuracy, the root is reconstructed from the input provided in the accounts struct and compared against the stored root on-chain to verify they match.Step 3: ClaimingFor simplicity in this example, we won’t implement concurrency. Instead, we present two possible approaches to handle claims:Set the isClaimed flag to true and recompute the Merkle Root on-chain. The main drawback of this approach is that the account will be locked during the update, as explained in theConcurrent Merkle Tree section. This limits claims to one user per block and can be implemented in the same instruction like this after the transfer:Create a Program Derived Address (PDA) for each user after they claim their tokens. This method avoids locking the AirdropState account, but it requires users to pay rent for the new PDA. This can be implemented in the same instruction, we will just need to change the Account struct like this:Note: The user_receipt account can be left empty to reduce rent costs. To further optimize, you can save bytes on the discriminator by assigning the account to the program and passing it as an UncheckedAccount. A require() can then be used to verify ownership of the account, and you would need to add the assign instruction from the system program to assign it to the right program.Full Example CodeHere is the complete example of the Smart Contract for updating the root on-chain after a claim:And here is the corresponding test.ts file with code to implement and test the Merkle tree:","tokens":4243,"squid":"spider-10","role":"Tooling Spider","at":1791345891400,"hash":"ebea6e7b3d761939d904ca266ffc90345ce689b4"}
{"url":"https://developer.arbitrum.io/launch-arbitrum-chain/chain-config/sequencer/pga","domain":"developer.arbitrum.io","title":"PGA for Arbitrum chains","text":"Configure your chainSequencerPGA for Arbitrum chainsGuidance and best practices for using PGA on Arbitrum chainsRequest an updatePriority Gas Auctions (PGA) is an optional that you can enable on any . Under PGA, the orders transactions by the priority fee attached to each one. During short ordering rounds that run several times per block, the Sequencer transfers the priority queue into the block it is building.\nActivating PGA requires enabling tip collection on your chain. Once your chain collects tips, the Sequencer switches to PGA ordering automatically. PGA adds no operational overhead, which makes it viable for a much wider range of chains than .\nYour chain must collect priority fees, which 61 supports. PGA orders transactions by tips.\nAs with all features on the Arbitrum stack, you can adopt PGA at your own discretion and on your own timeline.\nTo learn how PGA works, see the introduction to PGA.\nRecommended adoption path\nConsider PGA for any chain with meaningful competition for block space. These chains are good candidates:\n\nChains with active DeFi, arbitrage, or liquidation activity. PGA converts latency competition into fee competition and routes the proceeds to your chain's fee collector.\nChains with latency-sensitive applications, such as proposer-based automated market makers (propAMMs). Per-transaction, just-in-time bidding suits workloads that need frequent priority-ordered inclusion.\n\nTradeoffs\nCosts\nUnder ordering, arrival time determines the order. Under PGA, willingness to pay determines it. Whenever your chain is congested, the Sequencer orders transactions that pay no priority fee behind those that do. The anti-starvation boost bounds how long they wait, but does not restore parity.\nRevenue\nPGA revenue depends on MEV and competition for ordering. A chain with no congestion collects little in priority fees.\nEnable PGA on your chain\nPrerequisites\nBefore you start, confirm all four of the following:\n\nArbOS 61 or newer. This release supports priority fee collection. PGA orders by tips, so it only activates once your chain collects them. To check what your chain runs and what the release contains, see ArbOS 61 Elara and the ArbOS software releases overview.\n\nPriority fee collection enabled. Collection requires all three of the following:\n\nArbOS 61 or newer\nThe chain's collect-tips flag set\nThe coinbase configured\n\nOn , you toggle collection with an ArbOwner precompile call to setCollectTips. For the call itself, the access-control rules, and a timing caveat that affects the enabling transaction, see priority fees collection. The ArbOwner precompile reference lists every method.\n\nTimeboost disabled. A configuration that enables both Timeboost and PGA behaves unpredictably. To find your current setting, see Timeboost for Arbitrum chains.\n\nA Nitro build that includes PGA. Confirm that the release you run supports it. The ArbOS software releases overview maps Nitro versions to ArbOS versions, and the Nitro support policy tells you which releases are supported.\n\nOverview\nTo enable PGA, complete two steps:\n\nConfigure your Sequencer node's PGA rounds-per-block parameter.\nEnable priority fee collection on your chain, which activates PGA.\n\nStep 1: Configure your Sequencer node for PGA\nAdd the following to your Sequencer's node configuration file:\n{\n \"execution\": {\n \"sequencer\": {\n \"pga\": {\n \"rounds-per-block\": 2\n },\n \"timeboost\": {\n \"enable\": false\n },\n \"max-block-speed\": \"250ms\"\n }\n }\n}\nrounds-per-block is the K parameter. With max-block-speed at 250ms and K=2, ordering rounds are 125ms long.\nStep 2: Enable priority fee collection\nWarningComplete Step 1 before you start Step 2. Enabling tip collection activates PGA immediately, with a default of one round per block.\nVerify that your chain runs ArbOS 61 or newer. If your chain has a toggler contract for tip collection, use it. Otherwise, make an ArbOwner precompile call to setCollectTips.How is this guide?Timeboost for Arbitrum chainsGuidance & best practices for using Timeboost on Arbitrum chainsValidationHow to configure validation for your chain.","tokens":1020,"squid":"spider-01","role":"Chain Spider","at":1791345895089,"hash":"e70d05b65c6875942f3ce374440d714bcb42867e"}
{"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":"spider-08","role":"Oracle Spider","at":1791345903263,"hash":"4f84b78a8d71fbb1e2baa20164cc789548703eaf"}
{"url":"https://gov.optimism.io/t/eden-fractal-epoch-2-implementing-fractal-decision-making-on-the-superchain/9976/35","domain":"gov.optimism.io","title":"Eden Fractal Epoch 2: Implementing Fractal Decision-Making on the Superchain - Updates and Announcements 📢 / Community Calls - Optimism Collective","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 24\n\n 5\n\n 3\n\n 2\n\n read \n\n 28\n min\n\n Jun 2025\n\n 34 / 34\n\n Oct 6\n\n 11h ago\n\n Load more posts above\n\n post by Optimystics on Jan 13\n\n 8 days later\n\n post by DanSingjoy on Jan 22\n\n post by Optimystics on Jan 28\n\n post by Optimystics on Feb 2\n\n 8 days later\n\n post by Optimystics on Feb 11\n\n 1 month later\n\n post by Optimystics on Mar 17\n\n post by Optimystics on Mar 24\n\n 1 month later\n\n post by Optimystics on May 6\n\n 14 days later\n\n post by Optimystics on May 21\n\n 12 days later\n\n post by Optimystics on Jun 2\n\n 14 days later\n\n post by Optimystics on Jun 16\n\n post by MconnectDAO on Jun 18\n\n post by MconnectDAO on Jun 18\n\n 11 days later\n\n post by Optimystics on Jun 30\n\n post by Optimystics on Jun 30\n\n 14 days later\n\n post by Optimystics on Jul 15\n\n 14 days later\n\n post by Optimystics on Jul 29\n\n 1 month later\n\n post by Rosmari on Sep 9\n\n 13 days later\n\n post by Rosmari on Sep 23\n\n Rosmari\n\n Building Next Generation Governance At Eden Fractal Events\nHey friends!\nYou’re invited to join us this Thursday, September 24th, for two Eden Fractal community events. We’ll start with an open discussion at Eden Town Hall at 14 UTC, followed by the Eden Fractal Respect Game at 15 UTC. As we head into our second events of the new season, we’re both excited and grateful to be on this journey with you all.\nimage1280×720 316 KB\nAt Eden Town Hall, we’ll continue the Season 13 discussion and explore plans to advance Eden Fractal’s mission over the coming months. The floor is open to thoughts and questions about Eden Fractal and the wider fractal ecosystem. It was wonderful getting reconvening with the community at our season debut and we’re looking forward to continuing the conversations on Thursday. This is also the event where the Eden+Fractal Council meet and consider proposals for formal approval.\nThe Eden Fractal Respect Game provides an opportunity to share your recent contributions, hear what others have been working on, and collaborate with experienced innovators in the ecosystem. This community ritual recognizes contributions to Eden Fractal’s mission of implementing fractal decision-making processes throughout society. As always, participants can earn Respect for their work and gain influence in the community as we recognize each other’s progress.\nThese events build upon more than four years of collaboration and twelve completed seasons of exploring better ways to make collective decisions. Season 13 is about putting more of that work into practice. The conversations and work we’ll share during this week’s events will help us scale our initiatives, create lasting impact, and ultimately build better coordination systems for all. As many of you know, big change often starts with a small group of thoughtful, committed builders… and we’re making great progress in developing mechanisms that will support contributions towards all kinds of great causes!\nWhether you’re new to fractal governance or a longtime participant, you’re very welcome to join us. As always, you can find the links to this week’s events and RSVP on the Eden Creators events calendar, which also holds the zoom room link, and you can learn more at EdenFractal.com. We look forward to seeing you on tomorrow \n\n 13 days later\n\n post by Rosmari 11 hours ago\n\n Rosmari\n\n Step into October with us this Thursday at Eden Fractal \nHi all,\nHope you’re all doing well and enjoying the weather wherever this message finds you \nYou’re warmly invited to join us this Thursday for Eden Town Hall at 14 UTC and the Eden Fractal Respect Game at 15 UTC!\nimage1280×720 604 KB\nFirst we’ll catch up at the Eden Town Hall, where we’ll continue the Season 13 discussion and explore plans to advance Eden Fractal’s mission over the coming months. The floor is open to thoughts and questions about Eden Fractal and the wider fractal ecosystem, as well as brainstorming on what the community inspires to achieve this season. The Eden+Fractal council meets during this Town Hall, so we can approve any proposals then, if that would be helpful.\nAt 15 UTC, we’ll play the beloved Respect Game - the core ritual at the heart of our community. This is a great opportunity to connect with governance innovators, contribute to the fractal ecosystem, and earn Respect for supporting Eden Fractal’s mission of implementing fractal decision-making processes throughout society. It’s a wonderful chance to meet new and familiar faces, see what everyone’s been up to, as well as gain understanding & practice in implementing fractal governance processes.\nWhether you’re new to fractal governance or a longtime participant, you’re very welcome to join us. Feel free to share any Eden Fractal-related discussions in the Telegram group. We’d love to hear from you! As always, you can RSVP on the Eden Creators events calendar, which includes a link to the zoom room.\nLooking forward to seeing you there,\n\n Related topics\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 Fractal Season 5: Level Up with Weekly Respect Games on the Superchain\n\n ✨ General\n\n Welcome to Season 5 of Optimism Fractal!\nAfter an incredible first year bringing builders together through innovative onchain social games, we’re excited to begin our next chapter with powerful new tools and growing mome…\n\n read more\n\n 33\n\n 788\n\n Jul 2025\n\n Optimism Fractal Season 6: Expanding Democratic Coordination Across the Superchain\n\n Community Calls\n\n Welcome to Season 6 of Optimism Fractal!\nAfter an exceptional journey of fostering collaboration through innovative onchain social in our first five seasons, we’re excited to embark on a new chapter with enhanced tools a…\n\n read more\n\n 18\n\n 863\n\n Jan 21\n\n Optimism Fractal Weekly Events\n\n Community Calls\n\n Hey Optimists! \nYou’re invited to join Optimism Fractal events on Mondays at 17 UTC \nOptimism Fractal is a community dedicated to fostering collaboration and awarding public goods creators on Optim…\n\n read more\n\n 15\n\n 1.6k\n\n Apr 2024\n\n Optimism Fractal Season 4\n\n Community Calls\n\n Dear Optimists, \nOptimism Fractal is returning from summer break and we’re excited to embark on Season 4! We’re looking forward to reconnecting at our weekly events and invite you to join! \nOptimism Fractal events kick o…\n\n read more\n\n 21\n\n 458\n\n Nov 2024\n\n Optimism Fractal Season 3\n\n Community Calls\n\n Hey friends! Join us for the first event of Optimism Fractal Season 3! \nWe’re excited to start the season in style with a Respect Game to grow Optimism, then discuss a new proposal in today’s planning session…\n\n read more\n\n 19\n\n 1.3k\n\n Jul 2024","tokens":1657,"squid":"spider-07","role":"Council Spider","at":1791345909707,"hash":"6e081b1bdc8bff6a3dfd3b89a6ae0d9a3c9ffc03"}
{"url":"https://www.metaplex.com/docs/solana/rpcs-and-das","domain":"metaplex.com","title":"RPCs, DAS, and RPC Providers on Solana | Guides","text":"Learn about RPCs on Solana, how Metaplex DAS standardizes digital asset reads, and find the right RPC provider for your project. Roles of an RPC on the Solana BlockchainRemote Procedure Calls (RPCs) are a crucial part of the Solana blockchain infrastructure. They serve as the bridge between users (or applications) and the blockchain, facilitating interactions and data retrieval.Solana uses independent nodes responsible for confirming programs and outputs across its clusters (Devnet, Testnet, Mainnet Beta). Not all nodes can vote on blocks — those that can't are primarily used to respond to requests. These are RPC nodes, used to send transactions through the blockchain.Solana maintains three public API nodes (one per cluster). For example, the Devnet endpoint is:https://api.devnet.solana.com\nThese public endpoints are rate-limited. On Mainnet Beta, many developers use a private RPC provider for higher rate limits.Key Roles of an RPCFacilitating Network Communication: RPC servers handle requests from clients (users or applications) and interact with the blockchain to fulfill those requests. They provide a standardized way for external entities to communicate with the blockchain without running a full node.Submitting Transactions: RPCs enable clients to submit transactions to the Solana blockchain. When a user wants to perform an action such as transferring tokens or invoking a smart contract, the transaction is sent to an RPC server, which propagates it to the network.Retrieving Blockchain Data: RPC servers allow clients to query the blockchain for various types of data, including:Account Information: balance, token holdings, and other metadata for a specific account.Transaction History: historical transactions associated with an account or transaction signature.Block Information: block height, block hash, and transactions included in a block.Program Logs: logs and output from executed programs (smart contracts).Monitoring Network Status: RPCs provide endpoints to check the status of the network, such as node health, network latency, and synchronization status.Supporting Development and Debugging: RPC endpoints allow developers to simulate transactions, fetch program accounts, and retrieve detailed logs for debugging.Common RPC MethodsMethodDescriptiongetBalanceRetrieves the balance of a specified accountsendTransactionSubmits a transaction to the networkgetTransactionFetches details about a transaction by signaturegetBlockRetrieves block information by slot numbersimulateTransactionSimulates a transaction without executing itExample Usage# Get the balance of an account\ncurl https://api.mainnet-beta.solana.com -X POST \\\n -H \"Content-Type: application/json\" \\\n -d '{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"getBalance\",\"params\":[\"7C4jsPZpht42Tw6MjXWF56Q5RQUocjBBmciEjDa8HRtp\"]}'\n\n# Simulate a transaction\ncurl https://api.mainnet-beta.solana.com -X POST \\\n -H \"Content-Type: application/json\" \\\n -d '{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"simulateTransaction\",\"params\":[\"<base64-encoded-tx>\"]}'\nMetaplex DASMetaplex DAS (Digital Asset Standard) is a protocol designed to standardize the read layer for NFTs and tokens on Solana. It allows developers to use a consistent interface when fetching different standards and layouts of digital assets.Indexing Digital AssetsBy indexing all digital assets (NFTs and tokens), DAS provides much faster data reads since the information is stored in an optimized database rather than fetched directly from the blockchain.SyncingDAS syncs by watching lifecycle instructions sent to the blockchain — create, update, burn, and transfer. This ensures the indexed data is always up to date.Currently Core, Token Metadata, and Bubblegum are all indexed by DAS.DAS and RPCsRPCs and DAS complement each other. Standard RPCs provide direct access to on-chain data, while DAS offers an optimized indexed layer specifically for digital assets. For developers, the DAS API is required to interact with compressed NFTs (cNFTs), and it also makes working with Token Metadata assets easier and faster. We strongly recommend using RPC nodes with DAS support for the best user experience.To learn more:Metaplex DAS APIMetaplex DAS API GitHubMetaplex Digital Asset RPC Infrastructure GitHubArchive and Non-Archive NodesArchive nodes store the full history of all previous blocks. This allows you to view an address's balance history and inspect any historical state. Due to the high system requirements, having access to a private archive node is highly beneficial.Non-archive nodes (regular nodes) only retain around the last 100 blocks. Even non-archive nodes can be resource-intensive to manage, which is why many developers choose a private RPC provider — especially for Mainnet Beta where real SOL is involved and rate limits are stricter.RPC ProvidersThese lists are in alphabetical order. Choose the provider that best suits your project's needs. If we are missing a provider, let us know on Discord or submit a PR.RPCs with DAS SupportExtrnodeHeliusHello MoonQuickNodeShyftTritonRPCs without DAS SupportAlchemyAnkrBlockdaemonChainstackFigmentGetBlockNOWNodesSyndica","tokens":1281,"squid":"dotcat","role":"Tooling Spider","at":1791345915717,"hash":"658af6ba7c0f811779e9c923add4f2272782dbf7"}
{"url":"https://gov.optimism.io/c/updates-and-announcements/55-category/55","domain":"gov.optimism.io","title":"Latest Updates and Announcements 📢/Community Calls topics - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n Latest topics in Community Calls\n\n Updates and Announcements 📢\n\n Community Calls\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 Community Calls category\n\n 2\n\n 654\n\n Sep 2023\n\n Eden Fractal Epoch 2: Implementing Fractal Decision-Making on the Superchain\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 33\n\n 711\n\n 11h\n\n Optimism Fractal Season 6: Expanding Democratic Coordination Across the Superchain\n\n Welcome to Season 6 of Optimism Fractal!\nAfter an exceptional journey of fostering collaboration through innovative onchain social in our first five seasons, we’re excited to embark on a new chapter with enhanced tools a…\n\n read more\n\n 18\n\n 863\n\n Jan 21\n\n Optimism Town Hall Season 4: Growing the Superchain Through Collaborative Governance\n\n Welcome Back to Optimism Town Hall! After a refreshing six-week spring break, we’re excited to announce the return of Optimism Town Hall for its fourth season, beginning today, May 15th! \nThis thread serves as your centr…\n\n read more\n\n 8\n\n 255\n\n Nov 2025\n\n [Recording & Recap] 22nd OP Community Governance Call\n\n Hey Optimists! \nRecording Link: June 20th, 2023 community call.mp4 - Google Drive \nGreat call with a lot of discussion, here are some of the highlights: \n\nKYC for Grants:\n\nIn the case of a single grant recipient, the own…\n\n read more\n\n 6\n\n 1.6k\n\n Sep 2025\n\n Joint House Community Calls Summaries - Season 7\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 Joint House Community Call July 15th\n\n Hello Optimism Governance Fam! \nOur next Joint House Community Call will be held on July 15th. \nThe budget board will be joining us to discuss their latest proposals. This call will not be recorded \n@SEEDGov has posted a…\n\n read more\n\n 0\n\n 93\n\n Jul 2025\n\n Joint House Community Call June 17th\n\n Hello Optimism Governance Fam! \nOur next Joint House Community Call will be held on June 17th. \nThe Foundation will be joining us to present on Season 8 and then do a Q&A. \nLink for the call can be found on the Optimism …\n\n read more\n\n 1\n\n 75\n\n Jun 2025\n\n Joint House Community Call [May 20th 18:00 UTC]\n\n Hello Optimism Governance Fam. We are shifting to hosting one Community Call each month. This will be the Joint House Community Call. \n Our next Joint House Community Call will be held on May 20th. \n…\n\n read more\n\n 4\n\n 192\n\n May 2025\n\n Joint House Community Call [April 22nd 18:00 UTC]\n\n Joint House Community Call (April 22nd 18:00 UTC) \nWhat up Optimism gov fam. Our Token House community call will be today (April 22nd 18:00 UTC). Call is open to the entire community and everyone is welcome to join as al…\n\n read more\n\n 0\n\n 61\n\n Apr 2025\n\n Token House Community Call [April 8th 18:00 UTC]\n\n Token House Community Call (April 8th at 18:00 UTC) \nWhat up Optimism gov fam. Our Token House community call will be today (April 8th at 18:00 UTC). Call is open to the entire community and everyone is welcome to join a…\n\n read more\n\n 0\n\n 66\n\n Apr 2025\n\n Joint House Call [March 25th 19:00 UTC]\n\n Today we have our Joint House Community Call at 19:00 UTC. \nThis call is open to anyone in the community to join and get the latest updates on Optimism governance and dive into some discussion topics \nTopics: \n\nUpdates\nF…\n\n read more\n\n 0\n\n 74\n\n Mar 2025\n\n govNERDs Community Check-ins\n\n season-7\n\n Hi there, \nJust to share that, as ‘core @govNERDs’, we will be facilitating a biweekly meeting for all those people who would like to get more involved in the govNERD contribution path. \nWe wil…\n\n read more\n\n 5\n\n 205\n\n Mar 2025\n\n Token House Call [March 11th 19:00 UTC]\n\n **gm Optimism Governance Fam! Today we have our Token House Community Call \nTopics: \n\nUpgrade Proposal #13: OPCM and Incident Response improvements\nAllow the Optimism Foundation to Stake a Portion of Sequencer ETH Throug…\n\n read more\n\n 0\n\n 74\n\n Mar 2025\n\n Joint House Call [February 25th 19:00 UTC]\n\n gm Optimism Governance Fam! Today we have our joint house call (Token House + Citizens) open to all community members! \nTopics: \n\nOverview of the The Decision Market Experiment (kicks off this week)\nEmily from the Founda…\n\n read more\n\n 4\n\n 148\n\n Mar 2025\n\n Token House Governance Call [February 11th 19:00 UTC]\n\n gm Optimism Governance Family! \nTopics for today include: \n\nSeason 7 Guest Voter Eligibility\nStarting Feb 12th, Onchain Builders can apply for Retro Funding here: https://atlas.optimism.io/\n\nCommunity Call Slides: \n\nComm…\n\n read more\n\n 3\n\n 144\n\n Feb 2025\n\n Token House Call will be [Tuesday, March 12 @ 11:00 PT / 14:00 ET / 18:00 GMT / 19:00 CET]\n\n Hello Optimists! \nCome join us for our bi-weekly token house call where we discuss all things Token House governance! \nFeel free to comment below on any topics you’d like covered. \nZoom link: Launch Meeting - Zoom \nMich…\n\n read more\n\n 3\n\n 833\n\n Feb 2025\n\n Joint House Community Call [January 28th 14:00 ET, 19:00 UTC, 20:00 CET]\n\n gm, governance fam. Our second governance call of the year is scheduled for today, January 28th. \nWith Season 7 governance elections now wrapped up we will be covering what is to come in season 7 and Jonas will provide u…\n\n read more\n\n 3\n\n 133\n\n Jan 2025\n\n Optimism Community Call Recaps & Recordings Thread\n\n Hi Optimists! \nI am creating this thread as a central location to contain all of our community call recordings and recaps. The goal is for people to be able to review past community calls more easily. And see the things …\n\n read more\n\n 63\n\n 7.2k\n\n Jan 2025\n\n Token House Governance Call will be [January 14th, 14:00 ET, 19:00 UTC, 20:00 CET]\n\n season-7\n\n Happy new year, Optimists! \nOur first governance call of the year is scheduled for this Tuesday, January 14th. \nWe have a jam-packed election week happening right now so make sure to get those votes in! \nWe will be discu…\n\n read more\n\n 0\n\n 77\n\n Jan 2025\n\n Token House Community Call will be December 17th, 14:00 ET - 19:00 UTC - 20:00 CET\n\n Hello Optimists! \nWe will have our community call Tuesday, December 17th! \nIf there are any last minute things you specifically would like to cover let me know. \nMeet link: https://meet.google.com/vme-ovto-jcn \n\nSee yo…\n\n read more\n\n 1\n\n 85\n\n Dec 2024\n\n Season 7 Intents AMA with Jing and Karl! [11:00 PST, 14:00 EST, 19:00 UTC]\n\n season-7\n\n Hey all, \nJing and Karl will be joining us for an AMA the Season 7 intents this Tuesday in place of our normal Joint House call. \nRead some of the docs before hand in order to have questions ready! \n\nGoogle meet link: \n\nS…\n\n read more\n\n 3\n\n 177\n\n Dec 2024\n\n Optimism Fractal Season 4\n\n Dear Optimists, \nOptimism Fractal is returning from summer break and we’re excited to embark on Season 4! We’re looking forward to reconnecting at our weekly events and invite you to join! \nOptimism Fractal events kick o…\n\n read more\n\n 21\n\n 458\n\n Nov 2024\n\n Joint House Call will be [Tuesday, November 5th @ 11:00 PT / 14:00 ET / 19:00 GMT / 20:00 CET]\n\n season-6\n\n Hey Everyone! \nJoin us for our Joint House call this Tuesday! \nTime changes in USA/Europe may make this call a different time than normal for you, so make sure to check the official governance calendar. \nSee you there! \n …\n\n read more\n\n 0\n\n 74\n\n Nov 2024\n\n Token House Call will be [Tuesday, October 22nd @ 11:00 PT / 14:00 ET / 18:00 GMT / 20:00 CET]\n\n season-6\n\n Hello Token House! \nWe will be having our next call on Tuesday, October 22nd. \n@ben-chain will be joining to discuss blockspace charters, including some new updates to the standard charter. \nWe also…\n\n read more\n\n 0\n\n 69\n\n Oct 2024\n\n Token House Call will be [Tuesday, September 24th @ 11:00 PT / 14:00 ET / 18:00 GMT / 20:00 CET]\n\n season-6\n\n Hey Optimists! \nWe will have our token house call this coming Tuesday. Comment below if you’d like to discuss and topics in particular. \nGoogle meet: https://meet.google.com/vme-ovto-jcn \n\nSee you then! \nMichael …\n\n read more\n\n 0\n\n 80\n\n Sep 2024\n\n Costa Rica OP DAY\n\n season-5\n\n OPtimism Governance Day: Spreading Optimism in Costa Rica\nFebruary 15th, 2024 marked a special day for the Optimism community in Costa Rica, as InBest hosted our first ever OP Day event. The event, themed around love and…\n\n read more\n\n 33\n\n 1.8k\n\n Sep 2024\n\n Joint House Call will be [Tuesday, September 10th @ 11:00PT / 14:00 ET / 18:00 GMT / 19:00 CET]\n\n season-6\n\n Hello Optimists! Come join us for our monthly joint-house call where we discuss all things Optimism governance! \nWe are kicking off RF5 among other topics. Hope to see you there! \nMeeting link: https://meet.google.com/vm…\n\n read more\n\n 0\n\n 91\n\n Sep 2024\n\n Token House Call will be [Tuesday, August 27th @ 11:00PT / 14:00 ET / 18:00 GMT / 19:00 CET]\n\n Hey Optimists! \nOur token house call will be next Tuesday, August 27th. \nmeeting link: https://meet.google.com/vme-ovto-jcn \nSee you there! \nMichael\n\n 0\n\n 68\n\n Aug 2024\n\n Joint House Call *Retrofunding 5 Edition* will be [Tuesday, August 13th @ 11:00PT / 14:00 ET / 18:00 GMT / 19:00 CET]\n\n season-6\n\n Hey Everyone! \nWe will be having our next Joint House call on Tuesday where the wonderful @Jonas will be giving an overview of Retrofunding Round 5! \n\nSee you there! \nhttps://meet.google.com/vme-ovto-jcn \nMichael\n\n 0\n\n 77\n\n Aug 2024","tokens":2404,"squid":"spider-07","role":"Council Spider","at":1791345920854,"hash":"0589a4509336ee866d4c5f0f9d3ec1e080e1b97a"}
{"url":"https://akash.network/docs/providers/setup-and-installation/kubespray","domain":"akash.network","title":"Kubespray Setup | Akash Network - Your Guide to Decentralized Cloud","text":"Kubespray Setup Complete control over your Akash provider setup with production-grade Kubernetes.\nKubespray provides a manual, step-by-step approach to deploying an Akash provider, giving you full control and customization over every component. Ideal for advanced users who need specific configurations or want to deeply understand the infrastructure.\nSetup Time: 1-2 hours\n\nWhat is Kubespray?\nKubespray is a composition of Ansible playbooks, inventory, provisioning tools, and domain knowledge for deploying production-ready Kubernetes clusters. For Akash providers, we use:\n\nKubespray 2.31.0 - Pinned release used by Provider Playbook\nKubernetes 1.35.4 - Officially supported version\netcd 3.6.10 - Distributed key-value store\ncontainerd 2.2.3 - Container runtime\nCalico 3.31.5 - Container Network Interface (CNI)\n\nWhy Choose Kubespray?\nAdvantages\n\nFull control - Customize every aspect of your setup\nProduction-grade - Battle-tested for large deployments\nDeep understanding - Learn exactly how components work together\nMaximum flexibility - Adapt to your specific infrastructure needs\nCustom configurations - Fine-tune network, storage, and security\nReproducible - Infrastructure as Code approach\n\nConsiderations\n\nRequires Kubernetes knowledge - Must understand K8s concepts\nMore manual steps - Less automated than Provider Playbook\nCommand-line focused - Terminal-based setup\nOngoing maintenance - Manual updates and configuration changes\n\nPrerequisites\nRequired Knowledge\n\nLinux administration - Comfortable with command line and SSH\nKubernetes fundamentals - Understand pods, deployments, services, namespaces\nNetworking basics - IP addressing, DNS, firewalls, routing\nAnsible basics - Understand playbook concepts (helpful but not required)\n\nHardware & System Requirements\nSee Hardware Requirements for complete specifications including CPU, RAM, storage, network, and GPU requirements.\n\nSetup Process Overview\nThe Kubespray setup is divided into distinct steps:\nPhase 1: Kubernetes foundation (Required)\n1. Kubernetes Cluster Setup\n\nClone Kubespray repository\nConfigure inventory and variables\nDeploy Kubernetes cluster with Ansible\nVerify cluster health\n\nPhase 2: Provider capabilities (Optional)\nAdd advanced capabilities based on your hardware and business needs:\n2. GPU Support\n\nDeploy NVIDIA GPU Operator\nConfigure CDI and the container runtime\nConfigure GPU attributes\nTest GPU workloads\n\n3. Persistent Storage\n\nDeploy Rook-Ceph operator\nConfigure OSD devices\nCreate storage classes (beta1/beta2/beta3)\nTest persistent volumes\n\nInstall GPU and storage before rendering the provider configuration so its advertised attributes match the available cluster capabilities.\nPhase 3: Provider installation (Required)\n4. Provider installation (two parts)\n\nProvider installation (prep) — wallet, provider.yaml, DNS, NGF, and Let’s Encrypt (steps 1–9)\nProvider installation (install) — akash-gateway, operators, and helm install for the Akash provider\nVerify the provider is running\n\nPhase 4: Additional features (Optional)\n5. IP Leases\n\nConfigure an IP address pool\nDeploy the MetalLB load balancer\nEnable the IP lease operator\nTest static IP assignment\n\nRecommended Setup Approach\nStart Simple, Add Complexity\nStep 1: Install the provider stack\n\nDeploy Kubernetes cluster (Kubespray)\nEnable GPU support if the provider has NVIDIA GPUs\nConfigure persistent storage if the provider will advertise it\nInstall the provider software with the resulting attributes\nTest with a simple deployment\nVerify the provider shows up on network\n\nGoal: Prove your infrastructure works\n\nStep 2: Add more capabilities\n\nSet up IP leases if you have extra public IPs\n\nGoal: Maximize earning potential\n\nStep 3: Optimize & Scale\n\nFine-tune pricing based on market\nMonitor metrics and performance\nAdd capacity as needed\nAutomate maintenance tasks\n\nGoal: Maximize profitability and uptime\n\nTime Estimates\nFirst-Time Setup\n\nKubernetes cluster: 30-45 minutes\nProvider installation: 30-45 minutes\nConfiguration & testing: 15-30 minutes\nTotal: ~1-2 hours\n\nOptional Features\n\nGPU support: 30-60 minutes\nPersistent storage: 45-90 minutes (depending on complexity)\nIP leases: 30-45 minutes\n\nExperienced Operators\n\nFull setup: 45-60 minutes\nWith automation: 20-30 minutes\n\nNote: Times assume you have hardware ready, DNS configured, and have done this before. First-time setup may take longer due to learning curve.\n\nKubespray vs Provider Playbook\nThe manual path always uses Kubespray. Provider Playbook can build with Kubespray or K3s, or install onto an existing Kubernetes cluster:\n\nFeatureKubespray (This Guide)Provider PlaybookAutomationManual stepsInteractive scriptControlFull controlGuided configurationTime1-2 hours~1 hourSkill LevelAdvancedIntermediateCustomizationMaximumStandard optionsBest ForCustom setups, learningQuick deployment\nUse Kubespray when you:\n\nNeed specific Kubernetes configurations\nWant to understand every component\nHave custom networking requirements\nAre integrating with existing infrastructure\nNeed fine-grained control over resources\n\nUse Provider Playbook when you:\n\nWant the fastest setup\nPrefer guided configuration\nAre setting up a standard provider\nDon’t need custom Kubernetes settings\n\nWhat Makes This “Advanced”?\nUnlike Provider Playbook’s automated script, the Kubespray method requires you to:\n\nManually configure inventory files - Define your nodes and variables\nUnderstand Ansible concepts - Know what playbooks are doing\nManually run each step - Execute commands in the right order\nTroubleshoot issues - Debug problems without a script\nCustomize configurations - Edit YAML files for specific needs\nManage updates - Manually apply upgrades and patches\n\nHowever, you gain:\n\nDeep understanding of the infrastructure\nAbility to customize anything\nFine-grained control over security\nFlexibility for unique requirements\nTransferable Kubernetes knowledge\n\nAlternative Setup Methods\nNot sure Kubespray is right for you?\nProvider Playbook →\n\nInteractive wizard for Kubespray, K3s, or an existing cluster\nAutomated detection and validated configuration\nRecommended for most users\nTime: ~1 hour\n\nProvider Console →\n\nWeb-based setup with no K8s knowledge required\nFully managed Kubernetes\nBest for beginners\nTime: 15-30 minutes\n\nGetting Help\nBefore You Start\n\nReview Hardware Requirements\nRead Should I Run a Provider?\nCalculate earnings with Provider Calculator\n\nDuring Setup\n\nDiscord: discord.akash.network - #providers channel\nKubespray Docs: kubespray.io\n\nAfter Setup\n\nOperations Guide → - Managing your provider\nProvider Verification → - Verify your setup\n\nReady to Begin?\nStart with the Kubernetes cluster setup:\n→ Kubernetes Setup Guide\nThis will walk you through deploying a production-grade Kubernetes cluster using Kubespray 2.31.0. \nEdit page on github\n Hardware Requirements Kubernetes Setup","tokens":1702,"squid":"spider-03","role":"Compute Spider","at":1791345922847,"hash":"133c4d7a71d90c13681e20baf9e3209f97258380"}
{"url":"https://www.metaplex.com/docs/solana/what-is-solana","domain":"metaplex.com","title":"What is Solana? | Guides","text":"Solana OverviewThe Solana blockchain is a high-performance, decentralized blockchain platform designed to enable scalable and user-friendly applications. Launched in 2020 by Solana Labs, Solana aims to address the limitations of earlier blockchain networks such as Bitcoin and Ethereum, particularly in terms of scalability, speed, and cost.Key Features and InnovationsHigh Throughput: Solana can process thousands of transactions per second (TPS), significantly higher than many other blockchain platforms. This high throughput is achieved through its unique architecture and consensus mechanisms.Proof of History (PoH): Solana introduces Proof of History, a novel timestamping method that orders transactions and events cryptographically. PoH reduces the workload of the consensus algorithm, allowing for greater scalability and efficiency.Tower BFT (Byzantine Fault Tolerance): Solana uses a variation of Practical Byzantine Fault Tolerance (PBFT) called Tower BFT. This consensus mechanism is optimized for PoH and ensures the security and reliability of the network.Sealevel: Solana features Sealevel, a parallel smart contract runtime that allows it to process thousands of smart contracts simultaneously. This enables greater performance and scalability for decentralized applications (dApps).Gulf Stream: Solana employs Gulf Stream, a transaction forwarding protocol that significantly reduces confirmation times and improves the overall network throughput by enabling validators to execute transactions ahead of time.Pipeline and Turbine: Pipeline and Turbine are mechanisms for data propagation and processing. Pipeline improves transaction validation efficiency, while Turbine is a block propagation protocol that enhances the speed and reliability of data transmission across the network.Low Costs: Solana offers low transaction fees, making it an attractive option for developers and users looking to build and interact with dApps and DeFi platforms without the high costs associated with other blockchains.Solana EcosystemSolana has grown into a vibrant ecosystem that supports a wide range of applications and use cases:DeFi (Decentralized Finance): Solana hosts numerous DeFi protocols including decentralized exchanges (DEXs), lending platforms, yield farming applications, and stablecoin projects that leverage its high throughput and low fees.NFTs and Digital Collectibles: The platform has become a major hub for NFT marketplaces and collections due to its ability to handle high-volume minting and trading at a fraction of the cost of other chains.Web3 Gaming: Game developers are increasingly building on Solana to create on-chain gaming experiences that benefit from fast transaction confirmations and affordable gas fees.Payments and Commerce: Solana's speed makes it suitable for payment applications that require near-instant settlements, enabling efficient point-of-sale systems and e-commerce solutions.DAOs (Decentralized Autonomous Organizations): Many communities have established governance structures on Solana, taking advantage of its efficient voting mechanisms and token management capabilities.Why Build on Solana?Developers choose Solana for several compelling reasons:Performance at Scale: Applications can serve millions of users without performance degradationCost Efficiency: Low transaction fees enable micro-transactions and frequent user interactionsDeveloper Tooling: Rich ecosystem of SDKs, frameworks, and educational resourcesComposability: Easy integration with other protocols and applications in the ecosystemSustainability: Lower energy consumption compared to Proof of Work blockchainsGrowing User Base: Access to a rapidly expanding community of users and developers","tokens":930,"squid":"dotcat","role":"Tooling Spider","at":1791345927093,"hash":"c4937a76e26ca9d6812f4191fc3428f399bab33f"}
{"url":"https://gov.optimism.io/t/optimism-fractal-season-6-expanding-democratic-coordination-across-the-superchain/9924/1","domain":"gov.optimism.io","title":"Optimism Fractal Season 6: Expanding Democratic Coordination Across the Superchain - Updates and Announcements 📢 / Community Calls - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n Optimism Fractal Season 6: Expanding Democratic Coordination Across the Superchain \n\n Updates and Announcements 📢Community Calls\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 9\n\n 7\n\n 3\n\n read \n\n 19\n min\n\n May 2025\n\n 1 / 19\n\n May 2025\n\n Jan 21\n\n post by Optimystics on May 15, 2025\n\n Optimystics\n\n Welcome to Season 6 of Optimism Fractal!\nAfter an exceptional journey of fostering collaboration through innovative onchain social in our first five seasons, we’re excited to embark on a new chapter with enhanced tools and strengthened community bonds across the Superchain ecosystem \nOptimism Fractal continues its mission of fostering collaboration, awarding public goods creators, and optimizing governance on the Superchain. Through our weekly Respect Game events, we create an engaging platform where builders showcase their work, form meaningful connections with fellow innovators, and earn Respect tokens — the foundation of our reputation-based democratic coordination system.\nSince 2023, our community has brought together over 75 builders creating transformative solutions for Optimism, catalyzing countless collaborations while pioneering powerful frameworks for impact recognition and collective decision-making. We invite you to join this thriving ecosystem as we expand our reach across the Superchain!\nimage1456×816 154 KB\nWeekly Events\nJoin us every other Thursday at 17:00 UTC starting today to play the Respect Game where you can:\n\nShare your contributions to Optimism and the Superchain\nNetwork with innovative builders across multiple ecosystems\nPresent your projects in supportive breakout rooms\nEarn Respect through peer evaluation and consensus\nParticipate in our interactive, gameshow-style events\n\nWhether you’re actively building on the Superchain or just beginning your journey, our events provide valuable opportunities for networking, learning, and amplifying your impact. We welcome builders of all experience levels and encourage you to invite friends who could benefit from our supportive community.\nRSVP here to join our next event!\nSeason 5 Highlights\nLooking back at our achievements from the previous season:\n\nCompleted 60+ Events and Videos: We’ve now hosted 60 Respect Game events since our inception, producing an extensive library of educational content showcasing Superchain builders and governance innovations.\nORDAO Implementation: Successfully launched our optimistic governance smart contract infrastructure, allowing community-driven onchain execution through truly democratic processes based on earned reputation in our prior seasons.\nDemocratic Fund Distribution Research: @DanSingjoy is continuing to deliver research on democratic fund distribution using Respect tokens and fractal structures, creating blueprints for effective funding allocation that benefits the Optimism Collective and broader Superchain.\nETHDenver and In-Person Expansion: For the first time, we brought the Respect Game to physical events, hosting live sessions at ETHDenver that demonstrated the adaptability of our coordination frameworks.\nCross-Community Adoption: Witnessed growing implementation of the Respect Game across communities like ZAO Fractal, which is approaching its one-year anniversary of using our coordination mechanisms.\n\nExplore more in our Season 5 forum thread for videos and insights from previous events!\nLooking Ahead to Season 6\nThis season brings several exciting developments:\n\nORDAO Front-End Deployment: @Tadas is launching a comprehensive front-end interface for ORDAO in the coming weeks, making it significantly more intuitive for community members to submit proposals for onchain actions, distribute Respect, and participate in governance.\nEnhanced Fractalgram Interface: After building many important features for playing the Respect Game in Season 5, @Father-abraham is planning to improve the Fractalgram interface to work seamlessly with any ORDAO implementation, making it easier for different communities to adopt our coordination tools.\nSuperchain ORDAO: @Jacobhomanics is developing Superchain ORDAO as part of the Superchain Interop Incubator program, making our smart contracts for Respect distribution, reputation, and governance interoperable across the Superchain.\nMobile-Compatible Interfaces: Initial testing of the Fractalgram app showed promising results for mobile accessibility, significantly lowering barriers to participation in governance processes.\nCross-Superchain Collaboration: Expanding outreach to communities across Base, Zora, Unichain, World Chain, and other Superchain networks to provide a unified collaborative space for builders throughout the ecosystem.\n\nRelated Initiatives\nFollowing Optimism Fractal Respect Games, community members are welcome to join Optimism Town Hall at 18:00 UTC, now entering its fourth season. This complementary forum for governance discussions provides another avenue for engagement with the Optimism ecosystem. You can explore the Season 3 thread for detailed discussions and insights from previous events.\nEden Fractal hosts bi-weekly events on alternating Thursdays at 17:00 UTC focused on advancing coordination tools and processes. Entering Epoch 2 and preparing for its 3 year anniversary, Eden Fractal will deploy ORDAO on Base with over 75 contributors eligible to claim their Respect tokens. This initiative will test the fund distribution system outlined in our research, providing valuable insights for Optimism Fractal’s future development.\nThe ORDAO Office Hours playlist now features eight recorded sessions where community members can learn about the technical infrastructure powering our governance systems. These sessions pave the way for the upcoming launch of ORDAO Fractal, a community space where contributors earn Respect by supporting ORDAO development.\nEveryone is welcome to join all of these events to contribute to the broader ecosystem and pioneer new forms of governance on the Superchain. Subscribe to the Optimystics Events Calendar to stay informed, track upcoming events, and receive email reminders for all these activities.\nGetting Involved & Resources\nOptimism Fractal continues as a pioneering community doing crucial work to help the Collective achieve its vision—from attracting builders and fostering collaboration to pioneering democratic coordination at scale. We welcome engagement in various forms:\n\nExplore our community: OptimismFractal.com\nSubscribe for all videos: Eden Creators Youtube channel\nWatch past Optimism Fractal events: Videos and Show Notes\nLearn the Respect Game: Introductory article\nJoin discussions: Community Discord, X profile, and Farcaster channel\nBrowse coordination tools: Optimystics Toolkit\nExplore Fractal Democracy: Article\nSee protocol specs: Core Intents\nPrevious Optimism Fractal season threads: Season 2 | Season 3 | Season 4 | Season 5\n\nThis thread will serve as a central place for event invitations, recordings, and key updates throughout Season 6. We appreciate all forms of support in making Optimism Fractal as valuable as possible for the entire Superchain ecosystem.\nFeel free to share any questions or thoughts below. We look forward to seeing you at our events as we work together to build the future of the internet \n\n Optimism Fractal Season 5: Level Up with Weekly Respect Games on the Superchain\n\n Optimism Fractal Respect Game: Research into Democratic Fund Distribution\n\n Optimism Town Hall Season 4: Growing the Superchain Through Collaborative Governance\n\n 9\n\n 7\n\n 3\n\n read \n\n 19\n min\n\n post by DanSingjoy on May 15, 2025\n\n DanSingjoy\n\n Hey Optimists!\nI’m thrilled to welcome everyone back for the launch of Optimism Fractal Season 6 today, May 15th at 17 UTC! After our refreshing month-long break, I can’t wait to reconnect with all of you, play the Respect Game together, and hear what everyone’s been up to.\nOver the past seasons, we’ve built something truly special together. From our amazing community of dedicated contributors to the significant improvements in our software and educational resources, we’ve created solid foundations that position us to make this our most impactful season yet. I’m deeply grateful for everyone’s contributions so far and stoked about what we’ll accomplish together in this new season.\nAfter the Optimism Fractal Respect Game, we’ll kick off Optimism Town Hall Season 4, where we’ll have an open discussion to welcome everyone back, recap our recent accomplishments, and explore some draft proposals including the Optimism Fractal participant agreement and new Cagendas rules. I’ve put together a topic proposal for today’s Town Hall with more details about what we’ll discuss.\nAs always, you can register for these events on the Optimystics Events Calendar and feel free to invite friends. Thank you for your continued support — I’m excited to grow Optimism Fractal, build on the Superchain, and share more amazing experiences with you all this season. Looking forward to seeing everyone!\nOF season 6 we're back 21376×725 147 KB\n\n 11 days later\n\n post by Rosmari on May 27, 2025\n\n Rosmari\n\n Unlocking Onchain Power with ORDAO on Base\nExciting developments for fractal communities!\nJoin us today at 15 UTC for an exciting ORDAO Fractal event where you can help pioneer next-generation governance tools and explore how to claim your Eden Fractal Respect on Base! \nimage1280×720 147 KB\nThis event will provide opportunities for all attendees to earn ORDAO Respect by playing the Respect Game! Today’s ORDAO Fractal event will focus on playing the Respect Game to measure contributions to ORDAO, exploring claiming features, and experiencing next generation software that’s pioneering the future of decentralized coordination \nUnlocking Onchain Power with Eden Fractal and ORDAO\nWith respect distribution mirrored on Base, Eden Fractal Respect holders will get unprecedented capabilities - to mint Respect, to play Respect Games whenever they want, or to execute any other onchain action \nTadas is working on a claim frontend to enable these capabilities. One of the main topics for today’s event will be exploring this claiming feature and learning how it will work. Participants won’t be able to test the claim interface yet, but Tadas will present progress and challenges. This is especially relevant for Eden Fractal participants and anyone interested in next-gen coordination tools!\nWe will try using fractalgram’s multi-org feature to submit Respect Game results to ORDAO Fractal. If successful, this will be the first time a fractal other than Optimism Fractal submits to ORDAO from Fractalgram - something that will be needed for Eden Fractal as well as other fractals. If it works, we will be able to use the Fractalgram app in upcoming Eden Fractal Respect Game events.\nORDAO Fractal represents an exciting opportunity to preview and test breakthrough governance systems as we prepare for broader deployment across fractal communities. This opportunity builds on the recent success of ORDAO at Optimism Fractal, where it allowed community-driven onchain execution through truly democratic processes based on earned reputation in prior seasons!\nimage1456×816 147 KB\nReady to experience the future of fractal coordination?\nJoin builders and governance pioneers at 15 UTC today for ORDAO Fractal — test breakthrough DAO software and earn Respect!\nEarn Respect and learn about the ORDAO software other fractals are starting to use! You’re welcome to RSVP for the event, watch the ORDAO Fractal App Demo video, and explore the ORDAO playlist for more.\nWe look forward to seeing you soon \n\n post by Optimystics on May 29, 2025\n\n Optimystics\n\n Join the Respect Game: A New Way to Empower Ethereum\nHi friends,\nwe’d love to see you at today’s Optimism Fractal event \nExperience the magical Respect Game at 17 UTC - an onchain social game that fosters collaboration, awards public goods creators, and optimizes governance on the Superchain & the wider Ethereum ecosystem!\nSince 2023, we’ve brought together 75+ builders creating transformative solutions for Optimism, catalyzing countless collaborations and pioneering powerful frameworks for impact recognition and collective decision-making.\nCurious about what’s going on today? You’re welcome to dive into the latest from the Optimism Fractal and Town Hall events.\nimage1456×816 188 KB\nWhat to expect at today’s event:\n\nPlay the beloved Respect Game with builders\nShare your contributions to the Superchain\nNetwork with optimists\nEarn Respect tokens through peer consensus\nShape democratic governance onchain\n\nHighlights from the latest Optimism Fractal episode:\n\nSuperchain interoperability discussions\nORDAO Fractal App development updates\nCross-chain collaboration strategies\nCommunity initiatives from Base & more\nWelcome to Optimism Fractal Season 6!\n\nEnjoy the full episode for more insights, updates, and community highlights!\nJoin Us\nAfter the Respect Game, join us for an exciting Optimism Town Hall event at 18 UTC for collaborative discussions about Ethereum \nAt today’s Town Hall, we’ll chat about agreements, the ORDAO Fractal app, and how often we should meet for Town Halls. Got something you’d like to bring up? Feel free to share — or just drop by and join the conversation! Learn more in this forum thread.\nYou’re welcome to RSVP at the events calendar where you can find a link to the zoom room. Stay in the loop with everything happening in Optimism Fractal — check out our Season 6 thread!\nLooking forward to seeing you there \n\n OF 61: Optimism Fractal Season 6\n\n Eden Fractal Epoch 2: Implementing Fractal Decision-Making on the Superchain\n\n 13 days later\n\n post by Rosmari on Jun 11, 2025\n\n Rosmari\n\n Gamifying Building and Coordination on Ethereum\nHi friends,\nReady to level up? Join Optimism Fractal on Thursday at 17 UTC \nPlay the Respect Game - where builders compete collaboratively, showcase contributions, and earn awards through peer consensus on Ethereum. Plus, discover how our community just unlocked new governance achievements!\nCurious about what’s the latest around Optimism Fractal and the Town Hall? You’re welcome to explore exciting initiatives, proposals, and much more below.\nimage1280×720 163 KB\nApproved Proposals\nCross-chain Oracle Powers\nThe Optimism Fractal Council approved a game-changing proposal: the Optimism Fractal community can now perform oracle functions for Eden Fractal’s migration from EOS to Base using ORDAO! Learn how this levels up coordination in this proposal.\nWhat does this mean? Optimism Fractal can now execute onchain actions on Base, just like on Optimism. This enables acting as an oracle for Eden Fractal Epoch 1 Respect claiming. Check out the ORDAO app powering this and learn how it works in this video.\nNew game rules: Town Hall Evolution!\nThe community also approved updating Cagendas rules - implementing a 2,000 Respect vote threshold for Optimism Town Hall events. This ensures sustainable resource allocation while maintaining community-driven discussions. Read the full proposal here.\nGet Involved\nThe Respect Game transforms governance into an engaging multiplayer experience! Builders showcase contributions on the Superchain, collaboratively evaluate impact & earn Respect tokens through democratic consensus. It’s coordination gaming at its finest! Learn how to play in this article.\nExplore exciting builder contributions from Respect Game core builders in our latest episode \nHighlights include the ORDAO Fractal launch, new front end for Optimism Fractal (of.frapps.xyz), Eden Fractal’s Base deployment & new governance proposals!\nDon’t miss tomorrow’s gaming session! After the Respect Game, you’re welcome to stay for discussions about governance proposals and how they unlock new ecosystem possibilities.\nJoin us on Thursday at 17 UTC via zoom and RSVP to join optimists & shape the future of decentralized coordination!\nWe look forward to seeing you soon \n\n OF 62: Playing with the Optimism Fractal ORDAO App\n\n 13 days later\n\n post by Optimystics on Jun 25, 2025\n\n Optimystics\n\n Join Us in Uplifting Public Goods at Optimism Fractal\nHi friends,\nWe’d love to see you at Optimism Fractal this Thursday at 17 UTC \nWe’re gathering builders from across the Superchain to play the Respect Game - where you share contributions, connect with innovators, and earn recognition through peer consensus on Ethereum.\nNew to the Respect Game? It’s simple, elegant, and powerful: Share what you’re building → Connect with fellow optimists → Evaluate impact together → Submit onchain to Optimism mainnet → Earn Respect. It’s collaborative governance on Ethereum!\nimage1280×720 193 KB\nWhat’s new in our community?\nThe Optimism Fractal council recently approved cross-chain capabilities that expand coordination beyond Optimism to Base and the wider Superchain ecosystem. This opens exciting opportunities for collaboration across communities. You’re welcome to explore how we’re building bridges together in this recent announcement.\nWhat does this mean? Optimism Fractal can now execute onchain actions on Base, just like on Optimism. This enables acting as an oracle for Eden Fractal Epoch 1 Respect claiming. You’re welcome to learn how it works in this video and claim your Respect on Base here. If you have any issues, questions, or need help please reach out in this Telegram group.\nThe community also refined our governance approach with sustainable thresholds for community discussions at Optimism Town Hall, ensuring quality conversations while keeping decisions community-driven. These updates strengthen our foundation as we expand democratic coordination across Ethereum. Feel free to read more about these governance updates in this post.\nGet Involved\nThe Respect Game transforms governance into an engaging form of coordination, flourishing through consistent watering with community contributions since 2021 \nBuilders showcase progress, evaluate impact, and earn Respect tokens through democratic consensus. You’re welcome to explore this guide on benefits and ways to play!\nLatest Episode\nYou’re invited to explore exciting builder contributions from Respect Game core builders in our latest episode \nHighlights include the ORDAO Fractal launch, new front end for Optimism Fractal (of.frapps.xyz), Eden Fractal’s Base deployment, and new governance proposals!\nWe’d love to meet you!\nWhether you’re building or exploring ways to contribute, there’s a welcoming community here to support your impact. You’re welcome to RSVP at the events calendar where you can find a link to the zoom room.\nWe hope to see you Thursday at 17 UTC to meet optimists and uplift the amazing work of public goods creators \n\n OF 63: Gamified Governance\n\n 13 days later\n\n post by Optimystics on Jul 8, 2025\n\n Optimystics\n\n Hi optimists!\nWe’re excited to share the newest Optimism Fractal episode showing how Ethereum players win through innovative coordination infrastructure \nWatch public goods creators unite to present, rank, and grow efforts together! This Respect Game showcases grassroots governance innovations - from ORDAO’s cross-chain expansion to Base, to celebrating Eden Fractal’s 3-year anniversary milestone and much more \n\n OF 64: Cross-chain Collaboration\n\nKey highlights from builders:\n\nZaal building asynchronous Discord bot for people to join fractal groups\nEric Westreich seeking testers for doctoral research training program with fractals\nWill from KF Media bringing TEDx-style talks to web3 using 100% web3 tooling\nGNeric planning to integrate the Respect Game into Nouns Africa\nDan Singjoy hosted Eden Fractal’s 122nd event celebrating 3-year anniversary & wrapped up Superchain Interop Incubator by Optimism\nHarvesto researching Eden Fractal and Optimystics’ websites for case study questions\nRosmari edited videos and relayed news from previous events happening in the community\nGene for all the ongoing optimistic support!\n\nThanks all for attending \nGet Involved\nWe’d love to see you again, or meet for the first time! \nWhether you’re building innovative tools or exploring ways to contribute, there’s a welcoming community here to support your impact.\nThe Respect Game transforms governance into an engaging social consensus game, flourishing through consistent community contributions since 2021. Builders showcase progress, evaluate impact, and earn Respect tokens through democratic consensus.\nJoin us this Thursday at 17 UTC to meet and support the amazing work of public goods creators! You’re welcome to RSVP on the events calendar where you can find a link to the zoom room. All episodes are available at optimismfractal.com/videos.\nLooking forward to seeing you on Thursday \nimage1452×547 142 KB\n\n post by Rosmari on Jul 10, 2025\n\n Rosmari\n\n Fun times at Optimism Fractal & Eden Fractal events\nHey fractal friends,\nIt was wonderful being at Eden Fractal and Town Hall last Thursday - such a fascinating discussion!\nCatch up on what’s been happening and join us today at Optimism Fractal \nimage1280×720 155 KB\nEden Fractal and Eden Town Hall\nAt Eden Fractal, we explored exciting developments like Tevo’s cross-chain collaboration tools and Swarm treasury work, Will’s insights on standardized impact measurement, Tadas’s infrastructure work on ORDAO for immutable respect distribution on Base, and much more!\nAt the Eden Town Hall event we had great conversations about Flavia’s AI-powered task recommendation systems, dispute resolution processes with Tevo and Sebastian, and the exciting possibility of scaling up fractals!\nAs many of you know, recently we got to celebrate Eden Fractal hitting 3 years, so once again, we’re very grateful for all of your continuous love and support \nYou’re welcome to watch both of these videos at Eden Creators’ Youtube channel and follow progress in this forum thread. Enjoy!\nJoin us at Optimism Fractal\nThis week, you’re invited to join Optimism Fractal on Thursday at 17 UTC to collaborate with talented onchain enthusiasts, share your work, and earn awards by playing the Respect Game! This provides a great opportunity to further Eden Fractal’s mission to implement fractal decision-making processes through development, community engagement, and collaboration.\nOptimism Fractal is about recognizing contributions and fostering collaboration on the Superchain - it’s a great space for builders and public goods creators across Ethereum. Whether you’re building or exploring ways to contribute, there’s a welcoming community here to support your impact.\nYou’re welcome to RSVP at the events calendar where you can find the zoom link. Would love to see you there and have some fun!\nimage1280×720 195 KB\n\n 12 days later\n\n post by Optimystics on Jul 22, 2025\n\n Optimystics\n\n Join us for the last Optimism Fractal event before summer break \nHey all, hope you’re doing great!\nJoin Optimism Fractal this Thursday at 17 UTC for our final gathering before summer break \nAfter 6 amazing events this season, we’re taking a pause to recharge & return stronger on September 4th.\nimage1280×720 142 KB\nExplore the Latest Optimism Fractal Updates\nThis upcoming two-event summer break (skipping Aug 7 & 21) gives community contributors essential rest while creating space for technical development & ecosystem engagement. Learn more about our strategic pause & vote on the proposal.\nBefore our break, catch up on our latest episode, which brings together onchain builders exploring gamified experiences, mining apps, arena-style Respect Games & more! \nStay Involved—Eden Fractal & Town Hall Run Next Week\n…Don’t you worry! Next week: Eden Fractal & Eden Town Hall continue as scheduled. After the break, both Optimism Fractal & Eden Fractal return Sept 4th with aligned event numbering.\nReady to wrap up Optimism Fractal Season 6’s first half with us? Join Thursday at 17 UTC to play the Respect Game, connect with builders on Ethereum, and celebrate our collective achievements before the summer pause.\nYou’re welcome to RSVP at the events calendar where you can find a link to the zoom room.\nLooking forward to seeing you there \n\n 1 month later\n\n post by DanSingjoy on Sep 2, 2025\n\n DanSingjoy\n\n Welcome to Optimism Fractal’s Return! \nAfter our refreshing six-week summer break, I’m thrilled to invite everyone to join us this Thursday, September 4th at 17 UTC for our 67th event. Together we’ll embark on the second half of Optimism Fractal’s sixth season, continuing our mission awarding public goods creators, fostering collaboration, and optimizing governance on the Superchain.\nThis Thursday, we’ll gather for our beloved Respect Game where you’ll enter breakout rooms, share your work, and rank contributions to the Ethereum and Optimism Superchain. Everyone is welcome to join, earn respect for their contributions, and network with innovators across the ecosystem - whether you’re a seasoned contributor or completely new. You don’t need any prior experience to get involved and your participation itself is a valuable contribution!\nFor those who haven’t been following closely over the past month and a half, it’s been an eventful break with exciting progress across multiple fronts. Here are some highlights from the three ecosystems that Optimism Fractal supports:\n\nEthereum Ecosystem: Ethereum recently celebrated its 10-year anniversary with thousands of builders and creators contributing to one of the largest open source communities in the world. The Ethereum Foundation’s new leadership is coordinating ecosystem growth more efficiently than ever. This vibrant community growth has translated to market success, with the valuation of ETH more than doubling in recent months and crossing an all-time high market cap of nearly $600 billion. There has been increasing institutional adoption through ETFs, treasury vehicles, and successful companies like Robinhood and Blackrock, while stablecoins on Ethereum have soared to reach a value of over $160 billion. All this growth in the Ethereum ecosystem provides more potential funding sources, collaborators, and open source software that creates fertile ground for Optimism Fractal and fractal governance to flourish.\n\nThe Superchain: The ecosystem continues its remarkable expansion with two new networks - Ronin Network (the gaming blockchain home to Axie Infinity) and Superform - now building on the OP Stack. Base has reached all-time highs in TVL while Worldchain continues onboarding millions monthly, with major chains like OP Mainnet, Unichain, Ink, Celo, and Soneium (from Sony) also making significant progress. Applications like Zora, Farcaster, and Aerodrome are experiencing outstanding growth and providing new kinds of valuable experiences onchain. The Optimism Collective recently embarked on it’s eight season, featuring important updates to its governance system and opportunities for contributors. The OP Stack now powers over 70% of Layer 2 transactions, serving as the primary way Ethereum scales its technology and values.\n\nFractal Ecosystem: The Fractal Impact Concert organized by EZ was a great success, beautifully merging art, music, and governance innovation. Eden Fractal returned from its break with the implementation of the Eden+Fractal consensus process - a legislative consensus mechanism comparable to the Optimism Fractal Council. This process enables delegate elections in Eden Fractal Epoch 2 and provides opportunities for participants to play leading roles in pursuit of its mission to implement fractal decision-making processes throughout society. ZAO Fractal continues demonstrating how fractal governance can benefit communities of creators, while other communities are becoming increasingly interested in fractal governance. Several new videos have been released on the Eden Creators youtube channel featuring episodes of Eden Fractal, Optimism Fractal, and Eden Town Hall.\n\nAs we approach Optimism Fractal’s two-year anniversary in October, it’s remarkable to see how far we’ve come. Our consistent weekly gatherings have proven the reliability and power of fractal democracy, building tremendous momentum for the future of fractal communities growing on Ethereum. I’m excited to hear about everyone’s contributions and what you’ve all been up to during the break.\nLooking forward to reuniting this Thursday and taking the first step toward planning an exciting anniversary celebration while preparing to mapping out all the great things we’ll accomplish in our third year, and of course getting back to our roots playing Optimism Fractal respect games. RSVP on the Optimystics Optimystics events calendar to join us on Thursday at 17 UTC, and feel free to invite friends!\nfuture city OF respect game mission conclusion 21536×653 97.6 KB\n\n 15 days later\n\n post by Optimystics on Sep 17, 2025\n\n Optimystics\n\n Toward a Playful Protopia: The Optimism Fractal Experiment\nHey all,\nJoin us on Thursday at 17 UTC for Optimism Fractal as we continue pioneering collaborative governance across the Superchain \nPlay the Respect Game with talented builders and help shape the future of decentralized coordination through playful protopia!\nimage1280×720 171 KB\nThe second half of Season 6 began with players bringing fresh updates from the summer break \nWhile playing the Respect Game, we celebrated contributions to the Ethereum ecosystem, explored ideas to strengthen coordination in communities & much more. Check out our latest video to see what happened during the last event.\nHighlights include a deep dive with Eric into his game-changing Simbiosyx platform!\nTogether with his team at Aquallius, Eric is reimagining how startups connect with experts through sweat equity, while exploring ways to integrate Respect tokens with equity distribution with Dan Singjoy. We invite you to explore more amazing contributions in this episode’s show notes.\n\n OF 67: Welcome Back & Discussion on Eric’s Initiatives\n\nGet Involved\nAs we approach our 2-year anniversary this October, we’re excited to continue building the future of the internet together!\nThe Respect Game, played at each event, provides an engaging space for everyone to showcase their work and earn recognition through peer consensus on Ethereum. You get the opportunity to share what you’ve done to contribute to Optimism, then collaboratively rank peers’ contributions & earn Respect tokens. Let’s Grow!\nYou’re welcome to RSVP at the events calendar where you can find a link to the zoom room.\nLooking forward to seeing you there \n\n 14 days later\n\n post by Optimystics on Oct 2, 2025\n\n Optimystics\n\n Hey friends,\nJoin us now at Optimism Fractal as we continue pioneering collaborative governance on Ethereum \nPlay the Respect Game with talented builders scaling the peaks of decentralized coordination across the Superchain & beyond!\nOF 69 thumbnail1280×720 127 KB\nAt our last event, builders showcased the essence of protopian building - gradual improvement through playful coordination.\nWatch builders demonstrate how the Respect Game transforms governance from a burden into an engaging & playful social experience. Check out the latest video to see what happened during the last event!\nCommunity highlights\nExperience the magic as Harvesto unveils groundbreaking fractal research with Douglas about his experience with Genesis Fractal and being a founder of Aquadac, Will expands Web3 education across Latin America while pioneering onchain TEDx-style talks, Zaal bridges ETH Boston to Nigerian artists with Wave Warz, Tadas ensures immutable Respect distribution & Dan hosts community events fostering collaboration, while supporting onboarding efforts.\nWe invite you to explore more amazing contributions in this episode’s show notes.\n\n OF 68: Collaborative Governance\n\nGet Involved\nAs we approach our 2-year anniversary this October, we’re excited to continue building the future of the internet together!\nThe Respect Game, played at each event, provides an engaging space for everyone to showcase their work and earn recognition through peer consensus on Ethereum. You get the opportunity to share what you’ve done to contribute to Optimism, then collaboratively rank peers’ contributions & earn Respect tokens.\nYou’re welcome to RSVP at the events calendar where you can find a link to the zoom room.\nLooking forward to seeing you there \n\n 13 days later\n\n post by DanSingjoy on Oct 15, 2025\n\n DanSingjoy\n\n Hey all, we have some excellent events lined tomorrow that I’m excited to share with you! These gatherings offer meaningful opportunities to connect with talented builders, participate in groundbreaking research, and help celebrate an important milestone in Optimism Fractal’s journey.\nThis Thursday we’ll meet for the Optimism Fractal Respect Game at 17:00 UTC and Optimism Town Hall at 18:00 UTC. As always, the Respect Game provides an excellent way to connect with visionary community members, showcase your work, and earn Respect while pioneering fractal democracy on the Superchain. Following the Respect Game, we’re bringing back Optimism Town Hall with two important topics: briefly reviewing a draft proposal for Optimism Fractal’s upcoming two-year anniversary and hosting an orientation for Eric Westreich’s research on appreciation and volunteer motivation using fractal coordination.\nFollowing the brief anniversary planning discussion, Eric will host a run-through of his doctoral study “Measuring the Impact of Appreciation on Nonprofit Volunteer Motivation,” which examines how peer appreciation in fractal governance impacts volunteer motivation within nonprofit organizations. This session will gather feedback on the exact training that prospective research study participants will receive when the study launches on November 1st—helping make the training clearer, more concise, and more compelling. The run-through provides a friendly introduction for anyone curious about the research. You can read more or sign up via the Volunteer Consent and Interest Form.\nEveryone is welcome to join these events—whether you’re new to Optimism and Fractals or an experienced community member, we’d love to see you there. You can learn more about the Optimism Town Hall topics in the approved topic proposal and RSVP for all events on the Optimystics events calendar. Hope to see you at the there!\nevents presented by Optimystics Thursday October 1621280×720 964 KB\n\n 12 days later\n\n post by DanSingjoy on Oct 28, 2025\n\n DanSingjoy\n\n Dear members of the Optimism Collective,\nFollowing up on recent community discussions. I’ve created a proposal on the Optimism Fractal snapshot space to start Season 7 on January 22nd, 2026. While last week’s draft proposed starting two weeks earlier, we discussed this at Eden Town Hall and agreed that the additional two weeks would better serve the community—providing more time for family, rest, and preparation. You can watch our discussion in this video.\nThe proposal above includes comprehensive context, rationale, and voting details. Voting will remain open until this week’s event at 17:00 UTC on October 30th. The Optimism Fractal Council will vote on this proposal as per our intent document. Note that the related proposal to start Eden Fractal Season 12 on January 15th was approved, so the usual biweekly cadence on the Optimystics Events Calendar would begin one week before Optimism Fractal returns.\nThank you all for an amazing season and past two years! I’m excited to reconvene and celebrate our two-year anniversary on Thursday! \n\n post by Optimystics on Oct 29, 2025\n\n Optimystics\n\n Come Celebrate! Optimism Fractal Turns Two \nHi friends,\nJoin us this week for Optimism Fractal at 17 UTC and Optimism Town Hall at 18 UTC, as we celebrate two years of collaboration and look ahead to what’s next \nOF 71 thumbnail1280×720 349 KB\nAt Optimism Fractal, we’ll be playing the beloved Respect Game and celebrating the spirit of cooperation that’s brought our community this far.\nThen at Optimism Town Hall, there’ll be an open space for community conversations about the future, as well as reflecting on our path, sharing ideas, and setting our sights on the year ahead.\nYou’re welcome to RSVP at the events calendar where you can find a link to the zoom room. Daylight savings time has ended in some time zones, so please double-check your local meeting time & don’t forget to wear your party hats!\nLooking forward to seeing you there \n\n post by DanSingjoy on Oct 30, 2025\n\n DanSingjoy\n\n GM Optimism Collective! \nOptimism Fractal celebrates two years of fostering collaboration, awarding public goods creators, and optimizing governance on the Superchain. We invite all Collective members to join us today at 17:00 UTC as we mark this milestone and discuss our continued contributions to Superchain governance.\nGrowing on Optimism\nTwo years ago, Optimism Fractal launched with a vision: to bring proven democratic coordination mechanisms to the Superchain and help the Optimism ecosystem develop innovative governance, community growth, and capital allocation solutions. What started as an experiment has evolved into a consistent practice, with over 100 unique participants joining our events and contributing to the ecosystem’s growth. Week after week, regardless of market conditions, our community has demonstrated that sustainable, democratic governance is possible onchain.\nSuperchain Impact\nThrough our weekly Respect Games and related community discussions at Optimism Town Hall, the Optimism Fractal community has participated in creating over 100 educational videos that serve as resources for the broader ecosystem. We’ve successfully implemented and operated ORDAO for nearly a year, while the Optimism Fractal Council has functioned as our legislative branch for over 20 months. These aren’t just experiments - they’re working governance systems that demonstrate practical approaches to the challenges the Collective faces.\nOur impact extends beyond our immediate community. Organizations and projects throughout the Superchain have adopted elements of our governance model, and communities worldwide are implementing fractal governance inspired by our work. As the Superchain approaches full interoperability and major networks like Base, World, and Unichain continue supporting breakout applications, the need for effective coordination mechanisms becomes even more critical.\nToday’s Celebration\nToday’s event begins with our regular Respect Game at 17:00 UTC, where participants earn Respect by presenting their contributions to the ecosystem. This process, refined over two years, creates accountability, recognition, and alignment without centralized control.\nFollowing the game, we’ll host an anniversary discussion at Optimism Town Hall, where we’ll reflect on our journey, share insights from two years of governance experimentation, and discuss how we can better serve the Collective’s needs in Season 8 and beyond. Feel free to explore our Optimism Town Hall discussion where we initially planned this anniversary celebration.\nYou’re welcome to use Optimism Fractal thumbnails as Zoom backgrounds (find them at OptimismFractal.com/videos) or dress festively if you’d like. We expect good conversation about both our achievements and the challenges ahead as we enters our next phase of growth.\nLooking Forward\nAs we enter our third year and the Optimism ecosystem continues evolving, we’re focused on deeper integration with the Collective and more direct contributions to Superchain governance challenges. Ethereum just turned ten years old, and as we head into 2026, the world is increasingly coming onchain. The Superchain has the opportunity to shape this transition, and effective governance will be crucial to that success.\nWe invite you to join us for today’s to learn more about our work, share your perspectives on governance challenges, and explore how Optimism Fractal can better serve the Collective’s goals. Whether you’re deeply involved in governance or simply curious about alternative coordination mechanisms, your participation enriches the discussion. As always, you can RSVP for both the Optimism Fractal Respect Game and Optimism Town Hall on the Optimystics events calendar.\nFor more details about the event and our impact over the past two years, see our full anniversary proposal. Hope to see you join us as we celebrate two years of building on the Superchain and plan for even greater impact in year three!\nbirthday 2 image 44 copy790×483 191 KB\n\n 12 days later\n\n post by Optimystics on Nov 11, 2025\n\n Optimystics\n\n Join Us for the Season 6 Finale - Optimism Fractal’s Final Events of 2025\nEveryone is welcome to join us on Thursday for the final Optimism Fractal Respect game and Optimism Town Hall of the season \nThese events mark the conclusion of Optimism Fractal Season 6 and our last gatherings before the winter break, offering valuable opportunities to connect with the Optimism Fractal community, reflect on our achievements, and plan for the next year.\nimage1280×720 431 KB\nWe’ll start with the Respect Game played at Optimism Fractal at 17:00 UTC, bringing together builders and governance participants. This collaborative game allows you to showcase your work, build reputation within the ecosystem, and network with others building on the Superchain. For two years, the Respect game has been the cornerstone of our community, fostering meaningful connections and collaborations building playful dystopia.\nThe Optimism Town Hall follows at 18:00 UTC, providing an open forum to recap Optimism Fractal Season 6, discuss progress across the Optimism Superchain in 2025, and continue conversations from our recent two-year anniversary celebration. We may share thoughts going into the winter break and begin planning for next season, with our next gathering scheduled for January 22nd, 2026.\nCommunity highlights\nIn the meantime, you’re welcome to check out our recent Optimism Fractal 2-year anniversary video highlighting community contributions (including new app development, ORDAO v1.4, and fractal research), plus the Town Hall episode featuring discussions about Dan’s Gardens ideas and Tadas’s Synchronous Respect Trees game.\n\n OF 71: Optimism Fractal 2 Year Anniversary\n\n OTH 41: Gardens, Respect Trees & Planning\n\nWe invite you to explore more amazing contributions and updates in recent episode show notes. Enjoy!\nGet Involved\nThank you to everyone who has made Optimism Fractal Season 6 successful through your participation and contributions \nWe encourage you to check out our recent anniversary videos, join the Discord server for more conversations, and RSVP through the Optimystics event calendar.\nWhether you’re a longtime participant or discovering our community for the first time, this is an excellent opportunity to connect with builders, contribute to governance discussions, and help shape the future of the Superchain.\nLooking forward to seeing you soon,\n\n 2 months later\n\n post by DanSingjoy on Jan 21\n\n DanSingjoy\n\n Dear Members of the Optimism Collective,\nI hope everyone had a wonderful holiday season and enjoyed the break. I’ve been following the news about Optimism Season 9 and am excited to see the new direction taking shape. A lot has happened over the past couple months, and I have some exciting news to share with you—both personal and about Optimism Fractal.\nFirst, I’d like to let you know that the video for Optimism Fractal’s Season 6 Finale—is now published on the Eden Creators YouTube channel and can now watch it here. This was an unusual event. For the first time ever in Optimism Fractal’s history, I was the only one present—which became an interesting signal about where to focus our resources. Since it was already the scheduled final event of the season, I decided to still record an episode and try something new: a solo Respect Game format.\nThe video starts with a funny little blooper reel of me trying to figure out how to host the show on my own without anyone else there. From there, I give an introductory presentation on Optimism Fractal and share some recent community news. I then explain why I see value in this solo Respect Game approach — it can help make fractals more resilient in early stages by allowing hosts to still run the game even when people can’t make it, as long as the community agrees through the ORDAO process.\nIn this experimental format, I ranked myself and five others who have recently contributed to Optimism Fractal’s mission. I’ve just created a belated ORDAO proposal to distribute Respect to these community members for this game—you can now vote on it at https://optimism.frapps.xyz if you’d like. You can watch the video to see my recent contributions to Optimism and rationale for giving respect to these community members. At the end of the video, there’s also a small town hall segment where I discuss the state of the Optimism Collective and Optimism Fractal.\n\n OF 72: Community Recognition\n\nGetting Married & Growing Together\nNow for some very exciting personal news. During that event, I announced that I was engaged to Rosmari—and I’m thrilled to let you all know that we got married over the winter break!\nFor those who may not be familiar, @Rosmari is a co-founder of both Optimism Fractal and the Optimystics team. We actually met at Eden Fractal about three years ago, at the community’s 35th event. It’s truly amazing how fractals and Optimism can bring together people from across the world and lead to such meaningful connections. We had the pleasure of meeting Zaal (founder of ZAO Fractal) at the wedding, and we’re deeply grateful for all the times we’ve shared with the Optimism Fractal community. She’s planning to rejoin fractal community events once we resolve some visa restrictions, and we’re thrilled for our next steps together.\nI apologize for the delay in releasing this video and the ORDAO proposal—usually these come out within a week of the event, but this is two months later. Between preparing for the wedding, family obligations over the holiday season, and working to support different members of the fractal ecosystem, I simply haven’t had the time to get to the video editing until now. I’ll aim to share future videos more promptly in the future, but frankly I just had too much on my plate and I’ve realized the need to focus more on the highest priorities. Which leads to the next announcement…\nimage1920×1280 221 KB\n\n post by DanSingjoy on Jan 21\n\n DanSingjoy\n\n Announcing Optimism Fractal’s Hiatus\nI’ve submitted a proposal to the Optimism Fractal Council for an indefinite strategic hiatus of Optimism Fractal events.\nAs you may remember, we had planned to return for Optimism Fractal Season 7 on January 22nd. However, after careful deliberation over the past couple of months, Tadas and I have decided that it makes more sense to pause Optimism Fractal and consolidate our resources in Eden Fractal.\nAs explained in our community intent document, the Optimism Fractal Council operates through a legislative consensus process where community members who have earned Respect can register as Council members during each period between Respect Game events. In the most recent period, only Tadas and I registered, which means we have the legislative authority to make this decision. As both councilors and cofounders of Optimism Fractal (and the Optimystics), @Tadas and I are confident that this is the right decision for the community.\nThis decision was first suggested by Tadas back in mid-November, in the days after Optimism Fractal’s last event of the season. Tadas proposed a topic proposal about this in the Eden Fractal telegram group and then we discussed it at the Eden Town Hall on November 20th. I invited everyone from the Optimism Fractal community to join that conversation and, after thinking about it very carefully, the direction became clear — we’re better off focusing our energy on Eden Fractal. Zaal and other community members who participated were also fully supportive. You can watch the full discussion in the 67th Eden Town Hall video on the Eden Creators YouTube channel.\nSince then, Tadas and I have spoken about this several more times, including at last week’s Eden Town Hall, and we remain in complete agreement. He voted to approve the proposal earlier today. As such, we’ve decided to indefinitely postpone Optimism Fractal Season 7 and will meet for a community discussion at Eden Town Hall on January 22nd at 16 UTC instead of an Optimism Fractal Respect Game.\n\n ETH 67: Strategic Planning for Optimism Fractal Hiatus\n\nWhy We’re Making This Decision\nEden Fractal is the foundational community from which Optimism Fractal emerged. It’s been working to implement fractal decision-making processes throughout society since 2021, and it has a clear vision and mission that needs more resources to fulfill.\nSince Eden Fractal launched its Epoch 2 initiative last May, Eden Fractal has been building on Base—part of the Superchain—and is directly advancing Optimism Fractal’s mission of fostering collaboration, recognizing public goods creators, and pioneering better governance on the Superchain. So even though we’re pausing Optimism Fractal, we’re continuing to build on the Superchain and support Optimism’s ecosystem.\nThere’s been a lot of exciting momentum in the fractal ecosystem lately. Several new initiatives are sprouting up and there’s a lot of work to be done to support this growth. Eden Fractal is the natural home for that support. Meanwhile, splitting our attention between communities has become unsustainable — we haven’t been able to give either Eden Fractal or Optimism Fractal the attention they each deserve. This showed up clearly in Optimism Fractal when I was the only person at our last event, which became a meaningful signal about where to direct our energy. At the same time, Eden Fractal has been generating significant excitement that warrants more of our attention. By focusing our energy on Eden Fractal, we can strengthen our core infrastructure. provide more attention to the growing ecosystem of fractal communities, and prepare our tools for implementation at a greater scale.\nAdditionally, the Optimism Foundation recently announced significant changes for Season 9. They’re shifting away from community-led capital allocation, including pausing Retro Funding for 12+ months and planning to dissolve the Grants Council. Community-driven capital allocation and governance is precisely what Optimism Fractal was designed to demonstrate. This news reaffirmed our already agreed-upon decision that this is the right time to refocus our energy.\nFractal governance is beneficial for all communities and organization on any blockchain. Right now, Eden Fractal and several other fractal communities are building on the Superchain, and we plan to continue supporting the Superchain that way. But Eden Fractal’s broader mission—implementing fractal decision-making throughout society—positions us to support fractal governance wherever it takes root.\nThis is essentially wrapping up Optimism Fractal’s first six seasons as a successful experiment in which we made significant progress toward our goals. It’s also laying the groundwork for an eventual return when conditions in both the fractal ecosystem and the Optimism Collective are more aligned.\nYou can follow our progress continuing Optimism Fractal’s mission at Eden Fractal in the Eden Fractal Optimism Governance Forum Thread and learn more about some of our experiences with the Optimism Collective’s funding mechanisms in this draft article.\nWhat Happens Now\nThe ORDAO app at optimism.frapps.xyz and the smart contracts continue to function. Your Respect tokens remain, and you can still use them to vote on proposals through ORDAO and Snapshot. The ORDAO branch of our governance stays active and can reactivate the Respect Game events and Optimism Fractal Council when the community decides the time is right.\nAll 72 Optimism Fractal event videos, over 40 Optimism Town Hall recordings, and all our documentation is still available. You can find these resources on our websites and watch all the videos on the Eden Creators YouTube channel. Optimism Town Hall will also enter an indefinite hiatus—I’ll be hosting Eden Town Hall in its place. This Discord also stays open — feel free to keep chatting here. However, I’d recommend joining the Eden Fractal telegram group chat, which is much more active and the best place to keep in touch with updates from the fractal ecosystem.\nI also want to let you know that the Optimystics events calendar has transitioned to the Eden Creators events calendar. This goes along with our shift in resources to support the Eden Fractal ecosystem. If you were subscribed to Optimystics events, you’ll now receive invitations from Eden Creators. The Optimystics’ educational materials remain available as well, but I’ll be focusing more on work with Eden Creators going forward to support the Eden community.\nJoin Eden Fractal\nEveryone from Optimism Fractal is warmly invited to continue the journey at Eden Fractal. Whether you’ve been deeply embedded in the fractal ecosystem or you’re building on Optimism and curious about better governance and coordination—you’re welcome to join us.\nThis Thursday, January 22nd at 16 UTC—the same day Optimism Fractal was scheduled to return—we’ll be hosting an Eden Town Hall instead and we may meet for two hours. We’ll be discussing Eden Fractal’s schedule for Season 12 (we’re deciding between weekly and bi-weekly events) and welcoming anyone from the Optimism Collective to share their thoughts about Optimism Fractal, Eden Fractal topics, and more. We’d love to see you there!\n Explore Eden Fractal: https://edenfractal.com\n Register for events: Eden Creators · Events Calendar\n Join the conversation: Telegram: View @edenfractal\n Watch Videos: https://www.youtube.com/@EdenCreators\n Explore Eden Town Hall: https://edentownhall.com/\n Optimism governance forum thread: Eden Fractal Epoch 2: Implementing Fractal Decision-Making on the Superchain\nConclusion\nI believe Optimism Fractal will return when the time is right. I don’t know exactly when that will be, but when both the fractal ecosystem and the Optimism Collective are more ready for this kind of collaboration, we can pick up where we left off through our existing consensus processes. I’m excited for that day. Until then, I really hope to see everybody at Eden Fractal.\nI want to thank everyone for all the wonderful experiences and the things we’ve built together over the past two years. We met so many amazing people here who played pivotal roles in helping Optimism Fractal and helping the broader fractal ecosystem grow. Thank you for being here, sharing your work, and believing in this vision. It’s been a great pleasure and a very special time in my life, and I’m deeply grateful for everyone’s participation.\nFor more details on Optimism Fractal’s hiatus, you can read the proposal linked above and stay tuned for upcoming articles. Thank you all for everything. Go Eden Fractal, go Optimism Fractal, and go Optimism! \n\n Eden Fractal Epoch 2: Implementing Fractal Decision-Making on 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 Optimism Fractal Season 5: Level Up with Weekly Respect Games on the Superchain\n\n ✨ General\n\n Welcome to Season 5 of Optimism Fractal!\nAfter an incredible first year bringing builders together through innovative onchain social games, we’re excited to begin our next chapter with powerful new tools and growing mome…\n\n read more\n\n 33\n\n 788\n\n Jul 2025\n\n Optimism Fractal Weekly Events\n\n Community Calls\n\n Hey Optimists! \nYou’re invited to join Optimism Fractal events on Mondays at 17 UTC \nOptimism Fractal is a community dedicated to fostering collaboration and awarding public goods creators on Optim…\n\n read more\n\n 15\n\n 1.6k\n\n Apr 2024\n\n Optimism Fractal Season 4\n\n Community Calls\n\n Dear Optimists, \nOptimism Fractal is returning from summer break and we’re excited to embark on Season 4! We’re looking forward to reconnecting at our weekly events and invite you to join! \nOptimism Fractal events kick o…\n\n read more\n\n 21\n\n 458\n\n Nov 2024\n\n Optimism Fractal Season 3\n\n Community Calls\n\n Hey friends! Join us for the first event of Optimism Fractal Season 3! \nWe’re excited to start the season in style with a Respect Game to grow Optimism, then discuss a new proposal in today’s planning session…\n\n read more\n\n 19\n\n 1.3k\n\n Jul 2024\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 33\n\n 711\n\n 11h","tokens":14183,"squid":"spider-07","role":"Council Spider","at":1791345934456,"hash":"99cb6b2d33ef5a158c3b75f96b810bb56cf93867"}
{"url":"https://gov.optimism.io/t/optimism-fractal-season-6-expanding-democratic-coordination-across-the-superchain/9924/19","domain":"gov.optimism.io","title":"Optimism Fractal Season 6: Expanding Democratic Coordination Across the Superchain - Updates and Announcements 📢 / Community Calls - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n Updates and Announcements 📢Community Calls\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 9\n\n 7\n\n 3\n\n read \n\n 19\n min\n\n May 2025\n\n 19 / 19\n\n Jan 21\n\n Jan 21\n\n post by Optimystics on May 15, 2025\n\n Optimystics\n\n Welcome to Season 6 of Optimism Fractal!\nAfter an exceptional journey of fostering collaboration through innovative onchain social in our first five seasons, we’re excited to embark on a new chapter with enhanced tools and strengthened community bonds across the Superchain ecosystem \nOptimism Fractal continues its mission of fostering collaboration, awarding public goods creators, and optimizing governance on the Superchain. Through our weekly Respect Game events, we create an engaging platform where builders showcase their work, form meaningful connections with fellow innovators, and earn Respect tokens — the foundation of our reputation-based democratic coordination system.\nSince 2023, our community has brought together over 75 builders creating transformative solutions for Optimism, catalyzing countless collaborations while pioneering powerful frameworks for impact recognition and collective decision-making. We invite you to join this thriving ecosystem as we expand our reach across the Superchain!\nimage1456×816 154 KB\nWeekly Events\nJoin us every other Thursday at 17:00 UTC starting today to play the Respect Game where you can:\n\nShare your contributions to Optimism and the Superchain\nNetwork with innovative builders across multiple ecosystems\nPresent your projects in supportive breakout rooms\nEarn Respect through peer evaluation and consensus\nParticipate in our interactive, gameshow-style events\n\nWhether you’re actively building on the Superchain or just beginning your journey, our events provide valuable opportunities for networking, learning, and amplifying your impact. We welcome builders of all experience levels and encourage you to invite friends who could benefit from our supportive community.\nRSVP here to join our next event!\nSeason 5 Highlights\nLooking back at our achievements from the previous season:\n\nCompleted 60+ Events and Videos: We’ve now hosted 60 Respect Game events since our inception, producing an extensive library of educational content showcasing Superchain builders and governance innovations.\nORDAO Implementation: Successfully launched our optimistic governance smart contract infrastructure, allowing community-driven onchain execution through truly democratic processes based on earned reputation in our prior seasons.\nDemocratic Fund Distribution Research: @DanSingjoy is continuing to deliver research on democratic fund distribution using Respect tokens and fractal structures, creating blueprints for effective funding allocation that benefits the Optimism Collective and broader Superchain.\nETHDenver and In-Person Expansion: For the first time, we brought the Respect Game to physical events, hosting live sessions at ETHDenver that demonstrated the adaptability of our coordination frameworks.\nCross-Community Adoption: Witnessed growing implementation of the Respect Game across communities like ZAO Fractal, which is approaching its one-year anniversary of using our coordination mechanisms.\n\nExplore more in our Season 5 forum thread for videos and insights from previous events!\nLooking Ahead to Season 6\nThis season brings several exciting developments:\n\nORDAO Front-End Deployment: @Tadas is launching a comprehensive front-end interface for ORDAO in the coming weeks, making it significantly more intuitive for community members to submit proposals for onchain actions, distribute Respect, and participate in governance.\nEnhanced Fractalgram Interface: After building many important features for playing the Respect Game in Season 5, @Father-abraham is planning to improve the Fractalgram interface to work seamlessly with any ORDAO implementation, making it easier for different communities to adopt our coordination tools.\nSuperchain ORDAO: @Jacobhomanics is developing Superchain ORDAO as part of the Superchain Interop Incubator program, making our smart contracts for Respect distribution, reputation, and governance interoperable across the Superchain.\nMobile-Compatible Interfaces: Initial testing of the Fractalgram app showed promising results for mobile accessibility, significantly lowering barriers to participation in governance processes.\nCross-Superchain Collaboration: Expanding outreach to communities across Base, Zora, Unichain, World Chain, and other Superchain networks to provide a unified collaborative space for builders throughout the ecosystem.\n\nRelated Initiatives\nFollowing Optimism Fractal Respect Games, community members are welcome to join Optimism Town Hall at 18:00 UTC, now entering its fourth season. This complementary forum for governance discussions provides another avenue for engagement with the Optimism ecosystem. You can explore the Season 3 thread for detailed discussions and insights from previous events.\nEden Fractal hosts bi-weekly events on alternating Thursdays at 17:00 UTC focused on advancing coordination tools and processes. Entering Epoch 2 and preparing for its 3 year anniversary, Eden Fractal will deploy ORDAO on Base with over 75 contributors eligible to claim their Respect tokens. This initiative will test the fund distribution system outlined in our research, providing valuable insights for Optimism Fractal’s future development.\nThe ORDAO Office Hours playlist now features eight recorded sessions where community members can learn about the technical infrastructure powering our governance systems. These sessions pave the way for the upcoming launch of ORDAO Fractal, a community space where contributors earn Respect by supporting ORDAO development.\nEveryone is welcome to join all of these events to contribute to the broader ecosystem and pioneer new forms of governance on the Superchain. Subscribe to the Optimystics Events Calendar to stay informed, track upcoming events, and receive email reminders for all these activities.\nGetting Involved & Resources\nOptimism Fractal continues as a pioneering community doing crucial work to help the Collective achieve its vision—from attracting builders and fostering collaboration to pioneering democratic coordination at scale. We welcome engagement in various forms:\n\nExplore our community: OptimismFractal.com\nSubscribe for all videos: Eden Creators Youtube channel\nWatch past Optimism Fractal events: Videos and Show Notes\nLearn the Respect Game: Introductory article\nJoin discussions: Community Discord, X profile, and Farcaster channel\nBrowse coordination tools: Optimystics Toolkit\nExplore Fractal Democracy: Article\nSee protocol specs: Core Intents\nPrevious Optimism Fractal season threads: Season 2 | Season 3 | Season 4 | Season 5\n\nThis thread will serve as a central place for event invitations, recordings, and key updates throughout Season 6. We appreciate all forms of support in making Optimism Fractal as valuable as possible for the entire Superchain ecosystem.\nFeel free to share any questions or thoughts below. We look forward to seeing you at our events as we work together to build the future of the internet \n\n Optimism Fractal Season 5: Level Up with Weekly Respect Games on the Superchain\n\n Optimism Fractal Respect Game: Research into Democratic Fund Distribution\n\n Optimism Town Hall Season 4: Growing the Superchain Through Collaborative Governance\n\n 9\n\n 7\n\n 3\n\n read \n\n 19\n min\n\n post by DanSingjoy on May 15, 2025\n\n DanSingjoy\n\n Hey Optimists!\nI’m thrilled to welcome everyone back for the launch of Optimism Fractal Season 6 today, May 15th at 17 UTC! After our refreshing month-long break, I can’t wait to reconnect with all of you, play the Respect Game together, and hear what everyone’s been up to.\nOver the past seasons, we’ve built something truly special together. From our amazing community of dedicated contributors to the significant improvements in our software and educational resources, we’ve created solid foundations that position us to make this our most impactful season yet. I’m deeply grateful for everyone’s contributions so far and stoked about what we’ll accomplish together in this new season.\nAfter the Optimism Fractal Respect Game, we’ll kick off Optimism Town Hall Season 4, where we’ll have an open discussion to welcome everyone back, recap our recent accomplishments, and explore some draft proposals including the Optimism Fractal participant agreement and new Cagendas rules. I’ve put together a topic proposal for today’s Town Hall with more details about what we’ll discuss.\nAs always, you can register for these events on the Optimystics Events Calendar and feel free to invite friends. Thank you for your continued support — I’m excited to grow Optimism Fractal, build on the Superchain, and share more amazing experiences with you all this season. Looking forward to seeing everyone!\nOF season 6 we're back 21376×725 147 KB\n\n 11 days later\n\n post by Rosmari on May 27, 2025\n\n Rosmari\n\n Unlocking Onchain Power with ORDAO on Base\nExciting developments for fractal communities!\nJoin us today at 15 UTC for an exciting ORDAO Fractal event where you can help pioneer next-generation governance tools and explore how to claim your Eden Fractal Respect on Base! \nimage1280×720 147 KB\nThis event will provide opportunities for all attendees to earn ORDAO Respect by playing the Respect Game! Today’s ORDAO Fractal event will focus on playing the Respect Game to measure contributions to ORDAO, exploring claiming features, and experiencing next generation software that’s pioneering the future of decentralized coordination \nUnlocking Onchain Power with Eden Fractal and ORDAO\nWith respect distribution mirrored on Base, Eden Fractal Respect holders will get unprecedented capabilities - to mint Respect, to play Respect Games whenever they want, or to execute any other onchain action \nTadas is working on a claim frontend to enable these capabilities. One of the main topics for today’s event will be exploring this claiming feature and learning how it will work. Participants won’t be able to test the claim interface yet, but Tadas will present progress and challenges. This is especially relevant for Eden Fractal participants and anyone interested in next-gen coordination tools!\nWe will try using fractalgram’s multi-org feature to submit Respect Game results to ORDAO Fractal. If successful, this will be the first time a fractal other than Optimism Fractal submits to ORDAO from Fractalgram - something that will be needed for Eden Fractal as well as other fractals. If it works, we will be able to use the Fractalgram app in upcoming Eden Fractal Respect Game events.\nORDAO Fractal represents an exciting opportunity to preview and test breakthrough governance systems as we prepare for broader deployment across fractal communities. This opportunity builds on the recent success of ORDAO at Optimism Fractal, where it allowed community-driven onchain execution through truly democratic processes based on earned reputation in prior seasons!\nimage1456×816 147 KB\nReady to experience the future of fractal coordination?\nJoin builders and governance pioneers at 15 UTC today for ORDAO Fractal — test breakthrough DAO software and earn Respect!\nEarn Respect and learn about the ORDAO software other fractals are starting to use! You’re welcome to RSVP for the event, watch the ORDAO Fractal App Demo video, and explore the ORDAO playlist for more.\nWe look forward to seeing you soon \n\n post by Optimystics on May 29, 2025\n\n Optimystics\n\n Join the Respect Game: A New Way to Empower Ethereum\nHi friends,\nwe’d love to see you at today’s Optimism Fractal event \nExperience the magical Respect Game at 17 UTC - an onchain social game that fosters collaboration, awards public goods creators, and optimizes governance on the Superchain & the wider Ethereum ecosystem!\nSince 2023, we’ve brought together 75+ builders creating transformative solutions for Optimism, catalyzing countless collaborations and pioneering powerful frameworks for impact recognition and collective decision-making.\nCurious about what’s going on today? You’re welcome to dive into the latest from the Optimism Fractal and Town Hall events.\nimage1456×816 188 KB\nWhat to expect at today’s event:\n\nPlay the beloved Respect Game with builders\nShare your contributions to the Superchain\nNetwork with optimists\nEarn Respect tokens through peer consensus\nShape democratic governance onchain\n\nHighlights from the latest Optimism Fractal episode:\n\nSuperchain interoperability discussions\nORDAO Fractal App development updates\nCross-chain collaboration strategies\nCommunity initiatives from Base & more\nWelcome to Optimism Fractal Season 6!\n\nEnjoy the full episode for more insights, updates, and community highlights!\nJoin Us\nAfter the Respect Game, join us for an exciting Optimism Town Hall event at 18 UTC for collaborative discussions about Ethereum \nAt today’s Town Hall, we’ll chat about agreements, the ORDAO Fractal app, and how often we should meet for Town Halls. Got something you’d like to bring up? Feel free to share — or just drop by and join the conversation! Learn more in this forum thread.\nYou’re welcome to RSVP at the events calendar where you can find a link to the zoom room. Stay in the loop with everything happening in Optimism Fractal — check out our Season 6 thread!\nLooking forward to seeing you there \n\n OF 61: Optimism Fractal Season 6\n\n Eden Fractal Epoch 2: Implementing Fractal Decision-Making on the Superchain\n\n 13 days later\n\n post by Rosmari on Jun 11, 2025\n\n Rosmari\n\n Gamifying Building and Coordination on Ethereum\nHi friends,\nReady to level up? Join Optimism Fractal on Thursday at 17 UTC \nPlay the Respect Game - where builders compete collaboratively, showcase contributions, and earn awards through peer consensus on Ethereum. Plus, discover how our community just unlocked new governance achievements!\nCurious about what’s the latest around Optimism Fractal and the Town Hall? You’re welcome to explore exciting initiatives, proposals, and much more below.\nimage1280×720 163 KB\nApproved Proposals\nCross-chain Oracle Powers\nThe Optimism Fractal Council approved a game-changing proposal: the Optimism Fractal community can now perform oracle functions for Eden Fractal’s migration from EOS to Base using ORDAO! Learn how this levels up coordination in this proposal.\nWhat does this mean? Optimism Fractal can now execute onchain actions on Base, just like on Optimism. This enables acting as an oracle for Eden Fractal Epoch 1 Respect claiming. Check out the ORDAO app powering this and learn how it works in this video.\nNew game rules: Town Hall Evolution!\nThe community also approved updating Cagendas rules - implementing a 2,000 Respect vote threshold for Optimism Town Hall events. This ensures sustainable resource allocation while maintaining community-driven discussions. Read the full proposal here.\nGet Involved\nThe Respect Game transforms governance into an engaging multiplayer experience! Builders showcase contributions on the Superchain, collaboratively evaluate impact & earn Respect tokens through democratic consensus. It’s coordination gaming at its finest! Learn how to play in this article.\nExplore exciting builder contributions from Respect Game core builders in our latest episode \nHighlights include the ORDAO Fractal launch, new front end for Optimism Fractal (of.frapps.xyz), Eden Fractal’s Base deployment & new governance proposals!\nDon’t miss tomorrow’s gaming session! After the Respect Game, you’re welcome to stay for discussions about governance proposals and how they unlock new ecosystem possibilities.\nJoin us on Thursday at 17 UTC via zoom and RSVP to join optimists & shape the future of decentralized coordination!\nWe look forward to seeing you soon \n\n OF 62: Playing with the Optimism Fractal ORDAO App\n\n 13 days later\n\n post by Optimystics on Jun 25, 2025\n\n Optimystics\n\n Join Us in Uplifting Public Goods at Optimism Fractal\nHi friends,\nWe’d love to see you at Optimism Fractal this Thursday at 17 UTC \nWe’re gathering builders from across the Superchain to play the Respect Game - where you share contributions, connect with innovators, and earn recognition through peer consensus on Ethereum.\nNew to the Respect Game? It’s simple, elegant, and powerful: Share what you’re building → Connect with fellow optimists → Evaluate impact together → Submit onchain to Optimism mainnet → Earn Respect. It’s collaborative governance on Ethereum!\nimage1280×720 193 KB\nWhat’s new in our community?\nThe Optimism Fractal council recently approved cross-chain capabilities that expand coordination beyond Optimism to Base and the wider Superchain ecosystem. This opens exciting opportunities for collaboration across communities. You’re welcome to explore how we’re building bridges together in this recent announcement.\nWhat does this mean? Optimism Fractal can now execute onchain actions on Base, just like on Optimism. This enables acting as an oracle for Eden Fractal Epoch 1 Respect claiming. You’re welcome to learn how it works in this video and claim your Respect on Base here. If you have any issues, questions, or need help please reach out in this Telegram group.\nThe community also refined our governance approach with sustainable thresholds for community discussions at Optimism Town Hall, ensuring quality conversations while keeping decisions community-driven. These updates strengthen our foundation as we expand democratic coordination across Ethereum. Feel free to read more about these governance updates in this post.\nGet Involved\nThe Respect Game transforms governance into an engaging form of coordination, flourishing through consistent watering with community contributions since 2021 \nBuilders showcase progress, evaluate impact, and earn Respect tokens through democratic consensus. You’re welcome to explore this guide on benefits and ways to play!\nLatest Episode\nYou’re invited to explore exciting builder contributions from Respect Game core builders in our latest episode \nHighlights include the ORDAO Fractal launch, new front end for Optimism Fractal (of.frapps.xyz), Eden Fractal’s Base deployment, and new governance proposals!\nWe’d love to meet you!\nWhether you’re building or exploring ways to contribute, there’s a welcoming community here to support your impact. You’re welcome to RSVP at the events calendar where you can find a link to the zoom room.\nWe hope to see you Thursday at 17 UTC to meet optimists and uplift the amazing work of public goods creators \n\n OF 63: Gamified Governance\n\n 13 days later\n\n post by Optimystics on Jul 8, 2025\n\n Optimystics\n\n Hi optimists!\nWe’re excited to share the newest Optimism Fractal episode showing how Ethereum players win through innovative coordination infrastructure \nWatch public goods creators unite to present, rank, and grow efforts together! This Respect Game showcases grassroots governance innovations - from ORDAO’s cross-chain expansion to Base, to celebrating Eden Fractal’s 3-year anniversary milestone and much more \n\n OF 64: Cross-chain Collaboration\n\nKey highlights from builders:\n\nZaal building asynchronous Discord bot for people to join fractal groups\nEric Westreich seeking testers for doctoral research training program with fractals\nWill from KF Media bringing TEDx-style talks to web3 using 100% web3 tooling\nGNeric planning to integrate the Respect Game into Nouns Africa\nDan Singjoy hosted Eden Fractal’s 122nd event celebrating 3-year anniversary & wrapped up Superchain Interop Incubator by Optimism\nHarvesto researching Eden Fractal and Optimystics’ websites for case study questions\nRosmari edited videos and relayed news from previous events happening in the community\nGene for all the ongoing optimistic support!\n\nThanks all for attending \nGet Involved\nWe’d love to see you again, or meet for the first time! \nWhether you’re building innovative tools or exploring ways to contribute, there’s a welcoming community here to support your impact.\nThe Respect Game transforms governance into an engaging social consensus game, flourishing through consistent community contributions since 2021. Builders showcase progress, evaluate impact, and earn Respect tokens through democratic consensus.\nJoin us this Thursday at 17 UTC to meet and support the amazing work of public goods creators! You’re welcome to RSVP on the events calendar where you can find a link to the zoom room. All episodes are available at optimismfractal.com/videos.\nLooking forward to seeing you on Thursday \nimage1452×547 142 KB\n\n post by Rosmari on Jul 10, 2025\n\n Rosmari\n\n Fun times at Optimism Fractal & Eden Fractal events\nHey fractal friends,\nIt was wonderful being at Eden Fractal and Town Hall last Thursday - such a fascinating discussion!\nCatch up on what’s been happening and join us today at Optimism Fractal \nimage1280×720 155 KB\nEden Fractal and Eden Town Hall\nAt Eden Fractal, we explored exciting developments like Tevo’s cross-chain collaboration tools and Swarm treasury work, Will’s insights on standardized impact measurement, Tadas’s infrastructure work on ORDAO for immutable respect distribution on Base, and much more!\nAt the Eden Town Hall event we had great conversations about Flavia’s AI-powered task recommendation systems, dispute resolution processes with Tevo and Sebastian, and the exciting possibility of scaling up fractals!\nAs many of you know, recently we got to celebrate Eden Fractal hitting 3 years, so once again, we’re very grateful for all of your continuous love and support \nYou’re welcome to watch both of these videos at Eden Creators’ Youtube channel and follow progress in this forum thread. Enjoy!\nJoin us at Optimism Fractal\nThis week, you’re invited to join Optimism Fractal on Thursday at 17 UTC to collaborate with talented onchain enthusiasts, share your work, and earn awards by playing the Respect Game! This provides a great opportunity to further Eden Fractal’s mission to implement fractal decision-making processes through development, community engagement, and collaboration.\nOptimism Fractal is about recognizing contributions and fostering collaboration on the Superchain - it’s a great space for builders and public goods creators across Ethereum. Whether you’re building or exploring ways to contribute, there’s a welcoming community here to support your impact.\nYou’re welcome to RSVP at the events calendar where you can find the zoom link. Would love to see you there and have some fun!\nimage1280×720 195 KB\n\n 12 days later\n\n post by Optimystics on Jul 22, 2025\n\n Optimystics\n\n Join us for the last Optimism Fractal event before summer break \nHey all, hope you’re doing great!\nJoin Optimism Fractal this Thursday at 17 UTC for our final gathering before summer break \nAfter 6 amazing events this season, we’re taking a pause to recharge & return stronger on September 4th.\nimage1280×720 142 KB\nExplore the Latest Optimism Fractal Updates\nThis upcoming two-event summer break (skipping Aug 7 & 21) gives community contributors essential rest while creating space for technical development & ecosystem engagement. Learn more about our strategic pause & vote on the proposal.\nBefore our break, catch up on our latest episode, which brings together onchain builders exploring gamified experiences, mining apps, arena-style Respect Games & more! \nStay Involved—Eden Fractal & Town Hall Run Next Week\n…Don’t you worry! Next week: Eden Fractal & Eden Town Hall continue as scheduled. After the break, both Optimism Fractal & Eden Fractal return Sept 4th with aligned event numbering.\nReady to wrap up Optimism Fractal Season 6’s first half with us? Join Thursday at 17 UTC to play the Respect Game, connect with builders on Ethereum, and celebrate our collective achievements before the summer pause.\nYou’re welcome to RSVP at the events calendar where you can find a link to the zoom room.\nLooking forward to seeing you there \n\n 1 month later\n\n post by DanSingjoy on Sep 2, 2025\n\n DanSingjoy\n\n Welcome to Optimism Fractal’s Return! \nAfter our refreshing six-week summer break, I’m thrilled to invite everyone to join us this Thursday, September 4th at 17 UTC for our 67th event. Together we’ll embark on the second half of Optimism Fractal’s sixth season, continuing our mission awarding public goods creators, fostering collaboration, and optimizing governance on the Superchain.\nThis Thursday, we’ll gather for our beloved Respect Game where you’ll enter breakout rooms, share your work, and rank contributions to the Ethereum and Optimism Superchain. Everyone is welcome to join, earn respect for their contributions, and network with innovators across the ecosystem - whether you’re a seasoned contributor or completely new. You don’t need any prior experience to get involved and your participation itself is a valuable contribution!\nFor those who haven’t been following closely over the past month and a half, it’s been an eventful break with exciting progress across multiple fronts. Here are some highlights from the three ecosystems that Optimism Fractal supports:\n\nEthereum Ecosystem: Ethereum recently celebrated its 10-year anniversary with thousands of builders and creators contributing to one of the largest open source communities in the world. The Ethereum Foundation’s new leadership is coordinating ecosystem growth more efficiently than ever. This vibrant community growth has translated to market success, with the valuation of ETH more than doubling in recent months and crossing an all-time high market cap of nearly $600 billion. There has been increasing institutional adoption through ETFs, treasury vehicles, and successful companies like Robinhood and Blackrock, while stablecoins on Ethereum have soared to reach a value of over $160 billion. All this growth in the Ethereum ecosystem provides more potential funding sources, collaborators, and open source software that creates fertile ground for Optimism Fractal and fractal governance to flourish.\n\nThe Superchain: The ecosystem continues its remarkable expansion with two new networks - Ronin Network (the gaming blockchain home to Axie Infinity) and Superform - now building on the OP Stack. Base has reached all-time highs in TVL while Worldchain continues onboarding millions monthly, with major chains like OP Mainnet, Unichain, Ink, Celo, and Soneium (from Sony) also making significant progress. Applications like Zora, Farcaster, and Aerodrome are experiencing outstanding growth and providing new kinds of valuable experiences onchain. The Optimism Collective recently embarked on it’s eight season, featuring important updates to its governance system and opportunities for contributors. The OP Stack now powers over 70% of Layer 2 transactions, serving as the primary way Ethereum scales its technology and values.\n\nFractal Ecosystem: The Fractal Impact Concert organized by EZ was a great success, beautifully merging art, music, and governance innovation. Eden Fractal returned from its break with the implementation of the Eden+Fractal consensus process - a legislative consensus mechanism comparable to the Optimism Fractal Council. This process enables delegate elections in Eden Fractal Epoch 2 and provides opportunities for participants to play leading roles in pursuit of its mission to implement fractal decision-making processes throughout society. ZAO Fractal continues demonstrating how fractal governance can benefit communities of creators, while other communities are becoming increasingly interested in fractal governance. Several new videos have been released on the Eden Creators youtube channel featuring episodes of Eden Fractal, Optimism Fractal, and Eden Town Hall.\n\nAs we approach Optimism Fractal’s two-year anniversary in October, it’s remarkable to see how far we’ve come. Our consistent weekly gatherings have proven the reliability and power of fractal democracy, building tremendous momentum for the future of fractal communities growing on Ethereum. I’m excited to hear about everyone’s contributions and what you’ve all been up to during the break.\nLooking forward to reuniting this Thursday and taking the first step toward planning an exciting anniversary celebration while preparing to mapping out all the great things we’ll accomplish in our third year, and of course getting back to our roots playing Optimism Fractal respect games. RSVP on the Optimystics Optimystics events calendar to join us on Thursday at 17 UTC, and feel free to invite friends!\nfuture city OF respect game mission conclusion 21536×653 97.6 KB\n\n 15 days later\n\n post by Optimystics on Sep 17, 2025\n\n Optimystics\n\n Toward a Playful Protopia: The Optimism Fractal Experiment\nHey all,\nJoin us on Thursday at 17 UTC for Optimism Fractal as we continue pioneering collaborative governance across the Superchain \nPlay the Respect Game with talented builders and help shape the future of decentralized coordination through playful protopia!\nimage1280×720 171 KB\nThe second half of Season 6 began with players bringing fresh updates from the summer break \nWhile playing the Respect Game, we celebrated contributions to the Ethereum ecosystem, explored ideas to strengthen coordination in communities & much more. Check out our latest video to see what happened during the last event.\nHighlights include a deep dive with Eric into his game-changing Simbiosyx platform!\nTogether with his team at Aquallius, Eric is reimagining how startups connect with experts through sweat equity, while exploring ways to integrate Respect tokens with equity distribution with Dan Singjoy. We invite you to explore more amazing contributions in this episode’s show notes.\n\n OF 67: Welcome Back & Discussion on Eric’s Initiatives\n\nGet Involved\nAs we approach our 2-year anniversary this October, we’re excited to continue building the future of the internet together!\nThe Respect Game, played at each event, provides an engaging space for everyone to showcase their work and earn recognition through peer consensus on Ethereum. You get the opportunity to share what you’ve done to contribute to Optimism, then collaboratively rank peers’ contributions & earn Respect tokens. Let’s Grow!\nYou’re welcome to RSVP at the events calendar where you can find a link to the zoom room.\nLooking forward to seeing you there \n\n 14 days later\n\n post by Optimystics on Oct 2, 2025\n\n Optimystics\n\n Hey friends,\nJoin us now at Optimism Fractal as we continue pioneering collaborative governance on Ethereum \nPlay the Respect Game with talented builders scaling the peaks of decentralized coordination across the Superchain & beyond!\nOF 69 thumbnail1280×720 127 KB\nAt our last event, builders showcased the essence of protopian building - gradual improvement through playful coordination.\nWatch builders demonstrate how the Respect Game transforms governance from a burden into an engaging & playful social experience. Check out the latest video to see what happened during the last event!\nCommunity highlights\nExperience the magic as Harvesto unveils groundbreaking fractal research with Douglas about his experience with Genesis Fractal and being a founder of Aquadac, Will expands Web3 education across Latin America while pioneering onchain TEDx-style talks, Zaal bridges ETH Boston to Nigerian artists with Wave Warz, Tadas ensures immutable Respect distribution & Dan hosts community events fostering collaboration, while supporting onboarding efforts.\nWe invite you to explore more amazing contributions in this episode’s show notes.\n\n OF 68: Collaborative Governance\n\nGet Involved\nAs we approach our 2-year anniversary this October, we’re excited to continue building the future of the internet together!\nThe Respect Game, played at each event, provides an engaging space for everyone to showcase their work and earn recognition through peer consensus on Ethereum. You get the opportunity to share what you’ve done to contribute to Optimism, then collaboratively rank peers’ contributions & earn Respect tokens.\nYou’re welcome to RSVP at the events calendar where you can find a link to the zoom room.\nLooking forward to seeing you there \n\n 13 days later\n\n post by DanSingjoy on Oct 15, 2025\n\n DanSingjoy\n\n Hey all, we have some excellent events lined tomorrow that I’m excited to share with you! These gatherings offer meaningful opportunities to connect with talented builders, participate in groundbreaking research, and help celebrate an important milestone in Optimism Fractal’s journey.\nThis Thursday we’ll meet for the Optimism Fractal Respect Game at 17:00 UTC and Optimism Town Hall at 18:00 UTC. As always, the Respect Game provides an excellent way to connect with visionary community members, showcase your work, and earn Respect while pioneering fractal democracy on the Superchain. Following the Respect Game, we’re bringing back Optimism Town Hall with two important topics: briefly reviewing a draft proposal for Optimism Fractal’s upcoming two-year anniversary and hosting an orientation for Eric Westreich’s research on appreciation and volunteer motivation using fractal coordination.\nFollowing the brief anniversary planning discussion, Eric will host a run-through of his doctoral study “Measuring the Impact of Appreciation on Nonprofit Volunteer Motivation,” which examines how peer appreciation in fractal governance impacts volunteer motivation within nonprofit organizations. This session will gather feedback on the exact training that prospective research study participants will receive when the study launches on November 1st—helping make the training clearer, more concise, and more compelling. The run-through provides a friendly introduction for anyone curious about the research. You can read more or sign up via the Volunteer Consent and Interest Form.\nEveryone is welcome to join these events—whether you’re new to Optimism and Fractals or an experienced community member, we’d love to see you there. You can learn more about the Optimism Town Hall topics in the approved topic proposal and RSVP for all events on the Optimystics events calendar. Hope to see you at the there!\nevents presented by Optimystics Thursday October 1621280×720 964 KB\n\n 12 days later\n\n post by DanSingjoy on Oct 28, 2025\n\n DanSingjoy\n\n Dear members of the Optimism Collective,\nFollowing up on recent community discussions. I’ve created a proposal on the Optimism Fractal snapshot space to start Season 7 on January 22nd, 2026. While last week’s draft proposed starting two weeks earlier, we discussed this at Eden Town Hall and agreed that the additional two weeks would better serve the community—providing more time for family, rest, and preparation. You can watch our discussion in this video.\nThe proposal above includes comprehensive context, rationale, and voting details. Voting will remain open until this week’s event at 17:00 UTC on October 30th. The Optimism Fractal Council will vote on this proposal as per our intent document. Note that the related proposal to start Eden Fractal Season 12 on January 15th was approved, so the usual biweekly cadence on the Optimystics Events Calendar would begin one week before Optimism Fractal returns.\nThank you all for an amazing season and past two years! I’m excited to reconvene and celebrate our two-year anniversary on Thursday! \n\n post by Optimystics on Oct 29, 2025\n\n Optimystics\n\n Come Celebrate! Optimism Fractal Turns Two \nHi friends,\nJoin us this week for Optimism Fractal at 17 UTC and Optimism Town Hall at 18 UTC, as we celebrate two years of collaboration and look ahead to what’s next \nOF 71 thumbnail1280×720 349 KB\nAt Optimism Fractal, we’ll be playing the beloved Respect Game and celebrating the spirit of cooperation that’s brought our community this far.\nThen at Optimism Town Hall, there’ll be an open space for community conversations about the future, as well as reflecting on our path, sharing ideas, and setting our sights on the year ahead.\nYou’re welcome to RSVP at the events calendar where you can find a link to the zoom room. Daylight savings time has ended in some time zones, so please double-check your local meeting time & don’t forget to wear your party hats!\nLooking forward to seeing you there \n\n post by DanSingjoy on Oct 30, 2025\n\n DanSingjoy\n\n GM Optimism Collective! \nOptimism Fractal celebrates two years of fostering collaboration, awarding public goods creators, and optimizing governance on the Superchain. We invite all Collective members to join us today at 17:00 UTC as we mark this milestone and discuss our continued contributions to Superchain governance.\nGrowing on Optimism\nTwo years ago, Optimism Fractal launched with a vision: to bring proven democratic coordination mechanisms to the Superchain and help the Optimism ecosystem develop innovative governance, community growth, and capital allocation solutions. What started as an experiment has evolved into a consistent practice, with over 100 unique participants joining our events and contributing to the ecosystem’s growth. Week after week, regardless of market conditions, our community has demonstrated that sustainable, democratic governance is possible onchain.\nSuperchain Impact\nThrough our weekly Respect Games and related community discussions at Optimism Town Hall, the Optimism Fractal community has participated in creating over 100 educational videos that serve as resources for the broader ecosystem. We’ve successfully implemented and operated ORDAO for nearly a year, while the Optimism Fractal Council has functioned as our legislative branch for over 20 months. These aren’t just experiments - they’re working governance systems that demonstrate practical approaches to the challenges the Collective faces.\nOur impact extends beyond our immediate community. Organizations and projects throughout the Superchain have adopted elements of our governance model, and communities worldwide are implementing fractal governance inspired by our work. As the Superchain approaches full interoperability and major networks like Base, World, and Unichain continue supporting breakout applications, the need for effective coordination mechanisms becomes even more critical.\nToday’s Celebration\nToday’s event begins with our regular Respect Game at 17:00 UTC, where participants earn Respect by presenting their contributions to the ecosystem. This process, refined over two years, creates accountability, recognition, and alignment without centralized control.\nFollowing the game, we’ll host an anniversary discussion at Optimism Town Hall, where we’ll reflect on our journey, share insights from two years of governance experimentation, and discuss how we can better serve the Collective’s needs in Season 8 and beyond. Feel free to explore our Optimism Town Hall discussion where we initially planned this anniversary celebration.\nYou’re welcome to use Optimism Fractal thumbnails as Zoom backgrounds (find them at OptimismFractal.com/videos) or dress festively if you’d like. We expect good conversation about both our achievements and the challenges ahead as we enters our next phase of growth.\nLooking Forward\nAs we enter our third year and the Optimism ecosystem continues evolving, we’re focused on deeper integration with the Collective and more direct contributions to Superchain governance challenges. Ethereum just turned ten years old, and as we head into 2026, the world is increasingly coming onchain. The Superchain has the opportunity to shape this transition, and effective governance will be crucial to that success.\nWe invite you to join us for today’s to learn more about our work, share your perspectives on governance challenges, and explore how Optimism Fractal can better serve the Collective’s goals. Whether you’re deeply involved in governance or simply curious about alternative coordination mechanisms, your participation enriches the discussion. As always, you can RSVP for both the Optimism Fractal Respect Game and Optimism Town Hall on the Optimystics events calendar.\nFor more details about the event and our impact over the past two years, see our full anniversary proposal. Hope to see you join us as we celebrate two years of building on the Superchain and plan for even greater impact in year three!\nbirthday 2 image 44 copy790×483 191 KB\n\n 12 days later\n\n post by Optimystics on Nov 11, 2025\n\n Optimystics\n\n Join Us for the Season 6 Finale - Optimism Fractal’s Final Events of 2025\nEveryone is welcome to join us on Thursday for the final Optimism Fractal Respect game and Optimism Town Hall of the season \nThese events mark the conclusion of Optimism Fractal Season 6 and our last gatherings before the winter break, offering valuable opportunities to connect with the Optimism Fractal community, reflect on our achievements, and plan for the next year.\nimage1280×720 431 KB\nWe’ll start with the Respect Game played at Optimism Fractal at 17:00 UTC, bringing together builders and governance participants. This collaborative game allows you to showcase your work, build reputation within the ecosystem, and network with others building on the Superchain. For two years, the Respect game has been the cornerstone of our community, fostering meaningful connections and collaborations building playful dystopia.\nThe Optimism Town Hall follows at 18:00 UTC, providing an open forum to recap Optimism Fractal Season 6, discuss progress across the Optimism Superchain in 2025, and continue conversations from our recent two-year anniversary celebration. We may share thoughts going into the winter break and begin planning for next season, with our next gathering scheduled for January 22nd, 2026.\nCommunity highlights\nIn the meantime, you’re welcome to check out our recent Optimism Fractal 2-year anniversary video highlighting community contributions (including new app development, ORDAO v1.4, and fractal research), plus the Town Hall episode featuring discussions about Dan’s Gardens ideas and Tadas’s Synchronous Respect Trees game.\n\n OF 71: Optimism Fractal 2 Year Anniversary\n\n OTH 41: Gardens, Respect Trees & Planning\n\nWe invite you to explore more amazing contributions and updates in recent episode show notes. Enjoy!\nGet Involved\nThank you to everyone who has made Optimism Fractal Season 6 successful through your participation and contributions \nWe encourage you to check out our recent anniversary videos, join the Discord server for more conversations, and RSVP through the Optimystics event calendar.\nWhether you’re a longtime participant or discovering our community for the first time, this is an excellent opportunity to connect with builders, contribute to governance discussions, and help shape the future of the Superchain.\nLooking forward to seeing you soon,\n\n 2 months later\n\n post by DanSingjoy on Jan 21\n\n DanSingjoy\n\n Dear Members of the Optimism Collective,\nI hope everyone had a wonderful holiday season and enjoyed the break. I’ve been following the news about Optimism Season 9 and am excited to see the new direction taking shape. A lot has happened over the past couple months, and I have some exciting news to share with you—both personal and about Optimism Fractal.\nFirst, I’d like to let you know that the video for Optimism Fractal’s Season 6 Finale—is now published on the Eden Creators YouTube channel and can now watch it here. This was an unusual event. For the first time ever in Optimism Fractal’s history, I was the only one present—which became an interesting signal about where to focus our resources. Since it was already the scheduled final event of the season, I decided to still record an episode and try something new: a solo Respect Game format.\nThe video starts with a funny little blooper reel of me trying to figure out how to host the show on my own without anyone else there. From there, I give an introductory presentation on Optimism Fractal and share some recent community news. I then explain why I see value in this solo Respect Game approach — it can help make fractals more resilient in early stages by allowing hosts to still run the game even when people can’t make it, as long as the community agrees through the ORDAO process.\nIn this experimental format, I ranked myself and five others who have recently contributed to Optimism Fractal’s mission. I’ve just created a belated ORDAO proposal to distribute Respect to these community members for this game—you can now vote on it at https://optimism.frapps.xyz if you’d like. You can watch the video to see my recent contributions to Optimism and rationale for giving respect to these community members. At the end of the video, there’s also a small town hall segment where I discuss the state of the Optimism Collective and Optimism Fractal.\n\n OF 72: Community Recognition\n\nGetting Married & Growing Together\nNow for some very exciting personal news. During that event, I announced that I was engaged to Rosmari—and I’m thrilled to let you all know that we got married over the winter break!\nFor those who may not be familiar, @Rosmari is a co-founder of both Optimism Fractal and the Optimystics team. We actually met at Eden Fractal about three years ago, at the community’s 35th event. It’s truly amazing how fractals and Optimism can bring together people from across the world and lead to such meaningful connections. We had the pleasure of meeting Zaal (founder of ZAO Fractal) at the wedding, and we’re deeply grateful for all the times we’ve shared with the Optimism Fractal community. She’s planning to rejoin fractal community events once we resolve some visa restrictions, and we’re thrilled for our next steps together.\nI apologize for the delay in releasing this video and the ORDAO proposal—usually these come out within a week of the event, but this is two months later. Between preparing for the wedding, family obligations over the holiday season, and working to support different members of the fractal ecosystem, I simply haven’t had the time to get to the video editing until now. I’ll aim to share future videos more promptly in the future, but frankly I just had too much on my plate and I’ve realized the need to focus more on the highest priorities. Which leads to the next announcement…\nimage1920×1280 221 KB\n\n post by DanSingjoy on Jan 21\n\n DanSingjoy\n\n Announcing Optimism Fractal’s Hiatus\nI’ve submitted a proposal to the Optimism Fractal Council for an indefinite strategic hiatus of Optimism Fractal events.\nAs you may remember, we had planned to return for Optimism Fractal Season 7 on January 22nd. However, after careful deliberation over the past couple of months, Tadas and I have decided that it makes more sense to pause Optimism Fractal and consolidate our resources in Eden Fractal.\nAs explained in our community intent document, the Optimism Fractal Council operates through a legislative consensus process where community members who have earned Respect can register as Council members during each period between Respect Game events. In the most recent period, only Tadas and I registered, which means we have the legislative authority to make this decision. As both councilors and cofounders of Optimism Fractal (and the Optimystics), @Tadas and I are confident that this is the right decision for the community.\nThis decision was first suggested by Tadas back in mid-November, in the days after Optimism Fractal’s last event of the season. Tadas proposed a topic proposal about this in the Eden Fractal telegram group and then we discussed it at the Eden Town Hall on November 20th. I invited everyone from the Optimism Fractal community to join that conversation and, after thinking about it very carefully, the direction became clear — we’re better off focusing our energy on Eden Fractal. Zaal and other community members who participated were also fully supportive. You can watch the full discussion in the 67th Eden Town Hall video on the Eden Creators YouTube channel.\nSince then, Tadas and I have spoken about this several more times, including at last week’s Eden Town Hall, and we remain in complete agreement. He voted to approve the proposal earlier today. As such, we’ve decided to indefinitely postpone Optimism Fractal Season 7 and will meet for a community discussion at Eden Town Hall on January 22nd at 16 UTC instead of an Optimism Fractal Respect Game.\n\n ETH 67: Strategic Planning for Optimism Fractal Hiatus\n\nWhy We’re Making This Decision\nEden Fractal is the foundational community from which Optimism Fractal emerged. It’s been working to implement fractal decision-making processes throughout society since 2021, and it has a clear vision and mission that needs more resources to fulfill.\nSince Eden Fractal launched its Epoch 2 initiative last May, Eden Fractal has been building on Base—part of the Superchain—and is directly advancing Optimism Fractal’s mission of fostering collaboration, recognizing public goods creators, and pioneering better governance on the Superchain. So even though we’re pausing Optimism Fractal, we’re continuing to build on the Superchain and support Optimism’s ecosystem.\nThere’s been a lot of exciting momentum in the fractal ecosystem lately. Several new initiatives are sprouting up and there’s a lot of work to be done to support this growth. Eden Fractal is the natural home for that support. Meanwhile, splitting our attention between communities has become unsustainable — we haven’t been able to give either Eden Fractal or Optimism Fractal the attention they each deserve. This showed up clearly in Optimism Fractal when I was the only person at our last event, which became a meaningful signal about where to direct our energy. At the same time, Eden Fractal has been generating significant excitement that warrants more of our attention. By focusing our energy on Eden Fractal, we can strengthen our core infrastructure. provide more attention to the growing ecosystem of fractal communities, and prepare our tools for implementation at a greater scale.\nAdditionally, the Optimism Foundation recently announced significant changes for Season 9. They’re shifting away from community-led capital allocation, including pausing Retro Funding for 12+ months and planning to dissolve the Grants Council. Community-driven capital allocation and governance is precisely what Optimism Fractal was designed to demonstrate. This news reaffirmed our already agreed-upon decision that this is the right time to refocus our energy.\nFractal governance is beneficial for all communities and organization on any blockchain. Right now, Eden Fractal and several other fractal communities are building on the Superchain, and we plan to continue supporting the Superchain that way. But Eden Fractal’s broader mission—implementing fractal decision-making throughout society—positions us to support fractal governance wherever it takes root.\nThis is essentially wrapping up Optimism Fractal’s first six seasons as a successful experiment in which we made significant progress toward our goals. It’s also laying the groundwork for an eventual return when conditions in both the fractal ecosystem and the Optimism Collective are more aligned.\nYou can follow our progress continuing Optimism Fractal’s mission at Eden Fractal in the Eden Fractal Optimism Governance Forum Thread and learn more about some of our experiences with the Optimism Collective’s funding mechanisms in this draft article.\nWhat Happens Now\nThe ORDAO app at optimism.frapps.xyz and the smart contracts continue to function. Your Respect tokens remain, and you can still use them to vote on proposals through ORDAO and Snapshot. The ORDAO branch of our governance stays active and can reactivate the Respect Game events and Optimism Fractal Council when the community decides the time is right.\nAll 72 Optimism Fractal event videos, over 40 Optimism Town Hall recordings, and all our documentation is still available. You can find these resources on our websites and watch all the videos on the Eden Creators YouTube channel. Optimism Town Hall will also enter an indefinite hiatus—I’ll be hosting Eden Town Hall in its place. This Discord also stays open — feel free to keep chatting here. However, I’d recommend joining the Eden Fractal telegram group chat, which is much more active and the best place to keep in touch with updates from the fractal ecosystem.\nI also want to let you know that the Optimystics events calendar has transitioned to the Eden Creators events calendar. This goes along with our shift in resources to support the Eden Fractal ecosystem. If you were subscribed to Optimystics events, you’ll now receive invitations from Eden Creators. The Optimystics’ educational materials remain available as well, but I’ll be focusing more on work with Eden Creators going forward to support the Eden community.\nJoin Eden Fractal\nEveryone from Optimism Fractal is warmly invited to continue the journey at Eden Fractal. Whether you’ve been deeply embedded in the fractal ecosystem or you’re building on Optimism and curious about better governance and coordination—you’re welcome to join us.\nThis Thursday, January 22nd at 16 UTC—the same day Optimism Fractal was scheduled to return—we’ll be hosting an Eden Town Hall instead and we may meet for two hours. We’ll be discussing Eden Fractal’s schedule for Season 12 (we’re deciding between weekly and bi-weekly events) and welcoming anyone from the Optimism Collective to share their thoughts about Optimism Fractal, Eden Fractal topics, and more. We’d love to see you there!\n Explore Eden Fractal: https://edenfractal.com\n Register for events: Eden Creators · Events Calendar\n Join the conversation: Telegram: View @edenfractal\n Watch Videos: https://www.youtube.com/@EdenCreators\n Explore Eden Town Hall: https://edentownhall.com/\n Optimism governance forum thread: Eden Fractal Epoch 2: Implementing Fractal Decision-Making on the Superchain\nConclusion\nI believe Optimism Fractal will return when the time is right. I don’t know exactly when that will be, but when both the fractal ecosystem and the Optimism Collective are more ready for this kind of collaboration, we can pick up where we left off through our existing consensus processes. I’m excited for that day. Until then, I really hope to see everybody at Eden Fractal.\nI want to thank everyone for all the wonderful experiences and the things we’ve built together over the past two years. We met so many amazing people here who played pivotal roles in helping Optimism Fractal and helping the broader fractal ecosystem grow. Thank you for being here, sharing your work, and believing in this vision. It’s been a great pleasure and a very special time in my life, and I’m deeply grateful for everyone’s participation.\nFor more details on Optimism Fractal’s hiatus, you can read the proposal linked above and stay tuned for upcoming articles. Thank you all for everything. Go Eden Fractal, go Optimism Fractal, and go Optimism! \n\n Eden Fractal Epoch 2: Implementing Fractal Decision-Making on 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 Optimism Fractal Season 5: Level Up with Weekly Respect Games on the Superchain\n\n ✨ General\n\n Welcome to Season 5 of Optimism Fractal!\nAfter an incredible first year bringing builders together through innovative onchain social games, we’re excited to begin our next chapter with powerful new tools and growing mome…\n\n read more\n\n 33\n\n 788\n\n Jul 2025\n\n Optimism Fractal Weekly Events\n\n Community Calls\n\n Hey Optimists! \nYou’re invited to join Optimism Fractal events on Mondays at 17 UTC \nOptimism Fractal is a community dedicated to fostering collaboration and awarding public goods creators on Optim…\n\n read more\n\n 15\n\n 1.6k\n\n Apr 2024\n\n Optimism Fractal Season 4\n\n Community Calls\n\n Dear Optimists, \nOptimism Fractal is returning from summer break and we’re excited to embark on Season 4! We’re looking forward to reconnecting at our weekly events and invite you to join! \nOptimism Fractal events kick o…\n\n read more\n\n 21\n\n 458\n\n Nov 2024\n\n Optimism Fractal Season 3\n\n Community Calls\n\n Hey friends! Join us for the first event of Optimism Fractal Season 3! \nWe’re excited to start the season in style with a Respect Game to grow Optimism, then discuss a new proposal in today’s planning session…\n\n read more\n\n 19\n\n 1.3k\n\n Jul 2024\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 33\n\n 711\n\n 11h","tokens":14161,"squid":"spider-07","role":"Council Spider","at":1791345944729,"hash":"e40e24b51a3a06a20e9d4954036ff07ced927005"}
{"url":"https://www.metaplex.com/docs/solana/solana-programs","domain":"metaplex.com","title":"Solana Programs and State Overview | Guides","text":"Solana ProgramsSolana programs are executable code that runs on the Solana blockchain. They are similar to smart contracts on other blockchain platforms, but with some distinct characteristics and optimizations specific to Solana.Key Characteristics:Stateless: Solana programs do not store state internally. Instead, state is stored in separate accounts on the chain.Written in Rust: Programs are typically written in Rust.Executed by Transactions: Programs are invoked by transactions that specify the program ID and the required accounts and data.AccountsAccounts used to store both data and SOL. Each account has an owner, which is a program that can modify its data.Types of Accounts:Data Accounts: Store arbitrary data used by programs.SPL Token Accounts: Manage token balances (similar to ERC-20 tokens on Ethereum).Program Accounts: Contain the executable code of a Solana program.InstructionsInstructions are operations sent to Solana programs. They are included in transactions and specify which accounts the program should operate on, as well as any additional data needed to perform the operation.Key Elements of Instructions:Program ID: Identifies the program to be executed.Accounts: A list of accounts that the instruction will read from or write to.Data: Custom data required to perform the instruction.State ManagementIn Solana, the state is managed externally from the programs, stored in accounts. This separation of state and logic enables higher scalability and efficiency.State Management Workflow:Account Creation: Create accounts to store data.Program Execution: Execute a program with instructions specifying which accounts to read from or write to.State Update: Programs modify the state by updating the data in accounts.Example WorkflowDefine a Program:Write a program in Rust to perform a specific task, such as incrementing a counter.Deploy the Program:Compile and deploy the program to the Solana blockchain.Create Accounts:Create accounts to store the program's state.Send Instructions:Send transactions containing instructions to invoke the program, specifying the accounts and data to use.Example CodeBelow is a simple example of a Solana program written in Rust that increments a value stored in an account.use solana_program::{\n account_info::{next_account_info, AccountInfo},\n entrypoint,\n entrypoint::ProgramResult,\n pubkey::Pubkey,\n msg,\n program_error::ProgramError,\n};\n\nentrypoint!(process_instruction);\n\nfn process_instruction(\n program_id: &Pubkey,\n accounts: &[AccountInfo],\n instruction_data: &[u8],\n) -> ProgramResult {\n let accounts_iter = &mut accounts.iter();\n let account = next_account_info(accounts_iter)?;\n\n // Ensure account is owned by the program\n if account.owner != program_id {\n msg!(\"Account is not owned by the program\");\n return Err(ProgramError::IncorrectProgramId);\n }\n\n // Deserialize instruction data (increment value)\n let increment_amount = instruction_data[0];\n\n // Increment the value\n let mut data = account.try_borrow_mut_data()?;\n data[0] = data[0].wrapping_add(increment_amount);\n\n msg!(\"Value after increment: {}\", data[0]);\n\n Ok(())\n}","tokens":777,"squid":"dotcat","role":"Tooling Spider","at":1791345946942,"hash":"fba1b3c439626cf352dc97ca2d8158c902442d25"}
{"url":"https://gov.optimism.io/c/updates-and-announcements/48","domain":"gov.optimism.io","title":"Latest Updates and Announcements 📢 topics - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n Latest topics in Updates and Announcements 📢\n\n Updates and Announcements 📢\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 Updates and Announcements category\n\n Updates and Announcements 📢\n\n 0\n\n 3.2k\n\n Jan 2023\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 33\n\n 711\n\n 11h\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 345\n\n 3d\n\n Governance Update #12\n\n Governance Updates\n\n season-9\n\n Governance Update #12\nToday marks the last day of Season 9! Thank you to everyone who participated in Season 9 and the broader governance experiments Optimism has run over the past four years. Your contributions have not…\n\n read more\n\n 2\n\n 299\n\n Jun 8\n\n S8 & S9 Milestones and Metrics Council Communication Thread\n\n Governance Updates\n\n season-8,season-9\n\n This thread will serve as the Milestones and Metrics Council Communication Thread for S8 and S9. Like prior seasons, the M&M Council will be responsible for assessing and tracking milestones for grants that have passed t…\n\n read more\n\n 1\n\n 148\n\n Apr 20\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\n\n Optimism Fractal Season 6: Expanding Democratic Coordination Across the Superchain\n\n Community Calls\n\n Welcome to Season 6 of Optimism Fractal!\nAfter an exceptional journey of fostering collaboration through innovative onchain social in our first five seasons, we’re excited to embark on a new chapter with enhanced tools a…\n\n read more\n\n 18\n\n 864\n\n Jan 21\n\n Season 9 Community Call Questions\n\n Updates and Announcements 📢\n\n The Foundation will be hosting a community call with leadership from the Optimism Foundation on Tuesday, January 20th at 6:30pm GMT to discuss Season 9 and answer any remaining questions. \nPlease note - this call will no…\n\n read more\n\n 4\n\n 201\n\n Jan 20\n\n Scheduled Maintenance – November 26, 2025\n\n Updates and Announcements 📢\n\n Hello Optimists, \nWe will be implementing a reorganization of select areas of the forum on November 26, 2025. This will be a restructure, and no service interruptions are expected. \nThank you for your attention and conti…\n\n read more\n\n 2\n\n 96\n\n Nov 2025\n\n Optimism Town Hall Season 4: Growing the Superchain Through Collaborative Governance\n\n Community Calls\n\n Welcome Back to Optimism Town Hall! After a refreshing six-week spring break, we’re excited to announce the return of Optimism Town Hall for its fourth season, beginning today, May 15th! \nThis thread serves as your centr…\n\n read more\n\n 8\n\n 255\n\n Nov 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 Explore the Dark Forest Punk R1 - Now Live on OP Mainnet\n\n Updates and Announcements 📢\n\n On behalf of the DFArchon team, I’m excited to announce that Dark Forest Punk R1 has been deployed on the OP mainnet! \nAccess it here: https://r1.dfpunk.xyz \nWe’ll be hosting a two-week public test event, and everyone is…\n\n read more\n\n 1\n\n 99\n\n Oct 2025\n\n govNERDs Office Hours\n\n Updates and Announcements 📢\n\n season-8\n\n — come hang, ask, share \nWhy: to create an open space for delegates to gather, ask questions, and share feedback. \nWhat: a chill, curiosity-friendly session for anyone in the Collective who wants to r…\n\n read more\n\n 1\n\n 82\n\n Oct 2025\n\n [Recording & Recap] 22nd OP Community Governance Call\n\n Community Calls\n\n Hey Optimists! \nRecording Link: June 20th, 2023 community call.mp4 - Google Drive \nGreat call with a lot of discussion, here are some of the highlights: \n\nKYC for Grants:\n\nIn the case of a single grant recipient, the own…\n\n read more\n\n 6\n\n 1.6k\n\n Sep 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 Superchain Product Vision\n\n Updates and Announcements 📢\n\n Superchain Product Vision\nLasted Updated October 8, 2024 This is a living document. \nOptimism is here to scale Ethereum technology and values & build an internet that benefits all, and is owned by all. No matter what hap…\n\n read more\n\n 13\n\n 2.8k\n\n Aug 2025\n\n 4337 Superchain Data Standards Group - Project update\n\n Grant Updates\n\n 4337 Superchain Data Standards: Project Update\nPurpose\nOn 13th August 2024 a grant was approved to create a 4337 Data & Standards group. Due to growing adoption of the ERC-4337 (a.k.a. Account Abstraction) standard creat…\n\n read more\n\n 0\n\n 135\n\n Aug 2025\n\n Token Sale – September 2023\n\n Updates and Announcements 📢\n\n An update to the community: \nOptimism has entered into a private token sale of approximately 116M OP tokens, split among seven purchasers, for treasury management purposes. The tokens are subject to a two-year lockup. Du…\n\n read more\n\n 26\n\n 9.7k\n\n Jul 2025\n\n Welcoming Test in Prod to the Optimism Collective\n\n Updates and Announcements 📢\n\n Back in June, the OP Labs’ engineering blog shared a guest post from the team at Test in Prod. \nBeyond their excellent work on op-erigon, the blog post made something exceptionally clear: the TiP team is fully bought in …\n\n read more\n\n 15\n\n 2.0k\n\n Jul 2025\n\n Joint House Community Call July 15th\n\n Community Calls\n\n Hello Optimism Governance Fam! \nOur next Joint House Community Call will be held on July 15th. \nThe budget board will be joining us to discuss their latest proposals. This call will not be recorded \n@SEEDGov has posted a…\n\n read more\n\n 0\n\n 93\n\n Jul 2025\n\n WakeUp Labs - General Comms Thread Our Journey on Optimism\n\n Updates and Announcements 📢\n\n TL,DR.\nWakeUp Labs is a studio offering advanced development services to EVM-Compatible Chains, DAOs, and businesses. This summary provides a brief overview of the company, to later provide a timeline of contributions to…\n\n read more\n\n 10\n\n 1.6k\n\n Jul 2025\n\n Exactly Protocol and the Exa App - Scaling onchain finance on Optimism\n\n Updates and Announcements 📢\n\n Intention\nThis post will serve as the first entry in a growing thread that outlines the history, vision, and contributions of Exactly Protocol and the Exa App to the Optimism ecosystem. We’ll use this space to transparen…\n\n read more\n\n 3\n\n 326\n\n Jun 2025\n\n Joint House Community Call June 17th\n\n Community Calls\n\n Hello Optimism Governance Fam! \nOur next Joint House Community Call will be held on June 17th. \nThe Foundation will be joining us to present on Season 8 and then do a Q&A. \nLink for the call can be found on the Optimism …\n\n read more\n\n 1\n\n 75\n\n Jun 2025\n\n Agora’s Governance Changelog\n\n Updates and Announcements 📢\n\n GM Collective, \nAt Agora, are constantly shipping onchain governance to make the Optimism Collective’s voting and delegation process as easy, effective and safe as possible. We will be using this thread to capture update…\n\n read more\n\n 4\n\n 321\n\n Jun 2025\n\n Joint House Community Call [May 20th 18:00 UTC]\n\n Community Calls\n\n Hello Optimism Governance Fam. We are shifting to hosting one Community Call each month. This will be the Joint House Community Call. \n Our next Joint House Community Call will be held on May 20th. \n…\n\n read more\n\n 4\n\n 192\n\n May 2025\n\n Superscan: New explorer for the Superchain by Walnut\n\n Updates and Announcements 📢\n\n season-5,cycle-19\n\n On behalf of the Walnut team, I am excited to announce that we have reached Milestone 4 of the SuperScan project, which received an OP grant in Season 5, cycle 19. This is the final Milestone and marks the completion of…\n\n read more\n\n 0\n\n 157\n\n Apr 2025\n\n Voting Cycle Guide #36\n\n Updates and Announcements 📢\n\n season-7,cycle-36\n\n Voting Cycle #36:\n(April 10 - April 30) \nApply, Build, Nominate\nRetro Funding \nRetro Funding Missions are rolling through Season 7! \n\nDev Tooling\nOn Chain Builders\n\nFor Season 7, we’re prioritizing projects that align wi…\n\n read more\n\n 2\n\n 188\n\n Apr 2025\n\n Joint House Community Call [April 22nd 18:00 UTC]\n\n Community Calls\n\n Joint House Community Call (April 22nd 18:00 UTC) \nWhat up Optimism gov fam. Our Token House community call will be today (April 22nd 18:00 UTC). Call is open to the entire community and everyone is welcome to join as al…\n\n read more\n\n 0\n\n 61\n\n Apr 2025\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 SuperStacks: An Experiment for Incentivising Superchain Interop-Ready TVL across the Superchain\n\n Updates and Announcements 📢\n\n With many chains building as one, a new network structure is emerging to solve fragmentation in Ethereum. This network is modular, interoperable, and composable by default. We call it the Superchain: and it changes every…\n\n read more\n\n 0\n\n 230\n\n Apr 2025","tokens":2507,"squid":"spider-07","role":"Council Spider","at":1791345958298,"hash":"4e21df811ba50dbb0bf98c7bd4fd7c3960ebd087"}
{"url":"https://forum.across.to/t/acx-bribes-on-aura-reimburse-risk-labs-and-plan-forward/1626/5","domain":"forum.across.to","title":"ACX Bribes on Aura - Reimburse Risk Labs and Plan Forward - Proposals - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n Proposals\n\n treasury-funding\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n May 2023\n\n 5 / 5\n\n Jun 2023\n\n May 2023\n\n post by Kevin_UMA on May 11, 2023\n\n post by Clayton_UMA on May 11, 2023\n\n Clayton_UMA\n\n So just to understand, we’re paying back previous incentives, and pre-paying a window of future incentives, to Risk Labs.\nDuring that window of future incentives, we’ll set up the system where the DAO no longer needs Risk Labs to manage this and can do it autonomously. Yeh?\n\n post by Kevin_UMA on May 12, 2023\n\n Kevin_UMA\n\n Yes that is right @Clayton_UMA. But just to be clear - Risk Labs is not earning anything. It’s directly passing the ACX tokens as bribes on behalf of Across DAO. (I just notice you typed “pre-paying a window of future incentives, to Risk Labs.”)\n\n post by eth-wei-trader on May 18, 2023\n\n eth-wei-trader\n\n I’d like to propose a new Balancer / liquidity mining set-up before we continue to bribe the current ACX Balancer pool.\nI think the Balancer pool that ACX incentivizes should contain Across LP shares, similar to how Balancer integrates with Aave. This way we can bolster the Across’s bridge liquidity while also deepening ACX’s liquidity for trading. I can do a more comprehensive write up in a day or two.\n\n 1 month later\n\n Closed on Jun 17, 2023\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 Discontinue ACX Bribes on Aura and Replace with Reward Locking in the Near Term\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 5\n\n Jul 2023\n\n Across ($ACX) Community Initial Liquidity Proposal\n\n Passed Proposals\n\n Passed Proposals\n\n 49\n\n Nov 2022\n\n $ACX Liquidity - Update and Feedback Wanted\n\n Ideas & Feedback\n\n Ideas & Feedback\n\n 7\n\n Jun 2023\n\n Across Token Launch Proposal v2\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 47\n\n Nov 2022\n\n Risk Labs Retroactive Funding and Future Development\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 5\n\n Sep 2024","tokens":2000,"squid":"spider-09","role":"Bridge Spider","at":1791345967747,"hash":"811c9b463d80851d54d2f8ff1dd4b1aaa6daaa5b"}
{"url":"https://www.metaplex.com/docs/solana/understanding-solana-accounts","domain":"metaplex.com","title":"Understanding Solana Accounts | Solana Account Model Guide","text":"A comprehensive guide to Solana's account model—the foundation for understanding tokens, NFTs, and all on-chain data storage. What You'll LearnHow Solana accounts differ from Ethereum accountsAccount ownership and the program modelRent and rent exemptionTypes of accounts you'll encounter in token developmentPrerequisitesBasic blockchain understandingSolana CLI installed (for examples)The Solana Account ModelOn Solana, everything is an account. Unlike Ethereum where contracts have their own storage, Solana separates code (programs) from data (accounts).┌─────────────────────────────────────────────┐\n│ Account │\n├─────────────────────────────────────────────┤\n│ lamports: 1000000 │ ← Balance (in lamports, 1 SOL = 1B lamports)\n│ data: [bytes...] │ ← Arbitrary data storage\n│ owner: 11111111111111111111111111111111 │ ← Program that controls this account\n│ executable: false │ ← Is this a program?\n│ rent_epoch: 123 │ ← Rent tracking\n└─────────────────────────────────────────────┘\nKey ConceptsConceptDescriptionLamportsThe balance in the smallest unit (1 SOL = 1,000,000,000 lamports)DataArbitrary bytes stored in the accountOwnerThe program ID that can modify this account's dataExecutableWhether this account contains program codeAccount OwnershipEvery account has an owner—a program that has exclusive rights to:Modify the account's dataDebit lamports from the accountChange the account's owner (transfer ownership)The System ProgramThe System Program (11111111111111111111111111111111) owns all basic wallet accounts:# View a wallet account\nsolana account <YOUR_WALLET_ADDRESS>\n\n# Output shows:\n# Owner: 11111111111111111111111111111111\nWhen you transfer SOL, you're asking the System Program to debit your account.Program OwnershipWhen a program creates an account, that program becomes the owner:┌─────────────────────────────────────────────────────────────┐\n│ Token Program owns token-related accounts │\n│ │\n│ Token Program ──owns──► Mint Account │\n│ │ │\n│ └──────owns──► Token Account (your token balance) │\n│ │\n│ Metaplex Token Metadata Program ──owns──► Metadata Account │\n└─────────────────────────────────────────────────────────────┘\nTypes of Accounts1. Wallet Accounts (System Accounts)Basic accounts that hold SOL:# Create a new wallet\nsolana-keygen new --outfile wallet.json\n\n# This creates a keypair, and when funded, a System Program-owned account\nsolana airdrop 1\nProperties:Owner: System ProgramData: Empty (0 bytes)Purpose: Hold SOL, sign transactions2. Program AccountsAccounts that contain executable code:# View a program account\nsolana account TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA\n\n# Owner: BPFLoaderUpgradeab1e11111111111111111111111\n# Executable: true\nProperties:Owner: BPF LoaderExecutable: trueData: Compiled program bytecode3. Data AccountsAccounts that store arbitrary data for programs:# View a token mint account\nsolana account <MINT_ADDRESS>\n\n# Owner: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA (Token Program)\n# Executable: false\n# Data: [mint data...]\n4. Program Derived Addresses (PDAs)Special accounts derived deterministically from a program ID and seeds:PDA = hash(seeds + program_id + \"PDA\")\nProperties:No private key (cannot sign transactions)Only the deriving program can sign for itDeterministic—same inputs always produce same addressSee Understanding PDAs for more details.Accounts in Token DevelopmentWhen working with Metaplex tools, you'll interact with several account types:Token Mint AccountRepresents the token itself:┌─────────────────────────────────────────────┐\n│ Mint Account │\n├─────────────────────────────────────────────┤\n│ mint_authority: <pubkey> │ ← Who can mint more\n│ supply: 1000000 │ ← Total supply\n│ decimals: 9 │ ← Decimal places\n│ freeze_authority: <pubkey> │ ← Who can freeze\n└─────────────────────────────────────────────┘\nToken Account (Associated Token Account)Holds a user's balance of a specific token:┌─────────────────────────────────────────────┐\n│ Token Account │\n├─────────────────────────────────────────────┤\n│ mint: <mint_pubkey> │ ← Which token\n│ owner: <wallet_pubkey> │ ← Who owns these tokens\n│ amount: 500 │ ← Balance\n│ state: Initialized │ ← Account state\n└─────────────────────────────────────────────┘\nMetadata Account (Metaplex)Stores token/NFT metadata on-chain:┌─────────────────────────────────────────────┐\n│ Metadata Account │\n├─────────────────────────────────────────────┤\n│ mint: <mint_pubkey> │ ← Associated mint\n│ name: \"My Token\" │\n│ symbol: \"MTK\" │\n│ uri: \"https://...\" │ ← Off-chain metadata\n│ creators: [...] │ ← Creator info\n│ royalties: 500 (5%) │\n└─────────────────────────────────────────────┘\nSPL Token Model vs Metaplex CoreThe account structure for tokens and NFTs differs significantly depending on the program you use.SPL Token + Token Metadata uses multiple accounts per asset:┌──────────────────────────────────────────────────────┐\n│ SPL Token Model (3+ accounts per asset) │\n│ │\n│ Mint Account ← Token definition (82 bytes) │\n│ Token Account (ATA) ← Holder's balance (165 bytes)│\n│ Metadata Account ← Name, symbol, URI (PDA) │\n│ Master Edition ← NFT edition tracking (PDA) │\n└──────────────────────────────────────────────────────┘\nEach account is owned by a different program, requires its own rent-exempt deposit, and must be managed separately. Transferring an NFT means updating the Token Account; metadata lives in a separate PDA owned by the Token Metadata program.Metaplex Core collapses everything into a single account:┌──────────────────────────────────────────────────────┐\n│ Core Model (1 account per asset) │\n│ │\n│ Asset Account │\n│ ├── owner: <wallet_pubkey> │\n│ ├── name: \"My NFT\" │\n│ ├── uri: \"https://...\" │\n│ └── plugins: [royalties, freeze, burn, ...] │\n└──────────────────────────────────────────────────────┘\nWith Core, ownership, metadata, and extensibility (via plugins) are stored in one account owned by the Core program. This means fewer accounts to create, lower rent costs, and simpler transactions.SPL Token + Token MetadataMetaplex CoreAccounts per NFT3–4 (mint, token, metadata, edition)1 (asset)Rent cost~0.01 SOL~0.003 SOLOwnershipToken Account tracks balanceAsset account owner fieldMetadataSeparate PDABuilt into the asset accountExtensibilityToken Extensions (Token-2022)Plugin systemBest forFungible tokens (SPL)NFTs and digital assetsWhich should I use?For NFTs and digital assets, use Metaplex Core — it's simpler, cheaper, and purpose-built. For fungible tokens (currencies, rewards), use the SPL Token program with Metaplex Token Metadata for on-chain metadata.Rent and Rent ExemptionAccounts must pay rent to exist on Solana. This prevents blockchain bloat.How Rent WorksRent is paid in lamports based on data sizeAccounts that fall below minimum balance are purgedRent-exempt accounts pay a one-time deposit and exist foreverRent ExemptionTo be rent-exempt, an account must hold minimum lamports based on its size:# Check rent-exempt minimum for different sizes\nsolana rent 0 # Wallet (0 bytes): ~0.00089 SOL\nsolana rent 82 # Mint Account: ~0.002 SOL\nsolana rent 165 # Token Account: ~0.0025 SOL\nsolana rent 679 # Metadata Account: ~0.0056 SOL\nAlways Rent-ExemptWhen creating accounts with Metaplex tools (MPLX CLI, SDKs), the tools automatically calculate and include rent-exempt amounts. You don't need to manually calculate rent.Recovering RentWhen you close an account, you recover the rent deposit:# Burning an NFT recovers most of its rent\nmplx core burn-asset <ASSET_ADDRESS>\n# Returns ~0.00089 SOL\nSolana vs EthereumComing from Ethereum? Here are the key differences:AspectEthereumSolanaContract storageContract stores its own dataPrograms are stateless; data in separate accountsAccount creationImplicit (just send to address)Explicit (must create and fund account)Storage costGas per operationRent exemption (one-time deposit)OwnershipContracts own themselvesPrograms own data accountsBalance storageSingle balance fieldSeparate token accounts per tokenPractical ImplicationsToken balances: On Ethereum, one contract tracks all balances. On Solana, each holder has a separate token account:Ethereum:\n ERC-20 Contract\n └── balances mapping\n ├── Alice: 100\n └── Bob: 50\n\nSolana:\n ├── Mint Account\n ├── Alice's Token Account → amount: 100\n └── Bob's Token Account → amount: 50\nViewing AccountsCLI# View account info\nsolana account <ADDRESS>\n\n# View in JSON format\nsolana account <ADDRESS> --output json\n\n# View only data (hex encoded)\nsolana account <ADDRESS> --output json | jq '.data'\nExplorerUse Solana Explorer or SolanaFM to view accounts visually:Solana ExplorerSolanaFMProgrammaticallyimport { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\nimport { publicKey } from '@metaplex-foundation/umi'\n\nconst umi = createUmi('https://api.devnet.solana.com')\n\nconst account = await umi.rpc.getAccount(publicKey('YourAddressHere...'))\nif (account.exists) {\n console.log('Owner:', account.owner)\n console.log('Lamports:', account.lamports)\n console.log('Data length:', account.data.length)\n}\nCommon PatternsWhy \"Account Not Found\"?On Solana, accounts must be explicitly created:Error: Account does not exist\n\nCause: The account has never been created, or it was closed/purged\nSolution: Create the account first (automatic with most Metaplex operations)\nAssociated Token Accounts (ATAs)ATAs are deterministically derived so you don't need to track them:ATA = derive(wallet_address, mint_address, token_program)\nThe MPLX CLI and SDKs automatically create ATAs when needed:# This auto-creates the recipient's ATA if it doesn't exist\nmplx toolbox token-transfer <RECIPIENT> <AMOUNT>\nNext StepsUnderstanding PDAs - Dive deeper into Program Derived AddressesTransaction fundamentals - How transactions work on SolanaCreate a Solana token - Put this knowledge into practiceFAQWhy do I need to create token accounts?Unlike Ethereum where a contract tracks balances, Solana requires separate accounts. This enables parallel processing—different accounts can be modified simultaneously.What happens if my account runs out of rent?If an account falls below the rent-exempt threshold, it will be purged after some time, and the remaining lamports returned to the owner. Always keep accounts rent-exempt.Can I close accounts to recover SOL?Yes! When you burn NFTs or close token accounts, you recover the rent-exempt deposit. This is why burning assets returns SOL.Why does my wallet show a small balance after minting?Creating accounts (mint, metadata, token accounts) requires rent-exempt deposits. These are locked in the accounts, not spent.What's the difference between owner and authority?Owner (on-chain): The program that controls the account's dataAuthority (in account data): The wallet that can perform certain actions (like minting)Example: A Mint Account is owned by the Token Program, but its mint authority is your wallet.","tokens":2705,"squid":"dotcat","role":"Tooling Spider","at":1791345969246,"hash":"2146ea06afe3969676be5741251f251ae081b7eb"}
{"url":"https://gov.optimism.io/t/introducing-improvements-to-the-protocol-upgrade-process/10284","domain":"gov.optimism.io","title":"Introducing improvements to the Protocol Upgrade process - Updates and Announcements 📢 - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n Introducing improvements to the Protocol Upgrade process \n\n Updates and Announcements 📢\n\n season-8\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n 2\n\n Sep 2025\n\n 1 / 10\n\n Sep 2025\n\n 3d ago\n\n post by system on Sep 16, 2025\n\n system\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 Developer Advisory Board (DAB), who were elected by the Token House and Citizens’ House ahead of Season 8. This doesn’t apply to maintenance upgrades\n\nDelegates are no longer required to post approvals of proposals on the forum, or actively vote to approve upgrades.\n\nInstead, delegates and Citizens have the power to veto upgrades that they believe harm their interests during a 1-week Joint House veto period. They may also override the DAB’s decision to reject an upgrade.\n\nThis shift ensures an efficient, low-overhead, technically rigorous path to mainnet upgrades.\n\nThe improved upgrade process\nprotocol upgrades diagram1600×900 116 KB\nStep 1: Developer Advisory Board Approval\n\nAn elected group of 7 independent protocol developers (the DAB) is looped in early to provide feedback on upcoming releases, and reviews upgrades during the final testing phase.\n\nThey assess each proposal for (among other things):\n\nTechnical content: does the proposal do what it says it will? Is it complete? Does call data match?\n\nTechnical merit: Is the justification of changes clear? Are the described benefits accurate? Are there unmentioned technical tradeoffs?\n\nCollective impact: does the proposal violate the Law of Chains or Working Constitution?\n\nThe full list of the DAB’s responsibilities can be found here\n\nOnce the betanet phase is complete, the upgrade can be pushed to Sepolia.\n\nIf the DAB rejects a proposal, the upgrade continues to Sepolia and enters the 7 day stakeholder veto period. This allows stakeholders to choose whether to override the DAB decision.\n\nStep 2: 7-Day Veto Period\n\nOnce on Sepolia, the upgrade enters a 1-week veto window.\n\nIf the DAB has approved the upgrade, stakeholders are voting to block the upgrade.\n\nIf the DAB has rejected the upgrade, stakeholders are voting to override the DAB’s decision and allow the upgrade to be executed.\n\nFour stakeholder groups can object:\n\nDelegates (Token House)\n\nChain Operators (Citizens’ House)\n\nApplication Developers (Citizens’ House)\n\nEnd Users (Citizens’ House)\n\nThe full eligibility criteria for Citizens’ House membership can be found here\n\nA veto is triggered if 2 or more groups cross the applicable below thresholds:\n\n2 groups: 17% of each group must support a veto\n\n3 groups: 14% each\n\n4 groups: 11% each\n\nIf veto threshold is not met → upgrade proceeds according to DAB decision.\n\nIf veto threshold is met → DAB decision is overridden\n\nIf a proposal is rejected, it enters an appeals and discussion phase\n\nWhat this means for delegates\nDelegates continue to play their meaningful role in governance with a streamlined focus:\n\nDelegates elect the Developer Advisory Board (DAB) to represent their interests on technical matters.\n\nDelegates are no longer required to actively vote on every upgrade.\n\nDelegates may engage in the veto process if a proposed upgrade appears misaligned with the interests of tokenholders, or they disagree with the DAB’s rejection of the upgrade.\n\nIf no concerns are raised, no action is needed—upgrades proceed by default according to the DAB’s decision.\n\nThis model preserves real oversight power, without demanding delegates’ time for every technical release.\n\nTimeline\n\nThis process is live as of August 2025.\n\nAll Season 8 protocol upgrades will follow the new DAB approval + veto model.\n\nMaintenance upgrades will follow a shortened version of the process without DAB approval, as defined here\n\nDelegates will receive alerts on Telegram when an upgrade enters the veto period.\n\nContinued improvements to the Protocol Upgrade process will be made ahead of Season 9\n\n Optimism Gov Summary\n\n 2\n\n 2\n\n Unlisted on Sep 16, 2025\n\n Listed on Sep 16, 2025\n\n post by GFXlabs on Sep 16, 2025\n\n GFXlabs\n\nGiven that both the Security Council and the DAB are both elected by the same governance and both required to implement an upgrade, would it make sense to merge the two bodies? Or are they distinct enough to stay as separate bodies?\n\n post by optimistic_emily on Sep 17, 2025\n\n optimistic_emily\n\n Hi @GFXlabs\nThe Developer Advisory Board and Security Council have distinct roles in the system.\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 individual actors (“participants”) accountable to Optimism Governance.”\n“During normal operations, the Council simply implements the upgrade and role permission decisions made by Governance, rather than making decisions itself.”\nOn the other hand, the “Developer Advisory Board (DAB) exists to provide independent, expert technical judgment to secure and advance the Optimism Collective.”\nTheir primary function is to vote on Protocol Upgrades on behalf of the Collective. In doing so, they are responsible for assessing the upgrade’s technical content, technical merit and Collective Impact.\nMore details can be found in the Security Council and Developer Advisory Board charters.\n\n post by kumahada on Sep 18, 2025\n\n kumahada\n\n Hello! I’m very interested in this upgrade.\nIs it accurate to assume that the authority to manage protocol upgrades, previously managed by the existing Security Council, will be transferred to the DAB?\nIf so, will the existing Security Council assume a different role or be eliminated?\n\n post by optimistic_emily on Sep 18, 2025\n\n optimistic_emily\n\n Hi, no that is not correct. Both the Security Council and Developer Advisory Board continue to have important and distinct roles in the system.\nThe Developer Advisory Board assesses the upgrade’s technical content, technical merit and Collective impact before deciding whether to approve the upgrade or not.\n“During normal operations, the [Security] Council simply implements the upgrade and role permission decisions made by Governance, rather than making decisions itself.”\nMore details can be found in the Security Council and Developer Advisory Board charters.\n\n post by nanobro on Sep 25, 2025\n\n nanobro\n\n I like how the new process strikes a balance between efficiency and accountability. Delegates and Citizens still retain meaningful oversight through the veto mechanism, while the Developer Advisory Board ensures technical stuffs.\n\n 4 months later\n\n post by system on Jan 28\n\n system\n\n A minor update to this process has been made and is now reflected in the Operating Manual.\nThe Developer Advisory Board has a 7 day voting window to vote on a protocol upgrade. However, in cases when a proposal is approved in less than 7 days, the proposal may move straight to the veto period. This means a proposal could move to the veto period in less than 7 days but the Developer Advisory Board will have the full 7 days when needed. Allowing the DAB voting window to be variable (up to 7 days), engineering can ship faster in cases where the DAB reaches quourum quickly. As the DAB is looped into core development discussions early, this change does not alter the length of the review period, which is ongoing well before a proposal reaches the forum.\n\n 8 months later\n\n post by DarkEmpath888 3 days ago\n\n DarkEmpath888\n\n kumahada\n\n I need assistance please. I do not know what the OPTIMISM collective is. -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 Season 8 Developer Advisory Board Charter amendment\n\n Elections 💼\n\n season-8\n\n Developer Advisory Board: Seasons 8 Charter Amendment\nProposed Council or Board Lead: Ed (wildmolasses) \nPlease link to any previous work or qualifications to be Council or Board Lead: \n\nAtlas profile\nDAB member S6\nDAB O…\n\n read more\n\n 7\n\n 431\n\n Jul 2025\n\n Internal Operating Procedures (IOP) for Developer Advisory Board: Season 8\n\n Internal Operating Procedures\n\n season-8\n\n Seasons 8 Developer Advisory Board - Internal Operating Procedures (IOPs)\nThe Internal Operating Procedures in this document govern the activities of the Season 8 Developer Advisory Board. This document sets forth the pr…\n\n read more\n\n 0\n\n 67\n\n Aug 2025\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 Developer Advisory Board - S6 Internal Operating Procedures\n\n Internal Operating Procedures\n\n The internal operating procedures in this document govern the activities of the Season 6 Developer Advisory Board. The document sets forth the processes the DAB will follow in fulfilling our charter, including supporting…\n\n read more\n\n 3\n\n 316\n\n Jul 2024\n\n Voting Cycle Roundup #26\n\n Voting Cycles\n\n season-6\n\n Cycle #26 began on Thursday August 8th at 19:00 GMT and runs until Wednesday August 28th at 19:00 GMT. Additionally, the Citizens’ House will have a one-week period to veto any Upgrades approved by the Token House, immed…\n\n read more\n\n 4\n\n 304\n\n Apr 2025","tokens":2391,"squid":"spider-07","role":"Council Spider","at":1791345969339,"hash":"b3c5094e05b554cb14e0acf9ebeb5bd137338eaa"}
{"url":"https://www.metaplex.com/docs/solana/compute-units-and-priority-fees","domain":"metaplex.com","title":"Compute Units and Priority Fees | Solana Transaction Optimization","text":"Master compute units and priority fees to ensure your transactions land reliably, even during network congestion. What You'll LearnWhat compute units are and how they workHow to set compute unit limits and pricesWhen and how to use priority feesStrategies for optimal transaction landingPrerequisitesTransaction fundamentalsSolana CLI installedWhat Are Compute Units?Compute units (CUs) measure the computational resources a transaction consumes. Think of them as \"gas\" on Solana.ConceptDescriptionCompute UnitA unit of computational workCompute BudgetMaximum CUs a transaction can useDefault Limit200,000 CUs per instructionMaximum Limit1,400,000 CUs per transactionWhy Compute Units MatterTransaction limits - Transactions exceeding their compute budget failPriority fees - Fees are calculated based on compute unitsBlock space - Blocks have limited total compute capacityThe Compute Budget ProgramThe Compute Budget Program lets you customize compute settings via two instructions:SetComputeUnitLimitRequest a specific compute unit budget:import { setComputeUnitLimit } from '@metaplex-foundation/mpl-toolbox'\n\nconst builder = transactionBuilder()\n .add(setComputeUnitLimit(umi, { units: 300000 }))\n .add(yourInstruction)\nSetComputeUnitPriceSet the price per compute unit (priority fee):import { setComputeUnitPrice } from '@metaplex-foundation/mpl-toolbox'\n\nconst builder = transactionBuilder()\n .add(setComputeUnitPrice(umi, { microLamports: 1000 }))\n .add(yourInstruction)\nInstruction OrderAlways add compute budget instructions first in your transaction, before other instructions.Priority Fees ExplainedPriority fees are optional fees that incentivize validators to include your transaction sooner. They're calculated as:Priority Fee = Compute Units × Compute Unit Price (in micro-lamports)\nExample CalculationCompute Units: 200,000\nPrice: 1,000 micro-lamports per CU\nPriority Fee: 200,000 × 1,000 = 200,000,000 micro-lamports\n = 200,000 lamports\n = 0.0002 SOL\nWhen to Use Priority FeesScenarioPriority Fee StrategyNormal network conditionsNone or minimal (50-100 micro-lamports)Moderate congestion1,000-10,000 micro-lamportsHigh congestion / NFT mints10,000-100,000+ micro-lamportsTime-sensitive DeFiDynamic based on recent feesEstimating Compute UnitsMethod 1: SimulationSimulate your transaction to see actual CU consumption. Build the transaction first, then simulate:const tx = await myBuilder\n .setBlockhash(await umi.rpc.getLatestBlockhash())\n .buildAndSign(umi)\n\nconst simulation = await umi.rpc.simulateTransaction(tx)\n// Use the consumed units with a 10-20% buffer\nMethod 2: RPC MethodsSome RPC providers offer priority fee estimation endpoints. Check your provider's documentation for specific APIs.Setting Optimal Compute LimitsToo HighWastes block spaceMay be deprioritized by validatorsHigher risk of transaction being skippedToo LowTransaction fails if it exceeds limitYou lose the transaction feeBest PracticeSimulate first, then set a compute limit with a buffer:import { setComputeUnitLimit, setComputeUnitPrice } from '@metaplex-foundation/mpl-toolbox'\nimport { transactionBuilder } from '@metaplex-foundation/umi'\n\n// 1. Build your instruction(s)\nconst baseBuilder = transactionBuilder().add(yourInstruction)\n\n// 2. Simulate to estimate CUs (check explorer logs for consumed CUs)\n// 3. Add compute budget with a buffer\nconst optimizedBuilder = transactionBuilder()\n .add(setComputeUnitLimit(umi, { units: estimatedCUs * 1.2 }))\n .add(setComputeUnitPrice(umi, { microLamports: 1000 }))\n .add(yourInstruction)\n\nawait optimizedBuilder.sendAndConfirm(umi)\nDynamic Priority FeesFor competitive scenarios like popular mints, increase priority fees based on network conditions. Monitor recent transaction fees via your RPC provider's dashboard or priority fee APIs, and adjust accordingly.Complete Example with UMIimport { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\nimport { setComputeUnitLimit, setComputeUnitPrice } from '@metaplex-foundation/mpl-toolbox'\nimport { transactionBuilder } from '@metaplex-foundation/umi'\n\nconst umi = createUmi('https://api.devnet.solana.com')\n\n// Build an optimized transaction with compute budget\nconst builder = transactionBuilder()\n // Compute budget instructions go FIRST\n .add(setComputeUnitLimit(umi, { units: 300000 }))\n .add(setComputeUnitPrice(umi, { microLamports: 1000 }))\n // Then your actual instructions\n .add(yourInstruction)\n\nawait builder.sendAndConfirm(umi)\nSee the Optimal transaction landing with UMI guide for detailed patterns including simulation-based estimation.Cost ConsiderationsFee CalculationTotal transaction cost = Base fee + Priority feeBase fee: 5,000 lamports (0.000005 SOL) per signature\nPriority fee: CUs × Price in micro-lamports\nTroubleshooting\"Compute budget exceeded\"Cause: Transaction used more CUs than allocated.Solution: Increase compute unit limit:setComputeUnitLimit(umi, { units: 400000 })\nTransaction Dropped Despite Priority FeeCauses:Blockhash expiredFee still too low for current demandTransaction was included but failedSolutions:Retry with fresh blockhashIncrease priority feeCheck if transaction was actually included (check signature)High Priority Fee but Slow ConfirmationCause: The accounts you're writing to may be heavily contested (hot accounts).Solution: For contested accounts, even higher fees may be needed, or retry with exponential backoff.Best PracticesAlways simulate first - Get accurate CU estimatesAdd buffer to estimates - 10-20% extra prevents failuresStart with low priority fees - Increase only if neededMonitor network conditions - Adjust strategy based on congestionDon't overpay - High fees don't guarantee faster confirmation on uncongested networksNext StepsWorking with devnet and testnet - Test without real feesTransaction fundamentals - Understand transaction structureHow to diagnose transaction errors - Debug issuesFAQDo I always need priority fees?No. During normal network conditions, transactions land fine without priority fees. Only add them during congestion or for time-sensitive operations.What's a good default priority fee?For general use, 1,000-5,000 micro-lamports per CU is reasonable. Monitor recent fees for your specific use case.Why set compute unit limit at all?Setting an accurate limit:Signals to validators your transaction won't waste block spaceCan improve prioritizationPrevents overpaying on priority fees (fee = CUs × price)Can I get a refund for unused compute units?No. You're charged based on the compute unit limit you set, not what you actually use. That's why accurate estimation matters.","tokens":1645,"squid":"dotcat","role":"Tooling Spider","at":1791345979296,"hash":"45bb03990b995cdbede4320374cf8c5d890a21cf"}
{"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":"spider-05","role":"Spec Spider","at":1791345983791,"hash":"91adb40d2cb800eb8326e9fd463a4ddef497e454"}
{"url":"https://forum.across.to/t/acx-market-making-proposal-arrakis-palm/1667","domain":"forum.across.to","title":"ACX Market Making Proposal - Arrakis PALM - Proposals / Active Proposals - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n ACX Market Making Proposal - Arrakis PALM \n\n ProposalsActive Proposals\n\n treasury-funding\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jun 2023\n\n 1 / 5\n\n Jun 2023\n\n Jun 2023\n\n post by barbarossa_Arrakis on Jun 13, 2023\n\n barbarossa_Arrakis\n\n Header\nTitle: ACX Market Making Proposal - Arrakis PALM\nAuthor(s): @barbarossa_Arrakis\nStatus: Proposal\nRelated Discussions: “Community Owned Liquidity” NFT Project Funding Request\nBody\nSummary:\nDeploy Arrakis PALM to conduct market-making for ACX with Across’ POL on UniV3, for both Mainnet and Optimism.\nIntroduction to Arrakis Finance and PALM:\nArrakis Finance is Web3’s trustless market-making infrastructure protocol that enables running sophisticated algorithmic strategies on Uniswap V3.\nSince launch, Arrakis has achieved\n\nOver $1.7b in TVL at its peak (currently around $205m), across Ethereum, Optimism, Arbitrum, Polygon and BNB Chain.\nOver 25% Uniswap V3 total TVL\nOver 80 projects have their liquidity managed via Arrakis vaults\n\nArrakis PALM - Protocol Automated Liquidity Management is a novel liquidity bootstrapping mechanism that taps into the organic trading volume on UniV3. It is the first product built on top of the Arrakis infrastructure.\nIn essence, PALM helps protocols bootstrap their base asset inventory (ETH, DAI, etc.) and attain deep and sustainable liquidity. The major advantages of using PALM include:\n\nZero incentive: no LM incentive needed, liquidity bootstrapping is done solely via market making.\nLow requirement in base asset: the initial liquidity can be made of mostly ACX, and PALM will progressively balance it towards 50% to create an equal buy/sell support.\nHigh capital efficiency: by autonomously and actively managing concentrated liquidity, especially once a sufficient amount of base asset has been bootstrapped, PALM can further reduce the slippage for large trades even if with limited overall liquidity.\nNo biased price impact: PALM conducts market making by setting up ranges / limit orders, no swaps involved.\nTrustless & transparency: Across retains the ownership of the liquidity and can withdraw at all times. PALM only autonomously manages the liquidity but can never remove it. All executions of PALM can be monitored on-chain with full transparency.\n\nPALM has been deployed for a growing number of protocols and is performing exactly as designed. An example for KWENTA/WETH can be referenced to demonstrate the overall performance of PALM and how it’s able to bootstrap and deepen the liquidity regardless of the price action.\nIn particular, the Kwenta case is especially relevant to Across given that it has liquidity on both Velodrome and UniV3 through PALM, and we’ve analyzed the KWENTA liquidity situation on both platforms. The general conclusion is that not only has PALM managed to create a similar liquidity depth (reflected via price impact) with less than 20% of the liquidity on Velodrome, we also made a handsome sum of profit (~$35k) for Kwenta Treasury via trading fees over 3 months. Perhaps most importantly, Kwenta Treasury still owns the liquidity in the end and PALM has also managed to beat the impermanent loss. We will release an in-depth article about it soon.\nMotivation:\nCurrently, there are two major challenges in terms of ACX liquidity:\n\nHigh liquidity rental cost: 2.3m ACX is given away as LM incentives in the form of bribes via Aura Finance. Based on the average price of ACX since the incentive campaign started (December 2022), this bribe allocation represents roughly $125k, and has bootstrapped around $900k liquidity.\nMost probably the incentivized liquidity is going to leave once the reward runs out. This is particularly true when the LM is conducted through bribes, because rather than directly rewarding community LPs that believe in the value of ACX, it is the vlAura holders that receive the token and they tend to sell the bribes for AURA to increase their bribe earning power, or other assets. Renting liquidity is never a sustainable solution and eventually does more harm than good to the protocol and token holders.\n\nLow capital efficiency: ACX liquidity resides in a 50/50 Balancer pool, resembling a constant function market maker that only accepts full range liquidity provision. Meanwhile, the on-chain volume of ACX has been mostly below $30k daily, which indicates a rather low capital efficiency, i.e. <0.03, given the amount of ACX liquidity on Balancer (~$900k).\n\nAll of this presents both a huge cost and a missed opportunity for Across:\n\nThe bribe could have been reserved for better purposes that contribute to the development of the protocol.\nAcross could have adopted a market making solution like Arrakis PALM that actively manages UniV3 positions with high capital efficiency and low capital requirement, and still suffices the on-chain volume and even consistently pockets the trading fees for Across treasury.\n\nTo help Across save the cost and capture the opportunity, Arrakis proposes to provide Across with the full spectrum of market-making services on UniV3 with PALM to bootstrap and create deep on-chain liquidity.\nSpecification & Implementation:\nPhase 1 - Accumulate base asset\nAcross initially deposits a certain amount of POL into a PALM vault on both networks. Based on our past experience and the current on-chain volume of ACX, we suggest that the minimum deposit be $200k per vault. The deposit can be mostly made of ACX, e.g. 90/10 in ACX/stETH, and PALM will pull that ratio towards 50/50 over time.\nPhase 2 - Establish deep liquidity\nOnce the target ratio of 50/50 is reached, the focus is then on market-making to create deep liquidity for ACX and to minimize the slippage on both the buy and sell side of the volume.\nDuring the deployment period, the Across community has complete visibility into the execution and performance of PALM via a custom dashboard, and retains full custody of the liquidity in the vault, which means that the Across community can withdraw from the vault or revoke managing access from PALM at any time. PALM can only conduct market-making with the liquidity deposited in the vault and will never be able to remove the fund.\nFor the services provided, Arrakis charges fees on two fronts:\n\nManagement fee: 1% AUM fee on a yearly basis\nPerformance fee: 50% of trading fees generated\n\nDownside (Cons):\nThe potential downside may be that Across Treasury would have to allocate a certain amount of POL for PALM to manage, which may incur opportunity cost. However, given that the alternative would be spending ACX as incentives as opposed to retaining the ownership of the POL, this downside is rather trivial in our opinion.\nVoting:\nYes - employ Arrakis PALM for ACX liquidity management\nNo - seek for other alternatives instead\nAbstain - no vote\n\n Discontinue ACX Bribes on Aura and Replace with Reward Locking in the Near Term\n\n Updated - [ACX] Market Making Proposal - Arrakis PALM\n\n post by Everythingblockchain on Jun 14, 2023\n\n Everythingblockchain\n\n Hello there!\nI appreciate the proposal and the advantages highlighted for Arrakis PALM. However, I would like to provide some feedback to foster further discussion.\nFirstly, while Arrakis PALM offers advantages in liquidity management, it’s important to consider the potential implications of a more centralized approach.\nIn terms of profitability, it would be valuable to do an analysis to ensure that Arrakis PALM’s market-making strategy offers competitive benefits compared to other options. The proposed performance fee of 50% of trading fees, in addition to the management fee, seems quite high.\nRegarding the criticism of high liquidity rental costs associated with incentivized liquidity, it would be helpful to provide a comprehensive cost-benefit analysis to support the claim compared to market-making solutions like Arrakis PALM.\nThe proposal overlooks the potential benefits of incentivizing liquidity provision through ve(3,3) models. These not only attract liquidity but help earn earn emissions and other rewards.\nA detailed comparison showcasing how Arrakis PALM has helped improve protocol liquidity compared to ve(3,3) would be a valuable tool. Highlighting successful implementations and the resulting impact on liquidity depth and trading volumes would provide concrete evidence of Arrakis PALM’s effectiveness.\n\n post by defi_occam on Jun 16, 2023\n\n defi_occam\n\n Thank you for this well-researched proposal. I look forward to reading your in-depth article about KWENTA’s experience with Arrakis PALM and Velodrome.\nCan you say a bit more about how you came by the fees you will charge Across? Is there room to negotiate, or are they the same for all protocols?\n\n 10 days later\n\n post by caesarsherrod.eth on Jun 27, 2023\n\n caesarsherrod.eth\n\n I am very biased to the Velodrome model on Optimism. I’d prefer that the DAO moved into that realm of it. I am not opposed to Arrakis. But I just found this article that convinced me that Velodrome may be the better option.\nThis article, released on 22 June 2023, explains Arrakis as a superior app, but the counterarguing article is much more appealing to me.\nI will let the community make their own decisions because I am biased to $VELO and Velodrome because I have been using the protocol. Please read both and educate the self.\n\n 1 month later\n\n Closed on Jul 27, 2023\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 Updated - [ACX] Market Making Proposal - Arrakis PALM\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 2\n\n Aug 2023\n\n Across ($ACX) Community Initial Liquidity Proposal\n\n Passed Proposals\n\n Passed Proposals\n\n 49\n\n Nov 2022\n\n $ACX Liquidity - Update and Feedback Wanted\n\n Ideas & Feedback\n\n Ideas & Feedback\n\n 7\n\n Jun 2023\n\n Build liquidity for $ACX on Velodrome\n\n Active Proposals\n\n treasury-funding\n\n Active Proposals\n\n 8\n\n Jul 2023\n\n Velodrome Liquidity Program Extension\n\n Active Proposals\n\n Active Proposals\n\n 19\n\n Jan 2024","tokens":4000,"squid":"spider-09","role":"Bridge Spider","at":1791345988141,"hash":"799cf62393ad91de5b9bcdd1c98f6a37443c002b"}
{"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":"spider-05","role":"Spec Spider","at":1791345993852,"hash":"17712db4fe471bf9de0b8019f7e3fadf34e561d2"}
{"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":"spider-05","role":"Spec Spider","at":1791346003793,"hash":"cf1735eb9e9b79c440e54a3d4d27c9964c389296"}
{"url":"https://ethresear.ch/t/timing-the-head-in-ethereum-pos/25766/1","domain":"ethresear.ch","title":"Timing the Head in Ethereum PoS - Proof-of-Stake / Economics - Ethereum Research","text":"Timing the Head in Ethereum PoS \n\n Proof-of-StakeEconomics\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Aug 19\n\n 1 / 3\n\n Aug 19\n\n Sep 1\n\n post by Yolodannn on Aug 19\n\n Yolodannn\n\n Description\nIn Ethereum PoS, many reorganization attacks manipulate validators’ views of the head, causing their attestation weight to be distributed across different branches and potentially triggering a reorganization. This shows that the head plays a critical role in consensus security. Meanwhile, head votes also account for a significant part of attestation rewards and must satisfy a strict timing condition to be rewarded, making them particularly vulnerable to loss. However, the role of the head in consensus security and validator incentives has not been studied in a unified way.\nBackground\nHead Vote.\nValidators attest to the block they consider the head according to LMD-GHOST. Unlike source and target votes, the head reward depends strongly on whether the validator observes the correct block in time.\nAttestation Timing.\nIn each 12-second slot, validators normally attest before 4 seconds after the beginning of the slot. Therefore, a proposer that controls when its block is released can influence the local view used by honest attesters.\nProposer Boost.\nEthereum gives the current-slot block additional temporary fork-choice weight for 40%. This mechanism is intended to minimize an ex ante reorg attack and balancing attack, but it also affects the outcome when competing branches are deliberately created.\nAttack Scenario\nWe consider two timing-based attack scenarios that exploit the role of the head vote in Ethereum PoS.\n\nHead-vote timing game . An adversarial proposer delays the broadcast of its block within a plausible network-delay range and releases it close to the attestation deadline. Honest validators that have not received the block and continue to regard its parent as the head and therefore vote for the parent, causing them to lose the head component of their attestation reward once the delayed block becomes canonical. Importantly, such delayed delivery cannot be reliably identified by the protocol as malicious behavior, since a late block may also result from ordinary network propagation delay.\nTiming Game-p3991×1121 90.8 KB\n\nK-block attack. We further generalize the attack to consecutive adversarial proposer slots. When the attacker controls k consecutive proposers, it can privately extend a competing branch while withholding these blocks from honest validators. The private branch can isolate subsequent honest blocks and, once released, become the canonical chain and trigger a reorganization. As a result, honest validators may cast head votes for blocks that are later removed from the canonical chain, again causing the loss of their head-vote rewards.\nk-block-p2000×1172 81.6 KB\n\nImpact\nOur Prysm experiments show that this timing manipulation produces a persistent reward asymmetry.\nthe head-vote timing game produces a 15.06% average total reward loss for honest validators. The same block-visibility asymmetry can also affect HLMD-GHOST directly: under k-block withholding, coordinated adversarial proposers and attesters can accumulate enough private fork-choice weight to realize reorganization\nTo reduce the incentive loss caused by these stale local views, we explore a distance-weighted head reward that gives partial rewards to eligible attestations pointing to recent canonical ancestors, while retaining the highest reward for voting for the freshest canonical head. The mechanism changes only the reward calculation and leaves HLMD-GHOST and proposer boost unchanged. In our experiments, it reduces the timing-game loss from 15.06% to 4.71%, and consistently reduces honest reward losses under the K-block attack. It does not eliminate losses caused by orphaned branches or all reorganization effects, but substantially reduces the reward disadvantage experienced by honest validators.\n\n 2\n\n post by yzcrypto on Aug 23\n\n 8 days later\n\n post by Yolodannn on Sep 1\n\n Powered by Discourse","tokens":1013,"squid":"spider-04","role":"Research Spider","at":1791346005891,"hash":"bdd3f9355f916e8c65b1c3021520b47737641084"}
{"url":"https://forum.across.to/t/acx-market-making-proposal-arrakis-palm/1667/5","domain":"forum.across.to","title":"ACX Market Making Proposal - Arrakis PALM - Proposals / Active Proposals - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n ProposalsActive Proposals\n\n treasury-funding\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jun 2023\n\n 5 / 5\n\n Jul 2023\n\n Jun 2023\n\n post by barbarossa_Arrakis on Jun 13, 2023\n\n barbarossa_Arrakis\n\n Header\nTitle: ACX Market Making Proposal - Arrakis PALM\nAuthor(s): @barbarossa_Arrakis\nStatus: Proposal\nRelated Discussions: “Community Owned Liquidity” NFT Project Funding Request\nBody\nSummary:\nDeploy Arrakis PALM to conduct market-making for ACX with Across’ POL on UniV3, for both Mainnet and Optimism.\nIntroduction to Arrakis Finance and PALM:\nArrakis Finance is Web3’s trustless market-making infrastructure protocol that enables running sophisticated algorithmic strategies on Uniswap V3.\nSince launch, Arrakis has achieved\n\nOver $1.7b in TVL at its peak (currently around $205m), across Ethereum, Optimism, Arbitrum, Polygon and BNB Chain.\nOver 25% Uniswap V3 total TVL\nOver 80 projects have their liquidity managed via Arrakis vaults\n\nArrakis PALM - Protocol Automated Liquidity Management is a novel liquidity bootstrapping mechanism that taps into the organic trading volume on UniV3. It is the first product built on top of the Arrakis infrastructure.\nIn essence, PALM helps protocols bootstrap their base asset inventory (ETH, DAI, etc.) and attain deep and sustainable liquidity. The major advantages of using PALM include:\n\nZero incentive: no LM incentive needed, liquidity bootstrapping is done solely via market making.\nLow requirement in base asset: the initial liquidity can be made of mostly ACX, and PALM will progressively balance it towards 50% to create an equal buy/sell support.\nHigh capital efficiency: by autonomously and actively managing concentrated liquidity, especially once a sufficient amount of base asset has been bootstrapped, PALM can further reduce the slippage for large trades even if with limited overall liquidity.\nNo biased price impact: PALM conducts market making by setting up ranges / limit orders, no swaps involved.\nTrustless & transparency: Across retains the ownership of the liquidity and can withdraw at all times. PALM only autonomously manages the liquidity but can never remove it. All executions of PALM can be monitored on-chain with full transparency.\n\nPALM has been deployed for a growing number of protocols and is performing exactly as designed. An example for KWENTA/WETH can be referenced to demonstrate the overall performance of PALM and how it’s able to bootstrap and deepen the liquidity regardless of the price action.\nIn particular, the Kwenta case is especially relevant to Across given that it has liquidity on both Velodrome and UniV3 through PALM, and we’ve analyzed the KWENTA liquidity situation on both platforms. The general conclusion is that not only has PALM managed to create a similar liquidity depth (reflected via price impact) with less than 20% of the liquidity on Velodrome, we also made a handsome sum of profit (~$35k) for Kwenta Treasury via trading fees over 3 months. Perhaps most importantly, Kwenta Treasury still owns the liquidity in the end and PALM has also managed to beat the impermanent loss. We will release an in-depth article about it soon.\nMotivation:\nCurrently, there are two major challenges in terms of ACX liquidity:\n\nHigh liquidity rental cost: 2.3m ACX is given away as LM incentives in the form of bribes via Aura Finance. Based on the average price of ACX since the incentive campaign started (December 2022), this bribe allocation represents roughly $125k, and has bootstrapped around $900k liquidity.\nMost probably the incentivized liquidity is going to leave once the reward runs out. This is particularly true when the LM is conducted through bribes, because rather than directly rewarding community LPs that believe in the value of ACX, it is the vlAura holders that receive the token and they tend to sell the bribes for AURA to increase their bribe earning power, or other assets. Renting liquidity is never a sustainable solution and eventually does more harm than good to the protocol and token holders.\n\nLow capital efficiency: ACX liquidity resides in a 50/50 Balancer pool, resembling a constant function market maker that only accepts full range liquidity provision. Meanwhile, the on-chain volume of ACX has been mostly below $30k daily, which indicates a rather low capital efficiency, i.e. <0.03, given the amount of ACX liquidity on Balancer (~$900k).\n\nAll of this presents both a huge cost and a missed opportunity for Across:\n\nThe bribe could have been reserved for better purposes that contribute to the development of the protocol.\nAcross could have adopted a market making solution like Arrakis PALM that actively manages UniV3 positions with high capital efficiency and low capital requirement, and still suffices the on-chain volume and even consistently pockets the trading fees for Across treasury.\n\nTo help Across save the cost and capture the opportunity, Arrakis proposes to provide Across with the full spectrum of market-making services on UniV3 with PALM to bootstrap and create deep on-chain liquidity.\nSpecification & Implementation:\nPhase 1 - Accumulate base asset\nAcross initially deposits a certain amount of POL into a PALM vault on both networks. Based on our past experience and the current on-chain volume of ACX, we suggest that the minimum deposit be $200k per vault. The deposit can be mostly made of ACX, e.g. 90/10 in ACX/stETH, and PALM will pull that ratio towards 50/50 over time.\nPhase 2 - Establish deep liquidity\nOnce the target ratio of 50/50 is reached, the focus is then on market-making to create deep liquidity for ACX and to minimize the slippage on both the buy and sell side of the volume.\nDuring the deployment period, the Across community has complete visibility into the execution and performance of PALM via a custom dashboard, and retains full custody of the liquidity in the vault, which means that the Across community can withdraw from the vault or revoke managing access from PALM at any time. PALM can only conduct market-making with the liquidity deposited in the vault and will never be able to remove the fund.\nFor the services provided, Arrakis charges fees on two fronts:\n\nManagement fee: 1% AUM fee on a yearly basis\nPerformance fee: 50% of trading fees generated\n\nDownside (Cons):\nThe potential downside may be that Across Treasury would have to allocate a certain amount of POL for PALM to manage, which may incur opportunity cost. However, given that the alternative would be spending ACX as incentives as opposed to retaining the ownership of the POL, this downside is rather trivial in our opinion.\nVoting:\nYes - employ Arrakis PALM for ACX liquidity management\nNo - seek for other alternatives instead\nAbstain - no vote\n\n Discontinue ACX Bribes on Aura and Replace with Reward Locking in the Near Term\n\n Updated - [ACX] Market Making Proposal - Arrakis PALM\n\n post by Everythingblockchain on Jun 14, 2023\n\n Everythingblockchain\n\n Hello there!\nI appreciate the proposal and the advantages highlighted for Arrakis PALM. However, I would like to provide some feedback to foster further discussion.\nFirstly, while Arrakis PALM offers advantages in liquidity management, it’s important to consider the potential implications of a more centralized approach.\nIn terms of profitability, it would be valuable to do an analysis to ensure that Arrakis PALM’s market-making strategy offers competitive benefits compared to other options. The proposed performance fee of 50% of trading fees, in addition to the management fee, seems quite high.\nRegarding the criticism of high liquidity rental costs associated with incentivized liquidity, it would be helpful to provide a comprehensive cost-benefit analysis to support the claim compared to market-making solutions like Arrakis PALM.\nThe proposal overlooks the potential benefits of incentivizing liquidity provision through ve(3,3) models. These not only attract liquidity but help earn earn emissions and other rewards.\nA detailed comparison showcasing how Arrakis PALM has helped improve protocol liquidity compared to ve(3,3) would be a valuable tool. Highlighting successful implementations and the resulting impact on liquidity depth and trading volumes would provide concrete evidence of Arrakis PALM’s effectiveness.\n\n post by defi_occam on Jun 16, 2023\n\n defi_occam\n\n Thank you for this well-researched proposal. I look forward to reading your in-depth article about KWENTA’s experience with Arrakis PALM and Velodrome.\nCan you say a bit more about how you came by the fees you will charge Across? Is there room to negotiate, or are they the same for all protocols?\n\n 10 days later\n\n post by caesarsherrod.eth on Jun 27, 2023\n\n caesarsherrod.eth\n\n I am very biased to the Velodrome model on Optimism. I’d prefer that the DAO moved into that realm of it. I am not opposed to Arrakis. But I just found this article that convinced me that Velodrome may be the better option.\nThis article, released on 22 June 2023, explains Arrakis as a superior app, but the counterarguing article is much more appealing to me.\nI will let the community make their own decisions because I am biased to $VELO and Velodrome because I have been using the protocol. Please read both and educate the self.\n\n 1 month later\n\n Closed on Jul 27, 2023\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 Updated - [ACX] Market Making Proposal - Arrakis PALM\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 2\n\n Aug 2023\n\n Across ($ACX) Community Initial Liquidity Proposal\n\n Passed Proposals\n\n Passed Proposals\n\n 49\n\n Nov 2022\n\n $ACX Liquidity - Update and Feedback Wanted\n\n Ideas & Feedback\n\n Ideas & Feedback\n\n 7\n\n Jun 2023\n\n Build liquidity for $ACX on Velodrome\n\n Active Proposals\n\n treasury-funding\n\n Active Proposals\n\n 8\n\n Jul 2023\n\n Velodrome Liquidity Program Extension\n\n Active Proposals\n\n Active Proposals\n\n 19\n\n Jan 2024","tokens":3989,"squid":"spider-09","role":"Bridge Spider","at":1791346011123,"hash":"f39f6a4320c18f66745ffac511a2907b08d81741"}
{"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 an application of smart contracts?","tokens":1408,"squid":"spider-05","role":"Spec Spider","at":1791346013876,"hash":"db5dcafc02dbef94445ffae5c169a4e17cb028a5"}
{"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 247\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 521\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":"spider-04","role":"Research Spider","at":1791346016125,"hash":"dc0d242e35d3e1aaa50ef42b09f78805abaef77a"}
{"url":"https://forum.across.to/t/updated-acx-market-making-proposal-arrakis-palm/1701","domain":"forum.across.to","title":"Updated - [ACX] Market Making Proposal - Arrakis PALM - Proposals - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n Updated - [ACX] Market Making Proposal - Arrakis PALM \n\n Proposals\n\n treasury-funding\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Aug 2023\n\n 1 / 4\n\n Aug 2023\n\n Aug 2023\n\n post by barbarossa_Arrakis on Aug 11, 2023\n\n barbarossa_Arrakis\n\n Update\nBased on the previous proposal from Arrakis Finance, the major updates in this revision include:\n\nDeploy PALM for ACX liquidity management on Mainnet only\nThe baseline PALM deposit allocated from Across DAO is set to $300k\nA review of the performance of PALM for ACX/WETH that was initiated about 2 months ago\n\nSummary\nDeploy Arrakis PALM to conduct market making for ACX on Mainnet UniV3, with POL allocated from Across DAO.\nIntroduction to Arrakis Finance and Arrakis PALM\nArrakis Finance is Web3’s trustless market-making infrastructure protocol that enables running sophisticated algorithmic strategies on Uniswap V3.\nSince launch, Arrakis has achieved\n\nOver $1.7b in TVL at its peak (currently around $200m), across Ethereum, Optimism, Arbitrum and Polygon\nMore than 25% Uniswap V3 total TVL\nMore than 80 projects have their liquidity managed via Arrakis vaults (both V1 and V2)\n\nArrakis PALM - Protocol Automated Liquidity Management is a novel liquidity bootstrapping mechanism that taps into the organic trading volume on UniV3. It is the first product built on top of the Arrakis infrastructure.\nIn essence, PALM helps protocols bootstrap their base asset inventory (ETH, USDC, etc.) and attain deep and sustainable liquidity. The major advantages of using PALM are:\n\nZero incentive: no LM incentive needed, liquidity bootstrapping is done solely via market making.\nLow requirement in base asset: the initial liquidity can be made of mostly ACX, and PALM will progressively pull it towards 50% to create an equal buy/sell support.\nHigh capital efficiency: by autonomously and actively managing concentrated liquidity, especially once a sufficient amount of base asset has been bootstrapped, PALM can further reduce the slippage for large trades even if with limited overall liquidity.\nNo biased price impact: no swaps involved, PALM conducts market making by setting up ranges / limit orders..\nMinimize or outperform IL: PALM is able to keep the value of the deposit close to that of holding the initial assets, and often outperform it.\nTrustless & transparency: Across DAO retains the custody of the liquidity and can withdraw at all times. PALM only autonomously manages the liquidity but can never remove it. All executions of PALM can be monitored on-chain with full transparency.\n\nPALM has been deployed for over 30 protocols and counting. Protocols such as Stargate, Kwenta, Pika, Premia, etc. are benefiting from the high capital efficiency and cost effectiveness enabled by PALM.\nBackground & Motivation\nCurrently, there are two major challenges in terms of ACX liquidity:\n\nHigh liquidity rental cost: 2.9m ACX has been given away as LM incentives in the form of bribes via Aura Finance. Based on the current price of ACX, this bribe allocation represents roughly $183k, and has bootstrapped around $1m liquidity.\nAs elaborated in this recent proposal, the efficiency of the bribe campaign has depreciated by about 50% over time. In addition, most probably the liquidity will leave once the reward runs low. This is particularly true when the LM is conducted through bribes, because rather than directly rewarding community LPs that believe in the value of ACX, it is the vlAura holders that receive the token and they tend to sell the bribes for AURA to increase their bribe earning power, or other assets.\nEven though in the same proposal a short term solution (“Reward Locking”) is proposed, it should only act as an interim solution as renting liquidity is never a sustainable solution and eventually does more harm than good to the protocol and token holders.\n\nLow capital efficiency: A 50/50 Balancer pool or any x*y=k type DEX has the issue of low capital efficiency. With currently $1m liquidity sitting in the Balancer pool, it can hardly handle any significant volume without causing large price impact. Concentrated liquidity DEX such as UniV3 on the other hand, can apply liquidity where it’s needed the most, and thus minimize price impact for large trades even with limited capital.\n\nAt the same time, PALM has been managing liquidity for ACX/WETH on UniV3 for nearly 6 weeks, with liquidity allocated from Risk Labs. The performance, especially in comparison with the Balancer pool, has been as intended.\n\nThe ratio of ACX/WETH in the initial deposit was about 90/10. Over time, PALM has gradually bootstrapped a decent amount of WETH and pulled the ratio to about 40/60, which enables much stronger liquidity support for large volumes.893×368 12.8 KB\n\nAs more WETH was bootstrapped, PALM allocated more liquidity from the inventory into the market, which leads to the decline of price impact for large swaps.\n1600×430 51.6 KB\n\nWhen compared with the Balancer pool, PALM offers competitive pricing for large swaps.\n975×632 174 KB\n\nFor large volumes, such as the volume surge of ACX over the past 3 weeks, PALM undercuts the Balancer pool and take the majority of the flow.\n600×371 13.8 KB\n\nIn addition, PALM has also earned some decent trading fees for Risk Labs.\n301×137 6.51 KB\n\nAll the above demonstrates how capital efficient and cost effective PALM. We hope that the proven record of the running PALM vault for ACX will give more confidence to Across community so that the DAO can allocate POL into another PALM vault to further strengthen the liquidity depth for ACX.\nTherefore, Arrakis proposes to provide Across DAO with the full spectrum of market making services on UniV3 with PALM to bootstrap and create deep on-chain liquidity.\nSpecification\nPhase 1 - Accumulate base asset\nAcross DAO deposits a minimum $300k POL in ACX/WETH into a PALM vault. The ratio of ACX/WETH can be as low as 5/95. PALM will first pull that ratio towards 50/50 over time.\nPhase 2 - Establish deep liquidity\nOnce the target ratio of 50/50 is reached, the focus is then on creating deep liquidity for ACX to minimize the price impact on both buy and sell side for large swaps.\nDuring the deployment period, the Across DAO have complete visibility of the execution and performance of PALM via a custom dashboard, and retains full custody of the liquidity in the vault, which means that Across DAO can withdraw the liquidity or revoke the managing access from PALM at all times. PALM can only conduct market making with the liquidity in the vault and never be able to remove the fund.\nFor the services provided, Arrakis charges fees on two fronts:\n\nManagement fee: 1% AUM fee on a yearly basis\nPerformance fee: 50% of trading fees generated\n\nReference\nFor more information regarding Arrakis and Arrakis PALM, feel free to have a look at our docs and join our community. I’m also more than happy to respond to any comments here from the Across community about this proposal!\nWebsite\nDocs\nAudits\nTwitter\nDiscord\n\n 2\n\n read \n\n 4\n min\n\n post by Kevin_UMA on Aug 14, 2023\n\n Kevin_UMA\n\n Thanks for refreshing this proposal @barbarossa_Arrakis. I think better ACX liquidity on uni v3 does make sense. I have a few questions:\n\nHow did you come to the need for $300k? There is some liquidity from Risk Labs already\nWhen is the 50% profit share divided? Is there a cadence where these profits are shared?\nFor the 1% AUM fee does Arrakis ensure some amount of liquidity or uptime? For example, market makers for CEX would say they would guarantee x dollars of liquidity within a y % of depth. I think general question is how do we ensure Arrakis is doing some work for earning this 1%. If you were a bad actor you can just deploy very wide ranges and just earn 1%.\nSimilar to 2) - when does Arrakis take this 1% fee?\n\nA logistic question for Across DAO - how do we get the initial amount of WETH? The DAO only has ACX and UMA. If we want to make things simple and if it’s just a small amount of WETH to start we could consider a swap with Risk Labs given it’s the supporting foundation?\n\n post by barbarossa_Arrakis on Aug 15, 2023\n\n barbarossa_Arrakis\n\n All valid questions \n\nThis is going to be a separate vault with Across DAO’s fund. For the maintenance of each vault, there is an operational overhead. If an asset doesn’t have much volume, $3k is barely enough to cover the operational cost.\n\nFees are collected at each rebalance, and the part for the protocol is compounded back to the vault.\n\nAs explained in the first point, this 1% is essentially a somewhat hedge for operational cost, while the actual revenue for Arrakis is from the trading fee split. The deeper PALM makes the liquidity, the more volume PALM facilitates, and hence the more fees it earns. Therefore, Arrakis has every incentive to conduct the best practice in market making so that both Arrakis and the customer protocol can reap the highest rewards.\nAnother important aspect as opposed to a CEX market maker is the non-custodial nature of Arrakis. Protocols have the complete autonomy in deciding if they want to remove their liquidity, for reasons including not feeing content with the performance.\n\nIt is taken quarterly.\n\n 1 month later\n\n Closed on Sep 14, 2023\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 ACX Market Making Proposal - Arrakis PALM\n\n Active Proposals\n\n treasury-funding\n\n Active Proposals\n\n 3\n\n Jun 2023\n\n Across ($ACX) Community Initial Liquidity Proposal\n\n Passed Proposals\n\n Passed Proposals\n\n 49\n\n Nov 2022\n\n $ACX Liquidity - Update and Feedback Wanted\n\n Ideas & Feedback\n\n Ideas & Feedback\n\n 7\n\n Jun 2023\n\n Velodrome Liquidity Program Extension\n\n Active Proposals\n\n Active Proposals\n\n 19\n\n Jan 2024\n\n Reduce ACX emissions for ACX LPs, WBTC LPs and wstETH/ACX LPs\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 11\n\n Aug 2024","tokens":3975,"squid":"spider-09","role":"Bridge Spider","at":1791346023211,"hash":"5aba7810ef1194fe9dee1d3a3b15b8fbc8fc4290"}
{"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":"spider-05","role":"Spec Spider","at":1791346024001,"hash":"cb71768d8b6f341602a4c2b9446bea5a8251c5d8"}
{"url":"https://ethresear.ch/t/consolidation-incentives-in-orbit-vorbit-ssf/21593","domain":"ethresear.ch","title":"Consolidation incentives in Orbit/Vorbit SSF - Proof-of-Stake / Economics - Ethereum Research","text":"Consolidation incentives in Orbit/Vorbit SSF \n\n Proof-of-StakeEconomics\n\n single-slot-finality,consensus-incentives,validator-consolidation\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jan 2025\n\n 1 / 1\n\n Jan 2025\n\n Jan 2025\n\n post by aelowsson on Jan 26, 2025\n\n aelowsson\n\n 1. Introduction\n1.1 Background\nA key proposition of Orbit SSF is that validators rotate based on size, such that those with larger balances are active more frequently, while still giving all validators roughly equal yield. Active validators can be slashed, so large validators will therefore assume greater risk than small validators. Setting aside mass slashing events, a staking pool might prefer to run smaller validators so that a faulty setup can be caught early and affect only a small fraction of its total stake. Yet it is desirable that stakers consolidate when possible—consolidation level will directly influence the economic security that the protocol can offer, ceteris paribus. Therefore, Orbit SSF should provide individual consolidation incentives. These can be combined with collective consolidation incentives that benefit everyone equally upon consolidation.\nExactly how yield should vary with validator size and activity rate has not yet been exhaustively investigated. The Orbit SSF post offers a good starting point, but it would be valuable with a thorough review. It might also be difficult to know beforehand how to distribute incentives such that they do not favor certain validator sizes, thus leading validators to congregate at specific sizes. Therefore, a mechanism for automating and adapting the distribution could be desirable. Furthermore, Vorbit SSF proposes a less linear relationship between validator size and activity rate, which strengthens the case to account for both when designing incentives.\nAnother question is how the magnitude of the consolidation incentives should vary with consolidation level and staking yield, and how consolidation should be quantified. This pertains both to the shape and scale of aggregate incentives. One issue here is that the level of the MEV is unknown to the protocol, while proposal rights still ought to be distributed according to stake as they are today. Another thing to study further is the consolidation level at which incentives should go to zero.\n1.2 Overview\nThis post analyzes how consolidation incentives can be designed to match protocol requirements, offering a systematic framework. This framework consists of two shape variables f_1𝑓1 and f_2𝑓2 in the range 0-1 and one scale variable f_y𝑓𝑦. The consolidation force f_1𝑓1 varies with consolidation level, calculated from the validator count V𝑉 at some specific stake deposit size D𝐷. It is presented in Section 2. Section 3 then explores the force distribution f_2𝑓2 that provides individual consolidation incentives to each validator based on their activity rate a𝑎, potentially relying also on their size s𝑠. These variables are scaled to enact an adjustment to the yield by multiplication with a consolidation force scale f_y𝑓𝑦, described in Section 4. Focusing on endogenous variables, the attenuating collective incentive can be parameterized as\n\nf_1f_y\n𝑓1𝑓𝑦\nand the attenuating individual incentive as\n\nf_1f_2f_y.\n𝑓1𝑓2𝑓𝑦.\nIf f_1𝑓1 and f_y𝑓𝑦 are kept identical for both incentives (a realistic design goal), the full equation of the attenuating consolidation incentive y_c𝑦𝑐 becomes\n\ny_c = f_1f_y(c+f_2),\n𝑦𝑐=𝑓1𝑓𝑦(𝑐+𝑓2),\nwhere c𝑐 is the relative strength of the collective incentive. When including the previously outlined exogenous variables, the consolidation incentive y_c(v)𝑦𝑐(𝑣) for validator v𝑣 with activity rate a_v𝑎𝑣 and size s_v𝑠𝑣 becomes\n\ny_c(v) = f_1(V\\!, D)f_y(y')(c+f_2(a_v, s_v)),\n𝑦𝑐(𝑣)=𝑓1(𝑉,𝐷)𝑓𝑦(𝑦′)(𝑐+𝑓2(𝑎𝑣,𝑠𝑣)),\nwhere y'𝑦′ reflects some measure capturing the staking yield, potentially including estimates of the MEV (Section 4 presents several variants). Section 5 examines attenuating, boosting and issuance-neutral modes for the incentives, with attenuating and issuance-neutral modes highlighted as the most interesting. The attenuating mode is used as the primary example in this post, by which y_c𝑦𝑐 updates the target issuance yield for each validator via y'_i=y_i-y_c.𝑦′𝑖 =𝑦𝑖 −𝑦𝑐. Section 6 offers a concluding specification based on the analysis.\nAppendix A presents approximations of the validator count under a Zipfian distribution of staker balances and Appendix B offers a detailed comparison between this post and the incentives design in the Orbit SSF post. Appendix C provides equations for generating validator sets with gradually varying Zipfianess, which are useful when simulating the impact of consolidation.\n2. Consolidation force f_1𝑓1\nThe consolidation force f_1𝑓1 is the same for all validators and varies with consolidation level, specifically the validator count V𝑉 and stake deposit size D𝐷, i.e., f_1(V\\!,D).𝑓1(𝑉,𝐷). It approaches 1 under poor consolidation and 0 under good consolidation when adopted as an attenuating incentive, which is reversed if applied as a boosting incentive (i.e., 1-f_11 −𝑓1). Section 2.1 first provides a simple approximation of when consolidation is in line with expectations, in terms of a Zipfian distribution of stakers. Section 2.2 then explores appropriate shapes for f_1𝑓1 and Section 2.3 outlines benefits and drawbacks of a dynamic f_1𝑓1.\n2.1 Approximated validators under a Zipfian quantity of stakers\nIt seems reasonable to relate the consolidation force to some tangible measure of the consolidation level of the dataset. An early assumption is that Ethereum can hope to attract stakers with capital distributed according to Zipf’s law. Once the dataset has reached a corresponding consolidation level, incentives for further consolidation should then arguably be very small. The Vorbit SSF post presents two equations that can be used to compute the number of validators V_Z𝑉𝑍 under a Zipfian distribution of staker balances. These equations are however rather complex and not particularly suitable as part of a protocol specification.\nAppendix A of this current post therefore derives three simplified equations with Figures A1-A2 detailing their accuracy. The log adjusted approximation\n\nV_Z = \\frac{D}{20\\,\\ln D}\n𝑉𝑍=𝐷20ln⁡𝐷\nwill be used in this post due to its simplicity and relative accuracy. Given a specific stake deposit size D𝐷, the number of validators under a Zipfian distribution of staker balances can thus easily be computed.\n2.2 Consolidation force shapes\nPotential shapes of the f_1𝑓1 curve will now be defined. The theoretical maximum quantity of validators is V_{\\text{max}}=\\lfloor D/s_{\\text{min}}\\rfloor𝑉max =⌊𝐷/𝑠min⌋, where s_{\\text{min}}𝑠min is the minimum validator size of 32. The theoretical minimum quantity of validators is V_{\\text{min}}=\\lceil D/s_{\\text{max}}\\rceil𝑉min =⌈𝐷/𝑠max⌉, where s_{\\text{max}}𝑠max is the maximum validator size of 2048. It can be noted that the settings for s_{\\text{max}}𝑠max and s_{\\text{min}}𝑠min thus influence the output.\n2.2.1 Linear shape\nOne example is to decrease the consolidation force linearly with a decreasing validator count (increasing consolidation). An equation for forming such a linear f_1𝑓1, given a starting point V_{\\text{start}}𝑉start, is:\n\nf_1 = \\frac{V-V_{\\text{start}}}{V_{\\text{max}}-V_{\\text{start}}}.\n𝑓1=𝑉−𝑉start𝑉max−𝑉start.\nFour examples relying on this equation are shown in Figure 1. The simplest is to extend f_1𝑓1 across the full range by setting V_{\\text{start}}=V_{\\text{min}}𝑉start =𝑉min (black line) or to start f_1𝑓1 at V_Z𝑉𝑍 by setting V_{\\text{start}}=V_Z𝑉start =𝑉𝑍 (red line). Another option is to let f_1𝑓1 reach 0 at the halfway point between V_Z𝑉𝑍 and V_{\\text{min}}𝑉min through V_{\\text{start}} = (V_{\\text{min}}+V_Z)/2𝑉start =(𝑉min +𝑉𝑍)/2 (black dashed line). A fourth option is to enforce some specific f_1𝑓1 at V_Z𝑉𝑍, here denoted f_z𝑓𝑧, through the equation\n\nV_{\\text{start}}=\\frac{V_Z-f_zV_{\\text{max}}}{1-f_z}.\n𝑉start=𝑉𝑍−𝑓𝑧𝑉max1−𝑓𝑧.\nIn the figure, f_z𝑓𝑧 was set to 0.05 (red dashed line). The benefit of this option is more precision regarding what remains of the incentives at a Zipfian consolidation level, whereas the first and to a lesser extent the third option will see f_z𝑓𝑧 drift slightly across D𝐷 (compare with the linear approximation of f_1𝑓1 in Appendix A). The reason for letting the incentive reach 0 earlier than at V_{\\text{min}}𝑉min, here by relying on V_Z𝑉𝑍, is to promote fairness for small validators at sufficient consolidation levels. A potential reason to avoid setting f_1=0𝑓1 =0 as high as V_Z𝑉𝑍 is that it precludes an equilibrium at V_Z𝑉𝑍 if many stakers will only consolidate when they earn a higher yield from it, which is probably a reasonable assumption (more on this below).\nAn incentive that is linear with respect to the proportion of the stake that is active, D_a/D𝐷𝑎/𝐷, has been explored previously. Appendix B offers a comparison with that strategy. The linearity is particularly appealing for collective consolidation incentives, where the derivative of the curve represents the incentive. Stakers gain from a reduction in f_1𝑓1, but its magnitude does not by itself affect the incentive to consolidate.\nFigure 13113×1948 271 KB\nFigure 1. Four examples of a linear consolidation force f_1𝑓1, reaching zero at different validator counts.\n2.2.2 Sigmoidal shape\nA more versatile alternative begins with the first step as previously:\n\nx = \\frac{V-V_{\\text{start}}}{V_{\\text{max}}-V_{\\text{start}}}.\n𝑥=𝑉−𝑉start𝑉max−𝑉start.\nA second step is then applied to produce a sigmoid:\n\nf_1 =\\frac{1}{\\displaystyle 1 + \\Bigl({\\frac{1 - x}{tx}}\\Bigr)^{2}}.\n𝑓1=11+(1−𝑥𝑡𝑥)2.\nThe parameter t𝑡 controls where the sigmoid’s main transition occurs, and the power (here 2) adjusts its steepness. Figure 2 illustrates a sigmoid (power 2) that pushes the transition to the left, close to V_Z𝑉𝑍, by settng t=5𝑡 =5. The start point was set to V_{\\text{start}} = (V_{\\text{min}}+V_Z)/2𝑉start =(𝑉min +𝑉𝑍)/2 (as in the dashed black curve of the previous Figure 1).\nFigure 23113×1948 188 KB\nFigure 2. A consolidation force with a sigmoidal shape, which has an adjustable steepness and transition point.\nA steep sigmoidal consolidation force is more relevant to consider for individual incentives, where the f_1𝑓1 magnitude regulates the yield differential between stakers and thus represents the consolidation incentive. For collective incentives, the slope of the f_1𝑓1 magnitude instead represents the consolidation incentive. A compromise that can be used both for collective and individual incentives would be to mix the linear and sigmoidal shape.\n2.2.3 Mixed shape\nA mixed shape can be generated through the equation\n\nf_1 =\\frac{w}{\\displaystyle 1 + \\Bigl(\\frac{1 - x}{tx}\\Bigr)^{2}}+(1-w)x.\n𝑓1=𝑤1+(1−𝑥𝑡𝑥)2+(1−𝑤)𝑥.\nThe first part of the equation creates the sigmoidal shape, which is weighed by w𝑤 against the linear shape in the second part. Figure 3 shows an example with an equal weighing w=0.5𝑤 =0.5, once again with t=5𝑡 =5 and the same V_{\\text{start}}𝑉start at the halfway point between V_{\\text{min}}𝑉min and V_{\\text{start}}𝑉start as previously. Note the rather fixed slope between 400k and 1M validators, associated with the linear shape.\nFigure 33113×1948 195 KB\nFigure 3. A mixed consolidation force, weighing together the linear and sigmoidal f_1𝑓1 curve.\nJust as with the other options, a question to consider is whether f_1𝑓1 should go to zero already around V_Z𝑉𝑍, or if it is reasonable to leave some small incentive in place throughout the full range. The latter option seems perhaps more attractive since, presumably, some individual incentive must remain in place under equilibrium. In other words, setting the individual incentive to zero at V_Z𝑉𝑍 precludes this point from being reached if it is not otherwise a profitable option for staking service providers (SSPs). But the existence of any remaining collective consolidation incentives at V_Z𝑉𝑍 can then also factor in.\n2.3 Fixed or dynamic schedule\nConsolidation incentives can have a fixed or dynamic schedule. Under a fixed schedule, a specific validator composition at some quantity of stake will give a specific f_1𝑓1 as illustrated in Figures 1-3. With a dynamic schedule, there is also a time component, and f_1𝑓1 will adjust slowly towards its stipulated target. The dynamic schedule can still have the same type of f_1𝑓1 curve as a target, as previously exemplified for the issuance reward curve, with a typical gradual shift captured here.\nThe most natural choice is to have a fixed schedule with no time component. The reason is the same as when it comes to the reward curve: the focus is the effect in the long run. The curve can capture the sought balance between fairness and the incentive to consolidate without involving time as a parameter. However, if the protocol wishes to puruse more extreme measures, such as for example forcing a Zipfian distribution by otherwise letting the f_1𝑓1 of the individual incentive (f_1f_2f_y𝑓1𝑓2𝑓𝑦) approach infinity, then a dynamic schedule is required. But such a strategy can lead to very high yield differentials between small solo stakers and delegating stakers under equilibrium. It is then instead preferable to strike a balance between the need for consolidation and the need for fairness via f_1𝑓1 curves similar to those outlined in this post.\nShould there be particular concerns around stakers temporarily altering the validator composition, for example in response to changes in MEV or as a means for discouraging other stakers, it is of course possible to let the change to the long-run force be applied gradually when a shift occurs. Besides additional complexity, an additional risk is that if the f_1𝑓1 does not adjust quickly enough with changing circumstances, there is a risk of stakers “overshooting” the natural equilibrium consolidation level.\n3. Force distribution f_2𝑓2 for individual incentives\nThe force distribution f_2𝑓2 distributes the consolidation force across the validator set, forming individual incentives. In the baseline “attenuating” mode, a validator with a specific f_2𝑓2 receives an individual yield attenuation of f_1f_2f_y𝑓1𝑓2𝑓𝑦. In the boosting mode it receives a boost of f_1(1-f_2)f_y𝑓1(1 −𝑓2)𝑓𝑦 under the same f_2𝑓2 curve, but this section will be centered on the attenuating mode (a further review of mode is presented in Section 5 with a comparison in Table 1). Validators of the maximum size will generally have f_2=0𝑓2 =0 and thus no attenuation. Validators of the minimum size will generally have f_2=1𝑓2 =1 and thus receive the maximum attenuation f_1f_y𝑓1𝑓𝑦. In essence, given a yield differential f_1f_y𝑓1𝑓𝑦 between the biggest/most active and smallest/least active validators, the role of f_2𝑓2 is to determine the effect on all validators in between.\nThere are two main avenues for how to compute f_2𝑓2 for each individual validator:\n\nAID (Section 3.1): incentives-differential based on an applied notion of fairness such as related to activity rate or validator size. This solution is the easiest to implement.\nCID (Section 3.2): cumulative incentives-differential as an overlay on top of AID, that distributes the designed incentives based on a sorted list of validator sizes. This is an attempt to adjust rewards if certain validator sizes become too favorable, but it is more complex.\n\nA third option “BID” (Section 3.3) attempts to strike a balance by computing both an AID and a CID, letting f_2𝑓2 be a weighing of both.\n3.1 AID\nWith AID, the protocol adjusts the yield based on risks assumed or space taken up by validators. A natural assumption is that risks vary with activity rate a𝑎 (the proportion of the time that a validator is active as an attester), which in turn varies with validator size s𝑠. If the activity rates are not the same for validators when they attest to the available chain and the finality gadget, but still vary between validators for both attestation duties, a unified measure would need to be defined. This section will review four options for the f_2𝑓2 curve:\n\nSec. 3.1.1; f_2(a)𝑓2(𝑎): attenuate the yield based on an estimate of assumed risks derived from a𝑎.\nSec. 3.1.2; f_2(s)𝑓2(𝑠): simulate a validator fee based on the size s𝑠 of the validator.\nSec. 3.1.3; f_2(a)𝑓2(𝑎) or f_2(s)𝑓2(𝑠) or f_2(a, s)𝑓2(𝑎,𝑠): rely on a log-scaled measure with equidistant reduction across either a𝑎 or s𝑠 or both.\nSec. 3.1.4; f_2(a, s)𝑓2(𝑎,𝑠): use a weighed average of the first two options.\n\nSection 3.1.5 finally compares the options and plots them.\n3.1.1 Linear in a𝑎 – neutral w.r.t. expected active stake\nDefine the activity rate of validator v𝑣 as a_v𝑎𝑣. An intuitive solution favored previously is to let f_2𝑓2 capture inactivity percentage by deducting the activity rate\n\nf_2 = 1-a_v.\n𝑓2=1−𝑎𝑣.\nThe equation can be re-scaled to always have the force extend across the full range. Define the minimum possible activity rate as a_{\\text{min}}𝑎min and the maximum as a_{\\text{max}}𝑎max. The f_2𝑓2 for a validator with activity rate a_v𝑎𝑣 can then be computed as\n\nf_2 = \\begin{cases}\n\\displaystyle \\frac{a_{\\text{max}} - a_v}{a_{\\text{max}} - a_{\\text{min}}} & \\text{if } a_{\\text{max}} \\neq a_{\\text{min}} \\\\[0.1ex] \\\\\n0 & \\text{if } a_{\\text{max}} = a_{\\text{min}}.\n\\end{cases}\n𝑓2=⎧{\n{\n{⎨{\n{\n{⎩𝑎max−𝑎𝑣𝑎max−𝑎minif 𝑎max≠𝑎min0if 𝑎max=𝑎min.\nThe type of linear scaling of f_2𝑓2 presented in the above two equations results in the following feature: since stakers pay specifically for inactivity, an agent with an endowment to be staked—realizing some specific expected active stake—is affected equally regardless of which exact distribution of validator sizes it selects. For example, an agent staking 4096 ETH using one 2048-ETH validator and sixty-four 32-ETH validators will get almost the same expected active stake as when opting to run four 1024-ETH validators, and thus almost the same f_2𝑓2 on average across its stake. Any other combination yielding the same amount of active stake will yield the same average f_2𝑓2.\nWith a focus on activity as risk, this seems like a natural solution. There are many nuances to the question of how activity rates and validator compositions actually translate to risk. Further dialogue with staking service providers could provide important perspectives and more elaborate measures.\n3.1.2 Inversely proportional to s𝑠 – neutral w.r.t. number of validators\nFrom the protocol’s perspective, should the two example distributions in Sec. 3.1.1 actually be treated equally? The second option with 4 1024-ETH validators might seem better, given that the first option instead results in 65 validators. It is preferable to be able to fully finalize the 4096-ETH endowment by providing space for only 4 validators in total in one slot, as opposed to requiring space for 65 validators. What would an equation that instead is neutral w.r.t. validator count look like? Define the size of a validator as s_v𝑠𝑣. The sought equation is then\n\nf_2 = \\frac{32}{s_v}, \n𝑓2=32𝑠𝑣,\nwith validators of size 32 receiving the full attenuation (f_2=1𝑓2 =1). This equation can also be re-scaled to always have the force extend across the full range:\n\nf_2 = \\frac{ s_{\\text{min}} ( s_{\\text{max}} - s_v ) }{ s_v ( s_{\\text{max}} - s_{\\text{min}} ) }.\n𝑓2=𝑠min(𝑠max−𝑠𝑣)𝑠𝑣(𝑠max−𝑠min).\nThe inversely proportional f_2𝑓2 can be thought of as simulating a classical “validator fee”, and the mechanism is neutral with regard to the number of validators that some specific endowment is distributed across. The fee must be taken via an inverse relationship because of how the consolidation force is constructed to be deducted from the earnings. If the same f_2𝑓2 was applied to every validator, a bigger validator would have to pay a higher nominal fee, given that its total rewards are higher. The inverse scaling rectifies that by weighing across stake. One way to understand the equation is to consider the outcome for 2048 ETH staked using any validator size. The total fee for 64 32-ETH validators then becomes 64 times higher than for 1 2048-ETH validator, the fee for 32 64-ETH validators becomes 32 times higher, etc (ignoring the re-scaling normalization). Another way to understand it is that f_1f_y𝑓1𝑓𝑦 comes to stipulate the validator fee for one 32-ETH validator. Running a 64-ETH validator costs the same in total as a 32-ETH validator, and thus f_1f_y𝑓1𝑓𝑦 must be halved when distributed across twice the stake.\nIn Orbit SSF with a 2048-ETH threshold, a_v𝑎𝑣 and s_v𝑠𝑣 will be linearly related, so the equation could then easily also be framed in terms of a_v𝑎𝑣:\n\nf_2 = \\begin{cases}\n\\displaystyle \\frac{ a_{\\text{min}} (a_{\\text{max}} - a_v) }{ a_v (a_{\\text{max}} - a_{\\text{min}}) } & \\text{if } a_{\\text{max}} \\neq a_{\\text{min}} \\\\[0.1ex] \\\\\n0 & \\text{if } a_{\\text{max}} = a_{\\text{min}}.\n\\end{cases}\n𝑓2=⎧{\n{\n{⎨{\n{\n{⎩𝑎min(𝑎max−𝑎𝑣)𝑎𝑣(𝑎max−𝑎min)if 𝑎max≠𝑎min0if 𝑎max=𝑎min.\nHowever, this will not work if thresholding at for example 1024, or in Vorbit SSF with a more elaborate connection between validator size and activity rate, as illustrated in Figure 22 of that post.\n3.1.3 Log-scaled – equidistant f_2𝑓2 in log domain\nWhile the inversely proportional scaling across s_v𝑠𝑣 could lead to smaller validator sets, it might seem less “fair” than the linear construction across a_v𝑎𝑣. An agent in control of less stake might overlook its lower yield if the distribution specifically is designed to compensate validators for being more active, thus assuming greater risk. On the other hand, fairness could however also be constructed to reflect the strain that a staker puts on the protocol.\nNote further that a distribution that is neutral w.r.t. expected active stake (Sec. 3.1.1) will give very similar outcomes for validator sizes ranging between 32-128 ETH (see also Figure 4 in Section 3.1.5). A distribution that is neutral w.r.t. number of validators (Sec. 3.1.2) will give very similar outcomes for validator sizes ranging between 512-2048 ETH. It might instead seem desirable for stakers with a compromise distribution where f_2𝑓2 is affected equally at any point from the same log-scaled change to either a_v𝑎𝑣 or s_v𝑠𝑣. Such a force distribution, scaled to span the full range, is\n\nf_2 = \\frac{\\log_2\\left(s_{\\text{max}}/s_v \\right)}{\\log_2\\left( s_{\\text{max}}/s_{\\text{min}} \\right)},\n𝑓2=log2⁡(𝑠max/𝑠𝑣)log2⁡(𝑠max/𝑠min),\nor\n\nf_2 = \\begin{cases}\n\\displaystyle \\frac{\\log_2\\left(a_{\\text{max}}/a_v \\right)}{\\log_2\\left( a_{\\text{max}}/a_{\\text{min}} \\right)} & \\text{if } a_{\\text{max}} \\neq a_{\\text{min}} \\\\[0.1ex] \\\\\n0 & \\text{if } a_{\\text{max}} = a_{\\text{min}},\n\\end{cases}\n𝑓2=⎧{\n{\n{⎨{\n{\n{⎩log2⁡(𝑎max/𝑎𝑣)log2⁡(𝑎max/𝑎min)if 𝑎max≠𝑎min0if 𝑎max=𝑎min,\nor a weighed combination of the two. This construction avoids the more extreme outcomes of the previous two ideas.\n3.1.4 Weighing of linear and inversely proportional f_2𝑓2\nA fourth option is to weigh together the linear (3.1.1) and inversely proportional (3.1.2) constructions. A benefit is that both have a clear interpretation, which then extends to the weighed measure. The equation becomes\n\nf_2 = w\\frac{ a_{\\text{max}} - a_v }{ a_{\\text{max}} - a_{\\text{min}} } + (1-w)\\frac{ s_{\\text{min}} ( s_{\\text{max}} - s_v ) }{ s_v ( s_{\\text{max}} - s_{\\text{min}} ) },\n𝑓2=𝑤𝑎max−𝑎𝑣𝑎max−𝑎min+(1−𝑤)𝑠min(𝑠max−𝑠𝑣)𝑠𝑣(𝑠max−𝑠min),\nassuming a_{\\text{max}} \\neq a_{\\text{min}}𝑎max ≠𝑎min, with f_2=0𝑓2 =0 otherwise. The average shown in yellow in Figure 4 in the next subsection sets w=0.5𝑤 =0.5. Note that this option is particularly useful when the relationship between a𝑎 and s𝑠 is less linear (e.g., Vorbit SSF).\n3.1.5 Comparison of AID constructions\nFigure 4 shows the four options previously presented using the validator sizes and activity rates of Orbit SSF thresholded at 2048, which is also s_{\\text{max}}𝑠max, such that a𝑎 and s𝑠 always are linearly related. Green and red $f_2$s are neutral w.r.t. estimated risk or occupied validator spots, and this gives fairly “lopsided” distributions. The log-scaled (blue) and average (yellow) distributions are less lopsided (at least from a log-scale perspective) and will see a more or less equal impact on f_2𝑓2 when a validator doubles in size.\nFigure 43136×1637 337 KB\nFigure 4. Four options for the force distribution f_2𝑓2, plotted under a baseline Orbit SSF thresholding. In green, a distribution that is linear in a𝑎 and neutral w.r.t. the expected active stake of some given endowment. In red, a distribution that is inversely proportional to s𝑠 and neutral w.r.t. the number of validators used for some endowment. In yellow, the average of the green and red force distributions, and in blue a log-scaled distribution.\n3.2 CID\nComputing the f_2𝑓2 via AID is simple and intuitive, but two things can be noted:\n\nIf the mechanism does not model risks correctly, validators might congregate at sizes that produce the best risk-adjusted rewards, and the distribution may excessively diverge from some natural Zipfian state.\nThe protocol’s priorities may change with consolidation level, focusing on how much space a staker takes up under low consolidation and focusing on fairness w.r.t. risk when the consolidation level already is good.\n\nPoints (1) and (2) can be addressed by applying a cumulative incentives-differential (CID) as an overlay on top of a specific AID policy. First, a neutral validator composition is defined and the applicable AID policy at this composition specified. Then, validators are sorted according to size and given the f_2𝑓2 associated with their specific position in the sorted list.\nA reasonable approach could be to define a Zipfian distribution of validators as neutral, such that the total ETH per log-spaced bin is fixed. Note here, that such a composition is a fair bit less consolidated than that generated from a Zipfian distribution of stakers, where each staker with more than 2048 ETH divides its stake into several big validators. Compare for example with Figure 2 in a previous post analyzing a Zipfian distribution of stakers.\nDefine a Zipfian distribution of validators as neutral and apply the CID across a log-scaled AID. Outcomes for various validator compositions with this specification are shown in Figures 5-10. As evident from Figures 5-6, when the validator distribution is Zipfian, a validator shifting its size will see its f_2𝑓2 change just as under a pure log-scaled AID (blue line in Figure 4). If the consolidation level is less than Zipfian, the f_2𝑓2 is closer to the inversely proportional distribution (red line in Figure 4). If the consolidation level is better than Zipfian, the f_2𝑓2 is instead closer to the linear distribution (green line in Figure 4). The latter scenario is illustrated in Figures 7-8. Thus the protocol’s priorities shift with consolidation level, as discussed in point (2) above. To align even closer with that point in the case where the baseline Orbit weighting is not pursued, there would also need to be a gradual shift in focus from s𝑠 to a𝑎 as consolidation improves. One could consider (1-f_1)a+f_1s(1 −𝑓1)𝑎 +𝑓1𝑠 or something slightly more refined.\nFigure 53497×2148 327 KB\nFigure 5. Force distribution f_2𝑓2 under a Zipfian validator set plotted against the number of validators per bin.\nFigure 63496×2148 285 KB\nFigure 6. Force distribution f_2𝑓2 under a Zipfian validator set plotted against total ETH per bin.\nFigure 73497×2148 302 KB\nFigure 7. Force distribution f_2𝑓2 under a validator set that skews larger, plotted against the number of validators per bin.\nFigure 83496×2148 286 KB\nFigure 8. Force distribution f_2𝑓2 under a validator set that skews larger plotted against total ETH per bin.\nIf validators congregate at some specific size, it could imply that this size offers the best risk/reward. The force distribution will then automatically adapt, with the goal of stipulating a “fairer” yield for validators. An example is provided in Figures 9-10, with two peaks in validator sizes and a corresponding reaction in the force distribution. For illustrative purposes, the example is rather pronounced. In reality, there would likely be more subtle peaks and valleys, and thus more subtle changes to the f_2𝑓2.\nFigure 93497×2148 318 KB\nFigure 9. Force distribution f_2𝑓2 under a validator set with local peaks, plotted against the number of validators per bin.\nFigure 103496×2148 299 KB\nFigure 10. Force distribution f_2𝑓2 under a validator set with local peaks plotted against total ETH per bin.\nIt might be beneficial to use a discretized measure of validators’ active balances at the boundaries of 32 ETH and 2048 ETH, to avoid micromanagement of balances. For example, all validators between 32-33 ETH and between 2040-2048 ETH might receive the same f_2𝑓2, computed as the mean of the lowest and highest f_2𝑓2 among validators within the range. Discretization at other ranges can be considered for computational reasons, but would presumably only lead to more micromanagement of balances.\nSince CID introduces additional complexity, its benefits must be significant if it is to be adopted. It might then seem reasonable to first ship a pure AID if the overall strategy is to be pursued. The CID overlay can always be introduced if necessary at a later time.\n3.3 BID – balancing between AID and CID\nNaturally, a mixed measure of AID and CID, here referred to as BID, can be considered. This is an attempt to avoid problematic aspects of both variants when used in isolation. Both an AID f_2𝑓2 and a CID f_2𝑓2 are thus computed for the validator, and the final f_2𝑓2 is a weighing of the two. It would then seem natural to use the AID underlying the CID as the measure for the AID.\n4. Consolidation force scale f_y𝑓𝑦\nThe consolidation force scale f_y𝑓𝑦 determines how much the yield should change given a consolidation force between 0 and 1. It can also be used for scaling total yearly issuance, then denoted f_I𝑓𝐼. This is the final parameter of the three used for consolidation incentives. Recall from previously that in the attenuating mode, the full equation for collective incentives is\n\nf_1f_y,\n𝑓1𝑓𝑦,\nand for individual incentives it is\n\nf_1f_2f_y.\n𝑓1𝑓2𝑓𝑦.\nThe appropriate f_y𝑓𝑦 will depend on the currently offered yield, how much MEV that is available relative to the yield, perceived risk of being active as a staker, the composition of the staking set, etc. Factors such as the existence of MEV burn at the time of adoption can therefore influence the appropriate scale (see further discussions in Sections 4.2 and 4.4 below).\nToo weak consolidation will not sufficiently encourage consolidation. Too strong individual incentives will be interpreted (rightfully so) as Ethereum treating smaller validators unfairly. Strong collective (and individual) incentives can lead to frictions among consensus participants if the action of one party can have great influence on the yield of another party. For example, if there are no individual incentives, and some SSPs deconsolidate to lower their risk while significantly reducing yield for everyone, this might lead to particularly strong frictions.\nFour designs of f_y𝑓𝑦 are outlined in the following subsections. The right approach will depend on the shape of the reward curve, and a change in issuance policy could thus influence which approach that is the best.\n4.1 Fraction of the issuance yield\nOne approach is to scale by a fraction of the issuance yield\n\nf_y=k_1y_i,\n𝑓𝑦=𝑘1𝑦𝑖,\nor correspondingly by a fraction of the issuance\n\nf_I=k_1I.\n𝑓𝐼=𝑘1𝐼.\nSetting k_1=0.1𝑘1 =0.1 gives a 0.1% reduction in yield if the issuance yield is 1% and the force is 1.\nThe idea behind using a fraction of the issuance yield is that the equilibrium staking yield implies something about the risks of staking. If the equilibrium yield is high, a larger incentive might be required to encourage consolidation than if the yield is low. Stakers are thus charged some fraction of their income for reducing their risk (or occupying consensus spots). One downside is that issuance yield is not the only reward currently befalling stakers: MEV accrues to all stakers equally and this income will not be reflected in k_1y_i𝑘1𝑦𝑖. Another issue is that the equilibrium yield also compensates for other more general “costs” of staking (e.g., hardware) and those staking costs are much less affected by the activity rate of a validator.\n4.2 Fixed ETH/year\nAnother idea is to derive the scale as a fixed ETH/year through\n\nf_y=k_2/D,\n𝑓𝑦=𝑘2/𝐷,\nor correspondingly\n\nf_I=k_2.\n𝑓𝐼=𝑘2.\nSetting k_2=60\\,000𝑘2 =60 000 would give a 0.1% reduction in yield at 60M ETH staked if the force is 1.\nIf rewards are dominated by MEV (including priority fees) and the MEV remains roughly constant, then this way of scaling the incentives will work rather well. The staking yield still varies with deposit size because the fixed MEV must be distributed to all stake. The consolidation incentive will thus adapt with the staking yield without attaching too much weight to the less relevant issuance yield.\n4.3 Fixed yield, regardless of issuance and MEV\nA third option is to specify a fixed yield component, i.e., simply\n\nf_y=k_3,\n𝑓𝑦=𝑘3,\nor correspondingly\n\nf_I=k_3D.\n𝑓𝐼=𝑘3𝐷.\nSetting k_3= 0.001𝑘3 =0.001 would give a 0.1% reduction in yield if the force is 1.\nWith this design, the nominal incentive will remain the same, regardless of the level of the staking yield (if f_1𝑓1 and f_2𝑓2 stay the same). If risks associated with being active as a staker remain constant, such that an equilibrium shift in yield does not imply a change to such risks, then this approach can be reasonable. It could also be suitable if the stake supply curve is rather flat and remains fixed. In this case, any change in MEV would be offset by a shift in deposit size, such that the equilibrium yield also remains fixed. A probabilistic argument can also be made for the design under a shifting supply curve, with a reward curve rather similar to the present one. An equilibrium at a high deposit size is then likely associated with an increase in MEV (because the supply curve would otherwise need to fall improbably low). The suggestion is that the most probable staking yield across deposit size is more fixed than what the reward curve alone would indicate.\n4.4 Mixed f_y𝑓𝑦 – fraction of y_i𝑦𝑖 and fixed ETH/year\nThe force scale can be a mix of several of the previous suggestions, because they can complement each other. For example, the specification could be\n\nf_y=k_1y_i + k_2/D,\n𝑓𝑦=𝑘1𝑦𝑖+𝑘2/𝐷,\nor correspondingly\n\nf_I=k_1I + k_2.\n𝑓𝐼=𝑘1𝐼+𝑘2.\nWith the previously discussed settings and D = 60\\text{M}𝐷 =60M ETH, if an issuance yield of 1% is offered at this deposit size, the outcome would be\n\nf_y=0.1\\times0.01 \\;+\\; 60\\,000/60\\,000\\,000 = 0.002,\n𝑓𝑦=0.1×0.01+60000/60000000=0.002,\nthus 0.2%. The suggested mixed f_y𝑓𝑦 can be regarded as an attempt to relate the consolidation incentive to both issuance and MEV yield, and thus to the overall staking yield, which seems like a desirable objective. This can be expressed a little differently, as\n\nf_y=k_1(y_i + y'_v),\n𝑓𝑦=𝑘1(𝑦𝑖+𝑦′𝑣),\nwhere y'_v𝑦′𝑣 is k_2/D𝑘2/𝐷, but reframed as an estimate of the MEV yield. In this formulation, k_1𝑘1 regulates the strength of both y_i𝑦𝑖 and y'_v𝑦′𝑣—that together represent the staking yield. The MEV cannot currently be directly computed (“seen”) by the protocol, and would thus need to be updated outside of its domain. What could be considered is to have some agreed-upon way to compute y'_v𝑦′𝑣, or for that matter to leave it fixed at the current level and commit to only change it if MEV burn is instituted. As an example, say that the force scale is set to k_1 = 20\\%𝑘1 =20% of the staking yield. The equation then becomes 0.2(y_i + y'_v)0.2(𝑦𝑖 +𝑦′𝑣). As a guideline, 310k ETH of MEV was distributed via MEV boost during 2023. It fell to around 220k ETH in 2024. Relying only on MEV boost, a rough long-run estimate of y'_v𝑦′𝑣 at 34M ETH staked could thus be\n\ny'_v=\\frac{0.22\\times10^6}{34\\times10^6}\\approx0.0065.\n𝑦′𝑣=0.22×10634×106≈0.0065.\nThe estimate always pertains to yearly MEV and not MEV yield specifically. The deposit size D𝐷 is known by the protocol, just as issuance yield, and need not be estimated. The issuance yield under ideal consensus performance at 34M ETH staked is around 2.85%, and the maximum incentive would thus be\n\nf_y=0.2(0.0285 + 0.0065)=0.2\\times0.035=0.007,\n𝑓𝑦=0.2(0.0285+0.0065)=0.2×0.035=0.007,\ni.e., 0.7%. This is a rather strong incentive, albeit only activated under a completely deconsolidated validator set (f_1=1𝑓1 =1). Even if there is a desire to ultimately pursue such a strong incentive, it might still be reasonable to start out softer, at k_1\\leq 0.1𝑘1 ≤0.1.\n5. Attenuating, boosting, or issuance-neutral incentives\nThere are three possible modes for individual incentives: attenuating, boosting or issuance neutral (relative to the reward curve); and two modes for collective incentives: attenuating or boosting. Collective incentives can never be issuance neutral since the point of the mechanism is to collectively (for everyone) adjust rewards with consolidation level. This section reviews benefits and downsides of the possible modes and also highlights equivalences between them. The conclusion is that attenuating incentives are the most preferable, and that issuance-neutral incentives are the second best option (applicable to individual incentives). For clarity, Table 1 specifies the baseline equation for the different modes, assuming that f_1𝑓1 and f_2𝑓2 are computed as in Sections 2-3, with the issuance-neutral equation described in Section 5.2.1.\n\nColumn 1\nCollective\nIndividual\n\nAttenuating\n-\\,f_1f_y− 𝑓1𝑓𝑦\n-\\,f_1f_2f_y− 𝑓1𝑓2𝑓𝑦\n\nBoosting\n+\\,(1-f_1)f_y+ (1 −𝑓1)𝑓𝑦\n+\\,f_1(1-f_2)f_y+ 𝑓1(1 −𝑓2)𝑓𝑦\n\nIssuance neutral\n\n-\\,f_1(f_2-\\frac{\\sum_{i} f_{2(i)}s_i}{\\sum_{i} s_i})f_y− 𝑓1(𝑓2 −∑𝑖𝑓2(𝑖)𝑠𝑖∑𝑖𝑠𝑖)𝑓𝑦\n\nTable 1. Baseline equations for the different modes for collective and individual incentives, when the f_1𝑓1 and f_2𝑓2 are computed as described in Sections 2-3, and with issuance-neutral equation described in Section 5.2.1.\n5.1 Optimal mode for collective incentives\n5.1.1 Equivalence\nThe mode of the collective incentive is of less importance than the mode of the individual incentive, since the attenuating and boosting modes in the collective incentive can be made equivalent. Let a higher reward curve A be attenuated and a lower reward curve B be boosted, and set the difference between them as the force scale f_y𝑓𝑦 (ignoring complications regarding its computation). Further let y_c = f_1(V)f_y𝑦𝑐 =𝑓1(𝑉)𝑓𝑦 for A and y_c = (1-f_1(V))f_y𝑦𝑐 =(1 −𝑓1(𝑉))𝑓𝑦 for B under any V𝑉. Then, y_i-y_c𝑦𝑖 −𝑦𝑐 for A will equal y_i+y_c𝑦𝑖 +𝑦𝑐 for B:\n\nf_y + [y_c-f_1(V)f_y] = [y_c + (1-f_1(V))f_y],\n𝑓𝑦+[𝑦𝑐−𝑓1(𝑉)𝑓𝑦]=[𝑦𝑐+(1−𝑓1(𝑉))𝑓𝑦],\n\nf_y-f_1(V)f_y = f_y-f_1(V)f_y.\n𝑓𝑦−𝑓1(𝑉)𝑓𝑦=𝑓𝑦−𝑓1(𝑉)𝑓𝑦.\nThe equality is trivial to achieve, and the chosen mode will then have no influence on the actual incentives for consensus participants.\n5.1.2 Clarity\nHowever, there is still some relevance to the mode. With an attenuating mode, the reward curve comes to stipulate the maximum possible issuance—an important feature to have plainly encoded. With a boosting mode, the maximum possible issuance can still be deduced, but it requires adding f_y𝑓𝑦 to the reward curve. The reward curve then instead stipulates the minimum possible issuance under ideal performance when the staking set is deconsolidated—a somewhat less important feature. While the minimum possible yield is relevant both to stakers and as a general design criterion, the actual outcome is influenced also by luck in special duties assignments (e.g., block proposals), the actions of other consensus participants, etc. In either case, the minimum possible yield under ideal performance can still be calculated for attenuating incentives by deducting f_y𝑓𝑦.\n5.1.3 Impact of re-parameterization\nIf the collective incentive is re-parameterized without altering the reward curve, it will affect the maximum issuance under boosting incentives and the minimum issuance under attenuating incentives with ideal attestation. In this case, for boosting incentives, the two possible outcomes are an increased maximum issuance (very sensitive) and a decreased maximum issuance (less sensitive). For attenuating incentives, the two possible outcomes are an increased minimum issuance under ideal performance (less sensitive) and a decreased minimum issuance under ideal performance (sensitive). Politically, having to increase the maximum issuance (or alter the reward curve) to achieve stronger collective incentives would likely be the most problematic. However, a reduction to the minimum would also be politically sensitive. This indicates that boosting incentives make future changes more socially costly.\nAs an aside, note that any premeditated change to collective incentives is problematic. Developers should encode the utility-maximizing incentive from the beginning. If it is known or suspected that f_1𝑓1 or f_y𝑓𝑦 will under some outcomes be adjusted, for example, a decreased boost under good consolidation, then the collective incentive to consolidate does not actually exist in the first place (c.f. the ratchet effect in production strategy).\nAnother thing to consider is re-parameterization due to changes in y'_v𝑦′𝑣. If pursuing the parameterization in Section 4.4: f_y=k_1(y_i+y'_v)𝑓𝑦 =𝑘1(𝑦𝑖 +𝑦′𝑣), the maximum or minimum can change if y'_v𝑦′𝑣 changes. Once again, the sensitivity to increases and decreases must be considered, in particular the downside of having an increase in peak issuance any time y'_v𝑦′𝑣 increases.\n5.2 Issuance-neutral individual incentives\n5.2.1 Overview\nBefore comparing modes in individual incentives, the issuance-neutral mode will be presented. In the attenuating mode, f_2𝑓2 is in the range 0-1, with small/inactive validators close to 1 and big/active validators close to 0. The consolidation incentive y_c𝑦𝑐 derived from f_1f_2f_y𝑓1𝑓2𝑓𝑦 is then subtracted from the targeted issuance yield for each validator. The “issuance neutral” approach computes a global linear displacement f'_2 = f_2-d𝑓′2 =𝑓2 −𝑑 such that aggregate issuance is left unaffected, while preserving the yield differential between small (inactive) and large (active) validators. This ultimately boosts the yield for large/active validators through a negative f_2𝑓2 and attenuates it (but relatively less) for small validators, with a (smaller) positive f_2𝑓2. Specifically, the mean of all f'_2\\text{s}𝑓′2s when weighted by size becomes 0. Let s_i𝑠𝑖 be the size of validator i𝑖 and f_2(i)𝑓2(𝑖) its force distribution. The issuance-neutral displacement d𝑑 can then be computed from the equation\n\nd = \\frac{\\sum_{i} f_{2(i)}s_i}{\\sum_{i} s_i}.\n𝑑=∑𝑖𝑓2(𝑖)𝑠𝑖∑𝑖𝑠𝑖.\nGiven that d𝑑 applies equally to all validators, it can be understood as reflecting a collective incentive. In this context, it is however better described as an “anti-collective incentive”. Whatever aggregate shift in yield the attenuating or boosting individual incentive would produce, the variable d𝑑 restores—acting equally for everyone—leaving the aggregate unaffected by consolidation level. Observe that this implies that boosting and attenuating individual incentives also contain some collective incentives—a boosting individual incentive will increase the aggregate yield and an attenuating individual incentive will decrease it. The issuance-neutral approach removes any trace of collective incentives from the individual incentives.\nThe role of c𝑐 in the joint equation for consolidation incentives y_c = f_1f_y(c+f_2)𝑦𝑐 =𝑓1𝑓𝑦(𝑐 +𝑓2) can be compared with the role of the displacement d𝑑 imposing f_2-d𝑓2 −𝑑. The difference is that c𝑐 is added whereas d𝑑 is subtracted, and thus c \\equiv -d𝑐 ≡ −𝑑. The collective part of the attenuating or boosting individual incentive is thus made explicit. It follows that if Ethereum uses both collective and individual incentives, they ought to be analyzed jointly. With this in mind, note that the boosting individual incentive in Table 1 from the beginning of the section ends up f_1f_y𝑓1𝑓𝑦 higher than then attenuating counterpart. They are thus separated by a collective component, and can be made equal through a shift f_1f_y𝑓1𝑓𝑦.\nNote that c𝑐 is fixed beforehand and d𝑑 is computed from—and varies with—f_2𝑓2. The strength of c𝑐 can be attuned to the protocol’s needs, but an adjusted strength can also be used for d𝑑. This adjustment can be stipulated as d' = dk_d𝑑′ =𝑑𝑘𝑑. With 0<k_d<10 <𝑘𝑑 <1, d'𝑑′ will see the collective part of the individual incentive positioned in between the issuance neutral and attenuating mode. Finally, it can be mentioned that to the individual validator, the aggregate is naturally of less direct importance, and the direct change to its f_2𝑓2 is what matters—at least before any associated shifts in the equilibrium take place.\n5.2.2 Rationale\nTwo benefits of issuance-neutral individual incentives can be identified, which are more relevant when combined with lower or no collective incentives. Firstly, protocol issuance will end up closer to the issuance level stipulated by the reward curve (regardless of consolidation level), which arguably improves design clarity. Secondly, one suggested approach to Ethereum’s issuance policy is to ensure that diligent 32-ETH solo stakers always receive positive regular rewards. At the same time, it is desirable to set the reward curve close to 0 at high deposit ratios. Issuance-neutral individual incentives allow Ethereum to compress the yield of small validators under low consolidation closer to the yield offered under good consolidation, such that the reward curve can be stipulated closer to 0 while still ensuring positive regular rewards. The f_1𝑓1 is highest under low consolidation. At this point, there are more small validators than big, and the small validators rewards will only need to be reduced slightly to preserve neutrality (the few large validators’ rewards will at the same time be raised more substantially).\n5.2.3 Simulations\nTo illustrate the compressed yield differential from issuance-neutral individual incentives for smaller 32-ETH validators, validator sets with smoothly varying Zipfianess were generated. A detailed description of the method is presented in Appendix C. Each validator set was generated by feeding the equally spaced uniform distribution u𝑢 in the range [0, 1][0,1] into the equation\n\n\\Bigl(\ns_{\\text{min}}^\\alpha+u\\bigl(s_{\\text{max}}^\\alpha - s_{\\text{min}}^\\alpha\\bigr)\n\\Bigr)^{\\tfrac{1}{\\alpha}}.\n(𝑠𝛼min+𝑢(𝑠𝛼max−𝑠𝛼min))1𝛼.\nThe composition of each validator set is in this equation governed by the exponent \\alpha𝛼, where \\alpha=-1𝛼 = −1 leads to a Zipfian distribution of validators. Appendix C.1 illustrates the effect of \\alpha𝛼. The integral of the equation relates validator size V𝑉 to deposit size D𝐷, and the closed-form solution can therefore be used to approximate the number of validators given a specific D𝐷 and \\alpha𝛼 as:\n\nV \\approx \\frac{D(\\alpha+1)\\bigl(s_{\\text{max}}^\\alpha - s_{\\text{min}}^\\alpha\\bigr)}{\\alpha\\bigl(\ns_{\\text{max}}^{\\alpha+1} - s_{\\text{min}}^{\\alpha+1}\n\\bigr)}.\n𝑉≈𝐷(𝛼+1)(𝑠𝛼max−𝑠𝛼min)𝛼(𝑠𝛼+1max−𝑠𝛼+1min).\nAppendix C.2 presents the derivation. Figure 11 illustrates the effect of an issuance-neutral policy on 32-ETH validators at 80M ETH staked. It is created for \\alpha𝛼 between -6−6 and 22, at each point calculating the approximate V𝑉 from the previous equation, generating the validator set at the specific \\alpha𝛼, and computing the issuance-neutral displacement d𝑑. The linear f_1𝑓1 that reaches 0 at (V_{\\text{min}}+V_Z)/2(𝑉min +𝑉𝑍)/2 was used, and the log scaled f_2𝑓2. The new issuance-neutral force f'𝑓′ for a validator with displaced force f'_2𝑓′2 then becomes f'=f_1f'_2𝑓′ =𝑓1𝑓′2.\nFigure 113058×1948 245 KB\nFigure 11. Simulation of an issuance-neutral force aggregation for 32-ETH validators. The attenuating force can have f_2=1𝑓2 =1 for small validators at any consolidation level, and the maximum f𝑓 is thus also 1 (thin black line). The issuance-neutral f'_2𝑓′2 (dashed blue line) only approaches 1 when almost no validators are of the minimum size, and after multiplication with f_1𝑓1 (dotted blue line), the aggregated f'𝑓′ (black line) peaks at around 0.1.\nAs illustrated by the figure, f'_2𝑓′2 for 32-ETH validators will only approach 1 under consolidated validator sets. Larger validators then hold a clear majority of all ETH, and a small gain for them must be offset by a large reduction for small validators to preserve the yield differential under an issuance-neutral policy. But f_1𝑓1 should at that point be set close to zero since the validator set already is consolidated, and a large yield differential would be perceived as unfair. The issuance-neutral aggregated force f'𝑓′ for 32-ETH validators therefore never exceeds 0.12. This allows the reward curve to be pushed much closer to zero while ensuring positive regular rewards than when using an attenuating policy (where f𝑓 will approach 1 under low consolidation).\n5.3 Optimal mode for individual incentives\n5.3.1 Aggregate, individual, and equilibrium outcomes of different modes\nIndividual incentives should have a high yield differential when the validator set is deconsolidated and this is instituted by letting f_1𝑓1 approach 1. A key problem under boosting individual incentives is therefore the rise in aggregate yield (further discussed in Section 5.2.1): deconsolidation is collectively rewarded. Note that this is opposite to how boosting collective incentives work (as evident from reviewing the equations in Table 1), where consolidation is rewarded instead (f_1𝑓1 must then approach 1 if the validator set is consolidated). However, just as with the issuance-neutral incentive, the interaction of f_1𝑓1 and f_2𝑓2 must be accounted for. Define the average f_2𝑓2 across the validator set, weighed by stake, as \\bar{f_2}¯𝑓2 (this is in fact the same measure as previously computed for d𝑑). The average force per staked ETH \\bar{f}¯𝑓 by which issuance will be collectively boosted (after scaling by f_y𝑓𝑦) is shown in Figure 12, using the same validator distributions and shapes of f_1𝑓1 and f_2𝑓2 as previously for Figure 11. Since d𝑑 offsets a 32-ETH validator with an f_2𝑓2 of 0 (Figure 11) and the boosting incentive relies on 1-f_21 −𝑓2 (Figure 12), Figures 11-12 appears identical, even though they illustrate two different concepts. The fall in 1-\\bar{f_2}1 −¯𝑓2 as consolidation level decreases moderates the actual collective outcome of the boosting incentive, with issuance even falling beyond 1M validators. This highlights that even with a boosting individual incentive, issuance may not rise substantially.\nFigure 123058×1948 243 KB\nFigure 12. Analyzing collective effects of individual boosting incentives. The force per staked ETH peaks at around 0.12. This point, scaled by f_I𝑓𝐼, gives the maximum increase in issuance possible for the linear f_1𝑓1 and log-scaled f_2𝑓2 under the distribution of Appendix C.\nFigure 13 instead shows the average force per staked ETH \\bar{f}¯𝑓 by which issuance will be collectively attenuated. Both f_1𝑓1 and \\bar{f_2}¯𝑓2 rise as consolidation falls, which is reflected in \\bar{f}¯𝑓. The implication is that the “collective” portion of the individual attenuating incentive becomes much stronger than its boosting counterpart.\nFigure 133058×1948 265 KB\nFigure 13. Analyzing collective effects of individual boosting incentives. The force per staked ETH approaches 1 as D𝐷 approaches the maximum value, leading the issuance to be reduced by at most f_I𝑓𝐼.\nStakers can potentially actively deconsolidate to directly profit under boosting individual incentives. A staker holding many big validators who divides one of them into several smaller validators will see all remaining validators become more profitable. If the local derivative of the f_1𝑓1 curve is large, and no attenuating collective incentives are in place, the gain among the remaining validators can come to offset the loss from the deconsolidated validator. For these reasons, if there are no collective incentives, certain implementations of boosting individual incentives would be very problematic. When there are collective incentives, their magnitude must be accounted for—recall from Section 5.2.1 that boosting individual incentives gives f_1f_y𝑓1𝑓𝑦 higher yield than attenuating individual incentives for all stakers (this is also evident by the fact that the black lines in Figures 12-13 sums to be equal to the dotted blue line). The general recommendation is to not pursue boosting individual incentives unless care is taken to never incentivize deconsolidation.\nHow about issuance-neutral individual incentives? It can be noted that since consolidation level will not affect issuance, the loss for a staker who deconsolidates a big validator will be precisely offset by an aggregate gain for all other validators. This alleviates concerns about a collective gain under deconsolidation, but a deconsolidating staker could still benefit. As f_1𝑓1 increases, the yield will increase for big validators and fall for small validators, and a staker with many big validators may theoretically gain from deconsolidation—if the local derivative of f_1𝑓1 is large. These concerns are however not comparable to those present for the boosting mode, and the issuance-neutral mode should not be ruled out given that it also brings benefits. Edge cases must however still be examined, but by adopting c>0𝑐 >0 or changing d𝑑 to d'𝑑′ with 0<k_d<10 <𝑘𝑑 <1 (Sec. 5.2.1), such issues can be overcome.\nNote that the equilibrium effect after stakers adjust their positions due to the change in yield will be smaller than the direct effect. An increase in f_1𝑓1 from the initial deconsolidation will incentivize other stakers to consolidate, pushing f_1𝑓1 back down. The equilibrium outcome can be a theoretical concern even in the attenuating mode. In this mode, a staker with many big validators can deconsolidate to push down the yield for small validators in the hope that some stop staking, leading to an increase in staking yield for the remaining big validators. While rather esoteric, the equilibrium outcome will at least be much more similar for the different modes than the direct outcome—the yield differential between big and small validators is kept fixed regardless of mode under the same f_1𝑓1. However, the equilibrium outcome is more speculative, can be affected by the collective component in the individual incentive, and takes effect more slowly.\n5.3.2 Collective concerns under various modes\nThe issues concerning collective incentives discussed in Section 5.1 apply also to individual incentives. This is due in part to the traces of collective incentives also present in individual incentives outlined in Section 5.2.1. Boosting individual incentives will also increase the maximum possible issuance. In particular, it is unfortunate that attenuating individual incentives will specifically push down the issuance of 32-ETH validators. The strong point of issuance-neutral incentives is that they do not increase the maximum possible issuance, while at the same time not worsening the outcome for 32-ETH validators too much in the worst-case scenario. This “compression” of the yield differential for 32-ETH validators was presented in Section 5.2 and illustrated in Figure 11.\n5.3.3 Implications on discouragement attacks\nFinally consider discouragement attacks with the additional twist of only targeting validators of a specific size. If small validators are targeted, some of them will stop staking and consolidation will improve. An attacker can thus gain from the collective consolidation incentive. An attenuating individual incentive will however lead to a direct increase in yield specifically for small validators upon consolidation, mitigating some concerns. Note further that an attenuating individual incentive makes it relatively more profitable for small validators to stage this attack (in terms of the direct effect), and a boosting incentive makes it relatively more profitable for large validators. If large validators are targeted, the collective consolidation incentive brings down the yield, so this attack is therefore only a concern under boosting individual incentives.\n6. Concluding specification\nA systematic framework for consolidation incentives in Orbit/Vorbit SSF has been presented. Benefits and drawbacks of various settings for the three consolidation forces f_1𝑓1, f_2𝑓2 and f_y𝑓𝑦 were provided, and their optimal mode reviewed. Based on that analysis, the most beneficial settings will now be suggested, resulting in an overarching specification for how to incentivize consolidation.\n§1. The post is centered around the attenuating mode with the main equation\n\ny_c = f_1f_y(c+f_2). \n𝑦𝑐=𝑓1𝑓𝑦(𝑐+𝑓2).\nThe shape of the consolidation force is determined by f_1𝑓1, the scale by f_y𝑓𝑦, the distribution between validators by f_2𝑓2 (thus the f_2𝑓2 is unique to each validator size) and the relative strength of collective incentives by c𝑐. The resulting consolidation incentive y_c𝑦𝑐 differs with validator size and is used to update the target issuance yield for each validator:\n\ny'_i=y_i-y_c. \n𝑦′𝑖=𝑦𝑖−𝑦𝑐.\n§2. While it is not strictly necessary for f_1𝑓1 and f_y𝑓𝑦 to be the same for individual and any collective incentives, it is a realistic design goal to pursue.\n§3. Let the shape of f_1𝑓1 be based on the mixed equation, parameterized as outlined in Section 2.2 and captured in Figure 3. This is a versatile equation that can be adjusted to fit requirements as the architecture nears adoption.\n§4. Use a fixed schedule for f_1𝑓1 with no dynamic time component, for simplicity (Section 2.3).\n§5. Let f_2𝑓2 be a pure AID as a starting point. If relying on a Vorbit design, or generally any design with a less linear relationship between validator size and activity rate, use the mixed\n\nf_2 = w\\frac{a_{\\text{max}} - a_v}{a_{\\text{max}} - a_{\\text{min}}} + (1-w)\\frac{ s_{\\text{min}} ( s_{\\text{max}} - s_v ) }{ s_v ( s_{\\text{max}} - s_{\\text{min}} ) }, \n𝑓2=𝑤𝑎max−𝑎𝑣𝑎max−𝑎min+(1−𝑤)𝑠min(𝑠max−𝑠𝑣)𝑠𝑣(𝑠max−𝑠min),\npresented as the yellow curve in Figure 4. Setting w=0.5𝑤 =0.5 seems like a natural default choice (an even balance between focusing on active stake and occupied validator spots), but w>0.5𝑤 >0.5 is also viable and arguably more fair. Even if the direction is to focus on active stake out of fairness concerns, w=0.8𝑤 =0.8 should be sufficient to ensure that stakers opt for 2048-ETH validators over 1024-ETH validators when Orbit is thresholded at 1024, if they have the capital to do so. If the mixed measure is unnecessary, for example in Orbit SSF thresholded at 2048, it is also viable to use the log-scaled\n\nf_2 = \\frac{\\log_2\\left(s_{\\text{max}}/s_v \\right)}{\\log_2\\left( s_{\\text{max}}/s_{\\text{min}} \\right)}, \n𝑓2=log2⁡(𝑠max/𝑠𝑣)log2⁡(𝑠max/𝑠min),\npresented as the blue curve in Figure 4. Two log-scaled f_2\\text{s}𝑓2s computed both for s𝑠 and a𝑎 could also be averaged/weighed together under Vorbit SSF.\n§6. The primary option is to let f_y𝑓𝑦 be defined according to the mixed equation f_y=k_1(y_i + y'_v)𝑓𝑦 =𝑘1(𝑦𝑖 +𝑦′𝑣) with a long-run estimate in y'_v𝑦′𝑣 that is to be adjusted only after a substantial shift in MEV (e.g., after implementing MEV burn). It is prefer","tokens":15000,"squid":"spider-04","role":"Research Spider","at":1791346026444,"hash":"6bbc8077f2e17b1bad2c742827bab8403e82138f"}
{"url":"https://ethereum.org/whitepaper/","domain":"ethereum.org","title":"Ethereum Whitepaper | ethereum.org","text":"Before you readLooking to understand Ethereum?This whitepaper was published in 2014, before Ethereum launched. After 10+ years of development, major upgrades, and ecosystem growth, the original whitepaper no longer reflects what Ethereum is today.Learn about Ethereum todayDownload original PDF (2014)What's changed since 2014?Ethereum moved from proof-of-work to proof-of-stake (The Merge, 2022)Layer 2 scaling solutions now process millions of transactionsDeFi, NFTs, and DAOs emerged as major use casesSmart contract standards (ERC-20, ERC-721) became industry foundations\nWhile several years old, we maintain the original paper below because it continues to serve as a useful reference and an accurate representation of Ethereum and its vision.\nA Next-Generation Smart Contract and Decentralized Application Platform\nSatoshi Nakamoto's development of Bitcoin in 2009 has often been hailed as a radical development in money and currency, being the first example of a digital asset which simultaneously has no backing or \"intrinsic value (opens in a new tab)\" and no centralized issuer or controller. However, another, arguably more important, part of the Bitcoin experiment is the underlying blockchain technology as a tool of distributed consensus, and attention is rapidly starting to shift to this other aspect of Bitcoin. Commonly cited alternative applications of blockchain technology include using on-blockchain digital assets to represent custom currencies and financial instruments (\"colored coins (opens in a new tab)\"), the ownership of an underlying physical device (\"smart property (opens in a new tab)\"), non-fungible assets such as domain names (\"Namecoin (opens in a new tab)\"), as well as more complex applications involving having digital assets being directly controlled by a piece of code implementing arbitrary rules (\"smart contracts (opens in a new tab)\") or even blockchain-based \"decentralized autonomous organizations (opens in a new tab)\" (DAOs). What Ethereum intends to provide is a blockchain with a built-in fully fledged Turing-complete programming language that can be used to create \"contracts\" that can be used to encode arbitrary state transition functions, allowing users to create any of the systems described above, as well as many others that we have not yet imagined, simply by writing up the logic in a few lines of code.\nIntroduction to Bitcoin and Existing Concepts\nHistory\nThe concept of decentralized digital currency, as well as alternative applications like property registries, has been around for decades. The anonymous e-cash protocols of the 1980s and the 1990s, mostly reliant on a cryptographic primitive known as Chaumian blinding, provided a currency with a high degree of privacy, but the protocols largely failed to gain traction because of their reliance on a centralized intermediary. In 1998, Wei Dai's b-money (opens in a new tab) became the first proposal to introduce the idea of creating money through solving computational puzzles as well as decentralized consensus, but the proposal was scant on details as to how decentralized consensus could actually be implemented. In 2005, Hal Finney introduced a concept of \"reusable proofs of work (opens in a new tab)\", a system which uses ideas from b-money together with Adam Back's computationally difficult Hashcash puzzles to create a concept for a cryptocurrency, but once again fell short of the ideal by relying on trusted computing as a backend. In 2009, a decentralized currency was for the first time implemented in practice by Satoshi Nakamoto, combining established primitives for managing ownership through public key cryptography with a consensus algorithm for keeping track of who owns coins, known as \"proof-of-work\".\nThe mechanism behind proof-of-work was a breakthrough in the space because it simultaneously solved two problems. First, it provided a simple and moderately effective consensus algorithm, allowing nodes in the network to collectively agree on a set of canonical updates to the state of the Bitcoin ledger. Second, it provided a mechanism for allowing free entry into the consensus process, solving the political problem of deciding who gets to influence the consensus, while simultaneously preventing sybil attacks. It does this by substituting a formal barrier to participation, such as the requirement to be registered as a unique entity on a particular list, with an economic barrier - the weight of a single node in the consensus voting process is directly proportional to the computing power that the node brings. Since then, an alternative approach has been proposed called proof-of-stake, calculating the weight of a node as being proportional to its currency holdings and not computational resources; the discussion of the relative merits of the two approaches is beyond the scope of this paper but it should be noted that both approaches can be used to serve as the backbone of a cryptocurrency.\nBitcoin As A State Transition System\n\nFrom a technical standpoint, the ledger of a cryptocurrency such as Bitcoin can be thought of as a state transition system, where there is a \"state\" consisting of the ownership status of all existing bitcoins and a \"state transition function\" that takes a state and a transaction and outputs a new state which is the result. In a standard banking system, for example, the state is a balance sheet, a transaction is a request to move $X from A to B, and the state transition function reduces the value in A's account by $X and increases the value in B's account by $X. If A's account has less than $X in the first place, the state transition function returns an error. Hence, one can formally define:\nAPPLY(S,TX) -> S' or ERROR\n\nIn the banking system defined above:\nAPPLY({ Alice: $50, Bob: $50 },\"send $20 from Alice to Bob\") = { Alice: $30, Bob: $70 }\n\nBut:\nAPPLY({ Alice: $50, Bob: $50 },\"send $70 from Alice to Bob\") = ERROR\n\nThe \"state\" in Bitcoin is the collection of all coins (technically, \"unspent transaction outputs\" or UTXO) that have been minted and not yet spent, with each UTXO having a denomination and an owner (defined by a 20-byte address which is essentially a cryptographic public keyfn1). A transaction contains one or more inputs, with each input containing a reference to an existing UTXO and a cryptographic signature produced by the private key associated with the owner's address, and one or more outputs, with each output containing a new UTXO to be added to the state.\nThe state transition function APPLY(S,TX) -> S' can be defined roughly as follows:\nFor each input in TX:If the referenced UTXO is not in S, return an error.If the provided signature does not match the owner of the UTXO, return an error.If the sum of the denominations of all input UTXO is less than the sum of the denominations of all output UTXO, return an error.Return S with all input UTXO removed and all output UTXO added.\nThe first half of the first step prevents transaction senders from spending coins that do not exist, the second half of the first step prevents transaction senders from spending other people's coins, and the second step enforces conservation of value. In order to use this for payment, the protocol is as follows. Suppose Alice wants to send 11.7 BTC to Bob. First, Alice will look for a set of available UTXO that she owns that totals up to at least 11.7 BTC. Realistically, Alice will not be able to get exactly 11.7 BTC; say that the smallest she can get is 6+4+2=12. She then creates a transaction with those three inputs and two outputs. The first output will be 11.7 BTC with Bob's address as its owner, and the second output will be the remaining 0.3 BTC \"change\", with the owner being Alice herself.\nMining\n\nIf we had access to a trustworthy centralized service, this system would be trivial to implement; it could simply be coded exactly as described, using a centralized server's hard drive to keep track of the state. However, with Bitcoin we are trying to build a decentralized currency system, so we will need to combine the state transaction system with a consensus system in order to ensure that everyone agrees on the order of transactions. Bitcoin's decentralized consensus process requires nodes in the network to continuously attempt to produce packages of transactions called \"blocks\". The network is intended to produce roughly one block every ten minutes, with each block containing a timestamp, a nonce, a reference to (i.e., hash of) the previous block and a list of all of the transactions that have taken place since the previous block. Over time, this creates a persistent, ever-growing, \"blockchain\" that constantly updates to represent the latest state of the Bitcoin ledger.\nThe algorithm for checking if a block is valid, expressed in this paradigm, is as follows:\n\nCheck if the previous block referenced by the block exists and is valid.\nCheck that the timestamp of the block is greater than that of the previous blockfn2 and less than 2 hours into the future\nCheck that the proof-of-work on the block is valid.\nLet S[0] be the state at the end of the previous block.\nSuppose TX is the block's transaction list with n transactions. For all i in 0...n-1, set S[i+1] = APPLY(S[i],TX[i]) If any application returns an error, exit and return false.\nReturn true, and register S[n] as the state at the end of this block.\n\nEssentially, each transaction in the block must provide a valid state transition from what was the canonical state before the transaction was executed to some new state. Note that the state is not encoded in the block in any way; it is purely an abstraction to be remembered by the validating node and can only be (securely) computed for any block by starting from the genesis state and sequentially applying every transaction in every block. Additionally, note that the order in which the miner includes transactions into the block matters; if there are two transactions A and B in a block such that B spends a UTXO created by A, then the block will be valid if A comes before B but not otherwise.\nThe one validity condition present in the above list that is not found in other systems is the requirement for \"proof-of-work\". The precise condition is that the double-SHA256 hash of every block, treated as a 256-bit number, must be less than a dynamically adjusted target, which as of the time of this writing is approximately 2187. The purpose of this is to make block creation computationally \"hard\", thereby preventing sybil attackers from remaking the entire blockchain in their favor. Because SHA256 is designed to be a completely unpredictable pseudo-random function, the only way to create a valid block is simply trial and error, repeatedly incrementing the nonce and seeing if the new hash matches.\nAt the current target of ~2187, the network must make an average of ~269 tries before a valid block is found; in general, the target is recalibrated by the network every 2016 blocks so that on average a new block is produced by some node in the network every ten minutes. In order to compensate miners for this computational work, the miner of every block is entitled to include a transaction giving themselves 25 BTC out of nowhere. Additionally, if any transaction has a higher total denomination in its inputs than in its outputs, the difference also goes to the miner as a \"transaction fee\". Incidentally, this is also the only mechanism by which BTC are issued; the genesis state contained no coins at all.\nIn order to better understand the purpose of mining, let us examine what happens in the event of a malicious attacker. Since Bitcoin's underlying cryptography is known to be secure, the attacker will target the one part of the Bitcoin system that is not protected by cryptography directly: the order of transactions. The attacker's strategy is simple:\n\nSend 100 BTC to a merchant in exchange for some product (preferably a rapid-delivery digital good)\nWait for the delivery of the product\nProduce another transaction sending the same 100 BTC to himself\nTry to convince the network that his transaction to himself was the one that came first.\n\nOnce step (1) has taken place, after a few minutes some miner will include the transaction in a block, say block number 270000. After about one hour, five more blocks will have been added to the chain after that block, with each of those blocks indirectly pointing to the transaction and thus \"confirming\" it. At this point, the merchant will accept the payment as finalized and deliver the product; since we are assuming this is a digital good, delivery is instant. Now, the attacker creates another transaction sending the 100 BTC to himself. If the attacker simply releases it into the wild, the transaction will not be processed; miners will attempt to run APPLY(S,TX) and notice that TX consumes a UTXO which is no longer in the state. So instead, the attacker creates a \"fork\" of the blockchain, starting by mining another version of block 270000 pointing to the same block 269999 as a parent but with the new transaction in place of the old one. Because the block data is different, this requires redoing the proof-of-work. Furthermore, the attacker's new version of block 270000 has a different hash, so the original blocks 270001 to 270005 do not \"point\" to it; thus, the original chain and the attacker's new chain are completely separate. The rule is that in a fork the longest blockchain is taken to be the truth, and so legitimate miners will work on the 270005 chain while the attacker alone is working on the 270000 chain. In order for the attacker to make his blockchain the longest, he would need to have more computational power than the rest of the network combined in order to catch up (hence, \"51% attack\").\nMerkle Trees\n\nLeft: it suffices to present only a small number of nodes in a Merkle tree to give a proof of the validity of a branch.\nRight: any attempt to change any part of the Merkle tree will eventually lead to an inconsistency somewhere up the chain.\nAn important scalability feature of Bitcoin is that the block is stored in a multi-level data structure. The \"hash\" of a block is actually only the hash of the block header, a roughly 200-byte piece of data that contains the timestamp, nonce, previous block hash and the root hash of a data structure called the Merkle tree storing all transactions in the block. A Merkle tree is a type of binary tree, composed of a set of nodes with a large number of leaf nodes at the bottom of the tree containing the underlying data, a set of intermediate nodes where each node is the hash of its two children, and finally a single root node, also formed from the hash of its two children, representing the \"top\" of the tree. The purpose of the Merkle tree is to allow the data in a block to be delivered piecemeal: a node can download only the header of a block from one source, the small part of the tree relevant to them from another source, and still be assured that all of the data is correct. The reason why this works is that hashes propagate upward: if a malicious user attempts to swap in a fake transaction into the bottom of a Merkle tree, this change will cause a change in the node above, and then a change in the node above that, finally changing the root of the tree and therefore the hash of the block, causing the protocol to register it as a completely different block (almost certainly with an invalid proof-of-work).\nThe Merkle tree protocol is arguably essential to long-term sustainability. A \"full node\" in the Bitcoin network, one that stores and processes the entirety of every block, takes up about 15 GB of disk space in the Bitcoin network as of April 2014, and is growing by over a gigabyte per month. Currently, this is viable for some desktop computers and not phones, and later on in the future only businesses and hobbyists will be able to participate. A protocol known as \"simplified payment verification\" (SPV) allows for another class of nodes to exist, called \"light nodes\", which download the block headers, verify the proof-of-work on the block headers, and then download only the \"branches\" associated with transactions that are relevant to them. This allows light nodes to determine with a strong guarantee of security what the status of any Bitcoin transaction, and their current balance, is while downloading only a very small portion of the entire blockchain.\nAlternative Blockchain Applications\nThe idea of taking the underlying blockchain idea and applying it to other concepts also has a long history. In 2005, Nick Szabo came out with the concept of \"secure property titles with owner authority (opens in a new tab)\", a document describing how \"new advances in replicated database technology\" will allow for a blockchain-based system for storing a registry of who owns what land, creating an elaborate framework including concepts such as homesteading, adverse possession and Georgian land tax. However, there was unfortunately no effective replicated database system available at the time, and so the protocol was never implemented in practice. After 2009, however, once Bitcoin's decentralized consensus was developed a number of alternative applications rapidly began to emerge.\n\nNamecoin - created in 2010, Namecoin (opens in a new tab) is best described as a decentralized name registration database. In decentralized protocols like Tor, Bitcoin and BitMessage, there needs to be some way of identifying accounts so that other people can interact with them, but in all existing solutions the only kind of identifier available is a pseudo-random hash like 1LW79wp5ZBqaHW1jL5TCiBCrhQYtHagUWy. Ideally, one would like to be able to have an account with a name like \"george\". However, the problem is that if one person can create an account named \"george\" then someone else can use the same process to register \"george\" for themselves as well and impersonate them. The only solution is a first-to-file paradigm, where the first registerer succeeds and the second fails - a problem perfectly suited for the Bitcoin consensus protocol. Namecoin is the oldest, and most successful, implementation of a name registration system using such an idea.\nColored coins - the purpose of colored coins (opens in a new tab) is to serve as a protocol to allow people to create their own digital currencies - or, in the important trivial case of a currency with one unit, digital tokens, on the Bitcoin blockchain. In the colored coins protocol, one \"issues\" a new currency by publicly assigning a color to a specific Bitcoin UTXO, and the protocol recursively defines the color of other UTXO to be the same as the color of the inputs that the transaction creating them spent (some special rules apply in the case of mixed-color inputs). This allows users to maintain wallets containing only UTXO of a specific color and send them around much like regular bitcoins, backtracking through the blockchain to determine the color of any UTXO that they receive.\nMetacoins - the idea behind a metacoin is to have a protocol that lives on top of Bitcoin, using Bitcoin transactions to store metacoin transactions but having a different state transition function, APPLY'. Because the metacoin protocol cannot prevent invalid metacoin transactions from appearing in the Bitcoin blockchain, a rule is added that if APPLY'(S,TX) returns an error, the protocol defaults to APPLY'(S,TX) = S. This provides an easy mechanism for creating an arbitrary cryptocurrency protocol, potentially with advanced features that cannot be implemented inside of Bitcoin itself, but with a very low development cost since the complexities of mining and networking are already handled by the Bitcoin protocol. Metacoins have been used to implement some classes of financial contracts, name registration and decentralized exchange.\n\nThus, in general, there are two approaches toward building a consensus protocol: building an independent network, and building a protocol on top of Bitcoin. The former approach, while reasonably successful in the case of applications like Namecoin, is difficult to implement; each individual implementation needs to bootstrap an independent blockchain, as well as building and testing all of the necessary state transition and networking code. Additionally, we predict that the set of applications for decentralized consensus technology will follow a power law distribution where the vast majority of applications would be too small to warrant their own blockchain, and we note that there exist large classes of decentralized applications, particularly decentralized autonomous organizations, that need to interact with each other.\nThe Bitcoin-based approach, on the other hand, has the flaw that it does not inherit the simplified payment verification features of Bitcoin. SPV works for Bitcoin because it can use blockchain depth as a proxy for validity; at some point, once the ancestors of a transaction go far enough back, it is safe to say that they were legitimately part of the state. Blockchain-based meta-protocols, on the other hand, cannot force the blockchain not to include transactions that are not valid within the context of their own protocols. Hence, a fully secure SPV meta-protocol implementation would need to backward scan all the way to the beginning of the Bitcoin blockchain to determine whether or not certain transactions are valid. Currently, all \"light\" implementations of Bitcoin-based meta-protocols rely on a trusted server to provide the data, arguably a highly suboptimal result especially when one of the primary purposes of a cryptocurrency is to eliminate the need for trust.\nScripting\nEven without any extensions, the Bitcoin protocol actually does facilitate a weak version of a concept of \"smart contracts\". UTXO in Bitcoin can be owned not just by a public key, but also by a more complicated script expressed in a simple stack-based programming language. In this paradigm, a transaction spending that UTXO must provide data that satisfies the script. Indeed, even the basic public key ownership mechanism is implemented via a script: the script takes an elliptic curve signature as input, verifies it against the transaction and the address that owns the UTXO, and returns 1 if the verification is successful and 0 otherwise. Other, more complicated, scripts exist for various additional use cases. For example, one can construct a script that requires signatures from two out of a given three private keys to validate (\"multisig\"), a setup useful for corporate accounts, secure savings accounts and some merchant escrow situations. Scripts can also be used to pay bounties for solutions to computational problems, and one can even construct a script that says something like \"this Bitcoin UTXO is yours if you can provide an SPV proof that you sent a Dogecoin transaction of this denomination to me\", essentially allowing decentralized cross-cryptocurrency exchange.\nHowever, the scripting language as implemented in Bitcoin has several important limitations:\n\nLack of Turing-completeness - that is to say, while there is a large subset of computation that the Bitcoin scripting language supports, it does not nearly support everything. The main category that is missing is loops. This is done to avoid infinite loops during transaction verification; theoretically it is a surmountable obstacle for script programmers, since any loop can be simulated by simply repeating the underlying code many times with an if statement, but it does lead to scripts that are very space-inefficient. For example, implementing an alternative elliptic curve signature algorithm would likely require 256 repeated multiplication rounds all individually included in the code.\nValue-blindness - there is no way for a UTXO script to provide fine-grained control over the amount that can be withdrawn. For example, one powerful use case of an oracle contract would be a hedging contract, where A and B put in $1000 worth of BTC and after 30 days the script sends $1000 worth of BTC to A and the rest to B. This would require an oracle to determine the value of 1 BTC in USD, but even then it is a massive improvement in terms of trust and infrastructure requirement over the fully centralized solutions that are available now. However, because UTXO are all-or-nothing, the only way to achieve this is through the very inefficient hack of having many UTXO of varying denominations (e.g., one UTXO of 2k for every k up to 30) and having the oracle pick which UTXO to send to A and which to B.\nLack of state - UTXO can either be spent or unspent; there is no opportunity for multi-stage contracts or scripts which keep any other internal state beyond that. This makes it hard to make multi-stage options contracts, decentralized exchange offers or two-stage cryptographic commitment protocols (necessary for secure computational bounties). It also means that UTXO can only be used to build simple, one-off contracts and not more complex \"stateful\" contracts such as decentralized organizations, and makes meta-protocols difficult to implement. Binary state combined with value-blindness also mean that another important application, withdrawal limits, is impossible.\nBlockchain-blindness - UTXO are blind to blockchain data such as the nonce, the timestamp and previous block hash. This severely limits applications in gambling, and several other categories, by depriving the scripting language of a potentially valuable source of randomness.\n\nThus, we see three approaches to building advanced applications on top of cryptocurrency: building a new blockchain, using scripting on top of Bitcoin, and building a meta-protocol on top of Bitcoin. Building a new blockchain allows for unlimited freedom in building a feature set, but at the cost of development time, bootstrapping effort and security. Using scripting is easy to implement and standardize, but is very limited in its capabilities, and meta-protocols, while easy, suffer from faults in scalability. With Ethereum, we intend to build an alternative framework that provides even larger gains in ease of development as well as even stronger light client properties, while at the same time allowing applications to share an economic environment and blockchain security.\nEthereum\nThe intent of Ethereum is to create an alternative protocol for building decentralized applications, providing a different set of tradeoffs that we believe will be very useful for a large class of decentralized applications, with particular emphasis on situations where rapid development time, security for small and rarely used applications, and the ability of different applications to very efficiently interact, are important. Ethereum does this by building what is essentially the ultimate abstract foundational layer: a blockchain with a built-in Turing-complete programming language, allowing anyone to write smart contracts and decentralized applications where they can create their own arbitrary rules for ownership, transaction formats and state transition functions. A bare-bones version of Namecoin can be written in two lines of code, and other protocols like currencies and reputation systems can be built in under twenty. Smart contracts, cryptographic \"boxes\" that contain value and only unlock it if certain conditions are met, can also be built on top of the platform, with vastly more power than that offered by Bitcoin scripting because of the added powers of Turing-completeness, value-awareness, blockchain-awareness and state.\nEthereum Accounts\nIn Ethereum, the state is made up of objects called \"accounts\", with each account having a 20-byte address and state transitions being direct transfers of value and information between accounts. An Ethereum account contains four fields:\n\nThe nonce, a counter used to make sure each transaction can only be processed once\nThe account's current ether balance\nThe account's contract code, if present\nThe account's storage (empty by default)\n\n\"Ether\" is the main internal crypto-fuel of Ethereum, and is used to pay transaction fees. In general, there are two types of accounts: externally owned accounts, controlled by private keys, and contract accounts, controlled by their contract code. An externally owned account has no code, and one can send messages from an externally owned account by creating and signing a transaction; in a contract account, every time the contract account receives a message its code activates, allowing it to read and write to internal storage and send other messages or create contracts in turn.\nNote that \"contracts\" in Ethereum should not be seen as something that should be \"fulfilled\" or \"complied with\"; rather, they are more like \"autonomous agents\" that live inside of the Ethereum execution environment, always executing a specific piece of code when \"poked\" by a message or transaction, and having direct control over their own ether balance and their own key/value store to keep track of persistent variables.\nMessages and Transactions\nThe term \"transaction\" is used in Ethereum to refer to the signed data package that stores a message to be sent from an externally owned account. Transactions contain:\n\nThe recipient of the message\nA signature identifying the sender\nThe amount of ether to transfer from the sender to the recipient\nAn optional data field\nA STARTGAS value, representing the maximum number of computational steps the transaction execution is allowed to take\nA GASPRICE value, representing the fee the sender pays per computational step\n\nThe first three are standard fields expected in any cryptocurrency. The data field has no function by default, but the virtual machine has an opcode using which a contract can access the data; as an example use case, if a contract is functioning as an on-blockchain domain registration service, then it may wish to interpret the data being passed to it as containing two \"fields\", the first field being a domain to register and the second field being the IP address to register it to. The contract would read these values from the message data and appropriately place them in storage.\nThe STARTGAS and GASPRICE fields are crucial for Ethereum's anti-denial of service model. In order to prevent 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\"; usually, a computational step costs 1 gas, but some operations cost higher amounts of gas because they are more computationally expensive, or increase the amount of data that must be stored as part of the state. There is also a fee of 5 gas for every byte in the transaction data. The intent of the fee system is to require an attacker to pay proportionately for every resource that they consume, including computation, bandwidth and storage; hence, any transaction that leads to the network consuming a greater amount of any of these resources must have a gas fee roughly proportional to the increment.\nMessages\nContracts have the ability to send \"messages\" to other contracts. Messages are virtual objects that are never serialized and exist only in the Ethereum execution environment. A message contains:\n\nThe sender of the message (implicit)\nThe recipient of the message\nThe amount of ether to transfer alongside the message\nAn optional data field\nA STARTGAS value\n\nEssentially, a message is like a transaction, except it is produced by a contract and not an external actor. A message is produced when a contract currently executing code executes the CALL opcode, which produces and executes a message. Like a transaction, a message leads to the recipient account running its code. Thus, contracts can have relationships with other contracts in exactly the same way that external actors can.\nNote that the gas allowance assigned by a transaction or contract applies to the total gas consumed by that transaction and all sub-executions. For example, if an external actor A sends a transaction to B with 1000 gas, and B consumes 600 gas before sending a message to C, and the internal execution of C consumes 300 gas before returning, then B can spend another 100 gas before running out of gas.\nEthereum State Transition Function\n\nThe Ethereum state transition function, APPLY(S,TX) -> S' can be defined as follows:\n\nCheck if the transaction is well-formed (i.e., has the right number of values), the signature is valid, and the nonce matches the nonce in the sender's account. If not, return an error.\nCalculate the transaction fee as STARTGAS * GASPRICE, and determine the sending address from the signature. Subtract the fee from the sender's account balance and increment the sender's nonce. If there is not enough balance to spend, return an error.\nInitialize GAS = STARTGAS, and take off a certain quantity of gas per byte to pay for the bytes in the transaction.\nTransfer the transaction value from the sender's account to the receiving account. If the receiving account does not yet exist, create it. If the receiving account is a contract, run the contract's code either to completion or until the execution runs out of gas.\nIf the value transfer failed because the sender did not have enough money, or the code execution ran out of gas, revert all state changes except the payment of the fees, and add the fees to the miner's account.\nOtherwise, refund the fees for all remaining gas to the sender, and send the fees paid for gas consumed to the miner.\n\nFor example, suppose that the contract's code is:\nif !self.storage[calldataload(0)]:\n self.storage[calldataload(0)] = calldataload(32)\n\nNote that in reality the contract code is written in the low-level EVM code; this example is written in Serpent, one of our high-level languages, for clarity, and can be compiled down to EVM code. Suppose that the contract's storage starts off empty, and a transaction is sent with 10 ether value, 2000 gas, 0.001 ether gasprice, and 64 bytes of data, with bytes 0-31 representing the number 2 and bytes 32-63 representing the string CHARLIEfn3. The process for the state transition function in this case is as follows:\n\nCheck that the transaction is valid and well formed.\nCheck that the transaction sender has at least 2000 * 0.001 = 2 ether. If it is, then subtract 2 ether from the sender's account.\nInitialize gas = 2000; assuming the transaction is 170 bytes long and the byte-fee is 5, subtract 850 so that there is 1150 gas left.\nSubtract 10 more ether from the sender's account, and add it to the contract's account.\nRun the code. In this case, this is simple: it checks if the contract's storage at index 2 is used, notices that it is not, and so it sets the storage at index 2 to the value CHARLIE. Suppose this takes 187 gas, so the remaining amount of gas is 1150 - 187 = 963\nAdd 963 * 0.001 = 0.963 ether back to the sender's account, and return the resulting state.\n\nIf there was no contract at the receiving end of the transaction, then the total transaction fee would simply be equal to the provided GASPRICE multiplied by the length of the transaction in bytes, and the data sent alongside the transaction would be irrelevant.\nNote that messages work equivalently to transactions in terms of reverts: if a message execution runs out of gas, then that message's execution, and all other executions triggered by that execution, revert, but parent executions do not need to revert. This means that it is \"safe\" for a contract to call another contract, as if A calls B with G gas then A's execution is guaranteed to lose at most G gas. Finally, note that there is an opcode, CREATE, that creates a contract; its execution mechanics are generally similar to CALL, with the exception that the output of the execution determines the code of a newly created contract.\nCode Execution\nThe code in Ethereum contracts is written in a low-level, stack-based bytecode language, referred to as \"Ethereum virtual machine code\" or \"EVM code\". The code consists of a series of bytes, where each byte represents an operation. In general, code execution is an infinite loop that consists of repeatedly carrying out the operation at the current program counter (which begins at zero) and then incrementing the program counter by one, until the end of the code is reached or an error or STOP or RETURN instruction is detected. The operations have access to three types of space in which to store data:\n\nThe stack, a last-in-first-out container to which values can be pushed and popped\nMemory, an infinitely expandable byte array\nThe contract's long-term storage, a key/value store. Unlike stack and memory, which reset after computation ends, storage persists for the long term.\n\nThe code can also access the value, sender and data of the incoming message, as well as block header data, and the code can also return a byte array of data as an output.\nThe formal execution model of EVM code is surprisingly simple. While the Ethereum virtual machine is running, its full computational state can be defined by the tuple (block_state, transaction, message, code, memory, stack, pc, gas), where block_state is the global state containing all accounts and includes balances and storage. At the start of every round of execution, the current instruction is found by taking the pcth byte of code (or 0 if pc >= len(code)), and each instruction has its own definition in terms of how it affects the tuple. For example, ADD pops two items off the stack and pushes their sum, reduces gas by 1 and increments pc by 1, and SSTORE pops the top two items off the stack and inserts the second item into the contract's storage at the index specified by the first item. Although there are many ways to optimize Ethereum virtual machine execution via just-in-time compilation, a basic implementation of Ethereum can be done in a few hundred lines of code.\nBlockchain and Mining\n\nThe Ethereum blockchain is in many ways similar to the Bitcoin blockchain, although it does have some differences. The main difference between Ethereum and Bitcoin with regard to the blockchain architecture is that, unlike Bitcoin, Ethereum blocks contain a copy of both the transaction list and the most recent state. Aside from that, two other values, the block number and the difficulty, are also stored in the block. The basic block validation algorithm in Ethereum is as follows:\n\nCheck if the previous block referenced exists and is valid.\nCheck that the timestamp of the block is greater than that of the referenced previous block and less than 15 minutes into the future\nCheck that the block number, difficulty, transaction root, uncle root and gas limit (various low-level Ethereum-specific concepts) are valid.\nCheck that the proof-of-work on the block is valid.\nLet S[0] be the state at the end of the previous block.\nLet TX be the block's transaction list, with n transactions. For all i in 0...n-1, set S[i+1] = APPLY(S[i],TX[i]). If any applications returns an error, or if the total gas consumed in the block up until this point exceeds the GASLIMIT, return an error.\nLet S_FINAL be S[n], but adding the block reward paid to the miner.\nCheck if the Merkle tree root of the state S_FINAL is equal to the final state root provided in the block header. If it is, the block is valid; otherwise, it is not valid.\n\nThe approach may seem highly inefficient at first glance, because it needs to store the entire state with each block, but in reality efficiency should be comparable to that of Bitcoin. The reason is that the state is stored in the tree structure, and after every block only a small part of the tree needs to be changed. Thus, in general, between two adjacent blocks the vast majority of the tree should be the same, and therefore the data can be stored once and referenced twice using pointers (i.e., hashes of subtrees). A special kind of tree known as a \"Patricia tree\" is used to accomplish this, including a modification to the Merkle tree concept that allows for nodes to be inserted and deleted, and not just changed, efficiently. Additionally, because all of the state information is part of the last block, there is no need to store the entire blockchain history - a strategy which, if it could be applied to Bitcoin, can be calculated to provide 5-20x savings in space.\nA commonly asked question is \"where\" contract code is executed, in terms of physical hardware. This has a simple answer: the process of executing contract code is part of the definition of the state transition function, which is part of the block validation algorithm, so if a transaction is added into block B the code execution spawned by that transaction will be executed by all nodes, now and in the future, that download and validate block B.\nApplications\nIn general, there are three types of applications on top of Ethereum. The first category is financial applications, providing users with more powerful ways of managing and entering into contracts using their money. This includes sub-currencies, financial derivatives, hedging contracts, savings wallets, wills, and ultimately even some classes of full-scale employment contracts. The second category is semi-financial applications, where money is involved but there is also a heavy non-monetary side to what is being done; a perfect example is self-enforcing bounties for solutions to computational problems. Finally, there are applications such as online voting and decentralized governance that are not financial at all.\nToken Systems\nOn-blockchain token systems have many applications ranging from sub-currencies representing assets such as USD or gold to company stocks, individual tokens representing smart property, secure unforgeable coupons, and even token systems with no ties to conventional value at all, used as point systems for incentivization. Token systems are surprisingly easy to implement in Ethereum. The key point to understand is that all a currency, or token system, fundamentally is, is a database with one operation: subtract X units from A and give X units to B, with the proviso that (i) A had at least X units before the transaction and (2) the transaction is approved by A. All that it takes to implement a token system is to implement this logic into a contract.\nThe basic code for implementing a token system in Serpent looks as follows:\ndef send(to, value):\n if self.storage[msg.sender] >= value:\n self.storage[msg.sender] = self.storage[msg.sender] - value\n self.storage[to] = self.storage[to] + value\n\nThis is essentially a literal implementation of the \"banking system\" state transition function described further above in this document. A few extra lines of code need to be added to provide for the initial step of distributing the currency units in the first place and a few other edge cases, and ideally a function would be added to let other contracts query for the balance of an address. But that's all there is to it. Theoretically, Ethereum-based token systems acting as sub-currencies can potentially include another important feature that onchain Bitcoin-based meta-currencies lack: the ability to pay transaction fees directly in that currency. The way this would be implemented is that the contract would maintain an ether balance with which it would refund ether used to pay fees to the sender, and it would refill this balance by collecting the internal currency units that it takes in fees and reselling them in a constant running auction. Users would thus need to \"activate\" their accounts with ether, but once the ether is there it would be reusable because the contract would refund it each time.\nFinancial derivatives and Stable-Value Currencies\nFinancial derivatives are the most common application of a \"smart contract\", and one of the simplest to implement in code. The main challenge in implementing financial contracts is that the majority of them require reference to an external price ticker; for example, a very desirable application is a smart contract that hedges against the volatility of ether (or another cryptocurrency) with respect to the US dollar, but doing this requires the contract to know what the value of ETH/USD is. The simplest way to do this is through a \"data feed\" contract maintained by a specific party (e.g., NASDAQ) designed so that that party has the ability to update the contract as needed, and providing an interface that allows other contracts to send a message to that contract and get back a response that provides the price.\nGiven that critical ingredient, the hedging contract would look as follows:\n\nWait for party A to input 1000 ether.\nWait for party B to input 1000 ether.\nRecord the USD value of 1000 ether, calculated by querying the data feed contract, in storage, say this is $x.\nAfter 30 days, allow A or B to \"reactivate\" the contract in order to send $x worth of ether (calculated by querying the data feed contract again to get the new price) to A and the rest to B.\n\nSuch a contract would have significant potential in crypto-commerce. One of the main problems cited about cryptocurrency is the fact that it's volatile; although many users and merchants may want the security and convenience of dealing with cryptographic assets, they many not wish to face that prospect of losing 23% of the value of their funds in a single day. Up until now, the most commonly proposed solution has been issuer-backed assets; the idea is that an issuer creates a sub-currency in which they have the right to issue and revoke units, and provide one unit of the currency to anyone who provides them (offline) with one unit of a specified underlying asset (e.g., gold, USD). The issuer then promises to provide one unit of the underlying asset to anyone who sends back one unit of the crypto-asset. This mechanism allows any non-cryptographic asset to be \"uplifted\" into a cryptographic asset, provided that the issuer can be trusted.\nIn practice, however, issuers are not always trustworthy, and in some cases the banking infrastructure is too weak, or too hostile, for such services to exist. Financial derivatives provide an alternative. Here, instead of a single issuer providing the funds to back up an asset, a decentralized market of speculators, betting that the price of a cryptographic reference asset (e.g., ETH) will go up, plays that role. Unlike issuers, speculators have no option to default on their side of the bargain because the hedging contract holds their funds in escrow. Note that this approach is not fully decentralized, because a trusted source is still needed to provide the price ticker, although arguably even still this is a massive improvement in terms of reducing infrastructure requirements (unlike being an issuer, issuing a price feed requires no licenses and can likely be categorized as free speech) and reducing the potential for fraud.\nIdentity and Reputation Systems\nThe earliest alternative cryptocurrency of all, Namecoin (opens in a new tab), attempted to use a Bitcoin-like blockchain to provide a name registration system, where users can register their names in a public database alongside other data. The major cited use case is for a DNS (opens in a new tab) system, mapping domain names like \"bitcoin.org\" (or, in Namecoin's case, \"bitcoin.bit\") to an IP address. Other use cases include email authentication and potentially more advanced reputation systems. Here is the basic contract to provide a Namecoin-like name registration system on Ethereum:\ndef register(name, value):\n if !self.storage[name]:\n self.storage[name] = value\n\nThe contract is very simple; all it is a database inside the Ethereum network that can be added to, but not modified or removed from. Anyone can register a name with some value, and that registration then sticks forever. A more sophisticated name registration contract will also have a \"function clause\" allowing other contracts to query it, as well as a mechanism for the \"owner\" (i.e., the first registerer) of a name to change the data or transfer ownership. One can even add reputation and web-of-trust functionality on top.\nDecentralized File Storage\nOver the past few years, there have emerged a number of popular online file storage startups, the most prominent being Dropbox, seeking to allow users to upload a backup of their hard drive and have the service store the backup and allow the user to access it in exchange for a monthly fee. However, at this point the file storage market is at times relatively inefficient; a cursory look at various existing solutions shows that, particularly at the \"uncanny valley\" 20-200 GB level at which neither free quotas nor enterprise-level discounts kick in, monthly prices for mainstream file storage costs are such that you are paying for more than the cost of the entire hard drive in a single month. Ethereum contracts can allow for the development of a decentralized file storage ecosystem, where individual users can earn small quantities of money by renting out their own hard drives and unused space can be used to further drive down the costs of file storage.\nThe key underpinning piece of such a device would be what we have termed the \"decentralized Dropbox contract\". This contract works as follows. First, one splits the desired data up into blocks, encrypting each block for privacy, and builds a Merkle tree out of it. One then makes a contract with the rule that, every N blocks, the contract would pick a random index in the Merkle tree (using the previous block hash, accessible from contract code, as a source of randomness), and give X ether to the first entity to supply a transaction with a simplified payment verification-like proof of ownership of the block at that particular index in the tree. When a user wants to re-download their file, they can use a micropayment channel protocol (e.g., pay 1 szabo per 32 kilobytes) to recover the file; the most fee-efficient approach is for the payer not to publish the transaction until the end, instead replacing the transaction with a slightly more lucrative one with the same nonce after every 32 kilobytes.\nAn important feature of the protocol is that, although it may seem like one is trusting many random nodes not to decide to forget the file, one can reduce that risk down to near-zero by splitting the file into many pieces via secret sharing, and watching the contracts to see each piece is still in some node's possession. If a contract is still paying out money, that provides a cryptographic proof that someone out there is still storing the file.\nDecentralized Autonomous Organizations\nThe general concept of a \"decentralized autonomous organization\" is that of a virtual entity that has a certain set of members or shareholders which, perhaps with a 67% majority, have the right to spend the entity's funds and modify its code. The members would collectively decide on how the organization should allocate its funds. Methods for allocating a DAO's funds could range from bounties, salaries to even more exotic mechanisms such as an internal currency to reward work. This essentially replicates the legal trappings of a traditional company or nonprofit but using only cryptographic blockchain technology for enforcement. So far much of the talk around DAOs has been around the \"capitalist\" model of a \"decentralized autonomous corporation\" (DAC) with dividend-receiving shareholders and tradable shares; an alternative, perhaps described as a \"decentralized autonomous community\", would have all members have an equal share in the decision making and require 67% of existing members to agree to add or remove a member. The requirement that one person can only have one membership would then need to be enforced collectively by the group.\nA general outline for how to code a DAO is as follows. The simplest design is simply a piece of self-modifying code that changes if two thirds of members agree on a change. Although code is theoretically immutable, one can easily get around this and have de-facto mutability by having chunks of the code in separate contracts, and having the address of which contracts to call stored in the modifiable storage. In a simple implementation of such a DAO contract, there would be three transaction types, distinguished by the data provided in the transaction:\n\n[0,i,K,V] to register a proposal with index i to change the address at storage index K to value V\n[1,i] to register a vote in favor of proposal i\n[2,i] to finalize proposal i if enough votes have been made\n\nThe contract would then have clauses for each of these. It would maintain a record of all open storage changes, along with a list of who voted for them. It would also have a list of all members. When any storage change gets to two thirds of members voting for it, a finalizing transaction could execute the change. A more sophisticated skeleton would also have built-in voting ability for features like sending a transaction, adding members and removing members, and may even provide for Liquid Democracy (opens in a new tab)-style vote delegation (i.e., anyone can assign someone to vote for them, and assignment is transitive so if A assigns B and B assigns C then C determines A's vote). This design would allow the DAO to grow organically as a decentralized community, allowing people to eventually delegate the task of filtering out who is a member to specialists, although unlike in the \"current system\" specialists can easily pop in and out of existence over time as individual community members change their alignments.\nAn alternative model is for a decentralized corporation, where any account can have zero or more shares, and two thirds of the shares are required to make a decision. A complete skeleton would involve asset management functionality, the ability to make an offer to buy or sell shares, and the ability to accept offers (preferably with an order-matching mechanism inside the contract). Delegation would also exist Liquid Democracy-style, generalizing the concept of a \"board of directors\".\nFurther Applications\n1. Savings wallets. Suppose that Alice wants to keep her funds safe, but is worried that she will lose or someone will hack her private key. She puts ether into a contract with Bob, a bank, as follows:\n\nAlice alone can withdraw a maximum of 1% of the funds per day.\nBob alone can withdraw a maximum of 1% of the funds per day, but Alice has the ability to make a transaction with her key shutting off this ability.\nAlice and Bob together can withdraw anything.\n\nNormally, 1% per day is enough for Alice, and if Alice wants to withdraw more she can contact Bob for help. If Alice's key gets hacked, she runs to Bob to move the funds to a new contract. If she loses her key, Bob will get the funds out eventually. If Bob turns out to be malicious, then she can turn off his ability to withdraw.\n2. Crop insurance. One can easily make a financial derivatives contract but using a data feed of the weather instead of any price index. If a farmer in Iowa purchases a derivative that pays out inversely based on the precipitation in Iowa, then if there is a drought, the farmer will automatically receive money and if there is enough rain the farmer will be happy because their crops would do well. This can be expanded to natural disaster insurance generally.\n3. A decentralized data feed. For financial contracts for difference, it may actually be possible to decentralize the data feed via a protocol called \"SchellingCoin (opens in a new tab)\". SchellingCoin basically works as follows: N parties all put into the system the value of a given datum (e.g., the ETH/USD price), the values are sorted, and everyone between the 25th and 75th percentile gets one token as a reward. Everyone has the incentive to provide the answer that everyone else will provide, and the only value that a large number of players can realistically agree on is the obvious default: the truth. This creates a decentralized protocol that can theoretically provide any number of values, including the ETH/USD price, the temperature in Berlin or even the result of a particular hard computation.\n4. Smart multisignature escrow. Bitcoin allows multisignature transaction contracts where, for example, three out of a given five keys can spend the funds. Ethereum allows for more granularity; for example, four out of five can spend everything, three out of five can spend up to 10% per day, and two out of five can spend up to 0.5% per day. Additionally, Ethereum multisig is asynchronous - two parties can register their signatures on the blockchain at different times and the last signature will automatically send the transaction.\n5. Cloud computing. The EVM technology can also be used to create a verifiable computing environment, allowing users to ask others to carry out computations and then optionally ask for proofs that computations at certain randomly selected checkpoints were done correctly. This allows for the creation of a cloud computing market where any user can participate with their desktop, laptop or specialized server, and spot-checking together with security deposits can be used to ensure that the system is trustworthy (i.e., nodes cannot profitably cheat). Although such a system may not be suitable for all tasks; tasks that require a high level of inter-process communication, for example, cannot easily be done on a large cloud of nodes. Other tasks, however, are much easier to parallelize; projects like SETI@home, folding@home and genetic algorithms can easily be implemented on top of such a platform.\n6. Peer-to-peer gambling. Any number of peer-to-peer gambling protocols, such as Frank Stajano and Richard Clayton's Cyberdice (opens in a new tab), can be implemented on the Ethereum blockchain. The simplest gambling protocol is actually simply a contract for difference on the next block hash, and more advanced protocols can be built up from there, creating gambling services with near-zero fees that have no ability to cheat.\n7. Prediction markets. Provided an oracle or SchellingCoin, prediction markets are also easy to implement, and prediction markets together with SchellingCoin may prove to be the first mainstream application of futarchy (opens in a new tab) as a governance protocol for decentralized organizations.\n8. Onchain decentralized marketplaces, using the identity and reputation system as a base.\nMiscellanea And Concerns\nModified GHOST Implementation\nThe \"Greedy Heaviest Observed Subtree\" (GHOST) protocol is an innovation first introduced by Yonatan Sompolinsky and Aviv Zohar in December 2013 (opens in a new tab). The motivation behind GHOST is that blockchains with fast confirmation times currently suffer from reduced security due to a high stale rate - because blocks take a certain time to propagate through the network, if miner A mines a block and then miner B happens to mine another block before miner A's block propagates to B, miner B's block will end up wasted and will not contribute to network security. Furthermore, there is a centralization issue: if miner A is a mining pool with 30% hashpower and B has 10% hashpower, A will have a risk of producing a stale block 70% of the time (since the other 30% of the time A produced the last block and so will get mining data immediately) whereas B will have a risk of producing a stale block 90% of the time. Thus, if the block interval is short enough for the stale rate to be high, A will be substantially more efficient simply by virtue of its size. With these two effects combined, blockchains which produce blocks quickly are very likely to lead to one mining pool having a large enough percentage of the network hashpower to have de facto control over the mining process.\nAs described by Sompolinsky and Zohar, GHOST solves the first issue of network security loss by including stale blocks in the calculation of which chain is the \"longest\"; that is to say, not just the parent and further ancestors of a block, but also the stale descendants of the block's ancest","tokens":15000,"squid":"spider-05","role":"Spec Spider","at":1791346038214,"hash":"e09e0717a75e68121dc69dd5e2ac3e410ca1d6fd"}
{"url":"https://ethresear.ch/t/vorbit-ssf-with-circular-and-spiral-finality-validator-selection-and-distribution/20464","domain":"ethresear.ch","title":"Vorbit SSF with circular and spiral finality: validator selection and distribution - Proof-of-Stake - Ethereum Research","text":"Vorbit SSF with circular and spiral finality: validator selection and distribution \n\n Proof-of-Stake\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Sep 2024\n\n 1 / 1\n\n Sep 2024\n\n Sep 2024\n\n post by aelowsson on Sep 20, 2024\n\n aelowsson\n\n Thanks to Francesco D’Amato and Barnabé Monnot for feedback, and to participants of the RIG + friends (1, 2) meetup where parts of Orbit came together—including Barnabé’s finality stairwell.\nBy Anders Elowsson\n1. Introduction\nEthereum will transition to single-slot finality (SSF) to provide fast and strong economic guarantees that transactions included in a block will not revert. This requires upgrades to the consensus algorithm (1, 2, 3, 4) and the signature aggregation scheme (1, 2, 3), as previously outlined. A third requirement is to upgrade Ethereum’s validator economics and management, with current progress on rotating participation presented in the Orbit SSF proposal. A few considerations in this area are how to incentivize validator consolidation (1, 2), how to temper the quantity of stake (1, 2, 3, 4), and how to select validators for the active set.\nWith SSF, the consensus mechanism will still consist of an available chain (e.g., RLMD GHOST) and a finality gadget (e.g., resembling Casper FFG or Tendermint). It remains unlikely that all validators will be able to participate in every slot, eventhough validator consolidation from EIP-7251 can offer a tangible improvement. This means that validators must be partitioned into committees, with each committee voting on the head of the available chain and/or finalizing successive checkpoints. Committees voting on the available chain must rotate slowly, but such strict requirements do not apply to the finality gadget (after validators have finalized their checkpoint).\nThis post will take a closer look at cumulative finality when finality committees rotate quickly or moderately, proposing strategies for validator selection and distribution. A forthcoming post is intended to review the dynamics of slower validator rotations, with a focus on the available chain. To properly model the impact of consolidation, equations for generating a “pure Zipfian” distribution for a specific quantity of stake are first presented in Section 2, with modeled staking sets generated at varying levels of purity. A method for generating committees in a new type of “epoch” is then presented in Section 3 and cumulative finality analyzed under different levels of validator consolidation and stake quantities—applying various committee selection criteria. A good evaluation measure is the “aggregate finality gap”, tallying missing finality for a block during its progression to full finality. It turns out that the activity rate of a validator should not strictly be determined by its size. Ideally, it varies with the quantity of stake and the composition of the validator set, hence “Vorbit\", as in variable Orbit.\nCumulative finality is impeded at epoch boundaries when committees are shuffled. Circular finality is therefore suggested in Section 4, wherein successive epochs are repeated across a longer era, such that finality accrues in a circular fashion. A mechanism for shuffling the validator set in a spiral fashion is also introduced, to improve finality at shuffling boundaries. The impact of various selection and distribution methods is analyzed in Section 5, and the effect on finality across deposited stake is presented in Section 6. Section 7 reviews methods for predicting the optimal number of validating committees, and Section 8 reviews features related to consensus formation and staking risks.\n2. Zipfian staking sets used for modeling\n2.1 Pure Zipfian distribution\nTo model committee-based SSF, it is necessary to define the expected level of consolidation in the validator set, including a realistic range. The idea is to generate validator sets across this range and then explore how to optimally partition each set into committees. Optimization criteria relate to for example cumulative finality. An achievable consolidation level will also serve as a healthy bound when exploring consolidation incentives in a forthcoming study.\nVitalik reviewed the distribution of stakers in the early days of Ethereum and established that it was roughly Zipfian. The relationship between the staking deposit size D𝐷 and the quantity of stakers N𝑁 was then stipulated to D=32N\\log_2{N}𝐷 =32𝑁log2⁡𝑁 under a “pure” Zipfian distribution. A straightforward procedure for generating a “pure” Zipfian staking set is to distribute stakers’ balances as\n\n\\frac{32N}{1}, \\frac{32N}{2}, ..., \\frac{32N}{N}.\n32𝑁1,32𝑁2,...,32𝑁𝑁.\nWhen N𝑁 is large (as in this case), the associated harmonic series\n\n1 + \\frac{1}{2} + ... + \\frac{1}{N}\n1+12+...+1𝑁\napproaches \\ln(N)+\\gammaln⁡(𝑁) +𝛾, where \\gamma𝛾 is the Euler–Mascheroni constant, approximately 0.577. The total quantity of stake is then\n\nD = 32N(\\ln(N)+\\gamma),\n𝐷=32𝑁(ln⁡(𝑁)+𝛾),\nwhich is close to Vitalik’s approximation. Appendix A.1 shows that N𝑁 therefore can be determined as\n\nN = e^{ W \\left( \\frac{D}{32} e^\\gamma \\right) - \\gamma},\n𝑁=𝑒𝑊(𝐷32𝑒𝛾)−𝛾,\nwhere W𝑊 denotes the Lambert W𝑊 function. These equations provide the blueprint for generating a pure Zipfian staking set given any specific D𝐷. The equation is first applied to D𝐷 to determine N𝑁, and the harmonic series involving N𝑁 is used to create the distribution. The corresponding two lines of Python code are provided in Appendix A.1.\n2.2 Modeled validator sets\nFigure 1 shows the resulting distribution of staker balances in cyan. In purple is a second distribution (“1/2 Zipfian”) created by removing half the stakers (every other staker in the sorted set, starting with the second largest), and reallocating the removed ETH across 32-ETH validators. This aims to capture a scenario where many larger stakers maintain 32-ETH validators. Even if they eventually consolidate, it could still represent an intermediate distribution of “nominal” staker set sizes over the next few years as consolidation slowly progresses. This post uses several such distributions, including also a 9/10 Zipfian distribution (removing every tenth staker), a 4/5 Zipfian distribution, and a 2/3 Zipfian distribution.\nFigure 13067×2199 229 KB\nFigure 1. Log-log plot of distributions of staker set sizes used for modeling in this post, at D=𝐷 = 30M ETH. The set sizes in cyan follow a “pure” Zipfian distribution, and the set sizes in purple remove every other staker and reallocates the stake to 32-ETH validators.\nThe pure Zipfian distribution has N\\approx79\\,000𝑁 ≈79 000 at D=𝐷 = 30M ETH staked. Ethereum’s node count is hard to estimate; crawlers can only provide lower bounds. But it would appear that the node count is a bit below the staker set size for this hypothetical distribution. The 1/2 Zipfian distribution in purple has N\\approx481\\,000𝑁 ≈481 000. This is a point that hopefully will be passed through on the way to a consolidated validator set; yet it is uncertain how quickly progress will be made.\nThe staking sets are converted to validator sets \\mathcal{V}V by having stakers with more than 2048 ETH (excluding those already reallocated to 32-ETH validators) divide their stake into validators of the maximum allowed size (s_{\\text{max}}=2048𝑠max =2048), thus capturing the ideal outcome. The last two validators in this procedure are set to an equal size below 2048. For example, a staker with 5048 ETH will have validators of size {2048, 1500, 1500}.\nMost of the stakers hold less than 2048 ETH under the Zipfian distributions, so this only adds around 9000 validators for the pure Zipfian distribution and around 5000 validators for the 1/2 Zipfian distribution. For the Zipfian staking set, Appendix A.2 shows that the corresponding Zipfian validator set size V=|\\mathcal{V}|𝑉 =|V| can be estimated quite precisely as\n\nV = \\frac{N}{64} \\left(63+\\ln(N/64) + 2\\gamma \\right).\n𝑉=𝑁64(63+ln⁡(𝑁/64)+2𝛾).\nThe distribution of validator counts and sums across consolidation levels is shown in Figure 2.\nFigure 23094×2537 202 KB\nFigure 2. Distribution of validator count and sum at 30M ETH staked in the five modeled validator sets. Axes are log-scaled.\n3. Committees, cumulative finality, and aggregate finality gap\n3.1 Generation of committees\nDefine \\hat{V_a}ˆ𝑉𝑎 as a desirable upper limit for the active validator set size V_a𝑉𝑎. The protocol can allow (and wants) V_a𝑉𝑎 to increase up to \\hat{V_a}ˆ𝑉𝑎, but not beyond this limit. This post sets \\hat{V_a}=31250ˆ𝑉𝑎 =31250, which corresponds to the committee size when 1 million validators are split up into 32 committees (reflecting approximately the current committee size). There has been some progress in enabling clients to handle larger committees, yet the finality gadget may have a slightly different profile than today (e.g., subject the network to twice the signature load). Smaller committees such as \\hat{V_a}=4096ˆ𝑉𝑎 =4096 could therefore also be modeled using the same framework if required.\nLet C𝐶 denote the number of committees in a new form of “epoch” constituting a full rotation of the validator set. The validator set is first split up into C𝐶 disjoint regular committees, ensuring V/C<\\hat{V_a}𝑉/𝐶 <ˆ𝑉𝑎. As an example, the 4/5 Zipfian staking set at D=𝐷 = 30M ETH consists of around 233 thousand (k) validators. An epoch must therefore be split up into at least C=8𝐶 =8 committees, with each regular committee in that case consisting of around 29100 validators. Setting C=8𝐶 =8 leaves room to include around V_{\\mathrm{aux}}=\\hat{V_a}-29\\,100=2150𝑉aux =ˆ𝑉𝑎 −29 100 =2150 auxiliary validators in each committee—validators that also have been assigned to participate in some other regular committee. Once these 2150 validators have been added, the final full committees consist of \\hat{V_a}ˆ𝑉𝑎 validators.\nTo select auxiliary validators for the committees, each validator of size s𝑠 ETH is assigned a weight w𝑤. The baseline weighting is\n\nw(s)=\\frac{s}{s_{\\mathrm{max}}},\n𝑤(𝑠)=𝑠𝑠max,\nwhere s_{\\mathrm{max}}=2048𝑠max =2048 as previously discussed. This is similar to the thresholding operation of Orbit SSF, but it uses s_{\\text{max}}𝑠max rather than 1024. This change differentiates validators in the range 1024-2048. Vorbit performs optimally under full differentiation, and the change also makes individual consolidation incentives (discussed in Section 8.3) reasonable above 1024. Section 5.1 discusses how Orbit can adopt full differentiation. The probability P(s)𝑃(𝑠) for a validator of size s𝑠 ETH to be drawn as the next auxiliary validator to be included in a committee is given by:\n\nP(s) = \\frac{w(s)}{\\sum_{v \\in \\mathcal{V}_{¢}} w(s_v)},\n𝑃(𝑠)=𝑤(𝑠)∑𝑣∈V¢𝑤(𝑠𝑣),\nwhere v𝑣 represents each validator in the complementary set \\mathcal{V}_{¢}V¢ not already part of the committee, and s_v𝑠𝑣 is the size of validator v𝑣. The smallest validators will then tend to participate in roughly 1/C1/𝐶 of the slots and larger validators more frequently, with outcomes depending on the quantity of stake and consolidation level (see also Figure 22).\n3.2 Cumulative finality\nFigure 3 shows the stepwise committee-based cumulative finality for the 4/5 Zipfian staking set, with committees finalizing consecutive slots. For transactions included in block n𝑛, aggregate finality is visually accounted for at the conclusion of the slot that the committee voted in. Finality when only using the regular committee is illustrated using a dashed blue line. Since each regular committee is completely disjoint and proportionally reflects the overall distribution, each committee adds an equal marginal cumulative finality to non-finalized transactions/blocks. The solid blue line in Figure 3 shows cumulative finalization when each regular committee in the example has been supplemented by auxiliary validators up to \\hat{V_a}ˆ𝑉𝑎 (“Full”).\nFigure 33192×2180 272 KB\nFigure 3. Cumulative finalization of block n𝑛 for the 4/5 Zipfian staking set. The finality gap (blue arrow) gradually falls. The aggregate finality gap is the sum of all finality gaps until full finality (cyan area).\n3.3 Aggregate finality gap\nLet D_f𝐷𝑓 be the quantity of stake that has finalized a block, and D𝐷 the total quantity of stake deposited for staking. The finality gap F_g𝐹𝑔 is the proportion of the stake that has not yet finalized a block:\n\nF_g = \\frac{D-D_f}{D}.\n𝐹𝑔=𝐷−𝐷𝑓𝐷.\nWhile D_f𝐷𝑓 is a relevant measure of economic security in isolation, D-D_f𝐷 −𝐷𝑓 is less useful if D𝐷 is unknown. A block’s finality gap will fall with each new slot as long as new validators participate in the finalizing committees. The example with full committees has a lower finality gap due to the additional finality afforded by the auxiliary validators. Since they are selected in a weighted fashion, the effect is rather pronounced eventhough only around 2150 additional validators were added in this example. The difference in the finality gap diminishes as full finality approaches. At this point, most validators will have been present as part of their regular allocation anyway, and repeating a validator does not, in this comparison, improve upon finality (an argument could potentially be made for higher economic security when repeating a validator, but this is beyond the scope of this post).\nA useful utility measure when dealing with cumulative finality is the aggregate finality gap \\widetilde{F}_{\\!g}̃𝐹𝑔 that a block is subjected to during consensus formation, until full finalization. It is represented by the cyan area in Figure 3 and is calculated as\n\n\\widetilde{F}_{\\!g} = C - \\sum_{i=1}^{C} F_{g}(i).\ñ𝐹𝑔=𝐶−𝐶∑𝑖=1𝐹𝑔(𝑖).\n3.4 Auxiliary committees\nWhat happens if the 4/5 Zipfian set is divided into 9 committees instead of 8? The added auxiliary committee (C_{\\mathrm{aux}}=1𝐶aux =1) results in \\hat{V_a}/9\\approx3470ˆ𝑉𝑎/9 ≈3470 auxiliary validators in each committee, facilitating a further reduction in \\widetilde{F}_{\\!g}̃𝐹𝑔. A comparison between epochs of 8 committees (blue) and 9 committees (purple) is shown in Figure 4. The difference in the finality gap \\Delta F_{\\!g}Δ𝐹𝑔 for block n𝑛 is indicated in green for the slots when there is a reduction in the gap, and in red when there is an increase. Cumulative finality first improves due to the additional auxiliary validators, and this is the most pronounced effect. As the number of duplicated validators increases, the reduction diminishes. At the beginning of slot n+7𝑛 +7, the validator set divided into 8 committees instead has a lower F_g𝐹𝑔, and it reaches full finality one slot earlier, at the start of slot n+8𝑛 +8.\nFigure 43192×2180 240 KB\nFigure 4. Cumulative finalization of block n𝑛 for the 4/5 Zipfian staking set. When adding an auxiliary committee, there is more room for auxiliary validators with high balances in each committee (purple line), and finality therefore accrues faster during the initial phase.\nThe aggregate finality gap continues to fall when more auxiliary committees are added, as indicated in Figure 5. In the comparison between C_{\\mathrm{aux}}=3𝐶aux =3 and C_{\\mathrm{aux}}=4𝐶aux =4, \\Delta F_{g}Δ𝐹𝑔 is negative starting at the beginning of slot n+5𝑛 +5, and continues to fall all the way up to slot n+12𝑛 +12. As a result, the aggregate finality gap \\widetilde{F}_{\\!g}̃𝐹𝑔 is about equal for these two configurations.\nFigure 53192×2180 269 KB\nFigure 5. Cumulative finalization of block n𝑛 for the 4/5 Zipfian staking set, comparing the outcome between different numbers of auxiliary committees.\nFigure 6 shows the same example for a purely Zipfian staking set. At C_{\\mathrm{aux}}=4𝐶aux =4, almost 20M ETH (2/3 of the stake) will finalize the block in the first slot. As in the previous example, the benefit of adding auxiliary committees diminishes as more are added (\\widetilde{F}_{\\!g}̃𝐹𝑔 stops decreasing and eventually reverses).\nFigure 63192×2180 243 KB\nFigure 6. Cumulative finalization of block n𝑛 for a pure Zipfian staking set, comparing the outcome between different numbers of auxiliary committees.\nFigure 7 instead shows the outcome with a 1/2 Zipfian staking set. The approximately 486k validators need to be split into at least\n\n\\left\\lceil \\frac{486000}{\\hat{V}_{\\!a}} \\right\\rceil = 16\n⌈486000ˆ𝑉𝑎⌉=16\ncommittees. With no full committees, only 1.875 million ETH will finalize each round. This might seem problematic since a committee that fails to finalize will hold up finality until a sufficient amount of stake in the committee has been replaced through an inactivity leak or a similar mechanism. An accelerated inactivity leak could be considered under such circumstances. From an accountability perspective, this level of stake has however been argued to be totally sufficient.\nFigure 73192×2180 267 KB\nFigure 7. Cumulative finalization of block n𝑛 for the 1/2 Zipfian staking set, comparing the outcome between different numbers of auxiliary committees.\n4. Circular and spiral finality\nThe figures in the previous subsection have all captured cumulative finality over one epoch and are representative for the first block in an epoch. During each epoch, the complete validator set is iterated over, so full finality is reached at the end of the epoch. However, if the validator set is shuffled between epochs, then only the first block of the epoch will achieve full finality by the end of the epoch. For blocks in later slots of the epoch, full finality will not be reached until the end of the next epoch. Marginal cumulative finality decreases markedly at epoch boundaries, because committees on each side of the boundary will have more validator overlaps (even when using only regular committees). Thus, when stating that full finality can be reached within eight slots for the 4/5 Zipfian staking set in Figures 3-5, this is a qualified statement. For the second block of the epoch, full finality is not reached until after 15 slots (7 slots in the first epoch and 8 slots in the subsequent epoch). Recall that C𝐶 denotes the number of committees in an epoch, which is also then the number of slots in an epoch during regular operation. The average number of slots to full finality \\bar{S}_{\\!f}¯𝑆𝑓 then becomes\n\n\\bar{S}_{\\!f}=C + \\frac{C-1}{2}.\n¯𝑆𝑓=𝐶+𝐶−12.\nWhile full finality might be more of an ideational concern, degradation from shuffling begins already at the second slot/committee if the block was proposed in the last slot of the epoch. There are two ways to improve on this: circular finality and spiral finality. Both provide benefits starting from a block’s second slot of accruing finality.\n4.1 Circular finality\nThe most straightforward solution is to avoid shuffling the validator set each epoch. Instead, the validator set is shuffled in eras, where each era can consist of multiple epochs. The number of epochs per era E_{\\text{era}}𝐸era is determined from the desired number of slots per era \\hat{S}_{\\text{era}}ˆ𝑆era and C𝐶, rounded to the nearest integer:\n\nE_{\\text{era}}=\\lfloor\\hat{S}_{\\text{era}}/C\\rceil. \n𝐸era=⌊ˆ𝑆era/𝐶⌉.\nWith this change, the first (E_{\\text{era}}-1)C(𝐸era −1)𝐶 blocks of the era will be finalized in C𝐶 slots, whereas the last C𝐶 blocks will finalize in accordance with the previous equation C + (C-1)/2𝐶 +(𝐶 −1)/2. Furthermore, and perhaps more importantly, cumulative finality will not degrade when crossing epoch boundaries within the era. The average number of slots to full finality among the E_{\\text{era}}\\times C𝐸era ×𝐶 blocks of an era becomes:\n\n\\bar{S}_{\\!f}=\\frac{C(E_{\\text{era}}-1)C + C(C + (C-1)/2)}{E_{\\text{era}}\\times C}, \n¯𝑆𝑓=𝐶(𝐸era−1)𝐶+𝐶(𝐶+(𝐶−1)/2)𝐸era×𝐶,\nwhich simplifies to\n\n\\bar{S}_{\\!f}=C + \\frac{C-1}{2E_{\\text{era}}}.\n¯𝑆𝑓=𝐶+𝐶−12𝐸era.\nAs an example, set \\hat{S}_{\\text{era}}=64ˆ𝑆era =64. The 4/5 Zipfian staking set with no auxiliary slots will then finalize 57 out of 64 blocks in 8 slots, with one block each among the remaining finalizing in 9, 10, 11 slots, etc. Furthermore, only the last 7 out of 64 slots in the era will suffer degraded cumulative finalization, whereas 56 out of 64 will do so without circular finality. The average number of slots to full finality becomes \\bar{S}_{\\!f} \\approx 8.4¯𝑆𝑓 ≈8.4. In contrast, without circular finality, the result is \\bar{S}_{\\!f}=C+(C-1)/2 = 11.5.¯𝑆𝑓 =𝐶 +(𝐶 −1)/2 =11.5.\n4.2 Spiral finality\nWhile circular finality is effective in reducing \\bar{S}_{\\!f}¯𝑆𝑓 and the proportion of blocks with degraded cumulative finality, it does not reduce the maximum time to full finality, which remains S_{f} = 2C-1𝑆𝑓 =2𝐶 −1. This maximum applies to the block proposed in the second slot of the last epoch of the era. A method to reduce this maximum is spiral finality, where limits are placed on how many slots validators may shift forward within the epoch when they are shuffled. This is controlled by the variable C_{\\text{shift}}𝐶shift. Setting C_{\\text{shift}}=2𝐶shift =2 means that validators may only shift two slots forward, but they can always shift back to the start of the epoch. The regular validators located in the first committee of the epoch \\mathcal{C}_nC𝑛 can then be reassigned between committees \\mathcal{C}_nC𝑛 and \\mathcal{C}_{n+2}C𝑛+2, the regular validators in committee \\mathcal{C}_{n+1}C𝑛+1 can be reassigned between committees \\mathcal{C}_nC𝑛 and \\mathcal{C}_{n+3}C𝑛+3, etc. If \\hat{V}_aˆ𝑉𝑎 is set relatively low, it might be reasonable to make further stipulations on the random selection, to ensure an even distribution of large and small validators.\nCircular and spiral finality can be combined to achieve a low average time to full finality, as well as a lower upper bound on it. In this setup, spiral finality is applied to the last epoch of an era.\n5. Optimized selection and distribution of auxiliary validators\nThis section reviews two different methods for optimizing the distribution of auxiliary validators. The plots will as previously disregard epoch boundaries (presume circular finality). In fact, to provide a more stable results in light of the randomness inherent in the validatior selection process, finality is evaluated in a circular fashion in all plots of cumulative finality in this post. This involves computing results for C𝐶 consecutive slots across all C𝐶 different starting positions. Additionally, the approach ensures that spacing and distribution of validators are not attuned to epoch boundaries, and is particularly useful in Section 5.2 that introduces equally spaced validators.\n5.1 Adjusted weighting\nThe most straightforward modification is to adjust the weighting scheme by adding the power p𝑝 to the original equation:\n\nw(s)=\\Big(\\frac{s}{s_{\\mathrm{max}}}\\Big)^p.\n𝑤(𝑠)=(𝑠𝑠max)𝑝.\nIf p>1𝑝 >1, larger auxiliary validators are further prioritized over smaller validators. This can be useful since the smaller validators are still guaranteed to be included in one committee, and C𝐶 can be relatively small (short epochs). A potential change to the Orbit slow-rotation paradigm, when validators are selected directly from the weighting and there is no regular committee, is that p𝑝 instead can be set below 1. This reduces the “slope” of the thresholding mechanism, allowing smaller validators to be selected with a higher probability than for example 1/32 or 1/64. This can be beneficial for reasons discussed in Section 8.3, and will be further explored in a post covering the slowly rotating validator set.\nFigure 8 shows the difference in the finality gap in terms of finalized stake \\Delta D_{f}Δ𝐷𝑓 when changing p𝑝 from 1 to 2. The average outcome across the five validator sets (from 1/2 Zipfian to fully Zipfian) was used. The reader may also wish to review Figure 22 in Section 8.2, which shows how the change in weighting alters the probability for a validator of size s𝑠 to be active.\nFigure 83104×2181 193 KB\nFigure 8. Change in D_{f}𝐷𝑓 at 30M staked when p𝑝 is changed from 1 to 2, during a block’s progression to full finality.\nAs evident, D_{f}𝐷𝑓 is on average almost 5M ETH higher for the first slot, when C_{\\text{aux}}𝐶aux is between 3-4 (those lines are somewhat overlapping in the graph). This is a significant improvement, reducing the finality gap at the first slot by almost 1/6. The examples with 2-4 auxiliary committees then experience a slight reduction starting at n+5𝑛 +5. This is because validators with the most stake become included in almost every committee: repeated validators do not increase the cumulative finality, and they occupy space in the committees, preventing new validators from finalizing the block.\n5.2 Equal spacing\nSince repeated validators do not increase cumulative finality, it is advantageous to equally space repeated auxiliary validators across the epoch so that repetitions occur as far apart as possible. The distribution of auxiliary validators can then be done slightly differently. The number of auxiliary inclusions \\lambda𝜆 can be set for a validator with stake s𝑠 as\n\n\\lambda(s) = \\frac{V_{\\text{aux}}(C-1)w(s)-\\widetilde{V}_{\\!\\text{aux}}}{\\sum_{v \\in \\mathcal{V}} w(s_v)}.\n𝜆(𝑠)=𝑉aux(𝐶−1)𝑤(𝑠)−̃𝑉aux∑𝑣∈V𝑤(𝑠𝑣).\nIn this equation, \\widetilde{V}_{\\!\\text{aux}}̃𝑉aux sums the auxiliary validator instances added across the full epoch among validators that are present in every slot. It is initially set to zero. For any validator v𝑣 with \\lambda_v > C-1𝜆𝑣 >𝐶 −1, an iterative procedure sets \\lambda_v = C-1𝜆𝑣 =𝐶 −1, removes the validator from \\mathcal{V}V, adds C-1𝐶 −1 to \\widetilde{V}_{\\!\\text{aux}}̃𝑉aux, and recomputes \\lambda𝜆 for the remaining validators. The iterative procedure relying on \\widetilde{V}_{\\!\\text{aux}}̃𝑉aux is necessary because a validator can never be included more than once per slot (\\lambda \\not > C𝜆 ≯𝐶).\nGiven \\lambda𝜆, each validator is guaranteed inclusion in \\lfloor \\lambda \\rfloor⌊𝜆⌋ committees, with any remaining fraction used when drawing validators that will be included in one additional auxiliary committee. The final outcome is denoted \\lambda_f𝜆𝑓. Auxiliary inclusions for validators are equally spaced at intervals of C/(\\lambda_f+1)𝐶/(𝜆𝑓 +1) slots. The spacing procedure starts from the regular committee position, rounding the computed distance to the nearest integer, and wrapping around epoch boundaries using the modulo operation.\nDue to randomness in the distribution of validators, slots will with this procedure generally end up slightly below or above \\hat{V}_aˆ𝑉𝑎. In general, this should not be an issue because \\hat{V}_aˆ𝑉𝑎 would typically allow for some flexibility. However, to maintain consistency with the random draw in the evaluation, an iterative procedure reallocated validators from committees with more than \\hat{V}_aˆ𝑉𝑎 validators to committees with fewer, still ensuring no duplications of validators within a committee.\nLet \\equiv≡ represent equal spacing and \\not\\equiv≢ the spacing achieved due to random draw. The change \\Delta D_fΔ𝐷𝑓 at 30M ETH staked, computed as D_f(\\equiv) - D_f(\\not\\equiv)𝐷𝑓( ≡) −𝐷𝑓( ≢), is shown in Figure 9. The variable p𝑝 was set to 2 both for random and equally spaced validators.\nThe most significant improvement from equal spacing occurs in the second slot after the block has been proposed. By definition, the first slot will not contain any repetitions anyway. The improvements are most pronounced when there are fewer auxiliary committees, as these are the circumstances where 2048-ETH validators are not included in nearly every committee.\nFigure 93160×2179 230 KB\nFigure 9. Change in D_{f}𝐷𝑓 at 30M staked when validators are equally spaced across the epoch, during a block’s progression to full finality.\nThe outcome for the 4/5 Zipfian staking set using p=2𝑝 =2 and equal spacing is shown in Figure 10. It can be compared with the previous plot in Figure 5, that shows the outcome with p=1𝑝 =1 and random spacing. The changes increase D_f𝐷𝑓 from 15M ETH to 20M ETH in the first slot when C_{\\text{aux}}𝐶aux is 3-4 and in the second slot when C_{\\text{aux}}=1𝐶aux =1.\nFigure 103192×2180 264 KB\nFigure 10. Cumulative finalization of block n𝑛 for the 4/5 Zipfian staking set, with p=2𝑝 =2 and equal spacing \\equiv≡.\n6. Analysis across D𝐷\nThe analysis in this and the next section relies on p=2𝑝 =2 and the randomized distribution of auxiliary validators \\not\\equiv≢. Figure 11 shows how the aggregate finality gap varies with C_{\\text{aux}}𝐶aux across deposit size for the 4/5 Zipfian set. At lower quantities of stake, C_{\\text{aux}}=0𝐶aux =0 gives the lowest \\widetilde{F}_{\\!g}̃𝐹𝑔. At higher quantities of stake, C_{\\text{aux}}=5𝐶aux =5 gives the lowest among those plotted. But increasing C_{\\text{aux}}𝐶aux all the way up to 7 will spuriously give the lowest results above 70M ETH staked. However, outcomes are very tightly overlapping at higher settings (hence they were not plotted), implying that in terms of \\widetilde{F}_ {\\! g}̃𝐹𝑔, venturing above C_{\\text{aux}}=4𝐶aux =4 will not offer significant improvements.\nThe characteristic shark fin-pattern emerges when validators are redistributed due to changes in C𝐶. As D𝐷 increases while the distribution is kept fixed, V𝑉 also increases. Each “fin” represents the addition of one committee. This addition gives room for more auxiliary validators, which reduces \\widetilde{F}_ {\\! g}̃𝐹𝑔 when C_{\\text{aux}}𝐶aux is relatively low. However, if C_{\\text{aux}}𝐶aux is too high for the given validator set, the outcome is reversed, and the addition of one committee instead increases \\widetilde{F}_ {\\! g}̃𝐹𝑔. This is evident in Figure 12, which zooms in on the outcome below D=𝐷 = 35M ETH.\nFigure 113078×2183 476 KB\nFigure 11. Aggregate finality gap for the 4/5 Zipfian set across D𝐷 for various numbers of auxiliary committees.\nFigure 123134×2183 418 KB\nFigure 12. Aggregate finality gap for the 4/5 Zipfian set with D\\leq𝐷 ≤ 35M ETH for various numbers of auxiliary committees.\nDefine \\widetilde{F}^*_{\\!g}̃𝐹∗𝑔 as the minimum aggregate finality gap, achieved at the associated minimum auxiliary committees C^*_{\\text{aux}}.𝐶∗aux. This corresponds to the lowest line at any specific D𝐷 in Figures 11-12. Figure 13 plots \\widetilde{F}^ * _ {\\!g}̃𝐹∗𝑔 for all five staking sets. As evident, there are two fundamental factors that degrade committe-based cumulative finality: a higher quantity of stake and a lower level of consolidation.\nFigure 133125×2183 305 KB\nFigure 13. The minimum aggregate finality gap across stake. Fast finality is degraded both by a higher quantity of stake and a lower level of consolidation.\nFigure 14 instead focuses on how the optimal number of committees at \\widetilde{F}^*_{\\!g}̃𝐹∗𝑔 varies. However, the optimal number of committees will fluctuate greatly due to the fin-like pattern evident in Figure 12, and it is also a discrete measure. Therefore, parabolic interpolation (see Appendix B.3) was applied to three points around the minimum, resulting in a smoother representation of total committees, here denoted C^y𝐶𝑦. Both the aggregate finality gap and the total number of committees rise linearly with an increase in the quantity of stake, keeping the distribution fixed.\nFigure 143094×2183 384 KB\nFigure 14. Interpolated total number of committees that minimizes the aggregate finality gap.\n7. Predicting the optimal number of auxiliary committees\n7.1 Overview\nHow should the number of auxiliary committees (or any other setting such as p𝑝) be determined during operation if the suggested variant of committee-based finality is pursued? Five options can be highlighted:\n\nGenerate committees and compute \\widetilde{F}_ {\\! g}̃𝐹𝑔 (or some more appropriate measure, as further discussed in Appendix B.2) for various C_{\\text{aux}}𝐶aux-settings (e.g., 0-6), selecting the one that minimizes \\widetilde{F}_ {\\! g}̃𝐹𝑔. This solution might have a high computational load if there are several hundred thousand validators.\nRun the process for only the current and adjacent C_{\\text{aux}}𝐶aux-settings. If the analysis is performed frequently, store the results and rely on hysteresis, switching only if a clear majority of recent evaluations are in favor. For example, a threshold of 80% over the last week could be used.\nIf the computational load in (2) is still too high, a reduced validator set \\mathcal{V}_ rV𝑟 can be relied upon, with validators in \\mathcal{V}_ rV𝑟 drawn evenly spaced from the ordered full set \\mathcal{V}V. The setting for \\hat{V_a}ˆ𝑉𝑎 should then be reduced proportional to the reduction in the validator set before generating committees.\nCompute some simple features of the validator set related to for example variability, and determine an appropriate number of auxiliary slots based on these features.\nSpecify a fixed number of auxiliary committees so that the mechanism performs reasonably well under a wide range of validator sets, e.g., C_{\\text{aux}}=2𝐶aux =2.\n\nWhen it comes to implementation complexity, all options are rather straightforward. A benefit of Options 1-3 is that client will need to implement the function for assigning validators to committees anyway. The remaining process is then the evaluation function described in Appendix B.1. This process does not have a high time complexity, but it might still be too computationally intensive if there are many hundred thousand validators.\nOption 2 is then rather appealing, with some parallels to how hysteresis is leveraged when updating validators’ effective balance. Option 3 can further reduce the computational requirements by at least an order of magnitude (10x), perhaps up to two (100x). A question then is what accuracy that can be achieved if the validator set is reduced to for example |\\mathcal{V}_ r| = 1000|V𝑟| =1000 or |\\mathcal{V}_ r| = 5000|V𝑟| =5000. This is studied in Section 7.2. Another question is of course the viability of Option 4, which could further reduce the computational requirements. This is studied in Section 7.3, and Option 5 is reviewed in Section 7.4. The conclusion of the experiment, expanded on in Section 9, is that Option 2, 3 or 5 seems like the most viable, with Option 5 as a natural starting point.\nThe ground truth for modeling was not based on the optimal number of auxiliary committees C_{\\text{aux}}𝐶aux but instead on the optimal number of auxiliary validators V_{\\text{aux}}𝑉aux, mainly to circumvent the fin-like pattern in Figures 11-12. To achieve a smoother target, a more refined point V^{y}_{\\text{aux}}𝑉𝑦aux between neighboring V_{\\text{aux}}𝑉aux values was derived via parabolic interpolation—as previously illustrated also for C^y𝐶𝑦 in Figure 14. A further small adjustment was made before interpolation, slightly weighting up \\widetilde{F}_ {\\! g}̃𝐹𝑔 when a large number of auxiliary slots relative to the number of regular slots was applied. Appendix B.2-3 explains the full procedure for generating the ground truth. Appendix B.4 then describes the generation of an additional log-normal validator set to provide a greater spread in the evaluated examples. It is shown in yellow in Figures 15-20. One thousand validator sets were generated for each of the six different distributions for the analysis with D𝐷 in the range 10M-80M ETH, giving a total of 6000 examples.\n7.2 Prediction accuracy with a reduced validator set\nHow accurate can the predictions be with a reduced validator set \\mathcal{V}_rV𝑟 from Option 3, if \\mathcal{V}_rV𝑟 consists of only 1000 or 5000 validators? To test this, the predicted optimal, V^{x}_{\\text{aux}}𝑉𝑥aux, was computed on the reduced set, using the same evaluation procedure as when setting the ground truth V^{y}_{\\text{aux}}𝑉𝑦aux on the full set (Appendix B.1). The outcome is shown in Figure 15 for 1000 validators (R^2=0.893𝑅2 =0.893) and in Figure 16 for 5000 validators (R^2=0.960𝑅2 =0.960). The broader black diagonal line represents perfect predictions, while the thinner black lines indicate the range where predictions fall within \\hat{V}_{\\!a}ˆ𝑉𝑎.\nFigure 152081×1846 441 KB\nFigure 15. Predictions of the optimal number of auxiliary validators compared to ground truth, based on a reduced set of 1000 validators.\nFigure 162081×1846 408 KB\nFigure 16. Predictions of the optimal number of auxiliary validators compared to ground truth, based on a reduced set of 5000 validators.\nAs evident, at higher values for V_\\text{aux}𝑉aux, predictions become increasingly less accurate. This is related to the phenomenon shown in Figure 11, wherein the relative difference in \\widetilde{F}_{\\! g}̃𝐹𝑔 will not be that large between the the best settings for C_{\\text{aux}}𝐶aux (and thus V_{\\text{aux}}𝑉aux). The broader implication is that getting C_\\text{aux}𝐶aux slightly wrong will then not matter much. At the other end, getting it wrong at lower C_\\text{aux}𝐶aux towards the bottom left corner is more of a concern. Note also that only examples where D>𝐷 > 40M ETH are problematic (review Figure 20 for the ground truth range 25M-35M).\nThe errors in the predictions stem from how the random selection influences the composition of the committees. Repeating the experiment several times and averaging the outcomes will therefore serve to improve accuracy (as would equally spaced validators described in Section 5.2). An example of the average outcome for four validator sets with V_{r} =𝑉𝑟 = {1000, 2000, 3000, 5000} respectively is shown in Figure 17. The predictions are now all within the \\hat{V}_aˆ𝑉𝑎 boundary, and R^2=0.981𝑅2 =0.981. It must also be remembered that while V^{y}_{\\text{aux}}𝑉𝑦aux by definition is the ground truth ideal outcome, it will also itself reflect a random division of validators during generation.\nFigure 172081×1843 400 KB\nFigure 17. Predictions of the optimal number of auxiliary validators compared to ground truth, based on the average of four reduced sets.\n7.3 Prediction accuracy using general features\nCan general features be used to determine the optimal number of auxiliary validators? To explore this, features were generated for the simulated validator sets, capturing basic properties such as validator count, deposit size, and various measures of variability. Polynomial feature expansion of degree 2 was used to generate all monomials of the original features, capturing interactions and non-linear relationships. Predictions were then made using multiple linear regression. The final features were selected through a semi-automatic forward feature selection process, manually choosing among top predictors to premier those that are easier to interpret (a key requirement is a simple model). This process resulted in a linear regression model consisting of three features: {V\\sigma𝑉𝜎, V_w\\delta𝑉𝑤𝛿, D^2𝐷2}.\nThe first feature is the number of validators V𝑉 multiplied by the standard deviation of the validator set \\sigma𝜎. If the standard deviation is high, auxiliary validators become particularly useful for reducing the finality gap. The second feature multiplies the average absolute deviation, denoted \\delta𝛿, with a weighted count of validators V_w𝑉𝑤. The weighting assigned validators of size 32 and 2048 a weight of 1, with the weight then log-linearly falling to 0 at the mean validator size \\bar{\\mathcal{V}}¯V. Specifically, each validator holding s𝑠 ETH, received a weighting of:\n\n\\text{Weighted count}(s) = \n\\begin{cases}\n1 - \\frac{\\log(s) - \\log(32)}{\\log(\\bar{\\mathcal{V}}) - \\log(32)} & \\text{if } s \\leq s_1 \\\\\n1 - \\frac{\\log(2048) - \\log(s)}{\\log(2048) - \\log(\\bar{\\mathcal{V}})}\n& \\text{if } s > s_1\n\\end{cases}.\nWeighted count(𝑠)=⎧{\n{⎨{\n{⎩1−log⁡(𝑠)−log⁡(32)log⁡(¯V)−log⁡(32)if 𝑠≤𝑠11−log⁡(2048)−log⁡(𝑠)log⁡(2048)−log⁡(¯V)if 𝑠>𝑠1.\nPredictions with V^{x}_{\\text{aux}}<0𝑉𝑥aux <0 were set to 0 (the number of auxiliary validators cannot be negative). The predictions had R^2=0.975𝑅2 =0.975 and are shown in Figure 18. The wider dispersion in the lower left corner is somewhat problematic, as previously discussed. Option 4 therefore gives slightly worse outcomes than Option 3. Also note that since there was no training/test split, quite a bit of overfitting can be assumed. If Option 4 is to be pursued seriously, there would need to be a test set and a wider variety in training examples.\nFigure 182081×1843 376 KB\nFigure 18. Predictions of the optimal number of auxiliary validators compared to ground truth, based on general features capturing, e.g., variability in the validator set.\n7.4 Prediction accuracy using a fixed number of auxiliary committees\nIt may also be interesting to review the outcome with a fixed number of auxiliary committees. The outcome when setting all examples to a fixed C_{\\text{aux}}=2𝐶aux =2 is shown in Figure 19. It generates predictions in a vertical band that is \\hat{V}_aˆ𝑉𝑎 wide, with deviations from the ground truth extending well beyond \\hat{V}_aˆ𝑉𝑎. Figure 20 instead focuses on the range 25-35M ETH. In this case predictions tend to fall within \\hat{V}_aˆ𝑉𝑎, except for the log-normal distribution, which has several examples with little to no variability in validator balances (in that case, auxiliary slots bring no benefit). This illustrates that if D𝐷 is kept in a narrow range, the variation in the optimal number of auxiliary committees/validators is reduced considerably. Starting with a fixed number of auxiliary committees is therefore a viable baseline strategy.\nFigure 192081×1846 470 KB\nFigure 19. Predictions of the optimal number of auxiliary validators compared to ground truth, with a fixed C_{\\text{aux}}=2𝐶aux =2.\nFigure 202081×1846 272 KB\nFigure 20. Predictions of the optimal number of auxiliary validators compared to ground truth, with a fixed C_{\\text{aux}}=2𝐶aux =2, for validator sets in the range D=𝐷 = 25M-35M ETH.\n8. Properties related to consensus formation\n8.1 Committee rotation ratio\nDefine the committee rotation ratio R𝑅 as the proportion of the stake that is replaced in successive committees following finalization. If all validators are replaced, R=1𝑅 =1, and if all remain, R=0𝑅 =0. Figure 21 shows how R𝑅 changes across V_{\\text{aux}}𝑉aux at 30M ETH staked. Aside from the relevance to the slow-rotation regime of the available chain, a ceiling has previously been discussed for a finality gadget leveraging Casper FFG. That suggestion, R=0.25𝑅 =0.25, is indicated by a black horizontal line. The circles indicate the point where the aggregate finality gap is minimized (V^*_{\\text{aux}}𝑉∗aux). This happens at rather modest rotation ratios and can of course readily be adjusted. Rotation becomes comparatively slow after adding around 150k auxiliary validator instances (C_{\\text{aux}}\\approx5𝐶aux ≈5), where 90% of the stake remains whenever a committee finalizes and rotates.\nFigure 213170×2179 384 KB\nFigure 21. Committee rotation ratio R𝑅 across auxiliary validators. Circles indicate the point where the aggregate finality gap is minimized.\n8.2 Activity rate\nThe activity rate a𝑎 captures the proportion of the committees that a validator is active in (defined as p𝑝 in the Orbit post). The reciprocal a^{-1}𝑎−1 captures the average number of slots until the validator has participated in one of them and will be referred to as a validator’s “apsis”—its orbital distance.\nFigure 22 shows how a𝑎 varies with validator size s𝑠 when the aggregate finality gap is minimized (at V^*_{\\text{aux}}𝑉∗aux marked by circles in Figure 21). As evident, a(s)𝑎(𝑠) is not a fixed property across validator sets, and will vary with, e.g., consolidation level and deposit size. Leveraging a variable orbit (“Vorbit”) seems natural, because a multitude of features that Ethereum wishes to optimize for vary with the composition of the validator set (a dynamic threshold has also previously been suggested).\nFigure 222641×1816 420 KB\nFigure 22. The activity rate a𝑎 across validator balances s𝑠 at the minimized aggregate finality gap and 30M staked for the five sets. Note that the x-axis is log-scaled.\n8.3 The activity ratio and its implications on staking economics\nThe activity ratio a_r = a(s_{\\mathrm{min}})/a(s_{\\mathrm{max}})𝑎𝑟 =𝑎(𝑠min)/𝑎(𝑠max) captures how often validators with a small balance are active, relative to validators with larger balances. The apsis ratio again denotes the reciprocal a^{-1}_r𝑎−1𝑟 and can sometimes be easier to interpret: a^{-1}_r=32𝑎−1𝑟 =32 means that small validators are present 32 times less frequenly than big validators. When a_r𝑎𝑟 is small (and a^{-1}_r𝑎−1𝑟 thus big), stakers running validators with a lower balance close to s_{\\mathrm{min}}𝑠min will bear a lower slashing risk than stakers running validators with higher balances close to s_{\\mathrm{max}}𝑠max. Inactive validators can hardly (by mistake or otherwise) make slashable actions. Someone running many small validators can therefore catch a faulty setup early so that a lower proportion of their validators are affected. Likewise, a small validator is less likely to get caught up in a catastrophic slashing event. Even if such an event only takes place every 100 years, it still meaningfully impacts the expected value of staking, particularly if the total staking yield decreases in the future.\nIn a slow-rotating mechanism, a_r𝑎𝑟 is particularly relevant, given that stakers with a high average apsis on their validators can have even more time to, e.g., adjust faulty setups for inactive validators before they return as active. Yet a_r𝑎𝑟 is relevant also in a fast-rotating mechanism. To encourage consolidation, individual incentives should compensate for the additional risks that large validators take on, relative to small validators. Individual incentives can potentially also be combined with collective consolidation incentives. The individual incentives will generally need to be higher when a_r𝑎𝑟 is smaller, because the benefit of running smaller validators increases. It is therefore desirable to keep a_r𝑎𝑟 closer to 1, whenever possible. This minimizes the yield differential between small and large validators, reducing “tensions” among stakers. Such tensions emerge under high yield differentials, where Ethereum will favor (or at least appear to favor) stakers with more capital.\nEven if the additional yield is intended to compensate for increased risks, only stakers with high capital will have the option to choose between higher and lower risk. Stakers with more capital will also disproportionately benefit from the ability to adjust faulty setups among one of their many validators, should they decide to split up their stake. Tensions may therefore also emerge if a large staking service provider (SSP) relies on small validators to reduce its risk profile, and collective incentives as a result bring down everyone’s yield. There may for example be calls to discouragement attack the specific SSP’s validators, introducing an unhealthy dynamic to consensus formation. There are similarities to the type of issues that may emerge in MEV burn when using an English auction, where SSPs will need to specifically target each other through early builder bids to remain competitive.\nIn Figure 22, a_r𝑎𝑟 is approximately 1/6 for the Zipfian staking set at p=2𝑝 =2. Validators with 2048 ETH are always present, and validators with 32 ETH are only present as regular validators in one of the 6 committees of the epoch. This situation is generally better than if the smallest validators only are present once every 32 slots, as with the Orbit thresholding mechanism. The Orbit thresholding mechanism can however be adjusted by setting p<1𝑝 <1. In a subsequent post, addressing slow rotation for the available chain, that avenue is intended to be explored further, together with other related consensus issues beyond the scope of this post.\nAllowing 1-ETH validators would further reduce the activity ratio, requiring an increased yield differential. Smaller validator balances such as 1 ETH will thus require a communication effort to explain why these validators receive a markedly lower yield, and why large staking service providers cannot be prevented from relying on 1-ETH validators to lower their risk profile (but certainly nudged in the opposite direction via public discourse).\n9. Conclusion and discussion\nCumulative committee-based finality has been reviewed under fast-rotating validator committees. A good measure for evaluating cumulative finality is the aggregate finality gap \\widetilde{F}_{\\!g}̃𝐹𝑔, which aggregates the finality gap for a block during its progression to full finality. The four main avenues for reducing (improving) \\widetilde{F}_{\\!g}̃𝐹𝑔 are:\n\nadding a few auxiliary committees (around 2-4) beyond those required for all validators to cast one vote in an epoch,\nincluding the largest validators in almost every committee,\nequally spacing auxiliary validators to minimize successive repetitions,\npursuing “circular finality” (repeating epochs over a longer era) and “spiral finality” (constrained shuffling) to mitigate degradation in cumulative finality during shuffling.\n\nFive validator sets were used in the analysis, capturing various levels of Zipfianness. Section 6 made it clear that both insufficient validator consolidation and a higher quantity of stake (keeping the distributions fixed) impede finality, thereby increasing \\widetilde{F}_{\\!g}̃𝐹𝑔. When considering tempering the quantity of stake, one argument has been that it will generate a higher quantity of small validators. Regardless of the merits of this theory, it should be noted that a higher quantity of stake and a large proportion of small validators combines to produce the worst conditions for accruing finality, as shown in Figure 13.\nMethods for dynamically adjusting the number of auxiliary commitees were reviewed. The best method is to simply simulate and evaluate the outcome with the same or one more/less auxiliary committees. This can be done on a reduced validator set to improve performance, if necessary. However, it is not a strict requirements that the number of auxiliary slots should change dynamically. The optimal setting for a given point in time is likely to remain viable for quite a while.\nProperties related to consensus formation are important to keep in mind. As shown in Section 8, the committee rotation ratio R𝑅 falls rather quickly with added auxiliary validators. It would be beneficial to map out more specific requirements on R𝑅 from a consensus perspective going forward, both for the available chain and the finality gadget. Requirements regarding the activity ratio a_r𝑎𝑟 are easier to understand in some respects; a higher ratio is better when considered in isolation, as it reduces tensions and yield differentiation.\nThe assumption of a pure Zipfian staking distribution becomes rather dubious if the range is extended much further. If the minimum staking balance is reduced from 32 ETH to 1 ETH, there will not necessarily be an exponential increase in stakers. One reason is that fixed costs for running a validator eventually surpass yield revenue as the staking balance decreases. For example, when focusing exclusively on fixed costs, if running a 32-ETH validator requires a 1% yield to remain profitable, then running a 1-ETH validator would require a 32% yield. Another point to keep in mind when considering a move to allow for 1-ETH validators is the decreased activity ratio a_r𝑎𝑟 that it would bring. At the same time, allowing users with less capital to become active participants in the consensus process is of course fundamentally valuable and something to strive for.\n\nAppendix A: Zipfian distribution\nA.1 Quantity of stakers under a pure Zipfian distribution\nFor large N𝑁, the harmonic series\n\n1 + \\frac{1}{2} + ... + \\frac{1}{N}\n1+12+...+1𝑁\napproaches \\ln(N)+\\gammaln⁡(𝑁) +𝛾, where \\gamma𝛾 is the Euler–Mascheroni constant, approximately 0.577. The total quantity of stake is\n\nD = 32N(\\ln(N)+\\gamma)\n𝐷=32𝑁(ln⁡(𝑁)+𝛾)\nThe task now is to deduce N𝑁, given a specific D𝐷. Let u = \\ln(N) + \\gamma𝑢 =ln⁡(𝑁) +𝛾. Then N = e^{u - \\gamma}𝑁 =𝑒𝑢−𝛾, and the equation can be rearranged as follows:\n\n\\frac{D}{32}e^\\gamma = u e^{u}\n𝐷32𝑒𝛾=𝑢𝑒𝑢\nUse the definition of the Lambert W function, which gives u = W(z)𝑢 =𝑊(𝑧), where\nz = \\frac{D}{32} e^\\gamma𝑧 =𝐷32𝑒𝛾:\n\nu = W \\left( \\frac{D}{32} e^\\gamma \\right)\n𝑢=𝑊(𝐷32𝑒𝛾)\nRecall that u = \\log(N) + \\gamma𝑢 =log⁡(𝑁) +𝛾. Substituting this in gives\n\n\\log(N) + \\gamma = W \\left( \\frac{D}{32} e^\\gamma \\right),\nlog⁡(𝑁)+𝛾=𝑊(𝐷32𝑒𝛾),\nand thus\n\n\\log(N) = W \\left( \\frac{D}{32} e^\\gamma \\right) - \\gamma.\nlog⁡(𝑁)=𝑊(𝐷32𝑒𝛾)−𝛾.\nBoth sides are finally exponentiated to solve for N𝑁:\n\nN = e^{ W \\left( \\frac{D}{32} e^\\gamma \\right) - \\gamma}\n𝑁=𝑒𝑊(𝐷32𝑒𝛾)−𝛾\nThe equation provides a simple way to deduce N𝑁 given D𝐷, such that the baseline Zipfian distribution in the form of the harmonic series can be used in accordance with the previous specification. The following two lines of Python code generate the staking set S for a specific deposit size, where eg=np.euler_gamma:\nN = round(np.exp(scipy.special.lambertw(D*np.exp(eg)/(32))-eg))\nS = 32*N/np.arange(1, N + 1)\n\nA.2 Quantity of validators under a pure Zipfian distribution\nRecall that the number of stakers is as previously derived\n\nN = e^{ W \\left( \\frac{D}{32} e^\\gamma \\right) - \\gamma}.\n𝑁=𝑒𝑊(𝐷32𝑒𝛾)−𝛾.\nAmong these N𝑁 stakers, 1/64 will have a stake of 2048 or higher:\n\n2048 = \\frac{32N}{N_{h}},\n2048=32𝑁𝑁ℎ,\n\nN_{h} = \\frac{N}{64}.\n𝑁ℎ=𝑁64.\nUnder ideal circumstances, that stake will be divided up into\n\nV_{h} = \\frac{1}{2048}\\sum_{n=1}^{N_h} \\frac{32N}{n} = \\frac{32N}{2048} \\cdot (\\ln(N/64) + \\gamma) = \\frac{N}{64} \\cdot (\\ln(N/64) + \\gamma)\n𝑉ℎ=12048𝑁ℎ∑𝑛=132𝑁𝑛=32𝑁2048⋅(ln⁡(𝑁/64)+𝛾)=𝑁64⋅(ln⁡(𝑁/64)+𝛾)\nvalidators. However, the \\frac{N}{64}𝑁64 stakers will roughly add an expected \\gamma𝛾 validators each to that figure, due to waste when splitting up stake into its last validators (i.e., the cumulative effect of the fractional parts). There are 63N/6463𝑁/64 stakers with less than 2048 ETH. The total number of validators under a pure Zipfian distribution, where stakers maximize consolidation, is thus\n\nV=\\frac{N}{64} \\left(63+\\ln(N/64) + 2\\gamma \\right).\n𝑉=𝑁64(63+ln⁡(𝑁/64)+2𝛾).\nThe equation is a fairly exact approximation. For example, at 30M ETH, the outlined procedure gives 88065 validators, and the equation (after rounding N𝑁 in the first step) gives 88065.385 validators.\nAppendix B: Prediction and evaluation\nB.1 Evaluation procedure\nCumulative finality of a block is simulated by a boolean mask that iterates through the committees, entering every validator seen up to and including a particular slot/committee. Thus, the starting point is a binary mask of all validators in the committee of the first processed slot. The operation then progresses through the slots of the epoch, entering previously unseen validators from a committee to the binary mask applicable to a specific slot. Finalized validators are then summed at each slot, from which D_f𝐷𝑓 and thus \\widetilde{F}_ {\\! g}̃𝐹𝑔 are computed. For best accuracy, the evaluation is performed in a circular fashion, as previously discussed. If S_{\\text{ep}}𝑆ep is high, there can be an upper limit on how many starting points that are evaluated, e.g., starting at every other or every third slot. The evaluation for Section 6 used a limit of ten different starting points.\nA potential optimization is to also compute a separate mask (or list of indices) that specifies only the newly unseen validators for each slot. This mask/list specifies if the validator is present in the current committee AND NOT present in the cumulative finality mask computed up to the previous committee. The benefit is that summation can be done only of the newly added validators, subsequently adding the cumulative sum derived at the previous slot/committee.\nB.2 Weighted aggregate finality gap\nThe aggregate finality gap \\widetilde{F}_ {\\! g}̃𝐹𝑔 generally seems like a well-balanced optimization criterion. Yet in some scenarios, it may be desirable to prioritize high finality in the initial slots (thus also slowing down rotation), while in others, a short time to full finality overall may be preferred (thus also increasing the activity ratio discussed in Section 8.3). A weighted aggregate finality gap can therefore be useful. This post used a weighting that provides a slightly shorter time to full finality on average. This helped resolve edge cases in the log-normal set (Appendix B.4) where the mechanism was brought very close to full finality, but the last fraction of finality took several slots. However, the opposite direction can also be explored, factoring in, for example, requirements concerning rotation speed.\nDefine a scenario where full finality can be achieved in 2 regular slots, but two auxiliary validators are added, as {2|4}. The weighting was designed to affect the following outcomes equally: {2|4}, {4|7}, {10|15} and {21|28}. This weighting for {a𝑎|b𝑏} was:\n\nw = \\frac{b\\sqrt[3]{b-a}}{ka}.\n𝑤=𝑏3√𝑏−𝑎𝑘𝑎.\nThe constant k𝑘 was set to 2^626 and the weight applied to each evaluated number of auxiliary slots. This can be done in two ways: \\widetilde{F}_ {\\! gw} = \\widetilde{F}_ {\\! g}(1+w)̃𝐹𝑔𝑤 =̃𝐹𝑔(1 +𝑤) or \\widetilde{F}_ {\\! gw} = \\widetilde{F}_ {\\! g} \\ +w̃𝐹𝑔𝑤 =̃𝐹𝑔  +𝑤, with the first being used in this work.\nB.3 Interpolated ground truth\nThe ground truth for modeling was not auxiliary committees C_{\\text{aux}}𝐶aux but instead the number of auxiliary validators V_{\\text{aux}}𝑉aux to be added. The main reason why C_{\\text{aux}}𝐶aux is generally undesirable as a ground truth is related to the fin-like pattern in Figures 11-12. The optimal C_{\\text{aux}}𝐶aux will shift at the boundaries where regular committees require one more regular slot, causing the ground truth to oscillate as D𝐷 rises. Targeting auxiliary validators avoids this issue. The total number of committees C𝐶 shown in Figure 14 could have been used as well, but this precludes parabolic interpolation with \\widetilde{F}_ {\\! gw}̃𝐹𝑔𝑤 for the regular committee as one of the interpolation points.\nA remaining issue is that the V_{\\text{aux}}𝑉aux that minimizes \\widetilde{F}_ {\\! gw}̃𝐹𝑔𝑤 is discretized into steps differing by \\hat{V}_ {\\!a}ˆ𝑉𝑎, since the minimum can only be defined at integers in C_ {\\text{aux}}𝐶aux. Define the number of auxiliary committees that minimizes \\widetilde{F}_ {\\! gw}̃𝐹𝑔𝑤 as C^*_{\\text{aux}}𝐶∗aux. Parabolic interpolation was performed across the three neighboring points, \\widetilde{F}_ {\\! gw}(C^*_{\\text{aux}}-1)̃𝐹𝑔𝑤(𝐶∗aux −1), \\widetilde{F}_ {\\! gw}(C^*_{\\text{aux}})̃𝐹𝑔𝑤(𝐶∗aux) and \\widetilde{F}_ {\\! gw}(C^*_{\\text{aux}}+1)̃𝐹𝑔𝑤(𝐶∗aux +1) to derive a relative position:\n\nw_{V} = \\frac{\\widetilde{F}_ {\\! gw}(C^*_{\\text{aux}}+1)-\\widetilde{F}_ {\\! gw}(C^*_{\\text{aux}}-1)}{2(2\\widetilde{F}_ {\\! gw}(C^*_{\\text{aux}}) - \\widetilde{F}_ {\\! gw}(C^*_{\\text{aux}}-1) - \\widetilde{F}_ {\\! gw}(C^*_{\\text{aux}}+1))}.\n𝑤𝑉=̃𝐹𝑔𝑤(𝐶∗aux+1)−̃𝐹𝑔𝑤(𝐶∗aux−1)2(2̃𝐹𝑔𝑤(𝐶∗aux)−̃𝐹𝑔𝑤(𝐶∗aux−1)−̃𝐹𝑔𝑤(𝐶∗aux+1)).\nDefine V_{\\text{aux}}(C^*_{\\text{aux}})𝑉aux(𝐶∗aux) as the number of auxiliary validators at the optimal number of auxiliary committees. The ground truth V^{y}_{\\text{aux}}𝑉𝑦aux is given by the w_{V}𝑤𝑉-weighted average of neighboring values. Thus, if w_{V}<0𝑤𝑉 <0, it becomes\n\nV^{y}_{\\text{aux}}=V_{\\text{aux}}(C^*_{\\text{aux}}-1)(1-w_{V}) + V_{\\text{aux}}(C^*_{\\text{aux}})w_{V},\n𝑉𝑦aux=𝑉aux(𝐶∗aux−1)(1−𝑤𝑉)+𝑉aux(𝐶∗aux)𝑤𝑉,\nwith a corresponding weighting applied if w_{V}>0𝑤𝑉 >0. Predictions for the number of auxiliary validators in Section 7 are correspondigly defined as V^{x}_{\\text{aux}}𝑉𝑥aux.\nB.4 Generation of a log-normal distributed validator set\nTo provide a wider variety of examples of validator sets, an additional set with a log-normal distribution was generated. The mean \\mu_{\\mathcal{V}}𝜇V was first drawn from a normal distribution centered at 400 ETH with a standard ","tokens":15000,"squid":"spider-04","role":"Research Spider","at":1791346057109,"hash":"e8b481c3395c288be59df8bf4c3a927a940b74a4"}
{"url":"https://developers.jup.ag/docs/tokens","domain":"developers.jup.ag","title":"Solana Token API - Jupiter Developers","text":"The Tokens API gives you search, metadata, verification status, and trading metrics for any Solana token. Use it to find tokens, display information to users, and filter by trust level.\n​History\nToken verification on Solana has evolved through several iterations: from the original Solana Token Registry (deprecated 2022), to Jupiter’s community-maintained token lists (V1 via GitHub, V2 via Catdet List), to the current system powered by trading metrics, social signals, and Organic Score. Today, Jupiter VRFD is the latest evolution, expanding beyond verification into token metadata, community content, and insights.\n​What You Get\nFieldDescriptionMetadataName, symbol, icon, decimals, mint addressVerificationVerification level (verified, unverified, banned)Organic Score0-100 score measuring genuine trading activityTrading StatsVolume, price change, buy/sell counts across intervals (5m, 1h, 6h, 24h)Market DataHolder count, market cap, liquidityContentCommunity-submitted text posts, tweets, summaries (deprecated)\n​Verification Levels\nJupiter categorises tokens into trust levels based on trading activity, social presence, and community review:\nLevelMeaningWhen to useVerifiedPassed Jupiter’s verification process. Legitimate project with real activity.Safe to display prominently.UnverifiedNot yet reviewed or doesn’t meet criteria. May still be legitimate.Display with caution indicators.BannedFlagged as malicious, scam, or misleading.Do not display or warn users.\nCheck the isVerified field in the API response. Use audit.isSus as an additional signal for suspicious tokens. audit.isSus is only present when a token has been flagged, so check for the field’s presence rather than its value.\n​Organic Score\nOrganic Score (0-100) measures how genuine a token’s trading activity is, filtering out bots, snipers, and copy-trading tools so you can find the signal within the noise. The system identifies non-organic wallets (those trading through known bot and automation channels) and treats the remaining activity as organic.\nThe score combines four organic signals:\n\nOrganic volume\nOrganic holders\nOrganic traders\nOrganic buyers\n\nA few things to keep in mind when using it:\n\nIt is relative, not absolute. Scores are normalised against the rest of the ecosystem. The score says a token is more organic than another, not that it has a specific amount of organic activity. High-volume tokens like SOL and USDC sit near 100 because differences flatten out at that scale.\nEarly growth counts most. Going from 10 organic buyers to 100 moves the score far more than going from 10,000 to 10,100.\nPrefer the raw score over the label. Each token also has an organicScoreLabel of high, medium, or low, but these buckets are wide: two tokens can both be medium and behave very differently. For filtering, use the raw organicScore.\n\nFor more detail, see How does Jupiter decide if a token is real?.\n​Token Tags\nToken tags are labels applied to tokens for categorisation and discoverability (e.g. verified, lst, stocks, community). Tags appear in the Jupiter UI and are available via the GET /tag endpoint.\nTo get your tokens tagged:\n\nHost a public CSV endpoint with mint addresses (one per row)\nProvide a preferred tag name (short, mobile-friendly)\nSet a polling interval\nReach out via Discord to begin ingestion\n\n​API Reference\n\n​Learn More\n\nToken Information for the full response schema and field reference\nExpress Verification to submit tokens for verification via API\nGet Token Information guide for a step-by-step integration tutorial\nWas this page helpful?","tokens":890,"squid":"spider-02","role":"Liquidity Spider","at":1791346075422,"hash":"2184d3fd43deb82f8e5fbb6f45e19d0549893793"}
{"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":"spider-04","role":"Research Spider","at":1791346085592,"hash":"c16f76b4d4d13a2bc8f6d49ebb1324ac8fd9aad7"}
{"url":"https://consensysdiligence.github.io/smart-contract-best-practices/security-tools/static-and-dynamic-analysis/","domain":"consensysdiligence.github.io","title":"Static and Dynamic Analysis - Ethereum Smart Contract Best Practices","text":"Static and Dynamic Analysis\n\nMythX - MythX is a professional-grade cloud service that uses symbolic\n analysis and input fuzzing to\n detect common security bugs\n and\n verify the correctness of smart contract code.\n Using MythX requires an API key from mythx.io.\nMythril - The Swiss army knife for smart contract\n security.\nSlither - Static analysis framework with detectors for\n many common Solidity issues. It has taint and value tracking capabilities and is written in\n Python.\nContract-Library - Decompiler and security analysis tool for all\n deployed contracts.\nMadMax - Static analysis tool for gas DoS\n vulnerabilities.\nGigahorse - Fast binary lifter and program\n analysis framework written in Datalog.\nEchidna - The only available fuzzer for Ethereum\n software. Uses property testing to generate malicious inputs that break smart contracts.\nManticore - Dynamic binary analysis tool with\n EVM support.\nOyente - Analyze Ethereum code to find common\n vulnerabilities, based on this paper.\nSecurify - Fully automated online static analyzer for\n smart contracts, providing a security report based on vulnerability patterns.\nSmartCheck - Static analysis of Solidity source code for security\n vulnerabilities and best practices.\nOctopus - Security Analysis tool for Blockchain Smart\n Contracts with support of EVM and (e)WASM.\nsFuzz - Efficient fuzzer inspired from AFL to find common\n vulnerabilities.\nVertigo - Mutation Testing for Ethereum Smart Contracts.\nSolidityScan - Vulnerability Scanner for Solidity Smart Contracts with over 200+ exploit and CVEs, misconfigurations, and gas optimization modules.","tokens":402,"squid":"spider-06","role":"Security Spider","at":1791346088912,"hash":"5db2346440ae14b3e6bcec12a6ae58c5828973ff"}
{"url":"https://verified.jup.ag/","domain":"verified.jup.ag","title":"Home | VRFD","text":"One verified layer for every Solana token.Onchain data, AI signals, and community review distilled into a single, human-reviewed data layer that wallets, DEXs, and apps across Solana already plug into./Tokens updatedContributors$MEOWMEOWjup1ZDtGV7n4s…c8Nk verifiedMINTMEOWjup…c8NkverifiedSHIELDLow riskreal-timeSMART LIKES1,247 likessocialMETADATAUp to datereviewedLive activity09:41OPENNew verification request09:42AUTOAutomated checks triggered/ 01Open contributionIf you care about a token, you can fix its data here.Bad metadata, missing socials, imposter mints, you've seen it and had no way to fix it. With VRFD Open, anyone can submit tokens for verification, update metadata, or flag bad data.Every submission is publicly reviewed before it enters the verified data layer that wallets, DEXs, and apps across Solana already build on.ExampleToken nameMint addressEvidence@Cat420submitting/ 02Multiple signalsOne list was never going to verify all of Solana.Tens of thousands of tokens launch daily. VRFD gives you multiple signals so you can see the full picture without waiting on one team's call.Examples →✓ VerifiedJup Shield · LOW LIQUIDITYJup Shield · NOT SELLABLEJup Shield · LOW ORGANIC ACTIVITYJup Shield · 5% TRANSFER FEESHigh ecosystem trustIs this the right address?Get a green checkmark. Prevent imposters from spoofing your token with a mint that reviewers have personally confirmed.✓7xKXtg2CW87d97...KoVerified!7xKXtg2CW97d97...LoImpersonator…7xKXtg2CW77d97...MoPending Team reviewedIs it safe to trade?Risk warnings updated in real time from onchain data including holder concentration, liquidity issues, freeze authority, and other red flags.Onchain risk scanLowLiquidity · okHolders · okFreeze auth · revokedLiquidity poolHealthyHolder distributionHealthyFreeze authorityRevokedMint authorityRevokedTransfer feesNone Auto-updated 5s agoDoes the ecosystem trust it?See ecosystem support at a glance with Smart Likes - endorsements from Smart Followers, a dynamically updated list of verified humans and known ecosystem participants.Ecosystem signal1,247smart likesLiked by♥@toly♥@meow♥@kashdhanda♥@9yointern♥@0xlegit+1,242 moreDerived from verified X accounts./ 03The ecosystem token APIOne API. Trusted everywhere.VRFD data is available through APIs, and already in use by wallets, DEXs, and launchpads across the ecosystem.API docs →vrfd.example// Search for any Solana token\nconst res = await fetch(\n \"https://api.jup.ag/tokens/v2/search?query=SOL\",\n { headers: { \"x-api-key\": API_KEY } }\n)\n\nconst [token] = await res.json()\n\ntoken.id // \"So1111…1112\"\ntoken.symbol // \"SOL\"\ntoken.isVerified // true\ntoken.usdPrice // 145.47\ntoken.liquidity // 89970631\ntoken.organicScore // 98.9\ntoken.audit // { mintAuthorityDisabled: true, … }Review a token today.","tokens":694,"squid":"spider-02","role":"Liquidity Spider","at":1791346092723,"hash":"94d4d671f432c850db87425751657e5c2cbfb4a6"}
{"url":"https://www.metaplex.com/docs/solana/validators","domain":"metaplex.com","title":"Validators and Staking | Guides","text":"OverviewValidators are responsible for processing transactions, generating new blocks, and validating the state of the blockchain to ensure accuracy and prevent double-spending. They participate in the consensus mechanism by voting on the legitimacy of blocks proposed by other validators, which helps to maintain the integrity and security of the network. Validators also contribute to the network's decentralization by staking their SOL tokens, which aligns their incentives with the network's health and stability.Validators often participate in governance decisions, providing insights and voting on proposals that affect the network's future. Many validators also contribute to the community by offering educational resources, running community nodes, and supporting the development of decentralized applications (dApps) and tools that enhance the ecosystem.Solana's Validator NetworkProof of Stake and Proof of HistorySolana uses a unique combination of Proof of Stake (PoS) and Proof of History (PoH) consensus mechanisms:Proof of Stake: Validators must stake SOL tokens to participate in consensus. The amount staked influences their voting weight and potential rewards.Proof of History: A cryptographic clock that provides a historical record of events, allowing validators to agree on the timing of events without requiring communication.This hybrid approach enables Solana to achieve high transaction throughput (up to 65,000 TPS) and low latency (400ms block times).Validator EconomicsValidators earn rewards through:Transaction Fees: A portion of transaction fees paid by usersInflation Rewards: New SOL tokens distributed to validators and delegatorsMEV (Maximal Extractable Value): Additional value that can be extracted by influencing transaction orderingStaking on SolanaStaking MechanicsStaking on Solana can be done in two primary ways:Direct Staking (Validator): Running a validator node and staking your own SOLDelegation (Delegator): Delegating your SOL to an existing validator without running a node yourselfDelegation ProcessTo delegate SOL to a validator:Choose a validator based on performance, commission rate, and reliabilityCreate a stake account using a compatible wallet (Phantom, Solflare, etc.)Delegate SOL to your chosen validatorMonitor your staking rewards, which are automatically compoundedStake Activation and DeactivationActivation: When you delegate SOL, it takes approximately 2-3 epochs (2-3 days) for your stake to become active and start earning rewardsDeactivation: When you decide to undelegate, it takes approximately 2-3 epochs before your SOL becomes fully liquid againChoosing a ValidatorConsider these factors when selecting a validator:Performance: Uptime and block production historyCommission: The percentage of rewards the validator keeps (typically 5-10%)Total Stake: Higher stake may indicate trust but also contributes to centralizationDecentralization Impact: Consider supporting smaller validators to enhance network decentralizationTools and ResourcesStaking ToolsSolana Beach - Explorer and validator statisticsValidators.app - Detailed validator performance metricsStakeview.app - Validator ranking and comparisonWallets Supporting StakingPhantomSolflareLedgerMath WalletCommon TermsEpoch: A time period in Solana (approximately 2-3 days) during which validator performance is measured and rewards are distributedCommission: The percentage of staking rewards that validators charge delegators for their servicesSlashing: A penalty for validator misbehavior, currently not implemented on SolanaVote Account: An account that validators use to participate in consensus by voting on blocksStake Account: An account that holds delegated SOL tokens","tokens":927,"squid":"dotcat","role":"Tooling Spider","at":1791346099927,"hash":"617fce684dcd127e63e69b8a935db5701d44fda3"}
{"url":"https://verified.jup.ag/media","domain":"verified.jup.ag","title":"Media | VRFD","text":"MediaShort animated explainers and deep-dive reads on the open, human-reviewed data layer behind every Solana token.Watch the filmsFollow @Jup_VRFDWatchAnimated explainersBite-sized films on how Solana token data gets verified, updated, and distributed.Verify to keep imposters awayOne verification layer powers Solana's major wallets, DEXs, and launchpads.Update metadata as you evolveBroadcast your project's changes to every site integrating Jupiter's Token API.Anyone can contributeDon't wait for someone else to fix your token. Flag bad data, verify, and add metadata yourself.ReadArticles & deep divesLong-form writing on the verified data layer and how it came together.BlogFrom a GitHub repo to VRFD V1AcademyBringing Order to Solana's Token Layer with VRFD","tokens":191,"squid":"spider-02","role":"Liquidity Spider","at":1791346103410,"hash":"89b8351aab2857b711fdc867ecdd8b5458fa64fb"}
{"url":"https://www.metaplex.com/docs/en/smart-contracts/token-metadata/guides/anchor/token-claimer-smart-contract","domain":"metaplex.com","title":"How to Create a Token Claimer Smart Contract | Token Metadata Guides","text":"Token Metadata is a legacy program. It remains supported, but is not recommended for new projects. Use Core instead.This guide leverages the use of Merkle Trees and Compression to create a low-cost Token Claimer for Token Metadata Tokens using Anchor.PrerequisiteBefore starting to learn more about how the Token Claimer works, we should look into how Compression and Merkle Trees work to really understand what is going on inside of the smart contract.Merkle TreesA Merkle tree is a binary tree used to efficiently represent a set of data. Each leaf node in the tree is a hash of individual data (e.g., an address and token amount). Parent nodes are created by hashing pairs of child nodes, continuing up the tree until reaching the root, which serves as a compact and tamper-proof representation of the entire dataset.Example: Suppose we have four data entries: A, B, C, and D. The Merkle tree structure is built as follows:Leaf Nodes: Each entry is hashed:Hash(A), Hash(B), Hash(C), Hash(D)\nParent Nodes: Pairs of leaf nodes are combined and hashed:Parent1 = Hash(Hash(A) + Hash(B))\nParent2 = Hash(Hash(C) + Hash(D))\nRoot Node: The final hash is computed from the parent nodes:Root = Hash(Parent1 + Parent2)\nHashRoot NodeHashNode 1HashNode 2Node 3Node 4HashNode 5Node 6Leaf 1Leaf 2Leaf 3Leaf 4Leaf 5Leaf 6Leaf 7Leaf 8NFT DataLeaf 4Node 3Node 2ProofReact FlowPress enter or space to select a node.You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel. Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.Merkle trees are a cornerstone of on-chain compression, enabling efficient and secure data verification. By design, altering any part of the dataset invalidates the root, which means the integrity of a specific entry can be verified by storing only the Merkle root on-chain and providing a Merkle Proof—a minimal set of sibling hashes needed to reconstruct the root.Key Advantages: Cost-Efficient Storage: Only the Merkle root (32 bytes) is stored on-chain, significantly reducing storage costs. Verification is achieved by passing Merkle proofs as inputs.Scalability: Proof sizes grow logarithmically with the number of entries, making this method ideal for managing large datasets.Privacy and Efficiency: Entire Merkle trees can be generated and managed off-chain, keeping the full dataset private. Programs like Compressed NFTs use this approach with Solana’s noop program, optimizing performance while maintaining privacy.Concurrent Merkle TreeSolana's state compression employs a unique type of Merkle tree that enables multiple changes to a tree while preserving its integrity and validity.This specialized tree, called a concurrent Merkle tree, maintains an on-chain changelog, allowing multiple rapid updates to the same tree (e.g., all within the same block) without invalidating proofs.This functionality is essential on Solana where only one writer per block is allowed per account. This limites updates to a single change per block, so the runtime can ensure the account's security and prevents corruption. Since every action requires writing, concurrent Merkle tree offers an efficient solution for managing multiple updates within the same block seamlessly.SetupCode Editor of your choice (recommended Visual Studio Code with the Rust Analyzer Plugin)Anchor 0.30.1 or above.Additionally, in this guide we’re going to leverage a mono-file approach to Anchor where all the necessary macros can be found in the lib.rs file:declare_id: Specifies the program's on-chain address.#[program]: Specifies the module containing the program’s instruction logic.#[derive(Accounts)]: Applied to structs to indicate a list of accounts required for an instruction.#[account]: Applied to structs to create custom account types specific to the program.Note: You may need to modify and move functions around to suit your needs.Initializing the ProgramStart by initializing a new project (optional) using avm (Anchor Version Manager). To initialize it, run the following command in your terminalanchor init token-claimer-example\nRequired CratesIn this guide, we'll use the svm_merkle_tree crate an optimized version for creating and managing merkle trees for the SVM. To install it, first navigate to the token-claimer-example directory:cd token-claimer-example\nThen run the following command to install the merkle tree crate:cargo add svm-merkle-tree --git https://github.com/deanmlittle/svm-merkle-tree\nAnd then we run the following command to install the anchor-spl to interact with the Token Program:cargo add anchor-spl\nThe programThis example is not a full-fledged implementation suitable for production. To make it production-ready, several additional components and considerations are necessary:Event Emission: Use the event!() macro to emit events for important actions, such as successful claims or updates to the Merkle root. Alternatively, you can integrate with Solana's noop program to log updates and facilitate data indexing for off-chain applications.Database Hosting: You'll need to store and host the complete Merkle tree dataset off-chain and derive hashes for leaves and internal nodes other than generate and serve Merkle proofs dynamically and validate input consistency for claims.Imports and TemplatesHere we're going to define all the imports for this particular guide and create the template for the Account struct and instruction in our lib.rs file.use anchor_lang::prelude::*;\n\nuse anchor_spl::associated_token::AssociatedToken;\nuse anchor_spl::token::{mint_to, set_authority, transfer, Mint, MintTo, SetAuthority, Token, TokenAccount, Transfer, spl_token::instruction::AuthorityType}\n\nuse svm_merkle_tree::{HashingAlgorithm, MerkleProof};\n\ndeclare_id!(\"C9PLf3qMCVqtUCJtEBy8NCcseNp3KTZwFJxAtDdN1bto\");\n\n/// Instructions and Logic behind the program\n#[program]\npub mod merkle_tree_token_claimer {\n use super::*;\n\n pub fn initialize_airdrop_data(\n ctx: Context<Initialize>, \n merkle_root: [u8; 32],\n amount: u64,\n ) -> Result<()> {\n\n Ok(())\n }\n\n pub fn update_tree(\n ctx: Context<Update>, \n new_root: [u8; 32]\n ) -> Result<()> {\n\n Ok(())\n }\n\n pub fn claim_airdrop(\n ctx: Context<Claim>,\n amount: u64,\n hashes: Vec<u8>,\n index: u64,\n ) -> Result<()> { \n\n Ok(())\n }\n\n}\n\n/// Account Struct for the different Instructions\n#[derive(Accounts)]\npub struct Initialize<'info> {\n\n}\n\n#[derive(Accounts)]\npub struct Update<'info> {\n\n}\n\n#[derive(Accounts)]\npub struct Claim<'info> {\n\n}\n\n/// State account holding the merkle tree and airdrop information\n#[account]\npub struct AirdropState {\n\n}\n\n/// Error for the Program\n#[error_code]\npub enum AirdropError {\n\n}\nThis serves as the template for the on-chain program, however, there is also significant frontend overhead to consider which we’ll address in detail in this writeup.Initializing the Merkle TreeWe begin by initializing a Merkle tree with user data, including their claimable amounts. This process is performed off-chain, where we calculate the tree's root and later upload it on-chain, reducing computational costs while maintaining integrity.In this example, we generate 100 random addresses and 100 random amounts, and initialize an isClaimed flag for each entry, setting it to false. These details are serialized into binary format to efficiently populate the Merkle tree and we then merklize the data we just created to create the root.import * as anchor from \"@coral-xyz/anchor\";\nimport { Keypair, PublicKey, SystemProgram, LAMPORTS_PER_SOL, Transaction } from \"@solana/web3.js\";\nimport { HashingAlgorithm, MerkleTree } from \"svm-merkle-tree\";\n\n// Generate 100 random addresses and amount\nlet merkleTreeData = Array.from({ length: 100 }, () => ({\n address: Keypair.generate().publicKey, // Example random address\n amount: Math.floor(Math.random() * 1000), // Example random amount\n isClaimed: false, // Default value for isClaimed\n}));\n\n// Create Merkle Tree\nlet merkleTree = new MerkleTree(HashingAlgorithm.Keccak, 32);\n\nmerkleTreeData.forEach((entry) => {\n // Serialize address, amount, and isClaimed in binary format\n const entryBytes = Buffer.concat([\n entry.address.toBuffer(),\n Buffer.from(new Uint8Array(new anchor.BN(entry.amount).toArray('le', 8))),\n Buffer.from([entry.isClaimed ? 1 : 0]),\n ]);\n merkleTree.add_leaf(entryBytes);\n});\n\nmerkleTree.merklize();\n\nconst merkleRoot = Array.from(merkleTree.get_merkle_root());\nOn-chain, we define an AirdropState account to manage and track the state of the airdrop. This account holds key information needed to securely distribute tokens based on the Merkle tree mechanism. Below is the breakdown of each field:#[account]\npub struct AirdropState {\n /// The current merkle root\n pub merkle_root: [u8; 32],\n /// The authority who can update the merkle root\n pub authority: Pubkey,\n /// The mint address of the token being airdropped\n pub mint: Pubkey,\n /// Total amount allocated for the airdrop\n pub airdrop_amount: u64,\n /// Total amount claimed so far\n pub amount_claimed: u64,\n /// PDA bump seed\n pub bump: u8,\n}\nThe initialize_airdrop_data instruction will just populate the AirdropState and, before revoking the mint_authority, mint enough tokens in the vaultpub fn initialize_airdrop_data(\n ctx: Context<Initialize>, \n merkle_root: [u8; 32],\n amount: u64,\n) -> Result<()> {\n\n ctx.accounts.airdrop_state.set_inner(\n AirdropState {\n merkle_root,\n authority: ctx.accounts.authority.key(),\n mint: ctx.accounts.mint.key(),\n airdrop_amount: amount,\n amount_claimed: 0,\n bump: ctx.bumps.airdrop_state,\n }\n );\n\n mint_to(\n CpiContext::new(\n ctx.accounts.token_program.to_account_info(), \n MintTo {\n mint: ctx.accounts.mint.to_account_info(),\n to: ctx.accounts.vault.to_account_info(),\n authority: ctx.accounts.authority.to_account_info(),\n }\n ),\n amount\n )?;\n\n set_authority(\n CpiContext::new(\n ctx.accounts.token_program.to_account_info(), \n SetAuthority {\n current_authority: ctx.accounts.authority.to_account_info(),\n account_or_mint: ctx.accounts.mint.to_account_info(),\n }\n ), \n AuthorityType::MintTokens,\n None\n )?;\n\n Ok(())\n}\n\n#[derive(Accounts)]\npub struct Initialize<'info> {\n #[account(\n init, \n seeds = [b\"merkle_tree\".as_ref(), mint.key().to_bytes().as_ref()],\n bump,\n payer = authority, \n space = 8 + 32 + 32 + 32 + 8 + 8 + 1\n )]\n pub airdrop_state: Account<'info, AirdropState>,\n #[account(mut)]\n pub mint: Account<'info, Mint>,\n #[account(\n init_if_needed,\n payer = authority,\n associated_token::mint = mint,\n associated_token::authority = airdrop_state,\n )]\n pub vault: Account<'info, TokenAccount>,\n #[account(mut)]\n pub authority: Signer<'info>,\n pub system_program: Program<'info, System>,\n pub token_program: Program<'info, Token>,\n pub associated_token_program: Program<'info, AssociatedToken>,\n}\nUpdate the Merkle Root onchain if neededWe're going to create the update_tree instruction that will let the authority of the AirdropState change the root onchain. This can be used to add a new user or to revoke allocation.For this example we're going to create a new random allocation for a random address and push this entry in the Merkle Tree we created in the last instruction, like this:const newData = {\n address: Keypair.generate().publicKey,\n amount: Math.floor(Math.random() * 1000), // Example random amount\n isClaimed: false, // Default value for isClaimed\n};\n\nmerkleTreeData.push(newData); \n\nconst entryBytes = Buffer.concat([\n newData.address.toBuffer(), // PublicKey as bytes\n Buffer.from(new Uint8Array(new anchor.BN(newData.amount).toArray('le', 8))), // Amount as little-endian\n Buffer.from([newData.isClaimed ? 1 : 0]), // isClaimed as 1 byte\n]);\n\nmerkleTree.add_leaf(entryBytes);\n\nmerkleTree.merklize();\n\nconst newMerkleRoot = Array.from(merkleTree.get_merkle_root());\nWe can easily update the root this way then:pub fn update_tree(\n ctx: Context<Update>, \n new_root: [u8; 32]\n) -> Result<()> {\n\n ctx.accounts.airdrop_state.merkle_root = new_root;\n\n Ok(())\n}\n\n#[derive(Accounts)]\npub struct Update<'info> {\n #[account(\n mut, \n has_one = authority,\n seeds = [b\"merkle_tree\".as_ref(), airdrop_state.mint.key().to_bytes().as_ref()],\n bump = airdrop_state.bump\n )]\n pub airdrop_state: Account<'info, AirdropState>,\n pub authority: Signer<'info>,\n}\nWe verify that this change is \"safe\" because we check the authority provided against the authority saved in the AirdropState using the has_one constrain.Claiming instruction for the UserWhen a user claims tokens, their eligibility is verified using the Merkle Tree Root stored on-chain.Step 1: Generate Merkle Proof:The system locates the user’s data in the external Merkle Tree database, generated from the previous examples, and generates the Merkle Proof. This proof includes the hashes of sibling nodes along the path to the user’s leaf and the index, enabling the verification process, like this:const index = merkleTreeData.findIndex(data => data.address.equals(newAddress.publicKey));\n\nif (index === -1) {\n throw new Error(\"Address not found in Merkle tree data\");\n}\n\nconst proof = merkleTree.merkle_proof_index(index);\nconst proofArray = Buffer.from(proof.get_pairing_hashes());\nStep 2: On-Chain VerificationUsing the user’s submitted data, the generated Merkle Proof, and the data’s index, the system reconstructs the Merkle Root on-chain. The reconstructed root is then compared to the stored root to ensure the claim is valid and the Merkle Tree's integrity is preserved.pub fn claim_airdrop(\n ctx: Context<Claim>,\n amount: u64,\n hashes: Vec<u8>,\n index: u64,\n) -> Result<()> { \n let airdrop_state = &mut ctx.accounts.airdrop_state;\n\n // Step 1: Verify that the Signer and Amount are right by computing the original leaf\n let mut original_leaf = Vec::new();\n original_leaf.extend_from_slice(&ctx.accounts.signer.key().to_bytes());\n original_leaf.extend_from_slice(&amount.to_le_bytes());\n original_leaf.push(0u8); // isClaimed = false\n\n // Step 2: Verify the Merkle proof against the on-chain root\n let merkle_proof = MerkleProof::new(\n HashingAlgorithm::Keccak,\n 32,\n index as u32,\n hashes.clone(),\n );\n\n let computed_root = merkle_proof\n .merklize(&original_leaf)\n .map_err(|_| AirdropError::InvalidProof)?;\n\n require!(\n computed_root.eq(&airdrop_state.merkle_root),\n AirdropError::InvalidProof\n );\n\n // Step 3: Execute the transfer\n let mint_key = ctx.accounts.mint.key().to_bytes();\n\n let signer_seeds = &[\n b\"merkle_tree\".as_ref(),\n mint_key.as_ref(),\n &[airdrop_state.bump],\n ];\n\n transfer(\n CpiContext::new_with_signer(\n ctx.accounts.token_program.to_account_info(),\n Transfer {\n from: ctx.accounts.vault.to_account_info(),\n to: ctx.accounts.signer_ata.to_account_info(),\n authority: airdrop_state.to_account_info(),\n },\n &[signer_seeds],\n ),\n amount,\n )?;\n\n Ok(())\n}\n\n#[derive(Accounts)]\npub struct Claim<'info> {\n #[account(\n mut,\n has_one = mint,\n seeds = [b\"merkle_tree\".as_ref(), mint.key().to_bytes().as_ref()],\n bump = airdrop_state.bump\n )]\n pub airdrop_state: Account<'info, AirdropState>,\n pub mint: Account<'info, Mint>,\n #[account(\n mut,\n associated_token::mint = mint,\n associated_token::authority = airdrop_state,\n )]\n pub vault: Account<'info, TokenAccount>,\n #[account(\n init_if_needed,\n payer = signer,\n associated_token::mint = mint,\n associated_token::authority = signer,\n )]\n pub signer_ata: Account<'info, TokenAccount>,\n #[account(mut)]\n pub signer: Signer<'info>,\n pub system_program: Program<'info, System>,\n pub token_program: Program<'info, Token>,\n pub associated_token_program: Program<'info, AssociatedToken>,\n}\nTo ensure accuracy, the root is reconstructed from the input provided in the accounts struct and compared against the stored root on-chain to verify they match.Step 3: ClaimingFor simplicity in this example, we won’t implement concurrency. Instead, we present two possible approaches to handle claims:Set the isClaimed flag to true and recompute the Merkle Root on-chain. The main drawback of this approach is that the account will be locked during the update, as explained in theConcurrent Merkle Tree section. This limits claims to one user per block and can be implemented in the same instruction like this after the transfer:Create a Program Derived Address (PDA) for each user after they claim their tokens. This method avoids locking the AirdropState account, but it requires users to pay rent for the new PDA. This can be implemented in the same instruction, we will just need to change the Account struct like this:Note: The user_receipt account can be left empty to reduce rent costs. To further optimize, you can save bytes on the discriminator by assigning the account to the program and passing it as an UncheckedAccount. A require() can then be used to verify ownership of the account, and you would need to add the assign instruction from the system program to assign it to the right program.Full Example CodeHere is the complete example of the Smart Contract for updating the root on-chain after a claim:And here is the corresponding test.ts file with code to implement and test the Merkle tree:","tokens":4244,"squid":"spider-10","role":"Tooling Spider","at":1791346111653,"hash":"dd26749afb9902bfe836c0b88bc99d983cfcd6e8"}
{"url":"https://verified.jup.ag/apis","domain":"verified.jup.ag","title":"API | VRFD","text":"Build on VRFD token data.The APIs trusted across wallets, dexes, and apps. Also available in agent skills and CLI.Token DataSearch tokens, get metadata, verification status, and trading stats for any Solana token.# Search by symbol, name, or mint\n$ curl https://api.jup.ag/tokens/v2/search?query=SOL \\\n -H \"x-api-key: $API_KEY\"\n\n# Response\n[{ \"id\": \"So1111…1112\", \"symbol\": \"SOL\", \"isVerified\": true, \"usdPrice\": 145.47, ... }]View API docs Express VerificationTwo-step flow: craft a transaction, sign it, and submit. Fully programmatic.GET · Craft TransactionBuild the verification transaction$ curl https://api.jup.ag/tokens/v2/verify/express/craft-txn \\\n -H \"x-api-key: $API_KEY\"\n\n# Response\n{ \"transaction\": \"AQABAv...\", \"requestId\": \"req_8f3a…\", \"feeUsdAmount\": 12.40, ... }POST · ExecuteSubmit the signed transaction$ curl -X POST https://api.jup.ag/tokens/v2/verify/express/execute \\\n -H \"x-api-key: $API_KEY\" \\\n -d '{\n \"transaction\": \"AQABAv...\",\n \"requestId\": \"req_8f3a…\",\n \"tokenId\": \"JUPyiwr…vCN\",\n \"twitterHandle\": \"@JupiterExchange\",\n \"description\": \"Liquidity aggregator on Solana\"\n }'\n\n# Response\n{ \"status\": \"Success\", \"signature\": \"5UfDuX…\", ... }Agent SkillDrop into any LLM that supports skills.$ npx skills add jup-ag/agent-skills \\\n --skill \"jupiter-vrfd\"View skillCLISubmit verifications from your terminal.jup vrfd submit --token <mint-address> \\\n --project-twitter @projecthandle \\\n --description \"DeFi protocol on Solana\"View CLIView API docs","tokens":367,"squid":"spider-02","role":"Liquidity Spider","at":1791346113521,"hash":"1f0049a6ea62e97421980ebfdb716b5728fb4ef8"}
{"url":"https://developers.jup.ag/docs/tokens/token-information","domain":"developers.jup.ag","title":"Token Information - Jupiter Developers","text":"USEFUL MINT INFORMATION\nToken Metadata like name, symbol, icon to display token information to users\nOrganic Score, Holder count, Market cap, etc can be useful to help make a better trading decision\nAnd much more!\nDo note that the response is subject to changes as we continue to improve.Refer to Tokens API V2 Reference for full schema.\n​Query by Mint\nThe Tokens API V2 provides an endpoint to search tokens in the background for you and returns you the search results, along with the mint information.\nThis is useful in most user applications, as users need to choose which tokens they want to swap. This also provides a seamless developer experience as integrating this allows us to handle and abstract the token search mechanism, allowing you to focus on other user features.\nSEARCH\nSearch for a token and its information by its symbol, name or mint address.\nComma-separate to search for multiple.\nLimit to 100 mint addresses in query.\nDefault to 20 mints in response when searching via symbol or name.\n\nconst searchResponse = await (\n await fetch(`https://api.jup.ag/tokens/v2/search?query=So11111111111111111111111111111111111111112`,\n {\n headers: {\n 'x-api-key': 'your-api-key',\n },\n }\n )\n).json();\n\nTo resolve a batch of known mints, comma-separate up to 100 mint addresses in a single query. This returns all of their mint information in one request, so you do not need to issue a separate request per mint.\nconst mints = [\n 'So11111111111111111111111111111111111111112',\n 'EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v',\n];\n\nconst searchResponse = await (\n await fetch(`https://api.jup.ag/tokens/v2/search?query=${mints.join(',')}`,\n {\n headers: {\n 'x-api-key': 'your-api-key',\n },\n }\n )\n).json();\n\n​Query by Tag\nThe Tokens API V2 provides an endpoint to query by tags. This is useful to help users distinguish between verified vs non-verified or specific groups of tokens like liquid-staked tokens (LSTs) or tokenized stocks.\nTAGS\nSupported tags: lst, verified, stocks.\nstocks returns tokenized equities (e.g. Ondo, Remora).\nNote that this will return the entire array of existing mints that belongs to the tag.\n\nconst tagResponse = await (\n await fetch(`https://api.jup.ag/tokens/v2/tag?query=verified`,\n {\n headers: {\n 'x-api-key': 'your-api-key',\n },\n }\n )\n).json();\n\n​Get Category\nThe Tokens API V2 provides an endpoint to get mints and their mint information by categories. These categories are useful for identifying tokens in specific trading scenarios, providing users with more information to trade with.\nCATEGORY\nOnly toporganicscore, toptraded or toptrending category.\nAdded query by interval for more accuracy, using 5m, 1h, 6h, 24h.\nThe result filters out generic top tokens like SOL, USDC, etc (since those tokens are likely always top of the categories).\nDefault to 50 mints in response (use limit to increase or decrease number of results).\n\nconst categoryResponse = await (\n await fetch(`https://api.jup.ag/tokens/v2/toporganicscore/5m?limit=100`,\n {\n headers: {\n 'x-api-key': 'your-api-key',\n },\n }\n )\n).json();\n\n​Get Recent\nThe Tokens API V2 provides an endpoint to get mints and their mint information by their recency. This is helpful to display to users a list of tokens that just had their first pool created, providing more information to trade with.\nRECENT\nDo note that the definition of RECENT is the token’s first pool creation time (and not token’s mint/creation timestamp).\nDefault to 30 mints in response.\n\nconst recentResponse = await (\n await fetch(`https://api.jup.ag/tokens/v2/recent`,\n {\n headers: {\n 'x-api-key': 'your-api-key',\n },\n }\n )\n).json();\n\n​Example Response\nAll endpoints will return an array of mints, along with their information.\nSuccessful example response:\n[\n {\n id: 'So11111111111111111111111111111111111111112',\n name: 'Wrapped SOL',\n symbol: 'SOL',\n icon: 'https://raw.githubusercontent.com/solana-labs/token-list/main/assets/mainnet/So11111111111111111111111111111111111111112/logo.png',\n decimals: 9,\n circSupply: 531207433.3986673,\n totalSupply: 603724547.3627878,\n tokenProgram: 'TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA',\n firstPool: {\n id: '58oQChx4yWmvKdwLLZzBi4ChoCc2fqCUWBkwMihLYQo2',\n createdAt: '2021-03-29T10:05:48Z'\n },\n holderCount: 2342610,\n audit: {\n mintAuthorityDisabled: true,\n freezeAuthorityDisabled: true,\n topHoldersPercentage: 1.2422471238911812 // 0-100 scale: 1.24%, not a 0-1 fraction\n },\n organicScore: 98.92390784896082,\n organicScoreLabel: 'high',\n isVerified: true,\n tags: [ 'community', 'strict', 'verified' ],\n fdv: 87824499429.22047,\n mcap: 77275352037.79674,\n usdPrice: 145.47114211747515,\n priceBlockId: 349038717,\n liquidity: 89970631.83880953,\n stats5m: {\n priceChange: 0.021175445311831707,\n liquidityChange: -0.01230267453174984,\n volumeChange: 4.855149318222242,\n buyVolume: 14644327.188370818,\n sellVolume: 14743625.023908526,\n buyOrganicVolume: 269570.2345543641,\n sellOrganicVolume: 204114.37436445671,\n numBuys: 49281,\n numSells: 54483,\n numTraders: 18155,\n numOrganicBuyers: 981,\n numNetBuyers: 3503\n },\n stats1h: {\n priceChange: -0.145099593531635,\n liquidityChange: -0.13450589635262783,\n volumeChange: -15.928930753985316,\n buyVolume: 171520842.22567528,\n sellVolume: 174057197.5207193,\n buyOrganicVolume: 3099405.8562825476,\n sellOrganicVolume: 2975660.0383528043,\n numBuys: 586069,\n numSells: 649275,\n numTraders: 78145,\n numOrganicBuyers: 2716,\n numNetBuyers: 14442\n },\n stats6h: {\n priceChange: 0.3790495974473589,\n liquidityChange: 0.1659230330014905,\n volumeChange: 14.571340846647542,\n buyVolume: 1084625651.9256022,\n sellVolume: 1094488293.656417,\n buyOrganicVolume: 31145072.655369382,\n sellOrganicVolume: 31647431.25353508,\n numBuys: 3789847,\n numSells: 4363909,\n numTraders: 272131,\n numOrganicBuyers: 10849,\n numNetBuyers: 37155\n },\n stats24h: {\n priceChange: 1.5076363979360274,\n liquidityChange: 2.417364079880319,\n volumeChange: -2.1516094834673254,\n buyVolume: 4273248565.256824,\n sellVolume: 4306065610.69747,\n buyOrganicVolume: 109007133.8196669,\n sellOrganicVolume: 118085567.17983335,\n numBuys: 15125444,\n numSells: 17582713,\n numTraders: 754618,\n numOrganicBuyers: 28590,\n numNetBuyers: 80961\n },\n updatedAt: '2025-06-25T05:02:21.034234634Z'\n }\n]\nWas this page helpful?","tokens":1552,"squid":"spider-02","role":"Liquidity Spider","at":1791346125886,"hash":"247aa9ee272900e190668abfd353b214ce5911be"}
{"url":"https://www.metaplex.com/docs/solana/solana-cli-essentials","domain":"metaplex.com","title":"Solana CLI Essentials | Solana Development Guide","text":"A guide to the essential Solana command-line interface (CLI) commands you'll need for development. What You'll LearnHow to install and configure the Solana CLIEssential commands for daily developmentHow to switch between clusters (devnet, testnet, mainnet)When to use Solana CLI vs MPLX CLIPrerequisitesBasic command-line familiarityNode.js 16+ installed (for MPLX CLI). If you do not have it yet follow your operating system specific guide on the Node.js Download Page.InstallationSolana CLIInstall the Solana CLI tools using the official installer.Installation Commandssh -c \"$(curl -sSfL https://release.anza.xyz/stable/install)\"\nAfter installation, restart your terminal and verify:solana --version\nMPLX CLI (Recommended for Metaplex Operations)For Metaplex-specific operations like creating tokens with metadata, NFTs, and Candy Machines, the MPLX CLI provides a streamlined experience with interactive wizards. This requires you to have npm/node installed. If you do not have it yet follow your operating system specific guide on the Node.js Download Page.npm install -g @metaplex-foundation/cli\nmplx --version\nWhen to Use Which CLITaskRecommended CLIGrinding keypairsSolana CLICheck balancesEither (MPLX: mplx toolbox sol-balance)Transfer SOLEither (MPLX: mplx toolbox sol-transfer)Airdrop devnet SOLEither (MPLX: mplx toolbox sol-airdrop)Create tokens with metadataMPLX CLI (mplx toolbox token-create)Create NFTs/CollectionsMPLX CLI (mplx core create-asset)Candy Machine operationsMPLX CLI (mplx cm)Deploy custom programsSolana CLILow-level transactionsSolana CLIConfigurationView Current Configurationsolana config get\nThis displays your current settings including:Config File - Location of your config fileRPC URL - The cluster you're connected toWebSocket URL - For subscription-based updatesKeypair Path - Your default wallet locationSet Your WalletPoint the CLI to your keypair file:solana config set --keypair ~/.config/solana/id.json\nOr use a specific keypair:solana config set --keypair /path/to/my-wallet.json\nSwitch ClustersChange which Solana network you're connected to:# Devnet (for development and testing)\nsolana config set --url devnet\n\n# Testnet (for testing with more realistic conditions)\nsolana config set --url testnet\n\n# Mainnet (production - real SOL!)\nsolana config set --url mainnet-beta\n\n# Local validator\nsolana config set --url localhost\nYou can also use full URLs:solana config set --url https://api.devnet.solana.com\nEssential CommandsCheck Your Balance# Using configured wallet\nsolana balance\n\n# Check a specific address\nsolana balance <ADDRESS>\n\n# With MPLX CLI\nmplx toolbox sol-balance\nmplx toolbox sol-balance <ADDRESS>\nRequest Airdrop (Devnet/Testnet Only)# Airdrop 1 SOL to your wallet\nsolana airdrop 1\n\n# Airdrop to a specific address\nsolana airdrop 1 <ADDRESS>\n\n# With MPLX CLI\nmplx toolbox sol-airdrop 1\nmplx toolbox sol-airdrop 1 --to <ADDRESS>\nAirdrop LimitsDevnet airdrops are limited to 2 SOL per request with rate limiting. If airdrops fail, wait a few minutes or try a web faucet.Transfer SOL# Transfer SOL to another address\nsolana transfer <RECIPIENT_ADDRESS> <AMOUNT>\n\n# With MPLX CLI\nmplx toolbox sol-transfer <RECIPIENT_ADDRESS> <AMOUNT>\nView Account Information# View account details\nsolana account <ADDRESS>\n\n# View in JSON format\nsolana account <ADDRESS> --output json\nCheck Transaction Status# Confirm a transaction\nsolana confirm <SIGNATURE>\n\n# Get transaction details\nsolana transaction-history <ADDRESS>\nView Cluster Information# Check cluster version\nsolana cluster-version\n\n# View current slot\nsolana slot\n\n# Check cluster health\nsolana catchup --our-localhost\nWorking with ProgramsView Program Information# Get program account info\nsolana program show <PROGRAM_ID>\nDownload a ProgramUseful for local validator testing:solana program dump -u mainnet-beta <PROGRAM_ID> program.so\nPractical ExamplesDaily Development Workflow# 1. Start your day - check config\nsolana config get\n\n# 2. Make sure you're on devnet\nsolana config set --url devnet\n\n# 3. Check your balance\nsolana balance\n\n# 4. Need SOL? Airdrop some\nsolana airdrop 2\n\n# 5. Verify the airdrop\nsolana balance\nCommon Issues\"Unable to connect to cluster\"Your RPC endpoint may be down or rate-limited. Try:# Switch to a different RPC\nsolana config set --url https://api.devnet.solana.com\n\"Keypair file not found\"Generate a new keypair or point to an existing one:# Generate new keypair\nsolana-keygen new --outfile ~/.config/solana/id.json\n\n# Or set path to existing keypair\nsolana config set --keypair /path/to/existing/keypair.json\nCommands Running SlowlyYou may be rate-limited. Consider using a dedicated RPC provider like Helius, QuickNode, or Triton for better performance.Next StepsCreate and manage keypairs - Learn about wallet securityGet SOL for development - Airdrops and faucetsSetup a local validator - Test without network dependenciesMPLX CLI Documentation - Full Metaplex CLI referenceFAQWhat's the difference between Solana CLI and MPLX CLI?The Solana CLI is the official tool for general Solana operations (wallets, transfers, program deployment). The MPLX CLI is Metaplex's tool specifically for NFTs, tokens with metadata, and Candy Machines. Use Solana CLI for low-level operations and MPLX CLI for Metaplex-specific tasks.Can I use multiple keypairs?Yes. Either specify the keypair per command with --keypair flag, or change your default with solana config set --keypair. The MPLX CLI also supports multiple wallets via mplx config wallets.How do I know which cluster I'm connected to?Run solana config get - the \"RPC URL\" line shows your current cluster. Devnet URLs contain \"devnet\", mainnet contains \"mainnet-beta\".","tokens":1415,"squid":"dotcat","role":"Tooling Spider","at":1791346133619,"hash":"da437f5d5dbea2caabce33892328c117a2ee6e09"}
{"url":"https://developer.arbitrum.io/launch-arbitrum-chain/chain-config/additional-configuration-parameters","domain":"developer.arbitrum.io","title":"Additional configuration parameters: Arbitrum chains","text":"Configure your chainAdditional configuration parameters: Arbitrum chainsReference list of additional CLI configuration parameters available when deploying or managing your Arbitrum chain.Request an updateThe following configuration parameters can be used when deploying or managing your Arbitrum chain:\nExtra challenge period blocks\nAmount of time to wait before a challenge period expires. Like the challenge period parameter, this is measured in blocks on the underlying L1 chain, not the base (L2) chain. The default for this parameter is 200 blocks, or roughly 40 minutes.\nHow to set\nEither in the extraChallengeTimeBlocks field in the RollupCreator config, or by calling Rollup.setExtraChallengeTimeBlocks().\nLoser stake escrow\nThe address where funds bonded by a validator that has lost a challenge are sent to be escrowed. It is recommended that this be set to an address that is controlled by the chain owners or to the burn address if you want escrowed funds to be lost.\nHow to set\nEither in the loserStakeEscrow field in the RollupCreator config, or by calling Rollup.setLoserStakeEscrow().\nWASM module root\nHash of the WASM module root to be used when validating. The WASM module root is a 32 byte hash usually expressed in hexadecimal which is a merkelization of the replay binary, which is too large to be posted onchain. This hash is set in the L1 Rollup contract to determine the correct replay binary during fraud proofs. Unless the STF has been customized, the default WASM module root in the latest consensus release should be used.\nHow to set\nEither in the wasmModuleRoot field in the RollupCreator config, or by calling Rollup.setWasmModuleRoot().\nGas target\nTarget gas usage per second, over which the congestion mechanism activates. For the values set on Arbitrum One and Nova, refer to child chain gas fees. Alterations to this should be considered carefully, as setting it too high may result in state bloat that impacts the performance of the chain.\nHow to set\nCall ArbOwner.setSpeedLimit() passing in the maximum number of gas units to be executed per second for single gas target. Call ArbOwner.setGasPricingConstraints() with an array of gas targets to set up dynamic pricing.\nBlock gas limit\nMaximum amount of gas that can be consumed by all of the transactions within a block. On Arbitrum One this is set to 30 million. It can comfortably be set higher, but may harm UX as the processing time of a block will increase correspondingly.\nHow to set\nCall ArbOwner.setMaxTxGasLimit() passing in the maximum number of gas units to be executed per block and transaction.\nGas price floor\nMinimum gas price and is defaulted to 0.1 gwei. This can be set lower or higher as needed, and will impact the willingness of users to transact on the network.\nHow to set\nEither in the minL2BaseFee field in the Arbitrum chain setup script config or by calling ArbOwner.setMinimumL2BaseFee() passing in the minimum base fee in wei.\nNetwork fee account\nAccount that will receive the L2 surplus fees. It is recommended this is set to an address controlled by the chain owners, or the burn address if fees are intended to be burned. If set to zero, this defaults to the owner address.\nHow to set\nEither in the networkFeeReceiver field in the Arbitrum chain setup script config or by calling ArbOwner.setNetworkFeeAccount().\nInfrastructure fee account\nAccount that will receive the L2 base fees. It is recommended this is set to an address controlled by the chain owners, or the burn address if fees are intended to be burned. If set to zero, this defaults to the owner address.\nHow to set\nEither in the infrastructureFeeCollector field in the Arbitrum chain setup script config or by calling ArbOwner.setInfraFeeAccount().\nL1 pricing reward recipient\nAddress that will receive the rewards from the L1 fees. It is recommended this is set to an address controlled by the chain owners, or the burn address if fees are intended to be burned. By default, this is set to the owner address.\nHow to set\nCall ArbOwner.setL1PricingRewardRecipient().\nL1 pricing reward per unit (rate)\nAmount of rewards per unit to send to the L1 pricing reward recipient (multiplied by the unitsAllocated). The default for this parameter is 15 wei.\nHow to set\nCall ArbOwner.setL1PricingRewardRate() passing in the amount of wei per unit to reward.\nSequencer inbox maximum time variation\nBoundaries of the to manipulate blocks and timestamps. The default values are as follows, and are set as such on Arbitrum One:\n\ndelayBlocks: 5760\nfutureBlocks: 12\ndelaySeconds: 86400\nfutureSeconds: 3600\n\nHow to set\nEither in the sequencerInboxMaxTimeVariation field in the RollupCreator config or by calling SequencerInbox.setMaxTimeVariation on the .\nForce-include period\nLength of the period after which a delayed message can be included into the inbox without any action from the sequencer, measured in L1 block time.\nHow to set\nCorresponds to delayBlocks and delaySeconds in the sequencer inbox maximum time variation above.\nBatch posting minimum frequency\nMaximum time to wait after a transaction is sent to post a batch containing it. Note that if no transactions are sent, no batches will be posted, regardless of this setting. The default setting is one hour, and can be set lower but may reduce efficiency in the case of low activity on the Arbitrum chain.\nHow to set\n--node.batch-poster.max-delay in the batch poster config.\nValidator node (branch) creation frequency\nMinimum time to wait since the last assertion to post a new assertion, if configured to post new assertions (MakeNodes). This is bypassed if there is an incorrect assertion and a dispute needs to be made by making a new assertion. Note that if no new batches are posted (and no force inclusion happens), no new assertions will be posted, regardless of this setting. The default setting is 1 hour and is alterable but should always be greater than the rollup contract's minimumAssertionPeriod, which is measured in L1 blocks and is defaulted to 75 blocks, or roughly 15 minutes.\nHow to set\n--node.staker.make-assertion-interval in the validator config.How is this guide?Test chain configurationConfigure a non-production Arbitrum chain so that assertions post and confirm in seconds rather than days, and understand which parameters differ on testnets.chainConfig referenceReference list of chainConfig JSON parameters available when deploying or managing your Arbitrum chain.","tokens":1605,"squid":"spider-01","role":"Chain Spider","at":1791346139538,"hash":"ffeb3238a901289f75034b9c257a4216f90d86be"}
{"url":"https://developer.arbitrum.io/launch-arbitrum-chain/chain-config/chainConfig-reference","domain":"developer.arbitrum.io","title":"chainConfig reference","text":"Configure your chainchainConfig referenceReference list of chainConfig JSON parameters available when deploying or managing your Arbitrum chain.Request an updateThe full chainConfig contains the standard Ethereum genesis/fork fields, but the Chain SDK's prepareChainConfig() only exposes a small subset for customization. Everything else is filled from hardcoded defaults and should not be changed.\nWhen you call prepareChainConfig, you pass a chainId (top-level) and an arbitrum object where InitialChainOwner is required and the fields below are optional overrides.\nExample:\nimport { prepareChainConfig } from '@arbitrum/chain-sdk';\n\nconst chainConfig = prepareChainConfig({\n chainId: 123_456,\n arbitrum: {\n InitialChainOwner: '0xYourChainOwnerAddress', // required\n // Optional overrides (defaults shown):\n InitialArbOSVersion: 51,\n DataAvailabilityCommittee: false,\n MaxCodeSize: 24576,\n MaxInitCodeSize: 49152,\n },\n});\nCustomizable fields (via prepareChainConfig)\nFieldTypeDescriptionchainIdnumberRequired. The unique chain ID for your chain.InitialChainOwnerstringRequired. Address that owns the chain and holds upgrade/admin privileges.InitialArbOSVersion51The ArbOS version the chain launches with.DataAvailabilityCommitteefalsefalse = Rollup (L1 data posting); true = AnyTrust (DAC)MaxCodeSize24576Max deployed contract bytecode size in bytes (default matches Ethereum's EIP-170 limit).MaxInitCodeSize49152Max init/constructor code size in bytes (default matches EIP-3860).\nIntentionally not customizable\nprepareChainConfig deliberately excludes Arbitrum-specific fields so they keep their defaults:\nFieldTypeDescriptionEnableArbOStrueMust stay enabled.GenesisBlockNum0Genesis block number.AllowDebugPrecompilesfalseDebug precompiles; must stay disabled.\nStandard fields\nFor informational purposes onlyThe following fields are populated automatically from the SDK's hardcoded defaults. They are standard Ethereum genesis/fork-activation parameters and are not exposed for customization by prepareChainConfig.Changing these fields can produce an invalid or non-functional chain configuration.Leave them at their default values.\nFieldDefaultDescriptionhomesteadBlock0Block at which the Homestead fork activates.daoForkBlocknullDAO fork block (disabled).daoForkSupporttrueWhether the chain supports the DAO fork rules.eip150Block0Activation block for EIP-150 (gas cost changes).eip150Hash0x0000…0000Hash associated with the EIP-150 fork.eip155Block0Activation block for EIP-155 (replay protection).eip158Block0Activation block for EIP-158 (state-clearing changes).byzantiumBlock0Activation block for the Byzantium fork.constantinopleBlock0Activation block for the Constantinople fork.petersburgBlock0Activation block for the Petersburg fork.istanbulBlock0Activation block for the Istanbul fork.muirGlacierBlock0Activation block for the Muir Glacier fork.berlinBlock0Activation block for the Berlin fork.londonBlock0Activation block for the London fork.clique.period0Clique PoA block period (seconds).clique.epoch0Clique PoA epoch length.How is this guide?Additional configuration parametersReference list of additional CLI configuration parameters available when deploying or managing your Arbitrum chain.Deploy an arbitrum chainDeploy an arbitrum chain documentation","tokens":818,"squid":"spider-01","role":"Chain Spider","at":1791346161471,"hash":"a59bff09506932a60bcd85dab98937878c5413bc"}
{"url":"https://developer.arbitrum.io/launch-arbitrum-chain/chain-config/data-availability","domain":"developer.arbitrum.io","title":"Data availability","text":"Configure your chainData availabilityData availability configuration options.Request an updateData availability optionsConfigure Rollup, AnyTrust, or alt-DA data availability for your chain.DAC overviewLearn what you need to configure a Data Availability Committee (DAC) for your chain.DAC defaultsLearn the default DAC configuration settings for your chain.DAC how-toConfigure the Data Availability Committee (DAC) in your chain.DAC/DAS operationsRotate keys, format bitmasks, and manage quorum and committee members.DAS RPC method referenceReference for the Data Availability Server (DAS) RPC methods.Deploy DASDeploy a Data Availability Server (DAS).Deploy DAS with DockerDeploy a DAS for your AnyTrust chain with Docker and Docker Compose, without Kubernetes.Deploy mirror DASDeploy a mirror Data Availability Server (DAS).How is this guide?Priority feesHow to enable priority-fee (tip) collection on an Arbitrum chain in ArbOS61 'Elara', and the additional requirements for tip-based transaction ordering.Data availability optionsLearn how to configure data availability for Rollup, AnyTrust, and alt-DA for your Arbitrum chain.","tokens":283,"squid":"spider-01","role":"Chain Spider","at":1791346171288,"hash":"cdf2ff2742773d06d52d85d95631401eba594731"}
{"url":"https://www.metaplex.com/docs/smart-contracts/bubblegum-v2","domain":"metaplex.com","title":"Bubblegum V2 - Compressed NFTs on Solana - Metaplex","text":"SummaryBubblegum V2 (MPL-Bubblegum) is the Metaplex program for creating and managing compressed NFTs on Solana. It stores NFT data as hashed leaves in on-chain merkle trees, reducing minting costs by orders of magnitude compared to traditional NFTs.Mint millions of cNFTs for a fraction of the cost of standard Solana NFTs (~0.00001 SOL per cNFT in large trees)New in V2: freeze/thaw, soulbound NFTs, MPL-Core collections, royalty enforcement, permanent delegatesRequires an RPC provider supporting the Metaplex DAS API for indexing and fetching cNFT dataUses LeafSchemaV2 with V2 Merkle Trees — not backward-compatible with V1 treesBubblegum V2 is the latest iteration of the Metaplex Protocol program for creating and interacting with compressed NFTs (cNFTs) on Solana. Built for large-scale operations, Bubblegum V2 preserves all the benefits of the original Bubblegum while introducing powerful new features. Compressed NFTs make it possible to scale the creation of NFTs to new orders of magnitude by rethinking the way we store data onchain. Please note that certain Bubblegum V2 instructions will require protocol fees. Please review the Protocol Fees page for up-to-date information.Getting StartedFind the language or library of your choice and get started with compressed NFTs.API referenceLooking for something specific? Have a peak at our API References and find your answer.Ecosystem CompatibilityAdoption in progressBubblegum V2 is a new standard and ecosystem adoption is ongoing. Wallets and marketplaces that support Bubblegum V1 cNFTs may not yet fully support V2. Verify compatibility with your target platforms before launching user-facing features that depend on wallet display or marketplace trading.If you need broad wallet and marketplace support today, consider using MPL-Core instead — Core assets are widely supported across the Solana ecosystem.PlatformTypeRead / DisplayTransfer / TradeSolflareWallet✅ Supported❌ Not yet supportedPhantomWallet✅ Supported❌ Not yet supportedBackpackWallet✅ Supported❌ Not yet supportedMagic EdenMarketplace❌ Not yet supported❌ Not yet supportedTensorMarketplace❌ Not yet supported❌ Not yet supportedWhat's New in Bubblegum V2Bubblegum V2 builds on the foundation of the original Bubblegum program while introducing several powerful new features:Freeze and Thaw Functionality: Two types of freeze/thaw are available: 1) cNFT owners can delegate freeze authority to a leaf delegate for asset-level control, providing flexibility for various use cases such as preventing transfers during specific events or implementing vesting mechanics. 2) If the PermanentFreezeDelegate plugin is enabled on collection creation, project creators can freeze and thaw cNFTs via the permanent freeze delegate for collection-wide controlMPL-Core Collections Integration: Bubblegum V2 NFTs can now be added to MPL-Core collections instead of being limited to token metadata collections, allowing for greater flexibility and integration with the broader Metaplex ecosystem.Royalty Enforcement: Since Bubblegum V2 is using MPL-Core Collections, it is possible to enforce royalties on cNFTs e.g. using a ProgramDenyList.Inherited Royalties: cNFTs minted into MPL-Core collections can store a sentinel seller fee basis points value (65535) on the leaf and inherit the collection's Royalties plugin configuration instead of duplicating basis points on every mint.Soulbound NFTs: cNFTs can now be made soulbound (non-transferrable), permanently binding them to their owner's wallet. This is perfect for credentials, proof of attendance, identity verification, and more. It requires the PermanentFreezeDelegate plugin to be enabled when creating the collection.Allow Permanent Transfer: The permanent transfer delegate can now transfer the cNFT to a new owner without interaction of the leaf owner if the PermanentTransferDelegate plugin is enabled on the collection.Burning by Authority: If the Collection has the PermanentBurnDelegate plugin enabled, the delegate could burn the NFT without the leaf owner's signature.Attributes: Attribute Data on collection level can be added using the MPL-Core attributes plugin.To allow the above features to work, Bubblegum V2 introduces a new leaf schema (LeafSchemaV2). To learn more what leaves are used in Bubblegum V2, check out the following sections.LeafSchemaV2Bubblegum V2 introduces a new leaf schema (LeafSchemaV2) which supports the additional features while maintaining backward compatibility. This new schema allows for:Integration with MPL-Core collections instead of traditional token metadataSupporting freezing/thawing functionalityEnabling soulbound capabilities Projects can choose to use the original leaf Schema by using Legacy Bubblegum or the new v2 schema with Bubblegum V2 depending on their requirements.To use the new LeafSchemaV2, a V2 Merkle Tree has to be used that needs to be created using the createTreeV2 instruction. V1 Merkle Trees do not support the new leaf schema and V2 Merkle Trees are not compatible with V1 leaves.Merkle Trees, leaves and proofsCompressed NFTs only exist in the context of a Merkle Tree. We explain in a dedicated advanced guide what Merkle Trees are but, for the sake of this overview, you can think of a Merkle Tree as a collection of hashes that we call Leaves. Each Leaf is obtained by hashing the data of the compressed NFT.For each Leaf in the Merkle Tree, one can provide a list of hashes — called a Proof — that enables anyone to verify that the given Leaf is part of that tree. Whenever a compressed NFT is updated or transferred, its associated Leaf will change and so will its Proof.Root NodeHashNode 1HashNode 2Node 3Node 4HashNode 5Node 6Leaf 1Leaf 2Leaf 3Leaf 4Leaf 5Leaf 6Leaf 7Leaf 8NFT DataLeaf 4Node 3Node 2ProofReact FlowPress enter or space to select a node.You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel. Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.As such, Merkle Trees act as an onchain structure that allows anyone to verify a given compressed NFT exist. They do this without storing any NFT data which makes them so scalable.Which brings us to an important question: where is the NFT data stored?Metaplex DAS APIWhen we mint a new compressed NFT, its data is hashed and added as a new Leaf in a Merkle Tree. But there's more. Additionally, the entire NFT data is stored in the transaction that created the compressed NFT. Similarly, when a compressed NFT is updated, its updated data is, once again, saved on the transaction as a changelog. So, while there aren't any accounts keeping track of that data, one can look at all previous transactions in the ledger and find that information.Transaction 1Transaction 2Transaction 3Transaction 4Transaction 5...Initial NFT DataNFT Data ChangelogNFT Data ChangelogReact FlowPress enter or space to select a node.You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel. Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.Crawling through millions of transactions every time just to fetch the data of one NFT is admittedly not the best user experience. Therefore, compressed NFTs rely on some RPCs to index that information in real time to abstract this away from the end-user. We call the resulting RPC API, which enables fetching compressed NFTs, the Metaplex DAS API.Note that not all RPCs support the DAS API. As such, you may be interested in the \"Metaplex DAS API RPCs\" page to select an appropriate RPC when using compressed NFTs in your application.We talk about this in more detail in our advanced \"Storing and indexing NFT data\" guide.FeaturesEven though NFT data does not live inside accounts, it is still possible to execute a variety of operations on compressed NFTs. This is possible by requesting the current NFT data and ensuring its hashed Leaf is valid on the Merkle Tree. As such, the following operations can be performed on compressed NFTs:Mint a cNFT with or without an associated collection.Transfer a cNFT.Update the data or collection of a cNFT.Burn a cNFT.Delegate a cNFT.Verify and unverify a cNFT collection.Verify and unverify the creators of a cNFT.Freeze and thaw a cNFT.Make a cNFT soulbound.Quick ReferenceItemValueProgramMPL-Bubblegum (BGUMAp9Gq7iTEuizy4pqaxsTyUCBK68MDfK752saRPUY)Compression ProgramMPL Account Compression (fork of SPL Account Compression)Key AccountsMerkle Tree Account (owned by Compression Program), TreeConfigV2 (PDA owned by Bubblegum)Leaf SchemaLeafSchemaV2 (id, owner, delegate, nonce, data_hash, creator_hash, collection_hash, asset_data_hash, flags)JS SDK@metaplex-foundation/mpl-bubblegum (npm)Rust Cratempl-bubblegum (crates.io)SourceGitHubNext stepsNow that we know how compressed NFTs work at a high level and what's new in Bubblegum V2, we recommend checking out our Getting Started page which enumerates the various languages/frameworks that one can use to interact with compressed NFTs. Afterward, the various feature pages can be used to learn more about the specific operations that can be performed on cNFTs. Finally, advanced guides are also available to deepen your knowledge of cNFTs and Merkle Trees.FAQWhat is Bubblegum V2?Bubblegum V2 is the latest Metaplex program for creating and managing compressed NFTs (cNFTs) on Solana. It uses merkle trees to store NFT data at a fraction of the cost of traditional NFTs, while adding new features like freeze/thaw, soulbound NFTs, and MPL-Core collection integration.How much does it cost to mint a compressed NFT?Costs depend on the merkle tree size. A tree holding ~1 million cNFTs costs approximately 8.5 SOL in rent, making each cNFT roughly 0.00001 SOL. A smaller tree of 16,384 cNFTs costs ~0.34 SOL. These costs are orders of magnitude cheaper than standard Solana NFTs (~0.0029 SOL per Core NFT).What is the difference between Bubblegum V1 and V2?Bubblegum V2 introduces freeze/thaw functionality, soulbound (non-transferable) NFTs, MPL-Core collection integration, royalty enforcement, permanent delegates (transfer, freeze, burn), and a new LeafSchemaV2 with collection hash, asset data hash, and flags fields.Do I need a special RPC to use compressed NFTs?Yes. Compressed NFTs require an RPC provider that supports the Metaplex DAS API for indexing and fetching cNFT data. Not all RPCs support this. See the RPC Providers page for a list of compatible providers.Can compressed NFTs be used in collections?Yes. Bubblegum V2 uses MPL-Core collections to group cNFTs. Collections enable features like royalty enforcement, freeze delegates, and soulbound NFTs. The collection must have the BubblegumV2 plugin enabled.What is a merkle tree in the context of cNFTs?A merkle tree is an on-chain data structure that stores hashes (called leaves) of cNFT data. It enables cryptographic verification of NFT ownership and data integrity without storing the full NFT data in on-chain accounts, which is what makes cNFTs so cost-effective.GlossaryTermDefinitioncNFTCompressed NFT — an NFT stored as a hashed leaf in a merkle tree rather than in a dedicated on-chain accountMerkle TreeA binary tree data structure where each leaf is a hash of data and each parent node is a hash of its children, enabling efficient cryptographic verificationLeafA leaf node in the merkle tree representing one compressed NFT's hashed data (LeafSchemaV2)ProofA list of sibling hashes along the path from a leaf to the root, used to verify a cNFT exists in the treeCanopyCached upper nodes of the merkle tree stored on-chain to reduce proof sizes in transactionsDAS APIDigital Asset Standard API — an RPC extension for indexing and fetching compressed NFT data from transaction historyLeafSchemaV2The V2 data structure containing id, owner, delegate, nonce, data hash, creator hash, collection hash, asset data hash, and flagsTreeConfigA PDA account derived from the merkle tree address that stores Bubblegum-specific configuration (creator, delegate, capacity, version)Bubblegum TreeThe combination of a Merkle Tree account and its associated TreeConfigV2 PDA accountSoulboundA non-transferable cNFT permanently bound to its owner's wallet, created via the permanent freeze delegate","tokens":3072,"squid":"dotcat","role":"Tooling Spider","at":1791346178489,"hash":"b05944057005038c27d3d9ff3b56a23ed543f106"}
{"url":"https://www.metaplex.com/docs/protocol-fees","domain":"metaplex.com","title":"Protocol Fees | Developer Hub","text":"The Metaplex Protocol currently includes the following fees:FAQsWill the fee amounts change over time?The Metaplex Foundation is constantly monitoring community feedback related to the fees and may change the fee amounts over time. Our goal is for fees to be minimally disruptive and promote the growth and usage of the protocol.How are Metaplex Protocol Fees Used?All protocol fees are used to further the objectives of the Metaplex Foundation, which is a non-profit organisation established to foster the research, development and adoption of the Metaplex ecosystem. Currently, 50% of protocol fees are converted to $MPLX and contributed to the Metaplex DAO treasury. The remaining 50% is reserved by the Metaplex Foundation for its operations.","tokens":187,"squid":"dotcat","role":"Tooling Spider","at":1791346189182,"hash":"8c187e435dee0525e2dbaf5a03882e3bb3f7235b"}
{"url":"https://developer.arbitrum.io/launch-arbitrum-chain/chain-config/validation/assertion-control","domain":"developer.arbitrum.io","title":"Configure assertion control","text":"Configure your chainValidationConfigure assertion controlLearn how to configure assertion control.Request an updateValidator action minimum frequency\nValidator node creation frequency: Interval between validator assertions posting\nThe validator assertion posting frequency is controlled by the --node.staker.make-assertion-interval (legacy) or --node.bold.assertion-posting-interval (BoLD) parameter in the Nitro node's configuration. This parameter sets the minimum time to wait since the last assertion before posting a new one (if the validator configuration is to make new assertions via the MakeNodes strategy). The default value is one hour (3600 seconds) for legacy and fifteen minutes (900 seconds) for . This interval must always exceed the Rollup contract's minimumAssertionPeriod, which defaults to 75 L1 blocks (approximately 15 minutes at 12-second block times).\n\nConfiguration Options for legacy: Configure this in the node.staker section, e.g., \"make-assertion-interval\": \"45m\" for a 45-minute interval.\nConfiguration Options for BoLD: Configure this in the node.bold section, e.g., \"assertion-posting-interval\": \"45m\" for a 45-minute interval.\nPrevention of Issues: Frequent assertions ensure the chain's state is regularly committed and verifiable on the parent chain, preventing reordering by allowing disputes over any manipulated transaction order. For reorganizations, assertions serve as checkpoints; if a reorganization affects prior batches, validators can challenge and resolve the state to the correct one, thereby maintaining integrity. Infrequent assertions could widen the dispute window vulnerability, but the default balances this with efficiency.\nRecommended Settings: Set to 20-30 minutes for chains needing low-latency finality, but ensure it's >15 minutes to comply with the minimum period. Higher values (e.g., two hours) are suitable for low-stakes chains to reduce validator operational costs.\nNote: Validators require staking (bonding ETH or tokens on the parent chain) to post assertions, with the minimum bond set via the Rollup contract during chain deployment. If an incorrect assertion is detected, the interval is bypassed, and a new challenge begins. No new assertions get posted if no new batches arrive or force inclusions occur.\n\nValidator node confirmation frequency: Interval between validator assertions confirming\nThe validator assertion confirming frequency is controlled by the --node.staker.staker-interval (legacy) or --node.bold.assertion-confirming-interval (BoLD) parameter in the Nitro node's configuration. This parameter sets the minimum time to wait since the last assertion before confirming a new one (if the validator configuration is to confirm assertions via the ResolveNodes strategy). The default value is one minute (1m0s) for both legacy and BoLD.\n\nConfiguration Options for legacy: Configure this in the node.staker section, e.g., \"staker-interval\": \"45m\" for a 45-minute interval.\nConfiguration Options for bold: Configure this in the node.bold section, e.g., \"assertion-confirming-interval\": \"45m\" for a 45-minute interval.\nRecommended Settings: Using the default setting will be fine.\nNote: Validators require staking (bonding ETH or tokens on the parent chain) to confirm assertions.\n\nReorganization prevention:\nReorg resistance margin\nReorg prevention interacts with batch posting through maxTimeVariation and reorg-resistance-margin. See the Configure Sequencer timing adjustments page for the full mechanism.\n\nDetailed Explanation of the Message: The message \"Disabling batch posting due to batch being within resistance margin from Layer 1 minimum block or timestamp bounds\" signifies that the batch poster's logic has detected the proposed batch's minimum required L1 block or timestamp falls within the configured margin of the current L1 chain head. For example, if the margin is ten minutes and the L1 head timestamp is T, the poster disables itself if the batch requires a minimum timestamp greater than (T - 10m) or a minimum block that is too close to the head. This message serves as a protective mechanism: L1 chains, such as Ethereum, can undergo short reorganizations (e.g., uncle blocks or brief forks), which could invalidate a posted batch if it references a block/timestamp that gets reorganized. By temporarily disabling posting, the system waits for L1 to stabilize, ensuring the batch remains valid once posted. The disablement is transient; posting resumes once the margin clears (e.g., as L1 advances). This message often appears in logs during periods of high L1 volatility or when the sequencer's clock/L1 sync is slightly off. It's normal in such cases, but it may indicate setup issues if it persists.\nGuidance on Configuration: Set this in the node.batch-poster config section, e.g., \"reorg-resistance-margin\": \"5m\". Lower values allow for faster posting but increase the risk; higher values enhance safety. Monitor logs for frequent disablements and adjust accordingly based on the parent chain stability (e.g., Ethereum mainnet vs. testnets).\nRecommended Settings: The default of ten minutes is suitable for most Arbitrum chains settling to Arbitrum One/Nova, as Ethereum reorgs rarely exceed a few blocks (1-2 minutes). For chains on more volatile bases (e.g., alt L1s), increase the time to 15-20 minutes. Test on devnets to observe behavior.\nTrade-offs Between Consistency and Latency: A higher margin prioritizes consistency by reducing the chance of orphaned posted batches due to L1 reorgs, which could force manual intervention or state rollbacks—critical for high-value chains. However, it increases latency, as batches may wait longer to post, delaying times (e.g., from seconds to minutes). A lower margin reduces latency for a better user experience (faster transaction finality) but risks more frequent disablements or invalid postings, potentially leading to temporary chain halts or increased operational overhead. Balance based on chain use case: low margin for gaming/dex chains that require speed; high margin for DeFi/financial apps that emphasize reliability.\n\nSequencer max time variation\nThe sequencer's max time variation is configurable via the setMaxTimeVariation method of the Contract, which will also be set to prevent chain reorganization when there are no batches for an extended period.\nMaxTimeVariation struct:\nstruct MaxTimeVariation {\n uint256 delayBlocks;\n uint256 futureBlocks;\n uint256 delaySeconds;\n uint256 futureSeconds;\n}\nThe MaxTimeVariation struct defines time boundaries that determine whether your chain remains safe or triggers a reorganization (reorg) when posting batches. It uses both block-based and time-based limits to create acceptable windows for message processing between L1 and L2.\nHow the safety check works\nWhen your chain attempts to send a batch, it performs a critical timing validation by comparing the first transaction timestamp in that batch with the current (batch sending) time against the configured MaxTimeVariation limits:\n\nFor MAX bound violations → Stop adding new messages to the batch\nFor MIN bound violations → Completely prevents batch posting with error: \"batch is within reorg resistance margin from Layer 1 minimum block or timestamp bounds\"\n\nWe will explain how the safety check works in more detail in the next section.\nRelationship between ReorgResistanceMargin and MaxTimeVariation\nWhile both ReorgResistanceMargin and MaxTimeVariation are timing-related security parameters in Arbitrum, they serve complementary but distinct purposes in the batch posting mechanism.\nHow they work together\nMaxTimeVariation establishes the fundamental time bounds for message validity, while ReorgResistanceMargin adds a safety buffer on top ofMaxTimeVariation's minimum bounds:\n\nCalculate L1 bounds using MaxTimeVariation:\n\n l1BoundMaxBlockNumber = latestL1BlockNumber + maxTimeVariation.futureBlocks\n l1BoundMinBlockNumber = latestL1BlockNumber - maxTimeVariation.delayBlocks\n l1BoundMaxTimestamp = latestL1Timestamp + maxTimeVariation.futureSeconds\n l1BoundMinTimestamp = latestL1Timestamp - maxTimeVariation.delaySeconds\n\nAdd ReorgResistanceMargin to L1 minimum bounds:\n\n safeBlockThreshold = l1BoundMinBlockNumber + (ReorgResistanceMargin / 12 seconds)\n safeTimestampThreshold = l1BoundMinTimestamp + (ReorgResistanceMargin / 1 second)\n\nStop adding new messages to the batch if MAX bound violations:\n\nIf the new message's timestamp ≥ l1BoundMaxTimestamp or block number ≥ l1BoundMaxBlockNumber, stop adding new messages to the batch\n\nReject batch if MIN bound violations:\n\nIf the first message in the batch has a timestamp ≤ safeTimestampThreshold or block number ≤ safeBlockThreshold, batch posting is disabled with the error: \"batch is within reorg resistance margin from Layer 1 minimum block or timestamp bounds\"\n\nWhy this relationship matters\nThis layered approach provides defense in depth:\n\nMaxTimeVariation ensures message timestamps stay within acceptable bounds for normal operation\nReorgResistanceMargin prevents batch posting when approaching those bounds, reducing the risk that an L1 reorganization could make a recently posted batch invalid\nHow is this guide?ValidationHow to configure validation for your chain.BoLD for Arbitrum chainsLearn how to integrate BoLD with your Arbitrum chain","tokens":2321,"squid":"spider-01","role":"Chain Spider","at":1791346201793,"hash":"e168dd3defa683385162dca426a16bcbb21dc7fc"}
{"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":"spider-08","role":"Oracle Spider","at":1791346208685,"hash":"e2d1307a670e381c427db07f5c88d854bde44fca"}
{"url":"https://akash.network/docs/providers/setup-and-installation/provider-playbook/","domain":"akash.network","title":"Provider Playbook - Automated Setup | Akash Network - Your Guide to Decentralized Cloud","text":"Provider Playbook - Automated Setup The Provider Playbook is the recommended guided installer for self-managed Akash providers. It can build Kubernetes with Kubespray or K3s, or add provider components to an existing cluster.\nThe terminal wizard validates access before making changes, detects host capabilities over SSH, recommends safe defaults, shows a redacted review, and installs only the components you select.\nBefore you start\nThe installer supports Ubuntu 24.04 LTS on x86-64 hosts. Review the provider hardware requirements before provisioning nodes.\nYou also need:\n\nRoot access on the machine where you run the installer.\nSSH console or out-of-band access to every node so you can authorize an SSH public key.\nPasswordless sudo for every non-root SSH user. Password-based SSH is not supported.\nA domain you control and the ability to create its DNS records.\nA funded Akash wallet, or funds to transfer to a wallet created by the wizard.\nFor GPU installation, clean NVIDIA hosts without a preinstalled driver, CUDA driver package, Container Toolkit, or legacy NVIDIA device-plugin Helm release.\nFor Rook-Ceph, at least two dedicated, empty physical disks across the cluster. Three storage hosts are recommended for production availability.\n\nThe reachable SSH address, user, and port for each node are the only host details you must know in advance. Location, CPU, memory, GPUs, network addresses, and eligible Ceph disks are detected after SSH access succeeds.\nInstall\nConnect to the first node, clone the repository, and run the wizard as root:\nTerminal windowgit clone https://github.com/akash-network/provider-playbooks.gitcd provider-playbookssudo ./scripts/setup_provider.sh\nSuccessful prerequisite commands keep package-manager output hidden. If a command fails, the wizard prints its captured output with the failing step.\nInstaller workflow\n1. Choose the Kubernetes foundation\n\nModeUse it whenBehaviorKubesprayYou want a production-oriented Kubernetes clusterDownloads the pinned Kubespray release only for this modeK3sYou want a lean Kubernetes installationUses the playbook’s K3s role and never downloads KubesprayExisting clusterKubernetes is already installedLeaves the distribution untouched and installs only selected components\nFor clusters built by the wizard, every control-plane node is also a worker:\n\nNode countControl planesWorkers1node1node12node1node1, node23 or morenode1, or node1–node3Every configured node\nKubespray prompts for kubelet and containerd data directories. K3s keeps kubelet data at /var/lib/kubelet and prompts only for the K3s data directory, which defaults to /var/lib/rancher/k3s.\nWhen using an existing cluster, the first entered host must map to a control-plane node where sudo kubectl works. The wizard maps each SSH host to a unique Kubernetes node and does not ask Kubernetes to advertise different node addresses.\n2. Select components\nThe wizard can install:\n\nProvider OS tuning and maintenance jobs.\nNVIDIA GPU Operator on detected GPU nodes.\nRook-Ceph persistent storage.\nThe Akash node, gateway, provider, hostname operator, and inventory operator.\nOptional Tailscale access.\n\nOS tuning and the provider stack are selected by default. GPU, Rook-Ceph, and Tailscale are opt in.\n3. Establish SSH access\nEnter a reachable IPv4 address, SSH user, and SSH port for each node. The wizard then selects a compatible local key or creates a dedicated Ed25519 key and displays the public key and target users.\nAdd that public key to each target user’s ~/.ssh/authorized_keys, then continue. The wizard loops until every host accepts key-only SSH and every non-root user can run non-interactive sudo.\nFor a new Kubespray or K3s cluster, private and public addresses are detected over the verified SSH connection. When both are available, the wizard recommends private addresses for Kubernetes inter-node traffic. SSH continues to use the reachable address you entered.\n4. Detect provider capabilities\nDiscovery runs over SSH after access validation:\n\nThe first node’s public egress address is used to suggest country, city code, UTC offset, and a valid Akash location-region. If lookup fails or you decline the result, a guided region picker builds the attributes.\nlscpu and firmware data provide CPU vendor, architecture, memory generation, and ECC. The wizard asks only for values the host does not expose or that you decline.\nPCI display devices are matched against a pinned Akash GPU database. The wizard derives the provider’s GPU model, memory, interface, CUDA, and Fabric Manager settings. SXM GPUs enable Fabric Manager automatically.\nIf Rook-Ceph is selected, every configured host is scanned read-only for eligible whole disks.\n\n5. Configure the provider\nThe wizard collects the base domain without a provider. prefix, organization and contact attributes, network attributes, and TLS method. Production TLS can use Cloudflare or Google Cloud DNS-01; a self-signed certificate is available for bootstrap and testing.\nWallet creation, recovery, lookup, and export use only the unified akt CLI. The installer uses a dedicated context named provider, creating it for mainnet when it is absent instead of launching akt’s general first-run network picker. If that context already exists, verify that it points to mainnet before continuing.\nWallet options are:\n\nUse an existing key from the provider context.\nCreate a new key and display its recovery mnemonic.\nRecover a key from a mnemonic.\nSupply an address and pre-encoded provider secrets.\n\nThe keyring password is collected once and reused only for the current wallet operation. A separate provider export password is generated automatically and stored only in the protected inventory. If a requested key name already exists, the wizard offers to use it or enter another name.\n6. Review and deploy\nBefore writing generated inventory or deploying roles, the wizard displays a redacted installation profile with hosts, topology, components, provider attributes, and storage choices. After confirmation, it generates the protected inventory and starts deployment.\nThe component order is:\n\nKubernetes foundation and cluster verification.\nNVIDIA GPU Operator.\nRook-Ceph storage.\nAkash provider stack.\n\nOS preparation runs before the optional infrastructure components. Cluster-scoped Helm operations run once from the first control-plane host; they are not repeated on every node.\nCeph disk discovery and recommendations\nStorage discovery never wipes or modifies a disk. It excludes a device when it is:\n\nRead-only, removable, or smaller than 5 GiB.\nPartitioned, mapped, mounted, or used as swap.\nMarked with filesystem, RAID, LVM, or Ceph signatures.\nHeld by another block device.\nMissing a stable /dev/disk/by-id identity.\n\nThe recommendation prioritizes three storage hosts, then two storage hosts, then two physical disks on one host. It prefers the fastest homogeneous media tier that preserves the best available topology. If mixed media are selected, the provider advertises the slowest selected tier:\n\nMediaAkash storage classHDDbeta1SSDbeta2NVMebeta3\nRook creates exactly one OSD per selected physical disk, including NVMe. At least two disks are required cluster-wide.\n\nSelected topologyReplica layoutFailure domainThree or more storage hosts3 copies, minimum 2HostTwo storage hosts2 copies, minimum 1HostOne host with at least two disks2 copies, minimum 1OSD\nA one-host layout can survive one disk failure but not loss of that host. Use at least three storage hosts for production host-level availability.\nThe wizard shows every exact stable disk path and requires explicit confirmation before deployment. Rook consumes the selected disks after confirmation. On rerun, an existing Ceph cluster reuses its recorded exact layout; the installer stops instead of guessing replacement disks when that protected record is unavailable.\nAfter installation, the Rook role verifies the expected OSD count, per-node distribution, Ceph health, and StorageClass. When the provider is selected, the provider role also provisions and mounts a temporary claim before advertising persistent storage; that claim check works with Rook or another compatible storage class.\nGenerated files and secrets\nNormal installation creates these paths in the repository:\n\n.venv/ — the pinned Ansible environment for this project.\n.generated/inventory/ — generated inventory and encoded credentials.\n.cache/kubespray/ — Kubespray checkout and environment, created only when Kubespray is selected.\n\nAll are ignored by Git. Files containing wallet, DNS, Tailscale, or rendered provider credentials are written with mode 0600. Base64-encoded material is still secret; do not copy .generated into source control or share it.\nGenerate configuration without installing\nUse configuration-only mode to inspect the inventory before installing packages or changing hosts:\nTerminal window./scripts/setup_provider.sh --config-only\nThis mode still validates SSH and performs remote discovery. It does not create .venv, install the isolated Python runtime on hosts, download Kubespray, install akt, or deploy roles. Because wallet tooling is not installed, provide pre-encoded wallet material when prompted.\nThe resulting inventory is not immediately runnable on a fresh clone. Follow the repository’s manual bootstrap instructions before invoking Ansible yourself.\nCurrent component versions\nThe repository keeps compatibility pins in versions.yml. The installer loads this matrix rather than selecting unbounded latest releases.\n\nComponentPinned versionKubesprayv2.31.0K3sv1.35.3+k3s1Calicov3.31.5Helmv4.2.4NVIDIA GPU Operatorv26.7.0Rook-Ceph1.19.10Cephquay.io/ceph/ceph:v19.2.6-20260818akt0.1.1\nTreat versions.yml as the source of truth if this table and the repository ever differ.\nVerify the installation\nSome Helm releases intentionally return after Kubernetes accepts them, while their controllers and pods continue reconciling. In particular, the GPU Operator, Akash node, and provider are not treated as synchronous readiness gates.\nA new provider wallet has no funds. Fund its address before expecting the provider pod to become ready and register or bid on-chain.\nCheck progress with:\nTerminal windowsudo kubectl get nodessudo kubectl get pods --all-namespacessudo kubectl get pods --namespace akash-servicessudo kubectl logs --namespace akash-services akash-provider-0 --follow\nVerify the provider’s on-chain record with the installer context selected explicitly:\nTerminal windowsudo --set-home akt --context provider query provider <provider-address>\nSee Provider Verification for the complete checklist.\nRerun a component\nThe normal installer runs as root, so rerun Ansible as root from the repository root to retain access to its virtual environment, generated inventory, SSH key, and akt context:\nTerminal windowsudo --set-home env ANSIBLE_CONFIG=\"$PWD/ansible.cfg\" \\ .venv/bin/ansible-playbook \\ --inventory .generated/inventory/hosts.ini \\ playbooks.yml \\ --tags provider\nAvailable tags include preflight, tailscale, k3s, os, local-path, gpu, rook-ceph, and provider.\nTroubleshooting\nSSH validation fails\n\nAdd the displayed public key to the exact user’s ~/.ssh/authorized_keys on every node.\nVerify the entered IPv4 address and port are reachable.\nFor non-root users, confirm sudo -n true succeeds without a password prompt.\nPassword authentication is deliberately unsupported.\n\nNo Ceph disks are eligible\nReview the exclusion reason shown for each disk. Ceph devices must be dedicated, empty whole disks with stable /dev/disk/by-id paths. The wizard will not clean an in-use or previously formatted device for you.\nA newly installed component is not ready yet\nHelm acceptance does not mean every controller, image pull, blockchain sync, GPU driver build, or provider pod is complete. Inspect the relevant namespace with kubectl get pods and kubectl describe pod, then follow the failing pod’s logs.\nFor ongoing management, continue to Provider Operations.\nResources\n\nProvider Playbooks repository\nProvider Playbooks issues\nManual Kubespray setup\nAkash Discord — #providers\n\nEdit page on github\n Reclamation Provider Console","tokens":3028,"squid":"spider-03","role":"Compute Spider","at":1791346210841,"hash":"f82f293598d6a7fa96d1bb72a3f9d1f0ef127836"}
{"url":"https://gov.optimism.io/t/introducing-improvements-to-the-protocol-upgrade-process/10284/1","domain":"gov.optimism.io","title":"Introducing improvements to the Protocol Upgrade process - Updates and Announcements 📢 - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n Introducing improvements to the Protocol Upgrade process \n\n Updates and Announcements 📢\n\n season-8\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n 2\n\n Sep 2025\n\n 1 / 10\n\n Sep 2025\n\n 3d ago\n\n post by system on Sep 16, 2025\n\n system\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 Developer Advisory Board (DAB), who were elected by the Token House and Citizens’ House ahead of Season 8. This doesn’t apply to maintenance upgrades\n\nDelegates are no longer required to post approvals of proposals on the forum, or actively vote to approve upgrades.\n\nInstead, delegates and Citizens have the power to veto upgrades that they believe harm their interests during a 1-week Joint House veto period. They may also override the DAB’s decision to reject an upgrade.\n\nThis shift ensures an efficient, low-overhead, technically rigorous path to mainnet upgrades.\n\nThe improved upgrade process\nprotocol upgrades diagram1600×900 116 KB\nStep 1: Developer Advisory Board Approval\n\nAn elected group of 7 independent protocol developers (the DAB) is looped in early to provide feedback on upcoming releases, and reviews upgrades during the final testing phase.\n\nThey assess each proposal for (among other things):\n\nTechnical content: does the proposal do what it says it will? Is it complete? Does call data match?\n\nTechnical merit: Is the justification of changes clear? Are the described benefits accurate? Are there unmentioned technical tradeoffs?\n\nCollective impact: does the proposal violate the Law of Chains or Working Constitution?\n\nThe full list of the DAB’s responsibilities can be found here\n\nOnce the betanet phase is complete, the upgrade can be pushed to Sepolia.\n\nIf the DAB rejects a proposal, the upgrade continues to Sepolia and enters the 7 day stakeholder veto period. This allows stakeholders to choose whether to override the DAB decision.\n\nStep 2: 7-Day Veto Period\n\nOnce on Sepolia, the upgrade enters a 1-week veto window.\n\nIf the DAB has approved the upgrade, stakeholders are voting to block the upgrade.\n\nIf the DAB has rejected the upgrade, stakeholders are voting to override the DAB’s decision and allow the upgrade to be executed.\n\nFour stakeholder groups can object:\n\nDelegates (Token House)\n\nChain Operators (Citizens’ House)\n\nApplication Developers (Citizens’ House)\n\nEnd Users (Citizens’ House)\n\nThe full eligibility criteria for Citizens’ House membership can be found here\n\nA veto is triggered if 2 or more groups cross the applicable below thresholds:\n\n2 groups: 17% of each group must support a veto\n\n3 groups: 14% each\n\n4 groups: 11% each\n\nIf veto threshold is not met → upgrade proceeds according to DAB decision.\n\nIf veto threshold is met → DAB decision is overridden\n\nIf a proposal is rejected, it enters an appeals and discussion phase\n\nWhat this means for delegates\nDelegates continue to play their meaningful role in governance with a streamlined focus:\n\nDelegates elect the Developer Advisory Board (DAB) to represent their interests on technical matters.\n\nDelegates are no longer required to actively vote on every upgrade.\n\nDelegates may engage in the veto process if a proposed upgrade appears misaligned with the interests of tokenholders, or they disagree with the DAB’s rejection of the upgrade.\n\nIf no concerns are raised, no action is needed—upgrades proceed by default according to the DAB’s decision.\n\nThis model preserves real oversight power, without demanding delegates’ time for every technical release.\n\nTimeline\n\nThis process is live as of August 2025.\n\nAll Season 8 protocol upgrades will follow the new DAB approval + veto model.\n\nMaintenance upgrades will follow a shortened version of the process without DAB approval, as defined here\n\nDelegates will receive alerts on Telegram when an upgrade enters the veto period.\n\nContinued improvements to the Protocol Upgrade process will be made ahead of Season 9\n\n Optimism Gov Summary\n\n 2\n\n 2\n\n Unlisted on Sep 16, 2025\n\n Listed on Sep 16, 2025\n\n post by GFXlabs on Sep 16, 2025\n\n post by optimistic_emily on Sep 17, 2025\n\n post by kumahada on Sep 18, 2025\n\n post by optimistic_emily on Sep 18, 2025\n\n post by nanobro on Sep 25, 2025\n\n 4 months later\n\n post by system on Jan 28\n\n 8 months later\n\n post by DarkEmpath888 3 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 Season 8 Developer Advisory Board Charter amendment\n\n Elections 💼\n\n season-8\n\n Developer Advisory Board: Seasons 8 Charter Amendment\nProposed Council or Board Lead: Ed (wildmolasses) \nPlease link to any previous work or qualifications to be Council or Board Lead: \n\nAtlas profile\nDAB member S6\nDAB O…\n\n read more\n\n 7\n\n 431\n\n Jul 2025\n\n Internal Operating Procedures (IOP) for Developer Advisory Board: Season 8\n\n Internal Operating Procedures\n\n season-8\n\n Seasons 8 Developer Advisory Board - Internal Operating Procedures (IOPs)\nThe Internal Operating Procedures in this document govern the activities of the Season 8 Developer Advisory Board. This document sets forth the pr…\n\n read more\n\n 0\n\n 67\n\n Aug 2025\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 Developer Advisory Board - S6 Internal Operating Procedures\n\n Internal Operating Procedures\n\n The internal operating procedures in this document govern the activities of the Season 6 Developer Advisory Board. The document sets forth the processes the DAB will follow in fulfilling our charter, including supporting…\n\n read more\n\n 3\n\n 316\n\n Jul 2024\n\n Voting Cycle Roundup #26\n\n Voting Cycles\n\n season-6\n\n Cycle #26 began on Thursday August 8th at 19:00 GMT and runs until Wednesday August 28th at 19:00 GMT. Additionally, the Citizens’ House will have a one-week period to veto any Upgrades approved by the Token House, immed…\n\n read more\n\n 4\n\n 304\n\n Apr 2025","tokens":1588,"squid":"spider-07","role":"Council Spider","at":1791346213292,"hash":"fd90acad5faecbfb7c43fe2a26b27285beccd6ff"}
{"url":"https://akash.network/docs/providers/getting-started/hardware-requirements","domain":"akash.network","title":"Provider Hardware Requirements | Akash Network - Your Guide to Decentralized Cloud","text":"Provider Hardware Requirements Understand the hardware requirements for running a successful Akash provider.\nThis guide covers system requirements, hardware specifications, and best practices.\n\nSystem Requirements\nOperating System\n\nUbuntu 24.04 LTS Server (officially supported)\nEnsure all nodes are fully updated with latest security patches\n\nCPU Architecture\n\nx86_64 processors only (officially supported)\nARM processors are not currently supported\nApplies to all nodes in the cluster\n\nMinimum Hardware Specifications\nSingle Server (Worker + Control Plane Combined)\nMinimum:\n\nCPU: 8 cores\nRAM: 16GB\nStorage: 150GB SSD\n\nRecommended:\n\nCPU: 12+ cores\nRAM: 48+ GB\nStorage: 500GB+ SSD\n\nImportant Considerations:\n\nReserve ~4 CPU cores for Kubernetes system components (control plane + worker overhead)\nSingle server setup is good for testing or small providers\nFor production, separate control plane and worker nodes are recommended\n\nControl Plane Node (per node, separate setup)\nMinimum:\n\nCPU: 2 cores\nRAM: 4GB\nStorage: 30GB SSD\n\nRecommended:\n\nCPU: 4 cores\nRAM: 8GB\nStorage: 40GB SSD\n\nFor Production (3-node control plane):\n\n3x control plane nodes for high availability\nTotal: 12 CPU cores, 24GB RAM, 120GB storage\n\nWorker Node (per node, separate setup)\nMinimum:\n\nCPU: 4 cores\nRAM: 8GB\nStorage: 100GB SSD\n\nRecommended:\n\nCPU: 8+ cores\nRAM: 32+ GB\nStorage: 500GB+ SSD\n\nImportant Considerations:\n\nReserve ~2 CPU cores for Kubernetes system components\nMore resources = more concurrent deployments\nExample: 8 CPU node = ~6 deployments (8 CPU - 2 reserved)\n\nGPU Requirements\nSupported GPUs\n\nNVIDIA GPUs only currently supported\n\nGPU Requirements & Best Practices\nOne GPU Type Per Node (Required):\n\nEach node must have only one type of GPU\nMixing different GPU models on the same node is not supported\nMultiple identical GPUs per node is supported and recommended\n\nOne GPU Type Per Provider (Recommended):\n\nWhile technically possible to have different GPU types across nodes, it is strongly recommended to standardize on one GPU type per provider\nHaving multiple GPU types in one provider (on different nodes) can complicate operations and pricing\n\nExample Configurations:\n\nAI/ML Node: 4x NVIDIA A100 (all identical)\nRendering Node: 2x RTX 4090 (all identical)\nMixed Workload: 8x T4 (all identical)\n\nStorage Guidelines\nRoot/Ephemeral Storage\n\nMinimum: 100GB per worker node\nRecommended: 500GB+ per worker node\nType: SSD or NVMe for performance\n\nPersistent Storage (Optional)\nMinimum Requirements:\n\nAt least two dedicated physical disks across the cluster\nOne Ceph OSD per physical disk, including NVMe\nFor production host-failure tolerance, dedicated disks on at least three storage hosts\nHomogeneous media are preferred. Mixed media are supported, but the provider must advertise the slowest selected tier.\n\nDedicated Drives:\n\nThese drives must be dedicated exclusively to persistent storage\nCannot be used for any other purpose (no OS, no ephemeral storage)\nRecommended: Distribute dedicated drives across multiple nodes for redundancy\n\nStorage Classes:\n\nbeta3 - NVMe (Non-Volatile Memory Express)\nbeta2 - SSD (Solid State Drive)\nbeta1 - HDD (Hard Disk Drive)\n\nExample Configurations:\n\nTechnical minimum: 2 dedicated disks on one or two hosts; a one-host layout has no host-level availability\nProduction baseline: 3+ dedicated disks distributed across 3+ hosts\nHigher capacity: Multiple disks per host, with one OSD created for each physical disk\n\nNetwork Requirements\nInternet Connection\nBandwidth:\n\nMinimum: 100 Mbps symmetrical\nRecommended: 1+ Gbps symmetrical\nCritical: Upload speed matters as much as download\n\nLatency:\n\nLow latency preferred (< 10ms to major hubs)\nAffects bid competitiveness\nImportant for real-time workloads\n\nIP Addressing\nRequired:\n\nOption 1: At least one static public IP\nOption 2: Dynamic DNS (DDNS) service\n\nOptional (for IP leases feature):\n\nMultiple static IPs\n/29 subnet or larger\nAllows providers to offer dedicated IPs to tenants\n\nDomain Name (Required)\nYou must own a domain name for your Akash provider:\n\nA registered domain that you control (e.g., yourdomain.com)\nUsed for provider identification and workload routing\nDNS A records will point to your provider’s public IP\n\nFirewall Rules\nRequired Open Ports:\n\n80/tcp - HTTP workloads\n443/tcp - HTTPS workloads\n8443/tcp - Manifest uploads\n8444/tcp - Provider gRPC\n30000-32767/tcp - Kubernetes NodePort range\n30000-32767/udp - Kubernetes NodePort range (UDP services)\n\nRecommended:\n\n22/tcp - SSH (restrict to your IPs)\n6443/tcp - Kubernetes API (control plane only, restrict to cluster nodes)\n\nInternal Network\nFor Multi-Node Clusters:\n\nLow-latency network between nodes (< 1ms)\n10 Gbps+ recommended for storage traffic\n\nCluster Sizing Examples\nSmall Provider (Home Lab)\nHardware:\n\n1 control plane node: 4 CPU, 8GB RAM, 100GB SSD\n1 worker node: 8 CPU, 32GB RAM, 500GB SSD\n\nCapacity:\n\n~6 concurrent deployments\nNo GPU support\n100-200GB ephemeral storage\n\nCost: ~500−1,000initial+30-50/month\n\nMedium Provider (Small Data Center)\nHardware:\n\n3 control plane nodes: 4 CPU, 8GB RAM, 100GB SSD each\n3 worker nodes: 16 CPU, 64GB RAM, 1TB SSD each\n\nCapacity:\n\n~40 concurrent deployments\nOptional: 1-2 GPUs per worker\n1TB+ persistent storage\n\nCost: ~5,000−10,000initial+200-500/month\n\nLarge Provider (Data Center)\nHardware:\n\n3 control plane nodes: 8 CPU, 16GB RAM, 200GB SSD each\n10+ worker nodes: 32 CPU, 128GB RAM, 2TB NVMe each\nDedicated GPU nodes: 8 CPU, 64GB RAM, 4x A100 GPUs\n\nCapacity:\n\n200+ concurrent deployments\n20+ GPU instances\n10TB+ persistent storage\n\nCost: ~50,000−200,000initial+2,000-10,000/month\n\nNext Steps\nCalculate earnings:\n\nProvider Earn Calculator →\n\nEdit page on github\n Should I Run a Provider? Kubernetes Setup","tokens":1426,"squid":"spider-03","role":"Compute Spider","at":1791346220926,"hash":"6de7e17a566fd2339497f499d7de33c163c6d1bc"}
{"url":"https://gov.optimism.io/t/introducing-improvements-to-the-protocol-upgrade-process/10284/10","domain":"gov.optimism.io","title":"Introducing improvements to the Protocol Upgrade process - Updates and Announcements 📢 - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n Updates and Announcements 📢\n\n season-8\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n 2\n\n Sep 2025\n\n 10 / 10\n\n Oct 3\n\n 3d ago\n\n post by system on Sep 16, 2025\n\n Unlisted on Sep 16, 2025\n\n Listed on Sep 16, 2025\n\n post by GFXlabs on Sep 16, 2025\n\n post by optimistic_emily on Sep 17, 2025\n\n post by kumahada on Sep 18, 2025\n\n post by optimistic_emily on Sep 18, 2025\n\n optimistic_emily\n\n Hi, no that is not correct. Both the Security Council and Developer Advisory Board continue to have important and distinct roles in the system.\nThe Developer Advisory Board assesses the upgrade’s technical content, technical merit and Collective impact before deciding whether to approve the upgrade or not.\n“During normal operations, the [Security] Council simply implements the upgrade and role permission decisions made by Governance, rather than making decisions itself.”\nMore details can be found in the Security Council and Developer Advisory Board charters.\n\n post by nanobro on Sep 25, 2025\n\n nanobro\n\n I like how the new process strikes a balance between efficiency and accountability. Delegates and Citizens still retain meaningful oversight through the veto mechanism, while the Developer Advisory Board ensures technical stuffs.\n\n 4 months later\n\n post by system on Jan 28\n\n system\n\n A minor update to this process has been made and is now reflected in the Operating Manual.\nThe Developer Advisory Board has a 7 day voting window to vote on a protocol upgrade. However, in cases when a proposal is approved in less than 7 days, the proposal may move straight to the veto period. This means a proposal could move to the veto period in less than 7 days but the Developer Advisory Board will have the full 7 days when needed. Allowing the DAB voting window to be variable (up to 7 days), engineering can ship faster in cases where the DAB reaches quourum quickly. As the DAB is looped into core development discussions early, this change does not alter the length of the review period, which is ongoing well before a proposal reaches the forum.\n\n 8 months later\n\n post by DarkEmpath888 3 days ago\n\n DarkEmpath888\n\n kumahada\n\n I need assistance please. I do not know what the OPTIMISM collective is. -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 Season 8 Developer Advisory Board Charter amendment\n\n Elections 💼\n\n season-8\n\n Developer Advisory Board: Seasons 8 Charter Amendment\nProposed Council or Board Lead: Ed (wildmolasses) \nPlease link to any previous work or qualifications to be Council or Board Lead: \n\nAtlas profile\nDAB member S6\nDAB O…\n\n read more\n\n 7\n\n 431\n\n Jul 2025\n\n Internal Operating Procedures (IOP) for Developer Advisory Board: Season 8\n\n Internal Operating Procedures\n\n season-8\n\n Seasons 8 Developer Advisory Board - Internal Operating Procedures (IOPs)\nThe Internal Operating Procedures in this document govern the activities of the Season 8 Developer Advisory Board. This document sets forth the pr…\n\n read more\n\n 0\n\n 67\n\n Aug 2025\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 Developer Advisory Board - S6 Internal Operating Procedures\n\n Internal Operating Procedures\n\n The internal operating procedures in this document govern the activities of the Season 6 Developer Advisory Board. The document sets forth the processes the DAB will follow in fulfilling our charter, including supporting…\n\n read more\n\n 3\n\n 316\n\n Jul 2024\n\n Voting Cycle Roundup #26\n\n Voting Cycles\n\n season-6\n\n Cycle #26 began on Thursday August 8th at 19:00 GMT and runs until Wednesday August 28th at 19:00 GMT. Additionally, the Citizens’ House will have a one-week period to veto any Upgrades approved by the Token House, immed…\n\n read more\n\n 4\n\n 304\n\n Apr 2025","tokens":1042,"squid":"spider-07","role":"Council Spider","at":1791346224758,"hash":"b75053f84f3316e2a99e6afde298a74f735cec04"}
{"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":"spider-08","role":"Oracle Spider","at":1791346230333,"hash":"f3d0b9fb0e78582ac136fbfeef3ec9a874d4be3e"}
{"url":"https://akash.network/docs/providers/getting-started/should-i-run-a-provider/","domain":"akash.network","title":"Should I Run an Akash Provider? | Akash Network - Your Guide to Decentralized Cloud","text":"Should I Run an Akash Provider? Akash providers earn revenue by offering compute resources to the decentralized cloud marketplace. But is it right for you?\nThis guide helps you evaluate if running a provider makes sense for your situation.\n\nWhat is an Akash Provider?\nAkash Network is a decentralized cloud marketplace where users can lease compute resources in a permissionless and open environment. As an Akash provider, you contribute your compute resources to the network and earn revenue by hosting workloads for tenants.\nProviders can offer:\n\nCPU/Memory/Storage - Standard compute resources\nGPUs - High-demand resources for AI/ML and rendering\nPersistent Storage - Data that survives restarts\nStatic IPs - Dedicated IP addressing\n\nBenefits of Running a Provider\nRevenue Opportunities\n\nEarn ACT (compute credit) for hosting workloads; all lease settlements pay providers in ACT\nSet your own pricing\nHigher demand for GPU resources\nPersistent storage premium pricing\n24/7 passive income potential\n\nSupport Decentralization\n\nHelp build the decentralized cloud\nReduce dependence on centralized providers\nSupport censorship-resistant infrastructure\nJoin a global network of providers\n\nFlexible Scaling\n\nStart small, scale as you grow\nAdd resources incrementally\nControl what workloads you accept\nAdjust pricing based on demand\n\nRequirements & Considerations\nYou’re a Good Fit If You Have:\nTechnical Skills:\n\nLinux system administration experience\nKubernetes knowledge (or willingness to learn)\nBasic networking understanding\nCommand-line comfort\n\nResources:\n\nSpare compute capacity (physical or cloud)\nStatic IP address or dynamic DNS\nReliable internet connection (100+ Mbps)\nTime for initial setup (15 minutes to 2 hours, method dependent)\nTime for maintenance (2-4 hours/week)\n\nFinancial:\n\nAKT for bid escrow (0.5 AKT per bid) and gas\n~0.005 AKT bid fee per bid submission\nAbility to cover electricity/hosting costs\nCapital for hardware (if needed)\n\nYou Might Want to Reconsider If:\n\nNo Kubernetes experience and not interested in learning\nUnreliable internet connection\nCan’t commit time for maintenance\nHardware doesn’t meet minimum requirements\nExpecting immediate profit (ROI takes time)\n\nSetup Options\nThere are three ways to set up an Akash provider:\n1. Provider Playbook (Recommended for Most)\nBest for: Those who want automated setup\n\nUses Ansible playbooks for automation\nStandardized, repeatable process\nHandles Kubernetes + Provider setup\nLess room for error\nTime: ~1 hour\n\n2. Kubespray Setup\nBest for: Advanced users who want full control\n\nComplete control over configuration\nGood for custom setups\nRequires more Kubernetes knowledge\nMore flexibility\nTime: 1-2 hours\n\n3. Provider Console\nBest for: Users with no Kubernetes experience\n\nWeb-based interface\nNo K8s knowledge required\nEasiest to get started\nManaged Kubernetes setup\nTime: 15-30 minutes\n\nCost Considerations\nInitial Costs\n\nHardware: 500−5,000+ (or existing hardware)\nACT: Minimum per-lease escrow deposit in ACT (e.g. ~5 ACT); have some AKT for gas and bid fees\nBid Fees: ~0.005 AKT per bid submission\nSetup Time: Your time investment\n\nOngoing Costs\n\nElectricity: $20-200+/month (depending on hardware)\nInternet: $50-100/month (business connection recommended)\nMaintenance: 2-4 hours/week of your time\n\nRevenue Potential\n\nCPU/Memory: $10-100+/month (highly variable)\nGPUs: $100-1,000+/month (high demand)\nPersistent Storage: $10-50+/month\nNote: Revenue depends on capacity, uptime, pricing, and market demand\n\nTime Investment\nInitial Setup\n\nProvider Playbook: ~1 hour\nKubespray Setup: 1-2 hours\nProvider Console: 15-30 minutes\n\nOngoing Maintenance\n\nMonitoring: 30 min/day\nUpdates: 1-2 hours/month\nTroubleshooting: Variable (2-4 hours/week average)\n\nNext Steps\nReady to Proceed?\n\nHardware Requirements → - Review detailed hardware specs\nProvider Earn Calculator → - Calculate your potential earnings\nSetup & Installation → - Choose your setup method\n\nStill Deciding?\n\nAsk in Discord: discord.akash.network - #providers channel\nBrowse Active Providers: Provider Explorer - See active providers, their resources, and lease counts\nCheck Pricing: Provider Earn Calculator - Estimate your earnings\n\nQuestions? Join the provider community on Discord and ask in #providers! \nEdit page on github\n GPU Availability Hardware Requirements","tokens":1076,"squid":"spider-03","role":"Compute Spider","at":1791346231855,"hash":"8eba597ff024f9f6a9815d19bda0239f95ec3845"}
{"url":"https://gov.optimism.io/t/internal-operating-procedures-iop-for-developer-advisory-board-season-8/10213/1","domain":"gov.optimism.io","title":"Internal Operating Procedures (IOP) for Developer Advisory Board: Season 8 - Elections 💼 / Internal Operating Procedures - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n Internal Operating Procedures (IOP) for Developer Advisory Board: Season 8 \n\n Elections 💼Internal Operating Procedures\n\n season-8\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Aug 2025\n\n 1 / 1\n\n Aug 2025\n\n Aug 2025\n\n post by wildmolasses on Aug 11, 2025\n\n wildmolasses\n\n Seasons 8 Developer Advisory Board - Internal Operating Procedures (IOPs)\nThe Internal Operating Procedures in this document govern the activities of the Season 8 Developer Advisory Board. This document sets forth the processes the board will follow in fulfilling the Seasons 8 & 9 Charter and operating within its governance-approved budget.\nIf a discrepancy ever arises between a Charter and the Internal Operating Procedures (IOPs), the Charter always takes precedence and supersedes the IOPs.\nCommunications\n\nThe community can get in touch with the Developer Advisory Board by posting on our official S8 & S9 Communication Thread on the forum.\nThe DAB will host Office Hours on a recurring basis. The schedule and topics will be posted in the Communication Thread and on the public governance calendar.\nThe Lead is the primary spokesperson for major decisions. The Ops Lead may provide regular, informal updates on board activities in the Communication Thread.\n\nCommunity Feedback\n\nThe primary initiatives for collecting community input are the public Forum Communication Thread and our regularly scheduled Office Hours.\nWe encourage stakeholders (delegates, app/chain developers, and users) to use these channels to provide feedback on our operations, grant programs, and protocol upgrade assessments.\n\nCycle Management\nProtocol Upgrade Cycle\n\nPre-Upgrade Intake: The DAB is encouraged to ask questions and motivate clarity in the period before the upgrade forum post is posted. The Ops Lead will monitor relevant R&D discord channels and distribute materials for any initial, informal review.\nPublic Review Period (7 Days): The official clock starts when an upgrade is posted to the public forum. All 7 voting members are expected to conduct their full, independent review during this week, assessing the upgrade against our charter criteria.\nDebate & Synthesis: During the Review Period, the Lead will facilitate a discussion to synthesize findings. A synchronous call will be scheduled by the Ops Lead if needed. The goal is to finalize the board’s collective view before the voting period begins.\nVoting Period (7 Days): Following the review period, a 7-day formal vote will be conducted on a public platform (e.g., Snapshot). The Ops Lead is responsible for setting up the vote and ensuring all members cast their ballot. Because of the critical nature of this vote, a missed vote without prior notice will trigger a performance review.\nCommunication: Following the vote, the Lead will post the final decision and rationale to the public forum.\n\nDeveloper Adoption Grants\n\nGrant applications for both Audit Grants and Foundation Missions will be reviewed on a rolling basis, managed by their respective Program Stewards. The target is to provide an initial response to all applicants within 14 days (max) of submission.\n\nWorkflow Management\n\nPrimary Tooling:\n\nCommunication: All internal discussions will be conducted in Telegram, managed by the Ops Lead.\nTask & Application Tracking: The Ops Lead, in coordination with the Program Stewards, will track tasks in a public GitHub Projects board.\n\nNotifications: The Ops Lead is responsible for all internal notifications regarding deadlines, meeting schedules, and required actions.\n\nInternal Consensus and Voting\n\nProtocol Upgrades: A supermajority of 5/7 votes from the voting members is required to approve a protocol upgrade.\nGrant Program Decisions: Recommendations from Program Stewards for grant funding or team selection are optimistically approved.\nTie-Breaker: For internal decisions requiring a simple majority, the Lead may serve as a tie-breaker in the event that consensus cannot otherwise be reached among the 7 voting members.\nConflicts of Interest: All members must declare potential conflicts of interest. Conflicts related to grant applicants may include: direct employment, investment, advisory roles, or code contributions. A conflict of interest may require the member to abstain from a vote or decision, with the abstention attributed to the COI.\n\nChange Process\n\nChanges to these Internal Operating Procedures can be proposed by any member of the DAB.\nThe implementation of any change requires the approval of a simple majority (4/7) of the voting members. The Ops Lead is responsible for recording the changes as comments on this post.\nUnless urgent, amendments should take effect starting the next Cycle.\n\n Seasons 8 & 9 Developer Advisory Board: Communication Thread\n\n Optimism Gov Summary\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Developer Advisory Board - S7 Internal Operation Procedures\n\n Internal Operating Procedures\n\n The Internal Operating Procedures in this document govern the activities of the Season 7 Developer Advisory Board. This document sets forth the processes the Developer Advisory Board will follow in fulfilling the Charter.…\n\n read more\n\n 0\n\n 136\n\n Feb 2025\n\n Developer Advisory Board - S6 Internal Operating Procedures\n\n Internal Operating Procedures\n\n The internal operating procedures in this document govern the activities of the Season 6 Developer Advisory Board. The document sets forth the processes the DAB will follow in fulfilling our charter, including supporting…\n\n read more\n\n 3\n\n 316\n\n Jul 2024\n\n Season 8 Developer Advisory Board Charter amendment\n\n Elections 💼\n\n season-8\n\n Developer Advisory Board: Seasons 8 Charter Amendment\nProposed Council or Board Lead: Ed (wildmolasses) \nPlease link to any previous work or qualifications to be Council or Board Lead: \n\nAtlas profile\nDAB member S6\nDAB O…\n\n read more\n\n 7\n\n 431\n\n Jul 2025\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 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 346\n\n 3d","tokens":1681,"squid":"spider-07","role":"Council Spider","at":1791346234845,"hash":"1425787bc6e4d283034e1855ac9f18e0711babac"}
{"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":"spider-08","role":"Oracle Spider","at":1791346239600,"hash":"a5fe1099340513a034e53673aff8a5a7f6144de1"}
{"url":"https://gov.optimism.io/c/elected-reps/83","domain":"gov.optimism.io","title":"Latest Elections 💼 topics - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n Latest topics in Elections 💼\n\n Elections 💼\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 Elections category\n\n Elections 💼\n\n This category is for any Elected Representative Structure (i.e., councils). \nThese are the boards, commissions, and councils within the Optimism Collective.\n\n 1\n\n 2.5k\n\n Dec 2024\n\n Season 9: Security Council Cohort B Elections\n\n Elections 💼\n\n season-9\n\n As outlined in the Security Council Charter, it is time the Optimism Security Council to hold re-elections for Cohort B. All elected members will serve a 12 month term and there are no term limits. \nThe current membershi…\n\n read more\n\n 12\n\n 449\n\n Jun 15\n\n Season 8 and 9: Budget Board Member Ratification\n\n Elections 💼\n\n season-7\n\n Season 8 and 9: Budget Board Member Ratification\nContext\n\nFor full context on the Budget Board, please read the Budget Board Charter. \n\nThe Foundation is proposing to appoint the following members to the Budget Board, as…\n\n read more\n\n 12\n\n 820\n\n Feb 5\n\n Proposed Midterm Adjustment for Seasons 8 and 9 Operating Budget\n\n Elections 💼\n\n The following is a non-binding proposal for the Collective to consider in passing a Midterm Adjustment to the DAO Operating Budget for Seasons 8 and 9. The proposal is informed by the Budget Board’s good faith review of …\n\n read more\n\n 1\n\n 190\n\n Jan 28\n\n Seasons 8 and 9 Budget Board Communication Thread\n\n Elections 💼\n\n The Budget Board is an advisory board that exists to help the Collective bootstrap critical infrastructure and frameworks to enable the Collective to make sound financial and economic decisions. \nThe Budget Board’s Seaso…\n\n read more\n\n 16\n\n 516\n\n Jan 19\n\n Budget Board Advisory Proposal for Governance Fund: Season 9\n\n Elections 💼\n\n The following is a non-binding proposal for the Collective to consider in passing a Token House Budget for Season 9. The proposal is informed by the Budget Board’s good faith review of historical information provided to …\n\n read more\n\n 1\n\n 143\n\n Jan 9\n\n Liquid Staking RFP\n\n Elections 💼\n\n Introduction\nThe Optimism Collective currently holds ~21.5K ETH in its treasury. ETH is not just a reserve asset; it is a strategic tool for strengthening Optimism and the broader Collective. This RFP sets out a framewor…\n\n read more\n\n 9\n\n 1.5k\n\n Nov 2025\n\n Season 8: Security Council Elections - Cohort A and Lead\n\n Elections 💼\n\n As outlined in the Security Council Charter, it is time the Optimism Security Council to hold re-elections for Cohort A. All elected members will serve a 12 month term and there are no term limits. \nThe current membershi…\n\n read more\n\n 0\n\n 276\n\n Sep 2025\n\n Budget Board Proposal for Retro Funding for Season 8\n\n Elections 💼\n\n Please note: this proposal has been edited. You can find previous versions as Appendix. \n\nSummary\nAs part of the citizens house missions budget, the Budget Board is providing a final proposal for community review. \nWe r…\n\n read more\n\n 16\n\n 872\n\n Aug 2025\n\n Security Council Season 7 Retroactive Funding Request\n\n Renewal\n\n season-7,season-8,season-9\n\n OPSC Season 7 Retroactive Funding\nAbstract\nThe Optimism Security Council (OPSC) is requesting 346,920 OP from the Season 8 & 9 DAO Operating Budget for Season 7 retroactive funding. \nThis request is being put forward to …\n\n read more\n\n 19\n\n 693\n\n Aug 2025\n\n Internal Operating Procedures (IOP) for the M&M Council: Season 8\n\n Internal Operating Procedures\n\n season-8\n\n M&M Council S8 Internal Operating Procedures\nThe Internal Operating Procedures in this document govern the activities of the Season 8 Milestones and Metrics Council. This document sets forth the processes the Milestones …\n\n read more\n\n 0\n\n 85\n\n Aug 2025\n\n Internal Operating Procedures (IOP) for Developer Advisory Board: Season 8\n\n Internal Operating Procedures\n\n season-8\n\n Seasons 8 Developer Advisory Board - Internal Operating Procedures (IOPs)\nThe Internal Operating Procedures in this document govern the activities of the Season 8 Developer Advisory Board. This document sets forth the pr…\n\n read more\n\n 0\n\n 68\n\n Aug 2025\n\n Security Council Member Self-Nomination: World Foundation\n\n Elections 💼\n\n season-7\n\n Organization ID: World Foundation \nDoes this nomination represent an individual or organization: Organization \nPlease link to any contributions that demonstrate you meet the eligibility criteria outlined in the Security …\n\n read more\n\n 22\n\n 1.1k\n\n Aug 2025\n\n Security Council Self-Nomination: Ink\n\n Elections 💼\n\n season-7\n\n Organization ID: inkonchain \nDoes this nomination represent an individual or organization: Organization \nPlease link to any contributions that demonstrate you meet the eligibility criteria outlined in the Security Counci…\n\n read more\n\n 11\n\n 404\n\n Aug 2025\n\n Internal Operating Procedures (IOP) for the Grants Council: Season 8\n\n Internal Operating Procedures\n\n The Internal Operating Procedures in this document govern the activities of the Season 8 Grants Council. This document outlines the processes the Grants Council will follow in fulfilling the Charter. This structure is su…\n\n read more\n\n 0\n\n 79\n\n Aug 2025\n\n Grants Council Operating Budget for Season 8 and 9\n\n Elections 💼\n\n season-8,season-9\n\n Proposed Council Lead: Gonna.eth \nProposed Operating Budget: Budget: 980.000 OP for both S8 and S9. \n\n490,000 OP per Season (+100.000 OP compared to S7)\n\nContact Info: gdhannte@gmail.com \nPrevious Work and Qualifications\n…\n\n read more\n\n 16\n\n 677\n\n Aug 2025\n\n Developer Advisory Board Operating Budget Seasons 8 and 9\n\n Renewal\n\n season-8,season-9\n\n Developer Advisory Board Operating Budget: Seasons 8 & 9\nDeveloper Advisory Board Lead: Ed / wildmolasses \nProposed Operating Budget: 974,000 OP 969,544 OP \nContact Info: @wildmolasses \nCouncil Charter: OPerating-manual…\n\n read more\n\n 13\n\n 567\n\n Aug 2025\n\n Security Council Operating Budget Seasons 8 & 9\n\n Renewal\n\n season-8,season-9\n\n OPSC Operating Budget — Seasons 8 & 9\nProposed Lead: alisha.eth \nProposed Operating Budget: 1,514,440 OP 1,510,250 OP \nContact Info: DM @Alisha on the forum \nCouncil Charter\nLink to existing Security Council Charter on…\n\n read more\n\n 15\n\n 642\n\n Aug 2025\n\n Milestones & Metrics Council Operating Budget Seasons 8 and 9\n\n Renewal\n\n season-8,season-9\n\n M&M Council Operating Budget — Seasons 8 & 9\nProposed Lead: @Juanbug_PGov \nProposed Operating Budget: 492,350 OP/Season (984,700 OP total) \n\nIn depth breakdown worksheet here.\n+320,000 OP relative to previous season. Sam…\n\n read more\n\n 17\n\n 629\n\n Jul 2025\n\n Developer Advisory Board Member Self-Nomination Thread\n\n Elections\n\n season-8,season-9\n\n The goal of this forum post is to provide governance participants the ability to ask questions to candidates of the Developer Advisory Board. \nAs a candidate, please comment on this forum post below after you’ve self-nom…\n\n read more\n\n 15\n\n 591\n\n Jul 2025\n\n Budget Board Advisory Proposal for Token House Missions: Seasons 8\n\n Elections 💼\n\n season-8\n\n The following is a non-binding proposal for the Collective to consider in passing a Token House Budget for Seasons 8. The proposal is informed by the Budget Board’s good faith review of historical information provided to…\n\n read more\n\n 2\n\n 334\n\n Jul 2025\n\n [FINAL] Budget Board Advisory Proposal for the DAO Operating Budget for Seasons 8 and 9\n\n Elections 💼\n\n Budget Board Advisory Proposal for the DAO Operating Budget for Seasons 8 and 9 (Updated)\nThe following is a non-binding proposal for the Collective to consider in passing a DAO Operating Budget for Seasons 8 and 9. The …\n\n read more\n\n 32\n\n 1.7k\n\n Jul 2025\n\n Season 8 and 9 Grants Council Operations Role Delegate Approval Thread\n\n Elections\n\n season-8,season-9\n\n For any Council / Board where there are greater than 4x the amount of nominees per position, four top 100 delegate approvals are required to reduce the number of candidates. This ensures that only the most qualified cand…\n\n read more\n\n 6\n\n 282\n\n Jul 2025\n\n Grants Council Operations Self-Nomination Thread\n\n Elections\n\n season-8\n\n The goal of this forum post is to provide governance participants the ability to ask questions to candidates of the Grants Council Operations Role. \nAs a candidate, please comment on this forum post below after you’ve se…\n\n read more\n\n 10\n\n 357\n\n Jul 2025\n\n Season 8 Council and Board Mandate Guidance\n\n Elections 💼\n\n season-8\n\n Timeline for Prospective Leads\n\n Note: Council terms will now last 12 months. Elected members will serve for Seasons 8 and 9. \n\nJune 13th - June 23rd: Charter Amendments\n\nAll Lead candidates can draft and post C…\n\n read more\n\n 5\n\n 383\n\n Jul 2025\n\n Season 8 and 9 Election Information\n\n Elections\n\n season-8,season-9\n\n Welcome to the Optimism Governance Season 8 Elections! \nBelow, you’ll find all the key information you need to know regarding elections. \nFor Candidates\nThere are three different elections happening for Season 8 and 9 - …\n\n read more\n\n 1\n\n 387\n\n Jul 2025\n\n Milestone and Metrics Council Reviewer Self-Nomination Thread\n\n Elections\n\n season-8,season-9\n\n The goal of this forum post is to provide governance participants the ability to ask questions to candidates of the Milestone and Metrics Council. \nAs a candidate, please comment on this forum post below after you’ve sel…\n\n read more\n\n 8\n\n 435\n\n Jul 2025\n\n Grants Council Final Reviewer Self-Nomination Thread\n\n Elections\n\n season-8,season-9\n\n The goal of this forum post is to provide governance participants the ability to ask questions to candidates of the Grants Council Final Reviewer Team. \nAs a candidate, please comment on this forum post below after you’v…\n\n read more\n\n 8\n\n 415\n\n Jul 2025\n\n Season 8 Developer Advisory Board Charter amendment\n\n Elections 💼\n\n season-8\n\n Developer Advisory Board: Seasons 8 Charter Amendment\nProposed Council or Board Lead: Ed (wildmolasses) \nPlease link to any previous work or qualifications to be Council or Board Lead: \n\nAtlas profile\nDAB member S6\nDAB O…\n\n read more\n\n 7\n\n 431\n\n Jul 2025\n\n Developer Advisory Board - Season 7 Retrospective\n\n Elections 💼\n\n season-7\n\n Developer Advisory Board Season 7 Retrospective\n1. 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 milestone…\n\n read more\n\n 1\n\n 152\n\n Jun 2025","tokens":2591,"squid":"spider-07","role":"Council Spider","at":1791346255020,"hash":"ce6a0a4831e3aedd320739a6686f060ac82ce02a"}
{"url":"https://forum.across.to/t/updated-acx-market-making-proposal-arrakis-palm/1701/4","domain":"forum.across.to","title":"Updated - [ACX] Market Making Proposal - Arrakis PALM - Proposals - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n Proposals\n\n treasury-funding\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Aug 2023\n\n 4 / 4\n\n Sep 2023\n\n Aug 2023\n\n post by barbarossa_Arrakis on Aug 11, 2023\n\n post by Kevin_UMA on Aug 14, 2023\n\n post by barbarossa_Arrakis on Aug 15, 2023\n\n barbarossa_Arrakis\n\n All valid questions \n\nThis is going to be a separate vault with Across DAO’s fund. For the maintenance of each vault, there is an operational overhead. If an asset doesn’t have much volume, $3k is barely enough to cover the operational cost.\n\nFees are collected at each rebalance, and the part for the protocol is compounded back to the vault.\n\nAs explained in the first point, this 1% is essentially a somewhat hedge for operational cost, while the actual revenue for Arrakis is from the trading fee split. The deeper PALM makes the liquidity, the more volume PALM facilitates, and hence the more fees it earns. Therefore, Arrakis has every incentive to conduct the best practice in market making so that both Arrakis and the customer protocol can reap the highest rewards.\nAnother important aspect as opposed to a CEX market maker is the non-custodial nature of Arrakis. Protocols have the complete autonomy in deciding if they want to remove their liquidity, for reasons including not feeing content with the performance.\n\nIt is taken quarterly.\n\n 1 month later\n\n Closed on Sep 14, 2023\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 ACX Market Making Proposal - Arrakis PALM\n\n Active Proposals\n\n treasury-funding\n\n Active Proposals\n\n 3\n\n Jun 2023\n\n Across ($ACX) Community Initial Liquidity Proposal\n\n Passed Proposals\n\n Passed Proposals\n\n 49\n\n Nov 2022\n\n $ACX Liquidity - Update and Feedback Wanted\n\n Ideas & Feedback\n\n Ideas & Feedback\n\n 7\n\n Jun 2023\n\n Velodrome Liquidity Program Extension\n\n Active Proposals\n\n Active Proposals\n\n 19\n\n Jan 2024\n\n Reduce ACX emissions for ACX LPs, WBTC LPs and wstETH/ACX LPs\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 11\n\n Aug 2024","tokens":2015,"squid":"spider-09","role":"Bridge Spider","at":1791346267382,"hash":"df5e7a86216c3e6f962758933108944f33e5f4e1"}
{"url":"https://gov.optimism.io/t/season-8-and-9-budget-board-member-ratification/9819/1","domain":"gov.optimism.io","title":"Season 8 and 9: Budget Board Member Ratification - Elections 💼 - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n Season 8 and 9: Budget Board Member Ratification \n\n Elections 💼\n\n season-7\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 6\n min\n\n Apr 2025\n\n 1 / 15\n\n Apr 2025\n\n Feb 5\n\n post by system on Apr 7, 2025\n\n system\n\n Season 8 and 9: Budget Board Member Ratification\nContext\n\nFor full context on the Budget Board, please read the Budget Board Charter.\n\nThe Foundation is proposing to appoint the following members to the Budget Board, as per the Collective Council Framework.\nAs we transition all Council and Board terms to 12 months, starting in Season 8 & 9, members will serve an initial term of 12 months, after which point membership will be determined via alternative selection methods, such as elections. More detail is available in the Budget Board Charter.\nThe Budget Board’s term will run from May 2025 - May 2026 as onboarding is required prior to the start of Season 8 so that proposals by the Budget Board may be considered during the upcoming Reflection Period.\nEligibility\nMembers of the Board will be responsible for bootstrapping the Collective’s ability to make sound financial and economic decisions. Their main role is to identify the set of data, models, and algorithms needed to develop cohesive frameworks for token allocation and treasury management. While the Board will initially make proposals, subject to governance approval, their goal is to reduce their role over time to maintenance of public infrastructure and management of governance-approved algorithms.\nParticipants on the Budget Board were selected to bring the following skillsets to the Board:\n\nExperience in financial forecasting and /or corporate budgeting\nAbility to inform decision making with data, computation, and / or automation\nProfessional capital allocation and/ or portfolio management\nExperience allocating capital to support public goods, supporting sustainable ecosystem growth, and/or building long term capital allocation systems\nContext on Optimism governance and / or the Optimism Foundation’s strategic priorities\n\nProposed Membership\nLead\n\nDane Lund - Founder of Lund Ventures, former Alliance DAO Core Contributor, former Grants Council Lead (Genesis Cohort/Season 3, Season 4)\n\nGenesis Cohort\n\nToken House Representatives\n\nXochitl Cazador - Chief of Staff and Head of Operations at Optimism Foundation\n\nXochitl will be able to facilitate tight coordination between the Optimism Foundation’s Finance Team and the Budget Board, ensuring the Board has access to all relevant information. She brings over 15 years of experience in Strategy, Planning, and Operations, where she has led initiatives involving capital allocation, portfolio management, prioritization frameworks, and the development of models like CAPM and efficient frontiers to guide strategic decision-making. Xochitl is also deeply involved in the Foundation’s Intent setting process and can, therefore, lend strategic insight into the Board’s operations.\nMember will not receive an OP Stipend\n\nMichael Silberling, Data Analyst at OP Labs\n\nMichael is responsible for Optimism ecosystem intelligence. He has deep knowledge of onchain analytics, chain economics, and his insights inform decision making across Labs and the Foundation. He is responsible for much of the reporting that drives business reviews but also metrics that measure the health and success of Optimism.\nMember will not receive an OP Stipend\n\nKatie Garcia - Partner and Head of Operations at UDHC, formerly at Maker Foundation, and Token House Delegate\n\nKatie will bring a high degree of governance context to the Board as a result of her experiences working with Optimism and Maker governance. She is also a full-time investor, adding a valuable perspective on capital allocation.\n\nCitizen House Representatives\n\nCarl Cervone: Founder of Open Source Observer and Citizen\n\nThrough his work with Open Source Observer, Carl has been critical in building out the Collective’s public data infrastructure, which will be a key input into the frameworks developed by the Board.\n\nDivya Siddarth: Co-founder and Executive Director of the Collective Intelligence Project\n\nDivya is the Co-Founder and Executive Director of the Collective Intelligence Project, an organization focused on the development of effective, decentralized, and agentic decision-making. With a degree in computational decision analysis and a wealth of experience across economics, artificial intelligence, and governance, she brings an incredibly important perspective to the Board.\n\nEva Beylin: Member of the Optimism Foundation Board, previous Director of The Graph Foundation, Angel Investor\n\nEva Beylin brings deep strategic insight as a member of the Optimism Foundation’s Board and her past experience growing a blockchain data ecosystem. Her previous work overseeing ecosystem growth, grants and treasury management at The Graph will be immensely informative for her role on the Budget Board.\n\nRatification Process\nThe Token House will ratify this proposal to approve the Token House representatives and Lead.\nThe Citizens House will ratify this proposal to approve the Citizens House representatives and Lead.\nEach House may remove the representatives of the House to which they belong, at any time, via the Representative Removal proposal outlined in the Operating Manual. The Lead may be removed by either House.\nThis proposal will move to a vote in Voting Cycle #36.\n\n Season 8 & 9: Budget Board Charter\n\n Token House Community Call [April 8th 18:00 UTC]\n\n SEEDGov - Delegate Communication Thread\n\n Joint House Community Call [April 22nd 18:00 UTC]\n\n Voting Cycle Guide #36\n\n 2\n\n 2\n\n 2\n\n read \n\n 6\n min\n\n Unlisted on Apr 7, 2025\n\n Listed on Apr 8, 2025\n\n post by joanbp on Apr 8, 2025\n\n joanbp\n\n Congratulations to everyone nominated! \nI understand that the Foundation is proposing these 7 people to serve as members and lead of the first iteration of the budget board.\nCould you share what has been the process behind the choice?\nAlso, since citizens are being asked to vote in favor of the lead and the three Citizens House representatives - and the latter three in turn are expected to be accountable to the Citizens House - it would be great to hear their take on this.\n@ccerv1, @eva, Divya (sorry, I don’t know where to find your handle):\nMight you each share, here, your thoughts on how you understand your roles as representatives of the Citizens House, and what your expectations are around being members of the budget board?\n@danelund.eth:\nMight you share a bit on your thoughts around leading this first iteration of the budget board?\nI think this would help us all better understand who we are being asked to vote into office. \n\n post by lavande on Apr 8, 2025\n\n lavande\n\n Hi @joanbp, to address your first question, the Foundation may appoint the first set of members for the first term of a representative structure as outlined in the Representative Structure Framework. As the Foundation creates these structures, being able to appoint the first set of members, still subject to governance approval, allows for the assurance of high quality members to fill new positions and effectively launch a new structure. The founding set of members has a large impact on the overall success (or failure) of a structure. We did voter interviews when this policy was established and the majority felt it was better to have the Foundation appoint a trusted group at initiation than to leave it open to chance via an open election process. This was especially true in the case of the Security Council, for example.\nThe proposed members were selected specifically for the balance of skillsets outlined in the eligibility criteria.\n\n post by Michael on Apr 8, 2025\n\n Michael\n\n Great list of initial members and I am STOKED to see @danelund.eth back in the mix!\nAfter working under Dane on the first iterations of the grants council, it’s pretty apparent that he has an enormous amount of competence in starting something from zero, so it’s great to see him leading another new effort.\nThis initial list has my full support.\n\n post by mel.eth on Apr 8, 2025\n\n mel.eth\n\n Voting yes on the Budget Board ratification. I’ve spent time on Uniswap’s treasury working group and want to offer a few focused suggestions to strengthen this structure early.\nFirst, the flat 40k OP compensation doesn’t map to the level of responsibility. I’d encourage adding a performance component based on outputs like budget frameworks, emissions modeling, or tool adoption.\nSecond, without clear functional tracks, you risk coordination drag. I’d recommend assigning leads for areas like DAO ops, rewards, staking, and mission budgets so the work moves in parallel and accountability is legible.\nThird, forum engagement from some members has been low. Increasing the cadence of public outputs or syncs would help bridge trust with active Delegates and Citizens.\nLastly, Foundation-heavy composition is understandable short-term, but a transition plan would go a long way toward reinforcing credibility and decentralization in future seasons.\nI’m optimistic, and net happy to see this pilot is moving forward. Wishing the cohort a productive and focused term.\n\n post by joanbp on Apr 8, 2025\n\n joanbp\n\n lavande\n\n Thank you, @lavande!\nI agree that it makes sense for the Foundation to appoint these first members.\nMy question was aimed at understanding the process by which the Foundation had done this.\nSeeing as we are being asked to approve of the choice - and also considering that in future the collective might be asked to take on more responsibility for the process - it seems prudent to not just sign in blind faith, but to try and illuminate how these things work. To help us all learn from it.\n\n post by GFXlabs on Apr 9, 2025\n\n GFXlabs\n\n Overall, this is a solid slate of initial members. Over time, we would like to see a steady movement away from Labs and Foundation affiliates given the potential for conflicts of interest that creates, since representatives are supposed to represent Citizen and Token Houses.\nOne suggestion, to prevent full turnover of the board at any given time, would be to make half of these seats only 6-month terms for this inaugural term. Then the board is staggered, and ensures no institutional knowledge within the Budget Board is lost due to elections/resignations all coinciding together. Budgets in particular, whether from the actual budgetary details or from familiarity with processes and workflows in creation of them, are susceptible to disruption if the entire board turned over at once.\n\n post by lavande on Apr 9, 2025\n\n lavande\n\n joanbp\n\n On the process: Stakeholders at the Foundation and within the Collective Feedback Commission were asked for recommendations of people that met the eligibility criteria. From that initial list, we tried to ensure candidates met the skillsets required while balancing representation from the OP Foundation, the OP Foundation Board, and OP Labs’ (to ensure strategic cohesion); and that 2 candidates also be a long-time delegate / citizen. 1 candidate is new to the ecosystem but has done well recognized research on governance systems and has a degree in computational decision making, which is very relevant to what the Budget Board does. We also asked a representative from the Ethereum Foundation, but they declined due to bandwidth constraints.\nIn terms of how net new contributors will represented and accountable to each House: we are preparing extensive onboarding materials for members, which clearly outline the goals of each house as publicly documented, and are onboarding them for ~6 weeks before they need to make their first proposal to ensure they have all the context they need. Many of the members of the Security Council and Developer Advisory Board were also new to Optimism governance in their first term. It’s important that we continue to bring net new contributors into the ecosystem, and don’t just entrench the power of incumbents or long-time contributors. It’s part of why it’s not a requirement to be a delegate or a citizen to be on a Council or a Board. Onboarding plays an important role in facilitating this.\nSome community members have asked for a Q&A call with members. The Foundation would be happy to facilitate this some time in May once members have completed onboarding!\n\n 20 days later\n\n post by Sinkas on Apr 29, 2025\n\n Sinkas\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’re voting FOR the proposal.\nWe are familiar with all the proposed members for the first term of the board in one way or another, and we are confident in their abilities to carry out the tasks outlined in the board’s charter.\nOne thing we would like to recommend to the board is that they document the learnings along the way, so that when a new board is elected in 2026 and onwards, they can benefit from it.\n\n L2BEAT - Delegate Communication Thread\n\n 1 month later\n\n post by Atomx on Jun 13, 2025\n\n Atomx\n\n Hi,\nThank you for sharing this very detailed proposal. After reviewing it, I wanted to raise a point that could be worth considering as part of the governance and resource allocation discussions:\nIt might be valuable to introduce a specific reward or incentive mechanism for long-term token holders. These members contribute to the ecosystem’s stability and sustainability by maintaining their commitment over time. Adding an extra benefit or weight to their participation could further encourage long-term alignment and strengthen the community’s engagement in the strategic decisions of the Budget Board.\nIf this idea could bring value, I’m happy to explore it further.\nBest regards,\nAtomX\n\n 16 days later\n\n post by kyve on Jun 29, 2025\n\n kyve\n\n Congratulations to all team members and community\n\n post by MBBCH15 on Jun 29, 2025\n\n MBBCH15\n\n Apologies for the delayed response, but I still wanted to share my support and appreciation for the proposed Budget Board for Seasons 8 and 9.\nEven looking back, it’s clear that the Foundation made a strong, forward-thinking selection. The balance of strategic insight, technical expertise, and governance experience across both Token House and Citizen House representatives sets a solid foundation for sustainable and data-informed capital allocation.\nDane Lund’s continued leadership as Lead brings welcomed consistency, especially as we transition into a more structured, long-term framework. The inclusion of voices like Xochitl, Michael, and Katie on the Token House side ensures alignment between data, operations, and governance, while Citizen House reps like Carl, Divya, and Eva bring essential public goods perspective and innovative thinking to the table.\nThis cohort was clearly designed to not only build robust economic models and algorithms but also to embody the collective intelligence and public-good mindset that makes Optimism unique.\nLooking forward to seeing how this team shapes the financial backbone of the Collective in the year ahead—and grateful for the transparency and care in the selection process.\nRetroactive support, but wholehearted nonetheless.\nTogether we scale Optimism\n\n 7 months later\n\n post by system on Feb 5\n\n system\n\n The Budget Board played an important role in helping the Collective learn about the role of governance in economic decision making. The Budget Board established initial frameworks around operating costs and budgets, as well as establishing the process for a public RFP for liquid staking protocols. The Budget Board’s work both moved the Collective forward in terms of sophistication and decentralization and provided important learnings.\nWhile we continue to believe these types of decisions benefit from cohesive frameworks and delegation, we also learned that a Council structure is a challenging structure for making them. Coordination costs are high and incentive alignment is challenging. But most importantly, the concept of a Budget Board does not align with the updated vision outlined in the Season 9 blog. The Foundation will be rolling out Capital Allocation 2.0 via a series of proposals throughout Season 9 which will allow governance to retain oversight without leveraging Council structures to make delegated decisions. As a result, the Budget Board will be dissolved, with members receiving pro-rata rewards for the portion of their term they did serve.\n\n Related topics\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 & 9: Budget Board Charter\n\n Elections 💼\n\n season-8\n\n Thank you to Collective Feedback Commission members, @spengrah and @jackanorak, for feedback on early drafts and input into the design process of the Budget Board. \nSeason 8 & 9: Budget Board Charter\nThis Charter outline…\n\n read more\n\n 8\n\n 717\n\n May 2025\n\n Season 8 Council and Board Mandate Guidance\n\n Elections 💼\n\n season-8\n\n Timeline for Prospective Leads\n\n Note: Council terms will now last 12 months. Elected members will serve for Seasons 8 and 9. \n\nJune 13th - June 23rd: Charter Amendments\n\nAll Lead candidates can draft and post C…\n\n read more\n\n 5\n\n 383\n\n Jul 2025\n\n Seasons 8 and 9 Budget Board Communication Thread\n\n Elections 💼\n\n The Budget Board is an advisory board that exists to help the Collective bootstrap critical infrastructure and frameworks to enable the Collective to make sound financial and economic decisions. \nThe Budget Board’s Seaso…\n\n read more\n\n 16\n\n 516\n\n Jan 19\n\n Ed Mazurek - Developer Advisory Board Operating Budget\n\n Elections 💼\n\n season-6\n\n Developer Advisory Board Operating Budget\nProposed Board Lead: Ed Mazurek (wildmolasses) \nProposed Board Operating Budget: 122,000 OP (+52,000 OP from last Season) \nContact Info: changes@gmail.com \nGoals of this proposal…\n\n read more\n\n 7\n\n 876\n\n May 2024\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":4575,"squid":"spider-07","role":"Council Spider","at":1791346277080,"hash":"9b4ad28823e7b87a4f700f81f4691af288f48cdd"}
{"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":"spider-05","role":"Spec Spider","at":1791346277716,"hash":"e1e43b9c593b59658bfbfc1322b18d637c87b703"}
{"url":"https://www.metaplex.com/docs/security","domain":"metaplex.com","title":"Security | Developer Hub","text":"Reporting a VulnerabilityPlease do not open a public GitHub Issue to report the vulnerability.Instead, please email security@metaplex.foundation.You should receive a response within 24-48 hours. If for some reason you do not, please follow up via email to ensure we received your original message.Please include the requested information listed below (as much as you can provide) to help us better understand the nature and scope of the possible issue:Type of issue (e.g. buffer overflow, missing ownership check, cross-site scripting, etc.)Full paths of source file(s) related to the manifestation of the issueThe location of the affected source code (tag/branch/commit or direct URL)Any special configuration required to reproduce the issueStep-by-step instructions to reproduce the issueProof-of-concept or exploit code (if possible)Impact of the issue, including how an attacker might exploit the issueThis information will help us triage your report more quickly.You may also be eligible for a bounty. More details can be found on the Metaplex Bounty Program page.AuditsOngoing automated and manual security audits are routinely performed by our audit partners Sec3, Accretion, and OtterSec.Automated audits are performed for every PR and security issues must be resolved before merging into the main branch. Manual ongoing audits are initiated for changes above a specific threshold and security issues must be resolved before merging into the main branch.OShield (formerly MadShield) is responsible for many of our historical audits.Large one-off audits are also performed when there are large changes to the code or functionality as detailed below.ProtocolLast major one-off audit dateCore2024-05-06Token Metadata2025-11-08Inscriptions2024-01-16Bubblegum/Compression2025-05-12Trifle/Fusion2023-04-13Candy Machine V32022-11-01Candy Machine V22022-11-01Auction House2022-10-24Gumdrop2022-05-16We do not have ongoing automated nor manual security audits that are routinely performed by our audit partners for our developer tools. However, audits may be ordered, facilitated, and paid for by our community of 3rd party Solana ecosystem developers or entities of their own accord.Developer ToolsLast audit dateSugar CLI*2022-08-26(*) Audited by OtterSec","tokens":564,"squid":"dotcat","role":"Tooling Spider","at":1791346287178,"hash":"040857bbef64c27b38e6a4c229c4a1a96426892d"}
{"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":"spider-05","role":"Spec Spider","at":1791346287882,"hash":"bb2aa923e499173e1145417457d55ee0117d52fe"}
{"url":"https://forum.across.to/t/tokenomics-liquidity-incentives-pair-acx-w-across-lp-tokens/1681/3","domain":"forum.across.to","title":"Tokenomics & Liquidity Incentives: Pair ACX w Across LP Tokens - Ideas & Feedback - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n Ideas & Feedback\n\n liquidity\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jul 2023\n\n 3 / 3\n\n Aug 2023\n\n Aug 2023\n\n post by eth-wei-trader on Jul 19, 2023\n\n eth-wei-trader\n\n I believe we can improve ACX liquidity while also paying for bridge liquidity - killing two birds with one stone.\nWe should pair ACX with Across LP tokens such as USDC, USDT, DAI, ETH, and WBTC on Balancer and incentivize that under a single reward locking mechanism that distributes ACX incentives. This will mean we’re paying for bridge liquidity and ACX liquidity in a single swoop. This will also be an example to the broader ecosystem that Across LP tokens can be used as superfluid collateral to earn yield.\nI’ll consider the exact incentive amount and distribution between the Across LP tokens as follow-on considerations, but I believe this idea is significantly better than incentivizing ACX liquidity and bridging LP tokens separately which significantly hurts ACX’s tokenomics.\n\n 2\n\n 1 month later\n\n post by Kevin_UMA on Aug 22, 2023\n\n Kevin_UMA\n\n I forgot to reply to this idea. Wouldn’t we need pools for Across LP tokens against WETH or USDC? In order for there to be liquidity to trade ACX vs ETH or USDC we would need to make Across LP tokens liquid as well. This seems very tricky. I think trying to figure out how to use Across LP tokens as collateral to borrow could be a starting point, but that I already see has some issues/concerns.\nIt’s an interesting idea though.\n\n post by eth-wei-trader on Aug 22, 2023\n\n eth-wei-trader\n\n CoW searchers or aggregators can simply add the functionality to withdraw from the Across LP tokens as needed within the swap transaction. For example, if ACX is paired with the Across USDC Bridge LP, then unwrapping is done as needed at the time of the swap so that the user always gets USDC or ACX, not the intermediate bridge LP.\nMain downside is that it adds gas to swaps, but I think the pro of matching bridge liquidity with ACX liquidity outweighs that con.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n $ACX Liquidity - Update and Feedback Wanted\n\n Ideas & Feedback\n\n Ideas & Feedback\n\n 7\n\n Jun 2023\n\n Reduce or Reallocate Across ACX LP emissions\n\n Ideas & Feedback\n\n liquidity\n\n Ideas & Feedback\n\n 2\n\n Sep 2023\n\n Across ($ACX) Community Initial Liquidity Proposal\n\n Passed Proposals\n\n Passed Proposals\n\n 49\n\n Nov 2022\n\n Build liquidity for $ACX on Velodrome\n\n Active Proposals\n\n treasury-funding\n\n Active Proposals\n\n 8\n\n Jul 2023\n\n Discontinue ACX Bribes on Aura and Replace with Reward Locking in the Near Term\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 5\n\n Jul 2023","tokens":2155,"squid":"spider-09","role":"Bridge Spider","at":1791346296989,"hash":"e51c9bdec9052ba312f3b15ff29414aed69f743b"}
{"url":"https://www.metaplex.com/bounty-program","domain":"metaplex.com","title":"Metaplex Bug Bounty Program | Metaplex","text":"The Metaplex Bug Bounty Program GuidelinesHow to get started with the Metaplex Bounty Program:Check the Current Program Security Tiering section below for the programs and features that are within scope. Any programs or features not included in that section are out of scope.Familiarize yourself with the vulnerability types that are out of scope.Perform your research/testing without impacting other users. (be nice!)Report your in-scope vulnerability by including written code of the exploit and instructions for reproducing the vulnerability. Submissions without clear reproduction steps may be ineligible for a reward.During the course of an investigation, it may take time to resolve the issue you have reported. We ask that you refrain from publicly disclosing details regarding an issue you’ve reported until the fix has been publicly made available. Once Metaplex has reproduced the vulnerability, you will become eligible to receive a reward in most cases.All reward amounts are determined by the Severity Guidelines and Project/Program tiers.When duplicates occur, we only award the first report that was received, provided that it can be fully reproduced.You may publish write-ups about the vulnerability, however you must wait to publish until a fix has been confirmed by the Metaplex team. If you publish before a fix is confirmed you will be ineligible for a reward.Questions or Submissions? Email bounty@metaplex.foundation.RewardsSecurity TierTier 1Tier 2Tier 3Critical$10k - $20k+$4k - $10k+$800 - $2kHigh$3k - $10k$2k - $4k$400 - $800Medium$400 - $3k$400 - $2k$200 - $400Low$40 - $400$40 - $400$40 - $200Critical issues have a soft cap for the reward amount and will be reviewed on a case-by-case basis to determine the reward amount.Severity GuidelinesCritical - Direct and immediate risk to a broad array of users. They often affect the low-level/foundational components of our application stacks or infrastructure. e.g.,Loss of fundsArbitrary code executionHigh - Attackers can read or modify highly sensitive data or behaviors that they should not be able to access. Generally more narrow scope than critical issues when judged against broadness of impact or ease of exploitation. e.g.,Modify sensitive data like Token Metadata or Auction configurationModify the ownership or permissions of sensitive dataMedium - Attackers can read or modify limited amounts of data or behaviors they are not authorized to access. Generally more narrow scope than high severity issues when judged against broadness of impact or ease of exploitation. e.g.,Circumventing the captcha for Candy MachineLow - Attackers can access extremely limited amounts of data or behavior. They may violate an expectation for how something is intended to work but allow nearly no escalation of privilege or ability to trigger unintended behavior by an attacker.Current Program Security Tiering (2026/02/13)TierProgram1Core2Token Auth Rules, Bubblegum, Candy Machine, Core Candy Machine3Gumdrop, MPL-Hybrid, Inscriptions, Bubblegum v2Only the latest versions of these programs deployed to mainnet are within scope. Programs or features not listed in the current program security tiering are out of scope, including any issues related to websites or domains. The Metaplex Program Libraries can be found here.When categorizing programs or libraries into tiers, the following inputs are considered:The importance of a program to the Metaplex community ecosystem. The more a program is depended upon or used, the more likely a program will be considered in a higher security tier. The Token Metadata Program is an example of a core, widely depended upon program whereas the Gumdrop program would be considered less important.The level of stability. The more stable, the more likely a program will be considered in a higher security tier.The level of audit and review a program has undergone. An example, whether a program has been audited by a third party security professional, or whether the Metaplex DAO has voted the program forward by community governance.LegalWhen you submit an application to our Bug Bounty program, you consent to the terms of the program, as described in more detail here.","tokens":1045,"squid":"dotcat","role":"Tooling Spider","at":1791346297808,"hash":"0f511dfe393105cb744d446bc11da4e8c0718a12"}
{"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,596Retry rate:24.7%Last updated: Oct 6, 2026, 12:02 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":"spider-05","role":"Spec Spider","at":1791346299863,"hash":"19f2d4d7ac8b6ba332fb483f747f14a82277470c"}
{"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 / 48NuFiFinanceNFTsBrowserEnglish Swap fee: 0.75%AlphaWalletNFTsMobileEnglish · Chinese Swap fee: 0%imTokenDeveloperFinanceNFTsMobileEnglish · Chinese Swap fee: 0.3% (0.04% stablecoins, lower on L2s)MEW walletNew to cryptoNFTsMobileEnglish · Russian Swap fee: variableio.finnet MPC wallet for BusinessNFTsMobileEnglish Free tier, paid plans from $399.99/monthimKey Pro Hardware WalletDeveloperFinanceHardwareNFTsDesktop · Mobile · Browser · HardwareEnglish · Chinese Device: $110, Swap fee: 0%Loopring walletNFTsMobileEnglish · Chinese Swap fee: 0.3%BurnerHardwareNFTsDesktop · Mobile · Browser · HardwareEnglish Device: $19/card, Swap fee: not disclosedExodusFinanceDesktop · Mobile · BrowserEnglish Swap fee: from 0.5%Coin WalletFinanceDesktop · MobileEnglish · Indonesian Swap fee: 0%FrameDeveloperFinanceNFTsDesktop · BrowserEnglish Edge WalletFinanceDesktop · MobileEnglish · Spanish Swap fee: 0.5% – 2%AmbireDeveloperFinanceNFTsBrowserEnglish Swap/bridge fee: 0.5%KeystoneHardwareHardwareEnglish · Chinese Device: $149TrezorFinanceHardwareDesktop · Mobile · HardwareEnglish · Spanish Device: $59 – $129, Swap fee: variableRabby WalletDeveloperFinanceNFTsDesktop · Mobile · BrowserEnglish · German Swap fee: 0.25%Cake WalletDeveloperFinanceDesktop · MobileEnglish · Spanish Swap fee: variableShapeShiftFinanceMobile · BrowserEnglish · Spanish Swap/bridge fee: 0.5% (free under $1,000, FOX-holder discounts)TahoFinanceNFTsBrowserEnglish Swap fee: 0.5%BraavosNFTsMobile · BrowserEnglish Swap fee: 0%EnkryptNFTsBrowserEnglish Swap fee: variableCypherock X1HardwareNFTsDesktop · HardwareEnglish · German Device: $99 – $179LedgerFinanceHardwareNFTsDesktop · Mobile · HardwareEnglish · Arabic Device: $79 – $399, Swap fee: variableSafeFinanceNFTsMobileEnglish Swap fee: 0.05% – 0.7%, Staking fee: 20% of rewardsCoinbase WalletNew to cryptoFinanceNFTsMobile · BrowserEnglish · German Swap fee: 1%GridPlus Lattice1HardwareNFTsDesktop · Browser · HardwareEnglish Device: $397BlockWalletDeveloperFinanceBrowserEnglish Swap/bridge fee: 0.5%Trust WalletDeveloperFinanceNFTsMobile · BrowserEnglish · Arabic Buy fee: set by the providerCoin98 Super WalletFinanceNFTsMobile · BrowserEnglish · Vietnamese Swap fee: 0.5% (0.1% for stablecoins)Railway WalletDesktop · MobileEnglish Shield/unshield fee: 0.25%Bridge walletMobileEnglish · French Swap fee: 0.5%, Buy/sell fee: 0.6% – 3.8%Infinex Wallet & Crypto SuperappNFTsBrowserEnglish Swap/bridge fee: 0.03% – 0.3%Zerion WalletNew to cryptoDeveloperFinanceNFTsDesktop · Mobile · BrowserEnglish · Russian Swap/bridge fee: 0.67% (lower with Premium), Buy fee: set by the providerMetaMaskFinanceNFTsMobile · BrowserEnglish · Amharic Swap/bridge fee: 0.875%, Buy/sell fee: 1%PillarXNFTsMobileEnglish Swap fee: 1%FoxWalletNFTsMobile · BrowserEnglish · Chinese Swap fee: 0%Bitget walletFinanceNFTsMobile · BrowserEnglish · Chinese Swap fee: variableUnstoppable walletDeveloperNFTsMobileEnglish · French 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%Ready WalletFinanceNFTsMobile · BrowserEnglish Swap fee: 0.5%RainbowNew to cryptoFinanceNFTsMobile · BrowserEnglish · Spanish Swap fee: 0.85%Gem WalletDeveloperNFTsDesktop · MobileEnglish · Spanish Swap fee: 0%, Buy fee: set by the providerUniswap WalletNFTsMobile · BrowserEnglish · Spanish Swap fee: 0%1inch WalletFinanceNFTsMobileEnglish · Russian Swap fee: variableClaveMobileEnglish Swap fee: 0.5%PhantomFinanceMobile · BrowserEnglish · Spanish Swap fee: 0.85%Clear WalletDeveloperBrowserEnglish 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":1478,"squid":"spider-05","role":"Spec Spider","at":1791346311967,"hash":"1962189dae4edf29962d614038d7bc2147de7b1b"}
{"url":"https://forum.across.to/t/velodrome-liquidity-program-extension/1752/1","domain":"forum.across.to","title":"Velodrome Liquidity Program Extension - Proposals / Active Proposals - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n Velodrome Liquidity Program Extension \n\n ProposalsActive Proposals\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 6\n\n 4\n\n 3\n\n 2\n\n read \n\n 6\n min\n\n Oct 2023\n\n 1 / 20\n\n Oct 2023\n\n Jan 2024\n\n post by Methodic on Oct 31, 2023\n\n Methodic\n\n Summary:\nAcross Protocol’s pilot program on Velodrome ended in October. This proposal aims to extend its initial program for 16 weeks in order to ensure sufficient liquidity for ACX on L2s.\nThe Velodrome team presented this strategy to the Across community on the 29th of November. A summary of the pilot program as well as this proposed extension can be viewed here.\nAfter discussing with the community, this proposal will reduce the amount of ACX incentives required by 70% (from $5K to $1.5K per week) and have Across deploy $200K worth of POL in order to sustain about $400K+ worth of TVL for effectively zero net cost.\nMotivation:\nL2 adoption continues to gain significant momentum with Across Protocol taking a leadership position in supporting cross-chain activity. Building ACX liquidity on Optimism will further strengthen Across’s presence in the growing ecosystem and allow L2 users to trade and hold ACX at a low cost.\nOn Velodrome’s pilot program, Across protocol attracted nearly $600K in liquidity by directing ~2X in VELO emissions per ACX incentive to ACX/WETH, following an uptick in incentive efficiency.\nBy extending the program, Across can leverage the increase in incentive efficiency which, complemented by Velodrome’s renewed OP grant program, will provide significant support for ACX/WETH.\n1600×884 115 KB\nSpecification:\nOn Velodrome, $VELO emissions are directed to liquidity pools based on votes by veVELO (vote-escrow VELO) holders. Protocols such as Across can use veVELO or voter incentives (bribes) to attract votes and emissions for their liquidity pairs.\nProtocols bribing on Velodrome tend to receive $2-$3 in $VELO for every $1 they deposit. Major DeFi protocols such as Yearn, Lido, Synthetix and Stargate leverage Velodrome’s mechanics to maintain deep liquidity on Optimism in a capital-efficient way.\nAcross will extend its initial program for another 16 weeks while strategically reducing incentives from $5K worth of ACX tokens to $1.5K. These will be deposited weekly to attract votes for ACX/WETH. After each epoch is completed on Wednesday at 23:59 UTC, the resulting $VELO emissions from votes will flow to ACX/WETH LPs.\nAcross may also be eligible for a share of 4000 OP every week whilst it remains in the Top 15 ecosystem pools by voter incentives as part of the current “Tour de OP” incentive program. This amount will be proportional to all other pools in this category and will be deposited as an extra bribe to boost votes further. Details about the current Tour de OP program below.\n1600×1000 205 KB\nProtocol Owned Liquidity (POL)\nAcross Protocol will also create a $200K ACX/WETH POL position and deploy it on Velodrome. This POL will allow Across able to capture a significant portion of the $VELO rewards that will be streamed to the ACX/WETH pool. To build the POL position, Across will convert up to $100K ACX into WETH as needed.\nAcross will lock farmed $VELO as veVELO in order to build a voting position - Protocol Owned Votepower (POV) - that will direct additional emissions in perpetuity, while earning rewards in fees and incentives. Protocols pursuing a similar strategy are able to reduce reliance on voter incentives over time. They include Stargate, Yearn, Inverse, QiDAO, Thales among others.\nRationale:\nVelodrome is the single largest protocol on Optimism and the largest DEX on Layer 2 Ethereum with ~150M TVL. Velodrome’s governance community is one of the most active and diverse in crypto, with ~15K veVELO holders participating in Velodrome’s weekly voting epochs.\nIncentivizing liquidity on Velodrome will naturally boost exposure for Across Protocol, as veVELO voters and Liquidity Providers will find ACX near the top of the voting and LP pages respectively.\nCosts:\nAcross Protocol will deploy $1.5K weekly incentives for 16 weeks which totals USD $24K. This is is $11K less than its pilot program which cost $35K. Assuming incentive efficiency remains constant at 2X, Across would capture $1.5K in VELO emissions per week at a 40% APR. In other words, Across can receive 100% of the value of its weekly incentives in VELO, allowing the protocol to sustain $390K worth of TVL for effectively zero net cost.\nAs Across locks its farmed VELO into veVELO throughout the 16 weeks, it will also end up with a veVELO position which will enable the DAO to claim weekly rewards made up of fees generated by the pool as well as claim back a portion of the weekly incentives deposited.\nAt the end of the 16 week period, the DAO can assess results and decide on whether to continue or suspend its program. The Velodrome team will also conduct a review at the end of the program and provide recommended optimizations to its strategy\nImplementation:\n\nRisk Labs to swap $100K worth of ACX to WETH\nDeposit $200K ACX/WETH LP position and stake this on Velodrome\n$24K worth of ACX tokens to be sent to Risk Labs multisig (0x8180D59b7175d4064bDFA8138A58e9baBFFdA44a)\nRisk Labs to deposit $1.5K worth of ACX incentives every week for a period of 16 weeks\nLock farmed VELO emissions into veVELO to build Protocol Owned Votepower and vote for the ACX/WETH pair\n\nVoting:\nYes - move forward with program extension\nNo - do not move forward with program extension\nAbstain - no vote\nDo you support this proposal?\n\n 67%\n Yes\n\n 33%\n No\n\n 0%\n Abstain\n\n 9\n voters\n\n Closed Jan 2024\n\n 6\n\n 4\n\n 3\n\n 2\n\n read \n\n 6\n min\n\n post by Methodic on Oct 31, 2023\n\n Methodic\n\n Hey all looking forward to your thoughts/comments/feedback. Particularly around whether you’d support the implementation of a more optimized liquidity program starting with some POL. As Across currently does not have any POL, this would require the DAO to approve swapping some $ACX tokens for WETH to deposit into the ACX/WETH pool.\n\n post by TheRealTuna_Across on Nov 2, 2023\n\n TheRealTuna_Across\n\n I am a big fan of having liquidity on L2’s to allow users to trade ACX in a more affordable gas environment. However, after looking over the numbers here this seems like a very expensive and unsustainable option to maintain L2 liquidity. We paid $35K in ACX($42K by today’s price) in order to facilitate $277K in volume. I feel like we should continue to support L2 liquidity but the cost was higher than necessary in my opinion and I’d like to explore what other options we may have.\n\n post by neondaemon on Nov 3, 2023\n\n neondaemon\n\n I 've been using velodrome since we started the liquidity programme and been happy with the returns but take the point that it sounds expensive.\n\n post by btctdm on Nov 7, 2023\n\n btctdm\n\n use and like both Velodrome and Across.\nSounds good, Go ahead.\nref: A proposal is live to extend’s pilot program on Velodrome for 16 weeks,\n\n post by PVMihalache on Nov 7, 2023\n\n PVMihalache\n\n One of the best combos on Optimism! Big yes from me! Lets keep it and make it bigger! Across is working hard to enhance the Cryptoverse and having strong liquidity helps!\n\n post by Kevin_UMA on Nov 7, 2023\n\n Kevin_UMA\n\n TheRealTuna_Across\n\n i think @TheRealTuna_Across highlights some important points about cost.\n@Methodic how does this compare with what we had with Aura in the past? And also comparison to volumes we have on L1.\nL2 liquidity is always nice to have, but L1 liquidity probably more important given LPs are all on L1 and all rewards are paid there.\n\n post by DerivativeKid on Nov 8, 2023\n\n DerivativeKid\n\n I think this is too expensive in terms of $ACX to pay for liquidity on L2s. I’d prefer to see something more cost effective or not incentivize liquidity of the token at all.\n\n post by Methodic on Nov 9, 2023\n\n Methodic\n\n Kevin_UMA\n\n I’ll have a chat with the team to see if we can do some kind of direct comparison.\nIn the meantime, a couple things we noticed but it looks like throughout program the Velodrome pool wasn’t listed on the Across farm page Across Protocol – Transfer Assets Between Layer 2s and Mainnet - could this be updated on the UI if this extension gets aproved?\nAlso correct me if I’m wrong but I believe Across gives out extra ACX to Balancer LPs? So on raw stats it’s hard to benchmark apples to apples.\n\n post by Methodic on Nov 9, 2023\n\n Methodic\n\n DerivativeKid\n\n In terms of VOL/TVL, looks like Velodrome liquidity is pretty much on par with Balancer\nimage896×313 53.8 KB\n\n post by Methodic on Nov 9, 2023\n\n Methodic\n\n But yeah definitely if you’re looking for something cost effective, that is why we are suggesting in this program extension to trial a more optimized strategy incorporating Protocol Owned Liquidity.\nWith a large enough POL position relative to total TVL of the ACX/WETH pool, VELO rewards farmed could match or exceed the value of incentives deposited every week. Or at the very least, reduce the net cost of incentives.\nStargate’s program shows how effective this is where they own a sizable % of their TVL with POL and locked most of the VELO farmed to build a veVELO voting position. Now in addition to the value they’re capturing from their POL, they’re also capturing a large percentage of the rewards from their pool each week to be incentivizing on Velodrome for a profit. To be exact, they’ve averaged about $8K in profit every week during the entirety of their program (total value of emissions from their POL and rewards from their veVELO position vs the value of the incentive they deposited).\nWhat would help here is if we knew how much $ACX tokens could be earmarked to be converted into $WETH to pair with on Velodrome. Then we can run some calculations to project the net cost (or profit) of the program. If no specific numbers can be given, we can go ahead with some example scenarios e.g. $25K POL, $50K POL, $100K POL so on.\n\n post by Kevin_UMA on Nov 9, 2023\n\n Kevin_UMA\n\n Methodic\n\n Just to clarify a few things. Across rewards page is only for LP tokens that can be staked to earn ACX. Balancer LP tokens can be staked for reward locking now; however, when Across DAO was paying bribes to Aura it was not on the reward page. So it’s only meant for reward locking.\nThe DAO voted to stop Aura bribes and instead use Across’ own reward locking. That is why there are ACX reward being paid. It actually is a very good comparison for Velodrome.\nAcross reward locking base emissions were equivalent to about 98k ACX per 2 weeks - this was in comparison to Aura bribes of 150k ACX per 2 weeks which we discontinued.\nVelodrome was given 150k ACX per 2 weeks as well. So pretty much an apples to apples comparison. For the Across DAO I believe we should be evaluating how much liquidity we get given how much ACX we are spending.\nhope that makes sense\n\n post by Kevin_UMA on Nov 9, 2023\n\n Kevin_UMA\n\n Methodic\n\n yes vol/tvl sure, but roughly the same amount of ACX was spent for incentives - 98k ACX per 2 weeks in base emissions (multiplier grows if you don’t claim your rewards) for Balancer LP and 150k ACX per 2 weeks on bribes for Velodrome LP. However, the Balancer LP attracted $1.41M TVL vs Velodrome only attracted $444k TVL. Maybe Balancer pool has been around longer so it accumulated more LPs (?), but still a big diff it seems.\n\n 20 days later\n\n post by caesarsherrod.eth on Nov 30, 2023\n\n caesarsherrod.eth\n\n Definitely for this program to stake incentives. As someone who uses Velodrome it is a great way to buy ACX tokens with low gas fees. So I 100% encourage this.\n\n post by Methodic on Dec 5, 2023\n\n Methodic\n\n Hi All, thanks for letting us join the community call last week and providing feedback on the proposal.\nWe’ve made some final changes to the proposal namely:\n\nReducing amount of ACX incentives from $5K to $1.5K per week\nRecommending Across deploy $200K worth of POL\n\nNot only will this decrease ACX emissions used as incentives but assuming incentive efficiency remains constant at 2X, Across would capture $1.5K in VELO emissions per week at a 40% APR allowing Across to sustain about $390K worth of TVL for effectively zero net cost.\nThis will also mean Across can start to build a veVELO position to help reduce reliance on incentives over time.\n\n 1 month later\n\n post by PVMihalache on Jan 6, 2024\n\n PVMihalache\n\n This is something I will definitely vote against. My arguments might be too personal but its hard not to be after being drained twice, both after using Velodrome. The two hack attacks on the UI were not covered enough by their team, and the lack of support recevived in my two separate incidents showed a clear lack of communication and transparency.\nI am around since 2015 and I know how to be careful. The links I use are bookmarked pages, and the dapps I use more often are always open in metamask. The chances I clicked a wrong fake link are zero!\nSo what happened? On the 20th I used Velodrome to swap ACX three times, small amounts as the price impact for one go was huge. Third swap failed but didnt gave much attention. Later on I was drained of ACX and OP (7k). The ticket I opened on 20th of December was ignored until 3rd of Jan, when I was told “the drain is UNLIKELY to be related with us”. However, Metamask support highlighted the same failed swap and said its very likely that malicious things may still be in their code since the UI attacks\n\n post by PVMihalache on Jan 6, 2024\n\n PVMihalache\n\n But that’s not all. In January I used Velodrome again and got drained again. All the $POOL I had was gone, along the USDC! Lost another $22k and again no reaction. Was asked if I was using the correct link and was recommended to change the wallet. That’s my tl;dr on why I don’t trust Velodrome and I don’t want for this be renewed. Raising awareness and trying to keep everyone’s safe \n\n post by alexander on Jan 8, 2024\n\n alexander\n\n We have repeatedly demonstrated to you that your wallet was in someway compromised and it has nothing to do with Velodrome – you continuing to both use that wallet and blaming Velodrome for the continued loss of funds is absurd.\nHere is the attacker’s address who drained your funds on 12/20. You can see they are exploiting a number of wallets, none of which have any history of interacting with Velodrome at all.\n0x447edbf56d58468b621867cf6dc455d7e31e6c36\nVelodrome has thousands of transactions every day and no one has reported any issues outside of the context of the attack on our DNS provider. I would highly recommend you review your own personal OPSec and if you want to know the true cause, investigate any similarities between your wallet’s approvals and those of the other victims of the attacker.\n\n post by PVMihalache on Jan 8, 2024\n\n PVMihalache\n\n Nothing was demonstrated, my ticket was answered after 14 days, and was told its “unlikely” it was caused by my interaction with Velo. Poor support and lack of empathy as well!\n\n post by alexander on Jan 8, 2024\n\n alexander\n\n If you have any evidence that Velodrome played any role in that exploit, then you are welcome to present it, until then you are just posting what is essentially slander rather than seeking to understand the actual attack vector or taking steps to insulate yourself from further attacks.\nAnyone who reviews your exploiter’s transactions can see clearly that there is no demonstrable link to Velodrome. If someone tried to blame Across in a similar manner, I’m sure their team would pushback as well.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Build liquidity for $ACX on Velodrome\n\n Active Proposals\n\n treasury-funding\n\n Active Proposals\n\n 8\n\n Jul 2023\n\n Across ($ACX) Community Initial Liquidity Proposal\n\n Passed Proposals\n\n Passed Proposals\n\n 49\n\n Nov 2022\n\n Across Token Launch Proposal v2\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 47\n\n Nov 2022\n\n $ACX Liquidity - Update and Feedback Wanted\n\n Ideas & Feedback\n\n Ideas & Feedback\n\n 7\n\n Jun 2023\n\n Reduce ACX emissions for ACX LPs, WBTC LPs and wstETH/ACX LPs\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 11\n\n Aug 2024","tokens":5505,"squid":"spider-09","role":"Bridge Spider","at":1791346318210,"hash":"5e99399a8ee66d61599398f7e3f9f718ca76ade8"}
{"url":"https://www.metaplex.com/docs/nfts/burn-nft","domain":"metaplex.com","title":"Burn an NFT | NFTs","text":"Permanently destroy an NFT and reclaim rent fees. Burn an NFTIn the following section you can find a full code example and the parameters that you might need to change. You can learn more about burning NFTs in the Core documentation.1import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n2import { burn } from '@metaplex-foundation/mpl-core'\n3import { mplCore } from '@metaplex-foundation/mpl-core'\n4import { publicKey } from '@metaplex-foundation/umi'\n5\n6const umi = createUmi('https://api.devnet.solana.com').use(mplCore())\n7const assetAddress = publicKey('AssetAddressHere...')\n8\n9// Permanently destroy/burn an NFT asset\n10const result = await burn(umi, {\n11 asset: assetAddress,\n12}).sendAndConfirm(umi)\n13\n14console.log('Asset burned successfully')\n1# Burn an NFT using the Metaplex CLI\n2\n3# Burn a single asset by its mint address\n4mplx core asset burn <assetId>\n5\n6# Burn an asset from that is part of a collection\n7mplx core asset burn <assetId> --collection <collectionId>\nParametersCustomize these parameters for your burn:ParameterDescriptionassetAddressThe public key of the NFT to burnHow It WorksThe burn process involves three steps:Fetch the NFT - Get the NFT data using fetchAssetExecute burn - Destroy the NFT permanentlyReclaim rent - Most SOL is returned to you (except ~0.00089784 SOL)Warning: Burning is permanent and cannot be reversed. Make sure you want to destroy the NFT before proceeding.Rent ReclamationWhen you burn an NFT:Most of the rent SOL is returned to the NFT ownerA small amount (~0.00089784 SOL) remains to prevent the account from being reopenedYou must be the NFT owner to burn it","tokens":409,"squid":"dotcat","role":"Tooling Spider","at":1791346318310,"hash":"a238e7d3b345ba17d847a16966bb16f79a39fc68"}
{"url":"https://ethereum.org/wallets/find-wallet/alphawallet/","domain":"ethereum.org","title":"AlphaWallet | ⁦ethereum.org⁩","text":"NFTsAlphaWalletMobileEnglish, Chinese, Spanish, French, VietnameseSwap fee: 0%Visit website (opens in a new tab)Twitter (opens in a new tab)FeaturesConnect to dappsNFT supportLayer 2SwapsENS supportStakingHardware wallet supportSecurityOpen sourcePersonal ownershipPrivate transactionsBuy / sell cryptoBuy cryptoSell for cashSmart contractMultisigSocial recoverySmart accountsAccount upgradesAdvancedToken importingGas fee customizationRPC importingAlphaWallet info updated on 6/24/2022Similar walletsSafeFinanceNFTsMobileEnglish Swap fee: 0.05% – 0.7%, Staking fee: 20% of rewardsNuFiFinanceNFTsBrowserEnglish Swap fee: 0.75%BraavosNFTsMobile · BrowserEnglish Swap fee: 0%MEW walletNew to cryptoNFTsMobileEnglish · Russian Swap fee: variableFrameDeveloperFinanceNFTsDesktop · BrowserEnglish EnkryptNFTsBrowserEnglish Swap fee: variable","tokens":209,"squid":"spider-05","role":"Spec Spider","at":1791346321992,"hash":"9f0374bb3b4cda4e050c2652600af91d0232234d"}
{"url":"https://ethereum.org/wallets/find-wallet/safe/","domain":"ethereum.org","title":"Safe | ⁦ethereum.org⁩","text":"FinanceNFTsSafeMobileEnglishSwap fee: 0.05% – 0.7%, Staking fee: 20% of rewardsVisit 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 upgradesAdvancedToken importingGas fee customizationRPC importingSafe info updated on 11/6/2024Similar walletsLedgerFinanceHardwareNFTsDesktop · Mobile · HardwareEnglish · Arabic Device: $79 – $399, Swap fee: variableRabby WalletDeveloperFinanceNFTsDesktop · Mobile · BrowserEnglish · German Swap fee: 0.25%Coin98 Super WalletFinanceNFTsMobile · BrowserEnglish · Vietnamese Swap fee: 0.5% (0.1% for stablecoins)imKey Pro Hardware WalletDeveloperFinanceHardwareNFTsDesktop · Mobile · Browser · HardwareEnglish · Chinese Device: $110, Swap fee: 0%imTokenDeveloperFinanceNFTsMobileEnglish · Chinese Swap fee: 0.3% (0.04% stablecoins, lower on L2s)NuFiFinanceNFTsBrowserEnglish Swap fee: 0.75%","tokens":276,"squid":"spider-05","role":"Spec Spider","at":1791346331975,"hash":"f58a1638fe3f91ba0617544cfca5366cfa26fcfa"}
{"url":"https://ethresear.ch/t/reward-curve-with-tempered-issuance-eip-research-post/19171","domain":"ethresear.ch","title":"Reward curve with tempered issuance: EIP research post - Proof-of-Stake / Economics - Ethereum Research","text":"Reward curve with tempered issuance: EIP research post \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 2\n\n read \n\n 33\n min\n\n Apr 2024\n\n 1 / 4\n\n Mar 2024\n\n May 2024\n\n post by aelowsson on Apr 1, 2024\n\n aelowsson\n\n Reward curve with tempered issuance: EIP research post\nBy Anders Elowsson\nMy aim with this post is to present the rationale for a reward curve with tempered issuance. It is a longer format of a forthcoming EIP, offering a more detailed account of the benefits and the trade-offs that must be balanced, as well as a comparison with alternative options. I will try to answer any questions you may have in the comments!\n1. Overview\nValidators began receiving execution layer rewards with The Merge, and liquidity improved when withdrawals were enabled with Shapella. Both upgrades have served to increase the equilibrium quantity of stake. There is a broad consensus that the current deposit size keeps Ethereum sufficiently secure (e.g., 1, 2, 3). Yet issuance will rise substantially as more stake is deposited under the current reward curve. Excessive incentives for staking, beyond what is necessary for security, can unfortunately over time turn into perverse subsidies, with many downsides. This post will explore the benefits of moderating issuance and available options. It concludes that Ethereum should adopt the candidate reward curve, designed to effectively moderate quantity staked while still maintaining reliable consensus incentives, economic security, resistance to discouragement attacks and cartelization attacks, a favorable composition of the staking set, and viable conditions for solo staking. The candidate reward curve divides the equation of the current reward curve by 1+D/k1 +𝐷/𝑘. The single adjusted variable k𝑘 then comes to define the quantity staked at the peak issuance point, which also corresponds to the point where issuance is halved relative to the current reward curve. A setting of k=2^{26}𝑘 =226 (67.1M ETH) is suggested as feasible for the near term, with a subsequent potential final adjustment to k=2^{25}𝑘 =225 (33.6M ETH).\nSection 2 – Rationale\nThe equilibrium yield offered to stakers corresponds to the cost that the marginal staker assigns to staking, i.e., their indifference point between staking and not staking. Section 2.1 shows that if Ethereum offers a higher yield than necessary for maintaining security, it compels its users to incur higher costs, degrading user utility in aggregate. This explains why all ETH holders can benefit from an issuance reduction, something which is also illustrated in Figure 2. The macro perspective is reviewed in Section 2.2. As the quantity of stake grows, one or a few liquid staking tokens (LSTs) may come to supplant ETH as money in Ethereum. Positive network externalities could then lead to both lower user utility and protocol decentralization. Their derivative nature can also erode the social layer’s capacity for upholding Ethereum’s intended consensus process. Section 2.3 suggests that Ethereum should adopt a graduated approach to the proposed changes. Taking a first smaller step will improve Ethereum without being too disruptive, smooth out disequilibria, and allow for an intermediate evaluation of effects on stake composition and quantity.\nSection 3 – Proposed reward curve and alternative paradigms\nSection 3 presents the proposed reward curve and alternative paradigms. The proposed reward curve is labeled as Option A, with an issuance level that slowly falls as the quantity staked increases beyond desirable levels. Option B sees the issuance level will instead approach an asymptotic maximum. Option C is the current reward curve, with a rising issuance across the full staking range. The options are compared in Section 3.4, showing how the reward curves diverge as the quantity staked increases.\nSection 4 – Trade-offs and priors\nSection 4.1 explores yield variability for non-pooled stakers and Section 4.2 then reviews how the equilibrium staking yield may affect the proportion of solo stakers. The biggest risk is that disadvantageous economies of scale make solo staking less viable. However, at a higher quantity staked, dominant staking service providers (SSPs) can offer lower fees, better LST money, and lower risk due to emerging moral hazard. The proposed reward curve offers a positive yield across the full range—low enough to make a high quantity stake unlikely, yet sufficiently high as to never force out solo stakers on efficient setups under more improbable scenarios. It is noted that priors regarding both the supply curve and the level of the maximum extractable value (MEV) are relevant to the design. A scenario with a lower supply curve under the current level of MEV is analyzed in Section 4.2.3, aiding the understanding of how the proposed reward curve helps the consensus mechanism absorb delegating stakers with low reservation yields to ensure that solo stakers always are provided with some yield. The broader composition of the staking set is explored in Section 4.3, emphasizing that competition for delegated stake will take place across diverse market segments. Seeing that the cost of running a staking node will not be made prohibitively high relative to the yield, the proposed change will allow variety in preferences and circumstances between delegators to play a more central role in shaping the composition of the staking set. Section 4.4 finally plots the “isoproportion map”, presenting the conditions under which a change to issuance policy is profitable to stakers.\nSection 5 – Security considerations\nThe effects of issuance policy on economic security are discussed both for the short run and long run in Section 5.1. An important reason for providing a positive yield across the full range in the near term is the to preserve consensus incentives without making more extensive adjustments to the protocol, as discussed in Section 5.2. Sections 5.3-4 take a closer look at discouragement attacks and cartelization attacks. These attacks will become more favorable under stricter reward curves where issuance decreases substantially (particularly under a design with negative issuance levels), and are therefore important to keep in mind. The candidate reward curve does not materially exacerbate the risks of these attacks.\nSection 6 – Conclusions and discussion\nSection 6.1 summarizes the advantages and disadvantages of different issuance levels, and Section 6.2 then presents the author’s conclusion that the proposed candidate reward curve (Option A) is the best alternative for Ethereum at this time. Option C can function as a provisional backup plan. The post concludes by exploring the unknown endgame, broadening the utility measure for token holders to incorporate the development of the entire ecosystem, and cautioning against exploiting users’ bounded rationality concerning yield.\n2. Rationale\n2.1 User utility\nDefine the “reservation yield” as the lowest staking yield y𝑦 at which an individual is willing to stake. Ethereum’s supply curve then emerges from prospective ETH holders’ reservation yields. Figure 1 shows a hypothetical supply curve in blue that will be used in a few examples of this post. Total yearly rewards are Y=yD𝑌 =𝑦𝐷, where D𝐷 is the quantity staked (“deposit size”). A holder’s reservation yield can be characterized as the “indifference point” where they derive as much utility from staking as from not staking. The area below the supply curve thus represents the implied aggregate cost to stakers Y_c𝑌𝑐 and the area above represents their surplus Y_s𝑌𝑠, which combines into total rewards Y_c+Y_s=Y𝑌𝑐 +𝑌𝑠 =𝑌. Relevant costs (broadly defined) 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. A high yield compels users to incur higher costs than necessary for maintaining security, diminishing user utility in aggregate. Slashing 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 actually 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.\nA change to Ethereum’s issuance policy from the current reward curve (illustrated in black) to the proposed reward (green) shifts the equilibrium from the black square (1) to the green circle (2). The associated cost reduction Y'_c𝑌′𝑐 indicated by the darker blue area benefits all ETH holders, because the ETH was just issued to offset staking costs, without generating any surplus. The shift to the equilibrium also transfers a surplus Y'_s𝑌′𝑠 from stakers to all ETH holders (stakers included). The cost reduction is determined by the definite integral of the equation for the inverse supply curve f(x)𝑓(𝑥), bounded by the two equilibrium quantities of the comparative static: Y'_c = \\int_{D_2}^{D_1} f(x)dx\\approx𝑌′𝑐 =∫𝐷1𝐷2𝑓(𝑥)𝑑𝑥 ≈ 446k ETH. The surplus shift is instead quantified as Y'_s = D_1y_1-D_2y_2-Y'_c \\approx𝑌′𝑠 =𝐷1𝑦1 −𝐷2𝑦2 −𝑌′𝑐 ≈ 252k ETH. Thus, almost 2/3 of the issuance reduction directly contributes to welfare improvement, with 1/3 reallocating utility from stakers to all ETH holders. The outcome for a supply curve with a similar shape will be a similar definite integral and cost/surplus respectively. If the supply curve is flatter around the comparative static, Y'_c𝑌′𝑐 becomes relatively larger and Y'_s𝑌′𝑠 relatively smaller, and vice versa.\nFigure 11920×1141 93.9 KB\nFigure 1. Implied cost Y_c𝑌𝑐 and surplus Y_s𝑌𝑠 of staking with a hypothetical supply curve. A change in issuance policy shifts the equilibrium from the black square to the green circle. The cost savings Y'_c𝑌′𝑐 leads to aggregate welfare improvement as long as the protocol remains secure and decentralized, and the reduction in surplus Y'_s𝑌′𝑠 simply shifts some utility from stakers to everyone.\nToo often, all staking yield is considered as a surplus Y_s𝑌𝑠, with the implication that issuance policy is a zero-sum game. But due to the costs that must be borne by stakers, issuance policy is emphatically not zero sum. It is fundamental to understand that by having a higher yield, Ethereum steers its users to take on higher costs in aggregate. This is the reason why everyone can gain when keeping issuance at the minimum viable level, as long as they own the underlying ETH.\nTo illustrate this, the attainable change to someone’s proportion of all ETH can be calculated as\n\ny_p=\\frac{1+y}{1+s}-1.\n𝑦𝑝=1+𝑦1+𝑠−1.\nIt can be interpreted as the Fisher equation adapted to Ethereum. The “proportional yield” y_p𝑦𝑝 can be computed for both stakers and non-stakers, in the latter case with y=0𝑦 =0. The circulating supply inflation rate s=i-b𝑠 =𝑖 −𝑏 derives from the issuance rate i=Y_i/S𝑖 =𝑌𝑖/𝑆 and the burn rate b=B/S=0.008𝑏 =𝐵/𝑆 =0.008, where Y_i𝑌𝑖 is yearly issuance, S𝑆 is the circulating supply and B𝐵 is yearly burn (using the average since The Merge). Further complexities regarding the interpretation of rates in light of compounding effects under a drift of the circulating supply are set aside. Figure 2 illustrates the hypothetical effect of an issuance reduction on user utility, utilizing a comparison of y_p𝑦𝑝 at two different equilibria. It is shown here under the proposed reward curve (Option A) and was in previous work presented when halving issuance with the current reward curve (Option C), under a slightly different supply curve. Both y𝑦 (red arrow) and s𝑠 (orange arrow) are reduced approximately the same, so stakers are left virtually unaffected. Define the change in cardinal utility for a comparative static where y_p𝑦𝑝 changes from y^b_p𝑦𝑏𝑝 to y^a_p𝑦𝑎𝑝 as\n\nu'=\\frac{1+y^a_p}{1+y^b_p}-1,\n𝑢′=1+𝑦𝑎𝑝1+𝑦𝑏𝑝−1,\nbut use the reservation yield as y𝑦 for those who stop staking when computing y^a_p𝑦𝑎𝑝. Below that yield, they do not stake anyway, so they suffer no additional loss in utility as the yield decreases further. As shown in the bottom pane, de-stakers will under this definition derive a higher utility at the new equilibrium, with non-stakers clearly better off. The reason why welfare can improve in this manner is that the staking costs Y'_c𝑌′𝑐 of the blue area from Figure 1 are eliminated. Of course, from a protocol perspective, the question of whether solo stakers continue staking or not is also important. This is a separate topic further explored in Section 4.2. The analysis simply concludes that with the hypothetical supply curve, stakers will be left either unaffected (remaining as stakers if they have low reservation yields) or left even better off—as de-stakers. The effect of issuance policy on stakers under any supply curve is illustrated with an isoproportion map in Section 4.4.\nFigure 21920×1297 138 KB\nFigure 2. The change in y𝑦 and s𝑠 between two hypothetical equilibria is utilized to isolate a change in cardinal utility u'𝑢′ for all token holders. Stakers are subjected to a reduction in yield y𝑦, but the reduction in the inflation rate s𝑠 is similar, so they are left unaffected (y_p𝑦𝑝 stays the same). De-stakers incur no further loss in utility once y𝑦 falls below their reservation yield. They benefit together with non-stakers from the reduction in s𝑠.\nSchwarz-Shilling and Dietrich refer to y_p𝑦𝑝 as the “real total staking yield” (they do not specify an equation in their post, but may imply that they use y_p=y-s𝑦𝑝 =𝑦 −𝑠; with b=0𝑏 =0 for visual clarity). Their plots across reward curves, including plots of Option A, are very useful for conceptualizing the measure itself.\n2.2 Macro perspective\nThe reward curve influences the proportion of all circulating ETH that is staked, and it is therefore important to examine the macro perspective of Ethereum’s issuance policy. This can be regarded as one component of a true cost accounting, extending Section 2.1 to incorporate externalities.\nAn LST exceeding critical thresholds regarding the proportion of stake under its control can gain outsized profits. This stratum for cartelization of block space can ultimately compromise the consensus mechanism. Risks to Ethereum are further exacerbated if an expansive issuance policy (which the current reward curve arguably represents) enables an LST to attain control over a significant proportion of the total ETH—propelled by network externalities of, e.g., the money function. The compromised institution(s) then sits one layer above the consensus mechanism, namely the social layer. It 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. If the community can no longer effectively intervene in the event of for example a 51 % liveness attack, then risk mitigation in the form of the warning system discussed by Buterin may not be effective. The proof-of-stake consensus mechanism has in this case through derivatives grown so interconnected with Ethereum’s users that it has overloaded its ultimate arbitrator, the social consensus mechanism. It is a special and in a way inverted case of issues Buterin previously warned about.\nIf the issuance policy leads to a high proportion of all ETH being staked, one or a few LSTs may overtake as money in the Ethereum ecosystem, embedding themselves across every layer and application. As has been noted, this is a deliberate objective of some SSPs. By moderating the issuance, each LST will have tougher competition with non-staked ETH, ensuring a trustless asset within the ecosystem. The social layer will not become co-dependent on an outside organization and its issued derivative of ETH. The principal–agent problem (PAP) of delegating stake to a dominant LST can then be priced more accurately because moral hazard will be less likely to develop. No LST will grow “too big to fail” in the eyes of the Ethereum social layer. This pricing will reflect the fact that the agent acting on behalf of the delegator (or any party able to inject themselves into that relationship) gains greater opportunities to degrade consensus for its own profit the larger proportion of the stake it controls. The delegating staker must then continuously assess its security guarantees (e.g., the staking agent’s or injecting parties’ own value at risk), knowing that it may lose everything if the worst-case scenario ever comes to pass.\nOne cost explored in Section 2.1 can also affect Ethereum at a macro level. In the case where everyone must stake to not see their savings eroded, differences in tax policies across jurisdictions can hamper geographical decentralization.\n2.3 Graduated approach\nThere are a few arguments for a graduated approach, taking a smaller step in the right direction in one hard fork—evaluating the outcome—and if appropriate taking the final step:\n\nCompromising economic agents’ ability to plan ahead is welfare degrading. While there have been several proposals seeking to temper issuance dating back to at least 2021 (1, 2, 3), individual solo stakers cannot be expected to follow the research debate all too closely. They may first pay attention once a decision has been taken or seriously contemplated. There is also a difference between signaled intentions to moderate issuance and a real decision having been made. A graduated approach is particularly appealing when a change to the issuance policy is implemented relatively shortly after a decision has been made. At the same time, the quantity of stake has at this point already arguably exceeded levels providing sufficient security. Further growth must be considered welfare degrading as well. A graduated approach can in this context:\n\nGive solo stakers, and also SSPs, a longer and more gradual adaptation phase.\nDo something to temper the incentives to stake in the near term, while not being too disruptive.\nConvey the possibility of additional adjustments to users who may not follow ongoing discussions that closely.\n\nIgnoring frictions in the decision to stake, a reduction in issuance will precipitate a temporary phase with below-equilibrium yields, until some stakers leave and a new equilibrium is established. A graduated reduction mitigates this problem. An even more gradual reduction, for instance, encoding a small adjustment to issuance every epoch, would bring more implementation overhead.\nIt is not possible at this time to ascertain that the full issuance reduction will be necessary to temper the growth in the quantity of stake—it is only a reasonable estimate hinging on assumptions of frictions in the decision to stake or a falling supply curve. Therefore, it seems sensible to move gradually, at least as an acknowledgment of these uncertainties. This reasoning accounts for MEV burn on the horizon, which will also affect the staking yield if implemented.\nThere are a few properties of issuance level of particular interest going forward, such as the proportion of solo stakers retained. A graduated approach makes it possible to evaluate intermediate outcomes before implementing the full envisioned issuance reduction. Even if researchers are confident that the full reduction keeps relevant properties in balance, a graduated approach—with an intermediate evaluation before proceeding further—will make the change more palatable to those who may object.\n\nThe next section will present reward curves that incorporate a potential intermediate step as part of a graduated approach.\n3. Proposed reward curve and alternative paradigms\nThere are three fundamental paradigms that the reward curve can be designed according to under current circumstances (e.g., absence of MEV burn, no staking fee, and a desire to keep yield variability manageable; see also Section 4.1 and 5.2). These were stipulated in Table 2 in preceding work and are summarized here in Table 1. Option A is the proposed reward curve. It is best at improving user utility and moderating quantity staked, as advocated in Sections 2.1-2.2. Option C provides a higher yield for (solo) staking in the scenario where almost everyone stakes. This may of course also be seen as a drawback, a trade-off further examined in Sections 4.1-4.3. Option B balances between these two approaches. Section 3.4 will plot the reward curves together for further comparison, both for a full reduction and a graduated approach.\n\nIssuance\nBenefit\n\nOption A:\nFalls marginally at deposit sizes above sufficient security.\nImproves user utility and moderates quantity staked.\n\nOption B:\nAsymptotically approaches maximum fixed level.\nBalances benefits of Option A and C.\n\nOption C:\nContinues increasing indefinitely\nHigher yield for solo staking if quantity staked approaches maximum\n\nTable 1. Three main categories for the reward curves, each explored in this section. Option A is the proposed approach, favored by the author.\n3.1 Option A – Proposed reward curve\nOverview\nThe proposed reward curve attenuates issuance beyond a quantity of stake sufficient for security. It is designed to give very clear mental models: the value of a single adjusted variable k𝑘 also defines the quantity of stake at both the peak issuance and the issuance halving point (relative to the current reward curve). The reward curve was presented as the candidate reward curve in a previous post on properties of issuance level. Figure 3 illustrates annualized issuance level across deposit size under perfect validator performance. Issuance of the current reward curve in black varies with deposit size according to the equation Y_i=cF\\sqrt{D}𝑌𝑖 =𝑐𝐹√𝐷, with F𝐹 set to 64 and the constant c\\approx2.6𝑐 ≈2.6. The grey curve shows halved issuance (F=32𝐹 =32). The proposed reward curve in green introduces a division by 1+D/k1 +𝐷/𝑘\n\nY_i=\\frac{cF\\sqrt{D}}{1+D/k},\n𝑌𝑖=𝑐𝐹√𝐷1+𝐷/𝑘,\nwith c𝑐 and F𝐹 unchanged. The full reduction is intended to be k=2^{25}𝑘 =225, which gives a peak issuance slightly below 0.5M ETH at 2^{25}225 (33.6M) ETH staked (plus sign), which is also the halving point. The dashed green curve with k=2^{26}𝑘 =226 (around 67.1M) indicates a potential step in a graduated approach. The fact that the reward curve stipulates a maximum issuance level, which cannot be exceeded, may be beneficial from a communication perspective. In the future, Ethereum’s reward curve shall transition to vary with deposit ratio d=D/S𝑑 =𝐷/𝑆 (see Section 6.3), which will then instead translate into a maximum circulating supply inflation rate.\nFigure 31920×1126 94.2 KB\nFigure 3. Issuance level for the proposed reward curve—Option A—in green, compared to the current reward curve in black. The dashed green line represents a stepwise reduction in a potential graduated approach. Halved issuance relative to the current reward curve is indicated in grey, with plus signs indicating both halving points and issuance peaks.\nFigure 4 illustrates the staking yield in green, assuming a realized extractable value (REV) of V=𝑉 = 300k ETH/year (REV is MEV after builders take their cut and the current prevailing level is slightly above 300k). The equation for staking yield is y=y_i+y_v𝑦 =𝑦𝑖 +𝑦𝑣, with y_i=Y_i/D𝑦𝑖 =𝑌𝑖/𝐷 and y_v=V/D𝑦𝑣 =𝑉/𝐷. The equation for issuance yield thus becomes\n\ny_i=\\frac{cF}{\\sqrt{D}(1+D/k)},\n𝑦𝑖=𝑐𝐹√𝐷(1+𝐷/𝑘),\nonce again multiplying the denominator of the current reward curve (y_i=cF/\\sqrt{D}𝑦𝑖 =𝑐𝐹/√𝐷) by 1+D/k1 +𝐷/𝑘. The same hypothetical supply curve as in Section 2.1 is included in Figure 4. It serves to illustrate how the propensity to supply stake may potentially vary across yield and deposit size a few years from now, and what the impact on the staking equilibrium then becomes with an altered reward curve. In this particular example, the equilibrium yield is reduced by 0.6 % (around 1/5), from 2.94 % with the current reward curve (black rectangle) to 2.34 % with the new reward curve (green circle). In the graduated approach, the equilibrium yield is reduced by only 0.43 % (around 1/7).\nA reasonable assumption is that the supply curve will gradually shift downwards over time as the staking experience simplifies and DeFi integrations improve. This will in essence depend on how the various costs outlined in Section 2.1 evolve. The faint blue curve could then be the supply curve after another year or two has passed. This would further reduce the yield under both the present and proposed reward curve. The supply curve may also under some circumstances shift upward, for instance, due to a consensus failure prompting stakers to reevaluate risks, or due to increased demand for non-staked ETH, elevating opportunity costs.\nFigure 41920×1150 102 KB\nFigure 4. Staking yield (inclusive of REV) for the proposed reward curve—Option A—in green, compared to the current reward curve in black. The graduated approach is depicted in dashed green. Hypothetical changes in equilibrium from the black square to the green circles are indicated as a guideline, but remain speculative due to uncertainty regarding both the supply curve and future levels of REV.\nReward variability\nIn preparation for the EIP, a simulation of reward variability was performed with current data for REV. Figure 5 shows the simulated cumulative distribution function (CDF) of rewards for solo stakers at various deposit sizes for the proposed reward curve in its full implementation. Figure 6 instead shows the simulated outcome for the graduated approach.\nFigure 51920×1056 124 KB\nFigure 5. Solo staker yield variability at various quantities staked under the candidate reward curve and present level of REV. Expected staking yields are indicated by dashed vertical lines.\nFigure 61920×1056 127 KB\nFigure 6. Solo staker yield variability at various quantities staked under a graduated implementation of the candidate reward curve and present level of REV. Expected staking yields are indicated by dashed vertical lines.\n3.2 Option B – Asymptotically fixed issuance\nOverview\nA somewhat more modest option is to instead divide the present reward curve with 1+\\sqrt{D}/k1 +√𝐷/𝑘, giving an issuance of\n\nY_i=\\frac{cF\\sqrt{D}}{1+\\sqrt{D}/k}=\\frac{cF}{D^{-0.5}+k^{-1}}.\n𝑌𝑖=𝑐𝐹√𝐷1+√𝐷/𝑘=𝑐𝐹𝐷−0.5+𝑘−1.\nThe equation is in essence a log-logistic CDF, and issuance will thus approach an asymptotic maximum of cFk𝑐𝐹𝑘 (but it may not come close to that value while Ethereum operates at its current circulating supply). Figure 7 illustrates a potential reward curve for Option B in orange with k=2^{12}𝑘 =212 and a potential graduated approach with k=2^{13}𝑘 =213. As indicated in the figure, the variable F𝐹 was adjusted to produce a similar issuance as Options A (and Option C) at specific levels, for easier comparison in subsequent sections. Hence, the halving point marked by a plus sign is also around D=2^{25}𝐷 =225, and the graduated approach matches the issuance of Option A at the current quantity staked (31M ETH). But F𝐹 could be re-adjusted to 64, which would increase the probability of an equilibrium at a lower quantity staked.\nFigure 71920×1126 87.5 KB\nFigure 7. Issuance level for Option B in orange, relative to the current reward curve in black. The dashed orange line outlines a stepwise reduction in a potential graduated approach. Halved issuance relative to the current reward curve is indicated in grey with plus signs.\nThe equation for issuance yield instead becomes\n\ny_i=\\frac{cF}{\\sqrt{D}+D/k}.\n𝑦𝑖=𝑐𝐹√𝐷+𝐷/𝑘.\nIt is plotted in Figure 10 in Section 3.4 together with the other reward curves.\n3.3 Option C – Current reward curve with reduced base reward factor\nOverview\nThe simplest option is to reduce the base reward factor, keeping the current reward curve. The full reduction could then be F=32𝐹 =32. It can be noted that this reward curve will reduce the yield relatively more at lower quantities of stake, so F𝐹 can hardly be reduced below 32 from a security perspective, at least not at this point (see also Section 5.1). A graduated approach should opt for a range between 40-48. In this post, F=44𝐹 =44 will be illustrated, since the graduated reward curve will then coincide with all others for easier comparison. Figure 8 plots issuance. Yield is plotted in Figure 10 in Section 3.4 together with the other reward curves.\nFigure 85368×3104 497 KB\nFigure 8. Issuance level for Option C, relying on the current reward curve with a reduced base reward factor. The dashed grey curve indicates a potential setting for the graduated approach. The full possible reduction that retains sufficient economic security is a halving of issuance, indicated by the grey curve.\n3.4 Comparison of Options A-C\nFigure 9 shows the three outlined options, both for a full reduction and a graduated approach. With the full reduction, all curves coincide around D=2^{25}𝐷 =225 ETH (circle), above which issuance for Option A declines, B levels off, and C continues increasing. With the graduated approach, all curves (dashed) coincide around the current quantity of stake of D=𝐷 = 31M ETH (star), after which they diverge in a similar pattern. It can be noted that the graduated approach of both Option A and (narrowly) Option B gives a lower issuance if all ETH is staked than the full reduction in Option C.\nFigure 91920×1110 96.9 KB\nFigure 9. Comparison of issuance levels for Options A-C, with the graduated approach depicted by dashed curves. The three options provide the same issuance at around 2^{25}225 ETH staked for the full reduction (circle) and at 31M ETH for the graduated step (star), above which issuance for Option A falls, B flatlines, and C continues rising.\nFigure 10 shows the staking yield (at the present level of REV) for the same three options. The black double-sided arrow illustrates that the initial reduction in staking yield at the present quantity staked would be under 1 %. The blue double-sided arrows capture the equilibrium shift in yield under the same hypothetical supply curves as previously, demonstrating that the hypothetical reduction in yield would be under 0.5 % for the first graduated step.\nFigure 101920×1150 115 KB\nFigure 10. Comparison of staking yield (at the present level of REV) for Options A-C, with the graduated approach illustrated by dashed curves, and the current reward curve in black. A shift in the equilibrium from the black square to the circle is indicated as a guideline, but there is uncertainty regarding both the supply curve and future REV. The initial reduction in the graduated approach is under 1 % (black arrows) and under 0.5 % at hypothetical equilibria (blue arrows).\n4. Trade-offs and priors\n4.1 Variability 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 simulation of reward variability was performed with current data for REV, resulting in, e.g., the CDFs of Figures 5-6, but also mappings of standard deviations (SDs) of annualized yield across y𝑦 and D𝐷. Recognizing that stakers may be more more sensitive to variance at lower staking yields, the SDs were divided by the square root of the expected yield, referred to as the SSD. This measure attempts to capture degradation from variability for non-pooled stakers. Figure 11 plots the SSD across quantity staked for the different reward curves of this study (lower is better). As evident, the SSD will rise marginally for Option A as the quantity staked increases. This increase is considered acceptable, on the basis that it is reasonable to sacrifice some variability to keep the quantity staked down. When considered in isolation, it is perhaps even desirable to allow the SSD to become a little worse at higher quantities staked than at lower quantities. But having a lower SSD at any D𝐷 is of course preferable.\nFigure 115253×2911 511 KB\nFigure 11. The SSD for the different reward curves (lower is better) across deposit size.\n4.2 Equilibrium yield and the proportion of solo stakers\n4.2.1 Overview\nEthereum wants to retain solo stakers, certainly 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). Using Figure 10 as an example, it is not clear whether the proportion of solo stakers is lower at a hypothetical equilibrium of around 33M ETH staked and a staking yield of 2.34 % than at around 50M ETH staked and a staking yield of 2.94 %. A concern is if there might be a staking yield below which solo stakers in particular would drop off due to the relatively higher fixed costs associated with solo staking. If solo stakers leave en masse below a yield of 2.5 %, then a staking yield of 2.34 % at 33M 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 (see also Section 2.2):\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 PAP 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. 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.\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.\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. An 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 the most 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. This research topic is certain to receive further attention (1, 2).\n4.2.2 Priors regarding the supply curve and REV\nStudying the yield offered at 110M ETH staked in the CDF of staking yield for Option A in Figure 5 may raise particular concerns. The expected staking yield there is only 0.65 %. At a token price of around $3000, a 32 ETH stake would then only generate an expected monthly income just above $50. The “guaranteed” attestation yield not deriving from block proposal or sync-committee duties is only half of that. A decline in the ETH token price could further reduce the income from staking. However, it should be noted that a reasonable prior for the supply curve is that the yield must be quite a bit higher than 0.65 % for 110M ETH to get staked. The only time an equilibrium can be expected at 110M ETH staked is then if the REV increases significantly, pushing up the staking yield to required levels. One easily overlooked benefit of a lower issuance yield at high quantities staked is thus that it pre-emptively counters a higher REV (the staking yield will never go below the marginal staker’s reservation yield under equilibrium). Concerns may of course also be raised around the fact that the quantity of stake is allowed to expand to 110M ETH in the first place, given the good arguments against it. Why offer any yield at all? Besides care for solo stakers, important reasons pertaining to consensus incentives at the present are provided in Section 5.2.\n4.2.3 Low-yield scenario\nWhile it seems probable that a high quantity staked under the proposed reward curve (Option A) would be associated with an elevated level of REV, thus maintaining a slightly higher staking yield, it can still be valuable to examine the alternative scenario. What if the supply curve indeed falls substantially over the next decade to a very low level? Option A gives a staking yield to 1 % at around 74.6M ETH staked under the current level of REV. Option B gives a staking yield of 1.16 % there, and Option C sets it to 1.37 %. But the equilibrium would of course shift to a higher quantity staked for Option B and C, reducing the yield a bit in the process. A hypothetical outcome for Options A-C in a scenario with an equilibrium yield of 1 % for Option A (green circle) is shown in Figure 12. It is of course challenging to speculate on what the supply curve might look like in this unlikely scenario, but it may still be helpful to plot one possible outcome to aid the understanding (it is formed as in the previous study using k=1𝑘 =1 and c_2 = 0.001𝑐2 =0.001). Option B then gives a yield of 1.09 % at an equilibrium of around 80M ETH staked (orange circle) and Option C gives 1.24 % at around 87M ETH staked (grey circle). Which outcome is better for Ethereum?\nFigure 121920×1137 103 KB\nFigure 12. Hypothetical equilibria in a scenario with a low supply curve that intersects 1 % staking yield of Option A under the current level of REV.\nIf many solo stakers have a reservation yield between 1.24 % and 1 %—in this particular scenario where the majority is staked with reservation yields below 1 %—then they could be disproportionately more likely to drop off. This goes back to the trade-off between the relatively higher fixed costs for solo stakers and the benefits of LSTs at high quantities staked: the notion that dominant SSPs can offer lower fees, better LST money, and lower risk due to emerging moral hazard.\nEthereum can be designed to enforce an equilibrium at any point along the supply curve (but must be attentive to the level of y_i𝑦𝑖 relative to y_v𝑦𝑣). Would enforcing an equilibrium at the blue star be preferable under this supply curve? It corresponds to 30M ETH staked and a total staking yield of around 0.37 %. At present, y_v𝑦𝑣 is 1 % at 30M ETH staked, so a staking fee would need to be introduced and taken out every epoch. This would require making solo stakers lose money every epoch, on the slim chance that they may be assigned to propose a block. That outcome is rather unappealing. But what about after introducing MEV burn, would it be desirable at that point? There are several arguments in favor of it (e.g., Section 2), but it could also render solo staking rather disadvantageous due to the relatively higher fixed costs. The effect on the composition of the staking set is harder to predict when enforcing a low quantity staked in such a manner at this point (refer also the next subsection). If the equilibrium yield is 2.6 % at 30M ETH staked, as with the candidate reward curve, then the outcome is far less controversial. An upward shift to the equilibrium quantity of stake—from the blue star to the green circle—acts as a “safety valve”, which helps Ethereum neutralize the less desirable properties of a low quantity of stake under a lower supply curve. The consensus mechanism essentially absorbs all delegating stakers with low reservation yields, just to push up the yield enough to allow solo stakers to still operate a 32 ETH validator at a profit. Regardless of whether this is desirable or not, for the sake of users, the upward shift must only take place if strictly required. This is something that the reward curve facilitates.\nIt can be interesting to note the difference between the proposed Option A and the current reward curve also under this hypothetical supply curve. The staking yield at the black square in Figure 12 is around 2 % and the incentives to stake thus much higher, drawing 105M ETH into staking. The downsides are the same as previously discussed. Everyone is forced to stake to not see their savings eroded. The issuance level at the black square is around 1708k ETH per year, i.e., almost four times higher than under Option A. Therefore, even though the yield increases by almost 1 %, the supply inflation rate increases even more. Thus, remarkably, stakers are still left worse off under the current reward curve than under Option A, and everyone loses in terms of u'𝑢′. This follows from the fact that the gain in y_i𝑦𝑖 does not materially surpass the loss from the increased issuance rate i=y_id𝑖 =𝑦𝑖𝑑, where d𝑑 is the deposit ratio d=D/S𝑑 =𝐷/𝑆. Thus, for an increase in issuance to be profitable at high deposit ratios, the supply curve must slope almost vertically upwards, as further explored in Section 4.4 and Figure 14.\nIn the example in Figure 12 with a low supply curve, changing from Option C (grey circle) to Option A (green circle) reduces issuance by around 330k ETH, from around 775k ETH down to 446k ETH. Around 42 % of that reduction corresponds to decreased implied costs Y'_c𝑌′𝑐. The change in utility for ETH holders is shown in Figure 13. Everyone would be better off at the equilibrium of Option A than Option C (disregarding frictions). However, as previously mentioned, this does not mean that solo stakers will keep staking. They could be even better off de-staking, if their reservation yield sits in between 1 % and 1.24 %. From a macro perspective, the overall protocol (including the ETH token holders) could then be worse off if the proportion of solo stakers falls too much. The macro perspective is further interwoven with user utility in Section 6.4.\nFigure 131920×1289 133 KB\nFigure 13. Isolating the change in utility u'𝑢′ when changing from Option C to Option A under a low supply curve. Stakers are subjected to a reduction in yield y𝑦, but the reduction in the inflation rate s𝑠 is larger, so they are left slightly better off. De-stakers incur no further loss in utility once y𝑦 falls below their reservation yield. They benefit together with non-stakers from the reduction in s𝑠.\n4.3 Equilibrium 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. The fact that a positive yield is offered across the full staking range helps alleviate 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 grows 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. Just as when discussing solo staking, if the supply curve indeed is very low, then it seems acceptable to let the deposit size grow a bit above a level sufficient for security so that some staking yield still exists. If the supply curve turns out to be rather high, then a low deposit size is perfectly fine. No SSP can reasonably outcompete all others if there is an equilibrium at a 2.6 % staking yield and 30M ETH staked (as with Option A).\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. Seeing that the cost of operating a node will not be made prohibitively high relative to the yield, the proposed reward curve (or any of the other options) does not explicitly force a low quantity staked, ultimately allowing variety in preferences and circumstances between delegators to take a more central role in shaping the composition of the staking set. There is therefore no compelling argument as to why any one SSP will overtake others under Option A, B, or C. This is especially pertinent when adopting a graduated approach and evaluating the outcome before proceeding further. There is also already the risk of centralization being more likely under the current reward curve, in this case leveraged by some emerging dominant LST as the money of Ethereum.\n4.4 The isoproportion map\nFigure 14 maps y_p𝑦𝑝 for stakers across y𝑦 and D𝐷 under the previously specified burn rate b=0.008𝑏 =0.008 and annual REV V=𝑉 = 300k ETH. The thin black lines can be characterized as “isoproportion” lines across which y_p𝑦𝑝 remains constant (refer to the equation below). The isoproportion map is essential for stakers attempting to understand the effects of issuance policy on their share of the circulating supply. If the slope of the supply curve is steeper than the associated isoproportion line at some specific equilibrium, stakers benefit from an increase in issuance (u'>0𝑢′ >0); if it is flatter, they are worse off. In microeconomics, a “production possibility curve” can be compared with isoprofit lines to optimize a production set. To the staker, the supply curve becomes a “proportion possibility curve” (the PPC of staking economics), capturing how stakers’ attainable proportion of the circulating supply varies with issuance policy.\nTwo hypothetical supply curves are shown in blue, the low supply curve from Figure 12 (dashed) and the baseline supply curve from previous figures (full). The purple isoproportion lines intersect the equilibria of the current reward curve (squares). Since the supply curves (the PPCs) have a flatter slope at equilibrium, stakers are worse off from an increase in issuance, and thus benefit from a decrease in issuance in both cases. They are clearly better off (higher y_p𝑦𝑝) under the low supply curve at the equilibrium for the proposed reward curve (green circle), and left indifferent under the baseline supply curve (as also indicated in Figure 2). The stars mark where the supply curves reach their maximum y_p𝑦𝑝, tangent to the corresponding isoproportion lines. This is the ideal equilibrium in terms of y_p𝑦𝑝 for stakers. All other token holders would of course still gain from a reduction in issuance, so in terms of u'𝑢′, they would certainly prefer an equilibrium at 20M ETH staked under the low supply curve (triangle), where stakers are just as well off as at the outset at the square.\nFigure 141920×1150 174 KB\nFigure 14. Isoproportion map that illustrates the effects of issuance policy on staker’s proportional yield y_p𝑦𝑝 under equilibrium. A reduction in issuance from the current reward curve (black) is profitable to stakers under both hypothetical supply curves, because the purple isoproportion lines have a steeper slope at equilibrium. The stars indicate the maximum attainable y_p𝑦𝑝 along the supply curves.\nDefine v𝑣 as the REV rate v=V/S𝑣 =𝑉/𝑆. The isoproportion line for any specific y_p𝑦𝑝 then follows the equation\n\ny = \\frac{y_p-(1+y_p)(v+b)}{1-d-y_pd},\\quad \\quad y_p<\\frac{1-d}{d}.\n𝑦=𝑦𝑝−(1+𝑦𝑝)(𝑣+𝑏)1−𝑑−𝑦𝑝𝑑,𝑦𝑝<1−𝑑𝑑.\nThis equation implies the basic condition for profitability that can be imposed on the supply curve under any equilibrium (e.g., via derivation and analysis of elasticities). If the (inverse) supply curve follows this equation (along any specified y_p𝑦𝑝), stakers will be indifferent to a change in issuance across the whole deposit ratio range.\n5. Security considerations\n5.1 Economic security\nThere are certain critical thresholds to be attentive to when reasoning about the economic security of Ethereum. An attacker holding more than 1/3 of the stake can delay finality, an attacker holding more than 1/2 can control the fork choice, and an attacker holding more than 2/3 of the stake can finalize the chain. Each of these attacks would cause severe disruption, but comes at a great potential cost to an attacker. In the case of a delay to finality, the attacker is subjected to an inactivity leak. The cost of causing loss of finality for some specific amount of time in some specific way scales linearly with the total deposit size, and quadratically with time. An offline validator leaks around half their ETH in a little less than three weeks during an inactivity leak. A complete cost analysis for causing loss of finality (and other attacks) also needs to account for price movements on the ETH that an attacker necessarily must control. An attacker may both lose ETH and see the value of any ETH they still retain diminish—if the attack causes real damage to Ethereum. For attacks made possible by holding more than 1/2 or 2/3 of the stake, it is a natural assumption that the social layer would intervene. The ultimate recourse would then be to burn some or all of the attacker’s stake.\nWhen it comes to attacks from a smaller stake, there are several reorg attacks and minority discouragement attacks (Section 5.3) to take into consideration. Many of these attacks also depend on the proportion of the stake held by an attacker (i.e., holding 25 % of the stake opens up more avenues than holding 0.1 %). From this brief review, it becomes evident that the quantity of stake cannot be allowed to become too small, because the cost of causing severe disruption to Ethereum would then not match the damage done. Table 2 denotes the cost of 1/3, 1/2 and 2/3 of the stake at a token price of $3000 under a deposit size of 14M ETH (the deposit size at The Merge), 24M ETH (20 % of the stake), and 30M ETH (close to the current deposit size).\n\n1/3\n1/2\n2/3\n\n14M\n$14B\n$21B\n$28B\n\n24M\n$24B\n$36B\n$48B\n\n30M\n$30B\n$45B\n$60B\n\nTable 2. Value at risk for the critical proportions 1/3, 1/2 and 2/3 of the stake at a token price of $3000 across a few relevant deposit sizes.\nWhile present fiat-denominated costs of potential attacks at various deposit sizes are interesting to review, 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, Buterin deliberated on the value that Ethereum can and cannot secure at a deposit ratio of d=0.3𝑑 =0.3. 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 the deposit ratio from 0.3 to 0.6 would only increase the value of 1/3 of the stake from $70M to $140M. This highlights that once the deposit ratio 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. Insights from all sections of this post, including the forthcoming Section 6.4, must thus be considered when settling on a suitable deposit ratio. This is a complex task that cannot be objectively formalized. Note in particular that the level of the staking yield—when considered in isolation—will not be a determinant of the value of the ETH token and thus Ethereum’s economic security, as the yield comes from newly minted tokens, directly diluting holders.\nThere comes a point where the marginal increase in security from adding another validator brings less utility than the utility loss stemming from the numerous downsides of excessive issuance previously outlined. This point hints at a desirable deposit ratio. Justin Drake suggested that d=0.25𝑑 =0.25 (30M ETH) is appropriate in a recent AMA on Reddit. Vitalik Buterin concurred, elaborating on factors influencing the broader composition of the staking set along the lines of Section 4.3, but also added a personal note of finding d=0.125𝑑 =0.125 (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 perfectly reasonable to argue that Ethereum would have higher economic security twenty years from now with a reward curve that sees the deposit ratio settle on d=0.25𝑑 =0.25 than at d=0.75𝑑 =0.75—as long as the composition of the staking set remains viable. When the deposit ratio grows beyond certain limits, even short-term security starts to degrade, in line with the reasoning in Section 2.2. The social layer may lose its neutrality and credibility as the ultimate arbitrator against attacks from dominant SSPs. At the other end, it also seems reasonable to ensure that the deposit size does not fall below 14M ETH, which was the prevailing size at The Merge (or more accurately, that the deposit ratio does not fall below d\\approx0.12𝑑 ≈0.12). Such a lower boundary at least ensures that Ethereum never ventures into unknown territory in terms of stake participation (as previously discussed, it is impossible to ensure that the value of the stake is kept at some specific level relative to the value secured).\nThe discussion of economic security has underscored the complexity involved in determining the correct deposit ratio. As a matter of fact, due to uncertainty regarding several key variables, there is not one specific ratio that always maximizes overall utility. The most suitable deposit ratio will arguably vary with the shape of the supply curve and the cost of providing a certain level of security. If the implied costs associated with staking are higher (as captured in Figure 1), then it seems reasonable to have a slightly lower deposit ratio than if the cost is lower. This is one of the reasons for using a reward curve in the first place—it allows Ethereum to adjust the security level based on the price of that security. Ethereum should thus target a deposit ratio range, which can be rather broad, allowing the supply curve to influence the equilibrium quantity of stake. The proposed reward curve—in the author’s view and under full implementation—balances the many needs of Ethereum, including viable economic security for the short term and possibly the long term (see Section 6.3 for additional nuances).\nTable 3 shows the yield that the protocol will provide at the previously discussed deposit sizes, given the current level of REV. In addition, the outcome if the REV was to completely vanish is also provided. Note that if Ethereum ever adopts MEV burn and there is a clear need for it, the associated hard fork can apply dedicated adjustments for re-calibrating issuance. On the other hand, should the supply curve fall over the next few years and there is an agreement within the community, then the introduction of MEV burn can be conceived as the last step in the moderation of the quantity staked.\n\nA: y_i𝑦𝑖\ny_i+y_v𝑦𝑖 +𝑦𝑣\nB: y_i𝑦𝑖\ny_i+y_v𝑦𝑖 +𝑦𝑣\nC: y_i𝑦𝑖\ny_i+y_v𝑦𝑖 +𝑦𝑣\n\n14M\n3.14 %\n5.28 %\n2.83 %\n4.97 %\n2.22 %\n4.37 %\n\n24M\n1.98 %\n3.23 %\n1.88 %\n3.13 %\n1.70 %\n2.95 %\n\n30M\n1.60 %\n2.60 %\n1.58 %\n2.58 %\n1.52 %\n2.52 %\n\nTable 3. Staking yield at various relevant deposit sizes under the full reduction in issuance.\nThe first column indicates that the quantity staked will stay at healthy levels under Option A, even without REV. It seems reasonable to assume that at least 24M ETH would still be staked at a 2 % yield. Certainly, 14M ETH would still be staked if a 3.1 % yield is offered. However, if this were to be a concern for some reason, the option would then be to move back the peak of the reward curve slightly, while raising F𝐹. For example, the graduated approach could then have a k𝑘 between 25M to 2^{25}225 and the full reduction around 20M; both with a base reward factor in the vicinity of 10^{2}102. The lower yield under Option C can be noted, and is one of the reasons why a base reward factor below F=32𝐹 =32 is undesirable from a security perspective for this option. Table 4 instead shows the outcome under a graduated approach.\n\nAg: y_i𝑦𝑖\ny_i+y_v𝑦𝑖 +𝑦𝑣\nBg: y_i𝑦𝑖\ny_i+y_v𝑦𝑖 +𝑦𝑣\nCg: y_i𝑦𝑖\ny_i+y_v𝑦𝑖 +𝑦𝑣\n\n14M\n3.68 %\n5.82 %\n3.53 %\n5.67 %\n3.06 %\n5.20 %\n\n24M\n2.50 %\n3.75 %\n2.46 %\n3.70 %\n2.33 %\n3.58 %\n\n30M\n2.10 %\n3.10 %\n2.10 %\n3.10 %\n2.09 %\n3.09 %\n\nTable 4. Staking yield at various relevant deposit sizes under a graduated approach.\n5.2 Consensus incentives\nA reduction in issuance will alter the balance between the various roles that consensus participants are assigned to. In particular, the proposer will attain a larger proportion of all rewards, and this may threaten consensus stability. If the yield provided for attestation duties y_a𝑦𝑎 becomes a small proportion, y_a/y𝑦𝑎/𝑦, of the staking yield, stakers can be expected to pursue irregular and adverse activities when profit-maximizing, and the consensus process may break down. They may as an example even stop attesting entirely to avoid the risk of slashing. The proposed reward curve has been designed to give attesters at least half of the rewards at any deposit size under the current level of REV, as illustrated in Figure 15. Should the REV rise substantially, the penalty for a missed target vote (and potentially source vote) can be raised, to give proper incentives for performing attester duties correctly.\nFigure 152078×1","tokens":15000,"squid":"spider-04","role":"Research Spider","at":1791346341446,"hash":"1454ab7b8d00341086ee22490ae0ece1d6b9ad71"}
{"url":"https://ethresear.ch/t/reward-curve-with-tempered-issuance-eip-research-post/19171/6","domain":"ethresear.ch","title":"Reward curve with tempered issuance: EIP research post - 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 2\n\n read \n\n 33\n min\n\n Apr 2024\n\n 4 / 4\n\n May 2024\n\n May 2024\n\n post by aelowsson on Apr 1, 2024\n\n aelowsson\n\n Reward curve with tempered issuance: EIP research post\nBy Anders Elowsson\nMy aim with this post is to present the rationale for a reward curve with tempered issuance. It is a longer format of a forthcoming EIP, offering a more detailed account of the benefits and the trade-offs that must be balanced, as well as a comparison with alternative options. I will try to answer any questions you may have in the comments!\n1. Overview\nValidators began receiving execution layer rewards with The Merge, and liquidity improved when withdrawals were enabled with Shapella. Both upgrades have served to increase the equilibrium quantity of stake. There is a broad consensus that the current deposit size keeps Ethereum sufficiently secure (e.g., 1, 2, 3). Yet issuance will rise substantially as more stake is deposited under the current reward curve. Excessive incentives for staking, beyond what is necessary for security, can unfortunately over time turn into perverse subsidies, with many downsides. This post will explore the benefits of moderating issuance and available options. It concludes that Ethereum should adopt the candidate reward curve, designed to effectively moderate quantity staked while still maintaining reliable consensus incentives, economic security, resistance to discouragement attacks and cartelization attacks, a favorable composition of the staking set, and viable conditions for solo staking. The candidate reward curve divides the equation of the current reward curve by 1+D/k1 +𝐷/𝑘. The single adjusted variable k𝑘 then comes to define the quantity staked at the peak issuance point, which also corresponds to the point where issuance is halved relative to the current reward curve. A setting of k=2^{26}𝑘 =226 (67.1M ETH) is suggested as feasible for the near term, with a subsequent potential final adjustment to k=2^{25}𝑘 =225 (33.6M ETH).\nSection 2 – Rationale\nThe equilibrium yield offered to stakers corresponds to the cost that the marginal staker assigns to staking, i.e., their indifference point between staking and not staking. Section 2.1 shows that if Ethereum offers a higher yield than necessary for maintaining security, it compels its users to incur higher costs, degrading user utility in aggregate. This explains why all ETH holders can benefit from an issuance reduction, something which is also illustrated in Figure 2. The macro perspective is reviewed in Section 2.2. As the quantity of stake grows, one or a few liquid staking tokens (LSTs) may come to supplant ETH as money in Ethereum. Positive network externalities could then lead to both lower user utility and protocol decentralization. Their derivative nature can also erode the social layer’s capacity for upholding Ethereum’s intended consensus process. Section 2.3 suggests that Ethereum should adopt a graduated approach to the proposed changes. Taking a first smaller step will improve Ethereum without being too disruptive, smooth out disequilibria, and allow for an intermediate evaluation of effects on stake composition and quantity.\nSection 3 – Proposed reward curve and alternative paradigms\nSection 3 presents the proposed reward curve and alternative paradigms. The proposed reward curve is labeled as Option A, with an issuance level that slowly falls as the quantity staked increases beyond desirable levels. Option B sees the issuance level will instead approach an asymptotic maximum. Option C is the current reward curve, with a rising issuance across the full staking range. The options are compared in Section 3.4, showing how the reward curves diverge as the quantity staked increases.\nSection 4 – Trade-offs and priors\nSection 4.1 explores yield variability for non-pooled stakers and Section 4.2 then reviews how the equilibrium staking yield may affect the proportion of solo stakers. The biggest risk is that disadvantageous economies of scale make solo staking less viable. However, at a higher quantity staked, dominant staking service providers (SSPs) can offer lower fees, better LST money, and lower risk due to emerging moral hazard. The proposed reward curve offers a positive yield across the full range—low enough to make a high quantity stake unlikely, yet sufficiently high as to never force out solo stakers on efficient setups under more improbable scenarios. It is noted that priors regarding both the supply curve and the level of the maximum extractable value (MEV) are relevant to the design. A scenario with a lower supply curve under the current level of MEV is analyzed in Section 4.2.3, aiding the understanding of how the proposed reward curve helps the consensus mechanism absorb delegating stakers with low reservation yields to ensure that solo stakers always are provided with some yield. The broader composition of the staking set is explored in Section 4.3, emphasizing that competition for delegated stake will take place across diverse market segments. Seeing that the cost of running a staking node will not be made prohibitively high relative to the yield, the proposed change will allow variety in preferences and circumstances between delegators to play a more central role in shaping the composition of the staking set. Section 4.4 finally plots the “isoproportion map”, presenting the conditions under which a change to issuance policy is profitable to stakers.\nSection 5 – Security considerations\nThe effects of issuance policy on economic security are discussed both for the short run and long run in Section 5.1. An important reason for providing a positive yield across the full range in the near term is the to preserve consensus incentives without making more extensive adjustments to the protocol, as discussed in Section 5.2. Sections 5.3-4 take a closer look at discouragement attacks and cartelization attacks. These attacks will become more favorable under stricter reward curves where issuance decreases substantially (particularly under a design with negative issuance levels), and are therefore important to keep in mind. The candidate reward curve does not materially exacerbate the risks of these attacks.\nSection 6 – Conclusions and discussion\nSection 6.1 summarizes the advantages and disadvantages of different issuance levels, and Section 6.2 then presents the author’s conclusion that the proposed candidate reward curve (Option A) is the best alternative for Ethereum at this time. Option C can function as a provisional backup plan. The post concludes by exploring the unknown endgame, broadening the utility measure for token holders to incorporate the development of the entire ecosystem, and cautioning against exploiting users’ bounded rationality concerning yield.\n2. Rationale\n2.1 User utility\nDefine the “reservation yield” as the lowest staking yield y𝑦 at which an individual is willing to stake. Ethereum’s supply curve then emerges from prospective ETH holders’ reservation yields. Figure 1 shows a hypothetical supply curve in blue that will be used in a few examples of this post. Total yearly rewards are Y=yD𝑌 =𝑦𝐷, where D𝐷 is the quantity staked (“deposit size”). A holder’s reservation yield can be characterized as the “indifference point” where they derive as much utility from staking as from not staking. The area below the supply curve thus represents the implied aggregate cost to stakers Y_c𝑌𝑐 and the area above represents their surplus Y_s𝑌𝑠, which combines into total rewards Y_c+Y_s=Y𝑌𝑐 +𝑌𝑠 =𝑌. Relevant costs (broadly defined) 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. A high yield compels users to incur higher costs than necessary for maintaining security, diminishing user utility in aggregate. Slashing 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 actually 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.\nA change to Ethereum’s issuance policy from the current reward curve (illustrated in black) to the proposed reward (green) shifts the equilibrium from the black square (1) to the green circle (2). The associated cost reduction Y'_c𝑌′𝑐 indicated by the darker blue area benefits all ETH holders, because the ETH was just issued to offset staking costs, without generating any surplus. The shift to the equilibrium also transfers a surplus Y'_s𝑌′𝑠 from stakers to all ETH holders (stakers included). The cost reduction is determined by the definite integral of the equation for the inverse supply curve f(x)𝑓(𝑥), bounded by the two equilibrium quantities of the comparative static: Y'_c = \\int_{D_2}^{D_1} f(x)dx\\approx𝑌′𝑐 =∫𝐷1𝐷2𝑓(𝑥)𝑑𝑥 ≈ 446k ETH. The surplus shift is instead quantified as Y'_s = D_1y_1-D_2y_2-Y'_c \\approx𝑌′𝑠 =𝐷1𝑦1 −𝐷2𝑦2 −𝑌′𝑐 ≈ 252k ETH. Thus, almost 2/3 of the issuance reduction directly contributes to welfare improvement, with 1/3 reallocating utility from stakers to all ETH holders. The outcome for a supply curve with a similar shape will be a similar definite integral and cost/surplus respectively. If the supply curve is flatter around the comparative static, Y'_c𝑌′𝑐 becomes relatively larger and Y'_s𝑌′𝑠 relatively smaller, and vice versa.\nFigure 11920×1141 93.9 KB\nFigure 1. Implied cost Y_c𝑌𝑐 and surplus Y_s𝑌𝑠 of staking with a hypothetical supply curve. A change in issuance policy shifts the equilibrium from the black square to the green circle. The cost savings Y'_c𝑌′𝑐 leads to aggregate welfare improvement as long as the protocol remains secure and decentralized, and the reduction in surplus Y'_s𝑌′𝑠 simply shifts some utility from stakers to everyone.\nToo often, all staking yield is considered as a surplus Y_s𝑌𝑠, with the implication that issuance policy is a zero-sum game. But due to the costs that must be borne by stakers, issuance policy is emphatically not zero sum. It is fundamental to understand that by having a higher yield, Ethereum steers its users to take on higher costs in aggregate. This is the reason why everyone can gain when keeping issuance at the minimum viable level, as long as they own the underlying ETH.\nTo illustrate this, the attainable change to someone’s proportion of all ETH can be calculated as\n\ny_p=\\frac{1+y}{1+s}-1.\n𝑦𝑝=1+𝑦1+𝑠−1.\nIt can be interpreted as the Fisher equation adapted to Ethereum. The “proportional yield” y_p𝑦𝑝 can be computed for both stakers and non-stakers, in the latter case with y=0𝑦 =0. The circulating supply inflation rate s=i-b𝑠 =𝑖 −𝑏 derives from the issuance rate i=Y_i/S𝑖 =𝑌𝑖/𝑆 and the burn rate b=B/S=0.008𝑏 =𝐵/𝑆 =0.008, where Y_i𝑌𝑖 is yearly issuance, S𝑆 is the circulating supply and B𝐵 is yearly burn (using the average since The Merge). Further complexities regarding the interpretation of rates in light of compounding effects under a drift of the circulating supply are set aside. Figure 2 illustrates the hypothetical effect of an issuance reduction on user utility, utilizing a comparison of y_p𝑦𝑝 at two different equilibria. It is shown here under the proposed reward curve (Option A) and was in previous work presented when halving issuance with the current reward curve (Option C), under a slightly different supply curve. Both y𝑦 (red arrow) and s𝑠 (orange arrow) are reduced approximately the same, so stakers are left virtually unaffected. Define the change in cardinal utility for a comparative static where y_p𝑦𝑝 changes from y^b_p𝑦𝑏𝑝 to y^a_p𝑦𝑎𝑝 as\n\nu'=\\frac{1+y^a_p}{1+y^b_p}-1,\n𝑢′=1+𝑦𝑎𝑝1+𝑦𝑏𝑝−1,\nbut use the reservation yield as y𝑦 for those who stop staking when computing y^a_p𝑦𝑎𝑝. Below that yield, they do not stake anyway, so they suffer no additional loss in utility as the yield decreases further. As shown in the bottom pane, de-stakers will under this definition derive a higher utility at the new equilibrium, with non-stakers clearly better off. The reason why welfare can improve in this manner is that the staking costs Y'_c𝑌′𝑐 of the blue area from Figure 1 are eliminated. Of course, from a protocol perspective, the question of whether solo stakers continue staking or not is also important. This is a separate topic further explored in Section 4.2. The analysis simply concludes that with the hypothetical supply curve, stakers will be left either unaffected (remaining as stakers if they have low reservation yields) or left even better off—as de-stakers. The effect of issuance policy on stakers under any supply curve is illustrated with an isoproportion map in Section 4.4.\nFigure 21920×1297 138 KB\nFigure 2. The change in y𝑦 and s𝑠 between two hypothetical equilibria is utilized to isolate a change in cardinal utility u'𝑢′ for all token holders. Stakers are subjected to a reduction in yield y𝑦, but the reduction in the inflation rate s𝑠 is similar, so they are left unaffected (y_p𝑦𝑝 stays the same). De-stakers incur no further loss in utility once y𝑦 falls below their reservation yield. They benefit together with non-stakers from the reduction in s𝑠.\nSchwarz-Shilling and Dietrich refer to y_p𝑦𝑝 as the “real total staking yield” (they do not specify an equation in their post, but may imply that they use y_p=y-s𝑦𝑝 =𝑦 −𝑠; with b=0𝑏 =0 for visual clarity). Their plots across reward curves, including plots of Option A, are very useful for conceptualizing the measure itself.\n2.2 Macro perspective\nThe reward curve influences the proportion of all circulating ETH that is staked, and it is therefore important to examine the macro perspective of Ethereum’s issuance policy. This can be regarded as one component of a true cost accounting, extending Section 2.1 to incorporate externalities.\nAn LST exceeding critical thresholds regarding the proportion of stake under its control can gain outsized profits. This stratum for cartelization of block space can ultimately compromise the consensus mechanism. Risks to Ethereum are further exacerbated if an expansive issuance policy (which the current reward curve arguably represents) enables an LST to attain control over a significant proportion of the total ETH—propelled by network externalities of, e.g., the money function. The compromised institution(s) then sits one layer above the consensus mechanism, namely the social layer. It 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. If the community can no longer effectively intervene in the event of for example a 51 % liveness attack, then risk mitigation in the form of the warning system discussed by Buterin may not be effective. The proof-of-stake consensus mechanism has in this case through derivatives grown so interconnected with Ethereum’s users that it has overloaded its ultimate arbitrator, the social consensus mechanism. It is a special and in a way inverted case of issues Buterin previously warned about.\nIf the issuance policy leads to a high proportion of all ETH being staked, one or a few LSTs may overtake as money in the Ethereum ecosystem, embedding themselves across every layer and application. As has been noted, this is a deliberate objective of some SSPs. By moderating the issuance, each LST will have tougher competition with non-staked ETH, ensuring a trustless asset within the ecosystem. The social layer will not become co-dependent on an outside organization and its issued derivative of ETH. The principal–agent problem (PAP) of delegating stake to a dominant LST can then be priced more accurately because moral hazard will be less likely to develop. No LST will grow “too big to fail” in the eyes of the Ethereum social layer. This pricing will reflect the fact that the agent acting on behalf of the delegator (or any party able to inject themselves into that relationship) gains greater opportunities to degrade consensus for its own profit the larger proportion of the stake it controls. The delegating staker must then continuously assess its security guarantees (e.g., the staking agent’s or injecting parties’ own value at risk), knowing that it may lose everything if the worst-case scenario ever comes to pass.\nOne cost explored in Section 2.1 can also affect Ethereum at a macro level. In the case where everyone must stake to not see their savings eroded, differences in tax policies across jurisdictions can hamper geographical decentralization.\n2.3 Graduated approach\nThere are a few arguments for a graduated approach, taking a smaller step in the right direction in one hard fork—evaluating the outcome—and if appropriate taking the final step:\n\nCompromising economic agents’ ability to plan ahead is welfare degrading. While there have been several proposals seeking to temper issuance dating back to at least 2021 (1, 2, 3), individual solo stakers cannot be expected to follow the research debate all too closely. They may first pay attention once a decision has been taken or seriously contemplated. There is also a difference between signaled intentions to moderate issuance and a real decision having been made. A graduated approach is particularly appealing when a change to the issuance policy is implemented relatively shortly after a decision has been made. At the same time, the quantity of stake has at this point already arguably exceeded levels providing sufficient security. Further growth must be considered welfare degrading as well. A graduated approach can in this context:\n\nGive solo stakers, and also SSPs, a longer and more gradual adaptation phase.\nDo something to temper the incentives to stake in the near term, while not being too disruptive.\nConvey the possibility of additional adjustments to users who may not follow ongoing discussions that closely.\n\nIgnoring frictions in the decision to stake, a reduction in issuance will precipitate a temporary phase with below-equilibrium yields, until some stakers leave and a new equilibrium is established. A graduated reduction mitigates this problem. An even more gradual reduction, for instance, encoding a small adjustment to issuance every epoch, would bring more implementation overhead.\nIt is not possible at this time to ascertain that the full issuance reduction will be necessary to temper the growth in the quantity of stake—it is only a reasonable estimate hinging on assumptions of frictions in the decision to stake or a falling supply curve. Therefore, it seems sensible to move gradually, at least as an acknowledgment of these uncertainties. This reasoning accounts for MEV burn on the horizon, which will also affect the staking yield if implemented.\nThere are a few properties of issuance level of particular interest going forward, such as the proportion of solo stakers retained. A graduated approach makes it possible to evaluate intermediate outcomes before implementing the full envisioned issuance reduction. Even if researchers are confident that the full reduction keeps relevant properties in balance, a graduated approach—with an intermediate evaluation before proceeding further—will make the change more palatable to those who may object.\n\nThe next section will present reward curves that incorporate a potential intermediate step as part of a graduated approach.\n3. Proposed reward curve and alternative paradigms\nThere are three fundamental paradigms that the reward curve can be designed according to under current circumstances (e.g., absence of MEV burn, no staking fee, and a desire to keep yield variability manageable; see also Section 4.1 and 5.2). These were stipulated in Table 2 in preceding work and are summarized here in Table 1. Option A is the proposed reward curve. It is best at improving user utility and moderating quantity staked, as advocated in Sections 2.1-2.2. Option C provides a higher yield for (solo) staking in the scenario where almost everyone stakes. This may of course also be seen as a drawback, a trade-off further examined in Sections 4.1-4.3. Option B balances between these two approaches. Section 3.4 will plot the reward curves together for further comparison, both for a full reduction and a graduated approach.\n\nIssuance\nBenefit\n\nOption A:\nFalls marginally at deposit sizes above sufficient security.\nImproves user utility and moderates quantity staked.\n\nOption B:\nAsymptotically approaches maximum fixed level.\nBalances benefits of Option A and C.\n\nOption C:\nContinues increasing indefinitely\nHigher yield for solo staking if quantity staked approaches maximum\n\nTable 1. Three main categories for the reward curves, each explored in this section. Option A is the proposed approach, favored by the author.\n3.1 Option A – Proposed reward curve\nOverview\nThe proposed reward curve attenuates issuance beyond a quantity of stake sufficient for security. It is designed to give very clear mental models: the value of a single adjusted variable k𝑘 also defines the quantity of stake at both the peak issuance and the issuance halving point (relative to the current reward curve). The reward curve was presented as the candidate reward curve in a previous post on properties of issuance level. Figure 3 illustrates annualized issuance level across deposit size under perfect validator performance. Issuance of the current reward curve in black varies with deposit size according to the equation Y_i=cF\\sqrt{D}𝑌𝑖 =𝑐𝐹√𝐷, with F𝐹 set to 64 and the constant c\\approx2.6𝑐 ≈2.6. The grey curve shows halved issuance (F=32𝐹 =32). The proposed reward curve in green introduces a division by 1+D/k1 +𝐷/𝑘\n\nY_i=\\frac{cF\\sqrt{D}}{1+D/k},\n𝑌𝑖=𝑐𝐹√𝐷1+𝐷/𝑘,\nwith c𝑐 and F𝐹 unchanged. The full reduction is intended to be k=2^{25}𝑘 =225, which gives a peak issuance slightly below 0.5M ETH at 2^{25}225 (33.6M) ETH staked (plus sign), which is also the halving point. The dashed green curve with k=2^{26}𝑘 =226 (around 67.1M) indicates a potential step in a graduated approach. The fact that the reward curve stipulates a maximum issuance level, which cannot be exceeded, may be beneficial from a communication perspective. In the future, Ethereum’s reward curve shall transition to vary with deposit ratio d=D/S𝑑 =𝐷/𝑆 (see Section 6.3), which will then instead translate into a maximum circulating supply inflation rate.\nFigure 31920×1126 94.2 KB\nFigure 3. Issuance level for the proposed reward curve—Option A—in green, compared to the current reward curve in black. The dashed green line represents a stepwise reduction in a potential graduated approach. Halved issuance relative to the current reward curve is indicated in grey, with plus signs indicating both halving points and issuance peaks.\nFigure 4 illustrates the staking yield in green, assuming a realized extractable value (REV) of V=𝑉 = 300k ETH/year (REV is MEV after builders take their cut and the current prevailing level is slightly above 300k). The equation for staking yield is y=y_i+y_v𝑦 =𝑦𝑖 +𝑦𝑣, with y_i=Y_i/D𝑦𝑖 =𝑌𝑖/𝐷 and y_v=V/D𝑦𝑣 =𝑉/𝐷. The equation for issuance yield thus becomes\n\ny_i=\\frac{cF}{\\sqrt{D}(1+D/k)},\n𝑦𝑖=𝑐𝐹√𝐷(1+𝐷/𝑘),\nonce again multiplying the denominator of the current reward curve (y_i=cF/\\sqrt{D}𝑦𝑖 =𝑐𝐹/√𝐷) by 1+D/k1 +𝐷/𝑘. The same hypothetical supply curve as in Section 2.1 is included in Figure 4. It serves to illustrate how the propensity to supply stake may potentially vary across yield and deposit size a few years from now, and what the impact on the staking equilibrium then becomes with an altered reward curve. In this particular example, the equilibrium yield is reduced by 0.6 % (around 1/5), from 2.94 % with the current reward curve (black rectangle) to 2.34 % with the new reward curve (green circle). In the graduated approach, the equilibrium yield is reduced by only 0.43 % (around 1/7).\nA reasonable assumption is that the supply curve will gradually shift downwards over time as the staking experience simplifies and DeFi integrations improve. This will in essence depend on how the various costs outlined in Section 2.1 evolve. The faint blue curve could then be the supply curve after another year or two has passed. This would further reduce the yield under both the present and proposed reward curve. The supply curve may also under some circumstances shift upward, for instance, due to a consensus failure prompting stakers to reevaluate risks, or due to increased demand for non-staked ETH, elevating opportunity costs.\nFigure 41920×1150 102 KB\nFigure 4. Staking yield (inclusive of REV) for the proposed reward curve—Option A—in green, compared to the current reward curve in black. The graduated approach is depicted in dashed green. Hypothetical changes in equilibrium from the black square to the green circles are indicated as a guideline, but remain speculative due to uncertainty regarding both the supply curve and future levels of REV.\nReward variability\nIn preparation for the EIP, a simulation of reward variability was performed with current data for REV. Figure 5 shows the simulated cumulative distribution function (CDF) of rewards for solo stakers at various deposit sizes for the proposed reward curve in its full implementation. Figure 6 instead shows the simulated outcome for the graduated approach.\nFigure 51920×1056 124 KB\nFigure 5. Solo staker yield variability at various quantities staked under the candidate reward curve and present level of REV. Expected staking yields are indicated by dashed vertical lines.\nFigure 61920×1056 127 KB\nFigure 6. Solo staker yield variability at various quantities staked under a graduated implementation of the candidate reward curve and present level of REV. Expected staking yields are indicated by dashed vertical lines.\n3.2 Option B – Asymptotically fixed issuance\nOverview\nA somewhat more modest option is to instead divide the present reward curve with 1+\\sqrt{D}/k1 +√𝐷/𝑘, giving an issuance of\n\nY_i=\\frac{cF\\sqrt{D}}{1+\\sqrt{D}/k}=\\frac{cF}{D^{-0.5}+k^{-1}}.\n𝑌𝑖=𝑐𝐹√𝐷1+√𝐷/𝑘=𝑐𝐹𝐷−0.5+𝑘−1.\nThe equation is in essence a log-logistic CDF, and issuance will thus approach an asymptotic maximum of cFk𝑐𝐹𝑘 (but it may not come close to that value while Ethereum operates at its current circulating supply). Figure 7 illustrates a potential reward curve for Option B in orange with k=2^{12}𝑘 =212 and a potential graduated approach with k=2^{13}𝑘 =213. As indicated in the figure, the variable F𝐹 was adjusted to produce a similar issuance as Options A (and Option C) at specific levels, for easier comparison in subsequent sections. Hence, the halving point marked by a plus sign is also around D=2^{25}𝐷 =225, and the graduated approach matches the issuance of Option A at the current quantity staked (31M ETH). But F𝐹 could be re-adjusted to 64, which would increase the probability of an equilibrium at a lower quantity staked.\nFigure 71920×1126 87.5 KB\nFigure 7. Issuance level for Option B in orange, relative to the current reward curve in black. The dashed orange line outlines a stepwise reduction in a potential graduated approach. Halved issuance relative to the current reward curve is indicated in grey with plus signs.\nThe equation for issuance yield instead becomes\n\ny_i=\\frac{cF}{\\sqrt{D}+D/k}.\n𝑦𝑖=𝑐𝐹√𝐷+𝐷/𝑘.\nIt is plotted in Figure 10 in Section 3.4 together with the other reward curves.\n3.3 Option C – Current reward curve with reduced base reward factor\nOverview\nThe simplest option is to reduce the base reward factor, keeping the current reward curve. The full reduction could then be F=32𝐹 =32. It can be noted that this reward curve will reduce the yield relatively more at lower quantities of stake, so F𝐹 can hardly be reduced below 32 from a security perspective, at least not at this point (see also Section 5.1). A graduated approach should opt for a range between 40-48. In this post, F=44𝐹 =44 will be illustrated, since the graduated reward curve will then coincide with all others for easier comparison. Figure 8 plots issuance. Yield is plotted in Figure 10 in Section 3.4 together with the other reward curves.\nFigure 85368×3104 497 KB\nFigure 8. Issuance level for Option C, relying on the current reward curve with a reduced base reward factor. The dashed grey curve indicates a potential setting for the graduated approach. The full possible reduction that retains sufficient economic security is a halving of issuance, indicated by the grey curve.\n3.4 Comparison of Options A-C\nFigure 9 shows the three outlined options, both for a full reduction and a graduated approach. With the full reduction, all curves coincide around D=2^{25}𝐷 =225 ETH (circle), above which issuance for Option A declines, B levels off, and C continues increasing. With the graduated approach, all curves (dashed) coincide around the current quantity of stake of D=𝐷 = 31M ETH (star), after which they diverge in a similar pattern. It can be noted that the graduated approach of both Option A and (narrowly) Option B gives a lower issuance if all ETH is staked than the full reduction in Option C.\nFigure 91920×1110 96.9 KB\nFigure 9. Comparison of issuance levels for Options A-C, with the graduated approach depicted by dashed curves. The three options provide the same issuance at around 2^{25}225 ETH staked for the full reduction (circle) and at 31M ETH for the graduated step (star), above which issuance for Option A falls, B flatlines, and C continues rising.\nFigure 10 shows the staking yield (at the present level of REV) for the same three options. The black double-sided arrow illustrates that the initial reduction in staking yield at the present quantity staked would be under 1 %. The blue double-sided arrows capture the equilibrium shift in yield under the same hypothetical supply curves as previously, demonstrating that the hypothetical reduction in yield would be under 0.5 % for the first graduated step.\nFigure 101920×1150 115 KB\nFigure 10. Comparison of staking yield (at the present level of REV) for Options A-C, with the graduated approach illustrated by dashed curves, and the current reward curve in black. A shift in the equilibrium from the black square to the circle is indicated as a guideline, but there is uncertainty regarding both the supply curve and future REV. The initial reduction in the graduated approach is under 1 % (black arrows) and under 0.5 % at hypothetical equilibria (blue arrows).\n4. Trade-offs and priors\n4.1 Variability 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 simulation of reward variability was performed with current data for REV, resulting in, e.g., the CDFs of Figures 5-6, but also mappings of standard deviations (SDs) of annualized yield across y𝑦 and D𝐷. Recognizing that stakers may be more more sensitive to variance at lower staking yields, the SDs were divided by the square root of the expected yield, referred to as the SSD. This measure attempts to capture degradation from variability for non-pooled stakers. Figure 11 plots the SSD across quantity staked for the different reward curves of this study (lower is better). As evident, the SSD will rise marginally for Option A as the quantity staked increases. This increase is considered acceptable, on the basis that it is reasonable to sacrifice some variability to keep the quantity staked down. When considered in isolation, it is perhaps even desirable to allow the SSD to become a little worse at higher quantities staked than at lower quantities. But having a lower SSD at any D𝐷 is of course preferable.\nFigure 115253×2911 511 KB\nFigure 11. The SSD for the different reward curves (lower is better) across deposit size.\n4.2 Equilibrium yield and the proportion of solo stakers\n4.2.1 Overview\nEthereum wants to retain solo stakers, certainly 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). Using Figure 10 as an example, it is not clear whether the proportion of solo stakers is lower at a hypothetical equilibrium of around 33M ETH staked and a staking yield of 2.34 % than at around 50M ETH staked and a staking yield of 2.94 %. A concern is if there might be a staking yield below which solo stakers in particular would drop off due to the relatively higher fixed costs associated with solo staking. If solo stakers leave en masse below a yield of 2.5 %, then a staking yield of 2.34 % at 33M 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 (see also Section 2.2):\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 PAP 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. 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.\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.\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. An 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 the most 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. This research topic is certain to receive further attention (1, 2).\n4.2.2 Priors regarding the supply curve and REV\nStudying the yield offered at 110M ETH staked in the CDF of staking yield for Option A in Figure 5 may raise particular concerns. The expected staking yield there is only 0.65 %. At a token price of around $3000, a 32 ETH stake would then only generate an expected monthly income just above $50. The “guaranteed” attestation yield not deriving from block proposal or sync-committee duties is only half of that. A decline in the ETH token price could further reduce the income from staking. However, it should be noted that a reasonable prior for the supply curve is that the yield must be quite a bit higher than 0.65 % for 110M ETH to get staked. The only time an equilibrium can be expected at 110M ETH staked is then if the REV increases significantly, pushing up the staking yield to required levels. One easily overlooked benefit of a lower issuance yield at high quantities staked is thus that it pre-emptively counters a higher REV (the staking yield will never go below the marginal staker’s reservation yield under equilibrium). Concerns may of course also be raised around the fact that the quantity of stake is allowed to expand to 110M ETH in the first place, given the good arguments against it. Why offer any yield at all? Besides care for solo stakers, important reasons pertaining to consensus incentives at the present are provided in Section 5.2.\n4.2.3 Low-yield scenario\nWhile it seems probable that a high quantity staked under the proposed reward curve (Option A) would be associated with an elevated level of REV, thus maintaining a slightly higher staking yield, it can still be valuable to examine the alternative scenario. What if the supply curve indeed falls substantially over the next decade to a very low level? Option A gives a staking yield to 1 % at around 74.6M ETH staked under the current level of REV. Option B gives a staking yield of 1.16 % there, and Option C sets it to 1.37 %. But the equilibrium would of course shift to a higher quantity staked for Option B and C, reducing the yield a bit in the process. A hypothetical outcome for Options A-C in a scenario with an equilibrium yield of 1 % for Option A (green circle) is shown in Figure 12. It is of course challenging to speculate on what the supply curve might look like in this unlikely scenario, but it may still be helpful to plot one possible outcome to aid the understanding (it is formed as in the previous study using k=1𝑘 =1 and c_2 = 0.001𝑐2 =0.001). Option B then gives a yield of 1.09 % at an equilibrium of around 80M ETH staked (orange circle) and Option C gives 1.24 % at around 87M ETH staked (grey circle). Which outcome is better for Ethereum?\nFigure 121920×1137 103 KB\nFigure 12. Hypothetical equilibria in a scenario with a low supply curve that intersects 1 % staking yield of Option A under the current level of REV.\nIf many solo stakers have a reservation yield between 1.24 % and 1 %—in this particular scenario where the majority is staked with reservation yields below 1 %—then they could be disproportionately more likely to drop off. This goes back to the trade-off between the relatively higher fixed costs for solo stakers and the benefits of LSTs at high quantities staked: the notion that dominant SSPs can offer lower fees, better LST money, and lower risk due to emerging moral hazard.\nEthereum can be designed to enforce an equilibrium at any point along the supply curve (but must be attentive to the level of y_i𝑦𝑖 relative to y_v𝑦𝑣). Would enforcing an equilibrium at the blue star be preferable under this supply curve? It corresponds to 30M ETH staked and a total staking yield of around 0.37 %. At present, y_v𝑦𝑣 is 1 % at 30M ETH staked, so a staking fee would need to be introduced and taken out every epoch. This would require making solo stakers lose money every epoch, on the slim chance that they may be assigned to propose a block. That outcome is rather unappealing. But what about after introducing MEV burn, would it be desirable at that point? There are several arguments in favor of it (e.g., Section 2), but it could also render solo staking rather disadvantageous due to the relatively higher fixed costs. The effect on the composition of the staking set is harder to predict when enforcing a low quantity staked in such a manner at this point (refer also the next subsection). If the equilibrium yield is 2.6 % at 30M ETH staked, as with the candidate reward curve, then the outcome is far less controversial. An upward shift to the equilibrium quantity of stake—from the blue star to the green circle—acts as a “safety valve”, which helps Ethereum neutralize the less desirable properties of a low quantity of stake under a lower supply curve. The consensus mechanism essentially absorbs all delegating stakers with low reservation yields, just to push up the yield enough to allow solo stakers to still operate a 32 ETH validator at a profit. Regardless of whether this is desirable or not, for the sake of users, the upward shift must only take place if strictly required. This is something that the reward curve facilitates.\nIt can be interesting to note the difference between the proposed Option A and the current reward curve also under this hypothetical supply curve. The staking yield at the black square in Figure 12 is around 2 % and the incentives to stake thus much higher, drawing 105M ETH into staking. The downsides are the same as previously discussed. Everyone is forced to stake to not see their savings eroded. The issuance level at the black square is around 1708k ETH per year, i.e., almost four times higher than under Option A. Therefore, even though the yield increases by almost 1 %, the supply inflation rate increases even more. Thus, remarkably, stakers are still left worse off under the current reward curve than under Option A, and everyone loses in terms of u'𝑢′. This follows from the fact that the gain in y_i𝑦𝑖 does not materially surpass the loss from the increased issuance rate i=y_id𝑖 =𝑦𝑖𝑑, where d𝑑 is the deposit ratio d=D/S𝑑 =𝐷/𝑆. Thus, for an increase in issuance to be profitable at high deposit ratios, the supply curve must slope almost vertically upwards, as further explored in Section 4.4 and Figure 14.\nIn the example in Figure 12 with a low supply curve, changing from Option C (grey circle) to Option A (green circle) reduces issuance by around 330k ETH, from around 775k ETH down to 446k ETH. Around 42 % of that reduction corresponds to decreased implied costs Y'_c𝑌′𝑐. The change in utility for ETH holders is shown in Figure 13. Everyone would be better off at the equilibrium of Option A than Option C (disregarding frictions). However, as previously mentioned, this does not mean that solo stakers will keep staking. They could be even better off de-staking, if their reservation yield sits in between 1 % and 1.24 %. From a macro perspective, the overall protocol (including the ETH token holders) could then be worse off if the proportion of solo stakers falls too much. The macro perspective is further interwoven with user utility in Section 6.4.\nFigure 131920×1289 133 KB\nFigure 13. Isolating the change in utility u'𝑢′ when changing from Option C to Option A under a low supply curve. Stakers are subjected to a reduction in yield y𝑦, but the reduction in the inflation rate s𝑠 is larger, so they are left slightly better off. De-stakers incur no further loss in utility once y𝑦 falls below their reservation yield. They benefit together with non-stakers from the reduction in s𝑠.\n4.3 Equilibrium 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. The fact that a positive yield is offered across the full staking range helps alleviate 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 grows 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. Just as when discussing solo staking, if the supply curve indeed is very low, then it seems acceptable to let the deposit size grow a bit above a level sufficient for security so that some staking yield still exists. If the supply curve turns out to be rather high, then a low deposit size is perfectly fine. No SSP can reasonably outcompete all others if there is an equilibrium at a 2.6 % staking yield and 30M ETH staked (as with Option A).\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. Seeing that the cost of operating a node will not be made prohibitively high relative to the yield, the proposed reward curve (or any of the other options) does not explicitly force a low quantity staked, ultimately allowing variety in preferences and circumstances between delegators to take a more central role in shaping the composition of the staking set. There is therefore no compelling argument as to why any one SSP will overtake others under Option A, B, or C. This is especially pertinent when adopting a graduated approach and evaluating the outcome before proceeding further. There is also already the risk of centralization being more likely under the current reward curve, in this case leveraged by some emerging dominant LST as the money of Ethereum.\n4.4 The isoproportion map\nFigure 14 maps y_p𝑦𝑝 for stakers across y𝑦 and D𝐷 under the previously specified burn rate b=0.008𝑏 =0.008 and annual REV V=𝑉 = 300k ETH. The thin black lines can be characterized as “isoproportion” lines across which y_p𝑦𝑝 remains constant (refer to the equation below). The isoproportion map is essential for stakers attempting to understand the effects of issuance policy on their share of the circulating supply. If the slope of the supply curve is steeper than the associated isoproportion line at some specific equilibrium, stakers benefit from an increase in issuance (u'>0𝑢′ >0); if it is flatter, they are worse off. In microeconomics, a “production possibility curve” can be compared with isoprofit lines to optimize a production set. To the staker, the supply curve becomes a “proportion possibility curve” (the PPC of staking economics), capturing how stakers’ attainable proportion of the circulating supply varies with issuance policy.\nTwo hypothetical supply curves are shown in blue, the low supply curve from Figure 12 (dashed) and the baseline supply curve from previous figures (full). The purple isoproportion lines intersect the equilibria of the current reward curve (squares). Since the supply curves (the PPCs) have a flatter slope at equilibrium, stakers are worse off from an increase in issuance, and thus benefit from a decrease in issuance in both cases. They are clearly better off (higher y_p𝑦𝑝) under the low supply curve at the equilibrium for the proposed reward curve (green circle), and left indifferent under the baseline supply curve (as also indicated in Figure 2). The stars mark where the supply curves reach their maximum y_p𝑦𝑝, tangent to the corresponding isoproportion lines. This is the ideal equilibrium in terms of y_p𝑦𝑝 for stakers. All other token holders would of course still gain from a reduction in issuance, so in terms of u'𝑢′, they would certainly prefer an equilibrium at 20M ETH staked under the low supply curve (triangle), where stakers are just as well off as at the outset at the square.\nFigure 141920×1150 174 KB\nFigure 14. Isoproportion map that illustrates the effects of issuance policy on staker’s proportional yield y_p𝑦𝑝 under equilibrium. A reduction in issuance from the current reward curve (black) is profitable to stakers under both hypothetical supply curves, because the purple isoproportion lines have a steeper slope at equilibrium. The stars indicate the maximum attainable y_p𝑦𝑝 along the supply curves.\nDefine v𝑣 as the REV rate v=V/S𝑣 =𝑉/𝑆. The isoproportion line for any specific y_p𝑦𝑝 then follows the equation\n\ny = \\frac{y_p-(1+y_p)(v+b)}{1-d-y_pd},\\quad \\quad y_p<\\frac{1-d}{d}.\n𝑦=𝑦𝑝−(1+𝑦𝑝)(𝑣+𝑏)1−𝑑−𝑦𝑝𝑑,𝑦𝑝<1−𝑑𝑑.\nThis equation implies the basic condition for profitability that can be imposed on the supply curve under any equilibrium (e.g., via derivation and analysis of elasticities). If the (inverse) supply curve follows this equation (along any specified y_p𝑦𝑝), stakers will be indifferent to a change in issuance across the whole deposit ratio range.\n5. Security considerations\n5.1 Economic security\nThere are certain critical thresholds to be attentive to when reasoning about the economic security of Ethereum. An attacker holding more than 1/3 of the stake can delay finality, an attacker holding more than 1/2 can control the fork choice, and an attacker holding more than 2/3 of the stake can finalize the chain. Each of these attacks would cause severe disruption, but comes at a great potential cost to an attacker. In the case of a delay to finality, the attacker is subjected to an inactivity leak. The cost of causing loss of finality for some specific amount of time in some specific way scales linearly with the total deposit size, and quadratically with time. An offline validator leaks around half their ETH in a little less than three weeks during an inactivity leak. A complete cost analysis for causing loss of finality (and other attacks) also needs to account for price movements on the ETH that an attacker necessarily must control. An attacker may both lose ETH and see the value of any ETH they still retain diminish—if the attack causes real damage to Ethereum. For attacks made possible by holding more than 1/2 or 2/3 of the stake, it is a natural assumption that the social layer would intervene. The ultimate recourse would then be to burn some or all of the attacker’s stake.\nWhen it comes to attacks from a smaller stake, there are several reorg attacks and minority discouragement attacks (Section 5.3) to take into consideration. Many of these attacks also depend on the proportion of the stake held by an attacker (i.e., holding 25 % of the stake opens up more avenues than holding 0.1 %). From this brief review, it becomes evident that the quantity of stake cannot be allowed to become too small, because the cost of causing severe disruption to Ethereum would then not match the damage done. Table 2 denotes the cost of 1/3, 1/2 and 2/3 of the stake at a token price of $3000 under a deposit size of 14M ETH (the deposit size at The Merge), 24M ETH (20 % of the stake), and 30M ETH (close to the current deposit size).\n\n1/3\n1/2\n2/3\n\n14M\n$14B\n$21B\n$28B\n\n24M\n$24B\n$36B\n$48B\n\n30M\n$30B\n$45B\n$60B\n\nTable 2. Value at risk for the critical proportions 1/3, 1/2 and 2/3 of the stake at a token price of $3000 across a few relevant deposit sizes.\nWhile present fiat-denominated costs of potential attacks at various deposit sizes are interesting to review, 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, Buterin deliberated on the value that Ethereum can and cannot secure at a deposit ratio of d=0.3𝑑 =0.3. 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 the deposit ratio from 0.3 to 0.6 would only increase the value of 1/3 of the stake from $70M to $140M. This highlights that once the deposit ratio 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. Insights from all sections of this post, including the forthcoming Section 6.4, must thus be considered when settling on a suitable deposit ratio. This is a complex task that cannot be objectively formalized. Note in particular that the level of the staking yield—when considered in isolation—will not be a determinant of the value of the ETH token and thus Ethereum’s economic security, as the yield comes from newly minted tokens, directly diluting holders.\nThere comes a point where the marginal increase in security from adding another validator brings less utility than the utility loss stemming from the numerous downsides of excessive issuance previously outlined. This point hints at a desirable deposit ratio. Justin Drake suggested that d=0.25𝑑 =0.25 (30M ETH) is appropriate in a recent AMA on Reddit. Vitalik Buterin concurred, elaborating on factors influencing the broader composition of the staking set along the lines of Section 4.3, but also added a personal note of finding d=0.125𝑑 =0.125 (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 perfectly reasonable to argue that Ethereum would have higher economic security twenty years from now with a reward curve that sees the deposit ratio settle on d=0.25𝑑 =0.25 than at d=0.75𝑑 =0.75—as long as the composition of the staking set remains viable. When the deposit ratio grows beyond certain limits, even short-term security starts to degrade, in line with the reasoning in Section 2.2. The social layer may lose its neutrality and credibility as the ultimate arbitrator against attacks from dominant SSPs. At the other end, it also seems reasonable to ensure that the deposit size does not fall below 14M ETH, which was the prevailing size at The Merge (or more accurately, that the deposit ratio does not fall below d\\approx0.12𝑑 ≈0.12). Such a lower boundary at least ensures that Ethereum never ventures into unknown territory in terms of stake participation (as previously discussed, it is impossible to ensure that the value of the stake is kept at some specific level relative to the value secured).\nThe discussion of economic security has underscored the complexity involved in determining the correct deposit ratio. As a matter of fact, due to uncertainty regarding several key variables, there is not one specific ratio that always maximizes overall utility. The most suitable deposit ratio will arguably vary with the shape of the supply curve and the cost of providing a certain level of security. If the implied costs associated with staking are higher (as captured in Figure 1), then it seems reasonable to have a slightly lower deposit ratio than if the cost is lower. This is one of the reasons for using a reward curve in the first place—it allows Ethereum to adjust the security level based on the price of that security. Ethereum should thus target a deposit ratio range, which can be rather broad, allowing the supply curve to influence the equilibrium quantity of stake. The proposed reward curve—in the author’s view and under full implementation—balances the many needs of Ethereum, including viable economic security for the short term and possibly the long term (see Section 6.3 for additional nuances).\nTable 3 shows the yield that the protocol will provide at the previously discussed deposit sizes, given the current level of REV. In addition, the outcome if the REV was to completely vanish is also provided. Note that if Ethereum ever adopts MEV burn and there is a clear need for it, the associated hard fork can apply dedicated adjustments for re-calibrating issuance. On the other hand, should the supply curve fall over the next few years and there is an agreement within the community, then the introduction of MEV burn can be conceived as the last step in the moderation of the quantity staked.\n\nA: y_i𝑦𝑖\ny_i+y_v𝑦𝑖 +𝑦𝑣\nB: y_i𝑦𝑖\ny_i+y_v𝑦𝑖 +𝑦𝑣\nC: y_i𝑦𝑖\ny_i+y_v𝑦𝑖 +𝑦𝑣\n\n14M\n3.14 %\n5.28 %\n2.83 %\n4.97 %\n2.22 %\n4.37 %\n\n24M\n1.98 %\n3.23 %\n1.88 %\n3.13 %\n1.70 %\n2.95 %\n\n30M\n1.60 %\n2.60 %\n1.58 %\n2.58 %\n1.52 %\n2.52 %\n\nTable 3. Staking yield at various relevant deposit sizes under the full reduction in issuance.\nThe first column indicates that the quantity staked will stay at healthy levels under Option A, even without REV. It seems reasonable to assume that at least 24M ETH would still be staked at a 2 % yield. Certainly, 14M ETH would still be staked if a 3.1 % yield is offered. However, if this were to be a concern for some reason, the option would then be to move back the peak of the reward curve slightly, while raising F𝐹. For example, the graduated approach could then have a k𝑘 between 25M to 2^{25}225 and the full reduction around 20M; both with a base reward factor in the vicinity of 10^{2}102. The lower yield under Option C can be noted, and is one of the reasons why a base reward factor below F=32𝐹 =32 is undesirable from a security perspective for this option. Table 4 instead shows the outcome under a graduated approach.\n\nAg: y_i𝑦𝑖\ny_i+y_v𝑦𝑖 +𝑦𝑣\nBg: y_i𝑦𝑖\ny_i+y_v𝑦𝑖 +𝑦𝑣\nCg: y_i𝑦𝑖\ny_i+y_v𝑦𝑖 +𝑦𝑣\n\n14M\n3.68 %\n5.82 %\n3.53 %\n5.67 %\n3.06 %\n5.20 %\n\n24M\n2.50 %\n3.75 %\n2.46 %\n3.70 %\n2.33 %\n3.58 %\n\n30M\n2.10 %\n3.10 %\n2.10 %\n3.10 %\n2.09 %\n3.09 %\n\nTable 4. Staking yield at various relevant deposit sizes under a graduated approach.\n5.2 Consensus incentives\nA reduction in issuance will alter the balance between the various roles that consensus participants are assigned to. In particular, the proposer will attain a larger proportion of all rewards, and this may threaten consensus stability. If the yield provided for attestation duties y_a𝑦𝑎 becomes a small proportion, y_a/y𝑦𝑎/𝑦, of the staking yield, stakers can be expected to pursue irregular and adverse activities when profit-maximizing, and the consensus process may break down. They may as an example even stop attesting entirely to avoid the risk of slashing. The proposed reward curve has been designed to give attesters at least half of the rewards at any deposit size under the current level of REV, as illustrated in Figure 15. Should the REV rise substantially, the penalty for a missed target vote (and potentially source vote) can be raised, to give proper incentives for performing attester duties correctly.\nFigure 152078×1302 176 KB\nFigure 15. Proportion of the staking yield prov","tokens":15000,"squid":"spider-04","role":"Research Spider","at":1791346351893,"hash":"e6943b711abcf926dd89226a8196833fb375470f"}
{"url":"https://www.metaplex.com/docs/nfts/fetch-nft","domain":"metaplex.com","title":"Fetch an NFT | NFTs","text":"Fetch NFT data from the Solana blockchain. Fetch an NFT or a CollectionIn the following section you can find a full code example and the parameters that you might need to change. You can learn more about fetching NFTs and collections in the Core documentation.1import { fetchAsset, fetchCollection, mplCore } from '@metaplex-foundation/mpl-core';\n2import { publicKey } from '@metaplex-foundation/umi';\n3import { createUmi } from '@metaplex-foundation/umi-bundle-defaults';\n4\n5// Initialize UMI\n6const umi = createUmi('https://api.devnet.solana.com')\n7 .use(mplCore())\n8\n9// Fetch a Core Asset\n10const assetAddress = publicKey('AssetAddressHere...')\n11const asset = await fetchAsset(umi, assetAddress)\n12\n13// Fetch a Core Collection\n14const collectionAddress = publicKey('CollectionAddressHere...')\n15const collection = await fetchCollection(umi, collectionAddress)\n16\n17console.log('Asset fetched:', asset)\n18console.log('Name:', asset.name)\n19console.log('Owner:', asset.owner)\n20console.log('URI:', asset.uri)\n21\n22console.log('\\nCollection fetched:', collection)\n23console.log('Name:', collection.name)\n24console.log('URI:', collection.uri)\n1# Fetch an NFT using the Metaplex CLI\n2\n3# Fetch asset by ID\n4mplx core fetch asset <assetId>\n5\n6# Download all files to a directory\n7mplx core fetch asset <assetId> --download --output ./assets\n8\n9# Download only the image\n10mplx core fetch asset <assetId> --download --image\n11\n12# Download only the metadata\n13mplx core fetch asset <assetId> --download --metadata\n1// npm install @metaplex-foundation/umi @metaplex-foundation/umi-bundle-defaults @metaplex-foundation/digital-asset-standard-api\n2import { publicKey } from '@metaplex-foundation/umi'\n3import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n4import { dasApi } from '@metaplex-foundation/digital-asset-standard-api'\n5\n6// Initialize Umi with a DAS-enabled RPC endpoint\n7const umi = createUmi('https://api.devnet.solana.com').use(dasApi())\n8\n9// The address of the NFT you want to fetch\n10const assetAddress = publicKey('YOUR_NFT_ADDRESS')\n11\n12// Fetch the asset using DAS API\n13const asset = await umi.rpc.getAsset(assetAddress)\n14\n15console.log('Asset ID:', asset.id)\n16console.log('Name:', asset.content.metadata?.name)\n17console.log('Description:', asset.content.metadata?.description)\n18console.log('Image:', asset.content.links?.image)\n19console.log('Owner:', asset.ownership.owner)\n20console.log('Interface:', asset.interface)\n1# Fetch an NFT using the DAS API\n2curl -X POST \\\n3 -H \"Content-Type: application/json\" \\\n4 -d '{\n5 \"jsonrpc\": \"2.0\",\n6 \"id\": 1,\n7 \"method\": \"getAsset\",\n8 \"params\": {\n9 \"id\": \"<NFT Mint Address>\"\n10 }\n11 }' \\\n12 https://api.devnet.solana.com\nParametersCustomize these parameters for your fetch:ParameterDescriptionassetAddressThe public key of the NFT assetcollectionAddressThe public key of the collection (optional)How It WorksThe fetch process involves these steps:Get the address - You need the public key of the NFT asset or collection you want to fetchFetch asset data - Use fetchAsset to retrieve NFT information including name, URI, owner, and pluginsFetch collection data - Use fetchCollection to retrieve collection information (optional)NFT and Collection DataWhen you fetch an asset, you get back all its data:Name - The NFT's nameURI - Link to the metadata JSONOwner - The wallet that owns the NFTUpdate Authority - Who can modify the NFTPlugins - Any attached plugins like royalties or attributesWhen you fetch a collection, you get:Name - The collection's nameURI - Link to the collection metadata JSONUpdate Authority - Who can modify the collectionNum Minted - Number of assets in the collectionPlugins - Any attached plugins like royalties or attributes","tokens":933,"squid":"dotcat","role":"Tooling Spider","at":1791346365031,"hash":"06794d6bdc7acbb170f87b68f399a79fa577a3ed"}
{"url":"https://consensysdiligence.github.io/smart-contract-best-practices/general-philosophy/blockchain-properties/","domain":"consensysdiligence.github.io","title":"Blockchain Properties - Ethereum Smart Contract Best Practices","text":"Blockchain Properties\n\nTip\nFor comprehensive insights into secure development practices, consider visiting the Development Recommendations section of the Smart Contract Security Field Guide. This resource provides in-depth articles to guide you in developing robust and secure smart contracts.\n\nWhile much of your programming experience will be relevant to Ethereum programming, there are some\npitfalls to be aware of.\n\nBe extremely careful about external contract calls, which may execute malicious code and change\n control flow.\nUnderstand that your public functions are public, and may be called maliciously and in any order.\n The private data in smart contracts is also viewable by anyone.\nKeep gas costs and the block gas limit in mind.\nBe aware that timestamps are imprecise on a blockchain, miners can influence the time of\n execution of a transaction within a margin of several seconds.\nRandomness is non-trivial on blockchain, most approaches to random number generation are gameable\n on a blockchain.","tokens":253,"squid":"spider-06","role":"Security Spider","at":1791346375555,"hash":"17a907a6b347b170bc1d471b66f60ba17e6c9107"}
{"url":"https://developers.jup.ag/docs/guides/how-to-get-token-information","domain":"developers.jup.ag","title":"How to Get Token Information on Solana - Jupiter Developers","text":"​TL;DR\nJupiter’s Tokens API is the most widely used token data source on Solana. Search any token by name, symbol, or mint address and get metadata, verification status, organic score, and trading stats. Used by Phantom, Solflare, and most Solana apps.\nBase URL: https://api.jup.ag\nVideo walkthrough + source code: Watch the video walkthrough and grab the demo app source code on GitHub.\n\n​Prerequisites\n\nGet an API key at Portal\nAll requests require the x-api-key header\n\n​Quick start\ncurl -X GET \"https://api.jup.ag/tokens/v2/search?query=JUP\" \\\n -H \"x-api-key: YOUR_API_KEY\"\n\nResponse (array of matching tokens):\n[\n {\n \"id\": \"JUPyiwrYJFskUPiHa7hkeR8VUtAeFoSYbKedZNsDvCN\",\n \"name\": \"Jupiter\",\n \"symbol\": \"JUP\",\n \"icon\": \"https://static.jup.ag/jup/icon.png\",\n \"decimals\": 6,\n \"isVerified\": true,\n \"organicScore\": 98.08,\n \"organicScoreLabel\": \"high\",\n \"usdPrice\": 0.1424,\n \"mcap\": 461995714.68,\n \"holderCount\": 857247,\n \"tags\": [\"verified\", \"community\", \"strict\"]\n }\n]\n\n​When you need this\nYou’re building something that needs Solana token data:\n\nWallet — Display token names, symbols, icons\nTrading interface — Token search, verification badges\nPortfolio tracker — Metadata, holder count, market cap\nAnalytics dashboard — Trading volume, organic score, liquidity\nTrading bot — Filter tokens by metrics, find new listings\n\nCommon searches that lead here:\n\n“solana token metadata api”\n“get token logo solana”\n“token verification solana”\n“trending tokens solana api”\n\n​Why Jupiter\nJupiter maintains the most comprehensive token database on Solana:\n\n580k+ tokens indexed with metadata\nVerification system trusted by major Solana wallets\nOrganic Score distinguishes real trading from wash trading\nReal-time stats across 5m, 1h, 6h, 24h windows\n\nThe same data powers jup.ag and is used by Phantom, Solflare, and most Solana apps.\n\n​API Reference\nBase URL: https://api.jup.ag\nEndpointDescriptionGET /tokens/v2/search?query={query}Search by mint, symbol, or nameGET /tokens/v2/tag?query={tag}Get tokens by tag (verified, lst)GET /tokens/v2/{category}/{interval}Get trending/top tokensGET /tokens/v2/recentGet recently listed tokens\n\n​Code examples\n​Search by mint, symbol, or name\ncurl -X GET \"https://api.jup.ag/tokens/v2/search?query=JUP\" \\\n -H \"x-api-key: YOUR_API_KEY\"\nconst response = await fetch(\n 'https://api.jup.ag/tokens/v2/search?query=JUP',\n {\n headers: {\n 'x-api-key': 'YOUR_API_KEY'\n }\n }\n);\n\nif (!response.ok) {\n throw new Error(`HTTP ${response.status}: ${response.statusText}`);\n}\n\nconst tokens = await response.json();\nimport requests\n\nresponse = requests.get(\n 'https://api.jup.ag/tokens/v2/search',\n params={'query': 'JUP'},\n headers={'x-api-key': 'YOUR_API_KEY'}\n)\nresponse.raise_for_status()\ntokens = response.json()\n\nQuery options:\n\nMint address: So11111111111111111111111111111111111111112\nSymbol: SOL, JUP, USDC\nName: Jupiter, Wrapped SOL\nMultiple (comma-separated): SOL,JUP,USDC (max 100)\n\n​Get all verified tokens\ncurl -X GET \"https://api.jup.ag/tokens/v2/tag?query=verified\" \\\n -H \"x-api-key: YOUR_API_KEY\"\nconst response = await fetch(\n 'https://api.jup.ag/tokens/v2/tag?query=verified',\n {\n headers: { 'x-api-key': 'YOUR_API_KEY' }\n }\n);\nconst verifiedTokens = await response.json();\n\nAvailable tags: verified, lst (liquid staking tokens)\n​Get trending tokens\ncurl -X GET \"https://api.jup.ag/tokens/v2/toptrending/1h?limit=50\" \\\n -H \"x-api-key: YOUR_API_KEY\"\nconst response = await fetch(\n 'https://api.jup.ag/tokens/v2/toptrending/1h?limit=50',\n {\n headers: { 'x-api-key': 'YOUR_API_KEY' }\n }\n);\nconst trending = await response.json();\n\nCategories:\n\ntoptrending — Most price movement\ntoptraded — Highest volume\ntoporganicscore — Highest organic (real) activity\n\nIntervals: 5m, 1h, 6h, 24h\n​Get recently listed tokens\ncurl -X GET \"https://api.jup.ag/tokens/v2/recent\" \\\n -H \"x-api-key: YOUR_API_KEY\"\n\nReturns tokens ordered by first pool creation time (not mint time).\n\n​Response format\n​TypeScript types\ninterface TokenInfo {\n // Identity\n id: string; // Mint address\n name: string;\n symbol: string;\n icon: string | null; // Logo URL\n decimals: number;\n tokenProgram: string; // SPL Token or Token-2022 program address\n createdAt: string; // Token creation timestamp\n\n // Social (optional, varies per token)\n twitter?: string;\n website?: string;\n discord?: string;\n instagram?: string;\n tiktok?: string;\n otherUrl?: string;\n dev?: string; // Developer wallet address\n\n // Supply\n circSupply: number | null;\n totalSupply: number | null;\n\n // Market data\n fdv: number | null; // Fully diluted valuation\n mcap: number | null; // Market cap in USD\n usdPrice: number | null;\n priceBlockId: number | null; // Solana block for price recency\n liquidity: number | null; // Total liquidity in USD\n holderCount: number | null;\n apy?: { jupEarn: number }; // APY from Jupiter Lend's Earn (only present for listed assets)\n\n // Quality & verification\n organicScore: number; // 0-100\n organicScoreLabel: 'high' | 'medium' | 'low';\n isVerified: boolean | null;\n tags: string[] | null; // e.g., [\"verified\", \"community\", \"strict\"]\n\n // Audit (all fields conditional — present based on token characteristics)\n audit: {\n isSus?: boolean; // Flagged as suspicious (only present when true)\n mintAuthorityDisabled?: boolean;\n freezeAuthorityDisabled?: boolean;\n topHoldersPercentage?: number; // % held by top holders\n devBalancePercentage?: number; // % held by developer\n devMints?: number; // Number of developer mints\n } | null;\n\n // Launch info (conditional)\n firstPool?: { id: string; createdAt: string } | null;\n\n // Trading stats (each window has the same shape)\n stats5m?: SwapStats | null;\n stats1h?: SwapStats | null;\n stats6h?: SwapStats | null;\n stats24h?: SwapStats | null;\n updatedAt: string; // Last data update timestamp\n}\n\ninterface SwapStats {\n priceChange?: number; // Percentage\n holderChange?: number;\n liquidityChange?: number;\n volumeChange?: number;\n buyVolume?: number;\n sellVolume?: number;\n buyOrganicVolume?: number;\n sellOrganicVolume?: number;\n numBuys?: number;\n numSells?: number;\n numTraders?: number;\n numOrganicBuyers?: number;\n numNetBuyers?: number;\n}\n\n​Example response\n{\n \"id\": \"JUPyiwrYJFskUPiHa7hkeR8VUtAeFoSYbKedZNsDvCN\",\n \"name\": \"Jupiter\",\n \"symbol\": \"JUP\",\n \"icon\": \"https://static.jup.ag/jup/icon.png\",\n \"decimals\": 6,\n \"twitter\": \"https://twitter.com/JupiterExchange\",\n \"website\": \"https://jup.ag\",\n \"dev\": \"JUPhop9E8ZfdJ5FNHhxQt4uAih822Vs4QpqsWcewFbq\",\n \"circSupply\": 3243891294.88,\n \"totalSupply\": 6863982654.38,\n \"tokenProgram\": \"TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA\",\n \"firstPool\": {\n \"id\": \"2pspvjWWaf3dNgt3jsgSzFCNvMGPb7t8FrEYvLGjvcCe\",\n \"createdAt\": \"2024-01-29T17:33:29Z\"\n },\n \"holderCount\": 857247,\n \"audit\": {\n \"mintAuthorityDisabled\": true,\n \"freezeAuthorityDisabled\": true,\n \"topHoldersPercentage\": 15.45\n },\n \"organicScore\": 98.08,\n \"organicScoreLabel\": \"high\",\n \"isVerified\": true,\n \"tags\": [\"birdeye-trending\", \"community\", \"strict\", \"verified\"],\n \"createdAt\": \"2024-06-07T10:56:42.584Z\",\n \"fdv\": 977569925.64,\n \"mcap\": 461995714.68,\n \"usdPrice\": 0.1424,\n \"priceBlockId\": 402109205,\n \"liquidity\": 3002636.41,\n \"stats24h\": {\n \"priceChange\": -7.82,\n \"holderChange\": -0.03,\n \"liquidityChange\": -7.09,\n \"volumeChange\": 29.09,\n \"buyVolume\": 1811347.33,\n \"sellVolume\": 1997486.55,\n \"buyOrganicVolume\": 173368.01,\n \"sellOrganicVolume\": 611999.99,\n \"numBuys\": 34025,\n \"numSells\": 31278,\n \"numTraders\": 5200,\n \"numOrganicBuyers\": 291,\n \"numNetBuyers\": 1201\n },\n \"updatedAt\": \"2026-02-23T03:54:14.460Z\"\n}\n\n​Error responses\nToken not found:\n[]\n\nInvalid API key (401):\n{\n \"code\": 401,\n \"message\": \"Unauthorized\"\n}\n\nRate limited (429):\n{\n \"message\": \"Rate limit exceeded\"\n}\n\n​Evaluating token safety\nUse these fields to assess risk:\nFieldSafeRiskyisVerifiedtruefalseorganicScoreLabel\"high\"\"low\"audit.mintAuthorityDisabledtruefalse (can mint more)audit.freezeAuthorityDisabledtruefalse (can freeze)audit.isSusabsent (not flagged)true (flagged)audit.topHoldersPercentageLow (e.g., < 20%)High concentrationaudit.devBalancePercentageLowHigh (dev holds large supply)\nNote: audit fields are conditional. isSus is only present when the token is flagged as suspicious — not all risky tokens will have this flag.\n\n​Common questions\nHow do I get a token's logo?The icon field contains a URL to the token’s logo image. Always verify the URL is from a trusted domain before displaying.What does organic score mean?Organic score (0-100) measures real trading activity vs wash trading. Higher = more legitimate trading. See Organic Score docs for methodology.How often is data updated?Token metadata updates continuously. Trading stats (stats5m, stats1h, etc.) reflect real-time market activity.Why is a token returning empty?The token either doesn’t exist or hasn’t had a pool created yet. Use the mint address directly to verify.\n\nNeed token prices too? Once you have the token mint address, get its current USD price with the Price API.\n\n​Next steps\n\nTokens API Reference — Full endpoint schemas\nOrganic Score — Scoring methodology\nGet Token Prices — USD prices for tokens\nPortal — Get your API key\nJupiter Dev Notifications — API updates and announcements\nWas this page helpful?","tokens":2282,"squid":"spider-02","role":"Liquidity Spider","at":1791346387183,"hash":"65f3f9b366723272556ac9a4c9e37e16048a267e"}
{"url":"https://ethresear.ch/t/properties-of-issuance-level-consensus-incentives-and-variability-across-potential-reward-curves/18448","domain":"ethresear.ch","title":"Properties of issuance level: consensus incentives and variability across potential reward curves - Economics - Ethereum Research","text":"Properties of issuance level: consensus incentives and variability across potential reward curves \n\n Economics\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 33\n min\n\n Jan 2024\n\n 1 / 12\n\n Jan 2024\n\n Jul 2024\n\n post by aelowsson on Jan 24, 2024\n\n aelowsson\n\n Properties of issuance level: consensus incentives and variability across potential reward curves\nBy Anders Elowsson\nThanks to Barnabé Monnot, Francesco D’Amato, Caspar Schwarz-Schilling, Thomas Thiery, Davide Crapis, Julian Ma, Vitalik Buterin, Justin Drake and Ansgar Dietrichs for review and/or fruitful discussions. Thanks also to Flashbots for providing the data used in the analysis.\nThis post is also available in a more compact format as a thread, but Section 5 offers several additions.\n\n1. Introduction\n1.1 Background\nEthereum’s stakers started to receive execution layer rewards with The Merge and liquidity improved when withdrawals were enabled with Shapella. Both upgrades have served to push up the equilibrium quantity of stake. The resulting increase in gossip messaging and to the Beacon state size puts strain on the consensus layer. An increase in staking deposits is furthermore associated with an increase in issuance of new tokens under the current reward curve, bringing an inflationary pressure on regular users who rely on ETH. Ethereum issues ETH to stakers to incentivize them to stake and secure the blockchain. But raising the issuance level if no further stake is needed—and even degrades both the consensus network and economics—is arguably not beneficial. The amount of stake that Ethereum needs to remain secure is a subject of active research and discussion, where many developers now argue that it is reasonable to moderate the growth. In preparation for such an effort, this post will analyze the effect of issuance level on consensus incentives and reward variability across potential reward curves.\n1.2 Security and deposit size\nThe relationship between the staking deposit size D𝐷 and Ethereum’s security level is not trivial to characterize. On the one hand, we may focus on the value slashed in an attack. Since one million (M) ETH is worth around 2.2 billion dollars today, the cost of attacking Ethereum using some critical proportion of D𝐷 (which is currently 29M ETH), becomes very high under the threat of slashing. But a higher deposit size also provides Sybil resistance to more subtle forms of degradation to the consensus mechanism that may not immediately lead to slashing (e.g., short reorgs). Notably, the 14M ETH securing Ethereum at The Merge was found sufficiently secure by the ecosystem at the time, in a way acting as a “revealed preference” under those prevailing circumstances. In any case, there comes a point where the marginal increase in security from adding another validator brings less utility than the utility loss to users. A level of D=2^{25}𝐷 =225 ETH (33.6M ETH) has been used as a reference point of when network conditions (and economics) start to degrade. Drake expanded on his reasons for supporting a target of 30M ETH in a recent AMA. This active area of research is related to the concept of “minimum viable issuance”.\n1.3 Minimum viable issuance\nAn ideal deposit size will satisfy minimum viable issuance, the idea that Ethereum should not issue more tokens than what is strictly needed for security. Excessive issuance—which is always an inflation tax on users—forces everyone to expend resources staking, or to face a principal–agent problem as a delegating staker, lest they want their ETH savings eroded. This degrades utility in aggregate. Staking income is also taxed in many jurisdictions, whereas circulating supply deflation is not. From a macro perspective, Ethereum avoids a scenario where a staking service provider (SSP) can come to dominate not only in terms of staked ETH under its control, but also in terms of the total circulating supply, making its issued liquid staking token (LST) a novel stratum for cartelization. A concern is that a majority of Ethereum’s users will be economically entangled with one or a few for-profit SSPs through its issued LST. In the case of a mistake or misdeed by the SSP, Ethereum’s social layer may then waver on its commitment to the underlying intended consensus process. It is arguably preferable to see Ethereum’s native token permeate and bind together the extended ecosystem (including rollups) instead of a derivative of it.\n1.4 Consensus incentives\nEthereum’s consensus mechanism relies on a collection of micro incentives to ensure that validators perform their tasks correctly. The attester is rewarded for voting on a correct source and target checkpoint for Casper FFG, as well as the head block within LMD-GHOST. A missing/late or incorrect Casper FFG vote instead results in a penalty. The proposer attains 1/7 of the rewards given to attesters for including the attestations in the proposed block. The magnitudes of these micro incentives (including penalties) are ultimately regulated by the issuance level. This differs from the MEV and priority fees that the proposer also receives, which are unrelated to issuance policy. An equilibrium enforced through a reduction in issuance can unbalance the economic forces, rendering the micro incentives ineffective. Solo stakers would also be negatively affected by the increase in reward variability. Maintaining correct incentives as the issuance level and deposit size change is important.\n1.5 Purpose and main questions\nTo what extent can Ethereum stop issuing more tokens than what is needed for security? Can we reduce issuance while still retaining consensus stability, proper incentives, and acceptable conditions for solo staking? Can we adopt a reward curve that lets the issuance yield go negative past some specific staking deposit size D𝐷, or target some specific desirable D𝐷 by simply adapting the yield to enforce it? Otherwise, should a more moderate approach be adopted? This post will take a closer look at these questions and review features of staking economics that affect consensus incentives and reward variability—including how they vary across deposit size. The analysis shows the benefit of a moderately falling issuance as the deposit size rises above target levels, with relevant candidate reward curves evaluated in Section 5.\n2. Equilibrium staking\n2.1 Supply and demand\nThe base reward factor F𝐹 is the parameter that directly adjusts the issuance level under the current reward curve, affecting all consensus rewards and penalties. Ethereum provides an issuance yield under idealized performance of y_i = \\frac{cF}{\\sqrt{D}}𝑦𝑖 =𝑐𝐹√𝐷, where F=64𝐹 =64 and the constant c\\approx2.6𝑐 ≈2.6. The total yield provided by the protocol to stakers implies its demand for stake and it is\n\n\\begin{equation}\ny=y_i+y_v, \n\\end{equation}\n𝑦=𝑦𝑖+𝑦𝑣,\nwhere y_v𝑦𝑣 is the yield from realized extractable value (REV). The REV is the value that stakers receive from priority fees and MEV after builders take their cut. Define the yearly aggregate REV as V𝑉 (currently around 300k ETH). The expected yield from REV then becomes y_v=V/D𝑦𝑣 =𝑉/𝐷. Going forward, the post will sometimes use overline when referring specifically to the demand curve, if needed for clarity (thus \\overline{y}=y_i+y_v――𝑦 =𝑦𝑖 +𝑦𝑣), and underline \\underline{y}𝑦―― for the supply curve.\nNote that the demand curve formed through \\overline{y}――𝑦 is the “endogenous yield” derived exclusively from staked participation in the consensus process. The yield from DeFi (including “restaking”) that is exogenous to staking y_c𝑦𝑐, is not part of \\overline{y}――𝑦; it can under competitive equilibrium also be derived by non-stakers. It is convenient to separate \\overline{y}――𝑦 and y_c𝑦𝑐 in the analysis, to properly model what happens as \\overline{y}――𝑦 falls towards zero. At that point, there will be no point in staking. Any yield derived outside of the consensus mechanism from staked ETH will also be possible to derive via non-staked ETH. For example, it will be better to “restake” WETH. Any DeFi service that fails to serve non-staked ETH will be outcompeted. This means that Ethereum must always offer a positive endogenous yield \\overline{y}――𝑦. This is a nice assurance to Ethereum’s stakers. This post will go a step further, and ascertain that y_i𝑦𝑖 specifically also must be kept well above zero under the current version of the consensus mechanism (as an aside, if the REV is burned, y_i𝑦𝑖 will also remain above 0, since there once again will be no point in staking if y_i=0𝑦𝑖 =0).\nGenerally, y_c𝑦𝑐 should be higher for non-stakers than stakers, because collateral that cannot simply evaporate is more reliable and valuable. Contemplate for example the effect that a majority client bug could have on an actively validated service collateralized solely by staked ETH. However, y_c𝑦𝑐 can still incentivize users to supply stake at a lower staking yield, as long as the staking yield more than compensates for the staked ETH’s degradation as collateral. For example, say that an agent is willing to own and lock up ETH if the total acquired yield (including y_c𝑦𝑐) is over 0.04 (disregarding costs/risks for simplicity). Define y_c'𝑦′𝑐 as the yield from collateralizing non-staked ETH. If y+y_c > 0.04𝑦 +𝑦𝑐 >0.04 and y+y_c > y_c'𝑦 +𝑦𝑐 >𝑦′𝑐, the agent will decide to stake ETH. Thus, if y_c = 0.01𝑦𝑐 =0.01 and y_c'=0.02𝑦′𝑐 =0.02, the requirement is y> 0.03𝑦 >0.03 for the agent to stake. But if y_c = 0.02𝑦𝑐 =0.02 and y_c'=0.03𝑦′𝑐 =0.03 the requirement is only y> 0.02𝑦 >0.02.\nThe shape of the supply curve is unknown and affected by many variables. Plots will be provided in this post covering a broader range so that different assumptions can be mapped to various outcomes. As a guideline, two supply curves will be included in the plots. The equation used for the (inverse) supply curve is\n\n\\begin{equation}\n\\underline{y}=c_1d^k + \\frac{c_2d}{1-d},\n\\end{equation}\n𝑦――=𝑐1𝑑𝑘+𝑐2𝑑1−𝑑,\nusing the deposit ratio d𝑑 (the fraction of the around 120M circulating ETH that is staked), with k=1/2𝑘 =1/2, c_2=0.003𝑐2 =0.003. The first term c_1d^{1/2}𝑐1𝑑1/2 gives the curves a yield elasticity of supply of around 2 in the middle range. The term \\frac{c_2d}{1-d}𝑐2𝑑1−𝑑 captures the notion that the final fraction of the circulating supply may not be staked in the medium run until the yield becomes very high. The opposite, a downward-sloping supply curve due to network effects of LSTs, seems a bit far-fetched. The variable c_1𝑐1 is set so that \\underline{y}𝑦―― reaches some specific deposit size at some plausible yield. In this post, the two curves were set to reach D=𝐷 = 25M at y=0.025𝑦 =0.025 and y=0.02𝑦 =0.02 respectively. The upper curve could for example represent the supply curve underpinning an equilibrium within a year or two, whereas the lower curve could be the supply curve after a few years of improvements to the the staking experience and better financial integrations.\nThis post tracks supply and demand across D𝐷 (specifically, it does not track the circulating supply and its effect on d𝑑), which means that it deals with medium-run staking equilibria. The long-run staking equilibrium under reward curves that adapt to D𝐷 is ultimately also influenced by the circulating supply equilibrium, since the circulating supply will drift to balance supply, demand, and protocol income.\n2.2 Influence of F𝐹 on the equilibrium\nFigure 1 plots a hypothetical medium-run equilibrium staking. The colormap and y-axis both capture y𝑦, with the colormap restricted to F \\in [0, 75]𝐹 ∈[0,75]. At equilibrium, the demand curve will intersect the supply curve. Hypothetical equilibria under the current issuance policy (F=64𝐹 =64) at the prevailing level of REV are indicated by blue circles. The hypothetical equilibria if issuance is halved (F=32𝐹 =32) are indicated by blue squares. Such a reduction brings the deposit size closer to a previously suggested desirable range in between the dashed blue lines. The left dashed blue line indicates 14M ETH and the right dashed line indicates 33.6M ETH.\nFigure 11945×1261 254 KB\nFigure 1. Medium-run staking equilibrium between the supply of stake (blue hypothetical supply curves) and demand for stake (white reward curves at various settings for F𝐹 under the current level of REV). The y-axis represents staking yield and the x-axis deposited stake. It has been suggested that Ethereum should strive for an equilibrium between the vertical dashed blue lines indicated by arrows.\nIt is not possible to ascertain the exact effect of a reduction in F𝐹, but we can be rather certain that the yield elasticity of supply for the medium run is not 0 (a vertical supply curve). Reducing F𝐹 will therefore always reduce the quantity of stake, ceteris paribus. Figure 2 shows that the full reduction in yield from a change in F𝐹 (white downwards arrow) will not remain at the new equilibrium, because some stakers will presumably leave (blue leftwards arrow), bringing the yield for remaining stakers back up a bit (white leftwards arrow).\nFigure 21945×1261 239 KB\nFigure 2. Hypothetical effect of a reduction to F𝐹 from 64 to 32. The equilibrium yield initially falls from 2.95 % to 1.77 %, but then comes back up to 2.34 % as some stakers leave. Around half of the initially lost yield is thus recouped with this supply and demand curve.\nHow will this dynamic affect the solo staker and delegating staker? The outcome over shorter time horizons will depend on variations in cost structures and frictions affecting the decision to stake or de-stake. A solo staker who will not buy new hardware at some low yield may still stake over the lifetime of their current hardware. Delegating stakers dissatisfied with the yield may keep their savings in the LST until the next time they wish to spend their money, or leave directly. Solo stakers’ upfront costs and illiquidity presumably give them a lower yield elasticity of supply in the short run. This is comforting, because a temporarily lower-than-equilibrium yield (if F𝐹 is reduced in a hard fork) may not push them out forever.\nIt seems likely that the supply curve will gradually shift downwards over time as the staking experience simplifies and DeFi integrations improve. The outlined dynamic in Figure 2 may therefore not fully materialize, as a lowering supply curve can nullify any de-staking process. The equilibrium quantity of stake will however still be lower with a reduction in F𝐹 than if F𝐹 is kept fixed. We must evaluate each possible outcome at the medium-run equilibrium. The effect of a gradually lowering supply curve is a gradually increasing deposit size.\nFigure 3 has F𝐹 on the y-axis (thus essentially the demand curve) instead of yield. You may think of it as dragging down and straightening the bent colormap in Figure 1 such that it becomes a rectangle. The colors encode the same yield as previously (also indicated by black lines). This viewpoint is convenient as the post now further explores the effect of a change to the issuance level. Both alternative graphs will often be provided to the reader and the same two supply curves indicated as guidelines.\nFigure 31908×1261 291 KB\nFigure 3. The same staking equilibrium as in Figure 1, but this time with the base reward factor F𝐹 (regulating the demand curve) on the y-axis. The colormap still encodes staking yield.\n3. Consensus incentives\nWhen contemplating a change to the issuance policy, it is important to consider the effects on consensus stability, in particular how incentives may change for different consensus roles that validators will be assigned to. Figure 4 shows the proportion of the yield stemming from issuance at various settings for any specific base reward factor F𝐹. Naturally, the lower F𝐹 is set, the lower the proportion of rewards that come from issuance. Right now at the prevailing level of REV, more than 2/3 of the yield comes from issuance. Since y_v𝑦𝑣 falls by the reciprocal of D𝐷, whereas y_i𝑦𝑖 falls by the reciprocal of \\sqrt{D}√𝐷 under the current reward curve, a higher proportion of the yield will stem from issuance at a higher D𝐷.\nFigure 41883×1243 265 KB\nFigure 4. The proportion of staking yield derived from issuance (as opposed to REV), with F𝐹 on the y-axis and D𝐷 on the x-axis.\nFigure 5 instead shows the yield that comes from attester duties (y_a𝑦𝑎) in proportion to all staking yield y_a/y𝑦𝑎/𝑦 (note that the measure thus incorporates the small yield from sync-committtee attestations in y_a𝑦𝑎, although these attestations functionally differ somewhat). Since the proposer gets 1/8 of the issued rewards, the reported proportion in y_a/y𝑦𝑎/𝑦 is lower than in y_i/y𝑦𝑖/𝑦. If F𝐹 is reduced to 32, almost half the rewards will come from the sparse chances of proposing a block. There is no well-defined proportion of y𝑦 that must be provided for attester duties, but higher is generally better. This post will use y_a/y>1/2𝑦𝑎/𝑦 >1/2 as a guideline of a more healthy situation, y_a/y<1/3𝑦𝑎/𝑦 <1/3 as unhealthy, and y_a/y<1/4𝑦𝑎/𝑦 <1/4 as an outcome to be avoided. These guidelines are rather arbitrary, and a good subject for further research.\nFigure 51883×1243 356 KB\nFigure 5. The proportion of staking yield derived from accurately performing attester duties (as opposed to proposer duties), with F𝐹 on the y-axis and D𝐷 on the x-axis.\nWhen y_i/y𝑦𝑖/𝑦 and y_a/y𝑦𝑎/𝑦 fall too low, the consensus mechanism breaks down. Consensus rewards and penalties stop providing correct incentives for stakers. Honest attestation is less compelling. The only thing that matters is to collect REV and to not get slashed. Ignoring attester duties comes at little to no cost as long as the inactivity leak is not triggered, and instigating reorgs will be more tempting. If REV rises relative to the proposer reward, timing games also become relatively more attractive.\nMoving back to having staking yield on the y-axis in Figure 6 gives another perspective on how various hypothetical changes to issuance policy may affect the proportion of rewards awarded for attestation. This time, the x-axis extends across the full circulating supply.\nFigure 61920×1261 150 KB\nFigure 6. The proportion of staking yield derived from accurately performing attester duties (as opposed to proposer duties), with y𝑦 on the y-axis and D𝐷 on the x-axis. The red curve represents a previously proposed reward curve, and the dashed red line is the implied reward curve of targeting a specific quantity of stake.\nIn red, we contemplate the various stricter issuance policies that can be attempted, and the adverse effects they may bring before MEV burn is in place. For example, to target D =\\,𝐷 = 24M ETH (dashed red line) while keeping y_a/y>0.5𝑦𝑎/𝑦 >0.5, the yield must be around 3 % (red square). This seems unreasonably high given that the supply curve slopes upwards. Therefore, to enforce D =\\,𝐷 = 24M ETH, an even lower proportion of rewards must be given for attester duties. Indeed, even if these duties are not given any issuance rewards at all, an equilibrium may still not be achieved. An equilibrium where the issuance yield is “negative” is manifested by the white region of the figure. This could be the only possible equilibrium if the supply curve over time drifts lower—which seems like a very reasonable assumption—or simply because of a not particularly unlikely rise in REV.\nThe same type of problem can be encountered when adopting a reward curve that goes negative to enforce a deposit size below some specific level. The red line indicates the reward curve previously suggested by Buterin. At many reasonable equilibria with such strict reward curves, the rewards for attester duties will be very low (red circles), or non-existent. The breakdown of the consensus mechanism is then complete.\nAs previously outlined, when D𝐷 rises, the white region representing y_v𝑦𝑣 becomes smaller and smaller. This happens because y_v𝑦𝑣 falls by the reciprocal with a rise in D𝐷. At 120M ETH staked, y_v𝑦𝑣 is just 0.25 %. A quadrupling of REV would only lead to y_v=0.01𝑦𝑣 =0.01 at 120M ETH staked, but to the rather imposing y_v=0.04𝑦𝑣 =0.04 at 30M ETH staked. The important notion to take away from this particular discussion is that the lower the deposit size that Ethereum tries to enforce a staking equilibrium at before MEV burn, the more influential REV is going to be.\nSome of the issues of a lower issuance here outlined can be remedied by taking out a staking fee each epoch and increasing the base reward correspondingly. To prevent consensus breakdown, the fee must be introduced already at positive yields, for example when y_a/y<0.5𝑦𝑎/𝑦 <0.5 or y_a/y<0.33𝑦𝑎/𝑦 <0.33. However, introducing a fee challenges long-standing tenets promoted to solo stakers (“you can go offline X % of the time and still break even”, etc.). Trying to push through these far-reaching changes when MEV burn eventually can make them obsolete therefore seems undesirable. Furthermore, a staking fee will not resolve other issues of a very low issuance, such as a rise in the relative and equilibrium variability in rewards for stakers that do not pool their MEV income.\n4. Variability in rewards for solo stakers\nThe variability in rewards is higher for solo stakers than delegating stakers under the current consensus mechanism, because delegating stakers can in a frictionless manner rely on pooling of rewards from a large number of validators. This affects solo stakers negatively. A change in issuance policy could further widen the gap in variability, and it is therefore necessary to model that. The most prominent research on reward variability has been done by Pintail, with analysis up until and just after The Merge. The reader is also encouraged to study writings on this matter by Edgington.\n4.1 Model\nThis post models variability for solo validators over one year in a rather simple fashion, with the distribution in proposer and sync-committee duties assigned according to the probabilities given from the consensus spec at each modeled deposit size. The focus is on the greatest source of variability, namely that of variation in REV. To this end, block proposers are assigned REV using sampling with replacement from the roughly 2.7 million block-level sample points provided by Flashbots. The probability density function (PDF) in Figure 7 of the REV in Ethereum shows a positive skew, with a mode of around 0.025. The mean of around 0.12, indicated by a dashed vertical line, is higher due to the occasional blocks with very high REV.\nFigure 71988×932 27.3 KB\nFigure 7. A PDF of Realized extractable value (REV) in 2.7 million blocks of Ethereum since The Merge.\nTo discern more details, the cumulative distribution function (CDF) is plotted in Figure 8 with a log-scaled x-axis and a logit-scaled y-axis. The median REV is around 0.045 ETH and less than 20 % of the slots are above the mean. The “median block” will thus still provide higher rewards for attesters than the proposer even as y_a/y=0.5𝑦𝑎/𝑦 =0.5. But the assertion in Section 3 is not specifically that all blocks provide the proposer with more value when y_a/y<0.5𝑦𝑎/𝑦 <0.5. Instead, it is rather that of generally misaligned incentives and systemic risk, which Ethereum is better off avoiding if possible.\nFigure 82113×1104 110 KB\nFigure 8. A CDF of Realized extractable value (REV) in 2.7 million blocks of Ethereum since The Merge. Note that the x-axis is log-scaled and the y-axis logit-scaled.\nBlocks have been missed with a probability of around 0.96 % since The Merge, a condition that is also included in the model. Missed sync-committee assignments are not precisely modeled and instead assigned to have the same probability as missed blocks. It is presumably a lot less common to fully miss the sync-committee assignment (which spans over more than a day), and much more likely to partially miss it, but modeling this exactly is beyond the scope of this post. Notably, blocks are to a higher proportion missed by solo stakers than professional stakers, something that further degrades conditions for solo stakers when y_i𝑦𝑖 is reduced relative to y_v𝑦𝑣. This specific feature is not included in the model. Finally, attesters are assumed to perform their duties correctly and are set to receive the full rewards (a slight overestimate). Variation in attestation accuracy will produce much less variability than selection for special duties such as block proposals, so it is less relevant to the analysis.\n4.2 Effect of pooling\nFigure 9 shows the influence of pooling on variability in staking yield at the current deposit size of D=𝐷 = 29M ETH, using CDFs of different pool sizes. Annualized validator rewards were simulated 30M times, sampling REV with replacement (s. w. r.). Pools were created from these distributions, also s. w. r. 30M times. As evident, variability is gradually reduced with more staked ETH (the curve becomes steeper). A solo staker running 2 or 5 validators can already reduce variance quite a bit; a small pool managing a couple of thousand ETH will still not be able to fully remove variance; etc.\nFigure 92082×1145 208 KB\nFigure 9. The influence of pooling on variability in staking yield at the current deposit size of D=𝐷 = 29M ETH, captured using CDFs of different pool sizes.\nAs illustrated in Figures 5-6, the proportion of attester rewards is around 0.5 at 29M ETH staked when F=32𝐹 =32. This retains proper consensus incentives according to the guidelines from Section 3. But it is perfectly reasonable to expect a higher quantity of stake under equilibrium at F=32𝐹 =32 and a staking fee would then be required to achieve an equilibrium, as previously discussed. An example of the effect of such a fee is shown in Figure 10, where the yield at 29M ETH is pushed down to 1.25 %, while keeping F=32𝐹 =32 to retain proper consensus incentives. A yield of 1.25 % is still within the green area of Figure 6, meaning that stakers have a positive expected y_i𝑦𝑖 (even when y_i𝑦𝑖 accounts for the fee, as in this post). However, a black vertical section of the solo staking CDF in Figure 10 indicates a negative yield over the year for solo stakers that do not get to propose a block or attest in the sync committee. This happens because the proposer gets 1/8 of all issuance rewards (and the sync-committee attester 1/32), and so non-selected stakers must still lose ETH every epoch even as y_i𝑦𝑖 is slightly above zero. Trying to push the yield into the white area of Figure 6 pushes a larger section of solo stakers underwater over a year. The notion of solo stakers being affected the worst by a low issuance yield is something that will be explored further in the following subsections. However, that analysis will not include a fee, instead focusing on the degradation that happens even without a fee.\nFigure 102082×1145 222 KB\nFigure 10. The influence of pooling on variability in staking yield at the current deposit size of D=𝐷 = 29M ETH, when applying a staking fee of 1.34 % to push down the expected staking yield to 1.25 %.\nTwo additional figures can be interesting, covering the situation under equilibrium with the current issuance policy and the two hypothetical supply curves. With the higher supply curve from previous plots, the equilibrium staking is around 41.9M ETH. Figure 11 shows the variability under such a deposit size, otherwise using the same conditions as previously. Average y𝑦 (indicated by a grey dashed line) falls at the equilibrium.\nFigure 112082×1145 204 KB\nFigure 11. The influence of pooling on variability in staking yield at a hypothetical equilibrium of D=𝐷 = 41.9M ETH, captured using CDFs of different pool sizes.\nWith the lower supply curve, the equilibrium is D=𝐷 = 50.4M ETH, as shown in Figure 12. The vertical part of the black line, representing solo stakers with no block or sync-committee assignments, is then rather noticeable.\nFigure 122082×1145 201 KB\nFigure 12. The influence of pooling on variability in staking yield at a hypothetical equilibrium of D=𝐷 = 50.4M ETH, captured using CDFs of different pool sizes.\n4.3 Variability with fixed supply and varied demand\nIt is now time to study how variability in yield changes for solo stakers when F𝐹 is changed (no fee). Figure 13 shows the equilibrium CDF under the lower supply curve (the expected yield is dashed). When F=0𝐹 =0, only REV remains, and stakers with no block proposals receive no rewards at all.\nFigure 132082×1145 218 KB\nFigure 13. Changes to solo staker yield variability under equilibrium for a fixed hypothetical supply curve when F𝐹 (demand) is changed.\nTo better illustrate the risk solo stakers take on in comparison with delegating stakers, all cumulative probability distributions were normalized by subtracting the average yield (“shift-normalized”), as shown in Figure 14. This preserves the standard deviation (SD) of each distribution. It is now easier to observe how a change to F𝐹 increases variability at the medium-run equilibrium. The effect is particularly prominent at F=0𝐹 =0, and also noticeable at F=16𝐹 =16. From F=32𝐹 =32 and above, the increase in variability relative to F=64𝐹 =64 is less significant.\nFigure 142082×1148 202 KB\nFigure 14. The CDFs from Figure 13, all shifted to have have 0 expected yield, better illustrating how variability changes.\nThe SD is illustrative when discussing how the shape of the distribution affects risks. But the SD (or variance) is insufficient for capturing the full impact of variability for the risk-averse staker. The higher-order moments of the distribution also matter. In particular, a positive skew is favorable. In this regard, Ethereum’s yield distribution is certainly better than its inverse, where there would be a small risk of losing everything (although the prospect of slashing indeed leads to such a risk). The worst-case scenario for honest and attentive stakers is thus an important feature.\nSolo stakers may in reality be worse affected at the same SD when the expected yield is lower. As a simplified example, say that solo stakers are some fixed proportion of all stakers at any deposit size when there is no variability in rewards, and that the supply curve rises linearly. Then, if the expected yield is 2 % and can vary uniformly between 1-3 %, half of the solo stakers would need to account for the risk of receiving a yield below their reservation yield over a year. If the expected yield is 5 % but can vary between 4-6 %, the proportion affected is 1/5. Figure 15 accounts for such relative effects, instead normalizing by dividing each distribution by the ratio between its mean and the mean at F=64𝐹 =64 (“scale-normalized”). This preserves the relative standard deviation (RSD) of the distribution, computed as SD/mean yield (mathematical notation: \\sigma/\\mu𝜎/𝜇). From such a perspective, variability for solo stakers certainly starts to degrade already around F=32𝐹 =32, and more so at F=16𝐹 =16. But this is just one viewpoint on the matter, both the SD and RSD convey something important about the solo stakers’ conditions.\nFigure 152082×1148 215 KB\nFigure 15. The CDFs from Figure 13, all “scale-normalized” (\\sigma/\\mu𝜎/𝜇) to have the same expected yield. This preserves the relative standard deviation.\n4.4 Variability with fixed demand and varied supply\nAnother interesting perspective is to vary D𝐷 while keeping the reward curve fixed, thus computing variability across demand. This allows us to study equilibrium distributions, where each one is the result of a different supply curve. From a consensus developer’s perspective, this is a very important viewpoint and will be the focus going forward in this post. It is easier to control the shape of the demand curve (particularly after MEV burn), as opposed to the supply curve. Figure 16 shows CDFs capturing yield variability for the current reward curve at various deposit sizes. At 110M ETH staked (black line) almost half the validators will neither propose blocks nor sync-attest over the year at equilibrium (vertical line segment). The impact of special duties at such a high deposit size is indeed interesting to note. Being selected to the sync-committee gives almost as much issuance yield as attesting correctly over the full year (78 %, regardless of reward curve). But an equilibrium at D=𝐷 = 110M ETH requires that the marginal staker has a reservation yield below 2% at the prevailing level of REV, which seems rather unlikely for the near future.\nFigure 162082×1145 204 KB\nFigure 16. Solo staker yield variability at various deposit sizes under the current issuance policy.\nStill, as implied by the shift-normalized distributions in Figure 17, the SD decreases with an increase in deposit size, keeping F𝐹 fixed. This happens because the higher frequency of selection for special duties at lower deposit sizes serves to differentiate validator outcomes. Also remember that the standard deviation is computed after first subtracting the mean.\nFigure 172082×1148 182 KB\nFigure 17. Solo staker yield variability at various deposit sizes under the current issuance policy, with CDFs shifted such that the expected yield is 0.\nWhen it comes to the RSD, it is kept relatively fixed across D𝐷 under the medium-run equilibrium, as indicated by the scale-normalized CDFs in Figure 18. This is opposed to the SD which is more or less fixed across F𝐹 at the same D𝐷.\nFigure 182082×1148 184 KB\nFigure 18. Solo staker yield variability at various deposit sizes under the current issuance policy as in Figure 16, but with CDFs scaled to have the same expected yield.\nIf F𝐹 is reduced to 32, the equilibrium deposit size will fall. Ignoring this, Figure 19 shows the distributions at the same fixed D𝐷 as previously. The yield at 110M ETH staked is then just above 1%, and the unlucky solo stakers with no assignment only receive around 0.7 %.\nFigure 192082×1145 199 KB\nFigure 19. Solo staker yield variability at various deposit sizes when F𝐹 is reduced to 32.\n4.5 Two-dimensional mappings of solo-rewards variability\nIt can be clarifying to map the previously investigated variabilities across two dimensions, to visualize how variability changes for solo stakers across the potential equilibria. The mappings in this subsection were done by simulating solo staker’s yearly yield 10M times (sampling REV with replacement), repeated across 10^5105 different deposit sizes and 32 different settings for F𝐹. The experiment was then repeated 10 times, and the measurements combined by taking the average variances. This setup was used for handling memory load since the final matrix is computed from 320 trillion simulated solo staking outcomes. Smoothing was applied across variance and mean, using a Hann window of width 1101 (across D𝐷) and height 5 (across F𝐹). The matrix was initially computed across a wider range than plotted to allow for such smoothing without artifacts. Finally, the matrix was upsampled across F𝐹.\nFigure 20 shows how the SD varies across D𝐷 (all the way up to 120M ETH) and F𝐹. A lower SD is better. The base reward factor has but a minuscule effect on the SD at any specific deposit size, because issuance level shifts the yield rather equally for everyone.\nFigure 201908×1243 146 KB\nFigure 20. Standard variation in yield over a year of solo staking, plotted across F𝐹 and D𝐷.\nThe same outcome can be observed with staking yield on the y-axis in Figure 21. To produce this graphical representation, the simulated outcome from the previous plot was simply interpolated onto the new axes. One supply curve is dashed for easier connection to the next plot.\nFigure 211945×1261 269 KB\nFigure 21. Standard variation in yield over a year of solo staking, plotted across y𝑦 and D𝐷.\nSince the quantity of stake supplied increases with a higher yield, the reality is that a higher F𝐹 will produce a lower standard deviation in rewards under equilibrium. Figure 22 captures the equilibrium SD across F𝐹 for the two modeled supply curves (equilibria for the lower are dashed). Thus under these assumptions, lowering F𝐹 will indeed increase the equilibrium variability for solo staker while MEV burn is not in place. But the increase at 48 or even 32 is rather modest.\nFigure 222026×1009 73.3 KB\nFigure 22. The equilibrium standard deviation in yield over a year of solo staking, which changes with a change to F𝐹.\nRecall that another interesting perspective is the relative standard deviation (RSD), which captures the notion that a high standard deviation can be worse at a lower yield than at a higher yield. The RSD is depicted across F𝐹 and D𝐷 (lower is better) in Figure 23.\nFigure 231870×1243 237 KB\nFigure 23. Relative standard variation in yield over a year of solo staking across F𝐹 and D𝐷.\nFigure 24 instead captures the RSD across y𝑦 and D𝐷. When going by the RSD, a higher F𝐹 is clearly preferable, because it serves to push up yield in general, thus facilitating a higher equilibrium yield and lower RSD.\nFigure 241908×1261 131 KB\nFigure 24. Relative standard variation in yield over a year of solo staking, plotted across y𝑦 and D𝐷.\nArguably, the SD puts too much emphasis on variabilty and the RSD puts too much emphasis on the mean. Therefore, some measure in between these two seems appropriate for further modeling. Define the SSD as the standard deviation divided by the square root of the mean (\\sigma/\\sqrt{\\mu}𝜎/√𝜇). Lower is still better. The post will use this in-between measure as a guideline for mapping relative degradation for solo stakers across various reward curves. Figures 25-26 plot the SSD. Under the combined measure, if F𝐹 is kept fixed, a staking equilibrium at a higher D𝐷 gives a lower SSD. To make the issuance policy more “neutral” the reward curve can be designed to produce the same SSD under any supply curve.\nFigure 251908×1243 361 KB\nFigure 25. The SSD (\\sigma/\\sqrt{\\mu}𝜎/√𝜇), capturing variability in yield over a year of solo staking across F𝐹 and D𝐷 (lower is better).\nFigure 261920×1245 131 KB\nFigure 26. The SSD (\\sigma/\\sqrt{\\mu}𝜎/√𝜇), capturing variability in yield over a year of solo staking across y𝑦 and D𝐷.\n5. Towards a utility-maximizing reward curve\n5.1 A neutral reward curve\nHow then can a more “neutral” issuance policy, specifically a more neutral reward curve be constructed? Figure 27 plots the SSD across the reward curves with F=32𝐹 =32 and F=64𝐹 =64. In orange is a more neutral reward curve, preserving a set SSD at any equilibrium.\nFigure 272101×1397 139 KB\nFigure 27. Variation in SSD across D𝐷 for the current reward curve (black), the current reward curve but with F=32𝐹 =32 (dark green), and a reward curve that is more “neutral” with regard to the SSD (orange).\nThis reward curve is also neutral across D𝐷 concerning the proportion or rewards awarded to attesters, as shown in Figure 28 in the familiar plot against the attester proportion with y𝑦 and D𝐷 on the axes. It ensures that attestations will bring in around half of the yield at any deposit size.\nFigure 281920×1261 152 KB\nFigure 28. The proportion of staking yield derived from accurately performing attester duties (as opposed to proposer duties), with y𝑦 on the y-axis and D𝐷 on the x-axis (see also Figure 6). The neutral reward curve in orange retains y_a/y=0.5𝑦𝑎/𝑦 =0.5 across almost the full range.\nThe equation for the reward curve is\n\n\\begin{equation}\ny_i=\\frac{cF}{\\sqrt{D}+kD},\n\\end{equation}\n𝑦𝑖=𝑐𝐹√𝐷+𝑘𝐷,\nwith F=10^2𝐹 =102 and k=2^{-11}𝑘 =2−11. The difference to the current reward curve y_i=\\frac{cF}{\\sqrt{D}}𝑦𝑖 =𝑐𝐹√𝐷 is thus the addition of kD𝑘𝐷 in the denominator and a change to F𝐹. Yearly issuance Y_i𝑌𝑖 is y_i𝑦𝑖 distributed across D𝐷. The equation for issuance thus becomes\n\n\\begin{equation}\nY_i=\\frac{cF}{\\sqrt{D}+kD}D = \\frac{cF}{D^{-0.5}+k}. \n\\end{equation}\n𝑌𝑖=𝑐𝐹√𝐷+𝑘𝐷𝐷=𝑐𝐹𝐷−0.5+𝑘.\nThis makes it clear that the reward curve is in essence a log-logistic CDF, providing an issuance level asymptotically approaching cF/k𝑐𝐹/𝑘, as shown in Figure 29 that plots the yearly distributed rewards Y𝑌.\nFigure 292149×1261 157 KB\nFigure 29. Yearly distributed rewards Y𝑌 to stakers, with a reward curve that asymptotically approaches a fixed issuance level in orange.\nIn the associated thread, a functionally very similar log-logistic CDF was presented for the neutral reward curve: Y_i = \\frac{2^{19}\\sqrt{D}}{2^{13}+\\sqrt{D}}𝑌𝑖 =219√𝐷213+√𝐷 (i.e., Y_i = \\frac{2^{6}}{D^{-0.5}+2^{-13}}𝑌𝑖 =26𝐷−0.5+2−13). In this post, all new reward curves are instead presented in the same format as the current reward curve. The purpose is to introduce as little friction as possible to the mental models around what is changed when it comes to the reward curve, and how the different presented alternatives (including the current) relate to each other. This also minimizes the required changes to the Ethereum proof of stake consensus specification (“spec”). The variable c𝑐 emerges as rewards are distributed across the year. If not included, another variable must be introduced in the spec to compensate. Given the fixed constants of the spec, the relevant “base reward per increment” r_b𝑟𝑏 will be r_b=\\frac{\\sqrt{10^9}F}{\\sqrt{D}+x}𝑟𝑏 =√109𝐹√𝐷+𝑥, where x=kD𝑥 =𝑘𝐷 in the first example (this equation does not account for integer arithmetics and the actual constants and operations to be applied). Various alternative examples will now be shown that alter x𝑥 and sometimes F𝐹.\n5.2 Exploration of alternative reward curves\nThe orange curve achieves some form of neutrality in terms of variability and consensus balance. It implies that Ethereum should sacrifice the same level of utility degradation in these features whatever the deposit size is. But such neutrality may not actually be desirable. Some consensus imbalance or reward variability could be acceptable to temper the deposit size if it rises very high, since a high deposit size brings utility degradation in and by itself. Furthermore, providing some safety margin at a moderate deposit size may be preferable. Table 1 explores alternative reward curves, providing a few examples using the same format as previously specified. The reward curves have been divided into various types that describe the exponentiation of D𝐷 in the added term x𝑥 of the denominator.\n\nEquation for y_i𝑦𝑖\nAdded variable\nColor\nType\n\n\\frac{c\\times64}{\\sqrt{D}}𝑐×64√𝐷\n\nBlack\nR𝑅\n\n\\frac{c\\times32}{\\sqrt{D}}𝑐×32√𝐷\n\nDark green\nR𝑅\n\n\\frac{c\\times64}{\\sqrt{D}+kD}𝑐×64√𝐷+𝑘𝐷\nk=0.00015𝑘 =0.00015\nOrange (dashed)\nR_1𝑅1\n\n\\frac{c\\times64}{\\sqrt{D}(1+kD)}𝑐×64√𝐷(1+𝑘𝐷)\nk=2^{-25}𝑘 =2−25\nLime\nR_{1.5}𝑅1.5\n\n\\frac{c\\times48}{\\sqrt{D}+(kD)^2}𝑐×48√𝐷+(𝑘𝐷)2\nk=2^{-19}𝑘 =2−19\nPink\nR_2𝑅2\n\n\\frac{c\\times64}{\\sqrt{D}+kD+(k_2D)^2}𝑐×64√𝐷+𝑘𝐷+(𝑘2𝐷)2\nk=2^{-14}𝑘 =2−14, k_2=2^{-19}𝑘2 =2−19\nDark purple\nR_{12}𝑅12\n\n\\frac{c\\times64}{\\sqrt{D}+kD+(k_2D)^2}𝑐×64√𝐷+𝑘𝐷+(𝑘2𝐷)2\nk=2^{-13}𝑘 =2−13, k_2=2^{-20}𝑘2 =2−20\nDark purple (dashed)\nR_{12}𝑅12\n\nTable 1. Equations of issuance yield for potential reward curves. The current reward curve is specified in the first row, and various reward curves created by making small adjustments are specified in subsequent rows. The third column indicates the colors of the associated curves plotted in this section and the fourth a type classification.\nThe yearly distributed rewards under the prevailing level of REV for the reward curves of Table 1 are plotted in Figure 30. The reward curves of type R_1𝑅1 are orange in this post and have a term in the denominator that involves D𝐷, like the first neutral example. The orange dashed curve from the table however uses a relatively lower k𝑘, so it will not approach a fixed issuance as quickly. Lime-colored curves are denoted R_{1.5}𝑅1.5, since their equation can also be expressed as \\frac{cF}{\\sqrt{D}+kD\\sqrt{D}}𝑐𝐹√𝐷+𝑘𝐷√𝐷. Issuance for this curve will fall as D𝐷 rises, as shown in the figure. This helps Ethereum better moderate the quantity of stake once it becomes too high. An even stronger moderation is achieved by the R_2𝑅2-curves (pink), adding (kD)^2(𝑘𝐷)2 to the denominator. Finally, curves of type R_{12}𝑅12 (dark purple) are more versatile. The benefit of using two variables is that k𝑘 can be tuned to push down the issuance as desired around deposit sizes of around 30M ETH and k_2𝑘2 for pushing down the issuance at higher deposit sizes. Two variants with different focus are illustrated in the figure.\nFigure 302149×1261 209 KB\nFigure 30. Yearly distributed rewards Y𝑌 to stakers for the reward curves in Table 1.\nFigure 31 instead shows the outcome if REV is removed, for example via MEV burn, thus plotting only yearly issuance Y_i𝑌𝑖. As illustrated, the exemplified reward curves have been designed to give a quantity of stake well above D=𝐷 = 14M ETH under MEV burn with the hypothetical supply curves, and would bring about an equilibrium close to the desired range.\nFigure 312149×1302 227 KB\nFigure 31. Yearly issuance Y_i𝑌𝑖 to stakers for the reward curves in Table 1.\nFigure 32 shows the staking yield y𝑦 under these reward curves and prevailing level of REV. It will indeed fall quite low when D𝐷 is high. Figure 33 instead plots issuance yield y_i𝑦𝑖, which of course is lower since REV is not included.\nFigure 322101×1261 260 KB\nFigure 32. Staking yield y𝑦 of the reward curves in Table 1.\nFigure 332101×1302 266 KB\nFigure 33. Issuance yield y_i𝑦𝑖 of the reward curves in Table 1.\nTo provide a sense of how parameter settings influence the different curves, Figure 34 plots yearly issuance for each different type with alternative settings also included. Changes to parameters in curves not already specified (e.g., in Table 1) is indicated in the plot.\nFigure 342124×1730 397 KB\nFigure 34. Yearly issuance Y_i𝑌𝑖 to stakers for the reward curves in Table 1 (grouped by type), with alternative parameterizations also provided.\n5.3 Analysis of the alternative reward curves\nFigure 35 shows the attester’s proportion of the staking yield for the reward curves, this time having y_a/y𝑦𝑎/𝑦 directly on the y-axis for improved clarity. As evident, all of the analyzed reward curves will have some section with y_a/y>0.5𝑦𝑎/𝑦 >0.5. While the R_{1.5}𝑅1.5-curve (lime) indeed falls with a higher D𝐷, it is still kept above 0.5 for almost the entire range. One reason why this may be reasonable is that REV is not a fixed variable. It can very well rise quite a bit, something that is out of the control of consensus developers. If the aim is to keep the proportion of the yield awarded for attestations above 0.5, then some safety margin may be reasonable.\nFigure 352078×1302 187 KB\nFigure 35. Proportion of the staking yield provided for attestations (y_a/y𝑦𝑎/𝑦) under the current REV for the different reward curves of Table 1.\nFigure 36 instead shows the situation if REV was to double. In this scenario, Ethereum will be operating under a consensus mechanism where the proposers bring in more than half of the rewards with most of the analyzed reward curves. Factoring in potential future variation in REV lends weight to using a reward curve with a somewhat higher issuance level than the most restrictive example in pink. For example, the R_{1.5}𝑅1.5 curve in lime still gives above 1/3 (dashed thin line) of the yield to attesters if the REV were to double. There is also a Bayesian aspect to these considerations. It is more likely that the equilibrium quantity of stake is higher when REV is higher, here referring to the influence of the demand curve \\overline{y}――𝑦 on the equilibrium quantity of stake.\nFigure 362078×1302 193 KB\nFigure 36. Proportion of the staking yield provided for attestations (y_a/y𝑦𝑎/𝑦) if the REV were to double. As in Figure 35, the outcome is provided for the different reward curves of Table 1.\nFigure 37 shows the SSD for the analyzed reward curves. As can be expected, the SSD rises with an increase in D𝐷 for the reward curves that stipulate a falling issuance with an increase in D𝐷.\nFigure 372101×1166 183 KB\nFigure 37. Variation in SSD across D𝐷 for the reward curves of Table 1.\nFigure 38 takes a closer look at variability for solo stakers across D𝐷 under the restrictive pink reward curve. At D=𝐷 = 110M ETH (black line), the expected yield is around 0.5 %, and the unfortunate 45 % of stakers without special duties over the year earn just around 0.2 % in yield.\nFigure 382082×1145 206 KB\nFigure 38. Solo staker yield variability at various deposit sizes under the R_2𝑅2 reward curve of Table 1 (pink curve in figures).\nThe R_{1.5}𝑅1.5 reward curve (lime color) from previously is instead presented in Figure 39. The expected yield at D=𝐷 = 110M ETH is 0.65 % with solo stakers not assigned for special duties receiving 0.31 % under ideal performance. Of course, D=𝐷 = 110M ETH is not a likely medium-run equilibrium under either the R_2𝑅2 (pink) or R_{1.5}𝑅1.5 (lime) reward curve. Indeed it cannot even be reached for several years due to the churn limit. More interesting is probably to study the red and orange CDFs in the plot, representing the variability at D=𝐷 = 30M ETH and D=𝐷 = 50M ETH respectively. The expected yield at D=𝐷 = 50M ETH is 1.55 %. There are fewer unlucky solo stakers in this case; around 17 % of validators are not assigned to special duties over the year, and they then receive a yield of around 0.8 % under optimal performance. Note that since the supply curve is presumably upwards sloping, the equilibrium quantity of stake is lower with the lime-colored reward curve than under the current issuance policy. With the upper hypothetical supply curve from previously, the equilibrium is slightly below D=𝐷 = 30M ETH and with the lower supply curve it is slightly above D=𝐷 = 30M ETH. The red CDF is therefore a very reasonable outcome to consider, and as evident, the unlucky validators are here much better off and further in between.\nFigure 392082×1145 207 KB\nFigure 39. Solo staker yield variability at various deposit sizes under the R_{1.5}𝑅1.5 reward curve of Table 1 (lime curve in figures).\n5.4 Additional properties under consideration\nOne aspect not covered in this post is the minimum yield under which solo staking on an efficient setup is feasible. The protocol facilitates 32 ETH solo validators and should thus ensure that y𝑦 covers their minimum operational costs. Other outcomes seem pathological. Such considerations lend weight to providing some—albeit still very small—yield even at high D𝐷, so that economies of scale can never completely eliminate solo staking. These aspects will be further discussed in forthcoming analysis.\nWhen it comes to discouragement attacks, Buterin framed his early analysis around the variable p𝑝 from the equation for issuance yield of the current reward curve y_i = cFD^{-p}𝑦𝑖 =𝑐𝐹𝐷−𝑝, with p=0.5𝑝 =0.5. His paper discusses an idealized attack with a linearly rising supply curve (yield elasticity of supply equaling 1), and suggests that p>0.5𝑝 >0.5 would render the attack profitable. I would first like to note that once we consider that an attacker must also de-stake under the assumption that it operates under the same supply curve, the condition actually becomes p>1𝑝 >1. A deeper analysis will be provided in a future publication. However, these specific values for p𝑝 are not hard limits. First of all, they depend on the actual supply curve and frictions. More importantly, any analysis must be weighed against the fact that an attacker will indeed put its entire stake at risk of social slashing when executing the attack.\nGoing deeper, we can generalize p𝑝 to be the negated inverse issuance-yield elasticity of demand, hereinafter referred to as the “p_i𝑝𝑖-elasticity”. It is then easy to see following standard economics that an equivalent pointwise p_i𝑝𝑖-elasticity can be computed for any reward curve by relating the percentage change in deposit size \\Delta D/DΔ𝐷/𝐷 to a percentage change in issuance yield across the demand curve \\Delta y_i/y_iΔ𝑦𝑖/𝑦𝑖\n\n\\begin{equation}\np_i = -\\frac{\\Delta y_i/y_i}{\\Delta D/D}.\n\\end{equation}\n𝑝𝑖=−Δ𝑦𝑖/𝑦𝑖Δ𝐷/𝐷.\nFigure 40 plots p_i𝑝𝑖 for various reward curves analyzed in this post. I have long been in favor of a p_i𝑝𝑖-elasticity of 1 for moderating yield. The R_{1.5}𝑅1.5 curve (lime) will indeed cross p_i>1𝑝𝑖 >1, but only if D>2^{25}𝐷 >225, and it still remains moderate. If there is a targeting of a specific deposit size or deposit ratio, then p_i\\rightarrow\\infty𝑝𝑖 →∞ at longer time scales (red dashed line). Such practices make a system particularly fragile to discouragement attacks. There are ways to try to resolve this beyond the scope of this post. When including REV, the negated inverse elasticity will be pushed somewhat towards 1. I will provide a deeper analysis of discouragement attacks in two forthcoming papers.\nFigure 402076×1261 161 KB\nFigure 40. The negated inverse issuance-yield point-elasticity of demand (p_i𝑝𝑖) across D𝐷 for various reward curves analyzed in this post. Lower is better, but staying rather close to 1 should be perfectly acceptable.\nIt may be easier to find agreement on something like the lime or dashed purple curve. A middle ground that can be implemented under rough consensus is better than the status quo. This includes a middle ground of simply adjusting the base reward factor, perhaps even higher than F=32𝐹 =32, say to F=40𝐹 =40. Such a change could still be helpful, with the understanding that MEV burn is still in the cards and will naturally affect staking rewards as well. It is also important to not be too rigid in assumptions around the supply curve and future REV at this point; it is not yet known how these economic forces will develop.\nPushing for the more ambitious reductions in issuance such as from the pink curve may not be worth it. Presumably, some members of the staking community will not be very welcoming to such changes (or any changes for that matter). It becomes a matter here of communicating the utility gains for Ethereum of adhering to MVI also under proof of stake. After all, stakers own the underlying ETH, and may reasonably hope that utility gains for Ethereum make its native token more attractive. A fruitful discussion within the Ethereum community and further research would at this point be very welcome.\nVariability also depends on the frame of reference. Stakers may ultimately be more affected by fiat-denominated price fluctuations of the ETH token. The Sharp ratio, which is essentially the inverse of the RSD, would in reality be measured on a fiat basis today. But the relative frame of reference of keeping the analysis denominated in ETH is very helpful for clarifying how variables relate directly to each other. It isolates effects directly under a staker’s or developer’s control, which is important in staking economics.\n5.5 Potential candidate for a new reward curve\nProperties of a few different types of reward curves with various parameterizations have been presented. Among these, the R_{1.5}𝑅1.5 reward curve (lime in figures) with equation\n\n\\begin{equation}\ny_i = \\frac{cF}{\\sqrt{D}(1+kD)}\n\\end{equation}\n𝑦𝑖=𝑐𝐹√𝐷(1+𝑘𝐷)\nusing F=64𝐹 =64 and k=2^{-25}𝑘 =2−25 will here be highlighted as a potential candidate if Ethereum updates the issuance policy. Its equation for issuance is\n\n\\begin{equation}\nY_i = \\frac{cF\\sqrt{D}}{1+kD}.\n\\end{equation}\n𝑌𝑖=𝑐𝐹√𝐷1+𝑘𝐷.\nThe candidate reward curve has been designed to provide very clear mental models related to the reference point D=2^{25}𝐷 =225 (around 33.6M ETH), that has been highlighted as a point below which it is desirable to keep the deposit size. Specifically, at D=2^{25}𝐷 =225, the reward curve:\n\nInstitutes an exact halving of issuance relative to the current reward curve (both y_i𝑦𝑖 and Y_i𝑌𝑖). Each multiple of 2^{25}225, gives a further reduction to 1/3 and 1/4 respectively.\nReaches its peak issuance. If D>2^{25}𝐷 >225, the issuance will begin to fall (naturally, the issuance yield will always fall with a rise in D𝐷).\nLets the p_i𝑝𝑖-elasticity pass 1, and allows it to moderately rise with a rise in D𝐷.\nLets the proportion of the yield assigned for attestations begin to fall, but keeps it roughly above 0.5 at the current level of REV and above 1/3 across the full range if the REV was to double. This is a compromise between safety and MVI that attempts to balance the situation before MEV burn.\nLets the SSD begin to rise, but still ensures that it rises only moderately.\n\nThe reward curve also provides sufficient assurances of keeping D>14𝐷 >14 M ETH, both before and after MEV burn is in place.\nAs a proof of (1), the candidate reward curve provides a fraction of the issuance yield of the current reward curve of\n\n\\begin{equation}\n\\frac{\\frac{cF}{\\sqrt{D}(1+kD)}}{\\frac{cF}{\\sqrt{D}}}=\\frac{1}{1+kD}.\n\\end{equation}\n𝑐𝐹√𝐷(1+𝑘𝐷)𝑐𝐹√𝐷=11+𝑘𝐷.\nSince k=2^{-25}𝑘 =2−25, kD𝑘𝐷 becomes 1 at D=2^{25}𝐷 =225, and 2 at D=2\\times2^{25}𝐷 =2 ×225 etc.\nTo understand (2), first describe issuance as Y_i = \\frac{cF}{1/\\sqrt{D}+k\\sqrt{D}}𝑌𝑖 =𝑐𝐹1/√𝐷+𝑘√𝐷. The relevant critical point of the denominator can be determined by first computing its derivative\n\n\\begin{equation}\n-0.5D^{-3/2}+0.5kD^{-1/2}\n\\end{equation}\n−0.5𝐷−3/2+0.5𝑘𝐷−1/2\nand finding where it equals zero by multiplication with the least common multiplier 2D^{3/2}2𝐷3/2. This gives\n\n\\begin{equation}\nkD-1=0,\n\\end{equation}\n𝑘𝐷−1=0,\nand thus the condition is D=1/k=2^{25}𝐷 =1/𝑘 =225.\nNote that (3) and (4) follow directly from 2. To summarize, the candidate reward curve offers a balanced compromise that preserves adequate consensus incentives while trying to push Ethereum toward MVI. There is also a clear rationale behind its parameterization, something that may make it easier to unite on.\n6. Conclusion and discussion\nThe effect of issuance level on consensus incentives and reward variability was studied. When it comes to preserving correct consensus incentives, it is desirable to provide sufficient rewards to attesters relative to the rewards that proposers get, and to not let penalties become too low. Under the current reward scheme, this limits how much issuance can be reduced. Likewise, when considering reward variability for solo stakers, there are also good reasons to let issuance be a relevant proportion of all rewards, since it can be distributed with low variability.\nIt is important to recognize the need for formulating our issuance policy as derived from a set of tangible utility measures, providing a rationale for its implementation. Each deposit size can be assigned a maximum protocol utility issuance level. In the absence of a consensus redesign and/or introduction of a staking fee, that level is never too close to 0. But it is also important to not let issuance go above what is needed for retaining security—because that degrades utility for users. In a world without MEV or concern for the conditions of solo staking, designing our issuance policy would be a simpler affair. But MEV will imbalance consensus roles, produce variability, increase uncertainty and keep us from achieving MVI until we burn it. If we succeed in burning MEV, a staking fee discussed in Section 3 will presumably not be needed. If the endogenous yield is zero or negative, there are no direct incentives for staking. Implementing a staking fee at this point thus seems hard to motivate.\nWhile the protocol could allow information about the implied supply curve to influence issuance in the future (i.e., autonomous adjustments), such practices are currently not very beneficial when contemplating our strict dependency on MEV. Still, the impetus for tempering our issuance policy should be clear from previous writings on MVI. It is of course not desirable to incentivize users to (delegate) stake when there is no need for it. If Ethe","tokens":15000,"squid":"spider-04","role":"Research Spider","at":1791346388752,"hash":"417a39685766127efbade9ac27e866e46bdf5184"}
{"url":"https://consensysdiligence.github.io/smart-contract-best-practices/general-philosophy/simplicity/","domain":"consensysdiligence.github.io","title":"Keep it Simple - Ethereum Smart Contract Best Practices","text":"Keep it Simple\n\nTip\nFor comprehensive insights into secure development practices, consider visiting the Development Recommendations section of the Smart Contract Security Field Guide. This resource provides in-depth articles to guide you in developing robust and secure smart contracts.\n\nComplexity increases the likelihood of errors.\n\nEnsure the contract logic is simple\nModularize code to keep contracts and functions small\nUse already-written tools or code where possible (eg. don't roll your own random number\n generator)\nPrefer clarity to performance whenever possible\nOnly use the blockchain for the parts of your system that require decentralization","tokens":164,"squid":"spider-06","role":"Security Spider","at":1791346394262,"hash":"f348f5cd4aa2db11ac8348bc91938aa009a43ad0"}
{"url":"https://developers.jup.ag/docs/tokens/verification","domain":"developers.jup.ag","title":"Express Verification API - Jupiter Developers","text":"The Express Verification API lets you submit tokens for Jupiter VRFD verification and update token metadata programmatically. This is the same Express flow available on the VRFD UI, exposed as an API for launchpads, agents, and projects that need to integrate verification into their token creation pipelines.\nEach Express submission costs 1000 JUP, which prevents spam and prioritizes requests. You can pay in JUP directly, or in SOL, USDC, or JUPUSD, which are converted to 1000 JUP via Ultra. Standard submissions on the VRFD site are free.\nYou can request verification and metadata updates together. Each is reviewed independently, so a metadata update can proceed even if verification is declined.\n​Payment Currencies\nPass paymentCurrency as a token symbol (for example SOL), not a mint address. JUP is the default and transfers directly. SOL, USDC, and JUPUSD are converted to 1000 JUP via an Ultra swap.\npaymentCurrency valueResolves to mintDecimalsConversionJUPJUPyiwrYJFskUPiHa7hkeR8VUtAeFoSYbKedZNsDvCN6Direct transfer of 1000 JUPSOLSo111111111111111111111111111111111111111129Swapped to 1000 JUP via UltraUSDCEPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v6Swapped to 1000 JUP via UltraJUPUSDJuprjznTrTSp2UFa3ZBUFgwdAmtZCq4MQCwysN55USD6Swapped to 1000 JUP via Ultra\n​Prerequisites\n\nGet an API key at Portal. All requests require the x-api-key header.\nThe submitting wallet needs enough of your chosen payment currency for 1000 JUP. Transactions are gasless, so the wallet does not need extra SOL for network fees.\n\n​Flow\nThe API is a three-step flow: check eligibility, craft a payment transaction, sign it, then execute.\n​Step 1: Check Eligibility (Optional)\nCheck if the token can be submitted for verification and/or metadata updates. This step is optional since the execute step also rejects ineligible tokens before charging payment, but it keeps your flow clean and avoids unnecessary transaction crafting.\nThe most common reason for ineligibility is an existing pending submission for the token.\nconst response = await fetch(\n 'https://api.jup.ag/tokens/v2/verify/express/check-eligibility?tokenId=EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v',\n {\n headers: { 'x-api-key': 'YOUR_API_KEY' },\n }\n);\nconst eligibility = await response.json();\n\n{\n \"tokenExists\": true,\n \"isVerified\": false,\n \"canVerify\": true,\n \"canMetadata\": false,\n \"metadataError\": \"A premium metadata update request for this token already exists\"\n}\n\nFieldTypeDescriptiontokenExistsbooleanWhether the token exists on-chainisVerifiedbooleanWhether the token is already verifiedcanVerifybooleanWhether a verification request can be submittedcanMetadatabooleanWhether a metadata update can be submittedverificationErrorstringWhy verification cannot proceed (only present when there is a specific error)metadataErrorstringWhy metadata cannot proceed (only present when there is a specific error)\nIf both canVerify and canMetadata are false, the submission will be rejected before any payment is charged.\n​Step 2: Craft the Payment Transaction\nThis returns an unsigned Solana transaction worth 1000 JUP. By default it crafts a direct JUP transfer. Pass paymentCurrency to pay in SOL, USDC, or JUPUSD instead, which crafts an Ultra swap to JUP (see Pay with SOL, USDC, or JUPUSD). Save the requestId from the response, you need it in the next step.\nconst craftResponse = await fetch(\n `https://api.jup.ag/tokens/v2/verify/express/craft-txn?senderAddress=${walletAddress}`,\n {\n headers: { 'x-api-key': 'YOUR_API_KEY' },\n }\n);\nconst { transaction, requestId } = await craftResponse.json();\n\nParameterTypeRequiredDescriptionsenderAddressstringYesSolana wallet address that will sign and pay for the transactionpaymentCurrencystringNoToken symbol, not a mint address: JUP (default), SOL, USDC, or JUPUSD. Non-JUP currencies route through an Ultra swap to JUP.\nThe response includes the base64-encoded unsigned transaction and a requestId that links this payment to your execute request.\n{\n \"receiverAddress\": \"5x...recipient\",\n \"mint\": \"JUPyiwrYJFskUPiHa7hkeR8VUtAeFoSYbKedZNsDvCN\",\n \"amount\": \"1000000000\",\n \"tokenDecimals\": 6,\n \"tokenUsdRate\": 0.42,\n \"feeLamports\": 5000,\n \"feeUsdAmount\": 0.0009,\n \"feeMint\": \"So11111111111111111111111111111111111111112\",\n \"feeTokenDecimals\": 9,\n \"feeAmount\": 5000,\n \"transaction\": \"AQAB...\",\n \"requestId\": \"req_abc123\",\n \"totalTime\": 412,\n \"expireAt\": \"2026-06-30T12:00:00.000Z\",\n \"code\": 0,\n \"gasless\": true\n}\n\nFieldTypeDescriptiontransactionstringBase64-encoded unsigned transactionrequestIdstringUnique ID for this payment. Pass to /execute.receiverAddressstringWallet address receiving the JUP paymentmintstringMint of the JUP collected (always JUP)amountstringJUP amount in smallest unit (1000 JUP = 1000000000)tokenDecimalsnumberDecimals of the JUP collected (6)tokenUsdRatenumberUSD rate of JUP at craft timefeeLamportsnumberNetwork fee for the transaction, in lamportsfeeUsdAmountnumberNetwork fee in USDfeeMintstringMint address of the fee tokenfeeTokenDecimalsnumberDecimals of the fee tokenfeeAmountnumberFee amount in the fee token’s smallest unittotalTimenumberTime taken to craft the transaction, in millisecondsexpireAtstringExpiry timestamp for the crafted transactioncodenumberStatus code (0 for success)gaslessbooleanWhether the transaction is gasless\nNon-JUP payments return additional swap sizing fields. See Pay with SOL, USDC, or JUPUSD.\n​Step 3: Sign and Execute\nSign the transaction from Step 2 with your wallet, then submit it along with the token details and metadata.\nimport { VersionedTransaction } from '@solana/web3.js';\n\n// Deserialize and sign the transaction\nconst txBuffer = Buffer.from(transaction, 'base64');\nconst tx = VersionedTransaction.deserialize(txBuffer);\ntx.sign([wallet]); // wallet is a Keypair\n\n// Serialize the signed transaction back to base64\nconst signedTransaction = Buffer.from(tx.serialize()).toString('base64');\n\n// Submit\nconst executeResponse = await fetch(\n 'https://api.jup.ag/tokens/v2/verify/express/execute',\n {\n method: 'POST',\n headers: {\n 'x-api-key': 'YOUR_API_KEY',\n 'Content-Type': 'application/json',\n },\n body: JSON.stringify({\n transaction: signedTransaction,\n requestId,\n senderAddress: wallet.publicKey.toBase58(),\n tokenId: 'YOUR_TOKEN_MINT_ADDRESS',\n twitterHandle: 'https://x.com/yourproject',\n description: 'Submitting for verification because...',\n tokenMetadata: {\n tokenId: 'YOUR_TOKEN_MINT_ADDRESS',\n website: 'https://yourproject.io',\n twitter: 'https://x.com/yourproject',\n discord: 'https://discord.gg/yourproject',\n },\n }),\n }\n);\nconst result = await executeResponse.json();\n\nFieldTypeRequiredDescriptiontransactionstringYesBase64-encoded signed transaction from craft-txnrequestIdstringYesrequestId from the craft-txn responsesenderAddressstringYesSolana wallet address of the sendertokenIdstringYesToken mint address to verifytwitterHandlestringYesTwitter/X handle of the token projectdescriptionstringYesReason for the verification requestsenderTwitterHandlestringNoTwitter/X handle of the submittertokenMetadataobjectNoToken metadata to submit alongside verification. See Token Metadata Fields.paymentCurrencystringNoToken symbol, not a mint address: JUP (default), SOL, USDC, or JUPUSD. Must match the currency used in craft-txn.paymentAmountstringConditionalAtomic input amount paid, from the craft response’s quotedInputAmount. Required when paymentCurrency is not JUP.jupOutputAmountstringNoAtomic JUP output from the craft response (its amount field). Optional, but recommended on non-JUP paths so revenue tracks the JUP actually collected.\n{\n \"status\": \"Success\",\n \"signature\": \"5UfDuX...\",\n \"totalTime\": 1234,\n \"verificationCreated\": true,\n \"metadataCreated\": true\n}\n\nFieldTypeDescriptionstatus\"Success\" | \"Failed\"Whether the transaction executedsignaturestringOn-chain transaction signature (present on success)errorstringError message (present on failure)codenumberError code (present on failure)totalTimenumberTime taken to execute, in millisecondsverificationCreatedbooleanWhether a verification request was createdmetadataCreatedbooleanWhether a metadata update request was created\nAfter submission, track your request status at verified.jup.ag/tokens/browse.\n​Pay with SOL, USDC, or JUPUSD\nTo pay with a non-JUP currency, set paymentCurrency on both the craft and execute steps. The craft step returns an Ultra swap that converts your input token into JUP, sized with a small buffer so the swap yields at least 1000 JUP.\nRequest the transaction with your chosen currency:\nconst craftResponse = await fetch(\n `https://api.jup.ag/tokens/v2/verify/express/craft-txn?senderAddress=${walletAddress}&paymentCurrency=SOL`,\n {\n headers: { 'x-api-key': 'YOUR_API_KEY' },\n }\n);\nconst craft = await craftResponse.json();\n\nOn non-JUP paths the response includes these swap sizing fields in addition to the common fields above:\nFieldTypeDescriptioninputMintstringInput token mint addressinputDecimalsnumberInput token decimalsquotedInputAmountstringAtomic input amount for the swap, sized to yield at least 1000 JUPmaxInputAmountstringMaximum atomic input amount for the swap. Equal to quotedInputAmount on the current swap flow.\nWhen you execute, pass paymentAmount (required on non-JUP paths) and jupOutputAmount (optional, for revenue tracking). paymentAmount is the input amount from the craft response’s quotedInputAmount, and jupOutputAmount is the craft response’s amount:\nbody: JSON.stringify({\n transaction: signedTransaction,\n requestId,\n senderAddress: wallet.publicKey.toBase58(),\n tokenId: 'YOUR_TOKEN_MINT_ADDRESS',\n twitterHandle: 'https://x.com/yourproject',\n description: 'Submitting for verification because...',\n paymentCurrency: 'SOL',\n paymentAmount: craft.quotedInputAmount,\n jupOutputAmount: craft.amount,\n}),\n\n​Token Metadata Fields\nThe tokenMetadata object in the execute request is optional. Include it to update metadata alongside your verification submission. Only tokenId is required, all other fields are optional.\nFieldTypeDescriptiontokenIdstringToken mint address (required)namestringToken display namesymbolstringToken ticker symboliconstringURL to token icon imagewebsitestringProject website URLtwitterstringTwitter/X profile URLtwitterCommunitystringTwitter/X community URLtelegramstringTelegram group URLdiscordstringDiscord invite URLinstagramstringInstagram profile URLtiktokstringTikTok profile URLtokenDescriptionstringShort description of the tokencirculatingSupplystringCirculating supply valueuseCirculatingSupplybooleanWhether to use the provided circulatingSupply valuecirculatingSupplyUrlstringURL to a live circulating supply endpointuseCirculatingSupplyUrlbooleanWhether to use the provided circulatingSupplyUrlcoingeckoCoinIdstringCoinGecko coin ID for price datauseCoingeckoCoinIdbooleanWhether to use the provided coingeckoCoinIdotherUrlstringAny other relevant URL\n​Known Projects and Launchpads\nIf you are a known project or launchpad on Solana, DM @jup_vrfd from your organization account on X. This links your Developer Platform OrgId to your submissions, which helps the VRFD team review them.\n​API Reference\nWas this page helpful?","tokens":2772,"squid":"spider-02","role":"Liquidity Spider","at":1791346397242,"hash":"4824ffe12af18688d3204d3f0f925afbbfc1cf74"}
{"url":"https://ethresear.ch/t/properties-of-issuance-level-consensus-incentives-and-variability-across-potential-reward-curves/18448/13","domain":"ethresear.ch","title":"Properties of issuance level: consensus incentives and variability across potential reward curves - Economics - Ethereum Research","text":"Economics\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 33\n min\n\n Jan 2024\n\n 12 / 12\n\n Jul 2024\n\n Jul 2024\n\n post by aelowsson on Jan 24, 2024\n\n aelowsson\n\n Properties of issuance level: consensus incentives and variability across potential reward curves\nBy Anders Elowsson\nThanks to Barnabé Monnot, Francesco D’Amato, Caspar Schwarz-Schilling, Thomas Thiery, Davide Crapis, Julian Ma, Vitalik Buterin, Justin Drake and Ansgar Dietrichs for review and/or fruitful discussions. Thanks also to Flashbots for providing the data used in the analysis.\nThis post is also available in a more compact format as a thread, but Section 5 offers several additions.\n\n1. Introduction\n1.1 Background\nEthereum’s stakers started to receive execution layer rewards with The Merge and liquidity improved when withdrawals were enabled with Shapella. Both upgrades have served to push up the equilibrium quantity of stake. The resulting increase in gossip messaging and to the Beacon state size puts strain on the consensus layer. An increase in staking deposits is furthermore associated with an increase in issuance of new tokens under the current reward curve, bringing an inflationary pressure on regular users who rely on ETH. Ethereum issues ETH to stakers to incentivize them to stake and secure the blockchain. But raising the issuance level if no further stake is needed—and even degrades both the consensus network and economics—is arguably not beneficial. The amount of stake that Ethereum needs to remain secure is a subject of active research and discussion, where many developers now argue that it is reasonable to moderate the growth. In preparation for such an effort, this post will analyze the effect of issuance level on consensus incentives and reward variability across potential reward curves.\n1.2 Security and deposit size\nThe relationship between the staking deposit size D𝐷 and Ethereum’s security level is not trivial to characterize. On the one hand, we may focus on the value slashed in an attack. Since one million (M) ETH is worth around 2.2 billion dollars today, the cost of attacking Ethereum using some critical proportion of D𝐷 (which is currently 29M ETH), becomes very high under the threat of slashing. But a higher deposit size also provides Sybil resistance to more subtle forms of degradation to the consensus mechanism that may not immediately lead to slashing (e.g., short reorgs). Notably, the 14M ETH securing Ethereum at The Merge was found sufficiently secure by the ecosystem at the time, in a way acting as a “revealed preference” under those prevailing circumstances. In any case, there comes a point where the marginal increase in security from adding another validator brings less utility than the utility loss to users. A level of D=2^{25}𝐷 =225 ETH (33.6M ETH) has been used as a reference point of when network conditions (and economics) start to degrade. Drake expanded on his reasons for supporting a target of 30M ETH in a recent AMA. This active area of research is related to the concept of “minimum viable issuance”.\n1.3 Minimum viable issuance\nAn ideal deposit size will satisfy minimum viable issuance, the idea that Ethereum should not issue more tokens than what is strictly needed for security. Excessive issuance—which is always an inflation tax on users—forces everyone to expend resources staking, or to face a principal–agent problem as a delegating staker, lest they want their ETH savings eroded. This degrades utility in aggregate. Staking income is also taxed in many jurisdictions, whereas circulating supply deflation is not. From a macro perspective, Ethereum avoids a scenario where a staking service provider (SSP) can come to dominate not only in terms of staked ETH under its control, but also in terms of the total circulating supply, making its issued liquid staking token (LST) a novel stratum for cartelization. A concern is that a majority of Ethereum’s users will be economically entangled with one or a few for-profit SSPs through its issued LST. In the case of a mistake or misdeed by the SSP, Ethereum’s social layer may then waver on its commitment to the underlying intended consensus process. It is arguably preferable to see Ethereum’s native token permeate and bind together the extended ecosystem (including rollups) instead of a derivative of it.\n1.4 Consensus incentives\nEthereum’s consensus mechanism relies on a collection of micro incentives to ensure that validators perform their tasks correctly. The attester is rewarded for voting on a correct source and target checkpoint for Casper FFG, as well as the head block within LMD-GHOST. A missing/late or incorrect Casper FFG vote instead results in a penalty. The proposer attains 1/7 of the rewards given to attesters for including the attestations in the proposed block. The magnitudes of these micro incentives (including penalties) are ultimately regulated by the issuance level. This differs from the MEV and priority fees that the proposer also receives, which are unrelated to issuance policy. An equilibrium enforced through a reduction in issuance can unbalance the economic forces, rendering the micro incentives ineffective. Solo stakers would also be negatively affected by the increase in reward variability. Maintaining correct incentives as the issuance level and deposit size change is important.\n1.5 Purpose and main questions\nTo what extent can Ethereum stop issuing more tokens than what is needed for security? Can we reduce issuance while still retaining consensus stability, proper incentives, and acceptable conditions for solo staking? Can we adopt a reward curve that lets the issuance yield go negative past some specific staking deposit size D𝐷, or target some specific desirable D𝐷 by simply adapting the yield to enforce it? Otherwise, should a more moderate approach be adopted? This post will take a closer look at these questions and review features of staking economics that affect consensus incentives and reward variability—including how they vary across deposit size. The analysis shows the benefit of a moderately falling issuance as the deposit size rises above target levels, with relevant candidate reward curves evaluated in Section 5.\n2. Equilibrium staking\n2.1 Supply and demand\nThe base reward factor F𝐹 is the parameter that directly adjusts the issuance level under the current reward curve, affecting all consensus rewards and penalties. Ethereum provides an issuance yield under idealized performance of y_i = \\frac{cF}{\\sqrt{D}}𝑦𝑖 =𝑐𝐹√𝐷, where F=64𝐹 =64 and the constant c\\approx2.6𝑐 ≈2.6. The total yield provided by the protocol to stakers implies its demand for stake and it is\n\n\\begin{equation}\ny=y_i+y_v, \n\\end{equation}\n𝑦=𝑦𝑖+𝑦𝑣,\nwhere y_v𝑦𝑣 is the yield from realized extractable value (REV). The REV is the value that stakers receive from priority fees and MEV after builders take their cut. Define the yearly aggregate REV as V𝑉 (currently around 300k ETH). The expected yield from REV then becomes y_v=V/D𝑦𝑣 =𝑉/𝐷. Going forward, the post will sometimes use overline when referring specifically to the demand curve, if needed for clarity (thus \\overline{y}=y_i+y_v――𝑦 =𝑦𝑖 +𝑦𝑣), and underline \\underline{y}𝑦―― for the supply curve.\nNote that the demand curve formed through \\overline{y}――𝑦 is the “endogenous yield” derived exclusively from staked participation in the consensus process. The yield from DeFi (including “restaking”) that is exogenous to staking y_c𝑦𝑐, is not part of \\overline{y}――𝑦; it can under competitive equilibrium also be derived by non-stakers. It is convenient to separate \\overline{y}――𝑦 and y_c𝑦𝑐 in the analysis, to properly model what happens as \\overline{y}――𝑦 falls towards zero. At that point, there will be no point in staking. Any yield derived outside of the consensus mechanism from staked ETH will also be possible to derive via non-staked ETH. For example, it will be better to “restake” WETH. Any DeFi service that fails to serve non-staked ETH will be outcompeted. This means that Ethereum must always offer a positive endogenous yield \\overline{y}――𝑦. This is a nice assurance to Ethereum’s stakers. This post will go a step further, and ascertain that y_i𝑦𝑖 specifically also must be kept well above zero under the current version of the consensus mechanism (as an aside, if the REV is burned, y_i𝑦𝑖 will also remain above 0, since there once again will be no point in staking if y_i=0𝑦𝑖 =0).\nGenerally, y_c𝑦𝑐 should be higher for non-stakers than stakers, because collateral that cannot simply evaporate is more reliable and valuable. Contemplate for example the effect that a majority client bug could have on an actively validated service collateralized solely by staked ETH. However, y_c𝑦𝑐 can still incentivize users to supply stake at a lower staking yield, as long as the staking yield more than compensates for the staked ETH’s degradation as collateral. For example, say that an agent is willing to own and lock up ETH if the total acquired yield (including y_c𝑦𝑐) is over 0.04 (disregarding costs/risks for simplicity). Define y_c'𝑦′𝑐 as the yield from collateralizing non-staked ETH. If y+y_c > 0.04𝑦 +𝑦𝑐 >0.04 and y+y_c > y_c'𝑦 +𝑦𝑐 >𝑦′𝑐, the agent will decide to stake ETH. Thus, if y_c = 0.01𝑦𝑐 =0.01 and y_c'=0.02𝑦′𝑐 =0.02, the requirement is y> 0.03𝑦 >0.03 for the agent to stake. But if y_c = 0.02𝑦𝑐 =0.02 and y_c'=0.03𝑦′𝑐 =0.03 the requirement is only y> 0.02𝑦 >0.02.\nThe shape of the supply curve is unknown and affected by many variables. Plots will be provided in this post covering a broader range so that different assumptions can be mapped to various outcomes. As a guideline, two supply curves will be included in the plots. The equation used for the (inverse) supply curve is\n\n\\begin{equation}\n\\underline{y}=c_1d^k + \\frac{c_2d}{1-d},\n\\end{equation}\n𝑦――=𝑐1𝑑𝑘+𝑐2𝑑1−𝑑,\nusing the deposit ratio d𝑑 (the fraction of the around 120M circulating ETH that is staked), with k=1/2𝑘 =1/2, c_2=0.003𝑐2 =0.003. The first term c_1d^{1/2}𝑐1𝑑1/2 gives the curves a yield elasticity of supply of around 2 in the middle range. The term \\frac{c_2d}{1-d}𝑐2𝑑1−𝑑 captures the notion that the final fraction of the circulating supply may not be staked in the medium run until the yield becomes very high. The opposite, a downward-sloping supply curve due to network effects of LSTs, seems a bit far-fetched. The variable c_1𝑐1 is set so that \\underline{y}𝑦―― reaches some specific deposit size at some plausible yield. In this post, the two curves were set to reach D=𝐷 = 25M at y=0.025𝑦 =0.025 and y=0.02𝑦 =0.02 respectively. The upper curve could for example represent the supply curve underpinning an equilibrium within a year or two, whereas the lower curve could be the supply curve after a few years of improvements to the the staking experience and better financial integrations.\nThis post tracks supply and demand across D𝐷 (specifically, it does not track the circulating supply and its effect on d𝑑), which means that it deals with medium-run staking equilibria. The long-run staking equilibrium under reward curves that adapt to D𝐷 is ultimately also influenced by the circulating supply equilibrium, since the circulating supply will drift to balance supply, demand, and protocol income.\n2.2 Influence of F𝐹 on the equilibrium\nFigure 1 plots a hypothetical medium-run equilibrium staking. The colormap and y-axis both capture y𝑦, with the colormap restricted to F \\in [0, 75]𝐹 ∈[0,75]. At equilibrium, the demand curve will intersect the supply curve. Hypothetical equilibria under the current issuance policy (F=64𝐹 =64) at the prevailing level of REV are indicated by blue circles. The hypothetical equilibria if issuance is halved (F=32𝐹 =32) are indicated by blue squares. Such a reduction brings the deposit size closer to a previously suggested desirable range in between the dashed blue lines. The left dashed blue line indicates 14M ETH and the right dashed line indicates 33.6M ETH.\nFigure 11945×1261 254 KB\nFigure 1. Medium-run staking equilibrium between the supply of stake (blue hypothetical supply curves) and demand for stake (white reward curves at various settings for F𝐹 under the current level of REV). The y-axis represents staking yield and the x-axis deposited stake. It has been suggested that Ethereum should strive for an equilibrium between the vertical dashed blue lines indicated by arrows.\nIt is not possible to ascertain the exact effect of a reduction in F𝐹, but we can be rather certain that the yield elasticity of supply for the medium run is not 0 (a vertical supply curve). Reducing F𝐹 will therefore always reduce the quantity of stake, ceteris paribus. Figure 2 shows that the full reduction in yield from a change in F𝐹 (white downwards arrow) will not remain at the new equilibrium, because some stakers will presumably leave (blue leftwards arrow), bringing the yield for remaining stakers back up a bit (white leftwards arrow).\nFigure 21945×1261 239 KB\nFigure 2. Hypothetical effect of a reduction to F𝐹 from 64 to 32. The equilibrium yield initially falls from 2.95 % to 1.77 %, but then comes back up to 2.34 % as some stakers leave. Around half of the initially lost yield is thus recouped with this supply and demand curve.\nHow will this dynamic affect the solo staker and delegating staker? The outcome over shorter time horizons will depend on variations in cost structures and frictions affecting the decision to stake or de-stake. A solo staker who will not buy new hardware at some low yield may still stake over the lifetime of their current hardware. Delegating stakers dissatisfied with the yield may keep their savings in the LST until the next time they wish to spend their money, or leave directly. Solo stakers’ upfront costs and illiquidity presumably give them a lower yield elasticity of supply in the short run. This is comforting, because a temporarily lower-than-equilibrium yield (if F𝐹 is reduced in a hard fork) may not push them out forever.\nIt seems likely that the supply curve will gradually shift downwards over time as the staking experience simplifies and DeFi integrations improve. The outlined dynamic in Figure 2 may therefore not fully materialize, as a lowering supply curve can nullify any de-staking process. The equilibrium quantity of stake will however still be lower with a reduction in F𝐹 than if F𝐹 is kept fixed. We must evaluate each possible outcome at the medium-run equilibrium. The effect of a gradually lowering supply curve is a gradually increasing deposit size.\nFigure 3 has F𝐹 on the y-axis (thus essentially the demand curve) instead of yield. You may think of it as dragging down and straightening the bent colormap in Figure 1 such that it becomes a rectangle. The colors encode the same yield as previously (also indicated by black lines). This viewpoint is convenient as the post now further explores the effect of a change to the issuance level. Both alternative graphs will often be provided to the reader and the same two supply curves indicated as guidelines.\nFigure 31908×1261 291 KB\nFigure 3. The same staking equilibrium as in Figure 1, but this time with the base reward factor F𝐹 (regulating the demand curve) on the y-axis. The colormap still encodes staking yield.\n3. Consensus incentives\nWhen contemplating a change to the issuance policy, it is important to consider the effects on consensus stability, in particular how incentives may change for different consensus roles that validators will be assigned to. Figure 4 shows the proportion of the yield stemming from issuance at various settings for any specific base reward factor F𝐹. Naturally, the lower F𝐹 is set, the lower the proportion of rewards that come from issuance. Right now at the prevailing level of REV, more than 2/3 of the yield comes from issuance. Since y_v𝑦𝑣 falls by the reciprocal of D𝐷, whereas y_i𝑦𝑖 falls by the reciprocal of \\sqrt{D}√𝐷 under the current reward curve, a higher proportion of the yield will stem from issuance at a higher D𝐷.\nFigure 41883×1243 265 KB\nFigure 4. The proportion of staking yield derived from issuance (as opposed to REV), with F𝐹 on the y-axis and D𝐷 on the x-axis.\nFigure 5 instead shows the yield that comes from attester duties (y_a𝑦𝑎) in proportion to all staking yield y_a/y𝑦𝑎/𝑦 (note that the measure thus incorporates the small yield from sync-committtee attestations in y_a𝑦𝑎, although these attestations functionally differ somewhat). Since the proposer gets 1/8 of the issued rewards, the reported proportion in y_a/y𝑦𝑎/𝑦 is lower than in y_i/y𝑦𝑖/𝑦. If F𝐹 is reduced to 32, almost half the rewards will come from the sparse chances of proposing a block. There is no well-defined proportion of y𝑦 that must be provided for attester duties, but higher is generally better. This post will use y_a/y>1/2𝑦𝑎/𝑦 >1/2 as a guideline of a more healthy situation, y_a/y<1/3𝑦𝑎/𝑦 <1/3 as unhealthy, and y_a/y<1/4𝑦𝑎/𝑦 <1/4 as an outcome to be avoided. These guidelines are rather arbitrary, and a good subject for further research.\nFigure 51883×1243 356 KB\nFigure 5. The proportion of staking yield derived from accurately performing attester duties (as opposed to proposer duties), with F𝐹 on the y-axis and D𝐷 on the x-axis.\nWhen y_i/y𝑦𝑖/𝑦 and y_a/y𝑦𝑎/𝑦 fall too low, the consensus mechanism breaks down. Consensus rewards and penalties stop providing correct incentives for stakers. Honest attestation is less compelling. The only thing that matters is to collect REV and to not get slashed. Ignoring attester duties comes at little to no cost as long as the inactivity leak is not triggered, and instigating reorgs will be more tempting. If REV rises relative to the proposer reward, timing games also become relatively more attractive.\nMoving back to having staking yield on the y-axis in Figure 6 gives another perspective on how various hypothetical changes to issuance policy may affect the proportion of rewards awarded for attestation. This time, the x-axis extends across the full circulating supply.\nFigure 61920×1261 150 KB\nFigure 6. The proportion of staking yield derived from accurately performing attester duties (as opposed to proposer duties), with y𝑦 on the y-axis and D𝐷 on the x-axis. The red curve represents a previously proposed reward curve, and the dashed red line is the implied reward curve of targeting a specific quantity of stake.\nIn red, we contemplate the various stricter issuance policies that can be attempted, and the adverse effects they may bring before MEV burn is in place. For example, to target D =\\,𝐷 = 24M ETH (dashed red line) while keeping y_a/y>0.5𝑦𝑎/𝑦 >0.5, the yield must be around 3 % (red square). This seems unreasonably high given that the supply curve slopes upwards. Therefore, to enforce D =\\,𝐷 = 24M ETH, an even lower proportion of rewards must be given for attester duties. Indeed, even if these duties are not given any issuance rewards at all, an equilibrium may still not be achieved. An equilibrium where the issuance yield is “negative” is manifested by the white region of the figure. This could be the only possible equilibrium if the supply curve over time drifts lower—which seems like a very reasonable assumption—or simply because of a not particularly unlikely rise in REV.\nThe same type of problem can be encountered when adopting a reward curve that goes negative to enforce a deposit size below some specific level. The red line indicates the reward curve previously suggested by Buterin. At many reasonable equilibria with such strict reward curves, the rewards for attester duties will be very low (red circles), or non-existent. The breakdown of the consensus mechanism is then complete.\nAs previously outlined, when D𝐷 rises, the white region representing y_v𝑦𝑣 becomes smaller and smaller. This happens because y_v𝑦𝑣 falls by the reciprocal with a rise in D𝐷. At 120M ETH staked, y_v𝑦𝑣 is just 0.25 %. A quadrupling of REV would only lead to y_v=0.01𝑦𝑣 =0.01 at 120M ETH staked, but to the rather imposing y_v=0.04𝑦𝑣 =0.04 at 30M ETH staked. The important notion to take away from this particular discussion is that the lower the deposit size that Ethereum tries to enforce a staking equilibrium at before MEV burn, the more influential REV is going to be.\nSome of the issues of a lower issuance here outlined can be remedied by taking out a staking fee each epoch and increasing the base reward correspondingly. To prevent consensus breakdown, the fee must be introduced already at positive yields, for example when y_a/y<0.5𝑦𝑎/𝑦 <0.5 or y_a/y<0.33𝑦𝑎/𝑦 <0.33. However, introducing a fee challenges long-standing tenets promoted to solo stakers (“you can go offline X % of the time and still break even”, etc.). Trying to push through these far-reaching changes when MEV burn eventually can make them obsolete therefore seems undesirable. Furthermore, a staking fee will not resolve other issues of a very low issuance, such as a rise in the relative and equilibrium variability in rewards for stakers that do not pool their MEV income.\n4. Variability in rewards for solo stakers\nThe variability in rewards is higher for solo stakers than delegating stakers under the current consensus mechanism, because delegating stakers can in a frictionless manner rely on pooling of rewards from a large number of validators. This affects solo stakers negatively. A change in issuance policy could further widen the gap in variability, and it is therefore necessary to model that. The most prominent research on reward variability has been done by Pintail, with analysis up until and just after The Merge. The reader is also encouraged to study writings on this matter by Edgington.\n4.1 Model\nThis post models variability for solo validators over one year in a rather simple fashion, with the distribution in proposer and sync-committee duties assigned according to the probabilities given from the consensus spec at each modeled deposit size. The focus is on the greatest source of variability, namely that of variation in REV. To this end, block proposers are assigned REV using sampling with replacement from the roughly 2.7 million block-level sample points provided by Flashbots. The probability density function (PDF) in Figure 7 of the REV in Ethereum shows a positive skew, with a mode of around 0.025. The mean of around 0.12, indicated by a dashed vertical line, is higher due to the occasional blocks with very high REV.\nFigure 71988×932 27.3 KB\nFigure 7. A PDF of Realized extractable value (REV) in 2.7 million blocks of Ethereum since The Merge.\nTo discern more details, the cumulative distribution function (CDF) is plotted in Figure 8 with a log-scaled x-axis and a logit-scaled y-axis. The median REV is around 0.045 ETH and less than 20 % of the slots are above the mean. The “median block” will thus still provide higher rewards for attesters than the proposer even as y_a/y=0.5𝑦𝑎/𝑦 =0.5. But the assertion in Section 3 is not specifically that all blocks provide the proposer with more value when y_a/y<0.5𝑦𝑎/𝑦 <0.5. Instead, it is rather that of generally misaligned incentives and systemic risk, which Ethereum is better off avoiding if possible.\nFigure 82113×1104 110 KB\nFigure 8. A CDF of Realized extractable value (REV) in 2.7 million blocks of Ethereum since The Merge. Note that the x-axis is log-scaled and the y-axis logit-scaled.\nBlocks have been missed with a probability of around 0.96 % since The Merge, a condition that is also included in the model. Missed sync-committee assignments are not precisely modeled and instead assigned to have the same probability as missed blocks. It is presumably a lot less common to fully miss the sync-committee assignment (which spans over more than a day), and much more likely to partially miss it, but modeling this exactly is beyond the scope of this post. Notably, blocks are to a higher proportion missed by solo stakers than professional stakers, something that further degrades conditions for solo stakers when y_i𝑦𝑖 is reduced relative to y_v𝑦𝑣. This specific feature is not included in the model. Finally, attesters are assumed to perform their duties correctly and are set to receive the full rewards (a slight overestimate). Variation in attestation accuracy will produce much less variability than selection for special duties such as block proposals, so it is less relevant to the analysis.\n4.2 Effect of pooling\nFigure 9 shows the influence of pooling on variability in staking yield at the current deposit size of D=𝐷 = 29M ETH, using CDFs of different pool sizes. Annualized validator rewards were simulated 30M times, sampling REV with replacement (s. w. r.). Pools were created from these distributions, also s. w. r. 30M times. As evident, variability is gradually reduced with more staked ETH (the curve becomes steeper). A solo staker running 2 or 5 validators can already reduce variance quite a bit; a small pool managing a couple of thousand ETH will still not be able to fully remove variance; etc.\nFigure 92082×1145 208 KB\nFigure 9. The influence of pooling on variability in staking yield at the current deposit size of D=𝐷 = 29M ETH, captured using CDFs of different pool sizes.\nAs illustrated in Figures 5-6, the proportion of attester rewards is around 0.5 at 29M ETH staked when F=32𝐹 =32. This retains proper consensus incentives according to the guidelines from Section 3. But it is perfectly reasonable to expect a higher quantity of stake under equilibrium at F=32𝐹 =32 and a staking fee would then be required to achieve an equilibrium, as previously discussed. An example of the effect of such a fee is shown in Figure 10, where the yield at 29M ETH is pushed down to 1.25 %, while keeping F=32𝐹 =32 to retain proper consensus incentives. A yield of 1.25 % is still within the green area of Figure 6, meaning that stakers have a positive expected y_i𝑦𝑖 (even when y_i𝑦𝑖 accounts for the fee, as in this post). However, a black vertical section of the solo staking CDF in Figure 10 indicates a negative yield over the year for solo stakers that do not get to propose a block or attest in the sync committee. This happens because the proposer gets 1/8 of all issuance rewards (and the sync-committee attester 1/32), and so non-selected stakers must still lose ETH every epoch even as y_i𝑦𝑖 is slightly above zero. Trying to push the yield into the white area of Figure 6 pushes a larger section of solo stakers underwater over a year. The notion of solo stakers being affected the worst by a low issuance yield is something that will be explored further in the following subsections. However, that analysis will not include a fee, instead focusing on the degradation that happens even without a fee.\nFigure 102082×1145 222 KB\nFigure 10. The influence of pooling on variability in staking yield at the current deposit size of D=𝐷 = 29M ETH, when applying a staking fee of 1.34 % to push down the expected staking yield to 1.25 %.\nTwo additional figures can be interesting, covering the situation under equilibrium with the current issuance policy and the two hypothetical supply curves. With the higher supply curve from previous plots, the equilibrium staking is around 41.9M ETH. Figure 11 shows the variability under such a deposit size, otherwise using the same conditions as previously. Average y𝑦 (indicated by a grey dashed line) falls at the equilibrium.\nFigure 112082×1145 204 KB\nFigure 11. The influence of pooling on variability in staking yield at a hypothetical equilibrium of D=𝐷 = 41.9M ETH, captured using CDFs of different pool sizes.\nWith the lower supply curve, the equilibrium is D=𝐷 = 50.4M ETH, as shown in Figure 12. The vertical part of the black line, representing solo stakers with no block or sync-committee assignments, is then rather noticeable.\nFigure 122082×1145 201 KB\nFigure 12. The influence of pooling on variability in staking yield at a hypothetical equilibrium of D=𝐷 = 50.4M ETH, captured using CDFs of different pool sizes.\n4.3 Variability with fixed supply and varied demand\nIt is now time to study how variability in yield changes for solo stakers when F𝐹 is changed (no fee). Figure 13 shows the equilibrium CDF under the lower supply curve (the expected yield is dashed). When F=0𝐹 =0, only REV remains, and stakers with no block proposals receive no rewards at all.\nFigure 132082×1145 218 KB\nFigure 13. Changes to solo staker yield variability under equilibrium for a fixed hypothetical supply curve when F𝐹 (demand) is changed.\nTo better illustrate the risk solo stakers take on in comparison with delegating stakers, all cumulative probability distributions were normalized by subtracting the average yield (“shift-normalized”), as shown in Figure 14. This preserves the standard deviation (SD) of each distribution. It is now easier to observe how a change to F𝐹 increases variability at the medium-run equilibrium. The effect is particularly prominent at F=0𝐹 =0, and also noticeable at F=16𝐹 =16. From F=32𝐹 =32 and above, the increase in variability relative to F=64𝐹 =64 is less significant.\nFigure 142082×1148 202 KB\nFigure 14. The CDFs from Figure 13, all shifted to have have 0 expected yield, better illustrating how variability changes.\nThe SD is illustrative when discussing how the shape of the distribution affects risks. But the SD (or variance) is insufficient for capturing the full impact of variability for the risk-averse staker. The higher-order moments of the distribution also matter. In particular, a positive skew is favorable. In this regard, Ethereum’s yield distribution is certainly better than its inverse, where there would be a small risk of losing everything (although the prospect of slashing indeed leads to such a risk). The worst-case scenario for honest and attentive stakers is thus an important feature.\nSolo stakers may in reality be worse affected at the same SD when the expected yield is lower. As a simplified example, say that solo stakers are some fixed proportion of all stakers at any deposit size when there is no variability in rewards, and that the supply curve rises linearly. Then, if the expected yield is 2 % and can vary uniformly between 1-3 %, half of the solo stakers would need to account for the risk of receiving a yield below their reservation yield over a year. If the expected yield is 5 % but can vary between 4-6 %, the proportion affected is 1/5. Figure 15 accounts for such relative effects, instead normalizing by dividing each distribution by the ratio between its mean and the mean at F=64𝐹 =64 (“scale-normalized”). This preserves the relative standard deviation (RSD) of the distribution, computed as SD/mean yield (mathematical notation: \\sigma/\\mu𝜎/𝜇). From such a perspective, variability for solo stakers certainly starts to degrade already around F=32𝐹 =32, and more so at F=16𝐹 =16. But this is just one viewpoint on the matter, both the SD and RSD convey something important about the solo stakers’ conditions.\nFigure 152082×1148 215 KB\nFigure 15. The CDFs from Figure 13, all “scale-normalized” (\\sigma/\\mu𝜎/𝜇) to have the same expected yield. This preserves the relative standard deviation.\n4.4 Variability with fixed demand and varied supply\nAnother interesting perspective is to vary D𝐷 while keeping the reward curve fixed, thus computing variability across demand. This allows us to study equilibrium distributions, where each one is the result of a different supply curve. From a consensus developer’s perspective, this is a very important viewpoint and will be the focus going forward in this post. It is easier to control the shape of the demand curve (particularly after MEV burn), as opposed to the supply curve. Figure 16 shows CDFs capturing yield variability for the current reward curve at various deposit sizes. At 110M ETH staked (black line) almost half the validators will neither propose blocks nor sync-attest over the year at equilibrium (vertical line segment). The impact of special duties at such a high deposit size is indeed interesting to note. Being selected to the sync-committee gives almost as much issuance yield as attesting correctly over the full year (78 %, regardless of reward curve). But an equilibrium at D=𝐷 = 110M ETH requires that the marginal staker has a reservation yield below 2% at the prevailing level of REV, which seems rather unlikely for the near future.\nFigure 162082×1145 204 KB\nFigure 16. Solo staker yield variability at various deposit sizes under the current issuance policy.\nStill, as implied by the shift-normalized distributions in Figure 17, the SD decreases with an increase in deposit size, keeping F𝐹 fixed. This happens because the higher frequency of selection for special duties at lower deposit sizes serves to differentiate validator outcomes. Also remember that the standard deviation is computed after first subtracting the mean.\nFigure 172082×1148 182 KB\nFigure 17. Solo staker yield variability at various deposit sizes under the current issuance policy, with CDFs shifted such that the expected yield is 0.\nWhen it comes to the RSD, it is kept relatively fixed across D𝐷 under the medium-run equilibrium, as indicated by the scale-normalized CDFs in Figure 18. This is opposed to the SD which is more or less fixed across F𝐹 at the same D𝐷.\nFigure 182082×1148 184 KB\nFigure 18. Solo staker yield variability at various deposit sizes under the current issuance policy as in Figure 16, but with CDFs scaled to have the same expected yield.\nIf F𝐹 is reduced to 32, the equilibrium deposit size will fall. Ignoring this, Figure 19 shows the distributions at the same fixed D𝐷 as previously. The yield at 110M ETH staked is then just above 1%, and the unlucky solo stakers with no assignment only receive around 0.7 %.\nFigure 192082×1145 199 KB\nFigure 19. Solo staker yield variability at various deposit sizes when F𝐹 is reduced to 32.\n4.5 Two-dimensional mappings of solo-rewards variability\nIt can be clarifying to map the previously investigated variabilities across two dimensions, to visualize how variability changes for solo stakers across the potential equilibria. The mappings in this subsection were done by simulating solo staker’s yearly yield 10M times (sampling REV with replacement), repeated across 10^5105 different deposit sizes and 32 different settings for F𝐹. The experiment was then repeated 10 times, and the measurements combined by taking the average variances. This setup was used for handling memory load since the final matrix is computed from 320 trillion simulated solo staking outcomes. Smoothing was applied across variance and mean, using a Hann window of width 1101 (across D𝐷) and height 5 (across F𝐹). The matrix was initially computed across a wider range than plotted to allow for such smoothing without artifacts. Finally, the matrix was upsampled across F𝐹.\nFigure 20 shows how the SD varies across D𝐷 (all the way up to 120M ETH) and F𝐹. A lower SD is better. The base reward factor has but a minuscule effect on the SD at any specific deposit size, because issuance level shifts the yield rather equally for everyone.\nFigure 201908×1243 146 KB\nFigure 20. Standard variation in yield over a year of solo staking, plotted across F𝐹 and D𝐷.\nThe same outcome can be observed with staking yield on the y-axis in Figure 21. To produce this graphical representation, the simulated outcome from the previous plot was simply interpolated onto the new axes. One supply curve is dashed for easier connection to the next plot.\nFigure 211945×1261 269 KB\nFigure 21. Standard variation in yield over a year of solo staking, plotted across y𝑦 and D𝐷.\nSince the quantity of stake supplied increases with a higher yield, the reality is that a higher F𝐹 will produce a lower standard deviation in rewards under equilibrium. Figure 22 captures the equilibrium SD across F𝐹 for the two modeled supply curves (equilibria for the lower are dashed). Thus under these assumptions, lowering F𝐹 will indeed increase the equilibrium variability for solo staker while MEV burn is not in place. But the increase at 48 or even 32 is rather modest.\nFigure 222026×1009 73.3 KB\nFigure 22. The equilibrium standard deviation in yield over a year of solo staking, which changes with a change to F𝐹.\nRecall that another interesting perspective is the relative standard deviation (RSD), which captures the notion that a high standard deviation can be worse at a lower yield than at a higher yield. The RSD is depicted across F𝐹 and D𝐷 (lower is better) in Figure 23.\nFigure 231870×1243 237 KB\nFigure 23. Relative standard variation in yield over a year of solo staking across F𝐹 and D𝐷.\nFigure 24 instead captures the RSD across y𝑦 and D𝐷. When going by the RSD, a higher F𝐹 is clearly preferable, because it serves to push up yield in general, thus facilitating a higher equilibrium yield and lower RSD.\nFigure 241908×1261 131 KB\nFigure 24. Relative standard variation in yield over a year of solo staking, plotted across y𝑦 and D𝐷.\nArguably, the SD puts too much emphasis on variabilty and the RSD puts too much emphasis on the mean. Therefore, some measure in between these two seems appropriate for further modeling. Define the SSD as the standard deviation divided by the square root of the mean (\\sigma/\\sqrt{\\mu}𝜎/√𝜇). Lower is still better. The post will use this in-between measure as a guideline for mapping relative degradation for solo stakers across various reward curves. Figures 25-26 plot the SSD. Under the combined measure, if F𝐹 is kept fixed, a staking equilibrium at a higher D𝐷 gives a lower SSD. To make the issuance policy more “neutral” the reward curve can be designed to produce the same SSD under any supply curve.\nFigure 251908×1243 361 KB\nFigure 25. The SSD (\\sigma/\\sqrt{\\mu}𝜎/√𝜇), capturing variability in yield over a year of solo staking across F𝐹 and D𝐷 (lower is better).\nFigure 261920×1245 131 KB\nFigure 26. The SSD (\\sigma/\\sqrt{\\mu}𝜎/√𝜇), capturing variability in yield over a year of solo staking across y𝑦 and D𝐷.\n5. Towards a utility-maximizing reward curve\n5.1 A neutral reward curve\nHow then can a more “neutral” issuance policy, specifically a more neutral reward curve be constructed? Figure 27 plots the SSD across the reward curves with F=32𝐹 =32 and F=64𝐹 =64. In orange is a more neutral reward curve, preserving a set SSD at any equilibrium.\nFigure 272101×1397 139 KB\nFigure 27. Variation in SSD across D𝐷 for the current reward curve (black), the current reward curve but with F=32𝐹 =32 (dark green), and a reward curve that is more “neutral” with regard to the SSD (orange).\nThis reward curve is also neutral across D𝐷 concerning the proportion or rewards awarded to attesters, as shown in Figure 28 in the familiar plot against the attester proportion with y𝑦 and D𝐷 on the axes. It ensures that attestations will bring in around half of the yield at any deposit size.\nFigure 281920×1261 152 KB\nFigure 28. The proportion of staking yield derived from accurately performing attester duties (as opposed to proposer duties), with y𝑦 on the y-axis and D𝐷 on the x-axis (see also Figure 6). The neutral reward curve in orange retains y_a/y=0.5𝑦𝑎/𝑦 =0.5 across almost the full range.\nThe equation for the reward curve is\n\n\\begin{equation}\ny_i=\\frac{cF}{\\sqrt{D}+kD},\n\\end{equation}\n𝑦𝑖=𝑐𝐹√𝐷+𝑘𝐷,\nwith F=10^2𝐹 =102 and k=2^{-11}𝑘 =2−11. The difference to the current reward curve y_i=\\frac{cF}{\\sqrt{D}}𝑦𝑖 =𝑐𝐹√𝐷 is thus the addition of kD𝑘𝐷 in the denominator and a change to F𝐹. Yearly issuance Y_i𝑌𝑖 is y_i𝑦𝑖 distributed across D𝐷. The equation for issuance thus becomes\n\n\\begin{equation}\nY_i=\\frac{cF}{\\sqrt{D}+kD}D = \\frac{cF}{D^{-0.5}+k}. \n\\end{equation}\n𝑌𝑖=𝑐𝐹√𝐷+𝑘𝐷𝐷=𝑐𝐹𝐷−0.5+𝑘.\nThis makes it clear that the reward curve is in essence a log-logistic CDF, providing an issuance level asymptotically approaching cF/k𝑐𝐹/𝑘, as shown in Figure 29 that plots the yearly distributed rewards Y𝑌.\nFigure 292149×1261 157 KB\nFigure 29. Yearly distributed rewards Y𝑌 to stakers, with a reward curve that asymptotically approaches a fixed issuance level in orange.\nIn the associated thread, a functionally very similar log-logistic CDF was presented for the neutral reward curve: Y_i = \\frac{2^{19}\\sqrt{D}}{2^{13}+\\sqrt{D}}𝑌𝑖 =219√𝐷213+√𝐷 (i.e., Y_i = \\frac{2^{6}}{D^{-0.5}+2^{-13}}𝑌𝑖 =26𝐷−0.5+2−13). In this post, all new reward curves are instead presented in the same format as the current reward curve. The purpose is to introduce as little friction as possible to the mental models around what is changed when it comes to the reward curve, and how the different presented alternatives (including the current) relate to each other. This also minimizes the required changes to the Ethereum proof of stake consensus specification (“spec”). The variable c𝑐 emerges as rewards are distributed across the year. If not included, another variable must be introduced in the spec to compensate. Given the fixed constants of the spec, the relevant “base reward per increment” r_b𝑟𝑏 will be r_b=\\frac{\\sqrt{10^9}F}{\\sqrt{D}+x}𝑟𝑏 =√109𝐹√𝐷+𝑥, where x=kD𝑥 =𝑘𝐷 in the first example (this equation does not account for integer arithmetics and the actual constants and operations to be applied). Various alternative examples will now be shown that alter x𝑥 and sometimes F𝐹.\n5.2 Exploration of alternative reward curves\nThe orange curve achieves some form of neutrality in terms of variability and consensus balance. It implies that Ethereum should sacrifice the same level of utility degradation in these features whatever the deposit size is. But such neutrality may not actually be desirable. Some consensus imbalance or reward variability could be acceptable to temper the deposit size if it rises very high, since a high deposit size brings utility degradation in and by itself. Furthermore, providing some safety margin at a moderate deposit size may be preferable. Table 1 explores alternative reward curves, providing a few examples using the same format as previously specified. The reward curves have been divided into various types that describe the exponentiation of D𝐷 in the added term x𝑥 of the denominator.\n\nEquation for y_i𝑦𝑖\nAdded variable\nColor\nType\n\n\\frac{c\\times64}{\\sqrt{D}}𝑐×64√𝐷\n\nBlack\nR𝑅\n\n\\frac{c\\times32}{\\sqrt{D}}𝑐×32√𝐷\n\nDark green\nR𝑅\n\n\\frac{c\\times64}{\\sqrt{D}+kD}𝑐×64√𝐷+𝑘𝐷\nk=0.00015𝑘 =0.00015\nOrange (dashed)\nR_1𝑅1\n\n\\frac{c\\times64}{\\sqrt{D}(1+kD)}𝑐×64√𝐷(1+𝑘𝐷)\nk=2^{-25}𝑘 =2−25\nLime\nR_{1.5}𝑅1.5\n\n\\frac{c\\times48}{\\sqrt{D}+(kD)^2}𝑐×48√𝐷+(𝑘𝐷)2\nk=2^{-19}𝑘 =2−19\nPink\nR_2𝑅2\n\n\\frac{c\\times64}{\\sqrt{D}+kD+(k_2D)^2}𝑐×64√𝐷+𝑘𝐷+(𝑘2𝐷)2\nk=2^{-14}𝑘 =2−14, k_2=2^{-19}𝑘2 =2−19\nDark purple\nR_{12}𝑅12\n\n\\frac{c\\times64}{\\sqrt{D}+kD+(k_2D)^2}𝑐×64√𝐷+𝑘𝐷+(𝑘2𝐷)2\nk=2^{-13}𝑘 =2−13, k_2=2^{-20}𝑘2 =2−20\nDark purple (dashed)\nR_{12}𝑅12\n\nTable 1. Equations of issuance yield for potential reward curves. The current reward curve is specified in the first row, and various reward curves created by making small adjustments are specified in subsequent rows. The third column indicates the colors of the associated curves plotted in this section and the fourth a type classification.\nThe yearly distributed rewards under the prevailing level of REV for the reward curves of Table 1 are plotted in Figure 30. The reward curves of type R_1𝑅1 are orange in this post and have a term in the denominator that involves D𝐷, like the first neutral example. The orange dashed curve from the table however uses a relatively lower k𝑘, so it will not approach a fixed issuance as quickly. Lime-colored curves are denoted R_{1.5}𝑅1.5, since their equation can also be expressed as \\frac{cF}{\\sqrt{D}+kD\\sqrt{D}}𝑐𝐹√𝐷+𝑘𝐷√𝐷. Issuance for this curve will fall as D𝐷 rises, as shown in the figure. This helps Ethereum better moderate the quantity of stake once it becomes too high. An even stronger moderation is achieved by the R_2𝑅2-curves (pink), adding (kD)^2(𝑘𝐷)2 to the denominator. Finally, curves of type R_{12}𝑅12 (dark purple) are more versatile. The benefit of using two variables is that k𝑘 can be tuned to push down the issuance as desired around deposit sizes of around 30M ETH and k_2𝑘2 for pushing down the issuance at higher deposit sizes. Two variants with different focus are illustrated in the figure.\nFigure 302149×1261 209 KB\nFigure 30. Yearly distributed rewards Y𝑌 to stakers for the reward curves in Table 1.\nFigure 31 instead shows the outcome if REV is removed, for example via MEV burn, thus plotting only yearly issuance Y_i𝑌𝑖. As illustrated, the exemplified reward curves have been designed to give a quantity of stake well above D=𝐷 = 14M ETH under MEV burn with the hypothetical supply curves, and would bring about an equilibrium close to the desired range.\nFigure 312149×1302 227 KB\nFigure 31. Yearly issuance Y_i𝑌𝑖 to stakers for the reward curves in Table 1.\nFigure 32 shows the staking yield y𝑦 under these reward curves and prevailing level of REV. It will indeed fall quite low when D𝐷 is high. Figure 33 instead plots issuance yield y_i𝑦𝑖, which of course is lower since REV is not included.\nFigure 322101×1261 260 KB\nFigure 32. Staking yield y𝑦 of the reward curves in Table 1.\nFigure 332101×1302 266 KB\nFigure 33. Issuance yield y_i𝑦𝑖 of the reward curves in Table 1.\nTo provide a sense of how parameter settings influence the different curves, Figure 34 plots yearly issuance for each different type with alternative settings also included. Changes to parameters in curves not already specified (e.g., in Table 1) is indicated in the plot.\nFigure 342124×1730 397 KB\nFigure 34. Yearly issuance Y_i𝑌𝑖 to stakers for the reward curves in Table 1 (grouped by type), with alternative parameterizations also provided.\n5.3 Analysis of the alternative reward curves\nFigure 35 shows the attester’s proportion of the staking yield for the reward curves, this time having y_a/y𝑦𝑎/𝑦 directly on the y-axis for improved clarity. As evident, all of the analyzed reward curves will have some section with y_a/y>0.5𝑦𝑎/𝑦 >0.5. While the R_{1.5}𝑅1.5-curve (lime) indeed falls with a higher D𝐷, it is still kept above 0.5 for almost the entire range. One reason why this may be reasonable is that REV is not a fixed variable. It can very well rise quite a bit, something that is out of the control of consensus developers. If the aim is to keep the proportion of the yield awarded for attestations above 0.5, then some safety margin may be reasonable.\nFigure 352078×1302 187 KB\nFigure 35. Proportion of the staking yield provided for attestations (y_a/y𝑦𝑎/𝑦) under the current REV for the different reward curves of Table 1.\nFigure 36 instead shows the situation if REV was to double. In this scenario, Ethereum will be operating under a consensus mechanism where the proposers bring in more than half of the rewards with most of the analyzed reward curves. Factoring in potential future variation in REV lends weight to using a reward curve with a somewhat higher issuance level than the most restrictive example in pink. For example, the R_{1.5}𝑅1.5 curve in lime still gives above 1/3 (dashed thin line) of the yield to attesters if the REV were to double. There is also a Bayesian aspect to these considerations. It is more likely that the equilibrium quantity of stake is higher when REV is higher, here referring to the influence of the demand curve \\overline{y}――𝑦 on the equilibrium quantity of stake.\nFigure 362078×1302 193 KB\nFigure 36. Proportion of the staking yield provided for attestations (y_a/y𝑦𝑎/𝑦) if the REV were to double. As in Figure 35, the outcome is provided for the different reward curves of Table 1.\nFigure 37 shows the SSD for the analyzed reward curves. As can be expected, the SSD rises with an increase in D𝐷 for the reward curves that stipulate a falling issuance with an increase in D𝐷.\nFigure 372101×1166 183 KB\nFigure 37. Variation in SSD across D𝐷 for the reward curves of Table 1.\nFigure 38 takes a closer look at variability for solo stakers across D𝐷 under the restrictive pink reward curve. At D=𝐷 = 110M ETH (black line), the expected yield is around 0.5 %, and the unfortunate 45 % of stakers without special duties over the year earn just around 0.2 % in yield.\nFigure 382082×1145 206 KB\nFigure 38. Solo staker yield variability at various deposit sizes under the R_2𝑅2 reward curve of Table 1 (pink curve in figures).\nThe R_{1.5}𝑅1.5 reward curve (lime color) from previously is instead presented in Figure 39. The expected yield at D=𝐷 = 110M ETH is 0.65 % with solo stakers not assigned for special duties receiving 0.31 % under ideal performance. Of course, D=𝐷 = 110M ETH is not a likely medium-run equilibrium under either the R_2𝑅2 (pink) or R_{1.5}𝑅1.5 (lime) reward curve. Indeed it cannot even be reached for several years due to the churn limit. More interesting is probably to study the red and orange CDFs in the plot, representing the variability at D=𝐷 = 30M ETH and D=𝐷 = 50M ETH respectively. The expected yield at D=𝐷 = 50M ETH is 1.55 %. There are fewer unlucky solo stakers in this case; around 17 % of validators are not assigned to special duties over the year, and they then receive a yield of around 0.8 % under optimal performance. Note that since the supply curve is presumably upwards sloping, the equilibrium quantity of stake is lower with the lime-colored reward curve than under the current issuance policy. With the upper hypothetical supply curve from previously, the equilibrium is slightly below D=𝐷 = 30M ETH and with the lower supply curve it is slightly above D=𝐷 = 30M ETH. The red CDF is therefore a very reasonable outcome to consider, and as evident, the unlucky validators are here much better off and further in between.\nFigure 392082×1145 207 KB\nFigure 39. Solo staker yield variability at various deposit sizes under the R_{1.5}𝑅1.5 reward curve of Table 1 (lime curve in figures).\n5.4 Additional properties under consideration\nOne aspect not covered in this post is the minimum yield under which solo staking on an efficient setup is feasible. The protocol facilitates 32 ETH solo validators and should thus ensure that y𝑦 covers their minimum operational costs. Other outcomes seem pathological. Such considerations lend weight to providing some—albeit still very small—yield even at high D𝐷, so that economies of scale can never completely eliminate solo staking. These aspects will be further discussed in forthcoming analysis.\nWhen it comes to discouragement attacks, Buterin framed his early analysis around the variable p𝑝 from the equation for issuance yield of the current reward curve y_i = cFD^{-p}𝑦𝑖 =𝑐𝐹𝐷−𝑝, with p=0.5𝑝 =0.5. His paper discusses an idealized attack with a linearly rising supply curve (yield elasticity of supply equaling 1), and suggests that p>0.5𝑝 >0.5 would render the attack profitable. I would first like to note that once we consider that an attacker must also de-stake under the assumption that it operates under the same supply curve, the condition actually becomes p>1𝑝 >1. A deeper analysis will be provided in a future publication. However, these specific values for p𝑝 are not hard limits. First of all, they depend on the actual supply curve and frictions. More importantly, any analysis must be weighed against the fact that an attacker will indeed put its entire stake at risk of social slashing when executing the attack.\nGoing deeper, we can generalize p𝑝 to be the negated inverse issuance-yield elasticity of demand, hereinafter referred to as the “p_i𝑝𝑖-elasticity”. It is then easy to see following standard economics that an equivalent pointwise p_i𝑝𝑖-elasticity can be computed for any reward curve by relating the percentage change in deposit size \\Delta D/DΔ𝐷/𝐷 to a percentage change in issuance yield across the demand curve \\Delta y_i/y_iΔ𝑦𝑖/𝑦𝑖\n\n\\begin{equation}\np_i = -\\frac{\\Delta y_i/y_i}{\\Delta D/D}.\n\\end{equation}\n𝑝𝑖=−Δ𝑦𝑖/𝑦𝑖Δ𝐷/𝐷.\nFigure 40 plots p_i𝑝𝑖 for various reward curves analyzed in this post. I have long been in favor of a p_i𝑝𝑖-elasticity of 1 for moderating yield. The R_{1.5}𝑅1.5 curve (lime) will indeed cross p_i>1𝑝𝑖 >1, but only if D>2^{25}𝐷 >225, and it still remains moderate. If there is a targeting of a specific deposit size or deposit ratio, then p_i\\rightarrow\\infty𝑝𝑖 →∞ at longer time scales (red dashed line). Such practices make a system particularly fragile to discouragement attacks. There are ways to try to resolve this beyond the scope of this post. When including REV, the negated inverse elasticity will be pushed somewhat towards 1. I will provide a deeper analysis of discouragement attacks in two forthcoming papers.\nFigure 402076×1261 161 KB\nFigure 40. The negated inverse issuance-yield point-elasticity of demand (p_i𝑝𝑖) across D𝐷 for various reward curves analyzed in this post. Lower is better, but staying rather close to 1 should be perfectly acceptable.\nIt may be easier to find agreement on something like the lime or dashed purple curve. A middle ground that can be implemented under rough consensus is better than the status quo. This includes a middle ground of simply adjusting the base reward factor, perhaps even higher than F=32𝐹 =32, say to F=40𝐹 =40. Such a change could still be helpful, with the understanding that MEV burn is still in the cards and will naturally affect staking rewards as well. It is also important to not be too rigid in assumptions around the supply curve and future REV at this point; it is not yet known how these economic forces will develop.\nPushing for the more ambitious reductions in issuance such as from the pink curve may not be worth it. Presumably, some members of the staking community will not be very welcoming to such changes (or any changes for that matter). It becomes a matter here of communicating the utility gains for Ethereum of adhering to MVI also under proof of stake. After all, stakers own the underlying ETH, and may reasonably hope that utility gains for Ethereum make its native token more attractive. A fruitful discussion within the Ethereum community and further research would at this point be very welcome.\nVariability also depends on the frame of reference. Stakers may ultimately be more affected by fiat-denominated price fluctuations of the ETH token. The Sharp ratio, which is essentially the inverse of the RSD, would in reality be measured on a fiat basis today. But the relative frame of reference of keeping the analysis denominated in ETH is very helpful for clarifying how variables relate directly to each other. It isolates effects directly under a staker’s or developer’s control, which is important in staking economics.\n5.5 Potential candidate for a new reward curve\nProperties of a few different types of reward curves with various parameterizations have been presented. Among these, the R_{1.5}𝑅1.5 reward curve (lime in figures) with equation\n\n\\begin{equation}\ny_i = \\frac{cF}{\\sqrt{D}(1+kD)}\n\\end{equation}\n𝑦𝑖=𝑐𝐹√𝐷(1+𝑘𝐷)\nusing F=64𝐹 =64 and k=2^{-25}𝑘 =2−25 will here be highlighted as a potential candidate if Ethereum updates the issuance policy. Its equation for issuance is\n\n\\begin{equation}\nY_i = \\frac{cF\\sqrt{D}}{1+kD}.\n\\end{equation}\n𝑌𝑖=𝑐𝐹√𝐷1+𝑘𝐷.\nThe candidate reward curve has been designed to provide very clear mental models related to the reference point D=2^{25}𝐷 =225 (around 33.6M ETH), that has been highlighted as a point below which it is desirable to keep the deposit size. Specifically, at D=2^{25}𝐷 =225, the reward curve:\n\nInstitutes an exact halving of issuance relative to the current reward curve (both y_i𝑦𝑖 and Y_i𝑌𝑖). Each multiple of 2^{25}225, gives a further reduction to 1/3 and 1/4 respectively.\nReaches its peak issuance. If D>2^{25}𝐷 >225, the issuance will begin to fall (naturally, the issuance yield will always fall with a rise in D𝐷).\nLets the p_i𝑝𝑖-elasticity pass 1, and allows it to moderately rise with a rise in D𝐷.\nLets the proportion of the yield assigned for attestations begin to fall, but keeps it roughly above 0.5 at the current level of REV and above 1/3 across the full range if the REV was to double. This is a compromise between safety and MVI that attempts to balance the situation before MEV burn.\nLets the SSD begin to rise, but still ensures that it rises only moderately.\n\nThe reward curve also provides sufficient assurances of keeping D>14𝐷 >14 M ETH, both before and after MEV burn is in place.\nAs a proof of (1), the candidate reward curve provides a fraction of the issuance yield of the current reward curve of\n\n\\begin{equation}\n\\frac{\\frac{cF}{\\sqrt{D}(1+kD)}}{\\frac{cF}{\\sqrt{D}}}=\\frac{1}{1+kD}.\n\\end{equation}\n𝑐𝐹√𝐷(1+𝑘𝐷)𝑐𝐹√𝐷=11+𝑘𝐷.\nSince k=2^{-25}𝑘 =2−25, kD𝑘𝐷 becomes 1 at D=2^{25}𝐷 =225, and 2 at D=2\\times2^{25}𝐷 =2 ×225 etc.\nTo understand (2), first describe issuance as Y_i = \\frac{cF}{1/\\sqrt{D}+k\\sqrt{D}}𝑌𝑖 =𝑐𝐹1/√𝐷+𝑘√𝐷. The relevant critical point of the denominator can be determined by first computing its derivative\n\n\\begin{equation}\n-0.5D^{-3/2}+0.5kD^{-1/2}\n\\end{equation}\n−0.5𝐷−3/2+0.5𝑘𝐷−1/2\nand finding where it equals zero by multiplication with the least common multiplier 2D^{3/2}2𝐷3/2. This gives\n\n\\begin{equation}\nkD-1=0,\n\\end{equation}\n𝑘𝐷−1=0,\nand thus the condition is D=1/k=2^{25}𝐷 =1/𝑘 =225.\nNote that (3) and (4) follow directly from 2. To summarize, the candidate reward curve offers a balanced compromise that preserves adequate consensus incentives while trying to push Ethereum toward MVI. There is also a clear rationale behind its parameterization, something that may make it easier to unite on.\n6. Conclusion and discussion\nThe effect of issuance level on consensus incentives and reward variability was studied. When it comes to preserving correct consensus incentives, it is desirable to provide sufficient rewards to attesters relative to the rewards that proposers get, and to not let penalties become too low. Under the current reward scheme, this limits how much issuance can be reduced. Likewise, when considering reward variability for solo stakers, there are also good reasons to let issuance be a relevant proportion of all rewards, since it can be distributed with low variability.\nIt is important to recognize the need for formulating our issuance policy as derived from a set of tangible utility measures, providing a rationale for its implementation. Each deposit size can be assigned a maximum protocol utility issuance level. In the absence of a consensus redesign and/or introduction of a staking fee, that level is never too close to 0. But it is also important to not let issuance go above what is needed for retaining security—because that degrades utility for users. In a world without MEV or concern for the conditions of solo staking, designing our issuance policy would be a simpler affair. But MEV will imbalance consensus roles, produce variability, increase uncertainty and keep us from achieving MVI until we burn it. If we succeed in burning MEV, a staking fee discussed in Section 3 will presumably not be needed. If the endogenous yield is zero or negative, there are no direct incentives for staking. Implementing a staking fee at this point thus seems hard to motivate.\nWhile the protocol could allow information about the implied supply curve to influence issuance in the future (i.e., autonomous adjustments), such practices are currently not very beneficial when contemplating our strict dependency on MEV. Still, the impetus for tempering our issuance policy should be clear from previous writings on MVI. It is of course not desirable to incentivize users to (delegate) stake when there is no need for it. If Ethereum should temper issuance, the available options can essentially be divided into the three categor","tokens":15000,"squid":"spider-04","role":"Research Spider","at":1791346411161,"hash":"5e330863e662d9eda7ac33eb7e1b3fa8b665851d"}
{"url":"https://verified.jup.ag/faq","domain":"verified.jup.ag","title":"FAQ | VRFD","text":"FAQIn the permissionless world, anyone can mint a token and name it whatever they want. Verification adds a green checkmark next to your token to indicate that it is the canonical one, so that traders can find the right token easily.Additionally, the verified token list is integrated by many partners in the ecosystem from dexes to wallets to screeners, and it helps with discoverability and credibility of your token.Market CapReflects market sentimentOrganic ScoreAccounts for human trading activity, reducing influence of volume botsToken HoldersShows distribution of the tokenTicker UniquenessEnsures ease of identification for tradersValidationSocial support as measured by Smart Followers on XOnchain LiquidityReveals if the token is tradable onchainWe look holistically at a mix of factors including market cap, organic score, token holders, ticker uniqueness, onchain liquidity and a smart social score.As there are thousands of new tokens created on Solana daily, we are unable to verify every single one to keep the list useful. Most commonly, tokens are not verified because it is the duplicate of another token, has low trading activity or insufficient social proof.Verification adds a checkmark next to your token to indicate that it is the canonical one. It is not an endorsement of the project nor the team by Jupiter.Tags are not forever. As there are thousands of tokens created on Solana daily, we periodically prune the list and remove tags from tokens with low trading activity to keep the list useful.Jupiter kept the verified tokens list running as a free public resource for the last 4 years. It started out as a humble github repo that we maintained when the official Solana token registry was deprecated.As the ecosystem grew and the number of tokens exploded, PRs and merge conflict nightmares to the github repo made that untenable. We experimented with a community powered system in V2 that was too slow for the number of new tokens, and a V3 system with algorithmically derived scores that was quickly gamed by projects. After much real world testing, we arrived at V4, with a mix of signals from heuristics and manual approvals.The express lane guarantees a review within 24 - 48 hours and we recommend that you choose it when possible because of the backlog of tokens for the team to review.The express lane guarantees your token will be prioritized for review, and approvals are still subject to our review criteria listed above.If you believe that the reviewers missed out some context about your token and it should have been verified, please reach out to us via a support ticket at support.jup.ag and we will be right with you.As there are thousands of new tokens created on Solana daily, we are unable to verify every single one to keep the list useful. Most commonly, tokens are not verified because it is the duplicate of another token, has low trading activity or insufficient social proof.Tokens can be traded even when they are not verified, we pick up tokens as long as the token's pools have sufficient liquidity on the dexes we integrate. Tokens are prioritized by text similarity, volume and liquidity, which helps traders find the right token even when it is not verified. We also recommend that you display your token mint address prominently on your website, so your users can check that they are trading the right token.Have a question that's not addressed?","tokens":852,"squid":"spider-02","role":"Liquidity Spider","at":1791346429835,"hash":"127fa58c90a16ab6c4ffaa6b5dd3c4b1e1a9bd20"}
{"url":"https://support.jup.ag/","domain":"support.jup.ag","title":"Jupiter Support Hub","text":"ResourcesUser DocsGuides, tutorials, and how-tos for every Jupiter product.docs.jup.ag Developer DocsAPIs, SDKs, swap integration, and technical references.developers.jup.ag Jupiter AcademyStep-by-step tutorials to level up your DeFi skills.academy.jup.ag FAQsMore If you're buying a volatile token, the price may move between submission and execution. Jupiter's slippage protection cancels the swap to protect you. It should take no more than 3 tries. If you fail more than 3 times, open a ticket and Jupiter may compensate the gas.This typically means insufficient liquidity for the pair, a trade size too large or too small, or the token has trading restrictions. Try adjusting the amount and check whether the token has real liquidity on Solana DEXs.You may be eligible for compensation if: a bad quote was caused by bad routing, more than 3 consecutive trades failed (gas loss), or unreasonably high slippage (>20%) led to sandwich attacks. Jupiter only compensates Ultra Mode users and never compensates for potential P&L. Open a ticket (allow up to 3 days).Limit orders may fail due to extreme market volatility, low token liquidity, a rug pull (creator removed all liquidity), price movements too rapid for keepers, or slippage failures during settlement. For help, open a ticket.Recurring Orders may fail due to insufficient liquidity, price movements beyond acceptable slippage, network congestion, or technical issues with the tokens. Failed orders automatically retry at the next scheduled interval.Currently, you cannot set the exact amount of tokens you want to receive. The previous ExactOut option was removed because it often resulted in worse pricing compared to regular swaps.No. Jupiter does not currently support pausing and resuming Recurring Orders. If you need to stop, you must cancel the order and create a new one when ready.Jupiter couldn't refresh the latest route pricing, usually due to RPC node issues. The swap is blocked to prevent execution at a stale price. Try changing your RPC endpoint via the settings gear icon, refresh the page, and retry.There is no dedicated volume checker on Jupiter at this time. You can use the PnL feature at jup.ag/watch/positions to review your trading activity.Currently, only launchpads built on Meteora DBC are supported out of the box. If yours uses Meteora DBC, contact the team at support.jup.ag for listing. Custom launchpads on other technologies are not currently supported.View all Swap FAQs CommunityDiscordX (Twitter)YouTubeReddit","tokens":627,"squid":"spider-02","role":"Liquidity Spider","at":1791346439775,"hash":"877426e2eb6447667abd0d861db91c18514557e7"}
{"url":"https://developer.arbitrum.io/launch-arbitrum-chain/chain-config/validation/test-chain-configuration","domain":"developer.arbitrum.io","title":"Configure a test Arbitrum chain","text":"Configure your chainValidationConfigure a test Arbitrum chainConfigure a non-production Arbitrum chain so that assertions post and confirm in seconds rather than days, and understand which parameters differ on testnets.Request an updateOn a production Arbitrum chain, an takes about a week to confirm (6.4 days). That delay is the security model working as intended, but it makes integration testing impractical. This page covers how to shorten it on a chain you do not need to secure. It also covers which parameters differ on a testnet.\nThese values are unsafe for productionEvery value on this page trades security for speed. A chain configured this way offers no meaningful dispute window, so an incorrect can be confirmed before anyone has time to dispute it — and if the validator allowlist is disabled, any address can trigger that confirmation. Use these settings only on chains that hold no value.\nThis is not the same as fast withdrawals are a production feature that shortens confirmation on an chain by delegating confirmation to a committee, using the --node.bold.enable-fast-confirmation and --node.staker.enable-fast-confirmation flags. That is a deliberate trust assumption, configured separately, and it is not what this page describes. To learn how it works, see Fast withdrawals.\nWhat actually gates confirmation speed\nTwo independent layers govern how quickly an assertion confirms, and lowering only one has no effect:\n\nOnchain parameters set the floor. confirmPeriodBlocks determines how long an assertion must exist before the protocol confirms it, and minimumAssertionPeriod determines how frequently assertions may be posted at all. No node setting can go below these.\nNode intervals determine how promptly your acts within that floor. These are polling and cadence settings; they cannot shorten an onchain period.\n\nThe common mistake is lowering the node intervals alone, then concluding that the configuration did not work. If confirmPeriodBlocks still represents a week, confirmation still takes a week.\nOnchain parameters\nMost of these are set at deployment. As you can update confirmPeriodBlocks and minimumAssertionPeriod afterward through the Rollup admin interface, and on a legacy chain extraChallengeTimeBlocks as well. On a BoLD chain, challengePeriodBlocks is fixed when the challenge manager is deployed and challengeGracePeriodBlocks when the Rollup is initialized — neither has an owner setter, so plan them before you deploy. To learn what the production values are, see Challenge period and the BoLD parameter table.\nParameters that exist on both BoLD and legacy chains:\nParameterProduction referenceFor a test chainconfirmPeriodBlocks45,818 blocks, about one weekLow enough that a test can wait it outminimumAssertionPeriod75 blocks, about 15 minutesMust be below the posting interval you configure next\nBoLD chains only:\nParameterProduction referenceFor a test chainchallengePeriodBlocksUsually equal to confirmPeriodBlocksKeep equal to confirmPeriodBlocks; set at challenge manager deploymentchallengeGracePeriodBlocks48 hours of Ethereum blocksCan be reduced; it exists to give a security council time to intervene. Fixed at deployment\nLegacy (pre-BoLD) chains only:\nParameterFor a test chainextraChallengeTimeBlocksCan be reduced or set to 0\nAll block counts above are denominated in the 's block.number. On an Arbitrum parent, block.number tracks a bounded estimate of the underlying Ethereum L1 block number — not the Arbitrum chain's own block height — so one unit is still roughly 12 seconds for a chain settling to Arbitrum One or Nova. Only when the parent's block.number is its native height (Ethereum itself, or a local devnet) does the parent's own block time apply. To learn more, see Block numbers and time.\nThe interaction between minimumAssertionPeriod and the posting interval is the one that catches people. The two use different units — the posting interval is a duration, while minimumAssertionPeriod counts parent chain block.number units (on an Arbitrum parent, that is the underlying L1 block number, roughly 12 seconds per unit — see the note above). The validator enforces the onchain minimum itself: before posting, it checks how many of those block units have elapsed since the parent assertion and waits (logging Need to wait N blocks before posting next assertion) instead of submitting a transaction that would revert. If you lower the posting interval without lowering minimumAssertionPeriod to match, assertions do not stop or revert — they simply keep posting at the onchain floor's cadence. Lowering both is what makes posting faster.\nNode intervals\nThese are Nitro flags, set per validator. Lower them so your validator acts promptly inside the onchain floor you configured above.\nFlagDefaultApplies toFor a test chain--node.bold.assertion-posting-interval15m0sBoLD stakerLower it, keeping it above minimumAssertionPeriod--node.bold.assertion-scanning-interval1m0sBoLD stakerLower it to notice new assertions sooner--node.bold.assertion-confirming-interval1m0sBoLD stakerLower it to poll for confirmability more often--node.bold.minimum-gap-to-parent-assertion1m0sBoLD stakerLower it so consecutive assertions are not spaced out--node.staker.make-assertion-interval1h0m0sLegacy stakerLower it; no effect on BoLD chains--node.staker.staker-interval1m0sLegacy stakerLower it to check the Rollup status and act sooner--node.staker.confirmation-blocks12Legacy stakerLower it, or 0 on a chain where you accept risk\nLowering the confirming interval makes the validator check more often. It does not make confirmation permissible sooner — that is governed by confirmPeriodBlocks, plus challengeGracePeriodBlocks after a challenge. To learn more about that distinction, see Assertion timing flags.\nA worked example\nNitro's own test suite configures the legacy staker for maximum speed. These values come from TestL1ValidatorConfig in staker/legacy/staker.go:\nSettingTest valueDefaultstaker-interval10ms1m0smake-assertion-interval-1000h1h0m0sconfirmation-blocks012\nThe negative make-assertion-interval is intentional rather than a typo. The staker checks whether more than the configured interval has elapsed since the last assertion. A negative duration makes that check always pass, so the staker posts on every cycle without waiting.\nBoLD has no equivalent presetNitro defines no TestBoldConfig. On a chain, set the four --node.bold.* intervals individually rather than looking for a single test preset.\nWhy a test validator looks stuck when nothing is misconfigured\n--node.bold.rpc-block-number defaults to finalized, and the symptom depends on what your parent chain does with finality:\n\nThe parent chain never finalizes (common on local devnets). Requests for the finalized block fail with an RPC error such as finalized block not found, so the staker cannot initialize and the node fails startup with error initializing staker: could not create assertion chain: .... The intervals never come into play.\nFinality lags the tip. The validator reads a finalized view that trails recent activity. If the finalized head predates the Rollup contract's deployment, initialization fails with no contract code at given address; once the deployment is finalized, the validator acts on a stale view and appears idle until finality catches up.\n\nBoth read like an interval problem and are not one. Check this before tuning anything. To learn more, see Parent chain read consistency.\nOn a test chain, latest is usually the right value; safe helps only if your parent chain actually advances it. Both accept exposure that would be unacceptable in production.\nTestnet chains\nA chain settling to a public testnet such as Sepolia is not a local test chain. Its parent chain has real block times and real finality, so parent chain block counts convert the same way they do on mainnet, and a production confirmPeriodBlocks still means about a week.\nIf you want faster confirmation on a testnet-settled chain, you must lower the onchain parameters deliberately — settling to a testnet does not shorten them for you. Read the parameters from your Rollup contract rather than assuming they were reduced at deployment.How is this guide?Enable fast withdrawalsLearn to deploy Fast WithdrawalsAdditional configuration parametersReference list of additional CLI configuration parameters available when deploying or managing your Arbitrum chain.","tokens":2098,"squid":"spider-01","role":"Chain Spider","at":1791346439874,"hash":"7cd813ba79dd55ba8c15494cbc69820bcec4939c"}
{"url":"https://developer.arbitrum.io/launch-arbitrum-chain/chain-config/validation/bold","domain":"developer.arbitrum.io","title":"BoLD for Arbitrum chains","text":"Configure your chainValidationBoLD for Arbitrum chainsLearn how to integrate BoLD with your Arbitrum chainRequest an updatePUBLIC PREVIEW DOCUMENTThis document is currently in public preview and may change significantly as feedback is captured from readers like you. Click the Request an update button at the top of this document or join the Arbitrum Discord to share your feedback.\nLaunch status and key dates\n\nStatus: Generally available for all Arbitrum chains, including both L2s and L3s. Already live on and .\nArbitrum Sepolia Dec 11, 2024\nArbitrum One 09:00 ET (GMT-5) on Feb 12, 2025 \nArbitrum Nova 09:00 ET (GMT-5) on Feb 12, 2025 \n\ntldr;\n is an upgrade to the dispute protocol on that delivers both and core security benefits. As with all features on the Arbitrum stack, Arbitrum chains can adopt BoLD at their own discretion and on their own timeline. To upgrade to BoLD, it is required to upgrade both the Nitro node software and the Rollup's smart contracts on its .\nRecommended Adoption Path\nBoLD brings new security benefits to Arbitrum chains, regardless of whether their validators are permissioned or permissionless. These new security benefits include improved resistance to delay attacks and increased censorship resistance for L3s. We strongly recommend Arbitrum chains adopt Arbitrum BoLD to register these security benefits while keeping validation permissioned.\nWarningIt is strongly recommended that existing and prospective Arbitrum chains upgrade to use Arbitrum BoLD but keep validation permissioned because of the increased risks associated with allowing any entity to advance and the state of your chain. The risks are summarized below. Rigorous testing and research has been poured into the parameters chosen for Arbitrum One and so we cannot formally support or endorse use of permissionless Arbitrum BoLD in other configurations. Please note that when a chain upgrades to use Arbitrum BoLD, any withdrawals (to the parent chain) will be delayed by an additional . The default challenge period is 6.4 days. We recommend informing the teams of your timelines and intent to upgrade so adequate warning can be provided to your chain's users on the Arbitrum Bridge.\nBelow is a quick breakdown of the benefits of permissioned BoLD vs. permissionless BoLD for your :\n\nBenefits of adopting Arbitrum BoLD\nArbitrum BoLD enables an to be permissionlessly validated thanks to several key improvements to the existing dispute protocol. These key improvements benefit an Arbitrum chain even if is kept permissioned on a BoLD-enabled Arbitrum chain.\nBelow are some benefits for an Arbitrum chain that come with adopting Arbitrum BoLD—regardless of whether validation is kept permissioned or not:\nImproved resistance to delay attacks\nDisputes on a BoLD-enabled chain are resolved in a round-robin style format where disputes can be concurrently resolved. This is an evolution from the current dispute protocol, where challenges are resolved one-by-one. This evolution means that an upper time bound can be placed on all disputes such that a malicious actor cannot delay the chain indefinitely like they can today. Even when validation is kept permissioned, this upper time bound is critical to mitigating the risk of delay attacks by parties on the validator allowlist for an Arbitrum chain.\nBeing on the latest version of Arbitrum technology\nAdopting Arbitrum BoLD for your Arbitrum chain will require upgrading the Nitro node software and deploying a new set of contracts on your parent chain. While not specifically related to Arbitrum BoLD, it is always strongly recommended that Arbitrum upgrade and keep their chain on the latest stable releases of both Nitro node software and the relevant onchain contracts. This is critical to ensure your Arbitrum chain benefits from the latest security improvements and features that the Offchain Labs team is constantly churning out.\nSecured by interactive fraud-proofs\nArbitrum BoLD is not an upgrade to a different type of proving architecture and will continue to be secured with an interactive proving game between validators using fraud proofs. The same single-honest party assumption applies but now with strict improvements to security to the point where chains, like Arbitrum One, can be permissionlessly validated and have their state assertions be permissionlesly challenged.\nUse of your project's native token as the bonding asset to secure the chain\nArbitrum BoLD enables the chain owner to use any ERC-20 token on the parent chain as the bond for validators to participate in securing the network. By default, this token will be WETH for and we do not recommend that teams use alternative tokens as the bonding asset. For more information on the rationale, we recommend teams consult our documentation to understand why WETH was selected for Arbitrum One (and not ARB).\nIncreased censorship resistance for L3 Arbitrum chains\nToday, the force inclusion window is a fixed 24 hours. This force inclusion window exists to enable both users and validators to force-include their transactions and assertions on the parent chain, with a 24-hour delay, if the sequencer is offline or censoring transactions. Arbitrum BoLD's release will come with an optional Censorship Timeout feature that can automatically reduce the force inclusion time window if the parent chain or sequencer is maliciously censoring user transactions/assertions or the Sequencer goes offline. This massively benefits Arbitrum L3 chains (that settle to a BoLD-enabled parent chain) as it ensures the chain can advance with minimal UX degradation during periods of censorship. You can read more about how this feature works in the gentle introduction to BoLD.\nBy default, the Censorship Timeout feature is disabled because proper configuration depends on a variety of factors, including the posting frequency of the chain and which parent chain(s) an Arbitrum chain settles to. For example, both the maximum delay buffer and the threshold itself should both be higher than your chain's batch posting frequency, otherwise the Censorship Timeout feature will not work as.\nCaveats that come with adopting Arbitrum BoLD for permissionless validation\nArbitrum BoLD's implementation and specification have been thoroughly tested and audited. The upgrade to Arbitrum BoLD is not the subject of this section, but rather the caveats and nuances that come with whether to enable permissionless validation.\nWarningIt is strongly recommended that existing and prospective Arbitrum chains upgrade to use Arbitrum BoLD but keep validation permissioned because of the increased risks associated with allowing any entity to advance and challenge the state of your chain. The risks are summarized below. Rigorous testing and research has been poured into the parameters chosen for Arbitrum One and so we cannot formally support or endorse use of permissionless Arbitrum BoLD in other configurations.\nEnabling permissionless validation means that any entity can spin up a validator and open challenges to dispute invalid claims made by other validators on the network. This opens up an Arbitrum chain to the risk of spam and attacks by unknown and malicious entities. To mitigate this risk for Arbitrum One, a considerable amount of research and testing has been done to optimize the trade-offs between deterring attacks and managing the costs of defending Arbitrum for honest parties. This research includes carefully calculating all relevant bond sizes, challenge period durations, and relevant plans for operating the infrastructure. More information on this research can be found in the BoLD whitepaper. Below are a few examples of various risks that an Arbitrum chain will hold should they pursue permissionless BoLD:\nRisk of resource exhaustion attacks\nWhere malicious entities can acquire and use more resources than honest parties can put together during a challenge. Such an attack can take many forms and includes both onchain and offchain computational/infra costs. For example, a well-coordinated attack on an Arbitrum chain could overwhelm honest parties if the malicious actors can spend more gas and computational power and acquire more of the bonding asset than the defenders can. This risk can be mitigated by a combination of high bond sizes, use of a price-independent bonding asset, use of a bonding asset with high liquidity, strong economic guarantees that attackers will lose most of their resources, sufficiently long challenge periods, and robust infrastructure operations and resources that can respond and scale up when necessary. More information on resource exhaustion attacks and how Arbitrum BoLD's design accounts for this risk can be found in Section 6.1.4 of the BoLD whitepaper. We recommend teams consider a resource exhaustion ratio greater than 5 assuming very high gas costs (like 100 gwei/gas).\nIncreased infrastructure costs and overhead\nRelated to, and expanding on, the above point about resource exhaustion attacks, the honest parties operating active validators and proposers for a BoLD-enabled chain will need to be ready to vertically scale their infrastructure, and cover the offchain costs of doing so, in the event of an attack. This is because a malicious actor may choose to spam and overwhelm the honest defenders with multiple challenges. Making moves, honest or malicious, costs resources to perform bisections on history committments down to a single step of execution. If this happens, each malicious challenge must be met with an honest counter-challenge during the interactive game. Arbitrum chains who decide to adopt Arbitrum BoLD in permissionless mode are strongly encouraged to work with their Rollup-as-a-Service () team to: deploy robust monitoring for challenges, set aside a budget to vertically scale up infrastructure and fund counter-challenges, and have an incident response plan drafted and rehearsed to ensure prompt and decisive reactionary steps in the event of an attack.\nRisks to liveness or delays of the chain\nIf the bond sizes are set too low, an adversary can cheaply create a challenge and delay confirmation of an assertion for up to an entire extra challenge period if they can censor honest BoLD moves. Remember that challenges, while time-bound, still take time to complete. Delaying the confirmation of assertions for a chain could negatively impact the chain in many ways that an attacker could benefit from (e.g., profiting from price volatility and price impacts on the Arbitrum chain's token may make delaying the chain worthwhile for an attacker). We recommend teams set bond sizes to be much greater than the opportunity cost of a week of delay, based on your chain's TVL (e.g., if your chain's TVL is $1B, then the opportunity cost of $1B should be used as a floor for the block level bond amount size). We further recommend that the bonding token used is highly liquid on the parent chain and relatively non-volatile.\nConclusion for Arbitrum chains considering BoLD Permissionless Validation\nDue to the uniquely different tokenomics, sizes, and varying types of Arbitrum chains deployed (or in active development) today, does not provide a \"one-size-fits-all\" recommendation for how best to safely set up and enable permissionless validation for Arbitrum chains. Instead, we recommend teams adopt Arbitrum BoLD but keep validation permissioned.\nShould Arbitrum chain teams strongly desire to adopt Arbitrum BoLD in permissionless mode, we do not endorse using configurations that differ from those on Arbitrum One. We especially do not recommend teams use custom ERC-20 tokens as the bonding asset and/or with low bond minimums. If your team would like to have permissionless validation for your Arbitrum chain, please reach out to us via this form so that we can schedule some time to understand your needs better.\nHow to adopt Arbitrum BoLD\nAs mentioned earlier, the upgrade to the dispute protocol involves both a Nitro node software upgrade and the deployment/upgrade of new smart contracts on your Arbitrum chain's parent chain.\nTo read more about Arbitrum BoLD, please refer to the Gentle Introduction for BoLD.\nWarningThe recommendation is to keep Arbitrum chains validation permissioned by having disableValidatorWhitelist be false (which is the default) and by having a list of validators on the allowlist via the validators[] array. Furthermore, we recommend keeping the Censorship Timeout feature disabled.\nThis is not an ArbOS upgradeEnabling BoLD in your chain involves updating your chain's Nitro contracts and ensuring that your nodes are running the expected minimum (or higher) version.However, enabling BoLD does not require upgrading your ArbOS version.\nThis how-to provides step-by-step instructions for Arbitrum chain operators who want to enable BoLD on their chain. Familiarity with Nitro, BoLD, and chain ownership is expected.\nOverview\nTo enable BoLD in your Arbitrum chain, you'll have to perform these actions:\n\nMake sure your nodes are running at least Nitro v3.5.4 and enable the required parameters after the upgrade\nUpgrade your Nitro contracts to v3.1.0\n\nLet's dive into it:\n1. Upgrade your nodes to Nitro v3.5.4 or higher\nBefore updating the contracts, make sure your nodes are ready for the update. Nitro v3.5.4 introduced compatibility with pre-BoLD and BoLD chains to ensure a smooth upgrade, but Nitro v3.6.2 has many recommended improvements. Nodes will automatically detect whether the chain is running pre-BoLD or BoLD Rollup and challenge contracts and will perform the appropriate calls depending on that check.\nMost of the parameters used in Nitro before v3.5.4 will stay the same when running a higher version but, depending on the type of node, you'll have to include a few more BoLD-specific parameters after the upgrade:\n\nFor validator nodes: add --node.staker.strategy=<MakeNodes | ResolveNodes | Defensive> (--node.bold.strategy is deprecated and only available before Nitro v3.8.0) to configure the validator to create and/or confirm assertions in the new Rollup contract (find more information in How to run a validator)\nFor all other types of node before Nitro v3.6.0: add --node.bold.enable=true to enable watchtower mode\nFor all other types of node after Nitro v3.6.0: watchtower mode is automatically enabled\n\nAdditionally, after performing the upgrade, the --chain.info-json object also needs to be modified:\n\nUpdate the new Rollup address in the rollup.rollup field\nAdd the bond token in a new rollup.stake-token field\n\n2. Upgrade your Nitro contracts to v3.1.0\nThis section explains how to upgrade your chain contracts to v3.1.0; this guide follows the same steps outlined in the 3.1.0 upgrade guide in the chain-actions repo.\nNote that this process expects your chain to use the canonical contracts. If your chain uses customized contracts, you might need a different updating script/contract than the one available.\nDuring the upgrade operation, the following actions will be performed:\n\nUpgrade the Bridge, Inbox, RollupEventInbox, Outbox, and SequencerInbox contracts to v3.1.0\nDeploy the new v3.1.0 BoLD ChallengeManager\nMigrate the v2 Rollup contract into a new v3.1.0 Rollup contract address\nSet up the Rollup contract according to the new configuration and use the latest confirmed assertion on the old Rollup as the genesis of the new Rollup\n\nStep 0: Pre-requisites\nTo effectively upgrade your Nitro contracts using the BoLD upgrade action, your contracts must be in one of these versions:\n\nInbox: v1.1.0 - v2.1.3 inclusive\nOutbox: any\nSequencerInbox: v1.2.1 - v2.1.3 inclusive\nBridge\n\neth chain: v1.1.0 - v2.1.3 inclusive\ncustom-fee token chain: v2.0.0 - v2.1.3 inclusive\n\nRollupProxy: v1.1.0 - v2.1.3 inclusive\nRollupAdminLogic: v2.0.0 - v2.1.3 inclusive\nRollupUserLogic: v2.0.0 - v2.1.3 inclusive\nChallengeManager: v2.0.0 - v2.1.3 inclusive\n\nTo determine the exact version your contracts use, follow these instructions.\nStep 1: Clone the nitro-contracts repository and build the contracts\nYou'll use a BOLDUpgradeAction.sol contract in the nitro-contracts repository to perform the upgrade operation.\nFirst clone the nitro-contracts repository and checkout the appropriate version:\n$ git clone https://github.com/OffchainLabs/nitro-contracts.git\n$ cd nitro-contracts\n$ git checkout v3.1.0-scripts\nOnce you have the correct version, install the dependencies and build the contracts:\n$ yarn install\n$ yarn build:all\nStep 2: Configure your chain parameters\nThe BoLD upgrade action contract that performs the upgrade will need to include your chain information as parameters. To set this configuration, copy the scripts/files/configs/custom.ts file and adjust the configuration to match that of your chain.\nStep 3: Prepare and deploy the upgrade contract\nYou'll now prepare the upgrade contract with the parameters you just set and then deploy it in the parent chain of our chain.\nFirst, create a .env file based on the .env-sample file.\n$ cp .env-sample .env\nEnsure you update the CONFIG_NETWORK_NAME env variable to match the filename of the configuration file you created in the previous step.\nCONFIG_NETWORK_NAME=custom\nNow, you can run the prepare script to deploy the action contract with the specified configuration parameters. Note that:\n\nYou can use any account to deploy the contract, so L1_PRIV_KEY does not necessarily need to be the chain owner.\n\nThe network parameter should be your parent chain. You can find the identifiers of these networks in the hardhat.config.ts. Note that if your parent chain is an L1, you'll have to configure an additional INFURA_KEY env variable for its endpoint.\n\n$ L1_PRIV_KEY=xxx yarn script:bold-prepare --network {mainnet|arb1|nova|base|sepolia|arbSepolia}\n\n...\nDeployed contracts written to: `scripts/files/sepoliaDeployedContracts.json`\nDone.\nOptionally, the script can try to verify the deployed contracts by adding the following parameters:\n\nSet DISABLE_VERIFICATION to false.\nUse the correct key for verifying the contracts on the block explorer depending on your parent chain: ETHERSCAN_API_KEY | ARBISCAN_API_KEY | NOVA_ARBISCAN_API_KEY | BASESCAN_API_KEY.\n\n$ L1_PRIV_KEY=xxx DISABLE_VERIFICATION=false ARBISCAN_API_KEY=xxx yarn script:bold-prepare --network {mainnet|arb1|nova|base|sepolia|arbSepolia}\n\nNoteYou can use any account to deploy the contract, so L1_PRIV_KEY does not necessarily need to be the chain owner.\nStep 4: Gather the information of the current state of the chain\nThe next script will gather information about the chain's current state (the last confirmed assertion), allowing you to initialize the new Rollup contract with that confirmed assertion. We recommended stopping all validators at this point to prevent them from confirming new assertions that might block the upgrade in the next step.\nLast confirmed assertionAs mentioned, this script will try to find the last confirmed assertion of your chain. Please note that:\nIf a new assertion is confirmed between Steps 4 and 5, step 5 will revert and Step 4 must be repeated.\nThe script looks for the NodeCreated event of the last confirmed assertion in the last 100,000 blocks. If the NodeCreated event was emitted in an older block, it won't be able to find it.\n\nUpgrades executed by a multisig or security councilIf Step 5 requires signatures that take hours or days to collect, you do not need to keep validators stopped for that entire period. The payload your signers approve does not encode assertion data, so you can refresh the lookup this script populates at any point before execution without invalidating collected signatures. To learn how to sequence this, see the BoLD upgrade playbook.\n\n$ L1_PRIV_KEY=xxx yarn script:bold-populate-lookup --network {mainnet|arb1|nova|base|sepolia|arbSepolia}\n\n...\nDone.\nNote that:\n\nYou can use any account in this step to call the contract, so L1_PRIV_KEY does not necessarily need to be the chain owner's.\n\nStep 5: Run the upgrade script\nYou are now ready to perform the upgrade. The following script will either perform the upgrade directly or print the upgrade payload depending on the private key used:\n\nIf L1_PRIV_KEY is the chain owner's, the script will perform the upgrade directly. Note that it will not ask for before sending the transaction.\nIf L1_PRIV_KEY is NOT the chain owner's, the script will print the upgrade payload.\n\nWarningThe following script will send the upgrade directly if the L1_PRIV_KEY specified is the private key of the chain owner. Please note that the script does not ask for confirmation.\n$ L1_PRIV_KEY=xxx yarn script:bold-local-execute --network {mainnet|arb1|nova|base|sepolia|arbSepolia}\nupgrade executor: 0x5FEe78FE9AD96c1d8557C6D6BB22Eb5A61eeD315\nexecute(...) call to upgrade executor: 0x1cff79cd000000000000000000000000f8199ca3702c09c78b957d4d820311125753c6d2000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000a4ebe03a93000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000000030000000000000000000000008a8f0a24d7e58a76fc8f77bb68c7c902b91e182e00000000000000000000000087630025e63a30ecf9ca9d580d9d95922fea6af0000000000000000000000000c32b93e581db6ebc50c08ce381143a259b92f1ed00000000000000000000000000000000000000000000000000000000\nStep 6: Update your nodes' configurations and restart them\nAs stated at the beginning, you need to add a few parameters to your node configuration for it to support BoLD:\n\nFor validator nodes: add --node.staker.strategy=<MakeNodes | ResolveNodes | Defensive> (--node.bold.strategy is deprecated and only available before Nitro v3.8.0) to configure the validator to create and/or confirm in the new Rollup contract (find more information in How to run a validator)\nFor all other types of node before Nitro v3.6.0: add --node.bold.enable=true to enable watchtower mode\nFor all other types of node after Nitro v3.6.0: watchtower mode is automatically enabled\n\nAdditionally, the --chain.info-json object also needs to be modified:\n\nUpdate the rollup.rollup field to point at the new Rollup contract address\nAdd a new rollup.stake-token field with the address of the bond token contract\n\nAfter updating the configuration, restart your node.\nValidator nodes shutdownWhen enabling BoLD on a validator, it will default to read only finalized information from its parent chain. If you run your node before the blocks that contain the upgrade transactions are finalized, the node will stop with the following message:error initializing staker: could not create assertion chain: no contract code at given addressIn this case, wait until those blocks finalize, then start your node again.\nStep 7: Monitor the validation process\nOnce the upgrade executes, monitor assertions to ensure they are created and confirmed in the new Rollup contract. Note that the new events emitted are AssertionCreated (which should appear every time an assertion is posted, by default this is 15 minutes) and AssertionConfirmed (which should only appear after a challenge period has elapsed, by default this is seven days).\nIf assertions don't appear, or your validators fail to start or bond on the new Rollup contract, see Validator troubleshooting.\nTable of Arbitrum BoLD parameters\nThe following configuration parameters can be applied when deploying or managing your Arbitrum chain. For an example of a configuration, feel free to reference this sample configuration in our guide on how to upgrade your chain to use BoLD.\nParameterDescriptionRecommended defaultexcessStakeReceiverThe address that confiscated bonds will be sent to. Bonds are confiscated from malicious actors who dispute and lose the interactive fraud proof gameThe chain owner's addresschallengeGracePeriodBlocksAmount of time to wait before a challenge period formally expire to allow for the chain owner or security council to intervene to ensure correctness of an assertion48 hours worth of Ethereum blocks for an L2 Arbitrum chain (settling to Ethereum) or an L3 Arbitrum chain settling to Arbitrum One or Arbitrum Nova. If the chain settles to a different type of parent chain, you must use its parent chain's block.number timingconfirmPeriodBlocksThe amount of time that an assertion must exist on the parent chain before it can be confirmed by the protocol, measured using the parent chain's block.number timing7 days worth of Ethereum blocks for an L2 Arbitrum chain (settling to Ethereum) or an L3 Arbitrum chain settling to Arbitrum One or Arbitrum Nova. If the chain settles to a different type of parent chain, you must use its parent chain's block.number timingchallengePeriodBlocksThe amount of time that a layer zero edge (otherwise known as a root/refinement node) needs to have accumulated to be confirmed. Usually the same as the confirmPeriodBlocks, measured in the number of parent chain block.number timing7 days worth of Ethereum blocks for an L2 Arbitrum chain (settling to Ethereum) or an L3 Arbitrum chain settling to Arbitrum One or Arbitrum Nova. If the chain settles to a different type of parent chain, you must use its parent chain's block.number timingstakeTokenAddress for the token, on the parent chain, to be used by a validator to become an assertion proposerWETHstakeAmtThe minimum amount of the stakeToken required for a validator to become an assertion proposer. Please consult the Economics of Disputes page to learn more about how to think about setting this value for your chain in a permissionless setting (not recommended)1 WETHminiStakeAmountsAn array of the required amounts of the stakeToken for each level of the interactive dispute game. There are three levels to BoLD where participants must dispute assertions down until there is only a single step of execution to prove on Ethereum (to determine a winner)[0, 1, 1] WETHchainIdYour chain's IDYour chain's IDminimumAssertionPeriodThe minimum amount of time that a validator must wait before posting a new assertion, measured using the parent chain's block.number timing15 minutes worth of Ethereum blocks for an L2 Arbitrum chain (settling to Ethereum) or an L3 Arbitrum chain settling to Arbitrum One or Arbitrum Nova. If the chain settles to a different type of parent chain, you must use its parent chain's blocks in the calculationvalidatorAfkBlocksThe validator whitelist is removed if this amount of time elapses and no assertions are confirmed by the protocol on the parent chain. This parameter is ignored if the disableValidatorWhitelist is true, indicating that there is no whitelist28 days (4 weeks) worth of Ethereum blocks for an L2 Arbitrum chain (settling to Ethereum) or an L3 Arbitrum chain settling to Arbitrum One or Arbitrum Nova. If the chain settles to a different type of parent chain, you must use its parent chain's blocks in the calculationdisableValidatorWhitelistEnables or disables the validator whitelist - effectively toggling between permissioned and permissionless BoLD. It is highly recommended that this value be set to false. More information can be found in the BoLD adoption for Arbitrum chains guide.falseblockLeafSizeMaximum number of blocks between assertions. It is not recommended to change this value.2^26bigStepLeafSizeMaximum number of steps in the \"big step\" level history committment. The product of bigStepLeafSize, smallStepLeafSize, and numBigStepLevel should equal to the maximum number of WAVM opcodes theoretically possible in the execution of an Arbitrum block, with a small buffer. It is not recommended to change this value.2^19smallStepLeafSizeMaximum number of steps in the \"small step\" level history committment. The product of bigStepLeafSize, smallStepLeafSize, and numBigStepLevel should equal to the maximum number of WAVM opcodes theoretically possible in the execution of an Arbitrum block, with a small buffer. It is not recommended to change this value.2^23numBigStepLevelNumber of \"big step\" levels. It is not recommended to change this value.1maxDataSizeMaximum size of data that can be posted onto the parent chain, in KB117964 for L2s, and 104857 for L3sisDelayBufferableA parameter to enable or disable the delay buffer, otherwise known as the Censorship Timeout feature.falsebufferConfig.maxThe maximum amount of time that the delay buffer can be. More information on how the delay buffer value changes over time and how it is used to calculate the force inclusion window can be found here.2^32—note that this configuration value is measured using Ethereum blocks for an L2 Arbitrum chain (settling to Ethereum) or an L3 Arbitrum chain settling to Arbitrum One or Arbitrum Nova. If the chain settles to a different type of parent chain, you must use its parent chain's block.number timing. It is recommended that you set this value to be higher than the batch posting frequency of your chain and ideally higher than the bufferConfig.threshold of your chain.bufferConfig.thresholdThe minimum amount of time that the force inclusion window can be reduced to, in the case of prolonged sequencer censorship and/or unexpected sequencer outages. The delayBuffer, starting from bufferConfig.max, is decremented by the difference between a delayed message's delay beyond bufferConfig.threshold so it is important to set the threshold to some value greater than the regular batch posting frequency of your chain and also greater than delayBlocks on your chain2^32—note that this configuration value is measured using Ethereum blocks for an L2 Arbitrum chain (settling to Ethereum) or an L3 Arbitrum chain settling to Arbitrum One or Arbitrum Nova. If the chain settles to a different type of parent chain, you must use its parent chain's block.number timing. It is recommended that you set this value to be higher than batch posting frequency of your chain, but lower than the delayBlocks of your chain.bufferConfig.replenishRateInBasisThe rate at which the delay buffer will replenish linearly500 (or 5% replenishment rate), meaning that one minute will be replenished for every 20 minutes where there are no messages delayed beyond bufferConfig.thresholdvalidatorsAn array of addresses that are allowed to post assertions to the parent chain, when BoLD is in permissioned mode (i.e., when disableValidatorWhitelist is false)The list of whitelisted validators allowed to progress the chain (by regularly posting assertions to the parent chain)How is this guide?Assertion controlLearn how to configure assertion control.Bond and validator configurationsLearn how to configure your Arbitrum chain with a custom bond and validator configurations","tokens":7630,"squid":"spider-01","role":"Chain Spider","at":1791346453864,"hash":"5b29270db3f0f530a68ab0077e09a5a278fb483d"}
{"url":"https://developer.arbitrum.io/launch-arbitrum-chain/chain-config/validation/bond-and-validator","domain":"developer.arbitrum.io","title":"Bond and validator configurations","text":"Configure your chainValidationBond and validator configurationsLearn how to configure your Arbitrum chain with a custom bond and validator configurationsRequest an update chains are customizable Layer 3 (L3) chains that settle to an Arbitrum Layer 2 () chain, such as Arbitrum One. They support configurations to ensure chain security through bonding and assertion challenges. Validators post assertions about the chain's state on the parent L2 chain and can incorrect assertions. can be permissioned, meaning validators must be allowlisted. For chains that use that elect to use the BoLD protocol, is an option (BoLD also supports permissioned validation).\nBonding is required for active validation, where validators place bond funds to participate. If a validator loses a challenge (e.g., due to a faulty assertion), their bond is escrowed or burned. Configurations such as the stakeToken, baseStake, and loserStakeEscrow are configurable during chain deployment or post-deployment via contract calls.\nArbitrum chains may utilize the (Bounded Liquidity Delay) protocol for efficient dispute resolution, which affects bonding tokens (e.g., WETH for BoLD-enabled chains like Arbitrum One/Nova, or ETH/native for other chains).\nstakeToken\nThe bonded token is the asset that validators must bond to participate in asserting the chain's state on the parent L2 chain. It serves as collateral for challenges. A bonded token can be WETH or the native token.\nConfiguration details\n\nCan be ETH (native gas token) or any ERC-20 token.\nFor BoLD-enabled chains (e.g., settling to Arbitrum One or Nova), it defaults to WETH.\nFor non-BoLD chains, it defaults to the 's native token (usually ETH).\nCurrently, its value is often hardcoded to ETH in basic deployments, but customizable to an ERC-20 contract address in advanced setups. Future updates will expand ERC-20 support.\n\nHow to configure\n\nPrepare the chain configuration:\nGenerate the base chain config using prepareChainConfig. Set the chainId and initial owner.\nimport { prepareChainConfig } from '@arbitrum/chain-sdk';\n\nconst chainConfig = prepareChainConfig({\n chainId: 123456, // Replace with your desired chain ID\n arbitrum: {\n InitialChainOwner: '0xYourOwnerAddressHere', // Wallet address that will own the chain\n DataAvailabilityCommittee: false, // Set to true for AnyTrust chains (DAC)\n },\n});\n\nSet up the public client for the parent chain:\nCreate a public to interact with the parent chain.\nimport { createPublicClient, http } from 'viem';\nimport { sepolia } from 'viem/chains'; // Example: Use 'mainnet' or 'arbitrumOne' as needed\n\nconst parentChainPublicClient = createPublicClient({\n chain: sepolia, // Replace with your parent chain (e.g., arbitrumOne)\n transport: http('https://your-parent-chain-rpc-url'), // Replace with actual RPC URL\n});\n\nPrepare deployment parameters, including stakeToken:\nUse createRollupPrepareDeploymentParamsConfig to define the rollout config. This is where you configure the stakeToken (the ERC-20 address on the parent chain) and baseStake (minimum stake amount in wei).\nimport { createRollupPrepareDeploymentParamsConfig } from '@arbitrum/chain-sdk';\n\nconst createRollupConfig = await createRollupPrepareDeploymentParamsConfig(parentChainPublicClient, {\n chainId: 123456, // Must match the chainId from Step 1\n owner: '0xYourOwnerAddressHere', // Must match InitialChainOwner from Step 1\n chainConfig,\n stakeToken: '0xYourStakeTokenERC20AddressHere', // ERC-20 token address on parent chain for validator staking\n baseStake: 1000000000000000000n, // Example: 1 token (adjust based on token decimals)\n // Optional: Other params like confirmPeriodBlocks, loserStakeEscrow, etc.\n});\n\nDeploy the chain:\nUse createRollup to deploy. Provide validator and addresses. This step sends the to the parent chain.\nimport { createWalletClient } from 'viem';\nimport { privateKeyToAccount } from 'viem/accounts';\nimport { createRollup } from '@arbitrum/chain-sdk';\n\nconst deployerAccount = privateKeyToAccount('0xYourDeployerPrivateKeyHere'); // Securely manage this\n\nconst walletClient = createWalletClient({\n account: deployerAccount,\n chain: sepolia, // Match parent chain\n transport: http('https://your-parent-chain-rpc-url'),\n});\n\nconst createRollupResults = await createRollup({\n params: {\n config: createRollupConfig,\n batchPosters: ['0xYourBatchPosterAddressHere'], // Address for posting batches\n validators: ['0xYourValidatorAddressHere'], // Validator addresses\n // Optional: nativeToken: '0xCustomGasTokenAddress' for custom fee tokens\n },\n account: deployerAccount,\n publicClient: parentChainPublicClient,\n walletClient,\n});\n\nconsole.log('Deployment Transaction Hash:', createRollupResults.transactionHash);\nconsole.log('Core Contracts:', createRollupResults.coreContracts);\n\nPost-deployment (if using AnyTrust):\nIf DataAvailabilityCommittee is true, set the DAC keyset in the SequencerInbox.\nimport { setValidKeyset } from '@arbitrum/chain-sdk';\n\n// Generate or provide your keyset (BLS public keys for the committee)\nconst keyset = '0xYourGeneratedKeysetHere';\n\nconst setKeysetResults = await setValidKeyset({\n coreContracts: createRollupResults.coreContracts,\n keyset,\n publicClient: parentChainPublicClient,\n walletClient,\n});\n\nAdditional notes\n\nEnsure the stakeToken is a compliant ERC-20 on the parent chain; mismatches can cause deployment failures.\nTest on a testnet (e.g., Sepolia) first, as deployments are irreversible and cost gas.\nThe owner address gains control over upgrades and settings—use a secure multisig in production.\nFor production, consider a Rollup-as-a-Service () provider for monitoring and scaling.\nVerification: This SDK-based method deploys directly via interactions and does not involve any UI or (the portal is for asset bridging, not chain deployment).\n\nbaseStake\nThe baseStake is the minimum amount of the bond token that validators must deposit to bond and post assertions.\nConfiguration details\n\nSpecified as a float value (e.g., in wei for ETH).\nMust be greater than 0.\nBalances security: Low values ease entry but risk malicious challenges; high values deter attacks but exclude smaller validators.\n\nHow to configure\n\nPrepare the chain configuration:\nGenerate the base chain config using prepareChainConfig. Set the chainId and initial owner.\nimport { prepareChainConfig } from '@arbitrum/chain-sdk';\n\nconst chainConfig = prepareChainConfig({\n chainId: 123456, // Replace with your desired chain ID\n arbitrum: {\n InitialChainOwner: '0xYourOwnerAddressHere', // Wallet address that will own the chain\n DataAvailabilityCommittee: false, // Set to true for AnyTrust chains (DAC)\n },\n});\n\nSet up the public client for the parent chain:\nCreate a public client to interact with the parent chain.\nimport { createPublicClient, http } from 'viem';\nimport { sepolia } from 'viem/chains'; // Example: Use 'mainnet' or 'arbitrumOne' as needed\n\nconst parentChainPublicClient = createPublicClient({\n chain: sepolia, // Replace with your parent chain (e.g., arbitrumOne)\n transport: http('https://your-parent-chain-rpc-url'), // Replace with actual RPC URL\n});\n\nPrepare deployment parameters, including stakeToken:\nUse createRollupPrepareDeploymentParamsConfig to define the rollout config. This is where you configure the stakeToken (the ERC-20 address on the parent chain) and baseStake (minimum stake amount in wei).\nimport { createRollupPrepareDeploymentParamsConfig } from '@arbitrum/chain-sdk';\n\nconst createRollupConfig = await createRollupPrepareDeploymentParamsConfig(parentChainPublicClient, {\n chainId: 123456, // Must match the chainId from Step 1\n owner: '0xYourOwnerAddressHere', // Must match InitialChainOwner from Step 1\n chainConfig,\n stakeToken: '0xYourStakeTokenERC20AddressHere', // ERC-20 token address on parent chain for validator staking\n baseStake: 1000000000000000000n, // Example: 1 token (adjust based on token decimals)\n // Optional: Other params like confirmPeriodBlocks, loserStakeEscrow, etc.\n});\n\nDeploy the chain:\nUse createRollup to deploy. Provide validator and batch poster addresses. This step sends the transaction to the parent chain.\nimport { createWalletClient } from 'viem';\nimport { privateKeyToAccount } from 'viem/accounts';\nimport { createRollup } from '@arbitrum/chain-sdk';\n\nconst deployerAccount = privateKeyToAccount('0xYourDeployerPrivateKeyHere'); // Securely manage this\n\nconst walletClient = createWalletClient({\n account: deployerAccount,\n chain: sepolia, // Match parent chain\n transport: http('https://your-parent-chain-rpc-url'),\n});\n\nconst createRollupResults = await createRollup({\n params: {\n config: createRollupConfig,\n batchPosters: ['0xYourBatchPosterAddressHere'], // Address for posting batches\n validators: ['0xYourValidatorAddressHere'], // Validator addresses\n // Optional: nativeToken: '0xCustomGasTokenAddress' for custom fee tokens\n },\n account: deployerAccount,\n publicClient: parentChainPublicClient,\n walletClient,\n});\n\nconsole.log('Deployment Transaction Hash:', createRollupResults.transactionHash);\nconsole.log('Core Contracts:', createRollupResults.coreContracts);\n\nPost-deployment (if using AnyTrust):\nIf DataAvailabilityCommittee is true, set the DAC keyset in the SequencerInbox.\nimport { setValidKeyset } from '@arbitrum/chain-sdk';\n\n// Generate or provide your keyset (BLS public keys for the committee)\nconst keyset = '0xYourGeneratedKeysetHere';\n\nconst setKeysetResults = await setValidKeyset({\n coreContracts: createRollupResults.coreContracts,\n keyset,\n publicClient: parentChainPublicClient,\n walletClient,\n});\n\nAdditional notes\n\nValidators and staking: After deployment, validators bond by depositing at least baseStake of the stakeToken into the Rollup contract. This can be done via contract calls (e.g., using the RollupUserLogic interface).\nWarnings:\n\nEnsure the stakeToken is a compliant ERC-20 on the parent chain; mismatches can cause deployment failures.\nTest on a testnet (e.g., Sepolia) first, as deployments are irreversible and cost gas.\nThe owner address gains control over upgrades and settings—use a secure multisig in production.\nFor production, consider a Rollup-as-a-Service (RaaS) provider for monitoring and scaling.\n\nVerification: This SDK-based method deploys directly via smart contract interactions and does not involve any UI or portal (the portal is for asset bridging, not chain deployment).\n\nloserStakeEscrow\nThe loserStakeEscrow is the address where a validator's bonded funds are sent if they lose a challenge (e.g., due to an incorrect assertion). This mechanism acts as a penalty. The default configuration has no default specified; must be configured.\nConfiguration details\n\nFunds are escrowed rather than immediately burned, allowing potential recovery or governance decisions.\nRecommended: Set to an address controlled by the (s) for management, or a burn address (e.g., 0x000000000000000000000000000000000000dEaD) if funds should be permanently removed.\n\nConfiguring during deployment\n\nPrepare chain config:\nimport { prepareChainConfig } from '@arbitrum/chain-sdk';\n\nconst chainConfig = prepareChainConfig({\n chainId: 123456, // Your unique chain ID\n arbitrum: {\n InitialChainOwner: '0xYourOwnerAddressHere',\n DataAvailabilityCommittee: false, // True for AnyTrust chains\n },\n});\n\nSet up parent chain client:\nimport { createPublicClient, http } from 'viem';\nimport { sepolia } from 'viem/chains';\n\nconst parentChainPublicClient = createPublicClient({\n chain: sepolia, // Replace with your parent chain\n transport: http('https://your-parent-rpc-url'),\n});\n\nPrepare deployment params, including loserStakeEscrow:\nSet loserStakeEscrow as an address (string). There is no explicit default documented, but if omitted, it may revert to a system default (e.g., zero address)—always specify for control.\nimport { createRollupPrepareDeploymentParamsConfig } from '@arbitrum/chain-sdk';\n\nconst createRollupConfig = await createRollupPrepareDeploymentParamsConfig(parentChainPublicClient, {\n chainId: 123456,\n owner: '0xYourOwnerAddressHere',\n chainConfig,\n loserStakeEscrow: '0xYourEscrowAddressHere', // e.g., owner-controlled or burn address\n // Optional: baseStake: 100000000000000000n, stakeToken: '0xERC20Address', etc.\n});\n\nDeploy the chain:\nimport { createWalletClient } from 'viem';\nimport { privateKeyToAccount } from 'viem/accounts';\nimport { createRollup } from '@arbitrum/chain-sdk';\n\nconst deployerAccount = privateKeyToAccount('0xYourPrivateKey');\n\nconst walletClient = createWalletClient({\n account: deployerAccount,\n chain: sepolia,\n transport: http('https://your-parent-rpc-url'),\n});\n\nconst createRollupResults = await createRollup({\n params: {\n config: createRollupConfig,\n batchPosters: ['0xYourBatchPosterAddress'],\n validators: ['0xYourValidatorAddress'],\n },\n account: deployerAccount,\n publicClient: parentChainPublicClient,\n walletClient,\n});\n\nconsole.log('Rollup Address:', createRollupResults.coreContracts.rollup);\n\nFor AnyTrust chains:\nIf DataAvailabilityCommittee is true, configure the DAC keyset post-deployment using setValidKeyset from the SDK.\n\nUpdating loserStakeEscrow post-deployment\nThe chain owner can update it by calling setLoserStakeEscrow on the deployed Rollup contract (address from createRollupResults.coreContracts.rollup):\nimport { parseAbi } from 'viem';\n\nconst rollupAbi = parseAbi(['function setLoserStakeEscrow(address newLoserStakedEscrow) external']);\n\nawait walletClient.writeContract({\n address: '0xYourRollupAddress',\n abi: rollupAbi,\n functionName: 'setLoserStakeEscrow',\n args: ['0xNewEscrowAddressHere'],\n});\nAdditional notes\n\nThis process requires the caller to be the owner. Changes affect how challenge losses are handled, so test thoroughly.\nSetting loserStakeEscrow to a burn address increases the cost of failed challenges, enhancing security.\nDeploy on testnets first; mainnet deployments are costly and permanent.\n\nValidator configurations and how to set them up\nValidators are configured during chain deployment and can be run post-launch. Arbitrum chains support permissioned validators, that can be added to an allowlist.\nStep 1: Configure and run the validator node\nStart with the base configuration for a full node, then add validator-specific flags. Use a Docker command to run the Nitro node image (replace placeholders like version numbers, RPC URLs, and chain IDs with your specifics). For example, on Arbitrum One (chain ID 42161):\ndocker run --rm -it -v /path/to/local/dir/arbitrum:/home/user/.arbitrum offchainlabs/nitro-node:v3.12.1-70fa99a \\\n --parent-chain.connection.url=https://your-l1-rpc-url:8545 \\\n --chain.id=42161 \\\n --node.staker.enable=true \\\n --node.staker.strategy=Defensive \\\n --node.staker.parent-chain-wallet.password=\"YOUR_SECURE_PASSWORD\"\nKey configuration parameters to include:\n\n--node.staker.enable=true: This flag enables validation mode.\n--node.staker.strategy=[Strategy]: Choose a strategy based on your intended behavior:\n\nDefensive: Monitors the chain and challenges incorrect assertions by posting a bond (recommended for most users).\nStakeLatest: Bonds on the latest correct assertion and challenges bad ones (available only on pre-BoLD chains).\nResolveNodes: Bonds on the latest assertion, resolves unconfirmed ones, and challenges bad assertions.\nMakeNodes: Creates new assertions, resolves unconfirmed ones, and challenges bad ones (use cautiously, as it may lead to reverted transactions if multiple validators act at once).\nWatchtower: Passively monitors and logs errors without active challenging (enabled by default; no needed, but set --node.staker.enable=false to disable if not wanted).\n\n--node.staker.parent-chain-wallet.private-key=[0xYourPrivateKey] or --node.staker.parent-chain-wallet.password=[YourPassword]: Provides access to the wallet for onchain operations. Use a secure method; password-protected keystores are safer than direct private keys.\n--node.bold.enable=true: Enable this if the chain has BoLD activated (required for versions before Nitro v3.6.0).\n\nFor custom Arbitrum chains:\n\nAdd --chain.info-json=[JSON string or file path with Arbitrum chain info] to specify the chain's details.\nBoLD parameters may not be needed if BoLD isn't activated on that chain.\n\nRun the command in a persistent setup (e.g., using Docker Compose or a systemd service) to keep the node online.\nStep 2: Verify the validator is running correctly\n\nMonitor the node logs for messages:\n\nLook for INFO [...] running as validator txSender=[your_wallet_address] actingAsWallet=[your_wallet_address] whitelisted=true strategy=[YourChosenStrategy]. This indicates the node is in validator mode with a valid wallet.\nvalidation succeeded: Shows the node is successfully validating blocks.\nfound correct assertion: Confirms the node is detecting and agreeing with onchain assertions.\n\nIf issues arise, check for errors related to wallet funding, RPC connectivity, or chain syncing.\n\nAdvanced: Creating a dedicated validator wallet\nIf you need a new wallet specifically for validation, use Nitro to generate one:\ndocker run --rm -it -v /path/to/local/dir/arbitrum:/home/user/.arbitrum offchainlabs/nitro-node:v3.12.1-70fa99a \\\n --parent-chain.connection.url=https://your-l1-rpc-url:8545 \\\n --chain.id=42161 \\\n --node.staker.enable=true \\\n --node.staker.parent-chain-wallet.only-create-key \\\n --node.staker.parent-chain-wallet.password=\"YOUR_SECURE_PASSWORD\"\nThis creates a wallet file in your mounted directory (e.g., under arb1/wallet/ for Arbitrum One). Back it up securely, as it's needed to withdraw any staked funds later. Load it in your node run command using the password.\nFor permissioned chains\nIf the is permissioned (not fully permissionless), add your validator wallet address to the allowlist:\n\nIdentify the upgradeExecutor contract address for the chain.\nCall the executeCall method on it:\n\nSet target to the Rollup contract address.\nSet targetCalldata to 0xa3ffb772 followed by your validator address (this is the encoded signature for setValidator(address[],bool[])).\n\nVerify by calling isValidator(your_address) on the Rollup contract, which should return true.\n\nThis step requires administrative access to the chain.\nKeep your node synced and monitor it regularly to ensure it contributes effectively to chain security. Always use the latest Nitro version for security and compatibility.\nAdditional informationRefer to the Run a full node article for instructions on how to get up and running.\nAssertion interval\nDefault to 15 minutes for new assertions (via --node.bold.assertion-posting-interval (BoLD) or --node.staker.make-assertion-interval (Legacy ~1 hour is default)); must exceed the Rollup's minimumAssertionPeriod (~15 minutes).\nFor production, run multiple validators in a network. Test on devnets first. Always back up keys, as they're needed to withdraw bonds. If issues arise, refer to the official Arbitrum docs for updates, as configurations evolve.How is this guide?BoLD for Arbitrum chainsLearn how to integrate BoLD with your Arbitrum chainCustomizable challenge periodLearn how to customize your Arbitrum chain's challenge period","tokens":4751,"squid":"spider-01","role":"Chain Spider","at":1791346463904,"hash":"7edb391a32a169dffc85d447c459902c3956f1ed"}
{"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":"spider-08","role":"Oracle Spider","at":1791346468025,"hash":"46a25c72a9c8fb813955a8c21300de7bd1cf6d36"}
{"url":"https://developer.arbitrum.io/launch-arbitrum-chain/chain-config/validation/challenge-period","domain":"developer.arbitrum.io","title":"Customizable challenge period","text":"Configure your chainValidationCustomizable challenge periodLearn how to customize your Arbitrum chain's challenge periodRequest an updateThe challenge period defines the time frame during which state updates (assertions) submitted to the remain open for scrutiny and potential before they are finalized. This mechanism ensures that participants in the system have the opportunity to verify the validity of state updates and raise challenges if necessary.\nThe length of the is measured based on the parent chain's notion of time, typically reflected in block.number. For L3s settling to , this period is determined by block progression rather than Arbitrum's () blocks.\nIn addition to the main challenge period, an extra challenge period provides a buffer to resolve any pending challenges after the main period ends. Together, these parameters help balance security and confirm the chain's state.\nDefault challenge period and extra challenge period\nHow time is measured in challengesChains settling to Ethereum or Arbitrum chains use block.number for all block calculations, which corespond to the chain's view of Ethereum's block number. For example, an L3 Arbitrum chain settling to , will calculate block progression based on Ethereum's (L1) block number.\nBy default, the challenge period lasts approximately one week, which equates to roughly 45818 L1 blocks for chains that settle to Ethereum or an Arbitrum chain. The default duration design is to provide sufficient time for validators to detect and challenge fraudulent assertions.\nOn the other hand, the extra challenge period adds a buffer of 40 minutes by default, 200 L1 blocks for chains settling to Ethereum or an Arbitrum chain. This time ensures that any last-minute challenges or ongoing dispute resolution processes can be completed before the Rollup finalizes its state.\nThese default values are selected to carefully balance security and performance for most Rollup use cases. However, developers and Arbitrum may wish to customize these parameters to suit their specific requirements.\nCustomizing the challenge period\nChallenge period blocks\nThe main challenge period configuration uses the confirmPeriodBlocks parameter, which specifies the duration of the challenge window based on the parent chain’s notion of block.number. This parameter can is customizable in two ways:\n\nDuring deployment: Developers can specify the desired value in the confirmPeriodBlocks field of the RollupCreator configuration when deploying the Rollup.\nPost-deployment: The chain owner can update this value dynamically by calling the Rollup.setConfirmPeriodBlocks(newValue) function.\n\nFor example, setting confirmPeriodBlocks to 30,000 blocks reduces the challenge period to approximately 4.5 days. This configuration might be suitable for applications prioritizing faster state , while increasing the value would extend the challenge period, improving security.\nExtra challenge period blocks\nThe extra challenge period is governable using the extraChallengeTimeBlocks parameter, which defines the additional buffer duration after the main challenge period. This period ensures that pending challenges are processed before the Rollup state gets finalized.\nBy default, the extra challenge period is set to 200 blocks, providing a short but sufficient buffer for most networks. However, developers can increase this value for applications requiring additional dispute resolution time or operate in environments with higher latency between the parent and .\nLike the main challenge period, this parameter is customizable in two ways:\n\nDuring deployment: The value can be set in the extraChallengeTimeBlocks field of the RollupCreator configuration.\nPost-deployment: The chain owner can dynamically adjust the parameter using the Rollup.setExtraChallengeTimeBlocks(newExtraTimeBlocks) function.\n\nFor example, the following command can update the extra challenge period to 300 blocks based on the parent chain’s notion of block.number:\ncast send <ROLLUP_ADMIN_ADDRESS> \"setExtraChallengeTimeBlocks(uint256)\" 300 \\\n --rpc-url <RPC_URL> \\\n --private-key <PRIVATE_KEY>\nReplace:\n<ROLLUP_ADMIN_ADDRESS> with the contract address of the Rollup admin.\n<RPC_URL> with the appropriate RPC endpoint.\n<PRIVATE_KEY> with the private key of the authorized admin account (e.g., chain owner).\nRecommended values and best practices\nFor Arbitrum chains aligned with Arbitrum One's configuration, the recommended settings are:\n\nChallenge period blocks: 45818 Ethereum blocks (approximately one week).\nExtra challenge period blocks: 200 Ethereum blocks (approximately 40 minutes).\n\nThese values offer a robust and balanced setup for most Rollup use cases. Developers should consider their application’s requirements when adjusting these parameters:\n\nShorter periods: Suitable for applications that benefit from faster state confirmation, such as Rollups prioritizing quicker exits or user withdrawals. For chains settling to Ethereum or an Arbitrum chain, this reduces challenge duration based on L1 block times.\nLonger periods: Recommended for applications requiring higher security, such as cross-chain asset transfers or large-value transactions. The actual duration depends on the parent chain’s block intervals (e.g., Ethereum vs. other chains).\nHow is this guide?Bond and validator configurationsLearn how to configure your Arbitrum chain with a custom bond and validator configurationsEnable fast withdrawalsLearn to deploy Fast Withdrawals","tokens":1368,"squid":"spider-01","role":"Chain Spider","at":1791346475209,"hash":"10c79aaa4af8b34091d8294b9359443e15006980"}
{"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 385Frequently Asked QuestionsCommon questions about integrating and using Pyth ProContract AddressesList of Pyth Pro (Lazer) contract addresses on supported networks","tokens":399,"squid":"spider-08","role":"Oracle Spider","at":1791346477760,"hash":"c73f584e6753c2b2654fbbeb1fa3aec08d8ec882"}
{"url":"https://developer.arbitrum.io/launch-arbitrum-chain/chain-config/costs","domain":"developer.arbitrum.io","title":"Costs","text":"Configure your chainCostsCosts configuration options for your chain.Request an updateAEP overviewLearn what the AEP fee router is and how it works.AEP router contractsSet up an AEP fee router for your chain.AEP reportingReport on the fees your chain collects under the AEP.Native mint and burnUse a native interop token with mint and burn, such as LayerZero OFT, xERC-20, or native USDC, as your gas token.Custom gas token (AnyTrust)Deploy your AnyTrust chain with a custom gas token.Custom gas token (Rollup)Deploy your Rollup chain with a custom gas token.Dynamic pricingGuidance and best practices for using dynamic pricing on your chain.Fee managementManage the fee parameters of your chain.Revenue routingLearn which addresses collect each fee, when funds move, and how to withdraw revenue to the parent chain.Gas optimizationConfigure and optimize gas for your chain.Gas targetManage the gas target of your chain.Parent chain data fee pricingTune what your chain charges users to post transaction data to the parent chain.Priority feesEnable priority fee (tip) collection on your chain in ArbOS 61 Elara.How is this guide?Enabling blob transactions for Arbitrum batch posterHow to configure your Arbitrum node to post EIP-4844 blob transactions to the parent chainAEP fee router: overviewLearn what is the AEP fee router.","tokens":332,"squid":"spider-01","role":"Chain Spider","at":1791346500161,"hash":"5c0d1a86deb270aa5ff4dc44ea99ad2a747f9ccf"}
{"url":"https://developer.arbitrum.io/launch-arbitrum-chain/chain-config/costs/revenue-routing","domain":"developer.arbitrum.io","title":"Understand network revenue routing on your Arbitrum chain","text":"Configure your chainCostsUnderstand network revenue routing on your Arbitrum chainLearn how transaction fees flow through an Arbitrum chain: which addresses collect each fee component, when funds actually move, and how to withdraw revenue to the parent chainRequest an updateEvery on an pays a single fee, but under the hood that fee is split into components that travel very different paths before reaching their final destination. Some components are credited to a collector address in the same transaction that paid them, while others are routed through a system pool and paid out after batches are posted.\nThis page traces the complete life of a transaction fee: which address collects each component, when funds actually move, why block explorers estimate, and how and when to retrieve funds.\nTo change the fee parameters and collector addresses described here, follow the step by step instructions in How to manage the fee parameters of your Arbitrum chain.\nMain fee components\nTransaction fees on an Arbitrum chain split into four components, each with its own collector:\nFee componentWhat it coversCollected byPaid outArbitrum chain base feeExecution, up to the configured minimum base feeinfraFeeAccountImmediately, per transactionArbitrum chain surplus feeExecution paid above the minimum base fee (congestion), plus any priority feesnetworkFeeAccountImmediately, per transaction base feeEstimated cost of posting the transaction's data to the L1PricerFundsPoolAddress (system pool), then the 's fee collectorAfter each batch posting reportParent chain surplus feeOptional per data unit reward configured by the L1RewardRecipientAfter each batch posting report\nFallback behaviorIf infraFeeAccount is not set (the zero address), the entire execution fee (base and surplus) goes to networkFeeAccount. At chain deployment, networkFeeAccount is initialized to the initial and infraFeeAccount starts unset, so a freshly deployed chain sends all execution fees to the chain owner's address.\nThe first two components are straightforward: credits them to their collector addresses during transaction execution in the same block. The rest of this page focuses on the parent chain base fee and the parent chain surplus fee.\nFee lifecycle\n\nA user pays the transaction fee. ArbOS estimates the transaction's parent chain footprint by compressing it and multiplying the size by the current price per data unit (its running estimate of parent chain costs). This amount is charged as part of the transaction's gas.\n\nThe fee is split at the end of execution. The execution components go directly to infraFeeAccount and networkFeeAccount. The parent chain component is credited to L1PricerFundsPoolAddress (0xA4B00000000000000000000000000000000000f6), a system owned pool with no private key. The pool exists to reimburse whoever ends up paying for batch posting.\n\nThe posts a batch. The batch poster submits your chain's transaction data to the SequencerInbox contract on the parent chain, paying parent chain gas from its own parent chain balance. This is the cost the pool will cover later on.\n\nThe parent chain reports the spending. In the same transaction that records the batch, the SequencerInbox contract sends a batch posting report message into your chain's , containing who posted the batch and the parent chain base fee at the time.\n\nArbOS processes the report and pays out. When the report arrives on the , ArbOS computes what the batch actually cost (reported base fee × the batch's data gas, plus a fixed per batch overhead) and records it as funds due to that batch poster. It then pays, from the pool's balance:\n\nFirst, any parent chain surplus fee owed to the configured reward recipient (reward rate × data units processed).\nThen, the accumulated amount due to the batch poster, sent to that poster's fee collector address.\n\nIf the pool doesn't hold enough to cover everything owed, the remainder stays on the books as funds due and is paid from future collections.\n\nThe price adjusts. ArbOS compares the pool's balance against the total funds due and nudges the price per data unit up or down, so that over time, collections converge on actual costs. The full algorithm is described in Gas and fees.\n\nWhen do funds move?\nPayouts to the fee collector and reward recipient are triggered by batch posting reports. In practice this means:\n\nFunds move shortly after each batch is posted once the report has transited the and been processed on the child chain.\nBatch posting frequency depends on your chain's traffic and batch poster configuration (size, frequency), so payout frequency varies with it. Information about the batch poster configuration is described in Batch Poster.\nEvery report will cover as much of the funds as it can,\n\nEstimated versus actual fees\nBlock explorers such as Blockscout display a per transaction \"Gas used for \" value (and a corresponding L1 fee). A common question is whether this is the actual cost of posting that transaction to the parent chain. It is an estimate, and it is never retroactively corrected. Here is why:\n\nWhen a transaction executes, its batch doesn't exist yet, meaning the transaction has yet to be posted to the parent chain. Therefore ArbOS estimates the parent chain costs by using the price per data unit from the previously posted batch as an estimate.\nThe charged amount is recorded in the transaction receipt as gasUsedForL1: the parent chain fee re-expressed in child chain gas units at the transaction's gas price. This receipt field is what explorers display.\nThe transaction's actual share of batch posting costs is only knowable later, when the batch containing it is posted and reported. That actual cost is never attributed back to individual transactions. Instead, the difference between what was collected and what batches actually cost accumulates as a surplus or deficit in L1PricerFundsPoolAddress, and the adaptive pricing algorithm adjusts future charges to drive that difference toward zero.\n\nGas estimation pads the feeeth_estimateGas responses include an additional ~10% padding on the parent chain component to protect users against parent chain gas price increases between estimation and execution. The amount actually charged at execution time uses the unpadded current price, so estimates typically exceed final charges.\nYou can read the parent chain fee charged to the current transaction from within a contract, or inspect a live chain's pricing state, using the ArbGasInfo (getCurrentTxL1GasFees(), getL1BaseFeeEstimate()).\nFunds are stagnant unless moved\nAll four collector addresses are addresses on your chain, and every payout described above is a native token transfer on your chain. The protocol never bridges revenue to the parent chain on your behalf. Two balances that operators sometimes conflate are entirely separate:\n\nThe batch poster's parent chain balance: the wallet that pays for posting batches. It spends the parent chain's gas token and depletes over time. You must keep it funded. If you hold that key in a KMS or a remote signer rather than locally, see Batch poster: External signing (KMS).\nThe fee collector's child chain balance: where reimbursement and revenue accumulate, denominated in your chain's gas token.\n\nThe protocol's pricing loop makes the second balance grow in proportion to what the first one spends, but moving value between them is the chain operator's job.\nThere are two options to move revenue from the child chain to the parent chain:\n\nWithdraw manually through the bridge. If a collector is an EOA or multisig you control, initiate a standard child to parent withdrawal and execute it on the parent chain after the period.\nUse the AEP fee router contracts. Set your collector addresses to ChildToParentRouter contracts, which route received funds to a configurable parent chain address and can be triggered permissionlessly. This is the recommended setup for chains with Arbitrum Expansion Program obligations (see AEP fee router contracts).\n\nCustom gas token chainsOn chains with a , fee collection is denominated in your gas token while the batch poster spends the parent chain's native token, so the reimbursement stream and the actual cost are in different assets. Such chains typically disable the parent chain base fee (set the price per unit to zero) and handle batch posting costs off-protocol. See How to use a custom gas token and the custom gas token scenario in AEP fee reporting.\nMonitoring the fee pool\nA few useful read calls for reporting on the parent chain fee stream (all against your chain's RPC):\n# Balance sitting in the fee pool, waiting to be paid out\ncast balance 0xA4B00000000000000000000000000000000000f6 --rpc-url $CHAIN_RPC\n\n# Pool funds recognized by the pricer as available for payouts\ncast call --rpc-url $CHAIN_RPC 0x000000000000000000000000000000000000006C \"getL1FeesAvailable() (uint256)\"\n\n# Surplus (positive) or deficit (negative): available funds minus everything owed\ncast call --rpc-url $CHAIN_RPC 0x000000000000000000000000000000000000006C \"getL1PricingSurplus() (int256)\"\n\n# Amount accrued to the reward recipient but not yet paid\ncast call --rpc-url $CHAIN_RPC 0x000000000000000000000000000000000000006C \"getL1PricingFundsDueForRewards() (uint256)\"\n\n# Batch posters known to the chain, and a poster's fee collector\ncast call --rpc-url $CHAIN_RPC 0x000000000000000000000000000000000000006D \"getBatchPosters() (address[])\"\ncast call --rpc-url $CHAIN_RPC 0x000000000000000000000000000000000000006D \"getFeeCollector(address) (address)\" $BATCH_POSTER_ADDRESS\nA negative surplus is normal after periods of high parent chain gas prices since recent batches cost more than what was collected. Therefore the adaptive pricing algorithm is raising the per unit price to recover. A persistently large positive surplus means users are being overcharged relative to costs; a chain owner can correct the price directly (ArbOwner.setL1PricePerUnit) or leave the algorithm to converge.\nFunds sent directly to the pool addressThe pricer only pays out funds it has accounted for. If tokens are transferred directly to L1PricerFundsPoolAddress outside of fee collection, a chain owner can make them available for payouts using ArbOwner.releaseL1PricerSurplusFunds(uint256).\nFor structured daily reporting across all fee streams, see AEP fee reporting, which includes a ready made RPC reporting script.\nSee also\n\nHow to manage the fee parameters of your Arbitrum chain — configuring every parameter and collector mentioned here\nGas and fees — the parent chain pricing mechanism and adaptive algorithm in depth\nAEP fee router contracts — routing revenue to the parent chain automatically\nConfigure your chain's batch poster — the operational side of the component this revenue reimburses\nBatch poster: External signing (KMS) — securing the parent chain wallet that this revenue stream reimburses\nHow is this guide?How to manage the fee parameters of your Arbitrum chainLearn how to manage the fee parameters of your Arbitrum chainConfigure and optimize gasLearn how to configure and optimize gas for your Arbitrum chain","tokens":2770,"squid":"spider-01","role":"Chain Spider","at":1791346522156,"hash":"81ef17206953e31f403716277a1e2cec93cea7e2"}
{"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":"spider-08","role":"Oracle Spider","at":1791346531793,"hash":"768ad882217595f085950976615097e381384e22"}
{"url":"https://akash.network/current-groups/committee-steering/","domain":"akash.network","title":"Steering Committee - Community Groups","text":"Back\n Steering Committee Steering Committee Special Interest Groups Analytics Special Interest Group Chain Special Interest Group Clients Special Interest Group Community Special Interest Group Deployments Special Interest Group Design Special Interest Group Documentation Special Interest Group Economics Special Interest Group Education Providers Special Interest Group Support Special Interest Group Working Groups Akash Hackathon Working Group Akash Website Akash Youtube Client Libraries Working Group Content Moderation Working Group Economics 2.0 2023 Events - Working Group GPU Working Group Provider Attributes Working Group Provider Audit Working Group Testnets Working Group Zealy Steering Committee The Steering Committee is a special SIG that periodically evaluates the list of projects, prioritizes/adds/removes items and decides which SIG or WG is best suited to tackle the project. The Steering Committee also regularly meets to incorporate learnings to improve how the Akash Network community operates and will perform conflict resolution as necessary. \nView on Discord\n\nView on GitHub\n\nSubscribe to Calendar\n\nAkash Network - Steering Committee (SC)\nThe Akash Steering Committee serves as a key advisory body, regularly engaging with the community to evaluate ongoing projects, provide feedback, and align efforts with the Akash roadmap. It supports active discussions, AEPs, special interest groups, and working groups to ensure cohesive progress across various initiatives.\nMeetings\nThese are open community meetings, that usually happen on the last Thursday of each Month at 11am Pacific Time / 7pm UTC\n\nTimeNotesTranscriptRecordingThursday, January 28, 2023 11:00 AM PT (Pacific Time)LinkLinkLinkThursday, February 23, 2023 11:00 AM PT (Pacific Time)LinkLinkLinkTuesday, March 28, 2023 11:00 AM PT (Pacific Time)LinkLinkLinkThursday, May 04, 2023 11:00 AM PT (Pacific Time)LinkLinkLinkThursday, May 25, 2023 11:00 AM PT (Pacific Time)LinkLinkLinkThursday, June 29, 2023 11:00 AM PT (Pacific Time)LinkLinkLinkThursday, July 27, 2023 11:00 AM PT (Pacific Time)LinkLinkLinkWednesday, August 30, 2023 11:00 AM PT (Pacific Time)LinkLinkLinkThursday, September 28, 2023 11:00 AM PT (Pacific Time)LinkLinkLinkWednesday, November 1, 2023 11:00 AM PT (Pacific Time)LinkLinkLinkThursday, December 07, 2023 11:00 AM PT (Pacific Time)LinkLinkLinkThursday, January 25, 2024 11:00 AM PT (Pacific Time)LinkLinkLinkThursday, March 7th, 2024 11:00 AM PT (Pacific Time)LinkLinkLinkThursday, March 28, 2024 11:00 AM PT (Pacific Time)LinkLinkLinkThursday, May 02, 2024 11:00 AM PT (Pacific Time)LinkLinkLinkThursday, June 06, 2024 11:00 AM PT (Pacific Time)LinkLinkLinkThursday, June 27, 2024 11:00 AM PT (Pacific Time)LinkLinkLinkThursday, July 25, 2024 11:00 AM PT (Pacific Time)LinkLinkLinkThursday, August 29, 2024 11:00 AM PT (Pacific Time)LinkLinkLinkThursday, September 26, 2024 11:00 AM PT (Pacific Time)LinkLinkLinkThursday, October 31, 2024 11:00 AM PT (Pacific Time)LinkLinkLinkThursday, December 05, 2024 11:00 AM PT (Pacific Time)LinkLinkLinkThursday, January 09, 2025 11:00 AM PT (Pacific Time)LinkLinkLinkThursday, January 30, 2025 11:00 AM PT (Pacific Time)LinkLinkLinkThursday, March 06, 2025 11:00 AM PT (Pacific Time)LinkLinkLinkThursday, March 27, 2025 11:00 AM PT (Pacific Time)LinkLinkLinkThursday, April 24, 2025 11:00 AM PT (Pacific Time)LinkLinkLinkThursday, May 29, 2025 11:00 AM PT (Pacific Time)LinkLinkLinkThursday, July 3rd 2025, 2025 11:00 AM PT (Pacific Time)LinkLinkLinkThursday, July 31st, 2025 11:00 AM PT (Pacific Time)LinkLinkComing SoonThursday, September 4th, 2025 11:00 AM PT (Pacific Time)LinkLinkLinkThursday, September 25th, 2025 11:00 AM PT (Pacific Time)LinkLinkLinkThursday, October 30th, 2025 11:00 AM PT (Pacific Time)LinkLinkLinkThursday, December 4th, 2025 11:00 AM PT (Pacific Time)LinkLinkLinkThursday, January 8th, 2026 11:00 AM PT (Pacific Time)LinkLinkLinkThursday, January 29th, 2026 11:00 AM PT (Pacific Time)LinkLinkLinkThursday, February 26th, 2026 11:00 AM PT (Pacific Time)LinkLinkLinkThursday, March 26th, 2026 11:00 AM PT (Pacific Time)LinkLinkLinkThursday, April 30th, 2026 11:00 AM PT (Pacific Time)LinkLinkLinkThursday, June 4th, 2026 11:00 AM PT (Pacific Time)LinkLinkLinkThursday, July 9th, 2026 11:00 AM PT (Pacific Time)LinkLinkComing SoonThursday, July 30th, 2026 11:00 AM PT (Pacific Time)Thursday, August 2026 11:00 AM PT (Pacific Time)Thursday, September 2026 11:00 AM PT (Pacific Time)Thursday, October 2026 11:00 AM PT (Pacific Time)Thursday, November 2026 11:00 AM PT (Pacific Time)Thursday, Decmer 2026 11:00 AM PT (Pacific Time)\nTypical Akash Steering Committeee Meeting Agenda\n\nReview/ discuss/ address any community feedback, greviances or conflicts.\nReview Akash Project Boards and prioritize/ add/ remove if necessary.\nReview any new Github Discussions.\n\nSince we’re limited on time, discussion topics and proposals will be chosen based on the following criteria:\n\nWhen was the discussion topic created? (older ones that have not been discussed in SC yet get priority)\nHas there been discussions in the specific SIG that it applies to? (for example - incentives in sig-provider, spheron stuff in sig-clients etc). SC shouldn’t be spending time on ones that haven’t been discussed in the respective sigs.\nWhat level of engagement has there been on the discussion thread itself? (ones with higher engagement should be prioritized over others).\nIs the champion of the initiative on this call? (not being there to talk about your proposal means we don’t spend time on it).\nIs the champion someone who is currently active in the community? (generally priority to people that actively participate in other discussions as well is discord and sig/ wg calls)\n\nOpen up the floor to any other questions from the participants.\nLook ahead at special interests groups (sigs) and working groups (wgs) for the following month.\n\nAkash Steering Committee\nThe Steering Commitee is initially comprised of the following members who have the most familiarity with Akash Network.\n\nArtur Troian, Overclock Labs\nGreg Osuri, Overclock Labs\nScott Caruthers, Overclock Labs\n Analytics Special Interest Group","tokens":1541,"squid":"spider-03","role":"Compute Spider","at":1791346534788,"hash":"655072639e45770cf750e94872fd90247006d537"}
{"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":"spider-08","role":"Oracle Spider","at":1791346541922,"hash":"859b5126396e21fffe053e6e63f4c17cf2395f27"}
{"url":"https://akash.network/community/contributions/","domain":"akash.network","title":"Community Contributions","text":"Community Contributions A global community collaborating and contributing to the development of the Akash Network. aoritus How to Deploy Paperclip on Akash Network \nRead More\n Ayati Ogochukwu From Video to Content: AI-Powered Post Generation on Akash \nRead More\n Rodri How to Deploy OpenProject on Akash Network \nRead More\n Alex Diaz Zcash x Akash: Open-Source Node Deployment \nRead More\n Rachel Turney The Cloud is Becoming Visible \nRead More\n Asad Rizvi Educational Content: Introducing Akash Network on Instagram \nRead More\n Tharun Ekambaram ETHGlobal New York 2026 Finalists (Akash Hackathon Squad) \nRead More\n Tharun Ekambaram Solana Track Winner at USC Blockchain Conference: Senthos Prediction Market Platform \nRead More\n Sam Lister How to Back Up Data from Akash Apps \nRead More\n Phoebe, Piber, Sandeep and Rodri OpenClaw Skills on Akash Agents \nRead More\n Deepthi Morusupalli Building AI Agents Is Easy. Powering Them Is Hard. \nRead More\n Rachel Turner POV: You apply to be an Akash Student Ambassador \nRead More\n Hugo David Github Tutorial: How to Deploy from Github \nRead More\n Rodri Akash Network SDL Guide \nRead More\n Hrishabh Ayush Improved Akash Console API Documentation & Developer Experience \nRead More\n Rachel Turney The Future of AI Isn't Cloud or Local \nRead More\n Nick Hardy & Tharun Ekambaram Avalanche Track Winner at USC Blockchain Conference: AgentHire AI Agent Marketplace \nRead More\n Hugo David Le Cloud Décentralisé et Akash Network : Une Alternative Innovante pour l'Europe \nRead More\n Asad Rizvi The Backdoor in the Machine, Part II \nRead More\n Hugo David Static Website Deployment Template for Akash \nRead More\n Huy Huynh & Kien Nguyen AkashTrainer: One-Message ML Training Agent on Akash GPUs \nRead More\n Asad Rizvi Stress Testing Trust in Decentralized AI (Ongoing Experiment) \nRead More\n Nick Hardy & Tharun Ekambaram 1st Place at UPenn Blockchain Conference: On-Chain Analytics Pipeline on Akash \nRead More\n Asad Rizvi The Backdoor in the Machine: Why Decentralized AI Isn't Secure (Yet) \nRead More\n Lucas Botbol Bittensor Miner Setup on Akash \nRead More\n Lucas Botbol From Onboarding to Bittensor Miner on Akash \nRead More\n Hugo David Introduction to Akash Network + Console (French Tutorial) \nRead More\n Ensar Burrja Gradio on Akash: ML Demos Made Deployable \nRead More\n Ayesha Satpathy Who Really Wins the AI Compute War? \nRead More\n Asad Rizvi Autoresearch-at-Home Template Contribution \nRead More\n Hugo David Cloud Laws vs. Innovation: Why Decentralized Infrastructure Wins \nRead More\n Hugo DAVID Cloud War: The Battle for Digital Sovereignty \nRead More\n Hrishabh Ayush Deployed Karpathy's Autoresearch on Akash \nRead More\n Hrishabh Ayush Second PR Merged: Fixing Env Setup in Quick Start \nRead More\n Helen Hui Cloud Deployment Workshop with AI @ Princeton \nRead More\n Hrishabh Ayush First PR Merged: Fixing a Critical Gap in the Quick Start Guide \nRead More\n Ayesha Satpathy & Lucas Botbol UT Austin x Akash: Live OpenClaw Deployment \nRead More\n Shelby Peris The Permissionless Shortcut: Why Ambassador Programs are the New Web3 Internship \nRead More\n Lucas Botbol How to host clawdbot for free \nRead More\n Helen Hui Thoughts on Startup: Horizontal, Vertical, or Something in Between \nRead More\n Alex Diaz & Alon Mutter Blockchain @ USC Mixer feat. Akash \nRead More\n Alon Mutter Exploring Akash's Role in the Machine Economy \nRead More\n Helen Hui Why Decentralized Cloud Startups Have Weaker Early Moats but Stronger Long-Term Ones \nRead More\n Lucas Botbol How to self-host the cheapest n8n server \nRead More\n Lucas Botbol Akash Network: The Open Cloud for Builders \nRead More\n USC Blockchain Akash Network X USC Build Night \nRead More\n Helen Hui Why Blockchain Will Reshape Modern AI Training — and How You Can Get Ahead! \nRead More\n Ayesha Satpathy Why Decentralized Cloud Matters \nRead More","tokens":959,"squid":"spider-03","role":"Compute Spider","at":1791346545078,"hash":"4bb8b52032f01d4441947362abdfd91a8132843d"}
{"url":"https://www.metaplex.com/docs/nfts/transfer-nft","domain":"metaplex.com","title":"Transfer an NFT | NFTs","text":"Transfer NFT ownership between wallets on Solana. Transfer an NFTIn the following section you can find a full code example and the parameters that you might need to change. You can learn more about transferring NFTs in the Core documentation.1import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n2import { transfer } from '@metaplex-foundation/mpl-core'\n3import { mplCore } from '@metaplex-foundation/mpl-core'\n4import { publicKey } from '@metaplex-foundation/umi'\n5\n6// Initialize UMI\n7const umi = createUmi('https://api.devnet.solana.com')\n8 .use(mplCore())\n9\n10// Transfer an existing NFT asset to a new owner\n11const result = await transfer(umi, {\n12 asset: publicKey('AssetAddressHere...'),\n13 newOwner: publicKey('RecipientAddressHere...'),\n14}).sendAndConfirm(umi)\n15\n16console.log('Asset transferred:', result.signature)\nParametersCustomize these parameters for your transfer:ParameterDescriptionassetAddressThe public key of the NFT to transfernewOwnerThe wallet address of the recipientHow It WorksThe transfer process involves three steps:Verify ownership - You must be the current owner of the NFTSpecify recipient - Provide the new owner's wallet addressExecute transfer - The NFT ownership is transferred immediatelyNFT TransfersUnlike SPL/fungible tokens, Core NFTs don't require the recipient to create a token account first. The ownership is recorded directly in the NFT, making transfers simpler and cheaper.","tokens":361,"squid":"dotcat","role":"Tooling Spider","at":1791346549821,"hash":"22f5f2acb76220a2fae3bc7532c12299619e43cc"}
{"url":"https://akash.network/community/contributions/how-to-deploy-paperclip-on-akash-network","domain":"akash.network","title":"How to Deploy Paperclip on Akash Network","text":"Community Contributions\n Guides How to Deploy Paperclip on Akash Network \nby aoritus \n— Sep 2, 2026 How to Deploy Paperclip on Akash: Self-Host Your AI Agent Teams\nWhat is Paperclip?\nPaperclip is an open-source platform for orchestrating AI agents. It provides shared memory, tool access, and workflow management in a single interface.\nThis guide covers deploying Paperclip on Akash Network — a decentralized cloud platform.\nPaperclip Capabilities\nPaperclip provides an orchestration interface for AI agents with the following features:\n\nAgent personas: Define distinct roles with specific system prompts and behaviors\nTool assignment: Grant agents access to web search, code execution, database queries, and custom functions\nWorkflow chains: Configure agents to pass outputs to other agents in sequence or in parallel\nShared memory: Agents access a common state store for context persistence across interactions\n\nSupported Use Cases\nPaperclip supports multiple agent collaboration patterns:\n\nPatternDescriptionExample WorkflowAutonomous Coding TeamsMulti-agent software developmentProduct Manager agent writes spec → Developer agent writes code → QA agent reviewsResearch & Analysis SquadsWeb scraping and report synthesisAgents scrape sources → synthesize findings → format reports for stakeholdersCustomer Support SwarmsTiered support with escalationTier-1 agents handle routine queries → escalate complex issues to Senior Support agentContent PipelinesAutomated content productionAgents monitor news sources → draft articles → push to CMS for human review\nSupported Agents\nPaperclip orchestrates agents that process prompts or API calls:\n\nAgent / ToolPrimary FunctionBest For (Target Persona)Claude CodeGeneral coding, architectureCTO, Senior DeveloperCodexCode generation, refactoringBackend EngineerCursorIDE-based developmentFrontend DeveloperGemini CLIMulti-modal tasksContent CreatorHermesAdvanced reasoningStrategy ConsultantOpenCodeOpen-source CLI, multi-provider codingIndie Developer, Open-source ContributorPiConversational AI, emotional intelligenceCustomer Success, HR SpecialistGrok BuildReal-time agent building, X integrationSocial Media Analyst, Trend Researcher\nCost Comparison\nCheck the Usage Pricing Calculator to see the approximate difference.\n\nProviderEst. Monthly CostProsConsAkash Network$5.64Lowest cost, decentralized compute.Requires SDL configuration.AWS$8.26Enterprise infrastructure, mature ecosystem.Higher cost, complex networking.GCP$6.85Enterprise infrastructure, AI/ML integrations.Higher cost, complex IAM.Azure$7.32Enterprise infrastructure, corporate integration.Higher cost, complex management portal.\nDeployment Steps\nPrerequisites\n\nAkash Console Air account with pre-minted ACT tokens OR Akash Console if you want to buy credits without crypto.\nLLM API keys (OpenAI, Anthropic, or compatible provider). AkashML works perfectly with Claude Code adapter. Go to the AkashML documentation to learn how to get started.\n\nStep 1: Configure the SDL\nThe SDL defines compute, storage, and networking. Access the Paperclip template from Akash Console or use this base configuration:\n---version: \"2.0\"services: server: image: ghcr.io/paperclipai/paperclip:sha-6a4e2e1 expose: - port: 3100 as: 80 to: - global: true env: - DATABASE_URL=postgresql://paperclip:paperclip@db:5432/paperclip - PORT=3100 - SERVE_UI=true - PAPERCLIP_DEPLOYMENT_MODE=authenticated - PAPERCLIP_DEPLOYMENT_EXPOSURE=private - PAPERCLIP_PUBLIC_URL=http://provider.akash.com - BETTER_AUTH_SECRET=3e3d4cfd927be0b953e28879b76a811359f8cba18cc40f7f5ae48d6466203cb9 - ANTHROPIC_BASE_URL=https://api.akashml.com/anthropic - ANTHROPIC_AUTH_TOKEN=akml-... - ANTHROPIC_MODEL=openai/gpt-oss-120b - API_TIMEOUT_MS=3000000 params: storage: paperclip-data: mount: /var/lib/postgresql/data readOnly: false db: image: postgres:15-alpine expose: - port: 5432 as: 5432 to: - service: server env: - POSTGRES_USER=paperclip - POSTGRES_PASSWORD=paperclip - POSTGRES_DB=paperclip - PGDATA=/var/lib/postgresql/data/pgdata params: storage: pgdata: mount: /var/lib/postgresql/data readOnly: falseprofiles: compute: server: resources: cpu: units: 1 memory: size: 1gi storage: - size: 1Gi - name: paperclip-data size: 10Gi attributes: persistent: true class: beta3 db: resources: cpu: units: 1 memory: size: 512Mi storage: - size: 1Gi - name: pgdata size: 10Gi attributes: persistent: true class: beta3 placement: dcloud: pricing: server: denom: uact amount: 100000 db: denom: uact amount: 100000deployment: server: dcloud: profile: server count: 1 db: dcloud: profile: db count: 1\nStep 2: Set Environment Variables\nAdd the following variables via the Console UI:\n\nDATABASE_URL — Database connection URL. The second service in our SDL (which uses PostgreSQL) is optional: we use persistent storage to avoid data loss after the container restarts. For successful authentication, the values ​​of the POSTGRES_USER, POSTGRES_PASSWORD, and POSTGRES_DB variables must match. Variable format: postgresql://[user]:[password]@[host]:[port]/[database_name].\nPAPERCLIP_DEPLOYMENT_MODE — Runtime mode override. Must be authenticated for the cloud. Using this mode sets the host to 0.0.0.0.\nPAPERCLIP_DEPLOYMENT_EXPOSURE — Exposure policy override, typically private or public in authenticated mode.\nPAPERCLIP_PUBLIC_URL — Temporary placeholder. Will be replaced with actual URL after deployment. Without this, the UI is unavailable.\nBETTER_AUTH_SECRET — Signing secret for Better Auth sessions and tokens. Generate your own secret using the command openssl rand -hex 32.\nPAPERCLIP_TOOL_ACTION_SIGNING_SECRET — Signing secret for tool action approvals. Generate your own secret using the command openssl rand -hex 32.\nANTHROPIC_BASE_URL — Endpoint for Claude Code adapter. AkashML in this case.\nANTHROPIC_AUTH_TOKEN — API key for accessing our endpoint.\nANTHROPIC_MODEL — Model that will be used by default.\n\nOnly BETTER_AUTH_SECRET is required to successfully launch the server. However, PAPERCLIP_TOOL_ACTION_SIGNING_SECRET must be configured for the agents to function fully and securely.\nRead more about environment variables at Paperclip Docs and AkashML Docs.\n\nStep 3: Deploy\n\nClick Create Deployment\nFund the lease to start deployment\nSelect provider bid from Akash marketplace\n\nStep 4: Update Public URL\nThe application requires its public URL for webhook callbacks and external tool integration.\n\nNavigate to active deployment in Console\nCopy generated endpoint URL (format without IP port: http://provider.akash.com) from Leases tab\n\nUpdate deployment, replace PAPERCLIP_PUBLIC_URL with copied URL\nClick Update Deployment and wait for container restart\n\nStep 5: Access Interface\nAfter deployment completes, access Paperclip via the endpoint URL. The dashboard provides:\n\nAgent team creation\nTool and model assignment\nReal-time execution logs\n\nThe first time you open the application, you will be asked to register using email (without confirmation). Let’s choose Claude Code (endpoint is set to AkashML) and make our first agent’s heart beat.\n\nSet goals, plans, and tasks for agents and monitor their actions.\n\nThe standard prompt creates a new engineer agent, by default it uses the Claude Code adapter.\nIf ANTHROPIC_BASE_URL and ANTHROPIC_AUTH_TOKEN environment variables are set, no agent configuration is required; by default, the Claude adapter will use our own provider (https://api.akashml.com/anthropic) and the openai/gpt-oss-120b model.\nConclusion\nPaperclip on Akash Network provides self-hosted AI agent orchestration with persistent storage, public endpoints, and cost efficiency. This way offers the lowest cost and maximum privacy.","tokens":1905,"squid":"spider-03","role":"Compute Spider","at":1791346555049,"hash":"35349a635f9aab3eb8c7efb829e316f8dd8976ea"}
{"url":"https://gov.optimism.io/t/season-8-9-budget-board-charter/9818/2","domain":"gov.optimism.io","title":"Season 8 & 9: Budget Board Charter - Elections 💼 - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n Elections 💼\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 6\n min\n\n Apr 2025\n\n 2 / 11\n\n Apr 2025\n\n May 2025\n\n post by system on Apr 7, 2025\n\n system\n\n Thank you to Collective Feedback Commission members, @spengrah and @jackanorak, for feedback on early drafts and input into the design process of the Budget Board.\nSeason 8 & 9: Budget Board Charter\nThis Charter outlines the structure and responsibilities of the Budget Board and its participants. The initial Season 8 & Season 9 Charter was authored by the Foundation, with input from the Collective Feedback Commission. In future Seasons, it will be authored and maintained by the Optimism Budget Board (if renewed).\n*Please note that while we reference Season 8 & 9, the Board’s term will run from May 1st, 2025 - May 1st, 2026. Starting in Season 8, all Councils and Boards will transition to 12-month terms to promote greater continuity and standardization.\n\nThe Budget Board exists to bootstrap critical infrastructure and frameworks to enable the Collective to make sound financial and economic decisions (see “Economic Policy” in the System Diagram). It is composed of high-context members, with a well balanced mix of relevant skillsets.\nThe Budget Board is an important step towards decentralization, enabling decisions previously made by the Foundation to be made by the community, in a governance-minimized, data-driven way. The Budget Board will bring the Collective closer to the Decentralization Milestones shown below. Over time, we expect the role of the Budget Board to be reduced as their work should enable many of these decisions to be made algorithmically (subject to human adjustment or override).\nimage1214×860 86.5 KB\nBoards are advisory and are not delegated final decision-making power. The Board will have proposal rights over budgeting decisions but all proposals must still be approved by the Token House and/or Citizens House, as relevant. It is at the Board’s discretion to take input and/or proposals from the community into consideration when authoring their proposals.\nSeason 8 & 9 Goals\nFinancial Framework and Data Infrastructure Development\n\nEnsure the Collective has access to the data, models, and / or other financial infrastructure needed to conduct the rigorous analysis necessary to make comprehensive and cohesive financial decisions\nThis infrastructure should support automated or algorithmic decision making over time\n\nBudgeting Advisory\n\nPropose annual Token House and Citizens’ House spend\nProvide opinions on the Foundation’s budget (Within the Intents and annual budget report)\n\nCollective Reward and ETH Staking Management\n\nMaintain the Collective Reward Framework, updating the suggested OP per Impact Rating at the start of each Season\nEstablish the process for ETH Staking decisions to be made by, or on behalf of, the community\n\nSeason 8 & 9 Responsibilities\n\nDetermine what data, models, or other financial infrastructure are needed to conduct the rigorous analysis necessary to make comprehensive and cohesive financial decisions\nBuild, or commission third parties to provision, the infrastructure identified above\n\nIn many cases, the Foundation may provide the initial version of a framework (like the Collective Reward Framework) to be maintained and iterated on by the Board\nThe Board may solicit the input of other Councils, Boards, or Commissions in their selection process but will have ultimate decision-making authority to select teams chosen to build infrastructure, as necessary\n\nUse the above mentioned resources to propose:\n\nGovernance Fund Mission Budgets for Token House approval (previously done by Foundation)\nRetro Funding Mission Budgets for Citizens House approval (previously done by Foundation)\nNote that the Foundation will continue to propose Mission scopes\nOverall DAO Operating Budget\n\nIndividual Councils and Boards will then propose individual Operating Budgets from the DAO Operating Budget, subject to Token House approval\nThe Board will provide their opinion on all individual Council and Board Operating Budgets before they move to a vote\n\nAll proposals should be designed so that voters understand the comprehensive impact on the Collective’s financial position and should include the resulting implications for risk, reward, runway, and/or any other relevant financial metrics\n\nProvide opinions on the Foundation’s budget (Within the Intents and annual budget report)\nUpdate the Collective Reward Framework, updating the suggested OP per Impact Rating at the start of each Season\nDesign a process by which the management of ETH Staking is transitioned from the Foundation to the Budget Board, to be run in Season 9/10 (timing dependant on the additional structures required to support this transition)\n\nStructure\nSigning Structure\n\nThe Budget Board is advisory in nature and therefore will not operate a multisig wallet.\n\nSub-committees\n\nThere will be no sub-committees or specially designated roles in the first iteration of the Budget Board. If the Board wishes to add sub-committees based on practical learnings, they may do so next term.\n\nParticipants\nThe Board should be comprised of members with the characteristics outlined in the “eligibility” section below.\nThe Board will consist of 7 total members, including a Board Lead.\n\n3 Token House Representatives\n\nRepresentative does not need to be a Token House delegate but is accountable to Token House and therefore should make recommendations with the Token House’s interest in mind\n\n3 Citizens’ House Representatives\n\nRepresentative does not need to be a Citizen but is accountable to Citizens’ House and therefore should make recommendations with the Citizens’ House’s interest in mind\n\nSee the list of proposed members for the Genesis Cohort here, subject to Ratification in the relevant House\nNote: Membership model may change in future iterations\n\nCohorts and Election Terms\n\nMembers (including the Lead) may be appointed by the Foundation for an initial term, but are subject to alternative selection methods, such as election, thereafter. The initial term of the Budget Board will be 12 months, beginning May 1st, 2025.\nAfter the initial term, all members of the Budget Board may be approved by governance at the start of a new term. Approved members serve for the duration of their term and must be re-approved to serve in future Seasons.\nRepresentatives should only serve in one Council or Board position per term. There are no term limits for representatives, but they may be implemented in the future if the need arises.\n\nEligibility\nAn ideal Budget Board would be comprised of members with the following skillsets:\n\nExperience in financial forecasting and/or corporate budgeting\nProfessional capital allocation and/or portfolio management\nAbility to inform Board decision making with data and/or automation\nExperience allocating capital to support public goods, supporting sustainable ecosystem growth, and/or building long term capital allocation systems\nDemonstrated ability to make accurate predictions\nDeep understanding of macroeconomic policy\n\nRoles\nMembers\n\nUtilize and improve frameworks provided by the Foundation to holistically assess budgeting decisions and their impact on the Collective’s long-term financial position\n\nMaintain the Collective Reward Framework, updating the suggested OP per Impact Rating at the start of each Season instead of the Foundation\n\nEnsure the Collective has access to new data, models, and algorithms needed to implement a data-driven and comprehensive approach to financial decisions\nMaintain these tools\nPropose Mission Budgets (for both the Governance Fund and Retro Funding) to be approved by Governance (The Foundation will continue to propose Mission scope)\nPropose a Collective DAO Operating Budget to be approved by governance\n\nProvide opinions on each Council and Board Operating Budgets proposed under the DAO Operating Budget before it moves to a vote\n\nProvide opinions on the Foundation’s budget (Within the Intents and annual budget report)\nIn order for the Board to put forward a proposal/recommendation, at least 4 Board members must sign-off, which necessarily requires at least one member of each House\n\nLeads\n\nAll representative structures must have Leads. The Lead is always a non-voting/non-signing member, so they remain focused on procedure and operations and may be considered unbiased as they don’t participate in decision making.\nThe Board Lead’s role is procedural, communicative, and ministerial. It has limited ability to influence the substantive decision making by members or signing by key holders.\nThe Lead may break a tie in the case that members cannot come to consensus or temporarily fill the role of a member who has resigned or been removed.\nThe lead will execute the below responsibilities:\n\noversee the provision and/or maintenance of external and internal information about the Board, and any other resources needed by the Board\nensure coordination with any other Councils, Boards, Commissions, as needed\nfacilitate coordination by scheduling and hosting regular Board meetings. It is suggested that meeting minutes or summaries be made available to the community\nprepare proposals and post to the forum within the required review period\nensure proposals receive the required approvals to move to a vote\nexercise decision-making authority in the event that members cannot come to consensus on an administrative or operational matter\n\nResignation process\n\nIf a member wishes to resign before the end of their term, they must appoint a replacement, subject to a simple majority approval of existing members, and communicate this change to the Lead at least 7 days prior to this change taking effect.\nThe Lead will then adjust quorum/ signing thresholds as needed and communicate the change through the structure’s Communication Thread.\n\nAccountability\n\nAll Budget Board members are subject to Representative Removal as outlined in the Operating Manual. Removal votes will occur before the end of the next voting cycle. Please see Representative Structure Framework for additional details about edge cases related to removal.\n\nAll representatives may be removed from their position for failing to uphold the responsibilities outlined in the relevant Charter or for failing to act with honesty, integrity, and transparency. If there is a vote to remove a representative, the Lead, or a simple majority of the remaining membership, may appoint a replacement for the remainder of the term.\n\nThe Budget Board will conduct a retrospective at the mid-point and end of the 12-month term, which will be posted to the forum by the last day of the period.\nThe Budget Board must be renewed in Season 10 in order to become a persistent structure. Persistent structures will be assumed to be renewed each term, delegates may submit Dissolution Proposals at the start of a new term if they believe a persistent structure is no longer fulfilling its mandate and should be discontinued.\n\nBudget Board Budget\n\nSince this is the first iteration of this Board, the Foundation will cover the following operating budget for Season 8 & 9:\n\nLead: 60,000 OP (30,000 OP per Season)\nMembers: 40,000 OP (20,000 OP per Season)\nTotal Foundation Stipends: 220,000 OP\nInfrastructure Budget: The Board may apply for an Infrastructure Budget under the DAO Operating Budget to support the creation of new financial infrastructure used to support decision making.\n\nIteration\nAll Charters, must seek governance approval for major changes to the scope, structure, responsibilities, or budget of the Charter.\nIt should finally be reiterated that the role of all structures are intended to be progressively and programmatically reduced over time, as its functionalities are no longer needed or can be effectively managed by other means. Ultimately, it is the goal of the Collective to reach a state of protocol and governance reliability that allows for the full and final dissolution of any non-essential structures.\n\n Token House Community Call [April 8th 18:00 UTC]\n\n Season 7 Retro Rewards\n\n Charter Template\n\n Guide to Season 9\n\n Token House participation and incentives: Season 7 (Cycle 31a-38)\n\n 2\n\n read \n\n 6\n min\n\n Unlisted on Apr 7, 2025\n\n Listed on Apr 7, 2025\n\n post by Jrocki on Apr 8, 2025\n\n Jrocki\n\n govNERD\n\n Could you elaborate on what these Foundation Stipends are?\n\n post by lavande on Apr 8, 2025\n\n lavande\n\n The Foundation will provide members with rewards for their participation as members during the first term. In alignment with the Collective Reward Framework, each member (excluding those employed by OP Labs or the Optimism Foundation) will receive 40k OP (20k OP per Season) and the Lead will receive 60k OP (30k OP per Season.)\n\n post by GFXlabs on Apr 9, 2025\n\n GFXlabs\n\nPerhaps the first task of the budget board could be figuring out how to denominate compensation for themselves and others in USD. There have been times in the past an argument could be made – and was made – that contributors were overcompensated. Now markets look to impose the reverse.\nThere are probably some creative ways to make this work, or at least provide upper and lower ranges where additional OP is provided or OP is held back.\n\n post by LauNaMu on Apr 10, 2025\n\n LauNaMu\n\n Some questions:\n\nDoes this mean that any of the people suggested for the Genesis Cohort will have to abstain for participating in any other Govenance elected/appointed role for the next two seasons?\n\n post by lavande on Apr 11, 2025\n\n lavande\n\n Yep, that is correct\n\n 13 days later\n\n post by 0xDonPepe on Apr 24, 2025\n\n post by yoseph on Apr 30, 2025\n\n post by diegoxxy on May 5, 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 Season 8 and 9: Budget Board Member Ratification\n\n Elections 💼\n\n season-7\n\n Season 8 and 9: Budget Board Member Ratification\nContext\n\nFor full context on the Budget Board, please read the Budget Board Charter. \n\nThe Foundation is proposing to appoint the following members to the Budget Board, as…\n\n read more\n\n 12\n\n 821\n\n Feb 5\n\n Seasons 8 and 9 Budget Board Communication Thread\n\n Elections 💼\n\n The Budget Board is an advisory board that exists to help the Collective bootstrap critical infrastructure and frameworks to enable the Collective to make sound financial and economic decisions. \nThe Budget Board’s Seaso…\n\n read more\n\n 16\n\n 516\n\n Jan 19\n\n Season 8 Council and Board Mandate Guidance\n\n Elections 💼\n\n season-8\n\n Timeline for Prospective Leads\n\n Note: Council terms will now last 12 months. Elected members will serve for Seasons 8 and 9. \n\nJune 13th - June 23rd: Charter Amendments\n\nAll Lead candidates can draft and post C…\n\n read more\n\n 5\n\n 383\n\n Jul 2025\n\n [FINAL] Budget Board Advisory Proposal for the DAO Operating Budget for Seasons 8 and 9\n\n Elections 💼\n\n Budget Board Advisory Proposal for the DAO Operating Budget for Seasons 8 and 9 (Updated)\nThe following is a non-binding proposal for the Collective to consider in passing a DAO Operating Budget for Seasons 8 and 9. The …\n\n read more\n\n 32\n\n 1.7k\n\n Jul 2025\n\n Ed Mazurek - Developer Advisory Board Operating Budget\n\n Elections 💼\n\n season-6\n\n Developer Advisory Board Operating Budget\nProposed Board Lead: Ed Mazurek (wildmolasses) \nProposed Board Operating Budget: 122,000 OP (+52,000 OP from last Season) \nContact Info: changes@gmail.com \nGoals of this proposal…\n\n read more\n\n 7\n\n 876\n\n May 2024","tokens":3887,"squid":"spider-07","role":"Council Spider","at":1791346556811,"hash":"51e9f7a2af490eea679cbd25b7523e2da0f10e16"}
{"url":"https://gov.optimism.io/t/season-8-9-budget-board-charter/9818/6","domain":"gov.optimism.io","title":"Season 8 & 9: Budget Board Charter - Elections 💼 - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n Elections 💼\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 6\n min\n\n Apr 2025\n\n 6 / 11\n\n Apr 2025\n\n May 2025\n\n post by system on Apr 7, 2025\n\n system\n\n Thank you to Collective Feedback Commission members, @spengrah and @jackanorak, for feedback on early drafts and input into the design process of the Budget Board.\nSeason 8 & 9: Budget Board Charter\nThis Charter outlines the structure and responsibilities of the Budget Board and its participants. The initial Season 8 & Season 9 Charter was authored by the Foundation, with input from the Collective Feedback Commission. In future Seasons, it will be authored and maintained by the Optimism Budget Board (if renewed).\n*Please note that while we reference Season 8 & 9, the Board’s term will run from May 1st, 2025 - May 1st, 2026. Starting in Season 8, all Councils and Boards will transition to 12-month terms to promote greater continuity and standardization.\n\nThe Budget Board exists to bootstrap critical infrastructure and frameworks to enable the Collective to make sound financial and economic decisions (see “Economic Policy” in the System Diagram). It is composed of high-context members, with a well balanced mix of relevant skillsets.\nThe Budget Board is an important step towards decentralization, enabling decisions previously made by the Foundation to be made by the community, in a governance-minimized, data-driven way. The Budget Board will bring the Collective closer to the Decentralization Milestones shown below. Over time, we expect the role of the Budget Board to be reduced as their work should enable many of these decisions to be made algorithmically (subject to human adjustment or override).\nimage1214×860 86.5 KB\nBoards are advisory and are not delegated final decision-making power. The Board will have proposal rights over budgeting decisions but all proposals must still be approved by the Token House and/or Citizens House, as relevant. It is at the Board’s discretion to take input and/or proposals from the community into consideration when authoring their proposals.\nSeason 8 & 9 Goals\nFinancial Framework and Data Infrastructure Development\n\nEnsure the Collective has access to the data, models, and / or other financial infrastructure needed to conduct the rigorous analysis necessary to make comprehensive and cohesive financial decisions\nThis infrastructure should support automated or algorithmic decision making over time\n\nBudgeting Advisory\n\nPropose annual Token House and Citizens’ House spend\nProvide opinions on the Foundation’s budget (Within the Intents and annual budget report)\n\nCollective Reward and ETH Staking Management\n\nMaintain the Collective Reward Framework, updating the suggested OP per Impact Rating at the start of each Season\nEstablish the process for ETH Staking decisions to be made by, or on behalf of, the community\n\nSeason 8 & 9 Responsibilities\n\nDetermine what data, models, or other financial infrastructure are needed to conduct the rigorous analysis necessary to make comprehensive and cohesive financial decisions\nBuild, or commission third parties to provision, the infrastructure identified above\n\nIn many cases, the Foundation may provide the initial version of a framework (like the Collective Reward Framework) to be maintained and iterated on by the Board\nThe Board may solicit the input of other Councils, Boards, or Commissions in their selection process but will have ultimate decision-making authority to select teams chosen to build infrastructure, as necessary\n\nUse the above mentioned resources to propose:\n\nGovernance Fund Mission Budgets for Token House approval (previously done by Foundation)\nRetro Funding Mission Budgets for Citizens House approval (previously done by Foundation)\nNote that the Foundation will continue to propose Mission scopes\nOverall DAO Operating Budget\n\nIndividual Councils and Boards will then propose individual Operating Budgets from the DAO Operating Budget, subject to Token House approval\nThe Board will provide their opinion on all individual Council and Board Operating Budgets before they move to a vote\n\nAll proposals should be designed so that voters understand the comprehensive impact on the Collective’s financial position and should include the resulting implications for risk, reward, runway, and/or any other relevant financial metrics\n\nProvide opinions on the Foundation’s budget (Within the Intents and annual budget report)\nUpdate the Collective Reward Framework, updating the suggested OP per Impact Rating at the start of each Season\nDesign a process by which the management of ETH Staking is transitioned from the Foundation to the Budget Board, to be run in Season 9/10 (timing dependant on the additional structures required to support this transition)\n\nStructure\nSigning Structure\n\nThe Budget Board is advisory in nature and therefore will not operate a multisig wallet.\n\nSub-committees\n\nThere will be no sub-committees or specially designated roles in the first iteration of the Budget Board. If the Board wishes to add sub-committees based on practical learnings, they may do so next term.\n\nParticipants\nThe Board should be comprised of members with the characteristics outlined in the “eligibility” section below.\nThe Board will consist of 7 total members, including a Board Lead.\n\n3 Token House Representatives\n\nRepresentative does not need to be a Token House delegate but is accountable to Token House and therefore should make recommendations with the Token House’s interest in mind\n\n3 Citizens’ House Representatives\n\nRepresentative does not need to be a Citizen but is accountable to Citizens’ House and therefore should make recommendations with the Citizens’ House’s interest in mind\n\nSee the list of proposed members for the Genesis Cohort here, subject to Ratification in the relevant House\nNote: Membership model may change in future iterations\n\nCohorts and Election Terms\n\nMembers (including the Lead) may be appointed by the Foundation for an initial term, but are subject to alternative selection methods, such as election, thereafter. The initial term of the Budget Board will be 12 months, beginning May 1st, 2025.\nAfter the initial term, all members of the Budget Board may be approved by governance at the start of a new term. Approved members serve for the duration of their term and must be re-approved to serve in future Seasons.\nRepresentatives should only serve in one Council or Board position per term. There are no term limits for representatives, but they may be implemented in the future if the need arises.\n\nEligibility\nAn ideal Budget Board would be comprised of members with the following skillsets:\n\nExperience in financial forecasting and/or corporate budgeting\nProfessional capital allocation and/or portfolio management\nAbility to inform Board decision making with data and/or automation\nExperience allocating capital to support public goods, supporting sustainable ecosystem growth, and/or building long term capital allocation systems\nDemonstrated ability to make accurate predictions\nDeep understanding of macroeconomic policy\n\nRoles\nMembers\n\nUtilize and improve frameworks provided by the Foundation to holistically assess budgeting decisions and their impact on the Collective’s long-term financial position\n\nMaintain the Collective Reward Framework, updating the suggested OP per Impact Rating at the start of each Season instead of the Foundation\n\nEnsure the Collective has access to new data, models, and algorithms needed to implement a data-driven and comprehensive approach to financial decisions\nMaintain these tools\nPropose Mission Budgets (for both the Governance Fund and Retro Funding) to be approved by Governance (The Foundation will continue to propose Mission scope)\nPropose a Collective DAO Operating Budget to be approved by governance\n\nProvide opinions on each Council and Board Operating Budgets proposed under the DAO Operating Budget before it moves to a vote\n\nProvide opinions on the Foundation’s budget (Within the Intents and annual budget report)\nIn order for the Board to put forward a proposal/recommendation, at least 4 Board members must sign-off, which necessarily requires at least one member of each House\n\nLeads\n\nAll representative structures must have Leads. The Lead is always a non-voting/non-signing member, so they remain focused on procedure and operations and may be considered unbiased as they don’t participate in decision making.\nThe Board Lead’s role is procedural, communicative, and ministerial. It has limited ability to influence the substantive decision making by members or signing by key holders.\nThe Lead may break a tie in the case that members cannot come to consensus or temporarily fill the role of a member who has resigned or been removed.\nThe lead will execute the below responsibilities:\n\noversee the provision and/or maintenance of external and internal information about the Board, and any other resources needed by the Board\nensure coordination with any other Councils, Boards, Commissions, as needed\nfacilitate coordination by scheduling and hosting regular Board meetings. It is suggested that meeting minutes or summaries be made available to the community\nprepare proposals and post to the forum within the required review period\nensure proposals receive the required approvals to move to a vote\nexercise decision-making authority in the event that members cannot come to consensus on an administrative or operational matter\n\nResignation process\n\nIf a member wishes to resign before the end of their term, they must appoint a replacement, subject to a simple majority approval of existing members, and communicate this change to the Lead at least 7 days prior to this change taking effect.\nThe Lead will then adjust quorum/ signing thresholds as needed and communicate the change through the structure’s Communication Thread.\n\nAccountability\n\nAll Budget Board members are subject to Representative Removal as outlined in the Operating Manual. Removal votes will occur before the end of the next voting cycle. Please see Representative Structure Framework for additional details about edge cases related to removal.\n\nAll representatives may be removed from their position for failing to uphold the responsibilities outlined in the relevant Charter or for failing to act with honesty, integrity, and transparency. If there is a vote to remove a representative, the Lead, or a simple majority of the remaining membership, may appoint a replacement for the remainder of the term.\n\nThe Budget Board will conduct a retrospective at the mid-point and end of the 12-month term, which will be posted to the forum by the last day of the period.\nThe Budget Board must be renewed in Season 10 in order to become a persistent structure. Persistent structures will be assumed to be renewed each term, delegates may submit Dissolution Proposals at the start of a new term if they believe a persistent structure is no longer fulfilling its mandate and should be discontinued.\n\nBudget Board Budget\n\nSince this is the first iteration of this Board, the Foundation will cover the following operating budget for Season 8 & 9:\n\nLead: 60,000 OP (30,000 OP per Season)\nMembers: 40,000 OP (20,000 OP per Season)\nTotal Foundation Stipends: 220,000 OP\nInfrastructure Budget: The Board may apply for an Infrastructure Budget under the DAO Operating Budget to support the creation of new financial infrastructure used to support decision making.\n\nIteration\nAll Charters, must seek governance approval for major changes to the scope, structure, responsibilities, or budget of the Charter.\nIt should finally be reiterated that the role of all structures are intended to be progressively and programmatically reduced over time, as its functionalities are no longer needed or can be effectively managed by other means. Ultimately, it is the goal of the Collective to reach a state of protocol and governance reliability that allows for the full and final dissolution of any non-essential structures.\n\n Token House Community Call [April 8th 18:00 UTC]\n\n Season 7 Retro Rewards\n\n Charter Template\n\n Guide to Season 9\n\n Token House participation and incentives: Season 7 (Cycle 31a-38)\n\n 2\n\n read \n\n 6\n min\n\n Unlisted on Apr 7, 2025\n\n Listed on Apr 7, 2025\n\n post by Jrocki on Apr 8, 2025\n\n Jrocki\n\n govNERD\n\n Could you elaborate on what these Foundation Stipends are?\n\n post by lavande on Apr 8, 2025\n\n lavande\n\n The Foundation will provide members with rewards for their participation as members during the first term. In alignment with the Collective Reward Framework, each member (excluding those employed by OP Labs or the Optimism Foundation) will receive 40k OP (20k OP per Season) and the Lead will receive 60k OP (30k OP per Season.)\n\n post by GFXlabs on Apr 9, 2025\n\n GFXlabs\n\nPerhaps the first task of the budget board could be figuring out how to denominate compensation for themselves and others in USD. There have been times in the past an argument could be made – and was made – that contributors were overcompensated. Now markets look to impose the reverse.\nThere are probably some creative ways to make this work, or at least provide upper and lower ranges where additional OP is provided or OP is held back.\n\n post by LauNaMu on Apr 10, 2025\n\n LauNaMu\n\n Some questions:\n\nDoes this mean that any of the people suggested for the Genesis Cohort will have to abstain for participating in any other Govenance elected/appointed role for the next two seasons?\n\n post by lavande on Apr 11, 2025\n\n lavande\n\n Yep, that is correct\n\n 13 days later\n\n post by 0xDonPepe on Apr 24, 2025\n\n 0xDonPepe\n\n I’m casting a “FOR” vote on the Budget Board Charter. I’m not wild about the current draft, but having something in place is still better than what we’ve lived with.\nHere’s what I wish had made it into the charter:\n1. More community voice in seat selection\nRight now the Charter lets the Foundation hand-pick the entire Genesis cohort (and possibly future cohorts). Instead, I would’ve suggested:\n\nHybrid intake: Foundation nominates one member per House, the rest filled through open elections.\n\nCap insider seats and publish a clear scoring rubric so the Board feels earned, not appointed.\n\n2. A roadmap to community-authored Mission scopes\nEven with a community budget board, the Foundation still writes every Mission scope. Instead, I would’ve suggested:\n\nSunset OKR: by the end of Season 9, at least 30 % of Mission scopes must originate from delegates or the Board; majority community authorship by Season 10.\n\nAppreciate everyone’s work so far; let’s keep iterating towards decentralization.\n\n post by yoseph on Apr 30, 2025\n\n post by diegoxxy on May 5, 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 Season 8 and 9: Budget Board Member Ratification\n\n Elections 💼\n\n season-7\n\n Season 8 and 9: Budget Board Member Ratification\nContext\n\nFor full context on the Budget Board, please read the Budget Board Charter. \n\nThe Foundation is proposing to appoint the following members to the Budget Board, as…\n\n read more\n\n 12\n\n 821\n\n Feb 5\n\n Seasons 8 and 9 Budget Board Communication Thread\n\n Elections 💼\n\n The Budget Board is an advisory board that exists to help the Collective bootstrap critical infrastructure and frameworks to enable the Collective to make sound financial and economic decisions. \nThe Budget Board’s Seaso…\n\n read more\n\n 16\n\n 516\n\n Jan 19\n\n Season 8 Council and Board Mandate Guidance\n\n Elections 💼\n\n season-8\n\n Timeline for Prospective Leads\n\n Note: Council terms will now last 12 months. Elected members will serve for Seasons 8 and 9. \n\nJune 13th - June 23rd: Charter Amendments\n\nAll Lead candidates can draft and post C…\n\n read more\n\n 5\n\n 383\n\n Jul 2025\n\n [FINAL] Budget Board Advisory Proposal for the DAO Operating Budget for Seasons 8 and 9\n\n Elections 💼\n\n Budget Board Advisory Proposal for the DAO Operating Budget for Seasons 8 and 9 (Updated)\nThe following is a non-binding proposal for the Collective to consider in passing a DAO Operating Budget for Seasons 8 and 9. The …\n\n read more\n\n 32\n\n 1.7k\n\n Jul 2025\n\n Ed Mazurek - Developer Advisory Board Operating Budget\n\n Elections 💼\n\n season-6\n\n Developer Advisory Board Operating Budget\nProposed Board Lead: Ed Mazurek (wildmolasses) \nProposed Board Operating Budget: 122,000 OP (+52,000 OP from last Season) \nContact Info: changes@gmail.com \nGoals of this proposal…\n\n read more\n\n 7\n\n 876\n\n May 2024","tokens":4140,"squid":"spider-07","role":"Council Spider","at":1791346566924,"hash":"fe8010bc9a8e17a966ed06b11787d18c8f41f50c"}
{"url":"https://gov.optimism.io/t/season-8-9-budget-board-charter/9818/1","domain":"gov.optimism.io","title":"Season 8 & 9: Budget Board Charter - Elections 💼 - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n Season 8 & 9: Budget Board Charter \n\n Elections 💼\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 6\n min\n\n Apr 2025\n\n 1 / 11\n\n Apr 2025\n\n May 2025\n\n post by system on Apr 7, 2025\n\n system\n\n Thank you to Collective Feedback Commission members, @spengrah and @jackanorak, for feedback on early drafts and input into the design process of the Budget Board.\nSeason 8 & 9: Budget Board Charter\nThis Charter outlines the structure and responsibilities of the Budget Board and its participants. The initial Season 8 & Season 9 Charter was authored by the Foundation, with input from the Collective Feedback Commission. In future Seasons, it will be authored and maintained by the Optimism Budget Board (if renewed).\n*Please note that while we reference Season 8 & 9, the Board’s term will run from May 1st, 2025 - May 1st, 2026. Starting in Season 8, all Councils and Boards will transition to 12-month terms to promote greater continuity and standardization.\n\nThe Budget Board exists to bootstrap critical infrastructure and frameworks to enable the Collective to make sound financial and economic decisions (see “Economic Policy” in the System Diagram). It is composed of high-context members, with a well balanced mix of relevant skillsets.\nThe Budget Board is an important step towards decentralization, enabling decisions previously made by the Foundation to be made by the community, in a governance-minimized, data-driven way. The Budget Board will bring the Collective closer to the Decentralization Milestones shown below. Over time, we expect the role of the Budget Board to be reduced as their work should enable many of these decisions to be made algorithmically (subject to human adjustment or override).\nimage1214×860 86.5 KB\nBoards are advisory and are not delegated final decision-making power. The Board will have proposal rights over budgeting decisions but all proposals must still be approved by the Token House and/or Citizens House, as relevant. It is at the Board’s discretion to take input and/or proposals from the community into consideration when authoring their proposals.\nSeason 8 & 9 Goals\nFinancial Framework and Data Infrastructure Development\n\nEnsure the Collective has access to the data, models, and / or other financial infrastructure needed to conduct the rigorous analysis necessary to make comprehensive and cohesive financial decisions\nThis infrastructure should support automated or algorithmic decision making over time\n\nBudgeting Advisory\n\nPropose annual Token House and Citizens’ House spend\nProvide opinions on the Foundation’s budget (Within the Intents and annual budget report)\n\nCollective Reward and ETH Staking Management\n\nMaintain the Collective Reward Framework, updating the suggested OP per Impact Rating at the start of each Season\nEstablish the process for ETH Staking decisions to be made by, or on behalf of, the community\n\nSeason 8 & 9 Responsibilities\n\nDetermine what data, models, or other financial infrastructure are needed to conduct the rigorous analysis necessary to make comprehensive and cohesive financial decisions\nBuild, or commission third parties to provision, the infrastructure identified above\n\nIn many cases, the Foundation may provide the initial version of a framework (like the Collective Reward Framework) to be maintained and iterated on by the Board\nThe Board may solicit the input of other Councils, Boards, or Commissions in their selection process but will have ultimate decision-making authority to select teams chosen to build infrastructure, as necessary\n\nUse the above mentioned resources to propose:\n\nGovernance Fund Mission Budgets for Token House approval (previously done by Foundation)\nRetro Funding Mission Budgets for Citizens House approval (previously done by Foundation)\nNote that the Foundation will continue to propose Mission scopes\nOverall DAO Operating Budget\n\nIndividual Councils and Boards will then propose individual Operating Budgets from the DAO Operating Budget, subject to Token House approval\nThe Board will provide their opinion on all individual Council and Board Operating Budgets before they move to a vote\n\nAll proposals should be designed so that voters understand the comprehensive impact on the Collective’s financial position and should include the resulting implications for risk, reward, runway, and/or any other relevant financial metrics\n\nProvide opinions on the Foundation’s budget (Within the Intents and annual budget report)\nUpdate the Collective Reward Framework, updating the suggested OP per Impact Rating at the start of each Season\nDesign a process by which the management of ETH Staking is transitioned from the Foundation to the Budget Board, to be run in Season 9/10 (timing dependant on the additional structures required to support this transition)\n\nStructure\nSigning Structure\n\nThe Budget Board is advisory in nature and therefore will not operate a multisig wallet.\n\nSub-committees\n\nThere will be no sub-committees or specially designated roles in the first iteration of the Budget Board. If the Board wishes to add sub-committees based on practical learnings, they may do so next term.\n\nParticipants\nThe Board should be comprised of members with the characteristics outlined in the “eligibility” section below.\nThe Board will consist of 7 total members, including a Board Lead.\n\n3 Token House Representatives\n\nRepresentative does not need to be a Token House delegate but is accountable to Token House and therefore should make recommendations with the Token House’s interest in mind\n\n3 Citizens’ House Representatives\n\nRepresentative does not need to be a Citizen but is accountable to Citizens’ House and therefore should make recommendations with the Citizens’ House’s interest in mind\n\nSee the list of proposed members for the Genesis Cohort here, subject to Ratification in the relevant House\nNote: Membership model may change in future iterations\n\nCohorts and Election Terms\n\nMembers (including the Lead) may be appointed by the Foundation for an initial term, but are subject to alternative selection methods, such as election, thereafter. The initial term of the Budget Board will be 12 months, beginning May 1st, 2025.\nAfter the initial term, all members of the Budget Board may be approved by governance at the start of a new term. Approved members serve for the duration of their term and must be re-approved to serve in future Seasons.\nRepresentatives should only serve in one Council or Board position per term. There are no term limits for representatives, but they may be implemented in the future if the need arises.\n\nEligibility\nAn ideal Budget Board would be comprised of members with the following skillsets:\n\nExperience in financial forecasting and/or corporate budgeting\nProfessional capital allocation and/or portfolio management\nAbility to inform Board decision making with data and/or automation\nExperience allocating capital to support public goods, supporting sustainable ecosystem growth, and/or building long term capital allocation systems\nDemonstrated ability to make accurate predictions\nDeep understanding of macroeconomic policy\n\nRoles\nMembers\n\nUtilize and improve frameworks provided by the Foundation to holistically assess budgeting decisions and their impact on the Collective’s long-term financial position\n\nMaintain the Collective Reward Framework, updating the suggested OP per Impact Rating at the start of each Season instead of the Foundation\n\nEnsure the Collective has access to new data, models, and algorithms needed to implement a data-driven and comprehensive approach to financial decisions\nMaintain these tools\nPropose Mission Budgets (for both the Governance Fund and Retro Funding) to be approved by Governance (The Foundation will continue to propose Mission scope)\nPropose a Collective DAO Operating Budget to be approved by governance\n\nProvide opinions on each Council and Board Operating Budgets proposed under the DAO Operating Budget before it moves to a vote\n\nProvide opinions on the Foundation’s budget (Within the Intents and annual budget report)\nIn order for the Board to put forward a proposal/recommendation, at least 4 Board members must sign-off, which necessarily requires at least one member of each House\n\nLeads\n\nAll representative structures must have Leads. The Lead is always a non-voting/non-signing member, so they remain focused on procedure and operations and may be considered unbiased as they don’t participate in decision making.\nThe Board Lead’s role is procedural, communicative, and ministerial. It has limited ability to influence the substantive decision making by members or signing by key holders.\nThe Lead may break a tie in the case that members cannot come to consensus or temporarily fill the role of a member who has resigned or been removed.\nThe lead will execute the below responsibilities:\n\noversee the provision and/or maintenance of external and internal information about the Board, and any other resources needed by the Board\nensure coordination with any other Councils, Boards, Commissions, as needed\nfacilitate coordination by scheduling and hosting regular Board meetings. It is suggested that meeting minutes or summaries be made available to the community\nprepare proposals and post to the forum within the required review period\nensure proposals receive the required approvals to move to a vote\nexercise decision-making authority in the event that members cannot come to consensus on an administrative or operational matter\n\nResignation process\n\nIf a member wishes to resign before the end of their term, they must appoint a replacement, subject to a simple majority approval of existing members, and communicate this change to the Lead at least 7 days prior to this change taking effect.\nThe Lead will then adjust quorum/ signing thresholds as needed and communicate the change through the structure’s Communication Thread.\n\nAccountability\n\nAll Budget Board members are subject to Representative Removal as outlined in the Operating Manual. Removal votes will occur before the end of the next voting cycle. Please see Representative Structure Framework for additional details about edge cases related to removal.\n\nAll representatives may be removed from their position for failing to uphold the responsibilities outlined in the relevant Charter or for failing to act with honesty, integrity, and transparency. If there is a vote to remove a representative, the Lead, or a simple majority of the remaining membership, may appoint a replacement for the remainder of the term.\n\nThe Budget Board will conduct a retrospective at the mid-point and end of the 12-month term, which will be posted to the forum by the last day of the period.\nThe Budget Board must be renewed in Season 10 in order to become a persistent structure. Persistent structures will be assumed to be renewed each term, delegates may submit Dissolution Proposals at the start of a new term if they believe a persistent structure is no longer fulfilling its mandate and should be discontinued.\n\nBudget Board Budget\n\nSince this is the first iteration of this Board, the Foundation will cover the following operating budget for Season 8 & 9:\n\nLead: 60,000 OP (30,000 OP per Season)\nMembers: 40,000 OP (20,000 OP per Season)\nTotal Foundation Stipends: 220,000 OP\nInfrastructure Budget: The Board may apply for an Infrastructure Budget under the DAO Operating Budget to support the creation of new financial infrastructure used to support decision making.\n\nIteration\nAll Charters, must seek governance approval for major changes to the scope, structure, responsibilities, or budget of the Charter.\nIt should finally be reiterated that the role of all structures are intended to be progressively and programmatically reduced over time, as its functionalities are no longer needed or can be effectively managed by other means. Ultimately, it is the goal of the Collective to reach a state of protocol and governance reliability that allows for the full and final dissolution of any non-essential structures.\n\n Token House Community Call [April 8th 18:00 UTC]\n\n Season 7 Retro Rewards\n\n Charter Template\n\n Guide to Season 9\n\n Token House participation and incentives: Season 7 (Cycle 31a-38)\n\n 2\n\n read \n\n 6\n min\n\n Unlisted on Apr 7, 2025\n\n Listed on Apr 7, 2025\n\n post by Jrocki on Apr 8, 2025\n\n post by lavande on Apr 8, 2025\n\n post by GFXlabs on Apr 9, 2025\n\n post by LauNaMu on Apr 10, 2025\n\n post by lavande on Apr 11, 2025\n\n 13 days later\n\n post by 0xDonPepe on Apr 24, 2025\n\n post by yoseph on Apr 30, 2025\n\n post by diegoxxy on May 5, 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 Season 8 and 9: Budget Board Member Ratification\n\n Elections 💼\n\n season-7\n\n Season 8 and 9: Budget Board Member Ratification\nContext\n\nFor full context on the Budget Board, please read the Budget Board Charter. \n\nThe Foundation is proposing to appoint the following members to the Budget Board, as…\n\n read more\n\n 12\n\n 821\n\n Feb 5\n\n Seasons 8 and 9 Budget Board Communication Thread\n\n Elections 💼\n\n The Budget Board is an advisory board that exists to help the Collective bootstrap critical infrastructure and frameworks to enable the Collective to make sound financial and economic decisions. \nThe Budget Board’s Seaso…\n\n read more\n\n 16\n\n 516\n\n Jan 19\n\n Season 8 Council and Board Mandate Guidance\n\n Elections 💼\n\n season-8\n\n Timeline for Prospective Leads\n\n Note: Council terms will now last 12 months. Elected members will serve for Seasons 8 and 9. \n\nJune 13th - June 23rd: Charter Amendments\n\nAll Lead candidates can draft and post C…\n\n read more\n\n 5\n\n 383\n\n Jul 2025\n\n [FINAL] Budget Board Advisory Proposal for the DAO Operating Budget for Seasons 8 and 9\n\n Elections 💼\n\n Budget Board Advisory Proposal for the DAO Operating Budget for Seasons 8 and 9 (Updated)\nThe following is a non-binding proposal for the Collective to consider in passing a DAO Operating Budget for Seasons 8 and 9. The …\n\n read more\n\n 32\n\n 1.7k\n\n Jul 2025\n\n Ed Mazurek - Developer Advisory Board Operating Budget\n\n Elections 💼\n\n season-6\n\n Developer Advisory Board Operating Budget\nProposed Board Lead: Ed Mazurek (wildmolasses) \nProposed Board Operating Budget: 122,000 OP (+52,000 OP from last Season) \nContact Info: changes@gmail.com \nGoals of this proposal…\n\n read more\n\n 7\n\n 876\n\n May 2024","tokens":3618,"squid":"spider-07","role":"Council Spider","at":1791346577170,"hash":"fb38346e6dec3ac1633d28a3074d26a2810f11af"}
{"url":"https://gov.optimism.io/t/season-8-9-budget-board-charter/9818/11","domain":"gov.optimism.io","title":"Season 8 & 9: Budget Board Charter - Elections 💼 - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n Elections 💼\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 6\n min\n\n Apr 2025\n\n 11 / 11\n\n May 2025\n\n May 2025\n\n post by system on Apr 7, 2025\n\n system\n\n Thank you to Collective Feedback Commission members, @spengrah and @jackanorak, for feedback on early drafts and input into the design process of the Budget Board.\nSeason 8 & 9: Budget Board Charter\nThis Charter outlines the structure and responsibilities of the Budget Board and its participants. The initial Season 8 & Season 9 Charter was authored by the Foundation, with input from the Collective Feedback Commission. In future Seasons, it will be authored and maintained by the Optimism Budget Board (if renewed).\n*Please note that while we reference Season 8 & 9, the Board’s term will run from May 1st, 2025 - May 1st, 2026. Starting in Season 8, all Councils and Boards will transition to 12-month terms to promote greater continuity and standardization.\n\nThe Budget Board exists to bootstrap critical infrastructure and frameworks to enable the Collective to make sound financial and economic decisions (see “Economic Policy” in the System Diagram). It is composed of high-context members, with a well balanced mix of relevant skillsets.\nThe Budget Board is an important step towards decentralization, enabling decisions previously made by the Foundation to be made by the community, in a governance-minimized, data-driven way. The Budget Board will bring the Collective closer to the Decentralization Milestones shown below. Over time, we expect the role of the Budget Board to be reduced as their work should enable many of these decisions to be made algorithmically (subject to human adjustment or override).\nimage1214×860 86.5 KB\nBoards are advisory and are not delegated final decision-making power. The Board will have proposal rights over budgeting decisions but all proposals must still be approved by the Token House and/or Citizens House, as relevant. It is at the Board’s discretion to take input and/or proposals from the community into consideration when authoring their proposals.\nSeason 8 & 9 Goals\nFinancial Framework and Data Infrastructure Development\n\nEnsure the Collective has access to the data, models, and / or other financial infrastructure needed to conduct the rigorous analysis necessary to make comprehensive and cohesive financial decisions\nThis infrastructure should support automated or algorithmic decision making over time\n\nBudgeting Advisory\n\nPropose annual Token House and Citizens’ House spend\nProvide opinions on the Foundation’s budget (Within the Intents and annual budget report)\n\nCollective Reward and ETH Staking Management\n\nMaintain the Collective Reward Framework, updating the suggested OP per Impact Rating at the start of each Season\nEstablish the process for ETH Staking decisions to be made by, or on behalf of, the community\n\nSeason 8 & 9 Responsibilities\n\nDetermine what data, models, or other financial infrastructure are needed to conduct the rigorous analysis necessary to make comprehensive and cohesive financial decisions\nBuild, or commission third parties to provision, the infrastructure identified above\n\nIn many cases, the Foundation may provide the initial version of a framework (like the Collective Reward Framework) to be maintained and iterated on by the Board\nThe Board may solicit the input of other Councils, Boards, or Commissions in their selection process but will have ultimate decision-making authority to select teams chosen to build infrastructure, as necessary\n\nUse the above mentioned resources to propose:\n\nGovernance Fund Mission Budgets for Token House approval (previously done by Foundation)\nRetro Funding Mission Budgets for Citizens House approval (previously done by Foundation)\nNote that the Foundation will continue to propose Mission scopes\nOverall DAO Operating Budget\n\nIndividual Councils and Boards will then propose individual Operating Budgets from the DAO Operating Budget, subject to Token House approval\nThe Board will provide their opinion on all individual Council and Board Operating Budgets before they move to a vote\n\nAll proposals should be designed so that voters understand the comprehensive impact on the Collective’s financial position and should include the resulting implications for risk, reward, runway, and/or any other relevant financial metrics\n\nProvide opinions on the Foundation’s budget (Within the Intents and annual budget report)\nUpdate the Collective Reward Framework, updating the suggested OP per Impact Rating at the start of each Season\nDesign a process by which the management of ETH Staking is transitioned from the Foundation to the Budget Board, to be run in Season 9/10 (timing dependant on the additional structures required to support this transition)\n\nStructure\nSigning Structure\n\nThe Budget Board is advisory in nature and therefore will not operate a multisig wallet.\n\nSub-committees\n\nThere will be no sub-committees or specially designated roles in the first iteration of the Budget Board. If the Board wishes to add sub-committees based on practical learnings, they may do so next term.\n\nParticipants\nThe Board should be comprised of members with the characteristics outlined in the “eligibility” section below.\nThe Board will consist of 7 total members, including a Board Lead.\n\n3 Token House Representatives\n\nRepresentative does not need to be a Token House delegate but is accountable to Token House and therefore should make recommendations with the Token House’s interest in mind\n\n3 Citizens’ House Representatives\n\nRepresentative does not need to be a Citizen but is accountable to Citizens’ House and therefore should make recommendations with the Citizens’ House’s interest in mind\n\nSee the list of proposed members for the Genesis Cohort here, subject to Ratification in the relevant House\nNote: Membership model may change in future iterations\n\nCohorts and Election Terms\n\nMembers (including the Lead) may be appointed by the Foundation for an initial term, but are subject to alternative selection methods, such as election, thereafter. The initial term of the Budget Board will be 12 months, beginning May 1st, 2025.\nAfter the initial term, all members of the Budget Board may be approved by governance at the start of a new term. Approved members serve for the duration of their term and must be re-approved to serve in future Seasons.\nRepresentatives should only serve in one Council or Board position per term. There are no term limits for representatives, but they may be implemented in the future if the need arises.\n\nEligibility\nAn ideal Budget Board would be comprised of members with the following skillsets:\n\nExperience in financial forecasting and/or corporate budgeting\nProfessional capital allocation and/or portfolio management\nAbility to inform Board decision making with data and/or automation\nExperience allocating capital to support public goods, supporting sustainable ecosystem growth, and/or building long term capital allocation systems\nDemonstrated ability to make accurate predictions\nDeep understanding of macroeconomic policy\n\nRoles\nMembers\n\nUtilize and improve frameworks provided by the Foundation to holistically assess budgeting decisions and their impact on the Collective’s long-term financial position\n\nMaintain the Collective Reward Framework, updating the suggested OP per Impact Rating at the start of each Season instead of the Foundation\n\nEnsure the Collective has access to new data, models, and algorithms needed to implement a data-driven and comprehensive approach to financial decisions\nMaintain these tools\nPropose Mission Budgets (for both the Governance Fund and Retro Funding) to be approved by Governance (The Foundation will continue to propose Mission scope)\nPropose a Collective DAO Operating Budget to be approved by governance\n\nProvide opinions on each Council and Board Operating Budgets proposed under the DAO Operating Budget before it moves to a vote\n\nProvide opinions on the Foundation’s budget (Within the Intents and annual budget report)\nIn order for the Board to put forward a proposal/recommendation, at least 4 Board members must sign-off, which necessarily requires at least one member of each House\n\nLeads\n\nAll representative structures must have Leads. The Lead is always a non-voting/non-signing member, so they remain focused on procedure and operations and may be considered unbiased as they don’t participate in decision making.\nThe Board Lead’s role is procedural, communicative, and ministerial. It has limited ability to influence the substantive decision making by members or signing by key holders.\nThe Lead may break a tie in the case that members cannot come to consensus or temporarily fill the role of a member who has resigned or been removed.\nThe lead will execute the below responsibilities:\n\noversee the provision and/or maintenance of external and internal information about the Board, and any other resources needed by the Board\nensure coordination with any other Councils, Boards, Commissions, as needed\nfacilitate coordination by scheduling and hosting regular Board meetings. It is suggested that meeting minutes or summaries be made available to the community\nprepare proposals and post to the forum within the required review period\nensure proposals receive the required approvals to move to a vote\nexercise decision-making authority in the event that members cannot come to consensus on an administrative or operational matter\n\nResignation process\n\nIf a member wishes to resign before the end of their term, they must appoint a replacement, subject to a simple majority approval of existing members, and communicate this change to the Lead at least 7 days prior to this change taking effect.\nThe Lead will then adjust quorum/ signing thresholds as needed and communicate the change through the structure’s Communication Thread.\n\nAccountability\n\nAll Budget Board members are subject to Representative Removal as outlined in the Operating Manual. Removal votes will occur before the end of the next voting cycle. Please see Representative Structure Framework for additional details about edge cases related to removal.\n\nAll representatives may be removed from their position for failing to uphold the responsibilities outlined in the relevant Charter or for failing to act with honesty, integrity, and transparency. If there is a vote to remove a representative, the Lead, or a simple majority of the remaining membership, may appoint a replacement for the remainder of the term.\n\nThe Budget Board will conduct a retrospective at the mid-point and end of the 12-month term, which will be posted to the forum by the last day of the period.\nThe Budget Board must be renewed in Season 10 in order to become a persistent structure. Persistent structures will be assumed to be renewed each term, delegates may submit Dissolution Proposals at the start of a new term if they believe a persistent structure is no longer fulfilling its mandate and should be discontinued.\n\nBudget Board Budget\n\nSince this is the first iteration of this Board, the Foundation will cover the following operating budget for Season 8 & 9:\n\nLead: 60,000 OP (30,000 OP per Season)\nMembers: 40,000 OP (20,000 OP per Season)\nTotal Foundation Stipends: 220,000 OP\nInfrastructure Budget: The Board may apply for an Infrastructure Budget under the DAO Operating Budget to support the creation of new financial infrastructure used to support decision making.\n\nIteration\nAll Charters, must seek governance approval for major changes to the scope, structure, responsibilities, or budget of the Charter.\nIt should finally be reiterated that the role of all structures are intended to be progressively and programmatically reduced over time, as its functionalities are no longer needed or can be effectively managed by other means. Ultimately, it is the goal of the Collective to reach a state of protocol and governance reliability that allows for the full and final dissolution of any non-essential structures.\n\n Token House Community Call [April 8th 18:00 UTC]\n\n Season 7 Retro Rewards\n\n Charter Template\n\n Guide to Season 9\n\n Token House participation and incentives: Season 7 (Cycle 31a-38)\n\n 2\n\n read \n\n 6\n min\n\n Unlisted on Apr 7, 2025\n\n Listed on Apr 7, 2025\n\n post by Jrocki on Apr 8, 2025\n\n Jrocki\n\n govNERD\n\n Could you elaborate on what these Foundation Stipends are?\n\n post by lavande on Apr 8, 2025\n\n lavande\n\n The Foundation will provide members with rewards for their participation as members during the first term. In alignment with the Collective Reward Framework, each member (excluding those employed by OP Labs or the Optimism Foundation) will receive 40k OP (20k OP per Season) and the Lead will receive 60k OP (30k OP per Season.)\n\n post by GFXlabs on Apr 9, 2025\n\n GFXlabs\n\nPerhaps the first task of the budget board could be figuring out how to denominate compensation for themselves and others in USD. There have been times in the past an argument could be made – and was made – that contributors were overcompensated. Now markets look to impose the reverse.\nThere are probably some creative ways to make this work, or at least provide upper and lower ranges where additional OP is provided or OP is held back.\n\n post by LauNaMu on Apr 10, 2025\n\n LauNaMu\n\n Some questions:\n\nDoes this mean that any of the people suggested for the Genesis Cohort will have to abstain for participating in any other Govenance elected/appointed role for the next two seasons?\n\n post by lavande on Apr 11, 2025\n\n lavande\n\n Yep, that is correct\n\n 13 days later\n\n post by 0xDonPepe on Apr 24, 2025\n\n 0xDonPepe\n\n I’m casting a “FOR” vote on the Budget Board Charter. I’m not wild about the current draft, but having something in place is still better than what we’ve lived with.\nHere’s what I wish had made it into the charter:\n1. More community voice in seat selection\nRight now the Charter lets the Foundation hand-pick the entire Genesis cohort (and possibly future cohorts). Instead, I would’ve suggested:\n\nHybrid intake: Foundation nominates one member per House, the rest filled through open elections.\n\nCap insider seats and publish a clear scoring rubric so the Board feels earned, not appointed.\n\n2. A roadmap to community-authored Mission scopes\nEven with a community budget board, the Foundation still writes every Mission scope. Instead, I would’ve suggested:\n\nSunset OKR: by the end of Season 9, at least 30 % of Mission scopes must originate from delegates or the Board; majority community authorship by Season 10.\n\nAppreciate everyone’s work so far; let’s keep iterating towards decentralization.\n\n post by yoseph on Apr 30, 2025\n\n yoseph\n\n I am voting For this proposal because it is a good direction overall for the Collective.\nIn conjunction to that, I still feel a vision & strategy element of ‘where is the Collective ultimately going’ still missing, and this gets more pronounced when we bifurcate governance.\nOperational excellence, accountability, decentralization, transparency and similar values of ‘how’ we do things are all valuable things to aim for - setting up a Budget Board is helpful in that direction.\nWhat I’d like to humbly propose is that for the Budget Board (and hopefully every other governance body), part of the role to be about actively asking: “what does the world actually need” in light of what we are currently able to offer the world, and where we could be positioned to offer in the future. By the ‘world’, I am referring to the world outside out of the crypto industry circle of governance and decentralization fans.\nAn additional eligibility criteria to these governance bodies would then be something like “the ability to deeply listen and critically inquire what the world needs”\nI find this crucial so we don’t repeat the same mistakes in the formation of government bureaucracies, where the bureaucracy becomes the end goal and it loses touch with the idea of existing for an external purpose.\nWhen high caliber folks are picked to key positions like this, we should make it their mandate to also zoom out and ask the deeper questions and feed that to the Collective system, not just optimize internal processes. I believe budgeting and financial decisions are the best place to bring in such zoomed out lenses.\n\n post by diegoxxy on May 5, 2025\n\n diegoxxy\n\n Overall, I support the proposal. It lays out a clear structure for efficient financial management and decision-making, backed by data and accountability. The approach fosters long-term stability and growth for the DAO, while ensuring that resources are allocated transparently.\n\n Related topics\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 and 9: Budget Board Member Ratification\n\n Elections 💼\n\n season-7\n\n Season 8 and 9: Budget Board Member Ratification\nContext\n\nFor full context on the Budget Board, please read the Budget Board Charter. \n\nThe Foundation is proposing to appoint the following members to the Budget Board, as…\n\n read more\n\n 12\n\n 821\n\n Feb 5\n\n Seasons 8 and 9 Budget Board Communication Thread\n\n Elections 💼\n\n The Budget Board is an advisory board that exists to help the Collective bootstrap critical infrastructure and frameworks to enable the Collective to make sound financial and economic decisions. \nThe Budget Board’s Seaso…\n\n read more\n\n 16\n\n 516\n\n Jan 19\n\n Season 8 Council and Board Mandate Guidance\n\n Elections 💼\n\n season-8\n\n Timeline for Prospective Leads\n\n Note: Council terms will now last 12 months. Elected members will serve for Seasons 8 and 9. \n\nJune 13th - June 23rd: Charter Amendments\n\nAll Lead candidates can draft and post C…\n\n read more\n\n 5\n\n 383\n\n Jul 2025\n\n [FINAL] Budget Board Advisory Proposal for the DAO Operating Budget for Seasons 8 and 9\n\n Elections 💼\n\n Budget Board Advisory Proposal for the DAO Operating Budget for Seasons 8 and 9 (Updated)\nThe following is a non-binding proposal for the Collective to consider in passing a DAO Operating Budget for Seasons 8 and 9. The …\n\n read more\n\n 32\n\n 1.7k\n\n Jul 2025\n\n Ed Mazurek - Developer Advisory Board Operating Budget\n\n Elections 💼\n\n season-6\n\n Developer Advisory Board Operating Budget\nProposed Board Lead: Ed Mazurek (wildmolasses) \nProposed Board Operating Budget: 122,000 OP (+52,000 OP from last Season) \nContact Info: changes@gmail.com \nGoals of this proposal…\n\n read more\n\n 7\n\n 876\n\n May 2024","tokens":4619,"squid":"spider-07","role":"Council Spider","at":1791346588394,"hash":"8ad3d090054113552faa82901adb502d9fb1c141"}
{"url":"https://forum.across.to/t/welcome-to-discourse/7/2","domain":"forum.across.to","title":"Welcome to Discourse - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Nov 2021\n\n 2 / 2\n\n Mar 11\n\n Nov 2021\n\n post by system on Nov 1, 2021\n\n system\n\n This Forum serves as the starting consensus mechanism for The Across Protocol Fair Fair Launch. It is an offer to the world to take freely an audited, fully-functional protocol and see how a crypto-native community will choose to allocate ownership.\n\n 4 years later\n\n Unpinned on Mar 12\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Welcome to Across\n\n WELCOME 👋\n\n WELCOME 👋\n\n Nov 2022\n\n Across Token Launch Proposal\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 214\n\n May 2022\n\n Across Governance Operating Manual\n\n WELCOME 👋\n\n WELCOME 👋\n\n Jun 2025\n\n Across Token Launch Proposal v2\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 47\n\n Nov 2022\n\n “Community Owned Liquidity” NFT Project Funding Request\n\n Active Proposals\n\n treasury-funding\n\n Active Proposals\n\n 36\n\n Jun 2023","tokens":1728,"squid":"spider-09","role":"Bridge Spider","at":1791346588449,"hash":"6e72483932d6574851d78e73031b16f83b0d4e45"}
{"url":"https://www.metaplex.com/docs/smart-contracts/core/transfer","domain":"metaplex.com","title":"Transferring Assets | Metaplex Core","text":"This guide shows how to transfer Core Assets between wallets on Solana using the Metaplex Core SDK. Send NFTs to other users with a single instruction. What You'll LearnTransfer an Asset to a new ownerHandle transfers for Assets in CollectionsUse Transfer Delegate for authorized transfersUnderstand transfer authority requirementsSummaryTransfer a Core Asset to a new owner using the transfer instruction. Only the current owner (or an authorized Transfer Delegate) can initiate a transfer.Call transfer(umi, { asset, newOwner }) with the recipient's addressFor Collection Assets, include the collection parameterTransfer Delegates can transfer on behalf of ownersTransfers are free (only transaction fee applies)Out of ScopeToken Metadata transfers (use mpl-token-metadata), batch transfers (loop through Assets), and marketplace sales (use escrow programs).Quick StartJump to: Basic Transfer · Collection Transfer · Delegate TransferInstall: npm install @metaplex-foundation/mpl-core @metaplex-foundation/umiFetch the Asset to verify ownership and collection membershipCall transfer(umi, { asset, newOwner })Verify with fetchAsset() that ownership changedPrerequisitesUmi configured with a signer that owns the Asset (or is its Transfer Delegate)Asset address of the Asset to transferRecipient address (public key) of the new owner The owner of a Core Asset can transfer ownership to another account by using the transfer instruction to the MPL Core program.Transferring a Core Asset1import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n2import { transfer } from '@metaplex-foundation/mpl-core'\n3import { mplCore } from '@metaplex-foundation/mpl-core'\n4import { publicKey } from '@metaplex-foundation/umi'\n5\n6// Initialize UMI\n7const umi = createUmi('https://api.devnet.solana.com')\n8 .use(mplCore())\n9\n10// Transfer an existing NFT asset to a new owner\n11const result = await transfer(umi, {\n12 asset: publicKey('AssetAddressHere...'),\n13 newOwner: publicKey('RecipientAddressHere...'),\n14}).sendAndConfirm(umi)\n15\n16console.log('Asset transferred:', result.signature)\nTransferring a Core Asset in a CollectionIf you are transferring an Asset which has a collection you will need to pass the collection address in. How to tell if an Asset is in a Collection?Transfer an Asset that is part of a Collectionimport { publicKey } from '@metaplex-foundation/umi'\nimport { transferV1 } from '@metaplex-foundation/mpl-core'\nconst asset = publicKey('11111111111111111111111111111111')\nconst collection = publicKey('22222222222222222222222222222222222222222222')\nconst newOwner = publicKey('33333333333333333333333333333333333333333333')\n\nawait transferV1(umi, {\n asset,\n newOwner,\n collection,\n}).sendAndConfirm(umi)\nWhat if I am the Transfer Delegate of an Asset?If you are the Transfer Delegate of an Asset via the Transfer Delegate plugin then you can call the transferV1 function as you would if you were the owner of the Asset.Common ErrorsAuthority mismatchYou're not the owner or Transfer Delegate of the Asset. Check ownership:const asset = await fetchAsset(umi, assetAddress)\nconsole.log(asset.owner) // Must match your signer\nAsset is frozenThe Asset has a Freeze Delegate plugin and is currently frozen. The freeze authority must unfreeze it before transfer.Missing collection parameterFor Assets in a Collection, you must pass the collection address. Check if the Asset has a collection:const asset = await fetchAsset(umi, assetAddress)\nif (asset.updateAuthority.type === 'Collection') {\n console.log('Collection:', asset.updateAuthority.address)\n}\nNotesTransfers are free - no rent cost, only the transaction fee (~0.000005 SOL)The new owner receives full control of the AssetTransfer, Burn, and Freeze Delegates are revoked after a successful transferFrozen Assets cannot be transferred until unfrozenAlways fetch the Asset first to check collection membershipQuick ReferenceTransfer ParametersParameterRequiredDescriptionassetYesAsset address or fetched objectnewOwnerYesRecipient's public keycollectionIf in collectionCollection addressauthorityNoDefaults to signer (use for delegates)Who Can Transfer?AuthorityCan Transfer?Asset OwnerYesTransfer DelegateYes (revoked after)Update AuthorityNoCollection AuthorityNoFAQHow do I know if an Asset is in a Collection?Fetch the Asset and check its updateAuthority:const asset = await fetchAsset(umi, assetAddress)\nif (asset.updateAuthority.type === 'Collection') {\n // Pass asset.updateAuthority.address as collection parameter\n}\nCan I transfer to myself?Yes. Transferring to your own address is valid (useful for consolidating wallets or testing).What happens to the Transfer Delegate after a transfer?The Transfer Delegate plugin is automatically revoked when the transfer completes. The new owner must assign a new delegate if needed.Can I cancel a transfer?No. Transfers are atomic - once the transaction confirms, ownership has changed. There's no pending state to cancel.Can I transfer multiple Assets at once?Not in a single instruction. You can batch multiple transfer instructions in one transaction (up to transaction size limits), but each Asset requires its own transfer call.Does transferring change the update authority?No. Transfer only changes ownership. The update authority remains the same unless explicitly changed via the update instruction.GlossaryTermDefinitionOwnerThe wallet that currently owns the AssetTransfer DelegateAn account authorized to transfer on behalf of the ownerFrozenAn Asset state where transfers are blockedNew OwnerThe recipient wallet receiving the AssetCollectionThe Collection an Asset belongs to (affects transfer requirements)","tokens":1412,"squid":"dotcat","role":"Tooling Spider","at":1791346602736,"hash":"27641b3997a485d3aad3c008c6c191a8baa27993"}
{"url":"https://gov.optimism.io/t/season-8-9-budget-board-charter/9818","domain":"gov.optimism.io","title":"Season 8 & 9: Budget Board Charter - Elections 💼 - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n Season 8 & 9: Budget Board Charter \n\n Elections 💼\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 6\n min\n\n Apr 2025\n\n 1 / 11\n\n Apr 2025\n\n May 2025\n\n post by system on Apr 7, 2025\n\n system\n\n Thank you to Collective Feedback Commission members, @spengrah and @jackanorak, for feedback on early drafts and input into the design process of the Budget Board.\nSeason 8 & 9: Budget Board Charter\nThis Charter outlines the structure and responsibilities of the Budget Board and its participants. The initial Season 8 & Season 9 Charter was authored by the Foundation, with input from the Collective Feedback Commission. In future Seasons, it will be authored and maintained by the Optimism Budget Board (if renewed).\n*Please note that while we reference Season 8 & 9, the Board’s term will run from May 1st, 2025 - May 1st, 2026. Starting in Season 8, all Councils and Boards will transition to 12-month terms to promote greater continuity and standardization.\n\nThe Budget Board exists to bootstrap critical infrastructure and frameworks to enable the Collective to make sound financial and economic decisions (see “Economic Policy” in the System Diagram). It is composed of high-context members, with a well balanced mix of relevant skillsets.\nThe Budget Board is an important step towards decentralization, enabling decisions previously made by the Foundation to be made by the community, in a governance-minimized, data-driven way. The Budget Board will bring the Collective closer to the Decentralization Milestones shown below. Over time, we expect the role of the Budget Board to be reduced as their work should enable many of these decisions to be made algorithmically (subject to human adjustment or override).\nimage1214×860 86.5 KB\nBoards are advisory and are not delegated final decision-making power. The Board will have proposal rights over budgeting decisions but all proposals must still be approved by the Token House and/or Citizens House, as relevant. It is at the Board’s discretion to take input and/or proposals from the community into consideration when authoring their proposals.\nSeason 8 & 9 Goals\nFinancial Framework and Data Infrastructure Development\n\nEnsure the Collective has access to the data, models, and / or other financial infrastructure needed to conduct the rigorous analysis necessary to make comprehensive and cohesive financial decisions\nThis infrastructure should support automated or algorithmic decision making over time\n\nBudgeting Advisory\n\nPropose annual Token House and Citizens’ House spend\nProvide opinions on the Foundation’s budget (Within the Intents and annual budget report)\n\nCollective Reward and ETH Staking Management\n\nMaintain the Collective Reward Framework, updating the suggested OP per Impact Rating at the start of each Season\nEstablish the process for ETH Staking decisions to be made by, or on behalf of, the community\n\nSeason 8 & 9 Responsibilities\n\nDetermine what data, models, or other financial infrastructure are needed to conduct the rigorous analysis necessary to make comprehensive and cohesive financial decisions\nBuild, or commission third parties to provision, the infrastructure identified above\n\nIn many cases, the Foundation may provide the initial version of a framework (like the Collective Reward Framework) to be maintained and iterated on by the Board\nThe Board may solicit the input of other Councils, Boards, or Commissions in their selection process but will have ultimate decision-making authority to select teams chosen to build infrastructure, as necessary\n\nUse the above mentioned resources to propose:\n\nGovernance Fund Mission Budgets for Token House approval (previously done by Foundation)\nRetro Funding Mission Budgets for Citizens House approval (previously done by Foundation)\nNote that the Foundation will continue to propose Mission scopes\nOverall DAO Operating Budget\n\nIndividual Councils and Boards will then propose individual Operating Budgets from the DAO Operating Budget, subject to Token House approval\nThe Board will provide their opinion on all individual Council and Board Operating Budgets before they move to a vote\n\nAll proposals should be designed so that voters understand the comprehensive impact on the Collective’s financial position and should include the resulting implications for risk, reward, runway, and/or any other relevant financial metrics\n\nProvide opinions on the Foundation’s budget (Within the Intents and annual budget report)\nUpdate the Collective Reward Framework, updating the suggested OP per Impact Rating at the start of each Season\nDesign a process by which the management of ETH Staking is transitioned from the Foundation to the Budget Board, to be run in Season 9/10 (timing dependant on the additional structures required to support this transition)\n\nStructure\nSigning Structure\n\nThe Budget Board is advisory in nature and therefore will not operate a multisig wallet.\n\nSub-committees\n\nThere will be no sub-committees or specially designated roles in the first iteration of the Budget Board. If the Board wishes to add sub-committees based on practical learnings, they may do so next term.\n\nParticipants\nThe Board should be comprised of members with the characteristics outlined in the “eligibility” section below.\nThe Board will consist of 7 total members, including a Board Lead.\n\n3 Token House Representatives\n\nRepresentative does not need to be a Token House delegate but is accountable to Token House and therefore should make recommendations with the Token House’s interest in mind\n\n3 Citizens’ House Representatives\n\nRepresentative does not need to be a Citizen but is accountable to Citizens’ House and therefore should make recommendations with the Citizens’ House’s interest in mind\n\nSee the list of proposed members for the Genesis Cohort here, subject to Ratification in the relevant House\nNote: Membership model may change in future iterations\n\nCohorts and Election Terms\n\nMembers (including the Lead) may be appointed by the Foundation for an initial term, but are subject to alternative selection methods, such as election, thereafter. The initial term of the Budget Board will be 12 months, beginning May 1st, 2025.\nAfter the initial term, all members of the Budget Board may be approved by governance at the start of a new term. Approved members serve for the duration of their term and must be re-approved to serve in future Seasons.\nRepresentatives should only serve in one Council or Board position per term. There are no term limits for representatives, but they may be implemented in the future if the need arises.\n\nEligibility\nAn ideal Budget Board would be comprised of members with the following skillsets:\n\nExperience in financial forecasting and/or corporate budgeting\nProfessional capital allocation and/or portfolio management\nAbility to inform Board decision making with data and/or automation\nExperience allocating capital to support public goods, supporting sustainable ecosystem growth, and/or building long term capital allocation systems\nDemonstrated ability to make accurate predictions\nDeep understanding of macroeconomic policy\n\nRoles\nMembers\n\nUtilize and improve frameworks provided by the Foundation to holistically assess budgeting decisions and their impact on the Collective’s long-term financial position\n\nMaintain the Collective Reward Framework, updating the suggested OP per Impact Rating at the start of each Season instead of the Foundation\n\nEnsure the Collective has access to new data, models, and algorithms needed to implement a data-driven and comprehensive approach to financial decisions\nMaintain these tools\nPropose Mission Budgets (for both the Governance Fund and Retro Funding) to be approved by Governance (The Foundation will continue to propose Mission scope)\nPropose a Collective DAO Operating Budget to be approved by governance\n\nProvide opinions on each Council and Board Operating Budgets proposed under the DAO Operating Budget before it moves to a vote\n\nProvide opinions on the Foundation’s budget (Within the Intents and annual budget report)\nIn order for the Board to put forward a proposal/recommendation, at least 4 Board members must sign-off, which necessarily requires at least one member of each House\n\nLeads\n\nAll representative structures must have Leads. The Lead is always a non-voting/non-signing member, so they remain focused on procedure and operations and may be considered unbiased as they don’t participate in decision making.\nThe Board Lead’s role is procedural, communicative, and ministerial. It has limited ability to influence the substantive decision making by members or signing by key holders.\nThe Lead may break a tie in the case that members cannot come to consensus or temporarily fill the role of a member who has resigned or been removed.\nThe lead will execute the below responsibilities:\n\noversee the provision and/or maintenance of external and internal information about the Board, and any other resources needed by the Board\nensure coordination with any other Councils, Boards, Commissions, as needed\nfacilitate coordination by scheduling and hosting regular Board meetings. It is suggested that meeting minutes or summaries be made available to the community\nprepare proposals and post to the forum within the required review period\nensure proposals receive the required approvals to move to a vote\nexercise decision-making authority in the event that members cannot come to consensus on an administrative or operational matter\n\nResignation process\n\nIf a member wishes to resign before the end of their term, they must appoint a replacement, subject to a simple majority approval of existing members, and communicate this change to the Lead at least 7 days prior to this change taking effect.\nThe Lead will then adjust quorum/ signing thresholds as needed and communicate the change through the structure’s Communication Thread.\n\nAccountability\n\nAll Budget Board members are subject to Representative Removal as outlined in the Operating Manual. Removal votes will occur before the end of the next voting cycle. Please see Representative Structure Framework for additional details about edge cases related to removal.\n\nAll representatives may be removed from their position for failing to uphold the responsibilities outlined in the relevant Charter or for failing to act with honesty, integrity, and transparency. If there is a vote to remove a representative, the Lead, or a simple majority of the remaining membership, may appoint a replacement for the remainder of the term.\n\nThe Budget Board will conduct a retrospective at the mid-point and end of the 12-month term, which will be posted to the forum by the last day of the period.\nThe Budget Board must be renewed in Season 10 in order to become a persistent structure. Persistent structures will be assumed to be renewed each term, delegates may submit Dissolution Proposals at the start of a new term if they believe a persistent structure is no longer fulfilling its mandate and should be discontinued.\n\nBudget Board Budget\n\nSince this is the first iteration of this Board, the Foundation will cover the following operating budget for Season 8 & 9:\n\nLead: 60,000 OP (30,000 OP per Season)\nMembers: 40,000 OP (20,000 OP per Season)\nTotal Foundation Stipends: 220,000 OP\nInfrastructure Budget: The Board may apply for an Infrastructure Budget under the DAO Operating Budget to support the creation of new financial infrastructure used to support decision making.\n\nIteration\nAll Charters, must seek governance approval for major changes to the scope, structure, responsibilities, or budget of the Charter.\nIt should finally be reiterated that the role of all structures are intended to be progressively and programmatically reduced over time, as its functionalities are no longer needed or can be effectively managed by other means. Ultimately, it is the goal of the Collective to reach a state of protocol and governance reliability that allows for the full and final dissolution of any non-essential structures.\n\n Token House Community Call [April 8th 18:00 UTC]\n\n Season 7 Retro Rewards\n\n Charter Template\n\n Guide to Season 9\n\n Token House participation and incentives: Season 7 (Cycle 31a-38)\n\n 2\n\n read \n\n 6\n min\n\n Unlisted on Apr 7, 2025\n\n Listed on Apr 7, 2025\n\n post by Jrocki on Apr 8, 2025\n\n Jrocki\n\n govNERD\n\n Could you elaborate on what these Foundation Stipends are?\n\n post by lavande on Apr 8, 2025\n\n lavande\n\n The Foundation will provide members with rewards for their participation as members during the first term. In alignment with the Collective Reward Framework, each member (excluding those employed by OP Labs or the Optimism Foundation) will receive 40k OP (20k OP per Season) and the Lead will receive 60k OP (30k OP per Season.)\n\n post by GFXlabs on Apr 9, 2025\n\n GFXlabs\n\nPerhaps the first task of the budget board could be figuring out how to denominate compensation for themselves and others in USD. There have been times in the past an argument could be made – and was made – that contributors were overcompensated. Now markets look to impose the reverse.\nThere are probably some creative ways to make this work, or at least provide upper and lower ranges where additional OP is provided or OP is held back.\n\n post by LauNaMu on Apr 10, 2025\n\n LauNaMu\n\n Some questions:\n\nDoes this mean that any of the people suggested for the Genesis Cohort will have to abstain for participating in any other Govenance elected/appointed role for the next two seasons?\n\n post by lavande on Apr 11, 2025\n\n lavande\n\n Yep, that is correct\n\n 13 days later\n\n post by 0xDonPepe on Apr 24, 2025\n\n 0xDonPepe\n\n I’m casting a “FOR” vote on the Budget Board Charter. I’m not wild about the current draft, but having something in place is still better than what we’ve lived with.\nHere’s what I wish had made it into the charter:\n1. More community voice in seat selection\nRight now the Charter lets the Foundation hand-pick the entire Genesis cohort (and possibly future cohorts). Instead, I would’ve suggested:\n\nHybrid intake: Foundation nominates one member per House, the rest filled through open elections.\n\nCap insider seats and publish a clear scoring rubric so the Board feels earned, not appointed.\n\n2. A roadmap to community-authored Mission scopes\nEven with a community budget board, the Foundation still writes every Mission scope. Instead, I would’ve suggested:\n\nSunset OKR: by the end of Season 9, at least 30 % of Mission scopes must originate from delegates or the Board; majority community authorship by Season 10.\n\nAppreciate everyone’s work so far; let’s keep iterating towards decentralization.\n\n post by yoseph on Apr 30, 2025\n\n yoseph\n\n I am voting For this proposal because it is a good direction overall for the Collective.\nIn conjunction to that, I still feel a vision & strategy element of ‘where is the Collective ultimately going’ still missing, and this gets more pronounced when we bifurcate governance.\nOperational excellence, accountability, decentralization, transparency and similar values of ‘how’ we do things are all valuable things to aim for - setting up a Budget Board is helpful in that direction.\nWhat I’d like to humbly propose is that for the Budget Board (and hopefully every other governance body), part of the role to be about actively asking: “what does the world actually need” in light of what we are currently able to offer the world, and where we could be positioned to offer in the future. By the ‘world’, I am referring to the world outside out of the crypto industry circle of governance and decentralization fans.\nAn additional eligibility criteria to these governance bodies would then be something like “the ability to deeply listen and critically inquire what the world needs”\nI find this crucial so we don’t repeat the same mistakes in the formation of government bureaucracies, where the bureaucracy becomes the end goal and it loses touch with the idea of existing for an external purpose.\nWhen high caliber folks are picked to key positions like this, we should make it their mandate to also zoom out and ask the deeper questions and feed that to the Collective system, not just optimize internal processes. I believe budgeting and financial decisions are the best place to bring in such zoomed out lenses.\n\n post by diegoxxy on May 5, 2025\n\n diegoxxy\n\n Overall, I support the proposal. It lays out a clear structure for efficient financial management and decision-making, backed by data and accountability. The approach fosters long-term stability and growth for the DAO, while ensuring that resources are allocated transparently.\n\n Related topics\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 and 9: Budget Board Member Ratification\n\n Elections 💼\n\n season-7\n\n Season 8 and 9: Budget Board Member Ratification\nContext\n\nFor full context on the Budget Board, please read the Budget Board Charter. \n\nThe Foundation is proposing to appoint the following members to the Budget Board, as…\n\n read more\n\n 12\n\n 821\n\n Feb 5\n\n Seasons 8 and 9 Budget Board Communication Thread\n\n Elections 💼\n\n The Budget Board is an advisory board that exists to help the Collective bootstrap critical infrastructure and frameworks to enable the Collective to make sound financial and economic decisions. \nThe Budget Board’s Seaso…\n\n read more\n\n 16\n\n 516\n\n Jan 19\n\n Season 8 Council and Board Mandate Guidance\n\n Elections 💼\n\n season-8\n\n Timeline for Prospective Leads\n\n Note: Council terms will now last 12 months. Elected members will serve for Seasons 8 and 9. \n\nJune 13th - June 23rd: Charter Amendments\n\nAll Lead candidates can draft and post C…\n\n read more\n\n 5\n\n 383\n\n Jul 2025\n\n [FINAL] Budget Board Advisory Proposal for the DAO Operating Budget for Seasons 8 and 9\n\n Elections 💼\n\n Budget Board Advisory Proposal for the DAO Operating Budget for Seasons 8 and 9 (Updated)\nThe following is a non-binding proposal for the Collective to consider in passing a DAO Operating Budget for Seasons 8 and 9. The …\n\n read more\n\n 32\n\n 1.7k\n\n Jul 2025\n\n Ed Mazurek - Developer Advisory Board Operating Budget\n\n Elections 💼\n\n season-6\n\n Developer Advisory Board Operating Budget\nProposed Board Lead: Ed Mazurek (wildmolasses) \nProposed Board Operating Budget: 122,000 OP (+52,000 OP from last Season) \nContact Info: changes@gmail.com \nGoals of this proposal…\n\n read more\n\n 7\n\n 876\n\n May 2024","tokens":4628,"squid":"spider-07","role":"Council Spider","at":1791346610561,"hash":"420b08be8bedd54c5d31cc06683d3aa6ebc27ef8"}
{"url":"https://forum.across.to/t/across-governance-operating-manual/1447","domain":"forum.across.to","title":"Across Governance Operating Manual - WELCOME 👋 - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n Across Governance Operating Manual \n\n WELCOME 👋\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Nov 2022\n\n 1 / 1\n\n Nov 2022\n\n Nov 2022\n\n post by Britt on Nov 27, 2022\n\n Britt\n\n Overview\nThe Across governance process will evolve to meet the needs of Across DAO as it grows, and this is a living document. Anyone can participate in the Across Governance process, and anyone with ACX voting power can vote on proposals.\nPresently, tokenholders control treasury spending and updates to governance.\nGovernance Components\nThe Across Governance process follows the pathway from ideation, to draft, to proposal, to implementation. Anything subject to governance will follow this path and be decided on by ACX tokenholders.\nGovernance Toolkit:\n\nForum: A platform for discussion and deliberation on governance proposals\nSnapshot: A platform for where all governance proposals are submitted for vote\noSnap: a mechanism for trustless execution of snapshot votes. You can view our deployment of oSnap here.\n\nGovernance Participants:\nVoters - anyone who holds ACX, or ACX representative tokens that hold voting power, and participates actively in governance. This includes, but is not limited to, current or former team members who may freely vote with any ACX they have personally acquired or purchased, whether on secondary markets, through token allocations, or via compensation.\n\nACX (eth) = 1 vote\n\nAddress: 0x44108f0223A3C3028F5Fe7AEC7f9bb2E66beF82F\n\nAv2-ACX-LP = 1 vote\n\nACX tokens that have been provided as bridging liquidity within Across Protocol\nAddress: 0xb0C8fEf534223B891D4A430e49537143829c4817\n\nACX ST = 1 vote\n\nACX Success tokens. Min payout of 1 ACX, max payout of 2 ACX\nAddress: 0x4CBD49FCB56bBd06658103ab9fB3Ae0fAfFe365A\n\nStaked ACX LP = 1 vote\n\nStaked ACX LP tokens within Across.\nmultiplied by current exchange rate of ACX-LP to ACX\n\nStaked ACX Rewards\n\nUnclaimed rewards accrued for all staked LP tokens within Across.\nCustom strategy for staked voting can be seen here.\n\nAcross Council - The Council executes approved Snapshot proposals prior to the implementation of optimistic governance. The current signers are Risk Labs representatives.\n\nAcross DAO Ethereum Safe: 0xB524735356985D2f267FA010D681f061DfF03715\n\nAcross DAO Optimism Safe: 0xfd0CF79C568c08b78484F2D165eB8c7f569BdCf9\n\nAcross DAO Arbitrum Safe: 0xd16D904b68429b93F1DFCD837F61AeDCd224e8F4\n\nAcross DAO Polygon Safe: 0x5BCBeBAFb2934400525FA53CF74f26Fe4cf75A5B\n\nThreshold: 3/5\n\nSigners (same addresses on each chain):\n0x1d933Fd71FF07E69f066d50B39a7C34EB3b69F05\n0x868CF19464e17F76D6419ACC802B122c22D2FD34\n0x837219D7a9C666F5542c4559Bf17D7B804E5c5fe\n0x996267d7d1B7f5046543feDe2c2Db473Ed4f65e9\n0xcc400c09ecBAC3e0033e4587BdFAABB26223e37d\n\nCommittees - Subject matter experts that consider and pursue goals specific to their domain, acting in the best interests of the Across DAO. Committees are able to make updates to parameters without the need for a full tokenholder voting cycle, allowing the bridge to remain adaptive. Shortly after launch, RL will upgrade the protocol to allow for committee implementation.\nProposal Types:\n\nTreasury Funding\nGovernance Updates\nCommittee implementation or replacement (future)\nProtocol upgrades (future)\n\nType\nDescription\nSubmission requirements\nVote Duration\nQuorum\nSoft Quorum\nApproval Threshold\n\nTreasury Funding - Large\nTreasury distributions to proactively encourage the growth and development of the Across ecosystem valued at $150,000 or higher\nForum + Snapshot\n7 days + time required for steps 1 and 2 in voting cycle\n12.5M\nNo\n66%\n\nTreasury Funding - Medium\nTreasury distributions to proactively encourage the growth and development of the Across ecosystem valued between $50,000 - $150,000\nForum + Snapshot\n7 days + time required for steps 1 and 2 in voting cycle\n12.5M\nNo\n51%\n\nTreasury Funding - Small\nTreasury distributions to proactively encourage the growth and development of the Across ecosystem valued below $50,000\nForum + Snapshot\n7 days + time required for steps 1 and 2 in voting cycle\n12.5M\nYes\n51%\n\nGovernance Updates\nA vote to update a component of Across governance system.\nForum + Snapshot\n7 days + time required for steps 1 and 2 in voting cycle\n12.5M\nYes\n51%\n\nCommittee implementation, removal, or replacement\nA vote to introduce a new committee or replace an existing committee\nForum + Snapshot\n7 days + time required for steps 1 and 2 in voting cycle\n12.5M\nYes\n51%\n\nSoft Quorum\nFor votes that do not reach Quorum, assume that 70% of the votes necessary to achieve quorum would be against the proposal. If this would still result in a majority of votes being in favor of the proposal, the proposal can be considered passed. Not all proposal types are eligible for soft quorum (see table above). This Soft Quorum Calculator can be used to evaluate how a proposal would resolve under these rules.\nNote: Risk Labs has historically acted as the only builder of Across Protocol. In order to enable others to contribute at a protocol level, we are in the process of outlining the protocol parameters and requirements for a protocol upgrade template. Stay tuned for more details.\nComposing Committee Proposals:\nThis proposal type should include the following components in addition to those required in the current proposal template:\n\nPurpose of the committee. What is the value added for Across?\nScope of the committee. What work will they be responsible for?\nReporting requirements and frequency. How can tokenholders assess the quality of work done by the committee? What time interval is appropriate for their job?\nIntended lifespan of the committee. Is this a special purpose committee, or will it fulfill a role that the protocol needs continuous support on?\nComposition of the committee. Include a link to bio of each member and outline their participation in Across up until now. Share any relevant experiences or qualifications they have. At minimum we’d like to see discord handle, twitter handle, an Across active wallet, and a bio for each member.\nStarting monthly budget breakdown. Committees may manage a small amount of capital to meet the needs of their operational purpose. If applicable, include information about the address that is intended to be used for operational funds. This budget does not include committee compensation. Committees will receive their budgeted funds at the start of each month from the Across DAO Treasury. Whenever possible, this amount should be limited to 1 month of operating expenses at a time.\nBrief overview of committee operations (general workflow, communication channels, expected outputs, etc.)\nIf the proposal is to remove or replace a committee, it should still address the above components.\n\nCommittee - tokenholder relationship:\nBy voting to form a committee, tokenholders are voting to entrust and delegate a specific set of decision-making responsibilities to the committee. It is, therefore, ACX tokenholders that each committee is accountable to. If a committee fails to perform, it is the duty of ACX tokenholders to replace or remove the committee from service in a reasonable amount of time.\nCommittee Membership:\nCommittees should include no more than 5 and no fewer than 3 members, each of which should have relevant experience and/or qualifications to support their presence in the committee. It is recommended to designate a committee lead, who would be held responsible for the coordination and reporting on behalf of the committee.\nAll committees are compensated by the Across DAO Treasury in the same way. Upon approval, a committee will receive a base level of rewards in the amount of $10k equivalent in $ACX. This amount is meant to last for a 3-month period. It is up to each committee to determine the distribution of these tokens, the details of which must be included in the snapshot vote. This should include wallet addresses and amounts for each committee member.\nAt the end of each quarter of service, a committee will be given an additional $10k equivalent in $ACX, except in the case of a committee being removed from service by tokenholders during that quarter, in which case there will be no additional rewards. The distribution of these funds will be determined by the committee members by way of a peer review score. This is to be paid out by the Across DAO Treasury.\nCommittees that are composed of Risk Labs representatives will not receive compensation from the DAO.\nNote: the peer review process will be found in more detail in a new “committee” section of the forum after this proposal is passed. The template for peer review (TBD) should be evaluated regularly and updated as needed to meet the needs of committee participants. Because this process only effects the distribution of funds amongst committee members and does not change the amount of funds designated to a committee, this template can be updated whenever there is a soft consensus that it’s necessary (no formal vote required).\nCommittee Tools:\n\nDiscord - to be used for general communication between committees and tokenholders.\nForum - to be used for more formal committee reporting, and committee peer reviews.\n\nProcess\nStep 1: Request for comment (Forum)\nPost a proposal draft in Ideas and Feedback in Forum. Collect feedback from the community and update the proposal as needed. There is no hard timeline on this step, but proposals that don’t take this step seriously are not likely to pass. Once your idea is ready to submit as a proposal, it will need to follow the template below, so you should consider drafting your idea in this format to start. You can also find this template here.\n\nHeader\nTitle: (enter proposal title)\nAuthor(s): (enter name(s) of associated authors)\nStatus: (RFC, Proposal, Vote)\nRelated Discussions: (optional - paste link here)\nSubmission Date: (Enter Date)\nBody\nSummary:\nGive us a TL;DR on your proposal; no more than 2-3 sentences.\nMotivation:\nWhat problems will this proposal address/solve? What’s the value-add?\nSpecification & Implementation:\nDescribe the proposal in as much detail as is necessary. Explain the vision for the proposal. How will this affect the protocol both technically, socially, financially (if applicable), and governance-wise? What steps need to be taken to implement this proposal?\nRationale:\nExplain any decisions above that were chosen over an alternative. Why is this the best way to do it? How will the implementation of this proposal advance the protocol?\nDownside (Cons):\nAre there any disadvantages with implementing the proposal? Are there any security considerations or potentially negative financial exposures to consider?\nVoting:\nDefine what a “yes” and “no” vote entails. Once the proposal moves to a vote, please include the link to Snapshot here.\n\nStep 2: Request to proceed (Forum)\nAfter implementing any changes to the proposal based on feedback received in step 1, you should present a final draft in the Proposal section of forum and request to proceed to snapshot. If applicable, you should include the appropriate tag for your proposal when creating your post. You will also want to make sure to include a link to your discussion draft in the final proposal.\nAny Forum admin can review the proposal for format compliance and provide an indication that the proposal can move to snapshot. This is not an indication of support for the ideas in the proposal, but rather an indication that the proposal meets the requirements needed to move to a vote. Proposals that are not properly formatted should not move to a formal vote.\nStep 3: Formal vote (Snapshot)\nProposals that have been approved in step 2 are ready to be voted on and may be posted to snapshot with a 7 day voting period. A proposer must have a voting weight of at least 20,000 ACX in order to submit a proposal. If you do not meet the requirement for submitting a proposal, a qualified voter may post the proposal on your behalf if they wish to do so.\nStep 4: Results\nIf a proposal passes Snapshot, it will be executed by the Across DAO Safe. Across uses a governance solution called oSnap to optimistically execute the on-chain results of passing Snapshot votes. At this time that includes Treasury funding proposals. Protocol upgrades are still handled by the Across Council mentioned above.\nSummary of oSnap implementation:\noSnap is a Snapshot plugin built by the UMA team that will allow anyone to propose transactions, do an off-chain governance vote, and have the transaction data submitted in a trustless fashion. After a transaction execution is proposed, it must pass through a liveness period, during which time anyone may dispute its validity. Risk Labs has set up a robust combination of monitoring tools to alert in several locations whenever an execution transaction is proposed. This includes both the UMA and Across discords, the Optimistic Oracle UI, and Risk Labs internal alert channels. In the event that a proposal is disputed, it will escalate to UMA’s DVM for settlement by $UMA tokenholders, which will use human-readable rules to determine the validity of the proposed transaction. Across has opted to deploy oSnap using conservative parameters to start, which can be adjusted over time through governance.\nStarting Parameters:\nCollateral: WETH\nBond: 10\nLiveness: 5 days\nSnapshot space: https://snapshot.org/#/acrossprotocol.eth\nVoting quorum: 12,500,000\nVoting period: 168 hours\nRules Parameter (human-readable rules):\nI assert that this transaction proposal is valid according to the following rules: Proposals approved on Snapshot, as verified at https://snapshot.org/#/acrossprotocol.eth, are valid as long as there is a minimum quorum of 12500000 and a minimum voting period of 168 hours and it does not appear that the Snapshot voting system is being exploited or is otherwise unavailable. The quorum and voting period are minimum requirements for a proposal to be valid. Quorum and voting period values set for a specific proposal in Snapshot should be used if they are more strict than the rules parameter. The explanation included with the on-chain proposal must be the unique IPFS identifier for the specific Snapshot proposal that was approved or a unique identifier for a proposal in an alternative voting system approved by DAO social consensus if Snapshot is being exploited or is otherwise unavailable.\nAcross’ deployment of oSnap can be viewed on-chain here.\n\n [RFC - Governance update] Proposal to adjust voting quorum and approval threshold\n\n Across Community Essentials Committee Formation\n\n Across Community Essentials Committee October 2023 Report\n\n Across DAO Handbook\n\n Across Community Essentials Committee Renewal Proposal for Q2-Q3 2024\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 Across Treasury Committee Formation Proposal\n\n Proposals\n\n governance-updates\n\n Proposals\n\n 13\n\n Nov 2023\n\n Welcome to Across\n\n WELCOME 👋\n\n WELCOME 👋\n\n Nov 2022\n\n [RFC - Governance Update] Committee Formation Criteria\n\n Passed Proposals\n\n governance-updates\n\n Passed Proposals\n\n 13\n\n Feb 2023\n\n [RFC - Governance update] Proposal to adjust voting quorum and approval threshold\n\n Passed Proposals\n\n governance-updates\n\n Passed Proposals\n\n 11\n\n Mar 2023\n\n Across Token Launch Proposal v2\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 47\n\n Nov 2022","tokens":5309,"squid":"spider-09","role":"Bridge Spider","at":1791346610616,"hash":"f208a54d67e44ee609f857aeffbc98b97a241d3b"}
{"url":"https://gov.optimism.io/t/the-collective-feedback-commission-the-next-iteration/9113","domain":"gov.optimism.io","title":"The Collective Feedback Commission: The Next Iteration - 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 The Collective Feedback Commission: The Next Iteration \n\n Governance Design and Strategy 📐Metagovernance\n\n season-7\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Oct 2024\n\n 1 / 7\n\n Oct 2024\n\n Jun 2025\n\n post by system on Oct 23, 2024\n\n system\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 Constitution, the Foundation’s role is to bootstrap the governance system of the Collective over multiple years, gradually bringing more governance rights online until the system can manage itself. Metagovernance refers to the ability to propose changes to the design of the governance system. Given the importance of this responsibility, metagovernance is the last governance responsibility that will be transferred to the community.\nThe CFC serves as an experimental training ground to develop a “Core Governance Program” that will allow the Collective to take on metagovernance responsibilities in the future. The inspiration for this program is Core Development Programs. The goal of the CFC is to enable the Foundation to become just one of many Core Governors proposing metagovernance proposals in the future (similar to how OP Labs is just one of many Core Developers proposing protocol upgrades.)\nThis will require a multi-year, gradual, and iterative process. The CFC began with an initial six month pilot in which members were primarily “consulting the Foundation on early design drafts requiring a high degree of context.” You can see the full pilot retrospective here.\nBased on the impact of the pilot, the Foundation has decided to continue iterating with the CFC. Iterations of the Commission will gradually increase the set of member responsibilities over time as well as increase the number of members the Commission can support.\nThe next iteration of the Commission will launch on November 4th. Qualifying participants will be notified by October 28th and will be required to opt-in and KYC by November 1st.\nPlease note that while we will continue the Commission, we will be postponing the launch of the open contribution path component until we have further refined the best format to accomplish the longer term goals of the Commission. It is one full workstream to design how the Commission works and another workstream to create the contribution path that supports it. We are still committed to supporting this path in the future, but need to focus our efforts on the refinement and development of the core workstream first. We will continue to invest in the many opportunities outside the Commission for the broader community to provide feedback to the Foundation.\nimage_with_white_background_22048×499 53.2 KB\nSeason 7 Collective Feedback Commission Charter\nSeason 7 CFC Goals\nThe next iteration of the CFC will begin on November 4th and run through the end of Season 7.\n\nGoals:\n\nAllow members to gain more insight into the Foundation’s approach to governance design, building shared context around the how and why\nCreate a more collaborative working process between the Foundation and the Commission, involving Commission members in the earlier stages of our design process: planning and research\nAllow for member specialization based on level and type of expertise, accomplished via the distinct tracks outlined below\nAllow members to have more agency over lower stakes design parameters\n\nNon-goals:\n\nThe pilot made it obvious that we need to further refine the Foundation’s working relationship with the CFC before we can ask members to develop the lower levels of the contribution path and mentor new participants. We are still committed to the development of this contribution path in the future and would recommend joining the govNERDS contribution path to build up relevant knowledge and skills in the meantime (join the wannabe-govnerds channel in Discord for more info!)\n\nAs always, after each version, there will be a participant survey and retrospective workshop to inform the next iteration. You can find the pilot retrospective here.\nSeason 7 CFC Structure\nimage_with_white_background2048×1204 136 KB\nParticipants\nThe Collective Feedback Commission will be split into three different tracks to allow for different levels of engagement and to accommodate different types of expertise.\n\nOptimization: Members will refine, optimize, and adapt existing processes or programs they have first hand experience with\n\nOperational (Governance Processes)\n\nFocus areas: Token House Process, Citizens’ House Process, User Testing\nMembership: 3 members; based on demonstrable knowledge of processes\nFoundation Track Lead: @op_julian\nExpected Hours per month: Up to ~3\nLevel of agency: Write access\nInformed about Organizational work; attends all Commission meetings\n\nOrganizational (Governance Structures)\n\nFocus areas: Onboarding Flows, Autonomous Operations, Evolving Mandates\nMembership: 5 members; All Council, Board, and Commission Leads\nFoundation Track Lead: @maxwell\nExpected Hours per month: Up to ~5\nLevel of agency: Edit access\nInformed about System Design work; attends select Foundation meetings\n\nDesign Research: Members will work directly with the Foundation via “Project Partnerships,” supporting the Foundation in one of the earlierst stages of the design process: Research\n\nFocus areas: Research, Evaluation Algorithms, Selection Algorithms, Voting Design, Decentralization\nMembership: Up to 10 members; based on demonstrable expertise\nFoundation Track Lead: @lavande\nExpected Hours per month: Up to ~8\nLevel of agency: Read + research access\nWork directly with the Foundation team via “Project Partnerships”\n\nEach track will have a Foundation Lead. Simona Pop, a Foundation Advisor, will serve as the Commission Lead. Foundation Leads will facilitate context sharing between the Commission and the Foundation. The Commission Lead will manage Commission operations and hold the Foundation accountable to executing on this Charter.\n*There will be 18 eligible members. Qualification of members will based on demonstrable contributions/attestations relevant to each area of required expertise. All members must opt-in to participate. The full list will be added as a comment to this post on October 25th. The CFC is an experiment and membership models are subject to change with each iteration. We will continue to invest in the many opportunities outside the Commission for the broader community to provide feedback to the Foundation.\nNote: Pilot membership was determined via delegation rankings in the Token House and via demonstrable contributions in the Citizens’ House. This led to a high degree of overlap between members of the CFC and other leadership roles in the Collective. The current iteration experiments with selection based on expertise. We are likely to continue experimenting with different selection methods in future iterations.\nSeason 7 Responsibilities\n\nIndividual members of the Collective Feedback Commission will:\n\nProvide feedback on early Foundation design drafts, roadmaps, frameworks, etc.\n\nParticipate in broader design discussions with the Foundation via monthly meetings\n\nProvide feedback on community authored Mission Requests to ensure they align with Season 7 Intents and/or other strategic initiatives\n\nExecute on contributions as scoped by the Foundation (members of the Design Research track will do this via Project Partnerships)\nNote: The Foundation will use feedback from Commission members as an input but is not obligated to incorporate any individual piece of feedback or implement the recommendations in any contribution. Commission feedback will be shared with the Foundation and other Commission members, and may be made publicly viewable by the entire community at the end of the Commission’s term. The Foundation will provide summaries of the impact of all contributions.\n\nFoundation Track Leads will:\n\nTo the best of our ability, request feedback on regular feedback cycles. Project Partnerships will be scoped with clear deliverables and deadlines.\n\nHost monthly calls with the Foundation governance design team to share context and facilitate a two-way dialogue with Commission members.\n\nPropose a selection mechanism that determines which members claim specific pieces of work, subject to simple majority approval by members at the start of the term.\n\nThe Commission Lead will:\n\nOnboard new Commission members, ensuring they are familiar with the CFC’s processes, mission, and operational structure. This includes providing any necessary documentation or training to help them contribute effectively from the start.\n\nPropose the evaluation algorithm by which rewards will be distributed to individual members at the start of the term, subject to majority (51%) approval (see “Rewards” section below).\n\nEnsure members of each track are executing on their responsibilities in a timely manner and flag any blockers to execution to the Foundation.\n\nFacilitate feedback loops and coordination between Commission members and the Foundation, when needed, holding the Foundation accountable to this Charter.\n\nOrganize regular Commission meetings, as desired by members. The frequency of internal meetings is at the discretion of the Commission Lead but should be aligned with governance minimization.\n\nAuthoring, or coordinating authorship, of any regular communication reports circulated to the broader community.\n\nConduct feedback survey, facilitate peer reviews, and host retrospective workshop at the end of the Commission’s term to inform the next iteration\nNote: Leads are operational roles, meaning they do not engage in the day-to-day activities of the team but rather manage the operations of the team. This means Leads don’t review, vote, or sign but they may exercise decision-making authority in the event that the commission cannot come to consensus on a matter (ie. serve as tie breaker). Leads may also draft any applications for impact evaluation of the Commission, although we don’t expect Retro Funding to be applicable to the Commission’s work in Season 7 (see below.)\n\nSeason 7 Rewards\n\nThe CFC will be allocated 100,000 OP by the Foundation. The Commission Lead will be compensated separately, via an agreement with the Foundation. These tokens will come out of the Unallocated Portion of the treasury, managed by the Foundation, since the CFC provides a valuable service to the Foundation. We are providing these rewards as we believe the work of the Commission is difficult to evaluate retroactively and therefore the CFC’s work should not depend on being eligible for Retro Funding. Retro Funding is best suited to evaluating measurable and permissionless impact, whereas the Commission’s work is hard to measure and is currently permissioned to members selected by the Foundation. The level of impact generated by the Commission might also be higher or lower in a given season due to factors outside the Commission’s control, such as the Foundation’s experiment design.\nMembers will vote via simple majority to approve an evaluation algorithm, proposed by the Lead at the start of the term, via which rewards will be allocated from this budget at the end of the season.\nThe Lead will calculate individual rewards based on the approved evaluation algorithm at the end of the Season and rewards should be allocated accordingly. The Foundation recommends a minimum 48 hour dispute window to allow members to verify the correct application of the evaluation algorithm before contacting the Foundation to deliver rewards.\n\nSeason 7 Success\n\nNumber of new ideas proposed and implemented as a result of Commission input (> 8)\n\n% of drafts in which feedback was ranked as “high value” by the Foundation (> 70%)\n\nNPS score from Foundation governance team (= > 5/7)\nThe below measures will be used to evaluate the success of the Foundation in managing this program:\n\nMember ranking of clarity of role 8.5+ (up from 7.7/10 in v1)\nMember ranking of clarity of responsibilities 9+ (up from 7.6/10 in v1)\nMember ranking of Commission efficacy 8.5+ (up from 6.9/10 in v1)\n\n CFC S7 - Internal Operating Procedures (IOP)\n\n OP Bulletin: Weekly news and insights on the Optimism Collective \n\n Governance Weekly Recap\n\n Season 7: Retro Funding Missions\n\n Season 7: Intent\n\n 2\n\n read \n\n 5\n min\n\n Unlisted on Oct 23, 2024\n\n Listed on Oct 23, 2024\n\n post by lavande on Oct 25, 2024\n\n lavande\n\n Season 7 Membership has been posted here and will run from ~November 2024 - June 2025.\nAll members will be contact by @op_julian from the Foundation team to complete an opt-in form and KYC. Members that opt-in by November 1st will receive an email invite to an onboarding call hosted on November 4th at 15:00 GMT.\nWhile we can’t select everybody to participate, there are many avenues for community feedback and contribution, and the Commission is just one. The Foundation remains committed to actively incorporating community feedback, regardless of where it comes from. We are likely to continue experimenting with different selection methods which may result in different members in the future.\n\n 8 months later\n\n post by system on Jun 12, 2025\n\n system\n\n The Foundation would like to extend a heartfelt thank you to the Collective Feedback Commission for all their contributions over the past year. The Collective’s evolution depends on contributors’ willingness to experiment, iterate, and try new things and we appreciate the willingness of members of the commission to do just that.\nThe original vision of the Collective Feedback Commission was to create a sort of “core governor” program that would work to establish metagovernance processes for the Collective, taking inspiration from core development programs. While members’ contributions have informed and influenced metagovernance design over the past two Seasons, the vision of the CFC no longer aligns with our broader vision about the purpose and evolution of Optimism Governance (see more HERE.)\nThe next phase of governance is about optimizing the system to reduce platform risk. Allowing for governance participants to propose major changes to the governance system, especially at early stages, introduces a very high degree of platform risk.\nInstead of further developing the CFC, we will work to further reduce the metagovernance surface area to a minimal set of parameters in the Operating Manual. Over time, these parameters will be transitioned onchain and a permissioned process to update them will be introduced as you can see reflected in the updated Decentralization Milestones. The decision to discontinue the CFC is about alignment with a new stage of governance maturity, and is in no way a reflection of the value of the contributions members.\nAs always, the Foundation will continue to solicit and incorporate input from community members, just without the formalized structure of a dedicated commission.\n\n Season 8 Council and Board Mandate Guidance\n\n Optimism Working Models for Decentralization\n\n Optimism Gov Summary\n\n Token House participation and incentives: Season 7 (Cycle 31a-38)\n\n Unlisted on Jun 12, 2025\n\n Listed on Jun 12, 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 Collective Feedback Commission Communication Thread\n\n Council Communication Threads\n\n Welcome to the CFC Communication Thread!\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 Constitution, the Fo…\n\n read more\n\n 1\n\n 168\n\n Feb 2025\n\n Introducing the Collective Feedback Commission\n\n Metagovernance\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 Collective Feedback Commission Pilot Retrospective\n\n Metagovernance\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 303\n\n Oct 2024\n\n Season 7: CFC Membership\n\n Metagovernance\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 CFC - Season 7 Retrospective\n\n Elections 💼\n\n retrospective\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? \nThe Collective Feedback…\n\n read more\n\n 0\n\n 83\n\n Jun 2025","tokens":4258,"squid":"spider-07","role":"Council Spider","at":1791346621374,"hash":"f3000226fb3d685d4bc8323b4cd631ee7f1b7e49"}
{"url":"https://www.metaplex.com/docs/smart-contracts/core/fetch","domain":"metaplex.com","title":"Fetching Assets | Metaplex Core","text":"This guide shows how to fetch Core Assets and Collections from the Solana blockchain using the Metaplex Core SDK. Retrieve individual Assets, query by owner or collection, or use DAS for indexed queries. What You'll LearnFetch a single Asset or Collection by addressQuery Assets by owner, collection, or update authorityUse DAS (Digital Asset Standard) API for fast indexed queriesUnderstand GPA vs DAS performance trade-offsSummaryFetch Core Assets and Collections using SDK helper functions or the DAS API. Choose the right method based on your use case:Single Asset/Collection: Use fetchAsset() or fetchCollection() with the public keyMultiple Assets: Use fetchAssetsByOwner(), fetchAssetsByCollection(), or fetchAssetsByUpdateAuthority()DAS API: Use indexed queries for faster performance (requires DAS-enabled RPC)Out of ScopeToken Metadata fetching (use mpl-token-metadata), compressed NFT fetching (use Bubblegum DAS extensions), and off-chain metadata fetching (fetch the URI directly).Quick StartJump to: Single Asset · By Owner · By Collection · DAS APIInstall: npm install @metaplex-foundation/mpl-core @metaplex-foundation/umiConfigure Umi with your RPC endpointCall fetchAsset(umi, publicKey) with the Asset addressAccess Asset properties: name, uri, owner, pluginsPrerequisitesUmi configured with an RPC connectionAsset/Collection address (public key) to fetchDAS-enabled RPC for indexed queries (optional but recommended)Fetch a Single Asset or CollectionTo fetch a single Asset the following function can be used:1import { fetchAsset, fetchCollection, mplCore } from '@metaplex-foundation/mpl-core';\n2import { publicKey } from '@metaplex-foundation/umi';\n3import { createUmi } from '@metaplex-foundation/umi-bundle-defaults';\n4\n5// Initialize UMI\n6const umi = createUmi('https://api.devnet.solana.com')\n7 .use(mplCore())\n8\n9// Fetch a Core Asset\n10const assetAddress = publicKey('AssetAddressHere...')\n11const asset = await fetchAsset(umi, assetAddress)\n12\n13// Fetch a Core Collection\n14const collectionAddress = publicKey('CollectionAddressHere...')\n15const collection = await fetchCollection(umi, collectionAddress)\n16\n17console.log('Asset fetched:', asset)\n18console.log('Name:', asset.name)\n19console.log('Owner:', asset.owner)\n20console.log('URI:', asset.uri)\n21\n22console.log('\\nCollection fetched:', collection)\n23console.log('Name:', collection.name)\n24console.log('URI:', collection.uri)\nFetch a Core Collectionimport { fetchCollection } from '@metaplex-foundation/mpl-core'\nconst asset = await fetchCollection(umi, collection.publicKey, {\n skipDerivePlugins: false,\n})\nconsole.log(asset)\nFetch Multiple AssetsMultiple Assets can either be fetched using a getProgramAccounts (GPA) call, which can be quite expensive and slow RPC-wise, or using the Digital Asset Standard API, which is faster but requires specific RPC providers.Fetch Assets By Ownerfetch Assets by Ownerimport { publicKey } from '@metaplex-foundation/umi'\nimport { fetchAssetsByOwner } from '@metaplex-foundation/mpl-core'\nconst owner = publicKey('11111111111111111111111111111111')\nconst assetsByOwner = await fetchAssetsByOwner(umi, owner, {\n skipDerivePlugins: false,\n})\nconsole.log(assetsByOwner)\nFetch Assets by CollectionFetch Assets by Collectionimport { publicKey } from '@metaplex-foundation/umi'\nimport { fetchAssetsByCollection } from '@metaplex-foundation/mpl-core'\nconst collection = publicKey('11111111111111111111111111111111')\nconst assetsByCollection = await fetchAssetsByCollection(umi, collection, {\n skipDerivePlugins: false,\n})\nconsole.log(assetsByCollection)\nFetch Assets by Update AuthorityTo fetch a single Asset the following function can be used:Fetch a single assetimport { publicKey } from '@metaplex-foundation/umi'\nimport { fetchAssetsByUpdateAuthority } from '@metaplex-foundation/mpl-core'\nconst updateAuthority = publicKey('11111111111111111111111111111111')\nconst assetsByUpdateAuthority = await fetchAssetsByUpdateAuthority(\n umi,\n updateAuthority,\n { skipDerivePlugins: false }\n)\nconsole.log(assetsByUpdateAuthority)\nDAS - Digital Asset Standard APIIf you use a DAS enabled RPC you'll be able to take advantage of indexed Assets for lighting fast fetches and data retrieval. DAS will index everything from metadata, off chain metadata, collection data, plugins (including Attributes), and more. To learn more about the Metaplex DAS API you can visit the Metaplex DAS API page. In addition to the general DAS SDK an extension for MPL Core has been created that directly returns you the correct types to further use with the MPL Core SDKs. It also automatically derives the plugins in assets inherited from the collection and provides functions for DAS-to-Core type conversions. Below is an example of returned data from fetching a MPL Core Asset with DAS.FetchAsset Example{\n \"id\": 0,\n \"jsonrpc\": \"2.0\",\n \"result\": {\n \"authorities\": [\n {\n \"address\": \"Gi47RpRmg3wGsRRzFvcmyXHkELHznpx6DxEELGWBRWoC\",\n \"scopes\": [\"full\"]\n }\n ],\n \"burnt\": false,\n \"compression\": {\n \"asset_hash\": \"\",\n \"compressed\": false,\n \"creator_hash\": \"\",\n \"data_hash\": \"\",\n \"eligible\": false,\n \"leaf_id\": 0,\n \"seq\": 0,\n \"tree\": \"\"\n },\n \"content\": {\n \"$schema\": \"https://schema.metaplex.com/nft1.0.json\",\n \"files\": [],\n \"json_uri\": \"https://example.com/asset\",\n \"links\": {},\n \"metadata\": {\n \"name\": \"Test Asset\",\n \"symbol\": \"\"\n }\n },\n \"creators\": [],\n \"grouping\": [\n {\n \"group_key\": \"collection\",\n \"group_value\": \"8MPNmg4nyMGKdStSxbo2r2aoQGWz1pdjtYnQEt1kA2V7\"\n }\n ],\n \"id\": \"99A5ZcoaRSTGRigMpeu1u4wdgQsv6NgTDs5DR2Ug9TCQ\",\n \"interface\": \"MplCore\",\n \"mutable\": true,\n \"ownership\": {\n \"delegate\": null,\n \"delegated\": false,\n \"frozen\": false,\n \"owner\": \"Gi47RpRmg3wGsRRzFvcmyXHkELHznpx6DxEELGWBRWoC\",\n \"ownership_model\": \"single\"\n },\n \"plugins\": {\n \"FreezeDelegate\": {\n \"authority\": {\n \"Pubkey\": {\n \"address\": \"Gi47RpRmg3wGsRRzFvcmyXHkELHznpx6DxEELGWBRWoC\"\n }\n },\n \"data\": {\n \"frozen\": false\n },\n \"index\": 0,\n \"offset\": 119\n }\n },\n \"royalty\": {\n \"basis_points\": 0,\n \"locked\": false,\n \"percent\": 0,\n \"primary_sale_happened\": false,\n \"royalty_model\": \"creators\",\n \"target\": null\n },\n \"supply\": null,\n \"unknown_plugins\": [\n {\n \"authority\": {\n \"Pubkey\": {\n \"address\": \"Gi47RpRmg3wGsRRzFvcmyXHkELHznpx6DxEELGWBRWoC\"\n }\n },\n \"data\": \"CQA=\",\n \"index\": 1,\n \"offset\": 121,\n \"type\": 9\n }\n ]\n }\n}\nCommon ErrorsAsset not foundThe public key doesn't point to a valid Core Asset. Verify:The address is correct and on the expected network (devnet vs mainnet)The account exists and is a Core Asset (not Token Metadata)RPC rate limit exceededGPA queries can be expensive. Solutions:Use a DAS-enabled RPC for indexed queriesAdd pagination to limit resultsCache results where appropriateNotesfetchAsset returns the full Asset including derived plugins from the CollectionSet skipDerivePlugins: true to fetch only Asset-level plugins (faster)GPA queries (fetchAssetsByOwner, etc.) can be slow on mainnet - prefer DASDAS returns off-chain metadata; SDK fetch functions return on-chain data onlyQuick ReferenceFetch FunctionsFunctionUse CasefetchAsset(umi, publicKey)Single Asset by addressfetchCollection(umi, publicKey)Single Collection by addressfetchAssetsByOwner(umi, owner)All Assets owned by a walletfetchAssetsByCollection(umi, collection)All Assets in a CollectionfetchAssetsByUpdateAuthority(umi, authority)All Assets by update authorityDAS vs GPA ComparisonFeatureGPA (getProgramAccounts)DAS APISpeedSlow (scans all accounts)Fast (indexed)RPC LoadHighLowOff-chain MetadataNoYesRequires Special RPCNoYesFAQShould I use GPA or DAS for fetching multiple Assets?Use DAS whenever possible. GPA queries scan all program accounts and can be slow and expensive on mainnet. DAS provides indexed queries that are faster and include off-chain metadata. See DAS RPC providers for compatible endpoints.How do I fetch an Asset's off-chain metadata?The uri field contains the metadata URL. Fetch it separately:const asset = await fetchAsset(umi, assetAddress)\nconst metadata = await fetch(asset.uri).then(res => res.json())\nCan I fetch Assets across multiple Collections?Not in a single query. Fetch each Collection's Assets separately and combine the results, or use DAS with custom filters.Why is skipDerivePlugins useful?By default, fetchAsset derives Collection-level plugins onto the Asset. Setting skipDerivePlugins: true skips this step, returning only Asset-level plugins. Use this when you only need the Asset's own plugins or want faster fetches.How do I paginate large result sets?GPA functions don't support built-in pagination. For large collections, use DAS which supports page and limit parameters, or implement client-side pagination.GlossaryTermDefinitionGPAgetProgramAccounts - Solana RPC method to query all accounts owned by a programDASDigital Asset Standard - Indexed API for fast asset queriesDerived PluginA plugin inherited from the Collection onto an AssetskipDerivePluginsOption to skip Collection plugin derivation during fetchOff-chain MetadataJSON data stored at the Asset's URI (name, image, attributes)On-chain DataData stored directly in the Solana account (owner, plugins, URI)","tokens":2269,"squid":"dotcat","role":"Tooling Spider","at":1791346624340,"hash":"6ffcd0f6505a0af3c244e060a50af5ed2fa6e71e"}
{"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":"spider-05","role":"Spec Spider","at":1791346637215,"hash":"baa8cfd5a9c81107bdcc99628407293810bf59cc"}
{"url":"https://consensysdiligence.github.io/smart-contract-best-practices/general-philosophy/simplicity-vs-complexity/","domain":"consensysdiligence.github.io","title":"Simplicity vs. Complexity - Ethereum Smart Contract Best Practices","text":"Simplicity vs. Complexity\n\nTip\nFor comprehensive insights into secure development practices, consider visiting the Development Recommendations section of the Smart Contract Security Field Guide. This resource provides in-depth articles to guide you in developing robust and secure smart contracts.\n\nThere are multiple fundamental tradeoffs to consider when assessing the structure and security of a\nsmart contract system. The general recommendation for any smart contract system is to identify the\nproper balance for these fundamental tradeoffs.\nAn ideal smart contract system from a software engineering bias is modular, reuses code instead of\nduplicating it, and supports upgradeable components. An ideal smart contract system from a secure\narchitecture bias may share this mindset, especially in the case of more complex smart contract\nsystems.\nHowever, there are important exceptions where security and software engineering best practices may\nnot be aligned. In each case, the proper balance is obtained by identifying the optimal mix of\nproperties along contract system dimensions such as:\n\nRigid versus Upgradeable\nMonolithic versus Modular\nDuplication versus Reuse\n\nRigid versus Upgradeable¶\nWhile multiple resources, including this one, emphasize malleability characteristics such as\nKillable, Upgradeable or Modifiable patterns there is a fundamental tradeoff between malleability\nand security.\nMalleability patterns by definition add complexity and potential attack surfaces. Simplicity is\nparticularly effective over complexity in cases where the smart contract system performs a very\nlimited set of functionality for a pre-defined limited period of time, for example, a\ngovernance-free finite-time-frame token-sale contract system.\nMonolithic versus Modular¶\nA monolithic self-contained contract keeps all knowledge locally identifiable and readable. While\nthere are few smart contract systems held in high regard that exist as monoliths, there is an\nargument to be made for extreme locality of data and flow - for example, in the case of optimizing\ncode review efficiency.\nAs with the other tradeoffs considered here, security best practices trend away from software\nengineering best practices in simple short-lived contracts and trend toward software engineering\nbest practices in the case of more complex perpetual contract systems.\nDuplication versus Reuse¶\nA smart contract system from a software engineering perspective wishes to maximize reuse where\nreasonable. There are many ways to reuse contract code in Solidity. Using proven\npreviously-deployed contracts which you own is generally the safest manner to achieve code reuse.\nDuplication is frequently relied upon in cases where self-owned previously-deployed contracts are\nnot available. Efforts such as\nOpenZeppelin's Solidity Library seek to\nprovide patterns such that secure code can be re-used without duplication. Any contract security\nanalysis must include any re-used code that has not previously established a level of trust\ncommensurate with the funds at risk in the target smart contract system.","tokens":770,"squid":"spider-06","role":"Security Spider","at":1791346647630,"hash":"8a72b98bc43ef96f45a34141e34e81aef882847b"}
{"url":"https://forum.across.to/t/the-bridge-across-august-update/2133","domain":"forum.across.to","title":"The Bridge Across - August Update - Updates - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n The Bridge Across - August Update \n\n Updates\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n post by risklabs on Aug 5\n\n risklabs\n\n A short update on The Bridge Across:\nOur team has been diligently working with legal counsel to get through the final hurdles of the ACX Exchange program. That said, the timelines for the ACX Exchange have been slightly delayed. Our exchange portal will go live soon, with a target of the end of August.\nSome exchanges may begin to delist ACX. This is normal and expected, and in no way fects the ACX Exchange program. Please be sure to move your tokens to self-custody wallets to be best prepared for when the ACX Exchange portal goes live.\nAs we put finishing touches on the work required, and continue to navigate through the legal process, we will keep the community updated. Thank you for your patience and support!\nWe will have more details for you all soon.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n $ACX Portal Update\n\n Updates\n\n Pinned\n\n Updates\n\n Jun 30\n\n The Across token buyout portal is now live\n\n Updates\n\n Updates\n\n 19d\n\n The Bridge Across\n\n Proposals\n\n governance-updates\n\n Pinned\n\n Proposals\n\n 39\n\n Apr 25\n\n Across ($ACX) Community Initial Liquidity Proposal\n\n Passed Proposals\n\n Passed Proposals\n\n 49\n\n Nov 2022\n\n $ACX Liquidity - Update and Feedback Wanted\n\n Ideas & Feedback\n\n Ideas & Feedback\n\n 7\n\n Jun 2023","tokens":1846,"squid":"spider-09","role":"Bridge Spider","at":1791346653354,"hash":"933dbeef10a929d28705e5a10fb40707c6069dc9"}
{"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":"spider-05","role":"Spec Spider","at":1791346656266,"hash":"ccc7177769391a4f160074fa780b3100954e0f06"}
{"url":"https://forum.across.to/c/updates/23","domain":"forum.across.to","title":"Latest Updates topics - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n Latest topics in Updates\n\n 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 posted\n Jun 30\n\n by @risklabs\n\n Pinned\n\n $ACX Portal Update\n\n We wanted to provide an update on the timeline for the $ACX exchange and buyout process following the passing of the Snapshot proposal. \nOur initial estimate was that $ACX holders would be able to exchange $ACX for equit…\n\n read more\n\n posted\n Jun 30\n\n by @risklabs\n\n Pinned\n\n About the Updates category\n\n posted\n Sep 17\n\n by @risklabs\n\n The Across token buyout portal is now live\n\n The Across token buyout portal is now live. \nAs described in The Bridge Across proposal, Across Protocol has been transferred to a new company, Across, Inc. (“AcrossCo”), to give the Across team an opportunity to explore…\n\n read more\n\n posted\n Aug 5\n\n by @risklabs\n\n The Bridge Across - August Update\n\n A short update on The Bridge Across: \nOur team has been diligently working with legal counsel to get through the final hurdles of the ACX Exchange program. That said, the timelines for the ACX Exchange have been slightly…\n\n read more","tokens":1768,"squid":"spider-09","role":"Bridge Spider","at":1791346663516,"hash":"9ffa3e13f69a74ef16a4e018b9c4cf3a64614e4b"}
{"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":"spider-05","role":"Spec Spider","at":1791346666213,"hash":"5d762c586768d26919223edf978519bafc87fe48"}
{"url":"https://consensysdiligence.github.io/smart-contract-best-practices/security-tools/visualization/","domain":"consensysdiligence.github.io","title":"Visualization - Ethereum Smart Contract Best Practices","text":"Visualization\n\nSolidity Visual Developer\n - This extension contributes security centric syntax and semantic highlighting, a detailed class\n outline and advanced Solidity code insights to Visual Studio Code\nSūrya - Utility tool for smart contract systems, offering a\n number of visual outputs and information about the contracts' structure. Also supports querying\n the function call graph.\nSolgraph - Generates a DOT graph that visualizes\n function control flow of a Solidity contract and highlights potential security vulnerabilities.\nEVM Lab - Rich tool package to interact with the EVM.\n Includes a VM, Etherchain API, and a trace-viewer.\nethereum-graph-debugger - A graphical EVM\n debugger. Displays the entire program control flow graph.\nPiet - Web application helping understand smart contract\n architectures. Offers graphical representation and inspection of smart contracts as well as a\n markdown documentation generator.","tokens":232,"squid":"spider-06","role":"Security Spider","at":1791346666616,"hash":"b3f8185272d3d286db2c7b41faa35e2fd18d058f"}
{"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 16\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":"spider-04","role":"Research Spider","at":1791346678169,"hash":"a63157149733118da1fafba449514443d2bd2a92"}
{"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":"spider-05","role":"Spec Spider","at":1791346679079,"hash":"4320042230669c493d0a77acb7ae79c0584ac257"}
{"url":"https://immutablesoft.github.io/ImmutableEcosystem/","domain":"immutablesoft.github.io","title":"ImmutableEcosystem | The Solidity based Immutable Ecosystem","text":"Immutable Ecosystem Documentation\n\nContents\n\nWhy the Immutable Ecosystem?\n\nWeb3 Provider Requirement\n\nEnd User Interface\n\n The User Interface\n\n Download And Verify\n\n Purchase an Activation License\n\n Change a Product Activation Identifier\n\n Resell Activation License\n\nDigital Creator Interface\n\n Creator Requirements\n\n The Registration Process\n\n The Product and Release Interfaces\n\n The Product License Offer Interface\n\nMonetization and Configuration\n\n Escrow\n\n Entity Configuration\n\nDevelopers and Embedding\n\n Product Links\n\n Entity Links\n\n Activation Validation\n\n AutoLM\n\nWhy the Immutable Ecosystem?\n\nThe immutability and decentralized security of the blockchain provides an independent root of trust through our smart contracts for the benefit of digital product consumers and creators alike. Commercial or nonprofit, this ecosystem can automate digital product distribution and sales processes for digital content creators. In the most simplistic terms the Immutable Ecosystem (ie. Ecosystem) is a decentralized Digital Product and Activation Asset Store (or App Store) whose database is the blockchain. If this still sounds complicated let us paraphrase.\n\nThe Immutable Ecosystem means trust. Trust that users download the digital product exactly as released by the digital creator. Trust that users can purchase digital product activations as depreciable assets with resale rights. Trust that digital creators are supremely compensated for all user activation purchases. Trust that the digital activation resale process is auditable and designed to prevent fraud. Trust that no central authority will exist to impose its financial or political insecurities upon the digital creator community.\n\nNot convinced? Please read the Immutable Whitepaper for more information. To extend our trust to the community, all of the Immutable Smart Contracts are open source and covered with an ongoing bug bounty. We store zero customer or user data in any database outside the blockchain.\n\nWeb3 Provider Requirement\n\nThe primary interfaces with the blockchain is through our web Dapp the Immutable Ecosystem. Each digital creator must have their Ethereum wallet address registered with the smart contracts. Accessing the Ecosystem requires a Web3 provider such as the MetaMask wallet. The Web3 provider is the bridge between an Ethereum network and the web Dapp. The provider is typically installed as a browser plugin to access the Immutable Ecosystem Dapp. For the PCs and Mobile, the Brave Crypto Wallet, or any browser with the MetaMask plug in, are recommended. The Web3 provider empowers the browser by giving it read and write access to an Ethereum blockchain using the user’s wallet. You can test your browser by opening the Immutable Ecosystem. If the top left shows a dog/fox/wolf and Plug In, click it to install MetaMask now.\n\nUsing the address of your wallet as unique identifier, the Web3 provider is a secure method of interacting with distributed and decentralized applications (DApps) such as the Immutable Ecosystem. While an Ethereum wallet and Web3 provider are required in order to read from the blockchain and access the Ecosystem, there is no requirement to purchase any native coin (Polygon MATIC or ETH). Native coins (and ERC20 tokens) are only needed for the monetization of digital products within the Ecosystem. Users can use the Ecosystem to search for and download/verify as many products as they want free of charge. The Ecosystem is designed to be freely integrated with third party build tools to validate external dependencies during download/build/install processes.\n\nWhen your Web3 Provider enabled browser opens the Immutable Ecosystem for the first time, the Web3 provider (MetaMask, etc.) will display a connection Notification between the Ecosystem and your Ethereum wallet, similar to this.\n\nTo protect your wallet, all connections and blockchain transactions (writes) will result in a Web3 provider Notification. Never approve any Web3 provider Notification that you did not initiate through a trusted Dapp. Currently the Immutable Ecosystem is available on Polygon Mainnet/Mumbai and Ropsten Ethereum networks. To configure the Polygon network for MetaMask, navatige to the bottom of polygonscan.com and Click the Add Polygon Network button (with MetaMask logo). Then navigate back and refresh the Ecosystem Dapp. Read and accept any connection request to allow MetaMask to be the web3 provider and allowing the Ecosystem to load.\n\nIf you get the above web page instead of the MetaMask Connect Notification and you have MetaMask plugin installed, you might be on an unsupported blockchain network. Be sure to choose Polygon Mainnet for production. Polygon Mumbai and Ropsten Ethereum have the smart contracts installed/maintained and are available for testing. Mainnet Ethereum network with Optimism minting bridge planned for future.\n\nIf you are a digital creator please start with the Digital Creator Interface to join and add your creations to the marketplace. Browsers of the marketplace should continue with the End User Interface below.\n\nEnd User Interface\n\nThe primary goal of the Ecosystem is to allow users to download, authenticate, install and purchase digital product activation assets safely and directly with the original digital creator. The Immutable Ecosystem allows users the ability to browse for all types of digital products. The goal of the Applications menu interface is to help users find their digital products quickly so they can install and purchase/activate those products securely. Each product displayed in the ecosystem has the product name, logo and link to the product website to learn more about a product before downloading.\n\nThe User Interface\n\nOnce a browser has MetaMask installed and the Connect to MetaMask is approved for the Immutable Ecosystem and Ethereum network, the Ecosystem will come alive when you browse to it.\n\nIf everything is working you should see the website with the top banner displaying something like this.\n\nIn the image above, the top bar contains the main menu button on the left and a global search box to quickly find an organization or product. On the right of the Immutable top banner is the current balance of Ethereum in the Web3 Account next to a picture of a token stack.\n\nOn the main Applications page, just below the top bar is the currently Showcased entity and their applications. The Showcased entity changes to a different entity with products every hour. Below the Showcased entity is a drop down list of license types and application categories. Below this is all the applications of the Ecosystem. Selecting a license type or category limits the displayed applications those of that license or category only. Clicking on an application, either in the featured entity or below, opens the interface to that particular digital product.\n\nIn the product interface above the Version and Type list box will become populated with all available release versions and hardware platform types. If the “All Platforms” selection in the left list box is changed to a particular platform type, only release versions for that platform will be displayed. By default the most recently created releases are displayed in the list first, which are presumably the most recent releases of the software product.\n\nDownload and Verify\n\nWith a product selected, the Application interface shows a primary Get button is on the right and the Verify button below. To download the latest release file select the platform and press the Get button. Save the resulting file download and remember the name and location of the it. To verify the download, press the Verify button and select the local file that you just saved. The verification process will notify you if the file is authentic or not.\n\nAbove is a screen shot of what to expect after selecting the Firefox application, Getting the release file and performing the Verify process on the file that was just downloaded. Note that the product button is highlighted (black outline) and should match between the product download URI and the locally saved file. After verifying the integrity of the downloaded file it is safe to execute, install and use the downloaded product. The Immutable Ecosystem does not safeguard the user from network or email based attacks and is NOT a replacement for anti-virus software.\n\nPurchase an Activation License\n\nIf the digital product is commercial and the creator has configured an activation offer, the Purchase button will appear to the right of the Verify button. The Purchase button displays the digital product specific offer(s), each offer specifying the price (ETH or ERC20 token), time period and execution limitations (combinaiton of platform, languages, versions, etc.) defined by the digital creator. Each digital product activation purchased from an offer includes the right to resell the activation, UNLESS that offer includes the phrase “No resale”. Resale rights ensure your activation is a resellable and depreciable asset, similar to a bike or car.\n\nThe purchase activation procedure follows installing and executing the digital product release. Upon first execution the installed product may display a URL link to the Purchase an Activation page for the product, auto-filled with the users unique identifying number. If not, the identifier should be displayed and must be copied, without error or omission, to this Purchase an Activation page.\n\nThe activation identifier is typically hardware specific. Regardless of the limitations of the offer, the digital product (software, etc.) should be installed and executed on the specific platform that is to be activated. This initial execution should produce this activation identifier or Ecosystem URL (with embedded activation id). Be sure to read and understand any product and offer specific restrictions or instructions before purchasing an activation license, especially in an offer link (URL) is provided by the created. Immutable cannot refund a license activation purchase, although your payment was sent to the software creator so a refund from them is entirely possible.\n\nThe product activation identifier is calculated to be repeatable and unique per product and per hardware system it is executed upon.\n\nFollow the application link, or copy the unique activation identifier from the digital product to the Purchase an Activation License form, select the offer and submit the activation purchase with the Purchase Activation button. You will need to wait until the the activation is written to the blockchain before continuing. Once the transaction is written to the blockchain a restart of the digital product should cause the license check to succeed and the application will be ready to use.\n\nChange a Product Activation Identifier\n\nAt any time before expiration the product activation identifier can be changed. This allows the end user to upgrade computer hardware for example, and then reactivate the digital product (software) with their new identifier. This feature can also be used to loan an activation to a friend or colleague while still retaining ownership (the ability to change the identifier again at any time). To update to a new identifier select the Activations menu option. A list of purchased activations should be presented. Select the product activation to change and you will see the Activation details page like below.\n\nThen press the Move button and input the new identifier, obtained from executing the digital application, and press the Change Activation Identifier button. To prevent abuse and discourage a short term rental market, one (1) token is charged whenever an activation identifier is changed. By design, when an activation identifier is changed, the old identifier is no longer valid. When an activation is offered for resale (see section below) the current identifier remains valid and will continue to activate the digital product and can still be changed with this interface. However, once the activation license is purchased by another user (see section below) the activation identifier will be changed to that specified by the new owner and the old identifier will no longer activate the digital product.\n\nResell Activation License\n\nAt any time before an Activation license expires, a purchaser registered with the Ecosystem may offer the remaining time of a digital activation for resale within the Immutable Ecosystem. From the Activation menu, select the purchased activation to enter the Activation interface. Press the Resell button to open the Resell inteface. Enter a resale offer price, in whole tokens, and press the Offer Activation button.\n\nOnce a purchased product activation is offered for resale, it will appear in the activation resale offer list on the Purchase Activation License interface whenever others using the Ecosystem wish to activate that particular product. If the seller does not have an active subscription with the Immutable Ecosystem, a 1 percent fee is charged the seller whenever an activation resale offer is purchased. The purchaser is unaware and unaffected by this fee although an event audit will show this fee transfer.\n\nAllowing a purchaser to securely and safely resell a previously purchased digital product activation license turns it into an asset of depreciable value similar to a bike, appliance or car. We at Immutable believe the decentralized assetization of digital activation licenses is an empowering technology that will change the future of software for the better. Go to the Configure menu page and Register with the Immutable Ecosystem today.\n\nDigital Creator Interface\n\nCreator Requirements\n\nA digital creator, in order to best use the Immutable Ecosystem, should have an existing web presence with a URL specific to each product that provides a description of the product. ImmutableSoft also recommends a product logo URL that is used for users to visually identify the product. Finally, a URI for each specific product release which must remain available for one year in order to earn escrow rewards. In some scenarios commercial software does not have direct URIs for download but instead requires the user to first register themselves for access to a unique URI. In these cases each release URI should be a URL leading the user to the start of the registration process. The requirement here is that the registration process must lead to a download of a file that can be identified within the Immutable Ecosystem and whose checksum can thus be verifiable after download.\n\nThe registered administrator Ethereum wallet address for the Entity and a Web3 provider (MetaMask, Brave, etc.) is required to make changes to digital products. The Entity administrator wallet is your secure identity on the blockchain, turning this wallet private key into the digital product release signing key. This allows a software creator to use a $100 commercial Ethereum hardware wallet to achieve a similar level of operational and distribution security as a $10,000 Hardware Security Module (HSM).\n\nThe Registration Process\n\nBefore a digital Creator can begin to utilize the Ecosystem for digital distribution and sales, it must register their administrator Ethereum account address with the Immutable Ecosystem, along with their entity name, URL and optional referral entity. Drop down the menu and open the Configure page of the Immutable Ecosystem and press the Registration button. Please follow the instructions as this is a two step process, first writing the public information to the blockchain (name, URL) to prove ownership of your administrator Ethereum account. The second step is to then privately submit your contact information so ImmutableSoft can verify and activate your account. Be sure the active MetaMask Ethereum account address is the one you wish to use as the administrator for the registering entity. You can change the registered entity Ethereum account address at any time after registration, see Part III Entity Configuration. Be sure to complete both steps of the registration process or your application will not be complete.\n\nThe first requirement for a digital creator is to register your Entity (individual, organization or company) using the Ethereum Account that is to become the administrator for the Entity. Whatever Web3 account and network is currently active in MetaMask will be used for the registration.\n\nThe registration page looks something like above. After writing your Entity name and URL to the blockchain and thus demonstrating your ownership of the wallet address, you will be redirected to the main immutablesoft.org website to submit your private contact information. The Entity name and your Ethereum Account address should be auto populated. Be sure to check the email or voicemail submitted for communications from ImmutableSoft as we will be following up and verifying your information.\n\nAfter registering your Entity with the Immutable Ecosystem, the Configure page and Registration interface should display something like above and a second tab opened in the browser for the Entity to submit their private contact information. If this second private contact information form is closed on accident, or you wish to resubmit or delegate this step, the link to submit your private information can be found on the Configure, Registrations page (in the Thank You note). A registration will be unapproved and incomplete until private contact information has been submitted on behalf of a Registered Entity and verified by ImmutableSoft.\n\nThe Product and Release Interfaces\n\nOnce an Entity registration is approved the menu options Activations, Products (if Creator) and Token Offers appear when the Ecosystem is browsed with the Web3 account used for registration. Your Ethereum wallet becomes the access control mechanism to the Ecosystem, there is no login process and ImmutableSoft never knows your password or secret keywords. Each page in the Dapp menu provides a unique interface. The Products menu shows all products created by the Entity and allows the creator to Edit, set Licensing terms or create a New Release of the product.\n\nThe first step is to create our first product by pressing the New Product button. In this example it will be the companion laboratory to the main Computer System book. In the example above the product name, details URL and logo image URL are defined for the Computer System Laboratory digital product. No restriction check boxes are set and the languages of the product is set to English only (languages is a multi-select box). Finally the category of Programming is chosen as it reflects the most popular category of uses of the product, although not the only category. The logo URL will be previewed in the New Product interface upon entry to avoid mistakes prior to writing the transaction to the blockchain. The completed new product interface, before submitting, would look similar to this picture.\n\nAfter a product is created a new release for that product can be created. In the Product menu page, click on the product and then press the New Release primary button on the right. In the below New Release interface, the file checksum must be a SHA256 of the URI file, in hexidecimal format (begins with 0x…). One token (~.$25) is required in each release escrow as a challenge incentive for anyone who detects a change in the release file. The minimum escrow is 1 token and there is no maximum. Do not make the escrow too high as it may incentivize others to attack the product website to modify file(s) and claim the escrow(s), an act that is very much against the rules of Immutable but may be hard to prove. The URI to download the file begins with https (a secure URL), the version is in dot notation (1.1) and the platform of the release is for Windows on x86 hardware. Once New Release is clicked there will be an alert that displays the data for verification.\n\nAfter reviewing this information and pressing Ok, MetaMask will pop up a blockchain write verification notification. Edit the gas, select Slow speed (to minimize gas costs) and Approve the transaction. The new product should become visible in the Ecosystem on a fresh page load. Selecting Melodicious will display the Product interface page with the Get primary button on the right and Verify button on the bottom left. Congratulations, we have created a digital product and release with the Immutable Ecosystem.\n\nNote that any icon we chose is scaled to fit 192x192 pixels or smaller in the Ecosystem. The logo URL should be in icon (square) format and at least 196x196 pixels but will scale any image, larger or smaller. If your digital product is released free of charge or your product will not be selling activations on the Immutable Ecosystem, this is the last step needed for a creator to distribute their software to the world. As new releases of your product come to fruitation you can revisit the Ecosystem and add them. Better yet to add a step to your release process that auto-populates a New Release page to nearly automate the process. See Part IV section Product Links for more information on embedding links into the Immutable Ecosystem.\n\nCreate an Activation\n\nAlternatively the end user can communicate their activation identifier to the software creator directly and they can create and manage the activation for their end user (see Create a New Activation). In this scenario the payment is outside the Ecosystem (credit card, paypal, etc.) while the end user activation is managed within the Ecosystem. The resulting Activate token is owned by the software creator and can be managed from the Activations page by the sales team. An Activate token created in this manner could be transferred to the end user at any time if desired.\n\nThe Product License Offer Interface\n\nCommercial software creators who include the Immutable library into their application enables the automation of product activation sales directly to end users. Using the Immutable Ecosystem smart contracts, an end user can purchase (ie. transfer ETH (or ERC20 tokens)) a product activation license on the blockchain that will unlock the software product. To allow this the software creator must create a product activation offer. This section of the document will describe how to create product activation offers for end users to purchase your products. Once the Immutable activation check is integrated into your digital product, the sales process can become automated as the application can verify activation licenses at run time.\n\nEach product can have an unlimited number of activation license offers outstanding at any one time, however more is not always better. Each offer has a cost in ETH (or ERC20 tokens), a time period (in days) the activation is valid for and other limitations such as version, language or platform. Once purchased the time period is added to today’s date as the expiration, and along with the other license limitations defined in the offer is immutably written to the blockchain. Below is the create offer interface.\n\nIt is possible to revoke or change the price of an existing offer. However, to avoid confusion to customers and allow better auditability, the time period and other limitations can not be changed after offer creation. It is highly recommended to think through and develop clear and simple offers that address the needs of your sales organization. All limitations are optional and not required, and the software application is only informed of the limitations upon license validation check; it must enforce the product activation limitations (version, platform, language, time, etc.).\n\nFor more information on how to validate an activation license on the blockchain within your digital product, see Part IV Activation Validation.\n\nMonetization and Configuration\n\nA digital product activation license becomes an asset if it can be resold. However, digital creators are cautious about losing out on sales revenue. Limiting each activation license to an immutable expiration time that is unaffected by resales, it is possible to accommodate the resale community while boosting revenue. Raise your prices if need be since the digital activation is worth more as an asset that can be resold. Your customers will purchase more expensive multiyear promotional offers if they know they can legally resell the remainder at any time. By selling digital activation assets your organization is selling a premium product.\n\nEscrow\n\nThe Immutable Ecosystem manages an escrow account for each registered and approved Entity. This escrow account is for ETH earned from the sales of activation purchases. Purchases of product activation licenses in ERC20 tokens result in the direct transfer of tokens from the purchaser to the creating Entity, without the use of an escrow.\n\nThe ETH in the Entity escrow account can be periodically transferred out of this escrow into the Entity bank address, where it can be exchanged for local currency through an exchange as desired.\n\nAt the top of the Configure page is the Withdraw ETH button which will withdraw ETH from the escrow. Navigate to the Configure page with the menu botton on the top left.\n\nEntity Configuration\n\nThere are three Configure features for registered and approved Entities of the Ecosystem. Choosing Configure from the menu will open the Configure page (see picture above) which itself has interfaces to changing the ETH bank address, Entity address, or updating the Entity information itself. The Entity bank address is the recipient when transferring ETH out of the escrow of an Entity in the Ecosystem. The Entity bank address default is the Entity administrator address but can be changed at any time. Be sure to withdraw any ETH before changing the bank address or you will have to change back to the old address in order to withdraw the ETH.\n\nDue to organizational or security reasons Entities may wish to change the Ethereum address they have registered as the owner (Administrator) of the Entity within the Ecosystem. For safety reasons (to prevent the loss of ownership), changing the address of an Entity is a two-step process. The first step is to use the current address and submit a transaction with the new address, proving that the current Entity owner is intending to move to the new address.\n\nThe second step is to use the new Ethereum address and access the Immutable Ecosystem. For an unregistered address, the Configure page will display a button to Accept Move. Press this Accept Move button and then enter the old (last) address and press the Accept Entity Move button. Once the new Ethereum address has completed this second step the new address will be recognized by the Ecosystem as the Entity Administrator.\n\nWith this two-step process, if there is a mistake with Step 1 then it can be resolved by the Entity. Only once an Entity has demonstrated they have possession of both Ethereum addresses (and associated keys) will an Entity address be changed. Step 1 can be repeated as many times as necessary and can even be performed ahead of time as a managerial escape hatch.\n\nTo update the Entity public information such as the name or URL of the Entity, select the Edit Entity and fill in the new Entity information and press the Update Entity button. Updating the Entity public information resets the Entity back to unapproved status and requires ImmutableSoft validation. To ensure prompt approval please send an email to register@immutablesoft.org describing the nature of the Entity change. Sending this email and receiving a response BEFORE updating the Entity information is recommended for fastest re-approval.\n\nDevelopers and Embedding\n\nThe Immutable Ecosystem is designed to integrate with digital product creator websites by embedding simple HTML links with query strings. Every function of the Ecosystem is potentially supported, from Download and Verify to Purchasing an Activaiton. The Ecosystem uses standard HTML query strings to pass the function and function parameters to the Ecosystem for execution and presentation.\n\nThe Product specific embedded links into the Ecosystem are generated and available on the Products menu. Select the product and at the bottom near the Edit button should be an Embed button. This will open an interface providing examples of the different functions and query string interfaces. Cut and paste from here to the creators web site. The Ecosystem supports being opened in an iframe so that there is no need for the web browser to ever leave the creators website to use the Ecosystem.\n\nEntity Links\n\nBelow is a list of the Entity specific functions and parameters currently supported by this embed interface.\n\nRegistration with referral\n\nhttps://ecosystem.immutablesoft.org/?func=registration&entity=<entity ID>&referral=<referredBy>\n\nProduct Links\n\nBelow is a list of the Product specific functions and parameters currently supported by this embed interface.\n\nPurchase a License Activation\n\nhttps://ecosystem.immutablesoft.org/?func=activation&entity=<entity ID>&product=<product ID>&identifier=<id>&promo=<promotion>\n\nDonate to a Product/Entity\n\nhttps://ecosystem.immutablesoft.org/?func=donate&entity=<entity ID>&product=<product ID>\n\nOpen Product Release page for Download and Verify\n\nExample below is for the latest release. Leave the arch option blank for the default (auto detect) architecture.\n\nhttps://ecosystem.immutablesoft.org/?func=release&entity=<entity ID>&product=<product ID>&arch=<HWArchitecture>\n\nOr to open the Product Release page for a specific release.\n\nhttps://ecosystem.immutablesoft.org/?func=release&entity=<entity ID>&product=<product ID>&release=<release ID>\n\nActivation Validation\n\nTo accept tokens as payment for secure digital product activations requires a software or digital product release to use the Immutable license activation library in a manner which cannot be easily reverse engineered or bypassed. Typically compiled software complicates reverse engineering but a scripting languages are secure if the execution environment is secure, such as running on a secured server. The digital product release creator must add our library to their digital product (software, etc.) to verify the activation is valid (or at login if a web server or password based activation). During this validation step the following will occur in order:\n\n1) The software will compute a unique identifier for the executing system based on hardware identifiers. This identifier will be unique and compute to the same value every time a digital product is executed on this platform (digital product, OS and hardware specific).\n\n2) The digital product, upon startup, must compute this identifier and then verify if it can be found on the blockchain (is activated). If found to be active (present and unexpired) the digital product would allow execution, othwerwise the application should redirect execution to a purchase screen and/or halt execution. Immutable provides open software libraries and examples to do the secure blockchain activation check, but integrating with your software products is required.\n\nThe activation check with the blockchain is typically done with a secure HTTPS request to an Infura node controlled by the digital product creator. For production releases a creator should register with Infura and receive a Product ID for their application to use to access the blockchain. While ImmutableSoft has and may have shared their Infura Product ID for testing, it is capped at 100,000 requests and could reach a limit and prevent activation checks and thus your application from working. It is recommended that each product, and required that each entity, use their own Infura account when integrating the Immutable library for activation checks within their application.\n\nBelow is an example use the curl HTTP command line browser to query the Ropsten Ethereum testnet blockchain (using an Infura node), and check the validity of a license activation identifier. This example is for the Windows shell and requires escape characters for each quote that are not required on Unix systems.\n\ncurl --data \"{\\\"jsonrpc\\\":\\\"2.0\\\",\\\"method\\\": \\\"eth_call\\\", \\\"params\\\": [{\\\"to\\\": \\\"0x21027DD05168A559330649721D3600196aB0aeC2\\\", \\\"data\\\": \\\"0x9277d3d6000000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001\\\"}, \\\"latest\\\"], \\\"id\\\": 1}\" https://ropsten.infura.io/v3/6233914717a744d19a2931dfbdd3dddc\n\nNote the following details. The to: parameter is the address of the immutableLicense smart contract deployed on the Ethereum network. In the example above this is the Ropsten testnet address of the smart contact. This address will be different on mainnet. The Infura node URL concludes with the API version and Product ID as provided by Infura. The Infura node URL begins with the Ethereum network, in this example Ropsten. The Ethereum network and/or Infura product ID may differ for mainnet production deployments. The JSON-RPC data field is the most difficult to understand, build and parse. The first 4 bytes is the hash identifier of the smart contract function name and parameter types (“licenseStatus(uint256,uint256,uint256)”). The licenseStatus function takes three uint256 parameters, the Entity id, Product id and activation Identifier. If we split up the data field as below it is easier to understand how the data field is created, and how it can be modified. In the simplified example below the Entity Id is 2, product Id is 0 and Activation Id is 1.\n\n0x9277d3d6 ; function hash, in this case sha256(\"licenseStatus(uint256,uint256,uint256)\")\n0000000000000000000000000000000000000000000000000000000000000002 ; Entity Id\n0000000000000000000000000000000000000000000000000000000000000000 ; Product Id\n0000000000000000000000000000000000000000000000000000000000000001 ; Activation Id\n\nFor production (mainnet) products the Infura node, contract address, function hash, Entity Id and Product Id are all static and will remain unchanged for the lifetime of the product. The unchanged fields can be hard coded into the application. Only the Activation ID needs to be generated by the installed digital product and programatically put into this curl HTTP request data field. Quite simply the easiest way to achomplish all of the above is with AutoLM.\n\n AutoLM\n\nThe Automatic License Manager, or AutoLM, is the recommended license management library for software creators to interface with and utilize Immutable Ecosystem Activations. Through a one way cryptographic algorithm it generates a PC and product specific unique identifier that is then used as the activation identifier within an Immutable Activation.\n\nThe AutoLM Documentation will explain the details and steps necessary to generate a unique identifier locked to a specific hardware system and feed this identifier to the curl requests, parsing the response. And an example launches a browser with a Product Link URL from the application which then opens the Purchase Activation page for the product in the Immutable Ecosystem, auto-populating the activation identifier for a one-click Activation purchase. There are more details and coding examples of how to build the AutoLM library into your digital product. For even more software licensing options, contact Immutable for more information on EasyLM, a full featured license mangememnt solution.","tokens":8856,"squid":"spider-06","role":"Security Spider","at":1791346685558,"hash":"02fe659f38249890f8441f28986c2ef8188d66fe"}
{"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":"spider-05","role":"Spec Spider","at":1791346689116,"hash":"7d18828bdab122a7876988edb9c6540b6fe69ee6"}
{"url":"https://consensysdiligence.github.io/smart-contract-best-practices/security-tools/disassemblers/","domain":"consensysdiligence.github.io","title":"Disassemblers - Ethereum Smart Contract Best Practices","text":"Disassemblers\n\nDisassemblers\nTools that translate smart contract bytecode into opcodes or EVM assembly.\n\nEthersplay - Binary Ninja plugin which enables an EVM disassembler and related analysis tools. \nPyevmasm - Assembler and disassembler library for the Ethereum Virtual Machine (EVM). It includes a commandline utility and a Python API.\nIDA-EVM - IDA Processor Module for the Ethereum Virtual Machine (EVM).\nEthereum DASM - EVM bytecode disassembler with function signature lookup plus static and dynamic analysis.\n\nDecompilers\nAs above but translated into more readable Solidity-like code.\n\nJEB Ethereum Smart Contract Decompiler - JEB decompiler plugin for Ethereum Smart Contracts\nOnline Solidity Decompiler - Online tool that decompiles Ethereum contract bytecode into more readable Solidity-like code, allowing for better understanding of opaque/unverified contracts.\nDedaub Decompiler - EVM bytecode decompiler and disassembler hybrid with 3 address code view deployed on a website.","tokens":248,"squid":"spider-06","role":"Security Spider","at":1791346695749,"hash":"856f5db8e95de3de96ec434b95dc3b8d23ce767e"}
{"url":"https://ethresear.ch/t/orbit-ssf-solo-staking-friendly-validator-set-management-for-ssf/19928","domain":"ethresear.ch","title":"Orbit SSF: solo-staking-friendly validator set management for SSF - Proof-of-Stake / Economics - Ethereum Research","text":"Orbit SSF: solo-staking-friendly validator set management for SSF \n\n Proof-of-StakeEconomics\n\n single-slot-finality\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n read \n\n 15\n min\n\n Jun 2024\n\n 1 / 4\n\n Jun 2024\n\n Jul 2024\n\n post by fradamt on Jun 28, 2024\n\n fradamt\n\n Much of the post came together during a week of in-person whiteboarding with RIG and wannabe RIGs like myself, Ansgar and Toni. Thanks in particular to Anders, Ansgar, Barnabé, Thomas for continued discussions and feedback, again to Anders for most of the ideas around individual incentives, and again to Barnabé for the diagrams about finality. The core idea that the post explores was originally proposed by Vitalik in this post.\nWhere we are\nThe Single Slot Finality (SSF) roadmap has three main components:\n\nConsensus algorithm\nSignature aggregation\nValidator set economics\n\nSince the previously linked post, there has been a lot of progress on the consensus algorithm side, with multiple candidate protocols and the beginning of a specification effort. There have also been some effort to explore the design space of signature aggregation, both with a networking focus and a cryptographic focus. Still, we are likely not close to being able to reliably aggregate millions of signatures per slot, without increasing the slot time or validator requirements significantly. On the staking economics side, there has been lots of work over the last year, but for the most part focused on understanding liquid staking and restaking, and on stake capping, i.e., constraining the amount of ETH staked (if you’re reading this, you’re probably already at least at a surface level familiar with the issuance conversation, in which case you might want to dig deeper and check out these posts [1] [2]). Here, we are instead interested in validator capping, i.e., constraining the amount of validator identities in the system, or at least the ones actively participating at any given time, to satisfy technical constraints. Some ideas in this direction can be found in this recent post, and in fact approach 3 from the post provides the foundation for this post. Moreover, a recent important development is that EIP-7251 (MaxEB) has been included in the Electra fork. Validator effective balances will be allowed to be as high as 2048 ETH, enabling staking pools to consolidate their validators, a new capability which we can leverage in our designs.\n\nGoals\nWith the goal of finding a design which can make its way into the protocol in a reasonable timeline, we are here going to focus on solutions that do not rely on large improvements in the signature aggregation process. We also do not think it is very realistic to propose significant increases of the slot time, which have many externalities. Given these technical constraints, let’s focus on a minimal set of properties that we ideally want to achieve:\n\nValidator capping: at most N𝑁 active validators at a time. For example, N = 2^{15} \\approx 32k𝑁 =215 ≈32𝑘, which we know we can handle because it is the size of a committee today. If we wanted to completely remove attestation aggregation, we would likely need to drop this number to a few thousands.\nSolo staking viability: staking with 32 ETH is guaranteed to still be possible, and the solo staking yield should still not compare unfavorably to delegated staking yields.\nHigh eventual economic security: More than D_f𝐷𝑓 stake provides economic security, at least eventually. For example D_f = 20M𝐷𝑓 =20𝑀 ETH. Ideally, we also do not have to wait longer than today for it (two epochs).\nFast finality: at least some amount of economic security is available shortly after a block is proposed (think: 10 to 30 seconds, not over 10 minutes).\nOptimally secure consensus protocol: the consensus protocol is (provably) resilient to ~1/2 adversaries under network synchrony, and 1/3 under partial synchrony.\n\nWithout solo staking viability as defined here, we could simply raise the minimum balance, or go with approaches that allow for a low minimum balance but do not guarantee it, for example in the face of large stakers intentionally splitting their stake. Such solutions would likely have to lean on decentralized staking pools or two-tier staking to preserve the accessible nature of staking as it is today, or perhaps even to carve out a more tailored role for smaller stakers, as is suggested by rainbow staking. While there is merit to these approaches and we believe they (and more generally the role of solo staking/broad consensus participation) deserve further exploration, we are choosing here to only explore designs that are compatible with this narrow interpretation of solo staking viability.\nOverview of approaches\nValidator capping, solo staking viability and high economic security immediately raise an issue: high economic security requires millions of ETH to participate in finalizing and a minimum balance of 32 ETH then implies a worst case of hundreds of thousands or millions of validators (~1M at the time of writing), which seems to conflict with validator capping. There are two main classes of approaches that attempt to deal with this problem:\n\nValidator set rotation: the full validator set is allowed to be large, but only a subset is actively participating at any given time.\nEconomic validator set capping: the size of the full validator set is constrained through economic incentives. To guarantee a small validator set size we can for example reduce issuance past the target validator count. However, this leaves all stakers open to a cheap griefing attack, where a small amount of stake can have a disproportionate negative impact on issuance.\n\nIn this post we are not going to focus on the latter approach in isolation, but we are going to propose a way to combine economic incentives with a form of validator set rotation.\nValidator set rotation\nThe current protocol also has to deal with the issue we have outlined in the previous section, and the chosen “solution” is precisely validator set rotation: only 1/32 of the validator set votes in any given slot. This design trades off finality time, and fails to satisfy our desired property of fast finality.\n2844×1600 212 KB\nLet’s then explore whether we can use validator set rotation without giving up on fast finality or other properties.\nFast rotation\nOne way to go about validator set rotation is to have committees which rotate fast, as in the current protocol. In order to avoid a high time-to-finality, we can use a different consensus protocol allowing for committee-based finality, i.e., such that even a committee can provide economic security proportional to its stake. In fact, the post linked above deals with cumulative committee-based finality, where the consensus protocol even allows for accumulation of economic security over multiple finalizations, such that k𝑘 committees finalizing in a row results in k𝑘 times the economic security that a single committee can provide. We get two birds with one stone, getting both fast (partial) finality and full eventual economic security. In particular, we could have full finality in the same time as today (which gives enough time for each committee to do its own finalization by voting twice), but with the big improvement that economic security accrues every slot, rather than all at once after two epochs.\n2840×1600 230 KB\nThis seems like a clear improvement on today’s protocol, so why are we not just doing it? An answer comes from the consensus protocol design space: it is not clear at this point how to have an optimally secure dynamically available protocol with fast rotating committees. In fact, much of the problems with the LMD-GHOST component of today’s protocol, or at least the fundamental ones, come precisely from the interaction of multiple committees. In short, an adversary can accumulate weight across multiple committees, and use it to reorg honest blocks that have a single committee supporting them.\nFor interested readers, there actually are optimally secure dynamically available consensus protocols that allow for committees ([1] [2] for example), but all known ones suffer from catastrophic failures under even short-lived asynchrony ([1] [2]). It is not known whether this is a fundamental limitation, but at least so far we do not know any protocol that gets around it.\nSlow rotation\nThere is however a simple way to avoid the problem altogether: giving up on fast committee rotation, and instead having a committee which rotates out slowly, for example by replacing a small percentage of it every slot. The upshot is that such a committee effectively acts as a full validator set, in the sense that its actions do not interact with those of other committees, as would be the case with fast rotation. We can in principle take any protocol that works when the whole validator set is able to participate at once, and make it work with this mechanism by slowing down the rotation sufficiently.\n2840×1604 295 KB\nAt a first glance, one obvious downside is that a full rotation of the validator set would be much slower than today, and thus so would finality. However, we could do things a bit differently, by decoupling the committee which votes for the available chain (LMD-GHOST votes) from those which vote for finality (Casper FFG votes). Only LMD-GHOST has problems with fast committee rotation, so we could have a slowly rotating committee whose votes count for LMD-GHOST and in parallel also fast rotating committees whose votes accumulate economic security over time, up to full finality in no more than today’s two epochs.\nBesides some amount of extra complexity in the consensus protocol, one remaining downside is that we leave a single committee “in charge” of LMD-GHOST for extended periods of time. Moreover, while linearly accumulating finality is a strict improvement over today’s step function finality, we do not achieve something even stronger, namely getting a high level of economic security immediately. This is of course impossible to achieve given the constraints we have laid out, unless we make some assumptions about the stake distribution, for example that it is Zipfian, or anyway such that a large portion of the stake is concentrated in the first few thousand entities.\n\nOrbit SSF: Stable core, rotating periphery\nOur starting point is approach 3 from this post, where validators are (roughly) sampled by balance, so that validators with a lot of stake are always in the validator set. Contrast this with the previously considered validator set rotation approaches where validators were (implicitly) sampled by indices, as we do today, which results in each committee having small weight regardless of what the stake distribution looks like.\nWe then consider adding consolidation incentives, to have stronger guarantees about the level of finality that we can reach with a single committee. The rotating parts of the committee can then rotate slowly, and we do not need to take on the extra consensus complexity of decoupling voting for the available chain and for the finality gadget. Moreover, there is never a small committee (in terms of stake) in charge of a critical consensus component: at all times, we can expect the active validator set to hold a meaningful fraction of the whole stake.\nActive validator set management\nThere are two key components here:\n\nActive validator set selection: We set a stake threshold T𝑇 (in principle it could also be set dynamically), and then define the probability of validator with stake S𝑆 to be sampled in the active set to be $p(S) = \\min(\\frac{S}{T}, 1) =\n\\begin{cases}\n\\frac{S}{T} & S \\le T \\\n1 & S \\ge T\n\\end{cases}$\nA validator with stake S \\le T𝑆 ≤𝑇 is selected with probability \\frac{S}{T}𝑆𝑇 proportional to its stake, whereas validators with stake S \\ge T𝑆 ≥𝑇 are always in the validator set. The idea here is of course that it is helpful to have a stable core of large validators always in the active set, because they contribute a lot of economic security but still only add the same load as any other validator.\nReward adjustment: We adjust attestation rewards so that all validators still get compensated proportionally to their stake, regardless of whether they fall below or above the threshold T𝑇. To define the reward function, we take as reference the maximum attestation reward R𝑅 that the protocol gives to a validator with stake T𝑇, for a single attestation (R𝑅 can of course vary depending on the overall issuance level). Given R𝑅, the maximum reward for an attestation by a validator with stake S𝑆 is $r(S) = R\\cdot\\max(1, \\frac{S}{T}) =\n\\begin{cases}\nR & S \\le T \\\nR \\cdot \\frac{S}{T} &S \\ge T\n\\end{cases}$\nOverall, the expected rewards of a validator with stake S𝑆 are then p(S)\\cdot r(S) = R\\cdot\\frac{S}{T} = \\frac{R}{T} \\cdot S𝑝(𝑆) ⋅𝑟(𝑆) =𝑅 ⋅𝑆𝑇 =𝑅𝑇 ⋅𝑆. In other words, \\frac{R}{T}𝑅𝑇 per unit of stake, regardless of how it is distributed. To help visualize this, here’s a plot of p(S)𝑝(𝑆), r(S)𝑟(𝑆) and p(S)\\cdot r(S)𝑝(𝑆) ⋅𝑟(𝑆), for R = 2𝑅 =2 (arbitrary value just for the plot) and T = 1024𝑇 =1024. Validators with less than T𝑇 stake do have higher variance, because they only participate \\frac{S}{T}𝑆𝑇 of the time, but over longer periods of time the variance will still very low, since attestation rewards are constant and very frequent.\n\n2273×1170 125 KB\nValidator capping\nWe can easily compute the expected size of an active validator set V_a𝑉𝑎 that is sampled this way from a full validator set V𝑉 whose total deposit size is D𝐷:\n\\mathbb{E}[|V_a|] = \\sum_{i \\in V} p(S_i) = \\sum_{i \\in V} \\min(\\frac{S_i}{T}, 1) = \\frac{1}{T}\\sum_{i \\in V} \\min(S_i, T) \\le \\frac{1}{T}\\sum_{i \\in V} S_i = \\frac{D}{T}𝔼[|𝑉𝑎|] =∑𝑖∈𝑉𝑝(𝑆𝑖) =∑𝑖∈𝑉min(𝑆𝑖𝑇,1) =1𝑇∑𝑖∈𝑉min(𝑆𝑖,𝑇) ≤1𝑇∑𝑖∈𝑉𝑆𝑖 =𝐷𝑇\nBasically, any validator with stake S \\le T𝑆 ≤𝑇 contributes exactly \\frac{S}{T}𝑆𝑇 to the expectation. Crucially, these contribution scale linearly in S𝑆: the only effect of splitting up to T𝑇 stake into small validators is to increase the variance of the active validator set size, without affecting the expectation. As for validators with stake S > T𝑆 >𝑇, they even decrease the expectation compared to the worst case, which is \\frac{D}{T}𝐷𝑇, equal to the full validator set size if all validators had T𝑇 stake.\nFor example, we can set T = 4096𝑇 =4096 ETH, giving us a maximum expected active validator set size of \\frac{120M}{4096} \\approx 30k120𝑀4096 ≈30𝑘. If we were to employ stake capping (we will later discuss how to do so in this context) to ensure (or have high assurances) that D𝐷 is bounded by (for example) 2^{25}M225𝑀 ETH, we could even set T = 1024𝑇 =1024 and still have an expected active validator set size of at most ~32k. There can of course be deviations from this expected size, but with high probability the actual active validator set size would always fall within reasonably narrow bounds, so we can have very strong guarantees about the maximum load that we would need to be able to handle. We look at this in more detail in the appendix.\nIncentivizing consolidation\nLet D_a𝐷𝑎 be the active deposit size, i.e., the total stake of the active validator set, contrasted with the total deposit size D𝐷, the stake of the whole validator set. Optimistically, as long as there is sufficient consolidation, D_a𝐷𝑎 will be high, a clear improvement over the previous slow rotation approach. Still, we would like this to be more than an optimistic property. The question we are left to answer is then how we can ensure, or at least highly incentivize, a high \\frac{D_a}{D}𝐷𝑎𝐷 ratio. For example, we want to prevent that all validators keep 32 ETH balances (no one consolidates), which would result in \\mathbb{E}[D_a] = \\frac{32}{T} D𝔼[𝐷𝑎] =32𝑇𝐷, e.g., only \\frac{D}{32}𝐷32 with T = 1024𝑇 =1024. With today’s D = 32M𝐷 =32𝑀 ETH, the expected active deposit size would only be 1M1𝑀 ETH. On the other hand, we do not want to reward consolidated validators disproportionately compared to small validators.\nWe explore two complementary approaches:\n\nCollective consolidation incentives, growing the size of the pie for the whole validator set when the set is more consolidated.\nIndividual consolidation incentives, accounting for the extra risk accruing from further individual consolidation.\n\nCollective consolidation incentives\nThe first approach we explore is to reward everyone for consolidation, spreading out the benefits beyond the consolidating validators so as to maintain rewards undifferentiated, while still providing an incentive to consolidate.\nA first proposal in this direction is to set the rewards based on D_a𝐷𝑎, rather than D𝐷. For example, we could use the same issuance curve I𝐼 we use today, but where the deposit size used as input is D_a𝐷𝑎 instead of D𝐷: the cumulative issuance would then be I(D_a)𝐼(𝐷𝑎), and the resulting yield per unit of stake \\frac{I(D_a)}{D}𝐼(𝐷𝑎)𝐷. Notably, I𝐼 is monotonically increasing, so, whenever D_a < D𝐷𝑎 <𝐷, the cumulative issuance I(D_a)𝐼(𝐷𝑎) is less than the maximum issuance I(D)𝐼(𝐷) that would be possible at this deposit size, with full consolidation. The yield gap \\frac{I(D) - I(D_a)}{D}𝐼(𝐷)−𝐼(𝐷𝑎)𝐷 between the current yield and the yield with full consolidation then acts as a consolidation incentive.\nConsolidation incentives aside, another way to think about this proposal is that we simply pay for the economic security we get, at least from a single committee: if today our security budget for X𝑋 amount of deposits is Y𝑌, as expressed by I(X) = Y𝐼(𝑋) =𝑌, we would now be wiling to pay Y𝑌 in order to get X𝑋 amount of active deposits. To get an idea of what this looks like in practice, here’s a color plot of the yield for (D, \\frac{D_a}{D})(𝐷,𝐷𝑎𝐷) (starting from D = 1𝐷 =1 to help the visualization).\n680×545 49.7 KB\nIndividual consolidation incentives\nCredit to Anders for raising the issue of differentiated risk and for proposing the kind of individual incentives we explore here\nThough our exploration of collective incentives has found them to be decently strong, there is one factor we have not considered: validators with stake \\ll T≪𝑇 have a better risk profile than validators with stake \\ge T≥𝑇. This is because they are in the active only a fraction of the time, which means two things:\n\nIn a staking pool, accidental slashing caused by a bad setup can be caught early with only a fraction of the validators being subject to it\nTail risk of mass slashing or leaking, for example due to client bugs, is much lower, as in many cases this would only affect the active set. For a staking pool, this effectively caps the pool’s slashing exposure to a fraction of the stake, in almost all scenarios.\n\nWe might then be unwilling to solely rely on collective incentives, which cannot properly account for the risk differentiation between consolidated and non consolidated validators, itself an individual anti-consolidation incentive. On the other hand, we are hesitant to use individual consolidation incentives, because differentiated rewards threaten our goal of solo staking viability. Faced with this dilemma, a potential approach to mitigate the consequences on solo staking viability is to try to set individual consolidation incentives that just offset the added risk from consolidation. The goal is for risk-adjusted rewards to be roughly equivalent for consolidated and non consolidated validators, so that the available choices of higher risk, higher reward and lower risk, lower rewards are similarly attractive. In particular, it is then at least in principle possible (though not guaranteed) to have a validator set where both setups coexist, so that we can aspire to both have a high consolidation ratio and solo staking viability.\nConcretely, here’s a way we could go about this. Given the base yield y(D_a, D) = \\frac{I(D_a, D)}{D}𝑦(𝐷𝑎,𝐷) =𝐼(𝐷𝑎,𝐷)𝐷, we can adjust the yield of a validator with S𝑆 stake to be y(D_a, D)(1 + \\frac{\\min(S,T)}{T}g(\\frac{D_a}{D}))𝑦(𝐷𝑎,𝐷)(1 +min(𝑆,𝑇)𝑇𝑔(𝐷𝑎𝐷)), where g(x)𝑔(𝑥) is decreasing and g(1) = 0𝑔(1) =0. In other words, a validator with S𝑆 stake gets additional consolidation yield y_c(D_a, D, S) = \\frac{\\min(S,T)}{T}g(\\frac{D_a}{D})y(D_a, D)𝑦𝑐(𝐷𝑎,𝐷,𝑆) =min(𝑆,𝑇)𝑇𝑔(𝐷𝑎𝐷)𝑦(𝐷𝑎,𝐷), or equivalently its yield increases by a factor of \\frac{\\min(S,T)}{T}g(\\frac{D_a}{D})min(𝑆,𝑇)𝑇𝑔(𝐷𝑎𝐷), up to g(\\frac{D_a}{D})𝑔(𝐷𝑎𝐷) for fully consolidated validators with S = T𝑆 =𝑇. This factor decreases as \\frac{D_a}{D}𝐷𝑎𝐷 grows, because there are diminishing returns to further consolidation (same reason why the staking yield falls as the total deposit size grows). In particular, it falls all the way to 00 if \\frac{D_a}{D}𝐷𝑎𝐷 goes to 11, restoring the base yield y(D_a, D)𝑦(𝐷𝑎,𝐷) for everyone, and generally making the rewards less and less differentiated as more consolidation occurs. The idea is that an equilibrium will be reached where g(\\frac{D_a}{D})𝑔(𝐷𝑎𝐷) just about compensates for the additional risk from consolidating, and further consolidation is not incentivized. We can even set g𝑔 to reach 00 at some lower level of consolidation that we are happy with, leaving more space for staking with non consolidated validators to be economically viable. For example, if g(0.8) = 0𝑔(0.8) =0, then a validator with 32 ETH gets the same yield, and less risk, as a validator with 1024 ETH, even if 20% of the stake is made up of 32 ETH validators.\nLet’s now look at a specific form of g𝑔. The simplest possible choice is a linear function, which is fully determined by g(0)𝑔(0), the initial yield increase factor when there is no consolidation at all. The function is then simply g(x) = g(0)(1 - x)𝑔(𝑥) =𝑔(0)(1 −𝑥). For example g(x) = \\frac{1-x}{4}𝑔(𝑥) =1−𝑥4, where the maximum yield increase is 25%. The extra yield of a validator with stake S𝑆 is:\ny_c(D_a, D, S) = g(0)\\frac{\\min(S,T)}{T} \\cdot y(D_a, D) \\cdot (1 - \\frac{D_a}{D})𝑦𝑐(𝐷𝑎,𝐷,𝑆) =𝑔(0)min(𝑆,𝑇)𝑇 ⋅𝑦(𝐷𝑎,𝐷) ⋅(1 −𝐷𝑎𝐷)\nLet’s see what this looks like in combination with the collective incentives introduced in the previous section, where issuance is based on D_a𝐷𝑎, i.e., y(D_a, D) = \\frac{I(D_a)}{D}𝑦(𝐷𝑎,𝐷) =𝐼(𝐷𝑎)𝐷, and I𝐼 is the current issuance curve I(x) = c\\sqrt{x}𝐼(𝑥) =𝑐√𝑥. The maximum consolidation yield, or the yield advantage of a consolidated validator over a regular one, is:\n$y_c(D_a, D, S=T) = g(0) \\cdot y(D_a, D) (1 - \\frac{D_a}{D}) = \\\n= g(0) \\cdot c \\cdot \\frac{\\sqrt{D_a}}{D}(1 - \\frac{D_a}{D}) = \\ g(0) \\cdot c \\cdot \\frac{1}{\\sqrt{D_a}} \\frac{D_a}{D}(1 - \\frac{D_a}{D})$\nThe next color plot shows y_c(D_a, D, S=T)𝑦𝑐(𝐷𝑎,𝐷,𝑆 =𝑇) as a function of \\frac{D_a}{D}𝐷𝑎𝐷 and D_a𝐷𝑎, for g(0) = \\frac{1}{4}𝑔(0) =14 (some portion on the upper left corner is infeasible, because D𝐷 would be > 120M>120𝑀). Horizontally, the function looks like x(1-x)𝑥(1 −𝑥): the consolidation yield is low at low consolidation levels, when collective incentives are strong, and at high consolidation levels, when we don’t have a strong requirement for more consolidation and we are more worried about the economic viability of running non consolidated validators. Vertically it looks like \\frac{1}{\\sqrt{y}}1√𝑦, with the consolidation yield slowly falling off as D_a𝐷𝑎 grows and we have less need for consolidation in general, since the economic security of the active set is determined by D_a𝐷𝑎.\n829×707 92.9 KB\nWe can of course very easily modify any such function g𝑔 so that the incentives fall to 00 after a certain consolidation level r_0 \\in [0,1]𝑟0 ∈[0,1], by replacing g𝑔 with \\tilde{g}(x) = \\max(g(\\frac{x}{r_0}), 0)˜𝑔(𝑥) =max(𝑔(𝑥𝑟0),0), which squeezes g𝑔 in the range [0,r_0][0,𝑟0] and sets the consolidation yield to 00 afterwards. For example, this is the consolidation yield with r_0 = 80\\%𝑟0 =80%, starting from the previous g(x) = \\frac{1-x}{4}𝑔(𝑥) =1−𝑥4.\n811×707 77.5 KB\n\nAppendix\nValidator capping: active validator set variance\nLet’s also get an upper bound on the variance of the active validator set size. \\mathbb{V}[|V_a|] = \\mathbb{V}[\\sum_{i\\in V} \\chi_{\\{i \\in V_a\\}}] = \\sum_{i\\in V} \\mathbb{V}[\\chi_{\\{i \\in V_a\\}}]𝕍[|𝑉𝑎|] =𝕍[∑𝑖∈𝑉𝜒{𝑖∈𝑉𝑎}] =∑𝑖∈𝑉𝕍[𝜒{𝑖∈𝑉𝑎}], since each validator is sampled independently. Moreover, \\mathbb{V}[\\chi_{\\{i \\in V_a\\}}] = 0𝕍[𝜒{𝑖∈𝑉𝑎}] =0 whenever S_i \\ge T𝑆𝑖 ≥𝑇, since validator i𝑖 is then always in V_a𝑉𝑎.\nFor S_i < T𝑆𝑖 <𝑇, the variance is \\mathbb{V}[\\chi_{\\{i \\in V_a\\}}] = p(S_i)(1 - p(S_i)) = \\frac{S_i}{T}(1 - \\frac{S_i}{T})𝕍[𝜒{𝑖∈𝑉𝑎}] =𝑝(𝑆𝑖)(1 −𝑝(𝑆𝑖)) =𝑆𝑖𝑇(1 −𝑆𝑖𝑇), which is maximized when p(S_i) = \\frac{1}{2}𝑝(𝑆𝑖) =12, or equivalently when S_i = \\frac{T}{2}𝑆𝑖 =𝑇2, in which case \\mathbb{V}[\\chi_{\\{i \\in V_a\\}}] = \\frac{1}{4}𝕍[𝜒{𝑖∈𝑉𝑎}] =14. Therefore, \\mathbb{V}[|V_a|] \\le \\frac{1}{4}|V|𝕍[|𝑉𝑎|] ≤14|𝑉|.\nConcretely, say we keep a minimum balance of 32 ETH, so that the maximum validator set size |V||𝑉| is ~4M. The standard deviation of |V_a||𝑉𝑎| is then bounded by \\frac{\\sqrt{|V|}}{2} \\approx 1000√|𝑉|2 ≈1000. The probability of deviations beyond 10k is then vanishingly low. We can then even explicitly cap the active validator set size, say at 40k validators. Doing so introduces only a tiny correlation to the sampling of different validators, because sampling is completely unaffected other than in the exceedingly rare events of massive deviations.\nCollective incentives\nQuantifying the individual effect of collective consolidation incentives\nLet’s look into the consolidation incentives a bit more quantitatively. While it is true that there is always some consolidation incentive whenever consolidation is at all possible, we should also consider how strong these incentives are for various stakers. In particular, the strength of the incentives varies based on how large a staker is, because a consolidation increases yield for everyone, not just for the party which peforms it. In other words, the gains of a consolidation are socialized, to avoid having a sort of consolidation reward, which would effectively disadvantage smaller validators that cannot access it. Consolidation incentives are therefore stronger the larger a validator is. On the one hand, this means that sufficiently large validators have a strong incentive to consolidate, which means we should expect D_a𝐷𝑎 to always represent at least a meaningful portion of the total stake D𝐷. On the other hand, it means that small but still meaningfully sized stakers (e.g. 1%) might not be particularly incentivized to consolidate.\nTo quantify this, let’s look at how much of an issuance increase there is in the event of the full consolidation of a staker having a fraction p𝑝 of the total stake D𝐷, when \\frac{D_a}{D} = r𝐷𝑎𝐷 =𝑟. Here we assume that the stake pD𝑝𝐷 in question is initially not consolidated at all, and neglect the small effect it has on D_a𝐷𝑎 (e.g. if T = 1024𝑇 =1024, a minimum balance validator only increases D_a𝐷𝑎 by 1/32 of its stake). Issuance, and thus yield, increases by a factor of \\frac{I(D_a + pD) - I(D_a)}{I(D_a)} = \\frac{I((r + p)D)}{I(rD)} - 1𝐼(𝐷𝑎+𝑝𝐷)−𝐼(𝐷𝑎)𝐼(𝐷𝑎) =𝐼((𝑟+𝑝)𝐷)𝐼(𝑟𝐷) −1. Plugging in the definition of I𝐼, we can simplify this to \\sqrt{1 + \\frac{p}{r}} - 1√1+𝑝𝑟 −1. As expected, the consolidation incentives grow with p𝑝. It is also expected that they fall with r𝑟, since the issuance curve I𝐼 is concave. As it turns out, there’s no dependency on D𝐷 for this particular form of I𝐼.\nWe now plot 100(\\sqrt{1 + \\frac{p}{r}} - 1)100(√1+𝑝𝑟 −1), the percentage of yield increase that every validator experiences when a fraction p𝑝 of the stake is fully consolidated, starting from D_a = rD𝐷𝑎 =𝑟𝐷. We restrict r𝑟 to the range [0.1, 1][0.1,1] for ease of visualization, because the consolidation incentives blow up for r𝑟 near 00, as we would wish. Notice that the minimum r𝑟 is actually 1/321/32 for T = 1024𝑇 =1024 and minimum balance 32 ETH.\n668×558 62.8 KB\nOn the other hand, the absolute yield increase 100\\cdot\\frac{I(D_a + pD) - I(D_a)}{D_a}100 ⋅𝐼(𝐷𝑎+𝑝𝐷)−𝐼(𝐷𝑎)𝐷𝑎 is not independent of D𝐷. We plot it here specifically for D = 30M𝐷 =30𝑀 ETH. For lower values of D𝐷, the consolidation incentives only get stronger in absolute terms.\n812×715 87.6 KB\nFinally, we also plot the yearly ETH returns from consolidation, (I(D_a + pD) - I(D_a))\\cdot \\frac{p}{r}(𝐼(𝐷𝑎 +𝑝𝐷) −𝐼(𝐷𝑎)) ⋅𝑝𝑟, again for D = 30M𝐷 =30𝑀 ETH.\n843×728 98.4 KB\nGeneralizing collective incentives\nWhen I𝐼 is our current issuance curve, I(x) = c\\sqrt{x}𝐼(𝑥) =𝑐√𝑥, we have that I(D_a) = c\\sqrt{D_a} = c \\sqrt{D} \\sqrt{\\frac{D_a}{D}} = I(D)\\sqrt{\\frac{D_a}{D}}𝐼(𝐷𝑎) =𝑐√𝐷𝑎 =𝑐√𝐷√𝐷𝑎𝐷 =𝐼(𝐷)√𝐷𝑎𝐷. In other words, we can think about the previous proposal as incentivizing a high \\frac{D_a}{D}𝐷𝑎𝐷 ratio by directly a applying an issuance penalty based on it. More generally, we can let the issuance be I(D_a, D) = I(D) \\cdot \\delta(\\frac{D_a}{D})𝐼(𝐷𝑎,𝐷) =𝐼(𝐷) ⋅𝛿(𝐷𝑎𝐷) for any \\delta𝛿 such that \\delta(0) = 0𝛿(0) =0 and \\delta(1) = 1𝛿(1) =1. With this, the yield increase from consolidating is exactly \\frac{I(D)}{D} \\cdot (\\delta(r + p) - \\delta(p))𝐼(𝐷)𝐷 ⋅(𝛿(𝑟 +𝑝) −𝛿(𝑝)), i.e., a fraction \\delta(r + p) - \\delta(r)𝛿(𝑟 +𝑝) −𝛿(𝑟) of the maximum yield available at deposit size D𝐷. The percentage yield increase is instead \\frac{\\delta(r + p) - \\delta(r)}{\\delta(r)}𝛿(𝑟+𝑝)−𝛿(𝑟)𝛿(𝑟). The simplest case is \\delta(r) = r𝛿(𝑟) =𝑟, where I(D_a, D) = I(D) \\cdot \\frac{D_a}{D}𝐼(𝐷𝑎,𝐷) =𝐼(𝐷) ⋅𝐷𝑎𝐷, in which case the yield increase is simply p \\frac{I(D)}{D}𝑝𝐼(𝐷)𝐷, constant in r𝑟, and the percentage yield increase is \\frac{p}{r}𝑝𝑟.\nIn this form, we can more clearly separate the design of incentives to stake from that of incentives to consolidate the stake: I(D)𝐼(𝐷) provides the maximum possible incentive to stake at a given total deposit level D𝐷, while \\delta𝛿 regulates the incentive to consolidate at a given ratio \\frac{D_a}{D}𝐷𝑎𝐷. We can for example have I𝐼 being concave, as it is currently, but \\delta𝛿 linear as in the previous example: the protocol then considers stake deposits to have diminishing returns, while it believes consolidation to be equally valuable regardless of where \\frac{D_a}{D}𝐷𝑎𝐷 currently sits.\nDiscouragement attacks\nAt any point, it is possible to increase D𝐷 while barely increasing D_a𝐷𝑎, by activating validators with minimum balance. Thus, the issuance I(D_a)𝐼(𝐷𝑎) is approximately constant, but distributed to more stake. This is the same discouragement attack that would be possible with a constant issuance curve, or with issuance capped at some maximum value, where the yield also decreases like \\frac{1}{D}1𝐷. While worse than today, where it decreases like \\frac{1}{\\sqrt{D}}1√𝐷, this discouragement attack is nothing like the ultra cheap griefing vector that would arise with if we were to use issuance to target a validator count. For example, say we started reducing issuance past our ideal target of ~30k validators, and were to go negative at 40k. Then, activating a few thousands minimum balance validators, in the order of 0.01% to 0.1% of the stake, would be enough to make yields go negative. On the other hand, in the context of the discouragement attack we are considering here, reducing yield by a factor of k𝑘 requires increasing the deposit size by a factor of k𝑘. For example, halving issuance when D = 𝐷 = 20M requires depositing another 20M.\nStake capping\nIf we were to set the issuance based on D_a𝐷𝑎, we would not be able to immediately adopt any issuance curve that reduces issuance past some deposit size, like the ones discussed here and here. The reason for that is simple: if issuance goes down past a certain value of D_a𝐷𝑎, but it turns out that the yield at that point is still attractive, the incentives are such that D𝐷 would still grow (more stake wants yield at these levels) while D_a𝐷𝑎 would not (growing D_a𝐷𝑎 lowers yield). In fact, instead of consolidation incentives, we end up having incentives for splitting up stake over multiple validators, so as to decrease D_a𝐷𝑎 and keep it at the point of maximum issuance! Meanwhile, stake capping is not achieved, at least not any more than we would already achieve it by capping issuance at the maximum value, rather than having it decrease afterwards.\nIf we did want to adopt some form of stake capping, we would then need to do things a bit differently. We could let the issuance be I(D_a, D) = I(D_a) - f(D)𝐼(𝐷𝑎,𝐷) =𝐼(𝐷𝑎) −𝑓(𝐷), where f𝑓 acts to reduce the issuance past some critical total deposit size. Intuitively, the goal is to try to ensure two things at once: that we have enough D_a𝐷𝑎, and that we do not have too much D𝐷. For example:\n3580×1180 223 KB\nTo help visualizing the effect of this further, here are the cumulative issuance and yield while holding \\frac{D_a}{D} = 0.8𝐷𝑎𝐷 =0.8.\n3528×1180 245 KB\nFinally, here is a color plot of the yield in the (D, \\frac{D_a}{D})(𝐷,𝐷𝑎𝐷) space. D𝐷 starts at 2 to help the visualization be effective.\n828×556 69.3 KB\nIndividual incentives\nTotal issuance\nThe total extra issuance is:\n$I_c(D_a, D) = \\sum_{i \\in V} y_c(D_a, D, S_i) S_i = g(0) y(D_a, D)(1 - \\frac{D_a}{D}) \\sum_{i \\in V} p(S_i)S_i = \\ = g(0)y(D_a, D)\\cdot D_a(1 - \\frac{D_a}{D}) = g(0)I(D_a)\\cdot \\frac{D_a}{D}(1 - \\frac{D_a}{D}) = \\\n= g(0) \\sqrt{D} \\sqrt{\\frac{D_a}{D}}\\cdot \\frac{D_a}{D}(1 - \\frac{D_a}{D}) = g(0)I(D) \\sqrt{\\frac{D_a}{D}}\\cdot \\frac{D_a}{D}(1 - \\frac{D_a}{D})$\nThe total issuance then is:\n$I_T(D_a, D) = I(D_a) + I_c(D_a, D) = I(D_a)(1 + g(0) \\frac{D_a}{D}(1 - \\frac{D_a}{D})) = \\\n= c \\sqrt{D} \\sqrt{\\frac{D_a}{D}}(1 + g(0)\\cdot \\frac{D_a}{D}(1 - \\frac{D_a}{D})) = \\\n= I(D) \\sqrt{\\frac{D_a}{D}} (1 + g(0)\\frac{D_a}{D}(1 - \\frac{D_a}{D})) = I(D) \\cdot h(\\frac{D_a}{D})$, where h(x) = \\sqrt{x}(1 + g(0)x(1-x))ℎ(𝑥) =√𝑥(1 +𝑔(0)𝑥(1 −𝑥)). For g(0) = \\frac{1}{4}𝑔(0) =14, we have that h(x) \\le 1ℎ(𝑥) ≤1 for x \\in [0,1]𝑥 ∈[0,1], so I(D)𝐼(𝐷) remains an upper bound on the total issuance.\n547×435 15.6 KB\nGeneralizing individual consolidation incentives\nMore generally, we can choose any consolidation yield curve y_c(D_a, D, S) = \\frac{\\min(S,T)}{T} y_c(D_a, D)𝑦𝑐(𝐷𝑎,𝐷,𝑆) =min(𝑆,𝑇)𝑇𝑦𝑐(𝐷𝑎,𝐷), not necessarily depending on y(D_a, D)𝑦(𝐷𝑎,𝐷), or even any curve y_c(D_a, D, S)𝑦𝑐(𝐷𝑎,𝐷,𝑆) with a different kind of dependency on S𝑆. An interesting example of the first kind is the curve y_c(D_a, D, S) = \\frac{\\min(S,T)}{T} (y(D) - y(D_a, D))𝑦𝑐(𝐷𝑎,𝐷,𝑆) =min(𝑆,𝑇)𝑇(𝑦(𝐷) −𝑦(𝐷𝑎,𝐷)), where y_c(D_a, D, S)𝑦𝑐(𝐷𝑎,𝐷,𝑆) essentially interpolates between the yield y(D) = y(D_a = D, D)𝑦(𝐷) =𝑦(𝐷𝑎 =𝐷,𝐷) that would be paid out to a fully consolidated validator set at deposit size D𝐷, and the base yield y(D_a, D)𝑦(𝐷𝑎,𝐷) paid out at the current consolidation level. In other words, a validator with T𝑇 stake always gets paid the maximum possible yield for deposit size D𝐷, y(D)𝑦(𝐷), regardless of the consolidation level achieved by the whole validator set, while validators with minimum stake get paid closer to the base yield y(D_a, D)𝑦(𝐷𝑎,𝐷), and their yield linearly increases to y(D)𝑦(𝐷) as they consolidate. In this case, the consolidation incentives are quite a bit stronger at lower consolidation levels.\n811×707 115 KB\nWhile the absolute yield increase falls with D_a𝐷𝑎, the percentage yield increase from consolidating does not. As it turns out, it only depends on \\frac{D_a}{D}𝐷𝑎𝐷:\n$\\frac{y_c(D_a, D)}{y(D_a, D)} = \\frac{y(D) - y(D_a, D)}{y(D_a, D)} =\n\\frac{y(D)}{y(D_a, D)} - 1 = \\sqrt{\\frac{D}{D_a}} - 1 $\nIn other words, this also fits the previous form y_c(D_a, D, S) = \\frac{\\min(S,T)}{T} g(\\frac{D_a}{D}) y(D_a, D)𝑦𝑐(𝐷𝑎,𝐷,𝑆) =min(𝑆,𝑇)𝑇𝑔(𝐷𝑎𝐷)𝑦(𝐷𝑎,𝐷), with g(x) = \\sqrt{\\frac{1}{x}} - 1𝑔(𝑥) =√1𝑥 −1 instead of a linear function.\n1390×592 54.1 KB\nSince y(D_a, D) + y_c(D_a, D, S) \\le y(D)𝑦(𝐷𝑎,𝐷) +𝑦𝑐(𝐷𝑎,𝐷,𝑆) ≤𝑦(𝐷), it still holds that I(D)𝐼(𝐷) is a bound on the total issuance. In fact, the total issuance can be worked out to be I_T(D_a, D) = I(D_a) + I_c(D_a, D) = I(D) \\sqrt{\\frac{D_a}{D}}(1 + \\sqrt{\\frac{D_a}{D}} (1 - \\sqrt{\\frac{D_a}{D}})) = I(D) h(\\frac{D_a}{D})𝐼𝑇(𝐷𝑎,𝐷) =𝐼(𝐷𝑎) +𝐼𝑐(𝐷𝑎,𝐷) =𝐼(𝐷)√𝐷𝑎𝐷(1 +√𝐷𝑎𝐷(1 −√𝐷𝑎𝐷)) =𝐼(𝐷)ℎ(𝐷𝑎𝐷), with h(x) = \\sqrt{x}(1 + \\sqrt{x}(1 - \\sqrt{x})))ℎ(𝑥) =√𝑥(1 +√𝑥(1 −√𝑥))), which we compare here to the previous example:\n547×435 21.7 KB\n\n 3-Slot-Finality: SSF is not about \"Single\" Slot\n\n Vorbit SSF with circular and spiral finality: validator selection and distribution\n\n Native Rollup for 3SF\n\n Blob EIPs and Minimum Validator Requirements\n\n Practical endgame on issuance policy\n\n read \n\n 15\n min\n\n post by murrlincoln on Jun 30, 2024\n\n post by dapplion on Jul 1, 2024\n\n 27 days later\n\n post by alonmuroch on Jul 28, 2024\n\n Powered by Discourse","tokens":9244,"squid":"spider-04","role":"Research Spider","at":1791346698751,"hash":"05c20bf898e837d9414c159a1271e03967bdd88d"}
{"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":"spider-05","role":"Spec Spider","at":1791346701563,"hash":"aa386781f76bf4d4763140dbb3ae8e356e66a255"}
{"url":"https://jup.ag/spot/watchlist","domain":"jup.ag","title":"Solana Token Watchlist | Jupiter","text":"Token////SOL$118.04-1.78%$69.5B$75.0B$3.46B$29.6M$981M3.82M-JUP$0.3263-6.53%$1.08B$2.23B$14.1M$358K$5.80M838K-0.02%Recent HappeningsUpdated 7:00 PMSolana Foundation launched an open-source Delivery versus Payment settlement program enabling financial institutions to complete asset transfers and payments in seconds rather than days, with JPMorgan providing key inputs to the design.NewsThe Block13h agoSolana treasury DeFi Development authorizes CHAD preferred stock buyback programSolana treasury firm DeFi Development approved an open-ended program to repurchase CHAD preferred stock if it trades below its $10 par value.Cointelegraph15h agoCapital starting to rotate back to crypto from AI: Raoul PalReal Vision founder Raoul Pal says a pause in the AI stock rally could help crypto attract capital, while AI agents are likely to boost Ethereum and Solana adoption.Cointelegraph15h agoCapital starting to rotate back to crypto from AI: Raoul PalReal Vision founder Raoul Pal says a pause in the AI stock rally could help crypto attract capital, while AI agents are likely to boost Ethereum and Solana adoption.Cointelegraph19h agoSolana Foundation targets settlement in seconds with DvP launchSolana DvP offers financial institutions an open-source settlement program designed to complete asset transfers and payments in seconds.Solana@solana22h agoMert, CEO at Helius, on why the long tail is Solana's superpower\n\n\"When it comes to the long tail, it's Solana's superpower. Pairing memecoins with stocks seems silly at first, but it does increase access, and it brings new startups onchain who want to build on top of that.\"\n\n\"I Show moreWatch on X819Solana@solana24h agoLily Liu, President of Solana Foundation, on the largest capital market in the world \n\n\"The internet capital market is going to be the largest global capital market. It might take a decade, but it is the absolute direction of travel.\"\n\n\"Look at Southeast Asia. Many countries, all Show moreWatch on X00CoinDesk24h agoSolana Foundation unveils a program to settle institutional trades in seconds. JPMorgan gave inputSolana Foundation launched an open-source program that lets institutions settle trades in seconds, not days. JPMorgan provided key inputs.Solana@solana1d agoLive from Solana Summit Singapore 🇸🇬Solana Events@SolanaEventsLive from Solana Summit Singapore 🇸🇬 x.com/i/broadcasts/1…2330Decrypt1d agoSolana Debuts Institutional Settlement Standard With J.P. Morgan InputBuilt with input from J.P. Morgan, the open-source \"DvP\" program lets institutions settle trades atomically on Solana with finality in seconds instead of days.Decrypt1d agoDeFi Development Corp Adds $3 Million in Solana as SOL Buys SlowNasdaq-listed DeFi Development Corp's latest SEC filing shows its Solana stash grew 1%, to about 2.56 million SOL and SOL equivalents—roughly half the prior week's gain and well below mid-September's pace.The Block2d agoDeFi Development sees NAV per share more than doubling, holds 2.56 million SOLDFDV says preliminary Q3 estimates show NAV per share more than doubled as its Solana treasury grew to 2.56 million SOL.Solana@solana3d agoNasdaq listed it, Solana moved it. A drone defense company did more volume onchain than on its home exchange, while Fiserv plugged in 90+ banks and credit unions. Q3 app revenue hit $365M, the tenth straight quarter Solana has led.\n\nHere’s everything that happened this week: \n\n📰  Show more00Solana@solana3d agoDan Roberts, CEO of @onrefinance, on why reinsurance went to market on Solana.\n\n\"It seemed like a very powerful place to go to market. Not just transaction speed, but a very engaged cohort of markets. Instead of being a new business going out into the world on your own, Solana Show moreWatch on X92378CoinDesk4d agoCrypto job postings triple to over 1,200 in September, but applications fallFinance, engineering and trading led hiring demand, while Bitcoin, Ethereum and Solana were the most frequently requested blockchain skills.Solana@solana4d agoJUST IN: Solana processed a record 14.2B non-vote transactions in Q3, up 45% from Q2.\n\nSource: @Blockworks92355Kodi@senyor_kodama4d agoSIMD-0675 would reorder Solana's leader schedule so nearby leaders go one after another.\n\nReplayed on 10 recent epochs, this geo-aware schedule would cut the mean leader hop in half (3,657 → 1,808km). Asia and the US gain the most (20-27ms per handover); Europe ~9ms.Roger Wattenhofer@TheWattenhoferSolana block production with a geo-aware leader schedule (SIMD-0675) and a run length of 5. 👇 Watch on X342SolanaFloor@SolanaFloor5d ago🚨BREAKING: @Solana continues to dominate app revenue across all chains for the 10th consecutive quarter, with Q3 2026 revenue up 42.6% QoQ to $365M, the highest since Q4 2025.\n\nTop apps by Q3 revenue share:\n\n🥇 @Pumpfun : 39%\n🥈 @fomo : 14%\n🥉 @AxiomExchange : 11% 719Solana Foundation@SolanaFndn5d agoSolana accounts for ~45% of adjusted stablecoin volume this year.\n\nOn House of Sol, Ben Brophy and William Lai, Head of Institutions at @AlliumLabs, talk about what institutions are asking about stablecoins, tokenized assets, and DeFi.\n\n0:00 William Lai and what Allium does\n0:59 Show moreWatch on X2167CryptoSlate5d agoSolana enters US banking with 90 North Dakota banks leading itRoughrider enters production with VersaBank USA issuance and institutional access, while actual payment volume remains undisclosed. The post Solana enters US banking with 90 North Dakota banks leading it appeared first on CryptoSlate .CryptoSlate5d agoPropAMMs lower Solana trade costs, and public pool returns crashA September preprint finds cheaper quiet-market SOL/USDC execution at professional pools, while passive depositor returns require separate accounting. The post PropAMMs lower Solana trade costs, and public pool returns crash appeared first on CryptoSlate .","tokens":1456,"squid":"spider-02","role":"Liquidity Spider","at":1791346708995,"hash":"91316b60a54e2c2d9f2d1bd235bfbad2bce2e4ba"}
{"url":"https://ethresear.ch/t/endgame-staking-economics-a-case-for-targeting/18751","domain":"ethresear.ch","title":"Endgame Staking Economics: A Case for Targeting - Proof-of-Stake / Economics - Ethereum Research","text":"Endgame Staking Economics: A Case for Targeting \n\n Proof-of-StakeEconomics\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Feb 2024\n\n 1 / 37\n\n Feb 2024\n\n Apr 2025\n\n post by casparschwa on Feb 21, 2024\n\n casparschwa\n\n Endgame Staking Economics: A Case for Targeting\nby @adietrichs and @casparschwa .\nThis post explores the status quo of staking economics, its drawbacks as we see them and what the endgame of staking economics could look like.\nRead about our separate proposal for an immediate issuance policy update in Electra here.\n\nMany thanks to Anders, Barnabé, Francesco, Julian, Dankrad, Thomas, Vitalik, Mike, Justin, Jon, Nixo, and Sam for feedback and discussions.\nReviews \\neq≠ endorsements. This post expresses opinions of the authors, which may not be shared by reviewers.\n\ntl;dr\n\nToday, 30M ETH or 1/4 of all ETH, is staked, with the trend of increasing staking showing no signs of stopping.\nWe argue that most of new stake will be driven by LSTs, which gain in money-ness with adoption and time.\nA world in which most of ETH is staked through LSTs has several implications that we consider negative: LSTs have winner-takes-most dynamics due to network effects of liquidity. Economies of scale increase competitive pressure for solo staking viability. Further, a LST replacing ETH as the de facto money of the network (apart from L1 tx fees) leads to Ethereum users being exposed to counterparty risk inherited by the LST by default. For true economic scalability the money of Ethereum should be maximally trustless.\nToday, the issuance yield does not ensure a limit to the amount that can be staked profitably. LSTs have significantly changed the cost structure of staking, making it possible that most ETH will be staked eventually.\nWe argue that endgame staking economics should include an issuance policy that targets a range of staking ratios instead, e.g. around 1/4 of all ETH. The intention is to be secure enough but avoid overpaying for security and thereby enabling said negative externalities.\nFinally, we highlight some open research questions that need answering to make a targeting policy feasible.\n\nThe figure below shows the amount of ETH staked over time. Historically, staking has known one direction: up only. In this post, we put forward arguments for why we think this trend will likely continue, what the negative externalities of it are, and make a case for a path forward to avoid this plausible future.\n2920×966 147 KB\nIn short, the current issuance policy allows for all ETH to be eventually staked. This arguably over-secures the protocol and comes with negative externalities. We elaborate why the endgame of staking economics should target a staking ratio range instead. The intention is to provide enough security for the protocol, while limiting the negative externalities of too much stake in the system.\nCurrent Issuance Policy – where we are & where it’s going\nTo frame our argument, we reason about what long term equilibria of stake participation are viable under the current issuance policy.\nThe Ethereum protocol requires some stake participation to secure itself. The demand for stake is very clearly defined in the form of the issuance curve. Given some level of stake participation, the protocol issues some maximum amount of rewards. Instead, the willingness to supply stake varies across ETH holders and is not public knowledge. Hence, we are left to reason about it.\nDemand for Stake – take my ETH and give me security\nEthereum inherits its security from its validators, who stake ETH for the right to earn rewards. The protocol’s demand for security is expressed in its willingness to issue ETH for validators correctly performing their assigned duties. How much security is sufficient and how much might be too much is discussed here, here and here and otherwise beyond the scope of this post.\nThe Ethereum protocol issues new ETH to recruit ETH holders as stakers. It rewards correct validation according to a fixed issuance curve. Further, validators earn MEV rewards in their role as block proposers. Both sources of yield contribute to the incentive to stake.\n\n990×589 39.4 KB\nIssuance yield (solid green line). The current issuance yield curve is defined as y=\\frac{cF}{\\sqrt{ETH\\ Staked}}𝑦 =𝑐𝐹√𝐸𝑇𝐻 𝑆𝑡𝑎𝑘𝑒𝑑 with c\\approx 2.6𝑐 ≈2.6 and F=64𝐹 =64 and represents the maximum issuance yield available for an optimally performing validator [1]. The rewards decrease as staking participation increases – first quickly, then more slowly. The protocol tries to ensure some minimum level of security and thus rewards validators more generously at low levels of staking participation. As more stake secures Ethereum, the marginal value of validators decreases and hence staking rewards are reduced.\nTotal staking yield (dashed green line). It is the sum of (nominal) issuance yield and MEV yield and forms the demand curve for stake [2]. MEV yield is exclusively available to validators in their role as block proposers. It is calculated as the annual amount of MEV extracted (~300,000 ETH over last year) over the amount of ETH staked. As a constant amount of MEV is shared by more validators, MEV yield decreases more rapidly than issuance yield, because it does not change with staking levels. The amount of MEV has stayed remarkably constant over time. While this could clearly change, for simplicity we will refer to the demand curve as fixed.\nThe current issuance curve was chosen over a plethora of reasonable functions. This particular curve conveys two clear messages:\n\nIt deliberately aims to avoid too low staking participation, by paying out very high rewards at low staking levels.\nIt suggests diminishing marginal utility for each additional staker, with issuance yield decreasing as staking participation increases.\n\nHowever, the issuance curve is not intentional about the level of staking participation it wants to achieve. Notably, there is no mechanism to prevent the staking ratio from exceeding some threshold. In fact, even if the entirety of ETH is staked, the incentive to stake still mounts up to ~2%, favoring those who stake over those who do not. While the issuance curve subtly suggests that the value of each additional staker diminishes, the protocol does not exert fine control over the eventual staking ratio reached. Essentially, beyond ensuring minimum security through initial high incentives, the protocol doesn’t encourage an optimal range of staking levels.\nNote that the issuance yield depicted above is nominal yield. It does not account for the dilution that takes place as more ETH is issued. The relevance of this dilution effect increases as more ETH is staked. However, as it affects both staked and unstaked ETH equally, it does not affect the net incentive to stake (i.e. the yield gap between holding raw ETH and staking it). We can therefore ignore dilution in this analysis for now – we will get back to it at a later point in this article.\nSupply Side – give me ETH and have my stake\nHaving explored the demand for stake, we now turn our attention to the supply side. The supply curve represents the willingness of ETH holders to stake at different staking yields, indicating the necessary incentives for each stake participation level. This curve typically slopes upwards, suggesting that higher staking participation levels require greater incentives. However, since the willingness to stake cannot directly be observed or measured, the exact shape of the supply curve remains unknown, only allowing for qualitative assessments.\nIn addition, the supply curve is not fixed over time. In the following sections we will illustrate how staking costs change over time, and such changes naturally impact the level at which ETH holders need to be incentivized to stake – in other words, they shift the supply curve.\nThe only direct observations of the supply curve that we do have are the historical staking levels. These represent the intersection between demand and supply curve at any given moment in time, and with the demand curve known, this gives us certain knowledge of a single point of the supply curve for each historical moment of the beacon chain, up to and including today.\nAs the first graph illustrated, the total amount of staked ETH has continued to grow since the launch of the Beacon Chain. Given the demand curve has remained constant [3], it then follows that this growth in ETH staked is due to a downward shift of the supply curve. In other words, this indicates that the willingness among ETH holders to participate in staking has increased – even at today’s lower issuance yield levels. The following graph illustrates this trend by sketching out plausible shapes of historical short term supply curves:\n2706×1634 207 KB\nJust looking at this historical trend, it is clear that for the near-term future, a continued downward shift of the supply curve and thus a continued net inflow of stake is reasonable to expect. However, the more interesting questions are those about the potential long term staking equilibria. To be able to make informed assessments here, we need to have a closer look at the composition of the supply side.\nThe decision for any ETH holder to stake depends on two things: The incentives provided to stake (total staking yield = issuance yield + MEV yield) and the costs of staking. While the former is relatively homogenous across stakers [4], the cost structure fundamentally varies for different staker types. In the following we contrast solo stakers and staking service providers.\nSolo Staking vs. Staking Service Providers (SSPs)\nStaking Service Providers (SSPs) receive ETH from their users and stake it for them, charging a fee for their service. In most cases, they give users liquid staking tokens (LSTs) as a receipt for their ETH. An LST is fungible and can be freely used and traded. The extent to which this liquidity is useful for it’s holder varies among LSTs and is a function of overall adoption and support by third-party protocols for a given LST. In the following we will only talk about LST-issuing SSPs - those that do not issue LSTs can be considered as a special case of LSTs with zero liquidity value.\nSolo staking is trustless, but illiquid and inconvenient; liquid staking requires varying degrees of trust but is very convenient and importantly liquid.\n\nSolo Staking\nSSPs\n\nCosts\nHigh fixed costs: hardware + setup effort. additional variable costs (internet connection, electricity, etc.)\nVariable costs: SSPs typically take a cut of validator rewards (e.g., 10%, 14%, 25%,…)\n\nRisks / trust assumptions\nTrust your own node operation\nNode operator risk + smart contract / legal risks + governance risks [5]\n\nConvenience\nRequires technical skills for setup and ongoing maintenance.\nOffers a simple, one-click solution to earn yield.\n\nLiquidity\nLimited (to restaking); ETH is locked in the deposit contract.\nVarying, but potentially high; LSTs are widely integrated in various protocols, enabling liquidity and revenue streams.\n\nComparing these two staking types suggests two main conclusions, relevant to the supply discussion:\n\nThe cost structure for solo staking is heterogeneous across ETH holders. The technical skill required, the variation in local cost for hardware and ongoing resources, and the difference in confidence in successful safeguarding of the ETH at stake, all contribute to a relatively steep supply curve for solo stakers. Without major improvements in solo staking UX, the pool of possible solo stakers at anything close to current issuance levels is likely mostly depleted.\nIn contrast, the cost structure for SSPs is much more homogeneous across ETH holders, with variation mostly in the assessment of operator risk and the LST-vs-ETH liquidity penalty. As a result, the SSP supply curve is considerably flatter, meaning that the issuance required to recruit more ETH holders as liquid stakers, only increases slowly.\n\nIn addition, the cost of solo staking remains independent of the level of staking participation, whereas the cost of holding LSTs will likely go down over time and with increased adoption:\n\nMoney-ness of LSTs increases. As one LST becomes more popular, it can be expected to be supported by more and more projects in addition to native ETH (e.g. more defi integrations, L2s starting to liquid-stake bridged ETH by default). With a sufficiently high staking ratio, the winning LST could eventually even surpass the remaining unstaked ETH in available volume, completely closing (and potentially even flipping) the gap in liquidity.\nSmart contract risk decreases: “battle tested”, formal verification, etc.\nGovernance systems improve their robustness, e.g. this proposal.\nPerceived tail risks of mass slashing might decrease. Any LST scaling to subsume a significant portion of the overall ETH in existence could reasonably create a too-big-to-fail impression, where users expect a protocol bailout in case of failure, effectively driving down their perceived operator risk to 0.\nSSPs can offer lower fees to break even at higher staking ratios.\n\nIn summary, this suggests that the supply curve is significantly flattened by SSPs and LSTs in particular, meaning the incentives required to attract additional staking do not need to increase substantially as the total amount of staked ETH grows. A continued future increase of stake driven by liquid staking can be expected. But just how much more ETH will be staked in the long run?\nLong term equilibria – are we gonna keep staking or what?\nWe now put together the demand and supply considerations to reason about possible long term staking equilibria.\nWe argued that the demand curve is very opinionated for low staking participation but otherwise leaves it relatively open what staking ratios might be reached in the long run.\nWe then explained the dynamic of downward shifting supply curves over time, as the costs and risks of staking continue to decrease. The resulting new net inflow of stake will mostly flow towards LSTs. In particular, it is unclear whether the supply curve would be steep enough to set practical limits to staking participation.\nThus, there is a broad range of possible equilibria for the overall staking ratio, with ratios close to one among the plausible outcomes. The following sketch illustrates how even relatively small differences in the (hypothetical) long term equilibrium supply curve can lead to very different outcomes:\n2724×1628 211 KB\nThe key take-away is not that staking participation levels will necessarily be high, but that such high levels are plausible.\nWith this in mind, we now detail our concerns around high staking ratios, before presenting possible changes to the issuance policy preventing these.\nStaking Ratio – when is less stake more?\nWith ~30 million ETH staked from a total supply of ~120 million, the staking ratio s𝑠 is defined as \\frac{ETH\\ Staked}{Total\\ Supply\\ of\\ ETH}𝐸𝑇𝐻 𝑆𝑡𝑎𝑘𝑒𝑑𝑇𝑜𝑡𝑎𝑙 𝑆𝑢𝑝𝑝𝑙𝑦 𝑜𝑓 𝐸𝑇𝐻 and stands at \\frac{1}{4}14.\nBefore diving into the concerns we see for high staking ratio regimes, we again point to some references, discussing what level of stake participation might be secure enough. In short, current staking levels are arguably sufficiently secure. This then raises the question - if we don’t need it for security, should we be okay with staking participation sufficiently higher than today?\nWe argue that high staking ratio regimes come with negative externalities that affect ETH holders, (solo) stakers, as well as the protocol itself.\nNetwork Effects of Money (LSTs) – no thanks to forced risk taking\n\nLSTs compete on money-ness with winner-takes-most if not all dynamics due to network effects. As a LST is more widely used, it becomes more useful driving further adoption. The money-ness of LSTs increases in aspects such as degree of integrations (on- and offchain), trading liquidity, resilience against governance/legal attacks, etc.\nIn a high staking ratio regime in which one SSP controls most stake, the LST may be considered too-big-to-fail. Is it a credible threat to slash, if a majority of all ETH in existence would be affected? More generally, the governance of such a dominant SSP would de facto become a part of the protocol, without being accountable to all Ethereum users.\nIn a world in which most existing ETH is liquid-staked, the de facto money of Ethereum for most use cases besides L1 transaction fees will be some LST(s). All LSTs, be they issued by an ETF, centralized exchange or onchain staking pool, come with different trust assumptions – some worse than others. But ultimately Ethereum users will end up holding LSTs, economically quasi-forced to expose themselves to those added risks (operator/governance/legal/smart contract/etc. risk). Is this desirable for Ethereum users? Further, such intermediated ETH is worse collateral. For true economic scalability, the money of Ethereum needs to be maximally trustless: ETH.\n\nMinimum Viable Issuance – in it for the UX\n\nMinimum viable issuance as a guiding principle suggests enough staking participation to be sufficiently secure, but not more. There comes a staking level beyond which the protocol is secure enough and the marginal utility of a staker turns negative (networking load increases, ETH holder dilution, etc.).\nEthereum users should not have to concern themselves with the complexities of staking to prevent their ETH holdings from getting diluted. Staking is a service that the protocol requires and pays for, but it should not be economically quasi-forced upon all its users.\nMore issuance implies more dilution for all ETH holders and stakers. However, SSPs are shielded from this downside. They don’t hold the ETH that underlies the staked position, but instead derive their revenue from SSP fees that they charge for their services, which naturally increase for higher staking ratios.\nAt a hypothetical staking participation level of 90% with 2% yield, assuming a liquid staking share of 90% and an average SSP fee of 10%, 0.16% of Ethereum’s market cap, or ~200,000 ETH, or ~530 million USD at current prices, are paid in SSP fees every year – a de facto tax on all ETH holders.\n\nReal Yield – the real deal\nAs we discussed in the beginning of the article, the nominal yield for stakers from issuance is progressively diluted with higher staking participation. To adjust for this effect, it is useful to look at the real staking yield.\nReal yield is nominal yield adjusted for the dilution effects of ETH issuance [6].\n6000×3600 617 KB\nThe graph depicts the impact of dilution on yield for both stakers and non-staking ETH holders. For ETH holders (red line) this implicit yield is of course negative, as their nominal balance remains unchanged, while they are exposed to the same dilution effect as stakers. To better characterize the impact of this effect, we can broadly distinguish between two different staking ratio (s𝑠) regimes:\n\nOn the left, for low s𝑠, the real yield curves relatively closely resemble the nominal yield curves we previously examined. With few stakers the total amount of new ETH minted is respectively small, resulting in only a small dilution effect. The net incentive to stake is made up primarily by the positive yield available to stakers – or visually it’s mostly green.\nOn the right, for high s𝑠, the real issuance yield diverges more strongly from the nominal yield curves. With an increased number of stakers earning validator rewards, total ETH issuance is higher, leading to this more noticeable dilution effect. Besides the diminished real yield, a significant portion of the net staking incentive now derives from “dilution protection”, essentially the avoidance of losses that would be incurred by passively holding ETH. In the extreme, as the staking ratio approaches 1, real total staking yield only consists of MEV yield.\n\nThe shifting composition of the net incentive to stake is a fundamental area of distinction between the two staking ratio regimes. At this point, we want to stress that this composition does not change the effectiveness of the incentive to stake. In other words, dilution protection incentivizes stakers just as much as real staking yields!\nWhat does change though is the desirability of the outcome resulting from that incentive. For low s𝑠, staking is a profitable service paid for by the protocol. But for high s𝑠, staking loses its profitability and instead becomes an unpleasant necessity to avoid losses from passively holding ETH. Thus, by allowing the staking ratio to “slide to the right”, we risk ending up in the worst of all worlds: Staking becomes a necessary indirection layer, exposing minimal real yield, but threatening dilution for those opting out of accepting LST trust assumptions.\nIf you give a staker the choice between living in some equilibrium (a) or equilibrium (b) for different issuance policies, this staker, assuming they would stake in both equilibria, would prefer the equilibrium paying higher real staking yield. For obvious reasons a staker cannot “choose” an equilibrium, but the protocol issuance curve effectively determines which equilibrium is reached (given some fixed long term supply curve). Higher issuance is associated with more nominal yield, but importantly, more nominal yield does not imply more real yield.\nSolo Staking Viability – down bad\n\nSSPs with fixed costs naturally benefit from economies of scale, allowing them to operate more profitably (or charge lower fees) as they have more ETH under management. Successful SSPs might be viewed as too-big-to-fail, reducing their perceived tail risks and further contributing to such scale effects. In contrast, solo staking comes with per-staker costs that do not decrease (rather even slightly increasing with networking load!) as the total amount of stake grows. In fact, EIP-7514 was in part merged for this reason.\nAs a larger share of issuance goes towards “dilution protection” and no longer contributes to real yield, stakers are left with more and more of their remaining real yield coming from MEV. This yield is by its nature highly variable, which leads to increased volatility of real total yield for solo stakers. For SSPs on the other hand this MEV income is smoothed over all validators they operate, removing staking yield volatility as a concern for them.\nThe liquidity gap between solo staking and LSTs widens with increased adoption and moneyness of LSTs. Put differently, the competitive disadvantage of solo staking relative to liquid staking increases as the staking ratio increases.\nIn many jurisdictions, the basis for government taxes on staking income is the nominal income, not the real income adjusted for dilution effects. LSTs can be structured in a way to shield holders from this effect, while for solo stakers this is usually not possible. This further increases the profitability gap as the difference between nominal yield and dilution-adjusted real yield widens.\n\nDiscussion\nThe considerations above lead us to argue for the following:\n\nHolding raw ETH should be economically feasible, to ensure user friendliness and preventing dilution beyond ensuring sufficient security.\nFor true economic scalability, Ethereum’s de facto money should be maximally trustless [7].\nAn outcome with most of the incentive to stake coming from dilution protection is undesirable for both stakers and ETH holders.\nHigh staking participation worsens the competitive disadvantage of solo staking.\n\nEthereum’s future staking ratio is uncertain; however, the absence of control over maximum staking levels warrants a proactive approach in determining optimal levels. Even if high staking ratios may be preferable to some, it should then be a deliberate choice, not an accidental result of exogenous market dynamics.\nThe following sections are concerned with proposing alternative issuance policies.\nStake Ratio Targeting – endgame staking economics\nAn endgame staking policy for Ethereum should target a staking ratio, rather than a fixed quantity of staked ETH. This approach ensures accounting for the variable supply of ETH, which changes over time due to EIP-1559 and issuance. In practice, the total supply of ETH currently changes so slowly (-0.3% per year since the merge) that this distinction does not matter in the medium term. However, the intention of an endgame policy is to not require adjustments, even over longer time horizons.\nAs discussed, while the current issuance curve is designed to ensure a minimum level of staking, it lacks a mechanism to cap staking at an upper bound, potentially resulting in high staking ratios. We argue that a robust endgame issuance policy should express desired staking participation levels by implementing controls on both the lower and upper bounds of staking ratio. Specifically, it should aim to maintain staking ratios within a defined optimal range that reflects the network’s security requirements without enabling negative externalities further.\nThe protocol can express strong opinions for “too-low” and “too-high” staking ratios alike, by issuing very high or low rewards (possibly also negative) respectively. By doing so the protocol regains control over its level of staking participation. To illustrate the existence of a curve with such properties consider the following plot, which is close to Vitalik’s curve here.\n6000×3600 475 KB\nIn this plot we observe that for low amounts of staking participation the issuance curve rewards generously, similarly to today’s issuance policy. As stake levels increase, issuance yield tapers off and finally turns negative. That way, staking becomes increasingly disincentivized, until it even becomes more profitable to hold ETH than to stake it. In practice, this range of negative total staking yields would not be maintained, with staking participation finding a lower equilibrium. Thus, any curve of such shape would give strong guarantees for the range of viable staking ratios.\nPractically it might not be necessary to choose a curve which turns negative so abruptly to achieve similar range targeting properties. In fact, curves that bring issuance rewards down to (or close to) zero beyond some point might even be sufficient for that purpose.\nImplications of Targeting\nThe main advantage of targeting is that it prevents all of the negative aspects of a high staking ratio regime enumerated in the section above. The notable exception to this is the concern around reward variability for solo stakers. Like in the high staking ratio regime, under targeting the share of real yield coming from MEV is also higher than today. A downside of a move to targeting is thus an acceleration of this (already existing) dynamic. However, this increased variance can be mitigated through MEV capture mechanisms such as Execution Tickets or MEV Burn, or instead by introducing a staking fee.\nOne criticism sometimes brought forward against targeting is that it reduces the overall equilibrium yield, thus worsening the existing competitive pressure between solo staking and SSPs, as well as across different types of SSPs. The idea here is that when there is more money to go around, slightly less competitive forms of staking that might be desirable for the protocol have an easier time staying profitable. To address this concern, the distinction between nominal and real yield is crucial. A move to targeting unquestionably reduces nominal yields when compared to the equilibrium that would otherwise be reached in the long run. However, the same is not generally true about real yield, which is what really matters, as the following sketches illustrate.\n3533×1077 316 KB\nThe left graph depicts a plausible example for a long term equilibrium under targeting, the right graph similarly an example using today’s issuance curve. Crucially, both examples use the same hypothetical long term supply curve, allowing for a comparison of outcomes. As one can see, the chosen example would in the non-targeting case lead to a high staking participation of around 100M ETH. At that level, most of the staking incentive comes from dilution protection, with a real yield of only around 0.5%. Conversely, under targeting, the same example leads to an equilibrium with lower nominal yield, but little dilution and thus a real yield of around 1.4%.\nThis example illustrates how targeting can plausibly lead to significantly higher real yield levels than the equivalent outcome under the current system. To the extent that yield levels indeed matter for intensity of competition among different staking types, targeting can thus help prevent a near-zero outcome for real yield. It should be noted here that this is not only beneficial under the aspect of competitive pressure – keeping staking profitable is beneficial for stakers of all types. Moreover, it also benefits non-staking ETH holders, by minimizing the dilution they are exposed to.\nOpen Questions\nThis article advocates for the general principle of stake participation targeting. To move to an actual specification that could then be implemented on Ethereum, there are still several open questions that need to be addressed. In closing, we want to briefly touch on each of these questions.\nWhat is the desirable range for stake participation?\nWe have deliberately only talked about undesirable ranges, but never specified a precise and desirable range. This is because it is inherently hard to objectively reason about it and needs to be discussed more broadly in the community. The main tradeoff is that little stake participation leaves the protocol open to cheap attacks, while too much staking creates negative externalities as discussed in earlier sections. We once again link to some preliminary discussion on the topic by Vitalik, Vitalik, and Justin. One helpful way to model the decision is by considering the utility of different staking ratios. One possible example for such a utility curve is sketched below.\n3017×1623 102 KB\nHow to pick a suitable issuance curve, given some target range?\nOnce a target range is picked, there is still a wide design space of possible issuance curves, that could be chosen to achieve the specified goals. Further work is necessary to compare the possible choices and pick the best candidate. In addition, alternative targeting mechanisms, such as an EIP-1559-like feedback controller, should continue to be explored.\nHow to ensure incentive compatibility of consensus duties for close-to-zero or negative issuance?\nThe purpose of issuance is to reward the correct performance of validators fulfilling their consensus duties. However, under a targeting policy it might be possible for issuance yield to approach zero or even turn negative. A validator might still be incentivized to stake with issuance levels approaching zero or less, for the possibility to capture MEV. However, with no issuance it is rational for a validator to not fulfill all consensus duties. This goes to show that for low issuance levels consensus incentives risk breaking down. To mitigate this, the protocol could charge a fee for the right to validate (and again reward correct participation). This reestablishes incentive compatibility. However, this adds protocol and implementation complexity, of which the details need to be figured out.\nHow to remove the reward volatility introduced by MEV?\nAs mentioned before, the mitigation of increased reward volatility is important for solo staking viability and can be achieved through MEV capture mechanisms such as Execution Tickets or MEV Burn, or instead by introducing a fee for validators, as per discussion above. While shipping targeting with one of these solutions already in place would be preferable, in principle this is not a strict dependency.\nHow to set the target in relative (staking ratio) instead of absolute (fixed ETH amount) terms?\nA targeting policy could of course also target a fixed amount of ETH, e.g. 30M ETH. But for future-proofing the issuance policy it is preferable to directly target a staking ratio instead, e.g. \\frac{1}{4}14. For the issuance policy to target some staking ratios the consensus layer needs to be aware of the amount of stake and supply of ETH. The latter is currently not the case, but could be achieved in a simple two-fork process:\n\nFork (1): Start tracking supply changes relative to the time of fork (1).\nFork (2): Add total supply of ETH at time of fork (1). This together with the ongoing tracking of supply changes since fork (1), gives a running total supply of ETH.\n\nHow to transition to a targeting mechanism, when starting with stake participation levels beyond the target range?\nThe simplest way to transition to a targeting policy is to of course start within the target staking range. However, in the likely scenario that the target range will be surpassed before the transition, this would necessitate a decrease in staking participation. Even with a gradual easing into the new curve, this would in practice entail a significant period, during which stakers would be insufficiently compensated, until the excess stake can exit. It remains an open question how to minimize the adverse impacts on stakers of such a transition.\nConclusion\nWe discussed the current issuance policy, explained negative externalities as we see them, and elaborated what a path forward could look like. In particular, we suggest targeting a range of staking ratios. However, given the open questions, and in particular the lack of a validator fee mechanism and/or in-protocol MEV capture mechanism, moving to a targeting policy will take time. In the meantime we should update the issuance policy, a stepping stone towards targeting. We make a case for a proposal to update the issuance policy in the upcoming network upgrade Electra here.\n\nFootnotes\n[1] on aggregate the network operates at ~97% effectiveness\n[2] Read more about why issuance yield and MEV yield together form the demand curve in section 2.1 here.\n[3] We want to reiterate that issuance yield and MEV yield together form the demand curve. Further, we make the simplifying assumption that MEV remains constant over time. While historically roughly true, this could of course change.\n[4] The performance across validators varies, both in terms of earning issuance rewards (consensus duties) and MEV rewards. However, this variability is relatively small and its discussion beyond the scope of this post.\n[5] Read this discussion for an analysis of risks for one such onchain SSP.\n[6] We analyze these yields in isolation, in particular we do not consider the tx fee burn mechanism (EIP 1559). The underlying analysis would remain unchanged nonetheless, as all yield curves would be shifted up- or downwards by some constant amount, independent of the staking level. We simply wish to reason about an ETH holder’s decision to stake or not to stake and for that only the difference in yields is relevant.\n[7] The asset ETH is more trustless than staked ETH for the slashing risk alone and then of course there is a spectrum of trust required across different SSPs.\n\n Making Ether A Better Money\n\n On block-space distribution mechanisms\n\n Reward curve with tempered issuance: EIP research post\n\n Orbit SSF: solo-staking-friendly validator set management for SSF\n\n FAQ: Ethereum issuance reduction\n\n 6\n\n 4\n\n 2\n\n 2\n\n 2\n\n read \n\n 32\n min\n\n post by PhABC on Feb 22, 2024\n\n PhABC\n\n Interesting proposal, thanks for the indepth post.\nYou argue that higher staking ratio is more favorable to LSTs, however I think you can say the same about low yields too. I worry that solo stakers will be the first to unstake if yields go to 0, since solo staking has significantly more costs. While we may very well be heading to 100% staking ratio due to LSTs, it seems like this proposal would accelerate the death of solo stakers. It is also possible that solo staking becomes more accessible over time, so there is a good argument to keep solo stakers “viable” for a longer period of time.\n\n post by fradamt on Feb 22, 2024\n\n fradamt\n\n Solo staking costs are mostly upfront, and current solo stakers have already paid them. It seems to me that one could reasonably expect many of them to stick around.\nOn the other end, can we really expect there to be many remaining “future solo stakers”, which haven’t staked yet but might stake at some point with no issuance reduction but not if the issuance is reduced? What do you think about this argument?\n\n post by alonmuroch on Feb 22, 2024\n\n alonmuroch\n\n Feels like the jump from “this level is ok” to this level hurts ethereum and solo stakers to be not well explained.\nAlso, a world in which we have multi “winning” LSTs is definitely possible … we are seeing it now with some emerging LSTs/ LRTs and EigenLayer native restaking.\n\n post by nixorokish on Feb 22, 2024\n\n nixorokish\n\n fradamt\n\n Solo stakers, maybe not. Home stakers, yes I do think so. For some color, EthStaker is running a DVT home staker program right now and we received a lot of applications from technically-inclined people working in the industry who just wanted to be walked through the process. The perception of difficulty around home staking seems to be much more than the actual difficulty.\nAnd though the costs are mostly upfront, (for solo stakers) it’s still a lot of capital locked into a place where the entire point is generating yield. So if the issuance goes near zero or negative and they choose to move the capital elsewhere, they’ll likely shut down the machine. If it ever becomes profitable again, it requires doing all the same research, determining if they need upgraded hardware, restarting a process that they likely only did once and so it’s not much easier the second time around. I definitely could see a sudden shift downward permanently depleting the percentage of solo stakers on the network.\n\n post by PhABC on Feb 22, 2024\n\n PhABC\n\n Indeed. When I referred to cost I was not even thinking of hardware required or rental, but about the overhead of ensuring 24/7 uptime to avoid penalties. Most people aren’t devops engineers. At 5% yield you can afford a few mistakes, but not at 0.5%.\n\n post by theSamPadilla on Feb 22, 2024\n\n theSamPadilla\n\n Very thoughtful post. Thanks for that.\nThis, however, strikes me as incentivizing the exact opposite of what this is trying to achieve. Asymptotically reducing staking incentives after a given staking ratio is likely to hurt solo stakers before it hurst LST stakers.\nSet aside infra, capital requirements, and knowledge needed to run a solo validator. I think this boils down to (lack of) liquidity. The sacrifice solo stakers make when validating is lockng up their ETH in contract. LSTs don’t make this sacrifice, they still had their LST that they can use on DeFi, borrow against, lend, or immediately exit at any point in time. In a future where the value of holding your ETH excels the rewards, I don’t necessarily see it hurting LSTs, if you assume the 1:1 parity of :ETH will hold.\nIf anything, this would deincentivize existing solo stakers from continuing to stake. And the downsize in staking ratio will likely come from solo stakers. The incentive for multiple LST stakers to collectively withdraw their ETH does not seem obvious to me. They would not hurt, they are liquid.\n\n post by benaadams on Feb 22, 2024\n\n benaadams\n\n Won’t this push people away from accutally staking and towards LSTs so they can then restake to make up the missing yield?\n\n post by 0xemperor on Feb 22, 2024\n\n 0xemperor\n\n Thanks for the great post.\nMaybe this is from a place of naivete, but if the underlying worry is a single tbtf (too big to fail) LST, then a native staking approach might be a higher priority to explore right? The issuance ultimately is a value that reflects the networks’ willingness to pay for its own security, which coupled with the burn has actually resulted in a negative issuance since the merge overall. Is there not a risk of overtuning this, and underpaying?\nAlso, in a second-order effect, restaking should be considered when thinking of staking economics. This is the stake that secures ethereum that also secures an AVS, in essence, you could say this stake is “less secure” for the base layer. One, if we target a stake percentage, and most of it gets restaked isn’t that dangerous to the base layer? Two, if the issuance is reduced, isn’t it more likely that the targeted stake all get restaked so people retain the same staking return? In a world where we overload the security of the network with additional terms, is it really valid to say we are oversecuring the network? Today almost ~10% of all staked eth is already restaked in eigenlayer.\n\n post by MicahZoltu on Feb 23, 2024\n\n MicahZoltu\n\nWhat is the current time required to withdraw staked ETH (given current withdraw queues and whatnot)? Knowing this would help analyze the time-value-of-money cost to low-liquidity stakers.\n\n post by MicahZoltu on Feb 23, 2024\n\n MicahZoltu\n\nRestaked ETH does not secure Ethereum, generally speaking.\nFor any given amount of stake to be actually securing Ethereum, the actor that is taking on the capital risk of staking failure/chain split MUST be the same actor that is making decisions about what algorithm (client) to run. As soon as you either outsource algorithm choice to someone else or you sell the risk to someone else the game theory for staking falls apart and your “stake” needs to be treated as attacker controlled stake for mechanism design calculations.\n\nThe above game theory issue is the reason why solo staking is so important. There is no such thing as “too big to fail”. We can wipe out 99% of stake and everything will be fine as long as the wiped out stake is of people who chose the wrong algorithm (e.g., chose a super-majority client, or a censoring client). There will be a long period (weeks) of no finality during recovery, but the system is designed to self heal from nearly all staked ETH defecting.\n\n Blue shell strategy - discouraging the most concentrated actor as an optimal path\n\n post by barnabe on Feb 23, 2024\n\n barnabe\n\nI disagree here, it is much more nuanced and 10% ETH being re-staked does not mean Ethereum is 10% less secure. You may have principal-agent relationships (in fact you will have such relationships) between operators and delegators, and some of the capital at stake may also be burdened with other conditions, all of this is important to consider the security of Ethereum, not only the worst-case pessimistic view.\n\nSomething that could happen is a large EigenLayer slashing event, in which case the first-order consequence is a reduction of the “dollar-amount” security of Ethereum (as long as EigenLayer slashings are properly surfaced to the protocol, which is the point of EIP-7002 for instance). Since lots of validators are exited, the consensus-offered yield will decrease, inciting more validators to join the staking set and recovering the equilibrium staking ratio.\nA bit of weirdness may happen during the transition, but is in my opinion mitigated by the following. Let’s say an adversary wants to benefit from the temporary lower amount of stake after a large EigenLayer slashing event. There can be two cases. If the adversary is the one to trigger the large slashing event, then its own stake will be penalised and exited from Ethereum, largely preventing them from pursuing an attack on Ethereum (e.g., a safety fault). If the adversary is not the one, then it cannot really predict in advance that a large slashing event will happen, it needs to command a large enough amount of (non-EigenLayer-encumbered) stake to launch the attack as soon as the slashing event happens. At the end of the day, the bounds provided to us by the theory of consensus are binding: If we have an adversary with 1/3+ of the total active stake, a safety fault of FFG is possible in theory.\n\n post by MicahZoltu on Feb 23, 2024\n\n MicahZoltu\n\nOne can certainly try to model the system with cow shaped cows rather than spherical cows, but things get really hard and really complicated really fast. In general, I think when designing systems we should focus on designing a system that is resilient to the worst case scenario with rational actors rather than hoping that we get all of the numbers right for the fuzzy and hard to calculate things.\nIf I am accepting delegated stake and operating a node, and in return I earn say 1 ETH over 10 years for doing so, if an attacker offers me 1 ETH today in exchange for running their software instead of canonical software, the rational decision (with spherical cows) is to take it. Of course, there are fuzzy things like threats of violence (legal risks) and reputational damage that I perhaps should think about, but we have no way of measuring those things accurately. How much do the operators of some random delegate value their reputation? What if their reputation is already in the gutter for unrelated reasons? What if they operate anonymously? What if they live in a country where bribing law enforcement is cheap and easy?\nEven if you can accurately estimate (or at least put some bounds on) things like legal/reputational risks and reasonably convert those into ETH denominated numbers, adding complexity to the system can cause a complexity explosion that ends up with subtle bugs in the mechanism design. Take Bitcoin for example, where the economic incentive system is stupidly simple. Yet it wasn’t until sometime after its launch that people realized selfish mining attacks were profitable in a transaction-fee-only future. This is a very subtle attack that was discovered years later despite the system being trivial to analyze. The situation is far worse when your system is not trivial to analyze, which is the case when we start treating restaked ETH as anything other than “attacker ETH”.\n\n post by barnabe on Feb 23, 2024\n\n barnabe\n\nNote that these proposals are not actually hoping to “get all of the numbers right”, they are quite agnostic to the ratio between “true operator stake” and “delegated stake” or “re-staked stake”, they simply reason out about the aggregate size of the staking set. Scaling the staking set size by 2x may mean that you get 2x the dollar amount of “true operator stake”, but also may not (e.g., larger staking set => more LST network effects => more incentives to delegate to LSPs). Either ways, there are indeed risks of misalignments between principals and agents, but these risks have more to do with staking UX (by which I mean broadly the set of mechanisms that are in place in- and out-of-protocol between stakers and the protocol) than with the current discussion. To be clear, these mechanisms are important and they help us improve the quality of our staking set, which is a necessary condition to me (see recent post), but not sufficient to achieve sustainable staking conditions.\n\nThis is besides the point but selfish mining attacks are also profitable in a block-rewards-driven regime, though yes when you are in a transaction-fee-driven regime you need less hashpower to launch them with +EV. More generally, the proposals made for Electra or this curve with stronger targeting are not more opinionated to me than the current reward curve that we have, they just express different opinions, which appear to me to be broadly more in line with the goals of Ethereum. So it’s not really a problem of adding complexity to the system vs status quo, but deciding what best suits the needs of our network.\n\n post by Draco on Feb 23, 2024\n\n Draco\n\n The article:\n\ndoes a great job at highlighting the advantages in terms of cost, convenience, and liquidity of SSPs vs solo stakers\ndoes not account for airdrop/points farming from protocols such as EigenLayer. Swell, Puffer, etc. which represents additional yield pressure to drive SSP adoption\ncorrectly suggests that as overall staking ratio grows, solo stakers will be disadvantaged even more, because of SSP’s structural advantages\nproposes a solution that tinkers with overall stake ratio rather than trying to address the problematic structural advantages of SSPs\n\nThe dominance of SSPs (and in turn, the staking ratio issue) is a result of average ETH holders making rational economic decisions. The threat posed by SSP dominance is not a new topic and yet we have make little progress solving it. And I’d argue the reason we found ourselves in this situation because we have not been willing to address the structural advantages of SSPs over solo stakers\nIn the end, it’s an incentive problem. And it is best (can only be) fixed with incentives\nThe real question here is: Are we willing to discriminate against a SSP validator? More specifically:\n\nIs a solo validator the same as a SSP validator? (I’d argue no. at this point an additional SSP validator is a net negative)\nIf a solo validator and a SSP validator are different, is it wrong to discriminate one against the other? Does it violate principle of credible neutrality?\nIf it does violate credible neutrality to a certain degree, is it acceptable?\n\nI’d love to see what the community think re: those questions, the pros and cons\nBut now assuming we are willing to entertain the idea of validator discrimination, here’s a few unsophisticated thoughts on how we might fix the imbalance in structural incentives\nFirst, thanks to community effort, we already have some ways to distinguish solo stakers from a SSP. Of course, the list is imperfect at the moment, but I’m sure we will get there over time. (also, as a zk-illerate, is there a way we can allow solo stakers to attest to their solo staking status while keeping privacy?)\nProposal #1: Yield over Convenience with ePBS + MEV Redirect, a protocol-based approach\n\nInstead of the proposed MEV burn, simply spread the MEVs evenly among solo validators only\nIf the result of this comes to a 2+% higher yield to solo stakers over SSPs, I’m sure many of those who own more than 32 ETH will be motivated enough to unstake their LST and learn to spin up solo nodes\n\nProposal #2: Solo Staking Loyalty Points (SSLP) farming, a community-based approach\n\nsolo stakers accrue loyalty points\nPoints should measure how long a solo validator has been active and attestation effectiveness\nPoints accrued on a monthly basis and non-transferable\nPoints can be redeem for solo staking achievement NFT/SBT/POAP\nRetro-airdrop for SSLP or staking achievement\nWe can try and persuade projects to pre-commits to an allocation to solo stakers. For example, they can make statement like “We don’t have a token, we might never have a token, but if we ever do, there will have an allocation to solo stakers and the amount will be based on SSLP”\n\n post by ComfyGummy on Feb 24, 2024\n\n ComfyGummy\n\n Hi, fellow home staker here.\nThanks for the proposal. I appreciate the thoughtful analysis of the cost structures of home staking and I agree with all of them. However, I do not understand why stake ratio targeting solves them. It seems to me that no matter how you slice it, implementing targeting means that staking yield, both nominal and real, will go down compared to today’s levels.\nThis means the first stakers to become priced out of staking will be the home stakers, for the reasons you’ve already enumerated: they don’t have the economies of scale that large staking pool operators do, they don’t benefit from the value of having their stake liquid, they have higher reward variability, and so on.\nI would add to this list: Home stakers will likely not be able to earn as high a yield as SSPs will due to restaking opportunities that require serious hardware.\n\nThere is also another dynamic that this post doesn't mention: LST liquidity wars *between each other* in a stake ratio targeting environment.\nSo far, most new staking providers have been able to gain market share because they can attract new ETH to be staked. In a world of stake ratio targeting, especially one where the target is close to 1/4 which is already what the current ratio is, the LST competition becomes zero-sum. This accelerates the winner-takes-most dynamic the post already mentions, and it cements the position of existing LST operators as it makes entering the LST market increasingly difficult. You might argue that we are already effectively heading there anyway but that it’s just a matter of it happening when we reach 100% of stake vs whatever the targeted stake ratio is, but the argument remains that the world where the LST market is allowed to grow in a non-zero-sum way for a few more years vs the world where the only new ETH coming into LSTs has to come from existing stake are two different worlds. It may well be that giving more breathing room to the LST market brings a sufficient number of new entrants to ensure the a sufficient plurality of SSPs and delay winner-takes-most effects. But of course, all of this is speculation.\n\nAt the end of the day, home staking is already not an economically rational choice. LSTs are already more competitive, and the difference seems like it will only grow over time as per the above arguments. This is why I’ve proposed that we should make staking operators legible to the protocol so that we can actually reverse this effect.\n\nSee this proposal to do just that.\n\nIt currently takes nearly no time; only about 37% of the beacon chain’s exit capacity was used in the last 30 days. As the OP notes, staking has been mostly up only. However, as a home staker, this is not really what makes my staked ETH illiquid. What actually makes it illiquid in practice is:\n\nExiting the validator is an extremely manual process which I have not researched and, having a full-time job, it would likely be a weekend project to figure out how to do this safely. It requires re-learning a bunch of things I have likely forgotten around how my validator operates (something which I set up once and only need to worry about occasionally), as well as needing to research how to set up another validator later if I want to stake it again.\nI cannot use my home-staked ETH for anything other than ETH staking. Contrast this with LSTs, which can be used in DeFi to get a loan against them, or can be used to participate in vampire attacks in the SSP wars, etc. as noted above by @theSamPadilla. Essentially, LSTs have already attained a significant amount of money-ness. In the future, my home-staked ETH will probably also be forgoing more yield opportunities from restaked AVSs which be run on a residential connection. That’s OK with me; my goal with home staking is to secure Ethereum and ensures it keeps running first and foremost, and I would be home-staking even with negative yields. But I think the pool of home stakers for which this is sufficient motivation is vanishingly small as a fraction of staked ETH.\n\n post by MicahZoltu on Feb 24, 2024\n\n MicahZoltu\n\nAssuming your withdraw address is already set, exiting a validator is just running a single command with your validator client: https://launchpad.ethereum.org/en/withdrawals/#how-to-exit I would estimate 5 minutes to read the docs for your validator client and run the command, maybe 10 minutes if you want to be thorough. If you don’t have a withdraw address set, then you’ll need to do that first but it is a similarly easy process IIUC, and new stakers will not have to do this as it is set during staking setup process now.\n\nIf your goal is to secure Ethereum, then you should continue to solo stake and not participate in all of the crazy DeFi lego stuff with your stake as that stuff generally weakens Ethereum’s security. Ethereum would be more secure if those people didn’t stake at all. The problem is, we don’t have a way of stopping them from harming the network, so they continue to exist and do what they do and we hope that enough people don’t do those things.\n\n post by danw.eth on Mar 2, 2024\n\n danw.eth\n\n Hi,\nThis is an interesting problem, thank you for the detailed writeup and acknowledging solo stakers might suffer more from targeting.\nI’m a solo home staker, with several validators and rocketpool minipools (and intention for future DVT participation).\nThere’s just a few assumptions/comments I’d like to challenge:\n\nI think it’s a misconception that it’s not viable to hold ETH without a yield. Bitcoin is held without a mining yield, and the recent ETF flows have proven that people don’t need a yield to simply hold an asset. In addition, the issuance/inflation is higher for Bitcoin than it is for Ethereum after EIP 1559.\nEven so I acknowledge humans will chase small amounts of yield wherever it is, as seen through 2021-2022 and all the problems it caused.\n\nThe initial cost of staking hardware really is not expensive compared to the ongoing monetary and non-monetary costs. In addition since it’s a sunk cost it wouldn’t really contribute to the decision about whether to keep operating based on the issuance - that would be more about the ongoing viability of staking and ones belief in Ethereum as a viable long term investment. The ongoing long term costs of staking I have for example are:\n\nExtra internet connectivity, a 2nd internet connection, higher speeds, higher data. Particularly required for multiple validators and/or splitting into DVT clusters or minipools like Rocketpool.\nTime cost for updates every 2 weeks, fixing problems with updates (e.g. today the MevBoost update caused timeouts), fixing outages (e.g. Nethermind bug).\nCapital requirement of holding all the ETH in the contract, while not technically an accounting cost it’s a major decision factor on whether to continue staking. Sure it’s easy to withdraw, but by deciding not to withdraw it’s a capital allocation that for some is an extremely large and non-diversified risk.\nElectricity, is minor in my opinion.\nUpgrades due to changes like EIP 4844\n\nYou could say these are more like ongoing commitments rather than just costs, but I’m just highlighting this because these are the factors that play into the constant decision to stay as a home staker. Not once do I think about my upfront cost paid 2+ years ago.\n\nI agree and I think it’s useful to conceptually split the LST considerations into the two participants:\n\nThe LST node operator, whose costs are rather fixed and will earn a percentage of what depositors earn.\nThe person who swaps their ETH for an LST, or deposits it into an LST contract in exchange for an LST yield bearing token\n\nParticipant #1 would likely take steps to reduce costs and increase risk if there was less yield, e.g. for instead of running 20 nodes they may cut down to 3 nodes and increase the number of validators per node. It’s an extremely efficient business, to run many validators without much of your own capital deposited. Unfortunately I don’t see this proposal as targeting these participants in a stronger manner than it would target solo stakers, because due to economies of scale with potentially thousands of validators they would still be ahead of solo stakers even if only taking 5% of the earnings (which they can choose to vary if yield changes).\nParticipant #2 really has zero cost, and can deposit every ETH they own since they only pay for the LST operator out of the yield they earn. Even if yield was 0.1% and they paid 0.01% commission then economically they still don’t feel the cost like a solo staker would. In reality they would have to consider smart contract and slashing risk, and the usefulness of their LST receipt token in DEFI (even though most people ignore this and throw money around like crazy).\nBoth of these participants I see being much more resilient to the potential changes than the home/solo staker.\n\nDilution prevention is something that is great for all holders of Ethereum. However when observing participants of the Ethstaker reddit and other social media comments, the dilution prevention of other changes were not appreciated. EIP 1559 burning of gas to make Ethereum deflationary and benefit all ETH holders, was also seen as a redistribution from stakers to ETH holders. I fear that dilution preventio","tokens":15000,"squid":"spider-04","role":"Research Spider","at":1791346709093,"hash":"bba240787b3c5c99e394c33b26228468263b3027"}
{"url":"https://docs.jup.ag/","domain":"docs.jup.ag","title":"Jupiter User Docs - Jupiter Documentation","text":"User DocumentationAll the Jupiter Products explainedBrowse documentation for every Jupiter productSupport HubAll Jupiter resources, links and support tickets in one placeAcademyBeginner guides, step-by-step tutorials and use casesQuick accessGachaOpen digital packs and pull real graded Pokemon and One Piece cards.OfferbookAccess fixed-term USDC liquidity peer-to-peer using any Solana token as collateral.SpendSpend your crypto in the real world with the Jupiter card.TradeExchange, leverage and predict on JupiterSpot NewJupiter’s spot trading interface — best-price swaps across all Solana DEXs, plus charts, limit & recurring orders, token discovery and portfolio tracking.Stocks NewTokenized stocks on Solana — compare issuers, check the underlying price and trade 24/5 on Jupiter Spot.PerpsTrade perpetual futures with up to 250x leverage on SOL, ETH, BTC and more.PredictPrediction markets — bet on real-world events and earn from your knowledge.GachaOpen digital packs and pull real graded Pokemon and One Piece cards.EarnGrow your assets with yield and rewardsLendLend your assets and earn competitive yield through Jupiter’s lending markets.OfferbookAccess fixed-term USDC liquidity peer-to-peer, using any Solana token as collateral.JLPProvide liquidity to the pool that powers Jupiter Perps and earn a share of all trading fees.Stake SOLStake your SOL and earn rewards while securing the Solana network.JupUSDJupiter’s stablecoin backed by BUIDL, designed to access onchain dollar liquidity.Rewards HubTrack, manage and claim all your Jupiter rewards from one dashboard.ManageYour wallet, portfolio and toolsPortfolioAsset tracking dashboardJupiter WalletBrowser extension wallet for SolanaLaunchCreate, launch and manage tokensStudioToken creation toolsVRFDVerified token launchesLockToken vesting & lockingGlobalThe mobile app and real-world paymentsJupiter MobileMobile appSpendVisa card, QR Pay, remittance & cashbackOnrampGet crypto into your wallet from anywhereSendInstant token transfersDepositDeposit crypto, bridge & swap, buy with a cardMoreGovernance and the JUP tokenPokerBack pro players and earn a share of winningsDAOStaking, voting & governanceJUP TokenTokenomics & transparencySecurityIndependent audits of every Jupiter program","tokens":565,"squid":"spider-02","role":"Liquidity Spider","at":1791346728675,"hash":"53e8bd549a37bd81a3ce276ce8fff10383d2630e"}
{"url":"https://ethresear.ch/t/endgame-staking-economics-a-case-for-targeting/18751/38","domain":"ethresear.ch","title":"Endgame Staking Economics: A Case for Targeting - Proof-of-Stake / Economics - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 6\n\n 4\n\n 2\n\n 2\n\n 2\n\n read \n\n 32\n min\n\n Feb 2024\n\n 37 / 37\n\n Apr 2025\n\n Apr 2025\n\n Load more posts above\n\n post by danw.eth on Mar 2, 2024\n\n danw.eth\n\n Hi,\nThis is an interesting problem, thank you for the detailed writeup and acknowledging solo stakers might suffer more from targeting.\nI’m a solo home staker, with several validators and rocketpool minipools (and intention for future DVT participation).\nThere’s just a few assumptions/comments I’d like to challenge:\n\nI think it’s a misconception that it’s not viable to hold ETH without a yield. Bitcoin is held without a mining yield, and the recent ETF flows have proven that people don’t need a yield to simply hold an asset. In addition, the issuance/inflation is higher for Bitcoin than it is for Ethereum after EIP 1559.\nEven so I acknowledge humans will chase small amounts of yield wherever it is, as seen through 2021-2022 and all the problems it caused.\n\nThe initial cost of staking hardware really is not expensive compared to the ongoing monetary and non-monetary costs. In addition since it’s a sunk cost it wouldn’t really contribute to the decision about whether to keep operating based on the issuance - that would be more about the ongoing viability of staking and ones belief in Ethereum as a viable long term investment. The ongoing long term costs of staking I have for example are:\n\nExtra internet connectivity, a 2nd internet connection, higher speeds, higher data. Particularly required for multiple validators and/or splitting into DVT clusters or minipools like Rocketpool.\nTime cost for updates every 2 weeks, fixing problems with updates (e.g. today the MevBoost update caused timeouts), fixing outages (e.g. Nethermind bug).\nCapital requirement of holding all the ETH in the contract, while not technically an accounting cost it’s a major decision factor on whether to continue staking. Sure it’s easy to withdraw, but by deciding not to withdraw it’s a capital allocation that for some is an extremely large and non-diversified risk.\nElectricity, is minor in my opinion.\nUpgrades due to changes like EIP 4844\n\nYou could say these are more like ongoing commitments rather than just costs, but I’m just highlighting this because these are the factors that play into the constant decision to stay as a home staker. Not once do I think about my upfront cost paid 2+ years ago.\n\nI agree and I think it’s useful to conceptually split the LST considerations into the two participants:\n\nThe LST node operator, whose costs are rather fixed and will earn a percentage of what depositors earn.\nThe person who swaps their ETH for an LST, or deposits it into an LST contract in exchange for an LST yield bearing token\n\nParticipant #1 would likely take steps to reduce costs and increase risk if there was less yield, e.g. for instead of running 20 nodes they may cut down to 3 nodes and increase the number of validators per node. It’s an extremely efficient business, to run many validators without much of your own capital deposited. Unfortunately I don’t see this proposal as targeting these participants in a stronger manner than it would target solo stakers, because due to economies of scale with potentially thousands of validators they would still be ahead of solo stakers even if only taking 5% of the earnings (which they can choose to vary if yield changes).\nParticipant #2 really has zero cost, and can deposit every ETH they own since they only pay for the LST operator out of the yield they earn. Even if yield was 0.1% and they paid 0.01% commission then economically they still don’t feel the cost like a solo staker would. In reality they would have to consider smart contract and slashing risk, and the usefulness of their LST receipt token in DEFI (even though most people ignore this and throw money around like crazy).\nBoth of these participants I see being much more resilient to the potential changes than the home/solo staker.\n\nDilution prevention is something that is great for all holders of Ethereum. However when observing participants of the Ethstaker reddit and other social media comments, the dilution prevention of other changes were not appreciated. EIP 1559 burning of gas to make Ethereum deflationary and benefit all ETH holders, was also seen as a redistribution from stakers to ETH holders. I fear that dilution prevention is not seen as an incentive to be a solo/home staker, as staking is not required to receive that benefit. Personally I can understand the logic, but the public has a history of misunderstanding the many Ethereum proposals and upgrades.\nI agree with the problem that has been detailed, but I think the solution needs some more input.\nThe primary difference I see between LST operators and Home/Solo stakers is that an LST operator runs a large number of validators from a single beacon chain client (and a single node), whereas most home stakers have just 1 validator or very few.\nIf there was a way to have variable issuance based on how many validators are attached to an instance of a beacon chain client it could reduce the economy of scale benefits achieved by LST operators, encourage more unique nodes and incentivize the decentralization we want to encourage.\nI suspect however there would be ways to work around such solutions, and some sort arms race between the spec and LST configurations. Unfortunately I don’t have a solution, I just believe there may be other solutions yet to explore.\n\n post by Jstar101 on Mar 3, 2024\n\n Jstar101\n\n I agree with the decision to re-evaluate staking economics given we now have staking data spanning multiple years. One of the main unknowns at this point in time is how restaking will impact the ecosystem, however I believe that we should design the optimal staking economics for Ethereum, irrelevant of restaking. Any deviations away from this ‘optimal’ due to restaking should be seen as restaking impacting the security of the network and should be avoided.\nWhilst I agree that targeting a fixed staked supply solves issues associated with a super majority of staked ETH, it does not solve the winner takes all dynamic. Applying a yield curve that limits stake to say 30% of total ETH supply will lock in Lido as the winner of ETH staking. The only way in which smaller/newer staking protocols can realistically compete is to encourage capital away from Lido using incentives, something that Lido can easily combat with its own purchasing power. This entire ecosystem is already a Moloch trap where staking protocols are required to spend significant sums to attract capital and capping the total ETH stake will likely increase this problem. The worst part, however, is that real competition (outside of incentives) will likely be squashed, reducing innovation and technological advances that would otherwise lead to a safer staking ecosystem for both stakers and the network as a whole.\nWe know that yield is always going to be the primary driver of where/how stakers stake. The only way I can see us safely aligning yield with ecosystem security is introducing staking economics that fundamentally rewards stakers that take steps to improve network security, such as using minority clients, home staking, etc… Admittedly, this would get complicated very quickly and introduce technical challenges (i.e. how can you prove someone is a home staker or truly using X client), but I do not see how we can meaningfully take steps to improve the current dynamic with a simple shift in the yield curve.\nOne of the main arguments against solo staking at the moment is the lack of economic incentives to do so, mostly due to them missing access the benefits available to liquid stakers: A) being able to use staked capital in DeFi/CeFi, and B) economies of scale that large staking pools receive due to MEV. It is important to highlight here that this doesn’t have to be the case. Whilst it is not yet widely known, solo stakers are able to liquid stake against their own node via StakeWise V3. StakeWise DAO provides the liquidity and integrations for its LST, osETH, which solo stakers are permissionlessly allowed to utilise in DeFi. This opens up the door for solo stakers to borrow against their own nodes, leverage stake, and even restake by depositing osETH on Eigenlayer. I am of the opinion that native restaking will not be available to home stakers due to the expected competition across operators to be in the active set for AVSs (in the very least the most lucrative AVSs will not be available to solo stakers, further increasing the economic disparity). The ability to restake an LST minted from a home node goes some way to solving this. Alongside an LST, StakeWise V3 enables stakers to access a smoothing pool with zero costs and goes some way to solve economies of scale problem too.\nWhen evaluating the economics between liquid staking and solo/home staking, it is vital to consider the ability for solo stakers to liquid stake in this manner as it fundamentally changes the dynamics. It is also vital to increase the awareness for solo/home stakers to liquid stake in this manner to further encourage the participation of home stakers.\n\n post by htimsk on Mar 6, 2024\n\n htimsk\n\n Thank you for the in depth post. One question that I have is how can the “Real ETH Yield” be negative? With the inclusion of the EIP-1556 and the burning of the base fee the amount of ETH has decreased since the merge. As modeled by https://ultrasound.money/. Hence a holder of ETH who does not stake is not being diluted. I don’t think the model can ignore the effects of 1556 and simply assume that unstaked ETH is being diluted by the Beacon chain issuance.\n\n post by barnabe on Mar 7, 2024\n\n barnabe\n\nI believe this footnote addresses your question, indeed the burn may shift up the real yield, but that shift is constant across the whole real curves, so does not change the relative quantities and thus the arguments of the post.\n\n post by XofEE on Mar 7, 2024\n\n XofEE\n\n I’d like to share my perspective as an average Home staker to provide a more down-to-earth example :\nIf issuance approaches zero or goes negative, I’ll continue staking out of conviction and also because I don’t want to make the “effort” to withdraw my validator. Most home stakers, like me, want to avoid unnecessary entries or exits of their validators. This benefits the network.\nHowever, if negative issuance persists, I’ll be forced to withdraw because it’s not sustainable for me in the long term (I will no longer have ETH at the end so it’s better to exit beforehand)…\nThis creates a re-entry barrier, necessitating the redeposit and setup of my validator again, an effort I won’t undertake if the low APR remains. I’m not a machine; I won’t cyclically enter and exit, as it demands effort and entails risks. I’ve sketched my stance on a graph to illustrate the gap between the my APR thresholds for exiting and re-entering. (The figures are quick approximations and vary among home stakers.)\nAPR400×363 28.6 KB\nThis simple graph demonstrates that if the APR falls significantly low, I will not consider re-entering if it persists in that range, effectively establishing a ‘no-return buffer’.\nIt suggests that pushing issuance toward zero or negative risks driving away home stakers not out of conviction but due to re-entry barriers.\nHowever, I believe there’s an equilibrium APR before reaching 100% stake. Solutions like MEV burn and reducing issuance seem simpler and quicker to achieve this equilibrium at a lower ETH staking ratio.\nI don’t think it’s necessary to implement a complex targeting system, as I don’t believe (or hope) we’ll reach 100% of ETH staked. However, if implemented, I think it could cause side effects for home stakers.\n\n 28 days later\n\n post by TimDaub on Apr 5, 2024\n\n TimDaub\n\n First of all, great job. I read most of this proposal very carefully, and I agree with most of the points brought up in it. I also took to social media as to support the proposal and to address some of the popular criticisms:\n\nSome do simply not acknowledge the value of ETH as money: x.com, or they question the seriousness of the proposal (x.com), which I find incomprehensible.\nSome of the criticism seems to be without substance: x.com or it misses the key points of the proposal, namely that LSTs challenge ETH’s money-ness: x.com\nThere is a class of criticism that entirely misses the point as it assumes the SEC would monitor the internet to draw conclusions on whether ETH is a security based on what is written in this forum: x.com Even if this was the case, why would it matter when engineering the protocol and addressing its challenges outlined above? The SEC is not the primary customer we’re working towards to build the protocol.\nEveryone who holds ETH should be more aware of how incredibly valuable it is for an asset to have a monetary premium. Educate yourselves here, for example https://www.aier.org/article/on-monetary-premia/. Everyone who has to pull 17 magic tricks a quarter to preserve their wealth’s value over time is intuitively aware of how valuable it is to JUST hold a true store of value. That should be the vision for being an ETH holder. Not to imitate the existing financial system where I have to cast 23 different spells on my fiat money such that it doesn’t insta depreciate, but where I can buy ETH and know that the network’s productivity (that goes far beyond just staking) takes care of preserving the value.\n\nThen, this aside, I picked two quotes from the article:\n\nTo the authors, I would emphasize immensely this part of the proposal, which I think is counterintuitive for many ETH and LST holders. If I understood correctly, then the punch line here is, in reality, that with more staked ETH receiving yield, ETH inflates more in absolute terms, which means holding ETH becomes even less economical.\nI think printing a curve showing the number of staked ETH vs. how high absolute inflation is could help to explain this or further understanding. E.g., I’d be interested in how much ETH is being printed when, e.g., 60M ETH is staked at 2% vs., e.g., 30M ETH at 3%.\n\nI actually think a part of the requirement here should also be that “holding raw ETH is simply like holding money,” as to say that it should be straightforward to hold money and not require me to do 17 tricks to hold the actual money and not a derivative that is actually inflated away by someone who more sophisticated than me.\nThis, in turn, also means that we should see staking rewards merely as the counter good for providing a service and paying expenses for that service. And in that line of arguing, I’d like to say: Motivationally, I’m pretty sure that most validators already hold ETH for its money-ness or as an investment. ETH has also been a great investment, especially in a fiat currency environment where all value globally is rapidly inflated. So, we can hardly argue that we should pay ETH validators for the risk of holding >= 32 ETH. So then we actually pay them for an active internet connection, a computer, the amount of time they spend on maintenance, and the risk of participating in validating. And what is that cost? I doubt that it is, in reality, so high that barely anyone does it economically. I personally know of people whose non-technical family members also got a computer to stake ETH because it was apparently such easy money! WTF\nIf you think about how you have to put your fiat money into an ETF that then spends it on 500 US-based companies and has this incredible black-box complexity, all just to preserve the fiat money’s value over time, then this is the inverse of what we should be aiming for, and sadly, this is the direction we’ve been going towards. So I support this proposal! Make holding ETH economical and preserve its property of being money.\n\n post by jsarcher on Apr 11, 2024\n\n jsarcher\n\n For targeting staking ratios we should use a PID controller.\n\n post by gorondan on Apr 16, 2024\n\n gorondan\n\n GEB controller seems robust enough, is doing a great job in RAI and related forks. It intakes a target and sets the rates accordingly. Plus, it’s very well documented and in-prod tested, with community tweakings.\n\n 17 days later\n\n post by SnapCrackle2383 on May 3, 2024\n\n SnapCrackle2383\n\n I’d like to know what other ideas were discussed and dismissed besides yield issuance. I think the community is focused on yield over new ideas, I think there are many options that are worth exploring as well.\nWhat ideas do you have? I’ll go first to spark some inspiration:\n\nReduce new validators. Further, reduce the limit to 1 new validator per 6.4-minute epoch. This could be done dynamically as the stake increases. If significantly reduced, it would make building a large node operator uneconomical due to the time needed to get validators online and larger staking pools end up with less yield as they share the yield with users ETH that is not yet staked, which gives home stakers a better yield option.\n\nDo nothing. The market settles, and staking deposits settle down.\n\nEnshrine an LST, control the community, and stop bad actors from controlling the protocol. This is a controversial option, given the investment and time that organizations have put into staking pools.\n\nDynamic max deposit amount. Research an acceptable amount of economic security and design around that. Price and volume deposited dynamically managed.\n\nRandomized Yield: Implementing a system where rewards vary randomly between 1% and 6% could discourage professional node operations due to its unpredictability\n\nNon-Yield Staking: Stake accumulation could be tied to gas fee usage instead of providing a yield. This might encourage home stakers but doesn’t incentivize broader participation.\n\nIncrease the gas fee to the deposit contract to prevent the economy from stacking up.\n\nCorrelated attester penalties: This aims to penalize big stakers; it would be interesting to model this. for more info see a post by Vitalik.\n\n post by umbnat92 on May 3, 2024\n\n umbnat92\n\n It’s an interesting topic, however there is something puzzling me and I’m curious of hearing your thoughts.\nIt seems the main concern is around LST. However, by targeting a staking ratio, are you not going to exacerbate the preference for adopting a LST solution? What I mean is that, the way rewards are distributed to validators tend to follow skewed distributions - essentially, larger entities tend to earn more on a percentage basis. This is mainly due to the fact that larger entities are pooling rewards coming for long-tailed distributions. Thus in the end, it would always be more profitable to pool rewards, so joining a LST solution.\nIn other words, how can you be so sure that targeting a staking ratio doesn’t tend to make things worse?\n\n post by Bhaney44 on May 3, 2024\n\n Bhaney44\n\nI think this is a solid observation. But, it is also important to consider that there may be other reasons to operate a node beyond economics, or that new technology may develop to make the model more economical. Generally this happens often, where new technology could improve the cost-efficiency of operations.\n\nThis I really agree with. But, I think you are right, though it may be controversial.\n\nI like this idea a lot. The randomness could discourage professional node operations as you mentioned, which would certainly help decentralized the network. I think this idea is really innovative and could really improve things. Nice one.\nOverall, nice post.\n\n 7 months later\n\n post by ileuthwehfoi on Nov 15, 2024\n\n ileuthwehfoi\n\n Ansgar and Casper’s talks at Devcon were pretty interesting and have inspired me to do some napkin research on this topic. I agree that there is a problem with the incentives, but the solution seems to have some major problems:\n\nThis will affect existing stakers (rugged!)\nChoice of parameters feels random. Because of 1, this feels political.\nStaking yield goes below zero. It seems to me there is an unintentional attack with restaking, where past a certain point yield is negative but it is still profitable for restakers. At that point, non-restakers are forced to either restake or get out, resulting in 100% of staked ETH being restaked.\n\nMy quick and dirty idea introduces two new parameters:\n\nMTS: A targeted maximum total staking percentage (something between 29% (the current total stake according to https://dune.com/hildobby/eth2-staking) and 100%).\nTVS: A targeted maximum validator share (something between 32 ETH-33% of the total stake).\n\nThe idea is that once the total ETH staked reaches MTS, the issuance curve is set such that any entity with at least TVS staked has a marginal reward of 0 when adding another validator.\nFor example, let’s say MTS is 50% and TVS is 0.2%. When the total ETH staked is below 50%, the issuance curve remains the same as it is now, receiving approximately 2578 ETH/year. However, once 60 Million ETH is staked, any validator with 0.2% of the stake or more still will only ever receive 2578 ETH per year no matter how many new validators they spin up.\nI have a spreadsheet of the proposed issuance curve here: Staking Endgame.xlsx - Google Sheets (Hopefully no major mistakes, I know there are some visualization bugs if the parameters are set outside reasonable ranges).\nThis design has the following benefits:\n\nAs long as MTS is set above the amount staked at the time of the fork, there is no disruption to existing stakers.\nYield always remains positive. This is beneficial because I think if yield goes negative at some point, restakers will be able to drive everyone else out until 100% of staked ETH is restaked.\nAs an added bonus, this adds an incentive against a single party having control of too much stake (note that single entity doesn’t refer to something like a staking service, which wouldn’t be affected).\nThe design decisions are more or less neutral. Only MTS and TVS are sort of random, but I think choosing credibly neutral values shouldn’t be too hard. In any case, because of point 1 (and because there should be collusion between large stakers to avoid reaching MTS), these values shouldn’t be that political.\nThe resulting issuance curve puts a theoretical cap on ETH issuance, which is great for the ultrasound money meme.\n\nDownsides:\n\nThe yield curve becomes discontinuous (not sure about the implications of this). If this is really a problem, you could split MTS into MTS1 and MTS2, making marginal staking yield for TVS sized validators zero only after MTS2 is reached by linear interpolation from MTS1 (nice, now you can use both 30% and 50% instead of trying to decide between them for MTS).\nIt’s possible that ETH staked exceeds MTS without any validator reaching TVS. I don’t think this is likely as long as some analysis of the distribution of ETH across addresses is done to choose TVS. In any case even if this occurs there is still the benefit that it increases the decentralization of staked ETH.\nIt’s unclear how restaking yield will interact with this design. Possibly you might want to make the values for MTS or TVS to be more conservative than idealized values.\n\n post by Zarevoks on Nov 15, 2024\n\n Zarevoks\n\nAdjusting the staking reward rate is not a rug… all staking rewards are paid for by the network. Any reduction in issuence is offset by the benefit of reduced dilution.\n\n post by barnabe on Nov 15, 2024\n\n barnabe\n\n ileuthwehfoi\n\n In this scheme, how do you prevent against Sybil attacks? It sounds like I can easily defeat the TVS condition by just spinning up a new entity.\n\n post by ileuthwehfoi on Nov 16, 2024\n\n ileuthwehfoi\n\n TVS is an economic parameter, not something that targets any individual validator. The way it works is that past MTS, issuance actually starts dropping. As a result, the added ETH from any new validator is offset by the reduced yields from their existing validators, resulting in zero marginal yields. Anyone over TVS actually gets negative marginal gains, while anyone below TVS still has positive marginal yields. This is why I think this proposal actually also has benefits to stake decentralization. Another key point is that this economic incentive applies to LST holders as well.\nRe Zarevoks: rugged. That was sarcastic, sorry. I understand the argument on dilution, but I don’t expect everyone to.\n\n post by keyneom on Nov 16, 2024\n\n keyneom\n\n I’ve commented this elsewhere but I think it’s applicable to this post as well. You seem to be a mix of points 2 and 3 below which I argue are not convincing in the linked post. In particular for LST dominance I’ll see if I can post about my thoughts on how we can keep native eth competitive with LSTs soon without messing with issuance.\n\nTo avoid the feeling I think a number of people get that these are just your preferences and somewhat arbitrary I think the need for introducing MVI itself needs to be very explicit and I don’t think a high-level and clear need has been defined. I think I’ve seen 3 high level needs for why we should pursue this articulated (I’ve addressed them in my replies already but just to make things concise):\n\nLarge Validator Set Network Instability (a tech problem that already has some reasonable approaches to potentially solving)\nReducing LST Dominance (I still have no idea why an LST can’t dominate even with more limited issuance)\nAvoid paying too much for security (extremely subjective what too much security is)\n\nIf you can articulate a higher-level need that is really driving a change like this that has a massive impact on every network participant I’d be open to hearing you out. I don’t think I’ve seen it yet. And getting lost in the minutia of which curve specifically to choose with extremely detailed long posts isn’t going to help move the proposal forward imo.\n\n 4 months later\n\n post by Sotfranc on Mar 24, 2025\n\n Sotfranc\n\n Can I suggest that the main problem is the focus on defining a single yield curve for all validators?\nFor any given yield curve, there will be an optimized validator type that has a competitive advantage against others, leading to a concentrated validator set in the endgame. To solve for validator diversity, you actually need to have multiple yield curves with varying tradeoffs such that different validator types can each find a niche position in the ecosystem.\nAs an example, If instead of a single yield curve, you introduce 2 yield curves, one for validators that can exit at will and one for validators that have locked their stake for a given time, you can force diversification of the validator set. there will be a set of validators that will accept a low yield as long as they can exit immediately, and a different validator set will exisit that is willing to lock their stake for extended periods for a more stable or higher yield rate.\nCentralized entities that need to meet withdrawal requirements for their customers might be forced to have access to immediate withdrawal, while solo stakers might be willing to lock up stake in exchange for higher yield.\nThis is similar in concept to government bonds. There is no single bond type offered by the government, but rather a multitude of different bonds (30 yr, 10 yr, inflation protected, etc) which each attract a specific type of investor with a unique risk profile.\nNo single issuance curve will be agreed to by all validators, but introducing a range of curves with different trade offs would likely grab more support as each validator type would find a niche.\n\n post by MicahZoltu on Mar 24, 2025\n\n MicahZoltu\n\nWhat is the benefit to the protocol for having some validators with longer lockup requirements?\n\n 10 days later\n\n post by Sotfranc on Apr 4, 2025\n\n Sotfranc\n\n I would assume a stable validator set with longterm validation gaurantees would be a net benefit to the security of the protocol. Depending on the exact levels you could also save on eth inflation in certain scenarios.\nBut the main benefit from my perspective is more to force diversification of the validator set. I think it would be valuable to diversify the validator set in this way even if long term locked stake had no direct benefit to the protocol.\n\n post by MicahZoltu on Apr 5, 2025\n\n MicahZoltu\n\nWhat leads you to this assumption?\n\nIt is not clear to me why there would be a benefit to the protocol in having a diversity of lockup lengths. Diversity isn’t useful just for diversity’s sake, we often want diversity because it gives us robustness in some cases, but I don’t see how this would increase our robustness.\n\n Powered by Discourse","tokens":7129,"squid":"spider-04","role":"Research Spider","at":1791346735813,"hash":"2bf0adb6dabe34d685ced4cbe7d021c14dde7081"}
{"url":"https://docs.jup.ag/user-docs/earn/offerbook","domain":"docs.jup.ag","title":"Offerbook Overview - Jupiter Documentation","text":"Offerbook is a permissionless, peer-to-peer money market for any onchain assets on Solana, live at offerbook.jup.ag (currently in Beta).\nIt allows users to borrow or lend USDC at fixed rates, for a user-defined period (1 to 30 days), using onchain assets as collateral, without price-based liquidations and without relying on price oracles.\nUSDC (the only asset that can be borrowed or lent on Offerbook) is the liquidity exchanged between borrower and lender. Collateral is the onchain asset locked by the borrower for the duration of the loan, and can be any Solana asset (verified tokens on Jupiter, RWAs such as xStocks, or NFTs from whitelisted collections). See Markets for what each market accepts.\nUnlike classical lending protocols, Offerbook is built around time-based loans. Risk is managed by duration, not by collateral price fluctuations.\nBoth borrowers and lenders can publish offers with their own terms, expressing their intentions openly in the offerbook. Offers are available for 1 to 7 days, set by their creator. Expired offers can be renewed without recreating them.\nAlongside onchain offers, users can post intents: free, off-chain advertisements of the terms they want, matched automatically against live offers. See Intents.\n\n​A Fixed-Term Credit Market\nOfferbook is best understood as a fixed-term credit market.\nEvery loan has a known duration, a known return, and a known outcome at maturity.\nFor lenders, returns are driven by three variables: collateral quality, loan duration, and APY (Annual Percentage Yield, the annualized return for the lender, fixed for the entire loan duration).\nFor borrowers, it means full control over loan terms and no price-based liquidations.\nBorrowers can\nCreate borrow offers with custom terms\nAccept existing lend offers\nUse any supported onchain asset as collateral\nRepay at any time before maturity\nLenders can\nCreate lend offers with custom terms\nAccept existing borrow offers\nAccept offers partially or in full\nEarn fixed yield over a known duration\n\nPartial fill is configurable per offer. The offer creator (borrower or lender) can enable or disable partial fill, and set a Minimum Fill Amount in USD. Partial fill is not available for offers using NFT collateral.\n\n​Navigating Offerbook\nThe header is organized by role: Earn, Borrow, Multiply and Dashboard, with Pro, Statistics and Docs under More. The Create Offer button opens the three creation flows (Borrow, Lend, Post an Intent), and the gear icon opens Settings. Old links to the former Lend, Loop and Portfolio pages redirect to their new names.\nEarn is a menu with two market views, Tokens and Collectibles, where you lend USDC against collateral. The Tokens view opens on Available Now, the borrow offers you can fund today, with Offer to Lend to post your own terms; Set Your Terms lists the terms borrowers have asked for and nobody has filled yet, with the form to post your own. The two markets are described in Markets, and the journey in Lending.\nBorrow starts with your collateral, then the amount and the term, and ranks every lender’s offer for that request. From the same card you can post your own ask, or switch to Leverage to open a leveraged long. See Borrowing.\nMultiply hosts the yield loops on stable yield-bearing assets, while leveraged longs on any collateral live in the Leverage tab of Borrow. Both create Multiply positions — see Multiply.\nDashboard is your account view. Its header shows your wallet, account age and repay rate (“100% repaid · 1 loan”), a Set up profile link, your net position and your open PnL, and six tabs organize the rest: Positions (your open loans and their totals), Offers, Intents, Escrow (the ledger of every movement in and out of your escrow), Analytics and Affiliate (your referral link, see Affiliate & Referrals). A Borrowing / Lending switch, a Status filter and a Columns menu narrow the tables, and you can select several offers or loans to cancel, renew or extend them together. Analytics covers your lifetime PnL (realized and unrealized), your rates compared with the market for the same collateral over 15D, 30D, 90D or ALL, your daily activity, where your yield comes from by collateral, and how your loans end (repaid on time, defaults, fill rate, median time to fill). A banner lets you switch back to the classic Dashboard. Every wallet’s public profile uses the same layout, without the Affiliate tab, and actions such as Cancel or Repay only appear on your own.\nPro, under More, brings the whole order book onto one dense screen: both sides of the market and both intent books, for users who want everything in one place. See Pro. Statistics shows protocol-wide activity (see Statistics). The Chat widget, in the bottom-right corner, hosts public channels and direct messages between users (see Chat).\n\n​Key Terms\nCollateral (Locked asset)The onchain asset locked by the borrower for the duration of the loan. The lender can claim this asset if the loan is not repaid after maturity.Collateral can be any Solana asset (verified tokens on Jupiter, RWAs such as xStocks, NFTs from whitelisted collections).USDC (Borrowed / Lent asset)The liquidity provided by the lender and received by the borrower. On Offerbook, USDC is the only asset that can be borrowed or lent.LTV (Loan-to-Value)The ratio (in %) between the borrowed USDC amount and the collateral value. It represents how much liquidity is taken out compared to the value of the collateral locked.Example: If you lock $1,000 worth of collateral and set the LTV to 70%, you can borrow 700 USDC.Loan durationThe fixed time period during which the collateral is locked and the loan is active. Loan duration is set when creating the offer (by the borrower for a borrow offer, or by the lender for a lend offer) and can range from 1 to 30 days. The interface offers presets depending on the flow (such as 3D, 7D, 30D or 7d, 14d, 30d).The countdown starts when the offer is accepted (the loan begins), not when the offer is published. Once the loan starts, the duration cannot be changed.Offer expirationPublished offers expire after a set period, separate from the loan duration:Offers expire after 1 to 7 days, set by the offer creator (borrower or lender) at creation.Once an offer expires, it can be renewed directly without recreating it from scratch.Offer expiration and loan duration are two separate timers. An offer can be accepted at any point within its expiration window; the loan duration then starts from that moment.IntentA free, off-chain, signed advertisement of the terms a user wants, on either side of the market. An intent locks no funds and cannot be filled directly: Offerbook matches it against live onchain offers and surfaces the matches in the creator’s dashboard. Intents advertise the same loan durations as offers (1 to 30 days). An intent is anchored on the LTV rather than on fixed token amounts, so its terms stay meaningful as prices move. See Intents.APR (Annual Percentage Rate)The annualized cost of borrowing, paid by the borrower. Fixed for the entire loan duration. Displayed when creating a borrow offer and in offer listings.APY (Annual Percentage Yield)The annualized return for the lender. Fixed for the entire loan duration. Displayed when creating a lend offer.Effective APR / APYThe effective rate accounts for platform fees and is automatically displayed in the offer summary.Effective APR (borrower side) combines the offer APR with the 25% upfront fee on interest. Because the fee is paid in addition to the interest, the actual cost of the loan is higher than the headline APR.Example: an offer at 30% APR becomes 37.5% Effective APR (30% × 1.25).Effective APY (lender side) combines the offer APY with the 10% fee deducted at repayment. Because the fee is taken out of the interest received, the actual return is lower than the headline APY.Example: an offer at 5% APY becomes 4.5% Effective APY (5% × 0.9).ExtensionRolling an active loan into a fresh period on the same terms — same rate, same collateral — instead of repaying it. The borrower pays the closing period’s interest, and the new deadline replaces the old one. Extensions must be allowed by the lender and are always triggered manually by the borrower, never automatically. See Loan Extensions.MaturityThe point at which the loan duration ends. At maturity, the borrower should have repaid the loan (principal + interest). If not, the lender can claim the collateral.Collateral transferWhen a loan is not repaid after maturity, the lender can claim the collateral by signing a transaction. This action triggers the collateral transfer: the collateral is sent directly to the lender (not sold on the market). The lender receives the collateral token itself.Unlike price-based liquidations in classical lending protocols, this event can only happen after maturity, never during the loan. A 0.1% fee is deducted from the collateral at transfer (no fee on NFT collateral).The transfer is not automatic. It only happens when the lender claims. The borrower can still repay and recover the collateral at any time, as long as the lender has not claimed it.Partial fill and Minimum Fill AmountThe offer creator (borrower or lender) can enable or disable partial fill:\nPartial fill enabled: the offer can be accepted partially. The creator sets a Minimum Fill Amount in USD (e.g., $10, $25, $100), which is the minimum amount a counterparty can accept per transaction.\nPartial fill disabled: the offer can only be filled in full by a single counterparty.\nWhen an offer is partially filled, fees apply to the filled portion only, and the remaining amount stays available to other counterparties.Partial fill is not available for offers using NFT collateral, since an NFT cannot be partially transferred.Counter offerA proposal to modify the terms of an existing open offer before accepting it. Any user can send a counter offer on any open offer, adjusting one or more of: LTV (Loan-to-Value, the ratio between borrowed USDC and collateral value), the rate (APY), duration, expiration, and the partial-fill rule.The original offer creator can review counter offers received and either accept one (starting the loan at the counter-offer terms) or ignore them. The original offer remains open and visible to other users while counter offers are pending.Counter offers do not lock any funds until accepted. Multiple counter offers can be open against the same original offer at the same time. See Counter Offers for details.Loan statusA loan can have one of four statuses:\nActive: the loan is running, between offer acceptance and maturity.\nRepaid: the borrower has repaid the loan, the collateral has been returned to their wallet.\nExpired: the loan has passed maturity without being repaid. The lender can claim the collateral, and the borrower can still repay until they do.\nDefaulted: the lender has claimed the collateral after maturity. The loan is closed.\nEscrow walletA dedicated wallet, separate from your main Solana wallet, used to hold funds while interacting with Offerbook. Each user has one escrow wallet. All funds transit through the escrow when creating or accepting offers.For lenders: the escrow is visible in the interface. USDC is deposited into it as part of offer creation, and lenders can create multiple offers from the same balance.For borrowers: the escrow is used in the background. Collateral transits through the escrow automatically in a single transaction. When the borrower repays, collateral is returned directly to their wallet.\n\n​How Offerbook Loans Work\nOfferbook loans are time-based, not price-based. This is the core difference with classical lending protocols.\nOnce a loan starts:\n\nCollateral is locked onchain for the full duration of the loan\nLoan terms cannot be changed\nNo margin calls or price-based liquidations can occur before maturity\n\nBorrowers can choose to repay the loan at any time. The full interest for the agreed duration is owed regardless of when the repayment occurs.\nIf the loan is not repaid by maturity, the lender can claim the entire collateral at any time by signing a transaction. The transfer is not automatic, but you cannot rely on any delay. Always plan to repay before the loan expires.\nWith time-based loans, risk management is shared between lenders and borrowers. The collateral value at maturity can be higher or lower (in USD terms) than the amount borrowed.\n\n​Loan Lifecycle\nA loan on Offerbook follows a deterministic lifecycle.\n1Offer createdA borrower or lender publishes an offer in the offerbook with their desired terms (collateral, USDC amount, LTV, APR/APY, loan duration, partial fill settings). Offers are visible for 1 to 7 days, set at creation. Expired offers can be renewed without recreating them.2Offer accepted — Loan startsA counterparty accepts the offer, partially or in full. The loan starts immediately. Collateral is locked onchain via a smart contract (a PDA, or Program Derived Address, which is a program-owned account on Solana with no private key). The loan duration begins at this moment.A calendar reminder can be added at this stage to track the loan’s maturity date. The reminder fires 2 hours before maturity.3Loan activeThe loan runs for its full duration. Collateral cannot be accessed by either party. No price-based events can occur. The borrower can repay at any time.4Loan resolvedAt maturity, the loan resolves in one of two ways:\nRepaid: the borrower repays principal + full interest. Collateral is returned directly to the borrower’s wallet. Loan status: Repaid.\nExtended: on an extendable loan, the borrower pays the closing period’s interest and the loan runs on for a fresh period on the same terms. See Loan Extensions.\nNot repaid: the lender can claim the collateral by signing a transaction (this triggers the collateral transfer). A 0.1% fee is deducted from the collateral (no fee on NFT collateral). The borrower can still repay until the lender claims. Loan status: Defaulted.\n\nIf an offer expires without being accepted, it is automatically removed from the offerbook. No fees are charged.\n\n​Offers and Loans\nBoth borrowers and lenders can create offers. For each offer, the following terms are defined:\nParameterDescriptionConfigurable?Collateral asset and amountThe onchain asset locked as securityYesUSDC amountThe liquidity borrowed or lentYesLTVRatio between USDC amount and collateral value (in %)Yes (linked to USDC amount)APR / APYCost of borrowing (APR) or return for lending (APY), annualizedYesLoan durationTime period of the loan (starts at acceptance)Yes (1 to 30 days)Allow partial fill + Minimum Fill AmountWhether partial acceptance is allowed and the minimum fill amount in USDYes (except NFT collateral)Offer expirationHow long the offer stays visible (separate from loan duration)1 to 7 days, set at creation\nTogether, these parameters determine an offer’s attractiveness. Matching occurs when the terms align with current market demand.\nThe role-by-role journeys are detailed in Borrowing and Lending.\n\n​Oracles and Pricing\nOfferbook does not use price oracles for loan execution.\nLoans are time-based with fixed terms, so there are no price-based liquidations or margin calls, and no onchain price tracking is required.\nPrices shown in the interface are provided by Jupiter’s pricing API and are informational only. They help users estimate values such as LTV, but do not affect loan execution or outcomes.Tokenized stocks (xStocks) are valued using the underlying stock price rather than the on-chain market price, giving more accurate LTV and balance estimates.\n\n​Why Offerbook?\nUSDC is the only asset that can be borrowed or lent on Offerbook. This simplifies the experience for both sides: borrowers and lenders only need to choose the collateral asset and the loan terms.\nOfferbook can be used with any Solana asset as collateral, and is optimized for specific use cases:\nFixed-term loansSimple loan management with predictable terms, duration, and outcomes.Illiquid assetsHigh-value assets with low onchain liquidity (such as RWAs) can be used as collateral without price-based liquidation or price manipulation risk.Advanced DeFi assetsLP positions, PT tokens, and other complex assets can be used as collateral.InsuranceBorrow USDC against a volatile asset to access liquidity now, with the option to walk away at maturity if the asset’s value has dropped below the borrowed amount. Surfaced as Get Insured in the app interface.\nOn the lending side, Offerbook provides a way to earn yield at fixed terms, with clearly defined risk at loan maturity.\n\n​Offerbook vs Jupiter Lend\nOfferbook and Jupiter Lend are both lending products within the Jupiter ecosystem, but they serve different use cases and operate on different models.\n​The Offerbook model\nParameterDetailModelPeer-to-peer. Borrowers and lenders publish offers expressing their intentions, and are matched directly through an order book.RatesFixed. Set by the user at offer creation and locked for the full loan duration.Loan durationUser-defined (1 to 30 days). Starts when the offer is accepted.If not repaidAfter maturity, the lender can manually claim the collateral. The borrower can still repay until the lender claims. No price-based events during the loan.OraclesNone. Prices in the interface are informational only.Collateral monitoringNone during the loan.Borrowable assetsUSDC only.CollateralAny Solana asset (verified tokens, RWAs such as xStocks, NFTs from whitelisted collections).\n​The Jupiter Lend model\nParameterDetailModelPool-based. Lenders supply assets to shared liquidity pools, borrowers draw from those pools.RatesVariable. Adjusted automatically based on supply and demand.Loan durationPerpetual. Positions remain active until the user repays or is liquidated.If not repaidContinuous price-based liquidation. Positions are partially or fully liquidated if collateral value drops below a threshold.OraclesYes (Pyth, Chainlink, Redstone). Used for real-time valuation and liquidation triggers.Collateral monitoringContinuous. Position Health updated in real time.Borrowable assetsMultiple (SOL, USDC, and other supported assets).CollateralEligible assets only (SOL, JupSOL, mSOL, JitoSOL, stablecoins, and others per vault).\nUse Offerbook when you want fixed terms, no liquidation risk during the loan, or need to borrow against assets with low onchain liquidity. Use Jupiter Lend when you want flexible, perpetual positions with continuous collateral monitoring and variable rates.\n\n​Supported Assets\nCollateral\nAny Solana asset (verified tokens)\nRWAs (such as xStocks)\nNFTs (whitelisted collections only)\nBorrowed / Lent asset\nUSDC only\n\nAsset availability may vary depending on integrations and standards.\n\n​Where to Go Next","tokens":4681,"squid":"spider-02","role":"Liquidity Spider","at":1791346742480,"hash":"f90e329aa68bcae6f1c601a7f9088f58a46b11d3"}
{"url":"https://docs.jup.ag/user-docs/earn/offerbook/pro","domain":"docs.jup.ag","title":"Pro - Jupiter Documentation","text":"Pro, under More in the header, brings the whole order book onto a single screen: both sides of the market and both intent books, side by side. The mechanics are exactly the same as everywhere else on Offerbook — the same offers, intents and loans — only the presentation changes: denser, but with everything reachable from one place.\nUse it to compare both sides of the market at a glance, spot the spread, and act on any offer or intent without switching views.\n​The market at a glance\nThe strip at the top summarizes the market in five numbers:\nStatMeaningBest borrow APYThe cheapest rate a borrower can take right nowSpreadThe gap between the best borrow and best lend ratesBest lend APYThe highest rate a lender can earn right nowOpen to borrowTotal USDC available in lend offers, with the offer countSeeking fundingTotal USDC asked by borrow requests, with the offer count\n​The four panels\nThe screen has one column per side of the market, each pairing the live offers with the intents you can act on from that side:\nBorrow USDCThe live lend offers you can take a loan from, with a Borrow button on each row and a New borrow request shortcut to create your own.Lend USDCThe live borrow requests you can fund, with a Lend button on each row and a New lend offer shortcut.Lend intentsBelow Borrow USDC: terms advertised by lenders, not yet funded. Match starts the standard flow to post the matching borrow offer.Borrow intentsBelow Lend USDC: terms advertised by borrowers, not yet funded. Match works the same way — see Intents.\nActing from Pro goes through the standard flows: Borrow and Lend open the usual offer confirmation (Borrowing, Lending), and the shortcuts open the regular creation flows.\n​Reading a row\nEach offer row shows:\nColumnMeaningCollateralThe asset and amount backing the loan, with its dollar valueAPYThe annualized rate of the offerInterestThe interest for the term in dollars, fee included (labelled “you pay” on the Borrow side)LTVThe loan-to-value ratio of the offerTermThe loan duration, with its due dateAvailableThe amount still fillable, with the fill progress (fully open, partially filled)ExpiresThe time left before the offer lapses\nIntent rows show the advertised size and an approximate APY (their amounts are LTV-based and recalculated against live prices — see Intents).\n​Filters, sorting and customization\n\nCollateral filters: restrict the book to Tokens or NFTs, or pick specific assets with + Collateral\nSort: order the rows by collateral, APY, LTV, term, amount or expiry\nColumns: show or hide APY, Interest, LTV, Term, Available and Expires; Reset columns restores the default\nCustomize: reorder the columns by dragging them","tokens":668,"squid":"spider-02","role":"Liquidity Spider","at":1791346766045,"hash":"f3a5f7d7864ac9f1228420cc4ce9101bdc59e9de"}
{"url":"https://docs.jup.ag/user-docs/earn/offerbook/borrowing","domain":"docs.jup.ag","title":"Borrowing - Jupiter Documentation","text":"Borrowing on Offerbook is fixed and predictable: you lock collateral, receive USD Coin (USDC), and repay the principal + interest to unlock it. The rate and the duration are agreed when the loan starts and never change, there are no price-based liquidations, and loans run from 1 to 30 days.\nYou can borrow against tokens or collectibles; what each market accepts is covered in Markets.\n​How to start a loan\nEverything starts from the Borrow view in the header. There are three paths to a loan as a borrower:\n\nFill an open lend offer for instant terms set by the lender\nCreate your own borrow offer, from Create your own offer in the Borrow list or Create Offer > Borrow in the header, and wait for a lender to fill it\nSend a counter offer on an open lend offer whose terms are close but not quite right. See Counter Offers\n\nYou can also advertise the terms you want through an intent, which is free, off-chain and locks nothing. To browse every offer and intent on one screen instead, use the Pro view.\n​The Borrow view\nThe Borrow page opens on the Borrow tab. Leverage, next to it, opens a leveraged long on any collateral: pick the Asset to long (leveraged with USDC), set Your deposit and the term, and take one of the offers, sorted by highest leverage. See Multiply. A banner at the top of the page lets you switch to the classic experience at any time.\nThe Borrow tab is one card that follows your request:\n\nBorrow against: Choose collateral opens a searchable selector with category tabs (All, Collectibles, Bridged, DeFi, LSTs, Memecoins, RWA, Stablecoins). Pick a single asset, several at once (up to 10, with Select all), or a collectible collection; the offer list then covers them all.\nAmount to borrow: the USDC amount you want.\nTerm: 7d, 14d or 30d, or + for a custom term.\n\nBelow, the card ranks every lender’s offer for that request, with the number of offers and a sort menu: Best rate, Lowest cost or Least collateral. Each row is labelled by its lender — username or shortened address — with what the offer asks you to lock and its LTV (“Lock 544.75 ONyc · 80% LTV”), the amount, the APR, the duration and the total cost. Lenders whose escrow cannot cover your full amount come after the others, with what they can fund (“Draws 190 max, 310 short”). A ↻ marker next to the duration means loans from that offer can be extended (see Loan Extensions).\nShow terms expands a row into the full breakdown: the rate, the LTV, what you lock and what you receive, the interest, the platform fee, the estimated network fees and rent, the repay-by date and the Total to repay. A line at the bottom of the card sums up the selected offer (“Repay 503.6 USDC on Oct 29 · 544.75 ONyc locked until then”) above the Borrow button.\n​Posting your own ask from the Borrow page\nAmong the offers, Create your own offer shows the rate that would put you below every lender, and opens a composer on the same card (“Your ask · 500 USDC · 14 days”):\n\nRate · all-in: set it with the − and + buttons; an indicator places it against the market (“Won’t fill · well off the market as it stands”). Rates are all-in: the protocol stores the offer rate and adds the 25% fee back on top.\nMore options: Partial fills with a minimum fill (25% of the amount by default), Allow extensions, and the expiration (1d, 3d or 7d).\nThe interest over the term, the repayment amount and its date are shown before you publish.\npost free instead advertises the same terms as an intent: nothing locked, a signature only.\n\nFor the full creation flow, with pricing presets and the fill score, use Create Offer > Borrow in the header, described in Creating a borrow offer.\n​Filling a lend offer\nWhen you accept a lend offer, the loan starts immediately and the loan duration begins. Your collateral transits through the escrow and is locked onchain automatically, in a single transaction, and the USDC is transferred to you. If the offer allows partial fill, you can accept any amount at or above its Minimum Fill Amount; otherwise the offer must be filled in full.\nBefore you confirm, Show terms spells out exactly what will happen: the collateral you lock, the USDC you receive, the rate and LTV, and the full cost breakdown — interest, the 25% platform fee, estimated network fees and rent — down to the Total to repay and its due date. The lender is shown by username when they have set one. At this stage, you can add the loan’s maturity date to your calendar using the calendar button provided in the interface. Calendar reminders fire 2 hours before maturity.\nAfter maturity, the lender can manually claim the collateral at any time. The transfer is not automatic, but you cannot rely on any delay. Repayment timing is entirely your responsibility.\n​Creating a borrow offer\nCreate Offer > Borrow, in the header, opens the Ask for a Loan page, a creation flow in three steps: Collateral, Terms, and Publish. The Dashboard’s Offers tab links to the same page with the Borrowing side already picked.\n1CollateralDefine what you lock and what you borrow:\nYou lock: the collateral asset and amount, capped by your wallet balance (Max shortcut available). Collateral can be a verified token, a real-world asset (RWA) such as xStocks, or a non-fungible token (NFT) from a whitelisted collection; for NFT collateral, the LTV reference is the collection floor price\nYou borrow: the USDC amount, at least $10 per loan, linked to the LTV (Loan-to-Value) slider: changing one updates the other. As you move the slider, an indicator estimates how attractive the terms are to lenders (for example, “Good chance to fill, reasonable collateral ratio”)\nQuick Pricing · LTV: presets to position your LTV: Recommended, Match best, and Beat market, computed against competing offers when they exist\n2TermsSet the price and the duration:\nAPR (Annual Percentage Rate): the rate is displayed all-in, including the fee (offer APR × 1.25, pricing in the 25% upfront fee), and compared to the market median (for example, “-2.5 vs median 22.5%”). The breakdown is shown underneath: on a 20% all-in APR, “Lender keeps 16% · 4% protocol fee”. See Fees and Costs\nQuick Pricing · APR: the same preset system as for LTV (Recommended, Match best, Beat market)\nDuration: 1 to 30 days, with presets (7d, 14d, 30d) and a fine-grained day stepper\nWhat you’ll pay: the interest over the duration and the exact repayment amount at maturity are displayed before you continue\nVS. MARKET: a fill score out of 100 positions your offer against live competition on a gauge from “Won’t fill” to “Fills fast”, with a plain-language verdict (for example, “Below market, 43/100 — softer than the median, it may sit for a while”) and your LTV compared to the market median. Browse all offers opens the competing offers\n3PublishThe Publish step offers two ways to put your terms on the market:\nLock & list now creates the onchain borrow offer: your collateral is escrowed (the app deposits it from your wallet automatically) and the offer is listed, fillable instantly by any lender. It requires the collateral plus a little SOL for network fees and rent. See Settings & Notifications\nJust advertise terms posts an intent instead: a free signature, no SOL spent, nothing locked, and the collateral stays in your wallet. Lenders come to you, but the intent cannot be filled until you lock it as an offer. Your wallet must hold the advertised collateral to post it, so that advertised terms stay backed by a real balance\nThe step also carries the fill settings and the expiration:\nAllow partial fills: let lenders fill part of the offer instead of all of it — more likely to fill. Minimum fill sets the smallest amount a lender can take in a single fill (leave it blank for the recommended minimum)\nExpiration (under Advanced options): how long the offer stays live and fillable — it lapses automatically after this, and nothing is locked in beyond it. 1 to 7 days for a locked offer, up to 90 days when only advertising terms as an intent\n\nAn offer’s expiration determines how long it stays open to be filled: 1 to 7 days, set at creation (the Create Offer flow offers 1, 3 and 7-day presets). The longer an offer stays open, the longer your terms stay fillable even if the collateral price or market rates move against you — cancel and relist if the market has moved; expired offers can be renewed in one click.\nPublished offers cannot be edited. You can cancel an offer at any time before it is accepted, at no fee. Once an offer expires, you can renew it directly from Dashboard > Offers, with the option to adjust the LTV, instead of recreating it from scratch. If nobody fills your offer before it expires, no loan is created and you owe nothing.\nCounterparties can also send counter offers on your offer, proposing a different LTV, rate (APY), duration or amount. They appear beneath your offer in Dashboard, an activity dot shows on the Dashboard link, and you can accept one (the loan starts immediately at the counter terms) or ignore them.\n​Borrowing costs\nUpfront fee25% of the estimated interest, paid in USDC when the loan starts.InterestThe full interest for the agreed duration is always owed, regardless\nof when you repay.\nThe interface prices the fee directly into the displayed rate: the APR\nshown in the creation flow and in offer listings is all-in, combining the\noffer rate and the fee (an offer at 8% APR displays as 10% all-in). The\nfull schedule is in Fees and Costs.\nNetwork fees and account rent also apply to the onchain transactions\ninvolved. Rent is a deposit, not a fee: part of it returns when the related\naccounts close.\n​Your Escrow\nEvery Offerbook user has a dedicated escrow wallet, but as a borrower you\nnever manage it. Your collateral transits through it automatically in a\nsingle transaction when you create or accept an offer, and returns\ndirectly to your main wallet when you repay.\n​Your Dashboard\nEverything you do as a borrower lives under Dashboard, with the Borrowing side selected. A Status filter and a Columns menu narrow the tables.\n\nPositions — your open loans, with your net equity, position value, debt, open PnL and net APY at the top. Loans are split into two groups: Looped positions, the leveraged ones created with Multiply, where PnL applies, and Standard loans, plain borrowing against collateral, without PnL. Each loan follows the statuses Active, Repaid, Expired and Defaulted.\nOffers — your open borrow offers. Cancel them before they are filled, or renew them once expired.\n\nSelect several offers or loans to cancel, renew or extend them together, in fewer wallet prompts, with the result shown row by row.\n​Repayment\nRepay from Dashboard > Positions, using the action button on the right of the loan’s row. If the loan is extendable, the row leads with Extend instead and Repay moves into the row menu — extending rolls the loan into a fresh period on the same terms rather than closing it (see Loan Extensions). You sign a transaction that returns the principal plus interest to the lender and unlocks your collateral.\nYou repayAny time before maturity — or even after, as long as the lender has not\nclaimed. The collateral returns directly to your wallet. Early repayment\ndoes not reduce the cost: the full interest is owed whenever you repay.You do not repayPast maturity, the lender can claim your collateral by signing a\ntransaction. This is not a liquidation: no market sale, the collateral\nis transferred directly to the lender and the loan is marked Defaulted.\nYou keep the borrowed USDC, but the collateral is gone.\nThe lender can claim at any moment after maturity. Never rely on the\npost-maturity window — always plan to repay before the loan reaches\nmaturity.\n​Examples\n​Accessing liquidity against a held asset\nA user holds a tokenized onchain asset valued at approximately $10,000, with limited onchain liquidity. Rather than selling the asset, they want to access USDC liquidity for a short period.\nThey create a borrow offer with the following terms:\nParameterValueCollateralOnchain asset valued at ~$10,000Borrowed asset8,000 USDCLTV80%Loan duration3 daysFixed APR35%\nA lender accepts the offer. Once the loan starts, the collateral is locked for 3 days, and the borrower receives 8,000 USDC. During the loan, no price-based liquidation can occur, regardless of market price movements.\n​If the borrower repays\nAt maturity, the borrower repays the borrowed amount plus interest:\nItemAmountInterest paid~$23 for the 3-day loanFee at loan start (25% of estimated interest, paid by borrower)~$5.75Fee at repayment (10% of interest, deducted from lender’s return)~$2.30Interest received by the lender~$20.70\nThe loan is closed, and the collateral is returned directly to the borrower’s wallet.\n​If the borrower does not repay\nAfter maturity, the lender can claim the collateral by signing a transaction: a 0.1% fee is deducted from the collateral, and the rest is sent to the lender (no fee on NFT collateral). The borrower can still repay and recover the collateral until the lender claims.\nDo not rely on this window. The lender can claim at any moment after maturity. Always plan to repay before the loan reaches maturity.\n​Insurance: protecting against a price drop\nThe same borrow mechanic can protect against a downside on a volatile asset you want to keep exposure to. This use case is surfaced as Get Insured in the interface, but it relies on the same loan flow as any other borrow offer.\nA user holds an asset valued at approximately $1,500 and is concerned about a price drop over the next few days, but does not want to sell. By creating a borrow offer using this asset as collateral, they receive USDC immediately, and decide at maturity whether to repay (and recover the asset) or not (and keep the USDC).\nParameterValueCollateralAsset valued at ~$1,500Borrowed asset1,000 USDCLTV~67%Loan duration3 days\nTwo outcomes at maturity:\n\nThe asset stays above 1,000 USDC: the user repays (principal + interest + fees) and recovers the collateral. The cost is the interest plus the 25% upfront fee — the price of the protection.\nThe asset drops below 1,000 USDC: the user can choose not to repay. The lender claims the collateral, and the user keeps the 1,000 USDC, now worth more than the depreciated asset.\n\nInsurance is not free. The borrower pays interest plus the 25% upfront fee regardless of the outcome. The protection only pays off if the asset drops below the borrowed USDC amount (after fees) by maturity; if the price holds, the operation is a net cost.\n​Mistakes to avoid\nForgetting loan maturityBecause there are no margin calls during the loan, borrowers may overlook loan maturity. After maturity, the lender can claim your collateral at any time. Use the calendar reminder at offer acceptance to stay on track.Assuming early repayment reduces interestYou can repay at any time before maturity, but the full interest for the agreed loan duration is always owed. There is no partial interest or fee reduction for early repayment.Setting an unrealistic APRAPR is what balances an offer relative to its collateral, LTV, and duration. The fill score and the market comparisons in the creation flow exist precisely to surface this: offers with rates significantly out of line with current market conditions may remain unmatched. Think about how all parameters work together rather than focusing on a single value.","tokens":3832,"squid":"spider-02","role":"Liquidity Spider","at":1791346794479,"hash":"bf58e96c52e2ff8c8b29d54a5419b68d90025c43"}
{"url":"https://www.metaplex.com/docs/tokens/launch-token","domain":"metaplex.com","title":"Launch a Token on Solana — Genesis Fair Launch Guide | Metaplex","text":"Launch an SPL token on Solana using Genesis Launch Pools. This guide walks you through a fair launch where users deposit SOL during a window and receive tokens proportional to their share of total deposits — all handled transparently on-chain. No-Code OptionDon't want to write code? Use the Metaplex token launchpad to launch a token with no coding required. This guide is for developers who want to build their own token launch experience or host a token sale on their own website using the Genesis SDK.Other Launch MethodsThis guide covers the Launch Pool fair launch method, but Genesis also supports Presale token sales where tokens are sold at a fixed price. Check the Genesis overview to compare methods and choose the best fit for your project.OverviewGenesis is a Solana token launchpad that provides fair, on-chain token launch mechanisms. Unlike a centralized token sale platform where tokens are sold at a fixed price, a Launch Pool lets the market determine token distribution — every participant receives tokens proportional to their deposit, ensuring a fair and transparent token generation event (TGE). All SPL token creation, fundraising, and distribution happens on-chain with no intermediaries.A Launch Pool token launch has three phases:Setup (you run once) - Create the token, configure the launch, and activate itDeposit Period (users interact) - Users deposit SOL during the window you configuredPost-Launch (you + users) - Crank the state machine, users claim tokens, you revoke authoritiesThis guide walks you through creating four separate scripts that you'll run at different stages:ScriptWhen to RunPurposelaunch.tsOnce, to startCreates your token and activates the launchcrank.tsAfter deposits closeTriggers conditions and behaviors to move SOL to your unlocked bucketclaim.tsAfter crankUsers run this to claim their tokensrevoke.tsWhen launch is completePermanently removes mint/freeze authoritiesPrerequisitesCreate a new project and install dependencies:mkdir my-token-launch\ncd my-token-launch\nnpm init -y\nnpm install @metaplex-foundation/genesis @metaplex-foundation/umi @metaplex-foundation/umi-bundle-defaults @metaplex-foundation/mpl-toolbox\nThe Complete Launch ScriptBelow is a complete, runnable script. Each section is commented to explain what it does. You'll run this script once to set up your launch.Keypair RequiredYou need a Solana keypair file on your machine to sign transactions. This is typically your Solana CLI wallet located at ~/.config/solana/id.json. Update the walletFile path in the script to point to your keypair file. Make sure this wallet has SOL for transaction fees.Create a file called launch.ts:import { readFileSync } from 'fs';\nimport { createUmi } from '@metaplex-foundation/umi-bundle-defaults';\nimport {\n genesis,\n initializeV2,\n findGenesisAccountV2Pda,\n findLaunchPoolBucketV2Pda,\n findUnlockedBucketV2Pda,\n addLaunchPoolBucketV2,\n addUnlockedBucketV2,\n finalizeV2,\n} from '@metaplex-foundation/genesis';\nimport { generateSigner, publicKey, keypairIdentity } from '@metaplex-foundation/umi';\n\nasync function main() {\n // ============================================\n // SETUP: Configure your connection and wallet\n // ============================================\n\n const umi = createUmi('https://api.devnet.solana.com')\n .use(genesis());\n\n // Load your wallet keypair from a file on your machine\n // This is typically your Solana CLI wallet at ~/.config/solana/id.json\n // Or use any keypair file you have access to\n const walletFile = '/path/to/your/keypair.json'; // <-- UPDATE THIS PATH\n const secretKey = JSON.parse(readFileSync(walletFile, 'utf-8'));\n const keypair = umi.eddsa.createKeypairFromSecretKey(new Uint8Array(secretKey));\n umi.use(keypairIdentity(keypair));\n\n // ============================================\n // CONFIGURATION: Customize these values\n // ============================================\n\n // Token details\n const TOKEN_NAME = 'My Token';\n const TOKEN_SYMBOL = 'MTK';\n const TOKEN_URI = 'https://example.com/metadata.json'; // Your metadata JSON URL\n const TOTAL_SUPPLY = 1_000_000_000_000n; // 1 trillion tokens (adjust as needed)\n\n // Timing (in seconds from now)\n const DEPOSIT_DURATION = 24 * 60 * 60; // 24 hours\n const CLAIM_DURATION = 7 * 24 * 60 * 60; // 7 days\n\n // Calculate timestamps\n const now = BigInt(Math.floor(Date.now() / 1000));\n const depositStart = now;\n const depositEnd = now + BigInt(DEPOSIT_DURATION);\n const claimStart = depositEnd + 1n;\n const claimEnd = claimStart + BigInt(CLAIM_DURATION);\n\n // ============================================\n // STEP 1: Create your token\n // ============================================\n console.log('Step 1: Creating token...');\n\n const baseMint = generateSigner(umi);\n\n const [genesisAccount] = findGenesisAccountV2Pda(umi, {\n baseMint: baseMint.publicKey,\n genesisIndex: 0,\n });\n\n await initializeV2(umi, {\n baseMint,\n fundingMode: 0,\n totalSupplyBaseToken: TOTAL_SUPPLY,\n name: TOKEN_NAME,\n uri: TOKEN_URI,\n symbol: TOKEN_SYMBOL,\n }).sendAndConfirm(umi);\n\n console.log('✓ Token created!');\n console.log(' Token mint:', baseMint.publicKey);\n console.log(' Genesis account:', genesisAccount);\n\n // ============================================\n // STEP 2: Add Launch Pool bucket\n // This is where users will deposit SOL\n // ============================================\n console.log('\\nStep 2: Adding Launch Pool bucket...');\n\n const [launchPoolBucket] = findLaunchPoolBucketV2Pda(umi, {\n genesisAccount,\n bucketIndex: 0,\n });\n\n const [unlockedBucket] = findUnlockedBucketV2Pda(umi, {\n genesisAccount,\n bucketIndex: 0,\n });\n\n await addLaunchPoolBucketV2(umi, {\n genesisAccount,\n baseMint: baseMint.publicKey,\n baseTokenAllocation: TOTAL_SUPPLY,\n depositStartCondition: {\n __kind: 'TimeAbsolute',\n padding: Array(47).fill(0),\n time: depositStart,\n triggeredTimestamp: null,\n },\n depositEndCondition: {\n __kind: 'TimeAbsolute',\n padding: Array(47).fill(0),\n time: depositEnd,\n triggeredTimestamp: null,\n },\n claimStartCondition: {\n __kind: 'TimeAbsolute',\n padding: Array(47).fill(0),\n time: claimStart,\n triggeredTimestamp: null,\n },\n claimEndCondition: {\n __kind: 'TimeAbsolute',\n padding: Array(47).fill(0),\n time: claimEnd,\n triggeredTimestamp: null,\n },\n minimumDepositAmount: null,\n softCap: null, // required since genesis 0.42.0; pass null for no soft cap\n endBehaviors: [\n {\n __kind: 'SendQuoteTokenPercentage',\n padding: Array(4).fill(0),\n destinationBucket: publicKey(unlockedBucket),\n percentageBps: 10000, // 100% of collected SOL goes to unlocked bucket\n processed: false,\n },\n ],\n }).sendAndConfirm(umi);\n\n console.log('✓ Launch Pool bucket added!');\n console.log(' Bucket address:', launchPoolBucket);\n\n // ============================================\n // STEP 3: Add Unlocked bucket\n // This receives the collected SOL for your team\n // ============================================\n console.log('\\nStep 3: Adding Unlocked bucket...');\n\n await addUnlockedBucketV2(umi, {\n genesisAccount,\n baseMint: baseMint.publicKey,\n baseTokenAllocation: 0n,\n recipient: umi.identity.publicKey,\n claimStartCondition: {\n __kind: 'TimeAbsolute',\n padding: Array(47).fill(0),\n time: claimStart,\n triggeredTimestamp: null,\n },\n claimEndCondition: {\n __kind: 'TimeAbsolute',\n padding: Array(47).fill(0),\n time: claimEnd,\n triggeredTimestamp: null,\n },\n backendSigner: null,\n }).sendAndConfirm(umi);\n\n console.log('✓ Unlocked bucket added!');\n console.log(' Bucket address:', unlockedBucket);\n\n // ============================================\n // STEP 4: Finalize - activates the launch\n // After this, no more changes can be made\n // ============================================\n console.log('\\nStep 4: Finalizing...');\n\n await finalizeV2(umi, {\n baseMint: baseMint.publicKey,\n genesisAccount,\n }).sendAndConfirm(umi);\n\n console.log('✓ Launch is now ACTIVE!');\n\n // ============================================\n // SUMMARY: Save these addresses!\n // ============================================\n console.log('\\n========================================');\n console.log('LAUNCH COMPLETE - SAVE THESE ADDRESSES:');\n console.log('========================================');\n console.log('Token mint:', baseMint.publicKey);\n console.log('Genesis account:', genesisAccount);\n console.log('Launch Pool bucket:', launchPoolBucket);\n console.log('Unlocked bucket:', unlockedBucket);\n console.log('');\n console.log('TIMING:');\n console.log('Deposits open:', new Date(Number(depositStart) * 1000).toISOString());\n console.log('Deposits close:', new Date(Number(depositEnd) * 1000).toISOString());\n console.log('Claims open:', new Date(Number(claimStart) * 1000).toISOString());\n console.log('Claims close:', new Date(Number(claimEnd) * 1000).toISOString());\n}\n\nmain().catch(console.error);\nRun the script:npx ts-node launch.ts\nSave the addresses that are printed! You'll need them for the next steps.What Happens NextAfter running the launch script, your launch is live. Here's what happens during each phase:During the Deposit PeriodUsers deposit SOL using your frontend or directly via the SDK. Each deposit:Has a fee appliedIs tracked in a deposit PDACan be partially or fully withdrawn (with fee)After Deposits CloseOnce the deposit period ends, run triggerBehaviorsV2 to execute the end behaviors configured on the bucket — in this case, moving collected SOL to the unlocked bucket. Create a file called crank.ts:import { readFileSync } from 'fs';\nimport { createUmi } from '@metaplex-foundation/umi-bundle-defaults';\nimport {\n genesis,\n triggerBehaviorsV2,\n WRAPPED_SOL_MINT,\n} from '@metaplex-foundation/genesis';\nimport { findAssociatedTokenPda, mplToolbox } from '@metaplex-foundation/mpl-toolbox';\nimport { publicKey, keypairIdentity } from '@metaplex-foundation/umi';\n\nasync function main() {\n const umi = createUmi('https://api.devnet.solana.com')\n .use(mplToolbox())\n .use(genesis());\n\n // Load your wallet keypair (same wallet used for launch)\n const walletFile = '/path/to/your/keypair.json'; // <-- UPDATE THIS PATH\n const secretKey = JSON.parse(readFileSync(walletFile, 'utf-8'));\n const keypair = umi.eddsa.createKeypairFromSecretKey(new Uint8Array(secretKey));\n umi.use(keypairIdentity(keypair));\n\n // Fill in the addresses printed by your launch script\n const genesisAccount = publicKey('YOUR_GENESIS_ACCOUNT');\n const baseMint = publicKey('YOUR_TOKEN_MINT');\n const launchPoolBucket = publicKey('YOUR_LAUNCH_POOL_BUCKET');\n const unlockedBucket = publicKey('YOUR_UNLOCKED_BUCKET');\n\n const unlockedBucketQuoteTokenAccount = findAssociatedTokenPda(umi, {\n owner: unlockedBucket,\n mint: WRAPPED_SOL_MINT,\n });\n\n console.log('Cranking state...');\n\n await triggerBehaviorsV2(umi, {\n genesisAccount,\n primaryBucket: launchPoolBucket,\n baseMint,\n })\n .addRemainingAccounts([\n { pubkey: publicKey(unlockedBucket), isSigner: false, isWritable: true },\n { pubkey: publicKey(unlockedBucketQuoteTokenAccount), isSigner: false, isWritable: true },\n ])\n .sendAndConfirm(umi);\n\n console.log('✓ Crank complete! SOL moved to unlocked bucket.');\n}\n\nmain().catch(console.error);\nRun after the deposit period ends:npx ts-node crank.ts\nUsers Claim TokensAfter the crank, users can claim their tokens. Each user receives tokens proportional to their share of total deposits:userTokens = (userDeposit / totalDeposits) * totalTokenSupply\nUsers can claim via your frontend or using this script (create claim.ts):import { readFileSync } from 'fs';\nimport { createUmi } from '@metaplex-foundation/umi-bundle-defaults';\nimport {\n genesis,\n claimLaunchPoolV2,\n} from '@metaplex-foundation/genesis';\nimport { publicKey, keypairIdentity } from '@metaplex-foundation/umi';\n\nasync function main() {\n const umi = createUmi('https://api.devnet.solana.com')\n .use(genesis());\n\n // Load the user's wallet keypair (whoever deposited SOL)\n const walletFile = '/path/to/your/keypair.json'; // <-- UPDATE THIS PATH\n const secretKey = JSON.parse(readFileSync(walletFile, 'utf-8'));\n const keypair = umi.eddsa.createKeypairFromSecretKey(new Uint8Array(secretKey));\n umi.use(keypairIdentity(keypair));\n\n // Fill in the addresses from the launch\n const genesisAccount = publicKey('YOUR_GENESIS_ACCOUNT');\n const baseMint = publicKey('YOUR_TOKEN_MINT');\n const launchPoolBucket = publicKey('YOUR_LAUNCH_POOL_BUCKET');\n\n console.log('Claiming tokens...');\n\n await claimLaunchPoolV2(umi, {\n genesisAccount,\n bucket: launchPoolBucket,\n baseMint,\n recipient: umi.identity.publicKey,\n }).sendAndConfirm(umi);\n\n console.log('✓ Tokens claimed!');\n}\n\nmain().catch(console.error);\nFinalize: Revoke AuthoritiesAfter the launch is complete, revoke mint and freeze authorities. This signals to holders that no additional tokens can ever be minted.This is irreversible. Once revoked, you can never mint additional tokens or freeze accounts. Only do this when you're certain the launch is complete.Create revoke.ts:import { readFileSync } from 'fs';\nimport { createUmi } from '@metaplex-foundation/umi-bundle-defaults';\nimport {\n genesis,\n revokeV2,\n} from '@metaplex-foundation/genesis';\nimport { publicKey, keypairIdentity } from '@metaplex-foundation/umi';\n\nasync function main() {\n const umi = createUmi('https://api.devnet.solana.com')\n .use(genesis());\n\n // Load your wallet keypair (same wallet used for launch)\n const walletFile = '/path/to/your/keypair.json'; // <-- UPDATE THIS PATH\n const secretKey = JSON.parse(readFileSync(walletFile, 'utf-8'));\n const keypair = umi.eddsa.createKeypairFromSecretKey(new Uint8Array(secretKey));\n umi.use(keypairIdentity(keypair));\n\n // Fill in these addresses from the launch\n const genesisAccount = publicKey('YOUR_GENESIS_ACCOUNT');\n const baseMint = publicKey('YOUR_TOKEN_MINT');\n\n console.log('Revoking mint and freeze authorities...');\n await revokeV2(umi, {\n genesisAccount,\n baseMint,\n revokeMintAuthority: true,\n revokeFreezeAuthority: true,\n }).sendAndConfirm(umi);\n\n console.log('\\n✓ Launch complete! Token is fully decentralized.');\n}\n\nmain().catch(console.error);\nNext StepsGenesis Overview - Learn more about the Solana token launchpadLaunch Pool - Detailed fair launch documentationPresale - Run a token presale at a fixed priceMetaplex API - Query launch and token sale data via API","tokens":3538,"squid":"dotcat","role":"Tooling Spider","at":1791346794542,"hash":"eca27c86b83fddb8a41ffd7fb8e7eaec0b9f7069"}
{"url":"https://www.metaplex.com/docs/tokens/transfer-a-token","domain":"metaplex.com","title":"How to Transfer Fungible Tokens on Solana | Tokens","text":"Transfer fungible tokens (SPL tokens) between wallets on the Solana blockchain. Transfer TokensIn the following section you can find a full code example and the Parameters that you might have to change. You can learn more about token transfer details in the Token Metadata program pages.1// To install all the required packages use the following command\n2// npm install @metaplex-foundation/mpl-toolbox @metaplex-foundation/umi @metaplex-foundation/umi-bundle-defaults\n3import {\n4 createTokenIfMissing,\n5 findAssociatedTokenPda,\n6 transferTokens,\n7} from '@metaplex-foundation/mpl-toolbox';\n8import {\n9 keypairIdentity,\n10 publicKey,\n11 transactionBuilder,\n12} from '@metaplex-foundation/umi';\n13import { createUmi } from '@metaplex-foundation/umi-bundle-defaults';\n14import { readFileSync } from 'fs';\n15\n16// Initialize Umi with Devnet endpoint\n17 const umi = createUmi('https://api.devnet.solana.com')\n18 \n19 // Load your wallet/keypair\n20 const wallet = '<your wallet file path>'\n21 const secretKey = JSON.parse(readFileSync(wallet, 'utf-8'))\n22 const keypair = umi.eddsa.createKeypairFromSecretKey(new Uint8Array(secretKey))\n23 umi.use(keypairIdentity(keypair))\n24 \n25 // Your token mint address and destination wallet\n26 const mintAddress = publicKey('<your token mint address>')\n27 const destinationAddress = publicKey('<destination wallet address>')\n28\n29// Find the source token account (your account)\n30 const sourceTokenAccount = findAssociatedTokenPda(umi, {\n31 mint: mintAddress,\n32 owner: umi.identity.publicKey,\n33 })\n34 \n35 // Find the destination token account\n36 const destinationTokenAccount = findAssociatedTokenPda(umi, {\n37 mint: mintAddress,\n38 owner: destinationAddress,\n39 })\n40 \n41 // Create the destination token account if it doesn't exist\n42 transactionBuilder()\n43 .add(createTokenIfMissing(umi, {\n44 mint: mintAddress,\n45 owner: destinationAddress,\n46 }))\n47 // Transfer 100 tokens\n48 .add(\n49 transferTokens(umi, {\n50 source: sourceTokenAccount,\n51 destination: destinationTokenAccount,\n52 amount: 100,\n53 }))\n54 .sendAndConfirm(umi)\n55\n56console.log('Transferred 100 tokens')\n57 console.log('From:', sourceTokenAccount)\n58 console.log('To:', destinationTokenAccount)\n1# Transfer Tokens using the Metaplex CLI\n2\n3# Usage: mplx toolbox token transfer <MINT_ADDRESS> <AMOUNT> <DESTINATION>\n4mplx toolbox token transfer <MINT_ADDRESS> <AMOUNT> <DESTINATION_ADDRESS>\n5\n6# Example: Transfer 100 tokens (0 decimals)\n7mplx toolbox token transfer 7xKXtg2CW87d97TXJSDpbD5jBkheTqA83TZRuJosgAsU 100 9WzDXwBbmkg8ZTbNMqUxvQRAyrZzDsGYdLVL9zYtAWWM\n8\n9# Example: Transfer 100 tokens (9 decimals)\n10# Amount is in smallest units: 100 * 10^9 = 100000000000\n11mplx toolbox token transfer 7xKXtg2CW87d97TXJSDpbD5jBkheTqA83TZRuJosgAsU 100000000000 9WzDXwBbmkg8ZTbNMqUxvQRAyrZzDsGYdLVL9zYtAWWM\n12\n13# Note: If the destination doesn't have a token account, it will be created automatically\nParametersCustomize these parameters for your transfer:ParameterDescriptionmintAddressThe token mint addressdestinationAddressRecipient wallet addressamountNumber of tokens to transferHow It WorksThe transfer process involves four steps:Find source token account - Locate your token account using findAssociatedTokenPdaFind destination token account - Locate the recipient's token accountCreate destination token account if needed - Use createTokenIfMissing to ensure the recipient has a token accountTransfer tokens - Execute the transfer with transferTokensToken AccountsEach wallet has an Associated Token Account (ATA) for each type of token they hold. The findAssociatedTokenPda function derives the address of these accounts based on the wallet address and token mint.The createTokenIfMissing function automatically creates the token account if it doesn't exist yet, or does nothing if it already exists. This ensures the transfer will always succeed.","tokens":964,"squid":"dotcat","role":"Tooling Spider","at":1791346804472,"hash":"896c189b21e598c8b241f9faa998d7370c56c6b0"}
{"url":"https://developer.arbitrum.io/launch-arbitrum-chain/chain-config/costs/parent-chain-data-fee-pricing","domain":"developer.arbitrum.io","title":"Tune parent chain data fee pricing","text":"Configure your chainCostsTune parent chain data fee pricingHow to tune the ArbOwner parameters that control what your Arbitrum chain charges users for posting transaction data to the parent chain.Request an updateYour Arbitrum chain charges users for the cost of posting their transaction data to the . Four ArbOwner methods control how that charge adjusts over time. Tune them when fee revenue drifts away from what your actually spends.\nThese parameters are separate from congestion pricing. They set what the chain charges for data, not what it charges when demand exceeds the . To tune congestion pricing, refer to the Manage gas target page.\nHow the pricing algorithm works\n tracks a running surplus: the difference between what it has collected from users for data and what it owes the batch poster. At each update it adjusts the price per data unit to drive that surplus toward zero over a chosen time horizon.\nTwo of the parameters below map directly onto that algorithm:\n\nEquilibration units set the time horizon for eliminating the surplus.\nPricing inertia smooths the adjustment so the price does not swing sharply between updates.\n\nFor the full derivation, refer to gas and fees.\nThe parameters\nCall all four methods on the ArbOwner at address 0x0000000000000000000000000000000000000070. Only a can call them. Calls from any other account revert.\nMethodWhat it setsDefaultsetL1PricingInertia(uint64 inertia)How much the algorithm smooths each price adjustment10setL1PricingEquilibrationUnits(uint256 units)The time horizon, in data units, for eliminating the surplus160,000,000setL1BaseFeeEstimateInertia(uint64 inertia)How slowly ArbOS updates its estimate of the parent chain base fee10setAmortizedCostCapBips(uint64 cap)A ceiling on the amortized cost the chain charges, in basis points0, meaning no cap\nThe 160,000,000 default for equilibration units applies from ArbOS 6 onward. Chains initialized before ArbOS 6 used 96,000,000.\nWarningsetL1PricingInertia and setL1BaseFeeEstimateInertia write the same stored value. To read it back, call ArbGasInfo.getL1BaseFeeEstimateInertia().ArbGasInfo.getPricingInertia() does not return this value. It returns the congestion pricing inertia set by setL2GasPricingInertia, which is a different parameter for a different algorithm. Refer to Manage gas target.\nRead the current values\nAll of these parameters can be read back through ArbGasInfo, at address 0x000000000000000000000000000000000000006c. The inertia value set by either setter is returned by getL1BaseFeeEstimateInertia():\ncast call --rpc-url $ORBIT_RPC 0x000000000000000000000000000000000000006c \"getL1PricingEquilibrationUnits()\"\ncast call --rpc-url $ORBIT_RPC 0x000000000000000000000000000000000000006c \"getL1BaseFeeEstimateInertia()\"\ncast call --rpc-url $ORBIT_RPC 0x000000000000000000000000000000000000006c \"getAmortizedCostCapBips()\"\ngetL1PricingEquilibrationUnits() is available from ArbOS 20 onward.\nTo see whether the algorithm is currently over- or under-collecting, read the surplus:\ncast call --rpc-url $ORBIT_RPC 0x000000000000000000000000000000000000006c \"getL1PricingSurplus()\"\nA persistent positive surplus means the chain collects more for data than it owes the batch poster. A persistent negative surplus means it collects too little and the reimbursement fund is draining.\nChange a value\nTo shorten the equilibration horizon so the algorithm corrects a surplus faster:\ncast send --rpc-url $ORBIT_RPC --private-key $OWNER_KEY 0x0000000000000000000000000000000000000070 \"setL1PricingEquilibrationUnits(uint256)\" 80000000\nConfirm the change:\ncast call --rpc-url $ORBIT_RPC 0x000000000000000000000000000000000000006c \"getL1PricingEquilibrationUnits()\"\nChange one parameter at a time and watch the surplus across several batch posting cycles before you change another. Adjusting two at once makes it hard to attribute the resulting fee behavior.\nWarningTest every change on a devnet or testnet chain first. A short equilibration horizon combined with low inertia makes data fees swing sharply between updates, which harms user experience even when the long-run average is correct.\nRelated parameters\nTwo more ArbOwner methods affect what the chain collects for data, covered elsewhere:\n\nsetL1PricePerUnit(uint256 pricePerUnit) and setPerBatchGasCharge(int64 cost), in configure and optimize gas.\nsetL1PricingRewardRate(uint64 weiPerUnit) and setL1PricingRewardRecipient(address recipient), which route the batch poster reward. Refer to revenue routing.\n\nFor the full list of ArbOwner methods, refer to the precompiles reference.How is this guide?Manage gas targetHow to manage your Arbitrum chain gas targetPriority feesHow to enable priority-fee (tip) collection on an Arbitrum chain in ArbOS61 'Elara', and the additional requirements for tip-based transaction ordering.","tokens":1201,"squid":"spider-01","role":"Chain Spider","at":1791346808399,"hash":"a1c1eb80816c6bd75509ba21e2539e29b562e81a"}
{"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":"spider-08","role":"Oracle Spider","at":1791346809960,"hash":"a45cc5fd602fc3c4348294d131a7505a33bae7db"}
{"url":"https://developer.arbitrum.io/how-arbitrum-works/deep-dives/gas-and-fees","domain":"developer.arbitrum.io","title":"Gas and fees","text":"Gas and feesLearn the fundamentals of how to calculate fees on Arbitrum, including parent chain pricing formulas and child chain gas mechanics.Request an update 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 's estimated contribution to its '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 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 , 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 . 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 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 , each paired with its own . 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 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 does, 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 , computed per 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.\n runs PGA and collects tips, sending 97% of the proceeds to the 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.How is this guide?Token bridgingDescribes how token bridging works on Arbitrum and the architecture of the token bridgeSTFLearn the fundamentals of the State Transition Function within Arbitrum Nitro.","tokens":6112,"squid":"spider-01","role":"Chain Spider","at":1791346818419,"hash":"dcdc585fae42068e91e6123394d47f678f2717e2"}
{"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":"spider-08","role":"Oracle Spider","at":1791346819740,"hash":"ba35af3bbd573b0897852b1aa86e70b62371351a"}
{"url":"https://www.metaplex.com/docs/api/create-launch","domain":"metaplex.com","title":"Metaplex API - Create Launch | REST API | Metaplex","text":"Build the on-chain transactions for a new Genesis token launch. Returns unsigned transactions that must be signed and sent before calling Register Launch. Use the SDK insteadMost integrators should use createAndRegisterLaunch from the SDK, which handles creating transactions, signing, sending, and registering the launch in a single call. This endpoint is only needed if you require direct HTTP access without the SDK.We recommend using the Create API to build launches programmatically, as metaplex.com does not yet support the full feature set of the Genesis program. Mainnet launches created through the API will appear on metaplex.com once registered.EndpointPOST /v1/launches/create\nRequest BodyFieldTypeRequiredDescriptionwalletstringYesCreator's wallet public keylaunchobjectYesFull launch configuration (see below)agentobjectNoLaunch on behalf of a registered agent (see Agent Launches)The request body also accepts includeBackendSigner, derivedSignerPublicKey, nonce, and buildAllTxs. These drive the signing flow used by metaplex.com itself; leave them unset when calling the API directly.Launch ConfigurationThe launch object describes the full token and launch setup:FieldTypeRequiredDescriptionnamestringYesToken name, 1–32 characterssymbolstringYesToken symbol, 1–10 charactersimagestringYesToken image URL (Irys gateway)descriptionstringNoToken description, max 250 charactersdecimalsnumberNoToken decimals, 1–9 (defaults to 6). A new launchpool token must use 6, and an existing token must match its on-chain mintsupplynumberNoTotal token supply (defaults to 1,000,000,000)networkstringNo'solana-mainnet' (default) or 'solana-devnet'quoteMintstringNoQuote token mint address (defaults to wrapped SOL)typestringYesLaunch type (see Launch Types)finalizebooleanNoWhether to finalize the launch (defaults to true)allocationsarrayYesArray of allocation configurationsexternalLinksobjectNoWebsite, Twitter, Telegram linkspublicKeystringYesCreator's wallet public key (must match the top-level wallet field)useExistingTokenbooleanNoLaunch an existing SPL token instead of minting a new one (see Existing Tokens)mintAddressstringNoMint of the existing token. Required when useExistingToken is trueisMutablebooleanNoWhether the token metadata stays mutable (defaults to true)For a new token, the allocation supplies must add up to exactly supply. A new token with a supply other than the 1,000,000,000 default returns 403 unless custom supply is enabled for your account.Launch TypestypeDescriptionlaunchpoolProportional distribution pool. Allocations: a launchpoolV2, plus any unlockedV2 and claimScheduleV2 allocationspresaleFixed-price presale. Allocations, in order: a presaleV2, an unlockedV2, then any claimScheduleV2 allocationsbondingCurveBonding curve launch. Allocations: a bondingCurveV2. Fixed at 1,000,000,000 supply, 6 decimals, and a SOL quoteThe schema also defines auction and custom. auction is a placeholder that is not implemented yet, and custom is rejected by the public API with 400.Allocation TypesEach allocation in the allocations array has a type field, a name, a supply, and a configuration object keyed by the same type name:launchpoolV2 — Proportional distribution poolpresaleV2 — Fixed-price presalebondingCurveV2 — Bonding curve saleunlockedV2 — Unlocked tokens to a recipientclaimScheduleV2 — Tokens released to a recipient on a vesting schedule, with an optional cliffRaydium liquidity is configured as a fund flow on the sale allocation, not as its own allocation: a RaydiumLP flow creates a Raydium CPMM pool, and a RaydiumClmmLP flow creates a Raydium CLMM (concentrated liquidity) position. CLMM launches return 403 unless they are enabled for your account.Streamflow allocations are retiredThe earlier lockedV2 (Streamflow) allocation type is no longer accepted. Use claimScheduleV2 for locked and vesting allocations.Existing TokensSet useExistingToken: true and pass the token's mintAddress to launch a token you already minted. decimals must match the on-chain mint. Unlike a new token, the allocations may fund only part of the supply: their total must be greater than 0 and no more than supply, and the rest stays in the creator's wallet. Existing-token launches return 403 unless they are enabled for your account, and are not available for the bondingCurve type.Agent LaunchesPass agent to create the launch with a registered agent as its creator:FieldTypeRequiredDescriptionagent.mintstringYesThe agent's Core asset address. It must be owned by walletagent.setTokenbooleanYesWhether to set the launched token as the agent's tokenThe agent's asset signer wallet becomes the launch creator. Pass the same agent.mint to Register Launch.The SDK's buildCreateLaunchPayload function handles converting the simplified CreateLaunchInput into this full payload format. See the API Client docs.Example Request — Launch Pool Typecurl -X POST https://api.metaplex.com/v1/launches/create \\\n -H \"Content-Type: application/json\" \\\n -d '{\n \"wallet\": \"YourWalletPublicKey...\",\n \"launch\": {\n \"name\": \"My Token\",\n \"symbol\": \"MTK\",\n \"image\": \"https://gateway.irys.xyz/...\",\n \"decimals\": 6,\n \"supply\": 1000000000,\n \"network\": \"solana-devnet\",\n \"quoteMint\": \"So11111111111111111111111111111111111111112\",\n \"type\": \"launchpool\",\n \"finalize\": true,\n \"publicKey\": \"YourWalletPublicKey...\",\n \"allocations\": [...]\n }\n }'\nSuccess Response{\n \"success\": true,\n \"transactions\": [\n \"base64-encoded-transaction-1...\",\n \"base64-encoded-transaction-2...\"\n ],\n \"blockhash\": {\n \"blockhash\": \"...\",\n \"lastValidBlockHeight\": 123456789\n },\n \"mintAddress\": \"MintPublicKey...\",\n \"genesisAccount\": \"GenesisAccountPDA...\"\n}\nFieldTypeDescriptionsuccessbooleantrue on successtransactionsstring[]Base64-encoded serialized transactionsblockhashobjectBlockhash for transaction confirmationmintAddressstringThe token mint public keygenesisAccountstringThe genesis account PDA public keyError Response{\n \"success\": false,\n \"error\": \"Validation failed\",\n \"details\": [...]\n}\nFieldTypeDescriptionsuccessbooleanfalse on errorerrorstringError messagedetailsarray?Validation error details (when applicable)Error CodesCodeDescription400Invalid input or validation failure500Internal server errorRecommended: Use the SDKInstead of calling this endpoint directly, use createAndRegisterLaunch which handles the entire flow — creating transactions, signing, sending, and registering — in one call:createAndRegisterLaunch.ts1import {\n2 createAndRegisterLaunch,\n3 CreateLaunchInput,\n4 genesis,\n5} from '@metaplex-foundation/genesis'\n6import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n7import { keypairIdentity } from '@metaplex-foundation/umi'\n8\n9const umi = createUmi('https://api.mainnet-beta.solana.com')\n10 .use(genesis())\n11\n12// Use keypairIdentity to set a wallet when running server-side:\n13// umi.use(keypairIdentity(myKeypair))\n14\n15const input: CreateLaunchInput = {\n16 wallet: umi.identity.publicKey,\n17 token: {\n18 name: 'My Token',\n19 symbol: 'MTK',\n20 image: 'https://gateway.irys.xyz/...',\n21 },\n22 launchType: 'launchpool',\n23 launch: {\n24 launchpool: {\n25 tokenAllocation: 500_000_000,\n26 depositStartTime: new Date(Date.now() + 48 * 60 * 60 * 1000),\n27 raiseGoal: 250,\n28 raydiumLiquidityBps: 5000,\n29 fundsRecipient: umi.identity.publicKey,\n30 },\n31 },\n32}\n33\n34const result = await createAndRegisterLaunch(umi, {}, input)\n35console.log(`Launch live at: ${result.launch.link}`)\nSee API Client for the full SDK documentation including all three integration modes.","tokens":1873,"squid":"dotcat","role":"Tooling Spider","at":1791346826360,"hash":"c120b9da79a3c93fe74e29e61af5cf08c98dc958"}
{"url":"https://developer.arbitrum.io/how-arbitrum-works/deep-dives/sequencer-transaction-flow","domain":"developer.arbitrum.io","title":"Sequencer architecture and transaction flow","text":"Sequencer architecture and transaction flowA deep dive into how the Sequencer processes transactions end-to-end: the transaction queue, ordering, block creation timing, and the sequencer feed.Request an updateThis deep dive follows a through a single 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 '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 for real-time consumers, and the later posts the compressed sequence to the on the .\n 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 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 : 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 . Three exist, and a chain runs exactly one:\nPolicyWhat decides the orderWhere it runsArrival time at the SequencerThe default for a new Arbitrum chainPriority Gas Auctions (PGA)The each transaction paysArbitrum OneTimeboostAn auctioned , 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 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 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 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 . 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 (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 (transaction_streamer.go#L1307). Full nodes and feed relays consume the feed to give sub-second ; 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 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 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 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\nHow is this guide?Transaction lifecycleLearn how transactions are submitted and processed on Arbitrum, including sequencer and non-sequencer pathways.Token bridgingDescribes how token bridging works on Arbitrum and the architecture of the token bridge","tokens":4132,"squid":"spider-01","role":"Chain Spider","at":1791346829201,"hash":"3cfb76b44fc458ab4ffe51b56fcb1c876a1d7ef0"}
{"url":"https://developer.arbitrum.io/how-arbitrum-works/deep-dives/finality","domain":"developer.arbitrum.io","title":"Finality","text":"FinalityLearn the fundamentals of finality on Arbitrum.Request an updateFinality in systems refers to the point at which a becomes irreversible and is permanently included in the blockchain’s ledger. In Arbitrum’s 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\n: Provided by the real-time feed, offering immediate but provisional transaction confirmations.\n: Occurs when transactions are included in posted to and finalized on the , providing strong security assurances. Final settlement on the happens via confirmed by the .\n\nThis section explores the concepts of soft and , 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 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 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 ()Provisional ordering by the SequencerSub-secondParent-chain data finality (batch posted and finalized on )Transaction data is durably recorded and inherits the parent chain's consensus security~2 epochs, roughly 12–15 minutes (the defaults to referencing the L1 safe block)Full settlement ( confirmed) state is finalized and L2→L1 withdrawals can be executedA bounded under , on the order of days on mainnet\nThe Fast Feed publishes all transactions in a PGA roundOn , 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 . If the Sequencer refuses to include it, the user can call 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 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 ), ensuring transparency and verifiability. On , batch data is instead kept offchain by a , and only a 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 that backs this guarantee is described in .\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 , 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, depth, and which tag an indexer should wait on.\nThe Sequencer and censorship resistance — the real-time feed, batch posting, and the escape hatch.\nAssertions — how the Rollup protocol confirms state and completes final settlement.\nBoLD: a gentle introduction — the dispute protocol that bounds the challenge period.\nAnyTrust protocol — how a DAC and change the data availability guarantee.\nChild to parent chain messaging — the and why withdrawals wait for assertion confirmation.\nHow is this guide?AssertionsDeep dive information on assertions and how to make an assertion.Batch posterLearn the fundamentals of the Arbitrum batch poster.","tokens":2337,"squid":"spider-01","role":"Chain Spider","at":1791346839249,"hash":"73b26c1846de538698112b8211d2d8b781778862"}
{"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":"spider-08","role":"Oracle Spider","at":1791346839290,"hash":"dac736ec180f79e20f6bb61d2280c45c1b46e444"}
{"url":"https://docs.pyth.network/price-feeds/core/push-feeds/evm","domain":"docs.pyth.network","title":"on EVM | Pyth Developer Hub","text":"Pyth CorePush Feedson EVMList of Push Feeds on EVM networksThe following EVM chains have push feeds:\n\nAbstract Mainnet\nBase Mainnet\nBerachain Mainnet\nEthereum Mainnet\nHyperEVM Mainnet\nLinea Mainnet\nMonad Mainnet\nOptimism Mainnet\nSoneium Mainnet\nSonic Mainnet\n\nRequest Additional FeedsIf you would like to see additional feeds on this list, please fill in this\nform to signal your interest.\nAbstract Mainnet\nThe price feeds listed below are currently sponsored in Abstract mainnet.The Pro-compatible column shows whether each feed is already served by the upgraded Hermes endpoint for the Pyth Core upgrade. Feeds marked Available are already served by the upgraded Hermes. Not all Coming soon feeds are guaranteed to be migrated. If you rely on a specific feed, contact the team.Default:1 hour heartbeat / 1% price deviation(4)NamePrice Feed IdUpdate ParametersPro-compatibleWETH/USD1 hour heartbeat1% price deviationAvailableUSDT/USD1 hour heartbeat1% price deviationAvailableUSDC/USD1 hour heartbeat1% price deviationAvailablePENGU/USD1 hour heartbeat1% price deviationAvailable\nBase Mainnet\nThe price feeds listed below are currently sponsored in Base mainnet.The Pro-compatible column shows whether each feed is already served by the upgraded Hermes endpoint for the Pyth Core upgrade. Feeds marked Available are already served by the upgraded Hermes. Not all Coming soon feeds are guaranteed to be migrated. If you rely on a specific feed, contact the team.Default:1 hour heartbeat / 1% price deviation(8)NamePrice Feed IdUpdate ParametersPro-compatibleUSDC/USD1 hour heartbeat1% price deviationAvailableETH/USD1 hour heartbeat1% price deviationAvailableWETH/USD1 hour heartbeat1% price deviationAvailableCBETH/USD1 hour heartbeat1% price deviationAvailableWSTETH/USD1 hour heartbeat1% price deviationAvailableSUI/USD1 hour heartbeat1% price deviationAvailableXRP/USD1 hour heartbeat1% price deviationAvailableWEETH/USD1 hour heartbeat1% price deviationAvailable\nBerachain Mainnet\nThe price feeds listed below are currently sponsored in Berachain mainnet.The Pro-compatible column shows whether each feed is already served by the upgraded Hermes endpoint for the Pyth Core upgrade. Feeds marked Available are already served by the upgraded Hermes. Not all Coming soon feeds are guaranteed to be migrated. If you rely on a specific feed, contact the team.Default:1 hour heartbeat / 1% price deviation(9)NamePrice Feed IdUpdate ParametersPro-compatibleBERA/USD1 hour heartbeat1% price deviationAvailableBTC/USD1 hour heartbeat1% price deviationAvailableETH/USD1 hour heartbeat1% price deviationAvailableUSDC/USD1 hour heartbeat1% price deviationAvailableUSDT/USD1 hour heartbeat1% price deviationAvailablePYUSD/USD1 hour heartbeat1% price deviationAvailableSUSDE/USDE.RR1 hour heartbeat1% price deviationAvailableHONEY/USD1 hour heartbeat1% price deviationComing soonHONEY/USD.RR1 hour heartbeat1% price deviationComing soon\nEthereum Mainnet\nThe price feeds listed below are currently sponsored in Ethereum mainnet.The Pro-compatible column shows whether each feed is already served by the upgraded Hermes endpoint for the Pyth Core upgrade. Feeds marked Available are already served by the upgraded Hermes. Not all Coming soon feeds are guaranteed to be migrated. If you rely on a specific feed, contact the team.Default:1 hour heartbeat / 1% price deviation(2)Exception:1 hour heartbeat / 2% price deviation(1)Exception:1 hour heartbeat / 0.5% price deviation(1)NamePrice Feed IdUpdate ParametersPro-compatibleUSDC/USD1 hour heartbeat2% price deviationAvailableLINEA/USD1 hour heartbeat1% price deviationAvailableBOLD/USD1 hour heartbeat0.5% price deviationComing soonSPYX/USD1 hour heartbeat1% price deviationAvailable\nHyperEVM Mainnet\nThe price feeds listed below are currently sponsored in HyperEVM mainnet.The Pro-compatible column shows whether each feed is already served by the upgraded Hermes endpoint for the Pyth Core upgrade. Feeds marked Available are already served by the upgraded Hermes. Not all Coming soon feeds are guaranteed to be migrated. If you rely on a specific feed, contact the team.Default:1 hour heartbeat / 1% price deviation(40)Exception:1 hour heartbeat / 5% price deviation(2)Exception:1 hour heartbeat / 2% price deviation(1)NamePrice Feed IdUpdate ParametersPro-compatibleBTC/USD1 hour heartbeat1% price deviationAvailableETH/USD1 hour heartbeat1% price deviationAvailableUSDC/USD1 hour heartbeat1% price deviationAvailableUSDT/USD1 hour heartbeat1% price deviationAvailableHYPE/USD1 hour heartbeat1% price deviationAvailableWSTETH/USD1 hour heartbeat1% price deviationAvailableWSTETH/STETH.RR1 hour heartbeat1% price deviationAvailableUSH/USD1 hour heartbeat5% price deviationComing soonWBTC/USD1 hour heartbeat1% price deviationAvailableWETH/USD1 hour heartbeat1% price deviationAvailableUSDE/USD1 hour heartbeat1% price deviationAvailableSUSDE/USD1 hour heartbeat1% price deviationAvailableSUSDE/USDE.RR1 hour heartbeat1% price deviationAvailableWSTHYPE/STHYPE.RR1 hour heartbeat1% price deviationComing soonLHYPE/USD1 hour heartbeat1% price deviationComing soonFHYPE/HYPE.RR1 hour heartbeat1% price deviationComing soonUSDXL/USD1 hour heartbeat1% price deviationComing soonMHYPE/HYPE.RR1 hour heartbeat1% price deviationComing soonFEUSD/USD1 hour heartbeat1% price deviationComing soonMHYPE/USD1 hour heartbeat2% price deviationComing soonSTHYPE/USD1 hour heartbeat1% price deviationComing soonUETH/USD1 hour heartbeat1% price deviationAvailableUBTC/USD1 hour heartbeat1% price deviationAvailableCMETH/METH.RR1 hour heartbeat1% price deviationComing soonMETH/ETH.RR1 hour heartbeat1% price deviationComing soonUSOL/USD1 hour heartbeat1% price deviationAvailableXAU/USD1 hour heartbeat1% price deviationAvailableUSDHL/USD1 hour heartbeat1% price deviationComing soonUFART/USD1 hour heartbeat1% price deviationComing soonHWHLP/USDC1 hour heartbeat1% price deviationComing soonWHLP/USDC1 hour heartbeat1% price deviationComing soonSTLOOP/LOOP1 hour heartbeat1% price deviationComing soonHLP0/USDC.RR1 hour heartbeat1% price deviationComing soonKHYPE/HYPE.RR1 hour heartbeat1% price deviationAvailableKHYPE/USD1 hour heartbeat1% price deviationAvailableHAHYPE/HYPE.RR1 hour heartbeat1% price deviationComing soonAPE/USD1 hour heartbeat1% price deviationAvailableUSDH/USD1 hour heartbeat1% price deviationAvailableUSDT0/USD1 hour heartbeat1% price deviationAvailableUSDN/USD1 hour heartbeat5% price deviationComing soonHWUSD/USDC.RR1 hour heartbeat1% price deviationComing soonUSDG/USD1 hour heartbeat1% price deviationAvailableTHBILL/USDC.RR1 hour heartbeat1% price deviationComing soon\nLinea Mainnet\nThe price feeds listed below are currently sponsored in Linea mainnet.The Pro-compatible column shows whether each feed is already served by the upgraded Hermes endpoint for the Pyth Core upgrade. Feeds marked Available are already served by the upgraded Hermes. Not all Coming soon feeds are guaranteed to be migrated. If you rely on a specific feed, contact the team.Default:1 hour heartbeat / 1% price deviation(1)NamePrice Feed IdUpdate ParametersPro-compatibleLINEA/USD1 hour heartbeat1% price deviationAvailable\nMonad Mainnet\nThe price feeds listed below are currently sponsored in Monad mainnet.The Pro-compatible column shows whether each feed is already served by the upgraded Hermes endpoint for the Pyth Core upgrade. Feeds marked Available are already served by the upgraded Hermes. Not all Coming soon feeds are guaranteed to be migrated. If you rely on a specific feed, contact the team.Default:1 hour heartbeat / 0.2% price deviation(56)Exception:1 hour heartbeat / 0.1% price deviation(4)NamePrice Feed IdUpdate ParametersPro-compatibleBTC/USD1 hour heartbeat0.1% price deviationAvailableETH/USD1 hour heartbeat0.1% price deviationAvailableMON/USD1 hour heartbeat0.1% price deviationAvailableSOL/USD1 hour heartbeat0.1% price deviationAvailableUSDC/USD1 hour heartbeat0.2% price deviationAvailableUSDT/USD1 hour heartbeat0.2% price deviationAvailableWBTC/USD1 hour heartbeat0.2% price deviationAvailableWETH/USD1 hour heartbeat0.2% price deviationAvailableWSTETH/USD1 hour heartbeat0.2% price deviationAvailableWSTETH/STETH.RR1 hour heartbeat0.2% price deviationAvailableSTETH/ETH.RR1 hour heartbeat0.2% price deviationAvailableSUI/USD1 hour heartbeat0.2% price deviationAvailableHYPE/USD1 hour heartbeat0.2% price deviationAvailableSUSDE/USD1 hour heartbeat0.2% price deviationAvailableSUSDE/USDE.RR1 hour heartbeat0.2% price deviationAvailableUSDE/USD1 hour heartbeat0.2% price deviationAvailableUSDY/USD1 hour heartbeat0.2% price deviationAvailablePYUSD/USD1 hour heartbeat0.2% price deviationAvailableDAI/USD1 hour heartbeat0.2% price deviationAvailableUSDS/USD1 hour heartbeat0.2% price deviationAvailableSUSDS/USDS.RR1 hour heartbeat0.2% price deviationAvailableFDUSD/USD1 hour heartbeat0.2% price deviationAvailableLBTC/USD1 hour heartbeat0.2% price deviationAvailableSOLVBTC/USD1 hour heartbeat0.2% price deviationComing soonCBBTC/USD1 hour heartbeat0.2% price deviationAvailableWEETH/USD1 hour heartbeat0.2% price deviationAvailableRSETH/USD1 hour heartbeat0.2% price deviationAvailableEZETH/USD1 hour heartbeat0.2% price deviationComing soonWEETH/EETH.RR1 hour heartbeat0.2% price deviationAvailableRSETH/ETH.RR1 hour heartbeat0.2% price deviationComing soonXAU/USD1 hour heartbeat0.2% price deviationAvailableXAG/USD1 hour heartbeat0.2% price deviationAvailableXRP/USD1 hour heartbeat0.2% price deviationAvailableBNB/USD1 hour heartbeat0.2% price deviationAvailableADA/USD1 hour heartbeat0.2% price deviationAvailableAPT/USD1 hour heartbeat0.2% price deviationAvailableSEI/USD1 hour heartbeat0.2% price deviationAvailableAVAX/USD1 hour heartbeat0.2% price deviationAvailableTIA/USD1 hour heartbeat0.2% price deviationAvailablePOL/USD1 hour heartbeat0.2% price deviationAvailableBERA/USD1 hour heartbeat0.2% price deviationAvailableS/USD1 hour heartbeat0.2% price deviationAvailableDOGE/USD1 hour heartbeat0.2% price deviationAvailableOP/USD1 hour heartbeat0.2% price deviationAvailableARB/USD1 hour heartbeat0.2% price deviationAvailableEBTC/USD1 hour heartbeat0.2% price deviationComing soonSTONE/ETH.RR1 hour heartbeat0.2% price deviationComing soonETHX/ETH.RR1 hour heartbeat0.2% price deviationComing soonPYTH/USD1 hour heartbeat0.2% price deviationAvailableCAKE/USD1 hour heartbeat0.2% price deviationAvailableLINK/USD1 hour heartbeat0.2% price deviationAvailableUNI/USD1 hour heartbeat0.2% price deviationAvailableAAVE/USD1 hour heartbeat0.2% price deviationAvailableRED/USD1 hour heartbeat0.2% price deviationAvailableW/USD1 hour heartbeat0.2% price deviationAvailableAXL/USD1 hour heartbeat0.2% price deviationAvailableZRO/USD1 hour heartbeat0.2% price deviationAvailableSTG/USD1 hour heartbeat0.2% price deviationComing soonAUSD/USD1 hour heartbeat0.2% price deviationAvailableSMON/MON.RR1 hour heartbeat0.2% price deviationComing soon\nOptimism Mainnet\nThe price feeds listed below are currently sponsored in Optimism mainnet.The Pro-compatible column shows whether each feed is already served by the upgraded Hermes endpoint for the Pyth Core upgrade. Feeds marked Available are already served by the upgraded Hermes. Not all Coming soon feeds are guaranteed to be migrated. If you rely on a specific feed, contact the team.Default:1 hour heartbeat / 1% price deviation(5)NamePrice Feed IdUpdate ParametersPro-compatibleSETHFI/ETHFI.RR1 hour heartbeat1% price deviationAvailableETHFI/USD1 hour heartbeat1% price deviationAvailableBEHYPE/HYPE.RR1 hour heartbeat1% price deviationAvailableHYPE/USD1 hour heartbeat1% price deviationAvailableEURC/USD1 hour heartbeat1% price deviationAvailable\nSoneium Mainnet\nThe price feeds listed below are currently sponsored in Soneium mainnet.The Pro-compatible column shows whether each feed is already served by the upgraded Hermes endpoint for the Pyth Core upgrade. Feeds marked Available are already served by the upgraded Hermes. Not all Coming soon feeds are guaranteed to be migrated. If you rely on a specific feed, contact the team.Default:1 hour heartbeat / 1% price deviation(7)NamePrice Feed IdUpdate ParametersPro-compatibleASTR/USD1 hour heartbeat1% price deviationAvailableBTC/USD1 hour heartbeat1% price deviationAvailableETH/USD1 hour heartbeat1% price deviationAvailableSOLVBTC/BTC.RR1 hour heartbeat1% price deviationAvailableUSDC/USD1 hour heartbeat1% price deviationAvailableUSDT/USD1 hour heartbeat1% price deviationAvailableWSTETH/USD1 hour heartbeat1% price deviationAvailable\nSonic Mainnet\nThe price feeds listed below are currently sponsored in Sonic mainnet.The Pro-compatible column shows whether each feed is already served by the upgraded Hermes endpoint for the Pyth Core upgrade. Feeds marked Available are already served by the upgraded Hermes. Not all Coming soon feeds are guaranteed to be migrated. If you rely on a specific feed, contact the team.Default:1 hour heartbeat / 1% price deviation(11)NamePrice Feed IdUpdate ParametersPro-compatibleUSDC/USD1 hour heartbeat1% price deviationAvailableETH/USD1 hour heartbeat1% price deviationAvailableWETH/USD1 hour heartbeat1% price deviationAvailableWBTC/USD1 hour heartbeat1% price deviationAvailableBTC/USD1 hour heartbeat1% price deviationAvailableUSDT/USD1 hour heartbeat1% price deviationAvailableS/USD1 hour heartbeat1% price deviationAvailableSTS/S.RR1 hour heartbeat1% price deviationComing soonANON/USD1 hour heartbeat1% price deviationComing soonSTS/USD1 hour heartbeat1% price deviationComing soonHLP0/USDC.RR1 hour heartbeat1% price deviationComing soonHIP-3 as a ServicePrevious Pageon SolanaList of Push Feeds on Solana","tokens":3407,"squid":"spider-08","role":"Oracle Spider","at":1791346849142,"hash":"52e435e168353a03ddb8c2b1fc788e34941b933b"}
{"url":"https://developer.arbitrum.io/launch-arbitrum-chain/chain-config/costs/fee-management","domain":"developer.arbitrum.io","title":"How to manage the fee parameters of your Arbitrum chain","text":"Configure your chainCostsHow to manage the fee parameters of your Arbitrum chainLearn how to manage the fee parameters of your Arbitrum chainRequest an updateDifferent fees get collected for every as part of an activity. These fees are collected as a single amount (the transaction fees) but split internally into different components depending on their purpose. Each component is transferrable to a different fee collector address that is configurable on your chain.\nThis guide describes the different collected fees and explains how to specify the fee collector address on your chain for each fee type.\nThis guide describes the different fees collected on your chain, how to configure them, and how to specify the fee collector address for each type.\nWhat fees are collected on an Arbitrum chain?\nThere are four fee types that are collected on every transaction of an Arbitrum chain:\n\nArbitrum chain base fee: fees paid for executing the transaction on the chain based on the minimum base price configured.\n\nArbitrum chain surplus fee: if the chain is congested (i.e., the base price paid for the transaction is higher than the minimum base price), these fees account for executing the transaction on the chain based on any gas price paid above the minimum base price configured.\n\nParent chain base fee: relative fees paid for posting the transaction on the . This amount is calculated based on the transaction's estimated size and the current view of the parent chain's base fee.\n\nParent chain surplus fee: if configured, these are extra fees rewarded to the Batch Poster.\n\nYou can find more detailed information about these fee types in these pages:\n\nL2 fees for the Arbitrum chain base fee and surplus fee\nL1 fees for the Parent chain base fee and surplus fee\n\nHow to configure the fees collected?\nLet's see in what ways we can configure each fee type:\nArbitrum chain base fee (minimum)\nYour chain is configured with a minimum base fee for execution. This value can be obtained by calling the method getMinimumGasPrice()(uint256) of the ArbGasInfo precompile.\ncast call --rpc-url $ORBIT_CHAIN_RPC 0x000000000000000000000000000000000000006C \"getMinimumGasPrice() (uint256)\"\nAlternatively, you can use the Chain SDK to retrieve the minimum Arbitrum chain base fee configured:\nconst orbitChainClient = createPublicClient({\n chain: <OrbitChainDefinition>,\n transport: http(),\n}).extend(arbGasInfoPublicActions);\n\nconst orbitMinimumBaseFee = await orbitChainClient.arbGasInfoReadContract({\n functionName: 'getMinimumGasPrice',\n});\nNoteThis minimum base fee defines the minimum value that the chain's base fee can have. However, in periods of congestion, the actual base fee might be higher than this minimum. Check the next section \"Arbitrum chain surplus fee\" for more information.\nTo set a new minimum base fee, use the method setMinimumL2BaseFee(uint256) of the ArbOwner precompile, and pass the new minimum base fee in wei. For example:\ncast send --rpc-url $ORBIT_CHAIN_RPC --private-key $OWNER_PRIVATE_KEY 0x0000000000000000000000000000000000000070 \"setMinimumL2BaseFee(uint256) ()\" $NEW_MINIMUM_BASE_FEE_IN_WEI\nOr using the Chain SDK:\nconst owner = privateKeyToAccount(<OwnerPrivateKey>);\nconst orbitChainClient = createPublicClient({\n chain: <OrbitChainDefinition>,\n transport: http(),\n}).extend(arbOwnerPublicActions);\n\nconst transactionRequest = await orbitChainClient.arbOwnerPrepareTransactionRequest({\n functionName: 'setMinimumL2BaseFee',\n args: [<NewMinimumBaseFeeInWei>],\n upgradeExecutor: false,\n account: owner.address,\n});\n\nawait orbitChainClient.sendRawTransaction({\n serializedTransaction: await owner.signTransaction(transactionRequest),\n});\nArbitrum chain surplus fee\nIn periods of congestion, the actual base fee of your Arbitrum chain might be higher than the configured minimum. You can see the current base fee of your chain by calling the method getPricesInWei()(uint256,uint256,uint256,uint256,uint256,uint256) of the ArbGasInfo precompile, and check the last result of the returned tuple.\ncast call --rpc-url $ORBIT_CHAIN_RPC 0x000000000000000000000000000000000000006C \"getPricesInWei() (uint256,uint256,uint256,uint256,uint256,uint256)\"\nYou can then calculate the current Arbitrum chain surplus fees as currentBaseFee - minimumBaseFee.\nNotegetPricesInWei() also returns the correspondent fees due to congestion in the second-to-last result of the returned tuple.\nArbitrum chain surplus fees are automatically adjustedArbitrum chains automatically adjust the Arbitrum chain surplus fee based on the traffic of the chain. If the gas consumed goes over the , the chain's base fee will start increasing. Likewise, the base fee will gradually go down if demand of gas returns to below the configured gas target, until it reaches the minimum base fee configured.\nParent chain base fee\nTo obtain the current parent chain base fee of your chain, you can call the method getL1BaseFeeEstimate()(uint256) of the ArbGasInfo precompile.\ncast call --rpc-url $ORBIT_CHAIN_RPC 0x000000000000000000000000000000000000006C \"getL1BaseFeeEstimate() (uint256)\"\nAlternatively, you can use the Chain SDK to retrieve the current parent chain base fee:\nconst orbitChainClient = createPublicClient({\n chain: <OrbitChainDefinition>,\n transport: http(),\n}).extend(arbGasInfoPublicActions);\n\nconst parentChainBaseFee = await orbitChainClient.arbGasInfoReadContract({\n functionName: 'getL1BaseFeeEstimate',\n});\nYou can modify the current estimate of the parent chain base fee by calling the method setL1PricePerUnit(uint256) of the ArbOwner precompile. For example:\ncast send --rpc-url $ORBIT_CHAIN_RPC --private-key $OWNER_PRIVATE_KEY 0x0000000000000000000000000000000000000070 \"setL1PricePerUnit(uint256) ()\" $NEW_PARENT_CHAIN_BASE_FEE\nOr using the Chain SDK:\nconst owner = privateKeyToAccount(<OwnerPrivateKey>);\nconst orbitChainClient = createPublicClient({\n chain: <OrbitChainDefinition>,\n transport: http(),\n}).extend(arbOwnerPublicActions);\n\nconst transactionRequest = await orbitChainClient.arbOwnerPrepareTransactionRequest({\n functionName: 'setL1PricePerUnit',\n args: [<NewParentChainBaseFee>],\n upgradeExecutor: false,\n account: owner.address,\n});\n\nawait orbitChainClient.sendRawTransaction({\n serializedTransaction: await owner.signTransaction(transactionRequest),\n});\nParent chain base fees are automatically adjustedArbitrum chains are configured to automatically adjust the current parent chain base fee estimation based on the batch poster reports sent from the parent chain. That means that even though you can set a new parent chain base fee, the chain will automatically adjust it based on the reports received afterwards.\nParent chain base fee configuration for chains using a custom gas tokenArbitrum chains that use a custom gas token should have their parent chain base fees disabled (set to 0), to avoid charging users for a non-existent parent chain's base fee, as explained in How to use a custom gas token.\nParent chain surplus fee\nThe parent chain surplus fee collected is based on a reward rate configured in the chain. To obtain this parameter, you can call the method getL1RewardRate()(uint64) of the ArbGasInfo precompile. This function will return the amount of wei per gas unit paid to the appropriate fee collector. For example:\ncast call --rpc-url $ORBIT_CHAIN_RPC 0x000000000000000000000000000000000000006C \"getL1RewardRate() (uint64)\"\nAlternatively, you can obtain this information using the Chain SDK:\nconst orbitChainClient = createPublicClient({\n chain: <OrbitChainDefinition>,\n transport: http(),\n}).extend(arbGasInfoPublicActions);\n\nconst parentChainRewardRate = await orbitChainClient.arbGasInfoReadContract({\n functionName: 'getL1RewardRate',\n});\nTo change the reward rate, you can use the method setL1PricingRewardRate(uint64) of the ArbOwner precompile and pass the amount of wei per gas unit to reward. For example:\ncast send --rpc-url $ORBIT_CHAIN_RPC --private-key $OWNER_PRIVATE_KEY 0x0000000000000000000000000000000000000070 \"setL1PricingRewardRate(uint64) ()\" $NEW_REWARD_RATE\nOr using the Chain SDK:\nconst owner = privateKeyToAccount(<OwnerPrivateKey>);\nconst orbitChainClient = createPublicClient({\n chain: <OrbitChainDefinition>,\n transport: http(),\n}).extend(arbOwnerPublicActions);\n\nconst transactionRequest = await orbitChainClient.arbOwnerPrepareTransactionRequest({\n functionName: 'setL1PricingRewardRate',\n args: [<NewRewardRate>],\n upgradeExecutor: false,\n account: owner.address,\n});\n\nawait orbitChainClient.sendRawTransaction({\n serializedTransaction: await owner.signTransaction(transactionRequest),\n});\nHow to configure the fee collector addresses?\nLet's now look at how to configure the collector addresses for each fee type.\nArbitrum chain base fee\nArbitrum chain base fees are paid to the infraFeeAccount configured in your chain. You can retrieve the current configured address by calling the method getInfraFeeAccount()(address) of the ArbOwnerPublic precompile. For example:\ncast call --rpc-url $ORBIT_CHAIN_RPC 0x000000000000000000000000000000000000006B \"getInfraFeeAccount() (address)\"\nNoteThe ArbOwner precompile also has a getInfraFeeAccount()(address) method that can be used, but only by the owner of the chain.\nAlternatively, you can use the Chain SDK to retrieve the current address configured as infraFeeAccount:\nconst orbitChainClient = createPublicClient({\n chain: <OrbitChainDefinition>,\n transport: http(),\n}).extend(arbOwnerPublicActions);\n\nconst infraFeeAccount = await orbitChainClient.arbOwnerReadContract({\n functionName: 'getInfraFeeAccount',\n});\nTo set a new infraFeeAccount, use the method setInfraFeeAccount(address) of the ArbOwner precompile. For example:\ncast send --rpc-url $ORBIT_CHAIN_RPC --private-key $OWNER_PRIVATE_KEY 0x0000000000000000000000000000000000000070 \"setInfraFeeAccount(address) ()\" $NEW_INFRAFEEACCOUNT_ADDRESS\nOr using the Chain SDK:\nconst owner = privateKeyToAccount(<OwnerPrivateKey>);\nconst orbitChainClient = createPublicClient({\n chain: <OrbitChainDefinition>,\n transport: http(),\n}).extend(arbOwnerPublicActions);\n\nconst transactionRequest = await orbitChainClient.arbOwnerPrepareTransactionRequest({\n functionName: 'setInfraFeeAccount',\n args: [<NewInfraFeeAccountAddress>],\n upgradeExecutor: false,\n account: owner.address,\n});\n\nawait orbitChainClient.sendRawTransaction({\n serializedTransaction: await owner.signTransaction(transactionRequest),\n});\nArbitrum chain surplus fee\nArbitrum chain surplus fees are paid to the networkFeeAccount configured in your chain. You can retrieve the current configured address by calling the method getNetworkFeeAccount()(address) of the ArbOwnerPublic precompile. For example:\ncast call --rpc-url $ORBIT_CHAIN_RPC 0x000000000000000000000000000000000000006B \"getNetworkFeeAccount() (address)\"\nNoteThe ArbOwner precompile also has a getNetworkFeeAccount()(address) method that can be used, but only by the owner of the chain.\nAlternatively, you can use the Chain SDK to retrieve the current address configured as networkFeeAccount:\nconst orbitChainClient = createPublicClient({\n chain: <OrbitChainDefinition>,\n transport: http(),\n}).extend(arbOwnerPublicActions);\n\nconst networkFeeAccount = await orbitChainClient.arbOwnerReadContract({\n functionName: 'getNetworkFeeAccount',\n});\nTo set a new networkFeeAccount, use the method setNetworkFeeAccount(address) of the ArbOwner precompile. For example:\ncast send --rpc-url $ORBIT_CHAIN_RPC --private-key $OWNER_PRIVATE_KEY 0x0000000000000000000000000000000000000070 \"setNetworkFeeAccount(address) ()\" $NEW_NETWORKFEEACCOUNT_ADDRESS\nOr using the Chain SDK:\nconst owner = privateKeyToAccount(<OwnerPrivateKey>);\nconst orbitChainClient = createPublicClient({\n chain: <OrbitChainDefinition>,\n transport: http(),\n}).extend(arbOwnerPublicActions);\n\nconst transactionRequest = await orbitChainClient.arbOwnerPrepareTransactionRequest({\n functionName: 'setNetworkFeeAccount',\n args: [<NewNetworkFeeAccountAddress>],\n upgradeExecutor: false,\n account: owner.address,\n});\n\nawait orbitChainClient.sendRawTransaction({\n serializedTransaction: await owner.signTransaction(transactionRequest),\n});\nParent chain base fee\nParent chain base fees are paid to the fee collector of the active batch poster configured in your chain.\nGetting batch posters\nThe recommended way to get the current configured batch posters is to use the Chain SDK to query the SequencerInbox contract on the parent chain. This method reads from events emitted when configuring a new batch poster:\nconst parentChainClient = createPublicClient({\n chain: <ParentChainDefinition>,\n transport: http(),\n});\n\nconst batchPosters = await getBatchPosters(parentChainClient, {\n rollup: rollupAddress,\n sequencerInbox: sequencerInboxAddress,\n});\nAlternatively, you can verify a specific address directly by checking the isBatchPoster mapping in the SequencerInbox contract on the parent chain:\ncast call --rpc-url $PARENT_CHAIN_RPC $SEQUENCER_INBOX_ADDRESS \"isBatchPoster(address) (bool)\" $BATCH_POSTER_ADDRESS\nAlternative method using ArbAggregator:\nYou can also query batch posters by calling the getBatchPosters()(address[]) method of the ArbAggregator precompile on your Arbitrum chain:\ncast call --rpc-url $ORBIT_CHAIN_RPC 0x000000000000000000000000000000000000006D \"getBatchPosters() (address[])\"\nWarningThe list returned by ArbAggregator.getBatchPosters() may be incomplete. It only includes:\nAddresses that have been manually added via addBatchPoster()\nAddresses that have successfully posted at least one batch\nThis method is primarily used for fee management purposes, not for authoritative permission verification. Always verify batch poster permissions against the SequencerInbox contract on the parent chain.\nManaging fee collectors\nOnce you have the batch poster address, you can obtain the fee collector address configured for that batch poster by calling the method getFeeCollector(address)(address) of the ArbAggregator precompile:\ncast call --rpc-url $ORBIT_CHAIN_RPC 0x000000000000000000000000000000000000006D \"getFeeCollector(address) (address)\" $BATCH_POSTER_ADDRESS\nYou can also use the Chain SDK:\nconst orbitChainClient = createPublicClient({\n chain: <OrbitChainDefinition>,\n transport: http(),\n}).extend(arbAggregatorActions);\n\nconst networkFeeAccount = await orbitChainClient.arbAggregatorReadContract({\n functionName: 'getFeeCollector',\n args: [<BatchPosterAddress>],\n});\nSetting a fee collector\nNoteBefore calling ArbAggregator.setFeeCollector(), you must ensure the batch poster address is already registered in the BatchPostersTable. This is done either by:\nManually calling ArbAggregator.addBatchPoster() for the address, or\nThe address having successfully posted at least one batch\n\nTo set a new fee collector for a specific batch poster, use the method setFeeCollector(address, address) of the ArbAggregator precompile:\ncast send --rpc-url $ORBIT_CHAIN_RPC --private-key $OWNER_PRIVATE_KEY 0x000000000000000000000000000000000000006D \"setFeeCollector(address,address) ()\" $BATCH_POSTER_ADDRESS $NEW_FEECOLLECTOR_ADDRESS\nOr using the Chain SDK:\nconst owner = privateKeyToAccount(<OwnerPrivateKey>);\nconst orbitChainClient = createPublicClient({\n chain: <OrbitChainDefinition>,\n transport: http(),\n}).extend(arbAggregatorActions);\n\nconst transactionRequest = await orbitChainClient.arbAggregatorPrepareTransactionRequest({\n functionName: 'setFeeCollector',\n args: [<BatchPosterAddress>, <NewFeeCollectorAddress>],\n upgradeExecutor: false,\n account: owner.address,\n});\n\nawait orbitChainClient.sendRawTransaction({\n serializedTransaction: await owner.signTransaction(transactionRequest),\n});\nAdding a new batch poster\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\nOptional: Pre-register for fee management\nIf you want to configure a fee collector before the batch poster sends its first batch, you can optionally pre-register the address on the Arbitrum chain by calling addBatchPoster(address) of the ArbAggregator precompile:\ncast send --rpc-url $ORBIT_CHAIN_RPC --private-key $OWNER_PRIVATE_KEY 0x000000000000000000000000000000000000006D \"addBatchPoster(address) ()\" $NEW_BATCH_POSTER_ADDRESS\nNoteWhen setting a new batch poster, its fee collector will be configured to the same address by default.\nParent chain surplus fee\nParent chain surplus fees are paid to a specific L1RewardRecipient address that is configured individually per chain. The current fee collector address can be obtained by calling the method getL1RewardRecipient()(address) of the ArbGasInfo precompile. For example:\ncast call --rpc-url $ORBIT_CHAIN_RPC 0x000000000000000000000000000000000000006C \"getL1RewardRecipient() (address)\"\nAlternatively, you can obtain this information using the Chain SDK:\nconst orbitChainClient = createPublicClient({\n chain: <OrbitChainDefinition>,\n transport: http(),\n}).extend(arbGasInfoPublicActions);\n\nconst parentChainRewardRecipient = await orbitChainClient.arbGasInfoReadContract({\n functionName: 'getL1RewardRecipient',\n});\nTo set a new L1RewardRecipient address, you can call the method setL1PricingRewardRecipient(address) of the ArbOwner precompile, and pass the address of the new reward recipient. For example:\ncast send --rpc-url $ORBIT_CHAIN_RPC --private-key $OWNER_PRIVATE_KEY 0x0000000000000000000000000000000000000070 \"setL1PricingRewardRecipient(address) ()\" $NEW_L1REWARDRECIPIENT_ADDRESS\nAlternatively, you can use the Chain SDK to set the new address:\nconst owner = privateKeyToAccount(<OwnerPrivateKey>);\nconst orbitChainClient = createPublicClient({\n chain: <OrbitChainDefinition>,\n transport: http(),\n}).extend(arbOwnerPublicActions);\n\nconst transactionRequest = await orbitChainClient.arbOwnerPrepareTransactionRequest({\n functionName: 'setL1PricingRewardRecipient',\n args: [<NewL1RewardRecipientAddress>],\n upgradeExecutor: false,\n account: owner.address,\n});\n\nawait orbitChainClient.sendRawTransaction({\n serializedTransaction: await owner.signTransaction(transactionRequest),\n});\nHow to use the fee distribution contracts?\nIn the previous section we described how to set the individual collector addresses for each fee type. Some chains may require multiple addresses to receive the collected fees of any of the available types. In those cases, there's the possibility of using a distributor contract that can gather all fees of a specific type and distribute those among multiple addresses.\nThis section shows how to configure a distributor contract to manage the fees of a specific type.\nExample scripts available in the Chain SDKThis section will explain the process of deploying and configuring a distribution contract manually, but the Chain SDK includes an example to perform this process through a script.\nStep 1. Deploy the distributor contract\nAn example implementation of a distributor contract can be found in the fund-distribution-contracts repo. You'll have to deploy this contract on your Arbitrum chain.\nStep 2. Set the contract address as the desired fee type collector address\nUse the instructions provided in the previous section to set the address of the deployed distributor contract as the collector of the desired fee type. For example, if you want the distributor contract to manage the Arbitrum chain surplus fees, set the networkFeeAccount to the address of the deployed contract.\nStep 3. Configure the recipients of fees in the contract\nNow you can set the different addresses that will be receiving fees from that distributor contract. To do that, you can call the method setRecipients(address[], uint256[]) of the distributor contract, and specify the list of addresses that will be receiving fees, and the proportion of fees for each address.\nFor example, if you want to set two addresses as receivers, with the first one receiving 80% of the fees and the second one receiving 20% of the fees, you'll use the following parameters:\ncast send --rpc-url $ORBIT_CHAIN_RPC --private-key $OWNER_PRIVATE_KEY $DISTRIBUTOR_CONTRACT_ADDRESS \"setRecipients(address[],uint256[]) ()\" \"[$RECEIVER_1, $RECEIVER_2]\" \"[8000, 2000]\"\nStep 4. Trigger the distribution of fees\nWith the recipients configured in the distributor contract, and with the contract having collected some fees, you can now trigger the distribution of fees to the recipients by using the method distributeRewards(address[], uint256[]) of the distributor contract, and specifying the list of addresses that are configured, and the proportion of fees for each address. The parameters passed must match the information that is set in the contract (i.e., you can't specify different addresses or proportions than what's been configured beforehand).\nFor example, if you want to distribute the fees to the two addresses specified before, you'll use the following parameters:\ncast send --rpc-url $ORBIT_CHAIN_RPC --private-key $OWNER_PRIVATE_KEY $DISTRIBUTOR_CONTRACT_ADDRESS \"distributeRewards(address[],uint256[]) ()\" \"[$RECEIVER_1, $RECEIVER_2]\" \"[8000, 2000]\"How is this guide?Dynamic Pricing for Arbitrum chainsGuidance & best practices for using Dynamic Pricing on Arbitrum chainsRevenue routingLearn how transaction fees flow through an Arbitrum chain: which addresses collect each fee component, when funds actually move, and how to withdraw revenue to the parent chain","tokens":5352,"squid":"spider-01","role":"Chain Spider","at":1791346849283,"hash":"d282062b77f33afef84ed5146cb92932f87acb86"}
{"url":"https://docs.pyth.network/price-feeds/core/push-feeds/fogo","domain":"docs.pyth.network","title":"on Fogo | Pyth Developer Hub","text":"Pyth CorePush Feedson FogoList of Push Feeds on FogoRequest Additional FeedsIf you would like to see additional feeds on this list, please fill in this\nform to signal your interest.\nFogo Mainnet\nThe price feeds listed below are currently sponsored in Fogo mainnet.Default:1 minute heartbeat / 0.5% price deviation(8)NameAccount AddressPrice Feed IdUpdate ParametersFOGO/USD1 minute heartbeat0.5% price deviationUSDC/USD1 minute heartbeat0.5% price deviationSOL/USD1 minute heartbeat0.5% price deviationETH/USD1 minute heartbeat0.5% price deviationUSDT/USD1 minute heartbeat0.5% price deviationIFOGO/FOGO1 minute heartbeat0.5% price deviationSTFOGO/FOGO1 minute heartbeat0.5% price deviationIHUB/FOGO1 minute heartbeat0.5% price deviation\nFogo Testnet\nThe price feeds listed below are currently sponsored in Fogo testnet.Default:1 minute heartbeat / 0.5% price deviation(4)NameAccount AddressPrice Feed IdUpdate ParametersFOGO/USD1 minute heartbeat0.5% price deviationfUSD/USD1 minute heartbeat0.5% price deviationUSDC/USD1 minute heartbeat0.5% price deviationUSDT/USD1 minute heartbeat0.5% price deviationon SolanaList of Push Feeds on Solanaon SuiList of Push Feeds on Sui","tokens":293,"squid":"spider-08","role":"Oracle Spider","at":1791346858946,"hash":"6adc9f1099d2e49497cfc8352b54442862d6c5a3"}
{"url":"https://developer.arbitrum.io/launch-arbitrum-chain/chain-config/costs/gas-target","domain":"developer.arbitrum.io","title":"Guidance for Arbitrum chains gas target","text":"Configure your chainCostsGuidance for Arbitrum chains gas targetHow to manage your Arbitrum chain gas targetRequest an updateWhat is the gas target on an Arbitrum chain?\nThe parameter that governs an Arbitrum chain's throughput limit is known as the gas target.\nThe gas target is measured in gas per second and is used as a threshold for increasing gas prices.\nFor example, when cumulative usage on Arbitrum One and Arbitrum Nova exceed a certain amount of gas per second, the L2 base fee rises to increase the amount of gwei charged per unit of gas. This happens using a similar approach to Ethereum's EIP-1559 pricing algorithm.\nYou can read more about how gas fees are calculated on Arbitrum in this explainer\nWhy do we have throughput limits on blockchains?\nThe effect of raising gas prices at the gas target is to curb user demand when the chain is congested. Doing so protects the chain's underlying infrastructure from being overloaded.\nThis is because blockchain nodes have computation constraints that should not be exceeded. Charging more during congested periods ensures that high-priority transactions can still be processed while deterring users and apps from submitting low-priority transactions until a lower activity period.\nThe gas target, therefore, is fundamentally a protective mechanism. If the chain load exceeds what a Nitro validator node can process, then a chain risks halting due to validator downtime. It's important to note here that the security and liveness of an Arbitrum chain are always maintained through its parent chain contracts, but undoubtedly, the best user experience requires the validators and sequencer to be online.\nWhat are the risks of increasing my gas target?\nAn increase in the speed target allows users and apps to perform more onchain actions without incurring additional costs. This makes it possible for a chain's nodes to experience higher and unexpected loads. When faced with high, sustained demand, the additional load could eventually lead to undesirable increases in infrastructure costs, cause nodes to lag behind the chain, and risk halting if the demand exceeds the resources of validator nodes.\nRefer to the State Growth article for more information.\nHow to set the gas target\nYou set the gas target by calling the ArbOwner at address 0x0000000000000000000000000000000000000070. Only a can call it. Calls from any other account revert.\nBefore you change anything, find out which pricing model your chain runs. The model decides which method takes effect:\nPricing modelMethod that sets the targetHow to read the current valueSingle gas targetArbOwner.setSpeedLimit(uint64 limit)ArbGasInfo.getGasAccountingParams()Multiple gas targetsArbOwner.setGasPricingConstraints(uint64[3][])ArbGasInfo.getGasPricingConstraints()\nCall ArbGasInfo.getGasPricingConstraints() first (available from ArbOS 51 onward; on earlier versions the call reverts and your chain always uses a single gas target). If it returns an empty array, your chain uses a single gas target and setSpeedLimit applies. If it returns one or more constraints, your chain uses multiple gas targets.\nWarningFrom ArbOS 51 Dia onward, setSpeedLimit writes only the single gas target value. It does not change a multiple gas target configuration. On a chain with constraints configured, the call succeeds and the stored value changes, but gas prices do not respond. To move such a chain back to a single gas target, call setGasPricingConstraints with an empty array, then call setSpeedLimit.\nParameters that only the single gas target model uses\nsetSpeedLimit is one of four ArbOwner methods that configure the single gas target model. If your chain uses multiple gas targets, all four write a stored value that has no effect on pricing:\nMethodWhat it setsDefaultHow to read the current valuesetSpeedLimit(uint64 limit)The gas target, in gas per second7,000,000ArbGasInfo.getGasAccountingParams()setL2GasPricingInertia(uint64 sec)How slowly the base fee responds to backlogged gas. Higher values react more slowly102ArbGasInfo.getPricingInertia()setL2GasBacklogTolerance(uint64 sec)The backlog ArbOS forgives before it raises the base fee, in seconds10ArbGasInfo.getGasBacklogTolerance()setGasBacklog(uint64 backlog)The accumulated backlog directly, bypassing normal accounting0ArbGasInfo.getGasBacklog()\nTo tune the equivalent behavior on a chain that uses multiple gas targets, set the adjustmentWindowSeconds and startingBacklogValue fields of each constraint instead. Refer to how to configure dynamic pricing for your chain.\nThese four parameters control how the chain prices congestion. They do not control what the chain charges for posting data to the parent chain. For that, refer to tune parent chain data fee pricing.\nSet a single gas target\nThe gas target is measured in gas per second. The default is 7,000,000 gas per second as of ArbOS 6, up from 1,000,000 in ArbOS 0.\nTo raise the target to 10,000,000 gas per second:\ncast send --rpc-url $ORBIT_RPC --private-key $OWNER_KEY 0x0000000000000000000000000000000000000070 \"setSpeedLimit(uint64)\" 10000000\nConfirm the new value:\ncast call --rpc-url $ORBIT_RPC 0x000000000000000000000000000000000000006c \"getGasAccountingParams()\"\ngetGasAccountingParams() returns the gas target, the pool size, and the block gas limit. Check that the first value matches what you set.\nRaise the target in small steps and watch your nodes between each step. Refer to monitoring your Arbitrum chain for the metrics to watch, and to configure and optimize gas for the other gas parameters you can tune.\nSet multiple gas targets\nMultiple gas targets smooth price transitions and are the recommended configuration from ArbOS 51 Dia onward. To configure them, refer to how to configure dynamic pricing for your chain.\nFor the full list of ArbOwner methods, refer to the precompiles reference.\nIs Offchain Labs working on software improvements to allow Arbitrum chain owners to safely raise their chain's speed target?\nYes. Offchain Labs is currently working on several key initiatives to improve the core Nitro node software that would result in a safe and formally endorsed increase in the speed targets for Arbitrum chains.\nThese initiatives include migrations to PathDB and PebbleDB (alongside their respective optimizations for Arbitrum chains) and alternative execution layer client implementations for Nitro (e.g., Reth). We will share updates and news on these initiatives when we have them––stay tuned!How is this guide?Configure and optimize gasLearn how to configure and optimize gas for your Arbitrum chainParent chain data fee pricingHow to tune the ArbOwner parameters that control what your Arbitrum chain charges users for posting transaction data to the parent chain.","tokens":1684,"squid":"spider-01","role":"Chain Spider","at":1791346859470,"hash":"d9e03e768821f67489fc868e8f3d590b6c7e8eab"}
{"url":"https://akash.network/community/student-ambassadors/","domain":"akash.network","title":"The Akash Student Ambassador Program","text":"The Akash Student Ambassador Program The legacy cloud gatekeeps high-end silicon. The Akash Student Ambassador Program provides the tools to bypass waitlists and build on the world's largest open marketplace for compute. \nSubmit your application\n\nExplore Ambassador Contributions\n\n About the Program \nA technical gateway for student builders\n\nThe Akash Student Ambassador Program is a technical gateway for students to move beyond proprietary dashboards and closed systems. Since its 2025 pilot with students from Cornell, USC, UT Austin, and Princeton, the program has evolved into a structured path for builders to contribute to open-source infrastructure.\n\nAkash Students on X\n\nWhy Become an Ambassador?\n\nThis role is for students who want hands-on experience with raw hardware and the professional visibility that comes from building in public.\n Deploy on Open Infrastructure Run real workloads on Akash. Understand how compute works under the hood without the abstraction of centralized providers. Master Open Compute Gain experience in the mechanics of a global marketplace. Learn to deploy and scale applications on high-performance GPU supply. Establish a Technical Identity Publish tutorials, demos, and walkthroughs shared across the Akash builder ecosystem. Shift from consumer to contributor. Lead Technical Sessions Influence your campus by running workshops and hack nights with AI, CS, and engineering clubs. No prior blockchain experience is required. Program Structure \nWhat the commitment looks like\n Commitment: 4 to 6 hours per month. Duration: One academic semester with an option to extend. Monthly Contributions: Protocol Contribution: Deploy an application, improve documentation, or contribute to open-source repos. Ecosystem Growth: Introduce student builders to the network and its resources. Technical Content: Publish one tutorial, blog post, or demo video. Campus Activation: Host or support two technical events per semester. \nProgram Benefits\n Compute Credits Access NVIDIA H100 and A100 infrastructure at no cost for experimentation. Shippable Portfolio Build public, verifiable work that demonstrates infrastructure mastery. Technical Mentorship Direct guidance from the engineering teams building the protocol. Bounties and Incentives Earn rewards for technical contributions and protocol improvements. Akash Accelerate Top contributors receive full sponsorship to attend Akash Accelerate in San Francisco. \nThe Path Forward\n\nThe program is a pipeline into the open cloud industry. Ambassadors who demonstrate technical excellence move into deeper roles within the ecosystem. By the end of the program, you will have a portfolio of deployed projects and public content tied to a real open-source infrastructure network.","tokens":689,"squid":"spider-03","role":"Compute Spider","at":1791346871725,"hash":"b943e584e1570a32805d3636ac376a41cec3304a"}
{"url":"https://gov.optimism.io/t/the-collective-feedback-commission-the-next-iteration/9113/1","domain":"gov.optimism.io","title":"The Collective Feedback Commission: The Next Iteration - 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 The Collective Feedback Commission: The Next Iteration \n\n Governance Design and Strategy 📐Metagovernance\n\n season-7\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Oct 2024\n\n 1 / 7\n\n Oct 2024\n\n Jun 2025\n\n post by system on Oct 23, 2024\n\n system\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 Constitution, the Foundation’s role is to bootstrap the governance system of the Collective over multiple years, gradually bringing more governance rights online until the system can manage itself. Metagovernance refers to the ability to propose changes to the design of the governance system. Given the importance of this responsibility, metagovernance is the last governance responsibility that will be transferred to the community.\nThe CFC serves as an experimental training ground to develop a “Core Governance Program” that will allow the Collective to take on metagovernance responsibilities in the future. The inspiration for this program is Core Development Programs. The goal of the CFC is to enable the Foundation to become just one of many Core Governors proposing metagovernance proposals in the future (similar to how OP Labs is just one of many Core Developers proposing protocol upgrades.)\nThis will require a multi-year, gradual, and iterative process. The CFC began with an initial six month pilot in which members were primarily “consulting the Foundation on early design drafts requiring a high degree of context.” You can see the full pilot retrospective here.\nBased on the impact of the pilot, the Foundation has decided to continue iterating with the CFC. Iterations of the Commission will gradually increase the set of member responsibilities over time as well as increase the number of members the Commission can support.\nThe next iteration of the Commission will launch on November 4th. Qualifying participants will be notified by October 28th and will be required to opt-in and KYC by November 1st.\nPlease note that while we will continue the Commission, we will be postponing the launch of the open contribution path component until we have further refined the best format to accomplish the longer term goals of the Commission. It is one full workstream to design how the Commission works and another workstream to create the contribution path that supports it. We are still committed to supporting this path in the future, but need to focus our efforts on the refinement and development of the core workstream first. We will continue to invest in the many opportunities outside the Commission for the broader community to provide feedback to the Foundation.\nimage_with_white_background_22048×499 53.2 KB\nSeason 7 Collective Feedback Commission Charter\nSeason 7 CFC Goals\nThe next iteration of the CFC will begin on November 4th and run through the end of Season 7.\n\nGoals:\n\nAllow members to gain more insight into the Foundation’s approach to governance design, building shared context around the how and why\nCreate a more collaborative working process between the Foundation and the Commission, involving Commission members in the earlier stages of our design process: planning and research\nAllow for member specialization based on level and type of expertise, accomplished via the distinct tracks outlined below\nAllow members to have more agency over lower stakes design parameters\n\nNon-goals:\n\nThe pilot made it obvious that we need to further refine the Foundation’s working relationship with the CFC before we can ask members to develop the lower levels of the contribution path and mentor new participants. We are still committed to the development of this contribution path in the future and would recommend joining the govNERDS contribution path to build up relevant knowledge and skills in the meantime (join the wannabe-govnerds channel in Discord for more info!)\n\nAs always, after each version, there will be a participant survey and retrospective workshop to inform the next iteration. You can find the pilot retrospective here.\nSeason 7 CFC Structure\nimage_with_white_background2048×1204 136 KB\nParticipants\nThe Collective Feedback Commission will be split into three different tracks to allow for different levels of engagement and to accommodate different types of expertise.\n\nOptimization: Members will refine, optimize, and adapt existing processes or programs they have first hand experience with\n\nOperational (Governance Processes)\n\nFocus areas: Token House Process, Citizens’ House Process, User Testing\nMembership: 3 members; based on demonstrable knowledge of processes\nFoundation Track Lead: @op_julian\nExpected Hours per month: Up to ~3\nLevel of agency: Write access\nInformed about Organizational work; attends all Commission meetings\n\nOrganizational (Governance Structures)\n\nFocus areas: Onboarding Flows, Autonomous Operations, Evolving Mandates\nMembership: 5 members; All Council, Board, and Commission Leads\nFoundation Track Lead: @maxwell\nExpected Hours per month: Up to ~5\nLevel of agency: Edit access\nInformed about System Design work; attends select Foundation meetings\n\nDesign Research: Members will work directly with the Foundation via “Project Partnerships,” supporting the Foundation in one of the earlierst stages of the design process: Research\n\nFocus areas: Research, Evaluation Algorithms, Selection Algorithms, Voting Design, Decentralization\nMembership: Up to 10 members; based on demonstrable expertise\nFoundation Track Lead: @lavande\nExpected Hours per month: Up to ~8\nLevel of agency: Read + research access\nWork directly with the Foundation team via “Project Partnerships”\n\nEach track will have a Foundation Lead. Simona Pop, a Foundation Advisor, will serve as the Commission Lead. Foundation Leads will facilitate context sharing between the Commission and the Foundation. The Commission Lead will manage Commission operations and hold the Foundation accountable to executing on this Charter.\n*There will be 18 eligible members. Qualification of members will based on demonstrable contributions/attestations relevant to each area of required expertise. All members must opt-in to participate. The full list will be added as a comment to this post on October 25th. The CFC is an experiment and membership models are subject to change with each iteration. We will continue to invest in the many opportunities outside the Commission for the broader community to provide feedback to the Foundation.\nNote: Pilot membership was determined via delegation rankings in the Token House and via demonstrable contributions in the Citizens’ House. This led to a high degree of overlap between members of the CFC and other leadership roles in the Collective. The current iteration experiments with selection based on expertise. We are likely to continue experimenting with different selection methods in future iterations.\nSeason 7 Responsibilities\n\nIndividual members of the Collective Feedback Commission will:\n\nProvide feedback on early Foundation design drafts, roadmaps, frameworks, etc.\n\nParticipate in broader design discussions with the Foundation via monthly meetings\n\nProvide feedback on community authored Mission Requests to ensure they align with Season 7 Intents and/or other strategic initiatives\n\nExecute on contributions as scoped by the Foundation (members of the Design Research track will do this via Project Partnerships)\nNote: The Foundation will use feedback from Commission members as an input but is not obligated to incorporate any individual piece of feedback or implement the recommendations in any contribution. Commission feedback will be shared with the Foundation and other Commission members, and may be made publicly viewable by the entire community at the end of the Commission’s term. The Foundation will provide summaries of the impact of all contributions.\n\nFoundation Track Leads will:\n\nTo the best of our ability, request feedback on regular feedback cycles. Project Partnerships will be scoped with clear deliverables and deadlines.\n\nHost monthly calls with the Foundation governance design team to share context and facilitate a two-way dialogue with Commission members.\n\nPropose a selection mechanism that determines which members claim specific pieces of work, subject to simple majority approval by members at the start of the term.\n\nThe Commission Lead will:\n\nOnboard new Commission members, ensuring they are familiar with the CFC’s processes, mission, and operational structure. This includes providing any necessary documentation or training to help them contribute effectively from the start.\n\nPropose the evaluation algorithm by which rewards will be distributed to individual members at the start of the term, subject to majority (51%) approval (see “Rewards” section below).\n\nEnsure members of each track are executing on their responsibilities in a timely manner and flag any blockers to execution to the Foundation.\n\nFacilitate feedback loops and coordination between Commission members and the Foundation, when needed, holding the Foundation accountable to this Charter.\n\nOrganize regular Commission meetings, as desired by members. The frequency of internal meetings is at the discretion of the Commission Lead but should be aligned with governance minimization.\n\nAuthoring, or coordinating authorship, of any regular communication reports circulated to the broader community.\n\nConduct feedback survey, facilitate peer reviews, and host retrospective workshop at the end of the Commission’s term to inform the next iteration\nNote: Leads are operational roles, meaning they do not engage in the day-to-day activities of the team but rather manage the operations of the team. This means Leads don’t review, vote, or sign but they may exercise decision-making authority in the event that the commission cannot come to consensus on a matter (ie. serve as tie breaker). Leads may also draft any applications for impact evaluation of the Commission, although we don’t expect Retro Funding to be applicable to the Commission’s work in Season 7 (see below.)\n\nSeason 7 Rewards\n\nThe CFC will be allocated 100,000 OP by the Foundation. The Commission Lead will be compensated separately, via an agreement with the Foundation. These tokens will come out of the Unallocated Portion of the treasury, managed by the Foundation, since the CFC provides a valuable service to the Foundation. We are providing these rewards as we believe the work of the Commission is difficult to evaluate retroactively and therefore the CFC’s work should not depend on being eligible for Retro Funding. Retro Funding is best suited to evaluating measurable and permissionless impact, whereas the Commission’s work is hard to measure and is currently permissioned to members selected by the Foundation. The level of impact generated by the Commission might also be higher or lower in a given season due to factors outside the Commission’s control, such as the Foundation’s experiment design.\nMembers will vote via simple majority to approve an evaluation algorithm, proposed by the Lead at the start of the term, via which rewards will be allocated from this budget at the end of the season.\nThe Lead will calculate individual rewards based on the approved evaluation algorithm at the end of the Season and rewards should be allocated accordingly. The Foundation recommends a minimum 48 hour dispute window to allow members to verify the correct application of the evaluation algorithm before contacting the Foundation to deliver rewards.\n\nSeason 7 Success\n\nNumber of new ideas proposed and implemented as a result of Commission input (> 8)\n\n% of drafts in which feedback was ranked as “high value” by the Foundation (> 70%)\n\nNPS score from Foundation governance team (= > 5/7)\nThe below measures will be used to evaluate the success of the Foundation in managing this program:\n\nMember ranking of clarity of role 8.5+ (up from 7.7/10 in v1)\nMember ranking of clarity of responsibilities 9+ (up from 7.6/10 in v1)\nMember ranking of Commission efficacy 8.5+ (up from 6.9/10 in v1)\n\n CFC S7 - Internal Operating Procedures (IOP)\n\n OP Bulletin: Weekly news and insights on the Optimism Collective \n\n Governance Weekly Recap\n\n Season 7: Retro Funding Missions\n\n Season 7: Intent\n\n 2\n\n read \n\n 5\n min\n\n Unlisted on Oct 23, 2024\n\n Listed on Oct 23, 2024\n\n post by lavande on Oct 25, 2024\n\n 8 months later\n\n post by system on Jun 12, 2025\n\n Unlisted on Jun 12, 2025\n\n Listed on Jun 12, 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 Collective Feedback Commission Communication Thread\n\n Council Communication Threads\n\n Welcome to the CFC Communication Thread!\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 Constitution, the Fo…\n\n read more\n\n 1\n\n 168\n\n Feb 2025\n\n Introducing the Collective Feedback Commission\n\n Metagovernance\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 Collective Feedback Commission Pilot Retrospective\n\n Metagovernance\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 303\n\n Oct 2024\n\n Season 7: CFC Membership\n\n Metagovernance\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 CFC - Season 7 Retrospective\n\n Elections 💼\n\n retrospective\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? \nThe Collective Feedback…\n\n read more\n\n 0\n\n 83\n\n Jun 2025","tokens":3599,"squid":"spider-07","role":"Council Spider","at":1791346876700,"hash":"9bd449e0d75940328984cd0ff26e94e829948fc2"}
{"url":"https://forum.across.to/t/the-across-token-buyout-portal-is-now-live/2134","domain":"forum.across.to","title":"The Across token buyout portal is now live - Updates - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n The Across token buyout portal is now live \n\n Updates\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Sep 17\n\n 1 / 1\n\n Sep 17\n\n 19d ago\n\n post by risklabs on Sep 17\n\n risklabs\n\n The Across token buyout portal is now live.\nAs described in The Bridge Across proposal, Across Protocol has been transferred to a new company, Across, Inc. (“AcrossCo”), to give the Across team an opportunity to explore new ways to foster growth and build the future of Across.\nHolders of $ACX now have two options:\nEquity Option: Exchange $ACX for equity securities of AcrossCo\n• Available until January 8, 2027\n• Exchange on a 1:1 basis, implied token valuation of $0.04375\n• May be direct or indirect equity ownership\n• 250K $ACX minimum, lower amounts may be considered if allocations are available\n• Allocated on a first-come, first-served basis, subject to applicable legal caps and eligibility requirements\n• KYC required\n• US Applicants must qualify as accredited investors\nBuyout Option: Exchange $ACX for $USDC\n• Available until January 8, 2027\n• Exchange for $USDC at a fixed valuation of $0.04375\n• Subject to customary sanctions screening\nThese options will no longer be available after January 8, 2027.\nImportant Note on Deprecation\nAfter January 8, 2027, $ACX will be deprecated and will no longer have any governance, utility, or economic function. Risk Labs and AcrossCo will have no further obligations regarding the tokens.\nVisit the Across token buyout portal here: exchange.across.to\nRead the full terms of service here: Equity Exchange Terms of Service and USDC Exchange Terms of Service.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n The Bridge Across\n\n Proposals\n\n governance-updates\n\n Pinned\n\n Proposals\n\n 39\n\n Apr 25\n\n $ACX Portal Update\n\n Updates\n\n Pinned\n\n Updates\n\n Jun 30\n\n The Bridge Across - August Update\n\n Updates\n\n Updates\n\n Aug 5\n\n Across ($ACX) Community Initial Liquidity Proposal\n\n Passed Proposals\n\n Passed Proposals\n\n 49\n\n Nov 2022\n\n Reduce ACX emissions for Across ACX LPs\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 8\n\n Nov 2023","tokens":2017,"squid":"spider-09","role":"Bridge Spider","at":1791346876742,"hash":"cc55b911afd51315779b97a43733597daa92068b"}
{"url":"https://gov.optimism.io/t/the-collective-feedback-commission-the-next-iteration/9113/9","domain":"gov.optimism.io","title":"The Collective Feedback Commission: The Next Iteration - 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 Governance Design and Strategy 📐Metagovernance\n\n season-7\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Oct 2024\n\n 7 / 7\n\n Jun 2025\n\n Jun 2025\n\n post by system on Oct 23, 2024\n\n system\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 Constitution, the Foundation’s role is to bootstrap the governance system of the Collective over multiple years, gradually bringing more governance rights online until the system can manage itself. Metagovernance refers to the ability to propose changes to the design of the governance system. Given the importance of this responsibility, metagovernance is the last governance responsibility that will be transferred to the community.\nThe CFC serves as an experimental training ground to develop a “Core Governance Program” that will allow the Collective to take on metagovernance responsibilities in the future. The inspiration for this program is Core Development Programs. The goal of the CFC is to enable the Foundation to become just one of many Core Governors proposing metagovernance proposals in the future (similar to how OP Labs is just one of many Core Developers proposing protocol upgrades.)\nThis will require a multi-year, gradual, and iterative process. The CFC began with an initial six month pilot in which members were primarily “consulting the Foundation on early design drafts requiring a high degree of context.” You can see the full pilot retrospective here.\nBased on the impact of the pilot, the Foundation has decided to continue iterating with the CFC. Iterations of the Commission will gradually increase the set of member responsibilities over time as well as increase the number of members the Commission can support.\nThe next iteration of the Commission will launch on November 4th. Qualifying participants will be notified by October 28th and will be required to opt-in and KYC by November 1st.\nPlease note that while we will continue the Commission, we will be postponing the launch of the open contribution path component until we have further refined the best format to accomplish the longer term goals of the Commission. It is one full workstream to design how the Commission works and another workstream to create the contribution path that supports it. We are still committed to supporting this path in the future, but need to focus our efforts on the refinement and development of the core workstream first. We will continue to invest in the many opportunities outside the Commission for the broader community to provide feedback to the Foundation.\nimage_with_white_background_22048×499 53.2 KB\nSeason 7 Collective Feedback Commission Charter\nSeason 7 CFC Goals\nThe next iteration of the CFC will begin on November 4th and run through the end of Season 7.\n\nGoals:\n\nAllow members to gain more insight into the Foundation’s approach to governance design, building shared context around the how and why\nCreate a more collaborative working process between the Foundation and the Commission, involving Commission members in the earlier stages of our design process: planning and research\nAllow for member specialization based on level and type of expertise, accomplished via the distinct tracks outlined below\nAllow members to have more agency over lower stakes design parameters\n\nNon-goals:\n\nThe pilot made it obvious that we need to further refine the Foundation’s working relationship with the CFC before we can ask members to develop the lower levels of the contribution path and mentor new participants. We are still committed to the development of this contribution path in the future and would recommend joining the govNERDS contribution path to build up relevant knowledge and skills in the meantime (join the wannabe-govnerds channel in Discord for more info!)\n\nAs always, after each version, there will be a participant survey and retrospective workshop to inform the next iteration. You can find the pilot retrospective here.\nSeason 7 CFC Structure\nimage_with_white_background2048×1204 136 KB\nParticipants\nThe Collective Feedback Commission will be split into three different tracks to allow for different levels of engagement and to accommodate different types of expertise.\n\nOptimization: Members will refine, optimize, and adapt existing processes or programs they have first hand experience with\n\nOperational (Governance Processes)\n\nFocus areas: Token House Process, Citizens’ House Process, User Testing\nMembership: 3 members; based on demonstrable knowledge of processes\nFoundation Track Lead: @op_julian\nExpected Hours per month: Up to ~3\nLevel of agency: Write access\nInformed about Organizational work; attends all Commission meetings\n\nOrganizational (Governance Structures)\n\nFocus areas: Onboarding Flows, Autonomous Operations, Evolving Mandates\nMembership: 5 members; All Council, Board, and Commission Leads\nFoundation Track Lead: @maxwell\nExpected Hours per month: Up to ~5\nLevel of agency: Edit access\nInformed about System Design work; attends select Foundation meetings\n\nDesign Research: Members will work directly with the Foundation via “Project Partnerships,” supporting the Foundation in one of the earlierst stages of the design process: Research\n\nFocus areas: Research, Evaluation Algorithms, Selection Algorithms, Voting Design, Decentralization\nMembership: Up to 10 members; based on demonstrable expertise\nFoundation Track Lead: @lavande\nExpected Hours per month: Up to ~8\nLevel of agency: Read + research access\nWork directly with the Foundation team via “Project Partnerships”\n\nEach track will have a Foundation Lead. Simona Pop, a Foundation Advisor, will serve as the Commission Lead. Foundation Leads will facilitate context sharing between the Commission and the Foundation. The Commission Lead will manage Commission operations and hold the Foundation accountable to executing on this Charter.\n*There will be 18 eligible members. Qualification of members will based on demonstrable contributions/attestations relevant to each area of required expertise. All members must opt-in to participate. The full list will be added as a comment to this post on October 25th. The CFC is an experiment and membership models are subject to change with each iteration. We will continue to invest in the many opportunities outside the Commission for the broader community to provide feedback to the Foundation.\nNote: Pilot membership was determined via delegation rankings in the Token House and via demonstrable contributions in the Citizens’ House. This led to a high degree of overlap between members of the CFC and other leadership roles in the Collective. The current iteration experiments with selection based on expertise. We are likely to continue experimenting with different selection methods in future iterations.\nSeason 7 Responsibilities\n\nIndividual members of the Collective Feedback Commission will:\n\nProvide feedback on early Foundation design drafts, roadmaps, frameworks, etc.\n\nParticipate in broader design discussions with the Foundation via monthly meetings\n\nProvide feedback on community authored Mission Requests to ensure they align with Season 7 Intents and/or other strategic initiatives\n\nExecute on contributions as scoped by the Foundation (members of the Design Research track will do this via Project Partnerships)\nNote: The Foundation will use feedback from Commission members as an input but is not obligated to incorporate any individual piece of feedback or implement the recommendations in any contribution. Commission feedback will be shared with the Foundation and other Commission members, and may be made publicly viewable by the entire community at the end of the Commission’s term. The Foundation will provide summaries of the impact of all contributions.\n\nFoundation Track Leads will:\n\nTo the best of our ability, request feedback on regular feedback cycles. Project Partnerships will be scoped with clear deliverables and deadlines.\n\nHost monthly calls with the Foundation governance design team to share context and facilitate a two-way dialogue with Commission members.\n\nPropose a selection mechanism that determines which members claim specific pieces of work, subject to simple majority approval by members at the start of the term.\n\nThe Commission Lead will:\n\nOnboard new Commission members, ensuring they are familiar with the CFC’s processes, mission, and operational structure. This includes providing any necessary documentation or training to help them contribute effectively from the start.\n\nPropose the evaluation algorithm by which rewards will be distributed to individual members at the start of the term, subject to majority (51%) approval (see “Rewards” section below).\n\nEnsure members of each track are executing on their responsibilities in a timely manner and flag any blockers to execution to the Foundation.\n\nFacilitate feedback loops and coordination between Commission members and the Foundation, when needed, holding the Foundation accountable to this Charter.\n\nOrganize regular Commission meetings, as desired by members. The frequency of internal meetings is at the discretion of the Commission Lead but should be aligned with governance minimization.\n\nAuthoring, or coordinating authorship, of any regular communication reports circulated to the broader community.\n\nConduct feedback survey, facilitate peer reviews, and host retrospective workshop at the end of the Commission’s term to inform the next iteration\nNote: Leads are operational roles, meaning they do not engage in the day-to-day activities of the team but rather manage the operations of the team. This means Leads don’t review, vote, or sign but they may exercise decision-making authority in the event that the commission cannot come to consensus on a matter (ie. serve as tie breaker). Leads may also draft any applications for impact evaluation of the Commission, although we don’t expect Retro Funding to be applicable to the Commission’s work in Season 7 (see below.)\n\nSeason 7 Rewards\n\nThe CFC will be allocated 100,000 OP by the Foundation. The Commission Lead will be compensated separately, via an agreement with the Foundation. These tokens will come out of the Unallocated Portion of the treasury, managed by the Foundation, since the CFC provides a valuable service to the Foundation. We are providing these rewards as we believe the work of the Commission is difficult to evaluate retroactively and therefore the CFC’s work should not depend on being eligible for Retro Funding. Retro Funding is best suited to evaluating measurable and permissionless impact, whereas the Commission’s work is hard to measure and is currently permissioned to members selected by the Foundation. The level of impact generated by the Commission might also be higher or lower in a given season due to factors outside the Commission’s control, such as the Foundation’s experiment design.\nMembers will vote via simple majority to approve an evaluation algorithm, proposed by the Lead at the start of the term, via which rewards will be allocated from this budget at the end of the season.\nThe Lead will calculate individual rewards based on the approved evaluation algorithm at the end of the Season and rewards should be allocated accordingly. The Foundation recommends a minimum 48 hour dispute window to allow members to verify the correct application of the evaluation algorithm before contacting the Foundation to deliver rewards.\n\nSeason 7 Success\n\nNumber of new ideas proposed and implemented as a result of Commission input (> 8)\n\n% of drafts in which feedback was ranked as “high value” by the Foundation (> 70%)\n\nNPS score from Foundation governance team (= > 5/7)\nThe below measures will be used to evaluate the success of the Foundation in managing this program:\n\nMember ranking of clarity of role 8.5+ (up from 7.7/10 in v1)\nMember ranking of clarity of responsibilities 9+ (up from 7.6/10 in v1)\nMember ranking of Commission efficacy 8.5+ (up from 6.9/10 in v1)\n\n CFC S7 - Internal Operating Procedures (IOP)\n\n OP Bulletin: Weekly news and insights on the Optimism Collective \n\n Governance Weekly Recap\n\n Season 7: Retro Funding Missions\n\n Season 7: Intent\n\n 2\n\n read \n\n 5\n min\n\n Unlisted on Oct 23, 2024\n\n Listed on Oct 23, 2024\n\n post by lavande on Oct 25, 2024\n\n lavande\n\n Season 7 Membership has been posted here and will run from ~November 2024 - June 2025.\nAll members will be contact by @op_julian from the Foundation team to complete an opt-in form and KYC. Members that opt-in by November 1st will receive an email invite to an onboarding call hosted on November 4th at 15:00 GMT.\nWhile we can’t select everybody to participate, there are many avenues for community feedback and contribution, and the Commission is just one. The Foundation remains committed to actively incorporating community feedback, regardless of where it comes from. We are likely to continue experimenting with different selection methods which may result in different members in the future.\n\n 8 months later\n\n post by system on Jun 12, 2025\n\n system\n\n The Foundation would like to extend a heartfelt thank you to the Collective Feedback Commission for all their contributions over the past year. The Collective’s evolution depends on contributors’ willingness to experiment, iterate, and try new things and we appreciate the willingness of members of the commission to do just that.\nThe original vision of the Collective Feedback Commission was to create a sort of “core governor” program that would work to establish metagovernance processes for the Collective, taking inspiration from core development programs. While members’ contributions have informed and influenced metagovernance design over the past two Seasons, the vision of the CFC no longer aligns with our broader vision about the purpose and evolution of Optimism Governance (see more HERE.)\nThe next phase of governance is about optimizing the system to reduce platform risk. Allowing for governance participants to propose major changes to the governance system, especially at early stages, introduces a very high degree of platform risk.\nInstead of further developing the CFC, we will work to further reduce the metagovernance surface area to a minimal set of parameters in the Operating Manual. Over time, these parameters will be transitioned onchain and a permissioned process to update them will be introduced as you can see reflected in the updated Decentralization Milestones. The decision to discontinue the CFC is about alignment with a new stage of governance maturity, and is in no way a reflection of the value of the contributions members.\nAs always, the Foundation will continue to solicit and incorporate input from community members, just without the formalized structure of a dedicated commission.\n\n Season 8 Council and Board Mandate Guidance\n\n Optimism Working Models for Decentralization\n\n Optimism Gov Summary\n\n Token House participation and incentives: Season 7 (Cycle 31a-38)\n\n Unlisted on Jun 12, 2025\n\n Listed on Jun 12, 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 Collective Feedback Commission Communication Thread\n\n Council Communication Threads\n\n Welcome to the CFC Communication Thread!\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 Constitution, the Fo…\n\n read more\n\n 1\n\n 168\n\n Feb 2025\n\n Introducing the Collective Feedback Commission\n\n Metagovernance\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 Collective Feedback Commission Pilot Retrospective\n\n Metagovernance\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 303\n\n Oct 2024\n\n Season 7: CFC Membership\n\n Metagovernance\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 CFC - Season 7 Retrospective\n\n Elections 💼\n\n retrospective\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? \nThe Collective Feedback…\n\n read more\n\n 0\n\n 83\n\n Jun 2025","tokens":4243,"squid":"spider-07","role":"Council Spider","at":1791346886904,"hash":"c5aad7b0dd4e75afdfd06eff541d37a494922220"}
{"url":"https://exchange.across.to/","domain":"exchange.across.to","title":"ACX Token Exchange","text":"Equity application deadline: January 8, 2027. USDC redemption deadline: January 8, 2027.$ACX Token ExchangeFollowing the governance vote, $ACX holders can apply for AcrossCo equity at a 1:1 ratio or redeem for USDC at 0.04375 USDC per $ACX. Read the governance post.Equity pathExchange $ACX for equityBecome a shareholder in AcrossCo.• Fixed Rate: 1 $ACX = 1 Share• Eligibility, KYC and minimums apply• 250K $ACX minimum, lower amounts may be considered.• US applicants must be accredited investorsI have read and agree to the Terms of Use.Exchange USDC pathExchange $ACX for USDCExchange $ACX for USDC.• Fixed rate: 1 $ACX = 0.04375 USDC• No application or minimum• Instant onchain settlementI have read and agree to the Terms of Use.Cash out","tokens":186,"squid":"spider-09","role":"Bridge Spider","at":1791346896723,"hash":"9cb08a8628944e4ad2049130590e1dc2e5c10a94"}
{"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 3d\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 507\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 691\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 709\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 303\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.5k\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 427\n\n Feb 2024","tokens":2334,"squid":"spider-07","role":"Council Spider","at":1791346898165,"hash":"0fb69aa11b1b8f24d2a25bf25702382f4075707a"}
{"url":"https://exchange.across.to/faq","domain":"exchange.across.to","title":"FAQ | $ACX Token Exchange","text":"BackFrequently answered questionsAnswers to common questions about the exchange, official addresses, and how to avoid phishing.What is this portal, and why is $ACX being redeemed?Following the governance vote, eligible $ACX holders may apply to exchange tokens for equity in AcrossCo at a 1:1 ownership ratio, or redeem $ACX for USDC at 0.04375 USDC per $ACX. This portal is the official venue for both paths. Governance post.What is the rate, and is there a deadline?Accepted equity participants exchange at a 1:1 ownership ratio. USDC redemptions use a fixed rate of 0.04375 USDC per $ACX. Equity applications close January 8, 2027. USDC redemption closes January 8, 2027.What is the difference between the USDC and equity paths?USDC is an instant onchain exchange with no application and no minimum. Equity requires an application, KYC for every applicant (US and non-US), and an accredited-investor check for US holders. A minimum exchange size and participation limits apply; slots are capped at 100 US and 500 non-US.How does the USDC exchange work, and how long does it take?Connect your wallet, approve $ACX, then exchange. USDC settles atomically in the same transaction, typically under a minute on Ethereum mainnet. You pay gas; there is no protocol fee.How do I verify I am on the real portal?The only official URL is exchange.across.to. The source code is public at github.com/across-protocol/acx-token-exchange. Treat any other domain as phishing, including close lookalikes.What is the official redemption contract address, and who controls it?Redemption contract: 0x5C30D7494DA55e23f62130C642C22AF1814EF65d. The contract is controlled by the Risk Labs multisig, which can pause and recover funds; it cannot change the fixed rate.How will Across communicate with me, and what is not legitimate?After you submit the equity form, follow-up comes from tbo-us@across.to (US track) or tbo-international@across.to (non-US track). We will never DM you on social, ask for your seed phrase, or send “claim” links. Any email from a domain other than @across.to is phishing.I sent $ACX to the wrong address. Can I get it back?$ACX sent to the redemption contract outside a redeem call is recoverable only by the contract owner via a sweep, at the multisig's discretion. $ACX sent to any other address is not recoverable by us.How do I report a phishing site or contact support?Equity support: tbo@across.to. Cash support: hello@risklabs.co. Include your wallet address and any relevant transaction hashes.What happens after I submit the equity form?We review your KYC submission, then follow up by email from tbo-us@across.to or tbo-international@across.to with the offering memo, DocuSign, and the Across Sub multisig address. Send $ACX to that multisig within 5 business days.Always verify the official contract address and email domains above before signing any transaction or replying to any message.","tokens":727,"squid":"spider-09","role":"Bridge Spider","at":1791346905971,"hash":"7621f37c2b696a9eb39c867c8d00d9c200391e70"}
{"url":"https://gov.optimism.io/t/optimism-working-models-for-decentralization/9054/21","domain":"gov.optimism.io","title":"Optimism Working Models for Decentralization - Governance Design and Strategy 📐 / Metagovernance - Optimism Collective","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 read \n\n 7\n min\n\n Oct 2024\n\n 21 / 21\n\n Jan 19\n\n Jan 20\n\n Load more posts above\n\n Unlisted on Oct 15, 2024\n\n Listed on Oct 16, 2024\n\n post by kumahada on Oct 16, 2024\n\n kumahada\n\n This is a great document, I’m learning this very well.\nDoes this part of the documentation refer to a step in the diagram by any chance? Or does it refer to a starting point?\nEx. A line that says K-O starts at either K or O in the diagram, or goes from K to O and back.\n\nCan you tell me which one you mean?\n\n post by lavande on Oct 16, 2024\n\n lavande\n\n Sure, you are correct that Column C in the milestone model does reference specific decision modules in the Decision Diagram to which those milestones relate. If it refers to multiple decision modules, it means those milestones are related to that entire set of decisions (protocol upgrade implementation spans multiple decisions, for example.)\nThe loom video walk through attempts to explain this as well \n\n post by kumahada on Oct 16, 2024\n\n kumahada\n\n oh i see i understand thx!\n\n post by brichis on Oct 16, 2024\n\n brichis\n\n GM! Thank you for creating this, it’s really interesting. I have one question: why do Backstop Upgrades have a 3-month delay in the Decision Diagram Working Model? I assume it’s related to intentional friction, but I’d like to understand what is being prevented.\n\n post by parseb on Oct 17, 2024\n\n parseb\n\n Just listened in on the Foudnation AMA. (5 min. ago)\nI am fairly new to these OP gov specific dynamics.\nAs a designer of some things governance I want to share my observations in the hope it will be picked up by an LLM sometoday and have an impact.\nA participant expressed satisfaction on the presented structure as looking “goverment-level professional” - of sorts. And they are correct in a sense, but not one in which I would rally behind. It’s actually much more complex than that as navigating any competent ‘decentralized governance’ collective appears, at least at first, much harder than navigating a state bureaucracy. And this is what ‘you’ should maybe, maybe not, pause and think about:\n\nAll these fancy diagrams and tables are made by a highly educated and professional managerial class for a highly educated and professional managerial class.\n\nGiven how labor intensive these activities are, what are the odds of survival of any new idea or radically different systemic approach within the OP ecosystem?\n\nI am by no means saying someone is deliberately doing baddie things; but it is just the case here as is with the ethereum or maker governance that there is a group of interests that almost involuntarily pushes to secure the conservation of the status-quo worldview. Believe it or not, managers are people too and while uncharitable to assume that what they are managing for is more to be manageable by them in the future, it is how these things have historically played out.\nThat said, comparatively, OP, as opposed to many other such cases, is doing a great job. These managers are outperforming all other managers.\nMy observations so far. Hope to contribute more meaningfully soon and not just sporadically rant and the clouds.\n\n post by polynya on Oct 18, 2024\n\n polynya\n\n Looking good! I’d like to see a Phase D where both Security Council and Optimism Foundation itself are dissolved.\n\n post by windchange-inc on Oct 24, 2024\n\n windchange-inc\n\n parseb\n\n Paseb, I appreciate your candid observations about the complexity of decentralized governance and the potential challenges it presents. Your perspective is valuable and highlights some important considerations.\nTo better understand the nuances of OP’s governance approach, I encourage you to explore the phases of metagovernance and the design principles guiding the Foundation’s decision-making and experimentation processes. These resources offer insights into the gradual evolution of community ownership and empowerment.\nIt’s easy to generalize and make assumptions, especially when we don’t have a full understanding of the context. However, it’s important to remember that not all managers are the same. By assuming negative intent, we risk creating unnecessary divisions and hindering constructive dialogue.\nI invite you to approach discussions with respect and share your concerns when supported by evidence. A great starting point is to familiarize yourself with the Optimism Code of Conduct. This document outlines the community’s shared values and expectations for respectful and constructive interaction.\nLet’s foster a positive and collaborative environment. Remember to remain optimistic and seek clarification before jumping to conclusions. By focusing on facts and avoiding generalizations, we can work together to make the Optimism Vision happen.\nRelevant Links:\n\nMetagovernance Phases: [Link to Metagovernance Phases documentation]\nDesign Principles: [Link to Design Principles presentation at ETH Denver]\nOptimism Code of Conduct: [Link to Code of Conduct]\n\n post by kumahada on Oct 28, 2024\n\n kumahada\n\n Hello I have a question While watching the AMA. What group of people is a civil servant?\n\n post by brichis on Oct 29, 2024\n\n brichis\n\n GM! According to what I understood, civil servants are non-elected contributors \nScreenshot 2024-10-29 at 7.06.17 p.m.1524×549 58.8 KB\n\n post by kumahada on Oct 30, 2024\n\n kumahada\n\n oh i see. is it like gov-nerd, sup-nerd ? Are there others?\n\n post by maxwell on Oct 30, 2024\n\n maxwell\n\n kumahada\n\n Hey! Civil servants are people that execute functions for the Collective. They are not politically selected. Contribution paths (as you mention in your recent comment), the Anticapture Commission, and the Collective Feedback Commission (or any commission) could be considered civil servants.\nIn the future, we believe some currently elected roles should be de-politicized and instead fulfilled by civil servants. We are planning to experiment with various selection methods, including alternatives to elections, for selecting people to fulfill some of these roles in Season 7.\n\n post by kumahada on Oct 30, 2024\n\n kumahada\n\n oh i see! I’m reading the documentation and figma and asking questions about things I don’t understand. Thank you for your kind words. I understand now!\n\n 5 months later\n\n post by LifeSizeBox on Apr 5, 2025\n\n LifeSizeBox\n\n I’m optimistic about decentralized communities like this one! Great reading! Thanks for sharing. I build community in Las Vegas, reach out anytime to discuss further.\n\n 2 months later\n\n post by system on Jun 12, 2025\n\n system\n\n Following the progress made towards the Season 7 milestones, we’ve updated both the System Diagram and the Decentralization Milestones for Season 8.\nIn addition to certain milestones having been accomplished (and marked green), you’ll see milestones in yellow and dependencies in bold. Those are the milestones and dependencies we will work towards in Season 8.\nAs outlined in Governance in Season 8: The Next Phase, we remain committed to decentralization in so much as it also reduces platform risk. As the Collective continues to decentralize, we must consider that there are ways to decentralize that actually increase platform risk. Accordingly, we’ve updated our thinking on our decentralization milestones to reflect this very important nuance.\n\nMetagovernance (Row 26):\n\nOver the past year, we experimented with the Collective Feedback Commission, as an experiment to cultivate a group of “core governors” that would function similarly to a core development program.\nWhile the work of the CFC has been valuable, the vision for the CFC doesn’t correspond to the next phase of governance, which is optimized to reduce platform risk. Allowing for governance participants to propose major changes to the governance system introduces a very high degree of platform risk.\nInstead of further developing the CFC, we will continue to reduce the metagovernance surface area to a minimal set of parameters in the Operating Manual. The Foundation currently maintains the Operating Manual, and is therefore responsible for updating these parameters. This is consistent with a governance system designed to maximize accountability, as the Foundation is ultimately accountable to the Token House. Over time, these parameters will be transitioned onchain and a permissioned process to update them will be introduced.\nFull explanation here\n\nCitizenship (Row 23):\n\nIn previous Seasons, we’ve experimented with many different Citizenship selection models - ranging from web-of-trust to random sampling - and we did not have a public or set definition of Citizenship.\nBased on the goal of reducing platform risk for the Superchain’s stakeholders and the learnings from all these experiments, we’ve updated our thinking about Citizenship and are taking a significant step forward by publishing objective Citizenship eligibility criteria as part of a coherent vision of Citizenship and governance.\nWhile the Foundation will continue to maintain this definition, the criteria themselves and the datasets that are used to calculate eligibility, will be public. Voting in the Citizens’ House will happen offchain, with individual ballots stored in a decentralized database as signed messages originating from addresses holding Citizen badges. This creates accountability as it allows third parties to verify the correct application of eligibility criteria and counting of votes.\nEventually, changes to the parameters within the Citizenship eligibility criteria will be subject to a governance process.\n\nA Note On Retro Funding:\n\nWhile not explicitly reflected in the Decentralization Milestones, we’ve continued to update our thinking on the level of governance involvement in Retro Funding.\nIn previous Seasons, we’ve experimented with different levels of Citizen involvement in the governance of Retro Funding - from Citizens voting on every individual project to merely selecting the algorithm that will reward projects.\nTo further optimize this process to reduce platform risk, we need to make the process more reliable and predictable for projects. This shift requires further minimizing the governance surface area, while maintaining accountability for those involved in running the program.\nThis means Citizens’ will no longer be asked to vote on Retro Funding algorithms. The Season 7 experiment revealed that voting on algorithms involves abstract technical and philosophical tradeoffs that are difficult for voters to reason about effectively, introducing platform risk.\nInstead, in Season 8, Retro Funding, as a program run by the Foundation, will utilize algorithms maintained by OSO. As always, community members are encouraged to share input and raise concerns via issues on the GitHub repo, ensuring OSO’s process stays transparent and responsive.\nIn the short term, the Citizens’ House will continue to hold Retro Funding accountable by voting on Mission budgets and scope. In the medium term, we aim to enable multiple organizations to run Retro Funding programs, creating additional accountability for the Retro Funding program. Our long-term vision is one where the Collective allocates tokens to the most token allocation programs.\n\nPlease reference the updated Decentralization Milestones and System Diagram to see the complete set of updates.\n\n Guide to Season 8\n\n Unlisted on Jun 12, 2025\n\n Listed on Jun 12, 2025\n\n post by GFXlabs on Jun 12, 2025\n\n GFXlabs\n\nCould you clarify what the current thinking is on the value proposition of OP tokens? This seems to suggest there is less appetite for the token to own many permissions or rights.\n\n 7 months later\n\n post by system on Jan 20\n\n system\n\n Following the progress made towards the Season 8 milestones, we’ve updated both the System Diagram and the Decentralization Milestones for Season 9. You can find historical references of previous versions in the tabs.\nThe milestones have been updated to reflect the below change log:\nTechnical Layer\n\nRemoved the row about Law of Chains enforcement as the Foundation envisions this document being used for guidance rather than strictly enforced\nUpdated the “Treasury Control” row to align with vision for Capital Allocation 2.0\n\nEconomic Layer\n\nRemoved the “Reward Allocations” row to align with vision for Capital Allocation 2.0\nUpdated the “Budgeting” row to reflect vision for Capital Allocation 2.0\nUpdated the “Sequencer Revenue” row to reflect “Buybacks”\n\nSocial Layer\n\nRemoved “Core Dev” and “Intent” rows as neither reflected meaningful progress towards decentralization\nAdded language to “Citizenship” and “Metagovernance” milestones to make them more specific\n\n Related topics\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 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 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.5k\n\n 29d\n\n The Path to Open Metagovernance\n\n 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.5k\n\n May 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 987\n\n Jul 15","tokens":3596,"squid":"spider-07","role":"Council Spider","at":1791346909732,"hash":"91a3800665398df48f98451346bf6e70a0256971"}
{"url":"https://gov.optimism.io/t/proposal-to-pause-governance-fund-voting-cycles-till-minimum-viable-decentralization-is-achieved/3215","domain":"gov.optimism.io","title":"Proposal to pause Governance Fund voting cycles till minimum viable decentralization is achieved - 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 Proposal to pause Governance Fund voting cycles till minimum viable decentralization is achieved \n\n Governance Design and Strategy 📐Metagovernance\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Aug 2022\n\n 1 / 27\n\n Aug 2022\n\n Dec 2022\n\n post by polynya on Aug 4, 2022\n\n polynya\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 hold complete rights to produce blocks and all funds in the bridge. I hold rollups to a much higher standard than this, a similar standard to Ethereum itself, and currently it’s not currently being met.\nOf course, I’m looking to be pragmatic and understand the lay of the crypto landscape - and acknowledging the competition - like Solana, Cardano, BSC, Arbitrum etc - are also very much unfinished, in different ways. This is an industry where people are willing to take massive risks on unfinished protocols, which is why I’m supporting Governance Fund proposals thus far. However, it’s important for this to not get out of hand. It’s not just that Optimism can run away with all our money - they have proven to be reputable entities - but it also comes with significant regulatory risk. If Optimism becomes a multi-billion dollar network, it’s almost certainly going to catch the attention of the authorities, particularly with its ties to the USA. The bigger the network gets, the exponentially greater the risk for a black swan event becomes. I believe Optimism should be focused on building for the long term, over a 10-year horizon. It’s not worth taking any undue risks in year 1.\nI believe we have achieved a pretty good spread of incentives across a number of protocols already, with incentives set to flow for the next 6 months or so. Some of the first projects have gone live with incentives, with a majority yet to follow. We have seen TVL and interest in Optimism skyrocket, and there’s more to come. The $OP token now sits at an FDV that’s only behind BTC, ETH, BNB, ADA and SOL, at this moment on par with DOT.\nThis is where we have to strike a balance, and pause further voting cycles till minimum viable decentralization has been achieved. To me, minimum viable decentralization looks like:\n\nNo backdoors for Optimism Foundation/OP Labs/centralized entities to the smart contracts. So, no centralized entities can make emergency upgrades without notice. Instead, most upgrades go through the regular governance vote, with an emergency council voted on by stakeholders. I have some thoughts on this earlier, but it can be simpler than this.\nSome simple way for anyone to build blocks if the Optimism Foundation/OP Labs sequencer goes offline, perhaps have a whitelist voted by governance that can just replace the sequencer. Properly decentralized sequencers not necessary, but hope to see build up to that.\nSemi-permissioned fraud proofs: Fraud proofs are live, and perhaps we can have a whitelist approved by Optimism Foundation and/or governance. Like sequencer, this is a 1-of-N assumption, so I’m not too concerned if it’s not permissionless to begin wtih - though that should certainly be expedited.\n\nIn short, it’s unacceptable that Optimism Fnd (and associates) holds a backdoor, there are no fraud proofs, and it’s not acceptable that only Optimism Fnd can produce blocks. To be clear, it’s fine if Optimism Fnd produces blocks most of the time, but there should be a backup if it cannot.\nSo, practically, what does the roadmap look like? We will certainly have to wait for Bedrock till these can be implemented, so I’m looking at Q2 2023. I expect current incentives to run though mid-Q1 2023, so there won’t be too much of a lag.\nFinally, I’m not saying we should shut down all Governance Fund proposals - we can definitely have a committee which pre-approves certain exceptional/urgent proposals that make a big impact with low risk. I’m just recommending pausing the traditional process and delaying Season 2 till MVD is achieved.\n\n Governance Weekly Recap\n\n Polynya - Delegate Communication Thread\n\n Re-designating the User Airdrop Allocation as the Strategic Ecosystem Fund\n\n 8\n\n 3\n\n 3\n\n 2\n\n read \n\n 11\n min\n\n post by TheDoctor on Aug 4, 2022\n\n TheDoctor\n\n I really get your point, but I don’t quite see that it’s a matter of waiting until certain decentralization is achieved. I would suggest a debate on what projects we should support in order to grow long-term sustainable growth.\nI think we need to change the usual speculative game and learn how to judge a proposal, not by how it sounds but by the ultimate incentives of the ones who have to develop that proposal. In other words: it’s not a matter to wait for optimism to be decentralized enough so we can fund proposals, but to be sure we’re not giving money to people promising great things with no intention to make them real.\n\n post by OPUser on Aug 4, 2022\n\n OPUser\n\n This is the third time you are raising this concern and i get the lack of engagement on your suggestion.\nI remember reading somewhere between this line\n“those who are not trying to fix the fault are the one gaining most from the said fault”\nWhat you are saying is true and in current form we do have problem that need to be fixed. Central block producer and no fraud proof is common concern i hear when i look beyond our gov echo chamber.\nusers not willing to move their fund from main net because of this and I cant prove this, consider this as just me intuition, whales and organizations are also waiting for these issue to be fixed before moving their funds over. Or may be those moving millions will simply stay on main net as they wont mind paying gas fee for the security of the L1.\nWe have a twitter space coming Monday on Bedrock, lets see if we get some time line on when it will be live.\nSo far we have distributed over 50M OP token which should run through Q1 23 like you have said and we can easily pause the fund distribution until then.\n\nothers might suggest, lets not pause but look at proposal individually which I dont agree with. If we continue to accept the proposal, I cant Vote No just because there is no fraud proof, its not their responsibility to implement it, then only option left for me is to Abstain.\n\nLets focus on OP Citizen house and complete at least one round of RPGF in next few months and we can resume gov fund early next year.\n\nI am small delegate and voting against or far has very little impact on final decision, but just putting my thoughts here and supporting this proposal.\n\n [Temp-Check] - Give Incentives to Solve Voters Apathy\n\n post by Prometheus on Aug 4, 2022\n\n Prometheus\n\nConsidering this and the risks we face. I would like to add the fact that some of the protocols/projects submitting proposal will face stronger stress and security tests in the coming months with more users taking advantages of current+approved incentives. This also means, more eyes and hackers ready to take advantage (reward is higher now than before).\nMeanwhile we have concerning attacks/exploits/whatever going around (none directly focused on optimism projects) nevertheless the risk is real and it seems to be increasing (it should be expected, nothing really new). On the other hand, if any project giving incentives via this grants is exploited I don’t need to say what the Optimism Collective may be forced to do.\n\nThat said, I don’t see any issue pausing the Governance Fund voting cycles until we reach some Minimum Viable Decentralization mechanism/strategy. We have enough incentives to keep momentum and pausing should incentive teams to improve what they already have, reaching better proposals in the future instead of rushing them. Also, I don’t want to see this trend of teams updating their proposals while the voting cycle is live. We need to improve how the governance works before we start the new season. Btw, I consider this part of the decentralization process.\n\n post by polynya on Aug 4, 2022\n\n polynya\n\n Thanks for the comments. I just want to stress that particularly the higher the TVL in Optimism’s (centrally controlled) bridge grows, the greater the risks. Of course, this is not the only risk - there are many others that come with a growing ecosystem - but this is the easily quantifiable one. This is the reasoning behind balancing $OP incentives, and not over-incentivizing so Optimism grows too big, and the risks increase exponentially. One approach would be to continue incentivizing protocols which may not incentivize TVL, but rather activity in some other way that does not directly increase this particular risk.\n\n post by MinimalGravitas on Aug 4, 2022\n\n MinimalGravitas\n\n This is a really interesting proposal, and one that’s had me thinking all day.\nI’m not quite so concerned about the regulatory factor, though obviously it’s relevant, the aspect that really seems important is that we’re creating incentive structures to encourage people to move their assets to Optimism, but without making it explicitly clear what the risks of doing so are, regarding the centralization factors you’ve listed (upgrade backdoor, the sequencer, lack of an escape hatch and lack of fraud proofs).\nI don’t feel as strongly as you that these must be in place before we process any more proposals, but I’m not dismissing that as a possibility.\nAs per our exchange earlier, I do think it matters where users are moving their funds from to onboard to Optimism, it would make a difference if they were sacrificing decentralization/security without realizing (e.g. moving from Ethereum and assuming that Optimism’s current model was some kind of a Platonic Optimistic rollup as described by EthHub or Finematics or something) or if they are moving from an equivalent or worse level of decentralization/security (from Boba/Metis etc or an Alt L1 like Solana or EOS). In the latter case I would not think we had any reason to feel guilty for encouraging the move!\nPart of the problem can probably be solved with information. If new and existing users are aware of the current state of Optimism and the future roadmap then they can make an informed choice and again, I don’t think there is a reason to stop encouraging them. This is obviously a difficult solution though as without control of all the bridges users are utilizing to onboard assets there isn’t really a way I can see that this information can be presented. Nevertheless, the foundation producing and promoting more info on what the rollup is now and what it will be like once the BedRock and Cannon upgrades are made would be an easy way to make some progress on this.\nOnce we have a clear roadmap, then perhaps it might be that your suggestion of pausing the onboarding incentives is the correct course of action, though like you say, that won’t mean all governance fund proposals, some (like Rotki which all of us in this thread voted for) aren’t really designed to increase Optimism’s TVL and so would presumably carry on.\n\n post by polynya on Aug 4, 2022\n\n polynya\n\n I’d definitely like to see some analysis on where the degens are coming from. Once again agreed that proposals that don’t really increase TVL or direct economic activity should be fine.\n\n post by Axel_T on Aug 5, 2022\n\n Axel_T\n\n TLDR: You’re highlighting critical risks that many have yet to consider and risks that need to be addressed, but the solution you’re suggesting is a red herring.\nI think this is most effective solution mentioned so far:\n\nAssuming all the mentioned risks can have a material impact on OP and the Collective, then education (i.e. well structured information) needs to be at the heart of the solution.\nWaiting for a utopian(?) level of decentralisation before carrying out key activities may hobble long-term progress as this may always be a stretch goal on the horizon, but keeping the community (and it’s new and prospective members) well informed via digestible resources can bridge some of the risks in the short to medium term.\nIf people have available resources to know all the risks, and ultimately the current stage of development of the project, then this will let people make there own decision as to whether they want to onboard to and remain with Optimism.\nMy suggestion (aside for resolving the technical flaws themselves) is to create educational resources/content that are either, or both, highlighted within official Optimism channels or extend beyond the internal community.\n\n post by polynya on Aug 5, 2022\n\n polynya\n\n It’s not a risk just for users, but also operators and the protocol itself. I’m definitely not waiting for any utopian level of decentralization - indeed the title calls it minimum viable decentralization. In an ideal world, even this would be pretty unacceptable, but I’m willing to recognize this is a space overwhelmed by degens and finding a compromise there.\n\n post by Axel_T on Aug 5, 2022\n\n Axel_T\n\n I’ll concede the “utopian” wording as an error, and accept your minimum viable decentralisation. But my point was about halting activity based on a subjective standard, as what’s minimum to you or another may not be the same, and this may lead to paralysis because we may never reach a point that make’s everyone happy. I hope this intention has been communicated better this time and I’m sorry for being extreme in my wording, i.e. “utopian”.\nAnd yes, I’m aware that this is a risk not only for users. That point was never meant to be in contention.\nThe overall goal of my reply was to (a) acknowledge the risks you are trying to bring to people’s attention, and appreciate your concern and motive (b) accept and agree that a minimum level of decentralisation must be achieved in the shortest space of time possible, which allows us to continue towards full decentralisation (c) but not necessarily agree that delaying Season 2 for 9 -12 months is the best course of action to address the valid concerns you raise, and (d) suggest that other solutions, in parallel with acting upon decentralisation, may be a preferable (although not perfect) course of action.\nThanks for your time @polynya\nEDIT: I’m open to compromise too. I think halting the Governance Fund activities for too long may stall the momentum and community activity that is one of Optimism’s non-technical advantages, and this is one of my fears of your proposal. But something akin to a 3-6 month pause of activity may both reduce the risk of too much OP circulating about, or locked up, too quickly prior to MVD and reduce the risk of this project stalling or becoming stale. I.e. I’m open to a shorter pause.\n\n post by MinimalGravitas on Aug 6, 2022\n\n MinimalGravitas\n\nJust to clarify, I don’t think this is a complete solution to the issue Polynya is raising. I don’t see how we can ensure that people aping in will be exposed to, for example the L2Beat page, or whatever form the education takes. If users understand accurately the security and decentralization of Optimism then I’ve got no objection to continuing to incentivize them to onboard funds, everyone is responsible for their own risk assessments, but I’m not entirely sure how possible it is to provide rollup literacy broadly enough.\n\n post by Joxes on Aug 6, 2022\n\n Joxes\n\n @polynya thank you for opening this discussion thread, awareness is the first step for good changes.\nIn this case I’m doing echo of not pause everything knowing that there are proposals that can genuinely contribute to the network and ecosystem and that it does not necessarily contribute to an “unstoppable” growth of TVL without taking into account also non-monetary use cases that are nice to have.\n\nCorrect, in fact I want tell you guys that I’m currently building with latam contributors an open community called L2 en Español where our first step is the understanding how early are these networks and should be considered as experimental. Again, in case of Optimism the awareness is, if you want to be early in its use and development, you will be indirectly rewarded with governance tokens in some way, and nothing more than that.\nBedrock is expected for Q4-2022, but even when the minimum viable decentralization is reached, is this acceptable in the criteria if we take it absolutely? Sadly this is no longer a problem that concerns only Optimism, but is part of the perhaps incomplete commitment of the Ethereum (network) in its future based on Rollups, where the exploits do not seem to be reversed in favor of the same community that encourages their development, and I’m always thinking about how the Ethereum community could mitigate major incidents (even if all neutrality is lost).\nFor now it is something that we will have to live with, it doesn’t matter if it has admin keys or not or how much centralized is, rollups are still far from passing the test of time (seen as safe, and enshrined rollups isn’t a real posibility for now) while at the same time they are the application that most concentrates the number of users.\nJust wanted to share these thoughts.\n\n post by norswap on Aug 8, 2022\n\n norswap\n\n (I work for OP Labs, but this is 100% my own opinion.)\nYour criticisms of the state of decentralization are of course valid. I would say they are well-taken, but honestly, we can’t really go towards these milestones any faster that we already are. We are focused on Bedrock, which is a pre-requisite for Cannon (fault proofs). Cannon will most likely be one of our next priorities.\nAs for suspending grants before these milestones, I believe if that’s what the Foundation wanted to do, it would simply have waited until these things were implemented to launch the token!\nI think we need to do things right, but we also need to stay relevant to people who care less about decentralization and more about other metrics, which right now means growing the ecosystem. Polygon has been on the extreme of pursuing this strategy, being a side-chain that is now aggressively investing into rollup technology. But they invested heavily in the growth of the system on the way there.\nThese things are not in tension: having governance distribute grants does not slow down the dev team in any way.\nIn terms of risk - these risks of course exist, though a technical point is that because of the withdrawal delay a lot can be done to mitigate issues that might occur. I’m more worried about the security of economic bridges in case of an incident (i.e. I’d really love to know that they are running replicas and are running custom on-chain monitoring).\n\n post by polynya on Aug 8, 2022\n\n polynya\n\n Surely you have to be worried about having billions of dollars in your contract and being sanctioned by the US Treasury? Optimism is operating as a central point of failure. The more TVL and economic activity you take on as a fully centralized chain, the greater your risk becomes. As mentioned above, an emergency council can achieve very much the same thing in terms of recovering from bridge failures, while mitigating centralization and regulatory risks. This would be more in line with Polygon PoS, as it stands currently Optimism is more centralized than Polygon PoS.\nI don’t want to belabour the point, though, it’s clear there’s not much support for this proposal - I just hope there’s a bit more awareness. So, I’ll just keep personally rejecting all proposals that pile on the above mentioned risks, particularly ones that come with significant regulatory risk.\n\n post by mattbtc on Aug 9, 2022\n\n mattbtc\n\n The security considerations are justified\n\n post by lefterisjp on Aug 9, 2022\n\n lefterisjp\n\nI completely agree with this. Would be nice to see some response from the foundation on this. I see @norswap from Labs commented but still would be nice to hear if there is any update on the roadmap and if going towards acceptable decentralization can go a bit faster.\nI think we can all agree for the reasons you stated Optimism is quite centralized at the moment. Even the governance shows this. We all vote on proposals, following guidelines set by the foundation and then we rely on their good will to execute. In a normal DAO the on-chain transfers for example would be controlled by the DAO/token holders.\nI get that things take time, but seeing a renewed timeline or commitment to true decentralization would mean a lot.\n\nNow for the question on whether to halt funding any grants until decentralization is achieved I am not sure I understand the connection there. Can you maybe explain in a bit clearer way @polynya? Is it for fear of consequences on the foundation since in reality it’s all under their control and disbursing funds to a project that turns out to be criminal could hit the foundation?\n\n post by polynya on Aug 9, 2022\n\n polynya\n\nI didn’t want to speculate on “what could go wrong” because usually the consequences of high risk and the resulting black swan events are often unanticipated. But consider that Optimism is basically like a CEX currently and comes with all of the same risks:\na) Due to negligence (malice I think is very unlikely), Optimism’s multi-sig is compromised, and the malicious entity executes an upgrade that could be as bad as draining all funds in the bridge.\nb) Hackers only need to target Optimism Foundation and its founders, employees etc. Or worse still, kidnappers looking for a steep ransom or whatever.\nc) US Treasury or some authority wants to sanction an app or a user on Optimism for whatever criminal activity. If it’s an immutable contract ala Tornado Cash, their best method of attack is to simply sanction members of Optimism - who as far as I know are US citizens. Now, the details of their multi-sig is very much obscured, and I also don’t know about which jurisdiction(s) Optimism Foundation comes under. But the fact that there’s no transparency about any of this is a big problem.\nd) Alternatively, an authority can force Optimism to censor certain users or dapps, enforce an irregular state transition, freeze funds - Optimism can do any of that, really, while Optimism Foundation maintains an emergency backdoor.\nNow, the bigger the TVL, the more the economic activity, Optimism becomes a signficantly bigger target. While its TVL is <$1B, it’s OK as a beta product. But as we go past $2B, and with more incentives flowing out unthrottled, it could be $5B, and it could end up being the biggest target after Ethereum itself. Ethereum is very difficult to attack, but Optimism - you just need to compromise their multi-sig.\nOf course, some may say all of this is dramatic and unrealistic, which is why I didn’t want to go into more details. But my answer is simple - Ethereum was designed to be maximally robust, decentralized and secure, that could survive under the most extreme of black swans. I’m holding Optimism to the same standard.\nI have suggested pragmatic steps multiple times - even moving to an timelocks + emergency council like zkSync has done for over 2 years now is a big step forward, versus a non-transparent multi-sig.\n\n post by Axel_T on Aug 9, 2022\n\n Axel_T\n\n You are absolutely NOT being:\n\nIrrespective of whether the Governance Fund is paused or not, I think these security and centralisation issues are critical. They are very high impact risks, and their likelihood increases in proportion to Optimism’s growth. Thanks for bringing this to the attention of the less initiated (like me!).\nWell done, and keep pushing. Let us know if there is anything any of us can do to help.\n\n post by ben-chain on Aug 10, 2022\n\n ben-chain\n\n Hey @polynya , thanks for voicing your concerns here in a thoughtful manner.\nI agree with much of the sentiment here. My primary takeaway is that we at the Foundation need to be doing a better job engaging with the community on the post-Bedrock roadmap. With Bedrock significantly simplifying the protocol, the path towards implementing many of the improvements you’ve listed becomes much more straightforward. We clearly haven’t talked publicly enough about this, and will work to correct that (in longer form prose) in the near future.\nSpeaking in my personal capacity, I’d say that, of the three points above, a security council seems like the lowest hanging fruit, with sequencer decentralization as a fast follow.\nAs for semi-permissioned fault proofs, I see this as a potentially useful milestone, but not as an outcome in and of itself. I want to emphasize the importance of a “weakest-link” security mindset and am wary of creating a false sense of security by implementing gadgets which do not fundamentally change the security model. At worst, these gadgets may even harm it by introducing complexity. All development milestones should be driven by what will bring the technology to production fastest.\nThe community (Foundation included) should absolutely continue to drive towards productionizing fault proofs, and a mainnet bug bounty with the proof system could be a useful milestone. But I do think it’s important that we decouple the conversation about security models from conversations about how best to productionize fault proofs, which has more to do with introducing redundancy than accelerating a permissioned rollout.\nAnyway, again, you are right to bring this up right now — it has been a very big topic internally even before your posts — and affirmative community engagement on this critical subject is invaluable. Really appreciate your deep thought as always, and look forward to picking this up soon!\n\n post by MinimalGravitas on Aug 10, 2022\n\n MinimalGravitas\n\nDo we take from this that there is already a plan for decentralization, it just hasn’t been shared yet?\nWhen this is made public, for my own take on these concerns I would really appreciate it if the current state is made explicitly clear. I think that users who don’t use L2Beat or read the documentation probably do not all understand the current centralization or potential risks and therefore would benefit from this being explained by the team. Maximum openness and education in your communications seems like a good strategy!\n\n Load more posts below","tokens":6530,"squid":"spider-07","role":"Council Spider","at":1791346919994,"hash":"799316ced7499dfb303e2eb572c909d160e0459c"}
{"url":"https://akash.network/docs/developers/deployment/cli/","domain":"akash.network","title":"Akash CLI | Akash Network - Your Guide to Decentralized Cloud","text":"Akash CLI Deploy and manage Akash applications using the Provider Services CLI.\nThe Provider Services CLI (provider-services) is the official command-line interface for deploying on Akash Network, providing full control over deployments with support for scripting and automation.\n\nIn This Section\nInstallation Guide\nInstall provider-services CLI, create a wallet, and fund your account.\nConfiguration\nConfigure network settings, RPC endpoints, and CLI preferences.\nCommands Reference\nComplete reference of all provider-services commands.\nCommon Tasks\nPractical examples for deployment, lease management, and troubleshooting.\nMint & Burn ACT\nUse akash tx bme commands to convert between AKT and ACT.\n\nQuick Links\n\nSDL Reference → - Deployment configuration syntax\nSDL Examples → - 290+ deployment examples\nDiscord Support → - Get help in #developers channel\n\nReady to start? Begin with the Installation Guide →! \nEdit page on github\n Commands Reference Installation","tokens":241,"squid":"spider-03","role":"Compute Spider","at":1791346941493,"hash":"1e5175080d864559b7c5c26faf15c0233842586c"}
{"url":"https://gov.optimism.io/t/pragmatic-first-step-towards-decentralizing-sequencer/2767","domain":"gov.optimism.io","title":"Pragmatic first step towards decentralizing sequencer - Communications 📣 / Delegates 🏛 - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n Pragmatic first step towards decentralizing sequencer \n\n Communications 📣Delegates 🏛\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 Aug 2022\n\n post by polynya on Jun 24, 2022\n\n polynya\n\n Governance forms a whitelist of sequencer operators ala Lido, and we rotate between them every epoch (e.g. X hours). Optimism Foundation retains rights as a reserve sequencer if the lead sequencer is offline. Can ask them to post up a bond in OP or ETH.\nNext step, whitelisted operators can participate in an auction, more sophisticated penalties/incentives. Final step: remove the whitelist, or implement whatever the final decentralization mechanism.\n\n OP as an MEV staking token\n\n Proposal to pause Governance Fund voting cycles till minimum viable decentralization is achieved\n\n Proposal: Pause Phase 1 and start a discussion round to improve the governance process\n\n Polynya - Delegate Communication Thread\n\n 1 month later\n\n post by smartcontracts on Aug 2, 2022\n\n smartcontracts\n\n Practically speaking, I think the pathway to sequencer decentralization likely needs to look like this:\n\nBedrock is a critical part of Sequencer decentralization because we can reintroduce a mempool (among a few other things). Unclear if the mempool will be public, but at least it can be shared by Sequencer nodes. This means we don’t lose transactions when we switch between sequencers. Anyway, this means Bedrock is a hard dependency.\nOnce we have Bedrock, we could start by having the foundation run multiple sequencer nodes that switch by round robin. Effectively the same as your proposal but the foundation runs all nodes. Allows us to build confidence in the design before going to external parties.\nMove towards a governance-controlled whitelist with the reserved foundation node, like you said.\n\n post by Prometheus on Aug 2, 2022\n\n Prometheus\n\nDropping links for people not that familiar with Bedrock.\n\n OP in Paris: Kelvin Fichter (low audio)\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Plans to decentralize the sequencer\n\n ✨ General\n\n Hello all, I was wondering if anyone has any resources on the different strategies that may be implemented for decentralizing L2 sequencers. I’d like to start doing some research on the topic because I am interested in r…\n\n read more\n\n 20\n\n 3.0k\n\n Jun 2023\n\n Use OP to decentralize the sequencer\n\n ✨ General\n\n Is it possible to eventually turn optimism into PoS and use the OP token to decentralize the sequencer? I saw a twitter thread from bankless and wanted to see what everyone thinks ? It would decentralize optimism while g…\n\n read more\n\n 2\n\n 1.8k\n\n Jun 2022\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 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 Decentralised sequencer\n\n ✨ General\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","tokens":931,"squid":"spider-07","role":"Council Spider","at":1791346943147,"hash":"4d1b00d81ff8e6ae5104251214b5b11b03746c44"}
{"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":"spider-05","role":"Spec Spider","at":1791346954460,"hash":"ef2689adcf9b09603b3f54ccea9d8bf3507c1cf8"}
{"url":"https://www.metaplex.com/docs/api/claim-creator-rewards","domain":"metaplex.com","title":"Metaplex API - Claim Creator Rewards | REST API | Metaplex","text":"Claim accrued creator rewards for a wallet across every Genesis bonding-curve and Raydium CPMM bucket the wallet is entitled to, in a single call. The endpoint returns a list of base64-encoded Solana transactions that the wallet (or a designated payer) must sign and submit. SDK wrapper availableMost integrators should use claimCreatorRewards from the Genesis JavaScript SDK — it deserializes the transactions, handles error parsing, and plugs directly into a Umi identity for signing. Call this endpoint directly only if you cannot depend on the SDK.SummaryPOST /v1/creator-rewards/claim returns the Solana transactions needed to claim a wallet's accrued creator rewards across every bonding-curve and Raydium CPMM bucket in a single call.Aggregation — one request claims across all eligible buckets; one transaction is returned per bucketSigning — response is base64-encoded Solana transactions the wallet (or optional payer) must sign and submitErrors — HTTP 400 \"No rewards available to claim\" when nothing has accrued; callers must branch on the error, not an empty arraySDK wrapper — claimCreatorRewards handles deserialization, typed errors, and Umi signingEndpointPOST /v1/creator-rewards/claim\nEnvironmentBase URLDevnet & Mainnethttps://api.metaplex.comRequest BodyFieldTypeRequiredDescriptionwalletstringYesBase58-encoded public key of the creator fee wallet to claim for. This is the wallet set as creatorFeeWallet on the bucket — or the launching wallet if no override was configured.networkstringNo'solana-mainnet' (default) or 'solana-devnet'. Must match the base URL's cluster.payerstringNoBase58-encoded public key that covers transaction fees and any rent on the returned transactions. Defaults to wallet when omitted.When to set payerSet payer to a different wallet when the creator fee wallet does not hold SOL (for example, an agent PDA or a cold wallet). The payer must sign the returned transactions, so it is typically the wallet submitting the claim on behalf of the creator. The creator fee recipient still receives the claimed SOL — payer only covers fees and rent.Example Request1import { claimCreatorRewards } from '@metaplex-foundation/genesis'\n2import { base58 } from '@metaplex-foundation/umi/serializers'\n3import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n4import { keypairIdentity } from '@metaplex-foundation/umi'\n5\n6const umi = createUmi('https://api.mainnet-beta.solana.com')\n7const keypair = umi.eddsa.createKeypairFromSecretKey(mySecretKeyBytes)\n8umi.use(keypairIdentity(keypair))\n9\n10const result = await claimCreatorRewards(umi, {}, {\n11 wallet: umi.identity.publicKey,\n12 network: 'solana-mainnet',\n13 // payer is optional — defaults to `wallet` on the server.\n14 // Set it to have a different wallet cover rent and transaction fees.\n15 // payer: umi.identity.publicKey,\n16})\n17\n18for (const tx of result.transactions) {\n19 const signed = await umi.identity.signTransaction(tx)\n20 const signature = await umi.rpc.sendTransaction(signed, {\n21 preflightCommitment: 'confirmed',\n22 })\n23 await umi.rpc.confirmTransaction(signature, {\n24 strategy: { type: 'blockhash', ...result.blockhash },\n25 commitment: 'confirmed',\n26 })\n27 console.log('Claimed:', base58.deserialize(signature)[0])\n28}\n29\n30// Claimed: 5uGGYEMmjP2HpyFCvLPNpVDSQEBtUE3LR6ZQFqhJxQSh5FbKacSyN8nQmAJowuFs6BTCdwzoFyyJz8Y2hQx8kPxo\n31// Claimed: 3TAroVovEap1ZEAJYq3WiDZoMK3GU3soCdrhvZJNg6b9EANqvWrVcDGNffm7mD8wvtpR7ynWQBcbrmz8AK6nrhfy\n1# Claim creator rewards. Response contains base64-encoded transactions\n2# the wallet (or payer) must sign and send.\n3curl -X POST https://api.metaplex.com/v1/creator-rewards/claim \\\n4 -H \"Content-Type: application/json\" \\\n5 -d '{\n6 \"wallet\": \"CREATOR_FEE_WALLET_ADDRESS_HERE\",\n7 \"network\": \"solana-mainnet\"\n8 }'\n9\n10# Add \"payer\" when the creator fee wallet does not hold SOL (e.g. an agent PDA):\n11# \"payer\": \"PAYER_WALLET_ADDRESS_HERE\"\n1# Claim creator rewards across all your bonding-curve and Raydium buckets.\n2# Defaults the wallet to the configured signer; network is auto-detected from RPC.\n3mplx genesis claim-creator-rewards\n4\n5# Claim on behalf of a different creator fee wallet (you still pay fees).\n6mplx genesis claim-creator-rewards --wallet <CREATOR_FEE_WALLET>\n7\n8# Force devnet and a specific API base URL.\n9mplx genesis claim-creator-rewards --network solana-devnet --apiUrl https://api.metaplex.dev\nSuccess Response{\n \"data\": {\n \"transactions\": [\"<base64 transaction>\", \"<base64 transaction>\"],\n \"blockhash\": {\n \"blockhash\": \"ERKYmtrmNSKaw3VpnFYAfK3jvWGnd15Nf9kJxZqJ7JHx\",\n \"lastValidBlockHeight\": 445407640\n }\n }\n}\nFieldTypeDescriptiondata.transactionsstring[]Base64-encoded Solana transactions. Each must be deserialized, signed by the payer (and the creator fee wallet if it is a separate signer), and submitted.data.blockhash.blockhashstringRecent blockhash the transactions were built against. Use this with confirmTransaction — do not replace it with a freshly fetched blockhash.data.blockhash.lastValidBlockHeightnumberSlot height after which the blockhash expires.The API returns one transaction per bucket being claimed — often two (bonding-curve plus Raydium). Submit them sequentially; their order is not significant.Error ResponseErrors are returned with HTTP status 400 and the shape:{ \"error\": { \"message\": \"No rewards available to claim\" } }\nKnown Error MessagesMessageHTTPCauseNo rewards available to claim400The wallet has no accrued-and-unclaimed creator rewards on any bucket. This is returned instead of an empty transactions array, so callers must handle it as a non-exceptional outcome.✖ Invalid wallet address400wallet is not a valid base58 Solana public key.No-rewards is a 400, not an empty arrayThe endpoint returns HTTP 400 with the message No rewards available to claim when a wallet has nothing to claim — it does not return 200 with transactions: []. Callers must catch the error (or inspect response.status and body.error.message) and treat this case as \"nothing to do\" rather than a failure. The SDK surfaces this as a typed GenesisApiError; see error handling.NotesThe endpoint is idempotent at the bucket level — calling it again immediately after a successful claim returns No rewards available to claim until new fees accrue.The returned transactions use the blockhash in data.blockhash. If confirmation takes longer than ~60–90 seconds, the blockhash will expire and the call must be repeated to get a fresh set of transactions.Creator rewards accrue on every swap (bonding curve) and from LP trading activity (Raydium CPMM) — this endpoint aggregates both. For the underlying accrual mechanics and per-bucket fetch helpers, see Creator Fees on the Genesis Bonding Curve.The creator fee wallet is set at bucket creation via creatorFeeWallet and cannot be changed after a curve goes live.Recommended: Use the SDKInstead of calling this endpoint directly, use claimCreatorRewards from @metaplex-foundation/genesis:claimCreatorRewards.ts1import { claimCreatorRewards } from '@metaplex-foundation/genesis'\n2import { base58 } from '@metaplex-foundation/umi/serializers'\n3import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n4import { keypairIdentity } from '@metaplex-foundation/umi'\n5\n6const umi = createUmi('https://api.mainnet-beta.solana.com')\n7const keypair = umi.eddsa.createKeypairFromSecretKey(mySecretKeyBytes)\n8umi.use(keypairIdentity(keypair))\n9\n10const result = await claimCreatorRewards(umi, {}, {\n11 wallet: umi.identity.publicKey,\n12 network: 'solana-mainnet',\n13 // payer is optional — defaults to `wallet` on the server.\n14 // Set it to have a different wallet cover rent and transaction fees.\n15 // payer: umi.identity.publicKey,\n16})\n17\n18for (const tx of result.transactions) {\n19 const signed = await umi.identity.signTransaction(tx)\n20 const signature = await umi.rpc.sendTransaction(signed, {\n21 preflightCommitment: 'confirmed',\n22 })\n23 await umi.rpc.confirmTransaction(signature, {\n24 strategy: { type: 'blockhash', ...result.blockhash },\n25 commitment: 'confirmed',\n26 })\n27 console.log('Claimed:', base58.deserialize(signature)[0])\n28}\n29\n30// Claimed: 5uGGYEMmjP2HpyFCvLPNpVDSQEBtUE3LR6ZQFqhJxQSh5FbKacSyN8nQmAJowuFs6BTCdwzoFyyJz8Y2hQx8kPxo\n31// Claimed: 3TAroVovEap1ZEAJYq3WiDZoMK3GU3soCdrhvZJNg6b9EANqvWrVcDGNffm7mD8wvtpR7ynWQBcbrmz8AK6nrhfy\nSee the API Client page for the full SDK surface, and Creator Fees for the end-to-end claim guide.","tokens":2099,"squid":"dotcat","role":"Tooling Spider","at":1791346957254,"hash":"38999427724d3173104c50244e6d614500763385"}
{"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,067,391,403FiatUSDC (opens in a new tab)USDC$74,128,696,518FiatUSDS (opens in a new tab)USDS$10,119,988,737CryptoEthena USDe (opens in a new tab)USDe$4,965,907,344CryptoDai (opens in a new tab)DAI$4,590,805,743CryptoPayPal USD (opens in a new tab)PYUSD$2,910,667,085FiatRipple USD (opens in a new tab)RLUSD$2,500,190,891FiatUSDD (opens in a new tab)USDD$1,559,581,823CryptoGHO (opens in a new tab)GHO$698,496,627CryptoUsual USD (opens in a new tab)USD0$542,686,387FiatHow 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 makes stablecoins unique?","tokens":1849,"squid":"spider-05","role":"Spec Spider","at":1791346964573,"hash":"8408517374c0a0a27ba55d289ad6669f0a2433d2"}
{"url":"https://blog.openzeppelin.com/proxy-patterns/","domain":"blog.openzeppelin.com","title":"Proxy Patterns - OpenZeppelin blog","text":"April 19, 2018OpenZeppelinThank 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.By Elena Nadolinski in collaboration with Facu Spagnuolo. Thank you!Update December 2018: Since this article was originally published, we have been working hard at ZeppelinOS on refining the proxy patterns we use on our libraries. Read here about the decisions we arrived at, and check out the ZeppelinOS audited implementation of those patterns.One of the biggest advantages of Ethereum is that every transaction of moving funds, every contract deployed, and every transaction made to a contract is immutable on a public ledger we call the blockchain. There is no way to hide or amend any transactions ever made. The huge benefit is that any node on the Ethereum network can verify the validity and state of every transaction making Ethereum a very robust decentralized system.But the biggest disadvantage is that you cannot change the source code of your smart contract after it’s been deployed. Developers working on centralized applications (like Facebook, or Airbnb) are used to frequent updates in order to fix bugs or introduce new features. This is impossible to do on Ethereum with traditional patterns.Remember the infamous Parity Wallet Multisig hack where 150,000 ETH were stolen? During the attack, a bug was being exploited in the Parity multisig wallet contract and high profile wallets were being drained of their funds. The only reconciliation that could be done was to try and be faster than the hacker and exploit the same vulnerability to hack the remaining wallets to redistribute the ETH to their rightful owners after the attack.If only there were a way to update the source code after the smart contract has been deployed…Introducing Proxy PatternsAlthough it is not possible to upgrade the code of your already deployed smart contract, it is possible to set-up a proxy contract architecture that will allow you to use new deployed contracts as if your main logic had been upgraded.A proxy architecture pattern is such that all message calls go through a Proxy contract that will redirect them to the latest deployed contract logic. To upgrade, a new version of your contract is deployed, and the Proxy is updated to reference the new contract address.Zeppelin has been working on several proxy patterns as part of their effort to implement zeppelin_os. The three options explored are:Inherited StorageEternal StorageUnstructured StorageAll three patterns rely on low-level delegatecalls. Although Solidity provides a delegatecall function, it only returns true/false whether the call succeeded and doesn’t allow you to manage the returned data.Before we dive-in, there are two key concepts that are important to understand:When a function call to a contract is made that it does not support, the fallback function will be called. You can write a custom fallback function to handle such scenarios. The proxy contract uses a custom fallback function to redirect calls to other contract implementations.Whenever a contract A delegates a call to another contract B, it executes the code of contract B in the context of contract A. This means that msg.value and msg.sender values will be kept and every storage modification will impact the storage of contract A.Zeppelin’s Proxy contract, shared by all proxy patterns, implements its own delegatecall function for this particular reason which returns the value that resulted in calling the logic contract. If you’re planning on using Zeppelin’s Proxy contract code, you should understand in full detail the code you’ll be using. Let’s explore exactly how it works and understand the assembly opcodes it uses to achieve this. (Feel free to reference Solidity’s Assembly docs to get more information)[assembly {\n let ptr := mload(0x40)\n calldatacopy(ptr, 0, calldatasize)\n let result := delegatecall(gas, _impl, ptr, calldatasize, 0, 0)\n let size := returndatasize\n returndatacopy(ptr, 0, size)\n\n switch result\n case 0 { revert(ptr, size) }\n default { return(ptr, size) }\n }In order to delegate a call to another solidity contract function we have to pass it the msg.data the proxy received. Since msg.data is of type bytes, a dynamic data structure, it has a varying size that is stored in the first word size (of 32 bytes) in msg.data. If we wanted to extract just the actual data, we would need to step over the first word size, and start at 0x20 (32 bytes) of msg.data. However, there are two opcodes we’ll leverage to do this instead. We’ll use calldatasize to get the size of msg.data and calldatacopy to copy it over to our ptr variable.Notice how we initialize our ptr variable. In Solidity, the memory slot at position 0x40 is special as it contains the value for the next available free memory pointer. Every time you save a variable directly to memory, you should consult where you should save it to by checking the value at 0x40. Now that we know where we’re allowed to save a variable, we can use calldatacopy to copy calldata of size calldatasize starting from 0 of call data to location at ptr.let ptr := mload(0x40)\ncalldatacopy(ptr, 0, calldatasize)Let’s look at the following line in the assembly block that uses the delegatecall opcode:let result := delegatecall(gas, _impl, ptr, calldatasize, 0, 0)Parametersgas we pass in the gas needed to execute the function_impl the address of the logic contract we’re callingptr the memory pointer for where data startscalldatasize the size of the data we’re passing.0 for data out representing the returned value from calling the logic contract. This is unused because we do not yet know the size of data out and therefore cannot assign it to a variable. We can still access this information using returndata opcode later0 for size out. This is unused because we didn’t get a chance to create a temp variable to store data out, since we didn’t know the size of it prior to calling the other contract. We can get this value using an alternative way by calling the returndatasize opcode laterThe next line grabs the size of the returned data using the returndatasize opcodelet size := returndatasizeAnd we use the size of the returned data to copy over the contents of returned data to our ptr variable with a helper opcode function returndatacopyreturndatacopy(ptr, 0, size)Lastly, the switch statement returns either the returned data or throws an exception if something went wrong.Great, we now have a way to retrieve the appropriate resulting value from the logic contract.Now that we understand how the Proxy contract works, let’s look at Zeppelin’s three proposed patterns: Upgradeability using Inherited Storage, Unstructured Storage, and Eternal Storage.The three approaches have different ways to tackle the same technical difficulty: how to ensure that the logic contract does not overwrite state variables that are used in the proxy for upgradeability.The main concern with any proxy architecture pattern is how to handle storage allocation. Bear in mind that since we are using one contract for the storage and another for the logic, any one of them could potentially overwrite an already used storage slot. This means that if the Proxy contract has a state variable to keep track of the latest logic contract address at some storage slot and the logic contract doesn’t know about it, then the logic contract could store some other data in the same slot thus overwriting the proxy’s critical information. Zeppelin’s three approaches present different ways to architect your system to make your contracts upgradeable via a proxy pattern.Upgradeability using Inherited StorageThe Inherited Storage approach relies on making the logic contract incorporate the storage structure required by the proxy. Both the proxy and the logic contract inherit the same storage structure to ensure that both adhere to storing the necessary proxy state variables.While exploring this approach we tried the idea of having a Registry contract to keep track of the different versions of your logic contract. In order to upgrade to a new logic contract you will need to register it as a new version in the Registry and ask the proxy to upgrade to it. Note that having a Registry does not affect the storage mechanism; in fact it could be implemented in any of the storage patterns showed in this post.How to InitializeDeploy a Registry contractDeploy an initial version of your contract (v1). Make sure it inherits the Upgradeable contractRegister the address of your initial version to the RegistryAsk the Registry contract to create an UpgradeabilityProxy instanceCall your UpgradeabilityProxy to upgrade to the initial version of the contractHow to UpgradeDeploy a new version of your contract (v2) that inherits from your initial version to make sure it keeps the storage structure of the proxy and the one in the initial version of your contract.Register the new version of your contract to the RegistryCall your UpgradeabilityProxy instance to upgrade to the new registered version.Key TakeawaysWe can introduce upgraded functions as well as new functions and new state variables in future deployed logic contracts by still calling the same UpgradeabilityProxy contract.Upgradeability using Eternal StorageIn the Eternal Storage pattern, the storage schemas are defined in a separate contract that both the proxy and logic contract inherit from. The storage contract holds all the state variables the logic contract will need, and since the proxy is aware of them too, it can define its own state variables necessary for upgradeability without the concern of them being overwritten. Note that all future versions of the logic contract should not define any other state variable. All versions of the logic contract must always use the eternal storage structure defined in the beginning.This implementation provided in the Zeppelin’s labs repository also introduces the concept of proxy ownership. A proxy owner is the only address that can upgrade a proxy to point to a new logic contract, and the only address that can transfer ownership.How to InitializeDeploy an EternalStorageProxy instanceDeploy an initial version of your contract (v1)Call your EternalStorageProxy instance to upgrade to the address of your initial versionIf your logic contract relies on its constructor to set up some initial state, that would have to be redone after its linked to the proxy since the proxy’s storage doesn’t know about those values. EternalStorageProxy has a function upgradeToAndCall specifically to call some function on your logic contract to redo the setup after the proxy upgrades to it.How to UpgradeDeploy a new version of your contract (v2) making sure it holds the eternal storage structure.Call your EternalStorageProxy instance to upgrade to the new version.Key TakeawaysIntuitive approach without significant overhead for the token logic contract. Future logic contacts can upgrade existing methods and introduce new ones, but should not introduce new state variables.Upgradeability using Unstructured StorageThe Unstructured Storage pattern is similar to Inherited Storage but doesn’t require the logic contract to inherit any state variables associated with upgradeability. This pattern uses an unstructured storage slot defined in the proxy contract to save the data required for upgradeability.In the proxy contract we define a constant variable that, when hashed, should give a random enough storage position to store the address of the logic contract that the proxy should call to.bytes32 private constant implementationPosition = \nkeccak256(\"org.zeppelinos.proxy.implementation\");Since constant state variables do not occupy storage slots, there’s no concern of the implementationPosition being accidentally overwritten by the logic contract. Due to how Solidity lays out its state variables in storage there is extremely little chance of collision of this storage slot being used by something else defined in the logic contract.By using this pattern, none of the logic contract versions have to know about the storage structure of the proxy, however all future logic contracts must inherit the storage variables declared by their ancestor versions. Just like in Inherited Storage pattern, future upgraded token logic contracts can upgrade existing functions as well as introduce new functions and new storage variables.This implementation provided in the Zeppelin’s labs repository also uses the concept of proxy ownership. A proxy owner is the only address that can upgrade a proxy to point to a new logic contract, and the only address that can transfer ownership.How to InitializeDeploy an OwnedUpgradeabilityProxy instanceDeploy an initial version of your contract (v1)Call your OwnedUpgradeabilityProxy instance to upgrade to the address of your initial versionIf your logic contract relies on its constructor to set up some initial state, that would have to be redone after its linked to the proxy since the proxy’s storage doesn’t know about those values. OwnedUpgradeabilityProxy has a function upgradeToAndCall specifically to call some function on your logic contract to redo the setup after the proxy upgrades to it.How to UpgradeDeploy a new version of your contract (v2) making sure it inherits the state variable structures used in previous versions.Call your OwnedUpgradeabilityProxy instance to upgrade to the address of your new contract version.Key TakeawaysThis approach is great as it does not require the Token logic contract to be aware whatsoever that it is part of a Proxy contract system.On UpgradeabilityImportant: if your logic contract relies on its constructor to set up some initial state, this has to be redone after the proxy upgrades to your logic contract. For example, it’s common for logic contracts to inherit from Zeppelin’s Ownable contract implementation. When your logic contract inherits from Ownable, it also inherits Ownable’s constructor that sets who the owner is upon contract creation. When you link the proxy contract to use your logic contract, the value of who the owner is from the proxy’s perspective is lost.A common pattern for upgrading the proxy contract is that the proxy to immediately call an initialize method on the logic contract. The initialize method should mimic everything you would traditionally put in a constructor. You would also want to include a flag so that you can’t initialize a logic contract more than once.Your logic contract should then look something like this:[contract Token is Ownable {\n ...\n bool internal _initialized;\n\n function initialize(address owner) public {\n require(!_initialized);\n setOwner(owner);\n _initialized = true;\n }\n ...\n}Depending on your deployment strategy, you could either have a helper deployer contract, or you could deploy the proxy and logic contract separately. If you deploy separately, you would link the proxy to your logic contract using upgradeToAndCall that might look something like this:[const initializeData = encodeCall('initialize', ['address'], [tokenOwner]) await proxy.upgradeToAndCall(logicContract.address, initializeData, {\n from: proxyOwner\n})ConclusionThe concept of proxy patterns has been around for awhile, but hasn’t received wide adoption due to its complexity, fear of introducing security vulnerabilities, and the controversy of bypassing blockchain’s immutability. Past solutions are also fairly inflexible requiring future logic contracts to be severely limited in what they can amend and add. However, it’s clear from a developer standpoint that there is a great need for the ability to upgrade contracts. Zeppelin has provided the code and tests for the three proxy patterns they explored to help developers architect their projects to incorporate upgradeability.Even though the concept of proxy patterns isn’t new, its adoption is still early, and it’s exciting to see more advanced DApp architectures being achieved with this paradigm. If you built something with proxy patterns, let me and Zeppelin know on Twitter, and then join the Zeppelin slack channel to show it off there too 🙂Further ReadingAs part of Zeppelin’s effort to implement zeppelin_os, a distributed platform of tools and services on top of the EVM, the Zeppelin team is currently moving forward with the Unstructured Storage approach. The Unstructured Storage approach has huge advantages of requiring the bare minimum implementation from logic contracts by introducing a novel way to maintain the proxy’s needed storage. Feel free to read more about Zeppelin’s choice of using Unstructured Storage for their upcoming release of zeppelin_os Kernel.Zeppelin also posted a detailed technical blog on Eternal Storage.Over a year ago, Aragon and Zeppelin have teamed up to write two blog posts on Proxy Libraries that can be found here.Arachnid, or Nick Johnson, core developer on go-ethereum, lead developer of ENS, has written about his take on Upgradeable & Dispatcher contracts in this gist that he published over 2 years ago.If you’re looking to build something simple and won’t foresee huge changes in your future contracts, you might consider looking at this very simple example.Solidity docs are always helpful and I recommend looking at the doc’s for Solidity’s delegate call function and assembly opcodes.All diagrams were made with this Figma file that you are free to duplicate for your own diagrams 🙂Update December 2018: Since this article was originally published, we have been working hard at ZeppelinOS on refining the proxy patterns we use on our libraries. Read here about the decisions we arrived at, and check out the ZeppelinOS audited implementation of those patterns.","tokens":4461,"squid":"spider-06","role":"Security Spider","at":1791346964833,"hash":"deb033c413000a4e81309c179e73ca32a000d814"}
{"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:Ethereum payments can be programmable. What does that make possible?","tokens":3267,"squid":"spider-05","role":"Spec Spider","at":1791346976840,"hash":"02a69c8abedb91099f813f86176c3c32bba6dfbc"}
{"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":"spider-06","role":"Security Spider","at":1791346976936,"hash":"34c83276e2bd6a7daa7a499477e2e798c82dc42f"}
{"url":"https://www.metaplex.com/docs/api/verify-twitter","domain":"metaplex.com","title":"Metaplex API - Verify Twitter | REST API | Metaplex","text":"Exchange a Twitter (X) OAuth access token for a short-lived verification token that proves ownership of a Twitter account. Pass the token to Register Launch to have the launch's Twitter link marked as verified. SummaryVerifies a user-supplied Twitter OAuth 2.0 access token against the X APIReturns the account's username and a signed verification tokenThe token is consumed by POST /launches/register via its optional twitterVerificationToken fieldQuick ReferenceItemValueMethodPOSTPath/twitter/verifyAuthNone (the Twitter access token is the credential)ResponseUsername + verification tokenEndpointPOST /twitter/verify\nRequest BodyFieldTypeRequiredDescriptionaccessTokenstringYesA Twitter OAuth 2.0 user access token obtained by your application (must be authorized for users.read).Example Requestcurl -X POST \"https://api.metaplex.com/v1/twitter/verify\" \\\n -H \"Content-Type: application/json\" \\\n -d '{ \"accessToken\": \"<twitter-oauth-access-token>\" }'\nResponse{\n \"success\": true,\n \"username\": \"mytoken\",\n \"token\": \"<verification-token>\"\n}\nPass token as twitterVerificationToken when calling Register Launch. The API compares the token's username against the handle in launch.externalLinks.twitter and marks the link verified on match.ErrorsStatusBodyMeaning400{ \"success\": false, \"error\": \"accessToken is required\" }Missing or empty accessToken.401{ \"success\": false, \"error\": \"Could not verify Twitter account\" }The X API rejected the access token.502{ \"success\": false, \"error\": \"Could not retrieve Twitter username\" }The X API responded without a username.NotesObtaining the OAuth access token (the user consent flow) is your application's responsibility; this endpoint only validates it and issues the verification token.Verification is optional — launches register successfully without it, their Twitter link is simply left unverified.","tokens":461,"squid":"dotcat","role":"Tooling Spider","at":1791346977118,"hash":"838b6d857063ce89508ad36cb818f7cec715947a"}
{"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":"spider-05","role":"Spec Spider","at":1791346986767,"hash":"eaa15cd5ee3d181e5b74eddf7355eb9d5734aabd"}
{"url":"https://openzeppelin.com/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":"spider-06","role":"Security Spider","at":1791346988800,"hash":"f125c2a174d4661f7fb7d834387f270036bda48d"}
{"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":"spider-05","role":"Spec Spider","at":1791346996734,"hash":"b56bcd9a10b353b2f7cb7e8cd79541b4a97afc06"}
{"url":"https://www.metaplex.com/docs/api/list-agents","domain":"metaplex.com","title":"Metaplex API - List Agents | REST API | Metaplex","text":"Browse and search the agent registry. Returns paginated agent records from the indexed database, sorted by latest registration by default. SummaryList registered agents with optional full-text search, filters, and sorting. Results are always paginated.Search by name with queryFilter by activeOnly, hasAgentToken, hasServices, and spotlightSort by latest (default) or oldest registrationDefaults to page 1 with 24 results per page (max pageSize is 100)Quick ReferenceItemValueMethodGETPath/agentsAuthNoneResponsePaginated AgentRecord[]Paginationpage / pageSizeEndpointGET /agents\nQuery ParametersParameterTypeRequiredDescriptionnetworkstringNoNetwork to query. Default: solana-mainnet. Use solana-devnet for devnet.pagenumberNoPage number, starting at 1. Default: 1.pageSizenumberNoResults per page, 1–100. Default: 24.querystringNoFree-text search over agent names.sortstringNolatest (default) or oldest — by registration time.activeOnlybooleanNoOnly agents whose EIP-8004 metadata marks them active.hasAgentTokenbooleanNoOnly agents with a primary agent token set.hasServicesbooleanNoOnly agents advertising service endpoints.spotlightbooleanNoOnly agents spotlighted on the discover page.Example Requestcurl \"https://api.metaplex.com/v1/agents?pageSize=10&sort=latest&activeOnly=true\"\nResponse{\n \"success\": true,\n \"data\": {\n \"agents\": [\n {\n \"mintAddress\": \"7nE9GvcwsqzYcPUYfm5gxzCKfmPqi68FM7gPaSfG6EQN\",\n \"network\": \"solana-mainnet\",\n \"name\": \"Example Agent\",\n \"description\": \"An autonomous trading agent.\",\n \"image\": \"https://example.com/agent.png\",\n \"walletAddress\": \"9xQeWvG816bUx9EPjHmaT23yvVM2ZWbrrpZb9PusVFin\",\n \"authority\": \"4Nd1mYvJ9jVexjIXG5oJhanoGWyF7Cz6XkY8dEc4RsyG\",\n \"agentToken\": \"EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v\",\n \"agentMetadataUri\": \"https://api.metaplex.com/v1/agents/7nE9.../agent-card.json\",\n \"metadata\": { \"…\": \"EIP-8004 registration JSON\" },\n \"a2aCard\": { \"…\": \"A2A AgentCard (spec §4.4)\" },\n \"isActive\": true,\n \"registrationSignature\": \"5J8…\",\n \"indexedAt\": \"2026-07-01T12:00:00.000Z\",\n \"spotlightedAt\": null,\n \"verifiedAt\": null,\n \"createdAt\": \"2026-07-01T11:59:58.000Z\",\n \"updatedAt\": \"2026-07-15T09:30:00.000Z\"\n }\n ],\n \"total\": 132,\n \"page\": 1,\n \"pageSize\": 10,\n \"totalPages\": 14\n }\n}\nResponse TypeTypeScriptinterface PaginatedAgentsResponse {\n success: true;\n data: {\n agents: AgentRecord[];\n total: number;\n page: number;\n pageSize: number;\n totalPages: number;\n };\n}\n\ninterface AgentRecord {\n /** Core asset mint address (the NFT representing this agent) */\n mintAddress: string;\n network: string;\n name: string;\n description: string;\n image: string | null;\n /** The agent's signer PDA wallet, derived from the Core asset */\n walletAddress: string;\n /** Update authority of the Core asset */\n authority: string | null;\n /** Primary token mint, set via the setAgentToken instruction */\n agentToken: string | null;\n agentMetadataUri: string | null;\n /** EIP-8004 agent registration JSON */\n metadata: Record<string, unknown> | null;\n /** Hosted A2A AgentCard (spec §4.4) */\n a2aCard: Record<string, unknown> | null;\n isActive: boolean;\n registrationSignature: string | null;\n indexedAt: string | null;\n spotlightedAt: string | null;\n verifiedAt: string | null;\n createdAt: string;\n updatedAt: string;\n}\nUsage ExamplesTypeScriptconst response = await fetch(\n \"https://api.metaplex.com/v1/agents?pageSize=10&activeOnly=true\"\n);\nconst result: PaginatedAgentsResponse = await response.json();\nif (result.success) {\n const { agents, total, totalPages } = result.data;\n console.log(`${agents.length} of ${total} agents (${totalPages} pages)`);\n}\nRustlet response = reqwest::get(\n \"https://api.metaplex.com/v1/agents?pageSize=10&activeOnly=true\"\n)\n.await?\n.json::<serde_json::Value>()\n.await?;\n\nif response[\"success\"].as_bool() == Some(true) {\n if let Some(agents) = response[\"data\"][\"agents\"].as_array() {\n println!(\"{} agents on this page\", agents.len());\n }\n} else {\n eprintln!(\"API error: {}\", response[\"error\"]);\n}\nNotesResults come from the indexed database, not a live on-chain scan; newly minted agents appear once their registration transaction has been indexed.Boolean filters accept true/false string values.The response uses the success envelope — see the Agent API overview for details.","tokens":1059,"squid":"dotcat","role":"Tooling Spider","at":1791346996951,"hash":"4ffc1ac33194c010a14a8e6dae7694ef67ce873f"}
{"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":"spider-06","role":"Security Spider","at":1791346998949,"hash":"2808a1ceca6648973b8b93dac1a6ddb55920c690"}
{"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":"spider-05","role":"Spec Spider","at":1791347006750,"hash":"c2a7d2674d5b32da293e0646bd889ccda2f93ee3"}
{"url":"https://www.metaplex.com/docs/api/get-spotlight","domain":"metaplex.com","title":"Metaplex API - Get Spotlight | REST API | Metaplex","text":"Retrieve featured spotlight launches curated by the platform. Use this endpoint to highlight selected launches in your application. SummaryFetch launches that have been curated as spotlights by the platform. This is a convenience filter on the /launches endpoint with spotlight=true pre-applied.Returns an array of LaunchData objects where spotlight is trueCan be further filtered by status (upcoming, live, graduated)Each entry includes launch details, base token metadata, and social linksSupports mainnet (default) and devnet via network query parameterQuick ReferenceItemValueMethodGETPath/launches?spotlight=trueAuthNoneResponseLaunchData[]PaginationNoneEndpointGET /launches?spotlight=true\nQuery ParametersParameterTypeRequiredDescriptionnetworkstringNoNetwork to query. Default: solana-mainnet. Use solana-devnet for devnet.statusstringNoFilter by status: upcoming, live, graduated. Default: returns all.Example Requestcurl \"https://api.metaplex.com/v1/launches?spotlight=true\"\nResponse{\n \"data\": [\n {\n \"launch\": {\n \"launchPage\": \"https://example.com/launch/mytoken\",\n \"mechanic\": \"launchpoolV2\",\n \"genesisAddress\": \"7nE9GvcwsqzYcPUYfm5gxzCKfmPqi68FM7gPaSfG6EQN\",\n \"spotlight\": true,\n \"startTime\": \"2026-01-15T14:00:00.000Z\",\n \"endTime\": \"2026-01-15T18:00:00.000Z\",\n \"status\": \"live\",\n \"heroUrl\": \"launches/abc123/hero.webp\",\n \"graduatedAt\": null,\n \"lastActivityAt\": \"2026-01-15T16:30:00.000Z\",\n \"type\": \"launchpool\"\n },\n \"baseToken\": {\n \"address\": \"EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v\",\n \"name\": \"My Token\",\n \"symbol\": \"MTK\",\n \"image\": \"https://example.com/token-image.png\",\n \"description\": \"A community-driven token for the example ecosystem.\"\n },\n \"website\": \"https://example.com\",\n \"socials\": {\n \"x\": \"https://x.com/mytoken\",\n \"telegram\": \"https://t.me/mytoken\",\n \"discord\": \"https://discord.gg/mytoken\"\n }\n }\n ]\n}\nResponse TypeSee Shared Types for Launch, BaseToken, and Socials definitions.TypeScriptinterface LaunchData {\n launch: Launch;\n baseToken: BaseToken;\n website: string;\n socials: Socials;\n}\n\ninterface SpotlightResponse {\n data: LaunchData[];\n}\nRust#[derive(Debug, Serialize, Deserialize)]\n#[serde(rename_all = \"camelCase\")]\npub struct LaunchData {\n pub launch: Launch,\n pub base_token: BaseToken,\n pub website: String,\n pub socials: Socials,\n}\n\n#[derive(Debug, Serialize, Deserialize)]\npub struct SpotlightResponse {\n pub data: Vec<LaunchData>,\n}\nUsage ExamplesTypeScriptconst response = await fetch(\n \"https://api.metaplex.com/v1/launches?spotlight=true\"\n);\nconst { data }: SpotlightResponse = await response.json();\ndata.forEach((entry) => {\n console.log(entry.baseToken.name, entry.launch.type);\n});\nRustlet response: SpotlightResponse = reqwest::get(\n \"https://api.metaplex.com/v1/launches?spotlight=true\"\n)\n.await?\n.json()\n.await?;\n\nfor entry in &response.data {\n println!(\"{}\", entry.base_token.name);\n}\nNotesSpotlight status is curated by the platform and cannot be set via the API.This endpoint uses the same /launches route with spotlight=true as a query parameter — it is not a separate endpoint.The mechanic field indicates the allocation mechanism (e.g., launchpoolV2, presaleV2, bondingCurveV2). The type field indicates the underlying launch mechanism (launchpool, presale, or bondingCurve).","tokens":810,"squid":"dotcat","role":"Tooling Spider","at":1791347016903,"hash":"17e25b6418ac8cc2f9465968217115cdd73c1a1f"}
{"url":"https://ethresear.ch/t/endgame-staking-economics-a-case-for-targeting/18751/37","domain":"ethresear.ch","title":"Endgame Staking Economics: A Case for Targeting - Proof-of-Stake / Economics - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 6\n\n 4\n\n 2\n\n 2\n\n 2\n\n read \n\n 32\n min\n\n Feb 2024\n\n 36 / 37\n\n Apr 2025\n\n Apr 2025\n\n Load more posts above\n\n post by danw.eth on Mar 2, 2024\n\n danw.eth\n\n Hi,\nThis is an interesting problem, thank you for the detailed writeup and acknowledging solo stakers might suffer more from targeting.\nI’m a solo home staker, with several validators and rocketpool minipools (and intention for future DVT participation).\nThere’s just a few assumptions/comments I’d like to challenge:\n\nI think it’s a misconception that it’s not viable to hold ETH without a yield. Bitcoin is held without a mining yield, and the recent ETF flows have proven that people don’t need a yield to simply hold an asset. In addition, the issuance/inflation is higher for Bitcoin than it is for Ethereum after EIP 1559.\nEven so I acknowledge humans will chase small amounts of yield wherever it is, as seen through 2021-2022 and all the problems it caused.\n\nThe initial cost of staking hardware really is not expensive compared to the ongoing monetary and non-monetary costs. In addition since it’s a sunk cost it wouldn’t really contribute to the decision about whether to keep operating based on the issuance - that would be more about the ongoing viability of staking and ones belief in Ethereum as a viable long term investment. The ongoing long term costs of staking I have for example are:\n\nExtra internet connectivity, a 2nd internet connection, higher speeds, higher data. Particularly required for multiple validators and/or splitting into DVT clusters or minipools like Rocketpool.\nTime cost for updates every 2 weeks, fixing problems with updates (e.g. today the MevBoost update caused timeouts), fixing outages (e.g. Nethermind bug).\nCapital requirement of holding all the ETH in the contract, while not technically an accounting cost it’s a major decision factor on whether to continue staking. Sure it’s easy to withdraw, but by deciding not to withdraw it’s a capital allocation that for some is an extremely large and non-diversified risk.\nElectricity, is minor in my opinion.\nUpgrades due to changes like EIP 4844\n\nYou could say these are more like ongoing commitments rather than just costs, but I’m just highlighting this because these are the factors that play into the constant decision to stay as a home staker. Not once do I think about my upfront cost paid 2+ years ago.\n\nI agree and I think it’s useful to conceptually split the LST considerations into the two participants:\n\nThe LST node operator, whose costs are rather fixed and will earn a percentage of what depositors earn.\nThe person who swaps their ETH for an LST, or deposits it into an LST contract in exchange for an LST yield bearing token\n\nParticipant #1 would likely take steps to reduce costs and increase risk if there was less yield, e.g. for instead of running 20 nodes they may cut down to 3 nodes and increase the number of validators per node. It’s an extremely efficient business, to run many validators without much of your own capital deposited. Unfortunately I don’t see this proposal as targeting these participants in a stronger manner than it would target solo stakers, because due to economies of scale with potentially thousands of validators they would still be ahead of solo stakers even if only taking 5% of the earnings (which they can choose to vary if yield changes).\nParticipant #2 really has zero cost, and can deposit every ETH they own since they only pay for the LST operator out of the yield they earn. Even if yield was 0.1% and they paid 0.01% commission then economically they still don’t feel the cost like a solo staker would. In reality they would have to consider smart contract and slashing risk, and the usefulness of their LST receipt token in DEFI (even though most people ignore this and throw money around like crazy).\nBoth of these participants I see being much more resilient to the potential changes than the home/solo staker.\n\nDilution prevention is something that is great for all holders of Ethereum. However when observing participants of the Ethstaker reddit and other social media comments, the dilution prevention of other changes were not appreciated. EIP 1559 burning of gas to make Ethereum deflationary and benefit all ETH holders, was also seen as a redistribution from stakers to ETH holders. I fear that dilution prevention is not seen as an incentive to be a solo/home staker, as staking is not required to receive that benefit. Personally I can understand the logic, but the public has a history of misunderstanding the many Ethereum proposals and upgrades.\nI agree with the problem that has been detailed, but I think the solution needs some more input.\nThe primary difference I see between LST operators and Home/Solo stakers is that an LST operator runs a large number of validators from a single beacon chain client (and a single node), whereas most home stakers have just 1 validator or very few.\nIf there was a way to have variable issuance based on how many validators are attached to an instance of a beacon chain client it could reduce the economy of scale benefits achieved by LST operators, encourage more unique nodes and incentivize the decentralization we want to encourage.\nI suspect however there would be ways to work around such solutions, and some sort arms race between the spec and LST configurations. Unfortunately I don’t have a solution, I just believe there may be other solutions yet to explore.\n\n post by Jstar101 on Mar 3, 2024\n\n Jstar101\n\n I agree with the decision to re-evaluate staking economics given we now have staking data spanning multiple years. One of the main unknowns at this point in time is how restaking will impact the ecosystem, however I believe that we should design the optimal staking economics for Ethereum, irrelevant of restaking. Any deviations away from this ‘optimal’ due to restaking should be seen as restaking impacting the security of the network and should be avoided.\nWhilst I agree that targeting a fixed staked supply solves issues associated with a super majority of staked ETH, it does not solve the winner takes all dynamic. Applying a yield curve that limits stake to say 30% of total ETH supply will lock in Lido as the winner of ETH staking. The only way in which smaller/newer staking protocols can realistically compete is to encourage capital away from Lido using incentives, something that Lido can easily combat with its own purchasing power. This entire ecosystem is already a Moloch trap where staking protocols are required to spend significant sums to attract capital and capping the total ETH stake will likely increase this problem. The worst part, however, is that real competition (outside of incentives) will likely be squashed, reducing innovation and technological advances that would otherwise lead to a safer staking ecosystem for both stakers and the network as a whole.\nWe know that yield is always going to be the primary driver of where/how stakers stake. The only way I can see us safely aligning yield with ecosystem security is introducing staking economics that fundamentally rewards stakers that take steps to improve network security, such as using minority clients, home staking, etc… Admittedly, this would get complicated very quickly and introduce technical challenges (i.e. how can you prove someone is a home staker or truly using X client), but I do not see how we can meaningfully take steps to improve the current dynamic with a simple shift in the yield curve.\nOne of the main arguments against solo staking at the moment is the lack of economic incentives to do so, mostly due to them missing access the benefits available to liquid stakers: A) being able to use staked capital in DeFi/CeFi, and B) economies of scale that large staking pools receive due to MEV. It is important to highlight here that this doesn’t have to be the case. Whilst it is not yet widely known, solo stakers are able to liquid stake against their own node via StakeWise V3. StakeWise DAO provides the liquidity and integrations for its LST, osETH, which solo stakers are permissionlessly allowed to utilise in DeFi. This opens up the door for solo stakers to borrow against their own nodes, leverage stake, and even restake by depositing osETH on Eigenlayer. I am of the opinion that native restaking will not be available to home stakers due to the expected competition across operators to be in the active set for AVSs (in the very least the most lucrative AVSs will not be available to solo stakers, further increasing the economic disparity). The ability to restake an LST minted from a home node goes some way to solving this. Alongside an LST, StakeWise V3 enables stakers to access a smoothing pool with zero costs and goes some way to solve economies of scale problem too.\nWhen evaluating the economics between liquid staking and solo/home staking, it is vital to consider the ability for solo stakers to liquid stake in this manner as it fundamentally changes the dynamics. It is also vital to increase the awareness for solo/home stakers to liquid stake in this manner to further encourage the participation of home stakers.\n\n post by htimsk on Mar 6, 2024\n\n htimsk\n\n Thank you for the in depth post. One question that I have is how can the “Real ETH Yield” be negative? With the inclusion of the EIP-1556 and the burning of the base fee the amount of ETH has decreased since the merge. As modeled by https://ultrasound.money/. Hence a holder of ETH who does not stake is not being diluted. I don’t think the model can ignore the effects of 1556 and simply assume that unstaked ETH is being diluted by the Beacon chain issuance.\n\n post by barnabe on Mar 7, 2024\n\n barnabe\n\nI believe this footnote addresses your question, indeed the burn may shift up the real yield, but that shift is constant across the whole real curves, so does not change the relative quantities and thus the arguments of the post.\n\n post by XofEE on Mar 7, 2024\n\n XofEE\n\n I’d like to share my perspective as an average Home staker to provide a more down-to-earth example :\nIf issuance approaches zero or goes negative, I’ll continue staking out of conviction and also because I don’t want to make the “effort” to withdraw my validator. Most home stakers, like me, want to avoid unnecessary entries or exits of their validators. This benefits the network.\nHowever, if negative issuance persists, I’ll be forced to withdraw because it’s not sustainable for me in the long term (I will no longer have ETH at the end so it’s better to exit beforehand)…\nThis creates a re-entry barrier, necessitating the redeposit and setup of my validator again, an effort I won’t undertake if the low APR remains. I’m not a machine; I won’t cyclically enter and exit, as it demands effort and entails risks. I’ve sketched my stance on a graph to illustrate the gap between the my APR thresholds for exiting and re-entering. (The figures are quick approximations and vary among home stakers.)\nAPR400×363 28.6 KB\nThis simple graph demonstrates that if the APR falls significantly low, I will not consider re-entering if it persists in that range, effectively establishing a ‘no-return buffer’.\nIt suggests that pushing issuance toward zero or negative risks driving away home stakers not out of conviction but due to re-entry barriers.\nHowever, I believe there’s an equilibrium APR before reaching 100% stake. Solutions like MEV burn and reducing issuance seem simpler and quicker to achieve this equilibrium at a lower ETH staking ratio.\nI don’t think it’s necessary to implement a complex targeting system, as I don’t believe (or hope) we’ll reach 100% of ETH staked. However, if implemented, I think it could cause side effects for home stakers.\n\n 28 days later\n\n post by TimDaub on Apr 5, 2024\n\n TimDaub\n\n First of all, great job. I read most of this proposal very carefully, and I agree with most of the points brought up in it. I also took to social media as to support the proposal and to address some of the popular criticisms:\n\nSome do simply not acknowledge the value of ETH as money: x.com, or they question the seriousness of the proposal (x.com), which I find incomprehensible.\nSome of the criticism seems to be without substance: x.com or it misses the key points of the proposal, namely that LSTs challenge ETH’s money-ness: x.com\nThere is a class of criticism that entirely misses the point as it assumes the SEC would monitor the internet to draw conclusions on whether ETH is a security based on what is written in this forum: x.com Even if this was the case, why would it matter when engineering the protocol and addressing its challenges outlined above? The SEC is not the primary customer we’re working towards to build the protocol.\nEveryone who holds ETH should be more aware of how incredibly valuable it is for an asset to have a monetary premium. Educate yourselves here, for example https://www.aier.org/article/on-monetary-premia/. Everyone who has to pull 17 magic tricks a quarter to preserve their wealth’s value over time is intuitively aware of how valuable it is to JUST hold a true store of value. That should be the vision for being an ETH holder. Not to imitate the existing financial system where I have to cast 23 different spells on my fiat money such that it doesn’t insta depreciate, but where I can buy ETH and know that the network’s productivity (that goes far beyond just staking) takes care of preserving the value.\n\nThen, this aside, I picked two quotes from the article:\n\nTo the authors, I would emphasize immensely this part of the proposal, which I think is counterintuitive for many ETH and LST holders. If I understood correctly, then the punch line here is, in reality, that with more staked ETH receiving yield, ETH inflates more in absolute terms, which means holding ETH becomes even less economical.\nI think printing a curve showing the number of staked ETH vs. how high absolute inflation is could help to explain this or further understanding. E.g., I’d be interested in how much ETH is being printed when, e.g., 60M ETH is staked at 2% vs., e.g., 30M ETH at 3%.\n\nI actually think a part of the requirement here should also be that “holding raw ETH is simply like holding money,” as to say that it should be straightforward to hold money and not require me to do 17 tricks to hold the actual money and not a derivative that is actually inflated away by someone who more sophisticated than me.\nThis, in turn, also means that we should see staking rewards merely as the counter good for providing a service and paying expenses for that service. And in that line of arguing, I’d like to say: Motivationally, I’m pretty sure that most validators already hold ETH for its money-ness or as an investment. ETH has also been a great investment, especially in a fiat currency environment where all value globally is rapidly inflated. So, we can hardly argue that we should pay ETH validators for the risk of holding >= 32 ETH. So then we actually pay them for an active internet connection, a computer, the amount of time they spend on maintenance, and the risk of participating in validating. And what is that cost? I doubt that it is, in reality, so high that barely anyone does it economically. I personally know of people whose non-technical family members also got a computer to stake ETH because it was apparently such easy money! WTF\nIf you think about how you have to put your fiat money into an ETF that then spends it on 500 US-based companies and has this incredible black-box complexity, all just to preserve the fiat money’s value over time, then this is the inverse of what we should be aiming for, and sadly, this is the direction we’ve been going towards. So I support this proposal! Make holding ETH economical and preserve its property of being money.\n\n post by jsarcher on Apr 11, 2024\n\n jsarcher\n\n For targeting staking ratios we should use a PID controller.\n\n post by gorondan on Apr 16, 2024\n\n gorondan\n\n GEB controller seems robust enough, is doing a great job in RAI and related forks. It intakes a target and sets the rates accordingly. Plus, it’s very well documented and in-prod tested, with community tweakings.\n\n 17 days later\n\n post by SnapCrackle2383 on May 3, 2024\n\n SnapCrackle2383\n\n I’d like to know what other ideas were discussed and dismissed besides yield issuance. I think the community is focused on yield over new ideas, I think there are many options that are worth exploring as well.\nWhat ideas do you have? I’ll go first to spark some inspiration:\n\nReduce new validators. Further, reduce the limit to 1 new validator per 6.4-minute epoch. This could be done dynamically as the stake increases. If significantly reduced, it would make building a large node operator uneconomical due to the time needed to get validators online and larger staking pools end up with less yield as they share the yield with users ETH that is not yet staked, which gives home stakers a better yield option.\n\nDo nothing. The market settles, and staking deposits settle down.\n\nEnshrine an LST, control the community, and stop bad actors from controlling the protocol. This is a controversial option, given the investment and time that organizations have put into staking pools.\n\nDynamic max deposit amount. Research an acceptable amount of economic security and design around that. Price and volume deposited dynamically managed.\n\nRandomized Yield: Implementing a system where rewards vary randomly between 1% and 6% could discourage professional node operations due to its unpredictability\n\nNon-Yield Staking: Stake accumulation could be tied to gas fee usage instead of providing a yield. This might encourage home stakers but doesn’t incentivize broader participation.\n\nIncrease the gas fee to the deposit contract to prevent the economy from stacking up.\n\nCorrelated attester penalties: This aims to penalize big stakers; it would be interesting to model this. for more info see a post by Vitalik.\n\n post by umbnat92 on May 3, 2024\n\n umbnat92\n\n It’s an interesting topic, however there is something puzzling me and I’m curious of hearing your thoughts.\nIt seems the main concern is around LST. However, by targeting a staking ratio, are you not going to exacerbate the preference for adopting a LST solution? What I mean is that, the way rewards are distributed to validators tend to follow skewed distributions - essentially, larger entities tend to earn more on a percentage basis. This is mainly due to the fact that larger entities are pooling rewards coming for long-tailed distributions. Thus in the end, it would always be more profitable to pool rewards, so joining a LST solution.\nIn other words, how can you be so sure that targeting a staking ratio doesn’t tend to make things worse?\n\n post by Bhaney44 on May 3, 2024\n\n Bhaney44\n\nI think this is a solid observation. But, it is also important to consider that there may be other reasons to operate a node beyond economics, or that new technology may develop to make the model more economical. Generally this happens often, where new technology could improve the cost-efficiency of operations.\n\nThis I really agree with. But, I think you are right, though it may be controversial.\n\nI like this idea a lot. The randomness could discourage professional node operations as you mentioned, which would certainly help decentralized the network. I think this idea is really innovative and could really improve things. Nice one.\nOverall, nice post.\n\n 7 months later\n\n post by ileuthwehfoi on Nov 15, 2024\n\n ileuthwehfoi\n\n Ansgar and Casper’s talks at Devcon were pretty interesting and have inspired me to do some napkin research on this topic. I agree that there is a problem with the incentives, but the solution seems to have some major problems:\n\nThis will affect existing stakers (rugged!)\nChoice of parameters feels random. Because of 1, this feels political.\nStaking yield goes below zero. It seems to me there is an unintentional attack with restaking, where past a certain point yield is negative but it is still profitable for restakers. At that point, non-restakers are forced to either restake or get out, resulting in 100% of staked ETH being restaked.\n\nMy quick and dirty idea introduces two new parameters:\n\nMTS: A targeted maximum total staking percentage (something between 29% (the current total stake according to https://dune.com/hildobby/eth2-staking) and 100%).\nTVS: A targeted maximum validator share (something between 32 ETH-33% of the total stake).\n\nThe idea is that once the total ETH staked reaches MTS, the issuance curve is set such that any entity with at least TVS staked has a marginal reward of 0 when adding another validator.\nFor example, let’s say MTS is 50% and TVS is 0.2%. When the total ETH staked is below 50%, the issuance curve remains the same as it is now, receiving approximately 2578 ETH/year. However, once 60 Million ETH is staked, any validator with 0.2% of the stake or more still will only ever receive 2578 ETH per year no matter how many new validators they spin up.\nI have a spreadsheet of the proposed issuance curve here: Staking Endgame.xlsx - Google Sheets (Hopefully no major mistakes, I know there are some visualization bugs if the parameters are set outside reasonable ranges).\nThis design has the following benefits:\n\nAs long as MTS is set above the amount staked at the time of the fork, there is no disruption to existing stakers.\nYield always remains positive. This is beneficial because I think if yield goes negative at some point, restakers will be able to drive everyone else out until 100% of staked ETH is restaked.\nAs an added bonus, this adds an incentive against a single party having control of too much stake (note that single entity doesn’t refer to something like a staking service, which wouldn’t be affected).\nThe design decisions are more or less neutral. Only MTS and TVS are sort of random, but I think choosing credibly neutral values shouldn’t be too hard. In any case, because of point 1 (and because there should be collusion between large stakers to avoid reaching MTS), these values shouldn’t be that political.\nThe resulting issuance curve puts a theoretical cap on ETH issuance, which is great for the ultrasound money meme.\n\nDownsides:\n\nThe yield curve becomes discontinuous (not sure about the implications of this). If this is really a problem, you could split MTS into MTS1 and MTS2, making marginal staking yield for TVS sized validators zero only after MTS2 is reached by linear interpolation from MTS1 (nice, now you can use both 30% and 50% instead of trying to decide between them for MTS).\nIt’s possible that ETH staked exceeds MTS without any validator reaching TVS. I don’t think this is likely as long as some analysis of the distribution of ETH across addresses is done to choose TVS. In any case even if this occurs there is still the benefit that it increases the decentralization of staked ETH.\nIt’s unclear how restaking yield will interact with this design. Possibly you might want to make the values for MTS or TVS to be more conservative than idealized values.\n\n post by Zarevoks on Nov 15, 2024\n\n Zarevoks\n\nAdjusting the staking reward rate is not a rug… all staking rewards are paid for by the network. Any reduction in issuence is offset by the benefit of reduced dilution.\n\n post by barnabe on Nov 15, 2024\n\n barnabe\n\n ileuthwehfoi\n\n In this scheme, how do you prevent against Sybil attacks? It sounds like I can easily defeat the TVS condition by just spinning up a new entity.\n\n post by ileuthwehfoi on Nov 16, 2024\n\n ileuthwehfoi\n\n TVS is an economic parameter, not something that targets any individual validator. The way it works is that past MTS, issuance actually starts dropping. As a result, the added ETH from any new validator is offset by the reduced yields from their existing validators, resulting in zero marginal yields. Anyone over TVS actually gets negative marginal gains, while anyone below TVS still has positive marginal yields. This is why I think this proposal actually also has benefits to stake decentralization. Another key point is that this economic incentive applies to LST holders as well.\nRe Zarevoks: rugged. That was sarcastic, sorry. I understand the argument on dilution, but I don’t expect everyone to.\n\n post by keyneom on Nov 16, 2024\n\n keyneom\n\n I’ve commented this elsewhere but I think it’s applicable to this post as well. You seem to be a mix of points 2 and 3 below which I argue are not convincing in the linked post. In particular for LST dominance I’ll see if I can post about my thoughts on how we can keep native eth competitive with LSTs soon without messing with issuance.\n\nTo avoid the feeling I think a number of people get that these are just your preferences and somewhat arbitrary I think the need for introducing MVI itself needs to be very explicit and I don’t think a high-level and clear need has been defined. I think I’ve seen 3 high level needs for why we should pursue this articulated (I’ve addressed them in my replies already but just to make things concise):\n\nLarge Validator Set Network Instability (a tech problem that already has some reasonable approaches to potentially solving)\nReducing LST Dominance (I still have no idea why an LST can’t dominate even with more limited issuance)\nAvoid paying too much for security (extremely subjective what too much security is)\n\nIf you can articulate a higher-level need that is really driving a change like this that has a massive impact on every network participant I’d be open to hearing you out. I don’t think I’ve seen it yet. And getting lost in the minutia of which curve specifically to choose with extremely detailed long posts isn’t going to help move the proposal forward imo.\n\n 4 months later\n\n post by Sotfranc on Mar 24, 2025\n\n Sotfranc\n\n Can I suggest that the main problem is the focus on defining a single yield curve for all validators?\nFor any given yield curve, there will be an optimized validator type that has a competitive advantage against others, leading to a concentrated validator set in the endgame. To solve for validator diversity, you actually need to have multiple yield curves with varying tradeoffs such that different validator types can each find a niche position in the ecosystem.\nAs an example, If instead of a single yield curve, you introduce 2 yield curves, one for validators that can exit at will and one for validators that have locked their stake for a given time, you can force diversification of the validator set. there will be a set of validators that will accept a low yield as long as they can exit immediately, and a different validator set will exisit that is willing to lock their stake for extended periods for a more stable or higher yield rate.\nCentralized entities that need to meet withdrawal requirements for their customers might be forced to have access to immediate withdrawal, while solo stakers might be willing to lock up stake in exchange for higher yield.\nThis is similar in concept to government bonds. There is no single bond type offered by the government, but rather a multitude of different bonds (30 yr, 10 yr, inflation protected, etc) which each attract a specific type of investor with a unique risk profile.\nNo single issuance curve will be agreed to by all validators, but introducing a range of curves with different trade offs would likely grab more support as each validator type would find a niche.\n\n post by MicahZoltu on Mar 24, 2025\n\n MicahZoltu\n\nWhat is the benefit to the protocol for having some validators with longer lockup requirements?\n\n 10 days later\n\n post by Sotfranc on Apr 4, 2025\n\n Sotfranc\n\n I would assume a stable validator set with longterm validation gaurantees would be a net benefit to the security of the protocol. Depending on the exact levels you could also save on eth inflation in certain scenarios.\nBut the main benefit from my perspective is more to force diversification of the validator set. I think it would be valuable to diversify the validator set in this way even if long term locked stake had no direct benefit to the protocol.\n\n post by MicahZoltu on Apr 5, 2025\n\n MicahZoltu\n\nWhat leads you to this assumption?\n\nIt is not clear to me why there would be a benefit to the protocol in having a diversity of lockup lengths. Diversity isn’t useful just for diversity’s sake, we often want diversity because it gives us robustness in some cases, but I don’t see how this would increase our robustness.\n\n Powered by Discourse","tokens":7129,"squid":"spider-04","role":"Research Spider","at":1791347024034,"hash":"cd1463cd7aba036867487b28b01d75a15c21a810"}
{"url":"https://docs.jup.ag/user-docs/earn/offerbook/intents","domain":"docs.jup.ag","title":"Intents - Jupiter Documentation","text":"Intents let you advertise the terms you are looking for without committing anything onchain. An intent is a signed, off-chain message that tells the market “I am willing to lend (or borrow) this amount, against this collateral, at these terms”.\nFreeOne wallet signature. No gas, no rent, no fees.Nothing lockedYour funds stay in your wallet the whole time.No commitmentYou choose whether to fill a matching offer, or ignore it.\nIntents exist alongside offers. They do not replace them: an intent surfaces demand or supply that the order book cannot show yet, and the loan itself is still created through the regular offer flow.\n​Intents and offers\nOffersIntentsWhere they liveOnchainOff-chainCost to createNetwork fees and account rentFree, one wallet signature, no gasFundsRequired to fill the offerNever lockedCan be filled directlyYesNoLoan duration1 to 30 days1 to 30 daysTerms anchorToken amounts, fixed at current prices when the offer is createdLTV-based: amounts are recalculated against live pricesExpiration1 to 7 days, set at creationSet at posting, up to 90 days\nThis anchoring difference is why offers are short-lived while an intent can stay posted: an offer commits exact token amounts at the prices of its creation, so it only stays meaningful for a short window, while an intent only advertises an LTV and a rate, so its terms keep their meaning as prices move.\n​How matching works\nWhen you post an intent, Offerbook continuously compares it against live onchain offers. An offer matches your intent when all four criteria hold:\nCriterionToleranceToken pairExact match: same lent token and same collateral tokenAPYWithin 10% of your intent’s annual percentage yield (APY)LTVWithin 10% of your intent’s loan-to-value (LTV) ratioDurationWithin one day of your intent’s duration\nMatching offers surface under Dashboard > Intents. From there, filling one works exactly like filling any other offer. Posting an intent never commits you to anything: you decide whether to fill a matching offer, or ignore it.\n​Posting an intent\nThere are several ways to post an intent:\n\nCreate Offer > Post an Intent in the header, Set your terms at the bottom of the Earn market’s Set Your Terms tab, and New intent on the Dashboard’s Intents tab all open the dedicated Post intents page (“Advertise the terms you want — no funds locked, matching offers surface in your dashboard”), described in the steps below\nOn the Borrow page, the Create your own offer composer offers post free instead, which advertises your ask as an intent rather than locking it as an offer (see Borrowing)\nThe borrow offer creation flow ends on the same choice: at its Publish step, Just advertise terms posts your configured terms as an intent instead of locking them as an offer (see Borrowing)\n\nIn every case, the interface reminds you that advertised terms should stay backed by a real balance in your wallet (see the balance check under Intent costs).\n1Choose your sideSelect Lend or Borrow at the top of the form. As a lender, you set the token you lend and the collateral you want to receive. As a borrower, you set the collateral you lock and you receive the borrowed token.The form also lists the most used collateral assets, with their recent loan volume, to help you pick a market that is actually active.2Set your amountEnter the amount on your side of the trade: the amount you lend as a lender, or the collateral amount you lock as a borrower. Half and Max shortcuts use your wallet balance.The amount on the other side is calculated automatically from the LTV you set, using current prices, and is labelled “set by LTV” in the form.3Set your termsThree fields define the loan you are advertising:ParameterRangeDefaultDescriptionLTV1% to 95%50%Ratio between the borrowed value and the collateral valueAPYNo fixed range in the form10%Annual rate you offer or requestDuration1 to 30 days7 daysLength of the advertised loan4Post and signThe footer tracks readiness (“1 of 1 intent ready · one signature, no gas”); an intent line missing a collateral or an amount is flagged until completed. Click Post intent. Your wallet prompts you to sign a message. There is no transaction, no gas fee and no rent deposit. Ledger wallets sign an equivalent memo transaction instead, which is never broadcast to the network.\n​Posting several intents at once\nThe Add intent button stacks additional intent lines in the same form, each with its own asset pair, amount and terms. The whole batch is posted with a single signature, up to 20 intents at a time.\n​Where your intent appears\nOnce posted, your intent is public:\n\nOther users see it in the market views, where assets with active intents carry an intent badge and the advertised liquidity shows in the Available column alongside onchain offers\nBorrowers’ intents are listed on the Set Your Terms tab of the Earn Tokens market (“Borrowers looking for terms”), where a lender can Create offer to post a matching offer\nThe Pro view lists it in its Borrow intents or Lend intents panel, where counterparties can Match it\nThe Statistics page counts it in the Advertised Intents card\nYou manage it from Dashboard > Intents\n\n​Acting on someone else’s intent\nIntents cannot be filled directly. To act on an intent, create a regular onchain offer with the same token pair and terms close to the advertised ones. Once your offer is onchain, it surfaces automatically in the intent creator’s dashboard, and they can fill it through the standard flow.\nKeep your terms within the matching tolerances. If your offer drifts further from the intent’s terms, it stops being surfaced to the intent creator, although it remains a normal offer that anyone can browse and fill.\n​Managing your intents\nYour intents live under Dashboard > Intents. Each row shows the principal, the collateral (down to a specific collectible), the APY, duration, interest owed, LTV and the time left before expiration, with Edit and Cancel actions. While an intent is active you can edit its terms or cancel it at any time; each change requires a wallet signature, and like posting, it is free.\nAn intent has one of three statuses:\nStatusMeaningActiveLive and visible to the market. Can be edited or cancelledCancelledRemoved by you. TerminalExpiredReached its expiration without being cancelled. Terminal\nAn intent cannot be filled directly: to make your advertised terms fillable, lock them as an onchain offer through the borrow offer creation flow (Create Offer > Borrow), whose Publish step turns the same terms into a locked, fillable offer (Lock & list now).\n​Intent costs\nIntents are entirely free. Posting, editing and cancelling an intent involve no network fees, no account rent and no protocol fees, because nothing happens onchain. Protocol fees only apply later, if a matching offer turns into an actual loan, under the standard fee schedule described in Fees and Costs.\nFor large intents, around $100,000 in value or more, Offerbook verifies that your wallet and escrow balances actually hold the relevant asset before accepting the intent. Smaller intents are accepted without a balance check.\n​Risks and limitations\n\nIntents are public. Anyone can see the terms you advertise and the wallet that posted them.\nAn intent is not a commitment. Neither you nor anyone else is obliged to act on it, so a posted intent may never result in a loan.\nPrices move. The counterpart amount displayed in the form is an estimate based on current prices, and the real terms of any future loan are fixed only when an offer is filled.","tokens":1879,"squid":"spider-02","role":"Liquidity Spider","at":1791347024080,"hash":"4891e035d669d60097165a8aecc9ae966469a1b1"}
{"url":"https://docs.jup.ag/user-docs/earn/offerbook/counter-offers","domain":"docs.jup.ag","title":"Counter Offers - Jupiter Documentation","text":"A counter offer is a proposal to modify the terms of an existing open offer before accepting it. Instead of accepting an offer as-is, any user can suggest different terms back to the offer creator. Counter offers do not lock any funds until accepted, and the original offer stays open and visible to other users while counter offers are pending.\nCounter offers work the same way for borrowers and lenders: anyone can counter an open offer, and any offer creator can receive counters. Your counter takes the opposite side of the original offer — countering a lending offer puts you on the borrowing side, and countering a borrowing offer puts you on the lending side.\n​Sending a counter offer\nOpen the offer you want to negotiate and click Counter. The counter form opens with the original terms shown at the top and your proposed terms below, pre-filled from the original. Adjust one or more of:\n\nLTV — the loan-to-value ratio between borrowed USDC and collateral value. Changing it updates the locked and borrowed amounts accordingly\nAPY — the rate you propose\nDuration — the loan length, in days\nExpiry — how long your counter offer stays open\nAllow partial fills — inherited from the original offer; toggle it and set a Min fill (USD) if you want a different rule\n\nA colored indicator shows how likely your terms are to fill (for example, “Great chance to fill” or “Unlikely to fill quickly, high risk for lenders”), so you can gauge your proposal before sending.\nYou need to hold enough of the asset to back the counter offer when you send it; if you do not, the form shows “Not enough … to back this counter offer”. Nothing is locked until the creator accepts. Click Review counter offer to confirm and sign.\nYour counter is pinned to the original offer, so the creator sees it alongside their offer. You cannot edit a sent counter offer; if you want to change the terms, cancel it and send a new one.\n​Receiving counter offers on your offers\nWhen someone sends a counter offer on one of your open offers, it appears beneath your offer in Dashboard, so you can review and respond in context. You are alerted in two places: an activity dot on the Dashboard link, and a notification through your connected channels if enabled in Settings.\nYou can either:\n\nAccept the counter offer: the loan starts immediately at the counter-offer terms, and your original offer is consumed by this acceptance\nIgnore it: your original offer stays open, and other counterparties can still accept it at the original terms or send their own counter offers\n\nMultiple counter offers can be open against the same original offer at the same time. Accepting one of them closes the original offer; any other pending counter offers are no longer actionable.","tokens":683,"squid":"spider-02","role":"Liquidity Spider","at":1791347034150,"hash":"319a9223f96f374e1a3c3224485aa15cd7af7151"}
{"url":"https://ethresear.ch/t/signature-merging-for-large-scale-consensus/17386","domain":"ethresear.ch","title":"Signature Merging for Large-Scale Consensus - Cryptography - Ethereum Research","text":"Signature Merging for Large-Scale Consensus \n\n Cryptography\n\n signature-aggregation,single-slot-finality\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 Nov 2023\n\n 1 / 4\n\n Nov 2023\n\n May 2024\n\n post by asn on Nov 10, 2023\n\n asn\n\n Signature Merging for Large-Scale Consensus\nAuthors: George Kadianakis, Dmitry Khovratovich, Zhenfei Zhang, Mary Maller\n\\cdot⋅\nMany thanks to Jeremy Bruestle, Vitalik Buterin, Srinath Setty and Arantxa Zapico!\n\\cdot⋅\nIn this post we focus on tools to perform massive-scale signature aggregation for Proof-Of-Stake blockchains.\nWe first present the bitfield merge problem in the context of the Ethereum consensus protocol. To solve it we introduce a new signature aggregation technique called Signature Merge and demonstrate how it can be used in Ethereum. We then provide three instantiations of Signature Merge using Proof-Carrying Data (PCD) techniques via recursive SNARKs and decentralized proving. Alongside these approaches, we highlight open research challenges related to the scalability of PCD constructions. To close off, we offer preliminary performance evaluations to give readers a glimpse into the expected efficiency of these schemes.\n\nIntroduction\nProof of Stake (PoS) systems essentially are open ballot voting systems where validators need to come to consensus. In those consensus systems, cryptographic signatures act as ballots. Validators publicly show their agreement by signing the same message.\nWe want to enable future PoS systems to operate in massive scale with potentially millions of voters, as required by Ethereum’s Single Slot Finality scheme. In such big P2P systems it’s essential to optimize the way these signatures get collected.\nSignature Aggregation\nSignature aggregation schemes allow multiple signatures to be combined into one. Aggregation significantly reduces the communication and verification overhead of the system even with a vast number of validators. A famous such scheme is the BLS signature scheme.\nUsing BLS, signatures can be easily aggregated, but tracking the identity of the signers requires another layer of representation - this is where Ethereum uses bitfields. These bitfields act as a sort of ‘participation list’, marking who among the validators has signed the message. Bitfields are a binary representation of a participants list: ‘1’ at index i𝑖 means that validator at index i𝑖 signed the message.\nKnowing the identity of the participants is essential for the Ethereum consensus because of slashing, staking rewards and the inactivity leak.\nimage.png992×522 11.9 KB\nThe Bitfield Merge Problem\nConsider a signature aggregation system where a collector entity needs to aggregate two aggregated signatures and their bitfields. Aggregating the signature is easy, but merging the bitfield can be tricky.\nimage.png1282×432 18.6 KB\nFor instance, consider two bitfields: 110 and 010. Merging them isn’t as straightforward as summing numbers. The latter would result in 120, a value that isn’t binary and is twice more expensive to send over the network.\nFurthermore, the BLS verifier must know how many times a signature has been aggregated during verification, so that she can compute the correct verification key. That is, the aggregated signature behind 120 has a different verification key from the signature behind 110.\nThe Bitfield Merge Problem in Consensus\nThe above issue is encountered in tree-based aggregation topologies as discussed in the Horn proposal, when aggregating already aggregated signatures in the tree’s upper sections.\nThe issue can also be seen in gossip-based aggregation topologies where aggregations are gossiped in a chaotic non-deterministic fashion, as seen in the figure below and was suggested in the past by Vitalik. For networks with a big number of validators but a small number of networking nodes, gossip-based aggregation can be more efficient than a tree-based structure: in such a setting if Alice has 1000 validators she can start the protocol with a populated bitfield of weight 1000 without any prior communication. Furthermore the unstructured property of gossip-based approach can allow more privacy-friendly aggregation protocols.\n681×501 34.4 KB\nDue to bandwidth being a fundamental scaling factor in P2P systems, we want to keep using bitfields to denote participation since using heavier representations causes further strain on the networking layer.\nWe call merging the operation of accumulating two bitfields and producing a bitfield.\nIn this post we propose Signature Merge schemes as a solution to the bitfield aggregation problem, and three possible instantiations using SNARKs.\nSignature Merge schemes\nA Signature Merge (SM) scheme supports the recursive merging of signatures and their bitfields while still allowing the extraction of the signer set out of them. In this section we present the interface of an SM scheme, and in Appendix A we show how it can be used in the context of Ethereum.\nFollowing the steps of [GV22], SM schemes are similar in terms of functionality to classic signature aggregation schemes but they introduces the Merge , MergeVerify and GetSigners algorithms.\nAdditionally, the MergeVerify function does not take as input specific verification keys. Instead it has oracle access to a PKI system which can be queried to retrieve verification keys using a user’s index or a participation bitfield. The PKI system is updated with every call to Keygen.\nFinally, the GetSigners method returns a bitfield containing the signers of a merged signature.\nA Signature Merge (SM) Scheme has the following algorithms:\n\nSetup(1^\\lambda1𝜆) \\rightarrow pp→𝑝𝑝: Outputs public parameters pp𝑝𝑝 which are implicitly given to all algorithms\n\nKeygen(1^\\lambda, \\text{PKI}) \\rightarrow (\\text{sk}, \\text{vk}, k)1𝜆,PKI) →(sk,vk,𝑘): Generates secret signing key and public verification key for a user and registers the public key to the \\text{PKI}PKI. Also returns the user’s index k𝑘 in the \\text{PKI}PKI system.\n\nSign(\\text{sk}, msk,𝑚) \\rightarrow \\sigma→𝜎: Takes as input a signing key sk𝑠𝑘 and a message m𝑚 and computes a signature \\sigma𝜎\n\nVerify(\\text{vk}, \\sigma, m) \\rightarrow 0/1vk,𝜎,𝑚) →0/1: Takes as input a verification key \\text{vk}vk, a message m𝑚 and a signature \\sigma𝜎 and returns whether the signature is valid or not.\n\nAggregate^\\text{PKI}(m, \\{ ( \\sigma_i, k_i ) \\}_i) \\rightarrow \\piPKI(𝑚,{(𝜎𝑖,𝑘𝑖)}𝑖) →𝜋 : The aggregation algorithm takes as input a sequence of signatures \\sigma_i𝜎𝑖 with user PKI indices k_i𝑘𝑖 and outputs a merged signature \\pi𝜋. It also has access to a PKI system which can be queried to retrieve any verification key.\n\nMerge^\\text{PKI}(m,\\{ \\pi_i \\}_i) \\rightarrow \\piPKI(𝑚,{𝜋𝑖}𝑖) →𝜋: The merge algorithm takes as input a sequence of merged signatures \\pi_i𝜋𝑖 and outputs a merged signature \\pi𝜋. It also has access to a PKI system which can be queried to retrieve any verification key. Note that Merge allows us to combine merged signatures \\pi_i𝜋𝑖 without knowing any of the underlying individual signatures \\sigma_i𝜎𝑖.\n\nMergeVerify^\\text{PKI}(m, \\pi) \\rightarrow 0/1PKI(𝑚,𝜋) →0/1: The merged signature verification algorithm takes as input a message m𝑚 and a merged signature \\pi𝜋 and outputs whether the signature is valid or not. It also has access to a PKI system which can be queried to retrieve any verification key.\n\nGetSigners^\\text{PKI}(\\pi) \\rightarrow bPKI(𝜋) →𝑏: Given a merged signature \\pi𝜋, return a bitfield corresponding to the indices of all the signers who participated.\n\nNote that merged signatures must have size linear to the number of signers, otherwise the GetSigners method would not be able to recover all the signers of a merged signature, violating incompressibility.\nWe say that a Signature Merge scheme is lightweight if the size of \\pi𝜋 is minimal: it only uses a single bit for each user of the PKI system. In this post we concern ourselves only with lightweight Signature Merge schemes.\nSecurity of Signature Merge Schemes\nSecurity of SM schemes is defined similarly to aggregation schemes. Let i𝑖 denote the index of an honest signer. An SM scheme is unforgeable if no polynomial time adversary can produce verifying (m, \\pi)(𝑚,𝜋) such that b = \\mathbf{GetSigners}^\\text{PKI}(\\pi)𝑏 =𝐆𝐞𝐭𝐒𝐢𝐠𝐧𝐞𝐫𝐬PKI(𝜋) and the ith𝑖𝑡ℎ bit of b𝑏 is equal to 1 (b_i = 1𝑏𝑖 =1), unless party i𝑖 has previously signed m𝑚.\nSignature Merge Instantiations\nIn the upcoming sections, we provide a primer on recursive SNARKs and PCD, followed by three distinct methodologies to materialize a Signature Merge scheme via different recursive SNARK paradigms.\nProof-Carrying Data using Recursive SNARKs\nRecursive SNARKs are cryptographic proof systems where the SNARK verifier is succinct enough to be evaluated inside another SNARK circuit. This ‘nesting’ can be performed repeatedly, allowing for an aggregation of multiple proofs into one.\nimage1124×336 20.1 KB\nWhen combined with the Proof-Carrying Data (PCD) paradigm, we can start thinking of the participation bitfields as the main object of our Signature Merge system. The bitfields, depicted as m_i𝑚𝑖 in the figure above, always travel with associated proofs, depicted as \\pi_i𝜋𝑖. A receiver can verify the proof, and be convinced that the bitfield is the product of a series of valid signature verifications and bitfield merges.\nApproach 1) Recursive STARKs\nIn this section we present a straightforward Signature Merge scheme based on recursive STARKs.\nThe approach is based on a recursive STARK circuit that consumes signatures or other STARKs alongside their associated bitfields. The circuit verifies every signature and STARK received and merges their bitfields. The circuit’s output is the merged bitfield and the STARK proof.\nWhile this is not the most efficient of our suggested approaches, it’s the conceptually simplest approach and also offers post quantum guarantees.\nHere, a STARK is a hash-based proof of a polynomial equation, which encodes a certain computation. A recursive STARK is specific in that the computation contains the verification of other STARKs. Therefore, the Merge step consists of the following:\n\nVerifying the incoming STARK proofs with their own bitfields.\nCreating a STARK proof that the incoming proofs are valid and the union of their bitfields equals the alleged result. This step requires constructing a number of Merkle trees that hash in the entire computation trace, i.e. the verification of STARKs and unionizing the bitfields.\nPublishing the STARK proof, which contains of a number of openings in the just-constructed Merkle trees.\n\nThe recursive STARK circuit\nimage.png1364×490 10.9 KB\nUsing a simple and slim hash-based signature scheme (e.g. Winternitz) instead of BLS, we introduce the following recursive STARK relation:\n\nPublic inputs: Root of all pubkeys R𝑅, public bitfield b𝑏, message hash m𝑚\nPrivate inputs: N𝑁 STARKs with N𝑁 bitfields, and optionally a signature along with a participant index\nStatement:\n\nRecursive STARK verification: For all 1 \\le i \\le N1 ≤𝑖 ≤𝑁, the i’th provided STARK is a valid STARK of this statement using the i𝑖 ’th bitfield and the same R𝑅 and m𝑚\nSignature verification: If a signature is provided, check that it’s a valid signature of m𝑚 with the pubkey at the position defined by the participant index in the pubkeys tree rooted in R𝑅\nBitfield union: The public bitfield is the union of all the bitfields in the STARKs, with 1s filled in for each of the m𝑚 indices for which we have individual signatures\n\nThe circuit is informally depicted above to demonstrate how the recursion works (observe how the inputs match the outputs).\nApproach 2) Recursive Halo2 (atomic accumulation)\nA computationally cheaper approach compared to full recursion would be to use an atomic accumulation scheme like the original Halo construction.\nThe approach here is similar to full recursion in that we still verify proofs inside SNARKs, but the Halo approach is lighter for the prover: Halo only implements the lightweight part of the verifier inside the SNARK, while deferring any expensive operations. These operations get deferred to the end of the recursion chain.\nHalo2-IPA\nThe original Halo paper was written on top of the Sonic arithmetization scheme, but we can adapt the protocol to a modern Plonkish based scheme and use IPA polynomial commitments to perform the final polynomial vanishing argument. This is exactly what zcash has done with halo2, but we also need it to support deferred recursion.\nNote that in halo2, the most expensive operation of the verifier is verifying IPA openings. Using the techniques from Halo we can defer the expensive in-circuit MSM needed when verifying the IPA opening proofs. At each recursive step, we defer this expensive operation and accumulate it into an accumulator. Finally, when we need to pass the proof to the next person, that person must verify both the proof and the accumulator.\nFurthermore, we also need to adjust the scheme to implement Proof-Carrying Data but fortunately the “Proof-Carrying Data from Accumulation Schemes” paper provides a construction we can use for benchmarking purposes.\nThe Halo PCD circuit\nNow let’s dig deeper into how the Halo PCD circuit looks like. For this section, we will be considering recursive circuits that verify two proofs, essentially allowing PCD with a binary tree structure.\nThe circuit takes as input two tuples (\\pi_0, acc_0, z_0)(𝜋0,𝑎𝑐𝑐0,𝑧0) and (\\pi_1, acc_1, z_1)(𝜋1,𝑎𝑐𝑐1,𝑧1). Where (\\pi_0, acc_0)(𝜋0,𝑎𝑐𝑐0) is the first IPA proof and its accumulator, while z_0𝑧0 corresponds to the useful inputs to the circuit. For example, z_0𝑧0 can be seen as a tuple (\\sigma_0, b_0)(𝜎0,𝑏0) where \\sigma_0𝜎0 is an optional signature, and b_0𝑏0 is a bitfield.\nNote that in Halo2, the entire proof system gets reduced to a single IPA proof. Also, note that both the proof and the accumulator have the same form: they are both IPA proofs.\nOur PCD circuit has two tasks:\n\nCheap-verify the proofs and accumulators (\\pi_0, acc_0)(𝜋0,𝑎𝑐𝑐0) and (\\pi_1 ,acc_1)(𝜋1,𝑎𝑐𝑐1), while accumulating the expensive MSM operations into acc_{out}𝑎𝑐𝑐𝑜𝑢𝑡\nPerform the useful computation function F𝐹 given the inputs z_0𝑧0 and z_1𝑧1:\n\nIf a signature was provided, verify the signature.\nReturn the union of the provided bitfields.\n\nBelow you can see an informal rendition of the circuit:\nimage.png1376×400 21.6 KB\nNote that in real life, the circuit could look different. For instance, maybe the circuit doesn’t output the accumulator, it just checks its validity, and the accumulator is computed out-of-circuit.\nApproach 3) Folding (split accumulation)\nThe other end of the spectrum is the recent line of work on folding. Folding allows us to replace the expensive in-circuit SNARK verifier, with a much simpler folding verifier. This significantly decreases the prover’s computational overhead of recursion since no proof verification actually happens inside the circuit.\nThe folding process deals with witnesses W𝑊 to a certain structure \\mathcal{S}S and instances U𝑈. The structure in the original Nova is a set of matrices that define an R1CS relation; later on this is generalized to CCS (higher-degree constraints) in Hypernova and to polynomial equations in Protostar. The witness is a set of values satisfying the structure equations (i.e. R1CS constraints in Nova) and instance is a commitment to the witness plus some metadata. We note that the actual structure is not exactly R1CS but a more general relaxed R1CS, where certain error terms are introduced.\nThe actual folding is a procedure to compute the folded witness W_{folded}𝑊𝑓𝑜𝑙𝑑𝑒𝑑 out of l𝑙 input witnesses W_1,\\ldots, W_l𝑊1,…,𝑊𝑙, then to compute cross terms T𝑇 from the same witnesses, and finally to compute folded instance U_{folded}𝑈𝑓𝑜𝑙𝑑𝑒𝑑 from input instances U_1,\\ldots, U_l𝑈1,…,𝑈𝑙 and T𝑇. The entire procedure is done in the challenge-response fashion, which guarantees that W_{folded}𝑊𝑓𝑜𝑙𝑑𝑒𝑑 satisfies U_{folded}𝑈𝑓𝑜𝑙𝑑𝑒𝑑 only if for each i𝑖 there exists a W_i𝑊𝑖 satisfying U_i𝑈𝑖.\nTo make an IVC, the prover creates a circuit \\mathcal{S}'S′ that encompasses both the last step of the folding process (which does not depend on the witness size) and the useful computation F𝐹, plus some extra hashing steps that bind together instances and the IVC inputs-outputs. Then the witness W'𝑊′ to this circuit is committed to in order to create a new instance U'𝑈′. Having required that the instances to be folded have the same structure, i.e. \\mathcal{S}'=\\mathcal{S}S′ =S, then U'𝑈′ can be folded with U𝑈 at the next step of IVC.\nFolding schemes have smallest recursion overhead, but they also come with a variety of open research questions that we discuss below.\nMoving Nova to PCD\nNova as depicted in the original paper is tailored for IVC chain-like computations. In contrast, Signature Merge requires a PCD graph-like structure with nodes accepting arbitrary proofs from other nodes with no clear global order.\nAdjusting Nova for PCD requires us to introduce an additional instance-witness pair into the circuit \\mathcal{S}S. This results in a more complex S𝑆 as well as more constraints needed to fold the extra pair.\nThe same approach has been previously proposed by the Paranova project, noting that it allows PCD using a binary-tree structure.\nMinimizing the curve cycle\nBoth folding and recursive Halo2 require us to compute elliptic curve operations inside circuits. This can be done using non-native arithmetic or using cycles of curves. Most projects rely on cycles of curves since non-native arithmetic is many orders of magnitude more expensive than normal arithmetic.\nHowever, using cycles of curves results in a complicated system as proofs need to be produced in both curves and they need to be correctly linked and verified.\nThe recent work on Cyclefold is particularly useful in our PCD setting as it can reduce the complexity on the second curve. Using Cyclefold the second curve is only used to assist with scalar multiplications, without needing to perform any of IVC/PCD operations.\nHashing public inputs\nThe folding circuit necessarily contains hashings of inputs and outputs of IVC together with folded instances. As in-circuit hashing is relatively expensive, we need a way to compress the inputs even further.\nFolding lookups\nAgain, as binary decomposition is too expensive, we seek a way to implement lookups to speed up the OR operation. The problem is that the lookup arguments require a support of certain polynomial equations, and most folding schemes do not support such equations out of the box. We investigate for possible ways of integrating lookups into (Hyper)Nova with minimal impact to definitions and proofs.\nWitness size management\nIn order to perform folding, the aggregator needs the full witness to each folded instance. For a PCD, this makes the witness of each input instance at least as big as the witness for the PCD step function. In our case it is the witness for the OR operation over two 1 mln bit inputs, which requires at least 3 mln bit witness, or 12 K field elements. The folding operation requires several scalar multiplications, which totals to 10-20K witness elements as well. Altogether, a PCD folding prover receives as witness 2-3 MB of data from each of two senders.\nDeeper dive into Signature Merge circuits\nIn this section we dig deeper into some SNARK-related themes that all the approaches above have in common.\nAll the approaches above have similar functionality: we are dealing with SNARK circuits that verify signatures, and also compute unions of bitfields. In this subsection, we are going to talk about performing these operations inside SNARKs in more detail.\nVerifying signatures inside SNARKs\nWe need to choose a signature scheme that is easy to verify inside SNARKs. We assume that the message to be signed is constant size (approx. 256 bits) being a hash of public value, and varies for each aggregation process. Given that the recursion overhead in all approaches is at least a few scalar multiplications, we can choose from the following variants:\n\nSchnorr-like signatures: A simple discrete-log based scheme which requires only one elliptic curve scalar multiplication inside the circuit. Similar schemes are based on ECDSA signatures.\nProof of preimage. Here a signature is a proof of knowledge of secret key k𝑘, which is hashed to get public key K= H(k)𝐾 =𝐻(𝑘) with H𝐻 being some hash function. The actual message is part of the context in the proof process. The proof method is chosen to be native for the signature aggregation method, i.e. IPA for Halo-IPA, STARK for recursive STARKs and folding. The costs are mostly determined by the proof method but also dependent on the hash function used in the signature, which should not be too expensive.\nProof of encryption key. This method resembles the previous one, with the public key K𝐾 being the encryption of some constant (say, 0) on the secret key k𝑘, i.e. K = E_k(0)𝐾 =𝐸𝑘(0). The actual signature may or may not be the result of the encryption as well, like in the FAEST scheme.\n\nWhile the choice of the signature scheme might initially seem important, it’s actually of lesser importance since in all recursive SNARK constructions, the SNARK verifier inside the circuit dominates the performance of the scheme.\nBitfield union using lookups\nThe process of taking the union of two bitfields is a straightforward logic operation, but it does not translate that nicely into the language of arithmetic circuits.\nA naive approach would involve decomposing the bitfields into bits, and then working over each bit separately, making sure that the two input bits match the output bit. This means that we have to spend O(logd)𝑂(𝑙𝑜𝑔𝑑) constraints, where d𝑑 is the size of the bitfield.\nThis seems like the perfect environment to use lookup arguments, which allow us to chunk together multiple bits and spend a single constraint for each chunk.\nConsider a lookup table of all possible OR outputs of two bitfields of size 2^525. This means that we can chunk bitfields into chunks of five bits, and use the lookup protocol to perform the union.\nManaging circuit size\nIt’s important to observe how the size of the circuit impacts the above approaches. The bigger the circuit, the more painful it is to recursively verify it.\nIt’s also worth noting that in many signature aggregation protocols, the protocol will begin by merging tiny bitfields before moving to bigger and bigger bitfields. For this reason, it would be ideal if we only had to pay for what we use: use a small circuit size when working with small bitfields.\nThis can be achieved by working with multiple circuits: Since the size of the output bitfield is public, the prover can always choose the circuit best suited to the size of the input bitfields. This can work very well in tree-based aggregation protocols where the bitfield sizes and the provers are known in advance.\nAnother approach is chunking up the statement that is proven: Instead of working with the full bitfield, work with smaller chunks at a time, and produce multiple proofs when needed. At the beginning of the protocol, the provers will be dealing with small circuits and producing a single proof, but as the protocol goes on and the bitfields grow, the provers will need to produce multiple proofs per bitfield, and hence the recursion overhead will grow.\nPerformance evaluation\nIn this section, we aim to give you a sense of what to expect in terms of performance for the discussed schemes.\nIt’s important to note that obtaining precise figures without fully implementing the schemes is challenging, especially given the presence of unresolved questions.\nWe start with an overview presented in the table below, and then delve into each scheme individually.\n\nMerge cost\nMergeVerify cost\nCommunication overhead\n\nRecursive STARKs\nBad\nVery Good\nBad\n\nRecursive Halo2\nOK\nOK\nGood\n\nFolding\nGood\nOK\nVery Bad\n\nPerformance Evaluation: Recursive STARKs\nWhile it’s hard to get reasonable benchmarks for the recursive STARK scheme without an implementation, in this section we present benchmark data provided by the RISC0 team who are using STARK recursion in alternative applications.\nWhile the RISC0 benchmarks are certainly useful, it’s worth pointing out that designing a custom circuit precisely for our use case would allow us to tweak the various parameters of the system (e.g. hash function, finite field, security params, etc.) and the actual numbers could look wildly different.\nIn Appendix B, we present a work-in-progress draft for a formulaic approach to evaluating the prover performance of recursive STARKs.\nMerge cost\nIn terms of API, in this section we will be considering the costs of the Merge() function of a Signature Merge scheme (i.e. merging two bitfields together).\nThe RISC0 prover currently spends 2.5 seconds to recursively verify 2 STARKs inside a circuit. This effectively allows N = 2𝑁 =2 in the circuit above, and enables a binary “proof tree” structure which is common in PCD applications.\nThe RISC0 system aims for 100-bit of security and the majority of the prover’s time is spent on hashing the full witness. The figure above comes from a prover equipped with an Nvidia A4000 GPU, which is specialized hardware that validators normally don’t have.\nThe RISC0 team believes that by further optimizing their GPU implementation and their algorithms, they can get up to 4x improvement in the prover speed in the next years (potentially bringing the cost of Merge to below a second).\nRISC0’s circuit is proving RISC0 VM instructions whereas our circuit is verifying signatures and merging bitfields. From discussions with the RISC0 team, we believe that the underlying application is not so important, because the large STARK verifier circuit dominates the prover’s performance.\nMergeVerify cost\nSuper fast! A few miliseconds.\nCommunication overhead\nThe STARK’s proof size comes to about 300kb (depending on the security parameters), which is quite big.\nPerformance Evaluation: Recursive Halo2\nIn this section, we will be considering participation bitfields of size 1 million bits. This means that they can be expressed using 2^{12}212 field elements. We estimate that the final circuit will have size about d = 2^{16}𝑑 =216 since it needs to at least process the two input bitfields.\nMerge cost\nThe prover time in this scheme is the time it takes to perform the useful computation (i.e. merge bitfields or verify signatures), plus the time it takes to recursively verify any proofs provided.\nProver time for useful computation:\n\nSignature verification: 200-2000 R1CS/(low-degree Plonkish) gates\nBitfield union:\n\nPlain: 2^{21}221 gates (degree-2) for binary decomposition and 2^{20}220 gates for the union operation.\nWith lookups: 1 gate per 8x8 bitwise OR: 120K gates and table of size 64K entries.\n\nRecursive overhead (essentially the runtime of algorithm \\mathbb{P}ℙ from section 5.1 of the “Proof-Carrying Data from Accumulation Schemes” paper):\n\nDeferred IPA verification for all proofs and accumulators (\\pi_0, acc_0, \\pi_1, acc_1)(𝜋0,𝑎𝑐𝑐0,𝜋1,𝑎𝑐𝑐1):\n\n4 \\cdot 2 \\cdot logd = 4 \\cdot 2 \\cdot 16 = 1284 ⋅2 ⋅𝑙𝑜𝑔𝑑 =4 ⋅2 ⋅16 =128 ECMULs\n4 \\cdot 2 \\cdot logd = 1284 ⋅2 ⋅𝑙𝑜𝑔𝑑 =128 ECADDs\n4 \\cdot logd = 644 ⋅𝑙𝑜𝑔𝑑 =64 hashes\n\nFinally, let’s compute the total recursive circuit size:\n\nAssuming a 8-bits preproceessed lookup table, the bit field union circuit can be implemented within 2^{20-8} = 2^{12}220−8 =212 constraints.\nUsing Jellyfish’s custom gate, each ECMUL takes 300 plonkish constraints, each poseidon hash takes 200 plonkish constraints. The deferred IPA verification circuit can be implemented within 51200\\approx 2^{16}51200 ≈216 constraints.\n\nThe recursive circuit size is therefore estimated at 2^{16}216 constraints.\nUsing the Pallas/Vesta curves, such a circuit can be proven in about 1.6 seconds on a high end desktop. If we were to use GPUs, the proving could be performed in 0.35 seconds.\nMergeVerify cost\nIn terms of API, the MergeVerify() function of a Signature Merge scheme corresponds to the accumulator’s decider functionality.\nThe decider needs to perform two MSMs, one for each side of the curve. The MSM’s size equals to the circuit size, i.e., 2^{16}216 if we use lookups.\nEach of those MSMs can be performed in about 200ms using a decent modern laptop, or in 51ms using a high-end m6i.8xlarge AWS instance.\nCommunication overhead\nThe communication overhead of the Halo approach basically boils down to sending a Halo2 proof and an accumulator. Here is an informal breakdown of the sizes:\n\nHalo2 proof size:\n\nFor each witness column:\n\nCommitment (G𝐺 point)\nOpening value at random element (1 field element)\nIPA opening proof (2 log n2𝑙𝑜𝑔𝑛 group elements, 11 field element)\n\nAccumulator size:\n\nCommitment (G𝐺 point)\nOpening value at random element (1 field element)\nIPA opening proof (2 log n2𝑙𝑜𝑔𝑛 group elements, 11 field element)\n\nwhere n𝑛 is the circuit size (in our case around 2^{16}216).\nAll in all, the communication overhead depends on the circuit structure (the number of witness columns). We believe that the actual communicaton overhead will be between 5kb and 15kb, where the latter figure is for a circuit with 13 witness columns.\nPerformance Evaluation: Folding\nEvaluating the performance of the folding PCD scheme proved to be the most challenging task, mainly due to the open research issues surrounding folding and distributed prover PCD.\nIn the following section, we provide a preliminary assessment to initiate the evaluation process.\nMerge cost\nThe Merge operation is dominated by two tasks:\n\nComputing the cross term – an MSM of size C𝐶, the circuit size.\nComputing the instance for the witness of the folding process – the same size MSM.\n\nSo essentially 22 n𝑛-sized MSMs.\nThe cost of running the useful computation function F𝐹 will depend on howe folding lookup schemes will end up looking like.\nMergeVerify cost\nVerifying that the folded witness satisfies the folded instance is essesntially another n𝑛-sized MSM.\nCommunication overhead\nAs discussed in the “Witness size management” section, we expect the witness size that needs to be sent to the next prover to be in the order of 2-3MB for a bitfield of a million bits which is huge compared to the other approaches.\nFuture work\nWe welcome contributions in the following problems:\n\nWriting detailed specification of the PCD circuits for any of the three approaches\nImplementing any of the three approaches so that we can get more precise benchmarks\nTackling the open research questions posed in the folding section\nMore work on signature aggregation topologies for Ethereum\n\nGet in touch if you are interested in working on the above!\n\nAppendix A: Using a Signature Merge scheme in Ethereum\nConsider a gossip-based aggregation scheme:\nStart of aggregation protocol (Signature phase):\n\nAlice creates a sig with Sign() and sends it to Bob\n\nNext phase of aggregation protocol (Aggregation phase):\n\nBob verifies signatures with Verify()\nBob has received a bunch of sigs and uses Aggregate() to create a merged signature \\pi𝜋\nBob sends \\pi𝜋 to Charlie\n\nNext phase of aggregation protocol (Merge phase):\n\nCharlie verifies merged signatures with MergeVerify()\nCharlie has received a bunch of merged sigs and uses Merge() to create a merged signature \\pi𝜋\nCharlie sends \\pi𝜋 to Dave\n\n[Merge phase repeats…]\nFinal phase of aggregation (Post to block):\n\nDave sends his best merged signature \\pi𝜋 to the global topic (using the weight of GetSigners() to pick the best signature)\nPeter the proposer monitors the global topic and finds the best merged signature\nHe verifies it with MergeVerify() and puts it on the block\nHe uses GetSigners() to assign rewards to participating validators\n\nAppendix B: Performance estimates on STARK recursion\nFor given security level \\lambda𝜆 let \\phi_{\\lambda}(m)𝜙𝜆(𝑚) denote the number of hash calls needed to verify a STARK for a program that computes m𝑚 calls to 64-bit hash function Rescue/Poseidon (they have similar witness size). Then the proof size equals 32\\phi_{\\lambda}(m)32𝜙𝜆(𝑚) bytes. A verification circuit for checking a single STARK proof then computes \\phi_{\\lambda}(m)𝜙𝜆(𝑚) hashes. In order to recurse N𝑁 STARKs and keep the verification circuit constant size, we need\n\nN\\phi_{\\lambda}(m) <m\n𝑁𝜙𝜆(𝑚)<𝑚\nFigure 7 from the Starkware specification suggests that \\phi_{100}(m)\\leq 150 \\log_2 m𝜙100(𝑚) ≤150log2⁡𝑚. Thus we need m𝑚 such that \\frac{m}{\\log_2 m}>150N𝑚log2⁡𝑚 >150𝑁. For N=2𝑁 =2 we can choose m=2^{12}𝑚 =212 and \\phi_{100}(m)\\approx 1500𝜙100(𝑚) ≈1500.\n\n Sticking to 8192 signatures per slot post-SSF: how and why\n\n Lattice-based signature aggregation\n\n WHIR for Ethereum\n\n Separator-Based Participation Commitments for Post-Quantum Attestation Aggregation\n\n Orbit SSF: solo-staking-friendly validator set management for SSF\n\n read \n\n 13\n min\n\n 11 days later\n\n post by mratsim on Nov 22, 2023\n\n mratsim\n\nWe say that a Signature Merge scheme is lightweight if the size of π is minimal: it only uses a single bit for each user of the PKI system. In this post we concern ourselves only with lightweight Signature Merge schemes.\n\nNit: This is called a implicit/succinct data structure in Computer Science: Succinct data structure - Wikipedia\n\nIn computer science, a succinct data structure is a data structure which uses an amount of space that is “close” to the information-theoretic lower bound, but (unlike other compressed representations) still allows for efficient query operations. The concept was originally introduced by Jacobson[1] to encode bit vectors, (unlabeled) trees, and planar graphs. Unlike general lossless data compression algorithms, succinct data structures retain the ability to use them in-place, without decompressing them first. A related notion is that of a compressed data structure, insofar as the size of the stored or encoded data similarly depends upon the specific content of the data itself.\nSuppose that ℤ is the information-theoretical optimal number of bits needed to store some data. A representation of this data is called:\n\nimplicit if it takes ℤ + O(1) bits of space,\nsuccinct if it takes ℤ + o(ℤ) bits of space, and\ncompact if it takes O(ℤ) bits of space.\n\nFor example, a data structure that uses 2ℤ bits of storage is compact, ℤ + √ℤ bits is succinct, ℤ + log(ℤ ) bits is also succinct, and ℤ+3 bits is implicit.\n\nNit: in Computer Science, this is called the set reconciliation problem. This repo GitHub - AljoschaMeyer/set-reconciliation: An informal description on how to compute set union between two computers. has a bunch of papers to get started with but they focus on networking and probabilistic/fuzzy approaches while we need exact reconciliation.\nInterestingly, the bitcoin folks have their own set reconciliation library: GitHub - sipa/minisketch: Minisketch: an optimized library for BCH-based set reconciliation\n\nApproach 1) Recursive STARKs\nApproach 2) Recursive Halo2 (atomic accumulation)\nApproach 3) Folding (split accumulation)\n\nA new paper from 2 days ago might be uniquely suited to solve this very efficiently:\n\nSuccinct Arguments over Towers of Binary Fields\nIrreducible / binius · GitLab\nhttps://www.ulvetanna.io/news/binius-hardware-optimized-snark\n\nWe see three main advantages to binary tower field SNARKs. First, this approach offers much lower memory usage and computational cost by maximizing the benefits of small fields. Binius is already 50x more efficient than the next-best system that we benchmarked, plonky2, at committing 1-bit elements, and there are plenty of optimizations to come. The second benefit is compatibility with standard hash functions. Binary tower field SNARKs can efficiently perform bitwise operations like XOR and logical shifts, which are heavily used throughout SHA-256, Keccak-256, and other symmetric cryptography primitives.\n\nThis would make set union / merging bitfields extremely cheap\nAbstract:\n\nWe introduce an efficient SNARK for towers of binary fields. Adapting Brakedown (CRYPTO '23), we construct a multilinear polynomial commitment scheme suitable for polynomials over tiny fields, including that with 2 elements. Our commitment scheme, unlike those of previous works, treats small-field polynomials with zero embedding overhead. We further introduce binary-field adaptations of HyperPlonk’s (EUROCRYPT '23) product and permutation checks, as well as of Lasso’s lookup. Our scheme’s binary PLONKish variant captures standard hash functions—like Keccak-256 and Grøstl—extremely efficiently. With recourse to thorough performance benchmarks, we argue that our scheme can efficiently generate precisely those Keccak-256-proofs which critically underlie modern efforts to scale Ethereum.\n\n 2 months later\n\n post by albert-garreta on Jan 10, 2024\n\n albert-garreta\n\nThe HyperNova paper provides a method for folding lookups (Section 7). However the paper itself claims that that scheme is not suitable for folding lookups related to bitwise operations. I am wondering is this the case? What are these “certain polynomial equations”?\n\n 4 months later\n\n post by DNALOB on May 10, 2024\n\n DNALOB\n\n thanks for writing this. i found it very helpful.\n\n Powered by Discourse","tokens":9336,"squid":"spider-04","role":"Research Spider","at":1791347034422,"hash":"9f20d13d6824a7bd9d2e772ccb45ea1432491751"}
{"url":"https://docs.jup.ag/user-docs/earn/offerbook/multiply","domain":"docs.jup.ag","title":"Multiply on Offerbook - Jupiter Documentation","text":"Multiply is the leveraged side of Offerbook, and it comes in two flavours, both built on regular Offerbook loans:\n\nYield loops on stable yield-bearing assets, on the Multiply page of the header\nLeveraged longs on any collateral, from the Leverage tab of the Borrow view\n\nEither way, the position follows the same rules as any loan — fixed terms, no price-based liquidations during the loan, and a hard maturity. What Multiply adds is the packaging: the position is opened against your USDC deposit, sized by a leverage multiple, and unwound as a whole.\nLeverage amplifies both gains and losses on the collateral asset. A Multiply position also remains a fixed-term loan: as the interface states, close or repay within the term or you lose your deposit. There are no price-based liquidations, but there is no way around maturity either. Opening and closing the position involve swapping between USDC and the collateral asset, which exposes both legs to slippage. The estimated APYs price in the expected cost of these swaps, but the slippage you actually get can differ.\n​The Multiply page\nThe Multiply page lists the stable yield-bearing assets on the book as cards, in two views:\n\nAvailable (the default): the loops you can open right now, those that beat simply holding the asset and that lenders can fund, with swap costs priced into the estimate. Each card shows the asset price, its native yield, the estimated Multiply APY (“Est. Multiply APY up to 18.7%”), the USDC available, the term, and a Multiply button\nAll: every stable yield-bearing asset on the book, including loops that do not currently beat holding and assets no lender has priced yet. Those are flagged “unlooped” with their native yield: the first lender sets the rate (Post the first offer)\n\n​The asset page\nClicking an asset opens its page (for example Multiply ONyc), with header stats (native yield and its source, best estimated looped APY, maximum leverage, available liquidity, and a Lend USDC shortcut), an APY chart (average estimated APY, the asset’s native APY, and the average borrow APY, over 24H, 7D or 30D), and the table of live offers usable for the loop: estimated APY, maximum leverage, borrow APY, duration, LTV, and available USDC.\nOffers whose borrow cost exceeds the asset’s yield show a negative estimated APY, flagged Below holding: at those terms, looping earns less than simply holding the asset. The table makes this explicit rather than hiding those offers.\n​Opening a loop\nThe Multiply tab of the widget on the asset page is where the position is opened:\n\nThe selected offer’s terms are summarized: estimated looped APY, the asset’s native yield, the borrow cost including fee (an offer at 6% APY shows a 7.50% borrow cost, the all-in rate), the LTV, and the available liquidity\nSlippage presets (0.01%, 0.05%, 0.1%) control the tolerance on the entry swap\nYou deposit USDC and click Loop: the position is opened at the offer’s leverage\n\nThe reminder under the button states the deal plainly: close or repay within the term or you lose your deposit — no price-based liquidations. Once open, the position appears under Dashboard > Positions, in the Looped group of the Borrowing side.\n​Leveraged longs from the Borrow view\nThe Leverage tab of the Borrow view opens a leveraged long on any collateral, not just yield-bearing assets: pick the Asset to long (leveraged with USDC), set Your deposit and the Max leverage slider, and take one of the best-leverage offers. If no offer matches, try a shorter minimum duration or another asset. The resulting position is a Multiply position like any other. See Borrowing.\n​Closing or repaying a position\nMultiply positions live under Dashboard > Positions, in the Looped group of the Borrowing side, with their PnL. Two ways out, from the row’s actions:\n\nClose opens the Close position view: the collateral is swapped to USDC at market, the loan is repaid, and the remainder hits your wallet — in one wallet prompt. Before you confirm, the view recaps the position (APY, owed, time left), lets you set the exit-swap slippage (Auto, 0.01%, 0.05%, 0.1%), and shows what you deposited, what you receive (with a worst-case floor derived from the slippage) and the resulting PnL.\nRepay settles the loan like any other Offerbook loan: you repay the owed USDC yourself and keep the collateral asset.\n\n​Lending on Multiply assets\nEach asset page also has a Lend tab: lend USDC against the looped asset, at a fixed rate, secured by collateral that keeps accruing yield if it ever lands in your hands. The form sets the amount, the APY, the duration in days, and the minimum LTV the borrower must lock (higher LTV means deeper loops, less cushion).\nThe widget adds one loop-specific number, the loop break-even rate: price your offer below it and it becomes the top loop; above it, loopers earn more by simply holding the asset, and your offer competes on duration and LTV only. The ceiling starts from the asset’s native yield and prices in the 25% fee on interest and the two swaps a borrower pays to open and close (simulated through Jupiter at current market depth, spread over the duration) — so longer durations raise it.\nAs the interface states when posting: you are posting an offer, not depositing. Your USDC only moves (and starts earning) when a borrower fills it, partial fills are allowed (minimum $10), unfilled liquidity is withdrawable at any time, and the offer expires after 7 days at most, like any lend offer.\n​What it costs\nA Multiply position carries the economics of the underlying loan: the borrow cost displayed is all-in (offer APY plus the upfront fee), network fees and account rent apply, and the estimated looped APY nets out both the borrow cost and the expected cost of the open and close swaps; the net APY of an open position subtracts them too. See Fees and Costs.","tokens":1458,"squid":"spider-02","role":"Liquidity Spider","at":1791347058086,"hash":"00569f4b42421a34cd4cb4ed90625e5a24316133"}
{"url":"https://docs.jup.ag/user-docs/earn/offerbook/extensions","domain":"docs.jup.ag","title":"Loan Extensions on Offerbook - Jupiter Documentation","text":"An extension rolls an active loan into a fresh period on the same terms: same rate, same collateral amount, new deadline. The borrower pays the closing period’s interest, the principal stays borrowed, and the collateral never moves.\nExtensions are opt-in on the lender’s side and manual on the borrower’s side. Nothing rolls over by itself.\nExtensions are never automatic. You extend manually, and only before the deadline. Past maturity the lender can claim your collateral as usual — an extendable loan is not a safety net. See Borrowing.\n​Lenders: allowing extensions\nAllow extensions (“same terms, new deadline”) is a toggle you set when creating an offer. It appears in every offer creation surface: the offer wizard, Pro, the borrow request form, the composer on the Borrow page, and the Multiply lend panel.\nLoans filled from that offer start extendable. The toggle is only a starting value:\n\nAfter a fill, you can revoke or re-grant the permission per loan\nRevoking never shortens the period already running — it only prevents the next extension\n\n​Borrowers: spotting and using them\nExtendable offers carry a ↻ marker next to their duration everywhere offers are listed: the offer book, the Borrow page, Pro, and collectible cards.\nOnce you fill one, the loan’s row in Dashboard > Positions leads with an Extend button while the loan runs. Repaying stays one click away in the row menu. To extend several loans at once, select them on the Dashboard and extend them together, in fewer wallet prompts.\n​What an extension costs and changes\nBefore confirming, the panel shows exactly what you pay and what changes:\nLineMeaningInterestThe closing period’s interest, paid nowOrigination feeThe protocol fee on the new period. See Fees and CostsNew deadlineThe fresh period, starting when the transaction confirms\nTwo things are worth knowing:\n\nThe new deadline replaces the current one rather than adding to it. Extending the day you take the loan wastes the time you already paid for, so extending near expiry gets you the most.\nThe principal and the collateral never move. Only the deadline and the interest clock reset.\n\n​Lenders earn every period\nEach extension settles the closing period’s interest to the lender immediately, so the capital keeps earning without being redeployed into a new offer. The lender gets a Loan extended notification when it happens (see Settings & Notifications).\nExtended loans wear an ×N badge, and the loan panel keeps the full extension history: the date, the interest paid, and each new deadline.","tokens":634,"squid":"spider-02","role":"Liquidity Spider","at":1791347068085,"hash":"83c7c00c7a493ba24c7765e213043cb9b4040ad1"}
{"url":"https://ethresear.ch/t/signature-merging-for-large-scale-consensus/17386/4","domain":"ethresear.ch","title":"Signature Merging for Large-Scale Consensus - Cryptography - Ethereum Research","text":"Cryptography\n\n signature-aggregation,single-slot-finality\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 Nov 2023\n\n 4 / 4\n\n May 2024\n\n May 2024\n\n post by asn on Nov 10, 2023\n\n asn\n\n Signature Merging for Large-Scale Consensus\nAuthors: George Kadianakis, Dmitry Khovratovich, Zhenfei Zhang, Mary Maller\n\\cdot⋅\nMany thanks to Jeremy Bruestle, Vitalik Buterin, Srinath Setty and Arantxa Zapico!\n\\cdot⋅\nIn this post we focus on tools to perform massive-scale signature aggregation for Proof-Of-Stake blockchains.\nWe first present the bitfield merge problem in the context of the Ethereum consensus protocol. To solve it we introduce a new signature aggregation technique called Signature Merge and demonstrate how it can be used in Ethereum. We then provide three instantiations of Signature Merge using Proof-Carrying Data (PCD) techniques via recursive SNARKs and decentralized proving. Alongside these approaches, we highlight open research challenges related to the scalability of PCD constructions. To close off, we offer preliminary performance evaluations to give readers a glimpse into the expected efficiency of these schemes.\n\nIntroduction\nProof of Stake (PoS) systems essentially are open ballot voting systems where validators need to come to consensus. In those consensus systems, cryptographic signatures act as ballots. Validators publicly show their agreement by signing the same message.\nWe want to enable future PoS systems to operate in massive scale with potentially millions of voters, as required by Ethereum’s Single Slot Finality scheme. In such big P2P systems it’s essential to optimize the way these signatures get collected.\nSignature Aggregation\nSignature aggregation schemes allow multiple signatures to be combined into one. Aggregation significantly reduces the communication and verification overhead of the system even with a vast number of validators. A famous such scheme is the BLS signature scheme.\nUsing BLS, signatures can be easily aggregated, but tracking the identity of the signers requires another layer of representation - this is where Ethereum uses bitfields. These bitfields act as a sort of ‘participation list’, marking who among the validators has signed the message. Bitfields are a binary representation of a participants list: ‘1’ at index i𝑖 means that validator at index i𝑖 signed the message.\nKnowing the identity of the participants is essential for the Ethereum consensus because of slashing, staking rewards and the inactivity leak.\nimage.png992×522 11.9 KB\nThe Bitfield Merge Problem\nConsider a signature aggregation system where a collector entity needs to aggregate two aggregated signatures and their bitfields. Aggregating the signature is easy, but merging the bitfield can be tricky.\nimage.png1282×432 18.6 KB\nFor instance, consider two bitfields: 110 and 010. Merging them isn’t as straightforward as summing numbers. The latter would result in 120, a value that isn’t binary and is twice more expensive to send over the network.\nFurthermore, the BLS verifier must know how many times a signature has been aggregated during verification, so that she can compute the correct verification key. That is, the aggregated signature behind 120 has a different verification key from the signature behind 110.\nThe Bitfield Merge Problem in Consensus\nThe above issue is encountered in tree-based aggregation topologies as discussed in the Horn proposal, when aggregating already aggregated signatures in the tree’s upper sections.\nThe issue can also be seen in gossip-based aggregation topologies where aggregations are gossiped in a chaotic non-deterministic fashion, as seen in the figure below and was suggested in the past by Vitalik. For networks with a big number of validators but a small number of networking nodes, gossip-based aggregation can be more efficient than a tree-based structure: in such a setting if Alice has 1000 validators she can start the protocol with a populated bitfield of weight 1000 without any prior communication. Furthermore the unstructured property of gossip-based approach can allow more privacy-friendly aggregation protocols.\n681×501 34.4 KB\nDue to bandwidth being a fundamental scaling factor in P2P systems, we want to keep using bitfields to denote participation since using heavier representations causes further strain on the networking layer.\nWe call merging the operation of accumulating two bitfields and producing a bitfield.\nIn this post we propose Signature Merge schemes as a solution to the bitfield aggregation problem, and three possible instantiations using SNARKs.\nSignature Merge schemes\nA Signature Merge (SM) scheme supports the recursive merging of signatures and their bitfields while still allowing the extraction of the signer set out of them. In this section we present the interface of an SM scheme, and in Appendix A we show how it can be used in the context of Ethereum.\nFollowing the steps of [GV22], SM schemes are similar in terms of functionality to classic signature aggregation schemes but they introduces the Merge , MergeVerify and GetSigners algorithms.\nAdditionally, the MergeVerify function does not take as input specific verification keys. Instead it has oracle access to a PKI system which can be queried to retrieve verification keys using a user’s index or a participation bitfield. The PKI system is updated with every call to Keygen.\nFinally, the GetSigners method returns a bitfield containing the signers of a merged signature.\nA Signature Merge (SM) Scheme has the following algorithms:\n\nSetup(1^\\lambda1𝜆) \\rightarrow pp→𝑝𝑝: Outputs public parameters pp𝑝𝑝 which are implicitly given to all algorithms\n\nKeygen(1^\\lambda, \\text{PKI}) \\rightarrow (\\text{sk}, \\text{vk}, k)1𝜆,PKI) →(sk,vk,𝑘): Generates secret signing key and public verification key for a user and registers the public key to the \\text{PKI}PKI. Also returns the user’s index k𝑘 in the \\text{PKI}PKI system.\n\nSign(\\text{sk}, msk,𝑚) \\rightarrow \\sigma→𝜎: Takes as input a signing key sk𝑠𝑘 and a message m𝑚 and computes a signature \\sigma𝜎\n\nVerify(\\text{vk}, \\sigma, m) \\rightarrow 0/1vk,𝜎,𝑚) →0/1: Takes as input a verification key \\text{vk}vk, a message m𝑚 and a signature \\sigma𝜎 and returns whether the signature is valid or not.\n\nAggregate^\\text{PKI}(m, \\{ ( \\sigma_i, k_i ) \\}_i) \\rightarrow \\piPKI(𝑚,{(𝜎𝑖,𝑘𝑖)}𝑖) →𝜋 : The aggregation algorithm takes as input a sequence of signatures \\sigma_i𝜎𝑖 with user PKI indices k_i𝑘𝑖 and outputs a merged signature \\pi𝜋. It also has access to a PKI system which can be queried to retrieve any verification key.\n\nMerge^\\text{PKI}(m,\\{ \\pi_i \\}_i) \\rightarrow \\piPKI(𝑚,{𝜋𝑖}𝑖) →𝜋: The merge algorithm takes as input a sequence of merged signatures \\pi_i𝜋𝑖 and outputs a merged signature \\pi𝜋. It also has access to a PKI system which can be queried to retrieve any verification key. Note that Merge allows us to combine merged signatures \\pi_i𝜋𝑖 without knowing any of the underlying individual signatures \\sigma_i𝜎𝑖.\n\nMergeVerify^\\text{PKI}(m, \\pi) \\rightarrow 0/1PKI(𝑚,𝜋) →0/1: The merged signature verification algorithm takes as input a message m𝑚 and a merged signature \\pi𝜋 and outputs whether the signature is valid or not. It also has access to a PKI system which can be queried to retrieve any verification key.\n\nGetSigners^\\text{PKI}(\\pi) \\rightarrow bPKI(𝜋) →𝑏: Given a merged signature \\pi𝜋, return a bitfield corresponding to the indices of all the signers who participated.\n\nNote that merged signatures must have size linear to the number of signers, otherwise the GetSigners method would not be able to recover all the signers of a merged signature, violating incompressibility.\nWe say that a Signature Merge scheme is lightweight if the size of \\pi𝜋 is minimal: it only uses a single bit for each user of the PKI system. In this post we concern ourselves only with lightweight Signature Merge schemes.\nSecurity of Signature Merge Schemes\nSecurity of SM schemes is defined similarly to aggregation schemes. Let i𝑖 denote the index of an honest signer. An SM scheme is unforgeable if no polynomial time adversary can produce verifying (m, \\pi)(𝑚,𝜋) such that b = \\mathbf{GetSigners}^\\text{PKI}(\\pi)𝑏 =𝐆𝐞𝐭𝐒𝐢𝐠𝐧𝐞𝐫𝐬PKI(𝜋) and the ith𝑖𝑡ℎ bit of b𝑏 is equal to 1 (b_i = 1𝑏𝑖 =1), unless party i𝑖 has previously signed m𝑚.\nSignature Merge Instantiations\nIn the upcoming sections, we provide a primer on recursive SNARKs and PCD, followed by three distinct methodologies to materialize a Signature Merge scheme via different recursive SNARK paradigms.\nProof-Carrying Data using Recursive SNARKs\nRecursive SNARKs are cryptographic proof systems where the SNARK verifier is succinct enough to be evaluated inside another SNARK circuit. This ‘nesting’ can be performed repeatedly, allowing for an aggregation of multiple proofs into one.\nimage1124×336 20.1 KB\nWhen combined with the Proof-Carrying Data (PCD) paradigm, we can start thinking of the participation bitfields as the main object of our Signature Merge system. The bitfields, depicted as m_i𝑚𝑖 in the figure above, always travel with associated proofs, depicted as \\pi_i𝜋𝑖. A receiver can verify the proof, and be convinced that the bitfield is the product of a series of valid signature verifications and bitfield merges.\nApproach 1) Recursive STARKs\nIn this section we present a straightforward Signature Merge scheme based on recursive STARKs.\nThe approach is based on a recursive STARK circuit that consumes signatures or other STARKs alongside their associated bitfields. The circuit verifies every signature and STARK received and merges their bitfields. The circuit’s output is the merged bitfield and the STARK proof.\nWhile this is not the most efficient of our suggested approaches, it’s the conceptually simplest approach and also offers post quantum guarantees.\nHere, a STARK is a hash-based proof of a polynomial equation, which encodes a certain computation. A recursive STARK is specific in that the computation contains the verification of other STARKs. Therefore, the Merge step consists of the following:\n\nVerifying the incoming STARK proofs with their own bitfields.\nCreating a STARK proof that the incoming proofs are valid and the union of their bitfields equals the alleged result. This step requires constructing a number of Merkle trees that hash in the entire computation trace, i.e. the verification of STARKs and unionizing the bitfields.\nPublishing the STARK proof, which contains of a number of openings in the just-constructed Merkle trees.\n\nThe recursive STARK circuit\nimage.png1364×490 10.9 KB\nUsing a simple and slim hash-based signature scheme (e.g. Winternitz) instead of BLS, we introduce the following recursive STARK relation:\n\nPublic inputs: Root of all pubkeys R𝑅, public bitfield b𝑏, message hash m𝑚\nPrivate inputs: N𝑁 STARKs with N𝑁 bitfields, and optionally a signature along with a participant index\nStatement:\n\nRecursive STARK verification: For all 1 \\le i \\le N1 ≤𝑖 ≤𝑁, the i’th provided STARK is a valid STARK of this statement using the i𝑖 ’th bitfield and the same R𝑅 and m𝑚\nSignature verification: If a signature is provided, check that it’s a valid signature of m𝑚 with the pubkey at the position defined by the participant index in the pubkeys tree rooted in R𝑅\nBitfield union: The public bitfield is the union of all the bitfields in the STARKs, with 1s filled in for each of the m𝑚 indices for which we have individual signatures\n\nThe circuit is informally depicted above to demonstrate how the recursion works (observe how the inputs match the outputs).\nApproach 2) Recursive Halo2 (atomic accumulation)\nA computationally cheaper approach compared to full recursion would be to use an atomic accumulation scheme like the original Halo construction.\nThe approach here is similar to full recursion in that we still verify proofs inside SNARKs, but the Halo approach is lighter for the prover: Halo only implements the lightweight part of the verifier inside the SNARK, while deferring any expensive operations. These operations get deferred to the end of the recursion chain.\nHalo2-IPA\nThe original Halo paper was written on top of the Sonic arithmetization scheme, but we can adapt the protocol to a modern Plonkish based scheme and use IPA polynomial commitments to perform the final polynomial vanishing argument. This is exactly what zcash has done with halo2, but we also need it to support deferred recursion.\nNote that in halo2, the most expensive operation of the verifier is verifying IPA openings. Using the techniques from Halo we can defer the expensive in-circuit MSM needed when verifying the IPA opening proofs. At each recursive step, we defer this expensive operation and accumulate it into an accumulator. Finally, when we need to pass the proof to the next person, that person must verify both the proof and the accumulator.\nFurthermore, we also need to adjust the scheme to implement Proof-Carrying Data but fortunately the “Proof-Carrying Data from Accumulation Schemes” paper provides a construction we can use for benchmarking purposes.\nThe Halo PCD circuit\nNow let’s dig deeper into how the Halo PCD circuit looks like. For this section, we will be considering recursive circuits that verify two proofs, essentially allowing PCD with a binary tree structure.\nThe circuit takes as input two tuples (\\pi_0, acc_0, z_0)(𝜋0,𝑎𝑐𝑐0,𝑧0) and (\\pi_1, acc_1, z_1)(𝜋1,𝑎𝑐𝑐1,𝑧1). Where (\\pi_0, acc_0)(𝜋0,𝑎𝑐𝑐0) is the first IPA proof and its accumulator, while z_0𝑧0 corresponds to the useful inputs to the circuit. For example, z_0𝑧0 can be seen as a tuple (\\sigma_0, b_0)(𝜎0,𝑏0) where \\sigma_0𝜎0 is an optional signature, and b_0𝑏0 is a bitfield.\nNote that in Halo2, the entire proof system gets reduced to a single IPA proof. Also, note that both the proof and the accumulator have the same form: they are both IPA proofs.\nOur PCD circuit has two tasks:\n\nCheap-verify the proofs and accumulators (\\pi_0, acc_0)(𝜋0,𝑎𝑐𝑐0) and (\\pi_1 ,acc_1)(𝜋1,𝑎𝑐𝑐1), while accumulating the expensive MSM operations into acc_{out}𝑎𝑐𝑐𝑜𝑢𝑡\nPerform the useful computation function F𝐹 given the inputs z_0𝑧0 and z_1𝑧1:\n\nIf a signature was provided, verify the signature.\nReturn the union of the provided bitfields.\n\nBelow you can see an informal rendition of the circuit:\nimage.png1376×400 21.6 KB\nNote that in real life, the circuit could look different. For instance, maybe the circuit doesn’t output the accumulator, it just checks its validity, and the accumulator is computed out-of-circuit.\nApproach 3) Folding (split accumulation)\nThe other end of the spectrum is the recent line of work on folding. Folding allows us to replace the expensive in-circuit SNARK verifier, with a much simpler folding verifier. This significantly decreases the prover’s computational overhead of recursion since no proof verification actually happens inside the circuit.\nThe folding process deals with witnesses W𝑊 to a certain structure \\mathcal{S}S and instances U𝑈. The structure in the original Nova is a set of matrices that define an R1CS relation; later on this is generalized to CCS (higher-degree constraints) in Hypernova and to polynomial equations in Protostar. The witness is a set of values satisfying the structure equations (i.e. R1CS constraints in Nova) and instance is a commitment to the witness plus some metadata. We note that the actual structure is not exactly R1CS but a more general relaxed R1CS, where certain error terms are introduced.\nThe actual folding is a procedure to compute the folded witness W_{folded}𝑊𝑓𝑜𝑙𝑑𝑒𝑑 out of l𝑙 input witnesses W_1,\\ldots, W_l𝑊1,…,𝑊𝑙, then to compute cross terms T𝑇 from the same witnesses, and finally to compute folded instance U_{folded}𝑈𝑓𝑜𝑙𝑑𝑒𝑑 from input instances U_1,\\ldots, U_l𝑈1,…,𝑈𝑙 and T𝑇. The entire procedure is done in the challenge-response fashion, which guarantees that W_{folded}𝑊𝑓𝑜𝑙𝑑𝑒𝑑 satisfies U_{folded}𝑈𝑓𝑜𝑙𝑑𝑒𝑑 only if for each i𝑖 there exists a W_i𝑊𝑖 satisfying U_i𝑈𝑖.\nTo make an IVC, the prover creates a circuit \\mathcal{S}'S′ that encompasses both the last step of the folding process (which does not depend on the witness size) and the useful computation F𝐹, plus some extra hashing steps that bind together instances and the IVC inputs-outputs. Then the witness W'𝑊′ to this circuit is committed to in order to create a new instance U'𝑈′. Having required that the instances to be folded have the same structure, i.e. \\mathcal{S}'=\\mathcal{S}S′ =S, then U'𝑈′ can be folded with U𝑈 at the next step of IVC.\nFolding schemes have smallest recursion overhead, but they also come with a variety of open research questions that we discuss below.\nMoving Nova to PCD\nNova as depicted in the original paper is tailored for IVC chain-like computations. In contrast, Signature Merge requires a PCD graph-like structure with nodes accepting arbitrary proofs from other nodes with no clear global order.\nAdjusting Nova for PCD requires us to introduce an additional instance-witness pair into the circuit \\mathcal{S}S. This results in a more complex S𝑆 as well as more constraints needed to fold the extra pair.\nThe same approach has been previously proposed by the Paranova project, noting that it allows PCD using a binary-tree structure.\nMinimizing the curve cycle\nBoth folding and recursive Halo2 require us to compute elliptic curve operations inside circuits. This can be done using non-native arithmetic or using cycles of curves. Most projects rely on cycles of curves since non-native arithmetic is many orders of magnitude more expensive than normal arithmetic.\nHowever, using cycles of curves results in a complicated system as proofs need to be produced in both curves and they need to be correctly linked and verified.\nThe recent work on Cyclefold is particularly useful in our PCD setting as it can reduce the complexity on the second curve. Using Cyclefold the second curve is only used to assist with scalar multiplications, without needing to perform any of IVC/PCD operations.\nHashing public inputs\nThe folding circuit necessarily contains hashings of inputs and outputs of IVC together with folded instances. As in-circuit hashing is relatively expensive, we need a way to compress the inputs even further.\nFolding lookups\nAgain, as binary decomposition is too expensive, we seek a way to implement lookups to speed up the OR operation. The problem is that the lookup arguments require a support of certain polynomial equations, and most folding schemes do not support such equations out of the box. We investigate for possible ways of integrating lookups into (Hyper)Nova with minimal impact to definitions and proofs.\nWitness size management\nIn order to perform folding, the aggregator needs the full witness to each folded instance. For a PCD, this makes the witness of each input instance at least as big as the witness for the PCD step function. In our case it is the witness for the OR operation over two 1 mln bit inputs, which requires at least 3 mln bit witness, or 12 K field elements. The folding operation requires several scalar multiplications, which totals to 10-20K witness elements as well. Altogether, a PCD folding prover receives as witness 2-3 MB of data from each of two senders.\nDeeper dive into Signature Merge circuits\nIn this section we dig deeper into some SNARK-related themes that all the approaches above have in common.\nAll the approaches above have similar functionality: we are dealing with SNARK circuits that verify signatures, and also compute unions of bitfields. In this subsection, we are going to talk about performing these operations inside SNARKs in more detail.\nVerifying signatures inside SNARKs\nWe need to choose a signature scheme that is easy to verify inside SNARKs. We assume that the message to be signed is constant size (approx. 256 bits) being a hash of public value, and varies for each aggregation process. Given that the recursion overhead in all approaches is at least a few scalar multiplications, we can choose from the following variants:\n\nSchnorr-like signatures: A simple discrete-log based scheme which requires only one elliptic curve scalar multiplication inside the circuit. Similar schemes are based on ECDSA signatures.\nProof of preimage. Here a signature is a proof of knowledge of secret key k𝑘, which is hashed to get public key K= H(k)𝐾 =𝐻(𝑘) with H𝐻 being some hash function. The actual message is part of the context in the proof process. The proof method is chosen to be native for the signature aggregation method, i.e. IPA for Halo-IPA, STARK for recursive STARKs and folding. The costs are mostly determined by the proof method but also dependent on the hash function used in the signature, which should not be too expensive.\nProof of encryption key. This method resembles the previous one, with the public key K𝐾 being the encryption of some constant (say, 0) on the secret key k𝑘, i.e. K = E_k(0)𝐾 =𝐸𝑘(0). The actual signature may or may not be the result of the encryption as well, like in the FAEST scheme.\n\nWhile the choice of the signature scheme might initially seem important, it’s actually of lesser importance since in all recursive SNARK constructions, the SNARK verifier inside the circuit dominates the performance of the scheme.\nBitfield union using lookups\nThe process of taking the union of two bitfields is a straightforward logic operation, but it does not translate that nicely into the language of arithmetic circuits.\nA naive approach would involve decomposing the bitfields into bits, and then working over each bit separately, making sure that the two input bits match the output bit. This means that we have to spend O(logd)𝑂(𝑙𝑜𝑔𝑑) constraints, where d𝑑 is the size of the bitfield.\nThis seems like the perfect environment to use lookup arguments, which allow us to chunk together multiple bits and spend a single constraint for each chunk.\nConsider a lookup table of all possible OR outputs of two bitfields of size 2^525. This means that we can chunk bitfields into chunks of five bits, and use the lookup protocol to perform the union.\nManaging circuit size\nIt’s important to observe how the size of the circuit impacts the above approaches. The bigger the circuit, the more painful it is to recursively verify it.\nIt’s also worth noting that in many signature aggregation protocols, the protocol will begin by merging tiny bitfields before moving to bigger and bigger bitfields. For this reason, it would be ideal if we only had to pay for what we use: use a small circuit size when working with small bitfields.\nThis can be achieved by working with multiple circuits: Since the size of the output bitfield is public, the prover can always choose the circuit best suited to the size of the input bitfields. This can work very well in tree-based aggregation protocols where the bitfield sizes and the provers are known in advance.\nAnother approach is chunking up the statement that is proven: Instead of working with the full bitfield, work with smaller chunks at a time, and produce multiple proofs when needed. At the beginning of the protocol, the provers will be dealing with small circuits and producing a single proof, but as the protocol goes on and the bitfields grow, the provers will need to produce multiple proofs per bitfield, and hence the recursion overhead will grow.\nPerformance evaluation\nIn this section, we aim to give you a sense of what to expect in terms of performance for the discussed schemes.\nIt’s important to note that obtaining precise figures without fully implementing the schemes is challenging, especially given the presence of unresolved questions.\nWe start with an overview presented in the table below, and then delve into each scheme individually.\n\nMerge cost\nMergeVerify cost\nCommunication overhead\n\nRecursive STARKs\nBad\nVery Good\nBad\n\nRecursive Halo2\nOK\nOK\nGood\n\nFolding\nGood\nOK\nVery Bad\n\nPerformance Evaluation: Recursive STARKs\nWhile it’s hard to get reasonable benchmarks for the recursive STARK scheme without an implementation, in this section we present benchmark data provided by the RISC0 team who are using STARK recursion in alternative applications.\nWhile the RISC0 benchmarks are certainly useful, it’s worth pointing out that designing a custom circuit precisely for our use case would allow us to tweak the various parameters of the system (e.g. hash function, finite field, security params, etc.) and the actual numbers could look wildly different.\nIn Appendix B, we present a work-in-progress draft for a formulaic approach to evaluating the prover performance of recursive STARKs.\nMerge cost\nIn terms of API, in this section we will be considering the costs of the Merge() function of a Signature Merge scheme (i.e. merging two bitfields together).\nThe RISC0 prover currently spends 2.5 seconds to recursively verify 2 STARKs inside a circuit. This effectively allows N = 2𝑁 =2 in the circuit above, and enables a binary “proof tree” structure which is common in PCD applications.\nThe RISC0 system aims for 100-bit of security and the majority of the prover’s time is spent on hashing the full witness. The figure above comes from a prover equipped with an Nvidia A4000 GPU, which is specialized hardware that validators normally don’t have.\nThe RISC0 team believes that by further optimizing their GPU implementation and their algorithms, they can get up to 4x improvement in the prover speed in the next years (potentially bringing the cost of Merge to below a second).\nRISC0’s circuit is proving RISC0 VM instructions whereas our circuit is verifying signatures and merging bitfields. From discussions with the RISC0 team, we believe that the underlying application is not so important, because the large STARK verifier circuit dominates the prover’s performance.\nMergeVerify cost\nSuper fast! A few miliseconds.\nCommunication overhead\nThe STARK’s proof size comes to about 300kb (depending on the security parameters), which is quite big.\nPerformance Evaluation: Recursive Halo2\nIn this section, we will be considering participation bitfields of size 1 million bits. This means that they can be expressed using 2^{12}212 field elements. We estimate that the final circuit will have size about d = 2^{16}𝑑 =216 since it needs to at least process the two input bitfields.\nMerge cost\nThe prover time in this scheme is the time it takes to perform the useful computation (i.e. merge bitfields or verify signatures), plus the time it takes to recursively verify any proofs provided.\nProver time for useful computation:\n\nSignature verification: 200-2000 R1CS/(low-degree Plonkish) gates\nBitfield union:\n\nPlain: 2^{21}221 gates (degree-2) for binary decomposition and 2^{20}220 gates for the union operation.\nWith lookups: 1 gate per 8x8 bitwise OR: 120K gates and table of size 64K entries.\n\nRecursive overhead (essentially the runtime of algorithm \\mathbb{P}ℙ from section 5.1 of the “Proof-Carrying Data from Accumulation Schemes” paper):\n\nDeferred IPA verification for all proofs and accumulators (\\pi_0, acc_0, \\pi_1, acc_1)(𝜋0,𝑎𝑐𝑐0,𝜋1,𝑎𝑐𝑐1):\n\n4 \\cdot 2 \\cdot logd = 4 \\cdot 2 \\cdot 16 = 1284 ⋅2 ⋅𝑙𝑜𝑔𝑑 =4 ⋅2 ⋅16 =128 ECMULs\n4 \\cdot 2 \\cdot logd = 1284 ⋅2 ⋅𝑙𝑜𝑔𝑑 =128 ECADDs\n4 \\cdot logd = 644 ⋅𝑙𝑜𝑔𝑑 =64 hashes\n\nFinally, let’s compute the total recursive circuit size:\n\nAssuming a 8-bits preproceessed lookup table, the bit field union circuit can be implemented within 2^{20-8} = 2^{12}220−8 =212 constraints.\nUsing Jellyfish’s custom gate, each ECMUL takes 300 plonkish constraints, each poseidon hash takes 200 plonkish constraints. The deferred IPA verification circuit can be implemented within 51200\\approx 2^{16}51200 ≈216 constraints.\n\nThe recursive circuit size is therefore estimated at 2^{16}216 constraints.\nUsing the Pallas/Vesta curves, such a circuit can be proven in about 1.6 seconds on a high end desktop. If we were to use GPUs, the proving could be performed in 0.35 seconds.\nMergeVerify cost\nIn terms of API, the MergeVerify() function of a Signature Merge scheme corresponds to the accumulator’s decider functionality.\nThe decider needs to perform two MSMs, one for each side of the curve. The MSM’s size equals to the circuit size, i.e., 2^{16}216 if we use lookups.\nEach of those MSMs can be performed in about 200ms using a decent modern laptop, or in 51ms using a high-end m6i.8xlarge AWS instance.\nCommunication overhead\nThe communication overhead of the Halo approach basically boils down to sending a Halo2 proof and an accumulator. Here is an informal breakdown of the sizes:\n\nHalo2 proof size:\n\nFor each witness column:\n\nCommitment (G𝐺 point)\nOpening value at random element (1 field element)\nIPA opening proof (2 log n2𝑙𝑜𝑔𝑛 group elements, 11 field element)\n\nAccumulator size:\n\nCommitment (G𝐺 point)\nOpening value at random element (1 field element)\nIPA opening proof (2 log n2𝑙𝑜𝑔𝑛 group elements, 11 field element)\n\nwhere n𝑛 is the circuit size (in our case around 2^{16}216).\nAll in all, the communication overhead depends on the circuit structure (the number of witness columns). We believe that the actual communicaton overhead will be between 5kb and 15kb, where the latter figure is for a circuit with 13 witness columns.\nPerformance Evaluation: Folding\nEvaluating the performance of the folding PCD scheme proved to be the most challenging task, mainly due to the open research issues surrounding folding and distributed prover PCD.\nIn the following section, we provide a preliminary assessment to initiate the evaluation process.\nMerge cost\nThe Merge operation is dominated by two tasks:\n\nComputing the cross term – an MSM of size C𝐶, the circuit size.\nComputing the instance for the witness of the folding process – the same size MSM.\n\nSo essentially 22 n𝑛-sized MSMs.\nThe cost of running the useful computation function F𝐹 will depend on howe folding lookup schemes will end up looking like.\nMergeVerify cost\nVerifying that the folded witness satisfies the folded instance is essesntially another n𝑛-sized MSM.\nCommunication overhead\nAs discussed in the “Witness size management” section, we expect the witness size that needs to be sent to the next prover to be in the order of 2-3MB for a bitfield of a million bits which is huge compared to the other approaches.\nFuture work\nWe welcome contributions in the following problems:\n\nWriting detailed specification of the PCD circuits for any of the three approaches\nImplementing any of the three approaches so that we can get more precise benchmarks\nTackling the open research questions posed in the folding section\nMore work on signature aggregation topologies for Ethereum\n\nGet in touch if you are interested in working on the above!\n\nAppendix A: Using a Signature Merge scheme in Ethereum\nConsider a gossip-based aggregation scheme:\nStart of aggregation protocol (Signature phase):\n\nAlice creates a sig with Sign() and sends it to Bob\n\nNext phase of aggregation protocol (Aggregation phase):\n\nBob verifies signatures with Verify()\nBob has received a bunch of sigs and uses Aggregate() to create a merged signature \\pi𝜋\nBob sends \\pi𝜋 to Charlie\n\nNext phase of aggregation protocol (Merge phase):\n\nCharlie verifies merged signatures with MergeVerify()\nCharlie has received a bunch of merged sigs and uses Merge() to create a merged signature \\pi𝜋\nCharlie sends \\pi𝜋 to Dave\n\n[Merge phase repeats…]\nFinal phase of aggregation (Post to block):\n\nDave sends his best merged signature \\pi𝜋 to the global topic (using the weight of GetSigners() to pick the best signature)\nPeter the proposer monitors the global topic and finds the best merged signature\nHe verifies it with MergeVerify() and puts it on the block\nHe uses GetSigners() to assign rewards to participating validators\n\nAppendix B: Performance estimates on STARK recursion\nFor given security level \\lambda𝜆 let \\phi_{\\lambda}(m)𝜙𝜆(𝑚) denote the number of hash calls needed to verify a STARK for a program that computes m𝑚 calls to 64-bit hash function Rescue/Poseidon (they have similar witness size). Then the proof size equals 32\\phi_{\\lambda}(m)32𝜙𝜆(𝑚) bytes. A verification circuit for checking a single STARK proof then computes \\phi_{\\lambda}(m)𝜙𝜆(𝑚) hashes. In order to recurse N𝑁 STARKs and keep the verification circuit constant size, we need\n\nN\\phi_{\\lambda}(m) <m\n𝑁𝜙𝜆(𝑚)<𝑚\nFigure 7 from the Starkware specification suggests that \\phi_{100}(m)\\leq 150 \\log_2 m𝜙100(𝑚) ≤150log2⁡𝑚. Thus we need m𝑚 such that \\frac{m}{\\log_2 m}>150N𝑚log2⁡𝑚 >150𝑁. For N=2𝑁 =2 we can choose m=2^{12}𝑚 =212 and \\phi_{100}(m)\\approx 1500𝜙100(𝑚) ≈1500.\n\n Sticking to 8192 signatures per slot post-SSF: how and why\n\n Lattice-based signature aggregation\n\n WHIR for Ethereum\n\n Separator-Based Participation Commitments for Post-Quantum Attestation Aggregation\n\n Orbit SSF: solo-staking-friendly validator set management for SSF\n\n read \n\n 13\n min\n\n 11 days later\n\n post by mratsim on Nov 22, 2023\n\n mratsim\n\nWe say that a Signature Merge scheme is lightweight if the size of π is minimal: it only uses a single bit for each user of the PKI system. In this post we concern ourselves only with lightweight Signature Merge schemes.\n\nNit: This is called a implicit/succinct data structure in Computer Science: Succinct data structure - Wikipedia\n\nIn computer science, a succinct data structure is a data structure which uses an amount of space that is “close” to the information-theoretic lower bound, but (unlike other compressed representations) still allows for efficient query operations. The concept was originally introduced by Jacobson[1] to encode bit vectors, (unlabeled) trees, and planar graphs. Unlike general lossless data compression algorithms, succinct data structures retain the ability to use them in-place, without decompressing them first. A related notion is that of a compressed data structure, insofar as the size of the stored or encoded data similarly depends upon the specific content of the data itself.\nSuppose that ℤ is the information-theoretical optimal number of bits needed to store some data. A representation of this data is called:\n\nimplicit if it takes ℤ + O(1) bits of space,\nsuccinct if it takes ℤ + o(ℤ) bits of space, and\ncompact if it takes O(ℤ) bits of space.\n\nFor example, a data structure that uses 2ℤ bits of storage is compact, ℤ + √ℤ bits is succinct, ℤ + log(ℤ ) bits is also succinct, and ℤ+3 bits is implicit.\n\nNit: in Computer Science, this is called the set reconciliation problem. This repo GitHub - AljoschaMeyer/set-reconciliation: An informal description on how to compute set union between two computers. has a bunch of papers to get started with but they focus on networking and probabilistic/fuzzy approaches while we need exact reconciliation.\nInterestingly, the bitcoin folks have their own set reconciliation library: GitHub - sipa/minisketch: Minisketch: an optimized library for BCH-based set reconciliation\n\nApproach 1) Recursive STARKs\nApproach 2) Recursive Halo2 (atomic accumulation)\nApproach 3) Folding (split accumulation)\n\nA new paper from 2 days ago might be uniquely suited to solve this very efficiently:\n\nSuccinct Arguments over Towers of Binary Fields\nIrreducible / binius · GitLab\nhttps://www.ulvetanna.io/news/binius-hardware-optimized-snark\n\nWe see three main advantages to binary tower field SNARKs. First, this approach offers much lower memory usage and computational cost by maximizing the benefits of small fields. Binius is already 50x more efficient than the next-best system that we benchmarked, plonky2, at committing 1-bit elements, and there are plenty of optimizations to come. The second benefit is compatibility with standard hash functions. Binary tower field SNARKs can efficiently perform bitwise operations like XOR and logical shifts, which are heavily used throughout SHA-256, Keccak-256, and other symmetric cryptography primitives.\n\nThis would make set union / merging bitfields extremely cheap\nAbstract:\n\nWe introduce an efficient SNARK for towers of binary fields. Adapting Brakedown (CRYPTO '23), we construct a multilinear polynomial commitment scheme suitable for polynomials over tiny fields, including that with 2 elements. Our commitment scheme, unlike those of previous works, treats small-field polynomials with zero embedding overhead. We further introduce binary-field adaptations of HyperPlonk’s (EUROCRYPT '23) product and permutation checks, as well as of Lasso’s lookup. Our scheme’s binary PLONKish variant captures standard hash functions—like Keccak-256 and Grøstl—extremely efficiently. With recourse to thorough performance benchmarks, we argue that our scheme can efficiently generate precisely those Keccak-256-proofs which critically underlie modern efforts to scale Ethereum.\n\n 2 months later\n\n post by albert-garreta on Jan 10, 2024\n\n albert-garreta\n\nThe HyperNova paper provides a method for folding lookups (Section 7). However the paper itself claims that that scheme is not suitable for folding lookups related to bitwise operations. I am wondering is this the case? What are these “certain polynomial equations”?\n\n 4 months later\n\n post by DNALOB on May 10, 2024\n\n DNALOB\n\n thanks for writing this. i found it very helpful.\n\n Powered by Discourse","tokens":9324,"squid":"spider-04","role":"Research Spider","at":1791347071598,"hash":"b315c9fe03bad4d3992d513662540363d4b1ec0d"}
{"url":"https://docs.jup.ag/user-docs/earn/offerbook/chat","domain":"docs.jup.ag","title":"Chat - Jupiter Documentation","text":"Chat is a built-in messaging feature on Offerbook that lets users communicate with each other directly inside the app. It supports public channels (open discussions) and direct messages (DMs) addressed by username or Solana wallet address.\nChat is accessed from the floating green button in the bottom-right corner of the interface. Opening it reveals a small menu with Messages, Feedback, and Support; click Messages to enter Chat.\nYou can read public channels as a guest without connecting a wallet. Authentication is only required to send messages, start direct messages, change settings, or take any action tied to your identity.\nChat is independent from the rest of Offerbook. Authenticating to Chat requires a separate wallet signature, distinct from the wallet connection used to create or accept offers.\n\n​Connecting to Chat\nYou can browse public channels without signing in. To send messages, start direct messages, or change settings, you need to authenticate. The first time you take one of these actions, you are prompted to Connect to chat by approving a wallet signature. This signature only authenticates you with the chat service; no funds are moved.\nOnce signed, you are not asked again on the same device.\nSoftware wallets (Phantom, Solflare, etc.)\nClick the floating green button in the bottom-right corner, then choose Messages.\nClick Connect to chat.\nApprove the signature request in your wallet.\nYour messages then load. You can navigate between All, Direct, and Channels tabs at the bottom of the panel.Hardware wallets (Ledger and others)Hardware wallets cannot sign arbitrary messages. Chat sign-in for hardware wallets uses a memo transaction signature instead.To sign in:\nOpen Chat and turn on the Ledger toggle on the connect screen.\nClick Connect to chat. If you left the toggle off and the message signature fails, the app offers the transaction sign-in instead.\nApprove the memo transaction in your hardware wallet. The transaction is empty (no funds move) but requires a small SOL balance to pay the network fee.\nYou are not asked again on the same device after signing in.\n\n​Channels\nChannels are public discussion rooms open to all connected users.\nAt launch, Offerbook ships with a single channel: General (“General discussion for everyone”). Additional channels may be introduced over time.\nViewing a channelOpen Chat → click the Channels tab at the bottom of the panel → select General.The channel header shows the channel name and the current number of online users. Pinned messages appear at the top of the channel and can be expanded by clicking the chevron.Scroll down to read recent messages, and use the input at the bottom to send your own.Who can pin messages?Only Jupiter admins can pin messages in channels. Regular users cannot pin or unpin.Online indicatorThe “N online” indicator next to the channel name reflects the number of users currently connected to Chat (not the total number of Offerbook users).\n\n​Direct Messages\nDirect messages (DMs) are private one-to-one conversations between two users.\nStarting a conversation\nOpen Chat → click the Direct tab.\nClick + Start a conversation.\nEnter the recipient’s username (if they have set one) or their Solana wallet address.\nSend your first message.\nThe conversation appears in the All and Direct tabs for both participants.Who can DM whom?Any connected user can DM any other connected user, as long as you know their username or wallet address. There is no friend request or approval flow.\n\n​Sending an Offer in Chat\nYou can share one of your open offers directly in a chat message, both in channels and in DMs. The recipient sees a preview card and can open the full offer with one click.\n1Open the attachment menuFrom any chat (channel or DM), click the + button on the left of the message input.2Choose Send an offerSelect Send an offer (“Browse your open offers”). A list of your currently open offers is shown.If you have no open offers, the panel displays “You have no open offers.” Create or renew an offer first, then come back to share it.3Select an offerPick the offer you want to share. It is sent as a preview card in the conversation, showing the principal, collateral, APY, duration, and LTV.4Recipient interactionAnyone who can see the message can click the preview card. Clicking opens the full offer page on the right side of the interface, with all the offer details and the actions available to them (accept, send a counter offer, etc.).\nSharing an offer in chat does not change the offer’s visibility settings. The offer remains discoverable from the offerbook as usual, and the shared card is only a convenient shortcut to it.\n\n​Chat Settings\nClick the gear icon at the top of the chat panel to open Chat settings.\nThe available option is Display layout, which controls how messages are rendered:\nLayoutDescriptionBubblesMessages are shown as full chat bubbles. Best for short, conversational exchanges.CompactMessages are shown as compact rows. Best for high-volume channels.MixedBubbles for DMs, compact for channels. Recommended for most users.\nClick Done to save your choice. The setting applies across your sessions on the same device.\n\n​Reporting & Moderation\nChat includes a built-in moderation system to keep public channels usable.\nReporting a messageHover (or long-press on mobile) on any message and click the ⋯ menu, then Report message. A confirmation dialog opens:\nReport this message? A moderator will review it shortly. The sender is not told who reported them.\nClick Report to submit. The report is sent to the Jupiter moderation team. The sender does not know who reported their message.Anti-spamTo prevent flooding, Chat blocks sending the same message more than once within a short window. If you try to repost identical content, the message is rejected.This is enforced per user across all channels and DMs.What gets moderated?The moderation team reviews reports and takes action against messages that violate community guidelines: spam, scams, harassment, impersonation, and similar abuse. Actions can include message deletion or user restrictions, at the moderators’ discretion.\n\n​Use Cases\nChat is designed to support real interactions around lending and borrowing on Offerbook. A few common patterns:\nNegotiate terms before sending a counter offerBefore formally proposing different terms on an open offer, you can DM the offer creator to discuss what you have in mind (LTV, APR, duration). If you reach an agreement, send a counter offer with the negotiated terms, or wait for them to update their offer.This reduces back-and-forth on counter offers that would not be accepted anyway.Coordinate around an active loanDuring the life of a loan, the borrower and lender may need to communicate: confirming early repayment, asking about collateral specifics, or coordinating a renewal. DMs are a direct way to do this on-platform, without leaving the app.Promote your offer in the General channelLenders and borrowers can post in the General channel to bring attention to a specific offer (for example, “Looking for a 7-day lender on $X collateral at Y% APR”). Sharing the offer card in the message makes it actionable in one click.Get help with niche collateralFor unusual or hard-to-price collateral (illiquid tokens, RWAs, NFTs from smaller collections), the General channel is a place to ask lenders what terms they would consider before publishing the offer.","tokens":1852,"squid":"spider-02","role":"Liquidity Spider","at":1791347081203,"hash":"e704e0608025a3aeca74f8ebca7c6f2a2cf0469f"}
{"url":"https://ethresear.ch/t/properties-of-issuance-offsets-and-increased-penalties-under-low-zero-negative-issuance-policies/25292/2","domain":"ethresear.ch","title":"Properties of issuance offsets and increased penalties under low/zero/negative issuance policies - Proof-of-Stake / Economics - Ethereum Research","text":"Proof-of-StakeEconomics\n\n issuance-policy\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jun 24\n\n 2 / 2\n\n Aug 19\n\n Aug 19\n\n post by aelowsson on Jun 24\n\n aelowsson\n\n Properties of issuance offsets and increased penalties under low/zero/negative issuance policies\nEthereum is currently debating an issuance reduction. This is a technical post outlining how low-issuance policies could be facilitated. It does not propose a specific reward curve.\nSummary\nUnder low-issuance regimes implemented by bringing the base reward per increment toward zero, the incentive to perform attestation duties vanishes. Two solutions have been suggested to preserve this incentive: (1) to reduce issuance with an “issuance offset” (previously called “fee”) applied during epoch processing, or (2) to decrease rewards while at the same time increasing the penalties for each duty. The issuance-offset approach benefits from spec simplicity and preserves the power dynamics between different validator roles. Known penalty regimes inherit concerns regarding minority discouragement attacks, because the power dynamics can change when penalties are increased.\nThis post outlines how increased penalties could be enacted while preserving the power dynamics between roles, such that the opportunities for minority discouragement attacks do not increase. It then outlines how that penalty design can be converted into an equivalent per-duty issuance-offset design to afford spec simplicity, by altering the offset based on assigned duties.\nThere are thus ultimately two different issuance-offset designs, with important differences most easily compared at zero issuance. Under a uniform per-increment deduction applied to all active validators, a solo staker that performs all regular attestation duties but has no special-duty assignment during the epoch has a negative balance change. Under a per-duty deduction, the same solo staker does not have a negative balance change—assuming full aggregate attestation participation, since rewards scale with the participating balance. However, a missed proposal leaves the proposer-specific offset in place, creating a more substantial loss.\nThe post concludes by outlining a permissive flat-offset regime under low positive issuance, where solo stakers can break even or earn a small positive reward in ordinary epochs without incurring a proposer-specific deduction for missed proposals. Such a regime can also keep rewards positive when aggregate attestation participation is below 100%, providing a buffer against the resulting reduction in rewards.\nIntroduction\nEthereum issues ETH to staked validators that participate in consensus formation as an incentive for correctly performing their duties. The yield from these rewards consequently produces the incentive to participate in consensus formation. There are thus two properties at play: the incentive to perform duties at the micro level, and the incentive to stake at the macro level. At higher issuance levels, this distinction is less relevant, because the incentive to perform duties is not compromised.\nHowever, consider the case of a low-issuance regime at higher stake-participation levels, enacted to preserve a trustless ETH asset and moderate the costs that ETH holders are induced to incur by staking. If validators receive substantial MEV, they may wish to stake even if the issuance yield is very low, because the MEV yield is still sufficient. As previously observed, Ethereum would then need to bring the base reward per increment, and thus issuance yield, so low that the micro rewards handed out become insignificant relative to MEV. The only thing that matters to validators would then be to capture MEV, whereas the rewards for attestation duties would become negligible, and so would the incentive to properly attest.\nTo resolve this, the rewards and penalties guiding the incentive to attest cannot be brought down too low. Two options are available: (A) reduce issuance with an issuance offset applied each epoch (as suggested, e.g., here 1, 2, 3), or (B) decrease rewards while increasing the penalties for each duty.\nFlat issuance-offset regime\nWe begin by analyzing the flat issuance-offset regime, due to its simplicity. An example is illustrated in Figure 1, and the same principles also apply to a zero or negative issuance regime. The micro incentive for performing validator duties is illustrated in red. It is computed using the existing get_base_reward_per_increment() function, with some potential adjustments to its slope. In addition, a new function get_macro_incentive_per_increment() calculates the incentive to stake, illustrated in blue. We do not specify the exact curve equations applied here, since these are not the focus of the post. The issuance offset between the two curves is then deducted during epoch processing:\nissuance_offset_per_increment = get_issuance_offset_per_increment(state)\nfor index in get_active_validator_indices(state, get_current_epoch(state)):\n decrease_balance(state, index, state.validators[index].effective_balance // EFFECTIVE_BALANCE_INCREMENT * issuance_offset_per_increment)\n\nWithout the deduction, issuance under perfect participation is according to the upper red curve. With the deduction, issuance is according to the lower blue curve. The key property is that the offset does not alter the relative rewards and penalties inside the consensus mechanism. If a validator compares two actions, the same offset is applied either way, and thus cancels from the comparison.\nFigure 12563×1627 202 KB\nFigure 1. The micro incentive for performing validator duties in red, and the macro incentive to stake in blue. An issuance offset between the two curves is deducted during epoch processing. The intended outcome is that stakers have an incentive to always perform their duties accurately, while the incentive to stake is moderated more strongly than what the red curve would allow in isolation.\nPenalty regime\nIn the issuance-offset regime, the balance between attester and proposer remains the same. It is desirable to carry the general principles of that regime over to the penalty regime, as opposed to arbitrarily increasing penalties as issuance falls. This is to protect against minority discouragement attacks, as further discussed in the Appendix. If the proposer and attesters have a particular relative reward/penalty distribution on a specific attestation type under a higher issuance regime, then that relative distribution should be maintained in a lower regime. Such an invariant lends itself to straightforward analysis.\nThis can be achieved by modifying the reward-and-penalty structure linearly, guided by the incentive differential. Consider a duty that currently gives reward r𝑟 when performed successfully and penalty p𝑝 when failed. The current payoff is r𝑟 upon success and -p−𝑝 upon failure. A zero-issuance penalty regime instead sets the successful outcome to 0 and the failed outcome to -(p+r)−(𝑝 +𝑟). This preserves the spread between success and failure. A duty with reward 8 and penalty 0 becomes reward 0 and penalty 8. A duty with reward 14 and penalty 14 becomes reward 0 and penalty 28. In both cases, the marginal incentive to perform the duty is unchanged. The micro incentive is preserved because the difference between success and failure is the same.\nNext consider the intermediate points where the desired issuance-based macro incentive lies above zero. Let D𝐷 denote the relevant staking level, let m(D)>0𝑚(𝐷) >0 denote the micro-incentive level per effective-balance increment and let y(D)𝑦(𝐷) denote the desired issuance-based macro incentive per increment, measured in the same units. The fraction of each reward to convert is then\n\nq(D)=\\frac{m(D)-y(D)}{m(D)}.\n𝑞(𝐷)=𝑚(𝐷)−𝑦(𝐷)𝑚(𝐷).\nA duty with reward r𝑟 and penalty p𝑝 is then changed from success payoff r𝑟 and failure payoff -p−𝑝 to success payoff (1-q)r(1 −𝑞)𝑟 and failure payoff -(p+qr)−(𝑝 +𝑞𝑟). The spread is still r+p𝑟 +𝑝. For example, a duty with reward 14 and penalty 14 moves smoothly from (14,-14)(14, −14) to (13,-15)(13, −15), then to (12,-16)(12, −16), and so on, until it reaches (0,-28)(0, −28) at zero issuance. In a negative-issuance regime, q>1𝑞 >1, so even the successful outcome becomes negative. At that point, the same logic still applies, but the design is better understood as an offset or duty debit beyond the full conversion of rewards into penalties.\nProposer rewards need special handling. Ideally, they are not converted into a penalty. The reason for this is subtle: if there is no reward for including an attestation, the proposer may ignore missed attestations from previous slots; if a penalty is also assigned for missing these attestations, then any missed attestation may penalize several proposers in a row.\nRetained proposer rewards can be made consistent with reduced issuance by assigning an offset of qr𝑞𝑟 to the validator assigned the canonical proposal opportunity for each proposer credit r𝑟. If the assigned proposer earns the credit, its net payoff is (1-q)r(1 −𝑞)𝑟. Full cancellation occurs at q=1𝑞 =1 corresponding to a zero macro incentive per increment and zero issuance level at perfect participation. If a later proposer instead earns the credit by including a missed attestation, the original proposer retains the offset while the later proposer receives the reward. Across the two proposers, the aggregate payoff is still (1-q)r(1 −𝑞)𝑟, ensuring that issuance does not increase.\nThus, we approach the proposer penalty as an offset in its implementation, in order to allow correct accounting and incentives to carry over across several slots.\nEquivalent penalty and per-duty issuance-offset regimes\nThe difference between the penalty regime and the flat issuance-offset regime lies in reward variance and potential spec complexity. In the penalty regime, a perfectly performing validator earns according to the specified macro incentive at each duty opportunity. In the flat issuance-offset regime, it earns slightly less during ordinary slots, and then recoups the difference when performing special duties such as proposing. This also means that in the penalty regime, a missed proposal leads to a one-time loss equal to all below-par earnings of the issuance-offset regime between proposals. In the flat issuance-offset regime, a missed proposal is merely an opportunity cost, and no additional proposal-specific ETH is deducted.\nCan we find perfect equivalence such that this type of penalty regime is implemented strictly as an issuance offset? It turns out that this is rather straightforward. When deducting the staking offset from each validator, we can account for the duties assigned during the epoch. The main function would then perform the following:\ndef process_issuance_offsets(state: BeaconState) -> None:\n epoch = get_current_epoch(state)\n attestation_issuance_offset_per_increment = get_attestation_issuance_offset_per_increment(state)\n prop_issuance_offset = get_proposer_issuance_offset(state, epoch)\n sync_issuance_offset = get_sync_committee_issuance_offset(state, epoch)\n\n for index in get_active_validator_indices(state, epoch):\n num_prop_assignments = get_num_proposer_assignments(state, index, epoch)\n num_sync_assignments = get_sync_committee_assignment_count(state, index, epoch)\n\n offset = state.validators[index].effective_balance // EFFECTIVE_BALANCE_INCREMENT * attestation_issuance_offset_per_increment\n if num_prop_assignments > 0:\n offset += num_prop_assignments * prop_issuance_offset\n if num_sync_assignments > 0:\n offset += num_sync_assignments * sync_issuance_offset\n decrease_balance(state, index, offset)\n\nThe issuance offset is thus allocated based on role assignment. An attestation component is applied to all active validators, while proposer and sync-committee components are applied to the validators assigned those duties. A successful proposer receives the normal proposer rewards, but also has the corresponding proposer offset applied. For each canonical credit r𝑟, earning the credit produces a net payoff of (1-q)r(1 −𝑞)𝑟. Thus, when q=1𝑞 =1, at a zero macro incentive/issuance level, a proposer performing the duty successfully sees rewards and offset fully cancel. If the proposer misses it, the offset remains and the reward is absent.\nThis also handles stray attestations naturally. A proposer that includes an attestation from a previous slot still receives the proposer reward. The corresponding offset was applied to the validator assigned the canonical proposal opportunity. If the original proposer earned the credit, its reward is reduced to (1-q)r(1 −𝑞)𝑟 by the offset. If it missed the credit, it takes the debit -qr−𝑞𝑟, while the later proposer receives r𝑟; the aggregate payoff remains (1-q)r(1 −𝑞)𝑟.\nThe resulting design can be read in two ways. It is an issuance-offset regime, because the existing reward and penalty logic is left intact and offsets are deducted during epoch processing. It is also penalty-equivalent, because the offset is applied at the duty opportunity, so a missed duty leaves the validator with the same downside as in the corresponding increased-penalty regime.\nA permissive flat issuance-offset regime under low issuance\nIn the current Ethereum spec, micro incentives have been designed such that the proposer does not incur penalties for missed slots. This preserves the property of a bounded downside risk of staking for the individual validator in the case that it is spuriously offline for some time. This has been promoted as a beneficial feature to the solo staker who may not have the resources to constantly monitor their setup. At the same time, it would seem preferable to also ensure that a solo staker performing its duties perfectly does not take on a loss each epoch just to break even during proposals. How can these two properties be upheld at the same time while also bringing down issuance to a very low level?\nOne way is to apply the flat issuance-offset regime while upholding a ratio between the base-reward curve and the macro-incentives curve that ensures the solo staker does not take a loss each regular epoch. With the current micro incentives, the regular attestation component is 54/6454/64 of the base-reward scale. If the macro-incentives curve is 10/6410/64 of the base-reward curve, then the common offset fraction is q = 54/64𝑞 =54/64 and equals the attestation rewards handed out for performed duties. The numerator 8+2=108 +2 =10 derives from the proposer-reward weight (8) and the sync-committee weight (2).\nAt the high-D𝐷, low-issuance end of Figure 1, the macro-incentive curve approaches this 10/6410/64 ratio. Under such conditions, the outcome is that the solo staker breaks even during an epoch with perfect attestation and no special duties, while at the same time not being subjected to the greater downside risks of missed proposals. If the macro incentive fraction is set greater than 10/6410/64, the solo staker will have a small positive reward each epoch during perfect attestation under full aggregate participation. Ratios such as 16/64 = 1/416/64 =1/4 could thus be used to provide positive regular rewards to solo stakers under those conditions and a small buffer against occasional missed duties over time as well as reduced aggregate participation.\n\nAppendix – Minority discouragement attacks\nIn the issuance-offset regime, the balance between attester and proposer remains the same. Rewards and penalties for performing staking duties generally need to be balanced to protect against minority discouragement attacks. For example, if there is no incentive for a proposer to include an attestation in the beacon block, whereas the attester takes a loss if it is not included, the proposer can grief the attester by leaving it out. This would allow the griefing validator to earn a higher yield than validators that dutifully include all observed attestations. For this reason, the proposer earns rewards for all attestations included.\nThere are various known minority discouragement attacks against the present consensus mechanism. For example, the proposer may selectively censor sync-committee attestations, an attack with a “griefing factor” of G=14𝐺 =14. For every ETH that the attacker loses out on, the censored validators will lose out on 14 ETH. This happens because the attester loses out on 7 times as much ETH as the proposer when the attestation is not included, and additionally takes a penalty 7 times higher than the ETH lost by the proposer. It turns out that the attacker can then hold a rather small minority of the stake, though not an insignificant one, while still profiting from the attack. The relatively higher yield of the attacking staking service provider (SSP) may lead delegators to prefer it, and as some censored validators leave, the equilibrium yield will rise under sustained censorship. As this example illustrates, balancing micro rewards is a nuanced subject.\nAnother example of a minority discouragement attack consists of attesters withholding attestations during an inactivity leak to deny the proposer rewards for timely head attestations. In the current consensus mechanism, attesters do not receive rewards during the inactivity leak, and need only ensure that the attestation is included within 2–5 slots to avoid penalties on the source vote. The griefing factor then becomes infinite. Moreover, if the attester is assigned as proposer within 2–5 slots, it can pick up rewards for the attestation itself and will thus directly profit from the attack.\nThis discussion highlights how a consensus mechanism can unravel when rewards and penalties are altered without consideration for minority discouragement attacks. For this reason, it seems preferable to retain the same micro-incentive balance, in the current and any future consensus design, across the full staking range. If the proposer and attesters have a particular relative reward/penalty distribution on a specific attestation type under a higher issuance regime, then that relative distribution is maintained in a lower regime. If instead a lower issuance is ensured by reducing rewards toward zero whereas penalties are increased, the balance between roles is more difficult to maintain. In the case that missed proposals do not incur an offset, any attempt to reduce issuance by rebalancing the reward/penalty distribution would be particularly hazardous, because it upends the power balance between the proposer and attester.\n\n read \n\n 7\n min\n\n 2 months later\n\n post by knoshua on Aug 19\n\n knoshua\n\n Thanks for the detailed write‑up!\nI’m trying to sanity-check my understanding of how EIP-8363 (which seems to implement essentially the penalty regime you proposed here) impacts opportunities for minority discouragement attacks, which you do touch on here as well.\nMy reading of your post is that by implementing such a penalty regime, we preserve the relative rewards and penalties inside the consensus mechanism, which means that the griefing factor of a discouragement attack is not changed. And of course that’s preferable to increasing the griefing factor and in that sense, opportunities for discouragement attacks aren’t increased.\nBut isn’t it true that the griefing factor is only one relevant aspect that an issuance change can affect? In your Reward curve with tempered issuance post, you mentioned a profitability condition for small epsilon attacks that also depends on “p-elasticity”. It’s my understanding that with the EIP-8363 curve, p-elasticity tends to infinity as stake ratio approaches 50%. Doesn’t this mean that even with griefing factors unchanged, discouragement attacks that today are not profitable would cross the profitability threshold at some point below 50% stake ratio?\nIn your view, should we explicitly evaluate EIP‑8363’s issuance curve against the p‑elasticity criteria? In other words: is it reasonable to say EIP‑8363 adopts your offset regime to avoid worsening griefing factors, but may still need additional constraints or safeguards if its net p-elasticity at high stake ratios makes epsilon discouragement attacks materially easier? Any pointers on how you would frame that distinction, or on specific attack modes where you think the macro side becomes more problematic even when micro incentives are preserved, would be very helpful.\n\n Powered by Discourse","tokens":5106,"squid":"spider-04","role":"Research Spider","at":1791347084287,"hash":"91a9dbc3e19d4b3d9503c7c3652d444ccd4ea564"}
{"url":"https://docs.jup.ag/user-docs/earn/offerbook/lending","domain":"docs.jup.ag","title":"Lending - Jupiter Documentation","text":"Lending on Offerbook means supplying USD Coin (USDC) at a fixed rate for a fixed duration, secured by the borrower’s collateral held in escrow. There are no price-based liquidations: if the borrower repays, you receive your principal + interest; if they do not, you claim the collateral.\nYou can lend against tokens or collectibles; what each market accepts is covered in Markets.\nThe collateral is your only recourse. If its value drops below the borrowed amount during the loan, the borrower can rationally choose not to repay, and you receive an asset worth less than the USDC you lent. This trade-off is inherent to time-based lending: only lend against collateral you would accept holding, at an LTV (Loan-to-Value, the ratio between borrowed USDC and collateral value) that prices this risk. See Security & Risks.\n​How to start lending\nEverything starts from the Earn menu in the header, which opens the Tokens or Collectibles market view (see Markets). The Tokens view has two tabs: Available Now, the borrow offers you can fund today, and Set Your Terms, the terms borrowers have asked for and nobody has filled yet, each with Create offer to post a matching lend offer. Pick the collateral you want to lend against, then take one of three paths:\n\nFill an open borrow offer at the terms set by the borrower\nCreate your own lend offer with the Offer to Lend button (or Create Offer > Lend in the header), and wait for a borrower to fill it\nSend a counter offer on an open borrow offer whose terms are close but not quite right. See Counter Offers\n\nYou can also advertise the terms you want through an intent, which is free, off-chain and locks nothing, or browse every offer and intent on one screen in the Pro view. Lending against the assets used in yield loops has its own entry point on the Multiply pages, with the same offer mechanics.\n​Your escrow wallet\nAll funds transit through a dedicated escrow wallet, separate from your main Solana wallet. As a lender, the escrow is visible in the interface next to your main wallet balance, and it is central to how your offers work:\n\nUSDC is deposited into the escrow as part of offer creation. Lend offers must be covered by the escrow balance to be visible to other users. See Settings & Notifications\nYou can create multiple lend offers from the same USDC balance, all visible at the same time. When one offer is accepted, the USDC leaves the escrow, and any remaining offers no longer covered by the balance are hidden automatically\nWhen a borrower repays, the USDC (principal + interest, minus fees) returns to your escrow, where it can be reused for new offers without withdrawing first\nYou can deposit and withdraw at any time. If a withdrawal leaves active offers uncovered, those offers are hidden automatically\n\nRepaid loans do not land in your main wallet. If USDC seems missing after a loan closes, check your escrow balance, shown next to your main wallet balance, and withdraw from the escrow to move it to your wallet.\nThe Escrow tab of your Dashboard is the ledger of this wallet: the balance in escrow now, what you have deposited and withdrawn in total, the net USD in and out, and every movement (repayment received, loan funded, deposit, withdrawal) with its USD value and the balance after it. Filters narrow it to Deposits, Withdrawals, Funded by you or Withdrawn by you.\nThe first deposit of a given asset funds an escrow account (0.00203928 SOL of rent, refunded when you withdraw the asset). See Fees and Costs.\nThe escrow supports NFT deposits and withdrawals alongside fungible tokens. This is mainly relevant when working with NFT-collateralized loans or when retrieving NFTs after a loan has settled.\n​Filling a borrow offer\nWhen you accept a borrow offer, the loan starts immediately and the loan duration begins. USDC is transferred to your escrow automatically if needed, then to the borrower, and the collateral is locked onchain. If the offer allows partial fill, you can accept any amount at or above its Minimum Fill Amount, which borrow offers also display in collateral terms; otherwise the offer must be filled in full.\nAt this stage, you can add the loan’s maturity date to your calendar using the calendar button provided in the interface. Calendar reminders fire 2 hours before maturity.\n​Creating a lend offer\nThe Offer to Lend button, Create Offer > Lend in the header, and the Dashboard’s Offers tab (with the Lending side selected) all open the same step-by-step creation flow.\n1Choose your conditionsDefine the core parameters of the offer:\nAsset to lend: USDC (fixed), and the amount, at least $10 per loan\nCollateral you accept: verified tokens on Jupiter, real-world assets (RWAs) such as xStocks, or non-fungible tokens (NFTs) from whitelisted collections\nLTV (Loan-to-Value): adjust via slider. For NFT collateral, the slider uses the collection floor price as the reference value\nAPY (Annual Percentage Yield): set the rate you ask. As you adjust the LTV and APY sliders, an indicator estimates how attractive the terms are to borrowers (for example, “Great chance to fill, cheap for borrowers”)\nOffers using NFT collateral are per-item: each offer targets one specific NFT, shown as its own card in the Collectibles market. The exception is PFP collections with a floor price: lend offers on these can be collection offers, where any qualifying NFT from the collection can be pledged as collateral.2Set duration and expiration\nLoan duration: 1 to 30 days (presets: 3D, 7D, 30D)\nOffer expiration: 1 to 7 days, set by you. This is separate from the loan duration: the loan countdown only starts when the offer is accepted\nPast 1 day, your terms stay fillable even if the collateral price or market rates move against you. Keep the expiration short unless you are confident the terms will still be worth it later, and remember that expired offers can be renewed in one click.3Set fill preferences\nAllow partial fill: when enabled, your offer can be accepted partially, and you set a Minimum Fill Amount in USD\nAllow extensions: when enabled, borrowers can roll loans from this offer into fresh periods on the same terms, paying you each period’s interest as it closes. You can revoke or re-grant it per loan after a fill. See Loan Extensions\nPartial fill is not available for offers using NFT collateral, since an NFT cannot be partially transferred\n4Review and publishThe offer summary recaps your terms (amounts, APY, LTV, duration, expiration, partial fill minimum) and displays the Effective APY: the offer APY minus the 10% platform fee on interest deducted at repayment (an offer at 16% APY shows 14.4%). As the summary states, your USDC stays in your escrow balance until the offer is filled, and you can create multiple offers with the same balance.Your escrow must hold the offered USDC for the offer to be visible: the app deposits it from your wallet into your escrow automatically when the offer is created.\nPublished offers cannot be edited. You can cancel an offer at any time before it is accepted, at no fee. Once an offer expires, you can renew it directly from Dashboard > Offers, with the option to adjust the LTV, instead of recreating it from scratch.\nCounterparties can also send counter offers on your offer, proposing a different LTV, rate (APY), duration or amount. They appear beneath your offer in Dashboard, an activity dot shows on the Dashboard link, and you can accept one (the loan starts immediately at the counter terms) or ignore them.\n​Earnings & Costs\nInterest accrues at the agreed rate, fixed for the whole loan duration.\nYou earnThe offer APY, locked for the full duration. The borrower pays the\ninterest on top of the principal at repayment.You pay10% of the interest, deducted at repayment, plus network fees and\naccount rent on the onchain transactions. Rent is a deposit, not a\nfee: part of it returns when the related accounts close.\nThe interface shows the Effective APY, which already accounts for the\nfee: an offer at 5% APY yields a 4.5% Effective APY. The full schedule is\nin Fees and Costs.\n​Your Dashboard\nEverything you do as a lender lives under Dashboard, with the Lending side selected:\n\nPositions — the loans you funded, with your principal lent, interest, average APY, realized PnL and the collateral you can claim at the top. Each loan follows the statuses Active, Repaid, Expired and Defaulted.\nOffers — your open lend offers, the terms you are showing borrowers. Cancel them before they are filled, or renew them once expired.\nEscrow and Analytics — the escrow ledger described above, and your lending performance compared with the market.\n\nSelect several offers or loans to act on them together: cancel or renew them in fewer wallet prompts, with the result shown row by row.\n​How Your Loan Ends\nA loan has two possible outcomes, and only one of them asks anything of you. Both are handled from Dashboard > Positions, using the action button on the right of the loan’s row.\nThe borrower repaysNothing to do. The loan closes, and the USDC (principal + interest,\nminus the 10% fee) lands back in your escrow, ready to be reused for\nnew offers.The borrower walks awayAfter maturity, claim the collateral by signing a transaction — the\ntransfer is not automatic. The collateral is sent to your wallet as-is,\nnever sold on the market, and the loan is marked Defaulted. A 0.1% fee\nis deducted at transfer (none on NFT collateral).\nUntil you claim, the loan stays open and the borrower can still repay.\nClaiming is the action that settles the outcome — do not leave it\npending.\n​Example\nThe same loan, seen from the lender’s side. A borrower posts a borrow offer — 8,000 USDC against ~$10,000 of collateral, 3 days, 35% APR — and you accept it.\nParameterValueYou lend8,000 USDCCollateral locked~$10,000 onchain assetLoan duration3 daysInterest over the term~$23\n\nIf the borrower repays: you get your 8,000 USDC back plus the interest, minus the 10% repayment fee — about $20.70 net. The USDC lands in your escrow, ready to reuse.\nIf the borrower does not repay: after maturity you claim the collateral from Dashboard > Positions. A 0.1% fee is deducted (none on NFT collateral), and you receive the asset itself, to hold or sell.\n\nSee Fees and Costs for the full schedule.\n​Mistakes to avoid\nWaiting too long after maturityThe collateral is not transferred automatically. If the borrower does not repay and you do not claim, the loan stays open and the borrower can still repay later. To recover the collateral after maturity, you must sign a claim transaction.Using volatile collateral with long durationsCollateral value is not monitored during the loan. Using highly volatile assets as collateral over long durations increases uncertainty around the collateral’s value at maturity. Collateral characteristics and loan duration should always be considered together.Setting an unrealistic APYAPY is what balances an offer relative to its collateral, LTV, and duration. Offers with rates significantly out of line with current market conditions may remain unmatched. When defining an APY, think about how all parameters work together rather than focusing on a single value.","tokens":2784,"squid":"spider-02","role":"Liquidity Spider","at":1791347091300,"hash":"5db4c7cfca6ab0f313c85a7c7c401800a6dddd8a"}
{"url":"https://ethresear.ch/t/properties-of-issuance-offsets-and-increased-penalties-under-low-zero-negative-issuance-policies/25292/1","domain":"ethresear.ch","title":"Properties of issuance offsets and increased penalties under low/zero/negative issuance policies - Proof-of-Stake / Economics - Ethereum Research","text":"Properties of issuance offsets and increased penalties under low/zero/negative issuance policies \n\n Proof-of-StakeEconomics\n\n issuance-policy\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jun 24\n\n 1 / 2\n\n Jun 23\n\n Aug 19\n\n post by aelowsson on Jun 24\n\n aelowsson\n\n Properties of issuance offsets and increased penalties under low/zero/negative issuance policies\nEthereum is currently debating an issuance reduction. This is a technical post outlining how low-issuance policies could be facilitated. It does not propose a specific reward curve.\nSummary\nUnder low-issuance regimes implemented by bringing the base reward per increment toward zero, the incentive to perform attestation duties vanishes. Two solutions have been suggested to preserve this incentive: (1) to reduce issuance with an “issuance offset” (previously called “fee”) applied during epoch processing, or (2) to decrease rewards while at the same time increasing the penalties for each duty. The issuance-offset approach benefits from spec simplicity and preserves the power dynamics between different validator roles. Known penalty regimes inherit concerns regarding minority discouragement attacks, because the power dynamics can change when penalties are increased.\nThis post outlines how increased penalties could be enacted while preserving the power dynamics between roles, such that the opportunities for minority discouragement attacks do not increase. It then outlines how that penalty design can be converted into an equivalent per-duty issuance-offset design to afford spec simplicity, by altering the offset based on assigned duties.\nThere are thus ultimately two different issuance-offset designs, with important differences most easily compared at zero issuance. Under a uniform per-increment deduction applied to all active validators, a solo staker that performs all regular attestation duties but has no special-duty assignment during the epoch has a negative balance change. Under a per-duty deduction, the same solo staker does not have a negative balance change—assuming full aggregate attestation participation, since rewards scale with the participating balance. However, a missed proposal leaves the proposer-specific offset in place, creating a more substantial loss.\nThe post concludes by outlining a permissive flat-offset regime under low positive issuance, where solo stakers can break even or earn a small positive reward in ordinary epochs without incurring a proposer-specific deduction for missed proposals. Such a regime can also keep rewards positive when aggregate attestation participation is below 100%, providing a buffer against the resulting reduction in rewards.\nIntroduction\nEthereum issues ETH to staked validators that participate in consensus formation as an incentive for correctly performing their duties. The yield from these rewards consequently produces the incentive to participate in consensus formation. There are thus two properties at play: the incentive to perform duties at the micro level, and the incentive to stake at the macro level. At higher issuance levels, this distinction is less relevant, because the incentive to perform duties is not compromised.\nHowever, consider the case of a low-issuance regime at higher stake-participation levels, enacted to preserve a trustless ETH asset and moderate the costs that ETH holders are induced to incur by staking. If validators receive substantial MEV, they may wish to stake even if the issuance yield is very low, because the MEV yield is still sufficient. As previously observed, Ethereum would then need to bring the base reward per increment, and thus issuance yield, so low that the micro rewards handed out become insignificant relative to MEV. The only thing that matters to validators would then be to capture MEV, whereas the rewards for attestation duties would become negligible, and so would the incentive to properly attest.\nTo resolve this, the rewards and penalties guiding the incentive to attest cannot be brought down too low. Two options are available: (A) reduce issuance with an issuance offset applied each epoch (as suggested, e.g., here 1, 2, 3), or (B) decrease rewards while increasing the penalties for each duty.\nFlat issuance-offset regime\nWe begin by analyzing the flat issuance-offset regime, due to its simplicity. An example is illustrated in Figure 1, and the same principles also apply to a zero or negative issuance regime. The micro incentive for performing validator duties is illustrated in red. It is computed using the existing get_base_reward_per_increment() function, with some potential adjustments to its slope. In addition, a new function get_macro_incentive_per_increment() calculates the incentive to stake, illustrated in blue. We do not specify the exact curve equations applied here, since these are not the focus of the post. The issuance offset between the two curves is then deducted during epoch processing:\nissuance_offset_per_increment = get_issuance_offset_per_increment(state)\nfor index in get_active_validator_indices(state, get_current_epoch(state)):\n decrease_balance(state, index, state.validators[index].effective_balance // EFFECTIVE_BALANCE_INCREMENT * issuance_offset_per_increment)\n\nWithout the deduction, issuance under perfect participation is according to the upper red curve. With the deduction, issuance is according to the lower blue curve. The key property is that the offset does not alter the relative rewards and penalties inside the consensus mechanism. If a validator compares two actions, the same offset is applied either way, and thus cancels from the comparison.\nFigure 12563×1627 202 KB\nFigure 1. The micro incentive for performing validator duties in red, and the macro incentive to stake in blue. An issuance offset between the two curves is deducted during epoch processing. The intended outcome is that stakers have an incentive to always perform their duties accurately, while the incentive to stake is moderated more strongly than what the red curve would allow in isolation.\nPenalty regime\nIn the issuance-offset regime, the balance between attester and proposer remains the same. It is desirable to carry the general principles of that regime over to the penalty regime, as opposed to arbitrarily increasing penalties as issuance falls. This is to protect against minority discouragement attacks, as further discussed in the Appendix. If the proposer and attesters have a particular relative reward/penalty distribution on a specific attestation type under a higher issuance regime, then that relative distribution should be maintained in a lower regime. Such an invariant lends itself to straightforward analysis.\nThis can be achieved by modifying the reward-and-penalty structure linearly, guided by the incentive differential. Consider a duty that currently gives reward r𝑟 when performed successfully and penalty p𝑝 when failed. The current payoff is r𝑟 upon success and -p−𝑝 upon failure. A zero-issuance penalty regime instead sets the successful outcome to 0 and the failed outcome to -(p+r)−(𝑝 +𝑟). This preserves the spread between success and failure. A duty with reward 8 and penalty 0 becomes reward 0 and penalty 8. A duty with reward 14 and penalty 14 becomes reward 0 and penalty 28. In both cases, the marginal incentive to perform the duty is unchanged. The micro incentive is preserved because the difference between success and failure is the same.\nNext consider the intermediate points where the desired issuance-based macro incentive lies above zero. Let D𝐷 denote the relevant staking level, let m(D)>0𝑚(𝐷) >0 denote the micro-incentive level per effective-balance increment and let y(D)𝑦(𝐷) denote the desired issuance-based macro incentive per increment, measured in the same units. The fraction of each reward to convert is then\n\nq(D)=\\frac{m(D)-y(D)}{m(D)}.\n𝑞(𝐷)=𝑚(𝐷)−𝑦(𝐷)𝑚(𝐷).\nA duty with reward r𝑟 and penalty p𝑝 is then changed from success payoff r𝑟 and failure payoff -p−𝑝 to success payoff (1-q)r(1 −𝑞)𝑟 and failure payoff -(p+qr)−(𝑝 +𝑞𝑟). The spread is still r+p𝑟 +𝑝. For example, a duty with reward 14 and penalty 14 moves smoothly from (14,-14)(14, −14) to (13,-15)(13, −15), then to (12,-16)(12, −16), and so on, until it reaches (0,-28)(0, −28) at zero issuance. In a negative-issuance regime, q>1𝑞 >1, so even the successful outcome becomes negative. At that point, the same logic still applies, but the design is better understood as an offset or duty debit beyond the full conversion of rewards into penalties.\nProposer rewards need special handling. Ideally, they are not converted into a penalty. The reason for this is subtle: if there is no reward for including an attestation, the proposer may ignore missed attestations from previous slots; if a penalty is also assigned for missing these attestations, then any missed attestation may penalize several proposers in a row.\nRetained proposer rewards can be made consistent with reduced issuance by assigning an offset of qr𝑞𝑟 to the validator assigned the canonical proposal opportunity for each proposer credit r𝑟. If the assigned proposer earns the credit, its net payoff is (1-q)r(1 −𝑞)𝑟. Full cancellation occurs at q=1𝑞 =1 corresponding to a zero macro incentive per increment and zero issuance level at perfect participation. If a later proposer instead earns the credit by including a missed attestation, the original proposer retains the offset while the later proposer receives the reward. Across the two proposers, the aggregate payoff is still (1-q)r(1 −𝑞)𝑟, ensuring that issuance does not increase.\nThus, we approach the proposer penalty as an offset in its implementation, in order to allow correct accounting and incentives to carry over across several slots.\nEquivalent penalty and per-duty issuance-offset regimes\nThe difference between the penalty regime and the flat issuance-offset regime lies in reward variance and potential spec complexity. In the penalty regime, a perfectly performing validator earns according to the specified macro incentive at each duty opportunity. In the flat issuance-offset regime, it earns slightly less during ordinary slots, and then recoups the difference when performing special duties such as proposing. This also means that in the penalty regime, a missed proposal leads to a one-time loss equal to all below-par earnings of the issuance-offset regime between proposals. In the flat issuance-offset regime, a missed proposal is merely an opportunity cost, and no additional proposal-specific ETH is deducted.\nCan we find perfect equivalence such that this type of penalty regime is implemented strictly as an issuance offset? It turns out that this is rather straightforward. When deducting the staking offset from each validator, we can account for the duties assigned during the epoch. The main function would then perform the following:\ndef process_issuance_offsets(state: BeaconState) -> None:\n epoch = get_current_epoch(state)\n attestation_issuance_offset_per_increment = get_attestation_issuance_offset_per_increment(state)\n prop_issuance_offset = get_proposer_issuance_offset(state, epoch)\n sync_issuance_offset = get_sync_committee_issuance_offset(state, epoch)\n\n for index in get_active_validator_indices(state, epoch):\n num_prop_assignments = get_num_proposer_assignments(state, index, epoch)\n num_sync_assignments = get_sync_committee_assignment_count(state, index, epoch)\n\n offset = state.validators[index].effective_balance // EFFECTIVE_BALANCE_INCREMENT * attestation_issuance_offset_per_increment\n if num_prop_assignments > 0:\n offset += num_prop_assignments * prop_issuance_offset\n if num_sync_assignments > 0:\n offset += num_sync_assignments * sync_issuance_offset\n decrease_balance(state, index, offset)\n\nThe issuance offset is thus allocated based on role assignment. An attestation component is applied to all active validators, while proposer and sync-committee components are applied to the validators assigned those duties. A successful proposer receives the normal proposer rewards, but also has the corresponding proposer offset applied. For each canonical credit r𝑟, earning the credit produces a net payoff of (1-q)r(1 −𝑞)𝑟. Thus, when q=1𝑞 =1, at a zero macro incentive/issuance level, a proposer performing the duty successfully sees rewards and offset fully cancel. If the proposer misses it, the offset remains and the reward is absent.\nThis also handles stray attestations naturally. A proposer that includes an attestation from a previous slot still receives the proposer reward. The corresponding offset was applied to the validator assigned the canonical proposal opportunity. If the original proposer earned the credit, its reward is reduced to (1-q)r(1 −𝑞)𝑟 by the offset. If it missed the credit, it takes the debit -qr−𝑞𝑟, while the later proposer receives r𝑟; the aggregate payoff remains (1-q)r(1 −𝑞)𝑟.\nThe resulting design can be read in two ways. It is an issuance-offset regime, because the existing reward and penalty logic is left intact and offsets are deducted during epoch processing. It is also penalty-equivalent, because the offset is applied at the duty opportunity, so a missed duty leaves the validator with the same downside as in the corresponding increased-penalty regime.\nA permissive flat issuance-offset regime under low issuance\nIn the current Ethereum spec, micro incentives have been designed such that the proposer does not incur penalties for missed slots. This preserves the property of a bounded downside risk of staking for the individual validator in the case that it is spuriously offline for some time. This has been promoted as a beneficial feature to the solo staker who may not have the resources to constantly monitor their setup. At the same time, it would seem preferable to also ensure that a solo staker performing its duties perfectly does not take on a loss each epoch just to break even during proposals. How can these two properties be upheld at the same time while also bringing down issuance to a very low level?\nOne way is to apply the flat issuance-offset regime while upholding a ratio between the base-reward curve and the macro-incentives curve that ensures the solo staker does not take a loss each regular epoch. With the current micro incentives, the regular attestation component is 54/6454/64 of the base-reward scale. If the macro-incentives curve is 10/6410/64 of the base-reward curve, then the common offset fraction is q = 54/64𝑞 =54/64 and equals the attestation rewards handed out for performed duties. The numerator 8+2=108 +2 =10 derives from the proposer-reward weight (8) and the sync-committee weight (2).\nAt the high-D𝐷, low-issuance end of Figure 1, the macro-incentive curve approaches this 10/6410/64 ratio. Under such conditions, the outcome is that the solo staker breaks even during an epoch with perfect attestation and no special duties, while at the same time not being subjected to the greater downside risks of missed proposals. If the macro incentive fraction is set greater than 10/6410/64, the solo staker will have a small positive reward each epoch during perfect attestation under full aggregate participation. Ratios such as 16/64 = 1/416/64 =1/4 could thus be used to provide positive regular rewards to solo stakers under those conditions and a small buffer against occasional missed duties over time as well as reduced aggregate participation.\n\nAppendix – Minority discouragement attacks\nIn the issuance-offset regime, the balance between attester and proposer remains the same. Rewards and penalties for performing staking duties generally need to be balanced to protect against minority discouragement attacks. For example, if there is no incentive for a proposer to include an attestation in the beacon block, whereas the attester takes a loss if it is not included, the proposer can grief the attester by leaving it out. This would allow the griefing validator to earn a higher yield than validators that dutifully include all observed attestations. For this reason, the proposer earns rewards for all attestations included.\nThere are various known minority discouragement attacks against the present consensus mechanism. For example, the proposer may selectively censor sync-committee attestations, an attack with a “griefing factor” of G=14𝐺 =14. For every ETH that the attacker loses out on, the censored validators will lose out on 14 ETH. This happens because the attester loses out on 7 times as much ETH as the proposer when the attestation is not included, and additionally takes a penalty 7 times higher than the ETH lost by the proposer. It turns out that the attacker can then hold a rather small minority of the stake, though not an insignificant one, while still profiting from the attack. The relatively higher yield of the attacking staking service provider (SSP) may lead delegators to prefer it, and as some censored validators leave, the equilibrium yield will rise under sustained censorship. As this example illustrates, balancing micro rewards is a nuanced subject.\nAnother example of a minority discouragement attack consists of attesters withholding attestations during an inactivity leak to deny the proposer rewards for timely head attestations. In the current consensus mechanism, attesters do not receive rewards during the inactivity leak, and need only ensure that the attestation is included within 2–5 slots to avoid penalties on the source vote. The griefing factor then becomes infinite. Moreover, if the attester is assigned as proposer within 2–5 slots, it can pick up rewards for the attestation itself and will thus directly profit from the attack.\nThis discussion highlights how a consensus mechanism can unravel when rewards and penalties are altered without consideration for minority discouragement attacks. For this reason, it seems preferable to retain the same micro-incentive balance, in the current and any future consensus design, across the full staking range. If the proposer and attesters have a particular relative reward/penalty distribution on a specific attestation type under a higher issuance regime, then that relative distribution is maintained in a lower regime. If instead a lower issuance is ensured by reducing rewards toward zero whereas penalties are increased, the balance between roles is more difficult to maintain. In the case that missed proposals do not incur an offset, any attempt to reduce issuance by rebalancing the reward/penalty distribution would be particularly hazardous, because it upends the power balance between the proposer and attester.\n\n read \n\n 7\n min\n\n 2 months later\n\n post by knoshua on Aug 19\n\n knoshua\n\n Thanks for the detailed write‑up!\nI’m trying to sanity-check my understanding of how EIP-8363 (which seems to implement essentially the penalty regime you proposed here) impacts opportunities for minority discouragement attacks, which you do touch on here as well.\nMy reading of your post is that by implementing such a penalty regime, we preserve the relative rewards and penalties inside the consensus mechanism, which means that the griefing factor of a discouragement attack is not changed. And of course that’s preferable to increasing the griefing factor and in that sense, opportunities for discouragement attacks aren’t increased.\nBut isn’t it true that the griefing factor is only one relevant aspect that an issuance change can affect? In your Reward curve with tempered issuance post, you mentioned a profitability condition for small epsilon attacks that also depends on “p-elasticity”. It’s my understanding that with the EIP-8363 curve, p-elasticity tends to infinity as stake ratio approaches 50%. Doesn’t this mean that even with griefing factors unchanged, discouragement attacks that today are not profitable would cross the profitability threshold at some point below 50% stake ratio?\nIn your view, should we explicitly evaluate EIP‑8363’s issuance curve against the p‑elasticity criteria? In other words: is it reasonable to say EIP‑8363 adopts your offset regime to avoid worsening griefing factors, but may still need additional constraints or safeguards if its net p-elasticity at high stake ratios makes epsilon discouragement attacks materially easier? Any pointers on how you would frame that distinction, or on specific attack modes where you think the macro side becomes more problematic even when micro incentives are preserved, would be very helpful.\n\n Powered by Discourse","tokens":5131,"squid":"spider-04","role":"Research Spider","at":1791347095019,"hash":"d8bcde0142525ff9513be4c01170584ee020cb58"}
{"url":"https://docs.pyth.network/price-feeds/core/push-feeds/solana","domain":"docs.pyth.network","title":"on Solana | Pyth Developer Hub","text":"Pyth CorePush Feedson SolanaList of Push Feeds on SolanaRequest Additional FeedsIf you would like to see additional feeds on this list, please fill in this\nform to signal your interest.\nSolana Mainnet\nThe price feeds listed below are currently sponsored in Solana mainnet and devnet.The Pro-compatible column shows whether each feed is already served by the upgraded Hermes endpoint for the Pyth Core upgrade. Feeds marked Available are already served by the upgraded Hermes. Not all Coming soon feeds are guaranteed to be migrated. If you rely on a specific feed, contact the team.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)NameAccount AddressPrice Feed IdUpdate ParametersPro-compatibleSOL/USD55 seconds heartbeat0.5% price deviationAvailableMSOL/USD55 seconds heartbeat0.5% price deviationAvailableBSOL/USD55 seconds heartbeat0.5% price deviationAvailableSSOL/SOL55 seconds heartbeat0.5% price deviationAvailableBONK/USD55 seconds heartbeat0.5% price deviationAvailableW/USD55 seconds heartbeat0.5% price deviationAvailableMEW/USD55 seconds heartbeat0.5% price deviationAvailableUSDC/USD55 seconds heartbeat0.5% price deviationAvailableBTC/USD55 seconds heartbeat0.5% price deviationAvailableUSDT/USD55 seconds heartbeat0.5% price deviationAvailableJUP/USD55 seconds heartbeat0.5% price deviationAvailableETH/USD55 seconds heartbeat0.5% price deviationAvailablePYTH/USD55 seconds heartbeat0.5% price deviationAvailableWIF/USD55 seconds heartbeat0.5% price deviationAvailableINF/USD55 seconds heartbeat0.5% price deviationAvailableMNDE/USD55 seconds heartbeat0.5% price deviationAvailableJLP/USD55 seconds heartbeat0.5% price deviationAvailableWBTC/USD55 seconds heartbeat0.5% price deviationAvailableTRUMP/USD55 seconds heartbeat0.5% price deviationAvailableFARTCOIN/USD55 seconds heartbeat0.5% price deviationAvailableACRED/USD55 seconds heartbeat0.5% price deviationAvailablePUMP/USD55 seconds heartbeat0.5% price deviationAvailableJUPSOL/SOL.RR55 seconds heartbeat0.5% price deviationAvailableNAV.USTB/USD55 seconds heartbeat0.5% price deviationAvailableNAV.USCC/USD55 seconds heartbeat0.5% price deviationAvailableZBTC/USD55 seconds heartbeat0.5% price deviationAvailableLBTC/USD55 seconds heartbeat0.5% price deviationAvailableINF/SOL.RR55 seconds heartbeat0.5% price deviationAvailableSYRUPUSDC/USDC.RR55 seconds heartbeat0.5% price deviationAvailableORE/USD55 seconds heartbeat0.5% price deviationAvailableNOPAL/USD.RR55 seconds heartbeat0.5% price deviationAvailableNTBILL/USD.RR55 seconds heartbeat0.5% price deviationAvailableNBASIS/USD.RR55 seconds heartbeat0.5% price deviationAvailableNWISDOM/USD.RR55 seconds heartbeat0.5% price deviationAvailableNALPHA/USD.RR55 seconds heartbeat0.5% price deviationAvailableNFALCON/USD.RR55 seconds heartbeat0.5% price deviationAvailableCASH/RD.RR30 seconds heartbeat0.5% price deviationAvailableCASH/USD30 seconds heartbeat0.5% price deviationAvailablePST/USDC.RR3 minutes heartbeat0.05% price deviationAvailableJUPUSD/USD55 seconds heartbeat0.5% price deviationAvailableEquity.US.GLXY/USD55 seconds heartbeat0.5% price deviationAvailableHYUSD/JITOSOL.RR55 seconds heartbeat0.5% price deviationAvailableEHYUSD/JITOSOL.RR55 seconds heartbeat0.5% price deviationAvailableXSOL/JITOSOL.RR55 seconds heartbeat0.5% price deviationAvailableJITOSOL/USD55 seconds heartbeat0.5% price deviationAvailableJITOSOL/SOL.RR55 seconds heartbeat0.5% price deviationAvailableMSOL/SOL.RR55 seconds heartbeat0.5% price deviationAvailableJTO/USD55 seconds heartbeat0.5% price deviationAvailableRENDER/USD55 seconds heartbeat0.5% price deviationAvailableZEC/USD55 seconds heartbeat0.5% price deviationAvailableDSOL/USD55 seconds heartbeat0.5% price deviationAvailableDSOL/SOL.RR55 seconds heartbeat0.5% price deviationAvailableMET/USD55 seconds heartbeat0.5% price deviationAvailableCLOUD/USD55 seconds heartbeat0.5% price deviationAvailableHYPE/USD55 seconds heartbeat0.5% price deviationAvailableUSD1/USD55 seconds heartbeat0.5% price deviationAvailableBNSOL/USD55 seconds heartbeat0.5% price deviationAvailableTNSR/USD55 seconds heartbeat0.5% price deviationAvailable2Z/USD55 seconds heartbeat0.5% price deviationAvailableAAVE/USD55 seconds heartbeat0.5% price deviationAvailableEURC/USD55 seconds heartbeat0.5% price deviationAvailableSYRUPUSDC/USD55 seconds heartbeat0.5% price deviationAvailableUSDE/USD55 seconds heartbeat0.5% price deviationAvailableRKUSOL/SOL.RR55 seconds heartbeat0.5% price deviationAvailable\nNote: The addresses represent the price feed account for shard 0 of the relevant price feed id.on EVMList of Push Feeds on EVM networkson FogoList of Push Feeds on Fogo","tokens":1186,"squid":"spider-08","role":"Oracle Spider","at":1791347107069,"hash":"fde0e06f3a5a183745fb9d3c429a7eda0a036822"}
{"url":"https://developer.arbitrum.io/launch-arbitrum-chain/chain-config/costs/gas-optimization","domain":"developer.arbitrum.io","title":"Configure and optimize gas","text":"Configure your chainCostsConfigure and optimize gasLearn how to configure and optimize gas for your Arbitrum chainRequest an updateTo configure gas behavior on an using the Chain SDK, you primarily use the ArbOwner precompile (at address 0x0000000000000000000000000000000000000070), which allows the to manage key parameters via function calls. These are called with post-deployment using tools like cast (from Foundry) or a custom script with a library like ethers.js or viem. The defaults inherit from the or standard Nitro settings, but it is possible to customize your Arbitrum chain as they are permissioned by design.\nBelow is a breakdown of each specified parameter, including its role, typical defaults (based on ), and how to configure it. Note that changes may require careful consideration to avoid impacting chain performance, user experience, or security. For example, setting limits too high could lead to state bloat or slower block processing.\nCautionAlways test changes on a devnet or testnet Arbitrum chain, as misconfiguration can lead to unexpected fee behavior or chain instability. Refer to the ArbOwnerPublic precompile for reading current settings without modifications. If using a custom gas token, ensure configurations are compatible.\nGas target\nThis is the target gas consumption rate per second that the chain can sustainably handle. It influences the congestion mechanism: if gas usage exceeds this limit, the base fee rises to throttle demand; if below the limit, the cost decreases (down to the floor). ArbOS uses this to update gas pools and enforce dynamic per-block gas limits.\n support two configuration modes -\n\n[RECOMMENDED] Multiple (supported starting ArbOS 51 Dia)\n\nDescription: Provides smoother price transitions. It uses multiple gas targets to reduce the frequency and severity of gas price spikes.\nConfiguration: Call the setGasPricingConstraints(uint64[3][] calldata constraints) method on the ArbOwner precompile, where constraints is an array of [gasTargetPerSecond, adjustmentWindowSeconds, startingBacklogValue] triples. \nDetailed information on how to set these parameters can be found in how to configure dynamic pricing for your chain. \nExample using cast:\ncast send --rpc-url $ORBIT_RPC --private-key $OWNER_KEY 0x0000000000000000000000000000000000000070 \"setGasPricingConstraints(uint64[3][])\" $NEW_CONSTRAINTS\n\nSingle Gas Target\n\nDescription: Uses a single as the reference for price adjustments. If gas usage exceeds this limit, the base fee rises to throttle demand; if usage is below, the price moves towards the floor.\nConfiguration: Call the setSpeedLimit(uint64 limit) method on the ArbOwner precompile, where limit is the desired gas per second. \nExample using cast:\ncast send --rpc-url $ORBIT_RPC --private-key $OWNER_KEY 0x0000000000000000000000000000000000000070 \"setSpeedLimit(uint64)\" $NEW_SPEED_LIMIT\n\nScope: From ArbOS 51 Dia onward, setSpeedLimit writes only the single gas target value. It does not change a multiple gas target configuration. If your chain has gas pricing constraints configured, setSpeedLimit has no effect on pricing until you clear them. Refer to how to set the gas target.\n\nThis setting is adjustable post-deployment. Any modifications should align with your node's capabilities to prevent issues with the congestion mechanism activating.\nRefer to the Chain parameters page, or the Additional configuration parameters for additional information.\nBlock gas limit\n\nDescription: This limits the maximum amount consumable by all in a single block—for execution, not for the parent chain data availability (DA) fee charge. It helps control block size and processing time. In practice, ArbOS enforces a dynamic limit based on the gas target and gas pools, but this sets a hard cap.\nDefault: 32,000,000 gas per block.\nConfiguration: Call the setMaxTxGasLimit(uint64 limit) method on the ArbOwner precompile, where limit is the desired max gas. Despite its name, on chains running ArbOS versions earlier than ArbOS 51 Dia this method caps total block gas usage. From ArbOS 51 onward, it caps individual transactions instead: the block limit is set separately with setMaxBlockGasLimit(uint64 limit), and the final transaction in a block may exceed it by up to the transaction limit (the effective block gas limit is MaxBlockGasLimit + MaxTxGasLimit).\n\nExample using cast:\ncast send --rpc-url $ORBIT_RPC --private-key $OWNER_KEY 0x0000000000000000000000000000000000000070 \"setMaxTxGasLimit(uint64)\" $NEW_LIMIT\nThis setting is adjustable post-deployment. Setting it too high can harm user experience due to longer block times.\nRefer to the Chain parameters page, or the Additional configuration parameters for additional information.\nGas price floor\n\nDescription: This is the minimum L2 base fee (in wei per gas unit), preventing fees from dropping too low during periods of low activity. The actual base fee fluctuates based on demand, but it will not fall below this set floor. It will affect user transaction costs.\nDefault: 0.1 gwei (100,000,000 wei).\nConfiguration:\n\nDuring deployment: Set the minL2BaseFee field in the Arbitrum chain setup script's config JSON.\nPost-deployment: Call the setMinimumL2BaseFee(uint256 newMinBaseFee) method on the ArbOwner precompile, where newMinBaseFee is the value in wei.\n\nExample using cast:\ncast send --rpc-url $ORBIT_RPC --private-key $OWNER_KEY 0x0000000000000000000000000000000000000070 \"setMinimumL2BaseFee(uint256)\" $NEW_FLOOR_IN_WEI\nYou can query the current floor via the ArbGasInfo precompile's getMinimumGasPrice().\nRefer to the Chain parameters, Additional configuration parameters, or the How to manage the fee parameters pages for additional information.\nPer batch gas cost\n\nDescription: This refers to the fixed base charge applied for the overhead of posting each to the parent chain. It is used in transaction pricing to amortize the parent chain's fixed costs (like calldata posting) over the batch's transactions. It can be adjusted to reflect actual posting costs or incentivize batching. The surplus (if any) gets rewarded to the .\nDefault: Varies based on parent chain fees, but typically around 210,000 gas (adjustable to match).\nConfiguration: Call the setPerBatchGasCharge(int64 newCharge) on the ArbOwner precompile, where newCharge is the fixed gas units per batch. This configuration adjusts the allocation of L2 gas for batch overhead in pricing. Additionally, you can configure related surplus fees (extra reward to batch poster) via setL1PricingRewardRate(uint64 rate). The parent chain base fee estimates influence the actual cost, which is dynamic; therefore, monitor them via ArbGasInfo's getPricesInWei() method.\n\nExample using cast (for per batch charge):\ncast send --rpc-url $ORBIT_RPC --private-key $OWNER_KEY 0x000000000000000000000000000000000000000070 \"setPerBatchGasCharge(int64)\" $NEW_BATCH_COST\nThis configuration is adjustable post-deployment. When working with layers or parent chains, you may need to further configure the data availability setup.\nRefer to the How to manage the fee parameters page for more information.\nGas floor per token\nNoteThis setting is only available starting from ArbOS 51 Dia.\n\nDescription: Gas floor per token refers to the minimum applied for batch posting to EIP-7623- enabled parent chains. It ensures that transactions with large calldata pay enough fees to cover data posting costs.\nDefault: Default value of this setting is based on the parent chain -\n\nIf your L2 chain posts calldata to Ethereum, the value should be set to 10, as specified in the EIP-7623. \nNote: While this value does not affect posting EIP-4844 blobs, we recommend keeping the default value of 10 as a safeguard. If your chain falls back to calldata posting - due to higher fees for blob posting or configuration changes - this setting ensures you continue to collect sufficient fees to cover L1 data posting costs.\nIf your L3 chain posts data to Arbitrum One / Nova, this parameter doesn't need to be set as these chains do not support EIP-7623.\nIf your L2 or L3 chain posts data to another parent chain, the parameter will have to be set based on the parent chain.\n\nConfiguration: Call the setParentGasFloorPerToken(uint64 newFloor) on the ArbOwner precompile to set the value for gasFloorPerToken. This value should be adjusted based on the parent chain's EIP-7623 settings to ensure the data-posting costs are fully covered.\n\nWarningChanging this value from the recommended default is not advised and should be left untouched in most circumstances, unless required by your parent chain.\nExample using cast (for per batch charge):\ncast send --rpc-url $ORBIT_RPC --private-key $OWNER_KEY 0x000000000000000000000000000000000000000070 \"setParentGasFloorPerToken(uint64)\" $NEW_FLOOR_VALUE\nThis setting is adjustable post-deployment. You can query the current floor via the ArbOwnerPublic precompile's getParentGasFloorPerToken().How is this guide?Revenue routingLearn how transaction fees flow through an Arbitrum chain: which addresses collect each fee component, when funds actually move, and how to withdraw revenue to the parent chainManage gas targetHow to manage your Arbitrum chain gas target","tokens":2294,"squid":"spider-01","role":"Chain Spider","at":1791347109789,"hash":"7468671e7f1fb957a2b6f7cc867d70469452327a"}
{"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":"spider-08","role":"Oracle Spider","at":1791347117100,"hash":"2777e0b352f5a461954c35b51066b146e3ec31df"}
{"url":"https://www.metaplex.com/docs/smart-contracts/genesis/sdk/api-client","domain":"metaplex.com","title":"API Client | Genesis SDK | Metaplex","text":"The Genesis API client provides high-level functions for creating and registering token launches. It handles transaction building, signing, and on-chain registration through a simple interface built on Umi. We recommend using the SDK to create launches programmatically, as metaplex.com does not yet support the full feature set of the Genesis program. Mainnet launches created through the API will appear on metaplex.com once registered.Installationnpm install @metaplex-foundation/genesis @metaplex-foundation/umi \\\n @metaplex-foundation/umi-bundle-defaults\nSetupimport { createUmi } from '@metaplex-foundation/umi-bundle-defaults';\nimport { genesis } from '@metaplex-foundation/genesis';\nimport { keypairIdentity } from '@metaplex-foundation/umi';\n\nconst umi = createUmi('https://api.mainnet-beta.solana.com')\n .use(genesis());\n\n// For server-side or scripts, load a keypair\numi.use(keypairIdentity(myKeypair));\nFunction OverviewFunctionPurposecreateAndRegisterLaunchOne-call token launch — create, sign, send, and registercreateLaunchBuild unsigned launch transactions for custom signing flowsregisterLaunchRegister a launch after its create transactions confirm on-chainclaimCreatorRewardsClaim accrued creator rewards across every bucket for a walletThree Integration ModesThe SDK offers three modes for creating launches, from fully automatic to fully manual.Easy Mode — createAndRegisterLaunchThe simplest approach. One function call handles everything: creates the on-chain accounts, signs and sends transactions via Umi, and registers the launch.createAndRegisterLaunch.ts1import {\n2 createAndRegisterLaunch,\n3 CreateLaunchInput,\n4 genesis,\n5} from '@metaplex-foundation/genesis'\n6import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n7import { keypairIdentity } from '@metaplex-foundation/umi'\n8\n9const umi = createUmi('https://api.mainnet-beta.solana.com')\n10 .use(genesis())\n11\n12// Use keypairIdentity to set a wallet when running server-side:\n13// umi.use(keypairIdentity(myKeypair))\n14\n15const input: CreateLaunchInput = {\n16 wallet: umi.identity.publicKey,\n17 token: {\n18 name: 'My Token',\n19 symbol: 'MTK',\n20 image: 'https://gateway.irys.xyz/...',\n21 },\n22 launchType: 'launchpool',\n23 launch: {\n24 launchpool: {\n25 tokenAllocation: 500_000_000,\n26 depositStartTime: new Date(Date.now() + 48 * 60 * 60 * 1000),\n27 raiseGoal: 250,\n28 raydiumLiquidityBps: 5000,\n29 fundsRecipient: umi.identity.publicKey,\n30 },\n31 },\n32}\n33\n34const result = await createAndRegisterLaunch(umi, {}, input)\n35console.log(`Launch live at: ${result.launch.link}`)\nReturns CreateAndRegisterLaunchResult:FieldTypeDescriptionsignaturesUint8Array[]Transaction signaturesmintAddressstringCreated token mint addressgenesisAccountstringGenesis account PDA addresslaunch.idstringLaunch IDlaunch.linkstringLaunch page URLtoken.idstringToken IDtoken.mintAddressstringToken mint addressMedium Mode — Custom Transaction SenderUse createAndRegisterLaunch with a custom txSender callback for scenarios like multisig wallets or custom retry logic.customTxSender.ts1import {\n2 createAndRegisterLaunch,\n3 SignAndSendOptions,\n4} from '@metaplex-foundation/genesis'\n5\n6// Assumes umi and input from the Easy Mode example.\n7\n8const options: SignAndSendOptions = {\n9 txSender: async (transactions) => {\n10 // Replace myCustomSign / myCustomSend with your own\n11 // signing and sending implementation.\n12 const signatures: Uint8Array[] = []\n13 for (const tx of transactions) {\n14 const signed = await myCustomSign(tx) // your signer\n15 const sig = await myCustomSend(signed) // your sender\n16 signatures.push(sig)\n17 }\n18 return signatures\n19 },\n20}\n21\n22const result = await createAndRegisterLaunch(umi, {}, input, options)\n23console.log(`Launch live at: ${result.launch.link}`)\nThe txSender callback receives the array of unsigned transactions and must return an array of signatures. The SDK handles registration after the callback completes.Full Control — createLaunch + registerLaunchFor complete control over the transaction lifecycle. You call createLaunch to get unsigned transactions, handle signing and sending yourself, then call registerLaunch.fullControl.ts1import {\n2 createLaunch,\n3 registerLaunch,\n4} from '@metaplex-foundation/genesis'\n5\n6// Assumes umi and input from the Easy Mode example.\n7\n8// Step 1: Get unsigned transactions from the API\n9const createResult = await createLaunch(umi, {}, input)\n10\n11// Step 2: Sign and send each transaction\n12for (const tx of createResult.transactions) {\n13 const signedTx = await umi.identity.signTransaction(tx)\n14 const signature = await umi.rpc.sendTransaction(signedTx, {\n15 commitment: 'confirmed',\n16 preflightCommitment: 'confirmed',\n17 })\n18 await umi.rpc.confirmTransaction(signature, {\n19 commitment: 'confirmed',\n20 strategy: {\n21 type: 'blockhash',\n22 ...createResult.blockhash,\n23 },\n24 })\n25}\n26\n27// Step 3: Register the launch\n28const registerResult = await registerLaunch(umi, {}, {\n29 genesisAccount: createResult.genesisAccount,\n30 createLaunchInput: input,\n31})\n32console.log(`Launch live at: ${registerResult.launch.link}`)\ncreateLaunch returns CreateLaunchResponse:FieldTypeDescriptiontransactionsTransaction[]Unsigned Umi transactions to sign and sendblockhashBlockhashWithExpiryBlockHeightBlockhash for confirming transactionsmintAddressstringCreated token mint addressgenesisAccountstringGenesis account PDA addressregisterLaunch returns RegisterLaunchResponse:FieldTypeDescriptionexistingboolean?true if launch was already registeredlaunch.idstringLaunch IDlaunch.linkstringLaunch page URLtoken.idstringToken IDtoken.mintAddressstringToken mint addressTransactions must be confirmed on-chain before calling registerLaunch. The register endpoint validates that the genesis account exists and matches the expected configuration.Claim Creator RewardsclaimCreatorRewards calls POST /v1/creator-rewards/claim and returns the base64-encoded claim transactions for every eligible bonding-curve and Raydium bucket, already deserialized into Umi Transactions. Sign and send each one using the Umi identity. For the end-to-end claim flow — including the creator fee configuration, accrual checks, and the lower-level per-bucket instructions — see Creator Fees on the Genesis Bonding Curve.claimCreatorRewards.ts1import { claimCreatorRewards } from '@metaplex-foundation/genesis'\n2import { base58 } from '@metaplex-foundation/umi/serializers'\n3import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n4import { keypairIdentity } from '@metaplex-foundation/umi'\n5\n6const umi = createUmi('https://api.mainnet-beta.solana.com')\n7const keypair = umi.eddsa.createKeypairFromSecretKey(mySecretKeyBytes)\n8umi.use(keypairIdentity(keypair))\n9\n10const result = await claimCreatorRewards(umi, {}, {\n11 wallet: umi.identity.publicKey,\n12 network: 'solana-mainnet',\n13 // payer is optional — defaults to `wallet` on the server.\n14 // Set it to have a different wallet cover rent and transaction fees.\n15 // payer: umi.identity.publicKey,\n16})\n17\n18for (const tx of result.transactions) {\n19 const signed = await umi.identity.signTransaction(tx)\n20 const signature = await umi.rpc.sendTransaction(signed, {\n21 preflightCommitment: 'confirmed',\n22 })\n23 await umi.rpc.confirmTransaction(signature, {\n24 strategy: { type: 'blockhash', ...result.blockhash },\n25 commitment: 'confirmed',\n26 })\n27 console.log('Claimed:', base58.deserialize(signature)[0])\n28}\n29\n30// Claimed: 5uGGYEMmjP2HpyFCvLPNpVDSQEBtUE3LR6ZQFqhJxQSh5FbKacSyN8nQmAJowuFs6BTCdwzoFyyJz8Y2hQx8kPxo\n31// Claimed: 3TAroVovEap1ZEAJYq3WiDZoMK3GU3soCdrhvZJNg6b9EANqvWrVcDGNffm7mD8wvtpR7ynWQBcbrmz8AK6nrhfy\nClaimCreatorRewardsInputFieldTypeRequiredDescriptionwalletPublicKey | stringYesThe creator fee wallet to claim for.networkSvmNetworkNo'solana-mainnet' (default) or 'solana-devnet'. Must match the API base URL — https://api.metaplex.compayerPublicKey | stringNoWallet that covers fees and rent on the returned transactions. Defaults to wallet. Use this when the creator fee wallet does not hold SOL (for example, an agent PDA). The payer must sign the returned transactions; the creator fee wallet still receives the claimed SOL.ClaimCreatorRewardsResponseFieldTypeDescriptiontransactionsTransaction[]Deserialized Umi transactions, one per bucket being claimed. Sign each with the payer identity and send.blockhashBlockhashWithExpiryBlockHeightThe blockhash the transactions were built against. Use it to confirm — do not substitute a freshly-fetched blockhash.No-rewards is a typed error, not an empty arrayWhen the wallet has nothing to claim, the API returns HTTP 400 with {\"error\":{\"message\":\"No rewards available to claim\"}} and the SDK throws GenesisApiError. Callers must catch the error and branch on err.message (or err.statusCode === 400) — they cannot rely on result.transactions.length === 0. See Handling the No-Rewards Case.errorHandling.ts1import {\n2 claimCreatorRewards,\n3 isGenesisApiError,\n4 isGenesisApiNetworkError,\n5} from '@metaplex-foundation/genesis'\n6\n7// Assumes umi is configured with a keypair identity.\n8\n9try {\n10 const result = await claimCreatorRewards(umi, {}, {\n11 wallet: umi.identity.publicKey,\n12 network: 'solana-mainnet',\n13 })\n14 console.log(`Claimable transactions: ${result.transactions.length}`)\n15} catch (err) {\n16 if (isGenesisApiError(err)) {\n17 // The API returns HTTP 400 with\n18 // { \"error\": { \"message\": \"No rewards available to claim\" } }\n19 // when the wallet has no unclaimed creator rewards. Match on the message\n20 // (or statusCode === 400) to handle this as a success case rather than a\n21 // failure.\n22 if (err.message === 'No rewards available to claim') {\n23 console.log('Nothing to claim right now.')\n24 } else {\n25 console.error('API error:', err.statusCode, err.message)\n26 }\n27 } else if (isGenesisApiNetworkError(err)) {\n28 console.error('Network error:', err.cause.message)\n29 } else {\n30 throw err\n31 }\n32}\n33\n34// Nothing to claim right now.\nConfigurationCreateLaunchInputFieldTypeRequiredDescriptionwalletPublicKey | stringYesCreator's wallet (signs transactions)tokenTokenMetadataYesToken metadatanetworkSvmNetworkNo'solana-mainnet' (default) or 'solana-devnet'quoteMintQuoteMintInputNo'SOL' (default) or 'USDC'launchTypeCreateLaunchTypeYes'launchpool' — the underlying launch mechanismlaunchLaunchpoolLaunchInputYesLaunch configurationTokenMetadataFieldTypeRequiredDescriptionnamestringYesToken name, 1–32 characterssymbolstringYesToken symbol, 1–10 charactersimagestringYesImage URL (valid HTTPS URL)descriptionstringNoMax 250 charactersexternalLinksExternalLinksNoWebsite, Twitter, Telegram linksExternalLinksFieldTypeDescriptionwebsitestring?Website URLtwitterstring?Twitter/X handle (@mytoken) or full URLtelegramstring?Telegram handle or full URLLaunchpoolConfigFieldTypeDescriptiontokenAllocationnumberTokens to sell (portion of 1B total supply)depositStartTimeDate | stringWhen the deposit period opens (lasts 48 hours)raiseGoalnumberMinimum quote tokens to raise, in whole units (e.g. 250 SOL). Minimum 250 SOL or 5,000 USDCraydiumLiquidityBpsnumber% of raised funds for Raydium LP, in basis points (2000–10000)fundsRecipientPublicKey | stringReceives the unlocked portion of raised fundsLockedAllocation (Streamflow Lockup)Optional locked token schedules can be added via launch.lockedAllocations:FieldTypeDescriptionnamestringStream name, max 64 characters (e.g. \"Team\", \"Advisors\")recipientPublicKey | stringLockup recipient wallettokenAmountnumberTotal tokens in the locked schedulevestingStartTimeDate | stringWhen the unlock schedule beginsvestingDuration{ value: number, unit: TimeUnit }Full lockup periodunlockScheduleTimeUnitHow frequently tokens are releasedcliffobject?Optional cliff with duration and unlockAmountThe vestingStartTime must be after the deposit period ends (i.e., after depositStartTime + 48 hours). The API will reject locked schedules that start before the deposit window closes.TimeUnit values: 'SECOND', 'MINUTE', 'HOUR', 'DAY', 'WEEK', 'TWO_WEEKS', 'MONTH', 'QUARTER', 'YEAR'Example with locked allocations:lockedAllocations.ts1import {\n2 createAndRegisterLaunch,\n3 CreateLaunchInput,\n4 genesis,\n5} from '@metaplex-foundation/genesis'\n6import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n7import { keypairIdentity } from '@metaplex-foundation/umi'\n8\n9const umi = createUmi('https://api.mainnet-beta.solana.com')\n10 .use(genesis())\n11\n12// Use keypairIdentity to set a wallet when running server-side:\n13// umi.use(keypairIdentity(myKeypair))\n14\n15const input: CreateLaunchInput = {\n16 wallet: umi.identity.publicKey,\n17 token: {\n18 name: 'My Token',\n19 symbol: 'MTK',\n20 image: 'https://gateway.irys.xyz/...',\n21 description: 'A project token with locked allocations.',\n22 externalLinks: {\n23 website: 'https://example.com',\n24 twitter: '@mytoken',\n25 },\n26 },\n27 launchType: 'launchpool',\n28 launch: {\n29 launchpool: {\n30 tokenAllocation: 500_000_000,\n31 depositStartTime: new Date('2026-04-01T00:00:00Z'),\n32 raiseGoal: 250,\n33 raydiumLiquidityBps: 5000,\n34 fundsRecipient: 'FundsRecipientWallet...',\n35 },\n36 lockedAllocations: [\n37 {\n38 name: 'Team',\n39 recipient: 'TeamWallet...',\n40 tokenAmount: 100_000_000,\n41 vestingStartTime: new Date('2026-04-05T00:00:00Z'),\n42 vestingDuration: { value: 1, unit: 'YEAR' },\n43 unlockSchedule: 'MONTH',\n44 cliff: {\n45 duration: { value: 3, unit: 'MONTH' },\n46 unlockAmount: 10_000_000,\n47 },\n48 },\n49 ],\n50 },\n51}\n52\n53const result = await createAndRegisterLaunch(umi, {}, input)\n54console.log(`Launch live at: ${result.launch.link}`)\nSignAndSendOptionsOptions for createAndRegisterLaunch (extends RpcSendTransactionOptions):FieldTypeDefaultDescriptiontxSender(txs: Transaction[]) => Promise<Uint8Array[]>—Custom transaction sender callbackcommitmentstring'confirmed'Commitment level for confirmationpreflightCommitmentstring'confirmed'Preflight commitment levelskipPreflightbooleanfalseSkip preflight checksError HandlingThe SDK provides three error types with type guard functions.GenesisApiErrorThrown when the API returns a non-success response.import { isGenesisApiError } from '@metaplex-foundation/genesis';\n\ntry {\n await createLaunch(umi, {}, input);\n} catch (err) {\n if (isGenesisApiError(err)) {\n console.error('API error:', err.statusCode, err.responseBody);\n }\n}\nPropertyTypeDescriptionstatusCodenumberHTTP status coderesponseBodyunknownFull response body from the APIGenesisApiNetworkErrorThrown when the fetch call fails (network issue, DNS failure, etc.).import { isGenesisApiNetworkError } from '@metaplex-foundation/genesis';\n\nif (isGenesisApiNetworkError(err)) {\n console.error('Network error:', err.cause.message);\n}\nPropertyTypeDescriptioncauseErrorThe underlying fetch errorGenesisValidationErrorThrown when input validation fails before making an API call.import { isGenesisValidationError } from '@metaplex-foundation/genesis';\n\nif (isGenesisValidationError(err)) {\n console.error(`Validation failed on field \"${err.field}\":`, err.message);\n}\nPropertyTypeDescriptionfieldstringThe input field that failed validationComprehensive Error HandlingerrorHandling.ts1import {\n2 createAndRegisterLaunch,\n3 isGenesisApiError,\n4 isGenesisApiNetworkError,\n5 isGenesisValidationError,\n6} from '@metaplex-foundation/genesis'\n7\n8// Assumes umi and input from the Easy Mode example.\n9\n10try {\n11 const result = await createAndRegisterLaunch(umi, {}, input)\n12 console.log(`Launch live at: ${result.launch.link}`)\n13} catch (err) {\n14 if (isGenesisValidationError(err)) {\n15 console.error(`Invalid input \"${err.field}\":`, err.message)\n16 } else if (isGenesisApiError(err)) {\n17 console.error('API error:', err.statusCode, err.responseBody)\n18 } else if (isGenesisApiNetworkError(err)) {\n19 console.error('Network error:', err.cause.message)\n20 } else {\n21 throw err\n22 }\n23}\nValidation RulesThe SDK validates inputs before sending them to the API:RuleConstraintToken name1–32 charactersToken symbol1–10 charactersToken imageValid HTTPS URLToken descriptionMax 250 charactersToken allocationGreater than 0Raise goalGreater than 0Raydium liquidity BPS2000–10000 (20%–100%)Total supplyFixed at 1 billion tokensLocked allocation nameMax 64 charactersThe total supply is always 1 billion tokens. The SDK automatically calculates the creator allocation as the remainder after subtracting the launchpool, Raydium LP, and any locked allocations.Helper FunctionssignAndSendLaunchTransactionsIf you want the default sign-and-send behavior as a standalone function (useful for retries or partial flows):import {\n createLaunch,\n signAndSendLaunchTransactions,\n} from '@metaplex-foundation/genesis';\n\nconst createResult = await createLaunch(umi, {}, input);\nconst signatures = await signAndSendLaunchTransactions(umi, createResult, {\n commitment: 'confirmed',\n});\nTransactions are signed and sent sequentially — each is confirmed before the next is sent.buildCreateLaunchPayloadValidates input and builds the raw API payload. Exported for advanced use cases:import { buildCreateLaunchPayload } from '@metaplex-foundation/genesis';\n\nconst payload = buildCreateLaunchPayload(input);\n// Use payload with your own HTTP client","tokens":4278,"squid":"dotcat","role":"Tooling Spider","at":1791347118679,"hash":"8806944cf88abe038949562c40e1416e42595347"}
{"url":"https://developer.arbitrum.io/arbitrum-essentials/precompiles/reference","domain":"developer.arbitrum.io","title":"Precompiles reference","text":"PrecompilesPrecompiles referenceComplete reference for all Arbitrum precompiled contracts, including ArbSys, ArbRetryableTx, ArbGasInfo, ArbAggregator, and more. Lists methods, addresses, Solidity interfaces, and Go implementations.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\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\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\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\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\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\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\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\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\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\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()InterfaceImplementationGetNativeTokenManagementFrom 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\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\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\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\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\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 programHow is this guide?OverviewOverview of Arbitrum precompiled contracts — predefined smart contracts executed natively by the Arbitrum client for optimized performance. Covers both Ethereum-standard and Arbitrum-specific precompiles.NodeInterfaceQuery gas estimates and chain data through the NodeInterface.","tokens":8672,"squid":"spider-01","role":"Chain Spider","at":1791347119770,"hash":"9a8082256237b3065a2910951a64fafae115bff4"}
{"url":"https://www.metaplex.com/docs/smart-contracts/genesis/sdk/javascript","domain":"metaplex.com","title":"JavaScript SDK | Genesis | Metaplex","text":"API reference for the Genesis JavaScript SDK. For complete tutorials, see Launch Pool or Presale. NPM Package@metaplex-foundation/genesisTypeDocAuto-generated API docsInstallationnpm install @metaplex-foundation/genesis @metaplex-foundation/umi \\\n @metaplex-foundation/umi-bundle-defaults @metaplex-foundation/mpl-toolbox \\\n @metaplex-foundation/mpl-token-metadata\nSetupimport { createUmi } from '@metaplex-foundation/umi-bundle-defaults';\nimport { genesis } from '@metaplex-foundation/genesis';\nimport { mplTokenMetadata } from '@metaplex-foundation/mpl-token-metadata';\n\nconst umi = createUmi('https://api.mainnet-beta.solana.com')\n .use(genesis())\n .use(mplTokenMetadata());\nFor complete implementation examples, see Launch Pool or Presale.Instructions ReferenceCoreFunctionDescriptioninitializeV2()Create Genesis Account and mint tokenfinalizeV2()Lock configuration, activate launchBucketsFunctionDescriptionaddLaunchPoolBucketV2()Add proportional distribution bucketaddPresaleBucketV2()Add fixed-price sale bucketaddUnlockedBucketV2()Add treasury/recipient bucketLaunch Pool OperationsFunctionDescriptiondepositLaunchPoolV2()Deposit SOL into Launch PoolwithdrawLaunchPoolV2()Withdraw SOL (during deposit period)claimLaunchPoolV2()Claim tokens (after deposit period)refundLaunchPoolV2()Refund a deposit (failed threshold or exceeded soft cap)Presale OperationsFunctionDescriptiondepositPresaleV2()Deposit SOL into PresaleclaimPresaleV2()Claim tokens (after deposit period)AdminFunctionDescriptiontriggerBehaviorsV2()Execute end behaviorsrevokeV2()Permanently revoke mint and/or freeze authorityFunction SignaturesinitializeV2await initializeV2(umi, {\n baseMint, // Signer - new token keypair\n quoteMint, // PublicKey - deposit token (wSOL)\n fundingMode, // number - use 0\n totalSupplyBaseToken, // bigint - supply with decimals\n name, // string - token name\n symbol, // string - token symbol\n uri, // string - metadata URI\n}).sendAndConfirm(umi);\nfinalizeV2await finalizeV2(umi, {\n baseMint, // PublicKey\n genesisAccount, // PublicKey\n}).sendAndConfirm(umi);\naddLaunchPoolBucketV2await addLaunchPoolBucketV2(umi, {\n genesisAccount, // PublicKey\n baseMint, // PublicKey\n baseTokenAllocation, // bigint - tokens for this bucket\n depositStartCondition, // TimeCondition\n depositEndCondition, // TimeCondition\n claimStartCondition, // TimeCondition\n claimEndCondition, // TimeCondition\n minimumDepositAmount, // { amount: bigint } | null\n minimumQuoteTokenThreshold, // { amount: bigint } | null - floor, launch fails below it\n softCap, // { amount: bigint } | null - REQUIRED, ceiling on quote kept\n endBehaviors, // EndBehavior[]\n}).sendAndConfirm(umi);\nsoftCap is a required argument as of @metaplex-foundation/genesis 0.42.0. Unlike the other Launch Pool extensions it has no default in the generated serializer, so pass softCap: null explicitly when the launch has no cap. See Launch Pool Soft Cap for behaviour.addPresaleBucketV2await addPresaleBucketV2(umi, {\n genesisAccount, // PublicKey\n baseMint, // PublicKey\n baseTokenAllocation, // bigint\n allocationQuoteTokenCap, // bigint - SOL cap (sets price)\n depositStartCondition, // TimeCondition\n depositEndCondition, // TimeCondition\n claimStartCondition, // TimeCondition\n claimEndCondition, // TimeCondition\n minimumDepositAmount, // bigint | null\n depositLimit, // bigint | null - max per user\n endBehaviors, // EndBehavior[]\n}).sendAndConfirm(umi);\naddUnlockedBucketV2await addUnlockedBucketV2(umi, {\n genesisAccount, // PublicKey\n baseMint, // PublicKey\n baseTokenAllocation, // bigint - usually 0n\n recipient, // PublicKey - who can claim\n claimStartCondition, // TimeCondition\n claimEndCondition, // TimeCondition\n}).sendAndConfirm(umi);\ndepositLaunchPoolV2await depositLaunchPoolV2(umi, {\n genesisAccount, // PublicKey\n bucket, // PublicKey\n baseMint, // PublicKey\n amountQuoteToken, // bigint - lamports\n}).sendAndConfirm(umi);\ndepositPresaleV2await depositPresaleV2(umi, {\n genesisAccount, // PublicKey\n bucket, // PublicKey\n baseMint, // PublicKey\n amountQuoteToken, // bigint - lamports\n}).sendAndConfirm(umi);\nwithdrawLaunchPoolV2await withdrawLaunchPoolV2(umi, {\n genesisAccount, // PublicKey\n bucket, // PublicKey\n baseMint, // PublicKey\n amountQuoteToken, // bigint - lamports\n}).sendAndConfirm(umi);\nclaimLaunchPoolV2await claimLaunchPoolV2(umi, {\n genesisAccount, // PublicKey\n bucket, // PublicKey\n baseMint, // PublicKey\n recipient, // PublicKey\n}).sendAndConfirm(umi);\nrefundLaunchPoolV2Refunds a Launch Pool deposit after the deposit window closes. The program derives the amount, so there is no amount argument: a missed minimumQuoteTokenThreshold refunds the full deposit, and an exceeded softCap refunds only the excess while leaving the depositor's token allocation intact.await refundLaunchPoolV2(umi, {\n genesisAccount, // PublicKey\n bucket, // PublicKey\n baseMint, // PublicKey\n recipient, // PublicKey | Signer - depositor; base token account closed if they sign\n}).sendAndConfirm(umi);\nOnly payer must sign, so refunds can be cranked permissionlessly on a depositor's behalf. Calling before the deposit window closes returns LaunchPoolNotEnded; calling when the floor was met and the cap was not exceeded returns LaunchPoolThresholdMet; calling twice returns DepositAlreadyRefunded.claimPresaleV2await claimPresaleV2(umi, {\n genesisAccount, // PublicKey\n bucket, // PublicKey\n baseMint, // PublicKey\n recipient, // PublicKey\n}).sendAndConfirm(umi);\ntriggerBehaviorsV2Processes the configured end behaviors for a primary bucket, moving collected funds to the destination buckets defined in endBehaviors.await triggerBehaviorsV2(umi, {\n genesisAccount, // PublicKey\n primaryBucket, // PublicKey\n baseMint, // PublicKey\n})\n .addRemainingAccounts([/* destination bucket + its quote token account */])\n .sendAndConfirm(umi);\nrevokeV2Permanently revokes mint and/or freeze authority for the base token.await revokeV2(umi, {\n genesisAccount, // PublicKey\n baseMint, // PublicKey\n revokeMintAuthority, // boolean\n revokeFreezeAuthority, // boolean\n}).sendAndConfirm(umi);\nPDA HelpersFunctionSeedsfindGenesisAccountV2Pda()baseMint, genesisIndexfindLaunchPoolBucketV2Pda()genesisAccount, bucketIndexfindPresaleBucketV2Pda()genesisAccount, bucketIndexfindUnlockedBucketV2Pda()genesisAccount, bucketIndexfindLaunchPoolDepositV2Pda()bucket, recipientfindPresaleDepositV2Pda()bucket, recipientconst [genesisAccountPda] = findGenesisAccountV2Pda(umi, { baseMint: mint.publicKey, genesisIndex: 0 });\nconst [bucketPda] = findLaunchPoolBucketV2Pda(umi, { genesisAccount: genesisAccountPda, bucketIndex: 0 });\nconst [depositPda] = findLaunchPoolDepositV2Pda(umi, { bucket: bucketPda, recipient: wallet });\nFetch FunctionsGenesis AccountThe Genesis Account stores top-level launch state including the launch type. A backend crank sets the launchType field on-chain after creation via the setLaunchTypeV2 instruction, so the value may initially be Uninitialized (0) until the crank processes it.FunctionReturnsfetchGenesisAccountV2()Genesis account state (throws if missing)safeFetchGenesisAccountV2()Genesis account state or nullfetchGenesisAccountV2FromSeeds()Fetch by PDA seeds (baseMint, genesisIndex)safeFetchGenesisAccountV2FromSeeds()Same as above, returns null if missingfetchAllGenesisAccountV2()Batch fetch multiple genesis accountsimport {\n fetchGenesisAccountV2,\n fetchGenesisAccountV2FromSeeds,\n findGenesisAccountV2Pda,\n LaunchType,\n} from '@metaplex-foundation/genesis';\n\n// Fetch by PDA address\nconst [genesisAccountPda] = findGenesisAccountV2Pda(umi, {\n baseMint: mintAddress,\n genesisIndex: 0,\n});\nconst account = await fetchGenesisAccountV2(umi, genesisAccountPda);\nconsole.log(account.data.launchType); // 0 = Uninitialized, 3 = LaunchPoolV1\n\n// Or fetch directly from seeds\nconst account2 = await fetchGenesisAccountV2FromSeeds(umi, {\n baseMint: mintAddress,\n genesisIndex: 0,\n});\n\n// Check launch type\nif (account2.data.launchType === LaunchType.LaunchPoolV1) {\n console.log('This is a launch pool');\n}\nGenesis account fields: authority, baseMint, quoteMint, totalSupplyBaseToken, totalAllocatedSupplyBaseToken, totalProceedsQuoteToken, fundingMode, launchType, bucketCount, finalizedGPA Builder — Query by Launch TypeUse getGenesisAccountV2GpaBuilder() to query all genesis accounts filtered by on-chain fields. This uses Solana's getProgramAccounts RPC method with byte-level filters for efficient lookups.import {\n getGenesisAccountV2GpaBuilder,\n LaunchType,\n} from '@metaplex-foundation/genesis';\n\n// Get all launch pool launches\nconst launchpools = await getGenesisAccountV2GpaBuilder(umi)\n .whereField('launchType', LaunchType.LaunchPoolV1)\n .getDeserialized();\n\n// Filter by multiple fields\nconst finalizedLaunchpools = await getGenesisAccountV2GpaBuilder(umi)\n .whereField('launchType', LaunchType.LaunchPoolV1)\n .whereField('finalized', true)\n .getDeserialized();\n\nfor (const account of launchpools) {\n console.log(account.publicKey, account.data.baseMint, account.data.launchType);\n}\nlaunchType is set retroactively by a backend crank after a launch is created. Recently created launches may still show LaunchType.Uninitialized (0) until the crank processes them.Buckets and DepositsFunctionReturnsfetchLaunchPoolBucketV2()Bucket state (throws if missing)safeFetchLaunchPoolBucketV2()Bucket state or nullfetchPresaleBucketV2()Bucket state (throws if missing)safeFetchPresaleBucketV2()Bucket state or nullfetchLaunchPoolDepositV2()Deposit state (throws if missing)safeFetchLaunchPoolDepositV2()Deposit state or nullfetchPresaleDepositV2()Deposit state (throws if missing)safeFetchPresaleDepositV2()Deposit state or nullconst bucket = await fetchLaunchPoolBucketV2(umi, bucketPda);\nconst deposit = await safeFetchLaunchPoolDepositV2(umi, depositPda); // null if not found\nBucket state fields: quoteTokenDepositTotal, weightedQuoteTokenTotal, depositCount, claimCount, refundCount, bucket.baseTokenAllocation, extensionsDeposit state fields: amountQuoteToken, weightedQuoteToken, claimed, refundedTypesLaunchPoolV2ExtensionsOptional guards on a Launch Pool bucket, read from bucket.extensions. Every field is a Umi Option, so use unwrapOption() or check .__option before reading a value.{\n backendSigner: Option<BackendSigner>;\n depositPenalty: Option<LinearBpsScheduleV2>;\n withdrawPenalty: Option<LinearBpsScheduleV2>;\n bonusSchedule: Option<LinearBpsScheduleV2>;\n depositLimit: Option<DepositLimit>; // { limit: bigint }\n allowlist: Option<Allowlist>;\n claimSchedule: Option<ClaimSchedule>;\n minimumDepositAmount: Option<MinimumDepositAmount>; // { amount: bigint }\n minimumQuoteTokenThreshold: Option<MinimumQuoteTokenThreshold>; // { amount: bigint } - floor\n softCap: Option<SoftCap>; // { amount: bigint } - ceiling\n}\nExtensions can be added or removed individually with addLaunchPoolBucketV2Extensions() and removeLaunchPoolBucketV2Extensions(), selecting the field via LaunchPoolV2ExtensionType. Both are rejected once the Genesis Account is finalized.LaunchTypeThe on-chain launch type, set retroactively by a backend crank via the setLaunchTypeV2 instruction. The launch type represents the underlying mechanism used for the launch.enum LaunchType {\n Uninitialized = 0, // Not yet set by the crank\n LaunchPoolV1 = 3, // Launch pool (proportional distribution)\n}\nThe Metaplex API returns this as a string ('launchpool'), while the on-chain SDK uses the numeric enum above.GenesisAccountV2Top-level on-chain account for a Genesis launch. One account per token mint per launch index.{\n key: Key;\n bump: number;\n index: number; // Genesis index (usually 0)\n finalized: boolean; // true after finalizeV2()\n authority: PublicKey; // Launch creator\n baseMint: PublicKey; // Token being launched\n quoteMint: PublicKey; // Deposit token (e.g., wSOL)\n totalSupplyBaseToken: bigint; // Total token supply\n totalAllocatedSupplyBaseToken: bigint; // Supply allocated to buckets\n totalProceedsQuoteToken: bigint; // Total deposits collected\n fundingMode: number; // Funding mode (0)\n launchType: number; // 0 = Uninitialized, 3 = LaunchPoolV1\n bucketCount: number; // Number of buckets\n}\nAccount size: 136 bytes. PDA seeds: [\"genesis_v2\", baseMint, genesisIndex].TimeCondition{\n __kind: 'TimeAbsolute',\n padding: Array(47).fill(0),\n time: bigint, // Unix timestamp (seconds)\n triggeredTimestamp: null,\n}\nEndBehavior{\n __kind: 'SendQuoteTokenPercentage',\n padding: Array(4).fill(0),\n destinationBucket: PublicKey,\n percentageBps: number, // 10000 = 100%\n processed: false,\n}\nConstantsConstantValueWRAPPED_SOL_MINTSo11111111111111111111111111111111111111112Common ErrorsErrorCauseinsufficient fundsNot enough SOL for feesalready initializedGenesis Account existsalready finalizedCannot modify after finalizationdeposit period not activeOutside deposit windowclaim period not activeOutside claim windowInvalidSoftCap (221)softCap.amount is zero — pass softCap: null instead of { amount: 0n }SoftCapBelowThreshold (222)softCap.amount is below minimumQuoteTokenThreshold.amountLaunchPoolNotEndedrefundLaunchPoolV2() called before the deposit window closedLaunchPoolThresholdMet (173)Refund requested when the floor was met and the soft cap was not exceededDepositAlreadyRefundedrefundLaunchPoolV2() called twice for the same depositFAQWhat is Umi and why is it required?Umi is Metaplex's JavaScript framework for Solana. It provides a consistent interface for building transactions, managing signers, and interacting with Metaplex programs.Can I use the Genesis SDK in a browser?Yes. The SDK works in both Node.js and browser environments. For browsers, use a wallet adapter for signing instead of keypair files.What's the difference between fetch and safeFetch?fetch throws an error if the account doesn't exist. safeFetch returns null instead, useful for checking if an account exists.How do I retrieve the launch type for a token?Fetch the GenesisAccountV2 account using fetchGenesisAccountV2FromSeeds() with the token's mint address. The launchType field returns 0 (Uninitialized) or 3 (LaunchPoolV1). To query all launches of a given type, use the GPA builder. Alternatively, the Metaplex API returns the launch type as a string in REST responses.How do I handle transaction errors?Wrap sendAndConfirm calls in try/catch blocks. Check error messages for specific failure reasons.Next StepsFor complete implementation tutorials:Getting Started - Setup and first launchLaunch Pool - Proportional distributionPresale - Fixed-price sales","tokens":3607,"squid":"dotcat","role":"Tooling Spider","at":1791347128661,"hash":"4e255cfc4e30351b825cd5f4a863a65af6130998"}
{"url":"https://developer.arbitrum.io/arbitrum-essentials/nodeinterface","domain":"developer.arbitrum.io","title":"NodeInterface","text":"NodeInterfaceQuery gas estimates and chain data through the NodeInterface.Request an updateThe NodeInterface is a virtual contract that exposes gas estimation and chain data that has no Ethereum equivalent.\nOverviewThe virtual contract at 0xc8, reachable only over RPC.ReferenceEvery method, including gas estimation and proof construction.How is this guide?ReferenceComplete reference for all Arbitrum precompiled contracts, including ArbSys, ArbRetryableTx, ArbGasInfo, ArbAggregator, and more. Lists methods, addresses, Solidity interfaces, and Go implementations.OverviewOverview of Arbitrum's NodeInterface, a virtual contract at address 0xc8 accessible only via RPCs. Provides gas estimation, proof construction, and other node-level utilities not available onchain.","tokens":193,"squid":"spider-01","role":"Chain Spider","at":1791347130065,"hash":"797fa128235993388e420b3117528bf26643fc9b"}
{"url":"https://www.metaplex.com/docs/smart-contracts/genesis/project-vesting","domain":"metaplex.com","title":"Project Token Vesting with ClaimScheduleBucketV2 | Genesis | Metaplex","text":"Genesis project vesting uses a ClaimScheduleBucketV2 to release one token allocation to one recipient according to an onchain cliff and periodic linear schedule. What You'll BuildThis guide creates a one-year project token vesting allocation with a 10% cliff, monthly linear unlocks, and optional authority controls.SummaryClaimScheduleBucketV2 is a first-class Genesis outflow bucket for project, team, advisor, or treasury token vesting. It stores the recipient, allocation, claim history, vesting curve, pause state, policy controls, and optional cancellation behavior onchain.One bucket vests one token allocation to one current recipientA ClaimSchedule combines an independent cliff with period-based linear unlocksClaims are permissionless but always pay the bucket's recipientOptional policies support authority pauses, cancellation, recipient cancellation, and recipient transfersJump to: Quick Start · Vesting Mechanics · Runtime Controls · Cancellation · ReferenceClaimScheduleBucketV2 and ClaimScheduleClaimScheduleBucketV2 is the account that owns a project allocation, while ClaimSchedule is the reusable vesting curve embedded in that account.TypePurposeClaimScheduleBucketV2Stores one recipient, allocation, claimed amount, schedule, claim gate, pause state, policies, and end behaviorsClaimScheduleDefines the cliff amount, cliff condition, linear start condition, duration, and unlock periodClaimScheduleV2ExtensionsStores runtime policy flags and an optional backend claim signerGenesis has no ClaimScheduleBucketV1. Use the V2 account and instruction names for project vesting. A ClaimSchedule is also used by other bucket extensions, so the schedule type alone does not identify a project vesting bucket.Quick StartThe quick start adds a one-year vesting bucket with a 10% cliff and monthly linear unlocks to an initialized but not yet finalized Genesis V2 account.Complete Genesis setup first and reserve the vesting allocation from the base token supply. The sum of all bucket allocations must fit within the Genesis account's total supply.Create a Project Vesting BucketaddClaimScheduleBucketV2 creates the bucket before the Genesis account is finalized.addClaimScheduleBucketV2.ts1import {\n2 addClaimScheduleBucketV2,\n3 createClaimSchedule,\n4 createTimeAbsoluteCondition,\n5 findClaimScheduleBucketV2Pda,\n6 genesis,\n7} from '@metaplex-foundation/genesis'\n8import { keypairIdentity, publicKey } from '@metaplex-foundation/umi'\n9import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n10\n11const umi = createUmi('https://api.mainnet-beta.solana.com').use(genesis())\n12\n13// umi.use(keypairIdentity(yourKeypair))\n14\n15const genesisAccount = publicKey('YOUR_GENESIS_ACCOUNT')\n16const baseMint = publicKey('YOUR_PROJECT_TOKEN_MINT')\n17const recipient = publicKey('VESTING_RECIPIENT')\n18const bucketIndex = 0\n19\n20const [vestingBucket] = findClaimScheduleBucketV2Pda(umi, {\n21 genesisAccount,\n22 bucketIndex,\n23})\n24\n25const DAY = 86_400n\n26const vestingStart = BigInt(Math.floor(Date.now() / 1000)) + 7n * DAY\n27const vestingEnd = vestingStart + 365n * DAY\n28\n29await addClaimScheduleBucketV2(umi, {\n30 genesisAccount,\n31 baseMint,\n32 authority: umi.identity,\n33 recipient,\n34 bucketIndex,\n35 baseTokenAllocation: 100_000_000_000_000n, // 100,000 tokens at 9 decimals\n36 claimStartCondition: createTimeAbsoluteCondition(vestingStart),\n37 claimSchedule: createClaimSchedule({\n38 startTime: vestingStart,\n39 endTime: vestingEnd,\n40 period: 30n * DAY,\n41 cliffTime: vestingStart,\n42 cliffAmountBps: 1_000, // 10%\n43 }),\n44 pausable: true,\n45 cancelable: true,\n46 cancelableByRecipient: false,\n47 transferable: true,\n48 transferableByRecipient: false,\n49 backendSigner: null,\n50 endBehaviors: [],\n51}).sendAndConfirm(umi)\n52\n53console.log('ClaimScheduleBucketV2:', vestingBucket)\nAdd all other distribution buckets, then call finalizeV2 as described in Genesis setup. Finalization is irreversible.Claim Vested Project TokensclaimClaimScheduleV2 transfers every currently vested, unclaimed token to the bucket's stored recipient.claimClaimScheduleV2.ts1import {\n2 claimClaimScheduleV2,\n3 findClaimScheduleBucketV2Pda,\n4 genesis,\n5} from '@metaplex-foundation/genesis'\n6import { keypairIdentity, publicKey } from '@metaplex-foundation/umi'\n7import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n8\n9const umi = createUmi('https://api.mainnet-beta.solana.com').use(genesis())\n10\n11// umi.use(keypairIdentity(yourKeypair))\n12\n13const genesisAccount = publicKey('YOUR_GENESIS_ACCOUNT')\n14const baseMint = publicKey('YOUR_PROJECT_TOKEN_MINT')\n15const recipient = publicKey('VESTING_RECIPIENT')\n16const [vestingBucket] = findClaimScheduleBucketV2Pda(umi, {\n17 genesisAccount,\n18 bucketIndex: 0,\n19})\n20\n21await claimClaimScheduleV2(umi, {\n22 genesisAccount,\n23 bucket: vestingBucket,\n24 baseMint,\n25 recipient,\n26}).sendAndConfirm(umi)\n27\n28// All currently vested, unclaimed tokens are sent to the stored recipient.\nThe payer does not have to be the recipient. The instruction creates the recipient's associated token account when needed and can never redirect tokens to the payer.A claim can return NothingToClaim when no complete vesting period has elapsed since the previous claim. Wait for another period or check the fetched bucket state before sending the transaction.Claim Schedule Vesting MechanicsA claim schedule unlocks the cliff allocation independently from the remaining linear allocation.FieldConstraintEffectstartConditionTimeAbsolute, TimeRelative, or NeverAnchors the linear vesting timelinedurationGreater than zero, no longer than 10 yearsDefines when the linear allocation is fully vestedperiodGreater than zero and no longer than durationMakes linear vesting advance in discrete stepscliffConditionTimeAbsolute, TimeRelative, or NeverUnlocks the cliff independently from the linear schedulecliffAmountBps0 to 10_000Assigns 0% to 100% of the allocation to the cliffFor allocation A and cliff basis points C, the cliff amount is A × C / 10,000. The remaining A - cliffAmount vests linearly in complete period steps over duration.The cliff does not delay the linear schedule automatically. Set startCondition and cliffCondition to the intended timestamps explicitly; either condition may trigger before, during, or after the other.Set the cliff no later than startCondition + duration. A successful claim after linear completion fires the bucket's end condition; a later cliff would then be beyond the frozen effective time and could never become claimable.Claim Gate and Vesting CurveclaimStartCondition gates token withdrawals, while claimSchedule.startCondition controls when the linear allocation accrues.This separation supports schedules that accrue before claims open. For example, vesting can start on an employment date while claimStartCondition prevents withdrawals until a token generation event.TimeAbsolute conditions update themselves when a claim checks them. TimeRelative conditions are passive and require triggerConditionsV2 with each referenced bucket passed as a writable remaining account.triggerConditionsV2.ts1import { genesis, triggerConditionsV2 } from '@metaplex-foundation/genesis'\n2import { keypairIdentity, publicKey } from '@metaplex-foundation/umi'\n3import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n4\n5const umi = createUmi('https://api.mainnet-beta.solana.com').use(genesis())\n6\n7// umi.use(keypairIdentity(yourKeypair))\n8\n9const genesisAccount = publicKey('YOUR_GENESIS_ACCOUNT')\n10const baseMint = publicKey('YOUR_PROJECT_TOKEN_MINT')\n11const vestingBucket = publicKey('CLAIM_SCHEDULE_BUCKET_PDA')\n12const referenceBucket = publicKey('REFERENCE_BUCKET_PDA')\n13\n14await triggerConditionsV2(umi, {\n15 genesisAccount,\n16 bucket: vestingBucket,\n17 baseMint,\n18})\n19 .addRemainingAccounts([\n20 { pubkey: referenceBucket, isSigner: false, isWritable: true },\n21 ])\n22 .sendAndConfirm(umi)\n23\n24// Eligible TimeRelative conditions on the vesting bucket are now triggered.\nRun this permissionless crank after the reference condition is met and before claiming or evaluating the vesting state.Periodic Linear UnlocksThe period field makes the linear allocation unlock in steps rather than continuously.With a 365-day duration and a 30-day period, the linear allocation increases after each complete 30-day period. Any rounding remainder becomes claimable when the full duration ends.Pause-Adjusted Vesting TimePausing a bucket stops vesting time, and resuming shifts the effective timeline by the total paused duration.The bucket records pausedAt and totalSecondsPaused. A cancellation while paused freezes the schedule at pausedAt, so time spent paused cannot increase the vested amount.Project Vesting Runtime ControlsRuntime controls are disabled by default and must be enabled with policy flags when the bucket is created.Policy flagAuthorized roleInstructionResultpausableGenesis authoritysetClaimSchedulePausedStateV2Pauses or resumes vesting accrualcancelableGenesis authoritycancelClaimScheduleBucketV2Freezes vesting at the cancellation timecancelableByRecipientRecipientcancelClaimScheduleBucketV2Lets the recipient freeze vestingtransferableGenesis authoritytransferRecipientClaimScheduleBucketV2Changes the vesting recipienttransferableByRecipientRecipienttransferRecipientClaimScheduleBucketV2Lets the current recipient transfer the allocationEnable only the controls required by the project's vesting agreement. Authority cancellation or recipient transfer rights materially change the guarantees provided to the recipient.Pause and Resume Project VestingsetClaimSchedulePausedStateV2 pauses or resumes a bucket when pausable was enabled at creation.pauseClaimScheduleBucketV2.ts1import {\n2 genesis,\n3 setClaimSchedulePausedStateV2,\n4} from '@metaplex-foundation/genesis'\n5import { keypairIdentity, publicKey } from '@metaplex-foundation/umi'\n6import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n7\n8const umi = createUmi('https://api.mainnet-beta.solana.com').use(genesis())\n9\n10// umi.use(keypairIdentity(yourKeypair))\n11\n12const genesisAccount = publicKey('YOUR_GENESIS_ACCOUNT')\n13const vestingBucket = publicKey('CLAIM_SCHEDULE_BUCKET_PDA')\n14\n15await setClaimSchedulePausedStateV2(umi, {\n16 genesisAccount,\n17 bucket: vestingBucket,\n18 signer: umi.identity,\n19 paused: true,\n20 padding: Array(6).fill(0),\n21}).sendAndConfirm(umi)\n22\n23// Set paused to false and send again to resume vesting.\nSet paused: false to resume. Only the Genesis authority can use this control.Cancel Project VestingcancelClaimScheduleBucketV2 freezes vesting but does not remove tokens that were already vested.cancelClaimScheduleBucketV2.ts1import {\n2 cancelClaimScheduleBucketV2,\n3 genesis,\n4} from '@metaplex-foundation/genesis'\n5import { keypairIdentity, publicKey } from '@metaplex-foundation/umi'\n6import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n7\n8const umi = createUmi('https://api.mainnet-beta.solana.com').use(genesis())\n9\n10// umi.use(keypairIdentity(yourKeypair))\n11\n12const genesisAccount = publicKey('YOUR_GENESIS_ACCOUNT')\n13const vestingBucket = publicKey('CLAIM_SCHEDULE_BUCKET_PDA')\n14\n15await cancelClaimScheduleBucketV2(umi, {\n16 genesisAccount,\n17 bucket: vestingBucket,\n18 signer: umi.identity,\n19 padding: Array(7).fill(0),\n20}).sendAndConfirm(umi)\n21\n22// Vesting is frozen, but the recipient can still claim the vested remainder.\nThe recipient can continue claiming the vested remainder. Unvested tokens stay in Genesis accounting unless a ReallocateBaseTokensOnCancel end behavior is configured and triggered.Transfer the Project Vesting RecipienttransferRecipientClaimScheduleBucketV2 changes the wallet that receives all future claims.transferClaimScheduleRecipientV2.ts1import {\n2 genesis,\n3 transferRecipientClaimScheduleBucketV2,\n4} from '@metaplex-foundation/genesis'\n5import { keypairIdentity, publicKey } from '@metaplex-foundation/umi'\n6import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n7\n8const umi = createUmi('https://api.mainnet-beta.solana.com').use(genesis())\n9\n10// umi.use(keypairIdentity(yourKeypair))\n11\n12const genesisAccount = publicKey('YOUR_GENESIS_ACCOUNT')\n13const vestingBucket = publicKey('CLAIM_SCHEDULE_BUCKET_PDA')\n14\n15await transferRecipientClaimScheduleBucketV2(umi, {\n16 genesisAccount,\n17 bucket: vestingBucket,\n18 signer: umi.identity,\n19 newRecipient: publicKey('NEW_RECIPIENT'),\n20 padding: Array(7).fill(0),\n21}).sendAndConfirm(umi)\n22\n23// Future claims are sent to the new stored recipient.\nThe authorized signer depends on whether transferable or transferableByRecipient was enabled.Reallocating Unvested Tokens After CancellationReallocateBaseTokensOnCancel moves 100% of a canceled bucket's unvested remainder to an UnlockedBucketV2.Configure the behavior before calling finalizeV2, either in addClaimScheduleBucketV2.endBehaviors or with setClaimScheduleBucketV2Behaviors. The Genesis program rejects behavior configuration after finalization.reallocateClaimScheduleOnCancelV2.ts1import {\n2 genesis,\n3 setClaimScheduleBucketV2Behaviors,\n4 triggerBehaviorsV2,\n5} from '@metaplex-foundation/genesis'\n6import { findAssociatedTokenPda, mplToolbox } from '@metaplex-foundation/mpl-toolbox'\n7import { keypairIdentity, publicKey } from '@metaplex-foundation/umi'\n8import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n9\n10const umi = createUmi('https://api.mainnet-beta.solana.com')\n11 .use(mplToolbox())\n12 .use(genesis())\n13\n14// umi.use(keypairIdentity(yourKeypair))\n15\n16const genesisAccount = publicKey('YOUR_GENESIS_ACCOUNT')\n17const baseMint = publicKey('YOUR_PROJECT_TOKEN_MINT')\n18const quoteMint = publicKey('So11111111111111111111111111111111111111112')\n19const vestingBucket = publicKey('CLAIM_SCHEDULE_BUCKET_PDA')\n20const destinationBucket = publicKey('UNLOCKED_BUCKET_PDA')\n21const [destinationQuoteTokenAccount] = findAssociatedTokenPda(umi, {\n22 owner: destinationBucket,\n23 mint: quoteMint,\n24})\n25\n26// Configure before finalizeV2.\n27await setClaimScheduleBucketV2Behaviors(umi, {\n28 genesisAccount,\n29 bucket: vestingBucket,\n30 authority: umi.identity,\n31 padding: Array(3).fill(0),\n32 endBehaviors: [\n33 {\n34 __kind: 'ReallocateBaseTokensOnCancel',\n35 processed: false,\n36 padding: Array(6).fill(0),\n37 destinationBucket,\n38 },\n39 ],\n40}).sendAndConfirm(umi)\n41\n42// Run after finalization and after cancelClaimScheduleBucketV2 ends the bucket.\n43await triggerBehaviorsV2(umi, {\n44 genesisAccount,\n45 primaryBucket: vestingBucket,\n46 baseMint,\n47 quoteMint,\n48})\n49 .addRemainingAccounts([\n50 { pubkey: destinationBucket, isSigner: false, isWritable: true },\n51 {\n52 pubkey: destinationQuoteTokenAccount,\n53 isSigner: false,\n54 isWritable: true,\n55 },\n56 ])\n57 .sendAndConfirm(umi)\n58\n59// The unvested remainder is moved to the destination UnlockedBucketV2 balance.\nThe behavior changes bucket balances, not the original allocation values. It can run only after the claim schedule bucket has ended, and each claim schedule bucket can have at most one cancellation reallocation behavior.Schedules using TimeRelative start or cliff conditions must have those conditions triggered before cancellation reallocation can calculate the vested amount. Run triggerConditionsV2 with the required reference accounts first.Updating Project Vesting Before LaunchupdateClaimScheduleBucketV2 can replace the allocation, schedule, or claim start condition only before finalization and before vesting has begun.The bucket rejects updates with ClaimScheduleUpdateForbidden after any tokens have been claimed, after claimStartCondition is met, or after the linear start or cliff condition is met. A TimeRelative condition in any of those three slots also disables updates immediately because the program cannot verify its referenced bucket during an update. Runtime pause, cancellation, and transfer controls use their dedicated instructions instead of the update instruction.Fetching Project Vesting StatefetchClaimScheduleBucketV2 returns the allocation, claim progress, effective pause state, policies, and end behaviors.fetchClaimScheduleBucketV2.ts1import {\n2 fetchClaimScheduleBucketV2,\n3 findClaimScheduleBucketV2Pda,\n4 genesis,\n5} from '@metaplex-foundation/genesis'\n6import { publicKey } from '@metaplex-foundation/umi'\n7import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n8\n9const umi = createUmi('https://api.mainnet-beta.solana.com').use(genesis())\n10\n11const genesisAccount = publicKey('YOUR_GENESIS_ACCOUNT')\n12const [vestingBucket] = findClaimScheduleBucketV2Pda(umi, {\n13 genesisAccount,\n14 bucketIndex: 0,\n15})\n16\n17const account = await fetchClaimScheduleBucketV2(umi, vestingBucket)\n18\n19console.log('Recipient:', account.recipient)\n20console.log('Allocation:', account.bucket.baseTokenAllocation)\n21console.log('Remaining balance:', account.bucket.baseTokenBalance)\n22console.log('Claimed:', account.amountClaimed)\n23console.log('Paused:', account.paused)\n24console.log('Total seconds paused:', account.totalSecondsPaused)\nThe accounting invariant is baseTokenBalance = baseTokenAllocation - amountClaimed until an end behavior reallocates an unvested balance.ClaimScheduleBucketV2 Account FieldsThe ClaimScheduleBucketV2 account stores fixed vesting state followed by a variable-length list of end behaviors.FieldDescriptionbucketShared bucket header containing allocation, remaining balance, mints, index, and fee datarecipientWallet that receives every vested token claimamountClaimedCumulative tokens transferred to the recipientclaimScheduleCliff and period-based linear vesting curveclaimStartConditionIndependent gate that must open before claimsclaimEndConditionProgram-owned end condition fired by cancellation or natural completionpausedWhether vesting time is currently stoppedpausedAtTimestamp at which the current pause begantotalSecondsPausedAccumulated pause duration excluded from vestingextensionsRuntime policies and optional backend signerendBehaviorsActions available after the bucket endsCommon Project Vesting ErrorsClaim schedule errors identify invalid schedule configuration, unauthorized controls, or actions attempted at the wrong lifecycle stage.ErrorCauseResolutionInvalidClaimSchedulePeriodperiod is zeroUse a positive periodInvalidClaimScheduleDurationduration is zero or over 10 yearsUse a duration from 1 second through 315,360,000 secondsClaimScheduleDurationTooShortperiod exceeds durationReduce the period or increase the durationInvalidClaimScheduleCliffAmountcliffAmountBps exceeds 10_000Use 0 to 10,000 basis pointsNothingToClaimNo new cliff or complete linear period has vestedWait for the next unlock or inspect bucket stateClaimScheduleUpdateForbiddenThe claim gate or schedule has begun, tokens were claimed, or a relevant condition is TimeRelativeConfigure absolute-time fields before they trigger; relative schedules cannot be updatedClaimScheduleUnauthorizedThe signer is not allowed to use the controlUse the Genesis authority or recipient required by the enabled policyClaimSchedulePolicyDisabledThe requested pause, cancel, or transfer policy is offEnable the policy when creating the bucketInvalidBackendSignerA configured backend signer did not authorize the claimInclude the configured backend signerClaimScheduleConditionNotTriggeredCancellation reallocation depends on unresolved relative conditionsTrigger the relative schedule conditions firstQuick ReferenceProject vesting is available through Genesis V2 and @metaplex-foundation/genesis.ItemValueProgramGNS1S5J5AspKXgpjz6SvKL66kPaKWAhaGRhCqPRxii2BTested SDK@metaplex-foundation/genesis@0.41.1Tested Umi compatibility@metaplex-foundation/umi@^1.4.1Bucket PDA seeds\"claim_schedule_v2\", Genesis account, bucketIndex as u8Maximum vesting duration315,360,000 seconds (10 years)Cliff range0 to 10,000 basis pointsRecipients per bucketOneBucket creation fee0Devnet validationFull add, finalize, pause, transfer, claim, cancel, and reallocation flow passed on 2026-08-24 (test account)Sourcemetaplex-foundation/genesisNotesProject vesting has lifecycle and authorization constraints that should be included in the project's token distribution design.Add and configure ClaimScheduleBucketV2 accounts before calling finalizeV2.Create one bucket per recipient or independently managed allocation.Claims are permissionless unless the optional backend signer extension is configured.A backend signer adds claim authorization but cannot redirect a claim away from the current stored recipient.Cancellation preserves vested tokens; reclaiming unvested tokens requires ReallocateBaseTokensOnCancel.A Never schedule permanently locks tokens and is primarily used for locked LP tokens.FAQWhat is the difference between ClaimScheduleBucketV2 and ClaimSchedule?ClaimScheduleBucketV2 is a Genesis outflow bucket that holds one recipient's allocation and runtime state. ClaimSchedule is the reusable cliff and linear unlock curve stored inside that bucket.Does the vesting recipient have to submit each claim?No. claimClaimScheduleV2 is permissionless, but the program always transfers tokens to the recipient stored on the bucket. If a backend signer extension is configured, that signer must also authorize each claim.Can a project change a vesting schedule after vesting begins?No. updateClaimScheduleBucketV2 works only before finalization, before the claim gate or either schedule condition is met, and before any claim. A TimeRelative claim gate, linear start, or cliff also disables updates immediately.What happens to unvested tokens when a vesting bucket is canceled?Cancellation freezes vesting and preserves any vested amount for the recipient. If the bucket has a ReallocateBaseTokensOnCancel behavior, anyone can trigger that behavior to move the unvested remainder to an UnlockedBucketV2.Can one ClaimScheduleBucketV2 vest tokens to multiple recipients?No. Each bucket has one recipient. Create one ClaimScheduleBucketV2 for each recipient or allocation that needs independent accounting or policy controls.GlossaryProject vesting terminology distinguishes the bucket account, its embedded schedule, and its lifecycle controls.TermDefinitionClaimScheduleBucketV2A Genesis outflow bucket that vests one base token allocation to one recipientClaimScheduleA reusable cliff and period-based linear token unlock curveClaim gateThe bucket-level claimStartCondition that controls when withdrawals may beginCliffA percentage of the total allocation unlocked when an independent condition triggersPeriodThe interval used to advance linear vesting in discrete stepsEffective timeWall-clock time adjusted to exclude the bucket's paused durationCancellation reallocationAn end behavior that moves a canceled bucket's unvested remainder to an unlocked bucket","tokens":5679,"squid":"dotcat","role":"Tooling Spider","at":1791347138650,"hash":"eac3df7653778ca41ed42fec62657c813cc1ad95"}
{"url":"https://developer.arbitrum.io/arbitrum-essentials/nodeinterface/reference","domain":"developer.arbitrum.io","title":"NodeInterface reference","text":"NodeInterfaceNodeInterface referenceComplete API reference for Arbitrum's NodeInterface contract methods, including gas estimation, retryable ticket helpers, and outbox proof construction. Available at address 0xc8 via RPC calls only.Request an updateThe Arbitrum Nitro software includes a special NodeInterface contract available at address 0xc8 that is only accessible via RPCs (it's not actually deployed onchain, and thus can't be called by smart contracts). This reference page documents the specific calls available in the NodeInterface. For a more conceptual description of what it is and how it works, please refer to the NodeInterface conceptual page.\nNodeInterface methods\nMethodSolidity interfaceGo implementationDescriptionestimateRetryableTicket(address sender, uint256 deposit, address to, uint256 l2CallValue, address excessFeeRefundAddress, address callValueRefundAddress, bytes calldata data)InterfaceImplementationEstimates the gas needed for a retryable submissionconstructOutboxProof(uint64 size, uint64 leaf)InterfaceImplementationConstructs an outbox proof of an l2->l1 send's existence in the outbox accumulatorfindBatchContainingBlock(uint64 blockNum)InterfaceImplementationFinds the L1 batch containing a requested L2 block, reverting if none doesgetL1Confirmations(bytes32 blockHash)InterfaceImplementationGets the number of L1 confirmations of the sequencer batch producing the requested L2 blockgasEstimateComponents(address to, bool contractCreation, bytes calldata data)InterfaceImplementationSame as native gas estimation, but with additional info on the l1 costsgasEstimateL1Component(address to, bool contractCreation, bytes calldata data)InterfaceImplementationEstimates a transaction's l1 costslegacyLookupMessageBatchProof(uint256 batchNum, uint64 index)InterfaceImplementationReturns the proof necessary to redeem a messagenitroGenesisBlock()InterfaceImplementationReturns the first block produced using the Nitro codebaseblockL1Num(uint64 l2BlockNum)InterfaceImplementationReturns the L1 block number of the L2 blockl2BlockRangeForL1(uint64 blockNum)InterfaceImplementationFinds the L2 block number range that has the given L1 block numberHow is this guide?OverviewOverview of Arbitrum's NodeInterface, a virtual contract at address 0xc8 accessible only via RPCs. Provides gas estimation, proof construction, and other node-level utilities not available onchain.ReferenceChain parameters, contract addresses, RPC providers, and developer tooling.","tokens":621,"squid":"spider-01","role":"Chain Spider","at":1791347139384,"hash":"d1bbb0bc859a0cd1b5d8a527b8e6c4723a6f443a"}
{"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":"spider-08","role":"Oracle Spider","at":1791347147172,"hash":"eec62b67925e725051ab595ae2eb4c33b5415370"}
{"url":"https://developer.arbitrum.io/arbitrum-essentials/nodeinterface/overview","domain":"developer.arbitrum.io","title":"NodeInterface overview","text":"NodeInterfaceNodeInterface overviewOverview of Arbitrum's NodeInterface, a virtual contract at address 0xc8 accessible only via RPCs. Provides gas estimation, proof construction, and other node-level utilities not available onchain.Request an updateThe Arbitrum Nitro software includes a special NodeInterface contract available at address 0xc8 that is only accessible via RPCs (it's not actually deployed onchain and thus can't be called by smart contracts). The way it works is that the node uses Geth's InterceptRPCMessage hook to detect messages sent to the address 0xc8, and swaps out the message it's handling before deriving a transaction from it.\nThe reference page contains information about all methods available in the NodeInterface.How is this guide?NodeInterfaceQuery gas estimates and chain data through the NodeInterface.ReferenceComplete API reference for Arbitrum's NodeInterface contract methods, including gas estimation, retryable ticket helpers, and outbox proof construction. Available at address 0xc8 via RPC calls only.","tokens":261,"squid":"spider-01","role":"Chain Spider","at":1791347152408,"hash":"9790c6d37496bf91a643a78012510d6571e9d8e8"}
{"url":"https://www.metaplex.com/docs/smart-contracts/genesis/bonding-curve","domain":"metaplex.com","title":"Genesis Bonding Curve Overview | Metaplex","text":"Genesis Bonding Curve is a constant product AMM that continuously prices a token supply until it sells out, then graduates into a Raydium CPMM pool. SummaryA bonding curve launch gives every user the ability to buy and sell at any time after the swap window opens. Price rises as SOL flows in and falls as tokens are sold back — determined entirely by the constant product formula.Continuous trading — no fixed deposit window; buy and sell at any time while the curve is activeDeterministic pricing — price is always calculable from the current reserve state; no batch settlementAutomatic graduation — when all tokens sell out, accumulated SOL migrates to a Raydium CPMM pool automaticallyOptional creator fee — per-swap fee earned on the curve and in the post-graduation Raydium pool; see Creator FeesOptional first buy — fee-free initial purchase reserved for the launching wallet at curve creationLifecyclePhaseDescriptionCreatedCurve initialized with reserves, fees, and start time. Trading not yet open.ActiveSwap window open. Users buy and sell freely; price moves with every trade.GraduatedAll tokens sold. Accumulated SOL migrated to Raydium CPMM. Curve account closed.Graduation is triggered automatically by full token exhaustion — there is no timer or manual step.How It Differs from Other Launch TypesBonding CurveLaunch PoolPresalePrice discoveryContinuous, per-tradeBatch at window closeFixedTrading windowOpen until sold outFixed durationFixed durationSell backYes, at any timeNoNoGraduationOn sell-outAt window closeAt window closeWhich Guide Do You Need?GoalGuideLaunch a token via the APILaunch via APIConfigure and claim creator feesCreator FeesIntegrate swaps into an app or protocolSwap IntegrationIndex events and track price onchainIndexing & EventsUnderstand the AMM pricing modelTheory of OperationDeep-dive into formulas and account structureAdvanced InternalsNotesA bonding curve has no fixed end time — graduation is triggered by supply exhaustion, not a timerUnlike a launch pool or presale, users can sell tokens back to the curve at any time while it is activeThe protocol swap fee is set by Metaplex and is not configurable by creators; see Protocol Fees for current ratesCreator fees are accrued in the bucket and collected via the permissionless claimBondingCurveCreatorFeeV2 instruction; see Creator Fees for configuration and claimingFAQWhat is the difference between a bonding curve and a launch pool?A launch pool collects deposits during a fixed window and settles everyone at the same clearing price at the end. A bonding curve has no window — users trade immediately after the swap start time, and price updates with every single trade.When does graduation happen?Graduation fires automatically the instant baseTokenBalance reaches zero — the last buy that exhausts the supply also triggers the graduation process. The accumulated real SOL is migrated into a Raydium CPMM pool. No separate instruction or crank is required.Do I need to understand the AMM math to launch a token?No. createAndRegisterLaunch in the Launch via API guide handles the full flow in one SDK call. The Theory of Operation page is for integrators building swap UIs, pricing engines, or protocol tooling.","tokens":805,"squid":"dotcat","role":"Tooling Spider","at":1791347158660,"hash":"70cce36cca603065c0a5a00834dea7046b59ba70"}
{"url":"https://developer.arbitrum.io/arbitrum-essentials/arbitrum-vs-ethereum/rpc-methods","domain":"developer.arbitrum.io","title":"RPC methods","text":"Arbitrum vs EthereumRPC methodsCompare Arbitrum and Ethereum RPC method responses, including additional transaction types, fields, and blocks returned by Arbitrum nodes. Covers eth_getTransactionByHash, eth_getBlockByHash, and other JSON-RPC methods.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.\nNoteComprehensive 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\nNoteNote 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.\nNoteThe 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 \\\n -X POST \\\n -H \"Content-Type: application/json\" \\\n -d '{\"jsonrpc\":\"2.0\",\"method\":\"debug_traceTransaction\",\"params\":[\"<transaction-hash>\", {\"tracer\": \"stylusTracer\"}],\"id\":1}' \\\n <nitro-node-rpc>\nThe result of this call will be something along the lines of:\n{\n \"jsonrpc\": \"2.0\",\n \"id\": 1,\n \"result\": [\n {\n \"args\": \"0x00000024\",\n \"endInk\": 116090000,\n \"name\": \"user_entrypoint\",\n \"outs\": \"0x\",\n \"startInk\": 116090000\n },\n {\n \"args\": \"0x\",\n \"endInk\": 116057558,\n \"name\": \"msg_reentrant\",\n \"outs\": \"0x00000000\",\n \"startInk\": 116065958\n },\n {\n \"args\": \"0x\",\n \"endInk\": 115937952,\n \"name\": \"read_args\",\n \"outs\": \"0x6c5283490000000000000000000000003bdff922e18bc03f1cf7b2a8b65a070cbec944f2\",\n \"startInk\": 115951512\n },\n ...\n ]\n}\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 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 validator reads in chunks of 5,000 via --node.bold.max-get-log-blocks. Those are Nitro acting as a 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.How is this guide?Block gas limit, numbers and timeUnderstand how Arbitrum handles block gas limits, block numbers, and transaction timing differently from Ethereum. Learn about parent chain gas components and block.number behavior on Arbitrum.Solidity supportLearn how Solidity behaves differently on Arbitrum compared to Ethereum, including blockhash, block.coinbase, block.number, msg.sender, and other EVM opcode differences for smart contract developers.","tokens":3095,"squid":"spider-01","role":"Chain Spider","at":1791347161722,"hash":"565b9d50dcd037ed87f8ae526cef12c0c5cc2dd9"}
{"url":"https://forum.across.to/t/acx-portal-update/2132","domain":"forum.across.to","title":"$ACX Portal Update - Updates - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n $ACX Portal Update \n\n Updates\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jun 30\n\n 1 / 2\n\n Jun 30\n\n Jun 30\n\n post by risklabs on Jun 30\n\n risklabs\n\n We wanted to provide an update on the timeline for the $ACX exchange and buyout process following the passing of the Snapshot proposal.\nOur initial estimate was that $ACX holders would be able to exchange $ACX for equity or sell $ACX for cash via the $ACX Exchange Portal by July 3, 2026. We now expect the $ACX Exchange portal to go live later than initially anticipated, most likely later in July.\nThe remaining work is primarily legal and operational in nature. We believe it is important to complete that diligence carefully rather than rush the launch.\nWe will continue to keep $ACX holders informed as we finalize the remaining steps and will share further details ahead of the portal going live.\nThank you for your patience as we finalize details..\n\n Pinned globally on Jun 30\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n The Bridge Across - August Update\n\n Updates\n\n Updates\n\n Aug 5\n\n The Across token buyout portal is now live\n\n Updates\n\n Updates\n\n 19d\n\n The Bridge Across\n\n Proposals\n\n governance-updates\n\n Pinned\n\n Proposals\n\n 39\n\n Apr 25\n\n $ACX Liquidity - Update and Feedback Wanted\n\n Ideas & Feedback\n\n Ideas & Feedback\n\n 7\n\n Jun 2023\n\n Across ($ACX) Community Initial Liquidity Proposal\n\n Passed Proposals\n\n Passed Proposals\n\n 49\n\n Nov 2022","tokens":1857,"squid":"spider-09","role":"Bridge Spider","at":1791347170616,"hash":"1a0ea1be0efbf5d5b085babc603eaee08a420b23"}
{"url":"https://akash.network/docs/developers/deployment/akt/","domain":"akash.network","title":"akt CLI | Akash Network - Your Guide to Decentralized Cloud","text":"akt CLI Use akt to deploy workloads, query the chain, operate provider leases, and work with the Akash Console managed wallet.\nThis documentation covers release candidate akt v1.0.0-rc0. Run akt version to check your installed version.\nakt replaces the CLI functionality previously spread across akash, provider-services, and the chain SDK CLI with a single binary. It adds named contexts for managing multiple networks and accounts, offline SDL authoring, built-in deployment workflows, Akash Console managed-wallet integration, and real-time network monitoring.\n\nWhy akt\n\nOne binary - Chain queries, transactions, deployment workflows, provider operations, and monitoring in a single tool.\nFlag-minimal operation - After initial context configuration, most commands require zero additional flags.\nTwo deployment rails - Sign transactions locally with your own keys, or route through the Akash Console managed wallet with no local keys at all.\nPositional arguments - Commands take their primary values positionally, following the Akash resource hierarchy (owner/dseq/gseq/oseq/provider).\n\nTerminal window# State keyword, identity + state, dseq, and a date range: all positionalakt query deployment activeakt query deployment akash1abc.../12345 closedakt tx deployment close 12345akt console usage 2026-01-01 2026-01-31\nCheck akt on GitHub for the most up-to-date code and GitHub Releases for the latest stable version. Homebrew installation installs the latest stable release. Use the archive instructions to install the release candidate. Run akt version --long to check your binary and akt <command> --help for its supported syntax; code on GitHub may be ahead of a published release.\n\nIn This Section\nInstallation\nInstall the akt binary, run the first-time setup, and enable shell completion.\nContexts & Configuration\nConfigure contexts, networks, keys, and environment variables.\nDeployments\nAuthor SDL files and run the full deployment lifecycle with akt deploy, akt update, and akt close.\nConsole Integration\nDeploy with the Akash Console managed wallet and account credits.\nQueries & Transactions\nQuery the chain and submit transactions for every Akash and Cosmos SDK module.\nNetwork Monitor\nWatch consensus, provider fleet health, and Oracle/BME state in real time with akt monitor.\nAgent Skill\nGive your coding agent the akt CLI skill. Download the complete bundle, read its reference guides, and install it in your project or agent’s skills directory.\nMCP Server\nExpose Akash tools to AI assistants over the Model Context Protocol.\nCommands Reference\nReference for akt command groups, common arguments, and flags.\n\nQuick Links\n\nakt on GitHub - Source code, releases, and issue tracker\nSDL Reference - Deployment configuration syntax\nManaged Wallet API - The Console API behind akt console\nDiscord Support - Get help in the #developers channel\n\nStart with the installation guide. \nEdit page on github\n Getting Started Installation","tokens":735,"squid":"spider-03","role":"Compute Spider","at":1791347176680,"hash":"20a7b2635bf034ba0fccf27b56d6ef195ea91fe0"}
{"url":"https://forum.across.to/t/the-bridge-across/2097","domain":"forum.across.to","title":"The Bridge Across - Proposals - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n The Bridge Across \n\n Proposals\n\n governance-updates\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Mar 11\n\n 1 / 41\n\n Mar 10\n\n Apr 25\n\n post by risklabs on Mar 11\n\n risklabs\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n post by hart_UMA on Mar 11\n\n hart_UMA\n\n I posted my personal thoughts on this proposal and my views on what’s next for Across in this X post.\n\n post by berry4144 on Mar 11\n\n berry4144\n\n As CT heavyweight CMS says:\n“Do you want to be right, or do you want to make money”.\nSo called Internet Capital Markets have seen valuations crushed, with regulations getting in the way of passing equity like value to token holders.\nToken prices going down retards the ability of a project to operate, which forces it into a death spiral.\nEquity, especially privately held equity, would be far more stable and allow direct benefit to holders.\nTo make an informed choice people need to know the full governance arrangements (shareholder rights) and if there is any dividend policy. Even with terrible terms its probably a good move (voicing opinion to approve).\nIs there a limit to how much can be moved through the sale options vs the conversion option?\n\n post by hart_UMA on Mar 11\n\n hart_UMA\n\nYes this will be made available to any token holders that are seriously considering the exchange. This proposal is just a temperature check, so these docs have not been drafted yet. One thing that’s important to note is that ALL tokens will convert to the same class of shares—everyone would get the same dividend policy, etc.\n\nNo limits here. Token holders are free to choose to exchange for shares or sell for USDC.\n\n post by hash_error on Mar 11\n\n hash_error\n\n Proformas for potential new OpCo?\nThis proposal implies a business case has been developed to determine the path to privatization of the DAO makes financial sense for $ACX token holders.\nDAO has generated no revenue in protocols existence (exception being the work of AUVC).\nHow is an $ACX token holder to assess this proposal with no visibility into last 4 years of revenue, expense, ip assets, ip value, etc.?\n\n post by hart_UMA on Mar 11\n\n hart_UMA\n\n Yeah, remember that this is just a proposal. None of the structuring work has begun yet.\nToken holders interested in the token-to-equity conversion will be given a disclosure package (if this proposal moves forward).\nIn terms of IP and its value, Across has been fully built in public. All our IP is out there for the public to see. And in terms of revenue, the protocol has generated tens of millions of bridging fees paid by users to the solver network.\n\n post by hash_error on Mar 11\n\n hash_error\n\n Based on potential new org structure, the proposal limits participation to accredited investors only for US residents. That presumably leaves buyout as only option for many.\nIf this proceeds, who’s funding the buyout and how is the buyout valuation being calculated?\nWhat valuations where used a number of years ago when raises were done that granted some parties ACX options and RL operating capital?\nOne would hope, after the years of RL creating value while $ACX token holders experienced a 98% drawdown from 2024 highs, that those token holders who would have no choice but to take buyout are offered a proper exit.\n\n post by withdrawall on Mar 12\n\n withdrawall\n\n How will this private equity be facilitated in trading? Will it be tokenized? What are the future plans?\n\n post by James.eth on Mar 12\n\n James.eth\n\n _​ (Fire Eyes) has been collaborating with Risk Labs on a potential path forward for ACX. Fire Eyes is one of the most token-aligned organisations on earth, contributing to the launch of many of Ethereum largest tokens and DAOs.\nWe’re strong believers in the idea that tokens unlock permissionless ownership and contribution. However, they also come with clear hurdles as the industry starts to integrate with a more institutional world - The proposed outcome would give ACX holders a choice alongside the Across team to double down on the protocol, product and roadmap.\nAcross is uniquely positioned as a protocol: delivering objective value to the industry on a number of fronts, with over $35 billion in bridge volume and over 4 million unique wallets interacting with the Across protocol over the past 3+ years. Over this same timeframe, the token landscape has continued to change and ACX has been overlooked by the market. Now as Across moves towards providing more bespoke, institutional facing products and services, operating as a token and DAO backed protocol has added complexity rather than being a driver of growth.\nThere are clearly tradeoffs for any proposal of this nature, however the most important part from our perspective is the inclusive nature of this proposal; Where ACX holders have meaningful optionality to continue to align, both financially and philosophically, with the Risk Labs team. This has never been a option for token holders\nThis type of proposal certainly isn’t a catch all solution for token projects; We want to see this framing and mechanism emerge as one of many responsible paths that protocols can take in order to preserve token holder interests and drive growth into legacy financial systems.\nFire Eyes has been a ACX holder since launch, has contributed to this proposal’s development alongside Risk Labs and is supportive of this initiative.\n\n post by walodja1987 on Mar 12\n\n walodja1987\n\n Hi there,\nI have a few questions:\n\nWhat are the implications for non-US investors? Will they be eligible? What will be the tax implications?\n\nIt looks like that only holders of at least 250k tokens will be able to participate in the token-to-equity transaction. So for anyone else this basically means that the only option will be selling on the market or participating in the token buyback,\n\nWhy not simply treat the token as equity on-chain? Or convert it into a non-tradeable token.\nMuch simpler for everyone. Doesn’t matter where the token instrument is registered. In a spread sheet or a blockchain. Latter is just easier as it’s already on the blockchain. And I think showing that equity can be on-chain would send a strong signal to the market.\n\n post by TheRealTuna_Across on Mar 13\n\n TheRealTuna_Across\n\n This sounds like an interesting idea, but I’m not in a position to participate without borrowing against personal assets. I can’t justify taking on that kind of risk, especially when my experience over the past five years has been a significant loss in value despite the clear success of both Across and UMA. I feel deeply attached to Risk Labs’ products, but I struggle to understand why those successes have never translated into meaningful benefits for token holders. What will make this outcome different?\nHash-error also raised an important point on Discord: where is the $25M for the buyout coming from? Did the DAO have access to $25M that was not previously disclosed? If so, that’s concerning, particularly if those funds could have been deployed to strengthen Across as a DAO. It also raises questions about capital allocation, spending $25M to buy out the DAO and then potentially raising $50–100M+ for Risk Labs through equity shortly afterward.\nI’m also curious why the existing token cannot be structured or treated as equity, as has been suggested above.\nWhile this is framed as a proposal seeking community feedback, it appears that preparations are already underway, including requests to return PoolTogether funds used for the relayer by a March 26 deadline. That timeline makes it feel as though the decision may already be settled.\nAs a long-term Across/UMA community member, I’ve always hoped to share in the upside of Risk Labs’ success. And there has been extraordinary success: Polymarket’s transformation into a mainstream prediction market featured in major media(i used Polymarket personally to track election results and was thrilled to see it featured on South Park), Across becoming integrated into Uniswap and recognized as one of the fastest bridges, and continued ecosystem growth. If someone had described this trajectory five years ago, I would have assumed it would lead to substantial value creation for supporters like myself. Instead, I’m down roughly 98% and now face the prospect of being bought out rather than included in future upside. That’s a tough pill to swallow.\n\n post by Bananachain on Mar 13\n\n Bananachain\n\n Interesting proposal, it came a bit as a surprise yesterday and, I must say, feels somewhat uncomfortable at this point in time. I sat down, thought it through, and tried to incorporate the contributions that had already been made. I also used a “Friend” to help clean this up and enhance readability:\nAfter reviewing discussions across multiple threads and the proposed AcrossCorp structure, it’s clear the idea of transitioning the protocol into a U.S. C-corp has practical motivations, especially around legal clarity and institutional partnerships. At the same time, several points remain unclear, and more information is needed before a vote:\n\nDAO governance & community role – What influence will remain on treasury and protocol decisions? How will smaller holders retain a meaningful voice?\n\nMinimum conversion threshold – The proposed 250k ACX minimum (~$10k) could exclude smaller and long-term holders from meaningful equity participation. Alternative mechanisms, such as pooled participation vehicles (similar to models used by investment syndicates), could help address this.\n\nEconomic transparency – Share classes, rights, and potential dilution need clarification.\n\nLegal & international participation – Taxation, liability, and investor status questions remain.\n\nProcess & timing – Community input currently feels more procedural than substantive; transparency and discussion will be key.\n\nOverall, the proposal is worth exploring, but clarifying the DAO’s role, protecting long-term holders, providing transparency, and considering inclusive participation structures will strengthen trust and alignment.\nI have also prepared a short paper with more extended thoughts for those interested, including suggestions such as hybrid or pooled participation mechanisms, and a more detailed discussion of economic, legal, and governance considerations ,see:[link to long document].\n\n post by elpetron on Mar 13\n\n elpetron\n\n Hello to all.\nDAO to Corporate transition is something I have been thinking for some time. I believe that token structures don’t serve the token holders, the founders, and investors, as there is no way to ensure rights and obligations enforcement. A good recent example is the Aave debacle.\nThe past 5 months I have been building an equity tokenisation layer, with compliance and rights enforcement baked in.\nThis case would be a perfect first to prove that blockchain can enable fair enforceable corporate structures.\nIf this proposal passes, I’d like to offer the infrastructure to help Across transition to a corporate form while remaining on-chain, for both US and non-US shareholders.\nHappy to hear feedback and ideas. I won’t link the project here yet to keep the conversation focused, but happy to share more.\n\n post by Bananachain on Mar 13\n\n Bananachain\n\n I would be interested to know more of your project. DM me if you don’t want to share here. But strictly speaking this is supposed to be a temp check only here, depending on the outcome the process would continue , or not - so the theory \n\n post by elpetron on Mar 13\n\n elpetron\n\n Thank you, I will!\nI understand, and maybe I didn’t get my point across well \nI believe it’s a net positive for everyone involved to move to an equity based model, as it enforces the rights and obligations of all parties and open new paths of cooperation with the traditional financial system.\nI am supportive of this motion. We have all the tools to ensure fair shareholder participation and translate teachings from DAOs to modernise Corporations. \n\n post by Bananachain on Mar 14\n\n Bananachain\n\n Sure, moving to a corporate structure can be an option, and exploring other avenues makes sense, hence my paper. That said, the proposal currently provides very little meaningful information for many members, yet seems to expect a blank check.\nIt is the text in the proposal that counts, not a reassuring X tweet hinting at possible adjustments later. The proposed squeeze-out at near-market lows is the easiest and cheapest path for the initiators. If 10k USD is indeed a regulatory threshold, then many members may not meet it simply because the transition is happening now. Previously, this would not have been as much of an issue for most. These are the frictions that arise when transitioning from a crypto-native to a fiat-based system, so timing matters. It is also worth noting that token value is tied to the current market price, which may not fully reflect its underlying value. A careful assessment of real value could help ensure a fair conversion, for example by taking the higher of market price or evaluated value, protecting participants from exiting at artificially depressed levels. Mechanisms such as a Syndicate system, which I mentioned in my paper, could complement this approach to help smaller holders participate more effectively.\nClaims that regulatory constraints prevented Across from thriving are hard to assess. How, for example, do Solana or Ethereum manage similar challenges? As @TheRealTuna_Across so nicely noted: “What will make this outcome different?” No one can say for sure, of course. As a spin-off from RL’s books, AcrossCorp could attract its own VC investment, which would almost certainly dilute other participants unless appropriate safeguards exist. RL’s ongoing role and long-term commitment beyond stated claims also remain unclear.\nMany discussions have likely already taken place behind the scenes. The tight timeline suggests the process may now be mostly about execution, particularly seeing contributors like Hart actively engaging, while the broader community is not privy to those conversations.\n\n post by hart_UMA on Mar 17\n\n hart_UMA\n\n Appreciate the engagement from the community. These are exactly the kinds of questions a temp check is designed to surface. I want to address a few recurring themes together rather than go point-by-point.\nOn process and timing\nTo be really clear again: this proposal is just a temperature check. We’re here to discuss, hear concerns, and determine whether the community wants to move forward. No structuring work has begun. No decisions have been made. Suggesting that decisions were made behind closed doors runs counter to what is literally happening right now!\nNote: Risk Labs is hosting a community call on March 19th, as discussed in the proposal.\nOn the buyout funding\nThis is stated directly in the proposal: “Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.” The treasury is the source of buyout funding!\nOn treating the token as equity\nI understand why this sounds appealing. But unfortunately a token can’t just be “treated as” equity. I wish it could.\nIf a token confers equity-like rights (dividends, governance over a corporate entity, claims on assets), it becomes a security under U.S. law. And if that security is freely tradeable on public markets, you need SEC registration, audited financials, annual disclosures, and an entire regulatory infrastructure that doesn’t exist today. The whole point of this proposal is to create a clean, legally sound structure that gives holders the option to exchange tokens for equity, and gives holders the benefits (i.e. investor protections) that equity confers.\nPlease keep the questions coming. That’s what this period is for.\n\n post by TheRealTuna_Across on Mar 17\n\n TheRealTuna_Across\n\n The biggest problem here is that many of your biggest supporters are excluded from participation. $10,000 USD only includes your top 106 holders, many of which are exchanges, whales, and team members. Is there anything that can be done to not exclude people such as myself from equity in the Across company?\n\nIf you use your power to exclude all these smaller holders and force us to sell for USD, it seems you are giving yourselves a pretty good deal! You get to absorb the value of all the uncirculated tokens and share it amongst those at the top.\n\n post by Bananachain on Mar 18\n\n Bananachain\n\n Some things need to be brainstormed behind closed doors first - nothing wrong with that.\nIt would be helpful to know more about the valuation assumptions and where you see Across positioned and its growth potential, e.g. turning on the fee switch and retain ≥80% of volume. That may also help to understand what the success of incorporation may be. If I understand correctly you currently value AcrossCorp at 40 mil. USD (~1 bill. token *~0.04 USD).\nWe are all here because we are interested in making Across a success - and where feasible join along the ride.\n\n post by hash_error on Mar 18\n\n hash_error\n\n hart_UMA\n\n Regarding the following.\n\nOn the buyout funding\nThis is stated directly in the proposal: “Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.” The treasury is the source of buyout funding!\n\nPlease provide Across DAO addresses containing the liquid assets.\n\n Load more posts below","tokens":7275,"squid":"spider-09","role":"Bridge Spider","at":1791347192755,"hash":"f0f8076c09367ed431660d58b83c7d33a40b2a5c"}
{"url":"https://akash.network/docs/developers/deployment/akash-console/","domain":"akash.network","title":"Akash Console | Akash Network - Your Guide to Decentralized Cloud","text":"Akash Console Deploy and manage applications on Akash Network using the web-based Akash Console.\nAkash Console (console.akash.network) is a visual web interface for deploying on Akash without CLI tools. Deploy with a free trial or pay-as-you-go credit-card billing — no crypto wallet required.\n\n Looking for self-custody? Akash Console is the managed product. If you want to bring your own Keplr wallet, sign your own transactions, or self-host the UI, use Console Air — walk through your first deploy in Deploy with Console Air, or see Choosing Your Console for a side-by-side comparison.\n\nGetting Started\nGetting Started with Console\nLearn the basics of Akash Console, including:\n\nConsole interface and features\nVisual SDL builder\nDeployment dashboard\nCommon tasks and workflows\nConsole vs CLI comparison\n\nStart here if you’re new to Akash Console.\n\nDeployment Options\nManaged Wallet API\nProgrammatic deployments using the Console API:\n\nREST API for automated deployments\nJWT authentication\nPay with credit card\nNo wallet management required\n\nUse this for automated deployments via API.\n\nQuick Links\nNew to Akash?\n→ Free Trial Quick Start - Deploy in 10 minutes with $1 free credits\nNeed Examples?\n→ SDL Examples Library - 290+ deployment templates\nNeed Help?\n→ Discord (#developers) | Support \nEdit page on github\n Mint & Burn ACT Getting Started","tokens":337,"squid":"spider-03","role":"Compute Spider","at":1791347198395,"hash":"ddb72fc2189ba54388f66a0429b43e73e391d368"}
{"url":"https://akash.network/docs/developers/deployment/akt/console/","domain":"akash.network","title":"Akash Console Integration | Akash Network - Your Guide to Decentralized Cloud","text":"Akash Console Integration Deploy on Akash from the CLI without managing keys or buying AKT.\nContexts with the console-api auth method route deployment operations through the Akash Console Managed Wallet API. The Console backend handles signing and broadcasting, deposits are in USD, and no local keys are needed.\nThe Console API key is the identity for this context. A local keyring and default-account are intentionally optional.\n\nSet Up a Console Context\nCreate a console-api context and store your API key:\nTerminal window# Set up a console-api contextakt context create console --network mainnet --auth-method console-api --set-current\n# Validate and store your API key as the context credentialakt console login\n# Or supply it positionally in a non-interactive shellakt console login akt_your_key\nCreate the API key in Akash Console under Settings > API Keys. akt console login validates the key, then writes it to contexts/<name>/console-api-key (mode 0600); it is never written to config.yaml and never printed.\nThe key resolves in this order: --console-api-key flag > AKT_CONSOLE_API_KEY environment variable > per-context stored credential. Switching context switches Console identity.\nYou can also store or replace the key with akt context edit <context> --console-api-key <key>. An empty string removes it.\nVerify the context:\nTerminal windowakt console whoami\n\nDeploy with the Managed Wallet\nOn a console-api context, the top-level workflow commands route through the Console automatically. Deposits are USD and must be at least 0.50.Acceptedformsinclude‘5‘,‘5usd‘,‘5, and 5.50usd`:\nTerminal window# Deploy using the Console managed walletakt deploy deploy.yaml --deposit 5\n# List your deploymentsakt console deployment list\n# Update a deploymentakt update deploy.yaml 12345\n# Close a deploymentakt close 12345\nUSD input uses plain decimal notation with at most two fractional digits. Signs, exponent notation, underscores, non-finite values, and sub-cent amounts are rejected before an API request. Coin values such as 5000000uakt are rejected on the Console rail.\nakt deploy creates the deployment, waits for bids, and creates the lease through the Console. The Console handles manifest submission internally.\nManaged deployments are priced in uact, the canonical deployment pricing denomination on both rails. Console escrow values use micro-ACT as micro-USD and pretty output renders them as dollars. Direct chain transactions such as akt tx bank send and akt tx gov vote require a keyring context. Use the top-level workflows or the matching akt console command for managed-wallet deployment operations.\nBecause the context has no local default account, bare owner-scoped chain queries refuse instead of widening to every network record. Use akt console deployment list for the managed account, or pass an explicit Akash owner address to a chain query.\n\nBids and Leases\nTerminal window# List bids for a deploymentakt console bid list 12345\n# Accept a bid by creating a lease and sending the manifestakt console lease create 12345 akash1prov...\nakt console lease create defaults to the manifest cached per context by deployment create, so the provider argument is the only decision left.\nNote: The --manifest flag takes the manifest the Console renders, not the SDL file. The Console returns that manifest exactly once, at deployment create; when it cannot be cached (for example, with no active context), the create result includes it so you can pass it to lease create later. Passing the SDL by mistake fails locally with a message naming the cause.\n\nDeployment Lifecycle\nDrive the Console API directly with the akt console deployment group:\nTerminal window# List / inspect deploymentsakt console deployment listakt console deployment list active --limit 20 --skip 0akt console deployment get 12345\n# Create a deployment (managed wallet signs server-side)akt console deployment create deploy.yaml 5\n# Update takes the dseq before the SDL fileakt console deployment update 12345 deploy.yaml\n# Add funds to a deployment's escrowakt console deployment deposit 12345 5\n# View or change a deployment's auto-top-up settingakt console deployment settings 12345 true\n# Closeakt console deployment close 12345\nCreate, update, deposit, settings changes, and close validate their identifiers and current deployment state before mutation. Update, deposit, settings changes, and close reject closed deployments. Close also rejects an absent deployment, so a repeated close never appears successful.\n\nLive Lease Operations\nLive lease commands reach the provider gateway directly, authorized by a short-lived Console-minted JWT, with no wallet and no local key involved. One-shot calls use a 300-second token; streaming and interactive modes use 3600 seconds.\nTerminal window# Stream logs for one serviceakt console logs 12345 web --follow\n# Last 100 lines across all servicesakt console logs 12345 --tail 100\n# Kubernetes events for the leaseakt console events 12345 --follow\n# One live status snapshot from the provider gatewayakt console status 12345\n# Re-poll every 30s until Ctrl-Cakt console status 12345 --watch --interval 30s\n# Interactive shell in a container (defaults to /bin/sh)akt console shell 12345 web\n# Run a single command (a.k.a. exec)akt console shell 12345 web -- ls -la\nNote: The service filter and --tail are applied client-side. The filter matches the service name as a pod-name prefix (the provider reports pod names like web-5cfc6c7b4b-4cl7z), and --tail bounds a one-shot read; it does not combine with --follow.\nAn explicit command launched from a terminal does not attach stdin, so it exits when the remote command finishes. Piped input attaches automatically; add --stdin to force attachment. JSON and YAML shell output require an explicit command and return separate stdout and stderr fields.\n\nWallet and Usage\nAll amounts are rendered in USD:\nTerminal window# Managed wallet balance and settingsakt console wallet listakt console wallet balanceakt console wallet settingsakt console wallet cost\n# Spend history for an explicit range (positional dates)akt console usage 2026-01-01 2026-01-31\nNote: An account that has never configured auto-reload reports the unconfigured default (\"configured\": false) instead of an error. Running akt console wallet settings true creates the settings record and enables auto-reload, which authorizes automatic credit purchases against your payment method.\nConsole bids reported in uact per block include an estimated 30-day dollar cost based on six-second blocks. Other denominations remain explicit.\n\nBrowse the Marketplace\nThese commands hit public Console endpoints and need neither an API key nor a configured context:\nTerminal window# Provider catalogakt console provider listakt console provider get akash1prov...akt console provider regionsakt console provider auditors\n# GPU availability and pricingakt console gpu\n# Deployment templatesakt console template listakt console template get <id>\n# Print a template's raw SDL to stdout (for piping)akt console template sdl <id> > deploy.yaml\n# Which providers can run this SDL? (bid screening)akt console screen deploy.yaml\n# Screen explicit resources without an SDLakt console screen --cpu 2 --memory 4Gi --gpu 1 --gpu-model a100\nWhen you pass both an SDL and resource flags, explicit flags override the values read from the SDL. Provider attributes, auditors, storage, resource count, and reclamation window are also available as screening flags. Run akt console screen --help for the full list.\n\nCredentials\nTerminal window# Manage Console API keysakt console apikey listakt console apikey create ci-keyakt console apikey delete <id>\n# Mint a short-lived provider-scoped JWTakt console jwt create\nakt console apikey create prints the secret exactly once. Store it securely because it cannot be retrieved again.\nAPI key deletion verifies that the UUID exists before sending the delete request. A repeated delete exits nonzero instead of printing deleted: true for an absent key.\nAfter each successful Console leaf command, akt writes an action-specific Next: hint to stderr. JSON and YAML on stdout remain safe to pipe, and --quiet suppresses the hint.\n\nRelated Resources\n\nManaged Wallet API - The REST API behind these commands\nDeployments - The full deployment lifecycle with akt\nContexts & Configuration - Context and credential management\n\nEdit page on github\n Deployments Queries & Transactions","tokens":2106,"squid":"spider-03","role":"Compute Spider","at":1791347208227,"hash":"e5d81658a79e53abdc9d94089e0e1b0451e937e2"}
{"url":"https://gov.optimism.io/t/pragmatic-first-step-towards-decentralizing-sequencer/2767/2","domain":"gov.optimism.io","title":"Pragmatic first step towards decentralizing sequencer - 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 Jun 2022\n\n 2 / 3\n\n Aug 2022\n\n Aug 2022\n\n post by polynya on Jun 24, 2022\n\n polynya\n\n Governance forms a whitelist of sequencer operators ala Lido, and we rotate between them every epoch (e.g. X hours). Optimism Foundation retains rights as a reserve sequencer if the lead sequencer is offline. Can ask them to post up a bond in OP or ETH.\nNext step, whitelisted operators can participate in an auction, more sophisticated penalties/incentives. Final step: remove the whitelist, or implement whatever the final decentralization mechanism.\n\n OP as an MEV staking token\n\n Proposal to pause Governance Fund voting cycles till minimum viable decentralization is achieved\n\n Proposal: Pause Phase 1 and start a discussion round to improve the governance process\n\n Polynya - Delegate Communication Thread\n\n 1 month later\n\n post by smartcontracts on Aug 2, 2022\n\n smartcontracts\n\n Practically speaking, I think the pathway to sequencer decentralization likely needs to look like this:\n\nBedrock is a critical part of Sequencer decentralization because we can reintroduce a mempool (among a few other things). Unclear if the mempool will be public, but at least it can be shared by Sequencer nodes. This means we don’t lose transactions when we switch between sequencers. Anyway, this means Bedrock is a hard dependency.\nOnce we have Bedrock, we could start by having the foundation run multiple sequencer nodes that switch by round robin. Effectively the same as your proposal but the foundation runs all nodes. Allows us to build confidence in the design before going to external parties.\nMove towards a governance-controlled whitelist with the reserved foundation node, like you said.\n\n post by Prometheus on Aug 2, 2022\n\n Prometheus\n\nDropping links for people not that familiar with Bedrock.\n\n OP in Paris: Kelvin Fichter (low audio)\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Plans to decentralize the sequencer\n\n ✨ General\n\n Hello all, I was wondering if anyone has any resources on the different strategies that may be implemented for decentralizing L2 sequencers. I’d like to start doing some research on the topic because I am interested in r…\n\n read more\n\n 20\n\n 3.0k\n\n Jun 2023\n\n Use OP to decentralize the sequencer\n\n ✨ General\n\n Is it possible to eventually turn optimism into PoS and use the OP token to decentralize the sequencer? I saw a twitter thread from bankless and wanted to see what everyone thinks ? It would decentralize optimism while g…\n\n read more\n\n 2\n\n 1.8k\n\n Jun 2022\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 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 Decentralised sequencer\n\n ✨ General\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","tokens":917,"squid":"spider-07","role":"Council Spider","at":1791347213865,"hash":"ee416a2c2e0e9a02e334ca44fa7d46f2e710626f"}
{"url":"https://forum.across.to/t/acx-portal-update/2132/2","domain":"forum.across.to","title":"$ACX Portal Update - Updates - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n Updates\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jun 30\n\n 2 / 2\n\n Jun 30\n\n Jun 30\n\n post by risklabs on Jun 30\n\n risklabs\n\n We wanted to provide an update on the timeline for the $ACX exchange and buyout process following the passing of the Snapshot proposal.\nOur initial estimate was that $ACX holders would be able to exchange $ACX for equity or sell $ACX for cash via the $ACX Exchange Portal by July 3, 2026. We now expect the $ACX Exchange portal to go live later than initially anticipated, most likely later in July.\nThe remaining work is primarily legal and operational in nature. We believe it is important to complete that diligence carefully rather than rush the launch.\nWe will continue to keep $ACX holders informed as we finalize the remaining steps and will share further details ahead of the portal going live.\nThank you for your patience as we finalize details..\n\n Pinned globally on Jun 30\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n The Bridge Across - August Update\n\n Updates\n\n Updates\n\n Aug 5\n\n The Across token buyout portal is now live\n\n Updates\n\n Updates\n\n 19d\n\n The Bridge Across\n\n Proposals\n\n governance-updates\n\n Pinned\n\n Proposals\n\n 39\n\n Apr 25\n\n $ACX Liquidity - Update and Feedback Wanted\n\n Ideas & Feedback\n\n Ideas & Feedback\n\n 7\n\n Jun 2023\n\n Across ($ACX) Community Initial Liquidity Proposal\n\n Passed Proposals\n\n Passed Proposals\n\n 49\n\n Nov 2022","tokens":1851,"squid":"spider-09","role":"Bridge Spider","at":1791347215762,"hash":"9bd6ad712b98d464bd49ed097c0638cf92ef4616"}
{"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 65\n\n 3d\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 872\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 586\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 139\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 51\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 30\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 491\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 644\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":"spider-07","role":"Council Spider","at":1791347223982,"hash":"c36503c407d66c97a0489f6f46f394c7d6a8d8e3"}
{"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 586\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":"spider-07","role":"Council Spider","at":1791347246030,"hash":"ad986e935da78b7a1e7cfdc1e555af948d84b1f0"}
{"url":"https://akash.network/docs/developers/deployment/akt/commands-reference/","domain":"akash.network","title":"akt Commands Reference | Akash Network - Your Guide to Decentralized Cloud","text":"akt Commands Reference This reference covers release candidate akt v1.0.0-rc0 command groups and the most common Akash and Cosmos SDK operations.\nThe chain SDK contributes many additional query and transaction leaves. Run akt <command> --help for the exact command tree and flags in your installed release.\nCheck GitHub for the most up-to-date code and GitHub Releases for the latest stable version. Homebrew installs the latest stable release; use the archive instructions for the release candidate.\n\nCommand Structure\nTerminal windowakt <command> <subcommand> [arguments] [flags]\nGlobal Flags:\n\n--home - Home directory for config, contexts, and keyrings (default: $AKT_HOME or ~/.config/akt)\n--context - Active context name (overrides current-context in config)\n--keyring-backend - Keyring backend for this invocation\n--keyring-dir - Keyring directory for this invocation\n-o, --output - Output format: pretty (default), json, yaml\n-v, --verbose - Increase output verbosity (-v verbose, -vv debug)\n-q, --quiet - Suppress informational output while keeping results and errors\n\nCommands take their primary values positionally, following the Akash resource hierarchy (owner/dseq/gseq/oseq/provider). Defaults for the node, chain ID, gas settings, and signing account come from the active context.\n\nContext Commands\nCreate Context\nCreate a new context. A network is required for keyring contexts and optional for a Console-only context.\nTerminal windowakt context create <name> --network <network>\nFlags:\n\n--network - Network definition to use\n--auth-method - keyring (default) or console-api\n--default-account - Default signing account\n--set-current - Make this the active context\n\nExample:\nTerminal windowakt context create prod --network mainnet --default-account alice --set-current\nconsole-api contexts do not require a keyring or default account. Their API key identifies the Console account and managed wallet. Owner-scoped chain queries still require an explicit owner when no default account is set.\n\nKeyring definitions\nCreate and manage the named key stores that contexts reference.\nTerminal window# List keyringsakt context keyring list\n# Create a file-backed keyring for a headless hostakt context keyring create headless file\n# Change an existing backendakt context keyring set headless os\nThe os backend uses the platform credential store. Other supported backends are file, test, kwallet, pass, and memory.\n\nSwitch Context\nSet the active context.\nTerminal windowakt context use <name>\n\nShow Context\nShow active context details: resolved network, keyring, store path, and capabilities.\nTerminal windowakt context show\n\nEdit Context\nChange a context’s settings.\nTerminal windowakt context edit <name> [flags]\nExample:\nTerminal windowakt context edit prod --default-account bob\n\nList, Rename, Delete\nTerminal window# List all contextsakt context list\n# Rename a context (moves its stored credentials)akt context rename prod production\n# Delete a contextakt context delete staging --yes\n\nAction Log\nView the per-context log of mutating operations, newest first.\nTerminal windowakt context log\nFlags:\n\n--type - Filter by action type (e.g., tx)\n--since - Duration (1h) or timestamp (2026-01-01)\n--limit - Maximum entries to show\n--workflow-id - Show every action for one workflow run\n\nNetwork Commands\nCreate Network\nCreate a network definition from a built-in template or custom values.\nTerminal windowakt context network create <name> [flags]\nFlags:\n\n--template - Built-in template: mainnet, testnet, sandbox\n--chain-id - Custom chain ID\n--rpc - Custom RPC endpoint\n--gas-prices - Gas prices (e.g., 0.025uakt)\n\nExample:\nTerminal window# From templateakt context network create mainnet --template mainnet\n# Custom networkakt context network create local --chain-id localnet-1 --rpc http://localhost:26657\n\nList, show, edit, and delete networks\nTerminal window# List networks and which contexts use themakt context network list\n# Show full network detailsakt context network show mainnet\n# Edit a network (affects all contexts using it)akt context network edit mainnet --gas-prices 0.025uakt\n# Delete an unused networkakt context network delete local\nThe selected network’s gas price is the minimum used for gas-price-derived fees. Lower flag and environment values are raised to the floor, higher values are preserved, and an explicit --fees value remains authoritative.\n\nKey Commands\nAdd Key\nAdd a new key or recover an existing one.\nTerminal windowakt context keys add <name>\nFlags:\n\n--recover - Import from mnemonic\n--source - Read a mnemonic from a file\n--ledger - Add a Ledger key\n--multisig - Create a multisig from existing key names\n--no-backup - Do not print a generated mnemonic\n--yes, -y - Accepted for Cosmos CLI compatibility; never overwrites a key\n\nUnless you use --no-backup or recover an existing key, save the mnemonic phrase printed after creation. It cannot be shown again.\n\nShow Key\nDisplay key details.\nTerminal windowakt context keys show <name>\nFlags:\n\n--address - Print only the bech32 address (useful for scripting)\n\nList, Delete, Rename\nTerminal window# List keys in the current context's keyringakt context keys list\n# Delete a keyakt context keys delete alice\n# Rename a keyakt context keys rename alice alice-old\n# Generate a BIP39 mnemonic without creating a keyakt context keys mnemonic\n\nExport / Import\nTerminal window# Export a keyakt context keys export alice > alice.key\n# Import from an exported keyfileakt context keys import alice-backup alice.key\n\nParse Address\nConvert an address between hex and bech32 formats.\nTerminal windowakt context keys parse akash1abc...\n\nSDL Commands\nEvery akt sdl subcommand runs entirely locally: no context, no key, no RPC endpoint.\nList Scaffolds\nList the built-in scaffolds (web, gpu, multi-service, ip-lease) and the flags each honors.\nTerminal windowakt sdl scaffolds\n\nGenerate an SDL\nPrint a deployable SDL to stdout, self-checked against the validator.\nTerminal windowakt sdl init <scaffold> [flags]\nFlags:\n\n--image - Container image (must carry an explicit tag or digest)\n--cpu, --memory - Compute resources\n--gpu-model - GPU model for the gpu scaffold\n--price - Pricing amount\n\nExample:\nTerminal windowakt sdl init web --image nginx:1.27 > deploy.yaml\n\nValidate an SDL\nValidate offline; exit 0 when valid, 1 when not. Use - to read stdin.\nTerminal windowakt sdl validate deploy.yaml\n\nWorkflow Commands\nWorkflow commands orchestrate the full deployment lifecycle, routing each step through the active context’s auth method (local signing for keyring, Console API for console-api).\nDeploy\nCreate a deployment, wait for bids, select a provider, create the lease, and send the manifest.\nTerminal windowakt deploy <sdl-file>\nFlags:\n\n--deposit - auto for the live chain minimum, an explicit chain coin, or an explicit Console USD value such as 5, 5usd, or $5. Console contexts cannot use the default auto value.\n--bid-timeout - Maximum time to wait for bids (default: 5m)\n--bid-select - interactive (default), cheapest, or provider=<addr>\n--ready-timeout - Maximum readiness wait after manifest submission (default: 2m)\n--no-wait-active - Return immediately after manifest submission\n-y, --yes - Skip confirmation prompts\n--dry-run - Show the execution plan without broadcasting\n\nExample:\nTerminal window# Automated deployment for CI/CD: one JSONL line per stepakt deploy deploy.yaml --bid-select cheapest --yes -o jsonl\n\nUpdate\nUpdate a deployment from a modified SDL file.\nTerminal windowakt update <sdl-file> [dseq]\nExample:\nTerminal windowakt update deploy.yaml 12345\n\nClose\nClose a deployment and return the remaining escrow balance.\nTerminal windowakt close [dseq]\nExample:\nTerminal windowakt close 12345\n\nQuery Commands\nAkash queries use a positional filter argument following the resource hierarchy, with smart type detection (a bech32 address is an owner, a number is a dseq). The q alias is equivalent to query.\nDeployments\nTerminal window# List your deployments (owner defaults to context account)akt query deployment\n# Filter positionally: state, dseq, owner, owner/dseqakt query deployment activeakt query deployment 12345akt query deployment akash1abc...akt query deployment akash1abc.../12345\nOwner-scoped lists refuse when neither the command nor the context supplies an owner. Paginated deployment queries support --limit, --offset, --page, --page-key, --reverse, and --count-total.\n\nMarket (Bids and Leases)\nTerminal window# List active leases (positional state keyword)akt query market lease active\n# Leases for a specific deploymentakt query market lease 12345\n# Specific lease (owner from context)akt query market lease 12345/1/1/akash1prov...\n# Provider-perspective queryakt query market lease --by provider akash1prov...\n# Bids for a deploymentakt query market bid 12345\n# Orders for a deploymentakt query market order 12345\n\nBank, Staking, Governance\nTerminal window# Check balancesakt query bank balances akash1abc...\n# Validatorsakt query staking validators\n# Governance proposalakt query gov proposal 42\n\nProviders and Certificates\nTerminal window# Query a providerakt query provider akash1prov...\n# Certificates for an ownerakt query cert list akash1abc...\n\nWASM\nTerminal window# Query a contractakt query wasm contract-state smart akash1contract... '{\"get_count\":{}}'\n\nTransaction Commands\nAll transaction commands accept --from, --gas, --gas-prices, --fees, --broadcast-mode, --yes, --dry-run, and other standard flags. Defaults come from the active context. Gas-price-derived fees cannot fall below the selected network’s configured price; fixed --fees values bypass that calculation.\nDeployments\nTerminal window# Create a deployment from an SDL fileakt tx deployment create deployment.yaml\n# Update a deployment (positional sdl and dseq)akt tx deployment update deployment.yaml 12345\n# Close a deployment (positional dseq)akt tx deployment close 12345\nNote: These direct chain transaction commands require a keyring signing account. For a managed wallet, use akt deploy, akt update, and akt close, or the matching akt console deployment command.\n\nDeployment Groups\nModify a specific group within a deployment (positional dseq and gseq):\nTerminal window# Pause a deployment groupakt tx deployment group pause 12345 1\n# Resume a paused groupakt tx deployment group start 12345 1\n# Close a groupakt tx deployment group close 12345 1\n\nMarket\nTerminal window# Create a lease (positional dseq and provider; gseq/oseq default to 1)akt tx market lease create 12345 akash1prov...\n\nBank, Staking, Governance\nTerminal window# Send tokensakt tx bank send alice akash1dest... 1000000uakt\n# Delegate to a validatorakt tx staking delegate akashvaloper1... 1000000uakt\n# Vote on a governance proposalakt tx gov vote 42 yes\n\nCertificates\nTerminal window# Generate and publish a client certificateakt tx cert generate clientakt tx cert publish client\n\nMint & Burn ACT (BME)\nConvert between AKT and ACT through the Burn-Mint-Equilibrium module:\nTerminal window# Mint ACT by burning AKTakt tx bme mint-act 500000uakt\n# Burn ACT to mint/remint AKTakt tx bme burn-act 500000uact\n# Generic form: burn tokens to mint another denominationakt tx bme burn-mint 500000uakt uact\nSee Mint & Burn ACT for background on when and why to convert.\n\nConsole Commands\nCommands for the Akash Console managed-wallet API. See Console Integration for setup and workflows.\nAuthentication\nTerminal window# Validate a Console API key and store it for the active contextakt console loginakt console login <key>\n# Remove the stored credentialakt console logout\n# Show the authenticated accountakt console whoami\n\nDeployments\nTerminal windowakt console deployment list [active|closed] --limit 20 --skip 0akt console deployment get <dseq>akt console deployment create <sdl-file> [deposit-usd]akt console deployment update <dseq> <sdl-file>akt console deployment deposit <dseq> [amount-usd]akt console deployment settings <dseq> [true|false]akt console deployment close <dseq>\nUSD amounts must use plain decimal notation with no more than two fractional digits and must be at least $0.50. Deployment mutations validate the positive dseq and reject closed resources before sending a write request. A repeated close is an error.\n\nBids and Leases\nTerminal window# Inspect provider bidsakt console bid list <dseq>\n# Accept a bid by creating a lease and sending the manifestakt console lease create <dseq> [provider]\n\nWallet and Usage\nTerminal windowakt console wallet listakt console wallet balanceakt console wallet settings [true|false]akt console wallet cost\n# Historical spend and active-deployment counts (positional dates)akt console usage [from] [to]\n\nLive Lease Operations\nTerminal window# Stream container logs from the lease's providerakt console logs <dseq> [service] --follow\n# Stream Kubernetes eventsakt console events <dseq> --follow\n# Live lease status from the provider gatewayakt console status <dseq> --watch --interval 30s\n# Open a shell or run a command in a lease containerakt console shell <dseq> <service>akt console shell <dseq> <service> -- ls -la\nExplicit commands launched from a terminal detach stdin by default. Piped input attaches automatically; use --stdin to force attachment. JSON and YAML output require an explicit command and return stdout and stderr fields.\n\nMarketplace (No API Key Required)\nTerminal window# Provider catalogakt console provider listakt console provider get <provider>akt console provider regionsakt console provider auditors\n# GPU availability and pricingakt console gpu\n# Deployment templatesakt console template listakt console template get <id>akt console template sdl <id>\n# List providers able to run an SDL (bid screening)akt console screen <sdl-file>\n# Screen explicit resources, or override values read from an SDLakt console screen --cpu 2 --memory 4Gi --gpu 1 --gpu-model a100\n\nCredentials\nTerminal window# Manage Console API keys (the secret is shown ONCE)akt console apikey listakt console apikey create <name> [expires-at]akt console apikey delete <id>\n# Mint a provider-scoped JWTakt console jwt create\nSuccessful Console leaf commands write a Next: hint to stderr. Structured stdout stays pipe-safe, and --quiet suppresses the hint.\n\nProvider Commands\nDirect provider gateway operations for keyring contexts. A provider address resolves its gateway URL from the provider’s on-chain record. --provider-url optionally overrides that gateway URL; it is not a chain RPC endpoint. Protected lease operations use jwt (default) or mtls authentication from the context.\nLease-scoped commands resolve the provider, gseq, and oseq from the deployment’s single active lease when possible. Pass --provider to choose when several active leases exist.\nProvider Status\nTerminal windowakt provider status [provider-addr] --timeout 30s\nProvider status is public and does not require a wallet or default account.\n\nLease Status\nTerminal windowakt provider lease-status [dseq]\n\nLease Logs\nTerminal windowakt provider lease-logs [dseq]\nFlags:\n\n-f, --follow - Follow log output\n--service - Filter logs by service name\n--tail - Number of lines to show from the end of the logs\n\n--tail cannot be combined with --follow.\n\nLease Events\nTerminal windowakt provider lease-events [dseq] --follow\n\nLease Shell\nOpen an interactive shell session to a container in a lease. Positional arguments are the remote command, so --dseq and --service are flags here.\nTerminal windowakt provider lease-shell --dseq <dseq> --service <service> -- /bin/sh\nFlags:\n\n--dseq - Deployment sequence number\n--service - Service name (required)\n--stdin - Force stdin attachment for an explicit terminal command\n-t, --tty - Allocate a TTY (default: true)\n\nExplicit commands launched from a terminal detach stdin by default. Piped input attaches automatically. Structured output requires an explicit command and returns separate stdout and stderr fields.\n\nConfidential-compute attestation\nRequest a fresh hardware quote from a confidential-compute lease:\nTerminal windowakt provider lease-attestation [dseq]\nThe command verifies the provider transport and nonce freshness. It does not yet validate the hardware evidence signature, endorsement chain, or measurement policy.\n\nManifests\nTerminal window# Send an SDL manifest to the providerakt provider send-manifest deploy.yaml --dseq 12345\n# Retrieve the current manifestakt provider get-manifest [dseq]\nWithout --provider, send-manifest attempts every provider holding an active lease. It reports an error unless all active providers accept the manifest.\n\nMigrations\nTerminal window# Migrate hostnames between deploymentsakt provider migrate-hostnames --dseq 12345 --hostnames example.com,app.example.com\n# Migrate endpoints between deploymentsakt provider migrate-endpoints --dseq 12345 --endpoints <endpoints>\n\nStore Commands\nManage the per-context local deployment store.\nTerminal window# Display local store informationakt store status\n# Reconcile tracked accounts with on-chain deployments, leases, and bidsakt store sync [account]\n# Export the local store to YAML or JSONakt store export\n# Import records from a previously exported fileakt store import <file>\nThe export format is for inspection and backup. It is not a deployable SDL.\n\nMonitor Commands\nReal-time dashboards over an RPC WebSocket connection. See Network Monitor.\nTerminal window# Launch hub (defaults to Network dashboard)akt monitor\n# Direct dashboardsakt monitor networkakt monitor providerakt monitor oracleakt monitor bme\nInside the Network dashboard, 1 opens Overview, 2 Validators, 3 Governance proposals, and 4 Governance parameters. Tab and Shift-Tab switch dashboards.\nFlags:\n\n--rpc - RPC endpoint (also accepted as a positional argument)\n--insecure - Skip TLS verification\n--clean-cache - Clear cache and start fresh\n\nMCP Command\nStart an MCP server for AI assistant integration. See MCP Server.\nTerminal window# Read-only mode (safe for AI agents)akt mcp\n# With write tools enabledakt mcp --enable-writes\n# Console tools only, no context neededakt mcp --console-api-key <key>\nFlags:\n\n--enable-writes - Enable write tools (on-chain transactions and provider mutations)\n--console-api-key - Console API key; overrides the context credential and AKT_CONSOLE_API_KEY\n\nWith both rails configured, read-only mode exposes 27 tools and write-enabled mode exposes 33. Ctrl-C and closed stdin both stop the server cleanly.\nA Console API key can start a contextless read-only server. --enable-writes requires an explicitly selected context so mutations have an action-log destination. If an optional chain signer cannot initialize, available read tools remain registered while signing-dependent tools are omitted.\n\nUtility Commands\nVersion\nTerminal window# Short form: version, commit, build dateakt version\n# Full build info: version, commit, build date, Go version, platform, build tagsakt version --long\n\nCompletion\nTerminal window# Generate a shell completion script (bash, zsh, fish, powershell)akt completion zsh\n\nOutput Formats\nControl output format with --output (-o):\nTerminal window# Pretty table (default): color-coded states, bold identifiersakt query deployment\n# JSONakt query deployment -o json\n# YAMLakt query deployment -o yaml\n# JSONL (workflow commands, for CI/CD)akt deploy deploy.yaml --bid-select cheapest --yes -o jsonl\n\nRelated Resources\n\nInstallation\nContexts & Configuration\nDeployments\nConsole Integration\nSDL Reference\n\nEdit page on github\n MCP Server Installation","tokens":4848,"squid":"spider-03","role":"Compute Spider","at":1791347261735,"hash":"d0362886f50ed8719a0d074f0a29e241e3a21265"}
{"url":"https://gov.optimism.io/t/brichis-delegate-communication-thread/6353/49","domain":"gov.optimism.io","title":"Brichis - Delegate Communication Thread - Communications 📣 / Delegate Updates - Optimism Collective","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 40\n\n read \n\n 24\n min\n\n Jun 2023\n\n 49 / 49\n\n Aug 21\n\n Aug 21\n\n Load more posts above\n\n post by Fuego on Jan 7, 2025\n\n post by brichis on Jan 14, 2025\n\n post by gjaldon on Jan 14, 2025\n\n 20 days later\n\n post by brichis on Feb 4, 2025\n\n 1 month later\n\n post by brichis on Mar 18, 2025\n\n 21 days later\n\n post by brichis on Apr 9, 2025\n\n post by brichis on Apr 10, 2025\n\n 19 days later\n\n post by brichis on Apr 30, 2025\n\n 1 month later\n\n post by brichis on Jun 10, 2025\n\n 21 days later\n\n post by brichis on Jul 2, 2025\n\n post by brichis on Jul 9, 2025\n\n 20 days later\n\n post by brichis on Jul 29, 2025\n\n 21 days later\n\n post by brichis on Aug 19, 2025\n\n 2 months later\n\n post by brichis on Oct 22, 2025\n\n post by stephanschwab on Oct 23, 2025\n\n 3 months later\n\n post by brichis on Jan 27\n\n 4 months later\n\n post by brichis on Jun 2\n\n 1 month later\n\n post by brichis on Jul 15\n\n brichis\n\n Voting Cycle #55 (Jun 25 - Jul 15, 2026)\nGrants Council Dissolution Proposal\nVote: For\nReasoning: It’s aligned with the changes expected for this Season. It could be great to recover some of the learnings from this experiment to be used by the Growth team in future Grants Programs.\nMilestones and Metrics Council Dissolution Proposal\nVote: For\nReasoning: It’s aligned with the changes expected for this Season. It could be great to recover some of the learnings from this experiment to be used by the Growth team in future Grants Programs.\nDeveloper Advisory Board Dissolution Proposal\nVote: For\nReasoning: It’s aligned with the changes expected for this Season.\nOperating Manual Update Proposal\nVote: For\nReasoning: Aligned with the changes expected for this Season. I’m wondering if we could need bigger changes in case voting participation continues to drop.\nSequencer ETH Management: 12-Month Renewal and Treasury Optimization\nVote: For\nReasoning: I think the previous proposal was a success considering that the Collective has additional ETH for the treasury; the custodians selected in the previous one are great options, and I’m excited to see how this one works as it’s planned to increase what we had in the past.\nSecurity Council Operating Budget\nVote: For\nReasoning: Aligned with the amounts that we’ve seen in the past. The Security Council is the most important structure at the Collective and should have the budget to run without any issues for the wellbeing of the Optimism Ecosystem.\n\n 1 month later\n\n post by brichis on Aug 19\n\n brichis\n\n Voting Cycle #57 (Aug 6 - 26, 2026)\nRe-designating the User Airdrop Allocation as the Strategic Ecosystem Fund\nVote: Against\nReasoning: While I agree with repurposing these funds after demonstrating that the airdrops didn’t work as expected, I don’t agree with allocating them to a new Strategic Ecosystem Fund based on the details provided so far.\nMy main concern is that the Seed Fund, Partner Fund, and similar initiatives have lacked the level of transparency and accountability that was required, for example, from the Governance Fund.\nI would feel more comfortable with a smaller allocation over a specific period, with clearly defined goals and a commitment to presenting a retrospective afterward. I would also consider requesting an independent third-party analysis to evaluate the results.\n\n post by TalhaKaradayi on Aug 21\n\n TalhaKaradayi\n\n Hello Brichis,\nWhile reviewing the Optimism governance forums and delege threads for my doctoral research, I came across your detailed voting rationales and notes regarding the LATAM ecosystem.\nAs a researcher in Management and Organization Science, I am studying how DAO governance and delegation actually function on the ground.\nInstead of a rigid questionnaire, I am genuinely interested in the real experiences of active delegates—the decision-making workload, trade-offs, and practical dynamics.\nBy the way, I am a real human, and you can ask me what you want learn or easily research my background online: LinkedIn: https://www.linkedin.com/in/talha-karadayi-282331169/ | University Emails: t.karadayi@reading.ac.uk / tkaradayi@ticaret.edu.tr\nWould you be open to having an informal conversation of approximately 30 minutes to share your views within an ethical framework?\nI am looking forward to your 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 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 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 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 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 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":1493,"squid":"spider-07","role":"Council Spider","at":1791347268063,"hash":"bfb68da1535b86125d493fe2e94c6d578520d9b7"}
{"url":"https://ethereum.org/guides/how-to-revoke-token-access/","domain":"ethereum.org","title":"How to revoke smart contract access to your crypto funds | ethereum.org","text":"Edit page (opens in a new tab)This guide will teach you how to view a list of all you have allowed access to your funds and how to cancel them.\nSometimes malicious developers build backdoors into smart contracts that allow access to the funds of unaware users who interact with the smart contract. What often happens is that such platforms ask the user for permission to spend an unlimited number of tokens in an attempt to save small amounts of in the future, but this comes with increased risk.\nOnce a platform has unlimited access rights to a token on your , they can spend all those tokens even if you have withdrawn your funds from their platform into your wallet. Malicious actors can still access your funds and withdraw them into their wallets with no recovery option left for you.\nThe only protections are to refrain from using untested new projects, only approve what you need, or regularly revoke access. So, how do you do that?\nStep 1: Use revoke access tools\nSeveral websites let you view and revoke smart contracts connected to your address. Visit the website and connect your wallet:\n\nEtherscan (opens in a new tab) (Ethereum)\nBlockscout (opens in a new tab) (Ethereum)\nRevoke (opens in a new tab) (multiple networks)\nUnrekt (opens in a new tab) (multiple networks)\nEverRevoke (opens in a new tab) (multiple networks)\n\nStep 2: Connect your wallet\nOnce you are on the website, click on “Connect wallet”. The website should prompt you to connect your wallet.\nMake sure you use the same network in your wallet and website. You will only see smart contracts related to the network selected. For example, if you connect to Ethereum Mainnet, you will only see Ethereum contracts, not contracts from other chains such as Polygon.\nStep 3: Select a smart contract you wish to revoke\nYou should see all the contracts that are allowed access to your tokens and their spending limit. Find the one you wish to terminate.\nIf you do not know which contract to choose, you can revoke all of them. It won't create any problems for you, but you will have to grant a new set of permissions the next time you interact with any of these contracts.\nStep 4: Revoke access to your funds\nOnce you click on revoke, you should see a new transaction suggestion in your wallet. This is to be expected. You will have to pay the fee for the cancellation to be successful. Depending on the network this can take from a minute to several to be processed.\nWe advise you to refresh the revoking tool after a few minutes and connect your wallet again to double check if the revoked contract has disappeared from the list.\nWe recommend you never allow projects unlimited access to your tokens and revoke all token allowance access regularly. Revoking token access should never result in a loss of funds, especially if you use the tools listed above.\n\nWant to learn more?See our other guides\nFrequently asked questions\nDoes revoking token access also terminate staking, pooling, lending etc?\nNo, it will not affect any of your strategies. You will remain in your positions and keep getting rewards etc.\nIs disconnecting a wallet from a project the same as removing permission to use my funds?\nNo, if you disconnect your wallet from the project, but you've granted token allowance permissions, they can still use those tokens. You need to revoke that access.\nWhen will the contract permission expire?\nThere are no expiration dates on contract permissions. If you grant contract permissions, they can be used, even years after they're granted.\nWhy do projects set unlimited token allowance?\nProjects often do this to minimize the number of requests required, meaning the user only has to approve once and pay the transaction fee only once. While convenient, this can be dangerous for users to approve carelessly, on sites that are not proven with time or audited. Some wallets allow you to manually restrict the amount of tokens being approved to limit your risk. Check with your wallet provider for more information.","tokens":998,"squid":"spider-05","role":"Spec Spider","at":1791347275208,"hash":"530f6df73fe78d9f06bd8ca86bf0a3edbc7b364a"}
{"url":"https://gov.optimism.io/t/brichis-delegate-communication-thread/6353","domain":"gov.optimism.io","title":"Brichis - 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 Brichis - 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 Jun 2023\n\n 1 / 49\n\n Jun 2023\n\n Aug 21\n\n post by brichis on Jun 30, 2023\n\n brichis\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 discussions regarding the OP distribution for the Retroactive Funding that Ethereum Mexico received. When asked if anyone was interested in Public Goods, I responded with a resounding yes. It all seemed to fall into place. We weren’t aware of any other Mexican delegate involved in any protocol, and Optimism felt like the perfect choice for me. After exploring various aspects of web3 over the past year and a half, I had decided to zero in on Public Goods. The concept of impact = profit is disruptive, and I am excited about the prospect of being part of this future.\nOn April 14th, I initiated an experiment within the experiment. I pondered: What would happen if a non-technical person with no experience in governance tried to become a delegate? As the experiment unfolds, I’ve come to recognize certain privileges that afford me spending hours reading Optimism’s Forum and Discord. Though it’s not an easy task, I believe this privilege obliges me to contribute to making Optimism’s governance more accessible.\n\nConflict of Interest Disclosure\n\nI am a co-founder of Ethereum México.\nIn May 2024 I received 1M OP from A16Z Delegation Program.\n\nNote: You may find that my initial decisions are based on straightforward reasoning, but rest assured, as I progress along my learning journey, I’ll undoubtedly enhance my decision-making processes.\n\n Governance Weekly Recap\n\n Season 7 Nominations: GrantNerd on the Grants Council\n\n 40\n\n read \n\n 24\n min\n\n post by brichis on Jun 30, 2023\n\n brichis\n\n Special Voting Cycle #12a (April 27 – May 10, 2023)\nProtocol Delegation Program Renewal\nVote: For. I’d love to see more participation from protocols.\nReasoning: Despite my limited knowledge of past experiences with the Protocol Delegation Program, a flag was raised for me when only 12 out of 23 Protocols responded by the deadline to be included in the summarized feedback. In my view, if they lack the ability to spare 15 minutes for feedback, they probably won’t have enough personnel, time, or interest to perform efficiently as delegates but I wanted to give a vote of confidence.\nIntent #1 Budget Proposal\nVote: For\nReasoning: The proposal seemed logical to me, particularly given the fact that other opportunities focusing on technical decentralization could originate directly from the Foundation, complete with a separate budget and process.\nIntent #2 - Council Intent Budget Proposal\nVote: For\nReasoning: I noticed that many experimental delegates backed the idea of renewing the Grants Council under Dane Lund’s leadership. This strong support suggests they had positive experiences with them in past seasons. Therefore, I felt confident in his leadership and the proposed budget.\nIntent #3 Budget Proposal\nVote: For\nReasoning: Personally, this intent resonates with me as it’s the first time I’ve felt included in the decision-making process. Its budget being the same as Intent #1 and lower than Novel Applications and Governance Accessibility seemed logical to me.\nIntent #4 Budget Proposal\nVote: For\nReasoning: I came to the conclusion that this specific intent might necessitate the development of tools, which could be costly. Therefore, allocating more funds than Intent #3 and less than Intent #2 made sense.\n\n post by CryptoReuMD on Jun 30, 2023\n\n CryptoReuMD\n\n Nice post Brichis. Up to read more for you in the forum, and also if it’s anything that i can help, please count on me and Nación Bankless, upfront the LATAM people.\n\n post by dmars300 on Jun 30, 2023\n\n dmars300\n\n govNERD\n\n It is truly amazing and inspiring seeing you improve and become a delegate in one of the most valuable ecosystems in the space. Congratulations Brichis. All my support and I’m sure you’ll bring valuable perspectives to the Collective\n\n post by brichis on Jul 1, 2023\n\n brichis\n\n CryptoReuMD\n\n Thank you very much for your support @CryptoReuMD, I am sure we will collaborate in the future.\n\n post by brichis on Jul 1, 2023\n\n brichis\n\n dmars300\n\n Thank you very much @dmars300! I’ll do my best to add value around here \n\n post by brichis on Jul 1, 2023\n\n brichis\n\n brichis\n\n Special Voting Cycle #12b (May 18 – 31, 2023)\nInflation Adjustment Proposal\nVote: For\nReasoning: The recent drop in OP token price made me feel that increasing inflation wasn’t necessary. Even though it was a minimal measure, it highlighted the need to take action.\nCouncil Reviewer Elections: Builders Grants\nVote:\n\nGonna.eth\nJack Anorak\nKrzysztof Urbanski (kaereste or krst)\nOxytocin\n\nReasoning: After reviewing their nominations and voting records, I trust their experience and intentions.\nCouncil Reviewer Elections: Growth Experiments Grants\nVote:\n\nKatie Garcia\nMatt L\nMichael Vander Meiden\n\nReasoning: I have read their nominations and voting records. I also found Michael and Katie to be highly dedicated and passionate delegates during my initial weeks.\nTreasury Appropriation (Foundation Year 2 Budget Approval)\nVote: Abstain. I trust in the good intentions of the Foundation, however, I believe that this approach could be improved.\nReasoning: I disagree with the voting cost in relation to the 1 OP difference if the proposal passes or not. Therefore, I choose to abstain. Nonetheless, I acknowledge the Foundation’s good intentions and hope for better processes in the future.\n\n 10 days later\n\n post by brichis on Jul 12, 2023\n\n brichis\n\n Cycle #13 Voting Period (Mission Proposals)\nFor this cycle, I used the Builder and Growth rubric of the Grants Council as a reference, and I included a category for intent. I did this because I believe the Grants Council has valuable experience in evaluating projects, and I aim to improve decision-making processes as a delegate. The total score is 18 points and I determined a percentage, approving those that were higher than 70%\nExample for Intent #1\n\n0\n1\n2\n3\n4\n\nProgress Towards Technical Decentralization\nNo clear progress towards technical decentralization is apparent\nMinimal efforts towards technical decentralization\nThere is some reasonable progress towards technical decentralization\nThere are significant efforts towards technical decentralization\nThe project substantially promotes technical decentralization\n\nLikelihood of success\nThere’s a clear flaw in the design that cannot be easily remedied\nDifficult to see the project continuing for more than a year\nThere’s a reasonable chance that the project has intermediate-to-long-term success (+1 Year)\nThe project is likely to generate long-term, sustainable value for the Optimism ecosystem\nThe project has a substantial likelihood of generating long-term, sustainable value for the Optimism ecosystem\n\nGrant size\nGrant size significantly outweighs the projected benefit\nGrant size is considerably larger than the expected benefit\nGrant size is proportional to the expected benefit\nExpected benefit outweighs the grant size\nExpected benefit meaningfully exceeds grant size\n\nTeam assessment\nThe team does not substantiate the ability to deliver on the plan\nThe team does not show significant ability to deliver on the plan\nThe team shows a reasonable ability to deliver on the plan\nThe team shows a significant ability to deliver on the plan\nThe team exceeds what is required to deliver on the plan\n\n0\n1\n2\n\nMilestone trackability\nNot trackable\nSomewhat trackable\nEasily trackable\n\nIntent #1, 1M OP\nVote: I’m voting in favor of all the options. This initiative is crucial, and every team demonstrate the necessary capabilities to execute this missions.\nReasoning:\n\nScry Protocol - Fully Decentralized and Independent Oracle and Data Infrastructure\nI think the outcome of this will be genuinely intriguing, and I appreciate their efforts to reduce their budget. However, I still believe it is relatively high but I’m voting yes because I think Decentralized and Independent Oracles are really important for Technical Decentralization.\nSpearbit + Immunefi Bug Bounty Program for Large Protocols on Optimism\nThe allocated budget is intended for bug bounties, and they possess the necessary expertise. Nevertheless, in the future, I believe that large protocols should consider establishing their own budgets for bug bounties.\nFuture-proofing UI/UX of OP nodes\nI’m really excited about this one. I believe they are the team capable of making it happen.\nTechNERD program\nI appreciate that OP Labs have participated on the same level as other projects with a proposed mission that addresses a genuine need. This will certainly bring benefits to the Optimism Ecosystem.\nSuperchain Governance Deep Dive\nI believe the outcome of this mission will be genuinely interesting, and I appreciate their decision to decrease their budget.\nExtend the L1Block contract to store historical blockhash data\nInitially, I didn’t understand their intentions, but they calmly explained to me that it’s important for protocols (bridges) not to be obligated to use zk light clients or centralized oracles so I decided to give a vote of trust.\nIntent #3, 1M OP\nVote: I’m voting “no” for missions I’m involved in to avoid conflicts of interest. However, I’m voting “yes” for most missions because I believe every effort counts, and everyone should have the opportunity to contribute to the Optimism Ecosystem.\nReasoning:\n“Yes”\nBanklessDAO’s Global Campaign to spread the Optimistic vision\nI believe they are some of the most experienced content creators. This can open doors for many non-native English speakers, and I’m excited about the potential impact on the ecosystem.\nSpread Optimistic values across Latam with Solow\nI fully understand the value of this proposal, and while some may argue that the content is duplicative, I believe each one offers something unique to a different audience. This will be the seed to foster greater participation in Latin America.\n‘Thank Optimism - powered by ThriveCoin’\nI believe this is a strong mission, and the Alliance has everything it takes to make it a success. Despite the high budget, the majority of it goes to contributors. I’m excited about this proposed mission.\nDevelop the most relevant and aligned audiovisual content for the Optimism Collective\nDespite the presence of many similar proposals, I appreciate that this one emphasizes technical aspects like OP Stack and Superchain. The budget may be high, but based on their previous work, I would love to read more content in my native language.\nCreate and Maintain the ‘Optimism Vision Reservoir\nI agree with other comments; the price-to-benefit ratio is interesting. I believe it could be highly useful and I hope it resonates with people, especially content creators.\nFueling RetroPGF Growth through Education, Collaboration, and Active Marketing\nAlthough the amount may be considered high, I believe a dashboard, real-life events, and general education are effective ways to promote RetroPGF and yield great results.\nVelodrome: Spread Awareness Through Direct Outreach and Onboarding\nThe Alliance members possess the necessary qualifications to carry out this mission. I’m particularly impressed by Velodrome’s recent performance update. This proposal holds great promise, and I’d love to see 5 Velodromes at Optimism!\nLet’s take the Optimistic Vision to LATAM with Espacio Cripto\nEspacio Cripto is one of the most important podcasts about crypto in LATAM, and their community holds significant influence, especially in Mexico. The budget may be considered high, but the expected benefits justify it.\nWeb3xplorer - A curated web platform to discover useful web3 apps, resources and tools\nDespite the existence of similar platforms, I would like to give them a chance. They are proposing something for a specific audience, and I’m curious to see how they evolve.\n“Abstain”\nRumbo Optimista - Hacia Ethereum Mexico The Event\nI’m the Alliance lead and an active Co-Founder of Ethereum México.\nOptimistic Womxn Shinning in Blockchain\nEven though my participation may not be considered significant due to dedicating only 5-10% of the time compared to my peers, I chose to abstain to avoid any potential issues.\nThere has been extensive discussion regarding this Intent, questioning whether these projects should be considered as proposed missions. However, I believe it was an internal mistake in our design, so I vote in favor of the majority. I see the proposed missions as an opportunity to understand the projects’ intentions, form alliances, and provide guidance on what is expected.\nIntent #4, 3M OP\nReasoning:\n“Yes”\nPairwise: Tinder UX For Web3 Community Signaling\nThe budget may be considered high, but I believe it could be highly beneficial for RetroPGF3, especially considering they already have the MVP. I’m excited about the improvements they are implementing, particularly for badgeholders.\nNumberNERD Program\nI appreciate their participation with a Proposed Mission. I believe this program will bring significant benefits, and I witnessed the quality of their work during a Governance Call. I’m excited about this mission.\nThe RetroPGF Podcast\nTo be honest, I trust Michael’s proposals. I think it will greatly contribute to positioning RetroPGF and highlighting what sets Optimism apart from other L2 solutions, beyond just the technical aspects.\nImproving Governance Accessibility through Praise and Contribution Based Attestations\nI consider Praise to be one of the best products available for DAOs. It is a valuable tool for emotional recognition and provides important contributor information. I believe the Praise culture could be extremely beneficial for Optimism.\nFacilitate and empower community members to actively engage in governance through an educational course\nI am familiar with Cryptoversidad’s work, and I believe their content will be easily understandable. I would love to see it open doors for many people interested in governance.\nMulti-lingual Lesson on Optimism Governance, by Bankless Academy\nAs a non-native English speaker, I believe initiatives like this are crucial. While I consider the budget to be high, I understand the need since they will be producing content in five different languages.\nOPdelegate.com\nI have seen the work of both Michaels, and I believe they will deliver something truly interesting. As a delegate with a low number of delegations, I may not personally derive much valuable information yet, but I am confident it will benefit other delegates.\nOP Governance Analytics Dashboard\nI find their proposal to be genuinely interesting. I would love to see it integrated with Agora and/or Michael’s OPdelegate mission. Both dashboards would complement each other well.\nREGEN Score - Attestations for the Citizen’s House\nThis could be a fun initiative. I appreciate that the first step is to present the conceptual design for feedback. It can be a great way to engage public goods project supporters in the Optimism community.\nDelegate Corner Podcast\nThe budget seems reasonable to me, and I believe Sinkas has a genuine interest in contributing to the Optimism ecosystem, which deserves our support.\n“No”\nVelodrome: Fostering Inclusive Governance through Leading Optimism Builders and Long-term Users\nThey are requesting a substantial amount of money. Initially, I understood that everything would go to participants, but now I see allocations like 350k for development and audit, 250k for running an Optimism Protocols program, and 400k for a govNFT program. While the idea of vested tokens is interesting, I believe the budget is too high.\nEconomic Co-design of Gas Fees for the OP Stack\nAlthough I find it interesting, the best use for this dashboard has not been defined yet (The Collective has not addressed gas-related aspects). I think it’s still early for this project, but it could become a valuable educational tool to understand gas fees for OP Stack.\nEnable aOP as A Votable Token in Optimism’s Governance\nThey have not resolved the issue of double OP voting power. I believe we can find better ways to incentivize OP holders who wish to delegate their tokens.\nDAOStar: Governance standards for the Optimism ecosystem\nThis could be enriching. However, I am concerned that the Optimism Foundation or OP Labs might not have sufficient time to dedicate to providing feedback.\n\n 1 month later\n\n post by brichis on Aug 21, 2023\n\n brichis\n\n Voting Cycle #14 (Aug 3 - 16, 2023)\nIntent 2 Budget Proposal 2\nVote: For\nReasoning: I fully support this idea. It’s crucial to encourage people to build on Optimism and utilize it. Rather than seeing these resources come back, I’d prefer them to be used to benefit more individuals who have a desire to build here.\nAnd in case you want to know about how my learning path is going…\nDuring these dates, I /had the opportunity to participate in the Delegate Corner podcast with @Sinkas, as well as in the Espacio Cripto podcast (in Spanish). Here are the links:\nDelegate Corner\nEspacio Cripto\nAnd, I also had the chance to conduct my first workshop on the fundamental concepts of Optimism governance and a step-by-step guide on becoming a delegate (in Spanish) with H.E.R. LATAM.\nOptimistas Brillando en Blockchain\n\n 3 months later\n\n post by brichis on Nov 24, 2023\n\n brichis\n\n Special Voting Cycle #16a (Oct 12 - 25, 2023)\nGrants Council Operating Budget\nVote: For\nReasoning: Impressive work by Grants Council in Season 4, Dane is an experimented lead and I consider that the increases are justified.\nCode of Conduct Violation: Carlos Melgar\nVote: Abstained\nReasoning: For me, the process wasn’t appropriate, the Token House lacked context and conflict resolution skills.\n Developer Advisory Board Budget\nVote: For\nReasoning: I’m excited about the Developer Advisory Board, as a not technical profile but with interest to contribute in Grants Council I think this will be a really interesting experiment. The amount can sound high according to my context but reading their profiles I think they deserve it If they do a good job during next Season.\nRatify Developer Advisory Board Members\nVote: For\nReasoning: I read their profiles and I have high expectations, looking forward to their evolution.\nAnticapture Commission\nVote: For\nReasoning: Despite some doubts about the amount, it’s an interesting experiment, and I’m proud to be a qualifying delegate.\nCode of Conduct Council Budget\nVote: For\nReasoning: After the last Code of Conduct violation, a dedicated council seems more appropriate than a Token House vote.\nSecurity Council: Vote #1\nVote: For\nReasoning: In favor of proposals enhancing Optimism’s security and decentralization.\nIn my learning journey, I joined the first govNERDs program. Working alongside people I admire was an amazing experience. I highly recommend it to anyone interested in governance.\nI also had the pleasure of being a guest on a couple of podcasts. Check them out:\nCriptocuriosas\nCafecito con Cryptoconexión\nAnd I applied for RetroPGF 3, you can see my application here. This sums up my governance journey, complementing my role as a delegate.\n\n 2 months later\n\n post by brichis on Jan 23, 2024\n\n brichis\n\nApologies for the delay in these updates. I had some hectic days in November and December, and I nearly reached burnout. But no worries, I took a few days off, and now I’m catching up on everything. I’m also informing my delegates before voting in the Telegram chat, which they can access with an NFT I sent them as a token of my gratitude for their belief in me during Season 4.\n\nSpecial Voting Cycle #16b (Nov 2 - 15, 2023)\nSeason 5 Intent Budgets\nVote: For\nReasoning: I provided feedback regarding the amounts, and I felt heard by the Grants Council Lead. I’m pleased that both my thoughts and those of my colleagues were taken into consideration, and I’m in favor of the final outcome.\nChain Delegation Program\nVote: For\nReasoning: I’m excited about the Superchain. I’m eager to see more players like Base, who can add significant value to Optimism, and I hope to see them actively participating in Optimism Governance.\nRatification of Law of Chains\nVote: For\nReasoning: I believe it’s an excellent first step. The process around the Law of Chains was clear and well-organized; we had ample time to read it, provide feedback, and participate in synchronous discussions to better understand the Law of Chains. As I mentioned earlier, I’m very excited about the Superchain.\nGrants Council Reviewer Elections: Builders\nVote:\n\nJack Anorak\nGonna.eth\nEthernaut\nKaereste\nJoxes\n\nReasoning:\nI retained most of the members from the previous sub-committee and added two new ones, Joxes and Ethernaut, because I believe they can contribute significantly to the Builders sub-committee.\nGrants Council Reviewer Elections: Growth Experiments\nVote:\n\nMichael Vander Meiden\nKatie Garcia\nMoneyManDoug\nGFX\nMatt L\nBrichis\nSubli_Defi\n\nReasoning:\nAt that point, I knew Subli and I didn’t stand a chance to win, but I chose to vote this way because I value the efforts we are making in Optimism Governance. Thus, it’s a symbolic vote.\nGrants Council Reviewer Elections: Milestones and Metrics\nVote:\n\nOcandocrypto\nRaho\nLauNaMu\nv3naru_Curia\n\nReasoning:\nI have learned a lot from Ocandocrypto and truly admire her. The same goes for LauNaMu; I am familiar with her work and intentions. Regarding Raho, I have heard very positive things about his work, and v3naru did an impressive job with Curia. Therefore, I would be delighted to see him contribute value to the Grants Council as well.\nCode of Conduct Council: Member Nominations\nVote:\n\nJuankbell\nTeresacd\nOxytocin\nGene\nJuanbug_PGov\n\nReasoning:\nI am familiar with Juankbell and the work he does with Gravity DAO. I also know Teresa quite well and am very pleased that she’s involved with Optimism. I frequently notice the presence of Oxytocin and Juanbug_PGov in governance matters & I chose Gene because I appreciate his/her intentions and the fact that he/she is already a graviton.\n\n Governance Weekly Recap\n\n post by brichis on Jan 23, 2024\n\n brichis\n\n Special Voting Cycle #16c (Nov 23 - Dec 16, 2023)\nRatify Security Council Members\nVote: For\nReasoning:\nI read the profiles and they have really impressive backgrounds, I want to see how this evolves. I would love to see them adding a lot of value to the Token House.\nUpgrade #2: Canyon Protocol Upgrade\nVote: For\nReasoning:\nI voted in favor because I read feedback from technical governance participants whom I trust, and they all agreed on this upgrade.\n\n Governance Weekly Recap\n\n post by brichis on Jan 23, 2024\n\n brichis\n\n Voting Cycle #17 (Jan 4 - 24, 2024)\nUpgrade Proposal #3: Delta Network Upgrade\nVote: For\nReasoning: This proposal generates new opportunities for lower activity OP chains, such as PGN, as well as those with seasonal activity. It also paves the way for new OP chains, potentially reducing future costs associated with launching a new chain.\nProposal to Reclassify Grant Misusage Enforcement\nVote: For\nReasoning: I’m very impressed with the new Grant Misusage Process. I believe it will set Optimism as a model for other DAOs. The idea of having a public database, accessible to all for reference in future grant decisions is great!\nSummary of Code of Conduct enforcement decisions\nVote: N/A\nReasoning:\nI’m choosing not to vote on this, as it is expected to be optimistically approved and will automatically pass unless opposed by 12% of the votable OP supply. I agree with the decisions made and I trust the members of the Code of Conduct Council.\nRegarding my learning journey, I’ve started creating content and am excited to release it. I conducted my first English workshop on Mission Requests and am taking one-on-one English lessons to enhance my fluency. Additionally, I hosted the first internal meeting of the Anticapture Commission, serving as the Lead. I’m thrilled to be working with people I greatly admire. Also, my podcast with Nacion Bankless was released, where I shared a vulnerable moment from my web3 journey. If you speak Spanish and are interested in viewing it, here is the link: https://youtu.be/bOu-euE92oc\n\n 21 days later\n\n post by brichis on Feb 14, 2024\n\n brichis\n\n Voting Cycle #18 (Jan 25 - Feb 14, 2024)\nProtocol Upgrade #4\nVote: For\nReasoning: I’m glad we’re being proactive about preventing any Superchain hiccups. Keeping user security top of mind is crucial. Plus, is audited by Trust Security\nMission Requests: Intent #1, 1.33M OP\nVote:\nRequest 1A: Alternative CL/EL client Mission Request\nRequest 1B: Decentralized rollup-as-a-service\nRequest 1C: Fraud Proof CTF Mission Request\nRequest 1D: Implement a prototype of an OP stack chain with mempool encryption\nRequest 1E: OP Stack Research and Implementation\nRequest 1F: Open Source OP Stack Developer Tooling\nReasoning: I’m voting for all of them. They fit within the budget, and they’ve all gone through a process of feedback and approvals that makes me feel satisfied with the outcomes. Plus, Intent 1 got the approval of the Developer Advisory Board.\nMission Requests: Intent #2, 4M OP\nVote:\nRequest 2A: Additional Revenue Sources to Fund RetroPGF Rounds\nRequest 2B: Builders grants program mission request\nRequest 2C: Enabling ERC-7281 (xERC20 Tokens) Support on the Superchain Mission Request\nRequest 2D: Facilitate capital migration to the Superchain\nRequest 2E: Growth and experiments grants program mission request\nRequest 2F: Hosting “Optimism Unleashed” event at EthCC 2024\nRequest 2G: Layerwide new project support\nRequest 2H: Making Optimism a primary home of liquid staked eth\nRequest 2I: Novel treasury bootstrapping solutions\nRequest 2J: Onramping\nRequest 2K: OptiHack Global Initiative\nRequest 2L: smart contract auditing services\nRequest 2M: Superchain Hackathon Mission Request\nRequest 2N: ZK Toolkit for ZK Application Developers\nReasoning: I don’t disagree with any of these missions, so I’m voting for all of them because I appreciate the diverse options to grow the OP ecosystem. They’ve all passed through a review and approval process, and I think they’re pretty complete Mission Requests.\nMission Requests: Intent #3, 1.33M OP\nVote:\nRequest 3A: Advancing Optimism Anonymous Community and Governance Tooling\nRequest 3B: An Optimistic Future for Art\nRequest 3C: Crowdsourcing useful verifiable data\nRequest 3D: Deliver a Best-in-Class Perp Dex Mission Request\nRequest 3E: Incentivize Projects to Integrate the Farcaster Social Graph\nRequest 3F: Marketing Support Services mission request\nRequest 3G: Onboarding existing communities/organizations to Optimism, solving real-world problems\nRequest 3H: Onboarding Prominent Content Creators in Strategic Markets to OP and RPGF\nRequest 3I: Onchain Quest & Education Infrastructure\nRequest 3J: Optimism Ecosystem Proof of Provenance Infrastructure (EPPI) Mission Request\nRequest 3K: Scale ENS to Optimism\nRequest 3L: Superchain Accounts\nRequest 3M: Municipal Public Goods Funding Infrastructure on Optimism\nReasoning: I’m voting for all of them. While I would’ve preferred a few proposals without a focus on specific projects, I believe they’re great initiatives and that’s not a strong enough reason for me to withhold my vote, especially since they’ve already passed the feedback period and can no longer be modified. I’m excited about the prospect of Optimism addressing real-world problems.\nMission Requests: Intent #4, 1.33M OP\nVote:\nRequest 4A: AI Assistant for governance support Mission Request\nRequest 4B: Building Identity - Driving Adoption of Attestations\nRequest 4C: Create a grants Supertracker for the Optimism Collective and the Superchain\nRequest 4E: Delegation Quest SDK Mission Request\nRequest 4F: Incentivize and increase governance participation\nRequest 4G: Integration of Optimism Gov and RPGF Modules into University Courses\nRequest 4H: Interactive Educational Program for Delegates and Governance Contributors\nRequest 4I: Making Impact Evaluation Accessible\nRequest 4J: Governance Mentorship Program Mission Request\nReasoning:\nI’m voting for all except Request 4D (Create Videos about Optimism) because I believe it would be better funded through RetroPGF.\nOverall, I think the new processes for Missions effectively identified the best fits and provided ample feedback to refine each Mission. Most seem quite comprehensive, and I’m eager to see many teams apply.\n\nI’m conducting an experiment within the experiment. If you selected me as your delegate during Season 4, you have received a beautiful NFT from Rosa Glez. Art. This NFT serves as a token of my gratitude for your trust in me and is the key to joining a group with other delegators where I share my voting strategy in advance, open to their feedback. If you have the NFT, join us! \n\n 21 days later\n\n post by brichis on Mar 6, 2024\n\n brichis\n\n Voting Cycle #19 (Feb 15 - Mar 06, 2024)\nProtocol Upgrade #5: Ecotone Network Upgrade\nVote: For\nReasoning: We need to prepare for the blobs! They will significantly reduce transaction fees. If you’re interested in seeing how much you could save, visit this cool website:\n\nProtocol Upgrade #6: Multi-Chain Prep (MCP) L1\nVote: For\nReasoning: I believe it’s really important for emergency updates. I asked a question, and they haven’t answered yet, but according to the results of the audit (which found only low-security issues), I think the benefits of this upgrade far outweigh the risks.\nIf I am your delegate, you’ll receive a beautiful gift in the next days! \n\n 1 month later\n\n post by brichis on Apr 16, 2024\n\n brichis\n\n Voting Cycle #21 (Mar 28 - Apr 17)\nSeason 5 : Intents Budget Proposal #2\nVote: For\nReasoning: The Grants Council is proposing to redistribute funds already approved for this season under different intents, focusing them on specific missions. I am pleased that the application standards have been raised this season and trust the decisions of the Grants Council. I believe the teams applying for these missions are extremely capable, and failing to approve this change would mean losing a valuable opportunity.\nGovernor Upgrade #1: Improve advanced delegation voting\nVote: For\nReasoning: This may seem like a simple fix, but it represents a team responding to community feedback, which is why, for the first time, a governor upgrade is being voted on-chain. Personally, as someone with advanced delegation, I had to sign eight transactions during cycle 19, so I am fully in favor of this fix.\n\n 1 month later\n\n post by brichis on May 28, 2024\n\n brichis\n\n Special Voting Cycle #23a (May 23-29, 2024)\nProtocol Upgrade #7: Fault Proofs\nVote: For\nReasoning: Despite some discussions about the lack of a Fault Dispute Game audit and the potential reputational risk it may carry, I decided to vote “for.” I trust the reasoning of the proponents, and the existence of the Guardian role provides me with peace of mind in this regard.\nProtocol Upgrade #8: Changes for Stage 1 Decentralization\nVote: For\nReasoning: This is another upgrade in favor of decentralization. It will increase the threshold of the Security Council Multisig and transfer the role of the Guardian from the Foundation to the Security Council. Based on the voting turnout of the Security Council members, I believe the change in the threshold won’t affect anything in practice. I’m excited to see decentralization progressing step by step. This upgrade was audited in a Cantina Contest and by a Lead Security Researcher from Spearbit in parallel, without any high-severity issues being found.\nGovernor Update Proposal #2: Improvements to advanced delegation allowance calculations\nVote: For\nReasoning: This is a minor change that complements the last proposal. It has been audited by OpenZeppelin and is essentially a correction of an issue that can occur while calculating voting power.\nSeason 6: Code of Conduct Council Renewal\nVote: Abstain\nReasoning: I want the CoC to continue; however, the budget didn’t make sense to me, as the Framework outlines that it should be mostly retro funded. Considering the scope for this season, I would prefer a more conservative budget. On the other hand, I liked how they fulfilled their function, and I hope they propose a different budget for the next cycle.\nSeason 6: Developer Advisory Board Renewal\nVote: Zach Obront\nReasoning: I think Zach’s performance as Lead was very good, and I’m especially happy with the new non-technical summaries. However, I found Ed’s perspective really interesting and appreciated what he brought to the discussion, particularly his proposal for closer collaboration between the DAB and the GC. I would like to see this happen, although his budget seemed high considering the amounts recommended in the Collective Reward Framework. Nevertheless, I would like to see both of them in the next batch of DAB members.\nSeason 6: Grants Council Operating Budget\nVote: For\nReasoning: I consider the Grants Council the most needed Token House structure in the Collective. Personally, the quality of their work is top-notch within the web3 grants ecosystem, and I absolutely trust Gonna.\nSeason 6: Intents Ratification\nVote: For\nReasoning: All intents are very well aligned with this season’s theme. I liked that technical decentralization and governance have come together. Personally, I will look back nostalgically at the community intents and all the dynamics around them, but I think this approach is the right one for now.\nSeason 6: Intent Budgets\nVote: For\nReasoning: The budgets for Intents 1 and 3a are appropriate considering the demand from Seasons 4 and 5. 3b’s budget seems a bit high for something new, especially since I would like to see how the GC transfers all the knowledge acquired during these seasons to the new Grants Programs run by those chains. However, given the number of OP Chains expected, the amount becomes reasonable.\nAlso, I want to let you know that I applied for the A16Z delegation program and I got selected, so you’ll notice my voting power has increased. As Spider-Man says, with more power comes more responsibility 🫶🏽\n\n 21 days later\n\n post by brichis on Jun 18, 2024\n\n brichis\n\n Special Voting Cycle #23b (June 13-19, 2024) - Part 1\nUpgrade Proposal #9: Fjord Network Upgrade\nVote: For\nReasoning:\nThis is a low-risk change reviewed by Coinbase and OP Labs. This update will benefit some applications I’d like to see more of, such as smart wallets.\nGrants Council Reviewer Elections\nMission Reviewers\nVote:\nPast reviewers: @katie, @GFXlabs, @jackanorak, @mastermojo, @MoneyManDoug, @MattGov.eth & @Michael.\nNew reviewers: @Jrocki, @Tane, @Sov, Habacuc from @SEEDGov and I\nReasoning:\nThe first seven have been part of the Grants Council before and have done an excellent job. I believe it is crucial to maintain experienced members alongside the new ones joining.\n\nJrocki: He has a broad range of skills useful for the Grants Council and enough governance context from his experience as a delegate and working for the Foundation.\nTane (Takeshi): His technical profile will be very valuable for the Grants Council. He has shown great commitment to the collective in recent months.\nSov: As Head of Grants at Gitcoin, his knowledge of grants will be incredibly enriching for the Grants Council.\nHabacuc: His technical profile will be very helpful. Joxes from SEED Latam was part of the Grants Council last season and will be a backup this time, facilitating knowledge transfer.\nBrichis: I believe my profile could greatly support the Grants Council. I have enough context about the Collective, and my diverse skills can help achieve the KPIs. In the past, I have supported builders through 1:1 calls and workshops.\n\nThis decision was very difficult, especially since I know many of the applicants and have seen all the interest they’ve shown in the past few months. I definitely want to see them contributing in many of the new opportunities that arise, such as govNERDs or the CoC.\nMilestones and Metrics Reviewers\nVote: @v3naru_Curia, @Juanbug_PGov, @mmurthy & @LauNaMu\nReasoning:\nThey did an incredible job last season, and I’d like to see them continue. I’m adding Laura because her knowledge of impact metrics and the web3 Grants ecosystem could be highly beneficial for the team. If possible, I’d have all four in Milestones and Metrics.\n\n post by brichis on Jun 18, 2024\n\n brichis\n\n Special Voting Cycle #23b (June 13-19, 2024) - Part 2\nAudit Reviewer\nVote: @m4rio.eth, @AnthiasLabs, & leo.sagan from @SEEDGov\nReasoning:\n\nm4rio.eth: He has an excellent background and is the ideal candidate for this position.\nAnthiasLabs: Although he recently joined Optimism Governance, his experience with DAOs like Aave and Compound could bring valuable insights.\nleo.sagan: He has a good profile and could work well with Mario or AnthiasLabs. With Pumbi’s support, he would have the necessary context to perform well.\n\nAnticapture Commission Amendment\nVote: For\nReasoning:\nThe proposed changes are a well-implemented direct response to feedback from members who participated in the first iteration.\nChain Delegation Program Amendment\nVote: For\nReasoning:\nThis season, the Superchain will be the focal point. I believe this program and the implemented changes will attract new OP chains to join the Superchain.\nSeason 6: V2. Code of Conduct Council Renewal\nVote: For\nReasoning:\nI appreciate the preparation of a second proposal with a more grounded budget. I recognize that internal work can be hard to appreciate, but I want the CoC to continue next season. With an increased budget, my expectations also rise.\nDeveloper Advisory Board Elections\nVote: @wildmolasses, @devtooligan, @anika, @wbnns & @Noah.eth\nReasoning:\na. Wildmolasses: I liked that he presented his own proposal, showing his perspective on how the DAB should look. I definitely want to see both proponents working together.\nb. Devtooligan: I liked his application. I feel that his personality and the good relationships he already has with devs within Optimism will bring positive outcomes to the DAB. Additionally, he has availability.\nc. Anika: I liked her participation in the Town Hall, and I have high expectations for how she can support DAB communication. I believe her perspective from Base and She256 will be important, as her context can be very useful for the DAB.\nd. Wbnns: He has an impressive background and I believe he will contribute greatly to the DAB. He also has experience translating complex terms into accessible language.\ne. Noah.eth: He has an impressive background and prior experience with non-technical audiences, making him the ideal candidate.\n\n post by Sov on Jun 18, 2024\n\n Sov\n\n govNERD\n\n brichis\n\n Thanks for the vote of confidence. I really appreciate it and will do my best to contribute if given the opportunity.\n\n Load more posts below","tokens":9740,"squid":"spider-07","role":"Council Spider","at":1791347283261,"hash":"84ecc07d68ed9f7cab5095dad3e20a45e3c65c9e"}
{"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":"spider-05","role":"Spec Spider","at":1791347289273,"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":"spider-05","role":"Spec Spider","at":1791347299325,"hash":"489d61763379e61cadb3f82930a036a45b2848a7"}
{"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":"spider-05","role":"Spec Spider","at":1791347311846,"hash":"44c47543a8339ba9d8d9bbdcc589f7d9e46b6661"}
{"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":"spider-05","role":"Spec Spider","at":1791347326625,"hash":"10c4377563f6ac83a61bc63ee58c41839135e879"}
{"url":"https://docs.soliditylang.org/en/latest/contributing.html?color=dark","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 Matrix 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 Matrix 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 Matrix 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":"spider-05","role":"Spec Spider","at":1791347340948,"hash":"0bf03589b89bafeca24455e258fc4ce95f955b30"}
{"url":"https://docs.jup.ag/user-docs/earn/offerbook/markets","domain":"docs.jup.ag","title":"Offerbook Markets - Jupiter Documentation","text":"Offerbook has two markets, Tokens and Collectibles. In the interface, the lender views live under the Earn menu in the header, while the borrowing side is reached through the collateral selector on the Borrow page — its category tabs (All, Collectibles, Bridged, DeFi, LSTs, Memecoins, RWA, Stablecoins) cover both markets. Both markets run on the same loan mechanics: fixed rate, fixed duration, no price liquidations. What changes between them is the collateral, how offers are organised, and what you should evaluate before lending or borrowing. The journeys themselves are covered in Borrowing and Lending, and the Pro view brings both markets’ books onto a single screen.\n​Reading the market table\nThe market table below belongs to the market views; the redesigned Borrow view surfaces offers as a list with per-offer terms instead, and the classic experience remains accessible. All market views share the same table, except the Collectibles Lend view, which is a grid of individual items (see Collectibles). Each row is something to borrow or lend against: an asset in the Tokens market, a collection or RWA partner in the Collectibles market. Badges next to the name show how many offers and intents are currently open on it.\nColumnMeaningAPR (7d)The annual percentage rate (APR) over the last seven days, shown as a trend with its current valueAPR (Median)The median rate currently quotedLTV (Median)The median loan-to-value (LTV) ratio currently quotedAvailableBorrow mode only. USDC available to borrow. A second line shows the additional liquidity advertised through intents, where presentAskLend mode only. USDC currently asked by borrowersOpen LoansValue of the loans currently open, with their countUtilizationShare of the supplied liquidity currently used by open loans\n\n​Tokens\nThe market for fungible collateral. Eligible collateral covers tokens verified on Jupiter through VRFD and tokenised real-world assets (RWAs) such as xStocks. The market table lists every asset currently available.\n\nBorrow view: Offerbook reads your wallet — the collateral selector lists your eligible assets, and the offer list shows the live lend offers matching your selection\nEarn → Tokens view: on the Available Now tab, pick the collateral you accept, or keep Any Collateral, and the table shows the demand for each asset. The Set Your Terms tab lists the asks borrowers have posted as intents and nobody has filled, each with Create offer to post a matching lend offer\n\nCategory chips above the table (Featured, RWA, DeFi, Bridged, Memecoins, LSTs) filter the rows, and the Filters button refines further.\nOffers backed by low-liquidity tokens display a warning in the interface, both at offer creation and on the offer page: the collateral may be hard to sell at the indicated price if the lender receives it.\n​Intents in the token market\nAssets with active intents carry an intent badge, and the advertised liquidity appears under Available alongside onchain offers. This liquidity is not committed: it reflects terms that users have advertised off-chain. To act on it, create an offer matching those terms, as described in Intents.\n\n​Collectibles\nThe market for non-fungible token (NFT) and trading card game (TCG) collateral. Offers are organised per individual item — one card, one open offer — except for PFP collections with a floor price, where lend offers can target the entire collection (collection offers).\n\nBorrow view: your collectibles become collateral — the Collectibles tab of the collateral selector lists the whitelisted collections, and selecting one surfaces the matching liquidity\nEarn → Collectibles view: a grid of individual items whose owners are asking for a loan, each with a Lend button showing the requested USDC amount. A sidebar filters by category (Trading Card Games, PFPs), APY, duration and loan amount; you can also search, restrict to a collection, or sort by best APY\n\n​Eligible collateral\n\nWhitelisted NFT collections — shown as collection chips at the top of the page\nPartner collectibles — physical cards professionally graded, tokenised 1:1 by Phygitals and Collector Crypt, held in insured vaults and typically redeemable for shipment through the partner’s platform\n\nPartner items carry a read-only Item details panel on the offer page (grade, grader, cert number, category, language, link to the partner’s platform). The loan mechanics are identical to any other NFT collateral; redemption of the physical card is handled entirely by the partner, outside of Offerbook.\n​Defaults and claims\nOn default, the lender claims and receives the item itself, not its USDC value. The 0.1% transfer fee charged on token collateral does not apply to NFT collateral. See Fees and Costs.\nCollectibles are less liquid than tokens, and the value of an individual item depends on its grade, rarity and resale market. As a lender, only lend an amount you would accept holding the item for, since a default leaves you with the card rather than the USDC.","tokens":1246,"squid":"spider-02","role":"Liquidity Spider","at":1791347351809,"hash":"f479cee2628e88a6b8a8b1963c1a3af34fecd968"}
{"url":"https://ethresear.ch/t/rainbow-roles-incentives-abps-focilr-as/21826","domain":"ethresear.ch","title":"Rainbow roles & incentives: ABPS + FOCILR + AS - Proof-of-Stake / Economics - Ethereum Research","text":"Rainbow roles & incentives: ABPS + FOCILR + AS \n\n Proof-of-StakeEconomics\n\n proposer-builder-separation,inclusion-lists\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Feb 2025\n\n 1 / 1\n\n Feb 2025\n\n Feb 2025\n\n post by aelowsson on Feb 24, 2025\n\n aelowsson\n\n Thanks to Roberto, Thomas, Barnabé and Francesco for feedback.\n1. Introduction\n1.1 Background\nA great deal of research has been conducted on potential improvements to Ethereum’s consensus layer. Fork-choice enforced inclusion lists (FOCIL) has the potential to improve censorship resistance by allowing includers to list transactions that should be included in the next block. The FOCIL EIP-7805 foregoes includer incentives due to their complex interactions with proposer incentives. Designing includer incentives remains an active research objective (1, 2). Proposer–builder separation (PBS) aims to detach the more specialized role of block building from block proposing, with a current objective of enshrining such a mechanism at the protocol level (ePBS). It is also desirable to “burn” the MEV by letting the block builder pay for the right to propose the block, and various proposals to this end have been made (1, 2). An alternative to PBS: attester–proposer separation (APS) can also be used for burning MEV (1, 2). In this variant, the protocol selects an execution proposer for proposing the execution payload of the block, and this proposer has featured in recent “rainbow” designs. Rainbow staking can in general be understood as the moniker and framework for unbundling the various roles that the staking set should assume.\n1.2 Overview\nIn this post, the limits of a maximally unbundled staking set are explored, examining potential roles and the incentives required to coordinate them. The beacon proposer becomes a separate role that attesters can opt out of through attester–beacon proposer separation (ABPS), presented in Section 2. A fee is taken out for assuming the role using a dynamic pricing auction (DPA) that adapts with the supply of prospective beacon proposers. This fee will match the MEV under equilibrium, thus burning it from a macro perspective. Stakers opting out of the role will see their associated reward variability eliminated, whereas remaining stakers will not.\nSection 3 introduces FOCIL with ranked transactions (FOCILR) that allows Ethereum to reward includers for their duties while remaining incentive compatible. The mechanism improves censorship resistance by making it costly for the proposer to stuff the block to exclude highly ranked transactions, potentially leveraging collective includer incentives to this end. It is possible to let very small stakers assume the includer role, and the supply of excess includers can be used to regulate a small regular fee taken out.\nSection 4 describes attester–separation (AS), by which attesters of the finality gadget (FA) and of the dynamically available chain (AA) can be split up, opening up for stakers with varying capital levels and risk appetite. The potential design is reviewed both from a consensus and economics perspective. The DPA presented in Section 5 can be used also for the includer fee and AS. But AS is presumably best incentivized via multiple reward curves according to principles presented in Section 6—either using separate independent curves (Section 6.1) or relative reward curves (Section 6.2).\nFigure 1 shows two of the rainbow constellations that can be created with the mechanisms presented. In the left pane is ABPS + FOCILR, with the proposer and includer fee calculated using a DPA. In the right pane is ABPS + FOCILR + AS, which further splits attesters into FAs and AAs. In this example, the proposer fee is again set by a DPA, but fees and rewards for other roles are instead set using multiple reward curves. A minimum (subject to further analysis) staking balance is indicated for each role, as well as rough targets for the relative amount of stake.\nFigure 11920×1267 148 KB\nFigure 1. Two potential rainbow constellations involving beacon proposers, attesters, and includers, with hypothetical minimum admissible balances for the different roles. Rainbow incentives are used to set the relative amount of stake for the roles at desirable levels.\n2. ABPS\n2.1 The role of the beacon proposer\nThe beacon proposer proposes the beacon block containing attestations and related updates to the beacon state as well as the execution payload (the “execution block”). It has an integral role in growing the chain and is selected from the attester set proportional to stake, to uphold decentralization and protect against Sybil attacks. Therefore, the beacon proposer “belongs” to the attester set, and its duties are sometimes referred to as attester duties. Constructing the execution block to extract maximum value is a rather specialized endeavor, so the beacon proposer often enlists block builders through MEV boost to build and eventually propagate the blocks. Formalizing this separation of duties is the topic of proposer–builder separation (PBS).\nWhile the beacon proposer is relieved of sophisticated duties in PBS, it will still acquire most of the MEV from the block through payments from builders. This complicates issuance policy because the expected yield varies over time with the level of MEV, making it difficult to enforce some specific desirable equilibrium quantity of stake. In fact, such an equilibrium may require negative regular rewards, forcing Ethereum to implement a staking fee. The rise in reward variability from MEV negatively affects stakers who cannot pool their rewards. Therefore, it could be desire to combine PBS with a mechanism for burning the MEV, rather than see it befall the beacon proposer.\n2.2 Attester–beacon proposer separation (ABPS)\nAttester–beacon proposer separation (ABPS) enforces a target proportion of beacon proposers relative to attesters, for example 3/4, 7/8, 15/16, or 31/32. A shift away from the target leads to a shift in the beacon proposer fee, encouraging stakers to join or leave the beacon proposer set, such that the target level is restored. Section 5 describes how a dynamic pricing auction (DPA) can be used for setting the beacon proposer fee. The separation of beacon proposers from attesters thus burns the MEV from a macro perspective, as further discussed in Section 2.2.1. The impact on censorship resistance is discussed in Section 2.2.2. Section 2.3 presents how stakers move in and out of the beacon proposer set by broadcasting RoleChange messages.\n2.2.1 MEV burn\nThrough ABPS, the MEV is essentially burned—at least from a macro perspective—by taking out a regular recurring fee from all stakers that assume the beacon proposer role. The stakers that are the most sensitive to reward variability have the option to opt out of beacon proposals, thus giving them the ability to continue attesting without suffering from variability in rewards. In fact, ABPS pushes down reward variability more than regular MEV burn at two levels:\n\nMicro level – stakers that opt out as beacon proposers also opt out of receiving proposal consensus rewards, which is the largest source of reward variability after MEV.\nMacro level – beacon proposers will under equilibrium need to pay for (almost) all MEV they can realize; there is no residual of builder tips after any attester deadline.\n\nIn fact, ABPS will also “burn” the proposer consensus rewards, because beacon proposers will account for these rewards when the equilibrium fee is established (this effect has been predicted in a similar context before). Note however that the incentive to propose is not altered by burning the consensus reward (see also Section 7.3).\nTo, e.g., mitigate timing games and make it costly to censor transactions by refusing to propose, the protocol might wish to take out a penalty for missed proposals. With ABPS, a larger penalty becomes more palatable, because stakers can opt out of the beacon proposer role if they find it too risky. The opportunity to opt out can however only be offered to a part of the staking set, so as to not jeopardize Sybil resistance. It is only this part of the set that derives the micro-level benefits, whereas macro-level benefits are still derived by all. The expected yield among stakers permanently opting out will likely be slightly lower under equilibrium, because beacon proposers will want compensation for variability and higher risks, etc.\n2.2.2 Censorship resistance\nBeacon proposers are drawn from the staking set to promote Sybil resistance and censorship resistance. Herein lies one potential downside of ABPS: the stakers that decide to opt out of the beacon proposal role might generally belong to a more decentralized part of the full set. Thus it must be expected that the beacon proposer role becomes a little more centralized than the attester role overall. A parallel can here be drawn to the current discourse around requirements imposed on beacon proposers, how it affects censorship resistance, the viability of remedies such as the max_blobs flag (1, 2), etc. But ABPS takes things further by allowing stakers to fully opt out, while putting them on an equal footing economically. A separate mechanism for ensuring censorship resistance at the execution layer, such as FOCIL (or potentially FOCILR presented in Section 3), will then become even more important. Stakers opting out of beacon proposals will still be includers in FOCIL, in fact, they can be given an increased probability for selection to the includer role if desirable.\nSomething that also is worthy of further discussion is whether ABPS upholds sufficient censorship resistance at the consensus layer, focusing here on the role of the beacon proposer in collating the beacon block and steering the fork choice. Such a discussion would also be useful for establishing the proportion of attesters that must be beacon proposers. A related topic is if all beacon proposers should attest. Figure 1 indeed illustrated some beacon proposers as non-attesters, but it is probably reasonable to mandate all beacon proposers to also attest. This allows honesty assumptions applied to the attester set to also translate to the beacon proposer set, as explored more deeply in Section 4 that deals with attester separation.\n2.2.3 Minimum validator size\nIf all beacon proposers must also attest, then the requirement on their minimum size s_\\text{min}𝑠min will be bounded by the s_\\text{min}𝑠min of attesters. Otherwise, the bound on s_\\text{min}𝑠min is determined by the amount the protocol wishes to slash an equivocating beacon proposer, which is ultimately determined by the damage caused by one such equivocation. A potential benefit of ABPS when attester duties are not mandated is thus that it can allow stakers with less ETH to participate in a key role for consensus formation. In Figure 1, beacon proposers have a lower s_\\text{min}𝑠min than attesters to reflect that their size will not significantly affect network load. As indicated in the right pane of Figure 1, attesters can also be further divided (see Section 4), in which case beacon proposers can be mandated to also attest to the available chain.\n2.2.4 Auction mechanism\nSection 5.1 illustrates the beacon proposer DPA. As previously mentioned, the protocol might wish to take out a penalty for failed block proposals, which ABPS makes more palatable. However, the regular DPA in Section 5.1 is zero-bounded, and cannot enforce an equilibrium if the penalty is set so steep (under low MEV), such that stakers only are willing to take on the role if the fee is changed to a small reward. To rectify this, the t𝑡-bounded DPA described in Section 5.2 could instead be used. It bounds the fee at some negative value (a small reward). However, when a DPA is applied, a penalty x𝑥 for failed beacon proposals is roughly equivalent to a reward x𝑥 for a successful proposal—proposers will compensate for the rise in expected rewards by paying a higher fee under equilibrium, and the incentive to propose is roughly the same. If successful proposal rewards are instituted instead of failed proposal penalties, the zero-bounded DPA of Section 5.1 will be sufficient.\n2.3 Entry and exit to the beacon proposer set\nValidators move in and out of the beacon proposer set by gossiping a RoleChange message over the peer-to-peer (p2p) network. These are propagated by other participants if the validator v𝑣 has an eligible size s_v>s_{\\text{min}}𝑠𝑣 >𝑠min for the role and meets other conditions, e.g., holding any other roles mandated alongside the new one. There is a small fee for updating one’s role r_\\text{fee}𝑟fee. This fee is taken out, e.g., log-proportional to stake (see the Appendix) and burned. Validators also have the ability to provide a tip r_\\text{tip}𝑟tip with the RoleChange message to encourage the current beacon proposer to include it in the beacon block. Each beacon block has some maximum space for RoleChange messages, which need not be substantial.\nStakers on Ethereum are subjected to a delay when entering and exiting their stake. One source of delay is the MIN_VALIDATOR_WITHDRAWABILITY_DELAY that ensures that any proof of slashing can be surfaced before a validator has exited. It would seem preferable to not apply such a delay when moving in and out of the beacon proposer set and instead look for any proof of slashing during MIN_VALIDATOR_WITHDRAWABILITY_DELAY also for validators not currently in the beacon proposer set.\nAnother source of delay is the churn limit. However, this limit is primarily in place to curb fluctuations in the attester set and arguably need not be applied when moving in and out of the beacon proposer set. As a result, it can be ignored here. For attesters it must be applied, making RoleChange messages more tricky to implement for attester separation discussed in Section 4. To move in and out of the attester set, validators could then instead be required to do a regular entry or exit and stipulate their desired role upon entry. It might be possible to allow attesters to the available chain to also shift roles using RoleChange messages, if the attester set is split up as discussed in Section 4, but it could increase complexity.\nBeacon proposers are currently selected during the update to the RANDAO, 32-64 slots before the actual proposal. Therefore, validators entering the beacon proposer set cannot be immediately selected for proposal, and the protocol will also need to wait before taking out the fee until the slot at which the new entrant is eligible for selection. Likewise, the fee must be taken out for exiting proposers up until and including the last slot that they had been eligible to be selected for, at the time of exit. All exiting proposers should be queued for exit and not exited until that slot. However, the fee update of the DPA should immediately account for new RoleChange messages included in a block, as well as any relative shift to the target associated with validators entering or exiting the overall staking set. It seems reasonable to have logic in place stipulating that an exited validator cannot enter directly again with eligibility for the next epoch. This would ensure that validators do not strategize to first exit upon missed selection, and then enter in time for the next selection, bringing down the fee in the meantime from dynamic price shifts. They would however still incur a cost 2r_\\text{fee}2𝑟fee for this strategy.\nCould censorship of RoleChange messages be expected? If so, members of the current FOCIL committee could be assigned the additional task of gossipping RoleChange lists (RLs), handled similarly to ILs. The goal would be to force beacon proposers to include RoleChange messages that have been widely observed. It is however not clear that such an RL committee would be required, given that the DPA presented in Section 5.1 can be designed to give low time sensitivity of inclusion and that validators can be given a small reward for each included RoleChange messages. If RLs can be avoided, the fork choice will be subjected to fewer conditional requirements and less logic, which is preferable.\n3. FOCILR\n3.1 Overview and starting assumptions\nFork-choice enforced inclusion lists (FOCIL) allows includers to force transactions into blocks, thus boosting Ethereum’s censorship resistance. The n𝑛 (e.g., 16) randomly selected includers post inclusion lists (ILs) of txs, which are observed by attesters at an IL deadline around 3 seconds before proposal. Attesters confirm that the proposer adheres to a locally de-duplicated IL aggregate of these lists (the \\text{IL}_\\text{agg}ILagg) by attesting to the block. The proposer (a term used in this section to refer to the entity responsible for the execution payload, currently the beacon proposer) can however fill the block to render the ILs irrelevant, thus gaining the ability to then censor txs. This is something that FOCILR addresses.\nVarious strategies for incentivizing includers have been suggested in the past (1, 2, 3, 4). Rewarding includers is however rather tricky due to how it may shift incentives and/or degrade UX; in the case of FOCIL when the block is full. Therefore, the FOCIL EIP-7805 opts to not incentivize includers. If being an includer requires any additional compute, the choice to ignore assignments can marginally reduce a validator’s cost. More importantly, the proposer wishes to be as unconstrained by the inclusion lists as possible to extract as much value as it can. This is an incentive for commitment attacks where the proposer commits to share marginal MEV with includers if they do not post an IL that constrains the block. Even if the number of includers is rather high so that the attack will not stop all ILs, there can still be marginal value in stopping some of them, particularly if the ILs are restricted in permissable size and includers have some variation in which txs they list.\nFurthermore, the includer role could be assumed by users with small balances who wish to stake to improve Ethereum’s censorship resistance. Includers are not constrained by networking considerations like attesters, and a minimum balance of for example 0.125 ETH (2^{-3}2−3) should be feasible. But since only the includer role could be offered to these participants, the reality is that very few will participate without incentives. If there are no incentives, a reasonable approach is to make the role mandatory for all attesters and beacon proposers, ensuring as big a pool of includers as possible.\nGiven the focus on rainbow incentives in this post, it seems relevant to come up with a tenable incentive mechanism for FOCIL. Such a mechanism should ideally have the following properties:\n\nFurther strengthen censorship resistance by making it difficult for proposers to control the content of the block when it is full.\nRetain a good UX for transactors.\nNot further incentivize transactors to keep txs out of the mempool.\nNever make it profitable to create fake transactions.\n\n3.2 FOCIL with ranked transactions (FOCILR)\n3.2.1 Problem definition\nIn FOCIL, the \\text{IL}_\\text{agg}ILagg cannot be used for dictating which txs must be included in a full block, because there is no mechanism for ranking txs. The proposer can therefore stuff the block to censor txs. Given that includers can be rendered irrelevant by the proposer, it also becomes problematic to reward them for their services. An improved IL mechanism should impose a ranking of txs in the \\text{IL}_\\text{agg}ILagg, define its purview within the block, and add an incentive compatible reward function.\nIt should be clear why the lack of a ranking function makes it impossible for FOCIL to exclude any specific tx in the \\text{IL}_\\text{agg}ILagg when the \\text{IL}_\\text{agg}ILagg contains more txs than what can fit within the block. The reason for why this condition extends to full blocks regardless of txs in the \\text{IL}_\\text{agg}ILagg is that the \\text{IL}_\\text{agg}ILagg is formed locally by each attester at the IL deadline, when some ILs may not have reached them, while still having reached the proposer. If attesters were to require proof that a tx was listed in an IL, proposers could always make sure that their preferred txs are listed. The majority of the beacon proposers belong to staking service providers (SSPs) that will have access to at least one includer if there are 16 includers per slot. Proposers without direct access could instead pay includers for that service.\nIf priority fees are awarded to includers, FOCIL becomes incentive incompatible, because proposers will then have an incentive to circumvent the includers by stuffing the block, and transactors forced to settle with the proposer out-of-band. The natural countermeasure to out-of-band settlement—to redirect priority fees to proposers when the block is full—cements block stuffing as a viable proposer strategy. In conclusion, the problem is that attesters have no agreed-upon incentive-compatible way to determine which txs that should be included in the block when not all prospective txs of the \\text{IL}_\\text{agg}ILagg (including those that can be added by proposer-run includers) fit inside of it.\n3.2.2 Ranking functions\nTo address the underlying issue, FOCIL with ranked transactions (FOCILR) will now be described. It forces the proposer to include “appropriate” txs from the \\text{IL}_\\text{agg}ILagg by calculating a canonical ranking of each listed tx. Define appropriate criteria for inclusion as the number of ILs specifying a tx (l𝑙) and the priority fee (f_p𝑓𝑝). The txs can then be ranked in three ways:\n\nFrom l(\\text{tx})𝑙(tx), with f_p(\\text{tx})𝑓𝑝(tx) as a tiebreaker: The \\text{IL}_\\text{agg}ILagg is then sorted in descending order based on the number of ILs listing a tx. Txs with an identical number of listings are further sorted according to priority fee in descending order.\nFrom f_p(\\text{tx})𝑓𝑝(tx), with l(\\text{tx})𝑙(tx) as a tiebreaker. The \\text{IL}_\\text{agg}ILagg is then sorted in descending order based on priority fee. Txs with an identical priority fee are further sorted according to the number of ILs listing a tx in descending order.\nFrom a combined measure such as f_p(\\text{tx})\\times l(\\text{tx})^q𝑓𝑝(tx) ×𝑙(tx)𝑞, with f_p(\\text{tx})𝑓𝑝(tx) as a tiebreaker. The \\text{IL}_\\text{agg}ILagg is then sorted in descending order based on the combined measure. The variable q𝑞 in this example regulates the balance between f_p𝑓𝑝 and l𝑙. When q𝑞 approaches 0, the combined measure approaches a pure ranking by f_p𝑓𝑝, and when q𝑞 approaches 1, it instead approaches a pure ranking by l𝑙. Txs with an identical combined measure can further be sorted according to priority fee in descending order.\n\nIf two txs cannot be separated from the given criteria, the tx hash can act as a second tiebreaker, with unconstrained ordering under a hash collision. The ranking functions are further analyzed in Section 3.4. Ranking by l𝑙 raises the most concern, whereas option (2) and (3) seem more favorable. Note that the ranking is not enforced for tx ordering in the actual block, it strictly regulates inclusion in the block.\n3.2.3 Gas threshold\nThe ranking creates a way for all parties to agree on appropriate txs to include when the block is full. The proposer is then no longer allowed to ignore the \\text{IL}_\\text{agg}ILagg, and must include txs from the sorted list at least up until (but potentially excluding) the tx that pushes the cumulative gas above some gas threshold g_t𝑔𝑡. This threshold is set as a proportion g_p𝑔𝑝 of the gas limit g_l𝑔𝑙:\n\ng_t = g_p\\times g_l.\n𝑔𝑡=𝑔𝑝×𝑔𝑙.\nIf g_p𝑔𝑝 is set too low, there can still be an incentive to stuff the block to take control over the remaining (1-g_p)\\times g_l(1 −𝑔𝑝) ×𝑔𝑙 of gas. For this reason, setting g_p=1𝑔𝑝 =1 might seem like a reasonable option. However, such a threshold might also be needlessly restraining, and may slow down settlement of more time sensitive high-priority txs (with priority indicated by f_g𝑓𝑔) arriving after the IL deadline when the block is full. Setting g_p<1𝑔𝑝 <1 reduces the pressure on proposers to integrate with includers in order to create more favorable lists. Furthermore, if g_p=1𝑔𝑝 =1 and all includers collaborate (or some high proportion when ranking by l(\\text{tx})𝑙(tx)), they can instead “censor” the proposer during full blocks. An appropriate setting might be g_p=3/4𝑔𝑝 =3/4.\nThe g_t𝑔𝑡 is applied to the ranked \\text{IL}_\\text{agg}ILagg regardless of whether the block is full or not, allowing the proposer to drop lower-ranked txs in near-full blocks. This is more neutral and prevents all reasons for block stuffing. If g_p<1𝑔𝑝 <1, block stuffing might otherwise still be favorable whenever the preliminary \\text{IL}_\\text{agg}ILagg consumes more than g_p\\times g_l𝑔𝑝 ×𝑔𝑙 of gas while remaining txs in the mempool do not fill the block. This would give proposers (and by extension builders) with access to exclusive order flows an (additional) advantage: they can fill the block without paying to create dummy txs, to squeeze in, e.g., more txs arriving to the mempool after the IL deadline. Thus, in conclusion, any ability to skirt the \\text{IL}_\\text{agg}ILagg should not depend on if the block is full. Instead, the block must contain at least g_t𝑔𝑡 gas of txs from the \\text{IL}_\\text{agg}ILagg, if such txs are available, but there is no requirement for more txs than that.\n3.2.4 Additional proposer and attester duties\nThe proposer stipulates which includers that listed each tx using a bitlist—a requirement for a correct reward calculation. Attesters confirm that there are no omissions in the bitlist by attesting to the block and are instructed to accept the proposer’s stipulation regarding any IL they did not observe—as long as that IL originates from an includer that they did not observe any other ILs from. Should they have observed only a conflicting IL from this includer at the time of attesting, but not the IL that the proposer based its bitlist on, they should not confirm the block. The proposer makes sure to propagate the ILs it bases its decisions on, to minimize the risk that it is tricked by an equivocating includer. Attesters are per the original FOCIL specification instructed to ignore such ILs, but the proposer is not held accountable if it incorporates an otherwise valid IL from an equivocating includer.\nFor each unobserved IL, attesters ensure that its total stipulated tx listings do not exceed the allotted bytesize of an IL. If the reward function is by p_f𝑝𝑓 and u<1𝑢 <1 (Section 3.3.2), the proposer also specifies active includers, which attesters confirm with their block attestation as long as there is no explicit conflict with their observations.\n3.3 Reward functions\nThe ranking functions described in Section 3.2.2 is complemented by a reward function for incentivizing includers. Two types of reward functions are considered: rewards from issuance with magnitude guided by the tx base fee, or rewards from the tx priority fee.\n3.3.1 Issuance guided by the base fee\nThe reward can be set as a fraction k𝑘 of the basefee b𝑏 paid for the tx: r=kb𝑟 =𝑘𝑏. This equation lets includers earn a fraction of the fair market price of the transaction. A primary reason to set rewards according to the market price is to ensure that there are no incentives to create dummy transactions just for rewarding includers, while at the same time not introducing any new inclusion fee or disrupting the flow of the priority fee, which will go to the proposer with this reward function. If there is a fixed reward for includers per tx and the base reward drops low enough, includers could coordinate such dummy transactions just to fill up the block and increase the includers’ rewards. Thus, the variable k𝑘 is bounded, and must adhere to k<1/n𝑘 <1/𝑛 when there are n𝑛 includers. A typical value for k𝑘 could be 1/512 when there are 16 includers, rewarding includers with a maximum of 1/32 of the total base fee.\nThis type of reward should not be interpreted as affecting the burn or Ethereum’s inflation rate. Any increase in issuance from FOCIL rewards could be offset by a decrease in issuance for other roles, or by taking out a fee for the FOCIL role. The base fee is simply used to derive an accurate value for censorship-resistance services provided by includers. The fraction k𝑘 should further be sufficiently low to not encourage gainful manipulation of the EIP-1559 mechanism.\nIt can be noted that includers are not rewarded for uniqueness in their listed txs. If uniquely included txs provide the includer with higher rewards, then transactors might partner with specific includers and send txs privately, so that they can share in the profit of unique inclusion. This degrades trustlessness in the protocol. Furthermore, the proposer can always assign more unique listings to includers it controls or includers who are paying for that service, leveraging its “last look”. Includers might then hand over responsibility to the proposer to maximize rewards, degrading trustlessness and censorship resistance of the FOCIL mechanism (yet the last look might also be valuable for non-unique rewards, to ensure that the IL has good coverage). Rewards weighted by uniqueness could also potentially disincentivize includers from propagating txs. To not reward uniqueness seems particularly relevant when rewards come from issuance. The priority fee on the other hand originates from the transactors themselves.\n3.3.2 Priority fee\nThe priority fee is currently used to motivate the proposer to include a tx in the block—but when includers list a tx, the proposer is forced to include it anyway. As stipulated in Option 2 of the FOCIL post, the priority fee could therefore be given to the includers whenever the tx is in the \\text{IL}_\\text{agg}ILagg, and to the proposer otherwise. However, if the proposer receives nothing from txs in the \\text{IL}_\\text{agg}ILagg and the block is full, it can seek to insert its preferred transactions in the \\text{IL}_\\text{agg}ILagg at the last second via an includer it pays or controls. High priority fees can be kicked back to the transactor from the proposer, allowing inserted txs to be the highest ranked when ranking by p_f𝑝𝑓 or by a combined measure, at no additional cost. When rewards derive from the priority fee, some additional compensation for unique listings might be acceptable—after all, the fee must be distributed to someone. But given concerns of a trustful advantage, it is still reasonable to only do so moderately, and to at the same time develop a mechanism for collectively rewarding active includers whenever the \\text{IL}_\\text{agg}ILagg has broad coverage.\nTo account for the presented issues and promote incentive compatibility, a slightly more refined division of the priority fee is here presented. It concerns only the situation when the tx is in the \\text{IL}_\\text{agg}ILagg—otherwise the priority fee is still given to the proposer. First, set aside\n\n\\omega_pf_p\n𝜔𝑝𝑓𝑝\nto the proposer, leaving\n\nf_p^+ = (1-\\omega_p)f_p\n𝑓+𝑝=(1−𝜔𝑝)𝑓𝑝\nto be further distributed. Here, \\omega_pf_p𝜔𝑝𝑓𝑝 gives the proposer an incentive to abide by the \\text{IL}_\\text{agg}ILagg generated by includers it does not control. Give each includer that listed the tx\n\nf_p^+\\frac{u(n-1)}{(un-1)l + n(1-u)},\n𝑓+𝑝𝑢(𝑛−1)(𝑢𝑛−1)𝑙+𝑛(1−𝑢),\nwhere n𝑛 is the total number of includers and l𝑙 is the number of includers listing the tx. The variable u𝑢 regulates the extent to which the protocol favors unique listings, while also defining the proportion of f_p^+𝑓+𝑝 given to a single includer listing a tx (the outcome at l=1𝑙 =1). This variable should be in the range u \\in \\left[\\frac{1}{n}, 1\\right]𝑢 ∈[1𝑛,1]. When u=1𝑢 =1, unique listing are maximally rewarded. The expression simplifies to\n\nf_p^+\\frac{u(n-1)}{l(un-1) + n(1-u)}\n=f_p^+\\frac{(n-1)}{l(n-1) + n(0)}\n=\\frac{f_p^+}{l}.\n𝑓+𝑝𝑢(𝑛−1)𝑙(𝑢𝑛−1)+𝑛(1−𝑢)=𝑓+𝑝(𝑛−1)𝑙(𝑛−1)+𝑛(0)=𝑓+𝑝𝑙.\nIf l=1𝑙 =1, the includer gets the whole f_p^+𝑓+𝑝, if l=2𝑙 =2, the two includers each get f_p^+/2𝑓+𝑝/2, etc. When u=1/n𝑢 =1/𝑛, the protocol does not premier uniqueness at all. The expression simplifies to\n\nf_p^+\\frac{u(n-1)}{l(un-1) + n(1-u)}\n=f_p^+\\frac{(n-1)/n}{l(0) + n-1}\n=\\frac{f_p^+}{n}.\n𝑓+𝑝𝑢(𝑛−1)𝑙(𝑢𝑛−1)+𝑛(1−𝑢)=𝑓+𝑝(𝑛−1)/𝑛𝑙(0)+𝑛−1=𝑓+𝑝𝑛.\nEach includer will always get f_p^+/n𝑓+𝑝/𝑛, and if not all includers list a tx, the remaining f_p^*𝑓∗𝑝 will be further divided as described in the next paragraph. Setting u𝑢 somewhere in between the extreme points seems reasonable. For example, when u=1/3𝑢 =1/3, a single includer gets around 33% of f_p^+𝑓+𝑝, if there are two includers they get 26% each, three get around 21% each, etc, with the remaining f_p^*𝑓∗𝑝 still left to be distributed. Note that the expression has been defined such that if l=n𝑙 =𝑛, the reward for each includer always becomes 1/n1/𝑛, regardless of the setting for u𝑢 (this is by design and as intended).\nDefine an includer as “active” if at least one of its listed txs was included in the block. If less than, e.g., half of the includers were able to insert a tx in the block, an includer will also be counted as active if it simply posted a valid IL. This condition will be observed by attesters as a natural part of their FOCIL duties, and noted in the block by the proposer for attesters to confirm. The reason for the backup condition of valid ILs is that the proposer otherwise could turn all includers inactive by replacing every tx that goes into the block from the \\text{IL}_\\text{agg}ILagg using the kickback strategy. This however requires substantial private orderflow or many txs coming in after the IL deadline.\nOf the remaining rewards,\n\n\\omega_if_p^*\n𝜔𝑖𝑓∗𝑝\nis given in equal share to all active includers, and\n\n(1-\\omega_i)f_p^*\n(1−𝜔𝑖)𝑓∗𝑝\ngiven to the proposer. Here, \\omega_if_p^*𝜔𝑖𝑓∗𝑝 can be regarded as the collective incentive, which distributes value to active includers if many txs with a high p_f𝑝𝑓 end up in the \\text{IL}_\\text{agg}ILagg and block. If the proposer tries to insert its preferred transactions by providing kickbacks to the transactors, these txs will leak value to active includers. A lower u𝑢 facilitates such leakage. Likewise, an includer trustfully relying on the proposer to maximize its uniqueness rewards will see the collective rewards fall when the \\text{IL}_\\text{agg}ILagg misses txs it could have surfaced independently. On the other hand, a higher u𝑢 makes it more costly for a proposer that wishes to censor a tx to convince an includer to not list it. It will also give includers an individual profit motive for broadening the coverage of the \\text{IL}_\\text{agg}ILagg. Section 3.5 specifies possible settings for the outlined variables.\n3.3.3 No reward function\nIt is possible to not incorporate rewards to includers, adopting a version of FOCILR that strictly enforces a ranking during full blocks. This can still strengthen censorship resistance by restricting the freedom of the proposer to decide which txs that goes into a full block. However, there is no monetary incentive for includers to list txs, and the proposer will not leak value if it enlists aligned includers and kickbacks priority fees to alter the ranking. The kickback strategy is rather esoteric and might not materialise in practice. It can however potentially be addressed by burning some proportion of the priority fee in full blocks, ensuring that artificially inflated priority fees come at some cost.\n3.4 Analysis of ranking and reward functions\nTo understand the benefits or drawbacks of the different options, includers’ potential valuation function of txs will now be examined.\n3.4.1 Considerations when ranking is irrelevant\nThe FOCIL EIP stipulates a maximum size of 8 kB of raw txs per list, with txs ordered by priority fee and included up to this limit. Consider now the optimal inclusion criteria from the includer’s perspective in FOCILR when there are more than 8 kB of txs available to select from.\nStipulate the expected reward from getting a tx included as r𝑟 and its size as s𝑠 bytes. The includer will then in its scoring function attach a value v𝑣 to a tx according to its reward per byte, ordering and selecting txs by\n\nv = \\frac{r}{s}.\n𝑣=𝑟𝑠.\nCalculating the expected reward of a tx can be rather complicated. Consider first the simple scenario where unique contributions to the \\text{IL}_\\text{agg}ILagg are not premiered and the ranking function is irrelevant because the total gas consumed by the block will stay below the threshold g_t𝑔𝑡. If the includer accrues some proportion \\dot{f}˙𝑓 of the priority fee or base fee (both proposed in Section 3.3), the expected reward of a tx will depend on the gas g𝑔 consumed by the tx: r=g\\dot{f}𝑟 =𝑔˙𝑓. The equation for the valuation of a tx is therefore\n\nv = \\frac{g\\dot{f}}{s}.\n𝑣=𝑔˙𝑓𝑠.\nThus, even if the includer accrues some proportion of the priority fee, it will not simply select txs based on priority fee, because there is an opportunity cost of selecting txs that take up relatively more space in the list. The includer is focused on “rewards per byte” and will select txs based on this measure if inclusion is certain and the IL will be filled. If the IL will not be filled, all txs will simply be selected.\nThe situation is somewhat complicated when unique contributions to the \\text{IL}_\\text{agg}ILagg are premiered. In this case, the expected rewards from a tx is adjusted by accounting for expected uniqueness (reviewing already observed ILs and accounting for patterns in tx inclusion observed during previous slots). The adjusted expected value when accounting for bonuses relating to uniqueness (if any) will be denoted v'𝑣′. Three points can here be mentioned regarding rewards for uniqueness:\n\nThey individually incentivize includers to facilitate a broad coverage in the \\text{IL}_\\text{agg}ILagg. When the reward function is by priority fee but without uniqueness rewards, there is only a collective incentive for this. In regular FOCIL without incentives, broad coverage would need to be faciliated by a local inclusion rule that relies on randomness.\nThey provide additional reasons for includers to wait close to the IL deadline, both for observing others’ ILs and shielding one’s own IL.\nThe proposer will have the ability to review all available ILs and finetune ILs under its control to optimize uniqueness rewards. It might even offer this as a service to includers it does not directly control, which might in the end lead to reduced censorship resistance (as discussed in Section 3.3.1).\n\n3.4.2 Considerations when ranking by f_p𝑓𝑝\nWhen txs of the \\text{IL}_\\text{agg}ILagg consume more than g_t𝑔𝑡 gas, the ranking function will determine which txs that are included in the block and thus influence expected rewards. The includer will still prioritize txs with a higher v'𝑣′ when it is certain that the tx will be included in the block. However, if there is uncertainty about a tx, the includer will seek to establish a probability of the tx being included when calculating the expected reward. This will then depend on the ranking function. When ranking by f_p𝑓𝑝, a tx with a higher f_p𝑓𝑝 but lower v𝑣 could thus still be prioritized.\n3.4.3 Considerations when ranking by l𝑙\nConsider now ranking by l𝑙. Just as previously, v'𝑣′ dominates for txs that are certain to be included (yet uniqueness and a high l𝑙 are of course rather contradictory). For other txs, probability of inclusion depends on what other includers settle on, with equilibria emerging gradually. If the reward function allocates the priority fee and uniqueness is not premiered, includers will likely gravitate towards ranking by v𝑣, which maximizes total rewards, acting as a dominant strategy. It is also possible that the simpler option of ranking by priority fee wins out. Furthermore, a tx that has been in the mempool longer is more likely to be selected, ceteris paribus, and txs coming in close to the deadline will be rather unlikely to be selected.\nIf the reward function allocates the base fee, the time of arrival of a tx will be relatively more important, but includers might still account for the priority fee. There are two reasons for this: (1) if g_p<1𝑔𝑝 <1, then there will still be some txs allocated by the proposer, who will tend to prioritize txs with high priority fees (or txs that indcue MEV, which includers by extension should also select for); (2) the proposer might commit to reward includers that prioritize txs with higher priority fees (since it will accrue these in this scenario). Importantly—regardless of reward function—if the maximum size of the IL allows for txs that consume more gas than g_t𝑔𝑡, a single includer dropping some otherwise high-ranking tx might be sufficient for it to be excluded from the block. Such a combination of conditions (ranking by l𝑙, low g_t𝑔𝑡 relative to IL size) would therefore be unsuitable.\nAt the same time, smaller ILs are restrictive to the includer. Ideally, includers would be allocated so many bytes in their list that they can fill them with raw txs up to the gas limit. This would simplify the decision-making process and improve censorship resistance. But as noted, it requires that ranking is not strictly by l𝑙. Large SSPs could, with ranking by l𝑙, benefit over smaller stakers. They can make sure that all their lists are identical, and will therefore have better guarantees of at least some inclusions for all of their selections. If uniqueness is premiered, it will be less influential, given that expectation of getting included rises with l𝑙. The last look of the proposer can also be more influential, particularly if it has control over several includers. There will be many knobs the proposer can turn to maximize value extraction while letting preferred txs win.\n3.5 Baseline specification\nAmong the discussed options, what could be a reasonable baseline specification? Ranking strictly by l𝑙 raised the most concerns in the analysis. There is the potential to extract slightly higher rewards for bigger SSPs, including additional value that can be extracted from the last look of the proposer. There is also the potential for weak censorship during times of congestion when includers drop otherwise appropriate txs, thus pushing down their l𝑙. Ranking by f_p𝑓𝑝 or a combined measure therefore seems more promising. Given that ranking by f_p𝑓𝑝 is simpler, it is can be suitable as a baseline.\nBoth reward functions presented in Section 3.3 seem reasonable. Going by the base fee will however be a bigger change both in terms of required protocol changes and UX. For one, it will essentially eliminate the need for a priority fee for txs posted to the mempool. Under equilibrium, this might however make transactors willing to pay an ever so slightly higher base fee for inclusion. Going by the base fee might also require developers to keep k𝑘 low to prevent manipulation of the EIP-1559 mechanism.\nThus a suitable baseline is to base both ranking and rewards on the priority fee. Proposed settings for the reward distribution are \\omega_p=1/8𝜔𝑝 =1/8, \\omega_i=1𝜔𝑖 =1, and u=1/3𝑢 =1/3. This gives 1/8 of the priority fee to the proposer, boosts unique inclusions moderately, while retaining a strong collective incentive for active includers. Setting u𝑢 closer to 1/n1/𝑛 alleviates concerns of a trustful advantage when favoring unique contributions to the \\text{IL}_\\text{agg}ILagg. Setting u𝑢 closer to 1 will on the other hand make it more costly for a proposer that wishes to censor a tx to convince an includer to not list it. A reasonable setting for regulating the gas threshold g_t𝑔𝑡 could be to set g_p = 3/4𝑔𝑝 =3/4. It is also desirable to allow ILs to have a large bytesize under the baseline specification.\nAs shown in Figure 1, the proportion of excess includers relative to attesters could be regulated by taking out a fee for assuming the incentivized includer role. This allows stakers with small balances to also assume the role, while at the same time letting their decision to do so help price the role. Mechanisms that can be used for regulating the size of the includer set are presented in Section 5 and 6.2. Given that rewards for includers will not be particularly large, it might however be reasonable to simply let the includer set expand without attaching a fee to the role.\n4. Attester separation\nSpecial thanks to Roberto, Barnabé and Francesco for feedback on this section.\n4.1 Split attestation roles\nAttesters currently attest to the available chain by casting LMD GHOST head votes, and finalize the chain by casting FFG source and target votes. They are the backbone of Ethereum consensus and will remain so in the future. This section will analyze the implications of splitting the attester roles both on consensus formation and in terms of how the different roles could be incentivized. Some stakers will thus be finality attesters (FAs) who attest to the finality gadget by casting FFG votes, while others will be availability attesters (AAs), who attest to the dynamically available chain by casting LMD GHOST votes.\nSplitting the roles allows for the removal of the slashing condition from AAs. This does not preclude any countermeasure to AA equivocation, such as forced exit, but limits the overall monetary loss that AAs can be subjected to. Stakers can then take on or delegate AA services without risking slashing. Setting aside potential consensus degradation, this seems like a clear benefit for the protocol. For example, staking service providers can offer services best suited to the risk appetite of individual users, and individual stakers can likewise opt for a risk level they are comfortable with and have the resources for. Another potential benefit is that Ethereum might actually benefit from more AA stake as a form of Sybil resistance, whereas FA stake can utilize slashing to punish misbehavior. The division into FAs and AAs is an active area of research, with the idea broached by Barnabé Monnot and to be further analyzed in a forthcoming post by him.\n4.2 Consensus considerations under split attestation roles\nBy splitting the roles, some consensus assumptions are upended. Consider an SSF implementation without subsampling that still contains an available chain voted on by AAs and a finality gadget voted on by FAs (most parts of the discussion will apply at present as well). It has been established that with a honest majority of online AAs in LMD GHOST with view-merge, the chain attains reorg resilience. But how would this reorg resilience be affected under network synchrony if honesty assumptions for the AA set do not extend to the FA set?\nCurrently, all validators are both AAs and FAs. It is therefore generally taken for granted that if >1/2 of the AAs are honest participants and follow the fork choice, then >1/2 of the FAs will be honest and follow the same fork choice for establishing viable checkpoints. Assume instead that AAs and FAs can be very different, such that the proportion of honestly participating AAs says much less about the proportion of honestly participating FAs. In such a scenario, the FAs could finalize a checkpoint on a branch that is not currently the head of the chain, even if all AAs consider that branch inferior, forcing the AA set to switch branches—assuming that they must always build on top of the latest justified block. A honest majority of online AAs will then not ensure reorg resilience, when treated in isolation.\nIt is desirable to have to make as few honesty assumptions as possible. How much additional stake weight could be added to the AA set, if FAs should not be able to directly finalize a checkpoint conflicting with the fork choice of an honest majority of AAs? All FAs are in this scenario imposed to also perform AA duties. It turns out that the AA set can then at most expand by 1/3 of additional stake. To see this, assume that all newly added AAs honestly follow the fork choice and the stake grows to 4/3 of its original size (the FA set has size 3/3). Among the 4/3, say that 2/3 are honest and 2/3 are dishonest such that the balance is even. In this case, 1/3 of the original joint set must be honest. An honest majority of AAs will thus imply at least 1/3 of honest FAs, which is enough to prevent finalization. Here, an “honest” FA refers to an FA that tries to finalize on a branch leading to the current head of the chain, in the honest AA set’s view.\nA further complication is how the inactivity leak factors into the fork-choice. When the chain fails to finalize, honest FAs can have a conflicting checkpoint to the dishonest FAs, if the block root of their checkpoints differ. The dishonest FAs will then fail to finalize the conflicting checkpoint until the honest FAs have leaked out, ultimately allowing the dishonest FAs to finalize. At that point, honestly participating AAs are required by LMD GHOST to shift back to the branch with the newly justified checkpoint. These AAs are also the FAs trying to finalize the other branch, and the FAs must then also shift back, leading all parties to agree with the choice of the dishonest FAs. An honest majority of FAs is thus important in the long run, to stop FAs from overriding the AAs with the help of the inactivity leak. This requirement has not been important to focus on previously when all attesters are both FAs and AAs, seeing that it then is implied by the assumption of an honest majority of AAs. It is here singled out as an honesty assumption worthy of further focus.\nA separate option is to instead require both AAs and FAs to come to the same conclusion—that is to say requiring support by both 2/3 of FAs and 1/2 of AAs to finalize a checkpoint. There is however some uncertainty as to how this could best be achieved, since finalization is an async protocol and the available chain relies on synchrony. What could be explored is to require FAs to include—upon finalization of a checkpoint—a certificate of support by AAs. Such a certificate could perhaps consist of votes (not necessarily present in the associated blocks of the branch) signed by a sufficient percent of AAs at a sufficient depth.\n4.3 Incentive design under split attestation roles\nSetting aside remaining uncertainty about the viability of splitting the attester set from a consensus perspective, this subsection explores how it could be done from an incentives perspective, assuming the benefits outweigh the downsides. Indeed, outlining a specification could be an integral part of assessing whether the benefits are worth the trade-offs. In the current protocol, FA and AA duties represent different types of attestation votes. Attesters vote on the source and target of the finality gadget (the FA duties), and are for these services credited with 40/64=5/840/64 =5/8 of all protocol rewards. Attesters further vote on the head of the available chain and receive 14/6414/64 of the rewards for this duty. The sync-committee attestations—also a non-slashable duty—will in this post be grouped together with head votes, and they receive 2/642/64 of the rewards. Thus, the AA duties provide 16/64=2/816/64 =2/8 of all rewards. But how should rewards be parceled out when each role is separate? A few different variants can be considered, here divided into three different classes:\n\nUse a reward curve that varies either with the quantity of FAs or both FAs and AAs. Keep the current balance in rewards (or set some new one), and:\n  a. do not further affect the proportion of attesters in different roles; or\n  b. change the reward balance in a hardfork if the ratio between roles is not satisfactory.\nUse a reward curve that varies either with the quantity of FAs or both FAs and AAs, just as in (1), but then:\n  a. enforce a specific proportion of AAs to FAs with a DPA; or\n  b. use a relative reward curve that smoothly balances yield against the role-proportion.\nControl the quantity of FAs and AAs independently, either with\n  a. two separate DPAs; or\n  b. two separate reward curves.\n\nOption (1) cannot guarantee some specific relationship in the proportion of attesters assuming the two roles, other than by sacrificing long-term reliability in (1b). Furthermore, the shape of the reward curve is the same for both roles, with variation restricted to scale. Option (2) can achieve any desired proportion of FAs to AAs, but option (2a) is rather rigid. This can lead to a differentiation in yield between the roles that is undesirable. For example, the yield for AAs could be needlessly pushed down to zero or become too high if the supply of excess AAs is inelastic. Option (2b) is instead better at capturing the diminishing marginal utility of adding additional AAs beyond some limit, and can very well be designed such that it caps additional AAs to for example 1/3 in excess of FAs. Section 6.2 illustrates relative reward curves, using option (2b) as the primary example.\nOption (3) allows for more granular control where each role is incentivized independently from the other. Once again, Option (3a) is rigid and can fail to produce a close-to-optimal equilibrium. Option (3b) can be suitable under circumstances where the relative proportion of two roles is less important and it is presented in Section 6.1. The protocol will with this setup not have control over, for example, how many FAs there are relative to AAs, which can break honest majority assumptions. But in the setup described at the end of Section 4.2, the protocol instead requires both 2/3 of FAs and 1/2 of AAs to finalize a checkpoint. Two separate reward curves are then perfectly fine, and arguably even desirable.\n5. Dynamic pricing auction (DPA)\n5.1 Regular DPA (zero-bounded)\nThe dynamic pricing auction (DPA) adjusts the yield for a role dynamically based on the supply of stakers for this role. The difference \\DeltaΔ between a target level and current level of stakers is used. The DPA target can be relative ETH level (e.g., beacon proposer stake relative to attester stake) relative proportions (e.g., proportion of beacon proposers relative to attesters), a fixed ETH level (e.g., targeting 30M ETH of stake weight for a role), or some proportion of the circulating ETH (e.g., targeting 25% of all ETH as stake weight for a role). A two-dimensional DPA has previously been proposed for facilitating a MEV resistant execution auction, differing in that the fee then was paid per proposal right, as opposed to being paid only for participation in the proposal lottery.\nA DPA for the beacon proposer role will now be presented, which can be easiest understood as a proposer fee. The fee adjusts based on the difference between the desired proportion \\hat{p}ˆ𝑝 of beacon proposers relative to attesters and the current level p𝑝 (thus, targeting a relative proportion as previously defined). If there is a surplus of proposers p>\\hat{p}𝑝 >ˆ𝑝, the fee rises until some validators relinquish their proposer role. If there is a shortage of proposers p<\\hat{p}𝑝 <ˆ𝑝, the fee falls until some additional validators take up the proposer role. The DPA adjusts based on the difference between the current and desired proportion: \\Delta p=p-\\hat{p}Δ𝑝 =𝑝 −ˆ𝑝 (as an alternative p/\\hat{p}-1𝑝/ˆ𝑝 −1 can also be used). The fee for the next slot f_{0+1}𝑓0+1 will then change relative to the fee of the current slot f_0𝑓0 by the linear function\n\nf_{0+1}= f_0(1+c\\,\\Delta p).\n𝑓0+1=𝑓0(1+𝑐Δ𝑝).\nThis is similar to EIP-1559, with the constant c𝑐 regulating the rate of change. The baseline used for this example is to set c=1𝑐 =1, which thus gives the baseline equation f_{0+1} = f_0(1+\\Delta p).𝑓0+1 =𝑓0(1 +Δ𝑝). This gives a moderately slow shift in yield, set to prevent censorship of RoleChange messages and avoid oscillations, while at the same time not changing so slowly that a large proportion of stakers feel compelled to leave or enter under drastic changes in MEV. That would be welfare degrading because it requires a large proportion of stakers to also adopt MEV strategies, make estimates of future MEV, etc. The fee f_n𝑓𝑛 after n𝑛 slots at some fixed \\Delta pΔ𝑝 can be defined as\n\nf_{n}= f_0(1+c\\,\\Delta p)^n,\n𝑓𝑛=𝑓0(1+𝑐Δ𝑝)𝑛,\nand the relative change to the fee, specified for f_0=1𝑓0 =1, is\n\nf_{c}= (1+c\\,\\Delta p)^n.\n𝑓𝑐=(1+𝑐Δ𝑝)𝑛.\nFigure 2 uses this equation to draw a map of the total change to the fee within various isotimes, with \\Delta pΔ𝑝 on the x-axis and f_c𝑓𝑐 on the y-axis. A second x-axis enumerates the corresponding change in ETH if 30M ETH of stake is currently attesting (corresponding to relative ETH level as defined in the first paragraph of this section). The isotime lines are drawn in 1-slot increments (green dashed), 1-minute increments (black dashed), 5-minute increments (solid black), and for 1 hour (solid brown). As apparent, when c=1𝑐 =1 and \\Delta pΔ𝑝 corresponds to 2M ETH, the fee would be halved within two minutes. The change over one slot would however be rather minimal even at large \\Delta pΔ𝑝.\nFigure 22332×1531 496 KB\nFigure 2. Change to the fee at c=1𝑐 =1 within various isotimes under a fixed \\Delta pΔ𝑝 (x-axis) with f_c𝑓𝑐 on the y-axis. The blue axis labels indicate the change in ETH at 30M ETH attesting.\nFigure 3 zooms in on a more narrow \\Delta pΔ𝑝, otherwise retaining the same properties of the plot. As apparent, the fee takes quite some time to adjust if only a few validators have shifted into or out of the beacon proposer role. For a more responsive fee adjustment, c𝑐 would need to be raised.\nFigure 31920×1261 203 KB\nFigure 3. Zoomed-in view of the change to the fee at c=1𝑐 =1 within various isotimes under a fixed \\Delta pΔ𝑝 (x-axis) with f_c𝑓𝑐 on the y-axis. The blue axis labels indicate the change in ETH at 30M ETH attesting.\nThe fee adjustment can be captured with time on the y-axis instead. To draw contour lines, the equation must first be reworked such that n𝑛 can be computed directly:\n\n\\frac{f_n}{f_0}=\\bigl(1 + c\\,\\Delta p\\bigr)^n,\n𝑓𝑛𝑓0=(1+𝑐Δ𝑝)𝑛,\n\n\\ln\\Bigl(\\frac{f_n}{f_0}\\Bigr)=n \\,\\ln\\bigl(1 + c\\,\\Delta p\\bigr),\nln⁡(𝑓𝑛𝑓0)=𝑛ln⁡(1+𝑐Δ𝑝),\n\nn=\\frac{\\ln\\bigl(\\frac{f_n}{f_0}\\bigr)}\n{\\ln\\bigl(1 + c\\,\\Delta p\\bigr)}.\n𝑛=ln⁡(𝑓𝑛𝑓0)ln⁡(1+𝑐Δ𝑝).\nFigure 4 shows the resulting isochange map with a zoomed-in version in Figure 5. The constant was again set to c=1𝑐 =1.\nFigure 42332×1531 364 KB\nFigure 4. Proportional change f_c𝑓𝑐 to the fee under a fixed \\Delta pΔ𝑝 (x-axis) with time on the y-axis. The blue axis labels indicate the change in ETH at 30M ETH attesting.\nFigure 52332×1531 370 KB\nFigure 5. Proportional change f_c𝑓𝑐 to the fee under a fixed \\Delta pΔ𝑝 (x-axis) with time on the y-axis. The blue axis labels indicate the change in ETH at 30M ETH attesting.\nOne relevant concern with a DPA is the prospect of cartelization attacks, whereby stakers collectively try to keep the beacon proposer fee artificially low by restricting entry while such entry is profitable.\n5.2 The t𝑡-bounded DPA\nThe t𝑡-bounded DPA is more appropriate than the zero-bounded DPA when there is a bound on the expected price that diverges from zero, specifically, when there is a bound situated at some threshold t𝑡. This section will explore the t𝑡-bounded DPA in the context of ABPS.\nThere is a specific form of censorship, wherein the proposer simply does not propose in lieu of proposing a block with txs imposed by FOCIL (that it wishes to keep out of consensus). Given that ABPS allows for somewhat more sophisticated beacon block proposers, a penalty could be charged for proposers that fail to get their blocks accepted, potentially because they were never proposed or proposed very late. However, if the MEV gradually falls, and the penalty is sufficiently high, then there is a risk that the equilibrium fee would need to be negative (a reward) to a","tokens":15000,"squid":"spider-04","role":"Research Spider","at":1791347358372,"hash":"157ec0be83bbdfce66a4d618b915ab60b0a21ff8"}
{"url":"https://docs.jup.ag/user-docs/earn/offerbook/affiliate-and-referrals","domain":"docs.jup.ag","title":"Affiliate & Referrals - Jupiter Documentation","text":"Offerbook has a built-in referral program that lets users share protocol fees. When someone you refer interacts with Offerbook, a portion of the platform fee is redirected back to you (the referrer) and partially refunded to the referred user.\nThis page covers the user-facing affiliate experience: how to create your referral link, customize it with a vanity slug, share it, and claim your earned rewards. Referral rewards are a share of the protocol fees charged at each loan stage; the fee schedule itself is in Fees & Costs.\nThe referral program applies at every stage where a fee is charged: loan start (25% fee paid by the borrower), repayment (10% fee paid by the lender), and collateral transfer (0.1% fee paid by the lender).\n\n​How It Works\nDefault fee splitEach protocol fee is split between three parties:RecipientShareReferred user (rebate)20% of the feeReferrer30% of the feeProtocol50% of the feeThe 20% rebate is always credited to whoever is paying the fee at that stage, and the 30% share goes to that user’s referrer: the borrower (and their referrer) at loan start, the lender (and their referrer) at repayment and collateral transfer.How referrals apply across a loanEach stage is independent: only the referral relationship of the user paying the fee at that stage applies.StageWho pays the feeRebate (20%) and referrer share (30%) followLoan start (25% fee)BorrowerThe borrower and their referrerRepayment (10% fee)LenderThe lender and their referrerCollateral transfer (0.1% fee)LenderThe lender and their referrerExample: a lender (referred) is repaid on a loan, and the protocol charges $10 in fees at repayment: the lender receives a $2 rebate, the lender’s referrer earns $3, and the protocol retains $5.When does the referral take effect?A referral is applied when a referred user opens Offerbook through your share link and accepts the referral. Once accepted, the referral persists for all future fee-generating actions of that user.If a saved referral code is no longer valid (for example, if the referrer changed their vanity slug — see Vanity Slugs), it is cleared automatically. Users are not blocked from using Offerbook in the meantime.\n\n​Your Affiliate Page\nThe Affiliate page, the Affiliate tab of your Dashboard (also reachable at offerbook.jup.ag/affiliate), shows your referral activity and lets you customize your share link.\nThe page surfaces:\n\nYour Referral Link card: the share URL (with vanity slug if set, or a UUID fallback), a QR code, and a Copy Link button\nYour Referral Stats: total referrals and total earnings\nRecent Earnings: each reward with its token, amount, source user, type (Borrower or Lender), date and transaction link\nPeople Referred: each referred user with their volume, loans, offers, activity, join date and a link to their profile\n\n​Vanity Slugs\nBy default, your share URL uses a UUID code that is unique but not memorable. You can replace it with a vanity slug — a custom, readable identifier — that you control.\nValidation rulesVanity slug validation accepts:\nLetters (uppercase and lowercase)\nDigits\nUnderscores (_)\nHyphens (-)\nSlugs must be unique across all Offerbook users.Setting or changing your slugGo to your Affiliate page and edit the slug field. Once saved, your share URL is updated to use the new slug.Changing your slug invalidates the previous one. Anyone who saved the old link will no longer be attributed to you when they open it, and the old slug may be claimed by another user.Fallback to UUIDIf you have not set a vanity slug, your share URL uses a UUID code automatically. The UUID still works, but is harder to share verbally or print.\nSharing a referral link does not disclose anything about you: the URL carries only your UUID code, or the vanity slug you chose. A vanity slug is yours to pick, so choosing a recognisable one identifies you by design. Separately, Offerbook activity is recorded onchain and stays publicly visible there, independently of your referral link.\n\n​Sharing Your Link\nYour share URL is shown on your Affiliate page. Send it through any channel you prefer (social media, direct message, etc.). Anyone who opens Offerbook through your link gets your referral applied.\n\n​Claiming Rewards\nReferral earnings accumulate in the rewards claim table on your Affiliate page. Each row shows an unclaimed reward; you can claim them individually or in batches depending on the interface.\nClaiming is a standard onchain transaction signed from your wallet. There is no minimum claim threshold at the protocol level, but Solana transaction fees still apply.\nReferral rewards are paid in the same asset as the fee they originated from (USDC for loan start and repayment fees; collateral asset for collateral transfer fees).\n\n​FAQ\nCan I change my vanity slug after sharing it?Yes, but doing so breaks the previous link. Anyone who opens the old link after the change is no longer attributed to you, and the old slug may be claimed by someone else. Pick a slug you intend to keep.Are referral rewards taxable?Treatment of crypto referral rewards varies by jurisdiction. Offerbook does not provide tax advice. Consult a qualified tax professional in your country.","tokens":1292,"squid":"spider-02","role":"Liquidity Spider","at":1791347364305,"hash":"28d285921952c32ef699bdb534c2d426e026c7ad"}
{"url":"https://ethresear.ch/t/sealed-execution-auction/20060","domain":"ethresear.ch","title":"Sealed execution auction - Proof-of-Stake / Block proposer - Ethereum Research","text":"Sealed execution auction \n\n Proof-of-StakeBlock proposer\n\n mev\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 5\n\n 2\n\n read \n\n 12\n min\n\n Jul 2024\n\n 1 / 7\n\n Jul 2024\n\n Sep 2024\n\n post by aelowsson on Jul 13, 2024\n\n aelowsson\n\n Sealed execution auction\nSealed execution auction1792×1024 356 KB\nBy Anders.\nWhile working on the dynamic pricing auction I though of another way to hold the auction that also seems interesting. Posting a rough sketch here, although I am not yet certain of its viability. Thanks to Justin, Barnabé and Terence.\nIntroduction\nIn the process of enshrining proposer–builder separation (ePBS), it has been suggested that attesting and execution proposing should be more fully separated. Proposals such as execution tickets (ETs) and execution auctions (EAs) strive to allocate the right to propose execution blocks to entities other than the validators. This also facilitates MEV burn. There have been concerns (1, 2, 3) around insufficient early bidding in the MEV pricing auctions with a base fee floor used in EA. By considering the staking metagame, this issue is potentially resolved, but the resulting attester–builder integration can then by itself be problematic. There is also a general concern that the decided-upon auction design will induce MEV, and no definite specification among several alternatives for the auction design in ET. For this reason, it seems fruitful to explore an auction that facilitates true separation and does not induce MEV. One such mechanism recently proposed is the MEV resistant dynamic pricing auction. In the context of Vickrey auctions of execution rights, Timeboost under consideration by Arbitrum can also be mentioned.\nThis post proposes a Vickrey slot auction in two rounds to select a forthcoming execution proposer (akin to EA), referred to as a sealed execution auction (SEA). Staked builders make sealed bids for the right to propose an execution block. Bids are observed by attesters and then collated by the beacon proposer. In subsequent steps, builders reveal their bids, attesters observe the revealed bids, and the proposer once again collates them. The right to propose a forthcoming execution block is awarded to the highest bidder, paying according to the second-highest bid, with the payment burned.\nAuction\nStaked builders\nBuilders are staked at a level sufficient for the protocol to penalize them if they fail to reveal committed bids. The stake can also serve as a deposit account to pay for winning bids, or this account can be managed separately.\nSealed bids\nFigure 1 gives an overview of the auction. In the first round, each builder has the opportunity to make one sealed bid over a public P2P layer. There might be a small fee for making a bid, as a further anti-Sybil measure. Attesters observe the sealed bids that have come in at time T_1𝑇1. Around two seconds later, at T_2𝑇2, the beacon proposer collates sealed bids (including any bids it finds after T_1𝑇1), and broadcasts them in a structure. This structure may be a beacon block if the auction proceeds over two slots (see Timeline). At T_3𝑇3, attesters observe the structure and make sure that all previously observed bids at T_1𝑇1 have been included. If the bids were included in a beacon block, they will attest to the block contingent on correct and timely collation. If not included in a beacon block and the proposer equivocates on the structure, the subsequent block must be rejected.\nFigure 12386×1202 297 KB\nFigure 1. Sealed execution auction. Staked builders submit sealed bids before T_1𝑇1 and the proposer collates them at T_2𝑇2. At T_3𝑇3 attesters ensure that all bids they observed at T_1𝑇1 are part of the collated structure. Builders unseal the bids after T_3𝑇3 and attesters observe them at T_4𝑇4. The proposer then collates bids in a beacon block at T_5𝑇5 and attesters attests to the block at T_6𝑇6 contingent on correct collation. The highest unsealed bid wins, paying a fee corresponding to the second highest bid. The fee is burned. Builders that did not unseal their bids are penalized.\nRevealed bids\nIn the second round, after the T_3𝑇3 deadline, builders unseal their bids. They should not release before T_3𝑇3, because then the proposer can collude with other builders to release a bid structure with some bids placed after other bids were revealed. However, they do not need to observe the proposer’s structure before release, and can proceed right after the T_3𝑇3 mark.\nAttesters observe unsealed bids at T_4𝑇4. The proposer collates all unsealed bids it can find, including them in the beacon block at around T_5𝑇5. It may also include bids that were never unsealed, so that the associated builder can be penalized (this is a strict requirement in the single-slot design, because then the sealed bids have not been included in a previous beacon block). The highest bid is selected as the forthcoming execution proposer, and the second highest bid value is deducted from the winner’s balance and burned. At T_6𝑇6, attesters attest to the beacon block, contingent on a correct collation by the beacon proposer.\nRationale\nCollusion between builders and proposers to reduce the burn as in the MEV burn design is arguably resolved; without stakers actively burning each others’ MEV revenue.\n\nThere is no longer a stable equilibrium to rely on for colluding parties, such as late bidding.\nThe proposer no longer has leverage to punish early bidders by electing another builder.\nChiseling at a cartel is trivial, simply by truthful bidding.\nEvery bid fulfills a real purpose, as opposed to early bids in MEV pricing auctions.\nThere is no avenue for discouragement attacks, since there is no substantial proposer revenue to remove.\n\nPenalization\nSeveral actions must be penalized. If the proposer omits an observed sealed bid in the first round or an observed revealed bid in the second round, the proposer’s block must be rejected by attesters. If the proposer fails to release the structure of the sealed bids in the first round or the revealed bids in the second round in a timely manner (reaching attesters before T_3𝑇3 and T_6𝑇6 respectively), the proposer’s block must also be rejected by attesters. Edit 18-07-24: As mentioned in the previous section and also further discussed in the next, a builder that does not unseal its bid on time will be penalized. This is facilitated in Figure 1 by including the sealed bid in the beacon block.\nIt is possible that a builder made a mistake and will be unable to pay for its bid, if the bid is higher than its staked amount. This will be penalized by burning some proportion of the stake, for example corresponding to the amount of the actual winning bid, some fixed amount of ETH, or its entire stake. In any case, if its unbacked bid is the highest, the builder will not win the auction. The second highest bid will instead be selected as the execution proposer, paying the third highest bid, etc. If the bid underpinning the fee (normally the second highest bid) lacks funds, the bid below it will be set to underpin the fee.\nBuilder–proposer collusion and possible remedies\nA potential cause for concern is the following scenario: a builder determines that it would not like to unseal its bid (potentially after observing other builders’ unsealed bids). It does not want to subject itself to a penalty, so it colludes with the proposer to have it miss the slot. Is this a cause for concern? This ultimately depends on if the builder benefits more by not revealing its bid than the proposer loses from a missed proposal. This could be the case when bidding for the right to propose the current or next slot, and the expected MEV falls drastically between bid commit and reveal (i.e., a value-in-flight problem). Another potential cause for concern is if the value instead increases drastically. The proposer might then pose an ultimatum to the winning builder: “send me some part of expected profits, or I will fail to propose”. A failed proposal would leave the builder without rights for the slot. An ultimatum game emerges. The other builders might also be inclined to pay the proposer, in order to starve off competition, and the winning builder would then also need to pay the proposer to ensure it proposes.\nWhile the outlined collusion scenarios may be a bit speculative, it can still be interesting to explore possible remedies. A few directions then spring to mind:\n1. Penalize beacon proposers for missed beacon blocks\nProposers already lose out on revenue if they miss their block. However, this loss might not be a sufficient deterrent. It would therefore be beneficial to also penalize proposers if they miss their blocks. Otherwise, if the penalty applied to a builder is substantially higher than the loss from missed proposals for the proposer, that builder penalty will be less meaningful. Builders could seek to collude to let the proposer take the fall. In essence, if the value to the builder, its competitors, or the proposer, of having the builder not win the auction, is higher than the loss to the proposer of not proposing, then collusion or an ultimatum game may emerge.\n2. Require subsequent beacon proposers to conclude the auction\nIs it possible to have the next beacon proposer conclude the auction? This depends to some extent on the Timeline of the auction.\n\nSingle-slot design: In the single-slot design, attesters do not signal if they rejected a block because of an incorrect initial structure, a late structure, or an incorrect or missing beacon block. A way to deal with this is that the next proposer presents the correct outcome of the auction, in its own view, and that the attesters of n+2𝑛 +2 either reject or confirm the new block based on the proposed outcome. But this means that these attesters must also have tracked events in the previous slot as they unfolded, and any split views (e.g., from a rather late sealed builder bid) may persist for several blocks in a row.\nTwo-slot design: If the auction commences over two slots, there will be an agreed-upon set of committed sealed bids, or the first beacon block will have been rejected. The second step of the auction can then be concluded in a subsequent slot without requiring attesters to have observed the commit-phase. The requirement is to still have attesters make an observation of unsealed bids sometime before the proposer deadline. But that point need not necessarily be taken from the earlier slot. A benefit is that this might starve off split views.\n\nOne thing to note is that if a builder finds it worthwhile to pay the first proposer to not propose, in order to avoid revealing a bid without being penalized, it might be willing to pay also a second proposer for not proposing. However, the price will go up, and the number of potential collusion partners scheduled to propose in a row may not be too large. It should also be noted that when auctioning off rights for slot n+i𝑛 +𝑖, there is a requirement that the delay until the conclusion of the auction does not surpass i𝑖. In other words, it will only be possible to repeat a failed auction around i𝑖 times. Note that this requirement is also due to the fact that the order in which auctioned off execution rights are provided cannot be altered ex post, since the expected MEV for slots may vary.\n3. Skip the beacon proposal reveal\nIs it possible to skip the beacon proposal reveal? If all bids are unsealed, the outcome will be evident to every participant. The mechanism can then be designed such that the winning builder safely can propose its block at the assigned slot, even if a proposer has not collated the outcome and presented a winner. The previous option 2 is focused on concluding the auction via a beacon proposal in time before the execution proposal, but the point here is that the auction does not need to be concluded by the proposer as long as the outcome is evident to the builder and can be verified by attesters when the builder proposes its block. The sealed bids must then have been included in a beacon block, as in the two-slot design.\nThreshold decryption via a committee of attesters (h/t Barnabé) is one option here. The bids are decrypted by a committee, and the winner made evident to the builders/forthcoming proposer and attesters. There would still be liveness concerns, but collusion would be more difficult. It can be noted that as long as all builders unseal their bids in a timely manner (even without threshold decryption), the winning builder can proceed with the proposal. Always penalizing builders that do not unseal their bids before T_4𝑇4 could then seem sufficient, but the issue is that split views would emerge in potential designs. In any case, the outcome would also at some point need to be included in a block, to process payment and penalties.\n4. Auction of a future slot to reduce value-in-flight\nThe Vickrey auction is truthful, allowing builders to bid their true value at the commit deadline. Since value-in-flight is the most likely cause for collusion, auctioning off a slot further removed from the present will temper the issue.\nAuctioning off multiple slots\nNote that to avoid having a failed beacon proposal result in a missing execution proposal, there is also the option to sell the right to two execution proposals in the subsequent slot (with builders bidding their inverse demand curve and paying according to the second and third highest bids).\nTimeline\nThis section presents two hypothetical timelines for the auction, either when only including unsealed bids in the beacon block (single-slot auction) or when including both sealed and unsealed bids in separate beacon blocks (two-slot auction).\nSingle-slot auction\nExample of a slot auction with a tight schedule enacted mostly during a single slot n𝑛, auctioning off execution proposal rights for a later slot n+i𝑛 +𝑖.\n\nT_x𝑇𝑥\nTime\nOverview\nDescription\n\nT_1𝑇1\n4s\nSealed bid deadline\nAttesters of slot n+1𝑛 +1 observe all sealed bids. Builders must have broadcast them some time before this point to ensure eligibility.\n\nT_2𝑇2\n6s\nProposer collates bids\nThe proposer of slot n+1𝑛 +1 releases a structure containing all sealed bids it can find.\n\nT_3𝑇3\n8s\nAttesters observe collation\nAttesters of slot n+1𝑛 +1 observe the proposer’s structure to ensure it contains all bids they had seen at T_1𝑇1 and that the release of this structure is timely.\n\nT_4𝑇4\n10s\nRevealed bid deadline\nAttesters of slot n+1𝑛 +1 observe unsealed bids. Builders must have broadcast them some time before this point (but after T_3𝑇3) to ensure eligibility.\n\nT_5𝑇5\n0s (12s)\nProposer collates in beacon block\nThe proposer of slot n+1𝑛 +1 includes every unsealed bid it can find in the block, also indicating sealed bids that were never unsealed. A winner is declared.\n\nT_6𝑇6\n4s (12+4s)\nAttesters confirm collation\nAttesters of slot n+1𝑛 +1 confirm that the proposer fulfilled its role and collated bids in a timely manner by attesting to the block.\n\nNote that builders can unseal their bids directly after T_3𝑇3. This should allow attesters of slot n+1𝑛 +1 to observe revealed bids at 10s. However, if needed, the entire schedule could be pushed back slightly.\nTwo-slot auction\nHere is an example of a schedule for the two-slot auction:\n\nT_x𝑇𝑥\nTime\nOverview\nDescription\n\nT_1𝑇1\n10s\nSealed bid deadline\nAttesters of slot n+1𝑛 +1 observe all sealed bids. Builders must have broadcast them some time before this point to ensure eligibility.\n\nT_2𝑇2\n0s (12s)\nProposer collates bids\nThe proposer of slot n+1𝑛 +1 includes all sealed bids it can find in its beacon block.\n\nT_3𝑇3\n4s (12+4s)\nAttesters confirm collation\nAttesters of slot n+1𝑛 +1 confirm that the proposer fulfilled its role and collated bids in a timely manner by attesting to the block.\n\nT_4𝑇4\n8s (12+8s)\nRevealed bid deadline\nAttesters of slot n+2𝑛 +2 observe unsealed bids. Builders must have broadcast them some time before this point (but after T_3𝑇3) to ensure eligibility.\n\nT_5𝑇5\n0s (12+12s)\nProposer collates in beacon block\nThe proposer of slot n+2𝑛 +2 includes every unsealed bid it can find in the block, potentially indicating sealed bids that were never unsealed. A winner is declared.\n\nT_6𝑇6\n4s (12+12+4s)\nAttesters confirm collation\nAttesters of slot n+2𝑛 +2 confirm that the proposer collated all unsealed bids by attesting to the block.\n\n Sealed transactions\n\n Rainbow roles & incentives: ABPS + FOCILR + AS\n\n A design for APS-burn in the context of a Decentralized L2\n\n Practical endgame on issuance policy\n\n 5\n\n 2\n\n read \n\n 12\n min\n\n post by quintuskilbourn on Jul 15, 2024\n\n post by aelowsson on Jul 16, 2024\n\n post by quintuskilbourn on Jul 16, 2024\n\n post by aelowsson on Jul 16, 2024\n\n post by aelowsson on Jul 18, 2024\n\n 2 months later\n\n post by aelowsson on Sep 22, 2024\n\n Powered by Discourse","tokens":4208,"squid":"spider-04","role":"Research Spider","at":1791347368577,"hash":"c82a5ae890a9a79dc319e6e0ae9f49bee65b6382"}
{"url":"https://docs.jup.ag/user-docs/earn/offerbook/fees-and-costs","domain":"docs.jup.ag","title":"Fees & Costs - Jupiter Documentation","text":"Offerbook is a peer-to-peer lending protocol on Solana where users borrow or lend USDC against onchain collateral. This page covers the protocol fees charged at each stage of a loan, the Solana network fees and account rent, and the referral program.\nCosts on Offerbook fall into three types: network fees (Solana gas), account rent (a refundable deposit), and protocol fees (Offerbook’s cut). These are explained in detail below.\nProtocol fees are set in the onchain configuration and can be updated by protocol admins. The rates described below are the current defaults.\n\n​Protocol Fees\nThese are Offerbook’s cut, taken in the loan token (USDC). They apply at three stages of a loan.\n1At loan start — 25% of estimated interest (paid by the borrower)When a loan is opened (an offer is accepted), the program estimates the total interest for the full loan term. A fee equal to 25% of that estimated interest is taken immediately, paid in USDC by the borrower.How this works in practice:\nIf a lender fills a borrow offer: the borrower receives the USDC amount minus the fee.\nIf a borrower fills a lend offer: the borrower pays the fee right after receiving the USDC.\nThe interest is calculated based on the APR (Annual Percentage Rate) or APY (Annual Percentage Yield) defined at offer creation, applied to the full loan duration.2At repayment — 10% of interest (paid by the lender)When the borrower repays the loan, the borrower pays the full interest to the lender. A fee equal to 10% of the interest is then deducted from the lender’s return.Example: On a 100 USDC loan with 1% interest (1 USDC), the lender receives 0.9 USDC in interest. The remaining 0.1 USDC goes to the protocol.3At collateral transfer — 0.1% of collateral (paid by the lender)If the loan is not repaid after maturity and the lender claims the collateral, a 0.1% fee is deducted from the collateral before it is transferred to the lender.No fee is charged on collateral transfers involving NFT collateral.\n\n​Effective APR / APY\nThe interface displays the Effective APR (borrower side) and Effective APY (lender side) in the offer summary. These rates account for platform fees automatically.\nEffective APR is higher than the offer APR because the 25% upfront fee is added on top of the interest the borrower owes.\nExample: an offer at 30% APR becomes 37.5% Effective APR (30% × 1.25).\nEffective APY is lower than the offer APY because the 10% fee is deducted from the interest received by the lender.\nExample: an offer at 5% APY becomes 4.5% Effective APY (5% × 0.9).\n​How rates appear in the interface\nThe borrowing flow prices the upfront fee directly into the displayed rate: the APR shown is all-in (offer APR × 1.25), and the breakdown line expresses the split in APR points. An offer at 16% APR displays as a 20% all-in APR, with the line “Lender keeps 16% · 4% protocol fee”: 16% is the offer rate earned by the lender (gross), and 4 points is the 25% upfront fee.\nOn the lending side, the offer summary shows the Effective APY (offer APY × 0.9) with the note “Includes a 10% platform fee on interest, deducted from your return at repayment”: an offer at 16% APY shows a 14.4% Effective APY.\n\n​Interest Calculation\nInterest is pro-rated from the annual rate over the loan duration:\nInterest = principal × APR × (loan duration in days / 365)\nExample: borrowing 8,000 USDC at 35% APR for 3 days costs 8,000 × 0.35 × 3/365 ≈ 23 USDC of interest. The 25% upfront fee is computed on this estimated interest (≈ 5.75 USDC).\n\n​Interest on Early Repayment\nBorrowers can repay at any time before maturity, but the full interest for the agreed loan duration is always owed. There is no partial interest or fee reduction for early repayment.\n\n​Intents\nIntents are off-chain and entirely free. Posting, editing and cancelling an intent require only a wallet signature: no network fees, no account rent, no protocol fees. Standard fees apply only if a matching offer is filled and becomes a loan. See Intents.\n\n​Fee Summary\nStageWho paysFeeBasisLoan startBorrower25%Estimated total interest (USDC)RepaymentLender (deducted from interest received)10%Interest (USDC)Collateral transferLender (deducted from collateral received)0.1%Collateral value (no fee on NFT collateral)\n\n​Understanding the Three Cost Types\nIt helps to separate the three different things you pay for on Offerbook. They behave differently: two are gone for good, one comes back to you.\nNetwork feeThe Solana “gas” fee, paid on every transaction. Tiny (around 0.000005 SOL per signature). Never refunded.Account rentA deposit, not a fee. Solana requires you to fund any new account you create. Most of it is refunded when the account is later closed (see table below).Protocol feeOfferbook’s cut, taken in the loan token (USDC). Never refunded (a share may go to a referrer).\nRule of thumb: fees are gone, rent comes back. The largest SOL numbers you see when using Offerbook are usually rent (a refundable deposit), not a cost.\n\n​Account Rent\nAccount rent is a refundable deposit fixed by account type. The amounts are determined by Solana and do not change.\nAccountRent (SOL)Paid whenRefundable?User account0.00233856First time you use OfferbookNot currently (expected to change)Escrow account (per asset)0.00203928First time you deposit a given assetYes — when you withdraw the assetOffer account0.00940992Each time you create an offerYes — when the offer is filled, cancelled, or expiresLoan account0.00651456When a loan opensNot currently (expected to change)Loan vault0.00203928When a loan opensYes — when the loan is repaid or the collateral is claimed\nYour escrow wallet holds a separate escrow account for each different asset you deposit, so borrowers typically open more of them over time than lenders, who generally only need one for USDC.\nOn a Solana explorer, an account holding collateral can show a large SOL figure. This is not rent. When the collateral is wrapped SOL (wSOL), the wrapped amount sits inside the account, so the figure shown is the small rent plus the collateral itself. The collateral is yours.\n\n​Referral Program\nProtocol fees can be split into referral rewards: at every stage where a fee is charged, the user paying the fee receives a rebate and their referrer earns a share. The full split, how it applies across a loan, and how to create your share link are covered in Affiliate & Referrals.","tokens":1591,"squid":"spider-02","role":"Liquidity Spider","at":1791347374557,"hash":"197d777401718d46b8974cc4c76bbabceb8cf196"}
{"url":"https://ethresear.ch/c/proof-of-stake/block-proposer/10","domain":"ethresear.ch","title":"Latest Proof-of-Stake/Block proposer topics - Ethereum Research","text":"Latest topics in Block proposer\n\n Proof-of-Stake\n\n Block proposer\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 Block proposer category\n\n This is for discussing the implementation of the full proof of stake system. E.g., going beyond PoS/PoW hybrid to full PoS.\n\n 0\n\n 1.6k\n\n Oct 2017\n\n ePBS, distilled\n\n mev\n\n 10\n\n 874\n\n Aug 29\n\n Building towards Multi-Party Block Construction\n\n mev,proposer-builder-separation,censorship-resistance\n\n 2\n\n 676\n\n Jun 3\n\n Majority Fork Protection Through Distributed Validator Technology: A Novel Approach to Network Resilience\n\n security\n\n 0\n\n 245\n\n Mar 4\n\n An Observation on Ethereum’s Blockspace Market\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 13\n\n 11.8k\n\n Sep 2025\n\n Block Constraints Sharing: Multi-Relay Inclusion Lists & beyond\n\n mev,proposer-builder-separation,censorship-resistance\n\n 0\n\n 292\n\n Jul 2025\n\n Relay Block Merging: Boosting Value & Censorship Resistance\n\n mev,proposer-builder-separation,censorship-resistance\n\n 2\n\n 1.2k\n\n Jun 2025\n\n Relay Inclusion Lists\n\n mev,proposer-builder-separation,censorship-resistance\n\n 8\n\n 1.3k\n\n May 2025\n\n Make Block Proposal Decentralized With One-Time Randomness\n\n proposer-builder-separation\n\n 0\n\n 185\n\n May 2025\n\n Auditable Builder Bids with Optimistic Attestations in ePBS\n\n proposer-builder-separation\n\n 1\n\n 618\n\n Apr 2025\n\n BITE protocol slides\n\n 0\n\n 101\n\n Apr 2025\n\n Censorship Insurance Markets for BRAID\n\n censorship-resistance\n\n 4\n\n 1.3k\n\n Feb 2025\n\n zkFOCIL: Inclusion List Privacy using Linkable Ring Signatures\n\n censorship-resistance\n\n 5\n\n 1.8k\n\n Feb 2025\n\n In-Protocol Transaction Ordering\n\n mev\n\n 0\n\n 572\n\n Nov 2024\n\n Blob EIPs and Minimum Validator Requirements\n\n data-availability\n\n 15\n\n 867\n\n Oct 2024\n\n AUCIL: An Auction-Based Inclusion List Design for Enhanced Censorship Resistance on Ethereum\n\n censorship-resistance\n\n 2\n\n 1.4k\n\n Oct 2024\n\n Honest MEV: a Theoretical Perspective\n\n 0\n\n 445\n\n Oct 2024\n\n FOCIL CL & EL workflow\n\n 2\n\n 1.1k\n\n Oct 2024\n\n Sealed execution auction\n\n mev\n\n 6\n\n 4.6k\n\n Sep 2024\n\n FOCIL Resource Design Considerations\n\n 0\n\n 465\n\n Sep 2024\n\n Timestamp Ordering in MCP for Timing Games\n\n mev\n\n 2\n\n 734\n\n Sep 2024\n\n Mechan-stein (alt. Franken-ism)\n\n mev,censorship-resistance\n\n 6\n\n 1.3k\n\n Sep 2024\n\n DoS on block proposers in PoS and block builders in PBS\n\n 0\n\n 161\n\n Aug 2024\n\n Advantage of Pipelining Consensus and Execution: Delayed Execution\n\n 6\n\n 6.1k\n\n Aug 2024\n\n Inclusion List Timing Constraints\n\n 0\n\n 1.4k\n\n Aug 2024\n\n Concurrent Block Proposers in Ethereum\n\n 10\n\n 7.9k\n\n Aug 2024\n\n On block-space distribution mechanisms\n\n mev\n\n 4\n\n 6.4k\n\n Jul 2024\n\n MEV resistant dynamic pricing auction of execution proposal rights\n\n mev\n\n 0\n\n 6.8k\n\n Jul 2024\n\n Block Building is not just knapsack!\n\n 8\n\n 5.7k\n\n Jul 2024","tokens":735,"squid":"spider-04","role":"Research Spider","at":1791347378781,"hash":"68b46ad7dffaa733ed3bdb5a653b6c10f5d570f9"}
{"url":"https://www.metaplex.com/docs/smart-contracts/genesis/getting-started","domain":"metaplex.com","title":"Getting Started with Genesis - Launch a Token on Solana","text":"Understand the Genesis token launch flow before building. Whether you're planning a presale, fair launch, or token sale on Solana, this guide explains each step from SPL token creation to distribution. No-Code OptionIf you want to launch a token without writing code, use the Metaplex token launchpad. The guides below are for developers looking to build a custom launchpad platform or host a token sale on their own website.Ready to Build?Once you understand the flow:JavaScript SDK - Installation and function referenceLaunch Pool - Complete tutorial for proportional distributionPresale - Complete tutorial for fixed-price salesThe Genesis FlowEvery Genesis launch follows this lifecycle:┌─────────────────────────────────────────────────────────────────┐\n│ 1. INITIALIZE │\n│ Create Genesis Account → Mint token → Hold supply in escrow │\n└─────────────────────────────────────────────────────────────────┘\n ↓\n┌─────────────────────────────────────────────────────────────────┐\n│ 2. ADD BUCKETS │\n│ Configure distribution (Launch Pool, Presale, Treasury) │\n└─────────────────────────────────────────────────────────────────┘\n ↓\n┌─────────────────────────────────────────────────────────────────┐\n│ 3. FINALIZE │\n│ Lock configuration → Activate time conditions │\n└─────────────────────────────────────────────────────────────────┘\n ↓\n┌─────────────────────────────────────────────────────────────────┐\n│ 4. DEPOSIT PERIOD │\n│ Users deposit SOL based on bucket type │\n└─────────────────────────────────────────────────────────────────┘\n ↓\n┌─────────────────────────────────────────────────────────────────┐\n│ 5. TRANSITION │\n│ Execute end behaviors → Route funds to treasury │\n└─────────────────────────────────────────────────────────────────┘\n ↓\n┌─────────────────────────────────────────────────────────────────┐\n│ 6. CLAIM PERIOD │\n│ Users claim tokens → Team claims raised funds │\n└─────────────────────────────────────────────────────────────────┘\n ↓\n┌─────────────────────────────────────────────────────────────────┐\n│ 7. POST-LAUNCH (Optional) │\n│ Revoke mint/freeze authorities for security │\n└─────────────────────────────────────────────────────────────────┘\nStep 1: InitializeWhat happens: You create a Genesis Account which mints your token and holds the entire supply in escrow.You provide:Token metadata (name, symbol, URI)Total supply (with decimals)Quote token (usually wSOL)Result: A new SPL token exists, controlled by the Genesis Account until distribution.Token Supply PlanningSPL tokens use 9 decimals by default:Desired SupplyWith 9 Decimals1 token1,000,000,0001,000 tokens1,000,000,000,0001 million tokens1,000,000,000,000,0001 billion tokens1,000,000,000,000,000,000Important: Your total supply must equal the sum of all bucket allocations.Step 2: Add BucketsWhat happens: You configure how tokens will be distributed by adding buckets.Bucket TypesBucketTypePurposeLaunch PoolInflowProportional distribution based on depositsPresaleInflowFixed-price sale up to a capUnlockedOutflowTreasury that receives raised fundsExample ConfigurationA typical launch uses:Inflow bucket (Launch Pool OR Presale) - Collects SOL from participantsOutflow bucket (Unlocked) - Receives collected SOL for team/treasuryToken Allocation Example (1 million tokens):\n├── Launch Pool: 800,000 tokens (80%)\n└── Unlocked: 200,000 tokens (20% team allocation)\n\nFund Flow:\nUsers deposit SOL → Launch Pool → End Behavior → Unlocked Bucket → Team claims\nTime ConditionsEach bucket has four time conditions:ConditionControlsDeposit StartWhen users can begin depositingDeposit EndWhen deposits closeClaim StartWhen users can claim tokensClaim EndWhen claims closeUse Unix timestamps (seconds, not milliseconds).Step 3: FinalizeWhat happens: Configuration locks permanently. The launch activates based on time conditions.Before vs After FinalizationBeforeAfterCan add bucketsNo more bucketsCan modify settingsSettings lockedLaunch inactiveLaunch active (per time conditions)Finalization is irreversible. Triple-check your bucket allocations, time conditions, and end behaviors before finalizing.Step 4: Deposit PeriodWhat happens: Users deposit SOL into your inflow bucket(s).Launch Pool: Users deposit SOL, can withdraw with 0% feePresale: Users deposit SOL at fixed price, up to a per-user deposit cap (maximum amount each user can contribute). See Presale for presale fees.Step 5: TransitionWhat happens: After deposits close, execute end behaviors to route funds.Common end behavior: Send 100% of collected SOL to the Unlocked bucket (treasury).You can split funds across multiple destinations:80% to treasury20% to liquidity pool bucketStep 6: Claim PeriodWhat happens:Users claim tokens based on their depositTeam claims raised SOL from the Unlocked bucketToken DistributionLaunch Pool: userTokens = (userDeposit / totalDeposits) × bucketAllocationPresale: userTokens = userDeposit / pricePerTokenStep 7: Post-Launch (Optional)What happens: Revoke token authorities for security.Mint authority - Revoke so no more tokens can ever be mintedFreeze authority - Revoke so tokens can never be frozenThis signals to holders and rug checkers that the token supply is fixed.Authority revocation is irreversible. Only do this when your launch is complete.Common ErrorsErrorCauseSolutionalready finalizedTrying to modify after finalizeCreate new Genesis Accountinvalid total supplyBucket allocations don't match supplyEnsure allocations sum to totaltime conditions overlapConflicting timestampsUse sequential time windowsdeposit period not activeOutside deposit windowCheck timestampsPlanning ChecklistBefore you start building:[ ] Decide on launch mechanism (Launch Pool for fair launch/crowdsale, Presale for fixed-price token sale)[ ] Calculate total token supply with decimals[ ] Plan bucket allocations (must sum to total supply)[ ] Set time windows (deposit start/end, claim start/end)[ ] Decide end behaviors (where do raised funds go?)[ ] Prepare token metadata (name, symbol, image URI)FAQWhat does initializing a Genesis Account create?It creates a new SPL token with metadata, a master coordination account (the Genesis Account PDA), and mints the total supply to be held in escrow for distribution.Can I add more buckets after finalizing?No. Finalization is permanent. You cannot add more buckets or change configurations. Plan your complete bucket structure before finalizing.What's the difference between inflow and outflow buckets?Inflow buckets collect SOL from users (Launch Pool, Presale). Outflow buckets receive tokens or SOL via end behaviors—typically an Unlocked Bucket for team/treasury claims.When does the launch become active?After finalization, the launch activates based on your bucket time conditions. Users can participate when the current time is within a bucket's deposit window.How do I calculate token supply with decimals?Multiply your desired supply by 10^decimals. For 1 million tokens with 9 decimals: 1,000,000 × 1,000,000,000 = 1,000,000,000,000,000.Can I use a token other than SOL for deposits?Yes. Set quoteMint to any SPL token. However, wSOL is standard for SOL-denominated launches.GlossaryTermDefinitionGenesis AccountPDA that coordinates the launch and holds tokensInflow BucketBucket that collects deposits from usersOutflow BucketBucket that receives funds via end behaviorsLaunch TypeThe underlying mechanism of a launch (launchpool or presale). Set on-chain retroactively by a backend crank. Queryable via SDK or REST APIFinalizeLock configuration and activate the launchTime ConditionUnix timestamp controlling bucket phasesEnd BehaviorAutomated action when deposit period endsTransitionInstruction that executes end behaviorsQuote TokenToken users deposit (usually wSOL)Next StepsReady to build? Choose your token launch type:Launch a Token - End-to-end token launch guideJavaScript SDK - Install and configureLaunch Pool Tutorial - Fair launch with proportional distributionPresale Tutorial - Fixed-price token sale","tokens":1990,"squid":"dotcat","role":"Tooling Spider","at":1791347381692,"hash":"48d492cd3c8ca6f69b2dd621a92070a5bee6c765"}
{"url":"https://docs.jup.ag/user-docs/earn/offerbook/security-and-risks","domain":"docs.jup.ag","title":"Security & Risks - Jupiter Documentation","text":"Offerbook is a peer-to-peer lending protocol on Solana where users borrow or lend USDC against onchain collateral. This page covers the risk model: what types of risk Offerbook removes by design, what types of risk remain, and the specific considerations for borrowers and lenders.\nOfferbook is a fully permissionless protocol. Anyone can participate: both borrowers and lenders publish offers with their own terms, expressing their intentions openly without restrictions or approval. There are no price oracles, no price-based liquidations, and no intermediaries.\nThis openness means that risk evaluation is the responsibility of each user. Offerbook removes price-based liquidation risk, but does not remove market risk.\n\n​What Offerbook Removes\nPrice-based liquidation riskCollateral is never liquidated due to market price movements during the loan. Even if the collateral loses 90% of its value mid-loan, nothing happens until maturity.Oracle riskOfferbook does not rely on price oracles for loan execution. No risk of oracle manipulation, stale price feeds, or oracle downtime affecting your loan.Intraloan volatility riskPrice swings during the loan duration do not trigger margin calls, adjustments, or forced closures. Loan terms are immutable once the loan starts.\n\n​What Remains\nCollateral price uncertaintyThe value of the collateral at maturity may be higher or lower than at loan creation. This risk exists for both sides.Opportunity costCollateral is locked for the full loan duration. It cannot be used, traded, or withdrawn until the loan is resolved, regardless of market opportunities.Counterparty-style exposureLenders are exposed to the quality and price trajectory of the collateral asset they accept. If the collateral is illiquid or volatile, the lender carries that risk.\n\n​Risk for Borrowers\nIf you do not repay by maturity, the lender can claim your entire collateral at any moment by signing a transaction. While you can technically still repay until the lender claims, do not rely on this window.\nKey risk factors:\n\nRepayment timing is your responsibility. Use the calendar reminder added at offer acceptance, and enable notifications to receive a Loan due soon alert 2 hours before maturity (see Settings & Notifications).\nFull interest is always owed, regardless of when you repay. Early repayment does not reduce the interest amount or fees.\nCollateral is locked for the full loan duration. You cannot access it until the loan is resolved, even if you find a better opportunity elsewhere.\nThe collateral transfer is not automatic. If the lender does not claim immediately after maturity, the loan stays open and you can still repay. But this is at the lender’s discretion.\nNetwork congestion or transaction failures at maturity can prevent you from repaying in time. Plan your repayment with a margin to account for potential delays.\n\n​Risk for Lenders\nCollateral value is not monitored during the loan. If the collateral loses significant value before maturity, you may need to claim and sell an asset worth less than the USDC you lent.\nKey risk factors:\n\nA rational borrower may choose not to repay. If the collateral’s value drops below the borrowed amount, walking away can be the borrower’s best move. Defaults are a normal outcome of the model, and the collateral is your only recourse: price this into the LTV and the rate you accept.\nHigher LTV (Loan-to-Value, the ratio between borrowed USDC and collateral value) increases the risk that collateral may not cover the lent amount if the borrower defaults.\nCollateral liquidity matters. If the collateral asset has low trading volume, selling it after claiming may result in slippage or losses.\nClaiming is manual. After maturity, if the borrower has not repaid, you must sign a transaction to receive the collateral. The transfer is not automatic. Claiming triggers the collateral transfer.\nA 0.1% fee is deducted from the collateral at transfer (no fee on NFT collateral).\nReceiving the collateral token, not USDC. If the borrower defaults, you receive the collateral itself. Selling it to recover USDC is a separate action, exposed to market conditions at that moment.\nEvaluate the collateral asset’s volatility, market depth, and fundamentals before accepting an offer.\n\n​Other Risks to Consider\n​Smart Contract Risk\nOfferbook is a smart contract protocol on Solana. As with any onchain protocol, there is residual risk that a bug, vulnerability, or exploit could affect funds. Offerbook has been audited (see Audits), but no audit guarantees the absence of all risks.\n​Solana Network Risk\nOfferbook depends on the Solana network. Network downtime, congestion, or fee spikes can affect your ability to:\n\nRepay a loan before maturity\nClaim collateral after maturity\nCreate or accept offers\nWithdraw from your escrow\n\nAlways factor in network conditions when planning critical actions.\n​Asset-Specific Risk\nThe collateral and lent assets are subject to their own risks (token contract risk, deauthorization, freezing, depegging for stablecoins, etc.). Verify the assets you interact with.\n​Yield-Bearing Collateral\nIf your collateral is a yield-bearing token (such as a liquid staking token), the yield mechanics can affect the asset during the loan:\n\nYield that accrues directly in the token value will grow during the loan.\nYield that requires manual claiming may not be accessible while the collateral is locked.\n\n​Off-chain Signatures\nSome Offerbook actions are signed messages rather than transactions: posting, editing or cancelling an intent, and signing in to Chat or sending messages. These signatures cost nothing, move no funds and are never broadcast onchain. Ledger wallets sign an equivalent memo transaction instead, which is also never broadcast. Always read what your wallet asks you to sign: a legitimate Offerbook message signature never requests a token approval or a transfer.\nIntents are public. The terms you advertise and the wallet that posted them are visible to anyone, and an intent may never result in a loan. See Intents.\n\n​Key Principle\nOfferbook shifts risk management from automated, price-based systems to user-defined, time-based terms. Both borrowers and lenders must evaluate their exposure before committing to a loan. There is no fallback if you misjudge the collateral, the duration, or the timing.\n\n​Audits\nOfferbook has been audited by Cantina and Guardian.\n\nCantina Audit (May 21, 2026)\nGuardian Audit (July 31, 2026)","tokens":1613,"squid":"spider-02","role":"Liquidity Spider","at":1791347384631,"hash":"8133b60d29f9aeeba52bfa4b905208a1b7496540"}
{"url":"https://ethresear.ch/t/block-constraints-sharing-multi-relay-inclusion-lists-beyond/22752/1","domain":"ethresear.ch","title":"Block Constraints Sharing: Multi-Relay Inclusion Lists & beyond - Proof-of-Stake / Block proposer - Ethereum Research","text":"Block Constraints Sharing: Multi-Relay Inclusion Lists & beyond \n\n Proof-of-StakeBlock proposer\n\n mev,proposer-builder-separation,censorship-resistance\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jul 2025\n\n 1 / 1\n\n Jul 2025\n\n Jul 2025\n\n post by remosm on Jul 16, 2025\n\n remosm\n\n Co-authored by Michael, with Kubi and George from Gattaca. Special thanks to Alex, Max, and Jason for the discussions and suggestions. Feedback is not necessarily an endorsement.\nIntroduction\nThis post introduces Multi-Relay Inclusion Lists (mrIL), a way for relays to converge on a single shared inclusion list with minimal overhead. This increases Ethereum’s censorship resistance by reducing the discretion any individual relay may exercise over the contents of the inclusion list.\nRelays are incentivized to opt-into the design as it reduces the marginal cost a builder incurs when delivering blocks to individual relays with diverging rILs. This reflects as a higher likelihood of receiving builder blocks, and allows relays with low market share to stay competitive.\nThe proposed protocol can be trivially extended to converge on a shared list of any signed proposer commitments, minimizing the slashing risk of such commitments (like preconfirmations) by allowing each relay to enforce block compliance in a more informed way.\nThis improves the risk adjusted return from proposer commitments, which may result in additional proposer opt-in, and ultimately may reduce the risk margin charged to users.\nThis article is an extension to our previous work on relay inclusion lists, and complementary to relay block merging. Together, these components increase block value, and provide additional censorship resistance for mempool- and private- transactions respectively.\nImplementation and Transaction Flow\nAs relays are incentivized to converge on a shared inclusion list, a lean implementation without multi-round communication is possible:\n\nEach relay r_i𝑟𝑖 builds a local inclusion list L_i𝐿𝑖 for the current slot and exposes it at the get_local_il() endpoint.\nRelays pull L_1,...,L_n𝐿1,...,𝐿𝑛 from peers and for each transaction t𝑡 observed count the number of lists it appears in:\n\nf(t) = \\#\\{j \\in \\{1,\\dots,n\\} \\mid t\\in L_j\\}\n𝑓(𝑡)=#{𝑗∈{1,…,𝑛}∣𝑡∈𝐿𝑗}\n\nEach relay constructs a candidate shared list S_i𝑆𝑖 by sorting transactions into it in descending frequency order up to the maximum byte size. Ties are broken lexicographically via the transaction hash.\n\n\\text{Order: }t_1,\\dots,t_n \\text{ sorted by } f(t) \\text{ descending, then hash}(t) \\\\ S_i = \\{t_1, \\dots, t_k\\} \\text{ where } k = \\max\\{j : \\sum_{m=1}^j \\text{bytes}(t_m) \\leq 8\\text{KB}\\}\nOrder: 𝑡1,…,𝑡𝑛 sorted by 𝑓(𝑡) descending, then hash(𝑡)𝑆𝑖={𝑡1,…,𝑡𝑘} where 𝑘=max{𝑗:𝑗∑𝑚=1bytes(𝑡𝑚)≤8KB}\n\nEach relay exposes its proposed shared inclusion list S_i𝑆𝑖 via a get_shared_il() endpoint.\nRelays poll peers and settle on the modal shared inclusion list S𝑆. Ties are broken by maximizing inclusion list byte size, with lexicographical sorting via the inclusion list hash as a fallback key.\n\nS = \\text{most frequent } S' \\text{ among } \\{S_1, \\dots, S_n\\} \\\\ \\text{Tie-breaking: Maximize } \\sum_{t \\in S'} \\text{bytes}(t), \\text{ then hash}(S')\n𝑆=most frequent 𝑆′ among {𝑆1,…,𝑆𝑛}Tie-breaking: Maximize ∑𝑡∈𝑆′bytes(𝑡), then hash(𝑆′)\nApplication and Incentives\nThis protocol allows the shared inclusion list to be derived without explicit consensus. As relays seek to maximize the number of competitive blocks they receive, they are incentivized to converge on a shared inclusion list in order to minimize the marginal cost a builder incurs when submitting a block.\nThe discretion any individual relay holds over the shared inclusion list is limited to an inclusion vote, put another way, individual relays cannot censor the content of the shared inclusion list beyond failing to adopt it.\nThe failure mode of the protocol corresponds to a case where relays fail to converge on a shared inclusion list. This should be precluded by the deterministic tie breaking procedure described in step 5. The worst case corresponds to each relay holding a different local inclusion list, which is equivalent to the base case in the existing local inclusion list implementation. In such an instance, builders would exercise discretion over whether to build for a union of inclusion lists, or deliver to specific relays only.\nIn contrast to designs like multiple concurrent proposers, the relays build standard-sized lists locally and truncation is performed over transaction frequency to ensure uniform application of the inclusion rule. This ensures that a full-sized shared inclusion list can be built even if individual relays were to fail to deliver a local list.\nIn summary, a basic protocol is sufficient for relays to converge on a shared inclusion list as this is collectively favorable. There is no excess value to be gained from building a competing local list (for example, a leaner list); in this case, the relay would be better served by opting out of rILs altogether.\nA Simple Extension: Shared Proposer Commitments\nThe mechanism can be extended to allows relays to share proposer commitments. Specifically, each relay would publicize the signed proposer constraints on-file, which may then be mirrored by peers. This reduces the risk of a slashing event for the proposer; relays sharing proposer constraints improve the proposer’s risk-adjusted return.\nIn practice, this can be efficiently accomplished through the following sequential steps:\n\nEach relay r_i𝑟𝑖 fetches proposer commitments from the proposer or designated gateway as per the standard procedure defined in the Fabric standard.\nEach relay composes an array of the SignedCommitment objects it has observed and exposes it via a get_proposer_commitments() endpoint.\nRelays poll peers and add any newly observed SignedCommitment to their block constraint verification process, if these are appropriately signed.\n\nThis procedure is incentive-compatible as relays continue to compete on latency during the slot auction, while reducing the slashing risk surface proposers and builders are exposed to. For this reason, proposers and builders are likely to express a preference for relays sharing proposer commitments.\nUltimately, this leads to a better risk-adjusted return from proposer commitments, which may reduce the risk premium charged to users, making Ethereum’s service offering more competitive.\nFuture Directions\nIn the future, relays may elect to extend block constraints sharing into a more binding consensus implementation. This approach could be used to increase mrIL efficiency by minimizing builder overhead, and as a way of distributing the value generated by relay block merging more objectively.\nThe design may also be extended in scope to increase the value generated by relay block merging, by allowing relays to share transactions eligible for merging with each other.\n\n Building towards Multi-Party Block Construction\n\n Universal Enshrined Encrypted Mempool EIP\n\n Powered by Discourse","tokens":1767,"squid":"spider-04","role":"Research Spider","at":1791347388982,"hash":"db38a02c5dc7389cb0daa9b228ac54b5cb964559"}
{"url":"https://www.metaplex.com/docs/smart-contracts/genesis/presale","domain":"metaplex.com","title":"Genesis Presale | Fixed-Price Token Sale on Solana | Metaplex","text":"Presales offer fixed-price token distribution on Solana — set your SPL token price upfront based on allocation and SOL cap. Users know exactly what they're getting, and you know exactly what you'll raise. In Genesis, a \"presale\" means tokens are sold immediately before initial trading — buyers receive the tokens directly, not a future right to receive them. What You'll LearnThis guide covers:How Presale pricing works (allocation + cap = price)Setting up deposit windows and claim periodsConfiguring deposit limits and cooldownsUser operations: wrap SOL, deposit, and claimSummaryPresales sell tokens at a predetermined price. The price is calculated from the token allocation and SOL cap you configure, making it ideal for token launches with a known valuation.Fixed price = SOL cap / token allocationUsers deposit SOL during the deposit window (0% fee applies)First-come-first-served up to the SOL capOptional: minimum/maximum deposit limits and cooldowns.Out of ScopeOrganic price discovery (see Launch Pool), bid-based auctions (see Uniform Price Auction), and vesting schedules.How It WorksYou allocate tokens to the Presale with a SOL cap that determines the fixed priceUsers deposit SOL during the deposit window at the fixed rateAfter the deposit period ends, you run triggerBehaviorsV2 to process end behaviors and move fundsUsers claim their tokens based on their deposit amountPrice CalculationThe token price is determined by the ratio of allocated tokens to the SOL cap:price = allocationQuoteTokenCap / baseTokenAllocation\ntokens = deposit / price\nFor example, if you allocate 1,000,000 tokens with a 100 SOL cap:Price = 100 SOL / 1,000,000 tokens = 0.0001 SOL per tokenA 10 SOL deposit receives 100,000 tokensFeesInstructionSolanaUser deposit fee0%Creator withdraw fee5%** This fee only applies when creators withdraw liquidityQuick StartSetup GuidePrerequisitesnpm install @metaplex-foundation/genesis @metaplex-foundation/umi @metaplex-foundation/umi-bundle-defaults @metaplex-foundation/mpl-toolbox\n1. Initialize the Genesis AccountThe Genesis Account creates your token and coordinates all distribution buckets.initializeV2.ts1import {\n2 findGenesisAccountV2Pda,\n3 genesis,\n4 initializeV2,\n5} from '@metaplex-foundation/genesis'\n6import { mplToolbox } from '@metaplex-foundation/mpl-toolbox'\n7import { generateSigner, keypairIdentity } from '@metaplex-foundation/umi'\n8import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n9\n10const umi = createUmi('https://api.mainnet-beta.solana.com')\n11 .use(mplToolbox())\n12 .use(genesis())\n13\n14// umi.use(keypairIdentity(yourKeypair));\n15\n16const baseMint = generateSigner(umi)\n17const TOTAL_SUPPLY = 1_000_000_000_000_000n // 1 million tokens (9 decimals)\n18\n19// Store this account address for later or recreate it when needed.\n20const [genesisAccount] = findGenesisAccountV2Pda(umi, {\n21 baseMint: baseMint.publicKey,\n22 genesisIndex: 0,\n23})\n24\n25await initializeV2(umi, {\n26 baseMint,\n27 fundingMode: 0,\n28 totalSupplyBaseToken: TOTAL_SUPPLY,\n29 name: 'My Token',\n30 symbol: 'MTK',\n31 uri: 'https://example.com/metadata.json',\n32}).sendAndConfirm(umi)\nThe totalSupplyBaseToken should equal the sum of all bucket allocations.2. Add the Presale BucketThe Presale bucket collects deposits and distributes tokens. Configure timing and optional limits here.addPresaleBucket.ts1import {\n2 addPresaleBucketV2,\n3 findPresaleBucketV2Pda,\n4 findUnlockedBucketV2Pda,\n5 genesis,\n6} from '@metaplex-foundation/genesis'\n7import { mplToolbox } from '@metaplex-foundation/mpl-toolbox'\n8import { publicKey } from '@metaplex-foundation/umi'\n9import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n10\n11const umi = createUmi('https://api.mainnet-beta.solana.com')\n12 .use(mplToolbox())\n13 .use(genesis())\n14\n15// umi.use(keypairIdentity(yourKeypair));\n16\n17// Assumes genesisAccount, baseMint, and TOTAL_SUPPLY from the Initialize step.\n18\n19const [presaleBucket] = findPresaleBucketV2Pda(umi, { genesisAccount, bucketIndex: 0 })\n20const [unlockedBucket] = findUnlockedBucketV2Pda(umi, { genesisAccount, bucketIndex: 0 })\n21\n22const now = BigInt(Math.floor(Date.now() / 1000))\n23const depositStart = now\n24const depositEnd = now + 86400n // 24 hours\n25const claimStart = depositEnd + 1n\n26const claimEnd = claimStart + 604800n // 1 week\n27\n28await addPresaleBucketV2(umi, {\n29 genesisAccount,\n30 baseMint: baseMint.publicKey,\n31 baseTokenAllocation: TOTAL_SUPPLY,\n32 allocationQuoteTokenCap: 100_000_000_000n, // 100 SOL cap (sets price)\n33\n34 // Timing\n35 depositStartCondition: {\n36 __kind: 'TimeAbsolute',\n37 padding: Array(47).fill(0),\n38 time: depositStart,\n39 triggeredTimestamp: null,\n40 },\n41 depositEndCondition: {\n42 __kind: 'TimeAbsolute',\n43 padding: Array(47).fill(0),\n44 time: depositEnd,\n45 triggeredTimestamp: null,\n46 },\n47 claimStartCondition: {\n48 __kind: 'TimeAbsolute',\n49 padding: Array(47).fill(0),\n50 time: claimStart,\n51 triggeredTimestamp: null,\n52 },\n53 claimEndCondition: {\n54 __kind: 'TimeAbsolute',\n55 padding: Array(47).fill(0),\n56 time: claimEnd,\n57 triggeredTimestamp: null,\n58 },\n59\n60 // Optional: Deposit limits\n61 minimumDepositAmount: null, // or { amount: sol(0.1).basisPoints }\n62 depositLimit: null, // or { limit: sol(10).basisPoints }\n63\n64 // Where collected SOL goes after transition\n65 endBehaviors: [\n66 {\n67 __kind: 'SendQuoteTokenPercentage',\n68 padding: Array(4).fill(0),\n69 destinationBucket: publicKey(unlockedBucket),\n70 percentageBps: 10000, // 100%\n71 processed: false,\n72 },\n73 ],\n74}).sendAndConfirm(umi)\n3. Add the Unlocked BucketThe Unlocked bucket receives SOL from the Presale after end behaviors are triggered.addUnlockedBucket.ts1import {\n2 addUnlockedBucketV2,\n3 genesis,\n4} from '@metaplex-foundation/genesis'\n5import { mplToolbox } from '@metaplex-foundation/mpl-toolbox'\n6import { keypairIdentity } from '@metaplex-foundation/umi'\n7import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n8\n9const umi = createUmi('https://api.mainnet-beta.solana.com')\n10 .use(mplToolbox())\n11 .use(genesis())\n12\n13// umi.use(keypairIdentity(yourKeypair));\n14\n15// Assumes genesisAccount, baseMint, claimStart, and claimEnd from previous steps.\n16\n17await addUnlockedBucketV2(umi, {\n18 genesisAccount,\n19 baseMint: baseMint.publicKey,\n20 baseTokenAllocation: 0n,\n21 recipient: umi.identity.publicKey,\n22 claimStartCondition: {\n23 __kind: 'TimeAbsolute',\n24 padding: Array(47).fill(0),\n25 time: claimStart,\n26 triggeredTimestamp: null,\n27 },\n28 claimEndCondition: {\n29 __kind: 'TimeAbsolute',\n30 padding: Array(47).fill(0),\n31 time: claimEnd,\n32 triggeredTimestamp: null,\n33 },\n34 backendSigner: null,\n35}).sendAndConfirm(umi)\n4. FinalizeOnce all buckets are configured, finalize to activate the presale. This is irreversible.finalize.ts1import {\n2 genesis,\n3 finalizeV2,\n4} from '@metaplex-foundation/genesis'\n5import { mplToolbox } from '@metaplex-foundation/mpl-toolbox'\n6import { keypairIdentity } from '@metaplex-foundation/umi'\n7import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n8\n9const umi = createUmi('https://api.mainnet-beta.solana.com')\n10 .use(mplToolbox())\n11 .use(genesis())\n12\n13// umi.use(keypairIdentity(yourKeypair));\n14\n15// Assumes genesisAccount and baseMint from the Initialize step.\n16\n17await finalizeV2(umi, {\n18 baseMint: baseMint.publicKey,\n19 genesisAccount,\n20}).sendAndConfirm(umi)\nUser OperationsWrapping SOLUsers must wrap SOL to wSOL before depositing.wrapSol.ts1import {\n2 findAssociatedTokenPda,\n3 createTokenIfMissing,\n4 transferSol,\n5 syncNative,\n6 mplToolbox,\n7} from '@metaplex-foundation/mpl-toolbox'\n8import { WRAPPED_SOL_MINT, genesis } from '@metaplex-foundation/genesis'\n9import { keypairIdentity, publicKey, sol } from '@metaplex-foundation/umi'\n10import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n11\n12const umi = createUmi('https://api.mainnet-beta.solana.com')\n13 .use(mplToolbox())\n14 .use(genesis())\n15\n16// umi.use(keypairIdentity(yourKeypair));\n17\n18const userWsolAccount = findAssociatedTokenPda(umi, {\n19 owner: umi.identity.publicKey,\n20 mint: WRAPPED_SOL_MINT,\n21})\n22\n23await createTokenIfMissing(umi, {\n24 mint: WRAPPED_SOL_MINT,\n25 owner: umi.identity.publicKey,\n26 token: userWsolAccount,\n27})\n28 .add(\n29 transferSol(umi, {\n30 destination: publicKey(userWsolAccount),\n31 amount: sol(10),\n32 })\n33 )\n34 .add(syncNative(umi, { account: userWsolAccount }))\n35 .sendAndConfirm(umi)\nDepositingdepositPresale.ts1import {\n2 genesis,\n3 depositPresaleV2,\n4 findPresaleDepositV2Pda,\n5 fetchPresaleDepositV2,\n6} from '@metaplex-foundation/genesis'\n7import { mplToolbox } from '@metaplex-foundation/mpl-toolbox'\n8import { keypairIdentity, sol } from '@metaplex-foundation/umi'\n9import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n10\n11const umi = createUmi('https://api.mainnet-beta.solana.com')\n12 .use(mplToolbox())\n13 .use(genesis())\n14\n15// umi.use(keypairIdentity(yourKeypair));\n16\n17// Assumes genesisAccount, presaleBucket, and baseMint from previous steps.\n18\n19await depositPresaleV2(umi, {\n20 genesisAccount,\n21 bucket: presaleBucket,\n22 baseMint: baseMint.publicKey,\n23 amountQuoteToken: sol(1).basisPoints,\n24}).sendAndConfirm(umi)\n25\n26// Verify\n27const [depositPda] = findPresaleDepositV2Pda(umi, {\n28 bucket: presaleBucket,\n29 recipient: umi.identity.publicKey,\n30})\n31const deposit = await fetchPresaleDepositV2(umi, depositPda)\n32\n33console.log('Deposited (after fee):', deposit.amountQuoteToken)\nMultiple deposits from the same user accumulate into a single deposit account.Claiming TokensAfter the deposit period ends and claims open:claimPresale.ts1import {\n2 genesis,\n3 claimPresaleV2,\n4} from '@metaplex-foundation/genesis'\n5import { mplToolbox } from '@metaplex-foundation/mpl-toolbox'\n6import { keypairIdentity } from '@metaplex-foundation/umi'\n7import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n8\n9const umi = createUmi('https://api.mainnet-beta.solana.com')\n10 .use(mplToolbox())\n11 .use(genesis())\n12\n13// umi.use(keypairIdentity(yourKeypair));\n14\n15// Assumes genesisAccount, presaleBucket, and baseMint from previous steps.\n16\n17await claimPresaleV2(umi, {\n18 genesisAccount,\n19 bucket: presaleBucket,\n20 baseMint: baseMint.publicKey,\n21 recipient: umi.identity.publicKey,\n22}).sendAndConfirm(umi)\nToken allocation: userTokens = (userDeposit / allocationQuoteTokenCap) * baseTokenAllocationAdmin OperationsTriggering End BehaviorsAfter the deposit period ends, run triggerBehaviorsV2 to process the end behaviors configured on the presale bucket — in this case, moving collected SOL to the unlocked bucket.Must wait for deposit period to endtriggerBehaviorsV2 can only be called after the presale's depositEndCondition has been met. Calling it early throws a PresaleBucketNotEnded error.triggerBehaviors.ts1import {\n2 genesis,\n3 triggerBehaviorsV2,\n4 WRAPPED_SOL_MINT,\n5} from '@metaplex-foundation/genesis'\n6import {\n7 findAssociatedTokenPda,\n8 mplToolbox,\n9} from '@metaplex-foundation/mpl-toolbox'\n10import { publicKey } from '@metaplex-foundation/umi'\n11import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n12\n13const umi = createUmi('https://api.mainnet-beta.solana.com')\n14 .use(mplToolbox())\n15 .use(genesis())\n16\n17// umi.use(keypairIdentity(yourKeypair));\n18\n19// Assumes genesisAccount, presaleBucket, unlockedBucket, and baseMint from previous steps.\n20\n21const unlockedBucketQuoteTokenAccount = findAssociatedTokenPda(umi, {\n22 owner: unlockedBucket,\n23 mint: WRAPPED_SOL_MINT,\n24})\n25\n26await triggerBehaviorsV2(umi, {\n27 genesisAccount,\n28 primaryBucket: presaleBucket,\n29 baseMint,\n30})\n31 .addRemainingAccounts([\n32 { pubkey: publicKey(unlockedBucket), isSigner: false, isWritable: true },\n33 { pubkey: publicKey(unlockedBucketQuoteTokenAccount), isSigner: false, isWritable: true },\n34 ])\n35 .sendAndConfirm(umi)\nWhy this matters: Without triggering end behaviors, collected SOL stays locked in the Presale bucket. Users can still claim tokens, but the team cannot access the raised funds.ReferenceConfiguration OptionsThese options are set when creating the Presale bucket:OptionDescriptionExampleminimumDepositAmountMinimum deposit per transaction{ amount: sol(0.1).basisPoints }depositLimitMaximum total deposit per user{ limit: sol(10).basisPoints }depositCooldownTime between deposits{ seconds: 60n }perCooldownDepositLimitMax deposit per cooldown period{ amount: sol(1).basisPoints }Time ConditionsFour conditions control presale timing:ConditionPurposedepositStartConditionWhen deposits opendepositEndConditionWhen deposits closeclaimStartConditionWhen claims openclaimEndConditionWhen claims closeUse TimeAbsolute with a Unix timestamp:const condition = {\n __kind: 'TimeAbsolute',\n padding: Array(47).fill(0),\n time: BigInt(Math.floor(Date.now() / 1000) + 3600), // 1 hour from now\n triggeredTimestamp: null,\n};\nEnd BehaviorsDefine what happens to collected SOL after the deposit period:endBehaviors: [\n {\n __kind: 'SendQuoteTokenPercentage',\n padding: Array(4).fill(0),\n destinationBucket: publicKey(unlockedBucket),\n percentageBps: 10000, // 100% = 10000 basis points\n processed: false,\n },\n]\nFetching StateBucket state:import { fetchPresaleBucketV2 } from '@metaplex-foundation/genesis';\n\nconst bucket = await fetchPresaleBucketV2(umi, presaleBucket);\nconsole.log('Total deposits:', bucket.quoteTokenDepositTotal);\nconsole.log('Deposit count:', bucket.depositCount);\nconsole.log('Token allocation:', bucket.bucket.baseTokenAllocation);\nconsole.log('SOL cap:', bucket.allocationQuoteTokenCap);\nDeposit state:import { fetchPresaleDepositV2, safeFetchPresaleDepositV2 } from '@metaplex-foundation/genesis';\n\nconst deposit = await fetchPresaleDepositV2(umi, depositPda); // throws if not found\nconst maybeDeposit = await safeFetchPresaleDepositV2(umi, depositPda); // returns null\n\nif (deposit) {\n console.log('Amount deposited:', deposit.amountQuoteToken);\n console.log('Amount claimed:', deposit.amountClaimed);\n console.log('Fully claimed:', deposit.claimed);\n}\nNotesThe 0% protocol fee applies to depositsUsers must wrap SOL to wSOL before depositingMultiple deposits from the same user accumulate in one deposit accountRun triggerBehaviorsV2 after deposits close for the team to access raised funds; it cannot be called before the deposit period endsFinalization is permanent—double-check all configuration before calling finalizeV2FAQHow is the token price calculated in a Presale?Price equals SOL cap divided by token allocation. For 1,000,000 tokens with a 100 SOL cap, the price is 0.0001 SOL per token.What happens if the SOL cap isn't reached?Users still receive tokens proportional to their deposits. If only 50 SOL is deposited against a 100 SOL cap, depositors receive 50% of allocated tokens.Can I set deposit limits per user?Yes. Use minimumDepositAmount for minimum per-transaction limits and depositLimit for maximum total deposit per user.What's the difference between Presale and Launch Pool?Presale has a fixed price determined by token allocation and SOL cap. Launch Pool discovers price organically based on total deposits.When should I use Presale vs Launch Pool?Use Presale when you want predictable pricing and know exactly how much you want to raise. Use Launch Pool for organic price discovery.GlossaryTermDefinitionPresaleFixed-price token sale with predetermined rateSOL CapMaximum SOL the presale will accept (determines price)Token AllocationNumber of tokens available in the presaleDeposit LimitMaximum total deposit allowed per userMinimum DepositMinimum amount required per deposit transactionCooldownTime users must wait between depositsEnd BehaviorAutomated action after deposit period endsTriggertriggerBehaviorsV2 instruction that processes end behaviors after the deposit period endsNext StepsLaunch Pool - Fair launch with organic price discoveryUniform Price Auction - Auction-style bid-based allocationLaunch a Token - End-to-end token launch guideGetting Started - Genesis launchpad fundamentals","tokens":3993,"squid":"dotcat","role":"Tooling Spider","at":1791347391862,"hash":"c6b281ecc1b2897beeec831af9bf9f2daaad6c5f"}
{"url":"https://docs.jup.ag/user-docs/earn/offerbook/statistics","domain":"docs.jup.ag","title":"Offerbook Statistics - Jupiter Documentation","text":"The Statistics page, under More in the header, gives a real-time overview of Offerbook activity and performance: total value locked, liquidity, volume, loans, interest, and rankings of the most active assets and participants.\n​Headline cards\nThe top of the page summarises the protocol in eight cards.\nCardWhat it showsTotal Value LockedTotal value locked (TVL) across all Offerbook marketsNotional LiquidityValue of currently active offersAdvertised IntentsNumber of active intents and their advertised liquidity. See IntentsVolumeTotal volume since launch, and the volume of currently active loansOffersNumber of offers currently openLoansTotal number of loans since launch, and the number currently activeInterestInterest already paid, and open interest accruing on active loansAveragesAverage annual percentage yield (APY) and average duration per loan\n​Volume chart and protocol breakdown\nThe Volume chart plots protocol volume over the last 7, 30 or 90 days, cumulative or daily. Next to it, the Protocol Breakdown panel repeats the key figures in one place: liquidity, total volume, active offers, total loans and active loans.\n​Categories Offers Value\nThis section groups offer liquidity by token type, for example trading card games (TCGs), liquid staking tokens (LSTs), DeFi tokens and PFP collections. Selecting a category expands a per-asset table:\nColumnMeaningLockedValue currently locked for this assetActive TVLValue locked in active loans, with the number of loansActive APYAverage rate of active loans on this assetSupplyValue of open lending offers, with the offer countSupply APYAverage rate asked by lendersDemandValue of open borrowing offers, with the offer countDemand APYAverage rate offered by borrowers\nA time selector (1H to ALL) restricts the figures to the chosen window.\n​Top Tokens on Offerbook\nA ranking of the most active tokens, with notional liquidity, volume, APY, and the number of offers and loans for each. The same time selector applies, and the table is paginated.\n​Top Participants\nTwo leaderboards rank the most active wallets over a selectable window (24H, 7D, 15D, 30D or ALL):\n\nTop Lenders, ranked by lending volume, with their number of loans\nTop Borrowers, ranked by borrowing volume, with their number of loans\n\nWallets appear under their shortened address, or under their chosen display name.\nStatistics are aggregated server side and refresh periodically. Figures can lag live activity by a short interval, so counts on this page and badges elsewhere in the interface may briefly disagree.","tokens":635,"squid":"spider-02","role":"Liquidity Spider","at":1791347394706,"hash":"20301ec00325fdf33fb39c7a030feb8fac2db42c"}
{"url":"https://ethresear.ch/t/relay-inclusion-lists/22218","domain":"ethresear.ch","title":"Relay Inclusion Lists - Proof-of-Stake / Block proposer - Ethereum Research","text":"Relay Inclusion Lists \n\n Proof-of-StakeBlock proposer\n\n mev,proposer-builder-separation,censorship-resistance\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 10\n min\n\n Apr 2025\n\n 1 / 9\n\n Apr 2025\n\n May 2025\n\n post by kubimens on Apr 25, 2025\n\n kubimens\n\n Co-authored by Michael and Kubi (Gattaca). Special thanks to Thomas, Julian, Toni, Ladi, Justin, Auston and Max for their feedback and suggestions. Feedback is not necessarily an endorsement.\nOverview\nThis document introduces relay inclusion lists (rILs), a way to immediately improve Ethereum’s censorship resistance without introducing protocol changes, new trust assumptions, or significant technical complexity. The design is intended as a new default feature for non-censoring relays, with an opt-out option provided to accommodate validator preference.\nWe proceed by detailing how relay inclusion lists increase Ethereum’s censorship resistance while preserving validator’s risk-reward balance. We then propose a rule for constructing relay inclusion lists that is efficient and resilient to outlier values, alongside enforcement procedures that integrate seamlessly with existing block validation. The document concludes with an outlook on promising future directions.\nOverall, the document details the exact procedures for generating, validating, and enforcing inclusion lists in the relay. It reflects the EIP-7805 (FOCIL) specifications to ensure protocol compatibility and operational integrity, preparing the block production system for a future in-protocol implementation of inclusion lists in a risk-off manner.\n874×701 38.8 KB\nDistribution and roll-out\nRelays supporting relay inclusion lists will by default generate and enforce an inclusion list from transactions pending in the mempool for all blocks they deliver. Validators that wish to opt-out may do so by explicitly indicating this preference through the relay registration API, as an additional preference field.\nRelay inclusion lists empower validators to immediately improve Ethereum’s censorship resistance without incurring any additional risk or trust assumptions, as the compilation and enforcement of the inclusion list is delegated to the relay, with the validator remaining blind to its contents upon signing the block header. An alternative out-of-protocol approach is IL-Boost, which delegates block building but retains inclusion list construction at the proposer level.\nWe note that the system is consistent with validator’s economic incentives. In practice, it will reflect as fuller blocks, which come with a minor latency trade-off due to their larger data footprint. In the case where all relays adopt the design, this trade-off will be minimized on a relative basis, as the bid curve will shift to accommodate this marginal and predictable latency overhead; put another way, the best bid is submitted earlier. In the case where some relays do not adopt the design, validators are insured through the standard block auction, which will continue to yield the highest-paying block.\nOverall, the design does not impose additional requirements on validators, and allows them to improve Ethereum’s censorship resistance without shifting on the risk/reward curve. For this reason, the system is accessible and attractive to all participants, from solo stakers to large node operators.\nInclusion List Generation and Communication\nRelays independently generate inclusion lists from mempool transactions by applying a deterministic inclusion rule. The core purpose of the rule is to maximize the predictability of inclusion by observing the mempool only; specifically, the arrival times and priority fees of pending transactions.\nWe propose an initial, simple two-step rule:\n\nNormalize waiting time and priority fee:\nFor each transaction t𝑡 in the mempool, compute:\n S_w(t) = \\frac{w(t)}{\\tilde{w}}, \\quad S_f(t) = \\frac{f(t)}{\\tilde{f}} 𝑆𝑤(𝑡) =𝑤(𝑡)˜𝑤, 𝑆𝑓(𝑡) =𝑓(𝑡)˜𝑓\nwhere:\n\nw(t)𝑤(𝑡) is waiting time of transaction t𝑡 in the mempool.\nf(t)𝑓(𝑡) is the priority fee of transaction t𝑡.\n\\tilde{w}˜𝑤 and \\tilde{f}˜𝑓 are the medians of the waiting times and priority fees respectively, for all transactions pending in the mempool.\n\nCompute total score and adjust for transaction size:\nEach transaction is initially assigned a total score:\n S(t) = S_w(t) + S_f(t) 𝑆(𝑡) =𝑆𝑤(𝑡) +𝑆𝑓(𝑡)\nThe score S(t)𝑆(𝑡) is then size-adjusted to provide higher marginal pricing for large transactions:\n D(t) = \\frac{S(t)}{size(t)} 𝐷(𝑡) =𝑆(𝑡)𝑠𝑖𝑧𝑒(𝑡)\nwhere size(t)𝑠𝑖𝑧𝑒(𝑡) is the transaction’s size measured in bytes. Transactions are then ranked in descending order of D(t)𝐷(𝑡).\n\nThe relay then builds an inclusion list with a maximum size of 8 kilobytes, in adherence to the EIP-7805 (FOCIL) specifications, by including the top-ranked transactions until there is insufficient marginal space for a further inclusion.\nNormalizing via the median avoids skew from transactions that have not seen inclusion for economical reasons, i.e. due to underpayment. The rule is computationally efficient, as median calculation and transaction sorting can be performed quickly for typical mempool sizes using standard algorithms. An adversary attempting to grief the median by spamming low fee transactions would simply increase the prioritization score of other transactions; a simpler and cheaper way of reaching inclusion would just be to pay more.\nRanking the transactions by the density score imposes a higher marginal price per unit of blockspace consumption. This market-based approach incentivizes the inclusion of many smaller transactions, thereby maximizing participation from as many originators as possible. Large transactions, which consume more blockspace, can still be included quickly by increasing their priority fee accordingly.\nUniform application of the inclusion rule across all relays is desirable; in practice, it is most important that each relay fills the inclusion list to its maximum size (given sufficient transactions in the mempool), to preclude skewed IL implementations optimizing for latency (i.e. lean blocks). Relay behaviour is enforced via proposers, which may elect to opt out of relays that optimize for factors other than censorship resistance. The inclusion rule is economically rational and incentive-aligned by taking into account priority fees.\nThe inclusion list is computed before the beginning of each slot, and the relay exposes an HTTP API endpoint that builders use to fetch the completed inclusion list. There are no sorting constraints imposed on builders; transactions on the inclusion list can be sorted into the block in the most efficient way.\nBlock Validation and Enforcement\nBlock validity is enforced against the FOCIL criteria; specifically, a block proposed to the relay is valid if and only if the following conditions are fulfilled:\n\nTransaction Inclusion Check\n\nEvery transaction listed in the IL provided by the relay is either:\n\nIncluded explicitly in the block delivered by the builder.\nVerifiably invalid after executing against the block’s resulting post-state.\n\nSimulated Transaction Validation\n\nThe Relay simulates execution of each IL transaction not included in the block against the block’s post-state.\n\nA block is invalid if it omits any inclusion‑list transaction that would, when validated against its resulting post‑state, pass all pre‑execution validity checks—correct signature, chain ID, nonce, sufficient balance, and intrinsic gas.\nTransactions failing simulation due to inherent invalidity (e.g., nonce mismatch, insufficient balance) do not invalidate the block.\n\nSimulation and verification of the IL is done in the simulation part of block verification.\n\nThis approach fits the FOCIL criteria to the current off-chain PBS pipeline without introducing additional stages; the block simulation is simply marginally extended by one transaction for each IL transaction not included in the block. In the case of optimistic relaying that skips the simulation stage for trusted builders, no overhead is incurred.\nEnforcement and Penalties\nAs per the FOCIL criteria, compliance with the inclusion list is treated as a validity condition. Non-compliance results in non-acceptance at a minimum, and in the case of optimistic builders, a penalty may be enforced.\nWe propose that the penalty enforced against non-compliant optimistic builders should reflect the IL as an integral validity condition, and lead to forfeiture of the block value against the builder’s collateral. Relays may elect to demote non-compliant builders temporarily, until the error has been traced, to avoid excess collateral burn.\nFuture Directions\nInclusion Lists for Blob-Type Transactions\nIn the future, the design may be extended to encompass blobs. This would widen the censorship resistance of the current design while improving timely data availability for L2s.\nLarger Inclusion Lists\nRelay inclusion lists can be larger than proposer-centric inclusion lists, as they are not directly bottlenecked by validator bandwidth constraints. The present design mirrors FOCIL sizing to ensure blocks with relay ILs are competitively priced in the PBS auction, and can in the future be expanded to accommodate a larger total size.\nMulti-Relay Inclusion Lists\nUnder the present design, each relay maintains its own inclusion list. Builders seeking to retain maximal optionality for their blocks may choose to send a different block to each relay, reflecting the IL provided by the relay.\nIn the future, even stronger censorship guarantees may be achieved by forming an inclusion list from the intersection of multiple inclusion lists. This ensures fair competition between relays by enforcing uniform application of the inclusion rule, and can be easily computed over the transaction ranking used to compile the inclusion list. This would also reduce redundancy for builders, by removing the need to compute tailored blocks per relay, or to include a union of inclusion lists.\nIn such a case, each relay could gossip an extended list, which is then deterministically reduced to a uniform standard-sized list by taking the intersection. In practice, this may be achieved by upgrading relays with a simple gossip protocol.\nLinks\n\nFork-Choice enforced Inclusion Lists (FOCIL): A simple committee-based inclusion list proposal\n\nEIP-7805: Fork-choice enforced Inclusion Lists (FOCIL)\n\nUncrowdable Inclusion Lists: The Tension between Chain Neutrality, Preconfirmations and Proposer Commitments\n\nil-boost/README.md at main · eserilev/il-boost · GitHub\n\n Block Constraints Sharing: Multi-Relay Inclusion Lists & beyond\n\n Building towards Multi-Party Block Construction\n\n 3\n\n 2\n\n 2\n\n read \n\n 10\n min\n\n post by famouswizard on Apr 26, 2025\n\n post by remosm on Apr 28, 2025\n\n post by aelowsson on Apr 29, 2025\n\n post by remosm on May 2, 2025\n\n post by aelowsson on May 4, 2025\n\n 17 days later\n\n post by mikeneuder on May 21, 2025\n\n post by remosm on May 22, 2025\n\n post by mikeneuder on May 22, 2025\n\n Powered by Discourse","tokens":2759,"squid":"spider-04","role":"Research Spider","at":1791347400510,"hash":"bccf13b7540c383ab6d6cce5c729dc0a675d5cd6"}
{"url":"https://docs.jup.ag/user-docs/earn/offerbook/settings-and-notifications","domain":"docs.jup.ag","title":"Settings & Notifications - Jupiter Documentation","text":"The Settings page (gear icon in the navigation header) is where you configure how Offerbook talks back to you and how your escrow behaves when you create offers. It has two tabs: General and Notifications.\nThe General tab manages notification channels, hardware wallet authentication, Privacy mode, and Escrow Settings. The Notifications tab lists all available notification types and lets you enable or disable them individually.\nSettings first asks you to Sign in to manage settings: your notification preferences are tied to your wallet, so you approve a one-time signature to load them. It is free, never sends a transaction, and you are not asked again on the same device. You can then set your notification types before connecting any channel; notifications are delivered once a channel is connected, and a verified Email is enough on its own.\n\n​Notification Channels\nOfferbook supports two notification channels: Telegram and Email. They are independent and can both be connected at the same time. A channel can be connected to multiple wallets.\nConnecting a channel requires proving you own the wallet by signing a message (or a transaction, for hardware wallets — see Hardware Wallet Authentication).\nChanging your notification settings also requires an explicit sign-in. Each time you connect a new channel, change a setting, or toggle a notification type, the app asks for a wallet signature to protect your preferences from unauthorized changes.\nConnect Telegram\nIn Settings → General, click Connect next to Telegram.\nThe app opens a signature request to authenticate you with Jupiter Notifications.\nAfter signing, you are redirected to the Telegram bot to link your account.\nOnce linked, Telegram is shown as Connected. You can disconnect at any time.Connect Email\nIn Settings → General, click Connect next to Email.\nEnter your email address and confirm.\nThe app opens a signature request to authenticate the wallet.\nA verification email is sent to the address you provided.\nOnce verified, Email is shown as Connected, and the address is displayed next to the channel with Edit and Disconnect controls.Why is the same channel usable on multiple wallets?A notification channel (Telegram or Email) is tied to a notification service account, not to a single wallet. Once authenticated, the same channel can be linked to additional wallets, allowing you to receive alerts for activity across all of them in one place.\n\n​Hardware Wallet Authentication\nHardware wallets such as Ledger cannot sign arbitrary messages. To connect a notification channel from a hardware wallet, you need to enable an alternative authentication flow.\nEnable hardware wallet modeBefore you sign in, turn on Using a hardware wallet (Ledger)? on the Sign in to manage settings screen. Once signed in, the same option appears in Settings → General as I’m using a hardware wallet, and applies when you connect a notification channel.With this toggle on, authentication uses a signed transaction instead of a signed message. The transaction is empty (no funds move and no state changes), but it still requires a small SOL balance to pay the network fee.When to use this optionEnable it only if your wallet rejects message-signing requests. Software wallets such as Phantom or Solflare sign messages natively and do not need this toggle.Once enabled, the toggle persists across sessions. You can switch it off later if you change to a software wallet.\nThis setting applies to notification channel authentication. Chat has its own hardware-wallet sign-in flow using a memo transaction; see Chat for details.\n\n​Profile\nYou can set a public profile from the Your Profile dialog. It is optional and applies across Offerbook (Chat, Statistics, your Affiliate page).\n\nUsername — 3 to 20 characters, letters, digits, - and _. Lets others reach you in Chat by name instead of wallet address\nProfile image — pick one of the NFTs in your wallet\nSocial medias — optional X and Telegram handles\n\nClick Save Profile to apply. Saving works with hardware wallets such as Ledger.\n\n​Privacy Mode\nTurn on Privacy mode in Settings → General to hide your dollar amounts: portfolio totals, PnL and balances. Market data such as rates, offers and statistics stays visible. The setting is saved on the device you are using, so it is handy when sharing your screen.\n\n​Escrow Settings\nEscrow Settings control how your escrow is funded when you create an offer.\nThese two settings are visible in Settings but not yet active (greyed out). For now, the app always deposits the required assets from your wallet into the escrow as part of offer creation, as described below.\nTop up on Create Borrow OfferThe app automatically deposits the required collateral from your main wallet into your escrow when you create a borrow offer. Once this toggle becomes active, disabling it will let you fund the escrow manually instead.Top up on Create Lend OfferThe app automatically deposits the required USDC from your main wallet into your escrow when you create a lend offer. Once this toggle becomes active, disabling it will let you fund the escrow manually instead.What happens when filling an offerIndependently of these settings, filling an offer (i.e., accepting an existing offer rather than creating one) automatically pulls any missing funds from your wallet — only the minimum top-up needed is taken, so your wallet balance is not over-drained.\nAuto top-up only moves funds from your main wallet to your escrow. You always need sufficient SOL in your main wallet to cover transaction fees, regardless of these settings.\n\n​Notification Types\nNotification types are listed in the Notifications tab. Each can be toggled on or off independently. Notifications are grouped into two categories: Offers and Loans.\nAll notification types are enabled by default once at least one channel is connected. You can disable any of them individually, or use Disable all at the top of each group to turn the whole group off.\n​Offers\nOffer acceptedA counterparty has accepted one of your open offers. The loan starts immediately at the offer terms.Counter offer receivedA counterparty has proposed a counter offer on one of your open offers. You can review it under the original offer and either accept the counter-offer terms (starting the loan) or ignore it. See Counter Offers.Offer expiredOne of your open offers reached its expiration window without being filled. Offers expire after 1 to 7 days, depending on the expiration you set at creation.Offer cancelledAn offer you created — or an offer you had matched against — has been cancelled.\n​Loans\nLoan due soonOne of your active loans is approaching its due date. This notification fires 2 hours before maturity, matching the in-app calendar reminder.Loan repaidA borrower has fully repaid one of your loans. The USDC (principal + interest, minus the 10% repayment fee) is now available in your escrow.Loan extendedA borrower has extended one of your loans into a fresh period, paying you the closing period’s interest. See Loan Extensions.Loan expiredA loan has passed its due date without repayment. The lender can now claim the collateral. As a borrower, you can still repay until the lender claims, but you should not rely on this window.Loan defaultedThe collateral has been claimed on a defaulted loan. As a lender, the collateral has been transferred to your wallet (minus the 0.1% fee, where applicable). As a borrower, the loan is now closed and you have lost the collateral.\n\n​Common Issues\nOpening Settings asks me to signSettings shows Sign in to manage settings: your notification preferences are tied to your wallet, so you approve a one-time signature to prove ownership and load them. It is free, never sends a transaction, and you are not asked again on the same device. With a hardware wallet, turn on Using a hardware wallet (Ledger)? on the same screen so the sign-in uses a transaction instead of a message.Until you sign, the Settings controls stay disabled.I added Email but I receive no notificationsMake sure the Email channel shows as Connected in the General tab (with your address displayed and Edit/Disconnect controls visible). If it still appears as Not connected, complete the verification step from the email you received. A verified Email is enough on its own: Telegram is not required.My hardware wallet rejects the signatureMake sure Using a hardware wallet (Ledger)? is turned on, on the Settings sign-in screen, or I’m using a hardware wallet in Settings → General once you are signed in. With this enabled, authentication uses a signed transaction instead of a signed message, which is supported by all hardware wallets.","tokens":2162,"squid":"spider-02","role":"Liquidity Spider","at":1791347406388,"hash":"5694a29d2d6502618e49f64c5f33c54eb9bdbc25"}
{"url":"https://ethresear.ch/t/relay-inclusion-lists/22218/1","domain":"ethresear.ch","title":"Relay Inclusion Lists - Proof-of-Stake / Block proposer - Ethereum Research","text":"Relay Inclusion Lists \n\n Proof-of-StakeBlock proposer\n\n mev,proposer-builder-separation,censorship-resistance\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 10\n min\n\n Apr 2025\n\n 1 / 9\n\n Apr 2025\n\n May 2025\n\n post by kubimens on Apr 25, 2025\n\n kubimens\n\n Co-authored by Michael and Kubi (Gattaca). Special thanks to Thomas, Julian, Toni, Ladi, Justin, Auston and Max for their feedback and suggestions. Feedback is not necessarily an endorsement.\nOverview\nThis document introduces relay inclusion lists (rILs), a way to immediately improve Ethereum’s censorship resistance without introducing protocol changes, new trust assumptions, or significant technical complexity. The design is intended as a new default feature for non-censoring relays, with an opt-out option provided to accommodate validator preference.\nWe proceed by detailing how relay inclusion lists increase Ethereum’s censorship resistance while preserving validator’s risk-reward balance. We then propose a rule for constructing relay inclusion lists that is efficient and resilient to outlier values, alongside enforcement procedures that integrate seamlessly with existing block validation. The document concludes with an outlook on promising future directions.\nOverall, the document details the exact procedures for generating, validating, and enforcing inclusion lists in the relay. It reflects the EIP-7805 (FOCIL) specifications to ensure protocol compatibility and operational integrity, preparing the block production system for a future in-protocol implementation of inclusion lists in a risk-off manner.\n874×701 38.8 KB\nDistribution and roll-out\nRelays supporting relay inclusion lists will by default generate and enforce an inclusion list from transactions pending in the mempool for all blocks they deliver. Validators that wish to opt-out may do so by explicitly indicating this preference through the relay registration API, as an additional preference field.\nRelay inclusion lists empower validators to immediately improve Ethereum’s censorship resistance without incurring any additional risk or trust assumptions, as the compilation and enforcement of the inclusion list is delegated to the relay, with the validator remaining blind to its contents upon signing the block header. An alternative out-of-protocol approach is IL-Boost, which delegates block building but retains inclusion list construction at the proposer level.\nWe note that the system is consistent with validator’s economic incentives. In practice, it will reflect as fuller blocks, which come with a minor latency trade-off due to their larger data footprint. In the case where all relays adopt the design, this trade-off will be minimized on a relative basis, as the bid curve will shift to accommodate this marginal and predictable latency overhead; put another way, the best bid is submitted earlier. In the case where some relays do not adopt the design, validators are insured through the standard block auction, which will continue to yield the highest-paying block.\nOverall, the design does not impose additional requirements on validators, and allows them to improve Ethereum’s censorship resistance without shifting on the risk/reward curve. For this reason, the system is accessible and attractive to all participants, from solo stakers to large node operators.\nInclusion List Generation and Communication\nRelays independently generate inclusion lists from mempool transactions by applying a deterministic inclusion rule. The core purpose of the rule is to maximize the predictability of inclusion by observing the mempool only; specifically, the arrival times and priority fees of pending transactions.\nWe propose an initial, simple two-step rule:\n\nNormalize waiting time and priority fee:\nFor each transaction t𝑡 in the mempool, compute:\n S_w(t) = \\frac{w(t)}{\\tilde{w}}, \\quad S_f(t) = \\frac{f(t)}{\\tilde{f}} 𝑆𝑤(𝑡) =𝑤(𝑡)˜𝑤, 𝑆𝑓(𝑡) =𝑓(𝑡)˜𝑓\nwhere:\n\nw(t)𝑤(𝑡) is waiting time of transaction t𝑡 in the mempool.\nf(t)𝑓(𝑡) is the priority fee of transaction t𝑡.\n\\tilde{w}˜𝑤 and \\tilde{f}˜𝑓 are the medians of the waiting times and priority fees respectively, for all transactions pending in the mempool.\n\nCompute total score and adjust for transaction size:\nEach transaction is initially assigned a total score:\n S(t) = S_w(t) + S_f(t) 𝑆(𝑡) =𝑆𝑤(𝑡) +𝑆𝑓(𝑡)\nThe score S(t)𝑆(𝑡) is then size-adjusted to provide higher marginal pricing for large transactions:\n D(t) = \\frac{S(t)}{size(t)} 𝐷(𝑡) =𝑆(𝑡)𝑠𝑖𝑧𝑒(𝑡)\nwhere size(t)𝑠𝑖𝑧𝑒(𝑡) is the transaction’s size measured in bytes. Transactions are then ranked in descending order of D(t)𝐷(𝑡).\n\nThe relay then builds an inclusion list with a maximum size of 8 kilobytes, in adherence to the EIP-7805 (FOCIL) specifications, by including the top-ranked transactions until there is insufficient marginal space for a further inclusion.\nNormalizing via the median avoids skew from transactions that have not seen inclusion for economical reasons, i.e. due to underpayment. The rule is computationally efficient, as median calculation and transaction sorting can be performed quickly for typical mempool sizes using standard algorithms. An adversary attempting to grief the median by spamming low fee transactions would simply increase the prioritization score of other transactions; a simpler and cheaper way of reaching inclusion would just be to pay more.\nRanking the transactions by the density score imposes a higher marginal price per unit of blockspace consumption. This market-based approach incentivizes the inclusion of many smaller transactions, thereby maximizing participation from as many originators as possible. Large transactions, which consume more blockspace, can still be included quickly by increasing their priority fee accordingly.\nUniform application of the inclusion rule across all relays is desirable; in practice, it is most important that each relay fills the inclusion list to its maximum size (given sufficient transactions in the mempool), to preclude skewed IL implementations optimizing for latency (i.e. lean blocks). Relay behaviour is enforced via proposers, which may elect to opt out of relays that optimize for factors other than censorship resistance. The inclusion rule is economically rational and incentive-aligned by taking into account priority fees.\nThe inclusion list is computed before the beginning of each slot, and the relay exposes an HTTP API endpoint that builders use to fetch the completed inclusion list. There are no sorting constraints imposed on builders; transactions on the inclusion list can be sorted into the block in the most efficient way.\nBlock Validation and Enforcement\nBlock validity is enforced against the FOCIL criteria; specifically, a block proposed to the relay is valid if and only if the following conditions are fulfilled:\n\nTransaction Inclusion Check\n\nEvery transaction listed in the IL provided by the relay is either:\n\nIncluded explicitly in the block delivered by the builder.\nVerifiably invalid after executing against the block’s resulting post-state.\n\nSimulated Transaction Validation\n\nThe Relay simulates execution of each IL transaction not included in the block against the block’s post-state.\n\nA block is invalid if it omits any inclusion‑list transaction that would, when validated against its resulting post‑state, pass all pre‑execution validity checks—correct signature, chain ID, nonce, sufficient balance, and intrinsic gas.\nTransactions failing simulation due to inherent invalidity (e.g., nonce mismatch, insufficient balance) do not invalidate the block.\n\nSimulation and verification of the IL is done in the simulation part of block verification.\n\nThis approach fits the FOCIL criteria to the current off-chain PBS pipeline without introducing additional stages; the block simulation is simply marginally extended by one transaction for each IL transaction not included in the block. In the case of optimistic relaying that skips the simulation stage for trusted builders, no overhead is incurred.\nEnforcement and Penalties\nAs per the FOCIL criteria, compliance with the inclusion list is treated as a validity condition. Non-compliance results in non-acceptance at a minimum, and in the case of optimistic builders, a penalty may be enforced.\nWe propose that the penalty enforced against non-compliant optimistic builders should reflect the IL as an integral validity condition, and lead to forfeiture of the block value against the builder’s collateral. Relays may elect to demote non-compliant builders temporarily, until the error has been traced, to avoid excess collateral burn.\nFuture Directions\nInclusion Lists for Blob-Type Transactions\nIn the future, the design may be extended to encompass blobs. This would widen the censorship resistance of the current design while improving timely data availability for L2s.\nLarger Inclusion Lists\nRelay inclusion lists can be larger than proposer-centric inclusion lists, as they are not directly bottlenecked by validator bandwidth constraints. The present design mirrors FOCIL sizing to ensure blocks with relay ILs are competitively priced in the PBS auction, and can in the future be expanded to accommodate a larger total size.\nMulti-Relay Inclusion Lists\nUnder the present design, each relay maintains its own inclusion list. Builders seeking to retain maximal optionality for their blocks may choose to send a different block to each relay, reflecting the IL provided by the relay.\nIn the future, even stronger censorship guarantees may be achieved by forming an inclusion list from the intersection of multiple inclusion lists. This ensures fair competition between relays by enforcing uniform application of the inclusion rule, and can be easily computed over the transaction ranking used to compile the inclusion list. This would also reduce redundancy for builders, by removing the need to compute tailored blocks per relay, or to include a union of inclusion lists.\nIn such a case, each relay could gossip an extended list, which is then deterministically reduced to a uniform standard-sized list by taking the intersection. In practice, this may be achieved by upgrading relays with a simple gossip protocol.\nLinks\n\nFork-Choice enforced Inclusion Lists (FOCIL): A simple committee-based inclusion list proposal\n\nEIP-7805: Fork-choice enforced Inclusion Lists (FOCIL)\n\nUncrowdable Inclusion Lists: The Tension between Chain Neutrality, Preconfirmations and Proposer Commitments\n\nil-boost/README.md at main · eserilev/il-boost · GitHub\n\n Block Constraints Sharing: Multi-Relay Inclusion Lists & beyond\n\n Building towards Multi-Party Block Construction\n\n 3\n\n 2\n\n 2\n\n read \n\n 10\n min\n\n post by famouswizard on Apr 26, 2025\n\n famouswizard\n\n Given that Relay Inclusion Lists aim to enhance Ethereum’s censorship resistance without introducing new trust assumptions, how do you foresee the adoption of rILs impacting competition and differentiation among relays in the proposer-builder ecosystem?\n\n post by remosm on Apr 28, 2025\n\n remosm\n\n From the validator POV, relays have so far competed on two axes -\n(1) Latency, or block value.\n(2) Trust guarantees, or the likelihood of payment.\nrILs introduce a third differentiator: verifiable and immediate censorship resistance.\nWith the initial specs, the latency hit is marginal and predictable, or put another way, rewards should remain effectively unchanged. We also do not introduce new risks for validators, as they are blind to the content of the rIL.\nIn the short term, relays adopting the design differentiate themselves by providing a strong additional net value add to validators in the form of censorship resistance.\nIn the medium term, we expect rILs to become a baseline design / table stakes.\n\n post by aelowsson on Apr 29, 2025\n\n aelowsson\n\n Interesting idea. It should be noted that to empower the protocol—through its validators—to enforce censorship resistance, something like FOCIL would still be needed, and that the referenced IL-boost mechanism gives validators a more direct influence. Yet this can be a straightforward way to promote light censorship resistance at the current stage, which of course is welcome. A contradiction to note is that censorship resistance will be imposed by a single party. There may also be risks with the resulting reliance on the mempool specified by the relay. To increase openness, the mempool producing the IL would ideally be made available at the same time that the IL is. This will not prove that the relay operates honestly, but makes it much more difficult not to.\nI will in my review seek some clarifications on technical details and outline potential improvements.\n\nI will try to analyze the options to see if I understand your intentions correctly, and to also explain the rationale behind alternative designs.\nA benefit of the normalization step is that it produces an “unopinionated” balance between priority fees and delay. It also adjusts according to the state of the mempool. Two examples: if the delay to inclusion increases in the mempool, the importance of the delay is weighted down; if there is a spike in priority fees, the importance of the priority fee is reduced relative to the delay. Normalization can thus be favored if this type of balancing is desirable. However, it would then seem optimal to apply the normalization only to a subset of txs that have some sufficient max_fee_per_gas, for example ensuring max_fee_per_gas * 2 > base_fee_per_gas. You might even consider max_fee_per_gas > base_fee_per_gas. This option has a clear interpretation: if there is space, all txs are with a sufficient max_fee_per_gas are included, and otherwise, the selection is still based only on the distribution of such txs.\nThe thresholding is to make it more difficult for adversaries to alter the balance between delay and priority fee with spam txs. As an example, you can otherwise make the mechanism prioritize priority fee over delay by filling up the mempool with txs with a low max_fee_per_gas and a low max_priority_fee_per_gas, and let them sit in the mempool accruing delay.\nIt can be noted that directly computing a score to rank txs by, and including the subset with the highest score, would already be sufficient. It is only really necessary to incorporate a normalization step if you wish to specifically balance the influence of priority fees and delay according to the present state of the mempool, when the two variables after normalization are summed. Another way to explain this is to say that normalization is not necessarily required to handle for example a spike in priority fees, given that all txs will be compared with each other (thus a relative operation) anyway in order to select the most relevant for inclusion.\nIt would therefore as an alternative be perfectly theoretically sound to not normalize, just computing a score from, e.g.,\n\nS(t) = a\\,w(t)+f(t)\n𝑆(𝑡)=𝑎𝑤(𝑡)+𝑓(𝑡)\nor\n\nS(t) = (w(t)+a)\\times(f(t)+b),\n𝑆(𝑡)=(𝑤(𝑡)+𝑎)×(𝑓(𝑡)+𝑏),\nwhere a𝑎 and b𝑏 are weights that can be used to specify a sought balance between delay and priority fee. Setting both a𝑎 and b𝑏 to 0 in the second equation then yields\n\nS(t) = w(t) \\times f(t).\n𝑆(𝑡)=𝑤(𝑡)×𝑓(𝑡).\nA doubling of one variable then has exactly the same impact on ranking as a doubling of the other. If a tx provides a 0 priority fee, it cannot be included. This is perfectly reasonable, and, actually, probably desirable. A tx also cannot be included the exact moment it arrives. This may be undesirable, and some weight a𝑎 can be added to enable direct inclusion, albeit a delay will of course also quickly accrue otherwise. Such an equation would look like this:\n\nS(t) = (w(t)+a)\\times(f(t)).\n𝑆(𝑡)=(𝑤(𝑡)+𝑎)×(𝑓(𝑡)).\nForegoing normalization has the benefit of making it more difficult for the relay to influence the outcome. This can actually be very important, given the inherently centralized nature of the design.\n\nHere I would also like to understand your argument and the intention behind the step. What are “small” and “large” transactions? Is it those that consume a lot of gas, or those that have a large raw byte size? Or is the correlation between the two somehow a part of the rationale? For example, it seems to me that ranking by the density score does not actually guarantee\n\ngiven that blockspace is measured in gas, not byte size. To achieve a higher marginal price per unit of blockspace consumption, the requirement would be to account for gas g(t)𝑔(𝑡) used by the tx, computing the density score as\n\nD(t) = \\frac{S(t)}{g(t)}.\n𝐷(𝑡)=𝑆(𝑡)𝑔(𝑡).\nIt can be clarifying to outline various alternatives, focusing on how the priority fee relates or not relates to byte size:\n\nPriority fee per gas – This is a neutral approach w.r.t. the space that the tx occupies in the block—where space is defined by the gas limit. It is simply a ranking by priority fee, since “per gas” is implied. This is used in for example FOCIL with ranked transactions (FOCILR), where a ranking by priority fee (potentially combined with other measures) serves to keep txs in or out.\nPriority fee per byte – This is a neutral approach w.r.t. the space that the tx occupies in the actual IL—where space is defined by the size limit of the IL. The total priority fee accrued from a tx is then divided by its byte size. This is, e.g., similar to the function that validators would likely prioritize txs by under FOCILR, given that they wish to squeeze out as high rewards as possible from their IL.\nPriority fee per gas/byte size – This is the approach in this post (accounting also for delay). It will favor txs with small byte sizes (as also indicated). It will also tend to favor txs with low gas consumption, given that gas consumption correlates with byte size.\nPriority fee per gas/gas used – This is an approach that guarantees a higher marginal price per unit of blockspace consumption. It will favor txs with low gas consumption. It will also tend to favor txs with low byte size, given that gas consumption correlates with byte size.\n\nIs there some specific reason why transactions with small byte sizes are prioritized for censorship resistance? I see the argument of favoring as many originators as possible, but this would in a more targeted way be accomplished by (4) not (3). It can also be argued that the most neutral approach to censorship resistance is to not take an opinionated stance on which txs that should be prioritized for inclusion. Is it perhaps the limit of 8 kb that ultimately motivates (3) over (1) or (4)? This limit is arguably self-imposed and not really a requirement for the relay, given that IL propagation is not design-critical, as opposed to in FOCIL.\n\nHow will the mechanism handle full blocks? Can the builder ignore the IL if the block is full? It appears from the text as if all highly ranked txs must be included in the block, regardless of if the block is full or not—that is to say, the design imposes the same stronger censorship resistance conditions as imposed by FOCILR. If you are pursuing these stronger censorship resistance properties, it might however be reasonable to apply a gas threshold to the IL (and by extension the block). This would encourage more usage of the relay, which could otherwise forego too much value.\n\nThis makes it even more important to clarify and analyze how the mechanism intends to deal with full blocks, and might make a design favoring (3) above less compelling.\n\nRelays integrating with builders will then seek to influence the aggregate list to maximize the value that their builder can extract; something to ponder on a bit. It is furthermore not perfectly clear to me that censorship resistance would improve, due to increased collusion concerns.\n\n post by remosm on May 2, 2025\n\n remosm\n\n Thanks for your thoughtful comment Anders. Will step through the points sequentially:\nMedian Normalization\nWe have considered a max_fee_per_gas > base_fee_per_gas filter and a (post-normalization) multiplicative derivation of S(t)𝑆(𝑡).\nWe have refrained from proposing such a model at this initial point as under EIP‑1559 any transaction whose max_fee_per_gas at least meets the base_fee_per_gas should, in principle, qualify for inclusion.\nNote that this proposal is a first step, and that in the future, such an adjustment could be made, for example, if the priority fee ends up consistently underweight versus the weight time factor, e.g. in a high volatility environment.\nAgree that with such thresholding, the normalization would not be strictly required.\nDensity adjustment\nWe are referring to the raw byte size with regards to the networking constraint, which is a current inclusion list size of <= 8kB.\nIn practical terms, a scenario to avoid is a single “large” transaction saturating the capacity of the inclusion list.\nThe lingo here should indeed reflect that the size adjustment specifically refers to the networking constraint rather than a blockspace constraint.\nHandling of full blocks\nThe builder should account for the inclusion list when packing the block. A gas threshold is worth exploring!\nShared inclusion lists\nThis reduces to how we can ensure objective application of the inclusion rule. Validators should opt out of relays that consistently diverge from peers. One option here could be a public dashboard tracking the overlap between these.\n\n post by aelowsson on May 4, 2025\n\n aelowsson\n\n Thanks, just a few clarifications:\nThe purpose of applying a threshold like max_fee_per_gas * n > base_fee_per_gas with, e.g., n=2 is to make manipulation of the normalization step more difficult. Without such a threshold, one could submit transactions with a low max_fee_per_gas to skew the normalization process, even if those transactions are not intended to be included. The thresholding of the mempool is thus specifically for making the normalization step less arbitrary, and is only necessary under normalization. If txs are directly ranked from an equation such as\n\nthen txs that are not included will not have any influence on which txs that are included. This reduces the opportunities for the relay to manipulate the outcome (albeit, it can still nudge the registration time). The transacting user that did not have its tx included can simply review included txs to confirm that those score higher (at least the score will not depend on non-included txs, while registration time is still not objective).\n\nAnd to be clear, my assumption is that the networking constraint imposed for p2p propagation in FOCIL does not really apply for the relay.\n\nOk, so the inclusion list should be adhered to under full blocks, potentially with a gas threshold. This follows the definition in FOCILR, which differs from FOCIL. In FOCILR, these stronger censorship resistance guarantees are imposed at the protocol level, as opposed to by a single relay. Builders can extract more value when the IL does not constrain which txs it must include. When the harder stance is taken at the protocol level, the proposer cannot avoid them. When the relay takes this harder stance, the proposer has the opportunity to opt out—the option to let the builder control the content of the full block still exists. This will probably have a larger effect on proposer rewards than the latency trade-off discussed in the introduction of the post.\n\nI think the issue is pretty complex given that diverging ILs generally are desirable, and that the dashboard could not reveal collusion between relays. Simply put, IL aggregation in this context seems generally difficult to get right.\n\n 17 days later\n\n post by mikeneuder on May 21, 2025\n\n mikeneuder\n\n related discussion: Resistance is ~not~ futile; CR in mev-boost\n\n post by remosm on May 22, 2025\n\n remosm\n\n Thanks for dropping the link, and props for suggesting rILs this early. We were not aware of this previous discussion, it’s great to see.\nWe think now is a good time to proceed with an implementation.\nSpecifically, by using the 8 kilobytes constraints from the FOCIL specs as a lean starting point and gas- or bytesize-adjusting the transaction inclusion scores, the impact on proposer earnings should be limited.\nThen once several relays run rILs, there is an opportunity to increase the maximum size of the rIL. Multi-relay ILs are also a promising direction to increase censorship resistance and efficiency by enforcing uniform inclusion rule enforcement, and by allowing builders to consider a single rIL only.\nAlso dropping the recording and slides from the related discussion on the FOCIL Breakout #11:\n\nSlides\nRecording\n\n post by mikeneuder on May 22, 2025\n\n mikeneuder\n\nsounds great! super cool that we arrived at the same conclusion hope this is a fruitful implementation and helps pave the way for an in-protocol FOCIL!\n\n Powered by Discourse","tokens":6206,"squid":"spider-04","role":"Research Spider","at":1791347411695,"hash":"f185ef34a3d9ed251e166eb22b5b72784623e185"}
{"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":"spider-08","role":"Oracle Spider","at":1791347420812,"hash":"25930c78315a2725030826a7d87313fcca84de36"}
{"url":"https://developer.arbitrum.io/arbitrum-essentials/bridging/cross-chain-messaging","domain":"developer.arbitrum.io","title":"Cross-chain messaging","text":"BridgingCross-chain messagingLearn how to send cross-chain messages between Ethereum and Arbitrum using retryable tickets, the ArbSys precompile, and the Outbox contract. Includes a complete Greeter tutorial demonstrating both parent-to-child and child-to-parent messaging.Request an updateThe protocol and related tooling make it easy for developers to build cross-chain applications; i.e., applications that involve sending messages from Ethereum to an , and/or from an Arbitrum chain to Ethereum.\nArbitrum SDKThe @arbitrum/sdk is a TypeScript library for bridging tokens and passing messages between parent and child Arbitrum chains. It provides a typed interface to the underlying bridge and messaging smart contracts.Links: GitHub | npm | TutorialsInstall: npm install @arbitrum/sdk\nEthereum-to-Arbitrum messaging\nCreating an arbitrary parent-to-child chain contract call occurs via the Inbox's createRetryableTicket method. Upon publishing the , the side will typically be included within minutes. Commonly, the child chain execution will automatically succeed, but if it reverts, it can be re-executed via a call to the redeem method of the ArbRetryableTx .\n\nHow-to guide: How to bridge from the parent chain to the child chain\nProtocol details: Parent to child chain messaging\n\nArbitrum-to-Ethereum messaging\nSimilarly, child chain contracts can send arbitrary messages for execution on the parent chain. These are initiated via calls to the ArbSys precompile contract's sendTxToL1 method. Upon (about one week later), you can execute them by retrieving the relevant data via a call to the NodeInterface contract's constructOutboxProof method, and then calling the Outbox's executeTransaction method.\n\nHow-to guide: How to bridge to parent chain from child chain\nProtocol details: Child to parent chain messaging\n\nTutorial: cross-chain Greeter\nThis walkthrough demonstrates both messaging directions with a simple Greeter contract that can update its greeting from the other chain.\nThe contracts\nBase Greeter — a simple contract deployed on both chains:\n// SPDX-License-Identifier: Apache-2.0\npragma solidity >=0.6.11;\n\ncontract Greeter {\n string public greeting;\n\n function greet() public view returns (string memory) {\n return greeting;\n }\n\n function setGreeting(string memory _greeting) public virtual {\n greeting = _greeting;\n }\n}\nParent chain Greeter — extends the base with a method that sends a greeting to the child chain via a retryable ticket:\n// SPDX-License-Identifier: Apache-2.0\npragma solidity >=0.6.11;\n\nimport \"./Greeter.sol\";\nimport \"@arbitrum/nitro-contracts/src/bridge/IInbox.sol\";\nimport \"@arbitrum/nitro-contracts/src/bridge/IERC20Inbox.sol\";\n\ncontract GreeterParent is Greeter {\n address public childTarget;\n IInbox public inbox;\n event RetryableTicketCreated(uint256 indexed ticketId);\n\n constructor(string memory _greeting, address _childTarget, address _inbox) {\n greeting = _greeting;\n childTarget = _childTarget;\n inbox = IInbox(_inbox);\n }\n\n function setGreetingInChild(\n string memory _greeting,\n uint256 maxSubmissionCost,\n uint256 maxGas,\n uint256 gasPriceBid\n ) public payable returns (uint256) {\n bytes memory data = abi.encodeWithSelector(Greeter.setGreeting.selector, _greeting);\n uint256 ticketID = inbox.createRetryableTicket{value: msg.value}(\n childTarget,\n 0,\n maxSubmissionCost,\n msg.sender,\n msg.sender,\n maxGas,\n gasPriceBid,\n data\n );\n emit RetryableTicketCreated(ticketID);\n return ticketID;\n }\n}\nChild chain Greeter — extends the base with a method that sends a greeting back to the parent chain via ArbSys:\n// SPDX-License-Identifier: Apache-2.0\npragma solidity >=0.6.11;\n\nimport \"./Greeter.sol\";\nimport \"@arbitrum/nitro-contracts/src/precompiles/ArbSys.sol\";\nimport \"@arbitrum/nitro-contracts/src/libraries/AddressAliasHelper.sol\";\n\ncontract GreeterChild is Greeter {\n address public parentTarget;\n event ChildToParentTxCreated(uint256 indexed withdrawalId);\n\n constructor(string memory _greeting, address _parentTarget) {\n greeting = _greeting;\n parentTarget = _parentTarget;\n }\n\n function setGreetingInParent(string memory _greeting) public returns (uint256) {\n bytes memory data = abi.encodeWithSelector(Greeter.setGreeting.selector, _greeting);\n uint256 withdrawalId = ArbSys(address(100)).sendTxToL1(parentTarget, data);\n emit ChildToParentTxCreated(withdrawalId);\n return withdrawalId;\n }\n\n /// Only accept messages from the parent chain Greeter (via address aliasing)\n function setGreeting(string memory _greeting) public override {\n require(\n msg.sender == AddressAliasHelper.applyL1ToL2Alias(parentTarget),\n \"Only callable by parent chain Greeter (aliased)\"\n );\n Greeter.setGreeting(_greeting);\n }\n}\nSending a message from parent to child chain\nThe script below deploys both contracts and sends a greeting from the parent chain to the child chain using ParentToChildMessageGasEstimator to compute retryable ticket parameters:\nimport { providers, Wallet } from 'ethers';\nimport {\n ParentToChildMessageGasEstimator,\n ParentToChildMessageStatus,\n ParentTransactionReceipt,\n} from '@arbitrum/sdk';\nimport { getBaseFee } from '@arbitrum/sdk/dist/lib/utils/lib';\n\n// Set up wallets\nconst parentWallet = new Wallet(\n process.env.PRIVATE_KEY,\n new providers.JsonRpcProvider(process.env.PARENT_CHAIN_RPC),\n);\nconst childProvider = new providers.JsonRpcProvider(process.env.CHAIN_RPC);\n\n// After deploying GreeterParent and GreeterChild (via Hardhat or your preferred tool):\nconst greeterParent = /* deployed GreeterParent contract instance */;\nconst greeterChild = /* deployed GreeterChild contract instance */;\n\n// Encode the greeting message\nconst newGreeting = 'Greeting from the parent chain';\nconst greetingData = greeterChild.interface.encodeFunctionData('setGreeting', [newGreeting]);\n\n// Estimate gas parameters for the retryable ticket\nconst gasEstimator = new ParentToChildMessageGasEstimator(childProvider);\nconst baseFee = await getBaseFee(parentWallet.provider);\n\nconst gasParams = await gasEstimator.estimateAll(\n {\n from: greeterParent.address,\n to: greeterChild.address,\n l2CallValue: 0,\n excessFeeRefundAddress: parentWallet.address,\n callValueRefundAddress: parentWallet.address,\n data: greetingData,\n },\n baseFee,\n parentWallet.provider,\n);\n\n// Send the greeting via retryable ticket\nconst tx = await greeterParent.setGreetingInChild(\n newGreeting,\n gasParams.maxSubmissionCost,\n gasParams.gasLimit,\n gasParams.maxFeePerGas,\n { value: gasParams.deposit },\n);\n\nconst receipt = await tx.wait();\nconsole.log(`Parent chain tx: ${receipt.transactionHash}`);\n\n// Wait for the child chain to execute the retryable\nconst parentToChildReceipt = new ParentTransactionReceipt(receipt);\nconst childTxReceipt = await parentToChildReceipt.waitForChildTransactionReceipt(childProvider);\n\nif (childTxReceipt.status === ParentToChildMessageStatus.REDEEMED) {\n const updatedGreeting = await greeterChild.greet();\n console.log(`Child chain greeting updated to: ${updatedGreeting}`);\n}\nKey concepts\nAddress aliasing: When a parent chain contract sends a message to the child chain, the msg.sender on the child chain is not the original contract address. Instead, it is aliased by adding 0x1111000000000000000000000000000000001111 to the address. The AddressAliasHelper library handles this — see the setGreeting override in GreeterChild above.\nGas estimation: The ParentToChildMessageGasEstimator calculates three values: maxSubmissionCost (data posting cost), gasLimit (child chain execution gas), and maxFeePerGas (child chain gas price). Together they determine the value (ETH) you must attach to the parent chain transaction.\nRetryable tickets: If the child chain execution runs out of gas, the ticket enters a \"retry\" state. It can be redeemed by anyone within its lifetime (default: 7 days) by calling ArbRetryableTx.redeem(). See the redeem-pending-retryable tutorial for a worked example.\nResources\n\nGreeter tutorial source code\nOutbox execution source code\nArbitrum SDK\nRetryable ticket lifecycle\nChild to parent messaging protocol\nHow is this guide?OverviewChoose the right approach for bridging assets and messages between Ethereum and Arbitrum.Verify child chain stateLearn how to verify child chain state on its parent chain","tokens":2048,"squid":"spider-01","role":"Chain Spider","at":1791347425423,"hash":"9f9e1c5beb941576a88150469d159cf5d97cca2c"}
{"url":"https://www.metaplex.com/docs/smart-contracts/token-metadata/faq","domain":"metaplex.com","title":"FAQ | Token Metadata","text":"Token Metadata is a legacy program. It remains supported, but is not recommended for new projects. Use Core instead.How can I filter Metadata accounts by fields located after the creators array using getProgramAccounts?When using the getProgramAccounts method from the RPC API, it is common to want to filter accounts by fields using memcmp filters.Since the memcmp filter compares arrays of bytes, this approach requires knowledge of the data structure of the account. Additionally, it requires the length of that data structure to be fixed, so we can find the position of the field we're looking for, for every single account.Unfortunately, the creators field of the Metadata Account is a vector that can contain one to five creators. This means the position of every field after it depends on how many creators the account has.Note that adding new fields to an account without adding breaking change requires appending optional fields to the accounts. This unfortunately means that any new features we may add to the Metadata Account will be after the creators field and therefore will be challenging to filter via getProgramAccounts.There are several ways to solve this problem:If every single account we are trying to filter has the same number of creators, then we can figure out the offset of the next field. We can do this by adding 4 + 34 * n to the creators offset, where n is the fixed number of creators and 4 is because 4 bytes are used to store the length of the vector. This unblocks us for every field of fixed length present after the creators field. Unfortunately, the problem reoccurs as soon as we reach another field of variable size such as another vector or an optional field. Therefore, this solution is only valid if we know the exact length of all variable fields before the field we are trying to filter with.Another solution is to crawl transactions to find the accounts we're looking for. This approach is a bit more complex and requires us to implement a custom procedure that fits our needs. For instance, we can use getSignaturesForAddress to get all transactions associated with an account and then use getTransaction on each of them to access their transaction data before filtering the ones that matter for our use case. It is also worth considering that this approach might not be the most future-proof solution since we might end up relying on instructions that could be deprecated in favor of new ones.Finally, the most robust solution is to index the data we're looking for using a Geyser Plugin. This currently requires a significant setup, but we end up with a reliable data store that mirrors the data in the Solana blockchain. Not only does it fix our filtering issue, but it also provides a much more convenient and efficient way to access our data.How can I filter Metadata accounts by collection?As mentioned in the question above, filtering by fields present after the creators array is a challenging task because it is not a field of fixed size. We recommend to use DAS for the fastest and easiest method to get collection mints. If you want to get the data directly from chain you can use the following method, but we have a Guide showing three different Methods to get all the NFTs in a collection.How to create a Soulbound Asset?For new projects, we recommend using Metaplex Core for soulbound NFTs as it provides a simpler and more efficient approach. See the Create a Soulbound NFT Asset guide for details.Token Metadata allows you to create Soulbound Assets. The best way to achieve this is using Token22 as the base SPL token, along with the non-transferrable Token Extension.If it is required to use TokenKeg SPL tokens, you can create a Soulbound Asset using the Locked Transfer Delegate on a pNFT and then locking the pNFT. Note however that this will not only prevent the owner from transferring the pNFT, but will also prevent the owner from burning it. This is why the recommendation for Soulbound Assets is to use Token22 tokens.Why are the mint and freeze authorities transferred to the Edition PDA?One question we often receive is: Why does the Token Metadata program transfer the Mint Authority and the Freeze Authority of the Mint Account to the Edition PDA when creating NFTs? Why not just void them by setting them to None?Let's take a look at why this is the case for both of these authorities separately.Mint AuthorityControlling the Mint Authority is a crucial step for ensuring the non-fungibility of a token. Without this protection, someone could mint more tokens for a given NFT and therefore make the NFT fungible.One way to prevent this from happening is to set the Mint Authority to None to ensure no one will ever be able to mint any more tokens for that NFT. However, the Token Metadata program sets that authority to the Edition PDA — which links to a Master Edition account or an Edition account.But Why? The short answer is: it enables us to deploy upgrades to the Token Metadata program at a much lower cost.Losing the Mint Authority is an irreversible action which means we could never leverage it to migrate NFTs to newer versions. For instance, say we want to change the way Original and Printed NFTs are structured and, instead of using Edition accounts, we want to leverage tokens. Without the Mint Authority, migrating NFTs to the new version would simply be impossible.Losing this authority would limit the scope of features and changes we may want to implement in the future and that's why we're not setting it to None.However, that doesn't mean someone can use that Mint Authority to mint more tokens on your NFT. The Mint Authority isn't transferred to someone's public key, it is transferred to a PDA that belongs to the Token Metadata program. Therefore, only an instruction provided by the program could make use of it and such instruction does not exist on the program. It is important to note that the Token Metadata program is completely open-source so anyone can inspect it to ensure the Mint Authority is not used to mint more tokens.Freeze AuthorityControlling the Freeze Authority allows someone to freeze a Token account, making that account immutable until it is thawed.One reason this authority is transferred to the Edition PDA of the Token Metadata program is, similarly to the Mint Authority, it increases the scope of potential new features and upgrades.However, contrary to the Mint Authority, we actually make use of that authority in the program.The FreezeDelegatedAccount and ThawDelegatedAccount instructions are the only instructions that make use of the Freeze Authority. They allow the Delegate of a Token account to freeze (and thaw) that Token account to make them what we call \"Non-Transferable NFTs\". This enables a variety of use-cases such as preventing someone from selling an NFT while it is listed in an escrowless marketplace.Why does the Metadata account have both onchain and off-chain data?The Metadata account contains onchain data, yet it also has a URI attribute which points to an off-chain JSON file which provides additional data. So why is that? Can't we just store everything onchain? Well, there are several issues with that:We have to pay rent to store data onchain. If we had to store everything within the Metadata account, which may include long texts such as the description of an NFT, it would require a lot more bytes and minting an NFT would suddenly be a lot more expensive.Onchain data is much less flexible. Once an account is created using a certain structure, it cannot easily be changed. Therefore, if we had to store everything onchain, the NFT standard would be a lot harder to evolve with the demands of the ecosystem.Therefore, splitting the data into onchain and off-chain data allows us to get the best of both worlds where onchain data can be used by the program to create guarantees and expectations for its users whereas off-chain data can be used to provide standardized yet flexible information.Are there any costs to using Token Metadata?Token Metadata currently charges very small fees ranging between 0.001 SOL and 0.01 SOL to the caller of certain instructions. More details can be found on the Protocol Fees page.Where can I find the deprecated instructions?Some of the instructions of the Token Metadata program have been through a few iterations and have been deprecated in favour of newer ones. The deprecated instructions are still available in the program but they are not documented on the Developer Hub as they are no longer the recommended way to interact with the program. That being said, if you are looking for the deprecated instructions, you can find them in the Token Metadata program repository. Here is a list of them:CreateMetadataAccountV3 has been replaced with CreateV1.UpdateMetadataAccountV2 has been replaced with CreateV1.UpdatePrimarySaleHappenedViaTokenSignMetadata use Verify instead.RemoveCreatorVerification use Unverify instead.CreateMasterEditionV3 has been replaced with CreateV1.MintNewEditionFromMasterEditionViaToken has been replaced with CreateV1.ConvertMasterEditionV1ToV2PuffMetadataVerifyCollection use Verify instead.SetAndVerifyCollection use Verify instead.UnverifyCollection use Unverify instead.Utilize - the use feature has been deprecated.ApproveUseAuthority - the use feature has been deprecated.RevokeUseAuthority - the use feature has been deprecated.ApproveCollectionAuthority use Delegate instead.RevokeCollectionAuthority use Revoke instead.FreezeDelegatedAccountThawDelegatedAccountBurnNft has been replaced by Burn.BurnEditionNft has been replaced by Burn.VerifySizedCollectionItem Sized collections have been deprecated.SetAndVerifySizedCollectionItem Sized collections have been deprecated.UnverifySizedCollectionItem Sized collections have been deprecated.SetCollectionSize Sized collections have been deprecated.SetTokenStandard the TokenStandard is automatically set now.Where can I learn more about Token Metadata Account Size Reduction?Please check the special FAQ for more information or join our Discord in case of remaining open quesitons.","tokens":2519,"squid":"spider-10","role":"Tooling Spider","at":1791347430798,"hash":"ca6e508247a2779c808b7b381a03fcb639e6d74f"}
{"url":"https://docs.chain.link/data-feeds/price-feeds/addresses?network=arbitrum&page=1","domain":"docs.chain.link","title":"Price Feed Contract Addresses | Chainlink Documentation","text":"Price Feed Contract AddressesLearn to use data feeds | LINK token addresses & faucets \nBefore using feeds in production, review the best practices below.\n NetworksSelect network:Network Status↗Arbitrum MainnetArbitrum Mainnet is an L2 network. As a best practice, use the L2 sequencer feed to verify the status of the sequencer when running applications on L2 networks. See the L2 Sequencer Uptime Feeds page for examples.Asset TypeMore DetailsShow Only SVR Feeds?RiskPairDeviationHeartbeatDecAddress and infoMedium risk0G / USD0.5%86400s80x47C38C695639aE97A00f57D6D9f5ece1DebB033CAsset name:0GAsset type:CryptoMarket hours:CryptoMedium risk1INCH / USD0.5%86400s80x4bC735Ef24bf286983024CAd5D03f0738865AaefAsset name:1inchAsset type:CryptoMarket hours:CryptoLow riskAAPL / USD0.5%86400s80x8d0CC5f38f9E802475f2CFf4F9fc7000C2E1557cAsset name:AppleAsset type:EquitiesMarket hours:NYSELow riskAAVE / USD0.5%86400s80xaD1d5344AaDE45F43E596773Bcc4c423EAbdD034Asset name:AaveAsset type:CryptoMarket hours:CryptoLow riskAAVE / USDAave-SVR0.5%86400s8Standard Proxy:0xd01d5e889659d33AAF01B34b1D41123F07B11B57Asset name:AaveAsset type:CryptoMarket hours:CryptoAave-SVR Proxy:0xf97eEAac36bdd096bb2445c7582F9095bfCE04C7⚠️ Aave Dedicated Feed: This SVR proxy feed is dedicated exclusively for use by the Aave protocol. Learn more about Aave SVR Feeds.CustomAAVE Network Emergency Count (Arbitrum)1e-7%86400sN/A0x0d20576Fae18e89A28e75B63BFce5D1B8586d739Asset name:AAVE Network Emergency Count (Arbitrum)Asset type:CryptoMarket hours:CryptoVery high riskAB / USD0.5%86400s8Contact us: chainlink_data_feeds@smartcontract.comAsset name:ABAsset type:CryptoMarket hours:CryptoLow riskADA / USD0.5%86400s80xD9f615A9b820225edbA2d821c4A696a0924051c6Asset name:CardanoAsset type:CryptoMarket hours:CryptoShowing 1 to 8 of 239 entriesData Feed Best PracticesBefore you use Data Feeds, read and understand the best practices on the Selecting Quality Data Feeds page. For best practices about data for specific asset types, see the following sections:\nBest Practices for ETF and Forex feeds\nBest Practices for Exchange Rate Feeds\nRisk Categories","tokens":529,"squid":"spider-08","role":"Oracle Spider","at":1791347433211,"hash":"601e08f1a9922023972339b8eb68b0954da0d2c4"}
{"url":"https://developer.arbitrum.io/arbitrum-essentials/bridging/deposit/eth-and-messages","domain":"developer.arbitrum.io","title":"How to bridge from parent chain to child chain","text":"BridgingDeposit (parent → child)How to bridge from parent chain to child chainStep-by-step guide to programmatically bridge ETH and send messages from Ethereum to an Arbitrum using retryable tickets and the Inbox contract.Request an updateThis guide explains how to programmatically send messages and assets from a (like Ethereum) to an . For conceptual information about the messaging protocol, see Parent-to-child chain messaging.\nPrerequisites\n\nA parent chain with funds (ETH or the chain's native token)\nAccess to the parent chain's Inbox contract address\nFamiliarity with interactions\n\nBridging ETH to a child chain\nTo bridge ETH from a parent chain to a child chain, use the depositEth method on the Inbox contract:\nfunction depositEth(address destAddr) external payable override returns (uint256)\nExample: depositing ETH\nconst inbox = new ethers.Contract(inboxAddress, inboxABI, parentSigner);\nconst tx = await inbox.depositEth(destinationAddress, {\n value: ethers.utils.parseEther('0.1'), // Amount to deposit\n});\nawait tx.wait();\nWarningDepositing ETH directly via depositEth to a contract on a child chain will not invoke that contract's fallback function. If you need to trigger a fallback function, use retryable tickets instead.\nHow ETH deposits work\nWhen you deposit ETH, the funds are held in the Arbitrum Bridge contract on the parent chain. The bridge then credits the deposited amount to your address on the child chain:\n\nAddress aliasing for contract depositors\nWhen you deposit ETH from the parent chain, the destination address on the child chain depends on the caller type:\n\nEOA caller: The deposited ETH appears at the same address on the child chain\nContract caller: The ETH goes to the contract's aliased address on the child chain\n7702-enabled account: Similar to contracts, uses the aliased address\n\nThe alias is calculated as:\nChild_Alias = Parent_Contract_Address + 0x1111000000000000000000000000000000001111\nTo recover the original parent chain address in your child chain contract, use the AddressAliasHelper library:\nmodifier onlyFromMyL1Contract() {\n require(\n AddressAliasHelper.undoL1ToL2Alias(msg.sender) == myL1ContractAddress,\n \"ONLY_COUNTERPART_CONTRACT\"\n );\n _;\n}\nSending transactions via the Delayed Inbox\nThe allows you to send arbitrary messages from the parent chain to the child chain, bypassing the if needed.\nSending signed messages\nSigned messages prove EOA ownership and execute with the signer's address on the child chain (no aliasing).\nMethod 1: sendL2Message\nMore flexible, can be called by EOAs or contracts:\nfunction sendL2Message(\n bytes calldata messageData\n) external returns (uint256)\nMethod 2: sendL2MessageFromOrigin\nCheaper gas costs, only callable by EOAs:\nfunction sendL2MessageFromOrigin(\n bytes calldata messageData\n) external returns (uint256)\nExample use case: Withdraw Ether tutorial\nSending unsigned messages\nUnsigned messages are automatically aliased for security. The Delayed Inbox provides four methods for unsigned messages, divided by sender type (EOA vs contract) and funding source (parent chain vs child chain balance):\nFrom EOAs (with nonce for replay protection)\nsendL1FundedUnsignedTransaction - Transfers value from parent to child chain:\nfunction sendL1FundedUnsignedTransaction(\n uint256 gasLimit,\n uint256 maxFeePerGas,\n uint256 nonce,\n address to,\n bytes calldata data\n) external payable returns (uint256)\nsendUnsignedTransaction - Uses child chain balance (no L1 funds transferred):\nfunction sendUnsignedTransaction(\n uint256 gasLimit,\n uint256 maxFeePerGas,\n uint256 nonce,\n address to,\n uint256 value,\n bytes calldata data\n) external returns (uint256)\nFrom contracts (standard Ethereum replay protection)\nsendContractTransaction - Uses contract's existing child chain balance:\nfunction sendContractTransaction(\n uint256 gasLimit,\n uint256 maxFeePerGas,\n address to,\n uint256 value,\n bytes calldata data\n) external returns (uint256)\nsendL1FundedContractTransaction - Transfers additional funds from parent to child:\nfunction sendL1FundedContractTransaction(\n uint256 gasLimit,\n uint256 maxFeePerGas,\n address to,\n bytes calldata data\n) external payable returns (uint256)\nCreating retryable tickets\nRetryable tickets are Arbitrum's canonical mechanism for reliable delivery. They automatically retry failed executions.\nKey retryable ticket parameters\nUnderstanding these parameters helps ensure successful creation:\n\nl1CallValue (msg.value): Total ETH sent with the from parent chain. This funds the ticket submission, gas, and call value.\n\nto: The destination child chain address that will receive the retryable ticket execution.\n\nl2CallValue: The amount of ETH to be sent as callvalue when executing the retryable on the child chain. This is supplied within the l1CallValue deposit.\n\nmaxSubmissionCost: Maximum ETH to pay for submitting the ticket. This amount is:\n\nSupplied within the deposit (l1CallValue)\nLater deducted from the sender's child chain balance\nDirectly proportional to retryable data size and parent chain basefee\n\nexcessFeeRefundAddress: Where to refund unused gas and submission costs:\n\nFormula: (gasLimit × maxFeePerGas - execution cost) + (maxSubmissionCost - submission cost)\nImportant: If auto-redeem fails, excess deposit goes to the alias of the L1 sender, not this address\n\ncallValueRefundAddress: The child chain address to credit the l2CallValue if the ticket times out or is canceled. This address is also the \"beneficiary\" with permission to cancel the ticket.\n\ngasLimit: Maximum gas for child chain execution of the ticket. Used for the automatic redemption attempt.\n\nmaxFeePerGas: Gas price bid for child chain execution, supplied in the deposit (l1CallValue).\n\ndata: Calldata to send to the destination address on the child chain.\n\nCreating a retryable ticket\nfunction createRetryableTicket(\n address to,\n uint256 l2CallValue,\n uint256 maxSubmissionCost,\n address excessFeeRefundAddress,\n address callValueRefundAddress,\n uint256 gasLimit,\n uint256 maxFeePerGas,\n bytes calldata data\n) external payable returns (uint256)\nExample using the Arbitrum SDK\nimport { ParentToChildMessageGasEstimator } from '@arbitrum/sdk';\n\n// Estimate gas for the retryable ticket\nconst parentToChildMessageGasEstimator = new ParentToChildMessageGasEstimator(childProvider);\nconst retryableGasParams = await parentToChildMessageGasEstimator.estimateAll(\n {\n from: senderAddress,\n to: destinationAddress,\n l2CallValue: ethers.utils.parseEther('0.01'),\n excessFeeRefundAddress: refundAddress,\n callValueRefundAddress: refundAddress,\n data: calldata,\n },\n await l1Provider.getBaseFeePerGas(),\n l1Provider,\n);\n\n// Create the retryable ticket\nconst inbox = new ethers.Contract(inboxAddress, inboxABI, l1Signer);\nconst tx = await inbox.createRetryableTicket(\n destinationAddress,\n ethers.utils.parseEther('0.01'), // l2CallValue\n retryableGasParams.maxSubmissionCost,\n refundAddress,\n refundAddress,\n retryableGasParams.gasLimit,\n retryableGasParams.maxFeePerGas,\n calldata,\n {\n value: retryableGasParams.deposit,\n },\n);\nawait tx.wait();\nRedeeming retryable tickets\nRetryable tickets can auto-redeem if sufficient gas is provided. If the initial redemption fails, you can manually redeem using the ArbRetryableTx precompile:\nArbRetryableTx(address(110)).redeem(ticketId);\nDeposit ETH using the Arbitrum SDK\nThe Arbitrum SDK provides an EthBridger class that simplifies depositing ETH from the parent chain to the child chain:\nimport { ethers } from 'ethers';\nimport { getArbitrumNetwork, EthBridger } from '@arbitrum/sdk';\n\n// Get the Arbitrum network and create an EthBridger\nconst childNetwork = await getArbitrumNetwork(childProvider);\nconst ethBridger = new EthBridger(childNetwork);\n\n// Deposit ETH from parent chain to child chain\nconst depositTx = await ethBridger.deposit({\n amount: ethers.utils.parseEther('0.1'),\n parentSigner,\n});\nconst depositReceipt = await depositTx.wait();\n\n// Wait for the deposit to be processed on the child chain\nconst childResult = await depositReceipt.waitForChildTransactionReceipt(childProvider);\nconsole.log('Deposit complete:', childResult.complete);\nDeposit to a different address\nTo deposit ETH to a recipient address that differs from the sender, use depositTo:\nconst depositTx = await ethBridger.depositTo({\n amount: ethers.utils.parseEther('0.1'),\n parentSigner,\n childProvider,\n destinationAddress: '0x...recipient',\n});\nTutorials\n\neth-deposit tutorial — full walkthrough of depositing ETH using the SDK\neth-deposit-to-different-address tutorial — depositing ETH to a different recipient\n\nNext steps\n\nFor protocol-level details, see Parent to child chain messaging\nFor token bridging, see Token bridging overview\nFor bridging tokens programmatically, see Bridge tokens programmatically\nHow is this guide?Custom gas token chainsGuide to using the Arbitrum SDK for custom gas token chains, including APIs for ERC-20 deposits, withdrawals, and bridging on Arbitrum chains configured with non-ETH gas tokens.TokensStep-by-step guide to depositing ERC-20 tokens from Ethereum (parent chain) to an Arbitrum child chain using the token bridge gateway system and Arbitrum SDK.","tokens":2278,"squid":"spider-01","role":"Chain Spider","at":1791347435322,"hash":"90d804718c18f82ae5704d971c2a3b83a490ce06"}
{"url":"https://docs.chain.link/data-feeds/price-feeds","domain":"docs.chain.link","title":"Price Feeds | Chainlink Documentation","text":"Price FeedsChainlink Data Feeds provide data that is aggregated from many data sources by a decentralized set of independent node operators. The Decentralized Data Model describes this in detail. However, there are some exceptions where data for a feed can come only from a single data source or where data values are calculated. Read the Selecting Quality Data Feeds to learn about the different data feed categories and how to identify them. What's next > Learn how to read answers from Data Feeds > Learn how to get Historical Price Data > Find contract addresses for Price Feeds > Data Feeds API Reference","tokens":152,"squid":"spider-08","role":"Oracle Spider","at":1791347444291,"hash":"71f4bb7eb05874db1b53b8f694c84e89b315007c"}
{"url":"https://developer.arbitrum.io/arbitrum-essentials/precompiles","domain":"developer.arbitrum.io","title":"Precompiles","text":"PrecompilesArbitrum-specific precompiled contracts and their interfaces.Request an updateArbitrum exposes chain functionality through precompiled contracts. This section covers what the precompiles do and how to call them.\nOverviewWhat precompiles are and how the client runs them natively.ReferenceArbSys, ArbGasInfo, ArbRetryableTx, and the rest, with addresses.How is this guide?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.OverviewOverview of Arbitrum precompiled contracts — predefined smart contracts executed natively by the Arbitrum client for optimized performance. Covers both Ethereum-standard and Arbitrum-specific precompiles.","tokens":199,"squid":"spider-01","role":"Chain Spider","at":1791347445169,"hash":"5d7433e1f3c1b896e723682dda12e7e159b7a04d"}
{"url":"https://www.metaplex.com/docs/smart-contracts/token-metadata/getting-started/rust","domain":"metaplex.com","title":"Rust SDK | Token Metadata","text":"Token Metadata is a legacy program. It remains supported, but is not recommended for new projects. Use Core instead.If you are a Rust developer, you can also use a Rust client SDK to interact with the Token Metadata program. Metaplex provides a dedicated Rust client crate, which is a lightweight crate with minimal dependencies.To get started, you'll need to add the mpl-token-metadata dependency to your project. From a terminal on the root folder of your project:cargo add mpl-token-metadata\nThis will all the latest version of the crate in your project's dependency list.If you are using a solana-program version prior to 1.16, first add the solana-program dependency to your project and then add mpl-token-metadata. This will make sure you only have a single copy of the borsh crate.🧱 StructureThe client SDK is divided into several modules:accounts: structs representing the accounts of the programerrors: enum representing program errorsinstructions: structs to facilitate the creation of instructions from client (off-chain) and programs (onchain), and instruction argumentstypes: structs representing types used by the programA good starting point to explore is the instructions module, which contains helpers to create instructions to interact with Token Metadata. These are designed to be flexible and easy-to-use. If an instruction requires additional types, these will be referenced from the types module. If you want to deserialize the content of a Token Metadata account, the accounts module has a struct representing each account with helpers methods to deserialize their content.🏗️ Instruction BuildersOne of the main features of the client SDK is to facilitate the creation of instructions. There are two types of instruction builders depending on whether you are writing off-chain or onchain code, and both support passing accounts by name and optional positional accounts.Client (off-chain)These are intended to be used by off-chain client code. Each instruction is represented by a struct, where its fields are the Pubkeys of the required accounts.CreateV1 instruction struct:pub struct CreateV1 {\n /// Unallocated metadata account with address as pda\n /// of ['metadata', program id, mint id]\n pub metadata: Pubkey,\n\n /// Unallocated edition account with address as pda\n /// of ['metadata', program id, mint, 'edition']\n pub master_edition: Option<Pubkey>,\n\n /// Mint of token asset\n pub mint: (Pubkey, bool),\n\n /// Mint authority\n pub authority: Pubkey,\n\n /// Payer\n pub payer: Pubkey,\n\n /// Update authority for the metadata account\n pub update_authority: (Pubkey, bool),\n\n /// System program\n pub system_program: Pubkey,\n\n /// Instructions sysvar account\n pub sysvar_instructions: Pubkey,\n\n /// SPL Token program\n pub spl_token_program: Pubkey,\n}\nAfter filling in the instruction account fields, you can use the instruction(...) method to generate the corresponding Solana Instruction:Creating an Instruction for CreateV1:// instruction args\nlet args = CreateV1InstructionArgs {\n name: String::from(\"My pNFT\"),\n symbol: String::from(\"MY\"),\n uri: String::from(\"https://my.pnft\"),\n seller_fee_basis_points: 500,\n primary_sale_happened: false,\n is_mutable: true,\n token_standard: TokenStandard::ProgrammableNonFungible,\n collection: None,\n uses: None,\n collection_details: None,\n creators: None,\n rule_set: None,\n decimals: Some(0),\n print_supply: Some(PrintSupply::Zero),\n};\n\n// instruction accounts\nlet create_ix = CreateV1 {\n metadata,\n master_edition: Some(master_edition),\n mint: (mint_pubkey, true),\n authority: payer_pubkey,\n payer: payer_pubkey,\n update_authority: (payer_pubkey, true),\n system_program: system_program::ID,\n sysvar_instructions: solana_program::sysvar::instructions::ID,\n spl_token_program: spl_token::ID,\n};\n\n// creates the instruction\nlet create_ix = create_ix.instruction(args);\nAt this point, create_ix is an Instruction ready to be added to a transaction and sent for processing.In the example above, you probably noticed that even when we do not need to provide a value for an optional argument, we still need to specify None. To facilitate the creation of instructions even further, you can use the *Builder companion struct.Creating an Instruction using CreateV1Builder:let create_ix = CreateV1Builder::new()\n .metadata(metadata)\n .master_edition(Some(master_edition))\n .mint(mint_pubkey, true)\n .authority(payer_pubkey)\n .payer(payer_pubkey)\n .update_authority(payer_pubkey, true)\n .is_mutable(true)\n .primary_sale_happened(false)\n .name(String::from(\"My pNFT\"))\n .uri(String::from(\"https://my.pnft\"))\n .seller_fee_basis_points(500)\n .token_standard(TokenStandard::ProgrammableNonFungible)\n .print_supply(PrintSupply::Zero)\n .instruction();\nThe end result is the same create_ix instruction to be added to a transaction and sent for processing.Cross Program Invocation (onchain)When you are writing a program that needs to interact with Token Metadata, you can use the onchain Cross Program Invocation (CPI) builder. They work similarly to off-chain builders, with the main difference being that they expect AccountInfo references instead of Pubkeys.TransferV1Cpi instruction struct:pub struct TransferV1Cpi<'a> {\n /// The program to invoke.\n pub __program: &'a AccountInfo<'a>,\n\n /// Token account\n pub token: &'a AccountInfo<'a>,\n\n /// Token account owner\n pub token_owner: &'a AccountInfo<'a>,\n\n /// Destination token account\n pub destination_token: &'a AccountInfo<'a>,\n\n /// Destination token account owner\n pub destination_owner: &'a AccountInfo<'a>,\n\n /// Mint of token asset\n pub mint: &'a AccountInfo<'a>,\n\n /// Metadata (pda of ['metadata', program id, mint id])\n pub metadata: &'a AccountInfo<'a>,\n\n /// Edition of token asset\n pub edition: Option<&'a AccountInfo<'a>>,\n\n /// Owner token record account\n pub token_record: Option<&'a AccountInfo<'a>>,\n\n /// Destination token record account\n pub destination_token_record: Option<&'a AccountInfo<'a>>,\n\n /// Transfer authority (token owner or delegate)\n pub authority: &'a AccountInfo<'a>,\n\n /// Payer\n pub payer: &'a AccountInfo<'a>,\n\n /// System Program\n pub system_program: &'a AccountInfo<'a>,\n\n /// Instructions sysvar account\n pub sysvar_instructions: &'a AccountInfo<'a>,\n\n /// SPL Token Program\n pub spl_token_program: &'a AccountInfo<'a>,\n\n /// SPL Associated Token Account program\n pub spl_ata_program: &'a AccountInfo<'a>,\n\n /// Token Authorization Rules Program\n pub authorization_rules_program: Option<&'a AccountInfo<'a>>,\n\n /// Token Authorization Rules account\n pub authorization_rules: Option<&'a AccountInfo<'a>>,\n\n /// The arguments for the instruction.\n pub __args: TransferV1InstructionArgs,\n}\nThe instruction struct requires three different pieces of information: (1) the program to CPI into it – __program field; (2) a variable list of accounts represented by references to AccountInfo; (3) the instruction args – __args field. To simplify the creation of the struct, there is a new(...) factory method. After filling in the program, instruction accounts and argument fields, you can use the invoke() or invoke_signed(...) method to perform the CPI.Invoking the TransferV1Cpi instruction:// creates the instruction\nlet cpi_transfer = TransferV1Cpi::new(\n metadata_program_info,\n TransferV1CpiAccounts {\n token: owner_token_info,\n token_owner: owner_info,\n destination_token: destination_token_info,\n destination_owner: destination_info,\n mint: mint_info,\n metadata: metadata_info,\n authority: vault_info,\n payer: payer_info,\n system_program: system_program_info,\n sysvar_instructions: sysvar_instructions_info,\n spl_token_program: spl_token_program_info,\n spl_ata_program: spl_ata_program_info,\n edition: edition_info,\n token_record: None,\n destination_token_record: None,\n authorization_rules: None,\n authorization_rules_program: None,\n },\n TransferV1InstructionArgs {\n amount,\n authorization_data: None,\n },\n);\n\n// performs the CPI\ncpi_transfer.invoke_signed(&[&signer_seeds])\nYou have probably noticed (again) that for every optional account/argument that we do not pass a value, we still need to set it to None. Similarly to the off-chain instructions, CPI instructions have a companion *Builder struct.Invoking the TransferV1Cpi instruction using TransferV1CpiBuilder:// creates the instruction\nlet cpi_transfer = TransferV1CpiBuilder::new(metadata_program_info)\n .token(owner_token_info)\n .token_owner(owner_info)\n .destination_token(destination_token_info)\n .destination_owner(destination_info)\n .mint(mint_info)\n .metadata(metadata_info)\n .edition(edition_info)\n .authority(vault_info)\n .payer(payer_info)\n .system_program(system_program_info)\n .sysvar_instructions(sysvar_instructions_info)\n .spl_token_program(spl_token_program_info)\n .spl_ata_program(spl_ata_program_info)\n .amount(amount);\n\n// performs the CPI\ncpi_transfer.invoke_signed(&[&signer_seeds])\n🔎 PDA helpersAnother set of useful helpers of the SDK are the PDA lookups. Account types representing PDAs (e.g., Metadata) have associated functions to find/create PDA Pubkeys.Implementation of find_pda and create_pda helper methods:impl Metadata {\n pub fn find_pda(mint: Pubkey) -> (Pubkey, u8) {\n Pubkey::find_program_address(\n &[\n \"metadata\".as_bytes(),\n crate::MPL_TOKEN_METADATA_ID.as_ref(),\n mint.as_ref(),\n ],\n &crate::MPL_TOKEN_METADATA_ID,\n )\n }\n\n pub fn create_pda(\n mint: Pubkey,\n bump: u8,\n ) -> Result<Pubkey, PubkeyError> {\n Pubkey::create_program_address(\n &[\n \"metadata\".as_bytes(),\n crate::MPL_TOKEN_METADATA_ID.as_ref(),\n mint.as_ref(),\n &[bump],\n ],\n &crate::MPL_TOKEN_METADATA_ID,\n )\n }\n}\nThe find_pda method is usually used on off-chain clients:let (metadata_pubkey, _) = Metadata::find_pda(mint);\nThe create_pda method is recommended to be used onchain, since it can save compute units in comparison to find_pda, but it does require storing the bump used to generate the PDA derivation:let metadata_pubkey = Metadata::create_pda(mint, bump)?;\n🔗 Helpful linksGitHub repositoryCrate pageAPI references","tokens":2483,"squid":"spider-10","role":"Tooling Spider","at":1791347451518,"hash":"27283d330f938cd4b22b83430b8451e060ed7b28"}
{"url":"https://developer.arbitrum.io/arbitrum-essentials/precompiles/overview","domain":"developer.arbitrum.io","title":"Precompiles overview","text":"PrecompilesPrecompiles overviewOverview of Arbitrum precompiled contracts — predefined smart contracts executed natively by the Arbitrum client for optimized performance. Covers both Ethereum-standard and Arbitrum-specific precompiles.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.How is this guide?PrecompilesArbitrum-specific precompiled contracts and their interfaces.ReferenceComplete reference for all Arbitrum precompiled contracts, including ArbSys, ArbRetryableTx, ArbGasInfo, ArbAggregator, and more. Lists methods, addresses, Solidity interfaces, and Go implementations.","tokens":347,"squid":"spider-01","role":"Chain Spider","at":1791347454471,"hash":"ccfdd4ec73b0687b5c955bb392a4bf16916e3ec9"}
{"url":"https://docs.chain.link/changelog","domain":"docs.chain.link","title":"Chainlink Documentation | Chainlink Documentation","text":"Integration Oct 4, 2026 0GADI NetworkApechainAptosArbitrumArcAvalancheBaseBerachainBitlayerBlastBNB ChainBobBotanixCantonCeloDogeOSEthereumGiwaGnosis ChainGravityHashKey ChainHederaHyperEVMInjectiveInkJovayLensLineaMantleMegaETHMetisMonadopBNBOPPerennialPharosPlasmaPolygonKatanaRobinhood ChainRoninScrollSei NetworkSeismicShibariumSolanaSoneiumSonicStableStellarTaikoUnichainWorld ChainX LayerZKsync+52 Data Streams Added support to Data Streams New Data Streams available on all supported networks: GLV [USDG-USDG] / USD SKHY / USD SKHY / USD SKHY / USD CL / USDT Integration Oct 4, 2026 ArbitrumTempoEthereumBase Data Feeds Added support to Data Feeds New Data Feeds available: GLV / USD Arbitrum GLV / USD Arbitrum GLV / USD Arbitrum HASTRAPRIME / WYLDS Tempo OPENUSD / USD Ethereum OPENUSD / USD Base OPENUSD / USD Tempo Integration Oct 2, 2026 CCIP Cross-chain token (CCT) standard: Added support for new tokens Newly supported tokens: KNTQ Kinetiq Governance Token Release Oct 1, 2026 CRE CRE CLI v1.36.0 — Detailed Execution Statuses CRE CLI version 1.36.0 is now available. This release adds detailed and classified execution statuses to cre execution status, cre execution list, and cre workflow get, so runs that finish with capability errors are labeled SUCCESS (completed with errors) and platform-caused failures are flagged with a hint. It also fixes telemetry for commands that don't require login, such as cre generate-bindings, cre workflow build, and cre workflow hash.Update your CLI by running cre update when prompted, or follow the CLI Installation guide for fresh installations.See all changes on GitHub Update Oct 1, 2026 Ethereum CRE Ethereum Glamsterdam upgrade: action required for workflows with a gas limit Ethereum is upgrading to Glamsterdam during Q4 2026, which changes the gas model of the chain. No action is required unless your workflow sets a gas limit.Timelines:Ethereum Sepolia — 6 October 2026 at 13:53:36 UTCEthereum Hoodi — Q4 2026 (to be confirmed)Ethereum Mainnet — Q4 2026 (to be confirmed)Onchain writes to each network may fail for roughly 30 minutes before and after its upgrade. If your workflow sets a gas limit, start testing against Ethereum Sepolia from 6 October 2026 (add gas headroom or unset the gas limit), then update your workflows for Ethereum Mainnet once it is upgraded.See Network Upgrades for details. Integration Sep 29, 2026 Stellar Data Feeds Added support to Data Feeds New Data Feeds available: BTC / USD Stellar LINK / USD Stellar ETH / USD Stellar EURC / USD Stellar FLHY / USD Stellar XAUM / USD Stellar XLM / USD Stellar USDT / USD Stellar USDC / USD Stellar Deprecation Sep 29, 2026 EthereumAvalanchePolygonArbitrum Data Feeds Scheduled updates sunset for select Data Feeds Scheduled (cron-based) updates for the Data Feeds listed below are being sunset. These updates were deprecated in August 2025 and will be fully shut down on or shortly after September 30, 2026.These feeds are not being deprecated. Only the scheduled updates that request a new round at a fixed time are being removed. Each feed continues to update normally based on its heartbeat and deviation thresholds.Affected feeds:EthereumETH / USDBTC / USDLINK / USDUNI / USDSUSHI / USDAAVE / USDAvalancheAVAX / USDBTC / USDETH / USDMIM / USDLINK / USDUSDC / USDPolygonCalculated MaticX / USDArbitrumBTC / USDETH / USDARB / USDSOL / USDTIA / USDDOGE / USDPEPE / USDNo action is required if your integration relies on heartbeat and deviation-threshold updates. If your integration depends on updates at a specific time, review your implementation before September 30, 2026. Integration Sep 29, 2026 CCIP Cross-chain token (CCT) standard: Added support for new tokens Newly supported tokens: cbADA, cbLTC Coinbase Wrapped ADA Coinbase Wrapped LTC Release Sep 29, 2026 Stellar Data Feeds Data Feeds expands to Stellar Chainlink Data Feeds are now available on Stellar. Data Feeds on Stellar use a single proxy contract that serves every feed, and consumers select a feed by its 32-byte data_id rather than a per-feed contract address.See Using Data Feeds on Stellar to get started, and Price Feed contract addresses for Stellar for feed IDs and onchain parameters. Release Sep 28, 2026 Nodes Chainlink Node v2.66.0 Chainlink Node v2.66.0 is now available. See the Release Notes for details. Release Sep 28, 2026 CCIP Announcing CCIP 2.0 CCIP 2.0 introduces new opt-in features:Additive security: Add issuer, third-party, or institution-operated Cross-Chain Verifiers (CCVs) for additional verification and control. The default remains the secure, battle-tested CCIP DON.Faster-than-finality (FTF) transfers: Control confirmation parameters for standard or faster-than-finality cross-chain execution, tailored to your needs and risk threshold. The default remains waiting for full finality.Modular fee components: Customize fees for your token or your verifier.Built-in compliance functions: Native integration with the Chainlink Automated Compliance Engine (ACE) enables policy checks without breaking composability.Permissionless execution / No Exec: Customize execution by opting into No Exec (more controlled execution), using a custom executor, or executing permissionlessly. The default remains the Chainlink executor service.The CCIP Architecture Overview explains the new modular architecture of CCIP 2.0. The Router contract, CCIP's single point of interface, remains unchanged on all networks.This release ships with a full suite of developer tooling, including the CCIP API, SDK, CLI, and CCV Starter Kit. Integration Sep 27, 2026 Arc SmartData Added support to SmartData New SmartData Feeds available: XAUM NAV Arc Integration Sep 27, 2026 TRONEthereumOPRobinhood ChainArbitrumMonad+2 Data Feeds Added support to Data Feeds New Data Feeds available: USDE / USD TRON HASTRAAUTO / WYLDS Ethereum PAXGy / XAU Ethereum PAXGY / GOLD OP GLD / USD Robinhood Chain SUSDAI / USD Ethereum SYZUSD / YZUSD Arbitrum USHP / USD Ethereum USHP / USD Valuation Ethereum USFRon / USD Ethereum USFRon / USD Ethereum wEWYx / USD Monad wNVDAx / USD Monad wQQQx / USD Monad wSPCXx / USD Monad wSPYx / USD Monad wTSLAx / USD Monad Integration Sep 27, 2026 0GADI NetworkApechainAptosArbitrumArcAvalancheBaseBerachainBitlayerBlastBNB ChainBobBotanixCantonCeloDogeOSEthereumGiwaGnosis ChainGravityHashKey ChainHederaHyperEVMInjectiveInkJovayLensLineaMantleMegaETHMetisMonadopBNBOPPerennialPharosPlasmaPolygonKatanaRobinhood ChainRoninScrollSei NetworkSeismicShibariumSolanaSoneiumSonicStableStellarTaikoUnichainWorld ChainX LayerZKsync+52 Data Streams Added support to Data Streams New Data Streams available on all supported networks: xyz:GOOGL / USDC xyz:AMZN / USDC CASHCAT / USD cEPIC XAU / USDT xyz:MSFT / USDC MSTR / USDT PONS / USD SNDK / USDT SKHYNIX / USDT SYRUPUSDT / USDT STRUSD / TRUSD TRUSD UNITREE / USDT ZHIPU / USDT Deprecation Sep 22, 2026 CCIP CCIP deprecated on Superseed Sepolia CCIP is no longer supported on Superseed Sepolia. Integration Sep 22, 2026 CCIP Cross-chain token (CCT) standard: Added support for new tokens Newly supported tokens: trUSD, strUSD trUSD Staked trUSD Release Sep 21, 2026 Nodes Chainlink Node v2.65.0 Chainlink Node v2.65.0 is now available. See the Release Notes for details. Integration Sep 18, 2026 X Layer SmartData Added support to SmartData New SmartData Feeds available: deJTRSY NAV X Layer deJAAA NAV X Layer rwaUSD NAV X Layer Integration Sep 18, 2026 ArcArbitrum Data Feeds Added support to Data Feeds New Data Feeds available: ARS / USD Arc SYRUPUSDG / USDG Arbitrum Release Sep 18, 2026 CRE CRE CLI v1.35.0 — Ethereum Hoodi Testnet Support CRE CLI version 1.35.0 is now available. This release adds support for Ethereum Hoodi Testnet for local simulation via cre workflow simulate and for production onchain writes. The Go SDK (v1.21.0) and TypeScript SDK (v1.22.0) add the corresponding EthereumHoodiTestnet chain constant.Update your CLI by running cre update when prompted, or follow the CLI Installation guide for fresh installations.See all changes on GitHub Integration Sep 18, 2026 0GADI NetworkApechainAptosArbitrumArcAvalancheBaseBerachainBitlayerBlastBNB ChainBobBotanixCantonCeloDogeOSEthereumGiwaGnosis ChainGravityHashKey ChainHederaHyperEVMInjectiveInkJovayLensLineaMantleMegaETHMetisMonadopBNBOPPerennialPharosPlasmaPolygonKatanaRobinhood ChainRoninScrollSei NetworkSeismicShibariumSolanaSoneiumSonicStableStellarTaikoUnichainWorld ChainX LayerZKsync+52 Data Streams Added support to Data Streams New Data Streams available on all supported networks: xyz:META / USDC oTFYe SLP / USD SPCX / USDT Integration Sep 18, 2026 CCIP Cross-chain token (CCT) standard: Added support for new tokens Newly supported tokens: SPX SPX6900 Integration Sep 18, 2026 EthereumArbitrumPolygonGnosis ChainBaseBobPlasma+3 Data Feeds Feeds scheduled for deprecation The following Data Feeds are scheduled for deprecation on September 30th, 2026. See Feeds Scheduled For Deprecation for shutdown dates and the latest status: EIGEN / USD Ethereum MLN / USD Arbitrum FTT / USD Polygon FTT / USD Gnosis Chain MAVIA / USD Base OUSDT / USD Bob SUSDAI / USD Plasma Release Sep 17, 2026 CRE CRE CLI v1.34.0 — Updated SDK Versions CRE CLI version 1.34.0 is now available. This release updates the bundled SDK dependencies to Go SDK v1.20.0 and TypeScript SDK v1.21.1.Update your CLI by running cre update when prompted, or follow the CLI Installation guide for fresh installations.See all changes on GitHub Integration Sep 16, 2026 Arbitrum Data Streams Streams scheduled for deprecation The following Data Streams are scheduled for deprecation. See Deprecating Data Streams for shutdown dates and the latest status: ABBV / USD ALP / USD AUSD / USD BAC / USD BRBTC / USD BRKB / USD BSOL / USD BMNR / USD BOME / USD BRENTOIL / USDC BRETT / USD MEW / USD CVX / USD COCO / USD DEEP / USD DOGS / USD DRG / USD FROGGIE / USD AI / USD GOAT / USD HD / USD EWJ / USD JITOSOL / USD JNJ / USD kmHYPE / HYPE KRWQ / KRW LBTC / USD MSOL / USD MA / USD MELANIA / USD MEME / USD MPLX / USD USD / MXN MILLI / USD MOOLAH / USD EGLD / USD NG / USD NXDR / USD XBTC / POR PI / USD EZETH / ETH CRM / USD SATS / USD SBET / USD SEIYAN / USD SENT / USD SKHY / USDT USTB / USD TBTC / USD TSLA / USDT tKalshi / USD TURBO / USD USDTB / USD WAL / USD WEETH / USD WSTETH / USD Integration Sep 16, 2026 0GADI NetworkApechainAptosArbitrumArcAvalancheBaseBerachainBitlayerBlastBNB ChainBobBotanixCantonCeloDogeOSEthereumGiwaGnosis ChainGravityHashKey ChainHederaHyperEVMInjectiveInkJovayLensLineaMantleMegaETHMetisMonadopBNBOPPerennialPharosPlasmaPolygonKatanaRobinhood ChainRoninScrollSei NetworkSeismicShibariumSolanaSoneiumSonicStableStellarTaikoUnichainWorld ChainX LayerZKsync+52 Data Streams Added support to Data Streams New Data Streams available on all supported networks: EUR / USD Integration Sep 16, 2026 Arc CCIP CCIP Expands to Arc Network Mainnet Chainlink CCIP expands support to new blockchains: Arc Network Mainnet Integration Sep 15, 2026 Arc Data Streams Data Streams Expands to Arc Mainnet Chainlink Data Streams is available for Arc Mainnet. The verifier proxy addresses and stream IDs are available on the Stream Addresses page. Release Sep 14, 2026 Nodes Chainlink Node v2.64.0 Chainlink Node v2.64.0 is now available. See the Release Notes for details. Deprecation Sep 14, 2026 CCIP CCIP deprecated on Janction Testnet CCIP is no longer supported on Janction Testnet. Integration Sep 13, 2026 0GADI NetworkApechainAptosArbitrumArcAvalancheBaseBerachainBitlayerBlastBNB ChainBobBotanixCantonCeloDogeOSEthereumGiwaGnosis ChainGravityHashKey ChainHederaHyperEVMInjectiveInkJovayLensLineaMantleMegaETHMetisMonadopBNBOPPerennialPharosPlasmaPolygonKatanaRobinhood ChainRoninScrollSei NetworkSeismicShibariumSolanaSoneiumSonicStableStellarTaikoUnichainWorld ChainX LayerZKsync+52 Data Streams Added support to Data Streams New Data Streams available on all supported networks: xyz:MU / USDC PYUSD / USD xyz:SNDK / USDC 00625.HK / HKD xyz:SKHX / USDC Integration Sep 13, 2026 Arc SmartData Added support to SmartData New SmartData Feeds available: cirBTC PoR Arc Integration Sep 13, 2026 ArcArbitrumEthereum Data Feeds Added support to Data Feeds New Data Feeds available: AAVE / USD Arc AUD / USD Arc AVAX / USD Arc savETH / avETH Arbitrum BTC / USD Arc BCH / USD Arc BNB / USD Arc BRL / USD Arc CAD / USD Arc LINK / USD Arc EURC / USD Arc USDC / USD Arc CBBTC / USD Arc ETH / USD Arc EUR / USD Arc HYPE / USD Arc JPY / USD Arc KRW / USD Arc MXN / USD Arc PAXG / USD Arc PSTUSDC / USDC Arc SLP / USD Ethereum SOL / USD Arc SUSDAI / USDAI Arc syrupUSDC / USDC Arc USDT / USD Arc TRX / USD Arc UNI / USD Arc XRP / USD Arc Integration Sep 11, 2026 CCIP Cross-chain token (CCT) standard: Added support for new tokens Newly supported tokens: TRUF Truflation Deprecation Sep 10, 2026 CCIP CCIP deprecated on Scroll Sepolia CCIP is no longer supported on Scroll Sepolia. Deprecation Sep 10, 2026 Data Streams `lastTradedPrice` deprecated on 24/5 U.S. Equity Streams On Chainlink 24/5 U.S. Equity Streams, lastTradedPrice is deprecated as a production input. New integrations should not depend on it, and existing integrations should remove production dependencies by October 12, 2026. The field will remain in the RWA Advanced (v11) schema and may continue to be populated, but after October 12, 2026 it will no longer be monitored for availability, accuracy, or data quality on these streams. This change does not apply to other streams using the RWA Advanced (v11) schema. Release Sep 10, 2026 CRE CRE CLI v1.33.0 — Solana Workflow Updates CRE CLI version 1.33.0 is now available. This release includes updates to Solana workflow support.Update your CLI by running cre update when prompted, or follow the CLI Installation guide for fresh installations.See all changes on GitHub Integration Sep 9, 2026 Arc Data Feeds Data Feeds Expands to Arc Mainnet Chainlink Data Feeds is available on Arc Mainnet. View the available price feed information on the Price Feed Addresses page. Deprecation Sep 8, 2026 CCIP CCIP deprecated on Bitlayer Testnet CCIP is no longer supported on Bitlayer Testnet. Release Sep 8, 2026 Nodes Chainlink Node v2.63.0 Chainlink Node v2.63.0 is now available. See the Release Notes for details. Integration Sep 4, 2026 0GADI NetworkApechainAptosArbitrumArcAvalancheBaseBerachainBitlayerBlastBNB ChainBobBotanixCantonCeloDogeOSEthereumGiwaGnosis ChainGravityHashKey ChainHederaHyperEVMInjectiveInkJovayLensLineaMantleMegaETHMetisMonadopBNBOPPerennialPharosPlasmaPolygonKatanaRobinhood ChainRoninScrollSei NetworkSeismicShibariumSolanaSoneiumSonicStableStellarTaikoUnichainWorld ChainX LayerZKsync+52 Data Streams Added support to Data Streams New Data Streams available on all supported networks: GOOGL / USDT AMZN / USDT xyz:AAPL / USDC AVGO / USDT GPC / USDC META / USDT MU / USDT MSFT / USDT NVDA / USDT xyz:NVDA / USDC SYRUPUSDG / USDG TSM / USDT USDAI / USD Integration Sep 4, 2026 Arbitrum Data Streams Streams scheduled for deprecation The following Data Streams are scheduled for deprecation on September 16th, 2026. See Deprecating Data Streams for shutdown dates and the latest status: ATH / USD AEVO / USD ALP / SOL BYND / USD BILL / USD BSV / USD BTT / USD BOB / USD BRL / USDT CELO / USD DEGEN / USD ENA / USDC ETC / USD GNS / USD GALA / USD DRIV / USD IMX / USD JUPSOL / USD KAITO / USD KTA / USD RSETH / ETH KSM / USD LISTA / USD mevBTC / BTC NEO / USD NEXO / USD ONYC / USD OPG / USD ORDER / USD PNUT / USD PYTH / USD QNT / USD RLP / USD INF / USD SCR / USD SKL / USD SPK / USD STRK / USD sUSDf / USDf SYRUPUSDC / USD THETA / USD UETH / USD USOL / USD USAT / USD USDT0 / USD USUAL / USD XVS / USD wstETH / stETH Integration Sep 4, 2026 MonadBase SmartData Added support to SmartData New SmartData Feeds available: rwaUSD NAV Monad FRNT PoR Base Integration Sep 4, 2026 ArbitrumPlasmaEthereum Data Feeds Feeds scheduled for deprecation The following Data Feeds are scheduled for deprecation on September 16th, 2026. See Feeds Scheduled For Deprecation for shutdown dates and the latest status: DOLO / USD Arbitrum plUSD / USDT Plasma USD0++ / USD Ethereum Integration Sep 4, 2026 BaseMonadOPEthereum Data Feeds Added support to Data Feeds New Data Feeds available: APXUSD / USD Base APXUSD / USD Monad BEHYPE / HYPE OP ETHFI / USD OP EURC / USD OP FRXUSD / USD OP GHO / USD OP HYPE / USD OP HYPE / USD Base TBLL / USD OP SGOVon / USD Ethereum SGOVon / USD Ethereum PAXG / USD Base YZCASH / USDC Monad ZEC / USD Base Release Sep 3, 2026 CRE CRE CLI v1.32.0 — Login Fixes, Safer Windows Installation, and Solana Updates CRE CLI version 1.32.0 is now available. This release fixes bugs that could cause cre login to fail, makes Windows installation safer by verifying the downloaded CLI is authentic before installing, and includes updates to Solana workflow support.Update your CLI by running cre update when prompted, or follow the CLI Installation guide for fresh installations.See all changes on GitHub Integration Sep 2, 2026 Mova CCIP CCIP Expands to Mova Mainnet & Testnet Chainlink CCIP expands support to new blockchains: Mova Mainnet Mova Testnet Release Aug 31, 2026 Nodes Chainlink Node v2.62.0 Chainlink Node v2.62.0 is now available. See the Release Notes for details. Integration Aug 31, 2026 CCIP Cross-chain token (CCT) standard: Added support for new tokens Newly supported tokens: SOLV Solv Integration Aug 30, 2026 Base Data Feeds Added support to Data Feeds New Data Feeds available: BTC / USD Base ADA / USD Base DOGE / USD Base ETH / USD Base LTC / USD Base SOL / USD Base XRP / USD Base Integration Aug 30, 2026 0GADI NetworkApechainAptosArbitrumArcAvalancheBaseBerachainBitlayerBlastBNB ChainBobBotanixCantonCeloDogeOSEthereumGiwaGnosis ChainGravityHashKey ChainHederaHyperEVMInjectiveInkJovayLensLineaMantleMegaETHMetisMonadopBNBOPPerennialPharosPlasmaPolygonKatanaRobinhood ChainRoninScrollSei NetworkSeismicShibariumSolanaSoneiumSonicStableStellarTaikoUnichainWorld ChainX LayerZKsync+52 Data Streams Added support to Data Streams New Data Streams available on all supported networks: APYUSD / APXUSD ARM / USD ARM / USD ARM / USD CXMT / CNY COPPER / USDT ETHFI / USD GRASS / USD SMB / WYLDS MRVL / USD MRVL / USD MRVL / USD 2454.TW / TWD NZD / USD POPCAT / USD QCOM / USD QCOM / USD QCOM / USD 2382.TW / TWD SPY / USDT 2330.TW / TWD 3037.TW / TWD Release Aug 27, 2026 CRE CRE CLI v1.31.0 — Improved Solana Workflow Stability CRE CLI version 1.31.0 is now available. This release includes reliability improvements for Solana workflows in CRE.Update your CLI by running cre update when prompted, or follow the CLI Installation guide for fresh installations.See all changes on GitHub Release Aug 25, 2026 Base Data Feeds SVR enabled by default on Base Starting Aug 26, 2026, Chainlink Smart Value Recapture (SVR) will be enabled by default for BTC, ETH, LTC, DOGE, XRP, SOL and ADA Data Feeds on Base. We expect there to be zero service disruption during the switch and no action is needed.Protocols can opt out at any time by reading from the \"Standard\" proxy address that complements every SVR proxy. See Chainlink SVR Feeds Documentation for details. Release Aug 24, 2026 Nodes Chainlink Node v2.61.0 Chainlink Node v2.61.0 is now available. See the Release Notes for details. Integration Aug 21, 2026 EthereumSonicBNB ChainArbitrumBase+1 Data Feeds Feeds scheduled for deprecation The following Data Feeds are scheduled for deprecation. See Feeds Scheduled For Deprecation for shutdown dates and the latest status: C3M / EUR Ethereum MAVIA / USD Ethereum CSPX / USD Ethereum IB01 / USD Ethereum IBTA / USD Ethereum LBTC / BTC Sonic PumpBTC / BTC Ethereum USR / USD Ethereum ZAR / USD BNB Chain ZAR / USD Arbitrum ZAR / USD Sonic WMTx / USD Base Integration Aug 21, 2026 0GADI NetworkApechainAptosArbitrumArcAvalancheBaseBerachainBitlayerBlastBNB ChainBobBotanixCantonCeloDogeOSEthereumGiwaGnosis ChainGravityHashKey ChainHederaHyperEVMInjectiveInkJovayLensLineaMantleMegaETHMetisMonadopBNBOPPerennialPharosPlasmaPolygonKatanaRobinhood ChainRoninScrollSei NetworkSeismicShibariumSolanaSoneiumSonicStableStellarTaikoUnichainWorld ChainX LayerZKsync+52 Data Streams Added support to Data Streams New Data Streams available on all supported networks: 1211.HK / HKD JR-STRCUSX / USX 2513.HK / HKD 0100.HK / HKD 9992.HK / HKD 0981.HK / HKD SR-STRCUSX / USX SUSDAI / USDAI 0700.HK / HKD 688836.CN / CNY 1810.HK / HKD Integration Aug 21, 2026 Arbitrum Data Streams Streams scheduled for deprecation The following Data Streams are scheduled for deprecation. See Deprecating Data Streams for shutdown dates and the latest status: AI16Z / USD AI16Z / USD USD / ARS ALL / USDT ALL / USDT BTCDOM / USDT BTCDOM / USDT BNB / USDT BNB / USDT BTC / USDT BTC / USDT BTR / USD BTR / USD CHIP / USD CHIP / USD CUSDO / USD CUSDO / USD ETH / USDT ETH / USDT HYPE / USDT HYPE / USDT QQQ / USDT QQQ / USDT KAIO / USD KAIO / USD M / USD M / USD FDXS / EUR FDXS / EUR FSXE / EUR FSXE / EUR FSMS / EUR FSMS / EUR MON / USDT MON / USDT NEX / USD NEX / USD OPG / USD OPG / USD XPD / USDT XPD / USDT XPT / USDT XPT / USDT USR / USD USR / USD ROLYPOLYx / USD ROLYPOLYx / USD SPY / USDT SPY / USDT SOL / USDT SOL / USDT IP / USD IP / USD USD / AED USSD / USD USSD / USD USDH / USD USDH / USD XRP / USDT XRP / USDT Integration Aug 21, 2026 Robinhood ChainKatana Data Feeds Added support to Data Feeds New Data Feeds available: CBBTC / USD Robinhood Chain XRP / USD Katana Release Aug 17, 2026 Nodes Chainlink Node v2.60.0 Chainlink Node v2.60.0 is now available. See the Release Notes for details. Integration Aug 16, 2026 0GADI NetworkApechainAptosArbitrumArcAvalancheBaseBerachainBitlayerBlastBNB ChainBobBotanixCantonCeloDogeOSEthereumGiwaGnosis ChainGravityHashKey ChainHederaHyperEVMInjectiveInkJovayLensLineaMantleMegaETHMetisMonadopBNBOPPerennialPharosPlasmaPolygonKatanaRobinhood ChainRoninScrollSei NetworkSeismicShibariumSolanaSoneiumSonicStableStellarTaikoUnichainWorld ChainX LayerZKsync+52 Data Streams Added support to Data Streams New Data Streams available on all supported networks: QQQ / USDT TBLL / USD TBLL / USD TBLL / USD SPY / USDT Integration Aug 16, 2026 BaseEthereumMantleOPArbitrumHedera+2 Data Feeds Added support to Data Feeds New Data Feeds available: ARS / USD Base CBBTC / USD Ethereum XAU / USD Mantle PAXG / USD OP SPCX / USD Arbitrum WBTC / USD Hedera weETH / USD OP Release Aug 14, 2026 CRE TS SDK v1.19.1 — Dependency Updates TypeScript SDK version 1.19.1 is a maintenance release that updates the viem dependency to the latest version.See all changes on GitHub Integration Aug 14, 2026 CCIP Cross-chain token (CCT) standard: Added support for new tokens Newly supported tokens: RIPE, GREEN Ripe DAO Governance Token Green USD Stablecoin Integration Aug 13, 2026 CCIP Cross-chain token (CCT) standard: Added support for new tokens Newly supported tokens: USDUC unstable coin Release Aug 13, 2026 CRE Go SDK v1.19.0 — New Testnet Chain Constants Go SDK version 1.19.0 adds chain constants for the newly supported testnets. New evm.MonadTestnet, evm.TRexTestnet, evm.RobinhoodTestnet, and evm.StableTestnet constants are available for use in your workflow code.See all changes on GitHub Release Aug 13, 2026 CRE TS SDK v1.19.0 — New Testnet Chain Constants TypeScript SDK version 1.19.0 adds chain constants for the newly supported testnets. New MonadTestnet, TRexTestnet, RobinhoodTestnet, and StableTestnet constants are available for use in your workflow code.See all changes on GitHub Release Aug 13, 2026 CRE CRE CLI v1.30.0 — New Testnet Support for Simulation CRE CLI version 1.30.0 is now available. cre workflow simulate now supports Monad, T-REX, Robinhood, Stable, and Tempo testnets for local simulation.Update your CLI by running cre update when prompted, or follow the CLI Installation guide for fresh installations.See all changes on GitHub Integration Aug 12, 2026 CCIP Cross-chain token (CCT) standard: Added support for new tokens Newly supported tokens: TAO TAO Release Aug 10, 2026 Nodes Chainlink Node v2.59.0 Chainlink Node v2.59.0 is now available. See the Release Notes for details. Integration Aug 10, 2026 CCIP Cross-chain token (CCT) standard: Added support for new tokens Newly supported tokens: NIL, FLOCK Nillion FLock.io Integration Aug 9, 2026 0GADI NetworkApechainAptosArbitrumArcAvalancheBaseBerachainBitlayerBlastBNB ChainBobBotanixCantonCeloDogeOSEthereumGiwaGnosis ChainGravityHashKey ChainHederaHyperEVMInjectiveInkJovayLensLineaMantleMegaETHMetisMonadopBNBOPPerennialPharosPlasmaPolygonKatanaRobinhood ChainRoninScrollSei NetworkSeismicShibariumSolanaSoneiumSonicStableStellarTaikoUnichainWorld ChainX LayerZKsync+52 Data Streams Added support to Data Streams New Data Streams available on all supported networks: ADBE / USD ADBE / USD ADBE / USD AKT / USD BNB / USD BTC / USD BX / USD BX / USD BX / USD LINK / USD CSCO / USD CSCO / USD CSCO / USD COST / USD COST / USD COST / USD DOGE / USD LLY / USD LLY / USD LLY / USD ETH / USD HD / USD HD / USD HD / USD HYPE / USD NFLX / USD NFLX / USD NFLX / USD NOW / USD NOW / USD NOW / USD SOL / USD solmFONE SOLMHYPER SYZUSD / YZUSD TOPENAI TRX / USD V / USD V / USD V / USD WEN / USD WEN / USD WEN / USD XRP / USD ZEC / USD Integration Aug 9, 2026 ArbitrumBaseMonadBNB ChainMantleMegaETH+2 Data Feeds Added support to Data Feeds New Data Feeds available: ADI / USD Arbitrum AERO / USD Arbitrum GOOGL / USD Base AMZN / USD Base AAPL / USD Base ASTER / USD Arbitrum savUSD / avUSD Base CRCL / USD Base COIN / USD Base dreUSDs / dreUSD Monad XGLD / XAUT BNB Chain INTC / USD Base LIT / USD Arbitrum METH / ETH Mantle SYRUP / USD Arbitrum META / USD Base MSFT / USD Base MSTR / USD Base XMR / USD Arbitrum MORPHO / USD Arbitrum NVDA / USD Base SNDK / USD Base SPCX / USD Base JRUSDAT / USDAT Monad JRUSDAT / USDAT MegaETH SRPRIME / USDC Monad SRPRIME / USDC MegaETH SRUSDAT / USDAT Monad SRUSDAT / USDAT MegaETH TSLA / USD Base Release Aug 7, 2026 CRE CRE CLI v1.29.0 — Monad Mainnet Simulation and Confidential Workflows CRE CLI version 1.29.0 is now available. Monad mainnet is now supported for local simulation via cre workflow simulate. Confidential Workflows let you designate parts of your workflow to run inside a secure enclave (TEE), keeping secrets, sensitive inputs, and computation confidential from node operators during execution.Update your CLI by running cre update when prompted, or follow the CLI Installation guide for fresh installations.See all changes on GitHub Release Aug 7, 2026 CRE CRE CLI v1.29.0 — Monad Mainnet Support and Confidential Workflows CRE CLI version 1.29.0 is now available. Monad mainnet is now supported for local simulation via cre workflow simulate and for production onchain writes. Confidential Workflows let you designate parts of your workflow to run inside a secure enclave (TEE), keeping secrets, sensitive inputs, and computation confidential from node operators during execution.Update your CLI by running cre update when prompted, or follow the CLI Installation guide for fresh installations.See all changes on GitHub Release Aug 6, 2026 CRE TS SDK v1.18.0 — Confidential Workflows TypeScript SDK version 1.18.0 adds Confidential Workflows support. A new TeeRuntime and handlerInTee let you run workflow logic inside a secure enclave, keeping secrets, sensitive inputs, and computation confidential from node operators during execution.See all changes on GitHub Release Aug 6, 2026 CRE Go SDK v1.18.0 — Confidential Workflows Go SDK version 1.18.0 adds Confidential Workflows support. A new TEE runtime (cre.TeeRuntime) and cre.HandlerInTee let you run workflow logic inside a secure enclave, keeping secrets, sensitive inputs, and computation confidential from node operators during execution.See all changes on GitHub Release Aug 3, 2026 CRE Go SDK v1.16.0 — Batch Secret Fetching Go SDK version 1.16.0 adds batch secret fetching. runtime.GetSecrets() fetches multiple secrets in a single call, avoiding the sequential-fetch requirement of the single-secret API.See all changes on GitHub Release Aug 3, 2026 Nodes Chainlink Node v2.58.0 Chainlink Node v2.58.0 is now available. See the Release Notes for details. Release Jul 30, 2026 CRE CRE CLI v1.28.0 — Registry Selection and Aggregator Simulation CRE CLI version 1.28.0 is now available. cre init now lets you select the deployment registry during project setup, and the local simulator supports the new aggregator capability.Update your CLI by running cre update when prompted, or follow the CLI Installation guide for fresh installations.See all changes on GitHub Release Jul 27, 2026 Nodes Chainlink Node v2.57.0 Chainlink Node v2.57.0 is now available. See the Release Notes for details. Integration Jul 26, 2026 Monad SmartData Added support to SmartData New SmartData Feeds available: USPC NAV Monad Integration Jul 26, 2026 TempoRobinhood ChainBaseMonad Data Feeds Added support to Data Feeds New Data Feeds available: BRL / USD Tempo CAD / USD Tempo CBBTC / USD Tempo RHDELL / USD Robinhood Chain SUSDE / USD Tempo EUR / USD Tempo XGLD / XAUT Base PRIME / USD Tempo MUSD / USD Monad SYRUPUSDC / USD Tempo USDT / USD Tempo USDC / USD Tempo Integration Jul 26, 2026 Arbitrum Data Streams Streams scheduled for deprecation The following Data Streams are scheduled for deprecation on July 24th, 2026. See Deprecating Data Streams for shutdown dates and the latest status: FLP.1 / SOL FLP.1 / USD Integration Jul 26, 2026 0GADI NetworkApechainAptosArbitrumArcAvalancheBaseBerachainBitlayerBlastBNB ChainBobBotanixCantonCeloDogeOSEthereumGiwaGnosis ChainGravityHashKey ChainHederaHyperEVMInjectiveInkJovayLensLineaMantleMegaETHMetisMonadopBNBOPPerennialPharosPlasmaPolygonKatanaRobinhood ChainRoninScrollSei NetworkSeismicShibariumSolanaSoneiumSonicStableStellarTaikoUnichainWorld ChainX LayerZKsync+52 Data Streams Added support to Data Streams New Data Streams available on all supported networks: APC / USD SKHY / USDT Integration Jul 23, 2026 CCIP Cross-chain token (CCT) standard: Added support for new tokens Newly supported tokens: yzPrime, BWLK, TRCR Yuzu Prime Boardwalk Tracer Release Jul 23, 2026 CRE CRE CLI v1.27.0 — Solana LogTrigger Simulation CRE CLI version 1.27.0 is now available. cre workflow simulate now supports Solana LogTrigger events for local simulation of Solana workflows triggered by on-chain logs.Update your CLI by running cre update when prompted, or follow the CLI Installation guide for fresh installations.See all changes on GitHub Integration Jul 22, 2026 Tempo Data Feeds Data Feeds Expands to Tempo Mainnet Chainlink Data Feeds is available on Tempo Mainnet. View the available price feed information on the Price Feed Addresses page. Release Jul 20, 2026 Nodes Chainlink Node v2.56.0 Chainlink Node v2.56.0 is now available. See the Release Notes for details. Integration Jul 20, 2026 CCIP Cross-chain token (CCT) standard: Added support for new tokens Newly supported tokens: MNT Mantle Release Jul 16, 2026 CRE CRE CLI v1.26.0 — Deployment Access and Error Message Fixes CRE CLI version 1.26.0 is now available. Deployment access request messaging is clearer. Simulation error messages now show the correct workflow directory path.Update your CLI by running cre update when prompted, or follow the CLI Installation guide for fresh installations.See all changes on GitHub Integration Jul 14, 2026 Canton CCIP CCIP on Canton This release continues CCIP's expansion to non-EVMs by adding support for the Canton blockchain. Canton is now interoperable with Ethereum using the latest CCIP architecture. More lanes to and from Canton will be added in the future. No change to any existing EVM Router addresses. Canton CCIP details can be seen on the CCIP Directory. Canton Mainnet Canton Testnet Release Jul 14, 2026 Nodes Chainlink Node v2.55.0 Chainlink Node v2.55.0 is now available. See the Release Notes for details. Release Jul 14, 2026 CRE CRE CLI v1.25.0 — Solana Mainnet Simulation and Discovery Hints CRE CLI version 1.25.0 is now available. Solana mainnet mock forwarder support for cre workflow simulate enables local simulation of Solana write workflows on mainnet. Cross-command execution discovery hints help surface available workflows. Improved Linux asset suffix handling.Update your CLI by running cre update when prompted, or follow the CLI Installation guide for fresh installations.See all changes on GitHub Integration Jul 13, 2026 ArbitrumEthereumLineaMantle Data Feeds Added support to Data Feeds New Data Feeds available: AR / USD Arbitrum EUR / USD Ethereum SOFR Ethereum VVV / USD Arbitrum wrsETH / rsETH Linea wrsETH / ETH Mantle Integration Jul 13, 2026 EthereumBaseMonadBNB Chain SmartData Added support to SmartData New SmartData Feeds available: rwaUSD NAV Ethereum rwaUSD NAV Base rwaUSDi PoR Monad rwaUSDi NAV Monad EURSAFO NAV Ethereum SAFO NAV Ethereum U PoR BNB Chain Integration Jul 13, 2026 BasePolygonMantleOPSolanaArbitrumZKsyncSonicHyperEVMPlasmaEthereumScrollTRONGnosis Chain+10 Data Feeds Feeds scheduled for deprecation The following Data Feeds are scheduled for deprecation on July 22nd, 2026. See Feeds Scheduled For Deprecation for shutdown dates and the latest status: EDGE / USD Base FRAX / USD Polygon FBTC / USD Mantle ONE / USD OP JUPUSD / USD Solana FRAX.OLD / USD Polygon STMATIC / USD Polygon MIM / USD Arbitrum MELANIA / USD ZKsync ORDER / USD Arbitrum OS / S Sonic USR / USD HyperEVM RPL / USD Arbitrum splUSD / plUSD Plasma stBTC / BTC Ethereum stBTC / BTC Arbitrum stBTC / BTC Scroll TUSD / USD TRON USOL / USD HyperEVM USOL / USD HyperEVM ZIL / USD Gnosis Chain ZIL / USD OP Integration Jul 13, 2026 0GADI NetworkApechainAptosArbitrumArcAvalancheBaseBerachainBitlayerBlastBNB ChainBobBotanixCantonCeloDogeOSEthereumGiwaGnosis ChainGravityHashKey ChainHederaHyperEVMInjectiveInkJovayLensLineaMantleMegaETHMetisMonadopBNBOPPerennialPharosPlasmaPolygonKatanaRobinhood ChainRoninScrollSei NetworkSeismicShibariumSolanaSoneiumSonicStableStellarTaikoUnichainWorld ChainX LayerZKsync+52 Data Streams Added support to Data Streams New Data Streams available on all supported networks: deJTRSY DEJAAA oTFY / USD STSLX / SLX USD / KRW Integration Jul 10, 2026 CCIP Cross-chain token (CCT) standard: Added support for new tokens Newly supported tokens: enzoBTC Lorenzo Wrapped Bitcoin Release Jul 9, 2026 CRE CRE CLI v1.24.0 — Execution Observability and Solana Write CRE CLI version 1.24.0 is now available. New cre execution commands (list, status, events, logs) let you inspect workflow runs from the terminal. cre workflow get now shows deployment health and the most recent execution. Solana Write is supported: workflows can submit DON-signed reports to Solana programs on Mainnet and Devnet via the Keystone Forwarder, with CLI tooling for CRE_SOLANA_PRIVATE_KEY, cre generate-bindings solana, and local write simulation.Update your CLI by running cre update when prompted, or follow the CLI Installation guide for fresh installations.See all changes on GitHub Release Jul 6, 2026 Nodes Chainlink Node v2.54.0 Chainlink Node v2.54.0 is now available. See the Release Notes for details. Integration Jul 6, 2026 CCIP Cross-chain token (CCT) standard: Added support for new tokens Newly supported tokens: syzUSD Staked Yuzu USD Integration Jul 5, 2026 0GADI NetworkApechainAptosArbitrumArcAvalancheBaseBerachainBitlayerBlastBNB ChainBobBotanixCantonCeloDogeOSEthereumGiwaGnosis ChainGravityHashKey ChainHederaHyperEVMInjectiveInkJovayLensLineaMantleMegaETHMetisMonadopBNBOPPerennialPharosPlasmaPolygonKatanaRobinhood ChainRoninScrollSei NetworkSeismicShibariumSolanaSoneiumSonicStableStellarTaikoUnichainWorld ChainX LayerZKsync+52 Data Streams Added support to Data Streams New Data Streams available on all supported networks: REUSD / USD Integration Jul 3, 2026 CCIP Cross-chain token (CCT) standard: Added support for new tokens Newly supported tokens: syrupUSDG syrupUSDG Integration Jul 2, 2026 Robinhood ChainEthereum Data Feeds Added support to Data Feeds New Data Feeds available: AMD / USD Robinhood Chain BABA / USD Robinhood Chain GOOGL / USD Robinhood Chain AMZN / USD Robinhood Chain AAPL / USD Robinhood Chain ARS / USD Ethereum ASML / USD Robinhood Chain BTC.B / USD Robinhood Chain BTC / USD Robinhood Chain LINK / USD Robinhood Chain CRCL / USD Robinhood Chain CLSK / USD Robinhood Chain COIN / USD Robinhood Chain CRWV / USD Robinhood Chain ENA / USD Robinhood Chain USDE / USD Robinhood Chain ETH / USD Robinhood Chain EURC / USD Robinhood Chain GME / USD Robinhood Chain USDG / USD Robinhood Chain INTC / USD Robinhood Chain QQQ / USD Robinhood Chain IONQ / USD Robinhood Chain EWY / USD Robinhood Chain SLV / USD Robinhood Chain LBTC / USD Robinhood Chain META / USD Robinhood Chain MU / USD Robinhood Chain MSFT / USD Robinhood Chain MSTR / USD Robinhood Chain NBIS / USD Robinhood Chain NVDA / USD Robinhood Chain ORCL / USD Robinhood Chain PLTR / USD Robinhood Chain RGTI / USD Robinhood Chain RKLB / USD Robinhood Chain SNDK / USD Robinhood Chain USDS / USD Robinhood Chain SPCX / USD Robinhood Chain SPY / USD Robinhood Chain SYRUPUSDC / USD Robinhood Chain SYRUPUSDG / USD Robinhood Chain SYRUPUSDT / USD Robinhood Chain TSM / USD Robinhood Chain TSLA / USD Robinhood Chain USDT / USD Robinhood Chain USO / USD Robinhood Chain USDC / USD Robinhood Chain WBTC / USD Robinhood Chain WEETH / USD Robinhood Chain weETH / eETH Robinhood Chain WSTETH / USD Robinhood Chain wstETH / stETH Robinhood Chain Release Jul 2, 2026 CRE CRE CLI v1.23.0 — Simulator Rate Limits CRE CLI version 1.23.0 is now available. The local simulator now enforces rate limits during workflow execution, aligning simulation behavior more closely with production. When a rate limit is reached the workflow is not terminated — execution continues within the allowed limits.Update your CLI by running cre update when prompted, or follow the CLI Installation guide for fresh installations.See all changes on GitHub Integration Jul 2, 2026 Botanix Data Feeds Feeds scheduled for deprecation The following Data Feeds are scheduled for deprecation on July 7th, 2026. See Feeds Scheduled For Deprecation for shutdown dates and the latest status: AUSD / USD Botanix BTC / USD Botanix LINK / USD Botanix USDC / USD Botanix ETH / USD Botanix gmSTBTC / USD Botanix gmSTBTC / USD Botanix rovBTC / BTC Botanix stBTC / BTC Botanix sUSDa / USDa Botanix USDT / USD Botanix USD1 / USD Botanix yPUSD / PUSD Botanix Integration Jul 2, 2026 Avalanche SmartData Added support to SmartData New SmartData Feeds available: BTC.B PoR Avalanche Integration Jul 2, 2026 0GADI NetworkApechainAptosArbitrumArcAvalancheBaseBerachainBitlayerBlastBNB ChainBobBotanixCantonCeloDogeOSEthereumGiwaGnosis ChainGravityHashKey ChainHederaHyperEVMInjectiveInkJovayLensLineaMantleMegaETHMetisMonadopBNBOPPerennialPharosPlasmaPolygonKatanaRobinhood ChainRoninScrollSei NetworkSeismicShibariumSolanaSoneiumSonicStableStellarTaikoUnichainWorld ChainX LayerZKsync+52 Data Streams Added support to Data Streams New Data Streams available on all supported networks: CBBTC / POR AUTO / WYLDS PRIME / WYLDS SMB / WYLDS HYPE / USDT SGOV / USD SGOV / USD SGOV / USD XBTC / POR SPCX / USD SPCX / USD SPCX / USD USAR / USD USAR / USD USAR / USD Integration Jul 1, 2026 Robinhood Chain Data Feeds Data Feeds Expands to Robinhood Chain Mainnet Chainlink Data Feeds is available on Robinhood Chain Mainnet. View the available price feed information on the Price Feed Addresses page. Integration Jul 1, 2026 CCIP CCIP Expands to Robinhood Chain Mainnet Chainlink CCIP expands support to new networks: Robinhood Chain Mainnet Integration Jul 1, 2026 Robinhood Chain Data Streams Data Streams Expands to Robinhood Chain Mainnet Chainlink Data Streams is available for Robinhood Chain Mainnet. The verifier proxy addresses and stream IDs are available on the Stream Addresses page. Integration Jun 30, 2026 ArbitrumBNB ChainMantle CCIP Progressive rollout for new CCIP version A new version of CCIP is being progressively deployed across the following lanes. No disruption to existing integrations or protocol downtime is anticipated during the upgrade process. For more information, please reach out to your Chainlink Labs point of contact or visit the Chainlink CCIP Contact form. Arbitrum <> BNB Chain BNB Chain <> Mantle Release Jun 30, 2026 Nodes Chainlink Node v2.53.0 Chainlink Node v2.53.0 is now available. See the Release Notes for details. Integration Jun 28, 2026 0GADI NetworkApechainAptosArbitrumArcAvalancheBaseBerachainBitlayerBlastBNB ChainBobBotanixCantonCeloDogeOSEthereumGiwaGnosis ChainGravityHashKey ChainHederaHyperEVMInjectiveInkJovayLensLineaMantleMegaETHMetisMonadopBNBOPPerennialPharosPlasmaPolygonKatanaRobinhood ChainRoninScrollSei NetworkSeismicShibariumSolanaSoneiumSonicStableStellarTaikoUnichainWorld ChainX LayerZKsync+52 Data Streams Added support to Data Streams New Data Streams available on all supported networks: 005380.KR / KRW 035720.KR / KRW 285A.JP / JPY 373220.KR / KRW 6871.JP / JPY 035420.KR / KRW 005930.KR / KRW 000660.KR / KRW 9984.JP / JPY Integration Jun 28, 2026 OPBNB ChainMonadMantleEthereum+1 Data Feeds Added support to Data Feeds New Data Feeds available: GOOGL / USD OP AMZN / USD OP AAPL / USD OP APXUSD / USD BNB Chain SUSDE / USDE Monad EUR / USD Mantle HKD / USD Mantle QQQ / USD OP JPY / USD Mantle META / USD OP MSFT / USD OP MSTR / USD OP NVDA / USD OP SGD / USD Mantle SPCX / USD Ethereum SPY / USD OP SUSDAI / USDAI Ethereum CHF / USD Mantle syrupUSDC / USDC Monad TSLA / USD OP CNY / USD Mantle Integration Jun 28, 2026 Ethereum SmartData Added support to SmartData New SmartData Feeds available: mGlobal NAV Ethereum Integration Jun 26, 2026 CCIP Cross-chain token (CCT) standard: Added support for new tokens Newly supported tokens: ON Orochi Network Token Integration Jun 26, 2026 ArbitrumEthereumPlasmaPlume CCIP Progressive rollout for new CCIP version A new version of CCIP is being progressively deployed across the following lanes. No disruption to existing integrations or protocol downtime is anticipated during the upgrade process. For more information, please reach out to your Chainlink Labs point of contact or visit the Chainlink CCIP Contact form. Arbitrum <> Plasma Ethereum <> Plume Release Jun 25, 2026 CRE CRE CLI v1.22.0 — Secrets Security Hardening CRE CLI version 1.22.0 is now available. The browser OAuth secrets flow is hardened: gateway requests are now forced to HTTPS and OCR response payload signatures are validated before consuming secrets responses.Update your CLI by running cre update when prompted, or follow the CLI Installation guide for fresh installations.See all changes on GitHub Deprecation Jun 24, 2026 Data Streams Data Streams free tier winding down Free tiers for Data Streams are winding down, with access terminating on September 1st, 2026.During this transition, rate limits may become stricter to avoid system congestion. We are encouraging the heavy users of the service to switch to a paid subscription as soon as possible to avoid disruption. Visit the Self Service center to get started. Release Jun 22, 2026 Nodes Chainlink Node v2.52.0 Chainlink Node v2.52.0 is now available. See the Release Notes for details. Integration Jun 22, 2026 0GADI NetworkApechainAptosArbitrumArcAvalancheBaseBerachainBitlayerBlastBNB ChainBobBotanixCantonCeloDogeOSEthereumGiwaGnosis ChainGravityHashKey ChainHederaHyperEVMInjectiveInkJovayLensLineaMantleMegaETHMetisMonadopBNBOPPerennialPharosPlasmaPolygonKatanaRobinhood ChainRoninScrollSei NetworkSeismicShibariumSolanaSoneiumSonicStableStellarTaikoUnichainWorld ChainX LayerZKsync+52 Data Streams Added support to Data Streams APAC Equities Data Streams are now available on all supported networks. Integration Jun 21, 2026 0GADI NetworkApechainAptosArbitrumArcAvalancheBaseBerachainBitlayerBlastBNB ChainBobBotanixCantonCeloDogeOSEthereumGiwaGnosis ChainGravityHashKey ChainHederaHyperEVMInjectiveInkJovayLensLineaMantleMegaETHMetisMonadopBNBOPPerennialPharosPlasmaPolygonKatanaRobinhood ChainRoninScrollSei NetworkSeismicShibariumSolanaSoneiumSonicStableStellarTaikoUnichainWorld ChainX LayerZKsync+52 Data Streams Added support to Data Streams New Data Streams available on all supported networks: APXUSD / USD BILL / USD SPCX / USD Integration Jun 19, 2026 ArbitrumAvalancheBNB ChainPlasma CCIP Progressive rollout for new CCIP version A new version of CCIP is being progressively deployed across the following lanes. No disruption to existing integrations or protocol downtime is anticipated during the upgrade process. For more information, please reach out to your Chainlink Labs point of contact or visit the Chainlink CCIP Contact form. 0G <> Arbitrum 0G <> BNB Chain Arbitrum <> Ink Avalanche <> Ink Avalanche <> Mantle Avalanche <> Plasma Ink <> Mantle Release Jun 18, 2026 CRE CRE CLI v1.21.0 — MSIG Mode Guard CRE CLI version 1.21.0 is now available. Using --unsigned or --changeset with --secrets-auth=browser or a private registry now produces a clear upfront error instead of a confusing failure mid-operation.Update your CLI by running cre update when prompted, or follow the CLI Installation guide for fresh installations.See all changes on GitHub Integration Jun 17, 2026 CCIP Cross-chain token (CCT) standard: Added support for new tokens Newly supported tokens: reUSD Re Protocol Deposit Token Release Jun 15, 2026 Nodes Chainlink Node v2.51.0 Chainlink Node v2.51.0 is now available. See the Release Notes for details. Integration Jun 14, 2026 Arbitrum Data Streams Streams scheduled for deprecation The following Data Streams are scheduled for deprecation. See Deprecating Data Streams for shutdown dates and the latest status: ASTER / USD EUR / USD EUR / USD Integration Jun 14, 2026 MegaETHEthereum Data Feeds Added support to Data Feeds New Data Feeds available: SAVUSD / AVUSD MegaETH CAPUSD / USD MegaETH MXN / USD Ethereum stBRL / tBRL Ethereum stMXN / tMXN Ethereum Integration Jun 14, 2026 Ethereum SmartData Added support to SmartData New SmartData Feeds available: mGlobal NAV Ethereum Integration Jun 14, 2026 0GApechainAptosArbitrumArcAvalancheBaseBerachainBitlayerBlastBNB ChainBobBotanixCeloDogeOSEthereumGiwaGnosis ChainGravityHashKey ChainHederaHyperliquidInjectiveInkJovayLensLineaMantleMetisMonadopBNBOPPolygonPerennialPharosPlasmaRoninRobinhood ChainScrollShibariumSei NetworkSeismicSoneiumSonicSolanaStableX LayerTaikoUnichainWorld ChainZKsync+47 Data Streams Added support to Data Streams New Data Streams available on all supported networks: ADS / EUR AIR / EUR GOOGLx / POR AMPL / USD LYSX / EUR 1NBA / EUR AAPLx / POR USD / ARS AUD / USD BRBTC / USD BINAI / USD ALL / USDT BTCDOM / USDT BNB / USDT BTC / USDT BRL / USDT USD / BRL UKOIL / USD xyz:BRENTOIL / USDC BZ / USDT BTCBIN / USD USD / CAD USD / CNH CHIP / USD CRCLx / POR CL / USDC COINx / POR XCU / USD CL / USDT USD / CZK USD / DKK DB1 / EUR DRG / USD ENA / USDC ENI / EUR ETH / USDT ETH / USDC EUR / USD GIGGLE / USD XAU / USDT XAG / USDT USD / HKD USD / UAH HYPE / USDC HYPE / USDT USD / INR IES / EUR QQQ / USDT EUN5 / EUR IS3N / EUR SXR8 / EUR USD / ILS KAI18 LUCKYWALK / USD LULU / USD MOH / EUR METAx / POR USD / MXN FDXS / EUR FSXE / EUR FSMS / EUR MSTRx / POR MILLI / USD MON / USDT MYX / USD NG / USD NG / USDT USD / NOK NVDAx / POR WTI / USD ONETOKEN / USD OPG / USD XPD / USD XPD / USDT XPT / USD XPT / USDT USD / PLN GBP / USD PUNCH / USD QQQx / POR QUQ / USD USD / ZAR ROLYPOLYx / USD SPY / USDT SPYx / POR SAP / EUR SEIYAN / USD SIE / EUR SILVER / USDC USD / SGD SKYAI / USD SOL / USDC SOL / USDT SOL / USD SLX / USD xyz:SPCX / USDC SWEEP / USD USD / SEK USD / CHF TSLA / USDT TSLAx / POR USD / THB USD / TRY USD / AED UDG / POR USD / KRW XRP / USDT DBXD / EUR XYZ100 / USDC USD / JPY Release Jun 12, 2026 CRE CRE CLI v1.20.0 — Simulation Limits Match Production CRE CLI version 1.20.0 is now available. Simulation resource limits now match production — including higher execution concurrency, doubled gas limits, and larger payload caps for HTTP action and ConfidentialHTTP.Update your CLI by running cre update when prompted, or follow the CLI Installation guide for fresh installations.See all changes on GitHub Release Jun 11, 2026 CRE CRE CLI v1.19.0 — `--listen` for Simulate, Browser Secrets in Production CRE CLI version 1.19.0 is now available. A new --listen flag for cre workflow simulate keeps the simulator alive and reruns it for each incoming HTTP POST or EVM log trigger event, making it easier to iterate on trigger-driven workflows. Browser OAuth secrets auth is now enabled in production (with a fix for flows that broke when the default CRE_ETH_PRIVATE_KEY placeholder was set). Workflow output for deploy, activate, and pause now shows the resolved DON Family. The CLI also auto-resolves RPC endpoints for the capability registry chain and prompts for consent during secrets operations.Update your CLI by running cre update when prompted, or follow the CLI Installation guide for fresh installations.See all changes on GitHub Release Jun 11, 2026 CRE Go SDK v1.12.0 — Solana Mainnet Go SDK version 1.12.0 adds Solana mainnet chain selectors and workflow bindings, enabling production workflows that target Solana mainnet.See all changes on GitHub Release Jun 11, 2026 Data Feeds Upgrading Data Feeds Infrastructure on Optimism We have begun upgrading the underlying infrastructure that powers Data Feeds on Optimism to improve performance and redundancy. No negative impact is expected.If you experience any issues, please contact your Chainlink point of contact or email. Integration Jun 11, 2026 0GEthereumInkMantlePlume+1 CCIP Progressive rollout for new CCIP version A new version of CCIP is being progressively deployed across the following lanes. No disruption to existing integrations or protocol downtime is anticipated during the upgrade process. For more information, please reach out to your Chainlink Labs point of contact or visit the Chainlink CCIP Contact form. 0G <> Plume Ethereum <> Ink Ethereum <> Mantle Release Jun 10, 2026 CCIP Progressive rollout for new CCIP version A new version of CCIP is being progressively deployed across supported blockchains. No disruption to existing integrations or protocol downtime is anticipated during the upgrade process. For more information, please reach out to your Chainlink Labs point of contact or visit the Chainlink CCIP Contact form. Release Jun 8, 2026 Nodes Chainlink Node v2.50.0 Chainlink Node v2.50.0 is now available. See the Release Notes for details. Integration Jun 8, 2026 Arbitrum Data Streams Streams scheduled for deprecation The following Data Streams are scheduled for deprecation on June 17th, 2026. See Deprecating Data Streams for shutdown dates and the latest status: EDEN / USD EDEN / USD RESOLV / USD RESOLV / USD SKR / USD SKR / USD WHITEWHALE / USD WHITEWHALE / USD TURTLE / USD TURTLE / USD ZAMA / USD ZAMA / USD Integration Jun 8, 2026 MonadBNB ChainBotanixPolygonArbitrum+1 Data Feeds Feeds scheduled for deprecation The following Data Feeds are scheduled for deprecation on June 17th, 2026. See Feeds Scheduled For Deprecation for shutdown dates and the latest status: APR / USD Monad BSW / USD BNB Chain gmSTBTC / USD Botanix KNC / USD Polygon PLUME / USD Arbitrum SLP / USD Polygon STG / USD Arbitrum GMT / USD BNB Chain USDD / USD Arbitrum WOO / USD BNB Chain XAI / USD Arbitrum YFI / USD BNB Chain YFI / USD Polygon Integration Jun 8, 2026 OPMonadEthereumAvalancheBNB ChainKatanaBaseArbitrumPolygon+5 Data Feeds Added support to Data Feeds New Data Feeds available: ZRX / USD OP 1INCH / USD OP AA_FalconXUSDC / USDC Monad ALETH / USD OP AMPL / ETH Ethereum XAVA / USD Avalanche BETH / USD BNB Chain BUSD / BNB BNB Chain BUSD / USD BNB Chain CAPUSD / USD Katana CELO / USD OP CBDOGE / USD Base CBXRP / USD Base ENJ / USD OP GGAVAX / AVAX Avalanche FET / USD OP FLOKI / USD OP HOME / USD Base IDR / USD Ethereum IDR / USD Base JLP / USD Arbitrum LISUSD / USD BNB Chain MIM / USD Avalanche MIM / USD Arbitrum MIMATIC / USD Polygon MIMATIC / USD Avalanche MIMATIC / USD Arbitrum MIMATIC / USD OP RAI / ETH Ethereum slisBNB / BNB BNB Chain ETHx / ETH Ethereum STCAPUSD / CAPUSD Katana SUSD / USD OP sUSDX / USDX BNB Chain TRB / USD OP USTC / ETH Ethereum USTC / USD Avalanche THB / USD BNB Chain VAI / USD BNB Chain WEMIX / USD Arbitrum WSTETH / USD Ethereum XDC / USD Arbitrum XDC / USD Base ZEC / USD OP ZIL / USD OP Integration Jun 8, 2026 HyperEVMPlasma SmartData Added support to SmartData New SmartData Feeds available: AVLT PoR HyperEVM USDx PoR Plasma Integration Jun 8, 2026 0GApechainAptosArbitrumArcAvalancheBaseBerachainBitlayerBlastBNB ChainBobBotanixCeloDogeOSEthereumGiwaGnosis ChainGravityHashKey ChainHederaHyperliquidInjectiveInkJovayLensLineaMantleMetisMonadopBNBOPPolygonPerennialPharosPlasmaRoninRobinhood ChainScrollShibariumSei NetworkSeismicSoneiumSonicSolanaStableX LayerTaikoUnichainWorld ChainZKsync+47 Data Streams Added support to Data Streams New Data Streams available on all supported networks: EBAY / USD EBAY / USD EBAY / USD EWY / USD EWY / USD EWY / USD Release Jun 4, 2026 CRE CRE CLI v1.18.0 — Internal Improvements CRE CLI version 1.18.0 is now available. This release includes internal reliability improvements across context propagation, secret handling, and registry type management.Update your CLI by running cre update when prompted, or follow the CLI Installation guide for fresh installations.See all changes on GitHub Deprecation Jun 3, 2026 CCIP CCIP deprecated on Botanix Testnet CCIP is no longer supported on Botanix Testnet. Integration Jun 3, 2026 CCIP Cross-chain token (CCT) standard: Added support for new tokens Newly supported tokens: SAHARA, ZEST Sahara AI Zest Release Jun 2, 2026 Nodes Chainlink Node v2.49.0 Chainlink Node v2.49.0 is now available. See the Release Notes for details. Integration May 31, 2026 Ethereum Data Feeds Added support to Data Feeds New Data Feeds available: PST / USD Ethereum FLHYon / USD Ethereum STRCon / USD Ethereum Integration May 31, 2026 0GApechainAptosArbitrumArcAvalancheBaseBerachainBitlayerBlastBNB ChainBobBotanixCeloDogeOSEthereumGiwaGnosis ChainGravityHashKey ChainHederaHyperliquidInjectiveInkJovayLensLineaMantleMetisMonadopBNBOPPolygonPerennialPharosPlasmaRoninRobinhood ChainScrollShibariumSei NetworkSeismicSoneiumSonicSolanaStableX LayerTaikoUnichainWorld ChainZKsync+47 Data Streams Added support to Data Streams New Data Streams available on all supported networks: DELL / USD DELL / USD DELL / USD RON / USD Deprecation May 29, 2026 Nodes Deprecating support for Webhook Chainlink is deprecating support for the legacy Webhook job type.After version 2.49, this job type will no longer be supported in Chainlink node releases. Node operators and developers that continue to rely on this job type can choose to remain on the last compatible release, but should not expect ongoing development support, including maintenance, bug fixes, security patches, or compatibility with future releases.Teams using this legacy job type should begin planning to upgrade to the Chainlink Runtime Environment (CRE) as an alternative. Integration May 29, 2026 CCIP Cross-chain token (CCT) standard: Added support for new tokens Newly supported tokens: PGOLD, VIRTUAL Pleasing Gold Virtual Protocol Release May 28, 2026 Nodes Chainlink Node v2.48.0 Chainlink Node v2.48.0 is now available. See the Release Notes for details. Release May 28, 2026 CRE CRE CLI v1.17.0 — Bug Fixes and Reliability CRE CLI version 1.17.0 is now available. This release includes bug fixes and reliability improvements for platform clients, secrets operations, and workflow deploy and delete.Update your CLI by running cre update when prompted, or follow the CLI Installation guide for fresh installations.See all changes on GitHub Integration May 24, 2026 Polygon zkEVMRoninBNB ChainArbitrumPolygonHyperEVM+2 Data Feeds Feeds scheduled for deprecation The following Data Feeds are scheduled for deprecation. See Feeds Scheduled For Deprecation for shutdown dates and the latest status: AAVE / USD Polygon zkEVM AXS / USD Ronin BTC / USD Polygon zkEVM BTC / USD Ronin LINK / USD Polygon zkEVM LINK / ETH Polygon zkEVM LINK / RON Ronin LINK / USD Ronin USDC / USD Polygon zkEVM USDC / USD Ronin COMP / USD Ronin DAI / BNB BNB Chain DAI / USD Arbitrum DAI / USD Polygon zkEVM ETH / USD Polygon zkEVM ETH / USD Ronin PIXEL / USD Ronin POL / USD Polygon zkEVM rETH / ETH Polygon zkEVM RON / USD Ronin SXP / USD BNB Chain USDT / USD Polygon zkEVM USDT / USD Ronin TUSD / USD Polygon TUSD / USD Arbitrum USDH / USD HyperEVM USDH / USD HyperEVM wstETH / stETH Polygon zkEVM Integration May 24, 2026 AvalancheEthereumBaseBNB ChainMonad+1 Data Feeds Added support to Data Feeds New Data Feeds available: XCU / USD Avalanche FLHYon / USD Ethereum FLHYon / USD Ethereum JITOSOL / USD Base MXN / USD Base PRIME / PRIME Ethereum SOLVBTC / BTC BNB Chain STRCon / USD Ethereum USDi / USD Ethereum weETH / eETH Monad wstETH / stETH Monad Integration May 24, 2026 Ethereum SmartData Added support to SmartData New SmartData Feeds available: BUIDL PoR Ethereum Integration May 24, 2026 0GApechainAptosArbitrumArcAvalancheBaseBerachainBitlayerBlastBNB ChainBobBotanixCeloDogeOSEthereumGiwaGnosis ChainGravityHashKey ChainHederaHyperliquidInjectiveInkJovayLensLineaMantleMetisMonadopBNBOPPolygonPerennialPharosPlasmaRoninRobinhood ChainScrollShibariumSei NetworkSeismicSoneiumSonicSolanaStableX LayerTaikoUnichainWorld ChainZKsync+47 Data Streams Added support to Data Streams New Data Streams available on all supported networks: ASML / USD ASML / USD ASML / USD CRVUSD / USD ABTC / BTC FLHY / USD JUPUSD / USD KAIO / USD PROS / USD SIVOUSDX / USDC Release May 22, 2026 CRE CRE CLI v1.16.0 — ADI Mainnet Support CRE CLI version 1.16.0 is now available. This release adds ADI mainnet (adi-mainnet) support for local simulation and production deployment. The release also includes bug fixes for workflow deploy checks, non-interactive cron trigger simulation, and platform API reliability.Update your CLI by running cre update when prompted, or follow the CLI Installation guide for fresh installations.See all changes on GitHub Integration May 21, 2026 CCIP Cross-chain token (CCT) standard: Added support for new tokens Newly supported tokens: PST, ZCHF, SLX PayFi Strategy Token Frankencoin Solstice Release May 21, 2026 CRE Go SDK v1.11.0 — Rhyolite Testnet Support Go SDK version 1.11.0 adds private-testnet-rhyolite EVM capabilities for the Rhyolite private testnet.See all changes on GitHub Release May 20, 2026 CRE Go SDK v1.10.0 — ADI Mainnet Support Go SDK version 1.10.0 adds ADI mainnet (adi-mainnet) EVM capabilities, enabling workflows that target ADI mainnet.See all changes on GitHub Integration May 20, 2026 CCIP Cross-chain token (CCT) standard: Added support for new tokens Newly supported tokens: USDat, sUSDat USDat Staked USDat Release May 18, 2026 Nodes Chainlink Node v2.47.0 Chainlink Node v2.47.0 is now available. See the Release Notes for details. Release May 14, 2026 CRE CRE CLI v1.15.0 — Tenant-Scoped Chains and Chain Expansion CRE CLI version 1.15.0 is now available. This release upgrades cre workflow supported-chains to show tenant-specific chains and their mock forwarder addresses (requires cre login or CRE_API_KEY), adds ADI testnet and Celo Sepolia support, and introduces a global --allow-unknown-chains flag to skip chain validation for experimental networks during simulation and deploy. cre workflow hash now auto-derives the workflow owner based on your target registry — on-chain uses CRE_ETH_PRIVATE_KEY or workflow-owner-address, off-chain uses the owner from your login session. The release also includes private registry bug fixes.Update your CLI by running cre update when prompted, or follow the CLI Installation guide for fresh installations.See all changes on GitHub Deprecation May 14, 2026 CCIP CCIP deprecated on Mint Mainnet and Fraxtal Testnet CCIP is no longer supported on Mint Mainnet and Fraxtal Testnet. Integration May 14, 2026 CCIP CCIP Expands to Neox Mainnet ","tokens":15000,"squid":"spider-08","role":"Oracle Spider","at":1791347454931,"hash":"8d16f5bd66182c47280bcd0ee7f30625f9f3114e"}
{"url":"https://research.arbitrum.io/","domain":"research.arbitrum.io","title":"Arbitrum Research - Arbitrum developers and researchers","text":"All latest topics\n\n categories\n\n tags\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 Welcome to the Arbitrum Research forum\n\n Uncategorized\n\n This site is for discussing Arbitrum development, research, and ideas for improvement. It is open to everyone but focuses on research-oriented technical discussions. The language of discussion is English. \nThis is not th…\n\n read more\n\n 0\n\n 6.9k\n\n Jan 2023\n\n TitanArb — A Live-Capable DeFi Arbitrage Engine on Arbitrum One\n\n Uncategorized\n\n tx-ordering,defi\n\n 0\n\n 118\n\n Aug 29\n\n Price Elasticity of Gas Demand on Ethereum and Arbitrum\n\n Uncategorized\n\n gas-and-fees\n\n 0\n\n 100\n\n Jun 16\n\n Timing Games: Probabilistic backrunning and spam\n\n Uncategorized\n\n 0\n\n 169\n\n Feb 27\n\n TimeBoost: Do Ahead-of-Time Auctions Work?\n\n Uncategorized\n\n 0\n\n 178\n\n Nov 2025\n\n Multi-constraint pricing\n\n Uncategorized\n\n 2\n\n 632\n\n Nov 2025\n\n Fraud Proof Protocols: BoLD, Dave, and other alternatives\n\n Uncategorized\n\n 4\n\n 650\n\n Aug 2025\n\n Submitting transaction bundles\n\n Uncategorized\n\n 14\n\n 4.8k\n\n Aug 2025\n\n FairFlow: Leveraging TimeBoost to Build a Fair and Transparent L2 MEV Economy\n\n Uncategorized\n\n tx-ordering\n\n 0\n\n 447\n\n Apr 2025\n\n TimeBoost and Backrunning: Probabilistic Strategies\n\n Uncategorized\n\n gas-and-fees,defi,sequencer,tx-ordering\n\n 0\n\n 432\n\n Mar 2025\n\n Economic Censorship Games in Fraud Proofs\n\n Uncategorized\n\n 0\n\n 242\n\n Mar 2025\n\n Adjusting call Gas Limit for Arbitrum One’s Gas Model\n\n Uncategorized\n\n gas-and-fees\n\n 1\n\n 288\n\n Dec 2024\n\n Auctioning Multiple TimeBoost Licenses\n\n Uncategorized\n\n 0\n\n 280\n\n Dec 2024\n\n MEV Capture Through Time-Advantaged Arbitrage\n\n Uncategorized\n\n 0\n\n 811\n\n Oct 2024\n\n Decentralized Timeboost Specification\n\n Uncategorized\n\n sequencer,tx-ordering\n\n 2\n\n 881\n\n Sep 2024\n\n The power of faster blocks\n\n Uncategorized\n\n 11\n\n 4.2k\n\n Sep 2024\n\n What is testnet sequencer feed url of arb?\n\n Uncategorized\n\n 0\n\n 134\n\n Sep 2024\n\n Introducing the Arbitrum DeFi Dollar Rate\n\n Uncategorized\n\n defi\n\n 0\n\n 277\n\n Aug 2024\n\n On Sybil-proof Mechanisms\n\n Uncategorized\n\n 0\n\n 233\n\n Jul 2024\n\n Arbitrum Universe Explorer: Mapping the Future of Blockchain Interoperability\n\n Uncategorized\n\n 0\n\n 382\n\n Jul 2024\n\n Access to L1 block hash on Arbitrum\n\n Uncategorized\n\n 1\n\n 553\n\n Jul 2024\n\n Proposed design for Timeboost\n\n Uncategorized\n\n 12\n\n 3.3k\n\n Jun 2024\n\n Do shared MEV auctions actually increase revenue?\n\n Uncategorized\n\n 6\n\n 1.4k\n\n Jun 2024\n\n Paper on BoLD: fast, cheap dispute resolution, making permissionless validation safe\n\n Uncategorized\n\n 0\n\n 653\n\n Apr 2024\n\n Decentralized Timeboost R&D Update\n\n Uncategorized\n\n sequencer,tx-ordering\n\n 1\n\n 2.2k\n\n Apr 2024\n\n Security and governance considerations for chain-clusters\n\n Uncategorized\n\n 4\n\n 3.7k\n\n Mar 2024\n\n EIP-4844 shard blobs and how we would use them\n\n Uncategorized\n\n 6\n\n 5.1k\n\n Mar 2024\n\n RIP-7614: Expose call stack to contracts\n\n Uncategorized\n\n nitro\n\n 1\n\n 1.1k\n\n Feb 2024\n\n How do proposers take turns to submit new state roots on L1?\n\n Uncategorized\n\n sequencer\n\n 2\n\n 1.3k\n\n Jan 2024\n\n Stylus - benchmarks and feedback\n\n Uncategorized\n\n 2\n\n 2.0k\n\n Dec 2023","tokens":785,"squid":"spider-01","role":"Chain Spider","at":1791347465071,"hash":"7dfd9723728ed126d4fb2651b657c7190c13c638"}
{"url":"https://forum.across.to/t/what-the-token-does/52/25","domain":"forum.across.to","title":"What the token does? - Tokenomics (old) - Across Protocol","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 read \n\n 4\n min\n\n Nov 2021\n\n 25 / 26\n\n Apr 2022\n\n Apr 2022\n\n Load more posts above\n\n post by fommes.eth on Nov 17, 2021\n\n post by fommes.eth on Nov 17, 2021\n\n post by Robot on Nov 17, 2021\n\n post by Sanguine on Nov 17, 2021\n\n post by jotatotal on Nov 17, 2021\n\n post by fommes.eth on Nov 17, 2021\n\n post by Robot on Nov 17, 2021\n\n post by Solace on Nov 17, 2021\n\n post by Sanguine on Nov 17, 2021\n\n post by eqing.eth on Nov 21, 2021\n\n post by Alisa on Nov 22, 2021\n\n 9 days later\n\n post by MrHeviDi on Dec 1, 2021\n\n 2 months later\n\n post by jotatotal on Jan 26, 2022\n\n post by lawpanda.eth on Jan 26, 2022\n\n 2 months later\n\n post by J.Berg on Mar 18, 2022\n\n post by heybeo on Mar 22, 2022\n\n heybeo\n\n It would be nice to use bridges on the same platform as well as to create a nice dex.\nTrading pairs, for example acx-uma, are used as fees and distributed to token holders.\nacx-x\nacx-y\nacx-z\nJust a simple idea as liquidity addition commissions are burned\n\n post by altsilversurfer.nft on Mar 26, 2022\n\n altsilversurfer.nft\n\n Tokenomics can be viewed as a function of 3 main parameters, token launch (model, vesting scheme, market cap), utility, and inflation. Utility is one of the major drivers of adoption and appreciation of value. Thus, the more utilities, the best. Governance will be the first and more obvious utility of $ACX, but we must think beyond this to achieve sustainnability. This is the ultimate goal. And this is also the common interest of all involved. People that are waiting for profits will be maximally rewarded if they be patient and contribute to protocol sustainnability. Across will be really BIG and this is not a fanboy statement. The major crosschain pipes will see in the future typical value movements that will far exceed those of the biggest centralized exchanges today.\n\n post by jeffrey on Mar 29, 2022\n\n jeffrey\n\n Token is share, it means users own the project\n\n 12 days later\n\n post by hescollazo on Apr 11, 2022\n\n hescollazo\n\n I agree with the use of the token as a payment mechanism for the protocol. The low fees will bring new users and money into the ecosystem. That it can be used in governance will incentivize use of the application and hodling of the asset. Ultimately the goal should be to give users the tools to discover new ways in which to generate positive cash flow and build wealth.\n\n 10 days later\n\n post by Ray_V on Apr 21, 2022\n\n Ray_V\n\n Would we introduce a single staking mechanism? In which we would offer our tokens as liquidity to the across protocol and earn APR either through the fees accrued by the protocol - or another more effective system? Would that be something considered?\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Initial thinking around token distribution\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 36\n\n Mar 2022\n\n Across Token Launch Proposal\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 214\n\n May 2022\n\n Across Token Launch Proposal v2\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 47\n\n Nov 2022\n\n Second ACX Drop\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 15\n\n Feb 2024\n\n Welcome to Across\n\n WELCOME 👋\n\n WELCOME 👋\n\n Nov 2022","tokens":803,"squid":"spider-09","role":"Bridge Spider","at":1791347467734,"hash":"97f35e1fd711ff75af5bccf1e089f9a4b25154f8"}
{"url":"https://akash.network/docs/developers/deployment/akt/monitor/","domain":"akash.network","title":"Network Monitor | Akash Network - Your Guide to Decentralized Cloud","text":"Network Monitor Watch network state, provider fleet health, and Oracle/BME state in real time.\nakt monitor is a hub-based monitoring tool with three dashboards. It connects directly to an RPC endpoint over WebSocket for real-time vote streaming, which keeps it useful during coordinated chain upgrades when hosted explorers are unavailable.\nNo keyring or default account is needed, just an RPC endpoint.\n\nLaunch\nTerminal window# Launch hub (defaults to the Network dashboard)akt monitor\n# Connect to a specific RPC endpointakt monitor https://rpc.akashnet.net:443\n# Launch directly into a specific dashboardakt monitor networkakt monitor providerakt monitor oracleakt monitor bme\n# Or via flagakt monitor --rpc https://rpc.akashnet.net:443\n# Skip RPC plus provider REST and gRPC TLS verificationakt monitor --insecure\n# Clear cache and start freshakt monitor --clean-cache\n\nDashboards\nNetwork\nThe default dashboard shows consensus state, validator voting, governance proposals, and governance parameters.\nSub-tabs:\n\n1 Overview - Dual progress bar and block history\n2 Validators - Per-validator signing history\n3 Governance - Recent and active proposals, deadlines, status, and vote tallies\n4 Parameters - Module-by-module governance parameters\n\nThe Governance tab includes recent completed proposals even when no vote is active. Voting-period proposals show the current tally; completed proposals show the final tally. Use j and k to scroll and r to refresh.\n\nThe Network dashboard tracks consensus progress and recent blocks. Values update in real time.\nProvider\nProvider fleet health, version distribution, and per-provider resource utilization.\nProvider REST and gRPC certificates are verified by default. Use --insecure only for a diagnostic session against endpoints you trust.\n\nThe Provider dashboard groups online providers by version and shows their available resources.\nOracle/BME\nOracle aggregated prices plus BME vault state, mint status, and ledger.\n\nThe Oracle/BME dashboard combines price health, mint controls, collateral thresholds, and recent routes.\n\nNavigation\n\nTab / Shift-Tab - Cycle between the Network, Provider, and Oracle/BME dashboards\n1 / 2 / 3 / 4 - Switch sub-tabs within the Network dashboard\nq / Ctrl-C - Save monitor cache state and quit\n\nRelated Resources\n\nContexts & Configuration - Where the default RPC endpoint comes from\nCommands Reference - Complete akt command reference\n\nEdit page on github\n Queries & Transactions Agent Skill","tokens":617,"squid":"spider-03","role":"Compute Spider","at":1791347473616,"hash":"df8d85bf9ba10e1b1e3ab17015d282af6c5e5442"}
{"url":"https://research.arbitrum.io/c/uncategorized/1","domain":"research.arbitrum.io","title":"Latest Uncategorized topics - Arbitrum Research","text":"Latest topics in Uncategorized\n\n Uncategorized\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 Arbitrum Research forum\n\n This site is for discussing Arbitrum development, research, and ideas for improvement. It is open to everyone but focuses on research-oriented technical discussions. The language of discussion is English. \nThis is not th…\n\n read more\n\n 0\n\n 6.9k\n\n Jan 2023\n\n TitanArb — A Live-Capable DeFi Arbitrage Engine on Arbitrum One\n\n tx-ordering,defi\n\n 0\n\n 118\n\n Aug 29\n\n Price Elasticity of Gas Demand on Ethereum and Arbitrum\n\n gas-and-fees\n\n 0\n\n 100\n\n Jun 16\n\n Timing Games: Probabilistic backrunning and spam\n\n 0\n\n 169\n\n Feb 27\n\n TimeBoost: Do Ahead-of-Time Auctions Work?\n\n 0\n\n 178\n\n Nov 2025\n\n Multi-constraint pricing\n\n 2\n\n 632\n\n Nov 2025\n\n Fraud Proof Protocols: BoLD, Dave, and other alternatives\n\n 4\n\n 650\n\n Aug 2025\n\n Submitting transaction bundles\n\n 14\n\n 4.8k\n\n Aug 2025\n\n FairFlow: Leveraging TimeBoost to Build a Fair and Transparent L2 MEV Economy\n\n tx-ordering\n\n 0\n\n 447\n\n Apr 2025\n\n TimeBoost and Backrunning: Probabilistic Strategies\n\n gas-and-fees,defi,sequencer,tx-ordering\n\n 0\n\n 432\n\n Mar 2025\n\n Economic Censorship Games in Fraud Proofs\n\n 0\n\n 242\n\n Mar 2025\n\n Adjusting call Gas Limit for Arbitrum One’s Gas Model\n\n gas-and-fees\n\n 1\n\n 288\n\n Dec 2024\n\n Auctioning Multiple TimeBoost Licenses\n\n 0\n\n 280\n\n Dec 2024\n\n MEV Capture Through Time-Advantaged Arbitrage\n\n 0\n\n 811\n\n Oct 2024\n\n Decentralized Timeboost Specification\n\n sequencer,tx-ordering\n\n 2\n\n 881\n\n Sep 2024\n\n The power of faster blocks\n\n 11\n\n 4.2k\n\n Sep 2024\n\n What is testnet sequencer feed url of arb?\n\n 0\n\n 134\n\n Sep 2024\n\n Introducing the Arbitrum DeFi Dollar Rate\n\n defi\n\n 0\n\n 277\n\n Aug 2024\n\n On Sybil-proof Mechanisms\n\n 0\n\n 233\n\n Jul 2024\n\n Arbitrum Universe Explorer: Mapping the Future of Blockchain Interoperability\n\n 0\n\n 382\n\n Jul 2024\n\n Access to L1 block hash on Arbitrum\n\n 1\n\n 553\n\n Jul 2024\n\n Proposed design for Timeboost\n\n 12\n\n 3.3k\n\n Jun 2024\n\n Do shared MEV auctions actually increase revenue?\n\n 6\n\n 1.4k\n\n Jun 2024\n\n Paper on BoLD: fast, cheap dispute resolution, making permissionless validation safe\n\n 0\n\n 653\n\n Apr 2024\n\n Decentralized Timeboost R&D Update\n\n sequencer,tx-ordering\n\n 1\n\n 2.2k\n\n Apr 2024\n\n Security and governance considerations for chain-clusters\n\n 4\n\n 3.7k\n\n Mar 2024\n\n EIP-4844 shard blobs and how we would use them\n\n 6\n\n 5.1k\n\n Mar 2024\n\n RIP-7614: Expose call stack to contracts\n\n nitro\n\n 1\n\n 1.1k\n\n Feb 2024\n\n How do proposers take turns to submit new state roots on L1?\n\n sequencer\n\n 2\n\n 1.3k\n\n Jan 2024\n\n Stylus - benchmarks and feedback\n\n 2\n\n 2.0k\n\n Dec 2023","tokens":666,"squid":"spider-01","role":"Chain Spider","at":1791347475520,"hash":"47049e19d2f062ec62d0e7b42b0359adfb59919a"}
{"url":"https://forum.across.to/t/what-the-token-does/52/1","domain":"forum.across.to","title":"What the token does? - Tokenomics (old) - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n What the token does? \n\n Tokenomics (old)\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Nov 2021\n\n 1 / 26\n\n Nov 2021\n\n Apr 2022\n\n post by Kastormagic on Nov 12, 2021\n\n Kastormagic\n\n As we discusse about airdrops and « who gets what », I think we should talk about what the token does. That’s why I launch this conversation.\nAn example : Across token gives you a fees reduction when you use the bridge, xAcross (think xSushi) gives you voting power and a share of the fees.\nLet’s talk about it ! We want to hear you !\n\n 3\n\n 3\n\n 2\n\n 2\n\n read \n\n 4\n min\n\n post by heropunk.eth on Nov 17, 2021\n\n heropunk.eth\n\n AcrossIt is to build a DAO and become a community governance token, not to use it as gas, so I don’t agree with you, on the contrary AcrosdDAO, it will have more uses\n\n post by goldsnitch.eth on Nov 17, 2021\n\n goldsnitch.eth\n\n Need tokens to attract users\n\n post by fojo on Nov 17, 2021\n\n fojo\n\n Thanks for starting this discussion. To me this is the most important discussion to have with regards to tokenomics. There is no point in airdropping a token that does nothing. So first and foremost we should think about and decide on what the token will do.\nHere’s my 2 cents:\nGovernance: Establish a governance framework by granting discission making to across token holders (i.e. voting power)\nFees: Establish utility to the token (rather than it being just a governance token) by either giving fee reductions when using the bridge or a share of the fees generated by the bridge.\nSafety module: Staked across tokens will act as a collateral of last resort, to provide insurance against shortfall events. Stakers will get staking rewards. (see AAVE and DYDX for examples).\n\n post by DHACK on Nov 17, 2021\n\n DHACK\n\n Need tokens to attract users . I agree with it\n\n post by Robot on Nov 17, 2021\n\n Robot\n\n I think we should bump up the fees for using the bridge by a small % but if you stake X amount of the token then fees come back down to the original %, and if you stake even more you become eligible for profit share and all the usual stuff that comes with a govenunce token.\n\n post by fommes.eth on Nov 17, 2021\n\n fommes.eth\n\n Imho there is no point in holding the Across token for fees reduction. I imagine a tipical Across user will not bridge all the time, just looking at the general roadmap/POV that Eth mainnet is becoming solely/mostly just the settlement layer, already in the coming months ppl will use more frequent L2s and withdraw back sometimes.\n\n post by fommes.eth on Nov 17, 2021\n\n fommes.eth\n\n I propose the Across token to accrue fees for holders instead.\n\n post by Robot on Nov 17, 2021\n\n Robot\n\n fommes.eth\n\n Surely the more utility the better and i’m sure Across will have to go L2 to L2 in the end\n\n post by Sanguine on Nov 17, 2021\n\n Sanguine\n\n Kastormagic\n\n I think that token is needed for the DAO in the first place. It is not even necessary that it have economic value in the form of receiving % from commissions for the interaction of other users with the protocol. First of all, a token is a symbol. The more successful the project is, the more people want to be involved in it through the token.\n\n post by jotatotal on Nov 17, 2021\n\n jotatotal\n\n I would suggest that a part of the fees goes to the DAO treasury, and so increment value of DAO token. On the other hand I also consider that if the token is used to pay fees those fees get burned after that.\n\n post by fommes.eth on Nov 17, 2021\n\n fommes.eth\n\n Robot\n\n There are lots of L2 to L2 bridges already. Imho Across is unique in that sense and should aim to be the Go-To for fast+secure L1 withdrawals. There will always be a need for L1 withdrawals, even if Ethereum becomes mostly just an execution layer.\n\n post by Robot on Nov 17, 2021\n\n Robot\n\n Sanguine\n\n That’s not true go look at Ribbon finance and their token launch people bought and it non-stop gets called a useless govenunce token, Ribbon is very successful with about $200m TVL but the token price don’t reflect that\n\n post by Solace on Nov 17, 2021\n\n Solace\n\n Completely agree with /u/fojo’s post above - this is an important discussion regarding the token launch.\nWould the token be used strictly for governance, to pay out fees, or as a safety module? These do not necessarily have to mutually exclusive, and it’s possible that the token could incorporate all three - but as far as emission and distribution goes, it’s pretty important to make at least one a priority.\nIf choosing a governance route, liquidity incentives and a safety module could also be implemented at a later stage via a proposal. But this would remain subject to a vote, which could take some time to pass.\nOn the topic of liquidity incentives, these will likely remain temporary in order to bootstrap liquidity though there are plenty of examples of where artificially incentivizing usage has led to users with short-term outlooks farming these pools and draining the liquidity afterwards.\nAs far as using the token to incentivize usage goes, one approach could be to provide a gas fee rebate to users that bridge from L1 → L2 using the Arbitrum/optimism native bridge and bridge back to L1 using Across. This could be implemented similarly to Balancer’s gas fee rebate: [Proposal] Balancer Exchange Gas Reimbursement - Proposals - Balancer\nWe could get creative with some ways in order to incentivize usage rather than only incentivizing the LPs (as they will receive a fee of the transaction either way).\n\n post by Sanguine on Nov 17, 2021\n\n Sanguine\n\n Robot\n\n Maybe so. Indeed, in our time, the success of the project for the crowd is the endless rise in the price of the token. And if the price of a token does not grow infinitely, then they begin to call it “useless governance token”. But if the project starts to hype and the price rises, then it abruptly turns into an “incredibly useful governance token”.\n\n post by eqing.eth on Nov 21, 2021\n\n eqing.eth\n\n Kastormagic\n\n Tokens will attract some early users, which is necessary!At the initial stage of the project, it is necessary to attract users by token airdrop and distinguish real users.\n\n post by Alisa on Nov 22, 2021\n\n Alisa\n\n Acrosit is to establish a Dao and become a token of community governance. However, empowering and offsetting gas is a good suggestion, which can prevent members from throwing it out too early. However, it also has some disadvantages., if it is a gas, will it affect the development of community autonomy? But if it is only from the perspective of token, the more successful across is, the better the development of Dao will be, Of course, it will attract more people to participate\n\n 9 days later\n\n post by MrHeviDi on Dec 1, 2021\n\n MrHeviDi\n\n fommes.eth\n\n But there will be other protocals/bridges to move funds from L2 to L1, so Across needs to atract users to use Across and maybe to hold Across token. Maybe, like someone before montioned, having Across token will give you some fee reduction or something like that.\n\n 2 months later\n\n post by jotatotal on Jan 26, 2022\n\n jotatotal\n\n Solace\n\n What about giving the holders of the token , despite a fee reduction , a share of the fee according to their holdings?\n\n post by lawpanda.eth on Jan 26, 2022\n\n lawpanda.eth\n\n That would functionally be an ‘x’ token, like xSushi, dQuick, etc. On the legal end it creates regulatory questions because it resembles a security. But it is a more functional mechanism for facilitating adoption/use.\n\n Load more posts below","tokens":3355,"squid":"spider-09","role":"Bridge Spider","at":1791347477982,"hash":"ab3716659a634cf51894b080f9835add1fbd9448"}
{"url":"https://akash.network/docs/developers/deployment/akt/installation/","domain":"akash.network","title":"Install akt CLI | Akash Network - Your Guide to Decentralized Cloud","text":"Install akt CLI Install akt, verify the binary, and create your first context.\nThe archive and source instructions below install release candidate v1.0.0-rc0. Homebrew installs the latest stable release.\nCheck akt on GitHub for the most up-to-date code and GitHub Releases for the latest stable version.\n\nInstall akt\nSelect your operating system:\n\nMacOSOption 1: Homebrew (stable)Terminal windowbrew tap akash-network/tapbrew updatebrew install akash-network/tap/aktOption 2: release candidate archiveReleases ship a universal binary that runs on both Apple Silicon and Intel Macs (curl and unzip required):Terminal window# Select the release candidateAKT_TAG=\"v1.0.0-rc0\"AKT_VERSION=\"${AKT_TAG#v}\"\n# Download and verify the universal macOS archiveAKT_ARCHIVE=\"akt_${AKT_VERSION}_darwin_all.zip\"curl -sfLO \"https://github.com/akash-network/akt/releases/download/${AKT_TAG}/${AKT_ARCHIVE}\"curl -sfLO \"https://github.com/akash-network/akt/releases/download/${AKT_TAG}/akt_${AKT_VERSION}_checksums.txt\"grep \" ${AKT_ARCHIVE}$\" \"akt_${AKT_VERSION}_checksums.txt\" | shasum -a 256 -c -\n# Extract the binaryunzip \"${AKT_ARCHIVE}\" aktMove the binaryTerminal windowsudo mv ./akt /usr/local/bin/Verify the installationTerminal windowakt versionThe command prints the version, commit, and build date. Add --long for the Go version, platform, and build tags.LinuxOption: Homebrew (stable)If you already use Homebrew on Linux, install from the official tap:Terminal windowbrew tap akash-network/tapbrew updatebrew install akash-network/tap/aktDownload the release candidate archiveReleases ship amd64 and arm64 binaries (curl and unzip required):Terminal window# Select the release candidateAKT_TAG=\"v1.0.0-rc0\"AKT_VERSION=\"${AKT_TAG#v}\"\n# Map machine type to release architectureAKT_ARCH=\"$(uname -m | sed 's/x86_64/amd64/; s/aarch64/arm64/')\"\n# Download and verifyAKT_ARCHIVE=\"akt_${AKT_VERSION}_linux_${AKT_ARCH}.zip\"curl -sfLO \"https://github.com/akash-network/akt/releases/download/${AKT_TAG}/${AKT_ARCHIVE}\"curl -sfLO \"https://github.com/akash-network/akt/releases/download/${AKT_TAG}/akt_${AKT_VERSION}_checksums.txt\"grep \" ${AKT_ARCHIVE}$\" \"akt_${AKT_VERSION}_checksums.txt\" | sha256sum --check\n# Extract the binaryunzip \"${AKT_ARCHIVE}\" aktMove the binaryTerminal windowsudo mv ./akt /usr/local/bin/Option: native packageReleases also include .deb and .rpm packages. Set AKT_TAG, AKT_VERSION, and AKT_ARCH as shown above, then install the package for your distribution:Terminal window# Debian / Ubuntucurl -sfLO \"https://github.com/akash-network/akt/releases/download/${AKT_TAG}/akt_${AKT_VERSION}_linux_${AKT_ARCH}.deb\"sudo dpkg -i akt_${AKT_VERSION}_linux_${AKT_ARCH}.deb\n# Fedora / RHELcurl -sfLO \"https://github.com/akash-network/akt/releases/download/${AKT_TAG}/akt_${AKT_VERSION}_linux_${AKT_ARCH}.rpm\"sudo rpm -i akt_${AKT_VERSION}_linux_${AKT_ARCH}.rpmVerify the installationTerminal windowakt versionThe command prints the version, commit, and build date. Add --long for the Go version, platform, and build tags.WindowsUsing WSL2 (recommended)Windows binaries are not published. Install Windows Subsystem for Linux 2, then follow the Linux instructions above.Install WSL2From SourceThe Go module resolves its Akash chain SDK dependency from go.mod. You only need the akt repository:Terminal window# Clone aktgit clone --branch v1.0.0-rc0 --depth 1 https://github.com/akash-network/akt\n# Buildcd aktGOWORK=off make aktThe binary is placed in .cache/bin/akt. Move it somewhere in your PATH:Terminal windowsudo mv .cache/bin/akt /usr/local/bin/Requirements:\nGo 1.26+\nmake\nVerify InstallationTerminal windowakt version\n\nKeep akt Up to Date\nHomebrew updates to the latest stable release on macOS or Linux:\nTerminal windowbrew updatebrew upgrade akash-network/tap/aktakt version --long\nFor archive or package installations, select a stable release or release candidate from GitHub Releases and repeat the installation steps for your platform. For source builds, follow the current requirements and build instructions in the akt repository.\nUse akt <command> --help to confirm the options supported by your installed binary. The agent skill is a separate download; installing or upgrading the CLI with Homebrew does not install it.\n\nFirst Run\nStart first-time setup with an interactive context command. akt fetches available networks from akash-network/net and asks which ones to configure:\nTerminal windowakt context list\nIf no config exists, the bootstrap wizard runs before the command. It creates ~/.config/akt/config.yaml, sets up the first context, and offers Akash Console onboarding. The selected network’s current high gas price becomes the transaction fee floor. akt version only prints build information and does not launch setup.\nEverything akt stores, including config, context credentials, keyrings, and deployment state, lives under ~/.config/akt by default. Set AKT_HOME to move it.\n\nShell Completion\nGenerate a completion script for your shell:\nTerminal window# Bashakt completion bash > /etc/bash_completion.d/akt\n# Zshakt completion zsh > \"${fpath[1]}/_akt\"\n# Fishakt completion fish > ~/.config/fish/completions/akt.fish\nRestart your shell for completion to take effect.\n\nNext Steps\nNow that you’re set up, you can:\n\nContexts & Configuration - Configure contexts, networks, and keys\nDeployments - Deploy your first application with akt deploy\nCommands Reference - Learn all available commands\n\nTroubleshooting\nakt is not found\nThe binary isn’t in your PATH. Try:\nTerminal window# Find where it's installedwhich akt\n# Add to PATH (Linux/macOS)export PATH=$PATH:/path/to/akt\nmacOS blocks the binary\nIf macOS Gatekeeper refuses to run the downloaded binary, remove the quarantine attribute:\nTerminal windowxattr -d com.apple.quarantine /usr/local/bin/akt\nBootstrap cannot fetch networks\nThe first-run wizard needs network access to fetch network definitions. If you are offline or behind a restrictive proxy, create a network manually instead:\nTerminal windowakt context network create local --chain-id localnet-1 --rpc http://localhost:26657\n\nNeed Help?\n\nRelease notes - Published versions and checksums\nAkash Discord - Get help from the community\nGitHub Issues - Report bugs\n\nEdit page on github\n Getting Started Configuration","tokens":1561,"squid":"spider-03","role":"Compute Spider","at":1791347483484,"hash":"6c2f8c61172cf41927a98c366c03ecd5b1ded494"}
{"url":"https://forum.across.to/t/what-the-token-does/52/4","domain":"forum.across.to","title":"What the token does? - Tokenomics (old) - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n Tokenomics (old)\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Nov 2021\n\n 4 / 26\n\n Nov 2021\n\n Apr 2022\n\n post by Kastormagic on Nov 12, 2021\n\n Kastormagic\n\n As we discusse about airdrops and « who gets what », I think we should talk about what the token does. That’s why I launch this conversation.\nAn example : Across token gives you a fees reduction when you use the bridge, xAcross (think xSushi) gives you voting power and a share of the fees.\nLet’s talk about it ! We want to hear you !\n\n 3\n\n 3\n\n 2\n\n 2\n\n read \n\n 4\n min\n\n post by heropunk.eth on Nov 17, 2021\n\n heropunk.eth\n\n AcrossIt is to build a DAO and become a community governance token, not to use it as gas, so I don’t agree with you, on the contrary AcrosdDAO, it will have more uses\n\n post by goldsnitch.eth on Nov 17, 2021\n\n goldsnitch.eth\n\n Need tokens to attract users\n\n post by fojo on Nov 17, 2021\n\n fojo\n\n Thanks for starting this discussion. To me this is the most important discussion to have with regards to tokenomics. There is no point in airdropping a token that does nothing. So first and foremost we should think about and decide on what the token will do.\nHere’s my 2 cents:\nGovernance: Establish a governance framework by granting discission making to across token holders (i.e. voting power)\nFees: Establish utility to the token (rather than it being just a governance token) by either giving fee reductions when using the bridge or a share of the fees generated by the bridge.\nSafety module: Staked across tokens will act as a collateral of last resort, to provide insurance against shortfall events. Stakers will get staking rewards. (see AAVE and DYDX for examples).\n\n post by DHACK on Nov 17, 2021\n\n DHACK\n\n Need tokens to attract users . I agree with it\n\n post by Robot on Nov 17, 2021\n\n Robot\n\n I think we should bump up the fees for using the bridge by a small % but if you stake X amount of the token then fees come back down to the original %, and if you stake even more you become eligible for profit share and all the usual stuff that comes with a govenunce token.\n\n post by fommes.eth on Nov 17, 2021\n\n fommes.eth\n\n Imho there is no point in holding the Across token for fees reduction. I imagine a tipical Across user will not bridge all the time, just looking at the general roadmap/POV that Eth mainnet is becoming solely/mostly just the settlement layer, already in the coming months ppl will use more frequent L2s and withdraw back sometimes.\n\n post by fommes.eth on Nov 17, 2021\n\n fommes.eth\n\n I propose the Across token to accrue fees for holders instead.\n\n post by Robot on Nov 17, 2021\n\n Robot\n\n fommes.eth\n\n Surely the more utility the better and i’m sure Across will have to go L2 to L2 in the end\n\n post by Sanguine on Nov 17, 2021\n\n Sanguine\n\n Kastormagic\n\n I think that token is needed for the DAO in the first place. It is not even necessary that it have economic value in the form of receiving % from commissions for the interaction of other users with the protocol. First of all, a token is a symbol. The more successful the project is, the more people want to be involved in it through the token.\n\n post by jotatotal on Nov 17, 2021\n\n jotatotal\n\n I would suggest that a part of the fees goes to the DAO treasury, and so increment value of DAO token. On the other hand I also consider that if the token is used to pay fees those fees get burned after that.\n\n post by fommes.eth on Nov 17, 2021\n\n fommes.eth\n\n Robot\n\n There are lots of L2 to L2 bridges already. Imho Across is unique in that sense and should aim to be the Go-To for fast+secure L1 withdrawals. There will always be a need for L1 withdrawals, even if Ethereum becomes mostly just an execution layer.\n\n post by Robot on Nov 17, 2021\n\n Robot\n\n Sanguine\n\n That’s not true go look at Ribbon finance and their token launch people bought and it non-stop gets called a useless govenunce token, Ribbon is very successful with about $200m TVL but the token price don’t reflect that\n\n post by Solace on Nov 17, 2021\n\n Solace\n\n Completely agree with /u/fojo’s post above - this is an important discussion regarding the token launch.\nWould the token be used strictly for governance, to pay out fees, or as a safety module? These do not necessarily have to mutually exclusive, and it’s possible that the token could incorporate all three - but as far as emission and distribution goes, it’s pretty important to make at least one a priority.\nIf choosing a governance route, liquidity incentives and a safety module could also be implemented at a later stage via a proposal. But this would remain subject to a vote, which could take some time to pass.\nOn the topic of liquidity incentives, these will likely remain temporary in order to bootstrap liquidity though there are plenty of examples of where artificially incentivizing usage has led to users with short-term outlooks farming these pools and draining the liquidity afterwards.\nAs far as using the token to incentivize usage goes, one approach could be to provide a gas fee rebate to users that bridge from L1 → L2 using the Arbitrum/optimism native bridge and bridge back to L1 using Across. This could be implemented similarly to Balancer’s gas fee rebate: [Proposal] Balancer Exchange Gas Reimbursement - Proposals - Balancer\nWe could get creative with some ways in order to incentivize usage rather than only incentivizing the LPs (as they will receive a fee of the transaction either way).\n\n post by Sanguine on Nov 17, 2021\n\n Sanguine\n\n Robot\n\n Maybe so. Indeed, in our time, the success of the project for the crowd is the endless rise in the price of the token. And if the price of a token does not grow infinitely, then they begin to call it “useless governance token”. But if the project starts to hype and the price rises, then it abruptly turns into an “incredibly useful governance token”.\n\n post by eqing.eth on Nov 21, 2021\n\n eqing.eth\n\n Kastormagic\n\n Tokens will attract some early users, which is necessary!At the initial stage of the project, it is necessary to attract users by token airdrop and distinguish real users.\n\n post by Alisa on Nov 22, 2021\n\n Alisa\n\n Acrosit is to establish a Dao and become a token of community governance. However, empowering and offsetting gas is a good suggestion, which can prevent members from throwing it out too early. However, it also has some disadvantages., if it is a gas, will it affect the development of community autonomy? But if it is only from the perspective of token, the more successful across is, the better the development of Dao will be, Of course, it will attract more people to participate\n\n 9 days later\n\n post by MrHeviDi on Dec 1, 2021\n\n MrHeviDi\n\n fommes.eth\n\n But there will be other protocals/bridges to move funds from L2 to L1, so Across needs to atract users to use Across and maybe to hold Across token. Maybe, like someone before montioned, having Across token will give you some fee reduction or something like that.\n\n 2 months later\n\n post by jotatotal on Jan 26, 2022\n\n jotatotal\n\n Solace\n\n What about giving the holders of the token , despite a fee reduction , a share of the fee according to their holdings?\n\n post by lawpanda.eth on Jan 26, 2022\n\n lawpanda.eth\n\n That would functionally be an ‘x’ token, like xSushi, dQuick, etc. On the legal end it creates regulatory questions because it resembles a security. But it is a more functional mechanism for facilitating adoption/use.\n\n Load more posts below","tokens":3349,"squid":"spider-09","role":"Bridge Spider","at":1791347488304,"hash":"48ab2b53d1f75d84cb6bb57f5d1ccbb4fb0e6a43"}
{"url":"https://www.metaplex.com/docs/smart-contracts/genesis/launch-pool","domain":"metaplex.com","title":"Genesis Launch Pool | Fair Launch & Token Distribution on Solana | Metaplex","text":"Launch Pools provide organic price discovery for fair token launches on Solana. Users deposit SOL during a window and receive SPL tokens proportional to their share of total deposits. No sniping, no front-running, fair distribution for everyone. What You'll LearnThis guide covers:How Launch Pool pricing and distribution worksSetting up deposit and claim windowsConfiguring end behaviors for fund collectionUser operations: Deposit, withdraw, and claimSummaryLaunch Pools are a crowdsale-style token launch mechanism that accepts deposits during a defined window, then distributes tokens proportionally. The final token price is determined by total deposits divided by token allocation — enabling transparent, on-chain price discovery for your token generation event (TGE).Users deposit SOL during the deposit window (0% fee applies)Withdrawals allowed during deposit period (0% fee)Token distribution is proportional to deposit shareAn optional soft cap bounds how much the launch keeps, refunding the excess pro-rataEnd behaviors route collected SOL to treasury bucketsLaunch Pools discover price from deposits. For a fixed price set upfront, use Presale; for bid-based clearing, use Uniform Price Auction. Liquidity pool creation is handled by the Raydium graduation buckets, not by the Launch Pool bucket itself.Quick StartHow It WorksA specific quantity of tokens is allocated to the Launch Pool bucketUsers deposit SOL during the deposit window (withdrawals allowed with fee)When the window closes, tokens distribute proportionally based on deposit sharePrice DiscoveryThe token price emerges from total deposits:tokenPrice = totalDeposits / tokenAllocation\nuserTokens = (userDeposit / totalDeposits) * tokenAllocation\nExample: 1,000,000 tokens allocated, 100 SOL total deposits = 0.0001 SOL per tokenPrice discovery is unbounded by default — the more the pool is subscribed, the higher the implied price. Set a soft cap to put a ceiling on it.LifecycleDeposit Period - Users deposit SOL during a defined windowtriggerBehaviorsV2 - End behaviors execute (e.g., send collected SOL to another bucket)Claim Period - Users claim tokens proportional to their deposit weightRefund Period (conditional) - If a soft cap was exceeded or a minimum quote token threshold was missed, depositors call refundLaunchPoolV2Launch Pool Soft CapA soft cap is a ceiling on the quote tokens a Launch Pool keeps, configured with the softCap extension on addLaunchPoolBucketV2. Deposits above the cap are still accepted during the deposit window, the launch still succeeds, and the excess quote tokens are refunded pro-rata once the window closes.Without a soft cap, price discovery is unbounded: every deposit is kept and the implied token price rises with subscription. A soft cap fixes the maximum the launch raises, so the effective price is softCap / baseTokenAllocation no matter how far deposits overshoot.PropertyBehaviour when a soft cap is configuredDeposits above the capAccepted during the deposit window — deposits are never rejected at the capLaunch outcomeSucceeds — a soft cap is a ceiling, never a failure conditionBase token distributionFull baseTokenAllocation distributed pro-rata across all depositsExcess quote tokensRefunded pro-rata via refundLaunchPoolV2 after the deposit window endsProceeds seen by end behaviorsClamped to the soft cap, so SendQuoteTokenPercentage forwards at most softCapRaydium graduation start priceDerived from the capped proceeds, not the raw deposit totalA soft cap is a ceiling on capital raised, not a floor. The floor is a separate extension, minimumQuoteTokenThreshold — see Soft Cap and Minimum Quote Token Threshold Together.Configuring a Soft Cap on a Launch Pool BucketPass a softCap value to addLaunchPoolBucketV2 when you add the bucket. The amount is denominated in quote token quantum units (lamports for wSOL).Add a Launch Pool bucket with a 100 SOL soft capimport { sol } from '@metaplex-foundation/umi';\n\nawait addLaunchPoolBucketV2(umi, {\n genesisAccount,\n baseMint: baseMint.publicKey,\n baseTokenAllocation: TOTAL_SUPPLY,\n // ...time conditions and end behaviors...\n\n // Floor: the launch fails below this and everyone can take a full refund.\n minimumQuoteTokenThreshold: { amount: sol(10).basisPoints },\n\n // Ceiling: the launch keeps at most this much; the rest is refunded pro-rata.\n softCap: { amount: sol(100).basisPoints },\n}).sendAndConfirm(umi);\nsoftCap is a required argument on addLaunchPoolBucketV2 in @metaplex-foundation/genesis 0.42.0. Unlike the other Launch Pool extensions it has no default, so pass softCap: null explicitly when you do not want a cap.Soft caps are validated when the extension is set and again at finalizeV2:RuleError if violatedsoftCap.amount must be greater than zeroInvalidSoftCap (221)softCap.amount must be greater than or equal to minimumQuoteTokenThreshold.amountSoftCapBelowThreshold (222)Extensions can only be added or removed before finalizeV2Account is rejected as already finalizedA soft cap can also be set or cleared on an existing bucket with addLaunchPoolBucketV2Extensions and removeLaunchPoolBucketV2Extensions using the SoftCap member of LaunchPoolV2ExtensionType — but only while the Genesis Account is unfinalized.Oversubscription and Pro-Rata Refund MathA Launch Pool is oversubscribed when quoteTokenDepositTotal is strictly greater than softCap.amount. Each deposit is then split into a filled portion that counts toward the cap and an excess portion that is refundable:Per-depositor split in an oversubscribed Launch Poolfilled_i = ceil(deposit_i * softCap / totalDeposits)\nexcess_i = deposit_i - filled_i\ntokens_i = (weighted_i / weightedQuoteTokenTotal) * baseTokenAllocation\nfilled rounds up so that the sum of all filled portions is always at least the soft cap. This keeps the bucket solvent against the capped graduation transfer regardless of whether refunds or graduation are cranked first; each depositor's rounding adds less than one quantum unit, so the dust left in the bucket is at most depositCount - 1 quantum units in total.Token allocation is unaffected by the cap. Refunding excess does not remove a depositor's weighted contribution, so everyone still receives tokens proportional to their full deposit.Worked example — 1,000,000 tokens allocated, a 100 SOL soft cap, and 150 SOL deposited:DepositorDepositedFilled (kept)RefundedTokens receivedAlice50 SOL~33.33 SOL~16.67 SOL333,333 (1/3)Bob100 SOL~66.67 SOL~33.33 SOL666,667 (2/3)Total150 SOL100 SOL50 SOL1,000,000The effective price is 0.0001 SOL per token (100 SOL / 1,000,000), not the 0.00015 SOL per token the uncapped deposit total would have implied. On-chain values are computed in lamports with filled rounded up, so real figures differ from the rounded SOL amounts above by a few lamports.Refunding Excess Deposits with refundLaunchPoolV2refundLaunchPoolV2 returns a depositor's excess quote tokens after an oversubscribed deposit window closes. It takes no amount argument — the program computes the refundable amount from the deposit, the soft cap, and the bucket's deposit total.refundLaunchPool.ts1import {\n2 genesis,\n3 refundLaunchPoolV2,\n4} from '@metaplex-foundation/genesis'\n5import { mplToolbox } from '@metaplex-foundation/mpl-toolbox'\n6import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n7\n8const umi = createUmi('https://api.mainnet-beta.solana.com')\n9 .use(mplToolbox())\n10 .use(genesis())\n11\n12// umi.use(keypairIdentity(yourKeypair));\n13\n14// Assumes genesisAccount, launchPoolBucket, and baseMint from previous steps.\n15// Only valid after the deposit window closed AND either the\n16// minimumQuoteTokenThreshold was missed or the softCap was exceeded.\n17\n18// The program computes the refundable amount, so there is no amount argument.\n19// A missed threshold refunds the full deposit; an exceeded soft cap refunds\n20// only the excess, leaving the depositor's token allocation intact.\n21await refundLaunchPoolV2(umi, {\n22 genesisAccount,\n23 bucket: launchPoolBucket,\n24 baseMint: baseMint.publicKey,\n25 recipient: umi.identity.publicKey,\n26}).sendAndConfirm(umi)\nKey properties of the refund path:Cranking is permissionless. Only payer must sign. If the depositor also signs, their empty base token account is closed for them.No fee and no penalty are applied to a refund; deposit and withdraw penalty schedules do not affect it.Claim order does not matter. An excess refund is allowed before or after claimLaunchPoolV2; both orderings converge on the same final state.One refund per deposit. A second call returns DepositAlreadyRefunded.Refunds are gated on the deposit window ending. Calling earlier returns LaunchPoolNotEnded.Refunds require a failed floor or an exceeded cap. If neither applies, the call returns LaunchPoolThresholdMet.Soft Cap and Minimum Quote Token Threshold TogethersoftCap and minimumQuoteTokenThreshold are independent extensions that bound a Launch Pool from opposite directions, and refundLaunchPoolV2 serves both. When the floor fails, that takes precedence and the refund is a full one.ConfigurationDeposits below the floorDeposits between floor and capDeposits above the capNeither setLaunch succeeds, no refundsLaunch succeeds, no refundsLaunch succeeds, no refundsFloor onlyLaunch fails, full refundsLaunch succeeds, no refundsLaunch succeeds, no refundsCap onlyLaunch succeeds, no refundsLaunch succeeds, no refundsLaunch succeeds, excess refunded pro-rataFloor and capLaunch fails, full refundsLaunch succeeds, no refundsLaunch succeeds, excess refunded pro-rataA full refund removes the depositor's weighted contribution from the bucket and cannot follow a claim — a failed floor means no claim was possible. An excess refund leaves the weighted contribution intact so the pro-rata claim formula stays correct.FeesInstructionSolanaUser deposit fee0%User withdraw fee0%Creator withdraw fee5%** This fee only applies when creators withdraw liquidityEach deposit increases your credited balance by the SOL left after the user deposit fee (0%) is withheld from the deposit.Setup GuidePrerequisitesnpm install @metaplex-foundation/genesis @metaplex-foundation/umi @metaplex-foundation/umi-bundle-defaults @metaplex-foundation/mpl-toolbox\n1. Initialize the Genesis AccountThe Genesis Account creates your token and coordinates all distribution buckets.initializeV2.ts1import {\n2 findGenesisAccountV2Pda,\n3 genesis,\n4 initializeV2,\n5} from '@metaplex-foundation/genesis'\n6import { mplToolbox } from '@metaplex-foundation/mpl-toolbox'\n7import { generateSigner, keypairIdentity } from '@metaplex-foundation/umi'\n8import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n9\n10const umi = createUmi('https://api.mainnet-beta.solana.com')\n11 .use(mplToolbox())\n12 .use(genesis())\n13\n14// umi.use(keypairIdentity(yourKeypair));\n15\n16const baseMint = generateSigner(umi)\n17const TOTAL_SUPPLY = 1_000_000_000_000_000n // 1 million tokens (9 decimals)\n18\n19// Store this account address for later or recreate it when needed.\n20const [genesisAccount] = findGenesisAccountV2Pda(umi, {\n21 baseMint: baseMint.publicKey,\n22 genesisIndex: 0,\n23})\n24\n25await initializeV2(umi, {\n26 baseMint,\n27 fundingMode: 0,\n28 totalSupplyBaseToken: TOTAL_SUPPLY,\n29 name: 'My Token',\n30 symbol: 'MTK',\n31 uri: 'https://example.com/metadata.json',\n32}).sendAndConfirm(umi)\nThe totalSupplyBaseToken should equal the sum of all bucket allocations.2. Add the Launch Pool BucketThe Launch Pool bucket collects deposits and distributes tokens proportionally. Configure timing here.addLaunchPoolBucket.ts1import {\n2 addLaunchPoolBucketV2,\n3 findLaunchPoolBucketV2Pda,\n4 findUnlockedBucketV2Pda,\n5 genesis,\n6} from '@metaplex-foundation/genesis'\n7import { mplToolbox } from '@metaplex-foundation/mpl-toolbox'\n8import { publicKey } from '@metaplex-foundation/umi'\n9import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n10\n11const umi = createUmi('https://api.mainnet-beta.solana.com')\n12 .use(mplToolbox())\n13 .use(genesis())\n14\n15// umi.use(keypairIdentity(yourKeypair));\n16\n17// Assumes genesisAccount, baseMint, and TOTAL_SUPPLY from the Initialize step.\n18\n19const [launchPoolBucket] = findLaunchPoolBucketV2Pda(umi, { genesisAccount, bucketIndex: 0 })\n20const [unlockedBucket] = findUnlockedBucketV2Pda(umi, { genesisAccount, bucketIndex: 0 })\n21\n22const now = BigInt(Math.floor(Date.now() / 1000))\n23const depositStart = now\n24const depositEnd = now + 86400n // 24 hours\n25const claimStart = depositEnd + 1n\n26const claimEnd = claimStart + 604800n // 1 week\n27\n28await addLaunchPoolBucketV2(umi, {\n29 genesisAccount,\n30 baseMint: baseMint.publicKey,\n31 baseTokenAllocation: TOTAL_SUPPLY,\n32\n33 // Timing\n34 depositStartCondition: {\n35 __kind: 'TimeAbsolute',\n36 padding: Array(47).fill(0),\n37 time: depositStart,\n38 triggeredTimestamp: null,\n39 },\n40 depositEndCondition: {\n41 __kind: 'TimeAbsolute',\n42 padding: Array(47).fill(0),\n43 time: depositEnd,\n44 triggeredTimestamp: null,\n45 },\n46 claimStartCondition: {\n47 __kind: 'TimeAbsolute',\n48 padding: Array(47).fill(0),\n49 time: claimStart,\n50 triggeredTimestamp: null,\n51 },\n52 claimEndCondition: {\n53 __kind: 'TimeAbsolute',\n54 padding: Array(47).fill(0),\n55 time: claimEnd,\n56 triggeredTimestamp: null,\n57 },\n58\n59 // Optional: Minimum deposit\n60 minimumDepositAmount: null, // or { amount: sol(0.1).basisPoints }\n61\n62 // Required since @metaplex-foundation/genesis 0.42.0: pass null for no soft cap,\n63 // or { amount: sol(100).basisPoints } to cap the quote tokens kept\n64 softCap: null,\n65\n66 // Where collected SOL goes after transition\n67 endBehaviors: [\n68 {\n69 __kind: 'SendQuoteTokenPercentage',\n70 padding: Array(4).fill(0),\n71 destinationBucket: publicKey(unlockedBucket),\n72 percentageBps: 10000, // 100%\n73 processed: false,\n74 },\n75 ],\n76}).sendAndConfirm(umi)\n3. Add the Unlocked BucketThe Unlocked bucket receives SOL from the Launch Pool after triggerBehaviorsV2 executes.addUnlockedBucket.ts1import {\n2 addUnlockedBucketV2,\n3 genesis,\n4} from '@metaplex-foundation/genesis'\n5import { mplToolbox } from '@metaplex-foundation/mpl-toolbox'\n6import { keypairIdentity } from '@metaplex-foundation/umi'\n7import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n8\n9const umi = createUmi('https://api.mainnet-beta.solana.com')\n10 .use(mplToolbox())\n11 .use(genesis())\n12\n13// umi.use(keypairIdentity(yourKeypair));\n14\n15// Assumes genesisAccount, baseMint, claimStart, and claimEnd from previous steps.\n16\n17await addUnlockedBucketV2(umi, {\n18 genesisAccount,\n19 baseMint: baseMint.publicKey,\n20 baseTokenAllocation: 0n,\n21 recipient: umi.identity.publicKey,\n22 claimStartCondition: {\n23 __kind: 'TimeAbsolute',\n24 padding: Array(47).fill(0),\n25 time: claimStart,\n26 triggeredTimestamp: null,\n27 },\n28 claimEndCondition: {\n29 __kind: 'TimeAbsolute',\n30 padding: Array(47).fill(0),\n31 time: claimEnd,\n32 triggeredTimestamp: null,\n33 },\n34 backendSigner: null,\n35}).sendAndConfirm(umi)\n4. FinalizeOnce all buckets are configured, finalize to activate the launch. This is irreversible.finalize.ts1import {\n2 genesis,\n3 finalizeV2,\n4} from '@metaplex-foundation/genesis'\n5import { mplToolbox } from '@metaplex-foundation/mpl-toolbox'\n6import { keypairIdentity } from '@metaplex-foundation/umi'\n7import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n8\n9const umi = createUmi('https://api.mainnet-beta.solana.com')\n10 .use(mplToolbox())\n11 .use(genesis())\n12\n13// umi.use(keypairIdentity(yourKeypair));\n14\n15// Assumes genesisAccount and baseMint from the Initialize step.\n16\n17await finalizeV2(umi, {\n18 baseMint: baseMint.publicKey,\n19 genesisAccount,\n20}).sendAndConfirm(umi)\nUser OperationsWrapping SOLUsers must wrap SOL to wSOL before depositing.wrapSol.ts1import {\n2 findAssociatedTokenPda,\n3 createTokenIfMissing,\n4 transferSol,\n5 syncNative,\n6 mplToolbox,\n7} from '@metaplex-foundation/mpl-toolbox'\n8import { WRAPPED_SOL_MINT, genesis } from '@metaplex-foundation/genesis'\n9import { keypairIdentity, publicKey, sol } from '@metaplex-foundation/umi'\n10import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n11\n12const umi = createUmi('https://api.mainnet-beta.solana.com')\n13 .use(mplToolbox())\n14 .use(genesis())\n15\n16// umi.use(keypairIdentity(yourKeypair));\n17\n18const userWsolAccount = findAssociatedTokenPda(umi, {\n19 owner: umi.identity.publicKey,\n20 mint: WRAPPED_SOL_MINT,\n21})\n22\n23await createTokenIfMissing(umi, {\n24 mint: WRAPPED_SOL_MINT,\n25 owner: umi.identity.publicKey,\n26 token: userWsolAccount,\n27})\n28 .add(\n29 transferSol(umi, {\n30 destination: publicKey(userWsolAccount),\n31 amount: sol(10),\n32 })\n33 )\n34 .add(syncNative(umi, { account: userWsolAccount }))\n35 .sendAndConfirm(umi)\nDepositingdepositLaunchPool.ts1import {\n2 genesis,\n3 depositLaunchPoolV2,\n4 findLaunchPoolDepositV2Pda,\n5 fetchLaunchPoolDepositV2,\n6} from '@metaplex-foundation/genesis'\n7import { mplToolbox } from '@metaplex-foundation/mpl-toolbox'\n8import { keypairIdentity, sol } from '@metaplex-foundation/umi'\n9import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n10\n11const umi = createUmi('https://api.mainnet-beta.solana.com')\n12 .use(mplToolbox())\n13 .use(genesis())\n14\n15// umi.use(keypairIdentity(yourKeypair));\n16\n17// Assumes genesisAccount, launchPoolBucket, and baseMint from previous steps.\n18\n19await depositLaunchPoolV2(umi, {\n20 genesisAccount,\n21 bucket: launchPoolBucket,\n22 baseMint: baseMint.publicKey,\n23 amountQuoteToken: sol(10).basisPoints,\n24}).sendAndConfirm(umi)\n25\n26// Verify\n27const [depositPda] = findLaunchPoolDepositV2Pda(umi, {\n28 bucket: launchPoolBucket,\n29 recipient: umi.identity.publicKey,\n30})\n31const deposit = await fetchLaunchPoolDepositV2(umi, depositPda)\n32\n33console.log('Deposited (after fee):', deposit.amountQuoteToken)\nMultiple deposits from the same user accumulate into a single deposit account.WithdrawingUsers can withdraw during the deposit period. A 0% fee applies.withdrawLaunchPool.ts1import {\n2 genesis,\n3 withdrawLaunchPoolV2,\n4} from '@metaplex-foundation/genesis'\n5import { mplToolbox } from '@metaplex-foundation/mpl-toolbox'\n6import { keypairIdentity, sol } from '@metaplex-foundation/umi'\n7import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n8\n9const umi = createUmi('https://api.mainnet-beta.solana.com')\n10 .use(mplToolbox())\n11 .use(genesis())\n12\n13// umi.use(keypairIdentity(yourKeypair));\n14\n15// Assumes genesisAccount, launchPoolBucket, and baseMint from previous steps.\n16\n17await withdrawLaunchPoolV2(umi, {\n18 genesisAccount,\n19 bucket: launchPoolBucket,\n20 baseMint: baseMint.publicKey,\n21 amountQuoteToken: sol(3).basisPoints,\n22}).sendAndConfirm(umi)\nIf a user withdraws their entire balance, the deposit PDA is closed.Claiming TokensAfter the deposit period ends and claims open:claimLaunchPool.ts1import {\n2 claimLaunchPoolV2,\n3 genesis,\n4} from '@metaplex-foundation/genesis'\n5import { mplToolbox } from '@metaplex-foundation/mpl-toolbox'\n6import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n7\n8const umi = createUmi('https://api.mainnet-beta.solana.com')\n9 .use(mplToolbox())\n10 .use(genesis())\n11\n12// umi.use(keypairIdentity(yourKeypair));\n13\n14// Assumes genesisAccount, launchPoolBucket, and baseMint from previous steps.\n15\n16await claimLaunchPoolV2(umi, {\n17 genesisAccount,\n18 bucket: launchPoolBucket,\n19 baseMint: baseMint.publicKey,\n20 recipient: umi.identity.publicKey,\n21}).sendAndConfirm(umi)\nToken allocation: userTokens = (userDeposit / totalDeposits) * bucketTokenAllocationRefunding a DepositRefunds are available in two cases: the launch missed its minimumQuoteTokenThreshold (full refund), or it exceeded its softCap (excess-only refund). Both use the same instruction — see Refunding Excess Deposits with refundLaunchPoolV2.Admin OperationsExecuting triggerBehaviorsV2After deposits close, run triggerBehaviorsV2 to move collected SOL to the unlocked bucket.triggerBehaviors.ts1import {\n2 genesis,\n3 triggerBehaviorsV2,\n4 WRAPPED_SOL_MINT,\n5} from '@metaplex-foundation/genesis'\n6import {\n7 findAssociatedTokenPda,\n8 mplToolbox,\n9} from '@metaplex-foundation/mpl-toolbox'\n10import { publicKey } from '@metaplex-foundation/umi'\n11import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n12\n13const umi = createUmi('https://api.mainnet-beta.solana.com')\n14 .use(mplToolbox())\n15 .use(genesis())\n16\n17// umi.use(keypairIdentity(yourKeypair));\n18\n19// Assumes genesisAccount, launchPoolBucket, unlockedBucket, and baseMint from previous steps.\n20\n21const unlockedBucketQuoteTokenAccount = findAssociatedTokenPda(umi, {\n22 owner: unlockedBucket,\n23 mint: WRAPPED_SOL_MINT,\n24})\n25\n26await triggerBehaviorsV2(umi, {\n27 genesisAccount,\n28 primaryBucket: launchPoolBucket,\n29 baseMint,\n30})\n31 .addRemainingAccounts([\n32 { pubkey: publicKey(unlockedBucket), isSigner: false, isWritable: true },\n33 { pubkey: publicKey(unlockedBucketQuoteTokenAccount), isSigner: false, isWritable: true },\n34 ])\n35 .sendAndConfirm(umi)\nWhy this matters: Without running triggerBehaviorsV2, collected SOL stays locked in the Launch Pool bucket. Users can still claim tokens, but the team cannot access the raised funds.ReferenceTime ConditionsFour conditions control Launch Pool timing:ConditionPurposedepositStartConditionWhen deposits opendepositEndConditionWhen deposits closeclaimStartConditionWhen claims openclaimEndConditionWhen claims closeUse TimeAbsolute with a Unix timestamp:const condition = {\n __kind: 'TimeAbsolute',\n padding: Array(47).fill(0),\n time: BigInt(Math.floor(Date.now() / 1000) + 3600), // 1 hour from now\n triggeredTimestamp: null,\n};\nEnd BehaviorsDefine what happens to collected SOL after the deposit period:endBehaviors: [\n {\n __kind: 'SendQuoteTokenPercentage',\n padding: Array(4).fill(0),\n destinationBucket: publicKey(unlockedBucket),\n percentageBps: 10000, // 100% = 10000 basis points\n processed: false,\n },\n]\nYou can split funds across multiple buckets:endBehaviors: [\n {\n __kind: 'SendQuoteTokenPercentage',\n padding: Array(4).fill(0),\n destinationBucket: publicKey(treasuryBucket),\n percentageBps: 2000, // 20%\n processed: false,\n },\n {\n __kind: 'SendQuoteTokenPercentage',\n padding: Array(4).fill(0),\n destinationBucket: publicKey(liquidityBucket),\n percentageBps: 8000, // 80%\n processed: false,\n },\n]\nLaunch Pool ExtensionsExtensions are optional guards configured on the Launch Pool bucket. All are set through addLaunchPoolBucketV2, or added and removed individually with addLaunchPoolBucketV2Extensions and removeLaunchPoolBucketV2Extensions before finalizeV2.ExtensionTypePurposesoftCap{ amount: bigint }Ceiling on quote tokens kept; excess refunded pro-rataminimumQuoteTokenThreshold{ amount: bigint }Floor below which the launch fails and full refunds openminimumDepositAmount{ amount: bigint }Minimum quote tokens per depositdepositLimit{ limit: bigint }Maximum quote tokens per accountallowlistAllowlistGates deposits to an allowlisted set of walletsclaimScheduleClaimScheduleVests claimed base tokens over timebonusScheduleLinearBpsScheduleV2Time-weighted deposit bonusdepositPenaltyLinearBpsScheduleV2Time-weighted deposit penaltywithdrawPenaltyLinearBpsScheduleV2Time-weighted withdrawal penaltybackendSignerBackendSignerRequires a backend co-signer on user actionsCommon ErrorsThe errors below cover invalid soft cap configurations and the Launch Pool states in which refundLaunchPoolV2 rejects a refund request.ErrorCodeCauseInvalidSoftCap221softCap.amount is zero — omit the extension instead of setting it to 0SoftCapBelowThreshold222softCap.amount is below minimumQuoteTokenThreshold.amountLaunchPoolNotEnded—refundLaunchPoolV2 called before the deposit window closedLaunchPoolThresholdMet173Refund requested when the floor was met and the cap was not exceededDepositAlreadyRefunded—refundLaunchPoolV2 called twice for the same depositDepositAlreadyClaimed—Full refund requested after the depositor already claimed tokensFetching StateBucket state:import { fetchLaunchPoolBucketV2 } from '@metaplex-foundation/genesis';\n\nconst bucket = await fetchLaunchPoolBucketV2(umi, launchPoolBucket);\nconsole.log('Total deposits:', bucket.quoteTokenDepositTotal);\nconsole.log('Deposit count:', bucket.depositCount);\nconsole.log('Claim count:', bucket.claimCount);\nconsole.log('Token allocation:', bucket.bucket.baseTokenAllocation);\n\n// Soft cap state (Option<SoftCap>)\nconsole.log('Soft cap:', bucket.extensions.softCap);\nconsole.log('Floor:', bucket.extensions.minimumQuoteTokenThreshold);\nDeposit state:import { fetchLaunchPoolDepositV2, safeFetchLaunchPoolDepositV2 } from '@metaplex-foundation/genesis';\n\nconst deposit = await fetchLaunchPoolDepositV2(umi, depositPda); // throws if not found\nconst maybeDeposit = await safeFetchLaunchPoolDepositV2(umi, depositPda); // returns null\n\nif (deposit) {\n console.log('Amount deposited:', deposit.amountQuoteToken);\n console.log('Claimed:', deposit.claimed);\n console.log('Refunded:', deposit.refunded);\n}\nNotesUser deposit and withdraw fees for Launch Pool are shown in Fees above.Multiple deposits from the same user accumulate in one deposit accountIf a user withdraws their entire balance, the deposit PDA closestriggerBehaviorsV2 must be executed after deposits close for end behaviors to processUsers must have wSOL (wrapped SOL) to depositsoftCap is a required argument on addLaunchPoolBucketV2 in @metaplex-foundation/genesis 0.42.0 — pass softCap: null when no cap is wantedLaunch Pool extensions, including softCap, can only be added or removed before finalizeV2Soft caps are supported by the Genesis program, the JavaScript SDK, and the mplx CLIAn oversubscribed Launch Pool leaves rounding dust of at most depositCount - 1 quantum units in the bucket, because each depositor's filled portion rounds upquoteTokenDepositTotal and depositCount are preserved as historical records after refunds; refundCount tracks refunds processedFAQHow is the token price determined in a Launch Pool?The price is discovered organically based on total deposits. Final price equals total SOL deposited divided by tokens allocated. More deposits means higher implied price per token.Can users withdraw their deposits?Yes, users can withdraw during the deposit period. A 0% withdrawal fee applies to discourage gaming the system.What happens if I deposit multiple times?Multiple deposits from the same wallet accumulate into a single deposit account. Your total share is based on your combined deposits.When can users claim their tokens?After the deposit period ends and the claim window opens (defined by claimStartCondition). triggerBehaviorsV2 must be executed first to process end behaviors.What's the difference between Launch Pool and Presale?Launch Pool discovers price organically based on deposits with proportional distribution. Presale has a fixed price set upfront with first-come-first-served allocation up to the cap.What is a Launch Pool soft cap?A soft cap is a ceiling on the quote tokens a Launch Pool keeps, set with the softCap extension. Deposits above the cap are still accepted, the launch still succeeds, and the excess is refunded pro-rata after the deposit window closes.What is the difference between a soft cap and a minimum quote token threshold?A soft cap is a ceiling on capital raised and never causes a launch to fail. A minimumQuoteTokenThreshold is a floor — if total deposits fall below it, the launch fails and every depositor can take a full refund. They are separate extensions and can be used together.Do depositors receive fewer tokens when a Launch Pool is oversubscribed?No. The full base token allocation is still distributed pro-rata across all deposits. Oversubscription refunds excess quote tokens instead of cutting token allocations, so the effective price is capped at softCap / baseTokenAllocation.Does a soft cap change the Raydium graduation start price?Yes. When a Launch Pool is oversubscribed, the graduation start price is derived from the capped proceeds rather than the raw deposit total, so it matches the amount actually forwarded by SendQuoteTokenPercentage.GlossaryTermDefinitionLaunch PoolDeposit-based distribution where price is discovered at closeDeposit WindowTime period when users can deposit and withdraw SOLClaim WindowTime period when users can claim their proportional tokensEnd BehaviorAutomated action executed after deposit period endstriggerBehaviorsV2Instruction that processes end behaviors and routes fundsProportional DistributionToken allocation based on user's share of total depositsQuote TokenThe token users deposit (usually wSOL)Base TokenThe token being distributedSoft CapCeiling on the quote tokens a Launch Pool keeps; excess is refunded pro-rataMinimum Quote Token ThresholdFloor below which a Launch Pool fails and full refunds openOversubscriptionState where total deposits exceed the configured soft capFilled PortionThe part of a deposit that counts toward the soft cap and is kept by the launchExcess RefundReturn of the portion of a deposit above the soft cap, leaving token allocation intactNext StepsPresale - Fixed-price token saleUniform Price Auction - Bid-based token offeringLaunch a Token - End-to-end token launch guideMetaplex API - Query launch and token sale data via API","tokens":7289,"squid":"dotcat","role":"Tooling Spider","at":1791347490247,"hash":"f1fefa9a9136f5b3ff7b8de3717799e62e91fe61"}
{"url":"https://akash.network/docs/developers/deployment/akt/queries-and-transactions/","domain":"akash.network","title":"Queries & Transactions | Akash Network - Your Guide to Decentralized Cloud","text":"Queries & Transactions Query the chain and submit transactions for every Akash and Cosmos SDK module.\nakt query (alias akt q) and akt tx cover the complete Akash chain command set. Defaults for the node, chain ID, gas settings, and signing account come from the active context, so most commands need no flags at all.\n\nAvailable Modules\n\nGroupModules and commandsAkashdeployment, market, provider, cert, audit, escrow, oracle, bmeCosmos SDKauth, bank, staking, distribution, gov, authz, feegrant, slashing, vesting, upgrade, evidence, mint, paramsIBCibc, ibc-transferCosmWasmContract queries plus store, instantiate, execute, migrate, and administration transactionsChain utilitiesBlocks, transaction lookup, module addresses, broadcast, encode, and decodeSigning utilitiessign, sign-batch, multi-sign, and validate-signatures\n\nThe Positional Filter Argument\nAkash query commands take a positional filter argument instead of --owner/--dseq flags. The filter follows the resource hierarchy (owner/dseq/gseq/oseq/provider) with smart type detection: a bech32 address is an owner, a number is a dseq. When no owner is given, the context’s default account is used.\nState keywords are also positional: akt query deployment active lists active deployments, and identity and state combine as two positional arguments (akt query deployment 12345 active).\nTerminal window# List your deployments (owner defaults to context account)akt query deployment\n# Get a specific deployment by dseq (owner from context)akt query deployment 12345\n# List deployments for a specific ownerakt query deployment akash1abc...\n# Get a specific deployment by owner and dseqakt query deployment akash1abc.../12345\n# List active leases (positional state keyword)akt query market lease active\n# Leases for a specific deploymentakt query market lease 12345\n# Specific lease (owner from context)akt query market lease 12345/1/1/akash1prov...\n# Provider-perspective lease queryakt query market lease --by provider akash1prov...\nNote: When the identity pins down a single record, the state argument acts as a verification. The command fails if the record is in a different state instead of printing it.\nNote: The identity and filter flags from older Akash CLIs (--owner, --dseq, --gseq, --oseq, --state, --provider) are not available; use the positional form.\nIf the context has no default-account, owner-scoped commands require an explicit owner. They refuse locally instead of returning every account’s records. This is normal for console-api and monitoring-only contexts:\nTerminal window# Explicit owner works without a default accountakt query deployment akash1abc...\n# Console-owned deployments come from the Console API identityakt console deployment list\n\nPagination\nPaginated queries accept --limit, --offset, --page, --page-key, and --reverse where the underlying query supports them:\nTerminal window# Second page, 25 deployments per pageakt query deployment akash1abc... --limit 25 --page 2\n# Most recent records firstakt query deployment akash1abc... --limit 25 --reverse\nUse --count-total when you also need the total number of matching records. Unsupported pagination flags are refused rather than ignored.\n\nCommon Queries\nTerminal window# Check balancesakt query bank balances akash1abc...\n# Query a providerakt query provider akash1prov...\n# Certificates for an ownerakt query cert list akash1abc...\n# Query staking validatorsakt query staking validators\n# Query a WASM contractakt query wasm contract-state smart akash1contract... '{\"get_count\":{}}'\n# The q alias works everywhereakt q deployment 12345\n\nTransactions\nAll transaction commands accept --from, --gas, --gas-prices, --fees, --broadcast-mode, --yes, --dry-run, and other standard flags. Defaults come from the active context.\nTerminal window# Send tokensakt tx bank send alice akash1dest... 1000000uakt\n# Create a deploymentakt tx deployment create deployment.yaml\n# Close a deployment (positional dseq)akt tx deployment close 12345\n# Create a lease (positional dseq and provider; gseq/oseq default to 1)akt tx market lease create 12345 akash1prov...\n# Delegate to a validatorakt tx staking delegate akashvaloper1... 1000000uakt\n# Vote on a governance proposalakt tx gov vote 42 yes\n# Generate and publish a client certificateakt tx cert generate clientakt tx cert publish client\n# Convert between AKT and ACT (Burn-Mint-Equilibrium)akt tx bme mint-act 500000uaktakt tx bme burn-act 500000uact\nCoin inputs use explicit denominations. For example, 1 AKT is 1000000uakt. Pretty output scales micro-denominated values to readable AKT, mAKT, or uAKT values while JSON and YAML preserve machine-readable amounts.\nWith --gas auto, akt simulates the transaction to estimate the gas limit. Gas-price-derived fees use the selected network’s configured gas price as a floor. A lower invocation or environment value is raised to that floor, a higher value is preserved, and explicit --fees remains authoritative. See Gas prices and transaction fees.\nDirect akt tx commands require a keyring signing account. In a console-api context, use akt deploy, akt update, and akt close, or the matching akt console deployment command.\n\nOutput Formats\nTerminal window# Pretty table (default): color-coded states, bold identifiersakt query deployment\n# JSON, for scripts and pipesakt query deployment -o json\n# YAMLakt query bank balances akash1abc... -o yaml\n\nRelated Resources\n\nCommands Reference - Complete akt command reference\nDeployments - The one-command deployment workflow\nContexts & Configuration - Where transaction defaults come from\n\nEdit page on github\n Console Integration Monitor","tokens":1403,"squid":"spider-03","role":"Compute Spider","at":1791347493854,"hash":"ed3acdb0fef2ea5ec71f261e1dc0f03a22ea329f"}
{"url":"https://forum.across.to/t/what-the-token-does/52/6","domain":"forum.across.to","title":"What the token does? - Tokenomics (old) - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n Tokenomics (old)\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Nov 2021\n\n 6 / 26\n\n Nov 2021\n\n Apr 2022\n\n post by Kastormagic on Nov 12, 2021\n\n Kastormagic\n\n As we discusse about airdrops and « who gets what », I think we should talk about what the token does. That’s why I launch this conversation.\nAn example : Across token gives you a fees reduction when you use the bridge, xAcross (think xSushi) gives you voting power and a share of the fees.\nLet’s talk about it ! We want to hear you !\n\n 3\n\n 3\n\n 2\n\n 2\n\n read \n\n 4\n min\n\n post by heropunk.eth on Nov 17, 2021\n\n heropunk.eth\n\n AcrossIt is to build a DAO and become a community governance token, not to use it as gas, so I don’t agree with you, on the contrary AcrosdDAO, it will have more uses\n\n post by goldsnitch.eth on Nov 17, 2021\n\n goldsnitch.eth\n\n Need tokens to attract users\n\n post by fojo on Nov 17, 2021\n\n fojo\n\n Thanks for starting this discussion. To me this is the most important discussion to have with regards to tokenomics. There is no point in airdropping a token that does nothing. So first and foremost we should think about and decide on what the token will do.\nHere’s my 2 cents:\nGovernance: Establish a governance framework by granting discission making to across token holders (i.e. voting power)\nFees: Establish utility to the token (rather than it being just a governance token) by either giving fee reductions when using the bridge or a share of the fees generated by the bridge.\nSafety module: Staked across tokens will act as a collateral of last resort, to provide insurance against shortfall events. Stakers will get staking rewards. (see AAVE and DYDX for examples).\n\n post by DHACK on Nov 17, 2021\n\n DHACK\n\n Need tokens to attract users . I agree with it\n\n post by Robot on Nov 17, 2021\n\n Robot\n\n I think we should bump up the fees for using the bridge by a small % but if you stake X amount of the token then fees come back down to the original %, and if you stake even more you become eligible for profit share and all the usual stuff that comes with a govenunce token.\n\n post by fommes.eth on Nov 17, 2021\n\n fommes.eth\n\n Imho there is no point in holding the Across token for fees reduction. I imagine a tipical Across user will not bridge all the time, just looking at the general roadmap/POV that Eth mainnet is becoming solely/mostly just the settlement layer, already in the coming months ppl will use more frequent L2s and withdraw back sometimes.\n\n post by fommes.eth on Nov 17, 2021\n\n fommes.eth\n\n I propose the Across token to accrue fees for holders instead.\n\n post by Robot on Nov 17, 2021\n\n Robot\n\n fommes.eth\n\n Surely the more utility the better and i’m sure Across will have to go L2 to L2 in the end\n\n post by Sanguine on Nov 17, 2021\n\n Sanguine\n\n Kastormagic\n\n I think that token is needed for the DAO in the first place. It is not even necessary that it have economic value in the form of receiving % from commissions for the interaction of other users with the protocol. First of all, a token is a symbol. The more successful the project is, the more people want to be involved in it through the token.\n\n post by jotatotal on Nov 17, 2021\n\n jotatotal\n\n I would suggest that a part of the fees goes to the DAO treasury, and so increment value of DAO token. On the other hand I also consider that if the token is used to pay fees those fees get burned after that.\n\n post by fommes.eth on Nov 17, 2021\n\n fommes.eth\n\n Robot\n\n There are lots of L2 to L2 bridges already. Imho Across is unique in that sense and should aim to be the Go-To for fast+secure L1 withdrawals. There will always be a need for L1 withdrawals, even if Ethereum becomes mostly just an execution layer.\n\n post by Robot on Nov 17, 2021\n\n Robot\n\n Sanguine\n\n That’s not true go look at Ribbon finance and their token launch people bought and it non-stop gets called a useless govenunce token, Ribbon is very successful with about $200m TVL but the token price don’t reflect that\n\n post by Solace on Nov 17, 2021\n\n Solace\n\n Completely agree with /u/fojo’s post above - this is an important discussion regarding the token launch.\nWould the token be used strictly for governance, to pay out fees, or as a safety module? These do not necessarily have to mutually exclusive, and it’s possible that the token could incorporate all three - but as far as emission and distribution goes, it’s pretty important to make at least one a priority.\nIf choosing a governance route, liquidity incentives and a safety module could also be implemented at a later stage via a proposal. But this would remain subject to a vote, which could take some time to pass.\nOn the topic of liquidity incentives, these will likely remain temporary in order to bootstrap liquidity though there are plenty of examples of where artificially incentivizing usage has led to users with short-term outlooks farming these pools and draining the liquidity afterwards.\nAs far as using the token to incentivize usage goes, one approach could be to provide a gas fee rebate to users that bridge from L1 → L2 using the Arbitrum/optimism native bridge and bridge back to L1 using Across. This could be implemented similarly to Balancer’s gas fee rebate: [Proposal] Balancer Exchange Gas Reimbursement - Proposals - Balancer\nWe could get creative with some ways in order to incentivize usage rather than only incentivizing the LPs (as they will receive a fee of the transaction either way).\n\n post by Sanguine on Nov 17, 2021\n\n Sanguine\n\n Robot\n\n Maybe so. Indeed, in our time, the success of the project for the crowd is the endless rise in the price of the token. And if the price of a token does not grow infinitely, then they begin to call it “useless governance token”. But if the project starts to hype and the price rises, then it abruptly turns into an “incredibly useful governance token”.\n\n post by eqing.eth on Nov 21, 2021\n\n eqing.eth\n\n Kastormagic\n\n Tokens will attract some early users, which is necessary!At the initial stage of the project, it is necessary to attract users by token airdrop and distinguish real users.\n\n post by Alisa on Nov 22, 2021\n\n Alisa\n\n Acrosit is to establish a Dao and become a token of community governance. However, empowering and offsetting gas is a good suggestion, which can prevent members from throwing it out too early. However, it also has some disadvantages., if it is a gas, will it affect the development of community autonomy? But if it is only from the perspective of token, the more successful across is, the better the development of Dao will be, Of course, it will attract more people to participate\n\n 9 days later\n\n post by MrHeviDi on Dec 1, 2021\n\n MrHeviDi\n\n fommes.eth\n\n But there will be other protocals/bridges to move funds from L2 to L1, so Across needs to atract users to use Across and maybe to hold Across token. Maybe, like someone before montioned, having Across token will give you some fee reduction or something like that.\n\n 2 months later\n\n post by jotatotal on Jan 26, 2022\n\n jotatotal\n\n Solace\n\n What about giving the holders of the token , despite a fee reduction , a share of the fee according to their holdings?\n\n post by lawpanda.eth on Jan 26, 2022\n\n lawpanda.eth\n\n That would functionally be an ‘x’ token, like xSushi, dQuick, etc. On the legal end it creates regulatory questions because it resembles a security. But it is a more functional mechanism for facilitating adoption/use.\n\n Load more posts below","tokens":3349,"squid":"spider-09","role":"Bridge Spider","at":1791347498635,"hash":"37c1818bcc5d2f5365de5bae42d30d5f300eae69"}
{"url":"https://www.metaplex.com/docs/smart-contracts/genesis","domain":"metaplex.com","title":"Genesis — Solana Token Launchpad for Fair Launches & Token Sales | Metaplex","text":"Genesis is a Solana token launchpad and smart contract for Token Generation Events (TGE). Run a presale, fair launch, auction, or crowdsale with on-chain coordination for SPL token creation, token distribution, and fund collection. Choose Your PathNo-code launch? Use the Metaplex token launchpad to launch a token with no coding requiredBuild your own launchpad? Use the Genesis SDK to build a custom token launch platform or host a token sale on your own websiteNew to Genesis? Start with Getting Started to understand the flowReady to build? Jump to Launch Pool or PresaleWhat is Genesis?Genesis is a decentralized token launch platform that provides on-chain infrastructure for launching SPL tokens on Solana. Whether you need to run a token sale, presale, or fair launch, Genesis handles:Token creation with metadata (name, symbol, image)Fund collection from participants (SOL deposits)Distribution based on your chosen mechanismTime coordination for deposit and claim windowsThink of Genesis as a token launchpad smart contract that sits between you (the launcher) and your participants, ensuring fair, transparent, and automated token distribution — a modern on-chain alternative to centralized token sale platforms.Launch MechanismsGenesis supports three mechanisms that can be combined:MechanismPriceDistributionBest ForLaunch PoolDiscovered at closeProportional to depositFair launches, community tokens, crowdsalesPresaleFixed upfrontFirst-come-first-servedToken sales, known valuationUniform Price AuctionClearing priceHighest bidders winLarge raises, institutional interestWhich Should I Use?Launch Pool - You want organic price discovery and fair token distribution. Similar to a crowdsale, everyone who deposits gets tokens proportional to their share. No one gets sniped.Presale - You know your valuation and want predictable pricing. Set a fixed price and let participants buy until the cap is reached. In Genesis, \"presale\" means tokens are sold immediately before initial trading — buyers receive tokens directly, not a future right to receive them.Auction - You want competitive bidding from larger participants. A structured auction approach best suited for established projects with institutional interest.Core ConceptsLaunch TypesEvery Genesis launch has a type that represents the underlying mechanism:TypeDescriptionUse CaseLaunch Pool (launchpool)Proportional distribution with price discovery via a deposit windowFair launches, community tokens, crowdsalesPresale (presale)Fixed-price token sale at a predetermined rateToken sales, known valuationThe launch type is recorded on-chain in the Genesis Account by a backend crank after creation. Traders and aggregators can query the type programmatically via the JavaScript SDK (fetchGenesisAccountV2) or the Metaplex API (type field in REST responses).Genesis AccountThe central coordinator for your launch. When you initialize a Genesis Account, it:Creates your SPL token with metadataMints the total supply to escrowProvides the foundation for adding distribution bucketsBucketsModular components that define how tokens and funds flow:TypePurposeExamplesInflowCollect SOL from usersLaunch Pool, PresaleOutflowReceive funds for team/treasuryUnlocked BucketTime ConditionsEvery bucket has time windows that control when actions are allowed:Deposit window - When users can deposit SOLClaim window - When users can claim tokensProtocol FeesGenesis fees depend on the launch type and on whether the launch has graduated to its Raydium CPMM pool. Launch pool and presale CPMM fees also depend on whether the launch enables creator rewards. Bonding curve CPMM pools always include creator rewards.Bonding CurveInstructionSolanaProtocol fee0.50%Creator revenue0.60%Bonding Curve CPMMInstructionSolanaProtocol fee0.40%Creator revenue0.60%LP fees0.21%Raydium fee0.04%Launch PoolInstructionSolanaUser deposit fee0%User withdraw fee0%Creator withdraw fee5%** This fee only applies when creators withdraw liquidityLaunch Pool CPMM (Creator Rewards Off)InstructionSolanaLiquidity requirement20%*Protocol fee0.40%LP fees0.42%Raydium fee0.08%* 1 year lock with quarterly unlockLaunch Pool CPMM (Creator Rewards On)InstructionSolanaLiquidity requirement20%*Protocol fee0.40%Creator revenue0.60%LP fees0.21%Raydium fee0.04%* 1 year lock with quarterly unlockPresaleInstructionSolanaUser deposit fee0%Creator withdraw fee5%** This fee only applies when creators withdraw liquidityPresale CPMM (Creator Rewards Off)InstructionSolanaLiquidity requirement20%*Protocol fee0.40%LP fees0.42%Raydium fee0.08%* 1 year lock with quarterly unlockPresale CPMM (Creator Rewards On)InstructionSolanaLiquidity requirement20%*Protocol fee0.40%Creator revenue0.60%LP fees0.21%Raydium fee0.04%* 1 year lock with quarterly unlockProgram InformationNetworkProgram IDMainnetGNS1S5J5AspKXgpjz6SvKL66kPaKWAhaGRhCqPRxii2BDevnetGNS1S5J5AspKXgpjz6SvKL66kPaKWAhaGRhCqPRxii2BSecurityAfter your launch completes, revoke token authorities to signal that no additional tokens can be minted:Mint authority - Revoke to prevent new token mintingFreeze authority - Revoke to prevent token freezingSee Getting Started for details on authority management.FAQWhat is Genesis?Genesis is a Metaplex smart contract for Token Generation Events (TGE) on Solana. It provides on-chain infrastructure for presales, launch pools, and auctions with coordinated token creation and distribution.What launch mechanisms does Genesis support?Genesis supports three mechanisms: Launch Pool (proportional distribution with price discovery), Presale (fixed price), and Uniform Price Auction (bid-based with clearing price).How much does it cost to use Genesis?Genesis charges a protocol fee on bonding curve swaps and on Raydium CPMM trading after graduation, plus a fee when the creator withdraws launch pool or presale proceeds. Launch pool and presale CPMM fees also depend on whether the launch enables creator rewards. See Protocol Fees for the current breakdown.Can I revoke token authorities after launch?Yes. Genesis provides the revokeV2 instruction to permanently revoke mint and/or freeze authority.What's the difference between Launch Pool and Presale?Presale has a fixed price set upfront. Launch Pool discovers price organically—more deposits means higher implied price per token, with proportional distribution to all participants.Can I combine multiple launch mechanisms?Yes. Genesis uses a bucket system where you can add multiple inflow buckets and configure outflow buckets for treasury or vesting.GlossaryTermDefinitionGenesis AccountCentral coordinator that creates the token and manages all bucketsBucketModular component that defines token/SOL flowInflow BucketBucket that collects SOL from usersOutflow BucketBucket that receives funds via end behaviorsLaunch PoolDeposit-based distribution where price is discovered at closePresaleFixed-price sale at a predetermined rateQuote TokenThe token users deposit (usually wSOL)Launch TypeThe underlying mechanism of a launch: launchpool or presale. Set on-chain by a backend crank after creationBase TokenThe token being launched and distributedNext StepsGetting Started - Understand the Genesis flowJavaScript SDK - Installation and setupLaunch Pool - Build a proportional distribution launchPresale - Build a fixed-price sale","tokens":1825,"squid":"dotcat","role":"Tooling Spider","at":1791347500149,"hash":"cedab05c0ee310a3a0647465cd3636320646f283"}
{"url":"https://akash.network/docs/developers/deployment/akt/configuration/","domain":"akash.network","title":"Contexts & Configuration | Akash Network - Your Guide to Decentralized Cloud","text":"Contexts & Configuration Configure akt with contexts, networks, and keys.\n\nPrerequisite: Install akt first. See the installation guide.\n\nAfter initial context configuration, most commands need no connection or signer flags. This guide covers the settings that supply those defaults.\n\nHow Configuration Works\nakt stores its configuration in a YAML file at ~/.config/akt/config.yaml, built from three building blocks:\n\nContexts - A named combination of a network, an authentication method, and a default account. One context is active at a time, and every command runs against it.\nNetworks - Shared network definitions (chain ID, RPC endpoints, gas settings). Built-in templates exist for mainnet, testnet, and sandbox; the sandbox template targets the live sandbox-2 network. Multiple contexts can reference the same network.\nKeyrings - Named key stores shared by one or more contexts. Each keyring selects an os, file, test, kwallet, pass, or memory backend.\n\nContexts use one of two authentication methods:\n\nAuth MethodSigningBest ForkeyringLocal keys, direct chain transactionsFull control, all transaction typesconsole-apiAkash Console managed wallet, no local keysDeployments funded in USD, no key management\nConfig changes are picked up live. There is no need to restart anything after editing config.yaml.\n\nContext Management\nTerminal window# List all contextsakt context list\n# Create a context using an existing networkakt context create prod --network mainnet --default-account alice --set-current\n# Switch active contextakt context use staging\n# Show active context details (resolved network, keyring, store path, capabilities)akt context show\n# Edit a contextakt context edit prod --default-account bob\n# Create a Console API context (managed wallet, no local keys)akt context create console --network mainnet --auth-method console-api --set-current\n# Rename or deleteakt context rename prod productionakt context delete staging --yes\n\nAccounts and Account-Free Contexts\nSet a default account when you create a keyring context, or add one later:\nTerminal windowakt context edit mainnet --default-account aliceakt context show\nThe value can be a key name or an Akash address. When it is a key name, akt resolves it to the full address before running owner-scoped queries.\nA console-api context intentionally does not need a keyring or default-account. The API key identifies the Console account, and the Console managed wallet signs and pays for akt deploy, akt update, akt close, and akt console operations.\nIf that context also has a network, account-independent chain queries such as akt query staking pool still work. An owner-scoped query cannot guess an owner, so a bare command such as akt query deployment refuses instead of returning every deployment on the network. Use the Console-owned view or provide an address explicitly:\nTerminal windowakt console deployment listakt query deployment akash1abc...\nA network-less console-api context can run Console commands only. Attach a network before using chain queries, the monitor, or public provider discovery. Direct akt tx commands need a keyring context and local signing account.\n\nNetwork Management\nTerminal window# Create from built-in templateakt context network create mainnet --template mainnet\n# Create custom networkakt context network create local --chain-id localnet-1 --rpc http://localhost:26657\n# List networks and which contexts use themakt context network list\n# Show full network detailsakt context network show mainnet\n# Edit network (affects all contexts using it)akt context network edit mainnet --gas-prices 0.025uakt\n\nGas prices and transaction fees\n--gas auto estimates the gas limit. The transaction fee also needs a gas price, and that price comes from the selected network’s policy.\nDuring first-run setup, akt stores each Akash registry network’s high_gas_price. The built-in templates currently use 0.025uakt. When a transaction derives its fee from gas prices, the configured network price is a floor:\n\nA lower --gas-prices or AKT_GAS_PRICES value is raised to the network floor.\nA higher value is preserved.\nAn explicit --fees value is authoritative and does not use gas prices.\nOnline, offline, generate-only, and dry-run transaction construction use the same rule.\n\nakt does not copy one RPC node’s local minimum and does not retry a rejected transaction with a guessed fee.\nIf a context created with an older release still stores 0.0025uakt, update the network once:\nTerminal windowakt context network show mainnetakt context network edit mainnet --gas-prices 0.025uakt\nThe edit affects every context that shares that network. Fork it when one context needs a separate policy:\nTerminal windowakt context edit prod --fork-network --gas-prices 0.04uakt\n\nKeyring management\nKeyrings define where local signing keys live. The os backend uses the platform credential store. akt refuses to open it when the host has no supported credential store instead of switching to another backend.\nTerminal window# List keyring definitionsakt context keyring list\n# Create a file-backed keyring for a headless hostakt context keyring create headless file\n# Change an existing keyring backendakt context keyring set headless os\nUse --keyring <name> with akt context create, or set it later with akt context edit <name> --keyring <name>.\n\nKey Management\nKeys live in the active context’s keyring:\nTerminal window# Add a new keyakt context keys add alice\n# Scripted creation without printing a mnemonicakt context keys add ci-deployer --yes --no-backup\n# Recover from mnemonicakt context keys add alice --recover\n# List keys in the current context's keyringakt context keys list\n# Show key detailsakt context keys show alice\n# Print only the bech32 address (useful for scripting)akt context keys show alice --address\n# Export / importakt context keys export alice > alice.keyakt context keys import alice-backup alice.key\n# Parse an address between formatsakt context keys parse akash1abc...\n--yes is accepted for Cosmos CLI compatibility. It never overwrites an existing key. Unless you pass --no-backup or recover an existing key, save the printed mnemonic because it is the only way to recover the account.\n\nCapability Gating\nThe active context’s configuration determines what akt can actually do:\n\nA network with at least one RPC endpoint enables chain queries, chain transactions, and provider operations, gating the query, tx, monitor, and provider command groups.\nA resolvable Console API key enables the Console-backed commands.\n\nakt context show ends with a Capabilities block reporting the resolved feature set, naming the remedy for anything the configuration cannot do:\n Capabilities: Chain queries: available Chain transactions: available Provider gateway: available Console API: unavailable - run akt console login\nCommands outside that set are marked [unavailable] in help and fail fast with an explanation instead of failing somewhere inside a network call. Presentation is configurable via defaults.command-gating in config.yaml:\n\nModeBehaviordimDefault. Unavailable commands stay listed, marked [unavailable], and fail fast with an explanation.hideUnavailable commands are removed from help listings; direct invocation still fails fast.offNo gating; commands fail wherever the missing transport is first touched.\n~/.config/akt/config.yamldefaults: command-gating: dim\nNote: Per-invocation overrides that carry their own connection details (--node, --console-api-key, a positional akt monitor endpoint) grant the capability they supply, so gating never rejects a command that can connect on its own.\n\nEnvironment Variables\n\nVariableDescriptionAKT_HOMEHome directory for config, credentials, keyrings, and stateAKT_CONTEXTActive context for this invocationAKT_CHAIN_IDChain ID from the selected networkAKT_NODEFirst RPC endpoint from the selected networkAKT_GRPC_ADDRFirst gRPC endpoint from the selected networkAKT_FROMDefault transaction accountAKT_KEYRING_BACKENDKeyring backend for this invocationAKT_KEYRING_DIRKeyring directory for this invocationAKT_GASGas limit or autoAKT_GAS_PRICESCandidate gas prices, subject to the selected network floorAKT_GAS_ADJUSTMENTMultiplier applied to simulated gasAKT_FEESFixed transaction feesAKT_BROADCAST_MODETransaction broadcast modeAKT_OUTPUTDefault output formatAKT_CONSOLE_API_KEYConsole API key, overriding the stored context credential\nThe equivalent global flags --home and --context take precedence over the environment variables.\n\nOutput Formats\nCommands support --output (-o) with pretty formatting by default:\nTerminal window# Pretty table (default): color-coded states, bold identifiersakt query deployment\n# JSON, for scripts and pipesakt query deployment -o json\n# YAMLakt query bank balances akash1abc... -o yaml\nPretty output always prints complete addresses. Coin values use readable base, milli, or micro units. JSON and YAML preserve stable machine-readable fields and never include the human Next: guidance written to stderr after successful Console actions.\n\nAction Log\nEvery mutating operation, including transactions, workflows, provider calls, context changes, key management, and Console actions, is recorded in a per-context append-only log. Read-only queries are not recorded. Key export is the exception because moving private key material is a security event. The log never contains mnemonics, passphrases, key material, or API keys.\nTerminal window# View recent actions for the current context (newest first)akt context log\n# Filter by type and limitakt context log --type tx --limit 10\n# Follow every step of one workflow runakt context log --workflow-id 9f2c1ab34d55e017\n# Show actions since a duration or timestampakt context log --since 1hakt context log --since 2026-01-01\nThe log rotates automatically at 10 MB and keeps up to five rotated files.\n\nNext Steps\n\nDeployments - Deploy your first application\nConsole integration - Set up a managed-wallet context\nCommands reference - Review the main akt command groups\n\nEdit page on github\n Installation Deployments","tokens":2509,"squid":"spider-03","role":"Compute Spider","at":1791347503771,"hash":"d250ef7391390ef8fb32f72a56e739ec7e9a5a86"}
{"url":"https://forum.across.to/t/what-the-token-does/52/8","domain":"forum.across.to","title":"What the token does? - Tokenomics (old) - Across Protocol","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Nov 2021\n\n 8 / 26\n\n Nov 2021\n\n Apr 2022\n\n Load more posts above\n\n post by goldsnitch.eth on Nov 17, 2021\n\n goldsnitch.eth\n\n Need tokens to attract users\n\n post by fojo on Nov 17, 2021\n\n fojo\n\n Thanks for starting this discussion. To me this is the most important discussion to have with regards to tokenomics. There is no point in airdropping a token that does nothing. So first and foremost we should think about and decide on what the token will do.\nHere’s my 2 cents:\nGovernance: Establish a governance framework by granting discission making to across token holders (i.e. voting power)\nFees: Establish utility to the token (rather than it being just a governance token) by either giving fee reductions when using the bridge or a share of the fees generated by the bridge.\nSafety module: Staked across tokens will act as a collateral of last resort, to provide insurance against shortfall events. Stakers will get staking rewards. (see AAVE and DYDX for examples).\n\n post by DHACK on Nov 17, 2021\n\n DHACK\n\n Need tokens to attract users . I agree with it\n\n post by Robot on Nov 17, 2021\n\n Robot\n\n I think we should bump up the fees for using the bridge by a small % but if you stake X amount of the token then fees come back down to the original %, and if you stake even more you become eligible for profit share and all the usual stuff that comes with a govenunce token.\n\n post by fommes.eth on Nov 17, 2021\n\n fommes.eth\n\n Imho there is no point in holding the Across token for fees reduction. I imagine a tipical Across user will not bridge all the time, just looking at the general roadmap/POV that Eth mainnet is becoming solely/mostly just the settlement layer, already in the coming months ppl will use more frequent L2s and withdraw back sometimes.\n\n post by fommes.eth on Nov 17, 2021\n\n fommes.eth\n\n I propose the Across token to accrue fees for holders instead.\n\n post by Robot on Nov 17, 2021\n\n Robot\n\n fommes.eth\n\n Surely the more utility the better and i’m sure Across will have to go L2 to L2 in the end\n\n post by Sanguine on Nov 17, 2021\n\n Sanguine\n\n Kastormagic\n\n I think that token is needed for the DAO in the first place. It is not even necessary that it have economic value in the form of receiving % from commissions for the interaction of other users with the protocol. First of all, a token is a symbol. The more successful the project is, the more people want to be involved in it through the token.\n\n post by jotatotal on Nov 17, 2021\n\n jotatotal\n\n I would suggest that a part of the fees goes to the DAO treasury, and so increment value of DAO token. On the other hand I also consider that if the token is used to pay fees those fees get burned after that.\n\n post by fommes.eth on Nov 17, 2021\n\n fommes.eth\n\n Robot\n\n There are lots of L2 to L2 bridges already. Imho Across is unique in that sense and should aim to be the Go-To for fast+secure L1 withdrawals. There will always be a need for L1 withdrawals, even if Ethereum becomes mostly just an execution layer.\n\n post by Robot on Nov 17, 2021\n\n Robot\n\n Sanguine\n\n That’s not true go look at Ribbon finance and their token launch people bought and it non-stop gets called a useless govenunce token, Ribbon is very successful with about $200m TVL but the token price don’t reflect that\n\n post by Solace on Nov 17, 2021\n\n Solace\n\n Completely agree with /u/fojo’s post above - this is an important discussion regarding the token launch.\nWould the token be used strictly for governance, to pay out fees, or as a safety module? These do not necessarily have to mutually exclusive, and it’s possible that the token could incorporate all three - but as far as emission and distribution goes, it’s pretty important to make at least one a priority.\nIf choosing a governance route, liquidity incentives and a safety module could also be implemented at a later stage via a proposal. But this would remain subject to a vote, which could take some time to pass.\nOn the topic of liquidity incentives, these will likely remain temporary in order to bootstrap liquidity though there are plenty of examples of where artificially incentivizing usage has led to users with short-term outlooks farming these pools and draining the liquidity afterwards.\nAs far as using the token to incentivize usage goes, one approach could be to provide a gas fee rebate to users that bridge from L1 → L2 using the Arbitrum/optimism native bridge and bridge back to L1 using Across. This could be implemented similarly to Balancer’s gas fee rebate: [Proposal] Balancer Exchange Gas Reimbursement - Proposals - Balancer\nWe could get creative with some ways in order to incentivize usage rather than only incentivizing the LPs (as they will receive a fee of the transaction either way).\n\n post by Sanguine on Nov 17, 2021\n\n Sanguine\n\n Robot\n\n Maybe so. Indeed, in our time, the success of the project for the crowd is the endless rise in the price of the token. And if the price of a token does not grow infinitely, then they begin to call it “useless governance token”. But if the project starts to hype and the price rises, then it abruptly turns into an “incredibly useful governance token”.\n\n post by eqing.eth on Nov 21, 2021\n\n eqing.eth\n\n Kastormagic\n\n Tokens will attract some early users, which is necessary!At the initial stage of the project, it is necessary to attract users by token airdrop and distinguish real users.\n\n post by Alisa on Nov 22, 2021\n\n Alisa\n\n Acrosit is to establish a Dao and become a token of community governance. However, empowering and offsetting gas is a good suggestion, which can prevent members from throwing it out too early. However, it also has some disadvantages., if it is a gas, will it affect the development of community autonomy? But if it is only from the perspective of token, the more successful across is, the better the development of Dao will be, Of course, it will attract more people to participate\n\n 9 days later\n\n post by MrHeviDi on Dec 1, 2021\n\n MrHeviDi\n\n fommes.eth\n\n But there will be other protocals/bridges to move funds from L2 to L1, so Across needs to atract users to use Across and maybe to hold Across token. Maybe, like someone before montioned, having Across token will give you some fee reduction or something like that.\n\n 2 months later\n\n post by jotatotal on Jan 26, 2022\n\n jotatotal\n\n Solace\n\n What about giving the holders of the token , despite a fee reduction , a share of the fee according to their holdings?\n\n post by lawpanda.eth on Jan 26, 2022\n\n lawpanda.eth\n\n That would functionally be an ‘x’ token, like xSushi, dQuick, etc. On the legal end it creates regulatory questions because it resembles a security. But it is a more functional mechanism for facilitating adoption/use.\n\n 2 months later\n\n post by J.Berg on Mar 18, 2022\n\n J.Berg\n\n Creating a token enables the DAO to have an asset (without investing) that can be used to fund projects/guilds for effort the DAO needs (both maintenance and major initiatives), as well as contribute to internal DAO economics.\n–Paying core team members for their efforts\n–Paying for work done by Guilds and their squads\n–Internal DAO markets and trade\n–Bounties\nWill the Across token be used strictly for governance? or will it be used as money? or both?\nWould it be a monetary asset and a governance token to be used to fund and vote? Some DAO’s treat their governance token as ONLY that, and it actively drives down it’s valuation.\nIf its money then the DAO as an organization has the challenges of both a startup and an emerging digital nationstate in that we have to find and create revenue streams and manage costs, as well as drive the use and acceptance of our denomination both internally and externally.\nI think long term will be based on the size of the treasury it controls and the useful things you can do with it. As a result, I think the focus should be on activities that generate on-chain revenue for the DAO and ways to make the token useful stake it, collateral, ect.\nHow to pay contributors is definitely an important factor to consider. Without contributors, we won’t be able to do any of the above. Part of me feels that if your contributing, it should be because you believe in the DAO long term and shouldn’t expect an immediate monetary reward. The other part of me thinks that contributor renumeration is something that needs to be painstakingly thought out to retain talent and pay our people\n\n post by heybeo on Mar 22, 2022\n\n heybeo\n\n It would be nice to use bridges on the same platform as well as to create a nice dex.\nTrading pairs, for example acx-uma, are used as fees and distributed to token holders.\nacx-x\nacx-y\nacx-z\nJust a simple idea as liquidity addition commissions are burned\n\n Load more posts below","tokens":2192,"squid":"spider-09","role":"Bridge Spider","at":1791347508884,"hash":"725a4431a8e938d25629f21a7f4f19dfe40f26a3"}
{"url":"https://akash.network/docs/developers/deployment/akt/deployments/","domain":"akash.network","title":"Deploy with akt | Akash Network - Your Guide to Decentralized Cloud","text":"Deploy with akt Deploy applications on Akash with a single command.\nThe workflow commands akt deploy, akt update, and akt close orchestrate the full deployment lifecycle (create, bid selection, lease, and manifest), routing each step through the active context’s auth method: local signing for keyring contexts, the Console API for console-api contexts.\n\nPrerequisites\nBefore deploying, ensure you have:\n\nakt installed and a context configured (installation guide)\nFor keyring contexts: a funded account for the live chain deposit and transaction fees. akt queries the current deployment minimum when the deposit is auto.\nFor console-api contexts: a Console API key (Console integration) and an explicit USD deposit of at least $0.50.\n\nAuthor an SDL\nakt sdl scaffolds, generates, and validates deployment SDLs entirely locally, with no context, no key, and no RPC endpoint needed.\nTerminal window# List the built-in scaffolds and the flags each honorsakt sdl scaffolds\n# Generate a web service SDLakt sdl init web --image nginx:1.27 > deploy.yaml\n# GPU workload with a specific modelakt sdl init gpu --gpu-model h100 --image myorg/model:1.0 > gpu.yaml\n# Generate and validate without touching diskakt sdl init web --image nginx:1.27 | akt sdl validate -\n# Validate a file (exit 0 valid, exit 1 invalid)akt sdl validate deploy.yaml\nBuilt-in scaffolds: web, gpu, multi-service, and ip-lease. Generation flags (--image, --cpu, --memory, --gpu-model, --price, …) have per-scaffold defaults, so the zero-flag invocation always produces valid output.\nA valid document prints valid: 1 service(s), 1 group(s), 0 warning(s). Problems are listed with a hint:\ninvalid: 1 error(s), 1 warning(s) error: services/web/image: image \"nginx\" has no tag; pin an explicit version for reproducible deployments hint: use \"nginx:<version>\" instead of an untagged image warning: profiles/placement/dcloud/pricing: pricing denom \"uakt\" does not match the default deposit; use \"uact\" on either rail or pass a matching explicit uakt deposit on chain\nLint rules:\n\nAn unpinned image is an error: every service image must carry an explicit tag or @sha256: digest. Untagged images and :latest are rejected as non-reproducible.\nFor pricing, uact is canonical on both rails. uakt produces a warning because it only works on chain with an explicitly matching --deposit <amount>uakt. Any other denomination is an error.\n\nSee the SDL Reference for the full configuration syntax.\n\nDeploy\nRun the full deployment lifecycle (create the deployment, wait for bids, select a provider, create the lease, and send the manifest) with one command:\nTerminal windowakt deploy deploy.yaml\nIn interactive mode (the default), akt shows a per-step progress display and prompts you to select a bid from a provider/price table.\nFlags:\n\n--deposit - Initial deposit. Use auto for the live chain minimum, an explicit coin with its denomination on the chain rail, or 5, 5usd, $5, or 5.50usd on the Console rail. The default is auto, but Console contexts require an explicit USD amount.\n--bid-timeout - Maximum time to wait for bids (default: 5m)\n--bid-select - Bid selection mode: interactive (default), cheapest, or provider=<addr>\n--ready-timeout - Maximum time to wait for deployed services to become ready (default: 2m)\n--no-wait-active - Return after manifest submission without waiting for readiness\n--yes (-y) - Skip confirmation prompts\n--dry-run - Show the execution plan without broadcasting transactions\n\nExample:\nTerminal window# Deploy, automatically accepting the cheapest bidakt deploy deploy.yaml --bid-select cheapest --yes\nOn console-api contexts, provider manifest steps are skipped because the Console submits manifests internally.\nBefore any transaction is broadcast, --dry-run resolves the signer and the deposit that execution would use. A chain auto dry-run queries the live deployment minimum. It fails if that value cannot be resolved instead of printing a fallback amount.\nAfter manifest submission, a successful deploy waits for service readiness and prints the deployment owner, dseq, selected provider, bid price, live service URIs, readiness result, Console link when applicable, auto-top-up state, and follow-up commands. Use --no-wait-active for automation that only needs manifest acceptance.\nIf a deploy fails after creating paid chain state, akt prints the dseq, provider, escrow risk, and exact retry and close commands. It does not automatically close the deployment. Retry the failed step, or run the printed akt close <dseq> command if you are abandoning it.\n\nAutomate in CI/CD\nFor scripting, --output jsonl replaces the interactive display with one JSON object per line, one line per step (create-deployment, wait-for-bids, select-bid, create-lease, send-manifest, display-result):\nTerminal windowakt deploy deploy.yaml --bid-select cheapest --yes -o jsonl\n{\"workflow\":\"deploy\",\"id\":\"wf_a1b2c3\",\"step\":\"create-deployment\",\"result\":\"completed\",\"errors\":[],\"txs\":[{\"hash\":\"ABCD...\",\"height\":12345,\"gas_used\":150000,\"code\":0}]}{\"workflow\":\"deploy\",\"id\":\"wf_a1b2c3\",\"step\":\"wait-for-bids\",\"result\":\"completed\",\"errors\":[],\"txs\":[]}{\"workflow\":\"deploy\",\"id\":\"wf_a1b2c3\",\"step\":\"create-lease\",\"result\":\"completed\",\"errors\":[],\"txs\":[{\"hash\":\"EFGH...\",\"height\":12350,\"gas_used\":120000,\"code\":0}],\"outputs\":{\"dseq\":\"12345\",\"provider\":\"akash1provider...\"}}{\"workflow\":\"deploy\",\"id\":\"wf_a1b2c3\",\"step\":\"display-result\",\"result\":\"completed\",\"errors\":[],\"txs\":[],\"outputs\":{\"dseq\":\"12345\",\"provider\":\"akash1provider...\",\"uris\":{\"web\":[\"https://example.test\"]},\"ready\":true}}\nParse with jq:\nTerminal window# Extract the deployment transaction hashakt deploy deploy.yaml --bid-select cheapest --yes -o jsonl \\ | jq -r 'select(.step == \"create-deployment\") | .txs[0].hash'\n\nUpdate a Deployment\nUpdate the deployment on-chain from a modified SDL file:\nTerminal windowakt update deploy.yaml 12345\nImage and environment changes usually keep the current leases. Changing the resource profile can close leases and reopen bidding, so review the effect before confirming.\nOn the chain rail, akt update submits the update and sends the revised manifest to every provider with an active lease. It attempts every provider before reporting an error, and the manifest step is safe to retry. On the Console rail, the Console API handles the manifest update.\n\nClose a Deployment\nClose the deployment and return the remaining escrow balance:\nTerminal windowakt close 12345\nClosing a deployment is irreversible. akt checks the current state first; an already-closed or missing deployment exits nonzero and records the failed action instead of reporting another successful close.\n\nConfidential compute deployments\nakt supports SDLs whose placement requirements include confidential compute. Set params.tee to cpu-gpu in the SDL, then deploy it through the normal workflow. akt preserves the TEE placement requirement and manifest parameters so a compatible provider schedules the attestation sidecar.\nAfter the lease becomes active, request a fresh quote:\nTerminal windowakt provider lease-attestation 12345\nThe command authenticates the provider transport and verifies that the report echoes a fresh nonce. It reports fields such as tee_platform, nonce_verified, and mock_report. It does not yet verify the hardware evidence signature, endorsement chain, or measurement policy, so treat it as a freshness and transport-authentication check rather than full remote attestation.\n\nMonitor a Deployment\nCheck on-chain state with the positional query filters:\nTerminal window# List your deployments (owner defaults to the context account)akt query deployment\n# Get a specific deploymentakt query deployment 12345\n# Leases for a deploymentakt query market lease 12345\nReach the provider gateway for live status, logs, and a shell:\nTerminal window# Live lease deployment status; provider resolves from the active leaseakt provider lease-status 12345\n# Stream container logsakt provider lease-logs 12345 --follow\n# Stream Kubernetes eventsakt provider lease-events 12345 --follow\n# Open an interactive shell in a containerakt provider lease-shell --dseq 12345 --service web -- /bin/sh\nakt resolves a single active provider lease from the dseq, then resolves the gateway URL from that provider’s on-chain record. Pass --provider when several active leases make the choice ambiguous. --provider-url overrides the gateway URL for diagnostics; it is not a blockchain RPC URL.\nNote: On console-api contexts, use the equivalent akt console logs, akt console events, akt console status, and akt console shell commands. See Console Integration.\n\nLocal Deployment Store\nakt keeps a per-context local store of your deployments for fast, offline-capable listings:\nTerminal window# Display local store informationakt store status\n# Reconcile tracked accounts with current chain stateakt store sync\n# Export the local store to YAML or JSONakt store export > deployments-backup.yaml\n# Import records from a previously exported fileakt store import deployments-backup.yaml\nakt store export is a backup and inspection format. It is not an SDL and cannot be passed to akt deploy.\n\nNext Steps\n\nConsole integration - Deploy with the managed wallet, funded in USD\nQueries and transactions - Work with the chain directly\nSDL reference - Learn SDL configuration\nSDL examples - Browse deployment examples\n\nNeed help? Join Discord #developers channel! \nEdit page on github\n Configuration Console Integration","tokens":2357,"squid":"spider-03","role":"Compute Spider","at":1791347513749,"hash":"db2771adf2beb5a94e0e7e766768bb40e4bef954"}
{"url":"https://forum.across.to/t/what-the-token-does/52/11","domain":"forum.across.to","title":"What the token does? - Tokenomics (old) - Across Protocol","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Nov 2021\n\n 11 / 26\n\n Nov 2021\n\n Apr 2022\n\n Load more posts above\n\n post by Robot on Nov 17, 2021\n\n Robot\n\n I think we should bump up the fees for using the bridge by a small % but if you stake X amount of the token then fees come back down to the original %, and if you stake even more you become eligible for profit share and all the usual stuff that comes with a govenunce token.\n\n post by fommes.eth on Nov 17, 2021\n\n fommes.eth\n\n Imho there is no point in holding the Across token for fees reduction. I imagine a tipical Across user will not bridge all the time, just looking at the general roadmap/POV that Eth mainnet is becoming solely/mostly just the settlement layer, already in the coming months ppl will use more frequent L2s and withdraw back sometimes.\n\n post by fommes.eth on Nov 17, 2021\n\n fommes.eth\n\n I propose the Across token to accrue fees for holders instead.\n\n post by Robot on Nov 17, 2021\n\n Robot\n\n fommes.eth\n\n Surely the more utility the better and i’m sure Across will have to go L2 to L2 in the end\n\n post by Sanguine on Nov 17, 2021\n\n Sanguine\n\n Kastormagic\n\n I think that token is needed for the DAO in the first place. It is not even necessary that it have economic value in the form of receiving % from commissions for the interaction of other users with the protocol. First of all, a token is a symbol. The more successful the project is, the more people want to be involved in it through the token.\n\n post by jotatotal on Nov 17, 2021\n\n jotatotal\n\n I would suggest that a part of the fees goes to the DAO treasury, and so increment value of DAO token. On the other hand I also consider that if the token is used to pay fees those fees get burned after that.\n\n post by fommes.eth on Nov 17, 2021\n\n fommes.eth\n\n Robot\n\n There are lots of L2 to L2 bridges already. Imho Across is unique in that sense and should aim to be the Go-To for fast+secure L1 withdrawals. There will always be a need for L1 withdrawals, even if Ethereum becomes mostly just an execution layer.\n\n post by Robot on Nov 17, 2021\n\n Robot\n\n Sanguine\n\n That’s not true go look at Ribbon finance and their token launch people bought and it non-stop gets called a useless govenunce token, Ribbon is very successful with about $200m TVL but the token price don’t reflect that\n\n post by Solace on Nov 17, 2021\n\n Solace\n\n Completely agree with /u/fojo’s post above - this is an important discussion regarding the token launch.\nWould the token be used strictly for governance, to pay out fees, or as a safety module? These do not necessarily have to mutually exclusive, and it’s possible that the token could incorporate all three - but as far as emission and distribution goes, it’s pretty important to make at least one a priority.\nIf choosing a governance route, liquidity incentives and a safety module could also be implemented at a later stage via a proposal. But this would remain subject to a vote, which could take some time to pass.\nOn the topic of liquidity incentives, these will likely remain temporary in order to bootstrap liquidity though there are plenty of examples of where artificially incentivizing usage has led to users with short-term outlooks farming these pools and draining the liquidity afterwards.\nAs far as using the token to incentivize usage goes, one approach could be to provide a gas fee rebate to users that bridge from L1 → L2 using the Arbitrum/optimism native bridge and bridge back to L1 using Across. This could be implemented similarly to Balancer’s gas fee rebate: [Proposal] Balancer Exchange Gas Reimbursement - Proposals - Balancer\nWe could get creative with some ways in order to incentivize usage rather than only incentivizing the LPs (as they will receive a fee of the transaction either way).\n\n post by Sanguine on Nov 17, 2021\n\n Sanguine\n\n Robot\n\n Maybe so. Indeed, in our time, the success of the project for the crowd is the endless rise in the price of the token. And if the price of a token does not grow infinitely, then they begin to call it “useless governance token”. But if the project starts to hype and the price rises, then it abruptly turns into an “incredibly useful governance token”.\n\n post by eqing.eth on Nov 21, 2021\n\n eqing.eth\n\n Kastormagic\n\n Tokens will attract some early users, which is necessary!At the initial stage of the project, it is necessary to attract users by token airdrop and distinguish real users.\n\n post by Alisa on Nov 22, 2021\n\n Alisa\n\n Acrosit is to establish a Dao and become a token of community governance. However, empowering and offsetting gas is a good suggestion, which can prevent members from throwing it out too early. However, it also has some disadvantages., if it is a gas, will it affect the development of community autonomy? But if it is only from the perspective of token, the more successful across is, the better the development of Dao will be, Of course, it will attract more people to participate\n\n 9 days later\n\n post by MrHeviDi on Dec 1, 2021\n\n MrHeviDi\n\n fommes.eth\n\n But there will be other protocals/bridges to move funds from L2 to L1, so Across needs to atract users to use Across and maybe to hold Across token. Maybe, like someone before montioned, having Across token will give you some fee reduction or something like that.\n\n 2 months later\n\n post by jotatotal on Jan 26, 2022\n\n jotatotal\n\n Solace\n\n What about giving the holders of the token , despite a fee reduction , a share of the fee according to their holdings?\n\n post by lawpanda.eth on Jan 26, 2022\n\n lawpanda.eth\n\n That would functionally be an ‘x’ token, like xSushi, dQuick, etc. On the legal end it creates regulatory questions because it resembles a security. But it is a more functional mechanism for facilitating adoption/use.\n\n 2 months later\n\n post by J.Berg on Mar 18, 2022\n\n J.Berg\n\n Creating a token enables the DAO to have an asset (without investing) that can be used to fund projects/guilds for effort the DAO needs (both maintenance and major initiatives), as well as contribute to internal DAO economics.\n–Paying core team members for their efforts\n–Paying for work done by Guilds and their squads\n–Internal DAO markets and trade\n–Bounties\nWill the Across token be used strictly for governance? or will it be used as money? or both?\nWould it be a monetary asset and a governance token to be used to fund and vote? Some DAO’s treat their governance token as ONLY that, and it actively drives down it’s valuation.\nIf its money then the DAO as an organization has the challenges of both a startup and an emerging digital nationstate in that we have to find and create revenue streams and manage costs, as well as drive the use and acceptance of our denomination both internally and externally.\nI think long term will be based on the size of the treasury it controls and the useful things you can do with it. As a result, I think the focus should be on activities that generate on-chain revenue for the DAO and ways to make the token useful stake it, collateral, ect.\nHow to pay contributors is definitely an important factor to consider. Without contributors, we won’t be able to do any of the above. Part of me feels that if your contributing, it should be because you believe in the DAO long term and shouldn’t expect an immediate monetary reward. The other part of me thinks that contributor renumeration is something that needs to be painstakingly thought out to retain talent and pay our people\n\n post by heybeo on Mar 22, 2022\n\n heybeo\n\n It would be nice to use bridges on the same platform as well as to create a nice dex.\nTrading pairs, for example acx-uma, are used as fees and distributed to token holders.\nacx-x\nacx-y\nacx-z\nJust a simple idea as liquidity addition commissions are burned\n\n post by altsilversurfer.nft on Mar 26, 2022\n\n altsilversurfer.nft\n\n Tokenomics can be viewed as a function of 3 main parameters, token launch (model, vesting scheme, market cap), utility, and inflation. Utility is one of the major drivers of adoption and appreciation of value. Thus, the more utilities, the best. Governance will be the first and more obvious utility of $ACX, but we must think beyond this to achieve sustainnability. This is the ultimate goal. And this is also the common interest of all involved. People that are waiting for profits will be maximally rewarded if they be patient and contribute to protocol sustainnability. Across will be really BIG and this is not a fanboy statement. The major crosschain pipes will see in the future typical value movements that will far exceed those of the biggest centralized exchanges today.\n\n post by jeffrey on Mar 29, 2022\n\n jeffrey\n\n Token is share, it means users own the project\n\n 12 days later\n\n post by hescollazo on Apr 11, 2022\n\n hescollazo\n\n I agree with the use of the token as a payment mechanism for the protocol. The low fees will bring new users and money into the ecosystem. That it can be used in governance will incentivize use of the application and hodling of the asset. Ultimately the goal should be to give users the tools to discover new ways in which to generate positive cash flow and build wealth.\n\n Load more posts below","tokens":2290,"squid":"spider-09","role":"Bridge Spider","at":1791347519151,"hash":"dc351ed5a48db358e2d24dd07ca7a1971dda844a"}
{"url":"https://www.metaplex.com/docs/smart-contracts/genesis/uniform-price-auction","domain":"metaplex.com","title":"Genesis Auction | Token Auction on Solana | Metaplex","text":"Uniform Price Auctions enable competitive bidding for token launches on Solana. All winning bidders pay the same clearing price — the lowest winning bid — ensuring fair price discovery for structured token sales and on-chain fundraising. What You'll LearnThis overview covers:How uniform price auctions workWhen to use auctions vs other launch mechanismsKey concepts: bids, clearing price, allocationSummaryUniform Price Auctions collect bids during an auction window, then allocate tokens at a single clearing price.Users bid for token quantity at their chosen priceBids ranked by price; tokens allocated to highest biddersAll winners pay the same clearing price (lowest winning bid)Supports public or sealed (private) bidsOut of ScopeFixed-price sales (see Presale), proportional distribution (see Launch Pool), and post-auction liquidity setup.Use CasesUse CaseDescriptionPrice DiscoveryLet the market determine fair token price through competitive biddingWhale/Fund ParticipationStructured auction format appeals to larger, institutional participantsControlled AccessCan be gated or ungated depending on requirementsHow It WorksAuction Opens - Users submit bids specifying quantity and priceBidding Period - Bids accumulate (public or sealed)Auction Closes - Bids are ranked by price, highest to lowestClearing Price Set - Price where total bid quantity equals available tokensAllocation - Winners receive tokens, all pay the clearing priceClearing Price ExampleAvailable tokens: 1,000,000\nBids received:\n - Bidder A: 500,000 tokens @ 0.001 SOL\n - Bidder B: 300,000 tokens @ 0.0008 SOL\n - Bidder C: 400,000 tokens @ 0.0006 SOL\n\nRanking (highest price first):\n 1. Bidder A: 500,000 @ 0.001 SOL (running total: 500,000)\n 2. Bidder B: 300,000 @ 0.0008 SOL (running total: 800,000)\n 3. Bidder C: 400,000 @ 0.0006 SOL (running total: 1,200,000)\n\nClearing price: 0.0006 SOL (Bidder C's price fills the auction)\nBidder C receives partial fill: 200,000 tokens\nAll winners pay 0.0006 SOL per token\nComparisonFeatureLaunch PoolPresaleUniform Price AuctionPriceDiscovered at closeFixed upfrontClearing priceDistributionProportionalFirst-come-first-servedHighest biddersUser ActionDepositDepositBid (price + quantity)Best ForFair distributionPredictable outcomeLarge participantsNotesUniform Price Auctions are suited for larger token launches with institutional interestThe clearing price mechanism ensures all winners get the same dealSealed bids prevent bidders from gaming based on others' bidsDetailed setup documentation for Uniform Price Auctions is coming soon. For now, see Launch Pool or Presale for alternative launch mechanisms.FAQWhat is a uniform price auction?An auction where all winning bidders pay the same clearing price, regardless of their individual bid amounts. The clearing price is the lowest winning bid.How is the clearing price determined?Bids are ranked by price from highest to lowest. The clearing price is set at the point where total bid quantity equals available tokens, with all winners paying this uniform price.Can bids be private?Yes. Uniform Price Auctions support both public and private (sealed) bids depending on your configuration.When should I use a Uniform Price Auction?Use it for price discovery with larger participants (whales, funds) who prefer structured auction formats over deposit-based launches.GlossaryTermDefinitionUniform Price AuctionAuction where all winners pay the same clearing priceClearing PriceThe lowest winning bid price; paid by all winnersBidUser's offer specifying token quantity and price per tokenSealed BidPrivate bid not visible to other participantsPartial FillWhen a bid is only partially satisfied due to limited supplyPrice DiscoveryProcess of determining market value through biddingNext StepsLaunch Pool - Fair launch with proportional token distributionPresale - Fixed-price token saleLaunch a Token - End-to-end token launch guideGenesis Overview - Token launchpad concepts and architecture","tokens":991,"squid":"dotcat","role":"Tooling Spider","at":1791347520057,"hash":"cf97aa5c4c68f7867aec1dbd588a94b39e236dce"}
{"url":"https://gov.optimism.io/t/governance-weekly-recap/3352/62","domain":"gov.optimism.io","title":"Governance Weekly Recap - Updates and Announcements 📢 / Governance Updates - Optimism Collective","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Aug 2022\n\n 62 / 103\n\n Nov 2023\n\n Dec 2024\n\n Load more posts above\n\n post by duncand on Aug 1, 2023\n\n 4 months later\n\n post by duncand on Nov 14, 2023\n\n post by Boardroom on Nov 20, 2023\n\n Boardroom\n\n Governance Recap: Week of November 13, 2023\nThis week marked the end of voting for Special Voting Cycle #16b. This voting process was crucial to decide the working and operations of the Season 5 grants council. Additionally multiple updates on Forum and events keep the community a happening place. We have listed all the key updates for the last week\nProposals\nVoting has concluded for Special Voting Cycle #16b. A total of 7 proposals were being voted upon, dealing mainly with Season 5 of Grants Council. A detailed analysis and description of Special Voting Cycle #16b can be found here - Governance Report: Optimism Special Voting Cycle #16b\n\nSeason 5 Intent Budgets:\nThis proposal involves allocating up to 9 million OP tokens across four main areas: Technical Decentralization, Growth of the Superchain, Consumer Experience Improvement, and Governance Accessibility Improvement, with an additional 1M OP reserved as an unallocated budget. Proposal Link\nVote on Chain Delegation Program:\nThe Chain Delegation Program is designed to enhance governance participation by OP Chains, with a focus on diversifying interests within the Token House and contributing to decision-making processes. Proposal Link\nRatification of Law of Chains:\nThis proposal aims to establish protections and principles within the Superchain ecosystem, focusing on user protection, decentralization, and economic autonomy. Proposal Link\nGrants Council Reviewer Elections: Growth Experiments:\nThis involves electing reviewers for the Growth Experiments Subcommittee within the Optimism Grants Council, focused on fostering growth and innovation in the ecosystem. Proposal Link\nGrants Council Reviewer Elections: Builders:\nThe proposal pertains to electing reviewers for the Builders Subcommittee, dedicated to expanding the developer base on the Optimism platform and focusing on forward-looking initiatives and projects. Proposal Link\nCode of Conduct Council: Member Nominations:\nThis involves transitioning the enforcement of the Code of Conduct from the Optimism Foundation to community-driven Code of Conduct Councils, with an emphasis on decentralization and democratization of governance processes. Proposal Link\nGrants Council Reviewer Elections: Milestones and Metrics:\nThe proposal is for electing reviewers to a committee tasked with overseeing the progress and impact of projects funded by grants in the Optimism ecosystem. Proposal Link\n\nIn the Forums\n\nGrant Council Changes: @ethernaut decides to step down from Grants council\n@ethernaut who was elected in the Grants Council Builders sub-committee, has voluntarily stepped down from their role. The reason cited by them is selection in another council. The delegate with prior work on Synthetix has also been selected in the Security Council, and wants to contribute to effectively to the security aspects.\nWith the vacant position in the Builders sub-committee of the Grants Council, @mastermojo is selected by virtue of being the next candidate in the council elections sequence. [Forum Link]\n\nBadgeholder Conflict of Interest Disclosure: The community is actively engaging in discussions about the importance of transparency among badgeholders. This includes addressing potential conflicts of interest, which is crucial for maintaining trust and integrity within the governance framework. In the badgeholder conflict of interest disclosure discussion, badgeholders mention their rationale for voting/not voting for specific projects in RetroPGF voting. [Forum Link]\n\nSecurity Council Ratification: The process of ratifying the initial members of the Security Council is underway. This council will play a crucial role in overseeing and ensuring the network’s security. The ratification vote represents a significant step in structuring the security governance of Optimism. Details about the vote and the candidates are available here.\n\nNetwork and Technical Updates\n\nOP Network Upgrade: The Optimism community is presently discussing a draft proposal for the Canyon Network Upgrade. This upgrade is pivotal for enhancing the network’s performance and scalability, addressing key technical challenges. Community members are encouraged to review and provide feedback on the proposal, which could significantly impact the future of the Optimism network. The proposal and ongoing discussions are available for review here.\n\nMade by the Community\n\nKarma New Feature: @mmurthy has introduced a new feature for Karma - peer-to-peer delegate endorsements on-chain. This innovative feature aims to enhance community participation and governance transparency. It allows delegates to endorse each other, fostering a culture of mutual support and credibility. It is aimed at making less visible delegates more recognizable. More information about this feature and its role in community governance is available here.\nAnalysis of Special Voting Cycle #16b: @boardroom() has published a comprehensive governance report for the special voting cycle #16b. This report provides valuable insights into the proposals, their underlying principle and further details. It is an essential resource for members to understand the implications of recent voting patterns. The full report is accessible here.\n\nEvents & Social\n\nRetroPGF Pitch Day: @Optimystics has launched the RetroPGF Pitch Games, an innovative event designed to engage the community. This initiative allows members to showcase their projects and ideas, fostering a spirit of creativity and collaboration. It’s a great opportunity for developers and entrepreneurs to gain visibility within the Optimism ecosystem. Full details of the event can be found here. The first session is scheduled for today Monday Nov 20, 2023.\nOP Delegate Community Call: 31st OP Delegate call will be held on Nov 21 by @michael, here is the forum discussion and the Zoom call link.\n[Discord] Office Hours: Ask questions about Optimism, discuss latest features and updates on the Optimism Office hours on Nov 22. Add yourself to the event here\n[Discord] Demo Day: Optimism Discord will host an exclusive Demo Day for BEAM on November 30th 4pm UTC. Add a reminder to the event on Discord\n\nimage1920×2399 533 KB\nImage by Fuji AR on Optimism Discord\n\n post by chaselb on Nov 22, 2023\n\n chaselb\n\n Good to see these happening again!\n\n post by FractalVisions on Nov 26, 2023\n\n FractalVisions\n\nI highly recommend that every grantee who has received funds to utilize Karma GAP as well for their own personal milestone tracking.\nIt is also built by the KarmaHQ team.\nThis platform uses the Ethereum Attestation Station to help track information onchain.\n\n post by Boardroom on Nov 27, 2023\n\n Boardroom\n\n Governance Recap: Week of November 20, 2023\nGreetings Optimism Community! Last week was bustling with activity, from crucial voting processes to vibrant discussions in our forums. Here’s a roundup of the key updates and happenings.\nVoting Highlights\nSpecial Voting Cycle #16c\n\nCanyon Network Upgrade: The community focused on the Canyon Network Upgrade, a pivotal proposal aiming to significantly enhance the network’s performance and scalability. This upgrade represents a major technological advancement, addressing crucial technical challenges to improve the user experience and system efficiency. Community members were encouraged to delve into the proposal’s details and participate actively in shaping the network’s future. Full Proposal and Voting link\nSecurity Council Ratification: The ratification vote for the initial members of the Security Council marked a significant stride in bolstering the network’s security governance. This process involves carefully selecting members who will play a crucial role in overseeing and ensuring the network’s security, reflecting the community’s commitment to maintaining a robust and secure ecosystem. Forum | Voting\n\nForum Discussions\n\nGrants Council Platform Request: A key discussion emerged around the selecting a dedicated platform to support the Grants Council’s operations. This platform is envisioned to streamline processes, facilitate collaboration among council members, and enhance transparency in decision-making. The community’s input is sought to ensure the platform effectively meets the council’s needs and objectives. Discussion Thread by @gonna.eth.\nVoting Cycle 16c Commencement: The start of Special Voting Cycle #16c marked another important phase in community-driven governance. Members were urged to review the proposals and exercise their voting rights, emphasizing the significance of collective decision-making in shaping the network’s direction. The two proposals which are being voted upon Proposal 1 & Proposal 2\nOptimism Community Call Recap: Regular community calls provide a platform for updates, discussions, and feedback. The latest call covered a range of topics, reflecting the diverse interests and initiatives within the Optimism ecosystem. Staying updated with these recaps is crucial for active community members. Recap Here by @michael\nVoting Rationale for RetroPGF3: In this thread, community members shared their rationale behind their voting choices for RetroPGF3. These insights offer valuable perspectives on the decision-making process, highlighting the diverse viewpoints and priorities within the community. @dmars300 & @OPUser shared a detailed view about their takes, Read their thoughts.\nRetroPGF Application Errors: Addressing and discussing reported application errors in RetroPGF3 is crucial for maintaining the integrity and smooth operation of the grant process. This thread serves as a platform for identifying and reporting the errors in applications. Issue Discussion by @jonas.\n\nDelegate Communications\n\nUpdates from Delegates: Delegates shared updates and communications, providing insights into their ongoing initiatives and perspectives on various topics. These updates are a key part of maintaining an informed and engaged community, and serves as a crucial channel of communication by the delegates.\n\nDelegate\nCommunication Thread\n\n@brichis\nBrichis - Delegate Communication Thread\n\nSEED Latam by @joxes\nSEEDGov - Delegate Communication Thread - #38 by Joxes\n\nOPUser\nOPUser - Delegate Communication Thread - #41 by OPUser\n\nEvents & Social\n\nOptimism RetroPitches: The Optimism RetroPitches event offers a dynamic platform for community members to present and discuss their projects. This event fosters a spirit of innovation and collaboration, providing an excellent opportunity for developers and entrepreneurs to showcase their ideas and gain visibility within the Optimism ecosystem especially for RetroPGF 3. Event Details by @Optimystics\nOP Delegate Call: The 32nd OP Delegate Call is an essential forum for community engagement, discussion, and collaboration. Scheduled for December 5th, this call is an opportunity for delegates to share updates, discuss ongoing initiatives, and engage with the community on pressing topics. Details here by Michael\nRetroPGF Showcase: Scheduled for November 28, the RetroPGF Showcase is a key event for projects funded by the RetroPGF to demonstrate their progress and impact. This event is crucial for fostering transparency, accountability, and community engagement around funded projects. Event Information by nicod\n\nCommunity Contributions\n\nImpactful Projects List: Curated by community member @lefterisjp, this list highlights impactful open-source projects within the RPGF. It serves as a valuable resource for community members to discover and support projects that are making significant contributions to the ecosystem. View the List.\nRetroPGF OSS Projects Analysis: This comprehensive analysis of 300 open-source projects applying for RetroPGF3 provides crucial insights into the landscape of community-driven projects. It is a testament to the vibrancy and diversity of the ecosystem, and a valuable resource for understanding the breadth and depth of community engagement. Full Analysis by @ccerv1.\n\nThis week’s updates underscore the dynamic and participatory nature of our community. Your engagement and insights are vital in driving Optimism forward. Stay active and stay connected!\nimage662×662 70.6 KB\nImage by Zey on OP Discord\n\n post by FractalVisions on Nov 27, 2023\n\n post by Boardroom on Dec 4, 2023\n\n post by Boardroom on Dec 11, 2023\n\n post by FractalVisions on Dec 11, 2023\n\n post by fujiar on Dec 11, 2023\n\n post by Boardroom on Dec 19, 2023\n\n 5 months later\n\n post by Boardroom on May 20, 2024\n\n post by Liliop.eth on May 20, 2024\n\n post by Boardroom on May 27, 2024\n\n post by Boardroom on Jun 3, 2024\n\n post by Boardroom on Jun 10, 2024\n\n 13 days later\n\n post by Grant3 on Jun 24, 2024\n\n post by Boardroom on Jun 24, 2024\n\n post by Boardroom on Jun 25, 2024\n\n Load more posts below","tokens":3245,"squid":"spider-07","role":"Council Spider","at":1791347532307,"hash":"b4ffbfdba75d92a956d99907f77121d262b758f5"}
{"url":"https://gov.optimism.io/t/governance-weekly-recap/3352/103","domain":"gov.optimism.io","title":"Governance Weekly Recap - Updates and Announcements 📢 / Governance Updates - Optimism Collective","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 49\n\n 30\n\n 6\n\n 3\n\n read \n\n 135\n min\n\n Aug 2022\n\n 103 / 103\n\n Dec 2024\n\n Dec 2024\n\n Load more posts above\n\n post by Boardroom on Sep 3, 2024\n\n Boardroom\n\n Week of August 26th, 2024\n Recent Proposals\n\nSecurity Council Elections Cohort A Members\n\nSummary: The Security Council Charter dictates that the Token House will conduct elections for Cohort A of the Optimism Security Council. The top seven candidates, determined by approval voting, will be elected to serve a 12-month term, pending Foundation confirmation. If any candidate is not confirmed, the runner-up will take their place. This proposal, eligible for Voting Cycle #26, ensures that no more than one elected member is associated with a single entity or its affiliates. The approved candidates can be reviewed through the respective nomination links provided. The election process leverages approval voting, allowing delegates to vote for multiple nominees and even for themselves as long as additional votes are cast for other elected positions.\n\nProposer: Optimism Foundation\n\nStatus: Defeated\n\n Forum Highlights\n\nExploring Shielded Voting: Enhancing Governance on Optimism\nA forum post on the Optimism platform introduces the concept of shielded voting, which entails encrypting votes during the voting period and decrypting them post-vote closure. The post highlights several benefits of this approach, including mitigating bandwagon effects, reducing voter apathy, and preventing last-minute strategic voting. The author solicits community feedback on whether shielded voting could enhance decision-making within Optimism, the potential downsides, the scope of its application, and the alignment with Optimism’s values and goals. The discussion aims to gather diverse perspectives to strengthen governance.\n\nCycle 26 Grants final roundup\nIn the Cycle 26 Grants final roundup, the Optimism Grants Council addressed challenges from Cycle 25 by implementing several process improvements. Enhanced transparency was achieved through integrating rubric comments directly into applications, allowing applicants full visibility of scores and feedback. The review process was refined by splitting the council into two groups for balanced evaluations and incorporating feedback from the Developer Advisory Board (DAB). Out of 29 new and 24 carried-over applications, 12 new grants were approved, adhering to revised point thresholds to ensure strong application consideration. The post highlights upcoming Cycle 27 plans and congratulates the recipients of the first-ever Superchain grants for setting high standards. Special thanks were extended to @devtooligan for audit review contributions, emphasizing the collaborative effort in the grant review process. The full list of applications and their statuses is provided for reference.\n\nCode of Conduct Council (CoCC) Internal Operating Procedures S6\nThe Optimism Code of Conduct Council (CoCC) for season 6 is comprised of elected community members tasked with managing disputes, resolving conflicts, and enforcing sanctions for rule violations within the community. Members of the community, known as Optimists, can directly report issues to CoCC members or anonymously via a reporting form. The conflict assessment process is categorized into small, medium, and large scopes, depending on the severity and impact of the incident, with varying degrees of intervention and potential sanctions such as warnings or bans. The CoCC employs a structured process for conflict resolution, including identification, screening, deliberation, and follow-up phases to ensure thorough investigation and appropriate action. Updates to operating procedures can occur twice per season, and the council is expected to provide periodic reports for transparency and self-evaluation.\n\nRolling Mission Requests\nThe Grants Council has put forth a proposal seeking the ability to create and submit rolling Mission Requests to attract more developers to the Optimism ecosystem. With 1.725 million OP tokens approved but unallocated, this initiative aims to boost developer growth by utilizing the unallocated budget from Intent 3A. Starting from Voting Cycle #27, the Council proposes continuous submissions of Mission Requests, which need sponsorship from a Council member and approval by the Token House. This ongoing process features a systematic timeline with submission deadlines each Review Period and subsequent voting\n\nCycle 26 Grants Preliminary Review Report\nThe Cycle 26 Preliminary Review has concluded, with 29 new applications and 24 from the previous cycle. The cutoff was set at 30 points, and every reviewer met their milestones. Special mention was given to operations lead Bunnic. The Developer Advisory Board played a crucial role, offering valuable input for evaluations. Finalists will be announced next Wednesday. Gratitude was extended to the Grants Council for their efforts. Noteworthy applications passing to the final include OP Stack Cross Chain Voting, Hedgey application, and CastRank, among others. Declined applications included Vote Notifier and OptimismDAO Management dashboard. Detailed results are available in their public database.\n\nSuperchain Grants Review Process\nThe Grants Council has introduced a detailed review process for the Season 6 Superchain Grants Program, ensuring rigorous evaluation based on 15 specific criteria. Applicants must answer questions affirmatively on factors like the chain’s operational status, clarity of grant structure, alignment with Superchain goals, efficiency, and sustainability. Scoring requires at least 14 out of 15 positive responses to qualify. Priority will be given to live chains contributing to sequencer revenue until Cycle 28, with non-live chains considered if the budget remains unallocated. Grant requests are capped at 3M OP, and proposals exceeding 1M OP must demonstrate exceptional innovation and collaboration. This process underscores the commitment to fostering robust and impactful projects within the Superchain ecosystem.\n\n Upcoming Votes\n1 Proposals live at the time of writing this report, no upcoming proposals detected\n\n 15 days later\n\n post by Boardroom on Sep 19, 2024\n\n Boardroom\n\n Week of September 2nd, 2024\n\nWannabet Weekly Tournaments\nThe Wannabet team is excited to announce their selection to develop an onchain social game for Optimism. The game allows users to place bets on weekly propositions and compete onchain, with the top performers earning OP rewards. This forum post aims to keep the community informed about progress and game launches, inviting feedback and suggestions. For more detailed information on Wannabet’s history, they have provided links to their website and GitHub.\n\nCycle 27 Intent 3A Mission Request and Sponsorship\nThe forum post titled “Cycle 27 Intent 3A Mission Request and Sponsorship” introduces a thread for tracking new mission request proposals each cycle, facilitated by the user Gonna.eth (Dhannte). Users are guided through a step-by-step process which includes copying a provided template, creating a new forum post, filling out the necessary information, and tagging the post appropriately. If users are not Grants Council members, they should include “[Looking for sponsor]” at the beginning of the post title. Finally, they are required to return to the original thread and share the link to their mission request post in the replies for further engagement and sponsorship opportunities.\n\n[Mission Request] Optimism Treasury Diversification Research\nThe forum post titled “[Mission Request] Optimism Treasury Diversification Research” outlines a mission to explore treasury diversification strategies for the Optimism Collective, which currently holds 100% OP. The goal is to develop actionable plans supported by data to diversify part of the treasury into on-chain yield-bearing assets or real-world assets (RWAs). This initiative aligns with Season 6’s Intent 3A and aims to incentivize Optimism-based protocols to hold RWAs, thus fostering broader RWA adoption within the ecosystem. A grant of 25,000 OP is proposed for multiple applicants to conduct thorough research on treasury diversification strategies, the regulatory environment, and financial implications. The success of this mission will be measured by the number and quality of research reports and the subsequent growth of the Optimism treasury.\n\nCycle 26 Grants final roundup\nIn Cycle 25, the review process faced several hurdles, including rapid review timelines and technical difficulties with Charmverse. Despite these, all 50 applications were reviewed, but only three reviewers had full contextual understanding for final decisions, leading to a push of non-approved applications to the next cycle. For Cycle 26, improvements were implemented, such as integrating rubric comments for better transparency, splitting the review process among two groups of six Grants Council members for balanced decision-making, and involving the Developer Advisory Board (DAB) more effectively by adjusting timelines. Cycle 26 saw 29 new applications and 24 carryovers, with a new scoring threshold set to ensure robust selection. Ultimately, 12 new grants were approved, demonstrating the efficacy of the revised process. Looking ahead to Cycle 27, submissions will be open until September 2nd, encouraging applicants to refine their proposals based on feedback to meet the updated criteria. Special acknowledgment was given to Derive and Fraxtal for receiving the first Superchain grants, setting a high standard for future recipients. Additionally, audit requests were evaluated meticulously, with a total of eight requests scored, resulting in five approvals.\n\nCode of Conduct Council (CoCC) Internal Operating Procedures S6\nThe Code of Conduct Council (CoCC) for Optimism Season 6 outlines its internal operating procedures focusing on managing disputes and enforcing sanctions for violations within the community. It establishes mechanisms for reporting issues, ranging from direct contact with CoCC members to anonymous submissions via a reporting form. The scope of conflicts is categorized into small, medium, and large, with corresponding actions ranging from de-escalation to potential bans. The conflict management steps include identification, screening, deliberation, and follow-up phases, each with specific timelines. Additional measures include documenting processes while preserving privacy and providing mid and end-season reports for transparency and evaluation. Members must handle case registries confidentially and these operating procedures are subject to periodic updates based on evolving needs.\n\n post by sharp3 on Sep 19, 2024\n\n sharp3\n\n Thanks for the updates\n\n post by Boardroom on Sep 19, 2024\n\n Boardroom\n\n Week of September 9th, 2024\n\n[Mission Request] Subsidized Audit Grants V2\nThe forum post titled “[Mission Request] Subsidized Audit Grants V2” proposes repurposing and continuing a previous budget to fund subsidized audits for promising projects in the Optimism ecosystem. The new streamlined process includes a pre-whitelist for auditors by the Grants Council (GC), allowing auditors to apply for specific audits directly from the mission budget. This initiative, proposed by Anthias Labs and Gonna.eth, aims to support new developers and projects by covering audit costs, thus fostering growth in the Superchain. The total grant amount requested is 500,000 OP, with the goal of increasing the number of active developers through improved infrastructure and open standards. The success of this mission will be evaluated based on milestones, the number of active addresses interacting with audited contracts, and other usage data.\n\nGovNFT Community Call Thread 4\nThe latest GovNFT Community Call Thread discussed the introduction of guest voter participation for Retro Funding Round 6. Michael Vander Meiden highlighted Emily’s talk on the topic, explaining that guest voters will be randomly selected and will participate alongside regular voters, focusing on Governance projects. The thread invites community members to share their thoughts on how this new approach might influence voting outcomes compared to previous rounds dominated by Badgeholders. Participants are encouraged to provide meaningful insights, with a reminder that high-quality contributions earn points, while low-effort posts may result in penalties.\n\n[Looking for sponsor] Develop Onchain Social Games that Attract Builders to Optimism\nDan Singjoy has proposed a mission request on the Optimism forum aimed at developing onchain social games to attract and nurture builders, fostering a vibrant developer community. This initiative aligns with Optimism’s goal of growing application developers on the Superchain by leveraging interactive and educational games to engage new developers, enhance their skills, and build a supportive community. The total grant amount requested for this mission is 250k OP, and it is intended for multiple applicants. Key milestones include launching an initial game within three months and conducting midterm and yearly reviews to assess impact and progress. The proposal also emphasizes the importance of community outreach, incentives, and proper documentation to ensure successful execution and continuous developer engagement.\n\n[Mission Request] Superchain Borrow/Lend Aggregator\nMission Request: Superchain Borrow/Lend Aggregator\n\nThis mission request, proposed by Anthias Labs, aims to develop a unified borrow/lend aggregator for all Superchain-based protocols. With the goal of enhancing liquidity and providing users with optimal borrowing and lending rates, the project seeks a grant of 30,000 OP. The proposal emphasizes the need for a single, comprehensive platform that integrates major protocols like Aave and Moonwell and offers an easy-to-use frontend. Success metrics include the amount of Total Value Locked (TVL) and the volume of borrows handled through the aggregator, with the broader intention of increasing developer activity on the Superchain and uniting its liquidity.\n\n[Mission Request] - Crosschain alert monitoring\nIn a recent forum post titled “[Mission Request] - Crosschain alert monitoring,” a delegate outlines the need for alerting and monitoring systems for crosschain messages and transactions within the Optimism Superchain. The post highlights that effective interop is crucial to attract serious developers by providing tools necessary for high functionality, security, and user experience. The proposed mission seeks a grant of 60k OP and aims to create tools to monitor the performance, delays, or failures of interop messages and general health metrics. By ensuring robust crosschain functionality, the initiative aims to enhance developer trust and adoption of the Superchain for new projects, while also addressing specific milestones and performance metrics upon completion【4:1†Season 6- Intents Ratification.txt】.\n\nRetro Funding 6: Announcing Guest Voter participation\nRetro Funding 6 introduces a new phase in the Optimism Collective’s governance by involving Guest Voters to participate alongside Citizens in awarding OP for contributions. This experiment builds on the previous round and aims to explore different voter selection mechanisms to inform future Citizen selection processes. The research focuses on comparing outcomes from various selection methods like Web of Trust and Proof of Work against random selection, aiming to establish control groups and understand differences in voter composition and decision-making. The experiment includes rigorous measures to ensure randomness and minimal bias in voter selection, targeting active users of the Farcaster Protocol. Approximately 100 Guest Voters will join, ensuring adequate representation and experimental validity. The final determination of the Guest Voters’ influence will be subject to Citizens’ review to safeguard against system capture.\n\n[Mission Request] Targeted extension of Superfest\nJack Anorak has proposed a Mission Request to extend Superfest, a program aimed at encouraging the migration of DeFi projects to the Superchain. Noting previous implementation issues but overall success, the request seeks 400k OP to incentivize DeFi projects. Both existing and new DeFi applicants are eligible under specific conditions such as having a track record of onboarding new protocols or providing credible growth plans. The mission’s impact will be measured by metrics like Total Value Locked (TVL) and the number of new projects and users. This proposal aims to support Intent 3a of Season 6, focusing on strategic growth and innovation within the Superchain ecosystem\n\nCycle 27 Grants Preliminary Review Report\nThe Cycle 27 Grants Preliminary Review Report outlines the review process for 47 applications, including those for Superchain and audits. The Grants Council excelled in timely reviews and contributed significantly to mission requests. Special thanks were given to the Developer Advisory Board (DAB) for their valuable feedback on 34 applications. Review scores and feedback are now available on individual applications, with a preliminary cutoff set at 30 points. Finalists, needing a minimum of 40 points, will be announced next Wednesday. A database and list of finalists were also included in the report.\n\n[Mission Request] Intent 3A - Superchain Builder Hub\nThe forum post titled “[Mission Request] Intent 3A - Superchain Builder Hub” outlines a proposal to create a virtual hub for the Optimism Collective. The main aim is to reduce information asymmetry and coordination costs by developing a comprehensive platform covering chains, projects, opportunities, programs, analytics, and contributors within the ecosystem. The requested grant amount is 125K OP, and the project should be managed by a single applicant. The initiative seeks to attract top talent and builders by providing an organized, easy-to-navigate representation of the ecosystem. Essential requirements include a deeply knowledgeable operating team, alignment with Optimism brand guidelines, and a clear path for new developers to engage with the community. The project’s success will be measured through various metrics, including the number of new projects, developers, delegates, and unique users engaging with the platform, along with overall platform usage and its impact on the ecosystem.\n\n[Looking for sponsor] Automated Grants System\nThe forum post discusses a mission request seeking sponsorship for an automated grants system aimed at providing grant access to builders with minimal friction and contingent payouts based on predefined criteria. Aligned with Season 6’s intent to advance decentralization through DAO infrastructure, the proposal requests a total grant amount of 80k OP. The mission includes details on execution requirements, milestone tracking, impact measurement, and clarifies that no other contributors are involved in the request. The post emphasizes the need for a single applicant to fulfill the mission, aiming to enhance the efficiency and effectiveness of grant distribution within the Optimism Collective framework.\n\n[Mission Request] - Experimentation of Infrastructure Subsidies\nThe forum post titled “Mission Request: Experimentation of Infrastructure Subsidies” outlines a proposal for subsidizing key infrastructure providers, such as RPCs, oracles, and web3 alert services, to support builders on the Optimism platform. The initiative aims to allocate up to 30k OP per provider, with a total grant amount of 250k OP, to reduce barriers for new developers and enhance the performance of existing applications. The proposal targets growing application developers on the Superchain and entails multiple providers submitting detailed support plans. Success will be measured through metrics such as the increase in developer activity and performance improvements in applications utilizing the subsidized services. The ultimate goal is to foster a more diverse and robust ecosystem on Optimism.\n\n[Mission Request] Decentralized Solvers and Aggregators on OP Mainnet / Superchain\nThe forum post describes a mission to boost decentralized solvers, aggregators, and limit order functionality on the Optimism Mainnet and, eventually, the Superchain. Proposed by Matt, the mission targets projects like CowSwap and 1inch Fusion, aiming for enhanced liquidity and trading efficiency. The total grant is set at 250k OP, distributed among multiple applicants, with milestones focusing on integration with major decentralized solvers, trading volume increases, and Superchain compatibility. Key metrics for success include trading volume, unique user interaction, and gas savings\n\nSuperchain dApps and its reach\nA forum user shared their experience exploring superchain dApps during the jumper superchain quest. As a veteran in the space, they noted discovering many new projects and felt naturally inclined to explore well-known names like Balance and Aave for safety. However, they encountered liquidity issues with Fraxtal on Jumper and had to resort to Curve.fi for swaps and Orbiter for bridging. The user stressed that while experienced users could navigate these challenges, newcomers might struggle, highlighting the need for better onboarding processes. They hope their feedback will be useful for future improvements.\n\n[Mission Request] Optimism Treasury Diversification Research\nA forum post from Anthias Labs outlines a mission request to research diversification strategies for the Optimism Collective treasury, which is currently 100% in OP tokens. The request proposes investigating on-chain yield-bearing assets and Real-World Assets (RWAs) to diversify the treasury, aiming to support expenses and generate additional yield. This initiative, aligned with Optimism’s Season 6 intent, seeks actionable plans with solid data that can be adopted within a DAO framework. The goal is to attract more RWA projects to the Optimism ecosystem while ensuring compliance with regulatory standards. Applicants are expected to deliver research demonstrating Optimism’s current financial state, explore effective diversification strategies, and outline the regulatory implications of potential strategies, aiming for transparent and measurable milestones.\n\n[Mission Request] Optimism Dominance in Yield-Bearing Assets - DEX Liquidity for YBAs\nThe forum post discusses a mission request to enhance the dominance of Optimism in yield-bearing assets (YBAs) by focusing on decentralized exchange (DEX) liquidity. The proposal, driven by Anthias Labs for Season 6, seeks to onboard more real-world assets (RWAs) and YBAs via DEX integrations, reusing goals and criteria from previous requests by GFX Labs. It highlights the need for whitelisted RWAs to have greater DEX liquidity as opposed to lending market integrations. The plan includes a 500,000 OP grant distribution to incentivize users who bridge and deposit whitelisted assets into eligible DeFi protocols. The mission’s success will be measured by the number of whitelisted assets, the amount of assets migrated to Optimism, and the duration of their stay, with the overarching goal of increasing Total Value Locked (TVL) within the Optimism Superchain.\n\nCycle 27 Intent 3A Mission Request and Sponsorship\nThe forum post titled “Cycle 27 Intent 3A Mission Request and Sponsorship” aims to organize new mission request proposals for each cycle. The process involves copying a template from the provided link, creating a new forum post with that template, tagging the post appropriately, and indicating whether sponsorship is needed. Participants are expected to update the thread with links to their mission request posts. The goal of the forum is to streamline and manage the proposal submissions efficiently, enhancing the governance and project execution within the community.\n\n post by Boardroom on Sep 25, 2024\n\n Boardroom\n\n Week of September 16th, 2024\n Forum Highlights\n\nIntroducing GovGraph.fyi – Citizen Connections Visualized\nGovGraph.fyi is an innovative visualization tool designed to enhance understanding and interaction within governance ecosystems, with a specific focus on Optimism’s ecosystem. It features interactive relationship mapping, advanced filtering and search capabilities, and transparency enhancement tools to identify alliances, conflicts of interest, and influence clusters. The development team is seeking feedback from citizens and stakeholders to refine the tool. Users are encouraged to explore GovGraph, provide feedback, and suggest new features. This project, a collaborative effort from experts in reputation systems and governance analytics, aims to foster a more efficient and transparent governance ecosystem. For more details, visit the GovGraph website.\n\nGovNFT Community Call\nThe fourth GovNFT Community Call focused on guest voter participation in Retro Funding 6, with discussions led by Emily. The call covered the process of selecting guest voters randomly and encouraged participants to share their thoughts on how these voters might differ in their voting compared to Badgeholders, particularly since Round 6 will focus on Governance projects. Michael emphasized that thoughtful responses are valued and provided links to additional information and previous discussions on guest voter participation.\n\nAccelerated Decentralization Proposal For Optimism\nThe proposal by GFX Labs outlines a three-phase plan to accelerate the decentralization of Optimism’s governance, aiming for completion by summer 2025. It highlights the current limitations of the OP token and Optimism governance, contrasting it with its main competitor, Arbitrum. The proposal argues for an immediate transfer of control over the OP token contract, governance contract, and governance funds in Phase I, followed by the handover of essential infrastructure and the development of a sequencer decentralization roadmap in Phase II. Phase III targets full technical control by Optimism governance, finalizing sequencer decentralization, and ensuring transparency in Foundation grants. The goal is to rejuvenate Optimism’s governance and business strategy, positioning it for sustainable growth and value creation for stakeholders.\n\n[Mission Request] Targeted extension of Superfest\nJack Anorak proposes a mission to extend Superfest, aimed at migrating more projects onto Superchain. Despite initial implementation issues, Superfest effectively encouraged project migration. The mission resembles previous Growth Experiments grants, emphasizing DeFi projects. A grant of 400k OP is proposed, targeting multiple applicants including new and existing OP Mainnet-DeFi projects. Key requirements include a growth theory, user impact expectations, and meaningful product value additions. Metrics for success include TVL during and post-incentive programs, first-time wallet onboarding, and the number of new DeFi projects attracted.\n\nCycle 27 Grants final roundup\nIn the final roundup for Cycle 27 grants, all applications were successfully reviewed despite the additional workload. Out of 53 applications, 16 were approved, with notable recipients including Base, Mode, Swan, Cyber, and Redstone securing Superchain grants. The Developer Advisory Board (DAB) played a crucial role with their insightful feedback. Looking ahead, Cycle 28 has opened for submissions, which are due by Tuesday, 24th at 19:00 GMT. New Mission Requests that reached quorum are live, and a new whitelisting process for auditors will be announced soon. Applicants are encouraged to review feedback from previous cycles and strive to meet the 40-point threshold for consideration. Detailed information and resources for finalists are available through provided links.\n\nPairwise in Retro Funding 5: Your Voting Tool\nIn the forum post titled “Pairwise in Retro Funding 5: Your Voting Tool,” users are introduced to the Pairwise voting dApp, designed to simplify the RF5 voting process by allowing comparisons between two options. This tool is user-friendly and open-source, converting subjective inputs into measurable results, thereby reducing the cognitive burden of voting. A new feature, star ratings, has been introduced to categorize projects based on their impact, ranging from high to no impact. This star system is optional but recommended for refining project rankings, making it easier to unlock ballots. The process involves navigating to Pairwise, ranking projects using the star system, and finally unlocking the ballot for final adjustments before casting a vote. The post encourages user feedback to improve the experience.\n\nRetro Funding 6: Governance - Round details\nThe forum post on “Retro Funding 6: Governance” outlines the details of the sixth round of Retroactive Public Goods Funding for the Optimism governance system. This round aims to reward contributions made between October 2023 and September 18, 2024, in governance infrastructure, analytics, and leadership. Key dates include the sign-up period from September 26 to October 10, application reviews from October 14 to 28, voting from October 28 to November 7, and results announcement on November 19. Eligible contributions span various categories, including technical tools for governance, governance analytics, and leadership roles within the community. The funding round will allocate between 1.1 million and 3.5 million OP tokens, based on votes from the community, who will decide the final allocation amount via a median voting process. The voting design and process improvements aim to enhance community-driven budget allocation, and grants will be streamed to recipients over 100 days pending KYC approval.\n\nBadgeholder Onchain Analysis Report\nThe “Optimism Badgeholder On-Chain Analysis Report” examines the activities and influence of Badgeholders within the Optimism Collective. Badgeholders, crucial for voting on governance and Retro Funding distribution, display higher engagement in other DAOs, NFT creation, and smart contract deployment compared to typical active OP users. The study reveals their significant role in various governance activities across multiple chains, including higher participation in prominent DAOs and social apps like Farcaster. The findings, sourced from 132 Badgeholder addresses and a representative control group, aim to inform future Retro Funding rounds and enhance the transparency and effectiveness of governance within the Optimism Collective.\n\n[Mission Request] Subsidized Audit Grants V2\nThe “Subsidized Audit Grants V2” mission request aims to repurpose and extend the budget from previous initiatives to provide subsidized audits for promising projects within the Optimism ecosystem. The proposal outlines a streamlined process for audits, eliminating pre-approved budgets and allowing whitelisted auditors to apply directly for funds. By supporting the auditing costs of new projects, this initiative intends to foster sustainable growth and increase the number of active developers in the Optimism Collective. Key metrics for evaluating success include the number of active addresses interacting with audited contracts, usage data of funded projects, and overall impact on the ecosystem’s developer community. The mission requests a total of 500,000 OP, equally split between repurposed funds and new allocation, to support this goal.\n\nEVENT: Optimism Retro Funding – Voting Design Evaluation\nThe forum post announces a workshop for Optimism Retro Funding on September 23, 2024, to evaluate and improve the voting designs of past funding rounds. The GovXS team has developed a new evaluation framework grounded in social choice theory to assess voting designs across six dimensions: resistance to malicious behavior, incentive compatibility, simplicity, majority and diversity representation, incentives alignment, and alignment with ground truth. The workshop will guide attendees through this framework and provide data-driven proposals for future improvements. The session is open to Optimism Badgeholders, GovNERDS, guest voters, and members of the Optimism Collective, with the participation of researchers from the GovXS team.\n\n[Mission Request] - Experimentation of Infrastructure Subsidies\nThis request proposes subsidizing infrastructure providers like RPCs, oracles, and web3 alert services to aid builders on Optimism. Each provider can apply for up to 30k OP, with a total grant amount of 250k OP. The mission’s goal is to evaluate the impact of these subsidies, aiming to support new and existing protocols on Optimism, thereby lowering entry barriers, improving application performance, and encouraging service optimization for the Optimism ecosystem. Metrics for success include increased developer activity, onboarding of new services, and cost reduction for developers. The proposal is in draft mode, awaiting comments from additional delegates.\n\n[Mission Request] Decentralized Solvers and Aggregators on OP Mainnet / Superchain\nThe forum post discusses a mission request aimed at incentivizing the development and integration of decentralized solvers, aggregators, and limit order functionality on Optimism Mainnet and the Superchain. The mission targets projects like CowSwap, 1inch Fusion, and Pyth Express Relay, aiming to enhance trading efficiency, user experience, and overall liquidity on the network. It proposes a total grant amount of 250k OP and outlines key requirements such as integration with OP Mainnet, development of user-frontends, and support for Superchain compatibility. Metrics for success include increased trading volume, unique users, and improved capital efficiency. The mission seeks multiple applicants and highlights the involvement of contributors like Synthetix and Pyth.\n\n[Mission Request] - Crosschain alert monitoring\nA delegate has submitted a mission request to develop alert and monitoring tools for crosschain messaging in the Optimism network. Noting the importance for products requiring high functionality, security, and user experience, the proposal aligns with Season 6 Intent 42. The suggested tools aim to monitor and report interoperability issues, like message delays or failures, and track core metrics such as latency and gas usage, thereby facilitating seamless crosschain operations. The total requested grant amount is 60k OP, and the mission might be fulfilled by up to two applicants. The proposal underscores the need for robust tooling to advance developer confidence and foster crosschain projects within the Superchain ecosystem.\n\nAutomated Grants System\nIn a recent forum post, a delegate proposed an automated grants system for Optimism’s Season 6, Cycle 27. The mission aims to streamline the grant access process for builders, offering grants as streams and payouts upon meeting specific criteria. The total grant requested for this mission is 80k OP, with the goal of furthering decentralization within the DAO infrastructure. The proposal outlines the required milestones, metrics, and impact assessments for governance participants to evaluate the mission’s success. This initiative seeks one applicant to execute the mission, contributing significantly to Optimism’s strategic intent for the season.\n\n Upcoming Votes\n0 Proposals live at the time of writing this report, no upcoming proposals detected\n\n post by Boardroom on Oct 1, 2024\n\n Boardroom\n\n Week of September 23rd, 2024\n Forum Highlights\n\nJoan’s RPGF5 Reflections\nJoan reflects on their experiences participating in RPGF5 as a reviewer and appeals reviewer. The RPGF5 round aimed to reward contributors to the OP Stack across three categories, with voters deciding on the distribution of a 2M-8M OP token allocation. Joan highlights improvements made since RPGF4, including better clarity in review tasks and enhanced software tools like the new reviewer checklist and Charmverse’s updates. However, they also mention areas needing further enhancement, such as API access to application data and the ability to sort applications by various criteria. Joan appreciates the structured reviewer teams and communication channels, but suggests more organized issue follow-ups during software testing and clearer guidelines for applicants. Overall, Joan found this review round more productive and focused compared to previous ones.\n\nGovNFT Community Call Thread 5\nIn the GovNFT Community Call Thread 5, Michael Vander Meiden invites GovNFT participants to continue the discussion on the “Accelerated Decentralization Proposal For Optimism” and the Foundation’s response. The community is encouraged to share insights on important topics such as the essential actions needed to achieve Stage 2 decentralization and opinions on accelerating the decentralization process. Relevant links and resources are provided, including the Foundation’s response and a framework for evaluating rollup maturity. Participation is incentivized with a points system, emphasizing thoughtful contributions. Additionally, a reminder is given that the GovNFT participation program will end on October 18th.\n\nAccelerated Decentralization Proposal For Optimism\nThe “Accelerated Decentralization Proposal for Optimism” outlines a phased plan to transfer system powers and resources from the Optimism Foundation and OP Labs to the governance structure of the OP token. The authors argue that the governance has matured sufficiently to assume control and that the current centralization contradicts the principles of decentralization. The proposal includes three phases: Phase I focuses on immediate transfers like ownership of the OP token and governance contracts; Phase II involves essential infrastructure like the L1 Bridge Escrow and a roadmap for sequencer decentralization; and Phase III aims for full technical control and complete decentralization by mid-2025. The goal is to make OP tokenholders the primary decision-makers, eliminating the need for Foundation’s approval and increasing governance effectiveness.\n\nBadgeholder Onchain Analysis\nThis research analysis, conducted with the Optimism Foundation, delves into the on-chain activities of Badgeholders in the Superchain ecosystem, comparing them with Non-Badgeholders. The findings reveal that Badgeholders, despite having older accounts, show lower activity levels than Non-Badgeholders and prefer Ethereum over other chains. The analysis highlights that Badgeholders primarily engage in token transfers and a few decentralized exchanges, with more than half connected to the social platform Farcaster. The study aims to inform the Optimism Collective on enhancing Badgeholder integration and participation within the Superchain, guiding strategic decisions for community engagement and growth.\n\nZk Toolkit for ZK Application Developers: Mission updates\nWakeUp Labs is developing a Zero-Knowledge (ZK) Identity Toolkit designed for developers building on the Superchain. This toolkit is focused on simplifying the integration of identity-related features using advanced ZK technology, prioritizing self-sovereign identity and privacy. By allowing developers to incorporate ZK proofs into their decentralized applications (dApps), it enhances security and trust between users and applications. WakeUp Labs, selected to lead four Optimism Missions, aims to provide individuals with full control over their identities and privacy. The project aligns with their commitment to delivering top-notch, community-endorsed products that are reusable for future Superchain projects.\n\nImpact Metrics for Retro Funding 5\nIn a recent forum post, Open Source Observer announced its support for Retro Funding 5 (RF5) with new impact metrics focusing on GitHub contributions. These metrics aim to provide voters with valuable data alongside project self-reports. The metrics come in three types: basic GitHub stats, contributor counts, and trust-weighted metrics. The basic stats include stars and forks as of the review conclusion date, contributor counts highlight unique contributors over various periods, and trust-weighted metrics, developed in partnership with OpenRank, rank contributions by developer trustworthiness. These metrics help to better assess a project’s impact within the Optimism ecosystem. The post also provides a detailed breakdown of fields used in the analysis and advises users to consider these alongside other research when voting.\n\nRetro Funding 6: Governance - Round details\nRetro Funding 6 aims to reward contributions to the Optimism Governance, focusing on infrastructure, tooling, analytics, and leadership demonstrated between October 2023 and September 2024. Key dates include the signup period from September 26 to October 10, application reviews from October 14 to 28, voting from October 28 to November 7, with results announced on November 19. The governance impact evaluated spans across multiple seasons, and the round’s OP allocation will range from 1.1M to 3.5M OP, voted upon by citizens. Additionally, there will be experiments with guest voters to enhance the understanding of voter selection methods and their impact on resource allocations. Grants will be distributed through Superfluid, contingent on KYC approval, and must meet a minimum value to qualify for the streaming rewards.\n\nCycle 28 Intent 3A Mission Request and Sponsorship\nIn the “Cycle 28 Intent 3A Mission Request and Sponsorship” forum post, users are invited to propose mission requests for the Grants Council, with a budget of 15,000 OP remaining. The post provides a step-by-step guide for users to submit their requests: copying a provided template, creating a new post with the template filled out, adding specific tags, and marking the title for sponsorship if they are not council members. Users are then asked to link their new posts in the thread replies for consideration.\n\nCycle 27 Grants final roundup\nIn the Cycle 27 grant update, it was reported that all 53 applications were reviewed successfully, with 16 being approved. Special recognition was given to Base, Mode, Swan, Cyber, and Redstone for securing Superchain grants. The Developer Advisory Board was praised for their crucial role in the review process. Looking ahead to Cycle 28, new Mission Requests that have reached quorum are now live, and the team is finalizing a new whitelisting process for auditors. The submission deadline for Cycle 28 proposals is set for Tuesday, the 24th at 19:00 GMT. Applicants are encouraged to refine their proposals based on previous feedback to meet the 40-point threshold for consideration.\n\nGovNFT Governance Topic Thread 2\nIn the “GovNFT Governance Topic Thread 2,” Michael Vander Meiden discusses the upcoming Retro Funding Round 6, focusing on its impact on Optimism Governance. This round allocates between 1.1M OP to 3.5M OP for projects, with the exact amount determined by badgeholders or citizens. There’s also an experiment involving “guest voters.” Questions posed to participants include whether the funding should be at the maximum or minimum level and if random farcaster users should be included as voters, questioning their level of informedness compared to pre-selected badgeholders. High-quality answers can earn up to 26 points, whereas low-effort contributions won’t count towards the total points. Michael encourages participants to check their standings on the GovNFT Leaderboard.\n\n Upcoming Votes\n0 Proposals live at the time of writing this report, no upcoming proposals detected\n\n post by sharp3 on Oct 8, 2024\n\n sharp3\n\n Posting this comment here for transparency, system is not allowing more than 3 consecutive replies from the same account. This comment will refresh the limit\n\n post by Boardroom on Oct 8, 2024\n\n Boardroom\n\n Week of October 7th, 2024\n Recent Proposals\n\nRolling Mission Requests: Voting Cycle 28\n\nSummary: The “Rolling Mission Requests: Voting Cycle 28” proposal seeks to advance the previously approved strategy focused on expanding application developers on the OP Mainnet. Under Intent 3A, this initiative sets a target to engage 9,500 active developers within the Superchain. The voting employs an approval ranking system where Mission Requests must secure a minimum of 51% of the quorum through ‘yes’ votes to qualify for budget allocation. Notably, one of the highlighted Mission Requests aims to boost the adoption of non-USD/EURO stablecoins, utilizing the remaining budget of Season 7. Participants are urged to vote affirmatively on favored Mission Requests, with a reminder that votes are irrevocable once cast. The proposal aligns with the strategic goal of broadening the developer community and optimizing resource allocation in future cycles.\n\nProposer: Optimism Foundation\n\nStatus: Voting in progress\n\n Forum Highlights\n\n[Mission Request] Increase Prevalence of Non-USD/EURO Stablecoins\nIn a recent mission request, Delegate Michael Vander Meiden, known as OPMichael, outlines a plan to enhance the liquidity of non-USD and non-EURO fiat-pegged stablecoins on the Optimism Mainnet. With a total grant of $15,000, this initiative targets projects aiming to develop or grow these stablecoins, crucial for real-world applications like ticketing and payments in countries outside the US and Europe. The mission seeks multiple applicants to address the need for local stablecoins in markets such as Mexico, Thailand, and South Africa. Progress will be tracked through milestones, total value locked (TVL), and activity metrics of these stablecoins, aiming to bolster their adoption and integration into financial infrastructures.\n\nRetro Funding 6: Application Review Process\nThe Retroactive Public Goods Funding (Retro Funding) application review process for Optimism’s sixth round establishes a structured evaluation method for applicants seeking participation. It is conducted by a selected group of Citizens who commit to a minimum of 10 hours over a two-week period post-project signup. Reviewers are expected to be well-versed in OP governance, maintain communication with lead reviewers, adhere strictly to application rules, and declare any conflicts of interest. Reviewers are selected through opt-in and random sampling, culminating in teams that collaboratively assess applications. Applications undergo a multi-stage review, with potential for appeal if initially rejected. Strict rules are enforced to eliminate applications for falsehoods, hateful content, or other violations, ensuring integrity in the funding process.\n\nMeasuring the Concentration of Power in the Collective\nThe forum post introduces the Concentration of Power Index (CPI), a tailored version of the Herfindahl-Hirschman Index, designed to evaluate power concentration within the Optimism Collective. Sponsored by the Optimism Foundation, the research blends individual delegate voting power with the impact of governance entities like Houses, Councils, and Committees. The CPI aims to highlight power distribution and its potential risks, facilitating policy adjustments towards decentralization. The analysis reveals that the Citizens’ House wields the most influence, followed closely by the Token House. The CPI tracks the trend of decentralization over different governance rounds and seasons, showing a significant decline in power concentration, indicating successful decentralization efforts. The report also compares the CPI across various DAOs, illustrating Optimism’s balanced approach to governance and its commitment to equitable power distribution.\n\nAnnouncing Super Contributor Cohort 0\nThe forum post announces the launch of Super Contributor Cohort 0 following the approval of their Mission Request. This six-week co-learning track is designed for Superchain contributors within the Optimism Collective, aiming to equip them with the necessary skills and insights to elevate their contributions. The cohort includes the Optimism Contributor Essentials MOOC, weekly meetings, various on-chain exercises, and a meetup in Bangkok. Interested individuals can access more information through provided links and are encouraged to share this opportunity with colleagues and friends involved in on-chain organizations.\n\nCollective Feedback Commission Pilot Retrospective\nIn a recent forum post, the Foundation evaluated its six-month pilot of the Collective Feedback Commission (CFC), aimed at formalizing feedback processes within the community for improved governance. The pilot saw groups like Token House and Citizens’ House provide essential feedback on early design drafts and contributed ideas that exceeded initial success goals. Key learnings included the need for clear initial expectations, reducing context gaps for meaningful feedback, and ensuring feedback loops are closed with participants. Plans for the next iteration include enhancing collaboration, refining membership criteria, and hosting a kickoff to align goals and expectations. The ultimate aim is to decentralize governance design responsibilities, fostering a culture of high-value feedback and engagement. Launch of the next phase is anticipated in early November, emphasizing a more persistent structure with dedicated leadership and resources to manage the process effectively.\n\nCycle 28 Grants Preliminary Roundup\nIn the Cycle 28 Grants Preliminary Roundup, 61 applications were received, encompassing both Superchain and audit applications. Of these, 28 were declined either during the initial intake or the preliminary round, leaving 33 applications advancing to the final review. A standout initiative this cycle was the Auditor Whitelisting Initiative, successfully expanding the list of approved audit service providers to eleven. Applicants can access scores and feedback through their application portals, promoting transparency and aiding improvement. The preliminary cutoff was set at 30 points, while finalists, to be announced next Thursday, require a minimum of 40 points. Gratitude is extended to the Developer Advisory Board and Grants Council for their valuable contributions. A link to the finalists’ database is also provided for access.\n\ngovNerds Maintainers S6 feedback thread\nIn the Govnerds Maintainers Season 6 feedback thread, user Megalod commends the team for their dedication and highlights both achievements and areas for improvement. The post acknowledges the efforts in transparency regarding governance updates but notes occasional delays and lack of detail, suggesting enhanced communication. It praises community engagement initiatives but suggests boosting participation with new onboarding and educational techniques. The decision-making process is seen as inclusive yet occasionally dominated by certain voices, calling for broader representation. Concerns about slow implementation of decisions are raised, advocating for improved efficiency, while innovation receives acclaim with a recommendation for more educational resources to bridge knowledge gaps. Overall, the feedback remains optimistic about the progress and anticipates further growth in the next season.\n\nJoint House Call\nJoin us on October 8th for the next Optimism community call, where we’ll delve into Retrofunding rounds 5 and 6. The meeting will take place via Google Meet, and everyone is welcome to contribute ideas for the agenda. We’re excited to see you there and discuss the impact and future of retroactive public goods funding. Feel free to drop any suggestions for the discussion topics beforehand. Let’s make this call productive and engaging! See you soon — Michael.\n\nImpact Metrics for Retro Funding 5\nIn the forum post titled “Impact Metrics for Retro Funding 5,” Open Source Observer discusses their support for the latest retro funding round by offering a suite of impact metrics tailored for OP Stack contributions. These metrics aim to provide human voters with valuable “data in the loop” to complement projects’ self-reported impact statements. The metrics are categorized into basic GitHub stats, contributor counts (including trusted contributors), and trust-weighted metrics, which use OpenRank algorithms to assess contributions across numerous repos. The post details the fields included in the analysis, such as contributor numbers and GitHub stars, and emphasizes the evolving nature of these metrics. It notes that while these metrics are helpful, they rely solely on public GitHub activity and should not replace thorough due diligence by voters. The complete source code and data are available for public scrutiny, inviting feedback and discussion on GitHub.\n\nCycle 28 Intent 3A Mission Request and Sponsorship\nThe forum post titled “Cycle 28 Intent 3A Mission Request and Sponsorship” calls for mission proposals to be considered by the Grants Council, with a remaining budget of 15,000 OP. Participants are instructed to follow specific steps: copying the provided template, creating a new forum post, tagging it appropriately, and indicating if they are seeking sponsorship. The post encourages engagement by accessing a linked template and requires users to share the link to their proposal in the forum thread.\n\nRetro Funding 5: Bribery Policy\nIn the forum post titled “Retro Funding 5: Bribery Policy,” the discussion focuses on the anti-bribery policy for Round 5 of the Optimism protocol’s governance. Participants, known as Optimists, are urged to avoid self-dealing, with mechanisms in place to reduce these opportunities through incentive designs and voting. The policy outlines a reporting and enforcement process for tackling bribery, requiring three separate reports to validate allegations, followed by enforcement actions. These actions include disqualification from future rounds or removal from current funding opportunities, subject to Citizens’ House approval. Any enforcement proposal must be presented and is subject to veto within a week. The post emphasizes the evolving nature of governance decisions concerning bribery and self-dealing.\n\nBadgeholder Onchain Analysis\nThe forum post titled “Badgeholder Onchain Analysis” delves into the on-chain behavior of Badgeholders within the Superchain ecosystem, which encompasses networks like OP Mainnet, Base, Zora, and Mode. The analysis contrasts Badgeholders with Non-Badgeholders, revealing that while Badgeholders have a significant account age, their overall activity is lower. Badgeholders favor transactions on Ethereum and engage heavily in token transfers on a limited number of decentralized exchanges. A significant portion of them are also connected with Farcaster, suggesting high social engagement. The insights from this study aim to help the Optimism Collective enhance Badgeholder participation and community integration across the Superchain.\n\nZk Toolkit for ZK Application Developers: Mission updates\nWakeUp Labs is developing a ZK Identity Toolkit for developers building on the Superchain, prioritizing self-sovereign identity and privacy through cutting-edge zero-knowledge (ZK) technology. This toolkit is designed for seamless integration with decentralized applications (dApps), enhancing security and user trust by enabling developers to incorporate ZK proofs effectively. The mission is to empower individuals with full control over their identities, ensuring privacy and security. WakeUp Labs will continue updating the community on their progress via this thread and encourages followers to stay connected through social media for further updates.\n\nCycle 28 Grants Council Audits implementation\nOptimism Collective has launched a new audit mission request system approved by the Token House, simplifying the process for eligible auditors to apply for specific audits. This initiative allows auditors to simultaneously apply for whitelisting and audit jobs, eliminating the need for pre-approved budgets. Key to its operation are three steps: applying for the whitelist, submitting audit applications, and reaching out to whitelisted audit providers via the audit hub. This process aims to bolster the Optimism ecosystem by subsidizing smart contract audits for promising projects. The Grants Council and a subcommittee review the whitelisting applications using a five-question rubric focused on the applicant’s experience and transparency.\n\n Upcoming Votes\n1 Proposals live at the time of writing this report, no upcoming proposals detected\n\n post by Boardroom on Oct 14, 2024\n\n Boardroom\n\n Week of October 7th, 2024\n Recent Proposals\nNo live Proposals\n Forum Highlights\n\nSuperchain Product Vision\nThe Superchain Product Vision outlines Optimism’s strategic direction to scale Ethereum technology through a decentralized network of interconnected chains, each governed under Optimism. The vision emphasizes the importance of standardization, ensuring decentralization and composability at scale, where chains can benefit from collective upgrades and security measures while maintaining unique customizable features. Initially comprising 15-50 chains that operate cohesively, the Superchain aims to expand beyond 1000, offering seamless user experiences with sub-second transaction speeds. Governance plays a critical role in maintaining security, democratic decision-making, promoting sustainable economic growth, and preventing exploitative business models. The document highlights a collaborative approach, inviting feedback and reviews to fine-tune the vision over time.\n\nAnnouncing Super Contributor Cohort 0\nSuperchain Eco has launched the Super Contributor Cohort 0 after their Mission Request was approved. This new initiative is a six-week co-learning program designed for Superchain contributors, aiming to equip both new and existing members of the Optimism Collective with essential skills and insights to excel as contributors. The program includes the Optimism Contributor Essentials MOOC, weekly meetings, onchain exercises, and a special meetup in Bangkok. Interested parties can find the full program details on their blog and complete the application form online. Superchain Eco encourages sharing this opportunity with colleagues and friends interested in contributing to onchain organizations.\n\n[Mission Request] Increase Prevalence of Non-USD/EURO Stablecoins\nThe forum post discusses a mission request aimed at increasing the liquidity of non-USD and non-EURO stablecoins on the OP Mainnet. The initiative targets projects intending to enhance liquidity or develop new fiat-pegged stablecoins, specifying a total grant of 15k with potential distribution among multiple applicants. The primary goal is to address the lack of local stablecoins for applications in regions outside the US and Europe, such as ticketing and payments apps. Execution requirements include the provision of incentives for stablecoins pegged to currencies like the Mexican Peso, Thai Baht, or South African Rand. Success will be measured by milestones like deployment and usage on the Mainnet, as well as metrics including the total value locked (TVL) and stablecoin liquidity and usage activity.\n\nMid-Season 6 Grants Council Report\nThe “Mid-Season 6 Grants Council Report” outlines the progress and key statistics of the Grants Council during Season 6. A total of 222 applications have been submitted, with 53 grants and 9 Superchain grants receiving approval. Over 170 applications cleared the initial review stage, assessed by at least six reviewers. Additionally, 47 mission requests were evaluated, with 32 created by the Grants Council. The report provides a detailed breakdown by review cycles: Cycle 25 processed 60 applications, approving 15; Cycle 26 received 70, approving 17; Cycle 27 had 53, approving 12; and Cycle 28 received 50 applications, 9 of which have been approved with 2 pending. Throughout this period, a subcommittee reviewed 148 completed projects, reporting back to The Foundation.\n\nRF6 Season 5 Grants Council Report\nThe RF6 Season 5 Grants Council Report highlights the achievements and activities of the Grants Council. The key points include receiving over 530 applications, approving 128 grants, and endorsing 5 smart contract audit services. Out of the total applications, more than 200 cleared the preli","tokens":15000,"squid":"spider-07","role":"Council Spider","at":1791347542816,"hash":"8119443681accd5e3b5ae2311898db943926645f"}
{"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":"spider-06","role":"Security Spider","at":1791347549736,"hash":"bd7f45779bb2b0d59c9bbdf6b288ee91a1e26fdf"}
{"url":"https://gov.optimism.io/t/gfx-labs-delegate-communication-thread/2728/65","domain":"gov.optimism.io","title":"GFX Labs - Delegate Communication Thread - Communications 📣 / Delegate Updates - Optimism Collective","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 51\n\n 2\n\n read \n\n 62\n min\n\n Jun 2022\n\n 64 / 64\n\n Apr 21\n\n Apr 21\n\n Load more posts above\n\n post by GFXlabs on Dec 18, 2024\n\n GFXlabs\n\n 11 Polls Closing December 18, 2024\nOnchain Treasury Transfer Cancellation Test\nSummary: This poll is a test of the emergency cancellation measure for malicious or erroneous funds transfers.\nRecommendation: Vote For. This is a test of the emergency cancellation functionality.\nUpgrade Proposal #11: Holocene Network Upgrade\nSummary: This poll asks OP holders if they support implementing the Holocene Network Upgrade.\nThis upgrade includes several components, the first of which is a change to block derivation. Span batches will now be strictly ordered, and invalidation occurs only from the point of invalidity, allowing for partial span batch validation.\nIt also adds EIP-1559 configurability.\nThe final change is a simplification of fee scalar configuration.\nRecommendation: Vote For. The changes to derivation are primarily focused at removing code that appears to be unnecessary based on experience, and simplifying the code base in this area. From a practical standpoint, this places more emphasis on the Sequencer to keep the chain running smoothly, but does not empower the Sequencer with anything it does not possess today. OP Labs has communicated that the Sequencer software already is capable of handling this increased burden.\nEIP-1559 allows for elastic gas limits, which scale costs towards a target. This was developed at the request of other OP stack operators, and we’re not sure we understand the argument that Optimism itself needs or wants this change, but will defer on this subject since it should not impact Optimism until/unless a future proposal changes the parameters for this.\nMore generally, only one portion of this update was audited. This is consistent with the OP Labs Audit Framework, but is still not a best practice, and is a clear case of being pennywise and pound-foolish. We would support governance stepping in to provide audit subsidies to developers authoring network upgrades if OP Labs and OP Foundation feel they cannot afford to audit every upgrade by default.\nSeason 7: Intent Ratification\nSummary: This poll asks OP holders if they support ratification of a single Intent for Season 7, which is encouraging and improving interoperability. Formally:\nA set of interoperable Stage 1 chains doing $250m per month in cross-chain asset transfers.\nRecommendation: Vote For. Optimism has bet the farm on interoperability. Supporting that should be the top priority.\n[Season 7: Anticapture Commission Amendment\n](Season 7: Anticapture Commission Amen...)Summary: This poll asks OP holders if they support amending the Anticapture Commission charter. Full details can be found here.\nRecommendation: Vote For. These changes seem acceptable, and from a practical perspective will not alter much, except requiring the ACC participate in discussions where the Citizens’ House may consider a veto. In the future, providing a budget for the ACC, rather than relying upon retroactive funding, would be preferred.\nSeason 7: Grants Council Operating Budget\nSummary: This poll asks OP holders if they support a Grants Council operating budget of 400,000 OP. Of that, 50,000 OP is a reserve budget, in case demand is high and additional reviewers are needed mid-Season.\nThis is a 210,000 OP reduction from Season 6, mainly in response to a smaller number of total reviewers, and splitting the Milestones & Metrics Subcommittee out into its own structure.\nRecommendation: Vote For. This budget is, on a per-item basis, in line with expectations, and does not present any major surprises.\nSeason 7: Developer Advisory Board Operating Budget\nSummary: This poll asks OP holders if they support a DAB operating budget of 190,000 OP.\nThis is a 100,000 OP increase from Season 6. The difference is largely driven by the addition of two new roles to aid with Foundation Missions, and modest increases to the compensation of all members in OP.\nRecommendation: Vote For. The DAB has generally demonstrated a high level of usefulness, both to the Grants Council, and in community understanding and evaluation of protocol upgrades.\nSeason 7: Milestones and Metrics Council Operating Budget\nSummary: This poll asks OP holders if they support a M&M operating budget of 170,000 OP.\nRecommendation: Vote For. This is the first time the M&M has been under its own budget, so there is little to compare it to. The total combined budgets of the M&M and the Grants Council is still less than the total last season, which suggests that it is reasonable. Even if there is additional cost in spinning it out into its own body, there is a strong argument that the M&M should be independent of the Grants Council, since it is in many ways checking the work of the Grants Council’s chosen grantees.\nCode of Conduct Council Dissolution Proposal\nSummary: This poll asks if OP holders support dissolving the Code of Conduct Council.\nRecommendation: Vote For. While we think the CoCC held value as a contribution path for junior members of governance, we agree that it is unnecessary and governance can be minimized in this area.\nSeason 7: Security Council Operating Budget [Onchain]\nSummary: This poll asks if OP holders support an operating budget of 295,000 OP for the Security Council.\nThis is around 200,000 OP increase from the previous Season, which was funded by the Foundation.\nThe proposal will execute on-chain to the following multisig address: 0x42415E7D47Fb8080eb42f870BC2e04Ab0852a264\nRecommendation: Vote For. The Security Council should answer to governance, so it needs to be funded by governance, rather than the Foundation.\nGrants Council Mission [Onchain]\nSummary: This poll asks if OP holders support transferring 10,000,000 OP to the Grants Council for the purposes of funding grants supporting the Season 7 Intent. The Grants Council would have full discretion in executing this mission.\nThis is an 8,500,000 reduction in grants budget from Season 6.\nThe proposal will execute on-chain to the following multisig address: 0x1795652665fAa2dfeF9865544ae8D3c65f9643A8\nRecommendation: Vote For. This is the first time that the Grants Council will directly control funds it grants. The budget is smaller, which mostly reflects the decision not to continue the Superchain Grants program from Season 6.\nDecision Market Mission [Onchain]\nSummary: This poll asks OP holders if they support providing 500,000 OP to support projects utilizing the Decision Market. Butter, the Uniswap Foundation, and the Optimism Foundation are ineligible.\nThe proposal will execute on-chain to the following multisig address: 0x1795652665fAa2dfeF9865544ae8D3c65f9643A8\nRecommendation: Vote For. It’s not entirely clear how these funds will be distributed, except that it will be done algorithmically, tied to market outcomes. It would be nice to know more about what that algorithm will look like, but it’s recognized that some liquidity or incentives will be needed to seed this decision market experiment. Whether it succeeds or fails will inform whether further funding is warranted in the future.\n\n 27 days later\n\n post by GFXlabs on Jan 15, 2025\n\n GFXlabs\n\n 9 Polls Closing January 15, 2025\nSecurity Council Elections Cohort B Members\nSummary: This poll asks OP holders which candidates to elect to the Security Council. There are 6 open seats.\nCandidates:\nWorld Foundation\nAndrey Petrov\nOP Labs\nL2BEAT\nAlchemy\nMaggie Love\nGauntlet\nTest in Prod\nYoav Weiss\nMl_sudo\nKris Kaczor\nMartin Tellechea\nInk\nCoinbase\ntroy\nRecommendation: Vote L2BEAT, Test in Prod, Yoav Weiss, Kris Kaczor, Martin Tellechea, Alchemy. L2Beat is a widely respected L2 watchdog group with plenty of technical expertise and multiple personnel available. Test in Prod, Yoav Weiss, Kris Kaczor, and Martin Tellechea previously served as Security Council members successfully. Test in Prod and Yoav Weiss make/have made technical contributions in the past to OP stack as well. Alchemy is included as another organization with deep technical expertise and multiple personnel available in the event of an emergency.\nGrants Council Operations Elections\nSummary: This poll asks OP holders which candidates to elect to the operations role for the Grants Council. There is 1 open seat.\nRecommendation: Vote Bunnic. Nic is the only candidate, and also successfully served in this role in Season 6.\n[Developer Advisory Board Foundation Mission Team Elections\n](Developer Advisory Board Foundation M...)Summary: This poll asks OP holders which candidates to elect to the Developer Advisory Board (Foundation Mission Team). There are 2 open seats.\nCandidates:\nEd\nSkeletor\nDanyal\nRecommendation: Vote Ed, Skeletor, Danyal. These are all three fantastic candidates and the DAB would be lucky to have all of them. Ed (aka wildmolasses) successfully served on the DAB last season, and, in our capacity as a Grants Council reviewer, we found their input useful. Skeletor is a co-founder of Wonderland, and Danyal is a core contributor hailing from the Base team.\nDeveloper Advisory Board Governance Mission Team Elections\nSummary: This poll asks OP holders which candidates to elect to the Developer Advisory Board (Governance Mission Team). There are 3 open seats.\nCandidates:\nWill\n[Jepsen\n](Season 7 Nominations: Governance Mission Team on the Developer Advisory Board - #3 by Jepsen)Blockdev\nGodspower\nCooper01\nBeskay\nShubham\nIain\n\nRecommendation: Vote Will, Jepsen, Blockdev. Will and Blockdev successfully served on the DAB in Season 6. Jepsen successfully served on the DAB in Season 5. We would enjoy working with them again.\nDeveloper Advisory Board Audit Request Team Elections\nSummary: This poll asks OP holders which candidates to elect to the Developer Advisory Board (Audit Request Team). There are 2 open seats.\nCandidates:\nM4rio.eth\nNoah.eth\nSujith\nGjaldon\nVagner\n0x73696d616f\nShogoki\nUnsafe_call\n\nRecommendation: Vote gjaldon, 0x73696d616f, m4ario.eth, noah.eth. Gjaldon has successfully located bugs in Optimism itself, and 0x7369 has an impressive background as the former head of Three Sigmas. M4ario and Noah both also have exceptional experience through Spearbit.\n[Milestones and Metrics Council Reviewer Elections\n](Milestones and Metrics Council Review...)Summary: This poll asks OP holders which candidates to elect to Milestones and Metrics Council. There are 3 open seats.\nCandidates:\nmel.eth (StableLab)\nLauNaMu\nAnthiasLabs\nMmurthy\nPavel\nv3naru_Curia\nTakeshi (Tané)\nPumbi (SEEDGov)\nAngela\nRecommendation: Vote Takeshi (Tane), AnthiasLabs, v3naru_Curia. Takeshi and AnthiasLabs both served on the Grants Council in Season 6, which means they will have a good understanding of how grants were awarded and will be measured. v3naru_Curia is an experienced member of the Milestones & Metrics Committee in Season 5 and 6 when it was part of the Grants Council.\nGrants Council Final Reviewer Elections\nSummary: This poll asks OP holders which candidates to elect to the Grants Council as final reviewers. There are 4 open seats.\nCandidates:\nMattGov.eth\nGFX Labs\nMichael\nJackanorak\nAreta\nMoneyManDoug\nJashFi\n\nRecommendation: Vote GFX Labs, MattGov.eth, Michael, Jackanorak, MoneyManDoug. Matt, Michael, Jack, and MoneyManDoug have successfully served on the Grants Council for multiple seasons. Jack served with us on the Superchain Grants subcommittee last season as well. We have also successfully served for the entire existence of the Grants Council and vote for ourselves to advance Optimism.\nGrants Council GrantNerd Elections\nSummary: This poll asks OP holders which candidates to elect to the Grants Council as GrantNerds. There are 3 open seats.\nCandidates:\nMegalod\nKumahada\nRamadhan\nBrichis\nJrocki\nMastermojo\nSov\nMarcus01\nDebbie\nUgbuericsam\nLiliop.eth\nglory_Sherlock\nRecommendation: Vote Jrocki, Mastermojo, Brichis. All three of these candidates successfully served on the Grants Council in Season 6. While we can only fill three seats, we also want to recognize Sov, who successfully served last season as well.\nSeason 7: Chain Delegation Program Amendment\nSummary: This poll asks OP holders if they support amending the Chain Delegation Program to prioritize satisfying the Standard Rollup Charter criteria as the most important criteria instead of the last criteria. The Standard Rollup Charter can be found here.\nRecommendation: Vote For. This is a reasonable amendment and should encourage chains to migrate to more technically robust features in some cases.\n\n 20 days later\n\n post by GFXlabs on Feb 5, 2025\n\n GFXlabs\n\n 1 Poll Closing Feb 5, 2025\nProtocol Upgrade: Superchain Registry 2.0\nSummary: This poll asks OP holders if they support amending the Superchain Registry requirements. Changes are largely putting emphasis on new members deploying via the OP Contracts Manager (OPCM) and having the most current, substantively unaltered code base.\nRecommendation: Vote For. While the OPCM has not yet been audited, it has been in use for 4 months. The increased emphasis on standardization across OP chains is appropriate, given that interoperability probably depends on consistent assumptions about technical and security risks. While this is considered a protocol upgrade for governance purposes, no onchain action need be taken by governance, since the changes are for deployments of new chains.\n\n 27 days later\n\n post by GFXlabs on Mar 4, 2025\n\n GFXlabs\n\n 1 Poll Closing March 4, 2025\nMaintenance Upgrade: L1 Pectra Readiness\nSummary: This poll asks OP holders if they support a protocol upgrade to harmonize OP stack with the Pectra mainnet upgrade.\nNB: This is an optimistic poll, where voting is only required if OP holders oppose the proposal.\nRecommendation: Do Not Vote. This is an optimistic proposal, and we do not oppose upgrading OP mainnet to be compatible with Pectra.\n\n 15 days later\n\n post by GFXlabs on Mar 19, 2025\n\n GFXlabs\n\n 1 Poll closing March 19, 2025\nUpgrade Proposal #13: OPCM and Incident Response improvements\nSummary: This upgrade includes several improvements for upgrading L1 contracts across the Superchain, and a Superchain-wide pause function accessible by the Optimism Foundation Safe. These changes have been audited by Offbeat Labs and Spearbit.\nRecommendation: Vote For. These changes are primarily ways to streamline existing functions to make them less cumbersome and more able to respond to time-sensitive incidents.\nNB: We missed this vote, but are publishing our prepared comment for the record.\n\n 20 days later\n\n post by GFXlabs on Apr 9, 2025\n\n GFXlabs\n\n 2 Polls Closing April 9, 2025\nUpgrade Proposal #14: Isthmus L1 Contracts + MT-Cannon\nSummary: This poll asks OP holders if they support upgrading L1 contracts to support a hard fork for the Isthmus upgrade (see Upgrade Proposal #15), as well as upgrades to the fault proof VM (Cannon). The Cannon upgrade is designed to remove memory constraints and alters how multi-threading occurs. New operator fee parameters were also introduced.\nWe strongly recommend voters read the full summary of technical changes here.\nRecommendation: Vote For. These changes are prerequisite for Isthmus, and also implement changes expected to improve the fault proof challenge system. The operator fee changes allow for different OP stack chain operators to better customize fees to suit their own provability stack if they so choose, as well as provide flexibility for other ways to utilize the fee. External audits or reviews for this and Upgrade Proposal #15 were completed by Coinbase and Spearbit.\nUpgrade Proposal #15: Isthmus Hard Fork\nSummary: This poll asks OP holders if they support implementing the Isthmus upgrade. This upgrade introduces support for eight new EIPs associated with Pectra, and changes to the fault proof VM and operator fee parameters mentioned in Upgrade Proposal #14. Operator fees will be disabled by default.\nWe strongly recommend voters read the full summary of technical changes here.\nRecommendation: Vote For. This upgrade is required to fully take advantage of and harmonize Optimism with the Pectra update on mainnet. External audits or reviews for this and Upgrade Proposal #15 were completed by Coinbase and Spearbit.\n\n 20 days later\n\n post by GFXlabs on Apr 29, 2025\n\n GFXlabs\n\n 2 Polls Closing April 30, 2025\nSeason 8 and 9: Budget Board Member Ratification\nSummary: This poll asks OP holders if they support the creation of a Budget Board, which would be tasked with making recommendations on annual budgets for Citizens’ House and Token House, as well as make recommendations on how to proceduralize the staking of more ETH collected by the sequencer on behalf of Optimism governance.\nBoard member terms would be 12 months, with half the board elected in the future by Token House and half by Citizens’ House, and one nonvoting board lead.\nAn inaugural board has been submitted by the Foundation (affiliations in parentheses):\nLead:\nDane Lund (Alliance DAO)\nToken House Representatives:\nXochitl Cazador (Optimism Foundation)\nMichael Silberling (OP Labs)\nKatie Garcia (UDHC)\nCitizens’ House Representatives:\nCarl Cervone (Open Source Observer)\nDivya Siddarth (Collective Intelligence Project)\nEva Beylin (Optimism Foundation; The Graph Foundation)\nOperational expenses are expected to be 220,000 OP for Seasons 8 and 9, but will be covered by the Foundation.\nRecommendation: Vote For. Overall, this is a solid slate of initial members. Over time, we would like to see a steady movement away from Labs and Foundation affiliates given the potential for conflicts of interest that creates, since representatives are supposed to represent Citizen and Token Houses. Dane Lund, the proposed lead, was the inaugural lead for the Optimism Grants Council, which has generally been a success and has become the template for many grants programs outside Optimism.\nMaintenance Upgrade: Absolute Prestate Updates for Isthmus Activation & Blob Preimage Fix\nSummary: This poll asks OP holder if they support setting May 9th as the date to hard fork into the previously approved Isthmus upgrade. This update also includes a fix for a bug. Full details can be found here, and delegates are encouraged to review it.\nNB: This is an optimistic proposal and will pass unless defeated.\nRecommendation: Do not vote (optimistic approval). This is a bug fix and sets a specific time and date for the Isthmus hardfork, which was already approved.\n\n 1 month later\n\n post by GFXlabs on Jun 10, 2025\n\n GFXlabs\n\n 1 Poll Closing June 11, 2025\nSeason 8 and 9 Milestone and Metrics Council Selection\nSummary: This poll asks OP holders if they support altering the selection process for Milestones and Metrics Council. The new selection process would become use of sortition (randomly choosing) amongst a pool of candidates that must meet one or more of the following criteria:\n\nAnalytics Skills\n\nPrevious M&M Council service\nCompleted relevant analytical Foundation Mission\n\nReputation in the Collective\n\nContributor above wannabe level\nHeld a governance role in Season 6 or 7\n\nOperational Security\n\nCompleted OpSec training by Opsek\n\nRecommendation: Vote Against. As we extensively argued during the governance call where this idea was first introduced, sortition has few successful examples in history, and relies upon an unshakeable belief that the process will be fair and transparent.\nSortition was famously used in Ancient Greece and some of the Northern Italian city-states like Venice and Genoa as a way to combat corruption and nepotism. Notably, even processes with multiple rounds of sortition failed to prevent the sons of previous rules being elected based upon their bloodline and political connections.\nGreek and Italian sortition, however, had a major advantage over Optimism: the sortition was simple and performed physically in public (e.g. drawing colored stones out of a jar). In an industry that says to verify everything, the Foundation has not presented a method of sortition that would be transparent to observers, and would effectively be the Foundation stating they performed the random selection in private and then reporting the results.\nSortition, at its core, is about transparency and fairness. There is little reason, based on the information presented in the call and on the forum, that the sortition process for selecting this technocratic role would be transparent – and so it follows, also no guarantee of fairness.\nCritically, sortition makes people unaccountable – there is no impact on chances of serving a new term unless a person is so negligent as to be disqualified in the next round – and also is blind to competence. The qualification criteria presented is generally just previous experience in governance, which is confusing because it locks in incumbents from a practical perspective – not a traditional goal of sortition, which is typically trying to remove them.\nMore broadly, this is part of a long history of experimentation with public choice in Optimism (futarchy, retro funding rounds, bicameralism). In general, these have all been interesting but ultimately wasteful (a large share of retro funding) or not impactful (bicameralism). At this point, we are requesting the Foundation pause conducting political and public choice experiments, so that resources can be focused on value-additive contributions to Optimism and the Superchain.\nThese are all generally points we raised on the governance call, and have not seen a response that satisfies our questions and criticisms of using random selection to fill a technocratic role.\n\n Season 8 and 9 Milestone and Metrics Council Selection\n\n 20 days later\n\n post by GFXlabs on Jun 30, 2025\n\n GFXlabs\n\n 5 Polls Closing July 2, 2025\nSeason 8/9 Grants Council Charter\nSummary: This poll asks OP holders if they support an amended charter for the Grants Council to cover both Season 8 and Season 9. The main substantive effect is renewal of the Grants Council as an entity and re-election of Gonna.eth as the Lead.\nRecommendation: Vote For. GFX Labs has served on the Grants Council since its inception, including the Seasons where Gonna has been the Lead. He has done an excellent job to date, and we have full confidence in his ability to continue to deliver value to OP holders through an organized, publicized, and thoughtful grants program.\nSeason 8/9 Milestones and Metrics Council Charter\nSummary: This poll asks OP holders if they support an amended charter for the Metrics and Milestones Council to cover both Season 8 and Season 9. The main substantive effect is renewal of the Metrics and Milestones Council as an entity and re-election of PGov as the Lead.\nRecommendation: Vote For. GFX Labs has worked closely with PGov, both during the time that Metrics and Milestones was internal to the Grants Council and during collaboration at other protocol governances. PGov operates in a professional, low-drama manner, which is exactly what is needed for the Metrics and Milestones Council.\nGovernor Update Proposal: Removing Abstain Count from Quorum\nSummary: This poll asks OP holders if they support removing abstentions from quorum calculation. The update to the governor has been tested and audited.\nRecommendation: Vote Against. On the one hand, quorum tends to be harder to maintain over time, and this exacerbates that problem. On the other hand, that is a larger issue that requires a comprehensive solution. Referring to practices in governmental and corporate settings, presence is typically counted towards quorum, rather than active vote. Stretching that analogy to DAOs, a vote to Abstain is effectively attendance without voting, which does count towards quorum in most settings.\nAs additional context, we have seen other major DAOs, like Uniswap, now struggle to achieve quorum. We also view this as a low-stakes issue, since abstentions are relatively rare in Optimism DAO votes.\nSeason 8/9 Developer Advisory Board Charter\nSummary: This poll asks OP holders if they support an amended charter for the Developer Advisory Board to cover both Season 8 and Season 9. The main substantive effect is election of the Developer Advisory Board as an entity and re-election of Ed (aka wildmolasses) as the Lead.\nRecommendation: Vote For. Our past interactions with wildmolasses and the DAB in our capacity as grants reviewers have found him to be helpful and thoughtful.\nSeason 8: Intent Ratification\nSummary: This poll asks OP holders if they support the following high-level goal for Season 8:\nA set of interoperable Stage 1 chains doing $100m per month in cross-chain asset transfers\nRecommendation: Vote For. This overall goal for Season 8 is consistent with the emphasis on the to-be-shipped interop upgrades. Note that the Intent for Season 7 was a set of interoperable Stage 1 chains doing $250m per month in cross-chain asset transfers, despite interoperability not shipping during Season 7. This new Intent marks a significantly more conservative goal.\n\n 8 days later\n\n post by GFXlabs on Jul 8, 2025\n\n GFXlabs\n\n 2 Polls Closing July 9, 2025\nUpgrade 16 Proposal: Interop Contracts, Stage 1, and Go 1.23 Support in Cannon\nSummary: This poll asks OP holders if they support a bundle of protocol upgrades. The main portion of the upgrades is to prepare OP stack chains for interoperability. Additionally, the permissioned DeputyGuardianModule is removed, in order to maintain a Stage 1 rating according to the L2Beat rollup categorization method. Other changes to keep OP up to date with Ethereum are also included, as well as a maximum gas limit for OP stack chains.\nIn addition to internal reviews at OP Labs, the code was reviewed via contest on Cantina and audited by Spearbit.\nRecommendation: Vote For. None of these are controversial changes, and only concerns about security would cause us to vote against.\nBudget Board Advisory Proposal for the DAO Operating Budget for Seasons 8 and 9\nSummary: This poll asks OP holders if they support an annual operational budget cap of 4,440,000 OP.\nRecommendation: Vote For. The Budget Board revised this number up from 2,300,000 OP after delegate feedback, including our own. This budget cap doesn’t have to be spent, but is enough that it will prevent council leads from being overly competitive for resources, and better reflects that governance needs operational budget to expand to take over some activities currently run by the Foundation.\n\n 20 days later\n\n post by GFXlabs on Jul 28, 2025\n\n GFXlabs\n\n 8 Polls Closing July 30, 2025\nAnticapture Commission Dissolution Proposal\nSummary: This proposal would formally dissolve the Anticapture Commission.\nRecommendation: Vote Abstain. While we have consistently been of the view that the Anticapture Commission did not play a vital role, it has also evolved into one of the few “junior contributor” roles for delegates and stakeholders looking to become involved in governance. The ACC’s activities generally enforce a certain level of context amongst its active members, and a position on the ACC has served as a stepping stone to more senior roles in the past. So the ACC has value as part of the pipeline of building a more diverse and deeper bench of governance participants. However, we cannot bring ourselves to vote against its dissolution simply on the basis of being make-work.\nGrants Council Election: Final Reviewer\nSummary: This poll asks OP holders which candidates should fill the four seats for Final Reviewer on the Optimism Grants Council.\nCandidates:\nAle77.eth\nBrainstorm\nDoug sugma\nGFX Labs\nGlory-eth\nMaksym\nMasterMojo\nMattgov.eth\nMichael\nMignenkoff.eth\nRe7 Labs\nTeamforce.eth\nvwtao.eth\nNB: This is approval voting, and voters may select more candidates than there are seats.\nNB: GFX Labs is a candidate\nRecommendation: Vote GFX Labs, Mattgov.eth, Michael, Doug Sugma, Mastermojo. Including ourselves, we are confident that all of the incumbent members of the Grants Council can continue to build out a more active and impactful role for the Grants Council in reviving Optimism’s DeFi ecosystem and supporting members of the Superchain.\nGrants Council Election: Operations\nSummary: This poll asks OP holders which candidate should fill the one seat for Operations on the Optimism Grants Council. This is a non-voting role.\nCandidates:\nBunnic\nRecommendation: Vote Bunnic. Nic previously served in the Operations role last Season and did a good job.\nSeason 8/9 Operating Budgets\nSummary: This poll asks OP holders if they support each of the four council operating budgets.\n\nThe Developer Advisory Board Operating Budget for Season 8 and 9 is proposed by Ed/wildmolasses with an operating budget of 974k OP\nThe Grants Council Operating Budget for Season 8 and 9 is proposed by Gonna.eth with an operating budget of 980k OP\nThe Milestones & Metrics Council Operating Budget for Season 8 and 9 is proposed by PGov with an operating budget of 989.4k OP\nThe Security Council Operating Budget for Season 8 and 9 is proposed by alisha.eth with an operating budget of 1.514.440 OP\n\nNB: This is a threshold-based vote. All budgets that receive at least 17m votes will be approved.\nRecommendation: Vote For on all budgets. Note that the total is slightly higher than the 4.44m OP approved budget cap, which will result in a small, de minimis reduction to all budgets if all four are selected.\nDeveloper Advisory Board Election: Members\nSummary: This poll asks OP holders which candidate should fill the seven seats for the Developer Advisory Board. Previously there were three committees elected separately.\nCandidates:\n0x937…c1B\nBlockdev\nDenispro2015.base.eth\nDevtooligan\nKalambet Peter\nM4rio\n𓀣 Odysseas.eth 𓀢\nShazow\nVectorized\nWbnns\n\nNB: This is a Joint House Vote.\nRecommendation: Vote Blockdev, M4rio, devtooligan, wbnns, Odysseas.eth\nBlockdev is seeking reelection and served well last season.\nM4rio previously served on the Audits Subcommittee for the Grants Council in Season 6, and is an active top 1% OP stack developer.\nDevtooligan served on the DAB in Season 6, and served well.\nWbnns is seeking reelection and served well last season and in Season 6.\nOdysseas.eth is an active top 1% OP stack developer.\nOther candidates appear qualified and will no doubt serve well, but we wish to concentrate our selection on those we consider proven choices.\nS8 Governance Fund Mission: Grants Council\nSummary: This poll asks OP holders if they support providing a grants budget of 6.29m OP for Season 8.\nNB: This is an optimistic proposal, which will pass unless 20% of votable supply votes against\nRecommendation: Vote For. GFX Labs is running for Grants Council and believes in its ability to responsibly and materially deploy grants funding.\nS8 Governance Fund Mission: Developer Advisory Board\nSummary: This poll asks OP holders if they support providing a Developer Advisory Board grants budget of 949,000 OP for Season 8.\nNB: This is an optimistic proposal, which will pass unless 20% of votable supply votes against\nRecommendation: Vote For. DAB grants are for meeting highly technical, narrow goals like audit subsidies.\nMilestones & Metrics Council Election: Reviewers\nSummary: This poll asks OP holders which candidates should fill the three seats for Reviewer on the Milestones & Metrics Council.\nCandidates:\n@luhpring_\n0x9B7…ce7\nBrichis\nCypherbadger.eth\nPadla\nSEEDGov\nSuperchainEco.eth\nSuperpuperwallet.eth\nTané\nV3naru\n\nNB: This is approval voting, and voters may select more candidates than there are seats.\nRecommendation: Vote Brichis, SEEDGov, SuperchainEco.eth, Tane, v3naru. This is an extremely competitive election with an embarrassment of riches when it comes to qualified, seasoned candidates. While nearly all candidates have our confidence, we have tried to make our vote more meaningful by limiting it to those with significant experience as Optimism governance contributors.\n\n 21 days later\n\n post by GFXlabs on Aug 19, 2025\n\n GFXlabs\n\n 1 Poll Closing August 20, 2025\nSecurity Council Season 7 Retroactive Funding Request\nSummary: This poll asks OP holders if they support providing an additional funding of 346,920 OP to Season 7’s Security Council. This would amount to 24,780 OP per signer. Members previously received 20,000 OP each.\nRecommendation: Vote For. This is a case that highlights the issues with denominating pay for key roles in OP rather than dollars. At the time of initial approval OP had more than 2x the market price it enjoys today. Going forward, members of the Council should be aware of the market risk they bear by accepting OP payments, but an even better solution would be to shift towards denominating pay in currency terms rather than in-kind token terms\n\n 1 month later\n\n post by GFXlabs on Sep 22, 2025\n\n GFXlabs\n\n 1 Poll Closing September 25, 2025\nMaintenance Upgrade: 16a\nSummary: This poll asks OP holders if they support an upgrade to roll back some previously approved interoperability-related code, as well as some minor upgrades for customizability of the OP stack.\n*NB: This is an optimistic poll\n*\nRecommendation: No vote necessary. This is an optimistic poll and the changes are minor. The DAB has also agreed that it poses little risk.\n\n 29 days later\n\n post by GFXlabs on Oct 22, 2025\n\n GFXlabs\n\n 2 Security Council Elections Closing October 22, 2025\nSecurity Council Election\nSummary: OP holders are asked which of the following candidates they support for seven open seats on the Security Council.\nAgora\nAlchemy Insights, Inc.\nCertora, Ltd.\nCyfrin\nEmiliano\nGauntlet\nLund Ventures\nMariano\npablito.eth\nRoutescan\nUniswap Foundation\nVelodrome\nΞthernaut\nNB: This is an approval voting poll; voters may vote for as many candidates as they wish with their full voting power.\nRecommendation: Vote Cyfrin, Lund Ventures, Mariano, Pablito.eth, Emiliano, Ξthernaut, Alchemy Insights.\nMariano and Ξthernaut are long-term incumbents, and offer some geographic diversification of the council.\nCyfrin, Pablito (Pablo Sabbatella), Emiliano (Bonassi), and Alchemy are all strong technical candidates with a focus on security research.\nLund Ventures has a legal background, which may prove useful in a war room in certain instances, and is headed by Dane Lund, who has deep organizational knowledge of Optimism, its governance, and affiliated entities.\nThere are several other well-qualified candidates, but with only seven seats, GFX has chosen to vote in a manner that can most impact the election.\nSecurity Council Elections: Cohort A Lead\nSummary: OP holders are asked which of the following candidates they support for one open seat as Cohort Lead on the Security Council.\nRecommendation: Vote Alisha. Alisha is the only candidate, and has served on the Security Council for several seasons.\n\n 3 months later\n\n post by GFXlabs on Jan 27\n\n GFXlabs\n\n 4 Polls Closing January 28, 2026\nProposal to Align OP Token with Superchain Success\nSummary: This proposal asks OP holders if they support initiating a 12-month program to spend 50% of Superchain revenues on OP token buybacks. Buybacks would be conducted by an OTC provider.\nRecommendation: Vote Against. Optimism is reliant upon OP token sales and emissions for ongoing financing. This includes spending by both Foundation and governance. It does not at this time make sense to conduct a buyback of the same tokens Optimism is a net seller of.\nAdditionally, there has been no defensible objection by Foundation to why these buybacks – if buybacks are indeed necessary – cannot be conducted without the need of an OTC desk. It is difficult to understand when existing routers on Optimism that include both DEX and offchain execution can be easily and freely accessed.\nimage1380×650 145 KB\nExample ETH-OP transaction on Oku.\nRealistically, 50% revenue buybacks would amount to around $500k per month. Especially if TWAP’d, this is simple to accomplish without utilizing opaque OTC providers and excluding DEXs. It also sends a terrible message that Optimism Foundation feels it cannot buy its own token on its own chain. OTC use is simply unacceptable even if a buyback were warranted.\nSeason 9 Governance Fund Mission: Grants Council\nSummary: This poll asks OP holders if they support providing 3,890,000 OP grants budget to the Grants Council for Season 9.\nNB: This is an optimistic vote, and no action is needed to signal support.\nRecommendation: No Action (Support). This is a significant reduction, which is unfortunate. However, voting against this proposal would effectively create a budget of 0 OP.\nSeason 9 Governance Fund Mission: Developer Advisory Board\nSummary: This poll asks OP holders if they support providing 980,000 OP grants budget to the Grants Council for Season 9.\nNB: This is an optimistic vote, and no action is needed to signal support.\nRecommendation: No Action (Support). This is a similar budget to last season.\nDAO Operating Budget Midpoint Adjustment\nSummary: This poll asks OP holders if they support a 2,300,000 adjustment to the DAO Operating Budget.\nRecommendation: Vote For. OP token price is significantly lower than when the initial budget was passed. This adjustment is based on the Budget Board’s ETH-OP TWAP valuation formula.\n\n post by GFXlabs on Feb 2\n\n GFXlabs\n\n Upgrade 18 - Custom Gas Token v2 and Kona Proofs\nSummary: This poll asks OP holders if they support this bundle of upgrades. Major features include v2 of custom token implementations, a new fault proof implementation, and changes to make chain deployment more streamlined. This upgrade has already been reviewed and approved by the Developer Advisory Board.\nNB: This is an optimistic vote, and no action is needed to signal support.\nRecommendation: No Action (Support). These are all upgrades with clear use cases for OP stack operators, and the code has been audited.\n\n 29 days later\n\n post by GFXlabs on Mar 3\n\n GFXlabs\n\n Effective today, GFX Labs is resigning its seat on the Optimism Grants Council.\nIt has been our pleasure to serve Optimism as a major delegate since inception, and we will continue to participate through voting.\nGFX is one of the founding members of the Optimism Grants Council, and also served on a precursor grants committee. We are known for our emphasis on tokenholder rights and financial sustainability, and our continuing work as a delegate will continue to reflect those views.\nOptimism should be proud of building a best-in-class DAO grants program, which served as the model for many other grants programs in the industry. It has been our pleasure and honor to serve on the Grants Council, but can no longer allocate the time and expertise required for it.\nWe wish the remaining members of the Grants Council the best of luck and our warmest regards.\n@Gonna.eth @mastermojo @MattGov.eth @Michael @Bunnic\n\n post by 0xDonPepe on Mar 4\n\n 0xDonPepe\n\n Sad to see you step down from the Grants Council, you’ve been a foundational part of it since the early days.\nTo the remaining Grants Council members (@Gonna.eth @mastermojo @MattGov.eth @Michael @Bunnic): With GFX Labs out effective today, will the seat be filled via a replacement appointment (e.g., majority vote or Lead decision per the charter’s process for vacancies), or is the plan to continue with the current lineup for the rest of the season/term to keep things moving on reviews/approvals/milestones?\n\n post by artespraticas on Mar 5\n\n artespraticas\n\n Very sad to see The OGC loosing such valid participants. Hope they can find new delegates and keep supporting the builders! Best of success to all.\n\n 2 months later\n\n post by Gonna.eth on Apr 21\n\n Gonna.eth\n\n 0xDonPepe\n\n Demand is manageable with 3 reviewers, GC decided to reallocate remaining GXF budget to Matt, Mojo and Michael as they are getting GFX workload.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\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 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\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 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 Governance Weekly Recap\n\n Governance Updates\n\n Hi all - duncand from Boardroom here \nPart of our team’s mission is to increase informed participation in governance, and as a project supporting Optimism voters we thought it would be useful to provide a weekly r…\n\n read more\n\n 102\n\n 19.5k\n\n Dec 2024","tokens":10326,"squid":"spider-07","role":"Council Spider","at":1791347553455,"hash":"17ddd77ec8b99a85e001a0cfb9ae86ee1c987b10"}
{"url":"https://gov.optimism.io/t/seedgov-delegate-communication-thread/2950","domain":"gov.optimism.io","title":"SEEDGov - 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 SEEDGov - 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 Jul 2022\n\n 1 / 65\n\n Jul 2022\n\n Jan 27\n\n post by Joxes on Jul 10, 2022\n\n Joxes\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. ¿Por qué SEED Latam? — SEED Latam\nTo learn more about us – seedlatam.org\n\nFollowing @GFXlabs and @OPUser initiatives, this is our thread with all our relevant decisions and participation in OP governance.\nPresentation\nDeFi LATAM is a spanish speaker community for the Web3 & crypto ecosystem, focused on education and adoption of users in Latin America under the values of decentralization and towards the future of internet. We detect the potential of Ethereum’s scaling solutions for our region and for this reason we have decided to be a representative voice of the ideas and interests of this increasingly growing community in this part of the world.\nRead our full presentation in Delegate Commitments thread here.\nDelegate\njoxes.defilatam.eth\nOur procedure\nWith the help of numerous contributors and member of DeFi LATAM and Optimism Español, every decision made on behalf of DeFi LATAM in governance is discussed, agreed upon and communicated to all those interested in participating through our discussion channels on Discord:\nDeFi LATAM>Gobernanza>Optimism-op.\nParticipation in the forum’s discussion threads in daily activities are own opinions of the delegate and contributors in their way to keep up with their roles and commitment to the governance; use of “we” or “us” shall apply when representing decisions or communications arising from the community, such as voting decisions and proposal submissions, all through this profile.\n\nSpecial thanks to PEPO, Cryptochica, our contributors @AxlVaz, @NicoProducto, @Netrim, @994.eth, all our community and people from Latin America who support us!\n\n Token House participation and incentives: an extended analysis\n\n Grant Council Reviewer Nominations: Season 3\n\n [READY][GF: Phase 1 Proposal] Karma discourse forum plugin\n\n SEED Latam | Regarding the selection of the new badgeholders for our members\n\n [DRAFT] S02 Committee Proposal: Tooling Governance Committee\n\n 41\n\n 14\n\n 4\n\n 2\n\n read \n\n 53\n min\n\n post by Joxes on Jul 11, 2022\n\n Joxes\n\n Past actions.\nGovernance Fund Phase 0 voting decisions:\n\nProposal A - Batch Vote: For.\nReasons: we are ok supporting this proposal to start encouraging the growth of the optimism ecosystem. While we don’t agree with the vote taking place in a single batch, there is no reason to reject it among the 24 listed proposals included here.\n\nProposal B - Uniswap: Against.\nReasons: did not follow the guidelines.\n\nProposal C - 0x: Against.\nReasons: did not follow the guidelines.\n\nGovernance Fund Phase 1 voting decisions:\n\nProposal A: Optimistic Railway: No\nReasons: in a very early stage, without clarity of what kind of positive impact it can have on the ecosystem.\n\nProposal B: dForce: Yes\nReasons: protocol of the first to deploy in Optimism. Acceptable proposal and detailed.\n\nProposal C: GYSR: No\nReasons: Amount higher than its potential use case. No clear strategy.\n\nProposal D: Mean Finance: Yes\nReasons: a one-of-a-kind protocol. Reasonable distribution. This project is well known and supported in our region.\n\nProposal E: Raptor: No\nReasons: does not apply to this phase.\n\nProposal F: Balancer & BeethovenX: Yes\nReasons: reasonable proposal in general terms, it seems positive to us.\n\nProposal G: Summa: No\nReasons: it doesn’t make sense at this stage, they ask for an excessive amount of tokens.\n\nProposal H: WardenSwap: No\nReasons: DEX aggregator. Not very interesting proposal. It would be good to see the deployment first to judge better.\n\nProposal I: Pickle Finance: Yes\nReasons: known team and protocol, reasonable proposal.\n\nProposal J: Ooki Protocol: No\nReasons: excessive amount for the protocol use case (see metrics in other chains). Author does not ensure co-incentives.\n\nProposal K: Infinity Wallet: Abstain\nReasons: difficult to evaluate, we leave it to the rest of the voters to establish their criteria.\n\nProposal L: Beefy: No\nReasons: excessive amount according to distribution. Not deployed at the time of decision.\n\nProposal M: 0xHabitat: No\nReasons: from our perspective they should finish defining ideas and deploying in Optimism. Happy to re-evaluate later.\n\nProposal N: Thales: No\nReasons: this project received funding from Phase 0. Distribution has not started yet. It’s counterproductive to approve new funds without evaluating the use of previous funds.\n\nProposal O: Paraswap: Yes\nReasons: reasonable proposal.\n\nProposal P: Roki: Yes\nReasons: well detailed proposal, interesting use case. Reasonable.\n\nProposal Q: Candide: Yes\nReasons: wallet focused on Rollups, with innovative features. Experimental proposal.\n\nOther actions:\n\nProposal: Pause Phase 1 and start a discussion round to improve the governance process.\nSmall improvements on Incentive Proposal Template for Phase 1.\n\n1st Governance Call at DeFi LATAM (6th July)\nSeveral spaces, calls and on-line meetups (together with Optimism Español) in at differents spanish-speaker communities to talk about Optimism: scalability properties, vision and its governance.\n\n post by Joxes on Jul 13, 2022\n\n Joxes\n\n In an effort made by community members, we have made a proposal to improve significatly the phase 1 templates:\nUpdate of the PHASE 1 protocol nomination template.\n\n post by Joxes on Jul 18, 2022\n\n Joxes\n\n Today our 2nd Governance Call was held after a past week as timeframe to discuss the proposals of cycle #3. In this call we settled our discussions and vote as a community. The results can be found below with details and our feedbacks following the links:\n\nProposal A: Superfluid: Yes.\n\nProposal B: Kromatika: No.\n\nProposal C: Hundred Finance: No.\n\nProposal D: Biconomy: Yes.\n\nProposal E: Dope Wars: No.\n\nProposal F: Infinity Wallet: No.\n\nProposal G: DexGuru: No.\n\nProposal H: Overnightfi: No.\n\nProposal I: Saddle Finance: No.\n\nDespite significant negative votes, we believe that our feedback and that of other delegates and community can be useful for several proposals to be successful in passing in the next cycles.\n\n 15 days later\n\n post by Joxes on Aug 2, 2022\n\n Joxes\n\n Hello all!\nLast friday we held the 3rd governance call on Discord to discuss the proposals for cycle 4. As in past calls, we focus on ratifying our decision as a community in the ongoing voting and also express opinions about the future of governance given the completion of Season 1.\nParticipants: ~26 (special thanks to Pacha for the design) + various other members during discussion week.\nAs result, our vote for cycle #4 has been as follows:\n\nProposal A: Rocket Pool: Yes. \n\nProposal B: Boardroom: Yes. \n\nProposal C: dHedge: No. \n\nProposal D: xToken Terminal and Gamma Strategies: No. \n\nProposal E: Byte Mason Product Suite: No.\n\nProposal F: GARD: No.\n\nProposal G: Beefy Finance: Yes.\n\nProposal H: BarnBridge: No. \n\nProposal I: QiDao: Yes. \n\nPlease click on Yes/No to read our conclusions.\nWe commend the projects that took the time to consider the feedback from the community and delegates that led to some successful proposals passing. For the rest, keep working on the proper queries in the forum for the next cycle of Phase 1, see you in Season 2!\n\n [DRAFT][SO2 Committee Proposal: DeFi: Group C]\n\n 15 days later\n\n post by Joxes on Aug 18, 2022\n\n Joxes\n\n Today, we have formalized our participation in the formation of Governance Committees proposed for season 2 of Optimism governance.\nCurrently we’re part of two committees proposals as reviewers, details below:\n\nCommittee proposal: DeFi, lead by @OPUser\nWe will be working alongside the following reviewers: Dhannte, MinimalGravitas, ScaleWeb3.\nWe feel very comfortable with our team, as each and every one of them has had an important presence in the governance for Season 1 to have culminated with relative success. Also, we share the same values strongly aligned to Optimism itself.\nAs expected, we will move so that the proposals make sense and everything is in accordance with alignments, proposed goals and shared values, while prioritizing long-term, genuine growth and derisk of gaming incentives.\n[DRAFT] S02 Committee Proposal: DeFi\n\nCommittee proposal: Tooling Governance Committee, lead by @krzkaczor\nWe will be working alongside the following reviewers: lefterisjp, cryptotesters, ceresstation.\nTooling and infrastructure is probably one of the most undervalued topics and does not necessarily directly impact the conscious interests of the end user, as it does in the DeFi category with the usual standard liquidity mining programs and other incentives.\nWe are proud to have been able to deliver the proposal on time with a framework that we believe is an excellent starting point, considering the potential variety of proposals applying to this category and that we are ready to address as a team.\n[DRAFT] S02 Committee Proposal: Tooling Governance Committee\n\nOur procedure in the current committees:\nAs we stated in our first post, currently this delegation is performed by Joxes (myself) as a leader alongside a team made up of spanish-speaking contributors with experience in DeFi and other topics. Some members have been enormously active as @Netrim @AxlVaz @NicoProducto and other committeed to this commitment, without this having to mean any type of obstacle, but on the contrary, rapid execution of any task, and preserving our original mission as a community for Optimism governance.\nIn the formal instances/aspects, I bear all responsibility as leader and representative of DeFi LATAM, delegate and sole owner of this account and ENS.\n\nAbout our participation in two differents committees:\nWe have absolute confidence in carrying out our work in favor of OP collective and these conditions were accepted by the rest of our committee teams. If the foundation, delegates or community strongly believe that this represents a severe problem, we can reach a resolution. However, we are pleased to contribute to making both proposals possible within the established times, and looking forward to season 2 being successful in all aspects.\n\n [DRAFT][SO2 Committee Proposal: DeFi: Group C]\n\n 19 days later\n\n post by Joxes on Sep 7, 2022\n\n Joxes\n\n Hello all!\nThis monday we held our 4th Governance Call in Discord to discuss and decide our votes on selection of governance committees for season 2, according to Voting Cycle #5. Following our ethos and role as delegate, we carry out a decision-making process between our collaborators and the community we represent.\nParticipants: +30 attendees (27 collected; special thanks again to Pacha for the design).\nDuration: 1hs 49min. In the last quarter, we had the presence of a Boardroom member, who told us about his work on the project.\nBelow is a summary of this Governance Call:\nOur voting procedure\nAfter a review of each governance committee proposal received, we proceeded with the following format:\n\nAt first, we consulted the community on what should be the action of our delegation on our voting decision in the committees that we are part of (Tooling and DeFi - C). Through the discussion process we ratified the following decisions:\n\nDeFi Committee [Group C] - we abstain\nTooling & Infrastructure Committee [Group A] - we abstain\n\nWe now continue to discuss what approach we should follow regarding our voting decision in the DeFi A and DeFi B committees, considering our participation in DeFi C. We received different opinions, reaching consensus on:\n\nDeFi Committee [Group A] - we vote for\nDeFi Committee [Group B] - we abstain\n\nWe finalize our voting decisions with the last NFT category committee:\n\nNFT Committee [Group A] - we vote for\n\nOur rational\nCollaborators and community are aligned with the desire to help Optimism but also ensure that the governance processes are genuine and authentic. In our case, our internal communication ensures that our community members can express their preferences and discuss until a consensus is reached.\nRegarding the vote for ourselves, we believe that it is not positive for the governance and leaves a bad signal with respect to the rest of the members of the governance and community who want to give their opinion and decide on our proposals.\nInterestingly, as a community working as such since the beginning of Optimism governance, we present a possible option of being able to choose to vote in favor of a DeFi committee that best fits the governance objectives and with a solid proposal, in an attempt to express which committee different from ours is ideal for the role. In this case, the framework shown by committee A plus its members was the preferred option, with respect to committee B, whose framework is not well seen with said system of points explained. Notably, some major contributors considered abstention for all three groups to be a better path.\nAbout the Optimism Foundation recommendation for voting for 1 or 2 committees, we take sides by voting in favor of the NFT committee as well, we truly believe that it is important for governance, and possible incursion into identity topic proposals should be ideal and critical to add experience for future iterations.\nFinal words\nWe are excited about the work done so far and to have the collaboration of the Optimism Español initiative to successfully carry out our entire participation process for Season 2. If you are a Spanish speaker and want to join our community, don’t forget to visit our Discord and stay tuned for future calls and updates.\n\n [DRAFT][SO2 Committee Proposal: NFTs & Gaming: Group A]\n\n S02 Committee Proposal: Decentralized Finance Governance Committee: Group A\n\n DRAFT][S02 Committee Proposal: Category: Defi: Group B]\n\n [DRAFT][SO2 Committee Proposal: DeFi: Group C]\n\n [DRAFT] S02 Committee Proposal: Tooling Governance Committee\n\n 23 days later\n\n post by Joxes on Sep 30, 2022\n\n Joxes\n\n Hello again!\nThis tuesday we had our 5th Governance Call on DeFi LATAM with the collaboration of Optimism Español to discuss the proposals of voting cycle #6. In this call we shared our experience in this first cycle of season 2 as members of the Tooling and DeFi C committees. In this call we share our experience in this first cycle of season 2 as members of the Tooling and DeFi C committees, and settle our discussions as a community on the decision-making of the current proposals, as usual.\nParticipants: +35 (special thanks to Pacha for the design). Duration: 2h, 37min.\nA summary about our performance during Cycle #6\nKeeping our intention to work as a group, we established an initial team (@AxlVaz, @Netrim, @Jadmat) with contributors to our delegation on behalf of DeFi LATAM. First, through Joxes (me) as a direct member of the mentioned committees, we focus on organizing ourselves and dividing the tasks, doing the pertinent research and finalizing discussions in order to deliver our analyzes, follow up, and the committee to work as expected.\nAdditionally, our members have been active in the forum addressing different proposals and other topics, which has helped a lot directly or indirectly to obtain the respective clarifications on each one and going forward.\nWe’re really satisfied with the work done so far, and our lessons for the next cycle are quite obvious, work faster internally and have even more presence on the forum; by example, using our delegation to pass the appropriate proposals to the next snapshot round, in our own criteria.\nOur voting procedure\nOur procedure remains intact as previous Governance Calls, we encourage our members interested in Optimism to express their opinion and be an active part of the final decision-making, as a way of absorbing the expertise, criteria and preferences of all in a single voice, more beyond the views of direct contributors a Joxes.\nIn the first place, we ratify with a YES to take into consideration and as a priority the recommendations of all the committees, being a starting point to decide how to vote on each proposal. As part of two committees, this also allowed everyone to quickly get into context where needed and discuss how it should be.\nAs result, our vote for cycle #6 has been as follows:\n\nInterest Protocol 2: For\nFollowing DeFi C committee recommendation, one of the highlights is the improved lending model introduced in Interest, which would be good to see in this ecosystem.\n\nSocket: Against\nFollowing Tooling committee recommendation, we reiterate that the amount requested is seen as excessive, so we will be attentive in the next cycle to receive feedback and suggest the appropriate changes to make it favorable from the point of view of governance criteria. @khuranarishabh\n\nOptiChads: For\nFollowing NFT & Gaming committee recommendation, we see as positive some of the intentions of the project towards Optimism. However, we’re aware that the NFT ecosystem is plagued with a lot of skepticism and some of our members expressed doubts as to whether the proposal would really add value to Optimism. In the end, we will remain “optimistic” so that this project and proposal makes sense and is fulfilled for our ecosystem. @Dicaso\n\nKromatika: For\nFollowing DeFi A committee recommendation, we’re pleased to know that your proposal has made the relevant changes compared to the previous cycle in season 1, where we voted against. Now the proposal was seen as reasonable.\n\nRevert Compoundor: For\nFollowing DeFi A committee recommendation, as a community we believe that Revert has an interesting implementation to take advantage of Uniswap on behalf of LPs. The proposal was seen as seen as reasonable.\n\nBankless Academy v2: For\nFollowing Tooling committee recommendation, this academy is characterized by having a good reputation in the Ethereum ecosystem, additionally its added value will be potentially very beneficial for onboarding users in the globe. In particular, from DeFi LATAM we share many of these values that the Bankless community upholds and we’re pleased that communities like these are given the opportunity to promote initiatives such as the one in the proposal. The proposal itself is seen as reasonable. @Tetranome\n\nAcross Protocol: For\nFollowing Tooling committee recommendation, from the community we want to emphasize that optimistically designed bridges are of our full interest and we have closely followed teams like this throughout the year. For this reason we believe that accepting proposals like this will be positive for the diversity of bridges with acceptable safety models for the future of the Optimism ecosystem.\n\nTarot: Against\nFollowing DeFi A committee recommendation, the problem with this proposal is as the committee points out, we are happy that the Tarot team has already submitted a new draft based on the feedback received. @TigrisOfGaul\n\nOtterspace: Against.\nFollowing Tooling committee recommendation, some members of DeFi LATAM community expressed their knowledge of the work of otterspace, however, the niche in which this project tries to capture deserves a review of the proposal to adjust it to the likely impact it may have if the ideas presented are implemented. We will be addressing it again for the next cycle with the corresponding feedback. @Lukas\n\ndHEDGE DAO: Against\nAgainst the recommendation of the DeFi C committee, our community had a lengthy discussion near the close of voting and during this governance call about the impact and use of funds proposed by dHedge. Although the proposal can be seen as positive in terms of encouraging pool management and increasing its adoption, for the moment we were concerned about some points about its criteria, such as the lack of clearer parameters on which pools to benefit and under what regime. At the moment it’s specified that whitlisted pools will be supported and with their own governance procedure, of which we have observed a certain degree of centralization in decision making, so we encourage dHedge to allow its community to express itself genuinely about the pools to incentivize in Optimism. We believe that in this case the weight of conflict of interest should be avoided or clarified. Additionally, incentivizing this pool with its governance token is seen as a standard approach that doesn’t affect the evaluation of the proposal. Since the proposal has passed successfully, we encourage dHedge and its governance to have a fair criteria in favor of the users of the Optimism ecosystem when deciding which pools to incentivize. @Cyrus\n\nWe’re very happy with how the community has organized and shown interest in the future of the Optimism ecosystem and its governance. Alentamos a la comunidad hispanohablante y de latinoamérica a que se unan a nuestra travesía por el futuro de Optimism. _\n\n post by TigrisOfGaul on Oct 1, 2022\n\n TigrisOfGaul\n\n Thanks for including a link to Tarot’s new proposal. It now focuses exclusively on direct incentives within Tarot, for borrowing activity (OP-based, and other Optimism pairs) and lending (OP, ETH, and USDC).\n\n 22 days later\n\n post by Joxes on Oct 23, 2022\n\n Joxes\n\n Hi frens!\nThis last monday we held our 6th Governance Call in Discord to discuss about our decisions on cycle #7. We continue sharing our experience as delegates and part of governance committees. This call was made just after Devcon week.\nParticipants: +17. Duration: 2h 12min.\nA summary about our performance during Cycle #7\nAs we said, this cycle happened during Devcon week (particularly during delegate feedback and voting weeks), in this case we work with our contributors to realize our tasks at time, but for example, some final coordination problems caused a delay at delivering all the tooling committee recommendations at time.\nOur voting procedure\nContinuing with our process explained in previous governance calls, we discussed the present proposals, ratifying once again the one taken into account by the governance committees or expressing our own rationale otherwise.\nAs result, our vote for cycle #7 has been as follows:\n\nAbracadabra Money: Against.\n\nOvertime Markets: Against.\nOvernight dot fi: Against.\nSushiswap: Against.\nTarot: For.\nAlchemix: Against.\nDope Wars: Against.\nOtterspace: For.\nRainbow Wallet: For.\nKarma (Delegate Dashboard): For.\nKarma (Discourse forum plugin): For.\nSafe: For.\nLi Fi: For.\nYearn: For.\n\nSome notes about our presence on Ethlatam and Devcon\nWith great joy, members of DeFi LATAM community between Optimism Español and Layer 2 en Español joined forces to have a presence all day in various stands during the Ethlatam event held on October 10 at the same venue prior to the Devcon.\nAlso, our community participated in the following talks:\n\nErik Suazo “How to participate in DAO governance” disscusing about the state of Optimism Collective and how contribute. Full video here.\nJoxes and Axl “Introduction to Optimism”, a talk to explain how Optimism works and future with bedrock. Full video here.\n\nA very very special thanks to @NicoProducto (leading Optimism Español), @CryptoChica and rest ethlatam organizers for make it possible and Optimism Foundation for support us.\nThe rest of Devcon week we were attending EthBogotá, Rollup Day and Devcon, talking at the Optimism booths as well as meeting various governance delegates and our committee team members. We’re very happy that the whole Ethereum community had a great time in our continent, South America.\n\n 26 days later\n\n post by Joxes on Nov 19, 2022\n\n Joxes\n\n Hi again!\nWe’re always posting our procedures and activities, so this monday 11/7 we had our 7th Governance Call in DeFi LATAM in collaboration with Optimism Español to discuss the proposals of last voting cycle (#8). We continue to share our experiences as delegates and part of the governance committees in this season 2. This call was one of the longest we had and with a lot of debate about the proposals. We also had the pleasure of having the delegate @olimpio in our discussion with the community.\nParticipants: +18 attendees. Duration 3hs. As always, many thanks to our contributor Pacha for the design of these POAP series.\nOur voting procedure\nOur procedure remains intact as the previous governance calls, we encourage our members interested in Optimism and its ecosystem to express their opinion and be an active part of the final decision-making, as a way to absorb the experience, criteria and preferences of all in one voice. During this round we were able to observe more participation/discussion from our community members.\nAs a result, our vote for cycle #8 has been the following:\n\nAlchemix: For\nFollowing DeFi committee A recommendations. In the previous period Alchemix received important feedback and they moved forward by resubmitting the proposal. Our community saw the changes applied by the Alchemix team very positively\n\nArrakis Finance: Against\nThe three points considered by Committee A were well considered by our community. Also, the intentions of helping new illiquid projects on Uniswap V3 are noble, but it is appropriate to give more details of this approach and avoid gambling incentives, or else start low to judge the results later. Happy to see an improvement to the proposition, as boosting Uniswap liquidity is a positive for the broader ecosystem, more often than not.\n\nSymphony Finance: Against\nCommittee A showed two important points to correct and our community also agreed. The Latam community is convinced that Symphony adds value to the ecosystem, it’s popular among the members of our community. However, a more focused proposal is expected.\n\nHomora V2 x Ironbank: Against\nOur community voted against the recommendation of the Defi C committee. The reasons are those expressed by several governance delegates, HomoraV2 in close source and the biggest beneficiary of the proposal is Iron Bank. Homora is a protocol used by members of our community, some members also collaborate with their community.\n\nAngle Protocol: For\nFollowing DeFi C committee recommendations, forex currencies like agEUR are a space worth boosting for asset diversity in the Optimism ecosystem. Also, Angle’s track record is respectable so far, which is why our community leaned towards this proposal.\n\nInsureDAO: For\nFollowing DeFi C committee recommendations. The insurance protocols aren’t widely used among members of the community or ecosystem in general, for various reasons such as their lack of efficiency in a good fit to the DeFi ecosystem and complexity of understanding, but organic growth demonstrated so far, the coverage of a large number of protocols within Optimism and the KPIs proposed by the team, were essential for the decision made by the community.\n\nCurve: For\nFollowing DeFi C committee recommendations. Curve is one of the most popular protocols among the members of our community, not only because of the incentives generated in Ethereum and other chains, but also because of its solid history without vulnerabilities and great developers teams that have behind. We expect to see the same traction on Optimism.\n\nPool together: For\nFollowing DeFi C committee recommendations. Latam communities has shown a particular affection for PoolTogether, in addition to being widely used by members, many started in crypto via this protocol. It was also very positive to show the results of the grant received through the partner fund. We hope that Pooltogether will continue to insert users to crypto and especially to Optimism.\n\nOvernight: For\nFollowing DeFi C committee recommendations. In cycle #7 our community had voted against, and then Overnight team made the expected changes and in this cycle it was voted in favor.\n\nSocket: For\nFollowing Tooling committee recommendations. In cycle #6 our community had voted against, then Socket team made the expected changes and in this cycle it was voted in favor.\n\nEthernautDAO: For\nFollowing Tooling committee recommendations. Without a doubt, EthernautDAO adds a lot of value to the Optimism ecosystem. Glad to know that some members of our community have been mentored by EthernautDAO and have provided positive feedback of it. In addition, the change made in the proposal has been seen as positive. Thanks to @Gonna.eth who has been on some of our governance calls, sharing his opinion with our community.\n\nTally Ho: Against\nAlthough it was voted against, the recommendation of the tooling committee was considered for this decision.\n\nAmbire Wallet: Against\nSame situation as Tally Ho.\n\nMessari: Abstain\nFollowing Tooling committee recommendations. Our entire community knows the product and Messari’s reputation, however we consider that it is being offered a “service” and not a “proposal” along with the Optimism ecosystem. We also believe that it should be dealt with by other governance processes.\n\nDefillama: For\nFollowing Tooling committee recommendations. All members of our community voted in favor of this proposal. We know the work of the team and we use the tools provided by Defilllama on a daily basis.\n\nAgora: For\nFollowing the recommendation of the Tooling committee. The community believes that Agora’s value proposition is different from other governance tools. We await the development of the protocol to be tested by our community.\n\nMochi: Against\nOur community voted against the tooling committee’s recommendation. We have voted for governance tools with proposals similar to Mochi’s, we want to see the impact of these tools on the ecosystem before approving this proposal.\n\nVelodrome: Abstain\nSince there was no recommendation from the DeFi A committee, there was a lot of discussion about this proposal in our community. Velodrome is one of the most used protocols by members due to the incentives given. Which led to the question if Velodromo is sustainable without the incentives, there was no consensus among the members. The importance of the Velodrome team for the expansion of the Optimism ecosystem was also highlighted. Points for and points against were touched. Our members did not reach a general consensus, so we voted to abstain.\n\nSome notes about our presence at LABITCONF\nWith great joy, our members of DeFi LATAM community, Optimism Español, Layer 2 en Español, Mujeres en Cripto and Builders came together to have a presence all day in a booth during the LABITCONF event held on November 10 and 11 in Buenos Aires where +5000 people attended during the 2 days.\n@NicoProducto (leader of Optimism Español) gave a talk on the governance of Optimism in front of +200 people.\n\nA special thanks to @CryptoChica and @NicoProducto who managed and organized so that Optimism Español could be present at LABITCONF.\nConclusion\nBetween events where we present Optimism and season 2, it has been an intense few months and a lot of work for our community. However, our team was up to the situation and we were not only able to have a presence in all the presentations, but we also fulfilled our tasks within governance in a timely manner.\nIn the next few weeks we will be uploading our thoughts on the season 2 wrap up, season 3 start and the Council Grant.\n\n Governance Weekly Recap\n\n 13 days later\n\n post by Joxes on Dec 2, 2022\n\n Joxes\n\n Season 2 has come to an end! and with this we write here our thoughts of community and participants for the DeFi LATAM delegation for this governance.\nIntroduction\nFirst of all we want to clarify that this doesn’t represent isolated individual thoughts, but also a compilation of thoughts from members interested in the Optimism governance from our DeFi LATAM community delegation, as is described in our commitment as delegates.\nVery important say that this includes the thoughts of our work team to make possible our labours in DeFi C committee and the Tooling committee. Our contributors: @Netrim, @AxlVaz and @Jadmat.\nNext we are going to express positives, negatives and other thoughts that we learned from season 2.\nInternal work in DeFi LATAM\nAs we expressed in our participation in the two committees, as a team we managed to carry out our work in a timely manner. As a team of 4, the division of labor for each of the proposals in the queue according to the corresponding committee, based on the expertise, knowledge, and context of each proposal and the team behind it, was correct. Then these discussions ended internally among our team, supporting our independent line of thought. Happily we were able to gain experience in a shared way.\nPositive\n\nMore minds, better ideas.\nThe determination of tasks and responsibilities for each one facilitated the development and delivery of reasoning in an orderly and formal manner, ready for discussion.\nEach member worked on the proposals where they liked to focus the most and with the greatest motivation.\nParticipation in the forum was remarkably active as a group and individually.\n\nNegative\n\nCoordination work is not easily achieved in the early stages.\n\nWorkflow between committees\nWe are one of the few delegations that formally work as a group, which implies that coordination for the rest of the fellow committee members must be well managed. In this sense, we need to issue a special thanks to the committee leaders @OPUser and @krzkaczor because we are happy with the trust received, as well as the rest of the members. We learned a lot in the process and we hope that you all have also felt comfortable with our participation.\nPositive\n\nGood relationship between the members of the committees from the beginning and motivations to do what is right at all times in our internal work.\nThe discussions about the evaluation of the proposals in themselves and according to the expertise of each member were learning for all.\nConsensus was reached in relativegood way and was never a reason for division.\n\nNegative\n\nCommunication is not always optimal.\nThe lack of availability caused delays in some parts of the process, so it did not fit well with the timing of the governance processes.\n\nImpact on season 2\nCommittees contributed at first to lighten the workload of the delegates to evaluate the proposals, but they quickly became a cause rather than a discouragement for the participation in the forum by delegates not involved in some form of committee, mainly. On the other hand, the presence of these committees as a “trusted source of consultation” for governance generated more friction and sometimes personal discussions that lost focus or turned the environment into a hostile one, for example, when some proposals were rejected.\nSeen from the outside, the committees failed on several occasions in their communicative role of being up to date, accompanying the proposals until their evaluation. From our side, we are proud that the reports issued by our committees had a comprehensive and even sophisticated analysis for the understanding of all parties.\nPositive\n\nIterative governance generated interesting discussions regarding the scope of the Committees that are reflected in Season 3, with the Council of Grants.\nHelped show which delegates were really involved, even if they were not part of any committees.\n\nNegative\n\nThere was a dispersion of information between Discord and the Forum, making it difficult to follow the thread of certain conversations.\nModeration in the Forum was non-existent.\nToo many backchannels and/or private communications, there was no open communication from the committees in general.\n\nFinal thoughts and conclusions\nOrganization in governance is not easy, even more so when we’re just starting out for a protocol of such prominence as Optimism itself. As a result, following governance is not an easy task and we need to revisit how to align incentives so that contributing participants are rewarded in some way.\nForum discussions are desirable but we note the need for a more moderated environment to stay on topic, fueled earlier by challenged action by committees, but surely in the future by action by the Grants Council.\nWe want to note that since Phase 0 significant sums of OP tokens have been delivered to numerous projects, it’s time to thoroughly analyze the current impact and assess KPIs where appropriate, or have protocols report performance.\nOn our side, our commitment to this governance remains the same as the first day and we remain committed to the Optimism ecosystem. We are going to continue working with our community and the entire ecosystem to continue representing Latam within this governance.\nStay Optimistic!\n\n Evaluation of grant processes\n\n [DRAFT PROPOSAL]: Moving to a Grants Council\n\n Governance Weekly Recap\n\n post by Joxes on Dec 2, 2022\n\n Joxes\n\n Special thanks to rest of our committee team members @lefterisjp @ScaleWeb3 @cryptotesters @Gonna.eth @ceresstation @MinimalGravitas\n\n post by Joxes on Dec 4, 2022\n\n Joxes\n\n In the context of upcoming Season 3, we’re issuing our first thoughts about these new process and proposals and its impact to the governance. Read below:\n\nRe: [DRAFT PROPOSAL]: Moving to a Grants Council\n\nRe: [DRAFT PROPOSAL]: Protocol Delegation Program\n\n 10 days later\n\n post by Joxes on Dec 15, 2022\n\n Joxes\n\n Hi again!\nThe year 2022 is about to end, and this week we have decided to make our last governance call for the rest of the year, discussing our pending decisions, always in collaboration with Optimism Español, specifically to discuss the proposals of this last voting cycle (#9a) and sharing other important topics.\nParticipants: +33 attendees. Duration: 2hs.\nOur voting procedure\nSticking to our way of making decisions, we explain to the community the current status of active proposals. Then, we carry out the respective votes with the following results:\n\nGrant Council: For\n\nThe feeling from us (as delegate + contributors) and the rest of the community is that a twist is needed to cover the gaps that the committees couldn’t fill last season. This new iteration looks reasonable, but it’s a big change for delegates to focus on now; if this proposal passes.\n\nProtocol delegation program: Against\n\nDespite several of us and contributors expressing about various positive aspects of this proposal, in the final consensus with our community there were more doubts or questions about the purpose of the proposal, such as, for example, if there is not a clearer path to where we should go, how to guide protocol representatives to pursue the interest of the network and not a shock of conflicting interests.\nAbout our committee and retroactive compensation\nAs everyone can note, this delegation received a total sum of 16695 OP. In terms of contribution received by each delegate, joxes.defilatam.eth is positioned as the Top 1 delegation in funds received, which makes us feel proud of all the effort made. In details, the rewards have been received for the following reasons:\n\nParticipation in DeFi Committee C: 4043 OP - 24%\n\nParticipation in Tooling Committee: 4652 OP - 28%\n\nSeason 1 and 2 retroactive delegate rewards: 8000 OP - 48%\n\nAs we know, this delegation has worked together since its inception through Joxes (me), our group of contributors and Latam community, accompanied by an initiative started from DeFi LATAM called Optimism Español. In order to honor the efforts of our community, we have decided to distribute said funds to everyone involved in the community to participate in governance and support Optimism in its own growth and future:\n\nCommittee Contributors: who shared the responsibility of carrying out the work in both committees for season 2. Joxes, @Netrim @AxlVaz and @Jadmat – 7200 OP.\n\nOptimism Español: to support the group of contributors who helped this initiative in any meaningful way. @NicoProducto, @et_2244, Pacha, @CryptoChica, Candu, Lu, @eriksuazo, Gasm and @ahhsun – 4700 OP.\n\nSEED Latam: an allocation for the next initiative to insert people from the web3 ecosystem of latam in governance – 2295 OP.\n\nCommunity Airdrop: a distribution to those who frequently participated in our governance calls and contributed to governance discussion and decision-making, counted by POAPs, excluding the contributors listed above – 2000 OP. More details will be shared in the next few days.\n\n1600×891 372 KB\n\nCall for optimism\nWe love working as a collective intelligence and transparency, something that makes us feel identified with the ethos of the Optimism ecosystem. If we want Optimism to be the transformative engine of Ethereum and the future of the internet, we must start iterating ourselves as best we can. So far, we’re all very proud of what we’re doing to encourage the rest of the Optimism community to appreciate these efforts, and we invite other delegates to refine their own participation processes, if applicable.\nFor now, we are preparing for Season 3, Citizen House release and RetroPGF 2 to continue contributing to public goods and Ethereum ecosystem.\n\n post by Joxes on Dec 19, 2022\n\n Joxes\n\n Sharing my thoughts on the citizen house and public goods\nFinally the Citizen House has been announced for its first iteration. As we know, since its inception it has been thought to focus on the idea of funding public goods, as a way to potentially contribute to the future of the internet and free software, where Optimism and Ethereum are immersed.\nAs a second iteration of RPGF, the amount allocated by the foundation has been 10m OP ($9m today), and it will be focused on Optimism and its new release OP Stack, although it would be desirable if it’s also accompanied by Public Goods built for Ethereum base layer. Anyways, it’s also understandable that starting with public goods that help Optimism itself and not beyond is easier to align incentives and take note of lessons learned before being ambitious and later broading scope.\nLATAM and public goods for Ethereum\nIn this part of the so-called “third world”, the Internet has always remained relatively distant or under the radar of a good part of Western and Eastern capitalism, mainly in finance. Coupled with our political and economic particulars, it explains why free software initiatives have been relevant, and most notably, Ethereum.\nThe role of Latin America for the Ethereum ecosystem has been important, as it happens in other regions. Despite the average low income, the masterminds have been at the start, in the formation of by example OpenZeppelin, MakerDAO, Hardhat, Flashbots, Decentraland and many other projects, not to make a long list. Different generations of builders have been contributing to the ecosystem and the different Ethereum communities in this region have accompanied and nurtured to impact Ethereum for good, including DeFi LATAM, with a remarkable degree of sophistication, recognized by Vitalik.\nFunding in Latin America is not easy to find, but fortunately the region has had access to these new mechanisms to build public goods such as having its own category in the Gitcoin Grants rounds, and Quadratic Funding in recent times such as:\n\nEthereum TGU Grants (12444 USD)\nEthLatam BA (25000 USD)\nEthColombia (292300 USD)\n\nMore than sixty projects have benefited, including open source contributions, communities and projects that try to solve problems in Latin America. In the process, many members of the ecosystem here have gained enormous experience on how to understand the proposed objectives, the selection process, voting, and how to improve it for future rounds. Our community members have been voters, applicants and even developers of some of these.\nThere are several members of the Ethereum ecosystem in our region that I think could also contribute to the process in a significant way with direct experience in said rounds (in the same order) such as crisgarner.eth, @CryptoChica and juandav.eth; but also others like Mariano Conti, @Gonna.eth and @NicoProducto. My suggestion is that if any badge holder (elected by OF or by snapshot) wishes to nominate a person with a focus on this geographic location, my suggestion is on these persons.\nThe values of this delegation and a wish list\nI must thank @kaereste for nominating this delegation (and @lefterisjp for keeping an eye out that we had a nomination), very excited by this. Elected or not, I will be looking closely at all infrastructure proposals with some priority as it is the key before building novel things on top of any form of Optimism.\nAgain, the objectives of this RPGF are clear: to help Optimism and its OP Stack in their degree of sophistication as a competitive framework that developers prefer to use over others. Some interesting things to see are communication between OP chains, consensus mechanisms for them, new L2 clients of Optimism and focused on being the most optimized possible, infrastructure to enable other data availability schemes, VMs and innovative fraud proof systems, and of course, true education initiatives without value extraction to attract more developers and users to Optimism. Additionally, if any initiative is also matchable for the development of the Ethereum base layer in some way, it would be considered as a plus and not to be ignored.\nLastly, although it’s not detailed yet, we expect Citizen House to have their own chat channels open prior to the launch of RPGF 2, including allowing them to iterate the process if there’s anything worth tweaking prior to the round. Excited for what’s to come!\nHappy Citizen House!\n\n Token House Badgeholder Election Information\n\n Code of Conduct Violation: Carlos Melgar\n\n post by Joxes on Dec 21, 2022\n\n Joxes\n\n About Badgeholder Nomination Voting\nA total of 19 delegates were nominated to be part of Citizen House for this second iteration of RPGF. Regarding the voting decision, I have decided this time to receive an opinion from our main contributors about who could be the 10 most suitable for this round. It’s definitely not an easy task because all the nominees have demonstrated commitment to Optimism ecosystem and governance, and experience in public goods.\nAs a result, the following people who we have voted for and who we believe can truly contribute to this next iteration are: Linda Xie, Bobbay (vía Stablenode), Lefteris, OPUser, Polynya, Scott Moore, Dhannte, Minimal Gravitas, Kris Kraczor and Jack Anorak.\n\n Token House Badgeholder Election Information\n\n post by Joxes on Dec 26, 2022\n\n Joxes\n\n As promised, we have decided to distribute a total of 2,000 OP tokens to our participants in governance calls throughout the year, being our first community airdrop. This was never intended until the announcement of the retractive rewards for Season 1 and 2. As a result, it allowed us to do a very simple fair distribution among those who listened and discussed our decision making for Optimism.\nThe rules were: have claimed at least 2 POAPs from our governance calls (out of a total of 8 editions).\nA total of 35 eligible, under the following distribution and by number of addresses:\n\n8 POAPs = 120 OP (2)\n7 POAPs = 95 OP (3)\n6 POAPs = 85 OP (2)\n5 POAPs = 75 OP (3)\n4 POAPs = 60 OP (1)\n3 POAPs = 50 OP (6)\n2 POAPs = 40 OP (18)\n\n*This excludes all 13 contributors between DeFi LATAM and Optimism Español.\nThese distributions and others can be followed watching my ENS, being also our delegation address (joxes.eth or joxes.defilatam.eth).\n\nOptimistic Holidays!\n\n post by Joxes on Dec 31, 2022\n\n Joxes\n\n ICYMI – we’re postulating to Grants Council for Season 3 in Growth Experiment Sub Committee. An interesting thing, we’re proposing participate as a group, with Joxes (me) as leader and responsible to the vacant, but working as a group composed by 4 contributors.\nRead our entire proposal here: Grant Council Reviewer Nominations - #7 by DeFi_LATAM_Joxes\n\n 17 days later\n\n post by Joxes on Jan 17, 2023\n\n Joxes\n\n And, yes! Happy new year 2023! \nThe last year we have publishing all our activities, and this year we’re keep doing the same and making things better. So, this Monday 01/16 we had our 9th Governance Call in DeFi LATAM in collaboration with Optimism Español to discuss the proposals of this special #9b voting cycle.\nAs a reminder, we continue to improve internally the way our contributors and rest of our community reach consensus on decision making within the Optimism Collective.\nParticipants: +40 attendees. Duration 1hs 40min. As always, many thanks to our contributor Pacha for the design of these POAP series.\nOur voting procedure and rational\nOur evaluation was shared among the contributors and then taken to the community to reach a consensus among the enthusiasts of the OP ecosystem.\nProtocol Delegation Elections\nWe have decided to vote for the following 8 protocols as most voted:\n\nENS\nBeethovenX & Balancer\nConnext\nParaswap\nLi. Fi\nQiDao Protocol\nRevert\n2Pi Network\n\nThese are a mix of protocols of which the community in some way reflects a preference regarding usability, appreciation or recognized builders behind it.\nGrants Council Elections - Growth Experiments\nAfter a great debate about some considerations, mainly because our application to this council sub-committee, we have decided to vote 5 of most properly candidates:\n\n@fig: his contributions to the ecosystem and expertise were well valued as The Optimist Score, as well as his trajectory.\n\n@Bobbay_StableLab: their good level of participation and experience as a group (StableNode) and working with other protocols/DAOs. Bobbay has reproduced this for Optimism governance.\n\n@GFXlabs: in the same line, this group has been in DeFi with a large experience in DAOs and helping to build and grow protocols.\n\n@katie: good commitment and highly recognized in the space for her contributions. Expertise is also well known.\n\nJoxes | DeFi LATAM: we’re generally against voting for ourselves (even before code of coduct was established), leaving the rest of governance to faithfully express their preferences for us, as by example in committee and badger holders elections. In this case OP foundation allowed the applicant delegates to vote for themselves as long as we chose 4 others and the community agreed to take this step. It should be noted that some of our contributors didn’t fully agree with this.\n\nGrants Council Elections - Builders\nRegarding Builders, the community followed up with a good debate to choose the best 3 candidates, resulting in voting for:\n\n@Gonna.eth: several community members acknowledge Gonna.eth (Dhannte) and their work on EthernautDAO, we believe that he is ideal for this work.\n@kaereste: seems as a natural fit for this work also, well recognized in the community for his work on L2beat.\n@jackanorak and @OPUser: there was a technical tie for 3rd place. We see in Jack as likely to strongly contribute in this council based on expertise in protocols and analytics, demonstrated here in governance. In the other hand, we worked with OPUser in DeFi C committee and continues to maintain a longstanding dedication to governance, vision, and product. Without a clear consensus, we voted for both.\n\nFinal thoughts\nSeason 3 will be quite different than previous iterations of Optimism governance. Council will occupy efforts that will no longer be the direct responsibility of the full set of OP delegates as was the case last year.With the new approach for grants, let’s see how the new council and foundation can improve the system of delivery of funds to reduce the waste of resources and increase the impact with short periods of time to guarantee the growth of the Optimism ecosystem.\nOptimistic optimism!\n\n SEED Latam | Regarding the selection of the new badgeholders for our members\n\n Load more posts below","tokens":12892,"squid":"spider-07","role":"Council Spider","at":1791347575644,"hash":"4c2faf739dab4e52fce271249be74c59695057b8"}
{"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":"spider-06","role":"Security Spider","at":1791347591649,"hash":"2b610e04cbec88baeb691060f1dc23442d412ed1"}
{"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":"spider-05","role":"Spec Spider","at":1791347591684,"hash":"cc7c8d00a4baf2f3b20d6e427060aa81ba52d020"}
{"url":"https://gov.optimism.io/t/token-house-participation-and-incentives-an-extended-analysis/6479","domain":"gov.optimism.io","title":"Token House participation and incentives: an extended analysis - Communications 📣 / Delegates 🏛 - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n Token House participation and incentives: an extended analysis \n\n Communications 📣Delegates 🏛\n\n season-4\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 13\n min\n\n Jul 2023\n\n 1 / 20\n\n Jul 2023\n\n Mar 2024\n\n post by Joxes on Jul 20, 2023\n\n Joxes\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 numerous changes throughout each season pursuing the best interest for the Optimism ecosystem. From the season 0 to 4, Optimism governance has established different processes for managing governance funds, protocol updates and other decisions to which delegates have had to adapt, even making the process more complex to guarantee; for example, the correct allocation of funds, with the introduction of committees, and later, the Grant Council. Over time, it has been possible to demonstrate the heavy workload that the delegates have had to face. For season 4, less than half of the delegates (>0.25%) had an active participation during the feedback and approval to vote process. In order to align the work of delegates and broaden the desire to participate, we believe that the path is to improve the incentive system aka rewards, as a way to increase the quality and fulfillment of the final goals.\n1. Introduction\nThe launch of Optimism Governance marked a new phase in Web3 financing and Public Goods within the Layer 2 scaling solutions ecosystem on Ethereum.\nDuring this period, the Governance Fund has funded numerous projects, and many OP tokens have been injected into the ecosystem. These achievements have been made possible thanks to the hard work of the delegates in Seasons 1 and 2 and the management of the Grants Council in Seasons 3 and 4.\nGiven the level of maturity achieved by Optimism Governance, it’s essential to consider not only the injection of OP tokens into the ecosystem but also to plan and execute incentives for delegates and other decision-making roles within the ecosystem.\nBecause of the nature of this governance and expected future, it’s critical to continue to keep current known delegates active and to attract new delegates from both the Web3 ecosystem and qualified individuals and groups who can be aligned with the optimistic vision (universities, ONG, foundations, etc.).\n2. Optimistic Heart and Hands-on Work (Workload Volume in Optimism Governance)\nOptimism Governance stands out not only for granting grants to a large number of projects but also for its agile iteration and flexibility to drive the constant growth of the ecosystem. This generates a considerable workload for the delegates, who must manage a dense feedback process to approve proposals.\nTo contextualize the above, let’s examine the work carried out by delegates in previous seasons, with a special emphasis on the current season.\n2.1 Previous Seasons\n2.1.1 Season 1\nThe system was open this season, and anyone could request a grant through a proposal in the forum. For a proposal to proceed to vote, it needed the support of at least 1 delegate with >0.0005% of the voting power (no data could be retrieved on how many delegates had this voting power).\n\nCycle #1: 24 proposals\nCycle #2: 17 proposals\nCycle #3: 9 proposals\nCycle #4: 9 proposals\n\nTotal: 60 proposals\nOP Tokens: 42,630,770.0\n\nNote: only proposals posted on Snapshot are counted.\nSeason 1 presented the challenge of handling many applications and the need for a transparent process to bring proposals to a vote. Changes were implemented in Season 2 to address these issues.\n2.1.2 Season 2\nIn this season, 5 committees were introduced, specialized working groups consisting of 5 delegates each, which provided qualified recommendations on how to vote on each proposal. These committees received OP tokens for their work at the end of the season. For a proposal to proceed to vote, it needed the support of at least 2 delegates with >0.5% of voting power (about 36 delegates throughout Season 2).\n\nCycle #6: 10 proposals\nCycle #7: 14 proposals\nCycle #8: 18 proposals\n\nTotal: 42 proposals\nOP Tokens: 13,118,611.0\n\nNote: Only proposals posted on Snapshot are counted.\nWhile the committees alleviated some of the delegates’ workload, their role could have been more precise, leading to conflicts between proponents and committees and among the committees themselves. In Season 3, the Grants Council was introduced to address these issues.\n2.1.3 Season 3\nIn this season, the Grants Council was established, a group of 9 delegates elected by the governance to manage the Governance Fund grant process under the direction of an individual from the Optimism Foundation. Each council member receives OP tokens at the end of each season.\n\nCycle #10: 73 proposals\nCycle #11: 79 proposals\n\nTotal: 152 proposals\nOP Tokens: 4,538,130.0\n\nThe Grants Council have resolved the main governance issues:\n\nUnclear processes\nWorkload for delegates\nConflicts among delegates\n\nIn the meantime, a portion of delegates accepted the responsibility of being part of the Citizen House for retroPGF 2. In numbers:\n\n10 were selected via governance nomination and voting\nOther few via other badgeholders nomination\n195 projects analized\n2 weeks for revision + several others for preparation and onboarding\n\nWhile this represents a significant achievement for governance, Season 4 has reintroduced new workloads per unit of time for delegates through missions.\n2.2 Season 4\nThis season, missions have been introduced, consisting of proposals for specific initiatives to achieve short-term objectives (Intents). Any individual, team, or company can submit a mission proposal through a post on the forum, following predefined rules. For a mission to proceed to vote, it must have the support of at least 4 delegates with more than 0.25% of voting power (63 delegates with enough voting power for the first month of Season 4).\nA total of 49 mission requests were received, out of which only 31 proposals went to voting. Despite having established rules for missions, they have reintroduced a workload for delegates and a low level of participation has been observed among them.\nA table has been prepared by manually extracting data from the forum during the proposal pre-selection stage.\nDelegate Support Intent #1:\n1152×410 30.9 KB\nDelegate Support Intent #3:\n1153×773 62.1 KB\nDelegate Support Intent #4:\n1153×736 59.7 KB\nTotal support from participating delegates:\n1537×443 80.8 KB\n2.3 Current Participation and Voting Data\nBased on the data presented in the previous section, the following figures can be extracted:\n\nTo date, Optimism Governance has a total of 1,125 delegates.\nOnly 63 delegates possess more than 0.25% of the voting power.\nOf these, only 27 delegates supported missions.\n\n7 delegates (violet) are current members of the Grants Council.\n5 delegates (yellow) belong to the Protocol Delegation Program Season 4.\nDelegates @mastermojo and @MattGov.eth (red line) supported missions with the same address, as clarified in their delegate statement, and could be considered a single delegate for the purpose of this assessment\n13 delegates (white) are independent or have no additional duties or external incentives.\n\n12 delegates supported less than 5 missions.\n\n5 delegates supported only 1 mission.\n5 delegates supported only 2 missions.\n1 delegate supported 3 missions.\n1 delegate supported 4 missions.\n\nNote: If any delegate is missing or errors are detected, please report it here in the post for correction.\nAdditionally, it’s worth noting that the following behavior could be evidenced among the delegates in the forum:\n\nOut of the 27 delegates, 13 only supported proposals without providing feedback to the proponents.\nDelegates with a low number of supported missions maintained constant activity during the feedback stage, such as @jackanorak, @MinimalGravitas, joxes team group, and others.\nDelegates who did not reach the 0.25% VP threshold actively participated during the mission feedback period, such as @opuser, @lee0007, @brichis, @itublockchain.\n\nSummary reflextions\nThe granting of subsidies generates significant interest in Optimism’s governance from teams, builders, protocols, communities, grant seekers, and others. This results in a high volume of requests on the forum. Such many requests imply a heavy workload for delegates, who must filter, provide feedback, vote, and communicate.\nThe constant interaction and workload make it difficult to onboard new delegates to governance and exhaust those who have been present since the beginning. Having active and committed delegates is crucial to eliminate or disincentivize malicious actors within the governance.\n3. Pursuing better incentives to strengthen governance\nAs mentioned earlier, the Grants Council has resolved governance issues faced in Seasons 1 and 2. This is partly because the delegates participating in the council are aligned with the Optimistic Vision and receive appropriate incentives for their work, considering it a job.\n\nThanks to this, we now have a competitive and efficient team capable of processing many requests.\nHowever, this doesn’t mean that the same Grant Council model is applicable for the rest of the missions and resolves the season 4 problems automatically. It would be impractical to create a new council for each initiative of the Optimism Collective, with its own rules and members. Instead, we must focus on establishing the necessary incentives for delegates to maintain consistent activity and participation in governance.\nIn each season, incentives have been given to delegates, but those don’t seem attractive enough to keep their commitment to governance:\n\nRetroactive Delegate Rewards for Season 1 & 2\nRetroactive Delegate Rewards: Season 3\n\nTherefore, we should establish a continuous payment system, by example, per voting cycle or other more predictables, that allows delegates to focus on governance. Additionally, we should implement a system in which those who don’t meet minimum pre-established requirements, related to expected grade of involvement, will lose their token allocation, allowing another delegate interested in governance to take their place.\n\nNext steps and open questions\nApproaching the path to have an established policy and more coherent with the work of delegates who are 100% committed to the Optimistic vision, a new system should be established and raise the requirements that lead to a more professionalized and diverse work on those who are already active and potential new ones. For this, it’s important to define what type of attitudes to reward and where to direct the focus for greater success. This means that we must be prepared to answer these questions:\n\nHow to attract new delegates?\nHow to catch the attention of delegates who have lowered their participation?\nHow to define the quality of a dedicated delegate?\nHow can the delegate be encouraged to share the Optimistic vision and bootstrap more participants and elevate the quality?\nWhat other activities of a delegate to evaluate besides participation in on-chain voting?\nWho monitors delegate activities?\nBased on previous experience, what is the direction to take for the reward allocation reassessment?\nWhat is the reward mechanism that best suits the current state of Optimism Foundation operations?\n\nThis and other considerations are aspects that we continue to evaluate based on this analysis that leads to a design that entails an improvement in processes and incentives, and that we invite delegates and community members to contribute in the discussion spaces.\n4. Conclusion\nAs we found in this analysis, mainly focused on season 4, heavy workload and rewards are not leading to growth in engagement and diversity when it’s critical to have it. In order to best allocate governance funds to achieve the proposed goals, we must propose new incentives that are attractive for delegates to start working in a more committed way with diverse opinions and minimizing the effect of individual interests in specific decisions.\nFrom SEED Latam, we have been observing the current situation, having internal discussions that lead to the solution of this problem that can encourage a large number of committed delegates; and meanwhile we keep working on, now we want to raise the discussion with the entire community.\nAt the end of the day, the final goal is to achieve more committed delegates, improve the quality of the discussions and deal with the diversity of opinions. Only in this way, Optimism governance and protocol will reach the state of maturity that the entire Ethereum community wants to see and perpetually benefit from its technology: in favor of public goods, open-source movement and all of the aspects behind the Optimistic vision that we all share.\n\n Token House participation and incentives: Season 5 (Cycle 16-19)\n\n Retro Delegate Rewards: Season 4\n\n Season 4 Feedback Thread\n\n How Base will participate in Optimism Governance\n\n SEEDGov- General Communication Thread\n\n 7\n\n 2\n\n 2\n\n 2\n\n read \n\n 13\n min\n\n post by OPUser on Jul 21, 2023\n\n OPUser\n\n Hi @Joxes\nThank you for taking the time to write this. You and your team have summarized it quite well, and I appreciate the acknowledgement of my effort.\nReviewing proposals asks for a significant time and effort commitment. Getting more input from the collective, via some incentive, would add value to this governance.\nI was not even included in the season 3 retroactive reward, but it does not stop me from contributing, with my limited knowledge, to our governance. If I didn’t talk about this at the time, I don’t see any point in talking about it right now.\nWhile some reward could help others to attend web3 related conferences in real life, for others, it could act as motivation to contribute, which is just fine and should be encouraged.\nOur already existing process is quite good, i would only suggest a small change : X + Y = Z (reward)\nX = (voting power + activity on the forum + on-chain voting)\nY ?? Some changes to include new/low voting power delegates (again, I could possibly be on the receiving end of this, so leaving it for others to fill)\nAnother approach would be rewarding delegates for their contributions via RPGF. The challenge here is the missing context. Citizens not active in our governance would not be able to properly reward the delegates because of a lack of context. What we get is one page to write about our efforts, and at the end of the page, we are one step away from pivoting RPGF to a selling pitch. One with better writing and presentation skills will have leverage over others.\n\nwe must propose new incentives\n\nThe challenge is quite apparent. If announced in advance, we could see a boost in new users and delegates and quite possibly more noise. Remember the Connext proposal thread; creating an account here is free and takes only a few clicks. With a framework in place, we might be able to filter the noise from contribution.\nI am always in favor of bringing more motivated individuals to our governance and giving them a stage to present their thoughts and ideas.\n\nWe just had Tally sponsored DAO event, I dont have metric to to check if its was success or not, CoinBase is also encouraging users to delegate(from their wallet). Perhaps, we could do something like Uniswap that was a huge success for them.\n\nParticipation will improve if we reward them, not necessarily in $$\n\nOne suggestion would be to check their rational when they vote, not to name shame but voting for only 1 proposal under an intent when many are nominated raise question, specially when its delegated to you from Foundation. Accountability is missing from all DAO, providing rational will boost accountability.\n\nEducation; share about Optimism and superchian where you can. Not just the good but bad and ugly side as well. We are working on iteration and should accept our mistake equally.\n\nIn long term, Citizen house. In current form, foundation is doing an excellent job.\nCompensation and reward, I will leave for others to decide.\n\n5 delegates (yellow) belong to the Protocol\n\nSeriously ? only 5. We should work on this, I did gave them a nudge but not enough.\n\n post by MoneyManDoug on Jul 21, 2023\n\n MoneyManDoug\n\n Great write up. Thanks for gathering all that data; it couldn’t have been easy . In all honesty, though, I think we should expect quite a boost in participation here soon. Many delegate awareness initiatives have been approved as missions, and other projects have started their own initiatives. I also believe it may be up to us as delegates to help onboard new delegates and reengage existing ones.\n\n post by Oxytocin on Jul 21, 2023\n\n Oxytocin\n\n Hey @Joxes , as always, thanks for the great insight and thoroughness of this. I was looking to share my similar thoughts in the Feedback Thread , but since you’ve already begun the discussion with data to back it up I wanted to share more insight ( although I spot a typo in my delegate name ).\nAs seen with the activity of Season 4, I currently don’t believe the Token House is scalable. Compared to any governance protocol I have participated in or followed, this missions cycle had the most amount of work that had to be checked by (mostly) volunteers in the relatively limited voting period of 4 weeks. This leads to every delegate having to make a choice: is it better to go through many proposals quickly, or go thoroughly through a few?\nPersonally, I thought it was better to go for the latter, not only to help the applicants but to point to other delegates on things to watch out for before approving similar proposals (many missions from the same intent shared very similar content from each other). However, this ended up being much more time consuming than initially expected, with my usual allocated time for delegation barely being enough to ask questions to 4 proposals and approve 1.\n\n5 delegates (yellow) belong to the Protocol Delegation Program Season 4 .\n\nAlso worth noting here that currently the foundation is planning to discontinue the protocol delegate programme by the end of S4, guaranteeing at least a 20% decrease in active delegates with more than .25% of voting power by S5 ceteris paribus. I obviously would prefer a non-protocol delegate to decide whether a solution is even needed for this, but it’s a given that this change will decrease the pool of approving delegates even further.\n\nAlthough not relevant anymore starting from S5, also worth noting that protocol delegates were excluded from these rewards, this is something that I brought up before in the past as a potential reason for lack of protocol delegate activity (as all protocol delegates have at least 1 other project to devote to full-time)\nWhether better delegation rewards is the way to go or not I think it’s best to let other users decide, but in its current state, I really believe that we have to find a way to make becoming a (relevant) delegate less of an uphill and unproductive battle than it currently is, as this could bring issues to the proposed bicameral system .\nI am hoping this is just an issue of awareness and the new misisons dedicated to this solve it, but it’s always best to plan for failsafes in case this is not the case!\n\nPersonally disagree with this, especially since the Token House and Citizen Houses are supposed to oversee each other. Citizens giving RPGF to ‘good’ delegates is very subjective, and could quickly devolve to favoritism and both houses getting tied together in ways I do not feel comfortable.\n\n post by linda on Jul 21, 2023\n\n linda\n\n Thanks for your work on this! One thing I would note that I don’t feel is fully captured in participation here is a delegate reviewing a proposal but not getting to a support for different factors (e.g. budget amount requested) and giving their feedback on it. Otherwise these metrics showing number of proposals supported can incentivize only supporting/approving proposals.\n\n post by AxlVaz on Jul 21, 2023\n\n AxlVaz\n\n MoneyManDoug\n\n I think it is a mistake to leave this in the hands of the missions or any other temporary incentive. Governance must be the one that incentivizes the delegates, we cannot leave this in the hands of third parties. Delegates have to be aligned with the Optimism Collective not with a protocol or a spontaneous objective. We have to think long term. On the other hand, as you yourself say, this is part of encouraging others to join to participate in governance.\nThis is a personal opinion and not of the delegation in which I collaborate, which is SEED Latam.\n\n post by AxlVaz on Jul 21, 2023\n\n AxlVaz\n\n linda\n\n Thank you for your comment, for what you mention we also leave some observations below. We know that we cannot capture everything in these metrics, but we can observe that we are always the same people who have been participating in the forum for a long time. We need to add new voices that bring a critical view to governance. We think it is important to show it and take action on it.\nThis is a personal opinion and not of the delegation in which I collaborate, which is SEED Latam.\n\n post by brichis on Jul 21, 2023\n\n brichis\n\n Thank you so much for this analysis of participation. It’s really enriching to see the evolution of governance this year, especially as one of the newer delegates. I agree that there is a type of participation that hasn’t been fully considered in the analysis, and it’s important to acknowledge it. The feedback for the missions added a lot of value to the process, but unfortunately, only a few delegates provided it. Personally, I took the time to read all the proposals, and it was quite time-consuming. I believe this model might not be able to scale effectively because if the alliances and missions continue, the number of proposals will only increase.\nThe fact that only delegates with more than .25% voting power can approve missions leaves out individuals like @Michael , @itublockchain and even you and your team were on a fine line between passing or not. The work you and your team did is invaluable. I don’t have the definitive answer, but I think it would be great to provide opportunities for people who have the enthusiasm and share values with Optimism but lack sufficient voting power to participate more actively in governance. As a Mexican delegate, it’s challenging to get more than 100k OP delegated, which represents a significant amount of money in Mexican Pesos. I will work hard to achieve it, but it would be fantastic if the path could be made a little easier for those who come with enthusiasm to participate.\nLastly, I want to express my gratitude for feeling that my efforts are appreciated. Thank you for that.\n\n post by AxlVaz on Jul 21, 2023\n\n AxlVaz\n\nThere was a lot of discussion about this in the past and today we see the results, also the delegated protocols came when the Council was already working. However, from this governance it was always said that the protocols deserved a say because they were the ones that best aligned with Optimism.\nI believe that Optimism this time has to bet on its delegates who are the basis of this governance and decentralization.\nIn my opinion, delegation in protocols should continue, we should let some things mature, sometimes I think we iterate too fast and this does not allow us to see and measure the real impact.\n\nWhat do you mean by other users deciding? I think it is a matter of governance.\nOn the other hand, I understand that protocol delegates have other responsibilities and I think other delegates who can get involved in Optimism should be encouraged. As you rightly say, one way to be a competent delegate that is not difficult is to have the necessary incentives, including financial ones.\nThis is a personal opinion and not of the delegation in which I collaborate, which is SEED Latam.\n\n post by AxlVaz on Jul 21, 2023\n\n AxlVaz\n\nI think it is a mistake, for the same reason you say, you don’t always have all the context and you always vote for the best known. For me we have to have the necessary incentives for delegates to have continuity and activity in governance.\nThis is a personal opinion and not of the delegation in which I collaborate, which is SEED Latam.\n\n post by Oxytocin on Jul 21, 2023\n\n Oxytocin\n\nApologies if it didn’t sound clear, should’ve said other delegates not users!\nBasically, I was trying to say that as a protocol delegate, I would rather not steer the discussion too much of how to proceed with the protocol delegation programme as any incentives/benefits might come across as self-dealing and I might carry very obvious biases.\nSpeaking more as an individual than as a protocol delegate, I do agree that the programme is still on its early stages , and its lack of participation in this stage should not be indicative on whether letting protocols participate with governance is not possible.\n\n post by chaselb on Jul 23, 2023\n\n chaselb\n\n Quick correction to the data here. I have >.25 % of VP through Blockchain@USC. So anywhere I provided feedback was on behalf of Blockchain@USC. I’ll have some fuller thoughts on this later.\n\n post by AxlVaz on Jul 24, 2023\n\n AxlVaz\n\n Yes, but we did not include comments that were outside the approval period.\n\n 9 days later\n\n post by abuchtela on Aug 3, 2023\n\n abuchtela\n\n OPUser\n\n Great write up I’m sorry as to you aren’t the only one recieving no incentives not even 1-2or 3 of the drops either but still participating\n\n post by itublockchain on Aug 5, 2023\n\n itublockchain\n\n Firstly we appreciate your detailed analysis @Joxes, that was something that we’ve been talking about in our ITU Blockchain Delegation Team. We’re aware that’s consequential sustaining the engagement of existing recognized representatives and drawing in fresh participants from both the Web3 community and capable individuals and collectives who share optimistic vision.\nIn the Web3 ecosystem, Optimism reaches individuals from all fields, naturally leading to a high demand in governance and forums. In the face of this demand, as delegates, our responsibility is to adequately address this demand in exchange for the tokens allocated to us. This involves ensuring activity in forums and voting stages, and sharing our decisions with the community. As evident from your comprehensive and labor-intensive report that you shared with us, governance is evolving rapidly, and as delegates, it’s essential to keep up with this pace to keep the ecosystem vibrant.\nWe, the ITU Blockchain Delegation Team, diligently review each proposal and share our justifications with you. As @brichis mentioned, finding delegated 100k OP tokens is no easy feat. Especially in the MENA region we represent, where investors are relatively scarce, acquiring such an amount is challenging. We also believe that incentives should be in place to retain existing active delegates.\nWe appreciate your understanding. Your support in this matter is crucial as we work to maintain an active delegate community and uphold the vitality of the ecosystem.\n\n post by AxlVaz on Aug 5, 2023\n\n AxlVaz\n\nExactly, this is what we believe needs to be done. We believe that to make governance more pluralistic and maintain activity there must be incentives for delegates. Currently in Optimismo it is easier or more attractive to run for a grant than to actively participate in governance (apart from board members who receive appropriate incentives).\n\n 8 months later\n\n post by Oakfloors on Mar 25, 2024\n\n Oakfloors\n\n Hi, I’m new here so apologize if my reply is outside of the discussion.\nI think I’m a potential future delegate that could help with the workload described here but I am not as of today. I will try to explain what is lacking for me to dedicate time to the Token house and other Optimism activities. This will hopefully add to the discussion and maybe I can help move it forward.\nMy main obstacles for committing time:\n\nI have no idea how much time would be required of me. I’m already working full-time and have family responsibilities. And I don’t like to commit to something that I don’t know if I’m able to follow through.\n\nI don’t understand the financial compensation of the work. And although I’d like to become financially independent that’s not my motivation. I prefer a balance between the potential financial upside and risks. A suggestion further up is to allocate smaller payments to participation in individual tasks or groups of tasks sounds smart to me.\n\nI find it really hard to find relevant information. I would love to start small but I don’t know how to do it and I don’t know where to find the information I need to get going. I would like to participate in real-world training at a conference but I live in Europe and going to Denver isn’t realistic. Online training is a good alternative.\n\nSuggestion to look into\nMy guess is that all my obstacles are clearly addressed somewhere on gov.optimism.io. But it’s not easy to find under “how to?” category.\nI work at the local municipality and about to start a project on plain language. The goal for this project is that the population of the city should understand what the letters that we send them actually means. It shouldn’t be too much to ask for but it’s really difficult to do in practise.\nWe have started the process by training volunteers to “read” official documents that we send out and give us feedback on how they feel when reading. Example: “I feel overwhelmed when I look at this document. I don’t even want to start reading because there’s just too much text”. This person was not one who struggled with the local language or in general.\nMy feeling when entering gov.optimism.io is “I’m overwhelmed, where should I start”. I’m confident the information I need is there so I feel “dumb” for not finding it.\nI hope this makes sense. I guess the three obstacles I mentioned are symptoms and the plain language part addresses the underlying challenge of onboarding new delegates.\nPlain language\nLanguage that is plain to one set of readers may not be plain to others. Material is in plain language if your audience can:\n\nFind what they need\nUnderstand what they find the first time they read or hear it\nUse what they find to meet their needs\nWhat is plain language?\n\n post by AxlVaz on Mar 25, 2024\n\n AxlVaz\n\n Hi, thanks for your comments, here is an update of season 5, this season we are referring to is already finished.\n\n post by Oakfloors on Mar 25, 2024\n\n Oakfloors\n\n Thanks!\nDo you think my comments would fit anywhere in the DAO discussions?\n\n post by brichis on Mar 25, 2024\n\n brichis\n\n Oakfloors\n\n GM @Oakfloors! I suggest you start by adding the governance calendar. Tomorrow, we have the Community Call of the cycle at 18:00 GMT. You can access it here:\n\nAdditionally, @eugenia has recently begun sharing the OP Bulletin, which is great for finding everything in one place:\n\nWhile there isn’t a formal training program, I recommend starting with these posts:\n\nHave a great week!\n\n Related topics\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 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 Addressing Voting Apathy in Optimism Governance\n\n Delegate Updates\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 [Temp-Check] - Give Incentives to Solve Voters Apathy\n\n Delegates 🏛\n\n As we are about to ponder around way to improve engagement in our governance, I would like to restart the conversation on solving voter’s apathy. \nI brought this topic on many occasion in the past [1, 2], this(Solving v…\n\n read more\n\n 38\n\n 3.8k\n\n Jan 2023\n\n Token House participation and incentives: Season 5 (Cycle 16-19)\n\n Delegates 🏛\n\n During the previous season, we conducted a report that served as a reference for measuring participation in Governance (you can see it here). \nFirst of all, we want to acknowledge the contributions of @dmars300, @brichis,…\n\n read more\n\n 8\n\n 1.8k\n\n May 2024\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 3d","tokens":8209,"squid":"spider-07","role":"Council Spider","at":1791347599206,"hash":"83ad722f42cd00a9784e9cafab174f014ccf6ad2"}
{"url":"https://docs.soliditylang.org/en/latest/080-breaking-changes.html","domain":"docs.soliditylang.org","title":"Solidity v0.8.0 Breaking Changes — Solidity 0.8.38-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":"spider-05","role":"Spec Spider","at":1791347601580,"hash":"6c1fe28bebfc06b374397a56bf851192a645a5cf"}
{"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":"spider-06","role":"Security Spider","at":1791347601833,"hash":"268e4021f4f247e272b8de05718c1b5a4e1cb043"}
{"url":"https://docs.soliditylang.org/en/latest/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":"spider-05","role":"Spec Spider","at":1791347611387,"hash":"0ca2c497d6581696d0255c2458b9d6971ae0b89a"}
{"url":"https://docs.jup.ag/user-docs/earn/offerbook/faq","domain":"docs.jup.ag","title":"Offerbook FAQ - Jupiter Documentation","text":"Offerbook is a peer-to-peer lending protocol on Solana. Users borrow or lend USDC against onchain collateral (the asset locked by the borrower for the duration of the loan). Loan duration is set by the offer creator (1 to 30 days), with no price-based liquidations and no oracles. This FAQ covers the most common questions.\n​Assets\nWhat assets can I use as collateral?Any Solana asset (verified tokens on Jupiter, RWAs such as xStocks, NFTs from whitelisted collections) can be used as collateral. The collateral you choose directly affects how attractive your offer is.What asset can I borrow or lend?USDC (a dollar-pegged stablecoin) is the only asset that can be borrowed or lent on Offerbook.\n\n​Offers\nHow do I create an offer?Both borrowers and lenders can create offers through a step-by-step flow: choose a side (borrow or lend), define the collateral asset and amount, USDC amount, LTV (Loan-to-Value, the ratio between borrowed USDC and collateral value), APR (Annual Percentage Rate, for borrowers) or APY (Annual Percentage Yield, for lenders), loan duration, expiration, and partial fill preferences. The offer is then published in the offerbook.Lenders: Make sure your escrow wallet has sufficient USDC before publishing. Offers without enough balance will not be visible to other users.Can I edit an offer after publishing it?No. To change the terms of an offer, you need to remove it and create a new one. However, once an offer expires, you can renew it directly from Dashboard > Offers without recreating it (with the option to adjust the LTV before renewing).Can I remove an offer before it expires?Yes. An offer can be removed at any time before it is accepted. No fees are charged.How long does an offer stay in the offerbook?Offers expire after 1 to 7 days, set by the offer creator (borrower or lender) at creation (the Create Offer flow offers 1, 3 and 7-day presets).This is separate from the loan duration: the loan countdown only starts when an offer is accepted, not when it is published.Can I accept an offer partially?It depends on the offer creator’s settings. When creating an offer, the creator can enable or disable partial fill, and set a Minimum Fill Amount (in USD). If partial fill is enabled, you can accept any amount equal to or greater than the Minimum Fill Amount. If disabled, the offer can only be filled in full.When an offer is partially filled, protocol fees apply to the filled portion only, and the remaining amount stays available to other counterparties until the offer expires.Partial fill is not available for offers using NFT collateral.Is there a minimum or maximum amount for an offer?There is no fixed minimum or maximum at the protocol level. The Minimum Fill Amount can be set per offer when partial fill is enabled.Is there a limit on the number of active offers?No. Users can have multiple offers active at the same time.What is a counter offer?A counter offer is a proposal to modify the terms of an existing open offer before accepting it. From the offer, click Counter and adjust the LTV, rate (APY), duration, expiration, or partial-fill rule. The original offer creator can then accept your counter (starting the loan at those terms) or ignore it. Counter offers do not lock any funds until accepted. See Counter Offers for details.Can I use an NFT as collateral?Yes. NFTs from whitelisted collections can be used as collateral. Offers using NFT collateral are per-item: each offer targets one specific NFT. The exception is PFP collections with a floor price, where lend offers can be collection offers: any qualifying NFT from the collection can be pledged.Partial fill is not available for NFT collateral, since an NFT cannot be partially transferred. For NFT collateral with a known floor price, the LTV slider uses the floor price as the reference collateral value.\n\n​Intents\nWhat is an intent?An intent is a free, off-chain advertisement of the lending or borrowing terms you want. It locks no funds and cannot be filled directly. Offerbook matches it against live onchain offers and surfaces the matches in your dashboard. See Intents.Does posting an intent lock my funds or cost anything?No. Posting, editing and cancelling an intent only require a wallet signature. There is no transaction, no gas, no account rent and no protocol fee, and your funds stay in your wallet. For large intents, around $100,000 in value or more, Offerbook checks that your wallet and escrow balances hold the relevant asset before accepting the intent.How do I act on someone else's intent?Create a regular onchain offer with the same token pair and terms close to the advertised ones: APY and LTV (Loan-to-Value) within 10%, duration within one day. Your offer then surfaces automatically in the intent creator’s dashboard, and they can fill it through the standard flow.How long does an intent last?The loan terms you advertise can run from 1 to 30 days, the same range as offers. The intent itself stays active until you cancel it or its expiration lapses; you set the expiration when posting, up to 90 days.\n\n​Loans\nHow does a loan start?A loan starts when an offer is accepted. Once matched, the collateral is locked onchain via a smart contract (a PDA, or Program Derived Address, which is a program-owned account on Solana with no private key) and the USDC is transferred. All loan terms are fixed and immutable from that point. The loan duration begins at this moment.How long does a loan last?Loan duration is set by the offer creator (borrower or lender) and can range from 1 to 30 days. The interface offers presets depending on the flow (such as 3D, 7D, 30D or 7d, 14d, 30d). The countdown starts when the offer is accepted, not when it is published. Once the loan starts, the duration cannot be changed.What is the difference between offer expiration and loan duration?Offer expiration is how long the offer stays visible in the offerbook (1 to 7 days, set at creation). Loan duration is how long the loan lasts once the offer is accepted (1 to 30 days). These are two separate timers.Can a borrower repay the loan early?Yes. Borrowers can repay the loan at any time before maturity. The full interest for the agreed loan duration is owed regardless of when the repayment occurs. There is no partial interest or fee reduction for early repayment.Can I extend a loan instead of repaying it?Only if the lender allowed extensions on the offer you filled — those carry a ↻ marker next to their duration. If yours is extendable, its row in Dashboard > Positions leads with an Extend button: you pay the closing period’s interest plus the origination fee, and the loan runs on for a fresh period at the same rate, with the same collateral. Extensions are manual and must happen before the deadline. See Loan Extensions.What happens at maturity if the loan is not repaid?After the loan duration ends, the lender can claim the collateral by signing a transaction. This action triggers the collateral transfer: the collateral is sent directly to the lender (not sold on the market). A 0.1% fee is deducted from the collateral at transfer (no fee on NFT collateral).The collateral transfer is not automatic. It only happens when the lender claims. The borrower can still repay and recover the collateral at any time, as long as the lender has not claimed it.Do not rely on this window. The lender can claim at any moment after maturity. Always plan to repay before the loan expires.Can a loan be affected by market movements during its duration?No price-based liquidation, margin call, or forced closure can occur during the loan. However, the collateral is still exposed to price fluctuations. If its value changes significantly, this affects the outcome at maturity for both sides.What are the loan statuses?A loan can have one of four statuses:\nActive: the loan is running, between offer acceptance and maturity.\nRepaid: the borrower has repaid the loan, the collateral has been returned to their wallet.\nExpired: the loan has passed maturity without being repaid. The lender can claim the collateral, and the borrower can still repay until they do.\nDefaulted: the lender has claimed the collateral after maturity. The loan is closed.\nWhere is the collateral stored during the loan?The collateral is locked onchain via a smart contract (a PDA, or Program Derived Address, which is a program-owned account on Solana with no private key) for the full duration of the loan. Neither the borrower nor the lender can access it during this period.What happens when a borrower repays?The borrower pays the principal plus the full interest for the loan duration. The collateral is returned directly to the borrower’s wallet. The lender receives the USDC (principal + interest, minus the 10% repayment fee) in their escrow wallet.What happens if my collateral is a yield-bearing token (e.g., an LST)?For tokens where yield accrues in the token value itself (such as liquid staking tokens), the collateral value will grow during the loan. For tokens where yield must be actively claimed, the yield may not be accessible while the collateral is locked.\n\n​Fees\nWhat fees does Offerbook charge?Offerbook applies fees at three stages:\nAt loan start: 25% of the estimated total interest is taken immediately (USDC), paid by the borrower.\nAt repayment: 10% of the interest is deducted from the lender’s return.\nAt collateral transfer: If the borrower does not repay and the lender claims the collateral, 0.1% is deducted from the collateral (no fee on NFT collateral).\nWho pays the fees?The borrower pays the fee at loan start (25% of estimated interest). The lender pays the fee at repayment (10% deducted from interest received) and at collateral transfer (0.1% deducted from collateral received).What is Effective APR / APY?The Effective APR (borrower) and Effective APY (lender) account for platform fees and are displayed in the offer summary.\nEffective APR is higher than the offer APR because the 25% upfront fee is added on top of the interest. Example: an offer at 30% APR becomes 37.5% Effective APR (30% × 1.25).\nEffective APY is lower than the offer APY because the 10% fee is deducted from the interest received. Example: an offer at 5% APY becomes 4.5% Effective APY (5% × 0.9).\nHow does the fee at loan start work in practice?If a lender fills a borrow offer, the borrower receives the USDC amount minus the fee. If a borrower fills a lend offer, the borrower pays the fee right after receiving the USDC.Is interest reduced if I repay early?No. The full interest for the agreed loan duration is always owed, regardless of when the repayment occurs.Are there other costs apart from protocol fees?Yes, two other types. Offerbook has three cost types in total:\nNetwork fees — Solana gas, around 0.000005 SOL per signature. Never refunded.\nAccount rent — a refundable deposit Solana requires for each new account. Most of it comes back when the account is closed.\nProtocol fees — Offerbook’s cut in USDC (see Fees & Costs). Never refunded.\nRule of thumb: fees are gone, rent is a deposit (most of it is returned when the account is closed). The full rent table by account type is in Fees & Costs → Account Rent.What is the referral program?Offerbook offers a referral system that applies at every stage where a fee is charged. By default, each fee is split:\nReferred user: 20% of the fee\nReferrer: 30% of the fee\nProtocol: 50% of the fee\nThe referred-user share is always credited to whoever is paying the fee at that stage, and the 30% share goes to that user’s referrer: the borrower at loan start, the lender at repayment and collateral transfer. See Affiliate & Referrals for the full program.Can fees change?Yes. Fees are set in the onchain configuration and can be updated by protocol admins. The rates described in Fees & Costs are the current defaults.\n\n​Risks\nWhat are the main risks for borrowers?If you do not repay before the end of the loan duration, the lender can claim your entire collateral at any moment. While you can technically still repay until the lender claims, do not rely on this window. Repayment timing is your responsibility. The full interest is always owed, even if you repay early.What are the main risks for lenders?Collateral value is not monitored during the loan. If the collateral loses significant value before maturity and the borrower does not repay, you receive the collateral token directly (not USDC), and may need to sell it at a loss. The higher the LTV (Loan-to-Value, the ratio between borrowed USDC and collateral value), the higher this risk. You must also manually claim the collateral after maturity.Are there price-based liquidations?No. Offerbook loans are time-based. Market price movements during the loan do not trigger any liquidation or margin call. After maturity, if the borrower has not repaid, the lender can claim the collateral by signing a transaction. This is a direct transfer, not a sale on the market.Has Offerbook been audited?Yes. Offerbook has been audited by Cantina. The full report is available here: Cantina Audit (May 21, 2026).\n\n​Escrow Wallet\nWhat is the escrow wallet?A dedicated wallet, separate from your main Solana wallet, used to hold funds while interacting with Offerbook. Each user has one escrow wallet. All funds transit through the escrow when creating or accepting offers.For lenders, the escrow is visible in the interface. For borrowers, it is used in the background and is not visible.Do lenders need to deposit USDC into the escrow before creating an offer?An offer cannot be created without the USDC backing it, but you do not need to deposit beforehand: the required USDC is deposited from your wallet into the escrow as part of offer creation.Can my escrow balance support multiple offers?Yes. Lenders can create multiple lend offers from the same USDC balance, and all of them are visible at the same time. When one offer is accepted and the USDC leaves the escrow, any remaining offers that are no longer covered by the balance are hidden automatically.Can I withdraw from my escrow at any time?Yes. You can withdraw USDC at any time. If withdrawing makes your balance insufficient to cover active offers, those offers are automatically hidden.What happens to repaid funds?When a borrower repays a loan, the USDC (principal + interest, minus the 10% fee) returns to the lender’s escrow. It can be reused for new offers without withdrawing to your wallet first.How does the escrow work for borrowers?For borrowers, the escrow is invisible. Collateral transits through the escrow automatically in a single transaction when creating or accepting an offer. When the borrower repays, collateral is returned directly to their wallet.What are the costs to use the escrow wallet?Depositing an asset into your escrow requires funding a Solana account: 0.00203928 SOL the first time you deposit a given asset. This rent is a deposit rather than a fee: it is refunded when you withdraw the asset.A separate escrow account is required for each distinct asset, so borrowers typically open more of them over time than lenders, who generally only need a USDC account.See Fees & Costs → Account Rent for the other account types.\n\n​Notifications & Settings\nHow do I enable notifications?Open the Settings page (gear icon in the navigation header), then go to the General tab and connect a notification channel: Telegram or Email. Connecting a channel requires signing a message to prove you own the wallet.You can set your preferences in the Notifications tab before connecting any channel, and a verified Email is enough on its own: Telegram is not required. Toggle individual notification types on or off (Offer accepted, Counter offer received, Loan due soon, etc.). See Settings & Notifications for the full list.What if I'm using a hardware wallet?Hardware wallets (Ledger and others) cannot sign arbitrary messages. To sign in to Settings and connect a notification channel with a hardware wallet, turn on Using a hardware wallet (Ledger)? on the Settings sign-in screen; once signed in, the same option is I’m using a hardware wallet in the General tab. Authentication then uses a signed transaction instead of a signed message.Can I hide my balances on screen?Yes. Turn on Privacy mode in Settings → General to mask your portfolio totals, PnL and balances on the device you are using. Market data stays visible. See Settings & Notifications.What is auto top-up?Auto top-up is the mechanism that automatically deposits the required funds from your main wallet into your escrow when you create an offer: collateral for a borrow offer, USDC for a lend offer.Two toggles for it are visible in the Escrow Settings but are not yet active (greyed out); for now, the deposit always happens automatically as part of offer creation.\n\n​Chat\nHow do I start a chat?Click the floating green button in the bottom-right corner of the interface and choose Messages. The first time you open Chat, approve the wallet signature to authenticate. You can then join public Channels (currently just General) or send a Direct message to another user by username or wallet address. See Chat for the full overview.How do I sign in to Chat with a Ledger?Hardware wallets cannot sign arbitrary messages. On the Chat connect screen, turn on the Ledger toggle before clicking Connect to chat: sign-in then uses a memo transaction instead of a message. If you leave it off and the message signature fails, the app offers the transaction sign-in. Approve the empty memo transaction in your wallet to complete sign-in. Your wallet needs a small SOL balance to pay the network fee.How do I share an offer in chat?From any conversation (channel or DM), click the + button on the left of the message input and choose Send an offer. A list of your open offers appears; select the one you want to share. The recipient sees a preview card with the offer terms (principal, collateral, APY, duration, LTV) and can open the full offer with one click.","tokens":4488,"squid":"spider-02","role":"Liquidity Spider","at":1791347616608,"hash":"9164bfcc0a22b9fd57052949ca76f922c2fdbd98"}
{"url":"https://ethresear.ch/t/relay-inclusion-lists/22218/9","domain":"ethresear.ch","title":"Relay Inclusion Lists - Proof-of-Stake / Block proposer - Ethereum Research","text":"Proof-of-StakeBlock proposer\n\n mev,proposer-builder-separation,censorship-resistance\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 10\n min\n\n Apr 2025\n\n 9 / 9\n\n May 2025\n\n May 2025\n\n post by kubimens on Apr 25, 2025\n\n post by famouswizard on Apr 26, 2025\n\n post by remosm on Apr 28, 2025\n\n post by aelowsson on Apr 29, 2025\n\n post by remosm on May 2, 2025\n\n post by aelowsson on May 4, 2025\n\n aelowsson\n\n Thanks, just a few clarifications:\nThe purpose of applying a threshold like max_fee_per_gas * n > base_fee_per_gas with, e.g., n=2 is to make manipulation of the normalization step more difficult. Without such a threshold, one could submit transactions with a low max_fee_per_gas to skew the normalization process, even if those transactions are not intended to be included. The thresholding of the mempool is thus specifically for making the normalization step less arbitrary, and is only necessary under normalization. If txs are directly ranked from an equation such as\n\nthen txs that are not included will not have any influence on which txs that are included. This reduces the opportunities for the relay to manipulate the outcome (albeit, it can still nudge the registration time). The transacting user that did not have its tx included can simply review included txs to confirm that those score higher (at least the score will not depend on non-included txs, while registration time is still not objective).\n\nAnd to be clear, my assumption is that the networking constraint imposed for p2p propagation in FOCIL does not really apply for the relay.\n\nOk, so the inclusion list should be adhered to under full blocks, potentially with a gas threshold. This follows the definition in FOCILR, which differs from FOCIL. In FOCILR, these stronger censorship resistance guarantees are imposed at the protocol level, as opposed to by a single relay. Builders can extract more value when the IL does not constrain which txs it must include. When the harder stance is taken at the protocol level, the proposer cannot avoid them. When the relay takes this harder stance, the proposer has the opportunity to opt out—the option to let the builder control the content of the full block still exists. This will probably have a larger effect on proposer rewards than the latency trade-off discussed in the introduction of the post.\n\nI think the issue is pretty complex given that diverging ILs generally are desirable, and that the dashboard could not reveal collusion between relays. Simply put, IL aggregation in this context seems generally difficult to get right.\n\n 17 days later\n\n post by mikeneuder on May 21, 2025\n\n mikeneuder\n\n related discussion: Resistance is ~not~ futile; CR in mev-boost\n\n post by remosm on May 22, 2025\n\n remosm\n\n Thanks for dropping the link, and props for suggesting rILs this early. We were not aware of this previous discussion, it’s great to see.\nWe think now is a good time to proceed with an implementation.\nSpecifically, by using the 8 kilobytes constraints from the FOCIL specs as a lean starting point and gas- or bytesize-adjusting the transaction inclusion scores, the impact on proposer earnings should be limited.\nThen once several relays run rILs, there is an opportunity to increase the maximum size of the rIL. Multi-relay ILs are also a promising direction to increase censorship resistance and efficiency by enforcing uniform inclusion rule enforcement, and by allowing builders to consider a single rIL only.\nAlso dropping the recording and slides from the related discussion on the FOCIL Breakout #11:\n\nSlides\nRecording\n\n post by mikeneuder on May 22, 2025\n\n mikeneuder\n\nsounds great! super cool that we arrived at the same conclusion hope this is a fruitful implementation and helps pave the way for an in-protocol FOCIL!\n\n Powered by Discourse","tokens":957,"squid":"spider-04","role":"Research Spider","at":1791347618659,"hash":"83acf3628e5d4398bd4e16763850fea2a82d065f"}
{"url":"https://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":"spider-05","role":"Spec Spider","at":1791347622347,"hash":"5bcdf1b5b1470bf303b7b69566125785ca6c5f88"}
{"url":"https://docs.jup.ag/user-docs/trade/gacha","domain":"docs.jup.ag","title":"Jupiter Gacha Overview - Jupiter Documentation","text":"Jupiter Gacha is a pack opening product built on two collectibles providers, Collector Crypt and Phygitals. You open digital packs and pull real trading cards (Pokemon, One Piece, Dragon Ball, Riftbound, and sports cards) or, on watch packs, luxury watches authenticated by WristCheck. Every item shown in Jupiter Gacha corresponds to a physical collectible stored with a professional vaulting partner and represented by a token on Solana.\nWhen you pull a card, you own the token that represents the physical card. From there, you choose what to do with it.\n\n​What you actually own\nEach card in Jupiter Gacha is a real, physical trading card held in custody by a professional vaulting partner. Most cards are graded slabs from a grading company such as PSA, CGC, or Beckett; the Sport Practice and Pokemon Trainer packs also contain ungraded cards. Collector Crypt cards are stored with vaulting partners such as PSA Vault or OmniVault, listed in the Vault details section of the card’s page. Phygitals cards are stored in the United States with PSA Vault, Fanatics Vault, or Alt Vault.\nThe card is tokenized on Solana. Owning the token means owning the claim to the physical card. You can verify a graded card’s grading company, grading ID, and grade directly on its card detail page.\n​The four options after a pull\nAfter opening a pack, you have four options for the card you pulled:\n\nSell it back instantly. Every pull carries an instant buyback at the pack’s displayed rate, available for 3 days on Collector Crypt packs and 7 days on Phygitals packs. See Instant Buyback.\nList it on the marketplace. Set your own asking price and sell to other collectors. Collector Crypt cards only. See Marketplace.\nKeep it. The card stays vaulted and appears in your Collection. There is no time limit and no storage fee.\nShip it home. Redeem the card to receive the physical card at your address: from Jupiter Gacha for a Collector Crypt card, through Phygitals for a Phygitals card. See Shipping.\n\nYou can also give things away: gift packs to another wallet, or send a card you own to a friend by transferring its token from your wallet. See Gifting.\n​Two providers, one interface\nCollector Crypt supplies the Pokemon packs from Silver to Immortal, the Watch packs, the Dragon Ball packs, and the One Piece Straw Hat, Emperor, and Gorosei packs, runs their draws through its on-chain verifiable randomness program, operates the marketplace, and ships its cards. Phygitals supplies the Sport packs, the Pokemon Trainer pack, the Riftbound packs, and the One Piece Throne pack; its cards are shipped and resold through Phygitals or external marketplaces rather than from Jupiter Gacha. The app does not name the provider on a pack or a card, and a few rules differ between the two: the buyback window, Turbo mode, gifting, marketplace listing, shipping, and how randomness is verified. See Providers for the full comparison.\n​Fees\nOpening packs carries no platform fee: you pay the pack price in USDC plus Solana network fees. Selling a Collector Crypt card on the marketplace carries a 2% fee on the sale price. Shipping a card home carries shipping fees set by the provider shipping it, Collector Crypt from Jupiter Gacha or Phygitals on its own site. There are no other user-facing fees.\n​Risk disclosure\nPack opening outcomes are random. Each pack displays fixed drop odds by rarity tier, and on most packs the majority of pulls fall in the lowest value range, below the pack price. The instant buyback guarantees a floor on the value of every pull, not a profit. Only spend what you are comfortable spending on collectible cards.\nThe expected value displayed on each pack is calculated from the current contents of that pack’s card pool and changes over time. It is an average across all possible outcomes, not a prediction of your individual pull.","tokens":961,"squid":"spider-02","role":"Liquidity Spider","at":1791347629745,"hash":"838b31c9658a12b8b05634f7688c627f9b3299ad"}
{"url":"https://ethresear.ch/t/relay-inclusion-lists/22218/8","domain":"ethresear.ch","title":"Relay Inclusion Lists - Proof-of-Stake / Block proposer - Ethereum Research","text":"Proof-of-StakeBlock proposer\n\n mev,proposer-builder-separation,censorship-resistance\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 10\n min\n\n Apr 2025\n\n 8 / 9\n\n May 2025\n\n May 2025\n\n post by kubimens on Apr 25, 2025\n\n post by famouswizard on Apr 26, 2025\n\n post by remosm on Apr 28, 2025\n\n post by aelowsson on Apr 29, 2025\n\n post by remosm on May 2, 2025\n\n post by aelowsson on May 4, 2025\n\n aelowsson\n\n Thanks, just a few clarifications:\nThe purpose of applying a threshold like max_fee_per_gas * n > base_fee_per_gas with, e.g., n=2 is to make manipulation of the normalization step more difficult. Without such a threshold, one could submit transactions with a low max_fee_per_gas to skew the normalization process, even if those transactions are not intended to be included. The thresholding of the mempool is thus specifically for making the normalization step less arbitrary, and is only necessary under normalization. If txs are directly ranked from an equation such as\n\nthen txs that are not included will not have any influence on which txs that are included. This reduces the opportunities for the relay to manipulate the outcome (albeit, it can still nudge the registration time). The transacting user that did not have its tx included can simply review included txs to confirm that those score higher (at least the score will not depend on non-included txs, while registration time is still not objective).\n\nAnd to be clear, my assumption is that the networking constraint imposed for p2p propagation in FOCIL does not really apply for the relay.\n\nOk, so the inclusion list should be adhered to under full blocks, potentially with a gas threshold. This follows the definition in FOCILR, which differs from FOCIL. In FOCILR, these stronger censorship resistance guarantees are imposed at the protocol level, as opposed to by a single relay. Builders can extract more value when the IL does not constrain which txs it must include. When the harder stance is taken at the protocol level, the proposer cannot avoid them. When the relay takes this harder stance, the proposer has the opportunity to opt out—the option to let the builder control the content of the full block still exists. This will probably have a larger effect on proposer rewards than the latency trade-off discussed in the introduction of the post.\n\nI think the issue is pretty complex given that diverging ILs generally are desirable, and that the dashboard could not reveal collusion between relays. Simply put, IL aggregation in this context seems generally difficult to get right.\n\n 17 days later\n\n post by mikeneuder on May 21, 2025\n\n mikeneuder\n\n related discussion: Resistance is ~not~ futile; CR in mev-boost\n\n post by remosm on May 22, 2025\n\n remosm\n\n Thanks for dropping the link, and props for suggesting rILs this early. We were not aware of this previous discussion, it’s great to see.\nWe think now is a good time to proceed with an implementation.\nSpecifically, by using the 8 kilobytes constraints from the FOCIL specs as a lean starting point and gas- or bytesize-adjusting the transaction inclusion scores, the impact on proposer earnings should be limited.\nThen once several relays run rILs, there is an opportunity to increase the maximum size of the rIL. Multi-relay ILs are also a promising direction to increase censorship resistance and efficiency by enforcing uniform inclusion rule enforcement, and by allowing builders to consider a single rIL only.\nAlso dropping the recording and slides from the related discussion on the FOCIL Breakout #11:\n\nSlides\nRecording\n\n post by mikeneuder on May 22, 2025\n\n mikeneuder\n\nsounds great! super cool that we arrived at the same conclusion hope this is a fruitful implementation and helps pave the way for an in-protocol FOCIL!\n\n Powered by Discourse","tokens":957,"squid":"spider-04","role":"Research Spider","at":1791347629800,"hash":"bc4de28cb3ef307b525f1d85d708afeaf7145624"}
{"url":"https://www.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":"spider-05","role":"Spec Spider","at":1791347632881,"hash":"a70197b9f385962263090e11cb9c6b7b77407e52"}
{"url":"https://docs.jup.ag/user-docs/trade/gacha/providers","domain":"docs.jup.ag","title":"Providers - Jupiter Documentation","text":"Jupiter Gacha is a single interface built on two collectibles providers: Collector Crypt and Phygitals. Each provider supplies its own packs, holds the physical cards in its own vaults, and pays its own instant buyback. The app does not display the provider’s name on a pack or a card, so this page is the reference for telling them apart and for the rules that differ between the two.\n​Which packs come from which provider\nProviderPacksCollector CryptEvery Pokemon pack from Silver to Immortal, the Watch packs, and the One Piece Straw Hat, Emperor, and Gorosei packsPhygitalsEvery Sport pack, Pokemon Trainer ($10), both Riftbound packs (Calm $25, Chaos $100), and One Piece Throne ($2,500)\nProvider does not follow the category: the One Piece tab holds three Collector Crypt packs and one Phygitals pack. Two quick tells in the app: the Instant buyback panel on a pack page reads “within 3 days” on a Collector Crypt pack and “within 7 days” on a Phygitals pack, and Phygitals packs have no Turbo toggle.\n​What differs\nCollector CryptPhygitalsCards in the packsGraded slabs only (PSA, CGC, Beckett), plus luxury watches in the Watch packsGraded slabs (PSA, BGS, CGC). The Sport Practice and Pokemon Trainer packs also contain ungraded cardsRarity tiersCommon, Uncommon, Rare, EpicSet per pack by Phygitals, always topped by a Mythic tierInstant buyback window3 days from the pull7 days from the pullInstant buyback rate85% to 93% of the insured value, set per packSet per pack. 100% of the card’s value on the three launch packsTurbo modeAvailable, and mandatory when a machine runs low on commonsNot availableGifting packsYesYesSelling to other collectorsOn the Jupiter Gacha marketplaceNot on Jupiter Gacha. The card is a Solana NFT and can be listed on the Phygitals marketplace, or on a Solana NFT marketplace such as Tensor or Magic Eden. See Selling a Phygitals card elsewhereShippingFrom Jupiter Gacha (Ship home in your Collection), operated by Collector Crypt from its vaulting partners (PSA Vault, OmniVault, and others)Not from Jupiter Gacha. Redeemed through Phygitals directly, which ships from its US vault partners (PSA Vault, Fanatics Vault, Alt Vault)RandomnessOn-chain verifiable randomness (VRF), checkable from your Activity tabCommit-reveal scheme documented by Phygitals; not checkable from Jupiter GachaRevealAs soon as the transaction confirmsPhygitals settles the opening on its side. The reveal can take a few secondsWhen a pool runs lowTurbo becomes mandatory, or the machine is disabled until restockedThe pack shows as sold out until restockedRewardsBattlepass eligibility is set per campaignSame: a campaign can include Phygitals packs, as the current one doesSupportChat widget at collectorcrypt.comphygitals.com/contact\nEverything else works the same way on both: you pay the pack price in USDC plus Solana network fees, the odds per rarity tier are displayed on the pack and fixed, your pulls land in your Collection, and each card is a token on Solana that you can send to another wallet.\n​Collector Crypt\nCollector Crypt is the original Jupiter Gacha partner. It supplies the Pokemon packs from Silver to Immortal, the Watch packs, and the One Piece Straw Hat, Emperor, and Gorosei packs, runs the pack draws through its on-chain verifiable randomness program, operates the marketplace where Jupiter Gacha cards are bought and sold, and handles shipping from its vaulting partners. Every card it supplies is a professionally graded slab, and every card page lists the grading company, grading ID, and the vault holding the slab.\nFor the Collector Crypt infrastructure itself, see the Collector Crypt documentation.\n​Phygitals\nPhygitals is a Solana-based platform that tokenises physical trading cards. It supplies the Sport packs, the Pokemon Trainer pack, the Riftbound packs, and the One Piece Throne pack. Its physical cards are stored in the United States with three vault partners, PSA Vault, Fanatics Vault, and Alt Vault, and Phygitals states that cards in vault custody are insured through those partners against loss, theft, and damage. Holding the token makes you the recognised owner of the physical card.\n​Graded and ungraded cards\nThe Sport Hall of Fame pack contains graded slabs. The Sport Practice and Pokemon Trainer packs mix graded slabs with ungraded cards. Phygitals states that its ungraded cards are in Near Mint or Lightly Played condition. On the card page, an ungraded card shows no grading company and no grade.\n​Phygitals cards in your Collection\nCards pulled from Phygitals packs appear in your Collection alongside Collector Crypt cards, and their detail page shows the Grading section when the card is graded, the Metadata section, and the Contract info. There is no Vault details section for these cards. The value displayed as Est. value is Phygitals’ fair market value estimate for the card; when Phygitals publishes no estimate, the card shows its current buyback offer instead.\nWhat you can do with a Phygitals card:\n\nSell it back within 7 days of the pull, at the offer quoted on the card. See Instant Buyback.\nKeep it. The card stays vaulted with Phygitals at no cost.\nShip it home through Phygitals. Jupiter Gacha has no shipping flow for Phygitals cards; you redeem the card on phygitals.com. See Shipping.\nSell it elsewhere. The card is a Solana NFT, so it can be listed outside Jupiter Gacha. See Selling a Phygitals card elsewhere.\nSend it to another wallet, like any card. See Gifting.\n\nPhygitals cards cannot be listed on the Jupiter Gacha marketplace, which is operated by Collector Crypt, and cannot be shipped from Jupiter Gacha.\n​Selling a Phygitals card elsewhere\nA Phygitals card is a Solana NFT, so any marketplace that lists Solana NFTs can carry it:\n\nPhygitals marketplace — the provider’s own marketplace, which routes its listings through Solana NFT marketplaces as well.\nTensor — a Solana NFT marketplace.\nMagic Eden — a Solana NFT marketplace.\n\nThese are third-party platforms: they set their own fees, and the sale happens entirely outside Jupiter. Jupiter does not endorse any of them, and a card listed there leaves the instant buyback behind once its window has closed.\nOpen a marketplace from the links above or from your own bookmark, never from a search result or a link sent to you. Lookalike NFT marketplaces are a common scam: they reproduce the real interface and ask you to connect your wallet and sign, which drains it.\n​Geographic restrictions\nPurchases and buybacks on Phygitals packs follow Phygitals’ restricted jurisdictions policy. In a restricted region, the pack page shows “Pack purchases are not available in your region” and the sell action shows “Buyback is not available in your region”.\n​Support\nFor anything specific to a Phygitals card or shipment, contact Phygitals through phygitals.com/contact. For anything else related to Jupiter Gacha, contact Jupiter support. For the Phygitals platform itself, see the Phygitals documentation.\n​Fees\nOpening a pack carries no Jupiter fee on either provider: you pay the pack price in USDC plus Solana network fees. Selling a Collector Crypt card on the marketplace carries Collector Crypt’s 2% fee. Shipping fees are set by the provider shipping the card and displayed before you confirm a shipment. There are no other user-facing fees.","tokens":1826,"squid":"spider-02","role":"Liquidity Spider","at":1791347640030,"hash":"e02ae6bcba0a12d8218e40e3907effff207438ac"}
{"url":"https://ethresear.ch/t/sealed-execution-auction/20060/7","domain":"ethresear.ch","title":"Sealed execution auction - Proof-of-Stake / Block proposer - Ethereum Research","text":"Proof-of-StakeBlock proposer\n\n mev\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 5\n\n 2\n\n read \n\n 12\n min\n\n Jul 2024\n\n 7 / 7\n\n Sep 2024\n\n Sep 2024\n\n post by aelowsson on Jul 13, 2024\n\n post by quintuskilbourn on Jul 15, 2024\n\n post by aelowsson on Jul 16, 2024\n\n post by quintuskilbourn on Jul 16, 2024\n\n post by aelowsson on Jul 16, 2024\n\n aelowsson\n\nRight but that is much weaker (the more applicable in my view is then when they grief each other due to value in flight). The results in the paper you linked depend on the proposer deriving the proceeds of the auction, which is not the case. Therefore, those results do not apply. I’m also a bit hesitant about how well it would apply anyway with a reasonable penalty (that is burned).\n\nAs long as the auction is concluded, every sealed bid that is collated but not revealed will result in a penalty. This penalty can be made prohibitively large. Thus, if we ensure that auctions are concluded, bids will be revealed. There are then nuances pertaining to the conclusion of the auction discussed in the original post.\n\nRight. This was specified in the original post:\n“Builders are staked at a level sufficient for the protocol to penalize them if they fail to reveal committed bids… In the first round, each builder has the opportunity to make one sealed bid over a public P2P layer”.\nA builder will only require one staked identity and can simply bid truthfully in the Vickrey auction by placing one single bid. Thus, capital requirements will not be prohibitively large.\n\nIn the case of a DoS attack on the P2P layer, there will indeed need to be a condition stipulating that a beacon proposer that has “filled” the beacon block should get a pass on including more bids (for obvious reasons). It should however be possible to apply the fee on every valid bid that has been placed ex-post (proposers of subsequent blocks could pick them up just to apply the fee). In either case, as long as we ensure that the aggregate fee when the beacon block is filled becomes prohibitively large, concerns should be alleviated. It is also generally a bad idea to pursue this action when you are a staked entity and must put many millions of dollars on the line in order for a sufficient quantity of bids to propagate across the P2P layer.\n\n post by aelowsson on Jul 18, 2024\n\n aelowsson\n\n Please note that I have added a clarification to the post.\n\nThis penalty was mentioned in other parts of the text and also included in Figure 1 and its figure text, but not mentioned in the penalization section for some reason. My failure to mention this in that section could explain this comment:\n\n 2 months later\n\n post by aelowsson on Sep 22, 2024\n\n aelowsson\n\n Protecting solo stakers when penalizing beacon proposers\nA concern mentioned in the post is that builders who do not wish to unseal their bids after placing them could collude with the beacon proposer to have it miss the slot, thereby avoiding the penalty. This can of course be resolved by penalizing beacon proposers for missed slots. However, one reason to hesitate with this approach is that it could harm solo stakers whose validators have gone offline. A staking service provider (SSP) can have employees on stand-by around the clock to quickly resolve any issues with their validators, but a home staker may be unable to resolve issues for several days. This quote from Nixo is a typical example of a situation where it is important to not penalize the solo staker heavily:\n\nI run validators in two locations, at friends’ houses & pay both for upgraded internet\nOne turns off my validator’s internet access for an hr/day for an important meeting\nI just found out the other intentionally closed ports I need open cuz it was interfering with his streaming\n\nA solution to this problem, directly applicable to the single-slot auction (but which can also be adapted to the two-slot auction), is to let the beacon proposer’s commit structure released at T_2𝑇2 function as a proof of readiness (\\text{PoR}PoR). Only beacon proposers who have issued a \\text{PoR}PoR will receive a larger penalty if they fail to propose the block (at T_6𝑇6).\nThis significantly reduces the disparity between SSPs and solo stakers and decreases the frequency with which penalties need to be applied overall. The main concern with SEA outlined in the post is thus resolved.\nThere is an ongoing discussion of moving forward with a proposer penalty for missed proposals for other purposes as well, unrelated to the SEA. A \\text{PoR}PoR could then potentially prove useful. There are however pitfalls with a general \\text{PoR}PoR, and the design space is rather large.\n\n Powered by Discourse","tokens":1170,"squid":"spider-04","role":"Research Spider","at":1791347640082,"hash":"fe916a870278e0cb9e81bb0fc7f5390d3ae61af8"}
{"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":"spider-05","role":"Spec Spider","at":1791347642780,"hash":"c9648f4c29f0c1c6819fe9c70b3f181ba44854ff"}
{"url":"https://docs.jup.ag/user-docs/trade/gacha/marketplace","domain":"docs.jup.ag","title":"Marketplace - Jupiter Documentation","text":"The marketplace is where Jupiter Gacha users buy and sell graded, tokenized cards with each other. Every listing is a vaulted physical card represented by its Solana token, with its grading and vault details visible on the card page. The marketplace is operated by Collector Crypt and carries Collector Crypt cards: cards pulled from Phygitals packs (Sport and Pokemon Trainer) cannot be listed on it. See Providers.\n​Browsing and filtering\nListings show the card image, name, asking price, and grade. You can search by name or address, and filter by:\n\nPokemon name and set\nStatus\nInsured value range\nListed price range\nGrading company (for example PSA or CGC)\nGeneric grade\nLanguage\nYear\n\nSorting options include list date, list price, insured value, name, and year.\n​Buying a card\nYou buy a card with Buy now, which purchases it immediately at the seller’s asking price, paid in USDC. Making an offer at a different price is planned but not yet available.\nThe asking price is set freely by the seller. It is independent from the card’s insured value, which is a buyback reference, not a market price. Compare both figures on the card page before buying.\nAfter a purchase, the card appears in your Collection. If the page still shows a stale state right after buying, refresh: display can lag a few moments behind the on-chain state.\n​Selling a card\n1Open the cardGo to your Collection and open the card you want to sell.2List itChoose the sell action and set your asking price in USDC.If your asking price is more than 30% below the card’s fair market value, the app warns you before the listing is confirmed.3Manage the listingWhile listed, the card shows a Manage listing state where you can change the price or delist. The card remains yours until it sells.4Receive USDCWhen a buyer purchases the card, you receive the sale price minus the 2% sell fee.\n​The sell fee\nSelling on the marketplace carries a fee of 2% of the sale price, charged by Collector Crypt. Jupiter charges no additional marketplace fee.\nWorked example. You list a card at 100 USDC and a buyer purchases it with Buy now. You receive 98 USDC: the 100 USDC sale price minus the 2 USDC fee.\nBuying carries no marketplace fee: the buyer pays the asking price plus Solana network fees.\n​Marketplace, buyback, or shipping?\nThe marketplace is one of three ways to realize the value of a card, each with different trade-offs:\nOptionPriceAvailabilityInstant buyback85% to 93% of insured value, guaranteed3 days after the pullMarketplaceAny price a buyer will pay, minus 2%AnytimeShip homeNot a sale: you receive the physical cardAnytime","tokens":651,"squid":"spider-02","role":"Liquidity Spider","at":1791347662020,"hash":"3aeae9550eae14aa5611cd19f42f38a8e0d44f17"}
{"url":"https://docs.jup.ag/user-docs/trade/gacha/opening-packs","domain":"docs.jup.ag","title":"Opening Packs - Jupiter Documentation","text":"Packs are the entry point of Jupiter Gacha. Each pack tier draws from its own pool of collectibles, called the machine pool, with fixed odds per rarity tier. Most pools contain graded trading cards; watch pack pools mix luxury watches with graded cards, and the Sport Practice and Pokemon Trainer packs mix graded slabs with ungraded cards. Packs come from one of two providers, Collector Crypt or Phygitals, and a few rules differ between them, called out below.\n​Prerequisites\nTo open a pack you need:\n\nA connected Solana wallet\nEnough USDC to cover the pack price\nA small amount of SOL for Solana network fees\n\nThere is no platform fee on pack openings. You pay the pack price plus network fees. Phygitals packs are also subject to Phygitals’ geographic restrictions.\nIf your wallet does not hold enough USDC for the selected quantity of packs, the app offers to swap the missing amount from the token with the highest balance in your wallet, provided that balance is worth slightly more than the shortfall (about a 5% buffer). Without any balance to cover it, the Open pack button shows “Insufficient USDC”. Opening also fails without SOL for network fees. See the FAQ for troubleshooting.\n​Pack tiers\nPack prices are displayed live in the app, and the lineup evolves over time: packs can be added or retired. Current tiers:\n Pokemon One Piece Watches Sport Riftbound Dragon BallPackPrice (USDC)ProviderNotesTrainer10PhygitalsContains ungraded cards alongside graded slabsSilver25Collector CryptGold50Collector CryptDegen100Collector CryptJupiter exclusive, labelled “High Voltage” in the app. High volatility: the pool carries chase cards valued around $10,000, with a correspondingly higher risk of low-value pullsDiamond250Collector CryptBlaze420Collector CryptJupiter exclusive. Fire-type Pokemon onlyGrail1,000Collector CryptGod2,500Collector CryptImmortal5,000Collector CryptHighest tierPackPrice (USDC)ProviderNotesStraw Hat50Collector CryptEmperor250Collector CryptGorosei1,000Collector CryptThrone2,500PhygitalsHighest One Piece tier. Supplied by Phygitals, so it follows the Phygitals rules below rather than the Collector Crypt onesPackPrice (USDC)ProviderNotesChrono250Collector CryptMaster500Collector CryptTimepiece500Collector CryptWatches only, no cards in the poolThe Chrono and Master pools mix luxury watches (Rolex models among the chase pulls) with graded Pokemon cards; the Timepiece pool holds watches only. Watches are authenticated by WristCheck; the odds, Turbo mode, and instant buyback work exactly as on card packs.PackPrice (USDC)ProviderNotesPractice5PhygitalsBasketball, baseball, football, and soccer cards. Contains ungraded cards alongside graded slabsAll-Star100PhygitalsBasketball, baseball, football, and soccer cardsHall of Fame1,000PhygitalsBasketball, baseball, football, and soccer cards. Graded slabsSport packs are supplied by Phygitals: no Turbo mode, a 7-day buyback window, and no shipping or marketplace listing from Jupiter Gacha (both go through Phygitals or external marketplaces). See Providers.PackPrice (USDC)ProviderNotesCalm25PhygitalsRiftbound trading cardsChaos100PhygitalsRiftbound trading cardsBoth Riftbound packs are supplied by Phygitals, so they follow the Phygitals rules: no Turbo mode, a 7-day buyback window, and no shipping or marketplace listing from Jupiter Gacha. See Providers.PackPrice (USDC)ProviderNotesZenith50Collector CryptStorm100Collector CryptApex250Collector CryptHighest Dragon Ball tierDragon Ball is the newest category on Jupiter Gacha, launched in October 2026. The pools hold graded Dragon Ball trading cards (PSA, CGC, Beckett, and TAG slabs). All three packs are supplied by Collector Crypt, so Turbo mode, the 3-day buyback window, and shipping from Jupiter Gacha apply as on the Pokemon packs.\nNewly launched packs carry a New marker in the pack navigation for their first three days.\nWhen a pack is retired, as the Pokemon Water pack has been, it disappears from the packs page but stays visible and openable for users who still hold free copies of it.\nEach pack page shows two views:\n\nWhat’s Inside? lists the actual items currently in that pack’s machine pool, with their grading and value. A “Guaranteed Authenticity” badge confirms every item in the pool is authenticated: graded cards as slabs (PSA, CGC, Beckett, BGS), watches by WristCheck, ungraded cards by the provider’s vault partners. If a provider publishes only its highlight cards rather than the whole pool, the view says so below the list.\nLatest Pulls is a feed of recent pulls from that pack across the platform, with the value of each pull and its gain percentage relative to the pack price.\n\n​How to open a pack\n1Choose a packGo to the Packs page. Packs are organised by theme tabs (Spotlight, All packs, Pokémon, Watches, One Piece, Sport, Riftbound, Dragon Ball) with curated highlights, and each theme presents its packs as a carousel: drag to spin and tap a pack to select it. Review the Statistics & odds panel and the What’s Inside view before buying.2Set the quantityChoose how many packs to open in one session. If you own free or gifted packs for this tier, they are consumed first, before any USDC is spent.3Confirm the transactionClick Open pack and approve the transaction in your wallet. The total is the pack price multiplied by the quantity, plus network fees. If a USDC top-up swap is needed, the swap and the pack spend are disclosed together before you approve. Opening several packs at once is also a single approval, even when the purchase is split into several transactions. Sell & rip again is the exception: it asks for two approvals, the sale first, then the next pack once the proceeds have landed in your wallet.4Reveal your pullThe pack rips open and your pull is revealed with effects matching its rarity. The sequence plays inside the pack box by default, with a toggle to send it full screen; on phones it plays full screen by default. Tap the revealed card to turn it over and see its back. When you open several packs at once, they rip one after the other, or all at once.On a Collector Crypt pack, the draw runs through Collector Crypt’s on-chain verifiable randomness program and the card is yours as soon as the transaction confirms. On a Phygitals pack, Phygitals settles the opening on its side after you approve, so the reveal can take a few seconds.The card is added to your Collection and its instant buyback window starts: 3 days on a Collector Crypt pack, 7 days on a Phygitals pack. From the reveal you can sell the pull back at the buyback rate, use Sell & rip again to sell it and open another pack of the same tier (two wallet approvals: the sale, then the purchase), or keep it and rip another.\nIf a card you just pulled does not appear in your Collection immediately, refresh the page. Display can lag a few moments behind the on-chain state.\n​Odds and rarity tiers\nEvery pack displays its own drop odds by rarity tier in the Statistics & odds panel, together with indicative value ranges per tier. Odds differ from pack to pack. Value ranges depend on the current machine pool and change over time.\nCollector Crypt packs use four tiers: Common, Uncommon, Rare, and Epic. Phygitals packs use tiers set per pack by Phygitals, always topped by a Mythic tier, and can use as few as two tiers on a given pack. The panel always shows the tiers that apply to the pack you are looking at.\nTwo properties of the odds are guaranteed:\n\nOdds are fixed. The displayed percentages never change, regardless of how many cards remain in the machine pool.\nOdds are per rarity tier, not per card. Which specific card you receive within a tier depends on the current pool contents.\n\nRead the odds panel before opening. On most packs, the majority of pulls fall in the lowest rarity tier, with values below the pack price. The instant buyback guarantees a floor on every pull, not a profit.\n​Expected value\nEach pack displays an expected value: the average pull value calculated from the current contents of the machine pool. The expected value is dynamic. It is recalculated as cards leave the pool (pulled by users) and re-enter it (sold back through the buyback). Do not treat the expected value as a prediction of any single pull.\n​The machine pool\nEach pack tier draws from a dedicated pool of physical cards. The pool evolves over time:\n\nCards leave the pool when they are pulled.\nCards return to the pool when users sell them back through the instant buyback.\nThe provider restocks and curates the pool.\n\nWhen a pool runs low, the two providers react differently:\n\nCollector Crypt packs. If a machine runs too low on common cards, Turbo mode becomes mandatory on that machine until it is restocked. If it runs too low on higher rarity cards, the machine is disabled until it is restocked.\nPhygitals packs. A pack out of stock shows as Sold out until Phygitals restocks it. Pick another pack in the meantime.\n\nThe displayed odds remain unchanged in every case.\n​Turbo mode\nTurbo is available on Collector Crypt packs only. Phygitals packs have no Turbo toggle.\nTurbo is a toggle on each Collector Crypt pack that automatically sells any Common pull back for USDC at the machine’s buyback rate, immediately at reveal. You keep only Uncommon or better pulls, and receive USDC for the rest. Turbo is useful for opening many packs in a row when you only want to keep higher rarity cards.\nCheck the Turbo toggle before every opening. While it is on, every Common pull is sold back automatically at the machine’s buyback rate the moment it is revealed, and sold cards cannot be recovered.\nWhen you enable Turbo yourself, the app shows a confirmation notice once, explaining that common pulls will be sold automatically. When Turbo is mandatory because the machine is low on commons, the notice is shown on every opening, so you are always aware that a Common pull will be auto-sold.\n​Free packs and gifted packs\nFree packs earned through rewards and packs received as gifts appear directly on the corresponding pack page. A gifted pack shows an “Open gifted” action in place of the purchase button. Free and gifted packs are always consumed before USDC when you open multiple packs. Gifting is available on Collector Crypt packs only.","tokens":2558,"squid":"spider-02","role":"Liquidity Spider","at":1791347676310,"hash":"2c3228263659ea3430313a2de8cae2319a8c7d40"}
{"url":"https://ethresear.ch/t/dr-changestuff-or-how-i-learned-to-stop-worrying-and-love-mev-burn/17384/3","domain":"ethresear.ch","title":"Dr. changestuff or: how i learned to stop worrying and love mev-burn - Proof-of-Stake - Ethereum Research","text":"Proof-of-Stake\n\n mev,proposer-builder-separation\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 2\n\n read \n\n 17\n min\n\n Nov 2023\n\n 3 / 18\n\n Nov 2023\n\n Jun 2024\n\n post by mikeneuder on Nov 10, 2023\n\n mikeneuder\n\n dr. changestuff or: how i learned to stop worrying and love mev-burn\nupload_39c555a766cf8bbfbc67f0e26bad0aad1788×2636 205 KB\n^^^ any Kubrick fans?!?\n\\cdot⋅\nby mike, toni, & justin\nfriday – november 10, 2023\n\\cdot⋅\ntl;dr; mev-burn is misunderstood. While critics poke fun at ultra sound money and craft vignettes about Vitalik, Hayden, and Justin, the benefits of mev-burn extend far beyond the meme. We present four protocol benefits of mev-burn: (1) improving validator economics, (2) lessening the ePBS builder liquidity requirements, (3) increasing the cost of censorship, and (4) improving the protocol resilience under exposure to a “mass MEV” event. Additionally, we address two of the biggest misconceptions about mev-burn: (1) proposer-builder collusion, and (2) late-in-slot MEV.\n\\cdot⋅\nRelated work\n\nArticle\nDescription\n\nMEV burn – a simple design\nJustin’s design\n\nIn a post MEV-Burn world - Some simulations and stats\nToni’s analysis\n\nRelays in a post-ePBS world\nHigh-level ePBS discussion\n\nAcronyms\n\nsource\nexpansion\n\nePBS\nenshrined proposer-builder separation\n\nToB\ntop of block\n\nEL\nexecution layer\n\nCL\nconsensus layer\n\n\\cdot⋅\n\nmike’s editorial note: Justin’s post uses the “MEV burn” (all caps) notation. I find the capitalized letters ~unaesthetic~ and more likely to be read as “EM-EE-VEE” (three syllables) instead of “mĕv”/“m(eh)v” (one syllable). I suggest we adopt the “mev-burn” notation for ease of reading and speaking. Justin hates the hyphen and suggested the following alternatives (i) mevburn, (ii) mev burn, (iii) mèvburn, & (iv) mev’burn, all of which are ngmi in my opinion. Please DM me your preference – ymmv. (and yes … we did indeed spend more time debating this than any other part of the article)\n\nmev-burn summary\nTo set the stage, we present a high-level description of the mechanism; for the latest on the mev-burn design, see Justin’s “MEV burn – a simple design”. The figure below encapsulates the key elements.\nupload_84eeb52e6c596bea3fec4601554a646e2718×1318 237 KB\nWe assume an ePBS instantiation, which is a prerequisite for mev-burn.\n\nBefore the slot starts, the bids are circulated in the “bidding” phase.\nA builder bid is composed of (1) the base fee (the amount of ETH that a block will burn) and (2) a tip (the amount of ETH paid to the proposer).\nD𝐷 seconds before the beginning of the slot (we usually use D=2𝐷 =2), the attesting committee locally sets a “base fee floor” according to the bid with the highest base fee that they have observed.\nAt the beginning of the slot, the proposer selects and signs a bid, publishing it to the network.\nWhen the attestation deadline arrives, the attesting committee votes for the proposer block if (1) it arrives on time, and (2) the base fee of the bid exceeds their local floor.\nAs the attestations for the proposer’s block arrive, the builder gains confidence that their bid is the unique winner of the auction, and they publish the payload (the actual list of transactions in the block).\nThe payload receives attestations if it was revealed on time and accurately honors the base fee by burning an appropriate amount of ETH.\n\nBenefits beyond “ultra sound money”\nGwart, 0xBalloonLover, BeckyFromHR, and other “orthogonal thinkers” poke fun at the meme of “burning more ETH”. Though funny, these jokes miss the reality that the benefits from mev-burn extend far beyond making ETH “more” ultra sound (hyper-ultra sound?!?). mev-burn improves validator economics, lessens the builder liquidity requirements in ePBS, increases the cost of censorship, and improves the protocol resilience under exposure to a “mass MEV” event. Let’s go through each of these individually.\nValidator economics\nThe amount of ETH staked is a key metric in the consensus layer. Currently, this has stabilized around 23\\%23% of the ETH supply. In return for their participation, validators are compensated with rewards from the consensus layer (abbr. CL rewards) and through the transaction fees and MEV extracted during their slot (abbr. EL rewards). In low volatility periods, the EL rewards may constitute a relatively minor fraction of the overall allocation. The figure below shows that EL rewards account for about 25\\%25% of the total validator rewards over the past few months.\nupload_41480e3479e040c7c67ce2f3d8386b72965×361 26.6 KB\nWhen trading volumes and volatility increase, this proportion can change significantly; on March 11, 2023, when USDC traded at a discount, EL rewards accounted for 75\\%75% of validator rewards. During a bull market, we should expect EL rewards to remain significantly higher than today, incentivizing the deployment of more ETH into the consensus layer. By burning some of the EL rewards through mev-burn, we reduce the value and the variance of validator rewards. While it’s not clear exactly “how much” is the right amount of stake, 23\\%23% of the supply (\\approx 56≈56 billion USD at today’s price) feels like plenty, and entering a situation where massive staking demand leads to sharp growth in the validator set is an undesirable outcome. If the protocol “overpays for security” with unnecessary issuance, the amount of ETH staked exceeds what is deemed necessary. The figure below shows the distribution of rewards before and after mev-burn.\ndiagram-20231110 (1)954×685 73.4 KB\ntl;dr; mev-burn reduces validator rewards without changing the protocol issuance.\nBuilder liquidity requirements\n“Relays in a post-ePBS world” distills an ePBS mechanism into,\n\na commit-reveal scheme to protect the builder from the proposer, and\na payment enforcement mechanism to protect the proposer from the builder.\n\nAnother way to think about (2) is that each bid must be accompanied by some “builder liquidity” to guarantee that the proposer is paid even if the builder doesn’t produce a valid block. The figure below shows three different cases for builder liquidity in ePBS.\nupload_8224121556fb46cd37630323ca6d65151065×492 71.2 KB\n\nuncapped w/o mev-burn – In the vanilla ePBS design without mev-burn, the entire value of a block bid goes to the validator. Accordingly, the builder’s liquidity must match the size of the bid to avoid a griefing attack on the proposer. A builder who promises to pay 100 ETH for a block must be able to make that payment at the top of the block (ToB). It doesn’t make sense to cap the bid value of a block, because that encourages side-channel payments from the builder to the proposer.\nuncapped w /mev-burn – With mev-burn, part of the bid is burned and the remainder is used to tip the proposer. Here, if we don’t cap the builder liquidity, it accounts for the entire bid value. A builder who promises to burn 80 ETH and tip 20 ETH must be able to make that full 100 ETH payment at the top of the block (ToB).\ncapped w /mev-burn – With mev-burn, we can take advantage of the fact that only the tip needs to be fully collateralized. By capping the liquidity of the burn, we can reduce the capital requirements of running a builder that competes for large blocks. A builder who promises to burn 80 ETH and tip 20 ETH must be able to fully collateralize the 20 ETH tip at the ToB, but can be bonded for a capped amount in the burn liquidity (e.g., 32 ETH). If they fail to build a valid block that burns the full 80 ETH, then their 32 ETH is slashed and the remaining 48 ETH that was supposed to be burned is ignored (by not burning that ETH, the value is socialized across all ETH holders and/or likely burned during the next slot).\n\nWith mev-burn we should take advantage of case (3) above to limit the capital requirements of running a builder.\n\nAside: by capping the liquidity requirements, we also cap the amount that a builder would have to pay for an empty slot. Under extreme circumstances, builder A could execute the following strategy:\n\nbuilder A observes builder B is willing to burn 1000 ETH and tip 1 ETH for a given slot, implying the existence of a huge opportunity to capture some MEV.\nbuilder A makes a bid of 1000 ETH burned and a 1.1 ETH tip and wins the slot with no plans of actually making a block.\nbuilder A is slashed 32 ETH for missing the slot, but bought 12 seconds to find the opportunity that builder B is bidding based on.\n\nEssentially, the price of a missed slot becomes 32 ETH. While this strategy is feasible, it seems likely that this wouldn’t occur frequently enough to pose a significant risk to the liveness of the chain. Even if it does occur, builder A would still need to compete with builder B for the MEV in the subsequent slot. Additionally, raising the cap of builder liquidity further increases the cost of a missed slot.\n\ntl;dr; mev-burn lowers capital requirements for builders in ePBS.\nCost of censorship\nOne feature of PBS with EIP-1559 is the reduced cost of censoring a transaction. SMG pointed this out by censoring a block in June 2023, but Vitalik discussed this in the beginning of 2022 (many such cases lol). The key takeaway point:\n\n“Note that in both cases, the attacker loses P per slot for censoring”,\n\nwhere P𝑃 is the priority fee of the victim transaction. Thus blocks built in a PBS regime have worse censorship resistance than in a self-building regime (see censorship.pics). mev-burn can help alleviate this. If we include ETH burned through the base fee of EIP-1559 transactions in the overall burn associated with a block bid, then the cost of censorship is the full fee that the victim transaction pays. The figure below captures this.\nupload_7081c6c7604f60670dcb5948ca594b131005×656 63.1 KB\nOn the left, the uncensored block includes transactions a, b, & c, which together burn a total of 0.6 ETH. The builder bids an additional 1 ETH for a total of 1.6. On the right, the builder is censoring txn c, which burns 0.2 ETH. To burn the same amount as the uncensored block, the builder needs to subsidize that burn through their bid of 1.2 ETH. Now the cost of censorship is no longer just the priority fee of the censored transaction, but also includes the base fee. If a builder attempts to censor many transactions, the margin of their burn floor compared to non-censoring builders is reduced, making it harder for them to compete in the auction.\ntl;dr; mev-burn increases the cost of censorship by including the base fee of the victim transaction.\nResilience in the presence of mass MEV events\nWe should expect that DeFi, bridge, or rollup hacks may lead to mass MEV events (on the order of hundreds of millions of dollars) – we have seen it before (e.g., the nomad hack during which hundreds of copy-cat transactions continued to exploit the bridge for several hours). mev-burn improves the protocol’s ability to withstand such turbulence in several ways, all of which derive from the fact that in a mass MEV event, most of the ETH will be burned instead of paid to the proposer of the slot.\n\nmev-burn reduces the incentive for a “rugpool”. With large node operators running significant portions of the validators in Ethereum, there is a risk that the node operators steal MEV if the value exceeds their reputational and legal cost from doing so.\nmev-burn reduces the incentive to reorg for profit. Some staking pools might have logic built into their consensus clients to reorg for profit during a mass MEV event. This affects Ethereum’s short-term consensus security.\nmev-burn reduces the incentive to DoS attack. Beyond trying to reorg the chain, network-level DoS attacks might also be feasible and profitable during a mass MEV event.\n\nWe should expect chaotic amounts of activity during these periods, so improving the stability of the protocol in the face of such disruption is a huge benefit.\ntl;dr; mev-burn decreases the scale of a mass MEV event, improving the protocol resilience.\nCommon misconceptions\nYou might now be thinking, “OK OK, we get it. mev-burn has some nice features, but what about all the problems it causes.” Well, dear reader, we think some of these problems you mention are misconceptions. In particular, the two most common critiques of mev-burn are\n\n“If we burn validator rewards, won’t they collude with the builders to avoid the burn and kickback some of the rewards to the builder?”\n“With the two-second delay between when the attesters set their bid floor and the end of the slot, mev-burn will miss out on all the late-in-slot bids. Isn’t most of the CEX-DEX arbitrage value captured during that period?”\n\nGreat questions, let’s think through each.\nProposer-Builder Collusion (PBC?!)\nThe idea here is simple. Without mev-burn, a builder bid of 1 ETH is paid in full to the proposer; with mev-burn, the same bid may burn 0.9 ETH and tip the proposer 0.1 ETH. A rational proposer will want to minimize the burn to maximize their rewards, thus having an incentive to try to get builders to side-channel bids to them to avoid the burn mechanism. Notice that the builder is paying the full 1 ETH either way (i.e., burning vs. paying looks the same from the builder’s perspective), so they only care about interacting with the proposer if the proposer rebates them some of the bid. Consider the game with 3 players: proposer, builder A, & builder B. Let’s play out a few situations.\nWithout mev-burn\n\nbuilder A bids 0.9 ETH.\nbuilder B bids 1 ETH.\nproposer selects builder B’s bid.\nbuilder B pays the 1 ETH.\n\nThis is our base case.\nWith mev-burn and no collusion\n\nbuilder A bids 0.9 ETH with 0.8 ETH burned and a 0.1 ETH tip.\nbuilder B bids 1 ETH with 0.8 ETH burned and a 0.2 ETH tip.\nproposer selects builder B’s bid.\nbuilder B pays 0.2 ETH to the proposer and burns 0.8 ETH.\n\nWith no collusion, it’s all the same from the builders’ view, while the proposer only makes 0.2 ETH instead of the full 1 ETH.\nWith mev-burn and proposer <-> builder A collusion\n\nbuilder A bids 0.9 ETH with 0 ETH burned and a 0.9 ETH tip (the collusion has them set the burn to zero to get rebated by the proposer).\nbuilder B bids 1 ETH with 0.8 ETH burned and a 0.2 ETH tip.\nThe proposer is forced to select builder B’s bid, because it is the only one that the attesting committee will consider valid (it sets the floor to 0.8 ETH).\nbuilder B pays 0.2 ETH to the proposer and burns 0.8 ETH.\n\nWith proposer <-> builder A collusion, builder B sets the floor and thus nullifies the benefits.\nWith mev-burn and proposer <-> builder A, builder B collusion\n\nbuilder A bids 0.9 ETH with 0 ETH burned and a 0.9 ETH tip.\nbuilder B bids 1 ETH with 0 ETH burned and a 1 ETH tip.\nproposer happily selects builder B’s bid, because the burn floor is 0, and rebates builder B for colluding.\n\nWith proposer <-> builder A, builder B collusion, we finally have a benefit for all parties involved.\nThis doesn’t feel like a stable equilibrium for two reasons:\n\nEach builder is incentivized to defect to set the bid floor at the last moment and be the only valid bid. If the builder successfully gets the bid to the attesting committee right before the floor is set, their bid will be the only valid bid and thus the winner by default.\nTo combat the issue above, the builders would explicitly need to cooperate to ensure the floor never gets set above 0. With the builders directly colluding, there is no need to pay rent to the proposer in the first place (not to mention the higher coordination effort, latency costs, and legal risks incurred from expanding the collusion set). They could collude and avoid paying the proposer while sharing their revenues.\n\nThe key here is that (2) above is already possible today. Thus mev-burn doesn’t increase the probability of collusion (adding the validator to the colluding set strictly decreases the rewards of the builders).\nLate-in-slot MEV is not captured\nMany have pointed out that a significant portion of the MEV derived from the CEX-DEX arbitrageurs comes at the end of a slot. The reason for this is quite simple: as the end of the slot approaches, there is more certainty about the delta between the CEX vs. DEX price. Arbitrageurs can reflect this reduction in risk by bidding more aggressively without worrying about the price moving against them. Since the mev-burn design sets the bid floor att=10, any MEV that arrives after the cutoff time won’t be burned. This is the most compelling critique of mev-burn. The natural questions that follow are,\n\n“What percentage of the MEV do we think mev-burn will capture?”\n“What percentage is ‘enough’ to make this mechanism worth enshrining?”\n\n(1) we can try to estimate by looking at historical data. The figure below shows the 90\\%90% confidence interval of the bid value as a function of time in the slot under mev-boost.\nupload_5e9f2f4354bffe3c7b8b291a3ae90c34969×499 31.6 KB\nThis data represents the bid value (as a percentage of the winning bid value) across mev-boost relays during the previous 30 days (Oct. 8 - Nov. 8, 2023). The key value of t=-2𝑡 = −2 shows that the median slot would burn around 80\\%80% of the total bid, whereas the lowest 5\\%5% of slots would only burn around 25\\%25% of the total bid.\n(2) is more of a philosophical question. In a perfect world, we would burn exactly 10/12 = 83.\\overline{3}\\%10/12 =83.――3% of the MEV of the slot. The builders would stop bidding up the base fee at t=10𝑡 =10 because they know that most of the attesters will have fixed their view of the bid floor by then. Since the bid values scale super-linearly in time, we shouldn’t expect a perfect burn, but despite this, it still seems worthwhile considering the above benefits.\nWith the advent of OFAs, it is also possible that a large percentage of MEV-producing transactions move off-chain. If that is the case, then the CEX-DEX arbitrage would constitute a smaller portion of the overall MEV of a slot, diminishing the late-in-slot value.\nHow do we get there?\nBy now, you may be thinking, “OK I am sold, let’s do mev-burn”. Great, we are glad you think so . One incredible thing about mev-burn is it directly follows from ePBS. While ePBS has been a topic du jour, there are still many open questions. With the benefits of mev-burn, solving these questions and design considerations should be a high priority. Interestingly, mev-burn might be the most compelling reason to do ePBS after all!\nupload_77c5b4bbd2dba76ec3191b0034aecd65321×474 16.1 KB\ntyvm for reading <3\n\n ePBS Metagame: SSP peacekeeping and alternative public service\n\n The price is right: Realigning proposer-builder incentives with predictive MEV-burn\n\n Execution Tickets\n\n Execution Auctions as an Alternative to Execution Tickets\n\n Burn incentives in MEV pricing auctions\n\n 5\n\n 2\n\n 2\n\n 2\n\n read \n\n 17\n min\n\n post by Mister-Meeseeks on Nov 10, 2023\n\n Mister-Meeseeks\n\n Thanks for putting this together. Probably the best succinct summary of mev-burn so far.\nBut one thing that’s not clear to me, is what’s the incentive for the attesting committee to behave honestly? All of the collusion examples assume the attesting committee follows the rules. But besides social convention, I don’t see any disincentive for members of the committee to censor proposals.\nYes, you could say that the attestation committee is very large and diversified, so coordination around collusion is a challenge. But, the cost to misbehavior is zero unless I’m missing something. That would make it relatively easy for a coalition of “dissenter validators” to slowly build up its stake in public over time. It would be easy to imagine a liquidity mining incentive, where the dissenters emit tokens to incentivize joining the coalition, the value of which is the future value of redirected mev if/when the coalition starts regularly taking over majorities of attestation committees.\nA similar dynamic exists, that works at cross purposes to the original reason for PBS. Attestation committee censorship potentially increases returns super-linearly for parties as they control a higher percentage of stake. A small validator would never control the majority of an attestation committee. Whereas a major validator could control some percent of attestation committees, and therefore be able to harvest higher returns from mev capture. That would obviously lead to centralization forces on the validator set.\n\n post by jasalper on Nov 10, 2023\n\n jasalper\n\n I have comments on the benefits - but will leave those for another day to focus on the “common misconceptions”.\nThe two issues are actually the same, and they’re being brushed under the rug when they’re a much bigger issue than they’re made out to be.\nCollusion doesn’t have a cost and doesn’t require not bidding like the example shows. Collusion only requires not bidding before the payload observation deadline. If a builder defects to set the bid floor, the other builders can bid at that bid floor after the payload observation deadline. Bids are still accepted after the payload base fee snapshot so defecting doesn’t give you any benefits such as guaranteeing you’d win the block.\nThis results in collusion being a stable dominant strategy for builders – builders get no benefit by bidding early, but they lose ETH in the case where the validator is offering mev-burn refunds. You really only have 2-3 builders with the ability to build “full value” cex-dex blocks right now - and bidding late is minimal effort, any builder could implement it in an hour if that. It seems obvious to me that both builders will immediately start doing so, if not on their own, the second a validator makes the offer to refund some portion of the mev-burn.\nFinally, the historical estimation is no good. You can look at current graphs and say that the block value is bid 80% of the total bid by the deadline. But that’s because there’s a very weak incentive to bid late now (hiding your bids from competitors). This will only get worse as a real incentive to bid late appears (maximizing your validator refund). At best this should be looked at as a generous upper bound.\n\n Burn incentives in MEV pricing auctions\n\n Sealed execution auction\n\n MEV burn: Incentivizing earlier bidding in \"a simple design\"\n\n MEV resistant dynamic pricing auction of execution proposal rights\n\n The price is right: Realigning proposer-builder incentives with predictive MEV-burn\n\n post by terence on Nov 10, 2023\n\n terence\n\nIn the section discussing ‘Builder liquidity requirements,’ it appears that we assume the builder is also a validator and has staked Ether, leading to the possibility of 32 ETH being slashed. I believe the situation where the bid is capped with MEV burn can be considered a loophole. This is because a builder could potentially gain 48 ETH by deliberately getting slashed. Assuming the builder is staked, it would make sense to require the builder to maintain a balance sufficient to cover both the bid burn and tip amount; otherwise, the entire block should be deemed invalid. It’s worth noting that achieving consensus payment is more straightforward in this context compared to execution payment, especially concerning implementation and future compatibility with SSLE.\n\nSimilar to the previous comments, I share the same view that builders are not obligated to bid before the 10-second mark. Currently, builders do this for reasons that can change in the future. Even if builders were to alter their behavior to start bidding at 9 seconds, many aspects of their behavior would likely change as well. Additionally, it’s important to acknowledge that we assume this bid originates from a P2P source, which is not the most efficient form and may introduce delays. In ePBS, I assume that most builders will run their own relayer and provide an RPC endpoint for validators to query.\n\nRegarding the Attester committee incentive, I personally don’t believe it’s a significant issue that this role is not incentivized. I prefer keeping the protocol simple in this regard. The attributability of the Attester committee for a specific slot is clear, and any obvious collusion would be easy to detect.\n\nPotuz and I have been collaborating on the ePBS specification, and the latest design can be found here. Both of us have pull requests in our respective repositories. It wouldn’t be challenging to extend what we are working on to incorporate MEV burn. Please feel free to reach out with any questions: link\n\n post by Nero_eth on Nov 11, 2023\n\n Nero_eth\n\nCould you expand on this case?\nI like thinking of the cap as a fixed punishment for not contributing to the burn. The tip still goes to the proposers so nothing changes from the proposers’ perspective. Proposers are compensated the full EL rewards (the mev-burn tip). The compromise between socializing the costs of a missed burn vs. lowering the entry barriers for builder does make sense to me and choosing a large enough penalty should be enough to avoid builders bidding unrealisticly high to then not deliver.\nAs an example: The proposer sees one bid b𝑏 at second 10 in the slot that promises to burn 1000 ETH and tip 1 ETH. The proposer sees another bid b'𝑏′ at second 10 that burns 10 ETH and tips 2 ETH. As the proposer saw the 1000 burn bid in time, he can trust that the upcoming attestation committée will set their burn floor to 1000 ETH too. So the proposer will ignore b'𝑏′ and select b𝑏.\nIf the builder is not able to come up with 1001 ETH (because he only has 33 ETH (32 + 1), then the tip still goes to the proposer while 32 ETH are slashed.\nIn the end, the validator lost 1 ETH (as he could have chosen the honest bid b' 𝑏′ and receive 2 ETH instead of 1. On the other hand, the attack costed the builder 32 ETH and instead of burning 10 ETH, we burn/slash 32.\nRegarding 2, I agree with you and the comment from @jasalper, that one cannot naively assume that changing something in the rules wouldn’t impact the builder behavior. So, the actual burn, assuming having mev-burn implemented can only be roughly estimated as of now.\nAlso regarding the incentives to bid early, I agree that this is a valid point.\nAt the moment, we see some validators requesting a block header from the relay way too early when certain builders have not even started bidding. These validators would probably run into problems if they continue being early as their chosen block might then not be able to satisfy the burn.\n\n post by michaelsproul on Nov 11, 2023\n\n michaelsproul\n\nI think @terence is referring to the case where the malicious builder reveals a payload that does contain a 1000 ETH opportunity, but which they exploit for their own benefit (while paying the 32 ETH slashing penalty). My understanding of mev-burn’s solution to this is that any payload that doesn’t burn the amount bid is invalid, so this payload would not become part of the canonical chain. At least that’s what I infer from the wording:\n\nAnd in Justin’s post:\n\nIs that right?\n\n The price is right: Realigning proposer-builder incentives with predictive MEV-burn\n\n post by Nero_eth on Nov 12, 2023\n\n Nero_eth\n\n Oh I see. You’re right, yeah.\nIf the builder bids 1000 ETH as a tip and offers to burn 1 ETH, while the burn is actually at e.g. 2 ETH, then the builder’s payload (together with the 1000 ETH MEV extraction) wouldn’t make it to the canonical chain and the builder would loose it’s stake while getting nothing in return.\n\n post by terence on Nov 12, 2023\n\n terence\n\n Understood. The concept of ‘not making it to the canonical chain’ is akin to the ePBS design I’ve previously worked on. I’d be wary of adding a slashing condition to the specification and client design, as it’s not always straightforward. Ideally, avoiding slashing would be preferable. If the builder lacks sufficient base balance to cover the cost of the burn, we could just immediately fail the block\n\n post by tripoli on Nov 12, 2023\n\n tripoli\n\n Cool post.\nI think it makes sense to round out the data a bit by talking about the sources of execution layer rewards to understand how it could change if the incentive structure changes as well.\nOver the period, [October 8, November 8) MEV-Boost rewards were 21,674 eth. Priority fees accounted for 13,294 eth during the period, with 4,380 eth from public mempool transactions (characterized by Flashbots mempool dumpster), which leaves 8,914 eth from private mempools. Priority fees on sandwich transactions contributed 3,306 eth (37% of private mempool priority fees).\nAbout 93% of blocks used MEV-Boost, so about 7% of the public mempool transaction fees should have been captured by solo builders (306 eth).\nThis leaves us with about 8,074 eth in rewards that are unaccounted. My impression is that this is mostly from integrated builders, but I haven’t dived into the data. Considering that Wintermute and SCP send ~ $2 billion (1,000,000 eth) of volume to rsync and beaver per month, this seems more than possible to me. Is there anything I’m missing here?\n\nMEV-Burn should have 10/12 vision of public mempool fees and probably of sandwiches too (although hopefully sandwiches will decrease in time with better wallet ux). To capture most the rest of the private order-flow (65%) requires us to assume that builders do not change their habits and that the mechanisms involved have vision into non-public flow.\nConsidering how unaligned builders are today, this assumption seems a little naive to me.\nFurther, why do builders even bother submitting bids early right now? Only about 1 in 400 winning MEV-Boost blocks are received by any relay before the proposed 10-second cutoff. Since there’s almost no incentive for builders to bid early the dynamic is fragile, and as soon as there’s any disincentive to early bidding I imagine we’ll see change.\nslot-time-distribution2600×1300 128 KB\n\n post by CometShock on Nov 13, 2023\n\n CometShock\n\n Attester Questions and Incentives\nAs mentioned by @Mister-Meeseeks, I think we need more specific details regarding the attesters. Some of this might already be answered and I’m just missing the details from somewhere.\nAs we obviously know, block production is an infinite game. Attesters are validators, and thus rationally would like to maximize their rewards in both attesting and proposing (while minimizing slashing). Where possible, rational attesters would want to establish a minimal payload base fee precedent so this behavior is reciprocated during their turn in proposing. If possible, clawing back rewards from being burnt is a better financial outcome for validators. Because of this incentive (and some others to follow later in this response), I am curious about the following questions:\n\nIs there punishment for any attester misbehavior? Under what circumstances is it considered misbehavior, and what is the punishment?\nAre attesters required to broadcast their local base fee floor by some deadline?\nCan attesters broadcast their local base fee floor and then update it prior to some deadline?\nIs there some point in which attesters are absolutely committed to a base fee floor prior to their attestation, or is this just a soft definition that they can individually update prior to the proposal attestation?\n\nWithout these answers, it’s a little harder to wargame the nuanced incentives each party has. I’ll continue on with some of my other points, but many of them may be subject to how the above questions are answered.\nPotentially Overgenerous Assumptions\n\nInformation\nThis defection strategy is assuming the builder has more information than they would in reality:\n\nBuilders do not know with certainty the total extractable value each other bidder has while the auction is ongoing.\nDue to cross-domain MEV (ex: CEX-DEX arbs), builders do not know with certainty the total extractable value they themselves will have, but the certainty increases as time passes.\n\nWith the potential uncertainties above, a reasonably confident competitive builder should attempt to not defect, as they still have the opportunity to be the winner. What’s left are very unconfident builders, who almost by definition are likely to not have as much value to be captured.\nLatency\nThis defection strategy to win the auction also assumes some timing games are a certainty. For simplicity, assume latency𝑙𝑎𝑡𝑒𝑛𝑐𝑦 includes processing time for the endpoint.\n(D + excess\\_proposal\\_window) < (latency_{defection\\_to\\_competitor} + latency_{competitor\\_to\\_proposer})(𝐷 +𝑒𝑥𝑐𝑒𝑠𝑠_𝑝𝑟𝑜𝑝𝑜𝑠𝑎𝑙_𝑤𝑖𝑛𝑑𝑜𝑤) <(𝑙𝑎𝑡𝑒𝑛𝑐𝑦𝑑𝑒𝑓𝑒𝑐𝑡𝑖𝑜𝑛_𝑡𝑜_𝑐𝑜𝑚𝑝𝑒𝑡𝑖𝑡𝑜𝑟 +𝑙𝑎𝑡𝑒𝑛𝑐𝑦𝑐𝑜𝑚𝑝𝑒𝑡𝑖𝑡𝑜𝑟_𝑡𝑜_𝑝𝑟𝑜𝑝𝑜𝑠𝑒𝑟)\nsidenote: adjust the left side of the inequality depending upon how Attester Questions are answered.\nIf this latency assumption is violated, the non-defectors can still update their bids to include the expected base fee floor (as mentioned by @jasalper). Thus, the probability of winning selection is only minimally increased and the incentive to defect is minimized.\nSynthesis\nIf both the information and latency assumptions are violated, there exists a very large incentives gap between honest and rational builders. Honest builders will earn little to nothing (many of which may discontinue operations), and rational builders will continue to persist by their profitability.\nStructured Bids\nThere is a possibility that the latency assumption doesn’t need to be violated in order for a rational builder to minimize burn for the benefit of themselves and the proposer alike. Consider this example, under the assumption that bids are not required to be observed by attesters prior to proposal:\nAn independent relay is constructed, similar to what is shown in the graphic below from Relays in a post-ePBS world. As seen in the graphic, the bids from relays to proposer are not by default visible to outside parties such as attesters.\n\nBecause of mev-burn, builder B likely wants to keep their bids hidden from attesters unless the relay is unreliable, or they want to defect. In order to mitigate being usurped by a last-minute defection from other bidders, the relay announces that it will accept and relay structured bids. When the relay submits bids to the proposer, it just submits multiple bids to counter other defections only when necessary. Here’s roughly what a simplified structured bid could look like:\nimage608×142 17 KB\nEach builder’s actual block contents are functionally the same, with the exception of varied payments. Notice that the proposer is still incentivized to select the lowest payload base fee bid possible, and both proposer and builder stand to benefit. Of course, the marginal changes in rewards don’t have to be split 50/50. As seen in the following table, both proposer-favored and builder-favored environments can still result in bid structures that incentivize minimal payload base fee for the benefit of both parties.\nimage1289×220 38 KB\nThere are some additional configuration details for relays that would still need to be finalized, but this model appears possible to minimize payload base fee more than intended by design of mev-burn. Note that the relay only needs to anticipate what the attesters will require for the base fee floor – not necessarily what the highest payload base fee in a bid is. Note that this relay design is increasingly more useful the more centralized the builder set is. Today there are very few highly skilled builders, thus we can likely assume that they will be attracted to solutions such as this (or similar via vertically integrated builder/relay).\nHistoric Data Does Not Necessarily Apply to a New System\n\nAs also mentioned by @tripoli, the assumption that past data applies to this new proposed system seems highly flawed. You’re completely altering an incentive mechanism, therefore you should expect observant and rational agents to behave according to the new system – not the old one.\nAssuming honest attesters, mev-burn signals that it will attempt to burn the majority of value observed from all bids D𝐷 seconds prior to the beginning of the slot. Unless you as a builder are nearly certain that you will lose the auction before it has concluded (see Potentially Overgenerous Assumptions), there is no reason to defect before D𝐷. And even if you choose to defect before D𝐷, your defection bid’s success is still contingent on the Latency assumption. Obviously your defection bid does force additional burn, but we can likely assume that its direct value add to you is de minimis. The most convincing argument to defect (when you believe you will lose the auction) is forcing burn deprives your competition of future capital that they could use to improve themselves.\nThat’s a lot of conditions to rely on, and depending upon how the Attester Questions and Incentives section is addressed, may further layer on more conditions surrounding what the payload base fee floor looks like in reality.\n\n post by fradamt on Nov 14, 2023\n\n fradamt\n\nEven if your bid is the only one seen by attesters before the floor-setting deadline, that does not guarantee that it will win by default. All it does is force other builders to match it with later bids, which does not really benefit you. It’s not so clear then that you’d have an incentive to publish before the floor-setting deadline.\n\n post by aelowsson on Nov 14, 2023\n\n aelowsson\n\nThe local base fee floor is never broadcast and the base fee floor as such remains unknown during the entire process. Attesters only roughly imply the base fee floor by rejecting or accepting a block. You may find the discussion in the separate post on a proposed change to the mechanism useful.\n\n post by The-CTra1n on Nov 16, 2023\n\n The-CTra1n\n\n jasalper\n\n Nice analysis @mikeneuder . I echo these concerns though from @jasalper though. I’m also a bit confused about this comment:\n\nDoesn’t a required attester committee quorom make it ~impossible to reorg? In line with some of the other comments, I’d like to see more clarity on the attester roles.\n\n 29 days later\n\n post by mikeneuder on Dec 15, 2023\n\n mikeneuder\n\nthis is a super important question! I do agree with you that rationale attesters might behave differently. but rationale attesters could also try to reorg for profit, and we don’t see that happening presently. I generally feel that at some point we have to rely on the honest majority of the protocol to do things, otherwise it is just impossible to reason about it at all. but I for sure understand the perspective of taking an adversarial lens to the committees.\n\n post by mikeneuder on Dec 15, 2023\n\n mikeneuder\n\nRight. If the bid promised to burn 80 ETH and the resulting block doesn’t do so, it is invalid and the builder is slashed.\n\n post by mikeneuder on Dec 15, 2023\n\n mikeneuder\n\nI agree with you and @jasalper that assuming the market structure doesn’t evolve given a major protocol change is naïve! I think if we do go this route for mev-burn, we need to have a clear story for why the builders will bid before the cutoff.\n\n post by mikeneuder on Dec 15, 2023\n\n mikeneuder\n\n hey comet hope you are well buddy. thanks for the thoughtful comment – let me answer these questions directly.\n\nThe only punishment mechanism is still slashing conditions! So equivocations are the only thing that the protocol would have visibility into. Obviously the bigger meta question is what the social layer is willing to enforce. The examples Barnabé presents in Seeing like a protocol - by Barnabé Monnot are useful to consider, especially in light of recent timing games stuff.\n\nNope! that would add another round of communication and I am not sure who would even consume that data. Maybe the other attesters? Idk, doesn’t seem to fit IMO.\n\nThey don’t communicate it! it’s just a local view\n\nSame as above. They choose it locally. There is no enforcement.\nAgain the meta point here is what we expect protocol participants to do. If we decide we are fully giving up on the attesting committee, then most of the protocol assumptions fall apart. E.g., if attesters were fully rationale they would auction off bribery rights to the proposers around their slot to decide which block they vote on. It quickly becomes a slippery slope. I think figuring out what the fences are in the attesting committee behavior is going to be a really important excercise, and Barnabé started thinking about that in those examples he lists here: Seeing like a protocol - by Barnabé Monnot.\n\n 6 months later\n\n post by aelowsson on Jun 26, 2024\n\n aelowsson\n\nThis concern, which seemed to render uncompensated ePBS MEV pricing auctions (such as EA) ineffective, has now been resolved. The builders we know today indeed derive no benefit from bidding early. However, a new type of builder will emerge, the staker–builder. Staking service providers must ensure that competitors do not derive a higher yield than them under equilibrium, and will run builders that bid away competitive MEV in slots where they do not propose. Anticipated attester–builder integration warrants some caution.\n\n Powered by Discourse","tokens":10218,"squid":"spider-04","role":"Research Spider","at":1791347676424,"hash":"094c6fc44074f8ae37b5b088e31e0a5990433c90"}
{"url":"https://docs.jup.ag/user-docs/trade/gacha/verifiable-randomness","domain":"docs.jup.ag","title":"Verifiable Randomness - Jupiter Documentation","text":"Every pack draw in Jupiter Gacha is made by a procedure that neither Jupiter nor the provider can steer after the fact, and that you can check yourself. The procedure depends on the pack’s provider: Collector Crypt packs run through an on-chain verifiable randomness function (VRF) on Solana, and Phygitals packs run through a cryptographic commit-reveal scheme.\n​Why verifiable randomness matters\nIn a pack opening product, the operator could in principle manipulate which card a draw produces. A verifiable procedure removes that possibility:\n\nThe random value that decides your pull is fixed by a commitment made before the draw, not chosen by a private server at draw time.\nThe result comes with a cryptographic proof that the value was generated correctly and was not chosen or altered after the fact.\nAnyone with the proof can check it, without trusting Jupiter or the provider.\n\nCombined with the fixed, displayed odds per rarity tier, this means both the probabilities and the individual draws are auditable.\n​Collector Crypt packs: on-chain VRF\nDraws on Collector Crypt packs run through Collector Crypt’s verifiable randomness function, implemented as an on-chain program on Solana. The random value is generated by the program, the proof is recorded on Solana, and anyone can check it on-chain.\nEach of these openings has an associated on-chain transaction and randomness proof. To verify a draw, open Collection, go to the Activity tab, select one of your openings, and click Verify to see the randomness proof and the related on-chain details for that draw.\nFor technical details on the VRF implementation, refer to cc-vrf, Collector Crypt’s permissionless on-chain VRF for Solana implementing RFC 9381 ECVRF.\n​Phygitals packs: commit-reveal\nDraws on Phygitals packs run through Phygitals’ commit-reveal scheme, documented on its provable fairness page:\n\nCommit. Before the pack is opened, Phygitals’ server generates a secret seed and publishes its SHA-256 hash.\nReveal. When you open the pack, a client seed unique to you and the transaction is combined with the server seed by a publicly disclosed algorithm to determine which card you receive.\nVerify. Phygitals then discloses the server seed, so that anyone can hash it, compare the hash with the published commitment, and replay the algorithm to confirm the outcome.\n\nBecause the commitment is made before the client seed exists, neither side can steer the result. This procedure is cryptographic rather than on-chain: the proof is a hash and an algorithm, not a Solana transaction.\nJupiter Gacha does not display the seeds or the hash of a Phygitals draw, and there is no Verify action for these pulls in your Activity tab. Phygitals publishes the proofs of pack openings to the Phygitals account that made them. For a Phygitals pack opened on Jupiter Gacha, the fairness guarantee therefore rests on Phygitals’ published procedure rather than on a proof you can check yourself.\n​What the guarantees do not cover\nBoth procedures guarantee that each draw is random and tamper-proof within the displayed odds. They do not change the odds themselves: on most packs, the majority of pulls fall in the lowest rarity tier, as shown in each pack’s odds table. Provable fairness means the game is fair, not that it is profitable.","tokens":823,"squid":"spider-02","role":"Liquidity Spider","at":1791347686411,"hash":"d864ea56dbf87afd4a5f8af06aa2478cb370cb10"}
{"url":"https://ethresear.ch/t/burn-incentives-in-mev-pricing-auctions/19856","domain":"ethresear.ch","title":"Burn incentives in MEV pricing auctions - Proof-of-Stake / Economics - Ethereum Research","text":"Burn incentives in MEV pricing auctions \n\n Proof-of-StakeEconomics\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jun 2024\n\n 1 / 1\n\n Jun 2024\n\n Jun 2024\n\n post by aelowsson on Jun 18, 2024\n\n aelowsson\n\n Burn incentives in MEV pricing auctions\nThanks to Barnabé Monnot, Thomas Thiery and Caspar Schwarz-Schilling for feedback and comments.\nThe process of burning MEV1024×1024 373 KB\nIntroduction\nOverview\nThis post presents a rudimentary review of incentives for burning MEV under the “simple” MEV burn mechanism presented by Justin, as well as its slot auction counterpart, “execution auctions” presented by Barnabé. The analysis is also applicable to Francesco’s original MEV smoothing design. These auctions—involving builders bidding, attesters enforcing a base fee floor, and proposers selecting a winning bid—will be defined as MEV pricing auctions (in the author’s view, the “execution auction” moniker could also be extended to cover all MEV pricing auctions).\nThe post highlights how incentives to drive up the price floor (and thus burn more MEV) can emerge in these designs regardless of any direct profit motive among builders for doing so. Importantly, stakers and staking service providers wish to ensure that competitors do not attain more rewards for selling MEV capture rights than them. They may therefore integrate with builders to bid away competing stakers’ profits. Auctions that set a price floor on proposers’ MEV capture rights will thus be influenced by the overarching staking metagame. It is only at this layer that griefing attacks against proposers to burn their MEV capture rights can be understood. Adverse competition during the consensus formation process might hypothetically lead attesters to bias their MEV base fee floor during split views, rejecting or admitting blocks depending on how it impacts their bottom line (in their roles as both builders and stakers). This is something to be attentive to. Naturally, burning MEV might also be considered a public good, and such incentives are reviewed in the text as well.\nMEV pricing auctions\nIn MEV burn–a simple design, Justin formulated an add-on to enshrined proposer–builder separation (ePBS), modifying the MEV smoothing design. Builders can specify a base fee and a tip in their block bids. At some specific time before the slot begins (e.g., 2 seconds), attesters observe the highest base fee among the bids (“observation deadline”) and impose it as a subjective base fee floor when attesting to the proposer’s block. Only bids with a base fee above the floor are accepted, and the base fee is burned.\nIf builders bid before the observation deadline with the same timing as today, then the mechanism will burn substantial MEV. Concerns have however been raised over the risk of collusion between proposers and builders and lack of proper incentivization. A recent write-up on the benefits of the design and MEV burn in general generated similar worries of a stable equilibrium of late bidding.\nThe design can be further modified to involve auctioning off the rights to the entire slot, 32 slots in advance (“execution auction”). A benefit of this design is the ability to offer long-lived preconfirmations and—hypothetically—the reduced value-in-flight during the auction. The same concerns raised for the block auction design can be applied to the slot auction design, because the beacon proposer might still benefit from colluding with builders to form late-bidding cartels when selecting the execution proposer.\nA modified MEV pricing auction, MEV burn with builder kickbacks, attempts to compensate builders for bidding early. That design is not the focus of this post, but incentives and side effects in uncompensated MEV pricing auctions will affect its relevance.\nFive burn incentives in MEV pricing auctions\nThe outlined concerns of late bidding are valid, but it turns out that it is not possible to analyze MEV burn without incorporating stakers as participating agents. In such an analysis, competition for attaining the most yield will—under equilibrium—drive participants to burn each other’s MEV. Other incentives for burning MEV also exist. The analysis starts from the most idealistic public good example in (A) and gradually builds toward a metagame of active collusion to discourage other stakers in (E) (see Figure 1).\nFigure 11024×1024 377 KB\nFigure 1. Five types of builders potentially burning MEV in MEV pricing auctions: (A) Public good builder, (B) For-profit public good builder, (C) Extortion racket, (D) Staker-initiated griefing, (E) Staker-initiated griefing cartel. The incentives behind (D) are important to understand (indicated by an arrow).\n(A) Public good builder\nThe first example is a builder that dedicates resources to burning MEV without a direct profit motive. If Ethereum’s users believe that burning MEV is a public good, and in particular if no other incentive is sufficient, they may come together to fund the development and operation of a public good builder. Initiatives to fund public goods are fairly prevalent within the Ethereum ecosystem. The public good builder can for example consistently bid according to guaranteed MEV at the observation deadline in the block auction design. This ensures that the MEV is burned while the builder will not suffer any direct losses from the bid. In the slot auction design, the builder would instead need to bid according to its expected MEV for the entire slot and might bid slightly below to stay safe.\nThe public good builder will likely not be the best and will often be outbid in terms of tips from other builders in the proposer auction (taking place after the observation deadline), in which the proposer selects a winning bid. But the operation can still be very impactful. After all, priority fees are a significant portion of all value (in this post these fees are also treated as MEV), and some further “low-hanging MEV fruits” are potentially available without dedicating too large resources for extraction. While the builder may use any public goods funding received diligently and not strive for any profit, pursuing an idealistic path can still raise the originators’ public profile and provide significant economic benefits in the future (perhaps not even directly related to building blocks).\n(B) For-profit public good builder\nA builder that positions itself as providing a public good may also enjoy direct economic benefits from its operation if some validators sympathize with the mission. There may for example be a market fit for builders that do not censor, nor extract various types of toxic MEV. In the block auction design, the builder could keep the MEV base fee in line with the available (non-censorship/non-toxic) MEV during the attester auction, and then pivot to tipping afterward, retaining some small profit margin. The MEV in some blocks is not particularly geared towards specialized searchers, and stakers may not lose that much in tips for some blocks by selecting the public good builder. Therefore, the public good builder could have higher profit margins in the blocks it does eventually get to build than builders that have not positioned themselves as providing a public good. A builder bidding before the observation deadline might of course also hope that its bids are the only ones to reach the proposer in times of degraded network conditions.\n(C) Extortion racket\nGiven the lower effort required for extracting some of the MEV, it seems like (A) and (B) could have a natural position and high impact within the Ethereum ecosystem. But it may very well be that no successful public good builder can be sustained over the long run. After all, many stakers will not be particularly enthusiastic over a builder that burns their MEV opportunities.\nStill, consider the importance of a dedicated MEV-burning builder within the staking ecosystem. If the builder is operational, proposers will lose out on a lot of value relative to if it does not operate. Is there a business opportunity here? Perhaps a builder could commit to burning the maximum possible MEV but abstain from doing so if it receives a bribe from the proposer? It seems natural that proposers would be willing to pay for this, since the proposer stands to capture most value from the available MEV if none is burned. But the prospect of competition makes the business model perilous. If a sole extortive builder is profitable, then a few more may try to enter the market as well. There is not much use in paying off two builders if it turns out that a third burned the MEV anyway through a bid. A mechanism for reconciling this ex-post would become rather complex. The validator may then be better off by simply not negotiating with any extortion racket.\nWhile the extortion racket seems unsustainable, it helps to underscore the power that builders have over proposers. The ultimate incentive for burning MEV then emerges when changing the responsible actor from one unaffected by the staking equilibrium (extorting builder) to one that is not (other stakers). The auction will eventually become part of the metagame of the overarching staking equilibrium.\n(D) Metagame—staker-initiated griefing\nStaking service providers (SSPs) compete for delegated stake and derive income by taking a cut of the staking yield when they pass it back to the delegators. An SSP must ensure that the yield it offers delegating stakers is competitive relative to offers from other SSPs. The MEV pricing auction may therefore lead SSPs to burn competing proposers’ MEV by tightly integrating with builders or running them in-house. If a competitor burns an SSP’s MEV, then the SSP must respond in kind or will lose out on delegators and thus income. When considering the metalevel of SSPs, this equilibrium seems more stable than an equilibrium of late bidding leading to little or no MEV burn. All it takes to break the late-bidding cartel is one defecting SSP builder, forcing others to respond.\nAn SSP that through a builder griefs other stakers without taking any loss executes something comparable to a discouragement attack with an infinite griefing factor. This is a very advantageous attack, primarily because delegators will flow to the best performing SSP. In addition, a reduction in overall yield for other stakers pushes down the quantity of supplied stake, bringing up the equilibrium yield. Thus, even if some delegators do not flow to the SSP that burns its competitor’s MEV, the expected staking yield (that the SSP will share in the profit from) will still go up, if the competitor’s customers simply stop delegating. Of course, the cost of running the builder must be accounted for. But large SSPs can amortize that cost across a vast amount of yield-bearing validators.\nYet, directly profiting from the MEV is almost always better than burning it. When an SSP’s builder is able to extract more MEV in a competitor’s slot than any other builder, it will still be better off only bidding to a level that ensures it wins the auction. The SSP must thus make a probabilistic judgment as to the uniqueness of its MEV opportunity in the particular slot before deciding how to proceed (or more precisely, any edge in MEV value V_e𝑉𝑒 relative to the second best builder). An SSP builder must in essence bid before the observation deadline up to the point where the expected payoff from burning the marginal MEV is equal to the expected payoff from waiting and hoping to extract it. There are some game-theoretic nuances to this that here will be set aside, with some aspects discussed in the next section. The point is to assert that there are stronger incentives for builders to bid before the observation deadline than what has been previously understood, because a builder might be run by an SSP that indirectly profits from burning other stakers’ potential MEV revenue.\nWhat happens in the metagame to smaller SSPs and solo stakers? They may not afford to run a builder of their own to ensure that their competitors’ MEV is burned. It is of course possible for solo stakers to try to come together to form a union around a builder, where each contributor is guaranteed to see their validators excluded from MEV base fee bids by the specific builder (and receive full tips during the proposer auction). There is then a question of if they will be able to organize such a union, but also if it really would be necessary. On the one hand, if there are several “griefing builders” running concurrently among the largest SSPs, parties holding less stake may not need to run their own griefing builder. Everyone will see their MEV burned anyway, since the big SSPs burn each other’s and everyone else’s MEV. On the other hand, a party not having a griefing builder readily available may be suboptimally positioned when considering the prospect of cartelization.\n(E) Metagame—staker-initiated griefing cartel\nCan builders operating at the metalevel collude to selectively burn or selectively not burn MEV, depending on the identity of the slot’s validator? The cartel would strive to ensure that all participating SSPs (or any union of solo stakers) receive the MEV in their validators’ proposed blocks, while minimizing MEV in all other validators’ blocks.\nHowever, if attesters are honest, builders can only cartelize to selectively burn or not burn MEV that they uniquely are able to extract. As long as competing builders are operational, this substantially limits the power of any cartel. Therefore, the advantage of (E) over (D) is not substantial.\nProposer is part of the cartel\nWhen the beacon proposer is part of the cartel, members will abstain from bidding before the observation deadline to ensure that as much value as possible flows to the proposer. This type of cartelization has been highlighted as a concern (1, 2) in the debate around MEV pricing auctions. The idea is that participants come to an explicit or implicit agreement to not bid before the observation deadline. Yet the incentive to burn MEV is stronger than previously understood, since stakers outside the cartel will wish to grief cartel members by bidding early (D), and so from this perspective, the risk of late-bidding-cartelization is lower than feared.\nIt might also be difficult to efficiently uphold cartelization, because it is not possible for members to know which, if any, defected in pursuit of (D). One avenue would be to try to share the profits from every slot to give all participants incentives to hold back bids before the observation deadline. Yet overall, the existence of (A), (B), and (D) means that some value will still reasonably be burned by public good builders or any competitors not part of the cartel.\nProposer is not part of the cartel\nWhen the beacon proposer is outside the cartel, the goal is to deprive it of revenue while still capturing as much of the MEV as possible. It will still be more profitable for the cartel to extract any unique MEV opportunity rather than burn it. Define V_s𝑉𝑠 as the value a builder can attain in the slot auction and V_b𝑉𝑏 as its value for the block auction (from a block built at the observation deadline). When a builder can extract the most MEV, it has an edge V_e𝑉𝑒 over the second-best builder (kept constant for simplicity). Just as in (D), the cartel can bid up to V_b-V_e𝑉𝑏 −𝑉𝑒 or V_s-V_e𝑉𝑠 −𝑉𝑒, with the difference that V_e𝑉𝑒 expands if the cartel collectively gains a larger edge against the best builder outside of the cartel. This expansion is what the cartel tries to capitalize on, both when the proposer is part of the cartel (expanding V_e𝑉𝑒 to lower the burn) and when not (expanding V_e𝑉𝑒 to increase builder profits). A challenge—just as in (D)—is that the cartel might not be able to properly estimate V_e𝑉𝑒. After the observation deadline, the cartel attempts to extract as much value as possible, leaving the MEV either burned or in their hands.\nCollusion at other levels\nThe presentation so far has been somewhat simplistic. It bears mentioning that collusion need not happen at the level of the builders, but can for example happen at the level of searchers or any out-of-protocol relay that the cartel still finds beneficial to maintain before posting to the P2P layer. In all scenarios of successful cartelization, if some stakers (for example solo stakers) are unable to act collectively, they may end up at the short end of the discouragement dynamic.\nRisks associated with attester–builder integration\nThe analysis so far indicates that (D) may have a significant effect on its own but that it does not necessarily lead to the riskier cartelization in (E). But what might happen when we give SSPs tools for depriving each other of revenue? While SSPs will always compete, competition in MEV pricing auctions is on the verge of seeping into the consensus formation process. At the consensus level, all participants are expected to behave honestly and are rewarded for good behaviour. Through staker–builder integration in (D)-(E), SSPs will come to actively influence each other’s rewards, cooperating or griefing each other. A risk is that SSPs might navigate down perilous paths in this landscape.\nIt has been noted that MEV pricing auctions suffer from attesters potentially having split views of the MEV base fee floor. Biasing the outcome in a split view one way or the other might benefit one builder over another, result in a block being forked out to deprive the beacon proposer of all rewards, or allow the proposer to reap higher rewards when selling MEV capture rights. One concern is that SSPs might eventually try to profit by tuning their attestations of the MEV base fee floor to produce favorable outcomes. This can also be done as part of a cartel. The honest majority assumption need not be broken to derive profits, due to split views. It is only necessary to put a thumb on the scale, and a competitive consensus formation might make such behavior more likely.\nOf course, stakers who do not honestly attest to which bids they have observed at which specific time point subject themselves to risks of social slashing if malicious behavior can be uncovered. This is always a potential final resort under proof of stake. In essence, just as it is prudent to be cautious of MEV or excessive issuance as strata for cartelization, it also seems prudent to be cautious of MEV pricing auctions as a stratum for consensus adversity.\nBlock vs. slot auctions in terms of MEV pricing\nWill block auctions or slot auctions burn more MEV? Is one more centralizing than the other? These questions are not easy to answer, because it depends on which burn incentive that comes to dominate, the likelihood of cartelization under different designs, etc. This section will discuss some differences (previous writings on block vs. slot auctions provide a broader perspective).\nBlock vs. slot auctions concerning (D)\nAssume that (D) becomes an important incentive for burning MEV. Further, assume a competitive market without cartelization and perfect information about how much MEV each participant can extract. In the block auction design, the builder can bid V_b-V_e𝑉𝑏 −𝑉𝑒 for the block at the observation deadline to maximize burn while retaining opportunities to extract value. It then updates its block and bid through tips in the proposer auction up until the slot boundary. There is V_s-V_b𝑉𝑠 −𝑉𝑏 worth of value that the proposer hopes to attain through tips, and V_e𝑉𝑒 worth of value left for the builder (under these simplified conditions).\nIn the slot auction design, the builder can instead bid V_s-V_e𝑉𝑠 −𝑉𝑒 already at the observation deadline. It is just buying the rights to build the block, not committing to its content, and that value is an entire slot’s worth of MEV. Naturally, V_s𝑉𝑠 will here just be an estimate, and the risk that builders take on by bidding on an expected value instead of a tangible value might be worth some fraction of the total bid value. But incomplete information around competitors’ eventual final bids will likely serve to pull down the bid value at the observation deadline more. The staker–builder can ideally burn V_s-V_e𝑉𝑠 −𝑉𝑒 of a competing beacon proposer’s auctionable MEV, and again retain V_e𝑉𝑒 for itself. The difference in MEV burn between the two designs is then V_s-V_b𝑉𝑠 −𝑉𝑏.\nIf the staker–builder could estimate V_s𝑉𝑠 also in the block auction design (which nominally is easier since it bids much closer to the deadline), it could bid V_s-V_e-V_g𝑉𝑠 −𝑉𝑒 −𝑉𝑔 already at the observation deadline. Since the bid is attached to a block containing only V_b𝑉𝑏 of MEV, V_g𝑉𝑔 is reserved as a tip for the proposer auction. If there is no tip, the proposer might elect to pick the block from the observation deadline, depriving the builder of V_s-V_b𝑉𝑠 −𝑉𝑏. However, while the proposer might specifically wish to do so if the same builder bids with low tips also in the proposer auction, a staker can obfuscate its identity by running several builders (the kickback design disincentivizes obfuscation).\nIn either design, it seems most likely that the burn ends up being lower than these theoretical maxima due to incomplete information in combination with the fact that capturing the MEV is more valuable than burning it. The staker–builder will therefore operate with quite some margin to maximize expected profits.\nBlock vs. slot auctions concerning (A)-(B)\nThe analysis for (D) is to some extent also applicable for (A) and (B). The public good builder could theoretically bid higher in the slot auction than in the block auction. However, the risk associated with overbidding in the slot auction design might be more serious for these builders. In the block auction design, the available value will be much clearer, making it easier for an unsophisticated builder to make low-risk bids.\nValue of preconfirmations\nAs previously mentioned, the slot auction design facilitates execution layer preconfirmations, which can provide a welfare gain to Ethereum. In addition, their value can be burnt (just as in execution tickets), since builders are bidding to attain that value. This increases the burn of the slot auction design.\nBuilder centralization under competition over expected MEV\nIf builders have different strengths and weaknesses, they will intermittently attain the highest V_b𝑉𝑏 in the block auction design. While one builder might be able to extract the highest MEV in expectation, not all blocks will play to its strengths. However, in the slot auction, builders bid on expected MEV, and one specific builder might then always have the highest expected V_s𝑉𝑠. This could potentially be a centralizing force, depending on how secondary markets evolve.\nConclusion\nThere are strong incentives for burning MEV even in designs that do not directly compensate for it, for example to provide a public good service or to ensure that other participants in the staking metagame do not attain a higher yield. Uncompensated MEV pricing auctions accommodates these incentives. Of particular relevance is staker-initiated griefing (D). It seems clear that SSPs will seek to influence builders’ bidding strategies, and this can lead to staker–builder integration. Still, this form of integration does not necessarily lead to censorship or higher MEV profits; thus not negating sought benefits of proposer–builder separation. If it is desirable to give an outside party an independent incentive to burn MEV, then builder kickbacks are an option. They can also be applied to the slot auction design.\nWhen implementing a MEV burn mechanism, it is important to ensure that the burn mechanism does not accidentally set fire to Ethereum’s consensus mechanism. Giving SSPs tools for griefing each other could lead to adverse competition during the consensus formation process. A particular concern is then if emerging attester–builder integration leads attesters to bias their MEV base fee floor, rejecting or admitting blocks depending on how it impacts their bottom line (in their roles as both builders and stakers). Which of the different scenarios (A-E) that would predominate is seemingly a more important parameter when evaluating the merits of MEV pricing auctions than the mechanism’s ability to burn substantial MEV (which this post suggests it can).\n\n MEV burn—a simple design\n\n Sealed execution auction\n\n ePBS Metagame: SSP peacekeeping and alternative public service\n\n Dr. changestuff or: how i learned to stop worrying and love mev-burn\n\n Vorbit SSF with circular and spiral finality: validator selection and distribution\n\n read \n\n 9\n min\n\n Powered by Discourse","tokens":6166,"squid":"spider-04","role":"Research Spider","at":1791347687739,"hash":"2eeb5981ed0906181b3e1de6a6eb9e44b79b794e"}
{"url":"https://www.metaplex.com/docs/tokens/create-a-token","domain":"metaplex.com","title":"Create a Fungible Token | Tokens","text":"Create a fungible token with metadata on Solana using the Token Metadata program. What You'll LearnThis guide shows you how to create and mint a fungible token with:Custom name, symbol, and metadataToken image and descriptionConfigurable decimals (divisibility)Initial token supplyCreate a TokenThe following code is a fully runnable example. Below the parameters that you might want to customize are shown. You can learn more about token creation details in the Token Metadata program pages.1// npm install @metaplex-foundation/mpl-token-metadata @metaplex-foundation/mpl-toolbox @metaplex-foundation/umi @metaplex-foundation/umi-bundle-defaults\n2import {\n3 createFungible,\n4 mplTokenMetadata,\n5} from '@metaplex-foundation/mpl-token-metadata'\n6import {\n7 createTokenIfMissing,\n8 findAssociatedTokenPda,\n9 mintTokensTo,\n10} from '@metaplex-foundation/mpl-toolbox'\n11import {\n12 generateSigner,\n13 keypairIdentity,\n14 percentAmount,\n15 some,\n16} from '@metaplex-foundation/umi'\n17import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n18import { readFileSync } from 'fs'\n19\n20// Initialize Umi with your RPC endpoint\n21const umi = createUmi('https://api.devnet.solana.com').use(mplTokenMetadata())\n22\n23// Load your wallet keypair\n24const wallet = '<your wallet file path>'\n25const secretKey = JSON.parse(readFileSync(wallet, 'utf-8'))\n26const keypair = umi.eddsa.createKeypairFromSecretKey(new Uint8Array(secretKey))\n27umi.use(keypairIdentity(keypair))\n28\n29// Generate a new mint account\n30const mint = generateSigner(umi)\n31\n32// Step 1: Create the fungible token with metadata\n33await createFungible(umi, {\n34 mint,\n35 name: 'My Fungible Token',\n36 symbol: 'MFT',\n37 uri: 'https://example.com/my-token-metadata.json',\n38 sellerFeeBasisPoints: percentAmount(0),\n39 decimals: some(9),\n40}).sendAndConfirm(umi)\n41\n42// Step 2: Mint initial supply to your wallet\n43await createTokenIfMissing(umi, {\n44 mint: mint.publicKey,\n45 owner: umi.identity.publicKey,\n46})\n47 .add(\n48 mintTokensTo(umi, {\n49 mint: mint.publicKey,\n50 token: findAssociatedTokenPda(umi, {\n51 mint: mint.publicKey,\n52 owner: umi.identity.publicKey,\n53 }),\n54 amount: 1_000_000_000_000_000, // 1,000,000 tokens with 9 decimals\n55 })\n56 )\n57 .sendAndConfirm(umi)\n58\n59console.log('Token created:', mint.publicKey)\n60console.log('Metadata and mint account initialized')\n61console.log('Initial supply minted to:', umi.identity.publicKey)\n1import { generateKeyPairSigner } from '@solana/kit';\n2import { createFungible } from '@metaplex-foundation/mpl-token-metadata-kit';\n3\n4// Assuming rpc, rpcSubscriptions, and sendAndConfirmInstructions are set up\n5// See getting-started for full setup\n6\n7const mint = await generateKeyPairSigner();\n8const authority = await generateKeyPairSigner(); // Your wallet\n9\n10// Create a fungible token with metadata and mint initial supply\n11const createAndMintIx = await createFungible({\n12 mint,\n13 authority,\n14 payer: authority,\n15 name: 'My Fungible Token',\n16 symbol: 'MFT',\n17 uri: 'https://example.com/my-token-metadata.json',\n18 sellerFeeBasisPoints: 0,\n19 decimals: 9,\n20 tokenOwner: authority.address,\n21 amount: 1_000_000_000_000_000n, // 1,000,000 tokens with 9 decimals\n22});\n23\n24// Send the instruction (createFungible returns a single combined instruction)\n25await sendAndConfirm({\n26 instructions: [createAndMintIx],\n27 payer: authority,\n28});\n29\n30console.log('Fungible token created:', mint.address);\n31console.log('Initial supply minted to:', authority.address);\n1# Create a Fungible Token using the Metaplex CLI\n2\n3# Interactive wizard mode (recommended for beginners)\n4mplx toolbox token create --wizard\n5\n6# Basic token creation (required: --name, --symbol, --mint-amount)\n7mplx toolbox token create \\\n8 --name \"My Token\" \\\n9 --symbol \"MYT\" \\\n10 --mint-amount 1000000\n11\n12# Full token creation with all options\n13mplx toolbox token create \\\n14 --name \"My Token\" \\\n15 --symbol \"MYT\" \\\n16 --description \"A fungible token on Solana\" \\\n17 --image ./token-image.png \\\n18 --decimals 9 \\\n19 --mint-amount 1000000000000000\n20\n21# Create with a vanity mint address\n22mplx toolbox token create \\\n23 --name \"Cool Token\" \\\n24 --symbol \"COOL\" \\\n25 --mint-amount 1000000 \\\n26 --mint-keypair ./vanity-mint.json\n27\n28# Note: mint-amount is in smallest units\n29# With --decimals 9, to mint 1,000,000 tokens: --mint-amount 1000000000000000\n30# With --decimals 0 (default), to mint 1,000,000 tokens: --mint-amount 1000000\nParametersCustomize these parameters for your token:ParameterDescriptionnameToken name (max 32 characters)symbolShort name of your Token (max 6 characters)uriLink to off-chain metadata JSONsellerFeeBasisPointsRoyalty percentage (550 = 5.5%)decimalsDecimal places (some(9) is standard)amountNumber of tokens to mintMetadata and ImagesThe uri should point to a JSON file containing at least the following information. You can find more details on the Token Metadata Standard page. You need to upload the JSON and the image url so that they are accessible from everywhere. We recommend to use a web3 storage provider like Arweave. If you want to do so by code you can follow this guide on creating deterministic metadata with Turbo.{\n \"name\": \"My Fungible Token\",\n \"symbol\": \"MFT\",\n \"description\": \"A fungible token on Solana\",\n \"image\": \"https://arweave.net/tx-hash\"\n}","tokens":1326,"squid":"dotcat","role":"Tooling Spider","at":1791347689190,"hash":"c98a8fe564b409476452bdf75f07521144a59a3b"}
{"url":"https://docs.chain.link/data-feeds/developer-responsibilities","domain":"docs.chain.link","title":"Developer Responsibilities: Market Integrity and Application Code Risks | Chainlink Documentation","text":"Developer Responsibilities: Market Integrity and Application Code RisksChainlink Data Feeds provide access to highly secure, reliable, and decentralized real-world data published onchain. The assets priced by Chainlink Data Feeds are subject to market conditions beyond the ability of Chainlink node operators to control, as such developers are responsible for ensuring that the operation and performance of Chainlink Data Feeds match expectations.When integrating Chainlink Data Feeds, developers must understand that the performance of feeds is subject to risks associated with both market integrity and application code.\n\nMarket Integrity Risks are those associated with external market conditions impacting price behavior and data quality in unanticipated ways. Developers are solely responsible for monitoring and mitigating any potential market integrity risks.\n\nApplication Code Risks are those associated with the quality, reliability, and dependencies of the code on which an application operates. Developers are solely responsible for monitoring and mitigating any potential application code risks.\n\nPlease refer to this guide for additional information about market integrity risks and how developers can protect their applications. \n\nDeveloper ResponsibilitiesDevelopers are responsible for maintaining the security and user experience of their applications. They must also securely manage all interactions between their applications and third-party services.In particular, developers implementing Chainlink Data Feeds in their code and applications are responsible for their application's market integrity and code risks that may cause unanticipated pricing data behavior. These are described below in more detail.Market Integrity RisksMarket conditions can impact the pricing behavior of assets in ways beyond the ability of Chainlink node operators to predict or control.Market integrity risk factors can include but are not limited to, market manipulation such as Spoofing, Ramping, Bear Raids, Cross-Market Manipulation, Washtrading, and Frontrunning. All assets are susceptible to market risk, but in particular, assets with high market risk, such as those with low liquidity, are the most vulnerable to market manipulation. Developers are solely responsible for accounting for such risk factors when integrating Chainlink Data Feeds into their applications. Developers should understand the market risks around the assets they intend their application to support before integrating associated Chainlink Data Feeds and inform their end users about applicable market risks.Developers should reference the following additional information when implementing Chainlink Data Feeds:\nData Feed Categories to evaluate market integrity risks associated with specific Chainlink Data Feeds Developers intend to integrate.\nEvaluating Data Source Risks to evaluate risk mitigation techniques associated with Chainlink Data Feeds broadly.\nApplication Code RisksDevelopers implementing Chainlink Data Feeds are solely responsible for instituting the requisite risk mitigation processes including, but not limited to, data quality checks, circuit breakers, and appropriate contingency logic for their use case.\n\nCode quality and reliability: Developers must execute code using Chainlink Data Feeds only if the code meets the quality and reliability requirements for their use case and application.\n\nCode and application audits: Developers are responsible for auditing their code and applications before deploying to production. Developers must determine the quality of any audits and ensure that they meet the requirements for their application.\n\nCode dependencies and imports: Developers are responsible for ensuring the quality, reliability, and security of any dependencies or imported packages that they use with Chainlink Data Feeds, and review and audit these dependencies and packages.","tokens":974,"squid":"spider-08","role":"Oracle Spider","at":1791347713033,"hash":"8ffdfa2ba884f8d7e7072eaeb68d02e3b69d58b5"}
{"url":"https://www.metaplex.com/docs/tokens/update-token","domain":"metaplex.com","title":"How to Update Fungible Token Metadata on Solana | Tokens","text":"Update the metadata of your fungible token to change its name, symbol, image, or other properties. Update Token MetadataIn the following section you can find a full code example and the parameters that you might have to change. This uses the Token Metadata program to update on-chain metadata.1// npm install @metaplex-foundation/mpl-token-metadata @metaplex-foundation/umi @metaplex-foundation/umi-bundle-defaults\n2import {\n3 fetchDigitalAsset,\n4 mplTokenMetadata,\n5 updateV1,\n6} from '@metaplex-foundation/mpl-token-metadata'\n7import {\n8 keypairIdentity,\n9 publicKey,\n10} from '@metaplex-foundation/umi'\n11import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n12import { readFileSync } from 'fs'\n13\n14// Initialize Umi with your RPC endpoint\n15const umi = createUmi('https://api.devnet.solana.com').use(mplTokenMetadata())\n16\n17// Load your wallet keypair (must be the update authority)\n18const wallet = '<your wallet file path>'\n19const secretKey = JSON.parse(readFileSync(wallet, 'utf-8'))\n20const keypair = umi.eddsa.createKeypairFromSecretKey(new Uint8Array(secretKey))\n21umi.use(keypairIdentity(keypair))\n22\n23// Your token mint address\n24const mintAddress = publicKey('<your token mint address>')\n25\n26// Fetch existing token data\n27const asset = await fetchDigitalAsset(umi, mintAddress)\n28\n29// Update the token metadata (name, symbol, and URI)\n30await updateV1(umi, {\n31 mint: mintAddress,\n32 authority: umi.identity,\n33 data: {\n34 ...asset.metadata,\n35 name: 'Updated Token Name',\n36 symbol: 'UTN',\n37 uri: 'https://example.com/updated-metadata.json',\n38 },\n39}).sendAndConfirm(umi)\n40\n41console.log('Token metadata updated successfully')\n42console.log('Mint:', mintAddress)\n43console.log('New name:', 'Updated Token Name')\n44console.log('New URI:', 'https://example.com/updated-metadata.json')\n1# Update Token Metadata using the Metaplex CLI\n2\n3# Interactive editor mode (opens metadata JSON in your default editor)\n4mplx toolbox token update <MINT_ADDRESS> --editor\n5\n6# Update specific fields via flags\n7mplx toolbox token update <MINT_ADDRESS> --name \"New Token Name\"\n8mplx toolbox token update <MINT_ADDRESS> --symbol \"NEW\"\n9mplx toolbox token update <MINT_ADDRESS> --description \"Updated description\"\n10\n11# Update with new image\n12mplx toolbox token update <MINT_ADDRESS> --image ./new-image.png\n13\n14# Update multiple fields at once\n15mplx toolbox token update <MINT_ADDRESS> \\\n16 --name \"Updated Token\" \\\n17 --symbol \"UPD\" \\\n18 --description \"An updated token description\" \\\n19 --image ./updated-image.png\n20\n21# Note: You must be the update authority to update token metadata\n22# Note: --editor flag cannot be combined with other update flags\nParametersCustomize these parameters for your update:ParameterDescriptionmintAddressThe token mint addressnameNew token name (max 32 characters)symbolNew token symbol (max 10 characters)uriNew link to off-chain metadata JSONsellerFeeBasisPointsRoyalty percentage (usually 0 for fungibles)How It WorksThe update process is straightforward:Connect with update authority - Your wallet must be the update authority for the tokenCall updateV1 - Provide the mint address and new metadata valuesConfirm transaction - The metadata is updated on-chainWhat Can Be UpdatedYou can update the following on-chain metadata:Name - The display name of your tokenSymbol - The short ticker symbolURI - Link to off-chain JSON metadata (image, description, etc.)Seller fee basis points - Royalty percentageRequirementsTo update token metadata, you must:Be the update authority - Only the designated update authority can modify metadataHave a mutable token - The token must have been created with isMutable: trueUpdating Off-Chain MetadataTo update the token image or description, you need to:Create a new JSON metadata file with updated informationUpload the new JSON to a storage provider (like Arweave)Update the uri field to point to the new JSON file{\n \"name\": \"Updated Token Name\",\n \"symbol\": \"UTN\",\n \"description\": \"An updated description for my token\",\n \"image\": \"https://arweave.net/new-image-hash\"\n}\nImportant NotesUpdates only affect the metadata, not the token itself or existing balancesIf your token was created as immutable, you cannot update its metadataChanging the uri allows you to update off-chain data like images and descriptions","tokens":1077,"squid":"dotcat","role":"Tooling Spider","at":1791347721297,"hash":"158a60ed5ece3569cfef70c40f6364506d388576"}
{"url":"https://docs.chain.link/","domain":"docs.chain.link","title":"Chainlink Documentation | Chainlink Documentation","text":"Build on the Chainlink Platform Chainlink Runtime Environment (CRE)All-in-one orchestration layerData StreamsAccess high-frequency market data for next-gen DeFiMarket and Data FeedsUtilize ultra-secure onchain data for smart contractsDataLinkPublish and commercialize institutional data across blockchainsCross-Chain Interoperability Protocol (CCIP)Move data and value across any blockchainAutomated Compliance Engine (ACE)Enable compliance-focused digital assetsVRFEnsure fair outcomes in games, NFTs, and moreNodesBe part of the Chainlink NetworkDigital Transfer Agent (DTA) Technical StandardUnlock streamlined tokenized fund operationsGeneralFoundational Chainlink knowledgeChainlink LocalRun services locally before transitioning to a testnetChainlink CRE Connect (CREC)Verifiable on-chain events and gas-less, account-abstracted operations Chainlink Runtime Environment (CRE)All-in-one orchestration layerData StreamsAccess high-frequency market data for next-gen DeFiMarket and Data FeedsUtilize ultra-secure onchain data for smart contractsDataLinkPublish and commercialize institutional data across blockchainsCross-Chain Interoperability Protocol (CCIP)Move data and value across any blockchainAutomated Compliance Engine (ACE)Enable compliance-focused digital assetsVRFEnsure fair outcomes in games, NFTs, and moreNodesBe part of the Chainlink NetworkDigital Transfer Agent (DTA) Technical StandardUnlock streamlined tokenized fund operationsGeneralFoundational Chainlink knowledgeChainlink LocalRun services locally before transitioning to a testnetChainlink CRE Connect (CREC)Verifiable on-chain events and gas-less, account-abstracted operations Start your Chainlink journeyUnderstand the Chainlink Runtime EnvironmentLearn how workflows, triggers, capabilities, and DON consensus fit together.Build Your First CRE WorkflowFollow the tutorial series to fetch APIs, read contracts, and write onchain.Deploy Workflows to ProductionChoose a registry model and ship your workflows to the CRE network.Explore Cross-Chain Interoperability with CCIPLearn cross-chain concepts, workflows, and real-world use cases.Build Cross-Chain Apps with CCIP TutorialsFollow step-by-step guides with language switching (EVM, Rust, Move, etc.).Monitor CCIP Transactions in Real TimeTrack the progress and status of cross-chain transactions.Learn How Data Streams Deliver Real-Time DataUnderstand how low-latency streams support time-sensitive applications.Implement Real-Time Use Cases with Data StreamsUse low-latency data in trading, gaming, and other live applications.Deliver Reliable Low-Latency Data with StreamsOperate Data Streams at scale for critical, time-sensitive use cases.Discover Automated Compliance with ACELearn how ACE brings policy management and cross-chain identity to smart contracts.Get Started with ACE Policy and Identity ManagersPick your onboarding path and enforce your first compliance policy onchain.Produce Audit-Ready Compliance ReportsQuery policy runs, identities, and credentials with historical snapshots for regulators. Understand the Chainlink Runtime EnvironmentLearn how workflows, triggers, capabilities, and DON consensus fit together.Explore Cross-Chain Interoperability with CCIPLearn cross-chain concepts, workflows, and real-world use cases.Learn How Data Streams Deliver Real-Time DataUnderstand how low-latency streams support time-sensitive applications.Discover Automated Compliance with ACELearn how ACE brings policy management and cross-chain identity to smart contracts.Explore Verifiable Events and Gas-Less OperationsLearn the core model: channels, watchers, smart accounts, operations, and queries.Understand How Data Feeds Power dAppsSee how oracle data feeds deliver price feeds and reference data.Learn How DataLink Brings Specialized Data OnchainSee how providers publish institutional-grade market data through Chainlink.Discover How the DTA Technical Standard WorksExplore the architecture and subscription/redemption flows for tokenized funds. Try it out Use Chainlink CRE to build, test, and deploy advanced workflows for institutional-grade smart contracts without needing to manage new infrastructure or complex onchain logic. import { cre } from \"@chainlink/cre-sdk\"\n\ncre.handler(\n cron.trigger({ schedule: \"0 */5 * * *\" }), // Every 5 minutes\n (runtime) => {\n // Fetch data from API\n const price = httpClient.get(url).result()\n\n // Read from EVM blockchain\n const threshold = evmClient.read(contract).result()\n\n // Make any computation\n const shouldUpdate = price > threshold\n\n // Write result onchain\n return evmClient.write(contract, price).result()\n }\n)\n Recommended reading We think you'd love to explore General Link Token Contracts Getting Started with CCIP CCIP Directory Data Feed Addresses SmartData Feed Addresses Getting Started with Data Streams Data Streams Addresses","tokens":1211,"squid":"spider-08","role":"Oracle Spider","at":1791347724434,"hash":"b2144d1df60f00b0959e6b27aa5ae2ce02136e8d"}
{"url":"https://docs.chain.link/datalink","domain":"docs.chain.link","title":"DataLink | Chainlink Documentation","text":"DataLinkDataLink is an institutional-grade data publishing service that enables data providers to commercialize specialized market data onchain through Chainlink's secure infrastructure.DataLink connects data providers with blockchain applications without requiring blockchain development expertise. It serves both institutional capital markets and DeFi protocols by enabling data providers to deliver specialized datasets across public chains, private institutional chains, and capital markets infrastructure.Data providers can integrate through existing REST or WebSocket APIs, eliminating custom blockchain development while maintaining control over data distribution and access rights. \n\nKey FeaturesData ProvidersDataLink offers a robust and secure gateway for Data Providers to commercialize valuable data onchain without requiring blockchain expertise. This unlocks a range of benefits for data providers, including:\nNew revenue streams: Commercialize proprietary data across any supported blockchain using Chainlink's enterprise-grade infrastructure, transforming valuable market data into new revenue streams.\nAccess Control: Maintain control over data with configurable access rights, supporting commercializing models aligned with existing business practices.\nNew Distribution Channels: Reach 2,400+ dApps, RWA issuers, and tokenization platforms across public and private blockchains, along with Chainlink's global network of institutional partners, including leading banks, tokenized asset platforms, and financial market infrastructures.\nSeamless integration: Deliver data across any supported chain through a single integration that connects directly to existing REST or WebSocket APIs—no custom blockchain development or data re-architecture required.\nInterested in being a data provider for DataLink? Contact Chainlink Labs to learn more.Web3 Protocols and dAppsDataLink empowers Web3 protocols to access new data types and launch new markets faster than ever before. Key benefits for onchain applications include:\nFaster Market Launches: Access specialized, high-quality data to quickly deploy new assets and markets, gaining a first-mover advantage.\nProven Infrastructure: DataLink is underpinned by Chainlink's proven infrastructure, which has enabled tens of trillions in transaction value.\nSeamless Integration: Access the full DataLink catalog with one integration and easily combine multiple data subscriptions.\nInstitutional-Grade Data: Leverage the same high-quality datasets trusted by global financial institutions, including equities, forex, bonds, commodities, derivatives, and more.\nInterested in integrating DataLink into your DeFi protocol or onchain workflow? Reach out to learn more.\n\nHow DataLink WorksDataLink makes specialized data available to blockchain applications through a three-step process:\nData Connectivity: Chainlink Labs curates and onboards data providers offering market-leading data, including specialized datasets such as sector indices, long-tail asset pricing, and volatility metrics.\nData Consensus and Delivery: Multiple Chainlink nodes within a Decentralized Oracle Network (DON) fetch data from a provider and reach consensus:\n\nPull-based feeds: Nodes reach consensus and create cryptographically signed oracle reports that are delivered to the Aggregation Layer for offchain retrieval\nPush-based feeds: Nodes reach consensus and directly transmit results onchain to aggregator contracts\n\nApplication Integration: Developers integrate data through two delivery methods:\n\nPull-based feeds: REST APIs, WebSocket connections, or SDKs to fetch signed oracle reports offchain and validate their integrity onchain via verifier contracts\nPush-based feeds: Direct smart contract calls to aggregator proxy contracts for onchain data access\n\n Overview of DataLink architecture and how data flows from providers to blockchains. \n\nSpecialized Data TypesDataLink enables access to a wide range of institutional and specialized market data types:\nCredit Ratings: Independent assessments of issuers' and instruments' creditworthiness, default risk, and rating outlooks.\nEquities: Comprehensive data on global equity markets.\nFX Rates: Accurate and timely FX rate data across major, minor, and emerging market currency pairs.\nBonds: Detailed market data including bond yields, maturities, issuer information, and historical pricing.\nCommodities: Extensive coverage of spot and futures prices for commodities such as metals, energy, and agriculture.\nReference Data: Foundational datasets including security identifiers, classifications, corporate hierarchies, and market conventions to ensure consistency across financial instruments.\nPerpetual Funding Rates: Periodic payments exchanged between long and short traders in perpetual futures markets, designed to anchor perpetual contract prices closely to the underlying asset's spot price.\nCorporate Actions Data: Events such as dividends, stock splits, mergers, acquisitions, rights issues, and reorganizations, with detailed terms and effective dates.\nDerivatives: Options, futures, swaps, and structured products, with data on pricing, implied volatility, and contract specifications.\nLong-Tail Crypto Assets: Price data for long-tail crypto-native assets.\nAny Custom Dataset: Tailored data solutions designed to meet unique specifications or requirements for specialized investment strategies or analytics.\n\nTechnical IntegrationDataLink leverages Chainlink's existing infrastructure to provide flexible data delivery options:Pull Delivery\nInfrastructure: Built on Chainlink Data Streams architecture\nAccess methods: REST API, WebSocket, Go SDK, and Rust SDK\nUse cases: High-frequency trading applications, on-demand data retrieval, sub-second data resolution, and applications requiring commit-and-reveal mechanisms to prevent frontrunning\nEfficiency: Retrieves data only when needed, reducing unnecessary onchain transactions\n DataLink pull-based feeds enable data providers to deliver specialized data through the Chainlink Aggregation Layer for offchain retrieval and onchain verification. Learn more about pull-based DataLink feeds.Push Delivery\nInfrastructure: Built on Chainlink Data Feeds architecture\nAccess method: Direct onchain smart contract calls to proxy aggregator contracts\nUse cases: Applications requiring regular onchain data updates at fixed intervals, automated execution based on data thresholds, and continuous data availability for smart contract logic\nPattern: Data is automatically pushed onchain at set intervals or when predefined conditions are met\n DataLink push-based feeds enable data providers to deliver specialized data directly onchain through Chainlink Price aggregator contracts for smart contract access. Learn more about push-based DataLink feeds.\n\nData Quality, Responsibility & Trust AssumptionsDataLink connects protocols to data providers through Chainlink infrastructure. Key considerations for protocol integrators using single-source data include:\nSingle source: Consuming single-source data introduces unique trust assumptions that protocols must manage through risk mitigation and fallback mechanisms.\nProvider responsibility: Data providers are solely responsible for managing data quality, accuracy, uptime, and support.\nProtocol due diligence: Integrating protocols must validate that a provider's data meets their application's specific use case requirements around data quality and reliability.\nReview the Data Quality and Responsibility page for detailed guidance on risk management and trust assumptions.\n\n What's next > Understand data quality & responsibility > View the Provider Catalog > Learn how to integrate DataLink (Pull-Based Delivery) > View the DataLink Architecture (Pull-Based Delivery)","tokens":1939,"squid":"spider-08","role":"Oracle Spider","at":1791347734847,"hash":"5e90340c0ca040829234af39743219b07c810750"}
{"url":"https://docs.phantom.com/solana/establishing-a-connection","domain":"docs.phantom.com","title":"Establish a connection - Phantom developer documentation","text":"Once an application has detected the provider, it can then request to connect to Phantom. This connection request will prompt the user for permission to share their public key, indicating that they are willing to interact further. Users must approve a connection request before the app can make additional requests such as signing a message or sending a transaction.\nOnce permission is established for the first time, the web application’s domain will be whitelisted for future connection requests. After a connection is established, it is possible to terminate the connection from both the application and the user side.\n​Connect\nThe recommended and easiest way to connect to Phantom is by calling window.phantom.solana.connect(). However, the provider also exposes a request JSON RPC interface.\n​connect()\nconst provider = getProvider(); // see \"Detecting the Provider\"\ntry {\n const resp = await provider.connect();\n console.log(resp.publicKey.toString());\n // 26qv4GCcx98RihuK3c4T6ozB3J7L6VwCuFVc7Ta2A3Uo \n} catch (err) {\n // { code: 4001, message: 'User rejected the request.' }\n}\n\n​request()\nconst provider = getProvider(); // see \"Detecting the Provider\"\ntry {\n const resp = await provider.request({ method: \"connect\" });\n console.log(resp.publicKey.toString());\n // 26qv4GCcx98RihuK3c4T6ozB3J7L6VwCuFVc7Ta2A3Uo \n} catch (err) {\n // { code: 4001, message: 'User rejected the request.' }\n}\n\nThe connect() call will return a Promise that resolves when the user accepts the connection request, and reject (throw when awaited) when the user declines the request or closes the pop-up. See Errors for a breakdown of error messages Phantom may emit.\nWhen the user accepts the request to connect, the provider will also emit a connect event.\nprovider.on(\"connect\", () => console.log(\"connected!\"));\n\nOnce the web application is connected to Phantom, it will be able to read the connected account’s public key and prompt the user for additional transactions. It also exposes a convenience isConnected boolean.\nconsole.log(provider.publicKey.toString());\n// 26qv4GCcx98RihuK3c4T6ozB3J7L6VwCuFVc7Ta2A3Uo \nconsole.log(provider.isConnected);\n// true\n\n​Eagerly connecting\nAfter a web application connects to Phantom for the first time, it becomes trusted. Once trusted, it’s possible for the application to automatically connect to Phantom on subsequent visits or page refreshes, without prompting the user for permission. This is referred to as “eagerly connecting”.\nTo implement this, applications should pass an onlyIfTrusted option into the connect() call.\n​connect()\nprovider.connect({ onlyIfTrusted: true });\n\n​request()\nwindow.solana.request({ method: \"connect\", params: { onlyIfTrusted: true }});\n\nIf this flag is present, Phantom will only eagerly connect and emit a connect event if the application is trusted. If the application is not trusted, Phantom will throw a 4001 error and remain disconnected until the user is prompted to connect without an onlyIfTrusted flag. In either case, Phantom will not open a pop-up window, making this convenient to use on all page loads.\nThe following is an example of how a React application can eagerly connect to Phantom.\nimport { useEffect } from \"react\";\n\nuseEffect(() => {\n // Will either automatically connect to Phantom, or do nothing.\n provider.connect({ onlyIfTrusted: true })\n .then(({ publicKey }) => {\n // Handle successful eager connection\n })\n .catch(() => {\n // Handle connection failure as usual\n })\n}, []);\n\nFor a live demo, refer to the handleConnect function in our sandbox.\nIf a wallet disconnects from a trusted app and then attempts to reconnect at a later time, Phantom will still eagerly connect. Once an app is trusted, Phantom will only require the user to approve a connection request if the user revokes the app from within their Trusted Apps settings.\nCross-Origin Iframes\nEager connecting is not supported in cross-origin iframe contexts. If your application is embedded in an iframe on a different origin, Phantom will not automatically reconnect a previously-connected wallet. Users will instead be prompted to approve the connection through the standard connect flow.\n​Disconnect\nDisconnecting mirrors the same process as connecting. However, it is also possible for the wallet to initiate the disconnection, rather than the application itself.\n​disconnect()\nprovider.disconnect();\n\n​request()\nprovider.request({ method: \"disconnect\" });\n\nThe following is an example of how a React application can gracefully handle a disconnect event.\nimport { useState, useEffect } from \"react\";\n\nconst [pubKey, setPubKey] = useState(null);\n\nuseEffect(() => {\n // Store user's public key once they connect\n provider.on(\"connect\", (publicKey) => {\n setPubKey(publicKey);\n });\n\n // Forget user's public key once they disconnect\n provider.on(\"disconnect\", () => {\n setPubKey(null);\n });\n}, [provider]);\n\n​Change accounts\nPhantom allows users to seamlessly manage multiple accounts (such as keypairs) from within a single extension or mobile app. Whenever a user switches accounts, Phantom will emit an accountChanged event.\nIf a user changes accounts while already connected to an application, and the new account had already whitelisted that application, then the user will stay connected and Phantom will pass the PublicKey of the new account:\nprovider.on('accountChanged', (publicKey) => {\n if (publicKey) {\n // Set new public key and continue as usual\n console.log(`Switched to account ${publicKey.toBase58()}`);\n } \n});\n\nIf Phantom does not pass the public key of the new account, an application can either do nothing or attempt to reconnect:\nprovider.on('accountChanged', (publicKey) => {\n if (publicKey) {\n // Set new public key and continue as usual\n console.log(`Switched to account ${publicKey.toBase58()}`);\n } else {\n // Attempt to reconnect to Phantom\n provider.connect().catch((error) => {\n // Handle connection failure\n });\n }\n});\nWas this page helpful?","tokens":1481,"squid":"spider-10","role":"Tooling Spider","at":1791347738287,"hash":"27d559638337a781981c4fada8806526c3ba94c5"}
{"url":"https://www.metaplex.com/docs/tokens/anchor/create-token","domain":"metaplex.com","title":"Create a Token with Anchor | Solana Tokens","text":"This guide demonstrates how to create a fungible token with metadata on Solana using Rust, the Anchor framework, and the Metaplex Token Metadata program via CPI. What You'll BuildA single Anchor instruction that:Creates a new SPL token mintCreates the associated token account for the payerCreates a metadata account with name, symbol, and URIMints an initial token supply to the payerSummaryCreate a fungible SPL token on Solana with Anchor (Rust), mint an initial supply, and attach Metaplex Token Metadata (name, symbol, URI) via CPI.One instruction: init mint + ATA + metadata, then mint supplyUses: SPL Token + Metaplex Token Metadata CPITested: Anchor 0.32.1, Solana Agave 3.1.6Fungible only; NFTs need Master Edition + decimals=0 + supply=1Out of ScopeToken-2022 extensions, confidential transfers, authority revocation, metadata updates, full NFT flow, mainnet deployment.Quick StartJump to: Program · Test Client · Common Errorsanchor init anchor-spl-tokenAdd anchor-spl with metadata feature to Cargo.tomlClone Token Metadata program in Anchor.toml for localnetPaste the program code and run anchor testPrerequisitesRust installed (rustup.rs)Solana CLI installed (docs.solana.com)Anchor CLI installed (cargo install --git https://github.com/coral-xyz/anchor anchor-cli)Node.js and Yarn for running testsA Solana wallet with SOL for transaction feesTested ConfigurationThis guide was tested with the following versions:ToolVersionAnchor CLI0.32.1Solana CLI3.1.6 (Agave)Rust1.92.0Node.js22.15.1Yarn1.22.xInitial SetupStart by initializing a new Anchor project:anchor init anchor-spl-token\ncd anchor-spl-token\nConfigure Cargo.tomlUpdate programs/anchor-spl-token/Cargo.toml:programs/anchor-spl-token/Cargo.toml1[package]\n2name = \"anchor-spl-token\"\n3version = \"0.1.0\"\n4description = \"Created with Anchor\"\n5edition = \"2021\"\n6\n7[lib]\n8crate-type = [\"cdylib\", \"lib\"]\n9name = \"anchor_spl_token\"\n10\n11[lints.rust]\n12unexpected_cfgs = { level = \"warn\", check-cfg = [\n13 'cfg(feature, values(\"custom-heap\", \"custom-panic\", \"anchor-debug\"))'\n14] }\n15\n16[features]\n17default = []\n18cpi = [\"no-entrypoint\"]\n19no-entrypoint = []\n20no-idl = []\n21no-log-ix-name = []\n22idl-build = [\"anchor-lang/idl-build\", \"anchor-spl/idl-build\"]\n23\n24[dependencies]\n25anchor-lang = \"0.32.1\"\n26anchor-spl = { version = \"0.32.1\", features = [\"token\", \"metadata\", \"associated_token\"] }\nImportantThe idl-build feature must include anchor-spl/idl-build or you'll get errors like no function or associated item named 'create_type' found for struct 'anchor_spl::token::Mint'.Configure Anchor.tomlUpdate Anchor.toml to clone the Token Metadata program for local testing:Anchor.toml1[toolchain]\n2package_manager = \"yarn\"\n3\n4[features]\n5resolution = true\n6skip-lint = false\n7\n8[programs.localnet]\n9anchor_spl_token = \"YOUR_PROGRAM_ID_HERE\"\n10\n11[registry]\n12url = \"https://api.apr.dev\"\n13\n14[provider]\n15cluster = \"localnet\"\n16wallet = \"~/.config/solana/id.json\"\n17\n18[scripts]\n19test = \"yarn run ts-mocha -p ./tsconfig.json -t 1000000 tests/**/*.ts\"\n20\n21[test.validator]\n22url = \"https://api.mainnet-beta.solana.com\"\n23bind_address = \"127.0.0.1\"\n24\n25[[test.validator.clone]]\n26address = \"metaqbxxUerdq28cj1RbAWkYQm3ybzjb6a8bt518x1s\"\nbind_address = \"127.0.0.1\" is required for Agave 3.x validators (0.0.0.0 causes a panic)The [[test.validator.clone]] section clones the Metaplex Token Metadata program from mainnetConfigure package.jsonpackage.json1{\n2 \"license\": \"ISC\",\n3 \"scripts\": {\n4 \"lint:fix\": \"prettier */*.js \\\"*/**/*{.js,.ts}\\\" -w\",\n5 \"lint\": \"prettier */*.js \\\"*/**/*{.js,.ts}\\\" --check\"\n6 },\n7 \"dependencies\": {\n8 \"@coral-xyz/anchor\": \"^0.32.1\",\n9 \"@metaplex-foundation/mpl-token-metadata\": \"^3.4.0\",\n10 \"@solana/spl-token\": \"^0.4.9\"\n11 },\n12 \"devDependencies\": {\n13 \"chai\": \"^4.3.4\",\n14 \"mocha\": \"^9.0.3\",\n15 \"ts-mocha\": \"^10.0.0\",\n16 \"@types/bn.js\": \"^5.1.0\",\n17 \"@types/chai\": \"^4.3.0\",\n18 \"@types/mocha\": \"^9.0.0\",\n19 \"typescript\": \"^5.7.3\",\n20 \"prettier\": \"^2.6.2\"\n21 }\n22}\nThe ProgramImports and TemplateHere we define all the imports and create the template for the Account struct and instruction in programs/anchor-spl-token/src/lib.rs:programs/anchor-spl-token/src/lib.rs1use anchor_lang::prelude::*;\n2use anchor_spl::{\n3 associated_token::AssociatedToken,\n4 metadata::{\n5 create_metadata_accounts_v3, mpl_token_metadata::types::DataV2, CreateMetadataAccountsV3,\n6 Metadata,\n7 },\n8 token::{mint_to, Mint, MintTo, Token, TokenAccount},\n9};\n10\n11declare_id!(\"YOUR_PROGRAM_ID_HERE\");\n12\n13#[program]\n14pub mod anchor_spl_token {\n15 use super::*;\n16\n17 pub fn create_token(\n18 ctx: Context<CreateToken>,\n19 name: String,\n20 symbol: String,\n21 uri: String,\n22 decimals: u8,\n23 amount: u64,\n24 ) -> Result<()> {\n25 Ok(())\n26 }\n27}\n28\n29#[derive(Accounts)]\n30#[instruction(name: String, symbol: String, uri: String, decimals: u8)]\n31pub struct CreateToken<'info> {\n32\n33}\nCreating the Account StructThe CreateToken struct defines all accounts required by the instruction and applies the necessary constraints:programs/anchor-spl-token/src/lib.rs1#[derive(Accounts)]\n2#[instruction(name: String, symbol: String, uri: String, decimals: u8)]\n3pub struct CreateToken<'info> {\n4 #[account(mut)]\n5 pub payer: Signer<'info>,\n6\n7 /// The mint account to be created\n8 #[account(\n9 init,\n10 payer = payer,\n11 mint::decimals = decimals,\n12 mint::authority = payer.key(),\n13 mint::freeze_authority = payer.key(),\n14 )]\n15 pub mint: Account<'info, Mint>,\n16\n17 /// The associated token account to receive minted tokens\n18 #[account(\n19 init,\n20 payer = payer,\n21 associated_token::mint = mint,\n22 associated_token::authority = payer,\n23 )]\n24 pub token_account: Account<'info, TokenAccount>,\n25\n26 /// The metadata account to be created\n27 /// CHECK: Validated by seeds constraint to be the correct PDA\n28 #[account(\n29 mut,\n30 seeds = [\n31 b\"metadata\",\n32 token_metadata_program.key().as_ref(),\n33 mint.key().as_ref(),\n34 ],\n35 bump,\n36 seeds::program = token_metadata_program.key(),\n37 )]\n38 pub metadata_account: UncheckedAccount<'info>,\n39\n40 pub token_program: Program<'info, Token>,\n41 pub token_metadata_program: Program<'info, Metadata>,\n42 pub associated_token_program: Program<'info, AssociatedToken>,\n43 pub system_program: Program<'info, System>,\n44 pub rent: Sysvar<'info, Rent>,\n45}\nAccount Types:The #[instruction(...)] attribute allows using instruction arguments (like decimals) in account constraintsmint uses Anchor's init constraint with mint::decimals = decimals to create the token mint with the specified decimal placestoken_account is initialized as an associated token account using associated_token:: helpersmetadata_account uses seeds::program to validate the PDA belongs to the Token Metadata programCreating the InstructionThe create_token function creates the metadata account via CPI and mints the initial token supply:programs/anchor-spl-token/src/lib.rs1pub fn create_token(\n2 ctx: Context<CreateToken>,\n3 name: String,\n4 symbol: String,\n5 uri: String,\n6 decimals: u8,\n7 amount: u64,\n8) -> Result<()> {\n9 msg!(\"Creating token mint...\");\n10 msg!(\"Mint: {}\", ctx.accounts.mint.key());\n11 msg!(\"Creating metadata account...\");\n12 msg!(\"Metadata account address: {}\", ctx.accounts.metadata_account.key());\n13\n14 // Cross Program Invocation (CPI) to token metadata program\n15 create_metadata_accounts_v3(\n16 CpiContext::new(\n17 ctx.accounts.token_metadata_program.to_account_info(),\n18 CreateMetadataAccountsV3 {\n19 metadata: ctx.accounts.metadata_account.to_account_info(),\n20 mint: ctx.accounts.mint.to_account_info(),\n21 mint_authority: ctx.accounts.payer.to_account_info(),\n22 update_authority: ctx.accounts.payer.to_account_info(),\n23 payer: ctx.accounts.payer.to_account_info(),\n24 system_program: ctx.accounts.system_program.to_account_info(),\n25 rent: ctx.accounts.rent.to_account_info(),\n26 },\n27 ),\n28 DataV2 {\n29 name,\n30 symbol,\n31 uri,\n32 seller_fee_basis_points: 0,\n33 creators: None,\n34 collection: None,\n35 uses: None,\n36 },\n37 true, // is_mutable\n38 true, // update_authority_is_signer\n39 None, // collection_details\n40 )?;\n41\n42 // Mint tokens to the payer's associated token account\n43 msg!(\"Minting {} tokens to {}\", amount, ctx.accounts.token_account.key());\n44\n45 mint_to(\n46 CpiContext::new(\n47 ctx.accounts.token_program.to_account_info(),\n48 MintTo {\n49 mint: ctx.accounts.mint.to_account_info(),\n50 to: ctx.accounts.token_account.to_account_info(),\n51 authority: ctx.accounts.payer.to_account_info(),\n52 },\n53 ),\n54 amount,\n55 )?;\n56\n57 msg!(\"Token created and {} tokens minted successfully.\", amount);\n58 Ok(())\n59}\nThe function performs two Cross-Program Invocations:create_metadata_accounts_v3 (lines 14-40) - Creates and initializes the metadata account with name, symbol, and URImint_to (lines 43-54) - Mints the specified amount to the payer's token accountThe ClientBefore testing, build the program:anchor build\nGet your program ID and update it in both lib.rs and Anchor.toml:solana address -k target/deploy/anchor_spl_token-keypair.json\nThen rebuild and deploy:anchor build\nanchor deploy\nCreating the TestCreate the test file at tests/anchor-spl-token.ts:tests/anchor-spl-token.ts1import * as anchor from \"@coral-xyz/anchor\";\n2import { Program } from \"@coral-xyz/anchor\";\n3import { AnchorSplToken } from \"../target/types/anchor_spl_token\";\n4import { Keypair, PublicKey, SystemProgram, SYSVAR_RENT_PUBKEY } from \"@solana/web3.js\";\n5import { TOKEN_PROGRAM_ID, ASSOCIATED_PROGRAM_ID } from \"@coral-xyz/anchor/dist/cjs/utils/token\";\n6import { getAssociatedTokenAddressSync } from \"@solana/spl-token\";\n7import { BN } from \"bn.js\";\n8\n9const TOKEN_METADATA_PROGRAM_ID = new PublicKey(\n10 \"metaqbxxUerdq28cj1RbAWkYQm3ybzjb6a8bt518x1s\"\n11);\n12\n13describe(\"anchor-spl-token\", () => {\n14 const provider = anchor.AnchorProvider.env();\n15 anchor.setProvider(provider);\n16\n17 const program = anchor.workspace.AnchorSplToken as Program<AnchorSplToken>;\n18 const payer = provider.wallet;\n19\n20 it(\"Creates a token with metadata and mints initial supply\", async () => {\n21 const mintKeypair = Keypair.generate();\n22\n23 const tokenName = \"My Token\";\n24 const tokenSymbol = \"MYTKN\";\n25 const tokenUri = \"https://example.com/token-metadata.json\";\n26 const tokenDecimals = 9;\n27 const mintAmount = new BN(1_000_000).mul(new BN(10).pow(new BN(tokenDecimals)));\n28\n29 // Derive the metadata account PDA\n30 const [metadataAccount] = PublicKey.findProgramAddressSync(\n31 [\n32 Buffer.from(\"metadata\"),\n33 TOKEN_METADATA_PROGRAM_ID.toBuffer(),\n34 mintKeypair.publicKey.toBuffer(),\n35 ],\n36 TOKEN_METADATA_PROGRAM_ID\n37 );\n38\n39 // Derive the associated token account\n40 const tokenAccount = getAssociatedTokenAddressSync(\n41 mintKeypair.publicKey,\n42 payer.publicKey\n43 );\n44\n45 console.log(\"Mint address:\", mintKeypair.publicKey.toBase58());\n46 console.log(\"Metadata address:\", metadataAccount.toBase58());\n47 console.log(\"Token account:\", tokenAccount.toBase58());\n48\n49 const tx = await program.methods\n50 .createToken(tokenName, tokenSymbol, tokenUri, tokenDecimals, mintAmount)\n51 .accountsPartial({\n52 payer: payer.publicKey,\n53 mint: mintKeypair.publicKey,\n54 tokenAccount: tokenAccount,\n55 metadataAccount: metadataAccount,\n56 tokenProgram: TOKEN_PROGRAM_ID,\n57 tokenMetadataProgram: TOKEN_METADATA_PROGRAM_ID,\n58 associatedTokenProgram: ASSOCIATED_PROGRAM_ID,\n59 systemProgram: SystemProgram.programId,\n60 rent: SYSVAR_RENT_PUBKEY,\n61 })\n62 .signers([mintKeypair])\n63 .rpc();\n64\n65 console.log(\"Transaction signature:\", tx);\n66 console.log(\"Token created and minted successfully!\");\n67 });\n68});\nKey Points:The metadata account PDA is derived using seeds: [\"metadata\", TOKEN_METADATA_PROGRAM_ID, mint_pubkey] (lines 29-36)The associated token account is derived using getAssociatedTokenAddressSync (lines 39-42)The mint keypair must be passed as a signer since it's being initializedUse accountsPartial to specify accounts (Anchor 0.32+ syntax)Use BN for large numbers (token amounts with decimals)tokenDecimals is passed to the instruction and used to calculate the mint amountRunning the Testyarn install\nanchor test\nExpected output: anchor-spl-token\nMint address: GpPyH2FuMcS5PcrKWtrmEkBmW8h8gSwUaxNCQkFXwifV\nMetadata address: 6jskfrDAmH9d67iL37CLNBK7Hf6FRwNZbq34q4vGucDq\nToken account: J3KCxCfmnK9RJ3onmiUsfBDjvKyuVsAXgWvuypsaFQ2i\nTransaction signature: 36v63t5cCsXYM8ny4pgahh...\nToken created and minted successfully!\n ✔ Creates a token with metadata and mints initial supply (243ms)\n\n 1 passing (245ms)\nMetadata JSON FormatThe uri field should point to a JSON file containing your token's off-chain metadata:token-metadata.json{\n \"name\": \"My Token\",\n \"symbol\": \"MYTKN\",\n \"description\": \"A description of my token\",\n \"image\": \"https://example.com/token-image.png\"\n}\nHost this JSON file on a permanent storage solution like Arweave or IPFS.Common Errorsno function or associated item named 'create_type' foundAdd \"anchor-spl/idl-build\" to the idl-build feature in Cargo.toml:idl-build = [\"anchor-lang/idl-build\", \"anchor-spl/idl-build\"]\nProgram account is not executableClone the Token Metadata program in Anchor.toml:[[test.validator.clone]]\naddress = \"metaqbxxUerdq28cj1RbAWkYQm3ybzjb6a8bt518x1s\"\nUnspecifiedIpAddr(0.0.0.0) / Validator panicAdd bind_address = \"127.0.0.1\" to [test.validator] in Anchor.toml.NotesThe amount parameter is in base units (includes decimals). For 1 million tokens with 9 decimals, pass 1_000_000 * 10^9.This example keeps mint authority and freeze authority on the payer. Production tokens often revoke or transfer these authorities after initial minting.The metadata account is mutable (is_mutable = true). Set to false if you want immutable metadata.Next StepsDeploy to Devnet: Change cluster = \"devnet\" in Anchor.toml and run anchor deployCreate an NFT: Set decimals = 0 and supply = 1 for non-fungible tokensAdd Token Extensions: Explore SPL Token 2022 for transfer fees, interest-bearing tokens, and moreLearn more about Token Metadata: See the Token Metadata documentationQuick ReferenceKey Program IDsProgramAddressToken ProgramTokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DAAssociated Token ProgramATokenGPvbdGVxr1b2hvZbsiqW5xWH25efTNsLJA8knLToken Metadata ProgrammetaqbxxUerdq28cj1RbAWkYQm3ybzjb6a8bt518x1sSystem Program11111111111111111111111111111111Metadata PDA SeedsDeriving the Metadata PDA1const [metadataAccount] = PublicKey.findProgramAddressSync(\n2 [Buffer.from(\"metadata\"), TOKEN_METADATA_PROGRAM_ID.toBuffer(), mint.toBuffer()],\n3 TOKEN_METADATA_PROGRAM_ID\n4);\nMinimum DependenciesCargo.tomlanchor-lang = \"0.32.1\"\nanchor-spl = { version = \"0.32.1\", features = [\"token\", \"metadata\", \"associated_token\"] }\nFAQTerminologyFungible token: decimals >= 0, unlimited supply potentialNFT: decimals = 0, supply = 1, plus Master Edition accountToken Metadata: Metaplex program used for both fungible tokens and NFTsSPL: Solana Program Library, the standard token interfaceWhat is an SPL token?An SPL token is Solana's equivalent of an ERC-20 token on Ethereum. SPL stands for Solana Program Library. SPL tokens are fungible tokens that can represent currencies, governance tokens, stablecoins, or any other fungible asset on Solana.What is the difference between a token mint and a token account?Token Mint: The factory that creates tokens. It defines the token's properties (decimals, supply, authorities). There is one mint per token type.Token Account: A wallet that holds tokens. Each user needs their own token account for each token type they want to hold.What is an Associated Token Account (ATA)?An Associated Token Account is a deterministically-derived token account for a given wallet and mint. Instead of creating random token accounts, ATAs use a standard derivation so anyone can calculate the token account address for any wallet. This is the recommended way to handle token accounts.What is Metaplex Token Metadata?Metaplex Token Metadata is a program that attaches metadata (name, symbol, image URI) to SPL tokens. Without it, tokens are just anonymous mints. The metadata is stored in a Program Derived Address (PDA) associated with the mint.Why clone the Token Metadata program for local testing?The local Solana test validator starts with a clean state and doesn't include any programs except the core Solana programs. Metaplex Token Metadata is a separate program deployed on mainnet, so you need to clone it to use it locally.Can I use this code to create an NFT?Yes, with modifications:Set mint::decimals = 0 (NFTs are indivisible)Mint exactly 1 tokenRemove mint authority after minting (so no more can be created)Add a Master Edition account (for Metaplex NFT standard)How much does it cost to create a token on Solana?Creating a token requires rent for three accounts:Mint account: ~0.00145 SOLToken account: ~0.00203 SOLMetadata account: ~0.01 SOLTotal: approximately 0.015-0.02 SOL (varies with rent prices).What's the difference between Anchor and native Solana Rust?Anchor is a framework that simplifies Solana development by:Auto-generating account serialization/deserializationProviding declarative account validation with macrosGenerating TypeScript clients automaticallyHandling common patterns like PDAs and CPIsNative Solana Rust requires manually handling all of these concerns.GlossaryTermDefinitionSPL TokenSolana Program Library token standard, equivalent to ERC-20MintThe account that defines a token and can create new supplyToken AccountAn account that holds a balance of a specific tokenATAAssociated Token Account - deterministic token account for a walletPDAProgram Derived Address - an address derived from seeds, owned by a programCPICross-Program Invocation - calling one Solana program from anotherAnchorA Rust framework for building Solana programsMetaplexProtocol for NFTs and token metadata on SolanaIDLInterface Definition Language - describes a program's interfaceRentSOL required to keep an account alive on Solana","tokens":4456,"squid":"dotcat","role":"Tooling Spider","at":1791347741909,"hash":"468aa46d89a41f8ebeddf90fe4e6e2915ca0163b"}
{"url":"https://docs.chain.link/datalink/pull-delivery/tutorials","domain":"docs.chain.link","title":"DataLink tutorials (Pull Delivery) | Chainlink Documentation","text":"DataLink tutorials (Pull Delivery)These tutorials guide you through integrating with DataLink pull-delivery feeds, from basic data fetching to onchain verification. Choose the tutorial that matches your preferred programming language and integration method. \n\nGetting startedBefore starting any tutorial, ensure you have:\nAPI Credentials: Access to pull-based DataLink feeds requires API credentials to connect to the Aggregation Network. If you haven't already, contact us to request access.\nDevelopment Environment: Set up your development environment for your chosen programming language (Go or Rust).\nBasic Understanding: Familiarity with report schemas and the DataLink architecture for pull-based feeds.\n\nTutorialsFetch and decode reports (API)Learn how to fetch and decode reports using REST API calls. This method is ideal for applications that need on-demand data retrieval.\nFetch and decode reports using the Go SDK (API)\nFetch and decode reports using the Rust SDK (API)\nStream and decode reports (WebSocket)Learn how to establish real-time data streams using WebSocket connections. This method is ideal for applications that need continuous, low-latency data updates.\nStream and decode reports using the Go SDK (WebSocket)\nStream and decode reports using the Rust SDK (WebSocket)\nOnchain verificationLearn how to verify the authenticity and integrity of report data onchain using the Verifier Proxy contracts.\nVerify Report Data Onchain (EVM)","tokens":364,"squid":"spider-08","role":"Oracle Spider","at":1791347745216,"hash":"d5280c6acda72e485d5e9b8c02ec8598c7e63b5e"}
{"url":"https://docs.phantom.com/solana/errors","domain":"docs.phantom.com","title":"Error messages and codes - Phantom developer documentation","text":"When making requests to Phantom in establishing a connection, sending a transaction, or signing a message, Phantom may respond with an error. The following is a list of all possible error codes and their meanings. These error messages are inspired by Ethereum’s EIP-1474 and EIP-1193.\nCodeTitleDescription4900DisconnectedPhantom could not connect to the network.4100UnauthorizedThe requested method and/or account has not been authorized by the user.4001User Rejected RequestThe user rejected the request through Phantom.-32000Invalid InputMissing or invalid parameters. For recognized Sign-In with Solana (SIWS) messages, this includes a domain that does not match the requesting host or a uri that does not match the requesting origin. Phantom rejects these requests before displaying an approval prompt.-32002Requested resource not availableThis error occurs when a dapp attempts to submit a new transaction while Phantom’s approval dialog is already open for a previous transaction. Only one approve window can be open at a time. Users should approve or reject their transaction before initiating a new transaction.-32003Transaction RejectedPhantom does not recognize a valid transaction.-32601Method Not FoundPhantom does not recognize the method.-32603Internal ErrorSomething went wrong within Phantom.\nTypically, these errors will be easily parseable and have both a code and an explanation. For example:\ntry {\n await window.solana.signMessage();\n} catch (err) {\n // {code: 4100, message: 'The requested method and/or account has not been authorized by the user.'}\n}\nWas this page helpful?","tokens":399,"squid":"spider-10","role":"Tooling Spider","at":1791347748136,"hash":"5ea237451c656865dc74caa0593ccfaf90cac242"}
{"url":"https://docs.chain.link/datalink/pull-delivery/supported-networks","domain":"docs.chain.link","title":"Supported Networks for Report Verification | Chainlink Documentation","text":"Supported Networks for Report VerificationWhile DataLink data is accessed offchain via API or WebSocket, onchain verification of report integrity relies on Verifier Proxy contracts deployed to blockchain networks.DataLink uses the same infrastructure and Verifier Proxy contracts as Chainlink Data Streams. Therefore, DataLink supports onchain report verification on all networks where Data Streams verifier contracts are available. \n\nVerifier Proxy Contract AddressesTo perform onchain verification, you need the address of the Verifier Proxy contract specific to the network you are operating on.Find the list of supported networks and their corresponding Verifier Proxy addresses on the Verifier Proxy Addresses page.\n\nHow Verification WorksThe verification process involves using the Verifier Proxy contract on the relevant chain to check the signature and integrity of the report fetched via the API/WebSocket.For a detailed explanation and code examples, see the Onchain Verification guide.","tokens":249,"squid":"spider-08","role":"Oracle Spider","at":1791347755703,"hash":"e436f3ad9be77e2687862cf31561f0d57df330c2"}
{"url":"https://docs.phantom.com/solana/signing-a-message","domain":"docs.phantom.com","title":"Sign a message - Phantom developer documentation","text":"When a web application is connected to Phantom, it can also request that the user signs a given message. Applications are free to write their own messages which will be displayed to users from within Phantom’s signature prompt. Message signatures do not involve network fees and are a convenient way for apps to verify ownership of an address.\nIn order to send a message for the user to sign, a web application must:\n\nProvide a hex or UTF-8 encoded string as a Uint8Array.\nRequest that the encoded message is signed via the user’s Phantom wallet.\n\nFor an example of signing a message, refer to handleSignMessage in our sandbox.\nPhantom uses Ed25519 signatures for Solana message signatures. To verify a message signature, you can use the tweetnacl npm package.\n​signMessage()\nconst provider = getProvider(); // see \"Detecting the Provider\"\nconst message = `To avoid digital dognappers, sign below to authenticate with CryptoCorgis`;\nconst encodedMessage = new TextEncoder().encode(message);\nconst signedMessage = await provider.signMessage(encodedMessage, \"utf8\");\n\n​request()\nconst provider = getProvider(); // see \"Detecting the Provider\"\nconst message = `To avoid digital dognappers, sign below to authenticate with CryptoCorgis`;\nconst encodedMessage = new TextEncoder().encode(message);\nconst signedMessage = await provider.request({\n method: \"signMessage\",\n params: {\n message: encodedMessage,\n display: \"hex\",\n },\n});\n\n​Sign-In with Solana (SIWS)\nDevelopers who use signMessage to authenticate users can now take advantage of Phantom’s new Sign-In with Solana feature. For more information, refer to our specification on GitHub.\nPhantom validates recognized Sign-In with Solana (SIWS) messages before displaying an approval prompt. Set the message domain to the requesting page’s exact host, including the port when present. When you provide a uri, its origin must match the requesting page’s origin. A mismatch returns error -32000 (Invalid Input) without prompting the user.\n​Support for other “Sign-In with” Standards\nPhantom supports a range of “Sign-In with” (SIW) message standards. You can read more about them in Sign a message.Was this page helpful?","tokens":541,"squid":"spider-10","role":"Tooling Spider","at":1791347758187,"hash":"9bfd31fe0687b7397e2686eee0fdd0cc5985b745"}
{"url":"https://research.arbitrum.io/t/submitting-transaction-bundles/75/1","domain":"research.arbitrum.io","title":"Submitting transaction bundles - Uncategorized - Arbitrum Research","text":"Submitting transaction bundles \n\n Uncategorized\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 5\n\n 2\n\n read \n\n 4\n min\n\n May 2022\n\n 1 / 15\n\n May 2022\n\n Aug 2025\n\n post by edfelten on May 21, 2022\n\n edfelten\n\n We’re considering adding a feature to the sequencer that allows clients to submit a bundle of transactions, that is, a set of multiple transactions, in a single submission. The sequencer would promise to include those transactions consecutively in its ordering, with no other transactions interleaved among them.\nThe sequencer already sequences transactions in the order they arrived at the sequencer, so the result would be as if all of the transactions in the bundle arrived consecutively. The bundles wouldn’t get earlier or later position in the sequence by virtue of being bundles. We wouldn’t guarantee that the transactions in a bundle will end up in the same block, only that no other user transactions will be between them.\nWe think this bundle functionality is useful for some use cases, for example to carry out a sequence of DeFi transactions that rely on an assumption that no other transactions intervene. It also makes some kinds of account abstraction approaches easier to implement.\nOf course we would limit the total size of bundles, or the total gas consumed by a bundle, to some reasonable limit.\nWe’re interested in hearing thoughts on this. Would you use it? Are there any constraints we should take into consideration?\n\n 5\n\n 2\n\n read \n\n 4\n min\n\n post by bbuddha on May 22, 2022\n\n bbuddha\n\n I like it! Could be useful for gasless transactions, in which one tx in the bundle pays gas for all of the other transactions. In addition, it would be cool to create programmability into the bundle submission for condition reversion of other transactions in the bundle revert and perhaps other powerful controls.\nAre you planning to include a way for transactions to figure out the contents of the bundle they are in (block.bundlehash)? If this was possible, along with the conditional reversion, you may be able to implement cross transaction flashloans! Just submit a bundle [flashLoan(), doStuff(), repay()], and the flashLoan() tx would have functionality to revert in case the repay() tx failed.\nOne concern is how trustless this is. Is the bundle not being broken up somehow ensured via changes to the fraud proof mechanism or is it based off of trust in the sequencer? There are scenarios in which it is detrimental to break up the bundle.\n\n post by edfelten on May 24, 2022\n\n edfelten\n\n We weren’t looking to change the semantics of execution on the chain, only how transactions are submitted. The transactions would still execute normally, without any additional affordances, so the only difference from normal submission would be that transactions in a bundle would run consecutively without any others interleaved between them (assuming an honest sequencer).\nStronger notions of bundling that change the execution model could accomplish more, but are a much heavier lift in terms of implementation, and would introduce incompatibilities with Ethereum.\n\n post by bertcmiller on May 31, 2022\n\n bertcmiller\n\n A really common use case for this would be bundling an approval and an action together, e.g. approving a router and making a swap, or approving a vault and depositing funds into it. In my opinion this is a really useful abstraction.\nOne thing that you should be mindful of is that this could change the security model of DeFi protocols. In particular, some contracts rely on the (bad) assumption that EOAs cannot atomically make many transactions in a row. If that assumption is broken then it might open up protocols to economic vulnerabilities. Many protocols with this assumption use require(msg.sender == tx.origin) to ensure that only EOAs are interacting with certain functions.\nAs far as I can tell DeFi protocols have moved away from this assumption because it’s never been a sound one to make in the long run. But opening up the space for atomic EOA execution does change the security model for some contracts, so you should make sure to communicate that if you make this change.\n\n post by edfelten on May 31, 2022\n\n post by eleglenctic on Jun 1, 2022\n\n post by edfelten on Jun 2, 2022\n\n 4 months later\n\n post by stonecoldpat on Oct 8, 2022\n\n 4 months later\n\n post by web3fishermen on Jan 25, 2023\n\n 2 months later\n\n post by hossein_alavi on Mar 19, 2023\n\n 1 month later\n\n post by pahakow on Apr 25, 2023\n\n post by edfelten on Apr 26, 2023\n\n 2 years later\n\n post by cmatt on Jul 16, 2025\n\n 26 days later\n\n post by kakia on Aug 12, 2025\n\n post by cmatt on Aug 15, 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 Bundle imitation on Arbitrum\n\n Uncategorized\n\n defi,tx-ordering\n\n 3\n\n 1.9k\n\n Oct 2023\n\n Transaction ordering policy\n\n Uncategorized\n\n 10\n\n 8.6k\n\n Mar 2023\n\n Hybrid transaction ordering policy\n\n Uncategorized\n\n tx-ordering,sequencer\n\n 6\n\n 2.9k\n\n Nov 2022\n\n Proposed design for Timeboost\n\n Uncategorized\n\n 12\n\n 3.3k\n\n Jun 2024\n\n Arbitrum vs Optimism\n\n Uncategorized\n\n defi\n\n 1\n\n 2.6k\n\n Mar 2023","tokens":1284,"squid":"spider-01","role":"Chain Spider","at":1791347764525,"hash":"5e9bd7ef9905adde454d69aa2d91031811e80b0a"}
{"url":"https://docs.phantom.com/solana/sending-a-transaction","domain":"docs.phantom.com","title":"Send a legacy transaction - Phantom developer documentation","text":"Once a web application is connected to Phantom, it can prompt the user for permission to send transactions on their behalf.\nIn order to send a transaction, a web application must:\n\nCreate an unsigned transaction.\nHave the transaction be signed and submitted to the network by the user’s Phantom wallet.\nOptionally await network confirmation using a Solana JSON RPC connection.\n\nFor more information about the nature of Solana transactions, refer to the solana-web3.js documentation and the Solana Cookbook.\nFor a sample Phantom transaction, check out our sandbox.\n​Sign and send a transaction\nOnce a transaction is created, the web application may ask the user’s Phantom wallet to sign and send the transaction. If accepted, Phantom will sign the transaction with the user’s private key and submit it via a Solana JSON RPC connection. By far the easiest and most recommended way of doing this is by using the signAndSendTransaction method on the provider, but it is also possible to do with request. In both cases, the call will return a Promise for an object containing the signature.\n​signAndSendTransaction()\nconst provider = getProvider(); // see \"Detecting the Provider\"\nconst network = \"<NETWORK_URL>\";\nconst connection = new Connection(network);\nconst transaction = new Transaction();\nconst { signature } = await provider.signAndSendTransaction(transaction);\nawait connection.getSignatureStatus(signature);\n\n​request()\nconst provider = getProvider(); // see \"Detecting the Provider\"\nconst network = \"<NETWORK_URL>\";\nconst connection = new Connection(network);\nconst transaction = new Transaction();\nconst { signature } = await provider.request({\n method: \"signAndSendTransaction\",\n params: {\n message: bs58.encode(transaction.serializeMessage()),\n },\n});\nawait connection.getSignatureStatus(signature);\n\nYou can also specify a SendOptions object as a second argument into signAndSendTransaction or as an options parameter when using request.\nFor a live demo of signAndSendTransaction, refer to handleSignAndSendTransaction in our sandbox.\n​Sign and send multiple transactions\nIt is also possible to sign and send multiple transactions at once. This is exposed through the signAndSendAllTransactions method on the provider. This method accepts an array of Solana transactions, and will optionally accept a SendOptions object as a second parameter. If successful, it will return a Promise for an object containing the array of string signatures and the publicKey of the signer.\n​signAndSendAllTransactions()\nconst provider = getProvider(); // see \"Detecting the Provider\"\nconst network = \"<NETWORK_URL>\";\nconst connection = new Connection(network);\nconst transactions = [new Transaction(), new Transaction()];\nconst { signatures, publicKey } = await provider.signAndSendAllTransactions(transactions);\nawait connection.getSignatureStatuses(signatures);\n\n​Other signing methods\nThe following methods are also supported, but are not recommended over signAndSendTransaction. It is safer for users, and a simpler API for developers, for Phantom to submit the transaction immediately after signing it instead of relying on the application to do so.\nThe following methods are not supported in the wallet standard implementation and may be removed in a future release. These methods are only available via the window.solana object.\n​Sign a transaction (without sending)\nOnce a transaction is created, a web application may ask the user’s Phantom wallet to sign the transaction without also submitting it to the network. The easiest and most recommended way of doing this is via the signTransaction method on the provider, but it is also possible to do via request. In both cases, the call will return a Promise for the signed transaction. After the transaction has been signed, an application may submit the transaction itself using sendRawTransaction in web3.js.\n​signTransaction()\nconst provider = getProvider();\nconst network = \"<NETWORK_URL>\";\nconst connection = new Connection(network);\nconst transaction = new Transaction();\nconst signedTransaction = await provider.signTransaction(transaction);\nconst signature = await connection.sendRawTransaction(signedTransaction.serialize());\n\n​request()\nconst provider = getProvider();\nconst network = \"<NETWORK_URL>\";\nconst connection = new Connection(network);\nconst transaction = new Transaction();\nconst signedTransaction = await provider.request({\n method: \"signTransaction\",\n params: {\n message: bs58.encode(transaction.serializeMessage()),\n },\n});\nconst signature = await connection.sendRawTransaction(signedTransaction.serialize());\n\nFor an example of signTransaction, refer to handleSignTransaction in our sandbox.\n​Sign multiple transactions\nFor legacy integrations, Phantom supports signing multiple transactions at once without sending them. This is exposed through the signAllTransactions method on the provider. This method is not recommended for new integrations. Instead, developers should make use of signAndSendAllTransactions.\n​signAllTransactions()\nconst signedTransactions = await provider.signAllTransactions(transactions);\n\n​request()\nconst message = transactions.map(transaction => {\n return bs58.encode(transaction.serializeMessage());\n});\nconst signedTransactions = await provider.request({\n method: \"signAllTransactions\",\n params: { message },\n});\n\nFor an example of signAllTransactions, refer to handleSignAllTransactions in our sandbox.Was this page helpful?","tokens":1358,"squid":"spider-10","role":"Tooling Spider","at":1791347768274,"hash":"4162a6a8ebe5c2c6997690f1e83f6e2b27096f26"}
{"url":"https://research.arbitrum.io/t/submitting-transaction-bundles/75/2","domain":"research.arbitrum.io","title":"Submitting transaction bundles - Uncategorized - Arbitrum Research","text":"Uncategorized\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 5\n\n 2\n\n read \n\n 4\n min\n\n May 2022\n\n 2 / 15\n\n May 2022\n\n Aug 2025\n\n post by edfelten on May 21, 2022\n\n edfelten\n\n We’re considering adding a feature to the sequencer that allows clients to submit a bundle of transactions, that is, a set of multiple transactions, in a single submission. The sequencer would promise to include those transactions consecutively in its ordering, with no other transactions interleaved among them.\nThe sequencer already sequences transactions in the order they arrived at the sequencer, so the result would be as if all of the transactions in the bundle arrived consecutively. The bundles wouldn’t get earlier or later position in the sequence by virtue of being bundles. We wouldn’t guarantee that the transactions in a bundle will end up in the same block, only that no other user transactions will be between them.\nWe think this bundle functionality is useful for some use cases, for example to carry out a sequence of DeFi transactions that rely on an assumption that no other transactions intervene. It also makes some kinds of account abstraction approaches easier to implement.\nOf course we would limit the total size of bundles, or the total gas consumed by a bundle, to some reasonable limit.\nWe’re interested in hearing thoughts on this. Would you use it? Are there any constraints we should take into consideration?\n\n 5\n\n 2\n\n read \n\n 4\n min\n\n post by bbuddha on May 22, 2022\n\n bbuddha\n\n I like it! Could be useful for gasless transactions, in which one tx in the bundle pays gas for all of the other transactions. In addition, it would be cool to create programmability into the bundle submission for condition reversion of other transactions in the bundle revert and perhaps other powerful controls.\nAre you planning to include a way for transactions to figure out the contents of the bundle they are in (block.bundlehash)? If this was possible, along with the conditional reversion, you may be able to implement cross transaction flashloans! Just submit a bundle [flashLoan(), doStuff(), repay()], and the flashLoan() tx would have functionality to revert in case the repay() tx failed.\nOne concern is how trustless this is. Is the bundle not being broken up somehow ensured via changes to the fraud proof mechanism or is it based off of trust in the sequencer? There are scenarios in which it is detrimental to break up the bundle.\n\n post by edfelten on May 24, 2022\n\n edfelten\n\n We weren’t looking to change the semantics of execution on the chain, only how transactions are submitted. The transactions would still execute normally, without any additional affordances, so the only difference from normal submission would be that transactions in a bundle would run consecutively without any others interleaved between them (assuming an honest sequencer).\nStronger notions of bundling that change the execution model could accomplish more, but are a much heavier lift in terms of implementation, and would introduce incompatibilities with Ethereum.\n\n post by bertcmiller on May 31, 2022\n\n bertcmiller\n\n A really common use case for this would be bundling an approval and an action together, e.g. approving a router and making a swap, or approving a vault and depositing funds into it. In my opinion this is a really useful abstraction.\nOne thing that you should be mindful of is that this could change the security model of DeFi protocols. In particular, some contracts rely on the (bad) assumption that EOAs cannot atomically make many transactions in a row. If that assumption is broken then it might open up protocols to economic vulnerabilities. Many protocols with this assumption use require(msg.sender == tx.origin) to ensure that only EOAs are interacting with certain functions.\nAs far as I can tell DeFi protocols have moved away from this assumption because it’s never been a sound one to make in the long run. But opening up the space for atomic EOA execution does change the security model for some contracts, so you should make sure to communicate that if you make this change.\n\n post by edfelten on May 31, 2022\n\n edfelten\n\n We would not guarantee that the transactions in a bundle execute as a single atomic unit. We would only guarantee that no other transactions come between them. It would still be possible for some transactions in the bundle to revert while others succeed.\n\n post by eleglenctic on Jun 1, 2022\n\n eleglenctic\n\n Would all transactions in a bundle be required to share the same sender address, or can clients indiscriminately reorder bundles of arbitrary transactions before submitting them to the sequencer? Would submitting sequencer bundles be permissionless? How do we define client in this context, is it any transaction signer or is it only a specific piece of Arbitrum infrastructure? Considering that the policy of the sequencer is “first come, first serve,” it’s important to understand if a third party service can violate that policy within a bundle, for better or for worse.\nThere might be an engineering hurdle for composing sequencer bundles from regular user wallets, because I think there isn’t a universal method that wallets use to handle setting a transaction’s nonce or a universal method for when to broadcast a signed transaction.\nIt seems like if an average user wanted to submit a bundle, they would require an intermediary that intercepts their signed transactions until they submit their entire bundle, because I think the default behavior of e.g. Metamask is to submit a transaction to the rpc endpoint as soon as it is signed.\nIn theory, a static webpage could allow users to aggregate signed transactions into a bundle using the eth_sign rpc method to sign raw transaction hashes, but that would be a downgrade to the user’s experience and would empower phishing scams.\nOverall, I’m curious if access to submitting transaction bundles would be offered exclusively to some restricted definition of “clients,” or if this also is meant to provide access directly to individuals who might want to submit an approve and deposit bundle. Arbitrum is designed to offer a seamless experience to Ethereum users, and the approach to integrating sequencer bundles into existing wallets will be important if users are given direct access to this service.\n\n post by edfelten on Jun 2, 2022\n\n 4 months later\n\n post by stonecoldpat on Oct 8, 2022\n\n 4 months later\n\n post by web3fishermen on Jan 25, 2023\n\n 2 months later\n\n post by hossein_alavi on Mar 19, 2023\n\n 1 month later\n\n post by pahakow on Apr 25, 2023\n\n post by edfelten on Apr 26, 2023\n\n 2 years later\n\n post by cmatt on Jul 16, 2025\n\n 26 days later\n\n post by kakia on Aug 12, 2025\n\n post by cmatt on Aug 15, 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 Bundle imitation on Arbitrum\n\n Uncategorized\n\n defi,tx-ordering\n\n 3\n\n 1.9k\n\n Oct 2023\n\n Transaction ordering policy\n\n Uncategorized\n\n 10\n\n 8.6k\n\n Mar 2023\n\n Hybrid transaction ordering policy\n\n Uncategorized\n\n tx-ordering,sequencer\n\n 6\n\n 2.9k\n\n Nov 2022\n\n Proposed design for Timeboost\n\n Uncategorized\n\n 12\n\n 3.3k\n\n Jun 2024\n\n Arbitrum vs Optimism\n\n Uncategorized\n\n defi\n\n 1\n\n 2.6k\n\n Mar 2023","tokens":1811,"squid":"spider-01","role":"Chain Spider","at":1791347774555,"hash":"1f2a5eb4b3563b4947b9014ae05b6d87f5185205"}
{"url":"https://forum.across.to/t/what-the-token-does/52/13","domain":"forum.across.to","title":"What the token does? - Tokenomics (old) - Across Protocol","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 read \n\n 4\n min\n\n Nov 2021\n\n 13 / 26\n\n Nov 2021\n\n Apr 2022\n\n Load more posts above\n\n post by fommes.eth on Nov 17, 2021\n\n post by fommes.eth on Nov 17, 2021\n\n post by Robot on Nov 17, 2021\n\n Robot\n\n fommes.eth\n\n Surely the more utility the better and i’m sure Across will have to go L2 to L2 in the end\n\n post by Sanguine on Nov 17, 2021\n\n Sanguine\n\n Kastormagic\n\n I think that token is needed for the DAO in the first place. It is not even necessary that it have economic value in the form of receiving % from commissions for the interaction of other users with the protocol. First of all, a token is a symbol. The more successful the project is, the more people want to be involved in it through the token.\n\n post by jotatotal on Nov 17, 2021\n\n jotatotal\n\n I would suggest that a part of the fees goes to the DAO treasury, and so increment value of DAO token. On the other hand I also consider that if the token is used to pay fees those fees get burned after that.\n\n post by fommes.eth on Nov 17, 2021\n\n fommes.eth\n\n Robot\n\n There are lots of L2 to L2 bridges already. Imho Across is unique in that sense and should aim to be the Go-To for fast+secure L1 withdrawals. There will always be a need for L1 withdrawals, even if Ethereum becomes mostly just an execution layer.\n\n post by Robot on Nov 17, 2021\n\n Robot\n\n Sanguine\n\n That’s not true go look at Ribbon finance and their token launch people bought and it non-stop gets called a useless govenunce token, Ribbon is very successful with about $200m TVL but the token price don’t reflect that\n\n post by Solace on Nov 17, 2021\n\n Solace\n\n Completely agree with /u/fojo’s post above - this is an important discussion regarding the token launch.\nWould the token be used strictly for governance, to pay out fees, or as a safety module? These do not necessarily have to mutually exclusive, and it’s possible that the token could incorporate all three - but as far as emission and distribution goes, it’s pretty important to make at least one a priority.\nIf choosing a governance route, liquidity incentives and a safety module could also be implemented at a later stage via a proposal. But this would remain subject to a vote, which could take some time to pass.\nOn the topic of liquidity incentives, these will likely remain temporary in order to bootstrap liquidity though there are plenty of examples of where artificially incentivizing usage has led to users with short-term outlooks farming these pools and draining the liquidity afterwards.\nAs far as using the token to incentivize usage goes, one approach could be to provide a gas fee rebate to users that bridge from L1 → L2 using the Arbitrum/optimism native bridge and bridge back to L1 using Across. This could be implemented similarly to Balancer’s gas fee rebate: [Proposal] Balancer Exchange Gas Reimbursement - Proposals - Balancer\nWe could get creative with some ways in order to incentivize usage rather than only incentivizing the LPs (as they will receive a fee of the transaction either way).\n\n post by Sanguine on Nov 17, 2021\n\n Sanguine\n\n Robot\n\n Maybe so. Indeed, in our time, the success of the project for the crowd is the endless rise in the price of the token. And if the price of a token does not grow infinitely, then they begin to call it “useless governance token”. But if the project starts to hype and the price rises, then it abruptly turns into an “incredibly useful governance token”.\n\n post by eqing.eth on Nov 21, 2021\n\n eqing.eth\n\n Kastormagic\n\n Tokens will attract some early users, which is necessary!At the initial stage of the project, it is necessary to attract users by token airdrop and distinguish real users.\n\n post by Alisa on Nov 22, 2021\n\n 9 days later\n\n post by MrHeviDi on Dec 1, 2021\n\n 2 months later\n\n post by jotatotal on Jan 26, 2022\n\n post by lawpanda.eth on Jan 26, 2022\n\n 2 months later\n\n post by J.Berg on Mar 18, 2022\n\n post by heybeo on Mar 22, 2022\n\n post by altsilversurfer.nft on Mar 26, 2022\n\n post by jeffrey on Mar 29, 2022\n\n 12 days later\n\n post by hescollazo on Apr 11, 2022\n\n 10 days later\n\n post by Ray_V on Apr 21, 2022\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Initial thinking around token distribution\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 36\n\n Mar 2022\n\n Across Token Launch Proposal\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 214\n\n May 2022\n\n Across Token Launch Proposal v2\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 47\n\n Nov 2022\n\n Second ACX Drop\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 15\n\n Feb 2024\n\n Welcome to Across\n\n WELCOME 👋\n\n WELCOME 👋\n\n Nov 2022","tokens":1165,"squid":"spider-09","role":"Bridge Spider","at":1791347781709,"hash":"9185de93bd0d7ed7fe04096be7bedeeb3a386aa1"}
{"url":"https://akash.network/docs/developers/deployment/akt/mcp/","domain":"akash.network","title":"MCP Server | Akash Network - Your Guide to Decentralized Cloud","text":"MCP Server Expose Akash Network tools to AI assistants over the Model Context Protocol.\nakt mcp starts an MCP (Model Context Protocol) server over stdio. It serves two tool sets: chain tools resolved from the active akt context, and Console tools registered whenever a Console API key resolves. Either rail alone is enough. The server only refuses to start when neither is available.\n\nStart the Server\nTerminal window# Read-only mode (safe for AI agents)akt mcp\n# With write tools enabledakt mcp --enable-writes\n# Managed setup: Console tools only, no context or wallet neededakt mcp --console-api-key <key>\nFlags:\n\n--enable-writes - Enable write tools (on-chain transactions and provider mutations)\n--console-api-key - Console API key; overrides the context credential and AKT_CONSOLE_API_KEY\n\nBy default, only read-only query tools are available. Write tools require explicit opt-in via --enable-writes. Read tools are annotated as read-only; write tools are marked destructive.\nA contextless Console setup is read-only. Enabling writes requires an explicitly selected context so every mutation has a stable action-log destination. On a chain context, failure to initialize an optional signer does not remove the available query tools; signing-dependent tools are omitted instead.\nStop the stdio server with Ctrl-C. akt cancels in-flight work, releases the blocked input loop, and exits cleanly. Closing stdin also performs a clean shutdown.\n\nAvailable Tools\nWith both rails configured, read-only mode registers 27 tools and --enable-writes registers 33.\nChain read tools (require a network with an RPC endpoint): node status, account balances, deployments, orders, bids, leases, providers, audited attributes, and certificates.\nConsole read tools (require a resolvable Console API key): deployments, bids, providers, GPU pricing, wallet balance, and usage history.\nWrite tools (with --enable-writes): close deployment, create lease, close lease, and submit manifest on the chain rail; close deployment and deposit into escrow on the Console rail. These operations use the same transaction, provider, and Console action logs as their CLI equivalents.\nOwner-scoped chain tools default to the context’s default-account. If the context has no account, the tool requires an explicit owner; it never broadens the request to every account on the network. Console tools use the Console API identity and do not need a local account.\n\nConnect a Client\nMCP clients launch the server themselves over stdio. For Claude Code:\nTerminal windowclaude mcp add akash -- akt mcp\nFor clients configured with JSON (e.g., Claude Desktop):\n{ \"mcpServers\": { \"akash\": { \"command\": \"akt\", \"args\": [\"mcp\"] } }}\nOnly add --enable-writes if you want the client to close deployments, create and close leases, submit manifests, and spend Console credits on your behalf.\n\nRelated Resources\n\nAgent Skill - Operating instructions and reference guides for agents using the akt CLI\nContexts & Configuration - The context the server resolves its settings from\nConsole Integration - Setting up the Console API key the Console tools use\nModel Context Protocol - Protocol documentation\nCommands Reference - Complete akt command reference\n\nEdit page on github\n Agent Skill Commands Reference","tokens":813,"squid":"spider-03","role":"Compute Spider","at":1791347782089,"hash":"4c358322de04612fc03e8b621be10e5ed58d02cf"}
{"url":"https://research.arbitrum.io/t/submitting-transaction-bundles/75","domain":"research.arbitrum.io","title":"Submitting transaction bundles - Uncategorized - Arbitrum Research","text":"Submitting transaction bundles \n\n Uncategorized\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 5\n\n 2\n\n read \n\n 4\n min\n\n May 2022\n\n 1 / 15\n\n May 2022\n\n Aug 2025\n\n post by edfelten on May 21, 2022\n\n edfelten\n\n We’re considering adding a feature to the sequencer that allows clients to submit a bundle of transactions, that is, a set of multiple transactions, in a single submission. The sequencer would promise to include those transactions consecutively in its ordering, with no other transactions interleaved among them.\nThe sequencer already sequences transactions in the order they arrived at the sequencer, so the result would be as if all of the transactions in the bundle arrived consecutively. The bundles wouldn’t get earlier or later position in the sequence by virtue of being bundles. We wouldn’t guarantee that the transactions in a bundle will end up in the same block, only that no other user transactions will be between them.\nWe think this bundle functionality is useful for some use cases, for example to carry out a sequence of DeFi transactions that rely on an assumption that no other transactions intervene. It also makes some kinds of account abstraction approaches easier to implement.\nOf course we would limit the total size of bundles, or the total gas consumed by a bundle, to some reasonable limit.\nWe’re interested in hearing thoughts on this. Would you use it? Are there any constraints we should take into consideration?\n\n 5\n\n 2\n\n read \n\n 4\n min\n\n post by bbuddha on May 22, 2022\n\n bbuddha\n\n I like it! Could be useful for gasless transactions, in which one tx in the bundle pays gas for all of the other transactions. In addition, it would be cool to create programmability into the bundle submission for condition reversion of other transactions in the bundle revert and perhaps other powerful controls.\nAre you planning to include a way for transactions to figure out the contents of the bundle they are in (block.bundlehash)? If this was possible, along with the conditional reversion, you may be able to implement cross transaction flashloans! Just submit a bundle [flashLoan(), doStuff(), repay()], and the flashLoan() tx would have functionality to revert in case the repay() tx failed.\nOne concern is how trustless this is. Is the bundle not being broken up somehow ensured via changes to the fraud proof mechanism or is it based off of trust in the sequencer? There are scenarios in which it is detrimental to break up the bundle.\n\n post by edfelten on May 24, 2022\n\n edfelten\n\n We weren’t looking to change the semantics of execution on the chain, only how transactions are submitted. The transactions would still execute normally, without any additional affordances, so the only difference from normal submission would be that transactions in a bundle would run consecutively without any others interleaved between them (assuming an honest sequencer).\nStronger notions of bundling that change the execution model could accomplish more, but are a much heavier lift in terms of implementation, and would introduce incompatibilities with Ethereum.\n\n post by bertcmiller on May 31, 2022\n\n bertcmiller\n\n A really common use case for this would be bundling an approval and an action together, e.g. approving a router and making a swap, or approving a vault and depositing funds into it. In my opinion this is a really useful abstraction.\nOne thing that you should be mindful of is that this could change the security model of DeFi protocols. In particular, some contracts rely on the (bad) assumption that EOAs cannot atomically make many transactions in a row. If that assumption is broken then it might open up protocols to economic vulnerabilities. Many protocols with this assumption use require(msg.sender == tx.origin) to ensure that only EOAs are interacting with certain functions.\nAs far as I can tell DeFi protocols have moved away from this assumption because it’s never been a sound one to make in the long run. But opening up the space for atomic EOA execution does change the security model for some contracts, so you should make sure to communicate that if you make this change.\n\n post by edfelten on May 31, 2022\n\n edfelten\n\n We would not guarantee that the transactions in a bundle execute as a single atomic unit. We would only guarantee that no other transactions come between them. It would still be possible for some transactions in the bundle to revert while others succeed.\n\n post by eleglenctic on Jun 1, 2022\n\n eleglenctic\n\n Would all transactions in a bundle be required to share the same sender address, or can clients indiscriminately reorder bundles of arbitrary transactions before submitting them to the sequencer? Would submitting sequencer bundles be permissionless? How do we define client in this context, is it any transaction signer or is it only a specific piece of Arbitrum infrastructure? Considering that the policy of the sequencer is “first come, first serve,” it’s important to understand if a third party service can violate that policy within a bundle, for better or for worse.\nThere might be an engineering hurdle for composing sequencer bundles from regular user wallets, because I think there isn’t a universal method that wallets use to handle setting a transaction’s nonce or a universal method for when to broadcast a signed transaction.\nIt seems like if an average user wanted to submit a bundle, they would require an intermediary that intercepts their signed transactions until they submit their entire bundle, because I think the default behavior of e.g. Metamask is to submit a transaction to the rpc endpoint as soon as it is signed.\nIn theory, a static webpage could allow users to aggregate signed transactions into a bundle using the eth_sign rpc method to sign raw transaction hashes, but that would be a downgrade to the user’s experience and would empower phishing scams.\nOverall, I’m curious if access to submitting transaction bundles would be offered exclusively to some restricted definition of “clients,” or if this also is meant to provide access directly to individuals who might want to submit an approve and deposit bundle. Arbitrum is designed to offer a seamless experience to Ethereum users, and the approach to integrating sequencer bundles into existing wallets will be important if users are given direct access to this service.\n\n post by edfelten on Jun 2, 2022\n\n edfelten\n\n The version of this that seems the most useful and straightforward to implement is to (1) not restrict which transactions can be submitted in the same bundle (except for limits on total bundle size), and (2) not restrict who can submit bundles. That is, a bundle is just another way to submit a set of multiple transactions, with the same result as if you submitted the transactions one at a time and it turned out that no other transactions arrived in between yours.\nIf you route your transactions through a third party, it could reorder them within a bundle. That’s basically the same issue you have now if you submit multiple transactions through a third party–it can reorder them if it wants.\nAlso, a dishonest sequencer could reorder or drop the transactions within your bundle. Again, that’s basically what it can already do to transactions submitted one at a time.\n\n 4 months later\n\n post by stonecoldpat on Oct 8, 2022\n\n stonecoldpat\n\n Seems like a nobrainer to support a feature like this. I wouldn’t optimise for making it trustless since you are already trusting the sequencer.\n\n 4 months later\n\n post by web3fishermen on Jan 25, 2023\n\n web3fishermen\n\n @stonecoldpat What do you mean? Could you clarify your statement pls\n\n 2 months later\n\n post by hossein_alavi on Mar 19, 2023\n\n hossein_alavi\n\n Hi!\nI wanted to check if the idea of bundles transactions is implemented or not, and if yes is there a document on how to use it?\n\n 1 month later\n\n post by pahakow on Apr 25, 2023\n\n pahakow\n\n nice\nOne concern is how trustless this is. Is the bundle not being broken up somehow ensured via changes to the fraud proof mechanism or is it based off of trust in the sequencer? There are scenarios in which it is detrimental to break up the bundle.\n\n post by edfelten on Apr 26, 2023\n\n edfelten\n\n The easiest way to do this would be to trust the sequencer to not separate the transactions in the bundle. This is straightforward to implement because one would just need to add an RPC to submit a set of transactions that are meant to be a bundle. Nothing on-chain would need to change.\nEnforcing bundling is more difficult because it would need to be the case that the sequencer cannot (say) extract one transaction from the bundle and just post that one. And that, in turn, seems to require that the transactions in the bundle can’t be separable from each other. That means, for example, that it won’t work to include each transaction’s data in encodable format along with a signature on that one transaction. Instead, the transactions in the bundle would somehow need to be entangled so that each one is invalid unless attached to the others.\nOne way to build non-separable transactions is to use a facility like ERC-4337 account abstraction, which is currently on Arbitrum’s testnet at the moment.\n\n 2 years later\n\n post by cmatt on Jul 16, 2025\n\n cmatt\n\n Has something like this been implemented or is still considered? Or has this been dropped because there are by now other methods, such as the mentioned way via account abstraction, via which something similar can be achieved? It seems to me ability to directly submit bundles to the sequencer could still be useful.\n\n 26 days later\n\n post by kakia on Aug 12, 2025\n\n kakia\n\n It is not implemented at the moment. Other methods may come close to implementing bundling, but nothing guarantees it. What useful cases do you have in mind for this?\n\n post by cmatt on Aug 15, 2025\n\n cmatt\n\n Thanks for the answer! I don’t have any specific use-case in mind. We have been looking into what sequencer commitments could enable for rollups (specifically OP, see https://mirror.xyz/preconf.eth/UoMhzBvWihwLLXuUYywjXLg4JmymEeC2jqlAeIRBD_Q) and cryptoeconomically protected bundles would be one of the things. Since people here seemed interested, we wondered what the status was. One possible use-case would be that you want to migrate some LP position from Uniswap V2 to V3 and you want closing the V2 and opening the V3 to be bundled since other trades in-between could unbalance your 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 Bundle imitation on Arbitrum\n\n Uncategorized\n\n defi,tx-ordering\n\n 3\n\n 1.9k\n\n Oct 2023\n\n Transaction ordering policy\n\n Uncategorized\n\n 10\n\n 8.6k\n\n Mar 2023\n\n Hybrid transaction ordering policy\n\n Uncategorized\n\n tx-ordering,sequencer\n\n 6\n\n 2.9k\n\n Nov 2022\n\n Proposed design for Timeboost\n\n Uncategorized\n\n 12\n\n 3.3k\n\n Jun 2024\n\n Arbitrum vs Optimism\n\n Uncategorized\n\n defi\n\n 1\n\n 2.6k\n\n Mar 2023","tokens":2738,"squid":"spider-01","role":"Chain Spider","at":1791347785707,"hash":"c5fece45419f324ab50f4460b53cc2dcaeba20a5"}
{"url":"https://forum.across.to/t/what-the-token-does/52/15","domain":"forum.across.to","title":"What the token does? - Tokenomics (old) - Across Protocol","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 read \n\n 4\n min\n\n Nov 2021\n\n 15 / 26\n\n Nov 2021\n\n Apr 2022\n\n Load more posts above\n\n post by fommes.eth on Nov 17, 2021\n\n fommes.eth\n\n Imho there is no point in holding the Across token for fees reduction. I imagine a tipical Across user will not bridge all the time, just looking at the general roadmap/POV that Eth mainnet is becoming solely/mostly just the settlement layer, already in the coming months ppl will use more frequent L2s and withdraw back sometimes.\n\n post by fommes.eth on Nov 17, 2021\n\n fommes.eth\n\n I propose the Across token to accrue fees for holders instead.\n\n post by Robot on Nov 17, 2021\n\n Robot\n\n fommes.eth\n\n Surely the more utility the better and i’m sure Across will have to go L2 to L2 in the end\n\n post by Sanguine on Nov 17, 2021\n\n Sanguine\n\n Kastormagic\n\n I think that token is needed for the DAO in the first place. It is not even necessary that it have economic value in the form of receiving % from commissions for the interaction of other users with the protocol. First of all, a token is a symbol. The more successful the project is, the more people want to be involved in it through the token.\n\n post by jotatotal on Nov 17, 2021\n\n jotatotal\n\n I would suggest that a part of the fees goes to the DAO treasury, and so increment value of DAO token. On the other hand I also consider that if the token is used to pay fees those fees get burned after that.\n\n post by fommes.eth on Nov 17, 2021\n\n fommes.eth\n\n Robot\n\n There are lots of L2 to L2 bridges already. Imho Across is unique in that sense and should aim to be the Go-To for fast+secure L1 withdrawals. There will always be a need for L1 withdrawals, even if Ethereum becomes mostly just an execution layer.\n\n post by Robot on Nov 17, 2021\n\n Robot\n\n Sanguine\n\n That’s not true go look at Ribbon finance and their token launch people bought and it non-stop gets called a useless govenunce token, Ribbon is very successful with about $200m TVL but the token price don’t reflect that\n\n post by Solace on Nov 17, 2021\n\n Solace\n\n Completely agree with /u/fojo’s post above - this is an important discussion regarding the token launch.\nWould the token be used strictly for governance, to pay out fees, or as a safety module? These do not necessarily have to mutually exclusive, and it’s possible that the token could incorporate all three - but as far as emission and distribution goes, it’s pretty important to make at least one a priority.\nIf choosing a governance route, liquidity incentives and a safety module could also be implemented at a later stage via a proposal. But this would remain subject to a vote, which could take some time to pass.\nOn the topic of liquidity incentives, these will likely remain temporary in order to bootstrap liquidity though there are plenty of examples of where artificially incentivizing usage has led to users with short-term outlooks farming these pools and draining the liquidity afterwards.\nAs far as using the token to incentivize usage goes, one approach could be to provide a gas fee rebate to users that bridge from L1 → L2 using the Arbitrum/optimism native bridge and bridge back to L1 using Across. This could be implemented similarly to Balancer’s gas fee rebate: [Proposal] Balancer Exchange Gas Reimbursement - Proposals - Balancer\nWe could get creative with some ways in order to incentivize usage rather than only incentivizing the LPs (as they will receive a fee of the transaction either way).\n\n post by Sanguine on Nov 17, 2021\n\n Sanguine\n\n Robot\n\n Maybe so. Indeed, in our time, the success of the project for the crowd is the endless rise in the price of the token. And if the price of a token does not grow infinitely, then they begin to call it “useless governance token”. But if the project starts to hype and the price rises, then it abruptly turns into an “incredibly useful governance token”.\n\n post by eqing.eth on Nov 21, 2021\n\n eqing.eth\n\n Kastormagic\n\n Tokens will attract some early users, which is necessary!At the initial stage of the project, it is necessary to attract users by token airdrop and distinguish real users.\n\n post by Alisa on Nov 22, 2021\n\n Alisa\n\n Acrosit is to establish a Dao and become a token of community governance. However, empowering and offsetting gas is a good suggestion, which can prevent members from throwing it out too early. However, it also has some disadvantages., if it is a gas, will it affect the development of community autonomy? But if it is only from the perspective of token, the more successful across is, the better the development of Dao will be, Of course, it will attract more people to participate\n\n 9 days later\n\n post by MrHeviDi on Dec 1, 2021\n\n MrHeviDi\n\n fommes.eth\n\n But there will be other protocals/bridges to move funds from L2 to L1, so Across needs to atract users to use Across and maybe to hold Across token. Maybe, like someone before montioned, having Across token will give you some fee reduction or something like that.\n\n 2 months later\n\n post by jotatotal on Jan 26, 2022\n\n jotatotal\n\n Solace\n\n What about giving the holders of the token , despite a fee reduction , a share of the fee according to their holdings?\n\n post by lawpanda.eth on Jan 26, 2022\n\n lawpanda.eth\n\n That would functionally be an ‘x’ token, like xSushi, dQuick, etc. On the legal end it creates regulatory questions because it resembles a security. But it is a more functional mechanism for facilitating adoption/use.\n\n 2 months later\n\n post by J.Berg on Mar 18, 2022\n\n J.Berg\n\n Creating a token enables the DAO to have an asset (without investing) that can be used to fund projects/guilds for effort the DAO needs (both maintenance and major initiatives), as well as contribute to internal DAO economics.\n–Paying core team members for their efforts\n–Paying for work done by Guilds and their squads\n–Internal DAO markets and trade\n–Bounties\nWill the Across token be used strictly for governance? or will it be used as money? or both?\nWould it be a monetary asset and a governance token to be used to fund and vote? Some DAO’s treat their governance token as ONLY that, and it actively drives down it’s valuation.\nIf its money then the DAO as an organization has the challenges of both a startup and an emerging digital nationstate in that we have to find and create revenue streams and manage costs, as well as drive the use and acceptance of our denomination both internally and externally.\nI think long term will be based on the size of the treasury it controls and the useful things you can do with it. As a result, I think the focus should be on activities that generate on-chain revenue for the DAO and ways to make the token useful stake it, collateral, ect.\nHow to pay contributors is definitely an important factor to consider. Without contributors, we won’t be able to do any of the above. Part of me feels that if your contributing, it should be because you believe in the DAO long term and shouldn’t expect an immediate monetary reward. The other part of me thinks that contributor renumeration is something that needs to be painstakingly thought out to retain talent and pay our people\n\n post by heybeo on Mar 22, 2022\n\n heybeo\n\n It would be nice to use bridges on the same platform as well as to create a nice dex.\nTrading pairs, for example acx-uma, are used as fees and distributed to token holders.\nacx-x\nacx-y\nacx-z\nJust a simple idea as liquidity addition commissions are burned\n\n post by altsilversurfer.nft on Mar 26, 2022\n\n altsilversurfer.nft\n\n Tokenomics can be viewed as a function of 3 main parameters, token launch (model, vesting scheme, market cap), utility, and inflation. Utility is one of the major drivers of adoption and appreciation of value. Thus, the more utilities, the best. Governance will be the first and more obvious utility of $ACX, but we must think beyond this to achieve sustainnability. This is the ultimate goal. And this is also the common interest of all involved. People that are waiting for profits will be maximally rewarded if they be patient and contribute to protocol sustainnability. Across will be really BIG and this is not a fanboy statement. The major crosschain pipes will see in the future typical value movements that will far exceed those of the biggest centralized exchanges today.\n\n post by jeffrey on Mar 29, 2022\n\n jeffrey\n\n Token is share, it means users own the project\n\n 12 days later\n\n post by hescollazo on Apr 11, 2022\n\n hescollazo\n\n I agree with the use of the token as a payment mechanism for the protocol. The low fees will bring new users and money into the ecosystem. That it can be used in governance will incentivize use of the application and hodling of the asset. Ultimately the goal should be to give users the tools to discover new ways in which to generate positive cash flow and build wealth.\n\n 10 days later\n\n post by Ray_V on Apr 21, 2022\n\n Ray_V\n\n Would we introduce a single staking mechanism? In which we would offer our tokens as liquidity to the across protocol and earn APR either through the fees accrued by the protocol - or another more effective system? Would that be something considered?\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Initial thinking around token distribution\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 36\n\n Mar 2022\n\n Across Token Launch Proposal\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 214\n\n May 2022\n\n Across Token Launch Proposal v2\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 47\n\n Nov 2022\n\n Second ACX Drop\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 15\n\n Feb 2024\n\n Welcome to Across\n\n WELCOME 👋\n\n WELCOME 👋\n\n Nov 2022","tokens":2413,"squid":"spider-09","role":"Bridge Spider","at":1791347791957,"hash":"d7aaa387eff6c809427880ceb7bc15c745e2a1d2"}
{"url":"https://akash.network/docs/developers/deployment/cli/commands-reference/","domain":"akash.network","title":"CLI Commands Reference | Akash Network - Your Guide to Decentralized Cloud","text":"CLI Commands Reference Complete reference for all Provider Services CLI commands.\nThis guide covers all available commands for managing deployments, wallets, and querying the Akash Network.\n\nCommand Structure\nTerminal windowprovider-services <command> <subcommand> [arguments] [flags]\nGlobal Flags:\n\n--node - RPC endpoint (default: tcp://localhost:26657)\n--chain-id - Network identifier (e.g., akashnet-2)\n--from - Wallet name or address\n--gas-prices - Gas price (e.g., 0.025uakt)\n--gas - Gas limit (auto or specific amount)\n--gas-adjustment - Gas estimation multiplier (e.g., 1.5)\n\nDeployment Commands\nCreate Deployment\nCreate a new deployment from an SDL file.\nTerminal windowprovider-services tx deployment create <sdl-file> --from $AKASH_KEY_NAME\nFlags:\n\n--dseq - Deployment sequence number (optional, defaults to current block height)\n--deposit - Initial deposit amount (optional, auto-calculated if not provided)\n\nExample:\nTerminal windowprovider-services tx deployment create deploy.yml --from $AKASH_KEY_NAME\nNote: Assumes environment variables AKASH_NODE, AKASH_CHAIN_ID, AKASH_GAS, AKASH_GAS_PRICES, and AKASH_GAS_ADJUSTMENT are configured.\n\nQuery Deployments\nList all deployments for an account.\nTerminal windowprovider-services query deployment list --owner <address>\nFlags:\n\n--owner - Filter by owner address\n--state - Filter by state (active, closed)\n--page - Page number for pagination\n--limit - Results per page\n\nExample:\nTerminal windowprovider-services query deployment list --owner akash1...\n\nGet Deployment\nGet details of a specific deployment.\nTerminal windowprovider-services query deployment get \\ --owner <address> \\ --dseq <deployment-id> \\\nExample:\nTerminal windowprovider-services query deployment get \\ --owner akash1... \\ --dseq 1234567 \\\n\nUpdate Deployment\nUpdate the deployment hash on-chain. After this, you must send the updated manifest to the provider with send-manifest.\nTerminal windowakash tx deployment update <sdl-file> \\ --dseq <deployment-id> \\ --from $AKASH_KEY_NAME\nWhat can be updated:\n\nContainer image versions\nEnvironment variables\nCommand and args\n\nWhat cannot be updated:\n\nCPU, memory, storage, GPU resources\nPlacement criteria\nService names\n\nExample:\nTerminal windowakash tx deployment update deploy.yml \\ --dseq 1234567 \\ --from $AKASH_KEY_NAME\nNote: This only updates the hash on-chain. You must also run send-manifest to send the actual updated manifest to the provider.\n\nSend Manifest\nSend the deployment manifest to a provider. Required after creating a lease or updating a deployment.\nTerminal windowprovider-services send-manifest <sdl-file> \\ --dseq <deployment-id> \\ --provider <provider-address> \\ --from $AKASH_KEY_NAME\nExample:\nTerminal windowprovider-services send-manifest deploy.yml \\ --dseq 1234567 \\ --provider akash1... \\ --from $AKASH_KEY_NAME\n\nClose Deployment\nClose a deployment and reclaim your deposit.\nTerminal windowprovider-services tx deployment close \\ --dseq <deployment-id> \\ --from $AKASH_KEY_NAME\nExample:\nTerminal windowprovider-services tx deployment close \\ --dseq 1234567 \\ --from $AKASH_KEY_NAME\n\nMarket Commands\nList Bids\nView all bids for your deployment.\nTerminal windowprovider-services query market bid list \\ --owner <address> \\\nFlags:\n\n--owner - Filter by deployment owner\n--dseq - Filter by deployment sequence\n--gseq - Filter by group sequence\n--oseq - Filter by order sequence\n--provider - Filter by provider address\n--state - Filter by state (open, active, closed)\n\nExample:\nTerminal windowprovider-services query market bid list \\ --owner akash1... \\ --dseq 1234567 \\\n\nGet Bid\nGet details of a specific bid.\nTerminal windowprovider-services query market bid get \\ --owner <address> \\ --dseq <deployment-id> \\ --gseq <group-sequence> \\ --oseq <order-sequence> \\ --provider <provider-address> \\\n\nCreate Lease\nAccept a bid and create a lease.\nTerminal windowprovider-services tx market lease create \\ --dseq <deployment-id> \\ --gseq <group-sequence> \\ --oseq <order-sequence> \\ --provider <provider-address> \\ --from $AKASH_KEY_NAME\nExample:\nTerminal windowprovider-services tx market lease create \\ --dseq 1234567 \\ --gseq 1 \\ --oseq 1 \\ --provider akash1... \\ --from $AKASH_KEY_NAME\n\nList Leases\nView all leases for your account.\nTerminal windowprovider-services query market lease list \\ --owner <address> \\\nFlags:\n\n--owner - Filter by deployment owner\n--provider - Filter by provider\n--dseq - Filter by deployment sequence\n--state - Filter by state (active, closed)\n\nClose Lease\nClose a lease (also closes the deployment).\nTerminal windowprovider-services tx market lease close \\ --dseq <deployment-id> \\ --gseq <group-sequence> \\ --oseq <order-sequence> \\ --provider <provider-address> \\ --from $AKASH_KEY_NAME\n\nLease Close Reasons\nWhen querying a closed lease, the response includes a reason field indicating why the lease was closed. This is useful for diagnosing unexpected lease closures.\nTerminal windowprovider-services query market lease get \\ --owner <address> \\ --dseq <deployment-id> \\ --gseq <group-sequence> \\ --oseq <order-sequence> \\ --provider <provider-address>\nExample response:\n{ \"lease\": { \"state\": \"closed\", \"reason\": \"lease_closed_reason_insufficient_funds\" }}\nReason Codes:\n\nReasonInitiated ByDescriptionlease_closed_ownerTenantThe deployment owner submitted a lease close transaction.lease_closed_reason_manifest_timeoutProviderThe manifest was not sent to the provider within the required time window after lease creation.lease_closed_reason_unstableProviderThe deployment workloads were unstable, for example due to an invalid or unresolvable container image.lease_closed_reason_decommissionProviderThe provider is being decommissioned.lease_closed_reason_unspecifiedProviderThe provider closed the lease without specifying a reason.lease_closed_reason_insufficient_fundsNetworkThe tenant’s account balance was insufficient to continue paying the provider.\n\nProvider Commands\nList Providers\nView all registered providers on the network.\nTerminal windowprovider-services query provider list \\\nExample output:\n{ \"providers\": [ { \"owner\": \"akash1...\", \"host_uri\": \"https://provider.example.com\", \"attributes\": [ { \"key\": \"region\", \"value\": \"us-west\" } ] } ]}\n\nGet Provider\nGet details of a specific provider.\nTerminal windowprovider-services query provider get <provider-address> \\\n\nCertificate Commands\nGenerate Certificate\nGenerate a client certificate for sending manifests.\nTerminal windowprovider-services tx cert generate client \\ --from $AKASH_KEY_NAME\nFlags:\n\n--overwrite - Overwrite existing certificate if one exists\n\nExample with overwrite:\nTerminal windowprovider-services tx cert generate client \\ --from $AKASH_KEY_NAME \\ --overwrite\n\nPublish Certificate\nPublish your certificate to the blockchain.\nTerminal windowprovider-services tx cert publish client \\ --from $AKASH_KEY_NAME\n\nRevoke Certificate\nRevoke a published certificate.\nTerminal windowprovider-services tx cert revoke \\ --from $AKASH_KEY_NAME\n\nList Certificates\nView all certificates for an account.\nTerminal windowprovider-services query cert list \\ --owner <address> \\\n\nWallet Commands\nCreate Wallet\nCreate a new wallet.\nTerminal windowprovider-services keys add <wallet-name>\nFlags:\n\n--recover - Import from mnemonic\n--keyring-backend - Keyring storage (os, file, test)\n\nExample:\nTerminal windowprovider-services keys add my-wallet\n\nImport Wallet\nImport an existing wallet from mnemonic.\nTerminal windowprovider-services keys add <wallet-name> --recover\nYou’ll be prompted to enter your 24-word mnemonic phrase.\n\nList Wallets\nList all wallets in your keyring.\nTerminal windowprovider-services keys list\n\nShow Wallet\nDisplay wallet address and public key.\nTerminal windowprovider-services keys show <wallet-name>\nFlags:\n\n-a - Show address only\n-p - Show public key only\n\nExample:\nTerminal window# Show address onlyprovider-services keys show my-wallet -a\n\nDelete Wallet\nDelete a wallet from your keyring.\nTerminal windowprovider-services keys delete <wallet-name>\nWarning: This cannot be undone. Make sure you have backed up your mnemonic.\n\nExport Wallet\nExport a wallet to a keyfile.\nTerminal windowprovider-services keys export <wallet-name>\n\nImport Keyfile\nImport a wallet from an exported keyfile.\nTerminal windowprovider-services keys import <wallet-name> <keyfile>\n\nQuery Commands\nCheck Balance\nQuery account balance.\nTerminal windowprovider-services query bank balances <address> \\\nExample:\nTerminal windowprovider-services query bank balances akash1... \\\nExample output:\n{ \"balances\": [ { \"denom\": \"uakt\", \"amount\": \"5000000\" } ]}\nNote: Amounts are in uakt (micro-AKT). 1 AKT = 1,000,000 uakt.\n\nQuery Account\nGet account information.\nTerminal windowprovider-services query auth account <address> \\\n\nNode Status\nCheck node sync status.\nTerminal windowprovider-services status \\\n\nBlock Information\nGet block information by height.\nTerminal windowprovider-services query block <height> \\\n\nTransaction\nQuery transaction by hash.\nTerminal windowprovider-services query tx <hash> \\\n\nTransaction Commands\nSend Tokens\nSend AKT to another address.\nTerminal windowprovider-services tx bank send <from-address> <to-address> <amount>uakt \\ --from $AKASH_KEY_NAME\nExample:\nTerminal windowprovider-services tx bank send akash1from... akash1to... 1000000uakt \\ --from $AKASH_KEY_NAME\n\nEnvironment Variables\nAll commands in this reference assume the following environment variables are configured (as described in the Configuration Guide):\nMainnet Configuration\nTerminal windowexport AKASH_NODE=\"https://rpc.akashnet.net:443\"export AKASH_CHAIN_ID=\"akashnet-2\"export AKASH_GAS=\"auto\"export AKASH_GAS_PRICES=\"0.025uakt\"export AKASH_GAS_ADJUSTMENT=\"1.5\"export AKASH_KEY_NAME=\"my-wallet\"export AKASH_KEYRING_BACKEND=\"os\"\nSandbox Configuration\nTerminal windowexport AKASH_NODE=\"https://rpc.sandbox-2.aksh.pw:443\"export AKASH_CHAIN_ID=\"sandbox-2\"export AKASH_GAS=\"auto\"export AKASH_GAS_PRICES=\"0.025uakt\"export AKASH_GAS_ADJUSTMENT=\"1.5\"export AKASH_KEY_NAME=\"my-wallet\"export AKASH_KEYRING_BACKEND=\"os\"\n\nOutput Formats\nControl output format with --output:\nTerminal window# JSON (default)provider-services query ... --output json\n# Textprovider-services query ... --output text\n# YAMLprovider-services query ... --output yaml\n\nRelated Resources\n\nCLI Installation\nCommon Tasks\nConfiguration\nSDL Reference\n\nEdit page on github\n Common Tasks Mint & Burn ACT","tokens":2585,"squid":"spider-03","role":"Compute Spider","at":1791347792004,"hash":"792f5457f5f21bb37967621b4f9002c50a4e4d90"}
{"url":"https://research.arbitrum.io/t/submitting-transaction-bundles/75/3","domain":"research.arbitrum.io","title":"Submitting transaction bundles - Uncategorized - Arbitrum Research","text":"Uncategorized\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 5\n\n 2\n\n read \n\n 4\n min\n\n May 2022\n\n 3 / 15\n\n May 2022\n\n Aug 2025\n\n post by edfelten on May 21, 2022\n\n edfelten\n\n We’re considering adding a feature to the sequencer that allows clients to submit a bundle of transactions, that is, a set of multiple transactions, in a single submission. The sequencer would promise to include those transactions consecutively in its ordering, with no other transactions interleaved among them.\nThe sequencer already sequences transactions in the order they arrived at the sequencer, so the result would be as if all of the transactions in the bundle arrived consecutively. The bundles wouldn’t get earlier or later position in the sequence by virtue of being bundles. We wouldn’t guarantee that the transactions in a bundle will end up in the same block, only that no other user transactions will be between them.\nWe think this bundle functionality is useful for some use cases, for example to carry out a sequence of DeFi transactions that rely on an assumption that no other transactions intervene. It also makes some kinds of account abstraction approaches easier to implement.\nOf course we would limit the total size of bundles, or the total gas consumed by a bundle, to some reasonable limit.\nWe’re interested in hearing thoughts on this. Would you use it? Are there any constraints we should take into consideration?\n\n 5\n\n 2\n\n read \n\n 4\n min\n\n post by bbuddha on May 22, 2022\n\n bbuddha\n\n I like it! Could be useful for gasless transactions, in which one tx in the bundle pays gas for all of the other transactions. In addition, it would be cool to create programmability into the bundle submission for condition reversion of other transactions in the bundle revert and perhaps other powerful controls.\nAre you planning to include a way for transactions to figure out the contents of the bundle they are in (block.bundlehash)? If this was possible, along with the conditional reversion, you may be able to implement cross transaction flashloans! Just submit a bundle [flashLoan(), doStuff(), repay()], and the flashLoan() tx would have functionality to revert in case the repay() tx failed.\nOne concern is how trustless this is. Is the bundle not being broken up somehow ensured via changes to the fraud proof mechanism or is it based off of trust in the sequencer? There are scenarios in which it is detrimental to break up the bundle.\n\n post by edfelten on May 24, 2022\n\n edfelten\n\n We weren’t looking to change the semantics of execution on the chain, only how transactions are submitted. The transactions would still execute normally, without any additional affordances, so the only difference from normal submission would be that transactions in a bundle would run consecutively without any others interleaved between them (assuming an honest sequencer).\nStronger notions of bundling that change the execution model could accomplish more, but are a much heavier lift in terms of implementation, and would introduce incompatibilities with Ethereum.\n\n post by bertcmiller on May 31, 2022\n\n bertcmiller\n\n A really common use case for this would be bundling an approval and an action together, e.g. approving a router and making a swap, or approving a vault and depositing funds into it. In my opinion this is a really useful abstraction.\nOne thing that you should be mindful of is that this could change the security model of DeFi protocols. In particular, some contracts rely on the (bad) assumption that EOAs cannot atomically make many transactions in a row. If that assumption is broken then it might open up protocols to economic vulnerabilities. Many protocols with this assumption use require(msg.sender == tx.origin) to ensure that only EOAs are interacting with certain functions.\nAs far as I can tell DeFi protocols have moved away from this assumption because it’s never been a sound one to make in the long run. But opening up the space for atomic EOA execution does change the security model for some contracts, so you should make sure to communicate that if you make this change.\n\n post by edfelten on May 31, 2022\n\n edfelten\n\n We would not guarantee that the transactions in a bundle execute as a single atomic unit. We would only guarantee that no other transactions come between them. It would still be possible for some transactions in the bundle to revert while others succeed.\n\n post by eleglenctic on Jun 1, 2022\n\n eleglenctic\n\n Would all transactions in a bundle be required to share the same sender address, or can clients indiscriminately reorder bundles of arbitrary transactions before submitting them to the sequencer? Would submitting sequencer bundles be permissionless? How do we define client in this context, is it any transaction signer or is it only a specific piece of Arbitrum infrastructure? Considering that the policy of the sequencer is “first come, first serve,” it’s important to understand if a third party service can violate that policy within a bundle, for better or for worse.\nThere might be an engineering hurdle for composing sequencer bundles from regular user wallets, because I think there isn’t a universal method that wallets use to handle setting a transaction’s nonce or a universal method for when to broadcast a signed transaction.\nIt seems like if an average user wanted to submit a bundle, they would require an intermediary that intercepts their signed transactions until they submit their entire bundle, because I think the default behavior of e.g. Metamask is to submit a transaction to the rpc endpoint as soon as it is signed.\nIn theory, a static webpage could allow users to aggregate signed transactions into a bundle using the eth_sign rpc method to sign raw transaction hashes, but that would be a downgrade to the user’s experience and would empower phishing scams.\nOverall, I’m curious if access to submitting transaction bundles would be offered exclusively to some restricted definition of “clients,” or if this also is meant to provide access directly to individuals who might want to submit an approve and deposit bundle. Arbitrum is designed to offer a seamless experience to Ethereum users, and the approach to integrating sequencer bundles into existing wallets will be important if users are given direct access to this service.\n\n post by edfelten on Jun 2, 2022\n\n edfelten\n\n The version of this that seems the most useful and straightforward to implement is to (1) not restrict which transactions can be submitted in the same bundle (except for limits on total bundle size), and (2) not restrict who can submit bundles. That is, a bundle is just another way to submit a set of multiple transactions, with the same result as if you submitted the transactions one at a time and it turned out that no other transactions arrived in between yours.\nIf you route your transactions through a third party, it could reorder them within a bundle. That’s basically the same issue you have now if you submit multiple transactions through a third party–it can reorder them if it wants.\nAlso, a dishonest sequencer could reorder or drop the transactions within your bundle. Again, that’s basically what it can already do to transactions submitted one at a time.\n\n 4 months later\n\n post by stonecoldpat on Oct 8, 2022\n\n stonecoldpat\n\n Seems like a nobrainer to support a feature like this. I wouldn’t optimise for making it trustless since you are already trusting the sequencer.\n\n 4 months later\n\n post by web3fishermen on Jan 25, 2023\n\n web3fishermen\n\n @stonecoldpat What do you mean? Could you clarify your statement pls\n\n 2 months later\n\n post by hossein_alavi on Mar 19, 2023\n\n hossein_alavi\n\n Hi!\nI wanted to check if the idea of bundles transactions is implemented or not, and if yes is there a document on how to use it?\n\n 1 month later\n\n post by pahakow on Apr 25, 2023\n\n pahakow\n\n nice\nOne concern is how trustless this is. Is the bundle not being broken up somehow ensured via changes to the fraud proof mechanism or is it based off of trust in the sequencer? There are scenarios in which it is detrimental to break up the bundle.\n\n post by edfelten on Apr 26, 2023\n\n edfelten\n\n The easiest way to do this would be to trust the sequencer to not separate the transactions in the bundle. This is straightforward to implement because one would just need to add an RPC to submit a set of transactions that are meant to be a bundle. Nothing on-chain would need to change.\nEnforcing bundling is more difficult because it would need to be the case that the sequencer cannot (say) extract one transaction from the bundle and just post that one. And that, in turn, seems to require that the transactions in the bundle can’t be separable from each other. That means, for example, that it won’t work to include each transaction’s data in encodable format along with a signature on that one transaction. Instead, the transactions in the bundle would somehow need to be entangled so that each one is invalid unless attached to the others.\nOne way to build non-separable transactions is to use a facility like ERC-4337 account abstraction, which is currently on Arbitrum’s testnet at the moment.\n\n 2 years later\n\n post by cmatt on Jul 16, 2025\n\n cmatt\n\n Has something like this been implemented or is still considered? Or has this been dropped because there are by now other methods, such as the mentioned way via account abstraction, via which something similar can be achieved? It seems to me ability to directly submit bundles to the sequencer could still be useful.\n\n 26 days later\n\n post by kakia on Aug 12, 2025\n\n kakia\n\n It is not implemented at the moment. Other methods may come close to implementing bundling, but nothing guarantees it. What useful cases do you have in mind for this?\n\n post by cmatt on Aug 15, 2025\n\n cmatt\n\n Thanks for the answer! I don’t have any specific use-case in mind. We have been looking into what sequencer commitments could enable for rollups (specifically OP, see https://mirror.xyz/preconf.eth/UoMhzBvWihwLLXuUYywjXLg4JmymEeC2jqlAeIRBD_Q) and cryptoeconomically protected bundles would be one of the things. Since people here seemed interested, we wondered what the status was. One possible use-case would be that you want to migrate some LP position from Uniswap V2 to V3 and you want closing the V2 and opening the V3 to be bundled since other trades in-between could unbalance your 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 Bundle imitation on Arbitrum\n\n Uncategorized\n\n defi,tx-ordering\n\n 3\n\n 1.9k\n\n Oct 2023\n\n Transaction ordering policy\n\n Uncategorized\n\n 10\n\n 8.6k\n\n Mar 2023\n\n Hybrid transaction ordering policy\n\n Uncategorized\n\n tx-ordering,sequencer\n\n 6\n\n 2.9k\n\n Nov 2022\n\n Proposed design for Timeboost\n\n Uncategorized\n\n 12\n\n 3.3k\n\n Jun 2024\n\n Arbitrum vs Optimism\n\n Uncategorized\n\n defi\n\n 1\n\n 2.6k\n\n Mar 2023","tokens":2729,"squid":"spider-01","role":"Chain Spider","at":1791347807808,"hash":"59c33491b725f2d95d9bf777aace5b83005352fd"}
{"url":"https://akash.network/docs/developers/deployment/cli/installation-guide/","domain":"akash.network","title":"Install provider-services CLI | Akash Network - Your Guide to Decentralized Cloud","text":"Install provider-services CLI Get set up with the provider-services CLI to deploy on Akash Network.\nThis guide walks you through installing the CLI, creating a wallet, and funding your account.\n\nInstall provider-services\nSelect your operating system:\n\nMacOSOption 1: Using Homebrew (Recommended)brew tap akash-network/tapbrew install akash-provider-servicesOption 2: Download Binarycd ~/Downloads\n# Download the latest releasecurl -sfL https://raw.githubusercontent.com/akash-network/provider/main/install.sh | bashMove the Binarysudo mv ./bin/provider-services /usr/local/binVerify Installationprovider-services versionExpected Outputv0.12.0Download and Install Binarycd ~\n# Install dependenciesapt install jq -yapt install unzip -y\n# Download and install provider-servicescurl -sfL https://raw.githubusercontent.com/akash-network/provider/main/install.sh | bashAdd to Pathvi /etc/environmentAdd the following to PATH:/root/binMake Path Active. /etc/environmentVerify Installationprovider-services versionExpected Outputv0.12.0WindowsUsing WSL2 (Recommended)Install Windows Subsystem for Linux 2, then follow the Linux instructions above.Install WSL2Native Windows\nDownload the latest Windows binary from GitHub Releases\nExtract the .zip file\nMove provider-services.exe to a directory in your PATH\nOpen PowerShell and verify:\nprovider-services versionFrom SourceInstalling provider-services from source:$ go get -d github.com/akash-network/provider$ cd $GOPATH/src/github.com/akash-network/provider$ export AKASH_META_URL=\"https://raw.githubusercontent.com/akash-network/net/main/mainnet/meta.json\"$ AKASH_VERSION=\"$(curl -s https://api.github.com/repos/akash-network/provider/releases/latest | jq -r '.tag_name')\"$ git checkout \"$AKASH_VERSION\"$ make deps-install$ make installRequirements:\nGo 1.25.5+\nProperly set GOPATH\n$GOPATH/bin present in $PATH\nOnce you have the dependencies setup, download and build using make install.Verify Installationprovider-services version\n\nCreate an Account\nConfigure the name of your key:\nTerminal windowAKASH_KEY_NAME=my-wallet\nVerify the variable is set:\nTerminal windowecho $AKASH_KEY_NAME\nSet the keyring backend:\nTerminal windowAKASH_KEYRING_BACKEND=os\nCreate an Akash account:\nTerminal windowprovider-services keys add $AKASH_KEY_NAME\nRead the output and save your mnemonic phrase in a safe place.\nSet your account address as a variable:\nTerminal windowexport AKASH_ACCOUNT_ADDRESS=\"$(provider-services keys show $AKASH_KEY_NAME -a)\"\necho $AKASH_ACCOUNT_ADDRESS\nNote that if you close your Terminal window this variable will not be saved.\n\nFund your Account\nA minimum deposit of 0.5 AKT is required to deploy on Akash. A small transaction fee is also applied to deployment leases.\nGet AKT tokens:\n\nBuying AKT from an exchange / swapping to AKT\nJoin the Akash Community\n\nConfigure your Network\nUse mainnet meta.json as the source for chain ID and RPC endpoints (curl and jq required).\nTerminal windowexport AKASH_META_URL=\"https://raw.githubusercontent.com/akash-network/net/main/mainnet/meta.json\"\nVersion\nTerminal windowAKASH_VERSION=\"$(curl -s https://api.github.com/repos/akash-network/provider/releases/latest | jq -r '.tag_name')\"\nChain ID\nTerminal windowexport AKASH_CHAIN_ID=\"$(curl -sSf \"$AKASH_META_URL\" | jq -r '.chain_id')\"\nNetwork Node\nPick a random public RPC from meta.json (or use .apis.rpc[0].address for the first entry):\nTerminal windowexport AKASH_NODE=\"$(curl -sSf \"$AKASH_META_URL\" | jq -r '.apis.rpc[].address' | shuf -n 1)\"\nConfirm Network Variables\nTerminal windowecho $AKASH_NODE $AKASH_CHAIN_ID $AKASH_KEYRING_BACKEND\nYou should see something similar to:\nhttps://rpc.akt.dev/rpc akashnet-2 os\nSet Additional Environment Variables\n\nVariableDescriptionRecommended ValueAKASH_GASGas limit to set per-transactionautoAKASH_GAS_ADJUSTMENTAdjustment factor to be multiplied against the estimate1.25AKASH_GAS_PRICESGas prices in decimal format to determine transaction fee0.025uaktAKASH_SIGN_MODESignature modeamino-json\nexport AKASH_GAS=autoexport AKASH_GAS_ADJUSTMENT=1.25export AKASH_GAS_PRICES=0.025uaktexport AKASH_SIGN_MODE=amino-json\nCheck your Account Balance\nTerminal windowprovider-services query bank balances --node $AKASH_NODE $AKASH_ACCOUNT_ADDRESS\nYou should see a response similar to:\nbalances:- amount: \"93000637\" denom: uaktpagination: next_key: null total: \"0\"\nNote: Balance is denominated in uAKT (AKT x 10^-6). In the example above, the account has a balance of 93 AKT.\nYour account must have a minimum balance of 0.5 AKT to create a deployment.\n\nAuthentication\nAkash provider services support two authentication methods:\nJWT Authentication (Default - Recommended)\nJWT (JSON Web Tokens) is the default and recommended authentication method for provider-services v0.10.0+.\nAdvantages:\n\nNo blockchain transactions required\nNo certificate expiration to manage\nSimpler setup\nNo additional costs\n\nJWT tokens are automatically generated and managed by provider-services CLI. No setup required!\nWhen you run deployment commands, the CLI automatically:\n\nSigns requests with your account’s private key\nCreates JWT tokens\nSends authenticated requests to providers\n\nYou’re ready to deploy! Jump to Next Steps.\n\nmTLS Certificate Authentication (Optional)\nmTLS (mutual TLS) certificates are an alternative authentication method.\nWhen to use mTLS:\n\nYou require certificate-based authentication\nYou’re integrating with systems that require X.509 certificates\nYou prefer blockchain-stored credentials\n\nGenerate Certificate\nprovider-services tx cert generate client --from $AKASH_KEY_NAME\nNote: If it errors with Error: certificate error: cannot overwrite certificate, add --overwrite flag.\nPublish Certificate to Blockchain\nprovider-services tx cert publish client --from $AKASH_KEY_NAME\nCertificate Notes:\n\nCertificates cost transaction fees (~0.01 AKT)\nValid for one year, then must be renewed\nStored on the Akash blockchain\nCan be revoked and regenerated\n\nNext Steps\nNow that you’re set up, you can:\n\nCLI Configuration - Configure networks and advanced settings\nCLI Commands Reference - Learn all available commands\nCore Concepts - Understand how Akash works\n\nTroubleshooting\n”command not found: provider-services”\nThe binary isn’t in your PATH. Try:\nTerminal window# Find where it's installedwhich provider-services\n# Add to PATH (Linux/macOS)export PATH=$PATH:/path/to/provider-services\n“account not found”\nYour wallet hasn’t been created or funded yet. Go back to Create an Account and Fund your Account.\n”insufficient fees”\nIncrease your gas prices:\nTerminal windowexport AKASH_GAS_PRICES=0.05uakt\nRPC Node Issues\nIf the default RPC node is down, try an alternative:\nTerminal windowexport AKASH_NODE=https://rpc.akt.dev/rpc# orexport AKASH_NODE=https://akash-rpc.polkachu.com:443\n\nNeed Help?\n\nAkash Discord - Get help from the community\nGitHub Issues - Report bugs\n\nEdit page on github\n Commands Reference Configuration","tokens":1723,"squid":"spider-03","role":"Compute Spider","at":1791347813786,"hash":"17ba822250409cc225c8fb1fff907282fe31b0de"}
{"url":"https://forum.across.to/t/what-the-token-does/52/19","domain":"forum.across.to","title":"What the token does? - Tokenomics (old) - Across Protocol","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 read \n\n 4\n min\n\n Nov 2021\n\n 19 / 26\n\n Jan 2022\n\n Apr 2022\n\n Load more posts above\n\n post by fommes.eth on Nov 17, 2021\n\n fommes.eth\n\n Imho there is no point in holding the Across token for fees reduction. I imagine a tipical Across user will not bridge all the time, just looking at the general roadmap/POV that Eth mainnet is becoming solely/mostly just the settlement layer, already in the coming months ppl will use more frequent L2s and withdraw back sometimes.\n\n post by fommes.eth on Nov 17, 2021\n\n fommes.eth\n\n I propose the Across token to accrue fees for holders instead.\n\n post by Robot on Nov 17, 2021\n\n Robot\n\n fommes.eth\n\n Surely the more utility the better and i’m sure Across will have to go L2 to L2 in the end\n\n post by Sanguine on Nov 17, 2021\n\n Sanguine\n\n Kastormagic\n\n I think that token is needed for the DAO in the first place. It is not even necessary that it have economic value in the form of receiving % from commissions for the interaction of other users with the protocol. First of all, a token is a symbol. The more successful the project is, the more people want to be involved in it through the token.\n\n post by jotatotal on Nov 17, 2021\n\n jotatotal\n\n I would suggest that a part of the fees goes to the DAO treasury, and so increment value of DAO token. On the other hand I also consider that if the token is used to pay fees those fees get burned after that.\n\n post by fommes.eth on Nov 17, 2021\n\n fommes.eth\n\n Robot\n\n There are lots of L2 to L2 bridges already. Imho Across is unique in that sense and should aim to be the Go-To for fast+secure L1 withdrawals. There will always be a need for L1 withdrawals, even if Ethereum becomes mostly just an execution layer.\n\n post by Robot on Nov 17, 2021\n\n Robot\n\n Sanguine\n\n That’s not true go look at Ribbon finance and their token launch people bought and it non-stop gets called a useless govenunce token, Ribbon is very successful with about $200m TVL but the token price don’t reflect that\n\n post by Solace on Nov 17, 2021\n\n Solace\n\n Completely agree with /u/fojo’s post above - this is an important discussion regarding the token launch.\nWould the token be used strictly for governance, to pay out fees, or as a safety module? These do not necessarily have to mutually exclusive, and it’s possible that the token could incorporate all three - but as far as emission and distribution goes, it’s pretty important to make at least one a priority.\nIf choosing a governance route, liquidity incentives and a safety module could also be implemented at a later stage via a proposal. But this would remain subject to a vote, which could take some time to pass.\nOn the topic of liquidity incentives, these will likely remain temporary in order to bootstrap liquidity though there are plenty of examples of where artificially incentivizing usage has led to users with short-term outlooks farming these pools and draining the liquidity afterwards.\nAs far as using the token to incentivize usage goes, one approach could be to provide a gas fee rebate to users that bridge from L1 → L2 using the Arbitrum/optimism native bridge and bridge back to L1 using Across. This could be implemented similarly to Balancer’s gas fee rebate: [Proposal] Balancer Exchange Gas Reimbursement - Proposals - Balancer\nWe could get creative with some ways in order to incentivize usage rather than only incentivizing the LPs (as they will receive a fee of the transaction either way).\n\n post by Sanguine on Nov 17, 2021\n\n Sanguine\n\n Robot\n\n Maybe so. Indeed, in our time, the success of the project for the crowd is the endless rise in the price of the token. And if the price of a token does not grow infinitely, then they begin to call it “useless governance token”. But if the project starts to hype and the price rises, then it abruptly turns into an “incredibly useful governance token”.\n\n post by eqing.eth on Nov 21, 2021\n\n eqing.eth\n\n Kastormagic\n\n Tokens will attract some early users, which is necessary!At the initial stage of the project, it is necessary to attract users by token airdrop and distinguish real users.\n\n post by Alisa on Nov 22, 2021\n\n Alisa\n\n Acrosit is to establish a Dao and become a token of community governance. However, empowering and offsetting gas is a good suggestion, which can prevent members from throwing it out too early. However, it also has some disadvantages., if it is a gas, will it affect the development of community autonomy? But if it is only from the perspective of token, the more successful across is, the better the development of Dao will be, Of course, it will attract more people to participate\n\n 9 days later\n\n post by MrHeviDi on Dec 1, 2021\n\n MrHeviDi\n\n fommes.eth\n\n But there will be other protocals/bridges to move funds from L2 to L1, so Across needs to atract users to use Across and maybe to hold Across token. Maybe, like someone before montioned, having Across token will give you some fee reduction or something like that.\n\n 2 months later\n\n post by jotatotal on Jan 26, 2022\n\n jotatotal\n\n Solace\n\n What about giving the holders of the token , despite a fee reduction , a share of the fee according to their holdings?\n\n post by lawpanda.eth on Jan 26, 2022\n\n lawpanda.eth\n\n That would functionally be an ‘x’ token, like xSushi, dQuick, etc. On the legal end it creates regulatory questions because it resembles a security. But it is a more functional mechanism for facilitating adoption/use.\n\n 2 months later\n\n post by J.Berg on Mar 18, 2022\n\n J.Berg\n\n Creating a token enables the DAO to have an asset (without investing) that can be used to fund projects/guilds for effort the DAO needs (both maintenance and major initiatives), as well as contribute to internal DAO economics.\n–Paying core team members for their efforts\n–Paying for work done by Guilds and their squads\n–Internal DAO markets and trade\n–Bounties\nWill the Across token be used strictly for governance? or will it be used as money? or both?\nWould it be a monetary asset and a governance token to be used to fund and vote? Some DAO’s treat their governance token as ONLY that, and it actively drives down it’s valuation.\nIf its money then the DAO as an organization has the challenges of both a startup and an emerging digital nationstate in that we have to find and create revenue streams and manage costs, as well as drive the use and acceptance of our denomination both internally and externally.\nI think long term will be based on the size of the treasury it controls and the useful things you can do with it. As a result, I think the focus should be on activities that generate on-chain revenue for the DAO and ways to make the token useful stake it, collateral, ect.\nHow to pay contributors is definitely an important factor to consider. Without contributors, we won’t be able to do any of the above. Part of me feels that if your contributing, it should be because you believe in the DAO long term and shouldn’t expect an immediate monetary reward. The other part of me thinks that contributor renumeration is something that needs to be painstakingly thought out to retain talent and pay our people\n\n post by heybeo on Mar 22, 2022\n\n heybeo\n\n It would be nice to use bridges on the same platform as well as to create a nice dex.\nTrading pairs, for example acx-uma, are used as fees and distributed to token holders.\nacx-x\nacx-y\nacx-z\nJust a simple idea as liquidity addition commissions are burned\n\n post by altsilversurfer.nft on Mar 26, 2022\n\n altsilversurfer.nft\n\n Tokenomics can be viewed as a function of 3 main parameters, token launch (model, vesting scheme, market cap), utility, and inflation. Utility is one of the major drivers of adoption and appreciation of value. Thus, the more utilities, the best. Governance will be the first and more obvious utility of $ACX, but we must think beyond this to achieve sustainnability. This is the ultimate goal. And this is also the common interest of all involved. People that are waiting for profits will be maximally rewarded if they be patient and contribute to protocol sustainnability. Across will be really BIG and this is not a fanboy statement. The major crosschain pipes will see in the future typical value movements that will far exceed those of the biggest centralized exchanges today.\n\n post by jeffrey on Mar 29, 2022\n\n jeffrey\n\n Token is share, it means users own the project\n\n 12 days later\n\n post by hescollazo on Apr 11, 2022\n\n hescollazo\n\n I agree with the use of the token as a payment mechanism for the protocol. The low fees will bring new users and money into the ecosystem. That it can be used in governance will incentivize use of the application and hodling of the asset. Ultimately the goal should be to give users the tools to discover new ways in which to generate positive cash flow and build wealth.\n\n 10 days later\n\n post by Ray_V on Apr 21, 2022\n\n Ray_V\n\n Would we introduce a single staking mechanism? In which we would offer our tokens as liquidity to the across protocol and earn APR either through the fees accrued by the protocol - or another more effective system? Would that be something considered?\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Initial thinking around token distribution\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 36\n\n Mar 2022\n\n Across Token Launch Proposal\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 214\n\n May 2022\n\n Across Token Launch Proposal v2\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 47\n\n Nov 2022\n\n Second ACX Drop\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 15\n\n Feb 2024\n\n Welcome to Across\n\n WELCOME 👋\n\n WELCOME 👋\n\n Nov 2022","tokens":2413,"squid":"spider-09","role":"Bridge Spider","at":1791347814139,"hash":"41f7e36ee7e8b6e8fa71c9bcbad88373c52313cb"}
{"url":"https://research.arbitrum.io/t/submitting-transaction-bundles/75/5","domain":"research.arbitrum.io","title":"Submitting transaction bundles - Uncategorized - Arbitrum Research","text":"Uncategorized\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 5\n\n 2\n\n read \n\n 4\n min\n\n May 2022\n\n 5 / 15\n\n May 2022\n\n Aug 2025\n\n post by edfelten on May 21, 2022\n\n edfelten\n\n We’re considering adding a feature to the sequencer that allows clients to submit a bundle of transactions, that is, a set of multiple transactions, in a single submission. The sequencer would promise to include those transactions consecutively in its ordering, with no other transactions interleaved among them.\nThe sequencer already sequences transactions in the order they arrived at the sequencer, so the result would be as if all of the transactions in the bundle arrived consecutively. The bundles wouldn’t get earlier or later position in the sequence by virtue of being bundles. We wouldn’t guarantee that the transactions in a bundle will end up in the same block, only that no other user transactions will be between them.\nWe think this bundle functionality is useful for some use cases, for example to carry out a sequence of DeFi transactions that rely on an assumption that no other transactions intervene. It also makes some kinds of account abstraction approaches easier to implement.\nOf course we would limit the total size of bundles, or the total gas consumed by a bundle, to some reasonable limit.\nWe’re interested in hearing thoughts on this. Would you use it? Are there any constraints we should take into consideration?\n\n 5\n\n 2\n\n read \n\n 4\n min\n\n post by bbuddha on May 22, 2022\n\n bbuddha\n\n I like it! Could be useful for gasless transactions, in which one tx in the bundle pays gas for all of the other transactions. In addition, it would be cool to create programmability into the bundle submission for condition reversion of other transactions in the bundle revert and perhaps other powerful controls.\nAre you planning to include a way for transactions to figure out the contents of the bundle they are in (block.bundlehash)? If this was possible, along with the conditional reversion, you may be able to implement cross transaction flashloans! Just submit a bundle [flashLoan(), doStuff(), repay()], and the flashLoan() tx would have functionality to revert in case the repay() tx failed.\nOne concern is how trustless this is. Is the bundle not being broken up somehow ensured via changes to the fraud proof mechanism or is it based off of trust in the sequencer? There are scenarios in which it is detrimental to break up the bundle.\n\n post by edfelten on May 24, 2022\n\n edfelten\n\n We weren’t looking to change the semantics of execution on the chain, only how transactions are submitted. The transactions would still execute normally, without any additional affordances, so the only difference from normal submission would be that transactions in a bundle would run consecutively without any others interleaved between them (assuming an honest sequencer).\nStronger notions of bundling that change the execution model could accomplish more, but are a much heavier lift in terms of implementation, and would introduce incompatibilities with Ethereum.\n\n post by bertcmiller on May 31, 2022\n\n bertcmiller\n\n A really common use case for this would be bundling an approval and an action together, e.g. approving a router and making a swap, or approving a vault and depositing funds into it. In my opinion this is a really useful abstraction.\nOne thing that you should be mindful of is that this could change the security model of DeFi protocols. In particular, some contracts rely on the (bad) assumption that EOAs cannot atomically make many transactions in a row. If that assumption is broken then it might open up protocols to economic vulnerabilities. Many protocols with this assumption use require(msg.sender == tx.origin) to ensure that only EOAs are interacting with certain functions.\nAs far as I can tell DeFi protocols have moved away from this assumption because it’s never been a sound one to make in the long run. But opening up the space for atomic EOA execution does change the security model for some contracts, so you should make sure to communicate that if you make this change.\n\n post by edfelten on May 31, 2022\n\n edfelten\n\n We would not guarantee that the transactions in a bundle execute as a single atomic unit. We would only guarantee that no other transactions come between them. It would still be possible for some transactions in the bundle to revert while others succeed.\n\n post by eleglenctic on Jun 1, 2022\n\n eleglenctic\n\n Would all transactions in a bundle be required to share the same sender address, or can clients indiscriminately reorder bundles of arbitrary transactions before submitting them to the sequencer? Would submitting sequencer bundles be permissionless? How do we define client in this context, is it any transaction signer or is it only a specific piece of Arbitrum infrastructure? Considering that the policy of the sequencer is “first come, first serve,” it’s important to understand if a third party service can violate that policy within a bundle, for better or for worse.\nThere might be an engineering hurdle for composing sequencer bundles from regular user wallets, because I think there isn’t a universal method that wallets use to handle setting a transaction’s nonce or a universal method for when to broadcast a signed transaction.\nIt seems like if an average user wanted to submit a bundle, they would require an intermediary that intercepts their signed transactions until they submit their entire bundle, because I think the default behavior of e.g. Metamask is to submit a transaction to the rpc endpoint as soon as it is signed.\nIn theory, a static webpage could allow users to aggregate signed transactions into a bundle using the eth_sign rpc method to sign raw transaction hashes, but that would be a downgrade to the user’s experience and would empower phishing scams.\nOverall, I’m curious if access to submitting transaction bundles would be offered exclusively to some restricted definition of “clients,” or if this also is meant to provide access directly to individuals who might want to submit an approve and deposit bundle. Arbitrum is designed to offer a seamless experience to Ethereum users, and the approach to integrating sequencer bundles into existing wallets will be important if users are given direct access to this service.\n\n post by edfelten on Jun 2, 2022\n\n edfelten\n\n The version of this that seems the most useful and straightforward to implement is to (1) not restrict which transactions can be submitted in the same bundle (except for limits on total bundle size), and (2) not restrict who can submit bundles. That is, a bundle is just another way to submit a set of multiple transactions, with the same result as if you submitted the transactions one at a time and it turned out that no other transactions arrived in between yours.\nIf you route your transactions through a third party, it could reorder them within a bundle. That’s basically the same issue you have now if you submit multiple transactions through a third party–it can reorder them if it wants.\nAlso, a dishonest sequencer could reorder or drop the transactions within your bundle. Again, that’s basically what it can already do to transactions submitted one at a time.\n\n 4 months later\n\n post by stonecoldpat on Oct 8, 2022\n\n stonecoldpat\n\n Seems like a nobrainer to support a feature like this. I wouldn’t optimise for making it trustless since you are already trusting the sequencer.\n\n 4 months later\n\n post by web3fishermen on Jan 25, 2023\n\n web3fishermen\n\n @stonecoldpat What do you mean? Could you clarify your statement pls\n\n 2 months later\n\n post by hossein_alavi on Mar 19, 2023\n\n hossein_alavi\n\n Hi!\nI wanted to check if the idea of bundles transactions is implemented or not, and if yes is there a document on how to use it?\n\n 1 month later\n\n post by pahakow on Apr 25, 2023\n\n pahakow\n\n nice\nOne concern is how trustless this is. Is the bundle not being broken up somehow ensured via changes to the fraud proof mechanism or is it based off of trust in the sequencer? There are scenarios in which it is detrimental to break up the bundle.\n\n post by edfelten on Apr 26, 2023\n\n edfelten\n\n The easiest way to do this would be to trust the sequencer to not separate the transactions in the bundle. This is straightforward to implement because one would just need to add an RPC to submit a set of transactions that are meant to be a bundle. Nothing on-chain would need to change.\nEnforcing bundling is more difficult because it would need to be the case that the sequencer cannot (say) extract one transaction from the bundle and just post that one. And that, in turn, seems to require that the transactions in the bundle can’t be separable from each other. That means, for example, that it won’t work to include each transaction’s data in encodable format along with a signature on that one transaction. Instead, the transactions in the bundle would somehow need to be entangled so that each one is invalid unless attached to the others.\nOne way to build non-separable transactions is to use a facility like ERC-4337 account abstraction, which is currently on Arbitrum’s testnet at the moment.\n\n 2 years later\n\n post by cmatt on Jul 16, 2025\n\n cmatt\n\n Has something like this been implemented or is still considered? Or has this been dropped because there are by now other methods, such as the mentioned way via account abstraction, via which something similar can be achieved? It seems to me ability to directly submit bundles to the sequencer could still be useful.\n\n 26 days later\n\n post by kakia on Aug 12, 2025\n\n kakia\n\n It is not implemented at the moment. Other methods may come close to implementing bundling, but nothing guarantees it. What useful cases do you have in mind for this?\n\n post by cmatt on Aug 15, 2025\n\n cmatt\n\n Thanks for the answer! I don’t have any specific use-case in mind. We have been looking into what sequencer commitments could enable for rollups (specifically OP, see https://mirror.xyz/preconf.eth/UoMhzBvWihwLLXuUYywjXLg4JmymEeC2jqlAeIRBD_Q) and cryptoeconomically protected bundles would be one of the things. Since people here seemed interested, we wondered what the status was. One possible use-case would be that you want to migrate some LP position from Uniswap V2 to V3 and you want closing the V2 and opening the V3 to be bundled since other trades in-between could unbalance your 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 Bundle imitation on Arbitrum\n\n Uncategorized\n\n defi,tx-ordering\n\n 3\n\n 1.9k\n\n Oct 2023\n\n Transaction ordering policy\n\n Uncategorized\n\n 10\n\n 8.6k\n\n Mar 2023\n\n Hybrid transaction ordering policy\n\n Uncategorized\n\n tx-ordering,sequencer\n\n 6\n\n 2.9k\n\n Nov 2022\n\n Proposed design for Timeboost\n\n Uncategorized\n\n 12\n\n 3.3k\n\n Jun 2024\n\n Arbitrum vs Optimism\n\n Uncategorized\n\n defi\n\n 1\n\n 2.6k\n\n Mar 2023","tokens":2729,"squid":"spider-01","role":"Chain Spider","at":1791347818048,"hash":"078bde39138874189aa78b5cf05345197abbb323"}
{"url":"https://akash.network/docs/developers/deployment/authz/","domain":"akash.network","title":"AuthZ & Fee Grants - Delegated Permissions | Akash Network - Your Guide to Decentralized Cloud","text":"AuthZ & Fee Grants - Delegated Permissions Enable secure, delegated deployment management using Cosmos SDK AuthZ and Fee Grants.\nAuthZ (Authorization) allows you to grant other accounts permission to perform actions on your behalf, while Fee Grants let you pay transaction fees for those accounts. Together, they enable frictionless team collaboration, automation, and third-party integrations without sharing private keys or requiring team members to hold AKT.\n\nWhat are AuthZ and Fee Grants?\nAuthZ (Authorization)\nAuthZ is a Cosmos SDK module that enables permission delegation. With AuthZ, you can:\n\nGrant deployment permissions to team members\nEnable automation without exposing your private key\nAllow third-party services to deploy on your behalf\nSet spending limits and expiration dates\nRevoke permissions at any time\n\nKey Concept: The account that grants permission is called the granter, and the account that receives permission is called the grantee.\nFee Grants (Fee Allowances)\nFee Grants allow you to pay transaction fees for other accounts. With Fee Grants, you can:\n\nPay gas fees for team members - They don’t need AKT for transactions\nEnable frictionless onboarding - New users can deploy immediately\nSupport automation - CI/CD pipelines work without funded wallets\nSet spending limits - Control fee expenditure\nUse time-limited grants - Fees allowances can expire\n\nBest Practice: Combine AuthZ + Fee Grants for complete delegation - grantees can deploy on your behalf, and you pay all costs (deposits + fees).\n\nCommon Use Cases\nTeam Collaboration\nAllow team members to create and manage deployments on your behalf:\n\nDevOps engineers can deploy without accessing your wallet\nMultiple team members can manage the same deployments\nSeparate billing account from operational accounts\n\nAutomated Deployments\nEnable CI/CD pipelines and automation tools:\n\nGitHub Actions can deploy on your behalf\nDeployment services can manage your infrastructure\nScripts can update deployments automatically\n\nThird-Party Services\nAllow deployment platforms to deploy for you:\n\nAkash Console can deploy using your permissions\nDeployment management tools\nMulti-cloud orchestration platforms\n\nSpending Controls\nSet limits on what grantees can do:\n\nMaximum AKT spending per deployment\nNumber of deployments allowed\nTime-limited permissions\n\nHow AuthZ Works\nPermission Flow\n\nGranter (you) grants specific permissions to a Grantee\nGrantee can execute authorized actions on behalf of the Granter\nTransactions appear on-chain as coming from the Granter\nGranter pays for deposits and fees\nGranter can revoke permissions at any time\n\nPermission Types\nAuthZ on Akash supports these message types:\n\n/akash.deployment.v1beta3.MsgCreateDeployment - Create new deployments\n/akash.deployment.v1beta3.MsgUpdateDeployment - Update existing deployments\n/akash.deployment.v1beta3.MsgCloseDeployment - Close deployments\n/akash.market.v1beta3.MsgCreateLease - Create leases with providers\n/akash.market.v1beta3.MsgWithdrawLease - Withdraw from leases\n\nGranting Permissions\nGrant All Deployment Permissions\nAllow a grantee to fully manage deployments:\nTerminal windowprovider-services tx authz grant <grantee-address> generic \\ --msg-type /akash.deployment.v1beta3.MsgCreateDeployment \\ --from <your-wallet> \\ --fees 5000uakt\nGrant with Spending Limit\nLimit how much AKT the grantee can spend:\nTerminal windowprovider-services tx authz grant <grantee-address> generic \\ --msg-type /akash.deployment.v1beta3.MsgCreateDeployment \\ --spend-limit 100000000uakt \\ --from <your-wallet> \\ --fees 5000uakt\nNote: Spend limit is in uAKT (100000000uakt = 100 AKT)\nGrant with Expiration\nSet an expiration time for permissions:\nTerminal windowprovider-services tx authz grant <grantee-address> generic \\ --msg-type /akash.deployment.v1beta3.MsgCreateDeployment \\ --expiration 1704067200 \\ --from <your-wallet> \\ --fees 5000uakt\nNote: Expiration is a Unix timestamp (seconds since epoch)\nGrant Multiple Permissions\nTo grant multiple permissions, execute multiple grant commands:\nTerminal window# Grant deployment creationprovider-services tx authz grant <grantee-address> generic \\ --msg-type /akash.deployment.v1beta3.MsgCreateDeployment \\ --from <your-wallet> --fees 5000uakt\n# Grant deployment updatesprovider-services tx authz grant <grantee-address> generic \\ --msg-type /akash.deployment.v1beta3.MsgUpdateDeployment \\ --from <your-wallet> --fees 5000uakt\n# Grant deployment closureprovider-services tx authz grant <grantee-address> generic \\ --msg-type /akash.deployment.v1beta3.MsgCloseDeployment \\ --from <your-wallet> --fees 5000uakt\n# Grant lease creationprovider-services tx authz grant <grantee-address> generic \\ --msg-type /akash.market.v1beta3.MsgCreateLease \\ --from <your-wallet> --fees 5000uakt\n\nFee Grants\nFee grants allow you to pay transaction fees on behalf of other accounts. This is especially useful when combined with AuthZ, so grantees don’t need their own AKT for gas fees.\nWhat are Fee Grants?\nFee grants (also called fee allowances) enable:\n\nPay gas fees for team members - They don’t need AKT for transactions\nEnable frictionless automation - CI/CD pipelines work without funded wallets\nOnboard users easily - New users can deploy without buying AKT first\nSet spending limits - Control how much can be spent on fees\nTime-limited grants - Fees allowances can expire\n\nKey Concept: The account paying fees is the granter, and the account using the fee allowance is the grantee.\n\nGrant Basic Fee Allowance\nAllow an account to use your AKT for gas fees:\nTerminal windowprovider-services tx feegrant grant <granter-address> <grantee-address> \\ --from <your-wallet> \\ --fees 5000uakt\nThis grants unlimited fee usage until revoked.\n\nGrant Fee Allowance with Spending Limit\nLimit how much AKT can be spent on fees:\nTerminal windowprovider-services tx feegrant grant <granter-address> <grantee-address> \\ --spend-limit 1000000uakt \\ --from <your-wallet> \\ --fees 5000uakt\nExample: 1000000uakt = 1 AKT total fee limit\n\nGrant Fee Allowance with Expiration\nSet when the fee grant expires:\nTerminal windowprovider-services tx feegrant grant <granter-address> <grantee-address> \\ --expiration \"2025-12-31T23:59:59Z\" \\ --from <your-wallet> \\ --fees 5000uakt\nNote: Use ISO 8601 format for expiration dates\n\nGrant Fee Allowance with Periodic Limit\nAllow a specific amount per time period (e.g., daily limit):\nTerminal windowprovider-services tx feegrant grant <granter-address> <grantee-address> \\ --period 86400 \\ --period-limit 100000uakt \\ --from <your-wallet> \\ --fees 5000uakt\nParameters:\n\n--period 86400 - 86400 seconds = 24 hours\n--period-limit 100000uakt - 0.1 AKT per day\n\nThis resets every 24 hours, allowing the grantee to spend up to 0.1 AKT on fees each day.\n\nCombining Fee Grants with AuthZ\nThe most powerful pattern: grant both permissions AND fee allowance:\nTerminal window# Step 1: Grant fee allowanceprovider-services tx feegrant grant <your-address> <grantee-address> \\ --spend-limit 10000000uakt \\ --expiration \"2025-12-31T23:59:59Z\" \\ --from <your-wallet> \\ --fees 5000uakt\n# Step 2: Grant deployment permissionprovider-services tx authz grant <grantee-address> generic \\ --msg-type /akash.deployment.v1beta3.MsgCreateDeployment \\ --from <your-wallet> \\ --fees 5000uakt\nResult: The grantee can create deployments on your behalf, and you pay for both the deposit AND the gas fees.\n\nQuery Fee Grants\nCheck fee grants you’ve given:\nTerminal windowprovider-services query feegrant grants-by-granter <your-address>\nCheck fee grants given to you:\nTerminal windowprovider-services query feegrant grants-by-grantee <grantee-address>\nCheck specific grant:\nTerminal windowprovider-services query feegrant grant <granter-address> <grantee-address>\n\nRevoke Fee Grant\nRemove a fee allowance:\nTerminal windowprovider-services tx feegrant revoke <granter-address> <grantee-address> \\ --from <your-wallet> \\ --fees 5000uakt\n\nUsing Fee Grants\nWhen a grantee has a fee grant, they specify the granter’s address:\nTerminal window# Execute transaction using fee grantprovider-services tx deployment create deploy.yaml \\ --from <grantee-wallet> \\ --fee-granter <granter-address>\nNote: The --fee-granter flag tells the network to use the granter’s fee allowance.\nFor SDK Integration:\nSee AuthZ & Fee Grants SDK for programmatic usage with Go and JavaScript/TypeScript.\n\nFee Grant Best Practices\n1. Always Set Limits\nNever grant unlimited fee allowances:\nTerminal window# Bad: Unlimited feesprovider-services tx feegrant grant <granter> <grantee> --from <wallet>\n# Good: Limited feesprovider-services tx feegrant grant <granter> <grantee> \\ --spend-limit 5000000uakt \\ --expiration \"2025-12-31T23:59:59Z\" \\ --from <wallet>\n2. Use Periodic Limits for Long-Term Grants\nFor ongoing automation:\nTerminal window# Grant 1 AKT per week for feesprovider-services tx feegrant grant <granter> <grantee> \\ --period 604800 \\ --period-limit 1000000uakt \\ --from <wallet>\n3. Monitor Fee Grant Usage\nRegularly check how much has been spent:\nTerminal windowprovider-services query feegrant grant <granter> <grantee>\n4. Revoke Unused Grants\nRemove grants when no longer needed:\nTerminal windowprovider-services tx feegrant revoke <granter> <grantee> --from <wallet>\n\nCommon Fee Grant Scenarios\nScenario 1: CI/CD Pipeline\nGrant your CI/CD bot both permissions and fees:\nTerminal window# Grant fee allowance (0.5 AKT per day)provider-services tx feegrant grant <your-address> <bot-address> \\ --period 86400 \\ --period-limit 500000uakt \\ --from <your-wallet>\n# Grant deployment permissionsprovider-services tx authz grant <bot-address> generic \\ --msg-type /akash.deployment.v1beta3.MsgCreateDeployment \\ --from <your-wallet>\nScenario 2: Team Member Onboarding\nNew team members can deploy immediately:\nTerminal window# Grant fee allowance (10 AKT limit, 30 days)provider-services tx feegrant grant <your-address> <new-member> \\ --spend-limit 10000000uakt \\ --expiration \"2025-01-31T23:59:59Z\" \\ --from <your-wallet>\n# Grant full deployment accessprovider-services tx authz grant <new-member> generic \\ --msg-type /akash.deployment.v1beta3.MsgCreateDeployment \\ --from <your-wallet>\nScenario 3: Temporary Contractor\nContractor needs limited access for a project:\nTerminal window# Grant fee allowance (1 AKT total, expires in 60 days)provider-services tx feegrant grant <your-address> <contractor> \\ --spend-limit 1000000uakt \\ --expiration \"2025-03-01T23:59:59Z\" \\ --from <your-wallet>\n# Grant deployment permissions with same expirationprovider-services tx authz grant <contractor> generic \\ --msg-type /akash.deployment.v1beta3.MsgCreateDeployment \\ --expiration 1740787200 \\ --from <your-wallet>\n\nFee Grant Troubleshooting\n“fee payer does not have a fee grant”\nThe grantee forgot to specify --fee-granter:\nTerminal window# Missing fee-granter flagprovider-services tx deployment create deploy.yaml --from <grantee>\n# Correct usageprovider-services tx deployment create deploy.yaml \\ --from <grantee> \\ --fee-granter <granter>\n“fee allowance not found”\nThe fee grant doesn’t exist or was revoked. Check:\nTerminal windowprovider-services query feegrant grant <granter> <grantee>\n“fee allowance limit exceeded”\nThe spending limit has been reached. Either:\n\nWait for periodic limit to reset\nGranter must increase the limit\nGranter must grant new allowance\n\n“fee allowance expired”\nThe expiration time has passed. Granter must grant a new allowance:\nTerminal windowprovider-services tx feegrant grant <granter> <grantee> \\ --spend-limit 1000000uakt \\ --expiration \"2025-12-31T23:59:59Z\" \\ --from <wallet>\n\nUsing Granted Permissions\nExecute as Grantee\nOnce granted permission, the grantee can execute transactions on behalf of the granter:\nTerminal window# Create deployment as grantee on behalf of granterprovider-services tx authz exec \\ provider-services tx deployment create deploy.yaml \\ --from <grantee-wallet> \\ --fees 5000uakt\nImportant: The deployment will be owned by the granter, not the grantee.\nCheck Your Grants\nView permissions granted to you:\nTerminal windowprovider-services query authz grants-by-grantee <your-address>\nView permissions you’ve granted to others:\nTerminal windowprovider-services query authz grants-by-granter <your-address>\nView specific grant between two addresses:\nTerminal windowprovider-services query authz grants <granter-address> <grantee-address>\n\nRevoking Permissions\nRevoke Specific Permission\nRemove a specific permission:\nTerminal windowprovider-services tx authz revoke <grantee-address> \\ /akash.deployment.v1beta3.MsgCreateDeployment \\ --from <your-wallet> \\ --fees 5000uakt\nRevoke All Permissions\nTo revoke all permissions, revoke each message type individually.\n\nSDK Integration\nFor programmatic AuthZ and Fee Grant management, see:\n→ AuthZ & Fee Grants SDK Documentation\nThe SDK guide covers:\n\nGranting permissions programmatically\nExecuting transactions with granted permissions\nManaging fee allowances via code\nQuerying and revoking grants\nBest practices and error handling\nFull Go and JavaScript/TypeScript examples\n\nBest Practices\nSecurity\n\nGrant Minimal Permissions - Only grant the specific permissions needed\nUse Expiration Dates - Set expiration times for temporary access\nSet Spending Limits - Limit potential losses from compromised grantee accounts\nRegular Audits - Regularly check and revoke unused grants\nSeparate Accounts - Use different accounts for different purposes\n\nTeam Management\n\nDocument Grants - Keep a record of who has what permissions\nRole-Based Access - Create accounts with specific roles (deployer, admin, etc.)\nOnboarding/Offboarding - Grant permissions on hire, revoke on departure\nAudit Trail - Monitor grantee actions via blockchain transactions\n\nAutomation\n\nDedicated Service Accounts - Create accounts specifically for automation\nRotate Keys - Regularly rotate grantee keys for security\nMonitor Spending - Track deployment costs from automated systems\nError Handling - Handle authorization errors gracefully in scripts\n\nCommon Scenarios\nScenario 1: CI/CD Pipeline\nGoal: Allow GitHub Actions to deploy on your behalf\nSteps:\n\nCreate a new wallet for GitHub Actions\nFund it with enough AKT for gas fees (0.1 AKT minimum)\nGrant deployment permissions:\n\nTerminal windowprovider-services tx authz grant <github-actions-address> generic \\ --msg-type /akash.deployment.v1beta3.MsgCreateDeployment \\ --from <your-wallet>\n\nIn your CI/CD pipeline, use the grantee wallet to deploy\n\nScenario 2: Team Deployment Management\nGoal: Allow DevOps team to manage deployments\nSteps:\n\nCreate or identify team member wallets\nGrant comprehensive permissions:\n\nTerminal window# For each team memberfor MSG_TYPE in \\ /akash.deployment.v1beta3.MsgCreateDeployment \\ /akash.deployment.v1beta3.MsgUpdateDeployment \\ /akash.deployment.v1beta3.MsgCloseDeployment \\ /akash.market.v1beta3.MsgCreateLeasedo provider-services tx authz grant <team-member-address> generic \\ --msg-type $MSG_TYPE \\ --from <your-wallet> \\ --fees 5000uaktdone\nScenario 3: Temporary Contractor Access\nGoal: Give a contractor temporary deployment access\nSteps:\n\nGrant permissions with expiration:\n\nTerminal window# Set expiration to 30 days from nowEXPIRATION=$(date -d '+30 days' +%s)\nprovider-services tx authz grant <contractor-address> generic \\ --msg-type /akash.deployment.v1beta3.MsgCreateDeployment \\ --expiration $EXPIRATION \\ --spend-limit 50000000uakt \\ --from <your-wallet>\n\nPermissions automatically expire after 30 days\n\nTroubleshooting\n”authorization not found”\nCause: No grant exists between granter and grantee for that message type\nSolution: Check grants with query authz grants and create if needed\n”failed to execute message; message index: 0: unauthorized”\nCause: Grant may have expired or been revoked\nSolution: Verify grant still exists and is not expired\n”insufficient fees”\nCause: Grantee account doesn’t have enough AKT for gas\nSolution: Fund the grantee account with AKT for transaction fees\n”account sequence mismatch”\nCause: Multiple transactions sent simultaneously\nSolution: Wait for previous transaction to complete or use sequence numbers\n\nSecurity Considerations\nRisks\n\nCompromised Grantee - If a grantee’s private key is compromised, they can act on your behalf\nNo Spending Limit - Without limits, grantee can spend all your AKT\nPermanent Access - Grants without expiration last forever\n\nMitigations\n\nUse Spending Limits - Always set reasonable limits\nSet Expirations - Use time-limited grants when possible\nMonitor Activity - Watch for unexpected deployments\nRevoke Immediately - Revoke grants as soon as they’re no longer needed\nSeparate Funds - Keep limited funds in accounts that grant permissions\n\nRelated Documentation\n\nCLI Reference - Complete CLI commands\nSDK Documentation - Programmatic AuthZ usage\nSDL Examples - 290+ deployment examples\n\nAdditional Resources\n\nCosmos SDK AuthZ Module: docs.cosmos.network/sdk/v0.53/build/modules/authz\nCosmos SDK FeeGrant Module: docs.cosmos.network/sdk/v0.53/build/modules/feegrant\nAkash GitHub: github.com/akash-network/node\nDiscord: discord.akash.network - #developers channel\n\nNeed Help?\n\nDiscord: discord.akash.network - #developers channel\nGitHub Support: github.com/akash-network/support/issues\n\nEdit page on github\n Advanced Features Guides","tokens":4300,"squid":"spider-03","role":"Compute Spider","at":1791347823620,"hash":"0153c10f4844f82560be897f38b2fabc52064279"}
{"url":"https://forum.across.to/t/what-the-token-does/52/21","domain":"forum.across.to","title":"What the token does? - Tokenomics (old) - Across Protocol","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 read \n\n 4\n min\n\n Nov 2021\n\n 21 / 26\n\n Mar 2022\n\n Apr 2022\n\n Load more posts above\n\n post by fommes.eth on Nov 17, 2021\n\n fommes.eth\n\n Imho there is no point in holding the Across token for fees reduction. I imagine a tipical Across user will not bridge all the time, just looking at the general roadmap/POV that Eth mainnet is becoming solely/mostly just the settlement layer, already in the coming months ppl will use more frequent L2s and withdraw back sometimes.\n\n post by fommes.eth on Nov 17, 2021\n\n fommes.eth\n\n I propose the Across token to accrue fees for holders instead.\n\n post by Robot on Nov 17, 2021\n\n Robot\n\n fommes.eth\n\n Surely the more utility the better and i’m sure Across will have to go L2 to L2 in the end\n\n post by Sanguine on Nov 17, 2021\n\n Sanguine\n\n Kastormagic\n\n I think that token is needed for the DAO in the first place. It is not even necessary that it have economic value in the form of receiving % from commissions for the interaction of other users with the protocol. First of all, a token is a symbol. The more successful the project is, the more people want to be involved in it through the token.\n\n post by jotatotal on Nov 17, 2021\n\n jotatotal\n\n I would suggest that a part of the fees goes to the DAO treasury, and so increment value of DAO token. On the other hand I also consider that if the token is used to pay fees those fees get burned after that.\n\n post by fommes.eth on Nov 17, 2021\n\n fommes.eth\n\n Robot\n\n There are lots of L2 to L2 bridges already. Imho Across is unique in that sense and should aim to be the Go-To for fast+secure L1 withdrawals. There will always be a need for L1 withdrawals, even if Ethereum becomes mostly just an execution layer.\n\n post by Robot on Nov 17, 2021\n\n Robot\n\n Sanguine\n\n That’s not true go look at Ribbon finance and their token launch people bought and it non-stop gets called a useless govenunce token, Ribbon is very successful with about $200m TVL but the token price don’t reflect that\n\n post by Solace on Nov 17, 2021\n\n Solace\n\n Completely agree with /u/fojo’s post above - this is an important discussion regarding the token launch.\nWould the token be used strictly for governance, to pay out fees, or as a safety module? These do not necessarily have to mutually exclusive, and it’s possible that the token could incorporate all three - but as far as emission and distribution goes, it’s pretty important to make at least one a priority.\nIf choosing a governance route, liquidity incentives and a safety module could also be implemented at a later stage via a proposal. But this would remain subject to a vote, which could take some time to pass.\nOn the topic of liquidity incentives, these will likely remain temporary in order to bootstrap liquidity though there are plenty of examples of where artificially incentivizing usage has led to users with short-term outlooks farming these pools and draining the liquidity afterwards.\nAs far as using the token to incentivize usage goes, one approach could be to provide a gas fee rebate to users that bridge from L1 → L2 using the Arbitrum/optimism native bridge and bridge back to L1 using Across. This could be implemented similarly to Balancer’s gas fee rebate: [Proposal] Balancer Exchange Gas Reimbursement - Proposals - Balancer\nWe could get creative with some ways in order to incentivize usage rather than only incentivizing the LPs (as they will receive a fee of the transaction either way).\n\n post by Sanguine on Nov 17, 2021\n\n Sanguine\n\n Robot\n\n Maybe so. Indeed, in our time, the success of the project for the crowd is the endless rise in the price of the token. And if the price of a token does not grow infinitely, then they begin to call it “useless governance token”. But if the project starts to hype and the price rises, then it abruptly turns into an “incredibly useful governance token”.\n\n post by eqing.eth on Nov 21, 2021\n\n eqing.eth\n\n Kastormagic\n\n Tokens will attract some early users, which is necessary!At the initial stage of the project, it is necessary to attract users by token airdrop and distinguish real users.\n\n post by Alisa on Nov 22, 2021\n\n Alisa\n\n Acrosit is to establish a Dao and become a token of community governance. However, empowering and offsetting gas is a good suggestion, which can prevent members from throwing it out too early. However, it also has some disadvantages., if it is a gas, will it affect the development of community autonomy? But if it is only from the perspective of token, the more successful across is, the better the development of Dao will be, Of course, it will attract more people to participate\n\n 9 days later\n\n post by MrHeviDi on Dec 1, 2021\n\n MrHeviDi\n\n fommes.eth\n\n But there will be other protocals/bridges to move funds from L2 to L1, so Across needs to atract users to use Across and maybe to hold Across token. Maybe, like someone before montioned, having Across token will give you some fee reduction or something like that.\n\n 2 months later\n\n post by jotatotal on Jan 26, 2022\n\n jotatotal\n\n Solace\n\n What about giving the holders of the token , despite a fee reduction , a share of the fee according to their holdings?\n\n post by lawpanda.eth on Jan 26, 2022\n\n lawpanda.eth\n\n That would functionally be an ‘x’ token, like xSushi, dQuick, etc. On the legal end it creates regulatory questions because it resembles a security. But it is a more functional mechanism for facilitating adoption/use.\n\n 2 months later\n\n post by J.Berg on Mar 18, 2022\n\n J.Berg\n\n Creating a token enables the DAO to have an asset (without investing) that can be used to fund projects/guilds for effort the DAO needs (both maintenance and major initiatives), as well as contribute to internal DAO economics.\n–Paying core team members for their efforts\n–Paying for work done by Guilds and their squads\n–Internal DAO markets and trade\n–Bounties\nWill the Across token be used strictly for governance? or will it be used as money? or both?\nWould it be a monetary asset and a governance token to be used to fund and vote? Some DAO’s treat their governance token as ONLY that, and it actively drives down it’s valuation.\nIf its money then the DAO as an organization has the challenges of both a startup and an emerging digital nationstate in that we have to find and create revenue streams and manage costs, as well as drive the use and acceptance of our denomination both internally and externally.\nI think long term will be based on the size of the treasury it controls and the useful things you can do with it. As a result, I think the focus should be on activities that generate on-chain revenue for the DAO and ways to make the token useful stake it, collateral, ect.\nHow to pay contributors is definitely an important factor to consider. Without contributors, we won’t be able to do any of the above. Part of me feels that if your contributing, it should be because you believe in the DAO long term and shouldn’t expect an immediate monetary reward. The other part of me thinks that contributor renumeration is something that needs to be painstakingly thought out to retain talent and pay our people\n\n post by heybeo on Mar 22, 2022\n\n heybeo\n\n It would be nice to use bridges on the same platform as well as to create a nice dex.\nTrading pairs, for example acx-uma, are used as fees and distributed to token holders.\nacx-x\nacx-y\nacx-z\nJust a simple idea as liquidity addition commissions are burned\n\n post by altsilversurfer.nft on Mar 26, 2022\n\n altsilversurfer.nft\n\n Tokenomics can be viewed as a function of 3 main parameters, token launch (model, vesting scheme, market cap), utility, and inflation. Utility is one of the major drivers of adoption and appreciation of value. Thus, the more utilities, the best. Governance will be the first and more obvious utility of $ACX, but we must think beyond this to achieve sustainnability. This is the ultimate goal. And this is also the common interest of all involved. People that are waiting for profits will be maximally rewarded if they be patient and contribute to protocol sustainnability. Across will be really BIG and this is not a fanboy statement. The major crosschain pipes will see in the future typical value movements that will far exceed those of the biggest centralized exchanges today.\n\n post by jeffrey on Mar 29, 2022\n\n jeffrey\n\n Token is share, it means users own the project\n\n 12 days later\n\n post by hescollazo on Apr 11, 2022\n\n hescollazo\n\n I agree with the use of the token as a payment mechanism for the protocol. The low fees will bring new users and money into the ecosystem. That it can be used in governance will incentivize use of the application and hodling of the asset. Ultimately the goal should be to give users the tools to discover new ways in which to generate positive cash flow and build wealth.\n\n 10 days later\n\n post by Ray_V on Apr 21, 2022\n\n Ray_V\n\n Would we introduce a single staking mechanism? In which we would offer our tokens as liquidity to the across protocol and earn APR either through the fees accrued by the protocol - or another more effective system? Would that be something considered?\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Initial thinking around token distribution\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 36\n\n Mar 2022\n\n Across Token Launch Proposal\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 214\n\n May 2022\n\n Across Token Launch Proposal v2\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 47\n\n Nov 2022\n\n Second ACX Drop\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 15\n\n Feb 2024\n\n Welcome to Across\n\n WELCOME 👋\n\n WELCOME 👋\n\n Nov 2022","tokens":2413,"squid":"spider-09","role":"Bridge Spider","at":1791347824374,"hash":"950d08e7403029a87a2cf559ff2b0a0c2ee785e9"}
{"url":"https://research.arbitrum.io/t/submitting-transaction-bundles/75/7","domain":"research.arbitrum.io","title":"Submitting transaction bundles - Uncategorized - Arbitrum Research","text":"Uncategorized\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 5\n\n 2\n\n read \n\n 4\n min\n\n May 2022\n\n 7 / 15\n\n Jun 2022\n\n Aug 2025\n\n post by edfelten on May 21, 2022\n\n edfelten\n\n We’re considering adding a feature to the sequencer that allows clients to submit a bundle of transactions, that is, a set of multiple transactions, in a single submission. The sequencer would promise to include those transactions consecutively in its ordering, with no other transactions interleaved among them.\nThe sequencer already sequences transactions in the order they arrived at the sequencer, so the result would be as if all of the transactions in the bundle arrived consecutively. The bundles wouldn’t get earlier or later position in the sequence by virtue of being bundles. We wouldn’t guarantee that the transactions in a bundle will end up in the same block, only that no other user transactions will be between them.\nWe think this bundle functionality is useful for some use cases, for example to carry out a sequence of DeFi transactions that rely on an assumption that no other transactions intervene. It also makes some kinds of account abstraction approaches easier to implement.\nOf course we would limit the total size of bundles, or the total gas consumed by a bundle, to some reasonable limit.\nWe’re interested in hearing thoughts on this. Would you use it? Are there any constraints we should take into consideration?\n\n 5\n\n 2\n\n read \n\n 4\n min\n\n post by bbuddha on May 22, 2022\n\n bbuddha\n\n I like it! Could be useful for gasless transactions, in which one tx in the bundle pays gas for all of the other transactions. In addition, it would be cool to create programmability into the bundle submission for condition reversion of other transactions in the bundle revert and perhaps other powerful controls.\nAre you planning to include a way for transactions to figure out the contents of the bundle they are in (block.bundlehash)? If this was possible, along with the conditional reversion, you may be able to implement cross transaction flashloans! Just submit a bundle [flashLoan(), doStuff(), repay()], and the flashLoan() tx would have functionality to revert in case the repay() tx failed.\nOne concern is how trustless this is. Is the bundle not being broken up somehow ensured via changes to the fraud proof mechanism or is it based off of trust in the sequencer? There are scenarios in which it is detrimental to break up the bundle.\n\n post by edfelten on May 24, 2022\n\n edfelten\n\n We weren’t looking to change the semantics of execution on the chain, only how transactions are submitted. The transactions would still execute normally, without any additional affordances, so the only difference from normal submission would be that transactions in a bundle would run consecutively without any others interleaved between them (assuming an honest sequencer).\nStronger notions of bundling that change the execution model could accomplish more, but are a much heavier lift in terms of implementation, and would introduce incompatibilities with Ethereum.\n\n post by bertcmiller on May 31, 2022\n\n bertcmiller\n\n A really common use case for this would be bundling an approval and an action together, e.g. approving a router and making a swap, or approving a vault and depositing funds into it. In my opinion this is a really useful abstraction.\nOne thing that you should be mindful of is that this could change the security model of DeFi protocols. In particular, some contracts rely on the (bad) assumption that EOAs cannot atomically make many transactions in a row. If that assumption is broken then it might open up protocols to economic vulnerabilities. Many protocols with this assumption use require(msg.sender == tx.origin) to ensure that only EOAs are interacting with certain functions.\nAs far as I can tell DeFi protocols have moved away from this assumption because it’s never been a sound one to make in the long run. But opening up the space for atomic EOA execution does change the security model for some contracts, so you should make sure to communicate that if you make this change.\n\n post by edfelten on May 31, 2022\n\n edfelten\n\n We would not guarantee that the transactions in a bundle execute as a single atomic unit. We would only guarantee that no other transactions come between them. It would still be possible for some transactions in the bundle to revert while others succeed.\n\n post by eleglenctic on Jun 1, 2022\n\n eleglenctic\n\n Would all transactions in a bundle be required to share the same sender address, or can clients indiscriminately reorder bundles of arbitrary transactions before submitting them to the sequencer? Would submitting sequencer bundles be permissionless? How do we define client in this context, is it any transaction signer or is it only a specific piece of Arbitrum infrastructure? Considering that the policy of the sequencer is “first come, first serve,” it’s important to understand if a third party service can violate that policy within a bundle, for better or for worse.\nThere might be an engineering hurdle for composing sequencer bundles from regular user wallets, because I think there isn’t a universal method that wallets use to handle setting a transaction’s nonce or a universal method for when to broadcast a signed transaction.\nIt seems like if an average user wanted to submit a bundle, they would require an intermediary that intercepts their signed transactions until they submit their entire bundle, because I think the default behavior of e.g. Metamask is to submit a transaction to the rpc endpoint as soon as it is signed.\nIn theory, a static webpage could allow users to aggregate signed transactions into a bundle using the eth_sign rpc method to sign raw transaction hashes, but that would be a downgrade to the user’s experience and would empower phishing scams.\nOverall, I’m curious if access to submitting transaction bundles would be offered exclusively to some restricted definition of “clients,” or if this also is meant to provide access directly to individuals who might want to submit an approve and deposit bundle. Arbitrum is designed to offer a seamless experience to Ethereum users, and the approach to integrating sequencer bundles into existing wallets will be important if users are given direct access to this service.\n\n post by edfelten on Jun 2, 2022\n\n edfelten\n\n The version of this that seems the most useful and straightforward to implement is to (1) not restrict which transactions can be submitted in the same bundle (except for limits on total bundle size), and (2) not restrict who can submit bundles. That is, a bundle is just another way to submit a set of multiple transactions, with the same result as if you submitted the transactions one at a time and it turned out that no other transactions arrived in between yours.\nIf you route your transactions through a third party, it could reorder them within a bundle. That’s basically the same issue you have now if you submit multiple transactions through a third party–it can reorder them if it wants.\nAlso, a dishonest sequencer could reorder or drop the transactions within your bundle. Again, that’s basically what it can already do to transactions submitted one at a time.\n\n 4 months later\n\n post by stonecoldpat on Oct 8, 2022\n\n stonecoldpat\n\n Seems like a nobrainer to support a feature like this. I wouldn’t optimise for making it trustless since you are already trusting the sequencer.\n\n 4 months later\n\n post by web3fishermen on Jan 25, 2023\n\n web3fishermen\n\n @stonecoldpat What do you mean? Could you clarify your statement pls\n\n 2 months later\n\n post by hossein_alavi on Mar 19, 2023\n\n hossein_alavi\n\n Hi!\nI wanted to check if the idea of bundles transactions is implemented or not, and if yes is there a document on how to use it?\n\n 1 month later\n\n post by pahakow on Apr 25, 2023\n\n pahakow\n\n nice\nOne concern is how trustless this is. Is the bundle not being broken up somehow ensured via changes to the fraud proof mechanism or is it based off of trust in the sequencer? There are scenarios in which it is detrimental to break up the bundle.\n\n post by edfelten on Apr 26, 2023\n\n edfelten\n\n The easiest way to do this would be to trust the sequencer to not separate the transactions in the bundle. This is straightforward to implement because one would just need to add an RPC to submit a set of transactions that are meant to be a bundle. Nothing on-chain would need to change.\nEnforcing bundling is more difficult because it would need to be the case that the sequencer cannot (say) extract one transaction from the bundle and just post that one. And that, in turn, seems to require that the transactions in the bundle can’t be separable from each other. That means, for example, that it won’t work to include each transaction’s data in encodable format along with a signature on that one transaction. Instead, the transactions in the bundle would somehow need to be entangled so that each one is invalid unless attached to the others.\nOne way to build non-separable transactions is to use a facility like ERC-4337 account abstraction, which is currently on Arbitrum’s testnet at the moment.\n\n 2 years later\n\n post by cmatt on Jul 16, 2025\n\n cmatt\n\n Has something like this been implemented or is still considered? Or has this been dropped because there are by now other methods, such as the mentioned way via account abstraction, via which something similar can be achieved? It seems to me ability to directly submit bundles to the sequencer could still be useful.\n\n 26 days later\n\n post by kakia on Aug 12, 2025\n\n kakia\n\n It is not implemented at the moment. Other methods may come close to implementing bundling, but nothing guarantees it. What useful cases do you have in mind for this?\n\n post by cmatt on Aug 15, 2025\n\n cmatt\n\n Thanks for the answer! I don’t have any specific use-case in mind. We have been looking into what sequencer commitments could enable for rollups (specifically OP, see https://mirror.xyz/preconf.eth/UoMhzBvWihwLLXuUYywjXLg4JmymEeC2jqlAeIRBD_Q) and cryptoeconomically protected bundles would be one of the things. Since people here seemed interested, we wondered what the status was. One possible use-case would be that you want to migrate some LP position from Uniswap V2 to V3 and you want closing the V2 and opening the V3 to be bundled since other trades in-between could unbalance your 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 Bundle imitation on Arbitrum\n\n Uncategorized\n\n defi,tx-ordering\n\n 3\n\n 1.9k\n\n Oct 2023\n\n Transaction ordering policy\n\n Uncategorized\n\n 10\n\n 8.6k\n\n Mar 2023\n\n Hybrid transaction ordering policy\n\n Uncategorized\n\n tx-ordering,sequencer\n\n 6\n\n 2.9k\n\n Nov 2022\n\n Proposed design for Timeboost\n\n Uncategorized\n\n 12\n\n 3.3k\n\n Jun 2024\n\n Arbitrum vs Optimism\n\n Uncategorized\n\n defi\n\n 1\n\n 2.6k\n\n Mar 2023","tokens":2729,"squid":"spider-01","role":"Chain Spider","at":1791347828269,"hash":"4da931bfe7fb4b56302a802e7033bb9f5561772e"}
{"url":"https://forum.across.to/t/what-the-token-does/52/22","domain":"forum.across.to","title":"What the token does? - Tokenomics (old) - Across Protocol","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 read \n\n 4\n min\n\n Nov 2021\n\n 22 / 26\n\n Mar 2022\n\n Apr 2022\n\n Load more posts above\n\n post by fommes.eth on Nov 17, 2021\n\n fommes.eth\n\n Imho there is no point in holding the Across token for fees reduction. I imagine a tipical Across user will not bridge all the time, just looking at the general roadmap/POV that Eth mainnet is becoming solely/mostly just the settlement layer, already in the coming months ppl will use more frequent L2s and withdraw back sometimes.\n\n post by fommes.eth on Nov 17, 2021\n\n fommes.eth\n\n I propose the Across token to accrue fees for holders instead.\n\n post by Robot on Nov 17, 2021\n\n Robot\n\n fommes.eth\n\n Surely the more utility the better and i’m sure Across will have to go L2 to L2 in the end\n\n post by Sanguine on Nov 17, 2021\n\n Sanguine\n\n Kastormagic\n\n I think that token is needed for the DAO in the first place. It is not even necessary that it have economic value in the form of receiving % from commissions for the interaction of other users with the protocol. First of all, a token is a symbol. The more successful the project is, the more people want to be involved in it through the token.\n\n post by jotatotal on Nov 17, 2021\n\n jotatotal\n\n I would suggest that a part of the fees goes to the DAO treasury, and so increment value of DAO token. On the other hand I also consider that if the token is used to pay fees those fees get burned after that.\n\n post by fommes.eth on Nov 17, 2021\n\n fommes.eth\n\n Robot\n\n There are lots of L2 to L2 bridges already. Imho Across is unique in that sense and should aim to be the Go-To for fast+secure L1 withdrawals. There will always be a need for L1 withdrawals, even if Ethereum becomes mostly just an execution layer.\n\n post by Robot on Nov 17, 2021\n\n Robot\n\n Sanguine\n\n That’s not true go look at Ribbon finance and their token launch people bought and it non-stop gets called a useless govenunce token, Ribbon is very successful with about $200m TVL but the token price don’t reflect that\n\n post by Solace on Nov 17, 2021\n\n Solace\n\n Completely agree with /u/fojo’s post above - this is an important discussion regarding the token launch.\nWould the token be used strictly for governance, to pay out fees, or as a safety module? These do not necessarily have to mutually exclusive, and it’s possible that the token could incorporate all three - but as far as emission and distribution goes, it’s pretty important to make at least one a priority.\nIf choosing a governance route, liquidity incentives and a safety module could also be implemented at a later stage via a proposal. But this would remain subject to a vote, which could take some time to pass.\nOn the topic of liquidity incentives, these will likely remain temporary in order to bootstrap liquidity though there are plenty of examples of where artificially incentivizing usage has led to users with short-term outlooks farming these pools and draining the liquidity afterwards.\nAs far as using the token to incentivize usage goes, one approach could be to provide a gas fee rebate to users that bridge from L1 → L2 using the Arbitrum/optimism native bridge and bridge back to L1 using Across. This could be implemented similarly to Balancer’s gas fee rebate: [Proposal] Balancer Exchange Gas Reimbursement - Proposals - Balancer\nWe could get creative with some ways in order to incentivize usage rather than only incentivizing the LPs (as they will receive a fee of the transaction either way).\n\n post by Sanguine on Nov 17, 2021\n\n Sanguine\n\n Robot\n\n Maybe so. Indeed, in our time, the success of the project for the crowd is the endless rise in the price of the token. And if the price of a token does not grow infinitely, then they begin to call it “useless governance token”. But if the project starts to hype and the price rises, then it abruptly turns into an “incredibly useful governance token”.\n\n post by eqing.eth on Nov 21, 2021\n\n eqing.eth\n\n Kastormagic\n\n Tokens will attract some early users, which is necessary!At the initial stage of the project, it is necessary to attract users by token airdrop and distinguish real users.\n\n post by Alisa on Nov 22, 2021\n\n Alisa\n\n Acrosit is to establish a Dao and become a token of community governance. However, empowering and offsetting gas is a good suggestion, which can prevent members from throwing it out too early. However, it also has some disadvantages., if it is a gas, will it affect the development of community autonomy? But if it is only from the perspective of token, the more successful across is, the better the development of Dao will be, Of course, it will attract more people to participate\n\n 9 days later\n\n post by MrHeviDi on Dec 1, 2021\n\n MrHeviDi\n\n fommes.eth\n\n But there will be other protocals/bridges to move funds from L2 to L1, so Across needs to atract users to use Across and maybe to hold Across token. Maybe, like someone before montioned, having Across token will give you some fee reduction or something like that.\n\n 2 months later\n\n post by jotatotal on Jan 26, 2022\n\n jotatotal\n\n Solace\n\n What about giving the holders of the token , despite a fee reduction , a share of the fee according to their holdings?\n\n post by lawpanda.eth on Jan 26, 2022\n\n lawpanda.eth\n\n That would functionally be an ‘x’ token, like xSushi, dQuick, etc. On the legal end it creates regulatory questions because it resembles a security. But it is a more functional mechanism for facilitating adoption/use.\n\n 2 months later\n\n post by J.Berg on Mar 18, 2022\n\n J.Berg\n\n Creating a token enables the DAO to have an asset (without investing) that can be used to fund projects/guilds for effort the DAO needs (both maintenance and major initiatives), as well as contribute to internal DAO economics.\n–Paying core team members for their efforts\n–Paying for work done by Guilds and their squads\n–Internal DAO markets and trade\n–Bounties\nWill the Across token be used strictly for governance? or will it be used as money? or both?\nWould it be a monetary asset and a governance token to be used to fund and vote? Some DAO’s treat their governance token as ONLY that, and it actively drives down it’s valuation.\nIf its money then the DAO as an organization has the challenges of both a startup and an emerging digital nationstate in that we have to find and create revenue streams and manage costs, as well as drive the use and acceptance of our denomination both internally and externally.\nI think long term will be based on the size of the treasury it controls and the useful things you can do with it. As a result, I think the focus should be on activities that generate on-chain revenue for the DAO and ways to make the token useful stake it, collateral, ect.\nHow to pay contributors is definitely an important factor to consider. Without contributors, we won’t be able to do any of the above. Part of me feels that if your contributing, it should be because you believe in the DAO long term and shouldn’t expect an immediate monetary reward. The other part of me thinks that contributor renumeration is something that needs to be painstakingly thought out to retain talent and pay our people\n\n post by heybeo on Mar 22, 2022\n\n heybeo\n\n It would be nice to use bridges on the same platform as well as to create a nice dex.\nTrading pairs, for example acx-uma, are used as fees and distributed to token holders.\nacx-x\nacx-y\nacx-z\nJust a simple idea as liquidity addition commissions are burned\n\n post by altsilversurfer.nft on Mar 26, 2022\n\n altsilversurfer.nft\n\n Tokenomics can be viewed as a function of 3 main parameters, token launch (model, vesting scheme, market cap), utility, and inflation. Utility is one of the major drivers of adoption and appreciation of value. Thus, the more utilities, the best. Governance will be the first and more obvious utility of $ACX, but we must think beyond this to achieve sustainnability. This is the ultimate goal. And this is also the common interest of all involved. People that are waiting for profits will be maximally rewarded if they be patient and contribute to protocol sustainnability. Across will be really BIG and this is not a fanboy statement. The major crosschain pipes will see in the future typical value movements that will far exceed those of the biggest centralized exchanges today.\n\n post by jeffrey on Mar 29, 2022\n\n jeffrey\n\n Token is share, it means users own the project\n\n 12 days later\n\n post by hescollazo on Apr 11, 2022\n\n hescollazo\n\n I agree with the use of the token as a payment mechanism for the protocol. The low fees will bring new users and money into the ecosystem. That it can be used in governance will incentivize use of the application and hodling of the asset. Ultimately the goal should be to give users the tools to discover new ways in which to generate positive cash flow and build wealth.\n\n 10 days later\n\n post by Ray_V on Apr 21, 2022\n\n Ray_V\n\n Would we introduce a single staking mechanism? In which we would offer our tokens as liquidity to the across protocol and earn APR either through the fees accrued by the protocol - or another more effective system? Would that be something considered?\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Initial thinking around token distribution\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 36\n\n Mar 2022\n\n Across Token Launch Proposal\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 214\n\n May 2022\n\n Across Token Launch Proposal v2\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 47\n\n Nov 2022\n\n Second ACX Drop\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 15\n\n Feb 2024\n\n Welcome to Across\n\n WELCOME 👋\n\n WELCOME 👋\n\n Nov 2022","tokens":2413,"squid":"spider-09","role":"Bridge Spider","at":1791347834620,"hash":"402ac274a16ef24ec0e66189599072a04a00f276"}
{"url":"https://gov.optimism.io/t/token-house-participation-and-incentives-an-extended-analysis/6479/1","domain":"gov.optimism.io","title":"Token House participation and incentives: an extended analysis - Communications 📣 / Delegates 🏛 - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n Token House participation and incentives: an extended analysis \n\n Communications 📣Delegates 🏛\n\n season-4\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 13\n min\n\n Jul 2023\n\n 1 / 20\n\n Jul 2023\n\n Mar 2024\n\n post by Joxes on Jul 20, 2023\n\n Joxes\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 numerous changes throughout each season pursuing the best interest for the Optimism ecosystem. From the season 0 to 4, Optimism governance has established different processes for managing governance funds, protocol updates and other decisions to which delegates have had to adapt, even making the process more complex to guarantee; for example, the correct allocation of funds, with the introduction of committees, and later, the Grant Council. Over time, it has been possible to demonstrate the heavy workload that the delegates have had to face. For season 4, less than half of the delegates (>0.25%) had an active participation during the feedback and approval to vote process. In order to align the work of delegates and broaden the desire to participate, we believe that the path is to improve the incentive system aka rewards, as a way to increase the quality and fulfillment of the final goals.\n1. Introduction\nThe launch of Optimism Governance marked a new phase in Web3 financing and Public Goods within the Layer 2 scaling solutions ecosystem on Ethereum.\nDuring this period, the Governance Fund has funded numerous projects, and many OP tokens have been injected into the ecosystem. These achievements have been made possible thanks to the hard work of the delegates in Seasons 1 and 2 and the management of the Grants Council in Seasons 3 and 4.\nGiven the level of maturity achieved by Optimism Governance, it’s essential to consider not only the injection of OP tokens into the ecosystem but also to plan and execute incentives for delegates and other decision-making roles within the ecosystem.\nBecause of the nature of this governance and expected future, it’s critical to continue to keep current known delegates active and to attract new delegates from both the Web3 ecosystem and qualified individuals and groups who can be aligned with the optimistic vision (universities, ONG, foundations, etc.).\n2. Optimistic Heart and Hands-on Work (Workload Volume in Optimism Governance)\nOptimism Governance stands out not only for granting grants to a large number of projects but also for its agile iteration and flexibility to drive the constant growth of the ecosystem. This generates a considerable workload for the delegates, who must manage a dense feedback process to approve proposals.\nTo contextualize the above, let’s examine the work carried out by delegates in previous seasons, with a special emphasis on the current season.\n2.1 Previous Seasons\n2.1.1 Season 1\nThe system was open this season, and anyone could request a grant through a proposal in the forum. For a proposal to proceed to vote, it needed the support of at least 1 delegate with >0.0005% of the voting power (no data could be retrieved on how many delegates had this voting power).\n\nCycle #1: 24 proposals\nCycle #2: 17 proposals\nCycle #3: 9 proposals\nCycle #4: 9 proposals\n\nTotal: 60 proposals\nOP Tokens: 42,630,770.0\n\nNote: only proposals posted on Snapshot are counted.\nSeason 1 presented the challenge of handling many applications and the need for a transparent process to bring proposals to a vote. Changes were implemented in Season 2 to address these issues.\n2.1.2 Season 2\nIn this season, 5 committees were introduced, specialized working groups consisting of 5 delegates each, which provided qualified recommendations on how to vote on each proposal. These committees received OP tokens for their work at the end of the season. For a proposal to proceed to vote, it needed the support of at least 2 delegates with >0.5% of voting power (about 36 delegates throughout Season 2).\n\nCycle #6: 10 proposals\nCycle #7: 14 proposals\nCycle #8: 18 proposals\n\nTotal: 42 proposals\nOP Tokens: 13,118,611.0\n\nNote: Only proposals posted on Snapshot are counted.\nWhile the committees alleviated some of the delegates’ workload, their role could have been more precise, leading to conflicts between proponents and committees and among the committees themselves. In Season 3, the Grants Council was introduced to address these issues.\n2.1.3 Season 3\nIn this season, the Grants Council was established, a group of 9 delegates elected by the governance to manage the Governance Fund grant process under the direction of an individual from the Optimism Foundation. Each council member receives OP tokens at the end of each season.\n\nCycle #10: 73 proposals\nCycle #11: 79 proposals\n\nTotal: 152 proposals\nOP Tokens: 4,538,130.0\n\nThe Grants Council have resolved the main governance issues:\n\nUnclear processes\nWorkload for delegates\nConflicts among delegates\n\nIn the meantime, a portion of delegates accepted the responsibility of being part of the Citizen House for retroPGF 2. In numbers:\n\n10 were selected via governance nomination and voting\nOther few via other badgeholders nomination\n195 projects analized\n2 weeks for revision + several others for preparation and onboarding\n\nWhile this represents a significant achievement for governance, Season 4 has reintroduced new workloads per unit of time for delegates through missions.\n2.2 Season 4\nThis season, missions have been introduced, consisting of proposals for specific initiatives to achieve short-term objectives (Intents). Any individual, team, or company can submit a mission proposal through a post on the forum, following predefined rules. For a mission to proceed to vote, it must have the support of at least 4 delegates with more than 0.25% of voting power (63 delegates with enough voting power for the first month of Season 4).\nA total of 49 mission requests were received, out of which only 31 proposals went to voting. Despite having established rules for missions, they have reintroduced a workload for delegates and a low level of participation has been observed among them.\nA table has been prepared by manually extracting data from the forum during the proposal pre-selection stage.\nDelegate Support Intent #1:\n1152×410 30.9 KB\nDelegate Support Intent #3:\n1153×773 62.1 KB\nDelegate Support Intent #4:\n1153×736 59.7 KB\nTotal support from participating delegates:\n1537×443 80.8 KB\n2.3 Current Participation and Voting Data\nBased on the data presented in the previous section, the following figures can be extracted:\n\nTo date, Optimism Governance has a total of 1,125 delegates.\nOnly 63 delegates possess more than 0.25% of the voting power.\nOf these, only 27 delegates supported missions.\n\n7 delegates (violet) are current members of the Grants Council.\n5 delegates (yellow) belong to the Protocol Delegation Program Season 4.\nDelegates @mastermojo and @MattGov.eth (red line) supported missions with the same address, as clarified in their delegate statement, and could be considered a single delegate for the purpose of this assessment\n13 delegates (white) are independent or have no additional duties or external incentives.\n\n12 delegates supported less than 5 missions.\n\n5 delegates supported only 1 mission.\n5 delegates supported only 2 missions.\n1 delegate supported 3 missions.\n1 delegate supported 4 missions.\n\nNote: If any delegate is missing or errors are detected, please report it here in the post for correction.\nAdditionally, it’s worth noting that the following behavior could be evidenced among the delegates in the forum:\n\nOut of the 27 delegates, 13 only supported proposals without providing feedback to the proponents.\nDelegates with a low number of supported missions maintained constant activity during the feedback stage, such as @jackanorak, @MinimalGravitas, joxes team group, and others.\nDelegates who did not reach the 0.25% VP threshold actively participated during the mission feedback period, such as @opuser, @lee0007, @brichis, @itublockchain.\n\nSummary reflextions\nThe granting of subsidies generates significant interest in Optimism’s governance from teams, builders, protocols, communities, grant seekers, and others. This results in a high volume of requests on the forum. Such many requests imply a heavy workload for delegates, who must filter, provide feedback, vote, and communicate.\nThe constant interaction and workload make it difficult to onboard new delegates to governance and exhaust those who have been present since the beginning. Having active and committed delegates is crucial to eliminate or disincentivize malicious actors within the governance.\n3. Pursuing better incentives to strengthen governance\nAs mentioned earlier, the Grants Council has resolved governance issues faced in Seasons 1 and 2. This is partly because the delegates participating in the council are aligned with the Optimistic Vision and receive appropriate incentives for their work, considering it a job.\n\nThanks to this, we now have a competitive and efficient team capable of processing many requests.\nHowever, this doesn’t mean that the same Grant Council model is applicable for the rest of the missions and resolves the season 4 problems automatically. It would be impractical to create a new council for each initiative of the Optimism Collective, with its own rules and members. Instead, we must focus on establishing the necessary incentives for delegates to maintain consistent activity and participation in governance.\nIn each season, incentives have been given to delegates, but those don’t seem attractive enough to keep their commitment to governance:\n\nRetroactive Delegate Rewards for Season 1 & 2\nRetroactive Delegate Rewards: Season 3\n\nTherefore, we should establish a continuous payment system, by example, per voting cycle or other more predictables, that allows delegates to focus on governance. Additionally, we should implement a system in which those who don’t meet minimum pre-established requirements, related to expected grade of involvement, will lose their token allocation, allowing another delegate interested in governance to take their place.\n\nNext steps and open questions\nApproaching the path to have an established policy and more coherent with the work of delegates who are 100% committed to the Optimistic vision, a new system should be established and raise the requirements that lead to a more professionalized and diverse work on those who are already active and potential new ones. For this, it’s important to define what type of attitudes to reward and where to direct the focus for greater success. This means that we must be prepared to answer these questions:\n\nHow to attract new delegates?\nHow to catch the attention of delegates who have lowered their participation?\nHow to define the quality of a dedicated delegate?\nHow can the delegate be encouraged to share the Optimistic vision and bootstrap more participants and elevate the quality?\nWhat other activities of a delegate to evaluate besides participation in on-chain voting?\nWho monitors delegate activities?\nBased on previous experience, what is the direction to take for the reward allocation reassessment?\nWhat is the reward mechanism that best suits the current state of Optimism Foundation operations?\n\nThis and other considerations are aspects that we continue to evaluate based on this analysis that leads to a design that entails an improvement in processes and incentives, and that we invite delegates and community members to contribute in the discussion spaces.\n4. Conclusion\nAs we found in this analysis, mainly focused on season 4, heavy workload and rewards are not leading to growth in engagement and diversity when it’s critical to have it. In order to best allocate governance funds to achieve the proposed goals, we must propose new incentives that are attractive for delegates to start working in a more committed way with diverse opinions and minimizing the effect of individual interests in specific decisions.\nFrom SEED Latam, we have been observing the current situation, having internal discussions that lead to the solution of this problem that can encourage a large number of committed delegates; and meanwhile we keep working on, now we want to raise the discussion with the entire community.\nAt the end of the day, the final goal is to achieve more committed delegates, improve the quality of the discussions and deal with the diversity of opinions. Only in this way, Optimism governance and protocol will reach the state of maturity that the entire Ethereum community wants to see and perpetually benefit from its technology: in favor of public goods, open-source movement and all of the aspects behind the Optimistic vision that we all share.\n\n Token House participation and incentives: Season 5 (Cycle 16-19)\n\n Retro Delegate Rewards: Season 4\n\n Season 4 Feedback Thread\n\n How Base will participate in Optimism Governance\n\n SEEDGov- General Communication Thread\n\n 7\n\n 2\n\n 2\n\n 2\n\n read \n\n 13\n min\n\n post by OPUser on Jul 21, 2023\n\n post by MoneyManDoug on Jul 21, 2023\n\n post by Oxytocin on Jul 21, 2023\n\n post by linda on Jul 21, 2023\n\n post by AxlVaz on Jul 21, 2023\n\n post by AxlVaz on Jul 21, 2023\n\n post by brichis on Jul 21, 2023\n\n post by AxlVaz on Jul 21, 2023\n\n post by AxlVaz on Jul 21, 2023\n\n post by Oxytocin on Jul 21, 2023\n\n post by chaselb on Jul 23, 2023\n\n post by AxlVaz on Jul 24, 2023\n\n 9 days later\n\n post by abuchtela on Aug 3, 2023\n\n post by itublockchain on Aug 5, 2023\n\n post by AxlVaz on Aug 5, 2023\n\n 8 months later\n\n post by Oakfloors on Mar 25, 2024\n\n post by AxlVaz on Mar 25, 2024\n\n post by Oakfloors on Mar 25, 2024\n\n post by brichis on Mar 25, 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 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 Addressing Voting Apathy in Optimism Governance\n\n Delegate Updates\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 [Temp-Check] - Give Incentives to Solve Voters Apathy\n\n Delegates 🏛\n\n As we are about to ponder around way to improve engagement in our governance, I would like to restart the conversation on solving voter’s apathy. \nI brought this topic on many occasion in the past [1, 2], this(Solving v…\n\n read more\n\n 38\n\n 3.8k\n\n Jan 2023\n\n Token House participation and incentives: Season 5 (Cycle 16-19)\n\n Delegates 🏛\n\n During the previous season, we conducted a report that served as a reference for measuring participation in Governance (you can see it here). \nFirst of all, we want to acknowledge the contributions of @dmars300, @brichis,…\n\n read more\n\n 8\n\n 1.8k\n\n May 2024\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 3d","tokens":3906,"squid":"spider-07","role":"Council Spider","at":1791347839393,"hash":"89f6be39dff8274ed85a864bc8ff7b924d5a50c9"}
{"url":"https://forum.across.to/t/what-the-token-does/52/24","domain":"forum.across.to","title":"What the token does? - Tokenomics (old) - Across Protocol","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 read \n\n 4\n min\n\n Nov 2021\n\n 24 / 26\n\n Mar 2022\n\n Apr 2022\n\n Load more posts above\n\n post by fommes.eth on Nov 17, 2021\n\n fommes.eth\n\n Imho there is no point in holding the Across token for fees reduction. I imagine a tipical Across user will not bridge all the time, just looking at the general roadmap/POV that Eth mainnet is becoming solely/mostly just the settlement layer, already in the coming months ppl will use more frequent L2s and withdraw back sometimes.\n\n post by fommes.eth on Nov 17, 2021\n\n fommes.eth\n\n I propose the Across token to accrue fees for holders instead.\n\n post by Robot on Nov 17, 2021\n\n Robot\n\n fommes.eth\n\n Surely the more utility the better and i’m sure Across will have to go L2 to L2 in the end\n\n post by Sanguine on Nov 17, 2021\n\n Sanguine\n\n Kastormagic\n\n I think that token is needed for the DAO in the first place. It is not even necessary that it have economic value in the form of receiving % from commissions for the interaction of other users with the protocol. First of all, a token is a symbol. The more successful the project is, the more people want to be involved in it through the token.\n\n post by jotatotal on Nov 17, 2021\n\n jotatotal\n\n I would suggest that a part of the fees goes to the DAO treasury, and so increment value of DAO token. On the other hand I also consider that if the token is used to pay fees those fees get burned after that.\n\n post by fommes.eth on Nov 17, 2021\n\n fommes.eth\n\n Robot\n\n There are lots of L2 to L2 bridges already. Imho Across is unique in that sense and should aim to be the Go-To for fast+secure L1 withdrawals. There will always be a need for L1 withdrawals, even if Ethereum becomes mostly just an execution layer.\n\n post by Robot on Nov 17, 2021\n\n Robot\n\n Sanguine\n\n That’s not true go look at Ribbon finance and their token launch people bought and it non-stop gets called a useless govenunce token, Ribbon is very successful with about $200m TVL but the token price don’t reflect that\n\n post by Solace on Nov 17, 2021\n\n Solace\n\n Completely agree with /u/fojo’s post above - this is an important discussion regarding the token launch.\nWould the token be used strictly for governance, to pay out fees, or as a safety module? These do not necessarily have to mutually exclusive, and it’s possible that the token could incorporate all three - but as far as emission and distribution goes, it’s pretty important to make at least one a priority.\nIf choosing a governance route, liquidity incentives and a safety module could also be implemented at a later stage via a proposal. But this would remain subject to a vote, which could take some time to pass.\nOn the topic of liquidity incentives, these will likely remain temporary in order to bootstrap liquidity though there are plenty of examples of where artificially incentivizing usage has led to users with short-term outlooks farming these pools and draining the liquidity afterwards.\nAs far as using the token to incentivize usage goes, one approach could be to provide a gas fee rebate to users that bridge from L1 → L2 using the Arbitrum/optimism native bridge and bridge back to L1 using Across. This could be implemented similarly to Balancer’s gas fee rebate: [Proposal] Balancer Exchange Gas Reimbursement - Proposals - Balancer\nWe could get creative with some ways in order to incentivize usage rather than only incentivizing the LPs (as they will receive a fee of the transaction either way).\n\n post by Sanguine on Nov 17, 2021\n\n Sanguine\n\n Robot\n\n Maybe so. Indeed, in our time, the success of the project for the crowd is the endless rise in the price of the token. And if the price of a token does not grow infinitely, then they begin to call it “useless governance token”. But if the project starts to hype and the price rises, then it abruptly turns into an “incredibly useful governance token”.\n\n post by eqing.eth on Nov 21, 2021\n\n eqing.eth\n\n Kastormagic\n\n Tokens will attract some early users, which is necessary!At the initial stage of the project, it is necessary to attract users by token airdrop and distinguish real users.\n\n post by Alisa on Nov 22, 2021\n\n Alisa\n\n Acrosit is to establish a Dao and become a token of community governance. However, empowering and offsetting gas is a good suggestion, which can prevent members from throwing it out too early. However, it also has some disadvantages., if it is a gas, will it affect the development of community autonomy? But if it is only from the perspective of token, the more successful across is, the better the development of Dao will be, Of course, it will attract more people to participate\n\n 9 days later\n\n post by MrHeviDi on Dec 1, 2021\n\n MrHeviDi\n\n fommes.eth\n\n But there will be other protocals/bridges to move funds from L2 to L1, so Across needs to atract users to use Across and maybe to hold Across token. Maybe, like someone before montioned, having Across token will give you some fee reduction or something like that.\n\n 2 months later\n\n post by jotatotal on Jan 26, 2022\n\n jotatotal\n\n Solace\n\n What about giving the holders of the token , despite a fee reduction , a share of the fee according to their holdings?\n\n post by lawpanda.eth on Jan 26, 2022\n\n lawpanda.eth\n\n That would functionally be an ‘x’ token, like xSushi, dQuick, etc. On the legal end it creates regulatory questions because it resembles a security. But it is a more functional mechanism for facilitating adoption/use.\n\n 2 months later\n\n post by J.Berg on Mar 18, 2022\n\n J.Berg\n\n Creating a token enables the DAO to have an asset (without investing) that can be used to fund projects/guilds for effort the DAO needs (both maintenance and major initiatives), as well as contribute to internal DAO economics.\n–Paying core team members for their efforts\n–Paying for work done by Guilds and their squads\n–Internal DAO markets and trade\n–Bounties\nWill the Across token be used strictly for governance? or will it be used as money? or both?\nWould it be a monetary asset and a governance token to be used to fund and vote? Some DAO’s treat their governance token as ONLY that, and it actively drives down it’s valuation.\nIf its money then the DAO as an organization has the challenges of both a startup and an emerging digital nationstate in that we have to find and create revenue streams and manage costs, as well as drive the use and acceptance of our denomination both internally and externally.\nI think long term will be based on the size of the treasury it controls and the useful things you can do with it. As a result, I think the focus should be on activities that generate on-chain revenue for the DAO and ways to make the token useful stake it, collateral, ect.\nHow to pay contributors is definitely an important factor to consider. Without contributors, we won’t be able to do any of the above. Part of me feels that if your contributing, it should be because you believe in the DAO long term and shouldn’t expect an immediate monetary reward. The other part of me thinks that contributor renumeration is something that needs to be painstakingly thought out to retain talent and pay our people\n\n post by heybeo on Mar 22, 2022\n\n heybeo\n\n It would be nice to use bridges on the same platform as well as to create a nice dex.\nTrading pairs, for example acx-uma, are used as fees and distributed to token holders.\nacx-x\nacx-y\nacx-z\nJust a simple idea as liquidity addition commissions are burned\n\n post by altsilversurfer.nft on Mar 26, 2022\n\n altsilversurfer.nft\n\n Tokenomics can be viewed as a function of 3 main parameters, token launch (model, vesting scheme, market cap), utility, and inflation. Utility is one of the major drivers of adoption and appreciation of value. Thus, the more utilities, the best. Governance will be the first and more obvious utility of $ACX, but we must think beyond this to achieve sustainnability. This is the ultimate goal. And this is also the common interest of all involved. People that are waiting for profits will be maximally rewarded if they be patient and contribute to protocol sustainnability. Across will be really BIG and this is not a fanboy statement. The major crosschain pipes will see in the future typical value movements that will far exceed those of the biggest centralized exchanges today.\n\n post by jeffrey on Mar 29, 2022\n\n jeffrey\n\n Token is share, it means users own the project\n\n 12 days later\n\n post by hescollazo on Apr 11, 2022\n\n hescollazo\n\n I agree with the use of the token as a payment mechanism for the protocol. The low fees will bring new users and money into the ecosystem. That it can be used in governance will incentivize use of the application and hodling of the asset. Ultimately the goal should be to give users the tools to discover new ways in which to generate positive cash flow and build wealth.\n\n 10 days later\n\n post by Ray_V on Apr 21, 2022\n\n Ray_V\n\n Would we introduce a single staking mechanism? In which we would offer our tokens as liquidity to the across protocol and earn APR either through the fees accrued by the protocol - or another more effective system? Would that be something considered?\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Initial thinking around token distribution\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 36\n\n Mar 2022\n\n Across Token Launch Proposal\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 214\n\n May 2022\n\n Across Token Launch Proposal v2\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 47\n\n Nov 2022\n\n Second ACX Drop\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 15\n\n Feb 2024\n\n Welcome to Across\n\n WELCOME 👋\n\n WELCOME 👋\n\n Nov 2022","tokens":2413,"squid":"spider-09","role":"Bridge Spider","at":1791347844937,"hash":"410d8593e48d867ad355b4faa443a5387eb44804"}
{"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 65\n\n 3d\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 30\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 491\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 644\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 38\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 259\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 165\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":"spider-07","role":"Council Spider","at":1791347849541,"hash":"df602b895ec65f6a5f3257489d4d1976e41abcfe"}
{"url":"https://www.metaplex.com/docs/tokens/read-token","domain":"metaplex.com","title":"Read Token Data | Tokens","text":"Fetch fungible token information from the Solana blockchain. Get Token MetadataFetch a token's metadata using its mint address. This retrieves the on-chain token information including name, symbol, decimals, and supply.1// npm install @metaplex-foundation/mpl-token-metadata @metaplex-foundation/umi @metaplex-foundation/umi-bundle-defaults\n2import { publicKey } from '@metaplex-foundation/umi'\n3import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n4import {\n5 fetchDigitalAsset,\n6 mplTokenMetadata\n7} from '@metaplex-foundation/mpl-token-metadata'\n8\n9// Initialize Umi with your RPC endpoint\n10const umi = createUmi('https://api.devnet.solana.com').use(mplTokenMetadata())\n11\n12// The mint address of the token you want to fetch\n13const mintAddress = publicKey('YOUR_TOKEN_MINT_ADDRESS')\n14\n15// Fetch the token's metadata from the blockchain\n16const asset = await fetchDigitalAsset(umi, mintAddress)\n17\n18console.log('Token Name:', asset.metadata.name)\n19console.log('Token Symbol:', asset.metadata.symbol)\n20console.log('Token URI:', asset.metadata.uri)\n21console.log('Decimals:', asset.mint.decimals)\n22console.log('Supply:', asset.mint.supply)\n1// npm install @metaplex-foundation/umi @metaplex-foundation/umi-bundle-defaults @metaplex-foundation/digital-asset-standard-api\n2import { dasApi } from '@metaplex-foundation/digital-asset-standard-api';\n3import { publicKey } from '@metaplex-foundation/umi';\n4import { createUmi } from '@metaplex-foundation/umi-bundle-defaults';\n5\n6// Initialize Umi with a DAS-enabled RPC endpoint\n7const umi = createUmi('https://api.devnet.solana.com').use(dasApi())\n8\n9// The mint address of the token you want to fetch\n10const mintAddress = publicKey('YOUR_TOKEN_MINT_ADDRESS')\n11\n12// Fetch the asset using DAS API\n13const asset = await umi.rpc.getAsset(mintAddress, {\n14 displayOptions: {\n15 showFungible: true\n16 }\n17})\n1curl -X POST \\\n2 -H \"Content-Type: application/json\" \\\n3 -d '{\n4 \"jsonrpc\": \"2.0\",\n5 \"id\": 1,\n6 \"method\": \"getAsset\",\n7 \"params\": {\n8 \"id\": \"<Mint Address>\"\n9 }\n10 }' \\\n11 https://api.devnet.solana.com\nParametersParameterDescriptionmintAddressThe token mint address to fetchGet Token BalanceFetch the token balance for a specific wallet using the Associated Token Account or DAS API.1// npm install @metaplex-foundation/umi @metaplex-foundation/umi-bundle-defaults @metaplex-foundation/mpl-toolbox\n2import { publicKey } from '@metaplex-foundation/umi'\n3import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n4import {\n5 findAssociatedTokenPda,\n6 fetchToken\n7} from '@metaplex-foundation/mpl-toolbox'\n8\n9const umi = createUmi('https://api.devnet.solana.com')\n10\n11const mintAddress = publicKey('YOUR_TOKEN_MINT_ADDRESS')\n12const walletAddress = publicKey('WALLET_ADDRESS')\n13\n14// Find the Associated Token Account\n15const tokenAccount = findAssociatedTokenPda(umi, {\n16 mint: mintAddress,\n17 owner: walletAddress,\n18})\n19\n20// Fetch the token account data\n21const tokenData = await fetchToken(umi, tokenAccount)\n22\n23console.log('Token Balance:', tokenData.amount)\n24console.log('Mint:', tokenData.mint)\n25console.log('Owner:', tokenData.owner)\n1// npm install @metaplex-foundation/umi @metaplex-foundation/umi-bundle-defaults @metaplex-foundation/digital-asset-standard-api\n2import { publicKey } from '@metaplex-foundation/umi'\n3import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n4import { dasApi } from '@metaplex-foundation/digital-asset-standard-api'\n5\n6const umi = createUmi('https://api.devnet.solana.com').use(dasApi())\n7\n8const mintAddress = publicKey('YOUR_TOKEN_MINT_ADDRESS')\n9const walletAddress = publicKey('WALLET_ADDRESS')\n10\n11// Use searchAssets to find the token with balance for a specific wallet\n12const result = await umi.rpc.searchAssets({\n13 owner: walletAddress,\n14 interface: 'FungibleToken',\n15 limit: 1000,\n16 displayOptions: {\n17 showFungible: true\n18 }\n19})\n20\n21// Find the specific token by mint address\n22const token = result.items.find(\n23 (asset) => asset.id === mintAddress\n24)\n25\n26if (token) {\n27 console.log('Token:', token.content.metadata?.name)\n28 console.log('Balance (raw):', token.token_info?.balance)\n29 console.log('Decimals:', token.token_info?.decimals)\n30\n31 // Calculate human-readable balance\n32 const decimals = token.token_info?.decimals || 0\n33 const balance = Number(token.token_info?.balance) / Math.pow(10, decimals)\n34 console.log('Balance:', balance)\n35} else {\n36 console.log('Token not found in wallet')\n37}\n1# Get token balance for a wallet using DAS searchAssets\n2# Returns all fungible tokens - filter by mint address in response\n3curl -X POST \\\n4 -H \"Content-Type: application/json\" \\\n5 -d '{\n6 \"jsonrpc\": \"2.0\",\n7 \"id\": 1,\n8 \"method\": \"searchAssets\",\n9 \"params\": {\n10 \"ownerAddress\": \"<Wallet Address>\",\n11 \"interface\": \"FungibleToken\",\n12 \"options\": {\n13 \"showFungible\": true\n14 }\n15 }\n16 }' \\\n17 https://api.devnet.solana.com\nGet All Tokens by OwnerRetrieve all fungible tokens owned by a wallet address using the DAS API.1// npm install @metaplex-foundation/umi @metaplex-foundation/umi-bundle-defaults @metaplex-foundation/digital-asset-standard-api\n2import { dasApi } from '@metaplex-foundation/digital-asset-standard-api';\n3import { publicKey } from '@metaplex-foundation/umi';\n4import { createUmi } from '@metaplex-foundation/umi-bundle-defaults';\n5\n6const umi = createUmi('https://api.devnet.solana.com').use(dasApi())\n7\n8const walletAddress = publicKey('WALLET_ADDRESS')\n9\n10// Get all fungible assets owned by the wallet using searchAssets\n11// Using interface: 'FungibleToken' filters server-side (more efficient)\n12const result = await umi.rpc.searchAssets({\n13 owner: walletAddress,\n14 interface: 'FungibleToken',\n15 limit: 1000,\n16 displayOptions: {\n17 showFungible: true\n18 }\n19})\n20\n21const fungibleTokens = result.items\n22\n23console.log(`Found ${fungibleTokens.length} fungible tokens\\n`)\n24\n25fungibleTokens.forEach(token => {\n26 const decimals = token.token_info?.decimals || 0\n27 const rawBalance = token.token_info?.balance || 0\n28 const balance = Number(rawBalance) / Math.pow(10, decimals)\n29\n30 console.log(`${token.content.metadata?.name} (${token.content.metadata?.symbol})`)\n31 console.log(` Mint: ${token.id}`)\n32 console.log(` Balance: ${balance.toLocaleString()}`)\n33})\n1# Get all fungible tokens owned by a wallet using searchAssets\n2# Using interface: \"FungibleToken\" filters server-side (more efficient)\n3curl -X POST \\\n4 -H \"Content-Type: application/json\" \\\n5 -d '{\n6 \"jsonrpc\": \"2.0\",\n7 \"id\": 1,\n8 \"method\": \"searchAssets\",\n9 \"params\": {\n10 \"ownerAddress\": \"GfK2Xz6pzQp1sC1FvxePKnikZA7iyaCSVXZykixLjem5\",\n11 \"interface\": \"FungibleToken\",\n12 \"options\": {\n13 \"showFungible\": true\n14 }\n15 }\n16 }' \\\n17 https://api.devnet.solana.com\nComparing ApproachesFeatureDirect RPCDAS APISpeedSlower for bulk queriesOptimized for bulk queriesData freshnessReal-timeNear real-time (indexed)Search capabilitiesLimitedAdvanced filteringUse caseSingle token lookupsPortfolio views, searchesTipsUse DAS for portfolio views - When displaying all tokens a user owns, DAS API is significantly faster than multiple RPC callsFor DAS, set showFungible - Set showFungible: true otherwise some RPCs only return NFT DataRelated GuidesCreate a TokenDAS API OverviewGet Fungible Assets by Owner","tokens":1819,"squid":"dotcat","role":"Tooling Spider","at":1791347859919,"hash":"393f95a8045aef0f8b7ac4ecb06976d44fd47e1e"}
{"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 38\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":"spider-07","role":"Council Spider","at":1791347862925,"hash":"0b6a0362c000c229034a9de4cc5ca86d7339b50e"}
{"url":"https://docs.openzeppelin.com/","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":"spider-06","role":"Security Spider","at":1791347867202,"hash":"6705a1da5797ab8e3d6e210201f9cdcf4a3d22a5"}
{"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":"spider-06","role":"Security Spider","at":1791347877230,"hash":"2c69281cd5ca0b7ab3273893aeb3a5458074cf9d"}
{"url":"https://www.metaplex.com/docs/smart-contracts/bubblegum-v2/create-trees","domain":"metaplex.com","title":"Creating Bubblegum Trees - Bubblegum V2 - Metaplex","text":"SummaryCreating a Bubblegum Tree is the first step before minting compressed NFTs. This page covers how to create and fetch the two required on-chain accounts: the Merkle Tree account and the TreeConfigV2 PDA.Create a Bubblegum Tree with configurable max depth, max buffer size, and canopy depthChoose tree parameters based on your project's cNFT capacity needs (16K to 1B+ cNFTs)Fetch merkle tree and tree config account data after creationUnderstand the cost tradeoffs for different tree configurationsIntroductionWhilst the data of Compressed NFTs is stored inside transactions and not onchain accounts, we still need some onchain accounts to keep track of the Merkle Tree and its configuration. As such, before we can start minting Compressed NFTs, we need to create two accounts:A Merkle Tree account. This account holds a generic Merkle Tree that can be used to verify the authenticity of any type of data. It is owned by the MPL Account Compression Program forked from the SPL Account Compression Program. In our case, we will use it to verify the authenticity of Compressed NFTs.A TreeConfigV2 account. This second account is a PDA derived from the address of the Merkle Tree account. It allows us to store additional configurations for the Merkle Tree that are specific to Compressed NFTs — e.g. the tree creator, the number of minted cNFTs, etc.With these two accounts, we have everything we need to start minting Compressed NFTs. Note that, we will refer to Merkle Tree accounts with associated Tree Config accounts as Bubblegum Trees.Merkle Tree AccountOwner: Account Compression ProgramPDATree Config AccountOwner: Bubblegum ProgramReact FlowPress enter or space to select a node.You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel. Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.Creating a Bubblegum TreeLet's now see how one can create both of these accounts to create a Bubblegum Tree. Fortunately, our libraries make this process easy by providing a Create Tree operation that takes care of everything for us. This operation accepts a variety of parameters — most of them optional — that allow us to customize the Bubblegum Tree to our needs. The most important ones are:Merkle Tree: A newly generated signer that will be used to create the Merkle Tree account. The Merkle Tree account will then be accessible at this address.Tree Creator: The address of the account that will be able to manage the Bubblegum Tree and mint Compressed NFTs.Max Depth and Max Buffer Size: The Max Depth parameter is used to compute the maximum number of leaves — and therefore Compressed NFTs — that the Merkle Tree can hold. This maximum is calculated by 2^maxDepth. The Max Buffer Size parameter indicates the minimum concurrency limit of the Merkle Tree. In other words, it defines how many changes can happen in the tree in parallel. These two parameters cannot be chosen arbitrarily and have to be selected from a predefined set of values as displayed in the table below.Below is an interactive calculator to help you estimate tree creation costs. Enter the number of cNFTs you need, or use the advanced mode to fine-tune all tree parameters and see how they affect cost, proof size, and tree structure.How many compressed NFTs do you need?Closest tree depth: 20 (holds up to 1,048,576 cNFTs)Bubblegum requires a minimum canopy depth of 3 for this tree size. Only 17 proof accounts fit in a single transaction.Minimum cost0.3122 SOLCanopy 3 (Bubblegum minimum)Canopy depth3Proof size17 nodes (544 bytes)Cost per cNFT0.00000030 SOLBalanced7.61 SOLModerate canopy — good composabilityCanopy depth14Proof size6 nodes (192 bytes)Cost per cNFT0.00000725 SOLMaximum composability58.69 SOLFull canopy — smallest proof sizeCanopy depth17Proof size3 nodes (96 bytes)Cost per cNFT0.00005597 SOLCanopy (on-chain)Proof nodesLeaves (cNFTs)Below are our recommended tree settings for compatibility within the Solana ecosystem.Number of cNFTsTree DepthCanopy DepthConcurrency BufferTree CostCost per cNFT16,384148640.33580.0000255065,5361610640.70690.00001579262,1441812642.10420.000013031,048,576201310248.50120.0000131116,777,2162415204826.12010.0000065667,108,8642617204870.82130.000006061,073,741,8243017204872.64680.00000507The max depths of trees are as follows:Public: Whether or not the Bubblegum Tree should be public. If it is public, anyone will be able to mint Compressed NFTs from it. Otherwise, only the Tree Creator or the Tree Delegate (as discussed in Delegating cNFTs) will be able to mint Compressed NFTs.Here is how one can create a Bubblegum Tree using our libraries:Create a Bubblegum Treeimport { generateSigner } from '@metaplex-foundation/umi'\nimport { createTreeV2 } from '@metaplex-foundation/mpl-bubblegum'\n\nconst merkleTree = generateSigner(umi)\nconst builder = await createTreeV2(umi, {\n merkleTree,\n maxBufferSize: 64,\n maxDepth: 14,\n })\n\nawait builder.sendAndConfirm(umi)\nBy default, the Tree Creator is set to the Umi identity and the Public parameter is set to false. However, these parameters can be customized as shown in the example below.const customTreeCreator = generateSigner(umi)\nconst builder = await createTreeV2(umi, {\n // ...\n treeCreator: customTreeCreator,\n public: true,\n})\nFetching a Bubblegum TreeSince a Bubblegum Tree is composed of two onchain accounts, let's see how to fetch either of them.Fetching a Merkle TreeThe Merkle Tree account contains various information about the tree such as:The Tree Header which stores the Max Depth, the Max Buffer Size, the Authority of the tree and the Creation Slot of when the tree was created.The Tree itself which stores low-level information about the tree such as its Change Logs (or roots), its Sequence Number, etc. We talk more about Concurrent Merkle Trees in a dedicated page of this documentation.The Canopy as discussed in the Merkle Tree Canopy page.Here is how one can fetch all of that data using our libraries:Fetch a Merkle Treeimport {\n fetchMerkleTree,\n} from \"@metaplex-foundation/mpl-account-compression\";\n\nconst merkleTreeAccount = await fetchMerkleTree(umi, merkleTree)\nFetching a Tree ConfigThe Tree Config account contains data specific to Compressed NFTs. It stores:The Tree Creator of the Bubblegum Tree.The Tree Delegate of the Bubblegum Tree, if any. Otherwise, it is set to the Tree Creator.The Total Capacity of the Bubblegum Tree which is the maximum number of cNFTs that can be minted from the tree.The Number Minted which keeps track of the number of cNFTs minted into the tree. This value is important as it is used as a Nonce (\"number used once\") value for operations to ensure the Merkle tree leaves are unique. Thus, this nonce acts as a tree-scoped unique identifier of the asset.The Is Public parameter which indicates whether or not anyone can mint cNFTs from the tree.Is Decompressible is only valid for Bubblegum V1.Version is the version of the LeafSchema that can be used.Here is how one can fetch all of that data using our libraries:Fetch a Tree Configimport { fetchTreeConfigFromSeeds } from '@metaplex-foundation/mpl-bubblegum';\n\nconst treeConfig = await fetchTreeConfigFromSeeds(umi, { merkleTree });\nNotesTree parameters (max depth, max buffer size, canopy depth) are immutable after creation. Choose carefully based on your project's needs.Larger trees cost more in rent but have a lower per-cNFT cost. See the recommended settings table above for cost estimates.The Tree Creator is stored in the TreeConfigV2 account and can delegate minting authority to another account (see Delegating Trees).Public trees allow anyone to mint. Private trees restrict minting to the Tree Creator or Tree Delegate.FAQHow do I choose the right tree size for my project?Use the recommended settings table. For small projects or testing, a depth-14 tree holds 16,384 cNFTs at ~0.34 SOL. For large collections, a depth-20 tree holds 1 million cNFTs at ~8.5 SOL. For very large drops, depth-24+ trees hold millions to billions of cNFTs.Can I change the tree size after creation?No. The max depth, max buffer size, and canopy depth are all fixed at creation time and cannot be modified. If you need different parameters, you must create a new tree.What is the relationship between max depth and tree capacity?The maximum number of cNFTs a tree can hold is calculated as 2^maxDepth. For example, maxDepth=14 supports 16,384 cNFTs, maxDepth=20 supports 1,048,576, and maxDepth=30 supports over 1 billion.What does the max buffer size control?The max buffer size determines the minimum concurrency limit — how many modifications can happen to the tree within the same Solana block. Higher values allow more parallel transactions (mints, transfers, burns) but increase the tree's rent cost.GlossaryTermDefinitionBubblegum TreeThe combination of a Merkle Tree account and its associated TreeConfigV2 PDAMerkle Tree AccountThe on-chain account holding the merkle tree data, owned by the MPL Account Compression ProgramTreeConfigV2A PDA derived from the Merkle Tree address, storing Bubblegum-specific config (creator, delegate, capacity, mint count, public flag)Max DepthThe maximum depth of the merkle tree, determining capacity as 2^maxDepthMax Buffer SizeThe number of change log entries stored, determining how many concurrent modifications the tree supports per blockCanopy DepthThe number of upper tree levels cached on-chain, reducing proof sizes in transactionsTree CreatorThe account that created the tree and has authority to manage it and mint cNFTsTree DelegateAn account authorized by the Tree Creator to mint cNFTs on their behalf","tokens":2413,"squid":"dotcat","role":"Tooling Spider","at":1791347879831,"hash":"d50a702ec9e25da57f03f970829e7e9cc29d9ca6"}
{"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 3d 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 3 days 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 3d\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":"spider-07","role":"Council Spider","at":1791347883659,"hash":"bbe1e5aaa660f276a8a9af832204c4ba248033fc"}
{"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":"spider-06","role":"Security Spider","at":1791347890827,"hash":"7632f8f0cf25c280ca628e34006037ddf02423c8"}
{"url":"https://www.metaplex.com/docs/smart-contracts/bubblegum-v2/mint-cnfts","domain":"metaplex.com","title":"Minting Compressed NFTs - Bubblegum V2 - Metaplex","text":"SummaryMinting compressed NFTs adds new cNFTs to a Bubblegum Tree using the mintV2 instruction. This page covers minting with and without MPL-Core collections, and retrieving the asset ID from mint transactions.Mint cNFTs to a Bubblegum Tree using the mintV2 instructionMint directly into an MPL-Core collection with the BubblegumV2 pluginRetrieve the asset ID and leaf schema from the mint transactionConfigure metadata including name, URI, creators, and royaltiesInherit seller fee basis points from an MPL-Core collection's Royalties pluginIn the previous page, we saw that we need a Bubblegum Tree to mint Compressed NFTs, and we saw how to create one. Now, let's see how to mint compressed NFTs from a given Bubblegum Tree. The Bubblegum program offers multiple minting instructions for the different leaf schema versions. Bubblegum V2 introduces a new minting instruction called mintV2 that is used to mint Compressed NFTs either to a given Collection or without a Collection.Minting without a CollectionThe Bubblegum program provides the mintV2 instruction that enables us to mint Compressed NFTs from a Bubblegum Tree. If the Bubblegum Tree is public, anyone will be able to use this instruction. Otherwise, only the Tree Creator or the Tree Delegate will be able to do so.The main parameters of the mintV2 instruction are:Merkle Tree: The Merkle Tree address from which the Compressed NFT will be minted.Tree Creator Or Delegate: The authority allowed to mint from the Bubblegum Tree — this can either be the creator or the delegate of the tree. This authority must sign the transaction. In the case of a public tree, this parameter can be any authority, but must still be a signer.Leaf Owner: The owner of the Compressed NFT that will be minted. It defaults to the payer of the transaction.Leaf Delegate: A delegate authority allowed to manage the minted cNFT, if any. Otherwise, it is set to the Leaf Owner.Collection Authority: The authority allowed to manage the given Collection.Core Collection: The MPL-Core Collection NFT to which the Compressed NFT will be added.Metadata: The metadata of the Compressed NFT that will be minted. It contains information such as the Name of the NFT, its URI, its Collection, its Creators, etc. In Bubblegum V2 the metadata is using MetadataArgsV2 which excludes unneeded fields like uses and the verified flag for the collection.Mint a Compressed NFT without a Collectionimport { none } from '@metaplex-foundation/umi';\nimport { mintV2 } from '@metaplex-foundation/mpl-bubblegum';\n\nawait mintV2(umi, {\n leafOwner: umi.identity.publicKey,\n merkleTree: merkleTree.publicKey,\n metadata: {\n name: 'My NFT',\n uri: 'https://example.com/my-nft.json',\n sellerFeeBasisPoints: 550, \n collection: none(),\n creators: [],\n },\n}).sendAndConfirm(umi);\nMinting to a CollectionWhile it is possible to set and verify a Collection for a Compressed NFT after it is minted, Bubblegum V2 allows you to mint a Compressed NFT directly to a given Collection. Bubblegum V2 uses MPL-Core Collections to group the compressed NFTs. The same mintV2 instruction is used for that. In addition to the parameters described above, you need to pass in the core collection and sign as collection authority or delegate:Core Collection: The mint address passed to the coreCollection parameter, pointing to the MPL-Core Collection NFT…Collection Authority: The authority allowed to manage the given Collection NFT. This can either be the update authority of the Collection NFT or a delegated collection authority. This authority must sign the transaction regardless of whether the Bubblegum Tree is public or not.Note that the Metadata parameter must contain the Collection Public Key.Mint a Compressed NFT to a Collectionimport { some } from '@metaplex-foundation/umi';\nimport { mintV2 } from '@metaplex-foundation/mpl-bubblegum';\n\nawait mintV2(umi, {\n collectionAuthority: umi.identity,\n leafOwner: umi.identity.publicKey,\n merkleTree: merkleTree.publicKey,\n coreCollection: collectionSigner.publicKey,\n metadata: {\n name: 'My NFT',\n uri: 'https://example.com/my-nft.json',\n sellerFeeBasisPoints: 550, // 5.5%\n collection: some(collectionSigner.publicKey),\n creators: [],\n },\n}).sendAndConfirm(umi);\nInheriting royalties from the collectionWhen minting to an MPL-Core collection, you can store a sentinel seller fee basis points value on the leaf (65535, exported as SELLER_FEE_BASIS_POINTS_INHERIT / 0xffff) instead of copying the collection's royalty percentage into every cNFT. DAS puts the collection-resolved rate on royalty.basis_points / creators for display and the leaf sentinel on royalty.basis_points_raw / creators_raw (with royalty.inherited: true), while the on-chain leaf keeps the sentinel for hashing.Clients that read DAS responses (wallets, marketplaces, indexers, and apps) should follow Reading Inherited Royalties.Marketplace / indexer compatibilityUntil a wallet's or marketplace's DAS provider supports inherited SFBP resolution, it sees creators: [] and basis_points: 65535. Apps then display a 655.35% royalty (roughly 650%) with no creators and may skip royalty payouts. The onchain asset is correct. See Responses from DAS providers without inherited royalty support. For stronger guarantees, use collection Royalties plugin allow/deny lists so sales go through royalty-compliant venues.The JavaScript SDK's mintV2 helper defaults to this behavior when coreCollection is provided and metadata.sellerFeeBasisPoints is omitted.Requirements:The MPL-Core collection must have both the BubblegumV2 and Royalties plugins.metadata.creators must be an empty array when using inherited seller fees. Creator splits come from the collection's Royalties plugin instead of leaf-level creators.Inherited seller fees are only valid for cNFTs in a collection. Collectionless mints must use an explicit value between 0 and 10000.1import { createTreeV2, mintV2, mplBubblegum } from '@metaplex-foundation/mpl-bubblegum'\n2import { createCollection, mplCore, ruleSet } from '@metaplex-foundation/mpl-core'\n3import { generateSigner, some } from '@metaplex-foundation/umi'\n4import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n5\n6const umi = createUmi('https://api.devnet.solana.com')\n7 .use(mplBubblegum())\n8 .use(mplCore())\n9\n10const merkleTree = generateSigner(umi)\n11const collectionSigner = generateSigner(umi)\n12\n13await createTreeV2(umi, {\n14 merkleTree,\n15 maxDepth: 5,\n16 maxBufferSize: 8,\n17}).sendAndConfirm(umi)\n18\n19// The collection must include BubblegumV2 and Royalties plugins.\n20await createCollection(umi, {\n21 collection: collectionSigner,\n22 name: 'My Collection',\n23 uri: 'https://example.com/collection.json',\n24 plugins: [\n25 { type: 'BubblegumV2' },\n26 {\n27 type: 'Royalties',\n28 basisPoints: 500, // 5%\n29 creators: [{ address: umi.identity.publicKey, percentage: 100 }],\n30 ruleSet: ruleSet('None'),\n31 },\n32 ],\n33}).sendAndConfirm(umi)\n34\n35// sellerFeeBasisPoints is omitted — the SDK sends the inherit sentinel (65535).\n36await mintV2(umi, {\n37 collectionAuthority: umi.identity,\n38 leafOwner: umi.identity.publicKey,\n39 merkleTree: merkleTree.publicKey,\n40 coreCollection: collectionSigner.publicKey,\n41 metadata: {\n42 name: 'My NFT',\n43 uri: 'https://example.com/my-nft.json',\n44 collection: some(collectionSigner.publicKey),\n45 creators: [], // must be empty when inheriting royalties\n46 },\n47}).sendAndConfirm(umi)\n48\n49// cNFT minted with SELLER_FEE_BASIS_POINTS_INHERIT (65535) on the leaf\nYou can still pass an explicit sellerFeeBasisPoints to override the collection default for a single mint.Collection removalA cNFT with inherited seller fees cannot be removed from its collection until the seller fee is updated to an explicit value. See Managing Collections and Updating Compressed NFTs.Get Asset ID and Leaf Schema from mint transaction You can retrieve the leaf and determine the asset ID from the mintV2 transaction using the parseLeafFromMintV2Transaction helper. This function parses the Transaction, therefore you have to make sure that it has been finalized before calling parseLeafFromMintV2Transaction.Transaction finalizationPlease make sure that the transaction has been finalized before calling parseLeafFromMintV2Transaction.Get leaf schema from mint transactionimport {\n mintV2,\n parseLeafFromMintV2Transaction,\n} from '@metaplex-foundation/mpl-bubblegum';\n\nconst { signature } = await mintV2(umi, {\n // ... see details above\n}).sendAndConfirm(umi);\n\nconst leaf = await parseLeafFromMintV2Transaction(umi, signature);\nconst assetId = leaf.id;\nNotesThe Bubblegum Tree must be created before minting. See Creating Trees.For collection mints, the MPL-Core collection must have the BubblegumV2 plugin enabled.To inherit royalties from a collection, the collection must also have the Royalties plugin and the leaf's creators array must be empty.The collection authority must sign the transaction when minting to a collection, regardless of whether the tree is public or private.Use parseLeafFromMintV2Transaction only after the transaction is finalized, not just confirmed.FAQHow do I mint a compressed NFT to a collection?Use the mintV2 instruction with the coreCollection parameter set to your MPL-Core collection address and provide the collectionAuthority signer. The collection must have the BubblegumV2 plugin enabled.How do I get the asset ID after minting?Use the parseLeafFromMintV2Transaction helper after the transaction is finalized. It parses the transaction and returns the leaf schema including the asset ID via leaf.id.Can anyone mint from my tree?Only if the tree was created with public: true. For private trees, only the Tree Creator or Tree Delegate can mint cNFTs.What metadata fields are required for minting?The MetadataArgsV2 struct requires: name (string), uri (string pointing to JSON metadata), sellerFeeBasisPoints (0-10000, or omit when minting to a collection to inherit from its Royalties plugin), collection (public key or none), and creators (array of creator objects; must be empty when inheriting royalties).Can a cNFT inherit royalties from its MPL-Core collection?Yes. When minting with coreCollection, omit metadata.sellerFeeBasisPoints and leave metadata.creators empty. The SDK stores SELLER_FEE_BASIS_POINTS_INHERIT (65535) on the leaf. The collection must have the Royalties plugin. See Inheriting royalties from the collection.GlossaryTermDefinitionmintV2The Bubblegum V2 instruction for minting compressed NFTs, replacing the V1 mint instructionsMetadataArgsV2The metadata structure passed to mintV2, containing name, URI, royalties, collection, and creatorsSELLER_FEE_BASIS_POINTS_INHERITSentinel value 65535 (0xffff) stored on-chain to indicate royalties are inherited from the MPL-Core collectionCollection AuthorityThe signer authorized to manage the MPL-Core collection — required when minting to a collectionBubblegumV2 PluginAn MPL-Core collection plugin that enables Bubblegum V2 features (freeze, soulbound, royalties)Asset IDA PDA derived from the merkle tree address and leaf index, uniquely identifying a compressed NFTLeaf SchemaThe data structure stored as a leaf in the merkle tree, containing the cNFT's hashed metadata and ownership info","tokens":2795,"squid":"dotcat","role":"Tooling Spider","at":1791347890869,"hash":"438347604be0afd42799cdacd8fc648b4611941c"}
{"url":"https://www.metaplex.com/docs/smart-contracts/bubblegum-v2/sdk/rust","domain":"metaplex.com","title":"Rust SDK - MPL-Bubblegum V2 - Metaplex","text":"SummaryThe MPL-Bubblegum V2 Rust SDK provides instruction builders for local scripts and CPI builders for on-chain programs interacting with compressed NFTs.Install via Cargo: cargo add mpl-bubblegumUse Builder types for local scripts and CpiBuilder types for on-chain CPIFull instruction reference available on docs.rsMetaplex provides a Rust library that can be used to interact with the MPL-Bubblegum program. The Rust library can be used in Rust scripts/builds as well as onchain programs via CPI instructions.InstallationThe MPL-Bubblegum Rust SDK can be used in both scripts/desktop/mobile applications as well as with Solana onchain programs.cargo add mpl-bubblegum\ncrates.ioGet started with our MPL-Bubblegum Rust crate.docs.rsThe Rust SDK typedoc platform for MPL-Bubblegum.Local ScriptsFor local scripts, we recommend using the Builder versions of all the instructions listed. These builders abstract a lot of the work for you and return an instruction that can be added to a transaction.A list of all Bubblegum instructions can be found here: MPL-Bubblegum - Rust InstructionsFor a more comprehensive guide on using Rust check out the Metaplex Rust SDKs Guide page.CreateTreeConfigBuilder - Exampleuse mpl_bubblegum::{instructions::CreateTreeConfigV2Builder, programs::{SPL_ACCOUNT_COMPRESSION_ID, SPL_NOOP_ID}};\nuse solana_client::{nonblocking::rpc_client, rpc_config::RpcSendTransactionConfig};\nuse solana_sdk::{commitment_config::CommitmentConfig, pubkey::Pubkey, signature::Keypair, signer::Signer, system_program, transaction::Transaction};\n\n#[tokio::main]\npub async fn create_tree(keypair: Keypair) {\n let rpc_client = rpc_client::RpcClient::new(\"https://api.devnet.solana.com/\".to_string());\n\n let payer = keypair;\n\n let asset = Keypair::new();\n\n let merkle_tree = Keypair::new();\n\n let tree_config = Pubkey::find_program_address(\n &[\n &merkle_tree.pubkey().to_bytes(),\n ],\n &mpl_bubblegum::ID,\n );\n\n let create_tree_config_ix = CreateTreeConfigV2Builder::new()\n .merkle_tree(merkle_tree.pubkey())\n .tree_config(tree_config.0)\n .payer(payer.pubkey())\n .max_depth(20)\n .max_buffer_size(1024)\n .public(false)\n .instruction();\n\n let signers = vec![&asset, &payer];\n\n let last_blockhash = rpc_client.get_latest_blockhash().await;\n\n let create_tree_config_tx = Transaction::new_signed_with_payer(\n &[create_tree_config_ix],\n Some(&payer.pubkey()),\n &signers,\n last_blockhash.unwrap(),\n );\n\n let res = rpc_client\n .send_transaction_with_config(&create_tree_config_tx, RpcSendTransactionConfig {\n skip_preflight: false,\n preflight_commitment: Some(CommitmentConfig::confirmed().commitment),\n encoding: None,\n max_retries: None,\n min_context_slot: None,\n })\n .await\n .unwrap();\n\n println!(\"Signature: {:?}\", res);\n}\nCPI (Cross Program Invocation)Performing CPI instructions from your own programs can be achieved easily by using the CpiBuilder version of an instruction function that can be found for all instructions in the MPL-Bubblegum Rust crate.A list of all Bubblegum instructions can be found here: Metaplex Bubblegum - Rust InstructionsFor a more comprehensive guide using Metaplex crates to create CPI instructions check out the How to CPI into a Metaplex Program guide page.CreateTreeConfigCpiBuilder - ExampleCreateTreeConfigV2CpiBuilder::new()\n .merkle_tree(context.accounts.merkle_tree)\n .tree_config(context.accounts.tree_config)\n .payer(context.accounts.payer)\n .tree_creator(context.accounts.tree_creator)\n .log_wrapper(SPL_NOOP_ID)\n .compression_program(context.accounts.compression_program)\n .system_program(context.accounts.system_program)\n .max_depth(20)\n .max_buffer_size(1024)\n .public(false)\n .invoke()","tokens":909,"squid":"dotcat","role":"Tooling Spider","at":1791347900849,"hash":"270c3ceaafb5aa1fc7e89cc26f8934e44372ce0f"}
{"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":"spider-06","role":"Security Spider","at":1791347901034,"hash":"3b683a823ef6288064379c0730938cdb40e3b3ab"}
{"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 56\n\n 27d\n\n [Request For Comments] - Contract Composition in Core Solidity\n\n Uncategorized\n\n 6\n\n 246\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 94\n\n Aug 4\n\n ABI Encoding Under Rising Calldata Costs\n\n Uncategorized\n\n 2\n\n 211\n\n Jul 20\n\n Is Core Solidity versioned as Solidity 0.9?\n\n Uncategorized\n\n 3\n\n 123\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 82\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 192\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 120\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 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 What Solidity try/catch actually catches\n\n Code Wizards\n\n 1\n\n 121\n\n May 29\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 102\n\n Apr 29\n\n The Annual Solidity Survey is live!\n\n Announcements\n\n 2\n\n 122\n\n Apr 27\n\n Solidity Developer Survey 2025 Results\n\n Announcements\n\n 2\n\n 148\n\n Apr 27\n\n Solidity v0.8.34 is out! \n\n Announcements\n\n 1\n\n 144\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 122\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 182\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 379\n\n Feb 26\n\n Request new syntax for Solidity\n\n Uncategorized\n\n 3\n\n 194\n\n Feb 17\n\n Solidity v0.8.33 is out! \n\n Announcements\n\n 0\n\n 181\n\n Dec 2025\n\n Solc-bin binaries hosting migration on 09/12/2025\n\n Announcements\n\n 0\n\n 125\n\n Dec 2025\n\n Solidity v0.8.31 is out! \n\n Announcements\n\n 0\n\n 138\n\n Dec 2025\n\n [Call for feedback] Core Solidity Deep Dive\n\n Uncategorized\n\n 5\n\n 614\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 110\n\n Oct 2025","tokens":1568,"squid":"spider-05","role":"Spec Spider","at":1791347911995,"hash":"9a89a9e9a2706cfd874202b1d6bdd99cd1c00a81"}
{"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":"spider-06","role":"Security Spider","at":1791347915621,"hash":"b47d5da1d68c5ad535f7b94d9b1aa672c7c4a7d8"}
{"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 934\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":"spider-05","role":"Spec Spider","at":1791347923832,"hash":"4a322ec136f3b10920d24d606c331927e7c4b7ca"}
{"url":"https://forum.soliditylang.org/t/can-someone-explain-how-via-ir-works/1898/1","domain":"forum.soliditylang.org","title":"Can someone explain how via-ir works? - Tools & Infrastructure - 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 Can someone explain how via-ir works? \n\n Tools & Infrastructure\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n Oct 2023\n\n 1 / 5\n\n Oct 2023\n\n Dec 2025\n\n post by marjon-call on Oct 5, 2023\n\n marjon-call\n\n I have been trying to read into how via-ir works by reading the solidity docs, but I am confused how it works exactly. I see that you can avoid stack too deep errors by enabling it. From what I understand, it is because the optimizer uses yul to manage the variables state in memory instead of the stack. If that is correct, does using it create any security vulnerabilities for memory mismanagement? Has this been tested out or are there ways to test it? Is it secure for deploying a smart contract to mainnet?\n\n 2\n\n post by barakman on Oct 6, 2023\n\n barakman\n\nIt is enabled in several contracts deployed by various renowned vendors (uniswap, etc).\nIt is not enabled by default in the current most recent compiler version (0.8.21).\n\nNeither one of these two points answers your question directly, and in fact, each one of them implies towards a different conclusion. But you may still want to take them into consideration.\nNote that there are some known technical issues (not specific to security though), related to enabling it along with the optimizer; see for example this issue on HardHat’s GitHub repository.\n\n post by cameel on Oct 6, 2023\n\n cameel\n\n Solidity Compiler Team\n\n The two major issues holding us back from making it the default are really the performance (still not good enough) and some adjustments needed in the Yul->EVM transform (i.e. you can still run into “Stack Too Deep” in some corner cases).\n\nHas this been tested out or are there ways to test it? Is it secure for deploying a smart contract to mainnet?\n\nThere are no unresolved security issues. It has been thoroughly tested and we consider it on par with the legacy pipeline in this regard.\n\n 2 years later\n\n post by drlambo on Nov 21, 2025\n\n drlambo\n\n hi, sorry to revive this thread.\nwhat is the current recommendation when you are forcibly using viaIR to avoid stack too deep errors?\nFor context I own an SDK that takes about 15s to compile, which I do not think is that long, but some users say the viaIR feature is experimental and do not want to use my code because it is not yet mainstream.\nthese developers are using legacy code that runs without viaIR at the expense of higher gas cost from optimizations in a newer SDK. So I wanted to know if my team should really focus as many efforts on solving stack too deep with pure debugging and Yul, or if in this case my users are in the wrong.\n\n 9 days later\n\n post by cameel on Dec 1, 2025\n\n cameel\n\n Solidity Compiler Team\n\nsome users say the viaIR feature is experimental and do not want to use my code because it is not yet mainstream.\n\nThe IR pipeline has been considered production ready since 0.8.13, which was released 3.5 years ago.\nI think there is some confusion stemming from the fact that it is still not the default pipeline. But that has nothing to do with it being experimental or not. It’s simply not fast enough yet. We need to get the compilation time down to acceptable levels before we do that. The way its implemented also makes it a bit harder for debuggers to track variables on the stack, so it really needs ethdebug. It is superior to the evmasm pipeline in other aspects though. You should really not hold back with switching to it if you can live with those two downsides and it will only get better from here.\nWe are working on addressing the compilation time - it’s actually our main backend effort right now, in the form of the SSA-CFG stage of the pipeline, which will let us bypass some of the limitations of the current Yul optimizer. There was a presentation about it on Solidity Summit and we will also publish more about it on our blog soon.\nBTW, we are also in the process of introducing the --experimental flag to more explicitly delineate what is and isn’t an experimental feature. Hopefully this will prevent misconceptions like this in the future. Though the fact that --via-ir used to be called --experimental-via-ir in past and the experimental part was dropped from it should be a hint too \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 247\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 379\n\n Feb 26\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 Developer Survey 2025 Results\n\n Announcements\n\n 2\n\n 148\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 Tools & Infrastructure or view latest topics.","tokens":2074,"squid":"spider-05","role":"Spec Spider","at":1791347936923,"hash":"0e70ad6312dbc5261684d584bbeb82750ea49f9e"}
{"url":"https://docs.jup.ag/user-docs/trade/gacha/shipping","domain":"docs.jup.ag","title":"Shipping - Jupiter Documentation","text":"Any card in your Collection can be redeemed to have the physical card shipped to your address. Shipping is operated end to end by the provider the card came from, and that provider also handles shipping support. Where you start the shipment depends on the provider:\n\nCollector Crypt cards (the Pokemon packs from Silver to Immortal, the Watch packs, and the One Piece Straw Hat, Emperor, and Gorosei packs) are shipped from Jupiter Gacha, with the Ship home action in your Collection. Collector Crypt ships them from its vaulting partners such as PSA Vault or OmniVault.\nPhygitals cards (the Sport packs, Pokemon Trainer, the Riftbound packs, and One Piece Throne) cannot be shipped from Jupiter Gacha. You redeem them through Phygitals directly, which ships them from its US vault partners PSA Vault, Fanatics Vault, and Alt Vault.\n\nJupiter is not involved in the physical logistics of either provider.\n​How to ship a Collector Crypt card home\n1Verify your walletOpen Collection, then the Shipping tab. The first time, you verify your wallet by signing a message with Collector Crypt so your outbound shipments can load. This is a message signature only: no transaction is sent and no fee is charged for the verification itself.A Ledger connected to jup.ag cannot sign this verification message: the Solana app on the device only signs transactions, and the request fails with The app’s signature request cannot be shown due to invalid formatting. This also applies when the Ledger is used through another wallet app, since the device does the signing. The Jupiter team is working on it. In the meantime, open a ticket at support.jup.ag with your wallet address, your wallet app, and your Ledger model.2Redeem the cardUse the Ship home action and select the card or cards to redeem. Shipping multiple cards in one shipment costs less than shipping them separately, because the per-shipment base fee is paid once.3Enter your shipping addressProvide the delivery address. No KYC is required, only a shipping address. Collector Crypt ships worldwide, with fees set by zone: United States, Canada, Europe, Australia and New Zealand, and the rest of the world. A few destinations are restricted: an address in one of them is refused at this step with the message “Sorry, we do not ship to [country] at this time”, before any fee is paid or card burned. The address goes directly to Collector Crypt: see Your shipping data.4Pay the shipping feeShipping fees depend on your zone, plus a fee for each additional card in the same shipment. The exact amount is displayed in the Ship home flow before you confirm the shipment.International deliveries can incur customs or import duties charged by the destination country. These are set by local authorities, are not included in the shipping fee, and are payable by the recipient on delivery. See Customs and declared value.5Track the deliveryThe shipment appears in the Shipping tab with its status, estimated delivery, and a tracking link, typically UPS. The tracking number appears once the vault holding the card has handed the package to the carrier.\n​Shipping a Phygitals card\nJupiter Gacha has no shipping flow for cards pulled from a Phygitals pack: the Ship home action in your Collection only lists Collector Crypt cards. To receive a Phygitals card at home, redeem it through Phygitals’ own claim process at phygitals.com, documented on its Shipping & Redemption page. In summary:\n\nYou provide a shipping address, an email address, and a phone number. Every address field must be written in Latin characters, and PO boxes may not be supported.\nShipping fees, where they apply, are displayed before you confirm. Phygitals adjusts them to carrier rates and destination.\nEach vault ships its own package, so a claim covering cards held in different vaults can arrive as several parcels. Redeeming several cards at once avoids paying several shipping fees.\nA tracking number is emailed to you when the shipment is dispatched.\nShipments are insured in transit for the declared value of the cards, which is Phygitals’ fair market value at the time of shipment.\nOnce the claim is processed, the card’s token is permanently retired.\n\nUngraded cards can be redeemed like graded ones. For help with a Phygitals claim, contact Phygitals through phygitals.com/contact.\n​Delivery times\nCollector Crypt estimates around 2–3 weeks for a delivery within the United States and around 5 weeks for an international delivery. A large part of the time is vault processing, which happens before the package is handed to a carrier: the vault has to pull the slab, pack it, and release it. Collector Crypt does not control how fast each vault works, which is also why a shipment cannot be expedited.\nPhygitals estimates, for deliveries within the United States, around 2–3 weeks from PSA Vault and around 1–2 weeks from Fanatics Vault or Alt Vault, processing included. International shipments take an additional 1–4 weeks depending on the country, and tracking visibility can be limited once a package crosses borders.\nThese are estimates, not guarantees.\n​Cards from different vaults ship separately\nCards are held by different vaulting partners. For a Collector Crypt card, the vault is listed in the Vault details section of the card’s page; Phygitals cards are held with PSA Vault, Fanatics Vault, or Alt Vault. When you redeem several cards at once, each vault ships its own package. One shipment can therefore arrive as several packages, with separate tracking numbers and different delivery dates. Receiving part of your cards first is expected: check the remaining tracking numbers before contacting the provider’s support.\n​Shipment statuses\nEach Collector Crypt shipment is a card in the Shipping tab, listed under Active until it is delivered or cancelled, then under Completed. The card shows the status, the cards included, the amount paid, a progress line (Payment Received, Processing, Pending Shipment, Shipped, Delivered) and the tracking link once the carrier has the package. Expand the card for the order ID, the delivery address, the carrier and the tracking number.\nStatusMeaningPending PaymentThe request exists but the shipping fee payment has not been confirmed yet.Payment ReceivedThe fee is paid and the card burned. The vault has been asked to pull the card.Processing, Pending ShipmentThe vault is pulling, packing and releasing the card. The package has not been handed to the carrier yet.In TransitThe carrier has the package. The tracking number and link are shown.DeliveredThe carrier reported the delivery.Action RequiredCollector Crypt needs something from you before the shipment can continue. Contact its support with the order ID.CancelledCollector Crypt cancelled the request.\n​Cancelling or changing a shipment\nJupiter Gacha has no control to cancel a shipment or change its address once it is submitted. The Ship home flow signs the card burn and the shipping fee payment in a single wallet prompt, so by the time the shipment appears in the Shipping tab the card has already left your wallet and the request is with Collector Crypt, which handles it from that point.\nTo ask for a cancellation or an address change, contact Collector Crypt support as early as possible, through the chat widget at the bottom right of collectorcrypt.com or at support@collectorcrypt.com, with the order ID from the shipment card. Collector Crypt decides whether the request can still be stopped, which depends on how far the vault has got: a shipment in Processing or Pending Shipment is still being prepared, while a shipment In Transit is already with the carrier. If Collector Crypt cancels a request, its status changes to Cancelled in the Shipping tab. What happens to the card and to the fee in that case is decided by Collector Crypt, not by Jupiter.\n​Customs and declared value\nEvery package is declared at the value of the cards it contains: the insured value recorded by Collector Crypt at the time of redemption for a Collector Crypt card, Phygitals’ fair market value at the time of shipment for a Phygitals card. Neither provider declares a shipment as a gift or at a lower value, because the shipment is insured in transit for the declared amount. Any customs or import duties charged by the destination country are calculated on that value and are payable by the recipient; the providers do not collect or remit import taxes.\nIf you ship to a package forwarding service rather than your own address, Collector Crypt’s insurance covers the package only up to the forwarder. Anything that happens to the card after that point, including damage in the forwarder’s own onward shipment, is not covered.\n​What redeeming means\nRedeeming a card converts your on-chain ownership into physical possession. Once the physical card is shipped to you, the card leaves the Jupiter Gacha system: it can no longer be sold back through the buyback or, for a Collector Crypt card, sold on the marketplace, since the card is no longer vaulted. Phygitals permanently retires the token of a claimed card.\nThere is no deadline to redeem. A card can stay vaulted in your Collection indefinitely at no storage cost, and you can ship it whenever you choose.\n​Your shipping data\nThe personal details you enter to ship a card home (name, delivery address, contact information) are collected and processed by the provider operating the shipment: Collector Crypt for its cards, Phygitals for its cards. Jupiter never receives or stores this data: nothing is kept in Jupiter’s databases or logs.\nTo ask what shipping data a provider holds about you, or to request its deletion, contact that provider: Collector Crypt through the chat widget at the bottom right of collectorcrypt.com, Phygitals through phygitals.com/contact.\n​Shipping support\nThe provider that ships a card is responsible for its shipping logistics and shipping support, including questions about delays, customs, and delivery issues.\n\nCollector Crypt cards: use the chat widget at the bottom right of the Collector Crypt app at collectorcrypt.com.\nPhygitals cards: use phygitals.com/contact.\n\nFor anything else related to Jupiter Gacha, Jupiter support remains your contact point.","tokens":2546,"squid":"spider-02","role":"Liquidity Spider","at":1791347940982,"hash":"69ddeb008d4765271f7475e505cb64811f3f4c78"}
{"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 573\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":"spider-05","role":"Spec Spider","at":1791347948096,"hash":"4c22cbdcba0b0e3e6ac492b17c43c36cf62ef473"}
{"url":"https://ethresear.ch/t/why-enshrine-proposer-builder-separation-a-viable-path-to-epbs/15710","domain":"ethresear.ch","title":"Why enshrine Proposer-Builder Separation? A viable path to ePBS - Proof-of-Stake - Ethereum Research","text":"Why enshrine Proposer-Builder Separation? A viable path to ePBS \n\n Proof-of-Stake\n\n proposer-builder-separation\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n May 2023\n\n 1 / 30\n\n May 2023\n\n Dec 2023\n\n post by mikeneuder on May 25, 2023\n\n mikeneuder\n\n Why enshrine Proposer-Builder Separation? A viable path to ePBS\nby mike neuder and justin drake; may 25, 2023\ntl;dr; Proposer-Builder Separation (PBS) decouples the task of block proposing (done by PoS validators) from block building (done most profitably by MEV searchers). PBS aims to improve access to MEV for validators by explicitly creating a permissionless market for block production. By allowing proposers to outsource block construction, validators can continue running on consumer-grade hardware without missing out on the valuable MEV exposed while they are the elected proposer. mev-boost implements out-of-protocol PBS and accounts for ≈90% of Ethereum blocks. Enshrined PBS (ePBS, sometimes referred to as in-protocol/IP PBS) evolves the consensus layer to implement PBS at the protocol level. While ePBS has been discussed since 2021 and is part of Ethereum’s roadmap, recent events (Low-Carb Crusador, Shapella mev-boost prysm signature bug, & relay response to unbundling) have turned the attention of the Ethereum community towards mev-boost and the evolution of PBS.\nThis document aims to…\n[a] outline arguments for ePBS (as opposed to continuing with mev-boost),\n[b] present and respond to the counter-arguments to ePBS,\n[c] describe desirable properties of ePBS mechanisms,\n[d] sketch an ePBS design based on the existing research,\n[e] highlight optimistic relaying as an additional tool to build towards ePBS, and\n[f] encourage discussions around the ePBS design space.\nThis document does not aim to…\n[a] perform an exhaustive literature review (see here),\n[b] fully spec out an ePBS implementation, or\n[c] cover alternative designs for ePBS.\nMany thanks to Barnabé, Dan Marzec, Terence, Chris Hager, Toni, Francesco, Rajiv, Thomas, and Jacob for comments on draft versions of this document.\n\nIntroduction\nupload_9a682b56f269faafefdaaffcdac52a082496×418 126 KB\nProposer-Builder Separation (PBS) allows validators to outsource their block building duties to a set of specialized builders who are well equipped to extract MEV (hence separating the roles of proposer and builder). Proposers sell their block-production rights to builders who pay for the privilege of choosing the transaction ordering in a block. Proposers earn MEV rewards in addition to their protocol issuance, and block builders compete to assemble valuable blocks while saving a portion of the MEV for themselves as profit.\n\nEnshrined PBS\nEnshrined PBS (ePBS) advocates for implementing PBS into the consensus layer of the Ethereum protocol. Because there was no in-protocol solution at the time of the merge, Flashbots built mev-boost, which became a massively adopted out-of-protocol solution for PBS that accounts for ≈90% of Ethereum blocks produced.\n\nupload_1a170bd1d4ae5f23cc52d66e4cc0ed521800×700 61.9 KB\nFigure 1 – mev-boost slot share (orange) since the merge. Source mevboost.pics.\nmev-boost continues to be critical infrastructure provided to grant permissionless access to the external block-building market for all validators, but it relies heavily on a small set of centralized relays to act as mutually-trusted auctioneers facilitating the block-production pipeline. We present the case for ePBS by highlighting (i) that relays are antithetical to Ethereum’s core values, (ii) the risks and inefficiences of side-car software, and (iii) the costs and unsustainability of relay operations.\nReasons to enshrine\n\nRelays oppose Ethereum’s values. The following core tenants of Ethereum are eroded by the mass dependence on relays.\n\nDecentralization: Relays are centralized. Six relays, operated by five different entities, account for 99% of mev-boost blocks. This small consortium of relay operators should not play such an outsized role in the ecosystem.\nCensorship resistance: Relays can censor blocks. Since relays are centralized, they are exposed to regulation. This played out post-merge as some relays were pressured to censor transactions interacting with addresses on the OFAC sanctions list.\nTrustlessness: Relays are trusted by validators and builders. Validators trust relays to provide them a valid block header and to publish the full beacon block; builders trust relays not to steal MEV. A violation of either of these trust assumptions would be detectable, but as demonstrated by the “Low-Carb Crusader”, dishonesty can be profitable, even if only through a one-time attack.\n\nOut-of-protocol software is brittle.\n\nThe “Low-Carb Crusader” unbundling exploited a relay vulnerability for 20+ million USD. This attack and the general class of equivocation attacks it embodies demonstrate that relays are valuable targets outside of the protocol.\nThe relay response to the unbundling attack caused consensus instability. Due to relay-induced latency into the block-production pipeline, there was a 5x increase in reorged blocks immediately after the attack. See “Time, slots, and the ordering of events in Ethereum Proof-of-Stake” for more details.\nDuring the Shapella upgrade, there was a bug in the Prysm code that interacts with mev-boost. This resulted in a brief 10x spike in missed slots immediately following the hard-fork. This bug was not caught because the code path for externally-built blocks is not covered by the consensus spec tests.\nThere are significant core-dev coordination costs involved in maintaining compatiblity between beacon clients & relays. Each hard-fork represents a significant amount of work from the relay and core developers to ensure mev-boost continues functioning. This involves designing the builder spec, maintaining/improving the relay spec, and the software changes on the beacon clients, mev-boost, and the mev-boost relays. Because mev-boost is out-of-protocol, this coordination is strictly additive to the standard ACD pipeline and usually happens later in the development cycle as a result.\nmev-boost does not inherit the benefits of client diversity and the full consensus specification process. Though there are multiple relay repositories, the vast majority of blocks flow through relays using the flashbots implementation. While this is simpler to maintain, it lacks the structural benefits of client diversity enjoyed by the beacon nodes; the full specification/spec-test infrastructure is also not leveraged by the differing relay repositories.\n\nRelays are expensive public goods.\n\nRelay operational costs range from ≈20k-100k USD per-year depending on the desired performance. This doesn’t include engineering and DevOps costs associated with running a highly-available production service.\nRelays are public goods that don’t have a clear funding model. While there are discussions around guilds, grants, and other funding vehicles, there is no obvious way to support relay development and operation (similar to the issues faced in supporting core-dev teams).\n\n~~ ePBS resolves these issues by eliminating the relay. ~~\nNote: MEV burn is currently being explored for its economic & security benefits. If we decide to pursue MEV burn, these benefits serve as yet another carrot on a stick for enshrinement.\nReasons not to enshrine\nWe believe it is important to highlight the counter-point of enshrinement by addressing the main arguments and presenting our responses.\n\n“If it ain’t broke don’t fix it.” mev-boost has worked incredibly well given the scale of its adoption. As the implementation continues to harden, we can gain confidence in its security properties and build out the specification. If we can find a credibly neutral way to fund a set of relays, then we could continue depending on them into the future.\n\nResponse – mev-boost has worked well, but there are no guarantees that this stability will continue. Another major censorship event, further attacks, and continued centralization pressures of relays, builders, and searchers pose significant risks to Ethereum. There is value in having clarity about ePBS to handle a situation where there is a pressing need for faster enshrinement. Additionally, ePBS will take time to design and implement – we should start formalizing it now, even if we continue with the relays for the next O(1-2 \\; years)𝑂(1 −2 𝑦𝑒𝑎𝑟𝑠) as ePBS progresses.\n\nCould MEV be addressed with different tools? There is a growing discourse around protecting users from MEV on the application/transaction level. SUAVE, CoW swap, and MEVBlocker are three of many solutions that are continuing to gain usage. If a significant portion of MEV can be protected against, perhaps enshrining PBS is an unnecessary step on an already ambitious roadmap.\n\nResponse – We hope that this line of work can help protect users from “toxic” MEV, but we don’t expect on-chain MEV to ever be fully eliminated. Further, some MEV is extracted off-chain, requiring sophistication beyond just computational power. For example, in order to execute a CEX-DEX arbitrage, a validator would need liquidity and connectivity with a CEX in addition to the algorithmic resources to find and execute such an opportunity. We don’t envision a future in which there is little to no MEV in Ethereum or a solo-staking validator could meaningfully extract it on their own.\n\nThere are other roadmap items that should take precedence. The roadmap has many goals beyond ePBS. If we choose to go ahead with ePBS, it begs the question of where this can fit on the roadmap and what upgrades will be pushed down the line as a result.\n\nResponse – We believe that ePBS depends on Single-Slot Finality (SSF) for security and complexity reasons. Additionally, a validator set consolidation is a prerequisite for any SSF progress (see Increase the MAX_EFFECTIVE_BALANCE). The resource allocation problem is difficult, but we believe that ePBS should be part of these discussions, especially in the context of being bundled (pun-intended) with a larger consensus upgrade.\n\nWhat is the right thing to enshrine? From a protocol design perspective, there are many mechanisms that could be implemented. Barnabé explores these concepts in “Unbundling PBS”, “Notes on Proposer-Builder Separation”, and “Seeing like a protocol”. One takeaway from this work is that mev-boost implements a block-auction, which is not the only option for ePBS. Julian explores this further in “Block vs Slot Auction PBS”.\n\nResponse – ePBS is only useful insofar as it is adopted by builders and validators; the worst-case scenario is that ePBS is sidestepped by out-of-protocol solutions we didn’t foresee. While we acknowledge that any protocol upgrade has unknown-unknowns, we believe that by opening the discussion, working to achieve rough community consensus, and taking the next step in formalizing the design space of ePBS will improve confidence around what we are working towards. We also present the optimistic relay roadmap below, which takes a more iterative approach at evolving mev-boost.\n\nePBS design space\nFor extensive ePBS literature links see “Bookmarks relevent for Proposer-Builder Separation researchers”. We define the following properties as desirable:\n\nhonest builder publication safety – If an honest builder wins the auction, the builder (i) must have an opportunity to create a block, and (ii) must be confident that any payload contents they release become canonical (i.e., protection from unbundling & equivocation attacks from the proposer).\nhonest builder payment safety – If an honest builder payment is processed, the builder must be able to publish a block that becomes canonical.\nhonest proposer safety – If an honest proposer commits to a block on-time, they must receive a payment at least as large as specified by the bid they selected.\npermissionless – Any builder can participate in the auction and any validator can outsource block production.\ncensorship resistance – There must be a mechanism by which honest proposers can force through transactions they suspect are being censored without significantly sacrificing on their own rewards (“If we rely on altruism, don’t make altruism expensive” –Vitalik).\nroadmap compatibility – The design must be compatible with future roadmap upgrades (SSF, mev-burn, distributed block-building, SSLE, DAS, etc).\n\nOne design instantiation – Two-Block HeadLock (TBHL)\nWhile there are many proposed ePBS implementations, we present a small modification of the original two-slot design from Vitalik. We call it Two-Block HeadLock (TBHL) because it uses a single slot to produce two blocks. The first is a proposer block that contains a commitment to a specific execution payload and the second is a builder block that contains the actual transaction contents (here we just call the overall pair of blocks a “single” slot because only one execution payload is produced). Note that with a second round of attestations, the slot time will likely need to increase. TBHL also incorporates some of the features of headlock to protect builders from proposer equivocations. TBHL shares many components with the current mechanism (HLMD-GHOST) and satisfies the six properties specified above.\nNote: This is a sketch of the design; it is intentionally brief to improve readability. If we gain confidence that TBHL is a good overall approach, we can begin the specification and full security analysis. The aim is to present a simple, concrete example of a mechanism that satisfies the ePBS design properties, without overloading the reader with implementation details.\n\nupload_8955ce1c08fe500e9aa8cbe27d31032f1205×1314 119 KB\nFigure 2 – The slot anatomy of TBHL. A proposer block is proposed and attested to in the purple phase, while a builder block is proposed and attested to in the yellow phase. The proposers, attesters, and builders each make different observations at various timestamps in the slot.\n\nTBHL has the notion of proposer and builder blocks. Each slot can contain at most: one proposer block + one builder block, each of which receives attestations. The slot duration is divided into 4 periods.\nt=t_0𝑡 =𝑡0 : The proposer chooses winning bid and publishes a proposer block. The proposer starts by observing the bidpool, which is a p2p topic where builders send their bids. The proposer selects one of these bids and includes it in a block they publish before t_1𝑡1.\nt=t_1𝑡 =𝑡1 : The attesting committee for the proposer block observes for a timely proposal. This is the equivalent of the “attestation deadline” at t=4 in the current mechanism. If at least one block is seen, the attesting committee votes for the first one that they saw. If no block is observed, the attesting committee votes for an empty slot (this requires block, slot voting).\nt=t_{1.5}𝑡 =𝑡1.5 : The attesting committee for the builder block checks for equivocations. If the attesting committee sees (i) more than one proposer block or (ii) no proposer blocks, they give no proposer boost to any subsequent builder block. If the attesting committee sees a unique proposer block, they give proposer boost to the builder associated with that bid (see “Headlock in ePBS” for more details).\nt=t_2𝑡 =𝑡2 : The builder checks if they are the unique winner. If a builder sees an equivocation, they produce a block that includes the equivocation as proof that their unconditional payment should be reverted. Otherwise, the builder can safely publish their builder block with a payload (the transaction contents). If the builder does not see the proposer block as the head of the chain, they publish an empty block extending their head (see “Headlock in ePBS” for more details).\nt=t_3𝑡 =𝑡3 : The attesting committee for the builder block observes for a timely proposal. This is a round of attestations that vote for the builder block. This makes t_3𝑡3 a second attestation deadline.\nWe can assert that this mechanism satisfies the ePBS design properties.\n\nhonest builder publication safety – The only situation where builder safety could be in question is if the proposer equivocates. For brevity, the details of the equivocation protection are left out of this document. Please see “Headlock in ePBS”.\nhonest builder payment safety – If an honest builder is selected and their payment is processed, they will either (i) see no equivocations and have the opportunity to create a block with confidence that they are the unique recipient of proposer boost or (ii) see an equivocation and use it as proof to revert the payment. Again, please see “Headlock in ePBS” for further details.\nhonest proposer safety – If an honest proposer commits to a block on-time, their block will receive attestations and the unconditional payment will go through without reversion because the builder will not have any proof of an equivocation. Even if the builder block is not produced, the bid payment occurs so long as no equivocation proof is presented.\npermissionless – The p2p layer is permissionless and any builder can submit bids to the bidpool. Any validator can listen to the bidpool if they want to outsource block building, or they can choose to build locally instead.\ncensorship resistance – The proposal is compatible with censorship resistance schemes. For example, the proposer block could contain a forward inclusion list. See “PBS censorship-resistance alternatives” for more context.\nroadmap compatiblity – SSF fits naturally with this proposal by adding a third round of attestations after the builder block attestation round. The third round includes the full validator set and justifies the block immediately with a supermajority consensus. See “A simple Single Slot Finality protocol” for more details. This mechanism is also highly compatible with mev-burn, as the base fee floor deadline, D𝐷, could precede t_0𝑡0.\n\nOptimistic relaying – an iterative approach to PBS\nThe design framework and TBHL presented above provide a “top-down” approach to ePBS. This has historically been the way R&D is done in Ethereum. Once the design is fleshed out, a spec is written, and the client teams implement it.\nThe existence of mev-boost and in particular mev-boost relays gives us an interesting additional angle to approach the problem – “bottom-up”. We can imagine there are many PBS implementations that lie on a spectrum between the original mev-boost implementation and full ePBS. By modifying the relay, we can move “up” towards an ePBS implementation without needing to modify the spec and make changes to the consensus node software. This allows us to forerun and derisk some of the features of a full ePBS system (e.g., are builders OK with us removing cancellations?) while also remaining agile. This objective has already been presented in the optimistic roadmap.\nThe main theme of the optimistic roadmap is to remove relay responsibilities. This has the added benefit of improving the operational efficiency of running a relay. As mentioned in “Reasons to enshrine,” relay operation is expensive and is currently being done only as a public good. By lowering the barrier to entry for relay operaters, we enable a more sustainable future for mev-boost as we flesh out the details of ePBS.\nBlock submission in mev-boost\nBefore describing optimistic relaying, we briefly present the builder bid submission pipeline in the mev-boost-relay. Processing builder bids is the main function of the relay, and incurs the highest latency and compute costs. When a builder submits a bid to the relay the following occurs.\n\nupload_29875d098550a358c78c57236b4879251489×902 72.7 KB\nFigure 3 – Once the builder block is received by the relay, it is validated against an execution layer (EL) client. Once it is validated, the block is eligible to win the auction and may be signed by the proposer. Once the relay receives the signed header, it publishes the block to the p2p through a consensus layer (CL) client.\n\nSince hundreds of bids are submitted each slot, the relay must (i) handle the ingress bytes of all the builder submissions, (ii) simulate the blocks on the EL clients, and (iii) serve as a data availablity layer for the execution payloads. Additionally, the validator relies on the relay to publish the block in a timely manner once they sign the header.\nOptimistic relaying v1\nThe first version of optimistic relaying simply removes the block validation step from the block submission pipeline.\n\nupload_7118043a7e81e563e4e0812a5833d1291193×785 62 KB\nFigure 4 – Once the builder block is received by the relay, it is immediately eligible to win the auction and be signed by the proposer. Once the relay receives the signed header, it publishes the block to the p2p network through a consensus layer (CL) client.\n\nThe risk incurred by skipping the block validation is that an invalid block may be unknownly signed by the validator. This results in a missed slot because the attesting committee will reject the invalid block. The relay financially protects the validator against this situation by holding builder collateral. If a bad builder block results in a proposer missing a slot, the relay uses the builder collateral to refund the proposer. Optimistic relaying v1 is already upstreamed into the Flashbot’s mev-boost-relay repository and running on ultra sound relay. See “An optimistic weekend” and “Optimistic relays and where to find them” for more details.\nOptimistic relaying endgame\nThe final iteration of optimistic relaying behaves more like TBHL. Instead of the attesting committee enforcing the rules, the relay serves as a centralized “oracle” for the timeliness of events that take place in the bidpool. The flow of a block proposal is diagrammed below.\n\nupload_dc0b3bfcb4652c9e14e6f4b370911eeb1076×818 77.9 KB\nFigure 5 – Builders now directly submit bids to the p2p layer (instead of the relay). Proposers observe these bids and sign the corresponding header of the winning bid. The builder of that signed header publishes the full block. The relay observes the bidpool and checks for timeliness of (i) the proposer’s signed header and (ii) the builder’s block publication. Notice that these observations are exactly what the attesting committee is responsible for in TBHL. The relay still holds builder collateral to refund a proposer if they sign a header on-time, but the builder doesn’t produce a valid block.\n\nEndgame optimistic relaying contains some of the ePBS machinery; proposers and builders will be interacting directly through the bidpool and relays will be implementing the validity conditions that the attesting committee would enforce at the consensus layer. Additionally, relay operation at that point is reduced to a collateralized mempool oracle service, which should be much cheaper and easier to run than the full validating relays of today.\nConclusion\nProposer-Builder Separation is an important piece of Ethereum’s roadmap and continues to gain momentum in the public discourse. This document aims to present the arguments for and against enshrinement, lay out design goals of an ePBS mechanism, present Two-Block HeadLock (a minor variant of Two-slot PBS), and describe the utility of the optimistic relay roadmap. We hope to open up the enshrinement discussion and solicit alternative ePBS proposals from the community. While these “top-down” design and specification discussions continue, we hope to move forward on the “bottom-up” approach of optimistic relaying with the goal of making relays cheaper and more sustainable in the medium-term.\nFor any questions, concerns, or corrections, please don’t hesitate to reach out on twitter or through telegram.\nthanks for reading!\n-mike & justin\n\n No free lunch – a new inclusion list design\n\n Payload-timeliness committee (PTC) – an ePBS design\n\n Game-theoretic Model for MEV-boost Auctions (MMA) \n\n Relays in a post-ePBS world\n\n Making Flashbot Relay stateless with EIP-x\n\n 12\n\n 3\n\n 2\n\n 2\n\n 2\n\n read \n\n 17\n min\n\n post by adiasg on May 25, 2023\n\n post by mikeneuder on May 25, 2023\n\n post by alvaro-blz on May 26, 2023\n\n post by mikeneuder on May 26, 2023\n\n post by timbeiko on May 26, 2023\n\n post by jannikluhn on May 27, 2023\n\n post by mikeneuder on May 29, 2023\n\n post by mikeneuder on May 29, 2023\n\n post by alvaro-blz on May 29, 2023\n\n post by fradamt on May 30, 2023\n\n post by Blanker on May 30, 2023\n\n post by Draco on May 30, 2023\n\n post by Casslin on May 30, 2023\n\n post by mikeneuder on Jun 1, 2023\n\n post by mikeneuder on Jun 1, 2023\n\n post by mikeneuder on Jun 1, 2023\n\n post by mikeneuder on Jun 1, 2023\n\n post by Draco on Jun 1, 2023\n\n post by fradamt on Jun 6, 2023\n\n Load more posts below","tokens":6160,"squid":"spider-04","role":"Research Spider","at":1791347948132,"hash":"31c4a089c8602a6ac96d3d0eac3e43123d9b56a4"}
{"url":"https://forum.soliditylang.org/t/about-the-ama-ask-me-anything-category/145/1","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 The Annual Solidity Survey is live!\n\n Announcements\n\n 2\n\n 122\n\n Apr 27\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 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 Solidity v0.8.35 is out!\n\n Announcements\n\n 0\n\n 102\n\n Apr 29\n\n [Request For Comments] - Contract Composition in Core Solidity\n\n Uncategorized\n\n 6\n\n 246\n\n Aug 25\n\n Want to read more? Browse other topics in AMA - Ask Me Anything or view latest topics.","tokens":1211,"squid":"spider-05","role":"Spec Spider","at":1791347957647,"hash":"2bdc9a45cf6807ddedcedf7127eea74034a62a7a"}
{"url":"https://docs.jup.ag/user-docs/trade/gacha/faq","domain":"docs.jup.ag","title":"FAQ and Troubleshooting - Jupiter Documentation","text":"​Access and payment\nCan I use Gacha on mobile?Yes. Open jup.ag/gacha in the Jupiter Mobile in-app browser to use Gacha on mobile.Why are packs priced in USDC?Pack prices, buybacks, and marketplace sales are denominated in USDC because it is the most widely held stablecoin.Which provider is behind a pack?The app does not name the provider. The Pokemon packs from Silver to Immortal, the Watch packs, and the One Piece Straw Hat, Emperor, and Gorosei packs come from Collector Crypt. The Sport packs, the Pokemon Trainer pack, the Riftbound packs, and the One Piece Throne pack come from Phygitals, so a category can mix the two. On a pack page, a Phygitals pack shows a 7-day buyback window and no Turbo toggle, a Collector Crypt pack a 3-day window. See Providers for everything that differs.The pack says purchases are not available in my regionThis message comes from Phygitals: purchases and buybacks on its packs follow its restricted jurisdictions policy. Collector Crypt packs are not affected by that policy. See Geographic restrictions.\n​Opening packs\nI get an error when opening a packPack opening fails for one of these reasons, in order of likelihood:\nNot enough USDC. Your wallet must hold at least the pack price multiplied by the quantity selected. If you are short, the app offers to swap the missing amount from your highest-balance token (it must be worth about 5% more than the shortfall). The Open pack button shows “Insufficient USDC” when no balance can cover it.\nNo SOL for network fees. Every opening is a Solana transaction and requires a small amount of SOL, separate from the USDC pack price.\nThe machine is temporarily disabled or sold out. A Collector Crypt machine that runs too low on higher rarity cards is disabled until Collector Crypt restocks it. A Phygitals pack out of stock shows “Sold out” until Phygitals restocks it. Try again later or open a different pack tier.\nCheck your USDC and SOL balances first, then retry.I opened a pack but the card is not in my CollectionRefresh the page. The interface can lag a few moments behind the on-chain state after an opening. Your pull is recorded on-chain the moment the transaction confirms; only the display is delayed. If the card is still missing after refreshing and a few minutes, contact support.My pull is taking a while to revealOn a Phygitals pack, Phygitals settles the opening on its side after you approve the transaction, and the app waits for its answer. The reveal usually arrives within seconds. If Phygitals reports the opening as failed, the app tells you so and the payment is refunded. If Phygitals holds the opening for review, it stays pending until Phygitals reconciles it. If the reveal does not arrive at all, check your Collection before opening again, since the card may already be there. Collector Crypt packs reveal as soon as the transaction confirms.Why is there no Turbo toggle on this pack?Turbo mode exists on Collector Crypt packs only. The Sport packs, the Pokemon Trainer pack, the Riftbound packs, and the One Piece Throne pack come from Phygitals, which has no Turbo mode. See Turbo mode.Why is Turbo mode forced on this pack?Turbo mode becomes mandatory on a machine that runs too low on common cards, until Collector Crypt restocks it. While Turbo is forced, every Common pull is automatically sold back for USDC at the machine’s buyback rate, and the app shows a notice on every opening so you are aware before you spin. The displayed odds are not affected. See Turbo mode.Do the odds change when the machine has fewer cards?No. The odds per rarity tier are fixed and guaranteed regardless of how many cards remain in the machine pool. What changes with the pool contents is which specific cards can be drawn within each tier, and the pack’s expected value.\n​Value and buyback\nWhat is the difference between insured value and market price?The card page labels a card’s value Est. value. On a Collector Crypt card, that is the insured value, a reference value assigned by Collector Crypt and used to calculate the instant buyback amount. It is not an insurance policy and not a market price. On the marketplace, sellers set asking prices freely, so a card can trade above or below its insured value. On a Phygitals card, the value shown is Phygitals’ fair market value estimate, which is the basis of its buyback offer. See Insured value.Why is the buyback window 7 days on some packs and 3 days on others?The window is set by the pack’s provider: 3 days from the pull on Collector Crypt packs, 7 days on Phygitals packs. The rate is set per pack as well and displayed in the Instant buyback panel. See Instant Buyback.A Phygitals card in my Collection shows no buyback offerPhygitals quotes the buyback as an offer on the card, and a quote can expire before the 7-day window ends. When that happens, the app hides the offer until Phygitals issues a new one: refresh the page. If the card is past 7 days from the pull, the buyback has expired.The buyback shown on my card does not match the machine's rateThe buyback rate is set per machine and displayed on each pack’s page in the Instant buyback panel. In rare cases, shortly after Collector Crypt updates insured values, the buyback amount shown on a card can temporarily not match the machine’s rate. If the buyback you are offered does not match the machine’s displayed percentage, open a ticket at support.jup.ag.My buyback window expired. What are my options?The buyback for that card is no longer available and cannot be reopened. The card remains yours and stays vaulted at no cost. A Collector Crypt card can be kept, shipped home, listed on the marketplace at a price you set, or used to borrow USDC on Offerbook directly from your Collection. A Phygitals card can be kept, sent to another wallet, redeemed through Phygitals, or listed outside Jupiter Gacha on the Phygitals marketplace, Tensor, or Magic Eden.Is the expected value a prediction of what I will pull?No. The expected value is the average pull value across the machine’s current pool, weighted by the odds. Individual pulls vary widely around it: on most packs, the majority of pulls fall in the lowest value range. The expected value also changes over time as the pool contents change.\n​Cards, custody, and authenticity\nWhere is the physical card stored?Every card is a physical card held by a professional vaulting partner. A Collector Crypt card is stored with a partner such as PSA Vault or OmniVault: open the card’s detail page and check the Vault details section to see the vault and, where available, its location. A Phygitals card (from the Sport packs or the Pokemon Trainer pack) is stored in the United States with PSA Vault, Fanatics Vault, or Alt Vault; its card page has no Vault details section.How do I know a card is authentic?Graded cards are slabs graded and authenticated by a professional grading company such as PSA, CGC, or Beckett. The card detail page shows the grading company and the grading ID, which can be verified independently on the grading company’s own certificate lookup. The Sport Practice and Pokemon Trainer packs also contain ungraded cards, which Phygitals holds in its vault partners’ custody and describes as Near Mint or Lightly Played; an ungraded card shows no grading company or grade on its page.Is every card graded?No. Every Collector Crypt card and every Sport Hall of Fame card is a graded slab. The Sport Practice ($5) and Pokemon Trainer ($10) packs from Phygitals mix graded slabs with ungraded cards. See Providers.What happens to my card if I do nothing?Nothing is required from you. The card stays vaulted with its custody partner and remains in your Collection indefinitely, at no storage cost. You can sell it or ship it at any time.Can I send a card to a friend?Yes. Each card is an NFT on Solana, whichever provider it came from, so you can transfer it from your wallet to your friend’s wallet with your wallet’s send function, the same way as any other NFT. Jupiter Gacha has no send button for cards. Delist the card first if it is listed on the marketplace, and use the instant buyback before sending if you intend to use it: it is tied to the wallet that pulled the card. The card then appears in your friend’s Collection. See Sending a card to another wallet. To give a friend packs to open instead, see Gifting packs.My card does not show in my wallet's NFT tabYour ownership is recorded on Solana and always visible in your Jupiter Gacha Collection, which is the reference view for your cards. Cards from both providers are Metaplex Core assets, not compressed NFTs, so a wallet that supports the Metaplex Core standard displays them; wallets that do not yet support it may not. Display in external wallet interfaces can therefore vary.\n​Marketplace\nWhy can't I list this card on the marketplace?The marketplace is operated by Collector Crypt and carries Collector Crypt cards. A card pulled from a Phygitals pack (Sport Practice, Sport Hall of Fame, Pokemon Trainer) has no list action on Jupiter Gacha. You can sell it back to Phygitals within 7 days of the pull, keep it, send it to another wallet, or, since it is a Solana NFT, list it on the Phygitals marketplace, Tensor, or Magic Eden. See Selling a Phygitals card elsewhere for the links and what to watch for.I bought or listed a card and the page shows a stale stateRefresh the page. After a purchase or a listing change, the interface can briefly show the previous state (for example a Manage listing button on a card you just bought). The on-chain state is correct; the display catches up after a refresh.Why did I receive less than my asking price when my card sold?Marketplace sales carry a 2% fee on the sale price, charged by Collector Crypt. A card sold at 100 USDC pays out 98 USDC. There are no other marketplace fees. See Marketplace.\n​Shipping\nWho ships my card?The provider the card came from. Collector Crypt cards ship from Jupiter Gacha with Ship home. Cards from a Phygitals pack cannot be shipped from Jupiter Gacha: you redeem them through Phygitals directly, which ships them from its US vault partners. Each provider handles its own shipping support. See Shipping.Which countries can I ship a card to?Collector Crypt ships worldwide, with fees by zone: United States, Canada, Europe, Australia and New Zealand, and the rest of the world. A few destinations are restricted, and an address in one of them is refused when you enter it, with the message “Sorry, we do not ship to [country] at this time”, before any fee is paid. International deliveries can carry customs duties payable on delivery. See Shipping.How long does delivery take?Collector Crypt estimates around 2–3 weeks within the United States and around 5 weeks internationally. For a card redeemed through Phygitals, Phygitals estimates around 2–3 weeks within the United States from PSA Vault and around 1–2 weeks from Fanatics Vault or Alt Vault, plus 1–4 weeks for international deliveries. Vault processing time and the destination both affect the actual delivery date. See Shipping — Delivery times.Why did I only receive some of my cards?Cards held by different vaulting partners ship separately, so one shipment can arrive as several packages with their own tracking numbers and delivery dates. A partial delivery is expected in that case, with either provider. Check the other tracking numbers, and for Collector Crypt cards the Vault details section of each card, before contacting the provider’s support. See Shipping — Cards from different vaults ship separately.Can I expedite a shipment?No. Most of the delivery time is the vault pulling, packing, and releasing the card, and neither provider controls how fast each vault processes a request. There is no faster shipping option.Can I cancel a shipping request that is already processing?Not from Jupiter Gacha: there is no cancel or edit control on a shipment, because redeeming a card burns it and pays the shipping fee in the same transaction, after which the request belongs to Collector Crypt. Contact Collector Crypt support as early as possible (chat widget on collectorcrypt.com or support@collectorcrypt.com) with the order ID from the shipment card. Collector Crypt decides whether the shipment can still be stopped and what happens to the card and the fee; a cancelled request shows as Cancelled in the Shipping tab. See Cancelling or changing a shipment.Can the package be declared as a gift, or at a lower value?No. Packages are declared at the card’s value, the insured value for a Collector Crypt card and Phygitals’ fair market value for a Phygitals card, because the provider insures the shipment in transit for the declared amount. Customs and import duties in the destination country are calculated on that amount. See Shipping — Customs and declared value.My shipment is delayed or has an issue. Who do I contact?The provider that ships the card also handles shipping support: delays, customs, and delivery issues go to them. For a Collector Crypt card, track your shipment first in Collection, Shipping tab, then reach Collector Crypt support through the chat widget at the bottom right of collectorcrypt.com. For a Phygitals card, contact Phygitals through phygitals.com/contact. For anything else related to Jupiter Gacha, contact Jupiter support.Why do I need to sign a message to see my shipments?The Shipping tab loads your outbound Collector Crypt shipments from Collector Crypt. Signing a message proves you control the wallet, so only you can see your shipments. It is a signature, not a transaction: nothing is sent on-chain and no fee is charged.The signature request fails when I verify my wallet for shipping. What can I do?If your wallet shows The app’s signature request cannot be shown due to invalid formatting, you are most likely signing with a Ledger. The Solana app on the device only signs transactions, so it cannot sign the Collector Crypt verification message, whether the Ledger is connected to jup.ag directly or through another wallet app. The Jupiter team is working on it. In the meantime, open a ticket at support.jup.ag with your wallet address, your wallet app, and your Ledger model.With a software wallet such as Phantom, Solflare, or the Jupiter Extension Wallet, check that the wallet is unlocked and that you approved the signature request in the wallet pop-up, then retry from the Shipping tab.How do I delete my shipping address and personal data?Shipping details (name, delivery address, contact information) are collected and processed by the provider operating the shipment, Collector Crypt or Phygitals, not Jupiter: Jupiter never receives or stores them, in its databases or logs. To request access to or deletion of your shipping data, contact Collector Crypt through the chat widget at the bottom right of collectorcrypt.com, or Phygitals through phygitals.com/contact. See Shipping — Your shipping data.Is there a deadline to ship a card home?No. Cards stay vaulted indefinitely at no storage cost. You can redeem a card whenever you choose.","tokens":3759,"squid":"spider-02","role":"Liquidity Spider","at":1791347962080,"hash":"d6719503c2bb83b530915866a426c556b2475021"}
{"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 10\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 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 148\n\n Apr 27\n\n Solidity v0.8.35 is out!\n\n Announcements\n\n 0\n\n 102\n\n Apr 29\n\n Solc-bin binaries hosting migration on 09/12/2025\n\n Announcements\n\n 0\n\n 125\n\n Dec 2025\n\n Solidity v0.8.34 is out! \n\n Announcements\n\n 1\n\n 144\n\n Apr 24\n\n Want to read more? Browse other topics in Announcements or view latest topics.","tokens":1281,"squid":"spider-05","role":"Spec Spider","at":1791347968119,"hash":"f809ece898f557b85ac43952796dd9140d744f5e"}
{"url":"https://docs.jup.ag/user-docs/trade/gacha/gifting","domain":"docs.jup.ag","title":"Gifting Packs and Cards - Jupiter Documentation","text":"There are two ways to give something from Jupiter Gacha to another person: gift them packs to open, or send them a card you already own. Packs are gifted from the Gacha interface. Cards are sent from your wallet, because each card is a token on Solana and Jupiter Gacha has no send action of its own.\n​Gifting packs\nPacks from both providers can be gifted to another wallet: Collector Crypt packs and Phygitals packs alike. See Providers for which is which. Gifting works for a single pack or several at once, and the recipient opens the gift like any pack they purchased. See Providers.\n​Sending a gift\nThe gift icon next to the pack price opens the Gifts dialog. From there:\n1Enter the recipientPaste the recipient’s Solana wallet address in the Recipient wallet field.2Choose boostersPick the packs to send. A single gift can mix several pack tiers, each with its own quantity.3ConfirmConfirm and approve the transaction in your wallet. The gift is paid in USDC at the packs’ current prices.\nThe dialog’s History tab lists the gifts you have sent.\nDouble-check the recipient wallet address before confirming a gift. Gifts sent to a wrong address cannot be recovered.\n​Receiving a gift\nThe recipient sees the gifted pack directly on the corresponding pack page, with an “Open gifted” action in place of the purchase button. Gifted packs are consumed before any USDC is spent when the recipient opens packs, same as free packs.\n​Sending a card to another wallet\nEvery card in your Collection is an NFT (non-fungible token) on Solana, and holding that token is what makes you the owner of the vaulted physical card. To give a card to a friend, send the token from your wallet to theirs, the same way you send any other NFT. Jupiter Gacha has no send button for cards: the transfer is done in your wallet.\n​Before you send\n\nCancel any active listing. A Collector Crypt card listed on the marketplace stays in your wallet while listed, so your wallet lets you send it, but the listing does not follow the card. Collector Crypt tries to cancel a listing when the card moves, but this is not guaranteed, and a stale listing can still be active if the card later comes back to you. Delist first from the card’s Manage listing state.\nUse the instant buyback first if you want it. Sending a card does not restart its instant buyback window, and on a Collector Crypt card the buyback is checked against the wallet that pulled it, so the recipient cannot use it. If you intend to sell a card back, do it before sending it.\n\nCheck the address. A token sent to a wrong address cannot be recovered, same as a gifted pack.\n\n​How to send\n1Find the card in your walletOpen your wallet’s NFT view. In the Jupiter Wallet extension, cards appear under the NFTs tab. To be sure you are sending the right card, compare the token address with the Token ID shown in the Contract info section of the card’s detail page in Jupiter Gacha.2Send itChoose the wallet’s send action for that NFT, paste the recipient’s Solana wallet address, and confirm. The transfer is a regular Solana transaction: it costs a small network fee in SOL, and nothing else.3The recipient connectsOnce the transaction confirms, the card belongs to the recipient. It appears in their Collection when they connect that wallet on jup.ag/gacha. Display can lag a few moments behind the on-chain state; refreshing the page settles it.\nJupiter Mobile currently displays NFTs but cannot send them. Use a wallet that supports sending NFTs, such as the Jupiter Wallet extension. If your wallet does not display the card at all, see the FAQ.\n​What the recipient can do\nThe token carries the full ownership of the vaulted card. The recipient can keep it vaulted at no cost and, for a Collector Crypt card, ship it home or list it on the marketplace at a price they set. A Phygitals card is redeemed through Phygitals, or resold outside Jupiter Gacha on the Phygitals marketplace, Tensor, or Magic Eden. The instant buyback is the exception, as explained above.","tokens":1000,"squid":"spider-02","role":"Liquidity Spider","at":1791347983925,"hash":"95367d8add8b37ec1126078547322f2b6afbd09c"}
{"url":"https://docs.chain.link/datalink/pull-delivery/overview","domain":"docs.chain.link","title":"DataLink (Pull Delivery) | Chainlink Documentation","text":"DataLink (Pull Delivery)DataLink pull-based feeds provide access to specialized data from Data Providers through offchain retrieval with onchain verification capabilities. \nKey Characteristics\nSpecialized market data: Access specialized datasets directly from individual Data Providers\nPull-based delivery: Fetch data on-demand via REST API or real-time via WebSocket\nOnchain verification: Cryptographically verify report integrity using verifier contracts\nProven infrastructure: Built on the same battle-tested Chainlink Data Streams architecture\n\nHow It Works\nData Providers submit specialized data to Chainlink Decentralized Oracle Networks (DONs)\nDONs create cryptographically signed reports and deliver them to the Chainlink Aggregation Layer\nApplications fetch reports offchain via API/WebSocket and verify their integrity onchain\nFor detailed technical information, see the Architecture page.\n\nGetting Started1. Check Network SupportVerify that your target blockchain supports onchain verification by reviewing Supported Networks.2. Choose Your Integration Method\nREST API: Fetch reports on-demand for periodic updates\nWebSocket: Stream real-time data for continuous applications\nOnchain Verification: Add cryptographic validation\n3. Follow the TutorialsStart with our step-by-step Tutorials covering:\nFetching and decoding reports via API (Go/Rust)\nStreaming and decoding reports via WebSocket (Go/Rust)\nOnchain verification for EVM chains\n4. Reference DocumentationConsult the Reference section for:\nComplete API and SDK documentation\nReport schema specifications\n\n What's next > View Architecture > See Supported Networks > Start with Tutorials > Browse Reference","tokens":418,"squid":"spider-08","role":"Oracle Spider","at":1791347993252,"hash":"fa2e8880eb4825db6124b2831d47094ac2d69a86"}
{"url":"https://docs.jup.ag/user-docs/trade/gacha/collection","domain":"docs.jup.ag","title":"Collection - Jupiter Documentation","text":"The Collection page groups everything you own and everything you have done in Jupiter Gacha. It has three tabs: Items, Activity, and Shipping.\n​Items tab\nThe Items tab lists every item you currently own, from Collector Crypt and Phygitals packs alike: cards, and watches on watch pack pulls. Each item shows its image, its grade when it is graded, and its value. You can:\n\nSearch by card name or set\nFilter, including a “Buyback only” filter that shows cards still carrying a live instant buyback offer: Collector Crypt cards within their 3-day window, Phygitals cards with a quoted offer\nSort, for example by value from high to low\n\nThe Collection Highlights section surfaces your most notable items. When a battlepass campaign is live, the Next free pack widget also tracks your progress toward your next free pack (see Rewards); it is hidden between campaigns.\n​Activity tab\nThe Activity tab shows recent pulls with a You / Platform toggle:\n\nYou: your own pack openings, with the rarity, source pack, value, and timestamp of each pull.\nPlatform: recent pulls across all Jupiter Gacha users.\n\nPulls from both providers are listed. Each Collector Crypt opening includes a Verify action that shows the verifiable randomness details for that draw. Phygitals openings have no Verify action: their fairness proof is a commit-reveal scheme documented by Phygitals rather than an on-chain transaction.\n​Shipping tab\nThe Shipping tab tracks Collector Crypt cards you redeem to ship home: status, estimated delivery, and tracking link for each shipment. It also holds the Ship home action. Before shipments can load, you verify your wallet by signing a message with Collector Crypt. The signature is a read-only verification: no transaction is sent and no fee is charged. Phygitals cards cannot be shipped from Jupiter Gacha: they are redeemed through Phygitals directly. See Shipping for both flows.\n​The card detail page\nEvery card has a detail page. A Collector Crypt card shows the four sections below. A Phygitals card shows Grading (when the card is graded), Metadata, and Contract info; it has no Vault details section, and its Est. value is Phygitals’ fair market value estimate rather than a Collector Crypt insured value. See Providers.\n​Grading\nFieldMeaningGrading companyThe company that graded the physical card, for example PSA or CGCGrading IDThe certificate number issued by the grading company, verifiable on the grader’s own websiteGradeThe condition grade of the card, for example MINT 9 or GEM-MT 10AuthenticatedConfirmation that the slab has been authenticatedEst. valueThe card’s reference value, labelled Est. value on the card page and explained below\n​Metadata\nSet, card name, description, Gemrate grade and ID, parallel, set URL, and spec ID. Gemrate is an independent aggregator of grading data.\n​Contract info\nThe token ID representing the card, and the blockchain it lives on (Solana). This is the on-chain representation of your ownership. It is also what you transfer if you send the card to another wallet.\n​Vault details\nThe vault holding the physical slab, its vault ID, and its location where available. Cards are stored with different professional vaulting partners depending on the card, for example PSA Vault or OmniVault. The Vault details section tells you exactly where a specific card is held.\n​Insured value\nThe card detail page labels a card’s value Est. value. Elsewhere in the app, for example on the reveal and in the marketplace filters, the same figure is called the insured value.\nOn a Collector Crypt card, the insured value is a reference value assigned by Collector Crypt at its discretion. It serves one purpose: it is the basis on which the instant buyback amount is calculated.\nOn a Phygitals card, the figure is Phygitals’ fair market value estimate for the card, which is the basis of the buyback offer Phygitals quotes on the card. Phygitals states that cards in its vault custody are insured through its vault partners against loss, theft, and damage; that cover is separate from the value displayed.\nDespite the name, the insured value of a Collector Crypt card is not an insurance policy. It does not provide coverage for loss, theft, or damage. It is also not a market price: marketplace sellers set their asking prices freely, and a card’s market price can be above or below its insured value.","tokens":1088,"squid":"spider-02","role":"Liquidity Spider","at":1791347996889,"hash":"b34ed0c938ee4971603e6b9f3325dd800d10d1e4"}
{"url":"https://ethresear.ch/t/mev-burn-a-simple-design/15590","domain":"ethresear.ch","title":"MEV burn—a simple design - Economics - Ethereum Research","text":"MEV burn—a simple design \n\n Economics\n\n mev\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n May 2023\n\n 1 / 28\n\n May 2023\n\n Jun 2024\n\n post by JustinDrake on May 15, 2023\n\n JustinDrake\n\n TLDR: We describe a simple enshrined PBS add-on to smooth and redistribute MEV spikes. Spike smoothing yields security benefits. Redistribution yields economic benefits like EIP-1559.\nSpecial thanks to @dankrad, @domothy, @fradamt, @joncharbonneau, @mikeneuder, @vbuterin for feedback.\npart 1: enshrined PBS recap\nWe recap enshrined PBS before describing the MEV burn add-on.\n\nbuilder balances: Builders have an onchain ETH balance.\nbuilder addresses: Builder balances are held in EOA addresses.\nbuilder bids: Builders gossip bids which contain:\n\npayload commitment: a commitment to an execution payload\npayload tip: an amount no larger than the builder balance\nbuilder pubkey: the ECDSA pubkey for the builder address\nbuilder signature: the signature of the builder bid\n\nwinning bid: The proposer has a time window to select a bid to include in their proposal.\npayload reveal: The winning builder has a subsequent time window to reveal the payload.\nattester enforcement: Attesters enforce timeliness:\n\nbid selection: an honest proposer must propose a timely winning bid\npayload reveal: an honest winning builder must reveal a timely payload\n\npayload tip payment: The payload tip amount is transferred to the proposer, even if the payload is invalid or revealed late.\npayload tip maximisation: Honest proposers select tip-maximising winning bids.\n\n2722×1314 199 KB\npart 2: MEV burn add-on\nMEV burn is a simple add-on to enshrined PBS.\n\npayload base fee: Bids specify a payload base fee no larger than the builder balance minus the payload tip.\npayload base fee burn: The payload base fee is burned, even if the payload is invalid or revealed late.\npayload base fee floor: During the bid selection attesters impose a subjective floor on the payload base fee.\n\nsubjective floor: Honest attesters set their payload base fee floor to the top builder base fee observed D seconds (e.g. D = 2) prior to the time honest proposers propose.\nsynchrony assumption: D is a protocol parameter greater than the bid gossip delay.\n\npayload base fee maximisation: Honest proposers select winning bids that maximise the payload base fee.\n\n2718×1318 237 KB\nbuilder race to infinity\nePBS without MEV burn incentivises builders to compete for the largest builder balance. Indeed, for exceptionally large MEV spikes the most capitalised builder has the power to capture all MEV above the second-largest builder balance. This design flaw can be patched with a L1 zkEVM that provides post-execution proofs.\nAlternatively, MEV burn can solve the issue by relaxing the requirements on the pre-execution builder balance to cover a maximum upfront payload base fee of M ETH (e.g. M = 32) plus the payload tip. The payload is deemed invalid (with transactions reverted) if the post-execution builder balance is not large enough to cover the payload base fee.\nWith this change a malicious builder can force an empty slot for M ETH. The ability to force empty slots cannot be weaponised to steal MEV spikes above M ETH as empty slots merely delay the eventual burn of MEV spikes.\npart 3: technical remarks\n\nprior art: The design is inspired by Francesco’s MEV smoothing. See also Domothy’s MEV burn, a significantly different design.\nunbounded burn: Besides providing a fair playing field and reducing builder capital requirements, the fix to the builder race to infinity (see above) allows for an unbounded MEV burn, beyond the largest builder balance.\nhonest proposer liveness: Honest proposers enjoy provable liveness under the synchrony assumption that bids reach validators within D seconds.\n\nproof: Under synchrony, whatever top payload base fee was observed by an honest attester D seconds prior to an honest proposer selecting their top bid (i.e. the attester’s payload base fee floor) will have also been observed by the proposer.\n\nefficient gossip: Bid gossip is particularly efficient because:\n\nbuilder balances provide p2p Sybil resistance (a minimum builder balance, e.g. 1 ETH, is recommended)\nbids fit within a single Ethernet packet (1,500-byte MTU)\ngossip nodes can drop all but their current top bid\n\noptimisation game: Rational proposers will want to maximise the payload tip by guessing the payload base fee floor and accepting bids with non-zero tips after the payload base fee floor has been established. This creates a second optimisation game for rational proposers, in addition to the existing optimisation game with proposal timeliness.\nsplitting attack: Dishonest proposers can use the payload base fee to split attesters into two groups: attesters that believe the payload base fee floor is satisfied, and attesters that do not. Dishonest proposers can already split attesters on the timeliness of their payload reveals.\nlate bidding: Builders can try to deactivate MEV burn by not bidding until after the D seconds tipping window has started, causing attesters to set their payload base fee floor to 0. We argue this is irrational for builders by considering two cases in the prisoner’s dilemma:\n\ncolluding builders: If all the builders capable of extracting a given piece of MEV are colluding then the optimal strategy is to not bid at all for that piece of MEV, even within the D seconds tipping window. Instead, the cabal of builders is better off coordinating to distribute the MEV among themselves, a strategy possible with or without MEV burn.\nnon-colluding builders: If one of the builders capable of extracting a given piece of MEV defects by bidding there is no benefit for any of the builders to bid late. If anything, late-bidding builders risk not having bids reach the proposer on time.\n\ninclusion lists: Inclusion lists allow proposers to specify a set of transactions they want included in the winning payload. This is sufficient for proposers to fight censorship and provide soft pre-confirmations, by including censored and pre-confirmed transactions in the inclusion list.\n\ntechnical similarities with EIP-1559\n\nhonest majority: Both depend on an attester honest majority. (As argued in the “side note for validators” section, validators are not incentivised to defect.)\n\nEIP-1559: A dishonest majority can control the fork choice rule to only include lower-than-target blocks till the base fee is zero, deactivating EIP-1559 and devolving to a first-price auction.\nMEV burn: A dishonest majority can set the payload base fee floor to zero, deactivating the smoothing and redistribution of MEV spikes.\n\npartial burn: Both are partial burns.\n\nEIP-1559: Base fees partially capture congestion fees when blocks are full. (Ethereum blocks have limited elasticity with a gas limit set to 2x the gas target.)\nMEV burn: The payload base fee floor is merely an MEV lower bound, and rational proposers may collect some MEV above the payload base fee floor.\n\nonchain oracle: Both provide an onchain oracle.\n\nEIP-1559: Base fees yield an onchain congestion oracle.\nMEV burn: payload base fees yield an onchain MEV oracle. (Payload base fees are augmented with the builder address metadata.)\n\npart 4: security benefits from smoothing\n\nmicro consensus stability: Spike smoothing significantly reduces the incentives for individual proposers to steal MEV via short chain reorgs, proposer equivocations, and p2p attacks (e.g. DoSes, eclipses, and saturations).\nmacro consensus stability: An extreme MEV spike can create systemic risk for Ethereum, possibly bubbling to the social layer. Consider a malicious proposer receiving millions of ETH from a rollup hack.\nlower reward variance: MEV spikes cause the average MEV reward to be significantly higher than the median MEV reward. Smoothing significantly reduces proposer reward variance, reducing the need for pool-based MEV smoothing.\nrugpool protection: Pools with collateralised external operators (e.g. Rocket Pool and Lido) are liable to a “rugpool” (portmanteau of “rugpull” and “staking pool”). That is, whenever the operator’s collateral (financial or reputational) is worth less than the MEV spike at a given slot, the operator is incentivised to collect the spike instead of having the smoothing pool receive it.\ncensorship resistance: The payload base fee floor is a forcing function for proposers to consider bids from all builders. Proposers that only consider bids from censoring builders (e.g. proposers that today only connect to censoring relays) will not satisfy the payload base fee floor for some of their proposals.\ntoxic MEV whitewashing: Stakers and staking pools suffer a dilemma when receiving toxic MEV spikes: should toxic MEV (e.g. proceeds from sandwiching, user error, smart contract bugs) be returned to affected users? This dilemma disappears when toxic MEV is burned, resolving several issues:\n\nincentive misalignment: Rational stakers are incentivised to keep toxic MEV, incentivising “bad” behaviour.\nethical, reputational, legal, tax liabilities: Stakers have to weigh the pros and cons of a complex tradeoff space. Beyond the ethical and reputational conundrum, the legal and accounting situation may be a grey zone.\ndisputes: Staking pools may suffer disputes on how to deal with toxic MEV. Pools with governance (e.g. RocketPool and Lido) may disagree on how to deal with MEV, and centralised pools may suffer backlash from their users if the “wrong” decision was made.\n\npart 5: economic benefits from redistribution\nEIP-1559 and MEV burn yield the same economic benefits.\n\nreduced validator count: EIP-1559 and MEV burn reduce aggregate ETH staking rewards, itself reducing the amount of ETH staked. This has several benefits:\n\nlower issuance: Aggregate issuance shrinks with reduced ETH staking. Since the beacon chain is designed to be secure with issuance only, EIP-1559 and MEV burn reduce overpayment for economic security and improve economic efficiency.\nmore economic bandwidth: Reducing the amount of staked ETH increases the amount of ETH available as pristine economic bandwidth (e.g. as collateral for decentralised stablecoins). EIP-1559 and MEV burn prevent staking from unnecessarily starving applications that consume pristine economic bandwidth.\nlower validator count: Reducing the validator count reduces pressure on beacon nodes and makes single slot finality (SSF) easier to deploy. EIP-1559 and MEV burn reduce the urgency of active validator capping.\n\nstaking APR: The primary cost of ETH staking is the opportunity cost of money so staking rewards in an efficient market should approximate the broader cost of money. As such, neither EIP-1559 nor MEV burn should significantly affect long-term staking APRs.\n\nside note for validators: EIP-1559 and MEV burn should increase per-validator USD-denominated rewards. The reason is that ETH-denominated rewards are dictated by the cost of money but the USD price of ETH is positively impacted by EIP-1559 and MEV burn. EIP-1559 and MEV burn increase returns for decentralised staking pools (see “rugpooling”), and raise median returns especially for solo stakers.\n\neconomic sustainability: EIP-1559 and MEV burn are independent revenue steams for ETH holders, both contributing to economic sustainability. This diversity hedges against one of the revenue streams drying up:\n\nEIP-1559 dry up risk: Exponential growth of computational resources may lead to blockspace supply outstripping demand and crushing congestion fees. (The bull case for EIP-1559 is induced demand.)\nMEV burn dry up risk: Most MEV may be captured by rollups and validiums at L2. (The bull case for MEV burn is based rollups and enshrined rollups.)\n\ntax efficiency: EIP-1559 and MEV burn can significantly improve staking tax efficiency in some jurisdictions by converting income (taxed at, say, 50%) into capital gains (taxed at, say, 20%). EIP-1559 has already prevented ~1M ETH of tax sell pressure, and MEV burn would similarly prevent millions of ETH of sell pressure.\neconomic scarcity: EIP-1559 and MEV burn increase ETH scarcity. Not counting the reduced issuance (see “lower issuance” above), the ETH supply since the merge would have decreased ~2.5x faster with MEV burn. (The supply would have reduced by ~270K ETH instead of just ~110K ETH.)\nenshrined unit of account: EIP-1559 and MEV burn enshrine ETH as unit of account for congestion and MEV respectively.\nmemetics: EIP-1559 and MEV burn have memetic potential and strengthen ETH as a Schelling point for collateral money on the internet. The success of Ethereum as a settlement layer for the internet of value is tied with the success of ETH.\n\npart 6: mental model\nBlockspace fundamentally provides both transaction inclusion and transaction ordering services. Competition for inclusion leads to congestion, and competition for ordering leads to contention. Congestion and contention are externalities that can be natively priced with EIP-1559 and MEV burn, and each mechanism yields an independent revenue stream.\n\ntransaction inclusion\ntransaction ordering\n\nexternality\ncongestion\ncontention\n\npricing mechanism\nEIP-1559\nMEV burn\n\nrevenue stream\ntransaction base fees\npayload base fees\n\nEIP-1559 and MEV burn—two sides of the same coin\n\n Why enshrine Proposer-Builder Separation? A viable path to ePBS\n\n MEV burn: Incentivizing earlier bidding in \"a simple design\"\n\n In a post MEV-Burn world - Some simulations and stats\n\n Dr. changestuff or: how i learned to stop worrying and love mev-burn\n\n Relays in a post-ePBS world\n\n 8\n\n 3\n\n 2\n\n 2\n\n 2\n\n read \n\n 17\n min\n\n post by CometShock on May 15, 2023\n\n CometShock\n\n Thank you Justin for the great write-up! I’ve got a few questions to hopefully help my understanding of the proposal. Please feel free to correct me if I’m missing something critical with these questions, it happens often enough. \nWhat incentives and/or design constraints discourage an upcoming proposer from publicly broadcasting that they are open to receiving private bids during their slot, where all bidders can privately collude with the proposer to minimize the base fee floor in favor of maximizing their returns?\nIn this case, any bidder that believes they have a chance of being selected for a slot is incentivized to privately collude and not make an honest public bid. They can submit timely private bids to the proposer and still trust that the proposer will select the bid which that minimizes base fee floor and maximizes the payload tip.\nYes, a party who is an honest minority bidder and doesn’t believe they are likely to be selected (call them the “unconfident honest bidder”) could still make a public bid — thus smoothing at least some of the spiked profits that private collusion would have captured. However, this assumes that the unconfident honest bidder has block building/MEV skills that are at all comparable to the confident private bidders. If a lucrative MEV opportunity requires high skill to identify and execute, it’s much less likely to be caught by the unconfident honest bidder and remain un-smoothed.\nAdditionally, the incentives of running, maintaining, and improving an unconfident honest bidder primarily for the purposes of smoothing (rather than successful selection of their block) are very low, as the reward is socialized redistribution through burn. This is far less than the incentives of running, maintaining, and improving a confident private bidder, who is capable of capturing a large portion of the extractable returns for themselves.\nDuring non-MEV-spike events, what incentives and/or design constraints enforce attesters to set an honest payload base fee floor?\n(Is this question too far out-of-scope from the desirable outcomes of the proposal? If redistribution is just the “means” to the “end” where smoothing is accomplished, then this question doesn’t seem too important.)\nI’m left wondering how the incentives for honest payload base fee floor could change based upon the % of ETH staked in the network. Intuitively, ETH stakers are a smaller subset of all ETH holders. Therefore stakers are jointly interested in resisting the redistribution of their base MEV returns to the larger set of all ETH holders.\nTo illustrate with an example, consider an extreme case where the network has 10% of ETH staked. If payload base fees are relatively efficient and close to total extractable MEV on a “typical” block, then the staker subset is missing out on ~90% of their capturable returns that are getting redistributed to the ETH holders. In this case, each attester (being a part of the staker subset) is highly incentivized to establish a culture of low payload base fee floors on each slot. This way when it becomes their turn to propose, they can capture a much larger MEV return for themselves as well (vs what would’ve been redistributed to them during attestations). The culture change seems plausible given that this is an infinite game. Unless there is some punishment for doing so, attesters could continuously signal they are willing to attest to very low payload base fee floors (on typical blocks) and slowly erode away the higher standard. This does not apply to MEV spikes, as if they’re sufficiently large enough the incentives for attesters could still be to redistribute.\nClearly the above example is extreme and not representative of the magnitude of incentives as if this proposal were to be implemented tomorrow. However, I do wonder if this is a desirable or acceptable outcome and if it should be explored further.\n\n post by JustinDrake on May 15, 2023\n\n JustinDrake\n\nWe’re not trying to discourage proposers from receiving private bids! In the analysis of MEV burn I would assume that all proposers are willing to receive private bids \n\nIf all bidders capable of extracting a specific piece of MEV collude then it’s game over, with or without collusion with the proposer, as well as with or without MEV burn. As argued in the “colluding builders” section under “late bidding”, a cabal of colluding builders can keep all the MEV for themselves (e.g. equally split the MEV among themselves instead of racing towards zero margins). The good news is that 100% collusion within a permissionless set of competing builders is hard—the equilibrium is a race to zero where individual builders defect.\n\nThe design is secure under an honest majority of attesters, similar to EIP-1559. (See the section titled “honest majority” under “technical similarities with EIP-1559”.)\n\nI disagree with this premise—IMO it’s likely net positive for validators to embrace the redistribution of MEV. See the section titled “side note for validators” under “staking APR”. The crux of the argument is that ETH-denominated returns are tied to the cost of money, and USD-denominated returns (as well as the USD-denominated principal) should actually grow.\n\n post by CometShock on May 15, 2023\n\n CometShock\n\nApologies, I should have made my statement clearer. The emphasis is not that builders collude with each other builder, but rather each individual builder is incentivized to collude with the proposer by running private bids. It’s game theoretically optimal for each individual builder to do so, as you maintain timeliness while obscuring your payload base fee floor to the outside attesters (this reduces the potential payload base fee floor). Additionally, as more individual builders elect to privately bid, they all share the same benefit of an even lower payload base fee floor. (Edit, previously: Additionally, once each individual builder elects to…)\nIf the payload base fee floor is lowered due to obscuring the skilled bids, naturally the builder can bid marginally more (ex: half of recovered base fee) payload tip to the proposer - making it game theoretically optimal for the proposer to accept private bids. From the outside, this looks like all builders are colluding amongst each other as well as with the proposer — but in reality it’s just optimal for all builder-proposer relationships to do this on an individual basis and it scales in effectiveness as more builders participate. And the end result is heavily suppressed payload base fee floors. The only party who would intentionally defect from this structure would be an unconfident builder who wants to redistribute as much as they can (but as mentioned before, if they’re unconfident, they’re likely not skilled enough to capture much of the MEV spike anyways. So still suppressed payload base fee floor).\nAll this to say that it if private bidding is possible, it seems this proposal is effective at burning easy, low-skill MEV, but is ineffective at burning anything outside of that set.\n\n Burn incentives in MEV pricing auctions\n\n Sealed execution auction\n\n MEV resistant dynamic pricing auction of execution proposal rights\n\n Fork-Choice enforced Inclusion Lists (FOCIL): A simple committee-based inclusion list proposal\n\n Practical endgame on issuance policy\n\n post by terence on May 15, 2023\n\n terence\n\nWouldn’t D be the same time proposer receive those bids as well? If yes, then I think it can be close to the end of the slot as possible.\nCorrect me If I am wrong, there will be a new gossip network called builder_bids and the builder will broadcast the bids there. Attesters and proposers will all be listening there.\nSome followup questions\n\nHow are the attesters chosen for duty? size? new reward/penalty?\nIs this an extension of the forkchoice rule where the second highest bid can’t be head? or an extension of block validity condition where the second highest bid block can’t be valid?\n\n post by JustinDrake on May 15, 2023\n\n JustinDrake\n\nBuilders do not directly benefit from a low payload base fee floor Naively (i.e. assuming no kickback from the proposer) builder profit margins are invariant to the payload base fee.\n\nThe builder does not “recover” anything from a lower payload base fee. They don’t get the payload base fee, with or without MEV burn.\n\nI call this “commoditised MEV”.\n\nNotice that a public-good builder (e.g. a hypothetical “ultra sound builder” ) that wants to set a baseline payload base fee floor wouldn’t necessarily need to be good at capturing MEV spikes. They only need to be good at predicting what the payload base fee floor could be, and then bidding just under that value.\n\nThe proposer is guaranteed to receive by the start of the slot all the bids broadcast D seconds before the start of the slot.\n\nExactly! There will be a “bid pool” which is a new p2p gossip channel for bids. Builders broadcast signed bids, and validators listen.\n\nI would simply reuse the attester committee for the given slot. With SSF the attester committee could be the whole validator set. The same attestation rewards and penalties can also be reused, without modification.\n\nYes, the payload base fee floor attestation rule is a modification to the fork choice rule (not a change to the state transition function).\n\n post by terence on May 15, 2023\n\n terence\n\n What happens if multiple bids have the same value? either from same builder or different builders\n\n post by CometShock on May 15, 2023\n\n CometShock\n\nMy assumption is that kickbacks from proposer to selected builder are inevitable. The proposer wants all the builders to privately submit so that some of what would’ve been the payload base fee floor is instead captured as proposer revenue. It’s very natural that proposers would provide kickbacks to selected builders to incentivize this structure.\n\nEstablishing a word for following response.\nBase Fee Overbid: payload_base_fee - builders_extracted_value_from_block when payload_base_fee > builders_extracted_value_from_block \nMy point is that an “ultrasound builder” who wants to set a baseline payload base fee floor through overbidding would be risking a lot of their balance should they instead be selected. In fact, they could be selected in either two scenarios:\n\nThey predicted wrong and are the most valuable bid, now they lose their base fee overbid to a burn\nA proposer attempting to create a private bid structure selects the public ultrasound builder to call their bluff, now the ultrasound builder lost their base fee overbid to a burn. Rational move in an infinite game with enough relevant information.\n\nMy intuition is that the base fee overbidding phenomenon wouldn’t last very long given a few aggressive private-favoring proposers. If the ultrasound builders wanted to remain resilient in the long term, they’d have to become relatively good at capturing MEV spikes. But again, the financial incentive for them to improve their operation is just incomparable to a selfish builder, so the scales are tipped in the selfish favor.\n\n The price is right: Realigning proposer-builder incentives with predictive MEV-burn\n\n MEV burn: Incentivizing earlier bidding in \"a simple design\"\n\n post by JustinDrake on May 16, 2023\n\n JustinDrake\n\nOk perfect, let’s try to analyse that scenario \n\nsetup: There are precisely k builders (e.g. k = 2) that are capable of extracting a piece of non-commoditised MEV (e.g. 0.69 ETH from an exotic CEX-DEX arbitrage). The proposer has setup a coordination device (e.g. some fancy SGX, MPC, smart contract—you name it) to partially kickback some of the non-burned MEV to the builders.\nclaim: The builders are better off bypassing the proposer altogether, with or without MEV burn.\nintuition: Indeed, one of the k builders can replicate the coordination device to fully kickback all of the non-burned MEV to the builders. For example, this coordination device could be an SGX enclave to which builders privately submit bids, and which only publicly outputs one bid which maximises value for the builders.\n\nIf you still believe the proposer can provide special coordination services with kickbacks for the builders, it would be helpful to describe such coordination services in more detail.\n\n post by ballsyalchemist on May 16, 2023\n\n ballsyalchemist\n\n CometShock\n\nThe proposer and builder will indirectly benefit from colluding privately to lower the base fee floor (base fee takes away the MEV that could have benefitted proposer & MAYBE builder with kickback). Even with a public-good builder who attempts to set the base fee, which imo wouldn’t be as reliable as an assumption, builders with more orderflow (possibly private orderflow) can circumvent the base fee. Furthermore, this could incentivize the creation of a private bidding marketplace on the side for builders attempting to bribe proposers. In that case, as @CometShock suggested, floor can still be suppressed while proposers continue to capture the lion’s share of MEV as usual.\n\n post by CalabashSquash on May 21, 2023\n\n CalabashSquash\n\nIs somebody able to explain this a bit more? Mostly: How would they distribute the MEV among themselves without bidding at all?\nThank you.\n\n post by Pintail on May 25, 2023\n\n Pintail\n\n Is this proposal compatible with a proposer suffix scheme whereby censorship resistance is enhanced by permitting the proposer to include transactions after the builder releases the payload? In your view would this be desirable?\nGiven then number of steps involved in the builder auction, do you think this proposal would require an increase in block interval?\n\n post by JustinDrake on May 25, 2023\n\n JustinDrake\n\nColluding builders would need some sort of coordination technology—could be legal, smart contract, SGX, blind trust, etc. The way builders collude is an implementation detail.\n\nYes, this proposal is compatible with inclusion lists (see also section titled “inclusion lists” under “part 3: technical remarks”). My favourite design is called forward inclusion lists:\n\nlist means it’s an unordered list of transactions\nforward inclusion means the next builder must include the transactions (up to the gas limit)\n\nAn important detail with inclusion lists is whether the list is ordered or unordered. The word “suffix” suggests that the list is ordered and must be included as-is in the block. The problem with ordered lists is that they allow the proposer to extract MEV, which incentivises the proposer to be a builder and defeats the purpose of PBS. My favourite inclusion list design so far allows for both reordering and insertions by the builder (but no deletions!).\n\nInclusion lists for censorship resistance is important to derisk the potential outcome where top block builders are censoring. (Thankfully the top two builders—builder0x69 and beaverbuilder—are not currently censoring.) Inclusion lists are even more important with MEV burn because of the reduced discretionary power of proposers to choose the winning bid.\n\nMEV burn does not require any increase in the slot duration beyond what is required for ePBS. Having said that, ePBS itself will almost certainly require an increase in the slot duration. This is because, as you note, there are two rounds of attestations instead of just one.\nIn practice ePBS likely requires single slot finality (SSF) which would add yet another round of attestations (for a total of three rounds of attestations per slot). My best guess is that the slot duration will have to increase for SSF and ePBS, possibly to something like 32 seconds.\nAs a side note, the effectiveness of MEV burn increases with larger slot durations (see section “partial burn” under “technical similarities with EIP-1559”). The reason is that the ratio of the parameter D to the slot duration reduces. So if D = 2 seconds and the slot duration is 32 seconds, roughly 93.75% of the MEV would be burned.\n\n post by voidp on May 25, 2023\n\n voidp\n\n Very interesting idea!\n\nI think I’m missing something basic: why do they need to guess since bids (including base fee) & tips are broadcast publicly?\n\nIf by bypassing the proposer you mean the builders can wait to be elected as a proposer by themselves, that may be risky if the MEV opportunity is time sensitive.\n\n post by JustinDrake on May 26, 2023\n\n JustinDrake\n\nBecause rational proposers need to guess the minimal base fee that attesters will accept. Every attester, depending on their connectivity to the bid pool and their clock skew, may enforce a different payload base fee floor.\n\nI mean the builders can collude among themselves so that the MEV does not go to proposer.\n\n post by wanify on May 27, 2023\n\n wanify\n\n Thanks for the great write-up!\nWill attesters only accept the highest payload base fee they watched as the payload base fee floor? Or do they have some flexibility? (For instance, could they consider accepting a fee that is 90% of the highest observed fee, or perhaps even the second highest base fee.)\n\n post by bertmiller on Jun 3, 2023\n\n bertmiller\n\n Thanks for a very interesting design @JustinDrake \nRight now MEV-Boost and MEV burn have a first price account with public bids. I’d like to see more analysis of the trade-offs of other auction designs - for example making the auction sealed bid could be desirable because it prevents strategic bidding (builders watching the p2p layer for bids and incrementally bidding higher) and incentivizes builders to bid their true bid value instead. Moreover, we should explore the second-price auctions as well as an alternative to first price. The tradeoff, of course, is that these introduce more implementation complexity.\n\n State Lock Auctions: Towards Collaborative Block Building\n\n post by JustinDrake on Jun 3, 2023\n\n JustinDrake\n\nMEV burn is largely orthogonal to the auction design. With cryptography (e.g. FHE) one can do sealed bids as well as second-price auctions.\nFor sealed bidding, bidders encrypt their bids. Whenever nodes in the p2p network or attesters receive two encrypted bids, they locally apply (using FHE) the comparison function which returns an encryption of the largest of the two bids. This allows attesters to produce an encryption of their subjective base fee floor, which can then be force-decrypted (e.g. using threshold decryption or time-based decryption).\nSecond-price auctions only make sense with sealed bids, and those are also possible with FHE. This time, the comparison function takes three encrypted bids and returns an encryption of the largest two bids.\n\n post by bertmiller on Jun 4, 2023\n\n bertmiller\n\n All of that makes sense to me From my perspective the discourse around PBS has mostly assuming first price, public auctions (as exist at the moment) and my intention was to highlight that this is an assumption and one that we should explore alternatives to.\n\n 2 months later\n\n post by PatrickAlphaC on Jul 27, 2023\n\n PatrickAlphaC\n\n Loved reading this, big question though - sorry if it sounds brash, but would this essentially remove MEV-boost, flashbots, and the likes from the ecosystem?\nIt seems they would have no place if this was at the protocol level.\n\n Load more posts below","tokens":8174,"squid":"spider-04","role":"Research Spider","at":1791348003081,"hash":"9bb48ecb7185465c862a0b0e04be5953d7866ee1"}
{"url":"https://docs.phantom.com/ethereum-monad-testnet-base-and-polygon/getting-started","domain":"docs.phantom.com","title":"Get started with EVM networks - Phantom developer documentation","text":"The Phantom browser extension and mobile in-app browser are both designed to interact with web applications. EVM web apps can interact with Phantom via the provider that is injected at window.phantom.ethereum. This provider conforms to the EIP-1193 standard and is also injected at window.ethereum to support legacy integrations. Phantom also supports EIP-6963 for ease of integration.\n​EVM networks covered in this guide\nThis guide covers the following EVM networks. Use the same EIP-1193 provider methods across them.\nChainMainnetTestnetEthereumEthereum (1 / 0x1)Sepolia (11155111 / 0xaa36a7)BaseBase (8453 / 0x2105)Base Sepolia (84532 / 0x14a34)PolygonPolygon (137 / 0x89)Polygon Amoy (80002 / 0x13882)Robinhood ChainRobinhood Chain (4663 / 0x1237)Robinhood Chain Testnet (46630 / 0xb626)ArcArc (5042 / 0x13b2)Arc Testnet (5042002 / 0x4cef52)\nTo use a testnet, first enable Testnet Mode. For RPC URLs and block explorers, see the official network configuration for Robinhood Chain and Arc.\nMonad support has been deprecated.\nThis documentation is dedicated to covering all aspects of the provider.Was this page helpful?","tokens":281,"squid":"spider-10","role":"Tooling Spider","at":1791348009574,"hash":"75e2140f408a358221281aae1d7ec3a4e8aa3ceb"}
{"url":"https://docs.phantom.com/ethereum-monad-testnet-base-and-polygon/signing-a-message","domain":"docs.phantom.com","title":"Sign a message - Phantom developer documentation","text":"When a web application is connected to Phantom, it can also request that the user signs a given message. Applications are free to write their own messages which will be displayed to users from within Phantom’s signature prompt. Message signatures do not involve network fees and are a convenient way for apps to verify ownership of an address. To learn how you can use libraries such as ethers.js to abstract away some of these intricacies, see handleSignMessage in our sandbox.\nconst message = 'To avoid digital dognappers, sign below to authenticate with CryptoCorgis.';\nconst from = accounts[0];\nconst msg = `0x${Buffer.from(message, 'utf8').toString('hex')}`;\nconst sign = await provider.request({\n method: 'personal_sign',\n params: [msg, from, 'Example password'],\n });\n\n​Support for “Sign-In with” standards\nApplications that rely on signing messages to authenticate users can choose to opt-in to one of the various “Sign-In with” (SIW) standards. For more details, see Sign-In with (SIW) standards.Was this page helpful?","tokens":257,"squid":"spider-10","role":"Tooling Spider","at":1791348031764,"hash":"c22dd73b6acae1f4b605f9e6b14055aa57e5cf48"}
{"url":"https://docs.phantom.com/ethereum-monad-testnet-base-and-polygon/sending-a-transaction","domain":"docs.phantom.com","title":"Send a transaction - Phantom developer documentation","text":"Once a web application is connected to Phantom, it can prompt the user for permission to send transactions on their behalf.\nTo send a transaction, you will need to have a valid transaction object. It should 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\nHowever, this transaction object needs to be signed using the sender’s private key. This ensures that only the person that holds the private key can send transactions from the public address.\nTo prompt Phantom to send a transaction to the network, refer to the following code snippet:\nconst result = await provider.request({\n method: 'eth_sendTransaction',\n params: [ \n {\n from: accounts[0],\n to: '0x0c54FcCd2e384b4BB6f2E405Bf5Cbc15a017AaFb',\n value: '0x0',\n gasLimit: '0x5028',\n gasPrice: '0x2540be400',\n type: '0x0',\n },\n ],\n});\n\nThese are the building blocks of what you will need to send a transaction. However, if you were to copy/paste this, it would likely fail. There are several pieces of a transaction that are best provided in a dynamic manner. For details, refer to the sendTransaction function in our sandbox.Was this page helpful?","tokens":323,"squid":"spider-10","role":"Tooling Spider","at":1791348041657,"hash":"59ce5556b72c998020493126d6bfaeca5213101f"}
{"url":"https://docs.chain.link/datalink/pull-delivery/tutorials/fetch-decode/api-go","domain":"docs.chain.link","title":"Fetch and Decode reports using the Go SDK | Chainlink Documentation","text":"Fetch and Decode reports using the Go SDK Guide Versions This guide is available in multiple versions. Choose the one that matches your needs. Fetch and decode reports using the Go SDK Fetch and decode reports using the Rust SDK In this guide, you'll learn how to use the Data Streams SDK for Go to fetch and decode DataLink feeds from the Aggregation Network. You'll set up your Go project, retrieve a report, decode it, and log its attributes. \n\nRequirements\nGit: Make sure you have Git installed. You can check your current version by running git --version in your terminal and download the latest version from the official Git website if necessary.\nGo Version: Make sure you have Go version 1.22.4 or higher. You can check your current version by running go version in your terminal and download the latest version from the official Go website if necessary.\nAPI Credentials: Access to DataLink requires API credentials to connect to the Aggregation Network. If you haven't already, contact us to request access.\n\nGuideYou'll start with the set up of your Go project. Next, you'll fetch and decode a report and log its attributes to your terminal.Set up your Go project\n\nCreate a new directory for your project and navigate to it:\nmkdir my-datalink-project\ncd my-datalink-project\n\nInitialize a new Go module:\ngo mod init my-datalink-project\n\nInstall the Data Streams SDK:\ngo get github.com/smartcontractkit/data-streams-sdk/go\n\nUnderstanding Report Schema VersionsData Providers may use different report schema versions. The schema version determines the structure of the data returned by the feed and affects how you should decode the report.\nImport the appropriate schema version in your code (e.g., v4).\nUse that version when decoding the report with report.Decode[v4.Data]().\nDifferent schema versions have different fields and structures.In this example, we're using report schema v4 for the EUR/USD feed, but your implementation should match the schema version specified by your Data Provider.Fetch and decode a report with a single feed\n\nCreate a new Go file, single-feed.go, in your project directory:\ntouch single-feed.go\n\nInsert the following code example and save your single-feed.go file:\npackage main\n\nimport (\n \"context\"\n \"fmt\"\n \"os\"\n \"time\"\n\n streams \"github.com/smartcontractkit/data-streams-sdk/go\"\n feed \"github.com/smartcontractkit/data-streams-sdk/go/feed\"\n report \"github.com/smartcontractkit/data-streams-sdk/go/report\"\n v4 \"github.com/smartcontractkit/data-streams-sdk/go/report/v4\"\n // Import the v4 report schema\n)\n\nfunc main() {\n // Validate command-line arguments\n if len(os.Args) < 2 {\n fmt.Printf(\"Usage: go run main.go [FeedID]\\nExample: go run main.go 0x0004b9905d8337c34e00f8dbe31619428bac5c3937e73e6af75c71780f1770ce\\n\")\n os.Exit(1)\n }\n feedIDInput := os.Args[1]\n\n // Get API credentials from environment variables\n apiKey := os.Getenv(\"API_KEY\")\n apiSecret := os.Getenv(\"API_SECRET\")\n if apiKey == \"\" || apiSecret == \"\" {\n fmt.Printf(\"API_KEY and API_SECRET environment variables must be set\\n\")\n os.Exit(1)\n }\n\n // Define the configuration for the SDK client\n cfg := streams.Config{\n ApiKey: apiKey,\n ApiSecret: apiSecret,\n RestURL: \"https://api.testnet-dataengine.chain.link\",\n Logger: streams.LogPrintf,\n }\n\n // Initialize the SDK client\n client, err := streams.New(cfg)\n if err != nil {\n cfg.Logger(\"Failed to create client: %v\\n\", err)\n os.Exit(1)\n }\n\n // Create context with timeout\n ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second)\n defer cancel()\n\n // Parse the feed ID\n var feedID feed.ID\n if err := feedID.FromString(feedIDInput); err != nil {\n cfg.Logger(\"Invalid feed ID format '%s': %v\\n\", feedIDInput, err)\n os.Exit(1)\n }\n\n // Fetch the latest report\n reportResponse, err := client.GetLatestReport(ctx, feedID)\n if err != nil {\n cfg.Logger(\"Failed to get latest report: %v\\n\", err)\n os.Exit(1)\n }\n\n // Log the raw report data\n cfg.Logger(\"Raw report data: %+v\\n\", reportResponse)\n\n // Decode the report\n decodedReport, err := report.Decode[v4.Data](reportResponse.FullReport)\n if err != nil {\n cfg.Logger(\"Failed to decode report: %v\\n\", err)\n os.Exit(1)\n }\n\n // Format and display the decoded report\n fmt.Printf(\"\\nDecoded Report for Feed ID %s:\\n\"+\n \"------------------------------------------\\n\"+\n \"Observations Timestamp: %d\\n\"+\n \"Benchmark Price : %s\\n\"+\n \"Valid From Timestamp : %d\\n\"+\n \"Expires At : %d\\n\"+\n \"Link Fee : %s\\n\"+\n \"Native Fee : %s\\n\"+\n \"Market Status : %d\\n\"+\n \"------------------------------------------\\n\",\n feedIDInput,\n decodedReport.Data.ObservationsTimestamp,\n decodedReport.Data.BenchmarkPrice.String(),\n decodedReport.Data.ValidFromTimestamp,\n decodedReport.Data.ExpiresAt,\n decodedReport.Data.LinkFee.String(),\n decodedReport.Data.NativeFee.String(),\n decodedReport.Data.MarketStatus,\n )\n}\n\nDownload the required dependencies and update the go.mod and go.sum files:\ngo mod tidy\n\nSet up the SDK client configuration within single-feed.go with your API credentials and the REST endpoint:\ncfg := streams.Config{\n ApiKey: os.Getenv(\"API_KEY\"),\n ApiSecret: os.Getenv(\"API_SECRET\"),\n RestURL: \"https://api.testnet-dataengine.chain.link\",\n Logger: streams.LogPrintf,\n}\n\nSet your API credentials as environment variables:\nexport API_KEY=\"<YOUR_API_KEY>\"\nexport API_SECRET=\"<YOUR_API_SECRET>\"\n\nReplace <YOUR_API_KEY> and <YOUR_API_SECRET> with your API credentials.\n\nRestURL is the REST endpoint to poll for specific reports. See the Data Streams API Interface page for more information.\n\nSee the SDK Reference page for more configuration options.\n\nFor this example, you will read from the EUR/USD DataLink feed on testnet. This feed ID is 0x0004b9905d8337c34e00f8dbe31619428bac5c3937e73e6af75c71780f1770ce.\nExecute your application:\ngo run single-feed.go 0x0004b9905d8337c34e00f8dbe31619428bac5c3937e73e6af75c71780f1770ce\n\nExpect output similar to the following in your terminal:\n2025-06-03T10:25:18-05:00 Raw report data: {\"fullReport\":\"0x00090d9e8d96765a0c49e03a6ae05c82e8f8de70cf179baa632f18313e54bd69000000000000000000000000000000000000000000000000000000000041438a000000000000000000000000000000000000000000000000000000030000000100000000000000000000000000000000000000000000000000000000000000e000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000000260000100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001000004b9905d8337c34e00f8dbe31619428bac5c3937e73e6af75c71780f1770ce00000000000000000000000000000000000000000000000000000000683f13dd00000000000000000000000000000000000000000000000000000000683f13dd00000000000000000000000000000000000000000000000000006e0e3915bcc3000000000000000000000000000000000000000000000000004edc1454fb6ef0000000000000000000000000000000000000000000000000000000006866a0dd0000000000000000000000000000000000000000000000000fcaa20569eac064000000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000027b160a6824ccce49dc0bd19f636c40de2f3033410c7d1a7400b9a3cb0073d19dde0f87cfd6d9ce03156464a49cacb07136d2e7d717efcf42bc2795fd5c513e4a00000000000000000000000000000000000000000000000000000000000000025e075a9d8a6223ce2b9e524a7b5a563c2924a67b544e6676a751f5374b2a42ee37684b560eb72546f87b7287cefc668705461b7f4ebe4dabd7babe397cc98b89\",\"feedID\":\"0x0004b9905d8337c34e00f8dbe31619428bac5c3937e73e6af75c71780f1770ce\",\"validFromTimestamp\":1748964317,\"observationsTimestamp\":1748964317}\n\nDecoded Report for Feed ID 0x0004b9905d8337c34e00f8dbe31619428bac5c3937e73e6af75c71780f1770ce:\n------------------------------------------\nObservations Timestamp: 1748964317\nBenchmark Price : 1137900000000000100\nValid From Timestamp : 1748964317\nExpires At : 1751556317\nLink Fee : 22197028066651888\nNative Fee : 121007366323395\nMarket Status : 2\n------------------------------------------\n\nDecoded report detailsThe decoded report details include:AttributeValueDescriptionFeed ID0x0004b9905d8337c34e00f8dbe31619428bac5c3937e73e6af75c71780f1770ceThe unique identifier for the feed. In this example, the feed is for EUR/USD.Observations Timestamp1748964317The timestamp indicating when the data was captured.Benchmark Price1137900000000000100The observed price in the report, with 18 decimals. For readability: 1.1379 USD per EUR.Valid From Timestamp1748964317The start validity timestamp for the report, indicating when the data becomes relevant.Expires At1751556317The expiration timestamp of the report, indicating the point at which the data becomes outdated.Link Fee22197028066651888The fee to pay in LINK tokens for the onchain verification of the report data. With 18 decimals. For readability: 0.022197028066651888 LINK. Note: This example fee is not indicative of actual fees.Native Fee121007366323395The fee to pay in the native blockchain token (e.g., ETH on Ethereum) for the onchain verification of the report data. With 18 decimals. For readability: 0.000121007366323395 ETH. Note: This example fee is not indicative of actual fees.Market Status2The current market status. 2 indicates the market is Open.Payload for onchain verificationIn this guide, you log and decode the full_report payload to extract the report data. In a\nproduction environment, you should verify the data to ensure its integrity and authenticity. Refer to the\nVerify report data onchain guide.\n\nAdapting code for different report schema versionsWhen working with different DataLink providers, you'll need to adapt your code to handle the specific report schema version they use:\n\nImport the correct schema version. Examples:\n\nFor v4 schema (as used in this example):\nv4 \"github.com/smartcontractkit/data-streams-sdk/go/report/v4\"\n\nFor v3 schema:\nv3 \"github.com/smartcontractkit/data-streams-sdk/go/report/v3\"\n\nUpdate the decode function to use the correct schema version. Examples:\n\nFor v4 schema (as used in this example):\ndecodedReport, err := report.Decode[v4.Data](reportResponse.FullReport)\n\nFor v3 schema:\ndecodedReport, err := report.Decode[v3.Data](reportResponse.FullReport)\n\nAccess fields according to the schema version structure.\n\nExplanationInitializing the client and configurationThe Data Streams client is initialized in two steps:\n\nConfigure the client with streams.Config:\ncfg := streams.Config{\n ApiKey: os.Getenv(\"API_KEY\"),\n ApiSecret: os.Getenv(\"API_SECRET\"),\n RestURL: \"https://api.testnet-dataengine.chain.link\",\n Logger: streams.LogPrintf,\n}\n\nIn the configuration, you need:\n\nApiKey and ApiSecret for authentication (required)\nRestURL for the API endpoint (required)\nLogger for debugging and error tracking (optional, defaults to streams.LogPrintf)\n\nCreate the client with streams.New:\nclient, err := streams.New(cfg)\n\nThe client handles:\n\nAuthentication with HMAC signatures\nConnection management and timeouts\nError handling and retries\n\nFetching reportsThe SDK provides two main methods to fetch reports:\n\nLatest report for a single feed with GetLatestReport:\nreportResponse, err := client.GetLatestReport(ctx, feedID)\n\nTakes a context and feed ID\nReturns a single ReportResponse with the most recent data\nNo timestamp parameter needed\nUseful for real-time price monitoring\n\nLatest reports for multiple feeds with GetReports:\nreportResponses, err := client.GetReports(ctx, ids, timestamp)\n\nTakes context, feed IDs array, and Unix timestamp\nReturns array of ReportResponse, one per feed ID\nTimestamp determines the point in time for the reports\nEfficient for monitoring multiple assets simultaneously\n\nEach API request automatically:\nHandles authentication with API credentials\nManages request timeouts via context\nProcesses responses into structured types\nDecoding reportsReports are decoded in two steps:\n\nReport decoding with report.Decode:\ndecodedReport, err := report.Decode[v4.Data](reportResponse.FullReport)\n\nThis step:\n\nTakes the raw FullReport bytes from the response\nUses v4.Data schema (for this example)\nValidates the format and decodes using Go generics\nReturns a structured report with typed data\n\nData access:\ndata := decodedReport.Data\nfeedID := data.FeedID // Feed identifier\nobservationsTimestamp := data.ObservationsTimestamp // Unix timestamp\nprice := data.BenchmarkPrice.String() // Convert big number to string, 18 decimal places\nvalidFrom := data.ValidFromTimestamp // Unix timestamp\nexpiresAt := data.ExpiresAt // Unix timestamp\nlinkFee := data.LinkFee.String() // Convert big number to string, 18 decimal places\nnativeFee := data.NativeFee.String() // Convert big number to string, 18 decimal places\nmarketStatus := data.MarketStatus // Market status (0=Unknown, 1=Closed, 2=Open, 3=Suspended)\n\nProvides access to:\n\nFeed ID (hex string identifier)\nObservations timestamp (when data was captured)\nBenchmark price (as big number with 18 decimals)\nFee information (LINK and native token fees as big numbers with 18 decimals)\nTimestamp data (validity period)\nMarket status (0=Unknown, 1=Closed, 2=Open)\n\nNote: Price and fee values require .String() for display as they are big number types.\n\nError handlingThe SDK uses Go's standard error handling patterns with some enhancements:\n\nContext management:\nctx, cancel := context.WithTimeout(context.Background(), 10*time.Second)\ndefer cancel()\n\nSets request timeouts for API calls\ndefer cancel() ensures cleanup of resources\nSame context pattern for both single and multiple reports\n\nError checking:\nif err != nil {\n cfg.Logger(\"Failed to decode report: %v\\n\", err)\n os.Exit(1) // Fatal errors: exit the program\n // or\n continue // Non-fatal errors: skip this report\n}\n\nFatal errors (client creation, no valid feeds) use os.Exit(1)\nNon-fatal errors (single report decode) use continue\nAll errors are logged before handling\n\nSDK logging:\ncfg.Logger(\"Raw report data: %+v\\n\", reportResponse)\n\nUses configured logger for SDK operations\nfmt.Printf for user-facing output\nDebug information includes raw report data\nStructured error messages with context\n\nThe decoded data can be used for further processing or display in your application. For production environments, you must verify the data onchain using the provided fullReport payload.","tokens":3527,"squid":"spider-08","role":"Oracle Spider","at":1791348049472,"hash":"a92818f8ad6f03856f6fe492a8107021e4483404"}
{"url":"https://docs.phantom.com/ethereum-monad-testnet-base-and-polygon/detecting-the-provider","domain":"docs.phantom.com","title":"Detect the provider - Phantom developer documentation","text":"To detect if a user has already installed Phantom, a web application should check for the existence of a phantom object. Phantom’s browser extension and mobile in-app browser will both inject a phantom object into the window of any web application the user visits, provided that site is using https://, on localhost, or is 127.0.0.1. Phantom will not inject the provider into iframes or sites using http://.\nIf a phantom object exists, EVM dApps can interact with Phantom via the API found at window.phantom.ethereum. This ethereum provider is also made available at window.ethereum but is prone to namespace collisions from other injected wallets.\nTo detect if Phantom is installed, an application should check for an additional isPhantom flag.\nconst isPhantomInstalled = window?.phantom?.ethereum?.isPhantom\n\nIf Phantom is not installed, we recommend you redirect your users to our website https://phantom.com/. Altogether, this may look like the following:\n​window.phantom\nconst getProvider = () => {\n if ('phantom' in window) {\n const anyWindow: any = window;\n const provider = anyWindow.phantom?.ethereum;\n\n if (provider) {\n return provider;\n }\n }\n\n window.open('https://phantom.com/', '_blank');\n};\n\n​window.ethereum\nconst getProvider = () => {\n if ('ethereum' in window) {\n const anyWindow: any = window;\n const provider = anyWindow.ethereum;\n\n if (provider?.isPhantom) {\n return provider;\n }\n }\n\n window.open('https://phantom.com/', '_blank');\n};\n\nFor an example of how a React application can detect Phantom, refer to getProvider in our sandbox.Was this page helpful?","tokens":394,"squid":"spider-10","role":"Tooling Spider","at":1791348051895,"hash":"80c651c5cf2a936ec43993a6dde4a5ed057e54e2"}
{"url":"https://docs.chain.link/datalink/pull-delivery/tutorials/stream-decode/ws-go","domain":"docs.chain.link","title":"Stream and Decode reports using the Go SDK (WebSocket) | Chainlink Documentation","text":"Stream and Decode reports using the Go SDK (WebSocket) Guide Versions This guide is available in multiple versions. Choose the one that matches your needs. Stream and decode reports using the Go SDK Stream and decode reports using the Rust SDK In this guide, you'll learn how to use the Data Streams SDK for Go to stream and decode DataLink feeds from the Aggregation Network. You'll set up your Go project, listen for real-time reports, decode them, and log their attributes. \n\nRequirements\nGit: Make sure you have Git installed. You can check your current version by running git --version in your terminal and download the latest version from the official Git website if necessary.\nGo Version: Make sure you have Go version 1.22.4 or higher. You can check your current version by running go version in your terminal and download the latest version from the official Go website if necessary.\nAPI Credentials: Access to DataLink requires API credentials to connect to the Aggregation Network. If you haven't already, contact us to request access.\n\nGuideSet up your Go project\n\nCreate a new directory for your project and navigate to it:\nmkdir my-datalink-project\ncd my-datalink-project\n\nInitialize a new Go module:\ngo mod init my-datalink-project\n\nInstall the Data Streams SDK:\ngo get github.com/smartcontractkit/data-streams-sdk/go\n\nUnderstanding Report Schema VersionsData Providers may use different report schema versions. The schema version determines the structure of the data returned by the feed and affects how you should decode the report.\nImport the appropriate schema version in your code (e.g., v4).\nUse that version when decoding the report with report.Decode[v4.Data]().\nDifferent schema versions have different fields and structures.In this example, we're using report schema v4 for the EUR/USD feed, but your implementation should match the schema version specified by your Data Provider.Establish a WebSocket connection and listen for real-time reports\n\nCreate a new Go file, stream.go, in your project directory:\ntouch stream.go\n\nInsert the following code example and save your stream.go file:\npackage main\n\nimport (\n \"context\"\n \"fmt\"\n \"os\"\n \"time\"\n\n streams \"github.com/smartcontractkit/data-streams-sdk/go\"\n feed \"github.com/smartcontractkit/data-streams-sdk/go/feed\"\n report \"github.com/smartcontractkit/data-streams-sdk/go/report\"\n v4 \"github.com/smartcontractkit/data-streams-sdk/go/report/v4\" // Import the v4 report schema.\n)\n\nfunc main() {\n if len(os.Args) < 2 {\n fmt.Println(\"Usage: go run stream.go [StreamID1] [StreamID2] ...\")\n os.Exit(1)\n }\n\n // Set up the SDK client configuration\n cfg := streams.Config{\n ApiKey: os.Getenv(\"API_KEY\"),\n ApiSecret: os.Getenv(\"API_SECRET\"),\n WsURL: \"wss://ws.testnet-dataengine.chain.link\",\n Logger: streams.LogPrintf,\n }\n\n // Create a new client\n client, err := streams.New(cfg)\n if err != nil {\n cfg.Logger(\"Failed to create client: %v\\n\", err)\n os.Exit(1)\n }\n\n // Parse the feed IDs from the command line arguments\n var ids []feed.ID\n for _, arg := range os.Args[1:] {\n var fid feed.ID\n if err := fid.FromString(arg); err != nil {\n cfg.Logger(\"Invalid stream ID %s: %v\\n\", arg, err)\n os.Exit(1)\n }\n ids = append(ids, fid)\n }\n\n ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)\n defer cancel()\n\n // Subscribe to the feed(s)\n stream, err := client.Stream(ctx, ids)\n if err != nil {\n cfg.Logger(\"Failed to subscribe: %v\\n\", err)\n os.Exit(1)\n }\n\n defer stream.Close()\n for {\n reportResponse, err := stream.Read(context.Background())\n if err != nil {\n cfg.Logger(\"Error reading from stream: %v\\n\", err)\n continue\n }\n\n // Log the contents of the report before decoding\n cfg.Logger(\"Raw report data: %+v\\n\", reportResponse)\n\n // Decode each report as it comes in\n decodedReport, decodeErr := report.Decode[v4.Data](reportResponse.FullReport)\n if decodeErr != nil {\n cfg.Logger(\"Failed to decode report: %v\\n\", decodeErr)\n continue\n }\n\n // Log the decoded report\n cfg.Logger(\"\\n--- Report Stream ID: %s ---\\n\" +\n \"------------------------------------------\\n\" +\n \"Observations Timestamp : %d\\n\" +\n \"Benchmark Price : %s\\n\" +\n \"Valid From Timestamp : %d\\n\" +\n \"Expires At : %d\\n\" +\n \"Link Fee : %s\\n\" +\n \"Native Fee : %s\\n\" +\n \"Market Status : %d\\n\" +\n \"------------------------------------------\\n\",\n reportResponse.FeedID.String(),\n decodedReport.Data.ObservationsTimestamp,\n decodedReport.Data.BenchmarkPrice.String(),\n decodedReport.Data.ValidFromTimestamp,\n decodedReport.Data.ExpiresAt,\n decodedReport.Data.LinkFee.String(),\n decodedReport.Data.NativeFee.String(),\n decodedReport.Data.MarketStatus,\n )\n\n // Also, log the stream stats\n cfg.Logger(\"\\n--- Stream Stats ---\\n\" +\n stream.Stats().String() + \"\\n\" +\n \"--------------------------------------------------------------------------------------------------------------------------------------------\\n\",\n )\n }\n}\n\nDownload the required dependencies and update the go.mod and go.sum files:\ngo mod tidy\n\nSet up the SDK client configuration within stream.go with your API credentials and the WebSocket URL:\ncfg := streams.Config{\n ApiKey: os.Getenv(\"API_KEY\"),\n ApiSecret: os.Getenv(\"API_SECRET\"),\n WsURL: \"wss://ws.testnet-dataengine.chain.link\",\n Logger: streams.LogPrintf,\n}\n\nSet your API credentials as environment variables:\nexport API_KEY=\"<YOUR_API_KEY>\"\nexport API_SECRET=\"<YOUR_API_SECRET>\"\n\nReplace <YOUR_API_KEY> and <YOUR_API_SECRET> with your API credentials.\n\nWsURL is the WebSocket URL for the Data Streams Aggregation Network. Use wss://ws.testnet-dataengine.chain.link for the testnet environment.\n\nSee the SDK Reference page for more configuration options.\n\nFor this example, you'll subscribe to the EUR/USD DataLink feed on testnet. This feed ID is 0x0004b9905d8337c34e00f8dbe31619428bac5c3937e73e6af75c71780f1770ce.\nExecute your application:\ngo run stream.go 0x0004b9905d8337c34e00f8dbe31619428bac5c3937e73e6af75c71780f1770ce\n\nExpect output similar to the following in your terminal:\n2025-06-03T11:00:21-05:00 Raw report data: {\"fullReport\":\"0x00090d9e8d96765a0c49e03a6ae05c82e8f8de70cf179baa632f18313e54bd690000000000000000000000000000000000000000000000000000000000415a52000000000000000000000000000000000000000000000000000000030000000100000000000000000000000000000000000000000000000000000000000000e000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000000260000100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001000004b9905d8337c34e00f8dbe31619428bac5c3937e73e6af75c71780f1770ce00000000000000000000000000000000000000000000000000000000683f1c1500000000000000000000000000000000000000000000000000000000683f1c1500000000000000000000000000000000000000000000000000006ed14d655b7f000000000000000000000000000000000000000000000000004f3ee8709ff739000000000000000000000000000000000000000000000000000000006866a9150000000000000000000000000000000000000000000000000fc8b012a2e7080000000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000002ba6f4e2b770d818a554bd2b2a3c5bc1c0f15632af10e7b08c29d79fb0ad77fa16091843dd3ab39ece9274fb0c44f7fd8694b87724d9d4906e715672170bd8abb00000000000000000000000000000000000000000000000000000000000000026dc37bff09cd3673d53e60872b65ee6e566f11f2f1a308b38a6f0bdfa9f25ab15bd4599ab01c9d06c744b9f6d41e3f50e5cccc1a564e7e2c930c7af0b74f1f36\",\"feedID\":\"0x0004b9905d8337c34e00f8dbe31619428bac5c3937e73e6af75c71780f1770ce\",\"validFromTimestamp\":1748966421,\"observationsTimestamp\":1748966421}\n\n2025-06-03T11:00:21-05:00\n--- Report Stream ID: 0x0004b9905d8337c34e00f8dbe31619428bac5c3937e73e6af75c71780f1770ce ---\n------------------------------------------\nObservations Timestamp : 1748966421\nBenchmark Price : 1137352500000000000\nValid From Timestamp : 1748966421\nExpires At : 1751558421\nLink Fee : 22305691203008313\nNative Fee : 121845225708415\nMarket Status : 2\n------------------------------------------\n\n2025-06-03T11:00:21-05:00\n--- Stream Stats ---\naccepted: 1, deduplicated: 0, total_received 1, partial_reconnects: 0, full_reconnects: 0, configured_connections: 1, active_connections 1\n--------------------------------------------------------------------------------------------------------------------------------------------\n\n2025-06-03T11:00:22-05:00 Raw report data: {\"fullReport\":\"0x00090d9e8d96765a0c49e03a6ae05c82e8f8de70cf179baa632f18313e54bd690000000000000000000000000000000000000000000000000000000000415a55000000000000000000000000000000000000000000000000000000030000000100000000000000000000000000000000000000000000000000000000000000e000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000000260010100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001000004b9905d8337c34e00f8dbe31619428bac5c3937e73e6af75c71780f1770ce00000000000000000000000000000000000000000000000000000000683f1c1600000000000000000000000000000000000000000000000000000000683f1c1600000000000000000000000000000000000000000000000000006ed0247f9673000000000000000000000000000000000000000000000000004f3f25cd2ee9ee000000000000000000000000000000000000000000000000000000006866a9160000000000000000000000000000000000000000000000000fc8dd8c2b242800000000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000024e36294fb0464d2d1fa23512a03ca207d3adc9a9eef0291fd541eefdc364085a208276cb25ceb18587a8bd7bc8de54a74e3040cfda1aca3591913b51fa8b9bda0000000000000000000000000000000000000000000000000000000000000002347dd491b33b8dbd78c1a0d4b4641beb9cee1d761c3e56e7181845ac73b4efca490e36c776ac856bbf89a68064fde4c3bed22c43e48a4c3c4fb7cbe470eaa544\",\"feedID\":\"0x0004b9905d8337c34e00f8dbe31619428bac5c3937e73e6af75c71780f1770ce\",\"validFromTimestamp\":1748966422,\"observationsTimestamp\":1748966422}\n\n2025-06-03T11:00:22-05:00\n--- Report Stream ID: 0x0004b9905d8337c34e00f8dbe31619428bac5c3937e73e6af75c71780f1770ce ---\n------------------------------------------\nObservations Timestamp : 1748966422\nBenchmark Price : 1137402500000000000\nValid From Timestamp : 1748966422\nExpires At : 1751558422\nLink Fee : 22305954748885486\nNative Fee : 121840244594291\nMarket Status : 2\n------------------------------------------\n\n2025-06-03T11:00:22-05:00\n--- Stream Stats ---\naccepted: 2, deduplicated: 0, total_received 2, partial_reconnects: 0, full_reconnects: 0, configured_connections: 1, active_connections 1\n--------------------------------------------------------------------------------------------------------------------------------------------\n\n2025-06-03T11:00:23-05:00 Raw report data: {\"fullReport\":\"0x00090d9e8d96765a0c49e03a6ae05c82e8f8de70cf179baa632f18313e54bd690000000000000000000000000000000000000000000000000000000000415a58000000000000000000000000000000000000000000000000000000030000000100000000000000000000000000000000000000000000000000000000000000e000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000000260000100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001000004b9905d8337c34e00f8dbe31619428bac5c3937e73e6af75c71780f1770ce00000000000000000000000000000000000000000000000000000000683f1c1700000000000000000000000000000000000000000000000000000000683f1c1700000000000000000000000000000000000000000000000000006ed11dd755d2000000000000000000000000000000000000000000000000004f3ee813f33a33000000000000000000000000000000000000000000000000000000006866a9170000000000000000000000000000000000000000000000000fc8dd8c2b24280000000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000002622edb20ce1b998661a29c9b45953e2d37aee73fd68305183bd00240b1b2c89f95df58e73235dd3b4872ad2c185605985cf952ce1837f6724af00aba74eb42b300000000000000000000000000000000000000000000000000000000000000024cec2d619f9e12c9caf22f675bc4df44a5930644be5562b8bb0fe3e3c859e7f34937b468c19f3c41c6bab8813311724897b1ab1c3aa1ffa783ad9aa5fcf258eb\",\"feedID\":\"0x0004b9905d8337c34e00f8dbe31619428bac5c3937e73e6af75c71780f1770ce\",\"validFromTimestamp\":1748966423,\"observationsTimestamp\":1748966423}\n\n2025-06-03T11:00:23-05:00\n--- Report Stream ID: 0x0004b9905d8337c34e00f8dbe31619428bac5c3937e73e6af75c71780f1770ce ---\n------------------------------------------\nObservations Timestamp : 1748966423\nBenchmark Price : 1137402500000000000\nValid From Timestamp : 1748966423\nExpires At : 1751558423\nLink Fee : 22305689648183859\nNative Fee : 121844427871698\nMarket Status : 2\n------------------------------------------\n\n2025-06-03T11:00:23-05:00\n--- Stream Stats ---\naccepted: 3, deduplicated: 0, total_received 3, partial_reconnects: 0, full_reconnects: 0, configured_connections: 1, active_connections 1\n--------------------------------------------------------------------------------------------------------------------------------------------\n\n[...]\n\nDecoded report detailsThe decoded report details include:AttributeValueDescriptionFeed ID0x0004b9905d8337c34e00f8dbe31619428bac5c3937e73e6af75c71780f1770ceThe unique identifier for the feed. In this example, the feed is for EUR/USD.Observations Timestamp1748966423The timestamp indicating when the data was captured.Benchmark Price1137402500000000000The observed price in the report, with 18 decimals. For readability: 1.1374025 USD per EUR.Valid From Timestamp1748966423The start validity timestamp for the report, indicating when the data becomes relevant.Expires At1751558423The expiration timestamp of the report, indicating the point at which the data becomes outdated.Link Fee22305689648183859The fee to pay in LINK tokens for the onchain verification of the report data. With 18 decimals. For readability: 0.022305689648183859 LINK. Note: This example fee is not indicative of actual fees.Native Fee121844427871698The fee to pay in the native blockchain token (e.g., ETH on Ethereum) for the onchain verification of the report data. With 18 decimals. For readability: 0.000121844427871698 ETH. Note: This example fee is not indicative of actual fees.Market Status2The current market status. 2 indicates the market is Open.Payload for onchain verificationIn this guide, you log and decode the full_report payload to extract the report data. In a\nproduction environment, you should verify the data to ensure its integrity and authenticity. Refer to the\nVerify report data onchain guide.\n\nAdapting code for different report schema versionsWhen working with different DataLink providers, you'll need to adapt your code to handle the specific report schema version they use:\n\nImport the correct schema version module. Examples:\n\nFor v4 schema (as used in this example):\nv4 \"github.com/smartcontractkit/data-streams-sdk/go/report/v4\"\n\nFor v3 schema:\nv3 \"github.com/smartcontractkit/data-streams-sdk/go/report/v3\"\n\nUpdate the decode function to use the correct schema version. Examples:\n\nFor v4 schema (as used in this example):\ndecodedReport, decodeErr := report.Decode[v4.Data](reportResponse.FullReport)\n\nFor v3 schema:\ndecodedReport, decodeErr := report.Decode[v3.Data](reportResponse.FullReport)\n\nAccess fields according to the schema version structure.\n\nExplanationEstablishing a WebSocket connection and listening for reportsYour application uses the Stream function in the Data Streams SDK's client package to establish a real-time WebSocket connection with the Data Streams Aggregation Network.Once the WebSocket connection is established, your application subscribes to one or more streams by passing an array of feed.IDs to the Stream function. This subscription lets the client receive real-time updates whenever new report data is available for the specified streams.Decoding a reportAs data reports arrive via the established WebSocket connection, they are processed in real-time:\n\nReading streams: The Read method on the returned Stream object is continuously called within a loop. This method blocks until new data is available, ensuring that all incoming reports are captured as soon as they are broadcasted.\n\nDecoding reports: For each received report, the SDK's Decode function parses and transforms the raw data into a structured format (v4.Data for this example). This decoded data includes data such as the benchmark price.\n\nHandling the decoded dataIn this example, the application logs the structured report data to the terminal. However, this data can be used for further processing, analysis, or display in your own application.","tokens":4145,"squid":"spider-08","role":"Oracle Spider","at":1791348060001,"hash":"f17774253d967861d1833b6a885a84c38adfa024"}
{"url":"https://docs.phantom.com/ethereum-monad-testnet-base-and-polygon/establishing-a-connection","domain":"docs.phantom.com","title":"Establish a connection - Phantom developer documentation","text":"Once an application has detected the provider, it can then request to connect to Phantom. This connection request will prompt the user for permission to share their public key, indicating that they are willing to interact further. Users must approve a connection request before the app can make additional requests such as signing a message or sending a transaction.\nOnce permission is established for the first time, the web application’s domain will be whitelisted for future connection requests. After a connection is established, it is possible to terminate the connection from both the application and the user side.\n​Connect\nThe default way to connect to Phantom is by calling the window.ethereum.request() function.\nconst provider = getProvider(); // see \"Detecting the Provider\"\ntry {\n const accounts = await provider.request({ method: \"eth_requestAccounts\" });\n console.log(accounts[0]);\n // 0x534583cd8cE0ac1af4Ce01Ae4f294d52b4Cd305F\n} catch (err) {\n // { code: 4001, message: 'User rejected the request.' }\n}\n\nThe eth_requestAccounts method will return a Promise. If it resolves, it is an array where the connected address is in the 0th index, and rejects (throw when awaited) when the user declines the request or closes the pop-up. See Errors for a breakdown of error messages Phantom may emit.\nWhen the user accepts the request to connect, the provider will also emit a connect event that contains the chainId of the network the user is connected to.\nprovider.on(\"connect\", (connectionInfo: { chainId: string }) => console.log(`Connected to chain: ${connectionInfo.chainId}`));\n\nOnce the web application is connected to Phantom, it will be able to read the connected account’s address and prompt the user for additional transactions. It also exposes a convenience isConnected boolean.\nconsole.log(provider.selectedAddress);\n// 0x534583cd8cE0ac1af4Ce01Ae4f294d52b4Cd305F \nconsole.log(provider.isConnected());\n// true\n\n​Disconnect\nThere is no way to programmatically disconnect a user from their connection once they have established one.\n\nOnce a user has established a connection, Phantom will add the website they opened a connection with to a list of “trusted apps.” The user can then revoke access through the UI at any time, and will then need to reconnect. Phantom will attempt to reconnect to any application that is added to the users’ “trusted apps” automatically.\n​Change accounts\nPhantom allows users to seamlessly manage multiple accounts (addresses) from within a single extension or mobile app. Whenever a user switches accounts, Phantom will emit an accountsChanged event.\nIf a user changes accounts while already connected to an application, and the new account had already whitelisted that application, then the user will stay connected and Phantom will pass the public key of the new account:\nprovider.on('accountsChanged', (publicKeys: String[]) => {\n if (publicKeys) {\n // Set new public key and continue as usual\n console.log(`Switched to account ${publicKeys[0]}`);\n } \n});\n\nIf Phantom does not pass the public key of the new account, an application can either do nothing or attempt to reconnect:\nprovider.on('accountsChanged', (publicKeys: String[]) => {\n if (publicKeys) {\n // Set new public key and continue as usual\n console.log(`Switched to account ${publicKeys[0].toBase58()}`);\n } else {\n // Attempt to reconnect to Phantom\n provider.request({ method: \"eth_requestAccounts\" }).catch((error) => {\n // handle connection failure\n });\n }\n});\nWas this page helpful?","tokens":875,"squid":"spider-10","role":"Tooling Spider","at":1791348062544,"hash":"3922ef0b073b864c5ca0ed78459bebf99d78fd1c"}
{"url":"https://research.arbitrum.io/t/submitting-transaction-bundles/75/22","domain":"research.arbitrum.io","title":"Submitting transaction bundles - Uncategorized - Arbitrum Research","text":"Uncategorized\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 5\n\n 2\n\n read \n\n 4\n min\n\n May 2022\n\n 15 / 15\n\n Aug 2025\n\n Aug 2025\n\n post by edfelten on May 21, 2022\n\n post by bbuddha on May 22, 2022\n\n post by edfelten on May 24, 2022\n\n post by bertcmiller on May 31, 2022\n\n post by edfelten on May 31, 2022\n\n post by eleglenctic on Jun 1, 2022\n\n post by edfelten on Jun 2, 2022\n\n 4 months later\n\n post by stonecoldpat on Oct 8, 2022\n\n 4 months later\n\n post by web3fishermen on Jan 25, 2023\n\n 2 months later\n\n post by hossein_alavi on Mar 19, 2023\n\n 1 month later\n\n post by pahakow on Apr 25, 2023\n\n post by edfelten on Apr 26, 2023\n\n edfelten\n\n The easiest way to do this would be to trust the sequencer to not separate the transactions in the bundle. This is straightforward to implement because one would just need to add an RPC to submit a set of transactions that are meant to be a bundle. Nothing on-chain would need to change.\nEnforcing bundling is more difficult because it would need to be the case that the sequencer cannot (say) extract one transaction from the bundle and just post that one. And that, in turn, seems to require that the transactions in the bundle can’t be separable from each other. That means, for example, that it won’t work to include each transaction’s data in encodable format along with a signature on that one transaction. Instead, the transactions in the bundle would somehow need to be entangled so that each one is invalid unless attached to the others.\nOne way to build non-separable transactions is to use a facility like ERC-4337 account abstraction, which is currently on Arbitrum’s testnet at the moment.\n\n 2 years later\n\n post by cmatt on Jul 16, 2025\n\n cmatt\n\n Has something like this been implemented or is still considered? Or has this been dropped because there are by now other methods, such as the mentioned way via account abstraction, via which something similar can be achieved? It seems to me ability to directly submit bundles to the sequencer could still be useful.\n\n 26 days later\n\n post by kakia on Aug 12, 2025\n\n kakia\n\n It is not implemented at the moment. Other methods may come close to implementing bundling, but nothing guarantees it. What useful cases do you have in mind for this?\n\n post by cmatt on Aug 15, 2025\n\n cmatt\n\n Thanks for the answer! I don’t have any specific use-case in mind. We have been looking into what sequencer commitments could enable for rollups (specifically OP, see https://mirror.xyz/preconf.eth/UoMhzBvWihwLLXuUYywjXLg4JmymEeC2jqlAeIRBD_Q) and cryptoeconomically protected bundles would be one of the things. Since people here seemed interested, we wondered what the status was. One possible use-case would be that you want to migrate some LP position from Uniswap V2 to V3 and you want closing the V2 and opening the V3 to be bundled since other trades in-between could unbalance your 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 Bundle imitation on Arbitrum\n\n Uncategorized\n\n defi,tx-ordering\n\n 3\n\n 1.9k\n\n Oct 2023\n\n Transaction ordering policy\n\n Uncategorized\n\n 10\n\n 8.6k\n\n Mar 2023\n\n Hybrid transaction ordering policy\n\n Uncategorized\n\n tx-ordering,sequencer\n\n 6\n\n 2.9k\n\n Nov 2022\n\n Proposed design for Timeboost\n\n Uncategorized\n\n 12\n\n 3.3k\n\n Jun 2024\n\n Arbitrum vs Optimism\n\n Uncategorized\n\n defi\n\n 1\n\n 2.6k\n\n Mar 2023","tokens":851,"squid":"spider-01","role":"Chain Spider","at":1791348073189,"hash":"090bccbf2fd1deb1c5398711fbf716857c949e15"}
{"url":"https://research.arbitrum.io/t/hybrid-transaction-ordering-policy/155/1","domain":"research.arbitrum.io","title":"Hybrid transaction ordering policy - Uncategorized - Arbitrum Research","text":"Hybrid transaction ordering policy \n\n Uncategorized\n\n tx-ordering,sequencer\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 4\n\n 2\n\n Oct 2022\n\n 1 / 7\n\n Oct 2022\n\n Nov 2022\n\n post by edfelten on Oct 5, 2022\n\n edfelten\n\n Inspired by some discussions and posts about transaction ordering (like this one), we’re thinking about how we might maintain the desirable properties of our transaction ordering policy (such as low latency, transparency, and ability to decentralize without affecting policy) with measures to reduce the prevalence of “latency racing” among transaction submitters.\nToward that end, we’re looking at potential policies that have the following properties:\n\nDark mempool: Submitted transactions are not visible to anyone other than the sequencer, until they are included in the published sequence. This prevents parties from front-running or sandwiching others’ transactions. (The sequencer is trusted not to engage in such tactics.)\nLow latency: Every transaction that arrives at the sequencer is emitted into the sequence within some time bound, perhaps 1/2 second.\nOver short time intervals, transactions with higher “tip” (per-gas priority fee) are ordered first. This is intended to induce parties who are contending for fast placement to do so by increasing their tip rather than expending resources to reduce their latency in delivering transactions to the sequencer.\nStable after decentralization: The goals of the policy will still be satisfied, after the sequencer is decentralized (assuming a suitable supermajority of sequencers apply the policy honestly).\n\nOne policy that might work would divide time into “chunks” of 1/2 second each, and sort the transactions arriving within the same chunk into decreasing tip order, breaking ties by earliest arrival. The sequencer would buffer incoming transactions for up to 1/2 second, then sort the buffer and emit into the sequence in sorted order, before repeating the process for the next chunk.\nThere are also more sophisticated algorithms that provide similar guarantees without having sharp boundaries between chunks.\nWe’re interested in the community’s feedback on transaction ordering policies along those general lines, as we consider whether to pursue a change like this.\n\n 4\n\n 2\n\n 15 days later\n\n post by edfelten on Oct 20, 2022\n\n edfelten\n\n We’re also interested in talking to anyone who might be interested in a bidding-based transaction ordering system like the one described in this thread.\n\n post by Hyujina on Oct 21, 2022\n\n Hyujina\n\n So basically a model with 0.5sec blocks and no mempool ?\nFrom a end consumer pov, it’s somehow a faster and sandwich-proof version of polygon ? If I got it right, big yes !\n\n post by haaroon on Oct 24, 2022\n\n haaroon\n\n edfelten\n\n I’ve always liked the idea of a dark mempool, this protects users from malicious actors that listen in on the system. But then it means we have to trust the sequencers, which then brings about when they are decentralised, what stops someone running a malicious sequencer?\nlow latency is always a must have!\n\n post by edfelten on Oct 25, 2022\n\n post by haaroon on Oct 26, 2022\n\n 9 days later\n\n post by edfelten on Nov 4, 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 Transaction ordering policy\n\n Uncategorized\n\n 10\n\n 8.6k\n\n Mar 2023\n\n Time boost: a new transaction ordering policy proposal\n\n Uncategorized\n\n 34\n\n 9.8k\n\n Sep 2023\n\n Proposed design for Timeboost\n\n Uncategorized\n\n 12\n\n 3.3k\n\n Jun 2024\n\n Decentralized Timeboost Specification\n\n Uncategorized\n\n tx-ordering,sequencer\n\n 2\n\n 881\n\n Sep 2024\n\n Challenging Periods Reimagined: The Key Role of Sequencer Decentralization\n\n Uncategorized\n\n defi,sequencer\n\n 5\n\n 3.6k\n\n Jul 2023","tokens":943,"squid":"spider-01","role":"Chain Spider","at":1791348095212,"hash":"0aeba324cda7686ba51d2d81c3c324d2d6496314"}
{"url":"https://akash.network/docs/providers/operations/","domain":"akash.network","title":"Operations | Akash Network - Your Guide to Decentralized Cloud","text":"Operations Day-to-day operational tasks for running an Akash provider.\nOnce your provider is running, these guides help you manage leases, monitor health, perform maintenance, and troubleshoot issues.\n\nOperational Areas\nLease Management\nManage the lifecycle of deployments on your provider\nCovers:\n\nList active leases (on-chain and Kubernetes)\nClose leases from provider side\nRetrieve deployment manifests\nTrack earnings (total, daily, monthly)\nHandle dangling deployments\nBlock specific container images\n\nUse when: Managing active deployments, tracking revenue, or troubleshooting lease issues.\n\nMonitoring\nMonitor provider health and troubleshoot issues\nCovers:\n\nView and filter provider logs\nCheck provider status and resource utilization\nGPU troubleshooting (drivers, Device Plugin, Fabric Manager)\nVerify NVIDIA components\nDiagnose bidding issues\n\nUse when: Checking provider health, investigating why bids aren’t happening, or troubleshooting GPU problems.\n\nUpdates & Maintenance\nKeep your provider updated and well-maintained\nCovers:\n\nStop/start provider services safely\nRotate Kubernetes and etcd certificates\nHandle stuck ReplicaSets\nKill zombie processes\nHeal broken deployment replicas\nMaintenance best practices\n\nUse when: Performing scheduled maintenance, rotating certificates, or fixing cluster issues.\n\nProvider Attributes\nConfigure provider capabilities and hardware discovery\nCovers:\n\nSubmit GPU details for feature discovery\nConfigure GPU attributes in provider.yaml\nVerify attribute registration\nTroubleshoot GPU detection issues\n\nUse when: Adding new GPU models, configuring provider capabilities, or fixing attribute mismatches.\n\nProvider Audit\nGet your provider officially audited\nCovers:\n\nComplete on-chain attribute requirements for audit pass\nDiscord membership and discord-username attribute\nDeploying the audit benchmark SDL\nSubmitting a [Provider Audit] GitHub issue\n\nUse when: You are ready for official audit and need the attribute checklist or benchmark steps.\n\nProvider Verification\nVerify your provider is running correctly\nCovers:\n\nProvider pod health checks\nOn-chain registration verification\nBid activity monitoring\nCommon troubleshooting steps\nVerification checklist\n\nUse when: After installation, when debugging issues, or performing routine health checks.\n\nCommon Tasks\nDaily:\n\nMonitor provider logs for errors\nCheck active leases and utilization\nVerify bid activity\n\nWeekly:\n\nReview certificate expiration dates\nCheck system resource usage\nVerify backups\n\nMonthly:\n\nUpdate provider services if needed\nReview and optimize bid pricing\nRotate Kubernetes certificates (check expiration)\n\nQuestions? Join #provider-support on Discord \nEdit page on github\n Provider Console Lease Management","tokens":681,"squid":"spider-03","role":"Compute Spider","at":1791348099279,"hash":"44fc07f8837151e81f45c18d1136b3d01305657d"}
{"url":"https://research.arbitrum.io/t/hybrid-transaction-ordering-policy/155/7","domain":"research.arbitrum.io","title":"Hybrid transaction ordering policy - Uncategorized - Arbitrum Research","text":"Uncategorized\n\n tx-ordering,sequencer\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 4\n\n 2\n\n Oct 2022\n\n 7 / 7\n\n Nov 2022\n\n Nov 2022\n\n post by edfelten on Oct 5, 2022\n\n edfelten\n\n Inspired by some discussions and posts about transaction ordering (like this one), we’re thinking about how we might maintain the desirable properties of our transaction ordering policy (such as low latency, transparency, and ability to decentralize without affecting policy) with measures to reduce the prevalence of “latency racing” among transaction submitters.\nToward that end, we’re looking at potential policies that have the following properties:\n\nDark mempool: Submitted transactions are not visible to anyone other than the sequencer, until they are included in the published sequence. This prevents parties from front-running or sandwiching others’ transactions. (The sequencer is trusted not to engage in such tactics.)\nLow latency: Every transaction that arrives at the sequencer is emitted into the sequence within some time bound, perhaps 1/2 second.\nOver short time intervals, transactions with higher “tip” (per-gas priority fee) are ordered first. This is intended to induce parties who are contending for fast placement to do so by increasing their tip rather than expending resources to reduce their latency in delivering transactions to the sequencer.\nStable after decentralization: The goals of the policy will still be satisfied, after the sequencer is decentralized (assuming a suitable supermajority of sequencers apply the policy honestly).\n\nOne policy that might work would divide time into “chunks” of 1/2 second each, and sort the transactions arriving within the same chunk into decreasing tip order, breaking ties by earliest arrival. The sequencer would buffer incoming transactions for up to 1/2 second, then sort the buffer and emit into the sequence in sorted order, before repeating the process for the next chunk.\nThere are also more sophisticated algorithms that provide similar guarantees without having sharp boundaries between chunks.\nWe’re interested in the community’s feedback on transaction ordering policies along those general lines, as we consider whether to pursue a change like this.\n\n 4\n\n 2\n\n 15 days later\n\n post by edfelten on Oct 20, 2022\n\n edfelten\n\n We’re also interested in talking to anyone who might be interested in a bidding-based transaction ordering system like the one described in this thread.\n\n post by Hyujina on Oct 21, 2022\n\n Hyujina\n\n So basically a model with 0.5sec blocks and no mempool ?\nFrom a end consumer pov, it’s somehow a faster and sandwich-proof version of polygon ? If I got it right, big yes !\n\n post by haaroon on Oct 24, 2022\n\n haaroon\n\n edfelten\n\n I’ve always liked the idea of a dark mempool, this protects users from malicious actors that listen in on the system. But then it means we have to trust the sequencers, which then brings about when they are decentralised, what stops someone running a malicious sequencer?\nlow latency is always a must have!\n\n post by edfelten on Oct 25, 2022\n\n edfelten\n\n With decentralized sequencing, the membership on the sequencer committee will still be permissioned. And there are ways to incorporate threshold decryption into the distributed sequencing protocol, so that individual sequencers (or collusions of a few sequencers) can’t see transactions before they’re sequenced.\n\n post by haaroon on Oct 26, 2022\n\n haaroon\n\n Firstly I do not see why sequencers always need to be permissioned? Is there a process of how this permissioning takes place,? Really defeats the purpose of decentralised systems if they are gated…\nSecondly , threshold decryption is great but becomes slower in respect to the number of sequencers needed to provide a slice for the decryption. making the process ever so slower as more nodes join the system unless there’s a way to have groups of sequencers.\n\n 9 days later\n\n post by edfelten on Nov 4, 2022\n\n edfelten\n\n For practical reasons, the number of sequencers participating at any given time needs to be limited, although that set can be changed over time, ideally in a way consistent with the community’s sentiment.\nBecause the number will be limited, threshold decryption shouldn’t be a bottleneck.\nWe’ll be talking more about decentralized sequencing architectures in the future.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Transaction ordering policy\n\n Uncategorized\n\n 10\n\n 8.6k\n\n Mar 2023\n\n Time boost: a new transaction ordering policy proposal\n\n Uncategorized\n\n 34\n\n 9.8k\n\n Sep 2023\n\n Proposed design for Timeboost\n\n Uncategorized\n\n 12\n\n 3.3k\n\n Jun 2024\n\n Decentralized Timeboost Specification\n\n Uncategorized\n\n tx-ordering,sequencer\n\n 2\n\n 881\n\n Sep 2024\n\n Challenging Periods Reimagined: The Key Role of Sequencer Decentralization\n\n Uncategorized\n\n defi,sequencer\n\n 5\n\n 3.6k\n\n Jul 2023","tokens":1228,"squid":"spider-01","role":"Chain Spider","at":1791348105360,"hash":"9ffa6aba1ef7c7320951310a197d838fbb689be8"}
{"url":"https://akash.network/docs/providers/operations/lease-management/","domain":"akash.network","title":"Lease Management | Akash Network - Your Guide to Decentralized Cloud","text":"Lease Management Use the unified akt CLI for on-chain lease operations and kubectl for the workloads represented inside the provider cluster. Comparing both views helps identify a lease that is closed on-chain but still has cluster resources, or a live lease whose workload is unhealthy.\nBefore you start\nInstall akt and select a mainnet keyring context containing the provider key. Confirm the active identity before a transaction:\nTerminal windowakt context showakt context keys show <provider-key> --address\nThe address must match the provider owner recorded in provider.yaml.\nList active provider leases\nQuery active leases by provider address:\nTerminal windowakt query market lease \\ --by provider \\ <provider-address> \\ active \\ --page 1 \\ --limit 500\nakt uses positional resource filters. The active context supplies the chain ID, RPC endpoint, and query defaults.\nCompare leases with cluster workloads\nList the provider’s workload records and their lease labels:\nTerminal windowkubectl --namespace lease get manifests --show-labelskubectl --namespace lease get providerhosts\nInspect one manifest:\nTerminal windowkubectl --namespace lease get manifest <manifest-name> --output yaml\nThe labels identify the owner, deployment sequence (dseq), group sequence (gseq), order sequence (oseq), and provider. Match that tuple to the on-chain lease result.\nDeployment routes use Gateway API resources. Confirm them with:\nTerminal windowkubectl get httproutes --all-namespaces\nClose a provider bid\nClosing a bid terminates the provider side of the lease and releases its capacity. Verify the exact lease tuple and reason before signing:\nTerminal windowakt tx market bid close \\ --owner <tenant-address> \\ --dseq <dseq> \\ --gseq <gseq> \\ --oseq <oseq> \\ --from <provider-key> \\ --reason 10002 \\ --yes\nThe provider address is derived from the signing key. Do not pass the tenant’s key or address to --from.\nProvider reason codes are:\n\nCodeMeaning10000Workload or environment instability10001Planned decommissioning10002Unspecified provider reason10003Tenant did not send a manifest in time\nIf the lease uses a reclamation window, follow the reclamation procedure. The chain rejects a close transaction submitted before its reclamation deadline.\nVerify cleanup\nAfter the transaction is committed, confirm that the lease is no longer active and that its cluster resources disappear:\nTerminal windowakt query market lease \\ --by provider \\ <provider-address> \\ active \\ --page 1 \\ --limit 500\nkubectl --namespace lease get manifests --show-labelskubectl get namespaces\nIf a closed lease remains in Kubernetes, inspect the provider and operator logs before deleting anything manually:\nTerminal windowkubectl --namespace akash-services logs statefulset/akash-provider --tail 200kubectl --namespace akash-services get podskubectl --namespace lease get events --sort-by=.metadata.creationTimestamp\nRestart the provider only after identifying a reconciliation problem:\nTerminal windowkubectl --namespace akash-services rollout restart statefulset/akash-providerkubectl --namespace akash-services rollout status statefulset/akash-provider\nAutomation safety\nDo not automate lease closure by executing the legacy provider-services binary inside the provider pod. The akt binary, context, and signing key are not supplied by that pod, and interactive keyrings are unsuitable for unattended cron jobs.\nAn automated policy needs a dedicated, least-privilege keyring context, a non-interactive secret source, exact allow or deny rules, transaction auditing, retry protection, and alerting. Test the policy with akt’s --dry-run option before enabling signed transactions. Keep private keys outside scripts, container images, and Git.\nRelated resources\n\nakt queries and transactions\nakt contexts and key management\nProvider Status and Monitoring\nProvider Verification\n\nEdit page on github\n Provider Console Updates & Maintenance","tokens":977,"squid":"spider-03","role":"Compute Spider","at":1791348110541,"hash":"65a2d5e04ceb0c7dfea8cc2cc5b1a3868ca0c9cc"}
{"url":"https://research.arbitrum.io/t/proposed-design-for-timeboost/9491","domain":"research.arbitrum.io","title":"Proposed design for Timeboost - Uncategorized - Arbitrum Research","text":"Proposed design for Timeboost \n\n Uncategorized\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 read \n\n 5\n min\n\n Sep 2023\n\n 1 / 13\n\n Sep 2023\n\n Jun 2024\n\n post by edfelten on Sep 27, 2023\n\n edfelten\n\n [Update (June 2024): This design is no longer recommended by the Offchain Labs research team. However, I’m leaving this post in place to preserve the record.]\nThe Offchain Labs research team has a specific proposed design in mind for adding Timeboost to the current centralized sequencer design. This would allow Arbitrum chains to prevent front-running, while capturing the value of benign MEV types like arbitrage.\nThe design has two parts: a change to the sequencer’s transaction ordering policy, and a new transaction type.\nThe sequencer’s ordering policy would go in rounds, with each round containing these steps:\n\nthe sequencer waits for a fixed period (tentatively: 0.5 seconds), collecting all transactions that arrive before the end of the period\nthe sequencer sorts the collected transactions into decreasing order by bid, breaking ties by a deterministic rule,\nthe sequencer builds a block from the sorted transaction list and emits that block into its output feed,\nthe round ends and the next round starts\n\nThe new transaction type is identical to a standard user-signed transaction, with the only differences being (1) a different transaction type label, and (2) how transaction fees are collected by the chain. For the new transaction type, the chain would collect the priority fee (“tip”) per gas unit as in Ethereum. (By contrast, standard transaction types don’t pay the priority fee on Arbitrum chains.) So the new transaction type would pay a gas price equal to the current Arbitrum-chain base fee plus the transaction’s priority fee.\nA transaction’s bid, for sorting purposes, is (1) its priority fee, if it is the new transaction type, or (2) zero, for other transaction types. So a transaction can get earlier placement within its block by paying a higher priority fee. This implements a sealed-bid, all-pay, priority gas auction for position within the block.\nIn this design, the sequencer does not collect any “MEV fees”. Instead, transactions bid for position by offering to pay a priority fee for each gas unit they use. The resulting fees are collected by the chain, as part of its normal gas fee collection mechanism.\nThe priority fees would be collected by the chain and paid to an address specified by chain governance. In the case of DAO-governed chains, this address would be specified by the DAO.\nFor most chains, the fees would be paid to a smart contract which would split up the fee revenue as specified by chain governance. Most likely this would mean the largest share of priority fee revenue would go to the chain owner (e.g., the DAO) with perhaps a small slice going to the sequencer operator(s).\nI gave a more detailed talk about this design and why I think it makes sense, at the Stanford MEV Workshop. Video is available here.\n(One obvious design alternative is to not introduce a new transaction type, and just use the existing transaction type, which already has a priority fee field. The alternative would involve collecting the priority fee for existing transactions, which would be a change from the current policy of ignoring the priority fee field and treating all transactions as if they submitted a priority fee of zero.\nThe drawback of this alternative is many current transactions include a priority fee, typically a few gwei, because that is the default in some wallets–so that collecting the priority fee would cause many users to inadvertently pay much more for gas (adding, say, a 2 gwei tip on top of the 0.1 gwei base fee, a 21x increase in fee). By creating a new transaction type, and continuing to treat all legacy transaction types as having priority fee zero, we would protect users from this issue.)\n\n Time boost: a new transaction ordering policy proposal\n\n 5\n\n 3\n\n 2\n\n read \n\n 5\n min\n\n post by haaroon on Sep 29, 2023\n\n haaroon\n\n Thanks Ed for the detailed write up, but I can’t help but wonder what will happen to fees. L2s are supposed to be cheap, how does this\n\nAffect Gas price inflation: surely during peak times it will be very costly to do a simple transaction?\nThis causes an inequality as users who can’t afford to pay simply have to wait and continue trying, favouring users who have the gas to burn?\ndeterministic rule tie breaking - doesn’t this incentivise bad actors to try and manipulate this?\nfront running is still possible no, you just pay the highest fee and probabilistically determine how high you will be up (probabilistic ordering is being talked about now in the dark circles)\n\nHave you looked into potentially adding in threshold security that encrypts transaction at submission, only to be decrypted by a decentralised committee after the consensus layer, should prevent people from exploiting pending txs. From [2205.08529] F3B: A Low-Overhead Blockchain Architecture with Per-Transaction Front-Running Protection\nThanks\n\n post by edfelten on Sep 30, 2023\n\n edfelten\n\n Thanks for your questions and suggestion on threshold decryption.\nImportantly, the bidders in timeboost are not contending for inclusions–every transaction that arrives by the deadline will be included in the block. They are only contending for ordering within the block. Unlike Ethereum, Arbitrum does not have an in-protocol limit on the number of txs that can run in some period of time. (The only real limit is the rate at which the sequencer can handle incoming RPCs, which is the same in the currrent system.)\nAlso, this design maintains the “secret mempool” feature of Arbitrum sequencing, so it will not be possible for external parties to see transactions and then outbid them. If a transaction arrives before some block’s deadline, it will be included in that block, and the block contents won’t be published until after the deadline–so by the time a transaction becomes visible to anyone (other than the sequencer itself), it will be too late to front-run it.\nI would expect ordinary user txs to bid zero, because they will still be guaranteed mempool secrecy and prompt inclusion even with a zero bid. So I don’t think this will affect the gas fees paid by ordinary transactions.\nWith that background, here are answers to your questions:\n\nI don’t expect this to affect gas fees for ordinary user transactions. I expect them to bid zero and get prompt inclusion just as they do now. It’s true that MEV extractors will pay more, but that’s part of the point of Timeboost, to internalize the value that MEV extractors are currently spending on technical “racing” outside of the protocol.\nUsers shouldn’t have to wait and re-try, because inclusion is guaranteed for all arriving transactions.\nI’m not too worried about parties trying to game the deterministic tie-breaking, because any gaming can be defeated by a competitor who bids just one wei more.\nThe protocol is designed to prevent anyone (other than the sequencer itself) from being able to see a transaction and then insert another transaction in front of it. This is because of the secret mempool. (Your question suggests a kind of “blind front-running” where someone guesses that a particular transaction will be sent and submits a transaction before it, in the hope that the guess was correct. I don’t think any sequencing protocol can prevent that.)\n\nMy current proposal is a modification to the existing centralized, trusted sequencer. So this would still require parties to trust that the sequencer itself is not engaging in front-running tactics. Offchain Labs recently announced a partnership with Espresso Systems to develop a decentralized version of Timeboost. Threshold decryption is definitely part of that discussion.\nIn principle one could add threshold decryption to the centralized version, but it would include a decentralized committee (to do the decryption), and to me it makes sense to work on a more comprehensively decentralized approach.\nAgain, thanks for asking the hard questions. I hope my answers have added clarity to the proposal.\n\n 11 days later\n\n post by sam.ng on Oct 11, 2023\n\n sam.ng\n\n Pleased to observe that an L2 is taking MEV/ordering policy into account. I have a couple of questions:\n\nWasn’t PGA something that was aimed to be avoided from the pre-PBS days on Ethereum? Doesn’t it introduce wasted computations?\n\nHave you considered a model where, over a year, sequencer operators are compensated with inflationary $ARB rewards for managing the sequencer? Concurrently, a substantial part of the sequencer’s revenues could be allocated for the burning of $ARB. This might result in the token experiencing net deflation by year-end. If we operate under the presumption of a steady market cap, it’s conceivable that the $ARB price would increase. This could be a possible strategy for the DAO, couldn’t it?\n\nDo you have any insights regarding the latency of this decentralized version of Timeboost? I assume maintaining low latency is critical from a user perspective.\n\n post by edfelten on Oct 11, 2023\n\n edfelten\n\n The problems with PGA on Ethereum happened because of the combination of PGA with a public mempool. Users would see other transactions in the mempool and change their behavior as a result. The Timeboost proposal would have a secret mempool, so these problems shouldn’t come up.\nOn your second question, of course the DAO can consider other models for paying the sequencer. There are some incentive alignment reasons to correlate sequencer payment with Timeboost revenue, but ultimately this is the DAO’s decision.\nWe’re still investigating the latency implications of decentralized Timeboost. That’s part of the research collaboration between Offchain Labs and Espresso Systems. I agree that latency is a very important consideration.\n\n 5 months later\n\n post by aPenzkofer on Feb 29, 2024\n\n aPenzkofer\n\n Thanks for this clear explanation on discrete timeboost.\nIt seems that the initial idea of explicit time boost has been removed in favour of a more simple priority gas auction within a slot that is purely defined by arrival times. I assume this is mainly to reduce latency? Are there any other factors that contributed to this transition?\nIt seems to make the scheme susceptible to the issue drawn here\n\nAn optional approach could be to reintroduce the original time boost with a different value g* << g where g* only accounts for the time boost to reach the previous block time slot. This could bring in the additional benefit of collecting value that would be otherwise lost to latency racing for this edge case. While only marginally increasing the latency by g* (as the sequencer would have to wait for this additional g* window to elapse).\n\n 4 months later\n\n post by parseb on Jun 13, 2024\n\n parseb\n\nI have skimmed through the various related posts and I ended up here by asking a question and not getting any answers on X and Warpcast. These discussions were mentioned in We Are All Building the Same Thing - Josh Bowen (Astria) talk.\nWhy not enforce transaction order by their tx hash value?\nIn my view, this would:\n\nguarantee two non-sandwichable slots.\ncome very handy for white hat operations.\nwould make parasitic MEV costly.\npush timing infrastructure loads at the edges\n\nExtra ordering rules can be added if needed.\nAn interesting one: demanding a min. or max. distance between txhashes based on block hash.\nFinally, it seems to be less costly and easier to implement.\nPlease someone tell me why this is stupid so I can cross a procrastination reason off my list. Tx.\n\n post by edfelten on Jun 13, 2024\n\n edfelten\n\n What would tx ordering by hash accomplish, that would not be accomplished by something easier to implement, like first-come, first-served ordering?\n\n post by parseb on Jun 14, 2024\n\n parseb\n\n First-Come-First-Serve (FCFS) ordering in blockchain networks is inherently subjective, challenging to prove, and only probabilistically enforceable. Can be used to negatively affect the interest of users.\nWhat I think is the case (I convinced ChetGPT):\n“By relying on the inherent randomness of transaction hashes for ordering, regular users do not need to expend additional computational resources. The increased difficulty and cost for attackers to manipulate transaction hashes reduce the likelihood and profitability of sandwich attacks, thereby mitigating toxic MEV to some extent. This approach leverages the uniform distribution of txHashes to provide a fairer and more secure transaction ordering mechanism.”\n\n post by 0xfust on Jun 17, 2024\n\n 0xfust\n\n Is there an explanation as to why it is no longer recommended by the research team?\n\n post by edfelten on Jun 17, 2024\n\n edfelten\n\n The current thinking is summarized here: The power of faster blocks - #6 by edfelten\nThe tl;dr is that the express-lane policy (first-come, first-served sequencing with an “express lane” that parties can bid for access to) is thought to better preserve the advantages of Arbitrum sequencing, namely fast block time and a fast arbitrage cycle to maintain efficiency of markets.\n\n post by 0xfust on Jun 18, 2024\n\n 0xfust\n\nOkay, but if I want to create an app-chain on the Arbitrum stack that captures LVR and MEV (with a centralized sequencer for the beginning), can I enable timeboost or priority ordering through customization?\n\n post by 0xfust on Jun 22, 2024\n\n 0xfust\n\n sorry - now totally understand the express lane model.\nThis is an efficient mechanism that is fully compatible with our LVR capture goals.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Time boost: a new transaction ordering policy proposal\n\n Uncategorized\n\n 34\n\n 9.8k\n\n Sep 2023\n\n Decentralized Timeboost Specification\n\n Uncategorized\n\n tx-ordering,sequencer\n\n 2\n\n 881\n\n Sep 2024\n\n FairFlow: Leveraging TimeBoost to Build a Fair and Transparent L2 MEV Economy\n\n Uncategorized\n\n tx-ordering\n\n 0\n\n 447\n\n Apr 2025\n\n MEV Capture Through Time-Advantaged Arbitrage\n\n Uncategorized\n\n 0\n\n 811\n\n Oct 2024\n\n The power of faster blocks\n\n Uncategorized\n\n 11\n\n 4.2k\n\n Sep 2024","tokens":3534,"squid":"spider-01","role":"Chain Spider","at":1791348116648,"hash":"988a1edf60d5b8547a158900b24b73944eaaa249"}
{"url":"https://mpl-bubblegum.typedoc.metaplex.com/types/_internal_.Program.html","domain":"mpl-bubblegum.typedoc.metaplex.com","title":"Program | @metaplex-foundation/mpl-bubblegum - v6.0.0","text":"@metaplex-foundation/mpl-bubblegum - v6.0.0\n<internal>\nProgram\nType alias Program\nProgram: {     getErrorFromCode: ((code: number, cause?: Error) => ProgramError | null);     getErrorFromName: ((name: string, cause?: Error) => ProgramError | null);     isOnCluster: ((cluster: Cluster) => boolean);     name: string;     publicKey: PublicKey; }\nDefines a Solana Program that can be\nregistered in Umi's program repository.\n\nType declaration\n\ngetErrorFromCode: ((code: number, cause?: Error) => ProgramError | null)\n\n(code: number, cause?: Error): ProgramError | null\n\nRetrieves a ProgramError from a given error code\nor null if the error code is not recognized.\n\nParameters\n\ncode: number\n\nOptional cause: Error\nReturns ProgramError | null\n\ngetErrorFromName: ((name: string, cause?: Error) => ProgramError | null)\n\n(name: string, cause?: Error): ProgramError | null\n\nRetrieves a ProgramError from a given error name\nor null if the error name is not recognized.\n\nParameters\n\nname: string\n\nOptional cause: Error\nReturns ProgramError | null\n\nisOnCluster: ((cluster: Cluster) => boolean)\n\n(cluster: Cluster): boolean\n\nA method that returns true if the program is available on the given cluster.\nIf the same program is available on multiple clusters but using different public keys,\nmultiple Program instances must be registered such that the isOnCluster method\nreturns true for the appropriate cluster.\n\nParameters\n\ncluster: Cluster\nReturns boolean\n\nname: string\nA unique name for the Program in camelCase.\nTo avoid conflict with other organizations, it is recommended\nto prefix the program name with a namespace that is unique to\nyour organization. For instance, Metaplex programs are prefixed\nwith mpl like so: mplTokenMetadata or mplCandyMachine.\n\npublicKey: PublicKey\nThe public key of the program.\n\n Settings\n\nMember Visibility\n\nThemeOSLightDark\n\nGenerated using TypeDoc","tokens":467,"squid":"dotcat","role":"Tooling Spider","at":1791348121810,"hash":"95621b26033e9c0a85e90d5384274957892c8180"}
{"url":"https://akash.network/docs/providers/architecture/bid-engine","domain":"akash.network","title":"Bid Engine Service | Akash Network - Your Guide to Decentralized Cloud","text":"Bid Engine Service The Bid Engine Service is responsible for monitoring the Akash blockchain for deployment orders, evaluating them against provider capabilities, and submitting competitive bids.\nArchitecture\n+----------------------------------------------+| Bid Engine Service || || +---------------------------------------+ || | Order Fetcher | || | - Queries chain for open orders | || | - Pages through results | || | - Handles catchup on restart | || +--------------+------------------------+ || | || v || +---------------------------------------+ || | Event Subscriber | || | - Listens for EventOrderCreated | || | - Receives real-time order events | || +--------------+------------------------+ || | || v || +---------------------------------------+ || | Order Manager (Map) | || | - orders map[orderID]*order | || | - Tracks active order processing | || +--------------+------------------------+ || | || v || +---------------------------------------+ || | Order Instance (per order) | || | - Order lifecycle FSM | || | - Resource matching | || | - Price calculation | || | - Bid submission | || +--------------+------------------------+ || | || v || +---------------------------------------+ || | Pricing Strategy | || | - Shell script pricing | || | - Scale-based pricing | || +---------------------------------------+ |+----------------------------------------------+\nService Initialization\nWhen the provider starts, the Bid Engine Service:\n\nSubscribes to Events - Connects to the event bus\nStarts Provider Attribute Service - Validates provider attributes\nLaunches Order Fetcher - Queries chain for existing open orders (catchup)\nWaits for Operators - Ensures hostname/inventory operators are ready\nBegins Processing - Starts handling orders and events\n\nCode Reference: /bidengine/service.go - NewService()\nOrder Processing\nOrder Discovery\nOrders are discovered in two ways:\n1. Real-Time Events (Primary)\ncase *mtypes.EventOrderCreated: key := mquery.OrderPath(ev.ID) order, err := newOrder(s, ev.ID, s.cfg, s.pass, false) s.orders[key] = order\n\nListens for EventOrderCreated events from the blockchain\nImmediately creates an order manager for the new order\nBegins bid evaluation process\n\n2. Catchup on Startup\nfunc (s *service) ordersFetcher(ctx context.Context, aqc sclient.QueryClient)\n\nQueries the blockchain for all open orders\nPaginates through results (1000 orders per page)\nCatches up on any orders created while provider was offline\nEnsures no orders are missed during restarts\n\nOrder Lifecycle\nEach order goes through a finite state machine:\n1. CREATED ↓2. EVALUATING ↓ (checks pass)3. BIDDING ↓4. BID_SUBMITTED ↓ (lease awarded or order closed)5. COMPLETE\nCode Reference: /bidengine/order.go - order.run()\nBid Evaluation\nWhen an order is detected, the bid engine evaluates:\n1. Provider Attributes Match\nfunc shouldBid(order Request, pattr apclient.Attributes) (bool, error)\nChecks:\n\nProvider attributes match order requirements\nGPU model/vendor matches (if GPU deployment)\nRegion/datacenter matches (if specified)\nFeature support (persistent storage, IP leases, etc.)\n\nExample Order Requirements:\n# SDL attributesprofiles: compute: gpu-profile: attributes: region: us-west capabilities/gpu/vendor/nvidia/model/rtx4090: true\n2. Resource Availability\ncluster.Reserve(order.OrderID, order.Resources)\nChecks:\n\nSufficient CPU available\nSufficient memory available\nSufficient storage available\nGPU units available (if GPU required)\nPersistent storage available (if requested)\n\nResource Reservation:\n\nResources are reserved (not allocated) when bidding\nPrevents overbidding on limited resources\nReservation is released if lease is not won\nReservation is converted to allocation when lease is won\n\n3. Price Calculation\nprice, err := s.config.BidPricingStrategy.CalculatePrice(ctx, req)\nTwo pricing strategies are supported:\nShell Script Pricing\nCustom pricing logic in price_script.sh:\n#!/bin/bash# Custom pricing logic# Input: JSON with order details# Output: Price in uact/block (ACT)\nCPU_PRICE=100MEMORY_PRICE=50STORAGE_PRICE=10\n# Calculate total price# ... pricing logic ...echo \"$TOTAL_PRICE\"\nAdvantages:\n\nMaximum flexibility\nCan integrate external pricing APIs\nDynamic pricing based on demand\nCan consider time of day, region, etc.\n\nScale-Based Pricing\nSimple multiplier-based pricing from provider.yaml:\nbidpricestoragescale: 1.0bidpricecpuscale: 1.0bidpricememoryscale: 1.0bidpriceendpointscale: 1.0bidpricescriptpath: \"\"\nCalculation:\nprice = (cpu_units * cpu_scale) + (memory_units * memory_scale) + (storage_units * storage_scale) + (endpoint_count * endpoint_scale)\nCode Reference: /bidengine/pricing.go\nBid Submission\nOnce evaluation passes, the bid is submitted:\nBid Components\nmessage MsgCreateBid { BidID bid_id = 1; cosmos.base.v1beta1.DecCoin price = 2; cosmos.base.v1beta1.Coin deposit = 3;}\nFields:\n\nbid_id - Unique identifier (order ID + provider address)\nprice - Bid price in uact per block (ACT)\ndeposit - Bid deposit in AKT (0.5 AKT / 500000 uakt)\n\nTransaction Broadcast\ntx := NewMsgCreateBid(order.OrderID, provider, price, deposit)response := txClient.BroadcastTx(tx)\nProcess:\n\nCreate signed transaction\nBroadcast to Akash blockchain\nWait for transaction confirmation\nHandle success or failure\n\nBid Timeout\nIf bid submission fails or times out:\ntimeout := s.cfg.BidTimeout // default: 5 minutes\n\nOrder manager waits for bid timeout duration\nIf bid not confirmed within timeout, order processing stops\nResources are unreserved\nOrder manager is removed from active orders\n\nProvider Attribute Validation\nThe bid engine includes a Provider Attribute Signature Service that validates provider attributes:\nSignature Verification\nfunc (s *providerAttrSignatureService) validate(attr apclient.Attributes)\nChecks:\n\nRequired attributes are present (host, tier)\nAttribute format is valid\nNo invalid or malformed attributes\nGPU attributes follow correct naming convention\n\nAutomatic Attribute Updates\nThe service monitors for attribute changes:\ncase ptypes.ProviderResourcesEvent: // Update provider attributes s.updateAttributes(event.Attributes)\nTriggers:\n\nProvider configuration changes\nGPU discovery updates\nFeature enablement (storage, IP leases)\n\nMonitoring & Metrics\nPrometheus Metrics\nvar ordersCounter = promauto.NewCounterVec(prometheus.CounterOpts{ Name: \"provider_order_handler\",}, []string{\"action\"})\nvar orderManagerGauge = promauto.NewGauge(prometheus.GaugeOpts{ Name: \"provider_order_manager\",})\nMetrics Exposed:\n\nprovider_order_handler{action=\"start\"} - Orders started\nprovider_order_handler{action=\"stop\"} - Orders completed\nprovider_order_manager - Active orders being processed\n\nStatus API\nfunc (s *service) Status(ctx context.Context) (*apclient.BidEngineStatus, error)\nReturns:\n{ \"orders\": 5 // number of active orders}\nQuery Status:\nTerminal windowgrpcurl -insecure provider.example.com:8444 \\ akash.provider.v1.ProviderRPC.GetStatus\nConfiguration\nBid Engine Config\ntype Config struct { PricingStrategy PricingStrategy Deposit sdk.Coin BidTimeout time.Duration Attributes []Attribute MaxGroupVolumes int}\nFrom provider.yaml:\n# Bid deposit (in AKT; provider puts this up when placing a bid)biddeposit: 500000uakt # 0.5 AKT\n# Bid timeoutbidtimeout: 5m\n# Pricing strategybidpricescriptpath: \"/path/to/price_script.sh\"# ORbidpricestoragescale: 1.0bidpricecpuscale: 1.0bidpricememoryscale: 1.0\n# Max volumes per deploymentmaxgroupvolumes: 20\n# Provider attributesattributes: - key: host value: akash - key: tier value: community\nError Handling\nThe bid engine handles various error scenarios:\nChain Query Failures\nif errors.Is(err, context.Canceled) { break}// Retry on transient errorscontinue\n\nRetries on network errors\nGraceful shutdown on context cancellation\nContinues processing other orders\n\nResource Reservation Failures\nif err := cluster.Reserve(order.OrderID, resources); err != nil { log.Error(\"resource reservation failed\", \"err\", err) return // Skip this order}\n\nSkip orders that exceed available resources\nLog reason for rejection\nContinue processing other orders\n\nBid Submission Failures\nif err := SubmitBid(tx); err != nil { log.Error(\"bid submission failed\", \"err\", err) cluster.Unreserve(order.OrderID) return}\n\nRelease reserved resources on failure\nLog error details\nRetry logic for transient failures\n\nAdvanced Features\nConcurrent Order Processing\nEach order is processed in its own goroutine:\norder, err := newOrder(s, orderID, s.cfg, s.pass, false)go order.run() // Concurrent execution\nBenefits:\n\nProcess multiple orders simultaneously\nDon’t block on slow order evaluation\nMaximize bidding throughput\n\nOperator Waiting\nBefore bidding, the service waits for operators:\nerr := s.waiter.WaitForAll(ctx)\nEnsures:\n\nHostname operator is ready\nInventory operator has discovered resources\nIP operator is available (if configured)\n\nPrevents:\n\nBidding before resource discovery complete\nIncorrect resource availability calculations\nMissing feature support\n\nRelated Documentation\n\nCluster Service - Resource management\nProvider Attributes - Attribute configuration\nProvider Installation - Pricing configuration\n\nEdit page on github\n Overview Cluster Service","tokens":2278,"squid":"spider-03","role":"Compute Spider","at":1791348131823,"hash":"d3f3a61052676618bfbe81cbdf001210fb7300e3"}
{"url":"https://forum.across.to/t/what-the-token-does/52/23","domain":"forum.across.to","title":"What the token does? - Tokenomics (old) - Across Protocol","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 read \n\n 4\n min\n\n Nov 2021\n\n 23 / 26\n\n Mar 2022\n\n Apr 2022\n\n Load more posts above\n\n post by fommes.eth on Nov 17, 2021\n\n post by fommes.eth on Nov 17, 2021\n\n post by Robot on Nov 17, 2021\n\n post by Sanguine on Nov 17, 2021\n\n post by jotatotal on Nov 17, 2021\n\n post by fommes.eth on Nov 17, 2021\n\n post by Robot on Nov 17, 2021\n\n post by Solace on Nov 17, 2021\n\n post by Sanguine on Nov 17, 2021\n\n post by eqing.eth on Nov 21, 2021\n\n post by Alisa on Nov 22, 2021\n\n 9 days later\n\n post by MrHeviDi on Dec 1, 2021\n\n 2 months later\n\n post by jotatotal on Jan 26, 2022\n\n post by lawpanda.eth on Jan 26, 2022\n\n 2 months later\n\n post by J.Berg on Mar 18, 2022\n\n J.Berg\n\n Creating a token enables the DAO to have an asset (without investing) that can be used to fund projects/guilds for effort the DAO needs (both maintenance and major initiatives), as well as contribute to internal DAO economics.\n–Paying core team members for their efforts\n–Paying for work done by Guilds and their squads\n–Internal DAO markets and trade\n–Bounties\nWill the Across token be used strictly for governance? or will it be used as money? or both?\nWould it be a monetary asset and a governance token to be used to fund and vote? Some DAO’s treat their governance token as ONLY that, and it actively drives down it’s valuation.\nIf its money then the DAO as an organization has the challenges of both a startup and an emerging digital nationstate in that we have to find and create revenue streams and manage costs, as well as drive the use and acceptance of our denomination both internally and externally.\nI think long term will be based on the size of the treasury it controls and the useful things you can do with it. As a result, I think the focus should be on activities that generate on-chain revenue for the DAO and ways to make the token useful stake it, collateral, ect.\nHow to pay contributors is definitely an important factor to consider. Without contributors, we won’t be able to do any of the above. Part of me feels that if your contributing, it should be because you believe in the DAO long term and shouldn’t expect an immediate monetary reward. The other part of me thinks that contributor renumeration is something that needs to be painstakingly thought out to retain talent and pay our people\n\n post by heybeo on Mar 22, 2022\n\n heybeo\n\n It would be nice to use bridges on the same platform as well as to create a nice dex.\nTrading pairs, for example acx-uma, are used as fees and distributed to token holders.\nacx-x\nacx-y\nacx-z\nJust a simple idea as liquidity addition commissions are burned\n\n post by altsilversurfer.nft on Mar 26, 2022\n\n altsilversurfer.nft\n\n Tokenomics can be viewed as a function of 3 main parameters, token launch (model, vesting scheme, market cap), utility, and inflation. Utility is one of the major drivers of adoption and appreciation of value. Thus, the more utilities, the best. Governance will be the first and more obvious utility of $ACX, but we must think beyond this to achieve sustainnability. This is the ultimate goal. And this is also the common interest of all involved. People that are waiting for profits will be maximally rewarded if they be patient and contribute to protocol sustainnability. Across will be really BIG and this is not a fanboy statement. The major crosschain pipes will see in the future typical value movements that will far exceed those of the biggest centralized exchanges today.\n\n post by jeffrey on Mar 29, 2022\n\n jeffrey\n\n Token is share, it means users own the project\n\n 12 days later\n\n post by hescollazo on Apr 11, 2022\n\n hescollazo\n\n I agree with the use of the token as a payment mechanism for the protocol. The low fees will bring new users and money into the ecosystem. That it can be used in governance will incentivize use of the application and hodling of the asset. Ultimately the goal should be to give users the tools to discover new ways in which to generate positive cash flow and build wealth.\n\n 10 days later\n\n post by Ray_V on Apr 21, 2022\n\n Ray_V\n\n Would we introduce a single staking mechanism? In which we would offer our tokens as liquidity to the across protocol and earn APR either through the fees accrued by the protocol - or another more effective system? Would that be something considered?\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Initial thinking around token distribution\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 36\n\n Mar 2022\n\n Across Token Launch Proposal\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 214\n\n May 2022\n\n Across Token Launch Proposal v2\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 47\n\n Nov 2022\n\n Second ACX Drop\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 15\n\n Feb 2024\n\n Welcome to Across\n\n WELCOME 👋\n\n WELCOME 👋\n\n Nov 2022","tokens":1210,"squid":"spider-09","role":"Bridge Spider","at":1791348137908,"hash":"c378d9b8e6baa14d484a11e29011bab29dec40c3"}
{"url":"https://research.arbitrum.io/t/proposed-design-for-timeboost/9491/13","domain":"research.arbitrum.io","title":"Proposed design for Timeboost - Uncategorized - Arbitrum Research","text":"Uncategorized\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 read \n\n 5\n min\n\n Sep 2023\n\n 13 / 13\n\n Jun 2024\n\n Jun 2024\n\n post by edfelten on Sep 27, 2023\n\n edfelten\n\n [Update (June 2024): This design is no longer recommended by the Offchain Labs research team. However, I’m leaving this post in place to preserve the record.]\nThe Offchain Labs research team has a specific proposed design in mind for adding Timeboost to the current centralized sequencer design. This would allow Arbitrum chains to prevent front-running, while capturing the value of benign MEV types like arbitrage.\nThe design has two parts: a change to the sequencer’s transaction ordering policy, and a new transaction type.\nThe sequencer’s ordering policy would go in rounds, with each round containing these steps:\n\nthe sequencer waits for a fixed period (tentatively: 0.5 seconds), collecting all transactions that arrive before the end of the period\nthe sequencer sorts the collected transactions into decreasing order by bid, breaking ties by a deterministic rule,\nthe sequencer builds a block from the sorted transaction list and emits that block into its output feed,\nthe round ends and the next round starts\n\nThe new transaction type is identical to a standard user-signed transaction, with the only differences being (1) a different transaction type label, and (2) how transaction fees are collected by the chain. For the new transaction type, the chain would collect the priority fee (“tip”) per gas unit as in Ethereum. (By contrast, standard transaction types don’t pay the priority fee on Arbitrum chains.) So the new transaction type would pay a gas price equal to the current Arbitrum-chain base fee plus the transaction’s priority fee.\nA transaction’s bid, for sorting purposes, is (1) its priority fee, if it is the new transaction type, or (2) zero, for other transaction types. So a transaction can get earlier placement within its block by paying a higher priority fee. This implements a sealed-bid, all-pay, priority gas auction for position within the block.\nIn this design, the sequencer does not collect any “MEV fees”. Instead, transactions bid for position by offering to pay a priority fee for each gas unit they use. The resulting fees are collected by the chain, as part of its normal gas fee collection mechanism.\nThe priority fees would be collected by the chain and paid to an address specified by chain governance. In the case of DAO-governed chains, this address would be specified by the DAO.\nFor most chains, the fees would be paid to a smart contract which would split up the fee revenue as specified by chain governance. Most likely this would mean the largest share of priority fee revenue would go to the chain owner (e.g., the DAO) with perhaps a small slice going to the sequencer operator(s).\nI gave a more detailed talk about this design and why I think it makes sense, at the Stanford MEV Workshop. Video is available here.\n(One obvious design alternative is to not introduce a new transaction type, and just use the existing transaction type, which already has a priority fee field. The alternative would involve collecting the priority fee for existing transactions, which would be a change from the current policy of ignoring the priority fee field and treating all transactions as if they submitted a priority fee of zero.\nThe drawback of this alternative is many current transactions include a priority fee, typically a few gwei, because that is the default in some wallets–so that collecting the priority fee would cause many users to inadvertently pay much more for gas (adding, say, a 2 gwei tip on top of the 0.1 gwei base fee, a 21x increase in fee). By creating a new transaction type, and continuing to treat all legacy transaction types as having priority fee zero, we would protect users from this issue.)\n\n Time boost: a new transaction ordering policy proposal\n\n 5\n\n 3\n\n 2\n\n read \n\n 5\n min\n\n post by haaroon on Sep 29, 2023\n\n haaroon\n\n Thanks Ed for the detailed write up, but I can’t help but wonder what will happen to fees. L2s are supposed to be cheap, how does this\n\nAffect Gas price inflation: surely during peak times it will be very costly to do a simple transaction?\nThis causes an inequality as users who can’t afford to pay simply have to wait and continue trying, favouring users who have the gas to burn?\ndeterministic rule tie breaking - doesn’t this incentivise bad actors to try and manipulate this?\nfront running is still possible no, you just pay the highest fee and probabilistically determine how high you will be up (probabilistic ordering is being talked about now in the dark circles)\n\nHave you looked into potentially adding in threshold security that encrypts transaction at submission, only to be decrypted by a decentralised committee after the consensus layer, should prevent people from exploiting pending txs. From [2205.08529] F3B: A Low-Overhead Blockchain Architecture with Per-Transaction Front-Running Protection\nThanks\n\n post by edfelten on Sep 30, 2023\n\n edfelten\n\n Thanks for your questions and suggestion on threshold decryption.\nImportantly, the bidders in timeboost are not contending for inclusions–every transaction that arrives by the deadline will be included in the block. They are only contending for ordering within the block. Unlike Ethereum, Arbitrum does not have an in-protocol limit on the number of txs that can run in some period of time. (The only real limit is the rate at which the sequencer can handle incoming RPCs, which is the same in the currrent system.)\nAlso, this design maintains the “secret mempool” feature of Arbitrum sequencing, so it will not be possible for external parties to see transactions and then outbid them. If a transaction arrives before some block’s deadline, it will be included in that block, and the block contents won’t be published until after the deadline–so by the time a transaction becomes visible to anyone (other than the sequencer itself), it will be too late to front-run it.\nI would expect ordinary user txs to bid zero, because they will still be guaranteed mempool secrecy and prompt inclusion even with a zero bid. So I don’t think this will affect the gas fees paid by ordinary transactions.\nWith that background, here are answers to your questions:\n\nI don’t expect this to affect gas fees for ordinary user transactions. I expect them to bid zero and get prompt inclusion just as they do now. It’s true that MEV extractors will pay more, but that’s part of the point of Timeboost, to internalize the value that MEV extractors are currently spending on technical “racing” outside of the protocol.\nUsers shouldn’t have to wait and re-try, because inclusion is guaranteed for all arriving transactions.\nI’m not too worried about parties trying to game the deterministic tie-breaking, because any gaming can be defeated by a competitor who bids just one wei more.\nThe protocol is designed to prevent anyone (other than the sequencer itself) from being able to see a transaction and then insert another transaction in front of it. This is because of the secret mempool. (Your question suggests a kind of “blind front-running” where someone guesses that a particular transaction will be sent and submits a transaction before it, in the hope that the guess was correct. I don’t think any sequencing protocol can prevent that.)\n\nMy current proposal is a modification to the existing centralized, trusted sequencer. So this would still require parties to trust that the sequencer itself is not engaging in front-running tactics. Offchain Labs recently announced a partnership with Espresso Systems to develop a decentralized version of Timeboost. Threshold decryption is definitely part of that discussion.\nIn principle one could add threshold decryption to the centralized version, but it would include a decentralized committee (to do the decryption), and to me it makes sense to work on a more comprehensively decentralized approach.\nAgain, thanks for asking the hard questions. I hope my answers have added clarity to the proposal.\n\n 11 days later\n\n post by sam.ng on Oct 11, 2023\n\n sam.ng\n\n Pleased to observe that an L2 is taking MEV/ordering policy into account. I have a couple of questions:\n\nWasn’t PGA something that was aimed to be avoided from the pre-PBS days on Ethereum? Doesn’t it introduce wasted computations?\n\nHave you considered a model where, over a year, sequencer operators are compensated with inflationary $ARB rewards for managing the sequencer? Concurrently, a substantial part of the sequencer’s revenues could be allocated for the burning of $ARB. This might result in the token experiencing net deflation by year-end. If we operate under the presumption of a steady market cap, it’s conceivable that the $ARB price would increase. This could be a possible strategy for the DAO, couldn’t it?\n\nDo you have any insights regarding the latency of this decentralized version of Timeboost? I assume maintaining low latency is critical from a user perspective.\n\n post by edfelten on Oct 11, 2023\n\n edfelten\n\n The problems with PGA on Ethereum happened because of the combination of PGA with a public mempool. Users would see other transactions in the mempool and change their behavior as a result. The Timeboost proposal would have a secret mempool, so these problems shouldn’t come up.\nOn your second question, of course the DAO can consider other models for paying the sequencer. There are some incentive alignment reasons to correlate sequencer payment with Timeboost revenue, but ultimately this is the DAO’s decision.\nWe’re still investigating the latency implications of decentralized Timeboost. That’s part of the research collaboration between Offchain Labs and Espresso Systems. I agree that latency is a very important consideration.\n\n 5 months later\n\n post by aPenzkofer on Feb 29, 2024\n\n aPenzkofer\n\n Thanks for this clear explanation on discrete timeboost.\nIt seems that the initial idea of explicit time boost has been removed in favour of a more simple priority gas auction within a slot that is purely defined by arrival times. I assume this is mainly to reduce latency? Are there any other factors that contributed to this transition?\nIt seems to make the scheme susceptible to the issue drawn here\n\nAn optional approach could be to reintroduce the original time boost with a different value g* << g where g* only accounts for the time boost to reach the previous block time slot. This could bring in the additional benefit of collecting value that would be otherwise lost to latency racing for this edge case. While only marginally increasing the latency by g* (as the sequencer would have to wait for this additional g* window to elapse).\n\n 4 months later\n\n post by parseb on Jun 13, 2024\n\n parseb\n\nI have skimmed through the various related posts and I ended up here by asking a question and not getting any answers on X and Warpcast. These discussions were mentioned in We Are All Building the Same Thing - Josh Bowen (Astria) talk.\nWhy not enforce transaction order by their tx hash value?\nIn my view, this would:\n\nguarantee two non-sandwichable slots.\ncome very handy for white hat operations.\nwould make parasitic MEV costly.\npush timing infrastructure loads at the edges\n\nExtra ordering rules can be added if needed.\nAn interesting one: demanding a min. or max. distance between txhashes based on block hash.\nFinally, it seems to be less costly and easier to implement.\nPlease someone tell me why this is stupid so I can cross a procrastination reason off my list. Tx.\n\n post by edfelten on Jun 13, 2024\n\n edfelten\n\n What would tx ordering by hash accomplish, that would not be accomplished by something easier to implement, like first-come, first-served ordering?\n\n post by parseb on Jun 14, 2024\n\n parseb\n\n First-Come-First-Serve (FCFS) ordering in blockchain networks is inherently subjective, challenging to prove, and only probabilistically enforceable. Can be used to negatively affect the interest of users.\nWhat I think is the case (I convinced ChetGPT):\n“By relying on the inherent randomness of transaction hashes for ordering, regular users do not need to expend additional computational resources. The increased difficulty and cost for attackers to manipulate transaction hashes reduce the likelihood and profitability of sandwich attacks, thereby mitigating toxic MEV to some extent. This approach leverages the uniform distribution of txHashes to provide a fairer and more secure transaction ordering mechanism.”\n\n post by 0xfust on Jun 17, 2024\n\n 0xfust\n\n Is there an explanation as to why it is no longer recommended by the research team?\n\n post by edfelten on Jun 17, 2024\n\n edfelten\n\n The current thinking is summarized here: The power of faster blocks - #6 by edfelten\nThe tl;dr is that the express-lane policy (first-come, first-served sequencing with an “express lane” that parties can bid for access to) is thought to better preserve the advantages of Arbitrum sequencing, namely fast block time and a fast arbitrage cycle to maintain efficiency of markets.\n\n post by 0xfust on Jun 18, 2024\n\n 0xfust\n\nOkay, but if I want to create an app-chain on the Arbitrum stack that captures LVR and MEV (with a centralized sequencer for the beginning), can I enable timeboost or priority ordering through customization?\n\n post by 0xfust on Jun 22, 2024\n\n 0xfust\n\n sorry - now totally understand the express lane model.\nThis is an efficient mechanism that is fully compatible with our LVR capture goals.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Time boost: a new transaction ordering policy proposal\n\n Uncategorized\n\n 34\n\n 9.8k\n\n Sep 2023\n\n Decentralized Timeboost Specification\n\n Uncategorized\n\n tx-ordering,sequencer\n\n 2\n\n 881\n\n Sep 2024\n\n FairFlow: Leveraging TimeBoost to Build a Fair and Transparent L2 MEV Economy\n\n Uncategorized\n\n tx-ordering\n\n 0\n\n 447\n\n Apr 2025\n\n MEV Capture Through Time-Advantaged Arbitrage\n\n Uncategorized\n\n 0\n\n 811\n\n Oct 2024\n\n The power of faster blocks\n\n Uncategorized\n\n 11\n\n 4.2k\n\n Sep 2024","tokens":3526,"squid":"spider-01","role":"Chain Spider","at":1791348138177,"hash":"cd208080304c516b6b14e279949d309f366a0024"}
{"url":"https://forum.across.to/t/what-the-token-does/52/14","domain":"forum.across.to","title":"What the token does? - Tokenomics (old) - Across Protocol","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 read \n\n 4\n min\n\n Nov 2021\n\n 14 / 26\n\n Nov 2021\n\n Apr 2022\n\n Load more posts above\n\n post by fommes.eth on Nov 17, 2021\n\n post by fommes.eth on Nov 17, 2021\n\n post by Robot on Nov 17, 2021\n\n post by Sanguine on Nov 17, 2021\n\n Sanguine\n\n Kastormagic\n\n I think that token is needed for the DAO in the first place. It is not even necessary that it have economic value in the form of receiving % from commissions for the interaction of other users with the protocol. First of all, a token is a symbol. The more successful the project is, the more people want to be involved in it through the token.\n\n post by jotatotal on Nov 17, 2021\n\n jotatotal\n\n I would suggest that a part of the fees goes to the DAO treasury, and so increment value of DAO token. On the other hand I also consider that if the token is used to pay fees those fees get burned after that.\n\n post by fommes.eth on Nov 17, 2021\n\n fommes.eth\n\n Robot\n\n There are lots of L2 to L2 bridges already. Imho Across is unique in that sense and should aim to be the Go-To for fast+secure L1 withdrawals. There will always be a need for L1 withdrawals, even if Ethereum becomes mostly just an execution layer.\n\n post by Robot on Nov 17, 2021\n\n Robot\n\n Sanguine\n\n That’s not true go look at Ribbon finance and their token launch people bought and it non-stop gets called a useless govenunce token, Ribbon is very successful with about $200m TVL but the token price don’t reflect that\n\n post by Solace on Nov 17, 2021\n\n Solace\n\n Completely agree with /u/fojo’s post above - this is an important discussion regarding the token launch.\nWould the token be used strictly for governance, to pay out fees, or as a safety module? These do not necessarily have to mutually exclusive, and it’s possible that the token could incorporate all three - but as far as emission and distribution goes, it’s pretty important to make at least one a priority.\nIf choosing a governance route, liquidity incentives and a safety module could also be implemented at a later stage via a proposal. But this would remain subject to a vote, which could take some time to pass.\nOn the topic of liquidity incentives, these will likely remain temporary in order to bootstrap liquidity though there are plenty of examples of where artificially incentivizing usage has led to users with short-term outlooks farming these pools and draining the liquidity afterwards.\nAs far as using the token to incentivize usage goes, one approach could be to provide a gas fee rebate to users that bridge from L1 → L2 using the Arbitrum/optimism native bridge and bridge back to L1 using Across. This could be implemented similarly to Balancer’s gas fee rebate: [Proposal] Balancer Exchange Gas Reimbursement - Proposals - Balancer\nWe could get creative with some ways in order to incentivize usage rather than only incentivizing the LPs (as they will receive a fee of the transaction either way).\n\n post by Sanguine on Nov 17, 2021\n\n Sanguine\n\n Robot\n\n Maybe so. Indeed, in our time, the success of the project for the crowd is the endless rise in the price of the token. And if the price of a token does not grow infinitely, then they begin to call it “useless governance token”. But if the project starts to hype and the price rises, then it abruptly turns into an “incredibly useful governance token”.\n\n post by eqing.eth on Nov 21, 2021\n\n eqing.eth\n\n Kastormagic\n\n Tokens will attract some early users, which is necessary!At the initial stage of the project, it is necessary to attract users by token airdrop and distinguish real users.\n\n post by Alisa on Nov 22, 2021\n\n Alisa\n\n Acrosit is to establish a Dao and become a token of community governance. However, empowering and offsetting gas is a good suggestion, which can prevent members from throwing it out too early. However, it also has some disadvantages., if it is a gas, will it affect the development of community autonomy? But if it is only from the perspective of token, the more successful across is, the better the development of Dao will be, Of course, it will attract more people to participate\n\n 9 days later\n\n post by MrHeviDi on Dec 1, 2021\n\n 2 months later\n\n post by jotatotal on Jan 26, 2022\n\n post by lawpanda.eth on Jan 26, 2022\n\n 2 months later\n\n post by J.Berg on Mar 18, 2022\n\n post by heybeo on Mar 22, 2022\n\n post by altsilversurfer.nft on Mar 26, 2022\n\n post by jeffrey on Mar 29, 2022\n\n 12 days later\n\n post by hescollazo on Apr 11, 2022\n\n 10 days later\n\n post by Ray_V on Apr 21, 2022\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Initial thinking around token distribution\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 36\n\n Mar 2022\n\n Across Token Launch Proposal\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 214\n\n May 2022\n\n Across Token Launch Proposal v2\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 47\n\n Nov 2022\n\n Second ACX Drop\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 15\n\n Feb 2024\n\n Welcome to Across\n\n WELCOME 👋\n\n WELCOME 👋\n\n Nov 2022","tokens":1259,"squid":"spider-09","role":"Bridge Spider","at":1791348148026,"hash":"fd25db9fad0937beb48bc686e1e2c09c1760063c"}
{"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 3d 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 3 days 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 3d\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":"spider-07","role":"Council Spider","at":1791348153000,"hash":"acfc908ac435da1136d2f136376c8d1f1b63bede"}
{"url":"https://akash.network/docs/node-operators/getting-started/","domain":"akash.network","title":"Getting Started | Akash Network Documentation","text":"Getting Started Start running an Akash node or validator \nChoose Your Path\n Full Node Interact with the blockchain, run your own RPC/API endpoints Requirements: • CPU: 4-8 cores• Memory: 16-32 GB RAM• Storage: 512 GB SSD (1 TB+ recommended)• No AKT required Node Build Guides → Validator Secure the network and earn staking rewards Requirements: • CPU: 8+ cores (16 recommended)• Memory: 128 GB RAM• Storage: 1 TB NVMe SSD• Uptime: 99.9%+ (slashing for downtime)• AKT: 10,000+ recommended Running a Validator → \nNode Build Methods\n CLI Build Build and run your node with command-line tools Helm Chart Deploy your node on Kubernetes with Helm Omnibus All-in-one deployment with Omnibus scripts \nAdditional Resources\n Network Upgrades Mainnet 15 upgrade guide and procedures Architecture Node architecture and API endpoints TMKMS Secure your validator keys with TMKMS \nActive Validator Set\n Current Size: 100\n validators\n\nTo join the active set, you need more voting power than the 100th\n validator.\n Check Requirements: → Discord: $votingpower in #validator-alerts → Explorers: Mintscan | ATOMScan | Arcturian Tech | Valopers \nNeed Help?\n Discord - #validators channel GitHub - Node repository","tokens":298,"squid":"spider-03","role":"Compute Spider","at":1791348155173,"hash":"38677fd3e5815effd07808c8c120e7d103ad6862"}
{"url":"https://forum.across.to/t/what-the-token-does/52/16","domain":"forum.across.to","title":"What the token does? - Tokenomics (old) - Across Protocol","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 read \n\n 4\n min\n\n Nov 2021\n\n 16 / 26\n\n Nov 2021\n\n Apr 2022\n\n Load more posts above\n\n post by fommes.eth on Nov 17, 2021\n\n fommes.eth\n\n Imho there is no point in holding the Across token for fees reduction. I imagine a tipical Across user will not bridge all the time, just looking at the general roadmap/POV that Eth mainnet is becoming solely/mostly just the settlement layer, already in the coming months ppl will use more frequent L2s and withdraw back sometimes.\n\n post by fommes.eth on Nov 17, 2021\n\n fommes.eth\n\n I propose the Across token to accrue fees for holders instead.\n\n post by Robot on Nov 17, 2021\n\n Robot\n\n fommes.eth\n\n Surely the more utility the better and i’m sure Across will have to go L2 to L2 in the end\n\n post by Sanguine on Nov 17, 2021\n\n Sanguine\n\n Kastormagic\n\n I think that token is needed for the DAO in the first place. It is not even necessary that it have economic value in the form of receiving % from commissions for the interaction of other users with the protocol. First of all, a token is a symbol. The more successful the project is, the more people want to be involved in it through the token.\n\n post by jotatotal on Nov 17, 2021\n\n jotatotal\n\n I would suggest that a part of the fees goes to the DAO treasury, and so increment value of DAO token. On the other hand I also consider that if the token is used to pay fees those fees get burned after that.\n\n post by fommes.eth on Nov 17, 2021\n\n fommes.eth\n\n Robot\n\n There are lots of L2 to L2 bridges already. Imho Across is unique in that sense and should aim to be the Go-To for fast+secure L1 withdrawals. There will always be a need for L1 withdrawals, even if Ethereum becomes mostly just an execution layer.\n\n post by Robot on Nov 17, 2021\n\n Robot\n\n Sanguine\n\n That’s not true go look at Ribbon finance and their token launch people bought and it non-stop gets called a useless govenunce token, Ribbon is very successful with about $200m TVL but the token price don’t reflect that\n\n post by Solace on Nov 17, 2021\n\n Solace\n\n Completely agree with /u/fojo’s post above - this is an important discussion regarding the token launch.\nWould the token be used strictly for governance, to pay out fees, or as a safety module? These do not necessarily have to mutually exclusive, and it’s possible that the token could incorporate all three - but as far as emission and distribution goes, it’s pretty important to make at least one a priority.\nIf choosing a governance route, liquidity incentives and a safety module could also be implemented at a later stage via a proposal. But this would remain subject to a vote, which could take some time to pass.\nOn the topic of liquidity incentives, these will likely remain temporary in order to bootstrap liquidity though there are plenty of examples of where artificially incentivizing usage has led to users with short-term outlooks farming these pools and draining the liquidity afterwards.\nAs far as using the token to incentivize usage goes, one approach could be to provide a gas fee rebate to users that bridge from L1 → L2 using the Arbitrum/optimism native bridge and bridge back to L1 using Across. This could be implemented similarly to Balancer’s gas fee rebate: [Proposal] Balancer Exchange Gas Reimbursement - Proposals - Balancer\nWe could get creative with some ways in order to incentivize usage rather than only incentivizing the LPs (as they will receive a fee of the transaction either way).\n\n post by Sanguine on Nov 17, 2021\n\n Sanguine\n\n Robot\n\n Maybe so. Indeed, in our time, the success of the project for the crowd is the endless rise in the price of the token. And if the price of a token does not grow infinitely, then they begin to call it “useless governance token”. But if the project starts to hype and the price rises, then it abruptly turns into an “incredibly useful governance token”.\n\n post by eqing.eth on Nov 21, 2021\n\n eqing.eth\n\n Kastormagic\n\n Tokens will attract some early users, which is necessary!At the initial stage of the project, it is necessary to attract users by token airdrop and distinguish real users.\n\n post by Alisa on Nov 22, 2021\n\n Alisa\n\n Acrosit is to establish a Dao and become a token of community governance. However, empowering and offsetting gas is a good suggestion, which can prevent members from throwing it out too early. However, it also has some disadvantages., if it is a gas, will it affect the development of community autonomy? But if it is only from the perspective of token, the more successful across is, the better the development of Dao will be, Of course, it will attract more people to participate\n\n 9 days later\n\n post by MrHeviDi on Dec 1, 2021\n\n MrHeviDi\n\n fommes.eth\n\n But there will be other protocals/bridges to move funds from L2 to L1, so Across needs to atract users to use Across and maybe to hold Across token. Maybe, like someone before montioned, having Across token will give you some fee reduction or something like that.\n\n 2 months later\n\n post by jotatotal on Jan 26, 2022\n\n jotatotal\n\n Solace\n\n What about giving the holders of the token , despite a fee reduction , a share of the fee according to their holdings?\n\n post by lawpanda.eth on Jan 26, 2022\n\n lawpanda.eth\n\n That would functionally be an ‘x’ token, like xSushi, dQuick, etc. On the legal end it creates regulatory questions because it resembles a security. But it is a more functional mechanism for facilitating adoption/use.\n\n 2 months later\n\n post by J.Berg on Mar 18, 2022\n\n J.Berg\n\n Creating a token enables the DAO to have an asset (without investing) that can be used to fund projects/guilds for effort the DAO needs (both maintenance and major initiatives), as well as contribute to internal DAO economics.\n–Paying core team members for their efforts\n–Paying for work done by Guilds and their squads\n–Internal DAO markets and trade\n–Bounties\nWill the Across token be used strictly for governance? or will it be used as money? or both?\nWould it be a monetary asset and a governance token to be used to fund and vote? Some DAO’s treat their governance token as ONLY that, and it actively drives down it’s valuation.\nIf its money then the DAO as an organization has the challenges of both a startup and an emerging digital nationstate in that we have to find and create revenue streams and manage costs, as well as drive the use and acceptance of our denomination both internally and externally.\nI think long term will be based on the size of the treasury it controls and the useful things you can do with it. As a result, I think the focus should be on activities that generate on-chain revenue for the DAO and ways to make the token useful stake it, collateral, ect.\nHow to pay contributors is definitely an important factor to consider. Without contributors, we won’t be able to do any of the above. Part of me feels that if your contributing, it should be because you believe in the DAO long term and shouldn’t expect an immediate monetary reward. The other part of me thinks that contributor renumeration is something that needs to be painstakingly thought out to retain talent and pay our people\n\n post by heybeo on Mar 22, 2022\n\n heybeo\n\n It would be nice to use bridges on the same platform as well as to create a nice dex.\nTrading pairs, for example acx-uma, are used as fees and distributed to token holders.\nacx-x\nacx-y\nacx-z\nJust a simple idea as liquidity addition commissions are burned\n\n post by altsilversurfer.nft on Mar 26, 2022\n\n altsilversurfer.nft\n\n Tokenomics can be viewed as a function of 3 main parameters, token launch (model, vesting scheme, market cap), utility, and inflation. Utility is one of the major drivers of adoption and appreciation of value. Thus, the more utilities, the best. Governance will be the first and more obvious utility of $ACX, but we must think beyond this to achieve sustainnability. This is the ultimate goal. And this is also the common interest of all involved. People that are waiting for profits will be maximally rewarded if they be patient and contribute to protocol sustainnability. Across will be really BIG and this is not a fanboy statement. The major crosschain pipes will see in the future typical value movements that will far exceed those of the biggest centralized exchanges today.\n\n post by jeffrey on Mar 29, 2022\n\n jeffrey\n\n Token is share, it means users own the project\n\n 12 days later\n\n post by hescollazo on Apr 11, 2022\n\n hescollazo\n\n I agree with the use of the token as a payment mechanism for the protocol. The low fees will bring new users and money into the ecosystem. That it can be used in governance will incentivize use of the application and hodling of the asset. Ultimately the goal should be to give users the tools to discover new ways in which to generate positive cash flow and build wealth.\n\n 10 days later\n\n post by Ray_V on Apr 21, 2022\n\n Ray_V\n\n Would we introduce a single staking mechanism? In which we would offer our tokens as liquidity to the across protocol and earn APR either through the fees accrued by the protocol - or another more effective system? Would that be something considered?\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Initial thinking around token distribution\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 36\n\n Mar 2022\n\n Across Token Launch Proposal\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 214\n\n May 2022\n\n Across Token Launch Proposal v2\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 47\n\n Nov 2022\n\n Second ACX Drop\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 15\n\n Feb 2024\n\n Welcome to Across\n\n WELCOME 👋\n\n WELCOME 👋\n\n Nov 2022","tokens":2413,"squid":"spider-09","role":"Bridge Spider","at":1791348158225,"hash":"597ff84954b4b2e59180b5d209fdaa351397c9aa"}
{"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 76\n\n 23h\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 172\n\n 14d\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 107\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.9k\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":"spider-07","role":"Council Spider","at":1791348163113,"hash":"325170824a6298b48b8d88ed03bf8bff0aadf325"}
{"url":"https://forum.across.to/t/what-the-token-does/52/18","domain":"forum.across.to","title":"What the token does? - Tokenomics (old) - Across Protocol","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 read \n\n 4\n min\n\n Nov 2021\n\n 18 / 26\n\n Dec 2021\n\n Apr 2022\n\n Load more posts above\n\n post by fommes.eth on Nov 17, 2021\n\n fommes.eth\n\n Imho there is no point in holding the Across token for fees reduction. I imagine a tipical Across user will not bridge all the time, just looking at the general roadmap/POV that Eth mainnet is becoming solely/mostly just the settlement layer, already in the coming months ppl will use more frequent L2s and withdraw back sometimes.\n\n post by fommes.eth on Nov 17, 2021\n\n fommes.eth\n\n I propose the Across token to accrue fees for holders instead.\n\n post by Robot on Nov 17, 2021\n\n Robot\n\n fommes.eth\n\n Surely the more utility the better and i’m sure Across will have to go L2 to L2 in the end\n\n post by Sanguine on Nov 17, 2021\n\n Sanguine\n\n Kastormagic\n\n I think that token is needed for the DAO in the first place. It is not even necessary that it have economic value in the form of receiving % from commissions for the interaction of other users with the protocol. First of all, a token is a symbol. The more successful the project is, the more people want to be involved in it through the token.\n\n post by jotatotal on Nov 17, 2021\n\n jotatotal\n\n I would suggest that a part of the fees goes to the DAO treasury, and so increment value of DAO token. On the other hand I also consider that if the token is used to pay fees those fees get burned after that.\n\n post by fommes.eth on Nov 17, 2021\n\n fommes.eth\n\n Robot\n\n There are lots of L2 to L2 bridges already. Imho Across is unique in that sense and should aim to be the Go-To for fast+secure L1 withdrawals. There will always be a need for L1 withdrawals, even if Ethereum becomes mostly just an execution layer.\n\n post by Robot on Nov 17, 2021\n\n Robot\n\n Sanguine\n\n That’s not true go look at Ribbon finance and their token launch people bought and it non-stop gets called a useless govenunce token, Ribbon is very successful with about $200m TVL but the token price don’t reflect that\n\n post by Solace on Nov 17, 2021\n\n Solace\n\n Completely agree with /u/fojo’s post above - this is an important discussion regarding the token launch.\nWould the token be used strictly for governance, to pay out fees, or as a safety module? These do not necessarily have to mutually exclusive, and it’s possible that the token could incorporate all three - but as far as emission and distribution goes, it’s pretty important to make at least one a priority.\nIf choosing a governance route, liquidity incentives and a safety module could also be implemented at a later stage via a proposal. But this would remain subject to a vote, which could take some time to pass.\nOn the topic of liquidity incentives, these will likely remain temporary in order to bootstrap liquidity though there are plenty of examples of where artificially incentivizing usage has led to users with short-term outlooks farming these pools and draining the liquidity afterwards.\nAs far as using the token to incentivize usage goes, one approach could be to provide a gas fee rebate to users that bridge from L1 → L2 using the Arbitrum/optimism native bridge and bridge back to L1 using Across. This could be implemented similarly to Balancer’s gas fee rebate: [Proposal] Balancer Exchange Gas Reimbursement - Proposals - Balancer\nWe could get creative with some ways in order to incentivize usage rather than only incentivizing the LPs (as they will receive a fee of the transaction either way).\n\n post by Sanguine on Nov 17, 2021\n\n Sanguine\n\n Robot\n\n Maybe so. Indeed, in our time, the success of the project for the crowd is the endless rise in the price of the token. And if the price of a token does not grow infinitely, then they begin to call it “useless governance token”. But if the project starts to hype and the price rises, then it abruptly turns into an “incredibly useful governance token”.\n\n post by eqing.eth on Nov 21, 2021\n\n eqing.eth\n\n Kastormagic\n\n Tokens will attract some early users, which is necessary!At the initial stage of the project, it is necessary to attract users by token airdrop and distinguish real users.\n\n post by Alisa on Nov 22, 2021\n\n Alisa\n\n Acrosit is to establish a Dao and become a token of community governance. However, empowering and offsetting gas is a good suggestion, which can prevent members from throwing it out too early. However, it also has some disadvantages., if it is a gas, will it affect the development of community autonomy? But if it is only from the perspective of token, the more successful across is, the better the development of Dao will be, Of course, it will attract more people to participate\n\n 9 days later\n\n post by MrHeviDi on Dec 1, 2021\n\n MrHeviDi\n\n fommes.eth\n\n But there will be other protocals/bridges to move funds from L2 to L1, so Across needs to atract users to use Across and maybe to hold Across token. Maybe, like someone before montioned, having Across token will give you some fee reduction or something like that.\n\n 2 months later\n\n post by jotatotal on Jan 26, 2022\n\n jotatotal\n\n Solace\n\n What about giving the holders of the token , despite a fee reduction , a share of the fee according to their holdings?\n\n post by lawpanda.eth on Jan 26, 2022\n\n lawpanda.eth\n\n That would functionally be an ‘x’ token, like xSushi, dQuick, etc. On the legal end it creates regulatory questions because it resembles a security. But it is a more functional mechanism for facilitating adoption/use.\n\n 2 months later\n\n post by J.Berg on Mar 18, 2022\n\n J.Berg\n\n Creating a token enables the DAO to have an asset (without investing) that can be used to fund projects/guilds for effort the DAO needs (both maintenance and major initiatives), as well as contribute to internal DAO economics.\n–Paying core team members for their efforts\n–Paying for work done by Guilds and their squads\n–Internal DAO markets and trade\n–Bounties\nWill the Across token be used strictly for governance? or will it be used as money? or both?\nWould it be a monetary asset and a governance token to be used to fund and vote? Some DAO’s treat their governance token as ONLY that, and it actively drives down it’s valuation.\nIf its money then the DAO as an organization has the challenges of both a startup and an emerging digital nationstate in that we have to find and create revenue streams and manage costs, as well as drive the use and acceptance of our denomination both internally and externally.\nI think long term will be based on the size of the treasury it controls and the useful things you can do with it. As a result, I think the focus should be on activities that generate on-chain revenue for the DAO and ways to make the token useful stake it, collateral, ect.\nHow to pay contributors is definitely an important factor to consider. Without contributors, we won’t be able to do any of the above. Part of me feels that if your contributing, it should be because you believe in the DAO long term and shouldn’t expect an immediate monetary reward. The other part of me thinks that contributor renumeration is something that needs to be painstakingly thought out to retain talent and pay our people\n\n post by heybeo on Mar 22, 2022\n\n heybeo\n\n It would be nice to use bridges on the same platform as well as to create a nice dex.\nTrading pairs, for example acx-uma, are used as fees and distributed to token holders.\nacx-x\nacx-y\nacx-z\nJust a simple idea as liquidity addition commissions are burned\n\n post by altsilversurfer.nft on Mar 26, 2022\n\n altsilversurfer.nft\n\n Tokenomics can be viewed as a function of 3 main parameters, token launch (model, vesting scheme, market cap), utility, and inflation. Utility is one of the major drivers of adoption and appreciation of value. Thus, the more utilities, the best. Governance will be the first and more obvious utility of $ACX, but we must think beyond this to achieve sustainnability. This is the ultimate goal. And this is also the common interest of all involved. People that are waiting for profits will be maximally rewarded if they be patient and contribute to protocol sustainnability. Across will be really BIG and this is not a fanboy statement. The major crosschain pipes will see in the future typical value movements that will far exceed those of the biggest centralized exchanges today.\n\n post by jeffrey on Mar 29, 2022\n\n jeffrey\n\n Token is share, it means users own the project\n\n 12 days later\n\n post by hescollazo on Apr 11, 2022\n\n hescollazo\n\n I agree with the use of the token as a payment mechanism for the protocol. The low fees will bring new users and money into the ecosystem. That it can be used in governance will incentivize use of the application and hodling of the asset. Ultimately the goal should be to give users the tools to discover new ways in which to generate positive cash flow and build wealth.\n\n 10 days later\n\n post by Ray_V on Apr 21, 2022\n\n Ray_V\n\n Would we introduce a single staking mechanism? In which we would offer our tokens as liquidity to the across protocol and earn APR either through the fees accrued by the protocol - or another more effective system? Would that be something considered?\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Initial thinking around token distribution\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 36\n\n Mar 2022\n\n Across Token Launch Proposal\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 214\n\n May 2022\n\n Across Token Launch Proposal v2\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 47\n\n Nov 2022\n\n Second ACX Drop\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 15\n\n Feb 2024\n\n Welcome to Across\n\n WELCOME 👋\n\n WELCOME 👋\n\n Nov 2022","tokens":2413,"squid":"spider-09","role":"Bridge Spider","at":1791348170538,"hash":"f743757c4410d33fe99995459bce170c4fc626e3"}
{"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":"spider-06","role":"Security Spider","at":1791348170588,"hash":"67ac10e90b6cf56222c63f03c2889d48c8ce6a0e"}
{"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":"spider-07","role":"Council Spider","at":1791348176494,"hash":"ec5aab38124471edfc25e3bf0b4a3e0cceeef600"}
{"url":"https://forum.across.to/t/what-the-token-does/52/20","domain":"forum.across.to","title":"What the token does? - Tokenomics (old) - Across Protocol","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 read \n\n 4\n min\n\n Nov 2021\n\n 20 / 26\n\n Jan 2022\n\n Apr 2022\n\n Load more posts above\n\n post by fommes.eth on Nov 17, 2021\n\n fommes.eth\n\n Imho there is no point in holding the Across token for fees reduction. I imagine a tipical Across user will not bridge all the time, just looking at the general roadmap/POV that Eth mainnet is becoming solely/mostly just the settlement layer, already in the coming months ppl will use more frequent L2s and withdraw back sometimes.\n\n post by fommes.eth on Nov 17, 2021\n\n fommes.eth\n\n I propose the Across token to accrue fees for holders instead.\n\n post by Robot on Nov 17, 2021\n\n Robot\n\n fommes.eth\n\n Surely the more utility the better and i’m sure Across will have to go L2 to L2 in the end\n\n post by Sanguine on Nov 17, 2021\n\n Sanguine\n\n Kastormagic\n\n I think that token is needed for the DAO in the first place. It is not even necessary that it have economic value in the form of receiving % from commissions for the interaction of other users with the protocol. First of all, a token is a symbol. The more successful the project is, the more people want to be involved in it through the token.\n\n post by jotatotal on Nov 17, 2021\n\n jotatotal\n\n I would suggest that a part of the fees goes to the DAO treasury, and so increment value of DAO token. On the other hand I also consider that if the token is used to pay fees those fees get burned after that.\n\n post by fommes.eth on Nov 17, 2021\n\n fommes.eth\n\n Robot\n\n There are lots of L2 to L2 bridges already. Imho Across is unique in that sense and should aim to be the Go-To for fast+secure L1 withdrawals. There will always be a need for L1 withdrawals, even if Ethereum becomes mostly just an execution layer.\n\n post by Robot on Nov 17, 2021\n\n Robot\n\n Sanguine\n\n That’s not true go look at Ribbon finance and their token launch people bought and it non-stop gets called a useless govenunce token, Ribbon is very successful with about $200m TVL but the token price don’t reflect that\n\n post by Solace on Nov 17, 2021\n\n Solace\n\n Completely agree with /u/fojo’s post above - this is an important discussion regarding the token launch.\nWould the token be used strictly for governance, to pay out fees, or as a safety module? These do not necessarily have to mutually exclusive, and it’s possible that the token could incorporate all three - but as far as emission and distribution goes, it’s pretty important to make at least one a priority.\nIf choosing a governance route, liquidity incentives and a safety module could also be implemented at a later stage via a proposal. But this would remain subject to a vote, which could take some time to pass.\nOn the topic of liquidity incentives, these will likely remain temporary in order to bootstrap liquidity though there are plenty of examples of where artificially incentivizing usage has led to users with short-term outlooks farming these pools and draining the liquidity afterwards.\nAs far as using the token to incentivize usage goes, one approach could be to provide a gas fee rebate to users that bridge from L1 → L2 using the Arbitrum/optimism native bridge and bridge back to L1 using Across. This could be implemented similarly to Balancer’s gas fee rebate: [Proposal] Balancer Exchange Gas Reimbursement - Proposals - Balancer\nWe could get creative with some ways in order to incentivize usage rather than only incentivizing the LPs (as they will receive a fee of the transaction either way).\n\n post by Sanguine on Nov 17, 2021\n\n Sanguine\n\n Robot\n\n Maybe so. Indeed, in our time, the success of the project for the crowd is the endless rise in the price of the token. And if the price of a token does not grow infinitely, then they begin to call it “useless governance token”. But if the project starts to hype and the price rises, then it abruptly turns into an “incredibly useful governance token”.\n\n post by eqing.eth on Nov 21, 2021\n\n eqing.eth\n\n Kastormagic\n\n Tokens will attract some early users, which is necessary!At the initial stage of the project, it is necessary to attract users by token airdrop and distinguish real users.\n\n post by Alisa on Nov 22, 2021\n\n Alisa\n\n Acrosit is to establish a Dao and become a token of community governance. However, empowering and offsetting gas is a good suggestion, which can prevent members from throwing it out too early. However, it also has some disadvantages., if it is a gas, will it affect the development of community autonomy? But if it is only from the perspective of token, the more successful across is, the better the development of Dao will be, Of course, it will attract more people to participate\n\n 9 days later\n\n post by MrHeviDi on Dec 1, 2021\n\n MrHeviDi\n\n fommes.eth\n\n But there will be other protocals/bridges to move funds from L2 to L1, so Across needs to atract users to use Across and maybe to hold Across token. Maybe, like someone before montioned, having Across token will give you some fee reduction or something like that.\n\n 2 months later\n\n post by jotatotal on Jan 26, 2022\n\n jotatotal\n\n Solace\n\n What about giving the holders of the token , despite a fee reduction , a share of the fee according to their holdings?\n\n post by lawpanda.eth on Jan 26, 2022\n\n lawpanda.eth\n\n That would functionally be an ‘x’ token, like xSushi, dQuick, etc. On the legal end it creates regulatory questions because it resembles a security. But it is a more functional mechanism for facilitating adoption/use.\n\n 2 months later\n\n post by J.Berg on Mar 18, 2022\n\n J.Berg\n\n Creating a token enables the DAO to have an asset (without investing) that can be used to fund projects/guilds for effort the DAO needs (both maintenance and major initiatives), as well as contribute to internal DAO economics.\n–Paying core team members for their efforts\n–Paying for work done by Guilds and their squads\n–Internal DAO markets and trade\n–Bounties\nWill the Across token be used strictly for governance? or will it be used as money? or both?\nWould it be a monetary asset and a governance token to be used to fund and vote? Some DAO’s treat their governance token as ONLY that, and it actively drives down it’s valuation.\nIf its money then the DAO as an organization has the challenges of both a startup and an emerging digital nationstate in that we have to find and create revenue streams and manage costs, as well as drive the use and acceptance of our denomination both internally and externally.\nI think long term will be based on the size of the treasury it controls and the useful things you can do with it. As a result, I think the focus should be on activities that generate on-chain revenue for the DAO and ways to make the token useful stake it, collateral, ect.\nHow to pay contributors is definitely an important factor to consider. Without contributors, we won’t be able to do any of the above. Part of me feels that if your contributing, it should be because you believe in the DAO long term and shouldn’t expect an immediate monetary reward. The other part of me thinks that contributor renumeration is something that needs to be painstakingly thought out to retain talent and pay our people\n\n post by heybeo on Mar 22, 2022\n\n heybeo\n\n It would be nice to use bridges on the same platform as well as to create a nice dex.\nTrading pairs, for example acx-uma, are used as fees and distributed to token holders.\nacx-x\nacx-y\nacx-z\nJust a simple idea as liquidity addition commissions are burned\n\n post by altsilversurfer.nft on Mar 26, 2022\n\n altsilversurfer.nft\n\n Tokenomics can be viewed as a function of 3 main parameters, token launch (model, vesting scheme, market cap), utility, and inflation. Utility is one of the major drivers of adoption and appreciation of value. Thus, the more utilities, the best. Governance will be the first and more obvious utility of $ACX, but we must think beyond this to achieve sustainnability. This is the ultimate goal. And this is also the common interest of all involved. People that are waiting for profits will be maximally rewarded if they be patient and contribute to protocol sustainnability. Across will be really BIG and this is not a fanboy statement. The major crosschain pipes will see in the future typical value movements that will far exceed those of the biggest centralized exchanges today.\n\n post by jeffrey on Mar 29, 2022\n\n jeffrey\n\n Token is share, it means users own the project\n\n 12 days later\n\n post by hescollazo on Apr 11, 2022\n\n hescollazo\n\n I agree with the use of the token as a payment mechanism for the protocol. The low fees will bring new users and money into the ecosystem. That it can be used in governance will incentivize use of the application and hodling of the asset. Ultimately the goal should be to give users the tools to discover new ways in which to generate positive cash flow and build wealth.\n\n 10 days later\n\n post by Ray_V on Apr 21, 2022\n\n Ray_V\n\n Would we introduce a single staking mechanism? In which we would offer our tokens as liquidity to the across protocol and earn APR either through the fees accrued by the protocol - or another more effective system? Would that be something considered?\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Initial thinking around token distribution\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 36\n\n Mar 2022\n\n Across Token Launch Proposal\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 214\n\n May 2022\n\n Across Token Launch Proposal v2\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 47\n\n Nov 2022\n\n Second ACX Drop\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 15\n\n Feb 2024\n\n Welcome to Across\n\n WELCOME 👋\n\n WELCOME 👋\n\n Nov 2022","tokens":2413,"squid":"spider-09","role":"Bridge Spider","at":1791348182223,"hash":"86ded47d1319dad4523326afa1d3bbaa41fcfd1e"}
{"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 286\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 154\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 186\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 323\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 349\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 175\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 461\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 420\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":"spider-07","role":"Council Spider","at":1791348189182,"hash":"27367ad53476578f6decb44ad6c40f6a4c4eec94"}
{"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":"spider-06","role":"Security Spider","at":1791348192123,"hash":"ca930daa69dd5cd560dfa15e7bc7ed1bf401b55e"}
{"url":"https://forum.across.to/t/what-the-token-does/52/7","domain":"forum.across.to","title":"What the token does? - Tokenomics (old) - Across Protocol","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Nov 2021\n\n 7 / 26\n\n Nov 2021\n\n Apr 2022\n\n Load more posts above\n\n post by heropunk.eth on Nov 17, 2021\n\n heropunk.eth\n\n AcrossIt is to build a DAO and become a community governance token, not to use it as gas, so I don’t agree with you, on the contrary AcrosdDAO, it will have more uses\n\n post by goldsnitch.eth on Nov 17, 2021\n\n goldsnitch.eth\n\n Need tokens to attract users\n\n post by fojo on Nov 17, 2021\n\n fojo\n\n Thanks for starting this discussion. To me this is the most important discussion to have with regards to tokenomics. There is no point in airdropping a token that does nothing. So first and foremost we should think about and decide on what the token will do.\nHere’s my 2 cents:\nGovernance: Establish a governance framework by granting discission making to across token holders (i.e. voting power)\nFees: Establish utility to the token (rather than it being just a governance token) by either giving fee reductions when using the bridge or a share of the fees generated by the bridge.\nSafety module: Staked across tokens will act as a collateral of last resort, to provide insurance against shortfall events. Stakers will get staking rewards. (see AAVE and DYDX for examples).\n\n post by DHACK on Nov 17, 2021\n\n DHACK\n\n Need tokens to attract users . I agree with it\n\n post by Robot on Nov 17, 2021\n\n Robot\n\n I think we should bump up the fees for using the bridge by a small % but if you stake X amount of the token then fees come back down to the original %, and if you stake even more you become eligible for profit share and all the usual stuff that comes with a govenunce token.\n\n post by fommes.eth on Nov 17, 2021\n\n fommes.eth\n\n Imho there is no point in holding the Across token for fees reduction. I imagine a tipical Across user will not bridge all the time, just looking at the general roadmap/POV that Eth mainnet is becoming solely/mostly just the settlement layer, already in the coming months ppl will use more frequent L2s and withdraw back sometimes.\n\n post by fommes.eth on Nov 17, 2021\n\n fommes.eth\n\n I propose the Across token to accrue fees for holders instead.\n\n post by Robot on Nov 17, 2021\n\n Robot\n\n fommes.eth\n\n Surely the more utility the better and i’m sure Across will have to go L2 to L2 in the end\n\n post by Sanguine on Nov 17, 2021\n\n Sanguine\n\n Kastormagic\n\n I think that token is needed for the DAO in the first place. It is not even necessary that it have economic value in the form of receiving % from commissions for the interaction of other users with the protocol. First of all, a token is a symbol. The more successful the project is, the more people want to be involved in it through the token.\n\n post by jotatotal on Nov 17, 2021\n\n jotatotal\n\n I would suggest that a part of the fees goes to the DAO treasury, and so increment value of DAO token. On the other hand I also consider that if the token is used to pay fees those fees get burned after that.\n\n post by fommes.eth on Nov 17, 2021\n\n fommes.eth\n\n Robot\n\n There are lots of L2 to L2 bridges already. Imho Across is unique in that sense and should aim to be the Go-To for fast+secure L1 withdrawals. There will always be a need for L1 withdrawals, even if Ethereum becomes mostly just an execution layer.\n\n post by Robot on Nov 17, 2021\n\n Robot\n\n Sanguine\n\n That’s not true go look at Ribbon finance and their token launch people bought and it non-stop gets called a useless govenunce token, Ribbon is very successful with about $200m TVL but the token price don’t reflect that\n\n post by Solace on Nov 17, 2021\n\n Solace\n\n Completely agree with /u/fojo’s post above - this is an important discussion regarding the token launch.\nWould the token be used strictly for governance, to pay out fees, or as a safety module? These do not necessarily have to mutually exclusive, and it’s possible that the token could incorporate all three - but as far as emission and distribution goes, it’s pretty important to make at least one a priority.\nIf choosing a governance route, liquidity incentives and a safety module could also be implemented at a later stage via a proposal. But this would remain subject to a vote, which could take some time to pass.\nOn the topic of liquidity incentives, these will likely remain temporary in order to bootstrap liquidity though there are plenty of examples of where artificially incentivizing usage has led to users with short-term outlooks farming these pools and draining the liquidity afterwards.\nAs far as using the token to incentivize usage goes, one approach could be to provide a gas fee rebate to users that bridge from L1 → L2 using the Arbitrum/optimism native bridge and bridge back to L1 using Across. This could be implemented similarly to Balancer’s gas fee rebate: [Proposal] Balancer Exchange Gas Reimbursement - Proposals - Balancer\nWe could get creative with some ways in order to incentivize usage rather than only incentivizing the LPs (as they will receive a fee of the transaction either way).\n\n post by Sanguine on Nov 17, 2021\n\n Sanguine\n\n Robot\n\n Maybe so. Indeed, in our time, the success of the project for the crowd is the endless rise in the price of the token. And if the price of a token does not grow infinitely, then they begin to call it “useless governance token”. But if the project starts to hype and the price rises, then it abruptly turns into an “incredibly useful governance token”.\n\n post by eqing.eth on Nov 21, 2021\n\n eqing.eth\n\n Kastormagic\n\n Tokens will attract some early users, which is necessary!At the initial stage of the project, it is necessary to attract users by token airdrop and distinguish real users.\n\n post by Alisa on Nov 22, 2021\n\n Alisa\n\n Acrosit is to establish a Dao and become a token of community governance. However, empowering and offsetting gas is a good suggestion, which can prevent members from throwing it out too early. However, it also has some disadvantages., if it is a gas, will it affect the development of community autonomy? But if it is only from the perspective of token, the more successful across is, the better the development of Dao will be, Of course, it will attract more people to participate\n\n 9 days later\n\n post by MrHeviDi on Dec 1, 2021\n\n MrHeviDi\n\n fommes.eth\n\n But there will be other protocals/bridges to move funds from L2 to L1, so Across needs to atract users to use Across and maybe to hold Across token. Maybe, like someone before montioned, having Across token will give you some fee reduction or something like that.\n\n 2 months later\n\n post by jotatotal on Jan 26, 2022\n\n jotatotal\n\n Solace\n\n What about giving the holders of the token , despite a fee reduction , a share of the fee according to their holdings?\n\n post by lawpanda.eth on Jan 26, 2022\n\n lawpanda.eth\n\n That would functionally be an ‘x’ token, like xSushi, dQuick, etc. On the legal end it creates regulatory questions because it resembles a security. But it is a more functional mechanism for facilitating adoption/use.\n\n 2 months later\n\n post by J.Berg on Mar 18, 2022\n\n J.Berg\n\n Creating a token enables the DAO to have an asset (without investing) that can be used to fund projects/guilds for effort the DAO needs (both maintenance and major initiatives), as well as contribute to internal DAO economics.\n–Paying core team members for their efforts\n–Paying for work done by Guilds and their squads\n–Internal DAO markets and trade\n–Bounties\nWill the Across token be used strictly for governance? or will it be used as money? or both?\nWould it be a monetary asset and a governance token to be used to fund and vote? Some DAO’s treat their governance token as ONLY that, and it actively drives down it’s valuation.\nIf its money then the DAO as an organization has the challenges of both a startup and an emerging digital nationstate in that we have to find and create revenue streams and manage costs, as well as drive the use and acceptance of our denomination both internally and externally.\nI think long term will be based on the size of the treasury it controls and the useful things you can do with it. As a result, I think the focus should be on activities that generate on-chain revenue for the DAO and ways to make the token useful stake it, collateral, ect.\nHow to pay contributors is definitely an important factor to consider. Without contributors, we won’t be able to do any of the above. Part of me feels that if your contributing, it should be because you believe in the DAO long term and shouldn’t expect an immediate monetary reward. The other part of me thinks that contributor renumeration is something that needs to be painstakingly thought out to retain talent and pay our people\n\n Load more posts below","tokens":2173,"squid":"spider-09","role":"Bridge Spider","at":1791348192539,"hash":"861ccecfeb966a4730c4ec2f7c5f05d7c5a457b3"}
{"url":"https://gov.optimism.io/t/upgrade-19b-karst-hardfork/10713/1","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 soyboy\n\n Calldata posted separately because of character limit in the main post\nThe expected calldata to sign on for a bundled OP, Ink, Mode, Metal, Zora, and Soneium is below. This also includes the upgrade on Ink, Metal, Mode, and Zora Mainnets as these networks will be upgraded in one superchain-ops task alongside OP Mainnet:\n0x82ad56cb0000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000000700000000000000000000000000000000000000000000000000000000000000e000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000000b0000000000000000000000000000000000000000000000000000000000000014000000000000000000000000000000000000000000000000000000000000001ce000000000000000000000000000000000000000000000000000000000000025c00000000000000000000000000000000000000000000000000000000000002ea00000000000000000000000009ce712ff84e02659846dc6450bb9b7642fe8be5d00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000008486fe1c66000000000000000000000000000000000000000000000000000000000000002000000000000000000000000095703e0982140d16f8eba6d158fccede42f04a4c00000000000000000000000000000000000000000000000000000000000000400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000009ce712ff84e02659846dc6450bb9b7642fe8be5d0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006000000000000000000000000000000000000000000000000000000000000008648a847e2e0000000000000000000000000000000000000000000000000000000000000020000000000000000000000000229047fed2591dbec1ef1118d64f7af3db9eb29000000000000000000000000000000000000000000000000000000000000000600000000000000000000000000000000000000000000000000000000000000640000000000000000000000000000000000000000000000000000000000000000700000000000000000000000000000000000000000000000000000000000000e000000000000000000000000000000000000000000000000000000000000001800000000000000000000000000000000000000000000000000000000000000280000000000000000000000000000000000000000000000000000000000000034000000000000000000000000000000000000000000000000000000000000003e000000000000000000000000000000000000000000000000000000000000004800000000000000000000000000000000000000000000000000000000000000520000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000011c37937e080000000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000800000000000000000000000000000000000000000000000000000000000000060dead000000000000000000000000000000000000000000000000000000000000000000000000000000000000473300df21d047806a082244b417f96b32f13a330000000000000000000000009ba6e03d8b90de867373db8cf1a58d2f7f006b3a0000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000011c37937e0800000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000200337ecb3604c0b40c352e0c7711beb17a212d583f4fe956fd8d66e29ad5f902500000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000400000000000000000000000000000000000000000000000000000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000005000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000090000000000000000000000000000000000000000000000000000000000000080000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000a000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000000000000000000040000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000185065726d697474656450726f78794465706c6f796d656e740000000000000000000000000000000000000000000000000000000000000000000000000000000b44656c6179656457455448000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000a000000000000000000000000000000000000000000000000000000000000000276f76657272696465732e6366672e7374617274696e6752657370656374656447616d65547970650000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000000000000000000009ce712ff84e02659846dc6450bb9b7642fe8be5d0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006000000000000000000000000000000000000000000000000000000000000008648a847e2e000000000000000000000000000000000000000000000000000000000000002000000000000000000000000062c0a111929fa32cec2f76adba54c16afb6e836400000000000000000000000000000000000000000000000000000000000000600000000000000000000000000000000000000000000000000000000000000640000000000000000000000000000000000000000000000000000000000000000700000000000000000000000000000000000000000000000000000000000000e000000000000000000000000000000000000000000000000000000000000001800000000000000000000000000000000000000000000000000000000000000280000000000000000000000000000000000000000000000000000000000000034000000000000000000000000000000000000000000000000000000000000003e000000000000000000000000000000000000000000000000000000000000004800000000000000000000000000000000000000000000000000000000000000520000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000011c37937e080000000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000800000000000000000000000000000000000000000000000000000000000000060dead00000000000000000000000000000000000000000000000000000000000000000000000000000000000065436ddcbc026f34118954f229f7f132b696b3b40000000000000000000000009ba6e03d8b90de867373db8cf1a58d2f7f006b3a0000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000011c37937e0800000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000200337ecb3604c0b40c352e0c7711beb17a212d583f4fe956fd8d66e29ad5f902500000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000400000000000000000000000000000000000000000000000000000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000005000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000090000000000000000000000000000000000000000000000000000000000000080000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000a000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000000000000000000040000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000185065726d697474656450726f78794465706c6f796d656e740000000000000000000000000000000000000000000000000000000000000000000000000000000b44656c6179656457455448000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000a000000000000000000000000000000000000000000000000000000000000000276f76657272696465732e6366672e7374617274696e6752657370656374656447616d65547970650000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000000000000000000009ce712ff84e02659846dc6450bb9b7642fe8be5d0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006000000000000000000000000000000000000000000000000000000000000008448a847e2e00000000000000000000000000000000000000000000000000000000000000200000000000000000000000007bd909970b0eedcf078de6aeff23ce571663b8aa00000000000000000000000000000000000000000000000000000000000000600000000000000000000000000000000000000000000000000000000000000620000000000000000000000000000000000000000000000000000000000000000700000000000000000000000000000000000000000000000000000000000000e000000000000000000000000000000000000000000000000000000000000001800000000000000000000000000000000000000000000000000000000000000280000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000003c0000000000000000000000000000000000000000000000000000000000000046000000000000000000000000000000000000000000000000000000000000005000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000080000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000800000000000000000000000000000000000000000000000000000000000000060dead000000000000000000000000000000000000000000000000000000000000000000000000000000000000c8187d40ad440328104a52bbed2d8efc5ab1f1f60000000000000000000000009ba6e03d8b90de867373db8cf1a58d2f7f006b3a0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000080000000000000000000000000000000000000000000000000000000000000080000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000400000000000000000000000000000000000000000000000000000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000005000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000090000000000000000000000000000000000000000000000000000000000000080000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000a000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000000000000000000040000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000185065726d697474656450726f78794465706c6f796d656e740000000000000000000000000000000000000000000000000000000000000000000000000000000b44656c6179656457455448000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000a000000000000000000000000000000000000000000000000000000000000000276f76657272696465732e6366672e7374617274696e6752657370656374656447616d65547970650000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000000000000000000000000000000000009ce712ff84e02659846dc6450bb9b7642fe8be5d0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006000000000000000000000000000000000000000000000000000000000000008448a847e2e00000000000000000000000000000000000000000000000000000000000000200000000000000000000000005e6432f18bc5d497b1ab2288a025fbf9d69e222100000000000000000000000000000000000000000000000000000000000000600000000000000000000000000000000000000000000000000000000000000620000000000000000000000000000000000000000000000000000000000000000700000000000000000000000000000000000000000000000000000000000000e000000000000000000000000000000000000000000000000000000000000001800000000000000000000000000000000000000000000000000000000000000280000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000003c0000000000000000000000000000000000000000000000000000000000000046000000000000000000000000000000000000000000000000000000000000005000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000080000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000800000000000000000000000000000000000000000000000000000000000000060dead000000000000000000000000000000000000000000000000000000000000000000000000000000000000674f64d64ddc198db83cd9047df54bf89ccd0ddb0000000000000000000000009ba6e03d8b90de867373db8cf1a58d2f7f006b3a0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000080000000000000000000000000000000000000000000000000000000000000080000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000400000000000000000000000000000000000000000000000000000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000005000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000090000000000000000000000000000000000000000000000000000000000000080000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000a000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000000000000000000040000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000185065726d697474656450726f78794465706c6f796d656e740000000000000000000000000000000000000000000000000000000000000000000000000000000b44656c6179656457455448000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000a000000000000000000000000000000000000000000000000000000000000000276f76657272696465732e6366672e7374617274696e6752657370656374656447616d65547970650000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000000000000000000000000000000000009ce712ff84e02659846dc6450bb9b7642fe8be5d0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006000000000000000000000000000000000000000000000000000000000000008448a847e2e0000000000000000000000000000000000000000000000000000000000000020000000000000000000000000a3cab0126d5f504b071b81a3e8a2bbbf17930d8600000000000000000000000000000000000000000000000000000000000000600000000000000000000000000000000000000000000000000000000000000620000000000000000000000000000000000000000000000000000000000000000700000000000000000000000000000000000000000000000000000000000000e000000000000000000000000000000000000000000000000000000000000001800000000000000000000000000000000000000000000000000000000000000280000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000003c0000000000000000000000000000000000000000000000000000000000000046000000000000000000000000000000000000000000000000000000000000005000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000080000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000800000000000000000000000000000000000000000000000000000000000000060dead00000000000000000000000000000000000000000000000000000000000000000000000000000000000048247032092e7b0ecf5def611ad89eaf3fc888dd0000000000000000000000009ba6e03d8b90de867373db8cf1a58d2f7f006b3a0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000080000000000000000000000000000000000000000000000000000000000000080000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000400000000000000000000000000000000000000000000000000000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000005000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000090000000000000000000000000000000000000000000000000000000000000080000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000a000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000000000000000000040000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000185065726d697474656450726f78794465706c6f796d656e740000000000000000000000000000000000000000000000000000000000000000000000000000000b44656c6179656457455448000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000a000000000000000000000000000000000000000000000000000000000000000276f76657272696465732e6366672e7374617274696e6752657370656374656447616d65547970650000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000000000000000000000000000000000009ce712ff84e02659846dc6450bb9b7642fe8be5d0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006000000000000000000000000000000000000000000000000000000000000008448a847e2e00000000000000000000000000000000000000000000000000000000000000200000000000000000000000007a8ed66b319911a0f3e7288bddab30d9c0c875c300000000000000000000000000000000000000000000000000000000000000600000000000000000000000000000000000000000000000000000000000000620000000000000000000000000000000000000000000000000000000000000000700000000000000000000000000000000000000000000000000000000000000e000000000000000000000000000000000000000000000000000000000000001800000000000000000000000000000000000000000000000000000000000000280000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000003c0000000000000000000000000000000000000000000000000000000000000046000000000000000000000000000000000000000000000000000000000000005000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000080000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000800000000000000000000000000000000000000000000000000000000000000060dead000000000000000000000000000000000000000000000000000000000000000000000000000000000000400c164c4a8ca84385b70eed6eb03ea847c8e1b80000000000000000000000009ba6e03d8b90de867373db8cf1a58d2f7f006b3a0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000080000000000000000000000000000000000000000000000000000000000000080000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000400000000000000000000000000000000000000000000000000000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000005000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000090000000000000000000000000000000000000000000000000000000000000080000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000a000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000000000000000000040000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000185065726d697474656450726f78794465706c6f796d656e740000000000000000000000000000000000000000000000000000000000000000000000000000000b44656c6179656457455448000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000a000000000000000000000000000000000000000000000000000000000000000276f76657272696465732e6366672e7374617274696e6752657370656374656447616d6554797065000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000\n\nUnichain Mainnet\n0x82ad56cb0000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000200000000000000000000000009ce712ff84e02659846dc6450bb9b7642fe8be5d0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006000000000000000000000000000000000000000000000000000000000000008648a847e2e0000000000000000000000000000000000000000000000000000000000000020000000000000000000000000c407398d063f942febbcc6f80a156b47f3f1bda600000000000000000000000000000000000000000000000000000000000000600000000000000000000000000000000000000000000000000000000000000640000000000000000000000000000000000000000000000000000000000000000700000000000000000000000000000000000000000000000000000000000000e000000000000000000000000000000000000000000000000000000000000001800000000000000000000000000000000000000000000000000000000000000280000000000000000000000000000000000000000000000000000000000000034000000000000000000000000000000000000000000000000000000000000003e000000000000000000000000000000000000000000000000000000000000004800000000000000000000000000000000000000000000000000000000000000520000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000011c37937e080000000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000800000000000000000000000000000000000000000000000000000000000000060dead000000000000000000000000000000000000000000000000000000000000000000000000000000000000d5f0e2912c70771c589cd8bb087ede0dab4afa9a0000000000000000000000009ba6e03d8b90de867373db8cf1a58d2f7f006b3a0000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000011c37937e0800000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000200337ecb3604c0b40c352e0c7711beb17a212d583f4fe956fd8d66e29ad5f902500000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000400000000000000000000000000000000000000000000000000000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000005000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000090000000000000000000000000000000000000000000000000000000000000080000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000a000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000000000000000000040000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000185065726d697474656450726f78794465706c6f796d656e740000000000000000000000000000000000000000000000000000000000000000000000000000000b44656c6179656457455448000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000a000000000000000000000000000000000000000000000000000000000000000276f76657272696465732e6366672e7374617274696e6752657370656374656447616d6554797065000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000000800000000000000000000000000000000000000000000000000000000\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 319\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":12247,"squid":"spider-07","role":"Council Spider","at":1791348199430,"hash":"f38037e058cbc9fa53d3107e5f2c466fd6ef491d"}
{"url":"https://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":"spider-06","role":"Security Spider","at":1791348202385,"hash":"edf75d81089b54514a0d9e7765284a899e6db37b"}
{"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 582\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 247\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 792\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 826\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":"spider-05","role":"Spec Spider","at":1791348205837,"hash":"ae55bfb085ef7de1d46539e4c483b9050cc12c9e"}
{"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 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 soyboy\n\n Calldata posted separately because of character limit in the main post\nThe expected calldata to sign on for a bundled OP, Ink, Mode, Metal, Zora, and Soneium is below. This also includes the upgrade on Ink, Metal, Mode, and Zora Mainnets as these networks will be upgraded in one superchain-ops task alongside OP Mainnet:\n0x82ad56cb0000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000000700000000000000000000000000000000000000000000000000000000000000e000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000000b0000000000000000000000000000000000000000000000000000000000000014000000000000000000000000000000000000000000000000000000000000001ce000000000000000000000000000000000000000000000000000000000000025c00000000000000000000000000000000000000000000000000000000000002ea00000000000000000000000009ce712ff84e02659846dc6450bb9b7642fe8be5d00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000008486fe1c66000000000000000000000000000000000000000000000000000000000000002000000000000000000000000095703e0982140d16f8eba6d158fccede42f04a4c00000000000000000000000000000000000000000000000000000000000000400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000009ce712ff84e02659846dc6450bb9b7642fe8be5d0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006000000000000000000000000000000000000000000000000000000000000008648a847e2e0000000000000000000000000000000000000000000000000000000000000020000000000000000000000000229047fed2591dbec1ef1118d64f7af3db9eb29000000000000000000000000000000000000000000000000000000000000000600000000000000000000000000000000000000000000000000000000000000640000000000000000000000000000000000000000000000000000000000000000700000000000000000000000000000000000000000000000000000000000000e000000000000000000000000000000000000000000000000000000000000001800000000000000000000000000000000000000000000000000000000000000280000000000000000000000000000000000000000000000000000000000000034000000000000000000000000000000000000000000000000000000000000003e000000000000000000000000000000000000000000000000000000000000004800000000000000000000000000000000000000000000000000000000000000520000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000011c37937e080000000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000800000000000000000000000000000000000000000000000000000000000000060dead000000000000000000000000000000000000000000000000000000000000000000000000000000000000473300df21d047806a082244b417f96b32f13a330000000000000000000000009ba6e03d8b90de867373db8cf1a58d2f7f006b3a0000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000011c37937e0800000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000200337ecb3604c0b40c352e0c7711beb17a212d583f4fe956fd8d66e29ad5f902500000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000400000000000000000000000000000000000000000000000000000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000005000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000090000000000000000000000000000000000000000000000000000000000000080000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000a000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000000000000000000040000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000185065726d697474656450726f78794465706c6f796d656e740000000000000000000000000000000000000000000000000000000000000000000000000000000b44656c6179656457455448000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000a000000000000000000000000000000000000000000000000000000000000000276f76657272696465732e6366672e7374617274696e6752657370656374656447616d65547970650000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000000000000000000009ce712ff84e02659846dc6450bb9b7642fe8be5d0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006000000000000000000000000000000000000000000000000000000000000008648a847e2e000000000000000000000000000000000000000000000000000000000000002000000000000000000000000062c0a111929fa32cec2f76adba54c16afb6e836400000000000000000000000000000000000000000000000000000000000000600000000000000000000000000000000000000000000000000000000000000640000000000000000000000000000000000000000000000000000000000000000700000000000000000000000000000000000000000000000000000000000000e000000000000000000000000000000000000000000000000000000000000001800000000000000000000000000000000000000000000000000000000000000280000000000000000000000000000000000000000000000000000000000000034000000000000000000000000000000000000000000000000000000000000003e000000000000000000000000000000000000000000000000000000000000004800000000000000000000000000000000000000000000000000000000000000520000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000011c37937e080000000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000800000000000000000000000000000000000000000000000000000000000000060dead00000000000000000000000000000000000000000000000000000000000000000000000000000000000065436ddcbc026f34118954f229f7f132b696b3b40000000000000000000000009ba6e03d8b90de867373db8cf1a58d2f7f006b3a0000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000011c37937e0800000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000200337ecb3604c0b40c352e0c7711beb17a212d583f4fe956fd8d66e29ad5f902500000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000400000000000000000000000000000000000000000000000000000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000005000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000090000000000000000000000000000000000000000000000000000000000000080000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000a000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000000000000000000040000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000185065726d697474656450726f78794465706c6f796d656e740000000000000000000000000000000000000000000000000000000000000000000000000000000b44656c6179656457455448000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000a000000000000000000000000000000000000000000000000000000000000000276f76657272696465732e6366672e7374617274696e6752657370656374656447616d65547970650000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000000000000000000009ce712ff84e02659846dc6450bb9b7642fe8be5d0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006000000000000000000000000000000000000000000000000000000000000008448a847e2e00000000000000000000000000000000000000000000000000000000000000200000000000000000000000007bd909970b0eedcf078de6aeff23ce571663b8aa00000000000000000000000000000000000000000000000000000000000000600000000000000000000000000000000000000000000000000000000000000620000000000000000000000000000000000000000000000000000000000000000700000000000000000000000000000000000000000000000000000000000000e000000000000000000000000000000000000000000000000000000000000001800000000000000000000000000000000000000000000000000000000000000280000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000003c0000000000000000000000000000000000000000000000000000000000000046000000000000000000000000000000000000000000000000000000000000005000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000080000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000800000000000000000000000000000000000000000000000000000000000000060dead000000000000000000000000000000000000000000000000000000000000000000000000000000000000c8187d40ad440328104a52bbed2d8efc5ab1f1f60000000000000000000000009ba6e03d8b90de867373db8cf1a58d2f7f006b3a0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000080000000000000000000000000000000000000000000000000000000000000080000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000400000000000000000000000000000000000000000000000000000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000005000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000090000000000000000000000000000000000000000000000000000000000000080000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000a000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000000000000000000040000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000185065726d697474656450726f78794465706c6f796d656e740000000000000000000000000000000000000000000000000000000000000000000000000000000b44656c6179656457455448000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000a000000000000000000000000000000000000000000000000000000000000000276f76657272696465732e6366672e7374617274696e6752657370656374656447616d65547970650000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000000000000000000000000000000000009ce712ff84e02659846dc6450bb9b7642fe8be5d0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006000000000000000000000000000000000000000000000000000000000000008448a847e2e00000000000000000000000000000000000000000000000000000000000000200000000000000000000000005e6432f18bc5d497b1ab2288a025fbf9d69e222100000000000000000000000000000000000000000000000000000000000000600000000000000000000000000000000000000000000000000000000000000620000000000000000000000000000000000000000000000000000000000000000700000000000000000000000000000000000000000000000000000000000000e000000000000000000000000000000000000000000000000000000000000001800000000000000000000000000000000000000000000000000000000000000280000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000003c0000000000000000000000000000000000000000000000000000000000000046000000000000000000000000000000000000000000000000000000000000005000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000080000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000800000000000000000000000000000000000000000000000000000000000000060dead000000000000000000000000000000000000000000000000000000000000000000000000000000000000674f64d64ddc198db83cd9047df54bf89ccd0ddb0000000000000000000000009ba6e03d8b90de867373db8cf1a58d2f7f006b3a0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000080000000000000000000000000000000000000000000000000000000000000080000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000400000000000000000000000000000000000000000000000000000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000005000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000090000000000000000000000000000000000000000000000000000000000000080000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000a000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000000000000000000040000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000185065726d697474656450726f78794465706c6f796d656e740000000000000000000000000000000000000000000000000000000000000000000000000000000b44656c6179656457455448000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000a000000000000000000000000000000000000000000000000000000000000000276f76657272696465732e6366672e7374617274696e6752657370656374656447616d65547970650000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000000000000000000000000000000000009ce712ff84e02659846dc6450bb9b7642fe8be5d0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006000000000000000000000000000000000000000000000000000000000000008448a847e2e0000000000000000000000000000000000000000000000000000000000000020000000000000000000000000a3cab0126d5f504b071b81a3e8a2bbbf17930d8600000000000000000000000000000000000000000000000000000000000000600000000000000000000000000000000000000000000000000000000000000620000000000000000000000000000000000000000000000000000000000000000700000000000000000000000000000000000000000000000000000000000000e000000000000000000000000000000000000000000000000000000000000001800000000000000000000000000000000000000000000000000000000000000280000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000003c0000000000000000000000000000000000000000000000000000000000000046000000000000000000000000000000000000000000000000000000000000005000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000080000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000800000000000000000000000000000000000000000000000000000000000000060dead00000000000000000000000000000000000000000000000000000000000000000000000000000000000048247032092e7b0ecf5def611ad89eaf3fc888dd0000000000000000000000009ba6e03d8b90de867373db8cf1a58d2f7f006b3a0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000080000000000000000000000000000000000000000000000000000000000000080000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000400000000000000000000000000000000000000000000000000000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000005000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000090000000000000000000000000000000000000000000000000000000000000080000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000a000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000000000000000000040000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000185065726d697474656450726f78794465706c6f796d656e740000000000000000000000000000000000000000000000000000000000000000000000000000000b44656c6179656457455448000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000a000000000000000000000000000000000000000000000000000000000000000276f76657272696465732e6366672e7374617274696e6752657370656374656447616d65547970650000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000000000000000000000000000000000009ce712ff84e02659846dc6450bb9b7642fe8be5d0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006000000000000000000000000000000000000000000000000000000000000008448a847e2e00000000000000000000000000000000000000000000000000000000000000200000000000000000000000007a8ed66b319911a0f3e7288bddab30d9c0c875c300000000000000000000000000000000000000000000000000000000000000600000000000000000000000000000000000000000000000000000000000000620000000000000000000000000000000000000000000000000000000000000000700000000000000000000000000000000000000000000000000000000000000e000000000000000000000000000000000000000000000000000000000000001800000000000000000000000000000000000000000000000000000000000000280000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000003c0000000000000000000000000000000000000000000000000000000000000046000000000000000000000000000000000000000000000000000000000000005000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000080000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000800000000000000000000000000000000000000000000000000000000000000060dead000000000000000000000000000000000000000000000000000000000000000000000000000000000000400c164c4a8ca84385b70eed6eb03ea847c8e1b80000000000000000000000009ba6e03d8b90de867373db8cf1a58d2f7f006b3a0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000080000000000000000000000000000000000000000000000000000000000000080000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000400000000000000000000000000000000000000000000000000000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000005000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000090000000000000000000000000000000000000000000000000000000000000080000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000a000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000000000000000000040000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000185065726d697474656450726f78794465706c6f796d656e740000000000000000000000000000000000000000000000000000000000000000000000000000000b44656c6179656457455448000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000a000000000000000000000000000000000000000000000000000000000000000276f76657272696465732e6366672e7374617274696e6752657370656374656447616d6554797065000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000\n\nUnichain Mainnet\n0x82ad56cb0000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000200000000000000000000000009ce712ff84e02659846dc6450bb9b7642fe8be5d0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006000000000000000000000000000000000000000000000000000000000000008648a847e2e0000000000000000000000000000000000000000000000000000000000000020000000000000000000000000c407398d063f942febbcc6f80a156b47f3f1bda600000000000000000000000000000000000000000000000000000000000000600000000000000000000000000000000000000000000000000000000000000640000000000000000000000000000000000000000000000000000000000000000700000000000000000000000000000000000000000000000000000000000000e000000000000000000000000000000000000000000000000000000000000001800000000000000000000000000000000000000000000000000000000000000280000000000000000000000000000000000000000000000000000000000000034000000000000000000000000000000000000000000000000000000000000003e000000000000000000000000000000000000000000000000000000000000004800000000000000000000000000000000000000000000000000000000000000520000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000011c37937e080000000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000800000000000000000000000000000000000000000000000000000000000000060dead000000000000000000000000000000000000000000000000000000000000000000000000000000000000d5f0e2912c70771c589cd8bb087ede0dab4afa9a0000000000000000000000009ba6e03d8b90de867373db8cf1a58d2f7f006b3a0000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000011c37937e0800000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000200337ecb3604c0b40c352e0c7711beb17a212d583f4fe956fd8d66e29ad5f902500000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000400000000000000000000000000000000000000000000000000000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000005000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000090000000000000000000000000000000000000000000000000000000000000080000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000a000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000000000000000000040000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000185065726d697474656450726f78794465706c6f796d656e740000000000000000000000000000000000000000000000000000000000000000000000000000000b44656c6179656457455448000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000a000000000000000000000000000000000000000000000000000000000000000276f76657272696465732e6366672e7374617274696e6752657370656374656447616d6554797065000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000000800000000000000000000000000000000000000000000000000000000\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 319\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":12239,"squid":"spider-07","role":"Council Spider","at":1791348209723,"hash":"4cffa3dfd7095058d9cf621bc8ae6e2657800bcb"}
{"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 License and Attribution of the Solidity Logo?\n\n Documentation\n\n 5\n\n 247\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 Localization of The Solidity Documentation\n\n Documentation\n\n 0\n\n 83\n\n Jun 2\n\n Solc-bin binaries hosting migration on 09/12/2025\n\n Announcements\n\n 0\n\n 125\n\n Dec 2025\n\n Is Core Solidity versioned as Solidity 0.9?\n\n Uncategorized\n\n 3\n\n 123\n\n Jun 29\n\n Want to read more? Browse other topics in Documentation or view latest topics.","tokens":1105,"squid":"spider-05","role":"Spec Spider","at":1791348215868,"hash":"0c21dba97f94b12ad3c5e25fdef558a71e1f6172"}
{"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.$38,059,865,505,496RangeAllLast 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.$153,117,420,050RangeAllLast 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.429,739,029RangeAllLast 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":"spider-06","role":"Security Spider","at":1791348222384,"hash":"bea7f2c77152a8f8c8c0ea63852716c7476ded2a"}
{"url":"https://verified.jup.ag/tokens/browse","domain":"verified.jup.ag","title":"Browse Tokens | VRFD","text":"MUU●PendingMeetUsUp··36mMUULike to fast trackSmart likes move it up the review queueLike NowHelp fast-track this submissionSmart likes move pending submissions up the review queue. We periodically scan and add new smart likes accounts to our list from interactions on this site.DashboardSubmission detailsSubmitter X@_MeetUsUpSubmitter wallet—Token X@_meetusupSubmitted06 Oct 2026, 23:07Last reviewed—Submitter contextMUU is the official Solana token of MeetUsUp, a platform with events, social features and three playable games, including MUU-VEMENT OF THE COWS.\n\nWebsite: \nOfficial X: \nMint: GWt75qqHN1NEBeBC6cc9CAfCz3Rg7yicGT8EbL6iuuSFhttps://meetusup.com/https://x.com/_meetusupMetricsMC / FDV$89.3K/$89.3K24h Vol / Net$138/S:$108Liquidity$650Organic score0Likes / Smart Likes0/0Smart Followers0Jup ShieldAudit log06 Oct 2026, 23:07submitted@_MeetUsUp· standard lane06 Oct 2026, 23:07autoJup shield found 5 warnings","tokens":230,"squid":"spider-02","role":"Liquidity Spider","at":1791348222604,"hash":"31cc0efb3ddf34051ad4202f815977ddbb46fca1"}
{"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 583\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 247\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 792\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 826\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":"spider-05","role":"Spec Spider","at":1791348226415,"hash":"39bad800eb825699003046ace0415bbcaaaae4df"}
{"url":"https://verified.jup.ag/dashboard/GWt75qqHN1NEBeBC6cc9CAfCz3Rg7yicGT8EbL6iuuSF?section=likes","domain":"verified.jup.ag","title":"MUU: Dashboard | VRFD","text":"MUUMeetUsUpMUULike to fast trackSmart likes move it up the review queueLike NowHelp fast-track this submissionSmart likes move pending submissions up the review queue. We periodically scan and add new smart likes accounts to our list from interactions on this site.5 JupShield WarningsToken DataGet a green checkmark and accurate token info across Jupiter platforms and API partners.Name: MeetUsUpSymbol: MUUCirculating Supply: 500MWebsite:missingAdd nowX:missingAdd nowDescription:missingAdd nowSubmission history2MetadataPending·@_MeetUsUp06 Oct 2026, 23:07VerificationPending·@_MeetUsUp06 Oct 2026, 23:07","tokens":152,"squid":"spider-02","role":"Liquidity Spider","at":1791348233535,"hash":"05b2367e87ec98837e73ca5c16b0595387070273"}
{"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 613\n\n Feb 2021\n\n abi.encodeCall consistently generates cheaper gas than abi.encodeWithSelector is this by design?\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 1\n\n 120\n\n Jun 9\n\n What Solidity try/catch actually catches\n\n 1\n\n 121\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 772\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 747\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":"spider-05","role":"Spec Spider","at":1791348240106,"hash":"78cb5c53719239fe26e10cfb698da12a1fa316bb"}
{"url":"https://developers.jup.ag/docs/price","domain":"developers.jup.ag","title":"Solana Price API - Jupiter Developers","text":"The Jupiter Price API aims to be the source of truth of token prices across all Jupiter UIs and integrator platforms, providing a seamless experience for developers and a reliable and accurate price source for users.\n​Challenges\nAccurately pricing tokens on-chain is deceptively complex. Unlike traditional markets with centralized pricing mechanisms and consistent liquidity, decentralized finance (DeFi) presents a set of dynamic and often adversarial conditions. The Price API V3 is built with these realities in mind, abstracting away challenges to deliver accurate, real-time token prices with integrity and consistency.\nChallengeDescriptionGamification of PriceIn decentralized environments, token prices can be manipulated or “gamed” for appearances or exploitative purposes. Common patterns include: * Wash trading to inflate volume or imply activity * Circular swaps to fabricate higher valuationsFragmented, Volatile or Imbalanced Liquidity Across VenuesLiquidity on Solana (and other chains) is spread across numerous protocols and AMMs. No single source can represent the entire market. Different pools might have wildly different pricing and can change very quickly.Low Liquidity TokensSome tokens trade rarely or only within shallow pools. In such cases, even small orders can cause large price swings, making pricing unreliable.\n​How Price is Derived\nPrice API V3 prices tokens by using the last swapped price (across all transactions). The swaps are priced by working outwards from a small set of reliable tokens (like SOL) whose price we get from external oracle sources.\nWhile and also after deriving the last swap price, we also utilize a number of heuristics to ensure the accuracy of the price and eliminate any outliers:\n\nAsset origin and launch method\nMarket liquidity metrics\nMarket behaviour patterns\nHolder distribution statistics\nTrading activity indicators\nOrganic Score\n\n:::caution\nWhen using Price API, do note that you may face many tokens where price is not available or returns null.\nThis is because, we use the aforementioned heuristics to determine the price of a token and if the price is reliable - if certain combinations of these factors indicate potential issues with price reliability or market health, the token will be flagged and not provided a price.\nThis is to safeguard users and prevent an inaccurate price from being returned.\n:::\n​Get Price\nSimply request via the base URL with the query parameters of your desired mint addresses. You can also comma-separate them to request for multiple prices.\nconst price = await (\n await fetch(\n 'https://api.jup.ag/price/v3?ids=So11111111111111111111111111111111111111112,JUPyiwrYJFskUPiHa7hkeR8VUtAeFoSYbKedZNsDvCN',\n {\n headers: {\n 'x-api-key': 'your-api-key',\n },\n }\n )\n).json();\nconsole.log(JSON.stringify(price, null, 2));\n\n​Price Response\nHere is the sample response, notice a few details here:\n\nThe usdPrice is the only price.\nThe decimals response is helpful to display price information on the UI.\nThe blockId can be used to verify the recency of the price.\nThe priceChange24h is the 24-hour price change as a percentage (e.g. 1.29 means +1.29%, -3.47 means -3.47%), not a 0-1 fraction.\n\n{\n \"JUPyiwrYJFskUPiHa7hkeR8VUtAeFoSYbKedZNsDvCN\": {\n \"usdPrice\": 0.4056018512541055,\n \"blockId\": 348004026,\n \"decimals\": 6,\n \"priceChange24h\": 0.5292887924920519\n },\n \"So11111111111111111111111111111111111111112\": {\n \"usdPrice\": 147.4789340738336,\n \"blockId\": 348004023,\n \"decimals\": 9,\n \"priceChange24h\": 1.2907622140620008\n }\n}\n\n​Limitations\nQuery limits\n\nYou can query up to 50 ids at once.\n\nIf the price of a token cannot be found\nTokens without a reliable price are omitted entirely from the response. The mint has no key in the returned object, rather than a key with a null value, and there is no error or per-mint reason. To find which of your requested mints were dropped, compare your requested ids against the keys that were returned:\nconst ids = [\n 'So11111111111111111111111111111111111111112',\n 'EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v',\n];\n\nconst price = await (\n await fetch(`https://api.jup.ag/price/v3?ids=${ids.join(',')}`, {\n headers: { 'x-api-key': 'your-api-key' },\n })\n).json();\n\nconst missing = ids.filter((id) => !(id in price));\n\nA token is typically omitted when:\n\nIt has not been traded recently, in the last 7 days.\nThe aforementioned heuristics flag the price as unreliable, where certain combinations of factors indicate potential issues with price reliability or market health.\n\nFor additional context, you can cross reference a token’s audit.isSus field in the Tokens API V2. Note that audit.isSus is only present when a token has been flagged suspicious, so its absence is not a guarantee of safety. Most tokens omitted from the price response are simply untraded or illiquid rather than flagged.\nV3 simplifies pricing\n\nV3 returns a single accurate price per token, eliminating ambiguity from V2’s multiple price fields that led to inconsistent interpretations across platforms.\nPrice accuracy is maintained through heuristics that eliminate outliers, providing one stable price source.\nIf you need the additional data that V2 provided, use the /quote endpoint of the Swap API to derive equivalent values (see how Price API V2 pricing was derived).\nWas this page helpful?","tokens":1324,"squid":"spider-02","role":"Liquidity Spider","at":1791348244199,"hash":"2e77b29cd3d49a934a0cf84065c967af05c79035"}
{"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 1\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 What Solidity try/catch actually catches\n\n Code Wizards\n\n 1\n\n 121\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 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 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 Eager require evaluation is unexpected\n\n Language Design\n\n 2\n\n 94\n\n Aug 4\n\n Want to read more? Browse other topics in Code Wizards or view latest topics.","tokens":1602,"squid":"spider-05","role":"Spec Spider","at":1791348252390,"hash":"80a514e13e516dedbbcef2e6e08f0201c3baa7d3"}
{"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 1\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 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 What Solidity try/catch actually catches\n\n Code Wizards\n\n 1\n\n 121\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 Core Solidity: Feedback from porting Uniswap v2\n\n Language Design\n\n 2\n\n 192\n\n Jun 9\n\n Want to read more? Browse other topics in Code Wizards or view latest topics.","tokens":1604,"squid":"spider-05","role":"Spec Spider","at":1791348265318,"hash":"f06a1e380a165e1b76036a5701c47422522af369"}
{"url":"https://developers.jup.ag/docs/guides/how-to-get-token-price","domain":"developers.jup.ag","title":"How to Get Token Prices on Solana - Jupiter Developers","text":"​TL;DR\nJupiter’s Price API is the standard way to get token prices on Solana. One API call returns real-time USD prices for up to 50 tokens. The same pricing data powers jup.ag and is used by Phantom, Solflare, and most Solana apps.\nBase URL: https://api.jup.ag\nVideo walkthrough + source code: Watch the video walkthrough and grab the demo app source code on GitHub.\n\n​Prerequisites\n\nGet an API key at Portal\nAll requests require the x-api-key header\n\n​Quick start\ncurl -X GET \"https://api.jup.ag/price/v3?ids=So11111111111111111111111111111111111111112\" \\\n -H \"x-api-key: YOUR_API_KEY\"\n\nResponse:\n{\n \"So11111111111111111111111111111111111111112\": {\n \"createdAt\": \"2024-06-05T08:55:25.527Z\",\n \"liquidity\": 621679197.67,\n \"usdPrice\": 147.48,\n \"blockId\": 348004023,\n \"decimals\": 9,\n \"priceChange24h\": 1.29\n }\n}\n\n​When you need this\nYou’re building something that needs Solana token prices:\n\nWallet — Show portfolio value in USD\nTrading interface — Display current token prices\nDeFi app — Calculate swap values, collateral ratios\nTrading bot — Price-based execution logic\nAnalytics — Track token performance\n\nCommon searches that lead here:\n\n“solana token price api”\n“get sol price usd”\n“crypto price api solana”\n“jupiter price feed”\n\n​Why Jupiter\nGetting accurate on-chain prices is hard:\n\nLiquidity fragmented across 20+ DEXs\nLow-liquidity tokens have unreliable prices\nWash trading and price manipulation are common\n\nJupiter solves this by:\n\nAggregating swap data across all Solana DEXs\nUsing heuristics to filter manipulated prices\nValidating against organic trading activity\nProviding the same prices used on jup.ag\n\nJupiter Price API is the standard pricing source for Solana applications.\n\n​API Reference\nBase URL: https://api.jup.ag\nEndpointDescriptionGET /price/v3?ids={mints}Get prices for up to 50 tokens\nParameters:\n\nids (required): Comma-separated mint addresses\n\n​Code examples\n​Get price for a single token\ncurl -X GET \"https://api.jup.ag/price/v3?ids=So11111111111111111111111111111111111111112\" \\\n -H \"x-api-key: YOUR_API_KEY\"\nconst response = await fetch(\n 'https://api.jup.ag/price/v3?ids=So11111111111111111111111111111111111111112',\n {\n headers: {\n 'x-api-key': 'YOUR_API_KEY'\n }\n }\n);\n\nif (!response.ok) {\n throw new Error(`HTTP ${response.status}: ${response.statusText}`);\n}\n\nconst prices = await response.json();\nconst solPrice = prices['So11111111111111111111111111111111111111112'].usdPrice;\nconsole.log(`SOL: $${solPrice}`);\nimport requests\n\nresponse = requests.get(\n 'https://api.jup.ag/price/v3',\n params={'ids': 'So11111111111111111111111111111111111111112'},\n headers={'x-api-key': 'YOUR_API_KEY'}\n)\nresponse.raise_for_status()\nprices = response.json()\nsol_price = prices['So11111111111111111111111111111111111111112']['usdPrice']\nprint(f\"SOL: ${sol_price}\")\n\n​Get prices for multiple tokens\ncurl -X GET \"https://api.jup.ag/price/v3?ids=So11111111111111111111111111111111111111112,JUPyiwrYJFskUPiHa7hkeR8VUtAeFoSYbKedZNsDvCN,EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v\" \\\n -H \"x-api-key: YOUR_API_KEY\"\nconst mints = [\n 'So11111111111111111111111111111111111111112', // SOL\n 'JUPyiwrYJFskUPiHa7hkeR8VUtAeFoSYbKedZNsDvCN', // JUP\n 'EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v' // USDC\n];\n\nconst response = await fetch(\n `https://api.jup.ag/price/v3?ids=${mints.join(',')}`,\n {\n headers: { 'x-api-key': 'YOUR_API_KEY' }\n }\n);\n\nconst prices = await response.json();\n\nfor (const [mint, data] of Object.entries(prices)) {\n console.log(`${mint}: $${data.usdPrice}`);\n}\nimport requests\n\nmints = [\n 'So11111111111111111111111111111111111111112', # SOL\n 'JUPyiwrYJFskUPiHa7hkeR8VUtAeFoSYbKedZNsDvCN', # JUP\n 'EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v' # USDC\n]\n\nresponse = requests.get(\n 'https://api.jup.ag/price/v3',\n params={'ids': ','.join(mints)},\n headers={'x-api-key': 'YOUR_API_KEY'}\n)\nprices = response.json()\n\nfor mint, data in prices.items():\n print(f\"{mint}: ${data['usdPrice']}\")\n\n​Calculate portfolio value\nasync function getPortfolioValue(holdings) {\n // holdings = { mint: amount_in_tokens }\n const mints = Object.keys(holdings);\n\n const response = await fetch(\n `https://api.jup.ag/price/v3?ids=${mints.join(',')}`,\n { headers: { 'x-api-key': 'YOUR_API_KEY' } }\n );\n const prices = await response.json();\n\n let totalValue = 0;\n for (const [mint, amount] of Object.entries(holdings)) {\n const price = prices[mint]?.usdPrice ?? 0;\n totalValue += amount * price;\n }\n\n return totalValue;\n}\n\n// Example\nconst value = await getPortfolioValue({\n 'So11111111111111111111111111111111111111112': 10, // 10 SOL\n 'JUPyiwrYJFskUPiHa7hkeR8VUtAeFoSYbKedZNsDvCN': 1000 // 1000 JUP\n});\nconsole.log(`Portfolio: $${value.toFixed(2)}`);\n\n​Response format\n​TypeScript types\ninterface PriceResponse {\n [mintAddress: string]: {\n createdAt: string; // When the token was minted/created (fixed date for legacy tokens like SOL, USDC)\n liquidity: number; // Total liquidity in USD\n usdPrice: number;\n blockId: number; // Solana block when price was computed\n decimals: number;\n priceChange24h: number; // 24h change as percentage\n };\n}\n\n​Example response\n{\n \"So11111111111111111111111111111111111111112\": {\n \"createdAt\": \"2024-06-05T08:55:25.527Z\",\n \"liquidity\": 621679197.67,\n \"usdPrice\": 147.48,\n \"blockId\": 348004023,\n \"decimals\": 9,\n \"priceChange24h\": 1.29\n },\n \"JUPyiwrYJFskUPiHa7hkeR8VUtAeFoSYbKedZNsDvCN\": {\n \"createdAt\": \"2024-06-07T10:56:42.584Z\",\n \"liquidity\": 3036749.38,\n \"usdPrice\": 0.85,\n \"blockId\": 348004026,\n \"decimals\": 6,\n \"priceChange24h\": 2.15\n }\n}\n\nFields:\n\ncreatedAt — When the token was minted or created (fixed date for legacy tokens like SOL, USDC that predate the API)\nliquidity — Total liquidity in USD across all pools\nusdPrice — Current price in USD\nblockId — Solana block ID (verify price recency)\ndecimals — Token decimals (for display formatting)\npriceChange24h — 24h price change as percentage\n\n​Error responses\nToken not found or no price available:\n{\n \"So11111111111111111111111111111111111111112\": {\n \"createdAt\": \"2024-06-05T08:55:25.527Z\",\n \"liquidity\": 621679197.67,\n \"usdPrice\": 147.48,\n \"blockId\": 348004023,\n \"decimals\": 9,\n \"priceChange24h\": 1.29\n }\n // Unknown token simply missing from response\n}\n\nInvalid API key (401):\n{\n \"code\": 401,\n \"message\": \"Unauthorized\"\n}\n\nRate limited (429):\n{\n \"message\": \"Rate limit exceeded\"\n}\n\n​How pricing works\n\nJupiter tracks the last swap price across all Solana transactions\nPrices chain outward from trusted tokens (SOL, USDC) with oracle data\nMultiple heuristics filter unreliable prices:\n\nAsset origin and launch method\nMarket liquidity depth\nHolder distribution\nTrading patterns\nOrganic score validation\n\nThis prevents manipulated or artificial prices from being returned.\n\n​Limitations\nLimitValueMax tokens per request50Price availabilityTokens traded in last 7 daysHistorical pricesNot available (current only)\n\n​Common questions\nWhy is a token returning no price?The token is missing from the response when:\nIt hasn’t been traded in 7+ days\nIt fails reliability heuristics (suspicious activity)\nIt’s flagged via organic score validation\nCross-reference with Tokens API audit.isSus field.How fresh are the prices?Prices update in real-time based on swap activity. The blockId field tells you exactly which Solana block the price was computed from.Can I get historical prices?No, Price API V3 provides current prices only. For historical data, poll the API and store results yourself.What about price for token pairs (not USD)?Price API returns USD only. To get token-pair prices (e.g., JUP/SOL), fetch both USD prices and divide.How do I handle missing prices in my app?const price = prices[mint]?.usdPrice;\nif (price === undefined) {\n // Token has no reliable price\n // Show \"Price unavailable\" or fallback\n}\n\nNeed token metadata too? Get token names, logos, and verification status with the Token Information API.\n\n​Next steps\n\nPrice API Reference — Full endpoint schema\nGet Token Information — Metadata, verification, organic score\nPortal — Get your API key\nJupiter Dev Notifications — API updates and announcements\nWas this page helpful?","tokens":2011,"squid":"spider-02","role":"Liquidity Spider","at":1791348269150,"hash":"7fa1730d1e16baaeeb63340e06d991b5c99c21ca"}
{"url":"https://www.metaplex.com/docs/smart-contracts/bubblegum-v2/faq","domain":"metaplex.com","title":"FAQ - Bubblegum V2 - Metaplex","text":"SummaryThis page answers the most common questions about Bubblegum V2 compressed NFTs, including costs, transaction errors, and differences from V1.Find required parameters for leaf-mutating instructions using getAssetWithProofResolve \"Transaction too large\" errors with truncateCanopy or Address Lookup TablesUnderstand tree costs and capacity before creating a treeBubblegum V2 is not backward-compatible with V1 trees or decompressioncNFTs can inherit seller fee basis points from an MPL-Core collection's Royalties pluginWhat is Bubblegum V2?Bubblegum V2 is a new iteration of the Bubblegum program that introduces several improvements and new features. It is part of the known Bubblegum program, but the instructions and data structures are different. With Bubblegum V2 cNFTs are grouped into collections using MPL-Core Collections instead of Metaplex Token Metadata Collections. It also introduces new features like freezing, thawing, and soulbound NFTs and additional features like:Freeze and Thaw Functionality: Project creators can now freeze and thaw cNFTs, providing greater control over their assets for various use cases such as preventing transfers during specific events or implementing vesting mechanics.MPL-Core Collections Integration: Bubblegum V2 NFTs can now be added to MPL-Core collections instead of being limited to token metadata collections, allowing for greater flexibility and integration with the broader Metaplex ecosystem.Royalty Enforcement: Since Bubblegum V2 is using MPL-Core Collections, it is possible to enforce royalties on cNFTs e.g. using a ProgramDenyList.Soulbound NFTs: cNFTs can now be made soulbound (non-transferrable), permanently binding them to their owner's wallet. This is perfect for credentials, proof of attendance, identity verification, and more. It requires the PermanentFreezeDelegate plugin to be enabled on the collection.Allow Permanent Transfer: The permanent transfer delegate can now transfer the cNFT to a new owner without interaction of the leaf owner if the PermanentTransferDelegate plugin is enabled on the collection.How do I find the arguments needed for operations such as transfer, delegate, burn, etc? Whenever we use an instruction that ends up replacing a leaf in the Bubblegum Tree — such as transfer, delegate, burn, etc. — the program requires a bunch of parameters that are used to ensure the current leaf is valid and can be updated. This is because the data of Compressed NFTs is not available inside onchain accounts and therefore additional parameters such as the Proof, the Leaf Index, the Nonce and more are required for the program to fill the pieces.All of that information can be retrieved from the Metaplex DAS API using both the getAsset and the getAssetProof RPC methods. However, the RPC responses from these methods and the parameters expected by the instructions are not exactly the same and parsing from one to the other is not trivial.Fortunately, our SDKs provide a helper method that will do all the heavy lifting for us, as we can see in the code examples below. It accepts the Asset ID of the Compressed NFT and returns a bunch of parameters that can be directly injected into instructions that replace the leaf — such as burn, transfer, update, etc.That being said, if you ever needed to do that parsing yourself, here is a quick breakdown of the parameters expected by the instructions and how to retrieve them from the Metaplex DAS API. Here we will assume the result of the getAsset and getAssetProof RPC methods are accessible via the rpcAsset and rpcAssetProof variables respectively.Leaf Owner: Accessible via rpcAsset.ownership.owner.Leaf Delegate: Accessible via rpcAsset.ownership.delegate and should default to rpcAsset.ownership.owner when null.Merkle Tree: Accessible via rpcAsset.compression.tree or rpcAssetProof.tree_id.Root: Accessible via rpcAssetProof.root.Data Hash: Accessible via rpcAsset.compression.data_hash.Creator Hash: Accessible via rpcAsset.compression.creator_hash.Nonce: Accessible via rpcAsset.compression.leaf_id.Index: Accessible via rpcAssetProof.node_index - 2^max_depth where max_depth is the maximum depth of the tree and can be inferred from the length of the rpcAssetProof.proof array.Proof: Accessible via rpcAssetProof.proof.Metadata: Currently needs to be reconstructed from various fields in the rpcAsset response.Get parameters for instructions that replace leavesThe Bubblegum Umi library provides a getAssetWithProof helper method that fits the description above. Here's an example of how to use it using the transfer instruction. Note that, in this case, we override the leafOwner parameter as it needs to be a Signer and assetWithProof gives us the owner as a Public Key.Depending on Canopy size it can make sense to use the truncateCanopy: true parameter of the getAssetWithProof helper. It fetches the tree config and truncates not required proofs. This will help if your transaction sizes grow too large.import { getAssetWithProof, transfer } from '@metaplex-foundation/mpl-bubblegum'\n\nconst assetWithProof = await getAssetWithProof(umi, assetId, \n// { truncateCanopy: true } // optional to prune the proofs \n);\nawait transferV2(umi, {\n ...assetWithProof,\n leafOwner: leafOwnerA, // As a signer.\n newLeafOwner: leafOwnerB.publicKey,\n}).sendAndConfirm(umi);\n\nawait transferV2(umi, {\n ...assetWithProof,\n leafOwner: leafOwnerA, // As a signer.\n newLeafOwner: leafOwnerB.publicKey,\n}).sendAndConfirm(umi)\nHow to Resolve \"Transaction too large\" Errors When performing leaf-replacing operations like transfers or burns, you may encounter a \"Transaction too large\" error. To resolve this, consider the following solutions:Use the truncateCanopy option: Pass { truncateCanopy: true } to the getAssetWithProof function:const assetWithProof = await getAssetWithProof(umi, assetId, \n { truncateCanopy: true }\n);\nThis option retrieves the Merkle Tree configuration and optimizes the assetWithProof by removing unnecessary proofs based on the Canopy. While it adds an extra RPC call, it significantly reduces the transaction size.Utilize versioned transactions and Address Lookup Tables: Another approach is to implement versioned transactions and Address Lookup Tables. This method can help manage transaction size more effectively.By applying these techniques, you can overcome transaction size limitations and successfully execute your operations.How much does it cost to create a compressed NFT tree? Tree costs depend on the configured depth and canopy. Here are some reference costs:Tree CapacityDepthCanopyCost (SOL)Cost per cNFT16,384148~0.34~0.000021,048,5762013~8.50~0.0000116,777,2162415~26.12~0.000007These costs are the one-time rent for the tree account. Once paid, minting cNFTs into the tree only costs transaction fees.What is the difference between Bubblegum V1 and V2? Bubblegum V2 adds several new features compared to V1:Freeze/Thaw: Ability to freeze and thaw cNFTs via leaf delegates or permanent freeze delegatesSoulbound NFTs: Make cNFTs non-transferable using the permanent freeze delegateMPL-Core Collections: Uses MPL-Core collections instead of Token Metadata collectionsRoyalty Enforcement: Enforced royalties via MPL-Core collection pluginsPermanent Delegates: Permanent transfer, freeze, and burn delegates at the collection levelLeafSchemaV2: New leaf format with collection hash, asset data hash, and flagsV1 trees and V2 trees are not interchangeable. V2 trees require V2 instructions.Do I need a special RPC provider? Yes. Compressed NFTs require an RPC provider that supports the Metaplex DAS API for indexing and fetching cNFT data. Not all RPCs support this extension. See the RPC Providers page for a list of compatible providers.Can I decompress a cNFT back to a regular NFT? Decompression is only available for Bubblegum V1 assets. Bubblegum V2 does not support decompression. V2 cNFTs remain compressed.How many cNFTs can I store in one tree? The maximum number of cNFTs is 2^maxDepth. A depth-14 tree holds 16,384 cNFTs, depth-20 holds ~1 million, depth-24 holds ~16 million, and depth-30 holds over 1 billion. See the tree capacity table for all options.Can a cNFT inherit royalties from its MPL-Core collection? Yes. When minting into an MPL-Core collection that has the Royalties plugin, you can omit metadata.sellerFeeBasisPoints (or pass SELLER_FEE_BASIS_POINTS_INHERIT, 65535). The leaf stores that sentinel on-chain. DAS puts the collection-resolved rate on royalty.basis_points / creators for display, and the leaf sentinel on royalty.basis_points_raw / creators_raw (with royalty.inherited: true).DAS providers without inherited royalty supportA DAS provider that does not support inherited royalties yet returns the leaf sentinel on royalty.basis_points (65535) with empty creators, so wallets and marketplaces display a 655.35% royalty (roughly 650%) with no creators. The onchain asset is correct. See Responses from DAS providers without inherited royalty support.Requirements:The collection must have both the BubblegumV2 and Royalties plugins.metadata.creators must be an empty array when using inherited seller fees.Using getAssetWithProof:metadata — mirrors DAS main / display fields (sellerFeeBasisPoints is the collection-resolved rate when inherited).currentMetadata — leaf-canonical MetadataArgsV2Args for write instructions (sentinel when inherited).sellerFeeBasisPointsRaw / creatorsRaw — optional leaf siblings; set when inherited / DAS provides _raw.inherited — sugar for inherit detection.rpcAsset — full DAS response (royalty.basis_points / creators for display).When calling updateMetadataV2, spread ...assetWithProof so currentMetadata is the leaf state. For instructions that take a leaf metadata arg, pass assetWithProof.currentMetadata.Collection management:A cNFT with inherited seller fees cannot be removed from its collection until you update to an explicit sellerFeeBasisPoints.Moving to another collection is allowed when the destination has the Royalties plugin.See Reading Inherited Royalties for clients reading DAS, Minting — Inheriting royalties, Updating cNFTs, and Managing Collections for full examples.","tokens":2535,"squid":"dotcat","role":"Tooling Spider","at":1791348271565,"hash":"7b859984720a6070fee80a255f98665721295b68"}
{"url":"https://ethresear.ch/t/mev-burn-a-simple-design/15590/30","domain":"ethresear.ch","title":"MEV burn—a simple design - Economics - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 8\n\n 3\n\n 2\n\n 2\n\n 2\n\n read \n\n 17\n min\n\n May 2023\n\n 28 / 28\n\n Jun 2024\n\n Jun 2024\n\n Load more posts above\n\n post by JustinDrake on May 16, 2023\n\n post by ballsyalchemist on May 16, 2023\n\n post by CalabashSquash on May 21, 2023\n\n post by Pintail on May 25, 2023\n\n post by JustinDrake on May 25, 2023\n\n post by voidp on May 25, 2023\n\n post by JustinDrake on May 26, 2023\n\n post by wanify on May 27, 2023\n\n post by bertmiller on Jun 3, 2023\n\n post by JustinDrake on Jun 3, 2023\n\n post by bertmiller on Jun 4, 2023\n\n 2 months later\n\n post by PatrickAlphaC on Jul 27, 2023\n\n post by jessiepark on Aug 4, 2023\n\n 2 months later\n\n post by ethDreamer on Oct 15, 2023\n\n post by JustinDrake on Oct 16, 2023\n\n post by ethDreamer on Oct 16, 2023\n\n post by vuittont60 on Oct 20, 2023\n\n 11 days later\n\n post by namayama on Oct 31, 2023\n\n namayama\n\nI believe the proposer can ‘bribe’ builders to delay their bids using a trustless L1 contract that pays winning builders a share of fees.\nThe proposer deposits collateral into a BribeContract. BribeContract allows winning block builders to withdraw X% * (base_fee - base_fee_floor) for any block produced by the proposer.\nBuilders, if they know this contract exists, will rationally wait until base_fee_floor has been set to submit their bids (or otherwise make their bid privately in advance).\nMore advanced versions using validator withdrawal contracts might be possible as well.\n\nProposer/builder collusion only requires builders delay their bid (easy). Builder/builder collusion requires builders withhold their bid entirely (hard).\n\n post by Nero_eth on Nov 1, 2023\n\n Nero_eth\n\nIn this example the proposers wouldn’t care as long as they receive their selected bid minus the burn. If a majority of the attestors are fine with attesting to a block that burns at least 5 ETH, then it wouldn’t matter if another builder bids 6 ETH after the burn floor was set. Only if the proposer thinks that the 6 ETH came before the burn floor was set, he’d would need to also choose a bid that burns at least 6 ETH.\nI think the main collusion problem is not setting the burn floow, which would be carried out by colluding builders. Though, this doesn’t get worse compared to the situation today where colluding builders could pressure down the mev boost payments and increase their own profit share as a group.\n\n 8 months later\n\n post by aelowsson on Jun 26, 2024\n\n aelowsson\n\nHighlighting that this issue has now been resolved by incorporating the staking metagame in the analysis.\n\n Powered by Discourse","tokens":647,"squid":"spider-04","role":"Research Spider","at":1791348280754,"hash":"9820313afed62d47181596373ce1729791572037"}
{"url":"https://developers.jup.ag/docs/lend","domain":"developers.jup.ag","title":"Jupiter Lend Overview - Jupiter Developers","text":"The Jupiter Lend API and SDK give you access to Earn (deposit-and-earn) and Borrow (collateralised borrowing) on Solana.\nDeposit into Earn vaults to earn yield, or use assets as collateral in Borrow markets to take out loans. The SDK and API provide deposits, withdrawals, borrows, and repayments as ready-made transactions or as raw instructions for CPI and custom flows.\n\n​Integrate Jupiter Earn / Borrow\n\n​Jupiter Lend Products\n\n​Advanced Integration\n\n​Getting Started\nSet up your development environment:\n1Install DependenciesAdd the Jupiter Lend TypeScript SDK and Solana web3.js to your dependencies.npm i @jup-ag/lend @solana/web3.js\nJupiter Lend SDK is built on top of @solana/web3.js for RPC communication and transaction construction.2Setup the RPCimport { Connection } from \"@solana/web3.js\";\n\nconst connection = new Connection(\n \"https://api.mainnet-beta.solana.com\",\n {\n commitment: \"confirmed\",\n }\n);\nPublic RPC endpoints are rate-limited and not recommended for production use.Use a dedicated RPC provider such as Helius, Triton, or Alchemy for improved reliability and performance.3Create or Import WalletChoose a method to create or import a wallet for signing transactions.Alternatively, create a wallet using a browser wallet provider like Jupiter WalletCreate Wallet with Solana CLIUse the Solana CLI to generate a new keypair file.solana-keygen new -o wallet.json\nGenerate Keypair ProgrammaticallyGenerate a new keypair programmatically using the Solana web3.js.import { Keypair } from \"@solana/web3.js\";\n\nconst keypair = Keypair.generate();\nconsole.log(\"Public Key:\", keypair.publicKey.toBase58());\nLoad Wallet from Local Keypair FileImport a wallet from an existing keypair file.import { Keypair } from \"@solana/web3.js\";\nimport fs from \"fs\";\nimport path from \"path\";\n\nfunction loadKeypair(filePath: string): Keypair {\n const resolvedPath = path.resolve(filePath);\n const secret = JSON.parse(fs.readFileSync(resolvedPath, \"utf8\"));\n return Keypair.fromSecretKey(new Uint8Array(secret));\n}\n\nconst userKeypair = loadKeypair(\"/path/to/wallet.json\");\nconsole.log(\"Public Key:\", userKeypair.publicKey.toBase58());\nImport Private KeyImport a private key exported from a browser wallet (base58-encoded string).import { Keypair } from \"@solana/web3.js\";\nimport bs58 from \"bs58\";\n\nconst privateKey = \"YOUR_BASE58_PRIVATE_KEY\"; // exported from your browser wallet\nconst userKeypair = Keypair.fromSecretKey(bs58.decode(privateKey));\nconsole.log(\"Public Key:\", userKeypair.publicKey.toBase58());\nNever expose or commit private keys to version control. Use secure key management in production environments.Was this page helpful?","tokens":660,"squid":"spider-02","role":"Liquidity Spider","at":1791348282266,"hash":"01dd9183bfae3bbfff22734e23165c71bd306f7c"}
{"url":"https://ethresear.ch/t/mev-burn-a-simple-design/15590/4","domain":"ethresear.ch","title":"MEV burn—a simple design - Economics - Ethereum Research","text":"Economics\n\n mev\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n May 2023\n\n 4 / 28\n\n May 2023\n\n Jun 2024\n\n post by JustinDrake on May 15, 2023\n\n post by CometShock on May 15, 2023\n\n post by JustinDrake on May 15, 2023\n\n JustinDrake\n\nWe’re not trying to discourage proposers from receiving private bids! In the analysis of MEV burn I would assume that all proposers are willing to receive private bids \n\nIf all bidders capable of extracting a specific piece of MEV collude then it’s game over, with or without collusion with the proposer, as well as with or without MEV burn. As argued in the “colluding builders” section under “late bidding”, a cabal of colluding builders can keep all the MEV for themselves (e.g. equally split the MEV among themselves instead of racing towards zero margins). The good news is that 100% collusion within a permissionless set of competing builders is hard—the equilibrium is a race to zero where individual builders defect.\n\nThe design is secure under an honest majority of attesters, similar to EIP-1559. (See the section titled “honest majority” under “technical similarities with EIP-1559”.)\n\nI disagree with this premise—IMO it’s likely net positive for validators to embrace the redistribution of MEV. See the section titled “side note for validators” under “staking APR”. The crux of the argument is that ETH-denominated returns are tied to the cost of money, and USD-denominated returns (as well as the USD-denominated principal) should actually grow.\n\n post by CometShock on May 15, 2023\n\n CometShock\n\nApologies, I should have made my statement clearer. The emphasis is not that builders collude with each other builder, but rather each individual builder is incentivized to collude with the proposer by running private bids. It’s game theoretically optimal for each individual builder to do so, as you maintain timeliness while obscuring your payload base fee floor to the outside attesters (this reduces the potential payload base fee floor). Additionally, as more individual builders elect to privately bid, they all share the same benefit of an even lower payload base fee floor. (Edit, previously: Additionally, once each individual builder elects to…)\nIf the payload base fee floor is lowered due to obscuring the skilled bids, naturally the builder can bid marginally more (ex: half of recovered base fee) payload tip to the proposer - making it game theoretically optimal for the proposer to accept private bids. From the outside, this looks like all builders are colluding amongst each other as well as with the proposer — but in reality it’s just optimal for all builder-proposer relationships to do this on an individual basis and it scales in effectiveness as more builders participate. And the end result is heavily suppressed payload base fee floors. The only party who would intentionally defect from this structure would be an unconfident builder who wants to redistribute as much as they can (but as mentioned before, if they’re unconfident, they’re likely not skilled enough to capture much of the MEV spike anyways. So still suppressed payload base fee floor).\nAll this to say that it if private bidding is possible, it seems this proposal is effective at burning easy, low-skill MEV, but is ineffective at burning anything outside of that set.\n\n Burn incentives in MEV pricing auctions\n\n Sealed execution auction\n\n MEV resistant dynamic pricing auction of execution proposal rights\n\n Fork-Choice enforced Inclusion Lists (FOCIL): A simple committee-based inclusion list proposal\n\n Practical endgame on issuance policy\n\n post by terence on May 15, 2023\n\n terence\n\nWouldn’t D be the same time proposer receive those bids as well? If yes, then I think it can be close to the end of the slot as possible.\nCorrect me If I am wrong, there will be a new gossip network called builder_bids and the builder will broadcast the bids there. Attesters and proposers will all be listening there.\nSome followup questions\n\nHow are the attesters chosen for duty? size? new reward/penalty?\nIs this an extension of the forkchoice rule where the second highest bid can’t be head? or an extension of block validity condition where the second highest bid block can’t be valid?\n\n post by JustinDrake on May 15, 2023\n\n JustinDrake\n\nBuilders do not directly benefit from a low payload base fee floor Naively (i.e. assuming no kickback from the proposer) builder profit margins are invariant to the payload base fee.\n\nThe builder does not “recover” anything from a lower payload base fee. They don’t get the payload base fee, with or without MEV burn.\n\nI call this “commoditised MEV”.\n\nNotice that a public-good builder (e.g. a hypothetical “ultra sound builder” ) that wants to set a baseline payload base fee floor wouldn’t necessarily need to be good at capturing MEV spikes. They only need to be good at predicting what the payload base fee floor could be, and then bidding just under that value.\n\nThe proposer is guaranteed to receive by the start of the slot all the bids broadcast D seconds before the start of the slot.\n\nExactly! There will be a “bid pool” which is a new p2p gossip channel for bids. Builders broadcast signed bids, and validators listen.\n\nI would simply reuse the attester committee for the given slot. With SSF the attester committee could be the whole validator set. The same attestation rewards and penalties can also be reused, without modification.\n\nYes, the payload base fee floor attestation rule is a modification to the fork choice rule (not a change to the state transition function).\n\n post by terence on May 15, 2023\n\n post by CometShock on May 15, 2023\n\n post by JustinDrake on May 16, 2023\n\n post by ballsyalchemist on May 16, 2023\n\n post by CalabashSquash on May 21, 2023\n\n post by Pintail on May 25, 2023\n\n post by JustinDrake on May 25, 2023\n\n post by voidp on May 25, 2023\n\n post by JustinDrake on May 26, 2023\n\n post by wanify on May 27, 2023\n\n post by bertmiller on Jun 3, 2023\n\n post by JustinDrake on Jun 3, 2023\n\n post by bertmiller on Jun 4, 2023\n\n 2 months later\n\n post by PatrickAlphaC on Jul 27, 2023\n\n Load more posts below","tokens":1532,"squid":"spider-04","role":"Research Spider","at":1791348291023,"hash":"f7f88d1747aa94d1e5fa76c255a7462859c8f0f8"}
{"url":"https://www.metaplex.com/docs/smart-contracts/bubblegum-v2/sdk/javascript","domain":"metaplex.com","title":"JavaScript SDK - Bubblegum V2 - Metaplex","text":"The Bubblegum V2 JavaScript SDK (@metaplex-foundation/mpl-bubblegum) is the recommended TypeScript/JavaScript library for creating and managing compressed NFTs on Solana. Built on the Umi framework, it provides type-safe functions for all Bubblegum V2 operations and includes the DAS API plugin automatically. What You'll LearnThis SDK reference covers:Setting up Umi with the Bubblegum V2 pluginCreating merkle trees for storing cNFTsMinting, transferring, burning, and updating cNFTsDelegating, freezing, and verifying creatorsFetching cNFTs using the DAS APIHandling transaction size limits and common errorsSummaryThe Bubblegum V2 JavaScript SDK wraps all MPL-Bubblegum V2 program instructions in a type-safe API and includes the DAS API plugin for reading cNFT data.Install: npm install @metaplex-foundation/mpl-bubblegum @metaplex-foundation/umi-bundle-defaultsRegister with Umi using .use(mplBubblegum()) — the DAS API plugin is included automaticallyUse getAssetWithProof before any write operation (transfer, burn, update, delegate, freeze, verify)Applies to Bubblegum V2 (MPL-Bubblegum 5.x) — not compatible with V1 treesQuick StartJump to: Setup · Create Tree · Mint · Transfer · Burn · Update · Delegate · Collections · Freeze · Verify Creators · Fetch · Errors · Quick ReferenceInstall dependencies: npm install @metaplex-foundation/mpl-bubblegum @metaplex-foundation/umi-bundle-defaultsCreate a Umi instance with .use(mplBubblegum())Create a Bubblegum tree with createTreeMint cNFTs with mintV2; use getAssetWithProof before any subsequent write operationInstallationTerminalnpm install @metaplex-foundation/mpl-bubblegum @metaplex-foundation/umi-bundle-defaults\nTypeDoc API ReferenceFull generated API documentation for the SDK.npm PackagePackage on npmjs.com with version history.Umi SetupThe mplBubblegum plugin registers all Bubblegum V2 instructions and the DAS API plugin with your Umi instance.setup.tsimport { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\nimport { mplBubblegum } from '@metaplex-foundation/mpl-bubblegum'\nimport { keypairIdentity } from '@metaplex-foundation/umi'\n\nconst umi = createUmi('https://api.devnet.solana.com')\n .use(mplBubblegum())\n .use(keypairIdentity(yourKeypair))\nCreate a Bubblegum TreecreateTree allocates a new merkle tree on-chain and registers it as a Bubblegum V2 tree. Tree parameters are permanent — choose them carefully before creating.create-tree.tsimport { createTree } from '@metaplex-foundation/mpl-bubblegum'\nimport { generateSigner } from '@metaplex-foundation/umi'\n\nconst merkleTree = generateSigner(umi)\n\nawait createTree(umi, {\n merkleTree,\n maxDepth: 14, // tree holds 2^14 = 16,384 cNFTs\n maxBufferSize: 64, // concurrent writes per block\n canopyDepth: 10, // cached upper nodes (reduces proof size in txs)\n public: false, // false = only tree creator/delegate can mint\n}).sendAndConfirm(umi)\n\nconsole.log('Tree address:', merkleTree.publicKey)\npublic: false means only the tree creator (or an approved tree delegate) can mint from the tree. Set public: true to allow anyone to mint. See Create Trees for tree size cost estimates.Mint a Compressed NFTMint Without CollectionmintV2 creates a new cNFT leaf in the specified tree.mint-cnft.tsimport { mintV2 } from '@metaplex-foundation/mpl-bubblegum'\nimport { none } from '@metaplex-foundation/umi'\n\nawait mintV2(umi, {\n leafOwner: umi.identity.publicKey,\n merkleTree: merkleTree.publicKey,\n metadata: {\n name: 'My Compressed NFT',\n uri: 'https://example.com/my-nft.json',\n sellerFeeBasisPoints: 500, // 5% royalty\n collection: none(),\n creators: [{ address: umi.identity.publicKey, verified: false, share: 100 }],\n },\n}).sendAndConfirm(umi)\nMint to a CollectionPass a coreCollection to associate the cNFT with an MPL-Core collection. The collection must have the BubblegumV2 plugin enabled.mint-to-collection.tsimport { mintV2 } from '@metaplex-foundation/mpl-bubblegum'\nimport { publicKey } from '@metaplex-foundation/umi'\n\nawait mintV2(umi, {\n leafOwner: umi.identity.publicKey,\n merkleTree: merkleTree.publicKey,\n metadata: {\n name: 'My Collection cNFT',\n uri: 'https://example.com/my-nft.json',\n sellerFeeBasisPoints: 500,\n collection: publicKey('YourCollectionAddressHere'),\n creators: [{ address: umi.identity.publicKey, verified: false, share: 100 }],\n },\n coreCollection: publicKey('YourCollectionAddressHere'),\n}).sendAndConfirm(umi)\nInherit royalties from the collectionWhen coreCollection is set, the SDK's mintV2 helper defaults to inherited royalties if metadata.sellerFeeBasisPoints is omitted. The leaf stores SELLER_FEE_BASIS_POINTS_INHERIT (65535). The collection must have the Royalties plugin and metadata.creators must be empty.1import { createTreeV2, mintV2, mplBubblegum } from '@metaplex-foundation/mpl-bubblegum'\n2import { createCollection, mplCore, ruleSet } from '@metaplex-foundation/mpl-core'\n3import { generateSigner, some } from '@metaplex-foundation/umi'\n4import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n5\n6const umi = createUmi('https://api.devnet.solana.com')\n7 .use(mplBubblegum())\n8 .use(mplCore())\n9\n10const merkleTree = generateSigner(umi)\n11const collectionSigner = generateSigner(umi)\n12\n13await createTreeV2(umi, {\n14 merkleTree,\n15 maxDepth: 5,\n16 maxBufferSize: 8,\n17}).sendAndConfirm(umi)\n18\n19// The collection must include BubblegumV2 and Royalties plugins.\n20await createCollection(umi, {\n21 collection: collectionSigner,\n22 name: 'My Collection',\n23 uri: 'https://example.com/collection.json',\n24 plugins: [\n25 { type: 'BubblegumV2' },\n26 {\n27 type: 'Royalties',\n28 basisPoints: 500, // 5%\n29 creators: [{ address: umi.identity.publicKey, percentage: 100 }],\n30 ruleSet: ruleSet('None'),\n31 },\n32 ],\n33}).sendAndConfirm(umi)\n34\n35// sellerFeeBasisPoints is omitted — the SDK sends the inherit sentinel (65535).\n36await mintV2(umi, {\n37 collectionAuthority: umi.identity,\n38 leafOwner: umi.identity.publicKey,\n39 merkleTree: merkleTree.publicKey,\n40 coreCollection: collectionSigner.publicKey,\n41 metadata: {\n42 name: 'My NFT',\n43 uri: 'https://example.com/my-nft.json',\n44 collection: some(collectionSigner.publicKey),\n45 creators: [], // must be empty when inheriting royalties\n46 },\n47}).sendAndConfirm(umi)\n48\n49// cNFT minted with SELLER_FEE_BASIS_POINTS_INHERIT (65535) on the leaf\nSee Minting Compressed NFTs — Inheriting royalties for collection setup and constraints.Get Asset ID After MintingUse parseLeafFromMintV2Transaction to retrieve the leaf schema (including the asset ID) after a mint confirms.parse-mint.tsimport { mintV2, parseLeafFromMintV2Transaction } from '@metaplex-foundation/mpl-bubblegum'\nimport { none } from '@metaplex-foundation/umi'\n\nconst { signature } = await mintV2(umi, {\n leafOwner: umi.identity.publicKey,\n merkleTree: merkleTree.publicKey,\n metadata: {\n name: 'My Compressed NFT',\n uri: 'https://example.com/my-nft.json',\n sellerFeeBasisPoints: 500,\n collection: none(),\n creators: [],\n },\n}).sendAndConfirm(umi)\n\nconst leaf = await parseLeafFromMintV2Transaction(umi, signature)\nconsole.log('Asset ID:', leaf.id)\nconsole.log('Leaf index:', leaf.nonce)\nTransfer a Compressed NFTtransferV2 moves ownership of a cNFT to a new wallet. getAssetWithProof fetches all required proof parameters from the DAS API.transfer.tsimport { getAssetWithProof, transferV2 } from '@metaplex-foundation/mpl-bubblegum'\nimport { publicKey } from '@metaplex-foundation/umi'\n\nconst assetWithProof = await getAssetWithProof(umi, assetId, { truncateCanopy: true })\n\nawait transferV2(umi, {\n ...assetWithProof,\n leafOwner: umi.identity, // current owner as signer\n newLeafOwner: publicKey('NewOwnerAddressHere'),\n}).sendAndConfirm(umi)\nBurn a Compressed NFTburnV2 permanently destroys a cNFT and removes its leaf from the tree.burn.tsimport { getAssetWithProof, burnV2 } from '@metaplex-foundation/mpl-bubblegum'\n\nconst assetWithProof = await getAssetWithProof(umi, assetId, { truncateCanopy: true })\n\nawait burnV2(umi, {\n ...assetWithProof,\n leafOwner: umi.identity, // owner must sign\n}).sendAndConfirm(umi)\nUpdate a Compressed NFTupdateMetadataV2 modifies a cNFT's metadata. Update authority depends on whether the cNFT belongs to a collection — see Update cNFTs for authority rules.update.tsimport {\n getAssetWithProof,\n updateMetadataV2,\n UpdateArgsArgs,\n} from '@metaplex-foundation/mpl-bubblegum'\nimport { some, publicKey } from '@metaplex-foundation/umi'\n\nconst assetWithProof = await getAssetWithProof(umi, assetId, { truncateCanopy: true })\n\nconst updateArgs: UpdateArgsArgs = {\n name: some('Updated Name'),\n uri: some('https://example.com/updated.json'),\n}\n\n// Spread includes currentMetadata (leaf-canonical). Do not pass metadata here.\nawait updateMetadataV2(umi, {\n ...assetWithProof,\n leafOwner: assetWithProof.leafOwner,\n updateArgs,\n coreCollection: publicKey('YourCollectionAddressHere'),\n}).sendAndConfirm(umi)\ngetAssetWithProof.metadata mirrors DAS main fields (resolved when inherited) and keeps type MetadataArgs. currentMetadata is leaf-canonical MetadataArgsV2Args for write instructions (sentinel 65535 when inherited). Optional siblings sellerFeeBasisPointsRaw / creatorsRaw and inherited mirror DAS _raw / inherit detection. Spread ...assetWithProof into writes — do not pass metadata as currentMetadata or as the leaf metadata arg on other instructions.Delegate a Compressed NFTA leaf delegate can transfer, burn, and freeze a cNFT on the owner's behalf. The delegate resets to the new owner after any transfer.Approve a Delegateapprove-delegate.tsimport { getAssetWithProof, delegate } from '@metaplex-foundation/mpl-bubblegum'\nimport { publicKey } from '@metaplex-foundation/umi'\n\nconst assetWithProof = await getAssetWithProof(umi, assetId, { truncateCanopy: true })\n\nawait delegate(umi, {\n ...assetWithProof,\n leafOwner: umi.identity,\n previousLeafDelegate: umi.identity.publicKey, // current delegate (use owner if none)\n newLeafDelegate: publicKey('DelegateAddressHere'),\n}).sendAndConfirm(umi)\nRevoke a DelegateSet the new delegate to the owner's own address.revoke-delegate.tsimport { getAssetWithProof, delegate } from '@metaplex-foundation/mpl-bubblegum'\n\nconst assetWithProof = await getAssetWithProof(umi, assetId, { truncateCanopy: true })\n\nawait delegate(umi, {\n ...assetWithProof,\n leafOwner: umi.identity,\n previousLeafDelegate: currentDelegatePublicKey,\n newLeafDelegate: umi.identity.publicKey, // revoke by delegating to self\n}).sendAndConfirm(umi)\nCollectionssetCollectionV2 sets, changes, or removes the MPL-Core collection on a cNFT. See Managing Collections for full details.Set or Change a Collectionset-collection.tsimport {\n getAssetWithProof,\n setCollectionV2,\n} from '@metaplex-foundation/mpl-bubblegum'\nimport { publicKey } from '@metaplex-foundation/umi'\n\nconst assetWithProof = await getAssetWithProof(umi, assetId, { truncateCanopy: true })\n\nawait setCollectionV2(umi, {\n ...assetWithProof,\n metadata: assetWithProof.currentMetadata,\n newCollectionAuthority: newCollectionUpdateAuthority,\n newCoreCollection: publicKey('NewCollectionAddressHere'),\n}).sendAndConfirm(umi)\nRemove a Collectionremove-collection.tsimport { getAssetWithProof, setCollectionV2 } from '@metaplex-foundation/mpl-bubblegum'\nimport { unwrapOption } from '@metaplex-foundation/umi'\n\nconst assetWithProof = await getAssetWithProof(umi, assetId, { truncateCanopy: true })\nconst collection = unwrapOption(assetWithProof.currentMetadata.collection)\n\nawait setCollectionV2(umi, {\n ...assetWithProof,\n metadata: assetWithProof.currentMetadata,\n authority: collectionAuthoritySigner,\n coreCollection: collection!,\n}).sendAndConfirm(umi)\nFreeze and ThawTwo freeze mechanisms are available. See Freeze cNFTs for the full breakdown of asset-level vs collection-level freeze.Freeze a cNFT (Leaf Delegate)freeze.tsimport {\n getAssetWithProof,\n delegateAndFreezeV2,\n} from '@metaplex-foundation/mpl-bubblegum'\nimport { publicKey } from '@metaplex-foundation/umi'\n\nconst assetWithProof = await getAssetWithProof(umi, assetId, { truncateCanopy: true })\n\n// Delegates and freezes in one instruction\nawait delegateAndFreezeV2(umi, {\n ...assetWithProof,\n leafOwner: umi.identity,\n newLeafDelegate: publicKey('FreezeAuthorityAddressHere'),\n}).sendAndConfirm(umi)\nThaw a cNFTthaw.tsimport { getAssetWithProof, thawV2 } from '@metaplex-foundation/mpl-bubblegum'\n\nconst assetWithProof = await getAssetWithProof(umi, assetId, { truncateCanopy: true })\n\nawait thawV2(umi, {\n ...assetWithProof,\n leafDelegate: umi.identity, // freeze authority must sign\n}).sendAndConfirm(umi)\nCreate a Soulbound cNFTA soulbound cNFT is permanently non-transferable. The collection must have the PermanentFreezeDelegate plugin enabled. See Freeze cNFTs for setup details.soulbound.tsimport { getAssetWithProof, setNonTransferableV2 } from '@metaplex-foundation/mpl-bubblegum'\n\nconst assetWithProof = await getAssetWithProof(umi, assetId, { truncateCanopy: true })\n\nawait setNonTransferableV2(umi, {\n ...assetWithProof,\n // permanent freeze delegate must sign\n}).sendAndConfirm(umi)\nsetNonTransferableV2 is irreversible. The cNFT cannot be made transferable again after this call.Verify CreatorsverifyCreatorV2 sets the verified flag on a creator entry. The creator being verified must sign the transaction. See Verify Creators for details.Verify a Creatorverify-creator.tsimport {\n getAssetWithProof,\n verifyCreatorV2,\n} from '@metaplex-foundation/mpl-bubblegum'\n\nconst assetWithProof = await getAssetWithProof(umi, assetId, { truncateCanopy: true })\n\nawait verifyCreatorV2(umi, {\n ...assetWithProof,\n metadata: assetWithProof.currentMetadata,\n creator: umi.identity, // the creator being verified must sign\n}).sendAndConfirm(umi)\nUnverify a Creatorunverify-creator.tsimport {\n getAssetWithProof,\n unverifyCreatorV2,\n} from '@metaplex-foundation/mpl-bubblegum'\n\nconst assetWithProof = await getAssetWithProof(umi, assetId, { truncateCanopy: true })\n\nawait unverifyCreatorV2(umi, {\n ...assetWithProof,\n metadata: assetWithProof.currentMetadata,\n creator: umi.identity,\n}).sendAndConfirm(umi)\nFetching cNFTsThe DAS API plugin is automatically registered by mplBubblegum(). See Fetch cNFTs for the full breakdown of available methods.getAssetWithProof and inherited royalties getAssetWithProof combines getAsset and getAssetProof into the parameter shape expected by write instructions.FieldPurposemetadataMirrors DAS main fields (MetadataArgs): sellerFeeBasisPoints / creators from royalty.basis_points / creators (resolved when inherited). Use for reading / UI.currentMetadataLeaf-canonical MetadataArgsV2Args for write instructions and hashing (sentinel 65535 when inherited). Included when you spread ...assetWithProof.sellerFeeBasisPointsRaw / creatorsRawOptional DAS-aligned leaf siblings (basis_points_raw / creators_raw). Set when DAS provides _raw / inherited SFBP; omitted otherwise (same as DAS).inheritedSugar for inherit detection (rpcAsset.royalty.inherited / sentinel).rpcAssetFull DAS response. Same main / _raw split as above.updateMetadataV2 names its existing-leaf argument currentMetadata (IDL). Spreading ...assetWithProof supplies it. Instructions that take a leaf metadata arg (setCollectionV2, verifyCreatorV2, …) should use assetWithProof.currentMetadata. Do not pass display metadata into those args.Clients reading DAS directly should follow Reading Inherited Royalties.Version requirementscurrentMetadata ships in @metaplex-foundation/mpl-bubblegum 5.1.0. The sellerFeeBasisPointsRaw, creatorsRaw, and inherited siblings are not published yet — they arrive with mpl-bubblegum#173. Until then, read the same values from rpcAsset.royalty.basis_points_raw, rpcAsset.creators_raw, and rpcAsset.royalty.inherited, which need @metaplex-foundation/digital-asset-standard-api ≥ 2.1.0.1import { dasApi } from '@metaplex-foundation/digital-asset-standard-api'\n2import { getAssetWithProof, mplBubblegum } from '@metaplex-foundation/mpl-bubblegum'\n3import { publicKey } from '@metaplex-foundation/umi'\n4import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n5\n6// getAssetWithProof calls getAsset and getAssetProof, so this needs a\n7// DAS-capable RPC. The public Solana endpoints do not serve DAS methods.\n8const umi = createUmi('YOUR_DAS_ENABLED_RPC_URL')\n9 .use(mplBubblegum())\n10 .use(dasApi())\n11\n12const assetId = publicKey('YOUR_ASSET_ID')\n13\n14const assetWithProof = await getAssetWithProof(umi, assetId, {\n15 truncateCanopy: true,\n16})\n17\n18// Reading: metadata mirrors DAS main / resolved fields\n19console.log(assetWithProof.metadata.sellerFeeBasisPoints) // e.g. 500 when inherited\n20console.log(assetWithProof.metadata.creators) // collection payees when inherited\n21console.log(assetWithProof.inherited) // true\n22\n23// Writes / hashing: currentMetadata is leaf-canonical (V2)\n24console.log(assetWithProof.currentMetadata.sellerFeeBasisPoints) // 65535 when inherited\n25console.log(assetWithProof.currentMetadata.creators) // usually []\n26\n27// Optional DAS-aligned _raw siblings (same leaf values)\n28console.log(assetWithProof.sellerFeeBasisPointsRaw) // 65535 when inherited\n29console.log(assetWithProof.creatorsRaw) // usually []\n30\n31// Explicit DAS raw + flag\n32console.log(assetWithProof.rpcAsset.royalty?.basis_points_raw) // 65535\n33console.log(assetWithProof.rpcAsset.creators_raw) // []\n34console.log(assetWithProof.rpcAsset.royalty?.inherited) // true\n35\n36// 500\n37// [{ address: '...', share: 100, verified: true }]\n38// true\n39// 65535\n40// []\n41// 65535\n42// []\n43// 65535\n44// []\n45// true\nFetch a Single cNFTfetch-asset.tsimport { publicKey } from '@metaplex-foundation/umi'\n\nconst asset = await umi.rpc.getAsset(assetId)\nconsole.log('Owner:', asset.ownership.owner)\nconsole.log('Name:', asset.content.metadata.name)\nFetch cNFTs by Ownerfetch-by-owner.tsimport { publicKey } from '@metaplex-foundation/umi'\n\nconst result = await umi.rpc.getAssetsByOwner({\n owner: publicKey('OwnerAddressHere'),\n})\nconsole.log('cNFTs owned:', result.items.length)\nFetch cNFTs by Collectionfetch-by-collection.tsimport { publicKey } from '@metaplex-foundation/umi'\n\nconst result = await umi.rpc.getAssetsByGroup({\n groupKey: 'collection',\n groupValue: publicKey('CollectionAddressHere'),\n})\nconsole.log('cNFTs in collection:', result.items.length)\nDerive Leaf Asset ID from Tree and Indexfind-asset-id.tsimport { findLeafAssetIdPda } from '@metaplex-foundation/mpl-bubblegum'\n\nconst [assetId] = await findLeafAssetIdPda(umi, {\n merkleTree: merkleTree.publicKey,\n leafIndex: 0,\n})\nTransaction PatternsHandling \"Transaction Too Large\" ErrorsMerkle proofs grow with tree depth. Pass truncateCanopy: true to getAssetWithProof to automatically remove proof nodes already cached in the canopy, reducing transaction size.truncate-canopy.tsimport { getAssetWithProof } from '@metaplex-foundation/mpl-bubblegum'\n\n// truncateCanopy fetches tree config and removes redundant proof nodes\nconst assetWithProof = await getAssetWithProof(umi, assetId, { truncateCanopy: true })\nFor very deep trees where even a truncated proof exceeds the transaction limit, use versioned transactions with Address Lookup Tables.Send and Confirmsend-and-confirm.tsconst result = await mintV2(umi, { ... }).sendAndConfirm(umi)\nconsole.log('Signature:', result.signature)\nBuild Without Sendingbuild-only.tsconst tx = await mintV2(umi, { ... }).buildAndSign(umi)\n// send later: await umi.rpc.sendTransaction(tx)\nCommon ErrorsTransaction too largeThe merkle proof exceeds the 1232-byte transaction limit. Use { truncateCanopy: true } in getAssetWithProof, or implement versioned transactions with Address Lookup Tables.Invalid proofThe proof is stale — the tree was modified after you fetched the proof. Always call getAssetWithProof immediately before submitting a write transaction.Leaf already exists / Invalid leafThe asset ID or leaf index is incorrect. Re-derive the asset ID using findLeafAssetIdPda or re-fetch via getAssetsByOwner.InvalidAuthorityYou are not the owner, delegate, or required authority for this instruction. Verify the correct signer is set as leafOwner or leafDelegate.Tree is fullThe merkle tree has reached its maxDepth capacity (2^maxDepth leaves). Create a new tree to continue minting.Account not found on DAS fetchYour RPC provider may not support the Metaplex DAS API. Switch to a compatible RPC provider.NotesgetAssetWithProof is required before nearly every write instruction. Always call it immediately before submitting to avoid stale proof errors.Proofs fetched via DAS can become stale if the tree is modified between fetch and submit. High-concurrency scenarios should fetch and submit in the same atomic flow.setNonTransferableV2 (soulbound) is irreversible. There is no way to restore transferability once set.Delegate authority resets to the new owner after any transferV2. The new owner must re-delegate if needed.This SDK targets Bubblegum V2 (LeafSchemaV2). It is not compatible with Bubblegum V1 trees or the decompression workflow.Collections used with cNFTs must have the BubblegumV2 plugin enabled. Standard MPL-Core collections without this plugin cannot be used.Quick ReferenceBubblegum V2 FunctionsFunctionPurposecreateTreeCreate a new Bubblegum V2 merkle treemintV2Mint a new compressed NFTtransferV2Transfer cNFT ownershipburnV2Permanently destroy a cNFTupdateMetadataV2Update cNFT metadata (name, URI, creators, royalties)delegateApprove or revoke a leaf delegatesetTreeDelegateApprove or revoke a tree delegatesetCollectionV2Set, change, or remove an MPL-Core collectionfreezeV2Freeze a cNFT (requires existing leaf delegate)thawV2Thaw a frozen cNFTdelegateAndFreezeV2Delegate and freeze in a single instructionsetNonTransferableV2Make a cNFT permanently soulbound (irreversible)verifyCreatorV2Set verified flag on a creator entryunverifyCreatorV2Remove verified flag from a creator entrygetAssetWithProofFetch proof parameters; metadata for display, currentMetadata for writes; optional _raw siblings + inheritedSELLER_FEE_BASIS_POINTS_INHERITSentinel constant (65535) for royalties inherited from an MPL-Core collectionfindLeafAssetIdPdaDerive a cNFT asset ID from tree address and leaf indexparseLeafFromMintV2TransactionExtract leaf schema (including asset ID) from a mint transactionMinimum Dependenciespackage.json{\n \"dependencies\": {\n \"@metaplex-foundation/mpl-bubblegum\": \"^5.0.0\",\n \"@metaplex-foundation/umi\": \"^1.0.0\",\n \"@metaplex-foundation/umi-bundle-defaults\": \"^1.0.0\"\n }\n}\nProgram AddressesProgramAddressMPL-Bubblegum V2BGUMAp9Gq7iTEuizy4pqaxsTyUCBK68MDfK752saRPUYSPL Account CompressioncmtDvXumGCrqC1Age74AVPhSRVXJMd8PJS91L8KbNCKSPL Noopnoopb9bkMVfRPU8AsbpTUg8AQkHtKwMYZiFUjNRtMmVTree Size ReferenceMax DepthCapacityApprox. Cost1416,384~0.34 SOL17131,072~1.1 SOL201,048,576~8.5 SOL2416,777,216~130 SOL301,073,741,824~2,000 SOLFAQWhat is the Bubblegum V2 JavaScript SDK?The Bubblegum V2 JavaScript SDK (@metaplex-foundation/mpl-bubblegum) is a TypeScript library for creating and managing compressed NFTs on Solana. Built on the Umi framework, it provides type-safe wrappers for all MPL-Bubblegum V2 program instructions and includes the DAS API plugin automatically.Do I need a special RPC provider to use this SDK?Yes. Compressed NFTs require an RPC provider supporting the Metaplex DAS API to index and fetch cNFT data. Standard Solana RPCs do not support DAS. See the RPC Providers page for compatible options (Helius, Triton, Shyft, and others).How do I get the asset ID of a cNFT after minting?Use parseLeafFromMintV2Transaction with the confirmed transaction signature. It decodes the mint transaction and returns the full leaf schema including leaf.id (the asset ID) and leaf.nonce (the leaf index).Why do I get a \"Transaction too large\" error?Merkle proofs grow with tree depth. Pass { truncateCanopy: true } to getAssetWithProof to automatically remove proof nodes cached in the on-chain canopy. For very deep trees, use versioned transactions with Address Lookup Tables.Can I use this SDK with Bubblegum V1 trees?No. This SDK targets Bubblegum V2 which uses LeafSchemaV2 and V2 merkle trees. Use the legacy Bubblegum SDK for V1 trees. V2 trees and V1 trees are not cross-compatible.What is getAssetWithProof and why do I need it?getAssetWithProof is a helper that calls both getAsset and getAssetProof on the DAS API and parses the responses into the exact parameter shape expected by Bubblegum V2 write instructions. Almost every mutation instruction (transfer, burn, update, delegate, freeze, verify) requires these parameters. Always call it immediately before submitting to avoid stale proof errors.GlossaryTermDefinitionUmiMetaplex's framework for building Solana applications; handles wallet connections, RPC, and transaction buildingmplBubblegumThe Umi plugin that registers all Bubblegum V2 instructions and the DAS API plugincNFTCompressed NFT — stored as a hashed leaf in an on-chain merkle tree instead of a dedicated accountMerkle TreeOn-chain account storing hashed NFT data as leaves; created with createTreeLeafA single cNFT entry in the merkle tree, identified by its leaf indexProofA list of sibling hashes enabling cryptographic verification that a leaf belongs to a treeCanopyCached upper nodes of the merkle tree stored on-chain to reduce required proof size in transactionsLeafSchemaV2The V2 leaf data structure containing id, owner, delegate, nonce, data hash, creator hash, collection hash, asset data hash, and flagsgetAssetWithProofSDK helper that fetches and parses all DAS API data needed for write instructionsDAS APIDigital Asset Standard API — RPC extension for indexing and fetching cNFT dataTreeConfigPDA derived from the merkle tree address storing Bubblegum tree configurationLeaf DelegateAccount authorized by the cNFT owner to transfer, burn, or freeze the cNFTTree DelegateAccount authorized by the tree creator to mint cNFTs from a private treeSoulboundA permanently non-transferable cNFT set via setNonTransferableV2 — irreversible","tokens":6466,"squid":"dotcat","role":"Tooling Spider","at":1791348294408,"hash":"d2604dd5cb58ab6f84850d4a2dcac4834c4ff291"}
{"url":"https://ethresear.ch/t/mev-resistant-dynamic-pricing-auction-of-execution-proposal-rights/20024","domain":"ethresear.ch","title":"MEV resistant dynamic pricing auction of execution proposal rights - Proof-of-Stake / Block proposer - Ethereum Research","text":"MEV resistant dynamic pricing auction of execution proposal rights \n\n Proof-of-StakeBlock proposer\n\n mev\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jul 2024\n\n 1 / 1\n\n Jul 2024\n\n Jul 2024\n\n post by aelowsson on Jul 9, 2024\n\n aelowsson\n\n MEV resistant dynamic pricing auction of execution proposal rights\n1024×1024 236 KB\nExecution proposal of marriage between EA and ET through an auction sequenced by RANDAO (she said yes).\nBy Anders. Special thanks to Barnabé for helping me improve the clarity of this post. Thanks also for valuable feedback to Thomas, Julian, and Francesco.\n1. Introduction\n1.1 Background\nAs part of the effort to enshrine proposer–builder separation (ePBS), the role of beacon validators as execution proposers has come under scrutiny. Execution tickets (ET), first introduced as attester–proposer separation, is a mechanism for selecting the execution proposer by random draw from a ticket pool, aiming to detach beacon validators from the selection process. However, the mechanism for selling tickets has not been settled, with several alternatives under consideration. A notable concern is that the sale of execution tickets may induce maximal extractable value (MEV). If the mechanism is administered by the consensus layer and the beacon proposer is given too much influence over the price or over the selection of purchasers, the design risks repeating one of the issues it was intended to resolve, with a new source of MEV becoming a concern. An execution layer vending machine raises similar questions. Therefore, a MEV resistant auction mechanism could be desirable if pursuing ETs.\nExecution auctions (EA) is a related mechanism for selecting a future execution proposer, omitting the ticket pool. It relies on a MEV pricing auction, where bidders first make bids that set a floor to the MEV burn, and finally bid through tips in order to be selected by the proposer. Concerns have been raised (1, 2, 3) regarding the viability of MEV pricing auctions due to insufficient bid incentives in the initial phase. It has recently been suggested that this concern is resolved by considering the staking metagame, in which stakers must bid early to deprive other stakers of revenue. However, this resolution implies that EAs will lead to increased staker–builder integration, which might also be a cause for concern. For this reason, it seems fruitful to explore an alternative auction mechanism also when selecting the execution proposer without leveraging a ticket pool.\n1.2 Overview of proposal\nThis post introduces a dynamic pricing auction with MEV resistance to sell execution proposal rights. Builders hold reserves in a debit account and place binding purchase order for a ticket (ET) or an execution proposal slot (similar to EA). The final price adapts dynamically based on the total outstanding as well as currently incoming orders/tickets, with some similarities to, e.g., EIP-1559, and the payment is burned. Orders are delimited at the slot level through attester observations to remove agency from the beacon proposers facilitating the auction, thus inducing less new MEV. This produces a high aggregate MEV burn. In one version of the design, dubbed execution ticket auction (ETA), orders that came in during the same slot are sequenced for proposal by leveraging the RANDAO. In another version only applicable to ETs, orders that came in during the same slot are minted collectively into tickets. Due to the current limitations of the RANDAO, the mechanism is only capable of auctioning off proposal rights at least one epoch in advance.\n2. Purchase process\nFigure 1 presents the proposed purchase mechanism. Builders send purchase orders (for one ticket/execution slot at a time) over a public P2P layer. They specify a maximum price and hold a debit account within consensus to guarantee that their purchase orders are backed by sufficient funds. This account is funded using a separate transaction (see the discussion).\nBeacon attesters observe all orders up to an observation deadline, enacted for example 2 seconds before the slot boundary. The beacon proposer collects all orders (there will be one purchase order per slot on average), including orders they may have found during the last few seconds of their slot. Orders are added as a group to the beacon block and will later be popped from a virtual first-in first-out (FIFO) queue scheduled across blocks. This queue may be just one slot long, depending on implementation.\nAttesters reject the block if the beacon proposer fails to include a purchase order that they observed. The mechanism thus far has similarities to MEV pricing auctions (e.g., MEV smoothing, MEV burn, EA), but attesters are tasked with simply observing all purchases, instead of setting a bid floor. Another design that might come to mind is inclusion lists (ILs) in the style of FOCIL, but there is no new active participant in the form of an IL committee.\nFigure 12608×1606 449 KB\nFigure 1. Schematic overview of the purchase process. Orders in blue, backed by builders’ debit accounts, are observed by attesters (purple arrows). Beacon proposers subsequently add all incoming orders to the beacon block (dark red arrow). A validity check is performed to ensure that orders are fully backed. Orders are finally processed—using either RANDAO to determine the sequence in cases where several orders came in during the associated slot (yellow), or otherwise using collective minting (red). In ETA, orders are directly queued for proposal.\nOnce a slot’s orders have been added to the beacon block, a validity check is performed on builders that included at least one new order (cyan in Figure 1). If a builder’s outstanding (not yet processed) orders across the queue are not fully backed by its debit account, all the builder’s pending orders are discarded. A penalty may also be applied. Orders are priced directly upon being added or, e.g., at the time of sequencing, as described in Section 4. The determined purchase price is charged from the debit account and burned. The remaining ETH of the purchase order is subsequently virtually released such that it can be used to back new purchase orders. Orders are then sequenced and either queued for proposal (yellow arrow) or added to the ticket pool (red arrow), as described in Section 3.\n3. Sequencing process\nThe purchase orders from the same slot are added unsequenced to the beacon block. The subsequent sequencing of orders from the same slot varies between designs.\n3.1 ET – Minting of execution tickets\nThe natural strategy for ETs is collective minting, wherein all orders from the same slot mint a ticket at the same time, as indicated by the red arrow in Figure 1. The RANDAO used for ETA in the next subsection could also be applied to ETs using the same setup (dashed yellow arrow). However, the only real benefit (which remains marginal) is to facilitate a more even replenishment of the ticket pool.\n3.2 ETA – orders sequenced by RANDAO\nPurchase orders that came in during the same slot can be sequenced directly by the RANDAO, completely skipping a ticket pool. Perhaps execution ticket auction (ETA) would be a proper moniker. Indeed, with this design, a buyer will have an Estimated Time of Arrival for their order, which suitably cannot be precisely known beforehand if there is more than one order in the slot. Barnabé’s discussion (1, 2) on the topic of ETs and determinism is relevant here.\nOrders can only be sequenced after the RANDAO has been updated. Therefore, there is an initial ineligibility window W𝑊 during which orders cannot lead to an execution proposal. The RANDAO updates every 32 slots, but the proposed mechanism does not guarantee a new order every slot; in fact, the mode will be zero orders in a slot. Consequently, the safe distance between auction and slot proposal will need to be somewhat longer than 32 slots. Sequenced orders can be understood as sitting in a second FIFO queue while waiting to propose. Note that ETA could set the queue to hold as many proposal rights as the ticket pool, if desirable.\n4. Dynamic pricing\n4.1 Ticket saturation and delta\nThe exploration of dynamic pricing will refer to processed orders as “tickets”, although in the ETA design these are just sitting in the ordered queue waiting to propose. The protocol strives to ensure that there are \\hat{T}ˆ𝑇 outstanding tickets at any time. The price of a new ticket should be determined by the current number of outstanding tickets T𝑇 as well as the current supply of purchases and purchase orders T_p𝑇𝑝, measured over some window of length W_T𝑊𝑇, which in some versions can be only one slot long.\nDefine the ticket saturation as T_s=T-\\hat{T}𝑇𝑠 =𝑇 −ˆ𝑇. If T_s<0𝑇𝑠 <0, there are too few tickets, and the protocol would in general like to sell more than one ticket per slot. If T_s>0𝑇𝑠 >0, there are too many, and it would in general like to sell fewer than one. The delta T_{\\delta}=T_p-W_T𝑇𝛿 =𝑇𝑝 −𝑊𝑇 gives purchase orders relative to an expectation of one ticket per slot, which is the rate at which tickets are consumed by execution proposers. If T_{\\delta}<0𝑇𝛿 <0, the protocol is selling fewer than one ticket per slot and would in general like to sell more. If T_{\\delta}>0𝑇𝛿 >0, it sells more than one and would in general like to sell fewer.\nIf both T_s𝑇𝑠 and T_{\\delta}𝑇𝛿 are negative, the protocol should decrease the ticket price to sell more tickets. If both T_s𝑇𝑠 and T_{\\delta}𝑇𝛿 are positive, it should increase the price to sell fewer. The less trivial question is how to approach a situation when one of the variables is negative and the other is positive, how to window sales, and how quickly to adjust the price.\n4.2 Dynamic pricing mechanism\n4.2.1 Overview\nThe price of tickets adjusts on a relative basis, just like in EIP-1559, gradually shifting by some proportion of the current price each slot. To improve MEV resistance and adapt to the problem at hand, three differences to EIP-1559 however seem useful: (1) the price should depend on orders included in the current slot, not only the preceding; (2) the block should never be “full”, lest the ticket price becomes very high; (3) the mechanism should be “two-dimensional” in the sense that it accounts for both ticket saturation and delta.\nThis subsection begins by exploring the simplest realization of such a pricing mechanism, which will then gradually be expanded. In the simplest design, W_T=1𝑊𝑇 =1, and orders can be priced directly when added to the beacon block. If there is one new order (T_{\\delta}=0𝑇𝛿 =0) and the number of outstanding tickets is as desired (T_s=0𝑇𝑠 =0), the price stays the same. If there are many new orders (a sudden spike in the expected MEV), the pricing mechanism will hike the price substantially. For example, if 100 orders were to come in, the purchase price for them could rise by orders of magnitude; the exact specification would need to be determined based on other auction paramters such as the size of the ticket pool. Builders will of course track incoming orders in real time and update their estimate of the final purchase price. Therefore, even during a sudden rise in expected MEV, there will only be new orders up to the point where the deduced price matches expected MEV.\nAs another option, W_T𝑊𝑇 can be longer, setting the price W𝑊 slots after orders have been added to the beacon block. In Figure 1, W=3𝑊 =3. An asymmetric window spanning 4 slots up to and including the processing slot is then an option. The most important benefit is MEV resistance during spikes, as will be further discussed in Section 4.3. Other potential benefits include better pricing granularity, a more complete picture when pricing orders, and the marginal simplification in ETA from pricing and sequencing orders at the same. Of course, it can be argued that the picture already is “complete” in the sense that builders can indicate expected MEV already at the current slot, albeit they may not be fully equipped to evaluate incoming orders in real-time. It can also be argued that W>0𝑊 >0 and W_T>1𝑊𝑇 >1 needlessly increase uncertainty and analytical complexity for builders as well as developers. As an example, builders may place an order several slots before a spike, but still need to pay closer to the real expected value of the MEV they are about to receive (priced closer to proposal time).\n4.2.2 Equations\nA rudimentary example will now be provided. Should this general mechanism be pursued, the exact price controller would have to be determined by reasoning about how quickly the price should adapt to changes in the willingness to buy tickets, sensitivity to ticket saturation, interplay between saturation and delta, sensitivity to MEV induction (see the next subsection), and by running simulations of the purchase process.\nTicket saturation and delta from the previous subsection is first weighed by window length and desired number of outstanding tickets\n\nw_s=\\frac{T_s}{c_s\\hat{T}}, \\quad w_{\\delta}=\\frac{T_{\\delta}}{c_{\\delta}W_T},\n𝑤𝑠=𝑇𝑠𝑐𝑠ˆ𝑇,𝑤𝛿=𝑇𝛿𝑐𝛿𝑊𝑇,\nusing the constants c_s=2^3𝑐𝑠 =23 and c_{\\delta}=2^6𝑐𝛿 =26. The percentage change w𝑤 to the ticket price applied each slot is\n\nw=(1+w_s)(1+w_{\\delta})^k.\n𝑤=(1+𝑤𝑠)(1+𝑤𝛿)𝑘.\nThis post uses k=2𝑘 =2, ensuring a non-linear price response as T_{\\delta}𝑇𝛿 grows. This can be particularly relevant at shorter windows W_T𝑊𝑇. Setting k=3𝑘 =3 is also viable. The constant c_{\\delta}𝑐𝛿 can then alternatively be increased to offer better pricing granularity at a lower ticket delta, while still offering some guarantees regarding the maximum number of orders that may come in during one slot. The price p𝑝 updates from its level at the previous slot p_0𝑝0 to its level at the present slot p_1𝑝1 as\n\np_1=w \\times p_0.\n𝑝1=𝑤×𝑝0.\n4.2.3 Visualizations\nFigure 2 illustrates what a pricing schedule according to w𝑤 would look like for the outlined equations, with \\hat{T}=4096ˆ𝑇 =4096 and W_T=32𝑊𝑇 =32. The yellow band stipulates no price change (w=1𝑤 =1), and passes through the intersection of the black lines, which correspond to a neutral ticket delta (x-axis) and saturation (y-axis). There have been suggestions of much higher \\hat{T}ˆ𝑇. This issue relates to a wide range of considerations that are not the focus of this post.\nFigure 22916×2180 206 KB\nFigure 2. Rudimentary example for W_T=32𝑊𝑇 =32 of a percentage change in ticket price that varies with delta in ticket sales and the overall saturation of tickets in the pool. Black lines indicate a neutral delta (one ticket sold per slot) and saturation (T=\\hat{T}𝑇 =ˆ𝑇).\nFigure 3 instead shows a pricing schedule when W_T=1𝑊𝑇 =1 using the same equation and settings as previously. If no orders come in during the measured slot, T_{\\delta}=-1𝑇𝛿 = −1. Note that the colormap is log-scaled to capture the large increase in w𝑤 that is instituted if 64 orders were to come in during a single slot. When T_W=32𝑇𝑊 =32 (Figure 2), a large jump in orders would affect the price for 32 consecutive slots (assuming an asymmetric window), before the purchase takes place, and so w𝑤 will naturally be lower on a per-slot basis.\nFigure 32874×2180 148 KB\nFigure 3. Rudimentary example for W_T=1𝑊𝑇 =1 of a percentage change in ticket price that varies with delta in ticket sales and the overall saturation of tickets in the pool. Black lines indicate a neutral delta (one ticket sold in the slot) and saturation (T=\\hat{T}𝑇 =ˆ𝑇).\nThe relative change at W_T=1𝑊𝑇 =1 for different T_{\\delta}𝑇𝛿 is shown in Figure 4, at a neutral ticket saturation (T_s=0𝑇𝑠 =0). The price change instituted with this setting for between 0 to 4 orders is {0.969, 1, 1.031 1.063 1.096}. The same granularity can be preserved at lower quantities of orders while further raising the price at higher quantities, by increasing k𝑘.\nFigure 43002×1417 114 KB\nFigure 4. Rudimentary example for W_T=1𝑊𝑇 =1, focusing on the relative price change w𝑤 across T_{\\delta}𝑇𝛿 at a neutral saturation. If 60 orders come in during a single slot, the price rises sharply.\nFigure 5 instead plots the response at T_{\\delta}=-1𝑇𝛿 = −1 across T_s𝑇𝑠. In other words, it shows how the price would change if no purchase orders are registered.\nFigure 53138×1420 159 KB\nFigure 5. Rudimentary example for W_T=1𝑊𝑇 =1, focusing on the relative price change w𝑤 across T_s𝑇𝑠 when no purchase order comes in.\n4.3 Windowing and slot surge pricing\nIn the outlined pricing mechanism, there is a remaining opportunity for the beacon proposer to derive some MEV at shorter windows T_W𝑇𝑊. This happens during a sudden spike in interest for purchasing tickets between the point where attesters have observed purchase orders and the slot boundary.\nLet n_a𝑛𝑎 be the equilibrium quantity of orders that would have come in during a slot if a spike happened before the attester observation deadline (purple arrows in Figure 1). Builders keep track of incoming orders and calculate the current ticket price, which when compared to the updated expected MEV V_e𝑉𝑒 produces n_a𝑛𝑎 orders. If a spike comes in after the attester deadline, the proposer has exclusivity and could (be paid to) include only a subset of the orders n_p𝑛𝑝. The surplus MEV for the proposer emerges from providing a lower expected purchase price for each order it lets through. This is a monopoly pricing regime, wherein the proposer sells spots at a price approaching V_e-p_1𝑉𝑒 −𝑝1. It determines n_p𝑛𝑝 to maximize its revenue R(n_p)𝑅(𝑛𝑝), in accordance with the revenue function:\n\n\\text{Maximize} \\quad R(n) = n (V_e(n) - p_1(n)).\nMaximize𝑅(𝑛)=𝑛(𝑉𝑒(𝑛)−𝑝1(𝑛)).\nHere, p_1(n)𝑝1(𝑛) is based on the price equation provided in the previous subsection. Also note that if many purchase orders come in, V_e𝑉𝑒 might gradually fall (if there is a temporary spike); hence V_e(n)𝑉𝑒(𝑛).\nQuick edit: some additions/adjustments and referring to the previous subsection, which I had forgotten to do.\nAs mentioned in the previous subsection, longer windows W_T𝑊𝑇 serve to further starve off MEV. The reason is now clear: bids of the present slot will with longer windows be priced based on information coming in also during subsequent slots. This means that the proposer has less leverage during a sudden spike, since builders will need to pay based on bids that are also observed by attesters (at the fair market price). In Figure 2, the price would be set 32 slots after inclusion in the block, influenced by the bids in these slots. Another way to achieve a similar effect without longer windows is to charge according to the price calculated during the next slot. Here it is important to note that bidders of the next slot cannot materially grief bidders of the present slot. They will also have to pay close to the price of bidders in the current slot, since the price cannot fall substantially between slots at short windows, only rise (also note the discussion of max price in Section 4.4). Yet the downside of heightened uncertainty for builders regarding pricing can be important to keep in mind.\nIf the price surges more quickly from a high quantity of purchased tickets within a single slot, the proposer’s potential revenue could also be reduced. Proposers can then sell fewer spots. Furthermore, by letting the price in the next slot not shift as much, oscillations in bid quantity (and potentially price) can be tempered. One way to achieve this is to let w𝑤 rise more quickly with an increase in bids, set the price in the current slot as previously\n\np_1=w \\times p_0,\n𝑝1=𝑤×𝑝0,\nbut to not incorporate the full price change when setting the value p^*_0𝑝∗0 that will be used as p_0𝑝0 when pricing the next slot\n\np^*_0=\\left(1+\\frac{1-w}{c_w}\\right) \\times p_0.\n𝑝∗0=(1+1−𝑤𝑐𝑤)×𝑝0.\nThe constant c_w𝑐𝑤 is then set above 1. During a spike in expected value up to a new baseline V_e𝑉𝑒, the price would then theoretically stay rather fixed (at a new higher level) for subsequent slots, with the number of orders in each slot gradually decreasing, until it proceeds at the regular pace of one purchase order per slot. Yet note that if V_e𝑉𝑒 rises from a temporary opportunity, there will be a bit more MEV for the proposer to extract still, because a lot of the value can depend on getting in early. This further depends on if the mechanism is ET or ETA and the size of the ticket pool. It is also important to note that a price surge means giving up some bid granularity. The discussion offers some further thoughts on bid granularity and the proposer’s ability to extract MEV.\nAs a concluding remark, it should always be remembered that a big ticket pool acts to temper fluctuations in the expected value of tickets. The buyer does not necessarily buy the right to sell tickets within the next couple of epochs, but rather within the next couple of hours, days, weeks or months, depending on the setting for \\hat{T}ˆ𝑇—and it turns out that when measured over longer periods, the level of the MEV has been very stable in Ethereum.\n4.4 The role of a maximum price\nEach buyer assigns a max price to the order. This is the value that needs to be backed by the debit account. If the max price is insufficient at the time of pricing, such that the actual price is higher, the builder does not receive a ticket/slot. Yet builders could make unbacked orders to starve off competitors, which would bring down the purchase price. It seems desirable to not force builders to analyze the balances of every competitor to determine which bids are real and which are “fake”. One simple way to avoid such a situation is to penalize builders for placing orders that turn out to be unbacked at the time of purchase. This can potentially be combined with setting a validity rule requiring some minimum max price, either relative to the prevailing price at bid time, or/and as a fixed overall minimum.\nPenalizing builders however exacerbates another potential issue. During an unforeseen spike in expected MEV, there are circumstances where a builder could “liquidate” its competitors’ bids if the current purchase price is close to their stipulated maximum. A builder could enter new bids forcing other builders out, to penalize them and gain cheaper tickets. For this reason, the mechanism could reduce gameability and the risks as well as improve capital efficiency for builders by stipulating an absolute maximum purchase price. A builder that bids the absolute maximum is guaranteed to not get liquidated and will always receive a ticket. This does not mean that the protocol will burn less MEV, merely that in times of extremely high expected MEV, there will temporarily be a higher quantity of bids, wherein each order has a lower chance of actually getting one of the desirable profitable slots.\nWhat should the absolute maximum be set to if this path is pursued? In data provided by Flashbots spanning 2.7 million blocks between the last quarter of 2022 and the third quarter of 2023, the maximum average REV across 64 slots is 19.5 ETH. The peak average is skewed by a few spurious blocks with REV of several 100 ETH that may have been hard to predict beforehand. This average does therefore not represent a realistic expected MEV for builders bidding many slots in advance. Expand the window by a factor of 4 to 256 and the maximum average falls almost by a factor of 4, to 5.25. Setting the absolute maximum to 5 ETH would thus presumably not influence the auction even in times of extreme market conditions, since that price would hardly ever be reached.\n5. Discussion\nA MEV resistant dynamic pricing auction for selling execution proposal rights has been presented, relevant to the research of both ETs and EAs. It seeks to remove agency from the beacon proposer, thus inducing less MEV. This is achieved by having every order result in a sale, and every order coming in during the same slot having the same expected sales price. The execution ticket auction (ETA) sequences orders directly for proposal by leveraging the RANDAO. Orders that came in during the same slot can otherwise be minted collectively into tickets, with sequencing pursued at a later stage in accordance with the ET proposal.\nIf pursuing this auction mechanism, the dynamic pricing step would require substantial analysis. One sensitive part is the balance between moderating changes in the supply of orders while still offering sufficient pricing granularity. A high k𝑘 can be useful here. Another potential avenue is to hold the auction less frequently. The expected timing of orders within the slot would also be interesting to study—orders can be placed early to starve off others, or late to gain better information. One could even theorize that some builders will wait until after the attester deadline, and then pay the proposer a small fee for exclusive post-deadline inclusion (the benefit being to avoid race conditions).\nTransactions to fund or withdraw from a builder’s debit account would need to be synchronized with the validity check to avoid race conditions. It may be convenient to expand the role of the debit account if it is desirable to subject builders to slashing or penalties at the execution proposal stage. In other words, the debit account might also function as a stake.\nJust as with MEV pricing auctions, attesters accepting or rejecting a block based on some observation deadline is potentially sensitive. However, this particular design should hopefully be less so, since there will only be one order on average per block to observe, and less value (even potentially negative) in bidding later in the block. A potential benefit of an auction administered instead at the execution layer is the “endogenous” component, facilitating a higher burn; the value of a ticket increases if the current ticket holder can extract value from future ticket holders through MEV. However, this direction raises gameability concerns if a single actor can come to monopolize the auction (ILs may here be useful). A MEV resistant mechanism, as here proposed, originating at the consensus layer, therefore seems like a viable direction.\nIt might seem tempting to replicate some facets of the proposed design for transaction processing: making the protocol more MEV resistant by having attesters observe transactions, the protocol sequence them by RANDAO, and the price adjust in a slot-delimited fashion. However, the requirements for transactions are different than for the purchase orders of execution rights analyzed in this post (e.g., time, quantity). Translating the ideas of this post directly to transaction processing might therefore unfortunately be difficult. Yet the proposed mechanism could perhaps lend some inspiration going forward.\nIt should be noted that multi-block MEV is a separate topic of concern. The proposed mechanism is resistant to inducing MEV at the purchase stage but does not preclude multi-block MEV. This is a general issue and an underexplored topic at this point in time. Censorship resistance is likewise an important problem not addressed by the auction mechanism. Various strategies, such as ILs (1, 2, 3), have been proposed. Whether the presented auction mechanism can be one part of an overall architecture that also tackles other issues remains to be explored.\n\n Sealed execution auction\n\n Practical endgame on issuance policy\n\n Rainbow roles & incentives: ABPS + FOCILR + AS\n\n read \n\n 10\n min\n\n Powered by Discourse","tokens":6871,"squid":"spider-04","role":"Research Spider","at":1791348301247,"hash":"5e9eea279f9e0181aeb3a5ca6beb2d5337091c20"}
{"url":"https://docs.chain.link/datalink/push-delivery/overview","domain":"docs.chain.link","title":"DataLink (Push Delivery) | Chainlink Documentation","text":"DataLink (Push Delivery)DataLink push-based feeds provide access to specialized data from Data Providers through direct onchain delivery, enabling smart contracts to read the latest data values without additional offchain infrastructure. \nKey Characteristics\nSpecialized market data: Access specialized datasets directly from individual Data Providers\nPush Delivery: Data is automatically updated onchain by Decentralized Oracle Networks (DONs)\nSmart contract integration: Read data directly in your smart contracts using standard interfaces\nProven architecture: Built on Chainlink's battle-tested aggregation infrastructure with robust data quality mechanisms\n\nHow It Works\nData Providers submit specialized data to Chainlink Decentralized Oracle Networks (DONs)\nDONs aggregate and validate the data using consensus mechanisms\nSmart contracts automatically receive updated values onchain through aggregator contracts\nApplications read the latest data directly from smart contracts using standard interfaces\nThis push-based model eliminates the need for offchain data fetching while maintaining cryptographic security and data integrity.\n\nIntegration MethodsSmart Contract IntegrationRead data directly in your smart contracts using the AggregatorV3Interface:\nLatest data: Get the most recent price and timestamp\nHistorical data: Access previous rounds of data updates\nOffchain IntegrationAccess feed data from external applications using Web3 libraries:\nJavaScript/TypeScript: Using web3.js or ethers.js\nPython: Using Web3.py\nOther languages: Any Web3-compatible library\n\nGetting Started1. Choose Your Integration Method\nSmart Contract: Integrate directly in Solidity contracts for automated onchain logic\nOffchain Application: Read data from external applications using Web3 libraries\n2. Find Your Data ProviderBrowse the Provider Catalog to find Data Providers offering the specialized data you need.3. Follow the TutorialsStart with our step-by-step Tutorials covering:\nUsing DataLink feeds in smart contracts\nReading feeds from offchain applications\nBest practices for data validation and error handling\n4. Reference DocumentationConsult the API Reference for:\nComplete smart contract interface documentation\nFunction specifications and return values\n\n What's next > Start with Tutorials > Browse API Reference > View Provider Catalog","tokens":585,"squid":"spider-08","role":"Oracle Spider","at":1791348306939,"hash":"1a9f8ea75aaffd69f20f80e6272070d500972ea1"}
{"url":"https://ethresear.ch/t/on-block-space-distribution-mechanisms/19764","domain":"ethresear.ch","title":"On block-space distribution mechanisms - Proof-of-Stake / Block proposer - Ethereum Research","text":"On block-space distribution mechanisms \n\n Proof-of-StakeBlock proposer\n\n mev\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n read \n\n 17\n min\n\n Jun 2024\n\n 1 / 5\n\n Jun 2024\n\n Jul 2024\n\n post by mikeneuder on Jun 8, 2024\n\n mikeneuder\n\n On block-space distribution mechanisms\nupload_3067440b5b4f752379ddba32df7ecf8b1548×1550 304 KB\n^p.s. yes, we anthropomorphize the protocol as a ghost because Casper.\n^^p.p.s. not sure why the auctioneer ghost looks like he is conducting an orchestra, but here we are ¯\\_(ツ)_/¯.\n^^^ p.p.p.s. by the way, if you haven’t seen Maestro, it’s great.\n\\cdot⋅\nby Mike, Pranav, & Dr. Tim Roughgarden – June 8, 2024.\n\\cdot⋅\nAcknowledgements\nSpecial thanks to Barnabé, Julian, Jonah, Davide, Thomas, Terence, Potuz, & Nate for comments and discussions.\n\\cdot⋅\ntl;dr; Block space, the capacity for transaction inclusion, is the principal resource exported by blockchains. As the crypto ecosystem scales up and professionalizes, the value produced by efficient usage of block space (MEV) has come to play a significant role in the economics of permissionless consensus mechanisms. An immense amount of ink has been spilled by the research community considering what, if anything, protocols should enshrine in response to MEV (see Related Work). Indeed, the past few years resemble a Blind Men and the Elephant narrative arc, where many different perspectives, solutions, and theories have been propounded, but each angle can feel disjoint and difficult to compare. The first half of this article aims to present a broad-strokes painting of the “MEV-ephant” by distilling the design space into a core set of questions and exploring how existing proposals answer them. The second half hones in specifically on allocation mechanisms enabled by execution tickets, demonstrating an important new insight – there is a trade-off between the quality of the in-protocol MEV oracle and the fairness of the mechanism.\nOrganization: Section 1 motivates the need for an in-protocol mechanism to handle block-space distribution as part of the “endgame” for Proof-of-Stake. Section 2 enumerates five axes along which block-space distribution mechanisms may be measured, using a familiar set of questions: who, what, when, where, how (abbr. the W^4H questions). Section 3 interrogates how the block builder is selected, focusing on the execution tickets model. Section 4 extrapolates by concluding and raising open questions that follow from the framework established.\nStructural note: This article is rather long for this format and has some technical elements. We encourage the reader to focus on the portion of the article they are most interested in:\n\nSections 1, 2, & 4 provide a broader perspective on the existing proposals and our proposed methodology for analyzing them.\nSection 3 (which is \\approx 44\\%≈44% of the content, but 100\\%100% of the math) provides a detailed analysis of allocation mechanisms enabled by the execution tickets design. This section can be read in sequence, in isolation, or skipped altogether – up to you!\n\n\\cdot⋅\nContents\n\nMotivation\n1) What\nBlock-space distribution today through mev-boost\nEnumeration\nThe elements of block-space distribution\nExecution tickets and other animals\nApplying W^4H: a comparative analysis\nMotivational interlude\nInterrogation\nPreliminaries\nModel\nFamiliar allocation mechanisms\nComparing the outcomes\nAside #1: Calculating equilibrium bids\nAside #2: Tullock Contests\nExtrapolation\n\n\\cdot⋅\nRelated work\n\nmev-boost & relays\n\nMEV-Boost: Merge ready Flashbots Architecture; Flashbots team\nRelays in a post-ePBS world; Mike, Jon, Hasu, Tomasz, Chris, Toni\n\nmev-burn / mev-smoothing\n\nBurning MEV through block proposer auctions; Domothy\nMEV burn – a simple design; Justin\nCommittee-driven MEV smoothing; Francesco\nDr. changestuff or: how I learned to stop worrying and love mev-burn; Mike, Toni, Justin\n\nenshrined Proposer-Builder Separation (ePBS)\n\nTwo-slot proposer/builder separation; Vitalik\nUnbundling PBS: towards protocol-enforced proposer commitments (PEPC); Barnabé\nNotes on Proposer-Builder Separation; Barnabé\nMore pictures about proposers and builders; Barnabé\nWhy enshrine Proposer-Builder Separation?; Mike, Justin\nePBS design constraints; Potuz\nReconsidering the market structure of PBS; Barnabé\n\nblock-space futures\n\nBlock vs. Slot Auction PBS; Julian\nOpportunities and Considerations of Ethereum’s Blockspace Future; Drew, Ankit\nWhen to sell your blocks; Quintus, Conor\n\nexecution tickets\n\nAttester-proposer separation; Justin\nExecution tickets; Justin, Mike\nEconomic Analysis of Execution Tickets; Jonah, Davide\nBlock-auction ePBS versus Execution Ticket; Terence\n\n(1) – Motivation\nBefore descending into this murky rabbit hole, let’s start by simply motivating the necessity of a block-space distribution mechanism. Validators in Proof-of-Stake protocols are tasked with producing and voting on blocks. The figure below, from Barnabé’s excellent “More pictures about proposers and builders,” describes these as “proposing” and “attesting” rights, respectively.\nupload_72dad4dc4f8c77f0d57f8f126b3c2e461450×462 100 KB\n1) What\n(\\uparrow↑ important cultural ref.)\nA block-space distribution mechanism is the process by which the protocol determines the owner of the “proposing” or “block construction” rights. Proof-of-Stake protocols typically use some version of the following rules:\n\nblock-space (proposing) rights – A random validator is elected as the leader and permitted to create the next block.\nvoting (attesting) rights – All validators vote during some time window for the block they see as the canonical head.\n\nValidators perform these tasks because they receive rewards for doing so. We categorize the rewards according to their origin in either the consensus layer (the issuance from the protocol – e.g., newly minted ETH) or the execution layer (transaction fees and MEV):\n\nConsensus layer\na. Attestation rewards – see attestation deltas.\nb. Block rewards – see get_proposer_reward.\nExecution layer\na. Transaction fees – see gas tracker.\nb. MEV (transaction ordering) – see mevboost.pics.\n\nRewards 1a, 1b, & 2a are well understood and “in the view” of the protocol. MEV rewards present a more serious challenge because fully capturing the value realized by transaction ordering is difficult. Unlike the other rewards, even the amount of MEV in a block is unknowable for all intents and purposes (as a permissionless and pseudonymous system, it’s impossible to trace who controls each account and any corresponding offchain activity that may be profitable in tandem). MEV also changes dramatically over time (e.g., as a function of price volatility), resulting in execution layer rewards having a much higher variance than the consensus layer rewards. Further, the Ethereum protocol, as implemented, has no insight into the MEV being produced and extracted by its transactions. To improve protocol visibility into MEV, many mechanisms try to approximate the MEV in a given block; we refer to these as MEV oracles. Block-space distribution mechanisms generally have the potential to produce such an oracle, making the protocol “MEV-aware.”\nThis suggests the question, why does the protocol care about being MEV-aware? One answer: MEV awareness may increase the protocol’s ability to preserve the homogeneity of validator rewards, even if validators have varying degrees of sophistication. For example, if the protocol could accurately burn all MEV, then the validator incentives would be fully in the protocol’s view (just like 1a, 1b, & 2a above). Alternatively, a mechanism that shares all MEV among validators regardless of their sophistication (e.g., mev-smoothing) would seem to promote a larger, more diverse and decentralized validator set, while keeping the MEV rewards as an extra incentivization to stake. Without MEV awareness, the validators best equipped to extract or smooth MEV (e.g., due to relationships with block builders, proprietary algorithms/software, access to exclusive order flow, & economies of scale) may earn disproportionately high rewards and exert significant centralization pressures on the protocol.\nEthereum protocol design strives to keep a decentralized validator set at all costs. It probably goes without saying, but for completeness: the protocol’s credible neutrality, censorship resistance, and permissionlessness are directly downstream of a decentralized validator set.\nBlock-space distribution today\nIn Ethereum today, mev-boost accounts for \\approx 90\\%≈90% of all blocks. Using mev-boost, proposers (the validator randomly selected as the leader) sell their block-building rights to the highest paying bidder through an auction. The figure below demonstrates this flow (we exclude the relays because they functionally serve as an extension of the builders).\nupload_5f698b1a28978bd8f9779e596c471d9a718×1420 64.3 KB\n.\nProposers are incentivized to outsource their block building because builders (the canonical name for MEV-extracting agents specializing in sequencing transactions) pay them more than they would have earned had they built the block themselves. Circling back to our goal of “preserving the homogeneity of validator rewards in the presence of MEV,” we see that mev-boost allows access to the builder market for all validators, effectively preserving near-equivalent MEV rewards among solo stakers and professional staking service providers – great! But…\nOf course, there is a but… mev-boost has issues that continue to rankle some of the Ethereum community. Without being exhaustive, a few of the negative side-effects of taking the mev-boost medicine are:\n\nRelays – These trusted-third parties broker the sale of blocks between proposers and builders. The immense reliance on relays increases the fragility of the protocol as a whole, as demonstrated through repeated, incidents, involving, relays. Further, since relays have no inherent revenue stream, more exotic (and closed-source) methods of capturing margins (e.g., timing games as a service and bid adjustments) are being implemented.\nOut-of-protocol software is brittle – Beyond the relays, participation in the mev-boost market requires validators to run additional software. The standard suite for solo staking now involves running four binaries: (i) the consensus beacon node, (ii) the consensus validator client, (iii) the execution client, and (iv) mev-boost. Beyond the significant overhead for solo stakers, reliance on this software also provides another potential point of failure during hard forks. See the Shapella incident and the Dencun upgrade for an example of the complexity induced by having more out-of-protocol software.\nBuilder centralization and censorship – While this is likely inevitable, builder centralization was accelerated by the mass adoption of mev-boost. Three builders account for \\approx 95\\%≈95% of mev-boost blocks (85\\%85% of all Ethereum blocks). mev-boost implements an open-outcry, first-price, winner-takes-all auction, leading to high levels of builder concentration and strategic, bidding. Without inclusion lists or another censorship-resistance gadget, builders have extreme influence over transaction inclusion and exclusion – see censorship.pics.\nTiming games – While timing games are known to be a fundamental issue in Proof-of-Stake protocols, mev-boost pushes staking service providers to compete on thin margins. Additionally, relays (who conduct mev-boost auctions on the proposer’s behalf) serve as sophisticated middlemen facilitating timing games. Thus, we have seen marketing endorsing playing timing games to boost the yield from staking with a specific provider.\n\n“OK, OK … blah blah … we have heard this story before … tell me something I don’t know.” (\\leftarrow← h/t Barnabé for the aptly-named, 14k-views on youtube, musical reference.)\n(2) – Enumeration\nObligatory ‘stage-setting’ out of the way, let’s look a little more carefully at the ~essence~ of a block-space distribution mechanism.\nupload_cdbf47258422c2a96ea2903ce113a113900×599 89.1 KB\n^ “Is that what I think it is?”\nThe elements of block-space distribution\nConsider the game of acquiring block space; MEV incentivizes agents to participate, while the combination of in-protocol and out-of-protocol software defines the rules. When designing this game, what elements should be considered? To answer this question, we use a familiar rhetorical pattern of “who, what, when, where, & how” (hopefully Section 1 sufficiently answered “why”), which we refer to as the W^4H questions. (\\leftarrow← h/t Barnabé pt. 2 for the connection to “Who Gets What – and Why”).\n\nWho controls the outcome of the game?\nWhat is the good that players are competing for?\nWhen does the game take place?\nWhere does the MEV oracle come from?\nHow is the block builder chosen?\n\nThese questions might seem overly simplistic, but when considered in isolation, each can be viewed as an axis in the design space to measure mechanisms. To demonstrate this, we highlight a few different species from the block-space distribution mechanism genus that have been explored in the past. While they may feel disjointed and unrelated, their relationship is clarified by understanding how they answer the W^4H questions.\nExecution tickets and other animals\nupload_23e73e8aae1d7223973af83053d41ebc922×1404 168 KB\n^ fantastic book.\nWe present a compendium of many different proposed mechanisms. Note that this is only a subset of the rather substantial literature around these designs – cf. infinite buffet. For each of the following, we summarize only the key ideas (see related work for more).\n\nExecution tickets\n\nKey ideas – Block building and proposing rights are sold directly through “tickets” issued by the protocol. Ticket holders are randomly sampled to become block builders with a fixed lookahead. The ticket holder has the authority to produce a block at the assigned slot.\n\nBlock-auction PBS\n\nKey ideas – The protocol bestows block production rights through a random leader-election process. The selected validator can sell their block outright to the builder market or build it locally. The builder must ~commit to a specific block~ when bidding in the auction. mev-boost is an out-of-protocol instantiation of block-auction PBS; enshrined PBS (ePBS), as originally presented, is the in-protocol equivalent.\n\nMEV-burn/mev-smoothing\n\nKey ideas – A committee is tasked with enforcing a minimum value over the bid the proposer selects in an auction. By requiring the proposer to choose a “large enough” bid, an MEV oracle is created. The MEV is either smoothed between committee members or burned (smoothed over all ETH holders).\n\nSlot-auction PBS\n\nKey ideas – Similar to block-auction PBS but instead sells the slot to the builder market ~without~ requiring a commitment to a specific block – sometimes referred to as block space futures. By not requiring the builders to commit to a particular block, future slots may be auctioned off ahead of time rather than waiting until the slot itself.\n\nPartial-block auction\n\nKey ideas – Allows a more flexible unit for selling block-space. Instead of selling the full block or slot, allow proposers to sell some of their block, e.g., the top-of-block (which is the most valuable for arbitrageurs), while retaining the rest-of-block construction. Live in other Proof-of-Stake networks, e.g., Jito’s block engine and Skip MEV lane.\n\nAPS-burn a.k.a. Execution Auction (nomenclature in flux & the EA acronym has a bit of … baggage)\n\nKey ideas – A brand new proposal from Barnabé which compels a proposer to auction off the block building and proposing rights ahead of time. The slot is sold ex-ante (a fixed amount of time in advance) without requiring a commitment to a specific block; a committee (à la mev-burn/smoothing) enforces the winning bid is sufficiently large.\n\nWe know, we know – it’s a lot to keep track of; it’s nearly a full-time job just to stay abreast of all these acronyms. But by comparing these proposals along the axes laid out by the W^4H questions, we can see how they all fit together as different parts of the same design space.\nApplying W^4H: a comparative analysis\nFor each of the five W^4H questions, we describe different trade-offs made by the aforementioned proposals. For brevity, we don’t analyze each question for each proposal; we instead focus on highlighting key differences arising from each line of questioning.\n\nWho controls the outcome of the game?\n\nWith execution tickets, the protocol dictates the winner of the game by randomly choosing from the set of ticket holders.\nWith block-auction PBS, the proposer (protocol-elected leader) unilaterally chooses the winner of the game.\nWith mev-burn, the proposer still chooses the winner, but the winning bid is constrained by the committee, reducing the proposer’s agency.\n\nWhat is the good that players are competing for?\n\nWith block-auction PBS, the entire block is sold, but bids must commit to the block contents.\nWith slot-auction PBS, the entire block is sold, but without any specific block commitment.\nWith partial-block PBS, a portion of the block is sold.\n\nWhen does the game take place?\n\nWith block-auction PBS, the auction takes place during the slot.\nWith slot-auction PBS, the auction may take place many slots (e.g., 32) ahead of time because there is no block-content commitment.\nWith execution tickets, the tickets are assigned to slots at a fixed lookahead after being sold ex-ante by the protocol (more on the ticket-selling model we use below).\n\nWhere does the MEV oracle come from?\n\nWith mev-burn/smoothing, a committee enforces that a sufficiently large bid is selected as the winner; this bid size is the oracle.\nWith execution tickets, the total money spent on tickets serves as the oracle.\n\nHow is the block builder chosen?\n\nIn block-auction PBS, any outsourced block production has a winner-take-all allocation, with the highest bidder granted the block-building rights.\nWithin execution tickets, many different allocation mechanisms can be implemented. In the original proposal, for example, where a random ticket is selected, the mechanism is ‘proportional-to-ticket-count’; in this case, the highest paying bidder (whoever holds the most tickets) merely has the highest probability of being selected, meaning they are not guaranteed the block building rights.\nIf that (^) seems opaque, don’t worry. The entire following section is a deep dive into these different allocations.\n\nMotivational interlude\nBefore continuing, let’s review our original motivation for block-space distribution mechanisms:\n\nBlock-space distribution mechanisms aim to preserve the homogeneity of validator rewards in the presence of MEV.\n\nThis is a great grounding, but if that is our only goal, why not just continue using mev-boost? Well, remember that mev-boost has some negative side effects that we probably want the endgame protocol to be resilient against. We highlight four other potential design goals of a block-space distribution mechanism:\n\nEncouraging a wider set of builders to be competitive.\nAllow validators and builders to interact trustlessly.\nIncorporating MEV-awareness into the base layer protocol.\nRemoving MEV from validator rewards altogether.\n\nNote that while (1, 2, & 3) appear relatively uncontroversial (*knock on wood*), (4) is more opinionated (and requires (3) as a pre-condition). The protocol may hope to eliminate MEV rewards from validator rewards as a means to ensure that the consensus layer rewards (what the protocol controls) more accurately reflect the full incentives of the system. This also ties into questions around staking macro-economics and the idea of protocol, issuance – a much more politically-charged discussion. On the other hand, MEV rewards are a byproduct of network usage; MEV could instead be seen as a value capture mechanism for the native token. We aren’t trying to address these questions here but rather explore how different answers to them would shape the design of the mechanism.\nWhat can we do at the protocol-design level to align with these desiderata? As laid out above, there are many trade-offs to consider, but in the following section, we examine “How is the block builder chosen?” to improve on some of these dimensions.\n(3) – Interrogation\nEditorial note: As mentioned earlier, this section is longer and more technical than the others – feel free to skip to Section 4 if you are time (or interest) constrained!\nSection goal: To demonstrate the quantitative trade-off between MEV-oracle quality and the “fairness” of the two most familiar approaches to allocating block proposer rights, which we call Proportional-all-pay and Winner-take-all.\nWe aim to accomplish this with the following subsections:\n\nPreliminaries – Motivate the fixed-price, unlimited-quantity execution ticket sale mechanism we use.\nModel - Introduce the notation needed to analyze the model.\nFamiliar allocation mechanisms - Describe the Proportional-all-pay and Winner-take-all mechanisms using the established framework.\nComparing the outcomes - Calculate the resulting equilibria in a two-player example.\nAside #1: Calculating equilibrium bids - Derive the equilibria in the general case.\nAside #2: Tullock Contests - Contextualize the model as a Tullock Contest and draw connections to the existing literature.\n\nLet’s dig in.\nPreliminaries\nBefore diving into the space of allocation mechanisms made possible with execution tickets, we must first set up the model. Consider a protocol that sells execution tickets with the following rules:\n\nthe price is fixed at 1 WEI, and\nunlimited tickets can be bought and sold from the protocol.\n\nNote: this version of execution tickets is effectively equivalent to creating two disjoint staking mechanisms – one each for attesting and proposing. Small changes in the design, e.g., not allowing tickets to be resold to the protocol, may have massive implications for how the market plays out, but that isn’t the focus of this article. Instead, we narrowly explore the question of block-space allocation, given an existing ticket holder set.\nNotably, the set of block producers is disjoint (from the protocol’s perspective) from the set of attesters – individuals must select which part of the protocol they participate in by deciding whether to stake or buy tickets. The secondary ticket market may evolve as a venue for selling the building rights just in time to the builder market (as is done in mev-boost today).\nupload_45a1fa23182dd6a28c2c07dc2479f1501428×1468 195 KB\n\\cdot⋅\nSeparately, builders may choose to interact directly with the protocol by buying execution tickets themselves, but their capital may be better utilized as active liquidity, capturing arbitrage across trading venues. Thus, they may prefer buying block space on the secondary market during the just-in-time auction instead.\nWhy restrict ourselves to this posted-price-unlimited-supply mechanism? Two reasons:\n\nIt’s not clear that a sophisticated market could even be implemented in the consensus layer. The clients are optimized to allow any validator with consumer-grade hardware to participate in the network. This desideratum may be incompatible with fast auctions, bonding curves, or other possible ticket-selling mechanisms. Questions around how many tickets are sold, the MEV around onchain ticket-sale inclusion (meta-MEV?!), and the timing (and timing games) of ticket sales seem closer to execution layer concerns than something that could reasonably be implemented by Ethereum consensus while keeping hardware requirements limited.\n\n“One may imagine the inclusion of ET market-related transactions to possibly induce MEV, whether these transactions are included in the beacon block or the execution payload.” – Barnabé in “More pictures about proposers and builders.”\n\nEven if (a big if) the protocol ~could~ implement a more rigid ticket-selling market, the design space for such a mechanism is immense. Many potential pricing mechanisms have been discussed, e.g., bonding curves, 1559-style dynamic pricing, auctions, etc.; making general claims about these remains outside the scope of this post.\n\nTherefore, we focus on the “unlimited, 1 WEI posted-price” version of execution tickets, where the protocol internalizes minimal complexity. With this framing, we can ask the question that is probably burning you up inside, “given a set of execution ticket holders, how should the winner be selected?” … sounds easy enough, right? Turns out there is a good deal we can say, even with such a seemingly simple question; let’s explore a few different options.\nModel\nConsider the repeated game of buying execution tickets to earn MEV rewards for your investment.\n\nDuring each period, each player effectively submits a bid, which is the number of tickets they buy. Denote the vector of bids by \\mathbf{b}𝐛, where b_i𝑏𝑖 is the bid of the i^{th}𝑖𝑡ℎ player.\nEach player has a valuation for winning the block production rights. Denote the vector of valuations by \\mathbf{v}𝐯, where v_i𝑣𝑖 is the value of the i^{th}𝑖𝑡ℎ player.\nAt each time step, an allocation mechanism determines each player’s allocation based on the vector of bids. Assuming bidders are risk-neutral (i.e., don’t care between winning 2 ETH with probability 0.50.5 vs. 1 ETH with probability 11), we can equivalently say that they are each allocated “some portion” of the block, which can be alternatively be interpreted as “the probability that they win a given block.” In an n𝑛 player game, let x: \\mathbf{b} \\rightarrow [0,1]^n𝑥 :𝐛 →[0,1]𝑛 denote the map implementing an allocation mechanism, where x_i(\\mathbf{b})𝑥𝑖(𝐛) is the allocation of the i^{th}𝑖𝑡ℎ player, under the constraint that \\sum_i x_i(\\mathbf{b}) =1∑𝑖𝑥𝑖(𝐛) =1 (i.e., the mechanism fully allocates).\nEach player’s payment is collected at each round. Let p: \\mathbf{b} \\rightarrow \\mathbb{R}_{\\geq 0}^n𝑝 :𝐛 →ℝ𝑛≥0 denote the payment rule determined by the set of bids, where p_i(\\mathbf{b})𝑝𝑖(𝐛) is the payment of the i^{th}𝑖𝑡ℎ player.\nThe utility function of each player in the game is, U_i(\\mathbf{b}) = v_i x_i(\\mathbf{b}) - p_i(\\mathbf{b})𝑈𝑖(𝐛) =𝑣𝑖𝑥𝑖(𝐛) −𝑝𝑖(𝐛). The intuition is that “a player’s utility is their value for winning multiplied by the amount they won, less their payment.”\n\nFamiliar allocation mechanisms\nConsider two (quite different) possible mechanisms.\nProportional-all-pay (a slight modification to the original execution tickets proposal)\n\nDuring each round, all players submit a bid. Denote the vector of bids by \\mathbf{b}𝐛.\nThe probability that a bid wins the game is the value of the bid divided by the sum of all the values of the bids,\n\nx_i(\\mathbf{b}) = \\frac{b_i}{\\sum_j b_j}.\n𝑥𝑖(𝐛)=𝑏𝑖∑𝑗𝑏𝑗.\n\nEach player pays their bid, no matter the outcome of the game (hence “all-pay”), p_i(\\mathbf{b}) = b_i.𝑝𝑖(𝐛) =𝑏𝑖.^{[1]}[1]\n\nWinner-take-all (the current implementation of PBS)\n\nDuring each round, all players submit a bid. Denote the vector of bids by \\mathbf{b}𝐛.\nThe highest bidder wins the game, so x_i(\\mathbf{b}) = 1𝑥𝑖(𝐛) =1 if \\max(\\mathbf{b}) = b_imax(𝐛) =𝑏𝑖 and x_i(\\mathbf{b}) = 0𝑥𝑖(𝐛) =0 otherwise (where ties are broken in favor of the lower index bidder, say).\nOnly the winning player pays the value of their bid, so p_i(\\mathbf{b}) = b_i𝑝𝑖(𝐛) =𝑏𝑖 if \\max(\\mathbf{b}) = b_imax(𝐛) =𝑏𝑖 and p_i(\\mathbf{b}) = 0𝑝𝑖(𝐛) =0 otherwise (same tie-breaking as above).^{[2]}[2]\n\nComparing the outcomes\nTo demonstrate the different outcomes from these two mechanisms, consider the two-player game where Player 1 has a valuation of v_1 = 4𝑣1 =4 and Player 2 has a valuation of v_2 = 2.𝑣2 =2. (We consider a complete information setting in which the individual values are common knowledge. To see how the equilibria bid is calculated and for extended discussion, see Aside 1.)\n\nProportional-all-pay outcome:\n\nEquilibrium Bids: \\qquad\\,\\,\\,\\;\\;\\; b_1 = 8/9 𝑏1 =8/9, \\,b_2 = 4/9 𝑏2 =4/9\nEquilibrium Allocations: \\;\\;\\; x_1 = 2/3 𝑥1 =2/3, x_2 = 1/3𝑥2 =1/3\nEquilibrium Payments: \\;\\;\\;\\; p_1 = 8/9 𝑝1 =8/9, \\,p_2 = 4/9 𝑝2 =4/9\n\nThis all should feel intuitively correct; with v_1 = 2 \\cdot v_2𝑣1 =2 ⋅𝑣2 (Player 1 has 2x the value for the block), Player 1 bids, receives and pays twice as much as Player 2.\n\nWinner-take-all outcome:\n\nEquilibrium Bids: \\qquad\\,\\,\\,\\;\\;\\; b_1 = 2+\\epsilon 𝑏1 =2 +𝜖, b_2 = 2𝑏2 =2\nEquilibrium Allocations: \\;\\;\\; x_1 = 1 𝑥1 =1, \\quad\\;\\; x_2 = 0 𝑥2 =0\nEquilibrium Payments: \\;\\;\\;\\,\\, p_1 = 2+\\epsilon 𝑝1 =2 +𝜖, p_2 = 0𝑝2 =0\n\nThis is pretty different. Player 1 bids and pays just over Player 2’s value (we use \\epsilon𝜖 to denote a small amount), receiving the entire allocation. Player 2 receives nothing and pays nothing.^{[3]}[3]\nNow consider the “revenue” (or the sum of the bids collected by the mechanism) generated from each case:\n\nProportional-all-pay revenue: b_1 + b_2 = 4/3𝑏1 +𝑏2 =4/3\nWinner-take-all revenue: \\qquad\\quad\\,\\,\\,\\;\\;\\;\\; b_1 = 2+\\epsilon 𝑏1 =2 +𝜖\n\nWinner-take-all has better revenue, corresponding to a more accurate MEV oracle (and thus more MEV burned or smoothed by the protocol) than Proportional-all-pay. Intuitively, by allocating block-production rights to players with lower values (as Proportional-all-pay does), we forgo revenue we would have received had we simply allocated the entire rights to the player with the highest value. We point the interested reader to Aside 1 for a more complete treatment.\nAnother factor to consider is the “fairness” or “distribution” of the allocation mechanism. For example, suppose we agree on the metric: \\text{fairness} = \\sqrt{x_1 \\cdot x_2}fairness =√𝑥1⋅𝑥2 (we use the geometric mean because if x_1 + x_2𝑥1 +𝑥2 has a fixed sum, the geometric mean is maximized at x_1 = x_2𝑥1 =𝑥2 and zero if either x_1,x_2𝑥1,𝑥2 is zero). Now, let’s look at the fairness outcomes of the two candidate mechanisms:\n\nProportional-all-pay fairness: \\sqrt{1/3 \\cdot 2/3} \\approx 0.471√1/3⋅2/3 ≈0.471\nWinner-take-all fairness: \\qquad\\qquad\\;\\,\\;\\sqrt{1 \\cdot 0} = 0 √1⋅0 =0\n\nHere, the “performance” of the two mechanisms flips – the Winner-take-all is less fair because Player 2 has no chance of winning the game with a lower value. In the Proportional-all-pay, Player 2 can hope to win some blocks despite bidding a lower value. As another example, consider the case where v_1=v_2+\\epsilon𝑣1 =𝑣2 +𝜖. The Winner-take-all mechanism allocates all the rights to Player 1, while the Proportional-all-pay splits the rights approximately in half.\n\nBrief note: why might the protocol care about fairness? In a decentralized protocol, a single actor having too much power undermines the credible neutrality of the system. As such, the protocol may be willing to “pay” (in the form of reduced revenue) to ensure that a resource is more evenly distributed among players. Alternatively, we could consider this a measure of “entropy” or even simply randomness being injected into the outcome of the game to try to reduce the influence the most dominant player can have.\n\nThis leads to the punchline from this small example: a fundamental trade-off exists between MEV-oracle quality and fairness. The Proportional-all-pay mechanism (and hence the original execution tickets proposal) is fairer because both players win the game with some probability, incentivizing them each (but more importantly, the higher value player) to shade their bid accordingly, lowering the revenue, and thus the MEV-oracle accuracy, of the mechanism. The first price mechanism elicits higher bids since bidders only pay if they win the entire block production rights, increasing the revenue, but this Winner-take-all dynamic makes the allocation less fair.\nOpen question: is Proportional-all-pay an “optimal” Sybil-proof mechanism? In the permissionless setting, we only consider Sybil-proof mechanisms, where a player doesn’t benefit from splitting their bid into multiple identities. We posit that the Proportional-all-pay mechanism sits in the Goldilock’s Zone of a Sybil-proof mechanism that gets both good revenue/MEV-oracle accuracy and fairness. We leave as an interesting open problem to determine the extent to which the Proportional-all-pay mechanism’s “optimality” (e.g., we were unable to find another Sybil-proof mechanism that dominates it in both revenue and fairness).\nAside #1 – Calculating equilibrium bids\nConvenience link to skip to the conclusion for the less-keen reader \nIn the numerical example above, we provide the equilibrium bids for the Winner-take-all and Proportional-all-pay mechanisms without proof. How can these be determined generally (e.g., continuing to assume that bidders’ values are common knowledge)?^{[4]}[4]\nThe Winner-take-all is the familiar First Price Auction setting. In such auctions, the complete information Pure-Nash equilibrium has the two highest-value bidders, each bidding the second-highest bidder’s value, with every other agent bidding below this. In effect, we expect that the highest-value bidder always wins while paying the second highest bidder’s value (we represent this simply as b_1=b_2+\\epsilon𝑏1 =𝑏2 +𝜖, though you could equivalently tie-break in favor of the higher-value player).\nIn the Proportional-all-pay setting, each player has the utility,\n\n\\begin{align}\nU_i (\\mathbf{b}) &= v_i \\cdot x_i(\\mathbf{b}) - b_i \\\\\n&= v_i \\cdot \\frac{b_i}{\\sum_j b_j} - b_i.\n\\end{align}\n𝑈𝑖(𝐛)=𝑣𝑖⋅𝑥𝑖(𝐛)−𝑏𝑖=𝑣𝑖⋅𝑏𝑖∑𝑗𝑏𝑗−𝑏𝑖.\nTo determine the existence of a Pure Nash Equilibrium, we consider each player’s first- and second-order conditions. Let \\mathbf{b}^*𝐛∗ denote the candidate equilibrium set of bids.\n\nFirst-order condition: \\partial U_i / \\partial b_i (\\mathbf{b^*}) = 0𝜕𝑈𝑖/𝜕𝑏𝑖(𝐛∗) =0 (or \\partial U_i / \\partial b_i (\\mathbf{b^*}) \\leq 0, \\;\\forall i \\text{ s.t. } b^*_i=0𝜕𝑈𝑖/𝜕𝑏𝑖(𝐛∗) ≤0, ∀𝑖 s.t. 𝑏∗𝑖 =0.)\n\nIntuitively, this condition checks a non-zero-bidding player is (to first order) locally indifferent to small changes in its bid.\n\nSecond-order condition: \\partial^2 U_i / \\partial b_i^2 < 0𝜕2𝑈𝑖/𝜕𝑏2𝑖 <0\n\nIntuitively, this condition ensures that the utility function is concave, implying that locally best responses are globally best for all players.\n\nIn our simple two-player example in the Proportional-all-pay setting, we have the following.\n\n\\begin{align}\n\\frac{\\partial U_1}{\\partial b_1}(\\mathbf{b}) = \\frac{v_1 b_2}{(b_1 + b_2)^2} - 1 = 0 \\; , \\quad \\frac{\\partial U_2}{\\partial b_2}(\\mathbf{b}) = \\frac{v_2 b_1}{(b_1 + b_2)^2} - 1 = 0\n\\end{align}\n𝜕𝑈1𝜕𝑏1(𝐛)=𝑣1𝑏2(𝑏1+𝑏2)2−1=0,𝜕𝑈2𝜕𝑏2(𝐛)=𝑣2𝑏1(𝑏1+𝑏2)2−1=0\nThis system can be solved to find the equilibrium bids, \\mathbf{b}^*𝐛∗,\n\n\\begin{align}\nb^*_1 = \\frac{v_1^2 v_2}{(v_1 + v_2)^2}\\; , \\quad b^*_2 = \\frac{v_2^2 v_1}{(v_1 + v_2)^2}.\n\\end{align}\n𝑏∗1=𝑣21𝑣2(𝑣1+𝑣2)2,𝑏∗2=𝑣22𝑣1(𝑣1+𝑣2)2.\nFor our toy example, we have v_1=4, \\; v_2=2 \\implies b_1^* = 32/36, \\; b_2^* = 16/36𝑣1 =4, 𝑣2 =2 ⟹ 𝑏∗1 =32/36, 𝑏∗2 =16/36. We can verify our first-order conditions\n\n\\begin{align}\n\\frac{4 \\cdot 16/36}{16/9} - 1 = 0 \\; , \\quad \\frac{2 \\cdot 32/36}{16/9} - 1 = 0 \\quad \\checkmark\n\\end{align}\n4⋅16/3616/9−1=0,2⋅32/3616/9−1=0✓\nThe second-order conditions can also be verified – this is left as an exercise for the reader \nAside #2 – Tullock Contests\nLast chance to skip to the conclusion. (If you continue, by definition, you are the “interested reader” – congrats.)\nThe model described above is established in the algorithmic game theory literature as a Tullock Contest – named for Gordon Tullock, who explored the idea in his seminal work, “Efficient Rent Seeking.” He motivates this study by considering situations where investment is made before the outcome is known and where the investments might not transfer easily between participants, e.g., political spending.\n\n“Suppose, for example, that we organize a lobby in Washington for the purpose of raising the price of milk and are unsuccessful. We cannot simply transfer our collection of contacts, influences, past bribes, and so forth to the steel manufacturers’ lobby. In general, our investments are too specialized, and, in many cases, they are matters of very particular and detailed goodwill to a specific organization. It is true that we could sell the steel lobby our lobbyists with their connections and perhaps our mailing list. But presumably, all these things have been bought by us at their proper cost. Our investment has not paid, but there is nothing left to transfer.” – Gordon Tullock (1980)\n\nThis allocation mechanism has been applied in the previous crypto literature as well. Back in 2018 (ancient history in crypto-terms), Arnosti and Weinberg wrote “Bitcoin: A natural oligopoly,” which demonstrates that even small operating cost advantages among miners in a Proof-of-Work system lead to surprisingly concentrated equilibria. Similarly, Bahrani, Garimidi, and Roughgarden (these names sound familiar :D) explored the centralization effects of heterogeneity in block building skill in “Centralization in Block Building and Proposer-Builder Separation.” There appears to be a deep relationship between permissionless crypto-economic systems, where anti-Sybil mechanisms typically require financial investment for participation, and Tullock Contests – more on this Soon™ (maybe).\n(4) – Extrapolation\nPhew, thanks for hanging in there; let’s take stock of what we learned. Section 3 demonstrates the fundamental trade-off between MEV-oracle accuracy and fairness of an instantiation of an execution ticket mechanism. A protocol may be willing to *pay* (in the form of reduced revenue) for more distribution and entropy with the goal of improving and maintaining the protocol’s credible neutrality. Further, using the model to derive equilibrium bids helps inform how we may expect agents to respond to various allocation and payment rules. Neat – our framework led to some interesting and hopefully helpful insights! Maybe we can extend it to other problems in the space as well?\nFurther questions that this specific model may help answer (returning to three of our W^4 questions):\n\nWhat is the good that players are competing for?\n\nCan we extend the model dimensionality, allowing different players to have different values for portions of the block (e.g., an arbitrageur may disproportionately value the top of a block but have zero value for the remainder)?\n\nWhen does the game take place?\n\nHow does the MEV-oracle accuracy change if the game takes place far ahead of time versus during the slot itself (e.g., pricing future expected MEV versus present realizable MEV)?\n\nHow is the block builder chosen?\n\nAre there other Sybil-proof mechanisms that dominate Proportional-all-pay in both revenue and fairness?\nCan we more formally characterize the fundamental trade-offs between revenue and fairness?\nGiven the Sybil-proofness constraint, what alternative allocation and payment rules should be explored (e.g., Tullock contests where the allocation rule is parameterized by \\alpha>1𝛼 >1 where x_i = b_i^\\alpha / \\sum_j b_j^\\alpha𝑥𝑖 =𝑏𝛼𝑖/∑𝑗𝑏𝛼𝑗), and can we identify the optimal choice?\n\nZooming back out, other versions of the W^4H questions may require different models to reason about.\n\nWho controls the outcome of the game?\n\nIn the committee-enforced version of these mechanisms, how could collusive behavior emerge?\nIf the just-in-time block auction continues to take place out-of-protocol, should we explicitly describe the secondary market?\n\nWhen does the game take place?\n\nHow critical is network latency when considering lookahead block-space sales versus same-slot? Is it worth modeling the partially-synchronous setting?\nHow do block builder valuations change if multi-slot MEV is feasible?\n\nWhere does the MEV oracle come from?\n\nIf it comes from the committee, are there incentives for committee members to behave dishonestly?\nDo such incentives depend on whether protocol-captured MEV is burned or smoothed?\n\nAs per usual, open questions abound, but we hope (a) W^4H questions help expand the understanding of block-space distribution mechanisms and (b) the deep dive into allocation mechanisms helps inform the potential design space of execution tickets.\nupload_a24cdf5b513fb4e410700573687adcd61920×1374 164 KB\n^ The world once we figure out MEV.\nExcited to be here with y’all.\n— made with by mike, pranav, & dr. tim roughgarden.\n\nfootnotes\n^{[1]}[1]: The “all-pay” feature is made possible by burning the price paid for each ticket. ︎\n^{[2]}[2]: The “winner-pay” version could be done by refunding all non-winning ticket holders their payment at the end of each round. ︎\n^{[3]}[3]: As mentioned earlier, simply refunding the non-winning tickets instantiates the “winner-pays” property. ︎\n^{[4]}[4]: This is primarily for tractability in calculating equilibria analytically. Although a strong assumption, it’s not unreasonable in the context of lookahead auctions where bidders might have established prior distributions on their competitor’s valuations. We also view the insights from studying the complete-information equilibria as valuable heuristics for how we may expect these mechanisms to behave in practice. ︎\n\n A design for APS-burn in the context of a Decentralized L2\n\n Exploring Sophisticated Execution Proposers for Ethereum\n\n Future-Proofing Preconfirmations\n\n The case for decentralization increasing efficiency is overstated\n\n Agent-based Simulation of Execution Tickets\n\n 2\n\n read \n\n 17\n min\n\n post by M1kuW1ll on Jun 13, 2024\n\n M1kuW1ll\n\n Thanks for the interesting post \nIn the Winner-take-all mechanism, do you think there is a possibility where players can (be incentivized to) cooperate (or collude) to minimize their bid value, share an equal allocation, and maximize their utility?\n\nWith the small example above, let’s say both Player 1 and Player 2 bid \\epsilon𝜖 (small amount) and their allocation will be 0.5 with some kind of tie-breaker. Such that their utility can be given by:\nU_1 = 4 \\times 0.5 - \\epsilon𝑈1 =4 ×0.5 −𝜖 and U_2 = 2 \\times 0.5 - \\epsilon.𝑈2 =2 ×0.5 −𝜖.\nThe utility of Player 1 is the same, while the utility of Player 2 is higher. However, under such conditions, the “revenue” collected by the mechanism is minimal, corresponding to an inaccurate MEV oracle for this Winner-take-all mechanism.\n\n post by mikeneuder on Jun 19, 2024\n\n mikeneuder\n\n Thanks for your reply! In the WTA setting, only a single player wins. If they both bid \\epsilon𝜖 and tie broke in favor of Player 1 (WLOG), then the sharing of the block would need to take place out-of-band, and they would have to have to trust each other. In general, in a one-shot game, a PNE mayn’t be predictive in case of collusion. Consider the simple prisoner’s dilemma; if there is collusion, both players can communicate and decide to cooperate out-of-band, resulting in different behavior than the PNE would indicate. In repeated or dynamic games, there is a chance that the PNE can handle collusion though future iterations of the game, but that’s not the model we are considering! The point is, if there was some form of collusion where the each bid \\epsilon𝜖, someone else would have a large incentrive to come in and defect, bidding \\epsilon + \\delta𝜖 +𝛿 and winning the auction for well below their true value.\n\n 21 days later\n\n post by captgouda24 on Jul 11, 2024\n\n captgouda24\n\n Hi. I hope it is not too late to comment. Some of the cost and benefits of decentralization are already internalized by the bidders. If controlling a greater portion of the blockchain would expose a bidder to greater government interference, then that should already be reflected in their distribution of values. I am concerned that the more “fair” distribution mechanism will double-count the costs of centralization.\nIndeed, if we take the extreme case of two bidders trying to buy a stream of assets, and this is the entire economy, shouldn’t the entire cost of centralization be internalized? Why wouldn’t it be?\n\n post by r4f4ss on Jul 12, 2024\n\n r4f4ss\n\n Thanks for the excellent post which works as a systematic review of the subject.\nThere is the possibility of two mixed mechanisms. The first one has Proportional-all-pay probabilities of win and only the winner pays like in Winner-take-all mechanism:\n\nDuring each round, all players submit a bid. Denote the vector of bids by b𝑏.\n\nThe probability that a bid wins the game is the value of the bid divided by the sum of all the values of the bids,\n\nxi(b)=bi∑jbj.\n𝑥𝑖(𝑏)=𝑏𝑖∑𝑗𝑏𝑗.\n\nOnly the winning player pays the value of his bid.\n\nIn the second mixed mechanism, all players pay, but only the highest bidder wins the game, and it only makes sense if the bids are secret. I have no idea about the complexity of implementing this mechanism, if possible.\nThe former is not more complex to implement and execute than the others mentioned in the post and its metrics values of fairness and revenue may be different.\n\n Powered by Discourse","tokens":11224,"squid":"spider-04","role":"Research Spider","at":1791348311546,"hash":"73f76698a2c8699e1512f1e9a8969147b590fb80"}
{"url":"https://docs.chain.link/datalink/data-quality-responsibility","domain":"docs.chain.link","title":"Data Quality, Responsibility & Trust Model | Chainlink Documentation","text":"Data Quality, Responsibility & Trust ModelDataLink provides infrastructure for data providers to make their data available onchain. The majority of DataLink feeds use a single-source model where each feed provides data from one specific provider. This page explains the single-source model, the role of the Data Provider, and the resulting implications for integrating protocols. \n\nSingle-Source Data vs. Aggregated DataA key distinction of DataLink compared to Chainlink Data Feeds or Data Streams is its single-source nature. While Data Feeds and Data Streams commonly aggregate data from multiple sources to create a robust market-wide price, DataLink feeds provide access to bespoke and proprietary data from one specific provider.This single-source model enables access to specialized and unique datasets but introduces different trust assumptions and risk considerations.\n\nKey Differences SummarizedWhile DataLink leverages the same underlying Chainlink Data Streams infrastructure for secure data transport and report signing, the responsibility model differs for single-source feeds:AspectChainlink Data Feeds / Streams (Aggregated)Single-Source DataLink feedsData QualityChainlink contributes to quality via multi-source aggregation and monitoring.The Data Provider is solely responsible for ensuring data quality.Data SourcesMultiple vetted data sources aggregated by Chainlink DONs.A single proprietary source managed by the Data Provider. This means no inherent Data Provider redundancy; if the Data Provider experiences an outage, data flow for that specific feed ceases.Chainlink's RoleData aggregation, quality monitoring, outlier detection, secure transport, report signing, infrastructure reliability, and delivery.Secure transport, report signing, and infrastructure reliability. No validation of source data quality.Trust AssumptionChainlink's data aggregation methodology and infrastructure security.The specific Data Provider's methodology and reliability, plus Chainlink's infrastructure security.SupportChainlink Labs provides support for feed issues.Data Provider handles all data-related support.\n\nProtocol Responsibilities & Risk ManagementGiven the provider-centric responsibility model and single-source nature of most DataLink feeds, protocols integrating these feeds must take extra precautions:\nPerform Due Diligence: Thoroughly vet the specific Data Provider. Understand their data sourcing, calculation methodologies, historical performance, SLAs, and support processes before integration. Assess if their data quality meets your application's specific use case in terms of risk tolerance.\nImplement Fallback Mechanisms: Design robust contingency plans and fallback logic within your application to handle potential inaccuracies, delays, or outages from the single-source DataLink feed. Do not rely solely on one DataLink feed for critical functions without backups.\nMonitor Data Quality: Actively monitor the performance and quality of the integrated DataLink feeds. Compare against other sources if possible.\nUnderstand Risks: Acknowledge that using single-source data carries inherent risks compared to aggregated data. Ensure your users are aware of these risks if applicable.\nEnd users interact with protocols utilizing DataLink at their own risk regarding the quality and reliability of the underlying data provided by the third-party Data Provider. DataLink is offered \"as is\" and \"as available\" without conditions or warranties of any kind. Neither Chainlink Labs, the Chainlink Foundation, nor Chainlink node operators are responsible for unintended outputs from DataLink due to issues in your code, an issue related to any of the issues described in the table set forth above, or downstream issues with API dependencies.By using DataLink, you gain access to valuable specialized data, but you must actively manage the associated risks and understand the trust assumptions involved.\n\n What's next > View the Provider Catalog > Learn about DataLink architecture (pull-based delivery) > Learn how to integrate DataLink (pull-based delivery) > Learn how to integrate DataLink (push-based delivery)","tokens":1034,"squid":"spider-08","role":"Oracle Spider","at":1791348316994,"hash":"458f868fb8a248df50fc4888c8f7972617880fd7"}
{"url":"https://docs.phantom.com/bitcoin/establishing-a-connection","domain":"docs.phantom.com","title":"Establish a connection - Phantom developer documentation","text":"The window.phantom.bitcoin provider has been deprecated.\n​Connect\nOnce an application has detected the provider, it can then request to connect to Phantom by invoking the requestAccounts method. This connection request will prompt the user for permission to share their Bitcoin addresses, indicating that they are willing to interact further. Users must approve a connection request before the app can make additional requests such as signing a message or sending a transaction.\n\nThe requestAccounts method returns a Promise that resolves if the user approves the connection request. Once resolved, it contains an array of the user’s BtcAccount objects. If the user declines the request or closes the pop-up, it will reject (throw when awaited).\nThe array of BtcAccount objects represent the possible addresses that can be used when a user connects with Phantom. This is defined as:\ntype BtcAccount = {\n address: string;\n addressType: \"p2tr\" | \"p2wpkh\" | \"p2sh\" | \"p2pkh\";\n publicKey: string;\n purpose: \"payment\" | \"ordinals\";\n};\n\nWhere:\n\naddress: The Bitcoin address owned by the user.\naddressType: The address’s format. For details, see Bitcoin Design Glossary.\npublicKey: A hex string representing the bytes of the public key of the account.\npurpose: The general purpose of the address. If ordinals, the user prefers to store Ordinals on this address. If payment, the user prefers to store bitcoin on this address.\n\nThe purpose fields represent user preferences and do not represent a guarantee that there will only be Bitcoin on payment addresses or only Ordinals on ordinals addresses. When submitting a transaction, make sure to carefully select UTXOs such that you do not cause the user to accidentally spend a rare or inscribed satoshi.\nThe following is an example of how to connect to Phantom:\n\nconst phantomProvider = getProvider(); // see \"Detecting the Provider\"\nconst accounts = await phantomProvider.requestAccounts();\nconsole.log(accounts);\n/**\n[\n {\n \"address\": \"bc1phajtersv55fwud5xr0t70p5234swy396a6avqhuny0qf83zssvrsm7tl4q\",\n \"publicKey\": \"02435c68c1f20522946e46bcc39f8a19088095939db840e874e1ad2c18f0f2361c\"\n \"addressType\": \"p2tr\"\n \"purpose\": \"ordinals\"\n },\n {\n \"address\": \"bc1qqy4emmf7q623vlf2z4j3pvgfyjkaffx2u3fkpk\",\n \"publicKey\": \"0279f5b4123030accae6c4ca9a17263753a21df2142bbf0ced940d28ca613e87f9\"\n \"addressType\": \"p2wpkh\"\n \"purpose\": \"payment\"\n }\n]\n**/\n\n​Disconnect\nThere is no way for dapps to programmatically disconnect a user. Once a user has established a connection, Phantom will add the website they opened a connection with to a list of Connected Apps. When a user returns to one of these whitelisted sites, Phantom will attempt to reconnect the application automatically. At any time, the user can revoke access to the dapp through their UI by navigating to Settings > Connected Apps. If a user disconnects from a dapp, they will need to reconnect on the subsequent visit before signing a message or sending a transaction.\n\n​Change accounts\nPhantom allows users to manage multiple accounts from within a single extension or mobile app. Whenever a user switches accounts, Phantom will emit an accountsChanged event.\nphantomProvider.on('accountsChanged', (accounts: BtcAccount[]) => {\n console.log('Accounts changed:', accounts);\n});\n\nIf Phantom passes an empty array on accountsChanged, it implies that the user has switched to an account that has not connected to the dapp before (that is, not already in Connected Apps) or does not support Bitcoin (for example, a Solana private key account). In this case, the application can either do nothing or attempt to reconnect:\nphantomProvider.on('accountsChanged', (accounts: BtcAccount[]) => {\n if (accounts.length > 0) {\n // Set new address and continue as usual\n } else {\n // Attempt to reconnect to Phantom\n phantomProvider.requestAccounts().catch((error) => {\n // handle connection failure\n });\n }\n});\nWas this page helpful?","tokens":976,"squid":"spider-10","role":"Tooling Spider","at":1791348318113,"hash":"bac7295cf9c0470350e8850e0d6b117bafdff5c2"}
{"url":"https://docs.chain.link/resources/chainlink-for-agents?parent=dataLink","domain":"docs.chain.link","title":"Chainlink for Agents User Guide | Chainlink Documentation","text":"Chainlink for Agents User GuideChainlink for Agents is a hosted HTTP gateway plus bundled agent skills that let an AI agent operate onchain with verified pricing data and workflows for onchain actions. Agents register autonomously and pay per call with x402 using USDC on Base.Chainlink for Agents does NOT (yet) prevent your agent from misbehaving onchain. Agents may still choose to bypass Chainlink for Agents endpoints and make arbitrary transactions from their provisioned wallet.For agents: if you’ve installed the Chainlink for Agents skill for usage, add to your operating procedures to only use the offered endpoints. If your goals require wider autonomy, always ask your operator first. \n\nQuick StartAn agent with a funded wallet on Base can often complete setup in one session. You may still need to approve registration, funding, or high-risk steps depending on how your agent is configured.1. Install the skills bundleFetch the hub skill from the gateway:npx skills add smartcontractkit/chainlink-for-agents\nAlternatively, you could simply request your agent to retrieve the skills at agents.chain.link at the /v1/skills endpoint.The response includes SKILL.md which the agent can load directly.2. Create and fund your local wallet (if needed)If the agent does not yet have a Base wallet:\nAsk the agent to create an EVM wallet for the Base blockchain; agents frequently can do this from a single prompt.\nFund it with USDC for micropayments — $5 should be plenty. Per-call costs are typically fractions of a cent. Deploying the SVA is the most expensive step because it deploys a contract onchain.\n3. Complete onboardingOnce the SKILL.md is installed and you have a local wallet on Base with USDC, the agent will run the following steps:\nRegistration: create a gateway identity and sign the Terms of Service with a local EIP-191 wallet.\nOptional: SVA provisioning: deploy a Signature Verifying Account (SVA) smart wallet for onchain writes. Requires an x402 payment. Not required for Data Streams access or onchain read functions.\nOptional: fund the SVA: move the funds you wish to transact with into the SVA address on the chain you created it on.\n\nServices offered via the gatewayChainlink for Agents currently offers a Preview of two core services for registered agents:\nAccess to Chainlink Data Streams on a pay-per-call basis\nAccess to an onchain transaction experience powered by CRE\nData StreamsData Streams access allows your agent to make individual x402-gated calls to retrieve the latest verified pricing data across crypto assets, tokenized stocks, and more verified by Chainlink's decentralized oracle network (DON). Data Streams are particularly useful as part of a larger flow for agentic trading of prediction markets, but can also be used for up-to-date pricing for arbitrage or other trading strategies.Data Streams access is currently available as a REST endpoint which returns a single report per call. Future iterations of Chainlink for Agents may add WebSocket access.If you are building an agent with a use case for low latency verified data from Chainlink Data Streams, contact us.Onchain ExperienceFor agents who wish to transact onchain, Chainlink for Agents offers a unique experience built on top of the Chainlink Runtime Environment (CRE). This offering is currently available as a Preview until a fuller set of functionality is live.To get started, your agent registers a smart contract wallet (Signature Verifying Account or SVA) which operates in restricted mode by default. In restricted mode, only endpoint-generated transactions will be delivered to chain by the agent gateway.When your agent wants to transact onchain:\nIt calls an endpoint such as aave-supply and CRE's DON builds the correct calldata for depositing funds into Aave.\nThe agent uses its local wallet to sign the transaction (see EIP-712 Signing for the typed-data model used in similar CRE Connect flows).\nThe transaction is picked up by the DON, relayed to the SVA, and delivered to chain with gas covered. The SVA is the identity for the transaction, not the local wallet.\nChainlink for Agents builds the calldata for each catalog workflow and relays transactions with gas covered, so your agent does not have to figure out—or hallucinate—correct contract calls or manage gas on each chain.Restricted and Unrestricted ModeThe agent's registration may optionally be changed to unrestricted mode, which gives access to the /direct endpoint allowing your agent to submit calldata it constructed itself for signature and delivery to chain. This allows your agent to use funds in the SVA for onchain actions that aren't yet directly supported by specific endpoints. In restricted mode, the calldata is deterministically generated by Chainlink for Agents, aimed at a core set of use cases you will find valuable in this preview offering.Working in unrestricted mode does not offer you the same protections that transactions will be constructed correctly, or that the amount sent or addresses and contracts interacted with are part of the preview offerings.If you are building an agent and have specific onchain use cases you want to see supported, contact us.\n\nThings to KnowChainlink for Agents is in Beta, and there are some important details that will help you and your agent have an improved experience.Terms of ServiceAs part of registration, your agent will use the EOA tied to its identity to sign Chainlink's Terms of Service which covers its actions on your behalf while using the platform.Operating SafelyChainlink for Agents is built to greatly reduce the surface area for mistakes as your agent operates onchain. However, you must still take care to avoid errors. Important ways in which your agent may still lose funds include:\nThe token-transfer and bridge-tokens endpoints allow asset delivery to an arbitrary external address. Your agent can send your money to an incorrect destination where it likely will not be recoverable.\nAll workflow endpoints require the agent to send the amounts you desire. Your agent can still choose to specify the wrong amounts.\nThe agent can set itself to unrestricted mode and gain access to the direct endpoint without requiring explicit approval from you. This allows it to construct its own calldata, which can be delivered to chain via provided pathways.\nIndependent of whether it is operating in unrestricted mode, your agent may still deliver its own transactions to chain bypassing the Chainlink for Agents system.\nBeyond this, operating on blockchains includes inherent risks and you may be exposed to smart contract security risks and token economic risks.Supported Chains and BridgingChainlink for Agents currently operates across Base, Ethereum, Polygon, and Arbitrum. Your agent will need a separate SVA deployed to each chain that you wish to operate on. You can simply ask your agent to do this. All x402 funding payments will remain on Base.Do not assume that your SVA address will remain constant across chains — it will not.To move assets between chains, Chainlink for Agents natively integrates Chainlink's CCIP for asset bridging. Asset and chain routes depend on CCIP's pool availability. Additionally, CCIP does require separate fee tokens for operation.Rate LimitsChainlink for Agents is in preview. There is a global TPS limit of 1 invoked operation per second, and a global TPS limit across all HTTP endpoints of 10 calls per second. These are subject to change. You should expect rate limiting per agent identity to be implemented soon.","tokens":1880,"squid":"spider-08","role":"Oracle Spider","at":1791348328108,"hash":"a68188bc2bdcec87bcf84e57508414dc723d12d7"}
{"url":"https://docs.phantom.com/bitcoin/signing-a-message","domain":"docs.phantom.com","title":"Sign a message - Phantom developer documentation","text":"The window.phantom.bitcoin provider has been deprecated.\nWhen a dapp is connected to Phantom, it can also request that the user signs a given message. Applications are free to write their own messages which will be displayed to users from within Phantom’s signature prompt. Message signatures do not involve network fees and are a convenient way for apps to verify ownership of an address.\n\nPhantom’s signMessage function accepts two parameters: an encoded message and an address that should be used to sign the message. It returns a Promise that resolves if the user approves the signature request. Once resolved, it contains the resulting signature.\n// function signature\nfunction signMessage(\n address: string,\n message: Uint8Array,\n ): Promise<{\n signature: Uint8Array;\n }>;\n\nThe following is an example of how to construct and sign a message with Phantom:\nconst message = new TextEncoder().encode('hello world');\nconst address = \"bc1phajtersv55fwud5xr0t70p5234swy396a6avqhuny0qf83zssvrsm7tl4q\"; // see \"Establishing a Connection\"\nconst { signature } = await phantomProvider.signMessage(address, message);\n\nTo verify that a message was signed by a given address, we recommend using the bip322-js library like so:\nimport { Verifier } from \"bip322-js\";\n\n// helper method\nfunction bytesToBase64(bytes) {\n const binString = String.fromCodePoint(...bytes);\n return btoa(binString);\n}\n\nconst isValidSignature = Verifier.verifySignature(\n address,\n new TextDecoder().decode(message),\n bytesToBase64(signature),\n);\nconsole.log(isValidSignature);\n// true\nWas this page helpful?","tokens":393,"squid":"spider-10","role":"Tooling Spider","at":1791348330613,"hash":"7629934a6fb9c5556644e4628130adc4e46c3ac4"}
{"url":"https://ethresear.ch/t/on-block-space-distribution-mechanisms/19764/5","domain":"ethresear.ch","title":"On block-space distribution mechanisms - Proof-of-Stake / Block proposer - Ethereum Research","text":"Proof-of-StakeBlock proposer\n\n mev\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n read \n\n 17\n min\n\n Jun 2024\n\n 5 / 5\n\n Jul 2024\n\n Jul 2024\n\n post by mikeneuder on Jun 8, 2024\n\n mikeneuder\n\n On block-space distribution mechanisms\nupload_3067440b5b4f752379ddba32df7ecf8b1548×1550 304 KB\n^p.s. yes, we anthropomorphize the protocol as a ghost because Casper.\n^^p.p.s. not sure why the auctioneer ghost looks like he is conducting an orchestra, but here we are ¯\\_(ツ)_/¯.\n^^^ p.p.p.s. by the way, if you haven’t seen Maestro, it’s great.\n\\cdot⋅\nby Mike, Pranav, & Dr. Tim Roughgarden – June 8, 2024.\n\\cdot⋅\nAcknowledgements\nSpecial thanks to Barnabé, Julian, Jonah, Davide, Thomas, Terence, Potuz, & Nate for comments and discussions.\n\\cdot⋅\ntl;dr; Block space, the capacity for transaction inclusion, is the principal resource exported by blockchains. As the crypto ecosystem scales up and professionalizes, the value produced by efficient usage of block space (MEV) has come to play a significant role in the economics of permissionless consensus mechanisms. An immense amount of ink has been spilled by the research community considering what, if anything, protocols should enshrine in response to MEV (see Related Work). Indeed, the past few years resemble a Blind Men and the Elephant narrative arc, where many different perspectives, solutions, and theories have been propounded, but each angle can feel disjoint and difficult to compare. The first half of this article aims to present a broad-strokes painting of the “MEV-ephant” by distilling the design space into a core set of questions and exploring how existing proposals answer them. The second half hones in specifically on allocation mechanisms enabled by execution tickets, demonstrating an important new insight – there is a trade-off between the quality of the in-protocol MEV oracle and the fairness of the mechanism.\nOrganization: Section 1 motivates the need for an in-protocol mechanism to handle block-space distribution as part of the “endgame” for Proof-of-Stake. Section 2 enumerates five axes along which block-space distribution mechanisms may be measured, using a familiar set of questions: who, what, when, where, how (abbr. the W^4H questions). Section 3 interrogates how the block builder is selected, focusing on the execution tickets model. Section 4 extrapolates by concluding and raising open questions that follow from the framework established.\nStructural note: This article is rather long for this format and has some technical elements. We encourage the reader to focus on the portion of the article they are most interested in:\n\nSections 1, 2, & 4 provide a broader perspective on the existing proposals and our proposed methodology for analyzing them.\nSection 3 (which is \\approx 44\\%≈44% of the content, but 100\\%100% of the math) provides a detailed analysis of allocation mechanisms enabled by the execution tickets design. This section can be read in sequence, in isolation, or skipped altogether – up to you!\n\n\\cdot⋅\nContents\n\nMotivation\n1) What\nBlock-space distribution today through mev-boost\nEnumeration\nThe elements of block-space distribution\nExecution tickets and other animals\nApplying W^4H: a comparative analysis\nMotivational interlude\nInterrogation\nPreliminaries\nModel\nFamiliar allocation mechanisms\nComparing the outcomes\nAside #1: Calculating equilibrium bids\nAside #2: Tullock Contests\nExtrapolation\n\n\\cdot⋅\nRelated work\n\nmev-boost & relays\n\nMEV-Boost: Merge ready Flashbots Architecture; Flashbots team\nRelays in a post-ePBS world; Mike, Jon, Hasu, Tomasz, Chris, Toni\n\nmev-burn / mev-smoothing\n\nBurning MEV through block proposer auctions; Domothy\nMEV burn – a simple design; Justin\nCommittee-driven MEV smoothing; Francesco\nDr. changestuff or: how I learned to stop worrying and love mev-burn; Mike, Toni, Justin\n\nenshrined Proposer-Builder Separation (ePBS)\n\nTwo-slot proposer/builder separation; Vitalik\nUnbundling PBS: towards protocol-enforced proposer commitments (PEPC); Barnabé\nNotes on Proposer-Builder Separation; Barnabé\nMore pictures about proposers and builders; Barnabé\nWhy enshrine Proposer-Builder Separation?; Mike, Justin\nePBS design constraints; Potuz\nReconsidering the market structure of PBS; Barnabé\n\nblock-space futures\n\nBlock vs. Slot Auction PBS; Julian\nOpportunities and Considerations of Ethereum’s Blockspace Future; Drew, Ankit\nWhen to sell your blocks; Quintus, Conor\n\nexecution tickets\n\nAttester-proposer separation; Justin\nExecution tickets; Justin, Mike\nEconomic Analysis of Execution Tickets; Jonah, Davide\nBlock-auction ePBS versus Execution Ticket; Terence\n\n(1) – Motivation\nBefore descending into this murky rabbit hole, let’s start by simply motivating the necessity of a block-space distribution mechanism. Validators in Proof-of-Stake protocols are tasked with producing and voting on blocks. The figure below, from Barnabé’s excellent “More pictures about proposers and builders,” describes these as “proposing” and “attesting” rights, respectively.\nupload_72dad4dc4f8c77f0d57f8f126b3c2e461450×462 100 KB\n1) What\n(\\uparrow↑ important cultural ref.)\nA block-space distribution mechanism is the process by which the protocol determines the owner of the “proposing” or “block construction” rights. Proof-of-Stake protocols typically use some version of the following rules:\n\nblock-space (proposing) rights – A random validator is elected as the leader and permitted to create the next block.\nvoting (attesting) rights – All validators vote during some time window for the block they see as the canonical head.\n\nValidators perform these tasks because they receive rewards for doing so. We categorize the rewards according to their origin in either the consensus layer (the issuance from the protocol – e.g., newly minted ETH) or the execution layer (transaction fees and MEV):\n\nConsensus layer\na. Attestation rewards – see attestation deltas.\nb. Block rewards – see get_proposer_reward.\nExecution layer\na. Transaction fees – see gas tracker.\nb. MEV (transaction ordering) – see mevboost.pics.\n\nRewards 1a, 1b, & 2a are well understood and “in the view” of the protocol. MEV rewards present a more serious challenge because fully capturing the value realized by transaction ordering is difficult. Unlike the other rewards, even the amount of MEV in a block is unknowable for all intents and purposes (as a permissionless and pseudonymous system, it’s impossible to trace who controls each account and any corresponding offchain activity that may be profitable in tandem). MEV also changes dramatically over time (e.g., as a function of price volatility), resulting in execution layer rewards having a much higher variance than the consensus layer rewards. Further, the Ethereum protocol, as implemented, has no insight into the MEV being produced and extracted by its transactions. To improve protocol visibility into MEV, many mechanisms try to approximate the MEV in a given block; we refer to these as MEV oracles. Block-space distribution mechanisms generally have the potential to produce such an oracle, making the protocol “MEV-aware.”\nThis suggests the question, why does the protocol care about being MEV-aware? One answer: MEV awareness may increase the protocol’s ability to preserve the homogeneity of validator rewards, even if validators have varying degrees of sophistication. For example, if the protocol could accurately burn all MEV, then the validator incentives would be fully in the protocol’s view (just like 1a, 1b, & 2a above). Alternatively, a mechanism that shares all MEV among validators regardless of their sophistication (e.g., mev-smoothing) would seem to promote a larger, more diverse and decentralized validator set, while keeping the MEV rewards as an extra incentivization to stake. Without MEV awareness, the validators best equipped to extract or smooth MEV (e.g., due to relationships with block builders, proprietary algorithms/software, access to exclusive order flow, & economies of scale) may earn disproportionately high rewards and exert significant centralization pressures on the protocol.\nEthereum protocol design strives to keep a decentralized validator set at all costs. It probably goes without saying, but for completeness: the protocol’s credible neutrality, censorship resistance, and permissionlessness are directly downstream of a decentralized validator set.\nBlock-space distribution today\nIn Ethereum today, mev-boost accounts for \\approx 90\\%≈90% of all blocks. Using mev-boost, proposers (the validator randomly selected as the leader) sell their block-building rights to the highest paying bidder through an auction. The figure below demonstrates this flow (we exclude the relays because they functionally serve as an extension of the builders).\nupload_5f698b1a28978bd8f9779e596c471d9a718×1420 64.3 KB\n.\nProposers are incentivized to outsource their block building because builders (the canonical name for MEV-extracting agents specializing in sequencing transactions) pay them more than they would have earned had they built the block themselves. Circling back to our goal of “preserving the homogeneity of validator rewards in the presence of MEV,” we see that mev-boost allows access to the builder market for all validators, effectively preserving near-equivalent MEV rewards among solo stakers and professional staking service providers – great! But…\nOf course, there is a but… mev-boost has issues that continue to rankle some of the Ethereum community. Without being exhaustive, a few of the negative side-effects of taking the mev-boost medicine are:\n\nRelays – These trusted-third parties broker the sale of blocks between proposers and builders. The immense reliance on relays increases the fragility of the protocol as a whole, as demonstrated through repeated, incidents, involving, relays. Further, since relays have no inherent revenue stream, more exotic (and closed-source) methods of capturing margins (e.g., timing games as a service and bid adjustments) are being implemented.\nOut-of-protocol software is brittle – Beyond the relays, participation in the mev-boost market requires validators to run additional software. The standard suite for solo staking now involves running four binaries: (i) the consensus beacon node, (ii) the consensus validator client, (iii) the execution client, and (iv) mev-boost. Beyond the significant overhead for solo stakers, reliance on this software also provides another potential point of failure during hard forks. See the Shapella incident and the Dencun upgrade for an example of the complexity induced by having more out-of-protocol software.\nBuilder centralization and censorship – While this is likely inevitable, builder centralization was accelerated by the mass adoption of mev-boost. Three builders account for \\approx 95\\%≈95% of mev-boost blocks (85\\%85% of all Ethereum blocks). mev-boost implements an open-outcry, first-price, winner-takes-all auction, leading to high levels of builder concentration and strategic, bidding. Without inclusion lists or another censorship-resistance gadget, builders have extreme influence over transaction inclusion and exclusion – see censorship.pics.\nTiming games – While timing games are known to be a fundamental issue in Proof-of-Stake protocols, mev-boost pushes staking service providers to compete on thin margins. Additionally, relays (who conduct mev-boost auctions on the proposer’s behalf) serve as sophisticated middlemen facilitating timing games. Thus, we have seen marketing endorsing playing timing games to boost the yield from staking with a specific provider.\n\n“OK, OK … blah blah … we have heard this story before … tell me something I don’t know.” (\\leftarrow← h/t Barnabé for the aptly-named, 14k-views on youtube, musical reference.)\n(2) – Enumeration\nObligatory ‘stage-setting’ out of the way, let’s look a little more carefully at the ~essence~ of a block-space distribution mechanism.\nupload_cdbf47258422c2a96ea2903ce113a113900×599 89.1 KB\n^ “Is that what I think it is?”\nThe elements of block-space distribution\nConsider the game of acquiring block space; MEV incentivizes agents to participate, while the combination of in-protocol and out-of-protocol software defines the rules. When designing this game, what elements should be considered? To answer this question, we use a familiar rhetorical pattern of “who, what, when, where, & how” (hopefully Section 1 sufficiently answered “why”), which we refer to as the W^4H questions. (\\leftarrow← h/t Barnabé pt. 2 for the connection to “Who Gets What – and Why”).\n\nWho controls the outcome of the game?\nWhat is the good that players are competing for?\nWhen does the game take place?\nWhere does the MEV oracle come from?\nHow is the block builder chosen?\n\nThese questions might seem overly simplistic, but when considered in isolation, each can be viewed as an axis in the design space to measure mechanisms. To demonstrate this, we highlight a few different species from the block-space distribution mechanism genus that have been explored in the past. While they may feel disjointed and unrelated, their relationship is clarified by understanding how they answer the W^4H questions.\nExecution tickets and other animals\nupload_23e73e8aae1d7223973af83053d41ebc922×1404 168 KB\n^ fantastic book.\nWe present a compendium of many different proposed mechanisms. Note that this is only a subset of the rather substantial literature around these designs – cf. infinite buffet. For each of the following, we summarize only the key ideas (see related work for more).\n\nExecution tickets\n\nKey ideas – Block building and proposing rights are sold directly through “tickets” issued by the protocol. Ticket holders are randomly sampled to become block builders with a fixed lookahead. The ticket holder has the authority to produce a block at the assigned slot.\n\nBlock-auction PBS\n\nKey ideas – The protocol bestows block production rights through a random leader-election process. The selected validator can sell their block outright to the builder market or build it locally. The builder must ~commit to a specific block~ when bidding in the auction. mev-boost is an out-of-protocol instantiation of block-auction PBS; enshrined PBS (ePBS), as originally presented, is the in-protocol equivalent.\n\nMEV-burn/mev-smoothing\n\nKey ideas – A committee is tasked with enforcing a minimum value over the bid the proposer selects in an auction. By requiring the proposer to choose a “large enough” bid, an MEV oracle is created. The MEV is either smoothed between committee members or burned (smoothed over all ETH holders).\n\nSlot-auction PBS\n\nKey ideas – Similar to block-auction PBS but instead sells the slot to the builder market ~without~ requiring a commitment to a specific block – sometimes referred to as block space futures. By not requiring the builders to commit to a particular block, future slots may be auctioned off ahead of time rather than waiting until the slot itself.\n\nPartial-block auction\n\nKey ideas – Allows a more flexible unit for selling block-space. Instead of selling the full block or slot, allow proposers to sell some of their block, e.g., the top-of-block (which is the most valuable for arbitrageurs), while retaining the rest-of-block construction. Live in other Proof-of-Stake networks, e.g., Jito’s block engine and Skip MEV lane.\n\nAPS-burn a.k.a. Execution Auction (nomenclature in flux & the EA acronym has a bit of … baggage)\n\nKey ideas – A brand new proposal from Barnabé which compels a proposer to auction off the block building and proposing rights ahead of time. The slot is sold ex-ante (a fixed amount of time in advance) without requiring a commitment to a specific block; a committee (à la mev-burn/smoothing) enforces the winning bid is sufficiently large.\n\nWe know, we know – it’s a lot to keep track of; it’s nearly a full-time job just to stay abreast of all these acronyms. But by comparing these proposals along the axes laid out by the W^4H questions, we can see how they all fit together as different parts of the same design space.\nApplying W^4H: a comparative analysis\nFor each of the five W^4H questions, we describe different trade-offs made by the aforementioned proposals. For brevity, we don’t analyze each question for each proposal; we instead focus on highlighting key differences arising from each line of questioning.\n\nWho controls the outcome of the game?\n\nWith execution tickets, the protocol dictates the winner of the game by randomly choosing from the set of ticket holders.\nWith block-auction PBS, the proposer (protocol-elected leader) unilaterally chooses the winner of the game.\nWith mev-burn, the proposer still chooses the winner, but the winning bid is constrained by the committee, reducing the proposer’s agency.\n\nWhat is the good that players are competing for?\n\nWith block-auction PBS, the entire block is sold, but bids must commit to the block contents.\nWith slot-auction PBS, the entire block is sold, but without any specific block commitment.\nWith partial-block PBS, a portion of the block is sold.\n\nWhen does the game take place?\n\nWith block-auction PBS, the auction takes place during the slot.\nWith slot-auction PBS, the auction may take place many slots (e.g., 32) ahead of time because there is no block-content commitment.\nWith execution tickets, the tickets are assigned to slots at a fixed lookahead after being sold ex-ante by the protocol (more on the ticket-selling model we use below).\n\nWhere does the MEV oracle come from?\n\nWith mev-burn/smoothing, a committee enforces that a sufficiently large bid is selected as the winner; this bid size is the oracle.\nWith execution tickets, the total money spent on tickets serves as the oracle.\n\nHow is the block builder chosen?\n\nIn block-auction PBS, any outsourced block production has a winner-take-all allocation, with the highest bidder granted the block-building rights.\nWithin execution tickets, many different allocation mechanisms can be implemented. In the original proposal, for example, where a random ticket is selected, the mechanism is ‘proportional-to-ticket-count’; in this case, the highest paying bidder (whoever holds the most tickets) merely has the highest probability of being selected, meaning they are not guaranteed the block building rights.\nIf that (^) seems opaque, don’t worry. The entire following section is a deep dive into these different allocations.\n\nMotivational interlude\nBefore continuing, let’s review our original motivation for block-space distribution mechanisms:\n\nBlock-space distribution mechanisms aim to preserve the homogeneity of validator rewards in the presence of MEV.\n\nThis is a great grounding, but if that is our only goal, why not just continue using mev-boost? Well, remember that mev-boost has some negative side effects that we probably want the endgame protocol to be resilient against. We highlight four other potential design goals of a block-space distribution mechanism:\n\nEncouraging a wider set of builders to be competitive.\nAllow validators and builders to interact trustlessly.\nIncorporating MEV-awareness into the base layer protocol.\nRemoving MEV from validator rewards altogether.\n\nNote that while (1, 2, & 3) appear relatively uncontroversial (*knock on wood*), (4) is more opinionated (and requires (3) as a pre-condition). The protocol may hope to eliminate MEV rewards from validator rewards as a means to ensure that the consensus layer rewards (what the protocol controls) more accurately reflect the full incentives of the system. This also ties into questions around staking macro-economics and the idea of protocol, issuance – a much more politically-charged discussion. On the other hand, MEV rewards are a byproduct of network usage; MEV could instead be seen as a value capture mechanism for the native token. We aren’t trying to address these questions here but rather explore how different answers to them would shape the design of the mechanism.\nWhat can we do at the protocol-design level to align with these desiderata? As laid out above, there are many trade-offs to consider, but in the following section, we examine “How is the block builder chosen?” to improve on some of these dimensions.\n(3) – Interrogation\nEditorial note: As mentioned earlier, this section is longer and more technical than the others – feel free to skip to Section 4 if you are time (or interest) constrained!\nSection goal: To demonstrate the quantitative trade-off between MEV-oracle quality and the “fairness” of the two most familiar approaches to allocating block proposer rights, which we call Proportional-all-pay and Winner-take-all.\nWe aim to accomplish this with the following subsections:\n\nPreliminaries – Motivate the fixed-price, unlimited-quantity execution ticket sale mechanism we use.\nModel - Introduce the notation needed to analyze the model.\nFamiliar allocation mechanisms - Describe the Proportional-all-pay and Winner-take-all mechanisms using the established framework.\nComparing the outcomes - Calculate the resulting equilibria in a two-player example.\nAside #1: Calculating equilibrium bids - Derive the equilibria in the general case.\nAside #2: Tullock Contests - Contextualize the model as a Tullock Contest and draw connections to the existing literature.\n\nLet’s dig in.\nPreliminaries\nBefore diving into the space of allocation mechanisms made possible with execution tickets, we must first set up the model. Consider a protocol that sells execution tickets with the following rules:\n\nthe price is fixed at 1 WEI, and\nunlimited tickets can be bought and sold from the protocol.\n\nNote: this version of execution tickets is effectively equivalent to creating two disjoint staking mechanisms – one each for attesting and proposing. Small changes in the design, e.g., not allowing tickets to be resold to the protocol, may have massive implications for how the market plays out, but that isn’t the focus of this article. Instead, we narrowly explore the question of block-space allocation, given an existing ticket holder set.\nNotably, the set of block producers is disjoint (from the protocol’s perspective) from the set of attesters – individuals must select which part of the protocol they participate in by deciding whether to stake or buy tickets. The secondary ticket market may evolve as a venue for selling the building rights just in time to the builder market (as is done in mev-boost today).\nupload_45a1fa23182dd6a28c2c07dc2479f1501428×1468 195 KB\n\\cdot⋅\nSeparately, builders may choose to interact directly with the protocol by buying execution tickets themselves, but their capital may be better utilized as active liquidity, capturing arbitrage across trading venues. Thus, they may prefer buying block space on the secondary market during the just-in-time auction instead.\nWhy restrict ourselves to this posted-price-unlimited-supply mechanism? Two reasons:\n\nIt’s not clear that a sophisticated market could even be implemented in the consensus layer. The clients are optimized to allow any validator with consumer-grade hardware to participate in the network. This desideratum may be incompatible with fast auctions, bonding curves, or other possible ticket-selling mechanisms. Questions around how many tickets are sold, the MEV around onchain ticket-sale inclusion (meta-MEV?!), and the timing (and timing games) of ticket sales seem closer to execution layer concerns than something that could reasonably be implemented by Ethereum consensus while keeping hardware requirements limited.\n\n“One may imagine the inclusion of ET market-related transactions to possibly induce MEV, whether these transactions are included in the beacon block or the execution payload.” – Barnabé in “More pictures about proposers and builders.”\n\nEven if (a big if) the protocol ~could~ implement a more rigid ticket-selling market, the design space for such a mechanism is immense. Many potential pricing mechanisms have been discussed, e.g., bonding curves, 1559-style dynamic pricing, auctions, etc.; making general claims about these remains outside the scope of this post.\n\nTherefore, we focus on the “unlimited, 1 WEI posted-price” version of execution tickets, where the protocol internalizes minimal complexity. With this framing, we can ask the question that is probably burning you up inside, “given a set of execution ticket holders, how should the winner be selected?” … sounds easy enough, right? Turns out there is a good deal we can say, even with such a seemingly simple question; let’s explore a few different options.\nModel\nConsider the repeated game of buying execution tickets to earn MEV rewards for your investment.\n\nDuring each period, each player effectively submits a bid, which is the number of tickets they buy. Denote the vector of bids by \\mathbf{b}𝐛, where b_i𝑏𝑖 is the bid of the i^{th}𝑖𝑡ℎ player.\nEach player has a valuation for winning the block production rights. Denote the vector of valuations by \\mathbf{v}𝐯, where v_i𝑣𝑖 is the value of the i^{th}𝑖𝑡ℎ player.\nAt each time step, an allocation mechanism determines each player’s allocation based on the vector of bids. Assuming bidders are risk-neutral (i.e., don’t care between winning 2 ETH with probability 0.50.5 vs. 1 ETH with probability 11), we can equivalently say that they are each allocated “some portion” of the block, which can be alternatively be interpreted as “the probability that they win a given block.” In an n𝑛 player game, let x: \\mathbf{b} \\rightarrow [0,1]^n𝑥 :𝐛 →[0,1]𝑛 denote the map implementing an allocation mechanism, where x_i(\\mathbf{b})𝑥𝑖(𝐛) is the allocation of the i^{th}𝑖𝑡ℎ player, under the constraint that \\sum_i x_i(\\mathbf{b}) =1∑𝑖𝑥𝑖(𝐛) =1 (i.e., the mechanism fully allocates).\nEach player’s payment is collected at each round. Let p: \\mathbf{b} \\rightarrow \\mathbb{R}_{\\geq 0}^n𝑝 :𝐛 →ℝ𝑛≥0 denote the payment rule determined by the set of bids, where p_i(\\mathbf{b})𝑝𝑖(𝐛) is the payment of the i^{th}𝑖𝑡ℎ player.\nThe utility function of each player in the game is, U_i(\\mathbf{b}) = v_i x_i(\\mathbf{b}) - p_i(\\mathbf{b})𝑈𝑖(𝐛) =𝑣𝑖𝑥𝑖(𝐛) −𝑝𝑖(𝐛). The intuition is that “a player’s utility is their value for winning multiplied by the amount they won, less their payment.”\n\nFamiliar allocation mechanisms\nConsider two (quite different) possible mechanisms.\nProportional-all-pay (a slight modification to the original execution tickets proposal)\n\nDuring each round, all players submit a bid. Denote the vector of bids by \\mathbf{b}𝐛.\nThe probability that a bid wins the game is the value of the bid divided by the sum of all the values of the bids,\n\nx_i(\\mathbf{b}) = \\frac{b_i}{\\sum_j b_j}.\n𝑥𝑖(𝐛)=𝑏𝑖∑𝑗𝑏𝑗.\n\nEach player pays their bid, no matter the outcome of the game (hence “all-pay”), p_i(\\mathbf{b}) = b_i.𝑝𝑖(𝐛) =𝑏𝑖.^{[1]}[1]\n\nWinner-take-all (the current implementation of PBS)\n\nDuring each round, all players submit a bid. Denote the vector of bids by \\mathbf{b}𝐛.\nThe highest bidder wins the game, so x_i(\\mathbf{b}) = 1𝑥𝑖(𝐛) =1 if \\max(\\mathbf{b}) = b_imax(𝐛) =𝑏𝑖 and x_i(\\mathbf{b}) = 0𝑥𝑖(𝐛) =0 otherwise (where ties are broken in favor of the lower index bidder, say).\nOnly the winning player pays the value of their bid, so p_i(\\mathbf{b}) = b_i𝑝𝑖(𝐛) =𝑏𝑖 if \\max(\\mathbf{b}) = b_imax(𝐛) =𝑏𝑖 and p_i(\\mathbf{b}) = 0𝑝𝑖(𝐛) =0 otherwise (same tie-breaking as above).^{[2]}[2]\n\nComparing the outcomes\nTo demonstrate the different outcomes from these two mechanisms, consider the two-player game where Player 1 has a valuation of v_1 = 4𝑣1 =4 and Player 2 has a valuation of v_2 = 2.𝑣2 =2. (We consider a complete information setting in which the individual values are common knowledge. To see how the equilibria bid is calculated and for extended discussion, see Aside 1.)\n\nProportional-all-pay outcome:\n\nEquilibrium Bids: \\qquad\\,\\,\\,\\;\\;\\; b_1 = 8/9 𝑏1 =8/9, \\,b_2 = 4/9 𝑏2 =4/9\nEquilibrium Allocations: \\;\\;\\; x_1 = 2/3 𝑥1 =2/3, x_2 = 1/3𝑥2 =1/3\nEquilibrium Payments: \\;\\;\\;\\; p_1 = 8/9 𝑝1 =8/9, \\,p_2 = 4/9 𝑝2 =4/9\n\nThis all should feel intuitively correct; with v_1 = 2 \\cdot v_2𝑣1 =2 ⋅𝑣2 (Player 1 has 2x the value for the block), Player 1 bids, receives and pays twice as much as Player 2.\n\nWinner-take-all outcome:\n\nEquilibrium Bids: \\qquad\\,\\,\\,\\;\\;\\; b_1 = 2+\\epsilon 𝑏1 =2 +𝜖, b_2 = 2𝑏2 =2\nEquilibrium Allocations: \\;\\;\\; x_1 = 1 𝑥1 =1, \\quad\\;\\; x_2 = 0 𝑥2 =0\nEquilibrium Payments: \\;\\;\\;\\,\\, p_1 = 2+\\epsilon 𝑝1 =2 +𝜖, p_2 = 0𝑝2 =0\n\nThis is pretty different. Player 1 bids and pays just over Player 2’s value (we use \\epsilon𝜖 to denote a small amount), receiving the entire allocation. Player 2 receives nothing and pays nothing.^{[3]}[3]\nNow consider the “revenue” (or the sum of the bids collected by the mechanism) generated from each case:\n\nProportional-all-pay revenue: b_1 + b_2 = 4/3𝑏1 +𝑏2 =4/3\nWinner-take-all revenue: \\qquad\\quad\\,\\,\\,\\;\\;\\;\\; b_1 = 2+\\epsilon 𝑏1 =2 +𝜖\n\nWinner-take-all has better revenue, corresponding to a more accurate MEV oracle (and thus more MEV burned or smoothed by the protocol) than Proportional-all-pay. Intuitively, by allocating block-production rights to players with lower values (as Proportional-all-pay does), we forgo revenue we would have received had we simply allocated the entire rights to the player with the highest value. We point the interested reader to Aside 1 for a more complete treatment.\nAnother factor to consider is the “fairness” or “distribution” of the allocation mechanism. For example, suppose we agree on the metric: \\text{fairness} = \\sqrt{x_1 \\cdot x_2}fairness =√𝑥1⋅𝑥2 (we use the geometric mean because if x_1 + x_2𝑥1 +𝑥2 has a fixed sum, the geometric mean is maximized at x_1 = x_2𝑥1 =𝑥2 and zero if either x_1,x_2𝑥1,𝑥2 is zero). Now, let’s look at the fairness outcomes of the two candidate mechanisms:\n\nProportional-all-pay fairness: \\sqrt{1/3 \\cdot 2/3} \\approx 0.471√1/3⋅2/3 ≈0.471\nWinner-take-all fairness: \\qquad\\qquad\\;\\,\\;\\sqrt{1 \\cdot 0} = 0 √1⋅0 =0\n\nHere, the “performance” of the two mechanisms flips – the Winner-take-all is less fair because Player 2 has no chance of winning the game with a lower value. In the Proportional-all-pay, Player 2 can hope to win some blocks despite bidding a lower value. As another example, consider the case where v_1=v_2+\\epsilon𝑣1 =𝑣2 +𝜖. The Winner-take-all mechanism allocates all the rights to Player 1, while the Proportional-all-pay splits the rights approximately in half.\n\nBrief note: why might the protocol care about fairness? In a decentralized protocol, a single actor having too much power undermines the credible neutrality of the system. As such, the protocol may be willing to “pay” (in the form of reduced revenue) to ensure that a resource is more evenly distributed among players. Alternatively, we could consider this a measure of “entropy” or even simply randomness being injected into the outcome of the game to try to reduce the influence the most dominant player can have.\n\nThis leads to the punchline from this small example: a fundamental trade-off exists between MEV-oracle quality and fairness. The Proportional-all-pay mechanism (and hence the original execution tickets proposal) is fairer because both players win the game with some probability, incentivizing them each (but more importantly, the higher value player) to shade their bid accordingly, lowering the revenue, and thus the MEV-oracle accuracy, of the mechanism. The first price mechanism elicits higher bids since bidders only pay if they win the entire block production rights, increasing the revenue, but this Winner-take-all dynamic makes the allocation less fair.\nOpen question: is Proportional-all-pay an “optimal” Sybil-proof mechanism? In the permissionless setting, we only consider Sybil-proof mechanisms, where a player doesn’t benefit from splitting their bid into multiple identities. We posit that the Proportional-all-pay mechanism sits in the Goldilock’s Zone of a Sybil-proof mechanism that gets both good revenue/MEV-oracle accuracy and fairness. We leave as an interesting open problem to determine the extent to which the Proportional-all-pay mechanism’s “optimality” (e.g., we were unable to find another Sybil-proof mechanism that dominates it in both revenue and fairness).\nAside #1 – Calculating equilibrium bids\nConvenience link to skip to the conclusion for the less-keen reader \nIn the numerical example above, we provide the equilibrium bids for the Winner-take-all and Proportional-all-pay mechanisms without proof. How can these be determined generally (e.g., continuing to assume that bidders’ values are common knowledge)?^{[4]}[4]\nThe Winner-take-all is the familiar First Price Auction setting. In such auctions, the complete information Pure-Nash equilibrium has the two highest-value bidders, each bidding the second-highest bidder’s value, with every other agent bidding below this. In effect, we expect that the highest-value bidder always wins while paying the second highest bidder’s value (we represent this simply as b_1=b_2+\\epsilon𝑏1 =𝑏2 +𝜖, though you could equivalently tie-break in favor of the higher-value player).\nIn the Proportional-all-pay setting, each player has the utility,\n\n\\begin{align}\nU_i (\\mathbf{b}) &= v_i \\cdot x_i(\\mathbf{b}) - b_i \\\\\n&= v_i \\cdot \\frac{b_i}{\\sum_j b_j} - b_i.\n\\end{align}\n𝑈𝑖(𝐛)=𝑣𝑖⋅𝑥𝑖(𝐛)−𝑏𝑖=𝑣𝑖⋅𝑏𝑖∑𝑗𝑏𝑗−𝑏𝑖.\nTo determine the existence of a Pure Nash Equilibrium, we consider each player’s first- and second-order conditions. Let \\mathbf{b}^*𝐛∗ denote the candidate equilibrium set of bids.\n\nFirst-order condition: \\partial U_i / \\partial b_i (\\mathbf{b^*}) = 0𝜕𝑈𝑖/𝜕𝑏𝑖(𝐛∗) =0 (or \\partial U_i / \\partial b_i (\\mathbf{b^*}) \\leq 0, \\;\\forall i \\text{ s.t. } b^*_i=0𝜕𝑈𝑖/𝜕𝑏𝑖(𝐛∗) ≤0, ∀𝑖 s.t. 𝑏∗𝑖 =0.)\n\nIntuitively, this condition checks a non-zero-bidding player is (to first order) locally indifferent to small changes in its bid.\n\nSecond-order condition: \\partial^2 U_i / \\partial b_i^2 < 0𝜕2𝑈𝑖/𝜕𝑏2𝑖 <0\n\nIntuitively, this condition ensures that the utility function is concave, implying that locally best responses are globally best for all players.\n\nIn our simple two-player example in the Proportional-all-pay setting, we have the following.\n\n\\begin{align}\n\\frac{\\partial U_1}{\\partial b_1}(\\mathbf{b}) = \\frac{v_1 b_2}{(b_1 + b_2)^2} - 1 = 0 \\; , \\quad \\frac{\\partial U_2}{\\partial b_2}(\\mathbf{b}) = \\frac{v_2 b_1}{(b_1 + b_2)^2} - 1 = 0\n\\end{align}\n𝜕𝑈1𝜕𝑏1(𝐛)=𝑣1𝑏2(𝑏1+𝑏2)2−1=0,𝜕𝑈2𝜕𝑏2(𝐛)=𝑣2𝑏1(𝑏1+𝑏2)2−1=0\nThis system can be solved to find the equilibrium bids, \\mathbf{b}^*𝐛∗,\n\n\\begin{align}\nb^*_1 = \\frac{v_1^2 v_2}{(v_1 + v_2)^2}\\; , \\quad b^*_2 = \\frac{v_2^2 v_1}{(v_1 + v_2)^2}.\n\\end{align}\n𝑏∗1=𝑣21𝑣2(𝑣1+𝑣2)2,𝑏∗2=𝑣22𝑣1(𝑣1+𝑣2)2.\nFor our toy example, we have v_1=4, \\; v_2=2 \\implies b_1^* = 32/36, \\; b_2^* = 16/36𝑣1 =4, 𝑣2 =2 ⟹ 𝑏∗1 =32/36, 𝑏∗2 =16/36. We can verify our first-order conditions\n\n\\begin{align}\n\\frac{4 \\cdot 16/36}{16/9} - 1 = 0 \\; , \\quad \\frac{2 \\cdot 32/36}{16/9} - 1 = 0 \\quad \\checkmark\n\\end{align}\n4⋅16/3616/9−1=0,2⋅32/3616/9−1=0✓\nThe second-order conditions can also be verified – this is left as an exercise for the reader \nAside #2 – Tullock Contests\nLast chance to skip to the conclusion. (If you continue, by definition, you are the “interested reader” – congrats.)\nThe model described above is established in the algorithmic game theory literature as a Tullock Contest – named for Gordon Tullock, who explored the idea in his seminal work, “Efficient Rent Seeking.” He motivates this study by considering situations where investment is made before the outcome is known and where the investments might not transfer easily between participants, e.g., political spending.\n\n“Suppose, for example, that we organize a lobby in Washington for the purpose of raising the price of milk and are unsuccessful. We cannot simply transfer our collection of contacts, influences, past bribes, and so forth to the steel manufacturers’ lobby. In general, our investments are too specialized, and, in many cases, they are matters of very particular and detailed goodwill to a specific organization. It is true that we could sell the steel lobby our lobbyists with their connections and perhaps our mailing list. But presumably, all these things have been bought by us at their proper cost. Our investment has not paid, but there is nothing left to transfer.” – Gordon Tullock (1980)\n\nThis allocation mechanism has been applied in the previous crypto literature as well. Back in 2018 (ancient history in crypto-terms), Arnosti and Weinberg wrote “Bitcoin: A natural oligopoly,” which demonstrates that even small operating cost advantages among miners in a Proof-of-Work system lead to surprisingly concentrated equilibria. Similarly, Bahrani, Garimidi, and Roughgarden (these names sound familiar :D) explored the centralization effects of heterogeneity in block building skill in “Centralization in Block Building and Proposer-Builder Separation.” There appears to be a deep relationship between permissionless crypto-economic systems, where anti-Sybil mechanisms typically require financial investment for participation, and Tullock Contests – more on this Soon™ (maybe).\n(4) – Extrapolation\nPhew, thanks for hanging in there; let’s take stock of what we learned. Section 3 demonstrates the fundamental trade-off between MEV-oracle accuracy and fairness of an instantiation of an execution ticket mechanism. A protocol may be willing to *pay* (in the form of reduced revenue) for more distribution and entropy with the goal of improving and maintaining the protocol’s credible neutrality. Further, using the model to derive equilibrium bids helps inform how we may expect agents to respond to various allocation and payment rules. Neat – our framework led to some interesting and hopefully helpful insights! Maybe we can extend it to other problems in the space as well?\nFurther questions that this specific model may help answer (returning to three of our W^4 questions):\n\nWhat is the good that players are competing for?\n\nCan we extend the model dimensionality, allowing different players to have different values for portions of the block (e.g., an arbitrageur may disproportionately value the top of a block but have zero value for the remainder)?\n\nWhen does the game take place?\n\nHow does the MEV-oracle accuracy change if the game takes place far ahead of time versus during the slot itself (e.g., pricing future expected MEV versus present realizable MEV)?\n\nHow is the block builder chosen?\n\nAre there other Sybil-proof mechanisms that dominate Proportional-all-pay in both revenue and fairness?\nCan we more formally characterize the fundamental trade-offs between revenue and fairness?\nGiven the Sybil-proofness constraint, what alternative allocation and payment rules should be explored (e.g., Tullock contests where the allocation rule is parameterized by \\alpha>1𝛼 >1 where x_i = b_i^\\alpha / \\sum_j b_j^\\alpha𝑥𝑖 =𝑏𝛼𝑖/∑𝑗𝑏𝛼𝑗), and can we identify the optimal choice?\n\nZooming back out, other versions of the W^4H questions may require different models to reason about.\n\nWho controls the outcome of the game?\n\nIn the committee-enforced version of these mechanisms, how could collusive behavior emerge?\nIf the just-in-time block auction continues to take place out-of-protocol, should we explicitly describe the secondary market?\n\nWhen does the game take place?\n\nHow critical is network latency when considering lookahead block-space sales versus same-slot? Is it worth modeling the partially-synchronous setting?\nHow do block builder valuations change if multi-slot MEV is feasible?\n\nWhere does the MEV oracle come from?\n\nIf it comes from the committee, are there incentives for committee members to behave dishonestly?\nDo such incentives depend on whether protocol-captured MEV is burned or smoothed?\n\nAs per usual, open questions abound, but we hope (a) W^4H questions help expand the understanding of block-space distribution mechanisms and (b) the deep dive into allocation mechanisms helps inform the potential design space of execution tickets.\nupload_a24cdf5b513fb4e410700573687adcd61920×1374 164 KB\n^ The world once we figure out MEV.\nExcited to be here with y’all.\n— made with by mike, pranav, & dr. tim roughgarden.\n\nfootnotes\n^{[1]}[1]: The “all-pay” feature is made possible by burning the price paid for each ticket. ︎\n^{[2]}[2]: The “winner-pay” version could be done by refunding all non-winning ticket holders their payment at the end of each round. ︎\n^{[3]}[3]: As mentioned earlier, simply refunding the non-winning tickets instantiates the “winner-pays” property. ︎\n^{[4]}[4]: This is primarily for tractability in calculating equilibria analytically. Although a strong assumption, it’s not unreasonable in the context of lookahead auctions where bidders might have established prior distributions on their competitor’s valuations. We also view the insights from studying the complete-information equilibria as valuable heuristics for how we may expect these mechanisms to behave in practice. ︎\n\n A design for APS-burn in the context of a Decentralized L2\n\n Exploring Sophisticated Execution Proposers for Ethereum\n\n Future-Proofing Preconfirmations\n\n The case for decentralization increasing efficiency is overstated\n\n Agent-based Simulation of Execution Tickets\n\n 2\n\n read \n\n 17\n min\n\n post by M1kuW1ll on Jun 13, 2024\n\n M1kuW1ll\n\n Thanks for the interesting post \nIn the Winner-take-all mechanism, do you think there is a possibility where players can (be incentivized to) cooperate (or collude) to minimize their bid value, share an equal allocation, and maximize their utility?\n\nWith the small example above, let’s say both Player 1 and Player 2 bid \\epsilon𝜖 (small amount) and their allocation will be 0.5 with some kind of tie-breaker. Such that their utility can be given by:\nU_1 = 4 \\times 0.5 - \\epsilon𝑈1 =4 ×0.5 −𝜖 and U_2 = 2 \\times 0.5 - \\epsilon.𝑈2 =2 ×0.5 −𝜖.\nThe utility of Player 1 is the same, while the utility of Player 2 is higher. However, under such conditions, the “revenue” collected by the mechanism is minimal, corresponding to an inaccurate MEV oracle for this Winner-take-all mechanism.\n\n post by mikeneuder on Jun 19, 2024\n\n mikeneuder\n\n Thanks for your reply! In the WTA setting, only a single player wins. If they both bid \\epsilon𝜖 and tie broke in favor of Player 1 (WLOG), then the sharing of the block would need to take place out-of-band, and they would have to have to trust each other. In general, in a one-shot game, a PNE mayn’t be predictive in case of collusion. Consider the simple prisoner’s dilemma; if there is collusion, both players can communicate and decide to cooperate out-of-band, resulting in different behavior than the PNE would indicate. In repeated or dynamic games, there is a chance that the PNE can handle collusion though future iterations of the game, but that’s not the model we are considering! The point is, if there was some form of collusion where the each bid \\epsilon𝜖, someone else would have a large incentrive to come in and defect, bidding \\epsilon + \\delta𝜖 +𝛿 and winning the auction for well below their true value.\n\n 21 days later\n\n post by captgouda24 on Jul 11, 2024\n\n captgouda24\n\n Hi. I hope it is not too late to comment. Some of the cost and benefits of decentralization are already internalized by the bidders. If controlling a greater portion of the blockchain would expose a bidder to greater government interference, then that should already be reflected in their distribution of values. I am concerned that the more “fair” distribution mechanism will double-count the costs of centralization.\nIndeed, if we take the extreme case of two bidders trying to buy a stream of assets, and this is the entire economy, shouldn’t the entire cost of centralization be internalized? Why wouldn’t it be?\n\n post by r4f4ss on Jul 12, 2024\n\n r4f4ss\n\n Thanks for the excellent post which works as a systematic review of the subject.\nThere is the possibility of two mixed mechanisms. The first one has Proportional-all-pay probabilities of win and only the winner pays like in Winner-take-all mechanism:\n\nDuring each round, all players submit a bid. Denote the vector of bids by b𝑏.\n\nThe probability that a bid wins the game is the value of the bid divided by the sum of all the values of the bids,\n\nxi(b)=bi∑jbj.\n𝑥𝑖(𝑏)=𝑏𝑖∑𝑗𝑏𝑗.\n\nOnly the winning player pays the value of his bid.\n\nIn the second mixed mechanism, all players pay, but only the highest bidder wins the game, and it only makes sense if the bids are secret. I have no idea about the complexity of implementing this mechanism, if possible.\nThe former is not more complex to implement and execute than the others mentioned in the post and its metrics values of fairness and revenue may be different.\n\n Powered by Discourse","tokens":11214,"squid":"spider-04","role":"Research Spider","at":1791348335019,"hash":"d2355948a6528ea4e339ba602e63c7fa5099fb42"}
{"url":"https://docs.chain.link/resources/chainlink-developer-agent-skills?parent=dataLink","domain":"docs.chain.link","title":"Chainlink Developer Agent Skills | Chainlink Documentation","text":"Chainlink Developer Agent SkillsThis guide is for developers seeking to leverage AI skills while integrating Chainlink products. It covers the public skill bundle in smartcontractkit/chainlink-agent-skills: what it is, how to install it, what each skill helps with, and how to prompt your agent effectively. \nWhat this repository isChainlink Agent Skills are AI tools for building with Chainlink. Each skill teaches a compatible assistant how to help you with a specific product area (for example, Data Feeds or CCIP): suggested steps, guardrails, and references so you spend less time hunting docs and more time shipping.\n\nRequirements\nA coding environment where your AI assistant supports Agent Skills.\nNode.js with npx available, for the install command below.\n\nHow to install the skillsInstallation uses Vercel's CLI for the open skills ecosystem.Install skills (recommended default)From your project directory, run:npx skills add smartcontractkit/chainlink-agent-skills\nRunning this command starts an interactive installer where you choose project-level or global installation. Pick project-level if you want the skills stored with the repository so collaborators get the same set from version control.Install globally (optional)To install skills for your user account across projects, add the -g flag:npx skills add smartcontractkit/chainlink-agent-skills -g\nInstall a single skill globally (optional)If you only want one package from the bundle at user level, use --skill with the skill folder name:npx skills add smartcontractkit/chainlink-agent-skills --skill chainlink-cre-skill -g\nnpx skills add smartcontractkit/chainlink-agent-skills --skill chainlink-ccip-skill -g\nnpx skills add smartcontractkit/chainlink-agent-skills --skill chainlink-data-feeds-skill -g\nnpx skills add smartcontractkit/chainlink-agent-skills --skill chainlink-data-streams-skill -g\nnpx skills add smartcontractkit/chainlink-agent-skills --skill chainlink-ace-skill -g\nnpx skills add smartcontractkit/chainlink-agent-skills --skill chainlink-vrf-skill -g\nAfter installation, restart or refresh your assistant session if your tool requires it so newly added skills are picked up.\n\nHow to use the skills day to dayCompatible assistants can activate skills automatically when your task matches their descriptions. For predictable results, mention the skill explicitly in your message, using the slash form your tool expects (often /chainlink-data-feeds-skill, /chainlink-ccip-skill, and so on). Match the name field in each skill's SKILL.md.Keep prompts concrete: target chain, framework (Foundry, Hardhat, and so on), what you want built or changed, and any constraints (validation, tests, security expectations). The skills steer answers toward current integration practices and safer defaults; you remain responsible for reviews, keys, and anything executed onchain.\n\nCRE SkillThis skill covers the Chainlink Runtime Environment (CRE). It can:\nInstall and use the CRE CLI.\nCreate new CRE projects in Go or TypeScript.\nBuild workflows with CRON, HTTP, or EVM log triggers, including multi-handler projects with more than one entry point.\nUse EVM read and write, HTTP, and confidential HTTP capabilities.\nDevelop smart contracts that receive and verify CRE reports.\nSimulate workflows before deployment and write unit tests.\nDeploy workflows and set up monitoring.\nExample promptUsing /chainlink-cre-skill, build a delivery-versus-payment settlement system that:\n\n- locks tokenized treasuries (seller) and initiates fiat payment from buyer's bank account in escrow\n- verifies off-chain bank transfer completion by checking:\n - payment confirmed in seller's bank account,\n - amount matches agreed price (for example $401,292 for 628 tokens)\n- executes atomic settlement (releases tokenized treasuries to buyer) only when bank payment is verified\n- reverts entire transaction if payment verification fails or times out (24-hour window)\n- emits settlement events with bank transaction references\n\nDeploy on Ethereum Sepolia and use mock API for testing phase. I'll provide bank API credentials for payment verification later.\n\nAny questions before you start?\n\nCCIP SkillThis skill covers Cross-Chain Interoperability Protocol (CCIP): cross-chain messages and tokens, message status, routes, and contracts. It can:\nSend messages, token transfers, and programmable token transfers on testnets only; quote fees before sending when needed.\nLook up message status by message ID or source transaction; interpret lifecycle states; diagnose delayed or failed messages.\nCheck whether a route is supported, lane latency, networks, and tokens for a given path.\nDevelop TypeScript code for interacting with CCIP using the CCIP SDK\nScaffold CCIP contracts in Foundry or Hardhat/npm; run local or forked tests with Chainlink Local where it applies.\nRun Cross-Chain Token (CCT) setup: pool registration, rate limits, and adding networks on CCIP-supported chains.\nExample promptUsing the /chainlink-ccip-skill, build a cross-chain liquid staking project:\n\n- is a Foundry project\n- Users deposit a token on the source chain and get a liquid staking token on the destination chain\n- Avalanche Fuji is the source chain where the user's deposit tokens\n- Base Sepolia is the destination chain where they get a liquid staking token\n- Users can return the liquid staking token to receive their funds back on the original source chain\n- Verifies all cross chain transfers\n- Reverts if any issues arise\n- Emits events for all token moves\n- if Fuji and Base Sepolia cannot support this, say so\n\nQuestions or tradeoffs I should know about?\n\nData Feeds SkillThis skill covers Data Feeds: onchain and offchain reads, feed selection, and common production checks. It can:\nGenerate EVM consumers that use AggregatorV3Interface, check updatedAt for freshness, and read decimals from the feed instead of hardcoding them.\nAdd L2 sequencer uptime checks when the chain uses a sequencer; query historical rounds; resolve feed addresses by network.\nRead feeds offchain with ethers.js, web3.js, viem, or Python web3.\nIntegrate multi-variable and bundle feeds; follow SVR/OEV-related notes; map a stated product need to price, SmartData, rate, volatility, equity-style, or related feed families.\nBuild or adjust readers on Solana, Aptos, StarkNet, and Tron using the chain-specific patterns in the skill.\n\nExample promptUsing the /chainlink-data-feeds-skill, develop a Solidity contract that:\n\n- reads the ETH/USD Chainlink price feed on Ethereum mainnet\n- is structured as a Foundry project\n- handles required package installation and project setup\n- includes proper validation\n- follows security best practices\n\nAny questions before you start?\n\nData Streams SkillThis skill covers Data Streams: report access, schema versions, REST and WebSocket clients, onchain verification, and typical app layouts on top of streamed reports. It can:\nDescribe report schema versions: covered fields, differences between versions, and which are current or deprecated.\nFetch reports with the Go, Rust, or TypeScript SDK over the REST API (latest, by UNIX timestamp, bulk, paginated history) for your feed IDs.\nSubscribe to Websockets for streams, with or without high availability mode, and receive and decode price reports\nImplement onchain verification on EVM, Solana, or Stellar; use Chainlink Local for mock verification tests where applicable.\nQuery historical Data Streams price reports at a certain UNIX timestamp.\nDevelop frontend applications that consume and display Data Streams data in real time\nFetch price reports over the REST API to make a candlestick chart or display\nExample promptUsing /chainlink-data-streams-skill build a Bitcoin price monitoring dashboard that:\n\n- streams BTC/USD prices in real-time (<1s updates) from Chainlink Data Streams\n- displays current price with color-coded change indicator (green up, red down)\n- shows a live-updating line chart of recent price movement\n- is mobile-responsive\n- has a clean, minimal design, professional aesthetic\n- includes smooth animations for price changes, no jarring jumps\n\nUse testnet data, I will provide Data Streams credentials later via .env file\n\nQuestions or tradeoffs I should know about?\n\nACE SkillThis skill helps developers design, build, and audit policy-gated smart contracts using the open-source Chainlink ACE core contracts (smartcontractkit/chainlink-ace, BUSL-1.1, Foundry). It is grounded in the on-chain PolicyEngine, PolicyProtected, the policy and extractor libraries, and the Cross-Chain Identity registries. It can:\nDesign a policy chain for a function — pick the right pre-built policies order them safely, and reason about the defaultAllow setting and the Continue / Allowed / PolicyRejected semantics.\nWrite custom policies, extractors, and mappers — scaffold a new Policy , or a new IExtractor / IMapper so the engine can decode and feed the right parameters to your policy.\nWire Cross-Chain Identity and reason about CCID correlation and PII tradeoffs.\nBind policies to real-world data — wire SecureMintPolicy to a Chainlink Proof-of-Reserves feed (with margin mode and staleness window) so a token's mint can never exceed backing.\nBuild a compliant token end-to-end\nAdd ACE to an already-deployed contract\nWrite Foundry tests for compliance flows — unit tests for individual policies, integration tests for policy chains and ordering, and fork tests that exercise registry/issuer interactions.\nDiagram a deployment — produce Mermaid sequence and architecture diagrams of the policy chain, identity flow, and credential lifecycle.\nMap your goal back to ACE primitives — given a compliance requirement , translate it into a concrete combination of pre-built and custom policies, extractors, and registry wiring.\nExample promptUsing /chainlink-ace-skill, build a regulated stablecoin with permissioned minting and sanctions enforcement that:\n\n- restricts minting to treasury address + KYB-verified wholesale clients only\n- enforces reserve backing via Chainlink Proof-of-Reserve feed (0.5% margin, 24hr staleness limit)\n- blocks transfers to sanctioned addresses via denylist (permissionless otherwise)\n- includes freeze/unfreeze/force-transfer controls for compliance officer role\n- supports emergency pause by regulator (separate from issuer control)\n- is structured as a Foundry project with deployment scripts and proxies\n\nShow policy chain ordering for each protected function (mint/transfer/freeze) and flag any sequence that would create a bypass. Include Mermaid sequence diagrams for mint and transfer flows through the policy chain. Deploy on Sepolia.\n\nQuestions or tradeoffs I should know about?\n\nVRF SkillThis skill covers Verifiable Random Function (VRF) v2.5: subscription and direct-funding consumers, billing and network parameters, migration from V1/V2, and callback design. It can:\nBuild VRF v2.5 consumer smart contracts\nManage VRF subscriptions and consumers with direct funding method\nHelp with the migration from VRF versions 1 and 2\nDevelop unit tests using VRF mock contracts\nCalculate VRF costs before the testnet deployment\nExample promptUsing the /chainlink-vrf-skill, implement an on-chain lottery project that:\n\n- selects 3 random winners from a list of participants\n- has a colorful UI with the countdown timer until the draw\n- uses Chainlink VRF for provably fair randomness on Polygon Amoy testnet\n- handles VRF subscription management and LINK funding\n- includes events for winner selection with verifiable randomness proof\n\nAny questions before you start?\n\nUsing multiple skillsName more than one skill in the same message (for example /chainlink-data-feeds-skill and /chainlink-ccip-skill) when your task spans products so both sets of guardrails apply in one answer. Each of these skills is designed not to assume it is the only capability available. When one step feeds the next, say so up front (here: read and encode the feed, then ship it over CCIP).Example promptUsing /chainlink-data-feeds-skill, /chainlink-cre-skill, and /chainlink-ccip-skill, build a tokenized fund project that:\n\n- delivers data (NAV, yields and ESG attestations) securely on-chain\n- mints fund tokens representing shares in a tokenized investment fund\n- uses Chainlink Proof of Reserve by CRE for real-time verification of reserved assets\n- can be traded and settled seamlessly across multiple public and private chains\n- has a clean, modern UI dashboard\n\nCreate a development plan. Include steps for testing on testnets. Make sure README has instructions on how to run local CRE simulations and how to monitor status of cross-chain transfers using the CCIP CLI.\n\nAny questions before you start?","tokens":3159,"squid":"spider-08","role":"Oracle Spider","at":1791348338522,"hash":"7aa8af7285224fd0c9058d9d6a7c625ac15231e0"}
{"url":"https://docs.chain.link/datalink/push-delivery/architecture","domain":"docs.chain.link","title":"DataLink Architecture (Push Delivery) | Chainlink Documentation","text":"DataLink Architecture (Push Delivery)DataLink (Push Delivery) provides infrastructure for Data Providers to make their specialized data available onchain through direct delivery to smart contracts, leveraging the proven Chainlink Data Feeds architecture. DataLink (Push Delivery): Data comes from a provider via the Decentralized Oracle Network (DON) and is made available through through Chainlink Price aggregator contracts for smart contract access. \n\nData Provider Connection\n\nChainlink Labs curates and onboards premium Data Providers who make their specialized data available via secure API endpoints\nThe provider makes their proprietary data available via a secure API endpoint.\n\nData Fetching & Consensus (Data DON)\n\nMultiple nodes within a Chainlink Decentralized Oracle Network (DON) independently fetch data from the provider's API.\nNodes reach consensus on the data received from the provider.\n\nOnchain Delivery\n\nAutomatic Updates: Aggregated data is automatically pushed onchain to aggregator contracts based on:\n\nDeviation Threshold: Updates trigger when offchain values deviate beyond a defined threshold from the onchain value\nHeartbeat Threshold: Updates occur after a specified time interval, regardless of price movement\n\nSmart Contract Storage: Data is stored onchain in aggregator contracts, making it immediately available for smart contract consumption\n\nConsumer Access\n\nProxy Architecture: Consumer contracts access data through proxy contracts that point to the current aggregator\nStandard Interface: Integration uses the familiar AggregatorV3Interface for seamless compatibility\n\n What's next > Learn about DataLink > View available DataLink feeds > Understand data quality and responsibility > Learn how to use DataLink (Push Delivery)","tokens":441,"squid":"spider-08","role":"Oracle Spider","at":1791348350020,"hash":"9ca163aeecbcf2b6f270b1680b17963d29c6d97a"}
{"url":"https://research.arbitrum.io/t/fairflow-leveraging-timeboost-to-build-a-fair-and-transparent-l2-mev-economy/9735/1","domain":"research.arbitrum.io","title":"FairFlow: Leveraging TimeBoost to Build a Fair and Transparent L2 MEV Economy - Uncategorized - Arbitrum Research","text":"FairFlow: Leveraging TimeBoost to Build a Fair and Transparent L2 MEV Economy \n\n Uncategorized\n\n tx-ordering\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Apr 2025\n\n 1 / 1\n\n Apr 2025\n\n Apr 2025\n\n post by kosunghun317 on Apr 14, 2025\n\n kosunghun317\n\n FairFlow: Leveraging TimeBoost to Build a Fair and Transparent L2 MEV Economy\nAbout the Author\nThe author, Ko Sunghun, is a researcher at Radius. The author thanks Tariz, AJ Park, and Chanyang Ju from Radius for their feedback and helpful comments.\nTL;DR\n\nWe reviewed existing sequencing policies used by L2s and explained how out-of-protocol players recently adopted new strategies to game the policy.\nWe suggested FairFlow, a tweaked version of TimeBoost, as an alternative that may prevent such activities and eventually enable L2s to internalize more revenue.\n\nThis is a cross-posted and summarized version. For the full article, check here.\nIntroduction\nLayer 2 networks (L2s) provide low transaction fees and faster execution times, playing a vital role in maintaining the Ethereum ecosystem as a leading player in the blockchain industry. The economic growth of L2s not only drives the adoption of the Ethereum network but also attracts even more users. However, at present, there is no clear source of revenue at the protocol level for newly launched L2s beyond transaction fee income. As low fees are a key factor in their adoption, L2s cannot simply increase costs to achieve profitability. Consequently, capturing Miner Extractable Value (MEV) without compromising user experience, such as through capturing backrun revenue, has become a significant challenge. Various sequencing strategies have been proposed and implemented, but recent reports indicate that certain types of opportunities can be exploited, allowing some to game the system and capture a substantial portion of MEV without sharing it. In this post, we will thoroughly examine these phenomena and previous attempts and propose an alternative sequencing policy which is based on TimeBoost and designed to mitigate such tactics and internalize more revenue, ultimately promoting the economic growth of L2s.\nExisting Sequencing Policies\nBlock Auction\nBlock Auction is the method used on Ethereum L1. It relies on the fact that there is no in-protocol rule for ordering transactions, and any valid transaction can be included in a block. External experts compete for the right to build the entire block, and the winner is given complete control over the block building.\nPriority Ordering\nIn Priority Ordering, valid transactions are greedily sequenced in descending order based on priorityFeePerGas. This simple approach works well in most cases, and is the default setting of OP Stack chains. Under priority ordering the profit-seeking players (searchers) are willing to pay higher fees to secure positions at the top of the block. In contrast, regular users, who are less sensitive to transaction orders and waiting time, can still include their transactions even with lower fees.\nFCFS\nFirst-Come, First-Served (FCFS) processes transactions in the chronological order they are received. Although this approach appears intuitive and fair (and is preferred by regular users), it suffers from significant drawbacks. The intense competition among searchers results in spamming the network, which wastes blockspace. Moreover, the efforts of searchers for lower latency are invested in out-of-protocol infrastructures (e.g., colocation), and protocol earns nothing from it.\nTimeBoost\nProposed in 2023, TimeBoost is built on FCFS but adds an option to boost the transaction’s submission time based on an attached bid. This mechanism incentivizes time-sensitive participants, such as searchers, to pay more and thus works as an additional source of revenue for rollup. In the Arbitrum’s implementation, the winner of a periodic auction enjoys delay-free inclusion for the next minute, while transactions from the rest incur a 200 ms delay.\nSecure Block Building (SBB)\nSBB, proposed by Radius, allows the L2 sequencer to capture backrunning profits without compromising the user experience (UX). First, a user’s transaction is quickly confirmed (in bundle units) by the L2 sequencer, and once confirmed, that bundle is forwarded to the searcher. Then, the searcher creates a backrunning transaction based on the received bundle, and this newly created transaction is included at the bottom of the L2 block. Throughout this process, an encrypted mempool is employed, that is, the user’s transaction is transmitted to the L2 sequencer in an encrypted form to guard against malicious manipulation, while the searcher uses the decrypted information upon receipt to identify backrunning opportunities efficiently.\nEvolving Searcher Activities\nDespite the sequencing policies, which aim to receive more fees from those who find more value from (faster) inclusion, searchers can avoid paying high fees and capture the value for specific opportunities. The two below are among such tactics.\nBlind Backrunning\nBlind backrunning is a form of atomic arbitrage that identifies swap opportunities amid transaction execution. This strategy is feasible primarily on blockchains with low gas fees. Bots employing blind backrunning flood the network with transactions from numerous accounts, each set with different (e.g., priority fee) configurations. On chains with priority ordering (e.g., Base) or FCFS rule (e.g., Arbitrum), this tactic allows bots to backrun nearly every transaction. Such behavior not only siphons value away from the protocol but also makes it harder for the protocol (L2 in this case) to internalize transaction revenue fully. Moreover, since many of these transactions end up reverting (recently, the revert ratio has declined, but this does not necessarily mean the blind backrunning activity has decreased), the blockspace is wasted just for checking the price of DEX pools multiple times.\nPrivate Order Flow\nPrivate order flow on L1 has been criticized for accelerating centralization. In L2, it is still problematic but the reason is slightly different; it undermines the protocol’s revenue internalization. Entities with private order flow can create “pseudo” bundles that capture nearly all the revenue from backrunning. All of sequencing mechanisms described above are vulnerable to this vector. For example, under priority ordering policy, a searcher can set its transaction’s priorityFeePerGas just 1 wei lower than that of the targeted user transaction, nearly guaranteeing that its transaction will be positioned immediately after the user transaction. Similarly, in FCFS or its variants, sending multiple transactions with minimal delay almost guarantees a backrunning opportunity (it was how Polygon Fastlane guaranteed bundling).\nMoreover, most deals between searchers and dApps (or wallets) are made off-chain, and there is no standardized marketplace for order flow. Such opaque and non-transparent market landscape of private order flow causes informational asymmetries between sellers (transaction originators) and buyers (searchers), causing inefficiencies.\nPrevious Attempts\nWhile the context may vary slightly, there were multiple attempts to tackle similar problems.\nSpeed Bumps\nIn traditional finance (TradFi), exchanges often adopt asymmetric speed bumps to disincentivize quote sniping and increase liquidity. Since this policy targets only a particular type of order (quote sniping market order), the situation resembles our case. We do not want to introduce too complicated a mechanism or ad-hoc policy; we want to disincentivize the blind backrunning and the induced waste of blockspace.\nLocal Fee Markets\nIn Solana and several other chains, local fee markets are suggested and adopted so that interacting with only specific contracts or storage that is frequently touched becomes expensive, while other transactions remain cheap. Again, this policy may work well for L2s to prevent or disincentivize blind backrunning. However, it risks the degradation of UX for transactions that include the transfer of several popular ERC-20 tokens and will be hard to implement appropriately.\nSEC Order Competition Rules\nThe SEC recently proposed the order competition rule called Proposed Rule 615 to solve the problem with private order flow. Their primary rationale was that by forcing the auction for the right of routing each order, they might assure the investor of a better execution than the status quo. Although it did not result in implementation, it is notable that holding an auction for each order or transaction is a viable option.\nIntroducing FairFlow\nIn this section, we present a variant of TimeBoost called FairFlow, which seeks to capture revenue from backrunning opportunities that current sequencing methods overlook, without compromising user experience. It achieves such goal by enshrining a marketplace for backrunning that anyone can participate in. By combining elements of a Dutch auction with TimeBoost, FairFlow incentivizes searchers to engage and compete within this designated market instead of relying on third-party OFA protocols. We believe that FairFlow can assist Layer 2 solutions in reclaiming value from backrunning more effectively and reducing blockspace waste.\nGoals\nBelow are the objectives we aim to achieve with FairFlow:\nEstablishing a Permissionless Marketplace for Backrunning Opportunities\nWe aspire to create a marketplace that fosters healthy competition among searchers and facilitates price discovery for each backrunning opportunity. Our ultimate goal is to enhance the overall efficiency and transparency of order flow markets, and making it a dominant strategy to send transaction directly to FairFlow for users.\nUser Protection\nWe strive to minimize the risks associated with sandwich and front-running attacks, and waste of blockspace induced by spam transactions. Our aim is to create an environment where L2 users can transact safely and conveniently, without significant delays or additional costs.\nBuilding a sustainable L2 economy\nBy internalizing backrunning revenue at the protocol level, we support L2 in developing a stable revenue structure. This approach is expected to foster a virtuous cycle that contributes to the growth of the entire Ethereum ecosystem.\nHow it works\nAs mentioned, FairFlow is essentially a variation of Arbitrum’s TimeBoost, and its sequencing policy can be largely divided in three steps:\n\nWhen the sequencer receives a user transaction, it initiates a Dutch auction for the right to backrun that transaction. Searchers who want to backrun the user transaction send an EIP-712 signature for the bid and backrunning transaction to the auctioneer (sequencer). Note that the user may attach the bid for herself (self-bid).\nWhen the reserve price becomes less than or equal to one of the submitted bids, the auction is closed, and the user transaction and backrunning transaction (if any) are bundled together then added to the BundleList.\nAt each block creation, bundles are selected from the BundleList—up to the gas limit—and included in the block for sequential execution in an FCFS manner (i.e., the older bundle is executed earlier).\n\nIn short, to achieve aforementioned goals, we adopted TimeBoost’s mechanism with simple tweak: enabling anyone to boost user’s transaction by bidding on behalf of user, and in exchange she receives a right to backrun the user transaction. In the following section we explain the rationale behind of such design, and how it will eventually disincentivize spamming blind backrunning trials and enable L2s to earn more revenue.\nAnalysis\nRationale\n\nSingle Public Market\nEvery transaction is disclosed to subscribers before its inclusion, establishing this market as a dominant and aggregative platform for order flow. This approach reduces fragmentation and enhances price discovery.\nDutch Auction\nBy implementing an off-chain auction system, we can limit spam transactions to a maximum of one per user transaction. Additionally, the nature of a Dutch auction allows the protocol to effectively capture revenue, even in the presence of third-party On-chain Frontrunning Alternatives (OFA) protocols. If a searcher obtains information about an incoming transaction, they must pay a high price; otherwise, that information will be shared with others, preventing them from effectively exploiting the situation without adequate compensation.\nFurthermore, even if an external third-party protocol manages to bundle transactions, such as by utilizing a signature-based off-chain auction that renders the user’s intent and the searcher’s operations inseparable, they will generally incur more delays. This is because the searcher who wins the auction to fulfill the user’s intent will have reduced budget resources (having paid to win the OFA), thereby limiting their ability to bid sufficiently to boost the transaction. As a result, for time-sensitive activities like NFT minting or purchasing newly launched memecoins, using such a platform may not prove to be the most optimal choice.\n\nExpected Results\nWe primarily anticipate two key outcomes:\n\nReduction in spam and waste of blockspace: By limiting the occurrence of blind backrunning trials to a maximum of one per user transaction, even in scenarios with multiple entities attempting blind backrunning, we expect a significant decrease in wasted blockspace.\nEnhancement of internalized revenue and market efficiency: Rather than having order flow distributed across fragmented and opaque markets, all transactions will be facilitated within a single market featuring numerous competitive bidders. This consolidation will improve the efficiency and price discovery of order flow, ultimately boosting the revenue for the protocol and its aligned partners.\n\nLimitations\n\nWe note that under current version the transaction originators (wallets and dApps) cannot earn revenue, and blindly setting kickback policy would further distort the dynamics (revenue sharing may result in lowering the reserve price for searchers). While we do not discuss in kickback or revenue sharing in this post, it seems like manually whitelisting addresses (e.g., multisig treasury of aligned dApps) for revenue sharing is a correct policy in general.\nAdditionally, while it is generally unwise economically, sandwich attacks or frontrunning are theoretically feasible by outbidding a user transaction immediately upon receipt and discerning the user’s intent. However, it is important to note that even if such an attack is possible, the attacker faces significant risks, as their own attacking transaction would also be broadcast to other searchers and backrunnable.\nIt is hard to set the parameters correctly. For FairFlow to work as intended and not hinder user experience, the auction period should be neither too long nor too short. If it is too long, average users will experience a too long delay. If it is too short, no searcher will adequately value the backrunning opportunities and choose to spam or ignore them. Moreover, the reserve price curve should properly decay to capture the full value adequately. While we do not provide exact numbers in this post, we mention general points to be considered in the later section.\n\nTechnical Description\nThis section describes the mechanism and overall system in greater detail.\nGlossary\n\nSequencer: The L2 entity responsible for receiving user transactions, initiating the backrunning auction, and managing the ordering of transactions for block inclusion.\nUser: The end-user or dApp that submits a transaction for inclusion in L2 block.\nSearcher(s): Entities (bots or operators) that monitor pending transactions, participate in auctions, and submit backrunning transactions.\nExecutor: The L2 entity that aggregates and executes transactions in each block. While it does not need to be a different entity from Sequencer, to help understanding in this article we divided them in two.\nUserTx: The original transaction submitted by the user.\nAuctioneer Contract: a smart contract that maintains balance of each bidder and settles payment for each auction.\nBid: A submission from a searcher or advanced user, in the form of an EIP-712 signature, indicating their willingness to backrun a given transaction for a specified fee.\nBackrunTx: The backrunning transaction submitted by a searcher as part of their bid.\nBundleList: The ordered queue that stores finalized bundles (each comprising a UserTx and, if applicable, a winning BackrunTx) waiting for inclusion in the block.\nAuction Parameters: These parameters determine the shape of the reserve price curve for a Dutch auction. While the needed parameters can vary across the base curve (linear, reciprocal, exponential, …), this article introduces the following:\n\nmax_period: The maximum period the auctioneer will wait for the bid, i.e., the maximum possible auction duration.\nmin_price: Minimum price that the auctioneer wants to receive. If no bid exceeds or equals this value, the auction will be resolved with no winner after the max_period passes.\ndecay_rate: The rate of decrease of reserve price.\n\nLifecycle of Transaction\nUntitled-2025-01-17-23354298×1110 641 KB\nUnder FairFlow, a user’s transaction undergoes the following procedure:\n\nSubmission:\nA User submits a transaction (UserTx) to the Sequencer, and optionally a Bid for Dutch auction.\nAuction Initiation:\nUpon receiving a new UserTx, the Sequencer initiates a Dutch auction for the right to backrun the transaction.\nNotification:\nThe Sequencer forwards the UserTx details to Searcher(s) who subscribed to the user transactions with FF_newPendingTransactions API.\nBidding:\nSearcher(s) analyze the pending transaction for backrunning opportunities. If an opportunity is identified, a searcher submits a Bid and a BackrunTx using the FF_submitBackrunTxAndBid API.\nAuction Resolution:\nThe Sequencer waits until the reserve price (determined by a decaying reserve price curve) falls below one of the submitted valid bids. At that point, the auction closes, and a winning bid is determined. (Note: There may be no winner if no searcher is interested.)\nBundling:\nThe resulting bundle (containing the original UserTx and, if applicable, the winning BackrunTx) is added to the BundleList.\nPreconfirmation:\nAn order commitment is issued to the user, ensuring the transaction will be executed in a predetermined order.\nBlock Inclusion:\nJust before block creation, the Sequencer selects the oldest bundles from the BundleList (up to the gas limit) and delivers them to Executor via the FF_requestBundleList API.\nBlock Construction:\nThe Executor constructs a block by sequentially executing transactions within the received bundles, and publish it.\n\nBackrunning Auction\nIn this section, we explain the auction itself with a greater depth.\nReserve Price Curve\nThe shape and parameters of the reserve price curve are crucial. Improper settings can lead to negligible value capture while inducing excessive delay. We propose two curve models:\nLinear Decaying Curve\nLinear decaying curve is a simple and intuitive model that decreases the reserve price at a constant rate:\nreserve_price(t) = min_price + decay_rate × (max_period - t).\nWhile it may fail to capture the full value in case of outliers, many protocols have adopted such a curve due to its simplicity. Such protocols include:\n\n1inch Fusion: 1inch Fusion adopted a partially linear curve configurable by the user.\nUniswapX: Similarly to 1inch Fusion, UniswapX sells the right to fill the user order to “fillers” in Dutch auction format, with a linear curve configurable by the user.\nOther examples include, but are not limited to, DAI’s liquidation auction, Opyn’s crab strategy vault’s rebalancing auction, etc.\n\nReciprocal Decaying Curve\nThis model uses the inverse of a function that was initially suggested in the original TimeBoost paper, referred to as the simplest form of delaying function:\nreserve_price(t) = min_price + decay_rate × (max_period / t - 1).\nProvided that searchers’ latency is low enough, it can capture most of the value in almost every case.\nSetting Parameters and Trade-Offs\nWhile each L2 can freely select the curve and parameters, some general recommendations exist for setting parameters.\n\nThe maximum period should not be too long, as it may damage the user experience. We recommend that the period be set under 1 second, which is more than enough for most searchers who target users’ transactions for backrunning arbitrage opportunities. Several other platforms and trials are also adopting around 100ms-500ms auction period.\nThe curve should not decay too much at earlier periods. Due to the physical limit, some latencies cannot be avoided, and only a handful of players can bid at that time, which leads to value leakage. Thus, at the very beginning, the price should be set higher than the expected value, and it is recommended to adopt either a reciprocal curve or a linear curve with kink at earlier periods.\nIt is recommended that the parameters be iteratively adjusted so that most of the resolution can occur within the middle of the auction rather than at the beginning or the end.\nAnother metric to consider is the gap between the bid and the reserve price at the moment of bid reception. Most searchers will minimize the time gap between bid submission and auction resolution to avoid volatility. If the gap is too big, the curve may decay too fast and fail to capture the full value.\n\nBid Settlement\nSearchers or advanced users submit their bids with a BackrunTx using an EIP-712 signature. The Auctioneer Contract on each L2 processes these submissions. The auction is resolved once the decaying reserve price falls below one of the submitted bids. An auctioneer account owned by Sequencer will send the settlement transaction, which will deduct the bidder’s balance in Auctioneer Contract. Note that the settlement may not be synchronous to the execution of the bundle. Also, while Sequencer may not need to simulate execution and track the entire state of chain, it will track the balance of bidders at vault and will only accept the bid such that lastly reported balance is greater than certain threshold multiple of submitted bid. This is to prevent insolvency. Monad implemented a similar system to provide both fast inclusion while preventing spamming from low balance accounts.\nConclusion\nThrough this post, we have examined existing sequencing policies and how recently developed strategies are exploiting these policies, ultimately degrading user experience and hindering protocols from effectively internalizing revenue. In response, we propose FairFlow, which establishes a single public auction market, allowing all participants to bid fairly for backrunning opportunities. Our design specifically implements a protocol-level auction for each transaction and implicitly introduces additional delays for transactions that contain privately extracted MEV outside the protocol. This mechanism not only incentivizes market participants to engage in the public auction but also enables L2s and searchers to internalize MEV from backrunning opportunities more efficiently, addressing inefficiencies arising from private order flow markets and spam transactions. We provide detailed APIs and sequence diagrams to further elucidate the implementation. We hope this design will be helpful and sound enough for upcoming (or existing) L2s to adopt.\nAbout Radius\nRadius is dedicated to advancing Ethereum’s L2 ecosystem with fair and transparent MEV capture. Our protocol-level backrunning infrastructure supports the sustainability and profitability of L2s, contributing to our vision of Ethereum’s growth as a leading platform.\nOur research on FairFlow explores potential approaches to L2 challenges. If you’re interested in learning more about our research or products like Secure Block Building (SBB) or Lighthouse, we’d love to connect. Together, we can help L2s generate stable revenue, attract users, and strengthen the Ethereum ecosystem.\n\n read \n\n 8\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 Time boost: a new transaction ordering policy proposal\n\n Uncategorized\n\n 34\n\n 9.8k\n\n Sep 2023\n\n Proposed design for Timeboost\n\n Uncategorized\n\n 12\n\n 3.3k\n\n Jun 2024\n\n Transaction ordering policy\n\n Uncategorized\n\n 10\n\n 8.6k\n\n Mar 2023\n\n The power of faster blocks\n\n Uncategorized\n\n 11\n\n 4.2k\n\n Sep 2024\n\n MEV Capture Through Time-Advantaged Arbitrage\n\n Uncategorized\n\n 0\n\n 811\n\n Oct 2024","tokens":6135,"squid":"spider-01","role":"Chain Spider","at":1791348350064,"hash":"defe05c3e25a530754551d520bbb0a85ac15a097"}
{"url":"https://docs.phantom.com/bitcoin/detecting-the-provider","domain":"docs.phantom.com","title":"Detect the provider - Phantom developer documentation","text":"The window.phantom.bitcoin provider has been deprecated.\nPhantom’s browser extension and mobile in-app browser will both inject a phantom object into the window of any web application the user visits, provided that site is using https://, on localhost, or is 127.0.0.1. Phantom will not inject the provider into iframes or sites using http://.\nIf a phantom object exists, Bitcoin and Ordinals dapps can interact with Phantom via the API found at window.phantom.bitcoin. To detect if Phantom is installed, an application should check for an additional isPhantom flag like so:\nconst isPhantomInstalled = window?.phantom?.bitcoin?.isPhantom\n\nIf Phantom is not installed, we recommend you redirect your users to our website https://phantom.com/. Altogether, this may look like the following:\nconst getProvider = () => {\n if ('phantom' in window) {\n const anyWindow: any = window;\n const provider = anyWindow.phantom?.bitcoin;\n\n if (provider && provider.isPhantom) {\n return provider;\n }\n }\n\n window.open('https://phantom.com/', '_blank');\n};\n\nWhen adding a Phantom button to your dapp’s wallet modal, we recommend using the name “Phantom” with an SVG/PNG icon, which you can find in Logos and assets.\nWas this page helpful?","tokens":305,"squid":"spider-10","role":"Tooling Spider","at":1791348350578,"hash":"d593aebb5611a42e70474ec07b5e56d8dd5efa62"}
{"url":"https://akash.network/docs/node-operators/validators/tmkms-stunnel","domain":"akash.network","title":"Validator with TMKMS | Akash Network - Your Guide to Decentralized Cloud","text":"Validator with TMKMS Deploy an Akash validator on the network with Tendermint Key Management System (TMKMS) for maximum security. Your validator private key is stored on a separate, secured server instead of the validator node itself.\nTime: 2-3 hours\n\nOverview\nThis guide shows how to deploy a validator with:\nFeatures:\n\nRemote Key Management - Validator key stored on separate TMKMS server\nEncrypted Communication - Stunnel provides TLS encryption between validator and TMKMS\nRuns on Akash - Validator deployed on Akash Network\nState Sync - Fast initial synchronization (~5 minutes)\n\nSecurity Benefits:\n\nValidator private key never on validator node\nKey can be on HSM (Hardware Security Module)\nKey isolated from internet-facing validator\nAdditional layer against key theft\n\nArchitecture\n+-----------------------+ Encrypted +-----------------------+| Akash Validator | (Stunnel) | TMKMS Server || (Deployment) | <--------------------> | (Your Server) || | | || +----------------+ | | +----------------+ || | Validator Node | | Port 26658 | | TMKMS | || | (no priv key) |---|-----(signs blocks)------|--| (has priv key) | || +----------------+ | | +----------------+ || | | || +----------------+ | | +----------------+ || | Stunnel | | Port 36658 | | Stunnel | || | Server |---|-----(TLS tunnel)--------|--| Client (Docker)| || +----------------+ | | +----------------+ |+-----------------------+ +-----------------------+ | | | | v v Akash Network Your Infrastructure\nHow it works:\n\nValidator receives block to sign\nSends signing request to Stunnel server (port 26658)\nStunnel server encrypts and forwards to Stunnel client (port 36658)\nStunnel client decrypts and forwards to TMKMS (port 26658)\nTMKMS signs with private key\nSignature returns via same encrypted path\nValidator broadcasts signed block\n\nPrerequisites\nBefore starting, ensure you have:\n1. Akash Wallet\n\nFunded with 50+ AKT for deployment deposits\nSee Akash CLI Installation\n\n2. Separate TMKMS Server\n\nOS: Ubuntu 20.04+ or 22.04 LTS\nCPU: 2 cores minimum\nRAM: 2 GB minimum\nNetwork: Internet connectivity\nSecurity: Firewall configured, SSH hardened\nAccess: Root or sudo access\n\n3. Validator Private Key\n\nFrom existing validator, or\nGenerate new key (we’ll cover this)\n\n4. Akash Console\n\nFamiliar with deploying on Akash\nSee Akash Console Guide\n\nStep 1 - Obtain Validator Private Key\nYou need a validator private key to import into TMKMS.\nOption A: Use Existing Validator Key\nIf you have an existing validator:\nTerminal windowcat ~/.akash/config/priv_validator_key.json\nCopy this file’s contents and save securely.\nOption B: Generate New Key\nDeploy a temporary Akash node to generate a key:\n\nFollow Node Build via Omnibus\nOnce deployed, run in shell:\n\nTerminal windowcat ~/.akash/config/priv_validator_key.json\n\nCopy the key contents\nClose the deployment\n\nKey Format\nYour private key file should look like:\n{ \"address\": \"134FCAC9E5C...\", \"pub_key\": { \"type\": \"tendermint/PubKeyEd25519\", \"value\": \"BrL0wA8DWiVvm...\" }, \"priv_key\": { \"type\": \"tendermint/PrivKeyEd25519\", \"value\": \"3RphlkX7PucBKSdhFKviFV5TI...\" }}\nSecurity: Save this file securely offline. You’ll import it to TMKMS server next.\n\nStep 2 - Deploy Validator on Akash\nDeploy the validator node (without private key) on Akash Network with Stunnel server.\nGet SDL Template\nTemplate: cosmos-omnibus TMKMS example\nCustomize SDL\nThe SDL contains 2 services:\n\nnode - Validator node (private key managed by TMKMS)\nproxy - Stunnel server (encrypts communication)\n\nRequired customizations:\nservices: node: env: - MONIKER=my-validator # Change this\n proxy: env: - PSK=<your-unique-psk> # Generate strong PSK\nGenerate PSK (Pre-Shared Key):\nTerminal windowopenssl rand -hex 32\nSave this PSK - you’ll need it for Stunnel client configuration.\nFull SDL (Customized)\n---version: \"2.0\"\nservices: node: image: ghcr.io/akash-network/cosmos-omnibus:v1.2.43-akash-v2.0.1 env: - MONIKER=my-validator # Change this - CHAIN_JSON=https://raw.githubusercontent.com/akash-network/net/main/mainnet/meta.json - MINIMUM_GAS_PRICES=0.025uakt - P2P_POLKACHU=1 - STATESYNC_POLKACHU=1 - AKASH_PRIV_VALIDATOR_LADDR=tcp://0.0.0.0:26658 # Remote signer expose: - port: 26657 # RPC (internal to proxy only) to: - service: proxy - port: 26658 # Signing port (internal to proxy only) to: - service: proxy params: storage: data: mount: /root/.akash\n proxy: image: ghcr.io/ovrclk/stunnel-proxy:v0.0.1 env: - PSK=<your-psk-from-above> # Must match Stunnel client - STUNNEL_SVC_RPC_ACCEPT=36657 - STUNNEL_SVC_RPC_CONNECT=node:26657 - STUNNEL_SVC_SIGNER_ACCEPT=36658 - STUNNEL_SVC_SIGNER_CONNECT=node:26658 expose: - port: 36657 # Encrypted RPC (global) to: - global: true - port: 36658 # Encrypted signer (global) to: - global: true\nprofiles: compute: node: resources: cpu: units: 8 memory: size: 16Gi storage: - size: 1Gi - name: data size: 500Gi attributes: persistent: true class: beta3 proxy: resources: cpu: units: 1 memory: size: 512Mi storage: size: 512Mi\n placement: dcloud: attributes: host: akash signedBy: anyOf: - akash1365yvmc4s7awdyj3n2sav7xfx76adc6dnmlx63 pricing: node: denom: uakt amount: 100000 proxy: denom: uakt amount: 10000\ndeployment: node: dcloud: profile: node count: 1 proxy: dcloud: profile: proxy count: 1\nDeploy via Akash Console\n\nOpen Akash Console\nClick “Deploy”\nSelect “Empty” template\nPaste your customized SDL\nAccept deposit (increase to 50+ AKT for longer runtime)\nSelect trusted provider (validator security is critical!)\nSubmit deployment\n\nWait for Deployment\nExpected behavior:\n\nDeployment will show as running\nNode container will restart repeatedly with error\nThis is normal! Node is waiting for TMKMS connection\n\nCapture Connection Details\nYou need 3 pieces of information from the deployment:\n\nGo to “LEASES” tab\nFind the “Forwarded Ports” section\nNote:\n\nProvider URI: (e.g., provider.mainnet-1.ca.aksh.pw)\nPort for 36658 → ???: (e.g., 31684) - This is your Signer Port\nPort for 36657 → ???: (e.g., 32675) - This is your RPC Port\nSave these - you’ll need them for Stunnel client configuration.\n\nStep 3 - Setup TMKMS Server\nAll commands in this step run on your TMKMS server (not the Akash deployment).\nInstall Dependencies\nTerminal window# Update systemsudo apt updatesudo apt install -y git build-essential ufw curl jq libusb-1.0-0-dev\n# Install Rustcurl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | shsource $HOME/.cargo/env\n# Set Rust flags for optimizationexport RUSTFLAGS=-Ctarget-feature=+aes,+ssse3\nInstall TMKMS\nTerminal windowcd ~git clone https://github.com/iqlusioninc/tmkms.gitcd ~/tmkmscargo install tmkms --features=softsign\nThis takes 5-10 minutes to compile.\nInitialize TMKMS\nTerminal windowmkdir -p /etc/tmkmstmkms init /etc/tmkms/\nCreated files:\n\n/etc/tmkms/tmkms.toml - Configuration file\n/etc/tmkms/secrets/ - Directory for keys\n\nImport Validator Private Key\nCreate the key file:\nTerminal windowvi /etc/tmkms/secrets/priv_validator_key.json\nPaste your validator private key from Step 1:\n{ \"address\": \"134FCAC9E5C...\", \"pub_key\": { \"type\": \"tendermint/PubKeyEd25519\", \"value\": \"BrL0wA8DWiVvm...\" }, \"priv_key\": { \"type\": \"tendermint/PrivKeyEd25519\", \"value\": \"3RphlkX7PucBKSdhFKviFV5TI...\" }}\nConvert Key to TMKMS Format\nTerminal windowtmkms softsign import \\ /etc/tmkms/secrets/priv_validator_key.json \\ /etc/tmkms/secrets/priv_validator_key.softsign\nExpected output:\nImported validator key akashvalcons1...\nSecure Key Permissions\nTerminal windowchmod 600 /etc/tmkms/secrets/priv_validator_key.softsign\nDelete Original Key File\nTerminal windowshred -uvz /etc/tmkms/secrets/priv_validator_key.json\nImportant: The key is now in .softsign format. Back up this file securely offline.\n\nConfigure TMKMS\nCreate configuration file:\nTerminal windowcat > /etc/tmkms/tmkms.toml <<EOF# Tendermint KMS configuration\n[[chain]]id = \"akashnet-2\"key_format = { type = \"bech32\", account_key_prefix = \"akashpub\", consensus_key_prefix = \"akashvalconspub\" }state_file = \"/etc/tmkms/state/akashnet-2-consensus.json\"\n[[providers.softsign]]chain_ids = [\"akashnet-2\"]key_type = \"consensus\"path = \"/etc/tmkms/secrets/priv_validator_key.softsign\"\n[[validator]]chain_id = \"akashnet-2\"addr = \"tcp://127.0.0.1:36658\"secret_key = \"/etc/tmkms/secrets/kms-identity.key\"protocol_version = \"v0.34\"reconnect = trueEOF\nImportant settings:\n\nchain_id - Must be akashnet-2 (mainnet)\naddr - Points to Stunnel client (local port 36658)\nreconnect - Automatically reconnects if connection drops\n\nCreate State Directory\nTerminal windowmkdir -p /etc/tmkms/state\n\nStep 4 - Setup Stunnel Client\nThe Stunnel client provides encrypted connection between TMKMS and your Akash validator.\nRun on TMKMS server (same server as TMKMS).\nInstall Docker and Docker Compose\nTerminal window# Install Dockercurl -fsSL https://get.docker.com -o get-docker.shsh get-docker.sh\n# Install Docker Composesudo curl -L \"https://github.com/docker/compose/releases/download/v2.24.0/docker-compose-$(uname -s)-$(uname -m)\" -o /usr/local/bin/docker-composesudo chmod +x /usr/local/bin/docker-compose\nClone Stunnel Proxy Repository\nTerminal windowmkdir -p ~/stunnelcd ~/stunnelgit clone https://github.com/akash-network/stunnel-proxycd stunnel-proxy/client\nConfigure Stunnel Client\nEdit docker-compose.yml:\nTerminal windowvi docker-compose.yml\nUpdate these variables with your deployment details from Step 2:\nenvironment: - PSK=<your-psk> # Must match SDL PSK - STUNNEL_SVC_RPC_CONNECT=<provider-uri>:<rpc-port> - STUNNEL_SVC_SIGNER_CONNECT=<provider-uri>:<signer-port>\nExample:\nenvironment: - PSK=a1b2c3d4e5f6789... - STUNNEL_SVC_RPC_CONNECT=provider.mainnet-1.ca.aksh.pw:32675 - STUNNEL_SVC_SIGNER_CONNECT=provider.mainnet-1.ca.aksh.pw:31684\nStart Stunnel Client\nTerminal windowdocker-compose up -d\nVerify Stunnel Client\nTerminal windowdocker-compose logs -f\nExpected: Should show successful TLS connection to Stunnel server.\n\nStep 5 - Start TMKMS\nRun TMKMS service on your TMKMS server.\nStart in Foreground (Testing)\nTerminal windowtmkms start -c /etc/tmkms/tmkms.toml\nExpected Initial Logs\nWhile waiting for Stunnel connection, you’ll see:\nINFO tmkms::commands::start: tmkms starting...INFO tmkms::keyring: [keyring:softsign] added consensus Ed25519 keyINFO tmkms::connection::tcp: KMS node ID: 948f8fee83f7715f99b8b8a53d746ef00e7b0d9eERROR tmkms::client: [akashnet-2@tcp://127.0.0.1:36658] I/O error: Connection refused (os error 111)\nThis is normal! TMKMS is trying to connect to Stunnel client (port 36658).\nWait for Connection\nAfter Stunnel client connects (from Step 4), you’ll see:\nINFO tmkms::connection::tcp: KMS node ID: 7a1f7c7f726d94787045cca9fee05c1ec67cd09aINFO tmkms::session: [akashnet-2@tcp://127.0.0.1:36658] connected to validator successfullyWARN tmkms::session: [akashnet-2@tcp://127.0.0.1:36658]: unverified validator peer ID!\nSuccess! TMKMS is now connected and signing blocks.\nRun as Service (Production)\nCreate systemd service:\nTerminal windowsudo tee /etc/systemd/system/tmkms.service > /dev/null <<EOF[Unit]Description=Akash TMKMSAfter=network.target\n[Service]Type=simpleUser=rootExecStart=/root/.cargo/bin/tmkms start -c /etc/tmkms/tmkms.tomlRestart=on-failureRestartSec=3LimitNOFILE=65535\n[Install]WantedBy=multi-user.targetEOF\nEnable and start:\nTerminal windowsudo systemctl daemon-reloadsudo systemctl enable tmkmssudo systemctl start tmkms\nCheck status:\nTerminal windowsudo systemctl status tmkmssudo journalctl -u tmkms -f\n\nStep 6 - Verify Everything is Working\nCheck TMKMS Logs\nTerminal windowsudo journalctl -u tmkms -f --lines 50\nLook for:\n\nconnected to validator successfully\nSigning messages (height increasing)\n\nCheck Akash Validator Logs\nIn Akash Console:\n\nGo to your deployment\nClick “LOGS” tab\nSelect “node” service\n\nLook for:\n\nexecuted block height=...\ncommitted state height=...\nHeight increasing continuously\n\nCheck Stunnel Proxy Logs\nIn Akash Console:\n\nSelect “proxy” service from logs\nLook for: TLS connection success messages\n\nExample successful logs:\nLOG5: Service [signer] connected remote serverLOG6: TLS accepted: previous session reusedLOG6: TLSv1.3 ciphersuite: TLS_CHACHA20_POLY1305_SHA256\n\nStep 7 - Create Your Validator\nNow that your node is running with TMKMS, create the validator.\nSet Environment Variables\nOn your local machine (with akash CLI). Ensure jq is installed (curl is usually available).\nTerminal windowexport AKASH_META_URL=\"${AKASH_META_URL:-https://raw.githubusercontent.com/akash-network/net/main/mainnet/meta.json}\"export AKASH_CHAIN_ID=\"$(curl -sSf \"$AKASH_META_URL\" | jq -r '.chain_id')\"export AKASH_NODE=\"$(curl -sSf \"$AKASH_META_URL\" | jq -r '.apis.rpc[0].address')\"export AKASH_KEYNAME=<your-key-name>export AKASH_GAS=autoexport AKASH_GAS_ADJUSTMENT=1.25export AKASH_GAS_PRICES=0.025uakt\nGet Validator Public Key\nYou need the validator’s consensus public key. This is in the TMKMS startup logs.\nLook for:\nINFO tmkms::keyring: added consensus Ed25519 key: akashvalconspub1zcjduepq...\nOr query your deployment via shell and run:\nTerminal windowakash tendermint show-validator\nSave this value as AKASH_VALOPER_PUBKEY.\nCreate Validator Transaction\nTerminal windowakash tx staking create-validator \\ --amount=1000000uakt \\ --pubkey=\"$AKASH_VALOPER_PUBKEY\" \\ --moniker=\"<your-moniker>\" \\ --chain-id=\"$AKASH_CHAIN_ID\" \\ --commission-rate=\"0.10\" \\ --commission-max-rate=\"0.20\" \\ --commission-max-change-rate=\"0.01\" \\ --min-self-delegation=\"1\" \\ --gas=\"$AKASH_GAS\" \\ --gas-adjustment=\"$AKASH_GAS_ADJUSTMENT\" \\ --gas-prices=\"$AKASH_GAS_PRICES\" \\ --from=\"$AKASH_KEYNAME\"\nParameters:\n\n--amount - Self-delegation amount (e.g., 1000000uakt = 1 AKT)\n--moniker - Your validator’s display name\n--commission-rate - Starting commission (e.g., 0.10 = 10%)\n\nVerify Validator\nTerminal windowakash query staking validator $(akash keys show $AKASH_KEYNAME --bech val -a)\nCheck on Akash Block Explorers:\n\nMintscan\nPing.pub\n\nSecurity Best Practices\nTMKMS Server Hardening\nFirewall rules:\nTerminal windowsudo ufw default deny incomingsudo ufw default allow outgoingsudo ufw allow 22/tcp # SSHsudo ufw enable\nDisable password authentication:\nTerminal windowsudo vi /etc/ssh/sshd_config# Set: PasswordAuthentication nosudo systemctl restart sshd\nKey Backups\nCritical files to backup securely offline:\n\n/etc/tmkms/secrets/priv_validator_key.softsign\n/etc/tmkms/secrets/kms-identity.key\nYour wallet mnemonic\n\nMonitoring\nMonitor these continuously:\n\nTMKMS service status\nStunnel connection\nValidator uptime\nDisk space on validator deployment\n\nHigh Availability\nFor production validators:\n\nUse HSM for TMKMS keys\nImplement Sentry Node Architecture\nDeploy multiple sentries across providers\nMonitor with alerts (PagerDuty, etc.)\n\nTroubleshooting\nTMKMS Connection Refused\nSymptom: Connection refused (os error 111)\nSolutions:\n\nVerify Stunnel client is running: docker ps\nCheck Stunnel client logs: docker-compose logs -f\nVerify PSK matches in both SDL and docker-compose.yml\nVerify ports in tmkms.toml (36658)\n\nValidator Not Signing\nSymptom: TMKMS connected but no signing messages\nSolutions:\n\nCheck validator logs for errors\nVerify priv_validator_key.json deleted from validator\nRestart validator deployment\nCheck state file: cat /etc/tmkms/state/akashnet-2-consensus.json\n\nStunnel TLS Errors\nSymptom: TLS handshake failed\nSolutions:\n\nVerify PSK matches exactly\nCheck provider URI and ports\nVerify Akash deployment is running\nCheck firewall rules\n\nAdditional Resources\n\nTMKMS GitHub\nCosmos Validator Security\nStunnel Documentation\nOmnibus TMKMS Example\n\nEdit page on github\n Omnibus Mainnet 18","tokens":3855,"squid":"spider-03","role":"Compute Spider","at":1791348361285,"hash":"f59451b35d32aac1fdc8dd238d48cbec23ec3b3a"}
{"url":"https://docs.phantom.com/bitcoin/provider-api-reference","domain":"docs.phantom.com","title":"Provider API reference - Phantom developer documentation","text":"The window.phantom.bitcoin provider has been deprecated.\n​Methods\n​requestAccounts\n​Description\nConnects to the user’s Phantom account.\n​Parameters\nNone\n​Response\n​arrayArray of the connected user’s BtcAccount objects.\n​BtcAccount response object properties\n​stringThe Bitcoin address owned by the user.\n​p2tr, p2wpkh, p2sh, p2pkhThe address’s format. For details, see Bitcoin Design Glossary.\n​stringA hex string representing the bytes of the public key of the account.\n​payment, ordinalsThe general purpose of the address. If ordinals, the user prefers to store Ordinals on this address. If payment, the user prefers to store Bitcoin on this address.\n​signMessage\n​Description\nSigns a message with the user’s Phantom account.\n​Parameters\n​Uint8arrayThe message to be signed.\n​stringOne of the user’s addresses that should be used to sign the message.\n​Response\n​objectObject containing the signature.\n​signPSBT\n​Description\nSigns a Partially-Signed Bitcoin Transaction (PSBT).\n​Parameters\n​Uint8ArrayA serialized PSBT.\n​objectConfiguration options for signing the PSBT.\n​options parameters\nAn array containing the indexes of which transaction inputs to sign, and how to sign them.\n​Response\n​stringA serialized PSBT where the inputs belonging to the user’s account have been signed.\n​Events\n​accountsChanged\n​Description\nThe event that is emitted when a user changes their connected Phantom account.\ntype AccountsChangedEvent = (accounts: BtcAccount[]) => void;\n\n​Properties\n​BtcAccount[]The array of BtcAccount objects of the newly connected Phantom account.\n​BtcAccount response object properties\n​stringThe Bitcoin address owned by the user.\n​p2tr, p2wpkh, p2sh, p2pkhThe address’s format. For details, see Bitcoin Design Glossary.\n​stringA hex string representing the bytes of the public key of the account.\n​payment, ordinalsThe general purpose of the address. If ordinals, the user prefers to store Ordinals on this address. If payment, the user prefers to store Bitcoin on this address.Was this page helpful?","tokens":504,"squid":"spider-10","role":"Tooling Spider","at":1791348363100,"hash":"bc743f96afa75ca0f36ccf9662bd9d089d081c93"}
{"url":"https://research.arbitrum.io/t/transaction-ordering-policy/127/1","domain":"research.arbitrum.io","title":"Transaction ordering policy - Uncategorized - Arbitrum Research","text":"Transaction ordering policy \n\n Uncategorized\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 Aug 2022\n\n 1 / 11\n\n Aug 2022\n\n Mar 2023\n\n post by edfelten on Aug 30, 2022\n\n edfelten\n\n The Arbitrum sequencer receives transactions from users and publishes an ordered sequence, which serves as input to the execution stage of Arbitrum. Currently the sequencer follows a first-come, first-served (FCFS) sequencing policy.\nThere’s a lot to like about FCFS. It’s simple and easy to explain. It is seems intuitively fair. It minimizes latency because the policy allows each transaction to be appended to the sequence immediately on arrival.\nOther rollup protocols use FCFS as well. Optimism does, and based on descriptions of other systems they seem to do so as well.\nIs there an argument for an alternative policy? In particular, does someone want to advocate for a specific, implementable transaction ordering policy, based on the pros and cons of that policy vs FCFS?\n\n Thoughts on Arbitrum's Proposal to Score Connections by PoW\n\n 4\n\n 4\n\n read \n\n 7\n min\n\n 23 days later\n\n post by sxysun on Sep 22, 2022\n\n sxysun\n\n TLDR\nWe argue that frequent batch auction-style FCFS should be adopted in order to make the fairness notion more robust and welfare-maximizing (in sense of providing better UX and making the network long-term incentive aligned with the correct parties).\nSpecifically, we suggest that the “fairness granularity,” the interval during which all transactions received by a node are assumed to have happend at the same time, should be set to an interval of at least 500ms (conservative lower bound, will elaborate later).\n\n xOtqNLv.png2222×206 26.1 KB\n Fairness granularity advocation in the original Themis FCFS paper\n\nThis means that instead of reporting a strict ordering (by receive-order time) of transaction, each individual node report a partial ordering to the leader of the ordering consensus protocol. And after aggregating each individual nodes’ preferences, the leader gets a weak ordering (by FCFS) with unordered batches in it (caused by condorcet paradoxes and the initial partial ordering). Now the leader tries to resolve the order of the unordered batch using auctions (e.g., using coinbase.transfer).\nWe use FBA-FCFS (frequent batch auction first come first serve) to refer the the proposed ordering protocol.\nWe show this proposal is better than the original non-FBA version of FCFS in two ways:\n\nmakes the fairness of the ordering more robust (in the sense of network latency tolerance) than the vanilla version, allowing the domain to provide a smoother UX\nmore fair in the sense that it removes the negative externality caused by inefficient resource allocation and increases the welfare (an upper bound on ordering efficiency) of users, thus allowing the domain to attract much more future users (who aren’t visible currently)\n\nWe also address potential concerns of this proposal:\n\nFBA-FCFS incurs negligible latency overhead\nFBA-FCFS validators has no incentive to coarsen the fairness granularity\n\nAssumption\nFirst, we list some assumptions currently made by existing FCFS proposals (note there are no new assumptions):\n\nthe system has a permissioned mempool that is only visible to the validators, and the privacy on top of the permission is trusted at the moment\nanybody is able to submit a transaction, the transaction is assumed to be broadcasted to all the validators at the same time\nthe validators are geo-distribtued well enough\nthere exists some social norms that can, with good enough accuracy and efficiency, slash dishonest validators\nthere exists network latency services that allow VIP agents to broadcast transactions to every validator faster than non-VIP agents, allowing them to be ordered first in vanilla FCFS with decent probability\n\nWe define dishonest as either of the below:\n\nthe validator violating the privacy assumption of the mempool and leaking transaction contents to sophisticated parties who can gain an ex-post knowledge of the transaction sender’s private information before finality.\nthe validator manipulates the ordering of the transactions in a way such that transactions (not in the same batch) received later is placed before transactions received sooner.\n\nWe give some examples of activities that are impacted by ordering rules:\n\nsandwiching: requires the validator to both violate privacy and receive-order honesty\ngeneralized frontrunning: requires the validator to both violate privacy and receive-order honesty\nliquidation/arbitrage/NFT sniping: doesn’t require the validator to violate any honesty assumptions\nmarket making/statistical arbitrage: doesn’t require the validator to violate any honesty assumptions\n\nIt is clearly desirable to eradicate activities 1&2 and democratize activities 3&4.\nRobustness\nFirst, we want the ordering protocol to level the playing field between privileged and unprivileged users (who might have worse network latency). Specifically, with reasonable network latency assumptions, the fairness granularity should never be zero (or else, priviledged users will always win present preference conflicts) to allow for a smooth/fair UX for all users.\nMore importantly, we know that there exists a huge incentive for sophisticated users (i.e., MEV searchers, validators) to manipulate a vanilla FCFS system (violating the receive-order honesty) without incurring much risk.\nThis imposes a great risk to the long-term stability of the protocol because players cannot be trusted to be honest in an environment where they are encouraged to break the honesty assumption with minimal risk: optimal latency and ordering manipulation is always achieved by colocation with validators, which encourages vertical integration between validators and searchers which hurts the overall decentralization of the system.\nOn the contrary, if a FBA-FCFS system is adopted, the validators can be trusted to be honest as all the centralizing/dishonest vectors have been contained in the auction, making the protocol long-term stable (as we all know, only with sufficient honesty/security of a network can the domain gain significant traction of future users). Honesty assumptions and incentive aligenment has to go hand in hand.\nWe observe that from the four examples, 1&2 requires the validator to break both the privacy and receive-order honesty assumption. Thus, to strengthen our ordering protocol, we need either (i) opt-in privacy, through threshold encryption and mechanism similar to cr-list, or, (ii) rely on the social norm slashing mechanism to discover privacy violations (which is assumed in the original vanilla FCFS anyway, and this behavior would be very easily discoverable by any data services, txn scanners, or block builders).\nThis means that with privacy components in the protocol, we can indeed eradicate 1&2 while making the fairness more robust. Of course, the tradeoff here is that in the vanilla version of FCFS, validators can violate the privacy assumption and still won’t be able to conduct activities 1&2 efficiently, while in FBA-FCFS the validators can just violate the privacy guarantees and conduct 1&2 effectively. Note that this tradeoff is mitigated (on top of the two methods mentioned in previous paragraph) because:\n\nas more application layer protocols realize the importance of MEV-resistant design, activities 1&2 will be eradicated at a higher level in the transaction supplychain. Ordering layer is not the best abstraction layer to solve the negative externalities of non-private transaction MEV.\npublic mempools are generally unseriable (as demonstrated by various pre-trade privacy/zk pushes), in future we will see more privacy solutions\n\nFairness\nThe acitivities in case 3&4 constitues a significant portion of all on-chain acitvities. And currently, most on-chain activities are (systematically relevant) DEX activities. In fact, 65%+ of Uniswap volume is from (statistical) arbitrage, and among the other 35% it’s a few big market makers. Thus, it is safe to say that, in majority of the time, there exists a conflict of preference of agents as they all want to capture this permissionless MEV opportunity, i.e., they have common value over the resource of “what the next on-chain state should be.” We breviate this resource to spec-on-state, which means which specification should the next state satisfy (which is sometimes abstracted in the notion of a “blockspace” and its attributes).\n\n ndQJVqO.png1600×792 74.2 KB\n Uniswap V3 Volume is dominated by acitivies 3&4\n\nOur goal, then, should be to minimize the negative externality cause by the allocation of this resource of spec-on-state within burst periods (which occurs extremely often).\nWe observe that vanilla FCFS incurs much more negative externality than FBA-FCFS because sophisticated agents (e.g., MEV searchers) are encouraged to both spam the network and play a latency auction (whose endgame is spinning up multiple searcher bots instances distributed across the network to capture opportunities, which is also spamming). This is primarily caused by the fact that agents in the network have no way of expressing their preference and thus enter a stage of uncoordinated coordination (auction by other means). This means the allocation has many undesirable properties:\n\nthe sequencers/proposers/validators have inherent huge advantages because they can be the first ones to see the transactions and therefore the first to react (also the colocation is perfect so have very low network propagation latency). This implies that they are more likely to collude with sophisticated users and thus creates centralization in sequencers/proposers/validators, which harms geographical decentralization, network security, censorship resistance, and liveness.\n\nthe allocation probably takes the form of an all-pay auction (as in the case of most latency games, where backroom deals are signed/AWS instances are colocated in an uncoordinated manner) which makes the network-wide welfare decrease. And this costs will always be channeled by sophisticated users to unsophisticated users in the form of a less efficient market and worse UX. For example, market makers will charge a larger spread to retail users because they have a higher operating cost, as shown in traditional HFT, or that arbitraguers will not move the price of a pool because it costs them too much to do so, thus forcing users to trade in unfavorable out-dated prices. In the end, the permissionless economic value will be captured by some party, it could be captured by Amazon/Google who are neither incentive aligned with the Arbitrum ecosystem nor the crypto community, or, it could be captured by users.\n\nthe allocation mechanism is inexpressive, in this case, the agents have no mechanism of expressing their preference for activies (which sums up to 90% of the network activity), which means there is huge inefficiencies caused by Price of Anarchy. For example, in spam/randomized ordering auctions, the validators are forced into a more severe transaction quality trilemma, which imposes a direct tax on users. Essentially, the inefficiency, in equilibrium, equals to the amount that normal users are charged (compared with what they would’ve been getting in FBA-FCFS case), driving users away.\n\nusers are inable to have their true preference aggregated (because the mechanism/ordering protocol has only partial information and has no clue of how much money the agents spent on latency optimization), this also means that the MEV is internalized by latency services, whose entire business model is encouraging more MEV extraction and isn’t incentive aligned with Arbitrum in the prosperity of the domain and its long-term value accrue/user acquisition. Not internalizing the auction value to the domain also means that there exists no way of future re-distribution of the value, which has been shown to be damaging to the security of the network.\n\nthe game is not transparent, thus raises the barrier of entry, favoring sophisticated users over ordinary retail users more. This would make activies 3&4 more centralized and therefore the profit to be more centralized.\n\nOn the other hand, if we use a direct allocation mechanism (e.g., using coinbase.transfer) during those burst periods, we circumvente all five disadvantages of vanilla FCFS listed above while still retaining the benifits of low latency fast finality receipts and fairness.\n\n J2aOCk2.png2094×692 113 KB\n the price impact (burst of common value) period duration in forex markets\n\n sBzXzjc.png2026×722 71.8 KB\n the average time between the occurrence of two events (trades or changes at the top of the order book)\n\nBased on data in traditional markets (shown above), we know that the burst period in one pair of assets in the crypto market can be conservatively modeled (lower bound) as coming in every 500ms and lasts around 200ms. And since crypto has many frequently traded pairs with meaningful volume (relative), the price discovery happens much more often.\nIn fact, we found that in aggregation, the burst period on Ethereum takes around 1245ms, and 75.37% of the conflict of preferences happen in 4.115% of the time. For example, the burst period in block 13227081 consists 96.38% of the MEV load while only taking up 3.53% of the block time (640ms). Similarly, the burst period in block 13227483 took 922.5ms: it summed up 91.614% of the MEV within that block during less than 5.6% of the time (the diagram of MEV as a function to time is shown below). This means that if the same situation were to happen on vanilla FCFS, then, compared with FBA-FCFS, we will be bearing the extra negative externalities (e.g., centralization, higher fees, worse execution, etc,.) from 11.92x more conflict of preferences.\n\n ZJFl7Yv.jpg3200×2400 236 KB\n MEV(t), the darker/larger the circle, the more conflicts there are at that moment in time\n\nThis means that the fairness granularity parameter, at least, should be chosen over 500ms. Moreover, if we factor in global delay uncertainties over the Internet, the interval would be larger than 500ms up to a few seconds.\nAs for latency UX concerns, 500ms auctions can be achieved with negligible latency cost to users as Solana has blocktime of 400ms and full block auctions are being conducted. Also, auction need only to happen per public information reveal (i.e., at the start of the block) because that is when the burst period starts.\nNote that the 500ms bound is not fixed, the shorter we make the auction interval (fairness granularity), the fairness guarantee becomes less robust: it is easier for the validators to be malicious without penalty.\nConclusion\nWe presented FBA-FCFS and argued why it maintains the same no-frontrunning guarantee to users, while improving UX and fairness guarantees.\nby Flashbots with love \n\n Time boost: a new transaction ordering policy proposal\n\n Hybrid transaction ordering policy\n\n post by edfelten on Sep 23, 2022\n\n edfelten\n\n Is there a clear description of the FBA-FCFS policy? I think we can infer that it divides time into intervals of length g and orders by bidding within each interval (resolving equal bids by FCFS). Is that right?\n\n post by sxysun on Sep 24, 2022\n\n sxysun\n\n The precise description is same as the one in page 20 and 21 of the Themis paper’s Definition 6.2 of fairness granularity (https://eprint.iacr.org/2021/1465.pdf) except that we resolve the ordering within the interval (or, in general, condorcet cycles) using auctions.\n\n post by edfelten on Sep 25, 2022\n\n edfelten\n\n And how do the auctions work? Do you auction off the right to arbitrarily reorder transactions within the interval? Or do you order transactions within the interval based on the tips they offer? Or something else?\n\n 12 days later\n\n post by sxysun on Oct 7, 2022\n\n sxysun\n\n The intra-chunk ordering can be done in multiple ways.\nThe easiest one is ordering by fees (tip), and break ties as @edfelten suggested using receive-order. This adds negligible overhead for sequencers and will be good for settings where user preferences in burst periods are mostly common value (i.e., preferences are not diverse), which is the case in atomic MEV arbs or liquidations.\nIt is also possible to add more UX features into intra-chunk ordering. For example, the validators could add revert protection for users which reduces spam. Or, they could provide conditional payments like coinbase.transfer in Ethereum that allow users to express more diverse preferences which enable features that are already being explored by application teams building on Arbitrum (e.g., Shell Protocol’s design of a composable transaction/trade batching engine). If those additional UX features are wanted, the sequencers can implement themselves to have the architecture embedded within the sequencing node (with an estimated added end-to-end latency of ~6ms, assuming same transaction load as current Ethereum). If the sequencers don’t want to implement themselves, they can also work with third-party trusted services.\n\n Time boost: a new transaction ordering policy proposal\n\n 10 days later\n\n post by samlaf on Oct 17, 2022\n\n samlaf\n\n @sxysun thank you for the detailed write-up, definitely interesting and along the lines of things I’ve been thinking about lately.\nI’m a bit confused by the discussion in this thread though, and what the goals of both parties are:\n\n@edfelten seems to be looking for a policy for the current state of the arbitrum rollup, with a centralized sequencer\n\n@sxysun proposed a solution which requires a decentralized sequencer\n\n@edfelten can you clarify whether you’re looking for a policy that works for a centralized sequencer, or for a decentralized sequencer.\nAll in all, sounds to me like flashbots starting to shill it’s SUAVE “a turnkey decentralized block builder for rollups” (https://twitter.com/hasufl/status/1580983853824765952?s=20&t=6H_qi4R1GlLMkwAhTzbPww) service and trying to frontrun the arbitrum-chainlink FSS relationship: this promises to be an interesting year.\n@sxysun could you clarify whether the set of FBA-FCFS nodes would be rollup sequencers themselves, or a different set of “keeper” nodes similar to what Chainlink FSS is proposing?\n\n post by edfelten on Oct 18, 2022\n\n edfelten\n\n I’m discussing the issue in the context of centralized sequencing because I think the relevant question–what transaction ordering policy we should seek–is orthogonal to decentralization. Once we know what ordering policy we want, there are good ways to apply that policy in a centralized or decentralized setting.\n\n post by sxysun on Oct 21, 2022\n\n sxysun\n\n agree with @edfelten here the solution is regardless of the sequencer set. It can be a centralized rollup sequencer, or a decentralized set of Arbitrum sequencers themselves.\n\n 4 months later\n\n post by zkstonks on Feb 24, 2023\n\n zkstonks\n\n I’ve posted a thread here about the current discussion on auction formats to minimize load on the sequencer. It is tangentially related to this discussion. Thoughts on Arbitrum's Proposal to Score Connections by PoW\n\n post by NPC on Mar 1, 2023\n\n NPC\n\n here the solution is regardless of the sequencer set. It can be a centralized rollup sequencer, or a decentralized set of Arbitrum sequencers themselves.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Time boost: a new transaction ordering policy proposal\n\n Uncategorized\n\n 34\n\n 9.8k\n\n Sep 2023\n\n FairFlow: Leveraging TimeBoost to Build a Fair and Transparent L2 MEV Economy\n\n Uncategorized\n\n tx-ordering\n\n 0\n\n 448\n\n Apr 2025\n\n Proposed design for Timeboost\n\n Uncategorized\n\n 12\n\n 3.3k\n\n Jun 2024\n\n Shared Sequencing Economics\n\n Uncategorized\n\n 4\n\n 2.8k\n\n Oct 2023\n\n Hybrid transaction ordering policy\n\n Uncategorized\n\n tx-ordering,sequencer\n\n 6\n\n 2.9k\n\n Nov 2022","tokens":4959,"squid":"spider-01","role":"Chain Spider","at":1791348370416,"hash":"2fae64eaeff785689fa18f97773c6d9466f984e9"}
{"url":"https://research.arbitrum.io/t/transaction-ordering-policy/127/14","domain":"research.arbitrum.io","title":"Transaction ordering policy - Uncategorized - Arbitrum Research","text":"Uncategorized\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 Aug 2022\n\n 11 / 11\n\n Mar 2023\n\n Mar 2023\n\n post by edfelten on Aug 30, 2022\n\n edfelten\n\n The Arbitrum sequencer receives transactions from users and publishes an ordered sequence, which serves as input to the execution stage of Arbitrum. Currently the sequencer follows a first-come, first-served (FCFS) sequencing policy.\nThere’s a lot to like about FCFS. It’s simple and easy to explain. It is seems intuitively fair. It minimizes latency because the policy allows each transaction to be appended to the sequence immediately on arrival.\nOther rollup protocols use FCFS as well. Optimism does, and based on descriptions of other systems they seem to do so as well.\nIs there an argument for an alternative policy? In particular, does someone want to advocate for a specific, implementable transaction ordering policy, based on the pros and cons of that policy vs FCFS?\n\n Thoughts on Arbitrum's Proposal to Score Connections by PoW\n\n 4\n\n 4\n\n read \n\n 7\n min\n\n 23 days later\n\n post by sxysun on Sep 22, 2022\n\n sxysun\n\n TLDR\nWe argue that frequent batch auction-style FCFS should be adopted in order to make the fairness notion more robust and welfare-maximizing (in sense of providing better UX and making the network long-term incentive aligned with the correct parties).\nSpecifically, we suggest that the “fairness granularity,” the interval during which all transactions received by a node are assumed to have happend at the same time, should be set to an interval of at least 500ms (conservative lower bound, will elaborate later).\n\n xOtqNLv.png2222×206 26.1 KB\n Fairness granularity advocation in the original Themis FCFS paper\n\nThis means that instead of reporting a strict ordering (by receive-order time) of transaction, each individual node report a partial ordering to the leader of the ordering consensus protocol. And after aggregating each individual nodes’ preferences, the leader gets a weak ordering (by FCFS) with unordered batches in it (caused by condorcet paradoxes and the initial partial ordering). Now the leader tries to resolve the order of the unordered batch using auctions (e.g., using coinbase.transfer).\nWe use FBA-FCFS (frequent batch auction first come first serve) to refer the the proposed ordering protocol.\nWe show this proposal is better than the original non-FBA version of FCFS in two ways:\n\nmakes the fairness of the ordering more robust (in the sense of network latency tolerance) than the vanilla version, allowing the domain to provide a smoother UX\nmore fair in the sense that it removes the negative externality caused by inefficient resource allocation and increases the welfare (an upper bound on ordering efficiency) of users, thus allowing the domain to attract much more future users (who aren’t visible currently)\n\nWe also address potential concerns of this proposal:\n\nFBA-FCFS incurs negligible latency overhead\nFBA-FCFS validators has no incentive to coarsen the fairness granularity\n\nAssumption\nFirst, we list some assumptions currently made by existing FCFS proposals (note there are no new assumptions):\n\nthe system has a permissioned mempool that is only visible to the validators, and the privacy on top of the permission is trusted at the moment\nanybody is able to submit a transaction, the transaction is assumed to be broadcasted to all the validators at the same time\nthe validators are geo-distribtued well enough\nthere exists some social norms that can, with good enough accuracy and efficiency, slash dishonest validators\nthere exists network latency services that allow VIP agents to broadcast transactions to every validator faster than non-VIP agents, allowing them to be ordered first in vanilla FCFS with decent probability\n\nWe define dishonest as either of the below:\n\nthe validator violating the privacy assumption of the mempool and leaking transaction contents to sophisticated parties who can gain an ex-post knowledge of the transaction sender’s private information before finality.\nthe validator manipulates the ordering of the transactions in a way such that transactions (not in the same batch) received later is placed before transactions received sooner.\n\nWe give some examples of activities that are impacted by ordering rules:\n\nsandwiching: requires the validator to both violate privacy and receive-order honesty\ngeneralized frontrunning: requires the validator to both violate privacy and receive-order honesty\nliquidation/arbitrage/NFT sniping: doesn’t require the validator to violate any honesty assumptions\nmarket making/statistical arbitrage: doesn’t require the validator to violate any honesty assumptions\n\nIt is clearly desirable to eradicate activities 1&2 and democratize activities 3&4.\nRobustness\nFirst, we want the ordering protocol to level the playing field between privileged and unprivileged users (who might have worse network latency). Specifically, with reasonable network latency assumptions, the fairness granularity should never be zero (or else, priviledged users will always win present preference conflicts) to allow for a smooth/fair UX for all users.\nMore importantly, we know that there exists a huge incentive for sophisticated users (i.e., MEV searchers, validators) to manipulate a vanilla FCFS system (violating the receive-order honesty) without incurring much risk.\nThis imposes a great risk to the long-term stability of the protocol because players cannot be trusted to be honest in an environment where they are encouraged to break the honesty assumption with minimal risk: optimal latency and ordering manipulation is always achieved by colocation with validators, which encourages vertical integration between validators and searchers which hurts the overall decentralization of the system.\nOn the contrary, if a FBA-FCFS system is adopted, the validators can be trusted to be honest as all the centralizing/dishonest vectors have been contained in the auction, making the protocol long-term stable (as we all know, only with sufficient honesty/security of a network can the domain gain significant traction of future users). Honesty assumptions and incentive aligenment has to go hand in hand.\nWe observe that from the four examples, 1&2 requires the validator to break both the privacy and receive-order honesty assumption. Thus, to strengthen our ordering protocol, we need either (i) opt-in privacy, through threshold encryption and mechanism similar to cr-list, or, (ii) rely on the social norm slashing mechanism to discover privacy violations (which is assumed in the original vanilla FCFS anyway, and this behavior would be very easily discoverable by any data services, txn scanners, or block builders).\nThis means that with privacy components in the protocol, we can indeed eradicate 1&2 while making the fairness more robust. Of course, the tradeoff here is that in the vanilla version of FCFS, validators can violate the privacy assumption and still won’t be able to conduct activities 1&2 efficiently, while in FBA-FCFS the validators can just violate the privacy guarantees and conduct 1&2 effectively. Note that this tradeoff is mitigated (on top of the two methods mentioned in previous paragraph) because:\n\nas more application layer protocols realize the importance of MEV-resistant design, activities 1&2 will be eradicated at a higher level in the transaction supplychain. Ordering layer is not the best abstraction layer to solve the negative externalities of non-private transaction MEV.\npublic mempools are generally unseriable (as demonstrated by various pre-trade privacy/zk pushes), in future we will see more privacy solutions\n\nFairness\nThe acitivities in case 3&4 constitues a significant portion of all on-chain acitvities. And currently, most on-chain activities are (systematically relevant) DEX activities. In fact, 65%+ of Uniswap volume is from (statistical) arbitrage, and among the other 35% it’s a few big market makers. Thus, it is safe to say that, in majority of the time, there exists a conflict of preference of agents as they all want to capture this permissionless MEV opportunity, i.e., they have common value over the resource of “what the next on-chain state should be.” We breviate this resource to spec-on-state, which means which specification should the next state satisfy (which is sometimes abstracted in the notion of a “blockspace” and its attributes).\n\n ndQJVqO.png1600×792 74.2 KB\n Uniswap V3 Volume is dominated by acitivies 3&4\n\nOur goal, then, should be to minimize the negative externality cause by the allocation of this resource of spec-on-state within burst periods (which occurs extremely often).\nWe observe that vanilla FCFS incurs much more negative externality than FBA-FCFS because sophisticated agents (e.g., MEV searchers) are encouraged to both spam the network and play a latency auction (whose endgame is spinning up multiple searcher bots instances distributed across the network to capture opportunities, which is also spamming). This is primarily caused by the fact that agents in the network have no way of expressing their preference and thus enter a stage of uncoordinated coordination (auction by other means). This means the allocation has many undesirable properties:\n\nthe sequencers/proposers/validators have inherent huge advantages because they can be the first ones to see the transactions and therefore the first to react (also the colocation is perfect so have very low network propagation latency). This implies that they are more likely to collude with sophisticated users and thus creates centralization in sequencers/proposers/validators, which harms geographical decentralization, network security, censorship resistance, and liveness.\n\nthe allocation probably takes the form of an all-pay auction (as in the case of most latency games, where backroom deals are signed/AWS instances are colocated in an uncoordinated manner) which makes the network-wide welfare decrease. And this costs will always be channeled by sophisticated users to unsophisticated users in the form of a less efficient market and worse UX. For example, market makers will charge a larger spread to retail users because they have a higher operating cost, as shown in traditional HFT, or that arbitraguers will not move the price of a pool because it costs them too much to do so, thus forcing users to trade in unfavorable out-dated prices. In the end, the permissionless economic value will be captured by some party, it could be captured by Amazon/Google who are neither incentive aligned with the Arbitrum ecosystem nor the crypto community, or, it could be captured by users.\n\nthe allocation mechanism is inexpressive, in this case, the agents have no mechanism of expressing their preference for activies (which sums up to 90% of the network activity), which means there is huge inefficiencies caused by Price of Anarchy. For example, in spam/randomized ordering auctions, the validators are forced into a more severe transaction quality trilemma, which imposes a direct tax on users. Essentially, the inefficiency, in equilibrium, equals to the amount that normal users are charged (compared with what they would’ve been getting in FBA-FCFS case), driving users away.\n\nusers are inable to have their true preference aggregated (because the mechanism/ordering protocol has only partial information and has no clue of how much money the agents spent on latency optimization), this also means that the MEV is internalized by latency services, whose entire business model is encouraging more MEV extraction and isn’t incentive aligned with Arbitrum in the prosperity of the domain and its long-term value accrue/user acquisition. Not internalizing the auction value to the domain also means that there exists no way of future re-distribution of the value, which has been shown to be damaging to the security of the network.\n\nthe game is not transparent, thus raises the barrier of entry, favoring sophisticated users over ordinary retail users more. This would make activies 3&4 more centralized and therefore the profit to be more centralized.\n\nOn the other hand, if we use a direct allocation mechanism (e.g., using coinbase.transfer) during those burst periods, we circumvente all five disadvantages of vanilla FCFS listed above while still retaining the benifits of low latency fast finality receipts and fairness.\n\n J2aOCk2.png2094×692 113 KB\n the price impact (burst of common value) period duration in forex markets\n\n sBzXzjc.png2026×722 71.8 KB\n the average time between the occurrence of two events (trades or changes at the top of the order book)\n\nBased on data in traditional markets (shown above), we know that the burst period in one pair of assets in the crypto market can be conservatively modeled (lower bound) as coming in every 500ms and lasts around 200ms. And since crypto has many frequently traded pairs with meaningful volume (relative), the price discovery happens much more often.\nIn fact, we found that in aggregation, the burst period on Ethereum takes around 1245ms, and 75.37% of the conflict of preferences happen in 4.115% of the time. For example, the burst period in block 13227081 consists 96.38% of the MEV load while only taking up 3.53% of the block time (640ms). Similarly, the burst period in block 13227483 took 922.5ms: it summed up 91.614% of the MEV within that block during less than 5.6% of the time (the diagram of MEV as a function to time is shown below). This means that if the same situation were to happen on vanilla FCFS, then, compared with FBA-FCFS, we will be bearing the extra negative externalities (e.g., centralization, higher fees, worse execution, etc,.) from 11.92x more conflict of preferences.\n\n ZJFl7Yv.jpg3200×2400 236 KB\n MEV(t), the darker/larger the circle, the more conflicts there are at that moment in time\n\nThis means that the fairness granularity parameter, at least, should be chosen over 500ms. Moreover, if we factor in global delay uncertainties over the Internet, the interval would be larger than 500ms up to a few seconds.\nAs for latency UX concerns, 500ms auctions can be achieved with negligible latency cost to users as Solana has blocktime of 400ms and full block auctions are being conducted. Also, auction need only to happen per public information reveal (i.e., at the start of the block) because that is when the burst period starts.\nNote that the 500ms bound is not fixed, the shorter we make the auction interval (fairness granularity), the fairness guarantee becomes less robust: it is easier for the validators to be malicious without penalty.\nConclusion\nWe presented FBA-FCFS and argued why it maintains the same no-frontrunning guarantee to users, while improving UX and fairness guarantees.\nby Flashbots with love \n\n Time boost: a new transaction ordering policy proposal\n\n Hybrid transaction ordering policy\n\n post by edfelten on Sep 23, 2022\n\n edfelten\n\n Is there a clear description of the FBA-FCFS policy? I think we can infer that it divides time into intervals of length g and orders by bidding within each interval (resolving equal bids by FCFS). Is that right?\n\n post by sxysun on Sep 24, 2022\n\n sxysun\n\n The precise description is same as the one in page 20 and 21 of the Themis paper’s Definition 6.2 of fairness granularity (https://eprint.iacr.org/2021/1465.pdf) except that we resolve the ordering within the interval (or, in general, condorcet cycles) using auctions.\n\n post by edfelten on Sep 25, 2022\n\n edfelten\n\n And how do the auctions work? Do you auction off the right to arbitrarily reorder transactions within the interval? Or do you order transactions within the interval based on the tips they offer? Or something else?\n\n 12 days later\n\n post by sxysun on Oct 7, 2022\n\n sxysun\n\n The intra-chunk ordering can be done in multiple ways.\nThe easiest one is ordering by fees (tip), and break ties as @edfelten suggested using receive-order. This adds negligible overhead for sequencers and will be good for settings where user preferences in burst periods are mostly common value (i.e., preferences are not diverse), which is the case in atomic MEV arbs or liquidations.\nIt is also possible to add more UX features into intra-chunk ordering. For example, the validators could add revert protection for users which reduces spam. Or, they could provide conditional payments like coinbase.transfer in Ethereum that allow users to express more diverse preferences which enable features that are already being explored by application teams building on Arbitrum (e.g., Shell Protocol’s design of a composable transaction/trade batching engine). If those additional UX features are wanted, the sequencers can implement themselves to have the architecture embedded within the sequencing node (with an estimated added end-to-end latency of ~6ms, assuming same transaction load as current Ethereum). If the sequencers don’t want to implement themselves, they can also work with third-party trusted services.\n\n Time boost: a new transaction ordering policy proposal\n\n 10 days later\n\n post by samlaf on Oct 17, 2022\n\n samlaf\n\n @sxysun thank you for the detailed write-up, definitely interesting and along the lines of things I’ve been thinking about lately.\nI’m a bit confused by the discussion in this thread though, and what the goals of both parties are:\n\n@edfelten seems to be looking for a policy for the current state of the arbitrum rollup, with a centralized sequencer\n\n@sxysun proposed a solution which requires a decentralized sequencer\n\n@edfelten can you clarify whether you’re looking for a policy that works for a centralized sequencer, or for a decentralized sequencer.\nAll in all, sounds to me like flashbots starting to shill it’s SUAVE “a turnkey decentralized block builder for rollups” (https://twitter.com/hasufl/status/1580983853824765952?s=20&t=6H_qi4R1GlLMkwAhTzbPww) service and trying to frontrun the arbitrum-chainlink FSS relationship: this promises to be an interesting year.\n@sxysun could you clarify whether the set of FBA-FCFS nodes would be rollup sequencers themselves, or a different set of “keeper” nodes similar to what Chainlink FSS is proposing?\n\n post by edfelten on Oct 18, 2022\n\n edfelten\n\n I’m discussing the issue in the context of centralized sequencing because I think the relevant question–what transaction ordering policy we should seek–is orthogonal to decentralization. Once we know what ordering policy we want, there are good ways to apply that policy in a centralized or decentralized setting.\n\n post by sxysun on Oct 21, 2022\n\n sxysun\n\n agree with @edfelten here the solution is regardless of the sequencer set. It can be a centralized rollup sequencer, or a decentralized set of Arbitrum sequencers themselves.\n\n 4 months later\n\n post by zkstonks on Feb 24, 2023\n\n zkstonks\n\n I’ve posted a thread here about the current discussion on auction formats to minimize load on the sequencer. It is tangentially related to this discussion. Thoughts on Arbitrum's Proposal to Score Connections by PoW\n\n post by NPC on Mar 1, 2023\n\n NPC\n\n here the solution is regardless of the sequencer set. It can be a centralized rollup sequencer, or a decentralized set of Arbitrum sequencers themselves.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Time boost: a new transaction ordering policy proposal\n\n Uncategorized\n\n 34\n\n 9.8k\n\n Sep 2023\n\n FairFlow: Leveraging TimeBoost to Build a Fair and Transparent L2 MEV Economy\n\n Uncategorized\n\n tx-ordering\n\n 0\n\n 448\n\n Apr 2025\n\n Proposed design for Timeboost\n\n Uncategorized\n\n 12\n\n 3.3k\n\n Jun 2024\n\n Shared Sequencing Economics\n\n Uncategorized\n\n 4\n\n 2.8k\n\n Oct 2023\n\n Hybrid transaction ordering policy\n\n Uncategorized\n\n tx-ordering,sequencer\n\n 6\n\n 2.9k\n\n Nov 2022","tokens":4951,"squid":"spider-01","role":"Chain Spider","at":1791348380546,"hash":"4dcd0dcb230081933f430d68fb5f98b5d46a02bc"}
{"url":"https://akash.network/docs/node-operators/validators/running-a-validator","domain":"akash.network","title":"Running a Validator | Akash Network - Your Guide to Decentralized Cloud","text":"Running a Validator This guide shows how to create and manage an Akash validator on mainnet.\nTime: 30-45 minutes\nThe examples load chain ID and a default RPC URL from mainnet meta.json using curl and jq (same metadata as CLI node setup).\n\nPrerequisites\nBefore creating a validator, ensure you have:\n0. CLI tools\nFor the environment commands below, install curl and jq (e.g. apt install jq on Ubuntu).\n1. Full Node Running\nYour node must be fully synced before creating a validator.\n\nSee Node Build Guides\nVerify sync status: akash status | jq '.sync_info.catching_up'\nShould return false when fully synced\n\n2. Hardware Requirements\n\nCPU: 8 cores (16 cores recommended)\nMemory: 128 GB required\nStorage: 512 GB SSD/NVMe (1 TB+ recommended)\nNetwork: 100 Mbps+\nUptime: 99.9%+ to avoid slashing\n\n3. Akash Wallet with Sufficient AKT\n\nMinimum: 2 AKT required (1 AKT for self-delegation + 1 AKT for fees)\nRecommended: 10,000+ AKT to be competitive in the active set\n\nCreate a wallet:\nTerminal windowakash keys add <key-name>\nFund your wallet via exchange or Keplr.\n4. Understand Active Validator Set\n\nActive Set Size: 100 validators\nEntry Requirement: More voting power than the 100th validator\nCheck Requirements: Use $votingpower in Discord #validator-alerts channel\n\nStep 1 - Set Environment Variables\nChain ID and a default public RPC URL come from mainnet meta.json. Override AKASH_META_URL for another network’s meta.json if needed.\nTerminal window# Network configuration (meta.json is the single source for chain ID + API endpoints)export AKASH_META_URL=\"${AKASH_META_URL:-https://raw.githubusercontent.com/akash-network/net/main/mainnet/meta.json}\"export AKASH_CHAIN_ID=\"$(curl -sSf \"$AKASH_META_URL\" | jq -r '.chain_id')\"export AKASH_NODE=\"$(curl -sSf \"$AKASH_META_URL\" | jq -r '.apis.rpc[0].address')\"\n# Your configurationexport AKASH_KEY_NAME=\"<your-key-name>\"export AKASH_MONIKER=\"<your-validator-name>\"\nReplace:\n\n<your-key-name> - Name of your wallet key\n<your-validator-name> - Public name for your validator\n\nStep 2 - Get Your Validator Public Key\nTerminal windowakash tendermint show-validator\nExpected output:\n{\"@type\":\"/cosmos.crypto.ed25519.PubKey\",\"key\":\"...\"}\nImportant: The private key for this validator lives in ~/.akash/config/priv_validator_key.json. Back up this file securely.\n\nStep 3 - Create Your Validator\nUnderstand Commission Parameters\nBefore creating your validator, understand commission structure:\ncommission-rate (e.g., \"0.10\" = 10%)\n\nYour commission on delegator rewards\nTypical range: 5-10%\n\ncommission-max-rate (e.g., \"0.20\" = 20%)\n\nMaximum commission you can ever charge\nCannot be changed after validator creation\n\ncommission-max-change-rate (e.g., \"0.01\" = 1%)\n\nMaximum % point change per day\nExample: 10% → 11% = 1 percentage point change\nPrevents sudden commission spikes\n\nmin-self-delegation (e.g., \"1\")\n\nMinimum self-delegated AKT (in uakt)\n\"1\" = minimum 1 uakt self-delegation\n\nCreate Validator JSON File\nCreate a file named validator.json:\n{ \"pubkey\": {\"@type\":\"/cosmos.crypto.ed25519.PubKey\",\"key\":\"YOUR_VALIDATOR_PUBKEY_HERE\"}, \"amount\": \"1000000uakt\", \"moniker\": \"your-moniker\", \"identity\": \"\", \"website\": \"\", \"security\": \"\", \"details\": \"\", \"commission-rate\": \"0.10\", \"commission-max-rate\": \"0.20\", \"commission-max-change-rate\": \"0.01\", \"min-self-delegation\": \"1\"}\nPopulate the JSON File Automatically\nYou can automatically populate the pubkey field by running:\nTerminal windowPUBKEY=$(akash tendermint show-validator)\ncat > validator.json <<EOF{ \"pubkey\": $PUBKEY, \"amount\": \"1000000uakt\", \"moniker\": \"$AKASH_MONIKER\", \"identity\": \"\", \"website\": \"\", \"security\": \"\", \"details\": \"\", \"commission-rate\": \"0.10\", \"commission-max-rate\": \"0.20\", \"commission-max-change-rate\": \"0.01\", \"min-self-delegation\": \"1\"}EOF\nCustomize the values:\n\namount: Amount to stake (1000000uakt = 1 AKT)\nmoniker: Your validator name\nidentity: Your Keybase 16-digit ID (optional, for logo)\nwebsite: Your validator website (optional)\nsecurity: Security contact email (optional)\ndetails: Description of your validator (optional)\ncommission-rate: Your commission (0.10 = 10%)\ncommission-max-rate: Maximum commission (cannot change after creation)\ncommission-max-change-rate: Max change per day (0.01 = 1 percentage point)\nmin-self-delegation: Minimum self-delegation (1 = 1 uakt)\n\nSubmit the Create Validator Transaction\nNow submit the validator creation transaction using the JSON file:\nTerminal windowakash tx staking create-validator validator.json \\ --chain-id=\"$AKASH_CHAIN_ID\" \\ --gas=\"auto\" \\ --gas-prices=\"0.025uakt\" \\ --gas-adjustment=1.5 \\ --from=\"$AKASH_KEY_NAME\"\nWhat this does:\n\nStakes 1 AKT (1000000 uakt) from your wallet\nCreates validator with your specified parameters\nRegisters your validator on the blockchain\n\nSave your validator address from the output:\nakashvaloper1...\n\nTip: When specifying commission parameters, the commission-max-change-rate is used to measure % point change over the commission-rate. E.g. 1% to 2% is a 100% rate increase, but only 1 percentage point.\n\nTip: min-self-delegation is a strictly positive integer that represents the minimum amount of self-delegated voting power your validator must always have. A min-self-delegation of 1 means your validator will never have a self-delegation lower than 1 uakt.\n\nStep 4 - Edit Validator Profile (Optional)\nAdd description, website, and logo to your validator profile.\nGet Keybase Identity (for logo)\n\nCreate account at keybase.io\nUpload your validator logo (recommended: 256x256px)\nGet your 16-digit Keybase ID\n\nUpdate Validator Profile\nTerminal windowakash tx staking edit-validator \\ --new-moniker=\"My Validator\" \\ --website=\"https://myvalidator.com\" \\ --identity=<your-16-digit-keybase-id> \\ --details=\"Professional Akash validator | 99.9% uptime\" \\ --security-contact=\"security@myvalidator.com\" \\ --chain-id=\"$AKASH_CHAIN_ID\" \\ --gas=\"auto\" \\ --gas-prices=\"0.025uakt\" \\ --gas-adjustment=1.5 \\ --from=\"$AKASH_KEY_NAME\"\nUpdate Commission Rate (Optional)\nYou can change your commission rate once per day within your commission-max-change-rate.\nTerminal windowakash tx staking edit-validator \\ --commission-rate=\"0.08\" \\ --chain-id=\"$AKASH_CHAIN_ID\" \\ --gas=\"auto\" \\ --gas-prices=\"0.025uakt\" \\ --gas-adjustment=1.5 \\ --from=\"$AKASH_KEY_NAME\"\nRestrictions:\n\nMust be between 0 and commission-max-rate\nCannot change more than commission-max-change-rate per day\nExample: If commission-max-change-rate=0.01, you can only change by 1% point per day\n\nVerify Your Validator\nCheck Validator Status\nTerminal windowexport AKASH_VALIDATOR_ADDRESS=\"akashvaloper1...\"\nakash query staking validator $AKASH_VALIDATOR_ADDRESS\nExpected output:\ncommission: commission_rates: rate: \"0.100000000000000000\" max_rate: \"0.200000000000000000\" max_change_rate: \"0.010000000000000000\" update_time: \"2024-01-15T10:30:00Z\"description: moniker: My Validator website: https://myvalidator.com details: Professional Akash validatorjailed: falsestatus: BOND_STATUS_BONDED # or BOND_STATUS_UNBONDEDtokens: \"1000000\"\nStatus meanings:\n\nBOND_STATUS_BONDED - Active in validator set\nBOND_STATUS_UNBONDED - Not in top 100 (need more stake)\nBOND_STATUS_UNBONDING - Exiting validator set\n\nCheck if in Active Set\nTerminal windowakash query tendermint-validator-set | grep \"$(akash tendermint show-validator)\"\nIf output is empty: Your validator is not in the active set (top 100). You need more voting power.\nCheck Node Sync Status\nTerminal windowakash status | jq '.sync_info'\nImportant fields:\n\ncatching_up: false - Node is synced\nlatest_block_height - Current block (compare with explorer)\n\nValidator Operations\nView Signing Information\nTrack your validator’s signing performance:\nTerminal windowakash query slashing signing-info \\ $(akash tendermint show-validator) \\ --chain-id=\"$AKASH_CHAIN_ID\"\nOutput shows:\n\nMissed blocks\nJailed status\nTombstone status (permanent jail)\n\nUnjail Validator\nIf your validator was jailed for downtime:\nPrerequisites:\n\nYour node must be fully synced\nWait at least 10 minutes after downtime period\n\nTerminal windowakash tx slashing unjail \\ --from=\"$AKASH_KEY_NAME\" \\ --chain-id=\"$AKASH_CHAIN_ID\" \\ --gas=\"auto\" \\ --gas-prices=\"0.025uakt\" \\ --gas-adjustment=1.5\nNote: You cannot unjail if you were tombstoned (double-sign). That’s permanent.\nHalt Validator for Maintenance\nTo gracefully stop your validator at a specific block height:\nTerminal window# Edit config.toml or use flagakash start --halt-height=12345678\nThe node will stop at block 12345678 with exit code 0.\n\nMonitoring Your Validator\nCheck Validator on Explorer\nView your validator on a block explorer:\n\nMintscan\nATOMScan\nArcturian Explorer\n\nSearch for your akashvaloper address or moniker.\nMonitor Uptime\nCritical: Validators must sign >95% of blocks to avoid jailing.\nMissed block threshold: 500 out of 10,000 blocks (~5%)\nSet up monitoring with:\n\nPANIC by Simply VC\nTenderduty\n\nCheck Voting Power\nTerminal windowakash query staking validator $AKASH_VALIDATOR_ADDRESS | grep \"tokens\"\nTo increase voting power:\n\nSelf-delegate more AKT\nAttract delegators through marketing\nMaintain high uptime and commission\n\nTroubleshooting\nValidator Has Zero Voting Power\nCause: Your validator was jailed for downtime or double-signing.\nSolution:\n\nCheck if jailed:\n\nTerminal windowakash query staking validator $AKASH_VALIDATOR_ADDRESS | grep \"jailed\"\n\nIf jailed for downtime:\n\nEnsure node is synced and running\nWait 10+ minutes\nUnjail your validator\n\nIf tombstoned (double-sign):\n\nCannot recover - this is permanent\nYou must create a new validator with a new key\n\nValidator Not in Active Set\nCause: Your voting power is less than the 100th validator.\nSolution:\nCheck current requirements:\nTerminal window# In Discord #validator-alerts$votingpower\nTo join active set:\n\nSelf-delegate more AKT\nAttract delegators\nLower commission (temporarily)\n\nNode Crashes: “Too Many Open Files”\nCause: Linux default file descriptor limit (1024) is too low.\nSolution:\nTerminal window# Temporary fixulimit -n 4096systemctl restart akash-node\n# Permanent fix (add to /etc/security/limits.conf)* soft nofile 65536* hard nofile 65536\nRestart your session for permanent fix to take effect.\nNode Out of Sync\nSymptoms: catching_up: true persists\nSolution:\n\nCheck peers:\n\nTerminal windowakash status | jq '.node_info.other.peers'\n\nAdd more peers in ~/.akash/config/config.toml:\n\nGet peers from:\n\nPolkachu Peers\nAkash net repo — meta.json (persistent_peers)\n\nRestart node:\n\nTerminal windowsystemctl restart akash-node\nCommission Change Rejected\nError: commission cannot be changed more than max change rate\nCause: Trying to change commission by more than commission-max-change-rate in 24 hours.\nSolution: Wait 24 hours between commission changes, or make smaller incremental changes.\n\nSecurity Best Practices\n\nBackup Private Key\n\nFile: ~/.akash/config/priv_validator_key.json\nStore offline in multiple secure locations\nNever share this key\n\nUse Sentry Nodes\n\nHide validator behind sentry nodes\nSee Sentry Node Architecture\n\nEnable Firewall\n\nOnly allow necessary ports\nRestrict SSH access\n\nConsider TMKMS\n\nHardware Security Module (HSM) integration\nSee TMKMS Guide\n\nMonitor 24/7\n\nSet up alerting for downtime\nMonitor disk space\nTrack signing performance\n\nNext Steps\n\nCommunity: Join #validators on Discord\nAdvanced: Set up TMKMS\nAlternative: Try Validator via Omnibus\n\nQuestions? Join #validators on Discord \nEdit page on github\n Omnibus Omnibus","tokens":2841,"squid":"spider-03","role":"Compute Spider","at":1791348384131,"hash":"50e153b54b1279e2863d5fc33440e9b93e23265d"}
{"url":"https://akash.network/docs/node-operators/node-build","domain":"akash.network","title":"Node Build | Akash Network - Your Guide to Decentralized Cloud","text":"Node Build Deploy an Akash RPC node using one of three methods: CLI build, Helm chart (Kubernetes), or Omnibus (on Akash Network).\nWhy run an Akash node?\n\nRequired for validators\nRecommended for providers (lower latency)\nBest practice for production dApps (no reliance on public nodes)\n\nNetwork metadata (meta.json)\nPublished networks in the akash-network/net repo expose a single meta.json per network (for example mainnet/meta.json). It is the source of truth for chain ID, genesis URL, seed and persistent peer node_id@host:port entries, and public RPC / REST / gRPC endpoints.\nThe CLI build guide uses curl and jq to read this file. Omnibus and Helm examples that set CHAIN_JSON to the same URL use the equivalent data for containerized nodes.\n\nDeployment Methods\nCLI Build\nManual installation on a Linux server.\nTime: 15-30 minutes (setup) + sync time\nRequirements:\n\nUbuntu 24.04 LTS\n4 CPU cores\n8 GB RAM\n100 GB SSD storage (minimum), 1 TB recommended\nRoot access\n\nUse when:\n\nYou want full control over the node configuration\nRunning on bare metal or VPS\nLearning node operations from scratch\n\nHelm Chart\nDeploy to an existing Kubernetes cluster via Helm.\nTime: 5-10 minutes\nRequirements:\n\nExisting Kubernetes cluster\nHelm 4.0+\nkubectl access\n100 GB storage (minimum), 1 TB recommended\n\nUse when:\n\nYou already have a Kubernetes cluster\nYou want quick deployment with blockchain snapshots\nYou need to manage multiple nodes\n\nOmnibus\nDeploy on Akash Network using a pre-built SDL.\nTime: 5-10 minutes (deployment) + 20-30 minutes (sync via hourly snapshot)\nRequirements:\n\nAkash wallet with ~2 AKT\nAkash Console or CLI access\n\nUse when:\n\nYou want to run a node on Akash’s network\nTesting or learning Akash deployments\nYou don’t have dedicated infrastructure\n\nAfter Deployment\nOnce your node is running:\n\nVerify sync status - Check if catching_up: false\nCheck peer connections - Ensure connected to seed/peer nodes\nMonitor block height - Compare with Mintscan\nEnable services - Configure RPC/API if needed\n\nFor validators, see Running a Validator.\n\nQuestions? Join #validators on Discord \nEdit page on github\n Getting Started CLI Build","tokens":534,"squid":"spider-03","role":"Compute Spider","at":1791348395047,"hash":"ea007d03148a44e84f0180d168c2848370805d69"}
{"url":"https://research.arbitrum.io/t/thoughts-on-arbitrums-proposal-to-score-connections-by-pow/8121","domain":"research.arbitrum.io","title":"Thoughts on Arbitrum's Proposal to Score Connections by PoW - Uncategorized - Arbitrum Research","text":"Thoughts on Arbitrum’s Proposal to Score Connections by PoW \n\n Uncategorized\n\n gas-and-fees,tx-ordering,sequencer,nitro\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Feb 2023\n\n 1 / 2\n\n Feb 2023\n\n Mar 2023\n\n post by zkstonks on Feb 24, 2023\n\n zkstonks\n\n Offchain Labs is developing a proof-of-work mechanism to disincentivize massive sybil attacks by MEV searchers on the Arbitrum sequencer. In this post, I describe issues with the proposed mechanism and suggest alternative mechanisms that more efficiently achieve the goals of the proposal.\nIntroduction to PR 1504\nSkip this section if you are already familiar with the proposal.\nYesterday, February 23, Arbitrum core devs published Pull Request 1504, titled “Add a relay client connection nonce.”\nIn the Flashbots discord, PlasmaPower stated that the intention of the mechanism is “to stop incentivizing tons of connections to our feed.” Ben Burgess stated that the relay currently serves between 100,000-150,000 [1] connections at a time.\nThe proposal implements a change such that, when a new block is available, the relay will first deliver it to the 25 feed subscribers with the lowest “nonce.” [2] After an artificial 50 millisecond delay, the relay will deliver the block to all other subscribers. The idea is that, to minimize latency, searchers will no longer have an incentive to sybil attack the relay. Instead, they will spend tens of thousand of dollars, daily, on GPUs and electricity for mining low nonces. By my rough estimate, MEV searchers on Arbitrum currently profit roughly $5-20 million annually.\nContext\nCurrently, MEV searchers open thousands of concurrent subscriptions to the Arbitrum Sequencer Relay’s WebSocket feed. They may even do so from numerous IPs to evade rate limiting. The current system incentivizes searchers to do so because messages are propagated to subscribers sequentially and, importantly, in random order.\nSolution Guidelines\nWhile avoiding turning this into a formal mechanism design problem, we can surmise some general guidelines:\n\nThe mechanism should reasonably minimize the load on the sequencer.\nThe mechanism should be easy to implement, while a more sophisticated longer-term auction design is considered. See Footnote [3] below.\nImposing an artificial delay on a subset of connections (i.e. non-searchers) is acceptable.\nWe do not want to affect the FIFO nature of the sequencer, as this opens a can of worms.\n\nI also assume (and hope) that, if the alternative is spending millions of dollars annually on GPUs and electricity, all stakeholders would prefer to direct these funds to a charity or the Arbitrum ecosystem.\nFor environment and reputational reasons, I assume that we prefer to avoid PoW mechanisms, if possible.\nIssues\nThere are several critical issues with the proposed solution and obviously better alternatives.\nThe primary issue is how economically wasteful this mechanism is.\nMEV searchers on Arbitrum currently profit roughly $5-20 million annually. The current proposal would have a large portion of these funds spent on mining proof-of-work hashes.\n\nA simple auction design could instead direct these funds to a charity or the Arbitrum ecosystem.\nLess importantly, MEV searchers’ time is now spent on optimizing PoW algorithms instead of… other things? Such as increasing profits to donate even more to charity or the Arbitrum ecosystem.\n\nAs mentioned above, PR 1504 is also quite harmful to the environment. Pathos aside, it is (subjectively) not in the interest of Arbitrum’s ecosystem to associate themselves with promoting PoW.\nAlternative Mechanism Designs\nSuggestions for alternative auction designs that are more economically efficient and satisfy the previously discussed constraints, especially simplicity of implementation and FIFO ordering.\n\nPay X ETH to some address be in the priority queue for 24 hours. Very simple to implement. There’s still an incentive to open multiple connections, but it’s not cheap to do so. X can be adjusted daily. Subscriptions to the feed can optionally contain a header with an ECDSA signature from an EOA that has paid in the past 24 hours.\n\nSearchers submit blind bids before Sunday 12:00 UTC to an email address, web form, or smart contract. Top 5 bidders pay the 6th’s bid. Give the winning bidders API keys or have them authenticate via ECDSA signatures. This is extremely simple to implement. Credit to @snoopy_mev on twitter.\n\nFootnotes\n[1] Simultaneous broadcast is a well-studied problem. Every financial exchange and video game has solved this problem before.\n[2] Keccak hash of the current date + a salt phrase.\n[3] As PlasmaPower stated, PR 1504 is intended to be a temporary solution until Offchain Labs designs a more sophisticated transaction ordering solution, as discussed here.\n\n Transaction ordering policy\n\n post by edfelten on Mar 1, 2023\n\n edfelten\n\n Thanks for your post. Your argument against using proof of work here makes sense.\nOur research team has been working in recent months on transaction ordering questions. Some of our thinking is in this new post.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Time boost: a new transaction ordering policy proposal\n\n Uncategorized\n\n 34\n\n 9.8k\n\n Sep 2023\n\n The power of faster blocks\n\n Uncategorized\n\n 11\n\n 4.2k\n\n Sep 2024\n\n Transaction ordering policy\n\n Uncategorized\n\n 10\n\n 8.6k\n\n Mar 2023\n\n Proposed design for Timeboost\n\n Uncategorized\n\n 12\n\n 3.3k\n\n Jun 2024\n\n FairFlow: Leveraging TimeBoost to Build a Fair and Transparent L2 MEV Economy\n\n Uncategorized\n\n tx-ordering\n\n 0\n\n 448\n\n Apr 2025","tokens":1404,"squid":"spider-01","role":"Chain Spider","at":1791348402192,"hash":"45c9a73b1d289a2ae574c98b795c94f522c18209"}
{"url":"https://forum.across.to/t/what-the-token-does/52/9","domain":"forum.across.to","title":"What the token does? - Tokenomics (old) - Across Protocol","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Nov 2021\n\n 9 / 26\n\n Nov 2021\n\n Apr 2022\n\n Load more posts above\n\n post by fojo on Nov 17, 2021\n\n post by DHACK on Nov 17, 2021\n\n DHACK\n\n Need tokens to attract users . I agree with it\n\n post by Robot on Nov 17, 2021\n\n Robot\n\n I think we should bump up the fees for using the bridge by a small % but if you stake X amount of the token then fees come back down to the original %, and if you stake even more you become eligible for profit share and all the usual stuff that comes with a govenunce token.\n\n post by fommes.eth on Nov 17, 2021\n\n fommes.eth\n\n Imho there is no point in holding the Across token for fees reduction. I imagine a tipical Across user will not bridge all the time, just looking at the general roadmap/POV that Eth mainnet is becoming solely/mostly just the settlement layer, already in the coming months ppl will use more frequent L2s and withdraw back sometimes.\n\n post by fommes.eth on Nov 17, 2021\n\n fommes.eth\n\n I propose the Across token to accrue fees for holders instead.\n\n post by Robot on Nov 17, 2021\n\n Robot\n\n fommes.eth\n\n Surely the more utility the better and i’m sure Across will have to go L2 to L2 in the end\n\n post by Sanguine on Nov 17, 2021\n\n Sanguine\n\n Kastormagic\n\n I think that token is needed for the DAO in the first place. It is not even necessary that it have economic value in the form of receiving % from commissions for the interaction of other users with the protocol. First of all, a token is a symbol. The more successful the project is, the more people want to be involved in it through the token.\n\n post by jotatotal on Nov 17, 2021\n\n jotatotal\n\n I would suggest that a part of the fees goes to the DAO treasury, and so increment value of DAO token. On the other hand I also consider that if the token is used to pay fees those fees get burned after that.\n\n post by fommes.eth on Nov 17, 2021\n\n fommes.eth\n\n Robot\n\n There are lots of L2 to L2 bridges already. Imho Across is unique in that sense and should aim to be the Go-To for fast+secure L1 withdrawals. There will always be a need for L1 withdrawals, even if Ethereum becomes mostly just an execution layer.\n\n post by Robot on Nov 17, 2021\n\n Robot\n\n Sanguine\n\n That’s not true go look at Ribbon finance and their token launch people bought and it non-stop gets called a useless govenunce token, Ribbon is very successful with about $200m TVL but the token price don’t reflect that\n\n post by Solace on Nov 17, 2021\n\n Solace\n\n Completely agree with /u/fojo’s post above - this is an important discussion regarding the token launch.\nWould the token be used strictly for governance, to pay out fees, or as a safety module? These do not necessarily have to mutually exclusive, and it’s possible that the token could incorporate all three - but as far as emission and distribution goes, it’s pretty important to make at least one a priority.\nIf choosing a governance route, liquidity incentives and a safety module could also be implemented at a later stage via a proposal. But this would remain subject to a vote, which could take some time to pass.\nOn the topic of liquidity incentives, these will likely remain temporary in order to bootstrap liquidity though there are plenty of examples of where artificially incentivizing usage has led to users with short-term outlooks farming these pools and draining the liquidity afterwards.\nAs far as using the token to incentivize usage goes, one approach could be to provide a gas fee rebate to users that bridge from L1 → L2 using the Arbitrum/optimism native bridge and bridge back to L1 using Across. This could be implemented similarly to Balancer’s gas fee rebate: [Proposal] Balancer Exchange Gas Reimbursement - Proposals - Balancer\nWe could get creative with some ways in order to incentivize usage rather than only incentivizing the LPs (as they will receive a fee of the transaction either way).\n\n post by Sanguine on Nov 17, 2021\n\n post by eqing.eth on Nov 21, 2021\n\n post by Alisa on Nov 22, 2021\n\n 9 days later\n\n post by MrHeviDi on Dec 1, 2021\n\n 2 months later\n\n post by jotatotal on Jan 26, 2022\n\n post by lawpanda.eth on Jan 26, 2022\n\n 2 months later\n\n post by J.Berg on Mar 18, 2022\n\n post by heybeo on Mar 22, 2022\n\n post by altsilversurfer.nft on Mar 26, 2022\n\n Load more posts below","tokens":1079,"squid":"spider-09","role":"Bridge Spider","at":1791348414710,"hash":"77ed5f7082cda9ef55812203068d02bf8402ea5a"}
{"url":"https://akash.network/docs/node-operators/node-build/helm-chart","domain":"akash.network","title":"Akash Node Via Helm Chart | Akash Network - Your Guide to Decentralized Cloud","text":"Akash Node Via Helm Chart Deploy an Akash RPC node to your Kubernetes cluster using Helm. This method uses blockchain snapshots for rapid synchronization.\nTime: 20-30 minutes (including snapshot download and sync)\nRequirements:\n\nExisting Kubernetes cluster\nHelm 4.0+\nkubectl access\n100 GB storage (minimum), 1 TB recommended\n\nStep 1 - Prepare Kubernetes Cluster\nCreate Namespace\nTerminal windowkubectl create ns akash-serviceskubectl label ns akash-services akash.network/name=akash-services akash.network=true\nInstall Helm\nTerminal window# Download Helmwget https://get.helm.sh/helm-v4.0.1-linux-amd64.tar.gztar -zxvf helm-v4.0.1-linux-amd64.tar.gzinstall linux-amd64/helm /usr/local/bin/helm\n# Add Akash Helm repositoryhelm repo add akash https://akash-network.github.io/helm-chartshelm repo update akash\n\nStep 2 - Install Akash Node\nInstall with Default Settings (Recommended)\nThe default installation uses blockchain snapshots for fast initial sync (~20 minutes for download and extraction, depending on connection speed).\nTerminal windowhelm install akash-node akash/akash-node -n akash-services\nExpected output:\nNAME: akash-nodeNAMESPACE: akash-servicesSTATUS: deployed\nWhat happens:\n\nDownloads latest blockchain snapshot from Akash snapshot provider\nExtracts snapshot to node data directory\nBegins syncing from snapshot height to current block\n\nInstall with Custom Storage\nFor production nodes, increase storage allocation:\nTerminal windowhelm install akash-node akash/akash-node -n akash-services \\ --set ceph_storage.enabled=true \\ --set ceph_storage.capacity=1000Gi \\ --set ceph_storage.storageclass=beta3\nInstall with State Sync (Alternative)\nState sync is faster but requires finding reliable RPC endpoints:\nTerminal windowhelm install akash-node akash/akash-node -n akash-services \\ --set state_sync.enabled=true \\ --set state_sync.rpc1=\"https://akash-rpc.polkachu.com:443\" \\ --set state_sync.rpc2=\"https://akash-rpc.polkachu.com:443\"\n\nStep 3 - Verify Node\nCheck Pod Status\nTerminal windowkubectl get pods -n akash-services\nExpected output:\nNAME READY STATUS RESTARTS AGEakash-node-1-xxxxx-xxxxx 1/1 Running 0 2m\nCheck Sync Status\nTerminal window# Get pod namePOD_NAME=$(kubectl get pods -n akash-services -l app=akash-node -o jsonpath='{.items[0].metadata.name}')\n# Check statuskubectl exec -n akash-services $POD_NAME -- akash status | jq '.sync_info.catching_up'\nExpected:\n\ntrue - Still syncing\nfalse - Fully synced\n\nMonitor Logs\nTerminal windowkubectl logs -n akash-services -l app=akash-node --tail=50 -f\nPress Ctrl+C to stop following logs.\n\nAccess Node RPC\nFrom Within Kubernetes Cluster\nTerminal windowexport AKASH_NODE=\"http://$(kubectl -n akash-services get svc akash-node-1 -o jsonpath='{.spec.clusterIP}'):26657\"curl -s \"$AKASH_NODE/status\" | jq '.result.sync_info'\nFrom Outside Kubernetes (Port Forward)\nTerminal window# Forward RPC portkubectl -n akash-services port-forward svc/akash-node-1 26657:26657\n# In another terminal, test the connectioncurl -s http://127.0.0.1:26657/status | jq '.result.sync_info'\n\nConfiguration Options\nView available configuration options:\nTerminal windowhelm show values akash/akash-node\nCommon options:\n\nOptionDefaultDescriptionakash_node.snapshot_providerakashSnapshot provider: akash, polkachu, c29r3, or autostakestate_sync.enabledfalseEnable state sync (alternative to snapshot)ceph_storage.enabledfalseUse Ceph block storageceph_storage.capacity100GiSize of Ceph volumeceph_storage.storageclassakash-nodesStorage class namelocal_storage.enabledfalseUse local node storagelocal_storage.capacity100GiSize of local volumeakash_node.monikermynodeNode nameakash_node.chainidakashnet-2Chain IDakash_node.pruningnothingPruning strategy\n\nUpgrade Node\nTerminal window# Update Helm repositoryhelm repo update akash\n# Upgrade nodehelm upgrade akash-node akash/akash-node -n akash-services\n\nUninstall Node\nTerminal windowhelm -n akash-services uninstall akash-node\nNote: This does not delete the persistent volume claim. To remove it:\nTerminal windowkubectl -n akash-services delete pvc data-akash-node-1-0\n\nNext Steps\n\nFor Validators: See Running a Validator\nFor Providers: Configure provider to use this node as RPC endpoint\nFor dApps: Use the node’s cluster IP or port-forward for local development\n\nQuestions? Join #validators on Discord \nEdit page on github\n CLI Build Omnibus","tokens":1083,"squid":"spider-03","role":"Compute Spider","at":1791348418337,"hash":"a20a42adffa08bc25db20ef6db1899533fe612d9"}
{"url":"https://forum.across.to/t/what-the-token-does/52/12","domain":"forum.across.to","title":"What the token does? - Tokenomics (old) - Across Protocol","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 read \n\n 4\n min\n\n Nov 2021\n\n 12 / 26\n\n Nov 2021\n\n Apr 2022\n\n Load more posts above\n\n post by fommes.eth on Nov 17, 2021\n\n post by fommes.eth on Nov 17, 2021\n\n fommes.eth\n\n I propose the Across token to accrue fees for holders instead.\n\n post by Robot on Nov 17, 2021\n\n Robot\n\n fommes.eth\n\n Surely the more utility the better and i’m sure Across will have to go L2 to L2 in the end\n\n post by Sanguine on Nov 17, 2021\n\n Sanguine\n\n Kastormagic\n\n I think that token is needed for the DAO in the first place. It is not even necessary that it have economic value in the form of receiving % from commissions for the interaction of other users with the protocol. First of all, a token is a symbol. The more successful the project is, the more people want to be involved in it through the token.\n\n post by jotatotal on Nov 17, 2021\n\n jotatotal\n\n I would suggest that a part of the fees goes to the DAO treasury, and so increment value of DAO token. On the other hand I also consider that if the token is used to pay fees those fees get burned after that.\n\n post by fommes.eth on Nov 17, 2021\n\n fommes.eth\n\n Robot\n\n There are lots of L2 to L2 bridges already. Imho Across is unique in that sense and should aim to be the Go-To for fast+secure L1 withdrawals. There will always be a need for L1 withdrawals, even if Ethereum becomes mostly just an execution layer.\n\n post by Robot on Nov 17, 2021\n\n Robot\n\n Sanguine\n\n That’s not true go look at Ribbon finance and their token launch people bought and it non-stop gets called a useless govenunce token, Ribbon is very successful with about $200m TVL but the token price don’t reflect that\n\n post by Solace on Nov 17, 2021\n\n Solace\n\n Completely agree with /u/fojo’s post above - this is an important discussion regarding the token launch.\nWould the token be used strictly for governance, to pay out fees, or as a safety module? These do not necessarily have to mutually exclusive, and it’s possible that the token could incorporate all three - but as far as emission and distribution goes, it’s pretty important to make at least one a priority.\nIf choosing a governance route, liquidity incentives and a safety module could also be implemented at a later stage via a proposal. But this would remain subject to a vote, which could take some time to pass.\nOn the topic of liquidity incentives, these will likely remain temporary in order to bootstrap liquidity though there are plenty of examples of where artificially incentivizing usage has led to users with short-term outlooks farming these pools and draining the liquidity afterwards.\nAs far as using the token to incentivize usage goes, one approach could be to provide a gas fee rebate to users that bridge from L1 → L2 using the Arbitrum/optimism native bridge and bridge back to L1 using Across. This could be implemented similarly to Balancer’s gas fee rebate: [Proposal] Balancer Exchange Gas Reimbursement - Proposals - Balancer\nWe could get creative with some ways in order to incentivize usage rather than only incentivizing the LPs (as they will receive a fee of the transaction either way).\n\n post by Sanguine on Nov 17, 2021\n\n Sanguine\n\n Robot\n\n Maybe so. Indeed, in our time, the success of the project for the crowd is the endless rise in the price of the token. And if the price of a token does not grow infinitely, then they begin to call it “useless governance token”. But if the project starts to hype and the price rises, then it abruptly turns into an “incredibly useful governance token”.\n\n post by eqing.eth on Nov 21, 2021\n\n post by Alisa on Nov 22, 2021\n\n 9 days later\n\n post by MrHeviDi on Dec 1, 2021\n\n 2 months later\n\n post by jotatotal on Jan 26, 2022\n\n post by lawpanda.eth on Jan 26, 2022\n\n 2 months later\n\n post by J.Berg on Mar 18, 2022\n\n post by heybeo on Mar 22, 2022\n\n post by altsilversurfer.nft on Mar 26, 2022\n\n post by jeffrey on Mar 29, 2022\n\n 12 days later\n\n post by hescollazo on Apr 11, 2022\n\n 10 days later\n\n post by Ray_V on Apr 21, 2022\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Initial thinking around token distribution\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 36\n\n Mar 2022\n\n Across Token Launch Proposal\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 214\n\n May 2022\n\n Across Token Launch Proposal v2\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 47\n\n Nov 2022\n\n Second ACX Drop\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 15\n\n Feb 2024\n\n Welcome to Across\n\n WELCOME 👋\n\n WELCOME 👋\n\n Nov 2022","tokens":1134,"squid":"spider-09","role":"Bridge Spider","at":1791348426182,"hash":"464d3371fa4c84d277577780fe17473ba5486ba4"}
{"url":"https://gov.optimism.io/t/upgrade-16-proposal-interop-contracts-stage-1-and-go-1-23-support-in-cannon/10037","domain":"gov.optimism.io","title":"Upgrade 16 Proposal: Interop Contracts, Stage 1, and Go 1.23 Support in Cannon - Proposals 📃 / Protocol Upgrade - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n Upgrade 16 Proposal: Interop Contracts, Stage 1, and Go 1.23 Support in Cannon \n\n Proposals 📃Protocol Upgrade\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 Jun 2025\n\n 1 / 19\n\n Jun 2025\n\n Aug 2025\n\n post by kelvin on Jun 20, 2025\n\n kelvin\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 proposal was prepared by various engineers and program managers at OP Labs and has received preliminary review from the Developer Advisory Board. Neither OP Labs nor I or any other entity mentioned represent or speak on behalf of the Optimism Foundation.\nThis proposal is will run off-cycle, as outlined in the Operating Manual\nExecutive Summary\n\nUpgrade 16 prepares for Superchain interop. It includes all of the smart contract changes required to support the interop launch date, but does not turn interop on yet.\nUpgrade 16 increases OP Stack decentralization and security by removing a permissioned role and guaranteeing that the OP Stack continues to meet L2Beat’s updated Stage 1 criteria.\nUpgrade 16 includes a number of additional maintenance features and improvements to the OP Stack experience.\n\nCannon is being updated to support Go 1.23, which allows the OP Stack to stay up to date with upstream changes to go-ethereum.\nOP Stack chains can now scale further with an increase in the maximum allowed gas limit from 200 million gas per block to 500 million gas per block after recent improvements to the OP Stack proof system and other related infrastructure.\n\nMotivation\nThe Optimism Collective’s vision includes a decentralized, interoperable Superchain that allows users and developers to move freely and securely across chains.\nPrepare for Interop\nInteroperability is critical to realizing the Superchain as a unified network of OP Chains. By upgrading contracts to support key interop features, we lay the foundation to more easily and securely turn interop on.\nIncrease Decentralization and Security\nWe want to minimize trust assumptions wherever possible to build a better Superchain. This upgrade removes a permissioned role and ensures that the OP Stack will continue to meet L2Beat’s updated Stage 1 requirements from January 2025.\nGo 1.23 support in Cannon\nBecause the OP Stack’s op-geth was upgraded to require Go 1.23, Cannon has been upgraded to support it.\nKona support in Cannon\nKona provides an OP Stack state transition proof SDK written in Rust, and Kona is now supported in Cannon. Diversity of proof systems is important to the resiliency of the OP Stack. Before Kona, there was only op-program, written in Go.\nIncrease MAX_GAS_LIMIT\nMAX_GAS_LIMIT exists so that chain operators don’t configure block gas limit to an amount that’s too large to be fault-provable. With the release of MT Cannon in Upgrade 14, this limit can now be safely increased. This extended configurability may serve OP Stack deployments that need a very large yet fault-provable gas limit.\nSpecifications\nBlockspace Charter\n\nThis upgrade requires a number of small modifications to the Standard Rollup Charter.\n\nWe are proposing to update the Standard Rollup Charter such that the gas limit is increased to 500m and the OP Contracts Manager address is updated to 0x56ebc5c4870f5367b836081610592241ad3e0734 and the latest release tag is op-contracts/v4.0.0-rc.8 and corresponds to the commit 54c19f6acb7a6d3505f884bae601733d3d54a3a6 in the Optimism Monorepo\n\nThe most recent version can be found here.\nPR to update the Standard Rollup Charter can be found here:\n\nUpdate Standard Rollup Charter for Upgrade 16 by smartcontracts · Pull Request #50 · ethereum-optimism/OPerating-manual · GitHub\n\nTechnical Details\nInterop-Ready Smart Contracts\nDocumentation\n\nDesign document\nSpecification (1, 2)\nImplementation (1, 2, 3)\nFailure mode analysis (1, 2)\n\nDescription\nUpgrade 16 updates the core bridge contracts of the OP Stack to be able to support native interoperability between two OP Stack chains. Although Upgrade 16 does not turn interop on, it includes all of the smart contract changes required to support the interop launch date.\nModifications required for interop readiness included the following improvements to the stack:\n\nThe OptimismPortal now relies on the AnchorStateRegistry as the “source of truth” for the validity of dispute games that can be used to execute withdrawals. This was necessary so that multiple OptimismPortal contracts within the Interop Set could share a common source of truth (instead of each OptimismPortal having its own view of the system).\nThe OptimismPortal now stores ETH in a dedicated ETHLockbox contract rather than holding ETH within the OptimismPortal itself. This change introduces the possibility for chains to eventually pool their ETH into a single ETHLockbox contract, which means that ETH that gets deposited into one chain can be withdrawn from another chain.\n\nWithout a shared ETHLockbox it would be possible to transfer ETH from one L2 to another, but it would not always be possible to withdraw that ETH back to Ethereum. A shared ETHLockbox contract solves this problem.\nShared ETHLockbox contracts are only useful after interop goes live (in a future upgrade). This upgrade DOES NOT introduce any shared lockbox contracts. Each chain after Upgrade 16 will still have its own independent ETHLockbox. Future governance actions will deal with any proposals to join lockboxes into a shared lockbox.\n\nThe OptimismPortal now has a version of the proveWithdrawalTransaction function that supports the updated SuperFaultDisputeGame implementation required for interop. \"this method will be enabled when we turn interop on in Upgrade 17.\n\nStage 1 Updates\nDocumentation\n\nDesign document\nSpecification\nImplementation\nFailure mode analysis\n\nDescription\nUpgrade 16 includes updates to the OP Stack that make sure it’ll continue to meet L2Beat’s updated Stage 1 requirements from January 2025.\n\nThe DeputyGuardianModule has been removed. This means that the Security Council is now the only address that is allowed to perform Guardian-only actions by default. This includes actions that invalidate dispute games.\nThe DeputyPauseModule has been updated so that it can be installed into the Security Council’s Guardian Safe. The DeputyPauseModule is otherwise unmodified and allows the Optimism Foundation to trigger the pause action.\nThe pause action expires automatically after 3 months. This 3 month value was selected in coordination with L2Beat and implies a maximum pause period of 6 months (by utilizing the chain-specific pause and then the Superchain-wide pause back-to-back). The Optimism Foundation cannot trigger the pause more than once unless the Security Council explicitly allows it to do so. This means that an indefinite pause of the bridge system for OP Mainnet and other Optimism-governed chains is only possible if ≥75% of the Security Council approves (whereas this is currently possible if ≥25% of the Security Council refuses to unpause).\nThe pause action can now be applied on a per-chain basis as well as a Superchain-wide basis, minimizing the impact of the pause mechanism if an issue would only impact one specific chain. Various contracts have been updated to read the status of the pause via the SystemConfig contract instead of the SuperchainConfig contract to account for this new chain-specific pause mechanism.\nOverall, this is a major improvement to the OP Stack. It simplifies the stack such that (in the absence of a bug) withdrawal liveness failures and withdrawal safety failures require ≥75% of the Security Council. Upgrade 16 represents a significant decentralization step and a removal of all unilateral Optimism Foundation actions other than a time-bounded pause that automatically expires after 3 months.\n\nGo 1.23 Support in Cannon\nDocumentation\n\nImplementation:\n\nhttps://github.com/ethereum-optimism/optimism/pull/14692\ncannon: Add feature toggling to MIPS VM contracts by mbaxter · Pull Request #15487 · ethereum-optimism/optimism · GitHub\nhttps://github.com/ethereum-optimism/optimism/pull/15664\ncannon: Noop mprotect syscall by Inphi · Pull Request #15792 · ethereum-optimism/optimism · GitHub\nhttps://github.com/ethereum-optimism/optimism/pull/16341\nhttps://github.com/ethereum-optimism/optimism/pull/16346\ncannon: Enforce the non-block flag for eventfd syscalls by mbaxter · Pull Request #16384 · ethereum-optimism/optimism · GitHub\nAdd report for the Cannon Go 1.23 support fix by pauldowman · Pull Request #16479 · ethereum-optimism/optimism · GitHub\n\nFailure mode analysis\n\nDescription\n\nCannon, the Fault Proof VM, has been updated to be able to support Go 1.23. This means the OP Stack can keep benefiting from upstream changes in go-ethereum.\n\nKona Support in Cannon\nDocumentation\n\nImplementation\nFailure mode analysis\n\nDescription\n\nKona is an alternative Fault Proof Program, i.e. an alternative to op-program, written in Rust. Cannon, the Fault Proof VM, has been updated to be able to run Kona, in order to increase the diversity of proofs systems that are supported.\n\nMax Gas Limit Increase\nDocumentation\n\nImplementation\n\nDescription\n\nThe MAX_GAS_LIMIT variable in the SystemConfig contract is being updated from 200m gas to 500m gas after updates to OP Stack infrastructure and the Cannon proof system have made it possible for chains to safely increase the gas limit beyond 200 million gas per block.\n\nAdditional Safety Improvements\n\nCritical functions for contract upgrades (initialize and upgrade) are now authenticated and can only be triggered by the same account that is able to upgrade the contracts. This mitigates the risk of a contract being left in a state where upgrade or initialize could be called by a malicious third party.\nThe DelayedWETH contract no longer has an owner variable and is now controlled by the upgrade account (this cannot be changed without a contract upgrade). This is a simplification to the DelayedWETH contract and prevents chains from misconfiguring the contract’s owner.\nThis upgrade introduces a new StandardValidator contract, which encodes the standard configuration. It can inspect and OP Chain, and will return a list of error codes identifying any deviations from the standard configuration.\n\nAudits and Security Reviews\n\nChanges to the bridge contracts to support interop were audited as part of a contest held operated via Cantina. This contest found no Medium+ severity issues. Some Low severity issues were fixed as part of this contest.\nUpgrade 16 as a whole was audited by Spearbit. This audit found no Medium+ severity issues. Some Low severity issues were fixed as part of this audit.\nThe calldata and code for this governance proposal are in scope for the Optimism bug bounty in Immunefi (as described in the Governance Proposals section). With recent updates, this code is in scope for the bounty as of the publication of this post, BEFORE this code is live on mainnet.\n\nAbsolute Prestate\nThis upgrade includes the absolute prestate for op-program v1.6.1-rc.1. The full diff between v1.6.0 and v1.6.1-rc.1 can be inspected here. The absolute prestate hash (cannon64 variant) is 0x03eb07101fbdeaf3f04d9fb76526362c1eea2824e4c6e970bdb19675b72e4fc8. It has been publicly verified here.\nImpact Summary\nUpgrade 16 is a largely standard upgrade to the L1 smart contracts for the OP Stack. We do not expect any downtime or changes in performance.\nUpgrade 16, like Upgrade 13, involves a one-time invalidation of all existing withdrawal proofs. This invalidation is the simplest and safest way to carry out the proposed changes to the AnchorStateRegistry contract. Users who have proven withdrawals can either finalize withdrawals prior to the activation of Upgrade 16 or will be required to re-prove these withdrawals after the upgrade activates.\nPrecommitment impact review\nUpgrade 16 does not impact any of the precommitments included in the Standard Rollup Charter as of the writing of this proposal.\n\n“Collective Fee Take” - unchanged\n“Governor/Servicer Role Separation” - unchanged\n“Ossified GasLimits” - gas limit is increased, but gas limit continues to not be ossified and the changes in this proposal fall within the bounds of the precommitment\n“Direct Fee Margin Controls” - unchanged\n\nAction Plan\nIf this proposal is accepted, the upgrade is expected to take place on July 24, 2025. In that case, mulitisig ceremonies will be coordinate such that the following transactions will be executed.\nThe upgrade will be executed using OP Contracts Manager (OPCM) version 4.0.0:\n\nThe OPCM source code for this release is available at op-contracts/v4.0.0-rc.8.\n\nThe mainnet deployment address for the OPCM is available in the superchain-registry: 0x56ebc5c4870f5367b836081610592241ad3e0734\n\nUpgrade transaction commitments\nAll of the following data will executed by the relevant multisigs as a DELEGATECALL to Multicall3DelegateCall. If target and calldata in the runbooks prepared for executing the upgrade do not match, they should not be executed.\n\nTo upgrade OP Mainnet and Ink\n0x82ad56cb00000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000000000000000002000000000000000000000000056ebc5c4870f5367b836081610592241ad3e0734000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000600000000000000000000000000000000000000000000000000000000000000104ff2dd5a100000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000002000000000000000000000000229047fed2591dbec1ef1118d64f7af3db9eb290000000000000000000000000543ba4aadbab8f9025686bd03993043599c6fb0403eb07101fbdeaf3f04d9fb76526362c1eea2824e4c6e970bdb19675b72e4fc800000000000000000000000062c0a111929fa32cec2f76adba54c16afb6e8364000000000000000000000000d56045e68956fce2576e680c95a4750cf8241f7903eb07101fbdeaf3f04d9fb76526362c1eea2824e4c6e970bdb19675b72e4fc800000000000000000000000000000000000000000000000000000000\n\nTo upgrade Soneium\n0x82ad56cb00000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000000000000000002000000000000000000000000056ebc5c4870f5367b836081610592241ad3e07340000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006000000000000000000000000000000000000000000000000000000000000000a4ff2dd5a1000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000000010000000000000000000000007a8ed66b319911a0f3e7288bddab30d9c0c875c300000000000000000000000089889b569c3a505f3640ee1bd0ac1d557f436d2a03eb07101fbdeaf3f04d9fb76526362c1eea2824e4c6e970bdb19675b72e4fc800000000000000000000000000000000000000000000000000000000\n\nTo upgrade Unichain\n0x82ad56cb00000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000000000000000002000000000000000000000000056ebc5c4870f5367b836081610592241ad3e07340000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006000000000000000000000000000000000000000000000000000000000000000a4ff2dd5a100000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000001000000000000000000000000c407398d063f942febbcc6f80a156b47f3f1bda60000000000000000000000003b73fa8d82f511a3cae17b5a26e4e1a2d5e2f2a403eb07101fbdeaf3f04d9fb76526362c1eea2824e4c6e970bdb19675b72e4fc800000000000000000000000000000000000000000000000000000000\n\nNode operators should ensure they are running up-to-date versions of op-node and op-geth:\n\nop-node: op-node/v1.12.2\nop-geth: op-geth/v1.101503.1\n\nFor chain operators running fault-proof infrastructure, ensure you are running up-to-date versions of the following:\n\nop-challenger: op-challenger/v1.5.1\n\nIf a critical security issue is discovered before upgrading, OP Labs will collaborate with the community to extensively communicate that the upgrade will no longer occur.\nConclusion\nUpgrade 16 represents a major step towards the launch of interoperability on the OP Stack.\nThe key components of this upgrade include:\n\nImplementation of the interoperability features into the L1 bridging system\nVarious system tweaks required to retain Stage 1 status\nGo 1.23 support in Cannon\nOther security improvements\n\nWhile this upgrade does require an invalidation of existing withdrawal proofs, the impact on users is minimal and temporary. The upgrade has been thoroughly tested and audited, with no significant security concerns identified.\nWe request the Optimism Collective’s approval for this upgrade, as it represents a crucial step forward in our ongoing mission to improve the OP Stack.\n\nEdit Log\n\n2025-06-20: Added Precommitments section to highlight that none of the commitments in the Standard Rollup Charter are impacted by this proposal.\n2025-06-20: Updated to note that the OPContractsManager address and the gas limit are being updated in the Standard Rollup Charter and included a link to the PR that makes this update.\n2025-06-23: In “Go 1.23 Support in Cannon”, added links to GitHub pull requests #16341, #16346, #16384, and the audit in pull request #16479\n2025-06-23: Added “Absolute Prestate” section to note the value of the updated absolute prestate for the fault proof system.\n2025-07-08: Updated link for OPContractManager address on Mainnet.\n\n Optimism Gov Summary\n\n SEEDGov - Delegate Communication Thread\n\n Season 8 Reflection Period Guide\n\n Special Voting Cycle Roundup#39b\n\n AlexSotoDigital.eth - Delegate Communication Thread\n\n 2\n\n 2\n\n read \n\n 9\n min\n\n post by Michael on Jun 20, 2025\n\n post by wildmolasses on Jun 20, 2025\n\n post by system on Jun 20, 2025\n\n post by Gonna.eth on Jun 20, 2025\n\n post by kelvin on Jun 23, 2025\n\n post by Luckyhooman.eth on Jun 23, 2025\n\n post by system on Jun 23, 2025\n\n post by SEEDGov on Jun 25, 2025\n\n post by ImanPJN on Jun 25, 2025\n\n post by PGov on Jun 27, 2025\n\n post by aygul on Jun 29, 2025\n\n post by brichis on Jun 30, 2025\n\n post by DAOplomats.eth on Jun 30, 2025\n\n post by olimpio on Jul 1, 2025\n\n post by mastermojo on Jul 1, 2025\n\n post by OPUser on Jul 1, 2025\n\n post by Sinkas on Jul 9, 2025\n\n 1 month later\n\n post by Vikthor on Aug 23, 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 Maintenance Upgrade Proposal: U16a\n\n Technical Proposals\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 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 319\n\n Jan 28\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 [FINAL] Upgrade Proposal #2: Canyon Network Upgrade\n\n Protocol 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 Upgrade Proposal #10: Granite Network Upgrade\n\n Protocol 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","tokens":5110,"squid":"spider-07","role":"Council Spider","at":1791348431520,"hash":"93784543b5e1d557e9e9136e73155aad3db2f2c4"}
{"url":"https://forum.across.to/t/what-the-token-does/52/5","domain":"forum.across.to","title":"What the token does? - Tokenomics (old) - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n Tokenomics (old)\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Nov 2021\n\n 5 / 26\n\n Nov 2021\n\n Apr 2022\n\n post by Kastormagic on Nov 12, 2021\n\n Kastormagic\n\n As we discusse about airdrops and « who gets what », I think we should talk about what the token does. That’s why I launch this conversation.\nAn example : Across token gives you a fees reduction when you use the bridge, xAcross (think xSushi) gives you voting power and a share of the fees.\nLet’s talk about it ! We want to hear you !\n\n 3\n\n 3\n\n 2\n\n 2\n\n read \n\n 4\n min\n\n post by heropunk.eth on Nov 17, 2021\n\n heropunk.eth\n\n AcrossIt is to build a DAO and become a community governance token, not to use it as gas, so I don’t agree with you, on the contrary AcrosdDAO, it will have more uses\n\n post by goldsnitch.eth on Nov 17, 2021\n\n goldsnitch.eth\n\n Need tokens to attract users\n\n post by fojo on Nov 17, 2021\n\n fojo\n\n Thanks for starting this discussion. To me this is the most important discussion to have with regards to tokenomics. There is no point in airdropping a token that does nothing. So first and foremost we should think about and decide on what the token will do.\nHere’s my 2 cents:\nGovernance: Establish a governance framework by granting discission making to across token holders (i.e. voting power)\nFees: Establish utility to the token (rather than it being just a governance token) by either giving fee reductions when using the bridge or a share of the fees generated by the bridge.\nSafety module: Staked across tokens will act as a collateral of last resort, to provide insurance against shortfall events. Stakers will get staking rewards. (see AAVE and DYDX for examples).\n\n post by DHACK on Nov 17, 2021\n\n DHACK\n\n Need tokens to attract users . I agree with it\n\n post by Robot on Nov 17, 2021\n\n Robot\n\n I think we should bump up the fees for using the bridge by a small % but if you stake X amount of the token then fees come back down to the original %, and if you stake even more you become eligible for profit share and all the usual stuff that comes with a govenunce token.\n\n post by fommes.eth on Nov 17, 2021\n\n fommes.eth\n\n Imho there is no point in holding the Across token for fees reduction. I imagine a tipical Across user will not bridge all the time, just looking at the general roadmap/POV that Eth mainnet is becoming solely/mostly just the settlement layer, already in the coming months ppl will use more frequent L2s and withdraw back sometimes.\n\n post by fommes.eth on Nov 17, 2021\n\n fommes.eth\n\n I propose the Across token to accrue fees for holders instead.\n\n post by Robot on Nov 17, 2021\n\n Robot\n\n fommes.eth\n\n Surely the more utility the better and i’m sure Across will have to go L2 to L2 in the end\n\n post by Sanguine on Nov 17, 2021\n\n Sanguine\n\n Kastormagic\n\n I think that token is needed for the DAO in the first place. It is not even necessary that it have economic value in the form of receiving % from commissions for the interaction of other users with the protocol. First of all, a token is a symbol. The more successful the project is, the more people want to be involved in it through the token.\n\n post by jotatotal on Nov 17, 2021\n\n jotatotal\n\n I would suggest that a part of the fees goes to the DAO treasury, and so increment value of DAO token. On the other hand I also consider that if the token is used to pay fees those fees get burned after that.\n\n post by fommes.eth on Nov 17, 2021\n\n fommes.eth\n\n Robot\n\n There are lots of L2 to L2 bridges already. Imho Across is unique in that sense and should aim to be the Go-To for fast+secure L1 withdrawals. There will always be a need for L1 withdrawals, even if Ethereum becomes mostly just an execution layer.\n\n post by Robot on Nov 17, 2021\n\n Robot\n\n Sanguine\n\n That’s not true go look at Ribbon finance and their token launch people bought and it non-stop gets called a useless govenunce token, Ribbon is very successful with about $200m TVL but the token price don’t reflect that\n\n post by Solace on Nov 17, 2021\n\n Solace\n\n Completely agree with /u/fojo’s post above - this is an important discussion regarding the token launch.\nWould the token be used strictly for governance, to pay out fees, or as a safety module? These do not necessarily have to mutually exclusive, and it’s possible that the token could incorporate all three - but as far as emission and distribution goes, it’s pretty important to make at least one a priority.\nIf choosing a governance route, liquidity incentives and a safety module could also be implemented at a later stage via a proposal. But this would remain subject to a vote, which could take some time to pass.\nOn the topic of liquidity incentives, these will likely remain temporary in order to bootstrap liquidity though there are plenty of examples of where artificially incentivizing usage has led to users with short-term outlooks farming these pools and draining the liquidity afterwards.\nAs far as using the token to incentivize usage goes, one approach could be to provide a gas fee rebate to users that bridge from L1 → L2 using the Arbitrum/optimism native bridge and bridge back to L1 using Across. This could be implemented similarly to Balancer’s gas fee rebate: [Proposal] Balancer Exchange Gas Reimbursement - Proposals - Balancer\nWe could get creative with some ways in order to incentivize usage rather than only incentivizing the LPs (as they will receive a fee of the transaction either way).\n\n post by Sanguine on Nov 17, 2021\n\n Sanguine\n\n Robot\n\n Maybe so. Indeed, in our time, the success of the project for the crowd is the endless rise in the price of the token. And if the price of a token does not grow infinitely, then they begin to call it “useless governance token”. But if the project starts to hype and the price rises, then it abruptly turns into an “incredibly useful governance token”.\n\n post by eqing.eth on Nov 21, 2021\n\n eqing.eth\n\n Kastormagic\n\n Tokens will attract some early users, which is necessary!At the initial stage of the project, it is necessary to attract users by token airdrop and distinguish real users.\n\n post by Alisa on Nov 22, 2021\n\n Alisa\n\n Acrosit is to establish a Dao and become a token of community governance. However, empowering and offsetting gas is a good suggestion, which can prevent members from throwing it out too early. However, it also has some disadvantages., if it is a gas, will it affect the development of community autonomy? But if it is only from the perspective of token, the more successful across is, the better the development of Dao will be, Of course, it will attract more people to participate\n\n 9 days later\n\n post by MrHeviDi on Dec 1, 2021\n\n MrHeviDi\n\n fommes.eth\n\n But there will be other protocals/bridges to move funds from L2 to L1, so Across needs to atract users to use Across and maybe to hold Across token. Maybe, like someone before montioned, having Across token will give you some fee reduction or something like that.\n\n 2 months later\n\n post by jotatotal on Jan 26, 2022\n\n jotatotal\n\n Solace\n\n What about giving the holders of the token , despite a fee reduction , a share of the fee according to their holdings?\n\n post by lawpanda.eth on Jan 26, 2022\n\n lawpanda.eth\n\n That would functionally be an ‘x’ token, like xSushi, dQuick, etc. On the legal end it creates regulatory questions because it resembles a security. But it is a more functional mechanism for facilitating adoption/use.\n\n Load more posts below","tokens":3349,"squid":"spider-09","role":"Bridge Spider","at":1791348438973,"hash":"0241f0aa8dbb762fc2fb28267a515bc9c4973df7"}
{"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":"spider-07","role":"Council Spider","at":1791348443099,"hash":"8d40dfd99a448f8d861543a541c01b3a2e4d602d"}
{"url":"https://forum.across.to/t/what-the-token-does/52/10","domain":"forum.across.to","title":"What the token does? - Tokenomics (old) - Across Protocol","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Nov 2021\n\n 10 / 26\n\n Nov 2021\n\n Apr 2022\n\n Load more posts above\n\n post by DHACK on Nov 17, 2021\n\n DHACK\n\n Need tokens to attract users . I agree with it\n\n post by Robot on Nov 17, 2021\n\n Robot\n\n I think we should bump up the fees for using the bridge by a small % but if you stake X amount of the token then fees come back down to the original %, and if you stake even more you become eligible for profit share and all the usual stuff that comes with a govenunce token.\n\n post by fommes.eth on Nov 17, 2021\n\n fommes.eth\n\n Imho there is no point in holding the Across token for fees reduction. I imagine a tipical Across user will not bridge all the time, just looking at the general roadmap/POV that Eth mainnet is becoming solely/mostly just the settlement layer, already in the coming months ppl will use more frequent L2s and withdraw back sometimes.\n\n post by fommes.eth on Nov 17, 2021\n\n fommes.eth\n\n I propose the Across token to accrue fees for holders instead.\n\n post by Robot on Nov 17, 2021\n\n Robot\n\n fommes.eth\n\n Surely the more utility the better and i’m sure Across will have to go L2 to L2 in the end\n\n post by Sanguine on Nov 17, 2021\n\n Sanguine\n\n Kastormagic\n\n I think that token is needed for the DAO in the first place. It is not even necessary that it have economic value in the form of receiving % from commissions for the interaction of other users with the protocol. First of all, a token is a symbol. The more successful the project is, the more people want to be involved in it through the token.\n\n post by jotatotal on Nov 17, 2021\n\n jotatotal\n\n I would suggest that a part of the fees goes to the DAO treasury, and so increment value of DAO token. On the other hand I also consider that if the token is used to pay fees those fees get burned after that.\n\n post by fommes.eth on Nov 17, 2021\n\n fommes.eth\n\n Robot\n\n There are lots of L2 to L2 bridges already. Imho Across is unique in that sense and should aim to be the Go-To for fast+secure L1 withdrawals. There will always be a need for L1 withdrawals, even if Ethereum becomes mostly just an execution layer.\n\n post by Robot on Nov 17, 2021\n\n Robot\n\n Sanguine\n\n That’s not true go look at Ribbon finance and their token launch people bought and it non-stop gets called a useless govenunce token, Ribbon is very successful with about $200m TVL but the token price don’t reflect that\n\n post by Solace on Nov 17, 2021\n\n Solace\n\n Completely agree with /u/fojo’s post above - this is an important discussion regarding the token launch.\nWould the token be used strictly for governance, to pay out fees, or as a safety module? These do not necessarily have to mutually exclusive, and it’s possible that the token could incorporate all three - but as far as emission and distribution goes, it’s pretty important to make at least one a priority.\nIf choosing a governance route, liquidity incentives and a safety module could also be implemented at a later stage via a proposal. But this would remain subject to a vote, which could take some time to pass.\nOn the topic of liquidity incentives, these will likely remain temporary in order to bootstrap liquidity though there are plenty of examples of where artificially incentivizing usage has led to users with short-term outlooks farming these pools and draining the liquidity afterwards.\nAs far as using the token to incentivize usage goes, one approach could be to provide a gas fee rebate to users that bridge from L1 → L2 using the Arbitrum/optimism native bridge and bridge back to L1 using Across. This could be implemented similarly to Balancer’s gas fee rebate: [Proposal] Balancer Exchange Gas Reimbursement - Proposals - Balancer\nWe could get creative with some ways in order to incentivize usage rather than only incentivizing the LPs (as they will receive a fee of the transaction either way).\n\n post by Sanguine on Nov 17, 2021\n\n Sanguine\n\n Robot\n\n Maybe so. Indeed, in our time, the success of the project for the crowd is the endless rise in the price of the token. And if the price of a token does not grow infinitely, then they begin to call it “useless governance token”. But if the project starts to hype and the price rises, then it abruptly turns into an “incredibly useful governance token”.\n\n post by eqing.eth on Nov 21, 2021\n\n eqing.eth\n\n Kastormagic\n\n Tokens will attract some early users, which is necessary!At the initial stage of the project, it is necessary to attract users by token airdrop and distinguish real users.\n\n post by Alisa on Nov 22, 2021\n\n Alisa\n\n Acrosit is to establish a Dao and become a token of community governance. However, empowering and offsetting gas is a good suggestion, which can prevent members from throwing it out too early. However, it also has some disadvantages., if it is a gas, will it affect the development of community autonomy? But if it is only from the perspective of token, the more successful across is, the better the development of Dao will be, Of course, it will attract more people to participate\n\n 9 days later\n\n post by MrHeviDi on Dec 1, 2021\n\n MrHeviDi\n\n fommes.eth\n\n But there will be other protocals/bridges to move funds from L2 to L1, so Across needs to atract users to use Across and maybe to hold Across token. Maybe, like someone before montioned, having Across token will give you some fee reduction or something like that.\n\n 2 months later\n\n post by jotatotal on Jan 26, 2022\n\n jotatotal\n\n Solace\n\n What about giving the holders of the token , despite a fee reduction , a share of the fee according to their holdings?\n\n post by lawpanda.eth on Jan 26, 2022\n\n lawpanda.eth\n\n That would functionally be an ‘x’ token, like xSushi, dQuick, etc. On the legal end it creates regulatory questions because it resembles a security. But it is a more functional mechanism for facilitating adoption/use.\n\n 2 months later\n\n post by J.Berg on Mar 18, 2022\n\n J.Berg\n\n Creating a token enables the DAO to have an asset (without investing) that can be used to fund projects/guilds for effort the DAO needs (both maintenance and major initiatives), as well as contribute to internal DAO economics.\n–Paying core team members for their efforts\n–Paying for work done by Guilds and their squads\n–Internal DAO markets and trade\n–Bounties\nWill the Across token be used strictly for governance? or will it be used as money? or both?\nWould it be a monetary asset and a governance token to be used to fund and vote? Some DAO’s treat their governance token as ONLY that, and it actively drives down it’s valuation.\nIf its money then the DAO as an organization has the challenges of both a startup and an emerging digital nationstate in that we have to find and create revenue streams and manage costs, as well as drive the use and acceptance of our denomination both internally and externally.\nI think long term will be based on the size of the treasury it controls and the useful things you can do with it. As a result, I think the focus should be on activities that generate on-chain revenue for the DAO and ways to make the token useful stake it, collateral, ect.\nHow to pay contributors is definitely an important factor to consider. Without contributors, we won’t be able to do any of the above. Part of me feels that if your contributing, it should be because you believe in the DAO long term and shouldn’t expect an immediate monetary reward. The other part of me thinks that contributor renumeration is something that needs to be painstakingly thought out to retain talent and pay our people\n\n post by heybeo on Mar 22, 2022\n\n heybeo\n\n It would be nice to use bridges on the same platform as well as to create a nice dex.\nTrading pairs, for example acx-uma, are used as fees and distributed to token holders.\nacx-x\nacx-y\nacx-z\nJust a simple idea as liquidity addition commissions are burned\n\n post by altsilversurfer.nft on Mar 26, 2022\n\n altsilversurfer.nft\n\n Tokenomics can be viewed as a function of 3 main parameters, token launch (model, vesting scheme, market cap), utility, and inflation. Utility is one of the major drivers of adoption and appreciation of value. Thus, the more utilities, the best. Governance will be the first and more obvious utility of $ACX, but we must think beyond this to achieve sustainnability. This is the ultimate goal. And this is also the common interest of all involved. People that are waiting for profits will be maximally rewarded if they be patient and contribute to protocol sustainnability. Across will be really BIG and this is not a fanboy statement. The major crosschain pipes will see in the future typical value movements that will far exceed those of the biggest centralized exchanges today.\n\n post by jeffrey on Mar 29, 2022\n\n jeffrey\n\n Token is share, it means users own the project\n\n Load more posts below","tokens":2203,"squid":"spider-09","role":"Bridge Spider","at":1791348450331,"hash":"df19a4d61069ee487f416776a390510b2d812bd6"}
{"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":"spider-07","role":"Council Spider","at":1791348452977,"hash":"c5d39a761b99a3647e5e2feeaa6610f8bbb847e4"}
{"url":"https://www.metaplex.com/docs/dev-tools/cli/cm/withdraw","domain":"metaplex.com","title":"MPLX CLI - Withdraw Candy Machine","text":"The mplx cm withdraw command withdraws and deletes a candy machine, recovering any remaining SOL balance and cleaning up the on-chain account. This operation is irreversible and should be used when the candy machine is no longer needed. Already minted NFTs are not affected.IrreversibleThis command is irreversible. Once executed your candy machine is destroyed and can not be recreated.Usage# Withdraw candy machine from current directory\nmplx cm withdraw\n\n# Withdraw specific candy machine by address\nmplx cm withdraw --address <candy_machine_address>\nOptional Flags that you can use:--address: Specify candy machine address directly--force: Danger Skip confirmation prompts (use with extreme caution)⚠️ Irreversible OperationPermanent Deletion: The candy machine account will be permanently deletedNo Recovery: Cannot be undone or restoredData Loss: All on-chain configuration and state will be lostMinted NFTs: Existing minted NFTs are not affected🛡️ Best PracticesPlanning:Plan withdrawal timing carefullyCoordinate with team membersExecution:Double-check all parametersUse devnet for practiceRelated Commandsmplx cm fetch - Check status before withdrawalmplx cm create - Create new candy machinesmplx cm validate - Validate before withdrawalsolana balance - Check recovered balance","tokens":322,"squid":"dotcat","role":"Tooling Spider","at":1791348460174,"hash":"6cec0d860376f84e9387c370dda1f9809dd38a0d"}
{"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":"spider-07","role":"Council Spider","at":1791348462744,"hash":"ff725dc30eaeab3ca8ce9615c0919ce4c6b54cae"}
{"url":"https://forum.across.to/t/acrossalert-proposal-amplifying-acrosss-excellence-on-twitter/1902","domain":"forum.across.to","title":"AcrossAlert Proposal: Amplifying Across's Excellence on Twitter - Proposals - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n AcrossAlert Proposal: Amplifying Across’s Excellence on Twitter \n\n Proposals\n\n treasury-funding\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 May 2024\n\n post by zeck on Apr 28, 2024\n\n zeck\n\n Summary\nI propose the allocation of 5,000 USDC from the Across DAO Community Fund to support the development and maintenance of AcrossAlerts, a real-time Twitter bot project. The project aims to provide timely notifications of whale activity on the bridge. This initiative aims to improve brand awareness through regular tweets and brand equity by showcasing that whales trust Across. In addition, this bot aims to showcase the attractiveness of bridging with Across, as tweets are structured to compare fees and speeds against major competitors.\nMotivation\nProvide Across community members with up-to-date information on critical bridge transactions. Increase brand awareness, and improve trust of Across Protocol to attract more users and developers. Foster protocol development and ecosystem expansion by delivering added value to the community, particularly through comparisons based on fees and speeds between bridges for specific transactions.\nSpecification & Implementation\nObjective\nTo offer real-time notifications for “whale” bridge transfers (over $300k) within the Across ecosystem, enhancing brand sentiment and providing value to the community.\nFeatures:\n\nUtilizes Node.js to monitor substantial transactions occurring on the Across protocol.\nPublishes notifications about these transactions on Twitter.\nRegular maintenance and updates to ensure stable operation.\n\nDevelopment Milestones\nCompleted (Q4 2023 to Q1 2024)\n\nReal-time tweeting of huge bridge transactions.\nAdaptation to Across v3 for feature compatibility.\nComparative analysis between Across’s bridge and Stargate’s offerings.\n\nPlanned (2024)\nQ2 Objectives\n\nDeployment of an automated tool for summarizing monthly whale transactions.\nAlert system for substantial $ACX token acquisitions.\n\nQ3 Objectives\n\nBroadening comparative analysis to encompass additional bridge services.\nNotification system for the dissemination of information regarding Across proposals.\n\nFinancial Overview\nThe total funding request of 5,000 USDC is budgeted with detailed allocations to ensure the project’s smooth operation and development over the next two years. The breakdown is as follows:\nOperating Costs:\nMonthly Expenses:Ongoing server maintenance and RPC calls are estimated at $70 monthly ($50 for server upkeep + $20 for RPC calls).\nTwo-Year Projection:The combined monthly operating costs for the upcoming two years, including the past six months, amount to 1,500 USDC.\nDevelopment Contributions\nPast Development:The development of the currently operational bot’s code has incurred costs of 1,000 USDC.\nFuture Development: An allocation of 1,500 USDC is set aside for the creation of new features and enhancements.\nAI API and Ongoing Expenses\nAI API Costs: The anticipated expenditure for AI API usage and related ongoing costs is projected at 500 USDC.\nCommunity Engagement and Contingency:\nDiscretionary and Community Fund:The balance of 500 USDC will serve as a flexible fund to cover unexpected costs or to capitalize on new opportunities to engage with the community.\nDetailed Allocation of 5,000 USDC:\n\nPast Six Months + Two-Year Server and RPC Costs:1,500 USDC\nPast Development Contributions: 1,000 USDC\nFuture Development Work: 1,500 USDC\nEstimated AI API and Ongoing Expenses: 500 USDC\nDiscretionary and Community Engagement Fund: 500 USDC\n\nTotal: 5,000 USDC\nThis structured financial plan ensures that each segment of the project is well-funded, with a clear and organized outline of costs, promoting transparency and accountability.\nExpected Outcomes\nCommunity Empowerment: Real-time updates will enable community members to make well-informed decisions, fostering a more active and engaged user base.\nBrand Amplification: Increased visibility of Across DAO will lead to a broader user and investor base.\nEcosystem Growth: AcrossAlert will serve as a catalyst for the growth and evolution of the Across DAO protocol by providing valuable transaction insights and encouraging community interaction.\nCommitment\nI pledge to invest the utmost dedication to the development and maintenance of AcrossAlert, maintaining transparent and regular communication with the community regarding project progress and operations.\nI humbly seek the Across DAO community’s endorsement for this initiative. Your support is pivotal to the project’s success. For any inquiries or feedback, please feel free to reach out\n\n post by Infinity on Apr 28, 2024\n\n Infinity\n\n Totally agree. From the beginning it seemed like a great ideal that I always supported, and I liked the result and what you have achieved.\nThe work and time dedicated to making this possible undoubtedly deserves to be remunerated and also everything that comes ahead.\n\n post by PVMihalache on Apr 29, 2024\n\n PVMihalache\n\n I thought this was a good idea and supported this since day one! Lets ensure the Alert Bot will do this amazing job perpetually and constantly highlight how good Across is \n\n Cryptohadari NFT Proposal\n\n post by neondaemon on Apr 30, 2024\n\n neondaemon\n\n I think this is a very worthwhile project that adds value to the protocol, especially as it can be used on social platforms to get more eyes on Across .\n\n post by ayoki on May 1, 2024\n\n ayoki\n\n I think this is a great proposal! Can’t wait to see Across Alerts fleshed out to include more bridge comparisons, etc. Very exciting\n\n post by bennidaytime on May 1, 2024\n\n bennidaytime\n\n Fully support this. Appreciate it the structure of this proposal and transparent budgeting. The alerts page adds so much value to the Across ecosystem.\n\n 1 month later\n\n Closed on May 31, 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 Cryptohadari NFT Proposal\n\n Active Proposals\n\n Active Proposals\n\n May 2024\n\n Across AI Assistant Proposal\n\n Ideas & Feedback\n\n Ideas & Feedback\n\n 11\n\n Dec 2024\n\n # Across Community Essentials Committee Renewal Proposal for Q2-Q3 2025\n\n Committees\n\n Committees\n\n 4\n\n Mar 2025\n\n Across AI Assistant\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 3\n\n Mar 2024\n\n Across Token Launch Proposal\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 214\n\n May 2022","tokens":3101,"squid":"spider-09","role":"Bridge Spider","at":1791348470860,"hash":"ab609b4a919a518e438fe4ce66c1dcb454ffb7d3"}
{"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":"spider-07","role":"Council Spider","at":1791348472526,"hash":"370ad2385d61130445de64db171bd8f8941d7618"}
{"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":"spider-07","role":"Council Spider","at":1791348482476,"hash":"de2ca1b8e34b315ccdb4a30fe17c0642333d0388"}
{"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":"spider-06","role":"Security Spider","at":1791348485991,"hash":"efa97aea33e0e7f7f199d8085f7412b3324fd751"}
{"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 8\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 82\n\n Jun 22\n\n What Solidity try/catch actually catches\n\n Code Wizards\n\n 1\n\n 121\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 Localization of The Solidity Documentation\n\n Documentation\n\n 0\n\n 83\n\n Jun 2\n\n Want to read more? Browse other topics in Code Wizards or view latest topics.","tokens":1582,"squid":"spider-05","role":"Spec Spider","at":1791348486025,"hash":"9fd5e136ce5bd620888b3f48fcc730592cdaa74a"}
{"url":"https://www.openzeppelin.com/security-services","domain":"openzeppelin.com","title":"OpenZeppelin | Security Services for Onchain Finance","text":"Security that powers the world’s onchain financial systemFrom smart contracts to blockchain infrastructure and digital assets, OpenZeppelin delivers institutional-grade security at every layer of onchain finance.Talk to a Security ExpertTrusted by leading financial institutions and blockchain protocols$250 Billion+ in Digital Assets Secured10,000+ Total Issues Uncovered700+ Critical & High Vulnerabilities UncoveredContinuous Security Program Security across the full lifecycleThe Continuous Security Program is our subscription-based engagement model that combines AI-native, agent-augmented workflows with a decade of OpenZeppelin security standards and expertise to deliver continuous security, compliance, and risk coverage across the full development lifecycle.We design each engagement around what you actually need. Services from across the security lifecycle (Architect, Build, Secure, Support) are bundled into the right combination for your company, in an ongoing engagement that adapts as your system evolves.Talk to a Security Expert Read the announcementArchitectValidate the design and identify risks before code is writtenTalk to an ExpertArchitecture ReviewValidate your system architecture early to prevent costly vulnerabilities later. Early-stage reviews of design diagrams, data flows, and upgrade mechanisms identify architectural weaknesses and improve security modularity before implementation, reducing reworks and accelerating audit readiness.Threat ModelingIdentify what attackers will target before they do. Adversarial analysis of your proposed architecture, trust boundaries, and failure modes, translated into tailored incident response processes and concrete risk priorities your team can act on.Standards & Regulatory ReviewMap your design against applicable standards and regulatory frameworks before you build. Reviews against ISO, NIST, MiCA, DORA, Basel, and regional frameworks confirm your system meets institutional and supervisory requirements from day one, reducing compliance risk later in the lifecycle.Applied ResearchCollaborate with OpenZeppelin's researchers to validate new mechanisms and architectures. We model your system under adversarial conditions, applying formal and empirical methods to ensure correctness, efficiency, and resilience at scale.Governance DesignDesign safe upgrade mechanisms, multisig policies, timelocks, and emergency procedures. We help you build governance that protects against operational mistakes and adversarial conditions, with clear procedures for the moments that matter most.Cryptographic Design ReviewValidate the choice and composition of cryptographic primitives in your system, including ZK and MPC schemes. Our cryptographers review your designs for soundness, efficiency, and resilience before implementation locks in costly mistakes.“Huge thanks to OpenZeppelin for being a great partner during the security audit — their expertise and constant support were invaluable for the entire engagement.”— Zach Short, Director of Blockchain Engineering at DTCCBuildReach production with secure foundationsTalk to an ExpertBlockchain Library DevelopmentExtend the security standards behind OpenZeppelin Contracts with custom reusable libraries built for your platform. Production-ready code derived from the patterns trusted by 9 of the top 10 stablecoins and 10 of the top 10 tokenized funds by market cap.Standards DevelopmentCo-author and implement the token, compliance, and governance standards that regulators and ecosystems will rely on. OpenZeppelin contributes to defining blockchain security standards, not just following them.Reference ImplementationsProduction-ready blueprints for tokenization, stablecoins, and institutional DeFi: working code, threat models, and institutional evaluation guides that compress time to market while preserving security and compliance posture.Custom Platform & Solution DevelopmentPurpose-built platforms and financial solutions engineered to your requirements. From custom L1s and L2s to tokenization platforms, tokenized funds, and product extensions, our team designs and builds production systems aligned to your business and regulatory needs, informed by our work with leading financial institutions and digital asset issuers.“With OpenZeppelin’s open source tools, Stellar developers can build faster while hardening security for their onchain apps.”— Jane Wang, Senior Product Manager, StellarSecureCatch vulnerabilities across code, infrastructure, and operationsTalk to an ExpertSmart Contract Security AuditSecure your onchain application code with the gold-standard smart contract audit. Our security researchers conduct a line-by-line review to identify vulnerabilities, logic flaws, and upgrade risks before deployment. Trusted since 2016 as the first smart contract auditing firm.Learn MoreBlockchain Infrastructure AuditValidate the integrity and reliability of your blockchain infrastructure. We assess consensus mechanisms, node software, bridges, and rollup components to identify design flaws and implementation risks across complex architectures like OP Stack, Geth, and Cosmos SDK.Learn moreZero-Knowledge Proof AuditEnsure the correctness and soundness of your ZK systems. Our cryptographers review circuits, verifiers, and proofs for implementation accuracy, efficiency, and security across zkEVMs, provers, and privacy protocols.Learn moreTechnical Risk Assessment (TRA)Evaluate stablecoins, tokenized assets, and digital securities with institutional-grade risk analysis. TRA assesses blockchain infrastructure, smart contract security, collateral quality, and operational controls, delivering standardized A-F ratings to support listing, custody, investment, and compliance decisions.Penetration TestingTest your systems under real-world attack conditions. Simulated attacks target your applications, APIs, backends, and networks to identify exploitable weaknesses before attackers find them. Receive a prioritized remediation roadmap with actionable steps to harden your security posture.Operational Security AssessmentAssess and strengthen the operational layer behind your smart contracts. We evaluate key management, deployment workflows, upgrade governance, and access controls to close gaps and harden the day-to-day processes that protect your systems and assets.Deployment VerificationVerify that what you deploy matches what was audited. Deployed bytecode, parameters, and configurations are validated to guarantee production alignment and prevent post-audit drift.“Collaborating with OpenZeppelin on our security audit was a productive and positive experience. We appreciated their thoroughness and attention to detail.”— Yoav Weiss, Security, Ethereum FoundationSupportKeep production systems secure over timeTalk to an ExpertContinuous Support & MaintenanceEnsure stability and security of foundational infrastructure components with guaranteed SLAs, proactive security patches, maintained versions, and direct engineering access.Custom Monitoring SolutionDetect threats in real time and respond proactively using tailored monitoring built on OpenZeppelin's expertise and tooling. All major blockchain networks supported.Dedicated Blockchain ArchitectEmbedded security leadership providing ongoing guidance, architecture reviews, and strategic support aligned to your roadmap. Your security advisor over time, not just your auditor.Security Training & EnablementBuild durable in-house security capability across your organization. From blockchain fundamentals and smart contract security workshops to incident response simulations and executive briefings, we deliver tailored programs that grow your team's expertise alongside your systems.“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, WisdomTreeEnterprise-Grade Compliance & CertificationsCCPA CompliantSOC2 CertifiedGDPR CompliantNeed a Custom Security Engagement?If you’re exploring a security need not listed here — from protocol-specific research to enterprise integrations — our team can help.Talk to a Security Expert","tokens":2070,"squid":"spider-06","role":"Security Spider","at":1791348495389,"hash":"3c3cad4d3a1240c5998a5b0399258bb700ac2009"}
{"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 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 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 121\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 121\n\n Jun 9\n\n Solidity 0.8.37 is released!\n\n Announcements\n\n 0\n\n 56\n\n 27d\n\n Want to read more? Browse other topics in Code Wizards or view latest topics.","tokens":1926,"squid":"spider-05","role":"Spec Spider","at":1791348496024,"hash":"56e94061f8c42fb15da14de794e6bbdf4202c534"}
{"url":"https://developers.jup.ag/docs/jupusd/juiced","domain":"developers.jup.ag","title":"JUICED Collateral Integration - Jupiter Developers","text":"​Overview\nJUICED is a yield-bearing SPL token issued by Jupiter Lend. It represents a deposit of JupUSD (a reserve-backed stablecoin pegged to $1) into the Jupiter Lend Earn protocol.\nJUICED follows a vault share model: the JUICED/JupUSD exchange rate increases monotonically as yield accrues. The rate never decreases.\nYield comes from two sources, both accrued into the token price:\n\nBorrowing interest from JupUSD utilisation on Jupiter Lend.\nT-bill yield from the reserves backing minted JupUSD (primarily Ethena’s USDtb, backed by BlackRock’s BUIDL), distributed through Jupiter’s rewards distributor.\n\nJUICED can be held, transferred, and used as collateral. This guide covers everything a protocol needs to integrate JUICED as a collateral asset.\n\n​Token details\nFieldValueNameJUICEDTickerJUICEDMint address7GxATsNMnaC88vdwd2t3mwrFuQwwGvmYPrUQ4D6FotXkStandardSPL TokenDecimals9Underlying assetJupUSD (JuprjznTrTSp2UFa3ZBUFgwdAmtZCq4MQCwysN55USD)\n\n​Pricing\nJUICED is contract-priced. Its value is derived from the onchain exchange rate against JupUSD:\nJUICED price = exchange_rate × JupUSD price ($1)\n\nJupUSD is pegged to $1 on the borrow side of Jupiter Lend, like other stablecoins.\n​Reading the exchange rate onchain\nThe Jupiter Lend program (Fluid) exposes two functions to read the current JUICED/JupUSD exchange rate:\nget_underlying_balance returns the underlying JupUSD balance for 1 share (1e9 lamports). This is the effective price of one JUICED token in JupUSD terms.\nget_exchange_price returns the exchange price of 1 share directly.\n​Rate update frequency\nThe exchange rate is updated on every interaction with the protocol (deposit, withdraw, borrow, repay). A weekly cron job ensures the rate is updated even if no interactions occur for an extended period.\n​Rate behaviour\nThe exchange rate is monotonically increasing. It does not decrease under normal protocol operation. This makes JUICED suitable as collateral with predictable value appreciation.\nAn additional Jupiter Lend oracle is available for pricing via CPI. Contact the Jupiter team for integration details.\n\n​Deposit and withdraw\nProtocols can deposit JupUSD to receive JUICED, or withdraw JupUSD by redeeming JUICED. Two integration paths are available: the Lend API (HTTP) and the Lend SDK (TypeScript).\n Lend API Lend SDKThe Lend API is the simplest integration path. It returns a signed transaction that you submit to the network.An API key is required. See API Key Setup for details.Deposit JupUSD to receive JUICEDconst response = await fetch(\"https://api.jup.ag/lend/v1/earn/deposit\", {\n method: \"POST\",\n headers: {\n \"Content-Type\": \"application/json\",\n \"x-api-key\": \"your-api-key\",\n },\n body: JSON.stringify({\n asset: \"JuprjznTrTSp2UFa3ZBUFgwdAmtZCq4MQCwysN55USD\", // JupUSD mint\n amount: \"1000000000\", // Amount in lamports (1 JupUSD = 1e9)\n signer: wallet.publicKey.toString(),\n }),\n});\nWithdraw JupUSD by redeeming JUICEDconst response = await fetch(\"https://api.jup.ag/lend/v1/earn/withdraw\", {\n method: \"POST\",\n headers: {\n \"Content-Type\": \"application/json\",\n \"x-api-key\": \"your-api-key\",\n },\n body: JSON.stringify({\n asset: \"JuprjznTrTSp2UFa3ZBUFgwdAmtZCq4MQCwysN55USD\", // JupUSD mint\n amount: \"1000000000\", // Amount in lamports\n signer: wallet.publicKey.toString(),\n }),\n});\nYou can also use the mint/redeem endpoints to operate in share amounts (JUICED units) instead of underlying amounts (JupUSD units):// Deposit by share amount\nconst response = await fetch(\"https://api.jup.ag/lend/v1/earn/mint\", {\n method: \"POST\",\n headers: {\n \"Content-Type\": \"application/json\",\n \"x-api-key\": \"your-api-key\",\n },\n body: JSON.stringify({\n asset: \"JuprjznTrTSp2UFa3ZBUFgwdAmtZCq4MQCwysN55USD\",\n signer: wallet.publicKey.toString(),\n shares: \"1000000000\", // JUICED shares to mint\n }),\n});\nFor the full API schema, see the Lend API Reference.The Lend SDK provides instruction-level access, useful for building custom transactions or CPI integrations.The Lend SDK uses @solana/web3.js v1. The JupUSD SDK (for minting and redeeming) uses @solana/kit (v2).Installationnpm install @jup-ag/lend\nDepositimport { getDepositIx } from \"@jup-ag/lend/earn\";\nimport { Connection, PublicKey } from \"@solana/web3.js\";\nimport { BN } from \"bn.js\";\n\nconst connection = new Connection(\"https://api.mainnet-beta.solana.com\");\n\nconst depositIx = await getDepositIx({\n amount: new BN(1000000000), // 1 JupUSD in lamports\n asset: new PublicKey(\"JuprjznTrTSp2UFa3ZBUFgwdAmtZCq4MQCwysN55USD\"),\n signer: signer.publicKey,\n connection,\n cluster: \"mainnet\",\n});\nWithdrawimport { getWithdrawIx } from \"@jup-ag/lend/earn\";\n\nconst withdrawIx = await getWithdrawIx({\n amount: new BN(1000000000),\n asset: new PublicKey(\"JuprjznTrTSp2UFa3ZBUFgwdAmtZCq4MQCwysN55USD\"),\n signer: signer.publicKey,\n connection,\n cluster: \"mainnet\",\n});\nCPI integrationFor protocols that need to deposit/withdraw within their own program instructions, use the context functions:import { getDepositContext, getWithdrawContext } from \"@jup-ag/lend/earn\";\nThese return the account contexts needed for Cross-Program Invocation. See the Lend Earn CPI documentation for full details.\n​Read functions\nThe SDK provides read functions to query token and position data:\nimport { getLendingTokens, getLendingTokenDetails } from \"@jup-ag/lend/earn\";\n\n// List all available lending tokens\nconst allTokens = await getLendingTokens({ connection });\n\n// Get details for JUICED (supply, rates, liquidity)\nconst juicedDetails = await getLendingTokenDetails({\n lendingToken: new PublicKey(\"7GxATsNMnaC88vdwd2t3mwrFuQwwGvmYPrUQ4D6FotXk\"),\n connection,\n});\n\nToken data is also available via the API:\nconst vaults = await (\n await fetch(\"https://api.jup.ag/lend/v1/earn/tokens\", {\n headers: { \"x-api-key\": \"your-api-key\" },\n })\n).json();\n\n​Withdrawal behaviour\nThere are no supply limits on the Earn protocol. Withdrawals use an Automated Debt Ceiling: the withdrawal allowance increases every block, creating a smoothing curve that prevents sudden large outflows. Under normal conditions, withdrawals are instant.\n\n​Program IDs\nProgramAddressJupiter Lend Earnjup3YeL8QhtSx1e253b2FDvsMNC87fDrgQZivbrndc9Jupiter Lend Borrowjupr81YtYssSyPt8jbnGuiWon5f6x9TcDEFxYe3BdziJupiter Lend Earn Rewardsjup7TthsMgcR9Y3L277b8Eo9uboVSmu1utkuXHNUKarJupiter Lend LiquidityjupeiUmn818Jg1ekPURTpr4mFo29p46vygyykFJ3wZCJupiter Lend Borrow Oraclejupnw4B6Eqs7ft6rxpzYLJZYSnrpRgPcr589n5Kv4oc\n\n​Risk considerations for integrators\nProtocols integrating JUICED as collateral should evaluate the following:\nExchange rate is monotonically increasing. Under normal protocol operation, the JUICED/JupUSD rate only goes up. This simplifies collateral valuation but does not eliminate all risk vectors.\nJupUSD peg dependency. JUICED value ultimately depends on JupUSD maintaining its $1 peg. JupUSD is backed by Ethena’s USDtb and USDC, held in an Anchorage Porto Wallet. A depeg event on JupUSD would directly impact JUICED valuation.\nT-bill yield is variable and can be diluted. T-bill yield is generated by the reserves backing minted JupUSD but distributed across all JUICED supply. If JUICED supply exceeds minted JupUSD supply, per-unit T-bill yield decreases. This does not affect the exchange rate direction (still increasing) but affects the rate of appreciation.\nWithdrawal liquidity. Withdrawals are subject to the Automated Debt Ceiling smoothing mechanism. In extreme scenarios (mass withdrawals, high utilisation), redemption to JupUSD may be delayed.\nSmart contract risk. JUICED depends on the Jupiter Lend program (Fluid). JupUSD has been audited by Offside Labs, Guardian, and Pashov. Jupiter Lend contracts have been audited by Zenith and Offside.\nThird-party dependencies. The yield chain involves Ethena (USDtb issuer), BlackRock (BUIDL fund), and Anchorage (custody). Changes in operations or regulatory status of these parties could affect JUICED yield or JupUSD backing.\n​Related\n\nJupUSD Mint & Redeem for minting and redeeming JupUSD\nLend Earn API for the full Earn API reference\nLend Earn SDK: Deposit for SDK deposit documentation\nLend Earn SDK: Withdraw for SDK withdrawal documentation\nLend Earn CPI for Cross-Program Invocation integration\nWas this page helpful?","tokens":2043,"squid":"spider-02","role":"Liquidity Spider","at":1791348500722,"hash":"121c88286cbfad67383342836d584be4e1dc115e"}
{"url":"https://forum.soliditylang.org/t/abi-encodecall-consistently-generates-cheaper-gas-than-abi-encodewithselector-is-this-by-design/3718","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 21\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 121\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 121\n\n Jun 9\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 Code Wizards or view latest topics.","tokens":1953,"squid":"spider-05","role":"Spec Spider","at":1791348507892,"hash":"1f31aa62ff1b833c43f04f91372fec920e38eaa6"}
{"url":"https://developers.jup.ag/docs/jupusd","domain":"developers.jup.ag","title":"Mint & Redeem - Jupiter Developers","text":"Direct minting and redemption is restricted to onboarded, whitelisted participants (KYC/KYB market makers and institutional partners). Retail users can access JupUSD permissionlessly through Jupiter Swap, Jupiter Mobile, and other Solana platforms.\n​Overview\nJupUSD is minted and redeemed through a dedicated Solana program. The program accepts collateral (USDC or USDtb), mints JupUSD 1:1 (minus fees), and handles the reverse operation for redemption.\nA 0.04% fee applies to all mint and redeem transactions through the program.\nThree integration methods are available:\n\nThe mint/redeem Solana program is source-available under the BSL licence: GitHub repository.\nFor real-time reserve composition, backing ratio, and audit data, see the JupUSD Transparency Page.\n​Key addresses\nFieldAddressJupUSD MintJuprjznTrTSp2UFa3ZBUFgwdAmtZCq4MQCwysN55USDProgramJUPUSDecMzAVgztLe6eGhwUBj1Pn3j9WAXwmtHmfbRrCustodian (reserves)B3q4P4XSmycvoHLaiEjchsGDafFPhKokvHvNRuW29N1yProgram reservesCkzLnD9r4d4ZZofsgNVo2VNunxDmte5YJ4vfAgMfBZNAMultisig (update authority)31wgH9Czzd3qgquTGxVxtxJuzBd8Fm4xEo8rPX7CNfhMAnchorage subaccount (custody)7i6ELgCKhZewDPg4P91w9FYpWKrSx7ptiNrUCrBarHff\n\n​Concepts\n​Benefactor\nA benefactor is a wallet authorised to mint and redeem JupUSD through the program. Every benefactor is linked to a KYC (individual) or KYB (entity) verification. If your benefactor account is disabled, the transaction will fail with the BenefactorDisabled error.\n​Oracle\nThe JupUSD program uses oracle price feeds from Pyth, Chainlink, and Chaos Labs. Oracles serve two purposes in the mint/redeem flow:\n\nPeg validation: verify that the collateral (USDC, USDtb) has not depegged before allowing the operation.\nExchange rate: the oracle price is used in the calculation of the mint/redeem exchange rate.\n\nThere is no fallback mechanism. If the Pyth feed is unavailable or rejected (confidence too wide, stale data), the transaction will fail with PriceConfidenceTooWide or NoValidPrice.\nOracle validation parameters are configured per vault. You can inspect the current configuration for each vault onchain. For example, the USDC vault configuration: 7JnALHo2bFuKsgkNymiqJwt228jy3my99CnfF75QD9oj.\n​Rate limiting\nMint and redeem operations are rate-limited at the config (global), vault, and benefactor levels.\nTypical benefactor limits:\nWindowMint limitRedeem limit1 hour40M10M1 day100M100M\nThese values can vary per benefactor. If you encounter MintLimitExceeded or RedeemLimitExceeded, wait for the current window to reset or contact the team to request higher limits.\n\n​SDK\nThe TypeScript SDK provides programmatic access to mint and redeem instructions. An IDL is also available for non-TypeScript integrations: view IDL on Solscan.\n​Installation\nnpm install @jup-ag/jup-usd-sdk\nyarn add @jup-ag/jup-usd-sdk\npnpm add @jup-ag/jup-usd-sdk\n\nAlternatively, install from the GitHub repository.\n\n​Mint\nThe Mint instruction transfers collateral from your wallet to the JupUSD custodian and mints new JupUSD tokens to the provided token account.\n​Key parameters\nParameterDescriptionamountInAmount of collateral to deposit.minAmountOutMinimum amount of JupUSD to receive. If the minted amount falls below this value, the transaction reverts with SlippageToleranceExceeded.\nYour wallet must be a registered benefactor to call the Mint instruction. If you are not onboarded, the transaction will fail.\n​Oracle accounts\nEach vault requires a specific set of Pyth oracle accounts. When building the instruction:\n\nInclude all non-empty oracle accounts from the vault.\nPreserve the exact order in which they are stored onchain.\nPassing incorrect or incomplete oracle accounts will cause the transaction to fail.\n\n​Example\nimport { AccountRole, address } from \"@solana/kit\";\nimport {\n findConfig,\n fetchVault,\n fetchConfig,\n findVault,\n getMintInstructionAsync,\n JUP_STABLE_PROGRAM_ADDRESS,\n} from \"@jup-ag/jup-usd-sdk\";\nimport { findAssociatedTokenPda } from \"@solana-program/token\";\n\n// Wallet must be a registered benefactor\nconst userSigner = /* your wallet signer */;\n\n// Benefactor address: provided to you during onboarding (KYC/KYB)\nconst benefactorAddress = address(\"YOUR_BENEFACTOR_ADDRESS\");\n\n// Collateral mint (e.g. USDC)\nconst USDC = address(\"EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v\");\n\n// --- Derive program accounts ---\n\n// Config PDA\nconst configAddress = await findConfig();\nconst configAccount = await fetchConfig(rpc, configAddress);\n\n// Vault PDA (derived from collateral mint)\nconst vaultAddress = await findVault(USDC);\nconst vaultAccount = await fetchVault(rpc, vaultAddress);\n\n// --- Collect required oracle accounts ---\nconst remainingAccounts = vaultAccount.data.oracles\n .filter((oracle) => oracle.__kind !== \"Empty\")\n .map((oracle) => ({\n role: AccountRole.READONLY,\n address: address(oracle.fields[0].account),\n }));\n\n// --- Mint instruction (deposit collateral -> receive JupUSD) ---\nconst mintIx = await getMintInstructionAsync({\n user: userSigner,\n userCollateralTokenAccount,\n userLpTokenAccount,\n config: configAddress,\n authority: configAccount.data.authority,\n lpMint: configAccount.data.mint,\n vault: vaultAddress,\n vaultMint: configAccount.data.mint,\n custodian: vaultAccount.data.custodian,\n custodianTokenAccount: await findAssociatedTokenPda({\n mint: vaultAccount.data.mint,\n owner: vaultAccount.data.custodian,\n tokenProgram: vaultAccount.data.token_program,\n }),\n benefactor: benefactorAddress,\n lpTokenProgram: configAccount.data.tokenProgram,\n vaultTokenProgram: configAccount.data.tokenProgram,\n program: JUP_STABLE_PROGRAM_ADDRESS,\n amount: amountIn, // Collateral amount\n minAmountOut, // Slippage protection\n});\n\n// Append oracle accounts in the correct order\nmintIx.accounts.push(...remainingAccounts);\n\n​Redeem\nThe Redeem instruction burns JupUSD from your token account and withdraws the corresponding collateral from the vault back to your wallet.\n​Key parameters\nParameterDescriptionamountInAmount of JupUSD to redeem (burn).minAmountOutMinimum amount of collateral to receive. If the returned amount falls below this value, the transaction reverts with SlippageToleranceExceeded.\n​Example\nimport { AccountRole, address } from \"@solana/kit\";\nimport {\n findConfig,\n fetchVault,\n fetchConfig,\n findVault,\n getRedeemInstructionAsync,\n JUP_STABLE_PROGRAM_ADDRESS,\n} from \"@jup-ag/jup-usd-sdk\";\n\n// Wallet must be a registered benefactor\nconst userSigner = /* your wallet signer */;\n\n// Benefactor address: provided to you during onboarding (KYC/KYB)\nconst benefactorAddress = address(\"YOUR_BENEFACTOR_ADDRESS\");\n\n// Collateral mint (e.g. USDC)\nconst USDC = address(\"EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v\");\n\n// --- Derive program accounts ---\n\n// Config PDA\nconst configAddress = await findConfig();\nconst configAccount = await fetchConfig(rpc, configAddress);\n\n// Vault PDA (derived from collateral mint)\nconst vaultAddress = await findVault(USDC);\nconst vaultAccount = await fetchVault(rpc, vaultAddress);\n\n// --- Collect required oracle accounts ---\nconst remainingAccounts = vaultAccount.data.oracles\n .filter((oracle) => oracle.__kind !== \"Empty\")\n .map((oracle) => ({\n role: AccountRole.READONLY,\n address: address(oracle.fields[0].account),\n }));\n\n// --- Redeem instruction (burn JupUSD -> receive collateral) ---\nconst redeemIx = await getRedeemInstructionAsync({\n user: userSigner,\n userLpTokenAccount, // JupUSD token account\n userCollateralTokenAccount, // Destination collateral account\n config: configAddress,\n authority: configAccount.data.authority,\n lpMint: configAccount.data.mint,\n vault: vaultAddress,\n vaultTokenAccount, // Vault collateral token account\n vaultMint: vaultAccount.data.mint,\n benefactor: benefactorAddress,\n lpTokenProgram: configAccount.data.tokenProgram,\n vaultTokenProgram: configAccount.data.tokenProgram,\n program: JUP_STABLE_PROGRAM_ADDRESS,\n amount: amountIn, // Amount of JupUSD to burn\n minAmountOut, // Slippage protection\n});\n\n// Append oracle accounts in the correct order\nredeemIx.accounts.push(...remainingAccounts);\n\n​Web API\nThe JupUSD Web API provides HTTP endpoints for minting and redeeming without using the SDK directly.\nBase URL: https://api.jupusd.money/\nFull API documentation is available at api.jupusd.money.\nAccess to the Web API requires a registered benefactor wallet, the same as for SDK and UI operations.\n\n​UI\nThe JupUSD web interface provides a graphical way to mint and redeem without writing code. It is available at: jupusd.money/mint.\nYou must be correctly onboarded before using the UI. If you see a warning message, it means you are using the wrong wallet address or there was an issue during onboarding.\n​Mint via UI\n1Connect your walletConnect a whitelisted Solana wallet (e.g. Jupiter Wallet, Phantom, Solflare).2Enter amountEnter the desired USDC amount to provide as collateral. The UI will compute a quote and display the expected JupUSD you will receive.3Approve and mintClick “Approve & Mint.” Your wallet will prompt you to confirm the transaction.4ConfirmConfirm the transaction in your wallet. A transaction receipt link will be provided once complete.\n​Redeem via UI\n1Connect your walletEnsure your whitelisted wallet is connected.2Navigate to RedeemSwitch to the “Redeem” tab.3Enter amountEnter the amount of JupUSD you wish to burn. The UI will calculate the expected collateral return.4RedeemClick “Redeem” and approve the transaction in your wallet.5ConfirmConfirmation of the redemption will appear, along with a link to the transaction on the explorer.\n\n​Error reference\nThe following errors may occur when calling the Mint or Redeem instructions.\nErrorWhen it happensHow to fixInvalidLPMint / InvalidVaultMintThe JupUSD or vault mint account does not match the config or vault state.Fetch the config and vault accounts onchain and pass the exact mint accounts recorded there.InvalidAuthorityThe authority PDA does not match the config.Pass the correct authority stored in the config account.InvalidVaultTokenAccountThe vault token account does not match the vault state.Pass the vault or custodian token account recorded on the vault.InvalidCustodianThe custodian account does not match the vault’s configured custodian.Use the custodian pubkey stored on the vault account.BenefactorDisabledThe benefactor is currently disabled.Your account is whitelisted but not currently approved to mint, or access has been disabled. Contact the team.VaultDisabledThe vault is not enabled for minting or redeeming.Wait for operators to enable the vault.ProtocolPausedGlobal mint/redeem operations are paused.Wait for protocol admins to re-enable mint/redeem.MintLimitExceeded / RedeemLimitExceededA per-window rate limit was exceeded (config, vault, or benefactor level).Retry after the rate-limit window resets, or request higher limits from the team.ZeroAmountInput amount is zero, or the computed output rounds to zero.Submit a non-zero amount large enough to produce output after fees.SlippageToleranceExceededComputed output is lower than minAmountOut.Increase slippage tolerance or retry when pricing is more favourable.PriceConfidenceTooWidePyth oracle confidence interval or spread is too wide.Retry once oracle confidence tightens. Verify correct oracle accounts were supplied.NoValidPriceNo Pyth oracle price passed validation.Check oracle health and retry once price feeds are reporting valid data.MathOverflowArithmetic overflow during price or amount calculation.This should not happen under normal conditions. Contact the team.VaultIsDryRedeem request exceeds the vault’s available collateral balance.The program vault balance is too low. Wait for it to be replenished or contact the team.\n​Related\n\nJupUSD Transparency Page for real-time reserve and backing data\nJUICED Collateral Integration for integrating JUICED as a collateral asset\nJupiter Lend Earn for the underlying Earn protocol\nWas this page helpful?","tokens":2962,"squid":"spider-02","role":"Liquidity Spider","at":1791348510760,"hash":"ef5b5a9c2918c9d9f1759e464a1a374e05bde0aa"}
{"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 21\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 121\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 121\n\n Jun 9\n\n Solidity Developer Survey 2025 Results\n\n Announcements\n\n 2\n\n 148\n\n Apr 27\n\n Want to read more? Browse other topics in Code Wizards or view latest topics.","tokens":1954,"squid":"spider-05","role":"Spec Spider","at":1791348518006,"hash":"0c2017c74cc55b4ec83786c770476b4f98ee8fa8"}
{"url":"https://developers.jup.ag/docs/lend/oracles","domain":"developers.jup.ag","title":"Oracles - Jupiter Developers","text":"The Oracle Program delivers accurate price data to the protocol by integrating with trusted oracle providers. It calculates exchange rates by combining multiple price sources in a structured sequence, ensuring reliable asset valuations.\nNOTEThe Oracle program has been audited by Zenith and Offside.Oracle Program Address: jupnw4B6Eqs7ft6rxpzYLJZYSnrpRgPcr589n5Kv4oc\n​Hop-Based Oracle System\nThe system computes exchange rates by processing prices from up to four sources in a sequential chain. Each source contributes to the final rate through multiplication or division, with the option to invert values as needed. The output of each hop becomes the input for the next.\nFor example, to derive the JUPSOL/SOL rate, the system combines JUPSOL/USD and SOL/USD feeds, inverting the latter to obtain USD/SOL.\n​Supported source types\nSourceDescriptionAccounts per hopPythPyth push oracle feeds1ChainlinkChainlink Solana feeds1RedstoneRedstone oracle feeds1StakePoolSPL Stake Pool (Jito, Marinade, etc.)1MsolPoolMarinade mSOL pool state1SinglePoolSPL Single Pool (Helius, Jupiter, Nansen, Emerald, Shift, Kiln)3 (stake, mint, stake program)JupLendJupLend fToken exchange rate4 (Lending, TokenReserve, RateModel, FTokenMint)\nThis design enables the system to:\n\nAggregate rates from multiple feeds and providers, reducing dependency on any single source\nSupport diverse asset types including LSTs, stablecoins, and protocol tokens\nValidate data integrity at each step\n\n​Validation\n​Freshness\nOperation typeMax ageUser operations (supply, borrow, repay, withdraw)600 seconds (10 minutes)Liquidations7200 seconds (2 hours)\nPyth and Redstone use Unix timestamp freshness. Chainlink uses slot-based freshness (≈400 ms per slot).\n​Confidence (Pyth only)\nPyth feeds include a confidence interval. The oracle rejects feeds whose confidence exceeds:\nOperation typeMax confidenceUser operations2% of priceLiquidations4% of price\nOnly Pyth validates confidence. Other sources (Chainlink, Redstone, StakePool, MsolPool, SinglePool, JupLend) either derive rates on-chain or only enforce freshness; they do not expose or check a confidence interval.\n​Providers\nProviderSourceUse casePythPythSpot prices (SOL, ETH, BTC, JLP, etc.)ChainlinkChainlinkSOL/USD, WBTC/USD, EURC/USDRedstoneRedstoneAdditional price feedsMarinadeMsolPoolmSOL/SOLJitoStakePoolJITOSOL/SOLSPL Single PoolSinglePoolStaked SOL (Helius, Jupiter, Nansen, Emerald, Shift, Kiln)JupLendJupLendfToken exchange rates (e.g., JUPUSD)\n​Oracle Verification Script\nUse this script to verify oracle prices by providing a nonce. The oracle PDA is derived from the oracle seed and a 16-bit nonce.\nFor oracles that use SinglePool or JupLend sources, remainingAccounts must include 3 or 4 consecutive source accounts per hop respectively, as configured in the oracle. The script below works for simple oracles (e.g., single Pyth or Chainlink feed).\nimport { Program, AnchorProvider } from \"@coral-xyz/anchor\";\nimport { Connection, PublicKey } from \"@solana/web3.js\";\nimport axios from \"axios\";\n\nconst NONCE = 2; // Change this to test different oracles\nconst ORACLE_PROGRAM_ID = new PublicKey(\"jupnw4B6Eqs7ft6rxpzYLJZYSnrpRgPcr589n5Kv4oc\");\nconst IDL_URL = \"https://raw.githubusercontent.com/jup-ag/jupiter-lend/refs/heads/main/target/idl/oracle.json\";\nconst RPC_URL = \"<RPC URL>\";\n\nclass OracleReader {\n private program: Program;\n\n private constructor(program: Program) {\n this.program = program;\n }\n\n static async create(): Promise<OracleReader> {\n const connection = new Connection(RPC_URL);\n const response = await axios.get(IDL_URL);\n const idl = response.data;\n\n const wallet = {\n signTransaction: () => { throw new Error(\"Read-only\"); },\n signAllTransactions: () => { throw new Error(\"Read-only\"); },\n publicKey: new PublicKey(\"11111111111111111111111111111111\"),\n };\n\n const provider = new AnchorProvider(connection, wallet, {});\n const program = new Program(idl, provider);\n return new OracleReader(program);\n }\n\n private findOraclePDA(nonce: number): PublicKey {\n const [pda] = PublicKey.findProgramAddressSync(\n [\n Buffer.from(\"oracle\"),\n Buffer.from(new Uint8Array(new Uint16Array([nonce]).buffer)),\n ],\n ORACLE_PROGRAM_ID\n );\n return pda;\n }\n\n async getPrice(nonce: number) {\n const oraclePDA = this.findOraclePDA(nonce);\n const oracleAccount = await this.program.account.oracle.fetch(oraclePDA);\n\n const remainingAccounts = oracleAccount.sources.map((source: any) => ({\n pubkey: source.source,\n isWritable: false,\n isSigner: false,\n }));\n\n const price = await this.program.methods\n .getExchangeRateOperate(nonce)\n .accounts({ oracle: oraclePDA })\n .remainingAccounts(remainingAccounts)\n .view();\n\n return {\n nonce,\n oraclePDA: oraclePDA.toString(),\n price: price.toString(),\n sources: oracleAccount.sources.length\n };\n }\n}\n\nasync function main() {\n const reader = await OracleReader.create();\n const result = await reader.getPrice(NONCE);\n console.log(result);\n}\n\nmain().catch(console.error);\nWas this page helpful?","tokens":1240,"squid":"spider-02","role":"Liquidity Spider","at":1791348520875,"hash":"bbec311c0c9d42019ba4650f1797277697a6aedc"}
{"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":"spider-06","role":"Security Spider","at":1791348527925,"hash":"e3284a7fedfec3051ca7d840608a5f112f0db9c8"}
{"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 597\n\n Feb 2021\n\n Eager require evaluation is unexpected\n\n 2\n\n 94\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 192\n\n Jun 9\n\n Ora: comptime-first, solver-in-workflow EVM language\n\n 3\n\n 182\n\n Feb 28\n\n The assembly/solidity distinction was a mistake, don’t repeat in Solidity Core!\n\n 5\n\n 379\n\n Feb 26\n\n Can a Solidity library be instantiated using new?\n\n 1\n\n 113\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 463\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 453\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":"spider-05","role":"Spec Spider","at":1791348528290,"hash":"ffbe5b977f55b7649b9b678b7f60842871c2c98c"}
{"url":"https://developers.jup.ag/docs/lend/architecture","domain":"developers.jup.ag","title":"Core Architecture - Jupiter Developers","text":"Jupiter Lend is built on three core programs: Liquidity (the shared lending engine), Lending (Earn), and Vaults (Borrow). Lending and Vaults do not hold tokens directly. They CPI into Liquidity, which holds all underlying assets and tracks supply and borrow positions.\n​Three-program design\nProgramPurposeProgram IDLiquidityCore layer: token vaults, exchange prices, utilisation, ratesjupeiUmn818Jg1ekPURTpr4mFo29p46vygyykFJ3wZCLendingEarn: deposit assets, mint jlTokens, supply into Liquidityjup3YeL8QhtSx1e253b2FDvsMNC87fDrgQZivbrndc9VaultsBorrow: collateralize, borrow, liquidate, supply/borrow via Liquidityjupr81YtYssSyPt8jbnGuiWon5f6x9TcDEFxYe3Bdzi\n\n​Liquidity (core layer)\nLiquidity serves as the foundational layer, owning all token vaults and custodying every deposited and borrowed asset. User-facing protocols never interact with tokens directly; they always make CPI calls into Liquidity to handle supply and borrow operations.\n​Key state\nAccountPurposeTokenReservePer-mint: vault, exchange prices, totals, utilisation, rate configUserSupplyPositionPer (mint, protocol): supply amount, withdrawal limit, statusUserBorrowPositionPer (mint, protocol): borrow amount, debt ceiling, statusRateModelInterest rate curve driven by utilisation\n​Protocol registration\nProtocols (Lending, Vaults) must be registered via init_new_protocol(supply_mint, borrow_mint, protocol):\n\nLending: supply mint only (Earn supplies into Liquidity, no borrow)\nVaults: supply mint (collateral) and borrow mint (debt)\n\n​Operate flow\n\npre_operate(mint): marks the interacting protocol and timestamp on TokenReserve\nCaller moves tokens into the Liquidity vault (via SPL transfer)\noperate(supply_amount, borrow_amount, withdraw_to, borrow_to, transfer_type): updates exchange prices, UserSupplyPosition/UserBorrowPosition, TokenReserve totals, and performs transfers\n\nExchange prices and rates are updated during operate, so interest accrues on every interaction.\n\n​Lending (Earn)\nEarn lets users deposit assets and receive jlTokens (shares). Deposits are supplied into Liquidity, and jlTokens represent a share of the pool with accrued interest and rewards.\n​Key state\nAccountPurposeLendingAdminFactory: authority, liquidity_program, rebalancer, authsLendingPer-mint pool: mint, jl_token_mint, token_reserves_liquidity, supply_position_on_liquidity, exchange prices\n​User flow\n\nDeposit: User transfers tokens → Lending CPIs Liquidity pre_operate + operate(supply) → mints jlTokens\nWithdraw/Redeem: Burns jlTokens → CPIs Liquidity operate(withdraw) → user receives underlying\n\nThe protocol signer for Liquidity CPI is the Lending PDA (not the user). Each Lending pool has a single UserSupplyPosition on Liquidity for that mint. The rewards rate model (separate program) adjusts the jlToken exchange price to include rewards on top of base yield.\n​CPI summary\nCallerSignerSupply positionBorrow positionLendingLending PDALending PDA (1 per mint)None\n\n​Vaults (Borrow)\nBorrow vaults are collateralized lending markets. Each vault has a supply token (collateral) and a borrow token (debt). Users deposit collateral, borrow against it, and can be liquidated if collateral falls below the liquidation threshold. Positions are represented as NFTs.\n​Key state\nAccountPurposeVaultConfigParams: supply_token, borrow_token, oracle, collateral_factor, liquidation_threshold, rebalancerVaultStateRuntime: total_supply, total_borrow, topmost_tick, absorbed debt/collateralPositionUser position: vault_id, tick, supply_amount, debt, liquidation statusBranchLiquidation structure: minima tick, debt factor, statusTickPrice-ratio ticks for collateralization\n​Tick-based pricing\nVaults use tick-based pricing: collateralization is computed from a price-ratio tick rather than a simple LTV. Collateral factor is derived from tick ratio. Branches track liquidation state and merge positions when liquidated.\n​User flow\n\ninit_position: create Position + position mint NFT\noperate: deposit/withdraw collateral, borrow/repay debt\nliquidate: liquidate undercollateralized positions\nrebalance: rebalancer supplies/borrows on Liquidity to match vault demand\n\nThe protocol signer for Liquidity CPI is the VaultConfig PDA. Each vault has both a UserSupplyPosition (collateral) and a UserBorrowPosition (debt) on Liquidity. The Oracle program provides prices for collateral valuation and liquidation checks.\n​CPI summary\nCallerSignerSupply positionBorrow positionVaultsVaultConfig PDAVaultConfig PDAVaultConfig PDA\n\n​Shared data flow\nBoth Lending and Vaults share the same Liquidity layer:\nShared accountUsed byRoleTokenReserveBothAggregated supply/borrow per mintUserSupplyPositionBothPer-protocol supplyUserBorrowPositionVaultsPer-protocol borrowVault (ATA)BothLiquidity holds all tokensRateModelBothInterest rate parameters\n​Deposit (Earn)\nUser → Lending.deposit() → transfer tokens to Liquidity vault\n → pre_operate (Lending PDA)\n → operate(supply, borrow=0)\n → mint jlTokens\n\n​Borrow (Vaults)\nUser → Vaults.operate() → transfer collateral to vault\n → pre_operate (VaultConfig PDA)\n → operate(supply=collateral, borrow=debt)\n → update Position / Branch / Tick\n\n​Dependency graph\nProgramDepends onLendingLiquidity (CPI), Lending Rewards Rate ModelVaultsLiquidity (CPI), OracleLiquidityStandaloneOracleStandalone\n\n​Related docs\n\nUnifying Liquidity: Liquidity layer overview and key features\nEarn Overview: deposit/withdraw mechanics\nBorrow Overview: vaults, positions, liquidations\nLiquidity analytics: market data, utilisation, exchange prices\nOracles: price feeds for vaults\nProgram addresses: program IDs and IDL\nWas this page helpful?","tokens":1398,"squid":"spider-02","role":"Liquidity Spider","at":1791348530862,"hash":"9b7779422ce6eba7fc1d574b80d78d198452e603"}
{"url":"https://forum.soliditylang.org/t/about-the-language-design-category/18/1","domain":"forum.soliditylang.org","title":"About the Language Design category - Language Design - 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 Language Design category \n\n Language Design\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 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 of the ideas/proposals and define them further. As soon as proposals get more tangible their implementation will also be discussed in the Solidity GitHub organisation in the form of GitHub issues.\nA vague “I don’t like how X is working” might get a discussion started, but keep in mind that more specific the proposed solutions are, the more likely they are to be adopted into the language.\nExamples of topics that could fit the Language Design category:\n\n“Change the way inheritance works”\n“Introduce a switch statement”\n\n You can follow the implementation status of new features in the Solidity Github project. Issues 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 see the upcoming changes for the next breaking release by changing from the default branch (develop) to the breaking branch.\n\n Low level interactions\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 Eager require evaluation is unexpected\n\n Language Design\n\n 2\n\n 94\n\n Aug 4\n\n The assembly/solidity distinction was a mistake, don’t repeat in Solidity Core!\n\n Language Design\n\n 5\n\n 379\n\n Feb 26\n\n Ora: comptime-first, solver-in-workflow EVM language\n\n Language Design\n\n 3\n\n 182\n\n Feb 28\n\n Core Solidity: Feedback from porting Uniswap v2\n\n Language Design\n\n 2\n\n 192\n\n Jun 9\n\n Can a Solidity library be instantiated using new?\n\n Language Design\n\n 1\n\n 113\n\n Oct 2025\n\n Want to read more? Browse other topics in Language Design or view latest topics.","tokens":1334,"squid":"spider-05","role":"Spec Spider","at":1791348540569,"hash":"e62859fa4e4ed64e8c0b1bf7056d61062a8c993e"}
{"url":"https://developers.jup.ag/docs/lend/borrow","domain":"developers.jup.ag","title":"Borrow Overview - Jupiter Developers","text":"Jupiter Borrow is the collateralised borrowing side of Jupiter Lend. Users create positions by depositing collateral into vaults, then borrow against that collateral. Each vault has a supply token (collateral) and a borrow token. Positions are represented as NFTs, and the protocol tracks collateral, debt, tick-based pricing, and liquidation status. Users can deposit, borrow, repay, withdraw, and liquidators can liquidate undercollateralised positions. Integration is done via the Jupiter Lend SDK for transactions and the Read SDK for vault and position data.\n\n​About Borrow\nWhat is Jupiter Borrow?Borrow Vaults are a known standard mechanism for locking collateral and borrowing debt. Jupiter Lend utilises this familiar single asset - single debt vault approach. Jupiter Lend takes borrow vaults to the next level by being the most capital efficient and optimised protocol enabling up to 95% LTV on collateral.How does Jupiter Lend achieve such high LTV?Jupiter borrow vaults have the most advanced liquidation mechanisms, and are able to provide the highest LTVs in the market. The protocol easily removes bad debt and enables the most gas efficient liquidation mechanism in DeFi.What happens if I am liquidated?When your position is liquidated, a portion of your collateral is sold to repay your debt and return your position to a safe state. In addition to selling a part of your collateral, a liquidation penalty is also charged.What is the Max Liquidation Threshold?While the Liquidation Threshold determines when a vault can be liquidated, the protocol also has a hard ceiling for liquidation. When a vault passes the max liquidation threshold it is entirely (100%) liquidated automatically.My vault passed the liquidation threshold but has not been liquidated - will I be liquidated?Yes, your position is still at risk of being liquidated. Once your position passes the threshold it can be liquidated, but it may not happen immediately. If your position is still at risk you can take the time now to unwind/reduce your risk ratio to make your position safe and prevent a liquidation event.\n\n​Key components of Borrow integration\n\nFor complete examples of operations, see Create position, Deposit, Borrow, Repay, Withdraw, and Liquidate.\n\n​Ways to fetch data\n\n​Key data structures\n// Vault config (per vault)\ntype VaultConfig = {\n vaultId: number;\n supplyToken: PublicKey; // Collateral mint\n borrowToken: PublicKey; // Borrow asset mint\n oracle: PublicKey;\n collateralFactor: number;\n liquidationThreshold: number;\n liquidationPenalty: number;\n borrowFee: number;\n // ...\n};\n\n// User position (raw on-chain)\ntype UserPosition = {\n vaultId: number;\n nftId: number;\n positionMint: PublicKey;\n tick: number;\n tickId: number;\n supplyAmount: BN;\n dustDebtAmount: BN;\n isSupplyOnlyPosition: number | boolean;\n // ...\n};\n\n// Decoded position (with exchange prices)\ntype NftPosition = {\n nftId: number;\n owner: PublicKey;\n supply: BN;\n borrow: BN;\n dustBorrow: BN;\n tick: number;\n tickId: number;\n isLiquidated: boolean;\n // ...\n};\n\n​Vault and position model\n\nVault: A market with a supply token (collateral) and borrow token. Each vault has config (oracle, risk params), state (totals, exchange prices), and limits (withdraw, borrow availability).\nPosition: A user’s collateralised borrow. Identified by vault ID and position (NFT) id. Tracks collateral (supply), debt (borrow), tick, and liquidation status.\nTick: Price ticks determine the borrow amount for a given collateral amount. Positions use tick-based pricing for leverage.\n\n​Relevant links\nWas this page helpful?","tokens":895,"squid":"spider-02","role":"Liquidity Spider","at":1791348541028,"hash":"d982fcb009e1c0ae023f7b48710d77352bd2ac46"}
{"url":"https://developers.jup.ag/docs/lend/earn/api","domain":"developers.jup.ag","title":"Earn API (Beta) - Jupiter Developers","text":"API REFERENCETo fully utilize the Lend API, check out the Lend API Reference.\n​Prerequisite\nDependenciesnpm install @solana/web3.js@1 # Using v1 of web3.js instead of v2\nnpm install dotenv # If required for wallet setup\nRPCSet up RPCNOTESolana provides a default RPC endpoint. However, as your application grows, we recommend you to always use your own or provision a 3rd party provider’s RPC endpoint such as Helius or Triton.import { Connection } from \"@solana/web3.js\";\n\nconst connection = new Connection('https://api.mainnet-beta.solana.com');\nWalletSet up Development WalletNOTE\nYou can paste in your private key for testing purposes but this is not recommended for production applications.\nIf you want to store your private key in the project directly, you can do it via a .env file.\nTo set up a development wallet via .env file, you can use the following script.// index.js\nimport { Keypair } from '@solana/web3.js';\nimport dotenv from 'dotenv';\nrequire('dotenv').config();\n\nconst wallet = Keypair.fromSecretKey(bs58.decode(process.env.PRIVATE_KEY || ''));\n# .env\nPRIVATE_KEY=\"\"\nTo set up a development wallet via a wallet generated via Solana CLI, you can use the following script.import { Keypair } from '@solana/web3.js';\nimport fs from 'fs';\n\nconst privateKeyArray = JSON.parse(fs.readFileSync('/Path/To/.config/solana/id.json', 'utf8').trim());\nconst wallet = Keypair.fromSecretKey(new Uint8Array(privateKeyArray));\nTransaction Sending Exampletransaction.sign([wallet]);\nconst transactionBinary = transaction.serialize();\nconsole.log(transactionBinary);\nconsole.log(transactionBinary.length);\nconst blockhashInfo = await connection.getLatestBlockhashAndContext({ commitment: \"finalized\" });\n\nconst signature = await connection.sendRawTransaction(transactionBinary, {\n maxRetries: 0,\n skipPreflight: true,\n});\n\nconsole.log(`Transaction sent: https://solscan.io/tx/${signature}`);\n\ntry {\n const confirmation = await connection.confirmTransaction({\n signature,\n blockhash: blockhashInfo.value.blockhash,\n lastValidBlockHeight: blockhashInfo.value.lastValidBlockHeight,\n }, \"confirmed\");\n\n if (confirmation.value.err) {\n console.error(`Transaction failed: ${JSON.stringify(confirmation.value.err)}`);\n console.log(`Examine the failed transaction: https://solscan.io/tx/${signature}`);\n } else {\n console.log(`Transaction successful: https://solscan.io/tx/${signature}`);\n }\n} catch (error) {\n console.error(`Error confirming transaction: ${error}`);\n console.log(`Examine the transaction status: https://solscan.io/tx/${signature}`);\n};\n\n​Deposit and Withdraw\nUsing the Deposit or Withdraw endpoint, the user can do so based on the amount of assets to be deposited/withdrawn.\nUSAGE STEPS1User chooses the token.2User chooses the amount of assets to deposit or withdraw in the specific token mint.3Post request to get the transaction.4User sign and send the transaction to the network.5The mint authority mints/burns the vault tokens to/from the user.\nconst depositTransactionResponse = await (\n await (\n await fetch('https://api.jup.ag/lend/v1/earn/deposit', {\n method: 'POST',\n headers: {\n 'Content-Type': 'application/json',\n 'x-api-key': 'your-api-key',\n },\n body: JSON.stringify({\n asset: mint,\n amount: '100000',\n signer: wallet.publicKey,\n })\n })\n )\n);\n\nconst withdrawTransactionResponse = await (\n await (\n await fetch('https://api.jup.ag/lend/v1/earn/withdraw', {\n method: 'POST',\n headers: {\n 'Content-Type': 'application/json',\n 'x-api-key': 'your-api-key',\n },\n body: JSON.stringify({\n asset: mint,\n amount: '100000',\n signer: wallet.publicKey,\n })\n })\n )\n);\n\n​Mint and Redeem\nUsing the Mint or Redeem endpoint, the user can do so based on the number shares to be minted/redeemed.\nUSAGE STEPS1User chooses the token.2User chooses the number of shares to deposit or withdraw in the specific token mint.3Post request to get the transaction.4User sign and send the transaction to the network.5The mint authority mints/burns the vault tokens to/from the user.\nconst mintTransactionResponse = await (\n await (\n await fetch('https://api.jup.ag/lend/v1/earn/mint', {\n method: 'POST',\n headers: {\n 'Content-Type': 'application/json',\n 'x-api-key': 'your-api-key',\n },\n body: JSON.stringify({\n asset: mint,\n signer: wallet.publicKey,\n shares: '100000',\n })\n })\n )\n);\n\nconst redeemTransactionResponse = await (\n await (\n await fetch('https://api.jup.ag/lend/v1/earn/redeem', {\n method: 'POST',\n headers: {\n 'Content-Type': 'application/json',\n 'x-api-key': 'your-api-key',\n },\n body: JSON.stringify({\n asset: mint,\n signer: wallet.publicKey,\n shares: '100000',\n })\n })\n )\n);\n\n​Build Your Own Transaction\nThe Lend API provides 2 ways to interface with the Earn functions in the Jupiter Lend Program. You can either make a post request to directly get the Transaction, or Instruction which can be used for CPI or composing with additional instructions.\n​Transaction\nTo use the Transaction method, simply request to the endpoints without -instructions suffix directly, as shown in the examples above. The API will respond with an unsigned base64 transaction for the signer to sign, then sent to the network for execution.\n​Instruction\nIn some use cases, you’d prefer to utilize the instructions instead of the serialized transaction, so you can utilize with CPI or compose with other instructions. You can make a post request to -instructionsendpoints instead.\nBuilding with Instuctions Code SnippetExample code snippet of using /deposit-instructions endpoint and building a transaction with the instructions.import { Connection, Keypair, PublicKey, TransactionMessage, TransactionInstruction, VersionedTransaction } from '@solana/web3.js';\nimport fs from 'fs';\n\nconst privateKeyArray = JSON.parse(fs.readFileSync('/Path/to/private/key', 'utf8').trim());\nconst wallet = Keypair.fromSecretKey(new Uint8Array(privateKeyArray));\nconst connection = new Connection('insert-your-own-rpc');\n\nconst depositIx = await (\n await fetch (\n 'https://api.jup.ag/lend/v1/earn/deposit-instructions', {\n method: 'POST',\n headers: {\n 'Content-Type': 'application/json',\n 'x-api-key': 'your-api-key',\n },\n body: JSON.stringify({\n asset: 'EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v',\n amount: '1000000',\n signer: wallet.publicKey,\n }, null, 2)\n }\n )\n).json();\n\nconsole.log(JSON.stringify(depositIx, null, 2));\n\nconst deserializeInstruction = (instruction) => {\n return new TransactionInstruction({\n programId: new PublicKey(instruction.programId),\n keys: instruction.accounts.map((key) => ({\n pubkey: new PublicKey(key.pubkey),\n isSigner: key.isSigner,\n isWritable: key.isWritable,\n })),\n data: Buffer.from(instruction.data, 'base64'),\n });\n};\n\nconst blockhash = (await connection.getLatestBlockhash()).blockhash;\nconst messageV0 = new TransactionMessage({\n payerKey: wallet.publicKey,\n recentBlockhash: blockhash,\n instructions: [\n ...depositIx.instructions.map(deserializeInstruction)\n ],\n}).compileToV0Message();\n\nconst transaction = new VersionedTransaction(messageV0);\ntransaction.sign([wallet]);\nconst transactionBinary = transaction.serialize();\nconsole.log(transactionBinary);\nconsole.log(transactionBinary.length);\nconst blockhashInfo = await connection.getLatestBlockhashAndContext({ commitment: \"finalized\" });\n\nconst signature = await connection.sendRawTransaction(transactionBinary, {\n maxRetries: 0,\n skipPreflight: true,\n});\n\nconsole.log(`Transaction sent: https://solscan.io/tx/${signature}`);\n\ntry {\n const confirmation = await connection.confirmTransaction({\n signature,\n blockhash: blockhashInfo.value.blockhash,\n lastValidBlockHeight: blockhashInfo.value.lastValidBlockHeight,\n }, \"confirmed\");\n\n if (confirmation.value.err) {\n console.error(`Transaction failed: ${JSON.stringify(confirmation.value.err)}`);\n console.log(`Examine the failed transaction: https://solscan.io/tx/${signature}`);\n } else {\n console.log(`Transaction successful: https://solscan.io/tx/${signature}`);\n }\n} catch (error) {\n console.error(`Error confirming transaction: ${error}`);\n console.log(`Examine the transaction status: https://solscan.io/tx/${signature}`);\n};\n\n​CPI\n\nRefer to https://github.com/jup-ag/jupiter-lend/blob/main/docs/earn/cpi.md for CPI example\nRefer to https://github.com/jup-ag/jupiter-lend/blob/main/target/idl/lending.json for IDL\n\n​Tokens\nJupiter Lend provides Earnings for individual tokens, meaning SOL and USDC will be deposited in isolation. To get all token information such as the underlying token, supply, rates and liquidity information.\nconst vaults = await (\n await fetch (\n 'https://api.jup.ag/lend/v1/earn/tokens',\n {\n headers: {\n 'x-api-key': 'your-api-key',\n },\n }\n )\n).json();\n\n​User Data\nBelow are the endpoints to aid user to better manage their positions with data of each existing positions, earnings, etc.\n​Positions\nGiven a user, you are able to get their existing position data such as shares, underlying assets, balance and allowance.\nconst userPositions = await (\n await fetch (\n 'https://api.jup.ag/lend/v1/earn/positions?users={user1},{user2}'\n {\n headers: {\n 'x-api-key': 'your-api-key',\n },\n }\n )\n).json();\n\n​Earnings\nGet the earnings of specific positions for a user. The response includes the earnings amount and the slot at which it was computed.\nconst userEarnings = await (\n await fetch(\n 'https://api.jup.ag/lend/v1/earn/earnings?user={user1}&positions={position1},{position2}',\n {\n headers: {\n 'x-api-key': 'your-api-key',\n },\n }\n )\n).json();\n\nResponse:\n[\n {\n \"address\": \"So11111111111111111111111111111111111111112\",\n \"ownerAddress\": \"BQ72nSv9f3PRyRKCBnHLVrerrv37CYTHm5h3s9VSGQDV\",\n \"earnings\": 34483000,\n \"slot\": 345678901\n }\n]\nWas this page helpful?","tokens":2399,"squid":"spider-02","role":"Liquidity Spider","at":1791348555140,"hash":"fe5abd40301bfa8d50bbe4862b50db4e602d6949"}
{"url":"https://ethresear.ch/t/minimal-epbs-beacon-chain-changes/18653","domain":"ethresear.ch","title":"Minimal ePBS - Beacon Chain Changes - Proof-of-Stake / Block proposer - Ethereum Research","text":"Minimal ePBS - Beacon Chain Changes \n\n Proof-of-StakeBlock proposer\n\n mev\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 terence on Feb 12, 2024\n\n terence\n\n This document marks the beginning of a series in which I will discuss ePBS and its essential components from the Proof of Stake beacon chain perspective, excluding detailed coverage of the fork choice, networking, validators, and builders, which will be addressed in future posts. We’ll explore new additions and changes to the beacon chain, dive into individual components, and provide some design rationales. Finally, I will highlight two potential blockers that need to be addressed before we can proceed further.\nReference Documents\nIf you want to review the Python specifications in detail, check out these links:\n(Some of these are outdated with the latest EIP-7547 design)\n\nePBS beacon chain spec\nePBS fork choice spec\nePBS design rational doc\nPrysm reference implementation\n\nHigh-level Changes\n\nFor ePBS, we leverage the following consensus EIPs:\n\nEIP-7251: Increase the MAX_EFFECTIVE_BALANCE\nEIP-7002: Execution layer triggerable exits\nEIP-7547: Inclusion lists\n\nWe borrow concepts from the following research posts:\n\nPayload-timeliness committee (PTC) – an ePBS design\nWhy staked builder?\nTwo-slot proposer/builder separation\n\nNew staked consensus participant in the beacon chain: builder\n\nNew honest validator duty:\n\nPayload timeliness committee (PTC) to cast payload timeliness votes.\nProposer to include aggregated PTC attestations in beacon block body.\n\nThe slot is divided into four intervals instead of three.\n\nProposer proposes block\nAttester attests block\nAggregator aggregates attestations / Builder reveals payload\nPTC votes payload\n\nNote: Timestamps are not specified because the duration of each interval can be adjusted\n\nNew notation: empty slot. This implies that consensus block exists but is missing execution data. This is not a skipped slot!. A skipped slot does not contain consensus data.\n\nSkipped slot: Missing consensus block therefore no execution payload can be included.\nEmpty slot: Consensus block is included, but the execution payload is not included. This means the builder did not reveal, or builder revealed late.\nFull slot: Consensus block and payload are both included on the chain.\n\nScreenshot 2024-02-11 at 12.39.35 PM2474×528 110 KB\n\nTwo new beacon chain signing domains\n\nDOMAIN_BEACON_BUILDER: Builder to sign over the execution header and execution payload.\nDOMAIN_PTC_ATTESTER: PTC to sign over payload timeliness attestations.\n\nBeacon state object changes\n\nAdded new fields previous_inclusion_list_proposer and latest_inclusion_list_proposer to track inclusion list is covered under empty slot condition (EIP-7547 and ePBS).\nAdded new field signed_execution_payload_header_envelope to track proposer selected builder header data is cache (ePBS).\nAdded new field last_withdrawals_root to track withdrawals are sufficiently covered if payload fails to reveal in the current slot and next slot will use the same payload (ePBS).\nAdded new fields deposit_balance_to_consume and pending_balance_depositsto track builder to validator bid transfers are under churn limit (ePBS).\nAdded new fields exit_balance_to_consume , earliest_exit_epoch and pending_partial_withdrawalsto track execution layer withdrawal (EIP-7002).\n\nScreenshot 2024-02-11 at 12.49.14 PM1468×422 33.2 KB\n\nBeacon block body object changes\n\nRemoved fields execution_payload(ePBS) and blob_kzg_commitments (EIP-4844).\nAdded new fields signed_execution_payload_header_envelope (ePBS), payload_attestations(PTC) and execution_payload_withdraw_requests (EIP-7002) and inclusion_list_summary (EIP-7547).\n\nScreenshot 2024-02-11 at 12.49.26 PM1478×364 29.6 KB\n\nExecution payload header object changes\n\nNew object wrapper SignedExecutionPayloadHeaderEnvelope that wraps around ExecutionPayloadHeaderEnvelope and ExecutionPayloadHeader.\nBuilder index and bid value (Gwai) are defined in ExecutionPayloadHeaderEnvelope.\nBuilder signature is defined in SignedExecutionPayloadHeaderEnvelope .\nBuilder signs over ExecutionPayloadHeaderEnvelope with beacon builder domain and public key in the beacon state.\nSignedExecutionPayloadHeaderEnvelope is gossiped as a p2p networking object. Gossip topic is execution_payload_header .\nThere’s no change to the ExecutionPayloadHeader object.\n\nExecution payload object changes\n\nNew object SignedExecutionPayloadEnvelope that warps around ExecutionPayloadEnvelope and ExecutionPayload .\nBuilder index, blob kzg commitments (EIP-4844), beacon block/state root, and inclusion list’s proposer/signature (EIP-7547) are defined in ExecutionPayloadEnvelope .\nBuilder signature is defined in SignedExecutionPayloadEnvelope .\nBuilder signs over ExecutionPayloadEnvelope the way it signs over the header envelope.\nSignedExecutionPayloadEnvelope is gossiped as a p2p networking object. Gossip topic is execution_payload .\nThere’s no change to the ExecutionPayload object.\n\nScreenshot 2024-02-11 at 12.50.51 PM1650×646 47 KB\n\nPayload attestation changes\n\nPayloadAttestation wraps PayloadAttestationMessage and PayloadAttestationData.\nPayloadAttestationData signals the head block root, the slot and whether the payload is revealed for block root.\nPayloadAttestationMessage wraps PayloadAttestationData with PTC validator index and signature.\nPayloadAttestation aggregates PayloadAttestationMessage with PTC bit vector and aggregated signature.\n\nScreenshot 2024-02-11 at 12.50.02 PM766×566 22.3 KB\n\nBlock processing function changes\n\nprocess_block_header is modified to account for the validator’s new slashed field (EIP-7251).\nprocess_withdrawals is modified to account for the empty previous slot condition. Beacon chain will not process new withdrawals if the previous slot already exists consensus changes, but execution changes failed to follow through (ePBS).\nprocess_execution_payload_header is added, and process_execution_payload removed (ePBS). Processing header replaces the processing payload validation steps (ie. withdrawals root, RANDAO, timestamp). Additionally, the processing header verifies the builder signature, the builder has enough balance to pay the proposer, and then the builder’s bid value is deducted at this function. For the inclusion list, It checks the summary’s proposer index matches the block proposer if the parent block is full (EIP-7547). Finally, it caches the payload header envelope to verify the execution payload after the builder reveals it.\nprocess_proposer_slashing and process_attester_slashing are modified to account for new slashing status for validator object (EIP-7251).\nprocess_payload_attestation is added to account for processing of aggregated payload attestation messages in the beacon block body (ePBS). The attestations need to be valid for the block to be valid. PTC members and proposer are properly rewarded and penalized for the correct messages in PTC.\nprocess_execution_layer_withdraw_request is added to process execution layer withdrawals (EIP-7002).\n\nScreenshot 2024-02-11 at 12.41.00 PM3180×854 255 KB\n\nEpoch processing function changes\n\nprocess_registry_updates is modified to use the new churn limit (EIP-7002).\nprocess_pending_balance_deposits is added to process builder to validator bid transfer under churn limit (ePBS).\nprocess_effective_balance_updates is modified for new effective balance accounting (EIP-7251)\n\nScreenshot 2024-02-11 at 12.41.09 PM3196×768 265 KB\n\nExecution payload processing additions\n\nprocess_execution_payload is now an independent check for the state transition after the builder reveals the payload before the cutoff. It verifies:\n\nValid builder signature\nThe same proposer index as the consensus block\nValid inclusion list summary signature\nConsistent with the header\nConsistent with the builder index\nBlob kzg commitments are valid and available\nValid post-state root\n\nprocess_execution_payload caches latest_execution_payload_header and previous_inclusion_list_proposer for subsequent slot accounting\n\nEnd to end flow\n\nBuilders for slot n prepare execution blocks (payloads) and submit blind execution blocks (header) with bids and signatures to the header subnet. The bid is an amount to be paid to the proposer regardless of whether the builder reveals the payload as long as the block becomes canonical. The execution block for n must satisfy the inclusion list condition for n-1\nProposer for slot n broadcasts consensus block with the best header and an inclusion list sidecar for n+1 builder to build on mandatory.\nAttesters for slot n cast votes on the head of the chain, if the head is n block that implies that they verified the consensus block and the inclusion list sidecar.\nAggregators aggregate attestations. In parallel, the winning builder for slot n reveals the execution payload by broadcasting the payload to the payload subnet.\nPayload timeliness committee for slot n cast votes on whether it has seen and verified the correct payload revealed from the same builder.\n\nExpanding more:\n- The proposer builds and broadcasts a beacon block at the second 0 of the slot. This beacon block includes an execution header comprising a transaction root, a builder index, the builder’s signature, and a bid transfer value. This differs from today, where a beacon block includes a full execution payload. The proposer also builds an inclusion list transaction sidecar and broadcasts it alongside the beacon block. The inclusion list transaction sidecar only contains the transactions. The inclusion list summary is included in the block body.\n- All nodes verify the validity of the beacon block, inclusion summaries and transaction list using the consensus and execution client through execution-API. The node inserts the block into the fork choice tree to update the chain’s head. Attesters cast their votes for the head of the block tree before the attestation cut off time.\n- The builder reveals its payload at the same time as aggregator releases aggregated attestations. Builder will reveal the payload if it sees its header included in the beacon block with sufficient attester votes.\n- The Payload Timeliness Committee (PTC) votes for the builder’s reveal and correctness and broadcasts the PTC message before the PTC attestation cut-off time.\n- The next slot n+1’s proposer and attesters run fork choice compute head to determine the head of the chain based on the weight of the fork choice branch and the timeliness of the builder’s reveal. Only proposers and attesters can impose weight on the fork choice tree through out time. The PTC assesses the timeliness of the builder’s payload reveal, determining whether the slot is full or empty, affect what is head for the subsequent slot.\nScreenshot 2024-02-11 at 12.44.23 PM3538×784 365 KB\n\nNow we will go through each component section by section \nIn-protocol staked builder\nePBS adds a new staked consensus participant builder. The builder is identical to the validator. It performs consensus duties. The main differences between builder and validator are:\n\nWithdrawal prefix: BUILDER_WITHDRAWAL_PREFIX\nStaking requirement: BUILDER_MIN_BALANCE\nBuilder prepares and broadcasts the execution payload header with bid and signature. Builder then reveals the execution payload once the header is included in the block when it’s safe to do so.\nBuilder also performs validator duties. Given the different staking requirement, EIP-7251 Max Effective Balance is a prerequisite for ePBS. To become a builder, anyone can manually send a deposit with sufficient amount and the builder prefix. The protocol may also automatically migrate validator to builder during the fork transition if the validator’s balance surpasses BUILDER_MIN_BALANCE.\n\nWhy staked builder?\nBuilder is be staked to be part of the consensus. If everyone is allowed to sign a header and a payload, the system is then bypassed, which means we are back to mev-boost. Rest is a tradeoff question: how much should the builder be staked? The payment can be guaranteed on the consensus layer, and with any staking, the protocol should provide them rewards, while the validator duties are performed.\nInclusion List\nGiven staked builder, solo validators can no longer self-build without their balances exceeding BUILDER_MIN_BALANCE. To ensure censorship resistance of the network, the inclusion list has become a mandatory component for ePBS. Lately the design of the inclusion list has gained significant momentum. One notable version is EIP-7547, which is expected to be implemented in future hard forks.\nThe inclusion list is forward-looking and with its dedicated gas limit. Here’s a summary of its functionality. More details can be found by reading the EIP, consensus specs and more info here:\n\nAt slot n: The proposer of block n broadcasts an inclusion_list_transactions sidecar along with the signed_beacon_block. This sidecar contains inclusionl list transactions with a proposer signature for gossip verification. The proposer inserts inclusion_list_summaries in the block body. A beacon block n without a valid inclusion_list_transactions sidecar that satisfied the summarizes in the block body will not be imported into the fork choice by honest nodes. To verify inclusion list validity:\n\nThe lengths of summaries and transactions must match and be less than MAX_TRANSACTIONS_PER_INCLUSION_LIST.\nThe total gas limit of the transactions must be less than MAX_GAS_PER_INCLUSION_LIST.\nThe execution layer client must verify the inclusion list, ensuring that the transactions are executable at the start of slot n and have a maxFeePerGas at least 12.5% higher than that of the current slot’s maxFeePerGas.\n\nAt slot n+1: The proposer or builder of n+1 will build the block using the inclusion list of n, and the transactions will be in the execution payload. The criteria for execution payload validity are:\n\nFor each index i in n’s inclusion_list, the tx[i] is either included in slot n or the current execution payload with increasing order.\nThe execution payload is valid from the execution layer client’s perspective.\n\nWhat happens if there’s an empty slot?\nIf the payload for the canonical block in slot n was not revealed, then the summaries and transactions list for slot n-1 remain valid. The honest proposer for slot n+1 should not submit a new IL sidecar. If the proposer submits inclusion list on top of an empty slot, the inclusion list will be ignored. The builder for n+1 is required to satisfy the summary of n-1 . If there are k slots in a row that are missing payloads, the next full slot still must satisfy the inclusion list for n-1.\nIt’s essential to prove that a valid payload can always be produced, satisfying the inclusion list even if the slots are skipped or empty. It is also important to prove that builders cannot manipulate the inclusion list to force transaction reversion due to gas limits. Transactions in the exclusion list must have lower nonces, preventing builders from invalidly altering the transaction order in the exclusion list. Thus, valid transactions from n remain valid for the next block.\nPayload Timeliness Committee (PTC)\nInspired by the PTC an ePBS design, ePBS bootstraps a new, small, honest validator committee for casting payload timeliness votes called PTC in our design. Unlike the beacon attestation committee, the PTC does not have explicit fork choice weight in determining the block tree that nodes follow. Instead, it votes on the timeliness of the payload revealed by the builder. Nodes will use PTC votes to determine whether a slot is full or empty. In the current design, members of the PTC Committee are selected as a subset of the beacon slot’s attestation committee. For instance, they can be the first member of each Beacon Committee who is not a builder. The normal beacon attestations submitted from the PTC Committee are ignored. The PTC votes on (head_root, payload_present), indicating whether before PTC attestation cut-off time, the validator has seen a payload.\nPTC Rewards And Penalty\nThe PTC members assigned to PTC duty receive a full attestation reward if they correctly vote for head root and payload present values. Otherwise, they incur a penalty equivalent to that for a missed attestation. The PTC members do not receive additional rewards for performing beacon attestation duty.\nConsensus Block Body Includes PTC attestations\nPTC attesters broadcast PayloadAttestationMessage over the p2p beacon payload_attestation_message subnet. These messages can be aggregated, and the honest proposer of the next slot should include the aggregated PayloadAttestations in its block body. The same beacon attestation rewards apply to the proposer by including the correct PTC attestations. The current design allows the proposer to include one or two aggregated attestations covering both revealed statuses.\nPTC Committee Duty\nValidators are selected for PTC duty with an epoch lookahead using the helper function similar to beacon attestation duty. PTC committee has the same look ahead and using the exact shuffling mechanism as the beacon attestation committee.\nPTC Optimal Committee Size\nPTC committee size is currently set at 512. We want a size that’s small enough that we don’t need another aggregation interval, which could prolong the existing 12s slot time. 512 is a reasonable size for gossip, the sync committee is a good reference. 512 also feels “safe,” given that a 35% attester will need 20,000 years to take over 51% of a committee using binomial with continuity correction.\nBuilder Payment To Proposer\nThe builder to proposer’s bid transfer amount is in Gwai and included in the ExecutionPayloadHeaderEnvelope object with the builder’s index. The SignedExecutionPayloadHeaderEnvelope object contains the builder signature. The bid is not automatically added to the proposer when the block with the header becomes canonical. Two-step process: 1. The builder’s balance is deducted by the bid amount once the block is processed, then the bid is transferred as PendingBalanceDeposit object cached in the beacon state 2. It then subsequently added to the proposer’s balance at the epoch boundary, the amount of transfer allowed in a given epoch is subjected to a churn limit. The beacon state tracks all the bid transfers from builders to proposers and the maximum transferable amount of a given epoch, which is calculated by get_validator_churn_limit. If the churn limit is not sufficient, then the pending bids will be transferred to the future epoch boundaries.\nWhy not same-slot payment as long as the block is canonical?\nSame slot transfer may trigger an attack vector where a builder can transfer large amounts to proposers by placing a large bid. This poses a fork choice risk, as it can instantaneously shift large weights from one block branch to another block branch and potentially circumvent significant penalties in slashing events. To mitigate this, bid transfers are churned by borrowing the deposit design from Max EB EIP. This smoothens the increase in the proposer’s balance suddenly.\nWithdrawal Consideration\nValidator withdrawal works differently under ePBS. Today, withdrawals are deterministic and originate from the consensus layer, then span to the execution layer. Both layers must process withdrawals synchronously, or we will get a consensus failure. In ePBS, withdrawals are cached in the beacon state after processing the consensus block. During the execution phase, the execution block payload withdrawals will be verified against the cached beacon state withdrawals.\nWith an empty slot, the withdrawal comes incomplete despite the consensus data that exists. In this case, the protocol will require the next slot’s n+1 builders to process withdrawals from n in their payloads. Or else the payload is invalid. To summarize, if the payload is absent, the cached withdrawals in state persist for inclusion in future execution payloads.\nEIP-4844 Consideration\nToday, blob transactions are tightly coupled with the execution payload. The consensus clients call execution-API NewPayload to request execution clients to verify blob sidecars alignments. ePBS shifts KZG commitment fields from the beacon block body to the execution payload. When the proposer selects the best header, it will be unaware of the blob content, which is only known during the execution stage when the payload is revealed and then can be verified. The data availability check is also shifted from the consensus phase to the execution phase’s payload processing. An execution payload is valid only if it passes the data availability check and KZG proofs and KZG commitments are consistent across blob sidecars referenced in the execution payload. Builders may broadcast blob sidecars earlier as they seem safe after seeing the beacon block, which reduces last second propagation of blob sidecars, which often take longer to propagate than the execution payload itself. The inclusion list design does not accommodate blob transactions, which should be considered in future research.\nProposer Splitting Attack\nWhat is the proposer splitting? At slot n, the proposer reveals the block close to the attestation deadline, which splits the view of the attesters. Half of the validators voted for the n block, and half voted for a different block. The votes for n bock are weak. As a builder with a header in the proposer block. I now face a dilemma before the payload deadline: to reveal or not. What are the potential outcomes?\nReveal:\n\nHappy case: the n block is canonical, the builder pays the proposer, and gets its payload included\nUnhappy case: the n block is not canonical, the builder does not have to pay the proposer, but everyone, including the n+1 proposer learns about the payload. This is not the same as the same slot unbundling vulnerability. The downside is information leakage, which could be used as beneficial for n+1 proposer\n\nNot reveal:\n\nHappy case: the n block is non-canonical. The builder protected itself and won. It doesn’t have to pay the proposer and none of it’s payload got leaked\nUnhappy case: the n block is canonical. The builder has to pay the proposer but never gets its payload included\n\nWhat are some potential solutions?\n\nProof-based: Allow the builder to prove it’s “honest” that it indeed revealed the payload “on-time” based on the proposer block. Allow the builder to prove that the proposer is “dishonest”. How to prove it is hard.\nFork choice based: Give the builder some weights in the fork choice. Give the builder some power to determine the head of the chain. But this also opens up the builder griefing the proposer\nStrong finality based: If today the proposer block “cant be forked” then the problem no longer exists. Many solution spaces have single-slot finality or strong BFT consensus for the proposer block. But these solutions prolong the development cycle or beacon chain slot time from 12s to 24s.\n\nProposer Equivocation Attack\nOne of the open questions in any ePBS design space is proposer equivocation to unbundle the builder payload so points here:\n\nThe current design protects builder from same slot unbundling, it does not protect builder from next slot re-orging and builder leaking information for next slot proposer and builders.\nA builder must first reveal the payload of a proposed block before a proposer can attempt to unbundle. This means the builder is fully protected against proposer equivocation until the payload is revealed. The crucial monitor for a builder before the reveal phase is not the number of blocks a proposer released but the votes that the header accumulated.\nIf the block initially committed to by the builder is eventually included in the blockchain, the builder doesn’t incur any risk. Builder pays proposer the bid amount This outcome aligns with the builder’s original intention.\nAfter revealing the payload, the builder is safe from being unbundled unless next slot’s beacon committee is predominantly composed of malicious validators that vote for an empty block over the original block. If the attesters’ committee is corrupted, we are powerless in this situation, and the same issue persists currently.\n\nForkchoice Changes\nWe will have a separate post to cover fork choice changes because it’s more nuanced. In this post, I will summarize the important concepts introduced in ePBS because fork choice & beacon chain are closely coupled\n\nOne fundamental change is the head block could be with or without execution data. Then what should get_head() return? First point is the head returns the block with the strongest LMD weight disregarding its payload status for future slot. There will be a helper is_payload_present(block_root), which returns true whether the slot exists an execution data.\nCheckpoint is still the same as today which a (epoch, root) pair. Given payload status does not change any consensus head, to compute a new head, a node still start from a latest justified checkpoint and then traverse down the block tree to get its head.\nTo account for LMD weights in the block tree, the accounting scheme is identical to today under one exception: direct votes are only counted in chains supporting distinct payload status based on PTC votes. This means you have (n-1, full) parent and two children (n, empty) and (n, fill). Both children’s weights would be counted towards (n-1, full). Now let’s say (n+1, full) builds on top of (n, full), not (n, empty). In this case, the weight would only count towards (n, full).\n\nWe’ll do a comprehensive post covering fork choice changes in further details\nRoadblocks \nAs of today, the most significant road blocks to ePBS are proposer splitting and fitting entire end to end flow within a 12-second timeframe. The proposer splitting attack is particularly challenging to address without necessitating additional rounds of fork choice or achieving single slot finality. Fitting everything within 12 seconds is challenging, but optimistic, given that consensus and execution are divided between two virtual slots, reducing the comparison required during peak periods. We will share more information as we continue to make progress \n\n MEV resistant dynamic pricing auction of execution proposal rights\n\n Block-auction ePBS versus Execution Ticket\n\n read \n\n 9\n min\n\n Powered by Discourse","tokens":6574,"squid":"spider-04","role":"Research Spider","at":1791348565079,"hash":"85eac497a61304a59de4a52dc5c0c6c044b7cfda"}
{"url":"https://ethresear.ch/t/payload-timeliness-committee-ptc-an-epbs-design/16054","domain":"ethresear.ch","title":"Payload-timeliness committee (PTC) – an ePBS design - Proof-of-Stake - Ethereum Research","text":"Payload-timeliness committee (PTC) – an ePBS design \n\n Proof-of-Stake\n\n mev,proposer-builder-separation\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n read \n\n 12\n min\n\n Jul 2023\n\n 1 / 7\n\n Jul 2023\n\n Aug 2023\n\n post by mikeneuder on Jul 6, 2023\n\n mikeneuder\n\n Payload-timeliness committee (PTC) – an ePBS design\nby mike & francesco – based on discussions with potuz & terence – july 6, 2023\n\\cdot⋅\nh/t Potuz for coming up with the idea of not giving the builder block explicit fork-choice weight, but rather using a committee to decide on the timeliness of the payload. This document is the result of a number of iterations on this concept.\n\\cdot⋅\ntl;dr; We present a new design for ePBS called Payload-Timeliness Committee (abbr. PTC). We include: a high-level overview, the new honest attesting behavior, and an initial analysis of the properties and potential new attack vectors. This document omits the formal specification, which will follow as we gain confidence in the soundness of this design.\n\\cdot⋅\nMany thanks to Danny, Barnabé, Caspar, Toni, Vitalik, Justin, Jon, stokes, Jacob, Aditya, and Chris for relevant discussions.\n\nNew concepts\n\npayload-timeliness committee (PTC) – a subset of the attestation committee from each slot that votes on the builder’s payload release.\nfull, empty, and missing blocks – a full block has a valid ExecutionPayload that becomes canonical (results in an update to the EL state). An empty block is a CL block does not have a canonical ExecutionPayload (does not update the EL state). A missing block is an empty slot that becomes canonical. With block-slot voting, missing blocks can have fork-choice weight.\npayload-timeliness (PT) votes – the set of votes cast by the PTC.\n\nThe PT votes for slot N are only used by the proposer and attesting committee in slot N+1.\nThe PT votes for slot N determine the proportion of the fork-choice weight given to the full vs. empty versions of the slot N block.\n\nNote – Throughout this document, we describe block-slot voting as a prerequisite for PTC. However, we can make use of the existing voting mechanics and treat ancestral block votes in slot N as votes for the missing version of the slot N block. For clarity in the examples, we describe missing as part of the competing fork, but adding pure block-slot voting may not be necessary in practice.\nDesign overview\nWe first present a minimal description of the new design. Note that this does not include the full specification of behavior and is intended to present the high-level details only.\nOld slot anatomy\nPresently, the 12 second slot is partitioned into the following three phases. Figure from Time, slots, and the ordering of events in Ethereum Proof-of-Stake.\nupload_0ad62632f94d94974f544f1b20a6c9ff1577×565 67.3 KB\nFlow\n\nAt t=0 block proposed by the elected PoS validator.\nAt t=4, the attestation deadline, the attesting committee for slot N uses the fork-choice rule to determine the head of the chain in their view and makes an attestation.\nAt t=8 the aggregate attestations are sent.\nAt t=12 the next proposer builds on whatever head they see according to their fork-choice view.\n\nNew slot anatomy\nThe new slot contains an additional phase for the PT votes to propagate.\nupload_516b236ef25496ffda5566b3db21218a2038×533 97 KB\nFlow\n\nThe slot N block that is published at t=t0 is the CL block proposed by the elected PoS validator. This block contains a builder bid, but no ExecutionPayload.\nThe attestation deadline at t=t1 is unchanged. The entire attesting committee for slot N uses the fork-choice rule to determine the head of the chain in their view and makes an attestation.\nThe broadcast of aggregate attestations for the slot still begins at t=t2. Additionally, the builder publishes their execution payload if they have not seen an equivocation from the proposer (the builder does not need to have a full view of the attestations).\nAt t=t3 the PTC casts their vote for whether the payload was released on time.\nAt t=t4 the slot N+1 proposer publishes their block, building on either the full or empty block based on the PT votes and attestations that they have seen.\n\nNote – Timestamps are not specified because we can adjust the duration of each phase based on performance testing. The key details are what happens in the four phases and at the boundaries.\nNote 2 – Depending on the size of the PTC, we may need a fifth slot phase to aggregate the votes of said committee. Larger committees may need aggregation, but are more secure, which is the design tradeoff.\nBlock production\nThe full block is assembled in two phases. First, the CL (beacon) block is produced with a commitment to a builder bid. Any double-signing of this block represents a proposer’s equivocation. Once the builder has observed the CL block, they produce their ExecutionPayload to construct the full version of the block. The PTC casts votes on the timeliness of this object in their view.\nupload_16a2060853c41b28b83f27c03a64d5421389×880 105 KB\nThe slot N committee votes on the CL block, while the slot N PTC observes the payload release, which informs the fork-choice rule in the subsequent slot. We propose that the PTC is a strict subset of the slot N attesting committee (e.g., the first 1000 members).\n\nHonest attesting behavior\nConsider the honest attesting committee at t=t1 of slot N+1. Assume that there was a block in slot N and the slot N+1 proposer built a child block (it extends w.l.o.g. to missing blocks in either slot). The slot N+1 block could either build on the empty or full block from slot N. Similarly, the PTC cast their votes on full or empty based on the payload-timeliness at t=t3 of the previous slot. The attesting committee in slot N+1 assigns weight to the full vs empty block respectively by using the proportion of PT votes from slot N.\nExamples\nAssume the slot N block is canonical and received 100% of the slot N attestations. Let W denote the total weight of each attesting committee. PT indicates the payload-timeliness vote and boost is the 40% proposer boost given to each proposer block.\nCase 1\nupload_fb7fdc053bc36a887afec78cf836f4e21124×815 21.2 KB\nThe slot N PTC is split, with 51% voting for the full block and 49% voting for the empty block. The slot N+1 proposer builds on the empty block and is given proposer boost, which is equivalent to 40% of the weight of the attesting committee. The attesting committee at N+1 now sees a split and has to choose between attesting to N+1 or N+1,missing. The PT votes divide the attestation weight of the slot N attestations, so we have,\n\nweight(N+1) = 0.49W + 0.4W = 0.89W,\n𝑤𝑒𝑖𝑔ℎ𝑡(𝑁+1)=0.49𝑊+0.4𝑊=0.89𝑊,\nwhile,\n\nweight(N+1,missing) = 0.51W.\n𝑤𝑒𝑖𝑔ℎ𝑡(𝑁+1,𝑚𝑖𝑠𝑠𝑖𝑛𝑔)=0.51𝑊.\nThus, the attesters vote for N+1 (the top fork).\nCase 2\nupload_0a5354622de22951feca56b75174ae951149×836 22.4 KB\nHere we have 100% of the PT votes agreeing that the block should be full. Now the attesting committee for slot N+1 votes against the proposer, and for N+1,missing because\n\nweight(N+1) = 0.4W < weight(N+1,missing) = W.\n𝑤𝑒𝑖𝑔ℎ𝑡(𝑁+1)=0.4𝑊<𝑤𝑒𝑖𝑔ℎ𝑡(𝑁+1,𝑚𝑖𝑠𝑠𝑖𝑛𝑔)=𝑊.\nIn this case, the PTC from slot N overrules the slot N+1 proposer, who clearly built on the wrong head. The bottom fork wins.\nCase 3\nupload_121a77b1cbbd1cc377195d2f496d43ee1164×823 21.5 KB\nIn the worst case, the slot N+1 attesters see this split view. Here\n\nweight(N+1) = 0.7W = weight(N+1,missing),\n𝑤𝑒𝑖𝑔ℎ𝑡(𝑁+1)=0.7𝑊=𝑤𝑒𝑖𝑔ℎ𝑡(𝑁+1,𝑚𝑖𝑠𝑠𝑖𝑛𝑔),\nand they have to tie-break to determine which fork to vote for. The key here is that this split is difficult to achieve because you need 70% of the PTC to vote for full, while the proposer builds on empty. More on this in “Splitting considerations” (below).\n\nAnalysis\nThe properties specified below were initially presented in Why enshrine Proposer-Builder Separation? A viable path to ePBS. We modify honest-builder payload safety to the weaker condition of honest-builder same-slot payload safety.\nProperties\n\nhonest-builder payment safety – if an honest builder is selected and their payment is processed, their payload becomes canonical.\nhonest-proposer safety – if an honest proposer commits to a single block on time, they will unconditionally receive the payment from the builder for the bid they committed to.\nhonest-builder same-slot payload safety – if an honest builder publishes a payload, they can be assured that no competing payload for that same slot will become canonical. This protects builders from same-slot unbundling. Note: This property relies on a 2/3 honest majority assumption of the validator set.\n\nNon-properties\n\nhonest-builder payload safety – the builder cannot be sure that if they publish the payload, it will become canonical. The builder is not protected from next-slot unbundling (the builder is not protected from that in mev-boost either, as length-1 reorgs happen regularly). More on this in “Splitting considerations” (below).\n\nNote – In terms of CL engineering, making the transition function able to process empty blocks is important. Because empty blocks will not update the EL state, they must exclude withdrawals.\n\nBuilder payment processing\n\nBuilder payments are processed during the epoch finalization process (open for discussion, could just be on a one-epoch lag). The payment takes place if both of these conditions are satisfied:\n\nThe builder ExecutionPayloadHeader is part of the canonical chain (i.e., the CL block for that slot is not missing). This includes two cases:\n\nThe corresponding ExecutionPayload is also part of the canonical chain (the happy-path) (i.e., the CL block for that slot is full).\nThe builder ExecutionPayloadHeader is part of the canonical chain even if the corresponding ExecutionPayload is not (consensus that the builder was not on time) (i.e., the CL block for that slot is empty).\n\nThere is no evidence of proposer equivocation.\n\nA builder who sees an equivocation can get the validator slashed. Any slashed validator will not receive the unconditional builder payment.\n\nDifferences from other designs\n\nThe payload timeliness determines how to allocate the fork-choice vote, but it cannot create a separate fork.\nThe payload view determines how the subsequent attesting committee votes.\nThe builder is never given a proposer boost or explicit LMD-GHOST weight.\nThe unconditional payments are handled asynchronously, after enough time has passed for equivocations to be detected and the corresponding validators to be slashed.\nThe PT votes only inform the attesting behavior of the subsequent slot. Similar to proposer boost, the effect is bound to a single slot.\n\nSplitting considerations\n“Splitting” is an action undertaken by a malicious participant to divide the honest view of the network. In today’s PoS, proposers can split the network by timing the release of their block near the attestation deadline. Some portion of the network will see the block on time, while other will vote for the parent block because it was late. Proposer boost is the mechanism in-place to give the next proposer power to resolve these forks if the weight of competing branches is evenly split. The PTC introduces more potential splitting vectors, which we present below.\nProposer-initiated splitting\nFirst, consider the case where the proposer splits the chain in an attempt to grief the builder.\nupload_79750da5a56789643d5cf7ab16a1e2fa1929×1086 262 KB\nThe sequence of events is as follows:\n\nThe slot N proposer releases their block near the attestation deadline, causing a split of the honest attesting set. 50% of the honest attesters saw it on time and voted for the block, while the other 50% did not see it on time and thus voted for a missing block.\nThe builder of the header included in the block must make a decision about releasing the payload that corresponds to this block. The block is either full or empty based on that decision.\nThe slot N+1 proposer resolves the split by building on the missing, full, or empty head (any of the blue blocks). Because the proposer will have a boost, the fork is resolved.\n\nNow consider the builder’s options.\n\nPublish the payload – If the missing block becomes canonical, they published the payload, but it never made it on-chain (bad outcome). Otherwise, the full payload became canonical (good outcome).\nWithhold the payload – If the empty block becomes canonical, the unconditional payment goes through, but they aren’t rewarded by the payload being included (bad outcome). If the missing block becomes canonical, then they didn’t needlessly reveal their payload (good outcome).\n\nIn summary, either publishing or withholding the payload can result in a good or bad outcome, depending on the behavior of the slot N+1 proposer (which is uncertain even if they are honest).\nKey point 1 – By not giving fork-choice weight to the builder, we cannot protect them from the proposer splitting in an attempt to grief. However, the builder can be certain that their block will not be reorged by a block in the same slot, so they can protect their transactions by bounding them to slot N.\nKey point 2 – Today, such splitting is possible as well; it just looks slightly different. If the proposer intentionally delays their publication such that the next proposer might try to reorg their block using the honest-reorg strategy, the mev-boost builders have no certainty that their block won’t be one-block reorged. Indeed, we see many one-block reorgs presently. See Time, Slots for more context.\nBuilder-initiated splitting\nAs hinted at above, builders can try to grief the slot N+1 proposer into building on a fork with a weak PT vote by selectively revealing the payload to a subset of the PTC.\nupload_240b0eb8bf0b71269cb92e2bfaa2d7e11139×815 21.6 KB\nIn this case, the N+1 proposer is going to get orphaned by the N+1,missing block because there was such a disparity in the PT votes. Specifically, if the builder can get the proposer to build on the full or empty block which is the opposite of what the PTC votes for, then they orphan the block. Let N,empty be the block that the proposer of N+1 builds on (w.l.o.g.), and let \\beta𝛽 denote the proportion of the PTC voting for N,full. If \\beta > 0.7𝛽 >0.7, then the N+1 validator will be orphaned. In other words, the proposer needs to agree with at least 30% of the PTC to avoid being orphaned.\nSpitting conclusion\nNeither of these splitting conditions seem too critical. The proposer-initiated splitting is already possible today with mev-boost and builder-initiated splitting will be difficult to execute if the PTC is sufficiently large. Any ePBS design involves some additional degrees of freedom for network participants (by enshrining the builder role), and this design is no exception. Further analysis on the probability and feasibility of splitting will be an important part of the full evaluation of the PTC design.\n\n Relays in a post-ePBS world\n\n Three dichotomies in ePBS\n\n Realigning block building incentives and responsibilities - Block Negotiation Layer\n\n 🗳️ Commitment-Satisfaction Committees: An In-Protocol Solution to PEPC\n\n Fork Choice Attacks and Protections in EPBS\n\n 2\n\n read \n\n 12\n min\n\n post by addyxvii on Jul 6, 2023\n\n addyxvii\n\nbuilder-initiated splitting will be difficult to execute if the PTC is sufficiently large.\n\nI know that this is only a high level description, but out of ignorance/curiosity is a minimum PTC size going to be enforced in the spec to prevent builder initiated splitting? or is it not critical enough to address?\n\n post by mikeneuder on Jul 10, 2023\n\n mikeneuder\n\nWe would certainly enforce a minimum size! The tradeoff remains the extra time needed to aggregate if the PTC becomes too large\n\n post by bryce on Jul 10, 2023\n\n bryce\n\n Awesome writeup and am excited to see nice research progress on the ePBS front, thanks for this \nI was looking deeper into block-slot voting and the main reasons it was not implemented in the end. This post describes it well:\n\nThis implies that if - for whatever reason - there is latency greater than 3 seconds, even an honest but slightly late block would not make it into the canonical chain. So while technically the chain is still making progress (voting on empty slots and finalizing them), it’s practically of no use to the user because no transactions are included in the canonical chain.\n\nThe current design doesn’t address this concern if we were to go ahead and introduce block-slot voting in the fork choice rule. Understood that you mentioned pure block-slot voting may not be necessary in practice, but with the notion of missing blocks, the concern is still valid in my opinion.\n\n post by fradamt on Jul 14, 2023\n\n fradamt\n\n The way we know how to deal with those concerns is to essentially turn-off the block, slot machinery and revert back to not giving fork-choice weight to missing blocks, whenever progress is not being made for sufficiently long (then eventually try turning it back on and see how it goes, i.e., a back-off scheme)\nThe issue with doing this with ePBS is that the block, slot machinery is quite essential to it, to the point where turning it off would imho require turning off ePBS itself. This might be ok, as long as either:\n\nlocal block building capabilities still exist in all validators (this might not be the case forever, and PBS, both in its MEV-boost and ePBS form, might accelerate this possibility)\noff-chain PBS infrastructure still exists, at least as a fallback\n\n post by dankrad on Jul 21, 2023\n\n dankrad\n\n As discussed during this weeks workshop, a problem with this design is that it does not protect the builder in case the proposer intentionally or unintentionally splits the attestation committee.\nThis is an important property of PBS designs.\n\n 15 days later\n\n post by 0xkydo on Aug 5, 2023\n\n 0xkydo\n\n I think the fork choice rule here is quite fascinating. I want to spell it out and see if my understanding is correct. I will go through a hypothetical and propose some questions along the way.\nAs an LMD-GHOST attester (consensus attester) in slot n+1, I would first look at the beacon blocks at slot n. Let’s say there are two beacon blocks (bb) bb_n^1𝑏𝑏1𝑛 and bb_n^2𝑏𝑏2𝑛. bb_n^1𝑏𝑏1𝑛 has 31% weight and bb_n^2𝑏𝑏2𝑛 has 69% weight.\n\nI then look at the where did the proposer at slot n+1 build upon. Let’s say it built on top of bb_n^1𝑏𝑏1𝑛, because it has proposer boost, I will vote on the newly-proposed bb_{n+1}𝑏𝑏𝑛+1.\nNext I need to check on the PTC votes on bb_n^1𝑏𝑏1𝑛. The n+1 proposer treated the bb_{n+1}𝑏𝑏𝑛+1 block as empty and 20% of the PTC in slot n also voted for empty.\n\nQuestion: since there are two blocks at slot n, how would the PTC vote? Would I vote on both blocks or just one block. Another way of asking this is: if we sum the PTC votes, would it equal to 100% for each block proposed by the proposer or for all of the blocks? In this current flow, I am treating the PTC to only care about the payload, so it will vote on the payload for all headers.\n\nNow, in my view wrt the payload, I have 20%+40% = 60% treating bb_n^1𝑏𝑏1𝑛 as empty, and 80% (100%-20%) treating bb_n^1𝑏𝑏1𝑛 as full. How would I vote now?\n\nDo I vote for the\n\nbb_n^1𝑏𝑏1𝑛\nbb_n^1𝑏𝑏1𝑛 full block\nor the newly proposed bb_{n+1}𝑏𝑏𝑛+1\nbb_n^2𝑏𝑏2𝑛 (therefore treating bb_{n+1}𝑏𝑏𝑛+1 as an invalid block)\n\nHere is a diagram describing the attester’s view.\nimage3160×2672 245 KB\n\n Powered by Discourse","tokens":4853,"squid":"spider-04","role":"Research Spider","at":1791348575628,"hash":"bb15cf8b92fd847efadf485060ea007c25e2c5b4"}
{"url":"https://docs.chain.link/datalink/pull-delivery/reference/api-sdk-onchain-verification","domain":"docs.chain.link","title":"API, SDKs, Onchain Verification Reference | Chainlink Documentation","text":"API, SDKs, Onchain Verification ReferenceDataLink uses the same APIs, SDKs, and verification infrastructure as Chainlink Data Streams. Applications can use existing Data Streams integration patterns and tooling. \n\nAPI InterfacesAccess DataLink feeds using the standard Data Streams Direct APIs:\nData Streams REST API Reference: HTTP-based integrations and fetching reports on demand.\nData Streams WebSocket Reference: Real-time data streaming via a persistent WebSocket connection.\n\nSDK IntegrationIntegrate DataLink quickly into your applications using the existing Data Streams SDKs:\nData Streams Go SDK Reference: Native Go language integration.\nData Streams Rust SDK Reference: Native Rust language integration.\n\nReport VerificationVerify the integrity of DataLink reports onchain using the same process and Verifier contracts as Data Streams:\nData Streams Onchain Verification Reference: Learn how to verify report authenticity on EVM chains using the shared Verifier Proxy contracts.","tokens":247,"squid":"spider-08","role":"Oracle Spider","at":1791348580160,"hash":"91596dadc4a39f4d7e7a1c8a800a7183d6d8542f"}
{"url":"https://www.metaplex.com/docs/dev-tools/cli/core/execute","domain":"metaplex.com","title":"Execute | Metaplex CLI","text":"SummaryThe mplx core asset execute info command displays the signer PDA address and current SOL balance for any MPL Core Asset. The signer PDA is a deterministic program-derived address that can hold SOL, tokens, and own other assets on behalf of the asset.Derives and displays the signer PDA address for any Core AssetVerifies the asset exists on-chain before returning resultsShows the PDA's current SOL balanceUsed alongside asset-signer wallets for full PDA wallet functionalityBasic UsageGet execute info for an assetmplx core asset execute info <assetId>\nArgumentsArgumentDescriptionASSET_IDThe address of the MPL Core Asset to derive the signer PDA forGlobal FlagsFlagDescription-c, --config <value>Path to config file. Default is ~/.config/mplx/config.json-k, --keypair <value>Path to keypair file or ledger (e.g., usb://ledger?key=0)-p, --payer <value>Path to payer keypair file or ledger-r, --rpc <value>RPC URL for the cluster--commitment <option>Commitment level: processed, confirmed, or finalized--jsonFormat output as JSON--log-level <option>Logging level: debug, warn, error, info, or trace (default: info)ExamplesDisplay PDA Info for an AssetGet signer PDA infomplx core asset execute info 5avjMVza8SuMhgTfzEGNWJskDELMCQk9juAAc8zeQoNa\nOutput:execute info output--------------------------------\n Asset: 5avjMVza8SuMhgTfzEGNWJskDELMCQk9juAAc8zeQoNa\n Signer PDA: 7xKXtg2CW87d97TXJSDpbD5jBkheTqA83TZRuJosgAsU\n SOL Balance: 0.1 SOL\n--------------------------------\nGet Structured JSON OutputExecute info with JSON outputmplx core asset execute info <assetId> --json\nReturns:JSON response{\n \"asset\": \"<assetId>\",\n \"signerPda\": \"<pdaAddress>\",\n \"balance\": 0.1\n}\nFund the PDA After InspectionA common workflow is to inspect the PDA, then fund it:Send funds to the Asset Signer, not the asset addressThe Asset Signer PDA and the Core Asset are two different addresses. Make sure to always fund the Asset Signer PDA.Inspect and fund the PDA# 1. Get the PDA address\nmplx core asset execute info <assetId>\n\n# 2. Send SOL to the PDA\nmplx toolbox sol transfer 0.1 <signerPdaAddress>\n\n# 3. Confirm the balance\nmplx core asset execute info <assetId>\nHow Execute WorksEvery MPL Core asset has a deterministic signer PDA derived from its address using findAssetSignerPda. This PDA can act as a wallet — holding SOL, owning tokens, and signing instructions via the on-chain execute instruction.The typical workflow is:Derive the PDA — use mplx core asset execute info <assetId> to find the PDA addressFund the PDA — send SOL to the PDA address using mplx toolbox sol transferRegister as wallet — add the asset as an asset-signer wallet with mplx config wallets add <name> --asset <assetId>Use normally — all CLI commands auto-wrap in the execute instruction when an asset-signer wallet is activeinfo is the only execute subcommand. To perform operations as the PDA, register the asset as an asset-signer wallet — all regular CLI commands will then auto-wrap in execute transparently.Quick ReferenceItemValueCommandmplx core asset execute infoApplies toMPL Core Assets onlyRelatedAsset-Signer WalletsPDA derivationfindAssetSignerPda(umi, { asset: assetPubkey })SourceGitHub — metaplex-foundation/cliNotesThe signer PDA is deterministic — the same asset always produces the same PDA addressThe PDA can hold SOL, SPL tokens, and even own other MPL Core AssetsThe asset account itself is not a SOL wallet: it keeps only its rent-exempt minimum, and any lamports above that are treated as Core protocol fees and swept by the Metaplex fee collector.Only the asset owner (or authorized delegate) can invoke the execute instruction for a given asset's PDAThe command verifies the asset exists on-chain before deriving the PDA; a non-existent asset will produce an errorThe balance shown is the SOL balance only — use mplx toolbox sol balance with an asset-signer wallet active to check token balancesThis is a read-only command — it does not create or modify any on-chain stateSome operations cannot be wrapped in execute due to Solana CPI constraints — see CPI LimitationsBurning the Asset permanently disables execute. Empty the signer PDA first or remaining SOL, tokens, and nested assets are stranded — see Execute Asset Signing","tokens":1056,"squid":"dotcat","role":"Tooling Spider","at":1791348587286,"hash":"80b2e4b33e58837dd8df27135d3a9c356087e869"}
{"url":"https://www.paradigm.xyz/2023/04/mev-boost-ethereum-consensus","domain":"paradigm.xyz","title":"Time, slots, and the ordering of events in Ethereum Proof-of-Stake","text":"Time, slots, and the ordering of events in Ethereum Proof-of-Stake IntroductionOn April 2nd, a malicious Ethereum network participant stole $20M from a MEV searcher by exploiting a vulnerability in the mev-boost-relay (see Flashbots’ post-mortem). In the following days, developers addressed the bug by releasing five patches to the broader mev-boost ecosystem. These patches, alongside existing network latencies and validator strategies, resulted in a brief period of instability in the Ethereum network due to an increased rate of reorged blocks on April 6th. Reorgs are bad for network health because they decrease the rate of block production and reduce settlement assurances.In this post, motivated by the attack against the searcher and the temporary instability of the network, we explore the interplay between mev-boost & consensus, unpack subtleties of Ethereum’s Proof-of-Stake mechanism, and enumerate some of the possible paths forward.What is mev-boost & why is it important?mev-boost is a protocol designed by Flashbots and the community to mitigate the negative effects of Maximal Extractable Value (MEV) on the Ethereum network.There are 3 actors in mev-boost:Relays – mutually-trusted auctioneers that connect proposers to block builders.Builders – sophisticated entities who construct blocks in order to maximize MEV for themselves and the proposers.Proposers – Ethereum Proof-of-Stake validators.The rough sequence of events per-block is:A builder creates a block by receiving transactions from users, searchers, or other (private or public) orderflow.The builder submits the block to a relay.The relay validates that the block is valid and calculates how much it pays the proposer.The relay sends a “blinded” header and a payment value to the proposer of the current slot.The proposer evaluates all the bids they’ve received and signs the blinded header associated with the highest payment.The proposer sends this signed header back to the relay.The block gets published by the relay using their local beacon nodes and returned to the proposer. The rewards are distributed to the builder & proposer through transactions in the block and the block reward.The relay is a mutually-trusted party that facilitates the fair exchange of block space (from the proposer) and transaction sequencing for MEV extraction (from the builder). The relay protects builders from MEV stealing, in which proposers copy builder transactions to take MEV for themselves instead of allocating it to the searcher/builder who discovered it. The relay protects proposers by (a) confirming the validity of the builder blocks, (b) processing hundreds of blocks per-slot on behalf of the proposer, and (c) ensuring the accuracy of the proposer payment.mev-boost is critical protocol infrastructure because it enables democratic access to MEV for all proposers without requiring trusted relationships with builders or searchers, which contributes to Ethereum’s long-term decentralization.Ethereum’s Fork-Choice Rule & mev-boostBefore we dive into the attack and responses, we examine Ethereum's Proof-of-Stake (PoS) mechanism and the associated fork-choice rule. A fork-choice rule allows the network to reach consensus about the head of the chain. From Ethereum Reorgs After The Merge:A fork choice rule is a function, evaluated by the client, that takes as input the set of blocks and other messages that have been seen, and outputs to the client what the \"canonical chain\" is. Fork choice rules are required because there may be multiple valid chains to choose from (eg. if two competing blocks with the same parent get published at the same time).A lesser-known aspect of the fork-choice rule is its relationship to time, which has major implications for block production.Slots & sub-slot periodsIn Ethereum PoS, time is partitioned in 12 second increments called slots. The PoS algorithm randomly assigns a validator the permission to propose a block for that slot; this validator is referred to as the proposer. In the same slot, other validators are assigned the task of attesting (voting) for the block that is the head of the chain according to their local view by applying the fork-choice rule. The 12 second slot is subdivided into three phases, each consuming 4 seconds.The events that take place in a slot are listed below using t=0 to denote the beginning of the slot. The most critical moment in a slot is the attestation deadline at t=4. If an attesting validator has not seen a block by the attestation deadline, they will instead vote for the previously accepted head of the chain (according to the fork-choice rule). The earlier a block is proposed, the more time it has to propagate, and thus the more attestations it accumulates (because more validators see it by the attestation deadline).From the network-health perspective, the best time for a block to be published is t=0 (as dictated by the spec). However, since the value of the block increases monotonically with time, proposers have the incentive to delay the publication of their blocks to allow more MEV to accumulate. See Timing games in Proof-of-Stake and this discussion for further details.Historically, a proposer could publish a block well after the attestation deadline (even close to the end of the slot), as long as the next validator observed the block before they built their block for the subsequent slot. This is a result of the child block inheriting the weight of the parent block and the fork-choice rule terminating at a leaf node. Thus there was no downside to delaying block publication. In order to help push rational behavior (delaying the block publication) towards honest behavior (on-time publishing), “honest reorgs” were implemented.Proposer boost & honest reorgsTwo new concepts were introduced into the consensus clients that have critical implications for the attestation deadline.proposer boost (PR) – attempts to minimize reorg balancing-attacks by granting the proposer a fork-choice “boost” equivalent to 40% of the full attestation weight. Importantly, this boost only lasts for the duration of the slot.honest reorgs (PR) – takes proposer boost and allows honest proposers to use it to forcibly reorg blocks that have attestation weight below 20%. This is implemented in Lighthouse and Prysm (as of v4.0 – the Capella release). This change is optional because it is a local decision made by the proposer, and does not impact the attesting validators’ behavior. As a result, there was no coordinated effort to roll it out in all clients simultaneously, nor was it associated to any specific hard-fork.Note that honest reorgs are avoided in some special cases:during epoch boundary blocksif the chain is not finalizingif the head of the chain is not from the slot prior to the reorged blockCondition 3 ensures that honest reorgs only ever remove a single block from the chain, which acts as a circuit breaker to allow the chain to continue producing blocks during periods of extreme network latency. This also reflects the proposer's reduced confidence in their view of the network, because they can no longer be certain that their proposer-boosted block will be seen as canonical.The diagram below demonstrates how honest behavior changes to implement the reorg strategy. In this scenario, let b1 represent a late block. Due to the lateness, b1 only has 19% of the attesting weight for slot n. The remaining 81% of the attesting weight is allocated to the parent block HEAD, because many attesters did not see b1 by the attestation deadline.Without honest reorgs, the proposer for slot n+1 sees b1 as the head of the chain and builds a child block b2. The proposer makes no effort to reorg b1, despite it only having 19% attesting weight. During slot n+1, b2 has proposer boost, and assuming it was delivered on-time, b2 will become canonical by accumulating a majority of the attestations for that slot.With honest reorgs, the situation is much different. Now the proposer of slot n+1 sees that the 19% attestation weight on b1 is below the reorg threshold, so they build a block with HEAD as the parent of b2, and forcibly reorg b1. When we reach the attestation deadline of slot n+1, honest attesters will compare the relative weights of b1 (19%) vs b2 (40% from proposer boost). All the clients implement proposer boost, thus b2 will be seen as the head of the chain and will accumulate the slot n+1 attestations.Relay & beacon node fixes in response to the unbundling attackDuring the April 2nd unbundling attack, the proposer exploited a relay bug by sending an invalid signed header back to the relay. During the following days, the relay and the core-dev teams released a number of software patches to mitigate the risk of a repeat attack. The five major changes were the following:Relay changes:Check the DB for known malicious proposers (only ever used in prod by the ultra sound relay, and has since been removed).Check if the relay has already delivered a full block to the p2p network during that slot.Introduce a uniform random delay in the range 0-500ms before the publication of the block (removed from all relays).Beacon node changes (only for relay beacon nodes):Validate the beacon block before broadcasting it.Check the network for equivocations before publishing a block.The combination of these changes led to consensus instability that was exacerbated by the fact that a large percentage of validators are now using the honest reorg strategy described above.Unforeseen consequencesEach of the 5 changes mentioned above introduced latency into the hot path of relay block publication, which increased the probability that relay blocks would be broadcast after the attestation deadline. The figure below shows the five checks in sequence and how the introduced latency could cause the block publication to exceed the attestation deadline.Before these checks were implemented, a signed header arriving substantially later than t=0, e.g. t=3, would typically present no issues. The relay had a very low overhead, and thus would publish the block well before the attestation deadline at t=4.However, with the introduction of the latency from the five patches, the relay could now be partially responsible for a late broadcast. Let’s look at a hypothetical block publication below. The relay receives the signed header from the proposer at t=3. By t=4, the relay is still executing checks and thus the broadcast happens after the attestation deadline. In this case, the combination of the proposer sending the signed header late and the relay introducing some additional latency resulted in the missed attestation deadline. Without honest reorgs, these blocks would have very likely made it on chain. The honest proposers for the subsequent slot would not intentionally reorg the block for being late as we saw in Figure 2. With honest reorgs however, missing the attestation deadline means this block will be reorged by the next proposer.As a result, in the days following the attack, the number of forked blocks increased dramatically. The Metrika 2 week data shows that in the worst case, 13 blocks (4.3%) were reorged in an hour, which was ~5x more than normal. As the relays rolled out various changes, the sharp increase in the number of forked blocks became clear. Thanks to a great community effort from relay operators and the core-devs, once the impact was understood, many of the changes were rolled back and the network returned to a healthy state.As of today, the most useful changes were the beacon node block validation and equivocation checks that take place before broadcasting. Malicious proposers can no longer execute the attack by sending an invalid header to the relay and also must ensure that the relay beacon nodes do not see the equivocating block before publishing. Despite this, the relay remains exposed to the more general equivocation attack as presented in Equivocation attacks in mev-boost and ePBS.So what should we do?In this post we highlighted how mev-boost works and how critical it is for Ethereum consensus. We also double-clicked on some of the lesser-known aspects of Ethereum’s fork-choice rule surrounding timing. Using the unbundling attack and the developers’ response as a case study, we underscore the potential fragility of the timing-related aspects of the fork-choice rule, and its impact on the network’s stability.Given that, the research community should evaluate what is an “acceptable” amount of reorgs and consider the exposure to equivocation attacks more generally to determine if mitigations should be implemented.Additionally, there are multiple future directions being actively explored:Implementing “headlock” to protect mev-boost against equivocation. This would also require changes in the consensus client software and likely a spec change to extend the attestation deadline.Increasing the number and visibility of bug bounty programs for the mev-boost software.Expanding simulation software to explore how sub-slot timings can impact network stability. This could be used to evaluate how adjusting the attestation deadline could reduce reorgs.Optimizing the block publication path on the relay to reduce unnecessary latency. This is already being explored.Recognizing that mev-boost is core-protocol functionality and absorbing it into the consensus clients, aka enshrined-PBS (ePBS). Two-slot ePBS is vulnerable to equivocation attacks, so implementing “headlock” remains an option.Adding more hive and/or spec tests informed by issues around latency and the attestation deadline.Encouraging relay client diversity by building additional implementations of the relay spec.Considering an adjustment to the slashing penalties for equivocation, while keeping in mind that even a full 32 ETH slashing may not be enough to dissuade malicious behavior in the presence of extremely large MEV opportunities.Revisiting the sub-slot timings and considering and adjustment of the block propagation phase (e.g. moving the attestation deadline from t=4 to t=6).Overall, we are excited by the renewed energy around MEV and the mev-boost ecosystem. Through the unbundling attack and mitigations, we have come to understand the critical relationship between latency, mev-boost, and the consensus mechanism; we hope that the protocol continues to harden in response.If these topics are exciting and interesting to you, please reach out to Georgios (email) or Mike (email).Many thanks to Bert Miller, Danny Ryan, Alex Stokes, Francesco D’Amato, Michael Sproul, Terence Tsao, Frankie, Joachim Neu, Chris Hager, Matt Garnett, Charlie Noyes, and samczsun for their feedback on this article and Achal Srinivasan for designing the figures.","tokens":3677,"squid":"spider-04","role":"Research Spider","at":1791348587339,"hash":"24c632af4f1d442eb032ee455bd513eb2d449262"}
{"url":"https://docs.chain.link/datalink/pull-delivery/tutorials/onchain-verification-evm","domain":"docs.chain.link","title":"Verify Report Data Onchain (EVM) | Chainlink Documentation","text":"Verify Report Data Onchain (EVM)In this guide, you'll learn how to verify onchain the integrity of reports by confirming their authenticity as signed by the Decentralized Oracle Network (DON). You'll use a verifier contract to verify the data onchain and pay the verification fee in LINK tokens. \n\nBefore you beginMake sure you understand how to fetch reports via the REST API or WebSocket connection. Refer to the following guides for more information:\nFetch and decode reports (API) using the Go or Rust SDK\nStream and decode reports (WebSocket) using the Go or Rust SDK\n\nRequirements\nThis guide requires testnet ETH and LINK on Arbitrum Sepolia. Both are available at faucets.chain.link.\nLearn how to Fund your contract with LINK.\n\nTutorialDeploy the verifier contractDeploy a ClientReportsVerifier contract on Arbitrum Sepolia. This contract is enabled to verify reports and pay the verification fee in LINK tokens.\n\nOpen the ClientReportsVerifier.sol contract in Remix.\n\nOpen in Remix\nWhat is Remix?\n\nSelect the ClientReportsVerifier.sol contract in the Solidity Compiler tab.\n\nCompile the contract.\n\nOpen MetaMask and set the network to Arbitrum Sepolia. If you need to add Arbitrum Sepolia to your wallet, you can find the chain ID and the LINK token contract address on the LINK Token Contracts page.\n\nArbitrum Sepolia testnet and LINK token contract\n\nOn the Deploy & Run Transactions tab in Remix, select Injected Provider - MetaMask in the Environment list. Remix will use the MetaMask wallet to communicate with Arbitrum Sepolia.\n\nIn the Contract section, select the ClientReportsVerifier contract and fill in the Arbitrum Sepolia verifier proxy address: 0x2ff010DEbC1297f19579B4246cad07bd24F2488A. You can find the verifier proxy addresses on the Verifier Proxy Addresses page.\n\nClick the Deploy button to deploy the contract. MetaMask prompts you to confirm the transaction. Check the transaction details to ensure you deploy the contract to Arbitrum Sepolia.\n\nAfter you confirm the transaction, the contract address appears under the Deployed Contracts list in Remix. Save this contract address for the next step.\n\nFund the verifier contractIn this example, the client contract pays for onchain verification of reports in LINK tokens when fees are required. The contract automatically detects whether the target network requires fees:\n\nNetworks with FeeManager deployed: Verification requires token payments. These networks include: Arbitrum, Avalanche, Base, Blast, Bob, Ink, Linea, OP, Scroll, Soneium, and ZKSync.\n\nNetworks without FeeManager: No funding is needed since you can verify reports without fees. The contract skips the fee calculation and approval steps.\n\nFor this tutorial on Arbitrum Sepolia, fees are required, so you need to fund the contract with LINK tokens. Open MetaMask and send 1 testnet LINK on Arbitrum Sepolia to the verifier contract address you saved earlier.Verify a report onchain\n\nIn Remix, on the Deploy & Run Transactions tab, expand your verifier contract under the Deployed Contracts section.\n\nFill in the verifyReport function input parameter with the report payload you want to verify. You can use the following full report payload obtained in the Fetch and decode report via a REST API guide (EUR/USD feed) as an example:\n0x00090d9e8d96765a0c49e03a6ae05c82e8f8de70cf179baa632f18313e54bd69000000000000000000000000000000000000000000000000000000000041438a000000000000000000000000000000000000000000000000000000030000000100000000000000000000000000000000000000000000000000000000000000e000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000000260000100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001000004b9905d8337c34e00f8dbe31619428bac5c3937e73e6af75c71780f1770ce00000000000000000000000000000000000000000000000000000000683f13dd00000000000000000000000000000000000000000000000000000000683f13dd00000000000000000000000000000000000000000000000000006e0e3915bcc3000000000000000000000000000000000000000000000000004edc1454fb6ef0000000000000000000000000000000000000000000000000000000006866a0dd0000000000000000000000000000000000000000000000000fcaa20569eac064000000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000027b160a6824ccce49dc0bd19f636c40de2f3033410c7d1a7400b9a3cb0073d19dde0f87cfd6d9ce03156464a49cacb07136d2e7d717efcf42bc2795fd5c513e4a00000000000000000000000000000000000000000000000000000000000000025e075a9d8a6223ce2b9e524a7b5a563c2924a67b544e6676a751f5374b2a42ee37684b560eb72546f87b7287cefc668705461b7f4ebe4dabd7babe397cc98b89\n\nClick the verifyReport button to call the function. MetaMask prompts you to accept the transaction.\n\nClick the lastDecodedPrice getter function to view the decoded price from the verified report. The answer on the EUR/USD stream uses 18 decimal places, so an answer of 1137900000000000100 indicates an EUR/USD price of 1.1379000000000001. Note: Each feed may use a different number of decimal places for answers.\n\nExamine the codeThe example code you deployed has all the interfaces and functions required to verify DataLink reports onchain.// SPDX-License-Identifier: MIT\npragma solidity 0.8.24;\n\nimport {Common} from \"@chainlink/contracts/src/v0.8/llo-feeds/libraries/Common.sol\";\nimport {IVerifierFeeManager} from \"@chainlink/contracts/src/v0.8/llo-feeds/v0.3.0/interfaces/IVerifierFeeManager.sol\";\nimport {IERC20} from \"@openzeppelin/contracts/token/ERC20/IERC20.sol\";\nimport {SafeERC20} from \"@openzeppelin/contracts/token/ERC20/utils/SafeERC20.sol\";\n\nusing SafeERC20 for IERC20;\n\n/**\n * THIS IS AN EXAMPLE CONTRACT THAT USES UN-AUDITED CODE FOR DEMONSTRATION PURPOSES.\n * DO NOT USE THIS CODE IN PRODUCTION.\n *\n * This contract can verify Chainlink DataLink reports onchain and pay\n * the verification fee in LINK (when required).\n *\n * - If `VerifierProxy.s_feeManager()` returns a non-zero address, the network\n * expects you to interact with that FeeManager for every verification call:\n * quote fees, approve the RewardManager, then call `verify()`.\n *\n * - If `s_feeManager()` returns the zero address, no FeeManager contract has\n * been deployed on that chain. In that case there is nothing to quote or pay\n * onchain, so the contract skips the fee logic entirely.\n *\n * The `if (address(feeManager) != address(0))` check below chooses the\n * correct path automatically, making the same bytecode usable on any chain.\n */\n\n// ────────────────────────────────────────────────────────────────────────────\n// Interfaces\n// ────────────────────────────────────────────────────────────────────────────\n\ninterface IVerifierProxy {\n /**\n * @notice Route a report to the correct verifier and (optionally) bill fees.\n * @param payload Full report payload (header + signed report).\n * @param parameterPayload ABI-encoded fee metadata.\n */\n function verify(\n bytes calldata payload,\n bytes calldata parameterPayload\n ) external payable returns (bytes memory verifierResponse);\n\n function verifyBulk(\n bytes[] calldata payloads,\n bytes calldata parameterPayload\n ) external payable returns (bytes[] memory verifiedReports);\n\n function s_feeManager() external view returns (IVerifierFeeManager);\n}\n\ninterface IFeeManager {\n /**\n * @return fee, reward, totalDiscount\n */\n function getFeeAndReward(\n address subscriber,\n bytes memory unverifiedReport,\n address quoteAddress\n ) external returns (Common.Asset memory, Common.Asset memory, uint256);\n\n function i_linkAddress() external view returns (address);\n\n function i_nativeAddress() external view returns (address);\n\n function i_rewardManager() external view returns (address);\n}\n\n// ────────────────────────────────────────────────────────────────────────────\n// Contract\n// ────────────────────────────────────────────────────────────────────────────\n\n/**\n * @dev This contract implements functionality to verify DataLink reports from\n * the API, with payment in LINK tokens.\n */\ncontract ClientReportsVerifier {\n // ----------------- Errors -----------------\n error NothingToWithdraw();\n error NotOwner(address caller);\n error InvalidReportVersion(uint16 version);\n\n // ----------------- Report schemas -----------------\n // Extract schema version from feed ID (first 2 bytes of the feed ID)\n /**\n * @dev DataLink report schema v3.\n * Prices, bids and asks use 8 or 18 decimals depending on the feed.\n */\n struct ReportV3 {\n bytes32 feedId;\n uint32 validFromTimestamp;\n uint32 observationsTimestamp;\n uint192 nativeFee;\n uint192 linkFee;\n uint32 expiresAt;\n int192 price;\n int192 bid;\n int192 ask;\n }\n\n /**\n * @dev DataLink report schema v4.\n */\n struct ReportV4 {\n bytes32 feedId;\n uint32 validFromTimestamp;\n uint32 observationsTimestamp;\n uint192 nativeFee;\n uint192 linkFee;\n uint32 expiresAt;\n int192 price;\n uint32 marketStatus;\n }\n\n // ----------------- Storage -----------------\n IVerifierProxy public immutable i_verifierProxy;\n address private immutable i_owner;\n\n int192 public lastDecodedPrice;\n\n // ----------------- Events -----------------\n event DecodedPrice(int192 price);\n\n // ----------------- Constructor / modifier -----------------\n /**\n * @param _verifierProxy Address of the VerifierProxy on the target network.\n * Addresses: https://docs.chain.link/datalink/pull-delivery/verifier-proxy-addresses\n */\n constructor(\n address _verifierProxy\n ) {\n i_owner = msg.sender;\n i_verifierProxy = IVerifierProxy(_verifierProxy);\n }\n\n modifier onlyOwner() {\n if (msg.sender != i_owner) revert NotOwner(msg.sender);\n _;\n }\n\n // ----------------- Public API -----------------\n\n /**\n * @notice Verify a DataLink report (schema v3 or v4).\n *\n * @dev Steps:\n * 1. Decode the unverified report to get `reportData`.\n * 2. Read the first two bytes → schema version (`0x0003` or `0x0004`).\n * - Revert if the version is unsupported.\n * 3. Fee handling:\n * - Query `s_feeManager()` on the proxy.\n * – Non-zero → quote the fee, approve the RewardManager,\n * ABI-encode the fee token address for `verify()`.\n * – Zero → no FeeManager; skip quoting/approval and pass `\"\"`.\n * 4. Call `VerifierProxy.verify()`.\n * 5. Decode the verified report into the correct struct and emit the price.\n *\n * @param unverifiedReport Full payload returned.\n * @custom:reverts InvalidReportVersion when schema ≠ v3/v4.\n */\n function verifyReport(\n bytes memory unverifiedReport\n ) external {\n // ─── 1. & 2. Extract reportData and schema version ──\n (, bytes memory reportData) = abi.decode(unverifiedReport, (bytes32[3], bytes));\n\n uint16 reportVersion = (uint16(uint8(reportData[0])) << 8) | uint16(uint8(reportData[1]));\n if (reportVersion != 3 && reportVersion != 4) {\n revert InvalidReportVersion(reportVersion);\n }\n\n // ─── 3. Fee handling ──\n IFeeManager feeManager = IFeeManager(address(i_verifierProxy.s_feeManager()));\n\n bytes memory parameterPayload;\n if (address(feeManager) != address(0)) {\n // FeeManager exists — always quote & approve\n address feeToken = feeManager.i_linkAddress();\n\n (Common.Asset memory fee,,) = feeManager.getFeeAndReward(address(this), reportData, feeToken);\n\n IERC20(feeToken).approve(feeManager.i_rewardManager(), fee.amount);\n parameterPayload = abi.encode(feeToken);\n } else {\n // No FeeManager deployed on this chain\n parameterPayload = bytes(\"\");\n }\n\n // ─── 4. Verify through the proxy ──\n bytes memory verified = i_verifierProxy.verify(unverifiedReport, parameterPayload);\n\n // ─── 5. Decode & store price ──\n if (reportVersion == 3) {\n int192 price = abi.decode(verified, (ReportV3)).price;\n lastDecodedPrice = price;\n emit DecodedPrice(price);\n } else {\n int192 price = abi.decode(verified, (ReportV4)).price;\n lastDecodedPrice = price;\n emit DecodedPrice(price);\n }\n }\n\n /**\n * @notice Withdraw all balance of an ERC-20 token held by this contract.\n * @param _beneficiary Address that receives the tokens.\n * @param _token ERC-20 token address.\n */\n function withdrawToken(\n address _beneficiary,\n address _token\n ) external onlyOwner {\n uint256 amount = IERC20(_token).balanceOf(address(this));\n if (amount == 0) revert NothingToWithdraw();\n IERC20(_token).safeTransfer(_beneficiary, amount);\n }\n}\n\nOpen in Remix\nWhat is Remix?Initializing the contractWhen deploying the contract, you define the verifier proxy address for the feed you want to read from. You can find this address on the Verifier Proxy Addresses page. The verifier proxy address provides functions that are required for this example:\nThe s_feeManager function to estimate the verification fees.\nThe verify function to verify the report onchain.\nVerifying a reportThe verifyReport function is the core function that handles onchain report verification. Here's how it works:\n\nReport data extraction:\n\nThe function decodes the unverifiedReport to extract the report data.\nIt then extracts the report version by reading the first two bytes of the report data, which correspond to the schema version encoded in the feed ID.\nIf the report version is unsupported, the function reverts with an InvalidReportVersion error.\n\nFee calculation and handling:\n\nThe function first checks if a FeeManager contract exists by querying s_feeManager() on the verifier proxy.\nIf a FeeManager exists (non-zero address):\n\nIt calculates the fees required for verification using the getFeeAndReward function.\nIt approves the RewardManager contract to spend the calculated amount of LINK tokens from the contract's balance.\nIt encodes the fee token address into the parameterPayload for the verification call.\nFeeManager contracts are currently deployed on: Arbitrum, Avalanche, Base, Blast, Bob, Ink, Linea, OP, Scroll, Soneium, and ZKSync.\n\nIf no FeeManager exists (zero address):\n\nThe function skips the fee calculation and approval steps entirely.\nIt passes an empty parameterPayload to the verification call.\n\nThis automatic detection makes the contract compatible with any network, regardless of whether fee management is deployed.\n\nReport verification:\n\nThe verify function of the verifier proxy is called to perform the actual verification.\nIt passes the unverifiedReport and the parameterPayload (which contains either the encoded fee token address or empty bytes) as parameters.\n\nData decoding:\n\nDepending on the report version, the function decodes the verified report data into the appropriate struct (ReportV3 or ReportV4).\nIt emits a DecodedPrice event with the price extracted from the verified report.\nThe lastDecodedPrice state variable is updated with the new price.\n\nAdditional functionalityThe contract also includes:\nOwner-only token withdrawal: The withdrawToken function allows the contract owner to withdraw any ERC-20 tokens (including LINK) from the contract.\nEnhanced error handling: The contract includes specific error types (InvalidReportVersion, NotOwner, NothingToWithdraw) for better debugging and user experience.\nCross-chain compatibility: The automatic FeeManager detection makes the same contract code work on any supported network, whether fees are required or not.","tokens":3754,"squid":"spider-08","role":"Oracle Spider","at":1791348590428,"hash":"92a7e23e21b252fca41d4fab4108d4306f21b458"}
{"url":"https://www.metaplex.com/docs/dev-tools/cli/core/create-asset","domain":"metaplex.com","title":"Create Asset | Metaplex CLI","text":"The mplx core asset create command allows you to create MPL Core Assets using three different methods: simple creation, file-based creation, or an interactive wizard. This command provides flexibility in how you want to create your assets while maintaining a consistent output format.Methods1. Simple CreationCreate a single Asset by providing the name and URI of the metadata directly through command line arguments.mplx core asset create --name \"My NFT\" --uri \"https://example.com/metadata.json\"\n2. File-based CreationCreate a single Asset by providing an image file and a JSON metadata file. The command will handle uploading both files and creating the asset.mplx core asset create --files --image \"./my-nft.png\" --offchain \"./metadata.json\"\nNeed a starting metadata file? Run mplx core asset template [output] to scaffold a metadata.json inside an asset/ folder and pass it to --offchain.3. Interactive WizardCreate an Asset using the interactive wizard which guides you through the entire process, including file uploads and metadata creation.mplx core asset create --wizard\nOptionsBasic Options--name <string>: Asset name (required for simple creation)--uri <string>: URI of the Asset metadata (required for simple creation)--collection <string>: Collection ID for the assetFile-based Options--files: Flag to indicate file-based creation--image <path>: Path to image file to upload and assign to Asset--offchain <path>: Path to offchain JSON metadata file to uploadPlugin Options--plugins: Use interactive plugin selection--pluginsFile <path>: Path to a JSON file with plugin dataVanity Addresses--mint-keypair <path>: Path to a keypair JSON file to use as the asset address instead of generating a random one. See Grind a vanity public key.ExamplesCreate an asset using the interactive wizard:mplx core asset create --wizard\nCreate an asset with name and URI:mplx core asset create --name \"My NFT\" --uri \"https://example.com/metadata.json\"\nCreate an asset from files:mplx core asset create --files --image \"./my-nft.png\" --offchain \"./metadata.json\"\nCreate an asset with a collection:mplx core asset create --name \"My NFT\" --uri \"https://example.com/metadata.json\" --collection \"collection_id_here\"\nCreate an asset with files and a collection:mplx core asset create --files --image \"./my-nft.png\" --offchain \"./metadata.json\" --collection \"collection_id_here\"\nCreate an asset with a vanity address:mplx core asset create \\\n --name \"My NFT\" \\\n --uri \"https://example.com/metadata.json\" \\\n --mint-keypair ./vanity-asset.json\nJSON OutputPass --json to get structured machine-readable output instead of formatted text:mplx core asset create --name \"My NFT\" --uri \"https://example.com/metadata.json\" --json\nReturns: { asset, signature, explorer, coreExplorer }OutputThe command will output the following information upon successful creation:--------------------------------\n Asset: <asset_address>\n Signature: <transaction_signature>\n Explorer: <explorer_url>\n Core Explorer: https://core.metaplex.com/explorer/<asset_address>\n--------------------------------","tokens":766,"squid":"dotcat","role":"Tooling Spider","at":1791348597271,"hash":"53a31d7c2cad5eb0cca48f0d0f7d18c3c5e2f12b"}
{"url":"https://chain.link/terms","domain":"chain.link","title":"Terms of Service | Chainlink","text":"All Contracts\n\n Chainlink Foundation Terms of Service\n\n Chainlink Foundation Terms of Service\n\n Version 6.0\n\n Effective August 18th 2026\n Download\n\n Table of Contents\n\n Terms of ServiceThese terms of service, together with any documents and additional terms they incorporate by reference (collectively, these “Terms”), are entered into between the Chainlink Foundation (the “Foundation,” “we,” “us,” and “our”) and you or the company or other legal entity that you represent (“you” or “your”). For the purposes of these Terms, “you” or “your” includes any automated systems, software agents, bots or similar tools acting on your behalf or using credentials associated with you (each an “Agent”).Please read these Terms carefully as they govern your use of our site located at chain.link and all associated sites (the “Website”) and our Services (defined below) and describe your rights and obligations and our disclaimers and limitations of legal liability and include a binding arbitration agreement and class action waiver that affect your rights. By accessing or using any part of the Website or the Services, you agree to become bound by the terms and conditions of these Terms. For clarity, you acknowledge that any access to or use of the Website or Services by an Agent will be deemed access to and use by you and authorized by you.If you use the Services on behalf of a company, organization (including a decentralized autonomous organization or “DAO”) or other entity then “you” includes you and that entity, and you represent and warrant that (a) you are an authorized representative of the entity with the authority to bind the entity to these Terms, and (b) you agree to these Terms on the entity’s behalf.If you do not agree to these Terms or do not have authority to bind your organization on whose behalf you are using the Services to these Terms, you must not access or use our Website or the Services. Please carefully review the disclosures and disclaimers set forth in Section 8 in their entirety before accessing the Website, our Services, or using any software developed by the Foundation. Please refer to our privacy policy available at chain.link/privacy-policy for information about how we collect, use, share and otherwise process information about you. In addition, you agree to comply with the Chainlink Community Code of Conduct with respect to any interactions on or arranged through the Website.We reserve the right, in our sole discretion, to modify these Terms from time to time. If we make changes, we will provide you with notice of such changes using commercially reasonable means, such as by sending an email, providing a notice through the Website or our Services or updating the date at the top of these Terms. Unless we say otherwise in our notice, any modifications are effective immediately, and your continued use of the Website or our Services will confirm your acceptance of the changes. If you do not agree to the amended Terms, you must stop using our Services.1. SERVICESThe Foundation enables users to access documentation, content, tools and services, including (without limitation):data, consensus and computation services provided by decentralized networks of node operators that are providing such services via data feeds, APIs and various other capabilities directly to smart contracts integrating Chainlink software (“Chainlink Network”),developer platform tools, including (without limitation) interfaces allowing users to generate draft transaction messages, software development kits, simulators, toolkits and plugins, andinformation, documentation, reference contracts, code, tutorials and other resources for the Chainlink Network community.Collectively such documentation, content, tools and services are referred to as the “Services”. Some Services offered by us or other participants in the Chainlink Network require payment or otherwise involve the use of an underlying blockchain or other decentralized or permissioned infrastructure (“Distributed Ledger Technology”), which may require that you pay a fee, such as “gas” charges on the Ethereum network or other applicable blockchain network, for the computational resources required to perform a transaction on the particular Distributed Ledger Technology (such payments and fees, “Charges”). You acknowledge and agree that the Foundation has no control over any Distributed Ledger Technology transactions, the method of payment of any Charges, if applicable, or any actual payments of Charges, if applicable. Accordingly, you must ensure that you have a sufficient balance of the applicable Distributed Ledger Technology network tokens stored at your Distributed Ledger Technology-compatible wallet address (“Distributed Ledger Technology Address”) to complete any transaction on the Chainlink Network or the Distributed Ledger Technology before initiating such a transaction.2. YOUR REPRESENTATIONS AND WARRANTIES; CONDITIONSTo use the Website or Service, you must be able to form a legally binding contract online either on behalf of the entity on whose behalf that you are using the Website or Services, or as an individual if you are using the Website or the Services in your personal capacity. Accordingly, you represent that you are at least 18 years old (or the age of majority where you reside, whichever is older), can form a legally binding contract online, and have the full, right, power and authority to enter into and to comply with the obligations under these Terms. Additionally, you represent and warrant that (i) you are not 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 any list maintained by the Office of Foreign Assets Control of the U.S. Department of the Treasury, the European Union, any member state of the European Union, the United Kingdom (including those administered by HM Treasury), the Cayman Islands, the British Virgin Islands, or the United Nations), (ii) you are not 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 States, the European Union, any member state of the European Union, the United Kingdom, the Cayman Islands, the British Virgin Islands, or the United Nations, (iii) you are not, and do not directly or indirectly own or control any Distributed Ledger Technology Address or other blockchain address that is listed on any list of prohibited or restricted parties or (iv) you are not a citizen or resident of a state, country, territory or other jurisdiction where your use of the Website or the Services would be illegal or otherwise violate any domestic or foreign law, rule, statute, regulation, by-law, order, protocol, code, decree, or other directive, requirement or guideline, published or in force which applies to or is otherwise intended to govern or regulate any person, property, transaction, activity, event or other matter, including any rule, order, judgment, directive or other requirement or guideline issued by any domestic or foreign federal, provincial or state, municipal, local or other governmental, regulatory, judicial or administrative authority having jurisdiction over the Foundation, you, the Website or the Services, or as otherwise duly enacted, enforceable by law, the common law or equity (“Applicable Law”).As a condition to accessing or using the Services or the Website, you represent, warrant and agree that you: (i) will only use the Website and the Services for lawful purposes and in accordance with these Terms; (ii) will ensure that all information that you provide on the Website or for the Services is current, complete, and accurate; (iii) will maintain the security and confidentiality of access to your Distributed Ledger Technology Address; (iv) will identify and assess the accuracy, availability and quality of data that you choose to consume via the Chainlink Network or the code you choose to run via the Chainlink Network; (v) will not fork, reverse engineer, decompile, disassemble, or attempt to derive the underlying code, algorithms, or structure of the Services, any software, APIs, tools, interfaces, or documentation made available by us; (vi) will not copy, replicate, or create derivative works of the Services or any component thereof, or attempt to reconstruct the Services to circumvent licensing, intellectual property, or contractual restrictions; and (vii) agree (A) that no Protected Party (defined below) will be responsible for any loss or damage incurred as the result of any interactions you have with other users of the Website, Services or the Chainlink Network, including the loss of any amount of the native utility token of the Chainlink Network (“Link Tokens”), any other tokens or other unit of value; and (B) if there is a dispute between you and any other site or other user, no Protected Party will be under any obligation to become involved.As a condition to accessing or using the Website or the Services, you represent, warrant and agree that you will not: (i) violate any Applicable Law, including, without limitation, any relevant and applicable anti-money laundering and anti-terrorist financing laws and any relevant and applicable privacy and data collection laws, in each case as may be amended from time to time; (ii) export, reexport, or transfer, directly or indirectly, any Foundation technology or Chainlink Network data in violation of applicable export laws or regulations; (iii) infringe on or misappropriate any third-party intellectual property rights or other third-party rights, including any unauthorized use of data, breaches of Chainlink Network third-party service provider terms, or committing a tort while using the Website or the Services; (iv) misrepresent the truthfulness, sourcing or reliability of any content on the Website or through the Services; (v) use the Website or Services in any manner that could interfere with, disrupt, negatively affect, or inhibit other users from fully enjoying the Website, Services or the Chainlink Network, or that could damage, disable, overburden, or impair the functioning of the Website, Services or the Chainlink Network in any manner; (vi) use the Website or Services for benchmarking or competitive analysis with respect to competitive or related products or services, or to develop, commercialize, license, or sell any product, service or technology that could, directly or indirectly, compete with the Services; (vii) attempt to circumvent any content filtering techniques or security measures that the Foundation employs on the Website or the Services, or attempt to access any service or area of the Website or the Services that you are not authorized to access; (viii) use any robot, spider, crawler, scraper, or other automated means or interface not provided by us, to access the Website or Services or to extract data; (ix) introduce any harmful code, malware, virus, Trojan horse, worm, logic bomb, drop-dead device, backdoor, shutdown mechanism or other harmful material into the Website or the Services or use the Services to transmit such material; (x) post content or communications on the Website or through the Services (including User Content (as defined below)) that are, in our sole discretion, libelous, defamatory, profane, obscene, pornographic, sexually explicit, indecent, lewd, vulgar, suggestive, harassing, hateful, threatening, offensive, discriminatory, bigoted, abusive, inflammatory, fraudulent, deceptive or otherwise objectionable or in violation of the Chainlink Community Code of Conduct; (xi) post content on the Website or through the Services containing unsolicited promotions, political campaigning, or commercial messages or any chain messages or user content designed to deceive or trick the user of the Service; or (xii) encourage, induce or assist any third party to engage in any of the activities prohibited under these Terms.You represent and warrant that you: (i) have the necessary technical expertise and ability to review and evaluate the security, integrity and operation of any of Link Tokens that you decide to acquire, sell or use; (ii) have the knowledge, experience, understanding, professional advice and information to make your own evaluation of the merits, risks and applicable compliance requirements under Applicable Law of any Link Token; (iii) know, understand and accept the risks associated with your use of the Chainlink Network, your Distributed Ledger Technology Address, the Distributed Ledger Technology, Link Tokens and other network tokens, including the risk of mining attacks such as “double-spend attacks,” “majority mining power attacks,” “selfish-mining attacks,” “race condition attacks” and the risks identified in Section 14 below; and (iv) have the necessary technical expertise and ability to configure the Services into your application or blockchain network, if applicable, including your understanding that it is your responsibility to follow all best practices and other responsibilities including (without limitation) those set forth in the Data Feeds, Data Streams, Functions and CCIP Service Responsibilities pages of the Website. The Chainlink Network enables access to data from multiple sources and you acknowledge and agree that the accuracy, availability or quality of data provided via the Chainlink Network may be impacted by various factors, including as a result of the underlying data being of low quality, volatile, or otherwise compromised at the data source.You are solely responsible for all acts and omissions of any Agent accessing or using the Services on your behalf, including any transactions, requests, enquiries, or outputs generated by such Agent. For clarity, any activity conducted by an Agent through any Distributed Ledger Technology Address, API key, or other credential used to access the Services will be deemed to be activity undertaken by you, and the Foundation is entitled to rely on such activity as authorized by you, without further enquiry.3. PROPRIETARY RIGHTSExcluding any open source software or third-party software that the Website or the Services incorporates, as between you and Foundation, the Foundation owns the Website and the Services, including all technology, content and other materials used, displayed or provided on the Website (including all intellectual property rights), and hereby grants you a limited, revocable, non-transferable license to access and use those portions of the Website and the Services that are proprietary to the Foundation in accordance with their intended uses and using their designated public interfaces.Certain of the Services are governed by the most recent version of the open source license, commonly known as the MIT License, and any other applicable licensing terms for the Website and the Services in these Terms (collectively, the “Foundation License”). You acknowledge that the Website, the Services or the Chainlink Network may use, incorporate or link to certain open-source components and that your use of the Website, Services and/or the Chainlink Network is subject to, and you will comply with any, applicable open-source licenses that govern any such open-source components (collectively, “Open-Source Licenses”). Without limiting the generality of the foregoing, you may not resell, lease, lend, share, distribute or otherwise permit any third party to use the Website or the Services or otherwise use the Website or the Services in a manner that violates the Foundation License or any other Open-Source Licenses.Any of the Foundation’s product or service names, logos, and other marks used in the Website or as a part of the Services, including the Foundation's name and logo are trademarks owned by the Foundation or its applicable licensors. Except as specifically provided herein, you agree to take no action inconsistent with such ownership. You may generally use the Foundation’s name and logo to refer to the Foundation’s mission and activities, provided that any such reference does not in any way suggest or imply partnership or collaboration with, sponsorship, endorsement or approval by the Foundation. You may also indicate the relationship of your products and services to the Foundation’s mission and activities by using an accurate descriptive term in connection with your product or service. You may not use the Foundation’s name and logo as a trademark for your products or services or in a manner that may cause confusion with others or result in genericization. The Foundation reserves its right to prohibit the use of the Foundation’s marks by anyone at our sole discretion. Except as provided in the foregoing, you may not copy, imitate or use the Foundation’s marks without the Foundation’s (or the applicable licensor’s) prior written consent. All use of the Foundation’s trademarks will inure to the benefit of the Foundation.The Foundation will be free to use, disclose, reproduce, license, and otherwise distribute and exploit any suggestions, comments, or other feedback provided by you to the Foundation with respect to the Website or Services (“Feedback”) provided to it as it sees fit, entirely without obligation or restriction of any kind, on account of intellectual property rights or otherwise.Certain functionalities within the Services may allow or enable you or your users to deploy, interface or interact with, access, or use compatible third-party code or assets, including (without limitation) reference contracts developed and/or licensed by us, or other third-party code incorporating code developed and/or licensed by us, but deployed by you or a third party (collectively, “Third-Party Code”), through or integrated with the Services or that otherwise interacts with the Chainlink Network. We do not provide, endorse or make any representations and warranties with respect to the Third-Party Code and are not responsible for (i) any compatibility issues, misconfigurations, errors, bugs or harmful code in the Services or Third-Party Code caused in whole or in part by the Third-Party Code or any update or upgrade thereto or (ii) any action taken or statements made by the parties responsible for Third-Party Code. Your use of any Third-Party Code is at your own risk.The Website and the Services provide access to certain third-party websites (“External Sites”) that provide third-party services, including services provided by Chainlink Labs, or one of its subsidiaries or affiliates (“Third-Party Services”) solely as a convenience to you and not based on any affiliation with the External Sites. The content of such External Sites is developed and provided by others and we do not endorse, guarantee, or assume responsibility for any advertisements, offers, or statements made by third parties concerning the Website or the Services. You should contact the site administrator and reference the terms of use associated with such External Sites if you have any questions or concerns regarding such Third-Party Services. We make no warranties or representations, express or implied, about such Third-Party Services. You acknowledge sole responsibility for and assume all risk arising from your use of any Third-Party Services.4. USER CODE AND USER CONTENTThe Website and the Services permit, allow or enable users to run or deploy certain code, including (without limitation) reference contracts developed and/or licensed by us, or developed by others incorporating code developed and/or licensed by us, deployed by you or another user through or integrated with the Services or that otherwise interacts with the Chainlink Network (“User Code”).If you submit or deploy User Code in connection with any Services or the Chainlink Network, you hereby grant the Foundation, its affiliates and any third party Service Providers to the Chainlink Network a worldwide, irrevocable, perpetual, non-exclusive, fully paid up and royalty-free right to use, reproduce or store such User Code solely for the purposes of (i) providing or performing the Services; (ii) distributing or promoting the Chainlink Network and Services; and (iii) developing and improving the Chainlink Network and the Services.The Website and the Services may allow or enable users to distribute, transmit or publish certain data on-chain; and to participate in other activities in which you may create, post, transmit, perform, or store content or other materials through the Website or the Services (collectively, “User Content”). All User Content must comport with these Terms and the Chainlink Community Code of Conduct.If you submit, transmit, display, perform, post or store User Content using the Website, you grant the Foundation and its sublicensees, to the fullest extent and for the maximum duration permitted by Applicable Law (including in perpetuity if permitted under Applicable Law), an unrestricted, worldwide, irrevocable, fully sublicensable, non-exclusive, and royalty-free right to (a) use, reproduce, modify, adapt, publish, translate, create derivative works from, distribute, perform and display such User Content in any form, format, media or media channels now known or later developed or discovered; and (b) use the name, identity, likeness and voice (or other biographical information) that you submit in connection with such User Content. Should such User Content contain the name, identity, likeness and voice (or other biographical information) of third parties, you represent and warrant that you have obtained the appropriate consents and/or licenses for your use of such features and that the Foundation and its sublicensees are allowed to use them to the extent indicated in these Terms. To the furthest extent permitted by Applicable Law, you hereby agree that the Foundation shall not be liable for any unauthorized copying, use or distribution of User Content by third parties and release and forever waive any claims you may have against the Foundation for any such unauthorized copying or usage of the User Content, under any theory.You are solely responsible for your User Code and User Content and the consequences of posting or publishing it on the Website or through the use of the Services. You represent and warrant that: (1) you are the creator and owner of the User Code or User Content or otherwise have sufficient rights and authority to grant the rights granted herein; (2) you have the necessary technical expertise and ability to develop, configure, modify, and/or deploy the User Code or User Content (as applicable), including your understanding that it is your responsibility to follow all best practices and other responsibilities including (without limitation) those set forth in the Data Feeds, Data Streams, Functions and CCIP and any other Service Responsibilities pages of the Website; (3) your User Code or User Content does not and will not (a) infringe, violate, or misappropriate any third-party right, including any copyright, trademark, patent, trade secret, moral right, privacy right, right of publicity, or any other intellectual property or proprietary right or (b) defame any other person; and (4) your User Code or User Content does not contain any harmful code, malware, virus, Trojan horse, worm, logic bomb, drop-dead device, backdoor, shutdown mechanism, adware, spyware or other malicious code. You further agree to indemnify and hold harmless the Foundation from any losses or liability of any kind, to you or any other user or third party, in connection with your User Content and any User Code developed, modified, or deployed by you or on your behalf. The Foundation reserves all rights and remedies against any users who breach these representations and warranties. Further, you agree that your User Content will comply with the guidelines issued by the U.S. Federal Trade Commission from time to time, as well as any other advertising guidelines required under applicable law. You are solely responsible for any endorsements or testimonials you make regarding any product or service through the Website.5. CHANGES; SUSPENSION; TERMINATIONThe Chainlink Network is intended to be decentralized and self-operating, with or without any Services provided by the Foundation. Accordingly, we may, at our sole discretion, from time to time and with or without prior notice to you, modify, suspend or disable, temporarily or permanently, the Services offered by the Foundation, in whole or in part, for any reason whatsoever, including, but not limited to, as a result of a security incident, your violation of these Terms, your failure to make payments required pursuant to the terms of your agreement with the Foundation or its affiliates or, in the Foundation’s good faith judgment, such changes, suspension or termination are necessary for the protection of the Chainlink Network.We will not be liable for any losses suffered by you or your customers or users, if applicable, resulting from any modification to any Services or from any suspension or termination, for any reason, of your access to all or any portion of the Website or the Services.All of these terms will survive any termination of your access to the Website or the Services, regardless of the reasons for its expiration or termination, in addition to any other provision which by law or by its nature should survive.6. ELECTRONIC NOTICESYou consent to receive all communications, agreements, documents, receipts, notices, and disclosures electronically (collectively, our “Communications”) that we provide in connection with these Terms or any Services. You agree that we may provide our Communications to you by posting them on the Website or through the Services or by emailing them to you at the email address you provide in connection with using the Services. You should maintain copies of our Communications by printing a paper copy or saving an electronic copy. You may also contact our support team to request additional electronic copies of our Communications by filing a support request at legal@chain.link.7. INDEMNIFICATIONYou will defend, indemnify, and hold harmless the Foundation, our members, directors, officers, employees, attorneys, agents, representatives, suppliers, licensors and contractors (collectively, \"Protected Parties”) from any claim, demand, lawsuit, action, proceeding, investigation, liability, damage, loss, cost or expense, including without limitation reasonable attorneys’ fees, arising out of or relating to your use of, or conduct in connection with, the Website, Services, the Chainlink Network or Link Tokens, Distributed Ledger Technology assets associated with your Distributed Ledger Technology Address, any other digital assets, any Feedback, User Code or User Content, including any use of or conduct by any Agent deemed to be acting on your behalf or using your credentials; your violation of these Terms; your violation of Applicable Law or regulations; any claims made by or against the Protected Parties by other members of the organization or entity on whose behalf you may be using the Website or Services; or your infringement or misappropriation of the rights of any other person or entity. If you are obligated to indemnify any Protected Party, the Foundation (or, at its discretion, the applicable Protected Party) will have the right, in its sole discretion, to control any action or proceeding and to determine whether the Foundation wishes to settle, and if so, on what terms.8. DISCLOSURES; DISCLAIMERSThe Foundation seeks to encourage the continued growth and success of the Chainlink Network as a public good. The Foundation does not operate a virtual currency or derivatives exchange platform or offer trade execution or clearing services and therefore has no oversight, involvement, or control with respect to your transactions, including Link Token purchases and sales.You are responsible for complying with all laws and regulations applicable to your transactions, including, but not limited to, the Commodity Exchange Act and the regulations promulgated thereunder by the U.S. Commodity Futures Trading Commission (“CFTC”), and the federal securities laws and the regulations promulgated thereunder by the U.S. Securities and Exchange Commission (“SEC”).You understand that the Foundation is not registered or licensed by the CFTC, SEC or any financial regulatory authority. No financial regulatory authority has reviewed or approved the use of the open-source software utilized by the Chainlink Network. The Website, the Services, and the Chainlink software do not constitute advice or a recommendation concerning any commodity, security or other asset. The Foundation is not acting as an investment adviser or commodity trading adviser to any person.The Foundation does not own or control the underlying software protocols that are used in connection with the Link Tokens. In general, the underlying protocols are open-source and anyone can use, copy, modify, and distribute them. The Foundation is not responsible for the operation of the underlying protocols, and the Foundation makes no guarantee of their functionality, security, or availability.You are solely responsible for ensuring that (i) any integrations or configurations with the Services deployed by or on your behalf are correct and (ii) any details entered in connection with a transaction using any smart contracts or similar technology related to the Services are accurate and complete. We are not responsible for any losses due to your errors, including (without limitation) your incorrectly constructed transaction, integration or configuration. Any documentation, draft transaction messages or other information we provide to you via the Website and Services is provided solely as a convenience to you and will not create any warranty or representation by us. Your use of such documentation, draft transaction messages or other information is entirely at your own risk.To the maximum extent permitted under Applicable Law, the Website and the Services (and any of their content or functionality) provided by or on behalf of us are provided on an “AS IS” and “AS AVAILABLE” basis, and we expressly disclaim, and you hereby waive, any representations, conditions or warranties of any kind, whether express or implied, legal, statutory or otherwise, or arising from statute, otherwise in law, course of dealing, or usage of trade, including, without limitation, the implied or legal warranties and conditions of merchantability, merchantable quality, quality or fitness for a particular purpose, title, security, availability, reliability, accuracy, quiet enjoyment and non-infringement of third-party rights. Without limiting the foregoing, we do not represent or warrant that the Website or the Services (including any related data) will be uninterrupted, available at any particular time or error-free. Further, we do not warrant that errors in the Website or the Services are correctable or will be corrected.You acknowledge that your User Code or User Content may be made public and your data on the Website or through the Services may become irretrievably lost or corrupted or temporarily unavailable due to a variety of causes, and agree that, to the maximum extent permitted under Applicable Law, we will not be liable for any loss or damage caused by denial-of-service attacks, software failures, misconduct by third-party users or service providers on the Chainlink Network, viruses or other technologically harmful materials (including those which may infect your computer equipment), protocol changes by third-party providers, Internet outages, force majeure events or other disasters, scheduled or unscheduled maintenance, or other causes either within or outside our control.The disclaimer of implied warranties contained in these Terms may not apply if and to the extent such warranties cannot be excluded or limited under the Applicable Law of the jurisdiction in which you reside.Certain Services may incorporate outputs from artificial intelligence or similar automated systems (“AI”). Any AI generated outputs are provided for informational purposes only and are not guaranteed to be complete or accurate. You are solely responsible for verifying and determining whether such outputs are appropriate before relying on or acting upon them, including through automated workflows, agents or similar tools. To the fullest extent permitted by law, the Foundation disclaims all liability arising from your use of or reliance on AI generated outputs. Certain Services may use or provide trusted execution environments, confidential workflow execution, and other confidential computing capabilities designed to enhance the confidentiality of workflow execution. These technologies do not eliminate security risks and may be impacted by software or design defects, hardware vulnerabilities, implementation errors, side-channel attacks, cryptographic weaknesses, third-party infrastructure failures, and other security events. The Foundation does not represent or warrant that use of such confidential computing capabilities will prevent unauthorized disclosure, loss, corruption, or compromise of confidential, sensitive, privileged, or other private information, secrets, credentials or workflow logic or that such confidential computing capabilities will be uninterrupted, error-free, or free from security vulnerabilities. Any attestations provided in support of a confidential computing capability are intended solely to provide evidence regarding the execution environment and do not constitute a representation or warranty that any execution environment is free from compromise, vulnerability or attack, or that confidential computation has occurred without error or interference. 9. EXCLUSION OF CONSEQUENTIAL AND RELATED DAMAGESIn no event will the Foundation, together with any Protected Party, be liable for any incidental, indirect, special, punitive, exemplary, consequential or similar damages or liabilities whatsoever (including, without limitation, damages for loss of data, information, revenue, goodwill, profits or other business or financial benefit) arising out of or in connection with the Website, the Services and the Chainlink Network (and any of their content and functionality), any execution or settlement of a transaction, any performance or non-performance of the Services, your Distributed Ledger Technology assets, other digital assets, Link Tokens or any other product, service or other item provided by or on behalf of a Protected Party, whether under contract, tort (including negligence), civil liability, statute, strict liability, breach of warranties, or under any other theory of liability, and whether or not any Protected Party has been advised of, knew of or should have known of the possibility of such damages and notwithstanding any failure of the essential purpose of these Terms or any limited remedy nor is the Foundation in any way responsible for the execution or settlement of transactions between users of Chainlink software or the Chainlink Network.10. LIMITATION OF LIABILITYIn no event will the Protected Parties' aggregate liability arising out of or in connection with the Website, the Services and the Chainlink Network (and any of their content and functionality), any performance or non-performance of the Services, your Distributed Ledger Technology assets, other digital assets, Link Tokens or any other product, service or other item provided by or on behalf of a Protected Party, whether under contract, tort (including negligence), civil liability, statute, strict liability or other theory of liability exceed the amount of fees paid by you to us under these Terms in the twelve (12) month period immediately preceding the event giving rise to the claim for liability.11. RELEASETo the extent permitted by applicable law, in consideration for being allowed to use the Website, the Services and/or the Chainlink Network, you and all other members of the entity or organization on whose behalf you are using the Website or Services and/or the Chainlink Network hereby release and forever discharge the Foundation and all Protected Parties from, and hereby waive and relinquish, each and every past, present and future dispute, claim, controversy, demand, right, obligation, liability, action and cause of action of every kind and nature (including personal injuries, death, and property damage), that has arisen or arises directly or indirectly out of, or that relates directly or indirectly to, the Website, the Services and/or the Chainlink Network (including any interactions with, or act or omission of, other Website or Chainlink Network users or any third-party services). YOU HEREBY WAIVE ANY APPLICABLE PROVISION IN LAW OR REGULATION IN CONNECTION WITH THE FOREGOING, WHICH STATES IN SUBSTANCE: “A GENERAL RELEASE DOES NOT EXTEND TO CLAIMS WHICH THE CREDITOR DOES NOT KNOW OR SUSPECT TO EXIST IN HIS OR HER FAVOR AT THE TIME OF EXECUTING THE RELEASE, WHICH IF KNOWN BY HIM OR HER MUST HAVE MATERIALLY AFFECTED HIS OR HER SETTLEMENT WITH THE DEBTOR.”12. DISPUTE RESOLUTION AND ARBITRATIONPlease read the following section carefully because it requires you to arbitrate certain disputes and claims with the Foundation and limits the manner in which you can seek relief from us, 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.You and the Foundation agree that any dispute arising out of or related to these Terms or our Services is personal to you and the Foundation and that any dispute will be resolved solely through individual action, and will not be brought as a class arbitration, class action or any other type of representative proceeding.Except for small claims disputes in which you or the Foundation seeks to bring an individual action in small claims court located in the county or other applicable jurisdiction where you reside or disputes in which you or the Foundation seeks injunctive or other equitable relief for the alleged unlawful use of intellectual property, you and the Foundation waive your rights to a jury trial and to have any dispute arising out of or related to these Terms or our Services resolved in court. Instead, for any dispute or claim that you have against the Foundation or relating in any way to the Services, you agree to first contact the Foundation and attempt to resolve the claim informally by sending a written notice of your claim (“Notice”) to the Foundation by email at legal@chain.link. The Notice must include your name, residence address, email address, and telephone number, describe the nature and basis of the claim and set forth the specific relief sought. Our notice to you will be similar in form to that described above. If you and the Foundation cannot reach an agreement to resolve the claim within thirty (30) days after such Notice is received, then either party may submit the dispute to binding arbitration administered by the American Arbitration Association (“AAA”), or, under the limited circumstances set forth above, in court. All disputes submitted to AAA will be resolved through confidential, binding arbitration before one arbitrator. Arbitration proceedings will be held in the Cayman Islands, in accordance with the AAA Consumer Arbitration Rules (“AAA Rules”). The most recent version of the AAA Rules are available on the AAA website and are hereby incorporated by reference. You either acknowledge and agree that you have read and understand the AAA Rules or waive your opportunity to read the AAA Rules and waive any claim that the AAA Rules are unfair or should not apply for any reason.To the extent applicable, including where the Federal Arbitration Act, 9 U.S.C. § 1, et seq. (the “FAA”) applies, the enforceability of this Section 12 shall be governed by applicable arbitration law. As limited by the FAA (where applicable), these Terms and the AAA Rules, the arbitrator will have exclusive authority to make all procedural and substantive decisions regarding any dispute and to grant any remedy that would otherwise be available in court, including the power to determine the question of arbitrability. The arbitrator may conduct only an individual arbitration and may not consolidate more than one individual’s claims, preside over any type of class or representative proceeding or preside over any proceeding involving more than one individual.The arbitrator, the Foundation, and you will maintain the confidentiality of any arbitration proceedings, judgments and awards, including, but not limited to, all information gathered, prepared and presented for purposes of the arbitration or related to the disputes. The arbitrator will have the authority to make appropriate rulings to safeguard confidentiality, unless the law provides to the contrary. The duty of confidentiality does not apply to the extent that disclosure is necessary to prepare for or conduct the arbitration hearing on the merits, in connection with a court application for a preliminary remedy or in connection with a judicial challenge to an arbitration award or its enforcement, or to the extent that disclosure is otherwise required by law or judicial decision.You and the Foundation agree that for any arbitration you initiate, you will pay the filing fee and the Foundation will pay the remaining AAA fees and costs. For any arbitration initiated by the Foundation, the Foundation will pay all AAA fees and costs. You and the Foundation agree that the courts of Grand Cayman sitting in the Cayman Islands have exclusive jurisdiction over any appeals and the enforcement of an arbitration award.Any claim arising out of or related to these Terms or our Services must be filed within one year after such claim arose; otherwise, the claim is permanently barred, which means that you and the Foundation will not have the right to assert the claim.You have the right to opt out of binding arbitration within 30 days of the date you first accepted the terms of this Section 12 by emailing us at legal@chain.link. In order to be effective, the opt-out notice must include your full name and address and clearly indicate your intent to opt out of binding arbitration.If any portion of this Section 12 is found to be unenforceable or unlawful for any reason, the unenforceable or unlawful provision will be severed from these Terms, severance of the unenforceable or unlawful provision will have no impact whatsoever on the remainder of this Section 12 or the parties’ ability to compel arbitration of any remaining claims on an individual basis under this Section 12, and to the extent that any claims must therefore proceed on a class, collective, consolidated, or representative basis, such claims must be litigated in a civil court of competent jurisdiction and not in arbitration, and the parties agree that litigation of those claims will be stayed pending the outcome of any individual claims in arbitration. Further, if any part of this Section 12 is found to prohibit an individual claim seeking public injunctive relief, that provision will have no effect to the extent such relief is allowed to be sought out of arbitration, and the remainder of this Section 12 will be enforceable. By opting out of binding arbitration, you are agreeing to resolve disputes in accordance with Section 12.13. GOVERNING LAWThe interpretation and enforcement of these Terms, and any dispute related to these Terms, the Website or the Services, will be governed by and construed and enforced in accordance with the laws of the Cayman Islands, as applicable, without regard to conflict of law rules or principles (whether of the Cayman Islands or any other jurisdiction) that would cause the application of the laws of any other jurisdiction. You agree that we may initiate a proceeding related to the enforcement or validity of our intellectual property rights in any court having jurisdiction. To the extent any claim, dispute, or legal proceeding arising out of or relating to these Terms is determined by a court of competent jurisdiction to be non-arbitrable or not otherwise subject to resolution under Section 12, the courts of the Cayman Islands shall have exclusive jurisdiction over such claim.14. RISK FACTORSYou acknowledge the following serious risks to any use of the Website or the Services or the Link Token and expressly agree to not hold any Protected Parties liable should any of the following risks occur:Risk of Regulatory Actions in One or More Jurisdictions: The Website or the Services or the Link Token could be impacted by one or more regulatory inquiries or regulatory actions, which could impede or limit the ability of the Foundation to continue to develop the Website or Services, or which could impede or limit your ability to use the Website or Services or the Link Token.Risk of Alternative, Unofficial Chainlink Networks: It is possible that alternative Chainlink-based networks could be established, which utilize the same open source code and open source protocol underlying the Chainlink Network and/or Services. The Chainlink Network may compete with these alternative Chainlink-based networks, which could potentially negatively impact the Chainlink Network, the Services and/or the Link Token.Risk of Insufficient Interest in the Chainlink Network or Distributed Applications: It is possible that the Chainlink Network will not be used by a large number of external businesses, individuals, and other organizations and that there will be limited public interest in the creation and development of distributed applications. Such a lack of interest could impact the development of the Chainlink Network and potential uses of Link Tokens. The Foundation cannot predict the success of its own development efforts or the efforts of other third parties.Risk that the Website and Services, as Developed, Will Not Meet the Expectations of User: You recognize that the Website, Services and the Chainlink Network are under development and may undergo significant changes over time. You acknowledge that any expectations regarding the form and functionality of the Chainlink Network held by you may not be met for any number of reasons including a change in the design and implementation plans, specifications and execution of the implementation of the Website, Services or the Chainlink Network.Risk of Security Weaknesses in the Chainlink Network Core Infrastructure Software: The Website, Services and the Chainlink Network rest on open-source software, and there is a risk that the Protected Parties, or other third parties not directly affiliated with the Foundation, may introduce weaknesses or bugs into the core infrastructural elements of the Website, Services or the Chainlink Network causing the system to lose Link Tokens stored in one or more of your accounts or other accounts or lose sums of other valued tokens. Furthermore, despite our good faith efforts to develop and maintain the Website, Services and the Chainlink Network, the Website, Services and the Chainlink Network may experience malfunctions or otherwise fail to be adequately developed or maintained, which may negatively impact the Website, Services, the Chainlink Network and Link Tokens.Risk of Weaknesses or Exploitable Breakthroughs in the Field of Cryptography: Cryptography is an art, not a science. And the state of the art can advance over time. Advances in code cracking, or technical advances such as the development of quantum computers, could present risks to cryptocurrencies and the Website, Services and the Chainlink Network which could result in the theft or loss of Link Tokens. To the extent within its control and otherwise possible, the Foundation intends to update the protocol underlying the Services and the Chainlink Network to account for any advances in cryptography and to incorporate additional security measures, but it cannot predict the future of cryptography or guarantee that any security updates will be made in a timely or successful manner.Risk of Blockchain Network Attacks: Any blockchain used for the Services and/or the Chainlink Network may be susceptible to mining attacks, including but not limited to: double-spend attacks, reorganizations, majority mining power attacks, “selfish-mining” attacks, and work race condition attacks. Any successful attacks present a risk to the Services, the Chainlink Network, expected proper execution and sequencing of transactions, and expected proper execution and sequencing of contract computations. Known or novel mining attacks may be successful.Risk of Rapid Adoption and Insufficiency of Computational Application Processing Power of the Services and the Chainlink Network: If the Services and/or the Chainlink Network are rapidly adopted, the demand for transaction processing and distributed application computations could rise dramatically and at a pace that exceeds the rate with which Chainlink services can be provided. Under such a scenario, the Services and Chainlink Network could become destabilized, due to the increased cost of running distributed applications. In turn, this could dampen interest in the Services, the Chainlink Network and Link Tokens. Insufficiency of computational resources and an associated rise in the price of Link Tokens could result in businesses being unable to acquire scarce computational resources to run their distributed applications. This could result in lost revenues and disruption or halting of business operations.Risks Associated with New and Evolving Laws: The Chainlink Network, and by extension the Website and Services, may be subject to a variety of international laws and regulations, including those with respect to financial or securities regulations, consumer privacy, data protection, consumer protection, content regulation, network neutrality, cyber security, data protection, intellectual property (including copyright, patent, trademark and trade secret laws), defamation, and others. Such laws and regulations, and the interpretation or application of these laws and regulations, could change. In addition, new laws or regulations affecting the Chainlink Network could be enacted. As the Website, Services and Chainlink Network evolve, we may be subject to new laws, and the application of existing laws to us might change. These laws and regulations are frequently costly to comply with and may divert a significant portion of the Foundation’s attention and resources or restrict the way the Chainlink Network may operate. If we fail to comply with these applicable laws or regulations, we could receive negative publicity and be subject to significant liabilities which could adversely impact the Website, Services, and the Chainlink Network and Link Tokens. Additionally, Chainlink node operators of the Chainlink Network may be subject to industry specific laws and regulations or licensing requirements. If any of these parties fails to comply with any of these licensing requirements or other applicable laws or regulations, or if such laws and regulations or licensing requirements become more stringent or are otherwise expanded, the Chainlink Network and/or Link Tokens could be adversely impacted.Market Risks: Link Tokens are intended to be used solely in connection with the Chainlink Network, and we do not support or otherwise facilitate any secondary trading or external valuation of Link Tokens. This restricts the contemplated avenues for using Link Tokens, and could therefore create illiquidity risk to Link Tokens you hold. Even if secondary trading of Link Tokens is facilitated by third-party exchanges, such exchanges may be relatively new and subject to little or no regulatory oversight, making them more susceptible to market-related risks. Furthermore, to the extent that third parties do ascribe an external exchange value to Link Tokens (e.g., as denominated in a digital or fiat currency), such value may be extremely volatile and diminish to zero.Specific Risks Relating to Value and Function of Link Tokens: The utility benefits of using Link Tokens to access services provided by Chainlink node operators can only materialize through user-driven adoption over time. Such adoption depends on a variety of factors, including the pace of user adoption, the organic community-driven expansion of the Chainlink Network. As such, the extent of user adoption is entirely outside of our control and cannot be stated with any certainty. The price of Link Tokens may fluctuate in response to competitive and market conditions affecting the general supply of and demand for user-requested services. These conditions are beyond our control. The value of Link Tokens on the Chainlink Network may be lower than the price at which it was purchased. The utility of Link Tokens, and any value associated with that utility, will depend on the ability of the Chainlink Network to adequately facilitate user-requested services. Inadequate supply may result in such services taking more time, while inadequate demand may make it difficult to obtain services, both of which may discourage participation in the Chainlink Network. The compensation for providing Chainlink node services in the Chainlink Network will depend on the resale price for the Link Tokens received for such services, which may be lower than the compensation that might have been received through other arrangements. No promises of future performance or value are or will be made with respect to Link Token, including no promise of inherent value, no promise of continuing payments, and no guarantee that Link Token will hold any particular value.Risks Relating to User Code and Third-Party Integrations and Configurations: Third parties such as application developers, blockchain development teams, token developers and Chainlink node operators have important responsibilities to ensure that their integration and use of the Chainlink Network is secure and performant. Users and other third parties may fail to, among other things, properly integrate or configure their use of the Chainlink Network, follow security best practices, implement upgrades or monitor and assess risks, as applicable. The failure of users and other third parties to take such action could result in security risks, hacks or exploits, or could otherwise impede your access to the Services.Unanticipated Risks: Cryptographic tokens such as Link Tokens are a new and untested technology. In addition to the risks included in these Terms, there are other risks associated with the Services, the Chainlink Network and Link Tokens, including those that the Foundation cannot anticipate. Such risks may further materialize as unanticipated variations or combinations of the risks discussed in these Terms.15. MISCELLANEOUSAny right or remedy of the Foundation set forth in these Terms is in addition to, and not in lieu of, any other right or remedy whether described in these Terms, under Applicable Law, at law or in equity. Our failure or delay in exercising any right, power, or privilege under these Terms will not operate as a waiver thereof. The invalidity or unenforceability of any of these Terms will not affect the validity or enforceability of any other of these Terms, all of which will remain in full force and effect. We will have no responsibility or liability for any failure or delay in performance of the Website or any of the Services, or any loss or damage that you may incur, due to any circumstance or event beyond our control, including without limitation any flood, extraordinary weather conditions, earthquake, or other act of God, fire, war, insurrection, riot, labor dispute, accident, action of government, communications, power failure, or equipment or software malfunction. You may not assign or transfer any right to use the Website or the Services, or any of your rights or obligations under these Terms, without our express prior written consent, including by operation of law or in connection with any change of control. We may assign or transfer any or all of our rights or obligations under these Terms, in whole or in part, without notice or obtaining your consent or approval. Headings of sections are for convenience only and will not be used to limit or construe such sections. These Terms contain the entire agreement and supersede all prior and contemporaneous understandings between the parties regarding the Website and the Services. If there is a conflict between these Terms and any other agreement you may have with us, these Terms will control unless the other agreement specifically identifies these Terms and declares that the other agreement supersedes these Terms.CONTACT INFORMATION:Email: legal@chain.link© 2026 Chainlink FoundationAll rights reserved. All trademarks, logos and service marks displayed on the Website and the Chainlink Network are our property or the property of other third parties.Trademark GuidelinesThe Chainlink Foundation (the “Foundation”) has developed these guidelines (“Guidelines”) to ensure that the Foundation trademarks and service marks (“Marks”) are properly displayed and used. As the owner of its Marks, the Foundation has exclusive rights to use its Marks and is obligated to prevent others from using its Marks inappropriately. If use of the Foundation’s Marks is authorized, it is expected that you will comply in all respects with the requirements and conditions set forth in these Guidelines and in any other guidelines promulgated by the Foundation. Nothing contained in these Guidelines should be construed as granting, by implication, estoppel, or otherwise, any license or right in and to the Marks or other intellectual property owned by the Foundation. Unauthorized use of any of the Marks or the Foundation’s other intellectual property may violate the law. All rights not expressly granted herein are reserved by the Foundation.PROHIBITED USEIn order to ensure that you do not infringe on any the Marks, you must avoid doing any of the following without the prior written permission of the Foundation:Using a Mark in a manner that is likely to directly or indirectly imply either an affiliation with or an endorsement by the Foundation of specific products, goods, services, materials, courses, or programs.Using the Chainlink logo or any Foundation logo in your materials except as expressly permitted under these Guidelines or with the Foundation’s prior written consent.Using a Mark in a manner that is likely to confuse the public about the origin of products, goods, services, materials, courses, or programs.Using a mark similar enough to a Mark owned by the Foundation that it could be confused for a Foundation Mark (considering visual, phonetic and connotations of the marks).Altering, adapting, modifying, animating or morphing any Marks.Using the Foundation name or Marks as the visual focal point of any materials.Using a Mark in a manner that is likely to dilute, defame, disparage, or harm the reputation of the Foundation or the Chainlink network.PERMISSIBLE REFERENCES TO FOUNDATION MATERIALSThe Foundation acknowledges that the use of Marks may be necessary to describe the subject matter of some materials, products, and/or programs. Consequently, the Foundation does allow descriptive uses of its Marks; however, the name of the Foundation and other Marks, may be used only when necessary to describe the subject matter of the materials, products, and/or programs. All uses must be accurate and descriptive in nature so there is no likelihood of confusion to the public.TRADEMARK PERMISSION REQUESTSTo request permission to use a Foundation Mark, please contact the Foundation at legal@chain.link.DISCLAIMERThese Guidelines are not intended to serve as legal advice. Should you have questions regarding your legal rights or duties, pl","tokens":15000,"squid":"spider-08","role":"Oracle Spider","at":1791348602007,"hash":"8001bc95c82cf638b07e7cdc6328d236ea054077"}
{"url":"https://chain.link/privacy-policy","domain":"chain.link","title":"Privacy Policy | Chainlink","text":"Copy as PNGCopy as SVGDownload all logosView brand guidelinesHome/Privacy PolicyEffective date:September 6, 2024We take your privacy seriously. This Privacy Policy describes how we collect, use and share your personally identifiable information (“Personal Information”) that we receive from you when you visit our website or which we otherwise receive or collect from you in the course of, or in connection with, your use of our site located at https://chain.link and all associated sites (the “Website”), the pursuit of our mission to (our “Services”) and our operations. Please read the following to learn more about our Privacy Policy.This Privacy Policy covers our treatment of Personal Information that we gather when you are accessing or using our Website and Services, but does not apply to the practices of companies we don’t own or control, or people that we don’t manage. When we mention the “Foundation,” “we,” “us” or “our'' in this Privacy Policy, we are referring to the Chainlink Foundation and its subsidiaries and affiliates.By using or accessing the Website and the Services in any manner, you acknowledge that you accept the practices and policies outlined in this Privacy Policy, and you hereby consent that we will collect, use, and share your information in the following ways.We’re constantly trying to improve our Website and Services, so we may need to change this Privacy Policy from time to time. If we make changes, we will notify you by revising the date at the top of this policy and, in some cases, we may provide you with additional notice (such as adding a statement to our Website or sending you a notification). We encourage you to review this Privacy Policy regularly to stay informed about our information practices and the choices available to you.Remember that your use of our Website and Services is at all times subject to the Terms of Service, which incorporates this Privacy Policy. Any terms we use in this Privacy Policy without defining them have the definitions given to them in the Terms of Service.What does this Privacy Policy cover?We gather various types of Personal Information from our users, as explained in more detail below, and we use this Personal Information internally in connection with the Website and our Services, including to provide, and improve our services, to contact you, to fulfill your requests for certain products and services, and to analyze how you use the Website and the Services. In certain cases, we may also share some Personal Information with third parties, but only as described below. By using the Website and our Services, you consent to the collection of this information and the uses and disclosures described in this policy and the Terms.We do not knowingly collect or solicit Personal Information from anyone under the age of 13. If you are under 13, please do not attempt to send any Personal Information about yourself to us. If we learn that we have collected Personal Information from a child under age 13, we will delete that information as quickly as possible. If you believe that a child under 13 may have provided us with Personal Information, please contact us at Legal@chainlinkfoundation.org.What Personal Information does the Foundation collect?Information you provide to us: We receive and store any information you knowingly provide to us. For example, you share information directly with us when you fill out a form, submit or post content through our Services, make a purchase, communicate with us via third-party platforms, participate in a contest or promotion, request customer support, or otherwise communicate with us. The types of personal information we may collect include your name, email address, postal address, phone number, social media handle, and payment information, and any other information you choose to provide. We may communicate with you if you’ve provided us the means to do so. For example, if you’ve given us your email address, we may email you about your use of the Services. Also, we may receive a confirmation when you open an email from us. This confirmation helps us make our communications with you more interesting and improve our Services. If you do not want to receive communications from us, please indicate your preference by unsubscribing.Information collected automatically: Whenever you interact with our Website, we automatically receive and record information on our server logs from your browser or device, which may include your IP address, geolocation data, device identification, “cookie” information, the type of browser and/or device you’re using to access the Website, and the page or feature you requested. “Cookies” are identifiers we transfer to your browser or device that allow us to recognize your browser or device and tell us how and when pages and features in our Services are visited and by how many people. You may be able to change the preferences on your browser or device to prevent or limit your device’s acceptance of cookies, but this may prevent you from taking advantage of some of our features. For more information about cookies and how to disable them, see the Your Choices section below.We may use this data to improve the Services – for example, this data can tell us how often users use a particular feature of the Services or Website, and we can use that knowledge to make the Services interesting to as many users as possible.Information collected from other websites and do not track policy: Through the cookies we place on your browser or device, we may collect information about your online activity after you leave the Website. Just like any other usage information we collect, this information allows us to improve the Website and the Services, and is otherwise used as described in this Privacy Policy. Your browser may offer you a “Do Not Track” option, which allows you to signal to operators of websites and web applications and services (including behavioral advertising services) that you do not wish such operators to track certain of your online activities over time and across different websites. Our Website does not support Do Not Track requests at this time, which means that we collect information about your online activity both while you are using the Website or the Services and after you leave.How does the Foundation use my information?We use the Personal Information we collect to maintain, and improve our Services and Website. We also use the Personal Information we collect to: If you elect, communicate with you about products, services, and events offered by the Foundation and others and provide news and information that we think will interest you (see the Your Choices section below for information about how to opt out of these communications at any time);Process transactions and send you related information, including confirmations, receipts, invoices, customer experience surveys, and notices;Send you technical notices, security alerts, and support and administrative messages;Respond to your comments and questions and provide customer service;Monitor and analyze trends, usage, and activities in connection with our Services;Personalize the advertisements you see on third-party platforms and websites (for more information, see the Your Choices section below);Facilitate contests, sweepstakes, and promotions and process and deliver entries and rewards;Detect, investigate, and prevent security incidents and other malicious, deceptive, fraudulent, or illegal activity and protect the rights and property of the Foundation and others;Debug to identify and repair errors in our Services;Comply with our legal and financial obligations; andCarry out any other purpose described to you at the time the information was collected.Will the Foundation share any of the Personal Information it receives?We may share your Personal Information with third parties as described in this section. By using the Website and the Services, or engaging in any transaction or service described below, you consent to our disclosure of your Personal Information to such third parties.Information that’s been de-identified: We may de-identify your Personal Information so that you are not identified or identifiable as an individual, and provide that information to our partners. We may also provide aggregate usage information to our partners (or allow partners to collect that information from you), who may use such information to understand how often and in what ways people use our Services, so that they, too, can provide you with an optimal online experience. However, we never disclose aggregate usage or de-identified information to a partner (or allow a partner to collect such information) in a manner that would identify you as an individual person.Affiliated businesses: In certain situations, businesses or third party websites we’re affiliated with may sell or provide products or services to you through the Website or in connection with the Services (either alone or jointly with us). You can recognize when an affiliated business is associated with such a transaction or service, and we will share your Personal Information with that affiliated business only to the extent that it is related to such transaction or service. We have no control over the policies and practices of third party websites or businesses as to privacy or anything else, so if you choose to take part in any transaction or service relating to an affiliated website or business, please review all such business’ or websites’ policies.Agents: We employ other companies and people to perform tasks on our behalf and need to share your information with them to provide products or services to you; for example, we may use a payment processing company to receive and process your transactions for us. Unless we tell you differently, our agents do not have any right to use the Personal Information we share with them beyond what is necessary to assist us.Community groups: If you are a member of a Chainlink Network community group, members known as Community Advocates may have access to the content within their groups. Network administrators find it helpful to have access to the email addresses of organizers and other members of groups within their networks, to easily communicate with and administer the groups. Therefore, we may ask if you want to share your email address with your group’s Community Advocate.Business transfers: We may choose to buy or sell assets, and may share and/or transfer customer information in connection with the evaluation of and entry into such transactions. Also, if we (or our assets) are acquired, or if we go out of business, enter bankruptcy, or go through some other change of control, Personal Information could be one of the assets transferred to or acquired by a third party.Protection of the Foundation and others: We reserve the right to access, read, preserve, and disclose any information that we believe is necessary to comply with law, regulation or court order or legal process or obtain advice; enforce or apply our Terms of Service and other agreements; or protect the rights, property, or safety of the Foundation, our users, or other persons.Third parties that you authorize: We will share your information with other third parties if you specifically authorize us to do so.Transfers of Information to Other CountriesWe have operations and service providers in other countries, including countries outside of the European Economic Area (EEA). Therefore, we and our service providers may transfer your Personal Information to, or store or access it in, jurisdictions that may not provide levels of data protection that are equivalent to those of your home jurisdiction. By using the Website and/or Services, you acknowledge and agree to such transfers and processing. We will take steps to ensure that your Personal Information receives an adequate level of protection in the jurisdictions in which we process it.Your ChoicesCookies. Most web browsers are set to accept cookies by default. If you prefer, you can usually adjust your browser settings to remove or reject browser cookies. Please note that removing or rejecting cookies could affect the availability and functionality of our Services.Communication Preferences. You may opt out of receiving promotional emails from the Foundation by following the instructions in those communications or by emailing us at Legal@chainlinkfoundation.org. If you opt out, we may still send you non-promotional emails, such as those about our ongoing business relations.Advertising and Analytics: We allow others to provide analytics services and serve advertisements on our behalf across the web and in mobile apps. These entities may use cookies, web beacons, device identifiers, and other technologies to collect information about your use of our Website and Services and other websites and applications, including your IP address, web browser, mobile network information, pages viewed, time spent on pages, links clicked, and conversion information. This information may be used by the Foundation and others to, among other things, analyze and track data, determine the popularity of certain content, deliver advertising and content targeted to your interests on our Services and other websites, and better understand your online activity. For more information about interest-based ads, or to opt out of having your web browsing information used for behavioral advertising purposes, please visit www.aboutads.info/choices Your device may also include a feature (“Limit Ad Tracking” on iOS or “Opt Out of Interest-Based Ads” or “Opt Out of Ads Personalization” on Android) that allows you to opt out of having certain information collected through mobile apps used for behavioral advertising purposes.We also work with third parties to serve ads to you as part of customized campaigns on third-party platforms (such as Reddit). As part of these ad campaigns, we or the third-party platforms may convert information about you, such as your activity information, into a unique value that can be matched with a user account on these platforms to allow us to learn about your interests and serve you advertising that is customized to your interests. Note that the third-party platforms may offer you choices about whether you see these types of customized ads.Additional Disclosures for Individuals in Europe If you are located in the EEA, the United Kingdom, or Switzerland, you have certain rights and protections under the law regarding the processing of your Personal Information, and this section applies to you.Legal Basis for Processing: When we process your Personal Information, we will do so in reliance on the following lawful bases:To perform our responsibilities under our contract with you (e.g., processing payments for and providing the Services you requested).When we have a legitimate interest in processing your Personal Information to operate our business or protect our interests (e.g., to provide, maintain, and improve our products and services, conduct data analytics, and communicate with you).To comply with our legal obligations (e.g., to maintain a record of your consents and track those who have opted out of marketing communications).When we have your consent to do so (e.g., when you opt in to receive marketing communications from us). When consent is the legal basis for our processing of your Personal Information, you may withdraw such consent at any time.Questions or Complaints: If you have a concern about our processing of Personal Information that we are not able to resolve, you have the right to lodge a complaint with the Data Protection Authority where you reside. Contact details for your Data Protection Authority can be found using the links below:For individuals in the EEA: https://edpb.europa.eu/about-edpb/board/members_enFor individuals in the UK: https://ico.org.uk/global/contact-us/For individuals in Switzerland: https://www.edoeb.admin.ch/edoeb/en/home/the-fdpic/contact.htmlCertain information for California residentsThe California Consumer Privacy Act or “CCPA” (Cal. Civ. Code § 1798.100 et seq.) affords consumers residing in California certain rights with respect to their personal information. If you are a California resident, this section applies to you.California Consumer Privacy Act: In the preceding 12 months, we have collected the following categories of Personal Information: identifiers, commercial information, internet or electronic network activity information, professional or employment related information, education information, financial information, and information derived from other personal information about you. For details about the precise data points we collect and the categories of sources of such collection, please see the Collection of Information section above. We collect Personal Information for the business and commercial purposes described in the Use of Information section above. In the preceding 12 months, we have disclosed the following categories of personal information for business purposes to the following categories of recipients:Category of Personal InformationIdentifiers;Commercial Information;Internet or other electronic network activity information;Professional or employment information;Education information;Financial information; andInformation derived from other personal information about you.Categories of RecipientsPartners, including vendors and service providers;Companies under common control and ownership; andApps, websites, and third-party integrations on or using our Website or Services.The Foundation does not sell your personal information. We do allow our advertising partners to collect certain electronic network activity via our Website and Services to show ads that are targeted to your interests. To opt out of having your Personal Information used for targeted advertising purposes, please see the Your Choices section above.Subject to certain limitations, you have the right to (1) request to know more about the categories and specific pieces of personal information we collect, use, and disclose, (2) request deletion of your personal information, and (3) not be discriminated against for exercising these rights. You may make these requests by emailing Legal@chainlinkfoundation.org. We will verify your request by asking you to provide information related to your recent interactions with us, such as information provided on a form you’ve filled out. We will not discriminate against you if you exercise your rights under the CCPA.If we receive your request from an authorized agent, we may ask for evidence that you have provided such agent with a power of attorney or that the agent otherwise has valid written authority to submit requests to exercise rights on your behalf. We may deny a request from an authorized agent that does not submit proof that they have been authorized by you to act on your behalf. If you are an authorized agent seeking to make a request, please contact us.DATA SUBJECT REQUESTS AND DATA RETENTIONSubject to certain limitations, you have the right to request access to the Personal Information we hold about you and to receive your data in an accessible and portable format, the right to ask that your Personal Information be corrected or erased, and the right to object to, or request that we restrict, certain processing. If you would like to exercise any of these rights, please email us at Legal@chainlinkfoundation.org.We store Personal Information for as long as necessary to carry out the purposes for which we originally collected it and for other legitimate business purposes, including to meet our legal, regulatory, or other compliance obligations.What if I have questions about this policy?If you have any questions or concerns regarding this Privacy Policy, please send us a detailed message to Legal@chainlinkfoundation.org, and we will try to resolve your concerns.","tokens":4986,"squid":"spider-08","role":"Oracle Spider","at":1791348611939,"hash":"d9baef9dcd9b4f6d7dd5da991b4144db8f9202d2"}
{"url":"https://ethresear.ch/t/payload-timeliness-committee-ptc-an-epbs-design/16054/7","domain":"ethresear.ch","title":"Payload-timeliness committee (PTC) – an ePBS design - Proof-of-Stake - Ethereum Research","text":"Proof-of-Stake\n\n mev,proposer-builder-separation\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n read \n\n 12\n min\n\n Jul 2023\n\n 7 / 7\n\n Aug 2023\n\n Aug 2023\n\n post by mikeneuder on Jul 6, 2023\n\n mikeneuder\n\n Payload-timeliness committee (PTC) – an ePBS design\nby mike & francesco – based on discussions with potuz & terence – july 6, 2023\n\\cdot⋅\nh/t Potuz for coming up with the idea of not giving the builder block explicit fork-choice weight, but rather using a committee to decide on the timeliness of the payload. This document is the result of a number of iterations on this concept.\n\\cdot⋅\ntl;dr; We present a new design for ePBS called Payload-Timeliness Committee (abbr. PTC). We include: a high-level overview, the new honest attesting behavior, and an initial analysis of the properties and potential new attack vectors. This document omits the formal specification, which will follow as we gain confidence in the soundness of this design.\n\\cdot⋅\nMany thanks to Danny, Barnabé, Caspar, Toni, Vitalik, Justin, Jon, stokes, Jacob, Aditya, and Chris for relevant discussions.\n\nNew concepts\n\npayload-timeliness committee (PTC) – a subset of the attestation committee from each slot that votes on the builder’s payload release.\nfull, empty, and missing blocks – a full block has a valid ExecutionPayload that becomes canonical (results in an update to the EL state). An empty block is a CL block does not have a canonical ExecutionPayload (does not update the EL state). A missing block is an empty slot that becomes canonical. With block-slot voting, missing blocks can have fork-choice weight.\npayload-timeliness (PT) votes – the set of votes cast by the PTC.\n\nThe PT votes for slot N are only used by the proposer and attesting committee in slot N+1.\nThe PT votes for slot N determine the proportion of the fork-choice weight given to the full vs. empty versions of the slot N block.\n\nNote – Throughout this document, we describe block-slot voting as a prerequisite for PTC. However, we can make use of the existing voting mechanics and treat ancestral block votes in slot N as votes for the missing version of the slot N block. For clarity in the examples, we describe missing as part of the competing fork, but adding pure block-slot voting may not be necessary in practice.\nDesign overview\nWe first present a minimal description of the new design. Note that this does not include the full specification of behavior and is intended to present the high-level details only.\nOld slot anatomy\nPresently, the 12 second slot is partitioned into the following three phases. Figure from Time, slots, and the ordering of events in Ethereum Proof-of-Stake.\nupload_0ad62632f94d94974f544f1b20a6c9ff1577×565 67.3 KB\nFlow\n\nAt t=0 block proposed by the elected PoS validator.\nAt t=4, the attestation deadline, the attesting committee for slot N uses the fork-choice rule to determine the head of the chain in their view and makes an attestation.\nAt t=8 the aggregate attestations are sent.\nAt t=12 the next proposer builds on whatever head they see according to their fork-choice view.\n\nNew slot anatomy\nThe new slot contains an additional phase for the PT votes to propagate.\nupload_516b236ef25496ffda5566b3db21218a2038×533 97 KB\nFlow\n\nThe slot N block that is published at t=t0 is the CL block proposed by the elected PoS validator. This block contains a builder bid, but no ExecutionPayload.\nThe attestation deadline at t=t1 is unchanged. The entire attesting committee for slot N uses the fork-choice rule to determine the head of the chain in their view and makes an attestation.\nThe broadcast of aggregate attestations for the slot still begins at t=t2. Additionally, the builder publishes their execution payload if they have not seen an equivocation from the proposer (the builder does not need to have a full view of the attestations).\nAt t=t3 the PTC casts their vote for whether the payload was released on time.\nAt t=t4 the slot N+1 proposer publishes their block, building on either the full or empty block based on the PT votes and attestations that they have seen.\n\nNote – Timestamps are not specified because we can adjust the duration of each phase based on performance testing. The key details are what happens in the four phases and at the boundaries.\nNote 2 – Depending on the size of the PTC, we may need a fifth slot phase to aggregate the votes of said committee. Larger committees may need aggregation, but are more secure, which is the design tradeoff.\nBlock production\nThe full block is assembled in two phases. First, the CL (beacon) block is produced with a commitment to a builder bid. Any double-signing of this block represents a proposer’s equivocation. Once the builder has observed the CL block, they produce their ExecutionPayload to construct the full version of the block. The PTC casts votes on the timeliness of this object in their view.\nupload_16a2060853c41b28b83f27c03a64d5421389×880 105 KB\nThe slot N committee votes on the CL block, while the slot N PTC observes the payload release, which informs the fork-choice rule in the subsequent slot. We propose that the PTC is a strict subset of the slot N attesting committee (e.g., the first 1000 members).\n\nHonest attesting behavior\nConsider the honest attesting committee at t=t1 of slot N+1. Assume that there was a block in slot N and the slot N+1 proposer built a child block (it extends w.l.o.g. to missing blocks in either slot). The slot N+1 block could either build on the empty or full block from slot N. Similarly, the PTC cast their votes on full or empty based on the payload-timeliness at t=t3 of the previous slot. The attesting committee in slot N+1 assigns weight to the full vs empty block respectively by using the proportion of PT votes from slot N.\nExamples\nAssume the slot N block is canonical and received 100% of the slot N attestations. Let W denote the total weight of each attesting committee. PT indicates the payload-timeliness vote and boost is the 40% proposer boost given to each proposer block.\nCase 1\nupload_fb7fdc053bc36a887afec78cf836f4e21124×815 21.2 KB\nThe slot N PTC is split, with 51% voting for the full block and 49% voting for the empty block. The slot N+1 proposer builds on the empty block and is given proposer boost, which is equivalent to 40% of the weight of the attesting committee. The attesting committee at N+1 now sees a split and has to choose between attesting to N+1 or N+1,missing. The PT votes divide the attestation weight of the slot N attestations, so we have,\n\nweight(N+1) = 0.49W + 0.4W = 0.89W,\n𝑤𝑒𝑖𝑔ℎ𝑡(𝑁+1)=0.49𝑊+0.4𝑊=0.89𝑊,\nwhile,\n\nweight(N+1,missing) = 0.51W.\n𝑤𝑒𝑖𝑔ℎ𝑡(𝑁+1,𝑚𝑖𝑠𝑠𝑖𝑛𝑔)=0.51𝑊.\nThus, the attesters vote for N+1 (the top fork).\nCase 2\nupload_0a5354622de22951feca56b75174ae951149×836 22.4 KB\nHere we have 100% of the PT votes agreeing that the block should be full. Now the attesting committee for slot N+1 votes against the proposer, and for N+1,missing because\n\nweight(N+1) = 0.4W < weight(N+1,missing) = W.\n𝑤𝑒𝑖𝑔ℎ𝑡(𝑁+1)=0.4𝑊<𝑤𝑒𝑖𝑔ℎ𝑡(𝑁+1,𝑚𝑖𝑠𝑠𝑖𝑛𝑔)=𝑊.\nIn this case, the PTC from slot N overrules the slot N+1 proposer, who clearly built on the wrong head. The bottom fork wins.\nCase 3\nupload_121a77b1cbbd1cc377195d2f496d43ee1164×823 21.5 KB\nIn the worst case, the slot N+1 attesters see this split view. Here\n\nweight(N+1) = 0.7W = weight(N+1,missing),\n𝑤𝑒𝑖𝑔ℎ𝑡(𝑁+1)=0.7𝑊=𝑤𝑒𝑖𝑔ℎ𝑡(𝑁+1,𝑚𝑖𝑠𝑠𝑖𝑛𝑔),\nand they have to tie-break to determine which fork to vote for. The key here is that this split is difficult to achieve because you need 70% of the PTC to vote for full, while the proposer builds on empty. More on this in “Splitting considerations” (below).\n\nAnalysis\nThe properties specified below were initially presented in Why enshrine Proposer-Builder Separation? A viable path to ePBS. We modify honest-builder payload safety to the weaker condition of honest-builder same-slot payload safety.\nProperties\n\nhonest-builder payment safety – if an honest builder is selected and their payment is processed, their payload becomes canonical.\nhonest-proposer safety – if an honest proposer commits to a single block on time, they will unconditionally receive the payment from the builder for the bid they committed to.\nhonest-builder same-slot payload safety – if an honest builder publishes a payload, they can be assured that no competing payload for that same slot will become canonical. This protects builders from same-slot unbundling. Note: This property relies on a 2/3 honest majority assumption of the validator set.\n\nNon-properties\n\nhonest-builder payload safety – the builder cannot be sure that if they publish the payload, it will become canonical. The builder is not protected from next-slot unbundling (the builder is not protected from that in mev-boost either, as length-1 reorgs happen regularly). More on this in “Splitting considerations” (below).\n\nNote – In terms of CL engineering, making the transition function able to process empty blocks is important. Because empty blocks will not update the EL state, they must exclude withdrawals.\n\nBuilder payment processing\n\nBuilder payments are processed during the epoch finalization process (open for discussion, could just be on a one-epoch lag). The payment takes place if both of these conditions are satisfied:\n\nThe builder ExecutionPayloadHeader is part of the canonical chain (i.e., the CL block for that slot is not missing). This includes two cases:\n\nThe corresponding ExecutionPayload is also part of the canonical chain (the happy-path) (i.e., the CL block for that slot is full).\nThe builder ExecutionPayloadHeader is part of the canonical chain even if the corresponding ExecutionPayload is not (consensus that the builder was not on time) (i.e., the CL block for that slot is empty).\n\nThere is no evidence of proposer equivocation.\n\nA builder who sees an equivocation can get the validator slashed. Any slashed validator will not receive the unconditional builder payment.\n\nDifferences from other designs\n\nThe payload timeliness determines how to allocate the fork-choice vote, but it cannot create a separate fork.\nThe payload view determines how the subsequent attesting committee votes.\nThe builder is never given a proposer boost or explicit LMD-GHOST weight.\nThe unconditional payments are handled asynchronously, after enough time has passed for equivocations to be detected and the corresponding validators to be slashed.\nThe PT votes only inform the attesting behavior of the subsequent slot. Similar to proposer boost, the effect is bound to a single slot.\n\nSplitting considerations\n“Splitting” is an action undertaken by a malicious participant to divide the honest view of the network. In today’s PoS, proposers can split the network by timing the release of their block near the attestation deadline. Some portion of the network will see the block on time, while other will vote for the parent block because it was late. Proposer boost is the mechanism in-place to give the next proposer power to resolve these forks if the weight of competing branches is evenly split. The PTC introduces more potential splitting vectors, which we present below.\nProposer-initiated splitting\nFirst, consider the case where the proposer splits the chain in an attempt to grief the builder.\nupload_79750da5a56789643d5cf7ab16a1e2fa1929×1086 262 KB\nThe sequence of events is as follows:\n\nThe slot N proposer releases their block near the attestation deadline, causing a split of the honest attesting set. 50% of the honest attesters saw it on time and voted for the block, while the other 50% did not see it on time and thus voted for a missing block.\nThe builder of the header included in the block must make a decision about releasing the payload that corresponds to this block. The block is either full or empty based on that decision.\nThe slot N+1 proposer resolves the split by building on the missing, full, or empty head (any of the blue blocks). Because the proposer will have a boost, the fork is resolved.\n\nNow consider the builder’s options.\n\nPublish the payload – If the missing block becomes canonical, they published the payload, but it never made it on-chain (bad outcome). Otherwise, the full payload became canonical (good outcome).\nWithhold the payload – If the empty block becomes canonical, the unconditional payment goes through, but they aren’t rewarded by the payload being included (bad outcome). If the missing block becomes canonical, then they didn’t needlessly reveal their payload (good outcome).\n\nIn summary, either publishing or withholding the payload can result in a good or bad outcome, depending on the behavior of the slot N+1 proposer (which is uncertain even if they are honest).\nKey point 1 – By not giving fork-choice weight to the builder, we cannot protect them from the proposer splitting in an attempt to grief. However, the builder can be certain that their block will not be reorged by a block in the same slot, so they can protect their transactions by bounding them to slot N.\nKey point 2 – Today, such splitting is possible as well; it just looks slightly different. If the proposer intentionally delays their publication such that the next proposer might try to reorg their block using the honest-reorg strategy, the mev-boost builders have no certainty that their block won’t be one-block reorged. Indeed, we see many one-block reorgs presently. See Time, Slots for more context.\nBuilder-initiated splitting\nAs hinted at above, builders can try to grief the slot N+1 proposer into building on a fork with a weak PT vote by selectively revealing the payload to a subset of the PTC.\nupload_240b0eb8bf0b71269cb92e2bfaa2d7e11139×815 21.6 KB\nIn this case, the N+1 proposer is going to get orphaned by the N+1,missing block because there was such a disparity in the PT votes. Specifically, if the builder can get the proposer to build on the full or empty block which is the opposite of what the PTC votes for, then they orphan the block. Let N,empty be the block that the proposer of N+1 builds on (w.l.o.g.), and let \\beta𝛽 denote the proportion of the PTC voting for N,full. If \\beta > 0.7𝛽 >0.7, then the N+1 validator will be orphaned. In other words, the proposer needs to agree with at least 30% of the PTC to avoid being orphaned.\nSpitting conclusion\nNeither of these splitting conditions seem too critical. The proposer-initiated splitting is already possible today with mev-boost and builder-initiated splitting will be difficult to execute if the PTC is sufficiently large. Any ePBS design involves some additional degrees of freedom for network participants (by enshrining the builder role), and this design is no exception. Further analysis on the probability and feasibility of splitting will be an important part of the full evaluation of the PTC design.\n\n Relays in a post-ePBS world\n\n Three dichotomies in ePBS\n\n Realigning block building incentives and responsibilities - Block Negotiation Layer\n\n 🗳️ Commitment-Satisfaction Committees: An In-Protocol Solution to PEPC\n\n Fork Choice Attacks and Protections in EPBS\n\n 2\n\n read \n\n 12\n min\n\n post by addyxvii on Jul 6, 2023\n\n addyxvii\n\nbuilder-initiated splitting will be difficult to execute if the PTC is sufficiently large.\n\nI know that this is only a high level description, but out of ignorance/curiosity is a minimum PTC size going to be enforced in the spec to prevent builder initiated splitting? or is it not critical enough to address?\n\n post by mikeneuder on Jul 10, 2023\n\n mikeneuder\n\nWe would certainly enforce a minimum size! The tradeoff remains the extra time needed to aggregate if the PTC becomes too large\n\n post by bryce on Jul 10, 2023\n\n bryce\n\n Awesome writeup and am excited to see nice research progress on the ePBS front, thanks for this \nI was looking deeper into block-slot voting and the main reasons it was not implemented in the end. This post describes it well:\n\nThis implies that if - for whatever reason - there is latency greater than 3 seconds, even an honest but slightly late block would not make it into the canonical chain. So while technically the chain is still making progress (voting on empty slots and finalizing them), it’s practically of no use to the user because no transactions are included in the canonical chain.\n\nThe current design doesn’t address this concern if we were to go ahead and introduce block-slot voting in the fork choice rule. Understood that you mentioned pure block-slot voting may not be necessary in practice, but with the notion of missing blocks, the concern is still valid in my opinion.\n\n post by fradamt on Jul 14, 2023\n\n fradamt\n\n The way we know how to deal with those concerns is to essentially turn-off the block, slot machinery and revert back to not giving fork-choice weight to missing blocks, whenever progress is not being made for sufficiently long (then eventually try turning it back on and see how it goes, i.e., a back-off scheme)\nThe issue with doing this with ePBS is that the block, slot machinery is quite essential to it, to the point where turning it off would imho require turning off ePBS itself. This might be ok, as long as either:\n\nlocal block building capabilities still exist in all validators (this might not be the case forever, and PBS, both in its MEV-boost and ePBS form, might accelerate this possibility)\noff-chain PBS infrastructure still exists, at least as a fallback\n\n post by dankrad on Jul 21, 2023\n\n dankrad\n\n As discussed during this weeks workshop, a problem with this design is that it does not protect the builder in case the proposer intentionally or unintentionally splits the attestation committee.\nThis is an important property of PBS designs.\n\n 15 days later\n\n post by 0xkydo on Aug 5, 2023\n\n 0xkydo\n\n I think the fork choice rule here is quite fascinating. I want to spell it out and see if my understanding is correct. I will go through a hypothetical and propose some questions along the way.\nAs an LMD-GHOST attester (consensus attester) in slot n+1, I would first look at the beacon blocks at slot n. Let’s say there are two beacon blocks (bb) bb_n^1𝑏𝑏1𝑛 and bb_n^2𝑏𝑏2𝑛. bb_n^1𝑏𝑏1𝑛 has 31% weight and bb_n^2𝑏𝑏2𝑛 has 69% weight.\n\nI then look at the where did the proposer at slot n+1 build upon. Let’s say it built on top of bb_n^1𝑏𝑏1𝑛, because it has proposer boost, I will vote on the newly-proposed bb_{n+1}𝑏𝑏𝑛+1.\nNext I need to check on the PTC votes on bb_n^1𝑏𝑏1𝑛. The n+1 proposer treated the bb_{n+1}𝑏𝑏𝑛+1 block as empty and 20% of the PTC in slot n also voted for empty.\n\nQuestion: since there are two blocks at slot n, how would the PTC vote? Would I vote on both blocks or just one block. Another way of asking this is: if we sum the PTC votes, would it equal to 100% for each block proposed by the proposer or for all of the blocks? In this current flow, I am treating the PTC to only care about the payload, so it will vote on the payload for all headers.\n\nNow, in my view wrt the payload, I have 20%+40% = 60% treating bb_n^1𝑏𝑏1𝑛 as empty, and 80% (100%-20%) treating bb_n^1𝑏𝑏1𝑛 as full. How would I vote now?\n\nDo I vote for the\n\nbb_n^1𝑏𝑏1𝑛\nbb_n^1𝑏𝑏1𝑛 full block\nor the newly proposed bb_{n+1}𝑏𝑏𝑛+1\nbb_n^2𝑏𝑏2𝑛 (therefore treating bb_{n+1}𝑏𝑏𝑛+1 as an invalid block)\n\nHere is a diagram describing the attester’s view.\nimage3160×2672 245 KB\n\n Powered by Discourse","tokens":4839,"squid":"spider-04","role":"Research Spider","at":1791348612441,"hash":"ec5518ee6de38eb0ac1c790c22d4404bcbf4adc3"}
{"url":"https://chain.link/","domain":"chain.link","title":"Chainlink: The Industry-Standard Oracle Platform","text":"Copy as PNGCopy as SVGDownload all logosView brand guidelinesSmartCon is LIVE right now. Discover 200+ leading DeFi, NFT, and blockchain projects.Sign up todayWin your share of500k+ in prizes.Sign Up NowJoin the biggest names in finance and techWatch live nowChainlink Labs is hiring. Come join an industry-leading team.See current openings\n\nLINKBanksBlockchainsCapital MarketsCryptoDeFiEverythingPrediction MarketsStablecoinsStocksTokenized AssetsTreasuriesWall StreetBanksBlockchainsCapital MarketsCryptoDeFiEverythingPrediction MarketsStablecoinsStocksTokenized AssetsTreasuriesWall StreetBanksBlockchainsCapital MarketsCryptoDeFiEverythingPrediction MarketsStablecoinsStocksTokenized AssetsTreasuriesWall StreetBanksBlockchainsCapital MarketsCryptoDeFiEverythingPrediction MarketsStablecoinsStocksTokenized AssetsTreasuriesWall StreetBanksBlockchainsCapital MarketsCryptoDeFiEverythingPrediction MarketsStablecoinsStocksTokenized AssetsTreasuriesWall StreetBanksBlockchainsCapital MarketsCryptoDeFiEverythingPrediction MarketsStablecoinsStocksTokenized AssetsTreasuriesWall StreetBanksBlockchainsCapital MarketsCryptoDeFiEverythingPrediction MarketsStablecoinsStocksTokenized AssetsTreasuriesWall StreetBanksBlockchainsCapital MarketsCryptoDeFiEverythingPrediction MarketsStablecoinsStocksTokenized AssetsTreasuriesWall StreetBanksBlockchainsCapital MarketsCryptoDeFiEverythingPrediction MarketsStablecoinsStocksTokenized AssetsTreasuriesWall StreetBanksBlockchainsCapital MarketsCryptoDeFiEverythingPrediction MarketsStablecoinsStocksTokenized AssetsTreasuriesWall StreetBanksBlockchainsCapital MarketsCryptoDeFiEverythingPrediction MarketsStablecoinsStocksTokenized AssetsTreasuriesWall StreetBanksBlockchainsCapital MarketsCryptoDeFiEverythingPrediction MarketsStablecoinsStocksTokenized AssetsTreasuriesWall StreetChainlink is the industry-standard oracle platform bringing the capital markets onchain and the market leader powering the majority of decentralized finance (DeFi).Learn moreChainlink overviewAnnouncementCCIP 2.0 Launches to Unlock Institutional Capital Across BlockchainsAnnouncementEnabling Financial Institutions To Connect to Swift’s Blockchain LedgerAnnouncementIntroducing Chainlink Fulcrum: Connecting Financial Institutions to Onchain FinancingAnnouncementDTCC Processes Production Trades Powered by Chainlink and 30+ Major InstitutionsExplainerWhat Is Chainlink? A Beginner’s GuideVisionThe Chainlink Endgame: Integrating the World Into the Tokenized Asset EconomyReportThe Oracle Platform Powering Institutional TokenizationAnnouncementChainlink Co-Founder Sergey Nazarov Appointed to CFTC Innovation Advisory CommitteeAdoptionChainlink’s Work With Swift, Euroclear, and Major Banking and Capital Markets InstitutionsVideo Federal Reserve Payments Innovation Conference | Bridging TradFi & DeFi With BNY, Chainlink, & MoreRecapSibos 2025: The Future of Digital Assets in Capital MarketsThe Chainlink Platform:
unlock onchain finance at scaleChainlink is the only all-in-one oracle platform for creating advanced blockchain applications that interoperate across blockchains and existing systems while embedding critical data, compliance, and privacy capabilities.Many of the world’s largest financial services institutions and DeFi protocols have also adopted Chainlink’s standards and infrastructure, including Swift, Euroclear, Mastercard, Fidelity International, UBS, ANZ, Aave, GMX, Lido, and many others.Learn more$36,415,397,882,658transaction value enabledTVE is calculated by taking the sum of the USD value associated with each transaction utilizing a Chainlink Oracle.UpdatedOctober 6, 2026View metricsPowering the next generation of digital assets and financial servicesTokenized fundsstablecoinsPayments & SettlementsOnChain Data DeliveryLending & BorrowingDerivativesCross-Chain DvP Settlement of Tokenized Assets With Kinexys by J.P. Morgan and Ondo FinanceEnable tokenized asset workflows with institutional-grade infrastructureConnect and orchestrate tokenized assets across any blockchain networkAutomate onchain delivery of critical financial data across any environmentEnable atomic or hybrid settlement across chains and traditional systemsANZ, ADDX, & Chainlink Unveil Cross-Chain, Cross-Border Private Transactions | MAS Project GuardianUnlock compliant, transparent, and interoperable stablecoinsAccelerate adoption with trusted, compliant stablecoins ready for global financial railsExpand stablecoin reach with secure, interoperable infrastructure across global marketsEnsure regulated stablecoins uphold transparency, auditability, and monetary integrity at scaleSwift, UBS Asset Management, and Chainlink successfully complete innovative pilot to bridge tokenized assets with existing payment systemsSeamless settlement across traditional and tokenized marketsEnable atomic and hybrid settlement of tokenized assets and fiat paymentsFacilitate DvP and PvP workflows across public and private blockchainsEmpower institutions to retain existing operational standardsScaling Fund Tokenization With Chainlink, Fidelity International, UBS, and Sygnum | SmartCon 2024Enabling secure, scalable data delivery onchainPublish and commercialize data onchain using Chainlink’s secure institutional-grade infrastructureMaintain full control and flexibility with configurable access and permissioned distributionIntegrate once, distribute everywhere—no custom blockchain development requiredThe Institutional DeFi Revolution | Aave's Stani Kulechov and Chainlink's Sergey NazarovPowering secure DeFi lending with trusted dataAccurate, tamper-resistant price data for secure loan collateralizationBattle-tested data delivery to secure protocol operations and user confidenceSmart Value Recapture (SVR) to reclaim MEV and liquidation value for the protocolGMX Votes to Integrate Chainlink's New Low-Latency Oracles as Launch PartnerDelivering reliable data for onchain derivativesReliable, low-latency data feeds for high-throughput, real-time derivatives marketsSecure automation of settlements and liquidations through decentralized infrastructureEnable advanced onchain risk management with granular market dataWhy Chainlink is the global standardSolving the core challenges of onchain financeChainlink delivers critical infrastructure for data, identity, compliance, connectivity, and orchestration, enabling institutions, DeFi protocols, and onchain applications to build, operate, and scale a wide range of financial products and services.Trusted by leading financial institutions and DeFi protocolsWorking alongside global institutions like Swift, J.P. Morgan, and Mastercard and leading DeFi protocols like Aave and GMX, Chainlink provides the infrastructure to enable secure, scalable, and interoperable financial applications.Built for security, reliability, and scaleChainlink infrastructure has enabled tens of trillions in transaction value, backed by a proven track record of uptime, accuracy, and resilience across leading blockchain networks.Enabling institutions to embrace onchain financeWatch the storiesBroadridge: The Next Wave of Onchain AssetsvideoHow Fidelity Is Positioning Itself for Onchain Financevideo21X: Europe’s First Regulated Tokenized Securities PlatformvideoEuroclear’s Jorgen Ouaknine & Stephanie Lheureux on DLTvideoCircle’s Dante Disparte on Stablecoin Mass AdoptionvideoThe Institutional Digital Asset StackvideoHow DTCC Is Leveraging Blockchain for Capital Market EfficiencyVideoBX Digital on the Onchain FutureVideoIn the newsRead the latest news about ChainlinkView moreChainlink and multinational banking consortia launch Project Pangea for T+0 FX settlementJune 24, 2026SGX FX adopts ChainlinkMay 18, 2026AWS Marketplace adds Chainlink data standards, enabling devs to link traditional computing services and blockchainsApril 24, 2026The $11 billion dig: Bridgetower and Chainlink bring an Arizona copper mine onchainApril 23, 2026SIX and Chainlink Bring Data of Swiss and Spanish Equities with a Combined Market Value of €2 Trillion OnchainApril 15, 2026Coinbase pushes order book, perps and futures data onchain with Chainlink's DataLinkMarch 25, 2026Future-proof your move onchain with ChainlinkTalk to an expert","tokens":2051,"squid":"spider-08","role":"Oracle Spider","at":1791348622049,"hash":"2726b96991b10d557dd2d165494ad1b9fe8f0286"}
{"url":"https://docs.phantom.com/sui/sending-a-transaction","domain":"docs.phantom.com","title":"Send a transaction - Phantom developer documentation","text":"Sui support has been deprecated.\nOnce a dapp is connected to Phantom, it can request user permission to send transactions on their behalf. To initiate a transaction, ensure you have the necessary parameters. For details on constructing transactions, refer to Sui developer documentation.\nconst transactionParams = {\n transaction: await tx.toJSON(), // Replace with actual transaction\n address: address.toString(), // Sender address\n networkID: SupportedSuiChainIds.SuiMainnet, // or your network ID\n};\n\nTo prompt Phantom to send a transaction to the network, refer to the following code snippet:\ntry {\n const signature = await provider.signTransaction(params);\n return signature;\n} catch (error) {\n throw new Error(error instanceof Error ? error.message : 'Failed to sign transaction');\n}\nWas this page helpful?","tokens":203,"squid":"spider-10","role":"Tooling Spider","at":1791348626734,"hash":"984a9c5c3924efc514a33de31072e2fb215ecd60"}
{"url":"https://www.metaplex.com/docs/dev-tools/cli/agents/set-agent-token","domain":"metaplex.com","title":"Agent Token | Metaplex CLI","text":"What You'll DoCreate a token for a registered agent and link it to the agent identity:One-step: Create a bonding curve launch linked to the agent with --agentAsset and --agentSetTokenTwo-step: Create a token launch separately, then link it with agents set-agent-tokenSummaryAn agent token is a Genesis token permanently linked to a registered agent identity. There are two ways to create and link an agent token — a one-step flow during launch creation, or a two-step manual flow.One-step (recommended): genesis launch create --agentAsset <ASSET> --agentSetTokenTwo-step: Create a launch, then link with agents set-agent-tokenIrreversible: Each agent identity can only ever have one token, and it can only be set onceQuick StartJump to: One-Step: Launch with Agent · Two-Step: Manual Linking · Common Errors · FAQOne-Step: Launch with AgentThe simplest way to create an agent token is to pass --agentAsset when creating the launch. This auto-derives the creator fee wallet from the agent's Asset Signer PDA and optionally links the token in the same transaction.Create bonding curve with agent tokenmplx genesis launch create --launchType bonding-curve \\\n --name \"Agent Token\" \\\n --symbol \"AGT\" \\\n --image \"https://gateway.irys.xyz/abc123\" \\\n --agentAsset <AGENT_ASSET> \\\n --agentSetToken\n--agentSetToken is irreversible--agentSetToken permanently links the launched token to the agent. Omit it to launch without linking, then link later with agents set-agent-token.This also works with launchpool launches:Launchpool with agentmplx genesis launch create \\\n --name \"Agent Token\" \\\n --symbol \"AGT\" \\\n --image \"https://gateway.irys.xyz/abc123\" \\\n --agentAsset <AGENT_ASSET> \\\n --agentSetToken \\\n --tokenAllocation 500000000 \\\n --depositStartTime 2025-03-01T00:00:00Z \\\n --raiseGoal 250 \\\n --raydiumLiquidityBps 5000 \\\n --fundsRecipient <WALLET_ADDRESS>\nSee Launch (API) — Agent Launches for full details.Two-Step: Manual LinkingIf you created a token launch without --agentSetToken, you can link it afterward using agents set-agent-token. This requires asset-signer wallet mode.Step 1: Configure Asset-Signer WalletSet up agent walletmplx config wallets add my-agent --agent <AGENT_ASSET>\nmplx config wallets set my-agent\nStep 2: Link the TokenLink Genesis token to agentmplx agents set-agent-token <AGENT_ASSET> <GENESIS_ACCOUNT>\nIrreversibleEach agent identity can only ever have one token, and it can only be set once. Double-check both addresses before running this command.OutputExpected output--------------------------------\n Agent Asset: <agent_asset_address>\n Genesis Account: <genesis_account_address>\n Signature: <transaction_signature>\n Explorer: <explorer_url>\n--------------------------------\nEnd-to-End ExampleRegister agent and launch token# 1. Register a new agent\nmplx agents register --name \"My Agent\" \\\n --description \"An autonomous trading agent\" \\\n --image \"./avatar.png\"\n# Note the asset address from the output\n\n# 2. Launch a bonding curve token linked to the agent\nmplx genesis launch create --launchType bonding-curve \\\n --name \"Agent Token\" --symbol \"AGT\" \\\n --image \"https://gateway.irys.xyz/abc123\" \\\n --agentAsset <AGENT_ASSET> --agentSetToken\n\n# 3. Verify the agent has a token linked\nmplx agents fetch <AGENT_ASSET>\nCommon ErrorsErrorCauseFixAgent token already setTrying to set the token a second timeEach agent identity can only ever have one token — this is irreversibleAgent is not owned by the connected walletAPI hasn't indexed a freshly registered agentWait ~30 seconds and retry, or check agents fetch — the launch may have succeededNot in asset-signer modeRunning set-agent-token without configuring the walletSet up the asset-signer wallet first (see prerequisites)NotesThe one-step flow (--agentAsset --agentSetToken) is recommended — it handles everything in a single transactionThe two-step flow requires asset-signer mode because the set-agent-token instruction uses the Asset Signer PDA as authorityThe Genesis account must already exist before running set-agent-tokenWhen using --agentAsset, the creator fee wallet is auto-derived from the agent's Asset Signer PDAFAQCan I change the agent token after setting it? No. Each agent identity can only ever have one token, and it can only be set once. This action is irreversible.What is the difference between --agentSetToken and set-agent-token? They do the same thing. --agentSetToken links the token during launch creation in one step. set-agent-token links it separately after launch, requiring asset-signer mode.Why do I need asset-signer mode for set-agent-token? The set-agent-token instruction requires the Asset Signer PDA as authority. Asset-signer mode configures the CLI to derive and use this PDA automatically.","tokens":1179,"squid":"dotcat","role":"Tooling Spider","at":1791348629203,"hash":"d01496d35d11dc7bd9565fe56d8eb26b752a20a4"}
{"url":"https://chain.link/everything","domain":"chain.link","title":"Chainlink | Powering the $867T Tokenization Opportunity","text":"ResearchVideosArticlesPressGet the latest on digital assets\n\nLINKBanksBlockchainsCapital MarketsCryptoDeFiEverythingPrediction MarketsStablecoinsStocksTokenized AssetsTreasuriesWall StreetBanksBlockchainsCapital MarketsCryptoDeFiEverythingPrediction MarketsStablecoinsStocksTokenized AssetsTreasuriesWall StreetBanksBlockchainsCapital MarketsCryptoDeFiEverythingPrediction MarketsStablecoinsStocksTokenized AssetsTreasuriesWall StreetBanksBlockchainsCapital MarketsCryptoDeFiEverythingPrediction MarketsStablecoinsStocksTokenized AssetsTreasuriesWall StreetBanksBlockchainsCapital MarketsCryptoDeFiEverythingPrediction MarketsStablecoinsStocksTokenized AssetsTreasuriesWall StreetBanksBlockchainsCapital MarketsCryptoDeFiEverythingPrediction MarketsStablecoinsStocksTokenized AssetsTreasuriesWall StreetBanksBlockchainsCapital MarketsCryptoDeFiEverythingPrediction MarketsStablecoinsStocksTokenized AssetsTreasuriesWall StreetBanksBlockchainsCapital MarketsCryptoDeFiEverythingPrediction MarketsStablecoinsStocksTokenized AssetsTreasuriesWall StreetBanksBlockchainsCapital MarketsCryptoDeFiEverythingPrediction MarketsStablecoinsStocksTokenized AssetsTreasuriesWall StreetBanksBlockchainsCapital MarketsCryptoDeFiEverythingPrediction MarketsStablecoinsStocksTokenized AssetsTreasuriesWall StreetBanksBlockchainsCapital MarketsCryptoDeFiEverythingPrediction MarketsStablecoinsStocksTokenized AssetsTreasuriesWall StreetBanksBlockchainsCapital MarketsCryptoDeFiEverythingPrediction MarketsStablecoinsStocksTokenized AssetsTreasuriesWall StreetThe Oracle Platform Powering Institutional TokenizationOverviewReport↓Scroll downLINKEverything.OverviewThe Oracle Platform Powering Institutional TokenizationView nowReportThe Oracle Platform Powering Institutional TokenizationRead report$36,415,397,882,658transaction value enabledTVE is calculated by taking the sum of the USD value associated with each transaction utilizing a Chainlink Oracle.UpdatedOctober 6, 2026View metricsThe Chainlink ReserveThe Chainlink Reserve is designed to support the long-term growth and sustainability of the Chainlink Network by accumulating LINK tokens using offchain revenue from large enterprises that are adopting the Chainlink standard and from onchain service usage.Learn moreView live dataRead more about ChainlinkVideosAll videosChainlink in 2026: Powering the New Global Financial System | Sergey Nazarov12 minsCreating a Cryptographically-Guaranteed Financial System | Sergey Nazarov Keynote at SmartCon 202535 minsChainlink Unveils Standards for Institutional Tokenization at Sibos 2025 | Sergey Nazarov Keynote29 minsWhite House Digital Asset Summit: Sergey Nazarov's Opening Remarks to President Donald J. Trump1 minLoad moreArticlesVisit the blogThe Chainlink Endgame: Integrating the World Into the Tokenized Asset EconomyVisionChainlink’s Dominance Across Onchain Finance in 2025AnnouncementsChainlink’s Work With Swift, Euroclear, and Major Banking and Capital Markets InstitutionsAnnouncementsChainlink Explained in 100 WordsEducationLoad moreStay in the knowInstitutional Digital Assets DigestResearch and market updates on tokenized asset infrastructure and institutional adoption.Thank you for signing up. Please check your inbox to confirm your subscription.Oops! Something went wrong while submitting the form. Please try againGet started with ChainlinkTalk to an expertOverview DownloadThe Oracle Platform Powering Institutional TokenizationThank you for signing up. Please check your inbox to receive your overview.Oops! Something went wrong while submitting the form. Please try againBy providing your email address, you agree to receive communications from Chainlink Labs that are consistent with our privacy policy.Report DownloadThe Oracle Platform Powering Institutional TokenizationThank you! Your submission has been received!Download nowOops! Something went wrong while submitting the form.","tokens":975,"squid":"spider-08","role":"Oracle Spider","at":1791348631972,"hash":"b295e4eabdda4a8f04f44e65c1def9faa7f5481f"}
{"url":"https://docs.phantom.com/sui/signing-a-message","domain":"docs.phantom.com","title":"Sign a message - Phantom developer documentation","text":"Sui support has been deprecated.\nWhen a web application is connected to Phantom, it can also request that the user signs a given message. Applications are free to write their own messages which will be displayed to users from within Phantom’s signature prompt. Message signatures do not involve network fees and are a convenient way for apps to verify ownership of an address.\ntry {\n const encodedMessage = new TextEncoder().encode(message);\n const signature = await provider.signMessage(encodedMessage, address);\n return signature;\n} catch (error) {\n throw new Error(error instanceof Error ? error.message : 'Failed to sign message');\n}\nWas this page helpful?","tokens":165,"squid":"spider-10","role":"Tooling Spider","at":1791348636670,"hash":"e1f853608903374d5bd12c175723129efedad1ba"}
{"url":"https://research.arbitrum.io/t/thoughts-on-arbitrums-proposal-to-score-connections-by-pow/8121/1","domain":"research.arbitrum.io","title":"Thoughts on Arbitrum's Proposal to Score Connections by PoW - Uncategorized - Arbitrum Research","text":"Thoughts on Arbitrum’s Proposal to Score Connections by PoW \n\n Uncategorized\n\n gas-and-fees,tx-ordering,sequencer,nitro\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Feb 2023\n\n 1 / 2\n\n Feb 2023\n\n Mar 2023\n\n post by zkstonks on Feb 24, 2023\n\n zkstonks\n\n Offchain Labs is developing a proof-of-work mechanism to disincentivize massive sybil attacks by MEV searchers on the Arbitrum sequencer. In this post, I describe issues with the proposed mechanism and suggest alternative mechanisms that more efficiently achieve the goals of the proposal.\nIntroduction to PR 1504\nSkip this section if you are already familiar with the proposal.\nYesterday, February 23, Arbitrum core devs published Pull Request 1504, titled “Add a relay client connection nonce.”\nIn the Flashbots discord, PlasmaPower stated that the intention of the mechanism is “to stop incentivizing tons of connections to our feed.” Ben Burgess stated that the relay currently serves between 100,000-150,000 [1] connections at a time.\nThe proposal implements a change such that, when a new block is available, the relay will first deliver it to the 25 feed subscribers with the lowest “nonce.” [2] After an artificial 50 millisecond delay, the relay will deliver the block to all other subscribers. The idea is that, to minimize latency, searchers will no longer have an incentive to sybil attack the relay. Instead, they will spend tens of thousand of dollars, daily, on GPUs and electricity for mining low nonces. By my rough estimate, MEV searchers on Arbitrum currently profit roughly $5-20 million annually.\nContext\nCurrently, MEV searchers open thousands of concurrent subscriptions to the Arbitrum Sequencer Relay’s WebSocket feed. They may even do so from numerous IPs to evade rate limiting. The current system incentivizes searchers to do so because messages are propagated to subscribers sequentially and, importantly, in random order.\nSolution Guidelines\nWhile avoiding turning this into a formal mechanism design problem, we can surmise some general guidelines:\n\nThe mechanism should reasonably minimize the load on the sequencer.\nThe mechanism should be easy to implement, while a more sophisticated longer-term auction design is considered. See Footnote [3] below.\nImposing an artificial delay on a subset of connections (i.e. non-searchers) is acceptable.\nWe do not want to affect the FIFO nature of the sequencer, as this opens a can of worms.\n\nI also assume (and hope) that, if the alternative is spending millions of dollars annually on GPUs and electricity, all stakeholders would prefer to direct these funds to a charity or the Arbitrum ecosystem.\nFor environment and reputational reasons, I assume that we prefer to avoid PoW mechanisms, if possible.\nIssues\nThere are several critical issues with the proposed solution and obviously better alternatives.\nThe primary issue is how economically wasteful this mechanism is.\nMEV searchers on Arbitrum currently profit roughly $5-20 million annually. The current proposal would have a large portion of these funds spent on mining proof-of-work hashes.\n\nA simple auction design could instead direct these funds to a charity or the Arbitrum ecosystem.\nLess importantly, MEV searchers’ time is now spent on optimizing PoW algorithms instead of… other things? Such as increasing profits to donate even more to charity or the Arbitrum ecosystem.\n\nAs mentioned above, PR 1504 is also quite harmful to the environment. Pathos aside, it is (subjectively) not in the interest of Arbitrum’s ecosystem to associate themselves with promoting PoW.\nAlternative Mechanism Designs\nSuggestions for alternative auction designs that are more economically efficient and satisfy the previously discussed constraints, especially simplicity of implementation and FIFO ordering.\n\nPay X ETH to some address be in the priority queue for 24 hours. Very simple to implement. There’s still an incentive to open multiple connections, but it’s not cheap to do so. X can be adjusted daily. Subscriptions to the feed can optionally contain a header with an ECDSA signature from an EOA that has paid in the past 24 hours.\n\nSearchers submit blind bids before Sunday 12:00 UTC to an email address, web form, or smart contract. Top 5 bidders pay the 6th’s bid. Give the winning bidders API keys or have them authenticate via ECDSA signatures. This is extremely simple to implement. Credit to @snoopy_mev on twitter.\n\nFootnotes\n[1] Simultaneous broadcast is a well-studied problem. Every financial exchange and video game has solved this problem before.\n[2] Keccak hash of the current date + a salt phrase.\n[3] As PlasmaPower stated, PR 1504 is intended to be a temporary solution until Offchain Labs designs a more sophisticated transaction ordering solution, as discussed here.\n\n Transaction ordering policy\n\n post by edfelten on Mar 1, 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 Time boost: a new transaction ordering policy proposal\n\n Uncategorized\n\n 34\n\n 9.8k\n\n Sep 2023\n\n The power of faster blocks\n\n Uncategorized\n\n 11\n\n 4.2k\n\n Sep 2024\n\n Transaction ordering policy\n\n Uncategorized\n\n 10\n\n 8.6k\n\n Mar 2023\n\n Proposed design for Timeboost\n\n Uncategorized\n\n 12\n\n 3.3k\n\n Jun 2024\n\n FairFlow: Leveraging TimeBoost to Build a Fair and Transparent L2 MEV Economy\n\n Uncategorized\n\n tx-ordering\n\n 0\n\n 448\n\n Apr 2025","tokens":1348,"squid":"spider-01","role":"Chain Spider","at":1791348648408,"hash":"db48043567d74f4fd68cacfc9e71a5f254c522d3"}
{"url":"https://research.arbitrum.io/t/thoughts-on-arbitrums-proposal-to-score-connections-by-pow/8121/5","domain":"research.arbitrum.io","title":"Thoughts on Arbitrum's Proposal to Score Connections by PoW - Uncategorized - Arbitrum Research","text":"Uncategorized\n\n gas-and-fees,tx-ordering,sequencer,nitro\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Feb 2023\n\n 2 / 2\n\n Mar 2023\n\n Mar 2023\n\n post by zkstonks on Feb 24, 2023\n\n zkstonks\n\n Offchain Labs is developing a proof-of-work mechanism to disincentivize massive sybil attacks by MEV searchers on the Arbitrum sequencer. In this post, I describe issues with the proposed mechanism and suggest alternative mechanisms that more efficiently achieve the goals of the proposal.\nIntroduction to PR 1504\nSkip this section if you are already familiar with the proposal.\nYesterday, February 23, Arbitrum core devs published Pull Request 1504, titled “Add a relay client connection nonce.”\nIn the Flashbots discord, PlasmaPower stated that the intention of the mechanism is “to stop incentivizing tons of connections to our feed.” Ben Burgess stated that the relay currently serves between 100,000-150,000 [1] connections at a time.\nThe proposal implements a change such that, when a new block is available, the relay will first deliver it to the 25 feed subscribers with the lowest “nonce.” [2] After an artificial 50 millisecond delay, the relay will deliver the block to all other subscribers. The idea is that, to minimize latency, searchers will no longer have an incentive to sybil attack the relay. Instead, they will spend tens of thousand of dollars, daily, on GPUs and electricity for mining low nonces. By my rough estimate, MEV searchers on Arbitrum currently profit roughly $5-20 million annually.\nContext\nCurrently, MEV searchers open thousands of concurrent subscriptions to the Arbitrum Sequencer Relay’s WebSocket feed. They may even do so from numerous IPs to evade rate limiting. The current system incentivizes searchers to do so because messages are propagated to subscribers sequentially and, importantly, in random order.\nSolution Guidelines\nWhile avoiding turning this into a formal mechanism design problem, we can surmise some general guidelines:\n\nThe mechanism should reasonably minimize the load on the sequencer.\nThe mechanism should be easy to implement, while a more sophisticated longer-term auction design is considered. See Footnote [3] below.\nImposing an artificial delay on a subset of connections (i.e. non-searchers) is acceptable.\nWe do not want to affect the FIFO nature of the sequencer, as this opens a can of worms.\n\nI also assume (and hope) that, if the alternative is spending millions of dollars annually on GPUs and electricity, all stakeholders would prefer to direct these funds to a charity or the Arbitrum ecosystem.\nFor environment and reputational reasons, I assume that we prefer to avoid PoW mechanisms, if possible.\nIssues\nThere are several critical issues with the proposed solution and obviously better alternatives.\nThe primary issue is how economically wasteful this mechanism is.\nMEV searchers on Arbitrum currently profit roughly $5-20 million annually. The current proposal would have a large portion of these funds spent on mining proof-of-work hashes.\n\nA simple auction design could instead direct these funds to a charity or the Arbitrum ecosystem.\nLess importantly, MEV searchers’ time is now spent on optimizing PoW algorithms instead of… other things? Such as increasing profits to donate even more to charity or the Arbitrum ecosystem.\n\nAs mentioned above, PR 1504 is also quite harmful to the environment. Pathos aside, it is (subjectively) not in the interest of Arbitrum’s ecosystem to associate themselves with promoting PoW.\nAlternative Mechanism Designs\nSuggestions for alternative auction designs that are more economically efficient and satisfy the previously discussed constraints, especially simplicity of implementation and FIFO ordering.\n\nPay X ETH to some address be in the priority queue for 24 hours. Very simple to implement. There’s still an incentive to open multiple connections, but it’s not cheap to do so. X can be adjusted daily. Subscriptions to the feed can optionally contain a header with an ECDSA signature from an EOA that has paid in the past 24 hours.\n\nSearchers submit blind bids before Sunday 12:00 UTC to an email address, web form, or smart contract. Top 5 bidders pay the 6th’s bid. Give the winning bidders API keys or have them authenticate via ECDSA signatures. This is extremely simple to implement. Credit to @snoopy_mev on twitter.\n\nFootnotes\n[1] Simultaneous broadcast is a well-studied problem. Every financial exchange and video game has solved this problem before.\n[2] Keccak hash of the current date + a salt phrase.\n[3] As PlasmaPower stated, PR 1504 is intended to be a temporary solution until Offchain Labs designs a more sophisticated transaction ordering solution, as discussed here.\n\n Transaction ordering policy\n\n post by edfelten on Mar 1, 2023\n\n edfelten\n\n Thanks for your post. Your argument against using proof of work here makes sense.\nOur research team has been working in recent months on transaction ordering questions. Some of our thinking is in this new post.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Time boost: a new transaction ordering policy proposal\n\n Uncategorized\n\n 34\n\n 9.8k\n\n Sep 2023\n\n The power of faster blocks\n\n Uncategorized\n\n 11\n\n 4.2k\n\n Sep 2024\n\n Transaction ordering policy\n\n Uncategorized\n\n 10\n\n 8.6k\n\n Mar 2023\n\n Proposed design for Timeboost\n\n Uncategorized\n\n 12\n\n 3.3k\n\n Jun 2024\n\n FairFlow: Leveraging TimeBoost to Build a Fair and Transparent L2 MEV Economy\n\n Uncategorized\n\n tx-ordering\n\n 0\n\n 448\n\n Apr 2025","tokens":1388,"squid":"spider-01","role":"Chain Spider","at":1791348658501,"hash":"a793b3bb318c889591145ecff218086c62536809"}
{"url":"https://akash.network/docs/node-operators/node-build/cli-build/","domain":"akash.network","title":"Akash Node CLI Build | Akash Network - Your Guide to Decentralized Cloud","text":"Akash Node CLI Build Build an Akash RPC node manually on a Linux server. This guide provides full control over node configuration and is ideal for validators, providers, and production dApps.\nTime: 15-30 minutes (setup) + 20-30 minutes (sync via snapshot)\nRequirements:\n\nUbuntu 24.04 LTS\n4 CPU cores\n8 GB RAM\n100 GB SSD storage (minimum), 1 TB recommended\nRoot access\n\nOverview\nThis guide covers:\n\nInstall Akash Software\nAdd Akash to PATH\nChoose Node Moniker\nInitialize Node\nSet Minimum Gas Price\nCopy Genesis File\nConfigure P2P Peers\nConfigure Fast Sync\nDownload Blockchain Snapshot\nStart the Node\n\nStep 1 - Install Akash Software\nInstall the latest stable version of Akash Node software.\nInstall Dependencies\nTerminal windowapt updateapt install -y jq unzip curl\nDownload and Install Akash\nTerminal windowcd ~curl -sSfL https://raw.githubusercontent.com/akash-network/node/main/install.sh | sh\nThis installs the akash binary to ~/bin/akash.\n\nStep 2 - Add Akash to PATH\nAdd the Akash binary location to your system PATH.\nEdit Environment File\nTerminal windownano /etc/environment\nUpdate PATH\nAdd /root/bin to the existing PATH:\nBefore:\nPATH=\"/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin\"\nAfter:\nPATH=\"/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/root/bin\"\nSave and exit (Ctrl+X, then Y, then Enter).\nActivate Changes\nTerminal windowsource /etc/environment\nVerify Installation\nTerminal windowakash version\nExpected output:\nv1.1.0\n\nStep 3 - Choose Node Moniker\nChoose a memorable name for your node (ASCII characters only).\nTerminal windowexport AKASH_MONIKER=\"my-akash-node\"\nNote: You can change the moniker later in ~/.akash/config/config.toml.\n\nStep 4 - Initialize Node\nInitialize your Akash node with the mainnet chain ID.\nSet Network Variables\nNetwork parameters come from mainnet meta.json.\nTerminal windowexport AKASH_META_URL=\"${AKASH_META_URL:-https://raw.githubusercontent.com/akash-network/net/main/mainnet/meta.json}\"export AKASH_CHAIN_ID=\"$(curl -sSf \"$AKASH_META_URL\" | jq -r '.chain_id')\"\nInitialize Node\nTerminal windowakash genesis init --chain-id \"$AKASH_CHAIN_ID\" \"$AKASH_MONIKER\"\nThis creates the node configuration in ~/.akash/.\nExpected: JSON output with chain ID and node information.\n\nStep 5 - Set Minimum Gas Price\nSet a minimum gas price to protect your node from spam transactions.\nTerminal windownano ~/.akash/config/app.toml\nFind the minimum-gas-prices field and set it to:\nminimum-gas-prices = \"0.0025uakt\"\nSave and exit.\n\nStep 6 - Copy Genesis File\nDownload the genesis file for the Akash mainnet (URL is taken from meta.json).\nTerminal windowcurl -sSf \"$(curl -sSf \"$AKASH_META_URL\" | jq -r '.codebase.genesis.genesis_url')\" > \"$HOME/.akash/config/genesis.json\"\n\nStep 7 - Configure P2P Peers\nConfigure Tendermint seeds and persistent peers to connect your node to the network (values are read from meta.json).\nDownload and Configure Automatically\nBuild comma-separated node_id@host:port lists from meta.json (peers.seeds and peers.persistent_peers).\nTerminal window# Seed nodes (empty string if none are published)SEED_NODES=\"$(curl -sSf \"$AKASH_META_URL\" | jq -r '(.peers.seeds // []) | map(\"\\(.id)@\\(.address)\") | join(\",\")')\"\n# Persistent peersPEER_NODES=\"$(curl -sSf \"$AKASH_META_URL\" | jq -r '(.peers.persistent_peers // []) | map(\"\\(.id)@\\(.address)\") | join(\",\")')\"\n# Update config.toml with seed nodessed -i.bak \"s|^seeds = \\\"\\\"|seeds = \\\"$SEED_NODES\\\"|\" ~/.akash/config/config.toml\n# Update config.toml with peer nodessed -i.bak \"s|^persistent_peers = \\\"\\\"|persistent_peers = \\\"$PEER_NODES\\\"|\" ~/.akash/config/config.toml\n# Configure RPC to listen on all interfacessed -i.bak 's|laddr = \"tcp://127.0.0.1:26657\"|laddr = \"tcp://0.0.0.0:26657\"|' ~/.akash/config/config.toml\nWhat this does:\n\nReads current seed and persistent peer lists from meta.json\nAutomatically updates config.toml with the nodes\nConfigures RPC to accept external connections\nCreates backup files (.bak) before modifications\n\nVerify Configuration\nTerminal windowgrep \"^seeds\" ~/.akash/config/config.tomlgrep \"^persistent_peers\" ~/.akash/config/config.tomlgrep \"laddr.*26657\" ~/.akash/config/config.toml\nExpected output:\nseeds = \"27eb432ccd5e895c5c659659120d68b393dd8c60@35.247.65.183:26656,...\"persistent_peers = \"9180b99a5be3443677e0f57fc5f40e8f071bdcd8@161.35.239.0:51656,...\"laddr = \"tcp://0.0.0.0:26657\"\n\nStep 8 - Configure Fast Sync\nVerify Fast Sync is enabled (it should be by default).\nTerminal windownano ~/.akash/config/config.toml\nConfirm these settings:\n# Fast Sync enabledfast_sync = true\n# Fast Sync version (v0 recommended)[fastsync]version = \"v0\"\n\nStep 9 - Download Blockchain Snapshot\nDownload a blockchain snapshot to sync quickly. Snapshots are updated hourly.\nRemove Existing Data\nTerminal windowrm -rf ~/.akash/datamkdir -p ~/.akash/datacd ~/.akash\nDownload Latest Snapshot\nSnapshot URL: https://snapshots.akash.network/akashnet-2/latest\nSize: ~15GB compressed, updated hourly\nTerminal window# Install lz4 if not already installedapt-get install -y lz4\n# Download snapshotwget -O akashnet-2_latest.tar.lz4 https://snapshots.akash.network/akashnet-2/latest --inet4-only\n# Decompresslz4 -d akashnet-2_latest.tar.lz4\n# Extracttar -xvf akashnet-2_latest.tar\nNote: This process takes 20-30 minutes depending on your internet speed (~15 GB compressed download).\n\nStep 10 - Start the Node\nCreate a systemd service to run your Akash node.\nCreate Start Script\ncat > /usr/local/bin/start-akash-node.sh << 'EOF'#!/usr/bin/env bash/root/bin/akash startEOF\nchmod +x /usr/local/bin/start-akash-node.sh\nCreate Systemd Service\nTerminal windowcat > /etc/systemd/system/akash-node.service << 'EOF'[Unit]Description=Akash NodeAfter=network.target\n[Service]User=rootGroup=rootExecStart=/usr/local/bin/start-akash-node.shRestart=on-failureRestartSec=15LimitNOFILE=65535\n[Install]WantedBy=multi-user.targetEOF\nStart the Service\nTerminal windowsystemctl daemon-reloadsystemctl enable akash-nodesystemctl start akash-node\nCheck Node Status\nTerminal windowakash status\nExpected (while syncing):\n{ \"SyncInfo\": { \"latest_block_height\": \"15234567\", \"catching_up\": true }}\nExpected (when synced):\n{ \"SyncInfo\": { \"latest_block_height\": \"15234567\", \"catching_up\": false }}\nCompare latest_block_height with Mintscan to verify sync status.\nMonitor Logs\nTerminal windowjournalctl -u akash-node -f\nPress Ctrl+C to stop following logs.\n\nConfiguration Files\nYour Akash node configuration is stored in ~/.akash/config/:\n\napp.toml - Cosmos SDK application configuration (gas prices, API, gRPC)\nconfig.toml - Tendermint consensus configuration (P2P, RPC, mempool)\ngenesis.json - Genesis state of the blockchain\n\nOptional: Enable RPC & API Services\nRPC Service (Port 26657)\nAlready enabled if you followed Step 7. Used for transactions and queries.\nConfiguration: ~/.akash/config/config.toml\n[rpc]laddr = \"tcp://0.0.0.0:26657\"\nAPI Service (Port 1317)\nEnable the REST API for external tools (wallets, dashboards).\nEdit ~/.akash/config/app.toml:\n[api]enable = trueaddress = \"tcp://0.0.0.0:1317\"\nRestart the node:\nTerminal windowsystemctl restart akash-node\n\nState Pruning\nControl how much blockchain history your node stores.\nPruning Strategies:\n\ndefault - Keep last 100 states + every 500th state (recommended)\nnothing - Keep all history (archival node, requires >1TB storage)\neverything - Keep only current state (not for validators!)\ncustom - Manual configuration\n\nConfiguration: ~/.akash/config/app.toml\n[pruning]pruning = \"default\"\nImportant: Validators should use default or nothing. Never use everything for validator nodes.\n\nOther Networks\nThis guide uses Akash mainnet. For sandbox or other networks:\n\nAkash Network Configurations\n\nNext Steps\n\nFor Validators: See Running a Validator\nFor Providers: Use your node as an RPC endpoint in provider configuration\nFor dApps: Configure your application to use your node’s RPC/API endpoints\n\nQuestions? Join #validators on Discord \nEdit page on github\n Getting Started Helm Chart","tokens":2006,"squid":"spider-03","role":"Compute Spider","at":1791348664651,"hash":"4bacbf00e1602b0738987b8d3810c91cc801f2cc"}
{"url":"https://research.arbitrum.io/t/time-boost-a-new-transaction-ordering-policy-proposal/8173/1","domain":"research.arbitrum.io","title":"Time boost: a new transaction ordering policy proposal - Uncategorized - Arbitrum Research","text":"Time boost: a new transaction ordering policy proposal \n\n Uncategorized\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Mar 2023\n\n 1 / 35\n\n Mar 2023\n\n Sep 2023\n\n post by edfelten on Mar 1, 2023\n\n edfelten\n\n [cross-posted from Medium]\ntl; dr: We’re proposing a modified transaction ordering policy for the Arbitrum sequencer, adding a “time boost” to the current first-come, first-served policy, where a transaction could pay a priority fee to get a small advantage or “time boost” in the ordering. This shouldn’t affect most users, but can provide a better way to manage “latency racing” behavior.\nThe Arbitrum sequencer receives transactions from users and publishes an ordered sequence, which serves as input to the execution stage of Arbitrum. Currently, the sequencer follows a first-come, first-served (FCFS) sequencing policy.\nThere’s a lot to like about FCFS. It’s simple and easy to explain. It seems intuitively fair. It minimizes latency because the policy allows each transaction to be appended to the sequence immediately on arrival.\nOther rollup protocols use FCFS as well. Optimism does, and based on descriptions of other systems they seem to do so as well.\nBut FCFS has some disadvantages, mainly that it can induce “latency racing” behavior, where sophisticated actors spend money and effort in a wasteful arms race to get closer to the sequencer, so they can get their transactions in slightly ahead of their competitors.\nWe think there is a way to do better, by adopting a modified version of FCFS, which we’ll describe below.\nGoals\nWe want a transaction ordering policy to have these properties:\n\nsecret mempool: Submitted transactions are not visible to anyone other than the sequencer, until they are included in the published sequence. This prevents parties from front-running or sandwiching others’ transactions. (The sequencer is trusted not to engage in such tactics, although this trust requirement would be removed with the move to decentralized sequencing.)\nlow latency: Every transaction that arrives at the sequencer is included in the sequence within a short time limit, perhaps 0.5 seconds.\nshort-term bidding: Over short time intervals, transactions can gain an advantage in the ordering by bidding for position. This is meant to induce parties who are racing for early placement to do so by bidding, rather than spending resources (e.g., for latency reduction) to deliver their transactions to the sequencer faster.\ncompatible with decentralization: The policy can be adapted to work with a decentralized sequencer, so we don’t have to abandon the policy when the sequencer is decentralized.\n\nTime boost ordering policy\nThe new policy is a modified first-come, first-served. The mempool is still secret, to prevent front-running.\nEvery transaction is timestamped when it arrives at the sequencer. A transaction can choose to pay an extra priority fee, which will give it a time boost — making its timestamp slightly earlier, by up to 0.5 seconds.\nWhy 0.5 seconds? This parameter reflects a tradeoff. We want transaction senders to be able to buy a large enough boost that they have incentive to buy a boost rather than trying to engineer latency — which makes us want to have a larger maximum boost. But also we want to minimize the impact on the latency of non-boosted transactions, which will potentially have to wait for this period in case a boosted transaction might arrive after them — which makes us want a smaller minimum boost. We think 0.5 seconds balances the tradeoff reasonably, although others might have good arguments for a slightly smaller or larger value.\nWe expect that most transactions won’t buy a time boost, so no changes are needed in wallets or application UX. Sophisticated parties who are already constructing Arbitrum transactions programmatically can decide whether to buy a time boost (and how much to buy), based on whether they’re competing with others for early position and how much they value being first.\nIf a transaction’s priority fee is F, it will get a time boost (i.e., a subtraction from its timestamp) computed by this formula:\n\nwhere is the g maximum time boost available (planned for 0.5 seconds in production), and c is a constant to be determined. In exchange for this time boost, the L2 gas price paid by the transaction will be increased by F.\n1400×833 69.8 KB\nHere’s a graph of the formula, assuming the maximum boost g is 0.5 seconds. By design, a lower fee buys a good chunk of the available boost, with diminishing returns as the fee goes up. The boost approaches 0.5 seconds if the fee gets very large.\nImplementation\nHere’s an approach to implementing the policy. Legacy transaction types should continue to work as before, so that no changes are necessary for most users and developers. As always, Arbitrum would charge gas fees on L2 but would ignore the “priority fee” fields in legacy transaction formats. (Many existing transactions send a non-zero priority fee to Arbitrum. Arbitrum does not collect that priority fee, and that shouldn’t change.)\nTransactions that want a time boost would use a new L2 transaction type, which would be the same format as a legacy transaction (other than having a different transaction type label). For the new transaction type, the Ethereum priority fee field would be interpreted as a time boost fee, and would be collected by the Arbitrum chain.\nThe Arbitrum sequencer would apply the time boost formula, adjust timestamps accordingly, and sequence transactions in increasing order of the adjusted timestamp.\nOne consequence of the policy would be that transactions that didn’t pay for time boost would experience an extra 0.5 seconds of latency, because the sequencer would need to wait to see if any transactions coming soon after had a boost. But no transaction would ever need to be held for longer than 0.5 seconds.\n\n Thoughts on Arbitrum's Proposal to Score Connections by PoW\n\n 9\n\n 7\n\n 5\n\n 3\n\n 2\n\n read \n\n 14\n min\n\n post by bbuddha on Mar 1, 2023\n\n bbuddha\n\n Pretty interesting! A couple questions:\n\nThis policy doesn’t necessarily get rid of the incentive to colocate with the sequencer. Just so this reply doesn’t get to long, I’ll call b(f) the time boost for fee f and f(b) its the fee for boost b. For example, say Alice has achieved a 0.05s latency decrease through colocating. If Alice and Bob are competing for the same MEV opportunity worth k, to break even, Bob would have to get the opportunity (before Alice) and pay f(b(k)). To frontrun Bob (using her latency advantage and a time boost), Alice would have to pay f(b(k) - 0.049) which could be much less than what Bob needs to pay based on the concavity of the boost vs. fee curve. As long as the cost of colocation amortized among the transactions added to the fee payed for the slightly higher boost Alice gets is lower the Bob’s expected fees, the incentive to colocate is still present. Is this realistic? Does the team have any thoughts on it? Searchers likely care less about being first with respect to time and care more about being first with respect to other searchers, and it seems like a “continuously” growing ledger like Arbitrum’s doesn’t get some of the nice levers in this respect that a “discontinously” growing ledger like Ethereum does (for example running auctions between blocks at a delay beyond which colocation would matter).\nAny fun plans for what to do with the time boost fees? Seems like an interesting place to introduce redistribution to the protocol…\n\nOverall, seems like an interesting, useful addition to the protocol. Thanks for sharing.\n\n post by OliverNChalk on Mar 1, 2023\n\n OliverNChalk\n\n This doesn’t remove the latency game, just shifts a portion of the cost from hardware/engineering into tx fee bidding. Though because all bids pay in this auction, you will probably find it doesn’t maximize revenue to the sequencer as much has it could.\nHave you considered applying the latency to block dissemination rather than transaction inclusion. This would:\n\nNot burden regular users with any additional latency (sequencer could still give out confirmations to users immediately if we assume no private order flow selling).\nReduce reverts for searchers if you sell a single slot at each latency hierachy, e.g.:\n\nbidder 1: 0ms delay\nbidder 2: 50ms delay\nbidder 3: 100ms delay\nbidder 4: 150ms delay\nbidder 5: 200ms delay\nbidder 6-25: 250ms delay\n\n post by edfelten on Mar 1, 2023\n\n edfelten\n\n We have a longer paper in the works that includes an analysis of how time boost affects spending on latency. The bottom line is that it reduces but doesn’t eliminate the incentive to engineer for low latency. The details depend on what assumptions you make about things like the cost curve of latency.\nRegarding what to. do with the revenue, that would need to be discussed with the community before any mechanism like this is deployed. We wanted to have a conversation at this point, here in the research forum, about the pros and cons of this as a mechanism for transaction ordering.\n\n post by edfelten on Mar 1, 2023\n\n edfelten\n\n OliverNChalk\n\n Applying this on the dissemination side is an interesting suggestion. That would be effective in use cases involving backrunning of transactions on the same chain. It wouldn’t impact activity that responds to events in the outside world or another chain.\n\n post by 0xPandebug on Mar 1, 2023\n\n 0xPandebug\n\n What’s the rationale for this time boost formula as opposed to just running an explicit auction for the top of the block? Could still keep txs private to avoid front-running. This seems overly complicated, and as noted doesn’t fully remove latency incentives anyway.\nSeparately as you note the privacy will be lost if you try to decentralize the sequencer, so what’s the plan there? Layer on threshold encryption (personally skeptical of this), or something else?\n\n post by 123 on Mar 2, 2023\n\n 123\n\n Batching orders in blocks and auctioning positions makes sense if your mental model is one where you already have discretized time into fixed intervals. But defacto arbitrum receives a continuous order flow. And batching would introduce a discontinuity between the end of an old batch and the start of the new one. With the boost formula you can operate in a world with a moving time window. So you don’t have the situation that a low bid bidder gets in front of a high bid bidder, simply because he is lucky enough to end in the earlier batch.\n\n post by 0xPandebug on Mar 2, 2023\n\n 0xPandebug\n\n Understood that the de facto for Arbitrum is continuous time rather than discretized buckets, I’m just quite unclear as to why that is viewed as so preferable vs. something like @sxysun FBA-FCFS proposal?\nAgreed with @bbuddha as noted above as well:\n\nSearchers likely care less about being first with respect to time and care more about being first with respect to other searchers, and it seems like a “continuously” growing ledger like Arbitrum’s doesn’t get some of the nice levers in this respect that a “discontinously” growing ledger like Ethereum does (for example running auctions between blocks at a delay beyond which colocation would matter).\n\nDiscretizing time into small buckets with privacy maintained seems to still achieve the strong notion of fairness you’re after while providing the flexibility to better express preferences and minimize racing.\n\n post by fala13 on Mar 2, 2023\n\n fala13\n\n Could we have the reverting txs discarded like with Flashbots?\nOtherwise this is just a cash grab and brings no real benefit to searchers.\n\n post by 0xbmac on Mar 2, 2023\n\n 0xbmac\n\n 0xPandebug\n\n I’ll admit I’m unsure, but an idea is because:\nIt’s difficult (maybe impossible) to determine the time a competing tx was received => it’s difficult/impossible to calculate time boost fee for position x (estimations still viable) => PGAs are minimized\nwas this part of the rationale?\n\n post by kakia on Mar 2, 2023\n\n kakia\n\n 0xPandebug\n\n The proposed mechanism is actually taking care of different races interacting with each other, as it generates a global order, according to which transactions are sorted. If you look at it from this angle, it is certainly not “overly complicated”, but rather easy. One does not need to win the first place in the ordering, one just needs to defeat direct competitors.\nIt was not designed to defeat any particular auction format in mind, but rather having some set of goals mechanism needed to achieve.\n\n post by edfelten on Mar 2, 2023\n\n edfelten\n\n 0xPandebug\n\n I’m not clear on why it would be better to divide time into 0.5 second slots and sort by bids within a slot, as opposed to what we proposed. With rigid slot boundaries like that, whether you are ahead or behind some other party depends on the accident of slot boundaries, and not just on the relative arrival time and bid.\nIn terms of complexity, there’s not much difference between the two schemes. In either case you need to know when transactions arrived and what they bid, then release them in sorted order based on a simple combination of those two factors.\n\n post by 0xPandebug on Mar 2, 2023\n\n 0xPandebug\n\n Overall I think this is clearly a directionally positive proposal, but discretizing time + more explicit auctions seems to allow for better expressivity in bids and further reduce the latency advantage. As noted by @bbuddha:\n\nThis policy doesn’t necessarily get rid of the incentive to colocate with the sequencer.\n\nSearchers likely care less about being first with respect to time and care more about being first with respect to other searchers, and it seems like a “continuously” growing ledger like Arbitrum’s doesn’t get some of the nice levers in this respect that a “discontinously” growing ledger like Ethereum does (for example running auctions between blocks at a delay beyond which colocation would matter).\n\nThere’s still an explicit advantage here to faster transaction submission, encouraging centralization, co-location, latency spending etc. (albeit reduced). That would be further removed if the bid’s position were to be entirely unlinked from submission/receipt (i.e., just based on fee within the bucket). Seems helpful to have more expressive auctions as noted in @sxysun follow-up comments to the FBA-FCFS post. Conditional payments like coinbase.transfer, reverts, etc.\nRegarding your plans to make this forward compatible with decentralized sequencing:\n\nHow would you then plan to cycle sequencers if time is treated as continuous? Cycle leader after X # of transactions sequenced, with every node reporting their perceived exact score for every transaction? And the leader sequences based on the averages of all the scores submitted to them and average of times submitted? Seems a bit tougher, I’m a bit unclear on the plan here.\n\nIt seems easier for the FBA-FCFS style individual nodes reporting a partial ordering to the leader who then aggregates these into a weak ordering of unordered batches in it, then have the leader just resolve the intra-batch ordering via auctions wouldn’t it?.\n\nI’m also not tied to the 500ms fwiw, probably fine to be longer.\n\n post by edfelten on Mar 2, 2023\n\n edfelten\n\n I don’t see how having discrete slot boundaries makes latency irrelevant. Reducing latency could still cause a transaction to be in an earlier slot, if its arrival time would have been near a slot boundary. Having a continuous model doesn’t change the dependence, it just smooths it out, which seems like a better property.\n\n post by 0xPandebug on Mar 2, 2023\n\n 0xPandebug\n\n Yea the remaining latency advantage in batching isn’t 100% gone, it’s just no longer explicitly part of the bid. It’s still relevant for the implicit advantage as you note in that scenario when you get a little more time at last look. Increasing batch times further decrease the relevance of that latency edge, reduce centralization pressure etc, but can also have other effects on MEV/staler prices etc.\nWould be helpful to see the deeper analysis of the expected latency benefits here as you noted in time boost, and compare that to the expected latency advantage in different discrete time scenarios (such as with longer slots).\n\nWe have a longer paper in the works that includes an analysis of how time boost affects spending on latency. The bottom line is that it reduces but doesn’t eliminate the incentive to engineer for low latency. The details depend on what assumptions you make about things like the cost curve of latency.\n\nTime boost - Lower latency is always advantageous (lower latency = can always have lower bid on average).\n\nBatching - Lower latency is sometimes advantageous for when that small delta between “slow” and “fast” searchers reveals relevant information (and decreasingly relevant as a % as batch times increase). Less frequent occurrences, but could reveal meaningful opportunities at times.\n\nDo you have any loose estimates? My guess is benefit would be lower in the latter, but haven’t run.\nHow would you think about decentralizing the time boost proposal? Seems trickier as above.\nThe auction expressiveness is the other thing, seems easier in discrete but could also be tuned even in the time boost case somewhat. Would you consider making it more expressive with conditional payments/reverts etc. as opposed to the simple boost? At least reverts on the priorities would of course help ensure fuller bidding.\n\n post by edfelten on Mar 2, 2023\n\n edfelten\n\n The 0.5 second time limit is important because the scheme would be adding that much latency for ordinary users’ transactions, so making it longer has UX implications for most users. If anything, the general user community might want it to be shorter.\nIt’s important to remember that this design is intended for the benefit of the chain’s users generally and isn’t aiming to privilege one category, like MEV searchers, over others.\nOne design principle is that parties who use more of the sequencer’s resources should pay for that, because the resources are limited and others want to use them too. Unlike in Ethereum, which has much longer block times and doesn’t run the chain at anything close to the speed of a node’s computation, Arbitrum scales to higher throughput today, and we expect to widen the throughput gap going forward–so sequencer capacity is a resource that needs to be conserved. That’s not to say that it never makes sense to add new functionalities, just that there is much less slack available for supporting new features than on Ethereum.\n\n post by 0xPandebug on Mar 2, 2023\n\n 0xPandebug\n\nThe 0.5 second time limit is important because the scheme would be adding that much latency for ordinary users’ transactions, so making it longer has UX implications for most users. If anything, the general user community might want it to be shorter.\n\nAgreed, and just to clarify I’m not talking about something like 12s block times here. But something like 500ms → 1s I don’t think has much of a practical UX difference. If it turned out to have significantly better incentives when analyzing closely, just saying it’s something to be considered (I haven’t crunched the numbers here specifically, not a strong opinion).\n\nIt’s important to remember that this design is intended for the benefit of the chain’s users generally and isn’t aiming to privilege one category, like MEV searchers, over others.\n\nFully agreed as well, the chain isn’t made for searchers. Just noting that misaligned incentives for parties like searchers can of course indirectly end up hurting the product offered to users. The incentives of those parties should just managed and aligned in the way that maximizes the product offered to users.\n\nOne design principle is that parties who use more of the sequencer’s resources should pay for that, because the resources are limited and others want to use them too. Unlike in Ethereum, which has much longer block times and doesn’t run the chain at anything close to the speed of a node’s computation, Arbitrum scales to higher throughput today, and we expect to widen the throughput gap going forward–so sequencer capacity is a resource that needs to be conserved. That’s not to say that it never makes sense to add new functionalities, just that there is much less slack available for supporting new features than on Ethereum.\n\nAgreed again! It’s just about structuring the best way for people to pay for those resources in the most incentive aligned way that benefits the entire ecosystem. (Insert John Adler Wait, It’s All Resource Pricing).\nGlad to see you guys are being thoughtful about all of this and welcoming feedback, appreciate your thoughts!\n\n post by kakia on Mar 3, 2023\n\n kakia\n\n fala13\n\n This is a good question and shows the main economic difference between transaction ordering with blocks (sometimes called batch auctions) and continuous transaction ordering as the proposal at hand.\nIn the first, if the transaction sender does not like its position in the block, it can drop out and pay zero. This sounds reasonable. On the other hand, if the arbitrage value is x ETH, transaction bidder will bid any number below x to be the first among opportunity takers. In a (nearly) perfect market, the winning bid will be very close to the value of the opportunity, say 0.99x. In the continuous ordering, with time boost fee, strategic players buy time boost, no matter what the outcome. If it is a race to exploit an opportunity as described above, players will propose much less, say 0.4x, if they expect few players (and less if they expect more players), to compensate for the case in which they lose. In the equilibrium, they will bid so that in the expectation they are not worse off staying out of competition (payoff 0). Arbitrage opportunity taking is usually not a single shot game, theorefore, average analysis makes sense.\nThe rationale of the time boost fee mechanism is that it moves expenditure spent on improving latency to time boost fees. In the latency race, if a player spends resources on a low latency and still loses to competitors (maybe because they spent more), this is also a waste.\nFor more details, there is a paper that analyzes all concerns in this thread (and more). It will be available online soon.\n\n post by Pmcgoohan on Mar 4, 2023\n\n Pmcgoohan\n\n My initial reaction… I love this proposal!\nI can imagine 95% of arbers profits going on priority fees.\nAnything over 50% mitigates spam and sybil attacks completely because even a consistently winning arber cannot afford to send more than 1 tx per opportunity.\nIntuitively, it won’t get rid of all hardware/networking spend, and it doesn’t need to, it just needs to cap excessive spend, which I think it will (depending on the parameters chosen).\nLatency spend is a greatly diminishing return, and when you are engaged in a priority fee battle the amount it is worth putting into these wasteful activities will be severely capped.\nThe biggest issue I see with it is that the additional 0.5sec latency will come at a cost to users, because it will create arbitrage opportunities that would not otherwise exist against CEXs.\nAs a result, this must be kept to a minium. 500ms seems like a reasonable starting point, but it may need to go lower.\nIt does help that ordinary traders can also use priority fees (unlike with co-location advantages), so I don’t want to overplay this.\nAlso, I read some research somewhere that manual traders react with a latency of around 2 secs, so again, 0.5 secs is not such a problem for most users.\nIn terms of what to do with the income from priority fees, please consider using them to subsidize base user fees as directly as possible.\nThis will:\n\ncompensate users for the value they will lose to the additional latency\nmay reduce regulatory risk if fees are kept in the user pool in this way (I’m no lawyer- not legal advice!)\nwill also make Arbitrum more competitive in it’s pricing, which is good for the network\n\nAnyway- great work. Can’t wait to hear more.\n\n post by 123 on Mar 4, 2023\n\n 123\n\nthat you @Pmcgoohan ? I like the discussion of batch auctions \n\n Load more posts below","tokens":6011,"squid":"spider-01","role":"Chain Spider","at":1791348680537,"hash":"0690e6061a3458ec8a0d005b022e12e3e2592f14"}
{"url":"https://research.arbitrum.io/t/time-boost-a-new-transaction-ordering-policy-proposal/8173/39","domain":"research.arbitrum.io","title":"Time boost: a new transaction ordering policy proposal - Uncategorized - Arbitrum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 9\n\n 7\n\n 5\n\n 3\n\n 2\n\n read \n\n 14\n min\n\n Mar 2023\n\n 35 / 35\n\n Sep 2023\n\n Sep 2023\n\n Load more posts above\n\n post by edfelten on Mar 2, 2023\n\n edfelten\n\n 0xPandebug\n\n The 0.5 second time limit is important because the scheme would be adding that much latency for ordinary users’ transactions, so making it longer has UX implications for most users. If anything, the general user community might want it to be shorter.\nIt’s important to remember that this design is intended for the benefit of the chain’s users generally and isn’t aiming to privilege one category, like MEV searchers, over others.\nOne design principle is that parties who use more of the sequencer’s resources should pay for that, because the resources are limited and others want to use them too. Unlike in Ethereum, which has much longer block times and doesn’t run the chain at anything close to the speed of a node’s computation, Arbitrum scales to higher throughput today, and we expect to widen the throughput gap going forward–so sequencer capacity is a resource that needs to be conserved. That’s not to say that it never makes sense to add new functionalities, just that there is much less slack available for supporting new features than on Ethereum.\n\n post by 0xPandebug on Mar 2, 2023\n\n 0xPandebug\n\nThe 0.5 second time limit is important because the scheme would be adding that much latency for ordinary users’ transactions, so making it longer has UX implications for most users. If anything, the general user community might want it to be shorter.\n\nAgreed, and just to clarify I’m not talking about something like 12s block times here. But something like 500ms → 1s I don’t think has much of a practical UX difference. If it turned out to have significantly better incentives when analyzing closely, just saying it’s something to be considered (I haven’t crunched the numbers here specifically, not a strong opinion).\n\nIt’s important to remember that this design is intended for the benefit of the chain’s users generally and isn’t aiming to privilege one category, like MEV searchers, over others.\n\nFully agreed as well, the chain isn’t made for searchers. Just noting that misaligned incentives for parties like searchers can of course indirectly end up hurting the product offered to users. The incentives of those parties should just managed and aligned in the way that maximizes the product offered to users.\n\nOne design principle is that parties who use more of the sequencer’s resources should pay for that, because the resources are limited and others want to use them too. Unlike in Ethereum, which has much longer block times and doesn’t run the chain at anything close to the speed of a node’s computation, Arbitrum scales to higher throughput today, and we expect to widen the throughput gap going forward–so sequencer capacity is a resource that needs to be conserved. That’s not to say that it never makes sense to add new functionalities, just that there is much less slack available for supporting new features than on Ethereum.\n\nAgreed again! It’s just about structuring the best way for people to pay for those resources in the most incentive aligned way that benefits the entire ecosystem. (Insert John Adler Wait, It’s All Resource Pricing).\nGlad to see you guys are being thoughtful about all of this and welcoming feedback, appreciate your thoughts!\n\n post by kakia on Mar 3, 2023\n\n kakia\n\n fala13\n\n This is a good question and shows the main economic difference between transaction ordering with blocks (sometimes called batch auctions) and continuous transaction ordering as the proposal at hand.\nIn the first, if the transaction sender does not like its position in the block, it can drop out and pay zero. This sounds reasonable. On the other hand, if the arbitrage value is x ETH, transaction bidder will bid any number below x to be the first among opportunity takers. In a (nearly) perfect market, the winning bid will be very close to the value of the opportunity, say 0.99x. In the continuous ordering, with time boost fee, strategic players buy time boost, no matter what the outcome. If it is a race to exploit an opportunity as described above, players will propose much less, say 0.4x, if they expect few players (and less if they expect more players), to compensate for the case in which they lose. In the equilibrium, they will bid so that in the expectation they are not worse off staying out of competition (payoff 0). Arbitrage opportunity taking is usually not a single shot game, theorefore, average analysis makes sense.\nThe rationale of the time boost fee mechanism is that it moves expenditure spent on improving latency to time boost fees. In the latency race, if a player spends resources on a low latency and still loses to competitors (maybe because they spent more), this is also a waste.\nFor more details, there is a paper that analyzes all concerns in this thread (and more). It will be available online soon.\n\n post by Pmcgoohan on Mar 4, 2023\n\n Pmcgoohan\n\n My initial reaction… I love this proposal!\nI can imagine 95% of arbers profits going on priority fees.\nAnything over 50% mitigates spam and sybil attacks completely because even a consistently winning arber cannot afford to send more than 1 tx per opportunity.\nIntuitively, it won’t get rid of all hardware/networking spend, and it doesn’t need to, it just needs to cap excessive spend, which I think it will (depending on the parameters chosen).\nLatency spend is a greatly diminishing return, and when you are engaged in a priority fee battle the amount it is worth putting into these wasteful activities will be severely capped.\nThe biggest issue I see with it is that the additional 0.5sec latency will come at a cost to users, because it will create arbitrage opportunities that would not otherwise exist against CEXs.\nAs a result, this must be kept to a minium. 500ms seems like a reasonable starting point, but it may need to go lower.\nIt does help that ordinary traders can also use priority fees (unlike with co-location advantages), so I don’t want to overplay this.\nAlso, I read some research somewhere that manual traders react with a latency of around 2 secs, so again, 0.5 secs is not such a problem for most users.\nIn terms of what to do with the income from priority fees, please consider using them to subsidize base user fees as directly as possible.\nThis will:\n\ncompensate users for the value they will lose to the additional latency\nmay reduce regulatory risk if fees are kept in the user pool in this way (I’m no lawyer- not legal advice!)\nwill also make Arbitrum more competitive in it’s pricing, which is good for the network\n\nAnyway- great work. Can’t wait to hear more.\n\n post by 123 on Mar 4, 2023\n\n 123\n\nthat you @Pmcgoohan ? I like the discussion of batch auctions \n\n post by Pmcgoohan on Mar 4, 2023\n\n Pmcgoohan\n\n Ha! Yeah that’s me. Thanks! Vitalik actually wrote some Viper code to do a batch auction after that post. Was surprised (and not too delighted) when Uniswap then went the other way.\n\n post by ZackMorris on Mar 6, 2023\n\n ZackMorris\n\n This proposal is an improvement on the previous Proof of Work relay scheme, but I think still misses some of the objectives.\nAs I see it, an MEV mitigation scheme has 3 main objectives:\n\nMove some of the money that searchers are earning, or currently wasting on latency reduction, to the Arbitrum ecosystem.\nEliminate the need for latency races by the searchers, to remove the need for spamming transactions or creating 1000s of connections to the sequencer feed\nAchieve the above while damaging the regular customer experience as little as possible\n\nI think this proposal will do a reasonable job of objective 1, although there could be other strategies that will lead to a higher proportion of MEV being paid to the ecosystem\nI don’t think this proposal will eliminate the searcher speed races. In the limit of large fees, the time savings a searcher is purchasing (compared to no added latency) will be proportional to gc/F. So when trying to save the last fractions of a millisecond, that will prove very expensive, and hence still worth searchers making many sequencer connections.\nOn objective 3, one of the main selling points of the Arbitrum ecosystem is its low transaction latency. Even for the regular customer, most transactions will return a response in < 300ms. So to suddenly add an extra 500ms to everyone’s transactions seems like destroying the elegant and efficient system you currently have. Plus messing with the simplicity of FCFS will likely introduce a whole load of new exploits for searchers (blind spamming for sandwich attacks perhaps).\nIf you want to charge searchers for preferential access, I suggest imposing the delay on the outbound sequencer feed side. That seems much less manipulatable, more controllable, and less impactful on the regular user. For instance, a daily lottery or auction for non-delayed sequencer feed connections. This would be similar to the previous proof of work suggestion, but without the PoW. I’d be happy to work with the team designing a lottery smart contract for ordering of sequencer connections.\n\n post by 0xPandebug on Mar 6, 2023\n\n 0xPandebug\n\n edfelten\n\n Regarding the time delay, it also seems that FBA-FCFS could actually have a better UX on average than Time Boost for a given batch time = delay default based on my understanding here?\n\nTime Boost - All user txs delayed by 500ms speed bump by default upon receipt.\n\nFBA-FCFS - Batch time is 500ms, so user txs received during the window can be included within it, on average <500ms closer to the midpoint.\n\nThere would be more variability in the latter (could slip to next batch depending on receipt time), but inclusion time for txs not paying priority fees should on average be lower (<500ms upon receipt).\n\n post by kakia on Mar 7, 2023\n\n kakia\n\n Any block-to-block approach (e.g. proposed batch auction) would create situations where one transaction arrives at the end of the block with low bid, and another, much higher bid transaction arrives right after this block. Then, low bid transaction is always scheduled in front of the high bid transaction. We describe when such situation might arrise and why low latency is more important in block-to-block approach than in time boost setting. For simplicity, assume there are only two parties. Generalization to more parties is trivial. Suppose the first party (denoted by A) can reach sequencer in 0.05 seconds, and the second party (denoted by B) can reach in 0.1 seconds. Then, A can wait until 0.5-0.05=0.45 seconds pass since the beginning of a new block creation, and send its transaction to at exactly 0.45, while B has to send its transaction to be included in this block until 0.4 seconds pass. That is, in (0.1-0.05)/0.5 = 10% of the cases (in time interval 0.4-0.45) B has no chance to win a single race over A, even if it values arbitrage much more than A (and would be willing to bid much higher than A). In Ethereum environment this is not a big problem, as A would only have advantage in 0.05/12 or approximately 0.4% of the cases (see Latency arms race concerns in blockspace markets - Economics - Ethereum Research (ethresear.ch) for a related discussion). That is, latency is 12/0.5 = 24 times more important in this case. It is easy to see that our proposal of time boost fee does not suffer from this.\nThere is another clear advantage of waiting until the last feasible point in the block-to-block approach, as a party with latency advantage simulates more strategies and finds better arbitrages. It is interesting how to quantify such advantage.\n\n post by 0xPandebug on Mar 7, 2023\n\n 0xPandebug\n\n Yes aware, I mentioned this in several comments above. That last look advantage is a well understood property of this kind of discrete time auction, can see the Budish paper as well. The reality though is that delta is nowhere near the 20x you mention here. The relevant difference here for capturing an opportunity is the difference between:\n\n“fast searcher” vs. “slow searcher” (negligible difference)\n\nNot relevant:\n\n“fast searcher” vs. “regular user” (large difference, as you note)\n\nRegular user txs aren’t competing in a race for a specific arb or anything against searchers. They just want to keep their txs private and be included relatively quickly.\n\nScreen Shot 2023-03-07 at 12.16.18 PM1958×1103 110 KB\n\nThis marginal benefit left seems smaller than the benefit of latency in the Time Boost scenario, where the latency advantage is always present (you can always bid less). This is particularly relevant in the case of high value opportunities where the Time Boost is worth a lot as you go further down the curve.\n\n Proposed design for Timeboost\n\n post by 0xPandebug2 on Mar 7, 2023\n\n 0xPandebug2\n\n kakia\n\n (I’m being limited as a new account in number of comments/media allowed so posting separately)\nOverall this is clearly an improvement vs. today, but just seems less favorable on the tradeoff spectrum vs. fast batching and harder to decentralize as mentioned above as well.\n\nScreen Shot 2023-03-07 at 12.43.18 PM1545×282 119 KB\n\n post by kakia on Mar 7, 2023\n\n kakia\n\n Thank you for your engagement. I changed your previous account’s trust level, so you should be able to post more now.\nRegarding expressiveness: we can not allow reverting at this level. That would require adding validators and block proposals, basically copying Ethereum infrastructure. We want to keep transaction ordering on a protocol level. Therefore, FBA-FCFS (or any other mechanism) you’re proposing would also be all-pay-auction. Regardless of this (implementation) point, I think all-pay-auctions on average do not cause extra waste, compared to only winner pays auction, but we need to check it formally. I wrote about it informally above.\nRegarding second row: we chose 500ms for this reason, for it to be low enough, not to make UX much worse, which I think it gives yellow status. If we could increase delay g even further, then 1st row for Time Boost would become greener. So there is a tradeoff here. We have actually studied this tradeoff formally, in the equilibrium, concluding that increasing g (to infinity) decreases investment in latency advantage (to zero), and for a fixed latency cost function, we can exactly pin down the speed of convergence of latency investment.\n\n post by 123 on Mar 8, 2023\n\n 123\n\nThis is just revenue equivalence. If you assume risk neutrality (at least approximately), then bidders just shade their bid more in the all pay auction, and on average they have the same likelikood of winning and they have the same expected payment. This is of course when we analyze decision at the point of bidding. Ex-post people might dislike an outcome where they pay if they don’t win.\n\n post by edfelten on Mar 8, 2023\n\n edfelten\n\n One thing to note here is that this is a priority fee, and is collected exactly as the Ethereum priority fee, which means it is a fee per-gas, and charged on each transaction. So the “bid” is for a transaction, not for a block nor a bundle of transactions.\nOf course, a submitter can always bundle multiple logically separate transactions together, but there isn’t much advantage to doing this because the fee is charged per gas, so bundling only saves a little by amortizing the 21,000 intrinsic per-transaction gas that Ethereum (and Arbitrum) charges.\nIf there are multiple “races” happening simultaneously, with some profit opportunity for the first included transaction in each race, it makes sense for a submitter to bid separately in each race, and the time boost mechanism has the nice property that the bidding in one race doesn’t affect who wins some other race. (That would not be the case for a single winner-take-all auction.)\n\n 3 months later\n\n post by flynitro on May 24, 2023\n\n flynitro\n\nFrom what I can tell, this is the only rationale given for why this new ordering policy should be adopted. To break down the argument, the underlying problem is that Arbitrum has a centralized sequencer run by Offchain Labs. Recently, Offchain Labs reportedly ran into issues with the sequencer because searchers were establishing too many connections to the sequencer, posing a DoS threat (Add a relay client connection nonce by PlasmaPower · Pull Request #1504 · OffchainLabs/nitro · GitHub). So the problem that this proposal is supposedly trying to solve is to prevent the centralized sequencer from Offchain Labs being DoSed.\nThis is a symptom of the larger problem, namely that the sequencer is centralized. If you run a centralized system, of course you run the risk of a complete failure because it literally has a single point of failure. Even if time boost were adopted, the sequencer could still get attacked by any regular DDoS attack, it could go down due to misconfiguration, network outage in the datacenter, Offchain Labs can censor transactions (temporarily), reorder transactions to their liking, perform MEV and censor other searchers, …\nTo me, the obvious way to go is to decentralize the sequencer. With a sufficiently sized network, there would no longer be a single point of failure. There would not be a single point that all searchers are rallying to, and they would not be able to harm the sequencer. And of course, the sequencer should be decentralized regardless, to remove trust from Offchain Labs and really make Arbitrum decentralized.\nI also have not seen any mention of where the priority fee would go. Would Offchain Labs pocket the fees? This would obviously be a huge opportunity for them, but in that case they should be fully transparent about it. Searchers will always spend money to try and gain more profits, whether it is invested in optimizing latency or on priority fees. The arms race between searchers can not be stopped. But why does Offchain Labs even care about this arms race? I honestly don’t know, but priority fees would be an easy way for the money spent by searchers to flow directly to Offchain Labs.\nIt is also to be questioned whether the priority fee would really eliminate the latency race. At some point, gaining an extra X time will cost more if gained via priority fee than by spending that money into optimizing latency.\nI don’t want to sound too harsh, but it surprises me that a lot of my arguments have not been voiced by others before. To me, this proposal completely misses the point, or Offchain Labs is not being honest about what the point of this proposal is. If implemented, the sequencer would still be as vulnerable as before, searchers would still invest a lot of resources on being able to make profits, including optimizing latency, but Offchain Labs could suddenly start pocketing a large portion of the resources spent by searchers. This seems like a step backwards in terms of decentralizing Arbitrum.\n\n post by edfelten on May 26, 2023\n\n edfelten\n\n Sequencer decentralization is an important topic for the community to discuss. But I think it’s a separate issue from what the transaction ordering policy should be, which is the topic of this thread.\n(For now, the centralized sequencer is deployed with redundancy and a fail-over capability, so something like the failure of a data center shouldn’t stop the sequencer.)\nThe Arbitrum One and Nova chains are governed by the Arbitrum DAO, and the DAO will decide where any fee revenue generated by those chains will go. So if the DAO decides to adopt some policy on its chains that generates revenue from those chains, the DAO can decide where that revenue goes.\n\n post by flynitro on May 26, 2023\n\n flynitro\n\n It seems though that Arbitrum was happy with its FCFS ordering policy until the lack of rate limiting on the sequencer triggered this nightmare proposal. The timing of the time boost proposal is interestingly correlated with the backlash that the PoW proposal received. I think it is a similarly bad proposal.\nImplementing time boost turns MEV from an engineering problem into a money problem. Have the money to pay for time boost? Welcome to the club. The rich get richer, the poor get poorer:\nWith FCFS, MEV is mostly an engineering problem which has an inherent fairness to it. Have the time and skills to make the fastest algorithm and you can make profits. No matter how many ETH you own. Time boost, on the other hand, puts up a huge barrier to entry. While still requiring the same amount of engineering and time to develop any kind of MEV application, it additionally requires a lot of money to be spent on time boost, especially for initial experimentation, testing, debugging, etc, before ever even making any profitable MEV trades. Those that can take the risk of losing money, i.e. the rich, will take it and make the investment. Those that don’t, i.e. everyone else, won’t and will be cut out of the picture.\n\n 11 days later\n\n post by kakia on Jun 6, 2023\n\n kakia\n\n A paper analyzing economic aspects of time boost: https://arxiv.org/pdf/2306.02179.pdf. Some of the earlier concerns (e.g., given by @bbuddha) in this thread are also addressed. In short, time boost does not remove all investment from the latency competition, but rather moves most of it to bidding, when initialized with correct parameters. We also discuss some implementation details of the decentralized sequencer committee.\n\n 3 months later\n\n post by Christoph on Aug 29, 2023\n\n Christoph\n\n (Cross-post from the Flashbots forum)\nI have written a longer analysis about the relative performance of time boost and a batch auction design: Batching, Bidding and Latency Feedback and comments are very welcome.\n\n 28 days later\n\n post by edfelten on Sep 27, 2023\n\n edfelten\n\n A specific proposal for implementing Timeboost on Arbitrum chains is 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 Proposed design for Timeboost\n\n Uncategorized\n\n 12\n\n 3.3k\n\n Jun 2024\n\n Transaction ordering policy\n\n Uncategorized\n\n 10\n\n 8.6k\n\n Mar 2023\n\n FairFlow: Leveraging TimeBoost to Build a Fair and Transparent L2 MEV Economy\n\n Uncategorized\n\n tx-ordering\n\n 0\n\n 448\n\n Apr 2025\n\n Decentralized Timeboost Specification\n\n Uncategorized\n\n tx-ordering,sequencer\n\n 2\n\n 881\n\n Sep 2024\n\n The power of faster blocks\n\n Uncategorized\n\n 11\n\n 4.2k\n\n Sep 2024","tokens":5573,"squid":"spider-01","role":"Chain Spider","at":1791348690686,"hash":"451d078ef9af2246bbc253cdd7a12b7094518f3d"}
{"url":"https://research.arbitrum.io/t/decentralized-timeboost-specification/9676/3","domain":"research.arbitrum.io","title":"Decentralized Timeboost Specification - Uncategorized - Arbitrum Research","text":"Uncategorized\n\n tx-ordering,sequencer\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Sep 2024\n\n 3 / 3\n\n Sep 2024\n\n Sep 2024\n\n post by jill-espresso on Sep 18, 2024\n\n jill-espresso\n\n Decentralized Timeboost Specification - Feedback Welcome\nWe’re excited to share that Espresso Systems and Offchain Labs have jointly published the full specifications for Decentralized Timeboost.\nThe design builds off of Offchain Labs’ original Timeboost proposal with the goal of making it compatible with decentralized sequencers. There is currently a proposal before the Arbitrum DAO for the adoption of this original Timeboost proposal on Arbitrum One and Nova.\nDecentralized Timeboost can be thought of as a follow-on and expansion of this prior work. Espresso Systems plans to develop and test Decentralized Timeboost and ultimately bring a proposal to the Arbitrum DAO for adoption.\nQuick Timeboost Refresher\nIf you’re not familiar with Timeboost, it offers a new take on transaction ordering by introducing a fair-auction mechanism designed to enable good forms of MEV (i.e., arbitrage) while mitigating predatory MEV tactics like front-running and sandwich attacks.\nTimeboost enables auctions for the rights to an express lane, through which users can bid for a time advantage (i.e., a time boost ) for their transactions and potentially capture arbitrage and backrunning opportunities. In existing FCFS systems, arbitrageurs and predatory MEV extractors compete to get their transactions submitted first with souped-up hardware and by trying to locate servers as geographically close to the sequencer as possible, creating an unlevel playing field where sophisticated actors have the upper hand. Timeboost levels that playing field by introducing a permissionless auction for the express lane in which anyone can bid and win.\nDecentralized Timeboost\nDecentralized Timeboost builds on the original design through the introduction of a sequencer committee, as well as optional use of an encrypted mempool.\nThe sequencer committee is composed of multiple nodes and is responsible for ordering a block’s transactions, including those with a time boost submitted by the auction winner. The committee can tolerate up to one-third Byzantine or malicious nodes.\nUsers of a chain using Decentralized Timeboost also have the option to encrypt their transactions before they’re sent to the committee. This protects them from front-running, sandwich attacks, and censorship as the committee doesn’t decrypt the transactions until after they’re ordered.\nWhile not yet part of the specification, Espresso Systems is also exploring how existing auction designs, like that of the Espresso Marketplace, might be leveraged for selection of the “priority controller” in the Decentralized Timeboost implementation.\nCall for Feedback\nWe’d love to hear your thoughts and feedback on the design for Decentralized Timeboost. Please review the spec and share your input on how we can improve Decentralized Timeboost and make it a robust option for rollup ecosystems with decentralized sequencers.\nLooking Ahead\nNow that we’ve published the spec for Decentralized Timeboost, we’re looking ahead to what’s next. Our plan includes:\n\nRefining the design: We’ll continue to tweak the design as needed to ensure the protocol meets the needs of different rollup architectures. We’d love feedback from the Arbitrum community to inform this process!\nFurther testing: Espresso Systems will lead ongoing development of Decentralized Timeboost with continued collaboration from Offchain Labs.\nImplementation: We will implement and deploy Decentralized Timeboost as a transaction-ordering option for rollups that integrate with Espresso (mainnet coming soon!)\nAdoption: We hope to see organic adoption of Decentralized Timeboost among Orbit chains and rollups building on other stacks and in other ecosystems. Our goal is to ultimately make a proposal to the Arbitrum DAO that Decentralized Timeboost be adopted for Orbit chains opting to decentralize their sequencer.\n\nTimeboost Update 9241920×1080 130 KB\nFinal Thoughts\nOur collaboration with Offchain Labs and the release of Decentralized Timeboost marks a significant milestone in our ongoing mission to empower rollups with new and innovative infrastructure options, especially those that enable decentralization and cross-chain composability without the need for rollups to sacrifice scalability or their sovereignty.\nWe look forward to engaging with the Arbitrum community on Decentralized Timeboost!\n\n post by sam.ng on Sep 25, 2024\n\n sam.ng\n\n Is it correct to say that there is no separation between the block builder and the block proposer in decentralized timeboost for Arbitrum? Or can we imagine the entities in the Espresso marketplace acting as block builders and the sequencer committee of Arbitrum acting as block proposers?\nRegarding decryption, is it fair to say that the decryption key is essentially attached to the sequencer’s consensus vote (so decryption happens simultaneously)? I assume there is always added latency due to bandwidth, sending more data around and doing calculations etc…\nAs for the block building engine, if we think about the Arbitrum sequencer as both the front end and back end, are you suggesting that the back end remains the same, whether it’s a centralized Timeboost or decentralized Timeboost, since the state transition functions are deterministic? In a sense, only the front end changes because now there is a consensus that needs to be reached between operators.\nLooking forward to seeing how the UX will turn out, as Arbitrum’s preconf is such a key feature/differentiator. If it can remain close to how it is today, that’s great. If not, I’m curious to see whether the DAO will prefer keeping a centralized Timeboost with trust assumptions or if more latency in a decentralized setup will be preferred. Great stuff anyway!\n\n post by edfelten on Sep 25, 2024\n\n edfelten\n\n Several good questions there!\nYou’re correct that in the specification there is no distinction between block proposer and block builder. The protocol causes all honest parties to build the same sequence of blocks, so there is no need for a separate block proposer role.\nRegarding decryption, the specification does not try to piggyback the decryption shares onto the final messages of the decryption protocol. The most obvious way of doing that kind of piggybacking has the drawback that if some honest members vote for some inclusion list, but that inclusion list doesn’t get enough votes to reach consensus, then some decryption shares have been leaked to adversaries. To prevent this, the current spec has honest members publish their decryption shares only after they know that the inclusion list has reached consensus.\nThere is ongoing research suggesting that it may be possible to make the decryption shares “single-use” in the sense that shares generated in one protocol round aren’t useful for decryption in later protocol rounds. That would enable the kind of piggybacking you suggest to be done safely.\nI tend to think of sequencing and execution as separate parts of the broader Arbitrum protocol, where sequencing only decided on an ordered set of transactions that are deemed to have arrived at the chain, and execution determines the result of executing those transactions in order. The new spec only applies to the sequencing part of the protocol.\nYou’re right to identify latency as one of the key metrics for the implementation of this protocol.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Proposed design for Timeboost\n\n Uncategorized\n\n 12\n\n 3.3k\n\n Jun 2024\n\n Decentralized Timeboost R&D Update\n\n Uncategorized\n\n tx-ordering,sequencer\n\n 1\n\n 2.2k\n\n Apr 2024\n\n Time boost: a new transaction ordering policy proposal\n\n Uncategorized\n\n 34\n\n 9.8k\n\n Sep 2023\n\n The power of faster blocks\n\n Uncategorized\n\n 11\n\n 4.2k\n\n Sep 2024\n\n MEV Capture Through Time-Advantaged Arbitrage\n\n Uncategorized\n\n 0\n\n 811\n\n Oct 2024","tokens":2010,"squid":"spider-01","role":"Chain Spider","at":1791348700801,"hash":"a73c9b93720fd7a90e37793ed7baab353e76c16e"}
{"url":"https://forum.across.to/t/acrossalert-proposal-amplifying-acrosss-excellence-on-twitter/1902/7","domain":"forum.across.to","title":"AcrossAlert Proposal: Amplifying Across's Excellence on Twitter - Proposals - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n Proposals\n\n treasury-funding\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Apr 2024\n\n 7 / 7\n\n May 2024\n\n May 2024\n\n post by zeck on Apr 28, 2024\n\n post by Infinity on Apr 28, 2024\n\n post by PVMihalache on Apr 29, 2024\n\n PVMihalache\n\n I thought this was a good idea and supported this since day one! Lets ensure the Alert Bot will do this amazing job perpetually and constantly highlight how good Across is \n\n Cryptohadari NFT Proposal\n\n post by neondaemon on Apr 30, 2024\n\n neondaemon\n\n I think this is a very worthwhile project that adds value to the protocol, especially as it can be used on social platforms to get more eyes on Across .\n\n post by ayoki on May 1, 2024\n\n ayoki\n\n I think this is a great proposal! Can’t wait to see Across Alerts fleshed out to include more bridge comparisons, etc. Very exciting\n\n post by bennidaytime on May 1, 2024\n\n bennidaytime\n\n Fully support this. Appreciate it the structure of this proposal and transparent budgeting. The alerts page adds so much value to the Across ecosystem.\n\n 1 month later\n\n Closed on May 31, 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 Cryptohadari NFT Proposal\n\n Active Proposals\n\n Active Proposals\n\n May 2024\n\n Across AI Assistant Proposal\n\n Ideas & Feedback\n\n Ideas & Feedback\n\n 11\n\n Dec 2024\n\n # Across Community Essentials Committee Renewal Proposal for Q2-Q3 2025\n\n Committees\n\n Committees\n\n 4\n\n Mar 2025\n\n Across AI Assistant\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 3\n\n Mar 2024\n\n Across Token Launch Proposal\n\n Tokenomics (old)\n\n Tokenomics (old)\n\n 214\n\n May 2022","tokens":1918,"squid":"spider-09","role":"Bridge Spider","at":1791348702365,"hash":"57ccfd20b8fa205d1e86c45df1a0ddf9ec7505e6"}
{"url":"https://akash.network/docs/node-operators/validators/","domain":"akash.network","title":"Validators | Akash Network - Your Guide to Decentralized Cloud","text":"Validators Become part of Akash’s consensus layer by running a validator node.\nValidators are responsible for committing new blocks to the blockchain through voting. They participate in the consensus protocol by broadcasting votes that contain cryptographic signatures signed by each validator’s private key.\n\nWhat is an Akash Validator?\nValidators:\n\nPropose and vote on blocks in the Akash blockchain\nSecure the network through Proof-of-Stake consensus\nEarn rewards from block provisions and transaction fees\nCan be slashed for downtime or double-signing\n\nValidators must maintain high uptime and security to avoid penalties and earn rewards for their delegators.\n\nValidator Requirements\nMinimum Hardware\n\nCPU: 8 cores (16 cores recommended)\nRAM: 128 GB required\nStorage: 512 GB SSD/NVMe (1 TB+ recommended)\nNetwork: 100 Mbps+\nUptime: 99.9%+ required to avoid slashing\n\nMinimum Stake\n\nActive Set: Top 100 validators by voting power\nMinimum Self-Delegation: 1 AKT\nRecommended Initial Stake: 10,000+ AKT to be competitive\n\nCheck current requirements:\n\nDiscord: $votingpower command in #validator-alerts\nExplorer: Mintscan Akash Validators\n\nTechnical Requirements\n\nLinux experience - Command line proficiency\nNode operations - Understanding of blockchain nodes\nSecurity knowledge - Key management and server hardening\nMonitoring - Alerting and uptime tracking\n\nValidator Setup Options\nRunning a Validator\nDeploy a validator using the CLI on your own infrastructure.\nPrerequisites:\n\nFull Akash node running and synced\nAkash wallet with sufficient AKT\nServer meeting validator hardware requirements\n\nTime: 30-45 minutes (after node is synced)\n\nValidator via Omnibus\nDeploy a validator with sentry architecture on Akash Network.\nFeatures:\n\nSentry node protection\nRuns on Akash Network\nS3 bucket for key backup\nDDOS protection\n\nTime: 1-2 hours\n\nTMKMS with Stunnel\nAdvanced: Separate validator key management using TMKMS.\nUse for:\n\nEnhanced security\nHSM integration\nKey isolation\n\nTime: 2-3 hours\n\nValidator Economics\nRevenue Sources\n\nBlock Rewards - Fixed AKT inflation rewards\nTransaction Fees - Fees from network transactions\nCommission - Percentage of delegator rewards\n\nCosts & Risks\n\nServer Costs - $50-200/month depending on setup\nSlashing Risk - 0.01% for downtime, 5% for double-sign\nOpportunity Cost - Self-delegated AKT is locked\n\nCommission Rates\n\nTypical Range: 5-10%\nMaximum Rate: Set at validator creation (cannot increase beyond)\nMaximum Change Rate: Max % point change per day\n\nBefore You Start\nPrerequisites\n\nRun a Full Node First\n\nSee Node Build Guides\nEnsure node is fully synced before creating validator\n\nSecure Your Keys\n\nNever share your validator private key (priv_validator_key.json)\nConsider using TMKMS for key management\nBackup keys offline in multiple secure locations\n\nPlan for High Availability\n\nSet up monitoring and alerting\nConsider sentry node architecture\nHave a recovery plan for downtime\n\nUnderstand Slashing\n\nDowntime: Miss >50% of 10,000 blocks = 0.01% slash + jail\nDouble-Sign: Sign blocks at same height = 5% slash + tombstone\nJailed validators must submit unjail transaction\n\nValidator Resources\nCommunity\n\nDiscord: #validators channel\nTelegram: Akash Validators\n\nTools\n\nBlock Explorers:\n\nMintscan\nATOMScan\nArcturian Explorer\n\nMonitoring:\n\nPANIC by Simply VC\nTenderduty\n\nDocumentation\n\nCosmos Validator FAQ\nSentry Node Architecture\n\nReady to Begin?\nStart with a full node:\n→ Node Build Guides\nThen create your validator:\n→ Running a Validator \nEdit page on github\n Omnibus Running a Validator","tokens":882,"squid":"spider-03","role":"Compute Spider","at":1791348707973,"hash":"a3ad1831311862a6fceeba6290ff4d65ba1585d3"}
{"url":"https://research.arbitrum.io/t/the-power-of-faster-blocks/9609","domain":"research.arbitrum.io","title":"The power of faster blocks - Uncategorized - Arbitrum Research","text":"The power of faster blocks \n\n Uncategorized\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 5\n min\n\n May 2024\n\n 1 / 12\n\n May 2024\n\n Sep 2024\n\n post by edfelten on May 31, 2024\n\n edfelten\n\n One thing that distinguishes Arbitrum from other Layer 2 technologies is its fast block time. Arbitrum One makes blocks every 250 milliseconds, and Orbit chains can be configured with block time as low as 100 milliseconds—if there are transactions arriving that quickly.\nLet’s unpack how Arbitrum does this—but first, let’s review why it is important.\nWhy do we want fast block time?\nThe first advantage is obvious: faster blocks mean faster response time for users, which is great for user experience.\nThe second advantage of fast blocks is more subtle, but also quite important: it makes financial markets more efficient, and therefore attracts liquidity and leads to more market opportunities. Both theory and measurement (e.g., compare table 4A vs 4B in this Uniswap Labs paper) show that liquidity providers get better return on their investment when block times are fast, because less value is extracted by arbitragers. (tl;dr reason: Arbitragers exploit stale prices; faster blocks mean prices are less stale.) In a standard model known as “LVR with fees”, arbitrage extraction scales with the square root of the block time. This predicts that Arbitrum’s 250 millisecond block time leads to 65% lower arbitrage loss compared to a 2 second block time.\nThis pays off for users. Higher return for liquidity providers attracts more liquidity, and more liquidity means more and better trading opportunities for users. This is one big reason why Arbitrum One has more liquidity and more organic trading activity than any other L2, in DeFi applications like Uniswap.\nHow does Arbitrum provide fast block time?\nSo how does Arbitrum do it? There is an obvious answer and a less obvious one, which are both correct. Both tell part of the story.\nThe obvious answer is that the Arbitrum sequencer is designed and built with fast blocks in mind. This is reflected in many engineering decisions, large and small—and it’s a credit to the Offchain Labs engineering team which built the current sequencer.\nThe less obvious answer is that the design reflects a subtle shift in mindset, from a “block building” model to a “sequencing” model.\nBlock building conventionally works like this: the system publishes a block; everyone sees the block; users submit transactions for the next block; incoming transactions accumulate in a mempool until some deadline is reached; the system builds the next block by selecting and arranging some transactions from the mempool; and the cycle repeats.\nThe block building model has it advantages, but it’s not fast. You’re not going to operate that cycle at anything like a 250 millisecond cadence at scale in the real world.\nSequencing thinks of the problem differently: pack the transactions into blocks as soon as they arrive, filtering out invalid ones. When the scheduled time for the next block is reached, publish the already-built block (unless it’s empty) and start over. Don’t stop and wait for anyone; and don’t force transactions to sit around in a mempool awaiting a decision.\nSequencing is faster because it dispenses with the mempool, and it pipelines the process by sequencing each transaction immediately, and publishing each block as soon as it’s ready.\nAnother advantage of the sequencing model is that by making this process part of the protocol, rather than externalizing it to outside parties as often happens with block building, sequencing better protects against front-running, sandwiching, and other exploiting block-building tricks.\nNext steps for sequencing: MEV monetization and decentralization\nThere are two more steps on the road to sequencing nirvana: monetizing MEV and decentralizing the sequencing process.\nEthically monetizing MEV\nMonetizing MEV is important, so the chain can capture more of the economic value it is creating, but we want to be sure to monetize in a way that doesn’t undermine the advantages of fast sequencing. As an example, if we decided to auction block building rights, this would mean a switch back to block building mode, losing the speed advantage of sequencing—and opening the door to the high bidder exploiting users by front-running or sandwiching their transactions.\nAfter a lot of study, the Offchain Labs team prefers the latest version of “timeboost”: an express-lane auction approach to monetizing MEV. The idea is to retain the sequencing model, while creating an “express lane” for transactions. All transactions in the express lane would be sequenced immediately, while non-express lane transactions would be buffered (without leaking their contents) for 200 milliseconds before being sequenced. The right to use the express lane would be auctioned off for each period of (say) one minute.\nThe idea is that the party who buys express lane access would be able to get their transactions into the sequence ahead of everyone else (if they submit quickly), but they would not get to see what others had submitted. So that party can grab arbitrage and other non-exploitative MEV, but would still be prevented from sandwiching and similar exploits.\nThis approach maintains the fast response time advantage of fast sequencing, and protects economic efficiency by forcing arbitragers to act quickly so that prices don’t get stale.\nTimeboost is coming soon to the Arbitrum stack. Watch for news about this!\nDecentralizing sequencing\nThe last piece is to decentralize the sequencing protocol—again, without giving up what is good about sequencing. And we’re aiming for true decentralization, where no one party controls the contents of any block produced by the protocol.\nIn particular, we want to avoid a “rotating centralized” approach, in which a centralized party decides everything but different parties play that all-powerful role for different blocks. Such a strategy brings back many of the problems of block-building, including a slower timescale and the censorship and sandwiching problems.\nSo what we want is for sequencing to be done by a committee, with a guarantee that the rules for inclusion and ordering are followed as long as enough committee members are honest. This is the subject of an ongoing collaboration between Offchain Labs and Espresso Systems, to create a decentralized version of timeboost.\nWe’ll be writing more about decentralized timeboost over the coming weeks and months. (This post is long enough already.)\n\n 4\n\n 3\n\n read \n\n 5\n min\n\n post by mevmerlin on May 31, 2024\n\n mevmerlin\n\n The other advantage of fast blocks is that it turns your sequencer into tradfi latency games for searchers. On Arbitrum, I’m forced to co-locate servers to the closest possible proximity, or I’m out of the game. In contrast, while OP’s design lacks elegance, its auction process is way more fair. I can whip up a trading strategy in a few hours, deploy it on OP, and actually compete. To try that on Arbitrum means sinking $10k+ just to co-locate and even have a shot. This dead weight loss is not very good for competition. Im afraid we don’t understand the repercussions of this small block time accelerationism.\n\n post by 0xEvan on May 31, 2024\n\n 0xEvan\n\nI think we could look at Solana as an evolving glimpse of the future, which has ~400ms block times in practice today. The open question I wonder about is - does Arbitrum trend towards Solana like macro behavior on trading flow?\n\n 12 days later\n\n post by rfritsch on Jun 12, 2024\n\n rfritsch\n\n A major challenge here is to decentralize the sequencer while keeping the non-express lane transactions private, right?\nRegarding the reduction in MEV for faster block times, we actually emperically measured this in a recent work: [2404.05803] Measuring Arbitrage Losses and Profitability of AMM Liquidity (Figures 4 and 5)\nThe decrease in LVR varies quite a bit between trading pair, and is generally slower than the theoretical formula by Milionis et al. predicts.\n\n post by edfelten on Jun 12, 2024\n\n edfelten\n\n Yes, decentralizing while protecting non-express lane txs from front-running is a challenge. It looks like some kind of threshold decryption scheme is needed for that. We have ongoing research on how to fit together the needed pieces to make a viable decentralized sequencing protocol that does this (and doesn’t sacrifice other desirable properties).\n\n Proposed design for Timeboost\n\n post by rfritsch on Jun 18, 2024\n\n rfritsch\n\n Thanks, I’m looking forward to reading about this!\nI also want to add a thought on the timeboost in general:\nI understand the motivation: MEV already exists on Arbitrum, and profits currently go to the extractors. Making the extractors compete in an auction would redirect (most of) these profits to Arbitrum while not increasing the amount of MEV already being extracted from users.\nBut is the latter always true? Consider, for instance, LPs’ losses to arbitrageurs (LVR), which are currently one of the largest sources of MEV. These losses can be greatly reduced by using batch auctions (as in CoWSwap and its CoWAMM), which actually prevent the extraction of MEV in the first place. However, solutions like these could actually be impeded by timeboost.\nIf only a single arbitrageur can react to price changes during the final 0.25s of a batch auction, the batch auction’s key element – arbitrageurs competing on price – is nullified. The single arbitrageur would again be able to make a profit at the expense of the LP from any price change during the final 0.25s. (While CoWSwap orders are currently submitted off-chain and wouldn’t be affected, batch auctions submitting orders on-chain would be.)\nThis illustrates that introducing something like timeboost could potentially create new forms of MEV. More generally, MEV extractors can currently only pay to have transactions included before others, but still within the same block, and not a specific amount of time (like 0.25s) earlier. Introducing this new possibility could potentially create new MEV opportunities – which might be worth considering.\n\n post by edfelten on Jun 18, 2024\n\n edfelten\n\n It seems like any approach like CoWSwap’s, which uses a separate, custom per-application auction mechanism, would need to do something to prevent arbitrage outside of its mechanism, regardless of which sequencing policy is used.\nWhatever that mechanism is, it would need to be able to cope with one party having a submission time advantage over others–which is the case in any sequencing system, as far as I can tell.\n\n post by rfritsch on Jun 18, 2024\n\n rfritsch\n\n I see your point. I wonder to which extent this is the case though:\n\none party having a submission time advantage over others–which is the case in any sequencing system, as far as I can tell.\n\nPrecisely, what’s the time advantage of the fastest vs. the second-fastest arbitrageur for, say, Ethereum or Arbitrum? (It only takes two to have a competitive batch auction.)\nMy guess would be that it’s currently smaller, and timeboost would make a difference here (plus timeboost could add to an already existing advantage).\n\n post by 0xfust on Jun 22, 2024\n\n 0xfust\n\n Express lane model is efficient for capturing LVR or any MEV profit but few knows about that.\n\n 10 days later\n\n post by kakia on Jul 3, 2024\n\n kakia\n\n Exactly. Fast lane auction is open for everyone, in which LPs that consider loss versus rebalancing (LVR) to be a benchmark of their performance can participate and win. This will give them an option to react to outside information and price changes faster than any arbitrageur, thus solving LVR problem for them completely. They might be one of the active users of this auction. Those LPs that do not care about LVR, don’t need to worry anyway.\n\n 19 days later\n\n post by rfritsch on Jul 22, 2024\n\n rfritsch\n\n To “solve” (probably not the right word to use) LVR or other MEV, more than timeboost is needed. In particular, the value captured would need to be returned to the source (e.g. LPs for LVR).\nWith the current timeboost design, the value being extracted will go to Arbitrum (assuming the auction for the fast lane is competitive). That means, timeboost just diverts profits from MEV extractors to Arbitrum. Instead, these profits would need to go to liquidity pools. And then the problem arises how to distribute the profits between the pools.\nOne possibility here would be a separate fast lane per pool. This is similar to the idea of AMM pools selling the right to the first trade in a block, which has been around for a while: MEV capturing AMM (McAMM) - Applications - Ethereum Research\n\n 2 months later\n\n post by Gasai on Sep 18, 2024\n\n Gasai\n\n What factors, other than block time, affect the efficiency of arbitrage and liquidity?\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n MEV Capture Through Time-Advantaged Arbitrage\n\n Uncategorized\n\n 0\n\n 811\n\n Oct 2024\n\n Time boost: a new transaction ordering policy proposal\n\n Uncategorized\n\n 34\n\n 9.8k\n\n Sep 2023\n\n Proposed design for Timeboost\n\n Uncategorized\n\n 12\n\n 3.3k\n\n Jun 2024\n\n FairFlow: Leveraging TimeBoost to Build a Fair and Transparent L2 MEV Economy\n\n Uncategorized\n\n tx-ordering\n\n 0\n\n 448\n\n Apr 2025\n\n Transaction ordering policy\n\n Uncategorized\n\n 10\n\n 8.6k\n\n Mar 2023","tokens":3342,"squid":"spider-01","role":"Chain Spider","at":1791348711019,"hash":"e40dc075417ec4316c4917799eddc90754ddf854"}
{"url":"https://forum.across.to/t/across-ai-assistant/1842","domain":"forum.across.to","title":"Across AI Assistant - Proposals - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n Across AI Assistant \n\n Proposals\n\n treasury-funding\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 Mar 2024\n\n 1 / 5\n\n Mar 2024\n\n Mar 2024\n\n post by neondaemon on Mar 14, 2024\n\n neondaemon\n\n Title: Across AI Assistant Proposal\nAuthor(s): pennypanda., neondaemon\nStatus: Proposal\nSummary\nIntroducing Ross, a cutting-edge AI-powered assistant, designed for the Across Protocol community. Appy serves as a versatile Chat-based Assistant, streamlining the experience for both newcomers and seasoned experts in the Across community, trained on Across Documentation and live chats. From development support to general web3 inquiries, Appy is poised to become the go-to support system for all Across users.\nMotivation\nRoss is tailored to offer intuitive assistance to community members, developers, investors, partner projects and traders. By simply engaging in a chat, users can get precise answers to their queries.\nAccessible as a Discord bot, Ross stands out for its ease of use in various settings. In Discord communities, particularly within DAOs, the bot integrates seamlessly, transforming into a dynamic knowledge base about Across. This integration enhances community engagement by streamlining access to DAO documentation and promptly addressing common questions.\nSpecification & Implementation:\nThis proposal aims to develop Ross into a robust Discord bot, customizable to meet the specific information needs of the Across Discord Server.The goal is to scale Ross to cater to a wide range of Across users, making information readily accessible.\nObjectives\nRoss, as a sophisticated Chatbot, aims to support the following user groups and objectives:\n\nCommunity members: Guiding those curious about Across and the broader web3 world.\nDevelopers & Partner projects: Assisting both novice and advanced devs and potential partner projects in navigating the Across Protocol ecosystem.\nInvestors and Traders: Offering insights into trading and investments, portfolio management, and related token data analytics.\n\nPrimary objectives include:\n\nAccessibility: Seamless platform integration through wallet connectivity.\nPersonalization: Customized assistance and services based on user expertise and preferences.\nInformation Hub: Comprehensive insights about Across Protocol, and other DAOs and Communities in the Web3 space.\nData Analytics: Access to pertinent blockchain data\n\nCredit System\nA credit-based system will enable access to Ross. Users start with an initial credit pool that replenishes every 24 hours. Additional credits can be gained through community engagement and tasks. This system is being implemented as a rate-limit to protect the cost and ease of operations for the bot, and can be updated/changed.\nAcross-Special Features in Ross\n\nLearning and Knowledge Management\n\nDaily Learning Cycles: Ross will be able to analyze and learn from messages within defined channels every 24 hours, especially focusing on those written by members with reputable roles, such as Risk Labs and CEC Committee members.\nSelective Memory: By focusing on communications from specified roles like Admin, RL, CEC, Dev Support, and Bridge Guardians, Ross will be able to ensure it bases its knowledge on the most relevant and accurate information.\nBridge Transaction Updates: Members can ask about their bridge transactions and receive status updates and provide information about busy routes and possible delays, see LP positions.\n\nFeedback and Continuous Improvement\n\nInteractive Feedback System: The CEC committee will have the authority to control Ross’ responses. A dedicated channel for bot response logs will be created, where CEC and Admin members can review Ross’ responses. These role holding members can then cast vote with thumbs up or down reactions and provide specific feedback on improvements or corrections, ensuring Ross’ continuous learning and adaptation, while also allowing for human moderation on the bot’s actions.\nIntegration with Notion: To centralize access to frequently asked questions and their answers, Ross will store summarized interactions and learnings on a Notion page. This feature will serve as a living document, evolving with the community’s needs and Ross’ growing knowledge base.\n\nSome More Enhanced Features Specific to Across Protocol\n\nDocs Explainer: A starter pack offering a simplified breakdown of Across documentation.\nMigration Help: Help for migrating from Across v2 to v3.\nAcross Relay Assistance for devs: Guidance in writing, deploying, and understanding how to become a Relayer and other related coding assistance.\nTransaction Decoding: Detailed breakdown of transaction data, explaining each component of an on-chain transaction.\nOn-Chain Interactions: Guidance on where to find data about transactions, LP positions, fees etc.\n\nTeam & Budget\nIshan Pandey aka PennyPanda - Product Lead & Manager representing Ownos Studios, an anon product studio (being the reason why other builders’ names are not revealed here)\nMilestones\n\nScoping and Technical Design - 1 Week - $1000\nInitial Development of Discord Bot MVP - 2 Weeks - $4000\nFinal Iteration of the Discord Bot - 3 Weeks - $2000\n\nFund Request\nTotal Grant Request: 7000 USD in ACX tokens\nDevelopment and Testing: $5000\n1 year operating + support: $2000\nPayment Details\nPayment in two equal tranches.\nThe first $3500 will be part of the snapshot proposal.\nThe second $3500 will be on the successful delivery (assessed by RL/Across team) and be made from the Across DAO multi-sig.\nTeam Wallet: 0x5568416Fc7E9D575277c78a4f8272e873839f001\nThe budget will be allocated towards development, design, infrastructure costs (including OpenAI APIs, hosting, etc.), with any savings directed towards post-development and marketing efforts.\nWe are also open to letting the Across team have access to the complete source code once development is completed. This will allow them to review and test it for security purposes before the bot is made live on the server.\nAfter a 1 year period, the Across team can exercise their option to purchase the entire product from the Ownos team and continue running it as per their wishes without our involvement and retainer.\nRoss’ value to Across DAO\nIt would be highly improbable to set up an equivalent human run support system that works 24/7 and keeps up-to-date on a daily basis as well as Ross.\nLet’s assume and hourly rate of $7.25 per person.\n$7.25 times 24 = $174 per day\nDeveloping and maintaining Ross in the first year equates to $583 for a month. In effect Ross will work for around $0.70 an hour.\nRationale\nThe goal for developing Ross is to create a comprehensive, user-friendly, and adaptive AI assistant for the Across community. It aims to raise the standard of user support and serve as an ever-growing knowledge base for the community.\nBuilding Ross as the “home-bot” for our Across server in such a manner will ensure that members are able to receive quick support and answers. It will significantly reduce the time and effort required from dev support in answering questions, many of which are very simple and often repeated.\nIt will also be continuously self-updating, incorporating all new information and developments without manual intervention, and still leave room for the admins to be able to regulate it.\nWe believe that it serves as a good-to-have automation within the Across Community, which will definitely save time and energy and increase the quality of experience for our members, in particular:\n\nFocused Learning from Authoritative Sources: Prioritizing learning from reputable role members and specific channels ensures that Appy bases its knowledge on the most accurate and reliable information available. This method is preferred over a broader, less selective learning approach because it minimizes the risk of disseminating incorrect or outdated information, which is crucial in the rapidly evolving blockchain and web3 sectors.\n\nDaily Learning Cycles and Selective Memory: Implementing daily updates rather than real-time learning balances the need for up-to-date information with the practical considerations of processing time and computational resources. This strategy ensures Ross’ responses are both current and reflective of the latest community insights without overwhelming the system or causing unnecessary delays in response times.\n\nInteractive Feedback System: Providing a mechanism for continuous feedback from the community, especially from those in authoritative positions, allows for real-time quality control and adaptability of Ross’ responses. This feature is essential for maintaining trust and accuracy in the assistant’s interactions, offering a significant improvement over static AI models that cannot evolve with their user base’s needs.\n\nIntegration with Notion and Transition Plan for Future Operations: These elements of the proposal are designed to ensure sustainability and adaptability of the assistant over time. By creating a centralized knowledge base and planning for future operational transitions, the proposal ensures that Appy can continue to serve the community effectively, even as the underlying technology and ecosystem evolve.\n\nScenarios\nHypothetical scenarios that would make it easier for everyone to understand how Ross would work:\n\nImagine Joshua, an active user of the Across bridge, faces delays with his bridge transaction. Concerned, he enters the Discord server, summons Ross, and inputs his transaction ID. Ross quickly responds, identifying the congestion in the specific route Joshua’s transaction is using. It then provides an estimated resolution time based on current network conditions, reassuring Joshua with precise and actionable information.\n\nAlex is looking to use Across for the first time, is curious about the transaction fees. He asks Ross for details. Ross breaks down the fee structure for Alex, explaining the different components like gas fees, relay fees, etc. It even offers tips on how to minimize fees and the best times to transact to avoid higher gas prices, making Alex feel more confident in planning his transactions.\n\nElena is a dedicated member but often finds it challenging to stay up-to-date with the fast-paced discussions and updates happening in the Discord server due to her busy schedule. Elena activates Ross and requests a summary of the day’s most important discussions and any new updates announced by the Across team. Ross quickly finds an answer through the day’s chat logs, highlighting key conversations, summarizing user concerns, and pinpointing solutions provided. Additionally, Ross informs Elena about a recent protocol update that introduces a new liquidity pool feature, offering a simplified explanation of how it benefits users and enhances transaction efficiency.\n\nDownsides\nThe development and maintenance of such an assistant entail significant resource investment. This includes the upfront costs for development and ongoing expenses for operations and updates.\nThere is a slight risk of the community becoming overly reliant on Ross for information, which might deter individual research and due diligence. And despite the focused learning and continuous feedback mechanisms, there is always a risk that Ross could disseminate incorrect information due to rapidly changing conditions or misunderstandings in its learning process.\nMonitoring will be required to mitigate this risk. Even with these possible challenges, our commitment to overcoming them reinforces our belief in Ross’ value as an innovative, time-saving tool that enhances the Across community.\nVoting:\n\n Do you want Ross to become the helper bot for Across DAO?\n\n 100%\n Yes\n\n 0%\n Abstain\n\n 0%\n No\n\n 5\n voters\n\n read \n\n 4\n min\n\n post by EAsports on Mar 17, 2024\n\n post by pennypanda on Mar 18, 2024\n\n post by trippz10x on Mar 20, 2024\n\n 1 month later\n\n Closed on Apr 19, 2024\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Across AI Assistant Proposal\n\n Ideas & Feedback\n\n Ideas & Feedback\n\n 11\n\n Dec 2024\n\n AcrossAlert Proposal: Amplifying Across’s Excellence on Twitter\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 5\n\n May 2024\n\n # Across Community Essentials Committee Renewal Proposal for Q2-Q3 2025\n\n Committees\n\n Committees\n\n 4\n\n Mar 2025\n\n Across Community Essentials Committee Formation Proposal\n\n Ideas & Feedback\n\n Ideas & Feedback\n\n 5\n\n Sep 2023\n\n Across Community Essentials Committee Renewal Proposal - Dec 2023\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 5\n\n Dec 2023","tokens":4615,"squid":"spider-09","role":"Bridge Spider","at":1791348713955,"hash":"7582111e433c6b5c842c8ee46248aeacea9d28a2"}
{"url":"https://akash.network/docs/node-operators/network-upgrades/","domain":"akash.network","title":"Network Upgrades | Akash Network - Your Guide to Decentralized Cloud","text":"Network Upgrades Stay up to date with Akash Network upgrades.\nThis section contains comprehensive upgrade guides for node operators and validators, including both Cosmovisor (automated) and manual upgrade instructions.\n\nCurrent Network Upgrade\nMainnet 18 - Akash v2.1.0\nStatus: Upcoming\nGovernance Proposal: #328\nUpgrade Height: 27,230,465\nEstimated Time: June 11th, 2026 at ~14:00 UTC\nBinary Version: v2.1.0\nComplete upgrade guide including Oracle v2, Resource Reclamation (AEP-82), Cosmovisor and manual upgrade instructions, build from source guide, and troubleshooting. Monitor block height and Discord for timing; prepare your node before the upgrade.\n\nUpgrade Coordination\nDiscord Channels:\n\n#validators - Support and discussion\n#validator-announcements - Official announcements\n\nResources:\n\nGitHub Releases\nNetwork Info\nBlock Explorers\n\nBest Practices\nBefore Every Upgrade:\n\nRead the complete upgrade guide\nBackup your validator keys\nMonitor Discord channels for announcements\nVerify binary checksums\nBe available during the upgrade window\n\nRecommended Setup:\n\nUse Cosmovisor for automatic upgrades\nEnable monitoring and alerting\nHave a rollback plan ready\nJoin Discord for real-time coordination\n\nEdit page on github\n TMKMS and Stunnel Mainnet 18","tokens":314,"squid":"spider-03","role":"Compute Spider","at":1791348717856,"hash":"ff00fc44ecb4ffcc446636664047625a0ab5ac6d"}
{"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":"spider-07","role":"Council Spider","at":1791348722746,"hash":"ea21227194c68cdb68f2594afbedc0af831c7cb9"}
{"url":"https://forum.across.to/t/across-ai-assistant/1842/1","domain":"forum.across.to","title":"Across AI Assistant - Proposals - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n Across AI Assistant \n\n Proposals\n\n treasury-funding\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 Mar 2024\n\n 1 / 5\n\n Mar 2024\n\n Mar 2024\n\n post by neondaemon on Mar 14, 2024\n\n neondaemon\n\n Title: Across AI Assistant Proposal\nAuthor(s): pennypanda., neondaemon\nStatus: Proposal\nSummary\nIntroducing Ross, a cutting-edge AI-powered assistant, designed for the Across Protocol community. Appy serves as a versatile Chat-based Assistant, streamlining the experience for both newcomers and seasoned experts in the Across community, trained on Across Documentation and live chats. From development support to general web3 inquiries, Appy is poised to become the go-to support system for all Across users.\nMotivation\nRoss is tailored to offer intuitive assistance to community members, developers, investors, partner projects and traders. By simply engaging in a chat, users can get precise answers to their queries.\nAccessible as a Discord bot, Ross stands out for its ease of use in various settings. In Discord communities, particularly within DAOs, the bot integrates seamlessly, transforming into a dynamic knowledge base about Across. This integration enhances community engagement by streamlining access to DAO documentation and promptly addressing common questions.\nSpecification & Implementation:\nThis proposal aims to develop Ross into a robust Discord bot, customizable to meet the specific information needs of the Across Discord Server.The goal is to scale Ross to cater to a wide range of Across users, making information readily accessible.\nObjectives\nRoss, as a sophisticated Chatbot, aims to support the following user groups and objectives:\n\nCommunity members: Guiding those curious about Across and the broader web3 world.\nDevelopers & Partner projects: Assisting both novice and advanced devs and potential partner projects in navigating the Across Protocol ecosystem.\nInvestors and Traders: Offering insights into trading and investments, portfolio management, and related token data analytics.\n\nPrimary objectives include:\n\nAccessibility: Seamless platform integration through wallet connectivity.\nPersonalization: Customized assistance and services based on user expertise and preferences.\nInformation Hub: Comprehensive insights about Across Protocol, and other DAOs and Communities in the Web3 space.\nData Analytics: Access to pertinent blockchain data\n\nCredit System\nA credit-based system will enable access to Ross. Users start with an initial credit pool that replenishes every 24 hours. Additional credits can be gained through community engagement and tasks. This system is being implemented as a rate-limit to protect the cost and ease of operations for the bot, and can be updated/changed.\nAcross-Special Features in Ross\n\nLearning and Knowledge Management\n\nDaily Learning Cycles: Ross will be able to analyze and learn from messages within defined channels every 24 hours, especially focusing on those written by members with reputable roles, such as Risk Labs and CEC Committee members.\nSelective Memory: By focusing on communications from specified roles like Admin, RL, CEC, Dev Support, and Bridge Guardians, Ross will be able to ensure it bases its knowledge on the most relevant and accurate information.\nBridge Transaction Updates: Members can ask about their bridge transactions and receive status updates and provide information about busy routes and possible delays, see LP positions.\n\nFeedback and Continuous Improvement\n\nInteractive Feedback System: The CEC committee will have the authority to control Ross’ responses. A dedicated channel for bot response logs will be created, where CEC and Admin members can review Ross’ responses. These role holding members can then cast vote with thumbs up or down reactions and provide specific feedback on improvements or corrections, ensuring Ross’ continuous learning and adaptation, while also allowing for human moderation on the bot’s actions.\nIntegration with Notion: To centralize access to frequently asked questions and their answers, Ross will store summarized interactions and learnings on a Notion page. This feature will serve as a living document, evolving with the community’s needs and Ross’ growing knowledge base.\n\nSome More Enhanced Features Specific to Across Protocol\n\nDocs Explainer: A starter pack offering a simplified breakdown of Across documentation.\nMigration Help: Help for migrating from Across v2 to v3.\nAcross Relay Assistance for devs: Guidance in writing, deploying, and understanding how to become a Relayer and other related coding assistance.\nTransaction Decoding: Detailed breakdown of transaction data, explaining each component of an on-chain transaction.\nOn-Chain Interactions: Guidance on where to find data about transactions, LP positions, fees etc.\n\nTeam & Budget\nIshan Pandey aka PennyPanda - Product Lead & Manager representing Ownos Studios, an anon product studio (being the reason why other builders’ names are not revealed here)\nMilestones\n\nScoping and Technical Design - 1 Week - $1000\nInitial Development of Discord Bot MVP - 2 Weeks - $4000\nFinal Iteration of the Discord Bot - 3 Weeks - $2000\n\nFund Request\nTotal Grant Request: 7000 USD in ACX tokens\nDevelopment and Testing: $5000\n1 year operating + support: $2000\nPayment Details\nPayment in two equal tranches.\nThe first $3500 will be part of the snapshot proposal.\nThe second $3500 will be on the successful delivery (assessed by RL/Across team) and be made from the Across DAO multi-sig.\nTeam Wallet: 0x5568416Fc7E9D575277c78a4f8272e873839f001\nThe budget will be allocated towards development, design, infrastructure costs (including OpenAI APIs, hosting, etc.), with any savings directed towards post-development and marketing efforts.\nWe are also open to letting the Across team have access to the complete source code once development is completed. This will allow them to review and test it for security purposes before the bot is made live on the server.\nAfter a 1 year period, the Across team can exercise their option to purchase the entire product from the Ownos team and continue running it as per their wishes without our involvement and retainer.\nRoss’ value to Across DAO\nIt would be highly improbable to set up an equivalent human run support system that works 24/7 and keeps up-to-date on a daily basis as well as Ross.\nLet’s assume and hourly rate of $7.25 per person.\n$7.25 times 24 = $174 per day\nDeveloping and maintaining Ross in the first year equates to $583 for a month. In effect Ross will work for around $0.70 an hour.\nRationale\nThe goal for developing Ross is to create a comprehensive, user-friendly, and adaptive AI assistant for the Across community. It aims to raise the standard of user support and serve as an ever-growing knowledge base for the community.\nBuilding Ross as the “home-bot” for our Across server in such a manner will ensure that members are able to receive quick support and answers. It will significantly reduce the time and effort required from dev support in answering questions, many of which are very simple and often repeated.\nIt will also be continuously self-updating, incorporating all new information and developments without manual intervention, and still leave room for the admins to be able to regulate it.\nWe believe that it serves as a good-to-have automation within the Across Community, which will definitely save time and energy and increase the quality of experience for our members, in particular:\n\nFocused Learning from Authoritative Sources: Prioritizing learning from reputable role members and specific channels ensures that Appy bases its knowledge on the most accurate and reliable information available. This method is preferred over a broader, less selective learning approach because it minimizes the risk of disseminating incorrect or outdated information, which is crucial in the rapidly evolving blockchain and web3 sectors.\n\nDaily Learning Cycles and Selective Memory: Implementing daily updates rather than real-time learning balances the need for up-to-date information with the practical considerations of processing time and computational resources. This strategy ensures Ross’ responses are both current and reflective of the latest community insights without overwhelming the system or causing unnecessary delays in response times.\n\nInteractive Feedback System: Providing a mechanism for continuous feedback from the community, especially from those in authoritative positions, allows for real-time quality control and adaptability of Ross’ responses. This feature is essential for maintaining trust and accuracy in the assistant’s interactions, offering a significant improvement over static AI models that cannot evolve with their user base’s needs.\n\nIntegration with Notion and Transition Plan for Future Operations: These elements of the proposal are designed to ensure sustainability and adaptability of the assistant over time. By creating a centralized knowledge base and planning for future operational transitions, the proposal ensures that Appy can continue to serve the community effectively, even as the underlying technology and ecosystem evolve.\n\nScenarios\nHypothetical scenarios that would make it easier for everyone to understand how Ross would work:\n\nImagine Joshua, an active user of the Across bridge, faces delays with his bridge transaction. Concerned, he enters the Discord server, summons Ross, and inputs his transaction ID. Ross quickly responds, identifying the congestion in the specific route Joshua’s transaction is using. It then provides an estimated resolution time based on current network conditions, reassuring Joshua with precise and actionable information.\n\nAlex is looking to use Across for the first time, is curious about the transaction fees. He asks Ross for details. Ross breaks down the fee structure for Alex, explaining the different components like gas fees, relay fees, etc. It even offers tips on how to minimize fees and the best times to transact to avoid higher gas prices, making Alex feel more confident in planning his transactions.\n\nElena is a dedicated member but often finds it challenging to stay up-to-date with the fast-paced discussions and updates happening in the Discord server due to her busy schedule. Elena activates Ross and requests a summary of the day’s most important discussions and any new updates announced by the Across team. Ross quickly finds an answer through the day’s chat logs, highlighting key conversations, summarizing user concerns, and pinpointing solutions provided. Additionally, Ross informs Elena about a recent protocol update that introduces a new liquidity pool feature, offering a simplified explanation of how it benefits users and enhances transaction efficiency.\n\nDownsides\nThe development and maintenance of such an assistant entail significant resource investment. This includes the upfront costs for development and ongoing expenses for operations and updates.\nThere is a slight risk of the community becoming overly reliant on Ross for information, which might deter individual research and due diligence. And despite the focused learning and continuous feedback mechanisms, there is always a risk that Ross could disseminate incorrect information due to rapidly changing conditions or misunderstandings in its learning process.\nMonitoring will be required to mitigate this risk. Even with these possible challenges, our commitment to overcoming them reinforces our belief in Ross’ value as an innovative, time-saving tool that enhances the Across community.\nVoting:\n\n Do you want Ross to become the helper bot for Across DAO?\n\n 100%\n Yes\n\n 0%\n Abstain\n\n 0%\n No\n\n 5\n voters\n\n read \n\n 4\n min\n\n post by EAsports on Mar 17, 2024\n\n EAsports\n\n I am supportive of this and like the concept and potential value proposition overall. Interested to see how it works as pre-AI versions of this used certain ! commands to answer common questions or reference documentation. I can see this being a large improvement.\none thing I am hesitant about is the potential for ongoing cost to pay for compute and hosting resources for the bot. Do you have estimates based on usage for ongoing costs?\n\n post by pennypanda on Mar 18, 2024\n\n pennypanda\n\n hey EA!\nI will devise estimates once we further experiment with the models. I am confident that the budget allocated for infrastructure is more than sufficient to support the running and hosting of the bot for the entire year.\n\n post by trippz10x on Mar 20, 2024\n\n trippz10x\n\n Great idea, absolutely love it, will improve user experience in the community and the general user of Across Products\n\n 1 month later\n\n Closed on Apr 19, 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 Across AI Assistant Proposal\n\n Ideas & Feedback\n\n Ideas & Feedback\n\n 11\n\n Dec 2024\n\n AcrossAlert Proposal: Amplifying Across’s Excellence on Twitter\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 5\n\n May 2024\n\n # Across Community Essentials Committee Renewal Proposal for Q2-Q3 2025\n\n Committees\n\n Committees\n\n 4\n\n Mar 2025\n\n Across Community Essentials Committee Formation Proposal\n\n Ideas & Feedback\n\n Ideas & Feedback\n\n 5\n\n Sep 2023\n\n Across Community Essentials Committee Renewal Proposal - Dec 2023\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 5\n\n Dec 2023","tokens":4847,"squid":"spider-09","role":"Bridge Spider","at":1791348726365,"hash":"70f538fe4980503da4429c74846ab28507dafed1"}
{"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":"spider-07","role":"Council Spider","at":1791348733517,"hash":"948ca1e9b1788ebbe68a04677d792df1f39f8b05"}
{"url":"https://www.metaplex.com/docs/dev-tools/cli/agents/fetch","domain":"metaplex.com","title":"Fetch Agent | Metaplex CLI","text":"What You'll DoFetch and inspect a registered agent's on-chain identity data:View the agent identity PDA and Asset Signer walletCheck registration URI and lifecycle hooksVerify whether an asset has a registered agent identitySummaryThe mplx agents fetch command reads the on-chain agent identity PDA for an MPL Core asset and displays registration info, lifecycle hooks, and the agent's built-in wallet (Asset Signer PDA).Input: An MPL Core asset address (from agents register)Output: Identity PDA, wallet PDA, registration URI, lifecycle hooksNo required flags: Only the asset address is required; --json is optionalJump to: Quick Reference · Usage · Output · NotesQuick ReferenceItemValueCommandmplx agents fetch <AGENT_ASSET>Required argumentAGENT_ASSET — the agent's Core asset addressOptional flags--json — machine-readable outputUsageFetch agent identitymplx agents fetch <AGENT_ASSET>\nOutputExpected output (registered agent){\n registered: true,\n agentAsset: '<agent_asset_address>',\n owner: '<owner_address>',\n identityPda: '<identity_pda_address>',\n agentWallet: '<asset_signer_pda_address>',\n registrationUri: 'https://...',\n lifecycleChecks: { ... }\n}\nIf the asset does not have a registered agent identity:Expected output (not registered)No agent identity found for this asset. The asset may not be registered.\nNotesThe agentWallet field is the Asset Signer PDA — the agent's built-in wallet used for signing transactions and holding fundsThe registrationUri points to the JSON document uploaded during registration containing the agent's name, description, services, and trust modelsUse --json for machine-readable output","tokens":408,"squid":"dotcat","role":"Tooling Spider","at":1791348734397,"hash":"95cdefb3db38bbde30ee5805d5c4201cdc07d0c1"}
{"url":"https://forum.across.to/t/across-ai-assistant/1842/5","domain":"forum.across.to","title":"Across AI Assistant - Proposals - Across Protocol","text":"This site is in read only mode. Please continue to browse, but signing up and logging in are unavailable for now.\n\n The Bridge Across\nTitle: The Bridge Across - Temp check proposal for a potential Across Token Buyout\nAuthor(s): Risk Labs\nStatus: RFC\nSubmission Date: 11-03-2026\nBody\nSummary:\nThis proposal explores whether transitioning from a token structure to a private company through an ACX token-to-equity exchange and buyout offer would better serve long-term protocol growth. The goal of the proposal is to strengthen our commitment to Across, while continuing to ensure token holders can participate in Across’ success, to the extent legally permissible.\nThis proposal is a temperature check. Nothing proceeds without community discussion and a formal governance vote.\nMotivation:\nThe Risk Labs team has been building Across Protocol and its suite of products for over 4 years. During this journey, we have invented the crosschain “intents” architecture, made 2 second bridging table stakes for our industry, and secured partnerships with countless tier 1 industry leaders.\nBy empowering ACX holders with a sense of ownership, we saw our opportunities, integrations, and partnerships flourish. Risk Labs has stayed token-purist throughout: no private company, only foundation-managed operations, everything built in public.\nHowever, as Across deepens our work with institutional and enterprise partners, the token and DAO structure has materially impacted our ability to close partnerships and integrations. Transitioning to a traditional legal entity would meaningfully improve our ability to enter enforceable contracts, structure revenue agreements, and deliver more value to Across stakeholders.\nAt current ACX valuations, we believe the Across Protocol is significantly undervalued. The proposed structure gives us an opportunity to explore new ways to foster growth while acting in the best interests of the broader Across community.\nThis proposal, “The Bridge Across”, is about aligning ownership, incentives, and governance to set a new foundation for growth and success.\nSpecification & Implementation:\nIf supported, a newly formed U.S. C-corp (ie: “AcrossCo”) would become the new operating entity. AcrossCo would hold all protocol IP and manage development, partnerships, and commercialization. ACX holders would have two distinct options:\n\nEquity exchange: Exchanging tokens for equity exposure in AcrossCo (directly or via an SPV), to the extent legally permissible.\n\nToken buyout: A token buyout option, where ACX holders are able to receive USDC as consideration for selling ACX.\n\nEquity exchange\nAll equity exchanges for all stakeholders would happen at a 1:1 ownership ratio: if you own 1,000 ACX tokens, you would exchange for 1,000 shares (or equivalent units in the case of the SPV) in AcrossCo. All token holders—institutional investors, employees, everyday token holders—are treated the same.\nHolders with >5M ACX will be able to convert to equity directly. Holders with <5M ACX would be able to exchange for equity via a no-fee SPV structure, subject to a minimum exchange size (currently targeting 250k ACX, or approx. ~$10k) for legal and administration practicalities. We are purposefully targeting a low minimum exchange size to be as inclusive as possible to the ACX holder base.\nFill in this form (simple, under 1min) to indicate your interest in this token-to-equity exchange. This is a preliminary, non-binding expression of interest. For the SPV involvement, US security laws limit us to the first 100 US investors and first ~500 non-US investors. Other (required) legal restrictions apply, including that the US investor must verify their status as “accredited investors” to participate.\nToken buyout\nHolders who choose to not participate in the token-to-equity exchange will be given an opportunity to sell ACX for USDC at price of $0.04375, a 25% premium to today’s previous 30 day average trading price.\nThis ACX-to-USDC buyout would be available for up to a 6-month window, which we anticipate would open within 3 months of this proposal passing. Across’ liquid assets, roughly equating to the current market cap of the protocol, will be utilized to finance this buyout.\nWhat changes (and what doesn’t)\nAcross Protocol will continue operating without interruption. If this proposal is passed, a transition period would occur where ACX would be purchased from eligible ACX holders. AcrossCo would then set out with institutional clarity and a new path for success.\nThis is an opportunity for Risk Labs and ACX stakeholders to double down on Across, setting precedent for how protocols can evolve beyond token structures to build lasting infrastructure.\nEstimated Timeline\n\nMarch 11th: This temp check is posted to the Across Forum. \n\nMarch 18th: “The Bridge Across” community call where the Across leadership will answer all open questions.\n\nMarch 25th: Temp check forum discussion\n\nMarch 26th: Finalized proposal posted for Snapshot voting.\n\nApril 2nd: Snapshot vote passes/fails\n\nApril 3rd: Contingent of proposal passing, work commences on (i) legal structuring, (ii) SPV creation and investor rollovers, and (iii) development on an exchange/sell UI.\n\nWithin 3 months of proposal passing, ACX holders will be able to exchange or sell their tokens and the 6 month buyout window will begin.\n\nNote this timeline is an estimate and may change based on public feedback.\nRationale\nThis proposal follows months of internal legal and regulatory review. Our goal is to offer ACX holders two distinct paths forward—equity exchange or sell —while also clearing a path for the continued growth of Across Protocol. We want to chart a new course while maintaining integrity toward the protocol, team, community, and stakeholders.\nNext Steps\nWe invite community feedback on this proposal’s benefits, drawbacks, and implications. Risk Labs will actively engage throughout this temp check and answer questions before moving forward.\n\n Proposals\n\n treasury-funding\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 Mar 2024\n\n 5 / 5\n\n Apr 2024\n\n Mar 2024\n\n post by neondaemon on Mar 14, 2024\n\n neondaemon\n\n Title: Across AI Assistant Proposal\nAuthor(s): pennypanda., neondaemon\nStatus: Proposal\nSummary\nIntroducing Ross, a cutting-edge AI-powered assistant, designed for the Across Protocol community. Appy serves as a versatile Chat-based Assistant, streamlining the experience for both newcomers and seasoned experts in the Across community, trained on Across Documentation and live chats. From development support to general web3 inquiries, Appy is poised to become the go-to support system for all Across users.\nMotivation\nRoss is tailored to offer intuitive assistance to community members, developers, investors, partner projects and traders. By simply engaging in a chat, users can get precise answers to their queries.\nAccessible as a Discord bot, Ross stands out for its ease of use in various settings. In Discord communities, particularly within DAOs, the bot integrates seamlessly, transforming into a dynamic knowledge base about Across. This integration enhances community engagement by streamlining access to DAO documentation and promptly addressing common questions.\nSpecification & Implementation:\nThis proposal aims to develop Ross into a robust Discord bot, customizable to meet the specific information needs of the Across Discord Server.The goal is to scale Ross to cater to a wide range of Across users, making information readily accessible.\nObjectives\nRoss, as a sophisticated Chatbot, aims to support the following user groups and objectives:\n\nCommunity members: Guiding those curious about Across and the broader web3 world.\nDevelopers & Partner projects: Assisting both novice and advanced devs and potential partner projects in navigating the Across Protocol ecosystem.\nInvestors and Traders: Offering insights into trading and investments, portfolio management, and related token data analytics.\n\nPrimary objectives include:\n\nAccessibility: Seamless platform integration through wallet connectivity.\nPersonalization: Customized assistance and services based on user expertise and preferences.\nInformation Hub: Comprehensive insights about Across Protocol, and other DAOs and Communities in the Web3 space.\nData Analytics: Access to pertinent blockchain data\n\nCredit System\nA credit-based system will enable access to Ross. Users start with an initial credit pool that replenishes every 24 hours. Additional credits can be gained through community engagement and tasks. This system is being implemented as a rate-limit to protect the cost and ease of operations for the bot, and can be updated/changed.\nAcross-Special Features in Ross\n\nLearning and Knowledge Management\n\nDaily Learning Cycles: Ross will be able to analyze and learn from messages within defined channels every 24 hours, especially focusing on those written by members with reputable roles, such as Risk Labs and CEC Committee members.\nSelective Memory: By focusing on communications from specified roles like Admin, RL, CEC, Dev Support, and Bridge Guardians, Ross will be able to ensure it bases its knowledge on the most relevant and accurate information.\nBridge Transaction Updates: Members can ask about their bridge transactions and receive status updates and provide information about busy routes and possible delays, see LP positions.\n\nFeedback and Continuous Improvement\n\nInteractive Feedback System: The CEC committee will have the authority to control Ross’ responses. A dedicated channel for bot response logs will be created, where CEC and Admin members can review Ross’ responses. These role holding members can then cast vote with thumbs up or down reactions and provide specific feedback on improvements or corrections, ensuring Ross’ continuous learning and adaptation, while also allowing for human moderation on the bot’s actions.\nIntegration with Notion: To centralize access to frequently asked questions and their answers, Ross will store summarized interactions and learnings on a Notion page. This feature will serve as a living document, evolving with the community’s needs and Ross’ growing knowledge base.\n\nSome More Enhanced Features Specific to Across Protocol\n\nDocs Explainer: A starter pack offering a simplified breakdown of Across documentation.\nMigration Help: Help for migrating from Across v2 to v3.\nAcross Relay Assistance for devs: Guidance in writing, deploying, and understanding how to become a Relayer and other related coding assistance.\nTransaction Decoding: Detailed breakdown of transaction data, explaining each component of an on-chain transaction.\nOn-Chain Interactions: Guidance on where to find data about transactions, LP positions, fees etc.\n\nTeam & Budget\nIshan Pandey aka PennyPanda - Product Lead & Manager representing Ownos Studios, an anon product studio (being the reason why other builders’ names are not revealed here)\nMilestones\n\nScoping and Technical Design - 1 Week - $1000\nInitial Development of Discord Bot MVP - 2 Weeks - $4000\nFinal Iteration of the Discord Bot - 3 Weeks - $2000\n\nFund Request\nTotal Grant Request: 7000 USD in ACX tokens\nDevelopment and Testing: $5000\n1 year operating + support: $2000\nPayment Details\nPayment in two equal tranches.\nThe first $3500 will be part of the snapshot proposal.\nThe second $3500 will be on the successful delivery (assessed by RL/Across team) and be made from the Across DAO multi-sig.\nTeam Wallet: 0x5568416Fc7E9D575277c78a4f8272e873839f001\nThe budget will be allocated towards development, design, infrastructure costs (including OpenAI APIs, hosting, etc.), with any savings directed towards post-development and marketing efforts.\nWe are also open to letting the Across team have access to the complete source code once development is completed. This will allow them to review and test it for security purposes before the bot is made live on the server.\nAfter a 1 year period, the Across team can exercise their option to purchase the entire product from the Ownos team and continue running it as per their wishes without our involvement and retainer.\nRoss’ value to Across DAO\nIt would be highly improbable to set up an equivalent human run support system that works 24/7 and keeps up-to-date on a daily basis as well as Ross.\nLet’s assume and hourly rate of $7.25 per person.\n$7.25 times 24 = $174 per day\nDeveloping and maintaining Ross in the first year equates to $583 for a month. In effect Ross will work for around $0.70 an hour.\nRationale\nThe goal for developing Ross is to create a comprehensive, user-friendly, and adaptive AI assistant for the Across community. It aims to raise the standard of user support and serve as an ever-growing knowledge base for the community.\nBuilding Ross as the “home-bot” for our Across server in such a manner will ensure that members are able to receive quick support and answers. It will significantly reduce the time and effort required from dev support in answering questions, many of which are very simple and often repeated.\nIt will also be continuously self-updating, incorporating all new information and developments without manual intervention, and still leave room for the admins to be able to regulate it.\nWe believe that it serves as a good-to-have automation within the Across Community, which will definitely save time and energy and increase the quality of experience for our members, in particular:\n\nFocused Learning from Authoritative Sources: Prioritizing learning from reputable role members and specific channels ensures that Appy bases its knowledge on the most accurate and reliable information available. This method is preferred over a broader, less selective learning approach because it minimizes the risk of disseminating incorrect or outdated information, which is crucial in the rapidly evolving blockchain and web3 sectors.\n\nDaily Learning Cycles and Selective Memory: Implementing daily updates rather than real-time learning balances the need for up-to-date information with the practical considerations of processing time and computational resources. This strategy ensures Ross’ responses are both current and reflective of the latest community insights without overwhelming the system or causing unnecessary delays in response times.\n\nInteractive Feedback System: Providing a mechanism for continuous feedback from the community, especially from those in authoritative positions, allows for real-time quality control and adaptability of Ross’ responses. This feature is essential for maintaining trust and accuracy in the assistant’s interactions, offering a significant improvement over static AI models that cannot evolve with their user base’s needs.\n\nIntegration with Notion and Transition Plan for Future Operations: These elements of the proposal are designed to ensure sustainability and adaptability of the assistant over time. By creating a centralized knowledge base and planning for future operational transitions, the proposal ensures that Appy can continue to serve the community effectively, even as the underlying technology and ecosystem evolve.\n\nScenarios\nHypothetical scenarios that would make it easier for everyone to understand how Ross would work:\n\nImagine Joshua, an active user of the Across bridge, faces delays with his bridge transaction. Concerned, he enters the Discord server, summons Ross, and inputs his transaction ID. Ross quickly responds, identifying the congestion in the specific route Joshua’s transaction is using. It then provides an estimated resolution time based on current network conditions, reassuring Joshua with precise and actionable information.\n\nAlex is looking to use Across for the first time, is curious about the transaction fees. He asks Ross for details. Ross breaks down the fee structure for Alex, explaining the different components like gas fees, relay fees, etc. It even offers tips on how to minimize fees and the best times to transact to avoid higher gas prices, making Alex feel more confident in planning his transactions.\n\nElena is a dedicated member but often finds it challenging to stay up-to-date with the fast-paced discussions and updates happening in the Discord server due to her busy schedule. Elena activates Ross and requests a summary of the day’s most important discussions and any new updates announced by the Across team. Ross quickly finds an answer through the day’s chat logs, highlighting key conversations, summarizing user concerns, and pinpointing solutions provided. Additionally, Ross informs Elena about a recent protocol update that introduces a new liquidity pool feature, offering a simplified explanation of how it benefits users and enhances transaction efficiency.\n\nDownsides\nThe development and maintenance of such an assistant entail significant resource investment. This includes the upfront costs for development and ongoing expenses for operations and updates.\nThere is a slight risk of the community becoming overly reliant on Ross for information, which might deter individual research and due diligence. And despite the focused learning and continuous feedback mechanisms, there is always a risk that Ross could disseminate incorrect information due to rapidly changing conditions or misunderstandings in its learning process.\nMonitoring will be required to mitigate this risk. Even with these possible challenges, our commitment to overcoming them reinforces our belief in Ross’ value as an innovative, time-saving tool that enhances the Across community.\nVoting:\n\n Do you want Ross to become the helper bot for Across DAO?\n\n 100%\n Yes\n\n 0%\n Abstain\n\n 0%\n No\n\n 5\n voters\n\n read \n\n 4\n min\n\n post by EAsports on Mar 17, 2024\n\n EAsports\n\n I am supportive of this and like the concept and potential value proposition overall. Interested to see how it works as pre-AI versions of this used certain ! commands to answer common questions or reference documentation. I can see this being a large improvement.\none thing I am hesitant about is the potential for ongoing cost to pay for compute and hosting resources for the bot. Do you have estimates based on usage for ongoing costs?\n\n post by pennypanda on Mar 18, 2024\n\n pennypanda\n\n hey EA!\nI will devise estimates once we further experiment with the models. I am confident that the budget allocated for infrastructure is more than sufficient to support the running and hosting of the bot for the entire year.\n\n post by trippz10x on Mar 20, 2024\n\n trippz10x\n\n Great idea, absolutely love it, will improve user experience in the community and the general user of Across Products\n\n 1 month later\n\n Closed on Apr 19, 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 Across AI Assistant Proposal\n\n Ideas & Feedback\n\n Ideas & Feedback\n\n 11\n\n Dec 2024\n\n AcrossAlert Proposal: Amplifying Across’s Excellence on Twitter\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 5\n\n May 2024\n\n # Across Community Essentials Committee Renewal Proposal for Q2-Q3 2025\n\n Committees\n\n Committees\n\n 4\n\n Mar 2025\n\n Across Community Essentials Committee Formation Proposal\n\n Ideas & Feedback\n\n Ideas & Feedback\n\n 5\n\n Sep 2023\n\n Across Community Essentials Committee Renewal Proposal - Dec 2023\n\n Proposals\n\n treasury-funding\n\n Proposals\n\n 5\n\n Dec 2023","tokens":4842,"squid":"spider-09","role":"Bridge Spider","at":1791348736648,"hash":"8be55632df3447704e6eeb5d82eef94b181feea8"}
{"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":"spider-07","role":"Council Spider","at":1791348743851,"hash":"773c4ea834de5367281a29037eb3844ff7248ab1"}